idnits 2.17.1 draft-ietf-ccamp-loose-path-reopt-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 609. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 599. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (February 8, 2006) is 6645 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) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group JP. Vasseur, Ed. 2 Internet-Draft Cisco Systems, Inc 3 Proposed Status: Informational Y. Ikejiri 4 Expires: August 12, 2006 NTT Communications Corporation 5 R. Zhang 6 BT Infonet 7 February 8, 2006 9 Reoptimization of Multiprotocol Label Switching (MPLS) Traffic 10 Engineering (TE) loosely routed Label Switch Path (LSP) 12 draft-ietf-ccamp-loose-path-reopt-02.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 12, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document defines a mechanism for the reoptimization of loosely 46 routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) 47 Traffic Engineering (TE) LSPs signaled with RSVP-TE. This document 48 proposes a mechanism that allows a TE LSP head-end LSR to trigger a 49 new path re-evaluation on every hop having a next hop defined as a 50 loose or abstract hop and a mid-point LSR to signal to the head-end 51 LSR that a better path exists (compared to the current path in use) 52 or that the TE LSP must be reoptimized because of some maintenance 53 required on the TE LSP path. The proposed mechanism applies to the 54 cases of intra and inter-domain (IGP area or Autonomous System) 55 packet and non-packet TE LSPs following a loosely routed path. 57 Requirements Language 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 [RFC2119]. 63 Table of Contents 65 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Establishment of a loosely routed TE LSP . . . . . . . . . . . 4 68 4. Reoptimization of a loosely routed TE LSP path . . . . . . . . 6 69 5. Signalling extensions . . . . . . . . . . . . . . . . . . . . 6 70 5.1. Path re-evaluation request . . . . . . . . . . . . . . . . 7 71 5.2. New error value sub-codes . . . . . . . . . . . . . . . . 7 72 6. Mode of operation . . . . . . . . . . . . . . . . . . . . . . 7 73 6.1. Head-end reoptimization control . . . . . . . . . . . . . 7 74 6.2. Reoptimization triggers . . . . . . . . . . . . . . . . . 8 75 6.3. Head-end request versus mid-point explicit 76 notification functions . . . . . . . . . . . . . . . . . . 8 77 6.3.1. Head-end request function . . . . . . . . . . . . . . 8 78 6.3.2. Mid-point explicit notification . . . . . . . . . . . 9 79 6.3.3. ERO caching . . . . . . . . . . . . . . . . . . . . . 10 80 7. Applicability and Interoperability . . . . . . . . . . . . . . 10 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 88 Intellectual Property and Copyright Statements . . . . . . . . . . 14 90 1. Terminology 92 Terminology used in this document 94 ABR: Area Border Router. 96 ERO: Explicit Route Object. 98 LSR: Label Switch Router. 100 TE LSP: Traffic Engineering Label Switched Path. 102 TE LSP head-end: head/source of the TE LSP. 104 TE LSP tail-end: tail/destination of the TE LSP. 106 IGP Area: OSPF Area or IS-IS level. 108 Intra-area TE LSP: TE LSP whose path does not transit across areas. 110 Inter-area TE LSP: A TE LSP whose path transits across at least two 111 different IGP areas. 113 Inter-AS MPLS TE LSP: A TE LSP whose path transits across at least 114 two different ASs or sub-ASs (BGP confederations). 116 2. Introduction 118 This document defines a mechanism for the reoptimization of loosely 119 routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) 120 Traffic Engineering LSPs signaled with RSVP-TE (see [RFC3209] and 121 [RFC3473]). A loosely routed LSP is defined as one that does not 122 contain a full explicit route identifying each LSR along the path of 123 the LSP at the time it is signaled by the ingress LSR. Such an LSP 124 is signaled with no ERO, with an ERO that contains at least one loose 125 hop, or with an ERO that contains an abstract node that is not a 126 simple abstract node (that is, an abstract node that identifies more 127 than one LSR). 129 The Traffic Engineering Working Group (TE WG) has specified a set of 130 requirements for inter-area and inter-AS MPLS Traffic Engineering 131 (see [RFC4105] and [RFC4216]). Both requirements documents specify 132 the need for some mechanism providing an option for the head-end to 133 control the reoptimization process should a more optimal path exist 134 in a downstream domain (IGP area or Autonomous System). This 135 document defines a solution to meet this requirement and proposes two 136 mechanisms: 138 (1) The first mechanism allows a head-end LSR to trigger a new path 139 re-evaluation on every hop having a next hop defined as a loose hop 140 or abstract node and get a notification from the mid-point on whether 141 a better path exists. 143 (2) The second mechanism allows a mid-point LSR to explicitly signal 144 to the head-end LSR that either a better path exists to reach a 145 loose/abstract hop (compared to the current path in use) or that the 146 TE LSP must be reoptimized because of some maintenance required along 147 the TE LSP path. In this case, the notification is sent by the mid- 148 point LSR without being polled by the head-end LSR. 150 A better path is defined as a lower cost path, where the cost is 151 determined by the metric used to compute the path. 153 3. Establishment of a loosely routed TE LSP 155 The aim of this section is purely to remind the mechanisms involved 156 in the establishment of a loosely routed TE LSP (in line with 157 [RFC3209]) and does not introduce any new protocol extensions or 158 mechanisms. 160 In the context of this document, a loosely routed LSP is defined as 161 one that does not contain a full explicit route identifying each LSR 162 along the path of the LSP at the time it is signaled by the ingress 163 LSR. Such an LSP is signaled with no ERO, with an ERO that contains 164 at least one loose hop, or with an ERO that contains an abstract node 165 that is not a simple abstract node (that is, an abstract node that 166 identifies more than one LSR). As specified in [RFC3209], loose hops 167 are listed in the ERO object of the RSVP Path message with the L flag 168 of the IPv4 or the IPv6 prefix sub-object set. 170 Each LSR along the path whose next hop is specified as a loose hop or 171 a non-specific abstract node triggers a path computation (also 172 referred to as an ERO expansion), before forwarding the RSVP Path 173 message downstream. The computed path may either be partial (up to 174 the next loose hop) or complete (set of strict hops up to the TE LSP 175 destination). 177 Note that the examples in the rest of this document are provided in 178 the context of MPLS inter-area TE but the proposed mechanism equally 179 applies to loosely routed paths within a single routing domain and 180 across multiple Autonomous Systems. The examples below are provided 181 with OSPF as the IGP but the described set of mechanisms similarly 182 apply to IS-IS. 184 An example of an explicit loosely routed TE LSP signaling. 186 <---area 1--><-area 0--><-area 2-> 188 R1---R2----R3---R6 R8---R10 189 | | | / | \ | 190 | | | / | \ | 191 | | | / | \| 192 R4---------R5---R7----R9---R11 194 Assumptions 196 - R3, R5, R8 and R9 are ABRs 198 - The path of an inter-area TE LSP T1 from R1 (head-end LSR) to R11 199 (tail-end LSR) is defined on R1 as the following loosely routed path: 200 R1-R3(loose)-R8(loose)-R11(loose). R3, R8 and R11 are defined as 201 loose hops. 203 Step 1: R1 determines that the next hop (R3) is a loose hop (not 204 directly connected to R1) and then performs an ERO expansion 205 operation to reach the next loose hops R3. The new ERO becomes: 206 R2(S)-R3(S)-R8(L)-R11(L) where: S: Strict hop (L=0) L: Loose hop 207 (L=1) 209 The R1-R2-R3 path satisfies T1's set of constraints. 211 Step 2: the RSVP Path message is then forwarded by R1 following the 212 path specified in the ERO object and reaches R3 with the following 213 content: R8(L)-R11(L). 215 Step 3: R3 determines that the next hop (R8) is a loose hop (not 216 directly connected to R3) and then performs an ERO expansion 217 operation to reach the next loose hops R8. The new ERO becomes: 218 R6(S)-R7(S)-R8(S)-R11(L). 220 Note: in this example, the assumption is made that the path is 221 computed on a per loose hop basis, also referred to a partial route 222 computation. Note that other path computation techniques may result 223 in complete paths (set of strict hops up to the final destination). 225 Step 4: the same procedure is repeated by R8 to reach T1's 226 destination (R11). 228 4. Reoptimization of a loosely routed TE LSP path 230 Once a loosely routed explicit TE LSP is set up, it is maintained 231 through normal RSVP procedures. During TE LSP life time, a more 232 optimal path might appear between an LSR and its next loose hop (for 233 the sake of illustration, suppose in the example above that a link 234 between R6 and R8 is added or restored that provides a preferable 235 path between R3 and R8 (R3-R6-R8) than the existing R3-R6-R7-R8 236 path). Since a preferable (e.g. shorter) path might not be visible 237 from the head-end LSR by means of the IGP if the head-end LSR does 238 not belong to the head-end IGP area, the head-end cannot make use of 239 this shorter path (and reroute the LSP using a make-before-break 240 technique as described in [RFC3209]) when appropriate. Hence, a new 241 mechanisms specified in this document is required to detect the 242 existence of such a preferable path and to notify the head-end LSR 243 accordingly. 245 This document defines a mechanism that allows: 247 - A head-end LSR to trigger on every LSR whose next hop is a loose 248 hop or an abstract node the re-evaluation of the current path in 249 order to detect a potentially more optimal path, 251 - A mid-point LSR whose next hop is a loose-hop or an abstract node 252 to signal (using a new Error value sub-code carried in a RSVP PERR 253 message) to the head-end LSR that a more preferable path exists (a 254 path with a lower cost, where the cost definition is determined by 255 some metric). 257 Once the existence of such a preferable path has been notified to the 258 head-end LSR, the head-end LSR can decide (depending on the TE LSP 259 characteristics) whether to perform a TE LSP graceful reoptimization 260 such as the "make-before-break" procedure. 262 There is another scenario whereby notifying the head-end LSR of the 263 existence of a better path is desirable: if the current path is about 264 the fail due to some (link or node) required maintenance. 266 This mechanism allows the head-end LSR to reoptimize a TE LSP making 267 use of the non disruptive make-before-break procedure if and only if 268 a preferable path exists and if such a reoptimization is desired. 270 5. Signalling extensions 272 A new flag in the SESSION ATTRIBUTE object and new Error value sub- 273 codes in the ERROR SPEC object are proposed in this document (to be 274 assigned by IANA). 276 5.1. Path re-evaluation request 278 The following new flag of the SESSION_ATTRIBUTE object (C-Type 1 and 279 7) is defined (suggested value to be confirmed by IANA): 281 Path re-evaluation request: 0x20 283 This flag indicates that a path re-evaluation (of the current path in 284 use) is requested. Note that this does not trigger any LSP Reroute 285 but instead just signals the request to evaluate whether a preferable 286 path exists. 288 Note: in case of link bundling for instance, although the resulting 289 ERO might be identical, this might give the opportunity for a mid- 290 point LSR to locally select another link within a bundle, although 291 strictly speaking, the ERO has not changed. 293 5.2. New error value sub-codes 295 As defined in [RFC3209], the ERROR-CODE 25 in ERROR-SPEC object 296 corresponds to a Notify Error. 298 This document adds three new error value sub-codes (suggested values 299 to be confirmed by IANA): 301 6 Preferable path exists 303 7 Local link maintenance required 305 8 Local node maintenance required 307 The details about the local maintenance required modes are detailed 308 in section 6.3.2. 310 6. Mode of operation 312 6.1. Head-end reoptimization control 314 The notification process of a preferable path (shorter path or new 315 path due to some maintenance required on the current path) is by 316 nature de-correlated from the reoptimization operation. In other 317 words, the location where a potentially preferable path is discovered 318 does not have to be where the TE LSP is actually reoptimized. This 319 document applies to the context of a head-end reoptimization. 321 6.2. Reoptimization triggers 323 There are several possible reoptimization triggers. For example, 324 such reoptimization triggers are: 326 - Timer-based: a reoptimization is triggered (process evaluating 327 whether a more optimal path can be found) when a configurable timer 328 expires, 330 - Event-driven: a reoptimization is triggered when a particular 331 network event occurs (such as a "Link-UP" event), 333 - Operator-driven: a reoptimization is manually triggered by the 334 Operator. 336 It is RECOMMENDED for an implementation supporting the extensions 337 proposed in this document to support the aforementioned modes as path 338 re-evaluation triggers. 340 6.3. Head-end request versus mid-point explicit notification functions 342 This document defines two functions: 344 1) "Head-end requesting function": the request for a new path 345 evaluation of a loosely routed TE LSP is requested by the head-end 346 LSR. 348 2) "Mid-point explicit notification function": a mid-point LSR having 349 determined that a preferable path (than the current path is use) 350 exists or having the need to perform a link/node local maintenance 351 explicitly notifies the head-end LSR that will in turn decide whether 352 to perform a reoptimization. 354 6.3.1. Head-end request function 356 When a timer-based reoptimization is triggered on the head-end LSR or 357 the operator manually requests a reoptimization, the head-end LSR 358 immediately sends an RSVP Path message with the "Path re-evaluation 359 request" bit of the SESSION-ATTRIBUTE object set. This bit is then 360 cleared in subsequent RSVP path messages sent downstream. In order 361 to handle the case of a lost Path message, the solution consists of 362 relying on the reliable messaging mechanism described in [RFC2961]. 364 Upon receiving a Path message with the "Path re-evaluation request" 365 bit set, every LSR for which the next abstract node contained in the 366 ERO is defined as a loose hop/abstract node performs the following 367 set of actions: 369 A path re-evaluation is triggered and the newly computed path is 370 compared to the existing path: 372 - If a preferable path can be found, the LSR performing the path re- 373 evaluation MUST immediately send an RSVP PErr to the head-end LSR 374 (Error code 25 (Notify), Error sub-code=6 (better path exists)). At 375 this point, the LSR MAY decide to not propagate such bit in 376 subsequent RSVP Path messages sent downstream for the re-evaluated TE 377 LSP: this mode is the RECOMMENDED mode for the reasons described 378 below. 380 The sending of an RSVP PERR Notify message "Preferable path exists" 381 to the head-end LSR will notify the head-end LSR of the existence of 382 a preferable path (e.g in a downstream area/AS or in another location 383 within a single domain). Hence, triggering additional path re- 384 evaluations on downstream nodes is unnecessary. The only motivation 385 to forward subsequent RSVP Path messages with the "Path re-evaluation 386 request" bit of the SESSION-ATTRIBUTE object set would be to trigger 387 path re-evaluation on downstream nodes that could in turn cache some 388 potentially better paths downstream with the objective to reduce the 389 signaling setup delay, should a reoptimization be performed by the 390 head-end LSR. 392 - If no preferable path can be found, the recommended mode is for an 393 LSR to relay the request (by setting the "Path re-evaluation" bit of 394 the SESSION-ATTRIBUTE object in RSVP path message sent downstream). 396 Note that, by preferable path, we mean a path having a lower cost. 398 If the RSVP Path message with the "Path re-evaluation request" bit 399 set is lost, then the next request will be sent when the next 400 reoptimization trigger will occur on the head-end LSR. The solution 401 to handle RSVP reliable messaging has been defined in [RFC2961]. 403 The network administrator may decide to establish some local policy 404 specifying to ignore such request or to consider those requests not 405 more frequently than a certain rate. 407 The proposed mechanism does not make any assumption of the path 408 computation method performed by the ERO expansion process. 410 6.3.2. Mid-point explicit notification 412 By contrast with the head-end request function, in this case, a mid- 413 point LSR whose next hop is a loose hop or an abstract node can 414 locally trigger a path re-evaluation when a configurable timer 415 expires, some specific events occur (e.g. link-up event for example) 416 or the user explicitly requests it. If a preferable path is found 417 compared to the path in use, the LSR sends an RSVP PERR to the head- 418 end LSR (Error code 25 (Notify), Error sub-code=6 ("preferable path 419 exists"). 421 There are other circumstances whereby any mid-point LSR MAY send an 422 RSVP PERR message with the objective for the TE LSP to be rerouted by 423 its head-end LSR: when a link or a node will go down for local 424 maintenance reasons. In this case, the LSR where a local maintenance 425 must be performed is responsible for sending an RSVP PERR message 426 with Error code 25 and Error sub-code=7 or 8 depending on the 427 affected network element (link or node). Then the first upstream 428 node having performed the ERO expansion MUST perform the following 429 set of actions: 431 - The link (sub-code=7) or the node (sub-code=8) MUST be locally 432 registered for further reference (the TE database must be updated) 434 - The RSVP PERR message MUST be immediately forwarded upstream to the 435 head-end LSR. Note that in the case of TE LSP spanning multiple 436 administrative domains, it may be desirable for the boundary LSR to 437 modify the RSVP PERR message and insert its own address for 438 confidentiality reason. 440 Upon receiving an RSVP PERR message with Error code 25 and Error sub- 441 code 7 or 8, the Head-end LSR SHOULD perform a TE LSP reoptimization. 443 Note that the two functions (head-end and mid-point driven) are not 444 exclusive from each other: both the timer and event-driven 445 reoptimization triggers can be implemented on the head-end and/or any 446 mid-point LSR with potentially different timer values for the timer 447 driven reoptimization case. 449 A head-end LSR MAY decide upon receiving an explicit mid-point 450 notification to delay its next path re-evaluation request. 452 6.3.3. ERO caching 454 Once a mid-point LSR has determined that a preferable path exists 455 (after a reoptimization request has been received by the head-end LSR 456 or the reoptimization timer on the mid-point has expired), the more 457 optimal path MAY be cached on the mid-point LSR for a limited amount 458 of time to avoid having to recompute a path once the head-LSR 459 performs a make-before-break. This mode is optional. A default 460 value for the caching timer of 5 seconds is suggested. 462 7. Applicability and Interoperability 463 The procedures described in this document are entirely optional 464 within an MPLS or GMPLS network. Implementations that do not support 465 the procedures described in this document will interoperate 466 seamlessly with those that do. Further, an implementation that does 467 not support the procedures described in this document will not be 468 impacted or implicated by a neighboring implementation that does 469 implement the procedures. 471 An ingress implementation that chooses not to support the procedures 472 described in this document may still achieve re-optimization by 473 periodically issuing a speculative make-before-break replacement of 474 an LSP without trying to discovery whether a more optimal path is 475 available in a downstream domain. Such a procedure would not be in 476 conflict with any mechanisms not already documented in [RFC3209] and 477 [RFC3473]. 479 An LSR not supporting the "Path re-evaluation request" bit of the 480 SESSION-ATTRIBUTE object SHALL forward it unmodified. 482 A head-end LSR not supporting an RSVP PERR with Error code 25 message 483 and Error sub-code = 6, 7 or 8 MUST just silently ignore such RSVP 484 PERR message. 486 8. IANA Considerations 488 IANA will assign a new flag named "Path re-evaluation request" in the 489 SESSION-ATTRIBUTE object (C-Type 1 and 7) specified in [RFC3209]. 490 Suggested value is (to be confirmed by IANA) 0x20. 492 IANA will also assign three new error sub-code values for the RSVP 493 PERR Notify message (Error code=25). Suggested values are (to be 494 confirmed by IANA): 496 6 Preferable path exists 498 7 Local link maintenance required 500 8 Local node maintenance required 502 9. Security Considerations 504 This document defines a mechanism for a mid-point LSR to notify the 505 head-end LSR of this existence of a preferable path or the need to 506 reroute the TE LSP for maintenance purposes. Hence, in case of a TE 507 LSP spanning multiple administrative domains, it may be desirable for 508 a boundary LSR to modify the RSVP PERR message (Code 25, Error sub- 509 code=6,7 or 8) so as to preserve confidentiality across domains. 510 Furthermore, a head-end LSR may decide to ignore explicit 511 notification coming from a mid-point residing in another domain. 512 Similarly, an LSR may decide to ignore (or accept but up to a pre- 513 defined rate) path re-evaluation requests originated by a head-end 514 LSR of another domain. 516 10. Acknowledgements 518 The authors would like to thank Carol Iturralde, Miya Kohno, Francois 519 Le Faucheur, Philip Matthews, Jim Gibson, Jean-Louis Le Roux, Kenji 520 Kumaki, Anca Zafir, Dimitri Papadimitriou for their useful comments. 521 A special thank to Adrian Farrel for his very valuable inputs. 523 11. References 525 11.1. Normative References 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, March 1997. 530 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 531 and S. Molendini, "RSVP Refresh Overhead Reduction 532 Extensions", RFC 2961, April 2001. 534 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 535 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 536 Tunnels", RFC 3209, December 2001. 538 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 539 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 540 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 542 11.2. Informative References 544 [RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for 545 Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. 547 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 548 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 549 November 2005. 551 Authors' Addresses 553 JP Vasseur (editor) 554 Cisco Systems, Inc 555 1414 Massachusetts Avenue 556 Boxborough, MA 01719 557 USA 559 Email: jpv@cisco.com 561 Yuichi Ikejiri 562 NTT Communications Corporation 563 1-1-6, Uchisaiwai-cho, Chiyoda-ku 564 Tokyo, 100-8019 565 Japan 567 Email: : y.ikejiri@ntt.com 569 Raymond Zhang 570 BT Infonet 571 2160 E. Grand Ave. 572 El Segundo, CA 90025 573 USA 575 Email: raymond_zhang@bt.infonet.com 577 Intellectual Property Statement 579 The IETF takes no position regarding the validity or scope of any 580 Intellectual Property Rights or other rights that might be claimed to 581 pertain to the implementation or use of the technology described in 582 this document or the extent to which any license under such rights 583 might or might not be available; nor does it represent that it has 584 made any independent effort to identify any such rights. Information 585 on the procedures with respect to rights in RFC documents can be 586 found in BCP 78 and BCP 79. 588 Copies of IPR disclosures made to the IETF Secretariat and any 589 assurances of licenses to be made available, or the result of an 590 attempt made to obtain a general license or permission for the use of 591 such proprietary rights by implementers or users of this 592 specification can be obtained from the IETF on-line IPR repository at 593 http://www.ietf.org/ipr. 595 The IETF invites any interested party to bring to its attention any 596 copyrights, patents or patent applications, or other proprietary 597 rights that may cover technology that may be required to implement 598 this standard. Please address the information to the IETF at 599 ietf-ipr@ietf.org. 601 Disclaimer of Validity 603 This document and the information contained herein are provided on an 604 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 605 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 606 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 607 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 608 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 609 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 611 Copyright Statement 613 Copyright (C) The Internet Society (2006). This document is subject 614 to the rights, licenses and restrictions contained in BCP 78, and 615 except as set forth therein, the authors retain all their rights. 617 Acknowledgment 619 Funding for the RFC Editor function is currently provided by the 620 Internet Society.