idnits 2.17.1 draft-vasseur-ccamp-inter-domain-path-comp-00.txt: -(80): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(92): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(490): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(498): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(500): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(788): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(912): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1262): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1274): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1278): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** 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 3667, Section 5.1 on line 1164. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1151. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 53 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1562 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 59, but not defined == Missing Reference: 'INTER-AREA-REQS' is mentioned on line 257, but not defined == Missing Reference: 'INTER-AS-REQS' is mentioned on line 258, but not defined == Missing Reference: 'INTER-DOMAIN-FRAMEWORK' is mentioned on line 172, but not defined == Missing Reference: 'INTER-AS-TE-REQS' is mentioned on line 549, but not defined == Missing Reference: 'INTER-AREA-TE-REQS' is mentioned on line 549, but not defined == Missing Reference: 'RFC2702' is mentioned on line 274, but not defined == Missing Reference: 'IS-IS-TE' is mentioned on line 348, but not defined == Missing Reference: 'CRANBACK' is mentioned on line 632, but not defined == Missing Reference: 'LOOSE-REOPT' is mentioned on line 997, but not defined == Unused Reference: 'RFC' is defined on line 1173, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 1176, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 1179, but no explicit reference was found in the text == Unused Reference: 'RSVP' is defined on line 1182, but no explicit reference was found in the text == Unused Reference: 'REFRESH-REDUCTION' is defined on line 1188, but no explicit reference was found in the text == Unused Reference: 'FAST-REROUTE' is defined on line 1192, but no explicit reference was found in the text == Unused Reference: 'ISIS-TE' is defined on line 1199, but no explicit reference was found in the text == Unused Reference: 'IGP-TE-CAP' is defined on line 1220, but no explicit reference was found in the text == Unused Reference: 'INT-AREA-REQ' is defined on line 1224, but no explicit reference was found in the text == Unused Reference: 'INT-AS-REQ' is defined on line 1228, but no explicit reference was found in the text == Unused Reference: 'INT-DOMAIN-FRWK' is defined on line 1232, but no explicit reference was found in the text == Unused Reference: 'FACILITY-BACKUP' is defined on line 1236, but no explicit reference was found in the text == Unused Reference: 'RSVP-CONSTRAINTS' is defined on line 1249, but no explicit reference was found in the text == Unused Reference: 'LSP-ATTRIBUTE' is defined on line 1252, but no explicit reference was found in the text == Unused Reference: 'GMPLS-OVERLAY' is defined on line 1256, but no explicit reference was found in the text == Unused Reference: 'EXCLUDE-ROUTE' is defined on line 1259, but no explicit reference was found in the text == Unused Reference: 'INTER-AREA-TE' is defined on line 1262, but no explicit reference was found in the text == Unused Reference: 'LSPPING' is defined on line 1265, but no explicit reference was found in the text == Unused Reference: 'MPLS-TTL' is defined on line 1283, but no explicit reference was found in the text == Unused Reference: 'LOOSE-PATH-REOPT' is defined on line 1273, but no explicit reference was found in the text == Unused Reference: 'NODE-ID' is defined on line 1277, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-lsp-fastreroute-03 ** Obsolete normative reference: RFC 3784 (ref. 'ISIS-TE') (Obsoleted by RFC 5305) == Outdated reference: A later version (-11) exists of draft-ietf-ospf-cap-03 == Outdated reference: A later version (-03) exists of draft-ietf-tewg-interarea-mpls-te-req-02 == Outdated reference: A later version (-09) exists of draft-ietf-tewg-interas-mpls-te-req-07 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-rsvp-te-exclude-route-00 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-nodeid-subobject-02 Summary: 15 errors (**), 0 flaws (~~), 41 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 JP Vasseur (Editor) 2 Cisco Systems, Inc. 3 Arthi Ayyangar (Editor) 4 Juniper Networks 5 Raymond Zhang 6 CCAMP Working Group Infonet Service Corporation 7 IETF Internet Draft 8 Expires: January, 2005 9 July, 2004 11 draft-vasseur-ccamp-inter-domain-path-comp-00.txt 13 Inter-domain Traffic Engineering LSP path computation methods 15 Status of this Memo 17 By submitting this Internet-Draft, I certify that any applicable patent 18 or IPR claims of which I am aware have been disclosed, and any of which 19 I become aware will be disclosed, in accordance with RFC 3668. 21 This document is an Internet-Draft and is in full conformance with all 22 provisions of Section 10 of RFC2026. Internet-Drafts are 23 Working documents of the Internet Engineering Task Force (IETF), its 24 areas, and its working groups. Note that other groups may also 25 distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference material 30 or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 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 two path computation methods for computing 40 inter-domain Traffic Engineering (TE) Multiprotocol Label Switching 41 (MPLS) and Generalized MPLS (GMPLS) Label Switched (LSP) paths. In this 42 document a domain is referred to as a collection of network elements 43 within a common sphere of address management or path computational 44 responsibility such as IGP areas and Autonomous Systems. 46 Vasseur, Ayyangar and Zhang 1 47 The first path computation method is also called per-domain path 48 computation whereby each entry boundary LSR is responsible for 49 computing the path to the next exit boundary LSR (where for instance a 50 boundary LSR is either an ARB or an ASBR) whereas in the second method 51 a Path Computation Element (PCE)is used to compute an end to end 52 partial or complete path across multiple domains. 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119 [RFC2119]. 60 Table of content 62 1 Terminology ---------------------------------------------------- 3 63 2 Introduction --------------------------------------------------- 4 64 3 General assumptions -------------------------------------------- 5 65 4. Scenario 1: Next-hop resolution during inter-domain TE LSP 66 setup (per-domain path computation) ------------------------------- 8 67 4.1. Path computation algorithm -------------------------------- 8 68 4.2. Example with an inter-area TE LSP ------------------------ 9 69 4.2.1. Case 1: T1 is a contiguous TE LSP-------------------------- 9 70 4.2.2. Case 2: T2 is a stitched or nested TE LSP ---------------- 10 71 4.3. Example with an inter-AS TE LSP -------------------------- 10 72 4.3.1. Case 1: T1 is a contiguous TE LSP ------------------------ 12 73 4.3.2. Case 2: T1 is a stitched or nested TE LSP ---------------- 13 74 5. Scenario 2: end to end shortest path computation --------- 13 75 5.1. Introduction and definition of an optimal path ----------- 13 76 5.2. Notion of PCE (Path Computation Element)------------------ 13 77 5.3. Dynamic PCE discovery ------------------------------------ 14 78 5.4. PCE selection -------------------------------------------- 14 79 5.5. LSR-PCE signaling protocol ------------------------------- 14 80 5.6. Dynamic computation of an optimal end to end TE LSP path � 14 81 5.7. Metric normalization ------------------------------------- 18 82 5.8. Diverse end to end path computation ---------------------- 18 83 6. Path optimality/diversity -------------------------------- 18 84 7. MPLS Traffic Engineering Fast Reroute for inter-domain TE 85 LSPs ------------------------------------------------------------- 19 86 7.1. Failure of an internal network element ------------------- 19 87 7.2. Failure of an inter-ASBR links (inter-AS TE) ------------- 19 88 7.3. Failure of an ABR or an ASBR node ------------------------ 19 89 8. Reoptimization of an inter-area/AS TE LSP ---------------- 19 90 8.1. Contiguous TE LSPs --------------------------------------- 19 91 8.1.1. Per-area/AS path computation (scenario 1) ---------------- 20 92 8.1.2. End to end shortest path computation (scenario 2)�-------- 21 93 8.2. Stitched or nested (non-contiguous) TE LSPs --------------- 21 94 9. Routing traffic onto inter-domain TE LSPs ----------------- 22 95 10. Security Considerations ----------------------------------- 22 96 11. Intellectual Property Considerations ---------------------- 22 97 12. Acknowledgments ----------------------------------------------- 23 99 Vasseur, Ayyangar and Zhang 2 100 1. Terminology 102 LSR: Label Switch Router 104 LSP: MPLS Label Switched Path 106 PCE: Path Computation Element. An LSR in charge of computing TE LSP 107 path for which it is not the Head-end. For instance, an ABR (inter- 108 area) or an ASBR (Inter-AS) can play the role of PCE. 110 PCC: Path Computation Client (any head-end LSR) requesting a path 111 computation from the Path Computation Element. 113 Local Repair: local protection techniques used to repair TE LSPs 114 quickly when a node or link along the LSPs path fails. 116 Protected LSP: an LSP is said to be protected at a given hop if it has 117 one or multiple associated backup tunnels originating at that hop. 119 Bypass Tunnel: an LSP that is used to protect a set of LSPs passing 120 over a common facility. 122 PLR: Point of Local Repair. The head-end of a bypass tunnel. 124 MP: Merge Point. The LSR where bypass tunnels meet the protected LSP. 126 NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A backup tunnel which 127 bypasses a single link of the protected LSP. 129 NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel which 130 bypasses a single node of the protected LSP. 132 Fast Reroutable LSP: any LSP for which the "Local protection desired" 133 bit is set in the Flag field of the SESSION_ATTRIBUTE object of its 134 Path messages or signaled with a FAST-REROUTE object. 136 CSPF: Constraint-based Shortest Path First. 138 Inter-AS MPLS TE LSP: A TE LSP whose head-end LSR and tail-end LSR do 139 not reside within the same Autonomous System (AS), or whose head-end 140 LSR and tail-end LSR are both in the same AS but the TE LSP�s path 141 may be across different ASes. Note that this definition also applies 142 to TE LSP whose Head-end and Tail-end LSRs reside in different sub-ASes 143 (BGP confederations). 145 Inter-area MPLS TE LSP: A TE LSP where the head-end LSR and tail-end 146 LSR do not reside in the same area or both the head-end and tail end 147 LSR reside in the same area but the TE LSP transits one or more 148 different areas along the path. 150 Vasseur, Ayyangar and Zhang 3 151 ABR Routers: routers used to connect two IGP areas (areas in OSPF or 152 L1/L2 in IS-IS) 154 Interconnect routers or ASBR routers: routers used to connect together 155 ASes of a different or the same Service Provider via one or more Inter- 156 AS links. 158 Boundary LSR: a boundary LSR is either an ABR in the context of inter- 159 area MPLS TE or an ASBR in the context of inter-AS MPLS TE. 161 TED: MPLS Traffic Engineering Database 163 The notion of contiguous, stitched and nested TE LSPs is defined in 164 {INTER-DOMAIN-SIG] and will not be repeated here. 166 2. Introduction 168 The requirements for inter-area and inter-AS MPLS Traffic Engineering 169 have been developed by the Traffic Engineering Working Group and have 170 been stated in [INTER-AREA-REQS] and [INTER-AS-REQS] respectively. The 171 framework for inter-domain MPLS Traffic Engineering has been provided 172 in [INTER-DOMAIN-FRAMEWORK]. 174 The set of mechanisms to establish and maintain inter-domain TE LSPs 175 has been specified in [INTER-DOMAIN-SIG]. 177 This document exclusively focuses on the path computation aspects and 178 defines two methods for computing inter-domain TE LSP paths. 180 Note that the mechanisms proposed in this document could also be 181 applicable to MPLS TE domains other than areas and ASes. 183 According to the wide set of requirements defined in [INTER-AS-TE-REQS] 184 and [INTER-AREA-TE-REQS], coming up with a single solution covering all 185 the requirements is certainly possible but may not be desired: indeed, 186 as described in [INTER-AS-TE-REQS] the spectrum of deployment scenarios 187 is quite large and designing a solution addressing the super-set of all 188 the requirements would lead to provide a rich set of mechanisms not 189 required in several cases. Depending on the deployment scenarios of a 190 SP, certain requirements stated above may be strict while certain other 191 requirements may be relaxed. 193 There are different ways in which inter-domain TE LSP path computation 194 may be performed. For example, if the requirement is to get an end-to- 195 end constraint-based shortest path across multiple domains, then a 196 mechanism using one or more distributed PCEs could be used to compute 197 the shortest path across different domains. Alternatively, one could 198 also use some static or discovery mechanisms to determine the next 199 boundary LSR per domain as the inter-domain TE LSP is being signaled. 200 Other offline mechanisms for path computation are not precluded either. 202 Vasseur, Ayyangar and Zhang 4 203 Depending on the Service Provider�s requirements, one may adopt either 204 of these techniques for inter-domain path computation. 206 Note that the adequate path computation method may be chosen based upon 207 the TE LSP characteristics and requirements. Thus, the two path 208 computation methods proposed in this document are not exclusive from 209 each other. 211 3. General assumptions 213 In the rest of this document, we make the following set of assumptions: 215 1) Assumptions common to inter-area and inter-AS TE: 217 - Each area or AS in all the examples below is assumed to be capable of 218 doing Traffic Engineering (i.e. running OSPF-TE or ISIS-TE and RSVP- 219 TE). An AS may itself be composed of several other sub-AS(es) (BGP 220 confederations) or areas/levels. 222 - The inter-area/AS LSPs are signaled using RSVP-TE ([RSVP-TE]). 224 - The path (ERO) for the inter-area/AS TE LSP traversing multiple 225 areas/ASes may be signaled as a set of (loose and/or strict) hops. The 226 hops may identify: 227 - The complete strict path end to end across different 228 areas/ASes 229 - The complete strict path in the source area/AS followed by 230 boundary LSRs (and domain identifiers, e.g. AS numbers) 231 - The complete list of boundary LSRs along the path 232 - The current boundary LSR and the LSP destination 234 In this case, the set of (loose or strict) hops can either be 235 statically configured on the Head-end LSR or dynamically computed. In 236 the former case, the resulting path is statically configured on the 237 Head-end LSR. In the latter case (dynamic computation), two methods are 238 specified in this document: 239 - A distributed path computation involving some PCEs (e.g 240 ABR/ASBR) resulting in an optimal end to end path across 241 multiple domains consisting of a set of strict and/or loose 242 hops, 243 - Some Auto-discovery mechanism based on BGP and/or IGP 244 information yielding the next-hop boundary LSR (ABR/ASBR) along 245 the path as the LSP is being signaled, along with crankback 246 mechanisms. 248 - Furthermore, the boundary LSRs are assumed to be capable of 249 performing local path computation for expansion of a loose next-hop in 250 the signaled ERO if the path is not signaled by the head-end LSR as a 251 set of strict hops or if the strict hop is an abstract node (e.g. an 252 AS). This can be done by performing a CSPF computation up to that next 253 loose hop as opposed to the TE LSP destination or by making use of some 255 Vasseur, Ayyangar and Zhang 5 256 PCEs. In any case, no topology or resource information needs to be 257 distributed between areas/ASes (as mandated per [INTER-AREA-REQS] and 258 [INTER-AS-REQS]), which is critical to preserve IGP/BGP scalability and 259 confidentiality in the case of TE LSPs spanning multiple routing 260 domains. 262 - The paths for the intra-area/AS FA-LSPs or LSP segments or for a 263 contiguous TE LSP within the area/AS, may be pre-configured or computed 264 dynamically based on the arriving inter-area/AS LSP setup request; 265 depending on the requirements of the transit area/AS. Note that this 266 capability is explicitly specified as a requirement in [INTER-AS-TE- 267 REQS]. When the paths for the FA-LSPs/LSP segments are pre-configured, 268 the constraints as well as other parameters like local protection 269 scheme for the intra-area/AS FA-LSP/LSP segment are also pre- 270 configured. 272 - While certain constraints like bandwidth can be used across different 273 areas/ASes, certain other TE constraints like resource affinity, color, 274 metric, etc. as listed in [RFC2702] could be translated at areas/ASes 275 boundaries. If required, it is assumed that, at the area/AS boundary 276 LSRs, there will exist some sort of local mapping based on offline 277 policy agreement, in order to translate such constraints across area/AS 278 boundaries. It is expected that such an assumption particularly applies 279 to inter-AS TE: for example, the local mapping would be similar to the 280 Inter-AS TE Agreement Enforcement Polices stated in [INTER-AS-TE-REQS]. 282 2) Example of topology for the inter-area TE case 284 The following example will be used for the inter-area TE case in this 285 document. 287 <--area1--><---area0---><----area2-----> 288 ------ABR1------------ABR�1------- 289 | / | | \ | 290 R0--X1 | | X2---X3--R1 291 | | | / | 292 -------ABR2-----------ABR�2------ 293 <=========== Inter-area TE LSP =======> 295 Assumptions 297 - ABR1, ABR2, ABR�1 and ABR�2 are ABRs, 298 - X1: an LSR in area 1, 299 - X2, X3: LSRs in area 2, 300 - An inter-area TE LSP T0 originated at R0 in area1 and terminating at 301 R1 in area2, 303 Notes: 304 - The terminology used in the example above corresponds to OSPF but the 305 path computation methods proposed in this document equally applies to 306 the case of an IS-IS multi-levels network. 308 Vasseur, Ayyangar and Zhang 6 309 - Just a few routers in each area are depicted in the diagram above for 310 the sake of simplicity. 312 3) Example of topology for the inter-AS TE case: 314 We will consider the following general case, built on a superset of the 315 various scenarios defined in [INTER-AS-TE-REQS]: 317 <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> 319 <---BGP---> <---BGP--> 320 CE1---R0---X1-ASBR1-----ASBR4�-R3---ASBR7-�--ASBR9----R6 321 |\ \ | / | / | / | | | 322 | \ ASBR2---/ ASBR5 | -- | | | 323 | \ | | |/ | | | 324 R1-R2�--ASBR3�----ASBR6�-R4---ASBR8�---ASBR10�--R7---CE2 326 <======= Inter-AS TE LSP(LSR to LSR)===========> 327 or 329 <======== Inter-AS TE LSP (CE to ASBR => 331 or 333 <================= Inter-AS TE LSP (CE to CE)===============> 335 The diagram above covers all the inter-AS TE deployment cases described 336 in [INTER-AS-TE-REQS]. 338 Assumptions: 340 - Three interconnected ASes, respectively AS1, AS2, and AS3. Note that 341 AS3 might be AS1 in some scenarios described in [INTER-AS-TE-REQS], 343 - The various ASBRs are BGP peers, without any IGP running on the 344 single hop links interconnecting the ASBRs and also referred to as 345 inter-ASBR links, 347 - Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE 348 extensions (see [OSPF-TE] and [IS-IS-TE]). In other words, the ASes are 349 TE enabled, 351 - Each AS can be made of several IGP areas. The path computation 352 techniques described in this document applies to the case of a single 353 AS made of multiple IGP areas, multiples ASes made of a single IGP 354 areas or any combination of the above. For the sake of simplicity, each 355 routing domain will be considered as single area in this document. 357 - An inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6 358 in AS3, 360 Vasseur, Ayyangar and Zhang 7 361 - In the example above, ASBR1, ASBR8 and ASBR9 could have the function 362 of PCE for the AS 1, 2 and 3 respectively (the notion of PCE applies to 363 the scenario 2 of this document). 365 4. Scenario 1: Next-hop resolution during inter-domain TE LSP set 366 up (per-domain path computation) 368 4.1. Path computation algorithm 370 Regardless of the nature of the inter-domain TE LSP (contiguous, 371 stitched or nested), a similar set of mechanisms for local TE LSP path 372 computation (next hop resolution) can be used. 374 When an ABR/ASBR receives a Path message with a loose next-hop or an 375 abstract node in the ERO, then it carries out the following actions: 377 1) It checks if the loose next-hop is accessible via the TED. If the 378 loose next-hop is not present in the TED, then it checks if the next- 379 hop at least has IP reachability (via IGP or BGP). If the next-hop is 380 not reachable, then the path computation stops and the LSR sends back a 381 PathErr upstream. If the next-hop is reachable, then it finds an 382 ABR/ASBR to get to the next-hop. In the absence of an auto-discovery 383 mechanism, the ABR in the case of inter-area TE or the ASBR in the 384 next-hop AS in the case of inter-AS TE should be the loose next-hop in 385 the ERO and hence should be accessible via the TED, otherwise the path 386 computation for the inter-area/AS TE LSP will fail. 388 2) If the next-hop boundary LSR is present in the TED. 390 a) Case of a contiguous TE LSP. The ABR/ASBR just performs an 391 ERO expansion (unless not allowed by policy) after having 392 computed the path to the next loose hop (ABR/ASBR) that obeys 393 the set of required constraints. If no path satisfying the set 394 of constraints can be found, the path computation stops and a 395 Path Error MUST be sent for the inter-area/AS TE LSP. 397 b) Case of stitched or nested LSP 399 i) if the ABR/ASBR (receiving the LSP setup request) is 400 a candidate LSR for intra-area FA-LSP/LSP segment 401 setup, and if there is no FA-LSP/LSP segment from this 402 LSR to the next-hop boundary LSR (satisfying the 403 constraints) it SHOULD signal a FA-LSP/LSP segment to 404 the next-hop boundary LSR. If pre-configured FA-LSP(s) 405 or LSP segment(s) already exist, then it SHOULD try to 406 select from among those intra-area/AS LSPs. Depending 407 on local policy, it MAY signal a new FA-LSP/LSP segment 408 if this selection fails. If the FA-LSP/LSP segment is 409 successfully signaled or selected, it propagates the 410 inter-area/AS Path message to the next-hop following 412 Vasseur, Ayyangar and Zhang 8 413 the procedures described in [LSP-HIER]. If, for some 414 reason the dynamic FA-LSP/LSP segment setup to the 415 next-hop boundary LSR fails, the path computation stops 416 and a PathErr is sent upstream for the inter-area/AS 417 LSP. Similarly, if selection of a preconfigured FA- 418 LSP/LSP segment fails and local policy prevents dynamic 419 FA-LSP/LSP segment setup, then the path computation 420 stops and a PathErr is sent upstream for the inter- 421 area/AS TE LSP. 423 ii) If, however, the boundary LSR is not a FA-LSP/LSP 424 segment candidate, then it SHOULD simply compute a CSPF 425 path up to the next-hop boundary LSR carry out an ERO 426 expansion to the next-hop boundary LSR) and propagate 427 the Path message downstream. The outgoing ERO is 428 modified after the ERO expansion to the loose next-hop. 430 Note that in both cases, path computation may be 431 stopped due to some local policy. 433 4.2. Example with an inter-area TE LSP 435 4.2.1. Case 1: T1 is a contiguous TE LSP 437 When the path message reaches ABR1, it first determines the egress LSR 438 from its area 0 along the LSP path (say ABR�1), either directly from 439 the ERO (if for example the next hop ABR is specified as a loose hop in 440 the ERO) or by using some constraint-aware auto-discovery mechanism. In 441 the former case, every inter-AS TE LSP path is defined as a set of 442 loose and strict hops but at least the ABRs traversed by the inter-area 443 TE LSP MUST be specified as loose hops on the head-End LSR. 445 - Example 1 (set of strict hops end to end): R0-X1-ABR1-ABR�1-X2-X3-R1 446 - Example 2 (set of loose hops): R0-ABR1(loose)-ABR�1(loose)-R1(loose) 447 - Example 3 (mix of strict and loose hops): R0-X1-ASBR1-ABR�1(loose)- 448 X2-X3-R1 450 At least, the set of ABRs from the TE LSP head-end to the tail-End MUST 451 be present in the ERO as a set of loose hops. Optionally, a set of 452 paths can be configured on the head-end LSR, ordered by priority. Each 453 priority path can be associated with a different set of constraints. 454 Typically, it might be desirable to systematically have a last resort 455 option with no constraint to ensure that the inter-area TE LSP could 456 always be set up if at least a path exists between the inter-area TE 457 LSP source and destination. Note that in case of set up failure or when 458 an RSVP Path Error is received indicating the TE LSP has suffered a 459 failure, an implementation might support the possibility to retry a 460 particular path option a specific amount of time (optionally with 461 dynamic intervals between each trial) before trying a lower priority 462 path option. Any path can be defined as a set of loose and strict hops. 464 Vasseur, Ayyangar and Zhang 9 465 In other words, in some cases, it might be desirable to rely on the 466 dynamic path computation in some area, and exert a strict control on 467 the path in other areas (defining strict hops). 469 Once it has computed the path up to the next ABR, ABR1 sends the Path 470 message for the inter-area TE LSP to ABR�1. ABR�1 then repeats the a 471 similar procedure and the Path message for the inter-area TE LSP will 472 reach the destination R1. If ABR�1 cannot find a path obeying the set 473 of constraints for the inter-area TE LSP, the path computation stops 474 and ABR�1 MUST send a PathErr message to ABR1. Then ABR1 can in turn 475 triggers a new computation by selecting another egress boundary LSR 476 (ABR�2 in the example above) if crankback is allowed for this inter- 477 area TE LSP (see [CRANBACK]). If crankback is not allowed for that 478 inter-area TE LSP or if ABR1 has been configured not to perform 479 crankback, then ABR1 MUST stop any path computation for the TE LSP and 480 MUST forward a PathErr up to the head-end LSR (R0) without trying to 481 select another egress LSR. 483 4.2.2. Case 2: T2 is a stitched or nested TE LSP 485 When the path message reaches ABR1, ABR1 first determines the egress 486 LSR from its area 0 along the LSP path (say ABR�1), either directly 487 from the ERO or by using some constraint-aware auto-discovery 488 mechanism. 490 ABR1 will check if it has a FA-LSP or LSP segment to ABR�1 matching the 491 constraints carried in the inter-area TE LSP Path message. If not, ABR1 492 will compute the path for a FA-LSP or LSP segment from ABR1 to ABR�1 493 satisfying the constraint and will set it up accordingly. Note that the 494 FA-LSP or LSP segment could have also been pre-configured. 496 Once the ABR has selected the FA-LSP/LSP segment for the inter-area 497 LSP, using the signaling procedures described in [LSP-HIER], ABR1 sends 498 the Path message for inter-area TE LSP to ABR�1. Note that irrespective 499 of whether ABR1 does nesting or stitching, the Path message for the 500 inter-area TE LSP is always forwarded to ABR�1. ABR�1 then repeats the 501 exact same procedures and the Path message for the inter-area TE LSP 502 will reach the destination R1. If ABR�1 cannot find a path obeying the 503 set of constraints for the inter-area TE LSP, then ABR�1 MUST send a 504 PathErr message to ABR1. Then ABR1 can in turn either select another 505 FA-LSP/LSP segment to ABR�1 if such an LSP exists or select another 506 egress boundary LSR (ABR�2 in the example above) if crankback is 507 allowed for this inter-area TE LSP (see [CRANBACK]). If crankback is 508 not allowed for that inter-area TE LSP or if ABR1 has been configured 509 not to perform crankback, then ABR1 MUST forward a PathErr up to the 510 inter-area head-end LSR (R0) without trying to select another egress 511 LSR. 513 4.3. Example with an inter-AS TE LSP 515 Vasseur, Ayyangar and Zhang 10 516 The procedures for establishing an inter-AS TE LSP are very similar to 517 those of an inter-area TE LSP described above. The main difference is 518 related to the presence of inter-ASBRs link(s). 520 The links interconnecting ASBRs are usually not TE enabled and no IGP 521 is running at the AS boundaries. An implementation supporting inter-AS 522 MPLS TE MUST obviously allow the set up of inter-AS TE LSP over the 523 region interconnecting multiple ASBRs. In other words, an ASBR 524 compliant with this document MUST support the set up of TE LSP over 525 ASBR to ASBR links, performing all the usual operations related to MPLS 526 Traffic Engineering (call admission control, �) as defined in [RSVP- 527 TE]. 529 In term of computation of an inter-AS TE LSP path, an interesting 530 optimization consists of allowing the ASBRs to flood the TE information 531 related to the inter-ASBR link(s) although no IGP TE is enabled over 532 those links (and so there is no IGP adjacency over the inter-ASBR 533 links). This of course implies for the inter-ASBR links to be TE- 534 enabled although no IGP is running on those links. This allows a head- 535 end LSR to make a more appropriate route selection up to the first ASBR 536 in the next hop AS in the case of scenario 1 and will significantly 537 reduce the number of signaling steps in route computation. This also 538 allows the entry ASBR in an AS to make a more appropriate route 539 selection up to the entry ASBR in the next hop AS taking into account 540 constraints associated with the ASBR-ASBR links. Moreover, this reduces 541 the risk of call set up failure due to inter-ASBR links not satisfying 542 the inter-AS TE LSP set of constraints. Note that the TE information is 543 only related to the inter-ASBR links: the TE LSA/LSP flooded by the 544 ASBR includes not only the TE-enabled links contained in the AS but 545 also the inter-ASBR links. 547 Note that no summarized TE information is leaked between ASes in any of 548 the proposed scenarios in this document which is compliant with the 549 requirements listed in [INTER-AREA-TE-REQS] and [INTER-AS-TE-REQS]. 551 Example: 553 <---BGP---> <---BGP--> 554 CE1---R0---X1-ASBR1-----ASBR4�-R3---ASBR7-�--ASBR9---R6 555 |\ \ | / | / | / | | | 556 | \ ASBR2---/ ASBR5 | -- | | | 557 | \ | | |/ | | | 558 R1-R2�--ASBR3�----ASBR6�-R4---ASBR8�---ASBR10---R7---CE2 560 For instance, in the diagram depicted above, when ASBR1 floods its IGP 561 TE LSA (opaque LSA for OSPF)/LSP (TLV 22 for IS-IS) in its routing 562 domain, it reflects the reservation states and TE properties of the 563 following links: X1-ASBR1, ASBR1-ASBR2 and ASBR1-ASBR4. 565 Thanks to such an optimization, the inter-ASBRs TE link information 566 corresponding to the links originated by the ASBR is made available in 568 Vasseur, Ayyangar and Zhang 11 569 the TED of other LSRs in the same area/AS that the ASBR belongs to. 570 Consequently, the CSPF computation for an inter-AS TE LSP path can also 571 take into account the inter-ASBR link(s). This will improve the chance 572 of successful path computation up to the next AS in case of a 573 bottleneck on some inter-ASBR links and it potentially reduces one 574 level of crankback. Note that no topology information is flooded and 575 these links are not used in IGP SPF computations. Only the TE 576 information for the links originated by the ASBR is advertised. 578 4.3.1. Case 1: T1 is a contiguous TE LSP 580 The inter-AS TE path may be configured on the head-end LSR as a set of 581 strict hops, loose hops or a combination of both. 583 - Example 1 (set of strict hops end to end): R0-X1-ASBR1-ASBR4-ASBR5- 584 R3-ASBR7-ASBR9-R6 585 - Example 2 (set of loose hops): R0-ASBR4(loose)-ASBR9(loose)-R6(loose) 586 - Example 3 (mix of strict and loose hops): R0-R2-ASBR3-ASBR2-ASBR1- 587 ASBR4(loose)-ASBR10(loose)-ASBR9-R6 589 When a next hop is a loose hop, a dynamic path calculation (also called 590 ERO expansion) is required taking into account the topology and TE 591 information of its own AS and the set of TE LSP constraints. In the 592 example 1 above, the inter-AS TE LSP path is statically configured as a 593 set of strict hops; thus, in this case, no dynamic computation is 594 required. Conversely, in the example 2, a per-AS path computation is 595 performed, respectively on R0 for AS1, ASBR4 for AS2 and ASBR9 for AS3. 596 Note that when an LSR has to perform an ERO expansion, the next hop 597 must either belong to the same AS, or must be the ASBR directly 598 connected to the next hops AS. In this later case, the ASBR 599 reachability MUST be announced in the IGP TE LSA/LSP originated by its 600 neighboring ASBR. Indeed, in the example 2 above, the TE LSP path is 601 defined as: R0-ASBR4(loose)-ASBR9(loose)-R6(loose). This implies that 602 R0 must compute the path from R0 to ASBR4, hence the need for R0 to get 603 the TE reservation state related to the ASBR1-ASBR4 link (flooded in 604 AS1 by ASBR1). In addition, ASBR1 MUST also announce the IP address of 605 ASBR4 specified in the T1 path configuration. 607 If an auto-discovery mechanism is available, every LSR receiving an 608 RSVP Path message, will have to determine automatically the next hop 609 ASBR, based on the IGP/BGP reachability of the TE LSP destination. With 610 such a scheme, the head-end LSR and every downstream ASBR loose hop 611 (except the last loose hop that computes the path to the final 612 destination) automatically computes the path up to the next ASBR, the 613 next loose hop based on the IGP/BGP reachability of the TE LSP 614 destination. If a particular destination is reachable via multiple 615 loose hops (ASBRs), local heuristics may be implemented by the head-end 616 LSR/ASBRs to select the next hop an ASBR among a list of possible 617 choices (closest exit point, metric advertised for the IP destination 618 (ex: OSPF LSA External - Type 2), local policy,...). Once the next ASBR 619 has been determined, an ERO expansion is performed as in the previous 621 Vasseur, Ayyangar and Zhang 12 622 case. 624 Once it has computed the path up to the next ASBR, ASBR1 sends the Path 625 message for the inter-area TE LSP to ASBR4 (supposing that ASBR4 is the 626 selected next hop ASBR). ASBR4 then repeats the exact same procedures 627 and the Path message for the inter-AS TE LSP will reach the destination 628 R1. If ASBR4 cannot find a path obeying the set of constraints for the 629 inter-AS TE LSP, then ASBR4 MUST send a PathErr message to ASBR1. Then 630 ASBR1 can in turn either select another ASBR (ASBR5 in the example 631 above) if crankback is allowed for this inter-AS TE LSP (see 632 [CRANBACK]). If crankback is not allowed for that inter-AS TE LSP or if 633 ASBR1 has been configured not to perform crankback, then ABR1 MUST stop 634 the path computation and MUST forward a PathErr up to the head-end LSR 635 (R0) without trying to select another egress LSR. In this case, the 636 head-end LSR can in turn select another sequence of loose hops, if 637 configured. Alternatively, the head-end LSR may decide to retry the 638 same path; this can be useful in case of set up failure due an outdated 639 IGP TE database in some downstream AS. An alternative could also be for 640 the head-end LSR to retry to same sequence of loose hops after having 641 relaxed some constraint(s). 643 4.3.2. Case 2: T1 is a stitched or nested TE LSP 645 The signaling procedures are very similar to the inter-area LSP setup 646 case described earlier. In this case, the FA-LSPs or LSP segments will 647 only be originated by the ASBRs at the entry to the AS. 649 5. Scenario 2: end to end shortest path computation 651 5.1. Introduction and definition of an optimal path 653 Qualifying a path as optimal requires some clarification. Indeed, a 654 globally optimal TE LSP placement usually refers to a set of TE LSP 655 whose placements optimize the network resources (i.e a placement that 656 reduces the maximum or average network load for instance). In this 657 document, an optimal inter-domain TE LSP path is defined as the 658 shortest path satisfying the set of required constraints path that 659 would be obtained in the absence of AS/Areas, in a totally flat network 660 between the source and destination of the TE LSP. 662 5.2. Notion of PCE (Path Computation Element) 664 An LSR is said to be a PCE (Path Computation Element) when it has the 665 ability to compute an inter-domain TE LSP path for a TE LSP it is not 666 the head-end of. Ideal candidates to support a PCE function are ABRs in 667 the context of inter-area TE (since each ABR has the view of two of 668 more areas in its TED) and ASBR in the context of inter-AS TE. Note 669 that in this document an LSR supporting the function of PCE is simply 670 referred to as a PCE. As in the case of intra-area TE, no assumption is 671 made on the actual path computation algorithm in use by the PCE (it can 673 Vasseur, Ayyangar and Zhang 13 674 be any variant of CSPF, algorithm based on linear-programming to solve 675 multi-constraints optimization problems and so on). 677 5.3. Dynamic PCE discovery 679 PCE(s) can either be statically configured on each LSR requesting an 680 inter-domain TE LSP path computation or dynamically discovered by means 681 of IGP extensions defined in [OSPF-CAP], [OSPF-TE-CAP], [ISIS-CAP] and 682 [ISIS-TE-CAP]. This allows an Operator to elect a subset of ABRs/ASBRs 683 to act as PCEs. 685 Note that if the domain is made of multiple areas/levels, [OSPF-CAP] 686 and [ISIS-CAP] support the capabilities announcements across the entire 687 routing domain (making use of TLV leaking procedure for IS-IS and OSPF 688 opaque LSA type 11 for OSPF). 690 5.4. PCE selection 692 It belongs to an LSR informed of the existence of multiple PCEs having 693 the capability to serve an inter-domain TE LSP path computation request 694 to select the preferred PCE. For instance, an LSR may select the 695 closest PCE based on the IGP metric or may just randomly select one of 696 the PCE. In case of multiple PCEs, the PCE selection process SHOULD be 697 such that the requests are balanced across multiple PCEs. In addition, 698 an LSR MUST be able to select another PCE if its preferred PCE does not 699 respond to its request after some configurable and potentially 700 dynamically computed amount of time (e.g. using some back-off 701 algorithm). Note that the PCE may or may not be along the TE LSP Path. 702 This implies that the PCE is just responsible for the TE LSP path 703 computation, not for its maintenance. Moreover, the PCE may compute 704 just a path segment, not the whole path end to end; in this case, the 705 returned computed path will contain loose hops so as to preserve 706 confidentiality across domain for instance. 708 5.5. LSR-PCE signaling protocol 710 The use of a PCE-based path computation method requires some signaling 711 protocol between the requesting LSR and the PCE so as: 712 - For the requesting LSR (also referred to as PCC) to send a path 713 computation request 714 - For the PCE to return the computed path by means of a path 715 computation reply 717 Such a signaling protocol has been defined in [PATH-COMP] as well as a 718 set of optional objects characterizing the constraints. 720 The protocol state machine is also defined in [PATH-COMP]. 722 5.6. Dynamic computation of an optimal end to end TE LSP path 724 Vasseur, Ayyangar and Zhang 14 725 This section specifies a PCE-based mechanism allowing for the 726 computation of an optimal (shortest) inter-domain TE LSP path obeying a 727 set of specified constraints. 729 Each step of the mechanism is illustrated by means of an inter-AS TE 730 LSP path computation example: the shortest path of an inter-AS TE LSP 731 T1 from R0 in AS1 to R6 in AS3. The case of inter-area TE LSP optimal 732 path computation is very similar. 734 Elements of procedure 736 1) Step 1: discovery by the head-end LSR of a PCE capable of serving 737 its path computation request. The PCE will either be an ABR (inter-area 738 TE) or an ASBR (Inter-AS TE). In the case of inter-AS TE, the PCE must 739 be able to serve the source AS and can compute inter-AS TE LSP path 740 terminating in the destination ASn. As mentioned above, the PCE can 741 either be statically configured or dynamically discovered via IGP 742 extensions. If multiple PCEs are discovered, the head-end LSR selects 743 one PCE based on some local policies/heuristics. 745 Ex: R1 selects ASBR1 as the PCE serving its request for the T1 path 746 computation. 748 2) Step 2: a Path computation request is sent to the selected PCE. 750 Case of inter-area MPLS TE: the head-end LSR sends its path computation 751 requests to the selected PCE (ABR). 753 Case of inter-AS MPLS TE: the path computation request can be sent 754 either (1) to a PCE in the same AS which will in turn relay the request 755 to a PCE of the next hop AS (Ex: R0 sends an RSVP path computation 756 request to ASBR1 which relays the request to say ASBR4) or (2) to the 757 PCE in the next hop AS if the head-end LSR has a complete topology and 758 TE view up to the next hop PCE (Ex: R0 sends an RSVP path computation 759 request to ASBR4). It is expected that (1) will be the most common 760 inter-AS TE deployment scenario for security issues. 762 Note that it may be desirable to set up some policies on the PCE to 763 limit the access to specific LSRs. Moreover, authentication process may 764 be required when sending a path computation request to a PCE (usual 765 RSVP authentication can be used in the case of [PATH-COMP]). 767 Step i: the PCE of ASi relays the path computation request to the 768 selected PCE peer in AS(i+1) located in the next hop AS. Note that the 769 address of the list of PCE(es) in the next hop AS must be statically 770 configured on the PCE. This only implies some static configuration on 771 the PCE. 773 Ex: ASBR1 relays the path computation request to ASBR4 in AS2. 775 Vasseur, Ayyangar and Zhang 15 776 If the TE LSP destination is in AS(i+1), then the PCE provides the list 777 of shortest paths (with their corresponding ERO (potentially partial 778 ERO) + Path-cost) from every ASBR to the TE LSP destination. A detailed 779 example is provided below. 781 If the TE LSP destination is not in AS(i+1), the PCE relays the path 782 computation request to the targeted PCE peer in AS(i+2) in the next hop 783 AS. 785 The process is iterated until the destination AS is reached. 787 Ex: ASBR4 relays the path computation request to ASBR9 which determines 788 that T1�s destination address belongs to its locally attached AS (AS3). 789 ASBR9 then returns a path computation reply to the requesting PCE 790 (ASBR4). The path computation reply contains two paths (provided that 791 two paths obeying the set of constraints exist): 792 - ERO 1: ASBR9-R6, Cost=c1, 793 - ERO 2: ASBR10-R7-R6, Cost=c2 794 Note that the ERO object might be made of loose hop to preserve 795 confidentiality. 797 Step 3: once a requesting PCEi receives a Path computation reply, the 798 shortest path is computed from ASi to ASi+1 by route concatenation. 799 This is done by computing a virtual SPT (Shortest Path Tree) rooted at 800 the TE LSP destination (using for instance a CSPF-based algorithm) 801 where the nodes are the ABSRs connected by virtual links whose costs 802 are equal to the shortest path connecting the ASBRs. 804 <---BGP---> <---BGP--> 805 CE1---R0---X1-ASBR1-----ASBR4�-R3---ASBR7-�--ASBR9---R6 806 |\ \ | / | / | / | | | 807 | \ ASBR2---/ ASBR5 | -- | | | 808 | \ | | |/ | | | 809 R1-R2�--ASBR3�----ASBR6�-R4---ASBR8�---ASBR10---R7---CE2 811 Resulting Virtual SPT computed by ASBR 4 813 ASBR4---ASBR7---ASBR9---R6 814 | | \ / /| \ / | / 815 | | \ / | \/ | / 816 | | / \/ | /\ | / 817 | | / /\ | / \ | / 818 |ASBR5--ASBR8---ASBR10 819 | | / / 820 | | / / 821 | | / / 822 | |/ / 823 ASBR6 825 First, we define a ASBR-ASBR virtual link as the shortest path within a 826 particular AS satisfying the TE LSP constraints. 828 Vasseur, Ayyangar and Zhang 16 829 Within ASi, the cost of each ASBR-ASBR virtual link is equal to the 830 shortest path cost satisfying the TE LSP constraints. This information 831 is computed by PCEi. 833 As described earlier, the cost of the inter-ASBR links between ASi and 834 AS(i+1) is also known by the PCEi by means of the IGP-extensions. 836 Within ASi+1, the cost of the ASBR-ASBR virtual link(s) is provided in 837 the path computation reply from the PCEi+1. 839 Ex: ASBR4 computes the shortest path for the TE LSP traversing AS2 and 840 AS3 and returns the following virtual SPT (along with the path costs) 841 to ASBR1: 843 ASBR4---R6 844 / 845 / 846 ASBR6 848 Then the process is reiterated recursively until the optimal (shortest) 849 end-to-end Path computation is computed. The whole path may not be seen 850 by each PCE for confidentiality reason. This process guarantees that 851 the shortest path is computed. 853 Example: the resulting virtual SPT computed by ASBR1 will finally be: 855 R0-----ASBR1-----ASBR4----R6 856 | \ | |\ \ / /|| / | 857 | \ | | \ \ / || / | 858 | \ | | / \/ || / | 859 | \ | | / \/\ ||/ | 860 | \-|-ASBR2�ASBR5 | 861 | | |\ /\/ || | 862 | | | \/ /\ || | 863 | | | /\/ \ || | 864 | | |/ /\ \|| | 865 --------|-ASBR3-�ASBR6-----| 867 Then once the optimal end to end path is computed and returned to the 868 Head-end, it signals the inter-domain TE LSP using a complete list of 869 ERO if the various PCEs have provided the list of ERO or some loose 870 hops otherwise. 872 An implementation MAY decide to support local caching of path 873 computation in order to optimize the path computation process. The 874 downside of path caching is the potential increase of call set up 875 failure. When caching is in use, it must be flushed upon TE LSP set up 876 failure provided that the PCE is along the inter-area/AS TE LSP path. 878 Vasseur, Ayyangar and Zhang 17 879 By contrast with scenario 1, an end-to-end shortest path obeying the 880 set of required constraint is computed. In that sense, the path is 881 optimal. 883 Some other variants of such an algorithm relying on the same principles 884 are also possible. 886 Note also that in case of ECMP paths, more than one path could be 887 returned to the requesting LSR. 889 5.7. Metric normalization 891 In the case of inter-area TE, the same IGP/TE metric scheme is usually 892 adopted for all the areas (e.g. based on the link-speed, propagation 893 delay or some other combination of constraints). Hence, the proposed 894 set of mechanism always computes the shortest path across multiple 895 areas obeying the required set of constraints. In the case of Inter-AS 896 TE, in order for this path computation to be meaningful, a metric 897 normalization between ASes is required. One solution to avoid IGP 898 metric modification would be for the SPs to agree on a TE metric 899 normalization and use the TE metric for TE LSP path computation (in 900 that case, this must be requested in the Path computation request via 901 the METRIC-COST object in the case of [PATH-COMP]). 903 5.8. Diverse end to end path computation 905 The RSVP signaling protocol defined in [PATH-COMP] allows an LSR to 906 request the computation of a set of N diversely routed TE LSPs. Then in 907 this scenario, a set of diversely routed TE LSP between two LSRs can be 908 computed since both paths are simultaneously computed. Such a PCE-based 909 path computation method allows for the computation of diverse paths 910 under various objective functions (such as minimizing the sum of the 911 costs of the N diverse paths, etc) in a very efficient manner (avoiding 912 the well-known �trapping� problem whereby a sequential placement of the 913 two TE LSPs may lead to the inability to find a path for the second TE 914 LSP due to the placement of the first TE LSP) both in terms of 915 objective function and number of passes required to compute those 916 paths. 918 6. Path optimality/diversity 920 In the case of scenario, since the inter-domain path is computed on a 921 per domain (area, AS) basis, one cannot guarantee that the shortest 922 inter-domain path can be found. Conversely, scenario 2 guarantees that 923 the shortest inter-domain path will always be computed. 924 Moreover, computing two diverse paths might not be possible with 925 scenario 1 in some topologies (due to the well-known �trapping� 926 problem) whereas such a limitation does not exist with scenario 2 since 927 both paths are dynamically and simultaneously computed. 929 Vasseur, Ayyangar and Zhang 18 930 As already pointed out, the required path computation method can be 931 selected by the Operator on a per LSP basis. 933 7. MPLS Traffic Engineering Fast Reroute for inter-domain TE LSPs 935 The signaling aspects of Fast Reroute and related constraints for each 936 TE LSP types in the case of inter-domain TE LSP has been covered in 937 [INTER-DOMAIN-SIG] and will not be repeated in this document. 939 There are multiple failure scenarios to consider in the case of Fast 940 Reroute for inter-domain TE LSPs. 942 7.1. Failure of an internal network element 944 The case of a failure of a network element within an area/AS such as a 945 link, SRLG or a node does not differ from Fast Reroute for intra-domain 946 TE LSP. 948 7.2. Failure of an inter-ASBR links (inter-AS TE) 950 In order to protect inter-domain TE LSPs from the failure of an inter- 951 ASBR link, this requires the computation of a backup tunnel path that 952 crosses an non IGP TE-enabled region (between two ASes). In both 953 scenario 1 and 2, if the inter-ASBR TE related information is flooded 954 in the IGPs, each ASBR is capable of computing the path according to 955 the backup tunnel constraints. Otherwise, the backup tunnel path MUST 956 be statically configured. 958 7.3. Failure of an ABR or an ASBR node 960 The constraints to be taken into account during the backup tunnel path 961 computation significantly differs upon the TE LSP type, network element 962 to protect (entry/exit boundary node) and the Fast Reroute method in 963 use (facility backup versus one-to-one). Those constraints have been 964 explored in detail in [INTER-DOMAIN-SIG] but since the backup tunnel is 965 itself an inter-domain TE LSP, its path computation can be performed 966 according to the two path computation methods described in this 967 document. 969 8. Reoptimization of an inter-area/AS TE LSP 971 The ability to reoptimize an existing inter-area/AS TE LSP path is of 972 course a requirement. The reoptimization process significantly differs 973 based upon the nature of the TE LSP and the mechanism in use for the TE 974 LSP path computation. 976 If the head-end LSR uses a dynamic and distributed path computation 977 technique such as the PCE-based path computation (described in section 978 6), then the head-end LSR can leverage this to send re-optimization 979 requests to the PCE to obtain an optimal end-to-end path. On the other 980 hand, in the absence of such a mechanism, the following mechanisms can 982 Vasseur, Ayyangar and Zhang 19 983 be used for re-optimization, which are dependent on the nature of the 984 inter-area/AS TE LSP. 986 8.1. Contiguous TE LSPs 988 8.1.1. Per-area/AS path computation (scenario 1) 990 After an inter-AS TE LSP has been set up, a more optimal route might 991 appear in the various traversed ASes. Then in this case, it is 992 desirable to get the ability to reroute an inter-AS TE LSP in a non- 993 disruptive fashion (making use of the so called Make Before Break 994 procedure) to follow this more optimal path. This is a known as a TE 995 LSP reoptimization procedure. 997 [LOOSE-REOPT] proposes a mechanisms allowing: 999 - The head-end LSR to trigger on every LSR whose next hop is a 1000 loose hop the re evaluation of the current path in order to 1001 detect a potentially more optimal path. This is done via 1002 explicit signaling request: the head-end LSR sets the �ERO 1003 Expansion request� bit of the SESSION-ATTRIBUTE object carried 1004 in the RSVP Path message. 1006 - An LSR whose next hop is a loose-hop to signal to the head- 1007 end LSR that a better path exists. This is performed by sending 1008 an RSVP Path Error Notify message (ERROR-CODE = 25), sub-code 6 1009 (Better path exists). 1011 This indication may be sent either: 1013 - In response to a query sent by the head-end LSR, 1014 - Spontaneously by any LSR having detected a more 1015 optimal path 1017 Such a mechanism allows for the reoptimization of a TE LSP if and only 1018 if a better path is some downstream area/AS is detected. 1020 The reoptimization event can either be timer or event-driven based (a 1021 link UP event for instance). 1023 Note that the reoptimization MUST always be performed in a non- 1024 disruptive fashion. 1026 Once the head-end LSR is informed of the existence of a more optimal 1027 path either in its head-end area/AS or in another AS, the inter-AS TE 1028 Path computation is triggered using the same set of mechanisms as when 1029 the TE LSP is first set up (per-AS path computation as in scenario 1 or 1030 involving some PCE(s) in scenario 2). Then the inter-AS TE LSP is set 1031 up following the more optimal path, making use of the make before break 1032 procedure. In case of a contiguous LSP, the reoptimization process is 1033 strictly controlled by the head-end LSR which triggers the make-before- 1035 Vasseur, Ayyangar and Zhang 20 1036 break procedure, regardless of the location where the more optimal path 1037 is. 1039 8.1.2. End to end shortest path computation (scenario 2) 1041 [PATH-COMP] provides the ability to request a path reoptimization. In 1042 order to avoid double bandwidth accounting which could result in 1043 falsely triggered call set up failure the requesting LSR just provides 1044 the current path of the inter-area/AS TE LSP path to be reoptimized. 1046 Note that in the case of loose hop reoptimization, the TE LSP may 1047 follow a preferable path within one or more domain(s) whereas in the 1048 PCE-based reoptimization process, since a shortest end to end path is 1049 computed this may lead to following a completely different inter-domain 1050 path (including a different set of ABRs/ASBRs). 1052 8.2. Stitched or nested (non-contiguous) TE LSPs 1054 In the case of a stitched or nested inter-domain TE LSP, the re- 1055 optimization process is treated as a local matter to any Area/AS. The 1056 main reason is that the inter-domain TE LSP is a different LSP (and 1057 therefore different RSVP session) from the intra-domain LSP segment or 1058 FA-LSP in an area or an AS. Therefore, reoptimization in an area/AS is 1059 done by locally reoptimizing the intra-domain LSP segment. Since the 1060 inter-domain TE LSPs are transported using LSP segments or FA-LSP 1061 across each domain, optimality of the inter-domain TE LSP in an area/AS 1062 is dependent on the optimality of the corresponding LSP segments or FA- 1063 LSPs. If, after an inter-domain LSP is setup, a more optimal path is 1064 available within an area/AS, the corresponding LSP segment(s) or FA-LSP 1065 will be re-optimized using "make-before-break" techniques discussed in 1066 [RSVP-TE]. Reoptimization of the LSP segment automatically reoptimizes 1067 the inter-domain TE LSPs that the LSP segment transports. 1068 Reoptimization parameters like frequency of reoptimization, criteria 1069 for reoptimization like metric or bandwidth availability; etc can vary 1070 from one area/AS to another and can be configured as required, per 1071 intra-area/AS TE LSP segment or FA-LSP if it is preconfigured or based 1072 on some global policy within the area/AS. 1074 Hence, in this scheme, since each area/AS takes care of reoptimizing 1075 its own LSP segments or FA-LSPs, and therefore the corresponding inter- 1076 domain TE LSPs, the make-before-break can happen locally and is not 1077 triggered by the head-end LSR for the inter-area/AS LSP. So, no 1078 additional RSVP signaling is required for LSP re-optimization and 1079 reoptimization is transparent to the HE LSR of the inter-area/AS TE 1080 LSP. 1082 If, however, an operator desires to manually trigger reoptimization at 1083 the head-end LSR for the inter-domain TE LSP, then this solution does 1084 not prevent that. A manual trigger for reoptimization at the head-end 1085 LSR SHOULD force a reoptimization thereby signaling a "new" path for 1086 the same LSP (along the optimal path) making use of the make-before- 1088 Vasseur, Ayyangar and Zhang 21 1089 break procedure. In response to this new setup request, the boundary 1090 LSR may either initiate new LSP segment setup, in case the inter- 1091 area/AS TE LSP is being stitched to the intra-area/AS LSP segment or it 1092 may select an existing FA-LSP in case of nesting. When the LSP setup 1093 along the current optimal path is complete, the head end should 1094 switchover the traffic onto that path and the old path is eventually 1095 torn down. Note that the head-end LSR does not know a priori whether a 1096 more optimal path exists. Such a manual trigger from the head-end LSR 1097 of the inter-area/AS TE LSP is, however, not considered to be a 1098 frequent occurrence. 1100 Note that because stitching or nesting rely on local optimization, the 1101 reoptimization process allows to locally reoptimize each TE LSP segment 1102 or FA-LSP: hence, the reoptimization is not global and cannot guarantee 1103 that the optimal path end to end is found. 1105 9. Routing traffic onto inter-domain TE LSPs 1107 Once an inter-domain TE LSP has been set up, the head-end LSR has to 1108 determine the set of traffic to be routed onto the TE LSP. 1110 In the case of an intra-domain TE LSP, various options are available: 1112 (1) Modify the IGP SPF such that shortest path calculation can 1113 be performed taking into account existing TE LSP, with some 1114 path preference, 1116 (2) Make use of static routing. Note that the recursive route 1117 resolution of BGP allows routing any traffic to a particular 1118 (MP)BGP peer making use of a unique static route pointing the 1119 BGP peer address to the TE LSP. So any routes advertised by the 1120 BGP peer (IPv4/VPNv4 routes) will be reached using the TE LSP. 1122 With an inter-domain TE LSP, just the mode (2) is available, as the TE 1123 LSP head-end does not have any topology information related to the 1124 destination area/AS. 1126 10. Security Considerations 1128 When signaling an inter-AS TE, an Operator may make use of the already 1129 defined security features related to RSVP (authentication). This may 1130 require some coordination between SPs to share the keys (see RFC 2747 1131 and RFC 3097). 1133 11. Intellectual Property Considerations 1135 The IETF takes no position regarding the validity or scope of any 1136 Intellectual Property Rights or other rights that might be claimed to 1137 pertain to the implementation or use of the technology described in 1138 this document or the extent to which any license under such rights 1139 might or might not be available; nor does it represent that it has 1141 Vasseur, Ayyangar and Zhang 22 1142 made any independent effort to identify any such rights. Information 1143 on the procedures with respect to rights in RFC documents can be 1144 found in BCP 78 and BCP 79. 1146 Copies of IPR disclosures made to the IETF Secretariat and any 1147 assurances of licenses to be made available, or the result of an 1148 attempt made to obtain a general license or permission for the use of 1149 such proprietary rights by implementers or users of this 1150 specification can be obtained from the IETF on-line IPR repository at 1151 http://www.ietf.org/ipr. 1153 The IETF invites any interested party to bring to its attention any 1154 copyrights, patents or patent applications, or other proprietary 1155 rights that may cover technology that may be required to implement 1156 this standard. Please address the information to the IETF at ietf- 1157 ipr@ietf.org.. 1159 IPR Disclosure Acknowledgement 1161 By submitting this Internet-Draft, I certify that any applicable 1162 patent or other IPR claims of which I am aware have been disclosed, 1163 and any of which I become aware will be disclosed, in accordance with 1164 RFC 3668. 1166 12. Acknowledgments 1168 We would like to acknowledge input and helpful comments from Adrian 1169 Farrel. 1171 Normative References 1173 [RFC] Bradner, S., "Key words for use in RFCs to indicate requirements 1174 levels", RFC 2119, March 1997. 1176 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 1177 3667, February 2004. 1179 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 1180 Technology", BCP 79, RFC 3668, February 2004. 1182 [RSVP] Braden, et al, " Resource ReSerVation Protocol (RSVP) � Version 1183 1, Functional Specification�, RFC 2205, September 1997. 1185 [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 1186 3209, December 2001. 1188 [REFRESH-REDUCTION] Berger et al, �RSVP Refresh Overhead Reduction 1189 Extensions�, RFC2961, April 2001. 1191 Vasseur, Ayyangar and Zhang 23 1192 [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for 1193 LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, December 1194 2003. 1196 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 1197 Extensions to OSPF Version 2", RFC 3630, September 2003. 1199 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", 1200 RFC 3784, June 2004. 1202 Informative references 1204 [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, 1205 J.P., "Extensions to OSPF for advertising Optional Router 1206 Capabilities", draft-ietf-ospf-cap-03.txt, work in progress. 1208 [OSPF-TE-CAP] Vasseur, J.P., Psenak, P., Yasukawa, S., "OSPF MPLS 1209 Traffic Engineering Capabilities", draft-vasseur-ospf-te-caps-00.txt, 1210 work in progress. 1212 [ISIS-CAP] Vasseur, J.P., Aggarwal, R., Shen, N., "IS-IS extensions for 1213 advertising router information", draft-vasseur-isis-caps-02.txt, work 1214 in progress. 1216 [ISIS-TE-CAP] Vasseur, J.P, Previdi, S., Mabey, P., Le Roux, J.L., "IS- 1217 IS MPLS Traffic Engineering Capabilities", draft-vasseur-isis-te-caps- 1218 00.txt, work in progress. 1220 [IGP-TE-CAP] Vasseur JP, Le Roux et al. �Routing extensions for 1221 discovery of TE router information�, draft-vasseur-ccamp-te-router- 1222 info-00.txt, work in progress. 1224 [INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J., "Requirements 1225 for inter-area MPLS Traffic Engineering", draft-ietf-tewg-interarea- 1226 mpls-te-req-02.txt, work in progress. 1228 [INT-AS-REQ] Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic 1229 Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req-07.txt, 1230 work in progress. 1232 [INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A Framework 1233 for Inter-Domain MPLS Traffic Engineering", draft-farrel-ccamp-inter- 1234 domain-framework-01.txt, work in progress. 1236 [FACILITY-BACKUP] Le Roux, J.L., Vasseur, J.P. et al. "Framework for 1237 PCE based MPLS Facility Backup Path Computation", draft-leroux-pce- 1238 backup-comp-frwk-00.txt, work in progress 1240 [INTER-DOMAIN-SIG] Ayyangar, A., Vasseur, JP. �Inter-domain MPLS 1241 Traffic Engineering � RSVP extensions�, draft-ayyangar-ccamp-inter- 1242 domain-rsvp-te, work in progress. 1244 Vasseur, Ayyangar and Zhang 24 1245 [PATH-COMP] Vasseur et al, �RSVP Path computation request and reply 1246 messages�, draft-vasseur-mpls-computation-rsvp-05.txt, work in 1247 progress. 1249 [RSVP-CONSTRAINTS] Kompella, K., "Carrying Constraints in RSVP", 1250 work in progress. 1252 [LSP-ATTRIBUTE] Farrel A. et al, "Encoding of Attributes for 1253 Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) 1254 Establishment Using RSVP-TE", (work in progress). 1256 [GMPLS-OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay 1257 Model", (work in progress). 1259 [EXCLUDE-ROUTE] Lee et all, Exclude Routes - Extension to RSVP-TE, 1260 draft-ietf-ccamp-rsvp-te-exclude-route-00.txt, work in progress. 1262 [INTER-AREA-TE] Kompella et all,�Multi-area MPLS Traffic Engineering�, 1263 draft-kompella-mpls-multiarea-te-04.txt, work in progress. 1265 [LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D.,Swallow, G., 1266 Wadhwa, S., Bonica, R., " Detecting Data Plane Liveliness in MPLS", 1267 Internet Draft , October 2002. (Work 1268 in Progress) 1270 [MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS 1271 Networks", RFC 3443 Updates RFC 3032) ", January 2003 1273 [LOOSE-PATH-REOPT] Vasseur, Ikejiri and Zhang �Reoptimization of an 1274 explicit loosely routed MPLS TE paths�, draft-vasseur-ccamp-loose-path- 1275 reopt-02.txt, July 2004, Work in Progress. 1277 [NODE-ID] Vasseur, Ali and Sivabalan, �Definition of an RRO node-id 1278 subobject�, draft-ietf-mpls-nodeid-subobject-02.txt, work in progress. 1280 [LSP-HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized 1281 MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, March 2002. 1283 [MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS 1284 Networks", RFC 3443 (Updates RFC 3032) ", January 2003. 1286 Authors' Address: 1288 Jean-Philippe Vasseur (Editor) 1289 Cisco Systems, Inc. 1290 300 Beaver Brook Road 1291 Boxborough , MA - 01719 1292 USA 1293 Email: jpv@cisco.com 1295 Vasseur, Ayyangar and Zhang 25 1296 Arthi Ayyangar (Editor) 1297 Juniper Networks, Inc 1298 1194 N.Mathilda Ave 1299 Sunnyvale, CA 94089 1300 USA 1301 e-mail: arthi@juniper.net 1303 Raymond Zhang 1304 Infonet Services Corporation 1305 2160 E. Grand Ave. 1306 El Segundo, CA 90025 1307 USA 1308 Email: raymond_zhang@infonet.com 1310 Full Copyright Statement 1312 Copyright (C) The Internet Society (2004). This document is subject to 1313 the rights, licenses and restrictions contained in BCP 78, and except 1314 as set forth therein, the authors retain all their rights. 1316 This document and the information contained herein are provided on an 1317 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1318 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1319 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1320 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1321 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1322 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1324 Vasseur, Ayyangar and Zhang 26