DetNet Enhanced Data Plane

Internet-Draft	DetNet Enhanced Data Plane	July 2022
Yang, et al.	Expires 12 January 2023	[Page]

Abstract

Aiming at providing the bounded latency to DetNet services, DetNet data plane is required to be enhanced. This document provides a method to extend DetNet data plane by introducing the Bounded Latency Information (BLI), which facilitates DetNet transit nodes to guarantee the bounded latency transmission in data plane.¶

1. Introduction

DetNet [RFC8655] provides the capability to carry specified unicast or multicast data flows with extremely low data loss rates and bounded end-to-end latency within a network domain. Three primary goals of DetNet QoS are defined in section 3.1 of [RFC8655]:¶

Minimum and maximum end-to-end latency from source to destination, timely delivery, and bounded jitter (packet delay variation) derived from these constraints.¶
Packet loss ratio under various assumptions as to the operational states of the nodes and links.¶
An upper bound on out-of-order packet delivery. It is worth noting that some DetNet applications are unable to tolerate any out-of-order delivery.¶

To fulfill the goals of DetNet QoS, DetNet architecture [RFC8655] defines a DetNet data plane protocol stack, which includes DetNet forwarding and service sub-layers. Specifically, DetNet data plane framework [RFC8938] specifies two metadata of flow identity and sequence number to be encoded in data plane. Flow-ID is used for identification of the flow or aggregate flow to decide the DetNet traffic treatment and PREOF in both sub-layers. At the same time, sequence number is only used for PREOF in service sub-layer.¶

For IP DetNet data plane, [RFC8939] specifies a method of using 6-tuple to identify DetNet flows. Management and control information defined in DetNet YANG module [I-D.ietf-detnet-yang] is used to select the forwarding outgoing interface and next hop. It is stated that the allocation of system resources and provisioning of related parameters is used for DetNet traffic treatment. However, [RFC8939] doesn't further specify the related parameters used in data plane.¶

In [RFC8964], DetNet Control Word (d-CW), DetNet service label (S-Label), and DetNet MPLS forwarding label(s) (F-Label) are defined for the MPLS-based DetNet data plane encapsulation, where the first two information is mainly used for the DetNet service sub-layer functions, the last information is used for the DetNet forwarding sub-layer functions. DetNet controller plane takes the responsibility to provision both flow identification information and the flow-specific resources needed to provide traffic treatment to meet each flow's service requirements. There is no specification in MPLS DetNet data plane to empower the packet treatment capabilities.¶

There are also other specifications of DetNet data planes such as [RFC9023], [RFC9024], [RFC9025], [RFC9037], and [RFC9056]. These documents specifies the DetNet data planes and interworking technologies of one type of network operating over another sub-network in order to extend the DetNet service range. However, these documents do not introduce new procedure or process, but to follow the specifications defined in [RFC8939] and [RFC8964].¶

To meet the requirements for large-scale deterministic networks and support the bounded latency objective specified in [I-D.liu-detnet-large-scale-requirements], DetNet data plane is required to be enhanced in the following aspects:¶

Explicit inclusion of the metadata used for traffic treatment, especially for bounded latency and jitter, when considering the support of DetNet flows scalability in large scale DetNet networks¶
Compatibility to different options of queuing, shaping, policing or any other underlying network technologies, in order to provide bounded latency¶
Minimize the end-to-end delay difference of multiple forwarding paths that are used for packet replication and elimination¶
DetNet data plane processing of DetNet flow coexists with the non-DetNet flows¶

This documents provides a method to extend DetNet data plane by introducing Bounded Latency Information (BLI), which facilitates DetNet transit nodes to guarantee the bounded latency transmission in data plane. The resources include the QoS mechanisms, scheduling mechanisms, or any other mechanisms from underlying network layer so as to support bounded latency. This document also proposes a format of bounded latency information and its encapsulations on DetNet data planes.¶

3. Design of DetNet Enhanced Data Plane

