idnits 2.17.1 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt: -(482): 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 -(492): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(910): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(914): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(942): 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 851. -- Found old boilerplate from RFC 3978, Section 5.5 on line 986. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 831. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 838. ** 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. == There are 42 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 1169 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.) ** There is 1 instance of too long lines in the document, the longest one being 12 characters in excess of 72. 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.) -- The document date (April 2005) is 6951 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 162, 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 809, but not defined == Unused Reference: 'RFC' is defined on line 862, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 865, 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 872, but no explicit reference was found in the text == Unused Reference: 'REFRESH-REDUCTION' is defined on line 878, but no explicit reference was found in the text == Unused Reference: 'FAST-REROUTE' is defined on line 881, but no explicit reference was found in the text == Unused Reference: 'ISIS-TE' is defined on line 888, but no explicit reference was found in the text == Unused Reference: 'INT-AREA-REQ' is defined on line 893, but no explicit reference was found in the text == Unused Reference: 'INT-AS-REQ' is defined on line 897, but no explicit reference was found in the text == Unused Reference: 'INT-DOMAIN-FRWK' is defined on line 901, but no explicit reference was found in the text == Unused Reference: 'FACILITY-BACKUP' is defined on line 905, but no explicit reference was found in the text == Unused Reference: 'LSP-ATTRIBUTE' is defined on line 918, but no explicit reference was found in the text == Unused Reference: 'GMPLS-OVERLAY' is defined on line 923, but no explicit reference was found in the text == Unused Reference: 'EXCLUDE-ROUTE' is defined on line 926, but no explicit reference was found in the text == Unused Reference: 'LSPPING' is defined on line 929, but no explicit reference was found in the text == Unused Reference: 'MPLS-TTL' is defined on line 947, but no explicit reference was found in the text == Unused Reference: 'LOOSE-PATH-REOPT' is defined on line 937, but no explicit reference was found in the text == Unused Reference: 'NODE-ID' is defined on line 941, 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 (-06) exists of draft-ietf-ccamp-lsp-stitching-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-05 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: October 2005 10 April 2005 12 draft-ietf-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 ........................ 11 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 inter-domain 76 TE LSPs ................................................. 13 77 6.1 Failure of an internal network element ................. 14 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 References .............................................. 17 86 10.1 Normative references .................................. 17 87 10.2 Informative references ................................ 18 89 Vasseur, Ayyangar and Zhang 2 90 1. Terminology 92 ABR Routers: routers used to connect two IGP areas (areas in OSPF or 93 L1/L2 in IS-IS) 95 Boundary LSR: a boundary LSR is either an ABR in the context of inter- 96 area MPLS TE or an ASBR in the context of inter-AS MPLS TE. 98 Bypass Tunnel: an LSP that is used to protect a set of LSPs passing 99 over a common facility. 101 CSPF: Constraint-based Shortest Path First. 103 Fast Reroutable LSP: any LSP for which the "Local protection desired" 104 bit is set in the Flag field of the SESSION_ATTRIBUTE object of its 105 Path messages or signaled with a FAST-REROUTE object. 107 Interconnect routers or ASBR routers: routers used to connect together 108 ASes of a different or the same Service Provider via one or more Inter- 109 AS links. 111 Inter-AS MPLS TE LSP: A TE LSP whose head-end LSR and tail-end LSR do 112 not reside within the same Autonomous System (AS), or whose head-end 113 LSR and tail-end LSR are both in the same AS but the TE LSP�s path 114 may be across different ASes. Note that this definition also applies to 115 TE LSP whose Head-end and Tail-end LSRs reside in different sub-ASes 116 (BGP confederations). 118 Inter-area MPLS TE LSP: A TE LSP where the head-end LSR and tail-end 119 LSR do not reside in the same area or both the head-end and tail end 120 LSR reside in the same area but the TE LSP transits one or more 121 different areas along the path. 123 LSR: Label Switch Router 125 LSP: MPLS Label Switched Path 127 Local Repair: local protection techniques used to repair TE LSPs 128 quickly when a node or link along the LSPs path fails. 130 MP: Merge Point. The LSR where bypass tunnels meet the protected LSP. 132 NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A backup tunnel which 133 bypasses a single link of the protected LSP. 135 NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel which 136 bypasses a single node of the protected LSP. 138 Vasseur, Ayyangar and Zhang 3 139 PCE: Path Computation Element. An LSR in charge of computing TE LSP 140 path for which it is not the Head-end. For instance, an ABR (inter- 141 area) or an ASBR (Inter-AS) can play the role of PCE. 143 PCC: Path Computation Client (any head-end LSR) requesting a path 144 computation from the Path Computation Element. 146 Protected LSP: an LSP is said to be protected at a given hop if it has 147 one or multiple associated backup tunnels originating at that hop. 149 PLR: Point of Local Repair. The head-end of a bypass tunnel. 151 TED: MPLS Traffic Engineering Database 153 The notion of contiguous, stitched and nested TE LSPs is defined in 154 [INTER-DOMAIN-SIG] and [LSP-STITCHING] and will not be repeated here. 156 2. Introduction 158 The requirements for inter-area and inter-AS MPLS Traffic Engineering 159 have been developed by the Traffic Engineering Working Group and have 160 been stated in [INTER-AREA-REQS] and [INTER-AS-REQS] respectively. The 161 framework for inter-domain MPLS Traffic Engineering has been provided 162 in [INTER-DOMAIN-FRAMEWORK]. 164 The set of mechanisms to establish and maintain inter-domain TE LSPs 165 are specified in [INTER-DOMAIN-SIG] and [LSP-STITCHING]. 167 This document exclusively focuses on the path computation aspects and 168 defines a method for computing inter-domain TE LSP paths where each 169 node in charge of computing a section of an inter-domain TE LSP path is 170 always along the path of such LSP. 172 When the visibility of an end to end complete path spanning multiple 173 domains is not available at the head end node, one approach described 174 in the document consists of using a per-domain path computation scheme 175 used during LSP setup to determine the inter-domain LSP path as it 176 traverses multiple domains. 178 Note that the mechanisms proposed in this document could also be 179 applicable to MPLS TE domains other than areas and ASes. 181 According to the wide set of requirements defined in [INTER-AS-TE-REQS] 182 and [INTER-AREA-TE-REQS], coming up with a single solution covering all 183 the requirements is certainly possible but may not be desired: indeed, 184 as described in [INTER-AS-TE-REQS] the spectrum of deployment scenarios 185 is quite large and designing a solution addressing the super-set of all 186 the requirements would lead to providing a rich set of mechanisms not 187 required in several cases. Depending on the deployment scenarios of a 188 SP, certain requirements stated above may be strict while certain other 189 requirements may be relaxed. 191 Vasseur, Ayyangar and Zhang 4 192 There are different ways in which inter-domain TE LSP path computation 193 may be performed. For example, if the requirement is to get an end-to- 194 end constraint-based shortest path across multiple domains, then a 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 242 Vasseur, Ayyangar and Zhang 5 243 that alternatively next-hop may be statically configured on the Head- 244 end LSR in which case next-hop auto-discovery would not be needed. 246 - Furthermore, the boundary LSRs are assumed to be capable of 247 performing local path computation for expansion of a loose next-hop in 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 Vasseur, Ayyangar and Zhang 6 296 Assumptions 298 - ABR1, ABR2, ABR�1 and ABR�2 are ABRs, 299 - X1: an LSR in area 1, 300 - X2, X3: LSRs in area 2, 301 - An inter-area TE LSP T0 originated at R0 in area1 and terminating at 302 R1 in area2, 304 Notes: 305 - The terminology used in the example above corresponds to OSPF but the 306 path computation methods proposed in this document equally applies to 307 the case of an IS-IS multi-levels network. 308 - Just a few routers in each area are depicted in the diagram above for 309 the sake of simplicity. 311 3) Example of topology for the inter-AS TE case: 313 We will consider the following general case, built on a superset of the 314 various scenarios defined in [INTER-AS-TE-REQS]: 316 <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> 318 <---BGP---> <---BGP--> 319 CE1---R0---X1-ASBR1-----ASBR4�-R3---ASBR7-�--ASBR9----R6 320 |\ \ | / | / | / | | | 321 | \ ASBR2---/ ASBR5 | -- | | | 322 | \ | | |/ | | | 323 R1-R2�--ASBR3�----ASBR6�-R4---ASBR8�---ASBR10�--R7---CE2 325 <======= Inter-AS TE LSP(LSR to LSR)===========> 326 or 328 <======== Inter-AS TE LSP (CE to ASBR => 330 or 332 <================= Inter-AS TE LSP (CE to CE)===============> Formatted: 334 The diagram above covers all the inter-AS TE deployment cases described 335 in [INTER-AS-TE-REQS]. 337 Assumptions: 339 - Three interconnected ASes, respectively AS1, AS2, and AS3. Note that 340 AS3 might be AS1 in some scenarios described in [INTER-AS-TE-REQS], 342 - The various ASBRs are BGP peers, without any IGP running on the 343 single hop links interconnecting the ASBRs and also referred to as 344 inter-ASBR links, 346 Vasseur, Ayyangar and Zhang 7 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 4. Per-domain path computation algorithm 362 Regardless of the nature of the inter-domain TE LSP (contiguous, 363 stitched or nested), a similar set of mechanisms for local TE LSP path 364 computation (next hop resolution) can be used. 366 When an ABR/ASBR receives a Path message with a loose next-hop or an 367 abstract node in the ERO, then it carries out the following actions: 369 1) It checks if the loose next-hop is accessible via the TED. If the 370 loose next-hop is not present in the TED, then it checks if the next- 371 hop at least has IP reachability (via IGP or BGP). If the next-hop is 372 not reachable, then the path computation stops and the LSR sends back a 373 PathErr upstream. If the next-hop is reachable, then it finds an 374 ABR/ASBR to get to the next-hop. In the absence of an auto-discovery 375 mechanism, the ABR in the case of inter-area TE or the ASBR in the 376 next-hop AS in the case of inter-AS TE should be the loose next-hop in 377 the ERO and hence should be accessible via the TED, otherwise the path 378 computation for the inter-domain TE LSP will fail. 380 2) If the next-hop boundary LSR is present in the TED. 382 a) Case of a contiguous TE LSP. The ABR/ASBR just performs an 383 ERO expansion (unless not allowed by policy) after having 384 computed the path to the next loose hop (ABR/ASBR) that obeys 385 the set of required constraints. If no path satisfying the set 386 of constraints can be found, the path computation stops and a 387 Path Error MUST be sent for the inter-domain TE LSP. 389 b) Case of stitched or nested LSP 391 i) if the ABR/ASBR (receiving the LSP setup request) is 392 a candidate LSR for intra-area FA-LSP/LSP segment 393 setup, and if there is no FA-LSP/LSP segment from this 394 LSR to the next-hop boundary LSR (satisfying the 395 constraints) it SHOULD signal a FA-LSP/LSP segment to 396 the next-hop boundary LSR. If pre-configured FA-LSP(s) 398 Vasseur, Ayyangar and Zhang 8 399 or LSP segment(s) already exist, then it SHOULD try to 400 select from among those intra-area/AS LSPs. Depending 401 on local policy, it MAY signal a new FA-LSP/LSP segment 402 if this selection fails. If the FA-LSP/LSP segment is 403 successfully signaled or selected, it propagates the 404 inter-domain Path message to the next-hop following the 405 procedures described in [LSP-HIER]. If, for some reason 406 the dynamic FA-LSP/LSP segment setup to the next-hop 407 boundary LSR fails, the path computation stops and a 408 PathErr is sent upstream for the inter-domain LSP. 409 Similarly, if selection of a preconfigured FA-LSP/LSP 410 segment fails and local policy prevents dynamic FA- 411 LSP/LSP segment setup, then the path computation stops 412 and a PathErr is sent upstream for the inter-domain TE 413 LSP. 415 ii) If, however, the boundary LSR is not a FA-LSP/LSP 416 segment candidate, then it SHOULD simply compute a CSPF 417 path up to the next-hop boundary LSR carry out an ERO 418 expansion to the next-hop boundary LSR) and propagate 419 the Path message downstream. The outgoing ERO is 420 modified after the ERO expansion to the loose next-hop. 422 Note that in both cases, path computation may be 423 stopped due to some local policy. 425 4.1. Example with an inter-area TE LSP 427 4.1.1. Case 1: T1 is a contiguous TE LSP 429 When the path message reaches ABR1, it first determines the egress LSR 430 from its area 0 along the LSP path (say ABR�1), either directly from 431 the ERO (if for example the next hop ABR is specified as a loose hop in 432 the ERO) or by using some constraint-aware auto-discovery mechanism. In 433 the former case, every inter-AS TE LSP path is defined as a set of 434 loose and strict hops but at least the ABRs traversed by the inter-area 435 TE LSP MUST be specified as loose hops on the head-End LSR. 437 - Example 1 (set of strict hops end to end): R0-X1-ABR1-ABR�1-X2-X3-R1 438 - Example 2 (set of loose hops): R0-ABR1(loose)-ABR�1(loose)-R1(loose) 439 - Example 3 (mix of strict and loose hops): R0-X1-ASBR1-ABR�1(loose)- 440 X2-X3-R1 442 At least, the set of ABRs from the TE LSP head-end to the tail-End MUST 443 be present in the ERO as a set of loose hops. Optionally, a set of 444 paths can be configured on the head-end LSR, ordered by priority. Each 445 priority path can be associated with a different set of constraints. 446 Typically, it might be desirable to systematically have a last resort 447 option with no constraint to ensure that the inter-area TE LSP could 448 always be set up if at least a path exists between the inter-area TE 450 Vasseur, Ayyangar and Zhang 9 451 LSP source and destination. Note that in case of set up failure or when 452 an RSVP Path Error is received indicating the TE LSP has suffered a 453 failure, an implementation might support the possibility to retry a 454 particular path option a specific amount of time (optionally with 455 dynamic intervals between each trial) before trying a lower priority 456 path option. Any path can be defined as a set of loose and strict hops. 457 In other words, in some cases, it might be desirable to rely on the 458 dynamic path computation in some area, and exert a strict control on 459 the path in other areas (defining strict hops). 461 Once it has computed the path up to the next ABR, ABR1 sends the Path 462 message for the inter-area TE LSP to ABR�1. ABR�1 then repeats the a 463 similar procedure and the Path message for the inter-area TE LSP will 464 reach the destination R1. If ABR�1 cannot find a path obeying the set 465 of constraints for the inter-area TE LSP, the path computation stops 466 and ABR�1 MUST send a PathErr message to ABR1. Then ABR1 can in turn 467 triggers a new computation by selecting another egress boundary LSR 468 (ABR�2 in the example above) if crankback is allowed for this inter- 469 area TE LSP (see [CRANBACK]). If crankback is not allowed for that 470 inter-area TE LSP or if ABR1 has been configured not to perform 471 crankback, then ABR1 MUST stop any path computation for the TE LSP and 472 MUST forward a PathErr up to the head-end LSR (R0) without trying to 473 select another egress LSR. 475 4.1.2. Case 2: T1 is a stitched or nested TE LSP 477 When the path message reaches ABR1, ABR1 first determines the egress 478 LSR from its area 0 along the LSP path (say ABR�1), either directly 479 from the ERO or by using some constraint-aware auto-discovery 480 mechanism. 482 ABR1 will check if it has a FA-LSP or LSP segment to ABR�1 matching the 483 constraints carried in the inter-area TE LSP Path message. If not, ABR1 484 will compute the path for a FA-LSP or LSP segment from ABR1 to ABR�1 485 satisfying the constraint and will set it up accordingly. Note that the 486 FA-LSP or LSP segment could have also been pre-configured. 488 Once the ABR has selected the FA-LSP/LSP segment for the inter-area 489 LSP, using the signaling procedures described in [LSP-HIER], ABR1 sends 490 the Path message for inter-area TE LSP to ABR�1. Note that irrespective 491 of whether ABR1 does nesting or stitching, the Path message for the 492 inter-area TE LSP is always forwarded to ABR�1. ABR�1 then repeats the 493 exact same procedures and the Path message for the inter-area TE LSP 494 will reach the destination R1. If ABR�1 cannot find a path obeying the 495 set of constraints for the inter-area TE LSP, then ABR�1 MUST send a 496 PathErr message to ABR1. Then ABR1 can in turn either select another 497 FA-LSP/LSP segment to ABR�1 if such an LSP exists or select another 498 egress boundary LSR (ABR�2 in the example above) if crankback is 499 allowed for this inter-area TE LSP (see [CRANBACK]). If crankback is 500 not allowed for that inter-area TE LSP or if ABR1 has been configured 501 not to perform crankback, then ABR1 MUST forward a PathErr up to the 503 Vasseur, Ayyangar and Zhang 10 504 inter-area head-end LSR (R0) without trying to select another egress 505 LSR. 507 4.2. Example with an inter-AS TE LSP 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 555 Vasseur, Ayyangar and Zhang 11 556 domain, it reflects the reservation states and TE properties of the 557 following links: X1-ASBR1, ASBR1-ASBR2 and ASBR1-ASBR4. 559 Thanks to such an optimization, the inter-ASBRs TE link information 560 corresponding to the links originated by the ASBR is made available in 561 the TED of other LSRs in the same area/AS that the ASBR belongs to. 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 608 Vasseur, Ayyangar and Zhang 12 609 loose hops (ASBRs), local heuristics may be implemented by the head-end 610 LSR/ASBRs to select the next hop an ASBR among a list of possible 611 choices (closest exit point, metric advertised for the IP destination 612 (ex: OSPF LSA External - Type 2), local policy,...). Once the next ASBR 613 has been determined, an ERO expansion is performed as in the previous 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 Vasseur, Ayyangar and Zhang 13 660 There are multiple failure scenarios to consider in the case of Fast 661 Reroute for inter-domain TE LSPs. 663 6.1. Failure of an internal network element 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 Vasseur, Ayyangar and Zhang 14 712 - The head-end LSR to trigger on every LSR whose next hop is a 713 loose hop the re evaluation of the current path in order to 714 detect a potentially more optimal path. This is done via 715 explicit signaling request: the head-end LSR sets the �ERO 716 Expansion request� bit of the SESSION-ATTRIBUTE object carried 717 in the RSVP Path message. 719 - An LSR whose next hop is a loose-hop to signal to the head- 720 end LSR that a better path exists. This is performed by sending 721 an RSVP Path Error Notify message (ERROR-CODE = 25), sub-code 6 722 (Better path exists). 724 This indication may be sent either: 726 - In response to a query sent by the head-end LSR, 727 - Spontaneously by any LSR having detected a more 728 optimal path 730 Such a mechanism allows for the reoptimization of a TE LSP if and only 731 if a better path is some downstream area/AS is detected. 733 The reoptimization event can either be timer or event-driven based (a 734 link UP event for instance). 736 Note that the reoptimization MUST always be performed in a non- 737 disruptive fashion. 739 Once the head-end LSR is informed of the existence of a more optimal 740 path either in its head-end area/AS or in another AS, the inter-AS TE 741 Path computation is triggered using the same set of mechanisms as when 742 the TE LSP is first set up. Then the inter-AS TE LSP is set up 743 following the more optimal path, making use of the make before break 744 procedure. In case of a contiguous LSP, the reoptimization process is 745 strictly controlled by the head-end LSR which triggers the make-before- 746 break procedure, regardless of the location where the more optimal path 747 is. 749 Note that in the case of loose hop reoptimization, the TE LSP may 750 follow a preferable path within one or more domain(s) whereas in the 751 case of PCE-based path computation techniques, the reoptimization 752 process may lead to following a completely different inter-domain path 753 (including a different set of ABRs/ASBRs) since end-to-end shortest 754 path is computed. 756 7.2. Stitched or nested (non-contiguous) TE LSPs 758 In the case of a stitched or nested inter-domain TE LSP, the re- 759 optimization process is treated as a local matter to any Area/AS. The 760 main reason is that the inter-domain TE LSP is a different LSP (and 761 therefore different RSVP session) from the intra-domain LSP segment or 762 FA-LSP in an area or an AS. Therefore, reoptimization in an area/AS is 764 Vasseur, Ayyangar and Zhang 15 765 done by locally reoptimizing the intra-domain FA LSP or LSP segment. 766 Since the inter-domain TE LSPs are transported using LSP segments or 767 FA-LSP across each domain, optimality of the inter-domain TE LSP in an 768 area/AS is dependent on the optimality of the corresponding LSP 769 segments or FA-LSPs. If, after an inter-domain LSP is setup, a more 770 optimal path is available within an area/AS, the corresponding LSP 771 segment(s) or FA-LSP will be re-optimized using "make-before-break" 772 techniques discussed in [RSVP-TE]. Reoptimization of the FA LSP or LSP 773 segment automatically reoptimizes the inter-domain TE LSPs that the LSP 774 segment transports. Reoptimization parameters like frequency of 775 reoptimization, criteria for reoptimization like metric or bandwidth 776 availability; etc can vary from one area/AS to another and can be 777 configured as required, per intra-area/AS TE LSP segment or FA-LSP if 778 it is preconfigured or based on some global policy within the area/AS. 780 Hence, in this scheme, since each area/AS takes care of reoptimizing 781 its own LSP segments or FA-LSPs, and therefore the corresponding inter- 782 domain TE LSPs, the make-before-break can happen locally and is not 783 triggered by the head-end LSR for the inter-domain LSP. So, no 784 additional RSVP signaling is required for LSP re-optimization and 785 reoptimization is transparent to the HE LSR of the inter-domain TE LSP. 787 If, however, an operator desires to manually trigger reoptimization at 788 the head-end LSR for the inter-domain TE LSP, then this solution does 789 not prevent that. A manual trigger for reoptimization at the head-end 790 LSR SHOULD force a reoptimization thereby signaling a "new" path for 791 the same LSP (along the optimal path) making use of the make-before- 792 break procedure. In response to this new setup request, the boundary 793 LSR may either initiate new LSP segment setup, in case the inter-domain 794 TE LSP is being stitched to the intra-area/AS LSP segment or it may 795 select an existing or new FA-LSP in case of nesting. When the LSP setup 796 along the current optimal path is complete, the head end should 797 switchover the traffic onto that path and the old path is eventually 798 torn down. Note that the head-end LSR does not know a priori whether a 799 more optimal path exists. Such a manual trigger from the head-end LSR 800 of the inter-domain TE LSP is, however, not considered to be a frequent 801 occurrence. 803 Note that stitching or nesting rely on local optimization: the 804 reoptimization process allows to locally reoptimize each TE LSP segment 805 or FA-LSP: hence, the reoptimization is not global and consequently the 806 end to end path may no longer to optimal, should it be optimal when set 807 up. 809 Procedures described in [LOOSE-REOPT] MUST be used if the operator does 810 not desire local re-optimization of certain inter-domain LSPs. In this 811 case, any re-optimization event within the domain MUST be reported to 812 the head-end node. This SHOULD be a configurable policy. 814 8. Security Considerations 816 Vasseur, Ayyangar and Zhang 16 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 9. Intellectual Property Considerations 824 The IETF takes no position regarding the validity or scope of any 825 Intellectual Property Rights or other rights that might be claimed to 826 pertain to the implementation or use of the technology described in 827 this document or the extent to which any license under such rights 828 might or might not be available; nor does it represent that it has 829 made any independent effort to identify any such rights. Information 830 on the procedures with respect to rights in RFC documents can be 831 found in BCP 78 and BCP 79. 833 Copies of IPR disclosures made to the IETF Secretariat and any 834 assurances of licenses to be made available, or the result of an 835 attempt made to obtain a general license or permission for the use of 836 such proprietary rights by implementers or users of this 837 specification can be obtained from the IETF on-line IPR repository at 838 http://www.ietf.org/ipr. 840 The IETF invites any interested party to bring to its attention any 841 copyrights, patents or patent applications, or other proprietary 842 rights that may cover technology that may be required to implement 843 this standard. Please address the information to the IETF at ietf- 844 ipr@ietf.org.. 846 IPR Disclosure Acknowledgement 848 By submitting this Internet-Draft, I certify that any applicable 849 patent or other IPR claims of which I am aware have been disclosed, 850 and any of which I become aware will be disclosed, in accordance with 851 RFC 3668. 853 10. Acknowledgments 855 We would like to acknowledge input and helpful comments from Adrian 856 Farrel. 858 11 References 860 10.1. Normative References 862 [RFC] Bradner, S., "Key words for use in RFCs to indicate requirements 863 levels", RFC 2119, March 1997. 865 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 866 3667, February 2004. 868 Vasseur, Ayyangar and Zhang 17 869 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 870 Technology", BCP 79, RFC 3668, February 2004. 872 [RSVP] Braden, et al, " Resource ReSerVation Protocol (RSVP) � Version 873 1, Functional Specification�, RFC 2205, September 1997. 875 [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 876 3209, December 2001. 878 [REFRESH-REDUCTION] Berger et al, �RSVP Refresh Overhead Reduction 879 Extensions�, RFC2961, April 2001. 881 [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for 882 LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, December 883 2003. 885 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 886 Extensions to OSPF Version 2", RFC 3630, September 2003. 888 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", 889 RFC 3784, June 2004. 891 10.2. Informative references 893 [INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J., "Requirements 894 for inter-area MPLS Traffic Engineering", draft-ietf-tewg-interarea- 895 mpls-te-req-03.txt, work in progress. 897 [INT-AS-REQ] Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic 898 Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req-09.txt, 899 work in progress. 901 [INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A Framework 902 for Inter-Domain MPLS Traffic Engineering", draft-ietf-ccamp-inter- 903 domain-framework-00.txt, work in progress. 905 [FACILITY-BACKUP] Le Roux, J.L., Vasseur, J.P. et al. "Framework for 906 PCE based MPLS Facility Backup Path Computation", draft-leroux-pce- 907 backup-comp-frwk-00.txt, work in progress 909 [INTER-DOMAIN-SIG] Ayyangar, A., Vasseur, JP. �Inter-domain MPLS 910 Traffic Engineering � RSVP extensions�, draft-ietf-ccamp-inter-domain- 911 rsvp-te, work in progress. 913 [LSP-STITCHING] Ayyangar, A., Vasseur, JP. �Label Switched Path 914 Stitching with Generalized MPLS Traffic Engineering�, draft-ietf-ccamp- 915 lsp-stitching-00, Work under progress. 917 Vasseur, Ayyangar and Zhang 18 918 [LSP-ATTRIBUTE] Farrel A. et al, "Encoding of Attributes for 919 Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) 920 Establishment Using RSVP-TE", draft-ietf-mpls-rsvpte-attributes-04,(work 921 in progress). 923 [GMPLS-OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay 924 Model", (work in progress). 926 [EXCLUDE-ROUTE] Lee et all, Exclude Routes - Extension to RSVP-TE, 927 draft-ietf-ccamp-rsvp-te-exclude-route-00.txt, work in progress. 929 [LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D.,Swallow, G., 930 Wadhwa, S., Bonica, R., " Detecting Data Plane Liveliness in MPLS", 931 Internet Draft , October 2002. (Work 932 in Progress) 934 [MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS 935 Networks", RFC 3443 Updates RFC 3032) ", January 2003 937 [LOOSE-PATH-REOPT] Vasseur, Ikejiri and Zhang �Reoptimization of an 938 explicit loosely routed MPLS TE paths�, draft-ietf-ccamp-loose-path- 939 reopt-01.txt, July 2004, Work in Progress. 941 [NODE-ID] Vasseur, Ali and Sivabalan, �Definition of an RRO node-id 942 subobject�, draft-ietf-mpls-nodeid-subobject-05.txt, work in progress. 944 [LSP-HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized 945 MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, March 2002. 947 [MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS 948 Networks", RFC 3443 (Updates RFC 3032) ", January 2003. 950 Authors' Address: 952 Jean-Philippe Vasseur (Editor) 953 Cisco Systems, Inc. 954 300 Beaver Brook Road 955 Boxborough , MA - 01719 956 USA 957 Email: jpv@cisco.com 959 Arthi Ayyangar (Editor) 960 Juniper Networks, Inc 961 1194 N.Mathilda Ave 962 Sunnyvale, CA 94089 963 USA 964 e-mail: arthi@juniper.net 966 Vasseur, Ayyangar and Zhang 19 967 Raymond Zhang 968 Infonet Services Corporation 969 2160 E. Grand Ave. 970 El Segundo, CA 90025 971 USA 972 Email: raymond_zhang@infonet.com 974 Full Copyright Statement 976 Copyright (C) The Internet Society (2005). This document is subject to 977 the rights, licenses and restrictions contained in BCP 78, and except 978 as set forth therein, the authors retain all their rights. 980 This document and the information contained herein are provided on an 981 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 982 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 983 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 984 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 985 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 986 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 988 Vasseur, Ayyangar and Zhang 20