PCEP Extension for Path Rate
draft-xl-pce-pcep-pathrate-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Quan Xiong , Jinming Li | ||
| Last updated | 2026-10-29 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-xl-pce-pcep-pathrate-00
pce Q. Xiong
Internet-Draft ZTE Corporation
Intended status: Standards Track J. Li
Expires: 3 May 2027 China Mobile
30 October 2026
PCEP Extension for Path Rate
draft-xl-pce-pcep-pathrate-00
Abstract
This document specifies extensions for PCEP to carry a Path Rate
(PRate), enabling a PCE to compute and distribute the maximum
sustainable rate for an end-to-end path. A new METRIC type and a new
objective function are defined.
Status of This Memo
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 3 May 2027.
Copyright Notice
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.
Xiong & Li Expires 3 May 2027 [Page 1]
Internet-Draft PCEP Extension for Path Rate October 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. PCEP Exensions . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1. Path Rate Metric . . . . . . . . . . . . . . . . . . 4
3.2. Objective Function . . . . . . . . . . . . . . . . . . . 4
3.2.1. Path Rate Objective Function . . . . . . . . . . . . 4
4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. PCReq and PCRep Messages . . . . . . . . . . . . . . . . 5
4.2. Stateful PCE and PCE-Initiated LSPs . . . . . . . . . . . 6
4.3. Segment Routing . . . . . . . . . . . . . . . . . . . . . 6
4.4. Multipath and P2MP Considerations . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6.1. METRIC Type . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Objective Function Code . . . . . . . . . . . . . . . . . 7
6.3. PCEP Error Type and Value . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The Path Computation Element (PCE) Communication Protocol (PCEP),
defined in [RFC5440], enables communication between a Path
Computation Client (PCC) and a PCE for the computation of
Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Traffic Engineering Label Switched Paths (TE LSPs). With the
introduction of stateful PCE extensions [RFC8231] and PCE-initiated
LSP setup [RFC8281], the PCE can actively manage and program paths in
the network.
In emerging AI computing networks, collective communication patterns
such as All-Reduce and All-to-All generate massive synchronized
bursts upon the completion of each computation phase. These bursts
can saturate switch buffers within microseconds, causing micro-burst
congestion, packet drops, and GPU starvation. Conventional
congestion control mechanisms (e.g., PFC, ECN/DCQCN, HPCC) rely on
the feedback loops and therefore typically cannot adjust the sending
rate in a timely manner to prevent the burst from impacting the
network.
Xiong & Li Expires 3 May 2027 [Page 2]
Internet-Draft PCEP Extension for Path Rate October 2026
To address this problem, this document introduces the concept of Link
Burst Rate, the maximum instantaneous burst rate that a node's egress
port can sustain. A controller or PCE collects Link Burst Rate
information and it can be associated with the network information via
telemetry such as queuing buffer, RTT and so on. The PCE computes
the Path Rate (PRate) for an end-to-end path as the minimum Link
Burst Rate across all links on the path and distributes this PRate
value to network nodes via PCEP.
This document defines:
*A new METRIC type "Path Rate" for the PCEP METRIC object;
*A new objective function MIN-PRate for optimizing the path rate
during path computation;
*Procedures for stateful PCE, PCE-initiated LSPs, and Segment Routing
(SR) scenarios.
2. Conventions Used in This Document
2.1. Terminology
* Link Burst Rate (LBRate): indicates the upper limit of the link
burst rate. It defines the upper bound of the burst rate over a
given link. This parameter can be measured, configured, or
computed.
* Path Rate (PRate): indicate the minimum link burst rate of all the
links in a path between a source node and a destination node. It
is used as rate limit and the maximum rate for that path,
expressed in bytes per second.
2.2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. PCEP Exensions
3.1. METRIC Object
Xiong & Li Expires 3 May 2027 [Page 3]
Internet-Draft PCEP Extension for Path Rate October 2026
3.1.1. Path Rate Metric
The METRIC object is defined in Section 7.8 of [RFC5440], comprising
metric-value and metric-type (T field), and a flags field, comprising
a number of bit flags (B "Bound" bit and C "Computed Metric" bit).
This document defines a new type for the METRIC object for Path Rate.
* T = TBD: Path Rate.
* A network comprises of a set of N links {Li, (i=1...N)}.
* A path P of an LSP is a list of K links {Lpi,(i=1...K)}.
* A Link Burst Rate of link L is denoted LBRate(L).
* As an optional computation method, the Link Burst Rate may be
derived LBRate(L) = (BufferSize(L) * 8) / RTT(L).
* The BufferSize(L) is the buffer size at the egress port of the
link l, in bytes.
* The RTT(L) is the round-trip propagation delay of the link L, in
seconds.
* A Path Rate metric for the path PRate(P) = Min { LBRate(L_pi) , i
= 1...K }.
The Path Rate metric type of the METRIC object in PCEP represents the
minimum of the Link Burst Rate of all links along the path.
3.2. Objective Function
3.2.1. Path Rate Objective Function
The description of the new objective function is as follows:
* Objective Function Code: TBD2
* Name: Minimum Path Rate (MIN-PRate)
* Description: Selects the path with the maximum PRate, i.e.,
maximizes the minimum Link Burst Rate along the path, thereby
providing the highest sustainable rate for the computed path.
The objective function is formulated using the following terminology:
* A network comprises a set of N links {L_i, (i=1...N)}.
Xiong & Li Expires 3 May 2027 [Page 4]
Internet-Draft PCEP Extension for Path Rate October 2026
* A path P is a list of K links {L_pi,(i=1...K)}.
* The Link Burst Rate of link L is denoted R(L).
* The PRate of a path P is denoted PRate(P), where PRate(P) = Min {
R(L_pi), i=1...K }.
* The MIN-PRate OF is to find a path P such that ( Min { R(L_pi),
i=1...K } ) is maximized.
Formally:
MAX_{P} ( Min_{i=1...K} R(L_pi) )
When a PCC requests the MIN-PRate objective function, the PCE SHOULD
compute a path that maximizes the PRate subject to all other
constraints. If no such path can be found that satisfies all
constraints, the PCE SHOULD return a NO-PATH object indicating the
reason for failure.
4. Operations
4.1. PCReq and PCRep Messages
When the PCE computes the path, it can also compute the PRate and
include this information in the METRIC object with the metric type in
the PCEP message when replying to the PCC. In a Path Computation
Reply (PCRep) message, the PCE MAY insert the METRIC object with an
Explicit Route Object (ERO) so as to provide the Path Rate METRIC for
the computed path. The PCE MAY also insert the METRIC object with a
NO-PATH object to indicate that the metric constraint could not be
satisfied.
Further, a PCC MAY use the Path Rate metric in a Path Computation
Request (PCReq) message to request a path meeting the burst rate
requirement of the path. In this case, the B bit MUST be set to
suggest a bound (a minimum) for the Path Rate metric that MUST NOT be
subceeded for the PCC to consider the computed path as acceptable.
The Path Rate metric must be less than or equal to the value
specified in the metric-value field.
A PCC can also use this metric to request that the PCE optimize the
path rate during path computation. In this case, the B bit MUST be
cleared. The PCE SHOULD use the MIN-PRate objective function to
maximize the PRate of the computed path.
Xiong & Li Expires 3 May 2027 [Page 5]
Internet-Draft PCEP Extension for Path Rate October 2026
Note that [RFC5440] allows two METRIC object instances for
optimization (B flag cleared); thus, the Path Rate metric object
might be used alongside other metric types as well.
The error handling and processing of the METRIC object is as
specified in [RFC5440].
4.2. Stateful PCE and PCE-Initiated LSPs
The new metric type defined in this document can also be used with
the stateful PCE extensions [RFC8231] and PCE-initiated LSP
extensions [RFC8281]. The format of PCEP messages described in
[RFC8231] and [RFC8281] uses intended-attribute-list and attribute-
list, respectively (where the intended-attribute-list is the
attribute-list defined in Section 6.5 of [RFC5440]).
A PCE MAY include the Path Rate metric in a PCInitiate or PCUpd
message to inform the PCC of the PRate calculated for the path or as
a bound constraint. A PCC MAY include the Path Rate metric as a
bound constraint or to indicate an optimization criterion (similar to
PCReq).
4.3. Segment Routing
A Segment Routed path (SR path) can be derived from an IGP Shortest
Path Tree (SPT). Segment Routed Traffic Engineering paths (SR-TE
paths) may not follow the IGP SPT. Such paths may be chosen by a PCE
taking into account various constraints and objective functions.
[RFC8664] specifies PCEP extensions for SR-TE LSPs for the MPLS data
plane, and [RFC9603] extends PCEP to support SR for the IPv6 data
plane. The extensions defined in this document are fully compatible
with both SR-MPLS and SRv6 scenarios. The PCE includes the Path Rate
METRIC object alongside the SR-ERO (or SRv6-ERO) in PCInitiate,
PCUpd, or PCRep messages.
Upon receiving the PRate, the SR headend configures the rate limiter
for the corresponding SR policy or candidate path.
For SRv6, the headend applies rate limiting to the flow matching the
SRv6 SID list.
4.4. Multipath and P2MP Considerations
For multipath scenarios where a single SR policy comprises multiple
candidate paths or segment lists, the METRIC object is currently
encoded at the candidate path level. The PRate for each candidate
path is computed independently as the minimum Link Burst Rate across
its constituent links.
Xiong & Li Expires 3 May 2027 [Page 6]
Internet-Draft PCEP Extension for Path Rate October 2026
A future update of this document may extend the PRate computation to
each segment list level, aligned with the multipath extensions
defined in [RFC10066]. The procedures for such per-segment-list
PRate distribution are out of scope for this version and may be
addressed in subsequent revisions.
The support for point-to-multipoint (P2MP) trees is also out of scope
for this version. Future revisions will leverage the P2MP framework
defined in [RFC8306], which introduces the P2MP bit (N-bit) in the RP
object and the P2MP END-POINTS object to signal P2MP path computation
requests and replies. When P2MP support is added, a new METRIC type
"P2MP Path Rate" will be defined, where the P2MP PRate for a tree T
is computed as:
P2MP PRate(T) = Minimum { PRate(Dest_j), j=1...M }
where PRate(Dest_j) is the P2P Path Rate for the path to destination
Dest_j, and M is the total number of destinations in the P2MP tree.
This reflects the fact that the source injection rate for the entire
tree must be capped at the most restrictive (minimum) PRate among all
destination paths to avoid congestion on any branch.
5. Security Considerations
This document defines a new METRIC type and a new objective function
for PCEP. These extensions do not introduce new security concerns
beyond those discussed in [RFC5440] and [RFC8253].
6. IANA Considerations
This document requests the following IANA actions.
6.1. METRIC Type
IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
registry group. Within this registry group, IANA maintains a
registry for "METRIC Object T Field". IANA is requested to make the
following allocation:
Value Description Reference
--------- --------------- --------------
TBD1 Path Rate This document
6.2. Objective Function Code
IANA maintains the "PCEP Objective Function" registry. IANA is
requested to make the following allocation:
Xiong & Li Expires 3 May 2027 [Page 7]
Internet-Draft PCEP Extension for Path Rate October 2026
Code Name Description
--------- --------------- --------------
TBD2 MIN-PRate Maximizes the minimum Link Burst Rate
along the path (i.e., maximizes PRate)
6.3. PCEP Error Type and Value
IANA maintains the "PCEP-ERROR Object Error Types and Values"
registry. IANA is requested to make the following allocation:
Error-Type Error-Value Meaning
------------ ---------------- ---------------------------------
5 TBD3 Metric Type not supported with this PST
When a PCEP speaker receives a METRIC object with T = TBD1 (Path
Rate) for a path setup type (PST) that the implementation does not
support, it MUST respond with a PCErr message with Error-Type = 5 and
Error-value = TBD3.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/rfc/rfc5440>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/rfc/rfc8231>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/rfc/rfc8253>.
Xiong & Li Expires 3 May 2027 [Page 8]
Internet-Draft PCEP Extension for Path Rate October 2026
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/rfc/rfc8281>.
[RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King,
"Extensions to the Path Computation Element Communication
Protocol (PCEP) for Point-to-Multipoint Traffic
Engineering Label Switched Paths", RFC 8306,
DOI 10.17487/RFC8306, November 2017,
<https://www.rfc-editor.org/rfc/rfc8306>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/rfc/rfc8664>.
[RFC9603] Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M.,
and Y. Zhu, "Path Computation Element Communication
Protocol (PCEP) Extensions for IPv6 Segment Routing",
RFC 9603, DOI 10.17487/RFC9603, July 2024,
<https://www.rfc-editor.org/rfc/rfc9603>.
[RFC10066] Koldychev, M., Ed. and S. Sidor, Ed., "Path Computation
Element Communication Protocol (PCEP) Extensions for
Signaling Multipath Information", RFC 10066,
DOI 10.17487/RFC10066, October 2026,
<https://www.rfc-editor.org/rfc/rfc10066>.
7.2. Informative References
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/rfc/rfc8754>.
Authors' Addresses
Quan Xiong
ZTE Corporation
Email: xiong.quan@zte.com.cn
Jinming Li
China Mobile
Email: lijinming@chinamobile.com
Xiong & Li Expires 3 May 2027 [Page 9]