Data Unit Groups for DetNet-Enabled Networks

Definition, and abbreviations

Abbreviation AR Augmented Reality ADU Application Data Unit DUG Data Unit Group IP Internet Protocol IPv6 Internet Protocol Version 6 MPLS Multi-Protocol Label Switching MTU Maximum Transmission Unit QoE Quality of Experience TLS Transport Layer Security TLV Type Length Values UDP User Datagram Protocol VR Virtual Reality XR eXtended Reality

Introduction Applications often send data which does not fit as payload into a single IP packet. As a result, a single Application Data Unit (ADU) is fragmented into smaller chunks with a maximum length of each chuck determined by the underlying computer network and its Maximum Transmission Unit (MTU). The set of packets that carry the entirety of a single ADU are hereby defined as a Data Unit Group (DUG). For high-throughput, low-latency applications such as Augmented Reality (AR) or Virtual Reality (VR) media applications, collectively called eXtended Reality (XR) applications, this can lead to situations where a single packet loss can lead to the loss of the whole ADU for the application. The same applies for closed-loop automation digital twinning applications that require a wide range of monitoring data of the real world to create the digital twin for on-demand decision making. Since some ADUs are more important than others for the Quality of Experience (QoE) for the application user or the accurate performance of a digital twin, it can be useful for the network to be aware of the difference of importance between the ADUs, to be able to down-prioritise (or even drop) the least important packets in case of congestion. Techniques have been developed in 5G (in 3GPP Release 18, ), to convey "XR metadata", including importance within the flow, associated with a "PDU Set" (i.e., set of packets transporting an ADU) to the network. The sending application determines the metadata and associates it with ADUs (e.g., within individual packets). The network uses the importance of packets to determine which packets to drop in case of congestion. Within this document, the group of packets that transport a single ADU is designated as a "Data Unit Group" (DUG). The purpose of this document is to define a mechanism for conveying importance (within the flow) and related metadata of DUGs to DetNet routers, to make it available for enhanced queuing, shaping, scheduling, and pre-emption decisions. This document aims primarily at extending the DetNet IP Data Plane in an initial revision of this draft, and may be extended to Multi-Protocol Label Switching (MPLS) and MPLS over User Datagram Protocol (UDP)/IP data plane options in future revisions.

Internet Protocol Version 6 Extension This document proposes the introduction of DUG as an extension to the IPv6 header. In order to comply with this requirement and to follow the guidelines on how to design IPv6 header extensions , , i.e., using Type Length Values (TLVs), a new IPv6 TLV is defined. As the order of extension headers are fixed in IPv6, the DUG-related information is added to an appropriate IPv6 header option. The main purpose of the proposed DUG TLVs is for intermediate node to read the values and perform any DetNet queuing, shaping, scheduling, ordering or even dropping over them. Thus, the "Hop-by-Hop" options header is identified as the most appropriate one, as intermediate nodes shall process the DUG-related information. The IPv6 header option is illustrated in and is a sequence in form of an unsigned integer number indicating the order of packets within a Data Unit Group. With each new packet, the sequence number is iterated by 1.

DUG metadata IPv6 option The set of values describe the DUG as follows:

DUG ID: an unsigned integer number identifying the DUG. The DUG ID of each new DUG is increased by 1 by the sender.
Sequence: an unsigned integer number indicating the order of packets within a DUG, starting from 0 and increased by 1 for each packet in the DUG.
D: This bit indicates the end of the DUG.
I: These four bits indicate the importance of this packet against other packets in the same DUG. Lower values indicate a higher importance and allow to prioritise packets in different DUGs. Importance may be derived from the application type or the sensitivity of applications when not receiving a DUG in their application.
C: A 1-bit field to indicate higher layer control plane packets. When reliable transport protocols are in use, e.g., TCP, or upper-layer control procedures take place, e.g., establishment of a TLS session, there is no ADU exchanged. However, these control packets are equally important to the delivery of an ADU and depending on their functionality in the communication sometime even more important than the ADU itself. This bit allows to tag these packets.
S: This 1-bit field indicates the start of a burst of packets within a DUG.
E: This 1-bit field indicates the end of a burst of packets within a DUG.

Additional padding may be needed to make the hop-by-hop options header a multiple of 8 bytes long.

Router Behavior A router can use DUG metadata to process packets belonging to the same traffic flow. For illustration, examples of such processing operations may include:

For increased reliability, DetNet routers may use one or more DUG header options to apply frame replication or different queuing techniques. For instance, the C or I flag can indicate higher importance of a packet or set of packets within the DUG, e.g., the establishment of a Transport Layer Security (TLS) session before the actual ADU is sent.
In case of congestion where some packets need to be dropped, the importance can be used to determine which packets to drop. This can include a subset of the entire DUG, identified by their DUG ID, within a DetNet flow.
Scheduling operations can use importance or other DUG metadata to determine which packet to send on which link. For example, the scheduler may forward packets on the same link used for other packets of the same DUG, to provide a consistent treatment. In another example, packets of higher importance may be forwarded over higher quality links.

Known Implementations The DUG concept described in this document is currently being implemented and validated in the SNS project PREDICT-6G , using temporary experimental values for the DUG sequence option and the DUG flag option The DUG-enabled router implementation utilises Express Data Paths (XDP) hooks provided by the extended Berkley Filters (eBPF) implementation in the Linux kernel . The XDP hook implements the parsing of the IPv6 header and the DUG options as well as extended logging to feed packet treatment behaviours to the monitoring repository of a Digital Twin. Furthermore, the XDP hook implements a fixed cycle time to judge all arriving packets against and over which basic queuing and drop mechanisms can be applied. Before testing the implementation, it was verified that the XDP hook has no negative impact on the actual networking performance of Linux. As reported in Section 2.2.7 in , the hook without any packet treatment (only parsing an IPv6 header and with logging implemented) had no impact on neither UDP nor TCP measurements using iperf and plain IPv6 traffic. To stress test the XDP hook and to provide measurement data to the Digital Twin to predict the impact on packet latency and jitter when admitting a new DetNet flow, a testbed of four nodes was created, as illustrated in . Two clients are connected to a forwarder, which is then connected to a Server. All links operate at 1G and are dedicated PCIe network interface cards. The forwarder is equipped with three network interface cards. To create congestion on the forwarder-to-server link, both clients (Client 1 and Client 2) send iperf-generated IPv6 traffic to the server. The clients also host a self-written client application that generates IPv6 traffic with the DUG header option. The DUG client applications inject two packets per second at the moment, signalling the start and the stop of a DUG.

DUG validation testbed With both iperf clients configured to max out the forwarder-to-server link (940Mbps maximum UDP goodput), the XDP hook allows to report on DUG packets that are not processed within a cycle to the monitoring repository of the Digital Twin. In the upcoming months, the XDP hook will be extended to be configurable from DetNet Controllers to read the priority field of the DUG flags and to prioritise a percentage of them if they are not being delivered with the configured XDP cycle time.

Security Considerations This memo describes metadata exposed in cleartext in the IPv6 header. This metadata is similar to metadata exposed in RTP header extensions such as . There is a potential for some limited privacy leakage, which may be acceptable for some applications, as a tradeoff to improve the overall quality of experience for the application. For example, it may be possible to determine video keyframes and their frequency.

IANA Considerations TODO: this memo may reserve one or more IPv6 Hop-by-Hop Options.

Acknowledgments This work has been partially funded by the European Commission Horizon Europe SNS JU projects PREDICT-6G (GA 101095890) . The following people contributed substantially to the content of this document and should be considered coauthors: Xavier de Foy, Abinaya Babu, and Muhammad Awais Jadoon.