idnits 2.17.1 draft-leroux-tewg-interarea-mpls-te-req-00.txt: -(756): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 7 instances of lines with non-ascii characters in the document. 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 592 has weird spacing: '...case of head-...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Being able to achieve the requirements listed in this document MUST be performed while preserving the IGP scalability, which is of the utmost importance. The hierarchy preservation objective addressed in the above section is actually an element to preserve IGP scalability. The solution MUST also not increase IGP load which could compromise IGP scalability. In particular, a solution satisfying those requirements MUST not require for the IGP to carry some unreasonable amount of extra information and MUST not unreasonably increase the IGP flooding frequency. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Particularly, as mentioned in 5.2 it may be desired, for some inter-area TE LSP carrying highly sensitive traffic, to compute a shortest inter-area path satisfying a set of constraints like bandwidth. This may require an additional routing mechanism, as base CSPF at head-end can not longer be used due to the lack of topology and resources information. Such routing mechanism MUST not compromise the scalability of the overall system. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Hence, the solution SHOULD be able to provide the ability to compute diversely routed inter-area TE LSP paths. In particular, if such paths obeying the set of constraints exist, the solution SHOULD be able to compute them. For the sake of illustration, there are some algorithms that may not always allow to find diversely routed TE LSPs because they make use of a two steps approach that cannot guarantee to compute two diversely routed TE LSP paths even if such a solution exist. This is in contrast with other methods that simultaneously compute the set of diversely routed paths and that can always find such paths if they exist. Moreover, the solution SHOULD not require extra-load in signalling and routing in order to reach that objective. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Because the number of LSRs participating in some TE mesh might be quite large, it might be desirable to provide some discovery mechanisms allowing an LSR to automatically discover the LSRs members of the TE mesh(es) that it belongs to. The discovery mechanism SHOULD be applicable across multiple IGP areas, and SHOULD not impact the IGP scalability, provided that IGP extensions are used for such a discovery mechanism. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The proposed solution (s) SHOULD not introduce unnecessary complexity to the current operating network to such a degree that it would affect the stability and diminish the benefits of deploying such solution over SP networks. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The deployment of inter-area MPLS TE SHOULD not have impact on existing MPLS TE mechanisms to allow for a smooth migration or co-existence. -- 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 (February 2004) is 7376 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'DS-TE-PROTO' is mentioned on line 237, but not defined == Missing Reference: 'DSTE-PROTO' is mentioned on line 629, but not defined == Missing Reference: 'SOFT-PREEMPT' is mentioned on line 646, but not defined == Missing Reference: 'LSP-PING' is mentioned on line 663, but not defined == Unused Reference: 'LSPPING' is defined on line 736, but no explicit reference was found in the text == Unused Reference: 'MPLS-ARCH' is defined on line 765, but no explicit reference was found in the text == Unused Reference: 'TE-APP' is defined on line 783, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-04 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-lsp-fastreroute-03 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-crankback-01 -- Obsolete informational reference (is this intentional?): RFC 3272 (ref. 'TE-OVW') (Obsoleted by RFC 9522) Summary: 4 errors (**), 0 flaws (~~), 19 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEWG Working Group JL Le Roux,(Ed.) 3 Internet Draft France Telecom 5 JP Vasseur, (Ed.) 6 Cisco System Inc. 8 Jim Boyle, (Ed.) 9 PDNETs 11 Category: Informational 12 Expires: August 2004 February 2004 14 Requirements for Inter-area MPLS Traffic Engineering 16 draft-leroux-tewg-interarea-mpls-te-req-00.txt 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet- Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document lists a detailed set of functional requirements for the 40 support of inter-area MPLS Traffic Engineering (inter-area MPLS TE) 41 which could serve as a guideline to develop the required set of 42 protocol extensions. 44 Conventions used in this document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC-2119. 50 0. Summary 52 (This section to be removed before publication.) 54 0.1. Related I-d's 56 This draft is actually a merge of two previous requirements IDs 57 related to inter-area MPLS-TE requirements: 58 draft-boyle-tewg-interarea-reqts-01.txt 59 draft-leroux-tewg-inter-area-te-rqs-00.txt 61 Table of Contents 63 1. Introduction................................................3 64 2. Contributing Authors........................................4 65 3. Terminology.................................................5 66 4. Current intra-area uses of MPLS Traffic Engineering.........5 67 4.1. Intra-area MPLS Traffic Engineering Applications............5 68 4.1.1. Intra-area resources optimization...........................5 69 4.1.2. Intra-area QoS guarantees...................................6 70 4.1.3. Fast recovery within an area................................6 71 4.2. Intra-area MPLS-TE and routing..............................7 72 5. Problem Statement, Requirements and Objectives of inter 73 area MPLS-TE..............................................8 74 5.1. Inter-Area Traffic Engineering Problem Statement............8 75 5.2. Requirements for inter-area MPLS-TE.........................9 76 5.3. Key Objectives for an inter-area MPLS-TE solution...........9 77 5.3.1. Preserve the IGP hierarchy concept..........................9 78 5.3.2. Preserve Scalability.......................................10 79 6. Application Scenario.......................................11 80 7. Detailed requirements for inter-area MPLS-TE...............12 81 7.1. Inter-area MPLS TE operations and interoperability.........12 82 7.2. Protocol signalling and path computation...................12 83 7.3. Path optimality............................................13 84 7.4. Support of diversely routed inter-areas TE LSPs............13 85 7.5. Inter-area Path selection policy...........................14 86 7.6. Reoptimization of inter-area TE LSP........................14 87 7.7. Failure handling and rerouting of an inter-area LSP........15 88 7.8. Fast recovery of inter-area TE LSP.........................15 89 7.9. DS-TE support..............................................15 90 7.10. Hierarchical LSP support....................................15 91 7.11. Soft preemption.............................................15 92 7.12. Auto-discovery..............................................16 93 7.13. Inter-area MPLS TE fault management requirements............16 94 7.14. Inter-area MPLS-TE and routing..............................16 95 8. Evaluation criteria........................................17 96 8.1. Performances...............................................17 97 8.2. Complexity and risks.......................................17 98 8.3. Backward Compatibility.....................................17 99 9. Security Considerations....................................17 100 10. Normative References.......................................18 101 11. Informative References.....................................19 102 12. Editors' Address:..........................................19 104 1. Introduction 106 The set of MPLS Traffic Engineering tools, defined in [RSVP-TE], 107 [OSPF-TE] and [ISIS-TE], that supports the requirements defined in 108 [TE-REQ], is used today by many network operators to achieve major 109 Traffic Engineering objectives defined in [TE-OVW] and summarized 110 below: 112 -Aggregated Traffic measurement 113 -Optimization of network resources utilization 114 -Support for end-to-end services requiring QoS guarantees 115 -Fast recovery against link/node/SRLG failures 117 However, the current set of MPLS Traffic Engineering mechanisms have 118 to date been limited to use within a single IGP area. 120 This document discusses the requirements for an inter-area MPLS 121 Traffic Engineering mechanism that may be used to achieve the same 122 set of objectives across multiple IGP areas. 124 Basically, it would be useful to extend MPLS TE capabilities across 125 IGP areas to support inter-area resources optimization, to provide 126 strict QoS guarantees between two edge routers located within 127 distinct areas, and to protect inter-area traffic against ABR 128 failures. 130 This document first addresses current uses of MPLS Traffic 131 Engineering within a single IGP area. This helps, then, in discussing 132 a set of functional requirements a solution must or should satisfy in 133 order to support inter-area MPLS Traffic Engineering. Since the scope 134 of requirements will vary between operators, some requirements will 135 be mandatory (MUST) whereas others will be optional (SHOULD). 136 Finally, a set of evaluation criteria for any solution meeting these 137 requirements is given. 139 2. Contributing Authors 141 This document was the collective work of several. The text and 142 content of this document was contributed by the editors and the 143 co-authors listed below (The contact information for the editors 144 appears in section 10, and is not repeated below.): 146 Ting-Wo Chung Yuichi Ikejiri 147 Bell Canada NTT Communications Corporation 148 181 Bay Street, Suite 350, 1-1-6, Uchisaiwai-cho, 149 Toronto, Chiyoda-ku, Tokyo 100-8019 150 Ontario, Canada, M5J 2T3 JAPAN 151 Email: ting_wo.chung@bell.ca Email: y.ikejiri@ntt.com 153 Raymond Zhang Parantap Lahiri 154 Infonet Services Corporation MCI 155 2160 E. Grand Ave. 22001 loudoun Cty Pky 156 El Segundo, CA 90025 Ashburn, VA 20147 157 USA USA 158 Email: raymond_zhang@infonet.com E-mail: parantap.lahiri@mci.com 160 Kenji Kumaki 161 KDDI Corporation 162 Garden Air Tower 163 Iidabashi, Chiyoda-ku, 164 Tokyo 102-8460, 165 JAPAN 166 E-mail : ke-kumaki@kddi.com 167 3. Terminology 169 LSR: Label Switch Router 171 TE LSP: MPLS Traffic Engineering Label Switched Path 173 Inter-area TE-LSP : TE LSP whose head-end LSR and tail-end LSR do 174 not reside within the same IGP area or both head-end 175 LSR and tail-end LSR are in the same IGP area but the TE LSP 176 transiting path may be across different IGP areas. 178 IGP area: OSPF area or IS-IS level. 180 ABR: Area Border Router, router used to connect two IGP areas (ABR in 181 OSPF or L1/L2 router in IS-IS). 183 CSPF: Constraint-based Shortest Path First. 185 4. Current intra-area uses of MPLS Traffic Engineering 187 This section addresses capabilities and uses of MPLS-TE within a 188 single IGP area. It first addresses various capabilities offered by 189 these mechanisms and then lists various approaches to integrate MPLS- 190 TE into routing. This section is intended to help defining the 191 requirements for MPLS-TE extensions across multiple IGP areas. 193 4.1. Intra-area MPLS Traffic Engineering Applications 195 4.1.1. Intra-area resources optimization 197 MPLS-TE can be used within an area to redirect paths of aggregated 198 flows away from over-utilized resources within a network topology. In 199 a small scale, this may be done by explicitly configuring a path to 200 be used between two routers. In a grander scale a mesh of LSPs 201 between central points in a network can be established with the LSPs 202 configured with paths defined statically in configuration or arrived 203 at by an algorithm that determines the shortest path given 204 constraints such as bandwidth or other administrative constraints. 205 In this way, MPLS-TE allows for greater control of how traffic 206 demands utilize a network topology. As mentioned in Section 1, uses 207 to date have been limited to within a single IGP area. 209 Note also that TE LSPs allow to measure traffic matrix in a simple 210 and scalable manner. Basically, aggregated traffic rate between two 211 LSRs is easily measured by accounting of traffic sent onto a TE LSP 212 provisioned between the two LSRs in question. 214 4.1.2. Intra-area QoS guarantees 216 The DiffServ IETF working group has defined a set of mechanisms 217 described in [DIFF-ARCH], [DIFF-AF] and [DIFF-EF] or [MPLS-DIFF] that 218 can be activated at the edge or over a DiffServ domain to contribute 219 to the enforcement of a (set of) QoS policy(ies), which can be 220 expressed in terms of maximum one-way transit delay, inter-packet 221 delay variation, loss rate, etc. Many Operators have some or full 222 deployment of Diffserv implementations in their networks today, 223 either across the entire network or at least at the edge of the 224 network. 226 In situations where strict QoS bounds are required, admission control 227 inside the backbone of a network is in some cases required in 228 addition to current Diffserv mechanisms. When the propagation delay 229 can be bounded, the performance targets, such as maximum one-way 230 transit delay may be guaranteed by providing bandwidth guarantees 231 along the Diffserv-enabled path. 233 MPLS-TE can be simply used with DiffServ: in that case, it only 234 ensures aggregate QoS guarantees for the whole traffic. It can also 235 be more intimately combined with DiffServ to perform per-class of 236 service admission control and resource reservation. This requires 237 extensions to MPLS-TE called DiffServ Aware TE and defined in [DS-TE- 238 PROTO]. DS-TE allows ensuring strict end-to-end QoS guarantees. For 239 instance, an EF DS-TE LSP may be provisioned between voice gateways 240 within the same area to ensure strict QoS to VoIP traffic. 242 MPLS-TE allows computing intra-area shortest paths satisfying various 243 constraint including bandwidth. For the sake of illustration, if the 244 IGP metrics reflects the propagation delay, it allows finding a 245 minimum propagation delay path satisfying various constraints like 246 bandwidth. 248 4.1.3. Fast recovery within an area 250 As traffic sensitive applications are deployed, one of the key 251 requirements is to provide fast recovery mechanisms(on the order of 252 tens of msecs) in case of network element failure, which cannot be 253 achieved with current IGP. 255 Various recovery mechanisms can be used to protect traffic carried 256 onto TE LSPs. They are defined in [MPLS-RECOV]. Protection mechanisms 257 are based on the provisioning of backup LSPs that are used to recover 258 traffic in case of failure of protected LSPs. Among those protection 259 mechanisms, local protection, also called Fast Reroute is intended to 260 achieve sub-50ms recovery in case of link/node/SRLG failure along the 261 LSP path [FAST-REROUTE]. Fast Reroute is currently used by many 262 operators to protect sensitive traffic inside an IGP area. 264 [FAST-REROUTE] defines two modes for backup LSPs. The first one, 265 called one-to-one backup, consists in setting up a detour LSP per 266 protected LSP and per element to protect. The second one called 267 facility-backup consists in setting up one or several bypass LSPs to 268 protect a given facility (link or node). In case of failure, all 269 protected LSPs are nested into the bypass LSPs (benefiting from the 270 MPLS label stacking property). 272 4.2. Intra-area MPLS-TE and routing 274 There are several possibilities to direct traffic into intra-area TE 275 LSPs: 277 1) Static routing to the LSP destination address or any other 278 addresses, 279 2) Traffic to the destination of the TE LSP or somewhere 280 beyond this destination from an IGP SPF perspective. 281 3) The LSP can be advertised as a link into the IGP to become 282 part of IGP database for all nodes, and thus taken into 283 account during SPF for all nodes. Note that, even if similar 284 in concept, this is different from the notion of Forwarding- 285 Adjacency, as defined in [LSP-HIER]. 286 4) Traffic sent to a set of routes announced by a (MP-)BGP 287 peer that is reachable through the TE-LSP by means of a 288 single static route to the corresponding BGP next-hop address 289 (2) or by means of IGP SPF (3). This is often called BGP 290 recursive routing. 292 5. Problem Statement, Requirements and Objectives of inter-area MPLS-TE 294 5.1. Inter-Area Traffic Engineering Problem Statement 296 As described in section 1, MPLS-TE is deployed today by many 297 operators to optimize network bandwidth usage, to provide strict QoS 298 guarantees and to ensure sub-50ms recovery in case of link/node/SRLG 299 failure. 301 However, MPLS-TE mechanisms are currently limited to a single IGP 302 area. This is basically due to the fact that hierarchy limits 303 topology visibility of head-end LSRs to their IGP area, and 304 consequently head-end LSRs can no longer run a CSPF algorithm to 305 compute the shortest constrained path to the tail-end. 307 Several operators have multi-area networks and many operators that 308 are still using a single IGP area may have to migrate to a multi-area 309 environment, as their network grows and single area scalability 310 limits are approached. 312 Hence, those operators may require inter-area traffic engineering to: 313 - Perform inter-area resource optimization, 314 - Provide inter-area QoS guarantees for traffic between edge 315 nodes located in different areas, 316 - Provide fast recovery across areas, to protect inter-area 317 traffic in case of link or node failure, including ABR node 318 failures. 320 For instance an operator running a multi-area IGP may have Voice 321 gateways located in different areas. Such VoIP transport requires 322 inter-area QoS guarantees and inter-area fast protection. 324 One possible approach for inter-area traffic engineering could 325 consist in deploying MPLS-TE on a per-area basis, but such an 326 approach has several limitations: 327 - Traffic aggregation at the ABR levels implies some constraints 328 that do no lead to efficient traffic engineering. Actually 329 such per-area TE approach might lead to sub-optimal resource 330 utilization, by optimizing resources independently in each 331 area. And what many operators want is to optimize their 332 resources as a whole, in other words as if there was only one 333 area (flat network). 334 - This does not allow computing an inter-area constrained 335 shortest path and thus does not ensure end-to-end QoS 336 guarantees across areas. 337 - Inter-area traffic cannot be protected with local protection 338 mechanisms such as [FAST-REROUTE] in case of ABR failure. 340 5.2. Requirements for inter-area MPLS-TE 342 For the reasons mentioned above, it is highly desired to extend the 343 current set of MPLS-TE mechanism across multiple IGP areas in order 344 to support the intra area applications described in section 1 across 345 areas. 347 Basically, the solution MUST allow setting up inter-area TE LSPs, ie 348 LSPs whose path crosses at least two IGP areas. 350 Inter-area MPLS-TE extensions are highly desired to provide inter- 351 area resources optimization, to provide strict inter-area QoS 352 guarantees, and to provide fast recovery across areas, particularly 353 in order to protect inter-area traffic against ABR failures. 355 It may be desired to compute inter-area shortest path that satisfy 356 some bandwidth constraints or any other constraints, as currently 357 possible within a single IGP area. For the sake of illustration, if 358 the IGP metrics reflects the propagation delay, it may be needed to 359 be able to find the optimal (shortest) path satisfying some 360 constraints (i.e bandwidth) across multiple IGP areas: such a path 361 would be the inter-area path offering the minimal propagation delay. 363 Thus the solution SHOULD provide the ability to compute inter-area 364 shortest path satisfying a set of constraints (i.e. bandwidth). 366 5.3. Key Objectives for an inter-area MPLS-TE solution 368 Any solution for inter-area MPLS-TE should be designed having as key 369 objectives to preserve IGP hierarchy concept, and to preserve routing 370 and signaling scalability. 372 5.3.1. Preserve the IGP hierarchy concept 374 The absence of a full link state topology database makes the 375 computation of an end-to-end path by the head-end LSR not possible 376 without further signaling and routing extensions. There are several 377 reasons that network operators choose to break up their network into 378 different areas. These often include scalability and containment of 379 routing information. The latter can help isolate most of a network 380 from receiving and processing updates that are of no consequence to 381 its routing decisions. Containment of routing information should not 382 be compromised to allow inter-area traffic engineering. Information 383 propagation for path-selection should continue to be localized. These 384 requirements are summarized as follows: 385 The solution MUST entirely preserve the concept of IGP hierarchy. In 386 other words, flooding of TE link information across areas MUST be 387 avoided. 389 5.3.2. Preserve Scalability 391 Being able to achieve the requirements listed in this document MUST 392 be performed while preserving the IGP scalability, which is of the 393 utmost importance. The hierarchy preservation objective addressed in 394 the above section is actually an element to preserve IGP scalability. 395 The solution MUST also not increase IGP load which could compromise 396 IGP scalability. In particular, a solution satisfying those 397 requirements MUST not require for the IGP to carry some unreasonable 398 amount of extra information and MUST not unreasonably increase the 399 IGP flooding frequency. 401 Likewise, the solution must also preserve scalability of RSVP-TE 402 ([RSVP-TE]). 404 Additionally, the base specification of MPLS TE is architecturally 405 structured and relatively devoid of excessive state propagation in 406 terms of routing or signaling. Its strength in extensibility can 407 also be seen as an Achilles heel, as there is really no limit to 408 what is possible with extensions. It is paramount to maintain 409 architectural vision and discretion when adapting it for use for 410 inter-area MPLS-TE. Additional information carried within 411 an area, or propagated outside of an area (via routing or 412 signaling) should neither be excessive, patchwork, nor 413 non-relevant. 415 Particularly, as mentioned in 5.2 it may be desired, for some inter- 416 area TE LSP carrying highly sensitive traffic, to compute a shortest 417 inter-area path satisfying a set of constraints like bandwidth. This 418 may require an additional routing mechanism, as base CSPF at head-end 419 can not longer be used due to the lack of topology and resources 420 information. Such routing mechanism MUST not compromise the 421 scalability of the overall system. 423 6. Application Scenario 425 ---area1--------area0------area2-- 426 ------R1-ABR1-R2-------ABR3------- 427 | \ | / | | 428 | R0 \ | / | R4 | 429 | R5 \ |/ | | 430 ---------ABR2----------ABR4------- 432 - ABR1, ABR2: Area0-Area1 ABRs 433 - ABR3, ABR4: Area0-Area2 ABRs 435 - R0, R1, R5: LSRs in area 1 436 - R2: an LSR in area 0 437 - R4: an LSR in area 2 439 Although the terminology and examples provided in this document make 440 use of the OSPF terminology, this document equally applies to IS-IS. 442 Typically, an inter-area TE LSP will be set up between R0 and R4 443 where both LSRS belong to different IGP areas. Note that the solution 444 MUST support the capability to protect such an inter-area TE LSP from 445 the failure on any link/SRLG/Node within any area and the failure of 446 any traversed ABR. For instance, if the TE-LSP R0->R4 goes through 447 R1->ABR1->R2, then it can be protected against ABR1 failure, thanks 448 to a backup LSP (detour or bypass) that may follow the alternate path 449 R1->ABR2->R2. 451 For instance R0 and R4 may be two voice gateways located in distinct 452 areas. An inter-area DS-TE LSP with class-type EF, is setup from R1 453 to R4 to route VoIP traffic classified as EF. Per-class inter-area 454 constraint based routing allows to route the DS-TE LSP over a path 455 that will ensure strict QoS guarantees for VoIP traffic. 457 In another application R0 and R4 may be two pseudo wire gateways 458 residing in different areas. An inter-area LSP may be setup to carry 459 pseudo wire connections. 461 In some cases, it might also be possible to have an inter-area TE LSP 462 from R0 to R5 transiting via the back-bone area (or any other levels 463 with IS-IS). Basically, there may be cases where there is no longer 464 enough resources on intra area path R0-to-R5, while there is a 465 feasible inter-area path through the backbone area. 467 7. Detailed requirements for inter-area MPLS-TE 469 7.1. Inter-area MPLS TE operations and interoperability 471 The inter-area MPLS TE solution MUST be consistent with requirements 472 discussed in [TE-REQ] and the derived solution MUST be such that it 473 will interoperate seamlessly with current intra-area MPLS TE 474 mechanisms and inherit its capability sets from [RSVP-TE]. 476 The proposed solution MUST allow provisioning at the head-end with 477 end-to-end RSVP signalling (eventually with loose paths) traversing 478 across the interconnected ABRs, without further provisioning required 479 along the transit path. 481 7.2. Protocol signalling and path computation 483 The proposed solution MUST allow the head-end LSR to explicitly 484 specify a set of LSRs, including ABRs, by means of strict or loose 485 hops for the inter-area TE LSP. 487 In addition, the proposed solution SHOULD also provide the ability to 488 specify and signal certain resources to be explicitly excluded in the 489 inter-area TE LSP path establishment. 491 If multiple signalling methods are proposed in the solution (e.g. 492 contiguous LSP, stitched or nested LSP), the head-end LSR MUST have 493 the ability to signal the required signalling method on a per-LSP 494 basis. 496 Several options may be used for path computations among those 497 - Per-area path computation based on ERO expansion with two 498 options for ABR selection: 499 -Static loose hop ABR configuration at the head-end LSR. 500 -Dynamic loose hop ABR determination. 501 - Inter-area end-to-end path computation, that may be based for 502 instance on a recursive constraint based searching thanks to 503 collaboration between ABRs. 505 Note that any path computation method may be used provided that it 506 respect key objectives pointed out in 5.3 508 7.3. Path optimality 510 As already mentioned in 5.2, the solution SHOULD provide the 511 capability for the head-end LSR to dynamically compute an optimal 512 path satisfying a set of specified constraints defined in [TE-REQ] 513 across multiple IGP areas. Note that this requirement document does 514 not mandate that all inter-area TE LSP require the computation of an 515 optimal (shortest) inter-area path: some inter-area TE LSP path may 516 be computed via some mechanisms not guaranteeing an optimal end to 517 end path whereas some other inter-area TE LSP paths carrying 518 sensitive traffic could be computed making use of some mechanisms 519 allowing to dynamically compute an optimal end-to-end path. Note that 520 regular constraints like bandwidth, affinities, IGP/TE metric 521 optimization, path diversity, etc MUST also be taken into account in 522 the computation of an optimal end-to-end path. 524 In the context of this requirement document, an optimal path is 525 defined as the shortest path across multiple areas taking into 526 account either the IGP or TE metric. In other words, such a path is 527 the path that would have been computed making use of some CSPF 528 algorithm in the absence of multiple IGP areas. 530 Note that mechanism allowing to compute an optimal path are likely to 531 consume more CPU resources than mechanisms computing only sub-optimal 532 paths. So a solution should support both mechanism, and SHOULD allow 533 the operator to select by configuration, and on a per-LSP basis, the 534 required level of optimality. 536 7.4. Support of diversely routed inter-areas TE LSPs 538 There are several cases where the ability to compute diversely routed 539 TE LSP paths may be desirable. For instance, in case of LSP 540 protection, primary and backup LSPs should be diversely routed. 541 Another example is the requirement to set up multiple TE LSPs between 542 a pair of LSRs residing in different IGP areas in case a single TE 543 LSP satisfying the set of requirements could not be found. 545 Hence, the solution SHOULD be able to provide the ability to compute 546 diversely routed inter-area TE LSP paths. In particular, if such 547 paths obeying the set of constraints exist, the solution SHOULD be 548 able to compute them. For the sake of illustration, there are some 549 algorithms that may not always allow to find diversely routed TE LSPs 550 because they make use of a two steps approach that cannot guarantee 551 to compute two diversely routed TE LSP paths even if such a solution 552 exist. This is in contrast with other methods that simultaneously 553 compute the set of diversely routed paths and that can always find 554 such paths if they exist. Moreover, the solution SHOULD not require 555 extra-load in signalling and routing in order to reach that 556 objective. 558 7.5. Inter-area Path selection policy 560 For inter-area TE LSPs whose head-end and tail-end LSRs reside in the 561 same IGP area, there may be intra-area and inter-area feasible paths. 562 In case the shortest path is an inter-area path, an operator may 563 either want to avoid, as far as possible, crossing area and thus 564 prefer selecting a sub-optimal intra-area path, or conversely may 565 prefer to use a shortest path, even if it crosses areas. Thus, the 566 solution MUST allow to enable or disable IGP area crossing, for TE 567 LSPs whose head-end and tail-end reside in the same IGP area. 569 7.6. Reoptimization of inter-area TE LSP 571 The solution MUST provide the ability to reoptimize in a non 572 disruptive manner (make before break) an inter-area TE LSP, should a 573 more optimal path appear in any traversed IGP area. The operator 574 should be able to parameter such a reoptimization on a timer or 575 event-driven basis. It should also be possible to trigger such a 576 reoptimization manually. 578 The solution SHOULD provide the ability to locally reoptimize and 579 inter-area TE-LSP within an area, ie retaining the same set of 580 transit ABRs. The reoptimization process in that case, MAY be 581 controlled by the inter-area head-end LSR or by an ABR. The ABR 582 should check for local optimality of the inter-area TE LSPs 583 established through it, based on a timer or triggered by an event. 584 Option of providing manual trigger to check for optimality should 585 also be provided. 587 The solution SHOULD also provide the ability to perform an end-to-end 588 reoptimization, resulting potentially in a change on the set of 589 transit ABRs. Such reoptimizaiton can be controled only by the HE 590 LSR. 592 In case of head-end control of reoptimization, the solution SHOULD 593 provide the ability for the inter-area head-end LSR to be informed of 594 the existence of a more optimal path in a downstream area and keep a 595 strict control on the reoptimization process. Hence, the inter-area 596 head-end LSR, once informed of a more optimal path in some downstream 597 IGP areas, could decide (or not) to gracefully perform a 598 reoptimization, according to the inter-area TE LSP characteristics. 600 7.7. Failure handling and rerouting of an inter-area LSP. 602 In case of inter-area TE LSP failure in the backbone or tail-end 603 area, it may be interesting to allow the ABR upstream to the failure 604 to try to recover the LSP using a procedure such as defined in 605 [CRANKBACK]. This may reduce the recovery delay, but with the risk of 606 multiple crankbacks, and sub-optimality. 607 The solution SHOULD provide the ability to allow/disallow crankback 608 via signalling on a per-LSP basis. 610 7.8. Fast recovery of inter-area TE LSP 612 The solution MUST provide the ability to benefit from fast recovery 613 making use of the local protection techniques specified in [FAST- 614 REROUTE] in both the case of an intra-area network element failure 615 (link/SRLG/Node) and an ABR node failure. Note that different 616 protection techniques SHOULD be usable in different parts of the 617 network to protect an inter-area TE LSP. This is of the utmost 618 importance in particular in the case of an ABR node failure that 619 typically carries a great deal of inter-area traffic. Moreover, the 620 solution SHOULD allow computing and setting up a backup tunnel 621 following an optimal path that offers bandwidth guarantees during 622 failure along with other potential constraints (like bounded 623 propagation delay increase along the backup path). 625 7.9. DS-TE support 627 The proposed inter-area MPLS TE solution SHOULD also satisfy core 628 requirements documented in [DSTE-REQ] and interoperate seamlessly 629 with current intra-area MPLS DS-TE mechanism [DSTE-PROTO]. 631 7.10. Hierarchical LSP support 633 In case of large inter-area MPLS deployment potentially involving a 634 large number of LSRs, it can be desirable/necessary to introduce 635 some level of hierarchy in the core in order to reduce the number of 636 states on core LSRs (it is worth mentioning that such a solution 637 implies other challenges). Hence, the proposed solution SHOULD allow 638 inter-area TE LSP aggregation (also referred to as LSP nesting) such 639 that individual TE LSPs can be carried onto one or more aggregating 640 LSP(s). One such mechanism, for example is described in [LSP-HIER]. 642 7.11. Soft preemption 644 The solution SHOULD support the ability to make use of the soft 645 preemption mechanisms for inter-area TE LSP such as one defined in 646 [SOFT-PREEMPT]. 648 7.12. Auto-discovery 650 Because the number of LSRs participating in some TE mesh might be 651 quite large, it might be desirable to provide some discovery 652 mechanisms allowing an LSR to automatically discover the LSRs members 653 of the TE mesh(es) that it belongs to. The discovery mechanism SHOULD 654 be applicable across multiple IGP areas, and SHOULD not impact the 655 IGP scalability, provided that IGP extensions are used for such a 656 discovery mechanism. 658 7.13. Inter-area MPLS TE fault management requirements 660 The proposed solution SHOULD be able to interoperate with fault 661 detection mechanisms of intra-area MPLS TE. 663 The solution SHOULD support[LSP-PING] and [MPLS-TTL]. 665 7.14. Inter-area MPLS-TE and routing 667 In the case of intra-area MPLS TE, there are currently several 668 possibilities to route traffic into an intra-area TE LSP. They are 669 listed in section 4.2. 671 In case of inter-area MPLS-TE, the solution MUST support static 672 routing into the LSP (1), and also BGP recursive routing with a 673 static route to the BGP next-hop address. 675 ABRs propagate IP reacheability information (summary LSA in OSPF and 676 IP reacheability TLV in ISIS), that MAY be used by the head-end LSR 677 to route traffic to a destination beyond the TE LSP tail-head LSR 678 (e.g. to an ASBR). 680 The advertisement of an inter-area TE LSP as a link into the IGP, to 681 attract traffic to an LSP source MUST be precluded when TE LSP head- 682 end and tail-end LSRs do not reside in the same IGP area. It MAY be 683 used when they reside in the same area. 685 8. Evaluation criteria 687 8.1. Performances 689 The solution SHOULD clearly be evaluated with respects to the 690 following criteria: 691 (1) Optimality of the computed inter-area TE LSP path, 692 (2) Optimality of the computed backup tunnel path protecting against 693 the failure of an ABR, capability to share bandwidth among backup 694 tunnels protecting independent facilities. 695 (3) Inter-area TE LSP set up time, 696 (4) Scalability and state impact. 698 Other criteria may be added in further revisions of this document. 700 8.2. Complexity and risks 702 The proposed solution (s) SHOULD not introduce unnecessary complexity 703 to the current operating network to such a degree that it would 704 affect the stability and diminish the benefits of deploying such 705 solution over SP networks. 707 8.3. Backward Compatibility 709 The deployment of inter-area MPLS TE SHOULD not have impact on 710 existing MPLS TE mechanisms to allow for a smooth migration or co- 711 existence. 713 9. Security Considerations 715 Inter-area MPLS-TE does not raise any new security issue, beyond 716 those of intra-area MPLS-TE. 718 10. Normative References 720 [TE-REQ], Awduche et. al., "Requirements for Traffic Engineering 721 over MPLS", RFC2702, September 1999. 723 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 724 Extensions to OSPF Version 2", RFC3630, September 2003. 726 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 727 Engineering", draft-ietf-isis-traffic-04.txt (work in progress) 729 [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 730 3209, December 2001. 732 [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE 733 for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, 734 December 2003. 736 [LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D.,Swallow, G., 737 Wadhwa, S., Bonica, R., " Detecting Data Plane Liveliness in MPLS", 738 Internet Draft <draft-ietf-mpls-lsp-ping-02.txt>, October 2002. 739 (Work in Progress) 741 [MPLS-TTL] Agarwal, R., et al, "Time to Live (TTL) Processing in MPLS 742 Networks", RFC 3443 Updates RFC 3032) ", January 2003. 744 [LSP-HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized 745 MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, March 2002. 747 [MPLS-RECOV] V. Sharma, F. Hellstrand, "Framework for Multi-Protocol 748 Label Switching (MPLS)-based Recovery", RFC 3469, February 2003 750 [CRANKBACK] Farrel, A., Ed., "Crankback Signaling Extensions for MPLS 751 Signaling�, draft-ietf-ccamp-crankback-01.txt, January 2004. 753 [DSTE-REQ] Le faucheur, F., et al, � Requirements for Support of 754 Differentiated Services-aware MPLS Traffic Engineering�, RFC3564. 756 [DSTE-PROTO]Le faucheur, F., Ed., �Protocol extensions for support of 757 Differentiated-Service-aware MPLS Traffic Engineering�, draft-ietf- 758 tewg-diff-te-proto-06.txt, January 2004. 760 [SOFT-PREEMPT]Meyer, M., et al, �MPLS Traffic Engineering Soft 761 preemption�, draft-ietf-mpls-soft-preemption-01.txt, October 2003. 763 11. Informative References 765 [MPLS-ARCH], Rosen, et. al., "Multiprotocol Label Switching 766 Architecture", RFC 3031, January 2001 768 [DIFF-ARCH], Blake, et. al., "An Architecture for Differentiated 769 Services", RFC 2475, December 1998 771 [DIFF-AF], Heinanen,et. al., "Assured Forwarding PHB Group", RFC 772 2597, June 1999. 774 [DIFF-EF], Davie, et. al., "An Expedited Forwarding PHB (Per-Hop 775 Behavior)", RFC 3246, March 2002 777 [MPLS-DIFF], Le Faucheur, et. al., "MPLS Support of Differentiated 778 Services", RFC 3270, May 2002 780 [TE-OVW], Awduche, et. al., "Overview and Principles of Internet 781 Traffic Engineering", RFC 3272,May 2002 783 [TE-APP], Boyle, et. al., "Applicability Statement of Traffic 784 Engineering", RFC 3346, August 2002. 786 12. Editors' Address: 788 Jean-Louis Le Roux 789 France Telecom 790 2, avenue Pierre-Marzin 791 22307 Lannion Cedex 792 France 794 Jean-Philippe Vasseur 795 Cisco Systems, Inc. 796 300 Beaver Brook Road 797 Boxborough , MA - 01719 798 USA 799 Email: jpv@cisco.com 801 Jim Boyle 802 Email: jboyle@pdnets.com 804 Full Copyright Statement 806 "Copyright (C) The Internet Society (2004). All Rights Reserved. 808 This document and translations of it may be copied and furnished to 809 others, and derivative works that comment on or otherwise explain it 810 or assist its implementation may be prepared, copied, published and 811 distributed, in whole or in part, without restriction of any kind, 812 provided that the above copyright notice and this paragraph are 813 included on all such copies and derivative works. However, this 814 document itself may not be modified in any way, such as by removing 815 the copyright notice or references to the Internet Society or other 816 Internet organizations, except as needed for the purpose of 817 developing Internet standards in which case the procedures for 818 copyrights defined in the Internet Standards process must be 819 followed, or as required to translate it into languages other than 820 English. 822 The limited permissions granted above are perpetual and will not be 823 revoked by the Internet Society or its successors or assigns. 825 This document and the information contained herein is provided on an 826 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 827 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 828 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 829 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 830 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.