MPLS Traffic Engineering Soft Preemption
Extracted elements (22)
A soft preempting LSR MAY check whether there exists soft preemptable TE LSP bandwidth already flagged by another node to reduce the under-provisioning exposure and the number of preempted TE LSPs, since coordinating preemption of the same LSP across multiple nodes avoids duplicating the penalty.
Hard preemption nearly guarantees traffic disruption because it tears down TE LSPs before reestablishment, even when reservation contention does not reflect actual data-plane congestion. Soft preemption was introduced to allow make-before-break rerouting, avoiding needless traffic loss when sufficient bandwidth exists for both LSPs.
In Diffserv-enabled architectures, hard preemption is less necessary to protect high-priority traffic because marking and queuing disciplines already enforce preference. Soft preemption is therefore especially attractive in MPLS networks with both Diffserv and TE capabilities.
The preempting node zeros its local bandwidth accounting for the soft preempted TE LSP immediately rather than waiting for the reroute to complete, creating a temporary under-provisioning condition. This is intentional: it frees capacity for the higher-priority LSP while the lower-priority LSP reroutes non-disruptively.
Backward compatibility is assured as long as implementations follow RFC 3209 recommendations; devices that do not recognize the 'Soft Preemption Desired' flag should pass the SESSION-ATTRIBUTE subobject transparently, resulting in hard preemption behavior.
Soft preemption as defined is designed for MPLS RSVP-TE enabled IP networks and may not functionally translate to some GMPLS technologies.
A local 'Soft Preemption Timer' MUST be started on the preempting node upon soft preemption to guard against indefinite bandwidth under-provisioning. If the timer expires, the node SHOULD send an RSVP PathTear and either a ResvTear or a PathErr with the 'Path_State_Removed' flag set.
It is RECOMMENDED that configuring the default preemption timer to 0 will cause the implementation to use hard preemption, providing a backward-compatible fallback.
Once a new path has been computed, the soft preempted TE LSP MUST be rerouted using the non-traffic-disruptive make-before-break procedure.
Should a refresh event for a soft preempted TE LSP arrive before the soft preemption timer expires, the soft preempting node MUST continue to refresh the TE LSP.
The soft preemption timer MUST be started upon soft preemption; this timer SHOULD be configurable, and a default value of 30 seconds is RECOMMENDED.
Under specific circumstances such as unacceptable link congestion, a node MAY decide to hard preempt a TE LSP even if its head-end LSR explicitly requested soft preemption via the SESSION-ATTRIBUTE 'Soft Preemption Desired' flag.
Upon reception of a PathErr with Error Code 'Reroute' and Error Value 'Reroute Request Soft Preemption', the head-end LSR MAY update the working copy of the TE-DB and MAY reduce or zero available bandwidth for the implied priority range before computing a new path.
Upon soft preemption, the preempting node MUST immediately send a PathErr message with Error Code=34 ('Reroute') and Error Value=1 ('Reroute Request Soft Preemption') for each soft preempted TE LSP.
When MESSAGE-ID extensions (RFC 2961) are available and enabled, PathErr messages with Error Code 'Reroute' and Error Value 'Reroute Request Soft Preemption' SHOULD be sent in reliable mode.
Within the same priority level, the preempting node SHOULD first attempt to preempt TE LSPs with the 'Soft Preemption Desired' bit of the SESSION-ATTRIBUTE object cleared (i.e., Hard Preemptable LSPs) before soft-preempting others.
A new RSVP PathErr Error Value sub-code is defined: Error Code=34 ('Reroute'), Error Value=1 ('Reroute Request Soft Preemption'), used by a preempting midpoint node to notify the head-end LSR that a soft preemption has been initiated.
The SESSION-ATTRIBUTE object (C-Type 1 and 7) is extended with a new 'Soft Preemption Desired' bit flag (0x40), allowing a TE LSP head-end to signal that it wishes to benefit from soft preemption rather than hard preemption.
IANA registered a new RSVP PathErr Error Value sub-code under Error Code 34 (Reroute, defined in RFC 5710): Error Value=1, 'Reroute Request Soft Preemption', as defined in this document.
IANA registered a new SESSION-ATTRIBUTE Object flag: bit 0x40, 'Soft Preemption Desired', as defined in this document.
Soft preemption introduces a temporary link under-provisioning condition while soft preempted TE LSPs are rerouted. If soft preemption processes are subverted, network operators face risk from this under-provisioning; MPLS control plane security techniques should be applied to protect against attacks. The document does not introduce new security issues beyond those of the original RSVP protocol (RFC 3209).
Soft preemption defines a 'PPend' (Preemption Pending) state for a TE LSP: entered when the preempting node zeros local BW accounting and sends a PathErr Reroute notification; exited either by successful make-before-break reroute (head-end tears old path) or by timer expiry triggering hard preemption (PathTear + ResvTear or PathErr with Path_State_Removed).