Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 9025

Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IP

Pages: ~8
Proposed Standard

Top   ToC   RFCv3-9025
B. Varga, Ed.
J. Farkas
L. Berger
LabN Consulting, L.L.C.
A. Malis
Malis Consulting
S. Bryant
Futurewei Technologies
April 2021

Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IP


This document specifies the MPLS Deterministic Networking (DetNet) data plane operation and encapsulation over an IP network. The approach is based on the operation of MPLS-over-UDP technology.

Status of This Memo

This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at

Copyright Notice

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Top   ToC   RFCv3-9025

1.  Introduction

Deterministic Networking (DetNet) is a service that can be offered by a network to DetNet flows. DetNet provides these flows extremely low packet loss rates and assured maximum end-to-end delivery latency. General background and concepts of DetNet can be found in [RFC 8655].
To carry DetNet MPLS flows with full functionality at the DetNet layer over an IP network, the following components are required (these are a subset of the requirements for MPLS encapsulation listed in [RFC 8964]):
  1. A method for identifying DetNet flows to the processing element.
  2. A method for carrying the DetNet sequence number.
  3. A method for distinguishing DetNet Operations, Administration, and Maintenance (OAM) packets from DetNet data packets.
  4. A method for carrying queuing and forwarding indication.
These requirements are satisfied by the DetNet over MPLS Encapsulation described in [RFC 8964] and they are partly satisfied (i.e., IP flows can be identified; however, no DetNet sequence number is carried) by the DetNet IP data plane defined in [RFC 8939].
This document specifies use of the MPLS DetNet encapsulation over an IP network. The approach is modeled on the operation of MPLS over an IP Packet Switched Network (PSN) using UDP encapsulation [RFC 7510]. It maps the MPLS data plane encapsulation described in [RFC 8964] to the DetNet IP data plane defined in [RFC 8939].
[RFC 7510] specifies that "MPLS-in-UDP MUST NOT be used over the general Internet, or over non-cooperating network operators, to carry traffic that is not congestion controlled." This constraint does apply to the use of RFC 7510 in a DetNet network because DetNet is constrained to operate within a single administrative control or within a closed group of administrative control.
Top   ToC   RFCv3-9025

2.  Terminology

2.1.  Terms Used in This Document

This document uses the terminology established in the DetNet architecture [RFC 8655]; the reader is assumed to be familiar with that document and its terminology.

2.2.  Abbreviations

The following abbreviations are used in this document:
A DetNet Control Word (d-CW) is used for sequencing and identifying duplicate packets of a DetNet flow at the DetNet service sub-layer.
Deterministic Networking
Differentiated Services Code Point
A special case of an S-Label, whose properties are known only at the aggregation and deaggregation endpoints.
A DetNet "forwarding" label that identifies the LSP used to forward a DetNet flow across an MPLS PSN, e.g., a hop-by-hop label used between label-switching routers.
Multiprotocol Label Switching
Operations, Administration, and Maintenance
Packet Elimination Function
Packet Ordering Function
Packet Replication, Elimination, and Ordering Functions
Packet Replication Function
Packet Switched Network
A DetNet "service" label that is used between DetNet nodes that also implement the DetNet service sub-layer functions. An S-Label is also used to identify a DetNet flow at the DetNet service sub-layer.

2.3.  Requirements Language

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 [RFC 2119] [RFC 8174] when, and only when, they appear in all capitals, as shown here.
Top   ToC   RFCv3-9025

3.  DetNet MPLS Operation over DetNet IP PSNs

This document builds on the specification of MPLS over UDP defined in [RFC 7510]. It may partly or entirely replace the F-Label(s) used in [RFC 8964] with UDP and IP headers. The UDP and IP header information is used to identify DetNet flows, including member flows, per [RFC 8939]. The resulting encapsulation is shown in Figure 1. There may be zero or more F-Labels between the S-Label and the UDP header.
Note that this encapsulation works equally well with IPv4, IPv6, and IPv6-based Segment Routing [RFC 8754].
|                                 |
|         DetNet App-Flow         |
|         Payload  Packet         |
|                                 |
+---------------------------------+ <--\
|       DetNet Control Word       |    |
+---------------------------------+    +--> DetNet data plane
|             S-Label             |    |    MPLS encapsulation
+---------------------------------+    |
|          [ F-Label(s) ]         |    |
+---------------------------------+ <--+
|           UDP Header            |    |
+---------------------------------+    +--> DetNet data plane
|           IP Header             |    |    IP encapsulation
+---------------------------------+ <--/
|           Data-Link             |
|           Physical              |