In order to support the enhanced traffic treatment functions, such as bounded latency, DetNet data plane is enhanced by carrying a new defined metadata information in DetNet service packets: Bounded Latency Information (BLI).¶

DetNet uses either one or combination of QoS related and resource allocation technologies to ensure the end-to-end bounded latency. [I-D.ietf-detnet-bounded-latency] introduces a set of scheduling mechanisms can be used to assure the bounded latency. [I-D.stein-srtsn] uses a single stack data structure to provide a unified approach to forwarding and deadline based scheduling. Noted that in most scheduling process, an ancillary information is required to be transmitted between DetNet nodes to facilitate local scheduling. In this document, this ancillary information is named bounded latency information. Bounded latency information is transmitted across multiple DetNet transit nodes and used by the DetNet forwarding sub-layer.¶

To cope with a variety of scheduling mechanisms and transfer different information in a uniform format in data plane, the bounded latency information is abstracted and classified into two categories: requirement and resource.¶

3.1. Category 1: Requirement

Bounded latency information in the requirement category may include the information like the end-to-end delay budget, local delay budget, local deadline, delay variation budget, local delay variation budget etc. For example, end-to-end delay budget describes the upper bounded latency value of DetNet flow in network. Then DetNet node may use this information to determine the packet priority or which queue can be used to transmit this packet. Local delay budget is a variation of end-to-end delay budget when multiple DetNet nodes may have same or different delay budget time of each in DetNet network. Deadline is straightforward to indicate how much time is left for this packet to meet the upper bounded latency requirement. Similar practice in 6LoWPANs is given by [RFC9034]. The usage of this information is similar to the delay budget information when DetNet node decides the priority or queue for the packet forwarding. Delay variation [I-D.mohammadpour-detnet-bounded-delay-variation] is another deterministic goal required by DetNet and should be considered in scheduling process when it is required. Priority can also be a type of requirement. DetNet application may assign its priority by different meanings and formats, which may not be equivalently fulfilled by existing QoS priority.¶

3.2. Category 2: Resource

Bounded latency information in the resource category includes the information like cycle ID, queue ID, and time slot ID etc. Since cycles, queues, or time slots are the real resources can be allocated for DetNet flow, they are named as the time resource ID. For example, time resource ID can represent a cycle ID when cyclic queuing mechanism is used on DetNet node. Time resource ID can also represent a queue ID when queue based scheduling mechanism is locally used on DetNet node. Time resource ID can represent a time slot ID too, when a time slot based mechanism like [RFC9030] is used.¶

4. Data Field of Bounded Latency Information

This section introduces the data field of bounded latency information in DetNet data plane. The format of the data field is shown as follows.¶

+---------------+-------------+-------------+-------------+
|   BLI Type    |   Format    |     Flag    |   Reserved  |
+---------------+-------------+---------------------------+
|                                                         ~
~         Bounded Latency Information (variable size)     ~
~                                                         |
+---------------------------------------------------------+

Figure 1: Data Field of Bounded Latency Information¶

where:¶

Bounded Latency Information Type: 8-bit identifier to represent the type of bounded latency information. A new registry is expected to be created and the value is assigned by IANA. Table 1 lists the value of BLI Type and the corresponding Bounded Latency Information defined so far,¶

+----------------+---------------------------------------+
| BLI Type Value |      Bounded Latency Information      |
+----------------+---------------------------------------+
|        0       |               Reserved                |
+----------------+---------------------------------------+
|        1       |           Time resource ID            |
+----------------+---------------------------------------+
|        2       |               Priority                |
+----------------+---------------------------------------+
|        3       |        End-to-end delay budget        |
+----------------+---------------------------------------+
|        4       |           Local delay budget          |
+----------------+---------------------------------------+
|        5       |           End-to-end deadline         |
+----------------+---------------------------------------+
|        6       |           Local deadline              |
+----------------+---------------------------------------+
|        7       |   End-to-end delay variation budget   |
+----------------+---------------------------------------+
|        8       |      Local delay variation budget     |
+----------------+---------------------------------------+

