]> 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 The Stateful PCE extensions allow Stateful control of Traffic Engineering (TE) LSPs using PCEP for RSVP-TE and Segment Routing (SR) (for both MPLS and IPv6 Data planes) for both PCE-Initiated and PCC-Initiated LSPs. Extensions to the Path Computation Element Communication Protocol (PCEP) for MPLS-TE Label Switched Path (LSP) Automatic Bandwidth Adjustments with Stateful PCE are defined in RFC 8733. It defines the AUTO-BANDWIDTH-ATTRIBUTES TLV and a set of sub-TLVs for each of the attributes. The sub-TLVs are included if there is a change since the last information sent in the PCEP message. However, it lacks a mechanism to remove an attribute identified by the sub-TLV explicitly. This document updates RFC 8733 by defining the behaviour to remove an attribute explicitly. In addition, this updates allow applying this PCEP extensions to SR-TE LSPs (for both MPLS and IPv6 Data planes), in addition to MPLS-TE LSPs.

Introduction describes the Path Computation Element Communication Protocol (PCEP). PCEP defines the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between PCEs, enabling computation of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP) characteristics. specifies extensions to PCEP to enable stateful control of MPLS TE LSPs. It describes two modes of operation - Passive stateful PCE and Active stateful PCE. Further, describes the setup, maintenance and teardown of PCE-Initiated LSPs for the stateful PCE model. PCEP Extensions for Segment Routing (SR) specifies extensions to PCEP that allow a stateful PCE to compute and initiate TE paths, as well as a PCC to request a path subject to certain constraint(s) and optimization criteria for Segment Routing. extends PCEP for Segment Routing for IPv6 data plane. As specified in , an LSP can be MPLS-TE LSP or SR-TE LSP based on the path setup type. As specified in , the term "LSP" used in the PCEP specifications for SRv6 would be equivalent to an SRv6 path (represented as a list of SRv6 segments). describes the auto-bandwidth feature that allows automatic and dynamic adjustment of the TE LSP bandwidth reservation based on the volume of traffic flowing through the LSP. It describes PCEP extensions for auto-bandwidth adjustment when employing an active stateful PCE for both PCE-initiated and PCC-initiated LSPs. It defines the AUTO-BANDWIDTH-ATTRIBUTES TLV that provides the 'configurable knobs' of the feature, and it can be included as an optional TLV in the LSPA object. The TLV is encoded in all PCEP messages for the LSP while the auto-bandwidth adjustment feature is enabled. The absence of the TLV indicates the PCEP speaker wishes to disable the feature. The TLV includes multiple AUTO-BANDWIDTH-ATTRIBUTES sub-TLVs defined in . The AUTO-BANDWIDTH-ATTRIBUTES sub-TLVs are included if there is a change since the last information was sent in the PCEP message. It also states that in the case of a missing sub-TLV, as per the local policy, either the default value or some other operator-configured value is used. Since the missing sub-TLV in a subsequent PCEP message is considered to indicate no change, there is no mechanism to remove a particular attribute encoded in the sub-TLV. This document updates to define such a procedure. Note that for the attributes that have an associated default value, they could simply encode the default value in the sub-TLV, but this cannot be used for the attributes that do not have a default value. This document proposes to use a special value of all zeros to indicate "restore to default", which could mean going back to the default values or removal of the attribute itself. The following table includes the sub-TLVs and the default values as per .

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, the use of the special value of all zeros in the value portion of the sub-TLV can be used to indicate "restore to default", which could mean :

• if an explicit default value is set for the sub-TLV:
  • Restore to the default values
• 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 consists of encoded data (of the specified length and type), which is set to zero. In cases where the value portion of the sub-TLV contains multiple fields, all fields are set to zero.

Conventions 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.

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

PCEP Extensions Section 5.1.1 of defines the AUTO-BANDWIDTH-CAPABILITY TLV as an optional TLV for use in the OPEN Object for auto-bandwidth adjustment. This document adds a new flag - Z (TBD): The flag indicates that a PCEP speaker supports the use of the special value of all zeros in the value field as specified in this document. The presence of the Z flag can give a clear indication to the PCEP peer whether they can use 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 sec)
• Adjustment-Interval: 172800 (2 days in sec)
• Adjustment-Threshold: 0x49989680 (10 Mbps in bps)

Now, if the PCE would like to not use the Adjustment-Thresholds feature for the LSP and set the Adjustment-Interval to 1 day, it could 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

On receiving the special value of all zeros in the value portion of the Adjustment-Threshold sub-TLV, the PCEP speaker would consider that to be the removal of the Adjustment-Threshold feature. Note that, the PCE could also set the Adjustment-Interval: 0x0 instead of the default value to trigger the restore to default. 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

Now, if the PCC receives an update with Sample-Interval with the special value of all zeros, this will lead to Sample-Interval being set to the default value of 300.

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)

Now, if the PCC receives an update with Down-Adjustment-Threshold with the special value of all zeros, this will lead to the removal of the Down-Adjustment-Threshold attribute and only Adjustment-Threshold remains. If the PCC receives an update with Adjustment-Threshold with the special value of all zeros, this will lead to the removal of the Adjustment-Threshold attribute as well.

Auto-Bandwidth for Segment Routing LSPs The PCEP extensions defined in for the MPLS-TE LSP path setup type, apply equally to the SR-TE LSP path setup types, for both SR-MPLS and SRv6 data planes.

Backward Compatibility Note that to achieve the same objective, an compliant implementation could send a PCEP message without the AUTO-BANDWIDTH-ATTRIBUTES TLV first and then include the AUTO-BANDWIDTH-ATTRIBUTES TLV with the updated sub-TLV. This is the same as "turning it off and on again", but would cause unnecessary path computation churn (compared to 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.

Security Considerations This document does not add any substantial new security concerns beyond those already discussed in . 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. IANA created a registry to manage the Flag field of the AUTO-BANDWIDTH-CAPABILITY TLV within the "Path Computation Element Protocol (PCEP) Numbers" registry group. This document requests IANA to allocate a new bit in the AUTO-BANDWIDTH-CAPABILITY TLV Flag Field registry, as follows. IANA is requested to make allocations starting from the least significant bit (31).

Bit	Description	Reference
TBD	Z flag (special value of all zeros)	[This.I-D]

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Stateful PCE extensions allow stateful control of MPLS-TE Label Switched Paths (LSPs) using PCEP. The auto-bandwidth feature allows automatic and dynamic adjustment of the TE LSP bandwidth reservation based on the volume of traffic flowing through the LSP. This document describes PCEP extensions for auto-bandwidth adjustment when employing an active stateful PCE for both PCE-initiated and PCC-initiated LSPs. Informative References Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks. This document updates RFC 8408. Segment Routing (SR) can be used to steer packets through a network using the IPv6 or MPLS data plane, employing the source routing paradigm. An SR Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since SR can be applied to both MPLS and IPv6 data planes, a PCE should be able to compute an SR Path for both MPLS and IPv6 data planes. The Path Computation Element Communication Protocol (PCEP) extension and mechanisms to support SR-MPLS have been defined. This document outlines the necessary extensions to support SR for the IPv6 data plane within PCEP.

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