PCEP Extensions for Path Delay Difference
draft-liu-pce-path-delay-difference-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Yao Liu | ||
| Last updated | 2026-06-12 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liu-pce-path-delay-difference-00
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
multipath-27>.
[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, <https://datatracker.ietf.org/doc/html/
draft-ietf-pce-pcep-pmtu-09>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[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,
<https://www.rfc-editor.org/info/rfc7471>.
[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,
<https://www.rfc-editor.org/info/rfc7810>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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, <https://www.rfc-editor.org/info/rfc8233>.
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,
<https://www.rfc-editor.org/info/rfc5671>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[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,
<https://www.rfc-editor.org/info/rfc8253>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
[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,
<https://www.rfc-editor.org/info/rfc9256>.
Author's Address
Yao Liu
ZTE Corporation
Nanjing
China
Email: liu.yao71@zte.com.cn
Liu Expires 14 December 2026 [Page 8]