Table 1: Bounded Latency Information Type and Value¶

Format: 8-bit value to indicate the format of bounded latency information. For example, the format could be 16-bit unsigned integer, 32-bit unsigned integer, PTP or NTP timestamp, and other pre-configured formats. Table 2 lists the value of Format and the corresponding Format defined so far,¶

   +--------------+-------------------------+
   | Format Value |          Format         |
   +--------------+-------------------------+
   |      1       | 32-bit unsigned Integer |
   +--------------+-------------------------+
   |      2       | 16-bit unsigned Integer |
   +--------------+-------------------------+
   |      3       |  8-bit unsigned Integer |
   +--------------+-------------------------+
   |      4       |   PTP 80-bit Timestamp  |
   +--------------+-------------------------+
   |      5       |   PTP 64-bit Timestamp  |
   +--------------+-------------------------+
   |      6       |   NTP 64-bit Timestamp  |
   +--------------+-------------------------+
   |      7       |   NTP 32-bit Timestamp  |
   +--------------+-------------------------+

Table 2: Format¶

Bounded Latency Information Type and Format are used together to specify the type, length and format of the bounded latency information.¶

: Reserved: Reserved for future usage.¶
: Time resource ID: the identifier to indicate the underlying resources used for bounded latency. The format is 32-bit unsigned integer with Format Value 1.¶
: Priority: QoS priority of the DetNet service packet. As six bits of the Differentiated Services Field [RFC2474] are used as a codepoint (DSCP), the format of priority is 8-bit unsigned integer with Format Value 3.¶
: End-to-end delay budget: the end-to-end delay requirement of DetNet service packet. The format is 32-bit unsigned Integer with Format Value 1.¶
: Local delay budget: the per hop delay requirement of DetNet service packet on this network node. The format is 32-bit unsigned Integer with Format Value 1.¶
: End-to-end deadline: the time when the packet must arrive at the final destination or exit the DetNet network. This time is usually the birth time plus the end-to-end delay budget. The format is the timestamp with proper length.¶
: Local deadline: the time when the packet must exit this network node. The format is the timestamp with proper length.¶
: End-to-end delay variation budget: the end-to-end delay variation requirement of DetNet service packet. The format is 8-bit or 16-bit unsigned Integer with Format Value 3 or Format Value 2.¶
: Local delay variation budget: the per hop delay variation requirement of DetNet service packet on this network node. The format is 8-bit or 16-bit unsigned Integer with Format Value 3 or Format Value 2.¶

Flags: 8 bits of flags. A new registry "Bounded Latency Flags" is expected to be created. At the writing time, all flags are unused and undefined.¶

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|U U U U U U U U|
+-+-+-+-+-+-+-+-+

Figure 2: Flag¶

Reserved: Keeps zero when it is not specified.¶
Bounded Latency Information: indicates the bounded latency information used for local scheduling processing. Table 1 shows the bounded latency information type and the corresponding values. The bounded latency information is different depending on the type of bounded latency information.¶

5. Encapsulation of Bounded Latency Information

BLI data field can be encapsulated in different DetNet data planes.¶

5.1. DetNet Data Plane of IP

For IPv6 based DetNet data plane, the data field of bounded latency information is recommended to be carried in IPv6 Extension Header Options, called Bounded Latency Information Option, 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 2
                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                | Option Type   | Opt Data Len  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   BLI Type    |     Format    |    Flag       |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               ~
~         Bounded Latency Information (variable size)           ~
~                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Bounded Latency Information Option¶

Option Type: 8-bit identifier of the type of option. Value TBD by IANA; the highest-order 3 bits of this field is 001 to skip over this option and continue processing the header if the processing IPv6 node does not recognize the Option Type and to permit the Option Data may change en route to the destination of packet.¶
Opt Data Len: 8-bit unsigned integer. Length of the Option Data field of this option, in octets.¶
For Bounded Latency Information data field, see section 4 for details.¶

