| Internet-Draft | Auto-BW-Update | October 2026 |
| Peng, et al. | Expires 12 April 2027 | [Page] |
Extensions for the stateful PCE model enable control of Traffic Engineering (TE) LSPs using the Path Computation Element Communication Protocol (PCEP) for RSVP-TE and Segment Routing (SR), for both PCE-initiated and PCC-initiated LSPs.¶
RFC 8733 defines PCEP extensions for automatically adjusting bandwidth on MPLS-TE Label Switched Paths (LSPs) using a stateful PCE. It also defines the AUTO-BANDWIDTH-ATTRIBUTES TLV and a set of sub-TLVs for the attributes. A sub-TLV is included when its value differs from the value last sent in a PCEP message. However, RFC 8733 lacks a mechanism to explicitly remove an attribute identified by a sub-TLV. This document updates RFC 8733 by defining such a mechanism.¶
In addition, this document applies the PCEP extensions for automatic bandwidth adjustment to SR-TE LSPs in both the MPLS (SR-MPLS) and IPv6 (SRv6) data planes. It also extends automatic bandwidth adjustment to multiple Segment Lists in an SR LSP using the extensions defined in draft-ietf-pce-multipath.¶
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 12 April 2027.¶
Copyright (c) 2026 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.¶
[RFC5440] describes the Path Computation Element Communication Protocol (PCEP). PCEP enables a Path Computation Client (PCC) to communicate with a Path Computation Element (PCE), or with other PCEs, to compute paths for Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs).¶
[RFC8231] specifies extensions to PCEP that enable stateful control of MPLS-TE LSPs. It describes two operating modes: passive stateful PCE and active stateful PCE. [RFC8281] describes the setup, maintenance, and teardown of PCE-initiated LSPs in the stateful PCE model.¶
[RFC8733] defines PCEP extensions for automatically adjusting bandwidth on MPLS-TE Label Switched Paths (LSPs) using a stateful PCE. It defines the AUTO-BANDWIDTH-ATTRIBUTES TLV and a set of sub-TLVs for the attributes. A sub-TLV is included when its value differs from the value last sent in a PCEP message. However, RFC 8733 lacks a mechanism to explicitly remove an attribute identified by a sub-TLV. This document updates [RFC8733] by defining such a mechanism.¶
[RFC8664] specifies PCEP extensions for Segment Routing (SR). These extensions allow a stateful PCE to compute and initiate TE paths and allow a PCC to request paths subject to constraints and optimization criteria. [RFC9603] extends PCEP for SR in the IPv6 data plane (SRv6). As specified in [RFC8664], an LSP can be an MPLS-TE LSP or an SR-TE LSP, depending on the path setup type.¶
An SR Policy, as defined in [RFC9256], contains one or more Candidate Paths (CPs), which a PCE may compute. Each Candidate Path can contain one or more Segment Lists (SLs). In PCEP messages, an SL is encoded as an Explicit Route Object (ERO) as described in Section 4.3 of [RFC8664].¶
[I-D.ietf-pce-multipath] defines PCEP extensions that allow the signaling of multipath information via PCEP. Using multipath extensions for SR Policy Candidate Paths requires support for [RFC9862].¶
This document applies PCEP extensions for automatic bandwidth adjustment to SR-TE LSPs in both the MPLS (SR-MPLS) and IPv6 (SRv6) data planes. It also extends automatic bandwidth adjustment to multiple SLs of an SR-TE LSP using the extensions defined in [I-D.ietf-pce-multipath].¶
The reader is assumed to be familiar with the terminology defined in [RFC8231], [RFC8281], [RFC8733], and [I-D.ietf-pce-multipath].¶
This document uses the following terms defined in [RFC5440]: Explicit Route Object (ERO), Path Computation Client (PCC), Path Computation Element (PCE), Path Computation Element Communication Protocol (PCEP), PCEP peer, and PCEP speaker.¶
This document extends the definition of Label Switched Path (LSP) in [RFC3031] as:¶
While the base PCEP specification [RFC4655] originally defined the PCE architecture for MPLS and GMPLS networks with LSPs instantiated using the RSVP-TE signaling protocol. As specified in the Terminology Section of [RFC9603], the term "LSP" used in the PCEP specifications would be equivalent to an SRv6 path (represented as a list of SRv6 segments) in the context of supporting SRv6 in PCEP using the SRv6 Path Setup Type.¶
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.¶
[RFC8733] describes the auto-bandwidth feature, which automatically adjusts TE LSP bandwidth reservations based on the traffic volume flowing through each LSP. It specifies PCEP extensions for auto-bandwidth adjustment using an active stateful PCE for both PCE-initiated [RFC8281] and PCC-initiated LSPs.¶
RFC 8733 also defines the AUTO-BANDWIDTH-ATTRIBUTES TLV, which provides configurable parameters for the feature and may be included as an optional TLV in the LSPA object. The TLV is included in all PCEP messages for an LSP while auto-bandwidth adjustment is enabled; its absence indicates that the PCEP speaker wishes to disable the feature. The TLV contains multiple AUTO-BANDWIDTH-ATTRIBUTES sub-TLVs defined in [RFC8733]. A sub-TLV is included when its value differs from the value last sent in a PCEP message. When a sub-TLV is absent, local policy determines whether its default value or another operator-configured value is used.¶
Because the absence of a sub-TLV in a subsequent PCEP message indicates that its value has not changed, a PCEP speaker cannot use omission to remove a previously specified attribute. This document updates [RFC8733] to define such a procedure.¶
A PCEP speaker can reset an attribute with an associated default value by encoding that value in the sub-TLV. This approach is unavailable for attributes without a default value.¶
This document defines a special all-zero value to mean "restore to default." Depending on the attribute, this restores its default value or removes the attribute.¶
The following table lists the sub-TLVs and their default values as defined in [RFC8733].¶
| Type | Len | Name | Default |
|---|---|---|---|
| 1 | 4 | Sample-Interval | 300 seconds |
| 2 | 4 | Adjustment-Interval | 86400 seconds |
| 3 | 4 | Down-Adjustment-Interval | Adjustment-Interval |
| 4 | 4 | Adjustment-Threshold | none |
| 5 | 8 | Adjustment-Threshold-Percentage | 5%, 0 |
| 6 | 4 | Down-Adjustment-Threshold | Adjustment-Threshold |
| 7 | 8 | Down-Adjustment-Threshold-Percentage | Adjustment-Threshold-Percentage |
| 8 | 4 | Minimum-Bandwidth | 0 |
| 9 | 4 | Maximum-Bandwidth | none |
| 10 | 8 | Overflow-Threshold | none |
| 11 | 8 | Overflow-Threshold-Percentage | none |
| 12 | 8 | Underflow-Threshold | none |
| 13 | 8 | Underflow-Threshold-Percentage | none |
Thus, an all-zero value in the value field of a sub-TLV indicates "restore to default," which may mean one of the following:¶
if an explicit default value is set for the sub-TLV:¶
Restore the default value¶
if the default value is set to another sub-TLV value:¶
Remove the associated attribute¶
if there is no default value for the sub-TLV:¶
Remove the associated attribute¶
The value portion of the sub-TLV contains encoded data of the specified length and type and is set to zero. If it contains multiple fields, each field is set to zero.¶
Section 5.2 of [RFC8733] defines the AUTO-BANDWIDTH-ATTRIBUTES TLV and its associated sub-TLVs.¶
This document updates [RFC8733] by adding this text at the end of paragraph 3 of Section 5.2 of [RFC8733]:¶
A special value of all zeros in the value portion of the sub-TLV indicates that the attribute identified by the sub-TLV is restored to the default value. The value of all zeros is not considered an invalid value and MUST be checked before individual fields. For the attributes that have an associated default value, on receiving such a sub-TLV, the PCEP speaker MUST treat it as an instruction to restore the default values. Note that the PCEP speaker could also set the default value in the sub-TLV itself. For the attributes that do not have an associated default value, on receiving such a sub-TLV, the PCEP speaker MUST treat it as an instruction to remove the specific auto-bandwidth attribute.¶
Section 5.1.1 of [RFC8733] defines the AUTO-BANDWIDTH-CAPABILITY TLV as an optional TLV for use in the OPEN Object for auto-bandwidth adjustment. This document adds the following flag:¶
Z (bit 31): Indicates that a PCEP speaker supports using the special all-zero value in the value field as specified in this document.¶
The presence of the Z flag indicates to the PCEP peer that this speaker supports the updated procedures defined in this document.¶
A PCEP speaker MUST NOT use the all-zero value semantics defined in this document unless the peer has advertised the Z flag in the AUTO-BANDWIDTH-CAPABILITY TLV.¶
The examples in this section assume that both PCEP speakers have advertised support for the Z flag.¶
Consider an LSP with the following information in the AUTO-BANDWIDTH-ATTRIBUTES TLV in the PCInitiate message:¶
Sample-Interval: 600 (in seconds)¶
Adjustment-Interval: 172800 (2 days in sec)¶
Adjustment-Threshold: 0x49989680 (10 Mbps in bps)¶
If the PCE wants to disable the Adjustment-Threshold feature for the LSP and set the Adjustment-Interval to one day, it can send the AUTO-BANDWIDTH-ATTRIBUTES TLV in the PCUpd message with the following sub-TLVs:¶
When the PCEP speaker receives an all-zero value in the Adjustment-Threshold sub-TLV, it interprets the value as an instruction to remove the Adjustment-Threshold feature.¶
The PCE could also set the Adjustment-Interval to 0x0 to reset it to its default value. The Sample-Interval remains unchanged.¶
Consider an LSP with the following information in the AUTO-BANDWIDTH-ATTRIBUTES TLV in the PCInitiate message:¶
Sample-Interval = 1000¶
If the PCC receives an update that sets Sample-Interval to all zeros, the PCC resets Sample-Interval to its default value of 300 seconds.¶
Consider an LSP with the following information in the AUTO-BANDWIDTH-ATTRIBUTES TLV in the PCInitiate message:¶
Adjustment-Threshold: 0x49989680 (10 Mbps in bps)¶
Down-Adjustment-Threshold: 0x93312D00 (20 Mbps in bps)¶
When the PCC receives an update that sets Down-Adjustment-Threshold to all zeros, it removes that attribute, leaving only Adjustment-Threshold.¶
If the PCC receives an update that sets Adjustment-Threshold to all zeros, it removes that attribute as well.¶
The PCEP extensions for automatic bandwidth adjustment defined in [RFC8733] for path setup type "0: Path is set up using the RSVP-TE signaling protocol" also apply to SR-TE LSPs that use path setup types as follows:¶
Path setup type "1: Traffic-engineering path is set up using Segment Routing" [RFC8664] for the SR-MPLS data plane.¶
Path setup type "3: Traffic engineering path is set up using SRv6" [RFC9603] for the IPv6 data plane.¶
This document extends the automatic bandwidth adjustment procedure defined in [RFC8733] to multiple path (e.g., SLs of an LSP) using the multipath PCEP extensions defined in [I-D.ietf-pce-multipath] as follows:¶
The auto-bandwidth attributes defined in Section 5.2 of [RFC8733] apply independently to each path of an LSP. Each path uses its own traffic samples, current bandwidth reservation, and calculated Adjusted Bandwidth.¶
A PCC (LSP head-end) collects traffic-rate samples and calculates the Adjusted Bandwidth independently for each path. As defined in Section 5.3 of [RFC8733], the PCC reports the calculated bandwidth to be adjusted to the stateful PCE using the existing Requested Bandwidth (Object-Type 1) fo BANDWIDTH (Class 5) for each path.¶
The Requested Bandwidth in BANDWIDTH object is associated with each path identified by its Path ID as specified in Section 4.2 of [I-D.ietf-pce-multipath] in PCRpt message specified in Section 5 of [I-D.ietf-pce-multipath].¶
A PCE updates the PCC with the bandwidth value used to compute each path in a PCUpd message, using the existing Requested Bandwidth in BANDWIDTH for each path.¶
The Requested Bandwidth in BANDWIDTH object is associated with each path identified by its Path ID as specified in Section 4.2 of [I-D.ietf-pce-multipath] in a PCUpd message as specified in Section 5 of [I-D.ietf-pce-multipath].¶
For a PCE-initiated LSP, the same per-path association for Requested Bandwidth in BANDWIDTH object is used in the PCInitiate message as specified in Section 5 of [I-D.ietf-pce-multipath].¶
Section 5.1.1 of [RFC8733] defines the AUTO-BANDWIDTH-CAPABILITY TLV as an optional TLV for use in the OPEN Object for auto-bandwidth adjustment. This document adds the following flag:¶
B (bit 30): Indicates that a PCEP speaker supports automatic bandwidth adjustment for multipath LSPs.¶
A PCEP speaker MUST NOT use the multipath auto-bandwidth procedure unless both peers advertise the AUTO-BANDWIDTH-CAPABILITY TLV defined in Section 5.1 of [RFC8733] with the B flag set, and successfully negotiate the MULTIPATH-CAP TLV as specified in Section 4.1 of [I-D.ietf-pce-multipath]. The MULTIPATH-CAP TLV MUST be present in the OPEN objects of both peers. Any per-LSP MULTIPATH-CAP TLV and its effective multipath limit are subject to the procedures in Section 4.1 of [I-D.ietf-pce-multipath].¶
To achieve the same objective, an implementation conforming to [RFC8733] could first send a PCEP message without the AUTO-BANDWIDTH-ATTRIBUTES TLV and then include the TLV with the updated sub-TLV. This is equivalent to turning the feature off and on again, but causes unnecessary path-computation churn compared with targeted removal of the attribute.¶
An existing implementation of [RFC8733] that does not support this update (where the Z flag is not set) will not recognize or use the special value of all zeros in the sub-TLV. If such a sub-TLV is received, as per [RFC8733], implementations may treat the sub-TLV as malformed and ignore it.¶
[Note to the RFC Editor: remove this section before publication and remove the reference to [RFC7942].]¶
This section records the status of known implementations of the protocol defined by this specification as of the posting of this Internet-Draft. It follows the proposal described in [RFC7942]. This information is intended to assist the IETF in deciding whether to progress drafts to RFCs; listing an implementation does not imply IETF endorsement. The information was supplied by IETF contributors and has not been independently verified. This section is not a catalog of available implementations or their features; other implementations may exist.¶
According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶
Organization: Huawei¶
Implementation: Based on NE40E-M2 V800R024C00SPC500.¶
Description: Enabling Automatic Bandwidth Adjustment for a PCC-Initiated SR-MPLS TE Policy¶
Maturity Level: Product (shipping)¶
Contact: tanren@huawei.com¶
Reference: https://support.huawei.com/enterprise/en/doc/EDOC1100419268/10a4db61/enabling-automatic-bandwidth-adjustment-for-a-pcc-initiated-sr-mpls-te-policy¶
All manageability requirements and considerations listed in [RFC5440], [RFC8231], [RFC8664], and [RFC9256] apply to the PCEP protocol extensions defined in this document.¶
The operational considerations in [I-D.ietf-pce-multipath] also apply to the multipath auto-bandwidth procedure defined in this document.¶
The manageability considerations in Section 6 of [RFC8733] also apply to this document. In addition, the requirements and considerations listed in this section apply.¶
Per-LSP controls at the PCC (LSP head-end) or PCE allow operators to enable or disable the auto-bandwidth feature. Configuration parameters include sampling and adjustment intervals, minimum and maximum bandwidths, and adjustment thresholds. Appropriate bandwidth limits help avoid adverse effects on the administrative domain, while consistent overflow and underflow thresholds support predictable bandwidth adjustments.¶
Management data models can expose auto-bandwidth configuration and operational information, including the relevant parameters and counters for PCEP messages carrying auto-bandwidth TLVs.¶
This document introduces no new liveness detection or monitoring requirements beyond those specified in [RFC5440].¶
This document introduces no new procedures for verifying correct operation beyond those specified in [RFC5440]. Logging an invalid sub-TLV value when it is ignored and the previous value is retained can aid troubleshooting.¶
The mechanisms defined in this document impose no new requirements on other protocols.¶
auto-bandwidth processing increases the load on PCCs and PCEs and can increase PCEP message traffic and signaling churn. Per-LSP limits, message-rate controls, and notifications for overload or threshold crossings provide ways to manage this impact. Short sampling intervals leave less time for transport protocols to react to frequent bandwidth changes.¶
The security considerations described in [RFC5440], [RFC8231], [RFC8281], [RFC8664], and [RFC9256] apply to this specification.¶
The security considerations in [I-D.ietf-pce-multipath] apply to the multipath auto-bandwidth procedure defined in this document.¶
The security considerations described in [RFC8733] also apply to this specification. Incorrect or unauthorized use of the all-zero value semantics could remove or reset auto-bandwidth attributes and affect LSP bandwidth adjustment behavior. Therefore, deployments MUST apply the security mechanisms and access controls described in [RFC8733] and the underlying PCEP security mechanisms.¶
[RFC8733] defines the AUTO-BANDWIDTH-CAPABILITY TLV Flag Field registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA is requested to allocate the bits 30 and 31 in that registry. Bit numbers are counted from bit 0 as the most significant bit.¶
| Bit | Description | Reference |
|---|---|---|
| 31 | Z flag (special value of all zeros) | This document |
| 30 | B flag (multipath auto-bandwidth support) | This document |
Thanks to Aijun Wang, Andrew Stone, and Luis Miguel Contreras Murillo for their review comments.¶