detnet S. Robitzsch
Internet-Draft InterDigital
Intended status: Standards Track LM Contreras
Expires: 24 April 2025 Telefonica
21 October 2024
Data Unit Groups for DetNet-Enabled Networks
draft-rc-detnet-data-unit-groups-00
Abstract
This document provides the description of an Internet Protocol (IP)
Version 6 (IPv6) extension header allowing DetNet routers to
determine the relative importance between packets of the same flow,
which enables gracefully dropping packets in case of congestion.
This behaviour can for example be useful for media flows, where
different application units can have very different impact on the
quality of experience of the user. 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.
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.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Robitzsch & LM Contreras Expires 24 April 2025 [Page 1]
Internet-Draft DUG-for-DetNet October 2024
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
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. Definition, and abbreviations . . . . . . . . . . . . . . . . 2
1.1. Abbreviation . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Internet Protocol Version 6 Extension . . . . . . . . . . . . 4
4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
5. Known Implementations . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
9. Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Definition, and abbreviations
1.1. 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
Robitzsch & LM Contreras Expires 24 April 2025 [Page 2]
Internet-Draft DUG-for-DetNet October 2024
VR Virtual Reality
XR eXtended Reality
2. 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,
[_3GPP-23.501]), 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
[RFC8939] in an initial revision of this draft, and may be extended
to Multi-Protocol Label Switching (MPLS) [RFC8964] and MPLS over User
Datagram Protocol (UDP)/IP [RFC9566] data plane options in future
revisions.
Robitzsch & LM Contreras Expires 24 April 2025 [Page 3]
Internet-Draft DUG-for-DetNet October 2024
3. 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 [RFC6564],
[RFC8200], 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 Figure 1 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.
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 | Length | DUG ID | Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D| I |C|S|E|
+-+-+-+-+-+-+-+-+
Figure 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.
Robitzsch & LM Contreras Expires 24 April 2025 [Page 4]
Internet-Draft DUG-for-DetNet October 2024
* 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.
4. 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.
Robitzsch & LM Contreras Expires 24 April 2025 [Page 5]
Internet-Draft DUG-for-DetNet October 2024
5. Known Implementations
The DUG concept described in this document is currently being
implemented and validated in the SNS project PREDICT-6G [P6G], 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 [eBPF]. 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 [P6G-D4.2], 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 Figure 2. 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.
Robitzsch & LM Contreras Expires 24 April 2025 [Page 6]
Internet-Draft DUG-for-DetNet October 2024
------------
| Client 1 |
------------\
\
------------- ----------
| Forwarder |---| Server |
------------- ----------
/
------------/
| Client 2 |
------------
Figure 2: 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.
6. 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 [I-D.draft-ietf-avtext-framemarking]. 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.
7. IANA Considerations
TODO: this memo may reserve one or more IPv6 Hop-by-Hop Options.
8. Acknowledgments
This work has been partially funded by the European Commission
Horizon Europe SNS JU projects PREDICT-6G (GA 101095890) [P6G]. 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.
9. Informative References
Robitzsch & LM Contreras Expires 24 April 2025 [Page 7]
Internet-Draft DUG-for-DetNet October 2024
[eBPF] eBPF, "Dynamically program the kernel for efficient
networking, observability, tracing, and security", 2024,
<https://ebpf.io>.
[I-D.draft-ietf-avtext-framemarking]
Zanaty, M., Berger, E., and S. Nandakumar, "Video Frame
Marking RTP Header Extension", Work in Progress, Internet-
Draft, draft-ietf-avtext-framemarking-16, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-avtext-
framemarking-16>.
[P6G] PREDICT-6G, "PRogrammable AI-Enabled DeterminIstiC
neTworking for 6G", 2024, <https://www.predict-6g.eu>.
[P6G-D4.2] PREDICT-6G, "D4.2 First report on PREDICT-6G system
validation", 2024, <https://zenodo.org/records/13867457>.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, DOI 10.17487/RFC6564, April 2012,
<https://www.rfc-editor.org/rfc/rfc6564>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>.
[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/rfc/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/rfc/rfc8964>.
[RFC9566] Varga, B., Farkas, J., and A. Malis, "Deterministic
Networking (DetNet) Packet Replication, Elimination, and
Ordering Functions (PREOF) via MPLS over UDP/IP",
RFC 9566, DOI 10.17487/RFC9566, April 2024,
<https://www.rfc-editor.org/rfc/rfc9566>.
[_3GPP-23.501]
3GPP, "Technical Specification Group Services and System
Aspects; Stage 2, Release 19", 3GPP 23.501, 2024,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3144>.
Robitzsch & LM Contreras Expires 24 April 2025 [Page 8]
Internet-Draft DUG-for-DetNet October 2024
Authors' Addresses
Sebastian Robitzsch
InterDigital
United Kingdom
Email: sebastian.robitzsch@interdigital.com
Luis M. Contreras
Telefonica
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
Robitzsch & LM Contreras Expires 24 April 2025 [Page 9]