PCE Y. Liu Internet-Draft ZTE Corporation Intended status: Standards Track 12 June 2026 Expires: 14 December 2026 PCEP Extensions for Path Delay Difference draft-liu-pce-path-delay-difference-00 Abstract In certain scenarios, such as load balancing, P2MP and DetNet, it is required that the delay difference among a set of paths to be controled within an expected range. This document describes extensions to PCEP to use the delay difference as a constraint for end-to-end path computation. 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. Liu Expires 14 December 2026 [Page 1] Internet-Draft PCEP for Path Delay Difference June 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Extensions to METRIC Object . . . . . . . . . . . . . . . . . 4 4.1. Multipath Delay Difference (MDD) Metric . . . . . . . . . 4 4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 5 5. Operational Considerations . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 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 Liu Expires 14 December 2026 [Page 2] Internet-Draft PCEP for Path Delay Difference June 2026 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. Liu Expires 14 December 2026 [Page 3] Internet-Draft PCEP for Path Delay Difference June 2026 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 4.1. Multipath Delay Difference (MDD) 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 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 [RFC8233] (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 [RFC7471] [RFC7810]) to 32-bit IEEE floating point may introduce some loss of precision, which is considered acceptable for typical deployments. Liu Expires 14 December 2026 [Page 4] Internet-Draft PCEP for Path Delay Difference June 2026 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 [RFC5440] 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. 4.2. Error Handling The error handling and processing of the METRIC object is as specified in [RFC5440]. 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. 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. Liu Expires 14 December 2026 [Page 5] Internet-Draft PCEP for Path Delay Difference June 2026 * 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: +=======+==================================+===============+ | Value | Description | Reference | +=======+==================================+===============+ | TBD1 | Multipath Delay Difference (MDD) | This document | +-------+----------------------------------+---------------+ Table 1: METRIC Object T Field Registry 8. References 8.1. Normative References [I-D.ietf-pce-multipath] Koldychev, M. and S. Sidor, "Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Liu Expires 14 December 2026 [Page 6] Internet-Draft PCEP for Path Delay Difference June 2026 Multipath Information", Work in Progress, Internet-Draft, draft-ietf-pce-multipath-27, 9 June 2026, . [I-D.ietf-pce-pcep-pmtu] Peng, S., Li, C., Han, L., Ndifor, L., and S. Sidor, "Support for Path MTU (PMTU) in the Path Computation Element (PCE) Communication Protocol (PCEP)", Work in Progress, Internet-Draft, draft-ietf-pce-pcep-pmtu-09, 20 February 2026, . [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, . [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, . [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 7810, DOI 10.17487/RFC7810, May 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, "Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 2017, . 8.2. Informative References Liu Expires 14 December 2026 [Page 7] Internet-Draft PCEP for Path Delay Difference June 2026 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, DOI 10.17487/RFC5671, October 2009, . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . [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, . [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, . [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, . Author's Address Yao Liu ZTE Corporation Nanjing China Email: liu.yao71@zte.com.cn Liu Expires 14 December 2026 [Page 8]