idnits 2.17.1 draft-ietf-ccamp-inter-domain-pd-path-comp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 899. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 876. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 883. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 889. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 7, 2006) is 6651 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2205' is defined on line 762, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-inter-domain-pd-path-comp' is defined on line 803, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2702 ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) ** Obsolete normative reference: RFC 4205 (Obsoleted by RFC 5307) == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-crankback-05 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-inter-domain-framework-04 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-inter-domain-pd-path-comp-01 == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-inter-domain-rsvp-te-02 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-lsp-stitching-02 == Outdated reference: A later version (-05) exists of draft-ietf-pce-architecture-04 Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group JP. Vasseur, Ed. 2 Internet-Draft Cisco Systems, Inc 3 Proposed Status: Standard A. Ayyangar, Ed. 4 Expires: August 11, 2006 Juniper Networks 5 R. Zhang 6 BT Infonet 7 February 7, 2006 9 A Per-domain path computation method for establishing Inter-domain 10 Traffic Engineering (TE) Label Switched Paths (LSPs) 12 draft-ietf-ccamp-inter-domain-pd-path-comp-02.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 11, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document specifies a per-domain path computation technique for 46 establishing inter-domain Traffic Engineering (TE) Multiprotocol 47 Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched 48 Paths (LSPs). In this document a domain refers to a collection of 49 network elements within a common sphere of address management or path 50 computational responsibility such as IGP areas and Autonomous 51 Systems. Per-domain computation applies where the full path of an 52 inter-domain TE LSP cannot be or is not determined at the ingress 53 node of the TE LSP, and is not signaled across domain boundaries. 54 This is most likely to arise owing to TE visibility limitations. The 55 signaling message indicates the destination and nodes up to the next 56 domain boundary. It may also indicate further domain boundaries or 57 domain identifiers. The path through each domain, possibly including 58 the choice of exit point from the domain, must be determined within 59 the domain. 61 Requirements Language 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC 2119 [RFC2119]. 67 Table of Contents 69 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. General assumptions . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. Common assumptions . . . . . . . . . . . . . . . . . . . . 5 73 3.2. Example of topology for the inter-area TE case . . . . . . 7 74 3.3. Example of topology for the inter-AS TE case . . . . . . . 7 75 4. Per-domain path computation procedures . . . . . . . . . . . . 9 76 4.1. Example with an inter-area TE LSP . . . . . . . . . . . . 12 77 4.1.1. Case 1: T0 is a contiguous TE LSP . . . . . . . . . . 12 78 4.1.2. Case 2: T0 is a stitched or nested TE LSP . . . . . . 13 79 4.2. Example with an inter-AS TE LSP . . . . . . . . . . . . . 13 80 4.2.1. Case 1: T1 is a contiguous TE LSP . . . . . . . . . . 14 81 4.2.2. Case 2: T1 is a stitched or nested TE LSP . . . . . . 14 82 5. Path optimality/diversity . . . . . . . . . . . . . . . . . . 15 83 6. Reoptimization of an inter-domain TE LSP . . . . . . . . . . . 15 84 6.1. Contiguous TE LSPs . . . . . . . . . . . . . . . . . . . . 15 85 6.2. Stitched or nested (non-contiguous) TE LSPs . . . . . . . 16 86 6.3. Path characteristics after reoptimization . . . . . . . . 17 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 92 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 94 Intellectual Property and Copyright Statements . . . . . . . . . . 21 96 1. Terminology 98 Terminology used in this document 100 ABR Routers: routers used to connect two IGP areas (areas in OSPF or 101 levels in IS-IS). 103 ASBR Routers: routers used to connect together ASes of a different or 104 the same Service Provider via one or more Inter-AS links. 106 Boundary LSR: a boundary LSR is either an ABR in the context of 107 inter-area TE or an ASBR in the context of inter-AS TE. 109 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 111 Inter-area TE LSP: A TE LSP that crosses an IGP area. 113 LSR: Label Switching Router. 115 LSP: Label Switched Path. 117 TE LSP: Traffic Engineering Label Switched Path. 119 PCE: Path Computation Element: an entity (component, application or 120 network node) that is capable of computing a network path or route 121 based on a network graph and applying computational constraints. 123 TED: Traffic Engineering Database. 125 The notion of contiguous, stitched and nested TE LSPs is defined in 126 [I-D.ietf-ccamp-inter-domain-framework] and will not be repeated 127 here. 129 2. Introduction 131 The requirements for inter-domain Traffic Engineering (inter-area and 132 inter-AS TE) have been developed by the Traffic Engineering Working 133 Group and have been stated in [RFC4105] and [RFC4216]. The framework 134 for inter-domain MPLS Traffic Engineering has been provided in 135 [I-D.ietf-ccamp-inter-domain-framework]. 137 Some of the mechanisms used to establish and maintain inter-domain TE 138 LSPs are specified in [I-D.ietf-ccamp-inter-domain-rsvp-te] and 139 [I-D.ietf-ccamp-lsp-stitching]. 141 This document exclusively focuses on the path computation aspects and 142 defines a method for establishing inter-domain TE LSP where each node 143 in charge of computing a section of an inter-domain TE LSP path is 144 always along the path of such TE LSP. 146 When the visibility of an end to end complete path spanning multiple 147 domains is not available at the Head-end LSR, one approach described 148 in this document consists of using a per-domain path computation 149 technique during LSP setup to determine the inter-domain TE LSP as it 150 traverses multiple domains. 152 The mechanisms proposed in this document are also applicable to MPLS 153 TE domains other than IGP areas and ASs. 155 The solution described in this document does not attempt to address 156 all the requirements specified in [RFC4105] and [RFC4216]. This is 157 acceptable according to [RFC4216] which indicates that a solution may 158 be developed to address a particular deployment scenario and might, 159 therefore, not meet all requirements for other deployment scenarios. 161 It must be pointed out that the inter-domain path computation 162 technique proposed in this document is one among many others and the 163 choice of the appropriate technique must be driven by the set of 164 requirements for the paths attributes and the applicability to a 165 particular technique with respect to the deployment scenario. For 166 example, if the requirement is to get an end-to-end constraint-based 167 shortest path across multiple domains, then a mechanism using one or 168 more distributed PCEs could be used to compute the shortest path 169 across different domains (see [I-D.ietf-pce-architecture]). Other 170 offline mechanisms for path computation are not precluded either. 171 Note also that a Service Provider may elect to use different inter- 172 domain path computation techniques for different TE LSP types. 174 3. General assumptions 176 3.1. Common assumptions 178 - Each domain in all the examples below is assumed to be capable of 179 doing Traffic Engineering (i.e. running OSPF-TE or ISIS-TE and 180 RSVP-TE). A domain may itself comprise multiple other domains. E.g. 181 An AS may itself be composed of several other sub-AS(es) (BGP 182 confederations) or areas/levels. In this case, the path computation 183 technique described for inter-area and inter-AS MPLS Traffic 184 Engineering just recursively applies. 186 - The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209]). 188 - The path (ERO) for an inter-domain TE LSP may be signaled as a set 189 of (loose and/or strict) hops. The hops may identify: 191 * The complete strict path end-to-end across different domains 193 * The complete strict path in the source domain followed by boundary 194 LSRs (or domain identifiers, e.g. AS numbers) 196 * The complete list of boundary LSRs along the path 198 * The current boundary LSR and the LSP destination. 200 The set of (loose or strict) hops can either be statically configured 201 on the Head-end LSR or dynamically computed. A per-domain path 202 computation method is defined in this document with an optional Auto- 203 discovery mechanism based on IGP and/or BGP information yielding the 204 next-hop boundary node (domain exit point, such as ABR/ASBR) along 205 the path as the TE LSP is being signaled, along with potential 206 crankback mechanisms. Alternatively the domain exit points may be 207 statically configured on the Head-end LSR in which case next-hop 208 boundary node auto-discovery would not be required. 210 - Boundary LSRs are assumed to be capable of performing local path 211 computation for expansion of a loose next-hop in the signaled ERO if 212 the path is not signaled by the Head-end LSR as a set of strict hops 213 or if the strict hop is an abstract node (e.g. an AS). In any case, 214 no topology or resource information needs to be distributed between 215 domains (as mandated per [RFC4105] and [RFC4216]), which is critical 216 to preserve IGP/BGP scalability and confidentiality in the case of TE 217 LSPs spanning multiple routing domains. 219 - The paths for the intra-domain Hierarchical LSPs (H-LSP) or S-LSPs 220 (S-LSP) or for a contiguous TE LSP within the domain may be pre- 221 configured or computed dynamically based on the arriving inter-domain 222 LSP setup request (depending on the requirements of the transit 223 domain). Note that this capability is explicitly specified as a 224 requirement in [RFC4216]. When the paths for the H-LSPs/S-LSP are 225 pre-configured, the constraints as well as other parameters like 226 local protection scheme for the intra-domain H-LSP/S-LSP are also 227 pre-configured. 229 - While certain constraints like bandwidth can be used across 230 different domains, certain other TE constraints like resource 231 affinity, color, metric, etc. as listed in [RFC2702] may need to be 232 translated at domain boundaries. If required, it is assumed that, at 233 the domain boundary LSRs, there will exist some sort of local mapping 234 based on policy agreement in order to translate such constraints 235 across domain boundaries. It is expected that such an assumption 236 particularly applies to inter-AS TE: for example, the local mapping 237 would be similar to the Inter-AS TE Agreement Enforcement Polices 238 stated in [RFC4216]. 240 - The procedures defined in this document are applicable to any node 241 (not just boundary node) that receives a Path message with an ERO 242 that constains a loose hop or an abstract node that is not a simple 243 abstract node (that is, an abstract node that identifies more than 244 one LSR). 246 3.2. Example of topology for the inter-area TE case 248 The following example will be used for the inter-area TE case in this 249 document. 251 <-area 1-><-- area 0 --><--- area 2 ---> 252 ------ABR1------------ABR3------- 253 | / | | \ | 254 R0--X1 | | X2---X3--R1 255 | | | / | 256 ------ABR2-----------ABR4-------- 257 <=========== Inter-area TE LSP =======> 259 Figure 1 - Example of topology for the inter-area TE case 261 Description of Figure 1: 263 - ABR1, ABR2, ABR3 and ABR4 are ABRs, 264 - X1: an LSR in area 1, 265 - X2, X3: LSRs in area 2, 266 - An inter-area TE LSP T0 originated at R0 in area 1 and terminating 267 at R1 in area 2. 269 Notes: 271 - The terminology used in the example above corresponds to OSPF but 272 the path computation technique proposed in this document equally 273 applies to the case of an IS-IS multi-level network. 275 - Just a few routers in each area are depicted in the diagram above 276 for the sake of simplicity. 278 - The example depicted in Figure 1 shows the case where the Head-end 279 and Tail-end areas are connected by means of area 0. The case of an 280 inter-area TE LSP between two IGP areas that does not transit through 281 area 0 is not precluded. 283 3.3. Example of topology for the inter-AS TE case 285 We consider the following general case, built on a superset of the 286 various scenarios defined in [RFC4216]: 288 <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> 290 <---BGP---> <---BGP--> 291 CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 292 |\ \ | / | / | / | | | 293 | \ ASBR2---/ ASBR5 | -- | | | 294 | \ | | |/ | | | 295 R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2 297 <======= Inter-AS TE LSP(LSR to LSR)===========> 298 or 300 <======== Inter-AS TE LSP (CE to ASBR => 302 or 304 <================= Inter-AS TE LSP (CE to CE)===============> 306 Figure 2 - Example of topology for the inter-AS TE case 308 The diagram depicted in Figure 2 covers all the inter-AS TE 309 deployment cases described in [RFC4216]. 311 Description of Figure 2: 313 - Three interconnected ASs, respectively AS1, AS2, and AS3. Note 314 that in some scenarios described in [RFC4216] AS1=AS3. 316 - The ASBRs in different ASs are BGP peers. There is usually no IGP 317 running on the single hop links interconnecting the ASBRs and also 318 referred to as inter-ASBR links. 320 - Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE 321 extensions (see [RFC3630], [RFC3784], [RFC4203] and [RFC4205]). In 322 other words, the ASs are TE enabled, 324 - Each AS can be made of several IGP areas. The path computation 325 technique described in this document applies to the case of a single 326 AS made of multiple IGP areas, multiples ASs made of a single IGP 327 areas or any combination of the above. For the sake of simplicity, 328 each routing domain will be considered as single area in this 329 document. The case of an Inter-AS TE LSP spanning multiple ASs where 330 some of those ASs are themselves made of multiple IGP areas can be 331 easily derived from the examples above: the per-domain path 332 computation technique described in this document is applied 333 recursively in this case. 335 - An inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6 336 in AS3. 338 4. Per-domain path computation procedures 340 The mechanisms for inter-domain TE LSP computation as described in 341 this document can be used regardless of the nature of the inter- 342 domain TE LSP (contiguous, stitched or nested). 344 Note that any path can be defined as a set of loose and strict hops. 345 In other words, in some cases, it might be desirable to rely on the 346 dynamic path computation in some area, and exert a strict control on 347 the path in other areas (defining strict hops). 349 When an LSR (e.g. a boundary node such as an ABR/ASBR) receives a 350 Path message with an ERO that contains a loose hop or an abstract 351 node that is not a simple abstract node (that is, an abstract node 352 that identifies more than one LSR), then it MUST follow the 353 procedures as described in [I-D.ietf-ccamp-inter-domain-rsvp-te]. In 354 addition, the following procedures describe the path computation 355 procedures that SHOULD be carried out on the LSR: 357 1) If the next hop boundary LSR is not present in the TED. 359 If the loose next-hop is not present in the TED, the following 360 conditions MUST be checked: 362 - If the IP address of the next hop boundary LSR is outside of the 363 current domain, 365 - If the domain is PSC (Packet Switch Capable) and uses in-band 366 control channel 368 If the two conditions above are satisfied then the boundary LSR 369 SHOULD check if the next-hop has IP reachability (via IGP or BGP). 370 If the next-hop is not reachable, then a signaling failure occurs and 371 the LSR SHOULD send back a PErr message upstream with error code=24 372 ("Routing Problem") and error subcode as described in section 4.3.4 373 of [RFC3209]. If the next-hop is reachable, then it SHOULD find a 374 domain boundary LSR (domain boundary point) to get to the next-hop. 375 The determination of domain boundary point based on routing 376 information is what we term as "auto-discovery" in this document. In 377 the absence of such an auto-discovery mechanism, a) the ABR in the 378 case of inter-area TE or the ASBR in the next-hop AS in the case of 379 inter-AS TE should be the signaled loose next-hop in the ERO and 380 hence should be accessible via the TED or b) there needs to be an 381 alternate scheme that provides the domain exit points. Otherwise the 382 path computation for the inter-domain TE LSP will fail. 384 An implementation MAY support the ability to disable such IP 385 reachability fall-back option should the next hop boundary LSR not be 386 present in the TED. In other words, an implementation MAY support 387 the possibility to trigger a signaling failure whenever the next-hop 388 is not present in the TED. 390 2) Once the next-hop boundary LSR has been determined (according to 391 the procedure described in 1)) or if the next-hop boundary is present 392 in the TED 394 a) Case of a contiguous TE LSP. The boundary LSR that processes the 395 ERO SHOULD perform an ERO expansion (unless not allowed by policy) 396 after having computed the path to the next loose hop (ABR/ASBR) that 397 obeys the set of required constraints. If no path satisfying the set 398 of constraints can be found, then this SHOULD be treated as a path 399 computation and signaling failure and a PErr message SHOULD be sent 400 for the inter-domain TE LSP based on section 4.3.4 of [RFC3209]. 402 b) Case of stitched or nested LSP 404 i) If the boundary LSR is a candidate LSR for intra-area H-LSP/S-LSP 405 setup (the LSR has local policy for nesting or stitching), and if 406 there is no H-LSP/S-LSP from this LSR to the next-hop boundary LSR 407 that satisfies the constraints, it SHOULD signal a H-LSP/S-LSP to the 408 next-hop boundary LSR. If pre-configured H-LSP(s) or S-LSP(s) 409 already exist, then it will try to select from among those intra- 410 domain LSPs. Depending on local policy, it MAY signal a new H-LSP/ 411 S-LSP if this selection fails. If the H-LSP/S-LSP is successfully 412 signaled or selected, it propagates the inter-domain Path message to 413 the next-hop following the procedures described in [I-D.ietf-ccamp- 414 inter-domain-rsvp-te]. If, for some reason the dynamic H-LSP/S-LSP 415 setup to the next-hop boundary LSR fails, then this SHOULD be treated 416 as a path computation and signaling failure and a PErr message SHOULD 417 be sent upstream for the inter-domain LSP. Similarly, if selection 418 of a preconfigured H-LSP/S-LSP fails and local policy prevents 419 dynamic H-LSP/S this SHOULD be treated as a path computation and 420 signaling failure and a PErr SHOULD be sent upstream for the inter- 421 domain TE LSP. In both these cases procedures described in section 422 4.3.4 of [RFC3209] SHOULD be followed to handle the failure. 424 ii) If, however, the boundary LSR is not a candidate for intra-domain 425 H-LSP/S-LSP (the LSR does not have local policy for nesting or 426 stitching), then it SHOULD apply the same procedure as for the 427 contiguous case. 429 Note that in both cases, path computation and signaling process may 430 be stopped due to policy violation. 432 The ERO of an inter-domain TE LSP may comprise abstract nodes such as 433 ASs. In such a case, upon receiving the ERO whose next hop is an AS, 434 the boundary LSR has to determine the next-hop boundary LSR which may 435 be determined based on the "auto-discovery" process mentioned above. 436 If multiple ASBRs candidates exist the boundary LSR may apply some 437 policies based on peering contracts that may have been pre- 438 negotiated. Once the next-hop boundary LSR has been determined a 439 similar procedure as the one described above is followed. 441 Note related to the inter-AS TE case 443 The links interconnecting ASBRs are usually not TE-enabled and no IGP 444 is running at the AS boundaries. An implementation supporting 445 inter-AS MPLS TE MUST allow the set up of inter-AS TE LSP over the 446 region interconnecting multiple ASBRs. In other words, an ASBR 447 compliant with this document MUST support the set up of TE LSP over 448 inter-ASBR links and MUST be able to perform all the usual operations 449 related to MPLS Traffic Engineering (call admission control, ...). 451 In terms of computation of an inter-AS TE LSP path, an interesting 452 optimization technique consists of allowing the ASBRs to flood the TE 453 information related to the inter-ASBR link(s) although no IGP TE is 454 enabled over those links (and so there is no IGP adjacency over the 455 inter-ASBR links). This of course implies for the inter-ASBR links 456 to be TE-enabled although no IGP is running on those links. This 457 allows an LSR (could be entry ASBR) in the previous AS to make a more 458 appropriate route selection up to the entry ASBR in the immediately 459 downstream AS taking into account the constraints associated with the 460 inter-ASBR links. This reduces the risk of call set up failure due 461 to inter-ASBR links not satisfying the inter-AS TE LSP set of 462 constraints. Note that the TE information is only related to the 463 inter-ASBR links: the TE LSA/LSP flooded by the ASBR includes not 464 only the TE-enabled links contained in the AS but also the inter-ASBR 465 links. 467 Note that no summarized TE information is leaked between ASs which is 468 compliant with the requirements listed in [RFC4105] and [RFC4216]. 470 For example, consider the diagram depicted in Figure 2: when ASBR1 471 floods its IGP TE LSA ((opaque LSA for OSPF)/LSP (TLV 22 for IS-IS)) 472 in its routing domain, it reflects the reservation states and TE 473 properties of the following links: X1-ASBR1, ASBR1-ASBR2 and ASBR1- 474 ASBR4. 476 Thanks to such an optimization, the inter-ASBRs TE link information 477 corresponding to the links originated by the ASBR is made available 478 in the TED of other LSRs in the same domain that the ASBR belongs to. 479 Consequently, the path computation for an inter-AS TE LSP path can 480 also take into account the inter-ASBR link(s). This will improve the 481 chance of successful signaling along the next AS in case of resource 482 shortage or unsatisfied constraints on inter-ASBR links and it 483 potentially reduces one level of crankback. Note that no topology 484 information is flooded and these links are not used in IGP SPF 485 computations. Only the TE information for the outgoing links 486 directly connected to the ASBR is advertised. 488 Note that an Operator may decide to operate a stitched segment or 489 1-hop hierarchical LSP for the inter-ASBR link. 491 4.1. Example with an inter-area TE LSP 493 4.1.1. Case 1: T0 is a contiguous TE LSP 495 The Head-end LSR (R0) first determines the next hop ABR (which could 496 be manually configured by the user or dynamically determined by using 497 auto-discovery mechanism). R0 then computes the path to reach the 498 selected next hop ABR (ABR1) and signals the Path message. When the 499 Path message reaches ABR1, it first determines the next hop ABR from 500 its area 0 along the LSP path (say ABR3), either directly from the 501 ERO (if for example the next hop ABR is specified as a loose hop in 502 the ERO) or by using the auto-discovery mechanism specified above. 504 - Example 1 (set of loose hops): R0-ABR1(loose)-ABR3(loose)-R1(loose) 506 - Example 2 (mix of strict and loose hops): R0-X1-ABR1-ABR3(loose)- 507 X2-X3-R1 509 Note that a set of paths can be configured on the Head-end LSR, 510 ordered by priority. Each priority path can be associated with a 511 different set of constraints. It may be desirable to systematically 512 have a last resort option with no constraint to ensure that the 513 inter-area TE LSP could always be set up if at least a TE path exists 514 between the inter-area TE LSP source and destination. In case of set 515 up failure or when an RSVP PErr is received indicating the TE LSP has 516 suffered a failure, an implementation might support the possibility 517 to retry a particular path option configurable amount of times 518 (optionally with dynamic intervals between each trial) before trying 519 a lower priority path option. 521 Once it has computed the path up to the next hop ABR (ABR3), ABR1 522 sends the Path message along the computed path. Upon receiving the 523 Path message, ABR3 then repeats a similar procedure. If ABR3 cannot 524 find a path obeying the set of constraints for the inter-area TE LSP, 525 the signaling process stops and ABR3 sends a PErr message to ABR1. 526 Then ABR1 can in turn trigger a new path computation by selecting 527 another egress boundary LSR (ABR4 in the example above) if crankback 528 is allowed for this inter-area TE LSP (see [I-D.ietf-ccamp- 529 crankback]). If crankback is not allowed for that inter-area TE LSP 530 or if ABR1 has been configured not to perform crankback, then ABR1 531 MUST stop the signaling process and MUST forward a PErr up to the 532 Head-end LSR (R0) without trying to select another ABR. 534 4.1.2. Case 2: T0 is a stitched or nested TE LSP 536 The Head-end LSR (R0) first determines the next hop ABR (which could 537 be manually configured by the user or dynamically determined by using 538 auto-discovery mechanism). R0 then computes the path to reach the 539 selected next hop ABR and signals the Path message. When the Path 540 message reaches ABR1, it first determines the next hop ABR from its 541 area 0 along the LSP path (say ABR3), either directly from the ERO 542 (if for example the next hop ABR is specified as a loose hop in the 543 ERO) or by using an auto-discovery mechanism, specified above. 545 ABR1 then checks if it has a H-LSP or S-LSP to ABR3 matching the 546 constraints carried in the inter-area TE LSP Path message. If not, 547 ABR1 computes the path for a H-LSP or S-LSP from ABR1 to ABR3 548 satisfying the constraint and sets it up accordingly. Note that the 549 H-LSP or S-LSP could have also been pre-configured. 551 Once ABR1 has selected the H-LSP/S-LSP for the inter-area LSP, using 552 the signaling procedures described in [I-D.ietf-ccamp-inter-domain- 553 rsvp-te], ABR1 sends the Path message for inter-area TE LSP to ABR3. 554 Note that irrespective of whether ABR1 does nesting or stitching, the 555 Path message for the inter-area TE LSP is always forwarded to ABR3. 556 ABR3 then repeats the exact same procedures. If ABR3 cannot find a 557 path obeying the set of constraints for the inter-area TE LSP, ABR3 558 sends a PErr message to ABR1. Then ABR1 can in turn either select 559 another H-LSP/S-LSP to ABR3 if such an LSP exists or select another 560 egress boundary LSR (ABR4 in the example above) if crankback is 561 allowed for this inter-area TE LSP (see [I-D.ietf-ccamp-crankback]). 562 If crankback is not allowed for that inter-area TE LSP or if ABR1 has 563 been configured not to perform crankback, then ABR1 forwards the PErr 564 up to the inter-area Head-end LSR (R0) without trying to select 565 another egress LSR. 567 4.2. Example with an inter-AS TE LSP 569 The path computation procedures for establishing an inter-AS TE LSP 570 are very similar to those of an inter-area TE LSP described above. 571 The main difference is related to the presence of inter-ASBRs 572 link(s). 574 4.2.1. Case 1: T1 is a contiguous TE LSP 576 The inter-AS TE path may be configured on the Head-end LSR as a set 577 of strict hops, loose hops or a combination of both. 579 - Example 1 (set of loose hops): ASBR4(loose)-ASBR9(loose)-R6(loose) 581 - Example 2 (mix of strict and loose hops): R2-ASBR3-ASBR2-ASBR1- 582 ASBR4-ASBR10(loose)-ASBR9-R6 584 In the example 1 above, a per-AS path computation is performed, 585 respectively on R0 for AS1, ASBR4 for AS2 and ASBR9 for AS3. Note 586 that when an LSR has to perform an ERO expansion, the next hop must 587 either belong to the same AS, or must be the ASBR directly connected 588 to the next hops AS. In this later case, the ASBR reachability is 589 announced in the IGP TE LSA/LSP originated by its neighboring ASBR. 590 In the example 1 above, the TE LSP path is defined as: ASBR4(loose)- 591 ASBR9(loose)-R6(loose). This implies that R0 must compute the path 592 from R0 to ASBR4, hence the need for R0 to get the TE reservation 593 state related to the ASBR1-ASBR4 link (flooded in AS1 by ASBR1). In 594 addition, ASBR1 must also announce the IP address of ASBR4 specified 595 in the T1's path configuration. 597 Once it has computed the path up to the next hop ASBR, ASBR1 sends 598 the Path message for the inter-area TE LSP to ASBR4 (supposing that 599 ASBR4 is the selected next hop ASBR). ASBR4 then repeats the exact 600 same procedures. If ASBR4 cannot find a path obeying the set of 601 constraints for the inter-AS TE LSP, then ASBR4 sends a PErr message 602 to ASBR1. Then ASBR1 can in turn either select another ASBR (ASBR5 603 in the example above) if crankback is allowed for this inter-AS TE 604 LSP (see [I-D.ietf-ccamp-crankback]). If crankback is not allowed 605 for that inter-AS TE LSP or if ASBR1 has been configured not to 606 perform crankback, ABR1 stops the signaling process and forwards a 607 PErr up to the Head-end LSR (R0) without trying to select another 608 egress LSR. In this case, the Head-end LSR can in turn select 609 another sequence of loose hops, if configured. Alternatively, the 610 Head-end LSR may decide to retry the same path; this can be useful in 611 case of set up failure due an outdated IGP TE database in some 612 downstream AS. An alternative could also be for the Head-end LSR to 613 retry to same sequence of loose hops after having relaxed some 614 constraint(s). 616 4.2.2. Case 2: T1 is a stitched or nested TE LSP 618 The path computation procedures are very similar to the inter-area 619 LSP setup case described earlier. In this case, the H-LSPs or S-LSPs 620 are originated by the ASBRs at the entry to the AS. 622 5. Path optimality/diversity 624 Since the inter-domain TE LSP is computed on a per domain (area, AS) 625 basis, one cannot guarantee that the optimal inter-domain path can be 626 found. 628 Moreover, computing two diverse paths using a per-domain path 629 computation approach may not be possible in some topologies (due to 630 the well-known 'trapping' problem). 632 As already pointed out, the required path computation method can be 633 selected by the Service Provider on a per LSP basis. 635 If the per-domain path computation technique does no meet the set of 636 requirements for a particular TE LSP (e.g. path optimality, 637 requirements for a set of diversely routed TE LSPs, ...) other 638 techniques such as PCE-based path computation techniques may be used 639 (see [I-D.ietf-pce-architecture]). 641 6. Reoptimization of an inter-domain TE LSP 643 The ability to reoptimize an already established inter-domain TE LSP 644 constitutes a requirement. The reoptimization process significantly 645 differs based upon the nature of the TE LSP and the mechanism in use 646 for the TE LSP computation. 648 The following mechanisms can be used for reoptimization and are 649 dependent on the nature of the inter-domain TE LSP. 651 6.1. Contiguous TE LSPs 653 After an inter-domain TE LSP has been set up, a more optimal route 654 might appear within any traversed domain. Then in this case, it is 655 desirable to get the ability to reroute an inter-domain TE LSP in a 656 non-disruptive fashion (making use of the so-called Make-Before-Break 657 procedure) to follow such more optimal path. This is a known as a TE 658 LSP reoptimization procedure. 660 [I-D.ietf-ccamp-loose-path-reopt] proposes a mechanism that allows 661 the Head-end LSR to be notified of the existence of a more optimal 662 path in a downstream domain. The Head-end LSR may then decide to 663 gracefully reroute the TE LSP using the so-called Make-Before-Break 664 procedure. In case of a contiguous LSP, the reoptimization process 665 is strictly controlled by the Head-end LSR which triggers the make- 666 before-break procedure, regardless of the location of the more 667 optimal path. 669 6.2. Stitched or nested (non-contiguous) TE LSPs 671 In the case of a stitched or nested inter-domain TE LSP, the 672 reoptimization process is treated as a local matter to any domain. 673 The main reason is that the inter-domain TE LSP is a different LSP 674 (and therefore different RSVP session) from the intra-domain S-LSP or 675 H-LSP in an area or an AS. Therefore, reoptimization in a domain is 676 done by locally reoptimizing the intra-domain H-LSP or S-LSP. Since 677 the inter-domain TE LSPs are transported using S-LSP or H-LSP across 678 each domain, optimality of the inter-domain TE LSP in a domain is 679 dependent on the optimality of the corresponding S-LSP or H-LSPs. 680 If, after an inter-domain LSP is setup, a more optimal path is 681 available within an domain, the corresponding S-LSP or H-LSP will be 682 reoptimized using "Make-Before-Break" techniques discussed in 683 [RFC3209]. Reoptimization of the H-LSP or S-LSP automatically 684 reoptimizes the inter-domain TE LSPs that the H-LSP or the S-LSP 685 transports. Reoptimization parameters like frequency of 686 reoptimization, criteria for reoptimization like metric or bandwidth 687 availability, etc can vary from one domain to another and can be 688 configured as required, per intra-domain TE S-LSP or H-LSP if it is 689 preconfigured or based on some global policy within the domain. 691 Hence, in this scheme, since each domain takes care of reoptimizing 692 its own S-LSPs or H-LSPs, and therefore the corresponding inter- 693 domain TE LSPs, the Make-Before-Break can happen locally and is not 694 triggered by the Head-end LSR for the inter-domain LSP. So, no 695 additional RSVP signaling is required for LSP reoptimization and 696 reoptimization is transparent to the Head-end LSR of the inter-domain 697 TE LSP. 699 If, however, an operator desires to manually trigger reoptimization 700 at the Head-end LSR for the inter-domain TE LSP, then this solution 701 does not prevent that. A manual trigger for reoptimization at the 702 Head-end LSR SHOULD force a reoptimization thereby signaling a "new" 703 path for the same LSP (along the more optimal path) making use of the 704 Make-Before-Break procedure. In response to this new setup request, 705 the boundary LSR may either initiate new S-LSP setup, in case the 706 inter-domain TE LSP is being stitched to the intra-domain S-LSP or it 707 may select an existing or new H-LSP in case of nesting. When the LSP 708 setup along the current path is complete, the Head-end LSR should 709 switchover the traffic onto that path and the old path is eventually 710 torn down. Note that the Head-end LSR does not know a priori whether 711 a more optimal path exists. Such a manual trigger from the Head-end 712 LSR of the inter-domain TE LSP is, however, not considered to be a 713 frequent occurrence. 715 Note that stitching or nesting rely on local optimization: the 716 reoptimization process allows to locally reoptimize each TE S-LSP or 717 H-LSP: hence, the reoptimization is not global and consequently the 718 end-to-end path may no longer be optimal should it be optimal when 719 being set up. 721 Procedures described in [I-D.ietf-ccamp-loose-path-reopt] MUST be 722 used if the operator does not desire local reoptimization of certain 723 inter-domain LSPs. In this case, any reoptimization event within the 724 domain MUST be reported to the Head-end node. This SHOULD be a 725 configurable policy. 727 6.3. Path characteristics after reoptimization 729 Note that in the case of loose hop reoptimization of contiguous 730 inter-domain TE LSP or local reoptimization of stitched/nested S-LSP 731 where boundary LSRs are specified as loose hops, the TE LSP may 732 follow a preferable path within one or more domain(s) but would still 733 traverse the same set of boundary LSRs. In contrast, in the case of 734 PCE-based path computation techniques, because end to end optimal 735 path is computed, the reoptimization process may lead to following a 736 completely different inter-domain path (including a different set of 737 boundary LSRs). 739 7. IANA Considerations 741 This document makes no request for any IANA action. 743 8. Security Considerations 745 Signaling of inter-domain TE LSPs raises security issues that have 746 been described in section 7 of [I-D.ietf-ccamp-inter-domain-rsvp-te]; 747 however the path computation aspects specified in this document do 748 not raise additional security concerns. 750 9. Acknowledgements 752 We would like to acknowledge input and helpful comments from Adrian 753 Farrel, Jean-Louis Le Roux, Dimitri Papadimitriou and Faisal Aslam. 755 10. References 757 10.1. Normative References 759 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 760 Requirement Levels", BCP 14, RFC 2119, March 1997. 762 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 763 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 764 Functional Specification", RFC 2205, September 1997. 766 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 767 McManus, "Requirements for Traffic Engineering Over MPLS", 768 RFC 2702, September 1999. 770 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 771 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 772 Tunnels", RFC 3209, December 2001. 774 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 775 (TE) Extensions to OSPF Version 2", RFC 3630, 776 September 2003. 778 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 779 System (IS-IS) Extensions for Traffic Engineering (TE)", 780 RFC 3784, June 2004. 782 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 783 of Generalized Multi-Protocol Label Switching (GMPLS)", 784 RFC 4203, October 2005. 786 [RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to 787 Intermediate System (IS-IS) Extensions in Support of 788 Generalized Multi-Protocol Label Switching (GMPLS)", 789 RFC 4205, October 2005. 791 10.2. Informative References 793 [I-D.ietf-ccamp-crankback] 794 Farrel, A., "Crankback Signaling Extensions for MPLS and 795 GMPLS RSVP-TE", draft-ietf-ccamp-crankback-05 (work in 796 progress), May 2005. 798 [I-D.ietf-ccamp-inter-domain-framework] 799 Farrel, A., "A Framework for Inter-Domain MPLS Traffic 800 Engineering", draft-ietf-ccamp-inter-domain-framework-04 801 (work in progress), July 2005. 803 [I-D.ietf-ccamp-inter-domain-pd-path-comp] 804 Vasseur, J., "A Per-domain path computation method for 805 establishing Inter-domain Traffic Engineering (TE) Label 806 Switched Paths (LSPs)", 807 draft-ietf-ccamp-inter-domain-pd-path-comp-01 (work in 808 progress), October 2005. 810 [I-D.ietf-ccamp-inter-domain-rsvp-te] 811 Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic 812 Engineering - RSVP-TE extensions", 813 draft-ietf-ccamp-inter-domain-rsvp-te-02 (work in 814 progress), October 2005. 816 [I-D.ietf-ccamp-loose-path-reopt] 817 Vasseur, J., "Reoptimization of Multiprotocol Label 818 Switching (MPLS) Traffic Engineering (TE) loosely routed 819 Label Switch Path (LSP)", 820 draft-ietf-ccamp-loose-path-reopt-02 (work in progress), 821 February 2006. 823 [I-D.ietf-ccamp-lsp-stitching] 824 Ayyangar, A. and J. Vasseur, "Label Switched Path 825 Stitching with Generalized MPLS Traffic Engineering", 826 draft-ietf-ccamp-lsp-stitching-02 (work in progress), 827 September 2005. 829 [I-D.ietf-pce-architecture] 830 Farrel, A., "A Path Computation Element (PCE) Based 831 Architecture", draft-ietf-pce-architecture-04 (work in 832 progress), January 2006. 834 [RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for 835 Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. 837 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 838 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 839 November 2005. 841 Authors' Addresses 843 JP Vasseur (editor) 844 Cisco Systems, Inc 845 1414 Massachusetts Avenue 846 Boxborough, MA 01719 847 USA 849 Email: jpv@cisco.com 851 Arthi Ayyangar (editor) 852 Juniper Networks 853 1194 N.Mathilda Avenue 854 Sunnyvale, CA 94089 855 USA 857 Email: arthi@juniper.net 859 Raymond Zhang 860 BT Infonet 861 2160 E. Grand Ave. 862 El Segundo, CA 90025 863 USA 865 Email: raymond_zhang@bt.infonet.com 867 Intellectual Property Statement 869 The IETF takes no position regarding the validity or scope of any 870 Intellectual Property Rights or other rights that might be claimed to 871 pertain to the implementation or use of the technology described in 872 this document or the extent to which any license under such rights 873 might or might not be available; nor does it represent that it has 874 made any independent effort to identify any such rights. Information 875 on the procedures with respect to rights in RFC documents can be 876 found in BCP 78 and BCP 79. 878 Copies of IPR disclosures made to the IETF Secretariat and any 879 assurances of licenses to be made available, or the result of an 880 attempt made to obtain a general license or permission for the use of 881 such proprietary rights by implementers or users of this 882 specification can be obtained from the IETF on-line IPR repository at 883 http://www.ietf.org/ipr. 885 The IETF invites any interested party to bring to its attention any 886 copyrights, patents or patent applications, or other proprietary 887 rights that may cover technology that may be required to implement 888 this standard. Please address the information to the IETF at 889 ietf-ipr@ietf.org. 891 Disclaimer of Validity 893 This document and the information contained herein are provided on an 894 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 895 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 896 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 897 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 898 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 899 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 901 Copyright Statement 903 Copyright (C) The Internet Society (2006). This document is subject 904 to the rights, licenses and restrictions contained in BCP 78, and 905 except as set forth therein, the authors retain all their rights. 907 Acknowledgment 909 Funding for the RFC Editor function is currently provided by the 910 Internet Society.