idnits 2.17.1 draft-ietf-ospf-mlinks-03.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. 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 (February 2002) is 8106 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 743 == Unused Reference: 'OPAQ' is defined on line 583, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'OPAQ' Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Murphy 3 Internet Draft US Geological Survey 4 Expiration Date: August 2002 February 2002 5 File name: draft-ietf-ospf-mlinks-03.txt 7 OSPF Multiple Area Links 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Table Of Contents 30 1.0 Abstract ................................................. 1 31 2.0 Overview ................................................. 2 32 2.1 Requirement for OSPF Multiple Area Links ................. 2 33 2.2 Proposed Solution ........................................ 3 34 2.2.1 Secondary Adjacencies .................................... 4 35 2.2.2 Secondary Neighbor Discovery ............................. 4 36 2.2.3 Advertising Secondary Links .............................. 5 37 2.3 Application .............................................. 5 38 3.0 Secondary Interfaces ..................................... 5 39 3.1 The SecondaryAreas Interface parameter ................... 5 40 3.2 The Secondary Interface Data Structure ................... 6 41 3.3 The Secondary Interface State Machine .................... 6 42 3.4 OSPF Protocol Packet Processing .......................... 7 43 3.5 Designated Router Election and Function .................. 7 44 4.0 Synchronizing Secondary Areas Using Mlink Type 9 LSAs .... 8 45 5.0 Secondary Neighbors ...................................... 8 46 5.1 The Secondary Neighbor Data Structure .................... 8 47 5.2 The Secondary Neighbor State Machine ..................... 9 48 5.3 Receiving Mlink Type 9 Neighbor Discover LSAs ............ 10 49 5.4 Receiving Secondary Hello Packets ........................ 11 50 6.0 Advertising Secondary Adjacencies ........................ 11 51 7.0 The Shortest Path First Calculation ...................... 11 52 8.0 Flushing Secondary Adjacencies ........................... 12 53 9.0 Security Considerations .................................. 12 54 10.0 Acknowledgments .......................................... 12 55 11.0 References ............................................... 12 56 12.0 Authors' Addresses ....................................... 12 57 Appendix A: Router-LSAs ........................................ 13 58 Appendix B: Mlink Type 9 Neighbor Discover LSAs ................ 17 59 Appendix C: Configuration Parameters ........................... 19 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 link. One area is 65 always configured as the link's primary area. The link's remaining 66 areas are termed secondary. Two border routers adjacent across the 67 same secondary area may forward the area's intra-area traffic across 68 the link. This option applies to standard areas, stub areas, and 69 NSSAs. It works over any OSPF interface. Routers with this option 70 configured are backward compatible with routers running the standard 71 OSPF Version 2 compliant implementation as defined in RFC 2328. 73 Please send comments to ospf@discuss.microsoft.com. 75 2.0 Overview 77 2.1 Requirement for OSPF Multiple Area Links 79 Large corporate networks in today's modern Internet have tremendous 80 human and equipment resources coupled with sizable budget invested in 81 their backbone infrastructure. Their regional networks are normally 82 not so fortunate and must multi-home to the backbone in order to take 83 advantage of the backbone's faster and more reliable network links. 84 Performance over a T1 link can pale by comparison to performance over 85 a DS3 or OC3 backbone link. Large corporate networks have sizable 86 backbone routing tables and routinely use stub areas and NSSAs. Under 87 the current OSPF specification intra-area routes are always preferred 88 over inter-area routes even when the traffic is sourced from and 89 destined to the same non-backbone OSPF area. 91 Consider the following typical OSPF example: 93 A0-----------Area 0 link------------B0-------N1 94 | DS3 (1) | (2) 95 | | 96 |NSSA 1 link NSSA 1 link| 97 | T1 (28) T1 (28) | 98 | | 99 | | 100 A1-----------NSSA 1 link------------B1-------M1 101 512k (56) (2) 103 where A0 and B0 are border routers attached to NSSA 1. A1 and B1 are 104 internal routers in NSSA 1. N1 and M1 are standard ethernet networks 105 in NSSA 1 which are directly attached to B0 and B1 respectively. The 106 cost of each link is shown in parentheses. All OSPF costs are 107 symmetric. Under the current OSPF specification the preferred path 108 between A0 and M1 is 110 A0<->A1<->B1<->M1 112 with an OSPF cost of 86, even though there exists a more preferred 113 path through B0 namely 115 A0<->B0<->B1<->M1 117 with an OSPF cost of 31. 119 In addition the NSSA 1 OSPF preferred path between A1 and N1 is 121 A1<->B1<->B0<->N1, 123 with an OSPF cost of 86, even though there exists a more preferred 124 path through the link between A0 and B0, namely 126 A1<->A0<->B0<->N1 128 with an OSPF cost of 31. Under the current OSPF specification NSSA 129 1's router A1 does not even see this path to N1 since it has no 130 knowledge of Area 0's topology. A0, on the other hand, would at lease 131 see the summary LSA of N1, but still cannot take advantage of it due 132 to OSPF intra-area path preference. 134 What is needed is a tool which makes the Area 0 link between A0 and 135 B0 visible inside NSSA 1. A common practice is to use multiple 136 interface subnets. However this is not an option when the path 137 between A0 and B0 is unnumbered or when one desires that the NSSA 1 138 path between A0 and B0 be unnumbered. Moreover when configuring 139 multiple interface subnets over multi-access networks, inverse-arp 140 limitations come into play and additional layer 2 PVCs may be 141 required, imposing potential resource and budgetary ramifications. 142 The existing tools for the multiple area usage of the same physical 143 link are awkward to configure, implementation dependent, 144 unnecessarily complex and unwieldy to maintain. If, in the above 145 example, the link between A0 and B0 were part of NSSA 1, path 146 preference would be optimal as the DS3 path would be intra-area for 147 NSSA 1. 149 2.2 Proposed Solution 151 The OSPF Multiple Area Links option is a simpler tool for configuring 152 multiple area links, requiring just a simple list of the areas 153 sharing an OSPF link. Once configured it lets multiple areas use the 154 same link between two border routers for each area's intra-area 155 traffic. Traffic may originate from inside each of the configured 156 areas, as every router in the configured areas sees the link as part 157 of its link state topology. Routers with configured OSPF Multiple 158 Area Links must be in Area 0, although the connection to Area 0 may 159 be one of the areas listed as sharing the link. 161 The current OSPF specification only allows one area per OSPF 162 interface. Thus, should an Area L dual-home to Area 0 via two border 163 routers which are adjacent over another Area K's router<->router link 164 or router<->network link, the adjacent link over Area K is not seen 165 inside Area L, even though the two border routers exist physically 166 adjacent within Area L. This, coupled with intra-area route 167 preference, prevents Area L from utilizing Area K's adjacent path. 169 2.2.1 Secondary Adjacencies 171 The softening of this restriction is facilitated by the addition of a 172 new interface configuration parameter called SecondaryAreas. This 173 parameter specifies a list of additional areas which share the OSPF 174 link (See Appendix C). The areas listed in this parameter are called 175 the interface's secondary areas, as opposed to the interface's 176 configured area, hereafter called the primary area. A separate 177 interface data structure is generated for each of the secondary 178 areas. For each secondary area listed in the SecondaryAreas parameter 179 a router can form OSPF adjacencies across the interface's directly 180 attached network or router link. These adjacencies are called 181 secondary adjacencies. 183 Secondary adjacencies are formed after the primary area's link state 184 data base exchange has synchronized matching secondary areas through 185 the flooding path with the link's other directly connected routers. 186 (See Section 4.0). Link state database exchange occurs across a 187 secondary adjacency along with normal flooding. Note that a secondary 188 adjacency for area 0 may not be configured for an interface which is 189 linked to a transit area for a configured virtual link (See Section 190 3.4). 192 2.2.2 Secondary Neighbor Discovery 194 A Type 9 opaque LSA is used to form secondary adjacencies over a 195 primary link with adjacent opaque capable border routers. Until an 196 opaque type is assigned for this option, experimental opaque type 224 197 will be used. The option's LSA is referred to as an mlink Type 9 LSA. 198 A Type 9 LSA is used for the exchange/update of an interface's 199 secondary areas because the flooding scope of this opaque LSA needs 200 to be restricted to routers which are directly attached to a common 201 network or router link. A separate mlink Type 9 LSA is originated for 202 each of the primary interface's secondary areas. If required, 203 included in a secondary area's mlink Type 9 LSA is the secondary 204 area's configured Designated Router priority. Mlink Type 9 LSAs are 205 propagated during the exchange/update of the primary area's link 206 state data base (LSDB) with its adjacent primary neighbors. 208 If a router A receives an mlink Type 9 LSA for area L originating 209 from a router B during the exchange/update of primary area K's LSDB, 210 then router A may form a secondary adjacency in area L with router B. 211 See Section 5.2 for details about secondary neighbor adjacency 212 formation. LSDB exchange and update across a secondary adjacency 213 proceed as defined in [OSPF] Sections 10 and 13. 215 2.2.3 Advertising Secondary Links 217 Secondary adjacencies are advertised as point-to-point links. Any 218 intervening transit network or stub network assigned to the primary 219 interface always belongs to the interface's primary area. There is no 220 network LSA for this intervening transit network in any of the 221 interface's secondary areas. All secondary adjacencies must be 222 advertised in a router-LSA with point-to-point type. 224 During the Dykstra shortest path first (SPF) calculation the LSAs for 225 secondary adjacencies look like point-to-point links. A border router 226 never includes in a secondary area's SPF tree any network across 227 which one of its secondary adjacencies span. This ensures 228 synchronization of the SPF tree amongst the secondary area's routers. 229 However, since border routers share the link's addressing, they may 230 use the IP addresses of their secondary neighbors for determining a 231 destination's next hop across a secondary link over a point-to- 232 multipoint or transit network. 234 2.3 Application 236 Consider now the example mentioned in Section 2.1 and assume NSSA 1 237 is configured as a secondary area over the Area 0 link between A0 and 238 B0. Since the routers A0, A1, B0, and B1 possess NSSA 1's router-LSAs 239 originating from A0 and B0 which define a secondary link between A0 240 and B0 in NSSA 1, the NSSA 1 intra-area SPF tree computed by the 241 Dykstra calculation now includes this DS3 link with a cost of 1. Thus 242 the preferred path between A0 and M1 is 244 A0<->B0<->B1<->M1 246 and the preferred path between A1 and N1 248 A1<->A0<->B0<->N1 250 3.0 Secondary Interfaces 252 3.1 The SecondaryAreas Interface Parameter 254 A new configuration parameter called SecondaryAreas has been added to 255 the OSPF interface data structure (See Appendix C). The 256 SecondaryAreas interface parameter lists a set of areas which may 257 form secondary adjacencies across the interface. If the 258 SecondaryAreas interface parameter has a null list, then no secondary 259 areas are configured for this interface and no secondary adjacencies 260 can be formed over the interface. 262 Each area listed in the SecondaryAreas interface parameter should 263 have a secondary interface data structure. With the exception of Area 264 ID all of secondary interface parameters which are usually 265 configurable, such as interface cost, authentication parameters and 266 Designated Router priority, default to the values assigned to the 267 primary interface. Furthermore, except for the Area ID, IP interface 268 address and mask, all configurable interface parameters should be 269 separately configurable for each secondary interface. Note that if a 270 virtual link is configured across a transit area which is linked to 271 an interface, then Area 0 may not be configured in the interface's 272 SecondaryAreas parameter. 274 3.2 The Secondary Interface Data Structure 276 An OSPF interface data structure should be built for each of an OSPF 277 interface's secondary areas. These interface data structures are 278 called secondary interface data structures and are loosely bound to 279 the primary interface. The configured primary area of an OSPF 280 interface generates its primary interface data structure. A point- 281 to-point layer 2 link between two routers may have only one OSPF 282 interface per area (See [OSPF] Sections 8.2 and 10.5). Additional 283 areas may be added as secondary areas, but they must not duplicate 284 areas already configured for the layer 2 link. A secondary 285 interface's list of neighboring routers is generated by examining the 286 primary interface's received mlink Type 9 LSAs as defined in Section 287 4.0 below. 289 With the exception of broadcast networks, secondary interfaces copy 290 their interface type from the primary interface's data structure. If 291 the primary interface's network has broadcast type then the secondary 292 interface's network has NBMA type. Secondary interfaces with NBMA 293 type still compute a Designated Router and a Backup Designated 294 Router. This promotes efficient flooding across the interface's 295 transit network. Note that secondary adjacencies are always 296 advertised as router links even when their network type is NBMA. As 297 such the Designated Router of a secondary NBMA link does not 298 originate a type-2 network LSA into the secondary area for the 299 primary interface's transit network. 301 3.3 The Secondary Interface State Machine 303 The interface states of a secondary interface are the same as the 304 interface states of a primary interface. Secondary neighbors exchange 305 Hello packets, called secondary Hello packets, just like primary 306 neighbors. The processing of received secondary Hellos is practically 307 unchanged (See Section 5.5). The InterfaceUp event for a secondary 308 interfaces is generated by its corresponding primary interface when 309 the primary interface transitions to either Point-to-point, DR Other, 310 DR, or Backup state. In addition to those actions described in [OSPF] 311 Section 9.3, when the InterfaceUp event is generated for secondary 312 interfaces, the neighbor Start event is generated for each existing 313 secondary neighbor. 315 The remainder of the interface state machine is virtually unchanged 316 for secondary interfaces. Those protocols which generate the events 317 InterfaceDown, LoopInd, UnloopInd for the primary interface should 318 generate the same events for all of the primary interface's 319 corresponding secondary interfaces. The NeighborChange and BackupSeen 320 events are generated through the orderly processing of secondary 321 Hello packets received across the secondary interface as described in 322 [OSPF] Section 10.5 and augmented in Section 5.4. It is notable that 323 since the secondary interface's InterfaceUp event occurs only after 324 the primary interface has transitioned to DR other, DR or Backup 325 state, a secondary interface's Wait Timer will never start before the 326 primary interface's Wait Timer has fired. This produces a more 327 orderly ascension to Full state for secondary NBMA adjacencies. 329 3.4 OSPF Protocol Packet processing 331 Since a secondary interface shares the ip address of its 332 corresponding primary interface, OSPF protocol packet processing 333 needs a minor adjustment. For broadcast, NBMA, and point-to- 334 multipoint links, the packet's IP source address is required to be on 335 the same network as the receiving OSPF primary interface. This can be 336 verified by comparing the packet's IP source address to the primary 337 interface's source address, after masking both addresses with the 338 interface mask (See [OSPF] Section 8.2). The Area Id is used to 339 distinguish the primary interface from its configured secondary 340 interfaces. Any router with a configured virtual link cannot 341 configure Area 0 in the SecondaryAreas parameters of any interface 342 belonging to the link's transit area. Otherwise the virtual link 343 would not be distinguishable from an Area 0 secondary link. 345 3.5 Designated Router Election and Function 347 The election of the Designated Router and the Backup Designated 348 router for a secondary link over a secondary NBMA network proceeds as 349 described in [OSPF] Section 9.4. Eligibility is determined from the 350 Designated Router priorities configured for each secondary area as 351 well as the priorities defined in received secondary Hellos from 352 secondary neighbors. Note that the Designated Router for a secondary 353 link does not originate a network-LSA (Type-2) into its secondary 354 area for the secondary NBMA network over which the secondary link 355 bridges. All secondary links are advertised as point-to-point links 356 (see Section 6.0). The only function of a secondary link's Designated 357 Router is flooding optimization. 359 4.0 Synchronizing Secondary Areas using Mlink Type 9 LSAs 361 Mlink Type 9 LSAs are used to discover and start secondary neighbor 362 relationships. If the primary interface is of broadcast or NBMA type 363 then all of its candidate Designated Routers must be opaque capable, 364 even if these routers have no secondary areas configured for their 365 link to the broadcast or NBMA network. Otherwise mlink Type 9 LSAs 366 may not propagate to all potential routers capable of forming 367 secondary adjacencies over the network. Note that these candidate 368 Designated Routers do not have to support OSPF Multiple Area Links, 369 but they do have to be opaque capable in order to flood mlink Type 9 370 LSAs to their adjacent primary neighbors who may or may not support 371 OSPF Multiple Area Links. 373 The format of the mlink Type 9 LSA is detailed in Appendix B. Any 374 router which has an interface with a non-empty SecondaryAreas 375 interface parameter must originate across the primary interface an 376 mlink Type 9 LSA for each configured secondary area. If an 377 interface's SecondaryAreas parameter is null, then no mlink Type 9 378 LSAs will be advertised. A secondary area's mlink Type 9 LSA 379 minimally lists as opaque information the secondary link's Area ID, 380 plus, if available, its IP address and, if required, its Designated 381 Router priority. A new mlink Type 9 LSA is reoriginated following 382 expiration of its LSRefreshInterval or when changes occur in the 383 secondary link's router priority. Mlink Type 9 LSAs are only flooded 384 at the routers fully adjacent primary neighbors. If a secondary area 385 is removed from a primary interface's configured secondary areas, its 386 locally originated mlink Type 9 LSA should be flushed. 388 The mlink Type 9 LSA of each of the primary interface's secondary 389 areas must have a unique opaque ID. The last 24 bits of the Secondary 390 Area ID will normally produce unique Opaque IDs. When it doesn't, 391 alter the least significant bits until uniqueness is achieved. 393 5.0 Secondary Neighbors 395 An OSPF router converses with its secondary neighbors. Each separate 396 conversation is described by a "secondary neighbor data structure". 397 Conversations between secondary neighbors are bound to the secondary 398 interface and identified by both the Area ID and either the router's 399 OSPF Router ID or its Neighbor IP address (see Section 3.4). Unless 400 discussed below details for the creation and maintenance of secondary 401 neighbors and secondary adjacencies are the same as discussed in 402 [OSPF] Sections 10. 404 5.1 The Secondary Neighbor Data Structure 406 The neighbor data structure for secondary adjacencies is identical to 407 the neighbor data structure for standard OSPF adjacencies. Secondary 408 neighbors are discovered by comparing the Area IDs of the primary 409 interface's received mlink Type 9 LSAs with the secondary areas 410 listed in the interface's SecondaryAreas parameter. For point-to- 411 multipoint and transit networks, the originator of the mlink Type 9 412 LSA should be on the same network as the receiving interface. This 413 can be verified by comparing the mlink Type 9 LSA's IP address field 414 with the IP address of the primary interface, after masking both 415 addresses with the interface mask. For point-to-point and point-to- 416 multipoint secondary network types, a separate neighbor data 417 structure is always built for each new secondary neighbor discovered 418 by a received mlink Type 9 LSA. Since the mlink Type 9 LSA of an NBMA 419 secondary link includes the neighbor's Designated Router priority, 420 its separate secondary neighbor data structure is built only when 421 either the local router or the originating router of the mlink Type 9 422 LSA is DR eligible (see Section 5.4). The Neighbor ID and the 423 Neighbor IP address of the secondary neighbor's data structure are 424 copied from the Advertising Router field and IP Address fields of the 425 mlink Type 9 LSA. 427 5.2 The Secondary Neighbor State Machine 429 While secondary neighbor states are identical to OSPF's neighbor 430 states, there are a few important distinctions in their actions and 431 the events which trigger them. When a primary interface receives an 432 new mlink Type 9 LSA from a primary neighbor, the LSA's content may 433 create a new secondary neighbor, destroy an existing secondary 434 neighbor or modify the state of an existing secondary neighbor. For 435 point-to-point and point-to-multipoint secondary network types, a new 436 secondary neighbor is always established. For NBMA secondary network 437 types, the decision whether or not to create a new secondary neighbor 438 depends on whether either the local router or the originating router 439 are DR eligible (See Section 5.3). A router must clear its own mlink 440 Type 9 LSAs from the database summary list of a primary neighbor 441 during database exchange to ensure that its corresponding secondary 442 neighbor relationships transition out of Down state. A secondary 443 neighbor state machine always passes through Attempt state, even for 444 point-to-point and point-to-multipoint secondary interface network 445 types (See Section 5.3 and 5.4). 447 If an mlink Type 9 LSA ages out, the KillNbr event is executed for 448 the corresponding secondary neighbor, and the LSA should be flushed. 449 If the state of the neighbor is 2-way or higher, the local router 450 should send a Hello packet to the secondary neighbor which omits it 451 from the neighbor list (See Section 5.5). The conditions which cause 452 the execution of the KillNbr and LLDown events for primary neighbors 453 should trigger the same events for any of their corresponding 454 secondary neighbors. 456 Since the formation of secondary neighbors is linked with the 457 database exchange and the link state update of the mlink Type 9 LSAs 458 received across the primary link, the timing of this exchange effects 459 when a secondary neighbor transitions to ExStart state. The mlink 460 Type 9 LSA of a secondary Area 0 should be listed at the top of the 461 database summary list. The mlink Type 9 LSAs of non-backbone 462 secondary areas should be listed at the bottom of the database 463 summary list. These tools mitigate the effect of the database 464 exchange by non-backbone secondary areas on the primary neighbor 465 state machine as it transitions to Full state, while at the same time 466 letting an Area 0 secondary neighbor state machine proceed to Full 467 state roughly in parallel with the primary neighbor state machine. 469 5.3 Receiving Mlink Type 9 Neighbor Discovery LSAs 471 This section explains the detailed processing of a received mlink 472 Type 9 LSA. Note that any mlink Type 9 LSAs received across a 473 secondary interface are simply ignored. Thus two neighbors which 474 don't agree on the primary area will never form either primary or 475 secondary adjacencies. 477 When an mlink Type 9 LSA is acknowledged during a primary neighbor's 478 database exchange or received via link state update, its Secondary 479 Area ID is checked against those listed in the primary interface's 480 SecondaryAreas parameter. If it is not listed processing of this LSA 481 stops. If it is listed, for point-to-multipoint and transit networks 482 the originator of the mlink Type 9 LSA should be on the same network 483 as the receiving interface. This can be verified by comparing the 484 mlink Type 9 LSA's IP address field with the IP address of the 485 primary interface, after masking both addresses with the interface 486 mask. If a match does not occur processing of this LSA stops. 488 Next check for the existence of a secondary neighbor in the current 489 list of secondary neighbors contained in the corresponding secondary 490 interface data structure. If a matching secondary neighbor data 491 structure cannot be found, (i.e. this is the first time the secondary 492 neighbor has been detected), and if the secondary network type is 493 either point-to-point or point-to-multipoint or the secondary network 494 type is NBMA and either the local router or the originating router is 495 DR eligible across the secondary NBMA, then create a secondary 496 neighbor data structure for the neighbor described in the mlink Type 497 9. The Neighbor ID and the Neighbor IP address of the secondary 498 neighbor data structure are copied from the Advertising Router and IP 499 Address fields of the mlink Type 9 LSA. The initial state of the 500 newly created secondary neighbor is set to Down. If the secondary 501 network type is point-to-point or point-to-multipoint, or the 502 secondary network type is NBMA and both the local router and the 503 originating router are DR eligible (as defined the secondary neighbor 504 data structure and the newly received mlink Type 9 LSA) then execute 505 a Start event for the newly created secondary neighbor. 507 5.4 Receiving Secondary Hello Packets 509 The processing of Secondary Hello Packets proceeds as described in 510 [OSPF] Section 10.5 with just a few exceptions. If a Secondary Hello 511 Packet is received from a non-existent secondary neighbor the 512 processing of the Hello Packet stops and the packet is dropped. 513 Secondary neighbor data structures are created by the processing of 514 received mlink Type 9 LSAs (See Section 5.4). If a Secondary Hello 515 Packet is received with a router priority which does not match that 516 of the mlink Type 9 LSA which created the secondary neighbor, a 1- 517 WayReceived event should be executed. 519 6.0 Advertising Secondary Adjacencies 521 A Border router advertises its secondary adjacencies in the router- 522 LSAs of its configured secondary areas as point-to-point links even 523 though they may be secondary NBMA links. Any stub or transit networks 524 shared by the primary link with its secondary links are never 525 advertised in the router-LSAs of its secondary areas. This allows 526 these stub and transit networks to retain a single area identity. 527 Noting that a secondary interface does share the IP address of its 528 corresponding primary interface, when adding the secondary link to 529 the router LSA [OSPF] Section 12.4.1.1 is reduced to simply 531 If a neighboring router has formed a secondary adjacency then add 532 a type 1 (point-to-point) link for this adjacency. Its Link ID 533 should be set to the Router ID of the neighboring router. If the 534 corresponding primary interface is numbered, the Link Data should 535 specify the primary interface's IP address. If the primary 536 interface is unnumbered, the Link Data field should specify the 537 interface's MIB-II [MIB] ifIndex value. The cost should be set to 538 the configured output cost of the corresponding secondary 539 interface. 541 7.0 The Shortest Path First Calculation 543 Since secondary links appear in the link state data base of an area 544 as point-to-point links there is no change required in the Shortest 545 Path First (SPF) calculation, except on those border routers where 546 they are configured. Border routers do not include in a secondary 547 area's SPF tree any network which one of its secondary adjacencies 548 transit. This ensures synchronization of the SPF tree amongst the 549 secondary area's other routers. However border routers do use the IP 550 addresses stored in their secondary neighbors' router-LSAs for 551 determining a destination's next hop across a secondary link when the 552 associated interface connects to a point-to-multipoint or transit 553 network. In this case the outgoing interface is derived directly from 554 the destination router's next hop IP address. 556 8.0 Flushing Secondary Adjacencies 558 Secondary adjacencies are flushed from the link state database of a 559 secondary area when their neighbors transition down from Full state, 560 just as with normal OSPF adjacencies. A new router-LSA is built for 561 the secondary area and flooded out all of the secondary area's 562 primary and secondary interfaces. Finally the SPF calculation is 563 performed to reflect the new link state topology. 565 9.0 Security Considerations 567 Security issues are not discussed in this memo. 569 10.0 Acknowledgments 571 This document was produced by the OSPF Working Group, chaired by John 572 Moy. Most notably, Acee Lindem, Redback Networks, provided 573 outstanding input which substantially simplified this document from 574 its previous incarnations. 576 11.0 References 578 [MIB] McCloghrie, K., and M. Rose, "Management Information Base for 579 network management of TCP/IP-based internets: MIB-II", STD 580 17, RFC 1213, Hughes LAN Systems, Performance Systems 581 International, March 1991. 583 [OPAQ] Coltun, Rob, "The OSPF Opaque LSA Option", FORE Systems, 584 August 1998. 586 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, Ascend Communications, 587 Inc., April 1998. 589 12.0 Author's Address 591 Pat Murphy 592 US Geological Survey 593 345 Middlefield Road, Mail Stop 870 594 Menlo Park, California 94560 596 Phone: (650)329-4044 597 EMail: pmurphy@noc.usgs.net 599 Appendix A. Router-LSAs 601 Router-LSAs are Type 1 LSAs. Each router in an area originates a 602 router-LSA. The router-LSA describes the state and cost of the 603 router's links (i.e., interfaces) to the area. All of the router's 604 links to an area, including secondary links, must be described in a 605 single router-LSA. For details concerning the construction of 606 router-LSAs see this document's Section 6.0 and [OSPF] Section 607 12.4.1. 609 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | LS age | Options | 1 | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Link State ID | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Advertising Router | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | LS sequence number | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | LS checksum | length | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | 0 |V|E|B| 0 | # links | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Link ID | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Link Data | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Type | # TOS | metric | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | ... | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | TOS | 0 | TOS metric | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Link ID | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Link Data | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | ... | 640 In router-LSAs, the Link State ID field is set to the router's OSPF 641 Router ID. Router-LSAs are flooded throughout a single area only. 643 bit V 644 When set, the router is an endpoint of one or more fully 645 adjacent virtual links having the described area as its 646 transit area (V is for virtual link endpoint). 648 bit E 649 When set, the router is an AS boundary router (E is for 650 external). 652 bit B 653 When set, the router is an area border router (B is for 654 border). 656 bit W 657 When set, the router is a wild-card multicast receiver (W is 658 for wild). 660 bit Nt 661 When set, the router is a NSSA border router which translates 662 type-7 LSAs into type-5 LSAs (Nt is for NSSA translation). 664 # links 665 The number of router links described in this LSA. This must be 666 the total collection of router links (i.e., interfaces) to the 667 area including a separate entry for each fully adjacent 668 secondary neighbor, regardless of its secondary link's network 669 type. 671 The following fields are used to describe each router link (i.e., 672 interface). Each router link is typed (see the below Type field). The 673 Type field indicates the kind of link being described. It may be a 674 link to a transit network, to another router or to a stub network. 675 The values of all the other fields describing a router link depend on 676 the link's Type. For example, each link has an associated 32-bit Link 677 Data field. For links to stub networks this field specifies the 678 network's IP address mask. For other link types the Link Data field 679 specifies the router interface's IP address. 681 Type 682 A quick description of the router link for one of the 683 following. Note that host routes are classified as links to 684 stub networks with network mask of 0xffffffff. Secondary 685 router links are always type 1 point-to-point even when they 686 have secondary NBMA network type. 688 Type Description 689 __________________________________________________ 690 1 Point-to-point connection to another router 691 2 Connection to a transit network 692 3 Connection to a stub network 693 4 Virtual link 695 Link ID 696 Identifies the object that this router link connects to. Its 697 value depends on the link's Type. When connecting to an object 698 that also originates an LSA (i.e., another router or a transit 699 network) the Link ID is equal to the neighboring LSA's Link 700 State ID. This provides the key for looking up the 701 neighboring LSA in the link state database during the routing 702 table calculation. See [OSPF] Section 12.2 for more details. 704 Type Link ID 705 ______________________________________ 706 1 Neighboring router's Router ID 707 2 IP address of Designated Router 708 3 IP network/subnet number 709 4 Neighboring router's Router ID 711 Link Data 712 Value again depends on the link's Type field. For connections 713 to stub networks, Link Data specifies the network's IP address 714 mask. For unnumbered point-to-point connections, it specifies 715 the interface's MIB-II [MIB] ifIndex value. For the other link 716 types it specifies the router interface's IP address. This 717 latter piece of information is needed during the routing table 718 build process, when calculating the IP address of the next 719 hop. Recall a secondary router link (Type 1) shares the IP 720 address of its corresponding primary interface, if it exists. 721 Otherwise it is an unnumbered point-to-point connection. See 722 Section 6.0 of this document and [OSPF] Section 16.1.1 for 723 more details. 725 # TOS 726 The number of different TOS metrics given for this link, not 727 counting the required link metric (referred to as the TOS 0 728 metric in [1583]). For example, if no additional TOS metrics 729 are given, this field is set to 0. Secondary Areas do not use 730 TOS. 732 metric 733 The cost of using this router link. For secondary links the 734 cost is specified in the secondary interface data structure. 736 Additional TOS-specific information may also be included, for 737 backward compatibility with previous versions of the OSPF 738 specification ([1583]). Within each link, and for each desired TOS, 739 TOS-specific link information may be encoded as follows: 741 TOS 742 IP Type of Service that this metric refers to. The encoding of 743 TOS in OSPF LSAs is described in [1583] Section 12.3. 745 TOS metric 746 TOS-specific metric information. 748 Appendix B. Mlink Type 9 Neighbor Discovery LSAs 750 Mlink Type 9 LSAs are used directly by OSPF to distribute lists of 751 candidate secondary areas among neighboring routers. Mlink Type 9 752 LSAs are flooded across the primary interface. The flooding scope of 753 an mlink Type 9 LSAs is link-local, which means mlink Type 9 LSAs are 754 never flooded beyond the local (sub)network or router link. 756 Sections 4.0 and 5.3 of this document describe the purpose of these 757 mlink Type 9 LSAs in more detail. 759 0 1 2 3 760 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 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | LS age | Options | 9 | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Opaque Type | Opaque ID | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Advertising Router | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | LS Sequence Number | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | LS checksum | Length | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Secondary Area ID | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | IP Address | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Sec Rtr Pri | 0 | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 Syntax of the mlink Type 9 LSA's Link-State ID 781 The link-state ID of an mlink Type 9 LSA is divided into an Opaque 782 Type field (the first 8 bits), which has value mlink, and the 783 Opaque ID (the remaining 24 bits). The mlink Type 9 LSA of each 784 of the primary interface's secondary areas must have a unique 785 opaque ID. The last 24 bits of the Secondary Area ID will normally 786 produce unique Opaque IDs. When it doesn't, alter the least 787 significant bits until uniqueness is achieved. 789 Options 790 The optional capabilities supported by this router for the 791 primary area, as documented in [OSPF] Section A.2. 793 Secondary Area ID 794 The area ID of the area across which a neighboring router may 795 form a secondary adjacency. 797 IP Address 798 The IP Address of the secondary area's corresponding primary 799 interface. If the primary interface has unnumbered point-to- 800 point type, then IP Address should be set to 0. 802 Sec Rtr Pri 803 This router's Designated Router priority for a secondary link 804 across a transit network. This parameter is used during the 805 secondary links (Backup) Designated Router election. If set to 806 0, the router will be ineligible to become the (Backup) 807 Designated Router for this secondary link. 809 Appendix C. Interface Data Structure 811 Chapter 9 in the OSPF specification documents the interface data 812 structure and the data items which are included in it. Section 3.1 of 813 this document defines a new interface configuration parameter called 814 SecondaryAreas which supports OSPF Multiple Area Links. The 815 SecondaryAreas interface parameter lists a set of areas which may 816 form secondary adjacencies across the interface. The SecondaryAreas 817 parameter's default setting is null. If a virtual link is configured 818 across a transit area linked to an interface, then Area 0 may not be 819 configured in the interface's SecondaryAreas parameter. 821 Each area listed in the SecondaryAreas interface parameter should 822 have a secondary interface data structure. With the exception of Area 823 ID all of secondary interface parameters which are usually 824 configurable, such as interface cost, authentication parameters and 825 Designated Router priority, default to the values assigned to the 826 primary interface. Furthermore, except for the Area ID, IP interface 827 address and mask, all configurable interface parameters should be 828 separately configurable for each secondary interface. The 829 SecondaryAreas parameter in a secondary interface data structure is 830 always null.