idnits 2.17.1 draft-ietf-ccamp-inter-domain-pd-path-comp-04.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 915. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 926. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 933. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 939. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 6, 2007) is 6282 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 795, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) ** Obsolete normative reference: RFC 4205 (Obsoleted by RFC 5307) == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-inter-domain-rsvp-te-04 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-lsp-stitching-04 Summary: 3 errors (**), 0 flaws (~~), 4 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 Intended status: Standards Track A. Ayyangar, Ed. 4 Expires: August 10, 2007 Nuova Systems 5 R. Zhang 6 BT Infonet 7 February 6, 2007 9 A Per-domain path computation method for establishing Inter-domain 10 Traffic Engineering (TE) Label Switched Paths (LSPs) 11 draft-ietf-ccamp-inter-domain-pd-path-comp-04 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 10, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document specifies a per-domain path computation technique for 45 establishing inter-domain Traffic Engineering (TE) Multiprotocol 46 Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched 47 Paths (LSPs). In this document a domain refers to a collection of 48 network elements within a common sphere of address management or path 49 computational responsibility such as IGP areas and Autonomous 50 Systems. Per-domain computation applies where the full path of an 51 inter-domain TE LSP cannot be or is not determined at the ingress 52 node of the TE LSP, and is not signaled across domain boundaries. 53 This is most likely to arise owing to TE visibility limitations. The 54 signaling message indicates the destination and nodes up to the next 55 domain boundary. It may also indicate further domain boundaries or 56 domain identifiers. The path through each domain, possibly including 57 the choice of exit point from the domain, must be determined within 58 the domain. 60 Requirements Language 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119 [RFC2119]. 66 Table of Contents 68 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. General assumptions . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Common assumptions . . . . . . . . . . . . . . . . . . . . 5 72 3.2. Example of topology for the inter-area TE case . . . . . . 7 73 3.3. Example of topology for the inter-AS TE case . . . . . . . 8 74 4. Per-domain path computation procedures . . . . . . . . . . . . 9 75 4.1. Example with an inter-area TE LSP . . . . . . . . . . . . 12 76 4.1.1. Case 1: T0 is a contiguous TE LSP . . . . . . . . . . 12 77 4.1.2. Case 2: T0 is a stitched or nested TE LSP . . . . . . 13 78 4.2. Example with an inter-AS TE LSP . . . . . . . . . . . . . 14 79 4.2.1. Case 1: T1 is a contiguous TE LSP . . . . . . . . . . 14 80 4.2.2. Case 2: T1 is a stitched or nested TE LSP . . . . . . 15 81 5. Path optimality/diversity . . . . . . . . . . . . . . . . . . 15 82 6. Reoptimization of an inter-domain TE LSP . . . . . . . . . . . 15 83 6.1. Contiguous TE LSPs . . . . . . . . . . . . . . . . . . . . 15 84 6.2. Stitched or nested (non-contiguous) TE LSPs . . . . . . . 16 85 6.3. Path characteristics after reoptimization . . . . . . . . 17 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 91 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 93 Intellectual Property and Copyright Statements . . . . . . . . . . 21 95 1. Terminology 97 Terminology used in this document 99 AS: Autonomous System. 101 ABR: routers used to connect two IGP areas (areas in OSPF or levels 102 in IS-IS). 104 ASBR: routers used to connect together ASes of a different or the 105 same Service Provider via one or more Inter-AS links. 107 Boundary LSR: a boundary LSR is either an ABR in the context of 108 inter-area TE or an ASBR in the context of inter-AS TE. 110 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 112 Inter-area TE LSP: A TE LSP that crosses an IGP area. 114 LSR: Label Switching Router. 116 LSP: Label Switched Path. 118 TE LSP: Traffic Engineering Label Switched Path. 120 PCE: Path Computation Element: an entity (component, application or 121 network node) that is capable of computing a network path or route 122 based on a network graph and applying computational constraints. 124 TED: Traffic Engineering Database. 126 The notion of contiguous, stitched and nested TE LSPs is defined in 127 [RFC4726] and will not be repeated 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 [RFC4726]. 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 [RFC4655]). Other offline mechanisms 170 for path computation are not precluded either. Note also that a 171 Service Provider may elect to use different inter-domain path 172 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] and 187 [RFC3473]). 189 - The path (ERO) for an inter-domain TE LSP may be signaled as a set 190 of (loose and/or strict) hops. 192 - The hops may identify: 194 * The complete strict path end-to-end across different domains 196 * The complete strict path in the source domain followed by boundary 197 LSRs (or domain identifiers, e.g. AS numbers) 199 * The complete list of boundary LSRs along the path 201 * The current boundary LSR and the LSP destination. 203 The set of (loose or strict) hops can either be statically configured 204 on the Head-end LSR or dynamically computed. A per-domain path 205 computation method is defined in this document with an optional Auto- 206 discovery mechanism based on IGP, BGP, policy routing information 207 yielding the next-hop boundary node (domain exit point, such as ABR/ 208 ASBR) along the path as the TE LSP is being signaled, along with 209 potential crankback mechanisms. Alternatively the domain exit points 210 may be statically configured on the Head-end LSR in which case next- 211 hop boundary node auto-discovery would not be required. 213 - Boundary LSRs are assumed to be capable of performing local path 214 computation for expansion of a loose next-hop in the signaled ERO if 215 the path is not signaled by the Head-end LSR as a set of strict hops 216 or if the strict hop is an abstract node (e.g. an AS). In any case, 217 no topology or resource information needs to be distributed between 218 domains (as mandated per [RFC4105] and [RFC4216]), which is critical 219 to preserve IGP/BGP scalability and confidentiality in the case of TE 220 LSPs spanning multiple routing domains. 222 - The paths for the intra-domain Hierarchical LSPs (H-LSP) or 223 Stitched LSPs (S-LSP) or for a contiguous TE LSP within the domain 224 may be pre-configured or computed dynamically based on the arriving 225 inter-domain LSP setup request (depending on the requirements of the 226 transit domain). Note that this capability is explicitly specified 227 as a requirement in [RFC4216]. When the paths for the H-LSPs/S-LSP 228 are pre-configured, the constraints as well as other parameters like 229 local protection scheme for the intra-domain H-LSP/S-LSP are also 230 pre-configured. 232 - While certain constraints like bandwidth can be used across 233 different domains, certain other TE constraints like resource 234 affinity, color, metric, etc. as listed in [RFC2702] may need to be 235 translated at domain boundaries. If required, it is assumed that, at 236 the domain boundary LSRs, there will exist some sort of local mapping 237 based on policy agreement in order to translate such constraints 238 across domain boundaries. It is expected that such an assumption 239 particularly applies to inter-AS TE: for example, the local mapping 240 would be similar to the Inter-AS TE Agreement Enforcement Polices 241 stated in [RFC4216]. 243 - The procedures defined in this document are applicable to any node 244 (not just boundary node) that receives a Path message with an ERO 245 that constains a loose hop or an abstract node that is not a simple 246 abstract node (that is, an abstract node that identifies more than 247 one LSR). 249 3.2. Example of topology for the inter-area TE case 251 The following example will be used for the inter-area TE case in this 252 document. 254 <-area 1-><-- area 0 --><--- area 2 ---> 255 ------ABR1------------ABR3------- 256 | / | | \ | 257 R0--X1 | | X2---X3--R1 258 | | | / | 259 ------ABR2-----------ABR4-------- 260 <=========== Inter-area TE LSP =======> 262 Figure 1 - Example of topology for the inter-area TE case 264 Description of Figure 1: 266 - ABR1, ABR2, ABR3 and ABR4 are ABRs, 267 - X1: an LSR in area 1, 268 - X2, X3: LSRs in area 2, 269 - An inter-area TE LSP T0 originated at R0 in area 1 and terminating 270 at R1 in area 2. 272 Notes: 274 - The terminology used in the example above corresponds to OSPF but 275 the path computation technique proposed in this document equally 276 applies to the case of an IS-IS multi-level network. 278 - Just a few routers in each area are depicted in the diagram above 279 for the sake of simplicity. 281 - The example depicted in Figure 1 shows the case where the Head-end 282 and Tail-end areas are connected by means of area 0. The case of an 283 inter-area TE LSP between two IGP areas that does not transit through 284 area 0 is not precluded. 286 3.3. Example of topology for the inter-AS TE case 288 We consider the following general case, built on a superset of the 289 various scenarios defined in [RFC4216]: 291 <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> 293 <---BGP---> <---BGP--> 294 CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 295 |\ \ | / | / | / | | | 296 | \ ASBR2---/ ASBR5 | -- | | | 297 | \ | | |/ | | | 298 R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2 300 <======= Inter-AS TE LSP(LSR to LSR)===========> 301 or 303 <======== Inter-AS TE LSP (CE to ASBR => 305 or 307 <================= Inter-AS TE LSP (CE to CE)===============> 309 Figure 2 - Example of topology for the inter-AS TE case 311 The diagram depicted in Figure 2 covers all the inter-AS TE 312 deployment cases described in [RFC4216]. 314 Description of Figure 2: 316 - Three interconnected ASs, respectively AS1, AS2, and AS3. Note 317 that in some scenarios described in [RFC4216] AS1=AS3. 319 - The ASBRs in different ASs are BGP peers. There is usually no IGP 320 running on the single hop links interconnecting the ASBRs and also 321 referred to as inter-ASBR links. 323 - Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE 324 extensions (see [RFC3630], [RFC3784], [RFC4203] and [RFC4205]). In 325 other words, the ASes are TE enabled, 327 - Each AS can be made of several IGP areas. The path computation 328 technique described in this document applies to the case of a single 329 AS made of multiple IGP areas, multiples ASs made of a single IGP 330 areas or any combination of the above. For the sake of simplicity, 331 each routing domain will be considered as single area in this 332 document. The case of an Inter-AS TE LSP spanning multiple ASs where 333 some of those ASs are themselves made of multiple IGP areas can be 334 easily derived from the examples above: the per-domain path 335 computation technique described in this document is applied 336 recursively in this case. 338 - An inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6 339 in AS3. 341 4. Per-domain path computation procedures 343 The mechanisms for inter-domain TE LSP computation as described in 344 this document can be used regardless of the nature of the inter- 345 domain TE LSP (contiguous, stitched or nested). 347 Note that any path can be defined as a set of loose and strict hops. 348 In other words, in some cases, it might be desirable to rely on the 349 dynamic path computation in some domain, and exert a strict control 350 on the path in other domains (defining strict hops). 352 When an LSR that is a boundary node such as an ABR/ASBR receives a 353 Path message with an ERO that contains a loose hop or an abstract 354 node that is not a simple abstract node (that is, an abstract node 355 that identifies more than one LSR), then it MUST follow the 356 procedures as described in [I-D.ietf-ccamp-inter-domain-rsvp-te]. In 357 addition, the following procedures describe the path computation 358 procedures that SHOULD be carried out on the LSR: 360 1) If the next hop is not present in the TED. 362 If the loose next-hop is not present in the TED, the following 363 conditions MUST be checked: 365 o If the IP address of the next hop boundary LSR is outside of the 366 current domain, 368 o If the domain is PSC (Packet Switch Capable) and uses in-band 369 control channel 371 If the two conditions above are satisfied then the boundary LSR 372 SHOULD check if the next-hop has IP reachability (via IGP or BGP). 373 If the next-hop is not reachable, then a signaling failure occurs and 374 the LSR SHOULD send back an RSVP PathErr message upstream with error 375 code=24 ("Routing Problem") and error subcode as described in section 376 4.3.4 of [RFC3209]. If the next-hop is reachable, then it SHOULD 377 find a domain boundary LSR (domain boundary point) to get to the 378 next-hop. The determination of domain boundary point based on 379 routing information is what we term as "auto-discovery" in this 380 document. In the absence of such an auto-discovery mechanism, a) the 381 ABR in the case of inter-area TE or the ASBR in the next-hop AS in 382 the case of inter-AS TE should be the signaled loose next-hop in the 383 ERO and hence should be accessible via the TED or b) there needs to 384 be an alternate scheme that provides the domain exit points. 385 Otherwise the path computation for the inter-domain TE LSP will fail. 387 An implementation MAY support the ability to disable such IP 388 reachability fall-back option should the next hop boundary LSR not be 389 present in the TED. In other words, an implementation MAY support 390 the possibility to trigger a signaling failure whenever the next-hop 391 is not present in the TED. 393 2) Once the next-hop boundary LSR has been determined (according to 394 the procedure described in 1)) or if the next-hop boundary is present 395 in the TED 397 o Case of a contiguous TE LSP. The boundary LSR that processes the 398 ERO SHOULD perform an ERO expansion (unless not allowed by policy) 399 after having computed the path to the next loose hop (ABR/ASBR) 400 that obeys the set of required constraints. If no path satisfying 401 the set of constraints can be found, then this SHOULD be treated 402 as a path computation and signaling failure and an RSVP PathErr 403 message SHOULD be sent for the inter-domain TE LSP based on 404 section 4.3.4 of [RFC3209]. 406 o Case of stitched or nested LSP 408 o 410 * If the boundary LSR is a candidate LSR for intra-area H-LSP/ 411 S-LSP setup (the LSR has local policy for nesting or 412 stitching), the TE LSP is a candidate for hierarchy/nesting 413 (the "Contiguous LSP" bit defined in 414 [I-D.ietf-ccamp-inter-domain-rsvp-te] is not set) and if there 415 is no H-LSP/S-LSP from this LSR to the next-hop boundary LSR 416 that satisfies the constraints, it SHOULD signal a H-LSP/S-LSP 417 to the next-hop boundary LSR. If pre-configured H-LSP(s) or 418 S-LSP(s) already exist, then it will try to select from among 419 those intra-domain LSPs. Depending on local policy, it MAY 420 signal a new H-LSP/S-LSP if this selection fails. If the 421 H-LSP/S-LSP is successfully signaled or selected, it propagates 422 the inter-domain Path message to the next-hop following the 423 procedures described in [I-D.ietf-ccamp-inter-domain-rsvp-te]. 424 If, for some reason the dynamic H-LSP/S-LSP setup to the next- 425 hop boundary LSR fails, then this SHOULD be treated as a path 426 computation and signaling failure and an RSVP PathErr message 427 SHOULD be sent upstream for the inter-domain LSP. Similarly, 428 if selection of a preconfigured H-LSP/S-LSP fails and local 429 policy prevents dynamic H-LSP/S this SHOULD be treated as a 430 path computation and signaling failure and an RSVP PathErr 431 SHOULD be sent upstream for the inter-domain TE LSP. In both 432 these cases procedures described in section 4.3.4 of [RFC3209] 433 SHOULD be followed to handle the failure. 435 * If, however, the boundary LSR is not a candidate for intra- 436 domain H-LSP/S-LSP (the LSR does not have local policy for 437 nesting or stitching) or the TE LSP is a not candidate for 438 hierarchy/nesting (the "Contiguous LSP" bit defined in 439 [I-D.ietf-ccamp-inter-domain-rsvp-te] is set), then it SHOULD 440 apply the same procedure as for the contiguous case. 442 Note that in both cases, path computation and signaling process may 443 be stopped due to policy violation. 445 The ERO of an inter-domain TE LSP may comprise abstract nodes such as 446 ASes. In such a case, upon receiving the ERO whose next hop is an 447 AS, the boundary LSR has to determine the next-hop boundary LSR which 448 may be determined based on the "auto-discovery" process mentioned 449 above. If multiple ASBRs candidates exist the boundary LSR may apply 450 some policies based on peering contracts that may have been pre- 451 negotiated. Once the next-hop boundary LSR has been determined a 452 similar procedure as the one described above is followed. 454 Note related to the inter-AS TE case 456 In terms of computation of an inter-AS TE LSP path, an interesting 457 optimization technique consists of allowing the ASBRs to flood the TE 458 information related to the inter-ASBR link(s) although no IGP TE is 459 enabled over those links (and so there is no IGP adjacency over the 460 inter-ASBR links). This of course implies for the inter-ASBR links 461 to be TE-enabled although no IGP is running on those links. This 462 allows an LSR (could be entry ASBR) in the previous AS to make a more 463 appropriate route selection up to the entry ASBR in the immediately 464 downstream AS taking into account the constraints associated with the 465 inter-ASBR links. This reduces the risk of call set up failure due 466 to inter-ASBR links not satisfying the inter-AS TE LSP set of 467 constraints. Note that the TE information is only related to the 468 inter-ASBR links: the TE LSA/LSP flooded by the ASBR includes not 469 only the TE-enabled links contained in the AS but also the inter-ASBR 470 links. 472 Note that no summarized TE information is leaked between ASes which 473 is compliant with the requirements listed in [RFC4105] and [RFC4216]. 475 For example, consider the diagram depicted in Figure 2: when ASBR1 476 floods its IGP TE LSA ((opaque LSA for OSPF)/LSP (TLV 22 for IS-IS)) 477 in its routing domain, it reflects the reservation states and TE 478 properties of the following links: X1-ASBR1, ASBR1-ASBR2 and ASBR1- 479 ASBR4. 481 Thanks to such an optimization, the inter-ASBRs TE link information 482 corresponding to the links originated by the ASBR is made available 483 in the TED of other LSRs in the same domain that the ASBR belongs to. 484 Consequently, the path computation for an inter-AS TE LSP path can 485 also take into account the inter-ASBR link(s). This will improve the 486 chance of successful signaling along the next AS in case of resource 487 shortage or unsatisfied constraints on inter-ASBR links and it 488 potentially reduces one level of crankback. Note that no topology 489 information is flooded and these links are not used in IGP SPF 490 computations. Only the TE information for the outgoing links 491 directly connected to the ASBR is advertised. 493 Note that an Operator may decide to operate a stitched segment or 494 1-hop hierarchical LSP for the inter-ASBR link. 496 4.1. Example with an inter-area TE LSP 498 4.1.1. Case 1: T0 is a contiguous TE LSP 500 The Head-end LSR (R0) first determines the next hop ABR (which could 501 be manually configured by the user or dynamically determined by using 502 auto-discovery mechanism). R0 then computes the path to reach the 503 selected next hop ABR (ABR1) and signals the Path message. When the 504 Path message reaches ABR1, it first determines the next hop ABR from 505 its area 0 along the LSP path (say ABR3), either directly from the 506 ERO (if for example the next hop ABR is specified as a loose hop in 507 the ERO) or by using the auto-discovery mechanism specified above. 509 - Example 1 (set of loose hops): R0-ABR1(loose)-ABR3(loose)-R1(loose) 511 - Example 2 (mix of strict and loose hops): R0-X1-ABR1-ABR3(loose)- 512 X2-X3-R1 514 Note that a set of paths can be configured on the Head-end LSR, 515 ordered by priority. Each priority path can be associated with a 516 different set of constraints. It may be desirable to systematically 517 have a last resort option with no constraint to ensure that the 518 inter-area TE LSP could always be set up if at least a TE path exists 519 between the inter-area TE LSP source and destination. In case of set 520 up failure or when an RSVP PathErr is received indicating the TE LSP 521 has suffered a failure, an implementation might support the 522 possibility to retry a particular path option configurable amount of 523 times (optionally with dynamic intervals between each trial) before 524 trying a lower priority path option. 526 Once it has computed the path up to the next hop ABR (ABR3), ABR1 527 sends the Path message along the computed path. Upon receiving the 528 Path message, ABR3 then repeats a similar procedure. If ABR3 cannot 529 find a path obeying the set of constraints for the inter-area TE LSP, 530 the signaling process stops and ABR3 sends a PathErr message to ABR1. 531 Then ABR1 can in turn trigger a new path computation by selecting 532 another egress boundary LSR (ABR4 in the example above) if crankback 533 is allowed for this inter-area TE LSP (see 534 [I-D.ietf-ccamp-crankback]). If crankback is not allowed for that 535 inter-area TE LSP or if ABR1 has been configured not to perform 536 crankback, then ABR1 MUST stop the signaling process and MUST forward 537 a PathErr up to the Head-end LSR (R0) without trying to select 538 another ABR. 540 4.1.2. Case 2: T0 is a stitched or nested TE LSP 542 The Head-end LSR (R0) first determines the next hop ABR (which could 543 be manually configured by the user or dynamically determined by using 544 auto-discovery mechanism). R0 then computes the path to reach the 545 selected next hop ABR and signals the Path message. When the Path 546 message reaches ABR1, it first determines the next hop ABR from its 547 area 0 along the LSP path (say ABR3), either directly from the ERO 548 (if for example the next hop ABR is specified as a loose hop in the 549 ERO) or by using an auto-discovery mechanism, specified above. 551 ABR1 then checks if it has a H-LSP or S-LSP to ABR3 matching the 552 constraints carried in the inter-area TE LSP Path message. If not, 553 ABR1 computes the path for a H-LSP or S-LSP from ABR1 to ABR3 554 satisfying the constraint and sets it up accordingly. Note that the 555 H-LSP or S-LSP could have also been pre-configured. 557 Once ABR1 has selected the H-LSP/S-LSP for the inter-area LSP, using 558 the signaling procedures described in 559 [I-D.ietf-ccamp-inter-domain-rsvp-te], ABR1 sends the Path message 560 for inter-area TE LSP to ABR3. Note that irrespective of whether 561 ABR1 does nesting or stitching, the Path message for the inter-area 562 TE LSP is always forwarded to ABR3. ABR3 then repeats the exact same 563 procedures. If ABR3 cannot find a path obeying the set of 564 constraints for the inter-area TE LSP, ABR3 sends a PathErr message 565 to ABR1. Then ABR1 can in turn either select another H-LSP/S-LSP to 566 ABR3 if such an LSP exists or select another egress boundary LSR 567 (ABR4 in the example above) if crankback is allowed for this inter- 568 area TE LSP (see [I-D.ietf-ccamp-crankback]). If crankback is not 569 allowed for that inter-area TE LSP or if ABR1 has been configured not 570 to perform crankback, then ABR1 forwards the PathErr up to the inter- 571 area Head-end LSR (R0) without trying to select another egress LSR. 573 4.2. Example with an inter-AS TE LSP 575 The path computation procedures for establishing an inter-AS TE LSP 576 are very similar to those of an inter-area TE LSP described above. 577 The main difference is related to the presence of inter-ASBRs 578 link(s). 580 4.2.1. Case 1: T1 is a contiguous TE LSP 582 The inter-AS TE path may be configured on the Head-end LSR as a set 583 of strict hops, loose hops or a combination of both. 585 - Example 1 (set of loose hops): ASBR4(loose)-ASBR9(loose)-R6(loose) 587 - Example 2 (mix of strict and loose hops): R2-ASBR3-ASBR2-ASBR1- 588 ASBR4-ASBR10(loose)-ASBR9-R6 590 In the example 1 above, a per-AS path computation is performed, 591 respectively on R0 for AS1, ASBR4 for AS2 and ASBR9 for AS3. Note 592 that when an LSR has to perform an ERO expansion, the next hop must 593 either belong to the same AS, or must be the ASBR directly connected 594 to the next hops AS. In this later case, the ASBR reachability is 595 announced in the IGP TE LSA/LSP originated by its neighboring ASBR. 596 In the example 1 above, the TE LSP path is defined as: ASBR4(loose)- 597 ASBR9(loose)-R6(loose). This implies that R0 must compute the path 598 from R0 to ASBR4, hence the need for R0 to get the TE reservation 599 state related to the ASBR1-ASBR4 link (flooded in AS1 by ASBR1). In 600 addition, ASBR1 must also announce the IP address of ASBR4 specified 601 in the T1's path configuration. 603 Once it has computed the path up to the next hop ASBR, ASBR1 sends 604 the Path message for the inter-area TE LSP to ASBR4 (supposing that 605 ASBR4 is the selected next hop ASBR). ASBR4 then repeats the exact 606 same procedures. If ASBR4 cannot find a path obeying the set of 607 constraints for the inter-AS TE LSP, then ASBR4 sends a PathErr 608 message to ASBR1. Then ASBR1 can in turn either select another ASBR 609 (ASBR5 in the example above) if crankback is allowed for this 610 inter-AS TE LSP (see [I-D.ietf-ccamp-crankback]). If crankback is 611 not allowed for that inter-AS TE LSP or if ASBR1 has been configured 612 not to perform crankback, ABR1 stops the signaling process and 613 forwards a PathErr up to the Head-end LSR (R0) without trying to 614 select another egress LSR. In this case, the Head-end LSR can in 615 turn select another sequence of loose hops, if configured. 616 Alternatively, the Head-end LSR may decide to retry the same path; 617 this can be useful in case of set up failure due an outdated IGP TE 618 database in some downstream AS. An alternative could also be for the 619 Head-end LSR to retry to same sequence of loose hops after having 620 relaxed some constraint(s). 622 4.2.2. Case 2: T1 is a stitched or nested TE LSP 624 The path computation procedures are very similar to the inter-area 625 LSP setup case described earlier. In this case, the H-LSPs or S-LSPs 626 are originated by the ASBRs at the entry to the AS. 628 5. Path optimality/diversity 630 Since the inter-domain TE LSP is computed on a per domain (area, AS) 631 basis, one cannot guarantee that the optimal inter-domain path can be 632 found. 634 Moreover, computing two diverse paths using a per-domain path 635 computation approach may not be possible in some topologies (due to 636 the well-known 'trapping' problem). 638 As already pointed out, the required path computation method can be 639 selected by the Service Provider on a per LSP basis. 641 If the per-domain path computation technique does not meet the set of 642 requirements for a particular TE LSP (e.g. path optimality, 643 requirements for a set of diversely routed TE LSPs, ...) other 644 techniques such as PCE-based path computation techniques may be used 645 (see [RFC4655]). 647 6. Reoptimization of an inter-domain TE LSP 649 As stated in [RFC4216]and in [RFC4105], the ability to reoptimize an 650 already established inter-domain TE LSP constitutes a requirement. 651 The reoptimization process significantly differs based upon the 652 nature of the TE LSP and the mechanism in use for the TE LSP 653 computation. 655 The following mechanisms can be used for reoptimization and are 656 dependent on the nature of the inter-domain TE LSP. 658 6.1. Contiguous TE LSPs 660 After an inter-domain TE LSP has been set up, a more optimal route 661 might appear within any traversed domain. Then in this case, it is 662 desirable to get the ability to reroute an inter-domain TE LSP in a 663 non-disruptive fashion (making use of the so-called Make-Before-Break 664 procedure) to follow such more optimal path. This is a known as a TE 665 LSP reoptimization procedure. 667 [I-D.ietf-ccamp-loose-path-reopt] proposes a mechanism that allows 668 the Head-end LSR to be notified of the existence of a more optimal 669 path in a downstream domain. The Head-end LSR may then decide to 670 gracefully reroute the TE LSP using the so-called Make-Before-Break 671 procedure. In case of a contiguous LSP, the reoptimization process 672 is strictly controlled by the Head-end LSR which triggers the make- 673 before-break procedure, regardless of the location of the more 674 optimal path. 676 6.2. Stitched or nested (non-contiguous) TE LSPs 678 In the case of a stitched or nested inter-domain TE LSP, the 679 reoptimization process is treated as a local matter to any domain. 680 The main reason is that the inter-domain TE LSP is a different LSP 681 (and therefore different RSVP session) from the intra-domain S-LSP or 682 H-LSP in an area or an AS. Therefore, reoptimization in a domain is 683 done by locally reoptimizing the intra-domain H-LSP or S-LSP. Since 684 the inter-domain TE LSPs are transported using S-LSP or H-LSP across 685 each domain, optimality of the inter-domain TE LSP in a domain is 686 dependent on the optimality of the corresponding S-LSP or H-LSPs. 687 If, after an inter-domain LSP is setup, a more optimal path is 688 available within an domain, the corresponding S-LSP or H-LSP will be 689 reoptimized using "Make-Before-Break" techniques discussed in 690 [RFC3209]. Reoptimization of the H-LSP or S-LSP automatically 691 reoptimizes the inter-domain TE LSPs that the H-LSP or the S-LSP 692 transports. Reoptimization parameters like frequency of 693 reoptimization, criteria for reoptimization like metric or bandwidth 694 availability, etc can vary from one domain to another and can be 695 configured as required, per intra-domain TE S-LSP or H-LSP if it is 696 preconfigured or based on some global policy within the domain. 698 Hence, in this scheme, since each domain takes care of reoptimizing 699 its own S-LSPs or H-LSPs, and therefore the corresponding inter- 700 domain TE LSPs, the Make-Before-Break can happen locally and is not 701 triggered by the Head-end LSR for the inter-domain LSP. So, no 702 additional RSVP signaling is required for LSP reoptimization and 703 reoptimization is transparent to the Head-end LSR of the inter-domain 704 TE LSP. 706 If, however, an operator desires to manually trigger reoptimization 707 at the Head-end LSR for the inter-domain TE LSP, then this solution 708 does not prevent that. A manual trigger for reoptimization at the 709 Head-end LSR SHOULD force a reoptimization thereby signaling a "new" 710 path for the same LSP (along the more optimal path) making use of the 711 Make-Before-Break procedure. In response to this new setup request, 712 the boundary LSR may either initiate new S-LSP setup, in case the 713 inter-domain TE LSP is being stitched to the intra-domain S-LSP or it 714 may select an existing or new H-LSP in case of nesting. When the LSP 715 setup along the current path is complete, the Head-end LSR should 716 switchover the traffic onto that path and the old path is eventually 717 torn down. Note that the Head-end LSR does not know a priori whether 718 a more optimal path exists. Such a manual trigger from the Head-end 719 LSR of the inter-domain TE LSP is, however, not considered to be a 720 frequent occurrence. 722 Procedures described in [I-D.ietf-ccamp-loose-path-reopt] MUST be 723 used if the operator does not desire local reoptimization of certain 724 inter-domain LSPs. In this case, any reoptimization event within the 725 domain MUST be reported to the Head-end node. This SHOULD be a 726 configurable policy. 728 6.3. Path characteristics after reoptimization 730 Note that in the case of loose hop reoptimization of contiguous 731 inter-domain TE LSP or local reoptimization of stitched/nested S-LSP 732 where boundary LSRs are specified as loose hops, the TE LSP may 733 follow a preferable path within one or more domain(s) but would still 734 traverse the same set of boundary LSRs. In contrast, in the case of 735 PCE-based path computation techniques, because end to end optimal 736 path is computed, the reoptimization process may lead to following a 737 completely different inter-domain path (including a different set of 738 boundary LSRs). 740 7. IANA Considerations 742 This document makes no request for any IANA action. 744 8. Security Considerations 746 Signaling of inter-domain TE LSPs raises security issues (discussed 747 in section 7 of [I-D.ietf-ccamp-inter-domain-rsvp-te]). 749 [RFC4726] provides an overview of the requirements for security in an 750 MPLS-TE or GMPLS multi-domain environment. In particular, when 751 signaling an inter-domain RSVP-TE LSP, an operator may make use of 752 the security features already defined for RSVP-TE ([RFC3209]). This 753 may require some coordination between the domains to share the keys 754 (see [RFC2747] and [RFC3097]), and care is required to ensure that 755 the keys are changed sufficiently frequently. Note that this may 756 involve additional synchronization, should the domain border nodes be 757 protected with FRR, since the MP and PLR should also share the key. 758 For an inter-domain TE LSP, especially when it traverses different 759 administrative or trust domains, the following mechanisms SHOULD be 760 provided to an operator (also see [RFC4216]): 762 1) A way to enforce policies and filters at the domain borders to 763 process the incoming inter-domain TE LSP setup requests (Path 764 messages) based on certain agreed trust and service levels/contracts 765 between domains. Various LSP attributes such as bandwidth, priority, 766 etc. could be part of such a contract. 2) A way for the operator to 767 rate-limit LSP setup requests or error notifications from a 768 particular domain. 3) A mechanism to allow policy-based outbound RSVP 769 message processing at the domain border node, which may involve 770 filtering or modification of certain addresses in RSVP objects and 771 messages. 773 This document relates to inter-domain path computation. It must be 774 noted that the process for establishing paths described in this 775 document does not increase the information exchanged between ASes and 776 preserves topology confidentiality, in compliance with [RFC4105] and 777 [RFC4216]. That being said, the signaling of inter-domain TE LSP 778 according to the procedure defined in this document requires path 779 computation on boundary nodes that may be exposed to various attacks. 780 Thus it is RECOMMENDED to support policy decisions to reject the ERO 781 expansion of an inter-domain TE LSP if not allowed. 783 9. Acknowledgements 785 We would like to acknowledge input and helpful comments from Adrian 786 Farrel, Jean-Louis Le Roux, Dimitri Papadimitriou and Faisal Aslam. 788 10. References 790 10.1. Normative References 792 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 793 Requirement Levels", BCP 14, RFC 2119, March 1997. 795 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 796 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 797 Functional Specification", RFC 2205, September 1997. 799 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 800 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 801 Tunnels", RFC 3209, December 2001. 803 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 804 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 805 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 807 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 808 (TE) Extensions to OSPF Version 2", RFC 3630, 809 September 2003. 811 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 812 System (IS-IS) Extensions for Traffic Engineering (TE)", 813 RFC 3784, June 2004. 815 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 816 of Generalized Multi-Protocol Label Switching (GMPLS)", 817 RFC 4203, October 2005. 819 [RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to 820 Intermediate System (IS-IS) Extensions in Support of 821 Generalized Multi-Protocol Label Switching (GMPLS)", 822 RFC 4205, October 2005. 824 10.2. Informative References 826 [I-D.ietf-ccamp-crankback] 827 Farrel, A., "Crankback Signaling Extensions for MPLS and 828 GMPLS RSVP-TE", draft-ietf-ccamp-crankback-06 (work in 829 progress), January 2007. 831 [I-D.ietf-ccamp-inter-domain-rsvp-te] 832 Ayyangar, A. and J. Vasseur, "Inter domain MPLS and GMPLS 833 Traffic Engineering - RSVP-TE extensions", 834 draft-ietf-ccamp-inter-domain-rsvp-te-04 (work in 835 progress), January 2007. 837 [I-D.ietf-ccamp-loose-path-reopt] 838 Vasseur, J., "Reoptimization of Multiprotocol Label 839 Switching (MPLS) Traffic Engineering (TE) loosely routed 840 Label Switch Path (LSP)", 841 draft-ietf-ccamp-loose-path-reopt-02 (work in progress), 842 February 2006. 844 [I-D.ietf-ccamp-lsp-stitching] 845 Ayyangar, A., "Label Switched Path Stitching with 846 Generalized MPLS Traffic Engineering", 847 draft-ietf-ccamp-lsp-stitching-04 (work in progress), 848 December 2006. 850 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 851 McManus, "Requirements for Traffic Engineering Over MPLS", 852 RFC 2702, September 1999. 854 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 855 Authentication", RFC 2747, January 2000. 857 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 858 Authentication -- Updated Message Type Value", RFC 3097, 859 April 2001. 861 [RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for 862 Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. 864 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 865 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 866 November 2005. 868 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 869 Element (PCE)-Based Architecture", RFC 4655, August 2006. 871 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 872 Inter-Domain Multiprotocol Label Switching Traffic 873 Engineering", RFC 4726, November 2006. 875 Authors' Addresses 877 JP Vasseur (editor) 878 Cisco Systems, Inc 879 1414 Massachusetts Avenue 880 Boxborough, MA 01719 881 USA 883 Email: jpv@cisco.com 885 Arthi Ayyangar (editor) 886 Nuova Systems 887 2600 San Tomas Expressway 888 Santa Clara, CA 95051 889 USA 891 Email: arthi@nuovasystems.com 893 Raymond Zhang 894 BT Infonet 895 2160 E. Grand Ave. 896 El Segundo, CA 90025 897 USA 899 Email: raymond_zhang@bt.infonet.com 901 Full Copyright Statement 903 Copyright (C) The IETF Trust (2007). 905 This document is subject to the rights, licenses and restrictions 906 contained in BCP 78, and except as set forth therein, the authors 907 retain all their rights. 909 This document and the information contained herein are provided on an 910 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 911 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 912 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 913 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 914 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 915 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 917 Intellectual Property 919 The IETF takes no position regarding the validity or scope of any 920 Intellectual Property Rights or other rights that might be claimed to 921 pertain to the implementation or use of the technology described in 922 this document or the extent to which any license under such rights 923 might or might not be available; nor does it represent that it has 924 made any independent effort to identify any such rights. Information 925 on the procedures with respect to rights in RFC documents can be 926 found in BCP 78 and BCP 79. 928 Copies of IPR disclosures made to the IETF Secretariat and any 929 assurances of licenses to be made available, or the result of an 930 attempt made to obtain a general license or permission for the use of 931 such proprietary rights by implementers or users of this 932 specification can be obtained from the IETF on-line IPR repository at 933 http://www.ietf.org/ipr. 935 The IETF invites any interested party to bring to its attention any 936 copyrights, patents or patent applications, or other proprietary 937 rights that may cover technology that may be required to implement 938 this standard. Please address the information to the IETF at 939 ietf-ipr@ietf.org. 941 Acknowledgment 943 Funding for the RFC Editor function is provided by the IETF 944 Administrative Support Activity (IASA).