idnits 2.17.1 draft-venkatachalam-interarea-mpls-te-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 562 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 88 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'CRANKBACK' is defined on line 496, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CRANKBACK' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group, S.Venkatachalam 2 Internet Traffic Engineering Working Group D. Papadimitriou 3 Internet Draft Alcatel 4 Document: 5 draft-venkatachalam-interarea-mpls-te-02.txt S.Dharanikota 6 Expiration Date: June 2002 Nayna Networks 8 A Framework for the LSP Setup Across IGP Areas 9 for MPLS Traffic Engineering 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026 except that the right to produce 15 derivative works is not granted. 17 This document is an Internet-Draft and is NOT offered in accordance 18 with Section 10 of RFC2026, and the author does not provide the IETF 19 with any rights other than to publish as an Internet-Draft 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other groups 23 may also distribute working documents as Internet-Drafts. Internet- 24 Drafts are draft documents valid for a maximum of six months and may be 25 updated, replaced, or obsoleted by other documents at any time. It is 26 inappropriate to use Internet- Drafts as reference material or to cite 27 them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 1. Abstract 36 In this draft, we propose an architecture for the inter-area LSP setup 37 based on a combination of constraints. We derive the 38 architectural requirements for the routing protocols, signaling 39 protocols and the MIBs to support such an idea. We also demonstrate how 40 such a mechanism will reduce the crankback during LSP setup. A possible 41 outline of the modifications to the CSPF algorithm and examples are 42 presented. In the companion document [INTER_AREA_EXT] we elaborate on 43 the extensions required for such architecture. 45 2. Acronyms 47 ABR Area Border Router 48 AS Autonomous System 49 ASBR Autonomous System Border Router 50 CR-LDP Constraint Based Routing LDP 51 CSPF Constraint-based Shortest Path First 52 IGP Interior Gateway Protocol 53 ISP Internet Service Provider 54 LDP Label Distribution Protocol 55 LER Label Edge Router 56 LSA Link State Attribute 57 LSR Label Switch Router 58 LSP Label Switched Path 59 MIB Management Information Base 60 MPLS Multi Protocol Label Switching 61 RSVP Resource Reservation Protocol 62 TE Traffic Engineering 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in RFC-2119 [RFC2119]. 68 3. Introduction 70 The ISP's networks are divided into Autonomous Systems (ASs), where 71 each AS is divided into IGP areas to allow the hiding and aggregating 72 of routing information. Although this concept of hierarchical routing 73 by an IGP makes sense from the routing perspective, it is a bottleneck 74 for traffic engineering as it hides the path taken by a packet to 75 destinations in the other routing areas. Hence, from the TE 76 perspective, requirements such as path selection and crankback need 77 different architectural additions to the existing IGPs and signaling 78 protocols for inter-area LSP setup. 80 Traffic engineering practice currently involves the setup and use of 81 Label Switched Paths (LSPs) as dedicated bandwidth pipes between two 82 end points. LSPs can be setup across several routers, either through 83 the use of manually specified routes, or routes that are computed. The 84 routes can be computed offline through the use of a dedicated tool, or 85 through the use of online constraint based routing using an IGP 86 [IGP_REQ, RSVP_EXT]. From [TOOL_VS_RP] discussion, it is clear that traffic 87 engineering can be implemented with the help of tools and routing protocol 88 extensions, as initiated by [IGP_REQ]. This draft describes a framework for 89 inter-area LSP setup. 91 Inter-area routing is one of the main mechanisms used today to provide 92 scalability within a IGP routing domain. Refer to RFC2329 for details 93 regarding the usage of inter-area OSPF routing. 95 In our solution, we propose to send across IGP areas, the summary routes 96 containing TE route attributes, which will be used at both the ABRs, 97 and the ASBRs in their TE path computation. Since an off-line TE tool cannot 98 compute the complete explicit path from ASBR to ASBR (end to end within 99 the AS domain) unless it knows the complete routing table of the AS, 100 we expect to have loose path specification, which can be translated into 101 explicit path in steps at the intermediate ABRs. The solutions we are 102 providing in this draft are applicable to the destination networks inside 103 the AS or outside the AS. For the sake of simplicity we consider the 104 LER performing the CSPF inside a given autonomous system. 106 In section 4, we present the outline of the architecture, which will be 107 used to derive the routing and signaling requirements in section 5. We 108 present examples in section 6 to consolidate the ideas presented in 109 this document. Scalability issues of these solutions are discussed in 110 section 7. Security considerations, acknowledgements and references 111 follow in sections 8, 9 and 10 respectively. 113 4. Architecture 115 4.1. Definitions 117 LSP section: An LSP section is that part of the inter-area LSP, that 118 which lies completely inside an IGP area; the inter-area LSP is a 119 sequence of LSP sections, connected at the ABRs. Each LSP section lies 120 in a different area. 122 Head node of the LSP section: The head node of an LSP section is either 123 the originating node or transit ABR depending on whether the LSP 124 section is the first or a subsequent LSP section. The head node could also 125 be another LSP tunnel previously setup (allowing LSP hierarchy) or 126 forwarding adjacencies (FAs). 128 4.2. Approach 130 This draft presents an approach to solving the problem of LSP setup 131 across IGP areas, through the use of the following components: 133 - IGP intra-area TE advertisements [INTRA_AREA, IGP_REQ] 134 - IGP inter-area TE summary advertisements [INTER_TE_OSPF, 135 INTER_TE_EXT] and 136 - Extensions to the signaling protocols [INTER_TE_EXT] 138 Our approach relies on the inter-area summary TE resource availability 139 information to determine efficiently whether an inter-area path to the 140 destination is at all possible with the constraints given. This inter- 141 area TE resource availability information is obtained from the link 142 state IGPs based on TE extensions [INTER_TE_OSPF, INTER_TE_EXT]. 143 The TE summary information propagated into an area could be that of 144 forwarding adjacencies (FAs), in addition to networks. The TE summary 145 values may need to be propagated only for a limited number of important 146 exit points (LERs) in an area. 148 These extensions provide a means to summarize the TE resource 149 availability attributes of destinations outside an area and advertise 150 these summaries into the target area by its ABR. Our solution is 151 independent of the TE attributes that need to be summarized with some 152 restrictions as discussed in the following sections. Since these 153 summaries provide a clear picture of the resources available across 154 areas, the probability of encountering a node (in another area) where 155 resources cannot be allocated to the LSP, is minimized. The summary TE 156 resource availability information also helps in determining the ABR 157 that is "closest" to the destination in terms of the resources required 158 for the LSP section. This determination is similar to the route 159 calculation based on summarized routes across areas in the link state 160 IGPs. 162 At the originating node of the LSP, the ABR that is in the path to the 163 destination with the most resources is determined using the TE summary 164 LSAs. The originating node will then compute an intra-area path to this 165 ABR based on the constraints. Such an intra-area path computation will 166 be based on the intra-area TE LSAs [INTRA_AREA][IGP_REQ]. Once a path 167 to the ABR is determined, an LSP is setup from the originating node to 168 the ABR using the MPLS signaling mechanisms of RVSP-TE or CR-LDP. The 169 signaling mechanisms of RSVP-TE and CR-LDP will be extended to carry 170 the constraints of the LSP. Hence at the transit ABR, the original 171 constraints are available for any further routing calculations. 173 Once the first LSP section is setup up from the originating node of the 174 LSP to the ABR (say ABR1), ABR1 will try to setup the next LSP section. 175 If the final destination (of the inter-area LSP) is in one of ABR1's 176 directly connected areas, the next LSP section is the last LSP section 177 and terminates at the final destination of the inter-area LSP. Else, if 178 the final destination (of the inter-area LSP) is in an area that can 179 only be reached through another ABR (say ABR2), the next LSP section is 180 a transit LSP section between ABR1 and ABR2. 182 ABR1 will perform an intra-area route computation to determine a path 183 for the next LSP section based on the constraints. ABR1 will then 184 perform the signaling to setup this next LSP section. 186 If the LSP section just setup is the last LSP section, the constraint 187 based LSP setup process is complete. 189 Else, if the LSP section just setup is a transit LSP section to ABR2, 190 the process of setting up an new LSP section toward the destination 191 continues at ABR2, just like at ABR1. This process of setting up LSP 192 sections is iterative, till the destination node is reached. 194 If at any point in the LSP setup process an LSP setup is a failure, due 195 to unavailability of resources, the LSP setup cranks back to the 196 immediately preceding ABR. 198 4.3. The LSP setup process 200 The process of setting up an LSP across areas is as follows. For each 201 LSP section: 203 1. At the source, a trigger to setup the primary and the secondary paths 204 is received by the LSP setup module. 205 2. This module requests the routing module for a route to setup the 206 primary or secondary path. 207 3. The routing module determines the ABR that has the best possible 208 route based on the constraints, to the inter-area destination, 209 4. The routing module calculates an intra-area route from the head 210 node of the LSP section to the transit ABR that satisfies the constraints, 211 5. The signaling module performs signaling and sets up the LSP section 212 (intra-area) from the head node of the LSP section to the transit ABR. 213 6. At the transit ABR, the route computation is performed based on the LSP 214 constraints received via the LSP setup message 215 7. If the final destination is not in this area, repeat the setup 216 process of 3, 4, 5 and 6 for the next LSP section, with the transit 217 ABR at the head of the next LSP section. 218 8. If the final destination is in this area, calculate an intra-area 219 route from the transit ABR to the destination that satisfies the 220 constraints, then signal and setup the final LSP section completing 221 the inter-area LSP setup. 222 9. If the setup of any LSP section is a failure, then crankback to 223 the immediately preceding ABR and perform a new LSP section setup, up to a 224 maximum of certain number of attempts. 226 4.4 Routing algorithm 228 The routing process at the head node of each LSP section performs the 229 following calculation: 231 1. If the destination is in the same area, perform a complete intra- 232 area route calculation based on all the constraints. If such a path is 233 found, go to 4. 234 2. If the destination is outside the area, do the following 235 computation: 236 2.1 ABR-list = {list of all ABRs in the area} - 237 {list of ABRs notified as ineligible via crankback} 238 2.2 While (ABR-list != {}) /* do while ABR-list is not empty */ 239 { 240 2.2.1 Use the inter-area TE summary LSAs to determine 241 the ABR with the greatest resources that satisfies 242 the constraints 243 2.2.2 If no such ABR, break to 2.3. 244 2.2.3 Use the intra-area TE LSAs to determine a path 245 to the selected ABR that satisfies all the 246 constraints of the LSP 247 2.2.4 If such a path is found, goto 4 and start the 248 signaling process to setup the LSP section to the 249 selected ABR. 250 2.2.5 Else, ABR-list = ABR-list - {selected ABR} 251 } 252 2.3 ABR-list = {list of all ABRs in the area} - 253 {list of ABRs notified as ineligible via crankback} 254 3. No suitable route was found and the LSP setup is a failure -signal 255 back the error. 256 4. A route was found, start the signaling process. 258 In the case of backup LSP computation, the above algorithm applies with 259 the following changes: 261 1. In 2.1 and 2.3: ABR-list = {list of all ABRs in the area} 262 {list of ABRs notified as ineligible via crankback} - 263 {list of ABRs in the primary LSP} 264 2. In 2.2.3 calculate the inter-area path that doesn't include any 265 nodes in the primary path 267 The following sections detail the requirements for the routing and 268 signaling components, crankback and general applicability. 270 5. Requirements of the solution 272 The requirements of are separated into routing protocol requirements, 273 signaling protocol requirements and other requirements. 275 5.1. Requirements for the IGP 277 5.1.1. Intra-area requirements 279 The IGP SHOULD support [INTRA_TE] to advertise and distribute the TE 280 information of the interfaces of the area. When there is a request for 281 the setup of a constraint based LSP within the area, the IGP will 282 determine the best path that satisfies the constraints by performing a 283 CSPF computation on the TE resources of the area, as specified by the 284 intra-area TE-LSAs. 286 With respect to the setup of LSPs within an area, the constraints on 287 the LSP can be one or more of the TE attributes flooded by the IGP in 288 the intra-area TE LSA. 290 5.1.2. Inter-area requirements 292 The Inter-area TE summary information is used by the route computation 293 process: 295 - to determine if a path to the inter-area destination that 296 satisfies the constraints does exist, and 297 - to determine the ABR to reach the next area. 299 To do such a computation, the IGP SHOULD be able to support TE 300 attribute summarization across areas, such as in [INTER_TE_OSPF] and 301 [INTER_TE_EXT]. 303 To allow traffic engineering across areas, the ABRs of the IGP SHOULD 304 perform TE attribute summarization; similar to the route summarization 305 that is already a part of the link state IGPs. In the general case of 306 TE attribute summarization, any number of TE attributes such as 307 bandwidth, delay to a destination can be summarized. These attributes 308 can be summarized through the use of a dijkstra or dijkstra-like 309 algorithm depending on whether the TE attribute is an additive metric, 310 or Max-Min metric, or some other type. The value of the TE summary 311 attribute to a destination advertised by an ABR represents the TE 312 resources of the best path available from the ABR to that destination 313 based on that TE attribute alone. For example, the value of the 314 summarized unreserved bandwidth attribute may be defined as in 315 [INTER_TE_OSPF]: 317 "The unreserved bandwidth to the summary destination is the largest of 318 all path-unreserved bandwidths, each associated with a possible path to 319 the destination. The path-unreserved bandwidth is the smallest 320 unreserved bandwidth of all the links in the path. Hence, the 321 unreserved bandwidth is the maximum amount of traffic that can 322 currently be sent to that destination, the other traffic on the links 323 being steady." 325 The summarized TE attributes will be distributed inside the areas by 326 the use of new link state messages for the purpose in OSPF and ISIS as 327 defined in [INTER_TE_OSPF] and [INTER_TE_EXT]. 329 5.1.3. Virtual links (TBD) 331 5.2. Signaling requirements 333 The signaling requirements are divided into setting up the initial LSP 334 (both primary and backup) and usage of the crankback facility during 335 LSP setup. 337 5.2.1. LSP setup 339 5.2.1.1. Primary LSP setup 341 Signaling SHOULD be extended to carry the LSP setup constraints 342 [INTER_AREA_EXT], such as: 344 - constraint list (TE Attribute 1, ... , TE Attribute N) 346 Signaling SHOULD trigger IGP computation for the explicit route in an 347 area at the transit ABRs. 349 5.2.1.2. Setting up the backup LSP 351 As this architecture distributes the LSP setup decisions, the 352 intermediate ABRs SHOULD know the path taken by the primary and the 353 backup LSPs. This enables the signaling component to request for a 354 backup path that's different from the path taken by the primary LSP, 355 during backup LSP setup. Hence, signaling SHOULD be extended to carry 356 the complete path of the primary LSP when setting up the backup LSP. 358 The same mechanisms used for the primary LSP setup SHOULD be used for 359 the backup LSP setup also. During the computation of the backup LSP, 360 the algorithm SHOULD consider the guidelines proposed in section 4.3. 362 5.2.2. Crankback during LSP setup 364 Crankback in an area SHOULD always be performed from the upstream ABR 365 of that LSP section. The mechanisms defined in section 5.2.1 will be 366 used for the setting up of the primary or the backup LSP. If the path 367 is not available, the information will be sent to the immediately 368 preceding ABR to retry the setup. 370 If the node that returns the error is itself an ABR, this node should 371 not be tried in the following attempts. Hence, at the preceding ABR the 372 routing process will determine a new route after pruning the previously 373 selected but unsuccessful ABRs from the computation. 375 5.2.3. LSP section repair 377 An interesting bi-product for this draft is the section repair. This 378 draft considers repair of LSPs within a certain area - i.e., when 379 the failure is in a certain an LSP section is detected (during the data 380 transfer phase), an LSP section-level repair can be initiated. The 381 error information is sent back to the immediately preceding ABR where a 382 different path to the destination of the LSP section is determined, and 383 a new LSP section setup is attempted. If successful, then the new LSP 384 section is spliced in to repair the LSP. 386 5.3. MIB requirements 388 The configuration requirements for such an architecture can be divided 389 into: 391 - Routing configuration, such as constraint filtering 392 - LSP Setup configuration, such as constraints 393 - Signaling configuration, such as crankback in-progress notification 394 required etc. 396 These configuration items are further elaborated in the extensions to 397 the inter-area draft for the signaling and routing [INTER_AREA_EXT]. 399 6. Examples for inter-area LSP setup 401 Let us assume that, as shown in Figure 1, an autonomous system has 402 three areas, Area 1 with network N1, and area border routers ABR1, ABR3 403 with area 0; and Area 2 with network N2, with area border routers ABR 2 404 and ABR 4 with area 0. Consider the case when a router on N1 wishes to 405 setup an LSP to N2 with constraints: 407 6.1. Example for basic inter-area LSP setup 409 Single Autonomous System 411 Area 1 Area 0 Area 2 412 -------------------- ------------------ ------------------------ 413 | | | | | | 414 | |N1 PS1 ------- -------- PS3 |N2 | 415 | |-------------- |ABR1 |\ |ABR 2 | -------| | 416 | | ------- \ PS2 -------- / | | 417 | ------- \ -------- / | 418 | |ABR 3 | -----------|ABR 4 |-----/ | 419 | ------- -------- | 420 | | | | | | 421 -------------------- ------------------- ------------------------- 423 Legend: 424 N# - Network (Note: This could be outside or inside the AS) 425 PS# - Primary LSP Section Number 427 Figure 1: An example for basic LSP setup across areas in an autonomous 428 system 430 The originating router router determines the ABR to go through as ABR1 431 based on the TE summary LSA, and calculates the primary LSP section in its 432 area, Area 1. ABR1 performs a similar inter-area computation to pick ABR4, 433 and an intra-area computation to determine the path of the LSP section PS2. 434 At ABR4, similar route computations are performed followed by the signaling 435 setup of the section PS3, completing the setup of the desired LSP. 437 6.2. Backup LSP creation example 439 The same logic used in the previous case needs to be used except that 440 the path selected for the backup should be non-intersecting with the 441 above path. This can be done in a distributed manner if the primary LSP 442 path is known. 444 6.3. Example for crankback during LSP setup 446 Single Autonomous System 448 Area 1 Area 0 Area 2 449 -------------------- ------------------ ------------------------ 450 | | | | | | 451 | |N1 PS1 ------- PS2 -------- PS3 |N2 | 452 | |-------------- |ABR1 |--------------|ABR 2 |--------X-------| | 453 | | ------- -------- --|PS4 |------| | 454 | ------- -------- |-----| | 455 | |ABR 3 | |ABR 4 | | 456 | ------- -------- | 457 | | | | | | 458 -------------------- ------------------- ------------------------- 460 Legend: 461 N# - Network (Note: This could be outside or inside the AS) 463 Figure 2: An example for crankback LSP setup in an autonomous system 465 If PS3 fails, as shown in Figure 2, the crankback can be done from 466 ABR2 to by pass PS3. 468 7. Scalability 470 The architecture is scalable in terms of the TE summarized routing 471 information to be propagated since the most important LERs that need the 472 inter-area LSPs are the ASBRs and their associate networks. Also, the 473 use of FAs for the destination LERs/networks will further reduce the 474 TE summary information, allowing even better scalability. 476 The architecture proposed distributes the computation across various 477 routers in the network, avoiding the bottleneck due to the use of 478 designated path computation servers, and hence scales well for a large 479 number of LSPs. 481 8. Security considerations 483 Security issues will be considered in the later versions of the 484 document. 486 9. Acknowledgements 488 The authors thank Darek Skalecki on his insightful comments on the 489 draft. 491 10. References 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, March 1997 496 [CRANKBACK] A. Iwata, et. al., "Crankback Routing Extensions for CR-LDP," 497 499 [IGP_REQ] T. Li, G. Swallow, D. Awduche, "IGP Requirements for Traffic 500 Engineering with MPLS," 502 [INTER_AREA_EXT] S. Dharanikota, S. Venkatachalam, "OSPF, IS-IS, RSVP, 503 CR-LDP extensions to support inter-area traffic engineering using MPLS 504 TE," 506 [INTRA_AREA] D. Katz, D. Yeung, "Traffic Engineering Extensions to 507 OSPF," 509 [INTER_TE_OSPF] S. Venkatachalam, and B. Abarbanel, "OSPF Extensions to 510 Support Inter-Area Traffic Engineering," 513 [QOS_CONST] F. Le Faucheur et al., "Requirements for support of 514 DiffServ-aware MPLS Traffic Engineering," 517 [QOS_TE_EXT] F. Le Faucheur et al., "Extensions to IS-IS, OSPF, RSVP 518 and CR-LDP for support of DiffServ-aware MPLS Traffic Engineering," 519 521 [RSVP_EXT] D. Awduche et al., "Extensions to RSVP for LSP Tunnels," 522 524 [TE_FRAMEWORK] D. O. Awduche, et al., "A Framework for internet 525 Traffic Engineering," 527 [TOOL_VS_RP] "Internet Traffic Engineering working group mailing list 528 discussion on centralized tool based TE versus constraint-based routing 529 protocol extensions," ftp://ftpext.eng.uu.net/tewg 531 11. Authors' addresses 533 Senthil K. Venkatachalam 535 Alcatel 536 15036 Conference Center Drive 537 Chantilly, VA 20151 538 Email: senthil_v@lycos.com 539 Phone: (703)679-6435 541 Sudheer Dharanikota 543 Nayna Networks 544 157 Topaz Drive 545 Milpitas, CA 95035 546 Email: sudheer@nayna.com 547 Phone: (408)-956-8000 x357 549 Papadimitriou Dimitri 551 Alcatel � IPO NSG-NA 552 Francis Wellesplein 1, 553 B-2018 Antwerpen, Belgium 554 Phone: +32 3 240-8491 555 Email: dimitri.papadimitriou@alcatel.be