idnits 2.17.1 draft-vasseur-ccamp-inter-domain-pd-path-comp-00.txt: -(483): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(491): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(493): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(939): 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 852. -- Found old boilerplate from RFC 3978, Section 5.5 on line 983. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 832. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 839. ** 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. 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 40 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 1181 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 == Line 215 has weird spacing: '... domain in al...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2005) is 7000 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) == Missing Reference: 'RFC2119' is mentioned on line 61, but not defined == Missing Reference: 'INTER-AREA-REQS' is mentioned on line 253, but not defined == Missing Reference: 'INTER-AS-REQS' is mentioned on line 254, but not defined == Missing Reference: 'INTER-DOMAIN-FRAMEWORK' is mentioned on line 163, but not defined == Missing Reference: 'INTER-AS-TE-REQS' is mentioned on line 541, but not defined == Missing Reference: 'INTER-AREA-TE-REQS' is mentioned on line 540, 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 624, but not defined == Missing Reference: 'LOOSE-REOPT' is mentioned on line 810, but not defined == Unused Reference: 'RFC' is defined on line 863, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 866, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 869, but no explicit reference was found in the text == Unused Reference: 'RSVP' is defined on line 873, but no explicit reference was found in the text == Unused Reference: 'REFRESH-REDUCTION' is defined on line 879, but no explicit reference was found in the text == Unused Reference: 'FAST-REROUTE' is defined on line 882, but no explicit reference was found in the text == Unused Reference: 'ISIS-TE' is defined on line 889, but no explicit reference was found in the text == Unused Reference: 'INT-AREA-REQ' is defined on line 894, but no explicit reference was found in the text == Unused Reference: 'INT-AS-REQ' is defined on line 898, but no explicit reference was found in the text == Unused Reference: 'INT-DOMAIN-FRWK' is defined on line 902, but no explicit reference was found in the text == Unused Reference: 'FACILITY-BACKUP' is defined on line 906, but no explicit reference was found in the text == Unused Reference: 'LSP-ATTRIBUTE' is defined on line 914, but no explicit reference was found in the text == Unused Reference: 'GMPLS-OVERLAY' is defined on line 919, but no explicit reference was found in the text == Unused Reference: 'EXCLUDE-ROUTE' is defined on line 922, but no explicit reference was found in the text == Unused Reference: 'LSPPING' is defined on line 926, but no explicit reference was found in the text == Unused Reference: 'MPLS-TTL' is defined on line 944, but no explicit reference was found in the text == Unused Reference: 'LOOSE-PATH-REOPT' is defined on line 934, but no explicit reference was found in the text == Unused Reference: 'NODE-ID' is defined on line 938, 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 (-06) exists of draft-ietf-ccamp-inter-domain-framework-00 == Outdated reference: A later version (-05) exists of draft-ietf-mpls-rsvpte-attributes-04 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-rsvp-te-exclude-route-00 == Outdated reference: A later version (-02) exists of draft-ietf-ccamp-loose-path-reopt-01 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-nodeid-subobject-03 Summary: 14 errors (**), 0 flaws (~~), 39 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group JP Vasseur (Editor) 3 IETF Internet draft Cisco Systems, Inc. 4 Proposed Status: Standard Arthi Ayyangar (Editor) 5 Juniper Networks 6 Raymond Zhang 7 Infonet Service Corporation 9 Expires: August 2005 10 February 2005 12 draft-vasseur-ccamp-inter-domain-pd-path-comp-00.txt 14 A Per-domain path computation method for computing Inter-domain Traffic 15 Engineering (TE) Label Switched Path (LSP) 17 Status of this Memo 19 By submitting this Internet-Draft, I certify that any applicable patent 20 or IPR claims of which I am aware have been disclosed, and any of which 21 I become aware will be disclosed, in accordance with RFC 3668. 23 This document is an Internet-Draft and is in full conformance with all 24 provisions of Section 10 of RFC2026. Internet-Drafts are 25 Working documents of the Internet Engineering Task Force (IETF), its 26 areas, and its working groups. Note that other groups may also 27 distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference material 32 or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This document specifies a per-domain path computation method for 42 computing inter-domain Traffic Engineering (TE) Multiprotocol Label 43 Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched (LSP) 44 paths. In this document a domain is referred to as a collection of 45 network elements within a common sphere of address management or path 46 computational responsibility such as IGP areas and Autonomous Systems. 48 Vasseur, Ayyangar and Zhang 1 49 The principle of per-domain path computation specified in this document 50 comprises of a GMPLS or MPLS node along an inter-domain LSP path, 51 computing a path up to the last reachable hop within its domain. It 52 covers cases where this last hop (domain exit point) may already be 53 specified in the signaling message as well the case where this last hop 54 may need to be determined by the GMPLS node. 56 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC 2119 [RFC2119]. 62 Table of content 64 1. Terminology ------------------------------------------- 3 65 2. Introduction ------------------------------------------ 4 66 3. General assumptions ----------------------------------- 5 67 4. Per-Domain path computation algorithm ----------------- 8 68 4.1 Example with an inter-area TE LSP -------------------- 9 69 4.1.1 Case 1: T1 is a contiguous TE LSP ------------------ 9 70 4.1.2 Case 2: T1 is a stitched or nested TE LSP ---------- 10 71 4.2 Example with an inter-AS TE LSP ---------------------- 10 72 4.2.1 Case 1: T1 is a contiguous TE LSP ----------------- 12 73 4.2.2 Case 2: T1 is a stitched or nested TE LSP --------- 13 74 5 Path optimality/diversity ------------------------------ 13 75 6 MPLS Traffic Engineering Fast Reroute for 76 inter-domain TE LSPs ------------------------------------- 13 77 6.1 Failure of an internal network element --------------- 13 78 6.2 Failure of an inter-ASBR links (inter-AS TE) --------- 14 79 6.3 Failure of an ABR or an ASBR node -------------------- 14 80 7. Reoptimization of an inter-domain TE LSP -------------- 14 81 7.1 Contiguous TE LSPs ----------------------------------- 14 82 7.2 Stitched or nested (non-contiguous) TE LSPs ---------- 15 83 8. Security Considerations ------------------------------- 16 84 9. Intellectual Property Considerations ------------------ 17 85 10. Acknowledgments -------------------------------------- 17 86 11. References ------------------------------------------- 17 87 11.1 Normative references -------------------------------- 17 88 11.2 Informative references ------------------------------ 18 90 Vasseur, Ayyangar and Zhang 2 91 1. Terminology 93 LSR: Label Switch Router 95 LSP: MPLS Label Switched Path 97 PCE: Path Computation Element. An LSR in charge of computing TE LSP 98 path for which it is not the Head-end. For instance, an ABR (inter- 99 area) or an ASBR (Inter-AS) can play the role of PCE. 101 PCC: Path Computation Client (any head-end LSR) requesting a path 102 computation from the Path Computation Element. 104 Local Repair: local protection techniques used to repair TE LSPs 105 quickly when a node or link along the LSPs path fails. 107 Protected LSP: an LSP is said to be protected at a given hop if it has 108 one or multiple associated backup tunnels originating at that hop. 110 Bypass Tunnel: an LSP that is used to protect a set of LSPs passing 111 over a common facility. 113 PLR: Point of Local Repair. The head-end of a bypass tunnel. 115 MP: Merge Point. The LSR where bypass tunnels meet the protected LSP. 117 NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A backup tunnel which 118 bypasses a single link of the protected LSP. 120 NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel which 121 bypasses a single node of the protected LSP. 123 Fast Reroutable LSP: any LSP for which the "Local protection desired" 124 bit is set in the Flag field of the SESSION_ATTRIBUTE object of its 125 Path messages or signaled with a FAST-REROUTE object. 127 CSPF: Constraint-based Shortest Path First. 129 Inter-AS MPLS TE LSP: A TE LSP whose head-end LSR and tail-end LSR do 130 not reside within the same Autonomous System (AS), or whose head-end 131 LSR and tail-end LSR are both in the same AS but the TE LSP�s path 132 may be across different ASes. Note that this definition also applies to 133 TE LSP whose Head-end and Tail-end LSRs reside in different sub-ASes 134 (BGP confederations). 136 Inter-area MPLS TE LSP: A TE LSP where the head-end LSR and tail-end 137 LSR do not reside in the same area or both the head-end and tail end 138 LSR reside in the same area but the TE LSP transits one or more 139 different areas along the path. 141 Vasseur, Ayyangar and Zhang 3 142 ABR Routers: routers used to connect two IGP areas (areas in OSPF or 143 L1/L2 in IS-IS) 145 Interconnect routers or ASBR routers: routers used to connect together 146 ASes of a different or the same Service Provider via one or more Inter- 147 AS links. 149 Boundary LSR: a boundary LSR is either an ABR in the context of inter- 150 area MPLS TE or an ASBR in the context of inter-AS MPLS TE. 152 TED: MPLS Traffic Engineering Database 154 The notion of contiguous, stitched and nested TE LSPs is defined in 155 [INTER-DOMAIN-SIG] and will not be repeated here. 157 2. Introduction 159 The requirements for inter-area and inter-AS MPLS Traffic Engineering 160 have been developed by the Traffic Engineering Working Group and have 161 been stated in [INTER-AREA-REQS] and [INTER-AS-REQS] respectively. The 162 framework for inter-domain MPLS Traffic Engineering has been provided 163 in [INTER-DOMAIN-FRAMEWORK]. 165 The set of mechanisms to establish and maintain inter-domain TE LSPs 166 are specified in [INTER-DOMAIN-SIG]. 168 This document exclusively focuses on the path computation aspects and 169 defines a method for computing inter-domain TE LSP paths. 171 When the visibility of an end to end complete path spanning multiple 172 domains is not available at the head end node, one approach described 173 in the document consists of using a per-domain path computation scheme 174 used during LSP setup to determine the inter-domain LSP path as it 175 traverses multiple domains. 177 Note that the mechanisms proposed in this document could also be 178 applicable to MPLS TE domains other than areas and ASes. 180 According to the wide set of requirements defined in [INTER-AS-TE-REQS] 181 and [INTER-AREA-TE-REQS], coming up with a single solution covering all 182 the requirements is certainly possible but may not be desired: indeed, 183 as described in [INTER-AS-TE-REQS] the spectrum of deployment scenarios 184 is quite large and designing a solution addressing the super-set of all 185 the requirements would lead to providing a rich set of mechanisms not 186 required in several cases. Depending on the deployment scenarios of a 187 SP, certain requirements stated above may be strict while certain other 188 requirements may be relaxed. 190 There are different ways in which inter-domain TE LSP path computation 191 may be performed. For example, if the requirement is to get an end-to- 192 end constraint-based shortest path across multiple domains, then a 194 Vasseur, Ayyangar and Zhang 4 195 mechanism using one or more distributed PCEs could be used to compute 196 the shortest path across different domains. Alternatively, one could 197 also use some static or discovery mechanisms to determine the next 198 boundary LSR per domain as the inter-domain TE LSP is being signaled. 199 Other offline mechanisms for path computation are not precluded either. 200 Depending on the Service Provider�s requirements, one may adopt either 201 of these techniques for inter-domain path computation. 203 Note that the adequate path computation method may be chosen based upon 204 the TE LSP characteristics and requirements. This document specifies an 205 inter-domain path computation technique based on per-domain path 206 computation and could be used in place or in conjunction with other 207 techniques. 209 3. General assumptions 211 In the rest of this document, we make the following set of assumptions: 213 1) Common assumptions 215 - Each domain in all the examples below is assumed to be capable of 216 doing Traffic Engineering (i.e. running OSPF-TE or ISIS-TE and RSVP- 217 TE). A domain may itself comprise multiple other domains. E.g. An AS 218 may itself be composed of several other sub-AS(es) (BGP confederations) 219 or areas/levels. 221 - The inter-domain LSPs are signaled using RSVP-TE ([RSVP-TE]). 223 - The path (ERO) for the inter-domain TE LSP traversing multiple 224 areas/ASes may be signaled as a set of (loose and/or strict) hops. The 225 hops may identify: 226 - The complete strict path end to end across different 227 areas/ASes 228 - The complete strict path in the source area/AS followed by 229 boundary LSRs (and domain identifiers, e.g. AS numbers) 230 - The complete list of boundary LSRs along the path 231 - The current boundary LSR and the LSP destination 233 In this case, the set of (loose or strict) hops can either be 234 statically configured on the Head-end LSR or dynamically computed. In 235 the former case, the resulting path is statically configured on the 236 Head-end LSR. In the latter case (dynamic computation), a per-domain 237 path computation method is defined in this document with some Auto- 238 discovery mechanism based on BGP and/or IGP information yielding the 239 next-hop boundary node (domain exit point, say ABR/ASBR) along the path 240 as the LSP is being signaled, along with crankback mechanisms. Note 241 that alternatively next-hop may be statically configured on the Head- 242 end LSR in which case next-hop auto-discovery would not be needed. 244 - Furthermore, the boundary LSRs are assumed to be capable of 245 performing local path computation for expansion of a loose next-hop in 247 Vasseur, Ayyangar and Zhang 5 248 the signaled ERO if the path is not signaled by the head-end LSR as a 249 set of strict hops or if the strict hop is an abstract node (e.g. an 250 AS). This can be done by performing a CSPF computation up to that next 251 loose hop as opposed to the TE LSP destination or by making use of some 252 PCEs. In any case, no topology or resource information needs to be 253 distributed between areas/ASes (as mandated per [INTER-AREA-REQS] and 254 [INTER-AS-REQS]), which is critical to preserve IGP/BGP scalability and 255 confidentiality in the case of TE LSPs spanning multiple routing 256 domains. 258 Note that PCE-based path computation may be mentioned in this document 259 for the sake of reference but such techniques are outside the scope of 260 this document. 262 - The paths for the intra-domain 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-domain 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, 300 Vasseur, Ayyangar and Zhang 6 301 - X2, X3: LSRs in area 2, 302 - An inter-area TE LSP T0 originated at R0 in area1 and terminating at 303 R1 in area2, 305 Notes: 306 - The terminology used in the example above corresponds to OSPF but the 307 path computation methods proposed in this document equally applies to 308 the case of an IS-IS multi-levels network. 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 Vasseur, Ayyangar and Zhang 7 352 - Each AS can be made of several IGP areas. The path computation 353 techniques described in this document applies to the case of a single 354 AS made of multiple IGP areas, multiples ASes made of a single IGP 355 areas or any combination of the above. For the sake of simplicity, each 356 routing domain will be considered as single area in this document. 358 - An inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6 359 in AS3. 361 4. Per-domain path computation algorithm 363 Regardless of the nature of the inter-domain TE LSP (contiguous, 364 stitched or nested), a similar set of mechanisms for local TE LSP path 365 computation (next hop resolution) can be used. 367 When an ABR/ASBR receives a Path message with a loose next-hop or an 368 abstract node in the ERO, then it carries out the following actions: 370 1) It checks if the loose next-hop is accessible via the TED. If the 371 loose next-hop is not present in the TED, then it checks if the next- 372 hop at least has IP reachability (via IGP or BGP). If the next-hop is 373 not reachable, then the path computation stops and the LSR sends back a 374 PathErr upstream. If the next-hop is reachable, then it finds an 375 ABR/ASBR to get to the next-hop. In the absence of an auto-discovery 376 mechanism, the ABR in the case of inter-area TE or the ASBR in the 377 next-hop AS in the case of inter-AS TE should be the loose next-hop in 378 the ERO and hence should be accessible via the TED, otherwise the path 379 computation for the inter-domain TE LSP will fail. 381 2) If the next-hop boundary LSR is present in the TED. 383 a) Case of a contiguous TE LSP. The ABR/ASBR just performs an 384 ERO expansion (unless not allowed by policy) after having 385 computed the path to the next loose hop (ABR/ASBR) that obeys 386 the set of required constraints. If no path satisfying the set 387 of constraints can be found, the path computation stops and a 388 Path Error MUST be sent for the inter-domain TE LSP. 390 b) Case of stitched or nested LSP 392 i) if the ABR/ASBR (receiving the LSP setup request) is 393 a candidate LSR for intra-area FA-LSP/LSP segment 394 setup, and if there is no FA-LSP/LSP segment from this 395 LSR to the next-hop boundary LSR (satisfying the 396 constraints) it SHOULD signal a FA-LSP/LSP segment to 397 the next-hop boundary LSR. If pre-configured FA-LSP(s) 398 or LSP segment(s) already exist, then it SHOULD try to 399 select from among those intra-area/AS LSPs. Depending 400 on local policy, it MAY signal a new FA-LSP/LSP segment 401 if this selection fails. If the FA-LSP/LSP segment is 402 successfully signaled or selected, it propagates the 404 Vasseur, Ayyangar and Zhang 8 405 inter-domain Path message to the next-hop following the 406 procedures described in [LSP-HIER]. If, for some reason 407 the dynamic FA-LSP/LSP segment setup to the next-hop 408 boundary LSR fails, the path computation stops and a 409 PathErr is sent upstream for the inter-domain LSP. 410 Similarly, if selection of a preconfigured FA-LSP/LSP 411 segment fails and local policy prevents dynamic FA- 412 LSP/LSP segment setup, then the path computation stops 413 and a PathErr is sent upstream for the inter-domain TE 414 LSP. 416 ii) If, however, the boundary LSR is not a FA-LSP/LSP 417 segment candidate, then it SHOULD simply compute a CSPF 418 path up to the next-hop boundary LSR carry out an ERO 419 expansion to the next-hop boundary LSR) and propagate 420 the Path message downstream. The outgoing ERO is 421 modified after the ERO expansion to the loose next-hop. 423 Note that in both cases, path computation may be 424 stopped due to some local policy. 426 4.1. Example with an inter-area TE LSP 428 4.1.1. Case 1: T1 is a contiguous TE LSP 430 When the path message reaches ABR1, it first determines the egress LSR 431 from its area 0 along the LSP path (say ABR�1), either directly from 432 the ERO (if for example the next hop ABR is specified as a loose hop in 433 the ERO) or by using some constraint-aware auto-discovery mechanism. In 434 the former case, every inter-AS TE LSP path is defined as a set of 435 loose and strict hops but at least the ABRs traversed by the inter-area 436 TE LSP MUST be specified as loose hops on the head-End LSR. 438 - Example 1 (set of strict hops end to end): R0-X1-ABR1-ABR�1-X2-X3-R1 439 - Example 2 (set of loose hops): R0-ABR1(loose)-ABR�1(loose)-R1(loose) 440 - Example 3 (mix of strict and loose hops): R0-X1-ASBR1-ABR�1(loose)- 441 X2-X3-R1 443 At least, the set of ABRs from the TE LSP head-end to the tail-End MUST 444 be present in the ERO as a set of loose hops. Optionally, a set of 445 paths can be configured on the head-end LSR, ordered by priority. Each 446 priority path can be associated with a different set of constraints. 447 Typically, it might be desirable to systematically have a last resort 448 option with no constraint to ensure that the inter-area TE LSP could 449 always be set up if at least a path exists between the inter-area TE 450 LSP source and destination. Note that in case of set up failure or when 451 an RSVP Path Error is received indicating the TE LSP has suffered a 452 failure, an implementation might support the possibility to retry a 453 particular path option a specific amount of time (optionally with 454 dynamic intervals between each trial) before trying a lower priority 456 Vasseur, Ayyangar and Zhang 9 457 path option. Any path can be defined as a set of loose and strict hops. 458 In other words, in some cases, it might be desirable to rely on the 459 dynamic path computation in some area, and exert a strict control on 460 the path in other areas (defining strict hops). 462 Once it has computed the path up to the next ABR, ABR1 sends the Path 463 message for the inter-area TE LSP to ABR�1. ABR�1 then repeats the a 464 similar procedure and the Path message for the inter-area TE LSP will 465 reach the destination R1. If ABR�1 cannot find a path obeying the set 466 of constraints for the inter-area TE LSP, the path computation stops 467 and ABR�1 MUST send a PathErr message to ABR1. Then ABR1 can in turn 468 triggers a new computation by selecting another egress boundary LSR 469 (ABR�2 in the example above) if crankback is allowed for this inter- 470 area TE LSP (see [CRANBACK]). If crankback is not allowed for that 471 inter-area TE LSP or if ABR1 has been configured not to perform 472 crankback, then ABR1 MUST stop any path computation for the TE LSP and 473 MUST forward a PathErr up to the head-end LSR (R0) without trying to 474 select another egress LSR. 476 4.1.2. Case 2: T1 is a stitched or nested TE LSP 478 When the path message reaches ABR1, ABR1 first determines the egress 479 LSR from its area 0 along the LSP path (say ABR�1), either directly 480 from the ERO or by using some constraint-aware auto-discovery 481 mechanism. 483 ABR1 will check if it has a FA-LSP or LSP segment to ABR�1 matching the 484 constraints carried in the inter-area TE LSP Path message. If not, ABR1 485 will compute the path for a FA-LSP or LSP segment from ABR1 to ABR�1 486 satisfying the constraint and will set it up accordingly. Note that the 487 FA-LSP or LSP segment could have also been pre-configured. 489 Once the ABR has selected the FA-LSP/LSP segment for the inter-area 490 LSP, using the signaling procedures described in [LSP-HIER], ABR1 sends 491 the Path message for inter-area TE LSP to ABR�1. Note that irrespective 492 of whether ABR1 does nesting or stitching, the Path message for the 493 inter-area TE LSP is always forwarded to ABR�1. ABR�1 then repeats the 494 exact same procedures and the Path message for the inter-area TE LSP 495 will reach the destination R1. If ABR�1 cannot find a path obeying the 496 set of constraints for the inter-area TE LSP, then ABR�1 MUST send a 497 PathErr message to ABR1. Then ABR1 can in turn either select another 498 FA-LSP/LSP segment to ABR�1 if such an LSP exists or select another 499 egress boundary LSR (ABR�2 in the example above) if crankback is 500 allowed for this inter-area TE LSP (see [CRANBACK]). If crankback is 501 not allowed for that inter-area TE LSP or if ABR1 has been configured 502 not to perform crankback, then ABR1 MUST forward a PathErr up to the 503 inter-area head-end LSR (R0) without trying to select another egress 504 LSR. 506 4.2. Example with an inter-AS TE LSP 508 Vasseur, Ayyangar and Zhang 10 509 The procedures for establishing an inter-AS TE LSP are very similar to 510 those of an inter-area TE LSP described above. The main difference is 511 related to the presence of inter-ASBRs link(s). 513 The links interconnecting ASBRs are usually not TE enabled and no IGP 514 is running at the AS boundaries. An implementation supporting inter-AS 515 MPLS TE MUST obviously allow the set up of inter-AS TE LSP over the 516 region interconnecting multiple ASBRs. In other words, an ASBR 517 compliant with this document MUST support the set up of TE LSP over 518 ASBR to ASBR links, performing all the usual operations related to MPLS 519 Traffic Engineering (call admission control, �) as defined in [RSVP- 520 TE]. 522 In term of computation of an inter-AS TE LSP path, an interesting 523 optimization consists of allowing the ASBRs to flood the TE information 524 related to the inter-ASBR link(s) although no IGP TE is enabled over 525 those links (and so there is no IGP adjacency over the inter-ASBR 526 links). This of course implies for the inter-ASBR links to be TE- 527 enabled although no IGP is running on those links. This allows a head- 528 end LSR to make a more appropriate route selection up to the first ASBR 529 in the next hop AS and will significantly reduce the number of 530 signaling steps in route computation. This also allows the entry ASBR 531 in an AS to make a more appropriate route selection up to the entry 532 ASBR in the next hop AS taking into account constraints associated with 533 the ASBR-ASBR links. Moreover, this reduces the risk of call set up 534 failure due to inter-ASBR links not satisfying the inter-AS TE LSP set 535 of constraints. Note that the TE information is only related to the 536 inter-ASBR links: the TE LSA/LSP flooded by the ASBR includes not only 537 the TE-enabled links contained in the AS but also the inter-ASBR links. 539 Note that no summarized TE information is leaked between ASes which is 540 compliant with the requirements listed in [INTER-AREA-TE-REQS] and 541 [INTER-AS-TE-REQS]. 543 Example: 545 <---BGP---> <---BGP--> 546 CE1---R0---X1-ASBR1-----ASBR4�-R3---ASBR7-�--ASBR9---R6 547 |\ \ | / | / | / | | | 548 | \ ASBR2---/ ASBR5 | -- | | | 549 | \ | | |/ | | | 550 R1-R2�--ASBR3�----ASBR6�-R4---ASBR8�---ASBR10---R7---CE2 552 For instance, in the diagram depicted above, when ASBR1 floods its IGP 553 TE LSA (opaque LSA for OSPF)/LSP (TLV 22 for IS-IS) in its routing 554 domain, it reflects the reservation states and TE properties of the 555 following links: X1-ASBR1, ASBR1-ASBR2 and ASBR1-ASBR4. 557 Thanks to such an optimization, the inter-ASBRs TE link information 558 corresponding to the links originated by the ASBR is made available in 559 the TED of other LSRs in the same area/AS that the ASBR belongs to. 561 Vasseur, Ayyangar and Zhang 11 562 Consequently, the CSPF computation for an inter-AS TE LSP path can also 563 take into account the inter-ASBR link(s). This will improve the chance 564 of successful path computation up to the next AS in case of a 565 bottleneck on some inter-ASBR links and it potentially reduces one 566 level of crankback. Note that no topology information is flooded and 567 these links are not used in IGP SPF computations. Only the TE 568 information for the links originated by the ASBR is advertised. 570 4.2.1. Case 1: T1 is a contiguous TE LSP 572 The inter-AS TE path may be configured on the head-end LSR as a set of 573 strict hops, loose hops or a combination of both. 575 - Example 1 (set of strict hops end to end): R0-X1-ASBR1-ASBR4-ASBR5- 576 R3-ASBR7-ASBR9-R6 577 - Example 2 (set of loose hops): R0-ASBR4(loose)-ASBR9(loose)-R6(loose) 578 - Example 3 (mix of strict and loose hops): R0-R2-ASBR3-ASBR2-ASBR1- 579 ASBR4(loose)-ASBR10(loose)-ASBR9-R6 581 When a next hop is a loose hop, a dynamic path calculation (also called 582 ERO expansion) is required taking into account the topology and TE 583 information of its own AS and the set of TE LSP constraints. In the 584 example 1 above, the inter-AS TE LSP path is statically configured as a 585 set of strict hops; thus, in this case, no dynamic computation is 586 required. Conversely, in the example 2, a per-AS path computation is 587 performed, respectively on R0 for AS1, ASBR4 for AS2 and ASBR9 for AS3. 588 Note that when an LSR has to perform an ERO expansion, the next hop 589 must either belong to the same AS, or must be the ASBR directly 590 connected to the next hops AS. In this later case, the ASBR 591 reachability MUST be announced in the IGP TE LSA/LSP originated by its 592 neighboring ASBR. Indeed, in the example 2 above, the TE LSP path is 593 defined as: R0-ASBR4(loose)-ASBR9(loose)-R6(loose). This implies that 594 R0 must compute the path from R0 to ASBR4, hence the need for R0 to get 595 the TE reservation state related to the ASBR1-ASBR4 link (flooded in 596 AS1 by ASBR1). In addition, ASBR1 MUST also announce the IP address of 597 ASBR4 specified in the T1 path configuration. 599 If an auto-discovery mechanism is available, every LSR receiving an 600 RSVP Path message, will have to determine automatically the next hop 601 ASBR, based on the IGP/BGP reachability of the TE LSP destination. With 602 such a scheme, the head-end LSR and every downstream ASBR loose hop 603 (except the last loose hop that computes the path to the final 604 destination) automatically computes the path up to the next ASBR, the 605 next loose hop based on the IGP/BGP reachability of the TE LSP 606 destination. If a particular destination is reachable via multiple 607 loose hops (ASBRs), local heuristics may be implemented by the head-end 608 LSR/ASBRs to select the next hop an ASBR among a list of possible 609 choices (closest exit point, metric advertised for the IP destination 610 (ex: OSPF LSA External - Type 2), local policy,...). Once the next ASBR 611 has been determined, an ERO expansion is performed as in the previous 613 Vasseur, Ayyangar and Zhang 12 614 case. 616 Once it has computed the path up to the next ASBR, ASBR1 sends the Path 617 message for the inter-area TE LSP to ASBR4 (supposing that ASBR4 is the 618 selected next hop ASBR). ASBR4 then repeats the exact same procedures 619 and the Path message for the inter-AS TE LSP will reach the destination 620 R1. If ASBR4 cannot find a path obeying the set of constraints for the 621 inter-AS TE LSP, then ASBR4 MUST send a PathErr message to ASBR1. Then 622 ASBR1 can in turn either select another ASBR (ASBR5 in the example 623 above) if crankback is allowed for this inter-AS TE LSP (see 624 [CRANBACK]). If crankback is not allowed for that inter-AS TE LSP or if 625 ASBR1 has been configured not to perform crankback, then ABR1 MUST stop 626 the path computation and MUST forward a PathErr up to the head-end LSR 627 (R0) without trying to select another egress LSR. In this case, the 628 head-end LSR can in turn select another sequence of loose hops, if 629 configured. Alternatively, the head-end LSR may decide to retry the 630 same path; this can be useful in case of set up failure due an outdated 631 IGP TE database in some downstream AS. An alternative could also be for 632 the head-end LSR to retry to same sequence of loose hops after having 633 relaxed some constraint(s). 635 4.2.2. Case 2: T1 is a stitched or nested TE LSP 637 The signaling procedures are very similar to the inter-area LSP setup 638 case described earlier. In this case, the FA-LSPs or LSP segments will 639 only be originated by the ASBRs at the entry to the AS. 641 5. Path optimality/diversity 643 Since the inter-domain path is computed on a per domain (area, AS) 644 basis, one cannot guarantee that the shortest inter-domain path can be 645 found. 647 Moreover, computing two diverse paths might not be possible in some 648 topologies (due to the well-known �trapping� problem). 650 As already pointed out, the required path computation method can be 651 selected by the Operator on a per LSP basis. 653 6. MPLS Traffic Engineering Fast Reroute for inter-domain TE LSPs 655 The signaling aspects of Fast Reroute and related constraints for each 656 TE LSP types in the case of inter-domain TE LSP has been covered in 657 [INTER-DOMAIN-SIG] and will not be repeated in this document. 659 There are multiple failure scenarios to consider in the case of Fast 660 Reroute for inter-domain TE LSPs. 662 6.1. Failure of an internal network element 664 Vasseur, Ayyangar and Zhang 13 665 The case of a failure of a network element within an area/AS such as a 666 link, SRLG or a node does not differ from Fast Reroute for intra-domain 667 TE LSP. 669 6.2. Failure of an inter-ASBR links (inter-AS TE) 671 In order to protect inter-domain TE LSPs from the failure of an inter- 672 ASBR link, this requires the computation of a backup tunnel path that 673 crosses an non IGP TE-enabled region (between two ASes). If the inter- 674 ASBR TE related information is flooded in the IGPs, each ASBR is 675 capable of computing the path according to the backup tunnel 676 constraints. Otherwise, the backup tunnel path MUST be statically 677 configured. 679 6.3. Failure of an ABR or an ASBR node 681 The constraints to be taken into account during the backup tunnel path 682 computation significantly differs upon the TE LSP type, network element 683 to protect (entry/exit boundary node) and the Fast Reroute method in 684 use (facility backup versus one-to-one). Those constraints have been 685 explored in detail in [INTER-DOMAIN-SIG] but since the backup tunnel is 686 itself an inter-domain TE LSP, its path computation can be performed 687 according to the two path computation methods described in this 688 document. 690 7. Reoptimization of an inter-domain TE LSP 692 The ability to reoptimize an existing inter-domain TE LSP path is of 693 course a requirement. The reoptimization process significantly differs 694 based upon the nature of the TE LSP and the mechanism in use for the TE 695 LSP path computation. 697 The following mechanisms can be used for re-optimization, which are 698 dependent on the nature of the inter-domain TE LSP. 700 7.1. Contiguous TE LSPs 702 After an inter-AS TE LSP has been set up, a more optimal route might 703 appear in the various traversed ASes. Then in this case, it is 704 desirable to get the ability to reroute an inter-AS TE LSP in a non- 705 disruptive fashion (making use of the so called Make Before Break 706 procedure) to follow this more optimal path. This is a known as a TE 707 LSP reoptimization procedure. 709 [LOOSE-REOPT] proposes a mechanisms allowing: 711 - The head-end LSR to trigger on every LSR whose next hop is a 712 loose hop the re evaluation of the current path in order to 713 detect a potentially more optimal path. This is done via 714 explicit signaling request: the head-end LSR sets the �ERO 716 Vasseur, Ayyangar and Zhang 14 717 Expansion request� bit of the SESSION-ATTRIBUTE object carried 718 in the RSVP Path message. 720 - An LSR whose next hop is a loose-hop to signal to the head- 721 end LSR that a better path exists. This is performed by sending 722 an RSVP Path Error Notify message (ERROR-CODE = 25), sub-code 6 723 (Better path exists). 725 This indication may be sent either: 727 - In response to a query sent by the head-end LSR, 728 - Spontaneously by any LSR having detected a more 729 optimal path 731 Such a mechanism allows for the reoptimization of a TE LSP if and only 732 if a better path is some downstream area/AS is detected. 734 The reoptimization event can either be timer or event-driven based (a 735 link UP event for instance). 737 Note that the reoptimization MUST always be performed in a non- 738 disruptive fashion. 740 Once the head-end LSR is informed of the existence of a more optimal 741 path either in its head-end area/AS or in another AS, the inter-AS TE 742 Path computation is triggered using the same set of mechanisms as when 743 the TE LSP is first set up. Then the inter-AS TE LSP is set up 744 following the more optimal path, making use of the make before break 745 procedure. In case of a contiguous LSP, the reoptimization process is 746 strictly controlled by the head-end LSR which triggers the make-before- 747 break procedure, regardless of the location where the more optimal path 748 is. 750 Note that in the case of loose hop reoptimization, the TE LSP may 751 follow a preferable path within one or more domain(s) whereas in the 752 case of PCE-based path computation techniques, the reoptimization 753 process may lead to following a completely different inter-domain path 754 (including a different set of ABRs/ASBRs) since end-to-end shortest 755 path is computed. 757 7.2. Stitched or nested (non-contiguous) TE LSPs 759 In the case of a stitched or nested inter-domain TE LSP, the re- 760 optimization process is treated as a local matter to any Area/AS. The 761 main reason is that the inter-domain TE LSP is a different LSP (and 762 therefore different RSVP session) from the intra-domain LSP segment or 763 FA-LSP in an area or an AS. Therefore, reoptimization in an area/AS is 764 done by locally reoptimizing the intra-domain FA LSP or LSP segment. 765 Since the inter-domain TE LSPs are transported using LSP segments or 766 FA-LSP across each domain, optimality of the inter-domain TE LSP in an 767 area/AS is dependent on the optimality of the corresponding LSP 769 Vasseur, Ayyangar and Zhang 15 770 segments or FA-LSPs. If, after an inter-domain LSP is setup, a more 771 optimal path is available within an area/AS, the corresponding LSP 772 segment(s) or FA-LSP will be re-optimized using "make-before-break" 773 techniques discussed in [RSVP-TE]. Reoptimization of the FA LSP or LSP 774 segment automatically reoptimizes the inter-domain TE LSPs that the LSP 775 segment transports. Reoptimization parameters like frequency of 776 reoptimization, criteria for reoptimization like metric or bandwidth 777 availability; etc can vary from one area/AS to another and can be 778 configured as required, per intra-area/AS TE LSP segment or FA-LSP if 779 it is preconfigured or based on some global policy within the area/AS. 781 Hence, in this scheme, since each area/AS takes care of reoptimizing 782 its own LSP segments or FA-LSPs, and therefore the corresponding inter- 783 domain TE LSPs, the make-before-break can happen locally and is not 784 triggered by the head-end LSR for the inter-domain LSP. So, no 785 additional RSVP signaling is required for LSP re-optimization and 786 reoptimization is transparent to the HE LSR of the inter-domain TE LSP. 788 If, however, an operator desires to manually trigger reoptimization at 789 the head-end LSR for the inter-domain TE LSP, then this solution does 790 not prevent that. A manual trigger for reoptimization at the head-end 791 LSR SHOULD force a reoptimization thereby signaling a "new" path for 792 the same LSP (along the optimal path) making use of the make-before- 793 break procedure. In response to this new setup request, the boundary 794 LSR may either initiate new LSP segment setup, in case the inter-domain 795 TE LSP is being stitched to the intra-area/AS LSP segment or it may 796 select an existing or new FA-LSP in case of nesting. When the LSP setup 797 along the current optimal path is complete, the head end should 798 switchover the traffic onto that path and the old path is eventually 799 torn down. Note that the head-end LSR does not know a priori whether a 800 more optimal path exists. Such a manual trigger from the head-end LSR 801 of the inter-domain TE LSP is, however, not considered to be a frequent 802 occurrence. 804 Note that stitching or nesting rely on local optimization: the 805 reoptimization process allows to locally reoptimize each TE LSP segment 806 or FA-LSP: hence, the reoptimization is not global and consequently the 807 end to end path may no longer to optimal, should it be optimal when set 808 up. 810 Procedures described in [LOOSE-REOPT] MUST be used if the operator does 811 not desire local re-optimization of certain inter-domain LSPs. In this 812 case, any re-optimization event within the domain MUST be reported to 813 the head-end node. This SHOULD be a configurable policy. 815 8. Security Considerations 817 When signaling an inter-AS TE, an Operator may make use of the already 818 defined security features related to RSVP (authentication). This may 819 require some coordination between Service Providers to share the keys 820 (see RFC 2747 and RFC 3097). 822 Vasseur, Ayyangar and Zhang 16 823 9. Intellectual Property Considerations 825 The IETF takes no position regarding the validity or scope of any 826 Intellectual Property Rights or other rights that might be claimed to 827 pertain to the implementation or use of the technology described in 828 this document or the extent to which any license under such rights 829 might or might not be available; nor does it represent that it has 830 made any independent effort to identify any such rights. Information 831 on the procedures with respect to rights in RFC documents can be 832 found in BCP 78 and BCP 79. 834 Copies of IPR disclosures made to the IETF Secretariat and any 835 assurances of licenses to be made available, or the result of an 836 attempt made to obtain a general license or permission for the use of 837 such proprietary rights by implementers or users of this 838 specification can be obtained from the IETF on-line IPR repository at 839 http://www.ietf.org/ipr. 841 The IETF invites any interested party to bring to its attention any 842 copyrights, patents or patent applications, or other proprietary 843 rights that may cover technology that may be required to implement 844 this standard. Please address the information to the IETF at ietf- 845 ipr@ietf.org.. 847 IPR Disclosure Acknowledgement 849 By submitting this Internet-Draft, I certify that any applicable 850 patent or other IPR claims of which I am aware have been disclosed, 851 and any of which I become aware will be disclosed, in accordance with 852 RFC 3668. 854 10. Acknowledgments 856 We would like to acknowledge input and helpful comments from Adrian 857 Farrel. 859 11 References 861 11.1. Normative References 863 [RFC] Bradner, S., "Key words for use in RFCs to indicate requirements 864 levels", RFC 2119, March 1997. 866 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 867 3667, February 2004. 869 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 870 Technology", BCP 79, RFC 3668, February 2004. 872 Vasseur, Ayyangar and Zhang 17 873 [RSVP] Braden, et al, " Resource ReSerVation Protocol (RSVP) � Version 874 1, Functional Specification�, RFC 2205, September 1997. 876 [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 877 3209, December 2001. 879 [REFRESH-REDUCTION] Berger et al, �RSVP Refresh Overhead Reduction 880 Extensions�, RFC2961, April 2001. 882 [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for 883 LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, December 884 2003. 886 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 887 Extensions to OSPF Version 2", RFC 3630, September 2003. 889 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", 890 RFC 3784, June 2004. 892 11.2. Informative references 894 [INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J., "Requirements 895 for inter-area MPLS Traffic Engineering", draft-ietf-tewg-interarea- 896 mpls-te-req-03.txt, work in progress. 898 [INT-AS-REQ] Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic 899 Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req-09.txt, 900 work in progress. 902 [INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A Framework 903 for Inter-Domain MPLS Traffic Engineering", draft-ietf-ccamp-inter- 904 domain-framework-00.txt, work in progress. 906 [FACILITY-BACKUP] Le Roux, J.L., Vasseur, J.P. et al. "Framework for 907 PCE based MPLS Facility Backup Path Computation", draft-leroux-pce- 908 backup-comp-frwk-00.txt, work in progress 910 [INTER-DOMAIN-SIG] Ayyangar, A., Vasseur, JP. �Inter-domain MPLS 911 Traffic Engineering � RSVP extensions�, draft-ayyangar-ccamp-inter- 912 domain-rsvp-te, work in progress. 914 [LSP-ATTRIBUTE] Farrel A. et al, "Encoding of Attributes for 915 Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) 916 Establishment Using RSVP-TE", draft-ietf-mpls-rsvpte-attributes-04,(work 917 in progress). 919 [GMPLS-OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay 920 Model", (work in progress). 922 [EXCLUDE-ROUTE] Lee et all, Exclude Routes - Extension to RSVP-TE, 923 draft-ietf-ccamp-rsvp-te-exclude-route-00.txt, work in progress. 925 Vasseur, Ayyangar and Zhang 18 926 [LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D.,Swallow, G., 927 Wadhwa, S., Bonica, R., " Detecting Data Plane Liveliness in MPLS", 928 Internet Draft , October 2002. (Work 929 in Progress) 931 [MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS 932 Networks", RFC 3443 Updates RFC 3032) ", January 2003 934 [LOOSE-PATH-REOPT] Vasseur, Ikejiri and Zhang �Reoptimization of an 935 explicit loosely routed MPLS TE paths�, draft-ietf-ccamp-loose-path- 936 reopt-01.txt, July 2004, Work in Progress. 938 [NODE-ID] Vasseur, Ali and Sivabalan, �Definition of an RRO node-id 939 subobject�, draft-ietf-mpls-nodeid-subobject-03.txt, work in progress. 941 [LSP-HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized 942 MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, March 2002. 944 [MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS 945 Networks", RFC 3443 (Updates RFC 3032) ", January 2003. 947 Authors' Address: 949 Jean-Philippe Vasseur (Editor) 950 Cisco Systems, Inc. 951 300 Beaver Brook Road 952 Boxborough , MA - 01719 953 USA 954 Email: jpv@cisco.com 956 Arthi Ayyangar (Editor) 957 Juniper Networks, Inc 958 1194 N.Mathilda Ave 959 Sunnyvale, CA 94089 960 USA 961 e-mail: arthi@juniper.net 963 Raymond Zhang 964 Infonet Services Corporation 965 2160 E. Grand Ave. 966 El Segundo, CA 90025 967 USA 968 Email: raymond_zhang@infonet.com 970 Full Copyright Statement 972 Vasseur, Ayyangar and Zhang 19 973 Copyright (C) The Internet Society (2005). This document is subject to 974 the rights, licenses and restrictions contained in BCP 78, and except 975 as set forth therein, the authors retain all their rights. 977 This document and the information contained herein are provided on an 978 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 979 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 980 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 981 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 982 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 983 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 985 Vasseur, Ayyangar and Zhang 20