Update to the Automatic Bandwidth Adjustment Procedure for MPLS-TE and SR-TE LSPs with a Stateful PCE

Update to the Automatic Bandwidth Adjustment Procedure for MPLS-TE and SR-TE LSPs with a Stateful PCE Huawei Technologies

Huawei Bld., No.156 Beiqing Rd. Beijing 100095 CN pengshuping@huawei.com

Huawei

IN dhruv.ietf@gmail.com

Cisco Systems, Inc.

CA rgandhi@cisco.com

Routing PCE Working Group autobandwidth, autobw, auto-bandwidth 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.

Introduction 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). specifies extensions to PCEP that enable stateful control of MPLS-TE LSPs. It describes two operating modes: passive stateful PCE and active stateful PCE. describes the setup, maintenance, and teardown of PCE-initiated LSPs in the stateful PCE model. 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 by defining such a mechanism. 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. extends PCEP for SR in the IPv6 data plane (SRv6). As specified in , 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 , 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 . defines PCEP extensions that allow the signaling of multipath information via PCEP. Using multipath extensions for SR Policy Candidate Paths requires support for . 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 .

Conventions

Terminology The reader is assumed to be familiar with the terminology defined in , , , and . This document uses the following terms defined in : 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 as: While the base PCEP specification 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 , 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.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

AUTO-BANDWIDTH-ATTRIBUTES TLV

Overview 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 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 . 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 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 . AUTO-BANDWIDTH-ATTRIBUTES Sub-TLVs and Default Values

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.

Updated PCEP Procedures defines the AUTO-BANDWIDTH-ATTRIBUTES TLV and its associated sub-TLVs. This document updates by adding this text at the end of paragraph 3 of :

PCEP Extension for Auto-Bandwidth 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.

Examples The examples in this section assume that both PCEP speakers have advertised support for the Z flag.

Example 1 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:

Adjustment-Interval: 86400 (1 day in seconds, the default value)
Adjustment-Threshold: 0x0

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.

Example 2 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.

Example 3 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.

Auto-Bandwidth for Segment Routing LSPs The PCEP extensions for automatic bandwidth adjustment defined in 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" for the SR-MPLS data plane.
Path setup type "3: Traffic engineering path is set up using SRv6" for the IPv6 data plane.

Procedure for Multipath Auto-Bandwidth This document extends the automatic bandwidth adjustment procedure defined in to multiple path (e.g., SLs of an LSP) using the multipath PCEP extensions defined in as follows:

The auto-bandwidth attributes defined in 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 , 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 in PCRpt message specified in .
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 in a PCUpd message as specified in . 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 .

PCEP Extension for Multipath Auto-Bandwidth 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 with the B flag set, and successfully negotiate the MULTIPATH-CAP TLV as specified in . 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 .

Backward Compatibility To achieve the same objective, an implementation conforming to 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 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 , implementations may treat the sub-TLV as malformed and ignore it.

Implementation Status [Note to the RFC Editor: remove this section before publication and remove the reference to .] 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 . 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 , "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".

Huawei's Commercial Delivery

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:

Operational and Manageability Considerations All manageability requirements and considerations listed in , , , and apply to the PCEP protocol extensions defined in this document. The operational considerations in also apply to the multipath auto-bandwidth procedure defined in this document. The manageability considerations in also apply to this document. In addition, the requirements and considerations listed in this section apply.

Control of Function and Policy 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.

Information and Data Models Management data models can expose auto-bandwidth configuration and operational information, including the relevant parameters and counters for PCEP messages carrying auto-bandwidth TLVs.

Liveness Detection and Monitoring This document introduces no new liveness detection or monitoring requirements beyond those specified in .

Verifying Correct Operation This document introduces no new procedures for verifying correct operation beyond those specified in . Logging an invalid sub-TLV value when it is ignored and the previous value is retained can aid troubleshooting.

Requirements for Other Protocols The mechanisms defined in this document impose no new requirements on other protocols.

Impact on Network Operations 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.

Security Considerations The security considerations described in , , , , and apply to this specification. The security considerations in apply to the multipath auto-bandwidth procedure defined in this document. The security considerations described in 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 and the underlying PCEP security mechanisms.

IANA Considerations

AUTO-BANDWIDTH-CAPABILITY TLV Flag Field 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. AUTO-BANDWIDTH-CAPABILITY TLV Flag Field

Bit	Description	Reference
31	Z flag (special value of all zeros)	This document
30	B flag (multipath auto-bandwidth support)	This document

References Normative References &RFC2119; &RFC3031; &RFC4655; &RFC5440; &RFC8174; &RFC8231; &RFC8281; &RFC8733; &RFC9256; &RFC9862; &I-D.ietf-pce-multipath; Informative References &RFC8664; &RFC7942; &RFC9603;

Acknowledgments Thanks to Aijun Wang, Andrew Stone, and Luis Miguel Contreras Murillo for their review comments.