Bounded latency information data field is encapsulated in either IPv6 Hop-by-Hop Options header or IPv6 Destination Options header depending on the processing happens at each hop or at the last hop. More than one bounded latency information can appear in one Bounded Latency Information Option. The Option Data Length and the Format are used to locate every bounded latency information. The encapsulation of Bounded Latency Information Option is shown in Figure 4 and Figure 5.¶

+--------------------------------------+
|          DetNet App-Flow             |
|        (Original IP) Packet          |
+--------------------------------------+
|        UDP/GRE/IPSec... Header       |
+--------------------------------------+
|            Other IPv6 EHs            |
+--------------------------------------+
|     IPv6 Hop-by-Hop Options Header   |
| (Bounded Latency Information Option) |
+--------------------------------------+
|             IPv6 Header              |
+--------------------------------------+
|              Data-Link               |
+--------------------------------------+
|              Physical                |
+--------------------------------------+

Figure 4: Encapsulation of BLI Option in IPv6 Hop-by-Hop Options Headers¶

+--------------------------------------+
|          DetNet App-Flow             |
|        (Original IP) Packet          |
+--------------------------------------+
|        UDP/GRE/IPSec... Header       |
+--------------------------------------+
|     IPv6 Destination Options Header  |
| (Bounded Latency Information Option) |
+--------------------------------------+
|            Other IPv6 EHs            |
+--------------------------------------+
|             IPv6 Header              |
+--------------------------------------+
|              Data-Link               |
+--------------------------------------+
|              Physical                |
+--------------------------------------+

Figure 5: Encapsulation of BLI Option in IPv6 Destination Options Headers¶

5.2. DetNet Data Plane of MPLS

An MPLS extension header is proposed in [I-D.song-mpls-extension-header]. An MPLS Extension Header (EH) encapsulated with the format of bounded latency information is called Bounded Latency Information Extension Header (BLIEH) and shown in Figure 6.¶

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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NH        |     HLEN      |      EXT      |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   BLI Type    |     Format    |     Flag      |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               ~
~         Bounded Latency Information (variable size)           ~
~                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: Bounded Latency Information Extension Header¶

NH: 8-bit indicator for the Next Header. This field identifies the type of the EH immediately following this EH.¶
HLEN: 8-bit unsigned integer for the Extension Header Length in 4-octet units, not including the first 4 octets.¶
EXT: 8-bit optional type extension.¶

The encapsulation of bounded latency information in MPLS extension headers with MPLS label stack is shown in the following figure. More than one BLI can be carried in one Bounded Latency Information Extension Header (BLIEH).¶

0                                  31
+--------+--------+--------+--------+  \
|                                   |  |
~     MPLS Label Stack              ~  |
|                                   |  |
+--------+--------+--------+--------+  |
|     EH Indicator (TBD)            |   > MPLS Label Stack
+--------+--------+--------+--------+  |  (extended with EHI)
|                                   |  |
~     MPLS Label Stack              ~  |
|                                   |  |
+--------+--------+--------+--------+ <
| Header of Extension Headers (HEH) |  |
+--------+--------+--------+--------+  |
|                                   | > MPLS EH Fields
~ Extension Header (EH)  with BLI  ~   |  (new)
|                                   |  |
+--------+--------+--------+--------+ <
|                                   |  |
~    Upper Layer Headers/Payload    ~   > MPLS Payload
|                                   |  |  (as is)
+--------+--------+--------+--------+  /

Figure 7: MPLS Encapsulation of Bounded Latency Information Extension Header¶

5.3. DetNet Data Plane of MPLS over UDP/IP

