idnits 2.17.1 draft-ietf-ccamp-inter-domain-pd-path-comp-06.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 959. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 970. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 977. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 983. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. 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 (November 16, 2007) is 5999 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: 2 errors (**), 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: May 19, 2008 Juniper Networks, Inc 5 R. Zhang 6 BT 7 November 16, 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-06 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 May 19, 2008. 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. 52 Per-domain computation applies where the full path of an inter-domain 53 TE LSP cannot be or is not determined at the ingress node of the TE 54 LSP, and is not signaled across domain boundaries. This is most 55 likely to arise owing to TE visibility limitations. The signaling 56 message indicates the destination and nodes up to the next domain 57 boundary. It may also indicate further domain boundaries or domain 58 identifiers. The path through each domain, possibly including the 59 choice of exit point from the domain, must be determined within the 60 domain. 62 Requirements Language 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in RFC 2119 [RFC2119]. 68 Table of Contents 70 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. General assumptions . . . . . . . . . . . . . . . . . . . . . 5 73 3.1. Common assumptions . . . . . . . . . . . . . . . . . . . . 5 74 3.2. Example of topology for the inter-area TE case . . . . . . 7 75 3.3. Example of topology for the inter-AS TE case . . . . . . . 8 76 4. Per-domain path computation procedures . . . . . . . . . . . . 9 77 4.1. Example with an inter-area TE LSP . . . . . . . . . . . . 13 78 4.1.1. Case 1: T0 is a contiguous TE LSP . . . . . . . . . . 13 79 4.1.2. Case 2: T0 is a stitched or nested TE LSP . . . . . . 14 80 4.2. Example with an inter-AS TE LSP . . . . . . . . . . . . . 14 81 4.2.1. Case 1: T1 is a contiguous TE LSP . . . . . . . . . . 14 82 4.2.2. Case 2: T1 is a stitched or nested TE LSP . . . . . . 15 83 5. Path optimality/diversity . . . . . . . . . . . . . . . . . . 15 84 6. Reoptimization of an inter-domain TE LSP . . . . . . . . . . . 16 85 6.1. Contiguous TE LSPs . . . . . . . . . . . . . . . . . . . . 17 86 6.2. Stitched or nested (non-contiguous) TE LSPs . . . . . . . 17 87 6.3. Path characteristics after reoptimization . . . . . . . . 18 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 93 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 95 Intellectual Property and Copyright Statements . . . . . . . . . . 23 97 1. Terminology 99 Terminology used in this document 101 AS: Autonomous System. 103 ABR: Area Border Router: routers used to connect two IGP areas (areas 104 in OSPF or levels in IS-IS). 106 ASBR: Autonomous System Border Router: routers used to connect 107 together ASes of a different or the same Service Provider via one or 108 more Inter-AS links. 110 Boundary LSR: a boundary LSR is either an ABR in the context of 111 inter-area TE or an ASBR in the context of inter-AS TE. 113 ERO: Explicit Route Object 115 IGP: Interior Gateway Protocol 117 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 119 Inter-area TE LSP: A TE LSP that crosses an IGP area. 121 LSR: Label Switching Router. 123 LSP: Label Switched Path. 125 TE LSP: Traffic Engineering Label Switched Path. 127 PCE: Path Computation Element: an entity (component, application or 128 network node) that is capable of computing a network path or route 129 based on a network graph and applying computational constraints. 131 TED: Traffic Engineering Database. 133 The notion of contiguous, stitched and nested TE LSPs is defined in 134 [RFC4726] and will not be repeated here. 136 2. Introduction 138 The requirements for inter-domain Traffic Engineering (inter-area and 139 inter-AS TE) have been developed by the Traffic Engineering Working 140 Group and have been stated in [RFC4105] and [RFC4216]. The framework 141 for inter-domain MPLS Traffic Engineering has been provided in 142 [RFC4726]. 144 Some of the mechanisms used to establish and maintain inter-domain TE 145 LSPs are specified in [I-D.ietf-ccamp-inter-domain-rsvp-te] and 146 [I-D.ietf-ccamp-lsp-stitching]. 148 This document exclusively focuses on the path computation aspects and 149 defines a method for establishing inter-domain TE LSP where each node 150 in charge of computing a section of an inter-domain TE LSP path is 151 always along the path of such TE LSP. 153 When the visibility of an end to end complete path spanning multiple 154 domains is not available at the Head-end LSR (LSR that inititiated 155 the TE LSP), one approach described in this document consists of 156 using a per-domain path computation technique during LSP setup to 157 determine the inter-domain TE LSP as it traverses multiple domains. 159 The mechanisms proposed in this document are also applicable to MPLS 160 TE domains other than IGP areas and ASs. 162 The solution described in this document does not attempt to address 163 all the requirements specified in [RFC4105] and [RFC4216]. This is 164 acceptable according to [RFC4216] which indicates that a solution may 165 be developed to address a particular deployment scenario and might, 166 therefore, not meet all requirements for other deployment scenarios. 168 It must be pointed out that the inter-domain path computation 169 technique proposed in this document is one among many others and the 170 choice of the appropriate technique must be driven by the set of 171 requirements for the paths attributes and the applicability to a 172 particular technique with respect to the deployment scenario. For 173 example, if the requirement is to get an end-to-end constraint-based 174 shortest path across multiple domains, then a mechanism using one or 175 more distributed PCEs could be used to compute the shortest path 176 across different domains (see [RFC4655]). Other offline mechanisms 177 for path computation are not precluded either. Note also that a 178 Service Provider may elect to use different inter-domain path 179 computation techniques for different TE LSP types. 181 3. General assumptions 183 3.1. Common assumptions 185 - Each domain in all the examples below is assumed to be capable of 186 doing Traffic Engineering (i.e. running OSPF-TE or ISIS-TE and 187 RSVP-TE). A domain may itself comprise multiple other domains. E.g. 188 An AS may itself be composed of several other sub-AS(es) (BGP 189 confederations) or areas/levels. In this case, the path computation 190 technique described for inter-area and inter-AS MPLS Traffic 191 Engineering just recursively applies. 193 - The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209] and 194 [RFC3473]). 196 - The path (specified by an ERO (Explicit Route Object) in an RSVP-TE 197 Path message)) for an inter-domain TE LSP may be signaled as a set of 198 (loose and/or strict) hops. 200 - The hops may identify: 202 * The complete strict path end-to-end across different domains 204 * The complete strict path in the source domain followed by boundary 205 LSRs (or domain identifiers, e.g. AS numbers) 207 * The complete list of boundary LSRs along the path 209 * The current boundary LSR and the LSP destination. 211 The set of (loose or strict) hops can either be statically configured 212 on the Head-end LSR or dynamically computed. A per-domain path 213 computation method is defined in this document with an optional Auto- 214 discovery mechanism based on IGP, BGP, policy routing information 215 yielding the next-hop boundary node (domain exit point, such as Area 216 Border Router (ABR) or an Autonomous System Border Router (ASBR) 217 along the path as the TE LSP is being signaled, along with potential 218 crankback mechanisms. Alternatively the domain exit points may be 219 statically configured on the Head-end LSR in which case next-hop 220 boundary node auto-discovery would not be required. 222 - Boundary LSRs are assumed to be capable of performing local path 223 computation for expansion of a loose next-hop in the signaled ERO if 224 the path is not signaled by the Head-end LSR as a set of strict hops 225 or if the strict hop is an abstract node (e.g. an AS). In any case, 226 no topology or resource information needs to be distributed between 227 domains (as mandated per [RFC4105] and [RFC4216]), which is critical 228 to preserve IGP/BGP scalability and confidentiality in the case of TE 229 LSPs spanning multiple routing domains. 231 - The paths for the intra-domain Hierarchical LSPs (H-LSP) or 232 Stitched LSPs (S-LSP) or for a contiguous TE LSP within the domain 233 may be pre-configured or computed dynamically based on the arriving 234 inter-domain LSP setup request (depending on the requirements of the 235 transit domain). Note that this capability is explicitly specified 236 as a requirement in [RFC4216]. When the paths for the H-LSPs/S-LSP 237 are pre-configured, the constraints as well as other parameters like 238 local protection scheme for the intra-domain H-LSP/S-LSP are also 239 pre-configured. 241 - While certain constraints like bandwidth can be used across 242 different domains, certain other TE constraints like resource 243 affinity, color, metric, etc. as listed in [RFC2702] may need to be 244 translated at domain boundaries. If required, it is assumed that, at 245 the domain boundary LSRs, there will exist some sort of local mapping 246 based on policy agreement in order to translate such constraints 247 across domain boundaries. It is expected that such an assumption 248 particularly applies to inter-AS TE: for example, the local mapping 249 would be similar to the Inter-AS TE Agreement Enforcement Polices 250 stated in [RFC4216]. 252 - The procedures defined in this document are applicable to any node 253 (not just boundary node) that receives a Path message with an ERO 254 that constains a loose hop or an abstract node that is not a simple 255 abstract node (that is, an abstract node that identifies more than 256 one LSR). 258 3.2. Example of topology for the inter-area TE case 260 The following example will be used for the inter-area TE case in this 261 document. 263 <-area 1-><-- area 0 --><--- area 2 ---> 264 ------ABR1------------ABR3------- 265 | / | | \ | 266 R0--X1 | | X2---X3--R1 267 | | | / | 268 ------ABR2-----------ABR4-------- 269 <=========== Inter-area TE LSP =======> 271 Figure 1 - Example of topology for the inter-area TE case 273 Description of Figure 1: 275 - ABR1, ABR2, ABR3 and ABR4 are ABRs, 276 - X1: an LSR in area 1, 277 - X2, X3: LSRs in area 2, 278 - An inter-area TE LSP T0 originated at R0 in area 1 and terminating 279 at R1 in area 2. 281 Notes: 283 - The terminology used in the example above corresponds to OSPF but 284 the path computation technique proposed in this document equally 285 applies to the case of an IS-IS multi-level network. 287 - Just a few routers in each area are depicted in the diagram above 288 for the sake of simplicity. 290 - The example depicted in Figure 1 shows the case where the Head-end 291 and Tail-end areas are connected by means of area 0. The case of an 292 inter-area TE LSP between two IGP areas that does not transit through 293 area 0 is not precluded. 295 3.3. Example of topology for the inter-AS TE case 297 We consider the following general case, built on a superset of the 298 various scenarios defined in [RFC4216]: 300 <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> 302 <---BGP---> <---BGP--> 303 CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 304 |\ \ | / | / | / | | | 305 | \ ASBR2---/ ASBR5 | -- | | | 306 | \ | | |/ | | | 307 R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2 309 <======= Inter-AS TE LSP(LSR to LSR)===========> 310 or 312 <======== Inter-AS TE LSP (CE to ASBR) => 314 or 316 <================= Inter-AS TE LSP (CE to CE)===============> 318 Figure 2 - Example of topology for the inter-AS TE case 320 The diagram depicted in Figure 2 covers all the inter-AS TE 321 deployment cases described in [RFC4216]. 323 Description of Figure 2: 325 - Three interconnected ASs, respectively AS1, AS2, and AS3. Note 326 that in some scenarios described in [RFC4216] AS1=AS3. 328 - The ASBRs in different ASs are BGP peers. There is usually no IGP 329 running on the single hop links interconnecting the ASBRs and also 330 referred to as inter-ASBR links. 332 - Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE 333 extensions (see [RFC3630], [RFC3784], [RFC4203] and [RFC4205]). In 334 other words, the ASes are TE enabled, 336 - Each AS can be made of several IGP areas. The path computation 337 technique described in this document applies to the case of a single 338 AS made of multiple IGP areas, multiples ASs made of a single IGP 339 areas or any combination of the above. For the sake of simplicity, 340 each routing domain will be considered as single area in this 341 document. The case of an Inter-AS TE LSP spanning multiple ASs where 342 some of those ASs are themselves made of multiple IGP areas can be 343 easily derived from the examples above: the per-domain path 344 computation technique described in this document is applied 345 recursively in this case. 347 - An inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6 348 in AS3. 350 4. Per-domain path computation procedures 352 The mechanisms for inter-domain TE LSP computation as described in 353 this document can be used regardless of the nature of the inter- 354 domain TE LSP (contiguous, stitched or nested). 356 Note that any path can be defined as a set of loose and strict hops. 357 In other words, in some cases, it might be desirable to rely on the 358 dynamic path computation in some domain, and exert a strict control 359 on the path in other domains (defining strict hops). 361 When an LSR that is a boundary node such as an ABR/ASBR receives a 362 Path message with an ERO that contains a strict node, the procedures 363 specified in [RFC3209] apply and no further action is needed. 365 When an LSR that is a boundary node such as an ABR/ASBR receives a 366 Path message with an ERO that contains a loose hop or an abstract 367 node that is not a simple abstract node (that is, an abstract node 368 that identifies more than one LSR), then it MUST follow the 369 procedures as described in [I-D.ietf-ccamp-inter-domain-rsvp-te]. 371 In addition, the following procedures describe the path computation 372 procedures that SHOULD be carried out on the LSR: 374 1) If the next hop is not present in the TED, the two following 375 conditions MUST be checked: 377 o If the IP address of the next hop boundary LSR is outside of the 378 current domain, 380 o If the next hop domain is PSC (Packet Switch Capable) and uses in- 381 band control channel 383 If the two conditions above are satisfied then the boundary LSR 384 SHOULD check if the next-hop has IP reachability (via IGP or BGP). 385 If the next-hop is not reachable, then a signaling failure occurs and 386 the LSR SHOULD send back an RSVP PathErr message upstream with error 387 code=24 ("Routing Problem") and error subcode as described in section 388 4.3.4 of [RFC3209]. If the available routing information indicates 389 that next-hop is reachable, the selected route will be expected to 390 pass through a domain boundary via a domain boundary LSR. The 391 determination of domain boundary point based on routing information 392 is what we term as "auto-discovery" in this document. In the absence 393 of such an auto-discovery mechanism, a) the ABR in the case of inter- 394 area TE or the ASBR in the next-hop AS in the case of inter-AS TE 395 should be the signaled loose next-hop in the ERO and hence should be 396 accessible via the TED or b) there needs to be an alternate scheme 397 that provides the domain exit points. Otherwise the path computation 398 for the inter-domain TE LSP will fail. 400 An implementation MAY support the ability to disable such IP 401 reachability fall-back option should the next hop boundary LSR not be 402 present in the TED. In other words, an implementation MAY support 403 the possibility to trigger a signaling failure whenever the next-hop 404 is not present in the TED. 406 2) Once the next-hop boundary LSR has been determined (according to 407 the procedure described in 1)) or if the next-hop boundary is present 408 in the TED 410 o Case of a contiguous TE LSP. Unless not allowed by policy, the 411 boundary LSR that processes the ERO SHOULD perform an ERO 412 expansion (process consisting of computing the constrained path up 413 to the next loose hop and add the list of hops as strcit nodes in 414 the ERO). If no path satisfying the set of constraints can be 415 found, then this is treated as a path computation and signaling 416 failure and an RSVP PathErr message SHOULD be sent for the inter- 417 domain TE LSP based on section 4.3.4 of [RFC3209]. 419 o Case of stitched or nested LSP 421 * If the boundary LSR is a candidate LSR for intra-area H-LSP/ 422 S-LSP setup (the boundary has local policy for nesting or 423 stitching), the TE LSP is a candidate for hierarchy/nesting 424 (the "Contiguous LSP" bit defined in 425 [I-D.ietf-ccamp-inter-domain-rsvp-te] is not set) and if there 426 is no H-LSP/S-LSP from this LSR to the next-hop boundary LSR 427 that satisfies the constraints, it SHOULD signal a H-LSP/S-LSP 428 to the next-hop boundary LSR. If pre-configured H-LSP(s) or 429 S-LSP(s) already exist, then it will try to select from among 430 those intra-domain LSPs. Depending on local policy, it MAY 431 signal a new H-LSP/S-LSP if this selection fails. If the 432 H-LSP/S-LSP is successfully signaled or selected, it propagates 433 the inter-domain Path message to the next-hop following the 434 procedures described in [I-D.ietf-ccamp-inter-domain-rsvp-te]. 435 If, for some reason the dynamic H-LSP/S-LSP setup to the next- 436 hop boundary LSR fails, then this SHOULD be treated as a path 437 computation and signaling failure and an RSVP PathErr message 438 SHOULD be sent upstream for the inter-domain LSP. Similarly, 439 if selection of a preconfigured H-LSP/S-LSP fails and local 440 policy prevents dynamic H-LSP/S this SHOULD be treated as a 441 path computation and signaling failure and an RSVP PathErr 442 SHOULD be sent upstream for the inter-domain TE LSP. In both 443 these cases procedures described in section 4.3.4 of [RFC3209] 444 SHOULD be followed to handle the failure. 446 * If, however, the boundary LSR is not a candidate for intra- 447 domain H-LSP/S-LSP (the boundary LSR does not have local policy 448 for nesting or stitching) or the TE LSP is a not candidate for 449 hierarchy/nesting (the "Contiguous LSP" bit defined in 450 [I-D.ietf-ccamp-inter-domain-rsvp-te] is set), then it SHOULD 451 apply the same procedure as for the contiguous case. 453 The ERO of an inter-domain TE LSP may comprise abstract nodes such as 454 ASes. In such a case, upon receiving the ERO whose next hop is an 455 AS, the boundary LSR has to determine the next-hop boundary LSR which 456 may be determined based on the "auto-discovery" process mentioned 457 above. If multiple ASBRs candidates exist the boundary LSR may apply 458 some policies based on peering contracts that may have been pre- 459 negotiated. Once the next-hop boundary LSR has been determined a 460 similar procedure as the one described above is followed. 462 Note related to the inter-AS TE case: 464 In terms of computation of an inter-AS TE LSP path, an interesting 465 optimization technique consists of allowing the ASBRs to flood the TE 466 information related to the inter-ASBR link(s) although no IGP TE is 467 enabled over those links (and so there is no IGP adjacency over the 468 inter-ASBR links). This of course implies for the inter-ASBR links 469 to be TE-enabled although no IGP is running on those links. 471 <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> 473 <---BGP---> <---BGP--> 474 CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 475 |\ \ | / | / | / | | | 476 | \ ASBR2---/ ASBR5 | -- | | | 477 | \ | | |/ | | | 478 R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2 480 Figure 3 - Flooding of the TE-related information for the Inter-ASBR links 482 Referring to figure 3, ASBR1 for example would advertise in its OSPF 483 LSA/IS-IS LSP the Traffic Engineering TLVs related to the link ASBR1- 484 ASBR4. 486 This allows an LSR (could be entry ASBR) in the previous AS to make a 487 more appropriate route selection up to the entry ASBR in the 488 immediately downstream AS taking into account the constraints 489 associated with the inter-ASBR links. This reduces the risk of call 490 set up failure due to inter-ASBR links not satisfying the inter-AS TE 491 LSP set of constraints. Note that the TE information is only related 492 to the inter-ASBR links: the TE LSA/LSP flooded by the ASBR includes 493 not only the TE-enabled links contained in the AS but also the inter- 494 ASBR links. 496 Note that no summarized TE information is leaked between ASes which 497 is compliant with the requirements listed in [RFC4105] and [RFC4216]. 499 For example, consider the diagram depicted in Figure 2: when ASBR1 500 floods its IGP TE LSA ((opaque LSA for OSPF)/LSP (TLV 22 for IS-IS)) 501 in its routing domain, it reflects the reservation states and TE 502 properties of the following links: X1-ASBR1, ASBR1-ASBR2 and ASBR1- 503 ASBR4. 505 Thanks to such an optimization, the inter-ASBRs TE link information 506 corresponding to the links originated by the ASBR is made available 507 in the TED of other LSRs in the same domain that the ASBR belongs to. 508 Consequently, the path computation for an inter-AS TE LSP path can 509 also take into account the inter-ASBR link(s). This will improve the 510 chance of successful signaling along the next AS in case of resource 511 shortage or unsatisfied constraints on inter-ASBR links and it 512 potentially reduces one level of crankback. Note that no topology 513 information is flooded and these links are not used in IGP SPF 514 computations. Only the TE information for the outgoing links 515 directly connected to the ASBR is advertised. 517 Note that an Operator may decide to operate a stitched segment or 518 1-hop hierarchical LSP for the inter-ASBR link. 520 4.1. Example with an inter-area TE LSP 522 The following example uses figure 1 as a reference. 524 4.1.1. Case 1: T0 is a contiguous TE LSP 526 The Head-end LSR (R0) first determines the next hop ABR (which could 527 be manually configured by the user or dynamically determined by using 528 auto-discovery mechanism). R0 then computes the path to reach the 529 selected next hop ABR (ABR1) and signals the Path message. When the 530 Path message reaches ABR1, it first determines the next hop ABR from 531 its area 0 along the LSP path (say ABR3), either directly from the 532 ERO (if for example the next hop ABR is specified as a loose hop in 533 the ERO) or by using the auto-discovery mechanism specified above. 535 - Example 1 (set of loose hops): R0-ABR1(loose)-ABR3(loose)-R1(loose) 537 - Example 2 (mix of strict and loose hops): R0-X1-ABR1-ABR3(loose)- 538 X2-X3-R1 540 Note that a set of paths can be configured on the Head-end LSR, 541 ordered by priority. Each priority path can be associated with a 542 different set of constraints. It may be desirable to systematically 543 have a last resort option with no constraint to ensure that the 544 inter-area TE LSP could always be set up if at least a TE path exists 545 between the inter-area TE LSP source and destination. In case of set 546 up failure or when an RSVP PathErr is received indicating the TE LSP 547 has suffered a failure, an implementation might support the 548 possibility to retry a particular path option configurable amount of 549 times (optionally with dynamic intervals between each trial) before 550 trying a lower priority path option. 552 Once it has computed the path up to the next hop ABR (ABR3), ABR1 553 sends the Path message along the computed path. Upon receiving the 554 Path message, ABR3 then repeats a similar procedure. If ABR3 cannot 555 find a path obeying the set of constraints for the inter-area TE LSP, 556 the signaling process stops and ABR3 sends a PathErr message to ABR1. 557 Then ABR1 can in turn trigger a new path computation by selecting 558 another egress boundary LSR (ABR4 in the example above) if crankback 559 is allowed for this inter-area TE LSP (see 560 [I-D.ietf-ccamp-crankback]). If crankback is not allowed for that 561 inter-area TE LSP or if ABR1 has been configured not to perform 562 crankback, then ABR1 MUST stop the signaling process and MUST forward 563 a PathErr up to the Head-end LSR (R0) without trying to select 564 another ABR. 566 4.1.2. Case 2: T0 is a stitched or nested TE LSP 568 The Head-end LSR (R0) first determines the next hop ABR (which could 569 be manually configured by the user or dynamically determined by using 570 auto-discovery mechanism). R0 then computes the path to reach the 571 selected next hop ABR and signals the Path message. When the Path 572 message reaches ABR1, it first determines the next hop ABR from its 573 area 0 along the LSP path (say ABR3), either directly from the ERO 574 (if for example the next hop ABR is specified as a loose hop in the 575 ERO) or by using an auto-discovery mechanism, specified above. 577 ABR1 then checks if it has a H-LSP or S-LSP to ABR3 matching the 578 constraints carried in the inter-area TE LSP Path message. If not, 579 ABR1 computes the path for a H-LSP or S-LSP from ABR1 to ABR3 580 satisfying the constraint and sets it up accordingly. Note that the 581 H-LSP or S-LSP could have also been pre-configured. 583 Once ABR1 has selected the H-LSP/S-LSP for the inter-area LSP, using 584 the signaling procedures described in 585 [I-D.ietf-ccamp-inter-domain-rsvp-te], ABR1 sends the Path message 586 for inter-area TE LSP to ABR3. Note that irrespective of whether 587 ABR1 does nesting or stitching, the Path message for the inter-area 588 TE LSP is always forwarded to ABR3. ABR3 then repeats the exact same 589 procedures. If ABR3 cannot find a path obeying the set of 590 constraints for the inter-area TE LSP, ABR3 sends a PathErr message 591 to ABR1. Then ABR1 can in turn either select another H-LSP/S-LSP to 592 ABR3 if such an LSP exists or select another egress boundary LSR 593 (ABR4 in the example above) if crankback is allowed for this inter- 594 area TE LSP (see [I-D.ietf-ccamp-crankback]). If crankback is not 595 allowed for that inter-area TE LSP or if ABR1 has been configured not 596 to perform crankback, then ABR1 forwards the PathErr up to the inter- 597 area Head-end LSR (R0) without trying to select another egress LSR. 599 4.2. Example with an inter-AS TE LSP 601 The following example uses figure 2 as a reference. 603 The path computation procedures for establishing an inter-AS TE LSP 604 are very similar to those of an inter-area TE LSP described above. 605 The main difference is related to the presence of inter-ASBRs 606 link(s). 608 4.2.1. Case 1: T1 is a contiguous TE LSP 610 The inter-AS TE path may be configured on the Head-end LSR as a set 611 of strict hops, loose hops or a combination of both. 613 - Example 1 (set of loose hops): ASBR4(loose)-ASBR9(loose)-R6(loose) 614 - Example 2 (mix of strict and loose hops): R2-ASBR3-ASBR2-ASBR1- 615 ASBR4-ASBR10(loose)-ASBR9-R6 617 In the example 1 above, a per-AS path computation is performed, 618 respectively on R0 for AS1, ASBR4 for AS2 and ASBR9 for AS3. Note 619 that when an LSR has to perform an ERO expansion, the next hop must 620 either belong to the same AS, or must be the ASBR directly connected 621 to the next hops AS. In this later case, the ASBR reachability is 622 announced in the IGP TE LSA/LSP originated by its neighboring ASBR. 623 In the example 1 above, the TE LSP path is defined as: ASBR4(loose)- 624 ASBR9(loose)-R6(loose). This implies that R0 must compute the path 625 from R0 to ASBR4, hence the need for R0 to get the TE reservation 626 state related to the ASBR1-ASBR4 link (flooded in AS1 by ASBR1). In 627 addition, ASBR1 must also announce the IP address of ASBR4 specified 628 in the T1's path configuration. 630 Once it has computed the path up to the next hop ASBR, ASBR1 sends 631 the Path message for the inter-area TE LSP to ASBR4 (supposing that 632 ASBR4 is the selected next hop ASBR). ASBR4 then repeats the exact 633 same procedures. If ASBR4 cannot find a path obeying the set of 634 constraints for the inter-AS TE LSP, then ASBR4 sends a PathErr 635 message to ASBR1. Then ASBR1 can in turn either select another ASBR 636 (ASBR5 in the example above) if crankback is allowed for this 637 inter-AS TE LSP (see [I-D.ietf-ccamp-crankback]). If crankback is 638 not allowed for that inter-AS TE LSP or if ASBR1 has been configured 639 not to perform crankback, ABR1 stops the signaling process and 640 forwards a PathErr up to the Head-end LSR (R0) without trying to 641 select another egress LSR. In this case, the Head-end LSR can in 642 turn select another sequence of loose hops, if configured. 643 Alternatively, the Head-end LSR may decide to retry the same path; 644 this can be useful in case of set up failure due an outdated IGP TE 645 database in some downstream AS. An alternative could also be for the 646 Head-end LSR to retry to same sequence of loose hops after having 647 relaxed some constraint(s). 649 4.2.2. Case 2: T1 is a stitched or nested TE LSP 651 The path computation procedures are very similar to the inter-area 652 LSP setup case described earlier. In this case, the H-LSPs or S-LSPs 653 are originated by the ASBRs at the entry to the AS. 655 5. Path optimality/diversity 657 Since the inter-domain TE LSP is computed on a per domain (area, AS) 658 basis, one cannot guarantee that the optimal inter-domain path can be 659 found. 661 Moreover, computing two diverse paths using a per-domain path 662 computation approach may not be possible in some topologies (due to 663 the well-known 'trapping' problem). 665 For example, consider the following simple topology: 667 +-------+ 668 / \ 669 A----B-----C------D 670 \ / 671 +---------+ 673 Figure 4 - Example of "trapping" problem 674 In the simple topology depicted in figure 3, with a serialized 675 approach using the per-domain path computation technique specified in 676 this document, a first TE LSP may be computed following the path 677 A-B-C-D, in which case no diverse path could be found although two 678 diverse paths actually exist: A-C-D and A-B-D. The aim of that 679 simple example that can easily be extended to the inter-domain case 680 is to illustrate the potential issue of not being able to find 681 diverse paths using the per-domain path computation approach when 682 diverse paths exist. 684 As already pointed out, the required path computation method can be 685 selected by the Service Provider on a per LSP basis. 687 If the per-domain path computation technique does not meet the set of 688 requirements for a particular TE LSP (e.g. path optimality, 689 requirements for a set of diversely routed TE LSPs, ...) other 690 techniques such as PCE-based path computation techniques may be used 691 (see [RFC4655]). 693 6. Reoptimization of an inter-domain TE LSP 695 As stated in [RFC4216]and in [RFC4105], the ability to reoptimize an 696 already established inter-domain TE LSP constitutes a requirement. 697 The reoptimization process significantly differs based upon the 698 nature of the TE LSP and the mechanism in use for the TE LSP 699 computation. 701 The following mechanisms can be used for reoptimization and are 702 dependent on the nature of the inter-domain TE LSP. 704 6.1. Contiguous TE LSPs 706 After an inter-domain TE LSP has been set up, a more optimal route 707 might appear within any traversed domain. Then in this case, it is 708 desirable to get the ability to reroute an inter-domain TE LSP in a 709 non-disruptive fashion (making use of the so-called Make-Before-Break 710 procedure) to follow such more optimal path. This is a known as a TE 711 LSP reoptimization procedure. 713 [RFC4736] proposes a mechanism that allows the Head-end LSR to be 714 notified of the existence of a more optimal path in a downstream 715 domain. The Head-end LSR may then decide to gracefully reroute the 716 TE LSP using the so-called Make-Before-Break procedure. In case of a 717 contiguous LSP, the reoptimization process is strictly controlled by 718 the Head-end LSR which triggers the make-before-break procedure as 719 defined in [RFC3209], regardless of the location of the more optimal 720 path. 722 6.2. Stitched or nested (non-contiguous) TE LSPs 724 In the case of a stitched or nested inter-domain TE LSP, the 725 reoptimization process is treated as a local matter to any domain. 726 The main reason is that the inter-domain TE LSP is a different LSP 727 (and therefore different RSVP session) from the intra-domain S-LSP or 728 H-LSP in an area or an AS. Therefore, reoptimization in a domain is 729 done by locally reoptimizing the intra-domain H-LSP or S-LSP. Since 730 the inter-domain TE LSPs are transported using S-LSP or H-LSP across 731 each domain, optimality of the inter-domain TE LSP in a domain is 732 dependent on the optimality of the corresponding S-LSP or H-LSPs. 733 If, after an inter-domain LSP is setup, a more optimal path is 734 available within an domain, the corresponding S-LSP or H-LSP will be 735 reoptimized using "Make-Before-Break" techniques discussed in 736 [RFC3209]. Reoptimization of the H-LSP or S-LSP automatically 737 reoptimizes the inter-domain TE LSPs that the H-LSP or the S-LSP 738 transports. Reoptimization parameters like frequency of 739 reoptimization, criteria for reoptimization like metric or bandwidth 740 availability, etc can vary from one domain to another and can be 741 configured as required, per intra-domain TE S-LSP or H-LSP if it is 742 preconfigured or based on some global policy within the domain. 744 Hence, in this scheme, since each domain takes care of reoptimizing 745 its own S-LSPs or H-LSPs, and therefore the corresponding inter- 746 domain TE LSPs, the Make-Before-Break can happen locally and is not 747 triggered by the Head-end LSR for the inter-domain LSP. So, no 748 additional RSVP signaling is required for LSP reoptimization and 749 reoptimization is transparent to the Head-end LSR of the inter-domain 750 TE LSP. 752 If, however, an operator desires to manually trigger reoptimization 753 at the Head-end LSR for the inter-domain TE LSP, then this solution 754 does not prevent that. A manual trigger for reoptimization at the 755 Head-end LSR SHOULD force a reoptimization thereby signaling a "new" 756 path for the same LSP (along the more optimal path) making use of the 757 Make-Before-Break procedure. In response to this new setup request, 758 the boundary LSR may either initiate new S-LSP setup, in case the 759 inter-domain TE LSP is being stitched to the intra-domain S-LSP or it 760 may select an existing or new H-LSP in case of nesting. When the LSP 761 setup along the current path is complete, the Head-end LSR should 762 switchover the traffic onto that path and the old path is eventually 763 torn down. Note that the Head-end LSR does not know a priori whether 764 a more optimal path exists. Such a manual trigger from the Head-end 765 LSR of the inter-domain TE LSP is, however, not considered to be a 766 frequent occurrence. 768 Procedures described in [RFC4736] MUST be used if the operator does 769 not desire local reoptimization of certain inter-domain LSPs. In 770 this case, any reoptimization event within the domain MUST be 771 reported to the Head-end node. This SHOULD be a configurable policy. 773 6.3. Path characteristics after reoptimization 775 Note that in the case of loose hop reoptimization of contiguous 776 inter-domain TE LSP or local reoptimization of stitched/nested S-LSP 777 where boundary LSRs are specified as loose hops, the TE LSP may 778 follow a preferable path within one or more domain(s) but would still 779 traverse the same set of boundary LSRs. In contrast, in the case of 780 PCE-based path computation techniques, because end to end optimal 781 path is computed, the reoptimization process may lead to following a 782 completely different inter-domain path (including a different set of 783 boundary LSRs). 785 7. IANA Considerations 787 This document makes no request for any IANA action. 789 8. Security Considerations 791 Signaling of inter-domain TE LSPs raises security issues (discussed 792 in section 7 of [I-D.ietf-ccamp-inter-domain-rsvp-te]). 794 [RFC4726] provides an overview of the requirements for security in an 795 MPLS-TE or GMPLS multi-domain environment. In particular, when 796 signaling an inter-domain RSVP-TE LSP, an operator may make use of 797 the security features already defined for RSVP-TE ([RFC3209]). This 798 may require some coordination between the domains to share the keys 799 (see [RFC2747] and [RFC3097]), and care is required to ensure that 800 the keys are changed sufficiently frequently. Note that this may 801 involve additional synchronization, should the domain border nodes be 802 protected with Fast Rerotue ([RFC4090], since the Merge Point (MP) 803 and Point of Local Repair (PLR) should also share the key. For an 804 inter-domain TE LSP, especially when it traverses different 805 administrative or trust domains, the following mechanisms SHOULD be 806 provided to an operator (also see [RFC4216]): 808 1) A way to enforce policies and filters at the domain borders to 809 process the incoming inter-domain TE LSP setup requests (Path 810 messages) based on certain agreed trust and service levels/contracts 811 between domains. Various LSP attributes such as bandwidth, priority, 812 etc. could be part of such a contract. 2) A way for the operator to 813 rate-limit LSP setup requests or error notifications from a 814 particular domain. 3) A mechanism to allow policy-based outbound RSVP 815 message processing at the domain border node, which may involve 816 filtering or modification of certain addresses in RSVP objects and 817 messages. 819 This document relates to inter-domain path computation. It must be 820 noted that the process for establishing paths described in this 821 document does not increase the information exchanged between ASes and 822 preserves topology confidentiality, in compliance with [RFC4105] and 823 [RFC4216]. That being said, the signaling of inter-domain TE LSP 824 according to the procedure defined in this document requires path 825 computation on boundary nodes that may be exposed to various attacks. 826 Thus it is RECOMMENDED to support policy decisions to reject the ERO 827 expansion of an inter-domain TE LSP if not allowed. 829 9. Acknowledgements 831 We would like to acknowledge input and helpful comments from Adrian 832 Farrel, Jean-Louis Le Roux, Dimitri Papadimitriou and Faisal Aslam. 834 10. References 836 10.1. Normative References 838 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 839 Requirement Levels", BCP 14, RFC 2119, March 1997. 841 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 842 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 843 Tunnels", RFC 3209, December 2001. 845 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 846 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 847 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 849 10.2. Informative References 851 [I-D.ietf-ccamp-crankback] 852 Farrel, A., "Crankback Signaling Extensions for MPLS and 853 GMPLS RSVP-TE", draft-ietf-ccamp-crankback-06 (work in 854 progress), January 2007. 856 [I-D.ietf-ccamp-inter-domain-rsvp-te] 857 Ayyangar, A., "Inter domain Multiprotocol Label Switching 858 (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - 859 RSVP-TE extensions", 860 draft-ietf-ccamp-inter-domain-rsvp-te-07 (work in 861 progress), September 2007. 863 [I-D.ietf-ccamp-lsp-stitching] 864 Ayyangar, A., "Label Switched Path Stitching with 865 Generalized Multiprotocol Label Switching Traffic 866 Engineering (GMPLS TE)", draft-ietf-ccamp-lsp-stitching-06 867 (work in progress), April 2007. 869 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 870 McManus, "Requirements for Traffic Engineering Over MPLS", 871 RFC 2702, September 1999. 873 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 874 Authentication", RFC 2747, January 2000. 876 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 877 Authentication -- Updated Message Type Value", RFC 3097, 878 April 2001. 880 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 881 (TE) Extensions to OSPF Version 2", RFC 3630, 882 September 2003. 884 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 885 System (IS-IS) Extensions for Traffic Engineering (TE)", 886 RFC 3784, June 2004. 888 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 889 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 890 May 2005. 892 [RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for 893 Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. 895 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 896 of Generalized Multi-Protocol Label Switching (GMPLS)", 897 RFC 4203, October 2005. 899 [RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to 900 Intermediate System (IS-IS) Extensions in Support of 901 Generalized Multi-Protocol Label Switching (GMPLS)", 902 RFC 4205, October 2005. 904 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 905 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 906 November 2005. 908 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 909 Element (PCE)-Based Architecture", RFC 4655, August 2006. 911 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 912 Inter-Domain Multiprotocol Label Switching Traffic 913 Engineering", RFC 4726, November 2006. 915 [RFC4736] Vasseur, JP., Ikejiri, Y., and R. Zhang, "Reoptimization 916 of Multiprotocol Label Switching (MPLS) Traffic 917 Engineering (TE) Loosely Routed Label Switched Path 918 (LSP)", RFC 4736, November 2006. 920 Authors' Addresses 922 JP Vasseur (editor) 923 Cisco Systems, Inc 924 1414 Massachusetts Avenue 925 Boxborough, MA 01719 926 USA 928 Email: jpv@cisco.com 930 Arthi Ayyangar (editor) 931 Juniper Networks, Inc 932 1194 N.Mathilda Ave 933 Sunnyvale, CA 94089 934 USA 936 Email: arthi@juniper.net 937 Raymond Zhang 938 BT 939 2160 E. Grand Ave. 940 El Segundo, CA 90025 941 USA 943 Email: raymond.zhang@bt.com 945 Full Copyright Statement 947 Copyright (C) The IETF Trust (2007). 949 This document is subject to the rights, licenses and restrictions 950 contained in BCP 78, and except as set forth therein, the authors 951 retain all their rights. 953 This document and the information contained herein are provided on an 954 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 955 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 956 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 957 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 958 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 959 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 961 Intellectual Property 963 The IETF takes no position regarding the validity or scope of any 964 Intellectual Property Rights or other rights that might be claimed to 965 pertain to the implementation or use of the technology described in 966 this document or the extent to which any license under such rights 967 might or might not be available; nor does it represent that it has 968 made any independent effort to identify any such rights. Information 969 on the procedures with respect to rights in RFC documents can be 970 found in BCP 78 and BCP 79. 972 Copies of IPR disclosures made to the IETF Secretariat and any 973 assurances of licenses to be made available, or the result of an 974 attempt made to obtain a general license or permission for the use of 975 such proprietary rights by implementers or users of this 976 specification can be obtained from the IETF on-line IPR repository at 977 http://www.ietf.org/ipr. 979 The IETF invites any interested party to bring to its attention any 980 copyrights, patents or patent applications, or other proprietary 981 rights that may cover technology that may be required to implement 982 this standard. Please address the information to the IETF at 983 ietf-ipr@ietf.org. 985 Acknowledgment 987 Funding for the RFC Editor function is provided by the IETF 988 Administrative Support Activity (IASA).