Internet-Draft PCEP Extension for Bounded Latency October 2024
Xiong, et al. Expires 24 April 2025 [Page]
Workgroup:
PCE
Internet-Draft:
draft-xiong-pce-detnet-bounded-latency-05
Published:
Intended Status:
Standards Track
Expires:
Authors:
Q. Xiong, Ed.
ZTE Corporation
P. Liu
China Mobile
R. Gandhi
Cisco Systems, Inc.

PCEP Extension for Bounded Latency

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 24 April 2025.

▲

Table of Contents

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). [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. [I-D.ietf-detnet-dataplane-taxonomy] has described the classification criteria of the solutions. And queuing mechanisms and solutions require different information to help the functions of ensuring deterministic latency, including regulation, queue management. As per [I-D.xiong-detnet-data-fields-edp], the deterministic latency information should be defined as the DetNet-specific metadata for enhanced DetNet data plane.

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.

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", "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].

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 latency and the end-to-end lower bounded latency along a deterministic path. The extensions for End-to-End Bounded Jitter Metric are as following shown:

  • 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 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 specified in [RFC5440] can be used to carry deterministic path information. In order to carry deterministic latency 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |L|  Type=TBD3  |     Length    |     Class     |    DLI  Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //  Deterministic Latency Information(variable, optional)       //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: DP-ERO Subobject Format

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

Class (8bits): indicates the deterministic forwarding class.

DLI Type (8bits): indicates the type of deterministic latency information.

