idnits 2.17.1 draft-ietf-ospf-mlinks-00.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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 (July 1998) is 9416 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) == Unused Reference: 'OPAQ' is defined on line 496, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'OPAQ' ** Obsolete normative reference: RFC 1583 (Obsoleted by RFC 2178) Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 4 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: December 1998 July 1998 5 File name: draft-ietf-ospf-mlinks-00.txt 7 OSPF Multiple Area Links 9 Status of this Memo 11 This document is an Internet-Draft. 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 To learn the current status of any Internet-Draft, please check the 22 "1id- abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Table Of Contents 29 1.0 Abstract ................................................. 1 30 2.0 Overview ................................................. 2 31 2.1 Requirement for OSPF Multiple Area Links ................. 2 32 2.2 Proposed Solution ........................................ 3 33 3.0 Implementation Details ................................... 6 34 3.1 SecondaryAreas Interface parameter ....................... 6 35 3.2 Advertising Secondary Areas .............................. 6 36 3.3 Forming Secondary Adjacencies ............................ 7 37 3.4 Advertising Secondary Adjacencies ........................ 7 38 3.5 Secondary Area Link State Data Base Exchange and Update .. 8 39 3.6 The Shortest Path First Calculation ...................... 9 40 3.7 Flushing Secondary Adjacencies ........................... 9 41 4.0 Acknowledgments .......................................... 10 42 5.0 References ............................................... 10 43 6.0 Security Considerations .................................. 10 44 7.0 Authors' Addresses ....................................... 10 45 Appendix A: Router LSAs ...................................... 11 46 Appendix B: mlink Opaque LSAs ................................ 13 47 Appendix C: Configuration Parameters ......................... 14 49 1.0 Abstract 51 This memo describes an option to the OSPF Version 2 specification 52 which allows multiple areas to share the same link. This option adds 53 no additional link state flooding over shared links other than the 54 normal link state database exchange and update originating from the 55 link's configured primary area. The option applies to standard areas, 56 stub areas, and NSSAreas. It eliminates the excess Area 0 link state 57 baggage that accompanies the use of virtual links as currently 58 practiced when configuring similar transits for standard OSPF areas. 59 Routers with this option configured are backward compatible with 60 routers running the standard OSPF Version 2 compliant implementation 61 as defined in RFC 2328, and can be restricted to a subset of the OSPF 62 routing domain. This option is applied only on OSPF border routers. 64 Implementation of OSPF multiple area links requires a modification to 65 the OSPF interface data structure which allows each interface of a 66 border router to be connected to multiple areas. One area is always 67 configured as the interface's primary area. Any additional areas 68 which are configured for an interface are called the interface's 69 secondary areas. Two adjacent border routers with mutually shared 70 secondary areas may transit a secondary area's intra-area traffic 71 over the adjacency. A typical application is a stub area or NSSArea 72 which is dual homed to the Area 0 backbone and loosely joined by an 73 internal slow speed link. If there exists a high speed Area 0 link 74 between two of the stub area's border routers, this option allows the 75 stub area's intra-area traffic to route across this high speed area 0 76 link. The current specification forces traffic to prefer the intra- 77 area path over the slow speed link. 79 Another not so common application makes Area 0 the secondary area 80 over a local high speed LAN link with the primary area a local stub 81 or NSSArea. Here Area 0 is not primary due to topological 82 limitations which restrict its applicability. E.g. the local LAN link 83 could be a campus backbone with dozens of routers on it, all part of 84 the same NSSArea. 86 Please send comments to ospf@discuss.microsoft.com. 88 2.0 Overview 90 2.1 Requirement for OSPF Multiple Area Links 92 Large corporate networks in todays modern Internet invest tremendous 93 human and equipment resources, coupled with sizable budget, into 94 their backbone infrastructure. Their regional networks are normally 95 not so fortunate, and must multi-home to the backbone in order to 96 take advantage of the backbone's high speed and high reliability 97 network links. Performance over a T1 link can pale by comparison to 98 performance over a DS3 or OC3 backbone link. Indeed, even a high 99 speed 100 megabit LAN link can carry an order of magnitude more 100 traffic than a standard 10 megabit link. Large corporate networks 101 have sizable backbone routing tables and routinely use stub areas and 102 NSSAreas. Under the current OSPF specification intra-area routes are 103 always preferred over inter-area routes even when the traffic is 104 sourced from and destined to the same non-backbone OSPF area. 106 Consider the following typical OSPF example: 108 A0-----------Area 0 link------------B0-------N1 109 | DS3 | 110 | | 111 |NSSArea 1 link NSSArea 1 link| 112 | T1 T1 | 113 | | 114 | | 115 A1---------NSSArea 1 link-----------B1-------M1 116 T1 118 where A0 and B0 are border routers attached to NSSArea 1. A1 and B1 119 are internal routers in NSSArea 1. N1 and M1 are standard ethernet 120 networks in NSSArea 1 directly attached to B0 and B1 respectively. 121 Assume all T1 links have an OSPF cost of 28 in both directions, N1 122 and M1 are attached with interface costs 2. The DS3 link has an OSPF 123 cost of 1. All costs are symmetric. Under the current OSPF 124 specification the preferred path between A0 and M1 is 126 A0<->A1<->B1<->M1 128 with OSPF cost 58, even though there exists a more preferred path 129 through B0 namely 131 A0<->B0<->B1<->M1 133 with OSPF cost 31. Indeed the DS3 link between A0 and B0 has the 134 potential of making the performance between A0 and B1 approach that 135 of a single T1. 137 Consider also the NSSArea 1 OSPF preferred path between A1 and N1, 139 A1<->B1<->B0<->N1, 141 with cost 58. Again there exists a more preferred path through the 142 link between A0 and B0, namely 144 A1<->A0<->B0<->N1 146 with cost 31. This link also has the potential of performing at 147 single hop T1 speeds. Under the current OSPF specification NSSArea 148 1's router A1 does not even see this path to N1 since it has no 149 knowledge of Area 0's topology. A0, on the other hand, would at 150 lease see the summary LSA of N1, but still cannot take advantage of 151 it due to OSPF intra-area path preference. 153 What is needed is a tool which makes the Area 0 link between A0 and 154 B0 visible in NSSArea 1. Virtual links are not an option since 155 virtual links don't work over NSSAreas. If the link between A0 and B0 156 were part of NSSArea 1, path preference would be optimal as the DS3 157 path would be intra-area for NSSArea 1. This cannot be the non- 158 backbone equivalent of an Area 0 virtual link. Excessive use of such 159 a feature would negate the purpose of the Area 0 backbone. 161 2.2 Proposed Solution 163 OSPF multiple area links provide the capability of allowing multiple 164 areas to use the same link/path between two border routers for 165 intra-area traffic. Traffic may originate from inside each of the 166 configured areas, as every router in the configured areas sees the 167 link/path as part of its link state topology. Only areas which are 168 dual homed to Area 0 may take advantage of this option, since any 169 router with multiple directly attached areas must be in Area 0 and it 170 takes at least two such border routers to create a multiple area 171 link. 173 The current OSPF specification only allows one area per interface. 174 Thus, should an Area L dual-home to two Area 0 border routers which 175 are adjacent over another Area K's router<->router link or router<- 176 >network link, the adjacent link over Area K is not seen inside Area 177 L, even though the two border routers exist physically adjacent 178 within Area L. This coupled with intra-area route preference prevents 179 Area L from utilizing Area K's adjacent link. 181 The softening of this restriction is facilitated by the addition of a 182 new parameter to the interface data structure called SecondaryAreas. 183 The SecondaryAreas interface parameter is a self-defining structure 184 containing a list of Area Ids for additional areas in which the 185 interface also belongs, along with their associated OSPF costs. The 186 areas listed in this parameter are called the interface's secondary 187 areas, as opposed to the interface's configured Area ID, hereafter 188 called the primary area. For each secondary area listed in the 189 SecondaryAreas parameter there is a list of neighboring Router Ids 190 which have formed adjacencies for the secondary area across the 191 interface's directly attached network or router link. These 192 adjacencies are called secondary adjacencies. Secondary adjacencies 193 are formed during the primary area's link state data base exchange 194 and update as defined in Sections 3.2 and 3.3. 196 A type 9 Opaque LSA is used to exchange/update the interface's 197 secondary areas with adjacent Opaque capable border routers. Until an 198 opaque type is assigned for this option, it will be simply referred 199 to as an mlink type 9 opaque LSA. A type 9 opaque LSA is used because 200 the flooding scope of the mlink type 9 opaque LSA needs to be 201 restricted to those routers directly attached to a common network or 202 router link. Each router will list its configured secondary addresses 203 as defined by the interface's SecondaryAreas parameter in its mlink 204 type 9 opaque LSA. The mlink type 9 opaque LSA is propagated during 205 the primary area's link state data base exchange and update with its 206 fully adjacent neighbors. If a router A receives an mlink type 9 207 opaque LSA from an adjacent router B during primary area K's link 208 state data base exchange, then router A and B form a secondary 209 adjacency in area L if and only if 211 1) Area L is listed in the interface's SecondaryArea parameter. 213 2) Area L is listed in router B's received mlink type 9 opaque 214 LSA. 216 3) Router A contains a type 1 (router) LSA from router B in Area 217 L's link state data base. 219 If routers A and B form a secondary adjacency then the router ID of 220 router B is added to Area L's list of secondary adjacencies for the 221 interface. 223 Secondary adjacencies are either point-to-point or point-to- 224 multipoint. Any intervening transit networks always belong to the 225 interface's primary area. There is no network LSA for a secondary 226 adjacency's intervening transit network in the secondary area. Hence 227 all secondary adjacencies for Area L must be advertised in router A's 228 type 1 (router) LSA with unnumbered point-to-point type. 230 During the Dykstra SPF calculation the LSAs for secondary adjacencies 231 look like unnumbered point-to-point links, except on border routers 232 where they originate. A Border router never includes in a secondary 233 area's SPF tree any network across which one of its secondary 234 adjacencies span. This ensures synchronization of the SPF tree 235 amongst the secondary area's routers. However border routers do use 236 the IP addresses stored in neighboring border router LSAs for 237 determining link paths across a multi-access secondary adjacency. 239 There is no secondary link state data base exchange or update over 240 secondary adjacencies. Instead, these adjacencies rely on the 241 secondary area's base topology (minus the secondary links) for 242 flooding link state information regarding an area's secondary 243 adjacencies. The reasons for not attempting a secondary link state 244 data base exchange/update are two fold. First, the goal of this 245 document is to establish a transit for multiple areas over a single 246 link without imposing the additional traffic load caused by passing 247 the secondary area's link state database over that link. Second the 248 added complexity of synchronizing multiple secondary area link state 249 databases over the link is unnecessary when the primary area is the 250 Area 0 backbone. Should the secondary area partition, traffic between 251 the two parts of the partitioned secondary area would still use the 252 secondary adjacent link via OSPF inter-area routing. 254 It is true that routing between the different parts of a secondary 255 area partitioned by a defunct secondary adjacency over an Area 0 link 256 would be based on the inter-area route computation results from 257 processing summary links. Summary-range aggregation may over simplify 258 routing between the different parts of a partitioned area. However 259 this is no different that what exists under the current OSPF base 260 standards. Furthermore, the proper partitioning of a secondary area's 261 assigned address space not only allows the summary-range aggregates 262 to effect proper routing during topological failures, but it also 263 promotes more cost effective and efficient routing even when 264 secondary areas are whole. 266 Consider now the example mentioned in Section 2.3 and assume Area 1 267 is configured as a secondary area over the Area 0 link between A0 and 268 B0. The NSSArea 1 intra-area shortest path first tree computed by the 269 Dykstra calculation now includes the DS3 link between A0 and B0 with 270 a cost of 1. Given that all four routers possess link state 271 advertisements for the link between A0 and B0 in NSSArea 1, the path 272 between A0 and M1 is now 274 A0<->B0<->B1<->M1 276 and the path between A1 and N1 is 278 A1<->A0<->B0<->N1 280 Furthermore, should the link between A1 and B1 fail terminating the 281 NSSArea 1's secondary adjacency between A0 and B0, the path between 282 A0 and M1 would still be 284 A0<->B0<->B1<->M1, 286 as the summary LSA for M1 originating from B0 forms an inter-area 287 path to M1. 289 3.0 Implementation Details 291 3.1 SecondaryAreas Interface parameter 293 A new parameter called SecondaryAreas is added to the OSPF interface 294 data structure. Implementations must support the manual configuration 295 of this parameter. The SecondaryAreas interface parameter lists the 296 set of Areas which can form secondary adjacencies over the interface, 297 complete with their secondary area interface costs. By default a 298 secondary area's interface cost is set to the value of the 299 interface's primary area cost. Only those Areas listed in the 300 SecondaryAreas interface parameter are candidate areas for the 301 interface's secondary adjacencies. If the SecondaryAreas interface 302 parameter has a null list, then no secondary areas are configured for 303 this interface and no secondary adjacencies can be formed over the 304 interface. 306 For each secondary area listed in the SecondaryAreas interface 307 parameter, there is a list of Router Ids which have formed secondary 308 adjacencies to the router over the interface. These Routers Ids 309 should also be listed in the interface's list of neighboring routers. 310 If the list of Router Ids is null, then the interface has no 311 secondary adjacencies for this secondary area. This list is 312 populated as defined in Section 3.3 below. 314 3.2 Advertising Secondary Areas 316 All routers which support secondary areas must also be opaque 317 capable. If the interface is of broadcast type, then all candidate 318 designated routers must be opaque capable, even if they have no 319 secondary areas configured for the interface which connects to the 320 broadcast transit network. Otherwise type 9 opaque LSAs, which are 321 used by this option, will not propagate to all potential routers 322 capable of forming secondary adjacencies over the broadcast transit 323 network. Note that candidate designated routers do not have to 324 support OSPF multiple area links, but they do have to be opaque 325 capable in order to flood the type 9 opaque LSA to their adjacent 326 neighbors who may or may not support OSPF multiple area links. 328 Any router which has an interface with a non-empty SecondaryAreas 329 interface parameter must advertise a type 9 opaque LSA with opaque 330 type mlink to the interface's fully adjacent neighbors. The mlink 331 type 9 opaque LSA contains the Area Ids listed in the interface's 332 SecondaryAreas parameter as Opaque Information. See Appendix B for 333 details. If an interface's SecondaryAreas parameter is null, then the 334 mlink type 9 opaque LSA should not be advertised. 336 By default, the mlink opaque type sets it opaque ID to the last 24 337 bits of the interface's IP address, if it has one. In the case of 338 unnumbered point-to-point connections, the mlink opaque ID is set to 339 the last 24 bits of the interface's MIB-II [MIB] ifIndex value. All 340 implementations should also support the manual configuration of an 341 interface's mlink opaque ID in the rare instance this default schema 342 results in duplication. 344 3.3 Forming Secondary Adjacencies 346 Two border routers A and B in area L may form a secondary adjacency 347 across an interface, whose primary area is K, under the following 348 conditions: 350 (a) Routers A and B are fully adjacent across the interface's 351 primary area K or they share a common area K full adjacency 352 with the interface's designated router. 354 (b) Routers A and B see router LSAs (type-1) for each other in 355 Area L's link state data base. 357 (c) Routers A and B have exchanged/updated mlink type 9 opaque 358 LSAs across the interface both of which contain Area L as a 359 candidate secondary area. 361 When all three conditions are met, a secondary adjacency is formed 362 between routers A and B across the interface's primary area. There is 363 no particular ordering of events. Either (a), (b), or (c) can trigger 364 the event which forms the secondary adjacency, provided the other two 365 conditions have already been met. 367 3.4 Advertising Secondary Adjacencies 369 Border routers advertise their secondary adjacencies in their router 370 LSAs as unnumbered point-to-point links even though they may be 371 numbered point-to-point links, point-to-multipoint links, or transit 372 network links in their associated interface's primary area. This 373 allows their interconnecting networks to retain a single area 374 identity, thus avoiding the inevitable problems which would occur 375 with duplicate summary links advertisements and aggregation. It also 376 makes configuration and deployment seamless. 378 As unnumbered point-to-point links, all secondary adjacencies have 379 link type 1. The building of the router LSA is described in [OSPF] 380 Section 12.4.1. For the purpose of building the router LSA, an 381 interface belongs to both its primary area and its secondary areas. 382 With this in mind, no change is required to [OSPF] Section 12.4.1. 384 Even though secondary adjacencies are considered unnumbered point- 385 to-point links, for the purpose of defining Link Data in the type 1 386 (router) LSA (see Appendix A) we allow them to use the interface's IP 387 address. For secondary adjacencies [OSPF] Section 12.4.1.1 is reduced 388 to simply 390 If a neighboring router has formed a secondary adjacency then add 391 a Type 1 link (point-to-point). The Link ID should be set to the 392 Router ID of the neighboring router. If the interface is numbered, 393 the Link Data should specify the IP interface address. For 394 unnumbered point-to-point networks, the Link Data field should 395 specify the interface's MIB-II [MIB] ifIndex value. The cost 396 should be set to the secondary area's cost of the point-to-point 397 interface as defined in the interface's SecondaryAreas parameter. 399 By not adding the type 3 links noted in [OSPF] Section 12.4.1. 400 secondary adjacencies retain the look and feel of an unnumbered 401 point-to-point links to the remaining routers in the secondary area, 402 even though they may configure their link data with the interface's 403 IP address. 405 3.5 Secondary Area Link State Data Base Exchange and Update 407 There is no link state data base exchange or update across a 408 secondary adjacency. Only the interface's primary area synchronizes 409 its link state data base with the interface's neighboring routers. 410 Instead, secondary areas rely on their base topology (i.e. the 411 topology without the secondary links), for complete flooding and 412 synchronization of the link state data base throughout the secondary 413 area. If the primary area is the area 0 backbone this is not a 414 problem, since the routing table entries generated by the secondary 415 areas summary links will forward packets when a secondary area's base 416 topology partitions in such a way that its secondary adjacencies are 417 dropped. 419 If the primary area is non-zero, then a simple IP over IP tunnel may 420 be configured for the secondary across the physical link. This tunnel 421 will perform link state data base synchronization for the secondary 422 area across the interface. The IP tunnel is not part of this 423 specification, but clearly it is advantageous to any OSPF multiple 424 area links implementation if tunneling of IP over IP is supported. 425 Note that if the tunnel is suitably configured with a high OSPF cost, 426 it would never be used for forwarding packets other than those 427 required for link state data base exchange and update. Moreover the 428 tunnel will always exist as long as the secondary adjacency's 429 physical link is active. 431 3.6 The Shortest Path First Calculation 433 Since secondary links appear in the link state data base of an area 434 as unnumbered point-to-point links there is no change required in the 435 Shortest Path First (SPF) calculation, except on those border routers 436 where they are configured. Border routers do not include in a 437 secondary area's SPF tree any network which one of its secondary 438 adjacencies transit. This ensures synchronization of the SPF tree 439 amongst the secondary area's routers. However border routers do use 440 the IP addresses stored in their secondary neighbors' type-1 (router) 441 LSAs for determining the destination next hop across a secondary 442 adjacency when the associated interface connects the destination 443 router via a point-to-multipoint link or transit network link. In 444 this case the outgoing interface is derived directly from the 445 destination router's next hop IP address. 447 3.7 Flushing Secondary Adjacencies 449 The dropping and flushing of secondary adjacencies from the link 450 state database of a secondary area is triggered by any of the 451 following events: 453 The secondary area is manually purged from the interface's 454 SecondaryAreas parameter. 456 An adjacent router looses its primary area adjacency. Note that 457 over a multi-access network termination happens when a neighboring 458 router ceases to be listed in the Designated Router's list of 459 neighbors. 461 The secondary area is no longer listed in the adjacent router's 462 mlink type 9 opaque LSA. 464 The adjacent router's mlink type 9 opaque LSA is flushed from the 465 primary area or exceeds MAXAge. 467 The adjacent router's type 1 (router) LSA is flushed from the 468 secondary area or exceeds MAXAge. In other words, the secondary 469 area has partitioned with the two formerly adjacent routers now in 470 separate parts. 472 When any of these events occur the interface's SecondaryAreas 473 parameter is updated to purge the adjacency. A new router LSA is 474 built for the secondary area and flooded out those interfaces for 475 which the secondary area is primary. The SPF calculation is done to 476 reflect the new link state topology. 478 4.0 Acknowledgments 480 This document was produced by the OSPF Working Group, chaired by John 481 Moy. 483 In addition, the comments of the following individuals are also 484 acknowledged: 486 Derek Yeung Cisco Systems 487 Rob Colton Fore Systems 489 5.0 References 491 [MIB] McCloghrie, K., and M. Rose, "Management Information Base for 492 network management of TCP/IP-based internets: MIB-II", STD 493 17, RFC 1213, Hughes LAN Systems, Performance Systems 494 International, March 1991. 496 [OPAQ] Coltun, Rob, "The OSPF Opaque LSA Option", FORE Systems, 497 August 1998. 499 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, Ascend Communications, 500 Inc., April 1998. 502 [1583] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 503 1994. 505 6.0 Security Considerations 507 Security issues are not discussed in this memo. 509 7.0 Author's Address 511 Pat Murphy 512 US Geological Survey 513 345 Middlefield Road, Mail Stop 870 514 Menlo Park, California 94560 516 Phone: (650)329-4044 517 EMail: pmurphy@noc.doi.net 519 Appendix A. Router-LSAs 521 Router-LSAs are Type 1 LSAs. Each router in an area originates a router-LSA. 522 The router-LSA describes the state and cost of the router's links (i.e., 523 interfaces) to the area. All of the router's links, including secondary 524 links, to an area must be described in a single router-LSA. For details 525 concerning the construction of router-LSAs, see this document's Section 3.6 526 and [OSPF] Section 12.4.1. 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | LS age | Options | 1 | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Link State ID | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Advertising Router | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | LS sequence number | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | LS checksum | length | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | 0 |V|E|B| 0 | # links | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Link ID | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Link Data | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Type | # TOS | metric | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | ... | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | TOS | 0 | TOS metric | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Link ID | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Link Data | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | ... | 559 In router-LSAs, the Link State ID field is set to the router's OSPF 560 Router ID. Router-LSAs are flooded throughout a single area only. 562 bit V 563 When set, the router is an endpoint of one or more fully 564 adjacent virtual links having the described area as Transit 565 area (V is for virtual link endpoint). 567 bit E 568 When set, the router is an AS boundary router (E is for 569 external). 571 bit B 572 When set, the router is an area border router (B is for 573 border). 575 bit W 576 When set, the router is a wild-card multicast receiver (W is 577 for for wild). 579 bit Nt 580 When set, the router is a NSSA border router which translates 581 type-7 LSAs into type-5 LSAs (Nt is for NSSA translation). 583 # links 584 The number of router links described in this LSA. This must be 585 the total collection of router links (i.e., interfaces) to the 586 area. 588 The following fields are used to describe each router link (i.e., 589 interface). Each router link is typed (see the below Type field). The 590 Type field indicates the kind of link being described. It may be a 591 link to a transit network, to another router or to a stub network. 592 The values of all the other fields describing a router link depend on 593 the link's Type. For example, each link has an associated 32-bit Link 594 Data field. For links to stub networks this field specifies the 595 network's IP address mask. For other link types the Link Data field 596 specifies the router interface's IP address. 598 Type 599 A quick description of the router link for one of the 600 following. Note that host routes are classified as links to 601 stub networks with network mask of 0xffffffff. 603 Type Description 604 __________________________________________________ 605 1 Point-to-point connection to another router 606 2 Connection to a transit network 607 3 Connection to a stub network 608 4 Virtual link 610 Link ID 611 Identifies the object that this router link connects to. Value 612 depends on the link's Type. When connecting to an object that 613 also originates an LSA (i.e., another router or a transit 614 network) the Link ID is equal to the neighboring LSA's Link 615 State ID. Secondary links area are always type 1 point-to- 616 point regardless of the type of their associated primary area. 617 This provides the key for looking up the neighboring LSA in 618 the link state database during the routing table calculation. 619 See [OSPF] Section 12.2 for more details. 621 Type Link ID 622 ______________________________________ 623 1 Neighboring router's Router ID 624 2 IP address of Designated Router 625 3 IP network/subnet number 626 4 Neighboring router's Router ID 628 Link Data 629 Value again depends on the link's Type field. For connections 630 to stub networks, Link Data specifies the network's IP address 631 mask. For unnumbered point-to-point connections, it specifies 632 the interface's MIB-II [MIB] ifIndex value. For the other link 633 types it specifies the router interface's IP address. This 634 latter piece of information is needed during the routing table 635 build process, when calculating the IP address of the next 636 hop. Although secondary links are considered unnumbered 637 point-to-point links, they do evaluate Link Data as if they 638 were numbered whenever their interface has an IP address 639 associated with its primary area. See Section 3.6 of this 640 document and [OSPF] Section 16.1.1 for more details. 642 # TOS 643 The number of different TOS metrics given for this link, not 644 counting the required link metric (referred to as the TOS 0 645 metric in [1583]). For example, if no additional TOS metrics 646 are given, this field is set to 0. Secondary Areas may use 647 TOS. 649 metric 650 The cost of using this router link. 652 Additional TOS-specific information may also be included, for 653 backward compatibility with previous versions of the OSPF 654 specification ([1583]). Within each link, and for each desired TOS, 655 TOS TOS-specific link information may be encoded as follows: 657 TOS 658 IP Type of Service that this metric refers to. The encoding of 659 TOS in OSPF LSAs is described in [1583] Section 12.3. 661 TOS metric 662 TOS-specific metric information. 664 Appendix B. mlink Opaque LSA 666 The mlink Opaque LSA is used directly by OSPF to distribute list of 667 candidate secondary areas among neighboring routers. The flooding 668 scope of the mlink type 9 Opaque LSA is link-local, which means mlink 669 LSAs are never forwarded beyond the local (sub)network. 671 Section 3.3 of this document describes the purpose of the mlink 672 Opaque LSA in more detail. 674 0 1 2 3 675 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 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | LS age | Options | Link State | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Opaque Type | Opaque ID | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Advertising Router | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | LS Sequence Number | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | LS checksum | Length | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Secondary Area ID 1 | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | . | 690 | . | 691 | . | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Secondary Area ID n | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 Syntax Of The Opaque LSA's Link-State ID 698 The link-state ID of the mlink Opaque LSA is divided into an 699 Opaque Type field (the first 8 bits), which has value mlink, and 700 the Opaque ID (the remaining 24 bits). The mlink Opaque ID is set 701 to the last 24 bits of the interface's primary area IP address, if 702 it has one. In the case of unnumbered point-to-point connections, 703 the mlink opaque ID is set to the last 24 bits of the interface's 704 MIB-II [MIB] ifIndex value. All implementations should also 705 support the manual configuration of an interface's mlink opaque ID 706 in the rare instance this default schema results in duplication. 708 Appendix C. Interface Data Structure 710 Chapter 9 in the OSPF specification documents the interface data 711 structure and the data items which are included in it. Section 3.1 of 712 this document defines a new configuration parameter called 713 SecondaryAreas which is to be included in support of OSPF multiple 714 area links. Sections 3.2 and 3.4 describe the application of the 715 parameter. 717 In addition, for each secondary area listed in an interface's 718 SecondaryAreas parameter, the interface data structure must maintain 719 a list of Router IDs which have formed secondary adjacencies for this 720 secondary area.