DetNet Enhanced Data Plane

DetNet 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 : 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 defines a DetNet data plane protocol stack, which includes DetNet forwarding and service sub-layers. Specifically, DetNet data plane framework 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, specifies a method of using 6-tuple to identify DetNet flows. Management and control information defined in DetNet YANG module 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, doesn't further specify the related parameters used in data plane. In , 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 , , , , and . 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 and . To meet the requirements for large-scale deterministic networks and support the bounded latency objective specified in , 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.

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 when, and only when, they appear in all capitals, as shown here.

The abbreviations used in this document are: BLI: Bounded Latency Information PREOF: Packet Replication, Elimination, and Ordering Functions

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. introduces a set of scheduling mechanisms can be used to assure the bounded latency. 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.

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

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

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

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,

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,

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

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.

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

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.

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.

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

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

An MPLS extension header is proposed in . 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.

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

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

This document describes a DetNet IP encapsulation that includes the bounded latency information based on the DetNet MPLS over UDP/IP data plane , 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.

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:

Bounded Latency Information Option

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

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:

Bounded Latency Information Type

TBD