idnits 2.17.1 draft-ietf-ospf-mlinks-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2000) is 8647 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1583' on line 878 == Unused Reference: 'OPAQ' is defined on line 717, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'OPAQ' Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Murphy 2 Internet Draft US Geological Survey 3 Expiration Date: February 2000 August 2000 4 File name: draft-ietf-ospf-mlinks-01.txt 6 Unnumbered OSPF Multiple Area Links 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Table Of Contents 29 1.0 Abstract ................................................. 1 30 2.0 Overview ................................................. 2 31 2.1 Requirement for Unnumbered OSPF Multiple Area Links ...... 2 32 2.2 Proposed Solution ........................................ 3 33 2.2.1 Secondary Adjacencies .................................... 4 34 2.2.2 Secondary Neighbor Discovery ............................. 4 35 2.2.3 Advertising Secondary Links .............................. 5 36 2.3 Application .............................................. 5 37 3.0 Secondary Interfaces ..................................... 5 38 3.1 The SecondaryAreas Interface parameter ................... 5 39 3.2 The Secondary Interface Data Structure ................... 6 40 3.3 The Secondary Interface State Machine .................... 6 41 3.4 OSPF Protocol Packet Processing .......................... 7 42 3.5 Designated Router Selection and Function ................. 7 43 4.0 Synchronizing Secondary Areas Using Mlink Type-9 LSAs .... 8 44 5.0 Secondary Neighbors ...................................... 9 45 5.1 The Secondary Neighbor Data Structure .................... 9 46 5.2 The Secondary Neighbor State Machine ..................... 10 47 5.3 Events Triggered by the Primary Neighbor State Machine.... 11 48 5.4 Receiving Hello Packets .................................. 11 49 5.5 Receiving Mlink Type-9 Neighbor Discover LSAs ............ 12 50 6.0 Advertising Secondary Adjacencies ........................ 13 51 7.0 The Shortest Path First Calculation ...................... 14 52 8.0 Flushing Secondary Adjacencies ........................... 14 53 9.0 Security Considerations .................................. 15 54 10.0 Acknowledgments .......................................... 15 55 11.0 References ............................................... 15 56 12.0 Authors' Addresses ....................................... 15 57 Appendix A: Router-LSAs ........................................ 16 58 Appendix B: Mlink Type-9 Neighbor Discover LSAs ................ 20 59 Appendix C: Configuration Parameters ........................... 23 61 1.0 Abstract 63 This memo describes an option to the OSPF Version 2 specification 64 which allows multiple areas to share the same OSPF interface and 65 links. One area is always configured as an interface's primary area. 66 The interface's remaining areas are termed secondary and view it as 67 unnumbered. Two border routers adjacent across the same secondary 68 area may forward the area's intra-area traffic across its secondary 69 links. This option applies to standard areas, stub areas, and NSSAs. 70 It works over any OSPF interface. Routers with this option 71 configured are backward compatible with routers running the standard 72 OSPF Version 2 compliant implementation as defined in RFC 2328. 74 Please send comments to ospf@discuss.microsoft.com. 76 2.0 Overview 78 2.1 Requirement for Unnumbered OSPF Multiple Area Links 80 Large corporate networks in today's modern Internet have tremendous 81 human and equipment resources coupled with sizable budget invested in 82 their backbone infrastructure. Their regional networks are normally 83 not so fortunate and must multi-home to the backbone in order to take 84 advantage of the backbone's faster and more reliable network links. 85 Performance over a T1 link can pale by comparison to performance over 86 a DS3 or OC3 backbone link. Large corporate networks have sizable 87 backbone routing tables and routinely use stub areas and NSSAs. Under 88 the current OSPF specification intra-area routes are always preferred 89 over inter-area routes even when the traffic is sourced from and 90 destined to the same non-backbone OSPF area. 92 Consider the following typical OSPF example: 94 A0-----------Area 0 link------------B0-------N1 95 | DS3 (1) | (2) 96 | | 97 |NSSA 1 link NSSA 1 link| 98 | T1 (28) T1 (28) | 99 | | 100 | | 101 A1-----------NSSA 1 link------------B1-------M1 102 512k (56) (2) 104 where A0 and B0 are border routers attached to NSSA 1. A1 and B1 are 105 internal routers in NSSA 1. N1 and M1 are standard ethernet networks 106 in NSSA 1 which are directly attached to B0 and B1 respectively. The 107 cost of each link is shown in parentheses. All OSPF costs are 108 symmetric. Under the current OSPF specification the preferred path 109 between A0 and M1 is 111 A0<->A1<->B1<->M1 113 with an OSPF cost of 86, even though there exists a more preferred 114 path through B0 namely 116 A0<->B0<->B1<->M1 118 with an OSPF cost of 31. 120 In addition the NSSA 1 OSPF preferred path between A1 and N1 is 122 A1<->B1<->B0<->N1, 124 with an OSPF cost of 86, even though there exists a more preferred 125 path through the link between A0 and B0, namely 127 A1<->A0<->B0<->N1 129 with an OSPF cost of 31. Under the current OSPF specification NSSA 130 1's router A1 does not even see this path to N1 since it has no 131 knowledge of Area 0's topology. A0, on the other hand, would at lease 132 see the summary LSA of N1, but still cannot take advantage of it due 133 to OSPF intra-area path preference. 135 What is needed is a tool which makes the Area 0 link between A0 and 136 B0 visible inside NSSA 1. A common practice is to use multiple 137 interface subnets. However this is not an option when the path 138 between A0 and B0 is unnumbered or when one desires that the NSSA 1 139 path between A0 and B0 be unnumbered. Moreover when configuring 140 multiple interface subnets over multi-access networks, inverse-arp 141 limitations come into play and additional layer 2 PVCs may be 142 required imposing potential resource and budgetary ramifications. The 143 existing tools for the multiple area usage of the same physical link 144 are awkward to configure, implementation dependent, unnecessarily 145 complex and unwieldy to maintain. These tools also burden the 146 physical link with the simultaneous database exchange of multiple 147 OSPF interfaces during adjacency formation. 149 The Unnumbered OSPF Multiple Area Links option is a simpler tool for 150 configuring multiple area links, requiring just a simple list of the 151 areas sharing an OSPF link. Furthermore it prioritizes database 152 exchange, giving preference to the primary area and Area 0 over other 153 non-backbone secondary areas. If, in the above example, the link 154 between A0 and B0 were part of NSSA 1, path preference would be 155 optimal as the DS3 path would be intra-area for NSSA 1. 157 2.2 Proposed Solution 159 The Unnumbered OSPF Multiple Area Links option lets multiple areas 160 use the same link between two border routers for intra-area traffic. 161 Traffic may originate from inside each of the configured areas, as 162 every router in the configured areas sees the link as part of its 163 link state topology. Routers with configured unnumbered OSPF multiple 164 area links must be in Area 0, although the connection to Area 0 may 165 be an unnumbered OSPF multiple area link. 167 The current OSPF specification only allows one area per OSPF 168 interface. Thus, should an Area L dual-home to Area 0 via two border 169 routers which are adjacent over another Area K's router<->router link 170 or router<->network link, the adjacent link over Area K is not seen 171 inside Area L, even though the two border routers exist physically 172 adjacent within Area L. This, coupled with intra-area route 173 preference, prevents Area L from utilizing Area K's adjacent path. 175 2.2.1 Secondary Adjacencies 177 The softening of this restriction is facilitated by the addition of a 178 new interface configuration parameter called SecondaryAreas. This 179 parameter specifies a list of additional areas in which an OSPF 180 interface also belongs (See Appendix C). The areas listed in this 181 parameter are called the interface's secondary areas, as opposed to 182 the interface's configured area, hereafter called the primary area. A 183 separate interface data structure is generated for each of the 184 secondary areas. For each secondary area listed in the SecondaryAreas 185 parameter a router can form OSPF adjacencies with the primary area's 186 neighboring routers across the interface's directly attached network 187 or router link. These adjacencies are called secondary adjacencies. 189 Secondary adjacencies are formed after the primary area's link state 190 data base exchange has synchronized matching secondary areas with any 191 of its primary neighbors (See Section 4.0). Link state database 192 exchange occurs across a secondary adjacency along with normal 193 flooding. Note that a secondary adjacency for area 0 may not be 194 configured over an interface which is linked to a transit area for a 195 configured virtual link. 197 2.2.2 Secondary Neighbor Discovery 199 A Type-9 opaque LSA is used to form secondary adjacencies over a 200 primary link with adjacent opaque capable border routers. Until an 201 opaque type is assigned for this option experimental opaque type 224 202 will be used. The option's LSA is referred to as an mlink Type-9 LSA. 203 A Type-9 LSA is used for the exchange/update of an interface's 204 secondary areas because the flooding scope of this opaque LSA needs 205 to be restricted to routers which are directly attached to a common 206 network or router link. A separate mlink Type-9 LSA is originated for 207 each of the primary interface's secondary areas. Included in a 208 secondary area's mlink Type-9 LSA is the secondary area's configured 209 optional capabilities, its authentication parameters, plus, if 210 required, its configured Designated Router priority. Mlink Type-9 211 LSAs are propagated during the exchange/update of the primary area's 212 link state data base (LSDB) with its adjacent primary neighbors. 214 If a router A receives an mlink Type-9 LSA for area L originating 215 from a router B during the exchange/update of primary area K's LSDB, 216 then router A may form a secondary adjacency in area L with router B 217 provided the LSA's optional capabilities and authentication 218 parameters match those configured for the secondary area in the 219 SecondaryAreas parameter. See Section 5.2 for details about secondary 220 neighbor adjacency formation. LSDB exchange and update across a 221 secondary adjacency proceed as defined in [OSPF] Sections 10 and 13. 223 2.2.3 Advertising Secondary Links 225 Secondary adjacencies are advertised as point-to-point or point-to- 226 multipoint links. Any intervening transit network always belongs to 227 the interface's primary area. Moreover, there is no network LSA for a 228 secondary adjacency's intervening transit network in the secondary 229 area. Hence all secondary adjacencies must be advertised in a 230 router's router-LSA with unnumbered point-to-point type. 232 During the Dykstra shortest path first (SPF) calculation the LSAs for 233 secondary adjacencies look like unnumbered point-to-point links. A 234 Border router never includes in a secondary area's SPF tree any 235 network across which one of its secondary adjacencies span. This 236 ensures synchronization of the SPF tree amongst the secondary area's 237 routers. However border routers may use the IP addresses of 238 neighboring routers for determining a destination's next hop across a 239 secondary link over a point-to-multipoint or transit network. 241 2.3 Application 243 Consider now the example mentioned in Section 2.1 and assume NSSA 1 244 is configured as a secondary area over the Area 0 link between A0 and 245 B0. Since the routers A0, A1, B0, and B1 possess NSSA 1's router-LSAs 246 originating from A0 and B0 which define a secondary link between A0 247 and B0 in NSSA 1, the NSSA 1 intra-area SPF tree computed by the 248 Dykstra calculation now includes this DS3 link with a cost of 1. Thus 249 the path between A0 and M1 is the more preferred path 251 A0<->B0<->B1<->M1 253 and the path between A1 and N1 is the more preferred path 255 A1<->A0<->B0<->N1 257 3.0 Secondary Interfaces 259 3.1 The SecondaryAreas Interface Parameter 261 A new configuration parameter called SecondaryAreas has been added to 262 the OSPF interface data structure (See Appendix C). The 263 SecondaryAreas interface parameter lists a set of areas which may 264 form unnumbered secondary adjacencies across the interface. If the 265 SecondaryAreas interface parameter has a null list, then no secondary 266 areas are configured for this interface and no secondary adjacencies 267 can be formed over the interface. For each secondary area listed in 268 the SecondaryAreas interface parameter the interface cost, 269 authentication parameters, and Designated Router priority are also 270 configurable. The SecondaryAreas' interface costs and the Designated 271 Router priorities default to the values assigned to the primary 272 interface. Note that if a virtual link is configured across a transit 273 area which is linked to an interface, then Area 0 may not be 274 configured in the interface's SecondaryAreas parameter. 276 3.2 The Secondary Interface Data Structure 278 An OSPF interface data structure should be built for each of an OSPF 279 interface's secondary areas. These interface data structures are 280 called secondary interface data structures and are bound to the 281 primary interface. The configured primary area of an OSPF interface 282 generates its primary interface data structure. Recall [OSPF] 283 Sections 8.2 and 10.5 imply that a point-to-point layer 2 link 284 between two routers may have only one OSPF interface per area. 285 Additional areas may be added as secondary areas, but they must not 286 duplicate areas already configured for the layer 2 link. 288 A secondary interface's list of neighboring routers is generated by 289 examining the primary interface's received mlink Type-9 LSAs as 290 defined in Section 4.0 below. Before a neighboring router may be 291 added to the secondary interface's list of neighboring routers it 292 must also occur in the primary interface's list of neighboring 293 routers. 295 Secondary interfaces copy their interface type from the primary 296 interface's data structure and still compute a Designated Router and 297 a Backup Designated Router over broadcast and NBMA networks. This 298 promotes efficient flooding across a primary interface's transit 299 network. However, these network links are always advertised as 300 unnumbered router<->router links and behave exactly like point-to- 301 multipoint interfaces. As such a secondary link's Designated Router 302 does not originate a type-2 network LSA into the secondary area for 303 the primary interface's transit network. 305 3.3 The Secondary Interface State Machine 307 The interface states of a secondary interface are the same as the 308 interface states of a primary interface. However in some cases state 309 transitions are triggered by the primary interface's state machine. 310 The InterfaceUp event is redefined for secondary links: 312 InterfaceUp 314 This event is triggered by the primary interface when it 315 transitions to either Point-to-point, DR Other, DR, or Backup 316 state. Its effect on the secondary interface's state is similar to 317 the effect the InterfaceUp event has on the primary interface's 318 state with one exception. The periodic sending of Hello packets is 319 suppressed for a secondary interface. If the primary interface 320 network is a physical point-to-point or point-to-multipoint 321 network, then the secondary interface transitions to Point-to- 322 point state. Else if the router is not eligible to become the 323 Designated Router, the interface state transitions to DR Other. 325 Otherwise the attached primary network is a broadcast or NBMA 326 network and the router is eligible to become a Designated Router 327 for the secondary area. In this case, an attempt is made to 328 discover the attached network's Designated Router for the 329 secondary area. The interface state is set to Waiting and the 330 single shot Wait Timer is started. 332 The events BackupSeen and NeighborChange for a secondary interface 333 are triggered during the processing of the primary interface's 334 received mlink Type-9 LSAs in very much the same way these events are 335 triggered for a standard OSPF interface during the processing of 336 received Hello Packets (See Section 5.5). 338 The events InterfaceDown, LoopInd, UnloopInd, and Wait Timer are 339 unchanged for secondary interfaces. Note that since the secondary 340 interface's InterfaceUp event occurs only after the primary interface 341 has transitioned to DR other, DR or Backup state, a secondary 342 interface's Wait Timer will never start before the primary 343 interface's Wait Timer has fired. 345 3.4 OSPF Protocol Packet processing 347 Since secondary interfaces are unnumbered interfaces, OSPF protocol 348 packet processing needs a minor adjustment. For point-to-point 349 networks there are no changes. For broadcast, NBMA, and point-to- 350 multipoint links, the packet's IP source address is required to be on 351 the same network as the receiving OSPF primary interface. This can be 352 verified by comparing the packet's IP source address to the primary 353 interface's source address, after masking both addresses with the 354 interface mask (See [OSPF] Section 8.2). 356 3.5 Designated Router Selection and Function 358 The election of the Designated Router and the Backup Designated 359 router for a secondary link over a broadcast or NBMA network proceeds 360 as described in [OSPF] Section 9.4. Eligibility is determined from 361 the Designated Router priorities defined in the SecondaryAreas 362 parameter and the received mlink Type-9 LSAs, as well as its 363 neighbors' views of the Designated Router and the Backup Designated 364 Router for the secondary link, which is also found in the received 365 mlink Type-9 LSAs. Any change in the calculating router's Designated 366 Router or Backup Designated Router for a secondary link will result 367 in the reorigination of the corresponding secondary area's mlink 368 Type-9 LSA. 370 Note that the Designated Router for a secondary link does not 371 originate a network-LSA (Type-2) into its secondary area for the 372 broadcast or NBMA network over which the secondary link bridges. All 373 secondary links remain unnumbered point-to-point or point-to- 374 multipoint (see Section 6.0). The only function of a secondary link's 375 Designated Router is flooding optimization. 377 4.0 Synchronizing Secondary Areas using Mlink Type-9 LSAs 379 Mlink Type-9 LSAs are used to discover and maintain secondary 380 neighbor relationships and to elect the Designated Router and Backup 381 Designated Router for multi-access secondary adjacencies. If the 382 primary interface is of broadcast or NBMA type then all of its 383 candidate Designated Routers must be opaque capable, even if these 384 routers have no secondary areas configured for their link to the 385 broadcast or NBMA network. Otherwise mlink Type-9 LSAs may not 386 propagate to all potential routers capable of forming secondary 387 adjacencies over the network. Note that these candidate Designated 388 Routers do not have to support unnumbered OSPF multiple area links, 389 but they do have to be opaque capable in order to flood mlink Type-9 390 LSAs to their adjacent primary neighbors who may or may not support 391 unnumbered OSPF multiple area links. 393 The format of the mlink Type-9 LSA is detailed in Appendix B. Any 394 router which has an interface with a non-empty SecondaryAreas 395 interface parameter must originate an mlink Type-9 LSA for each 396 configured secondary area. If an interface's SecondaryAreas parameter 397 is null, then no mlink Type-9 LSAs should be advertised. A secondary 398 area's mlink Type-9 LSA minimally lists as opaque information the 399 area's secondary area ID, its optional capabilities, its 400 authentication parameters, and, if required, its Designated Router 401 priority. 403 In addition, to ensure proper secondary neighbor state transition, a 404 secondary area's mlink Type-9 LSA also lists as opaque information 405 those primary neighbors from which an mlink Type-9 LSA has been 406 received for this area with matching optional capabilities and 407 authentication parameters (See Section 5.5). Any change in this list 408 will result in the reorigination of a new instance of the secondary 409 area's mlink Type-9 LSA. Also for broadcast and NBMA networks the 410 mlink Type-9 LSA lists the router's current choice for the area's 411 Designated Router and Backup Designated Router. A value of 0.0.0.0 in 412 these fields means that one has not yet been selected. 414 Unlike Hello Packets, a new instance of a secondary area's mlink 415 Type-9 LSA is only originated when the LSA's opaque information 416 content has changed or when the LSRefreshInterval has expired. The 417 LSA's content may change during the processing of received Hellos and 418 received mlink Type-9 LSAs, or when an mlink Type-9 LSA ages out or 419 when the primary interface parameters of a secondary area are 420 reconfigured. A new mlink Type-9 LSA is reoriginated following 421 expiration of its LSRefreshInterval or when changes occur in its 422 secondary area's interface cost, authentication parameters, router 423 priority, Designated Router, Backup Designated Router, or the area's 424 list of secondary neighbors at state greater than Init. Like other 425 LSAs, the reorigination of a mlink Type-9 LSA is subject to the 426 MinLSInterval. New mlink Type-9 LSAs are built from the list of 427 configured secondary areas plus their corresponding secondary 428 interface state machines and secondary neighbor state machines. Mlink 429 type-9 LSAs are only flooded at the routers fully adjacent primary 430 neighbors. If a secondary area is removed from a primary interface's 431 configured secondary areas, its locally originated mlink type-9 LSA 432 should be flushed. 434 The mlink Type-9 LSA of each of the primary interface's secondary 435 areas must have a unique opaque ID. The last 24 bits of the Secondary 436 Area ID will normally produce unique Opaque IDs. When it doesn't, 437 alter the least significant bits until uniqueness is achieved. 439 5.0 Secondary Neighbors 441 An OSPF router converses with its secondary neighbors. Each separate 442 conversation is described by a "secondary neighbor data structure". 443 Conversations between secondary neighbors are bound to the secondary 444 interface and identified by both the Area ID and either the router's 445 OSPF Router ID or its Neighbor IP address (see below). Unless 446 discussed below details for the creation and maintenance of secondary 447 neighbors and secondary adjacencies are the same as discussed in 448 [OSPF] Sections 9 and 10. 450 5.1 The Secondary Neighbor Data Structure 452 The neighbor data structure for secondary adjacencies is identical to 453 the neighbor data structure for standard OSPF adjacencies. Secondary 454 neighbors are discovered by comparing the contents of the primary 455 interface's received mlink Type-9 LSAs with its configured list of 456 secondary areas and then comparing the secondary areas' configured 457 optional capabilities (see Section 5.5) with those listed for them in 458 the neighboring router's mlink Type-9 LSAs. A separate neighbor data 459 structure is built for each matching secondary area. 461 The Inactivity Timer used for a primary neighbor data structure is 462 synchronized with the Inactivity Timer for all of its configured 463 secondary neighbor data structures. The secondary link's Designated 464 Router and the Backup Designated Router, as viewed by a secondary 465 neighbor, are specified as opaque information stored in the 466 neighbor's corresponding mlink Type-9 LSA and received over the 467 primary interface. Also included are the neighbor's Designated Router 468 priority for the secondary link, its optional capabilities, and a 469 list of secondary neighbors it sees over the secondary link. 471 The secondary Neighbor ID and Neighbor IP address are copied from the 472 corresponding primary area neighbor data structure. The OSPF optional 473 capabilities which are supported by the neighboring router for the 474 secondary area are learned from opaque information stored in the 475 neighbor's mlink Type-9 LSA for this area and must match the local 476 router's optional capabilities configured for the secondary area. 478 5.2 The Secondary Neighbor State Machine 480 While secondary neighbor states are identical to OSPF's neighbor 481 states, there are some important distinctions in their actions and 482 the events which trigger them. Every router which is a secondary 483 neighbor for a secondary interface is also a primary neighbor for its 484 primary interface. The two neighbor data structures are loosely bound 485 together so that events which happen to the primary neighbor may 486 trigger events for the secondary neighbor. 488 A secondary neighbor's Init, 1-way, and 2-way state transitions are 489 controlled by the reception across the primary interface of Hello 490 Packets and mlink Type-9 LSAs (See Sections 5.4 and 5.5). The 491 combination of the two eliminates the requirement for the periodic 492 sending of Hello Packets for each secondary interface. When a primary 493 neighbor state machine receives a new mlink Type-9 LSA from a primary 494 neighbor via link state update, or confirms the status of an existing 495 one during database exchange, the LSA's content may create a new 496 secondary neighbor or effect the state of an existing secondary 497 neighbor. A router must clear its own mlink Type-9 LSAs from the 498 database summary list during database exchange with its primary 499 neighbors to enable its secondary neighbors to transition past Init 500 state. Any existing mlink Type-9 LSAs previously received from other 501 primary neighbors must be cleared from the database summary list 502 during a primary neighbor's database exchange before their content 503 can create new secondary neighbors or change the state of existing 504 secondary neighbors. 506 If an mlink Type-9 LSA of a primary neighbor ages out, the KillNbr 507 event is executed for the primary neighbor's corresponding secondary 508 adjacency, and the LSA should be flushed. A newly received mlink 509 Type-9 LSA from a primary neighbor may effect the creation of a new 510 secondary adjacency for the neighbor. It may also cause the 511 corresponding secondary neighbor to drop to 2-Way state or lower or 512 be destroyed altogether. (See Section 5.5) 514 A secondary neighbor state machine never enters Attempt state for a 515 NBMA secondary interface. Instead it relies solely on its 516 corresponding primary neighbor state machine to start communications 517 over an NBMA. Hence there is no Start event for a secondary neighbor 518 state machine (See Section 5.4). 520 5.3 Events Triggered by the Primary Neighbor State Machine 522 When a primary neighbor state machine transitions down to ExStart due 523 to either a SeqNumberMismatch or BadLSReq event, it triggers a 1- 524 WayReceived Event for any secondary neighbors at state 2-way or 525 greater. 527 The events KillNbr, LLDown, and Inactivity Timer of a primary 528 neighbor state machine simultaneously trigger the same events for its 529 loosely bound secondary neighbor state machines. 531 Since the formation of secondary neighbors is linked with the 532 database exchange and the link state update of the mlink Type-9 LSAs 533 received from their loosely bound primary neighbors, the timing of 534 this exchange effects when a secondary neighbor transitions to 535 ExStart state. The mlink Type-9 LSA of a secondary Area 0 should be 536 listed at the top of the database summary list. The mlink type-9 LSAs 537 of non-backbone secondary areas should be listed at the bottom of the 538 database summary list. These tools mitigate the effect of the 539 database exchange by non-backbone secondary areas on the primary 540 neighbor state machine as it transitions to Full state, while at the 541 same time allowing an Area 0 secondary neighbor state machine to 542 proceed to Full state roughly in parallel with the primary neighbor 543 state machine. 545 5.4 Receiving Hello Packets 547 If a Hello Packet is received from one of the interface's existing 548 primary neighbors which has loosely bound secondary neighbors then 549 the corresponding secondary neighbor state machines are executed in 550 line as follows: 552 o Each Hello Packet causes each of the neighbor's existing secondary 553 neighbor state machines at state greater than Down to be executed 554 with the event HelloReceived. 556 o Then the list of neighbors contained in the Hello Packet is 557 examined. If the router itself does not appear in this list, then 558 each of the neighbor's existing secondary neighbor state machines 559 at state greater than Init should be executed with the event 1- 560 WayReceived. 562 Hello packets do not cause secondary neighbor structures to be 563 created and do not effect the election of Designated Routers and 564 Backup Designated Routers by the secondary interface state machines. 565 That is triggered by the processing of the primary interface's 566 received mlink Type-9 LSAs. All primary neighbors are considered 567 secondary neighbors for each configured secondary area. They 568 transition from Down to Init state with their corresponding primary 569 neighbors and freeze at Init state until the creation of their 570 secondary neighbor data structures is triggered when the primary 571 interface receives their mlink Type-9 LSAs. (See Section 5.5) 573 5.5 Receiving Mlink Type-9 Neighbor Discovery LSAs 575 This section explains the detailed processing of a received mlink 576 type-9 LSA. When an mlink Type-9 LSA is acknowledged during a primary 577 neighbor's database exchange or received via link state update, its 578 Secondary Area ID is checked against those listed in the primary 579 interface's SecondaryAreas parameter. If it is not listed processing 580 of this LSA stops. If it is listed and its optional capabilities or 581 authentication parameters no longer match those stored in the 582 SecondaryAreas parameter, then execute a KillNbr event for any 583 existing corresponding secondary neighbor state machine belonging to 584 this neighbor and terminate processing of this LSA. 586 Else check for the existence of a secondary neighbor state machine 587 for the Secondary Area ID that corresponds to the originating primary 588 neighbor. If one does not exist, create one. Initialize its state to 589 Init and copy the Neighbor ID, the Inactivity Timer, and the Neighbor 590 IP address from the corresponding primary neighbor state machine. 592 When the received mlink Type-9 LSA originated from a primary neighbor 593 over a broadcast, point-to-multipoint or NBMA network set the 594 corresponding secondary neighbor data structure's Router Priority 595 field, Neighbor's Designated Router field, and the Neighbor's Backup 596 Designated Router field from the corresponding fields in the LSA's 597 opaque data. Changes in these fields should be noted for possible use 598 in the steps below. 600 Now the rest of the mlink Type-9 LSA is examined generating events to 601 be given to the corresponding secondary neighbor and secondary 602 interface state machines. These state machines are specified either 603 to be executed or scheduled (see [OSPF] Section 4.4). For example, by 604 specifying below that the secondary neighbor state machine be 605 executed in line, several neighbor state transitions may be effected 606 by a single received mlink Type-9 LSA: 608 o The list of secondary neighbors contained in the LSA's opaque data 609 is examined. If the router itself appears in this list, then the 610 corresponding secondary neighbor state machine for this neighbor 611 should be executed with the event 2-WayReceived. Otherwise, the 612 secondary neighbor state machine should be executed with the event 613 1-WayReceived, and the processing of the LSA stops. 615 o Next, if a change in the neighbor's Secondary Router Priority 616 field in the LSA was noted, the corresponding secondary interface 617 state machine is scheduled with the event NeighborChange. 619 o If the neighbor is both declaring itself to be the Designated 620 Router in the LSA (LSA's Designated Router field = Neighbor IP 621 address), and the Backup Designated Router field in the LSA's 622 opaque information is equal to 0.0.0.0, and the corresponding 623 secondary interface is in state Waiting, then schedule the 624 secondary interface state machine with the event BackupSeen. 625 Otherwise, if the neighbor is declaring itself to be the 626 Designated Router in the LSA and it had not previously, or the 627 secondary neighbor is not declaring itself Designated Router in 628 the LSA where it had previously, then schedule the secondary 629 interface state machine with the event NeighborChange. 631 o If the secondary neighbor is declaring itself to be the Backup 632 Designated Router in the LSA (LSA's Backup Designated Router field 633 = Neighbor IP address) and the corresponding secondary interface 634 is in state Waiting, then schedule the secondary interface state 635 machine with the event BackupSeen. Otherwise, if the neighbor is 636 declaring itself to be the Backup Designated Router in the LSA and 637 it had not previously, or the neighbor is not declaring itself 638 Backup Designated Router where it had previously, the secondary 639 interface state machine is scheduled with the event 640 NeighborChange. 642 6.0 Advertising Secondary Adjacencies 644 Border routers advertise their secondary adjacencies in their 645 router-LSAs as unnumbered point-to-point links even though they may 646 be numbered point-to-point links, point-to-multipoint links, or 647 broadcast or NBMA network links in the OSPF interface's primary area. 648 This allows their interconnecting networks to retain a single area 649 identity. As unnumbered point-to-point links, all secondary 650 adjacencies have link type 1. The building of the router-LSA, as 651 described in [OSPF] Section 12.4.1, is virtually unchanged. 653 Even though secondary adjacencies are considered unnumbered point- 654 to-point links, for the purpose of defining Link Data in the router- 655 LSA (see Appendix A) they use the primary interface's IP address. For 656 secondary adjacencies [OSPF] Section 12.4.1.1 is reduced to simply 658 If a neighboring router has formed a secondary adjacency then add 659 a type 1 (point-to-point) link for this adjacency. Its Link ID 660 should be set to the Router ID of the neighboring router. If the 661 primary interface is numbered, the Link Data should specify the 662 primary interface's IP address. For unnumbered point-to-point 663 networks, the Link Data field should specify the interface's MIB- 664 II [MIB] ifIndex value. The cost should be set to the secondary 665 area's cost specified in the primary interface's SecondaryAreas 666 parameter. 668 By not adding the host route type 3 links noted in [OSPF] Section 669 12.4.1, secondary adjacencies retain the look and feel of unnumbered 670 point-to-point links to the remaining routers in the secondary area, 671 even though they may configure their link data with the primary 672 interface's IP address. 674 7.0 The Shortest Path First Calculation 676 Since secondary links appear in the link state data base of an area 677 as unnumbered point-to-point links there is no change required in the 678 Shortest Path First (SPF) calculation, except on those border routers 679 where they are configured. Border routers do not include in a 680 secondary area's SPF tree any network which one of its secondary 681 adjacencies transit. This ensures synchronization of the SPF tree 682 amongst the secondary area's routers. However border routers do use 683 the IP addresses stored in their secondary neighbors' router-LSAs for 684 determining a destination's next hop across a secondary link when the 685 associated interface connects to a point-to-multipoint or transit 686 network. In this case the outgoing interface is derived directly from 687 the destination router's next hop IP address. 689 8.0 Flushing Secondary Adjacencies 691 Secondary adjacencies are flushed from the link state database of a 692 secondary area when their neighbor states transition down from Full 693 status, just as with normal OSPF adjacencies. A new router-LSA is 694 built for the secondary area and flooded out all of the secondary 695 area's primary and secondary interfaces. Finally the SPF calculation 696 is performed to reflect the new link state topology. 698 9.0 Security Considerations 700 Security issues are not discussed in this memo. 702 10.0 Acknowledgments 704 This document was produced by the OSPF Working Group, chaired by John 705 Moy. In addition, comments from the following individual are also 706 acknowledged: 708 Acee Lindem IBM 710 11.0 References 712 [MIB] McCloghrie, K., and M. Rose, "Management Information Base for 713 network management of TCP/IP-based internets: MIB-II", STD 714 17, RFC 1213, Hughes LAN Systems, Performance Systems 715 International, March 1991. 717 [OPAQ] Coltun, Rob, "The OSPF Opaque LSA Option", FORE Systems, 718 August 1998. 720 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, Ascend Communications, 721 Inc., April 1998. 723 12.0 Author's Address 725 Pat Murphy 726 US Geological Survey 727 345 Middlefield Road, Mail Stop 870 728 Menlo Park, California 94560 730 Phone: (650)329-4044 731 EMail: pmurphy@usgs.gov 733 Appendix A. Router-LSAs 735 Router-LSAs are Type 1 LSAs. Each router in an area originates a router-LSA. 736 The router-LSA describes the state and cost of the router's links (i.e., 737 interfaces) to the area. All of the router's links to an area, including 738 secondary links, must be described in a single router-LSA. For details 739 concerning the construction of router-LSAs see this document's Section 6.0 740 and [OSPF] Section 12.4.1. 742 0 1 2 3 743 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 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | LS age | Options | 1 | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Link State ID | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Advertising Router | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | LS sequence number | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | LS checksum | length | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | 0 |V|E|B| 0 | # links | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Link ID | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Link Data | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Type | # TOS | metric | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | ... | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | TOS | 0 | TOS metric | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Link ID | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Link Data | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | ... | 773 In router-LSAs, the Link State ID field is set to the router's OSPF 774 Router ID. Router-LSAs are flooded throughout a single area only. 776 bit V 777 When set, the router is an endpoint of one or more fully 778 adjacent virtual links having the described area as its 779 transit area (V is for virtual link endpoint). 781 bit E 782 When set, the router is an AS boundary router (E is for 783 external). 785 bit B 786 When set, the router is an area border router (B is for 787 border). 789 bit W 790 When set, the router is a wild-card multicast receiver (W is 791 for wild). 793 bit Nt 794 When set, the router is a NSSA border router which translates 795 type-7 LSAs into type-5 LSAs (Nt is for NSSA translation). 797 # links 798 The number of router links described in this LSA. This must be 799 the total collection of router links (i.e., interfaces) to the 800 area as well as a separate entry for each fully adjacent 801 secondary neighbor across a broadcast or NBMA network link. 802 Secondary interfaces to broadcast and NBMA networks are 803 considered point-to-multipoint networks. 805 The following fields are used to describe each router link (i.e., 806 interface). Each router link is typed (see the below Type field). The 807 Type field indicates the kind of link being described. It may be a 808 link to a transit network, to another router or to a stub network. 809 The values of all the other fields describing a router link depend on 810 the link's Type. For example, each link has an associated 32-bit Link 811 Data field. For links to stub networks this field specifies the 812 network's IP address mask. For other link types the Link Data field 813 specifies the router interface's IP address. 815 Type 816 A quick description of the router link for one of the 817 following. Note that host routes are classified as links to 818 stub networks with network mask of 0xffffffff. 820 Type Description 821 __________________________________________________ 822 1 Point-to-point connection to another router 823 2 Connection to a transit network 824 3 Connection to a stub network 825 4 Virtual link 827 Link ID 828 Identifies the object that this router link connects to. Its 829 value depends on the link's Type. When connecting to an object 830 that also originates an LSA (i.e., another router or a transit 831 network) the Link ID is equal to the neighboring LSA's Link 832 State ID. Secondary links are always type 1 point-to-point 833 regardless of the type of their matching primary link. This 834 provides the key for looking up the neighboring LSA in the 835 link state database during the routing table calculation. See 836 [OSPF] Section 12.2 for more details. 838 Type Link ID 839 ______________________________________ 840 1 Neighboring router's Router ID 841 2 IP address of Designated Router 842 3 IP network/subnet number 843 4 Neighboring router's Router ID 845 Link Data 846 Value again depends on the link's Type field. For connections 847 to stub networks, Link Data specifies the network's IP address 848 mask. For unnumbered point-to-point connections, it specifies 849 the interface's MIB-II [MIB] ifIndex value. For the other link 850 types it specifies the router interface's IP address. This 851 latter piece of information is needed during the routing table 852 build process, when calculating the IP address of the next 853 hop. Although secondary links are considered unnumbered 854 point-to-point links, they do evaluate Link Data as if they 855 were numbered whenever their interface has an IP address 856 associated with its primary area. See Section 6.0 of this 857 document and [OSPF] Section 16.1.1 for more details. 859 # TOS 860 The number of different TOS metrics given for this link, not 861 counting the required link metric (referred to as the TOS 0 862 metric in [1583]). For example, if no additional TOS metrics 863 are given, this field is set to 0. Secondary Areas do not use 864 TOS. 866 metric 867 The cost of using this router link. For secondary links the 868 cost is specified in the primary interface's SecondaryAreas 869 parameter. 871 Additional TOS-specific information may also be included, for 872 backward compatibility with previous versions of the OSPF 873 specification ([1583]). Within each link, and for each desired TOS, 874 TOS-specific link information may be encoded as follows: 876 TOS 877 IP Type of Service that this metric refers to. The encoding of 878 TOS in OSPF LSAs is described in [1583] Section 12.3. 880 TOS metric 881 TOS-specific metric information. 883 Appendix B. Mlink Type-9 Neighbor Discovery LSAs 885 Mlink Type-9 LSAs are used directly by OSPF to distribute lists of 886 candidate secondary areas among neighboring routers. Mlink Type-9 887 LSAs are flooded across the primary interface. The flooding scope of 888 mlink Type-9 LSAs is link-local, which means mlink Type-9 LSAs are 889 never forwarded beyond the local (sub)network or router link. 891 Sections 4.0 and 5.5 of this document describe the purpose of these 892 mlink Type-9 LSAs in more detail. 894 0 1 2 3 895 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 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | LS age | Options | 9 | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Opaque Type | Opaque ID | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Advertising Router | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | LS Sequence Number | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | LS checksum | Length | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Secondary Area ID | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Sec AuType | Sec Options | Sec Rtr Pri | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Sec Authentication | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Sec Authentication | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | Designated Router | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Backup Designated Router | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Secondary neighbor | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | ... | 923 Syntax of the mlink Type-9 LSA's Link-State ID 925 The link-state ID of an mlink Type-9 LSA is divided into an Opaque 926 Type field (the first 8 bits), which has value mlink, and the 927 Opaque ID (the remaining 24 bits). The mlink Type-9 LSA of each 928 of the primary interface's secondary areas must have a unique 929 opaque ID. The last 24 bits of the Secondary Area ID will normally 930 produce unique Opaque IDs. When it doesn't, alter the least 931 significant bits until uniqueness is achieved. 933 Options 934 The optional capabilities supported by this router for the 935 primary area, as documented in [OSPF] Section A.2. 937 Secondary Area ID 938 The area ID of the area across which a neighboring router may 939 form a secondary adjacency. 941 Sec AuType 942 Identifies the authentication procedure to be used. 943 Authentication is discussed in [OSPF] Appendix D of the 944 specification. Consult [OSPF] Appendix D for a list of the 945 currently defined authentication types. 947 Sec Authentication 948 A 64-bit field for use by the authentication scheme. See [OSPF] 949 Appendix D for details. 951 Neighbors Cnt 952 This 16 bit field describes the number of secondary neighbors 953 listed for the Secondary Area ID. If there are no secondary 954 neighbors listed, then Neighbor Cnt should be set to 0. 956 Sec Options 957 The optional capabilities supported by this router for this 958 secondary area, as documented in [OSPF] Section A.2. 960 Sec Rtr Pri 961 This router's Designated Router priority for a secondary link 962 across a transit network. This parameter is used during the 963 secondary links (Backup) Designated Router election. If set to 964 0, the router will be ineligible to become the (Backup) 965 Designated Router for this secondary link. 967 Designated Router 968 The identity of the Designated Router for a secondary link, in 969 the view of the originating router. The Designated Router is 970 identified here by the IP address across the primary link. Its 971 value is set to 0.0.0.0 if there is no Designated Router for 972 the secondary link. 974 Backup Designated Router 975 The identity of the Backup Designated Router for a secondary 976 link, in the view of the originating router. The Backup 977 Designated Router is identified here by its IP address across 978 the primary link. Its value is set to 0.0.0.0 if there is no 979 Backup Designated Router for the secondary link. 981 Secondary Neighbor 982 The Router IDs of each router from whom valid mlink Type-9 LSAs 983 have been received across the primary link for the secondary 984 area with matching optional capabilities and authentication 985 parameters. 987 Appendix C. Interface Data Structure 989 Chapter 9 in the OSPF specification documents the interface data 990 structure and the data items which are included in it. Section 3.1 of 991 this document defines a new interface configuration parameter called 992 SecondaryAreas which supports unnumbered OSPF multiple area links. 993 The SecondaryAreas parameter's default setting is null. The 994 SecondaryAreas parameter in a secondary interface data structure is 995 always null. 997 For each secondary area listed in an interface's SecondaryAreas 998 parameter, the secondary link's interface cost, authentication 999 parameters and Designated Router priority must be configurable. If 1000 the interface cost and Designated Router priority are not configured 1001 they default to their corresponding values for the OSPF primary 1002 interface. If a virtual link is configured across a transit area 1003 linked to an interface, then Area 0 may not be configured in the 1004 interface's SecondaryAreas parameter.