LSP Modification Using CR-LDP
Extracted elements (21)
An explicit _modify_ action indicator flag is introduced in the LSPID TLV rather than inferring modification intent, so that the LSPID can unambiguously support other networking capabilities in the future without ambiguity about the intended operation.
Intermediate LSRs do not need to implement new procedures to track old versus new LSP characteristics; the dual-label coexistence model and the standard Label Release procedure handle cleanup without requiring LSR state for the modification transition.
The LSPID concept from CR-LDP is reused to achieve LSP modification without releasing the LSP or interrupting service, and without double-booking bandwidth. This avoids the need for a separate teardown-and-reestablish cycle.
The new holding priority is applied to both the existing and new labels immediately upon receipt of the modification Label Request, specifically to prevent the LSP from bumping itself during the two-label transition period.
The setup priority in a modification Label Request can differ from the original setup priority to indicate the relative urgency of the modification request, allowing operators to apply policy-based prioritization of bandwidth changes across competing LSPs.
This document depends on the _modify_ action indicator flag defined in CR-LDP (RFC 3212) and on the Label Abort Request message defined in the LDP specification (RFC 3036). Implementations must support both to use LSP modification.
At LSRs between route divergence points Rj and Rk during reroute modification, the LSPID TLV must still be updated and passed on to the next LSR as the Label Release message is propagated, even where only original-route labels exist.
If a Label Withdraw Message is used to withdraw a label associated with an LSPID, the Label TLV MUST be included to specify which label to withdraw.
If the LSP on the original path fails while a modification attempt is in progress, the attempt should be aborted by using the Label Abort Request message as specified in the LDP document (RFC 3036).
In the event of a modification failure, all modifications to the LSP including the holding priority must be restored to their original values.
LSP modification can only be allowed when the LSP is already set up and active. Modification is not defined nor allowed during the LSP establishment or label release/withdraw phases.
Only modification requested by the ingress LSR of the LSP is considered for CR-LSP. The ingress LSR cannot modify an LSP before a previous modification procedure is completed.
Upon receiving a Label Release Message, LSR Ri examines the LSPID and, if another set of labels still exists under it, releases only the old label without releasing the bandwidth resource in use (or releases only the delta bandwidth if decreased).
Upon receiving a Label Request Message requesting a new holding priority, the LSR assigns the new holding priority to both the existing incoming/outgoing labels and the new labels to be established for the LSPID, preventing self-bumping.
When an LSR Ri recognizes a previously seen LSPID in a Label Request Message, it reserves only the difference in bandwidth requirements compared to the already reserved bandwidth for that LSPID, preventing double booking.
A Label Request Message for modification carries the LSPID TLV (set to the existing LSPID), and may include modified Traffic Parameters TLV, ER-TLV, Resource Class (color) TLV, and Preemption TLV with values different from the original setup message.
The Label Release Message sent after successful modification carries the LSPID and a Label TLV identifying which label (the original) is to be released, enabling downstream LSRs to release only the old label while preserving the new one.
The LSPID TLV carries an action indicator flag with a _modify_ value, which explicitly signals that the Label Request Message is intended to modify an existing active CR-LSP rather than establish a new one. Defined in CR-LDP (RFC 3212).
Protection against unauthorized modification of LSPs by malign agents must be controlled by the MPLS domain. The document does not specify mechanisms but delegates security enforcement to the MPLS administrative domain.
During modification, the ingress LSR transitions from one outgoing label (A, original) to two simultaneous outgoing labels (A and B) for the same FEC upon receiving the Label Mapping response. It then activates FEC1->Label B, deactivates FEC1->Label A, and initiates release of label A. States: active-single-label -> dual-label (on Label Mapping receipt) -> active-new-label (after FTN swap) -> modification-complete (after Label Release propagation).
During reroute modification, at diverging LSR Rj the new route is forwarded as a new LSP setup until paths converge at Rk; the _modify_ action flag is ignored on the diverged segment. On convergence, behavior reverts to the modification procedure, and on Label Mapping return two label sets coexist where routes coincide.