PCEP Extensions for Path Delay Difference

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 14 December 2026.¶

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

Table of Contents

1. Introduction

PCEP [RFC5440] 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 [RFC8233] 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: [I-D.ietf-pce-multipath] 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 [RFC9256].¶
• Point-to-Multipoint (P2MP): A P2MP LSP [RFC5671] 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 [RFC8655], 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.¶

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. 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 [RFC8233].¶

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).¶

4. Extensions to METRIC Object

5. 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 [I-D.ietf-pce-pcep-pmtu].¶

6. Security Considerations

This document defines a new METRIC type that does not add any new security concerns beyond those discussed in [RFC5440] 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) [RFC5925] or PCEPS [RFC8253]. The procedure based on Transport Layer Security (TLS) in [RFC8253] is considered a security enhancement and thus is much better suited for sensitive service-aware information.¶

7. 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:¶

Author's Address