S-Labels, A-Labels (when present), d-CW, and zero or more F-Labels are used as defined in [RFC 8964] and are not modified by this document.
Top   ToC   RFCv3-9025

4.  DetNet Data Plane Procedures

To support outgoing DetNet MPLS over UDP encapsulation, an implementation MUST support the provisioning of UDP and IP header information in addition to or in place of F-Label(s). Note, when the PRF is performed at the MPLS service sub-layer, there will be multiple member flows, and each member flow will require the provisioning of their own UDP and IP header information. The headers for each outgoing packet MUST be formatted according to the configuration information and as defined in [RFC 7510], and the UDP Source Port value MUST be set to uniquely identify the DetNet flow. The packet MUST then be handled as a DetNet IP packet, per [RFC 8939]. This includes QoS-related traffic treatment.
To support the receive processing defined in this document, an implementation MUST also support the provisioning of received UDP and IP header information. The provisioned information MUST be used to identify incoming app flows based on the combination of S-Label and incoming encapsulation header information. Normal receive processing as defined in [RFC 8964], including PEF and POF, can then take place.
Top   ToC   RFCv3-9025

5.  Management and Control Information Summary

The following summarizes the minimum set of information that is needed to configure DetNet MPLS over UDP/IP:
  • Label information (A-Labels, S-Labels, and F-Labels) to be mapped to UDP/IP flows. Note that, for example, a single S-Label can map to multiple sets of UDP/IP information when PREOF is used.
  • IPv4 or IPv6 source address field
  • IPv4 or IPv6 destination address field
  • DSCP Field in either IPv4 Type of Service or IPv6 Traffic Class Fields
  • UDP Source Port
  • UDP Destination Port
  • Use/non-use of UDP checksum
This information MUST be provisioned per DetNet flow via configuration, e.g., via the controller [RFC 8655] or management plane. Not using the UDP checksum has to be evaluated on a case-by-case basis for a given network scenario based on the exception criteria defined in [RFC 7510], particularly when IPv6 is used.
It is the responsibility of the DetNet Controller Plane to properly provision both flow identification information and the flow-specific resources needed to provide the traffic treatment needed to meet each flow's service requirements. This applies for both aggregated and individual flows.
Top   ToC   RFCv3-9025

6.  Security Considerations

The solution defined in this document reuses mechanisms specified in other documents, and the security considerations in those documents apply equally to this document. Of particular note is [RFC 7510], as this document is primarily an application of MPLS-over-UDP. Additionally, the security considerations of DetNet in general are discussed in [RFC 8655] and [DETNET-SECURITY]. Finally, MPLS- and IP-specific security considerations are described in [RFC 8964] and [RFC 8939]. This document does not have additional security considerations.
Top   ToC   RFCv3-9025

7.  IANA Considerations

This document has no IANA actions.
Top   ToC   RFCv3-9025

8.  References

8.1.  Normative References

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
X. Xu, N. Sheth, L. Yong, R. Callon, and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 2015,
B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
B. Varga, J. Farkas, L. Berger, D. Fedyk, and S. Bryant, "Deterministic Networking (DetNet) Data Plane: IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
B. Varga, J. Farkas, L. Berger, A. Malis, S. Bryant, and J. Korhonen, "Deterministic Networking (DetNet) Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January 2021,

8.2.  Informative References

E Grossman, T Mizrahi, and A. J. Hacker, "Deterministic Networking (DetNet) Security Considerations", Internet-Draft draft-ietf-detnet-security-16, February 2021,
N. Finn, P. Thubert, B. Varga, and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019,
C. Filsfils, D. Dukes, S. Previdi, J. Leddy, S. Matsushima, and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
Top   ToC   RFCv3-9025


The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig Gunther, George Swallow, Yuanlong Jiang, and Carlos J. Bernardos for their various contributions to this work.
Top   ToC   RFCv3-9025


This document is derived from an earlier draft that was edited by Jouni Korhonen (, and as such, he contributed to and authored text in this document.
Top   ToC   RFCv3-9025

Authors' Addresses

Balázs Varga

Magyar Tudosok krt. 11.
Budapest   1117

János Farkas

Magyar Tudosok krt. 11.
Budapest   1117

Lou Berger

LabN Consulting, L.L.C.

Andrew G. Malis

Malis Consulting

Stewart Bryant

Futurewei Technologies
Top   ToC