Deterministic Latency Information (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. Deadline Information

When the DLI Type is deadline-based queuing mechanisms, it should carry deadline information for the DP-ERO subobject. For example, the deadline-based queuing mechanism has been proposed in [I-D.stein-srtsn] and [I-D.peng-detnet-deadline-based-forwarding]. The format of the deadline information is shown as 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Deadline                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Deadline Information

Deadline (32bits): indicates the deadline for a node to forward a flow.

3.3.2. Cycle Information

When the DLI Type is cyclic-based queuing mechanisms, it should carry cycle information for the DP-ERO subobject. For example, the cyclic-based queuing mechanism has been proposed in [IEEE 802.1Qdv], [I-D.dang-queuing-with-multiple-cyclic-buffers], [I-D.eckert-detnet-tcqf] and [I-D.chen-detnet-sr-based-bounded-latency]. The format of the cycle information is shown as 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Cycle Profile ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Cycle ID                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Cycle Information

Cycle Profile ID (32bits): indicates the profile number which the cyclic queue applied at a node.

Cycle ID (32bits): indicates the clycle number for a node to forward a flow.

3.3.3. Timeslot Information

When the DLI Type is timeslot-based queuing mechanisms, it should carry timeslot information for the DP-ERO subobject. For example, the timeslot-based queuing mechanism has been proposed in [I-D.peng-detnet-packet-timeslot-mechanism]. The format of the timeslot information is shown as 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Timeslot ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Timeslot Information

Timeslot ID (32bits): indicates the timeslot number for a node to forward a flow.

3.3.4. Ratio Information

When the DLI Type is rate-based queuing mechanisms, it should carry ratio information for the DP-ERO subobject. For example, the rate-based queuing mechanism has been proposed in [I-D.joung-detnet-stateless-fair-queuing], [IEEE802.1Qcr] and [I-D.eckert-detnet-glbf]. The format of the ratio information is shown as following figure.


    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Maximum packet size                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Service rate                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Ratio Information

Maximum packet size (32bits): indicates the maximum packet size which the node should forward.

Service rate (32bits): indicates the service rate which the node should forward.

3.3.5. Damper Information

When the DLI Type is damper-based queuing mechanisms, it should carry damper information in the DP-ERO subobject. For example, the damper-based queuing mechanism has been proposed in [I-D.mohammadpour-detnet-bounded-delay-variation] and [I-D.eckert-detnet-glbf]. The format of the damper information is shown as following figure.


    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Budget delay                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Damper Information

Budget delay (32bits): indicates the budget delay which the PCE calculated for this deterministic path.

4. Operations

The PCE needs to collect the value of the delays 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 the PCC. And as discussed in [I-D.ietf-detnet-dataplane-taxonomy], the end-to-end bounded latency calculation includes the bounded delay and jitter. The calculation of end-to-end bounded delay and jitter will differ in each queuing solution. For example, the end-to-end jitter is 2 times of the cycle ID when selecting cyclic-based queuing mechanism.

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 Delay Metric, the PCE should calculate the end-to-end delay to select the optimal deterministic path to meet the requirements. And when the bit is set in Metric object to indicate the End-to-End Bounded Jitter Metric, the PCE should calculate the end-to-end jitter. The 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.

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 Bounded Delay Metric    This document
     TBD2      End-to-End Bounded Jitter Metric   This document

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

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, "Deterministic Networking (DetNet) Controller Plane Framework", Work in Progress, Internet-Draft, draft-ietf-detnet-controller-plane-framework-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-controller-plane-framework-07>.
[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-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-dataplane-taxonomy-02>.
[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-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-scaling-requirements-06>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC4655]
Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, , <https://www.rfc-editor.org/info/rfc4655>.
[RFC5440]
Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, , <https://www.rfc-editor.org/info/rfc5440>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[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, , <https://www.rfc-editor.org/info/rfc8231>.
[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, , <https://www.rfc-editor.org/info/rfc8233>.
[RFC9357]
Xiong, Q., "Label Switched Path (LSP) Object Flag Extension for Stateful PCE", RFC 9357, DOI 10.17487/RFC9357, , <https://www.rfc-editor.org/info/rfc9357>.

8.2. Infomative References

[I-D.chen-detnet-sr-based-bounded-latency]
Chen, M., Geng, X., Li, Z., Joung, J., and J. Ryoo, "Segment Routing (SR) Based Bounded Latency", Work in Progress, Internet-Draft, draft-chen-detnet-sr-based-bounded-latency-03, , <https://datatracker.ietf.org/doc/html/draft-chen-detnet-sr-based-bounded-latency-03>.
[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, , <https://datatracker.ietf.org/doc/html/draft-dang-queuing-with-multiple-cyclic-buffers-00>.
[I-D.eckert-detnet-glbf]
Eckert, T. T., Clemm, A., Bryant, S., and S. Hommes, "Deterministic Networking (DetNet) Data Plane - guaranteed Latency Based Forwarding (gLBF) for bounded latency with low jitter and asynchronous forwarding in Deterministic Networks", Work in Progress, Internet-Draft, draft-eckert-detnet-glbf-03, , <https://datatracker.ietf.org/doc/html/draft-eckert-detnet-glbf-03>.
[I-D.eckert-detnet-tcqf]
Eckert, T. T., Li, Y., Bryant, S., Malis, A. G., Ryoo, J., Liu, P., Li, G., Ren, S., and F. Yang, "Deterministic Networking (DetNet) Data Plane - Tagged Cyclic Queuing and Forwarding (TCQF) for bounded latency with low jitter in large scale DetNets", Work in Progress, Internet-Draft, draft-eckert-detnet-tcqf-06, , <https://datatracker.ietf.org/doc/html/draft-eckert-detnet-tcqf-06>.
[I-D.joung-detnet-stateless-fair-queuing]
Joung, J., Ryoo, J., Cheung, T., Li, Y., and P. Liu, "Latency Guarantee with Stateless Fair Queuing", Work in Progress, Internet-Draft, draft-joung-detnet-stateless-fair-queuing-03, , <https://datatracker.ietf.org/doc/html/draft-joung-detnet-stateless-fair-queuing-03>.
[I-D.mohammadpour-detnet-bounded-delay-variation]
Mohammadpour, E. and J. Le Boudec, "DetNet Bounded Packet-Delay-Variation", Work in Progress, Internet-Draft, draft-mohammadpour-detnet-bounded-delay-variation-00, , <https://datatracker.ietf.org/doc/html/draft-mohammadpour-detnet-bounded-delay-variation-00>.
[I-D.peng-detnet-deadline-based-forwarding]
Peng, S., Du, Z., Basu, K., cheng, Yang, D., and C. Liu, "Deadline Based Deterministic Forwarding", Work in Progress, Internet-Draft, draft-peng-detnet-deadline-based-forwarding-12, , <https://datatracker.ietf.org/doc/html/draft-peng-detnet-deadline-based-forwarding-12>.
[I-D.peng-detnet-packet-timeslot-mechanism]
Peng, S., Liu, P., Basu, K., Liu, A., Yang, D., and G. Peng, "Timeslot Queueing and Forwarding Mechanism", Work in Progress, Internet-Draft, draft-peng-detnet-packet-timeslot-mechanism-09, , <https://datatracker.ietf.org/doc/html/draft-peng-detnet-packet-timeslot-mechanism-09>.
[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-02, , <https://datatracker.ietf.org/doc/html/draft-peng-lsr-deterministic-traffic-engineering-02>.
[I-D.stein-srtsn]
Stein, Y. J., "Segment Routed Time Sensitive Networking", Work in Progress, Internet-Draft, draft-stein-srtsn-01, , <https://datatracker.ietf.org/doc/html/draft-stein-srtsn-01>.
[I-D.xiong-detnet-data-fields-edp]
Xiong, Q., Liu, A., Gandhi, R., and D. Yang, "Data Fields for DetNet Enhanced Data Plane", Work in Progress, Internet-Draft, draft-xiong-detnet-data-fields-edp-02, , <https://datatracker.ietf.org/doc/html/draft-xiong-detnet-data-fields-edp-02>.
[RFC8655]
Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, , <https://www.rfc-editor.org/info/rfc8655>.
[RFC9055]
Grossman, E., Ed., Mizrahi, T., and A. Hacker, "Deterministic Networking (DetNet) Security Considerations", RFC 9055, DOI 10.17487/RFC9055, , <https://www.rfc-editor.org/info/rfc9055>.
[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, , <https://www.rfc-editor.org/info/rfc9320>.

Authors' Addresses

Quan Xiong (editor)
ZTE Corporation
China
Peng Liu
China Mobile
Beijing
China
Rakesh Gandhi
Cisco Systems, Inc.
Canada