| Internet-Draft | In-Place LSP BW Update | March 2025 |
| Ali & Beeram | Expires 4 September 2025 | [Page] |
This document describes the procedure for updating the bandwidth of an MPLS RSVP-TE Label Switched Path (LSP) tunnel in-place without employing make-before-break (MBB).¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 September 2025.¶
Copyright (c) 2025 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Sections 2.5 and 4.6.4 of [RFC3209] describe the RSVP signaling procedure for increasing the bandwidth of an MPLS TE tunnel using a make-before-break (MBB) operation. A bandwidth-update-triggered MBB operation for an MPLS RSVP-TE tunnel involves establishing a new LSP with a new LSP_ID and transferring traffic from the old LSP onto it before tearing down the old LSP. Establishing the new LSP involves programming the forwarding plane with new tunnel labels along its path, even in scenarios where both the old and new LSPs traverse the same path. Such MBB events can occur frequently in networks that deploy the 'auto-bandwidth' feature on RSVP-TE tunnels to monitor bandwidth utilization and periodically adjust tunnel bandwidth, causing a considerable amount of signaling and label programming churn in the network.¶
[RFC3209] does not explicitly discuss the procedure for handling a decrease in the bandwidth of an MPLS RSVP-TE tunnel, allowing an ingress LER implementation to have the option to update the LSP bandwidth "in-place" without employing MBB. The in-place LSP bandwidth update mechanism reduces signaling churn. It eliminates the need to reprogram labels at each transit Label Switch Router (LSR) along the path of the LSP and shift traffic at the ingress Label Edge Router (LER) from one LSP to another. However, the signaling procedure for handling any failures that the RSVP transit node may encounter while processing an in-place LSP bandwidth update request is unspecified. This document clarifies this procedure. It describes how an implementation can leverage the in-place LSP bandwidth update mechanism in both scenarios where the bandwidth of the TE tunnel needs to be decreased or increased.¶
This document does not cover the application of the in-place LSP bandwidth update procedure to anything other than point-to-point MPLS RSVP-TE tunnels.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Figure 1 illustrates an example RSVP signaling sequence for a scenario where the bandwidth of an LSP is successfully updated in-place. In the signaling sequence used for initial setup, the LSP is signaled with a bandwidth of 60 Mbps. This bandwidth value is encoded in the SENDER_TSPEC object of the PATH message sent hop-by-hop from the ingress LER to the egress LER , and upon successful admission control at each hop is encoded in the FLOWSPEC object of the RESV message sent in the reverse direction. In the in-place update signaling sequence, the same LSP instance, with no change to the LSP_ID in the SENDER_TEMPLATE object, is signaled with a bandwidth of 40 Mbps. When the ingress LER receives a RESV message with 40Mbps encoded in the FLOWSPEC object, the in-place LSP bandwidth update signaling sequence is deemed successful.¶
+----+ +----+ +----+ +----+ +----+ | R1 |---------| R2 |---------| R3 |---------| R4 |---------| R5 | +----+ +----+ +----+ +----+ +----+ Initial Setup: PATH msg PATH msg PATH msg PATH msg LSP-ID:X LSP-ID:X LSP-ID:X LSP-ID:X TSpecRate:60 TSpecRate:60 TSpecRate:60 TSpecRate:60 ------------> ------------> ------------> ------------> RESV msg RESV msg RESV msg RESV msg LSP-ID:X LSP-ID:X LSP-ID:X LSP-ID:X FSpecRate:60 FSpecRate:60 FSpecRate:60 FSpecRate:60 <------------ <------------ <------------ <------------ In-Pace LSP BW Update: PATH msg PATH msg PATH msg PATH msg LSP-ID:X LSP-ID:X LSP-ID:X LSP-ID:X TSpecRate:40 TSpecRate:40 TSpecRate:40 TSpecRate:40 ------------> ------------> ------------> ------------> RESV msg RESV msg RESV msg RESV msg LSP-ID:X LSP-ID:X LSP-ID:X LSP-ID:X FSpecRate:40 FSpecRate:40 FSpecRate:40 FSpecRate:40 <------------ <------------ <------------ <------------
Figure 2 illustrates an example RSVP signaling sequence for a scenario where the bandwidth of an LSP is not successfully updated in-place. In the initial setup signaling sequence, the LSP is signaled with a bandwidth of 60 Mbps. In the in-place update signaling sequence, the same LSP instance, with no change to the LSP_ID in the SENDER_TEMPLATE object, is signaled with a bandwidth of 80 Mbps. However, node R3 fails admission control and sends a PathErr with an error code of 'Admission Control Failure (1)' and error value of 'Requested bandwidth unavailable (2)'. When the ingress LER receives a PathErr message in response to an in-place LSP bandwidth update request, the in-place LSP bandwidth update signaling sequence is deemed a failure. A consequence of this failed attempt is that the bandwidth reservation in the path segment of the LSP upstream of R3 is inconsistent with the path segment downstream of R3. Another scenario in which the in-place LSP update signaling sequence is deemed a failure is when the ingress does not receive either a RESV message or a PATHErr message within a reasonable interval (bandwidth update request timed out). In such failed scenarios, the onus is on the ingress LER to reroute the path using MBB.¶
+----+ +----+ +----+ +----+ +----+ | R1 |---------| R2 |---------| R3 |---------| R4 |---------| R5 | +----+ +----+ +----+ +----+ +----+ Initial Setup: PATH msg PATH msg PATH msg PATH msg LSP-ID:X LSP-ID:X LSP-ID:X LSP-ID:X TSpecRate:60 TSpecRate:60 TSpecRate:60 TSpecRate:60 ------------> ------------> ------------> ------------> RESV msg RESV msg RESV msg RESV msg LSP-ID:X LSP-ID:X LSP-ID:X LSP-ID:X FSpecRate:60 FSpecRate:60 FSpecRate:60 FSpecRate:60 <------------ <------------ <------------ <------------ In-Pace LSP BW Update: PATH msg PATH msg LSP-ID:X LSP-ID:X TSpecRate:80 TSpecRate:80 ------------> ------------> PATHErr msg PATHErr msg LSP-ID:X LSP-ID:X ErrSpec:1,2 ErrSpec:1,2 <------------ <------------
An ingress LER implementation that supports in-place LSP bandwidth update MAY use local policy to determine whether to trigger the "in-place LSP bandwidth update" functionality or the "MBB" procedure to update LSP bandwidth. If the ingress LER is mandated by local policy to use in-place LSP bandwidth update, it SHOULD do the following when there is a need to update the bandwidth of the TE tunnel:¶
Compute and check if the current signaled TE path can accommodate the new bandwidth:¶
If it is determined that the current TE path can accommodate the new bandwidth, initiate in-place LSP bandwidth update signaling.¶
A transit LSR / egress LER implementation that supports in-place LSP bandwidth update SHOULD perform an admission control procedure when it receives an in-place LSP bandwidth update request. If the admission control succeeds, the transit LSR / egress LER SHOULD allow the in-place LSP bandwidth signaling sequence to complete. If the admission control fails, the transit LSR / egress LER:¶
[Editor's Notes: Should the document define a new error code/value or re-use (1,2)]¶
Since the procedure for handling an in-place LSP bandwidth update request at a transit/egress node is not specified in RFC3209, a transit/egress implementation that does not support this functionality may exhibit one of the following behaviors:¶
The in-place LSP bandwidth update functionality SHOULD NOT be enabled at the ingress LERs in a network with non-compliant transit/egress nodes that exhibit behavior [A]. The functionality MAY be enabled at the ingress LERs in a network with non-compliant nodes that exhibit behavior [B] or [C].¶
This document does not introduce new security issues. The security considerations pertaining to the original RSVP protocol [RFC2205] and RSVP-TE [RFC3209], and those that are described in [RFC5920], remain relevant.¶
This document has no IANA actions.¶
The authors would like to thank Colby Barth, Stephane Litkowski and Robert Sawaya for their review and suggestions.¶
The following people have contributed to this document:¶