RFC 9037

Deterministic Networking (DetNet) Data Plane: MPLS over IEEE 802.1 Time-Sensitive Networking (TSN)

📅 published June 2021, from ietf

Deterministic Networking (DetNet) Data Plane: MPLS over IEEE 802.1 Time-Sensitive Networking (TSN) 💖

okay bestie, this is RFC 9037 🎀 It's an Informational doc (so it's published for info, not as an Internet Standards Track spec 🙈), dated June 2021, with ISSN 2070-1721. The authors are B. Varga (editor), J. Farkas from Ericsson, A. Malis from Malis Consulting, and S. Bryant from Futurewei Technologies. The header doesn't list anything it obsoletes or updates, so no drama there ✨

The whole point: it explains how the DetNet MPLS data plane works when the path between MPLS (DetNet) nodes goes over an IEEE 802.1 TSN sub-network 🦋

Status of This Memo

okay so this section says the doc isn't an Internet Standards Track spec, it's just published for info 🌸 It's an IETF product, it reflects IETF community consensus, it got public review, and the IESG approved it for publication. Not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for that. If you want the current status, errata, or a way to send feedback, head to https://www.rfc-editor.org/info/rfc9037 🫶

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions for this document 📜 Any Code Components pulled out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 🔥

Table of Contents

1.  Introduction
2.  Terminology
  2.1.  Terms Used in This Document
  2.2.  Abbreviations
3.  DetNet MPLS Data Plane Overview
4.  DetNet MPLS Operation over IEEE 802.1 TSN Sub-networks
  4.1.  Functions for DetNet Flow to TSN Stream Mapping
  4.2.  TSN Requirements of MPLS DetNet Nodes
  4.3.  Service Protection within the TSN Sub-network
  4.4.  Aggregation during DetNet Flow to TSN Stream Mapping
5.  Management and Control Implications
6.  Security Considerations
7.  IANA Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🧚

okay so DetNet (Deterministic Networking) is a service a network can offer to DetNet flows 💅 It gives those flows a low packet loss rate and an assured maximum end-to-end delivery latency, which is so iconic. If you want the background and concepts, check [RFC8655] ✨

The DetNet architecture splits the DetNet-related data plane functions into two sub-layers: a service sub-layer and a forwarding sub-layer 🌈 The service sub-layer handles DetNet service protection and reordering. The forwarding sub-layer handles congestion protection (low loss, assured latency, and limited reordering), and it does that by leaning on MPLS Traffic Engineering mechanisms 🎀

[RFC8964] is the one that specifies the DetNet data plane operation for an MPLS-based PSN. MPLS-encapsulated DetNet flows can ride over network technologies that can provide the level of service DetNet needs 🦋 This doc zooms in on the case where MPLS (DetNet) nodes are interconnected by an IEEE 802.1 TSN sub-network. There's also tight teamwork between the IETF DetNet Working Group and the IEEE 802.1 Time-Sensitive Networking Task Group (TSN TG) 🫶

2. Terminology 💖

2.1. Terms Used in This Document

This doc uses the terminology from the DetNet architecture, [RFC8655] and [RFC8964] 💅 TSN-specific terms are defined by the TSN TG of the IEEE 802.1 Working Group. The reader is assumed to be familiar with those docs and their terminology, so go get familiar bestie 📚

2.2. Abbreviations

The following abbreviations are used in this document:

A-Label       Aggregation label; a special case of an S-Label.

d-CW          DetNet Control Word

DetNet        Deterministic Networking

F-Label       Forwarding label that identifies the LSP used by a
              DetNet flow.

FRER          Frame Replication and Elimination for Redundancy (TSN
              function)

L2            Layer 2

L3            Layer 3

LSP           Label Switched Path

MPLS          Multiprotocol Label Switching

PREOF         Packet Replication, Elimination, and Ordering Functions

PSN           Packet Switched Network

PW            Pseudowire

RSVP-TE       Resource Reservation Protocol - Traffic Engineering

S-Label       Service label

TSN           Time-Sensitive Networking

3. DetNet MPLS Data Plane Overview 🌸

The basic approach in [RFC8964] supports the DetNet service sub-layer using existing PW encapsulations and mechanisms 💜 It also supports the DetNet forwarding sub-layer using existing MPLS Traffic Engineering encapsulations and mechanisms. Very reuse-coded, I love it 🙈

A node works on a DetNet flow in the DetNet service sub-layer. So if a node is processing a DetNet packet whose service label (S-Label) is on top of the stack, it uses the local context tied to that S-Label (like a received forwarding label, F-Label) to figure out which local DetNet operations to apply to the packet ✨ An S-Label can be unique when it's taken from the platform label space [RFC3031]. That would let the node correctly identify the DetNet flow no matter which input interface or LSP the packet arrived on 🔥 The service sub-layer functions (that's PREOF) use a d-CW.

The DetNet MPLS data plane builds on MPLS Traffic Engineering encapsulations and mechanisms to give you a forwarding sub-layer 🦋 That sub-layer is in charge of resource allocation and explicit routes. It's supported by one or more F-Labels.

DetNet edge/relay nodes are aware of the DetNet service sub-layer, they understand what DetNet flows need, and they provide both the DetNet service and forwarding sub-layer functions 🧚 They add, remove, and process d-CWs, S-Labels, and F-Labels as needed. MPLS DetNet nodes and transit nodes include DetNet forwarding sub-layer functions, which notably support explicit routes and resource allocation to eliminate (or reduce) congestion loss and jitter 💅 Unlike the other DetNet node types, transit nodes provide no service sub-layer processing. Main character energy for the forwarding layer, honestly 👑

MPLS (DetNet) nodes and transit nodes that are interconnected by a TSN sub-network are the main focus of this doc. Section 4 covers how DetNet MPLS flows get mapped to TSN Streams, and which TSN protection mechanisms apply 🎀

4. DetNet MPLS Operation over IEEE 802.1 TSN Sub-networks 🫶

The DetNet WG works with IEEE 802.1 TSN to define one common architecture for both Layer 2 and Layer 3, so things stay consistent across very different networks 🌈 DetNet MPLS and TSN use the same techniques to deliver their deterministic service:

  • Service protection
  • Resource allocation
  • Explicit routes

As the DetNet architecture [RFC8655] describes, from the MPLS perspective, a sub-network gives you a single-hop connection between MPLS (DetNet) nodes 🦋 Resource allocation and explicit routes are treated as domain-internal functions, so they don't need function interworking across the DetNet MPLS network and the TSN sub-network. No extra work, bestie ✨

For the service protection function, the DetNet PREOF and TSN FRER functions are similar enough that some level of interworking is possible 💖 But that interworking is out of scope for this doc and is left for further study 📚

Figure 1 shows two MPLS (DetNet) nodes interconnected by a TSN sub-network. Node-1 is single-homed, and Node-2 is dual-homed to the TSN sub-network 🦋

   MPLS (DetNet)                 MPLS (DetNet)
      Node-1                        Node-2

   +----------+                  +----------+
