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