This document describes a DetNet IP encapsulation that includes the bounded latency information based on the DetNet MPLS over UDP/IP data plane [RFC9025], i.e., leveraging the MPLS-over-UDP technology. The bounded latency guarantee capable DetNet IP encapsulation builds on encapsulating DetNet PW over an IP/UDP tunnel [RFC7510]. It is noted that the format of MPLS Bounded Latency Extension Header (BLIEH) after UDP header is the same with the format of MPLS Bounded Latency Extension Header (BLIEH) defined in section 5.2, as well as without using any MPLS forwarding labels. The encapsulation of bounded latency information in DetNet Data Plane of MPLS over UDP/IP is shown in the following figure.¶

0                                 31
+----------------------------------+
|                                  |
|         DetNet App-Flow          |
|       (original IP) Packet       |
|                                  |
+----------------------------------+<--\
|                                  |    |
~ MPLS Bounded Latency Information ~    |
~     Extension Header (BLIEH)     ~    |
|                                  |    |
+----------------------------------+    +--> Bounded latency support
|      UDP/GRE/IPSec... Header     |    |    DetNet IP data
+----------------------------------+    |    plane encapsulation
|            IP Header             |    |
+----------------------------------+<--/
|            Data-Link             |
+----------------------------------+
|             Physical             |
+----------------------------------+

Figure 8: IPv6 extension option of bounded latency¶

6. IANA Considerations

6.1. New Destination Options and Hop-by-Hop Options

IANA is requested to allocate a value of "Destination Options and Hop-by-Hop Options" under "Internet Protocol Version 6 (IPv6) Parameters" registry. The suggested value is:¶

+------+-----+-----+-------+---------------------+-----------+
| Hex  | act | chg | rest  |     Description     | Reference |
+------+-----+-----+-------+---------------------+-----------+
|  TBD | 00  |  1  |  TBD  |       BLI Option    | This I-D  |
+------+-----+-----+-------+---------------------+-----------+

Bounded Latency Information Option¶

6.2. New Type of MPLS Extension Header

IANA is requested to allocate a 8-bit indicator for the Next Header to the Bounded Latency Extension Header.¶

6.3. New Subregistry of Bounded Latency Information Type

IANA is requested to define a new subregistry of "Bounded Latency Information Type" for the "Bounded Latency Information Option" under "Internet Protocol Version 6 (IPv6) Parameters" registry.¶

This new subregistry will include the following registries:¶

+-----------------+---------------------------------+-----------+
| Suggested Value |            Meaning              | Reference |
+-----------------+---------------------------------+-----------+
|       TBD       |            Reserved             | This I-D  |
+-----------------+---------------------------------+-----------+
|       TBD       |        Time resource ID         | This I-D  |
+-----------------+---------------------------------+-----------+
|       TBD       |            Priority             | This I-D  |
+-----------------+---------------------------------+-----------+
|       TBD       |    End-to-end delay budget      | This I-D  |
+-----------------+---------------------------------+-----------+
|       TBD       |        Local delay budget       | This I-D  |
+-----------------+---------------------------------+-----------+
|       TBD       |        End-to-end deadline      | This I-D  |
+-----------------+---------------------------------+-----------+
|       TBD       |        Local deadline           | This I-D  |
+-----------------+---------------------------------+-----------+
|       TBD       |End-to-end delay variation budget| This I-D  |
+-----------------+---------------------------------+-----------+
|       TBD       |   Local delay variation budget  | This I-D  |
+-----------------+---------------------------------+-----------+

Bounded Latency Information Type¶

8. Normative References

