PCEP Extensions for Path Delay Difference

Introduction PCEP is a communication protocol between a Path Computation Client (PCC) and a Path Computation Element (PCE) that allows a PCC to request path computation. PCEP supports the PCC to include various constraints in the request, such as bandwidth, hop count, affinity, and link/node/SRLG disjointness, enabling the PCE to compute paths that satisfy service requirements. Furthermore, RFC 8233 extends the METRIC object to support path delay, delay variation, packet loss, and other performance constraints. A single PCEP LSP can contain multiple forwarding paths. Typical cases include:

Load Balancing: defines a generic mechanism to carry multiple Explicit Route Objects (EROs) within a single PCEP LSP. It can be used to signal multiple paths and indicate equal or unequal load-balancing amongst the set of multipaths, e.g., multiple Segment Lists within an SR Policy Candidate Path .
Point-to-Multipoint (P2MP): A P2MP LSP originates from a root and branches out to multiple leaves. Although logically a single LSP, it actually comprises multiple independent branch paths from the root to different leaves.

In some cases, it is required that the end-to-end delay difference among the different paths (or branches) be controlled within a certain range. For many data center networks whose link transmission distances are short and relatively uniform, the delay difference among multiple paths is typically stable and can be well controlled, however, for wide area networks (WANs), links may traverse long distances with varying latencies (e.g., fiber length differences, different propagation media, or diverse geographical routes). As a result, the delay difference among multiple paths can be significant and dynamic, posing challenges to load-balancing and synchronization. Some cases are list below:

In load balancing scenarios, when per-flow ECMP is used, different flows belonging to the same service may be hashed to paths with substantially different delays. This may lead to uneven completion times for tasks that require collective communication (e.g., in distributed storage or AI training), ultimately degrading application-level performance. Besides,In emerging intelligent computing WAN scenarios, fine-grained load-balancing techniques such as per-packet spraying or flowlet-based switching are being explored to address the "elephant flow" problem. However, these techniques are highly sensitive to path delay differences. Excessive end-to-end delay disparity can cause severe packet reordering at the receiver, leading to increased reordering buffer pressure or even packet loss.
In P2MP scenarios, excessive delay difference among different leaf paths causes loss of synchronization among different receivers, negatively impacting user experience in services such as video conferencing and live streaming.
In Deterministic Networking (DetNet) scenarios , the Packet Replication and Elimination Functions (PREOF) require that the delay difference among redundant paths be bounded. Otherwise, the elimination buffer must be dimensioned larger, increasing end-to-end latency and jitter, which may violate the deterministic service guarantees.

Therefore, a mechanism is needed that allows a PCC to request that, when computing multiple forwarding paths of an LSP, the delay difference among paths/branches does not exceed a specified threshold. This document defines a new METRIC type, Multipath Delay Difference (MDD), to address this requirement in PCEP.

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.

Terminology This document uses the following terms:

Path Delay:: The end-to-end unidirectional delay of a single path (encoded as an ERO), expressed in microseconds, computed as the sum of link delays along the path .
Multipath Delay Difference (MDD):: For a given LSP, the difference between the maximum and minimum Path Delay among all constituent paths of that LSP.
Constituent Paths:: Multiple EROs associated with the same LSP, representing multiple forwarding paths (e.g., multiple Segment Lists of an SR Policy Candidate Path or multiple branches of a P2MP LSP).

Extensions to METRIC Object

Multipath Delay Difference (MDD) 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 to represent the maximum delay difference among multiple paths within an LSP: * T = TBD1: Multipath Delay Difference (MDD) * An LSP may contain M constituent paths {Pj, (j=1...M)}. * The Path Delay of a constituent path P is denoted D(P), as defined in (Section 3.1.1). * The Multipath Delay Difference (MDD) metric for the LSP = max{D(Pj)} - min{D(Pj)}. The MDD metric represents the difference between the maximum Path Delay and the minimum Path Delay among all constituent paths of the same LSP. The encoding for the MDD metric value is quantified in units of microseconds and encoded in IEEE floating point format. The conversion from 24-bit integer (as used in IGP TE metric extensions ) to 32-bit IEEE floating point may introduce some loss of precision, which is considered acceptable for typical deployments. A PCC MAY use the MDD metric in a Path Computation Request (PCReq) message to request a set of paths within an LSP meeting the end-to-end delay difference requirement. In this case, the B bit MUST be set to indicate a bound (a maximum) for the delay difference among the constituent paths that MUST NOT be exceeded for the PCC to consider the computed set of paths as acceptable. The MDD 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 the PCE to return the computed MDD value for the set of paths. In this case, the C bit MUST be set. A PCE MAY use the MDD metric in a Path Computation Reply (PCRep) message along with a NO-PATH object when the PCE cannot compute a set of paths meeting this constraint. A PCE MAY also use this metric to send the computed MDD value to the PCC when the C bit was set in the corresponding request. Note that allows two METRIC object instances for optimization (B flag cleared) and thus the MDD metric may be used alongside other metric types (e.g., Path Delay) to simultaneously request both absolute delay constraints and relative delay difference constraints.

Error Handling The error handling and processing of the METRIC object is as specified in . If a PCE does not recognize the MDD metric type and the P flag is set, it MUST send a PCErr message with Error-Type = 3 ("Unknown Object") or Error-Type = 4 ("Not supported object") as appropriate. If the P flag is cleared, the PCE MAY ignore the MDD metric.

Operational Considerations The usage of MDD Metric itself is not limited to the cases introduced in this document, but it is only meaningful when an LSP has multiple constituent paths. Therefore, if a PCC or PCE receives a PCEP message containing an MDD metric for an LSP that does not have (or is not requested to have) multiple paths, the MDD metric SHOULD be ignored. Specifically:

If a PCE receives a PCReq message with an MDD metric but the request does not imply multiple paths, the PCE SHOULD ignore the MDD metric.
If a PCC receives a PCRep or PCUpd/PCInitiate message containing an MDD metric but only a single path is provided, the PCC SHOULD ignore the MDD metric.

An implementation MAY choose not to support the use of this metric type for a particular Path Setup Type (PST) as a local policy. In such case, when receiving a request with the MDD metric and the P flag set, the implementation MUST respond with a PCErr message with Error-Type = 5 ("Policy Violation") and Error-value = TBD2 ("Metric Type not supported with this PST") as in .

Security Considerations This document defines a new METRIC type that does not add any new security concerns beyond those discussed in in itself. Some deployments may find the MDD information to be extra sensitive, as it could reveal network performance characteristics that could be used to influence path computation and setup with adverse effect. Additionally, snooping of PCEP messages with such data or using PCEP messages for network reconnaissance may give an attacker sensitive information about the operations of the network. Thus, such deployments should employ suitable PCEP security mechanisms like TCP Authentication Option (TCP-AO) or PCEPS . The procedure based on Transport Layer Security (TLS) in is considered a security enhancement and thus is much better suited for sensitive service-aware information.

IANA Considerations This document defines a new metric type for the PCEP. IANA is requested to allocate the following codepoint in the PCEP "METRIC Object T Field" registry: METRIC Object T Field Registry

Value	Description	Reference
TBD1	Multipath Delay Difference (MDD)	This document