idnits 2.17.1 draft-ietf-ccamp-inter-domain-pd-path-comp-05.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, updated by RFC 4748 on line 906. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 917. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 924. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 930. 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 (April 2007) is 6219 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) -- Obsolete informational reference (is this intentional?): RFC 3784 (Obsoleted by RFC 5305) -- Obsolete informational reference (is this intentional?): RFC 4205 (Obsoleted by RFC 5307) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 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: October 2007 Nuova Systems 5 R. Zhang 6 BT Infonet 7 April 2007 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-05 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 Abstract 39 This document specifies a per-domain path computation technique for 40 establishing inter-domain Traffic Engineering (TE) Multiprotocol 41 Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched 42 Paths (LSPs). In this document a domain refers to a collection of 43 network elements within a common sphere of address management or path 44 computational responsibility such as IGP areas and Autonomous 45 Systems. 47 Per-domain computation applies where the full path of an inter-domain 48 TE LSP cannot be or is not determined at the ingress node of the TE 49 LSP, and is not signaled across domain boundaries. This is most 50 likely to arise owing to TE visibility limitations. The signaling 51 message indicates the destination and nodes up to the next domain 52 boundary. It may also indicate further domain boundaries or domain 53 identifiers. The path through each domain, possibly including the 54 choice of exit point from the domain, must be determined within 55 the domain. 57 Requirements Language 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 [RFC2119]. 63 Table of Contents 65 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. General assumptions . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Common assumptions . . . . . . . . . . . . . . . . . . . . 5 69 3.2. Example of topology for the inter-area TE case . . . . . . 7 70 3.3. Example of topology for the inter-AS TE case . . . . . . . 8 71 4. Per-domain path computation procedures . . . . . . . . . . . . 9 72 4.1. Example with an inter-area TE LSP . . . . . . . . . . . . 12 73 4.1.1. Case 1: T0 is a contiguous TE LSP . . . . . . . . . . 12 74 4.1.2. Case 2: T0 is a stitched or nested TE LSP . . . . . . 13 75 4.2. Example with an inter-AS TE LSP . . . . . . . . . . . . . 14 76 4.2.1. Case 1: T1 is a contiguous TE LSP . . . . . . . . . . 14 77 4.2.2. Case 2: T1 is a stitched or nested TE LSP . . . . . . 15 78 5. Path optimality/diversity . . . . . . . . . . . . . . . . . . 15 79 6. Reoptimization of an inter-domain TE LSP . . . . . . . . . . . 15 80 6.1. Contiguous TE LSPs . . . . . . . . . . . . . . . . . . . . 15 81 6.2. Stitched or nested (non-contiguous) TE LSPs . . . . . . . 16 82 6.3. Path characteristics after reoptimization . . . . . . . . 17 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 90 Intellectual Property and Copyright Statements . . . . . . . . . . 21 92 1. Terminology 94 Terminology used in this document 96 AS: Autonomous System. 98 ABR: routers used to connect two IGP areas (areas in OSPF or levels 99 in IS-IS). 101 ASBR: routers used to connect together ASes of a different or the 102 same Service Provider via one or more Inter-AS links. 104 Boundary LSR: a boundary LSR is either an ABR in the context of 105 inter-area TE or an ASBR in the context of inter-AS TE. 107 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 109 Inter-area TE LSP: A TE LSP that crosses an IGP area. 111 LSR: Label Switching Router. 113 LSP: Label Switched Path. 115 TE LSP: Traffic Engineering Label Switched Path. 117 PCE: Path Computation Element: an entity (component, application or 118 network node) that is capable of computing a network path or route 119 based on a network graph and applying computational constraints. 121 TED: Traffic Engineering Database. 123 The notion of contiguous, stitched and nested TE LSPs is defined in 124 [RFC4726] and will not be repeated here. 126 2. Introduction 128 The requirements for inter-domain Traffic Engineering (inter-area and 129 inter-AS TE) have been developed by the Traffic Engineering Working 130 Group and have been stated in [RFC4105] and [RFC4216]. The framework 131 for inter-domain MPLS Traffic Engineering has been provided in 132 [RFC4726]. 134 Some of the mechanisms used to establish and maintain inter-domain TE 135 LSPs are specified in [I-D.ietf-ccamp-inter-domain-rsvp-te] and 136 [I-D.ietf-ccamp-lsp-stitching]. 138 This document exclusively focuses on the path computation aspects and 139 defines a method for establishing inter-domain TE LSP where each node 140 in charge of computing a section of an inter-domain TE LSP path is 141 always along the path of such TE LSP. 143 When the visibility of an end to end complete path spanning multiple 144 domains is not available at the Head-end LSR, one approach described 145 in this document consists of using a per-domain path computation 146 technique during LSP setup to determine the inter-domain TE LSP as it 147 traverses multiple domains. 149 The mechanisms proposed in this document are also applicable to MPLS 150 TE domains other than IGP areas and ASs. 152 The solution described in this document does not attempt to address 153 all the requirements specified in [RFC4105] and [RFC4216]. This is 154 acceptable according to [RFC4216] which indicates that a solution may 155 be developed to address a particular deployment scenario and might, 156 therefore, not meet all requirements for other deployment scenarios. 158 It must be pointed out that the inter-domain path computation 159 technique proposed in this document is one among many others and the 160 choice of the appropriate technique must be driven by the set of 161 requirements for the paths attributes and the applicability to a 162 particular technique with respect to the deployment scenario. For 163 example, if the requirement is to get an end-to-end constraint-based 164 shortest path across multiple domains, then a mechanism using one or 165 more distributed PCEs could be used to compute the shortest path 166 across different domains (see [RFC4655]). Other offline mechanisms 167 for path computation are not precluded either. Note also that a 168 Service Provider may elect to use different inter-domain path 169 computation techniques for different TE LSP types. 171 3. General assumptions 173 3.1. Common assumptions 175 - Each domain in all the examples below is assumed to be capable of 176 doing Traffic Engineering (i.e. running OSPF-TE or ISIS-TE and 177 RSVP-TE). A domain may itself comprise multiple other domains. 178 E.g., An AS may itself be composed of several other sub-AS(es) (BGP 179 confederations) or areas/levels. In this case, the path 180 computation technique described for inter-area and inter-AS MPLS 181 Traffic Engineering just recursively applies. 183 - The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209] and 184 [RFC3473]). 186 - The path (ERO) for an inter-domain TE LSP may be signaled as a set 187 of (loose and/or strict) hops. 189 - 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 194 boundary 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 201 configured on the Head-end LSR or dynamically computed. A 202 per-domain path computation method is defined in this document with 203 an optional Auto-discovery mechanism based on IGP, BGP, policy 204 routing information yielding the next-hop boundary node (domain 205 exit point, such as ABR/ASBR) along the path as the TE LSP is being 206 signaled, along with potential crankback mechanisms. Alternatively 207 the domain exit points may be statically configured on the Head-end 208 LSR in which case next-hop boundary node auto-discovery would not 209 be required. 211 - Boundary LSRs are assumed to be capable of performing local path 212 computation for expansion of a loose next-hop in the signaled ERO 213 if the path is not signaled by the Head-end LSR as a set of strict 214 hops or if the strict hop is an abstract node (e.g. an AS). In any 215 case, no topology or resource information needs to be distributed 216 between domains (as mandated per [RFC4105] and [RFC4216]), which is 217 critical to preserve IGP/BGP scalability and confidentiality in the 218 case of TE LSPs spanning multiple routing domains. 220 - The paths for the intra-domain Hierarchical LSPs (H-LSP) or 221 Stitched LSPs (S-LSP) or for a contiguous TE LSP within the domain 222 may be pre-configured or computed dynamically based on the arriving 223 inter-domain LSP setup request (depending on the requirements of 224 the transit domain). Note that this capability is explicitly 225 specified as a requirement in [RFC4216]. When the paths for the 226 H-LSPs/S-LSP are pre-configured, the constraints as well as other 227 parameters like local protection scheme for the intra-domain 228 H-LSP/S-LSP are also pre-configured. 230 - While certain constraints like bandwidth can be used across 231 different domains, certain other TE constraints like resource 232 affinity, color, metric, etc. as listed in [RFC2702] may need to be 233 translated at domain boundaries. If required, it is assumed that, 234 at the domain boundary LSRs, there will exist some sort of local 235 mapping based on policy agreement in order to translate such 236 constraints across domain boundaries. It is expected that such an 237 assumption particularly applies to inter-AS TE: for example, the 238 local mapping would be similar to the Inter-AS TE Agreement 239 Enforcement Polices stated in [RFC4216]. 241 - The procedures defined in this document are applicable to any node 242 (not just boundary node) that receives a Path message with an ERO 243 that constains a loose hop or an abstract node that is not a simple 244 abstract node (that is, an abstract node that identifies more than 245 one LSR). 247 3.2. Example of topology for the inter-area TE case 249 The following example will be used for the inter-area TE case in this 250 document. 252 <-area 1-><-- area 0 --><--- area 2 ---> 253 ------ABR1------------ABR3------- 254 | / | | \ | 255 R0--X1 | | X2---X3--R1 256 | | | / | 257 ------ABR2-----------ABR4-------- 258 <=========== Inter-area TE LSP =======> 260 Figure 1 - Example of topology for the inter-area TE case 262 Description of Figure 1: 264 - ABR1, ABR2, ABR3 and ABR4 are ABRs, 265 - X1: an LSR in area 1, 266 - X2, X3: LSRs in area 2, 267 - An inter-area TE LSP T0 originated at R0 in area 1 and terminating 268 at R1 in area 2. 270 Notes: 272 - The terminology used in the example above corresponds to OSPF but 273 the path computation technique proposed in this document equally 274 applies to the case of an IS-IS multi-level network. 276 - Just a few routers in each area are depicted in the diagram above 277 for the sake of simplicity. 279 - The example depicted in Figure 1 shows the case where the Head-end 280 and Tail-end areas are connected by means of area 0. The case of 281 an inter-area TE LSP between two IGP areas that does not transit 282 through area 0 is not precluded. 284 3.3. Example of topology for the inter-AS TE case 286 We consider the following general case, built on a superset of the 287 various scenarios defined in [RFC4216]: 289 <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> 291 <---BGP---> <---BGP--> 292 CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 293 |\ \ | / | / | / | | | 294 | \ ASBR2---/ ASBR5 | -- | | | 295 | \ | | |/ | | | 296 R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2 298 <======= Inter-AS TE LSP(LSR to LSR)===========> 300 or 302 <======== Inter-AS TE LSP (CE to ASBR => 304 or 306 <================= Inter-AS TE LSP (CE to CE)===============> 308 Figure 2 - Example of topology for the inter-AS TE case 310 The diagram depicted in Figure 2 covers all the inter-AS TE 311 deployment cases described in [RFC4216]. 313 Description of Figure 2: 315 - Three interconnected ASs, respectively AS1, AS2, and AS3. Note 316 that in some scenarios described in [RFC4216] AS1=AS3. 318 - The ASBRs in different ASs are BGP peers. There is usually no IGP 319 running on the single hop links interconnecting the ASBRs and also 320 referred to as inter-ASBR links. 322 - Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE 323 extensions (see [RFC3630], [RFC3784], [RFC4203] and [RFC4205]). In 324 other words, the ASes are TE enabled, 326 - Each AS can be made of several IGP areas. The path computation 327 technique described in this document applies to the case of a 328 single AS made of multiple IGP areas, multiples ASs made of a 329 single IGP areas or any combination of the above. For the sake of 330 simplicity, each routing domain will be considered as single area 331 in this document. The case of an Inter-AS TE LSP spanning multiple 332 ASs where some of those ASs are themselves made of multiple IGP 333 areas can be easily derived from the examples above: the per-domain 334 path computation technique described in this document is applied 335 recursively in this case. 337 - An inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6 338 in AS3. 340 4. Per-domain path computation procedures 342 The mechanisms for inter-domain TE LSP computation as described in 343 this document can be used regardless of the nature of the inter- 344 domain TE LSP (contiguous, stitched or nested). 346 Note that any path can be defined as a set of loose and strict hops. 347 In other words, in some cases, it might be desirable to rely on the 348 dynamic path computation in some domain, and exert a strict control 349 on the path in other domains (defining strict hops). 351 When an LSR that is a boundary node such as an ABR/ASBR receives a 352 Path message with an ERO that contains a loose hop or an abstract 353 node that is not a simple abstract node (that is, an abstract node 354 that identifies more than one LSR), then it MUST follow the 355 procedures as described in [I-D.ietf-ccamp-inter-domain-rsvp-te]. In 356 addition, the following procedures describe the path computation 357 procedures that SHOULD be carried out on the LSR: 359 1) If the next hop is not present in the TED. 361 If the loose next-hop is not present in the TED, the following 362 conditions MUST be checked: 364 o If the IP address of the next hop boundary LSR is outside of the 365 current domain, 367 o If the domain is PSC (Packet Switch Capable) and uses in-band 368 control channel 370 If the two conditions above are satisfied then the boundary LSR 371 SHOULD check if the next-hop has IP reachability (via IGP or BGP). 372 If the next-hop is not reachable, then a signaling failure occurs and 373 the LSR SHOULD send back an RSVP PathErr message upstream with error 374 code=24 ("Routing Problem") and error subcode as described in section 375 4.3.4 of [RFC3209]. If the next-hop is reachable, then it SHOULD 376 find a domain boundary LSR (domain boundary point) to get to the 377 next-hop. The determination of domain boundary point based on 378 routing information is what we term as "auto-discovery" in this 379 document. In the absence of such an auto-discovery mechanism, a) the 380 ABR in the case of inter-area TE or the ASBR in the next-hop AS in 381 the case of inter-AS TE should be the signaled loose next-hop in the 382 ERO and hence should be accessible via the TED or b) there needs to 383 be an alternate scheme that provides the domain exit points. 384 Otherwise the path computation for the inter-domain TE LSP will fail. 386 An implementation MAY support the ability to disable such IP 387 reachability fall-back option should the next hop boundary LSR not be 388 present in the TED. In other words, an implementation MAY support 389 the possibility to trigger a signaling failure whenever the next-hop 390 is not present in the TED. 392 2) Once the next-hop boundary LSR has been determined (according to 393 the procedure described in 1)) or if the next-hop boundary is present 394 in the TED 396 o Case of a contiguous TE LSP. The boundary LSR that processes the 397 ERO SHOULD perform an ERO expansion (unless not allowed by policy) 398 after having computed the path to the next loose hop (ABR/ASBR) 399 that obeys the set of required constraints. If no path satisfying 400 the set of constraints can be found, then this SHOULD be treated 401 as a path computation and signaling failure and an RSVP PathErr 402 message SHOULD be sent for the inter-domain TE LSP based on 403 section 4.3.4 of [RFC3209]. 405 o Case of stitched or nested LSP 407 * If the boundary LSR is a candidate LSR for intra-area H-LSP/ 408 S-LSP setup (the LSR has local policy for nesting or 409 stitching), the TE LSP is a candidate for hierarchy/nesting 410 (the "Contiguous LSP" bit defined in 411 [I-D.ietf-ccamp-inter-domain-rsvp-te] is not set) and if there 412 is no H-LSP/S-LSP from this LSR to the next-hop boundary LSR 413 that satisfies the constraints, it SHOULD signal a H-LSP/S-LSP 414 to the next-hop boundary LSR. If pre-configured H-LSP(s) or 415 S-LSP(s) already exist, then it will try to select from among 416 those intra-domain LSPs. Depending on local policy, it MAY 417 signal a new H-LSP/S-LSP if this selection fails. If the 418 H-LSP/S-LSP is successfully signaled or selected, it propagates 419 the inter-domain Path message to the next-hop following the 420 procedures described in [I-D.ietf-ccamp-inter-domain-rsvp-te]. 421 If, for some reason the dynamic H-LSP/S-LSP setup to the next- 422 hop boundary LSR fails, then this SHOULD be treated as a path 423 computation and signaling failure and an RSVP PathErr message 424 SHOULD be sent upstream for the inter-domain LSP. Similarly, 425 if selection of a preconfigured H-LSP/S-LSP fails and local 426 policy prevents dynamic H-LSP/S this SHOULD be treated as a 427 path computation and signaling failure and an RSVP PathErr 428 SHOULD be sent upstream for the inter-domain TE LSP. In both 429 these cases procedures described in section 4.3.4 of [RFC3209] 430 SHOULD be followed to handle the failure. 432 * If, however, the boundary LSR is not a candidate for intra- 433 domain H-LSP/S-LSP (the LSR does not have local policy for 434 nesting or stitching) or the TE LSP is a not candidate for 435 hierarchy/nesting (the "Contiguous LSP" bit defined in 436 [I-D.ietf-ccamp-inter-domain-rsvp-te] is set), then it SHOULD 437 apply the same procedure as for the contiguous case. 439 Note that in both cases, path computation and signaling process may 440 be stopped due to policy violation. 442 The ERO of an inter-domain TE LSP may comprise abstract nodes such as 443 ASes. In such a case, upon receiving the ERO whose next hop is an 444 AS, the boundary LSR has to determine the next-hop boundary LSR which 445 may be determined based on the "auto-discovery" process mentioned 446 above. If multiple ASBRs candidates exist the boundary LSR may apply 447 some policies based on peering contracts that may have been pre- 448 negotiated. Once the next-hop boundary LSR has been determined a 449 similar procedure as the one described above is followed. 451 Note related to the inter-AS TE case: 453 In terms of computation of an inter-AS TE LSP path, an interesting 454 optimization technique consists of allowing the ASBRs to flood the 455 TE information related to the inter-ASBR link(s) although no IGP TE 456 is enabled over those links (and so there is no IGP adjacency over 457 the inter-ASBR links). This of course implies for the inter-ASBR 458 links to be TE-enabled although no IGP is running on those links. 459 This allows an LSR (could be entry ASBR) in the previous AS to make 460 a more appropriate route selection up to the entry ASBR in the 461 immediately downstream AS taking into account the constraints 462 associated with the inter-ASBR links. This reduces the risk of 463 call set up failure due to inter-ASBR links not satisfying the 464 inter-AS TE LSP set of constraints. Note that the TE information 465 is only related to the inter-ASBR links: the TE LSA/LSP flooded by 466 the ASBR includes not only the TE-enabled links contained in the AS 467 but also the inter-ASBR links. 469 Note that no summarized TE information is leaked between ASes which 470 is compliant with the requirements listed in [RFC4105] and [RFC4216]. 472 For example, consider the diagram depicted in Figure 2: when ASBR1 473 floods its IGP TE LSA ((opaque LSA for OSPF)/LSP (TLV 22 for IS-IS)) 474 in its routing domain, it reflects the reservation states and TE 475 properties of the following links: X1-ASBR1, ASBR1-ASBR2 and ASBR1- 476 ASBR4. 478 Thanks to such an optimization, the inter-ASBRs TE link information 479 corresponding to the links originated by the ASBR is made available 480 in the TED of other LSRs in the same domain that the ASBR belongs to. 481 Consequently, the path computation for an inter-AS TE LSP path can 482 also take into account the inter-ASBR link(s). This will improve the 483 chance of successful signaling along the next AS in case of resource 484 shortage or unsatisfied constraints on inter-ASBR links and it 485 potentially reduces one level of crankback. Note that no topology 486 information is flooded and these links are not used in IGP SPF 487 computations. Only the TE information for the outgoing links 488 directly connected to the ASBR is advertised. 490 Note that an Operator may decide to operate a stitched segment or 491 1-hop hierarchical LSP for the inter-ASBR link. 493 4.1. Example with an inter-area TE LSP 495 4.1.1. Case 1: T0 is a contiguous TE LSP 497 The Head-end LSR (R0) first determines the next hop ABR (which could 498 be manually configured by the user or dynamically determined by using 499 auto-discovery mechanism). R0 then computes the path to reach the 500 selected next hop ABR (ABR1) and signals the Path message. When the 501 Path message reaches ABR1, it first determines the next hop ABR from 502 its area 0 along the LSP path (say ABR3), either directly from the 503 ERO (if for example the next hop ABR is specified as a loose hop in 504 the ERO) or by using the auto-discovery mechanism specified above. 506 - Example 1 (set of loose hops): R0-ABR1(loose)-ABR3(loose)-R1(loose) 508 - Example 2 (mix of strict and loose hops): R0-X1-ABR1-ABR3(loose)- 509 X2-X3-R1 511 Note that a set of paths can be configured on the Head-end LSR, 512 ordered by priority. Each priority path can be associated with a 513 different set of constraints. It may be desirable to systematically 514 have a last resort option with no constraint to ensure that the 515 inter-area TE LSP could always be set up if at least a TE path exists 516 between the inter-area TE LSP source and destination. In case of set 517 up failure or when an RSVP PathErr is received indicating the TE LSP 518 has suffered a failure, an implementation might support the 519 possibility to retry a particular path option configurable amount of 520 times (optionally with dynamic intervals between each trial) before 521 trying a lower priority path option. 523 Once it has computed the path up to the next hop ABR (ABR3), ABR1 524 sends the Path message along the computed path. Upon receiving the 525 Path message, ABR3 then repeats a similar procedure. If ABR3 cannot 526 find a path obeying the set of constraints for the inter-area TE LSP, 527 the signaling process stops and ABR3 sends a PathErr message to ABR1. 528 Then ABR1 can in turn trigger a new path computation by selecting 529 another egress boundary LSR (ABR4 in the example above) if crankback 530 is allowed for this inter-area TE LSP (see 531 [I-D.ietf-ccamp-crankback]). If crankback is not allowed for that 532 inter-area TE LSP or if ABR1 has been configured not to perform 533 crankback, then ABR1 MUST stop the signaling process and MUST forward 534 a PathErr up to the Head-end LSR (R0) without trying to select 535 another ABR. 537 4.1.2. Case 2: T0 is a stitched or nested TE LSP 539 The Head-end LSR (R0) first determines the next hop ABR (which could 540 be manually configured by the user or dynamically determined by using 541 auto-discovery mechanism). R0 then computes the path to reach the 542 selected next hop ABR and signals the Path message. When the Path 543 message reaches ABR1, it first determines the next hop ABR from its 544 area 0 along the LSP path (say ABR3), either directly from the ERO 545 (if for example the next hop ABR is specified as a loose hop in the 546 ERO) or by using an auto-discovery mechanism, specified above. 548 ABR1 then checks if it has a H-LSP or S-LSP to ABR3 matching the 549 constraints carried in the inter-area TE LSP Path message. If not, 550 ABR1 computes the path for a H-LSP or S-LSP from ABR1 to ABR3 551 satisfying the constraint and sets it up accordingly. Note that the 552 H-LSP or S-LSP could have also been pre-configured. 554 Once ABR1 has selected the H-LSP/S-LSP for the inter-area LSP, using 555 the signaling procedures described in 556 [I-D.ietf-ccamp-inter-domain-rsvp-te], ABR1 sends the Path message 557 for inter-area TE LSP to ABR3. Note that irrespective of whether 558 ABR1 does nesting or stitching, the Path message for the inter-area 559 TE LSP is always forwarded to ABR3. ABR3 then repeats the exact same 560 procedures. If ABR3 cannot find a path obeying the set of 561 constraints for the inter-area TE LSP, ABR3 sends a PathErr message 562 to ABR1. Then ABR1 can in turn either select another H-LSP/S-LSP to 563 ABR3 if such an LSP exists or select another egress boundary LSR 564 (ABR4 in the example above) if crankback is allowed for this inter- 565 area TE LSP (see [I-D.ietf-ccamp-crankback]). If crankback is not 566 allowed for that inter-area TE LSP or if ABR1 has been configured not 567 to perform crankback, then ABR1 forwards the PathErr up to the inter- 568 area Head-end LSR (R0) without trying to select another egress LSR. 570 4.2. Example with an inter-AS TE LSP 572 The path computation procedures for establishing an inter-AS TE LSP 573 are very similar to those of an inter-area TE LSP described above. 574 The main difference is related to the presence of inter-ASBRs 575 link(s). 577 4.2.1. Case 1: T1 is a contiguous TE LSP 579 The inter-AS TE path may be configured on the Head-end LSR as a set 580 of strict hops, loose hops or a combination of both. 582 - Example 1 (set of loose hops): ASBR4(loose)-ASBR9(loose)-R6(loose) 584 - Example 2 (mix of strict and loose hops): R2-ASBR3-ASBR2-ASBR1- 585 ASBR4-ASBR10(loose)-ASBR9-R6 587 In the example 1 above, a per-AS path computation is performed, 588 respectively on R0 for AS1, ASBR4 for AS2 and ASBR9 for AS3. Note 589 that when an LSR has to perform an ERO expansion, the next hop must 590 either belong to the same AS, or must be the ASBR directly connected 591 to the next hops AS. In this later case, the ASBR reachability is 592 announced in the IGP TE LSA/LSP originated by its neighboring ASBR. 593 In the example 1 above, the TE LSP path is defined as: ASBR4(loose)- 594 ASBR9(loose)-R6(loose). This implies that R0 must compute the path 595 from R0 to ASBR4, hence the need for R0 to get the TE reservation 596 state related to the ASBR1-ASBR4 link (flooded in AS1 by ASBR1). In 597 addition, ASBR1 must also announce the IP address of ASBR4 specified 598 in the T1's path configuration. 600 Once it has computed the path up to the next hop ASBR, ASBR1 sends 601 the Path message for the inter-area TE LSP to ASBR4 (supposing that 602 ASBR4 is the selected next hop ASBR). ASBR4 then repeats the exact 603 same procedures. If ASBR4 cannot find a path obeying the set of 604 constraints for the inter-AS TE LSP, then ASBR4 sends a PathErr 605 message to ASBR1. Then ASBR1 can in turn either select another ASBR 606 (ASBR5 in the example above) if crankback is allowed for this 607 inter-AS TE LSP (see [I-D.ietf-ccamp-crankback]). If crankback is 608 not allowed for that inter-AS TE LSP or if ASBR1 has been configured 609 not to perform crankback, ABR1 stops the signaling process and 610 forwards a PathErr up to the Head-end LSR (R0) without trying to 611 select another egress LSR. In this case, the Head-end LSR can in 612 turn select another sequence of loose hops, if configured. 613 Alternatively, the Head-end LSR may decide to retry the same path; 614 this can be useful in case of set up failure due an outdated IGP TE 615 database in some downstream AS. An alternative could also be for the 616 Head-end LSR to retry to same sequence of loose hops after having 617 relaxed some constraint(s). 619 4.2.2. Case 2: T1 is a stitched or nested TE LSP 621 The path computation procedures are very similar to the inter-area 622 LSP setup case described earlier. In this case, the H-LSPs or S-LSPs 623 are originated by the ASBRs at the entry to the AS. 625 5. Path optimality/diversity 627 Since the inter-domain TE LSP is computed on a per domain (area, AS) 628 basis, one cannot guarantee that the optimal inter-domain path can be 629 found. 631 Moreover, computing two diverse paths using a per-domain path 632 computation approach may not be possible in some topologies (due to 633 the well-known 'trapping' problem). 635 As already pointed out, the required path computation method can be 636 selected by the Service Provider on a per LSP basis. 638 If the per-domain path computation technique does not meet the set of 639 requirements for a particular TE LSP (e.g. path optimality, 640 requirements for a set of diversely routed TE LSPs, ...) other 641 techniques such as PCE-based path computation techniques may be used 642 (see [RFC4655]). 644 6. Reoptimization of an inter-domain TE LSP 646 As stated in [RFC4216]and in [RFC4105], the ability to reoptimize an 647 already established inter-domain TE LSP constitutes a requirement. 648 The reoptimization process significantly differs based upon the 649 nature of the TE LSP and the mechanism in use for the TE LSP 650 computation. 652 The following mechanisms can be used for reoptimization and are 653 dependent on the nature of the inter-domain TE LSP. 655 6.1. Contiguous TE LSPs 657 After an inter-domain TE LSP has been set up, a more optimal route 658 might appear within any traversed domain. Then in this case, it is 659 desirable to get the ability to reroute an inter-domain TE LSP in a 660 non-disruptive fashion (making use of the so-called Make-Before-Break 661 procedure) to follow such more optimal path. This is a known as a TE 662 LSP reoptimization procedure. 664 [RFC4736] proposes a mechanism that allows the Head-end LSR to be 665 notified of the existence of a more optimal path in a downstream 666 domain. The Head-end LSR may then decide to gracefully reroute the 667 TE LSP using the so-called Make-Before-Break procedure. In case of a 668 contiguous LSP, the reoptimization process is strictly controlled by 669 the Head-end LSR which triggers the make-before-break procedure, 670 regardless of the location of the more optimal path. 672 6.2. Stitched or nested (non-contiguous) TE LSPs 674 In the case of a stitched or nested inter-domain TE LSP, the 675 reoptimization process is treated as a local matter to any domain. 676 The main reason is that the inter-domain TE LSP is a different LSP 677 (and therefore different RSVP session) from the intra-domain S-LSP or 678 H-LSP in an area or an AS. Therefore, reoptimization in a domain is 679 done by locally reoptimizing the intra-domain H-LSP or S-LSP. Since 680 the inter-domain TE LSPs are transported using S-LSP or H-LSP across 681 each domain, optimality of the inter-domain TE LSP in a domain is 682 dependent on the optimality of the corresponding S-LSP or H-LSPs. 683 If, after an inter-domain LSP is setup, a more optimal path is 684 available within an domain, the corresponding S-LSP or H-LSP will be 685 reoptimized using "Make-Before-Break" techniques discussed in 686 [RFC3209]. Reoptimization of the H-LSP or S-LSP automatically 687 reoptimizes the inter-domain TE LSPs that the H-LSP or the S-LSP 688 transports. Reoptimization parameters like frequency of 689 reoptimization, criteria for reoptimization like metric or bandwidth 690 availability, etc can vary from one domain to another and can be 691 configured as required, per intra-domain TE S-LSP or H-LSP if it is 692 preconfigured or based on some global policy within the domain. 694 Hence, in this scheme, since each domain takes care of reoptimizing 695 its own S-LSPs or H-LSPs, and therefore the corresponding inter- 696 domain TE LSPs, the Make-Before-Break can happen locally and is not 697 triggered by the Head-end LSR for the inter-domain LSP. So, no 698 additional RSVP signaling is required for LSP reoptimization and 699 reoptimization is transparent to the Head-end LSR of the inter-domain 700 TE LSP. 702 If, however, an operator desires to manually trigger reoptimization 703 at the Head-end LSR for the inter-domain TE LSP, then this solution 704 does not prevent that. A manual trigger for reoptimization at the 705 Head-end LSR SHOULD force a reoptimization thereby signaling a "new" 706 path for the same LSP (along the more optimal path) making use of the 707 Make-Before-Break procedure. In response to this new setup request, 708 the boundary LSR may either initiate new S-LSP setup, in case the 709 inter-domain TE LSP is being stitched to the intra-domain S-LSP or it 710 may select an existing or new H-LSP in case of nesting. When the LSP 711 setup along the current path is complete, the Head-end LSR should 712 switchover the traffic onto that path and the old path is eventually 713 torn down. Note that the Head-end LSR does not know a priori whether 714 a more optimal path exists. Such a manual trigger from the Head-end 715 LSR of the inter-domain TE LSP is, however, not considered to be a 716 frequent occurrence. 718 Procedures described in [RFC4736] MUST be used if the operator does 719 not desire local reoptimization of certain inter-domain LSPs. In 720 this case, any reoptimization event within the domain MUST be 721 reported to the Head-end node. This SHOULD be a configurable policy. 723 6.3. Path characteristics after reoptimization 725 Note that in the case of loose hop reoptimization of contiguous 726 inter-domain TE LSP or local reoptimization of stitched/nested S-LSP 727 where boundary LSRs are specified as loose hops, the TE LSP may 728 follow a preferable path within one or more domain(s) but would still 729 traverse the same set of boundary LSRs. In contrast, in the case of 730 PCE-based path computation techniques, because end to end optimal 731 path is computed, the reoptimization process may lead to following a 732 completely different inter-domain path (including a different set of 733 boundary LSRs). 735 7. IANA Considerations 737 This document makes no request for any IANA action. 739 8. Security Considerations 741 Signaling of inter-domain TE LSPs raises security issues (discussed 742 in section 7 of [I-D.ietf-ccamp-inter-domain-rsvp-te]). 744 [RFC4726] provides an overview of the requirements for security in an 745 MPLS-TE or GMPLS multi-domain environment. In particular, when 746 signaling an inter-domain RSVP-TE LSP, an operator may make use of 747 the security features already defined for RSVP-TE ([RFC3209]). This 748 may require some coordination between the domains to share the keys 749 (see [RFC2747] and [RFC3097]), and care is required to ensure that 750 the keys are changed sufficiently frequently. Note that this may 751 involve additional synchronization, should the domain border nodes be 752 protected with FRR, since the MP and PLR should also share the key. 753 For an inter-domain TE LSP, especially when it traverses different 754 administrative or trust domains, the following mechanisms SHOULD be 755 provided to an operator (also see [RFC4216]): 757 1) A way to enforce policies and filters at the domain borders to 758 process the incoming inter-domain TE LSP setup requests (Path 759 messages) based on certain agreed trust and service levels/contracts 760 between domains. Various LSP attributes such as bandwidth, priority, 761 etc. could be part of such a contract. 2) A way for the operator to 762 rate-limit LSP setup requests or error notifications from a 763 particular domain. 3) A mechanism to allow policy-based outbound RSVP 764 message processing at the domain border node, which may involve 765 filtering or modification of certain addresses in RSVP objects and 766 messages. 768 This document relates to inter-domain path computation. It must be 769 noted that the process for establishing paths described in this 770 document does not increase the information exchanged between ASes and 771 preserves topology confidentiality, in compliance with [RFC4105] and 772 [RFC4216]. That being said, the signaling of inter-domain TE LSP 773 according to the procedure defined in this document requires path 774 computation on boundary nodes that may be exposed to various attacks. 775 Thus it is RECOMMENDED to support policy decisions to reject the ERO 776 expansion of an inter-domain TE LSP if not allowed. 778 9. Acknowledgements 780 We would like to acknowledge input and helpful comments from Adrian 781 Farrel, Jean-Louis Le Roux, Dimitri Papadimitriou and Faisal Aslam. 783 Adrian Farrel prepared the final verison of this document for IESG 784 review. 786 10. References 788 10.1. Normative References 790 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 791 Requirement Levels", BCP 14, RFC 2119, March 1997. 793 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 794 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 795 Tunnels", RFC 3209, December 2001. 797 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 798 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 799 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 801 10.2. Informative References 803 [I-D.ietf-ccamp-crankback] 804 Farrel, A., "Crankback Signaling Extensions for MPLS and 805 GMPLS RSVP-TE", draft-ietf-ccamp-crankback (work in 806 progress). 808 [I-D.ietf-ccamp-inter-domain-rsvp-te] 809 Ayyangar, A. and J. Vasseur, "Inter domain MPLS and GMPLS 810 Traffic Engineering - RSVP-TE extensions", 811 draft-ietf-ccamp-inter-domain-rsvp-te (work in 812 progress. 814 [I-D.ietf-ccamp-lsp-stitching] 815 Ayyangar, A., "Label Switched Path Stitching with 816 Generalized MPLS Traffic Engineering", 817 draft-ietf-ccamp-lsp-stitching (work in progress). 819 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 820 McManus, "Requirements for Traffic Engineering Over MPLS", 821 RFC 2702, September 1999. 823 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 824 Authentication", RFC 2747, January 2000. 826 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 827 Authentication -- Updated Message Type Value", RFC 3097, 828 April 2001. 830 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 831 (TE) Extensions to OSPF Version 2", RFC 3630, 832 September 2003. 834 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 835 System (IS-IS) Extensions for Traffic Engineering (TE)", 836 RFC 3784, June 2004. 838 [RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for 839 Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. 841 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 842 of Generalized Multi-Protocol Label Switching (GMPLS)", 843 RFC 4203, October 2005. 845 [RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to 846 Intermediate System (IS-IS) Extensions in Support of 847 Generalized Multi-Protocol Label Switching (GMPLS)", 848 RFC 4205, October 2005. 850 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 851 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 852 November 2005. 854 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 855 Element (PCE)-Based Architecture", RFC 4655, August 2006. 857 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 858 Inter-Domain Multiprotocol Label Switching Traffic 859 Engineering", RFC 4726, November 2006. 861 [RFC4736] Vasseur, J., Ikejiri, Y., and R. Zhang, "Reoptimization of 862 Multiprotocol Label Switching (MPLS) Traffic Engineering 863 (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, 864 November 2006. 866 Authors' Addresses 868 JP Vasseur (editor) 869 Cisco Systems, Inc 870 1414 Massachusetts Avenue 871 Boxborough, MA 01719 872 USA 874 Email: jpv@cisco.com 876 Arthi Ayyangar (editor) 877 Nuova Systems 878 2600 San Tomas Expressway 879 Santa Clara, CA 95051 880 USA 882 Email: arthi@nuovasystems.com 884 Raymond Zhang 885 BT Infonet 886 2160 E. Grand Ave. 887 El Segundo, CA 90025 888 USA 890 Email: raymond_zhang@bt.infonet.com 892 Full Copyright Statement 894 Copyright (C) The IETF Trust (2007). 896 This document is subject to the rights, licenses and restrictions 897 contained in BCP 78, and except as set forth therein, the authors 898 retain all their rights. 900 This document and the information contained herein are provided on an 901 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 902 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 903 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 904 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 905 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 906 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 908 Intellectual Property 910 The IETF takes no position regarding the validity or scope of any 911 Intellectual Property Rights or other rights that might be claimed to 912 pertain to the implementation or use of the technology described in 913 this document or the extent to which any license under such rights 914 might or might not be available; nor does it represent that it has 915 made any independent effort to identify any such rights. Information 916 on the procedures with respect to rights in RFC documents can be 917 found in BCP 78 and BCP 79. 919 Copies of IPR disclosures made to the IETF Secretariat and any 920 assurances of licenses to be made available, or the result of an 921 attempt made to obtain a general license or permission for the use of 922 such proprietary rights by implementers or users of this 923 specification can be obtained from the IETF on-line IPR repository at 924 http://www.ietf.org/ipr. 926 The IETF invites any interested party to bring to its attention any 927 copyrights, patents or patent applications, or other proprietary 928 rights that may cover technology that may be required to implement 929 this standard. Please address the information to the IETF at 930 ietf-ipr@ietf.org. 932 Acknowledgment 934 Funding for the RFC Editor function is provided by the IETF 935 Administrative Support Activity (IASA).