[I-D.ietf-detnet-bounded-latency]: Finn, N., Boudec, J. L., Mohammadpour, E., Zhang, J., and B. Varga, "DetNet Bounded Latency", Work in Progress, Internet-Draft, draft-ietf-detnet-bounded-latency-10, 8 April 2022, <https://www.ietf.org/archive/id/draft-ietf-detnet-bounded-latency-10.txt>.
[I-D.ietf-detnet-yang]: Geng, X., Ryoo, Y., Fedyk, D., Rahman, R., and Z. Li, "Deterministic Networking (DetNet) YANG Model", Work in Progress, Internet-Draft, draft-ietf-detnet-yang-16, 5 February 2022, <https://www.ietf.org/archive/id/draft-ietf-detnet-yang-16.txt>.
[I-D.liu-detnet-large-scale-requirements]: Liu, P., Li, Y., Eckert, T., Xiong, Q., and J. Ryoo, "Requirements for Large-Scale Deterministic Networks", Work in Progress, Internet-Draft, draft-liu-detnet-large-scale-requirements-02, 10 April 2022, <https://www.ietf.org/archive/id/draft-liu-detnet-large-scale-requirements-02.txt>.
[I-D.mohammadpour-detnet-bounded-delay-variation]: Mohammadpour, E. and J. L. Boudec, "DetNet Bounded Packet-Delay-Variation", Work in Progress, Internet-Draft, draft-mohammadpour-detnet-bounded-delay-variation-00, 10 September 2021, <https://www.ietf.org/archive/id/draft-mohammadpour-detnet-bounded-delay-variation-00.txt>.
[I-D.song-mpls-extension-header]: Song, H., Li, Z., Zhou, T., Andersson, L., Zhang, Z., Gandhi, R., Rajamanickam, J., and J. Bhattacharya, "MPLS Post-Stack Extension Header", Work in Progress, Internet-Draft, draft-song-mpls-extension-header-07, 8 July 2022, <https://www.ietf.org/archive/id/draft-song-mpls-extension-header-07.txt>.
[I-D.stein-srtsn]: Stein, Y. (., "Segment Routed Time Sensitive Networking", Work in Progress, Internet-Draft, draft-stein-srtsn-01, 29 August 2021, <https://www.ietf.org/archive/id/draft-stein-srtsn-01.txt>.
[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>.
[RFC2474]: Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[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>.
[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>.
[RFC8938]: Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. Bryant, "Deterministic Networking (DetNet) Data Plane Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, <https://www.rfc-editor.org/info/rfc8938>.
[RFC8939]: Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. Bryant, "Deterministic Networking (DetNet) Data Plane: IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, <https://www.rfc-editor.org/info/rfc8939>.
[RFC8964]: Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, S., and J. Korhonen, "Deterministic Networking (DetNet) Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January 2021, <https://www.rfc-editor.org/info/rfc8964>.
[RFC9023]: Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, "Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN)", RFC 9023, DOI 10.17487/RFC9023, June 2021, <https://www.rfc-editor.org/info/rfc9023>.
[RFC9024]: Varga, B., Ed., Farkas, J., Malis, A., Bryant, S., and D. Fedyk, "Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive Networking over MPLS", RFC 9024, DOI 10.17487/RFC9024, June 2021, <https://www.rfc-editor.org/info/rfc9024>.
[RFC9025]: Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. Bryant, "Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IP", RFC 9025, DOI 10.17487/RFC9025, April 2021, <https://www.rfc-editor.org/info/rfc9025>.
[RFC9030]: Thubert, P., Ed., "An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", RFC 9030, DOI 10.17487/RFC9030, May 2021, <https://www.rfc-editor.org/info/rfc9030>.
[RFC9034]: Thomas, L., Anamalamudi, S., Anand, S.V.R., Hegde, M., and C. Perkins, "Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 9034, DOI 10.17487/RFC9034, June 2021, <https://www.rfc-editor.org/info/rfc9034>.
[RFC9037]: Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, "Deterministic Networking (DetNet) Data Plane: MPLS over IEEE 802.1 Time-Sensitive Networking (TSN)", RFC 9037, DOI 10.17487/RFC9037, June 2021, <https://www.rfc-editor.org/info/rfc9037>.
[RFC9056]: Varga, B., Ed., Berger, L., Fedyk, D., Bryant, S., and J. Korhonen, "Deterministic Networking (DetNet) Data Plane: IP over MPLS", RFC 9056, DOI 10.17487/RFC9056, October 2021, <https://www.rfc-editor.org/info/rfc9056>.

DetNet Enhanced Data Plane

Abstract

Requirements Language

Status of This Memo

Copyright Notice

Table of Contents