Network Working Group P. Murphy Internet Draft US Geological Survey Expiration Date: August
20012002 February 20012002 File name: draft-ietf-ospf-mlinks-02.txt Unnumbereddraft-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. Table Of Contents 1.0 Abstract ................................................. 1 2.0 Overview ................................................. 2 2.1 Requirement for UnnumberedOSPF 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 SelectionElection and Function ................................... 7 4.0 Synchronizing Secondary Areas Using Mlink Type-9Type 9 LSAs .... 8 5.0 Secondary Neighbors ...................................... 98 5.1 The Secondary Neighbor Data Structure .................... 98 5.2 The Secondary Neighbor State Machine ..................... 109 5.3 Events Triggered by the Primary Neighbor State Machine.... 11 5.4 Receiving Hello Packets .................................. 11 5.5Receiving Mlink Type-9Type 9 Neighbor Discover LSAs ............ 1210 5.4 Receiving Secondary Hello Packets ........................ 11 6.0 Advertising Secondary Adjacencies ........................ 1311 7.0 The Shortest Path First Calculation ...................... 1411 8.0 Flushing Secondary Adjacencies ........................... 1412 9.0 Security Considerations .................................. 1512 10.0 Acknowledgments .......................................... 1512 11.0 References ............................................... 1512 12.0 Authors' Addresses ....................................... 1512 Appendix A: Router-LSAs ........................................ 1613 Appendix B: Mlink Type-9Type 9 Neighbor Discover LSAs ................ 2017 Appendix C: Configuration Parameters ........................... 2319 1.0 Abstract This memo describes an option to the OSPF Version 2 specification which allows multiple areas to share the same OSPF interface and links.link. One area is always configured as an interface'sthe link's primary area. The interface'slink's remaining areas are termed secondary and view it as unnumbered.secondary. Two border routers adjacent across the same secondary area may forward the area's intra-area traffic across its secondary links.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 email@example.com. 2.0 Overview 2.1 Requirement for UnnumberedOSPF 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, 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 requiredrequired, 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 NSSA 1, path preference would be optimal as the DS3 path would be intra-area for NSSA 1. 2.2 Proposed Solution The UnnumberedOSPF 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 unnumberedOSPF multiple area linksMultiple Area Links must be in Area 0, although the connection to Area 0 may be an unnumbered OSPF multiple areaone 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. 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 inwhich anshare the OSPF interface also belongslink (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 with the primary area's neighboring routersacross 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 any of its primary neighborsthe 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 overfor an interface which is linked to a transit area for a configured virtual link.link (See Section 3.4). 2.2.2 Secondary Neighbor Discovery A Type-9Type 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 optionoption, experimental opaque type 224 will be used. The option's LSA is referred to as an mlink Type-9Type 9 LSA. A Type-9Type 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-9Type 9 LSA is originated for each of the primary interface's secondary areas. IncludedIf required, included in a secondary area's mlink Type-9Type 9 LSA is the secondary area's configured optional capabilities, its authentication parameters, plus, if required, its configuredDesignated Router priority. Mlink Type-9Type 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-9Type 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 provided the LSA's optional capabilities and authentication parameters match those configured for the secondary area in the SecondaryAreas parameter.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. 2.2.3 Advertising Secondary Links Secondary adjacencies are advertised as point-to-point or point-to- multipointlinks. Any intervening transit network always belongs toor stub network assigned to the primary interface always belongs to the interface's primary area. Moreover, thereThere is no network LSA for a secondary adjacency'sthis intervening transit network in any of the interface's secondary area. Hence allareas. All secondary adjacencies must be advertised in a router'srouter-LSA with unnumberedpoint-to-point type. During the Dykstra shortest path first (SPF) calculation the LSAs for secondary adjacencies look like unnumberedpoint-to-point links. A Borderborder 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. HoweverHowever, since border routers share the link's addressing, they may use the IP addresses of neighboring routerstheir secondary neighbors for determining a destination's next hop across a secondary link over a point-to-multipointpoint-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 the more preferred pathA0<->B0<->B1<->M1 and the preferred path between A1 and N1 is the more preferred pathA1<->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 unnumberedsecondary 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. For each secondaryEach area listed in the SecondaryAreas interface parameter should have a secondary interface data structure. With the exception of Area ID all of secondary interface cost, authentication parameters, and Designated Router priorityparameters which are also configurable. The SecondaryAreas'usually configurable, such as interface costscost, authentication parameters and theDesignated Router prioritiespriority, 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. Recall [OSPF] Sections 8.2 and 10.5 imply that a point-to-pointA point- to-point layer 2 link between two routers may have only one OSPF interface per area.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-9Type 9 LSAs as defined in Section 4.0 below. Before a neighboring router may be added to the secondary interface's list of neighboring routers it must also occur inWith the primary interface's listexception of neighboring routers. Secondarybroadcast networks, secondary interfaces copy their interface type from the primary interface's data structure andstructure. 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 over broadcast and NBMA networks.Router. This promotes efficient flooding across a primarythe interface's transit network. However, these network linksNote that secondary adjacencies are always advertised as unnumbered router<->routerrouter links and behave exactly like point-to- multipoint interfaces.even when their network type is NBMA. As such a secondary link'sthe 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. However in some cases state transitions are triggered by theSecondary neighbors exchange Hello packets, called secondary Hello packets, just like primary interface's state machine.neighbors. The processing of received secondary Hellos is practically unchanged (See Section 5.5). The InterfaceUp event is redefinedfor a secondary links: InterfaceUp This eventinterfaces is triggeredgenerated by theits corresponding primary interface when itthe primary interface transitions to either Point-to-point, DR Other, DR, or Backup state. Its effect on the secondary interface's state is similarIn addition to the effectthose actions described in [OSPF] Section 9.3, when the InterfaceUp event has on the primary interface's state with one exception. The periodic sending of Hello packetsis suppressedgenerated for asecondary interface. Ifinterfaces, the primary interface networkneighbor Start event is a physical point-to-point or point-to-multipoint network, then thegenerated for each existing secondary interface transitions to Point-to- point state. Else if the router is not eligible to become the Designated Router,neighbor. The remainder of the interface state transitions to DR Other. Otherwise the attached primary network is a broadcast or NBMA network and the routermachine is eligible to become a Designated Routervirtually unchanged for thesecondary area. In this case, an attempt is made to discoverinterfaces. Those protocols which generate the attached network's Designated Routerevents InterfaceDown, LoopInd, UnloopInd for the secondary area. Theprimary interface state is set to Waiting andshould generate the single shot Wait Timer is started. Thesame events BackupSeen and NeighborChangefor a secondary interface are triggered during the processingall of the primary interface's received mlink Type-9 LSAs in very much the same way thesecorresponding secondary interfaces. The NeighborChange and BackupSeen events are triggered for a standard OSPF interface duringgenerated through the orderly processing of receivedsecondary Hello Packets (Seepackets received across the secondary interface as described in [OSPF] Section 5.5). The events InterfaceDown, LoopInd, UnloopInd,10.5 and Wait Timer are unchanged for secondary interfaces. Noteaugmented 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 interfaces are unnumbered interfaces,interface shares the ip address of its corresponding primary interface, OSPF protocol packet processing needs a minor adjustment. For point-to-point networks there are no changes. Forbroadcast, 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 FunctionThe election of the Designated Router andArea Id is used to distinguish the Backup Designated router forprimary 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 broadcast orsecondary 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,configured for each secondary area as well as its neighbors' views of the Designated Router and the Backup Designated Router forthe secondary link, which is also foundpriorities defined in thereceived mlink Type-9 LSAs. Any change in the calculating router's Designated Router or Backup Designated Router for asecondary link will result in the reorigination of the correspondingHellos from secondary area's mlink Type-9 LSA.neighbors. Note that the Designated Router for a secondary link does not originate a network-LSA (Type-2) into its secondary area for the broadcast orsecondary NBMA network over which the secondary link bridges. All secondary links remain unnumberedare advertised as point-to-point or point-to- multipointlinks (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-9Type 9 LSAs Mlink Type-9Type 9 LSAs are used to discover and maintainstart secondary neighbor relationships and to elect the Designated Router and Backup Designated Router for multi-access secondary adjacencies.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-9Type 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 unnumberedOSPF multiple area links,Multiple Area Links, but they do have to be opaque capable in order to flood mlink Type-9Type 9 LSAs to their adjacent primary neighbors who may or may not support unnumberedOSPF multiple area links.Multiple Area Links. The format of the mlink Type-9Type 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-9Type 9 LSA for each configured secondary area. If an interface's SecondaryAreas parameter is null, then no mlink Type-9Type 9 LSAs shouldwill be advertised. A secondary area's mlink Type-9Type 9 LSA minimally lists as opaque information the area'ssecondary arealink's Area ID, plus, if available, its optional capabilities, its authentication parameters,IP address and, if required, its Designated Router priority. In addition, to ensure properA new mlink Type 9 LSA is reoriginated following expiration of its LSRefreshInterval or when changes occur in the secondary neighbor state transition,link's router priority. Mlink Type 9 LSAs are only flooded at the routers fully adjacent primary neighbors. If a secondary area'sarea is removed from a primary interface's configured secondary areas, its locally originated 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-9Type 9 LSA should be flushed. The mlink Type-9Type 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).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 9 and10. 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 contentsArea IDs of the primary interface's received mlink Type-9Type 9 LSAs with its configured list ofthe secondary areas and then comparinglisted in the secondary areas' configured optional capabilities (see Section 5.5) with those listed for them ininterface's SecondaryAreas parameter. For point-to- multipoint and transit networks, the originator of the neighboring router'smlink Type-9 LSAs. AType 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 matching secondary area. The Inactivity Timer used for a primary neighbor data structure is synchronized with the Inactivity Timer for all of its configurednew secondary neighbor data structures. The secondary link's Designated Router and the Backup Designated Router, as vieweddiscovered by a secondary neighbor, are specified as opaque information stored inreceived mlink Type 9 LSA. Since the neighbor's correspondingmlink Type-9Type 9 LSA and received over the primary interface. Also included areof an NBMA secondary link includes the neighbor's Designated Router priority for the secondary link,priority, its optional capabilities, and a list ofseparate secondary neighbors it sees overneighbor data structure is built only when either the secondary link.local router or the originating router of the mlink Type 9 LSA is DR eligible (see Section 5.4). The secondaryNeighbor ID and the Neighbor IP address are copied from the corresponding primary area neighbor data structure. The OSPF optional capabilities which are supported by the neighboring router forof the secondary areaneighbor's data structure are learnedcopied from opaque information stored inthe neighbor's mlink Type-9 LSA for this areaAdvertising Router field and must match the local router's optional capabilities configured forIP Address fields of the secondary area.mlink Type 9 LSA. 5.2 The Secondary Neighbor State Machine While secondary neighbor states are identical to OSPF's neighbor states, there are somea few important distinctions in their actions and the events which trigger them. Every router which is a secondary neighbor forWhen 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 theprimary 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 machinereceives aan new mlink Type-9Type 9 LSA from a primary neighbor via link state update, or confirms the status of an existing one during database exchange,neighbor, the LSA's content may create a new secondary neighbor, destroy an existing secondary neighbor or effectmodify 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-9Type 9 LSAs from the database summary list of a primary neighbor during database exchange with its primary neighborsto enableensure that its corresponding secondary neighbors toneighbor relationships transition past Initout of Down 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 newA secondary neighbors or change theneighbor state of existingmachine always passes through Attempt state, even for point-to-point and point-to-multipoint secondary neighbors.interface network types (See Section 5.3 and 5.4). If an mlink Type-9Type 9 LSA of a primary neighborages out, the KillNbr event is executed for the primary neighbor'scorresponding secondary adjacency,neighbor, and the LSA should be flushed. A newly received mlink Type-9 LSA from a primary neighbor may effectIf the creationstate of a new secondary adjacency for the neighbor. It may also causethe corresponding secondaryneighbor to drop to 2-Way stateis 2-way or lower or be destroyed altogether. (See Section 5.5) A secondary neighbor state machine never enters Attempt state forhigher, the local router should send a NBMA secondary interface. Instead it relies solely on its corresponding primary neighbor state machineHello packet to start communications over an NBMA. Hence there is no Start event for athe secondary neighbor state machine (See Section 5.4). 5.3 Events Triggered bywhich omits it from the Primary Neighbor State Machine When a primaryneighbor 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.list (See Section 5.5). The events KillNbr, LLDown, and Inactivity Timerconditions which cause the execution of athe KillNbr and LLDown events for primary neighbor state machine simultaneouslyneighbors should trigger the same events for its loosely boundany of their corresponding secondary neighbor state machines.neighbors. Since the formation of secondary neighbors is linked with the database exchange and the link state update of the mlink Type-9Type 9 LSAs received from their loosely boundacross the primary neighbors,link, the timing of this exchange effects when a secondary neighbor transitions to ExStart state. The mlink Type-9Type 9 LSA of a secondary Area 0 should be listed at the top of the database summary list. The mlink type-9Type 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 allowingletting an Area 0 secondary neighbor state machine toproceed to Full state roughly in parallel with the primary neighbor state machine. 5.45.3 Receiving Hello Packets IfMlink Type 9 Neighbor Discovery LSAs This section explains the detailed processing of a Hello Packet isreceived from one of the interface's existing primary neighbors which has loosely boundmlink Type 9 LSA. Note that any mlink Type 9 LSAs received across a secondary interface are simply ignored. Thus two neighbors thenwhich don't agree on the correspondingprimary area will never form either primary or secondary neighbor state machines are executed in line as follows: o Each Hello Packet causes each of theadjacencies. When an mlink Type 9 LSA is acknowledged during a primary neighbor's existing secondary neighbor state machines atdatabase exchange or received via link state greater than Down to be executed with the event HelloReceived. o Then the list of neighbors contained in the Hello Packetupdate, its Secondary Area ID is examined. If the router itself does not appear 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 be created and do not effect the election of Designated 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 inchecked 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 neighbor data structure's Router Priority field, Neighbor's Designated Router field, and the Neighbor's Backup Designated Router field from the corresponding fields in the LSA's opaque data. Changes in these fields should be notedlisted, for possible use in the steps below. Nowpoint-to-multipoint and transit networks the restoriginator of the mlink Type-9Type 9 LSA is examined generating events toshould be given toon the corresponding secondary neighbor and secondary interface state machines. These state machines are specified either tosame network as the receiving interface. This can be executed or scheduled (see [OSPF] Section 4.4). For example,verified by specifying below thatcomparing 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 state machine be executedin line, several neighbor state transitions may be effected by a single received mlink Type-9 LSA: o Thethe current list of secondary neighbors contained in the LSA's opaquecorresponding secondary interface data is examined.structure. If the router itself appears in this list, then the correspondinga matching secondary neighbor state machine for this neighbor shoulddata structure cannot be executed withfound, (i.e. this is the event 2-WayReceived. Otherwise,first time the secondary neighbor state machine should be executed with the event 1-WayReceived,has been detected), and the processing of the LSA stops. o Next,if a change in the neighbor's Secondary Router Priority field inthe LSA was noted,secondary network type is either point-to-point or point-to-multipoint or the correspondingsecondary interface state machinenetwork type is scheduled withNBMA and either the event NeighborChange. o Iflocal router or the neighbororiginating router is both declaring itself to beDR eligible across the Designated Routersecondary NBMA, then create a secondary neighbor data structure for the neighbor described in the LSA (LSA's Designated Router field =mlink Type 9. The Neighbor IP address),ID and the Backup Designated Router field in the LSA's opaque information is equal to 0.0.0.0, andNeighbor IP address of the correspondingsecondary interface is in state Waiting, then scheduleneighbor data structure are copied from the Advertising Router and IP Address fields of the secondary interfacemlink Type 9 LSA. The initial state machine with the event BackupSeen. Otherwise, ifof the newly created secondary neighbor is declaring itselfset to be the Designated Router inDown. If the LSA and it had not previously,secondary network type is point-to-point or point-to-multipoint, or the secondary neighbornetwork type is not declaring itself Designated Router in the LSA where it had previously, then scheduleNBMA and both the secondary interface state machine withlocal router and the event NeighborChange. o Iforiginating router are DR eligible (as defined the secondary neighbor is declaring itself to be the Backup Designated Router in the LSA (LSA's Backup Designated Router field = Neighbor IP address)data structure and the corresponding secondary interface is in state Waiting,newly received mlink Type 9 LSA) then scheduleexecute a Start event for the newly created secondary interface state machineneighbor. 5.4 Receiving Secondary Hello Packets The processing of Secondary Hello Packets proceeds as described in [OSPF] Section 10.5 with the event BackupSeen. Otherwise, if the neighborjust a few exceptions. If a Secondary Hello Packet is declaring itself to bereceived from a non-existent secondary neighbor the Backup Designated Router inprocessing of the LSAHello Packet stops and it had not previously, orthe neighborpacket is not declaring itself Backup Designated Router where it had previously,dropped. Secondary neighbor data structures are created by the secondary interface state machineprocessing of received mlink Type 9 LSAs (See Section 5.4). If a Secondary Hello Packet is scheduledreceived with a router priority which does not match that of the mlink Type 9 LSA which created the secondary neighbor, a 1- WayReceived event NeighborChange.should be executed. 6.0 Advertising Secondary Adjacencies A Border routers advertise theirrouter advertises its secondary adjacencies in their router-LSAsthe router- LSAs of its configured secondary areas as unnumberedpoint-to-point links even though they may be numbered point-to-point links, point-to-multipoint links, or broadcast orsecondary NBMA networklinks. Any stub or transit networks shared by the primary link with its secondary links are never advertised in the OSPF interface's primary area.router-LSAs of its secondary areas. This allows their interconnectingthese stub and transit networks to retain a single area identity. As unnumbered point-to-point links, allNoting that a secondary adjacencies have link type 1. The buildinginterface does share the IP address of its corresponding primary interface, when adding the router-LSA, as described in [OSPF] Section 12.4.1, is virtually unchanged. Even thoughsecondary adjacencies are considered unnumbered point- to-point links, for the purpose of defining Link Data inlink to the router-router LSA (see Appendix A) they 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 (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. For unnumbered point-to-point networks,If the primary interface is unnumbered, the Link Data field should specify the interface's MIB- IIMIB-II [MIB] ifIndex value. The cost should be set to the secondary area'sconfigured output cost specified in the primary interface's SecondaryAreas parameter. By not adding the host route type 3 links noted in [OSPF] Section 12.4.1, secondary adjacencies retain the look and feelof unnumbered point-to-point links to the remaining routers inthe corresponding secondary area, even though they may configure their link data with the primary interface's IP address.interface. 7.0 The Shortest Path First Calculation Since secondary links appear in the link state data base of an area as unnumberedpoint-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 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 neighbor statesneighbors transition down from Full status,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. In addition, comments from the following individual are also acknowledged:Most notably, Acee Lindem IBMLindem, 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: firstname.lastname@example.org@noc.usgs.net 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). 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 as well asincluding a separate entry for each fully adjacent secondary neighbor across a broadcast or NBMAneighbor, regardless of its secondary link's network link. Secondary interfaces to broadcast and NBMA networks are considered point-to-multipoint networks.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 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. Secondary links are always type 1 point-to-point regardless of the type of their matching primary 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. AlthoughRecall a secondary links are considered unnumbered point-to-point links, they do evaluate Link Data as if they were numbered whenever their interface has anrouter link (Type 1) shares the IP address associated withof its corresponding primary area.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 ). 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 primary interface's SecondaryAreas parameter.in the secondary interface data structure. 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, TOS-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 Type-9Type 9 Neighbor Discovery LSAs Mlink Type-9Type 9 LSAs are used directly by OSPF to distribute lists of candidate secondary areas among neighboring routers. Mlink Type-9Type 9 LSAs are flooded across the primary interface. The flooding scope of an mlink Type-9Type 9 LSAs is link-local, which means mlink Type-9Type 9 LSAs are never forwardedflooded beyond the local (sub)network or router link. Sections 4.0 and 5.55.3 of this document describe the purpose of these mlink Type-9Type 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sec AuTypeIP Address | Sec Options+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sec Rtr Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sec Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sec Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Designated Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Designated Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Secondary neighbor0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |Syntax of the mlink Type-9Type 9 LSA's Link-State ID The link-state ID of an mlink Type-9Type 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-9Type 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 originating router. The Designated Router is identified here by the IP address across the primary link. Its value is set to 0.0.0.0 if there is no Designated Router for the secondary link. Backup Designated Router The identity of the Backup Designated Router for a secondary link, in the view of the originating router.IP Address The Backup Designated Router is identified here by itsIP address acrossAddress of the secondary area's corresponding primary interface. If the primary link. Its value isinterface has unnumbered point-to- point type, then IP Address should be set to 0.0.0.0 if there is no Backup0. Sec Rtr Pri This router's Designated Router priority for a secondary link across a transit network. This parameter is used during the secondary link. Secondary Neighbor Thelinks (Backup) Designated Router IDs of eachelection. If set to 0, the router from whom valid mlink Type-9 LSAs have been received acrosswill be ineligible to become the primary link(Backup) Designated Router for thethis secondary area with matching optional capabilities and authentication parameters.link. 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 unnumberedOSPF multiple area links. The SecondaryAreas parameter's default setting is null.Multiple Area Links. The SecondaryAreas interface parameter inlists a set of areas which may form secondary interface data structure is always null. For each secondary area listed in an interface's SecondaryAreas parameter, the secondary link's interface cost, authentication parameters and Designated Router priority must be configurable. If the interface cost and Designated Router priority are not configured they default to their corresponding values foradjacencies across the OSPF primaryinterface. 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.