idnits 2.17.1 draft-ietf-ospf-nssa-option-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-18) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 6 months document validity. ** 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. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1.0 Abstract' ) ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2.0 Overview' ) ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** There are 141 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 284 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([MOSPF], [OSPF]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 22 has weird spacing: '... Drafts are ...' == Line 23 has weird spacing: '...cuments of t...' == Line 24 has weird spacing: '...t other group...' == Line 34 has weird spacing: '... Draft direc...' == Line 61 has weird spacing: '... what humor...' == (136 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 1992) is 11508 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'OSPF' on line 490 looks like a reference -- Missing reference section? 'MOSPF' on line 553 looks like a reference Summary: 17 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ------------------------------------------------------------------------------- 3 Internet Draft OSPF NSSA Option October 1992 4 Expiration Date: April 1993 6 The OSPF NSSA Option 8 Rob Coltun 9 Consultant 10 (301) 340-9416 11 rcoltun@ni.umd.edu 13 Vince Fuller 14 BARRNet 15 Stanford University 16 Pine Hall 115 17 Stanford, CA, 94305-4122 18 vaf@Valinor.Stanford.EDU 20 Status of this Memo 22 This document is an Internet Draft. Internet Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its 24 Areas, and its Working Groups. Note that other groups may also 25 distribute working documents as Internet Drafts). 27 Internet Drafts are draft documents valid for a maximum of six 28 months. Internet Drafts may be updated, replaced, or obsoleted by 29 other documents at any time. It is not appropriate to use Inter- 30 net Drafts as reference material or to cite them other than as a 31 "working draft" or "work in progress." 33 Please check the I-D abstract listing contained in each Internet 34 Draft directory to learn the current status of this or any other 35 Internet Draft. 37 Table Of Contents 39 1.0 Abstract ................................................. 2 40 2.0 Overview ................................................. 2 41 2.1 Motivation ............................................... 2 42 2.2 Proposed Solution ........................................ 3 43 3.0 Implementation Details ................................... 5 44 3.1 The N-bit ................................................ 5 45 3.2 Type-7 LSAs .............................................. 5 46 3.3 Originating Type-7 LSAs .................................. 6 47 3.4 Calculating Type-7 AS External Routes .................... 7 48 3.5 Incremental Updates ...................................... 9 49 4.0 Originating Type-5 LSAs .................................. 9 50 4.1 Translating Type-7 LSAs .................................. 9 51 4.2 Flushing Translated Type-7 LSAs .......................... 10 52 5.0 Acknowledgements ......................................... 10 53 6.0 References ............................................... 10 54 Appendix A: Type-7 LSA Packet Format ......................... 11 55 Appendix B: The Options Field ................................ 11 56 Appendix C: Configuration Parameters ......................... 12 58 1.0 Abstract 60 This document describes a new optional type of OSPF area, some- 61 what humorously referred to as a "not-so-stubby" area (or NSSA). 62 NSSAs are similar to the existing OSPF stub area configuration 63 option but have the additional capability of importing AS exter- 64 nal routes in a limited fashion. 66 2.0 Overview 68 2.1 Motivation 70 Wide-area transit networks (such as the NSFNET regionals) often 71 have connections to moderately-complex "leaf" sites. A leaf site 72 may have multiple IP network numbers assigned to it. 74 Typically, one of the leaf site's networks is directly connected 75 to a router provided and administered by the transit network 76 while the others are distributed throughout and administered by 77 the site. From the transit network's perspective, all of the 78 network numbers associated with the site make up a single "stub" 79 entity. For example, BARRNet has one site composed of a class-B 80 network, 130.57.0.0, and a class-C network, 192.31.114.0. From 81 BARRNet's perspective, this configuration looks something like 82 this: 84 192.31.114 85 | 86 (cloud) 87 -------------- 130.57.4 88 | 89 | 90 ------ 131.119.13 ------ 91 |BR18|------------|BR10| 92 ------ ------ 93 | 94 V 95 to BARRNet "core" OSPF system 97 where the "cloud" consists of the subnets of 130.57 and network 98 192.31.114, all of which are learned by RIP on router BR18. 99 Topologically, this cloud looks very much like an OSPF stub area. 100 The advantages of running the cloud as an OSPF stub area are: 102 1. Type-5 routes (OSPF external link-state advertise- 103 ments (LSAs)) are not advertised into the cloud 104 utilizing less resources in the (perhaps limited) 105 cloud's routers. 107 2. The transit network is abstracted to the cloud 108 by advertising a default route into the cloud. 110 3. The cloud becomes a single manageable entity to the 111 transit network. 113 4. The cloud can become part of the transit network's 114 OSPF routing system. 116 However, the current definition of the OSPF protocol [OSPF] 117 imposes topological limitations which restrict simple cloud topo- 118 logies from becoming OSPF stub areas. In particular, it is ille- 119 gal for a stub area to import routes external to OSPF; it is not 120 possible for routers BR18 and BR10 to both be members of the stub 121 area and to import the routes learned from RIP or other IP rout- 122 ing protocols as type-5 (OSPF external LSAs) into the OSPF sys- 123 tem. In order to run OSPF out to BR18, BR18 must be a member of 124 a non-stub area or the OSPF backbone to import routes other than 125 its directly-connected network(s). Since it is not acceptable 126 for BR18 to maintain all of BARRNet's external (type-5) routes, 127 BARRNet is forced by OSPF's topological limitations to run OSPF 128 out to BR10 and to run RIP between BR18 and BR10. 130 2.2 Proposed Solution 132 This document describes a new optional type of OSPF area, some- 133 what humorously referred to as a "not-so-stubby" area (or NSSA) 134 which has the capability of importing external routes in a lim- 135 ited fashion. 137 The OSPF specification defines two general classes of area confi- 138 guration. The first allows type-5 LSAs to be flooded throughout 139 the area. In this configuration, type-5 LSAs may be originated 140 by routers internal to the area or flooded into the area by area 141 border routers. These areas, referred to herein as type-5 capa- 142 ble areas (or just plain areas in the OSPF spec), are dis- 143 tinguished by the fact that they can carry transit traffic. The 144 backbone is always a type-5 capable area. The second type of 145 area configuration, called stub, allows no type-5 LSAs to be pro- 146 pagated into/throughout the area and instead depends on default 147 routing to external destinations. 149 NSSAs are defined in much the same manner as existing stub areas. 150 To support NSSAs, a new option bit (the "N" bit) and a new type 151 of LSA (type-7) area defined. The "N" bit ensures that routers 152 belonging to an NSSA agree on its configuration. Similar to the 153 stub area's use of the "E" bit, both NSSA neighbors must agree on 154 the setting of the "N" bit or the OSPF neighbor adjacency will 155 not form. 157 Type-7 LSAs provide for carrying external route information 158 within an NSSA. Type-7 AS External LSAs have virtually the same 159 syntax as the Type-5 AS External LSAs with the obvious exception 160 of the link-state type (see section 3.2 for more details). There 161 are two major semantic differences between type-5 and type-7 162 LSAs. 164 o Type-7 LSAs may be originated by and advertised 165 throughout an NSSA; as with stub areas, NSSA's do not 166 receive or originate type-5 LSAs. 168 o Type-7 LSAs are advertised only within a single NSSA; 169 they are not flooded into the backbone area or any 170 other area by border routers, though the information 171 which they contain can be propagated into the backbone 172 area (see section 3.6). 174 In order to allow limited exchange of external information across 175 an NSSA area border, NSSA border routers will translate selected 176 type-7 LSAs received from the NSSA into type-5 LSAs. These 177 type-5 LSAs will be flooded to all type-5 capable areas. In 178 addition, an NSSA area border router can originate a default 179 type-7 LSA (IP address of 0.0.0.0) into the NSSA (note that the 180 default route originated by an NSSA area border router is never 181 translated into a type-5 LSA). As with stub areas and the sum- 182 mary default route, default routes are necessary because NSSAs do 183 not receive full routing information and therefore must have a 184 default route to route to AS-external destinations. As with stub 185 areas, NSSAs may be connected to the backbone at more than one 186 area border router, but may not be used as a transit area. 188 It should be noted that unlike stub areas, all OSPF summary 189 routes (type-3 LSAs) must be imported into NSSAs. This is to 190 ensure that OSPF internal routes are always chosen over OSPF 191 external (type-7) routes. 193 In our example topology the subnets of 130.57 and network 194 192.31.114, will still be learned by RIP on router BR18 but now 195 both BR10 and BR18 can be in an NSSA and all of BARRNets external 196 routes are hidden from BR18; BR10 becomes an NSSA area border 197 router and BR18 becomes an AS boundary router internal to the 198 NSSA. BR18 will import the subnets of 130.57 and network 199 192.31.114 as type-7 LSAs into the NSSA. BR10 then translates 200 these routes into type-5 LSAs and floods them into BARRNet's 201 backbone. 203 3.0 Implementation Details 205 3.1 The N-bit 207 The N-bit ensures that all members of a NSSA agree on the area's 208 configuration. Together, the N-bit and E-bit reflect an 209 interface's (and consequently the interface's associated area's) 210 external LSA flooding capability. As explained in section 10.5 211 of the OSPF specification, if type-5 LSAs are not flooded 212 into/throughout the area, the E-bit must be clear in the option 213 field of the received Hello packets. Interfaces associated with 214 an NSSA will not send or receive type-5 LSAs on that interface 215 but may send and receive type-7 LSAs. Therefore, if the N-bit is 216 set in the options field, the E-bit must be cleared. 218 To support the NSSA option an additional check must be made in 219 the function that handles receiving Hello packet to verify that 220 both the N-bit and the E-bit found in the Hello packet's option 221 field match the value of the options that have been configured in 222 the receiving interface. A mismatch in the options causes pro- 223 cessing of the received Hello packet to stop and the packet to be 224 dropped. 226 3.2 Type-7 LSAs: NSSA External Link-State Advertisements 228 External routes are imported into NSSAs as type-7 LSAs by the 229 NSSA's AS boundary routers. That is, type-7 LSAs are originated 230 by the NSSA's AS boundary routers that have an interface associ- 231 ated with the NSSA and are exchanging routing information with 232 routers belonging to another AS (or importing static routes). As 233 with type-5 LSAs a separate LSA is originated for each destina- 234 tion network. The link-state database must therefore be expanded 235 to contain a type-7 LSA. 237 Type 7-LSAs are identical to type-5 LSAs except for the following 238 (see section 12.3.4 "AS external links" in the OSPF specifica- 239 tion). 240 1. The type field in the LSA header is 7. 242 2. Type-7 LSAs are only flooded within the NSSA. 243 The flooding of type-7 LSAs follow the same rules 244 as the flooding of type 1-4 LSAs. 246 3. Type-7 LSAs are kept within the NSSA's LSDB (are area 247 specific) whereas because type-5 LSAs are flooded to 248 all type-5 capable areas, type-5 LSAs have global scope 249 in the router's LSDB. 251 4. At the area border router, selected type-7 LSAs are 252 translated into type 5-LSAs and flooded into the 253 backbone. 255 5. Type 7 LSAs have a propagate (P) bit which is 256 used to flag the area border router to translate the 257 type-7 LSA into a type-5 LSA. Examples of how the P-bit 258 is used for loop avoidance are in the following sections. 260 6. Those type-7 LSAs that are to be translated into type-5 261 LSAs must have their forwarding address set; 262 all type-5 LSAs that have been translated from type-7 LSAs 263 must contain a forwarding address. 264 The forwarding address contained in type-5 LSAs will 265 result in more efficient routing to the AS external 266 networks when there are multiple NSSA area 267 border routers. Having the forwarding address in the 268 type-7 LSAs will ease the translation of type-7 into 269 type-5 LSAs as the NSSA area border router will 270 not be required to compute the forwarding address. 272 If the network between the NSSA AS boundary router and the 273 adjacent AS is advertised into OSPF as an internal OSPF 274 route, the forwarding address should be the next hop 275 address as is currently done in type-5 LSAs, but unlike 276 type-5 LSAs if the intervening network is not advertised 277 into OSPF as an internal OSPF route, the forwarding 278 address should be any one of the router's active OSPF 279 interface addresses. 281 Type-5 and type-7 metrics and path types are directly comparable. 283 3.3 Originating Type-7 LSAs 285 NSSA AS boundary routers may originate type-7 LSAs. All NSSA 286 area border routers must also be AS boundary routers since they 287 all must have the capability of translating a type-7 LSAs into a 288 type-5 LSAs (see section 3.6 routes for the translation algo- 289 rithm). NSSA area border routers must set the E-bit (external 290 bit) as well as the B-bit (border bit) in its router (type-1) 291 LSA. 293 When an NSSA internal AS boundary router originates a type-7 LSA 294 that it wants to be translated into a type-5 LSA by the NSSA area 295 border router (and subsequently flooded into the backbone), it 296 must set the P-bit in the LS header's option field and add a 297 valid forwarding address in the type-7 LSA. 299 If a router is attached to another AS and is also an NSSA area 300 border router, it may originate a both a type-5 and a type-7 LSA 301 for the same network. The type-5 LSA will be flooded to the 302 backbone (and all attached type-5 capable areas) and the type-7 303 will be flooded into the NSSA. If this is the case, the P-bit 304 must be reset in the type-7 NSSA so the type-7 LSA isn't again 305 translated into a type-5 LSA by another NSSA area border router. 307 A type-7 default route (network 0.0.0.0) may be originated into 308 the NSSA by an NSSA area border router or by an NSSA AS boundary 309 router which is internal to the NSSA. The type-7 default route 310 originated by the NSSA area border router must have the P-bit 311 reset so that the default route originated by the NSSA area 312 border router will not find its way out of the NSSA into the rest 313 of the AS system via another NSSA area border router. The type-7 314 default originated by an NSSA AS boundary router which is inter- 315 nal to the NSSA may have the P-bit set. Type-7 routes which are 316 originated by the NSSA area border router will not get added to 317 other NSSA area border router's routing table. 319 A default route must not be injected into the NSSA as a summary 320 (type-3) LSA as in the stub area case. The reason for this is 321 that the preferred summary default route would be chosen over all 322 more specific type-7 route. Because summary routes are preferred 323 to external routes and to ensure that summary routes are chosen 324 over external within the NSSA, all summary routes (unlike stub 325 areas in which this is optional) must be imported into an NSSA. 327 3.4 Calculating Type-7 AS External Routes 329 This section is very similar to section 16.4 (Calculating AS 330 external routes) in the OSPF specification. An NSSA area border 331 router should examine both type-5 LSAs and type-7 LSAs if either 332 type-5 or type-7 routes need to be updated. Type-7 LSAs should 333 be examined after type-5 LSAs. An NSSA internal router should 334 examine type-7 LSAs when type-7 routes need to be recalculated. 336 In relation to the steps to calculate the routing table as 337 presented in the OSPF specification (chapter 16, "Calculation of 338 the Routing Table"), type-7 LSAs should be examined after step 5 339 where the routes to external destinations are calculated. 341 Type-7 routes are calculated by examining type-7 LSAs. Each of 342 LSAs are considered in turn. Most type-7 LSAs describe routes to 343 specific IP destinations. A type-7 LSA can also describe a 344 default route for the NSSA (destination = DefaultDestination). 345 For each type-7 LSA: 347 1. If the metric specified by the LSA is LSInfinity, the 348 age of the LSA equals MaxAge or the advertising router 349 field is equal to this router's router ID, examine the 350 next advertisement. 352 2. Call the destination described by the LSA N. Look up the 353 routing table entry for the AS boundary router (ASBR) that 354 originated the LSA. If no entry exists for the ASBR 355 (i.e., ASBR is unreachable), do nothing with this LSA and 356 consider the next in the list. 358 If the destination is the default route (destination = 359 DefaultDestination) and if the originator of the LSA and 360 the calculating router are both NSSA are border routers 361 do nothing with this LSA and consider the next in the list. 363 Else, this LSA describes an AS external path to destination 364 N. If the forwarding address (as specified in the forwarding 365 address field of the LSA) is 0.0.0.0, the packets routed 366 to the external destination N will be routed to the 367 originating ASBR. If the forwarding address is not 0.0.0.0, 368 look up the forwarding address in the routing table. Packets 369 routed to the external destination N will be routed within 370 the NSSA to the this forwarding address. An intra-area path 371 must therefore exist to the forwarding address. If no such 372 path exists, do nothing with the LSA and consider the next 373 in the list. 375 Call the routing table distance to the forwarding address 376 (or the distance to the originating ASBR if the forwarding 377 address is 0.0.0.0) X, and the cost specified in the type-7 378 LSA Y. X is in terms of the link-state metric, and Y is a 379 Type-1 or external metric. 381 3. Now, look up the routing table entry for the destination 382 N. If no entries exist for N, install the AS external path 383 to N, with the next hop equal to the list of next hops to 384 the forwarding address/ASBR, and the advertising router equal 385 to ASBR. If the external metric type is 1, then the 386 path-type is set to Type-1 external and the cost is equal 387 to X + Y. If the external metric type is 2, the path-type 388 is set to Type-2 external, the link-state component of the 389 route's cost is X, and the Type-2 cost is Y. 391 4. Else, if the paths present in the table are not Type-1 or 392 Type-2 external paths, do nothing (AS external paths have 393 the lowest priority). 395 5. Otherwise, compare the cost of this new AS external path 396 to the ones present in the table. Note that type-5 and 397 type-7 routes are directly comparable. Type-1 external 398 paths are always shorter than Type-2 external paths. 399 Type-1 external paths are compared by looking at the sum 400 of the distance to the forwarding address/ASBR and the 401 advertised Type-1 paths (X+Y). Type-2 external paths are 402 compared by looking at the advertised Type-2 metrics, 403 and then if necessary, the distance to the forwarding 404 address/ASBR. 405 When a type-5 LSA and a type-7 LSA are found to have the 406 same type and an equal distance, the following priorities 407 apply (listed from highest to lowest) for breaking the tie. 408 a. Any type 5 LSA. 409 b. A type-7 LSA with the P-bit set and the forwarding 410 address non-zero. 411 c. Any other type-7 LSA. 413 If the new path is shorter, it replaces the present paths 414 in the routing table entry. If the new path is the same 415 cost, it is added to the routing table entry's list of 416 paths. 418 3.5 Incremental Updates 420 Incremental updates for type-7 LSAs should be treated the same as 421 incremental updates for type-5 LSAs (see section 16.6 of the OSPF 422 specification). That is, if a new instance of a type-7 LSA is 423 received it is not necessary to recalculate the entire routing 424 table. If there is already an OSPF internal route to the destina- 425 tion represented by the type-7 LSA, no recalculation is neces- 426 sary. Otherwise, the procedure in the proceeding section will 427 have to be performed but only for the external routes (type-5 and 428 type-7) whose networks describe the same networks as the newly 429 received LSA. 431 4.0 Originating Type-5 LSAs 433 4.1 Translating Type-7 LSAs Into Type-5 LSAs 435 This step is performed as part of the NSSA's Dijkstra calculation 436 after type-5 and type-7 routes have been calculated. If the cal- 437 culating router is not an area border router this translation 438 algorithm should be skipped. All reachable area border routers 439 in the NSSA should now be examined noting the one with the 440 highest router ID. If this router has the highest router ID, it 441 will be the one translating type-7 LSAs into type-5 LSAs for the 442 NSSA, otherwise the translation algorithm should not be per- 443 formed. 445 All type-7 routes that have been added to the routing table 446 should be examined. If the type-7 LSA being examined has the P- 447 bit set and a non-zero forwarding address a new instance of a 448 type-5 LSA should be originated and flooded to all attached 449 type-5 capable areas if one of the following is true. 451 1. There currently is no type-5 LSA originated from this 452 router corresponding to the type-7 LSA. 454 2. The path type or the metric in the corresponding 455 type-5 LSA is different from the type-7 LSA. 457 3. The forwarding address in the corresponding 458 type-5 LSA is different from the type-7 LSA. 460 The newly originated type-5 LSAs will describe the same network 461 and have the same network mask, metrics, forwarding address, and 462 external route tag as the type-7 LSA. The advertising router 463 field will be the router ID of this area border router. 465 4.2 Flushing Translated Type-7 LSAs 467 If an NSSA area border router has translated a type-7 LSA to a 468 type-5 LSA that should no longer be translated, the type-5 LSA 469 should be flushed (set to MaxAge and flooded). The translated 470 type-5 LSA should be flushed whenever the routing table entry 471 that caused the translation changes so that either the routing 472 table entry is unreachable or the entry's associated LSA is not a 473 type-7 with the P-bit set and a non-zero forwarding address. 475 5.0 Acknowledgements 477 This document was produced by the OSPF Working Group, chaired by 478 John Moy. 480 In addition, the comments of the following individuals are also 481 acknowledged: 482 Phani Jajjarvarpu cisco 483 Dino Farinacci cisco 484 Jeff Honig Cornell University 485 John Moy Proteon, Inc. 486 Doug Williams IBM 488 6.0 References 490 [OSPF] Moy, J. OSPF Version 2. RFC 1247. July 1991. 491 [MOSPF] Moy, J. Multicast Extensions to OSPF. 492 Internet Draft. September 1992. 494 Appendix A: Type-7 Packet Format 496 0 32 497 ----------------------------------- 498 | | OPTS | 7 | 499 | ------------------ 500 | Link-State Header | 501 | | 502 ----------------------------------- 503 | Network Mask | 504 ----------------------------------- ______ 505 |E| Tos | metric | . 506 ----------------------------------- . repeated for each TOS 507 | Forwarding Address | . 508 ----------------------------------- . 509 | External Route Tag | ______ 510 ----------------------------------- 512 The definitions of the link-state ID, network mask, metrics and 513 external route tag are the same as the definitions for the type-5 514 LSAs (see A.4.5 in the OSPF specification) except for: 516 The Forwarding Address 517 If the network between the NSSA AS boundary router and the adja- 518 cent AS is advertised into OSPF as an internal OSPF route, the 519 forwarding address should be the next hop address but if the 520 intervening network is not advertised into OSPF as an internal 521 OSPF route, the forwarding address should be any one of the 522 router's active OSPF interface addresses. 524 Appendix B: The Options Field 526 The OSPF options field is present in OSPF Hello packets, Database 527 Description packets and all link-state advertisements. See appen- 528 dix A.2 in the OSPF specification for a description of option 529 field. 531 ------------------------------------ 532 | * | * | * | * | N/P | MC | E | T | 533 ------------------------------------ 535 The Type-7 LSA options field 537 T-bit: The T-bit describes the router's TOS capability. 539 E-bit: Type-5 AS external link advertisements are not 540 flooded into/through OSPF stub and NSSA areas. 541 The E-bit ensures that all members of a stub area 542 agree on that area configuration. The E-bit is 543 meaningful only in OSPF Hello packets. When the 544 E-bit is reset in the Hello packet sent out a 545 particular interface, it means that the router 546 will neither send nor receive type-5 AS external 547 link state advertisements on that interface (in other 548 words, the interface connects to a stub area). Two 549 routers will not become neighbors unless they agree 550 on the state of the E-bit. 552 MC-bit: The MC-bit describes the multicast capability of the 553 various pieces of the OSPF routing domain [MOSPF]. 555 N-bit: The N-bit describes the the router's NSSA capability. 556 The N-bit is used only in Hello packets and ensures 557 that all members of an NSSA agree on that area's 558 configuration. When the N-bit is reset in the Hello 559 packet sent out a particular interface, it means 560 that the router will neither send nor receive 561 type-7 LSAs on that interface. Two routers will not 562 form an adjacency unless they agree on the state 563 of the N-bit. If the N-bit is set in the options 564 field, the E-bit must be reset. 566 P-bit: The P-bit is used only in the type-7 LSA header. 567 It flags the NSSA area border router to translate the 568 type-7 LSA into a type-5 LSA. 570 Appendix C: Configuration Parameters 572 Appendix C.2 in the OSPF specification lists the area parameters. 573 Area ID, list of address ranges and authentication type remain 574 unchanged. For NSSAs the external capabilities of the area must 575 be set to accept type-7 external routes. Additionally there must 576 be a way of configuring the NSSA area border router to send a 577 default route into the NSSA using a specific metric (type-1 or 578 type-2 and the actual cost).