Network Working Group P. Murphy Internet Draft US Geological Survey Expiration Date: August 2002 February 2002 File name: draft-ietf-ospf-mlinks-03.txt OSPF Multiple Area Links Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Murphy [Page i]
Internet Draft OSPF Multiple Area Links February 2002 Table Of Contents 1.0 Abstract ................................................. 1 2.0 Overview ................................................. 2 2.1 Requirement for OSPF Multiple Area Links ................. 2 2.2 Proposed Solution ........................................ 3 2.2.1 Secondary Adjacencies .................................... 4 2.2.2 Secondary Neighbor Discovery ............................. 4 2.2.3 Advertising Secondary Links .............................. 5 2.3 Application .............................................. 5 3.0 Secondary Interfaces ..................................... 5 3.1 The SecondaryAreas Interface parameter ................... 5 3.2 The Secondary Interface Data Structure ................... 6 3.3 The Secondary Interface State Machine .................... 6 3.4 OSPF Protocol Packet Processing .......................... 7 3.5 Designated Router Election and Function .................. 7 4.0 Synchronizing Secondary Areas Using Mlink Type 9 LSAs .... 8 5.0 Secondary Neighbors ...................................... 8 5.1 The Secondary Neighbor Data Structure .................... 8 5.2 The Secondary Neighbor State Machine ..................... 9 5.3 Receiving Mlink Type 9 Neighbor Discover LSAs ............ 10 5.4 Receiving Secondary Hello Packets ........................ 11 6.0 Advertising Secondary Adjacencies ........................ 11 7.0 The Shortest Path First Calculation ...................... 11 8.0 Flushing Secondary Adjacencies ........................... 12 9.0 Security Considerations .................................. 12 10.0 Acknowledgments .......................................... 12 11.0 References ............................................... 12 12.0 Authors' Addresses ....................................... 12 Appendix A: Router-LSAs ........................................ 13 Appendix B: Mlink Type 9 Neighbor Discover LSAs ................ 17 Appendix C: Configuration Parameters ........................... 19 1.0 Abstract This memo describes an option to the OSPF Version 2 specification which allows multiple areas to share the same OSPF link. One area is always configured as the link's primary area. The link's remaining areas are termed secondary. Two border routers adjacent across the same secondary area may forward the area's intra-area traffic across the link. This option applies to standard areas, stub areas, and NSSAs. It works over any OSPF interface. Routers with this option configured are backward compatible with routers running the standard OSPF Version 2 compliant implementation as defined in RFC 2328. Please send comments to ospf@discuss.microsoft.com. Murphy [Page 1]
Internet Draft OSPF Multiple Area Links February 2002 2.0 Overview 2.1 Requirement for OSPF Multiple Area Links Large corporate networks in today's modern Internet have tremendous human and equipment resources coupled with sizable budget invested in their backbone infrastructure. Their regional networks are normally not so fortunate and must multi-home to the backbone in order to take advantage of the backbone's faster and more reliable network links. Performance over a T1 link can pale by comparison to performance over a DS3 or OC3 backbone link. Large corporate networks have sizable backbone routing tables and routinely use stub areas and NSSAs. Under the current OSPF specification intra-area routes are always preferred over inter-area routes even when the traffic is sourced from and destined to the same non-backbone OSPF area. Consider the following typical OSPF example: A0-----------Area 0 link------------B0-------N1 | DS3 (1) | (2) | | |NSSA 1 link NSSA 1 link| | T1 (28) T1 (28) | | | | | A1-----------NSSA 1 link------------B1-------M1 512k (56) (2) where A0 and B0 are border routers attached to NSSA 1. A1 and B1 are internal routers in NSSA 1. N1 and M1 are standard ethernet networks in NSSA 1 which are directly attached to B0 and B1 respectively. The cost of each link is shown in parentheses. All OSPF costs are symmetric. Under the current OSPF specification the preferred path between A0 and M1 is A0<->A1<->B1<->M1 with an OSPF cost of 86, even though there exists a more preferred path through B0 namely A0<->B0<->B1<->M1 with an OSPF cost of 31. In addition the NSSA 1 OSPF preferred path between A1 and N1 is A1<->B1<->B0<->N1, Murphy [Page 2]
Internet Draft OSPF Multiple Area Links February 2002 with an OSPF cost of 86, even though there exists a more preferred path through the link between A0 and B0, namely A1<->A0<->B0<->N1 with an OSPF cost of 31. Under the current OSPF specification NSSA 1's router A1 does not even see this path to N1 since it has no knowledge of Area 0's topology. A0, on the other hand, would at lease see the summary LSA of N1, but still cannot take advantage of it due to OSPF intra-area path preference. What is needed is a tool which makes the Area 0 link between A0 and B0 visible inside NSSA 1. A common practice is to use multiple interface subnets. However this is not an option when the path between A0 and B0 is unnumbered or when one desires that the NSSA 1 path between A0 and B0 be unnumbered. Moreover when configuring multiple interface subnets over multi-access networks, inverse-arp limitations come into play and additional layer 2 PVCs may be required, imposing potential resource and budgetary ramifications. The existing tools for the multiple area usage of the same physical link are awkward to configure, implementation dependent, unnecessarily complex and unwieldy to maintain. If, in the above example, the link between A0 and B0 were part of NSSA 1, path preference would be optimal as the DS3 path would be intra-area for NSSA 1. 2.2 Proposed Solution The OSPF Multiple Area Links option is a simpler tool for configuring multiple area links, requiring just a simple list of the areas sharing an OSPF link. Once configured it lets multiple areas use the same link between two border routers for each area's intra-area traffic. Traffic may originate from inside each of the configured areas, as every router in the configured areas sees the link as part of its link state topology. Routers with configured OSPF Multiple Area Links must be in Area 0, although the connection to Area 0 may be one of the areas listed as sharing the link. The current OSPF specification only allows one area per OSPF interface. Thus, should an Area L dual-home to Area 0 via two border routers which are adjacent over another Area K's router<->router link or router<->network link, the adjacent link over Area K is not seen inside Area L, even though the two border routers exist physically adjacent within Area L. This, coupled with intra-area route preference, prevents Area L from utilizing Area K's adjacent path. Murphy [Page 3]
Internet Draft OSPF Multiple Area Links February 2002 2.2.1 Secondary Adjacencies The softening of this restriction is facilitated by the addition of a new interface configuration parameter called SecondaryAreas. This parameter specifies a list of additional areas which share the OSPF link (See Appendix C). The areas listed in this parameter are called the interface's secondary areas, as opposed to the interface's configured area, hereafter called the primary area. A separate interface data structure is generated for each of the secondary areas. For each secondary area listed in the SecondaryAreas parameter a router can form OSPF adjacencies across the interface's directly attached network or router link. These adjacencies are called secondary adjacencies. Secondary adjacencies are formed after the primary area's link state data base exchange has synchronized matching secondary areas through the flooding path with the link's other directly connected routers. (See Section 4.0). Link state database exchange occurs across a secondary adjacency along with normal flooding. Note that a secondary adjacency for area 0 may not be configured for an interface which is linked to a transit area for a configured virtual link (See Section 3.4). 2.2.2 Secondary Neighbor Discovery A Type 9 opaque LSA is used to form secondary adjacencies over a primary link with adjacent opaque capable border routers. Until an opaque type is assigned for this option, experimental opaque type 224 will be used. The option's LSA is referred to as an mlink Type 9 LSA. A Type 9 LSA is used for the exchange/update of an interface's secondary areas because the flooding scope of this opaque LSA needs to be restricted to routers which are directly attached to a common network or router link. A separate mlink Type 9 LSA is originated for each of the primary interface's secondary areas. If required, included in a secondary area's mlink Type 9 LSA is the secondary area's configured Designated Router priority. Mlink Type 9 LSAs are propagated during the exchange/update of the primary area's link state data base (LSDB) with its adjacent primary neighbors. If a router A receives an mlink Type 9 LSA for area L originating from a router B during the exchange/update of primary area K's LSDB, then router A may form a secondary adjacency in area L with router B. See Section 5.2 for details about secondary neighbor adjacency formation. LSDB exchange and update across a secondary adjacency proceed as defined in [OSPF] Sections 10 and 13. Murphy [Page 4]
Internet Draft OSPF Multiple Area Links February 2002 2.2.3 Advertising Secondary Links Secondary adjacencies are advertised as point-to-point links. Any intervening transit network or stub network assigned to the primary interface always belongs to the interface's primary area. There is no network LSA for this intervening transit network in any of the interface's secondary areas. All secondary adjacencies must be advertised in a router-LSA with point-to-point type. During the Dykstra shortest path first (SPF) calculation the LSAs for secondary adjacencies look like point-to-point links. A border router never includes in a secondary area's SPF tree any network across which one of its secondary adjacencies span. This ensures synchronization of the SPF tree amongst the secondary area's routers. However, since border routers share the link's addressing, they may use the IP addresses of their secondary neighbors for determining a destination's next hop across a secondary link over a point-to- multipoint or transit network. 2.3 Application Consider now the example mentioned in Section 2.1 and assume NSSA 1 is configured as a secondary area over the Area 0 link between A0 and B0. Since the routers A0, A1, B0, and B1 possess NSSA 1's router-LSAs originating from A0 and B0 which define a secondary link between A0 and B0 in NSSA 1, the NSSA 1 intra-area SPF tree computed by the Dykstra calculation now includes this DS3 link with a cost of 1. Thus the preferred path between A0 and M1 is A0<->B0<->B1<->M1 and the preferred path between A1 and N1 A1<->A0<->B0<->N1 3.0 Secondary Interfaces 3.1 The SecondaryAreas Interface Parameter A new configuration parameter called SecondaryAreas has been added to the OSPF interface data structure (See Appendix C). The SecondaryAreas interface parameter lists a set of areas which may form secondary adjacencies across the interface. If the SecondaryAreas interface parameter has a null list, then no secondary areas are configured for this interface and no secondary adjacencies can be formed over the interface. Each area listed in the SecondaryAreas interface parameter should Murphy [Page 5]
Internet Draft OSPF Multiple Area Links February 2002 have a secondary interface data structure. With the exception of Area ID all of secondary interface parameters which are usually configurable, such as interface cost, authentication parameters and Designated Router priority, default to the values assigned to the primary interface. Furthermore, except for the Area ID, IP interface address and mask, all configurable interface parameters should be separately configurable for each secondary interface. Note that if a virtual link is configured across a transit area which is linked to an interface, then Area 0 may not be configured in the interface's SecondaryAreas parameter. 3.2 The Secondary Interface Data Structure An OSPF interface data structure should be built for each of an OSPF interface's secondary areas. These interface data structures are called secondary interface data structures and are loosely bound to the primary interface. The configured primary area of an OSPF interface generates its primary interface data structure. A point- to-point layer 2 link between two routers may have only one OSPF interface per area (See [OSPF] Sections 8.2 and 10.5). Additional areas may be added as secondary areas, but they must not duplicate areas already configured for the layer 2 link. A secondary interface's list of neighboring routers is generated by examining the primary interface's received mlink Type 9 LSAs as defined in Section 4.0 below. With the exception of broadcast networks, secondary interfaces copy their interface type from the primary interface's data structure. If the primary interface's network has broadcast type then the secondary interface's network has NBMA type. Secondary interfaces with NBMA type still compute a Designated Router and a Backup Designated Router. This promotes efficient flooding across the interface's transit network. Note that secondary adjacencies are always advertised as router links even when their network type is NBMA. As such the Designated Router of a secondary NBMA link does not originate a type-2 network LSA into the secondary area for the primary interface's transit network. 3.3 The Secondary Interface State Machine The interface states of a secondary interface are the same as the interface states of a primary interface. Secondary neighbors exchange Hello packets, called secondary Hello packets, just like primary neighbors. The processing of received secondary Hellos is practically unchanged (See Section 5.5). The InterfaceUp event for a secondary interfaces is generated by its corresponding primary interface when the primary interface transitions to either Point-to-point, DR Other, DR, or Backup state. In addition to those actions described in [OSPF] Murphy [Page 6]
Internet Draft OSPF Multiple Area Links February 2002 Section 9.3, when the InterfaceUp event is generated for secondary interfaces, the neighbor Start event is generated for each existing secondary neighbor. The remainder of the interface state machine is virtually unchanged for secondary interfaces. Those protocols which generate the events InterfaceDown, LoopInd, UnloopInd for the primary interface should generate the same events for all of the primary interface's corresponding secondary interfaces. The NeighborChange and BackupSeen events are generated through the orderly processing of secondary Hello packets received across the secondary interface as described in [OSPF] Section 10.5 and augmented in Section 5.4. It is notable that since the secondary interface's InterfaceUp event occurs only after the primary interface has transitioned to DR other, DR or Backup state, a secondary interface's Wait Timer will never start before the primary interface's Wait Timer has fired. This produces a more orderly ascension to Full state for secondary NBMA adjacencies. 3.4 OSPF Protocol Packet processing Since a secondary interface shares the ip address of its corresponding primary interface, OSPF protocol packet processing needs a minor adjustment. For broadcast, NBMA, and point-to- multipoint links, the packet's IP source address is required to be on the same network as the receiving OSPF primary interface. This can be verified by comparing the packet's IP source address to the primary interface's source address, after masking both addresses with the interface mask (See [OSPF] Section 8.2). The Area Id is used to distinguish the primary interface from its configured secondary interfaces. Any router with a configured virtual link cannot configure Area 0 in the SecondaryAreas parameters of any interface belonging to the link's transit area. Otherwise the virtual link would not be distinguishable from an Area 0 secondary link. 3.5 Designated Router Election and Function The election of the Designated Router and the Backup Designated router for a secondary link over a secondary NBMA network proceeds as described in [OSPF] Section 9.4. Eligibility is determined from the Designated Router priorities configured for each secondary area as well as the priorities defined in received secondary Hellos from secondary neighbors. Note that the Designated Router for a secondary link does not originate a network-LSA (Type-2) into its secondary area for the secondary NBMA network over which the secondary link bridges. All secondary links are advertised as point-to-point links (see Section 6.0). The only function of a secondary link's Designated Router is flooding optimization. Murphy [Page 7]
Internet Draft OSPF Multiple Area Links February 2002 4.0 Synchronizing Secondary Areas using Mlink Type 9 LSAs Mlink Type 9 LSAs are used to discover and start secondary neighbor relationships. If the primary interface is of broadcast or NBMA type then all of its candidate Designated Routers must be opaque capable, even if these routers have no secondary areas configured for their link to the broadcast or NBMA network. Otherwise mlink Type 9 LSAs may not propagate to all potential routers capable of forming secondary adjacencies over the network. Note that these candidate Designated Routers do not have to support OSPF Multiple Area Links, but they do have to be opaque capable in order to flood mlink Type 9 LSAs to their adjacent primary neighbors who may or may not support OSPF Multiple Area Links. The format of the mlink Type 9 LSA is detailed in Appendix B. Any router which has an interface with a non-empty SecondaryAreas interface parameter must originate across the primary interface an mlink Type 9 LSA for each configured secondary area. If an interface's SecondaryAreas parameter is null, then no mlink Type 9 LSAs will be advertised. A secondary area's mlink Type 9 LSA minimally lists as opaque information the secondary link's Area ID, plus, if available, its IP address and, if required, its Designated Router priority. A new mlink Type 9 LSA is reoriginated following expiration of its LSRefreshInterval or when changes occur in the secondary link's router priority. Mlink Type 9 LSAs are only flooded at the routers fully adjacent primary neighbors. If a secondary area is removed from a primary interface's configured secondary areas, its locally originated mlink Type 9 LSA should be flushed. The mlink Type 9 LSA of each of the primary interface's secondary areas must have a unique opaque ID. The last 24 bits of the Secondary Area ID will normally produce unique Opaque IDs. When it doesn't, alter the least significant bits until uniqueness is achieved. 5.0 Secondary Neighbors An OSPF router converses with its secondary neighbors. Each separate conversation is described by a "secondary neighbor data structure". Conversations between secondary neighbors are bound to the secondary interface and identified by both the Area ID and either the router's OSPF Router ID or its Neighbor IP address (see Section 3.4). Unless discussed below details for the creation and maintenance of secondary neighbors and secondary adjacencies are the same as discussed in [OSPF] Sections 10. 5.1 The Secondary Neighbor Data Structure The neighbor data structure for secondary adjacencies is identical to Murphy [Page 8]
Internet Draft OSPF Multiple Area Links February 2002 the neighbor data structure for standard OSPF adjacencies. Secondary neighbors are discovered by comparing the Area IDs of the primary interface's received mlink Type 9 LSAs with the secondary areas listed in the interface's SecondaryAreas parameter. For point-to- multipoint and transit networks, the originator of the mlink Type 9 LSA should be on the same network as the receiving interface. This can be verified by comparing the mlink Type 9 LSA's IP address field with the IP address of the primary interface, after masking both addresses with the interface mask. For point-to-point and point-to- multipoint secondary network types, a separate neighbor data structure is always built for each new secondary neighbor discovered by a received mlink Type 9 LSA. Since the mlink Type 9 LSA of an NBMA secondary link includes the neighbor's Designated Router priority, its separate secondary neighbor data structure is built only when either the local router or the originating router of the mlink Type 9 LSA is DR eligible (see Section 5.4). The Neighbor ID and the Neighbor IP address of the secondary neighbor's data structure are copied from the Advertising Router field and IP Address fields of the mlink Type 9 LSA. 5.2 The Secondary Neighbor State Machine While secondary neighbor states are identical to OSPF's neighbor states, there are a few important distinctions in their actions and the events which trigger them. When a primary interface receives an new mlink Type 9 LSA from a primary neighbor, the LSA's content may create a new secondary neighbor, destroy an existing secondary neighbor or modify the state of an existing secondary neighbor. For point-to-point and point-to-multipoint secondary network types, a new secondary neighbor is always established. For NBMA secondary network types, the decision whether or not to create a new secondary neighbor depends on whether either the local router or the originating router are DR eligible (See Section 5.3). A router must clear its own mlink Type 9 LSAs from the database summary list of a primary neighbor during database exchange to ensure that its corresponding secondary neighbor relationships transition out of Down state. A secondary neighbor state machine always passes through Attempt state, even for point-to-point and point-to-multipoint secondary interface network types (See Section 5.3 and 5.4). If an mlink Type 9 LSA ages out, the KillNbr event is executed for the corresponding secondary neighbor, and the LSA should be flushed. If the state of the neighbor is 2-way or higher, the local router should send a Hello packet to the secondary neighbor which omits it from the neighbor list (See Section 5.5). The conditions which cause the execution of the KillNbr and LLDown events for primary neighbors should trigger the same events for any of their corresponding secondary neighbors. Murphy [Page 9]
Internet Draft OSPF Multiple Area Links February 2002 Since the formation of secondary neighbors is linked with the database exchange and the link state update of the mlink Type 9 LSAs received across the primary link, the timing of this exchange effects when a secondary neighbor transitions to ExStart state. The mlink Type 9 LSA of a secondary Area 0 should be listed at the top of the database summary list. The mlink Type 9 LSAs of non-backbone secondary areas should be listed at the bottom of the database summary list. These tools mitigate the effect of the database exchange by non-backbone secondary areas on the primary neighbor state machine as it transitions to Full state, while at the same time letting an Area 0 secondary neighbor state machine proceed to Full state roughly in parallel with the primary neighbor state machine. 5.3 Receiving Mlink Type 9 Neighbor Discovery LSAs This section explains the detailed processing of a received mlink Type 9 LSA. Note that any mlink Type 9 LSAs received across a secondary interface are simply ignored. Thus two neighbors which don't agree on the primary area will never form either primary or secondary adjacencies. When an mlink Type 9 LSA is acknowledged during a primary neighbor's database exchange or received via link state update, its Secondary Area ID is checked against those listed in the primary interface's SecondaryAreas parameter. If it is not listed processing of this LSA stops. If it is listed, for point-to-multipoint and transit networks the originator of the mlink Type 9 LSA should be on the same network as the receiving interface. This can be verified by comparing the mlink Type 9 LSA's IP address field with the IP address of the primary interface, after masking both addresses with the interface mask. If a match does not occur processing of this LSA stops. Next check for the existence of a secondary neighbor in the current list of secondary neighbors contained in the corresponding secondary interface data structure. If a matching secondary neighbor data structure cannot be found, (i.e. this is the first time the secondary neighbor has been detected), and if the secondary network type is either point-to-point or point-to-multipoint or the secondary network type is NBMA and either the local router or the originating router is DR eligible across the secondary NBMA, then create a secondary neighbor data structure for the neighbor described in the mlink Type 9. The Neighbor ID and the Neighbor IP address of the secondary neighbor data structure are copied from the Advertising Router and IP Address fields of the mlink Type 9 LSA. The initial state of the newly created secondary neighbor is set to Down. If the secondary network type is point-to-point or point-to-multipoint, or the secondary network type is NBMA and both the local router and the originating router are DR eligible (as defined the secondary neighbor Murphy [Page 10]
Internet Draft OSPF Multiple Area Links February 2002 data structure and the newly received mlink Type 9 LSA) then execute a Start event for the newly created secondary neighbor. 5.4 Receiving Secondary Hello Packets The processing of Secondary Hello Packets proceeds as described in [OSPF] Section 10.5 with just a few exceptions. If a Secondary Hello Packet is received from a non-existent secondary neighbor the processing of the Hello Packet stops and the packet is dropped. Secondary neighbor data structures are created by the processing of received mlink Type 9 LSAs (See Section 5.4). If a Secondary Hello Packet is received with a router priority which does not match that of the mlink Type 9 LSA which created the secondary neighbor, a 1- WayReceived event should be executed. 6.0 Advertising Secondary Adjacencies A Border router advertises its secondary adjacencies in the router- LSAs of its configured secondary areas as point-to-point links even though they may be secondary NBMA links. Any stub or transit networks shared by the primary link with its secondary links are never advertised in the router-LSAs of its secondary areas. This allows these stub and transit networks to retain a single area identity. Noting that a secondary interface does share the IP address of its corresponding primary interface, when adding the secondary link to the router LSA [OSPF] Section 12.4.1.1 is reduced to simply If a neighboring router has formed a secondary adjacency then add a type 1 (point-to-point) link for this adjacency. Its Link ID should be set to the Router ID of the neighboring router. If the corresponding primary interface is numbered, the Link Data should specify the primary interface's IP address. If the primary interface is unnumbered, the Link Data field should specify the interface's MIB-II [MIB] ifIndex value. The cost should be set to the configured output cost of the corresponding secondary interface. 7.0 The Shortest Path First Calculation Since secondary links appear in the link state data base of an area as point-to-point links there is no change required in the Shortest Path First (SPF) calculation, except on those border routers where they are configured. Border routers do not include in a secondary area's SPF tree any network which one of its secondary adjacencies transit. This ensures synchronization of the SPF tree amongst the secondary area's other routers. However border routers do use the IP addresses stored in their secondary neighbors' router-LSAs for determining a destination's next hop across a secondary link when the Murphy [Page 11]
Internet Draft OSPF Multiple Area Links February 2002 associated interface connects to a point-to-multipoint or transit network. In this case the outgoing interface is derived directly from the destination router's next hop IP address. 8.0 Flushing Secondary Adjacencies Secondary adjacencies are flushed from the link state database of a secondary area when their neighbors transition down from Full state, just as with normal OSPF adjacencies. A new router-LSA is built for the secondary area and flooded out all of the secondary area's primary and secondary interfaces. Finally the SPF calculation is performed to reflect the new link state topology. 9.0 Security Considerations Security issues are not discussed in this memo. 10.0 Acknowledgments This document was produced by the OSPF Working Group, chaired by John Moy. Most notably, Acee Lindem, Redback Networks, provided outstanding input which substantially simplified this document from its previous incarnations. 11.0 References [MIB] McCloghrie, K., and M. Rose, "Management Information Base for network management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [OPAQ] Coltun, Rob, "The OSPF Opaque LSA Option", FORE Systems, August 1998. [OSPF] Moy, J., "OSPF Version 2", RFC 2328, Ascend Communications, Inc., April 1998. 12.0 Author's Address Pat Murphy US Geological Survey 345 Middlefield Road, Mail Stop 870 Menlo Park, California 94560 Phone: (650)329-4044 EMail: pmurphy@noc.usgs.net Murphy [Page 12]
Internet Draft OSPF Multiple Area Links February 2002 Appendix A. Router-LSAs Router-LSAs are Type 1 LSAs. Each router in an area originates a router-LSA. The router-LSA describes the state and cost of the router's links (i.e., interfaces) to the area. All of the router's links to an area, including secondary links, must be described in a single router-LSA. For details concerning the construction of router-LSAs see this document's Section 6.0 and [OSPF] Section 12.4.1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |V|E|B| 0 | # links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | # TOS | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS | 0 | TOS metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | In router-LSAs, the Link State ID field is set to the router's OSPF Router ID. Router-LSAs are flooded throughout a single area only. bit V When set, the router is an endpoint of one or more fully adjacent virtual links having the described area as its transit area (V is for virtual link endpoint). Murphy [Page 13]
Internet Draft OSPF Multiple Area Links February 2002 bit E When set, the router is an AS boundary router (E is for external). bit B When set, the router is an area border router (B is for border). bit W When set, the router is a wild-card multicast receiver (W is for wild). bit Nt When set, the router is a NSSA border router which translates type-7 LSAs into type-5 LSAs (Nt is for NSSA translation). # links The number of router links described in this LSA. This must be the total collection of router links (i.e., interfaces) to the area including a separate entry for each fully adjacent secondary neighbor, regardless of its secondary link's network type. The following fields are used to describe each router link (i.e., interface). Each router link is typed (see the below Type field). The Type field indicates the kind of link being described. It may be a link to a transit network, to another router or to a stub network. The values of all the other fields describing a router link depend on the link's Type. For example, each link has an associated 32-bit Link Data field. For links to stub networks this field specifies the network's IP address mask. For other link types the Link Data field specifies the router interface's IP address. Type A quick description of the router link for one of the following. Note that host routes are classified as links to stub networks with network mask of 0xffffffff. Secondary router links are always type 1 point-to-point even when they have secondary NBMA network type. Type Description __________________________________________________ 1 Point-to-point connection to another router 2 Connection to a transit network 3 Connection to a stub network 4 Virtual link Murphy [Page 14]
Internet Draft OSPF Multiple Area Links February 2002 Link ID Identifies the object that this router link connects to. Its value depends on the link's Type. When connecting to an object that also originates an LSA (i.e., another router or a transit network) the Link ID is equal to the neighboring LSA's Link State ID. This provides the key for looking up the neighboring LSA in the link state database during the routing table calculation. See [OSPF] Section 12.2 for more details. Type Link ID ______________________________________ 1 Neighboring router's Router ID 2 IP address of Designated Router 3 IP network/subnet number 4 Neighboring router's Router ID Link Data Value again depends on the link's Type field. For connections to stub networks, Link Data specifies the network's IP address mask. For unnumbered point-to-point connections, it specifies the interface's MIB-II [MIB] ifIndex value. For the other link types it specifies the router interface's IP address. This latter piece of information is needed during the routing table build process, when calculating the IP address of the next hop. Recall a secondary router link (Type 1) shares the IP address of its corresponding primary interface, if it exists. Otherwise it is an unnumbered point-to-point connection. See Section 6.0 of this document and [OSPF] Section 16.1.1 for more details. # TOS The number of different TOS metrics given for this link, not counting the required link metric (referred to as the TOS 0 metric in [1583]). For example, if no additional TOS metrics are given, this field is set to 0. Secondary Areas do not use TOS. metric The cost of using this router link. For secondary links the cost is specified in the secondary interface data structure. Additional TOS-specific information may also be included, for backward compatibility with previous versions of the OSPF specification ([1583]). Within each link, and for each desired TOS, TOS-specific link information may be encoded as follows: Murphy [Page 15]
Internet Draft OSPF Multiple Area Links February 2002 TOS IP Type of Service that this metric refers to. The encoding of TOS in OSPF LSAs is described in [1583] Section 12.3. TOS metric TOS-specific metric information. Murphy [Page 16]
Internet Draft OSPF Multiple Area Links February 2002 Appendix B. Mlink Type 9 Neighbor Discovery LSAs Mlink Type 9 LSAs are used directly by OSPF to distribute lists of candidate secondary areas among neighboring routers. Mlink Type 9 LSAs are flooded across the primary interface. The flooding scope of an mlink Type 9 LSAs is link-local, which means mlink Type 9 LSAs are never flooded beyond the local (sub)network or router link. Sections 4.0 and 5.3 of this document describe the purpose of these mlink Type 9 LSAs in more detail. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Secondary Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sec Rtr Pri | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Syntax of the mlink Type 9 LSA's Link-State ID The link-state ID of an mlink Type 9 LSA is divided into an Opaque Type field (the first 8 bits), which has value mlink, and the Opaque ID (the remaining 24 bits). The mlink Type 9 LSA of each of the primary interface's secondary areas must have a unique opaque ID. The last 24 bits of the Secondary Area ID will normally produce unique Opaque IDs. When it doesn't, alter the least significant bits until uniqueness is achieved. Options The optional capabilities supported by this router for the primary area, as documented in [OSPF] Section A.2. Secondary Area ID The area ID of the area across which a neighboring router may form a secondary adjacency. Murphy [Page 17]
Internet Draft OSPF Multiple Area Links February 2002 IP Address The IP Address of the secondary area's corresponding primary interface. If the primary interface has unnumbered point-to- point type, then IP Address should be set to 0. Sec Rtr Pri This router's Designated Router priority for a secondary link across a transit network. This parameter is used during the secondary links (Backup) Designated Router election. If set to 0, the router will be ineligible to become the (Backup) Designated Router for this secondary link. Murphy [Page 18]
Internet Draft OSPF Multiple Area Links February 2002 Appendix C. Interface Data Structure Chapter 9 in the OSPF specification documents the interface data structure and the data items which are included in it. Section 3.1 of this document defines a new interface configuration parameter called SecondaryAreas which supports OSPF Multiple Area Links. The SecondaryAreas interface parameter lists a set of areas which may form secondary adjacencies across the interface. The SecondaryAreas parameter's default setting is null. If a virtual link is configured across a transit area linked to an interface, then Area 0 may not be configured in the interface's SecondaryAreas parameter. Each area listed in the SecondaryAreas interface parameter should have a secondary interface data structure. With the exception of Area ID all of secondary interface parameters which are usually configurable, such as interface cost, authentication parameters and Designated Router priority, default to the values assigned to the primary interface. Furthermore, except for the Area ID, IP interface address and mask, all configurable interface parameters should be separately configurable for each secondary interface. The SecondaryAreas parameter in a secondary interface data structure is always null. Murphy [Page 19]
