RFC 9566

Deterministic Networking (DetNet) Packet Replication, Elimination, and Ordering Functions (PREOF) via MPLS over UDP/IP

📅 published April 2024, from ietf

📡 RFC 9566: DetNet PREOF via MPLS over UDP/IP 🦋

Deterministic Networking (DetNet) Packet Replication, Elimination, and Ordering Functions (PREOF) via MPLS over UDP/IP

  • Number: RFC 9566, an IETF Request for Comments 💖
  • Authors: B. Varga and J. Farkas (Ericsson), and A. Malis (Malis Consulting) 👑
  • Category: Informational, so it's published for info and isn't a Standards Track spec 🌸
  • ISSN: 2070-1721
  • Date: April 2024 📅
  • Obsoletes / Updates: The title block doesn't list any RFCs it obsoletes or updates 🫶

Abstract ✨

Okay so this document explains how the DetNet IP data plane can support the Packet Replication, Elimination, and Ordering Functions (PREOF) 🔥. It builds on the existing MPLS PREOF solution for the DetNet MPLS data plane, plus the mechanisms from MPLS-over-UDP technology. Iconic combo, no cap 💅

Status of This Memo 🎀

This document is not an Internet Standards Track specification. It's published for informational purposes, so it's not a standard, bestie 🍓

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🌈 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for the deets 🧐

Info about this doc's current status, any errata, and how to give feedback is at https://www.rfc-editor.org/info/rfc9566 💜

