idnits 2.17.1 draft-ietf-ospf-shortcut-abr-02.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 == The page length should not exceed 58 lines per page, but there was 18 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages 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. 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 2000) is 8679 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref2' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref3' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. D. Zinin 3 Internet Draft Cisco Systems 4 Expiration Date: January 2001 July 2000 5 File name: draft-ietf-ospf-shortcut-abr-02.txt 7 OSPF Shortcut ABR 8 Enhanced OSPF ABR Behavior 9 draft-ietf-ospf-shortcut-abr-02.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its Areas, and its Working Groups. Note that other 18 groups may also distribute working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six 21 months. Internet Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet 23 Drafts as reference material or to cite them other than as a "working 24 draft" or "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 OSPF [Ref1] is a link-state intra-domain routing protocol used for 35 routing in IP networks. Though the definition of the ABR in the 36 current OSPF specification does not require a router with multiple 37 attached areas to have a backbone connection, it is actually 38 necessary to provide successful routing to the inter-area and 39 external destinations. If this requirement is not met, all traffic, 40 destined for the areas not connected to such an ABR or out of the 41 OSPF domain, is dropped. The rules of originating and processing 42 Summary-LSAs given in the current OSPF standard [Ref1] can also 43 result in suboptimal inter-area routing. Though all these problems 44 can be fixed using virtual links, this memo describes an alternative 45 implementation of the OSPF ABR behavior, which allows the 46 administrator to avoid this or, if virtual links are still used, to 47 decrease the number of configured virtual links. 49 This memo also describes possible situations where the proposed 50 implementation can be used. 52 Acknowledgements 54 The author would like to acknowledge Christian Hopps and Peter Psenak 55 for their help in finding weak points in early versions of this 56 document, Thomas M. Thomas for reviewing the preceding version of it, 57 and James Huang for pointing out potential problems described in 58 section 7. 60 Special thanks go to John Moy who contributed a lot to this document 61 and provided a simpler algorithm representation, used herein. 63 Table of Contents 65 1 Overview ..................................................... 3 66 1.1 Introduction ............................................... 3 67 1.2 Motivation ................................................. 3 68 2 Description of Shortcut ABR behavior ......................... 5 69 3 Proposed changes to OSPF ABR behavior ........................ 6 70 3.1 Changes to Area Data Structure ............................. 6 71 3.2 Changes to Router-LSA Origination .......................... 8 72 3.3 Changes to Routing Table Calculation ....................... 8 73 3.4 Changes to Summary-LSA Origination ......................... 10 74 4 Implementation Details ....................................... 12 75 5 Compatibility ................................................ 12 76 6 Deployment Considerations .................................... 12 77 6.1 Necessity of Virtual Links ................................. 12 78 6.2 Change of Traffic Patterns ................................. 13 79 6.3 Optimized Inter-area Routing ............................... 13 80 6.4 Gradual Deployment of Shortcut ABRs ........................ 14 81 7 Routing Loops in Transition Periods .......................... 15 82 8 Security Considerations ...................................... 17 83 9 Appendixes ................................................... 17 84 A.1 Router-LSA ................................................. 17 85 10 References .................................................. 19 86 11 Author's Address ............................................ 19 88 1 Overview 90 1.1 Introduction 92 An OSPF routing domain can be split into several subdomains, called 93 areas, which limit the scope of LSA flooding. A router having attach- 94 ments to multiple areas is called an "area border router" (ABR). The 95 primary function of an ABR is to provide its attached areas with 96 Type-3 and Type-4 LSAs (which are used for describing routes and 97 ASBRs in other areas) as well as to perform actual inter-area rout- 98 ing. 100 1.2 Motivation 102 In OSPF, flooding of Type-1 and Type-2 LSAs is limited to the area 103 borders, so routers in other areas must somehow know how to reach 104 destinations and ASBRs residing in different areas. OSPF uses 105 Distance-Vector (DV) approach to achieve this goal, i.e., Area Border 106 Routers announce networks and ASBRs internal to directly connected 107 areas in Type-3 and Type-4 Summary-LSAs. 109 If routers using a DV protocol announce only directly attached net- 110 works, they must be fully meshed to provide complete routing informa- 111 tion to each other. This condition cannot always be met, so routers 112 also announce the networks they heard about from their neighbors. 113 This is the main reason for loops of routing updates in DV protocols, 114 which are solved using methods like split-horizon, limitting the max- 115 imum metric value or hop count, and hold-down timers. Application of 116 these rules to OSPF inter-area routing would make the code very com- 117 plex, but since areas in OSPF need not be fully meshed, ABRs are 118 allowed to reannounce inter-area routes. In order to prevent loops of 119 summaries in OSPF, ABRs reannounce only those inter-area routes which 120 are associated with the backbone area. Summaries from non-backbone 121 areas are just not considered by ABRs. Because inter-area routes are 122 not reannounced back into the backbone area, the latter functions as 123 a loop-free inter-area routing information repository. In order to 124 achieve normal routing to inter-area and AS-external destinations, 125 all areas in OSPF should be connected to the backbone either physi- 126 cally (via an interface) or logically (via a virtual link). This is 127 to ensure that all areas are provided with inter-area routes from the 128 backbone. 130 A basic discussion of the disadvantages of the standard inter-area 131 approach are given in [Ref2] and are applicable to this document as 132 well. In addition to that, consider another problem caused by stan- 133 dard OSPF ABR behavior (Figure 1). 135 . Area 2 . 136 . . 137 . +--+ . 138 ......|R5|....... 139 . +--+ . 140 . / \ . 141 . / \ . 142 . BB /10Mb \ 2Mb . 143 . / \ . 144 . | \ . 145 . +--+ +--+ . 146 ..|R1|......|R2|.. 147 . +--+ +--+ . 148 . | 10Mb |\ . 149 . ------------ | . 150 . | . 151 . +--+ . 152 . |R4| . 153 . Area 1 +--+ . 154 .................. 156 Figure 1. Suboptimal inter-area routing 158 In this example router R2 has a 2Mb link to R5. At the same time R1 159 has a better link (10 Mbps), but R2 cannot route traffic going to 160 area 2 through R1. This is because according to [Ref1] R2 is not 161 allowed to consider summary-LSAs from non-backbone areas and, conse- 162 quently, does not have routes covering destinations in area 2 via R1. 163 The situation looks even more interesting if R4's routing table is 164 considered. Since R2 floods summary-LSAs from R1 to R4, router R4 165 will have routes to the area 2 via R1 (the best path), expecting 166 traffic to go via 10Mbps links. In reality, R2 will not direct 167 traffic to R1, but will forward it via 2Mbps link attached to itself. 169 The last example shows how the main principle of OSPF---prefer the 170 shortest path---is broken due to distance vector approach used for 171 inter-area routing. Again, the problem can be fixed using the virtual 172 links between R1 and R2 in standard OSPF, but the solution proposed 173 in this document appears to be more elegant and involving less admin- 174 istrative and traffic overhead. More sophisticated examples of how 175 Shortcut ABR approach improves inter-area routing are given in sec- 176 tion 6. 178 2 Description of Shortcut ABR behavior 180 This section describes an alternative implementation of OSPF ABR 181 behavior, named "Shortcut ABR". It is an improvement on standard ABR 182 behavior, based on relaxation of the restrictions applied to the cal- 183 culation of the inter-area routes. 185 With the Shortcut ABR approach, ABRs are allowed to consider 186 summary-LSAs from all (or a subset of) attached areas by performing a 187 modified version of section 16.3 of [Ref1]. This gives Shortcut ABRs 188 a chance to install inter-area routes through non-backbone areas (if 189 non-backbone paths are really better), i.e. to "shortcut" through 190 them. The routing loop prevention is ensured by restricting the ori- 191 gination of summary-LSAs---inter-area routes are readvertised only if 192 they are associated with the backbone area (there is a valid LSA for 193 the destination learned from the backbone). Origination of summary- 194 LSAs for intra-area routes is done as in standard OSPF [Ref1]. 196 There is a probability of forming constant routing loops if 197 Shortcut-capable and standard ABRs are present in an OSPF domain and 198 can see each other through the backbone. Also, if transit or shortcut 199 areas form a circle, it is possible (though the probability is really 200 low) to have temporary routing loops as described in section 7. To 201 prevent these types of loops, two new variables (ShortcutConfigured 202 and ShortcutCapability) are introduced to the OSPF area data struc- 203 ture for non-backbone areas, and a new bit (S-bit) is announced in 204 the router-LSAs by the ABRs. 206 If the ABR doesn't have the backbone area connected, it considers 207 summary-LSAs from all attached areas. This is safe, because no 208 inter-area routes are associated with the backbone and get readver- 209 tised. The relaxation of the routing table calculation allows ABRs 210 without a backbone connection to route traffic between the attached 211 areas, as well as to route traffic destined for the backbone and 212 other areas using the routes derived from the summary-LSAs in each 213 attached area. This approach also enables router R2 in Figure 1 to 214 route inter-area traffic via R1. 216 Note that the proposed solution does not obviate the need of virtual 217 link configuration in case an ABR has no physical backbone connection 218 at all, but at the same time should reannounce inter-area routes 219 (intra-area routes are always announced to other areas). However, 220 this approach requires only a single backbone link per ABR or no 221 backbone link at all (if the ABR does not have to reannounce inter- 222 area routes and just needs to find the best routes through attached 223 areas itself). 225 3 Proposed changes to OSPF ABR behavior 227 This section describes the changes made to the base OSPF described in 228 [Ref1]. 230 3.1 Changes to Area Data Structure 232 Two new flags are introduced to OSPF area data structure--- 233 ShortcutConfigured and ShortcutCapability. 235 The ShortcutConfigured flag can be assigned three values: Default, 236 Enable, and Disable. The flag is set to Default value when an area 237 data structure is created. Description of the flag values is given 238 below. 240 Default 242 If area A's ShortcutConfigured flag is set to Default, and 243 the ABR has an active backbone connection, area A is not 244 used for shortcutting and the ABR does not set the S-bit in 245 the router-LSA originated for that area. If the ABR has no 246 backbone connection, area A is always used for shortcutting 247 and the ABR sets the S-bit in the router-LSA for that area. 249 Enable 251 If area A's ShortcutConfigured flag is set to Enable, and 252 the ABR has an active backbone connection, it sets the S- 253 bit in the router-LSA for area A and uses it for shortcut- 254 ting, provided that all other ABRs seen through this area 255 also report the S-bit. If the ABR has no backbone connec- 256 tion, it unconditionally uses area A for shortcutting and 257 sets the S-bit in the router-LSA originated for that area. 259 Disable 261 If an area's ShortcutConfigured flag is set to Disable, the 262 ABR doesn't use this area for shortcutting and doesn't set 263 the S-bit in the router-LSA originated for it. 265 Treamtment of the ShortcutConfigured flag described above ensures 266 that Shortcut ABRs operate correctly and efficiently without 267 explicit configuration. For example, when a Shortcut ABR is 268 attached to non-backbone areas only, the Default value will allow 269 it to shortcut through these areas. When a Shortcut ABR is con- 270 nected to the backbone, it doesn't shortcut through non-backbone 271 areas until it is explicitly configured to do so by setting the 272 ShortcutConfigured flag for specific (or all) areas to Enable 273 value and all other ABRs announce the S-bit (either because they 274 are not connected to the backbone, or because they were also con- 275 figured to shortcut through that area). Again, this behavior 276 ensures that no routing loop is established between a shortcut- 277 ting and not shortcutting ABR, as well as that shortcut areas do 278 not form a circle. 280 In addition to ShortcutConfigured, Shortcut ABRs maintain 281 ShortcutCapability flag in Area Data Structure for every non- 282 backbone area. These two flags are used to prevent permanent 283 routing loops in the networks where Shortcut-incapable ABRs are 284 used along with Shortcut ABRs. 286 While ShortcutConfigured flag indicates what the administrator 287 has configured for a particular area, ShortcutCapability indi- 288 cates that the area may actually be used for shortcutting either 289 because all other ABRs in the area agree on this using the S-bit 290 or because the calculating ABR does not have a backbone connec- 291 tion and was not explicitly configured not to do so. 293 Note that backbone-connected Shortcut ABRs are allowed to con- 294 sider summary-LSAs from a non-backbone area only if that area's 295 ShortcutCapability flag is set to TRUE. An area's ShortcutCapa- 296 bility flag, in turn, is set to TRUE when the ABR does not have a 297 backbone attachment and area's ShortcutConfigured is not set to 298 Disables, or when the ABR has a backbone connection, area's 299 ShortcutConfigured is set to Enable, and all other ABRs connected 300 to the area set their S bits in their router-LSAs. This means 301 that the calculating ABR and all other ABRs connected to that 302 area should be allowed to consider that area's summary-LSAs. 304 If, during the routing table calculation, a Shortcut ABR notices 305 that there is an ABR which does not announce the S-bit in any 306 area, the Shortcut ABR will probably need to clear the Shortcut- 307 Capability flag for that area (depending on whether it has a 308 backbone connection and the value of ShortcutConfigured flag). 309 Should the ABR in question find that all ABRs in an area agree on 310 the S-bit it may need to set the ShortcutCapability flag for that 311 area. 313 Note that announcement of S-bit does not depend on the results of 314 routing table calculation, but only on the setting of Shortcut- 315 Configured and backbone attachment. 317 3.2 Changes to Router-LSA Origination 319 The algorithm of Type 1 LSA (router-LSA) origination is changed 320 to have the Shortcut ABR announce its Shortcut capability in the 321 Router-LSA as described in A.1. A Shortcut ABR should set the S- 322 bit in the Router-LSA for Area A only if: 324 o the router does not have a backbone connection and 325 ShortcutConfigured flag for this area is NOT set to Dis- 326 able value, or 328 o the router has a backbone connection and area A's 329 ShortcutConfigured flag is set to Enable. 331 As in [Ref1] Shortcut ABRs identify themselves as ABRs by setting 332 the bit B in their Router-LSAs when they have more than one 333 attached area. 335 3.3 Changes to Routing Table Calculation 337 In order to maintain correct state of the ShortcutCapability 338 flag, steps 1 and 2 in section 16.1 of [Ref1] are changed as fol- 339 lows: 341 Step 1: 343 "Initialize the algorithm's data structures. Clear the 344 list of candidate vertices. Initialize the shortest-path 345 tree to only the root (which is the router doing the calcu- 346 lation). Set Area A's TransitCapability to FALSE. 347 ShortcutCapability flag is set as follow. 349 o If the router is not connected to the backbone and 350 Area A's ShortcutConfigured flag is NOT set to Dis- 351 able, or the router is connected to the backbone and 352 Area A's ShortcutConfigured flag is set to Enable, 353 set ShortcutCapability flag to TRUE. 355 o Otherwise, set Area A's ShortcutCapability flag to 356 FALSE." 358 Step 2: 360 "Call the vertex just added to the tree vertex V. Examine 361 the LSA associated with vertex V. This is a lookup in the 362 Area A's link state database based on the Vertex ID. If 363 this is a router-LSA, and bit V of the router-LSA (see Sec- 364 tion A.4.2) is set, set Area A's TransitCapability to TRUE. 366 If this is a router-LSA, and bit B of the router-LSA is set 367 (the router is an ABR), and bit S of the router-LSA is not 368 set (the ABR is either not Shortcut-capable or has a back- 369 bone connection and is not configured to use Area A for 370 shortcutting), and the ABR has a backbone connection, set 371 Area A's ShortcutCapability to FALSE. In any case, each 372 link described by the LSA gives the cost to an adjacent 373 vertex. For each described link, (say it joins vertex V to 374 vertex W):" 376 Note that the above algorithm, ensures that it is enough to check 377 only ShortcutCapability flag while deciding whether summary-LSAs 378 of a particular area should be considered or not. 380 The algorithm of calculating inter-area routes is changed as fol- 381 lows. 383 ABRs consider summary-LSAs only from those attached non-backbone 384 areas that have ShortcutCapability flag set to TRUE. This is 385 achieved by applying section 16.3 of [Ref1] to such areas. The 386 following changes to 16.3 are made. 388 Paragraph 1 of 16.3 is changed to be as follows: 390 "This step is only performed by area border routers attached 391 to one or more non-backbone areas that are either capable of 392 carrying transit traffic (i.e., "transit areas", or those 393 areas whose TransitCapability parameter has been set to TRUE 394 in Step 2 of the Dijkstra algorithm (see Section 16.1) or can 395 be used for shortcutting (those areas whose ShortcutCapability 396 parameter has NOT been set to FALSE during the Dijkstra algo- 397 rithm otherwise)." 399 Paragraph 4 of 16.3 is changed to be as follows: 401 "The calculation proceeds as follows. All summary-LSAs of the 402 areas with TransitCapability or ShortcutCapability parameter 403 set to TRUE are examined in turn. Each such summary-LSA 404 describes a route through a non-backbone area Area A to a Net- 405 work N (N's address is obtained by masking the LSA's Link 406 State ID with the network/subnet mask contained in the body of 407 the LSA) or in the case of a Type 4 summary-LSA, to an AS 408 boundary router N. Suppose also that the summary-LSA was ori- 409 ginated by an area border router BR." 411 Step (3) of the algorithm in 16.3 is changed to be as follows: 413 "Look up the routing table entry for N. (If N is an AS 414 boundary router, look up the "router" routing table entry 415 associated with the backbone area). If the route type is other 416 than backbone intra-area or inter-area (associated with any 417 area) then examine the next LSA. 419 In other words, this calculation updates backbone intra-area 420 routes found in Section 16.1, inter-area routes found in Sec- 421 tion 16.2 and installs new inter-area routes if the ABR does 422 not have a backbone connection." 424 Step (5) of the algorithm in 16.3 is changed to be as follows: 426 "If this cost is less than the cost occurring in N's routing 427 table entry, overwrite N's list of next hops with those used 428 for BR, and set N's routing table cost to IAC. Else, if IAC is 429 the same as N's current cost, add BR's list of next hops to 430 N's list of next hops. If the area associated with N's routing 431 table entry is the backbone, then the area and the type of the 432 path (either intra-area or inter-area) should remain 433 unchanged. Otherwise (the routing table entry does not exist 434 or the associated area is not the backbone), the type of the 435 route should be set to inter-area and associated area should 436 be set to the area associated with the summary-LSA being pro- 437 cessed." 439 In order to prevent routing loops, section 16.2 of [Ref1] is 440 changed. Step (3) of section 16.2 is changed to instruct the ABRs 441 to ignore summary defaults received from stub areas: 443 "If it is a Type 3 summary-LSA, and the collection of destina- 444 tions described by the summary-LSA equals one of the router's 445 configured area address ranges (see Section 3.5), and the par- 446 ticular area address range is active, then the summary-LSA 447 should be ignored. "Active" means that there are one or more 448 reachable (by intra-area paths) networks contained in the area 449 range. The summary-LSA should also be ignored if it is a sum- 450 mary default (Destination ID = DefaultDestination, Address 451 Mask = 0x00000000) and the area it has been received from is 452 a stub area. This is to prevent possible routing loops." 454 It is also reemphasized that routers are supposed to install dis- 455 card routing entries for active area ranges per 11.1 of [Ref1] 457 3.4 Changes to Summary-LSA Origination 459 The algorithm of the summary-LSAs origination is changed to 460 include an explicit restriction not to originate summary-LSAs for 461 inter-area routes if the route to the destination is not 462 associated with the backbone. 464 Note that if there are multiple alternative paths to a destina- 465 tion, some of which are via the backbone and the rest are via 466 non-backbone areas, the area associated with the corresponding 467 routing table entry will remain the backbone area, but the set of 468 next hops will actually direct traffic along the best path even 469 through non-backbone areas. 471 If the ABR in question has no backbone connection, it will not 472 originate summary-LSA for any inter-area route in any area, 473 because the area associated with the routing table entry will 474 never be the backbone area. 476 The ABR will also not readvertise an inter-area route from non- 477 backbone area if its backbone link state database does not con- 478 tain a summary-LSA, router-LSA, or network-LSA covering a 479 specific destination. 481 In order to implement described policy, the paragraph 2 in sec- 482 tion 12.4.3 of [Ref1] should be read as follows: 484 "... Note that only intra-area routes are advertised into the 485 backbone, while both intra-area and inter-area routes are 486 advertised into the other areas. Also, summary-LSAs for 487 inter-area routes are originated if and only if these routes 488 are associated with the backbone area (to prevent loops of 489 summary-LSAs)." 491 The 6th step of the algorithm given in sections 12.4.3 of [Ref1] 492 should be interpreted as shown below: 494 "Else, if the destination of this route is an AS boundary 495 router, a summary-LSA should be originated if and only if the 496 routing table entry describes the preferred path to the AS 497 boundary router (see Step 3 of Section 16.4) and it is associ- 498 ated with the backbone area. If so, a Type 4 summary-LSA is 499 originated for the destination, with Link State ID equal to 500 the AS boundary router's Router ID and metric equal to the 501 routing table entry's cost. Note: these LSAs should not be 502 generated if Area A has been configured as a stub area." 504 The 7th step of the algorithm given in sections 12.4.3 of [Ref1] 505 should be interpreted as shown below: 507 "Else, the Destination type is network. If this is an inter- 508 area route and it is associated with the backbone area, gen- 509 erate a Type 3 summary-LSA for the destination, with Link 510 State ID equal to the network's address (if necessary, the 511 Link State ID can also have one or more of the network's host 512 bits set; see Appendix E for details) and metric equal to the 513 routing table cost." 515 Described changes in the ABR behavior allow selection of most optimal 516 paths to inter-area and external destinations. Note that backbone 517 intra-area routes can be updated with better non-backbone inter-area 518 one, thus directing internal backbone traffic along more optimal 519 paths through other areas. 521 4 Implementation Details 523 If the current implementation of OSPF uses the standard described in 524 [Ref1], then support of the proposed Shortcut ABR behavior strategy 525 should be implemented as configurable options, allowing to change the 526 ABR behavior and set the ShortcutConfigured flag for a given area. 528 Note that the nature of the changes to OSPF presented in this docu- 529 ment is so that standard ABR behavior is not altered until at least 530 one area is used for shortcutting. 532 5 Compatibility 534 ABRs following the approach described in this document are required 535 to announce their Shortcut capability for a given area in Router- 536 LSAs. Since backbone-attached Shortcut ABRs do not consider Summary- 537 LSAs from an area until all ABRs agree on the S-bit, and ABRs not 538 attached to the backbone do not readvertise the inter-area routes, 539 the approach described in this document is compatible with standard 540 OSPF described in [Ref1]. 542 6 Deployment Considerations 544 This section discusses the deployment details of Shortcut ABR. 546 6.1 Necessity of Virtual Links 548 It should be repeated that Shortcut ABR behavior does not obviate the 549 need for virtual links in case an ABR has no physical backbone con- 550 nection. The difference with standard OSPF is that the administrator 551 does not need to configure virtual links through all areas he or she 552 wants the inter-area traffic to go through. Shortcut ABR needs a 553 single backbone connection (physical or virtual) to be able to rean- 554 nounce optimal inter-area routes to other areas. Note that it is not 555 necessary for a Shortcut ABR itself to have a backbone connection in 556 order to find the best inter-area paths, since it considers summary- 557 LSAs from all attached areas if the backbone is not configured. 559 6.2 Change of Traffic Patterns 561 Use of Shortcut ABR can lead to changes in the paths inter-area 562 traffic flows take comparing to those experienced with standard OSPF. 563 This happens because the Shortcut ABR approach allows a router to 564 find paths better than it is possible with the standard OSPF. While 565 standard OSPF tries to forward all inter-area traffic through the 566 backbone area (though it is not guaranteed), the Shortcut ABR finds 567 best routes in the domain even across non-backbone areas. With 568 Shortcut ABR the backbone area is used as a dedicated place of 569 inter-area routing information exchange and inter-area traffic is 570 allowed to cross non-backbone area borders if such a path is really 571 the best. 573 6.3 Optimized Inter-area Routing 575 Use of Shortcut ABR improves inter-area routing in OSPF domains by 576 allowing ABRs to consider summary-LSAs from all attached area and 577 consequently readvertise them into non-backbone areas. Consider an 578 example show in the Figure 2: 580 ....................... 581 . Backbone . ......... 582 . . . . 583 . +--+ +--+ . 584 . |R1| |R5|--| . 585 . +--+ +--+ 1| . 586 . 8/ 8\ 1/ . | . 587 . / \ -------- . | . 588 . 8/ 8\ /1 1\ . | Net N . 589 .+--+ +--+ +--+ 1| . 590 ......|R2|.....|R3|.......|R4|--| . 591 . +--+ +--+ +--+ . 592 . .|1 1/ \1 1/ . . Area 3 . 593 . .-------- -------- . .......... 594 . . . 595 . . . 596 .Area 1 . Area 2 . 597 ....... ................... 599 Figure 2. Optimized inter-area routing 601 In case all ABRs use standard OSPF approach, routing to the net N 602 would be as follows: 604 o R4 and R5 inject summary-LSAs into the backbone 605 o R4 also injects a summary-LSA into area 2 607 o R3 is limited to consider summary-LSAs from the backbone 608 only, so it doesn't see the alternative path through area 2 609 and always routes through the backbone (though parallel 610 paths are available) 612 o R3 injects summary-LSA for the inter-area routes derived 613 from the backbone summary-LSAs and received from R4 and R5 614 into Area 2 616 o R2 is not allowed to consider non-backbone summary-LSAs and 617 routes via serial links to R1, though more optimal paths do 618 exist 620 If R2, R3, and R4 use Shortcut ABR approach inter-area routing is 621 improved as shown below: 623 o R4 and R5 inject summary-LSAs into the backbone 625 o R4 also injects a summary-LSA into area 2 627 o R3 considers summary-LSAs from both attached areas and 628 installs the route through area 2 (it has three routes in 629 the routing table---via R5, via R4 through the backbone, and 630 via R4 through area 2) and performs traffic sharing between 631 the two ethernet links. 633 o R3 injects summary-LSA for the inter-area routes to N (it 634 will be the same as in the previous case, actually) 636 o R2 considers summary-LSAs from all attached areas and 637 prefers the route through area 2 rather than the backbone. 639 6.4 Gradual Deployment of Shortcut ABRs 641 Shortcut ABR behavior is designed in such a way that the administra- 642 tor can enable shortcutting through non-backbone OSPF areas gradu- 643 ally. 645 Since Shortcut ABRs are allowed to consider summaries only of those 646 areas that were configured as Shortcut (ShortcutConfigured flag in 647 area data structure is set to TRUE) and whose ShortcutCapability flag 648 is set to TRUE, it is easy to control which areas will accept addi- 649 tional inter-area traffic. For an area to become Shortcut-capable, 650 all ABRs that have links in it must agree on their configuration.. If 651 a single ABR in an area does not announce the S-bit in its Router-LSA 652 for this area, no other Shortcut ABRs connected to this area will 653 direct inter-area traffic through it (except for the cases when stan- 654 dard OSPF behavior leads to it). 656 The implementers should note that support of the configurable option 657 described in section 4 is very important for traffic control and suc- 658 cessful deployment. 660 7 Routing Loops in Transition Periods 662 As it was noted before standard OSPF ABR behavior uses DV approach to 663 distribute routing information among the areas. While the basic tech- 664 nique used in OSPF for this purpose provides loop-free environment, 665 existence of circular virtual link topology may lead to temporary 666 routing loops basically because of the section 16.3 that can update 667 backbone routes with non-backbone inter-area ones. The routing loops 668 formed in such situations are similar to those experienced in DV 669 routing protocols when the originator of a route loses its connec- 670 tivity to the network, sends messages withdrawing the route to all 671 neighbors, but not all messages manage to get through and the origi- 672 nator receives a false update from an upstream neighbor. An example 673 of such a temporary loop is illustrated in Figure 3. 675 In this example routers R1, R2, R3, and R4 are ABRs. All of them are 676 connected to the backbone ring that constitutes the backbone area. 677 Note that the link from R4 to the backbone ring (marked with aster- 678 isks) does not belong to area 2, but to the backbone area. The cost 679 of the backbone intra-area route between any given two ABRs is 10, 680 since they are all connected via a broadcast segment. The cost of 681 non-backbone intra-area path from R1 to R2, from R2 to R3, and from 682 R3 to R1 is 1. In this example, it doesn't matter what the cost 683 between R3 and R4 is. We are interested in network N residing in area 684 3. Both ABRs (R3 and R4) can reach this network. Suppose R3 can 685 reach it via a path with cost 1, while R4 via a path with cost 100. 686 Both routers announce summary-LSAs for network N into the backbone 687 area. If all ABRs follow the standard ABR behavior, and there are no 688 virtual links in the domain, R1 and R2 will install inter-area routes 689 to network N through the backbone area. If virtual links are esta- 690 blished between R1 and R2, R2 and R3, and R3 and R1, then routers R1 691 and R2 will choose more optimal paths through areas 4 and 2 692 correspondingly, according to the algorithm described in 16.3 of 694 [Ref1]. Also, R1 and R2 will announce summary-LSAs with cost 2 into 695 area 1, since inter-area routes to network N in their routing tables 696 are still backbone-associated. The same happens when R1, R2, and R3 697 are Shortcut-capable ABRs and agree to use areas 2 and 4 for 698 shortcutting. 700 .............. ................ 701 . . . . 702 . Area 1 +----+ Area 2 . 703 . ______| |________ . 704 . / 1| R2 |1 \ . 705 . / +----+ \ . 10 706 . / . 10| . *************** 707 . 1/ . | . * \1 . *--+ 708 +----+..... __|_ *......+----+....|R4|..... 709 | |10 / \ * 10| | +--+ . 710 | R1 |------* *--------| R3 | |100 . 711 +----+ \____/ +----+ 1 | . 712 . 1| . Backbone . |1.. \ | . 713 . | . . / . . \ | . 714 . | ................... / . . ----------- . 715 . | / . . Network N . 716 . \_______________________/ . . . 717 . . . Area 3 . 718 . Area 4 . ............ 719 ............................... 721 Figure 3. Sample topology with temporary routing loop 723 Now assume R3 loses its connectivity to area 3. After the routing 724 table is recalculated, R3 has an inter-area route to network N 725 through the backbone area via R4 with cost 110. R3 withdraws its 726 summary-LSA covering network N advertised into the backbone by flood- 727 ing corresponding MaxAge LSA (premature aging, as described in 14.1 728 of [Ref1]) and updates areas 2 and 4 with a new version of the 729 summary-LSA, containing the cost of 110. Now assume that R2 success- 730 fully receives and installs the new LSA, while R1 does not (due to 731 packet drops or other potential problems). R2 recalculates the rout- 732 ing table and installs the inter-area route via R1, because R1 did 733 not withdraw its summary-LSA with cost 2. After the new route is 734 installed into R2's routing table, R2 originates a summary-LSA for 735 network N with cost 3 into area 2. R3 uses this LSA to calculate the 736 route to N via R2 and announces a new summary-LSA with cost 4 into 737 area 4. This LSA is used by R1. A loop is formed. Note that R1, R2, 738 and R3 will not use the backbone path, because it will always be 739 updated by a non-backbone path with smaller metric. Described looping 740 stops when the cost of non-backbone inter-area path to network N 741 becomes greater than the cost of backbone-associated path, that is 742 greater than 110. 744 The loop described above is not Shortcut ABR-specific, i.e., it can 745 be seen even with standard ABR behavior when virtual links create a 746 circle. However, this document encourages administrators to configure 747 areas as shortcut and thus potentially increases the probability of 748 such a temporary loop. The author would like to emphasize that 1) 749 such routing loops are hardly to be seen in real networks with proper 750 domain design, and 2) even if such a loop forms, it is temporary, the 751 network finally converges and proper routes are installed. There 752 exist several methods to minimize the probability of described rout- 753 ing loop formation and to provide faster convergence in case a loop 754 has formed, but specification of these methods is outside the scope 755 of this document and will be delayed until the problem becomes 756 apparent. 758 8 Security Considerations 760 Shortcut ABR behavior specified in this document does not raise any 761 security issues that are not already covered in [Ref1]. 763 9 Appendixes 765 A.1 Router-LSA 767 An OSPF router originates a router-LSA into each of its attached 768 areas. The router-LSA describes the state and cost of the router's 769 interfaces to the area. The contents of the router-LSA are described 770 in detail in Section A.4.2 of [Ref1]. One more flag has been added 771 to the router-LSA, called bit S below. This flag indicates whether 772 the area has been configured as Shortcut on the ABR. See Sections 2 773 and 3 for more details. 775 0 1 2 3 776 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 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | LS age | Options | 1 | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Link State ID | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Advertising Router | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | LS sequence number | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | LS checksum | length | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | rtype | 0 | # links | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 790 | Link ID | P 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E 792 | Link Data | R 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Type | # TOS | TOS 0 metric | # 795 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L 796 # | TOS | 0 | metric | I 797 T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 798 O | ... | K 799 S +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S 800 | | TOS | 0 | metric | | 801 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 802 | ... | 804 The router LSA 806 +---+---+---+---+---+---+---+---+ 807 | * | * | S | Nt| W | V | E | B | 808 +---+---+---+---+---+---+---+-+-+ 810 The rtype field 812 The following defines the flags found in the rtype field. Each flag 813 classifies the router by function: 815 o bit B. When set, the router is an area border router (B is for 816 border). These routers forward unicast data traffic between OSPF 817 areas. 819 o bit E. When set, the router is an AS boundary router (E is for 820 external). These routers forward unicast data traffic between Auto- 821 nomous Systems. 823 o bit V. When set, the router is an endpoint of an active virtual 824 link (V is for virtual) which uses the described area as its Tran- 825 sit area. 827 o bit W. Used in MOSPF, when set, the router is a wild-card multicast 828 receiver. These routers receive all multicast datagrams, regardless 829 of destination. Inter-area multicast forwarders and inter-AS mul- 830 ticast forwarders are sometimes wild-card multicast receivers. 832 o bit Nt. Used in NSSA [Ref3], when set, the router is an NSSA border 833 router which is unconditionally translating type-7 LSAs into type-5 834 LSAs (Nt is for NSSA translation). 836 o bit S. When set, the router is a Shortcut-capable ABR and intends 837 to use the area for shortcutting provided that all other ABRs in 838 this area agree on that (also announce the S-bit into this area). 839 See sections 2 and 3 for more details. 841 10 References 843 [Ref1] J. Moy. OSPF version 2. Technical Report RFC 2328, Internet 844 Engineering Task Force, 1998. ftp://ftp.isi.edu/in- 845 notes/rfc2328.txt. 847 [Ref2] Zinin, Lindem, Yeung. Alternative OSPF ABR Implementations. 848 Work in progress, Internet Engineering Task Force. 849 http://www.ietf.org/internet-drafts/draft-ietf-ospf-abr-alt- 850 02.txt 852 [Ref3] Coltun, Fuller, Murphy. The OSPF NSSA Option. Work in 853 progress, Internet Engineering Task Force, 1999. 854 http://www.ietf.org/internet-drafts/draft-ietf-ospf-nssa- 855 update-08.txt 857 11 Author's Address 859 Alex Zinin 860 Cisco Systems 861 150 West Tasman Dr. 862 San Jose,CA 863 95134 864 E-mail: azinin@cisco.com