PCEP Extension for Path Rate

Introduction The Path Computation Element (PCE) Communication Protocol (PCEP), defined in , 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 and PCE-initiated LSP setup , 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. 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.

Conventions Used in This Document

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.

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.

PCEP Exensions

METRIC Object

Path Rate Metric The METRIC object is defined in Section 7.8 of , 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.

Objective Function

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)}.
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: 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.

Operations

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. Note that 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 .

Stateful PCE and PCE-Initiated LSPs The new metric type defined in this document can also be used with the stateful PCE extensions and PCE-initiated LSP extensions . The format of PCEP messages described in and uses intended-attribute-list and attribute-list, respectively (where the intended-attribute-list is the attribute-list defined in Section 6.5 of ). 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).

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. specifies PCEP extensions for SR-TE LSPs for the MPLS data plane, and 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.

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. A future update of this document may extend the PRate computation to each segment list level, aligned with the multipath extensions defined in . 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 , 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: 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.

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

IANA Considerations This document requests the following IANA actions.

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:

Objective Function Code IANA maintains the "PCEP Objective Function" registry. IANA is requested to make the following allocation:

PCEP Error Type and Value IANA maintains the "PCEP-ERROR Object Error Types and Values" registry. IANA is requested to make the following allocation: 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.