RFC 5712
MPLS Traffic Engineering Soft Preemption
MPLS Traffic Engineering Soft Preemption 💖
Okay bestie, here's the header tea 🎀. This is RFC 5712, published in January 2010 as a Standards Track document. The editors are M. Meyer, Ed. from British Telecom and JP. Vasseur, Ed. from Cisco Systems, Inc. It's catalogued under ISSN 2070-1721. The header doesn't list it as obsoleting or updating any other RFC, so it's standing on its own 💅.
Abstract ✨
So this doc spec's out MPLS Traffic Engineering Soft Preemption, a whole bundle of protocol changes that takes the idea of preemption and glows it up 🦋. The goal is to reduce, or even wipe out, the traffic disruption that happens to preempted Traffic Engineering Label Switched Paths (TE LSPs). Originally, MPLS RSVP-TE only had immediate TE LSP displacement on preemption, which is very much a "rip it off like a bandaid" energy 🙈. Using a reroute request notification helps the preempted TE LSP get rerouted more gracefully 🌸.
Here's the lowkey tricky part: for the short time soft preemption is switched on, reservations are under-provisioned (though traffic levels don't have to be) until the TE LSP(s) can get rerouted. That's why this feature is mainly, but not only, interesting in MPLS-enabled IP networks that have Differentiated Services and Traffic Engineering capabilities 🌈.
Status of This Memo ✨
This is an Internet Standards Track document 🎀.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 5741 📚.
Info about the current status of this document, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc5712 🔗.
Copyright Notice 💜
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 🌸.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please actually read these, because they spell out your rights and restrictions for this document 🫶. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.
Table of Contents 📑
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Acronyms and Abbreviations .................................3
2.2. Nomenclature ...............................................4
2.3. Requirements Language ......................................4
3. Motivations .....................................................4
4. RSVP Extensions .................................................5
4.1. SESSION-ATTRIBUTE Flags ....................................5
4.2. Path Error - "Reroute Request Soft Preemption"
Error Value ................................................5
5. Mode of Operation ...............................................6
6. Elements Of Procedures ..........................................7
6.1. On a Soft Preempting LSR ...................................7
6.2. On Head-end LSR of a Soft Preempted TE LSP .................9
7. Interoperability ...............................................10
8. Management .....................................................10
9. IANA Considerations ............................................11
9.1. New Session Attribute Object Flag .........................11
9.2. New Error Sub-Code Value ..................................11
10. Security Considerations .......................................11
11. Acknowledgements ..............................................12
12. Contributors ..................................................12
13. References ....................................................12
13.1. Normative References .....................................12
13.2. Informative References ...................................131. Introduction 🦋
Okay, so picture an MPLS Resource Reservation Protocol Traffic Engineering (RSVP-TE) enabled IP network (see [RFC3209]). In that network, hard preemption is the default behavior 💀. Hard preemption has no mechanism for handling preempted TE LSPs in a make-before-break fashion. Instead it uses a very intrusive method that can cause traffic disruption for a potentially large number of TE LSPs 😭. Without an alternative, network operators either just accept that limitation, or they lose functionality by using only one preemption priority or by using invalid bandwidth reservation values 🙈.
It's giving "understandably desirable features are less palatable." Stuff like TE reservation adjustments that the ingress Label Edge Router (LER) automates is less appealing when preemption is intrusive and keeping network stability high is a concern 🥺.
So this document defines extra signaling and maintenance mechanisms 💅. They alert the ingress LER that a preemption is pending, and they allow temporary control-plane under-provisioning while the preempted tunnel gets rerouted in a non-disruptive, make-before-break way by the ingress LER ✨. While the tunnel is being rerouted, link capacity is under-provisioned at the midpoint where preemption started, and possibly on one or more links upstream along the path where other soft preemptions may have happened 🌈.
2. Terminology 📚
This document follows the nomenclature of the MPLS Architecture defined in [RFC3031] 💖.
2.1. Acronyms and Abbreviations 🔤
CSPF: Constrained Shortest Path First.
DS: Differentiated Services.
LER: Label Edge Router.
LSR: Label Switching Router.
LSP: Label Switched Path.
MPLS: MultiProtocol Label Switching.
RSVP: Resource ReSerVation Protocol.
TE LSP: Traffic Engineering Label Switched Path.
2.2. Nomenclature 🏷️
Point of Preemption: the midpoint or ingress LSR that, because of its RSVP provisioning levels, is forced to either hard preempt or under-provision and signal soft preemption 🎯.
Hard Preemption: the (typically default) preemption process in which higher numeric priority TE LSPs get intrusively displaced at the point of preemption by lower numeric priority TE LSPs. In hard preemption, the TE LSP is torn down before it gets re-established 💥.
2.3. Requirements Language 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🫶.
3. Motivations 🌸
Okay this part is the "why." Initially, MPLS RSVP-TE [RFC3209] only supported one method of TE LSP preemption. It immediately tears down TE LSPs and ignores the preempted in-transit traffic 😬. That simple but abrupt process pretty much guarantees the preempted traffic gets discarded, even if only briefly, until the RSVP Path Error message reaches the ingress LER and gets processed, and a new data path can be set up 💔.
The Error Code and Error Values carried in the RSVP Path Error message that reports a preemption action are documented in [RFC5711] 📝. Also, preemption is referred to as a fatal error in [RFC5711] ☠️. In cases of actual resource contention, this might be helpful 👍. However, preemption can be triggered by mere reservation contention, and reservations might not reflect data-plane contention at that moment 🤷♀️. So when the conditions that promote preemption exist and hard preemption is the default, inferior-priority preempted traffic can get needlessly discarded even when there's enough bandwidth for both the preempted TE LSP and the preempting TE LSP(s) 😤.
Hard preemption might be a requirement for protecting numerically lower preemption priority traffic in a non-Diffserv-enabled architecture 🛡️. But in a Diffserv-enabled architecture, you don't need to rely only on preemption to enforce a preference for the most valued traffic, since the marking and queuing disciplines should already be aligned for those purposes 🍓. Even in non-Diffserv-aware networks, reservation contention may not accurately reflect the potential for data-plane congestion, depending on the TE LSP sizing rules. Imagine all LSPs are sized at double their observed traffic level 🙃.
4. RSVP Extensions 💅
4.1. SESSION-ATTRIBUTE Flags 🏳️🌈
So if you want a TE LSP to benefit from the soft preemption mechanism (meaning it isn't hard preempted when soft preemption is available), you signal it explicitly with a flag. This flag is defined for the SESSION-ATTRIBUTE object, for both the C-Type 1 and 7 ✨:
Soft Preemption Desired bit
Bit Flag Name Flag
0x40 Soft Preemption Desired4.2. Path Error - "Reroute Request Soft Preemption" Error Value 🧚
[RFC5710] specifies a new reroute-specific error code that lets a midpoint report a TE LSP reroute request (Error Code=34 - Reroute) 🗣️. This document specifies a new Error Value sub-code for the soft preemption case 🎀.
Error-value Meaning Reference
1 Reroute Request Soft Preemption This documentUpon (soft) preemption, the preempting node MUST issue a PathErr message with the Error Code=34 ("Reroute") and a value=1 ("Reroute Request Soft Preemption") 🚨.
...to be continued in part 2 🦋💖
5. Mode of Operation 🌸
okay so let's look at a little example, bestie 🫶 Here's the network:
R0--1G--R1---155----R2
| \ |
| \ 155
| \ |
155 1G R3
| \ |
| \ 155
| \|
R4----1G----R5
LSP1: LSP2:
R0-->R1 R1<--R2
\ |
V V
R5 R4
Figure 1: Example of Soft Preemption OperationIn the network in Figure 1, here's the setup 👀
- Reservable BW on R0-R1, R1-R5, and R4-R5 is 1 Gbit/s.
- Reservable BW on R1-R2, R1-R4, R2-R3, and R3-R5 is 155 Mbit/s.
- Bandwidths and costs are identical in both directions.
- Each circuit has an IGP metric of 10, and the IGP metric is used by CSPF.
- Two TE tunnels are defined:
- LSP1: 155 Mbit/s, setup/hold priority 0 tunnel, path R0-R1-R5.
- LSP2: 155 Mbit/s, setup/hold priority 7 tunnel, path R2-R1-R4.
- Circuit R1-R5 fails.
- Soft Preemption is functional.
Both TE LSPs are signaled with the "Soft Preemption Desired" bit of their SESSION-ATTRIBUTE object set. ✨
When the circuit R1-R5 fails, R1 detects it and sends an updated IGP LSA/LSP and Path Error message to all the head-end LSRs that have a TE LSP traversing the failed link (R0 in the example above). Either form of notification may arrive at the head-end LSRs first. 🏃♀️ Once R0 gets the link failure notification, it triggers a TE LSP reroute of LSP1 and re-signals LSP1 along the shortest path available that satisfies the TE LSP constraints: the R0-R1-R4-R5 path. The Resv messages for LSP1 travel in the upstream direction, from the destination to the head-end LSR (R5 to R0 in this example). LSP2 is soft preempted at R1 because it has a numerically lower priority value, and both bandwidth reservations cannot be satisfied on the R1-R4 link. 💅
Instead of sending a PathTear message for LSP2 upon preemption, like hard preemption does (which would cause an immediate traffic disruption for LSP2), R1's local bandwidth accounting for LSP2 is zeroed, and a PathErr message with error code "Reroute" and a value "Reroute Request Soft Preemption" for LSP2 is issued. 🦋
Once R2 receives the PathErr message for LSP2, it may update the working copy of the TE-DB before calculating a new path for the new LSP. If Diffserv [RFC3270] and TE [RFC3209] are deployed, receiving a "preemption pending" notification may imply to a head-end LSR that the available bandwidth for the affected priority level and numerically greater priority levels has been exhausted for the indicated node interface. R2 may choose to reduce or zero the available bandwidth for the implied priority range until more accurate information is available (i.e., a new IGP TE update is received). It follows that R2 re-computes a new path and performs a non-traffic-disruptive rerouting of the new TE LSP T2 by means of the make-before-break procedure. The old path is then torn down. 🌈
6. Elements Of Procedures 💜
6.1. On a Soft Preempting LSR
When a new TE LSP is signaled that requires a set of TE LSP(s) to be preempted because not all TE LSPs can be accommodated on a specific interface, a node triggers a preemption action. That action consists of selecting the set of TE LSPs that must be preempted so as to free up some bandwidth in order to satisfy the newly signaled numerically lower preemption TE LSP. 🎀
With hard preemption, when a TE LSP is preempted, the preempting node sends an RSVP PathErr message that serves as notification of a fatal action, as documented in [RFC5711]. When the head-end LSR receives the RSVP PathErr message, it sends an RSVP PathTear message, which would cause an immediate traffic disruption for the preempted TE LSP. 😭
By contrast, the mode of operation with soft preemption goes like this: the preempting node's local bandwidth accounting for the preempted TE LSP is zeroed, and a PathErr with error code "Reroute" and an error value "Reroute Request Soft Preemption" for that TE LSP is issued upstream toward the head-end LSR. ✨
If more than one soft preempted TE LSP has the same head-end LSR, these soft preemption PathErr notification messages may be bundled together. 🧚
The preempting node MUST immediately send a PathErr with error code "Reroute" and an error value "Reroute Request Soft Preemption" for each soft preempted TE LSP. The node MAY use the occurrence of soft preemption to trigger an immediate IGP update or to influence the scheduling of an IGP update. 🔥
To guard against a situation where bandwidth under-provisioning lasts forever, a local timer (named the "Soft preemption timer") MUST be started on the preemption node upon soft preemption. If this timer expires, the preempting node SHOULD send an RSVP PathTear and either a ResvTear message or a PathErr with the 'Path_State_Removed' flag set. 🕰️
If a refresh event for a soft preempted TE LSP arrives before the soft preemption timer expires, the soft preempting node MUST continue to refresh the TE LSP. Don't drop the refreshes, bestie 🙈
When the MESSAGE-ID extensions defined in [RFC2961] are available and enabled, PathErr messages with the error code "Reroute" and error value "Reroute Request Soft Preemption" SHOULD be sent in reliable mode. 🍓
The preempting node MAY preempt TE LSPs that have a numerically higher Holding priority than the Setup priority of the newly admitted LSP. Within the same priority, it SHOULD first attempt to preempt LSPs with the "Soft Preemption Desired" bit of the SESSION ATTRIBUTE object cleared, i.e., the TE LSPs that are considered Hard Preemptable. 👑
Selection of the preempted TE LSP at a preempting midpoint: when a numerically lower priority TE LSP is signaled and requires the preemption of a set of numerically higher priority LSPs, the node where preemption is to occur has to decide on the set of TE LSP(s) that are candidates for preemption. This decision is local, and various algorithms can be used depending on the objective (e.g., see [RFC4829]). As already mentioned, soft preemption causes a temporary link under-provisioning condition while the soft preempted TE LSPs are rerouted by their respective head-end LSRs. To reduce this under-provisioning exposure, a soft preempting LSR MAY first check whether there exists soft preemptable TE LSP bandwidth that is flagged by another node but still available for soft preemption locally. If sufficient overlap bandwidth exists, the LSR MAY attempt to soft preempt the same TE LSP. This would help reduce the temporarily elevated under-provisioning ratio on the links where soft preemption occurs, and reduce the number of preempted TE LSPs. Optionally, a midpoint LSR upstream or downstream from a soft preempting node MAY choose to flag the TE LSPs in soft preempted state. In the event a local preemption is needed, the LSPs that are in the cache and of the relevant priority level are soft preempted first, followed by the normal soft and hard preemption selection process for the given priority. 🧠
Under specific circumstances, such as unacceptable link congestion, a node MAY decide to hard preempt a TE LSP (by sending a fatal Path Error message, a PathTear, and either a ResvTear or a Path Error message with the 'Path_State_Removed' flag set) even if its head-end LSR explicitly requested soft preemption (by setting the "Soft Preemption Desired" flag of the corresponding SESSION-ATTRIBUTE object). Note that such a decision MAY also be made for TE LSPs under soft preemption state. 🥺
6.2. On Head-end LSR of a Soft Preempted TE LSP
When a PathErr message with error code "Reroute" and an error value "Reroute request soft preemption" arrives, the head-end LSR MAY first update the working copy of the TE-DB before computing a new path (e.g., by running CSPF) for the new LSP. If Diffserv [RFC3270] and MPLS Traffic Engineering [RFC3209] are deployed, receiving "preemption pending" may imply to a head-end LSR that the available bandwidth for the affected priority level and numerically greater priority levels has been exhausted for the indicated node interface. A head-end LSR MAY choose to reduce or zero the available bandwidth for the implied priority range until more accurate information is available (i.e., a new IGP TE update is received). 💖
Once a new path has been computed, the soft preempted TE LSP is rerouted using the non-traffic-disruptive make-before-break procedure. How long the head-end node avoids the node interface identified by the IP address contained in the PathErr is a local decision at the head-end node. 🌸
As a result of soft preemption, no traffic will be needlessly black-holed due to mere reservation contention. If loss does occur, it will be due only to an actual traffic congestion scenario, and it will follow the operator's Diffserv (if Diffserv is deployed) and queuing scheme. 🫶
7. Interoperability 🦋
Backward compatibility should be assured as long as the implementation followed the recommendations set forth in [RFC3209].
As mentioned previously, to guard against a situation where bandwidth under-provisioning lasts forever, a local timer (soft preemption timer) MUST be started on the preemption node upon soft preemption. When this timer expires, the soft preempted TE LSP SHOULD be hard preempted by sending a fatal Path Error message, a PathTear message, and either a ResvTear message or a PathErr message with the 'Path_State_Removed' flag set. This timer SHOULD be configurable, and a default value of 30 seconds is RECOMMENDED. ⏱️
It is RECOMMENDED that configuring the default preemption timer to 0 will cause the implementation to use hard preemption. 💀
Soft preemption as defined in this document is designed for use in MPLS RSVP-TE enabled IP networks and may not functionally translate to some GMPLS technologies. As with backward compatibility, if a device does not recognize a flag, it should pass the subobject transparently. 🌈
8. Management 📊
Both the point of preemption and the ingress LER SHOULD provide some form of accounting, both internally and to the network operator interface, with regard to which TE LSPs are involved and how much capacity is under-provisioned due to soft preemption. Displays of under-provisioning are recommended for the following midpoint, ingress, and egress views:
- Sum of current bandwidth per preemption priority per local interface
- Sum of current bandwidth total per local interface
- Sum of current bandwidth per local router (ingress, egress, midpoint)
- List of current LSPs and bandwidth in PPend (preemption pending) status
- List of current sum bandwidth and session count in PPend status per observed Explicit Route Object (ERO) hops (ingress and egress views only).
- Cumulative PPend events per observed ERO hop.
9. IANA Considerations 🎀
9.1. New Session Attribute Object Flag
A new flag of the Session Attribute Object has been registered by IANA. 🧁
Soft Preemption Desired bit
Bit Flag Name Reference
0x40 Soft Preemption Desired This document9.2. New Error Sub-Code Value 🎀
okay so [RFC5710] is the one that added a reroute-specific error code, which lets a midpoint report a TE LSP reroute request 🦋. this doc adds a brand new error sub-code value just for Soft Preemption, and it's giving very specific 💅
Error-value Meaning Reference
1 Reroute Request Soft Preemption This document10. Security Considerations 🔐
ngl this section is serious, but it's still a vibe 💀 this document doesn't introduce any new security issues 🫶 the security stuff from the original RSVP protocol [RFC3209] still applies, and you can find more MPLS security details in [SEC_FMWK].
as Section 6.1 noted, soft preemption can cause a temporary link under-provisioning situation while the soft preempted TE LSPs get rerouted by their head-end LSRs 😭 it's less bad than false hard preemption, and even with the mitigation procedures from Section 6.1, network operators should be aware of the risk if the soft preemption processes get subverted. they should use the relevant MPLS control plane security techniques to protect against attacks 🛡️✨
bestie, the takeaway: the mitigations help, but don't skip the security stuff 🙈
11. Acknowledgements 🌸
the authors wanted to thank Carol Iturralde, Dave Cooper, Loa Andersson, Arthi Ayyangar, Ina Minei, George Swallow, Adrian Farrel, and Mustapha Aissaoui for their valuable comments 🫶💖
12. Contributors 🧚
shoutout to these cuties who helped write it 💜
Denver Maddux
Limelight Networks
USA
EMail: denver@nitrous.net
Curtis Villamizar
AVICI
EMail:curtis@faster-light.net
Amir Birjandi
Juniper Networks
2251 Corporate Park Dr., Ste. 100
Herndon, VA 20171
USA
EMail: abirjandi@juniper.net13. References 📚
13.1. Normative References
these are the must-read ones, the foundation of the whole thing 👑
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC5710] Berger, L., Papadimitriou, D., and JP. Vasseur, "PathErr
Message Triggered MPLS and GMPLS LSP Reroutes", RFC 5710,
January 2010.
[RFC5711] Vasseur, JP., Swallow, G., and I. Minei, "Node Behavior
upon Originating and Receiving Resource Reservation
Protocol (RSVP) Path Error Messages", RFC 5711, January
2010.13.2. Informative References
these ones are extra reading, nice to have but not required 🌈
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002.
[RFC4829] de Oliveira, J., Vasseur, JP., Chen, L., and C. Scoglio,
"Label Switched Path (LSP) Preemption Policies for MPLS
Traffic Engineering", RFC 4829, April 2007.
[SEC_FMWK] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", Work in Progress, October 2009.Authors' Addresses 💌
these are the cuties who wrote it, and how to reach them 🦋
Matthew R. Meyer (editor)
British Telecom
EMail: matthew.meyer@bt.com
JP Vasseur (editor)
Cisco Systems, Inc.
11, Rue Camille Desmoulins
Issy Les Moulineaux, 92782
France
EMail: jpv@cisco.com📦 where this page comes from
- ietf: rfc5712 2010-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms