RFC 9025

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

📅 published April 2021, from ietf

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

  • RFC: 9025 🎀 (Request for Comments: 9025)
  • Category: Standards Track 👑 (ISSN: 2070-1721)
  • Date: April 2021 🌸
  • Published by: Internet Engineering Task Force (IETF) 🌈
  • Authors: B. Varga, Ed. (Ericsson), J. Farkas (Ericsson), L. Berger (LabN Consulting, L.L.C.), A. Malis (Malis Consulting), S. Bryant (Futurewei Technologies) 🫶
  • Obsoletes / Updates: neither is listed in the header, so this one isn't replacing or updating anything 🙈

Abstract ✨

okay so this doc explains how the MPLS DetNet data plane works and how it gets wrapped up to ride over an IP network 🦋 The whole approach is built on how MPLS-over-UDP already operates, so it's giving familiar vibes 💅

Status of This Memo 📜

bestie, this is an Internet Standards Track document 👑 which means it's the real deal.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, and it went through public review before the Internet Engineering Steering Group (IESG) approved it for publication 💜 If you want more on Internet Standards, check out Section 2 of RFC 7841.

You can find the current status of this document, any errata, and a place to send feedback at https://www.rfc-editor.org/info/rfc9025 🍓

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, as they read on the publication date. https://trustee.ietf.org/license-info has the details. Please read these carefully because they spell out your rights and restrictions for this document 🙏 Any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🌸

Table of Contents 🗂️

1.  Introduction
2.  Terminology
  2.1.  Terms Used in This Document
  2.2.  Abbreviations
  2.3.  Requirements Language
3.  DetNet MPLS Operation over DetNet IP PSNs
4.  DetNet Data Plane Procedures
5.  Management and Control Information Summary
6.  Security Considerations
7.  IANA Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction 🧚

okay so Deterministic Networking (DetNet) is a service a network can offer to DetNet flows ✨ It gives those flows extremely low packet loss rates and a guaranteed maximum end-to-end delivery latency. Main character energy 👑 If you want the background and concepts, [RFC8655] is where to look.

To carry DetNet MPLS flows with full functionality at the DetNet layer over an IP network, you need these four components. They're a subset of the requirements for MPLS encapsulation listed in [RFC8964] 💅

  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 fully satisfied by the DetNet over MPLS Encapsulation in [RFC8964], and they're partly satisfied by the DetNet IP data plane in [RFC8939] 🦋 With that one, IP flows can be identified, but no DetNet sequence number gets carried.

This document is all about using the MPLS DetNet encapsulation over an IP network 🎀 The approach is modeled on how MPLS works over an IP Packet Switched Network (PSN) using UDP encapsulation, per [RFC7510]. It maps the MPLS data plane encapsulation from [RFC8964] onto the DetNet IP data plane from [RFC8939] 💖

[RFC7510] says, "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." 🙈 That rule does apply when you use RFC 7510 in a DetNet network, since DetNet is limited to a single administrative control or a closed group of administrative control.

2. Terminology 📚

2.1. Terms Used in This Document

This document uses the terminology from the DetNet architecture in [RFC8655]. It assumes you already know that document and its terms, so go read it if you haven't 🌸

2.2. Abbreviations

Here are the abbreviations this document uses 💜

d-CW          A DetNet Control Word (d-CW) is used for sequencing and
              identifying duplicate packets of a DetNet flow at the
              DetNet service sub-layer.

DetNet        Deterministic Networking

DSCP          Differentiated Services Code Point

A-Label       A special case of an S-Label, whose properties are
              known only at the aggregation and deaggregation
              endpoints.

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

MPLS          Multiprotocol Label Switching

OAM           Operations, Administration, and Maintenance

PEF           Packet Elimination Function

POF           Packet Ordering Function

PREOF         Packet Replication, Elimination, and Ordering Functions

PRF           Packet Replication Function

PSN           Packet Switched Network

S-Label       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

Here's the deal with the key words. "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like that 🔥 Lowercase ones are just regular words, bestie.

3. DetNet MPLS Operation over DetNet IP PSNs 🦋

This document builds on the MPLS over UDP spec in [RFC7510] ✨ It can partly or entirely swap out the F-Label(s) from [RFC8964] for UDP and IP headers. The UDP and IP header info is used to identify DetNet flows, including member flows, per [RFC8939]. The result looks like Figure 1 below. There can be zero or more F-Labels between the S-Label and the UDP header 💅

Note that this encapsulation works just as well with IPv4, IPv6, and IPv6-based Segment Routing [RFC8754] 🌈

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


               Figure 1: UDP/IP Encapsulation of DetNet MPLS

S-Labels, A-Labels (when present), d-CW, and zero or more F-Labels keep working the way [RFC8964] defines them. This document doesn't change any of them 🫶

4. DetNet Data Plane Procedures 💜

Okay, this is the part where the rules get real. To support outgoing DetNet MPLS over UDP encapsulation, an implementation MUST support provisioning UDP and IP header information, either in addition to F-Label(s) or in place of them 🔥 Heads up: when the PRF runs at the MPLS service sub-layer, there are multiple member flows, and each one needs its own UDP and IP header info provisioned.

The headers for each outgoing packet MUST be formatted according to the configuration information and as defined in [RFC7510]. The UDP Source Port value MUST be set so that it uniquely identifies the DetNet flow ✨ After that, the packet MUST then be handled as a DetNet IP packet, per [RFC8939], and that includes the QoS-related traffic treatment 💖

For the receive side, an implementation MUST also support provisioning received UDP and IP header information 🎀 That provisioned info MUST be used to identify incoming app flows based on the combo of the S-Label and the incoming encapsulation header info. Then normal receive processing from [RFC8964], including PEF and POF, can happen 🦋

5. Management and Control Information Summary 🗂️

Here's the minimum set of info you need to configure DetNet MPLS over UDP/IP 🌸

  • Label information (A-Labels, S-Labels, and F-Labels) that gets mapped to UDP/IP flows. For example, one S-Label can map to multiple sets of UDP/IP info 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 info MUST be provisioned per DetNet flow through configuration, for example through the controller in [RFC8655] or the management plane 🧚 Whether to use the UDP checksum is a case-by-case call for each network scenario, based on the exception criteria in [RFC7510], especially when IPv6 is in play 🙈

It's the DetNet Controller Plane's job to properly provision both the flow identification info and the flow-specific resources needed for the traffic treatment each flow's service requirements call for. This goes for both aggregated and individual flows 👑

   |  Note: In the presence of network (and port) address translation
   |  devices/functions, it would be up to the Controller Plane to
   |  determine the appropriate information to ensure proper mapping
   |  at the sender/receiver.

6. Security Considerations 🔒

bestie, this one is serious, so read carefully 💀

The solution in this document reuses mechanisms specified in other documents, and the security considerations in those documents apply equally here. [RFC7510] is especially important, since this document is mainly an application of MPLS-over-UDP. The security considerations for DetNet in general are covered in [RFC8655] and [DETNET-SECURITY]. Finally, the MPLS- and IP-specific security considerations are described in [RFC8964] and [RFC8939]. This document doesn't add any security considerations of its own 🫶

7. IANA Considerations 🌈

This document has no IANA actions ✨

8. References 📖

8.1. Normative References ✨

okay bestie, these are the docs DetNet has to be read alongside, no skipping 💅

8.2. Informative References 🦋

these ones are super useful for context, not strictly required reading, but I'd still read them, ngl 🤓

Acknowledgements 🫶

the authors wanted to give a huge shoutout to 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. the whole squad, honestly 👑✨

Contributors 🌸

this document is derived from an earlier draft that was edited by Jouni Korhonen (jouni.nospam@gmail.com), and as such, he contributed to and authored text in this document. he really left his mark, iykyk 💜

Authors' Addresses 💖

the people who made it all happen, with their contact details, so you can slide into their inbox if you have questions 📬

Balázs Varga (editor)
Ericsson
Budapest
Magyar Tudosok krt. 11.
1117
Hungary

Email: balazs.a.varga@ericsson.com


János Farkas
Ericsson
Budapest
Magyar Tudosok krt. 11.
1117
Hungary

Email: janos.farkas@ericsson.com


Lou Berger
LabN Consulting, L.L.C.

Email: lberger@labn.net


Andrew G. Malis
Malis Consulting

Email: agmalis@gmail.com


Stewart Bryant
Futurewei Technologies

Email: sb@stewartbryant.com
📦 where this page comes from