idnits 2.17.1 draft-ietf-tewg-interarea-mpls-te-req-01.txt: -(821): 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 5 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 639 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: The absence of a full link state topology database makes the computation of an end-to-end optimal path by the head-end LSR not possible without further signaling and routing extensions. There are several reasons that network operators choose to break up their network into different areas. These often include scalability and containment of routing information. The latter can help isolate most of a network from receiving and processing updates that are of no consequence to its routing decisions. Containment of routing information MUST not be compromised to allow inter-area traffic engineering. Information propagation for path-selection MUST continue to be localized. In other words, the solution MUST entirely preserve the concept of IGP hierarchy. == 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 'MUST not' in this paragraph: As already mentioned in 5.3, IGP hierarchy does not allow the Head-End LSR computing an end-to-end optimal path. Additional mechanisms are required to compute an optimal path. These additional mechanisms MUST not alter the IGP hierarchy principles. One solution could consist of extending the IGP for the leaking of summarized TE information across areas, but this would not scale: An ABR would have to compute and advertise summarized TE data for each potential destination and a large set of constraints combinations which would ineluctability have undesirable consequences in term of amount of flooded information and ABR CSPF computations. Thus, in order to maintain containment of routing information and preserve the overall IGP scalability, the solution MUST preclude the leaking across area of any TE link information summarized or not. == 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 (May 2004) is 7286 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'DS-TE-PROTO' is mentioned on line 229, but not defined == Missing Reference: 'LSP-PING' is mentioned on line 716, but not defined == Unused Reference: 'LSPPING' is defined on line 802, but no explicit reference was found in the text == Unused Reference: 'MPLS-ARCH' is defined on line 827, but no explicit reference was found in the text == Unused Reference: 'TE-APP' is defined on line 845, 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-04 == 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-07 -- 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. -------------------------------------------------------------------------------- 2 TEWG Working Group JL Le Roux,(Ed.) 3 Internet Draft France Telecom 4 JP Vasseur, (Ed.) 5 Cisco System Inc. 6 Jim Boyle, (Ed.) 7 PDNETs 8 Category: Informational 9 Expires: October 2004 May 2004 11 Requirements for Inter-area MPLS Traffic Engineering 13 draft-ietf-tewg-interarea-mpls-te-req-01.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document lists a detailed set of functional requirements for the 37 support of inter-area MPLS Traffic Engineering (inter-area MPLS TE) 38 which could serve as a guideline to develop the required set of 39 protocol extensions. 41 Conventions used in this document 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC-2119. 47 Table of Contents 49 1. Introduction................................................3 50 2. Contributing Authors........................................4 51 3. Terminology.................................................5 52 4. Current intra-area uses of MPLS Traffic Engineering.........5 53 4.1. Intra-area MPLS Traffic Engineering Applications............5 54 4.1.1. Intra-area resources optimization...........................5 55 4.1.2. Intra-area QoS guarantees...................................6 56 4.1.3. Fast recovery within an area................................6 57 4.2. Intra-area MPLS-TE and routing..............................7 58 5. Problem Statement, Requirements and Objectives of inter 59 area MPLS-TE..............................................8 60 5.1. Inter-Area Traffic Engineering Problem Statement............8 61 5.2. Requirements for inter-area MPLS-TE.........................9 62 5.3. Key Objectives for an inter-area MPLS-TE solution...........9 63 5.3.1. Preserve the IGP hierarchy concept..........................9 64 5.3.2. Preserve Scalability.......................................10 65 6. Application Scenario.......................................11 66 7. Detailed requirements for inter-area MPLS-TE...............12 67 7.1. Inter-area MPLS TE operations and interoperability.........12 68 7.2. Inter-Area TE-LSP signalling...............................12 69 7.3. Path optimality............................................12 70 7.4. Inter-Area MPLS-TE Routing.................................13 71 7.5. Inter-Area MPLS-TE Path computation........................13 72 7.6. Inter-area Crankback Routing...............................14 73 7.7. Support of diversely routed inter-area TE LSPs.............14 74 7.8. Intra/Inter-area Path selection policy.....................15 75 7.9. Reoptimization of inter-area TE LSP........................15 76 7.10. Inter-area LSP Recovery....................................16 77 7.10.1. Rerouting of inter-area TE LSPs...................... .....16 78 7.10.2. Fast recovery of inter-area TE LSP................... .....16 79 7.11. DS-TE support..............................................16 80 7.12. Hierarchical LSP support...................................16 81 7.13. Hard/Soft pre-emption......................................17 82 7.14. Auto-discovery of TE meshes................................17 83 7.15. Inter-area MPLS TE fault management requirements...........17 84 7.16. Inter-area MPLS-TE and routing.............................17 85 8. Evaluation criteria........................................18 86 8.1. Performances...............................................18 87 8.2. Complexity and risks.......................................18 88 8.3. Backward Compatibility.....................................18 89 9. Security Considerations....................................19 90 10. Acknowledgements...........................................19 91 11. Normative References.......................................19 92 12. Informative References.....................................20 93 13. Editors' Address:..........................................21 95 1. Introduction 97 The set of MPLS Traffic Engineering tools, defined in [RSVP-TE], 98 [OSPF-TE] and [ISIS-TE], that supports the requirements defined in 99 [TE-REQ], is used today by many network operators to achieve major 100 Traffic Engineering objectives defined in [TE-OVW] and summarized 101 below: 103 -Aggregated Traffic measurement 104 -Optimization of network resources utilization 105 -Support for services requiring end-to-end QoS guarantees 106 -Fast recovery against link/node/SRLG failures 108 However, the current set of MPLS Traffic Engineering mechanisms have 109 to date been limited to use within a single IGP area. 111 This document discusses the requirements for an inter-area MPLS 112 Traffic Engineering mechanism that may be used to achieve the same 113 set of objectives across multiple IGP areas. 115 Basically, it would be useful to extend MPLS TE capabilities across 116 IGP areas to support inter-area resources optimization, to provide 117 strict QoS guarantees between two edge routers located within 118 distinct areas, and to protect inter-area traffic against ABR 119 failures. 121 This document firstly addresses current uses of MPLS Traffic 122 Engineering within a single IGP area. This helps, then, in discussing 123 a set of functional requirements a solution must or should satisfy in 124 order to support inter-area MPLS Traffic Engineering. Since the scope 125 of requirements will vary between operators, some requirements will 126 be mandatory (MUST) whereas others will be optional (SHOULD). 127 Finally, a set of evaluation criteria for any solution meeting these 128 requirements is given. 130 2. Contributing Authors 132 This document was the collective work of several. The text and 133 content of this document was contributed by the editors and the 134 co-authors listed below (The contact information for the editors 135 appears in section 13, and is not repeated below): 137 Ting-Wo Chung Yuichi Ikejiri 138 Bell Canada NTT Communications Corporation 139 181 Bay Street, Suite 350, 1-1-6, Uchisaiwai-cho, 140 Toronto, Chiyoda-ku, Tokyo 100-8019 141 Ontario, Canada, M5J 2T3 JAPAN 142 Email: ting_wo.chung@bell.ca Email: y.ikejiri@ntt.com 144 Raymond Zhang Parantap Lahiri 145 Infonet Services Corporation MCI 146 2160 E. Grand Ave. 22001 loudoun Cty Pky 147 El Segundo, CA 90025 Ashburn, VA 20147 148 USA USA 149 Email: raymond_zhang@infonet.com E-mail: parantap.lahiri@mci.com 151 Kenji Kumaki 152 KDDI Corporation 153 Garden Air Tower 154 Iidabashi, Chiyoda-ku, 155 Tokyo 102-8460, 156 JAPAN 157 E-mail : ke-kumaki@kddi.com 159 3. Terminology 161 LSR: Label Switching Router 163 TE-LSP: MPLS Traffic Engineering Label Switched Path 165 Inter-area TE-LSP : TE-LSP whose head-end LSR and tail-end LSR do 166 not reside within the same IGP area or both head-end 167 LSR and tail-end LSR are in the same IGP area but the TE LSP 168 transiting path may be across different IGP areas. 170 IGP area: OSPF area or IS-IS level. 172 ABR: Area Border Router, router used to connect two IGP areas (ABR in 173 OSPF or L1/L2 router in IS-IS). 175 CSPF: Constraint-based Shortest Path First. 177 4. Current intra-area uses of MPLS Traffic Engineering 179 This section addresses capabilities and uses of MPLS-TE within a 180 single IGP area. It first addresses various capabilities offered by 181 these mechanisms and then lists various approaches to integrate MPLS- 182 TE into routing. This section is intended to help defining the 183 requirements for MPLS-TE extensions across multiple IGP areas. 185 4.1. Intra-area MPLS Traffic Engineering Applications 187 4.1.1. Intra-area resources optimization 189 MPLS-TE can be used within an area to redirect paths of aggregated 190 flows away from over-utilized resources within a network topology. In 191 a small scale, this may be done by explicitly configuring a path to 192 be used between two routers. In a grander scale, a mesh of LSPs can 193 be established between central points in a network. LSPs paths can be 194 defined statically in configuration or arrived at by an algorithm 195 that determines the shortest path given constraints such as bandwidth 196 or other administrative constraints. 197 In this way, MPLS-TE allows for greater control of how traffic 198 demands utilize a network topology. As mentioned in Section 1, uses 199 to date have been limited to within a single IGP area. 201 Note also that TE-LSPs allow to measure traffic matrix in a simple 202 and scalable manner. Basically, aggregated traffic rate between two 203 LSRs is easily measured by accounting of traffic sent onto a TE LSP 204 provisioned between the two LSRs in question. 206 4.1.2. Intra-area QoS guarantees 208 The DiffServ IETF working group has defined a set of mechanisms 209 described in [DIFF-ARCH], [DIFF-AF] and [DIFF-EF] or [MPLS-DIFF] that 210 can be activated at the edge or over a DiffServ domain to contribute 211 to the enforcement of a (set of) QoS policy(ies), which can be 212 expressed in terms of maximum one-way transit delay, inter-packet 213 delay variation, loss rate, etc. Many Operators have some or full 214 deployment of DiffServ implementations in their networks today, 215 either across the entire network or at least at the edge of the 216 network. 218 In situations where strict QoS bounds are required, admission control 219 inside the backbone of a network is in some cases required in 220 addition to current DiffServ mechanisms. When the propagation delay 221 can be bounded, the performance targets, such as maximum one-way 222 transit delay may be guaranteed by providing bandwidth guarantees 223 along the DiffServ-enabled path. 225 MPLS-TE can be simply used with DiffServ: in that case, it only 226 ensures aggregate QoS guarantees for the whole traffic. It can also 227 be more intimately combined with DiffServ to perform per-class of 228 service admission control and resource reservation. This requires 229 extensions to MPLS-TE called DiffServ Aware TE and defined in [DS-TE- 230 PROTO]. DS-TE allows ensuring strict end-to-end QoS guarantees. For 231 instance, an EF DS-TE LSP may be provisioned between voice gateways 232 within the same area to ensure strict QoS to VoIP traffic. 234 MPLS-TE allows computing intra-area shortest paths satisfying various 235 constraints including bandwidth. For the sake of illustration, if the 236 IGP metrics reflects the propagation delay, it allows finding a 237 minimum propagation delay path satisfying various constraints like 238 bandwidth. 240 4.1.3. Fast recovery within an area 242 As traffic sensitive applications are deployed, one of the key 243 requirements is to provide fast recovery mechanisms, allowing to 244 guarantee traffic recovery on the order of tens of msecs, in case of 245 network element failure. Note that this cannot be achieved by relying 246 only on IGP rerouting. 248 Various recovery mechanisms can be used to protect traffic carried 249 onto TE LSPs. They are defined in [MPLS-RECOV]. Protection mechanisms 250 are based on the provisioning of backup LSPs that are used to recover 251 traffic in case of failure of protected LSPs. Among those protection 252 mechanisms, local protection, also called Fast Reroute is intended to 253 achieve sub-50ms recovery in case of link/node/SRLG failure along the 254 LSP path [FAST-REROUTE]. Fast Reroute is currently used by many 255 operators to protect sensitive traffic inside an IGP area. 257 [FAST-REROUTE] defines two modes for backup LSPs. The first one, 258 called one-to-one backup, consists in setting up a detour LSP per 259 protected LSP and per element to protect. The second one called 260 facility-backup consists in setting up one or several bypass LSPs to 261 protect a given facility (link or node). In case of failure, all 262 protected LSPs are nested into the bypass LSPs (benefiting from the 263 MPLS label stacking property). 265 4.2. Intra-area MPLS-TE and routing 267 There are several possibilities to direct traffic into intra-area TE 268 LSPs: 270 1) Static routing to the LSP destination address or any other 271 addresses. 272 2) Traffic to the destination of the TE LSP or somewhere 273 beyond this destination from an IGP SPF perspective. 274 3) The LSP can be advertised as a link into the IGP to become 275 part of IGP database for all nodes, and thus taken into 276 account during SPF for all nodes. Note that, even if similar 277 in concept, this is different from the notion of Forwarding- 278 Adjacency, as defined in [LSP-HIER]. 279 4) Traffic sent to a set of routes announced by a (MP-)BGP 280 peer that is reachable through the TE-LSP by means of a 281 single static route to the corresponding BGP next-hop address 282 (2) or by means of IGP SPF (3). This is often called BGP 283 recursive routing. 285 5. Problem Statement, Requirements and Objectives of inter-area MPLS-TE 287 5.1. Inter-Area Traffic Engineering Problem Statement 289 As described in section 1, MPLS-TE is deployed today by many 290 operators to optimize network bandwidth usage, to provide strict QoS 291 guarantees and to ensure sub-50ms recovery in case of link/node/SRLG 292 failure. 294 However, MPLS-TE mechanisms are currently limited to a single IGP 295 area. This is basically due to the fact that hierarchy limits 296 topology visibility of head-end LSRs to their IGP area, and 297 consequently head-end LSRs can no longer run a CSPF algorithm to 298 compute the shortest constrained path to the tail-end. 300 Several operators have multi-area networks and many operators that 301 are still using a single IGP area may have to migrate to a multi-area 302 environment, as their network grows and single area scalability 303 limits are approached. 305 Hence, those operators may require inter-area traffic engineering to: 306 - Perform inter-area resource optimization. 307 - Provide inter-area QoS guarantees for traffic between edge 308 nodes located in different areas. 309 - Provide fast recovery across areas, to protect inter-area 310 traffic in case of link or node failure, including ABR node 311 failures. 313 For instance an operator running a multi-area IGP may have Voice 314 gateways located in different areas. Such VoIP transport requires 315 inter-area QoS guarantees and inter-area fast protection. 317 One possible approach for inter-area traffic engineering could 318 consist in deploying MPLS-TE on a per-area basis, but such an 319 approach has several limitations: 320 - Traffic aggregation at the ABR levels implies some constraints 321 that do no lead to efficient traffic engineering. Actually 322 such per-area TE approach might lead to sub-optimal resource 323 utilization, by optimizing resources independently in each 324 area. And what many operators want is to optimize their 325 resources as a whole, in other words as if there was only one 326 area (flat network). 327 - This does not allow computing an inter-area constrained 328 shortest path and thus does not ensure end-to-end QoS 329 guarantees across areas. 330 - Inter-area traffic cannot be protected with local protection 331 mechanisms such as [FAST-REROUTE] in case of ABR failure. 333 5.2. Requirements for inter-area MPLS-TE 335 For the reasons mentioned above, it is highly desired to extend the 336 current set of MPLS-TE mechanisms across multiple IGP areas in order 337 to support the intra area applications described in section 1 across 338 areas. 340 Basically, the solution MUST allow setting up inter-area TE LSPs, ie 341 LSPs whose path crosses at least two IGP areas. 343 Inter-area MPLS-TE extensions are highly desired to provide: 344 - Inter-area resources optimization. 345 - Strict inter-area QoS guarantees. 346 - Fast recovery across areas, particularly in order to protect 347 inter-area traffic against ABR failures. 349 It may be desired to compute inter-area shortest path that satisfy 350 some bandwidth constraints or any other constraints, as currently 351 possible within a single IGP area. For the sake of illustration, if 352 the IGP metrics reflects the propagation delay, it may be needed to 353 be able to find the optimal (shortest) path satisfying some 354 constraints (i.e bandwidth) across multiple IGP areas: such a path 355 would be the inter-area path offering the minimal propagation delay. 357 Thus the solution SHOULD provide the ability to compute inter-area 358 shortest paths satisfying a set of constraints (i.e. bandwidth). 360 5.3. Key Objectives for an inter-area MPLS-TE solution 362 Any solution for inter-area MPLS-TE should be designed having as key 363 objectives to preserve IGP hierarchy concept, and to preserve routing 364 and signaling scalability. 366 5.3.1. Preserve the IGP hierarchy concept 368 The absence of a full link state topology database makes the 369 computation of an end-to-end optimal path by the head-end LSR not 370 possible without further signaling and routing extensions. There are 371 several reasons that network operators choose to break up their 372 network into different areas. These often include scalability and 373 containment of routing information. The latter can help isolate most 374 of a network from receiving and processing updates that are of no 375 consequence to its routing decisions. Containment of routing 376 information MUST not be compromised to allow inter-area traffic 377 engineering. Information propagation for path-selection MUST continue 378 to be localized. In other words, the solution MUST entirely preserve 379 the concept of IGP hierarchy. 381 5.3.2. Preserve Scalability 383 Being able to achieve the requirements listed in this document MUST 384 be performed while preserving the IGP scalability, which is of the 385 utmost importance. The hierarchy preservation objective addressed in 386 the above section is actually an element to preserve IGP scalability. 387 The solution MUST also not increase IGP load which could compromise 388 IGP scalability. In particular, a solution satisfying those 389 requirements MUST not require for the IGP to carry some unreasonable 390 amount of extra information and MUST not unreasonably increase the 391 IGP flooding frequency. 393 Likewise, the solution MUST also preserve scalability of RSVP-TE 394 ([RSVP-TE]). 396 Additionally, the base specification of MPLS TE is architecturally 397 structured and relatively devoid of excessive state propagation in 398 terms of routing or signaling. Its strength in extensibility can 399 also be seen as an Achilles heel, as there is really no limit to 400 what is possible with extensions. It is paramount to maintain 401 architectural vision and discretion when adapting it for use for 402 inter-area MPLS-TE. Additional information carried within 403 an area, or propagated outside of an area (via routing or 404 signaling) should neither be excessive, patchwork, nor 405 non-relevant. 407 Particularly, as mentioned in 5.2 it may be desired, for some inter- 408 area TE LSP carrying highly sensitive traffic, to compute a shortest 409 inter-area path satisfying a set of constraints like bandwidth. This 410 may require an additional routing mechanism, as base CSPF at head-end 411 can not longer be used due to the lack of topology and resources 412 information. Such routing mechanism MUST not compromise the 413 scalability of the overall system. 415 6. Application Scenario 417 ---area1--------area0------area2-- 418 ------R1-ABR1-R2-------ABR3------- 419 | \ | / | | 420 | R0 \ | / | R4 | 421 | R5 \ |/ | | 422 ---------ABR2----------ABR4------- 424 - ABR1, ABR2: Area0-Area1 ABRs 425 - ABR3, ABR4: Area0-Area2 ABRs 427 - R0, R1, R5: LSRs in area 1 428 - R2: an LSR in area 0 429 - R4: an LSR in area 2 431 Although the terminology and examples provided in this document make 432 use of the OSPF terminology, this document equally applies to IS-IS. 434 Typically, an inter-area TE LSP will be set up between R0 and R4 435 where both LSRs belong to different IGP areas. Note that the solution 436 MUST support the capability to protect such an inter-area TE LSP from 437 the failure on any link/SRLG/Node within any area and the failure of 438 any traversed ABR. For instance, if the TE-LSP R0->R4 goes through 439 R1->ABR1->R2, then it can be protected against ABR1 failure, thanks 440 to a backup LSP (detour or bypass) that may follow the alternate path 441 R1->ABR2->R2. 443 For instance R0 and R4 may be two voice gateways located in distinct 444 areas. An inter-area DS-TE LSP with class-type EF, is setup from R1 445 to R4 to route VoIP traffic classified as EF. Per-class inter-area 446 constraint based routing allows to route the DS-TE LSP over a path 447 that will ensure strict QoS guarantees for VoIP traffic. 449 In another application R0 and R4 may be two pseudo wire gateways 450 residing in different areas. An inter-area LSP may be setup to carry 451 pseudo wire connections. 453 In some cases, it might also be possible to have an inter-area TE LSP 454 from R0 to R5 transiting via the backbone area (or any other levels 455 with IS-IS). Basically, there may be cases where there is no longer 456 enough resources on any intra area path R0-to-R5, while there is a 457 feasible inter-area path through the backbone area. 459 7. Detailed requirements for inter-area MPLS-TE 461 7.1. Inter-area MPLS TE operations and interoperability 463 The inter-area MPLS TE solution MUST be consistent with requirements 464 discussed in [TE-REQ] and the derived solution MUST be such that it 465 will interoperate seamlessly with current intra-area MPLS TE 466 mechanisms and inherit its capability sets from [RSVP-TE]. 468 The proposed solution MUST allow provisioning at the head-end with 469 end-to-end RSVP signalling (potentially with loose paths) traversing 470 across the interconnected ABRs, without further provisioning required 471 along the transit path. 473 7.2. Inter-Area TE-LSP signalling 475 The solution MUST allow for the signalling of inter-area TE-LSPs, 476 using RSVP-TE. 478 If multiple signalling methods are proposed in the solution, the 479 head-end LSR MUST have the ability to signal the required or desired 480 method on a per-LSP basis. 482 The proposed solution MUST allow the head-end LSR to explicitly 483 specify a set of LSRs, including ABRs, by means of strict or loose 484 hops for the inter-area TE LSP. 486 In addition, the proposed solution SHOULD also provide the ability to 487 specify and signal certain resources to be explicitly excluded in the 488 inter-area TE LSP path establishment. 490 7.3. Path optimality 492 In the context of this requirement document, an optimal path is 493 defined as the shortest path across multiple areas taking into 494 account either the IGP or TE metric [METRIC]. In other words, such a 495 path is the path that would have been computed making use of some 496 CSPF algorithm in the absence of multiple IGP areas. 498 As already mentioned in 5.2, the solution SHOULD provide the 499 capability to dynamically compute an optimal path satisfying a set of 500 specified constraints defined in [TE-REQ] across multiple IGP areas. 501 Note that this requirement document does not mandate that all inter- 502 area TE LSPs require the computation of an optimal (shortest) inter- 503 area path: some inter-area TE LSP paths may be computed via some 504 mechanisms not guaranteeing an optimal end to end path whereas some 505 other inter-area TE LSP paths carrying sensitive traffic could be 506 computed making use of some mechanisms allowing to dynamically 507 compute an optimal end-to-end path. Note that regular constraints 508 like bandwidth, affinities, IGP/TE metric optimization, path 509 diversity, etc, MUST be taken into account in the computation of an 510 optimal end-to-end path. 512 7.4. Inter-Area MPLS-TE Routing 514 As already mentioned in 5.3, IGP hierarchy does not allow the Head- 515 End LSR computing an end-to-end optimal path. Additional mechanisms 516 are required to compute an optimal path. These additional mechanisms 517 MUST not alter the IGP hierarchy principles. 518 One solution could consist of extending the IGP for the leaking of 519 summarized TE information across areas, but this would not scale: An 520 ABR would have to compute and advertise summarized TE data for each 521 potential destination and a large set of constraints combinations 522 which would ineluctability have undesirable consequences in term of 523 amount of flooded information and ABR CSPF computations. 524 Thus, in order to maintain containment of routing information and 525 preserve the overall IGP scalability, the solution MUST preclude the 526 leaking across area of any TE link information summarized or not. 528 Conversely, this does not preclude the leaking of non topology 529 related information, that are not taken into account during path 530 selection, such as static TE Node information like TE router ids or 531 TE node capabilities. 533 7.5. Inter-Area MPLS-TE Path computation 535 Several methods may be used for path computation, as follows: 537 -Per-area path computation based on ERO expansion on the Head- 538 End LSR and on ABRs, with two options for ABR selection: 539 -Static configuration of ABRs as loose hops at the head-end LSR. 540 -Dynamic ABR selection. 542 -Inter-area end-to-end path computation, that may be 543 based for instance on a recursive constraint based searching 544 thanks to collaboration between ABRs. 546 Note that any path computation method may be used provided that it 547 respect key objectives pointed out in 5.3. 549 In case a solution supports more than one method, it SHOULD allow the 550 operator to select by configuration, and on a per-LSP basis, the 551 desired option. 553 7.6. Inter-area Crankback Routing 555 Crankback routing, as defined in [CRANKBACK] may be used for inter- 556 area TE-LSP. Basically for paths computed thanks to ERO expansions 557 with a dynamic selection of downstream ABRs, crankback routing can be 558 used when there is no feasible path from a selected downstream ABR to 559 the destination: The upstream ABR or Head-End LSR, selects another 560 downstream ABR, and perform ERO expansion. 561 Note that such method does not allow computing and optimal path but 562 just a feasible path. 563 Note also that there can be 0(N^2) LSP setup failures before finding 564 a feasible path where N is the average number of ABR between two 565 areas. This may have a non negligible impact on the LSP setup delay. 567 Crankback may also be used for inter-area LSP recovery: Basically in 568 case a link/node/SRLG failure occurs in the backbone or tail-end 569 area, the ABR upstream to the failure computes an alternate path an 570 reroutes locally the LSP. 572 An inter-area MPLS-TE solution MAY support [CRANKBACK]. 573 A solution that supports [CRANKBACK], MUST allow to 574 activate/deactivate it via signaling, on a per-LSP basis. 576 7.7. Support of diversely routed inter-area TE LSPs 578 There are several cases where the ability to compute diversely routed 579 TE LSP paths may be desirable. For instance, in case of LSP 580 protection, primary and backup LSPs should be diversely routed. 581 Another example is the requirement to set up multiple diversely 582 routed TE LSPs between a pair of LSRs residing in different IGP 583 areas. For instance when a single TE-LSP satisfying the bandwidth 584 constraint could not be found between two end-points, a solution 585 would consist of setting up multiple TE-LSPs such that the sum of 586 their bandwidth satisfy the bandwidth requirement. In this case, it 587 may be desirable to have these TE-LSPs diversely routed in order to 588 minimize the impact of a failure, on the traffic between the two end- 589 points. 591 Hence, the solution SHOULD be able to provide the ability to compute 592 diversely routed inter-area TE LSP paths. In particular, if such 593 paths obeying the set of constraints exist, the solution SHOULD be 594 able to compute them. For the sake of illustration, there are some 595 algorithms that may not always allow to find diversely routed TE LSPs 596 because they make use of a two steps approach that cannot guarantee 597 to compute two diversely routed TE LSP paths even if such a solution 598 exist. This is in contrast with other methods that simultaneously 599 compute the set of diversely routed paths and that can always find 600 such paths if they exist. Moreover, the solution SHOULD not require 601 extra-load in signalling and routing in order to reach that 602 objective. 604 7.8. Intra/Inter-area Path selection policy 606 For inter-area TE LSPs whose head-end and tail-end LSRs reside in the 607 same IGP area, there may be intra-area and inter-area feasible paths. 608 In case the shortest path is an inter-area path, an operator may 609 either want to avoid, as far as possible, crossing area and thus 610 prefer selecting a sub-optimal intra-area path, or conversely may 611 prefer to use a shortest path, even if it crosses areas. 612 Thus, the solution MUST allow to enable/disable IGP area crossing, on 613 a per-LSP basis, for TE LSPs whose head-end and tail-end reside in 614 the same IGP area. 616 7.9. Reoptimization of inter-area TE LSP 618 The solution MUST provide the ability to reoptimize in a non 619 disruptive manner (make before break) an inter-area TE LSP, should a 620 more optimal path appear in any traversed IGP area. The operator 621 should be able to parameter such a reoptimization on a timer or 622 event-driven basis. It should also be possible to trigger such a 623 reoptimization manually. 625 The solution SHOULD provide the ability to locally reoptimize and 626 inter-area TE-LSP within an area, i.e. retaining the same set of 627 transit ABRs. The reoptimization process in that case, MAY be 628 controlled by the inter-area head-end LSR or by an ABR. The ABR 629 should check for local optimality of the inter-area TE LSPs 630 established through it, based on a timer or triggered by an event. 631 Option of providing manual trigger to check for optimality should 632 also be provided. 634 The solution SHOULD also provide the ability to perform an end-to-end 635 reoptimization, resulting potentially in a change on the set of 636 transit ABRs. Such reoptimization can be controlled only by the HE 637 LSR. 639 In case of head-end control of reoptimization, the solution SHOULD 640 provide the ability for the inter-area head-end LSR to be informed of 641 the existence of a more optimal path in a downstream area and keep a 642 strict control on the reoptimization process. Hence, the inter-area 643 head-end LSR, once informed of a more optimal path in some downstream 644 IGP areas, could decide (or not) to gracefully perform a make-before- 645 break reoptimization, according to the inter-area TE LSP 646 characteristics. 648 7.10. Inter-area LSP Recovery. 650 7.10.1. Rerouting of inter-area TE LSPs 652 The solution MUST support rerouting of an inter-area TE LSP in case 653 of SRLG/link/node failure or pre-emption. Such rerouting may be 654 controlled by the Head-End LSR or by an ABR (see section 7.6 on 655 crankback). 657 7.10.2. Fast recovery of inter-area TE LSP 659 The solution MUST provide the ability to benefit from fast recovery 660 making use of the local protection techniques specified in [FAST- 661 REROUTE] in both the case of an intra-area network element failure 662 (link/SRLG/Node) and an ABR node failure. Note that different 663 protection techniques SHOULD be usable in different parts of the 664 network to protect an inter-area TE LSP. This is of the utmost 665 importance in particular in the case of an ABR node failure that 666 typically carries a great deal of inter-area traffic. Moreover, the 667 solution SHOULD allow computing and setting up a backup tunnel 668 following an optimal path that offers bandwidth guarantees during 669 failure along with other potential constraints (like bounded 670 propagation delay increase along the backup path). 672 7.11. DS-TE support 674 The proposed inter-area MPLS TE solution SHOULD also satisfy core 675 requirements documented in [DSTE-REQ] and interoperate seamlessly 676 with current intra-area MPLS DS-TE mechanism [DSTE-PROTO]. 678 7.12. Hierarchical LSP support 680 In case of large inter-area MPLS deployment potentially involving a 681 large number of LSRs, it can be desirable/necessary to introduce 682 some level of hierarchy in order to reduce the number of 683 states on LSRs (it is worth mentioning that such a solution implies 684 other challenges). Hence, the proposed solution SHOULD allow inter- 685 area TE LSP aggregation (also referred to as LSP nesting) such that 686 individual TE LSPs can be carried onto one or more aggregating 687 LSP(s). One such mechanism, for example is described in [LSP-HIER]. 689 7.13. Hard/Soft pre-emption 691 As defined in [MPLS-PREEMPT], there are two pre-emption models 692 applicable to MPLS: Soft and Hard Pre-emption 694 An inter-area MPLS-TE solution SHOULD support the two models. 696 In case of hard pre-emption, the pre-empted inter-area TE-LSP should 697 be rerouted, following requirements defined in section 7.10.1. 698 In case of soft pre-emption, the pre-empted inter-area TE-LSP should 699 be re-optimized, following requirements defined in section 7.9. 701 7.14. Auto-discovery of TE meshes 703 Because the number of LSRs participating in some TE mesh might be 704 quite large, it might be desirable to provide some discovery 705 mechanisms allowing an LSR to automatically discover the LSRs members 706 of the TE mesh(es) that it belongs to. The discovery mechanism SHOULD 707 be applicable across multiple IGP areas, and SHOULD not impact the 708 IGP scalability, provided that IGP extensions are used for such a 709 discovery mechanism. 711 7.15. Inter-area MPLS TE fault management requirements 713 The proposed solution SHOULD be able to interoperate with fault 714 detection mechanisms of intra-area MPLS TE. 716 The solution SHOULD support[LSP-PING] and [MPLS-TTL]. 718 The solution SHOULD also support for fault detection on backup LSPs, 719 in case [FAST-REROUTE] is deployed. 721 7.16. Inter-area MPLS-TE and routing 723 In the case of intra-area MPLS TE, there are currently several 724 possibilities to route traffic into an intra-area TE LSP. They are 725 listed in section 4.2. 727 In case of inter-area MPLS-TE, the solution MUST support static 728 routing into the LSP, and also BGP recursive routing with a static 729 route to the BGP next-hop address. 731 ABRs propagate IP reacheability information (summary LSA in OSPF and 732 IP reacheability TLV in ISIS), that MAY be used by the head-end LSR 733 to route traffic to a destination beyond the TE LSP tail-head LSR 734 (e.g. to an ASBR). 736 The advertisement of an inter-area TE LSP as a link into the IGP, to 737 attract traffic to an LSP source MUST be precluded when TE LSP head- 738 end and tail-end LSRs do not reside in the same IGP area. It MAY be 739 used when they reside in the same area. 741 8. Evaluation criteria 743 8.1. Performances 745 The solution SHOULD clearly be evaluated with respects to the 746 following criteria: 747 (1) Optimality of the computed inter-area TE LSP path. 748 (2) Optimality of the computed backup tunnel path protecting against 749 the failure of an ABR, capability to share bandwidth among backup 750 tunnels protecting independent facilities. 751 (3) Inter-area TE LSP set up time. 752 (4) RSVP-TE and IGP scalability (state impact, number of messages, 753 message size) 755 Other criteria may be added in further revisions of this document. 757 8.2. Complexity and risks 759 The proposed solution(s) SHOULD not introduce unnecessary complexity 760 to the current operating network to such a degree that it would 761 affect the stability and diminish the benefits of deploying such 762 solution over SP networks. 764 8.3. Backward Compatibility 766 The deployment of inter-area MPLS TE SHOULD not have impact on 767 existing MPLS TE mechanisms to allow for a smooth migration or co- 768 existence. In particular the solution SHOULD allow the setup of an 769 inter-area TE-LSP among transit LSRs that do not support inter-area 770 extensions, provided that these LSRs do not participate in the inter- 771 area TE procedure. For illustration purpose the solution MAY require 772 inter-area extensions on end-point LSRs an ABRs only. 774 9. Security Considerations 776 Inter-area MPLS-TE does not raise any new security issue, beyond 777 those of intra-area MPLS-TE. 779 10. Acknowledgements 781 We would like to thank Dimitri Papadimitriou for its useful comments 782 and suggestions. 784 11. Normative References 786 [TE-REQ] Awduche et. al., "Requirements for Traffic Engineering 787 over MPLS", RFC2702. 789 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 790 Extensions to OSPF Version 2", RFC3630. 792 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 793 Engineering", draft-ietf-isis-traffic-04.txt, work in progress. 795 [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 796 3209. 798 [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE 799 for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-04.txt, work 800 in progress. 802 [LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D.,Swallow, G., 803 Wadhwa, S., Bonica, R., " Detecting Data Plane Liveliness in MPLS", 804 Internet Draft "draft-ietf-mpls-lsp-ping-05.txt", work in progress. 806 [MPLS-TTL] Agarwal, R., et al, "Time to Live (TTL) Processing in MPLS 807 Networks", RFC 3443. 809 [LSP-HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized 810 MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, work in progress. 812 [MPLS-RECOV] V. Sharma, F. Hellstrand, "Framework for Multi-Protocol 813 Label Switching (MPLS)-based Recovery", RFC 3469. 815 [CRANKBACK] Farrel, A., Ed., "Crankback Signaling Extensions for MPLS 816 Signaling�, draft-ietf-ccamp-crankback-01.txt, work in progress. 818 [DSTE-REQ] Le faucheur, F., et al, � Requirements for Support of 819 Differentiated Services-aware MPLS Traffic Engineering�, RFC3564. 821 [DSTE-PROTO] Le faucheur, F., et al, �Protocol extensions for support 822 of Differentiated-Service-aware MPLS Traffic Engineering�, draft- 823 ietf-tewg-diff-te-proto-07.txt, work in progress. 825 12. Informative References 827 [MPLS-ARCH] Rosen, et. al., "Multiprotocol Label Switching 828 Architecture", RFC 3031. 830 [DIFF-ARCH] Blake, et. al., "An Architecture for Differentiated 831 Services", RFC 2475. 833 [DIFF-AF] Heinanen, et. al., "Assured Forwarding PHB Group", RFC 834 2597. 836 [DIFF-EF] Davie, et. al., "An Expedited Forwarding PHB (Per-Hop 837 Behavior)", RFC 3246. 839 [MPLS-DIFF] Le Faucheur, et. al., "MPLS Support of Differentiated 840 Services", RFC 3270. 842 [TE-OVW] Awduche, et. al., "Overview and Principles of Internet 843 Traffic Engineering", RFC 3272. 845 [TE-APP] Boyle, et. al., "Applicability Statement of Traffic 846 Engineering", RFC 3346. 848 [MPLS-PREEMPT] Farrel, A., "Interim Report on MPLS Pre-emption", 849 draft-farrel-mpls-preemption-interim-00.txt, work in progress. 851 [METRIC] Le Faucheur, et. Al., "Use of Interior Gateway Protocol 852 (IGP) Metric as a second MPLS Traffic Engineering Metric", draft- 853 ietf-tewg-te-metric-igp-02.txt, work in progress. 855 13. Editors' Address: 857 Jean-Louis Le Roux 858 France Telecom 859 2, avenue Pierre-Marzin 860 22307 Lannion Cedex 861 France 863 Jean-Philippe Vasseur 864 Cisco Systems, Inc. 865 300 Beaver Brook Road 866 Boxborough , MA - 01719 867 USA 868 Email: jpv@cisco.com 870 Jim Boyle 871 Email: jboyle@pdnets.com 873 Full Copyright Statement 875 "Copyright (C) The Internet Society (2004). All Rights Reserved. 877 This document and translations of it may be copied and furnished to 878 others, and derivative works that comment on or otherwise explain it 879 or assist its implementation may be prepared, copied, published and 880 distributed, in whole or in part, without restriction of any kind, 881 provided that the above copyright notice and this paragraph are 882 included on all such copies and derivative works. However, this 883 document itself may not be modified in any way, such as by removing 884 the copyright notice or references to the Internet Society or other 885 Internet organizations, except as needed for the purpose of 886 developing Internet standards in which case the procedures for 887 copyrights defined in the Internet Standards process must be 888 followed, or as required to translate it into languages other than 889 English. 891 The limited permissions granted above are perpetual and will not be 892 revoked by the Internet Society or its successors or assigns. 894 This document and the information contained herein is provided on an 895 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 896 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 897 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 898 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 899 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.