idr Q. Xiong Internet-Draft ZTE Corporation Intended status: Standards Track P. Liu Expires: 23 April 2026 China Mobile R. Gandhi Cisco Systems, Inc. 20 October 2025 PCEP Extension for Bounded Latency draft-xiong-pce-detnet-bounded-latency-06 Abstract In certain networks, such as Deterministic Networking (DetNet), it is required to consider the bounded latency for path selection. This document describes the extensions for Path Computation Element Communication Protocol (PCEP) to carry the bounded latency constraints and distribute deterministic paths for end-to-end path computation in deterministic services. 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 23 April 2026. Copyright Notice Copyright (c) 2025 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 Xiong, et al. Expires 23 April 2026 [Page 1] Internet-Draft PCEP Extension for Bounded Latency October 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. End-to-End Minimum Latency Metric . . . . . . . . . . 4 3.1.2. End-to-End Maximum Latency Metric . . . . . . . . . . 4 3.1.3. End-to-End Latency Variation Metric . . . . . . . . . 5 3.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Deterministic Path ERO Subobject . . . . . . . . . . . . 5 3.3.1. DLI Information for Right-bounded . . . . . . . . . . 7 3.3.2. DLI for Flow level Periodic Bounded . . . . . . . . . 8 3.3.3. DLI for Class Level Periodic Bounded . . . . . . . . 8 3.3.4. DLI for Flow Level Non-periodic Bounded . . . . . . . 8 3.3.5. DLI for Class Level Non-periodic Bounded . . . . . . 9 3.3.6. DLI for Flow Level Rate-based Unbounded . . . . . . . 10 3.3.7. DLI for Flow Level Rate-based Left-bounded . . . . . 10 3.4. Deterministic Path RRO Subobject . . . . . . . . . . . . 11 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Calculation of End-to-end Bounded Latency . . . . . . . . 11 4.2. Metric types . . . . . . . . . . . . . . . . . . . . . . 12 4.3. ERO and RRO Subobjects . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6.1. New Metric Types . . . . . . . . . . . . . . . . . . . . 13 6.2. New LSP-EXTENDED-FLAG Flag Registry . . . . . . . . . . . 14 6.3. New ERO Subobject . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction [RFC5440] describes the Path Computation Element Protocol (PCEP) which is used between a Path Computation Element (PCE) and a Path Computation Client (PCC) (or other PCE) to enable computation of Multi-protocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP). PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set of extensions to PCEP to enable active control of MPLS-TE and Generalized MPLS (GMPLS) tunnels. Xiong, et al. Expires 23 April 2026 [Page 2] Internet-Draft PCEP Extension for Bounded Latency October 2025 As depicted in [RFC4655], a PCE MUST be able to compute the path of a TE LSP by operating on the TED and considering bandwidth and other constraints applicable to the TE LSP service request. The constraint parameters are provided such as metric, bandwidth, delay, affinity, etc. However these parameters did not take into account the bounded latency requirements. According to [RFC8655]}, Deterministic Networking (DetNet) operates at the IP layer and delivers service which provides extremely low data loss rates and bounded latency within a network domain. The bounded latency indicates the minimum and maximum end-to-end latency from source to destination and bounded jitter (packet delay variation). [I-D.ietf-detnet-scaling-requirements] has described the enhanced requirements for DetNet data plane including the information used by functions ensuring deterministic latency should be supported. And queuing mechanisms and solutions require different information to help the functions of ensuring deterministic latency, including regulation, queue management. [I-D.ietf-detnet-dataplane-taxonomy] has defined the classification criteria and the suitable categories for this solutions. The computing method of end-to-end delay bounds is defined in [RFC9320]. It is the sum of the 6 delays in DetNet bounded latency model. And these delays should be measured and collected by IGP, but the related mechanisms are out of this document. The end-to-end delay bounds can also be computed as the sum of non queuing delay bound and queuing delay bound along the path. The upper bounds of non queuing delay are constant and depend on the specific network and the value of queuing delay bound depends on the queuing mechanisms deployed along the path. The queuing delay may differ notably in their specific queuing solutions, which should be selected and calculated by the controller (or PCE). The deterministic latency information related to each queuing mechanism should also be distributed. As per [I-D.ietf-detnet-controller-plane-framework], explicit path should be calculated and established in control plane to guarantee the deterministic transmission. The corresponding IS-IS and OSPF extensions are specified in [I-D.peng-lsr-deterministic-traffic-engineering]. When the PCE is deployed, the path computation should be applicable for deterministic networks. It is required that bounded latency including minimum and maximum end-to-end latency and bounded delay variation are considered during the deterministic path selection for PCE. The bounded latency constraints should be extended for PCEP. Moreover, the queuing-based parameters along the deterministic path should be provided to the PCC after the path computation such as deterministic latency information. Xiong, et al. Expires 23 April 2026 [Page 3] Internet-Draft PCEP Extension for Bounded Latency October 2025 This document describes the extensions for PCEP to carry bounded latency constraints and distribute deterministic paths for end-to-end path computation in deterministic services. 1.1. 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. 2. Terminology The terminology is defined as [RFC8655] and [RFC5440]. 3. PCEP Extensions 3.1. METRIC Object 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 bit and C bit). This document defines three types for the METRIC object to represent the end-to-end bounded latency. 3.1.1. End-to-End Minimum Latency Metric This document proposes the end-to-end minimum latency metric in PCEP to represent the lower bound of the end-to-end delay. The extensions for End-to-End Minimum Latency Metric are as following shown: *T=TBD1: End-to-End Minimum Latency Metric. *The value of End-to-End Minimum Latency Metric is the encoding in units of microseconds with 32 bits. *The B bit MUST be set to suggest a minimum bound for the end-to-end delay of deterministic path. The end-to-end delay must be no less than or equal to the value. 3.1.2. End-to-End Maximum Latency Metric This document proposes the end-to-end maximum latency metric in PCEP to represent the upper bound of the end-to-end delay. The extensions for End-to-End Maximum Latency Metric are as following shown: *T=TBD2: End-to-End Maximum Latency Metric. Xiong, et al. Expires 23 April 2026 [Page 4] Internet-Draft PCEP Extension for Bounded Latency October 2025 *The value of End-to-End Maximum Latency Metric is the encoding in units of microseconds with 32 bits. *The B bit MUST be set to suggest a maximum bound for the end-to-end delay of deterministic path. The end-to-end delay must be less than or equal to the value. 3.1.3. End-to-End Latency Variation Metric This document proposes the end-to-end latency variation metric in PCEP to represent the difference between the end-to-end upper latency and the end-to-end lower latency along a deterministic path. The extensions for End-to-End Latency Variation Metric are as following shown: *T=TBD3: End-to-End Latency Variation Metric. *The value of End-to-End Latency Variation Metric is the encoding in units of microseconds with 32 bits. *The B bit MUST be set to suggest a maximum bound for the end-to-end latency variation of deterministic path. The end-to-end latency variation must be less than or equal to the value. 3.2. LSP Object The LSP Object is defined in Section 7.3 of [RFC8231]. This document defines a new flag (D-flag) to present the deterministic path for the LSP-EXTENDED-FLAG TLV carried in LSP Object as defined in [RFC9357]. D (Request for Deterministic Path) : If the bit is set to 1, it indicates that the PCC requests PCE to compute the deterministic path. A PCE would also set this bit to 1 to indicate that the deterministic path is included by PCE and encoded in the PCRep, PCUpd or PCInitiate message. 3.3. Deterministic Path ERO Subobject The ERO (Explicit Route Object) specified in [RFC3209] and [RFC5440] can be used to carry a set of computed paths. In order to carry deterministic latency information, this document defines a new optional ERO subobject referred to as the Deterministic Path ERO subobject (DP-ERO). An ERO carrying a deterministic path consists of one or more ERO subobjects, and it MUST carry DP-ERO subobjects. An DP-ERO subobject is formatted as shown in the following figure: Xiong, et al. Expires 23 April 2026 [Page 5] Internet-Draft PCEP Extension for Bounded Latency October 2025 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type=TBD4 | Length | Class | DLI Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Deterministic Latency Information(variable, optional) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 DP-ERO subobject where: *L (1bit): The L bit is an attribute of the subobject. The L bit is set if the subobject represents a loose hop in the explicit route. If the bit is not set, the subobject represents a strict hop in the explicit route. *Type (8bits): Set to TBD4. *Length (8bits): Contains the total length of the subobject in octets. The Length MUST be at least 8 and MUST be a multiple of 4. *Class (8bits): indicates the deterministic forwarding class. *Deterministic Latency Information(DLI) Type (8bits): indicates the type of deterministic latency information with related queuing and scheduling metadata and it aglined with the suitable categories as defined in [I-D.ietf-detnet-dataplane-taxonomy] and shown in Figure 2. Xiong, et al. Expires 23 April 2026 [Page 6] Internet-Draft PCEP Extension for Bounded Latency October 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | DLI Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0x0000 | Unassigned | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0x0001 | Right-bounded | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0x0002 | Flow level periodic bounded | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0x0003 | Class level periodic bounded | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0x0004 | Flow level non-periodic bounded | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0x0005 | Class level non-periodic bounded | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0x0006 | Flow level rate based unbounded | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0x0007 | Flow level rate based left-bounded | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 DLI Type *Deterministic Latency Information(DLI) (variable): indicates the corresponding deterministic latency parameters. The format depends on the value in the DLI type and the following sections shows the examples of the information. 3.3.1. DLI Information for Right-bounded As per [I-D.ietf-detnet-dataplane-taxonomy], for solutions in the right-bounded category, a packet has only a maximum time bound. When the type is set to 0x0001, it should carry DLI for right-bounded category in the DP-ERO subobject with the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum time bound | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 DLI for Right-bounded *Maximum time bound: 32bits, indicates the required maximum time bound of a packet. Xiong, et al. Expires 23 April 2026 [Page 7] Internet-Draft PCEP Extension for Bounded Latency October 2025 3.3.2. DLI for Flow level Periodic Bounded As per [I-D.ietf-detnet-dataplane-taxonomy], the flow Level periodic bounded solutions define a set of time slots, which will be scheduled for flows or flow aggregates. When the type is set to 0x0002, it should carry DLI for flow level periodic bounded in the DP-ERO subobject with the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timeslot ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 DLI for Flow Level Periodic Bounded *Timeslot ID: indicates the identifier of the timeslot scheduled for a flow. 3.3.3. DLI for Class Level Periodic Bounded As per [I-D.ietf-detnet-dataplane-taxonomy], the periodic bounded solutions can be further categorized by the traffic granularity with class level subcategory. The class Level periodic bounded solutions define a set of cycles and each cycle will be scheduled for flows or flow aggregates within a class level. When the type is set to 0x0003, it should carry DLI for class level periodic bounded in the DP-ERO subobject with the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cycle ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 DLI for Class Level Periodic Bounded *Cycle ID (32bits): indicates the identifer which the queue applied for a node to forward DetNet flows within a class level. 3.3.4. DLI for Flow Level Non-periodic Bounded As per [I-D.ietf-detnet-dataplane-taxonomy], flow level non-periodic bounded solutions guarantee the minimum and maximum bounds of a packet in a flow or flow aggregate. Xiong, et al. Expires 23 April 2026 [Page 8] Internet-Draft PCEP Extension for Bounded Latency October 2025 When the type is set to 0x0004, it should carry DLI for flow level non-periodic bounded in the DP-ERO subobject with the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum time bound | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum time bound | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 DLI for Flow Level Non-periodic Bounded *Maximum time bound: 32bits, indicates the maximum time bound of a packet in a flow or flow aggregates. *Minimum time bound: 32bits, indicates the minimum time bound of a packet in a flow or flow aggregates. 3.3.5. DLI for Class Level Non-periodic Bounded As per [I-D.ietf-detnet-dataplane-taxonomy], class level non-periodic bounded solutions guarantee the minimum and maximum bounds of a packet within a class level. When the type is set to 0x0005, it should carry DLI for class level non-periodic bounded in the DP-ERO subobject with the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum time bound | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum time bound | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 DLI for Class Level Non-periodic Bounded *Maximum time bound: 32bits, indicates the maximum time bound of a packet within a class level. *Minimum time bound: 32bits, indicates the minimum time bound of a packet within a class level. Xiong, et al. Expires 23 April 2026 [Page 9] Internet-Draft PCEP Extension for Bounded Latency October 2025 3.3.6. DLI for Flow Level Rate-based Unbounded In flow level rate based unbounded category, the latency bound is primarily influenced by the ratio of a flow's maximum packet size, its allocated service rate and completion time. When the type is set to 0x0006, it should carry DLI for flow level rate based unbounded in the DP-ERO subobject with the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum packet size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Finish time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 DLI for Flow Level Rate-based Unbounded *Maximum packet size: 32 bits, indicates the maximum packet size of a flow. *Service rate: 32 bits, indicates the allocated service rate of a flow. *Finish time: 32 bits, indicates the required service completion time of a flow. 3.3.7. DLI for Flow Level Rate-based Left-bounded In flow level rate based left-bounded category, the latency bound is primarily influenced by the ratio of a flow's maximum packet size, its allocated service rate, start time and completion time. When the type is set to 0x0007, it should carry DLI for flow level rate based left-bounded in the DP-ERO subobject with the following format: Xiong, et al. Expires 23 April 2026 [Page 10] Internet-Draft PCEP Extension for Bounded Latency October 2025 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum packet size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Finish time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Eligible time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 DLI for Flow Level Rate-based Left-bounded *Maximum packet size: 32 bits, indicates the maximum packet size of a flow. *Service rate: 32 bits, indicates the allocated service rate of a flow. *Finish time: 32 bits, indicates the required service completion time of a flow. *Eligible time: 32bits, indicates the required service start time of a flow. 3.4. Deterministic Path RRO Subobject The Deterministic Path RECORD_ROUTE Object (DP-RRO) subobject is OPTIONAL. If used, it is carried in the RECORD_ROUTE Object (RRO). The subobject uses the standard format of an RRO subobject. The format of the DP-RRO subobject is the same as that of the DP-ERO subobject, but without the L flag. 4. Operations 4.1. Calculation of End-to-end Bounded Latency As per [RFC9320], the end-to-end delay bound can be computed as the sum of Output delay, Link delay, Frame preemption delay, Processing delay, Regulation delay and Queuing delay along a deterministic path like following: *per-hop_delay_bound = sum{Output delay + Link delay + Frame preemption delay + Processing delay + Regulation delay + Queuing delay}. *end_to_end_delay_bound = sum{per-hop_delay_bound(h),(h=1,2,...H)}. Xiong, et al. Expires 23 April 2026 [Page 11] Internet-Draft PCEP Extension for Bounded Latency October 2025 As per [RFC9320], it also can be encoded as the sum of non queuing delay bound and queuing delay bound along the deterministic path. Per-hop non queuing delay bound is the sum of the bounds over delays including Output delay, Link delay, Frame preemption delay and Processing delay and per-hop queuing delay bound is the sum of Regulation delay and Queuing delay like following: *end_to_end_delay_bound = non_queuing_delay_bound + queuing_delay_bound. As per [RFC9320], the end-to-end delay variation can be encoded as the sum of non queuing delay variation and queuing delay variation along the deterministic path like following: *end_to_end_delay_variation = non_queuing_delay_variation + queuing_delay_variation. Moreover, as discussed in [I-D.ietf-detnet-dataplane-taxonomy], the end-to-end bounded latency calculation includes the bounded delay and variation. The calculation of end-to-end bounded delay and variation will differ in each queuing solution. For example, the end-to-end delay variation is 2 times of the cycle ID when selecting cyclic- based queuing mechanism. 4.2. Metric types The PCE needs to collect the value of the delays as per [RFC9320] and related parameters by IGP, calculate the bounded latency, select a deterministic path with a specific queuing mechanism which meet the requirements and configure the related parameters to a PCC. The PCC MAY use the end-to-end bounded latency metrics in a Path Computation Request (PCReq) message to request a deterministic path meeting the end-to-end bounded latency requirements. A PCE MAY use the metrics in a Path Computation Reply (PCRep) message along with a NO-PATH object in the case where the PCE cannot compute a path meeting this constraints. A PCE can also use the metrics to send the computed end-to-end bounded latency to the PCC. 4.3. ERO and RRO Subobjects A PCC can request the computation of deterministic path and a PCE may respond with PCRep message. And the deterministic path can also be initiated by PCE with PCInitiate or PCUpd message in stateful PCE mode. When the D bit in LSP object is set to 1 within the message, it indicates to request the calculation of deterministic path. When the bit is set in Metric object to indicate the end-to-end bounded latnecy metric, the PCE should calculate the end-to-end latency bound to select the optimal deterministic path to meet the requirements. Xiong, et al. Expires 23 April 2026 [Page 12] Internet-Draft PCEP Extension for Bounded Latency October 2025 The DP-ERO subobject can be carried along the path to indicate the deterministic path and related information. The deterministic path being received by PCC encoded in DP-ERO, which carry the deterministic latency information. And the PCC may insert the deterministic latency information as the DetNet-specific metadata into the packet headers to achieve the deterministic forwarding. The set of computed paths can be specified by means of ERO [RFC3209], SR-RRO [RFC8664] and SRv6-ERO [RFC9603] subobjects. When the D bit in LSP object is set to 1, a DP-ERO subobject which carrying the deterministic path information MAY be inserted directly after the existing identifying subobjects such as ERO [RFC3209] , SR-ERO [RFC8664] and SRv6-ERO [RFC9603]. A DP-ERO subobject corresponds to be a preceding subobject which can not be the first subobject. For example, the path result is from node A, node B to node C and the encoding exmple of the deterministic path will be like following: *ERO(A) subobject->DP-ERO(A) subobject->ERO(B) subobject->DP-ERO(B) subobject->ERO(C) subobject->DP-ERO(C)subobject The DP-RRO subobject can be also carried directly after the existing identifying RRO subobjects such as RRO [RFC3209] , SR-RRO [RFC8664] and SRv6-RRO [RFC9603]. 5. Security Considerations Security considerations for DetNet are covered in the DetNet architecture [RFC8655], DetNet security considerations [RFC9055] and DetNet control plane [I-D.ietf-detnet-controller-plane-framework]. This document defines a new D bit and DP-ERO subobject for deterministic path in PCEP, which do not introduce any new security considerations beyond those already listed in [RFC5440],[RFC8231] and [RFC9357]. 6. IANA Considerations 6.1. New Metric Types This document defines two 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 End-to-End Minimum Latency Metric This document TBD2 End-to-End Maximum Latency Metric This document TBD3 End-to-End Latency Variation Metric This document Xiong, et al. Expires 23 April 2026 [Page 13] Internet-Draft PCEP Extension for Bounded Latency October 2025 6.2. New LSP-EXTENDED-FLAG Flag Registry [RFC9357] defines the LSP-EXTENDED-FLAG TLV. IANA is requested to make allocations from the Flag field registry, as follows: Bit Description Reference ------ ------------------------------ ------------- D flag Request for Deterministic Path This document 6.3. New ERO Subobject This document defines a new subobject type for the PCEP explicit route object (ERO). The code points for subobject types of these objects is maintained in the RSVP parameters registry, under the EXPLICIT_ROUTE and RECORD_ROUTE objects. IANA is requested to confirm the following allocations in the RSVP Parameters registry for each of the new subobject types defined in this document. Object Subobject Subobject Type -------------- --------------------- --------------- EXPLICIT_ROUTE DP-ERO (PCEP-specific) TBD4 RECORD_ROUTE DP-RRO (PCEP-specific) TBD4 7. Acknowledgements The authors would like to thank Dhruv Dhody, Andrew Stone, Lou Berger, Janos Farkas for their review, suggestions and comments to this document. 8. References 8.1. Normative References [I-D.ietf-detnet-controller-plane-framework] Malis, A. G., Geng, X., Chen, M., Varga, B., and C. J. Bernardos, "A Framework for Deterministic Networking (DetNet) Controller Plane", Work in Progress, Internet- Draft, draft-ietf-detnet-controller-plane-framework-15, 24 September 2025, . [I-D.ietf-detnet-dataplane-taxonomy] Joung, J., Geng, X., Peng, S., and T. T. Eckert, "Dataplane Enhancement Taxonomy", Work in Progress, Internet-Draft, draft-ietf-detnet-dataplane-taxonomy-04, 7 July 2025, . Xiong, et al. Expires 23 April 2026 [Page 14] Internet-Draft PCEP Extension for Bounded Latency October 2025 [I-D.ietf-detnet-scaling-requirements] Liu, P., Li, Y., Eckert, T. T., Xiong, Q., Ryoo, J., zhushiyin, and X. Geng, "Requirements for Scaling Deterministic Networks", Work in Progress, Internet-Draft, draft-ietf-detnet-scaling-requirements-09, 7 September 2025, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 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, . [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, . Xiong, et al. Expires 23 April 2026 [Page 15] Internet-Draft PCEP Extension for Bounded Latency October 2025 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", RFC 8664, DOI 10.17487/RFC8664, December 2019, . [RFC9320] Finn, N., Le Boudec, J.-Y., Mohammadpour, E., Zhang, J., and B. Varga, "Deterministic Networking (DetNet) Bounded Latency", RFC 9320, DOI 10.17487/RFC9320, November 2022, . [RFC9357] Xiong, Q., "Label Switched Path (LSP) Object Flag Extension for Stateful PCE", RFC 9357, DOI 10.17487/RFC9357, February 2023, . [RFC9603] Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M., and Y. Zhu, "Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing", RFC 9603, DOI 10.17487/RFC9603, July 2024, . 8.2. Informative References [I-D.peng-lsr-deterministic-traffic-engineering] Peng, S., "IGP Extensions for Deterministic Traffic Engineering", Work in Progress, Internet-Draft, draft- peng-lsr-deterministic-traffic-engineering-03, 23 December 2024, . [RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker, "Deterministic Networking (DetNet) Security Considerations", RFC 9055, DOI 10.17487/RFC9055, June 2021, . Authors' Addresses Quan Xiong ZTE Corporation Email: xiong.quan@zte.com.cn Peng Liu China Mobile Email: liupengyjy@chinamobile.com Xiong, et al. Expires 23 April 2026 [Page 16] Internet-Draft PCEP Extension for Bounded Latency October 2025 Rakesh Gandhi Cisco Systems, Inc. Email: rgandhi@cisco.com Xiong, et al. Expires 23 April 2026 [Page 17]