Network Working Group P. Murphy Internet Draft US Geological Survey Expiration Date:
December 1998 July 1998February 2000 August 2000 File name: draft-ietf-ospf-mlinks-00.txtdraft-ietf-ospf-mlinks-01.txt Unnumbered OSPF Multiple Area Links Status of this Memo This document is an Internet-Draft.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". To learn the current statusprogress." The list of any Internet-Draft, please check the "1id- abstracts.txt" listing contained in thecurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).can be accessed at http://www.ietf.org/shadow.html. Table Of Contents 1.0 Abstract ................................................. 1 2.0 Overview ................................................. 2 2.1 Requirement for Unnumbered 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 Implementation Details ................................... 6Secondary Interfaces ..................................... 5 3.1 The SecondaryAreas Interface parameter ....................... 6................... 5 3.2 AdvertisingThe Secondary Areas ..............................Interface Data Structure ................... 6 3.3 FormingThe Secondary Adjacencies ............................ 7Interface State Machine .................... 6 3.4 Advertising Secondary Adjacencies ........................OSPF Protocol Packet Processing .......................... 7 3.5 Secondary Area Link State Data Base ExchangeDesignated Router Selection and Update ..Function ................. 7 4.0 Synchronizing Secondary Areas Using Mlink Type-9 LSAs .... 8 3.65.0 Secondary Neighbors ...................................... 9 5.1 The Secondary Neighbor Data Structure .................... 9 5.2 The Secondary Neighbor State Machine ..................... 10 5.3 Events Triggered by the Primary Neighbor State Machine.... 11 5.4 Receiving Hello Packets .................................. 11 5.5 Receiving Mlink Type-9 Neighbor Discover LSAs ............ 12 6.0 Advertising Secondary Adjacencies ........................ 13 7.0 The Shortest Path First Calculation ...................... 9 3.714 8.0 Flushing Secondary Adjacencies ........................... 9 4.014 9.0 Security Considerations .................................. 15 10.0 Acknowledgments .......................................... 10 5.015 11.0 References ............................................... 10 6.0 Security Considerations .................................. 10 7.015 12.0 Authors' Addresses ....................................... 1015 Appendix A: Router LSAs ...................................... 11Router-LSAs ........................................ 16 Appendix B: mlink OpaqueMlink Type-9 Neighbor Discover LSAs ................................ 13................ 20 Appendix C: Configuration Parameters ......................... 14........................... 23 1.0 Abstract This memo describes an option to the OSPF Version 2 specification which allows multiple areas to share the same link. This option adds no additional link state flooding over shared links other than the normal link state database exchangeOSPF interface and update originating from the link'slinks. One area is always configured as an interface's primary area. The interface's remaining areas are termed secondary and view it as unnumbered. Two border routers adjacent across the same secondary area may forward the area's intra-area traffic across its secondary links. This option applies to standard areas, stub areas, and NSSAreas.NSSAs. It eliminates the excess Area 0 link state baggage that accompanies the use of virtual links as currently practiced when configuring similar transits for standardworks over any OSPF areas.interface. Routers with this option configured are backward compatible with routers running the standard OSPF Version 2 compliant implementation as defined in RFC 2328, and can be restricted2328. Please send comments to a subset of the OSPF routing domain. This option is applied only on OSPF border routers. Implementation of OSPF multiple area links requires a modification to the OSPF interface data structure which allows each interface of a border router to be connected to multiple areas. One area is always configured as the interface's primary area. Any additional areas which are configured for an interface are called the interface's secondary areas. Two adjacent border routers with mutually shared secondary areas may transit a secondary area's intra-area traffic over the adjacency. A typical application is a stub area or NSSArea which is dual homed to the Area 0 backbone and loosely joined by an internal slow speed link. If there exists a high speed Area 0 link between two of the stub area's border routers, this option allows the stub area's intra-area traffic to route across this high speed area 0 link. The current specification forces traffic to prefer the intra- area path over the slow speed link. Another not so common application makes Area 0 the secondary area over a local high speed LAN link with the primary area a local stub or NSSArea. Here Area 0 is not primary due to topological limitations which restrict its applicability. E.g. the local LAN link could be a campus backbone with dozens of routers on it, all part of the same NSSArea. Please send comments to email@example.com. 2.0 Overview 2.1 Requirement firstname.lastname@example.org. 2.0 Overview 2.1 Requirement for Unnumbered OSPF Multiple Area Links Large corporate networks in todaystoday's modern Internet investhave tremendous human and equipment resources,resources coupled with sizable budget, intobudget invested in their backbone infrastructure. Their regional networks are normally not so fortunate,fortunate and must multi-home to the backbone in order to take advantage of the backbone's high speedfaster and high reliabilitymore reliable network links. Performance over a T1 link can pale by comparison to performance over a DS3 or OC3 backbone link. Indeed, even a high speed 100 megabit LAN link can carry an order of magnitude more traffic than a standard 10 megabit link.Large corporate networks have sizable backbone routing tables and routinely use stub areas and NSSAreas.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) | | |NSSArea|NSSA 1 link NSSAreaNSSA 1 link| | T1 (28) T1 (28) | | | | | A1---------NSSAreaA1-----------NSSA 1 link-----------B1-------M1 T1link------------B1-------M1 512k (56) (2) where A0 and B0 are border routers attached to NSSAreaNSSA 1. A1 and B1 are internal routers in NSSAreaNSSA 1. N1 and M1 are standard ethernet networks in NSSAreaNSSA 1 which are directly attached to B0 and B1 respectively. Assume all T1 links have an OSPF cost of 28 in both directions, N1 and M1 are attached with interface costs 2.The DS3 link has an OSPFcost of 1.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 58,of 86, even though there exists a more preferred path through B0 namely A0<->B0<->B1<->M1 with an OSPF cost of 31. IndeedIn addition the DS3 linkNSSA 1 OSPF preferred path between A0A1 and B0 has the potential of making the performance between A0 and B1 approach that of a single T1. Consider also the NSSArea 1 OSPF preferred path between A1 and N1,N1 is A1<->B1<->B0<->N1, with an OSPF cost 58. Againof 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 31. This link also has the potentialof performing at single hop T1 speeds.31. Under the current OSPF specification NSSAreaNSSA 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 in NSSAreainside NSSA 1. Virtual links areA common practice is to use multiple interface subnets. However this is not an option since virtual links don't workwhen 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 NSSAreas. Ifmulti-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. These tools also burden the physical link with the simultaneous database exchange of multiple OSPF interfaces during adjacency formation. The Unnumbered 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. Furthermore it prioritizes database exchange, giving preference to the primary area and Area 0 over other non-backbone secondary areas. If, in the above example, the link between A0 and B0 were part of NSSAreaNSSA 1, path preference would be optimal as the DS3 path would be intra-area for NSSAreaNSSA 1. This cannot be the non- backbone equivalent of an Area 0 virtual link. Excessive use of such a feature would negate the purpose of the Area 0 backbone.2.2 Proposed Solution The Unnumbered OSPF multiple area links provide the capability of allowingMultiple Area Links option lets multiple areas touse the same link/pathlink between two border routers for intra-area traffic. Traffic may originate from inside each of the configured areas, as every router in the configured areas sees the link/pathlink as part of its link state topology. Only areas which are dual homed to Area 0 may take advantage of this option, since any routerRouters with configured unnumbered OSPF multiple directly attached areasarea links must be in Area 0 and it takes at least two such border routers0, although the connection to create aArea 0 may be an unnumbered OSPF multiple area link. The current OSPF specification only allows one area per OSPF interface. Thus, should an Area L dual-home to twoArea 0 via two border routers which are adjacent over another Area K's router<->router link or router<- >networkrouter<->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. ThisThis, coupled with intra-area route preferencepreference, prevents Area L from utilizing Area K's adjacent link.path. 2.2.1 Secondary Adjacencies The softening of this restriction is facilitated by the addition of a new parameter to theinterface data structureconfiguration parameter called SecondaryAreas. The SecondaryAreas interfaceThis parameter is a self-defining structure containingspecifies a list of Area Ids foradditional areas in which thean OSPF interface also belongs, along with their associated OSPF costs.belongs (See Appendix C). The areas listed in this parameter are called the interface's secondary areas, as opposed to the interface's configured Area ID,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 there isa list of neighboring Router Ids which have formedrouter can form OSPF adjacencies forwith the secondary areaprimary area's neighboring routers across the interface's directly attached network or router link. These adjacencies are called secondary adjacencies. Secondary adjacencies are formed duringafter the primary area's link state data base exchange and update as defined in Sections 3.2 and 3.3.has synchronized matching secondary areas with any of its primary neighbors (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 over an interface which is linked to a transit area for a configured virtual link. 2.2.2 Secondary Neighbor Discovery A type 9 OpaqueType-9 opaque LSA is used to exchange/update the interface'sform secondary areasadjacencies over a primary link with adjacent Opaqueopaque capable border routers. Until an opaque type is assigned for this option, itoption experimental opaque type 224 will be simplyused. The option's LSA is referred to as an mlink type 9 opaqueType-9 LSA. A type 9 opaqueType-9 LSA is used for the exchange/update of an interface's secondary areas because the flooding scope of the mlink type 9this opaque LSA needs to be restricted to thoserouters which are directly attached to a common network or router link. Each router will list its configured secondary addresses as defined byA separate mlink Type-9 LSA is originated for each of the primary interface's SecondaryAreas parametersecondary areas. Included in its mlink type 9 opaque LSA. Thea secondary area's mlink type 9 opaqueType-9 LSA is the secondary area's configured optional capabilities, its authentication parameters, plus, if required, its configured Designated Router priority. Mlink Type-9 LSAs are propagated during the exchange/update of the primary area's link state data base exchange and update(LSDB) with its fullyadjacent primary neighbors. If a router A receives an mlink type 9 opaqueType-9 LSA for area L originating from an adjacenta router B during the exchange/update of primary area K's link state data base exchange,LSDB, then router A and Bmay form a secondary adjacency in area L if and only if 1) Area L is listed in the interface's SecondaryArea parameter. 2) Area L is listed in router B's received mlink type 9 opaque LSA. 3) Router A contains a type 1 (router) LSA fromwith router B provided the LSA's optional capabilities and authentication parameters match those configured for the secondary area in Area L's link state data base. If routers Athe SecondaryAreas parameter. See Section 5.2 for details about secondary neighbor adjacency formation. LSDB exchange and B formupdate across a secondary adjacency then the router ID of router B is added to Area L's list of secondary adjacencies for the interface.proceed as defined in [OSPF] Sections 10 and 13. 2.2.3 Advertising Secondary Links Secondary adjacencies are eitheradvertised as point-to-point or point-to- multipoint.multipoint links. Any intervening transit networksnetwork always belongbelongs to the interface's primary area. ThereMoreover, there is no network LSA for a secondary adjacency's intervening transit network in the secondary area. Hence all secondary adjacencies for Area Lmust be advertised in router A's type 1 (router) LSAa router's router-LSA with unnumbered point-to-point type. During the Dykstra SPFshortest path first (SPF) calculation the LSAs for secondary adjacencies look like unnumbered point-to-point links, except on border routers where they originate.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 border routers domay use the IP addresses stored inof neighboring border router LSAsrouters for determining link pathsa destination's next hop across a multi-access secondary adjacency. There is nosecondary link state data base exchange or updateover secondary adjacencies. Instead, these adjacencies rely on the secondary area's base topology (minus the secondary links) for flooding link state information regarding an area's secondary adjacencies. The reasons for not attemptinga secondary link state data base exchange/update are two fold. First,point-to-multipoint or transit network. 2.3 Application Consider now the goal of this documentexample mentioned in Section 2.1 and assume NSSA 1 is to establish a transit for multiple areas overconfigured as a single link without imposing the additional traffic load caused by passing the secondary area's link state database over that link. Second the added complexity of synchronizing multiplesecondary area link state databasesover the link is unnecessary when the primary area is theArea 0 backbone. Shouldlink 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 area partition, trafficlink between the two parts of the partitioned secondary area would still use the secondary adjacent link via OSPF inter-area routing. It is true that routing between the different parts of a secondary area partitioned by a defunct secondary adjacency over an Area 0 link would be based on the inter-area route computation results from processing summary links. Summary-range aggregation may over simplify routing between the different parts of a partitioned area. However this is no different that what exists under the current OSPF base standards. Furthermore, the proper partitioning of a secondary area's assigned address space not only allows the summary-range aggregates to effect proper routing during topological failures, but it also promotes more cost effectiveA0 and efficient routing even when secondary areas are whole. Consider now the example mentionedB0 in Section 2.3 and assume Area 1 is configured as a secondary area overNSSA 1, the Area 0 link between A0 and B0. The NSSAreaNSSA 1 intra-area shortest path firstSPF tree computed by the Dykstra calculation now includes thethis DS3 link between A0 and B0with a cost of 1. Given that all four routers possess link state advertisements for the link between A0 and B0 in NSSArea 1,Thus the path between A0 and M1 is nowthe more preferred path A0<->B0<->B1<->M1 and the path between A1 and N1 is A1<->A0<->B0<->N1 Furthermore, should the link between A1 and B1 fail terminating the NSSArea 1's secondary adjacency between A0 and B0, the path between A0 and M1 would still be A0<->B0<->B1<->M1, asthe summary LSA for M1 originating from B0 forms an inter-areamore preferred path to M1.A1<->A0<->B0<->N1 3.0 Implementation DetailsSecondary Interfaces 3.1 The SecondaryAreas Interface parameterParameter A new configuration parameter called SecondaryAreas ishas been added to the OSPF interface data structure. Implementations must support the manual configuration of this parameter.structure (See Appendix C). The SecondaryAreas interface parameter lists thea set of Areasareas which canmay form unnumbered secondary adjacencies over the interface, complete with their secondary area interface costs. By default a secondary area's interface cost is set to the value ofacross the interface's primary area cost. Only those Areas listed in the SecondaryAreas interface parameter are candidate areas for the interface's secondary adjacencies. Ifinterface. 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. For each secondary area listed in the SecondaryAreas interface parameter, there is a list ofparameter the interface cost, authentication parameters, and Designated Router Ids which have formed secondary adjacenciespriority are also configurable. The SecondaryAreas' interface costs and the Designated Router priorities default to the router overvalues assigned to the primary interface. These Routers Ids should alsoNote that if a virtual link is configured across a transit area which is linked to an interface, then Area 0 may not be listedconfigured in the interface's listSecondaryAreas parameter. 3.2 The Secondary Interface Data Structure An OSPF interface data structure should be built for each of neighboring routers. Ifan OSPF interface's secondary areas. These interface data structures are called secondary interface data structures and are bound to the listprimary interface. The configured primary area of Router Ids is null, then thean OSPF interface has nogenerates its primary interface data structure. Recall [OSPF] Sections 8.2 and 10.5 imply that a point-to-point layer 2 link between two routers may have only one OSPF interface per area. Additional areas may be added as secondary adjacenciesareas, but they must not duplicate areas already configured for thisthe layer 2 link. A secondary area. Thisinterface's list of neighboring routers is populatedgenerated by examining the primary interface's received mlink Type-9 LSAs as defined in Section 3.34.0 below. 3.2 Advertising Secondary Areas All routers which support secondary areas must alsoBefore a neighboring router may be opaque capable. Ifadded to the interface issecondary interface's list of broadcast type, then all candidate designatedneighboring routers it must be opaque capable, even if they have no secondary areas configured foralso occur in the primary interface's list of neighboring routers. Secondary interfaces copy their interface which connects to the broadcast transit network. Otherwisetype 9 opaque LSAs, which are used by this option, willfrom the primary interface's data structure and still compute a Designated Router and a Backup Designated Router over broadcast and NBMA networks. This promotes efficient flooding across a primary interface's transit network. However, these network links are always advertised as unnumbered router<->router links and behave exactly like point-to- multipoint interfaces. As such a secondary link's Designated Router 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. However in some cases state transitions are triggered by the primary interface's state machine. The InterfaceUp event is redefined for secondary links: InterfaceUp This event is triggered by the primary interface when it transitions to either Point-to-point, DR Other, DR, or Backup state. Its effect on the secondary interface's state is similar to the effect the InterfaceUp event has on the primary interface's state with one exception. The periodic sending of Hello packets is suppressed for a secondary interface. If the primary interface network is a physical point-to-point or point-to-multipoint network, then the secondary interface transitions to Point-to- point state. Else if the router is not eligible to become the Designated Router, the interface state transitions to DR Other. Otherwise the attached primary network is a broadcast or NBMA network and the router is eligible to become a Designated Router for the secondary area. In this case, an attempt is made to discover the attached network's Designated Router for the secondary area. The interface state is set to Waiting and the single shot Wait Timer is started. The events BackupSeen and NeighborChange for a secondary interface are triggered during the processing of the primary interface's received mlink Type-9 LSAs in very much the same way these events are triggered for a standard OSPF interface during the processing of received Hello Packets (See Section 5.5). The events InterfaceDown, LoopInd, UnloopInd, and Wait Timer are unchanged for secondary interfaces. Note 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. 3.4 OSPF Protocol Packet processing Since secondary interfaces are unnumbered interfaces, OSPF protocol packet processing needs a minor adjustment. For point-to-point networks there are no changes. 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). 3.5 Designated Router Selection and Function The election of the Designated Router and the Backup Designated router for a secondary link over a broadcast or NBMA network proceeds as described in [OSPF] Section 9.4. Eligibility is determined from the Designated Router priorities defined in the SecondaryAreas parameter and the received mlink Type-9 LSAs, as well as its neighbors' views of the Designated Router and the Backup Designated Router for the secondary link, which is also found in the received mlink Type-9 LSAs. Any change in the calculating router's Designated Router or Backup Designated Router for a secondary link will result in the reorigination of the corresponding secondary area's mlink Type-9 LSA. Note that the Designated Router for a secondary link does not originate a network-LSA (Type-2) into its secondary area for the broadcast or NBMA network over which the secondary link bridges. All secondary links remain unnumbered point-to-point or point-to- multipoint (see Section 6.0). The only function of a secondary link's Designated Router is flooding optimization. 4.0 Synchronizing Secondary Areas using Mlink Type-9 LSAs Mlink Type-9 LSAs are used to discover and maintain secondary neighbor relationships and to elect the Designated Router and Backup Designated Router for multi-access secondary adjacencies. 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 unnumbered 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 unnumbered 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 an mlink Type-9 LSA for each configured secondary area. If an interface's SecondaryAreas parameter is null, then no mlink Type-9 LSAs should be advertised. A secondary area's mlink Type-9 LSA minimally lists as opaque information the area's secondary area ID, its optional capabilities, its authentication parameters, and, if required, its Designated Router priority. In addition, to ensure proper secondary neighbor state transition, a secondary area's mlink Type-9 LSA also lists as opaque information those primary neighbors from which an mlink Type-9 LSA has been received for this area with matching optional capabilities and authentication parameters (See Section 5.5). Any change in this list will result in the reorigination of a new instance of the secondary area's mlink Type-9 LSA. Also for broadcast and NBMA networks the mlink Type-9 LSA lists the router's current choice for the area's Designated Router and Backup Designated Router. A value of 0.0.0.0 in these fields means that one has not yet been selected. Unlike Hello Packets, a new instance of a secondary area's mlink Type-9 LSA is only originated when the LSA's opaque information content has changed or when the LSRefreshInterval has expired. The LSA's content may change during the processing of received Hellos and received mlink Type-9 LSAs, or when an mlink Type-9 LSA ages out or when the primary interface parameters of a secondary area are reconfigured. A new mlink Type-9 LSA is reoriginated following expiration of its LSRefreshInterval or when changes occur in its secondary area's interface cost, authentication parameters, router priority, Designated Router, Backup Designated Router, or the area's list of secondary neighbors at state greater than Init. Like other LSAs, the reorigination of a mlink Type-9 LSA is subject to the MinLSInterval. New mlink Type-9 LSAs are built from the list of configured secondary areas plus their corresponding secondary interface state machines and secondary neighbor state machines. 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 below). Unless discussed below details for the creation and maintenance of secondary neighbors and secondary adjacencies are the same as discussed in [OSPF] Sections 9 and 10. 5.1 The Secondary Neighbor Data Structure The neighbor data structure for secondary adjacencies is identical to the neighbor data structure for standard OSPF adjacencies. Secondary neighbors are discovered by comparing the contents of the primary interface's received mlink Type-9 LSAs with its configured list of secondary areas and then comparing the secondary areas' configured optional capabilities (see Section 5.5) with those listed for them in the neighboring router's mlink Type-9 LSAs. A separate neighbor data structure is built for each matching secondary area. The Inactivity Timer used for a primary neighbor data structure is synchronized with the Inactivity Timer for all of its configured secondary neighbor data structures. The secondary link's Designated Router and the Backup Designated Router, as viewed by a secondary neighbor, are specified as opaque information stored in the neighbor's corresponding mlink Type-9 LSA and received over the primary interface. Also included are the neighbor's Designated Router priority for the secondary link, its optional capabilities, and a list of secondary neighbors it sees over the secondary link. The secondary Neighbor ID and Neighbor IP address are copied from the corresponding primary area neighbor data structure. The OSPF optional capabilities which are supported by the neighboring router for the secondary area are learned from opaque information stored in the neighbor's mlink Type-9 LSA for this area and must match the local router's optional capabilities configured for the secondary area. 5.2 The Secondary Neighbor State Machine While secondary neighbor states are identical to OSPF's neighbor states, there are some important distinctions in their actions and the events which trigger them. Every router which is a secondary neighbor for a secondary interface is also a primary neighbor for its primary interface. The two neighbor data structures are loosely bound together so that events which happen to the primary neighbor may trigger events for the secondary neighbor. A secondary neighbor's Init, 1-way, and 2-way state transitions are controlled by the reception across the primary interface of Hello Packets and mlink Type-9 LSAs (See Sections 5.4 and 5.5). The combination of the two eliminates the requirement for the periodic sending of Hello Packets for each secondary interface. When a primary neighbor state machine receives a new mlink Type-9 LSA from a primary neighbor via link state update, or confirms the status of an existing one during database exchange, the LSA's content may create a new secondary neighbor or effect the state of an existing secondary neighbor. A router must clear its own mlink Type-9 LSAs from the database summary list during database exchange with its primary neighbors to enable its secondary neighbors to transition past Init state. Any existing mlink Type-9 LSAs previously received from other primary neighbors must be cleared from the database summary list during a primary neighbor's database exchange before their content can create new secondary neighbors or change the state of existing secondary neighbors. If an mlink Type-9 LSA of a primary neighbor ages out, the KillNbr event is executed for the primary neighbor's corresponding secondary adjacency, and the LSA should be flushed. A newly received mlink Type-9 LSA from a primary neighbor may effect the creation of a new secondary adjacency for the neighbor. It may also cause the corresponding secondary neighbor to drop to 2-Way state or lower or be destroyed altogether. (See Section 5.5) A secondary neighbor state machine never enters Attempt state for a NBMA secondary interface. Instead it relies solely on its corresponding primary neighbor state machine to start communications over an NBMA. Hence there is no Start event for a secondary neighbor state machine (See Section 5.4). 5.3 Events Triggered by the Primary Neighbor State Machine When a primary neighbor state machine transitions down to ExStart due to either a SeqNumberMismatch or BadLSReq event, it triggers a 1- WayReceived Event for any secondary neighbors at state 2-way or greater. The events KillNbr, LLDown, and Inactivity Timer of a primary neighbor state machine simultaneously trigger the same events for its loosely bound secondary neighbor state machines. Since the formation of secondary neighbors is linked with the database exchange and the link state update of the mlink Type-9 LSAs received from their loosely bound primary neighbors, 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 allowing an Area 0 secondary neighbor state machine to proceed to Full state roughly in parallel with the primary neighbor state machine. 5.4 Receiving Hello Packets If a Hello Packet is received from one of the interface's existing primary neighbors which has loosely bound secondary neighbors then the corresponding secondary neighbor state machines are executed in line as follows: o Each Hello Packet causes each of the neighbor's existing secondary neighbor state machines at state greater than Down to be executed with the event HelloReceived. o Then the list of neighbors contained in the Hello Packet is examined. If the router itself does not propagateappear in this list, then each of the neighbor's existing secondary neighbor state machines at state greater than Init should be executed with the event 1- WayReceived. Hello packets do not cause secondary neighbor structures to all potential routers capablebe created and do not effect the election of formingDesignated Routers and Backup Designated Routers by the secondary interface state machines. That is triggered by the processing of the primary interface's received mlink Type-9 LSAs. All primary neighbors are considered secondary neighbors for each configured secondary area. They transition from Down to Init state with their corresponding primary neighbors and freeze at Init state until the creation of their secondary neighbor data structures is triggered when the primary interface receives their mlink Type-9 LSAs. (See Section 5.5) 5.5 Receiving Mlink Type-9 Neighbor Discovery LSAs This section explains the detailed processing of a received mlink type-9 LSA. 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 and its optional capabilities or authentication parameters no longer match those stored in the SecondaryAreas parameter, then execute a KillNbr event for any existing corresponding secondary neighbor state machine belonging to this neighbor and terminate processing of this LSA. Else check for the existence of a secondary neighbor state machine for the Secondary Area ID that corresponds to the originating primary neighbor. If one does not exist, create one. Initialize its state to Init and copy the Neighbor ID, the Inactivity Timer, and the Neighbor IP address from the corresponding primary neighbor state machine. When the received mlink Type-9 LSA originated from a primary neighbor over a broadcast, point-to-multipoint or NBMA network set the corresponding secondary adjacencies overneighbor data structure's Router Priority field, Neighbor's Designated Router field, and the broadcast transit network. Note that candidate designated routers do not have to support OSPF multiple area links, but they do have to be opaque capableNeighbor's Backup Designated Router field from the corresponding fields in order to floodthe type 9LSA's opaque data. Changes in these fields should be noted for possible use in the steps below. Now the rest of the mlink Type-9 LSA is examined generating events to their adjacent neighbors who maybe given to the corresponding secondary neighbor and secondary interface state machines. These state machines are specified either to be executed or scheduled (see [OSPF] Section 4.4). For example, by specifying below that the secondary neighbor state machine be executed in line, several neighbor state transitions may not support OSPF multiple area links. Any router which has an interface with a non-empty SecondaryAreas interface parameter must advertisebe effected by a type 9 opaque LSA with opaque typesingle received mlink to the interface's fully adjacent neighbors.Type-9 LSA: o The mlink type 9list of secondary neighbors contained in the LSA's opaque LSA containsdata is examined. If the Area Ids listedrouter itself appears in this list, then the interface's SecondaryAreas parameter as Opaque Information. See Appendix Bcorresponding secondary neighbor state machine for details. If an interface's SecondaryAreas parameter is null, thenthis neighbor should be executed with the mlink type 9 opaque LSAevent 2-WayReceived. Otherwise, the secondary neighbor state machine should notbe advertised. By default,executed with the mlink opaque type sets it opaque ID toevent 1-WayReceived, and the last 24 bitsprocessing of the interface's IP address,LSA stops. o Next, if it has one. Ina change in the case of unnumbered point-to-point connections,neighbor's Secondary Router Priority field in the LSA was noted, the corresponding secondary interface state machine is scheduled with the event NeighborChange. o If the neighbor is both declaring itself to be the Designated Router in the LSA (LSA's Designated Router field = Neighbor IP address), and the Backup Designated Router field in the mlinkLSA's opaque IDinformation is setequal to 0.0.0.0, and the last 24 bits ofcorresponding secondary interface is in state Waiting, then schedule the interface's MIB-II [MIB] ifIndex value. All implementations should also supportsecondary interface state machine with the manual configuration of an interface's mlink opaque ID inevent BackupSeen. Otherwise, if the rare instance this default schema resultsneighbor is declaring itself to be the Designated Router in duplication. 3.3 Forming Secondary Adjacencies Two border routers Athe LSA and B in area L may form ait had not previously, or the secondary adjacency across an interface, whose primary areaneighbor is K, undernot declaring itself Designated Router in the following conditions: (a) Routers A and B are fully adjacent acrossLSA where it had previously, then schedule the interface's primary area K or they share a common area K full adjacencysecondary interface state machine with the interface's designated router. (b) Routers A and B see router LSAs (type-1) for each otherevent NeighborChange. o If the secondary neighbor is declaring itself to be the Backup Designated Router in Area L's link state data base. (c) Routers Athe LSA (LSA's Backup Designated Router field = Neighbor IP address) and B have exchanged/updated mlink type 9 opaque LSAs acrossthe interface both of which contain Area L as a candidatecorresponding secondary area. When all three conditions are met, a secondary adjacencyinterface is formed between routers A and B acrossin state Waiting, then schedule the interface's primary area. Theresecondary interface state machine with the event BackupSeen. Otherwise, if the neighbor is no particular ordering of events. Either (a), (b),declaring itself to be the Backup Designated Router in the LSA and it had not previously, or (c) can triggerthe event which formsneighbor is not declaring itself Backup Designated Router where it had previously, the secondary adjacency, providedinterface state machine is scheduled with the other two conditions have already been met. 3.4event NeighborChange. 6.0 Advertising Secondary Adjacencies Border routers advertise their secondary adjacencies in their router LSAsrouter-LSAs as unnumbered point-to-point links even though they may be numbered point-to-point links, point-to-multipoint links, or transitbroadcast or NBMA network links in their associatedthe OSPF interface's primary area. This allows their interconnecting networks to retain a single area identity, thus avoiding the inevitable problems which would occur with duplicate summary links advertisements and aggregation. It also makes configuration and deployment seamless.interconnecting networks to retain a single area identity. As unnumbered point-to-point links, all secondary adjacencies have link type 1. The building of the router LSA isrouter-LSA, as described in [OSPF] Section 12.4.1. For the purpose of building the router LSA, an interface belongs to both its primary area and its secondary areas. With this in mind, no change12.4.1, is required to [OSPF] Section 12.4.1.virtually unchanged. Even though secondary adjacencies are considered unnumbered point- to-point links, for the purpose of defining Link Data in the type 1 (router)router- LSA (see Appendix A) we allow them tothey use the primary interface's IP address. For secondary adjacencies [OSPF] Section 22.214.171.124 is reduced to simply If a neighboring router has formed a secondary adjacency then add a Type 1 link (point-to-point). The Link ID should be set to the Router ID of the neighboring router. If the interface is numbered, the Link Data should specify the IP interface address. For unnumbered point-to-point networks, the Link Data field should specify the interface's MIB-II [MIB] ifIndex value. The cost should be set to the secondary area's cost of the point-to-point interface as defined in the interface's SecondaryAreas parameter. By not adding thetype 3 links noted in [OSPF] Section 12.4.1. secondary adjacencies retain the look and feel of an unnumbered point-to-point links to the remaining routers in the secondary area, even though they may configure their link data with the interface's IP address. 3.5 Secondary Area Link State Data Base Exchange and Update There is no link state data base exchange or update across a secondary adjacency. Only the interface's primary area synchronizes its link state data base with the interface's neighboring routers. Instead, secondary areas rely on their base topology (i.e. the topology without the secondary links), for complete flooding and synchronization of the1 (point-to-point) link state data base throughout the secondary area. If the primary area is the area 0 backbone this is not a problem, since the routing table entries generated by the secondary areas summary links will forward packets when a secondary area's base topology partitions in such a way that its secondary adjacencies are dropped.for this adjacency. Its Link ID should be set to the Router ID of the neighboring router. If the primary areainterface is non-zero, then a simple IP overnumbered, the Link Data should specify the primary interface's IP tunnel may be configured foraddress. For unnumbered point-to-point networks, the secondary acrossLink Data field should specify the physical link. This tunnel will perform link state data base synchronization forinterface's MIB- II [MIB] ifIndex value. The cost should be set to the secondary area acrossarea's cost specified in the interface. The IP tunnel isprimary interface's SecondaryAreas parameter. By not part of this specification, but clearly it is advantageous to any OSPF multiple areaadding the host route type 3 links implementation if tunneling of IP over IP is supported. Note that ifnoted in [OSPF] Section 12.4.1, secondary adjacencies retain the tunnel is suitably configured with a high OSPF cost, it would never be used for forwarding packets other than those required for link state data base exchangelook and update. Moreoverfeel of unnumbered point-to-point links to the tunnel will always exist as long asremaining routers in the secondary adjacency's physicalarea, even though they may configure their link is active. 3.6data with the primary interface's IP address. 7.0 The Shortest Path First Calculation Since secondary links appear in the link state data base of an area as unnumbered 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 routers. However border routers do use the IP addresses stored in their secondary neighbors' type-1 (router) LSAsrouter-LSAs for determining the destinationa destination's next hop across a secondary adjacency when the associated interface connects the destination router via a point-to-multipoint link or transit network link. In this case the outgoing interface is derived directly from the destination router's next hop IP address. 3.7 Flushing Secondary Adjacencies The dropping and flushing of secondary adjacencies from thelink state database of a secondary area is triggered by any of the following events: The secondary area is manually purged from the interface's SecondaryAreas parameter. An adjacent router looses its primary area adjacency. Note that over a multi-access network termination happenswhen a neighboring router ceases to be listed inthe Designated Router's list of neighbors. The secondary area is no longer listed inassociated interface connects to a point-to-multipoint or transit network. In this case the adjacent router's mlink type 9 opaque LSA. The adjacent router's mlink type 9 opaque LSAoutgoing interface is flushedderived directly from the primary area or exceeds MAXAge. The adjacentdestination router's type 1 (router) LSA isnext hop IP address. 8.0 Flushing Secondary Adjacencies Secondary adjacencies are flushed from the link state database of a secondary area or exceeds MAXAge. In other words, the secondary area has partitionedwhen their neighbor states transition down from Full status, just as with the two formerly adjacent routers now in separate parts. When any of these events occur the interface's SecondaryAreas parameter is updated to purge the adjacency.normal OSPF adjacencies. A new router LSArouter-LSA is built for the secondary area and flooded out those interfaces for whichall of the secondary area is primary. Thearea's primary and secondary interfaces. Finally the SPF calculation is doneperformed to reflect the new link state topology. 4.09.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. In addition, thecomments offrom the following individualsindividual are also acknowledged: Derek Yeung Cisco Systems Rob Colton Fore Systems 5.0Acee Lindem IBM 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.  Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994. 6.0 Security Considerations Security issues are not discussed in this memo. 7.012.0 Author's Address Pat Murphy US Geological Survey 345 Middlefield Road, Mail Stop 870 Menlo Park, California 94560 Phone: (650)329-4044 EMail: email@example.com@usgs.gov 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,links to an area, including secondary links, to an areamust be described in a single router-LSA. For details concerning the construction of router-LSAs,router-LSAs see this document's Section 3.66.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 Transitits transit area (V is for virtual link endpoint). 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 forwild). 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.area as well as a separate entry for each fully adjacent secondary neighbor across a broadcast or NBMA network link. Secondary interfaces to broadcast and NBMA networks are considered point-to-multipoint networks. 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. 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 Link ID Identifies the object that this router link connects to. ValueIts 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. Secondary links areaare always type 1 point-to- pointpoint-to-point regardless of the type of their associatedmatching primary area.link. 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. Although secondary links are considered unnumbered point-to-point links, they do evaluate Link Data as if they were numbered whenever their interface has an IP address associated with its primary area. See Section 3.66.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 ). For example, if no additional TOS metrics are given, this field is set to 0. Secondary Areas maydo not use TOS. metric The cost of using this router link. For secondary links the cost is specified in the primary interface's SecondaryAreas parameter. Additional TOS-specific information may also be included, for backward compatibility with previous versions of the OSPF specification (). Within each link, and for each desired TOS, TOSTOS-specific link information may be encoded as follows: TOS IP Type of Service that this metric refers to. The encoding of TOS in OSPF LSAs is described in  Section 12.3. TOS metric TOS-specific metric information. Appendix B. mlink Opaque LSA The mlink Opaque LSA isMlink Type-9 Neighbor Discovery LSAs Mlink Type-9 LSAs are used directly by OSPF to distribute listlists of candidate secondary areas among neighboring routers. Mlink Type-9 LSAs are flooded across the primary interface. The flooding scope of themlink type 9 Opaque LSAType-9 LSAs is link-local, which means mlink Type-9 LSAs are never forwarded beyond the local (sub)network. Section 3.3(sub)network or router link. Sections 4.0 and 5.5 of this document describesdescribe the purpose of thethese mlink Opaque LSAType-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 | Link State9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Secondary Area ID 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .Sec AuType | Sec Options | Sec Rtr Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sec Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sec Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .Designated Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .Backup Designated Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Secondary Area ID nneighbor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Syntax Of The Opaqueof 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. Sec AuType Identifies the authentication procedure to be used. Authentication is discussed in [OSPF] Appendix D of the specification. Consult [OSPF] Appendix D for a list of the currently defined authentication types. Sec Authentication A 64-bit field for use by the authentication scheme. See [OSPF] Appendix D for details. Neighbors Cnt This 16 bit field describes the number of secondary neighbors listed for the Secondary Area ID. If there are no secondary neighbors listed, then Neighbor Cnt should be set to 0. Sec Options The optional capabilities supported by this router for this secondary area, as documented in [OSPF] Section A.2. 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. Designated Router The identity of the Designated Router for a secondary link, in the view of the mlink Opaque LSAoriginating router. The Designated Router is divided into an Opaque Type field (the first 8 bits), which has value mlink, andidentified here by the Opaque ID (the remaining 24 bits). The mlink Opaque IDIP address across the primary link. Its value is set to 0.0.0.0 if there is no Designated Router for the last 24 bitssecondary link. Backup Designated Router The identity of the interface's primary area IP address, if it has one. InBackup Designated Router for a secondary link, in the caseview of unnumbered point-to-point connections,the mlink opaque IDoriginating router. The Backup Designated Router is identified here by its IP address across the primary link. Its value is set to 0.0.0.0 if there is no Backup Designated Router for the last 24 bits of the interface's MIB-II [MIB] ifIndex value. All implementations should also support the manual configurationsecondary link. Secondary Neighbor The Router IDs of an interface'seach router from whom valid mlink opaque ID inType-9 LSAs have been received across the rare instance this default schema results in duplication.primary link for the secondary area with matching optional capabilities and authentication parameters. 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 is to be included in support ofsupports unnumbered OSPF multiple area links. Sections 3.2 and 3.4 describe the application of the parameter. In addition, forThe SecondaryAreas parameter's default setting is null. The SecondaryAreas parameter in a secondary interface data structure is always null. For each secondary area listed in an interface's SecondaryAreas parameter, the secondary link's interface data structurecost, authentication parameters and Designated Router priority must maintain a list ofbe configurable. If the interface cost and Designated Router IDs which have formed secondary adjacenciespriority are not configured they default to their corresponding values for this secondary area.the OSPF primary interface. 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.