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, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [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, . 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, . [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, . [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, . [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, . [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, . 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, . 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]