PCE Q. Xiong, Ed. Internet-Draft ZTE Corporation Intended status: Standards Track P. Liu Expires: 10 December 2023 China Mobile R. Gandhi Cisco Systems, Inc. 8 June 2023 PCEP Extension for DetNet Bounded Latency draft-xiong-pce-detnet-bounded-latency-03 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 deterministic latency constraints and distribute deterministic paths for end-to-end path computation in DetNet 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 10 December 2023. Copyright Notice Copyright (c) 2023 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 10 December 2023 [Page 1] Internet-Draft PCEP Extension for DetNet Bounded Latenc June 2023 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 . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. End-to-End Bounded Delay Metric . . . . . . . . . . . 4 3.1.2. End-to-End Bounded Jitter Metric . . . . . . . . . . 4 3.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Deterministic Path ERO Subobject . . . . . . . . . . . . 5 3.3.1. Deadline Information . . . . . . . . . . . . . . . . 7 3.3.2. Cycle Information . . . . . . . . . . . . . . . . . . 7 3.3.3. Timeslot Information . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5.1. New Metric Types . . . . . . . . . . . . . . . . . . . . 9 5.2. New LSP-EXTENDED-FLAG Flag Registry . . . . . . . . . . . 9 5.3. New ERO Subobject . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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. 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 can't meet the DetNet 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). Xiong, et al. Expires 10 December 2023 [Page 2] Internet-Draft PCEP Extension for DetNet Bounded Latenc June 2023 [I-D.ietf-detnet-scaling-requirements]has described the enhanced requirements for DetNet enhanced data plane including the deterministic latency guarantees. [I-D.xiong-detnet-large-scale-enhancements] has proposed the packet treatment which should support new functions such as queuing mechanisms to ensure the deterministic latency. A common data fields can be defined as per [I-D.xiong-detnet-data-fields-edp] and a Deterministic Latency Action (DLA) option has been proposed to carry queuing-based metadata. 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. As per [I-D.ietf-detnet-controller-plane-framework], explicit path should be calculated and established in control plane to guarantee the deterministic transimission. 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 DetNet 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 constriants should be extended for PCEP. Moreover, the information along the deterministic path should be provided to the PCC after the path conputation such as queuing parameters. This document describes the extensions for PCEP to carry deterministic latency constraints and distribute deterministic paths for end-to-end path computation in DetNet services. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Terminology The terminology is defined as [RFC8655] and [RFC5440]. Xiong, et al. Expires 10 December 2023 [Page 3] Internet-Draft PCEP Extension for DetNet Bounded Latenc June 2023 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 two types for the METRIC object. 3.1.1. End-to-End Bounded Delay Metric [RFC8233] has proposed the Path Delay metric type of the METRIC object to represent the sum of the Link Delay metric of all links along a P2P path. This document proposes the End-to-End Bounded Delay metric in PCEP to represent the sum of Output delay, Link delay, Frame preemption delay, Processing delay, Regulation delay and Queuing delay as defined in [RFC9320] along a deterministic path. Or the End-to-End Bounded Delay metric can be encoded as the sum of non queuing delay bound and queuing delay bound along the deterministic path. The extensions for End-to-End Bounded Delay Metric are as following shown: * T=TBD1: End-to-End Bounded Delay Metric. * The value of End-to-End Bounded Delay 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. A PCC MAY use the End-to-End Bounded Latency metric in a Path Computation Request (PCReq) message to request a deterministic path meeting the end-to-end latency requirement. A PCE MAY use the End- to-End Bounded Latency metric 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 constraint. A PCE can also use this metric to send the computed end-to-end bounded latency to the PCC. 3.1.2. End-to-End Bounded Jitter Metric [RFC8233] has proposed the Path Delay Variation metric type of the METRIC object to represent the sum of the Link Delay Variation metric of all links along the path. This document proposes the End-to-End Bounded Jitter metric in PCEP to represent the difference between the end-to-end upper bounded latecny and the end-to-end lower bounded latecny along a deterministic path. The extensions for End-to-End Bounded Jitter Metric are as following shown: Xiong, et al. Expires 10 December 2023 [Page 4] Internet-Draft PCEP Extension for DetNet Bounded Latenc June 2023 * T=TBD2: End-to-End Bounded Jitter Metric. * The value of End-to-End Bounded Jitter 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 jitter of deterministic path. The end-to-end jitter must be less than or equal to the value. A PCC MAY use the End-to-End Bounded Jitter metric in a PCReq message to request a deterministic path meeting the end-to-end delay variation requirement. A PCE MAY use the End-to-End Bounded Jitter metric in a PCRep message along with a NO-PATH object in the case where the PCE cannot compute a path meeting this constraint. A PCE can also use this metric to send the computed end-to-end bounded Jitter to the PCC. 3.2. LSP Object The LSP Object is defined in Section 7.3 of [RFC8231]. This document defiend 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 As defined in [RFC9320], the end-to-end delay bounds can be presented 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, but the value of queuing delay bound depends on the queuing mechanisms deployed along the deterministic path. [I-D.xiong-detnet-data-fields-edp] and a Deterministic Latency Action (DLA) option has been proposed to carry the queuing information. So to meet the requirements of the end-to-end delay, the PCE should select a path with a specific queuing mechanism and configure the related parameters to the PCC. And the PCC may insert the queuing-based information into the pakects headers. Xiong, et al. Expires 10 December 2023 [Page 5] Internet-Draft PCEP Extension for DetNet Bounded Latenc June 2023 The ERO specified in [RFC5440] can be used to carry deterministic path information. In order to carry deterministic latency Action Information such as queuing information, this document defines a new 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. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD3 | Length | DLA Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Deterministic Latency Action Information(variable, optional) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: DP-ERO Subobject Format Type (8bits): Set to TBD3. 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. DLA (Deterministic Latency Action) Type (16bits): indicates the type of queuing algorithm and each type represents the corresponding queuing mechanisms. The type can be defined refer to the queuing mechanisms which have been discussed such as [RFC9320]. More types can be defined due to the new queuing mechanisms. 1: indicates the Time Aware Shaping [IIEEE802.1Qbv]. 2: indicates the Credit-Based Shaper[IEEE802.1Q-2014]. 3: indicates the Asynchronous Traffic Shaping [IEEE802.1Qcr]. 4: indicates the Cyclic Queuing and Forwarding [IEEE802.1Qch]. 5: indicates the Deadline Based Forwarding [I-D.peng-detnet-deadline-based-forwarding]. 6: indicates the Multiple Cyclic Buffers Queuing Mechanism [I-D.dang-queuing-with-multiple-cyclic-buffers]. Xiong, et al. Expires 10 December 2023 [Page 6] Internet-Draft PCEP Extension for DetNet Bounded Latenc June 2023 7: indicates the ADN mechanism defined in [I-D.joung-detnet-asynch-detnet-framework]. 8: indicates the SR TSN local deadline mechanism defined in [I-D.stein-srtsn]. 9: indicates the Packet Timeslot mechanism defined in [I-D.peng-detnet-packet-timeslot-mechanism]. Deterministic Latency Action Infomation (variable): indicuates the corresponding Deterministic Latency Action parameters. The format depends on the value in the DLA Type field and is described in the following sections. 3.3.1. Deadline Information When the DLA Type is deadline-based queuing mechanisms, it should carry Deadline information for the DP-ERO subobject. The deadline- based queuing mechanism has been proposed in [I-D.stein-srtsn] and [I-D.peng-detnet-deadline-based-forwarding]. The deadlines along the path should be computed at PCE and configured to the PCC, and then inserted into the packet headers. When the Queuing Algorithm Type is set to indicate the deadline-based queuing mechanisms, the Deadline informatiom should be used to carry the deadline parameters. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Deadline | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Deadline Infomation Deadline (32bits): indicates the deadline time for a node to forward a DetNet flow. 3.3.2. Cycle Information When the DLA Type is cyclic-based queuing mechanisms, it should carry Cycle information for the DP-ERO subobject. The cyclic-based queuing mechanism has been proposed in [IEEE802.1Qch] and improved in [I-D.dang-queuing-with-multiple-cyclic-buffers]. The clycle along the path should be computed at PCE and configured to the PCC, and then inserted into the packet headers. When the Queuing Algorithm Type is set to indicate the cycle-based queuing mechanisms, the Cycle informatiom should be used to carry the cycle parameters. Xiong, et al. Expires 10 December 2023 [Page 7] Internet-Draft PCEP Extension for DetNet Bounded Latenc June 2023 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 Profile ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cycle ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Cycle TLV Cycle Profile ID (32bits): indicates the profile ID which the cyclic queue applied at a node. Cycle ID (32bits): indicates the Cycle ID for a node to forward a DetNet flow. 3.3.3. Timeslot Information When the DLA Type is timeslot-based queuing mechanisms, it should carry Timeslot information for the DP-ERO subobject. The timeslot- based queuing mechanism has been proposed in [I-D.peng-detnet-packet-timeslot-mechanism]. The timeslot ID along the path should be computed at PCE and configured to the PCC, and then inserted into the packet headers. When the Queuing Algorithm Type is set to indicate the Timeslot-based queuing mechanisms, the Timeslot informatiom should be used to carry the parameters. 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: Timeslot TLV Cycle ID (32bits): indicates the Cycle ID for a node to forward a DetNet flow. Timeslot ID (32bits): indicates the Timeslot ID for a node to forward a DetNet flow. Xiong, et al. Expires 10 December 2023 [Page 8] Internet-Draft PCEP Extension for DetNet Bounded Latenc June 2023 4. Security Considerations TBA 5. IANA Considerations 5.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 Bounded Delay Metric This document TBD2 End-to-End Bounded Jitter Metric This document 5.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 5.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 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) TBD3 6. Acknowledgements The authors would like to thank Dhruv Dhody, Andrew Stone, Lou Berger, Janos Farkas for their review, suggestions and comments to this document. 7. References 7.1. Normative References Xiong, et al. Expires 10 December 2023 [Page 9] Internet-Draft PCEP Extension for DetNet Bounded Latenc June 2023 [I-D.dang-queuing-with-multiple-cyclic-buffers] Liu, B. and J. Dang, "A Queuing Mechanism with Multiple Cyclic Buffers", Work in Progress, Internet-Draft, draft- dang-queuing-with-multiple-cyclic-buffers-00, 22 February 2021, . [I-D.ietf-detnet-controller-plane-framework] Malis, A. G., Geng, X., Chen, M., Qin, F., Varga, B., and C. J. Bernardos, "Deterministic Networking (DetNet) Controller Plane Framework", Work in Progress, Internet- Draft, draft-ietf-detnet-controller-plane-framework-04, 13 March 2023, . [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-02, 24 May 2023, . [I-D.ietf-pce-segment-routing-ipv6] Li, C., Negi, M. S., Sivabalan, S., Koldychev, M., Kaladharan, P., and Y. Zhu, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing leveraging the IPv6 dataplane", Work in Progress, Internet-Draft, draft-ietf-pce-segment-routing-ipv6-16, 6 March 2023, . [I-D.joung-detnet-asynch-detnet-framework] Joung, J., Ryoo, J., Cheung, T., Li, Y., and P. Liu, "Asynchronous Deterministic Networking Framework for Large-Scale Networks", Work in Progress, Internet-Draft, draft-joung-detnet-asynch-detnet-framework-02, 26 March 2023, . [I-D.peng-6man-deadline-option] Peng, S., Tan, B., and P. Liu, "Deadline Option", Work in Progress, Internet-Draft, draft-peng-6man-deadline-option- 01, 11 July 2022, . Xiong, et al. Expires 10 December 2023 [Page 10] Internet-Draft PCEP Extension for DetNet Bounded Latenc June 2023 [I-D.peng-detnet-deadline-based-forwarding] Peng, S., Liu, P., and D. Yang, "Deadline Based Deterministic Forwarding", Work in Progress, Internet- Draft, draft-peng-detnet-deadline-based-forwarding-05, 12 March 2023, . [I-D.peng-detnet-packet-timeslot-mechanism] Peng, S., Liu, P., Basu, K., Liu, A., and D. Yang, "Generic Packet Timeslot Scheduling Mechanism", Work in Progress, Internet-Draft, draft-peng-detnet-packet- timeslot-mechanism-02, 22 May 2023, . [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-00, 22 May 2023, . [I-D.stein-srtsn] Stein, Y. J., "Segment Routed Time Sensitive Networking", Work in Progress, Internet-Draft, draft-stein-srtsn-01, 29 August 2021, . [I-D.xiong-detnet-data-fields-edp] Xiong, Q. and D. Yang, "Data Fields for DetNet Enhanced Data Plane", Work in Progress, Internet-Draft, draft- xiong-detnet-data-fields-edp-00, 10 March 2023, . [I-D.xiong-detnet-large-scale-enhancements] Xiong, Q., Du, Z., Zhao, J., and D. Yang, "Enhanced DetNet Data Plane (EDP) Framework for Scaling Deterministic Networks", Work in Progress, Internet-Draft, draft-xiong- detnet-large-scale-enhancements-02, 13 March 2023, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Xiong, et al. Expires 10 December 2023 [Page 11] Internet-Draft PCEP Extension for DetNet Bounded Latenc June 2023 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, . [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, March 2012, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . [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, . Xiong, et al. Expires 10 December 2023 [Page 12] Internet-Draft PCEP Extension for DetNet Bounded Latenc June 2023 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, . [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, . Authors' Addresses Quan Xiong (editor) ZTE Corporation China Email: xiong.quan@zte.com.cn Peng Liu China Mobile Beijing China Email: liupengyjy@chinamobile.com Rakesh Gandhi Cisco Systems, Inc. Canada Email: rgandhi@cisco.com Xiong, et al. Expires 10 December 2023 [Page 13]