idnits 2.17.1 draft-ietf-ospf-shortcut-abr-00.txt: 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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == 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. ** The abstract seems to contain references ([Ref1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 347: '... MUST be inserted into the ro...' 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 1999) is 9050 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) == Outdated reference: A later version (-05) exists of draft-ietf-ospf-abr-alt-00 ** Downref: Normative reference to an Informational draft: draft-ietf-ospf-abr-alt (ref. 'Ref2') -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref3' Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. D. Zinin 2 Internet Draft AMT Group 3 Expiration Date: January 2000 July 1999 4 File name: draft-ietf-ospf-shortcut-abr-00.txt 6 OSPF Shortcut ABR 7 Enhanced OSPF ABR Behavior 8 draft-ietf-ospf-shortcut-abr-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its Areas, and its Working Groups. Note that other 17 groups may also distribute working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a "working 23 draft" or "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 OSPF [Ref1] is a link-state intra-domain routing protocol used for 34 routing in IP networks. Though the definition of the ABR in the 35 current OSPF specification does not require a router with multiple 36 attached areas to have a backbone connection, it is actually 37 necessary to provide successful routing to the inter-area and 38 external destinations. If this requirement is not met all traffic, 39 destined for the areas not connected to such an ABR or out of the 40 OSPF domain, is dropped. The rules of originating and processing 41 Summary-LSAs given in the current OSPF standard [Ref1] can also 42 result in suboptimal inter-area routing. Though all these problems 43 can be fixed using virtual links, this memo describes an alternative 44 implementation of the OSPF ABR behavior, which allows the 45 administrator to avoid it or, if virtual links are still used, to 46 decrease the number of configured virtual links. 48 This memo also describes possible situations where the proposed 49 implementation can be used. 51 Acknowledgements 53 The author would like to acknowledge Christian Hopps and Peter Psenak 54 for their help in finding weak points in early versions of this 55 document and Thomas M. Thomas for reviewing the preceding version of 56 it. 58 Special thanks go to John Moy who contributed a lot to this document 59 and provided a simpler algorithm representation, used herein. 61 Table of Contents 63 1 Overview ..................................................... 3 64 1.1 Introduction ............................................... 3 65 1.2 Motivation ................................................. 3 66 2 Description of Shortcut ABR behavior ......................... 5 67 3 Proposed changes to OSPF ABR behavior ........................ 5 68 3.1 Changes to Router-LSA origination .......................... 5 69 3.2 Changes to routing table calculation ....................... 6 70 3.3 Changes to Summary-LSA origination ......................... 9 71 4 Implementation Details ....................................... 10 72 5 Compatibility ................................................ 10 73 6 Deployment Considerations .................................... 11 74 6.1 Necessity of virtual links ................................. 11 75 6.2 Change of traffic patterns ................................. 11 76 6.3 Optimized inter-area routing ............................... 11 77 6.4 Gradual deployment of Shortcut ABRs ........................ 13 78 7 Security Considerations ...................................... 13 79 8 Appendixes ................................................... 14 80 A.1 Router-LSA ................................................. 14 81 9 References ................................................... 15 82 10 Author's Address ............................................ 16 84 1 Overview 86 1.1 Introduction 88 An OSPF routing domain can be split into several subdomains, called 89 areas, which limit the scope of LSA flooding. A router having attach- 90 ments to multiple areas is called an "area border router" (ABR). The 91 primary function of an ABR is to provide its attached areas with 92 Type-3 and Type-4 LSAs (which are used for describing routes and 93 ASBRs in other areas) as well as to perform actual inter-area rout- 94 ing. 96 1.2 Motivation 98 In OSPF flooding of Type-1 and Type-2 LSAs is limited to the area 99 borders, so routers in other areas must somehow know how to reach 100 destinations and ASBRs residing in different areas. OSPF uses 101 Distance-Vector (DV) approach to achieve this goal, i.e., Area Border 102 Routers announce routes and ASBRs internal to directly connected 103 areas in Type-3 and Type-4 Summary-LSAs. 105 If routers using a DV protocol announce only directly attached net- 106 works, they must be fully meshed to provide complete routing informa- 107 tion to each other. This condition cannot always be met, so routers 108 also announce the networks they heard about from their neighboring 109 routers. This is the main reason for loops of routing updates in DV 110 protocols, which are solved with such methods as split-horizon, 111 counting-to-infinity, triggered updates, and holddown-timers. Appli- 112 cation of these rules to OSPF inter-area routing would make the code 113 very complex, but since areas in OSPF need not be fully meshed, ABRs 114 are allowed to reannounce inter-area routes. In order to prevent 115 loops of summaries in OSPF, ABRs reannounce only those inter-area 116 routes which are associated with the backbone area. Summaries from 117 non-backbone areas are just not considered by ABRs. Because inter- 118 area routes are not reannounced back into the backbone area, the 119 latter functions as a loop-free inter-area routing information repo- 120 sitory. In order to achieve normal routing to inter-area and AS- 121 external destinations, all areas in OSPF must be connected to the 122 backbone either physically (via an interface) or logically (via a 123 virtual link). This is to ensure that all areas are provided with 124 inter-area routes from the backbone. 126 A basic discussion of the disadvantages of the standard inter-area 127 approach are given in [Ref2] and are applicable to this document as 128 well. In addition to that, consider another problem caused by stan- 129 dard OSPF ABR behavior (Figure 1). 131 . Area 2 . 132 . . 133 . +--+ . 134 ......|R5|....... 135 . +--+ . 136 . / \ . 137 . / \ . 138 . BB /10Mb \ 2Mb . 139 . / \ . 140 . | \ . 141 . +--+ +--+ . 142 ..|R1|......|R2|.. 143 . +--+ +--+ . 144 . | 10Mb |\ . 145 . ------------ | . 146 . | . 147 . +--+ . 148 . |R4| . 149 . Area 1 +--+ . 150 .................. 152 Figure 1. Suboptimal inter-area routing 154 In this example router R2 has a 2Mb link to R5. At the same time R1 155 has a better link (10 Mbps), but R2 cannot route traffic going to 156 area 2 through R1. This is because according to [Ref1] R2 is not 157 allowed to consider summary-LSAs from non-backbone areas and, conse- 158 quently, does not have routes covering destinations in area 2 via R1. 159 The situation looks even more interesting if R4's routing table is 160 considered. Since R2 floods summary-LSAs from R1 to R4, router R4 161 will have routes to the area 2 via R1 (the best path), expecting 162 traffic to go via 10Mbps links. In reality R2 will not direct traffic 163 to R1, but will forward it via 2Mbps link attached to itself. 165 The last example shows how the main principle of OSPF---prefer the 166 shortest path---is broken due to distance vector approach used for 167 inter-area routing. Again, the problem can be fixed using the virtual 168 links between R1 and R2 in standard OSPF, but the solution proposed 169 in this document appears to be more elegant and involving no adminis- 170 trative and traffic overhead. More sophisticated examples of how 171 Shortcut ABR approach improves inter-area routing are given in sec- 172 tion 6. 174 2 Description of Shortcut ABR behavior 176 This section describes an alternative implementation of OSPF ABR 177 behavior, named "Shortcut ABR". It is an improvement on standard ABR 178 behavior, based on relaxation of the restrictions applied to the cal- 179 culation of the inter-area routes. 181 ABRs are allowed to consider summary-LSAs from all attached areas (no 182 matter if it is connected to the backbone or not). The routing loop 183 prevention is done by restricting origination of summary-LSAs--- 184 inter-area routes are readvertised only if there is a valid summary- 185 LSA for the destination learned from the backbone. Origination of 186 summary-LSAs for intra-area routes is done as in standard OSPF, 187 described in [Ref1]. 189 The relaxation of the routing table calculation allows ABRs without a 190 backbone connection to route traffic between the attached areas, as 191 well as to route traffic destined for the backbone and other areas 192 using the routes derived from the summary-LSAs in each attached area. 193 This approach also enables router R2 in Figure 1 to route inter-area 194 traffic via R1. 196 Note that the proposed solution does not obviate the need of virtual 197 link configuration in case an area has no physical backbone connec- 198 tion at all. The method described here improves the behavior of a 199 router connecting two or more backbone-attached areas. 201 Though this document is initially oriented to processing Type-3 LSAs 202 and, consequently, is targeted to improving OSPF inter-area routing, 203 it's acceptable to apply described methods to Type-4 LSAs, which will 204 lead to improvement of external routing in an OSPF domain. 206 3 Proposed changes to OSPF ABR behavior 208 This section describes the changes made to the base OSPF described in 209 [Ref1]. 211 3.1 Changes to Router-LSA origination 213 The algorithm of Type 1 LSA (router-LSA) origination is changed 214 to have the Shortcut ABR announce its Shortcut capability in the 215 Router-LSA as described in A.1. A Shortcut ABR must set the S-bit 216 in the Router-LSA for Area A only if the area A's data structure 217 has ShortcutConfigured bit set to TRUE, i.e., the S-bit directly 218 reflects the state of ShortcutConfigured flag (see section 3.2 219 for more details). As in [Ref1] Shortcut ABRs identify themselves 220 as ABRs by setting the bit B in their Router-LSAs when they have 221 more than one attached area. 223 3.2 Changes to routing table calculation 225 Shortcut ABRs maintain two additional flags in Area Data Struc- 226 ture for every non-backbone area. The flags are named Shortcut- 227 Configured and ShortcutCapability. The first flag indicates 228 whether the administrator has configured the area to be Shortcut. 229 If so the ABR will set the S-bit in its Router-LSA for this area. 230 The second flag indicates that all other ABRs in the areas are 231 also Shortcut capable. Note that Shortcut ABR is allowed to con- 232 sider summary-LSAs from a non-backbone area only if ShortcutCapa- 233 bility flag is set to TRUE. ShortcutCapability flag, in turn, can 234 be set to TRUE only if ShortcutConfigured flag is also set to 235 TRUE. This means that the area must be configured as Shortcut on 236 the ABR itself and all other ABRs. 238 If during the routing table calculation a Shortcut ABR notices 239 that there is a ABR which is not Shortcut-capable in any area, 240 the Shortcut ABR must clear the ShortcutCapability flag for that 241 area, but still announce the ShortcutConfigured flag for the area 242 in the S-bit of the Router-LSA originated for this area. 244 Should the ABR in question find that there no ABRs in an area, 245 which are not Shortcut-capable, it must set the ShortcutCapabil- 246 ity flag for that area. 248 To implement this algorithm Steps 1 and 2 in section 16.1 of 249 [Ref1] are changed as follows: 251 Step 1: 253 "Initialize the algorithm's data structures. Clear the 254 list of candidate vertices. Initialize the shortest-path 255 tree to only the root (which is the router doing the calcu- 256 lation). Set Area A's TransitCapability to FALSE and 257 ShortcutCapability to the value of ShortcutConfigured." 259 Step 2: 261 "Call the vertex just added to the tree vertex V. Examine 262 the LSA associated with vertex V. This is a lookup in the 263 Area A's link state database based on the Vertex ID. If 264 this is a router-LSA, and bit V of the router-LSA (see Sec- 265 tion A.4.2) is set, set Area A's TransitCapability to TRUE. 266 If this is a router-LSA, and bit B of the router-LSA is set 267 (the router is an ABR) and bit S of the router-LSA is not 268 set (the ABR is not Shortcut-capable), set Area A's 269 ShortcutCapability to FALSE. In any case, each link 270 described by the LSA gives the cost to an adjacent vertex. 271 For each described link, (say it joins vertex V to vertex 272 W):" 274 ShortcutCapability flag is used to determine over which areas the 275 ABR can use shortcut paths. Shortcut ABRs are forbidden to con- 276 sider Summary-LSAs from the areas with ShortcutCapability flag 277 off. This method is introduced to prevent possible routing loops 278 when standard and Shortcut ABRs are simultaneously present in an 279 OSPF domain. The method also allows for gradual enabling 280 shortcutting over specific non-backbone areas when and where it 281 is necessary. 283 The algorithm of calculating inter-area routes is changed to 284 allow the router to consider the summary-LSAs from attached non- 285 backbone areas that have ShortcutCapability flag set to TRUE. 286 This is achieved by applying section 16.3 of [Ref1] to such 287 areas. The following changes to 16.3 are made. 289 Paragraph 1 of 16.3 is changed to be as follows: 291 "This step is only performed by area border routers attached 292 to one or more non-backbone areas that are either capable of 293 carrying transit traffic (i.e., "transit areas", or those 294 areas whose TransitCapability parameter has been set to TRUE 295 in Step 2 of the Dijkstra algorithm (see Section 16.1) or have 296 all ABRs supporting Shortcut feature (i.e., those areas whose 297 ShortcutCapability parameter hasn't been set to FALSE during 298 the Dijkstra algorithm)." 300 Paragraph 4 of 16.3 is changed to be as follows: 302 "The calculation proceeds as follows. All summary-LSAs of the 303 areas with TransitCapability or ShortcutCapability parameter 304 set to TRUE are examined in turn. Each such summary-LSA 305 describes a route through a non-backbone area Area A to a Net- 306 work N (N's address is obtained by masking the LSA's Link 307 State ID with the network/subnet mask contained in the body of 308 the LSA) or in the case of a Type 4 summary-LSA, to an AS 309 boundary router N. Suppose also that the summary-LSA was ori- 310 ginated by an area border router BR." 312 Step (3) of the algorithm in 16.3 is changed to be as follows: 314 "Look up the routing table entry for N. (If N is an AS boun- 315 dary router, look up the "router" routing table entry associ- 316 ated with the backbone area). If the route type is other than 317 backbone intra-area or inter-area (associated with any area) 318 then examine the next LSA. 320 In other words, this calculation updates backbone intra-area 321 routes found in Section 16.1, inter-area routes found in Sec- 322 tion 16.2 and installs new inter-area routes if the ABR does 323 not have a backbone connection." 325 Step (5) of the algorithm in 16.3 is changed to be as follows: 327 "If this cost is less than the cost occurring in N's routing 328 table entry, overwrite N's list of next hops with those used 329 for BR, and set N's routing table cost to IAC. Else, if IAC is 330 the same as N's current cost, add BR's list of next hops to 331 N's list of next hops. If the area associated with N's routing 332 table entry is the backbone, then the area and the type of the 333 path (either intra-area or inter-area) must remain unchanged. 334 Otherwise (the routing table entry does not exist or the asso- 335 ciated area is not the backbone), the type of the route must 336 be set to inter-area and associated area must be set to the 337 area associated with the summary-LSA being processed." 339 In order to prevent routing loops sections 11.1 and 16.2 of 340 [Ref1] are changed. 342 Section 11.1 is restricted to require installation of discard 343 routing table entries for each of the router's active area range. 344 So the paragraph 2 of 11.1 should be read as follows: 346 "Before the lookup begins, "discard" routing table entries 347 MUST be inserted into the routing table for each of the 348 router's active area address ranges (see Section 3.5). (An 349 area range is considered "active" if the range contains one or 350 more networks reachable by intra-area paths.) The destination 351 of a "discard" entry is the set of addresses described by its 352 associated active area address range, and the path type of 353 each "discard" entry is set to "inter-area".[10]" 355 Step (3) of section 16.2 is changed to instruct the ABRs to 356 ignore summary defaults received from stub areas: 358 "If it is a Type 3 summary-LSA, and the collection of destina- 359 tions described by the summary-LSA equals one of the router's 360 configured area address ranges (see Section 3.5), and the par- 361 ticular area address range is active, then the summary-LSA 362 should be ignored. "Active" means that there are one or more 363 reachable (by intra-area paths) networks contained in the area 364 range. The summary-LSA should also be ignored if it is a sum- 365 mary default (Destination ID = DefaultDestination, Address 366 Mask = 0x00000000) and the area it has been received from is 367 a stub area. This is to prevent possible routing loops." 369 3.3 Changes to Summary-LSA origination 371 The algorithm of the summary-LSAs origination is changed to 372 include an explicit restriction not to originate summary-LSAs for 373 inter-area routes if the route to the destination is not associ- 374 ated with the backbone. 376 Note that if there are multiple alternative paths to a destina- 377 tion, some of which are via the backbone and the rest are via 378 non-backbone areas, the area associated with the corresponding 379 routing table entry will remain the backbone area, but the set of 380 next hops will actually direct traffic along the best path even 381 through non-backbone areas. 383 If the ABR in question has no backbone connection, it will not 384 originate summary-LSA for any inter-area route in any area, 385 because the area associated with the routing table entry will 386 never be the backbone area. 388 The ABR will also not readvertise an inter-area route from non- 389 backbone area if its backbone link state database does not con- 390 tain a summary-LSA or router-LSA covering a specific destination. 392 In order to implement described policy, the paragraph 2 in sec- 393 tion 12.4.3 of [Ref1] should be read as follows: 395 "... Note that only intra-area routes are advertised into the 396 backbone, while both intra-area and inter-area routes are 397 advertised into the other areas. Also, summary-LSAs for 398 inter-area routes are originated if and only if these routes 399 are associated with the backbone area (to prevent loops of 400 summary-LSAs)." 402 The 6th step of the algorithm given in sections 12.4.3 of [Ref1] 403 must be read as shown below: 405 "Else, if the destination of this route is an AS boundary 406 router, a summary-LSA should be originated if and only if the 407 routing table entry describes the preferred path to the AS 408 boundary router (see Step 3 of Section 16.4) and it is associ- 409 ated with the backbone area. If so, a Type 4 summary-LSA is 410 originated for the destination, with Link State ID equal to 411 the AS boundary router's Router ID and metric equal to the 412 routing table entry's cost. Note: these LSAs should not be 413 generated if Area A has been configured as a stub area." 415 The 7th step of the algorithm given in sections 12.4.3 of [Ref1] 416 must be read as shown below: 418 "Else, the Destination type is network. If this is an inter- 419 area route and it is associated with the backbone area, gen- 420 erate a Type 3 summary-LSA for the destination, with Link 421 State ID equal to the network's address (if necessary, the 422 Link State ID can also have one or more of the network's host 423 bits set; see Appendix E for details) and metric equal to the 424 routing table cost." 426 Described changes in the ABR behavior allow selection of most optimal 427 paths to inter-area destinations. Note that backbone intra-area 428 routes can be updated with better non-backbone inter-area one, thus 429 directing internal backbone traffic along more optimal paths through 430 other areas. 432 4 Implementation Details 434 If the current implementation of OSPF uses the standard described in 435 [Ref1], then support of the proposed Shortcut ABR behavior strategy 436 must be implemented as an implicit configurable option, allowing to 437 set ShortcutConfigured flag for a given area. 439 Note that the nature of the changes to OSPF presented in this docu- 440 ment is so that standard ABR behavior is not altered until at least 441 one area is configured as Shortcut. 443 5 Compatibility 445 ABRs following the approach described in this document are required 446 to announce their Shortcut capability for a given area in Router- 447 LSAs. Since no loops are formed when all ABRs in a given area are 448 Shortcut and Shortcut ABRs do not consider Summary-LSAs from an area 449 when a Shortcut-incompatible ABR in such an area is seen, the 450 approach described in this document is compatible with standard OSPF 451 described in [Ref1]. 453 6 Deployment Considerations 455 This section discusses the deployment details of Shortcut ABR. 457 6.1 Necessity of virtual links 459 First of all it should be repeated that Shortcut ABR behavior does 460 not obviate the need for virtual links in case an area has no physi- 461 cal backbone connection. The difference with standard OSPF is that 462 the administrator does not need to configure virtual links through 463 all areas he or she wants the inter-area traffic to go through. A 464 Shortcut ABR needs a single backbone connection (physical or virtual) 465 to achieve optimal routing, since it considers summary-LSAs from all 466 attached areas. 468 6.2 Change of traffic patterns 470 Use of Shortcut ABR can lead to changes in the paths inter-area 471 traffic flows take comparing to those experienced with standard OSPF. 472 This happens because the Shortcut ABR approach allows a router to 473 find paths better than it is possible with the standard OSPF. While 474 standard OSPF tries to forward all inter-area traffic through the 475 backbone area (though it does not guarantee it), the Shortcut ABR 476 finds best routes in the domain even across non-backbone areas. With 477 Shortcut ABR the backbone area is used as a dedicated place of 478 inter-area routing information exchange and inter-area traffic is 479 allowed to cross non-backbone area borders if such a path is really 480 the best. 482 6.3 Optimized inter-area routing 484 Use of Shortcut ABR improves inter-area routing in OSPF domains by 485 allowing ABRs to consider summary-LSAs from all attached area and 486 consequently readvertise them into non-backbone areas. Consider an 487 example show in the Figure 2: 489 ....................... 490 . Backbone . ......... 491 . . . . 492 . +--+ +--+ . 493 . |R1| |R5|--| . 494 . +--+ +--+ 1| . 495 . 8/ 8\ 1/ . | . 496 . / \ -------- . | . 497 . 8/ 8\ /1 1\ . | Net N . 498 .+--+ +--+ +--+ 1| . 499 ......|R2|.....|R3|.......|R4|--| . 500 . +--+ +--+ +--+ . 501 . .|1 1/ \1 1/ . . Area 3 . 502 . .-------- -------- . .......... 503 . . . 504 . . . 505 .Area 1 . Area 2 . 506 ....... ................... 508 Figure 2. Optimized inter-area routing 510 In case all ABRs use standard OSPF approach, routing to the net N 511 would be as follows: 513 o R4 and R5 inject summary-LSAs into the backbone 515 o R4 also inject a summary-LSA into area 2 517 o R3 is limited to consider summary-LSAs from the backbone only, 518 so it doesn't see the alternative path through area 2 and 519 always routes through the backbone (though parallel paths are 520 available) 522 o R3 injects summary-LSA for the inter-area routes derived from 523 the backbone summary-LSAs and received from R4 and R5 into Area 524 2 526 o R2 is not allowed to consider non-backbone summary-LSAs and 527 routes via serial links to R1, though more optimal paths do 528 exist 530 If R2, R3, and R4 use Shortcut ABR approach inter-area routing is 531 improved as shown below: 533 o R4 and R5 inject summary-LSAs into the backbone 535 o R4 also inject a summary-LSA into area 2 537 o R3 considers summary-LSAs from both attached areas and installs 538 the route through area 2 (it has three routes in the routing 539 table---via R5, via R4 through the backbone, and via R4 through 540 area 2) and performs traffic sharing between the two ethernet 541 links. 543 o R3 injects summary-LSA for the inter-area routes to N (it will 544 be the same as in the previous case, actually) 546 o R2 considers summary-LSAs from all attached areas and prefers 547 the route through area 2 rather than the backbone. 549 6.4 Gradual deployment of Shortcut ABRs 551 Shortcut ABR behavior is designed in such a way that the administra- 552 tor can enable shortcutting through non-backbone OSPF areas gradu- 553 ally. 555 Since Shortcut ABRs are allowed to consider summaries only of those 556 areas that were configured as Shortcut (ShortcutConfigured flag in 557 area data structure is set to TRUE) and whose ShortcutCapability flag 558 is set to TRUE, it is easy to control which areas will accept addi- 559 tional inter-area traffic. For an area to become Shortcut-capable, 560 all ABRs that have links in it must have this area configured as 561 Shortcut. If a single ABR in an area does not announce the S-bit in 562 its Router-LSA for this area, no other Shortcut ABRs connected to 563 this area will direct inter-area traffic through it (except for the 564 cases when standard OSPF behavior leads to it). 566 The implementers should note that support of a configurable option 567 described in section 4 is very important for traffic control and suc- 568 cessful deployment. 570 7 Security Considerations 572 Shortcut ABR behavior specified in this document does not raise any 573 security issues that are not already covered in [Ref1]. 575 8 Appendixes 577 A.1 Router-LSA 579 An OSPF router originates a router-LSA into each of its attached 580 areas. The router-LSA describes the state and cost of the router's 581 interfaces to the area. The contents of the router-LSA are described 582 in detail in Section A.4.2 of [Ref1]. One more flag has been added 583 to the router-LSA, called bit S below. This flag indicates whether 584 the area has been configured as Shortcut on the ABR. Note that all 585 ABRs in an area must announce the S-bit this area to be used in 586 shortcutting. 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | LS age | Options | 1 | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Link State ID | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Advertising Router | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | LS sequence number | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | LS checksum | length | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | rtype | 0 | # links | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 603 | Link ID | P 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E 605 | Link Data | R 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Type | # TOS | TOS 0 metric | # 608 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L 609 # | TOS | 0 | metric | I 610 T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 611 O | ... | K 612 S +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S 613 | | TOS | 0 | metric | | 614 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 615 | ... | 617 The router LSA 619 +---+---+---+---+---+---+---+---+ 620 | * | * | * | S | W | V | E | B | 621 +---+---+---+---+---+---+---+-+-+ 623 The rtype field 625 The following defines the flags found in the rtype field. Each flag 626 classifies the router by function: 628 o bit B. When set, the router is an area border router (B is for 629 border). These routers forward unicast data traffic between OSPF 630 areas. 632 o bit E. When set, the router is an AS boundary router (E is for 633 external). These routers forward unicast data traffic between Auto- 634 nomous Systems. 636 o bit V. When set, the router is an endpoint of an active virtual 637 link (V is for virtual) which uses the described area as its Tran- 638 sit area. 640 o bit W. Used in MOSPF [Ref3], when set, the router is a wild-card 641 multicast receiver. These routers receive all multicast datagrams, 642 regardless of destination. Inter-area multicast forwarders and 643 inter-AS multicast forwarders are sometimes wild-card multicast 644 receivers (see [Ref3] for more details). 646 o bit S. When set, the router is a Shortcut-capable ABR and intends 647 to use the area for shortcutting provided that all other ABRs in 648 this area agree on that (also announce the S-bit into this area). 649 See sections 2 and 3 for more details. 651 9 References 653 [Ref1] J. Moy. OSPF version 2. Technical Report RFC 2328, Internet 654 Engineering Task Force, 1998. ftp://ftp.isi.edu/in- 655 notes/rfc2328.txt. 657 [Ref2] Zinin, Lindem, Yeung. Alternative OSPF ABR Implementations. 658 Work in progress, Internet Engineering Task Force. draft- 659 ietf-ospf-abr-alt-00.txt 661 [Ref3] J. Moy. Multicast Extensions to OSPF. Internet Engineering 662 Task Force, 1998. http://www.ietf.org/internet-drafts/draft- 663 ietf-mospf-mospf-01.txt. 665 10 Author's Address 667 Alex D. Zinin 668 AMT Group 669 8 Maly Znamensky per., bld. 1 670 Office 3b 671 121019 Moscow, Russia 672 E-mail: zinin@amt.ru