idnits 2.17.1 draft-ietf-mpls-soft-preemption-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (July 29, 2009) is 5377 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) == Outdated reference: A later version (-06) exists of draft-ietf-mpls-3209-patherr-04 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-gmpls-lsp-reroute-04 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group Matthew. Meyer, Ed. 3 Internet-Draft British Telecom 4 Intended status: Standards Track JP. Vasseur, Ed. 5 Expires: January 30, 2010 Cisco Systems, Inc 6 July 29, 2009 8 MPLS Traffic Engineering Soft Preemption 9 draft-ietf-mpls-soft-preemption-18.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 30, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document specifies Multiprotocol Label Switching (MPLS) Traffic 48 Engineering Soft Preemption, a suite of protocol modifications 49 extending the concept of preemption with the goal of reducing/ 50 eliminating traffic disruption of preempted Traffic Engineering Label 51 Switched Paths (TE LSPs). Initially MPLS RSVP-TE was defined 52 supporting only immediate TE LSP displacement upon preemption. The 53 utilization of a reroute request notification helps more gracefully 54 mitigate the re-route process of preempted TE LSP. For the brief 55 period soft preemption is activated, reservations (though not 56 necessarily traffic levels) are in effect under-provisioned until the 57 TE LSP(s) can be re-routed. For this reason, the feature is 58 primarily but not exclusively interesting in MPLS enabled IP networks 59 with Differentiated Services and Traffic Engineering capabilities. 61 Requirements Language 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC 2119 [RFC2119]. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 4 72 2.2. Nomenclature . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4. RSVP Extensions . . . . . . . . . . . . . . . . . . . . . . . 6 75 4.1. SESSION-ATTRIBUTE Flags . . . . . . . . . . . . . . . . . 6 76 4.2. Path Error - "Reroute request Soft Preemption" Error 77 Value . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 5. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 6 79 6. Elements Of Procedures . . . . . . . . . . . . . . . . . . . . 8 80 6.1. On a Soft Preempting LSR . . . . . . . . . . . . . . . . . 8 81 6.2. On Head-end LSR of a Soft Preempted TE LSP . . . . . . . . 10 82 7. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 10 83 8. Management . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 85 9.1. New Session Attribute Object Flag . . . . . . . . . . . . 12 86 9.2. New error sub-code value . . . . . . . . . . . . . . . . . 12 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 89 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 90 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 13.1. Normative References . . . . . . . . . . . . . . . . . . . 13 92 13.2. Informative References . . . . . . . . . . . . . . . . . . 13 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 95 1. Introduction 97 In an Multiprotocol Label Switching (MPLS) Resource Reservation 98 Protocol Traffic Engineering (RSVP-TE) (see [RFC3209]) enabled IP 99 network, hard preemption is the default behavior. Hard preemption 100 provides no mechanism to allow preempted Traffic Engineering Label 101 Switched Paths (TE LSPs) to be handled in a make-before-break 102 fashion: the hard preemption scheme instead utilizes a very intrusive 103 method that can cause traffic disruption for a potentially large 104 amount of TE LSPs. Without an alternative, network operators either 105 accept this limitation, or remove functionality by using only one 106 preemption priority or using invalid bandwidth reservation values. 107 Understandably desirable features like ingress (Label Edge Router) 108 LER automated (Traffic Engineering (TE) reservation adjustments are 109 less palatable when preemption is intrusive and high network 110 stability levels are a concern. 112 This document defines the use of additional signaling and maintenance 113 mechanisms to alert the ingress LER of the preemption that is pending 114 and allow for temporary control plane under-provisioning while the 115 preempted tunnel is re-routed in a non disruptive fashion (make- 116 before-break) by the ingress LER. During the period that the tunnel 117 is being re-routed, link capacity is under-provisioned on the 118 midpoint where preemption initiated and potentially one or more links 119 upstream along the path where other soft preemptions may have 120 occurred. 122 2. Terminology 124 This document follows the nomenclature of the MPLS Architecture 125 defined in [RFC3031]. 127 2.1. Acronyms and Abbreviations 129 CSPF: Constrained Shortest Path First. 131 DS: Differentiated Services. 133 LER: Label Edge Router. 135 LSR: Label Switching Router. 137 LSP: Label Switched Path. 139 MPLS: MultiProtocol Label Switching. 141 RSVP: Resource ReSerVation Protocol. 143 TE LSP: Traffic Engineering Label Switched Path. 145 2.2. Nomenclature 147 Point of Preemption - the midpoint or ingress LSR which due to RSVP 148 provisioning levels is forced to either hard preempt or under- 149 provision and signal soft preemption. 151 Hard Preemption - The (typically default) preemption process in which 152 higher numeric priority TE LSPs are intrusively displaced at the 153 point of preemption by lower numeric priority TE LSPs. In hard 154 preemption the TE LSP is torn down before reestablishment. 156 3. Motivations 158 Initially Multiprotocol Label Switching (MPLS) RSVP-TE [RFC3209] was 159 defined supporting only one method of TE LSP preemption which 160 immediately tears down TE LSPs, disregarding the preempted in-transit 161 traffic. This simple but abrupt process nearly guarantees preempted 162 traffic will be discarded, if only briefly, until the RSVP Path Error 163 message reaches and is processed by the ingress LER and a new data 164 path can be established. The Error Code and Error Values carried 165 within the RSVP Path Error message to report a preemption action are 166 documented in [I-D.ietf-mpls-3209-patherr]. Note that such 167 preemption is also referred to as a fatal error in 168 [I-D.ietf-mpls-3209-patherr]. In cases of actual resource contention 169 this might be helpful, however preemption may be triggered by mere 170 reservation contention and reservations may not reflect data plane 171 contention up to the moment. The result is that when conditions that 172 promote preemption exist and hard preemption is the default behavior, 173 inferior priority preempted traffic may be needlessly discarded when 174 sufficient bandwidth exists for both the preempted Traffic 175 Engineering Labeled Switched Path (TE LSP) and the preempting TE 176 LSP(s). 178 Hard preemption may be a requirement to protect numerically lower 179 preemption priority traffic in a non Diff-Serv enabled architecture, 180 but in a Diff-Serv enabled architecture, one need not rely 181 exclusively upon preemption to enforce a preference for the most 182 valued traffic since the marking and queuing disciplines should 183 already be aligned for those purposes. Moreover, even in non Diff- 184 Serv aware networks, depending on the TE LSP sizing rules (imagine 185 all LSPs are sized at double their observed traffic level), 186 reservation contention may not accurately reflect the potential for 187 data plane congestion. 189 4. RSVP Extensions 191 4.1. SESSION-ATTRIBUTE Flags 193 To explicitly signal the desire for a TE LSP to benefit from the soft 194 preemption mechanism (and so not to be hard preempted if the soft 195 preemption mechanism is available), the following flag of the 196 SESSION-ATTRIBUTE object (for both the C-Type 1 and 7) is defined: 198 Soft Preemption Desired bit 199 Bit Flag Name Flag 200 0x40 Soft Preemption Desired 202 4.2. Path Error - "Reroute request Soft Preemption" Error Value 204 [I-D.ietf-mpls-gmpls-lsp-reroute] specifies defines a new reroute- 205 specific error code that allows a mid-point to report a TE LSP 206 reroute request (Error-code=34 - Reroute). This document specifies a 207 new error sub-code value for the case of Soft Preemption (to be 208 confirmed by IANA upon publication of this document). 210 Error-value Meaning Reference 211 1 Reroute Request Soft Preemption This document 213 Upon (soft) preemption, the preemting node MUST issue a PathErr 214 message with the error code=34 ("Reroute") and a value=1 ("Reroute 215 request soft preemption"), to be confirmed by IANA. 217 5. Mode of Operation 219 Let's consider the following example: 221 R0--1G--R1---155----R2 222 | \ | 223 | \ 155 224 | \ | 225 155 1G R3 226 | \ | 227 | \ 155 228 | \| 229 R4----1G----R5 231 LSP1: LSP2: 233 R0-->R1 R1<--R2 234 \ | 235 V V 236 R5 R4 238 Figure 1: Example of Soft Preemption Operation 240 In the network depicted above in figure 1, consider the following 241 conditions: 243 o Reservable BW on R0-R1, R1-R5 and R4-R5 is 1Gb/sec. 245 o Reservable BW on R1-R2, R1-R4, R2-R3, R3-R5 is 155 Mb/sec. 247 o Bandwidths and costs are identical in both directions. 249 o Each circuit has an IGP metric of 10 and IGP metric is used by 250 CSPF. 252 o Two TE tunnels are defined: - LSP1: 155 Mb, setup/hold priority 0 253 tunnel, path R0-R1-R5. - LSP2: 155 Mb, setup/hold priority 7 254 tunnel, path R2-R1-R4. Both TE LSPs are signaled with the soft 255 preemption desired bit of their SESSION-ATTRIBUTE object set. 257 o Circuit R1-R5 fails 259 o Soft Preemption is functional. 261 When the circuit R1-R5 fails, R1 detects the failure and sends an 262 updated IGP LSA/LSP and Path Error message to all the head-end LSRs 263 having a TE LSP traversing the failed link (R0 in the example above). 264 Either form of notification may arrive at the head-end LSRs first. 265 Upon receiving the link failure notification, R0 triggers a TE LSP 266 re-route of LSP1, and re-signals LSP1 along shortest path available 267 satisfying the TE LSP constraints: R0-R1-R4-R5 path. The Resv 268 messages for LSP1 travel in the upstream direction (from the 269 destination to the head-end LSR - R5 to R0 in this example). LSP2 is 270 soft preempted at R1 as it has a numerically lower priority value and 271 both bandwidth reservations cannot be satisfied on the R1-R4 link. 273 Instead of sending a path tear for LSP2 upon preemption as with hard 274 preemption (which would result in an immediate traffic disruption for 275 LSP2), R1s local bandwidth accounting for LSP2 is zeroed and a 276 PathErr message with error code "Reroute" and a value "Reroute 277 request soft preemption" for LSP2 is issued. 279 Upon reception of the PathErr message for LSP2, R2 may update the 280 working copy of the TE-DB before running calculating a new path for 281 the new LSP. In the case that Diff-Serv [RFC3270] and TE [RFC3209] 282 are deployed, receiving a preemption pending notification may imply 283 to a head-end LSR that the available bandwidth for the affected 284 priority level and numerically greater priority levels has been 285 exhausted for the indicated node interface. R2 may choose to reduce 286 or zero available bandwidth for the implied priority range until more 287 accurate information is available (i.e. a new IGP TE update is 288 received). It follows that R2 re-computes a new path and performs a 289 non traffic disruptive rerouting of the new TE LSP T2 by means of the 290 make-before-break procedure. The old path is then torn down. 292 6. Elements Of Procedures 294 6.1. On a Soft Preempting LSR 296 When a new TE LSP is signaled which requires to preempt a set of TE 297 LSP(s) because not all TE LSPs can be accommodated on a specific 298 interface, a node triggers a preemption action which consists of 299 selecting the set of TE LSPs that must be preempted so as to free up 300 some bandwidth in order to satisfy the newly signaled numerically 301 lower preemption TE LSP. 303 With hard preemption, when a TE LSP is preempted, the preempting node 304 sends an RSVP PathErr message notifiying a fatal action as documented 305 in [I-D.ietf-mpls-3209-patherr]. Upon receiving the RSVP PathErr 306 message, the head-end LSR sends an RSVP Path Tear message, which 307 would result in an immediate traffic disruption for the preempted TE 308 LSP). By contrast, the mode of operation with soft preemption is as 309 follows: the preempting node's local bandwidth accounting for the 310 preempted TE LSP is zeroed and a PathErr with error code "Reroute" 311 and a error value "Reroute request soft preemption" for that TE LSP 312 is issued upstream toward the head-end LSR. 314 If more than one soft preempted TE LSP has the same head-end LSR, 315 these soft preemption PathErr notification messages may be bundled 316 together. 318 The preempting node MUST immediately send a PathErr with error code 319 "Reroute" and a error value "Reroute request soft preemption" for 320 each soft preempted TE LSP. The node MAY use the occurrence of soft 321 preemption to trigger an immediate IGP update or influence the 322 scheduling of an IGP update. 324 To guard against a situation where bandwidth under-provisioning will 325 last forever, a local timer (named the "Soft preemption timer") MUST 326 be started on the preemption node, upon soft preemption. If this 327 timer expires, the preempting node SHOULD send an RSVP PathTear and 328 either a ResvTear message or a PathErr with the 'Path_State_Removed' 329 flag set. 331 Should a refresh event for a soft preempted TE LSP arrive before the 332 soft preemption timer expires, the soft preempting node MUST continue 333 to refresh the TE LSP. 335 When the MESSAGE-ID extensions defined in [RFC2961] are available and 336 enabled, PathErr messages with error code "Reroute" and an error 337 value "Reroute request soft preemption" SHOULD be sent in reliable 338 mode. 340 The preempting node MAY preempt TE LSPs which have a numerically 341 higher Holding priority than the Setup priority of the newly admitted 342 LSP. Within the same priority, it SHOULD attempt to pre-empt LSPs 343 with the "Soft Preemption Desired" bit of the SESSION ATTRIBUTE 344 object cleared, i.e., TE LSP considered as Hard Preemptable, first. 346 Selection of the preempted TE LSP at a preempting mid-point: when a 347 numerically lower priority TE LSP is signaled that requires the 348 preemption of a set of numerically higher priority LSPs, the node 349 where preemption is to occur has to make a decision on the set of TE 350 LSP(s), candidates for preemption. This decision is a local decision 351 and various algorithms can be used, depending on the objective (e.g, 352 see [RFC4829]). As already mentioned, soft preemption causes a 353 temporary link under provisioning condition while the soft preempted 354 TE LSPs are rerouted by their respective head-end LSRs. In order to 355 reduce this under provisioning exposure, a soft-preempting LSR MAY 356 check first if there exists soft preemptable TE LSP bandwidth flagged 357 by another node but still available for soft-preemption locally. If 358 sufficient overlap bandwidth exists the LSR MAY attempt to soft 359 preempt the same TE LSP. This would help reducing the temporarily 360 elevated under-provisioning ratio on the links where soft preemption 361 occurs and the number of preempted TE LSPs. Optionally, a midpoint 362 LSR upstream or downstream from a soft preempting node MAY choose to 363 flag the TE LSPs soft preempted state. In the event a local 364 preemption is needed, the relevant priority level LSPs from the cache 365 are soft preempted first, followed by the normal soft and hard 366 preemption selection process for the given priority. 368 Under specific circumstances such as unacceptable link congestion, a 369 node MAY decide to hard preempt a TE LSP (by sending a fatal Path 370 Error message, a PathTear and either a ResvTear or a Path Error 371 message with the 'Path_State_Removed' flag set) even if its head-end 372 LSR explicitly requested 'soft preemption' ('Soft Preemption desired' 373 flag of the corresponding SESSION-ATTRIBUTE object set). Note that 374 such decision MAY also be taken for TE LSPs under soft preemption 375 state. 377 6.2. On Head-end LSR of a Soft Preempted TE LSP 379 Upon reception of a PathErr message with error code "Reroute" and an 380 error value "Reroute request soft preemption", the head-end LSR MAY 381 first update the working copy of the TE-DB before computing a new 382 path (e.g by running CSPF) for the new LSP. In the case that Diff- 383 Serv [RFC3270] and MPLS Traffic Engineering [RFC3209] are deployed, 384 receiving preemption pending may imply to a head-end LSR that the 385 available bandwidth for the affected priority level and numerically 386 greater priority levels has been exhausted for the indicated node 387 interface. A head-end LSR MAY choose to reduce or zero available 388 bandwidth for the implied priority range until more accurate 389 information is available (i.e., a new IGP TE update is received). 391 Once a new path has been computed, the soft preempted TE LSP is 392 rerouted using the non traffic disruptive make-before-break 393 procedure. The amount of time the head-end node avoids using the 394 node interface identified by the IP address contained in the PathErr 395 is based on a local decision at head-end node. 397 As a result of soft preemption, no traffic will be needlessly black 398 holed due to mere reservation contention. If loss is to occur, it 399 will be due only to an actual traffic congestion scenario and 400 according to the operators Diff-Serv (if Diff-Serv is deployed) and 401 queuing scheme. 403 7. Interoperability 405 Backward compatibility should be assured as long as the 406 implementation followed the recommendations set forth in [RFC3209]. 408 As mentioned previously, to guard against a situation where bandwidth 409 under-provisioning will last forever, a local timer (soft preemption 410 timer) MUST be started on the preemption node, upon soft preemption. 411 When this timer expires, the soft preempted TE LSP SHOULD be hard 412 preempted by sending a fatal Path Error message, a PathTear message 413 and either a ResvTear message or a PathErr message with the 414 'Path_State_Removed' flag set. This timer SHOULD be configurable and 415 a default value of 30 seconds is RECOMMENDED. 417 It is RECOMMENDED that configuring the default preemption timer to 0 418 will cause the implementation to use hard-preemption. 420 Soft Preemption as defined in this document is designed for use in 421 MPLS RSVP-TE enabled IP Networks and may not functionally translate 422 to some GMPLS technologies. As with backward compatibility, if a 423 device does not recognize a flag, it should pass the subobject 424 transparently. 426 8. Management 428 Both the point of preemption and the ingress LER SHOULD provide some 429 form of accounting internally and to the network operator interface 430 with regard to which TE LSPs and how much capacity is under- 431 provisioned due to soft preemption. Displays of under-provisioning 432 are recommended for the following midpoint, ingress and egress views: 434 o Sum of current bandwidth per preemption priority per local 435 interface 437 o Sum of current bandwidth total per local interface 439 o Sum of current bandwidth total local router (ingress, egress, 440 midpoint) 442 o List current LSPs and bandwidth in PPend status 444 o List current sum bandwidth and session count in PPend status per 445 observed ERO hops (ingress, egress views only). 447 o Cumulative PPend events per observed ERO hops. 449 9. IANA Considerations 451 IANA will not need to create a new registry. 453 9.1. New Session Attribute Object Flag 455 A new flag of the Session Attribute object is defined (to be 456 confirmed by IANA) 458 Soft Preemption Desired bit 459 Bit Flag Name Flag Reference 460 0x40 Soft Preemption Desired This document 462 9.2. New error sub-code value 464 [I-D.ietf-mpls-gmpls-lsp-reroute] defines a new reroute-specific 465 error code that allows a mid-point to report a TE LSP reroute 466 request. This document specifies a new error sub-code value for the 467 case of Soft Preemption (to be confirmed by IANA upon publication of 468 this document). 470 Error-value Meaning Reference 471 1 Reroute Request Soft Preemption This document 473 10. Security Considerations 475 This document does not introduce new security issues. The security 476 considerations pertaining to the original RSVP protocol [RFC3209] 477 remain relevant. 479 11. Acknowledgements 481 The authors would like to thank Carol Iturralde, Dave Cooper, Loa 482 Andersson, Arthi Ayyangar, Ina Minei, George Swallow, Adrian Farrel 483 and Mustapha Aissaoui for their valuable comments. 485 12. Authors' Addresses 487 The content of this document was contributed by the editors and the 488 co-authors listed below: 490 Denver Maddux 491 Limelight Networks 492 USA 493 email: denver@nitrous.net 495 Curtis Villamizar 496 AVICI 497 curtis@faster-light.net 499 Amir Birjandi 500 Juniper Networks 501 2251 corporate park dr ste 502 herndon, VA 20171 503 USA 504 abirjandi@juniper.net 506 13. References 508 13.1. Normative References 510 [I-D.ietf-mpls-3209-patherr] 511 Vasseur, J., Swallow, G., and I. Minei, "Node behavior 512 upon originating and receiving Resource ReserVation 513 Protocol (RSVP) Path Error message", 514 draft-ietf-mpls-3209-patherr-04 (work in progress), 515 February 2009. 517 [I-D.ietf-mpls-gmpls-lsp-reroute] 518 Berger, L., Papadimitriou, D., and J. Vasseur, "PathErr 519 Message Triggered MPLS and GMPLS LSP Reroute", 520 draft-ietf-mpls-gmpls-lsp-reroute-04 (work in progress), 521 January 2009. 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, March 1997. 526 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 527 Label Switching Architecture", RFC 3031, January 2001. 529 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 530 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 531 Tunnels", RFC 3209, December 2001. 533 13.2. Informative References 535 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 536 and S. Molendini, "RSVP Refresh Overhead Reduction 537 Extensions", RFC 2961, April 2001. 539 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 540 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 541 Protocol Label Switching (MPLS) Support of Differentiated 542 Services", RFC 3270, May 2002. 544 [RFC4829] de Oliveira, J., Vasseur, JP., Chen, L., and C. Scoglio, 545 "Label Switched Path (LSP) Preemption Policies for MPLS 546 Traffic Engineering", RFC 4829, April 2007. 548 Authors' Addresses 550 Matthew R. Meyer (editor) 551 British Telecom 552 matthew.meyer@bt.com 554 Email: 556 JP Vasseur (editor) 557 Cisco Systems, Inc 558 11, Rue Camille Desmoulins 559 Issy Les Moulineaux, 92782 560 France 562 Email: jpv@cisco.com