Copyright (c) 2024 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 (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please actually read these, because they spell out your rights and restrictions for this doc 🙈 Code Components pulled from this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Revised BSD License 🫶

Table of Contents 🧚

   1.  Introduction
   2.  Terminology
     2.1.  Terms Used in This Document
     2.2.  Abbreviations
   3.  Requirements for Adding PREOF to DetNet IP
   4.  Adding PREOF to DetNet IP
     4.1.  Solution Basics
     4.2.  Encapsulation
     4.3.  Packet Processing
     4.4.  Flow Aggregation
     4.5.  PREOF Processing
     4.6.  PREOF-Capable DetNet IP Domain
   5.  Control and Management Plane Parameters
   6.  Security Considerations
   7.  IANA Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction 💖

Okay the DetNet Working Group defined Packet Replication (PRF), Packet Elimination (PEF), and Packet Ordering (POF) Functions, which are represented as PREOF 🦋 Their job is service protection in the DetNet service sub-layer [RFC8655] 🛡️ The PREOF service protection method sends copies of the same packet over multiple maximally disjoint paths, then uses sequencing info to eliminate duplicates. Main character energy 👑

A possible implementation of PRF and PEF is described in [IEEE8021CB], and its related YANG data model is defined in [IEEE8021CBcv]. A possible implementation of POF is described in [RFC9550] ✨

Figure 1 shows a DetNet flow where PREOF gets applied while forwarding from source to destination 👀

                                          +------------+
                +---------------E1---+    |            |
    +---+       |               |    +---R3---+        |          +---+
    |src|------R1           +---+             |        E3----O----+dst|
    +---+       |           |                 E2-------+          +---+
                +----------R2                 |
                            +-----------------+

    R: Replication Function (PRF)
    E: Elimination Function (PEF)
    O: Ordering Function (POF)

                Figure 1: PREOF Scenario in a DetNet Network

In general, PREOF needs sequencing info included in the packets of a DetNet compound flow 🌸 You can do that by adding a sequence number or timestamp as part of the DetNet encapsulation. The sequencing info is typically added once, at or close to the source 🍓

The DetNet MPLS data plane [RFC8964] specifies how sequencing info is encoded in the MPLS header. But the DetNet IP data plane described in [RFC8939] doesn't specify how sequencing info can be encoded in the IP packet 😭 This document gives sequencing info to DetNet IP nodes, so it results in an improved version of the DetNet IP data plane 🎀 As suggested by [RFC8938], the solution uses existing standardized headers and encapsulations. The improvement comes from reusing the DetNet MPLS-over-UDP/IP data plane [RFC9025] with the restriction of using zero F-Labels 🧠✨

2. Terminology 🌈

2.1. Terms Used in This Document

This document uses the terminology from the DetNet architecture [RFC8655]. It's assumed you're familiar with that doc and its terminology, so go read it first, periodt 📚

2.2. Abbreviations

The following abbreviations are used in this document:

   DetNet        Deterministic Networking

   PEF           Packet Elimination Function

   POF           Packet Ordering Function

   PREOF         Packet Replication, Elimination, and Ordering Functions

   PRF           Packet Replication Function

3. Requirements for Adding PREOF to DetNet IP 🎯

The requirements for adding PREOF to DetNet IP are:

  • To reuse existing DetNet data plane solutions (e.g., [RFC8964], [RFC9025]), and
  • To allow the DetNet service sub-layer for IP packet-switched networks with minimal implementation effort 🫶

The described solution leverages MPLS header fields without requiring support of the MPLS forwarding plane. Lowkey genius, ngl 🔥

4. Adding PREOF to DetNet IP 🦋

4.1. Solution Basics

The DetNet IP encapsulation supporting the DetNet service sub-layer is based on the "UDP tunneling" concept 🌊 The solution creates a set of underlay UDP/IP tunnels between an overlay set of DetNet relay nodes.

At the edge of a PREOF-capable DetNet IP domain, the DetNet flow gets encapsulated in a UDP packet that contains the sequence number PREOF uses within the domain 💜 This solution keeps the 6-tuple-based DetNet flow identification in DetNet transit nodes, which operate at the DetNet forwarding sub-layer between the DetNet service sub-layer nodes. So it's compatible with [RFC8939] 🙌 Figure 2 shows how the PREOF-capable DetNet IP data plane fits into the DetNet sub-layers.

                    DetNet          IP
                       .
                       .
                 +------------+
                 |  Service   | d-CW, Service-ID (S-Label)
                 +------------+
                 | Forwarding | UDP/IP Header
                 +------------+

                                *d-CW: DetNet Control Word

                Figure 2: PREOF-Capable DetNet IP Data Plane

4.2. Encapsulation

The PREOF-capable DetNet IP encapsulation builds on encapsulating DetNet pseudowire (PW) directly over UDP 🎀 That is, it combines DetNet MPLS [RFC8964] with DetNet MPLS-in-UDP [RFC9025], without using any F-Labels, as shown in Figure 3. DetNet flows are identified at the receiving DetNet service sub-layer processing node via the S-Label and/or the UDP/IP header information.

Sequencing info for PREOF is provided by the DetNet Control Word (d-CW) per [RFC8964]. The S-Label identifies both the DetNet flow and the DetNet App-flow type. The UDP tunnel directs the packet across the DetNet domain to the next DetNet service sub-layer processing node 🧚

      +---------------------------------+
      |                                 |
      |         DetNet App-Flow         |
      |       (Original IP) Packet      |
      |                                 |
      +---------------------------------+ <--\
      |       DetNet Control Word       |    |
      +---------------------------------+    +--> PREOF-capable
      |       Service-ID (S-Label)      |    |    DetNet IP data
      +---------------------------------+    |    plane encapsulation
      |            UDP Header           |    |
      +---------------------------------+    |
      |            IP Header            |    |
      +---------------------------------+ <--/
      |            Data-Link            |
      +---------------------------------+
      |             Physical            |
      +---------------------------------+

              Figure 3: PREOF-Capable DetNet IP Encapsulation

4.3. Packet Processing

IP ingress and egress nodes of the PREOF-capable DetNet IP domain add and remove a DetNet service-specific d-CW and Service-ID (i.e., S-Label) 💅 Relay nodes can change Service-ID values while processing a DetNet flow, so the incoming and outgoing Service-IDs of a DetNet flow can be different 🦋 Service-ID values get provisioned per DetNet service via configuration, e.g., via the Controller Plane described in [RFC8938].

In some PREOF topologies, the node doing replication sends packets to multiple nodes performing, e.g., PEF or POF. The replication node can use different Service-ID values for the different member flows of the same DetNet service. Multi-flow, multi-ID, very organized 🌸

Note that the Service-ID is a local ID on the receiver side. It identifies the DetNet flow at the downstream DetNet service sub-layer receiver, so it only means something locally 🫶

4.4. Flow Aggregation ✨

okay so flow aggregation has two methods bestie 🎀 the RFC lists them like this:

  • aggregation using same UDP tunnel, and
  • aggregation of DetNet flows as a new DetNet flow

For the first method, the different DetNet pseudowires all share the same UDP tunnel 🦋 so at the forwarding sub-layer they count as one single (aggregated) flow. The service sub-layer is where the individual flows get their own identity, because each one gets a different Service-ID (see Figure 3) 💅

The second method is giving layers 🧁 It adds an extra hierarchy by tacking on another Service-ID and d-CW tuple to the encapsulation. The Aggregate-ID is a special kind of Service-ID, and its properties are only known at the aggregation and deaggregation end points. The main quirk is that the Aggregate-ID gets followed by a d-CW, and then comes a Service-ID/d-CW tuple. Figure 4 shows what the encapsulation looks like when aggregation is happening 👀

      +---------------------------------+
      |                                 |
      |         DetNet App-Flow         |
      |         Payload  Packet         |
      |                                 |
      +---------------------------------+ <--\
      |       DetNet Control Word       |    |
      +---------------------------------+    +--> PREOF-capable
      |       Service-ID (S-Label)      |    |    DetNet IP data
      +---------------------------------+    |    plane encapsulation
      |       DetNet Control Word       |    |
      +---------------------------------+    |
      |      Aggregate-ID (A-Label)     |    |
      +---------------------------------+    |
      |           UDP Header            |    |
      +---------------------------------+    |
      |            IP Header            |    |
      +---------------------------------+ <--/
      |            Data-Link            |
      +---------------------------------+
      |             Physical            |
      +---------------------------------+

Figure 4: Aggregating DetNet Flows as a New DetNet Flow 🌸

The aggregation method gets configured in the aggregation/deaggregation nodes, so that's where the setup happens ⭐

Also, if several DetNet flows are squished into one UDP tunnel, they all need to take the same path through the network 🛣️ no splitting up allowed!

4.5. PREOF Processing 🔥

okay this part is about what a node does when a DetNet flow shows up at the DetNet service sub-layer 🧚 The node looks at the local context tied to the received Service-ID, and that tells it which local DetNet operation(s) to apply to the packet. A unique Service-ID can be allocated, and it can identify a DetNet flow no matter which input interface or UDP tunnel the packet came in on. It is important to note that Service-ID values are driven by the receiver, not the sender. The receiver is the boss here 👑

The DetNet forwarding sub-layer is backed up by the UDP tunnel, and it's the one responsible for resource allocation and explicit routes 💜

For outgoing PREOF encapsulation and processing, you can set it up by provisioning the UDP and IP header information. Heads up: when PRF is performed at the DetNet service sub-layer, there are multiple member flows, and each member flow needs its own Service-ID, UDP header information, and IP header information 🫶 The headers for every outgoing packet get formatted according to the configuration information, and the UDP Source Port value gets set so it uniquely identifies the DetNet flow. After that, the packet is handled as a PREOF-capable DetNet IP packet ✨

On the incoming side, the node can process things by assigning a Service-ID to the received DetNet flow and then reading the information in the UDP and IP headers. The provisioned information is what identifies incoming App-flows, based on the combination of Service-ID and/or incoming encapsulation header information 🎀

4.6. PREOF-Capable DetNet IP Domain 🌈

Figure 5 shows PREOF being used in a PREOF-capable DetNet IP network. The big difference here is that service protection is provided end to end, and not only within sub-networks, which is what Figure 4 in <https://www.rfc-editor.org/rfc/rfc8939#figure-4> of [RFC8939] depicts 🦋

             <---------- PREOF-capable DetNet IP --------------->
                                       ______
                             ____     /      \__
                  ____      /     \__/          \____________
   +----+      __/    \____/                                 \    +----+
   |src |_____/                                               \___| dst|
   +----+     \_______            DetNet network    __________/   +----+
                      \_______                    _/
                              \         __     __/
                               \_______/  \___/

                                          +------------+
                +---------------E1---+    |            |
   +----+       |               |    +---R3---+        |          +----+
   |src |------R1           +---+             |        E3----O----+ dst|
   +----+       |           |                 E2-------+          +----+
                +----------R2                 |
                            +-----------------+

Figure 5: PREOF-Capable DetNet IP Domain 💖

5. Control and Management Plane Parameters 🎀

okay here's the list of info needed to identify individual and aggregated DetNet flows 📋

  • Service-ID information to be mapped to UDP/IP flows. Note that, for example, a single Service-ID can map to multiple sets of UDP/IP information when PREOF is used.
  • IPv4 or IPv6 Source Address field.
  • IPv4 or IPv6 source address prefix length, where a zero (0) value effectively means that the address field is ignored.
  • IPv4 or IPv6 Destination Address field.
  • IPv4 or IPv6 destination address prefix length, where a zero (0) effectively means that the address field is ignored.
  • IPv6 Flow Label field.
  • IPv4 Protocol field being equal to "UDP".
  • IPv6 (last) Next Header field being equal to "UDP".
  • For the IPv4 Type of Service and IPv6 Traffic Class fields:
    • Whether or not the Differentiated Services Code Point (DSCP) field is used in flow identification, as the use of the DSCP field for flow identification is optional.
    • If the DSCP field is used to identify a flow, then the flow identification information (for that flow) includes a list of DSCPs used by the given DetNet flow.
  • UDP Source Port. Support for both exact and wildcard matching is required. Port ranges can optionally be used.
  • UDP Destination Port. Support for both exact and wildcard matching is required. Port ranges can optionally be used.
  • For end systems, an optional maximum IP packet size that should be used for that outgoing DetNet IP flow.

This info gets provisioned per DetNet flow via configuration, e.g., via the Controller Plane 🛠️

Ordering of the set of information used to identify an individual DetNet flow can, for example, be used to give a DetNet service to one specific UDP flow (with unique Source and Destination Port field values), while a different service goes to the aggregate of all other flows that share that same UDP Destination Port value 💅

The minimum set of information for configuring the DetNet service sub-layer is:

  • App-flow identification information
  • Sequence number length
  • Type of PREOF to be executed on the DetNet flow
  • Service-ID(s) used by the member flows
  • Associated forwarding sub-layer information
  • Service aggregation information

And the minimum set for configuring the DetNet forwarding sub-layer is:

  • UDP tunnel-specific information
  • Traffic parameters

These parameters are defined in the DetNet flow and service information model [RFC9016] and the DetNet YANG model 📚

Note: this document focuses on using MPLS-over-UDP/IP encapsulation throughout an entire DetNet IP network, which makes MPLS-based DetNet Operations, Administration, and Maintenance (OAM) techniques applicable [RFC9546]. Using the described encapsulation only for a portion of a DetNet IP network that handles PREOF would complicate OAM 🙈

6. Security Considerations 💀

Okay, bestie, listen up because this one is serious 😭 There are no new DetNet-related security considerations introduced by this solution. That said, the security considerations of DetNet MPLS [RFC8964] and DetNet MPLS over UDP/IP [RFC9025] still apply, so please don't skip them 🔒

7. IANA Considerations 🌸

This document has no IANA actions. Nothing to register here, slay 💅

8. References 📚

8.1. Normative References

8.2. Informative References

  • [IEEE8021CB] IEEE, "IEEE Standard for Local and metropolitan area networks -- Frame Replication and Elimination for Reliability", IEEE Std 802.1CB-2017, DOI 10.1109/IEEESTD.2017.8091139, October 2017, <https://doi.org/10.1109/IEEESTD.2017.8091139>.
  • [IEEE8021CBcv] IEEE, "IEEE Standard for Local and metropolitan area networks -- Frame Replication and Elimination for Reliability - Amendment 1: Information Model, YANG Data Model, and Management Information Base Module", Amendment to IEEE Std 802.1CB-2017, IEEE Std 802.1CBcv-2021, DOI 10.1109/IEEESTD.2022.9715061, February 2022, <https://doi.org/10.1109/IEEESTD.2022.9715061>.
  • [RFC9550] Varga, B., Ed., Farkas, J., Kehrer, S., and T. Heer, "Deterministic Networking (DetNet): Packet Ordering Function", RFC 9550, DOI 10.17487/RFC9550, March 2024, <https://www.rfc-editor.org/info/rfc9550>.

Acknowledgements 🫶

The authors want to give a huge thank you to Stewart Bryant, Pascal Thubert, David Black, Shirley Yangfan, and Greg Mirsky 🌈 Their insightful comments and productive discussion helped make the document way better ✨

Authors' Addresses ✨

The brains behind this one, and how to reach them 🫶

Balazs Varga 💖

Balazs Varga
Ericsson
Budapest
Magyar Tudosok krt. 11.
1117
Hungary
Email: balazs.a.varga@ericsson.com

Janos Farkas 🦋

Janos Farkas
Ericsson
Budapest
Magyar Tudosok krt. 11.
1117
Hungary
Email: janos.farkas@ericsson.com

Andrew G. Malis 🌸

Andrew G. Malis
Malis Consulting
Email: agmalis@gmail.com
📦 where this page comes from