<--| Service* |-- DetNet flow ---| Service* |-->
   +----------+                  +----------+
   |Forwarding|                  |Forwarding|
   +--------.-+    <-TSN Str->   +-.-----.--+
             \      ,-------.     /     /
              +----[ TSN Sub-]---+     /
                   [ network ]--------+
                    `-------'
<---------------- DetNet MPLS --------------->

Note: * no service sub-layer required for transit nodes

     Figure 1: DetNet-Enabled MPLS Network over a TSN Sub-network

At the time of writing, the TSN TG of the IEEE 802.1 Working Group has defined (and is still defining) a bunch of amendments to [IEEE8021Q]. Those amendments provide zero congestion loss and bounded latency in bridged networks 🔥 [IEEE8021CB] also defines frame replication and elimination functions for reliability, and those should prove both compatible with and useful to DetNet networks 💜 All of these functions have to identify the flows that need TSN treatment, meaning they apply TSN functions during forwarding ✨

The TSN capabilities of the TSN sub-network are made available to MPLS (DetNet) flows through the protocol interworking function defined in Annex C.5 of [IEEE8021CB] 🧚 For example, when it's applied on the TSN edge port, it can convert an ingress unicast MPLS (DetNet) flow to use a specific Layer 2 multicast destination Media Access Control (MAC) address and a VLAN. That way the packet gets routed through a specific path inside the bridged network 🦋 A similar interworking function pair at the far end of the TSN sub-network restores the packet to its original Layer 2 destination MAC address and VLAN 🫶

Where TSN functions get placed depends on the TSN capabilities of the nodes along the path 🌸 MPLS (DetNet) nodes may or may not support TSN functions. For a given TSN Stream (which is the same thing as a DetNet flow), an MPLS (DetNet) node is treated as a Talker or a Listener inside the TSN sub-network 💅

Part 1 done, slay 🌈✨💖

4.1. Functions for DetNet Flow to TSN Stream Mapping ✨

okay so mapping a DetNet MPLS flow onto a TSN Stream is a two-step combo 💅 There's a passive and an active Stream identification function, and both work at the frame level 🎀. The passive one catches the MPLS label(s) of a DetNet MPLS flow. The active one edits the Ethernet header so it matches the ID of the mapped TSN Stream 🦋

Clause 6.8 of [IEEEP8021CBdb] defines a Mask-and-Match Stream identification function, and it can be the passive function for MPLS DetNet flows 💖

Clause 6.6 of [IEEE8021CB] defines an Active Destination MAC and a VLAN Stream identification function. It can swap out three Ethernet header fields for alternate values: (1) the destination MAC address, (2) the VLAN-ID, and (3) priority parameters 🌸 The replacement happens whether the frame is coming down the stack from the upper layers or up from the lower layers 🧚

Active Destination MAC and VLAN Stream identification can be used within a Talker to set flow identity, or within a Listener to recover the original addressing information 🫶 It can also be used in a TSN bridge that is providing translation as a proxy service for an end system 💜

4.2. TSN Requirements of MPLS DetNet Nodes

this is where the rules get serious 😭 This section covers required behavior of a TSN-aware MPLS (DetNet) node using a TSN sub-network. The implementation of TSN packet-processing functions must be compliant with the relevant IEEE 802.1 standards.

From the TSN sub-network's point of view, MPLS (DetNet) nodes are treated as a Talker or Listener, and they may be (1) TSN-unaware or (2) TSN-aware 🍓

For TSN-unaware MPLS DetNet nodes, the TSN relay nodes within the TSN sub-network must modify the Ethernet encapsulation of the DetNet MPLS flow (e.g., MAC translation, VLAN-ID setting, sequence number addition, etc.) so that proper TSN-specific handling happens inside the sub-network 🔥 There are no requirements defined for TSN-unaware MPLS DetNet nodes in this document.

TSN-aware MPLS (DetNet) nodes can be treated as a combo of a TSN-unaware Talker/Listener and a TSN-Relay, as shown in Figure 2 👑 In that case, the MPLS (DetNet) node must provide the TSN sub-network-specific Ethernet encapsulation over the link(s) towards the sub-network.

                 MPLS (DetNet)
                     Node
      <---------------------------------->

      +----------+
   <--| Service* |-- DetNet flow ------------------
      +----------+
      |Forwarding|
      +----------+    +---------------+
      |    L2    |    | L2 Relay with |<--- TSN ---
      |          |    | TSN function  |    Stream
      +-----.----+    +--.------.---.-+
             \__________/        \   \______
                                  \_________
       TSN-unaware
        Talker /          TSN-Bridge
        Listener             Relay
                                          <----- TSN Sub-network -----
      <------- TSN-aware Tlk/Lstn ------->

   Note: * no service sub-layer required for transit nodes

              Figure 2: MPLS (DetNet) Node with TSN Functions

A TSN-aware MPLS (DetNet) node implementation must support the Stream identification TSN component for recognizing flows 🔍

A Stream identification component must be able to instantiate the following functions: (1) Active Destination MAC and VLAN Stream identification function, (2) Mask-and-Match Stream identification function, and (3) the related managed objects in Clause 9 of [IEEE8021CB] and [IEEEP8021CBdb] 🧩

A TSN-aware MPLS (DetNet) node implementation must support the Sequencing function and the Sequence encode/decode function as defined in Clauses 7.4 and 7.6 of [IEEE8021CB] in order for FRER to be used inside the TSN sub-network 🔁

The Sequence encode/decode function must support the Redundancy tag (R-TAG) format as per Clause 7.8 of [IEEE8021CB] 🏷️

A TSN-aware MPLS (DetNet) node implementation must support the Stream splitting function and the Individual recovery function as defined in Clauses 7.5 and 7.7 of [IEEE8021CB] in order for that node to be a replication or elimination point for FRER 👯‍♀️

4.3. Service Protection within the TSN Sub-network

TSN Streams supporting DetNet flows may use FRER as defined in Clause 8 of [IEEE8021CB], based on the loss service requirements of the TSN Stream. Those are derived from the DetNet service requirements of the DetNet mapped flow 🛡️ The specific operation of FRER is not modified by the use of DetNet and follows [IEEE8021CB].

FRER and the service recovery it provides are only available within the TSN sub-network 🙅‍♀️ The reason is that the TSN Stream-ID and the TSN sequence number are not valid outside the sub-network. An MPLS (DetNet) node represents an L3 border, so it terminates all related information elements encoded in the L2 frames.

As the Stream-ID and the TSN sequence number are paired with similar MPLS flow parameters, FRER can be combined with PREOF functions 🌈 Such service protection interworking scenarios may require moving sequence number fields among TSN (L2) and PW (MPLS) encapsulations, and they are left for further study 🔮

4.4. Aggregation during DetNet Flow to TSN Stream Mapping

Implementation of this document shall use management and control information to map a DetNet flow to a TSN Stream. N:1 mapping (aggregating DetNet flows in a single TSN Stream) shall be supported 📦 The management or control function that provisions flow mapping shall ensure that adequate resources are allocated and configured to provide proper service requirements of the mapped flows 💅

5. Management and Control Implications ⚙️

Information related to DetNet flow and TSN Stream mapping is required only for TSN-aware MPLS (DetNet) nodes. From the data plane perspective, there is no practical difference based on the origin of flow-mapping-related information (management plane or control plane) 🤷‍♀️

The following summarizes the set of information that is needed to configure DetNet MPLS over TSN:

  • DetNet MPLS-related configuration information according to the DetNet role of the DetNet MPLS node, as per [RFC8964].
  • TSN-related configuration information according to the TSN role of the DetNet MPLS node, as per [IEEE8021Q], [IEEE8021CB], and [IEEEP8021CBdb].
  • Mapping between a DetNet MPLS flow(s) (label information: A-Labels, S-Labels, and F-Labels as defined in [RFC8964]) and a TSN Stream(s) (as Stream identification information defined in [IEEEP8021CBdb]). Note that managed objects for TSN Stream identification can be found in [IEEEP8021CBcv].

This information must be provisioned per DetNet flow 📝

Mappings between DetNet and TSN management and control planes are out of scope of this document. Some of the challenges are highlighted below 👀

TSN-aware MPLS DetNet nodes are members of both the DetNet domain and the TSN sub-network 🌉 Within the TSN sub-network, the TSN-aware MPLS (DetNet) node has a TSN-aware Talker/Listener role, so TSN-specific management and control plane functionalities must be implemented. There are many similarities in the management plane techniques used in DetNet and TSN, but that is not the case for the control plane protocols. For example, RSVP-TE and the Multiple Stream Registration Protocol (MSRP) behave differently. Therefore, management and control plane design are important aspects of scenarios where mapping between DetNet and TSN is required 🧠

In order to use a TSN sub-network between DetNet nodes, DetNet-specific information must be converted to information specific to the TSN sub-network. DetNet flow ID and flow-related parameters/requirements must be converted to a TSN Stream ID and stream-related parameters/requirements. Note that, as the TSN sub-network is just a portion of the end-to-end DetNet path (i.e., a single hop from the MPLS perspective), some parameters (e.g., delay) may differ significantly. Other parameters (like bandwidth) also may have to be tuned due to the L2 encapsulation used within the TSN sub-network 🎚️

In some cases, it may be challenging to determine some TSN-Stream-related information. For example, on a TSN-aware MPLS (DetNet) node that acts as a Talker, it is quite obvious which DetNet node is the Listener of the mapped TSN Stream (i.e., the MPLS next hop). However, it may be not trivial to locate the point/interface where that Listener is connected to the TSN sub-network. Such attributes may require interaction between control and management plane functions and between DetNet and TSN domains 🗺️

Mapping between DetNet flow identifiers and TSN Stream identifiers, if not provided explicitly, can be done by a TSN-aware MPLS (DetNet) node locally, based on information provided for configuration of the TSN Stream identification functions (Mask-and-Match Stream identification and active Stream identification) 🏠

Triggering the setup/modification of a TSN Stream in the TSN sub-network is an example where management and/or control plane interactions are required between the DetNet and TSN sub-network. TSN-unaware MPLS (DetNet) nodes make such a triggering even more complicated, as they are fully unaware of the sub-network and run independently 😵‍💫

Configuration of TSN-specific functions (e.g., FRER) inside the TSN sub-network is a TSN-domain-specific decision and may not be visible in the DetNet domain. Service protection interworking scenarios are left for further study 🔮

6. Security Considerations 🔐

Security considerations for DetNet are described in detail in [DETNET-SECURITY]. General security considerations are described in [RFC8655]. Considerations specific to the DetNet MPLS data plane are summarized in [RFC8964]. This section considers exclusively security considerations that are specific to the DetNet MPLS over TSN sub-network scenario.

The sub-network between DetNet nodes needs to be subject to appropriate confidentiality. Additionally, knowledge of what DetNet/TSN services are provided by a sub-network may supply information that can be used in a variety of security attacks. The ability to modify information exchanges between connected DetNet nodes may result in bogus operations. Therefore, it is important that the interface between DetNet nodes and the TSN sub-network are subject to authorization, authentication, and encryption.

⚠️ Serious moment, bestie: the bogus-operations risk above is real, so the interface between DetNet nodes and the TSN sub-network needs authorization, authentication, and encryption. Don't skip this one 😭

The TSN sub-network operates at Layer 2, so various security mechanisms defined by IEEE can be used to secure the connection between the DetNet nodes (e.g., encryption may be provided using MACsec [IEEE802.1AE-2018]) 🦋

7. IANA Considerations 🌸

This document has no IANA actions.

8. References 📚

8.1. Normative References

okay so this is the list of must-read stuff 📚✨ the spec leans on these, so you need them to get the full picture 💅

8.2. Informative References

these ones are extra reading 🦋 not strictly required, but lowkey super helpful if you want the deeper lore 🔥

  • [DETNET-SECURITY] Grossman, E., Ed., Mizrahi, T., and A. Hacker, "Deterministic Networking (DetNet) Security Considerations", Work in Progress, Internet-Draft, draft-ietf-detnet-security-16, 2 March 2021, <https://tools.ietf.org/html/draft-ietf-detnet-security-16>.
  • [IEEE802.1AE-2018] IEEE, "IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security", IEEE Std 802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December 2018, <https://ieeexplore.ieee.org/document/8585421>. 🎀
  • [IEEE8021Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", IEEE Std 802.1Q-2018, DOI 10.1109/IEEESTD.2018.8403927, July 2018, <https://ieeexplore.ieee.org/document/8403927/>. 🍓
  • [IEEEP8021CBcv] IEEE 802.1, "Draft Standard for Local and metropolitan area networks -- Frame Replication and Elimination for Reliability -- Amendment: Information Model, YANG Data Model and Management Information Base Module", IEEE P802.1CBcv, Draft 1.1, February 2021, <https://1.ieee802.org/tsn/802-1cbcv/>. 🧚

Acknowledgements

huge thank-you to Norman Finn, Lou Berger, Craig Gunther, Christophe Mangin, and Jouni Korhonen 🫶💖 the authors said thanks for all their different contributions to this work, and honestly the whole spec is better because of them ✨

Authors' Addresses

the authors, in their own words 🌸

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


Andrew G. Malis
Malis Consulting

Email: agmalis@gmail.com


Stewart Bryant
Futurewei Technologies

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