OSPF Multi-Area Adjacency
Extracted elements (17)
Each multi-area adjacency is announced as a point-to-point link (type 1 Router LSA) in the configured area, but no type 3 link is advertised for it. The primary adjacency continues to operate per RFC 2328, preserving backward compatibility.
The motivation for multi-area adjacency is to allow a high-speed link between ABRs to be preferred as an intra-area path in multiple areas. Without this extension, OSPF always prefers intra-area paths, so traffic is routed over lower-speed links rather than the backbone link that physically connects two areas.
Using secondary addresses to place a link in multiple areas requires extra IP configuration, does not apply to unnumbered interfaces, and inflates the routing table. Configuring a single-address link in multiple areas would violate the OSPF definition of an area as a collection of subnets. The proposed solution avoids both problems.
All mechanisms described in this document are backward compatible with standard OSPF implementations. A router at the far end of a multi-area adjacency need only model the adjacency as a point-to-point link; however, symmetric configuration of both neighbors as multi-area adjacencies simplifies topology representation and troubleshooting.
If there is a match for both a virtual link and a multi-area adjacency for the same Area ID, this is a configuration error that should be handled at the configuration level.
The multi-area adjacency mechanisms defined here also apply to OSPFv3. A multi-area adjacency is advertised as a point-to-point link in the router-LSA, but the type 3 link change from Section 2.7 does not apply to OSPFv3 because OSPFv3 router-LSA links are independent of addressing semantics. No prefixes for the multi-area adjacency are advertised in the intra-area-prefix-LSA.
A link-LSA SHOULD NOT be advertised for a multi-area adjacency in OSPFv3. The neighbor's IPv6 link-local address can instead be learned from the IPv6 header of Hello packets received over the multi-area adjacency.
For point-to-point interfaces, no neighbor address configuration is needed for multi-area adjacencies since only one neighbor exists. For all other network types, the neighbor address must be configured or automatically discovered via a mechanism external to OSPF.
On point-to-point interfaces, OSPF control packets for multi-area adjacencies are sent to the AllSPFRouters address. For all other network types, OSPF control packets are unicast to the remote neighbor's IP address.
Once a multi-area adjacency reaches the FULL state, it is advertised as a link type 1 (point-to-point) in the Router LSA with Link ID set to the remote router's Router ID and Link Data set to the neighbor's IP address or IfIndex for unnumbered interfaces.
The Area ID in a received OSPF packet header must either match the receiving interface's Area ID (single-hop case), indicate a non-backbone area matching a configured multi-area adjacency, or indicate the backbone (virtual link or multi-area adjacency). If none of these cases match, the packet should be discarded.
Unlike numbered point-to-point links, no type 3 link (stub network) is advertised for multi-area adjacencies in the Router LSA.
An OSPF interface data structure is built for each configured multi-area adjacency per Section 9 of RFC 2328. The interface type is always point-to-point, regardless of the underlying physical link type.
The packet reception logic in Section 8.2 of RFC 2328 is extended so that an OSPF packet is accepted if the Area ID in the header matches the configured area for a multi-area adjacency. The packet is then associated with that multi-area adjacency for further processing.
This document does not raise any security issues beyond those already covered in RFC 2328 (OSPF) or RFC 2740 (OSPFv3). All existing OSPF security mechanisms apply to multi-area adjacencies.
Both the neighbor data structure and neighbor FSM for multi-area adjacencies are the same as for standard OSPF as specified in Section 10 of RFC 2328. No changes to neighbor state transitions are introduced.
The interface FSM for a multi-area adjacency is identical to that of a point-to-point link irrespective of the underlying physical link. States and transitions follow the standard OSPF point-to-point interface FSM.