RFC 8964
Deterministic Networking (DetNet) Data Plane: MPLS
🎀 RFC 8964: Deterministic Networking (DetNet) Data Plane: MPLS 🦋
Okay bestie, this one is a Standards Track document from the IETF 💅 Its status is Internet Standards Track, it was published in January 2021, and it's the official RFC 8964 🌸 It was written by B. Varga, Ed. (editor), J. Farkas (Ericsson), L. Berger (LabN Consulting, L.L.C.), A. Malis (Malis Consulting), S. Bryant (Futurewei Technologies), and J. Korhonen ✨ It's an ISSN 2070-1721 doc, and it doesn't obsolete or update any other RFCs. Iconic, right? 👑
Abstract
okay so this doc specifies how the DetNet data plane works when it's running over an MPLS Packet Switched Network 🫶 It's lowkey built on top of stuff that already exists: pseudowire (PW) encapsulations and MPLS Traffic Engineering (MPLS-TE) encapsulations and mechanisms 💜 And it builds on the DetNet architecture and data plane framework. Main character energy, no cap 🔥
Status of This Memo
this is an Internet Standards Track document 💖
it's a product of the Internet Engineering Task Force (IETF) ✨ It represents the consensus of the IETF community, received public review, and got approved for publication by the Internet Engineering Steering Group (IESG) 🎀 If you want more info on Internet Standards, check out Section 2 of RFC 7841 🦋
for the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc8964 🌈
Copyright Notice
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 were on the publication date 📜 Read those carefully, bestie, because they explain your rights and restrictions. Code Components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 💅
Table of Contents 🧚
- Introduction
- Terminology
- 2.1. Terms Used in This Document
- 2.2. Abbreviations
- 2.3. Requirements Language
- Overview of the DetNet MPLS Data Plane
- 3.1. Layers of DetNet Data Plane
- 3.2. DetNet MPLS Data Plane Scenarios
- MPLS-Based DetNet Data Plane Solution
- 4.1. DetNet over MPLS Encapsulation Components
- 4.2. MPLS Data Plane Encapsulation
- 4.2.1. DetNet Control Word and DetNet Sequence Number
- 4.2.2. S-Labels
- 4.2.3. F-Labels
- 4.3. OAM Indication
- 4.4. Flow Aggregation
- 4.4.1. Aggregation via LSP Hierarchy
- 4.4.2. Aggregating DetNet Flows as a New DetNet Flow
- 4.5. Service Sub-Layer Considerations
- 4.5.1. Edge Node Processing
- 4.5.2. Relay Node Processing
- 4.6. Forwarding Sub-Layer Considerations
- 4.6.1. Class of Service
- 4.6.2. Quality of Service
- Management and Control Information Summary
- 5.1. Service Sub-Layer Information Summary
- 5.1.1. Service Aggregation Information Summary
- 5.2. Forwarding Sub-Layer Information Summary
- 5.1. Service Sub-Layer Information Summary
- Security Considerations
- IANA Considerations
- References
- 8.1. Normative References
- 8.2. Informative References
Acknowledgements, Contributors, and Authors' Addresses are also in here ✨
1. Introduction ✨
okay so DetNet is a service a network can offer to DetNet flows 🦋 It gives you data delivery with extremely low packet loss rates and bounded end-to-end delivery latency, which is so iconic 😭 You can get the general background and concepts from the DetNet architecture [RFC8655] 💜
so this doc is all about using the MPLS data plane to set up and support DetNet flows 🎀 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 gives you DetNet service functions like protection and reordering. In the DetNet data plane, a new set of functions, the Packet Replication, Elimination and Ordering Functions (PREOF), handle the service sub-layer tasks ✨ The forwarding sub-layer gives you forwarding assurance: low loss, assured latency, and limited out-of-order delivery 👑 Using the service sub-layer and forwarding sub-layer functions takes careful design and control by the Controller Plane, on top of the DetNet-specific MPLS encapsulation specified here 💅
this doc specifies the DetNet data plane operation and the on-wire encapsulation of DetNet flows over an MPLS-based Packet Switched Network (PSN), using the service reference model 🧚 MPLS encapsulation already gives you a solid foundation of building blocks for the DetNet service and forwarding sub-layer functions 🫶 MPLS-encapsulated DetNet can ride over a bunch of different network technologies that can give the level of service DetNet needs 💖 However, how DetNet MPLS gets carried over those specific technologies is out of scope for this doc 🙈
MPLS-encapsulated DetNet flows can carry different types of traffic, and the details of those traffic types are also out of scope 🌈 There's an example of IP using DetNet MPLS sub-networks in [RFC8939] ✨ DetNet MPLS may use an associated controller and Operations, Administration, and Maintenance (OAM) functions that are defined outside of this document 🍓
background info that's common to all DetNet data planes is in the DetNet data plane framework [RFC8938] 💜
2. Terminology ✨
2.1. Terms Used in This Document
this doc uses the terminology from the DetNet architecture [RFC8655] and the DetNet data plane framework [RFC8938] 💅 You're assumed to know those docs, their terms, and basic MPLS terminology from [RFC3031] 🫶
these are the terms introduced here:
- F-Label: a DetNet "forwarding" label that identifies the Label Switched Path (LSP) used to forward a DetNet flow across an MPLS PSN. It's a hop-by-hop label used between Label Switching Routers (LSRs) 🦋
- S-Label: a DetNet "service" label used between DetNet nodes that implement the DetNet service sub-layer functions. An S-Label identifies a DetNet flow at the DetNet service sub-layer at a receiving DetNet node 🎀
- A-Label: a special case of an S-Label, whose aggregation properties are known only at the aggregation and deaggregation end points 🌸
- d-CW: a DetNet Control Word (d-CW) used for sequencing information of a DetNet flow at the DetNet service sub-layer ✨
2.2. Abbreviations
these abbreviations show up in this doc 👑
- CoS: Class of Service
- CW: Control Word
- DetNet: Deterministic Networking
- LSR: Label Switching Router
- MPLS: Multiprotocol Label Switching
- MPLS-TE: Multiprotocol Label Switching Traffic Engineering
- MPLS-TP: Multiprotocol Label Switching Transport Profile
- OAM: Operations, Administration, and Maintenance
- PE: Provider Edge
- PEF: Packet Elimination Function
- PRF: Packet Replication Function
- PREOF: Packet Replication, Elimination and Ordering Functions
- POF: Packet Ordering Function
- PSN: Packet Switched Network
- PW: Pseudowire
- QoS: Quality of Service
- S-PE: Switching Provider Edge
- T-PE: Terminating Provider Edge
- TSN: Time-Sensitive Networking
2.3. Requirements Language
the key words here are the BCP 14 ones, and they only count when they show up in all capitals, as shown in the list below 💖 They get interpreted as described in BCP 14 [RFC2119] [RFC8174]:
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL"3. Overview of the DetNet MPLS Data Plane 🧚
3.1. Layers of DetNet Data Plane
MPLS gives DetNet a wide range of capabilities to use 🌈 A straightforward approach is to use MPLS for a DetNet service sub-layer based on the existing pseudowire (PW) encapsulations, plus the existing MPLS-TE encapsulations and mechanisms 💜 You can read up on PWs in [RFC3985], [RFC3032], and [RFC3031], and on MPLS-TE in [RFC3272] and [RFC3209] ✨
Here's the layer picture from Figure 1 🎀
DetNet MPLS
.
Bottom of Stack .
(inner label) +------------+
| Service | d-CW, S-Label (A-Label)
+------------+
| Forwarding | F-Label(s)
+------------+
Top of Stack .
(outer label) .
Figure 1: DetNet Adaptation to MPLS Data Planeso in Figure 1, the service sub-layer has a DetNet Control Word (d-CW) and an identifying service label (S-Label) 🦋 The d-CW follows the Generic PW MPLS Control Word (PWMCW) defined in [RFC4385] 💅 An aggregation label (A-Label) is a special case of S-Label used for aggregation 🌸
a node processing a received DetNet flow at the service sub-layer uses the local context tied to a received S-Label (aka a received F-Label, per the original text) to figure out which local DetNet operations to apply to that packet 🫶 An S-Label can come from the platform label space [RFC3031], which makes it unique and lets you identify the DetNet flow no matter which input interface or LSP the packet shows up on 🙌 Important note, bestie: S-Label values are driven by the receiver, not the sender 🚨
the DetNet forwarding sub-layer is supported by zero or more forwarding labels (F-Labels) 👑 MPLS-TE encapsulations and mechanisms can be used to provide a forwarding sub-layer that's responsible for resource allocation and explicit routes 💖
Part 1 of 7. More parts coming, so keep your eyes peeled 👀✨
3.2. DetNet MPLS Data Plane Scenarios ✨
Okay bestie, let's look at a DetNet MPLS network picture 🦋
DetNet MPLS Relay Transit Relay DetNet MPLS
End System Node Node Node End System
(T-PE) (S-PE) (LSR) (S-PE) (T-PE)
+----------+ +----------+
| Appl. |<------------ End-to-End Service ----------->| Appl. |
+----------+ +---------+ +---------+ +----------+
| Service |<--| Service |-- DetNet flow --| Service |-->| Service |
+----------+ +---------+ +----------+ +---------+ +----------+
|Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding|
+-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+
: Link : / ,-----. \ : Link : / ,-----. \
+........+ +-[ Sub- ]-+ +......+ +-[ Sub- ]-+
[Network] [Network]
`-----' `-----'
|<- LSP -->| |<-------- LSP -----------| |<--- LSP -->|
|<----------------- DetNet MPLS --------------------->|Figure 2: A DetNet MPLS Network
So Figure 2 shows a hypothetical network that is DetNet MPLS-only 💜 It's made of DetNet-aware, MPLS-enabled end systems sitting on top of a DetNet-aware MPLS network. The relay nodes are PE devices that mark where the MPLS LSP boundaries are, and the transit nodes are LSRs. Iconic layout, honestly 👑
DetNet end systems and relay nodes actually get what DetNet flows need 🫶 They handle both the DetNet service and forwarding sub-layer functions. With MPLS, DetNet service-aware nodes add, remove, and process d-CWs, S-Labels, and F-Labels as needed. DetNet MPLS nodes act like T-PEs when they're on the edge of an MPLS domain, and like S-PEs when they're in the middle of one. See [RFC6073] if you want the deets 🧚
Now, in a DetNet MPLS network, transit nodes can be either DetNet-service-aware or DetNet-unaware MPLS Label Switching Routers (LSRs). In that second case, those LSRs won't know about the special needs of the DetNet service sub-layer 🙈 but they can still do traffic engineering and provide the QoS capabilities needed so the (TE) LSPs meet what the carried DetNet flows need. Still serving, just differently 💅
The DetNet-over-MPLS approach supports a bunch of control and management plane types, and those types back up certain MPLS data plane deployments. For example, RSVP-TE, MPLS-TP, or MPLS Segment Routing (when extended to support resource allocation) are all valid MPLS deployment cases. Lots of options, all valid, no drama 🌈
Figure 3 zooms in on how an end-to-end MPLS-based DetNet service actually works 🎀 Here the Customer Edge (CE1 and CE2) can send and receive MPLS-encapsulated DetNet flows, and R1, R2, and R3 are relay nodes sitting in the middle of a DetNet network. The 'X' marks potential DetNet compound flow packet replication and elimination points in the end systems and relay nodes. In this example, service protection uses at least two DetNet member flows and TE LSPs 🔥 For a unidirectional flow, R1 supports PRF, and R3 supports PEF and POF. Also, relay nodes may change the underlying forwarding sub-layer, for example by tunneling MPLS over IEEE 802.1 TSN [DetNet-MPLS-over-TSN] or just over interconnected network links. Flexible queen 👑
DetNet DetNet
DetNet Service Transit Transit Service DetNet
MPLS | |<-Tnl->| |<-Tnl->| | MPLS
End | V 1 V V 2 V | End
System | +--------+ +--------+ +--------+ | System
+---+ | | R1 |=======| R2 |=======| R3 | | +---+
| X...DFa...|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|.DFa..|.X |
|CE1|========| \ | | X | | / |======|CE2|
| | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | |
+---+ | |=======| |=======| | +---+
^ +--------+ +--------+ +--------+ ^
| Relay Node Relay Node Relay Node |
| (S-PE) (S-PE) (S-PE) |
| |
|<---------------------- DetNet MPLS --------------------->|
| |
|<--------------- End-to-End DetNet Service -------------->|
-------------------------- Data Flow ------------------------->Figure 3: MPLS-Based Native DetNet
X - Optional service protection (none, PRF, PREOF, PEF/POF)
DFx - DetNet member flow x over a TE LSP4. MPLS-Based DetNet Data Plane Solution 🎀
4.1. DetNet over MPLS Encapsulation Components 💅
Okay, so to carry DetNet over MPLS, the following is required:
- A method of identifying the MPLS payload type.
- A method of identifying the DetNet flow(s) to the processing element.
- A method of distinguishing DetNet OAM packets from DetNet data packets.
- A method of carrying the DetNet sequence number.
- A suitable LSP to deliver the packet to the egress PE.
- A method of carrying queuing and forwarding indication.
In this design, an MPLS service label (the S-Label) is kind of like a pseudowire (PW) label [RFC3985] 🧚 and it's used to identify both the DetNet flow identity and the MPLS payload type, which covers (1) and (2) in that list above. OAM traffic gets told apart using the Associated Channel method described in [RFC4385]. The DetNet sequence number lives in the DetNet Control Word, and that same word also carries the Data/OAM discriminator 🌸 To keep implementation simple and maximize interoperability, two sequence number sizes are supported: a 16-bit sequence number and a 28-bit sequence number. The 16-bit one is there for some types of legacy clients. The 28-bit one is for situations where, in high-speed networks, the sequence number space needs to not wrap while packets are still in flight. Big brain move 🧠
The LSP used to forward the DetNet packet isn't restricted when it comes to how it gets established. It can be MPLS-LDP, MPLS-TE, MPLS-TP [RFC5921], MPLS Segment Routing [RFC8660], and so on 🦋 The F-Label(s) and the S-Label may be used alone or together to indicate the required queue processing as well as the forwarding parameters. And note that Penultimate Hop Popping (PHP) being possible means the S-Label might be the only label the terminating DetNet service receives 😭
4.2. MPLS Data Plane Encapsulation 🦋
Figure 4 shows a DetNet data plane MPLS encapsulation. This MPLS-based encapsulation of DetNet flows is well suited for the scenarios described in [RFC8938] 💖 Also, end-to-end DetNet service (native DetNet deployment, see Section 3.2) is possible too, as long as DetNet end systems can start and end MPLS-encapsulated packets.
Here's what the MPLS-based DetNet data plane encapsulation is made of:
- A DetNet Control Word (d-CW) containing sequencing information for packet replication and duplicate elimination purposes, and the OAM indicator.
- A DetNet service label (S-Label) that identifies a DetNet flow at the receiving DetNet service sub-layer processing node.
- Zero or more DetNet MPLS forwarding label(s) (F-Label) used to direct the packet along the Label Switched Path (LSP) to the next DetNet service sub-layer processing node along the path. When PHP is in use, there may be no F-Label in the protocol stack on the final hop.
- The necessary data-link encapsulation is then applied prior to transmission over the physical media.
DetNet MPLS-based encapsulation
+---------------------------------+
| |
| DetNet App-Flow |
| Payload Packet |
| |
+---------------------------------+ <--\
| DetNet Control Word | |
+---------------------------------+ +--> DetNet data plane
| S-Label | | MPLS encapsulation
+---------------------------------+ |
| [ F-Label(s) ] | |
+---------------------------------+ <--/
| Data-Link |
+---------------------------------+
| Physical |
+---------------------------------+Figure 4: Encapsulation of a DetNet App-Flow in an MPLS PSN
4.2.1. DetNet Control Word and DetNet Sequence Number 🌸
Alright, the DetNet Control Word (d-CW) follows the Generic PW MPLS Control Word (PWMCW) defined in [RFC4385]. The d-CW has to be formatted like Figure 5, and it MUST be present in all DetNet packets containing App-flow data 🎀 This format was made for two reasons: (1) to allow a bigger sequence number space, so the sequence number doesn't roll over as often in some applications, and (2) to let sequence numbering systems treat zero as a valid sequence number, which makes implementation simpler 🫶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: DetNet Control Word
- bits 0 to 3: Per [RFC4385], MUST be set to zero (0). 🙅
- Sequence Number (bits 4 to 31): An unsigned value implementing the DetNet sequence number. The sequence number space is a circular one with no restriction on the initial value. 🔄
A separate sequence number space MUST be maintained by the node that adds the d-CW for each DetNet App-flow, i.e., DetNet service. The following Sequence Number field lengths MUST be supported:
- 0 bits
- 16 bits
- 28 bits
The sequence number length MUST be provisioned on a per-DetNet-service basis via configuration, i.e., via the Controller Plane described in [RFC8938] 🧚
A 0-bit Sequence Number field length means there's no DetNet sequence number used for the flow. When the length is zero, the Sequence Number field MUST be set to zero (0) on all packets sent for the flow 🙈
When the Sequence Number field length is 16 or 28 bits for a flow, the sequence number MUST be incremented by one for each new App-flow packet sent. When the field length is 16 bits, d-CW bits 4 to 15 MUST be set to zero (0). The values can wrap, and it's important to remember that zero (0) is a valid field value 💜 For example, when the sequence number size is 16 bits, the sequence will contain: 65535, 0, 1, where zero (0) is an ordinary sequence number ✨
It's super important to note that this document differs from [RFC4448], where a sequence number of zero (0) is used to indicate that the sequence number check algorithm is not used. Don't mix them up, bestie 😭
The sequence number is optionally used during receive processing, as described below in Sections 4.2.2.2 and 4.2.2.3. 🌈
4.2.2. S-Labels ✨
okay bestie, so a DetNet flow at the service sub-layer gets its identity from an S-Label 🏷️ MPLS-aware DetNet end systems and edge nodes are, by definition, the MPLS ingress and egress nodes 👑, and they MUST add (push) and remove (pop) a DetNet service-specific d-CW and S-Label. relay nodes MAY swap S-Label values while they process a flow, so the incoming and outgoing S-Labels of one DetNet flow can be totally different 🦋
S-Label values MUST be provisioned per DetNet service through configuration, i.e., through the Controller Plane described in [RFC8938] 🎀 the tea is that S-Labels identify things at the downstream DetNet service sub-layer receiver, not the sender. so an S-Label MUST be allocated by the entity that controls the service sub-layer receiving a node's label space, and it MAY be allocated from the platform label space [RFC3031]. S-Labels are local to each node instead of being a global ID across the domain, so they must be advertised to their upstream DetNet service-aware peers (a DetNet MPLS end system, or a DetNet relay or edge node) and interpreted alongside their received F-Label(s) 💜 in some PREOF topologies, the node doing replication sends to several nodes doing PEF or POF, and it may need to send different S-Label values for the different member flows of the same DetNet service. that's a whole vibe 💅
An S-Label will normally sit at the bottom of the label stack once the last F-Label is removed, right before the d-CW 🌸 for OAM at the service sub-layer level, an OAM Associated Channel Header (ACH) [RFC4385] together with a Generic Associated Channel Label (GAL) [RFC5586] MAY be used in place of a d-CW ✨
Same energy with an Entropy Label Indicator (ELI) and Entropy Label (EL) [RFC6790] 🧚 they MAY be carried below the S-Label in networks where DetNet flows would otherwise get ECMP treatment. when ELs are used, the same EL value SHOULD be used for all of the packets sent using a specific S-Label, so the flow sticks to the same path. but, as outlined in [RFC8938], using ECMP for DetNet flows is NOT RECOMMENDED 🙈 ECMP MAY be used for non-DetNet flows within a DetNet domain, though 🍓
When receiving a DetNet MPLS packet, an implementation MUST identify the DetNet service associated with the incoming packet based on the S-Label. if a node is using platform labels for S-Labels, no extra info is needed, because the S-Label alone uniquely identifies the service 🔥 if platform labels aren't used, zero or more F-Labels proceeding the S-Label MUST be used together with the S-Label to uniquely identify the DetNet service for a received packet. the incoming interface MAY also be used together with any present F-Label(s) and the S-Label to uniquely identify an incoming DetNet service, for example where PHP is used 🦋 choosing the platform label space for an S-Label, or an S-Label plus one or more F-Labels, is a local implementation choice, with one caveat 🫶 when one or more F-Labels, or the incoming interface, is needed together with an S-Label to uniquely identify a service, the Controller Plane must ensure that incoming DetNet MPLS packets arrive with the needed information (F-Label(s) and/or the incoming interface) and provision that information. the provisioned information MUST then be used to identify the incoming DetNet service based on the combination of S-Label and F-Label(s) or the incoming interface 👑
using platform labels for S-Labels matches other pseudowire encapsulations for consistency, but there is no hard requirement about it 🌈 and implementation details of PREOF are out of scope for this document. [IEEE802.1CB-2017] defines equivalent replication and elimination-specific aspects, which can be applied to PRF and PEF 💖
4.2.2.1. Packet Replication Function Processing
the Packet Replication Function (PRF) MAY be supported by an implementation for outgoing DetNet flows 🍓 the use of PRF for a particular DetNet service MUST be provisioned through configuration, i.e., through the Controller Plane described in [RFC8938]. when replication is configured, the same App-flow data gets sent over multiple outgoing DetNet member flows using forwarding sub-layer LSPs 🌸 an S-Label value MUST be configured for each outgoing member flow, and the same d-CW field value MUST be used on all outgoing member flows for each replicated MPLS packet 💅
4.2.2.2. Packet Elimination Function Processing
implementations MAY support the Packet Elimination Function (PEF) for received DetNet MPLS flows 🦋 when supported, use of PEF for a particular DetNet service MUST be provisioned through configuration, i.e., through the Controller Plane described in [RFC8938].
once a DetNet service is identified for a received DetNet MPLS packet (see above), if PEF is configured for that service, duplicate (replicated) instances of a particular sequence number MUST be discarded 😭 how an implementation tells which packets are duplicates and which are new is an implementation choice. also, per Section 4.2.1, the Sequence Number field length may be 16 or 28 bits, and the field value can wrap around. PEF MUST NOT be used with DetNet flows configured with a d-CW Sequence Number field length of 0 bits 💀
an implementation MAY constrain the maximum number of sequence numbers it tracks, either platform-wide or per flow ✨ some implementations MAY support provisioning that maximum number of tracked sequence numbers, platform-wide or per flow 🧚
4.2.2.3. Packet Ordering Function Processing
a function related to in-order delivery is the Packet Ordering Function (POF) 🌷 implementations MAY support POF. when supported, use of POF for a particular DetNet service MUST be provisioned through configuration, i.e., through the Controller Plane described by [RFC8938]. implementations MAY require that PEF and POF be used in combination, and there is no requirement about the order in which PEF and POF execute in an implementation 💜
once a DetNet service is identified for a received DetNet MPLS packet (see above), if POF is configured for that service, packets MUST be processed in the order indicated in the received d-CW Sequence Number field, which may not match the order the packets arrived in 🎀 per Section 4.2.1, the Sequence Number field length may be 16 or 28 bits. the sequence number goes up by one (1) for each new MPLS packet sent for a particular DetNet service, and the field value can wrap. how an implementation identifies the order of received packets is an implementation choice 🌈
an implementation MAY constrain the maximum number of out-of-order packets it can process, either platform-wide or per flow. the number of out-of-order packets that can be processed also affects the latency of a flow ⏰ the latency impact on the system resources needed for a specific DetNet flow will need to be evaluated by the Controller Plane based on that flow's traffic specification. an example traffic specification usable with MPLS-TE is in [RFC2212] 📜
DetNet implementations can use flow-specific requirements (like the maximum number of out-of-order packets and the maximum latency of the flow) to configure POF-related buffers 🫧 POF implementation details are out of scope for this document, and POF configuration parameters are implementation specific. the Controller Plane identifies and sets those POF configuration parameters 👑
4.2.3. F-Labels 🦋
F-Labels are the ones holding up the DetNet forwarding sub-layer 💖 they provide LSP-based connectivity between DetNet service sub-layer processing nodes, so the nodes can talk to each other properly 🫶
4.2.3.1. Service Sub-Layer-Related Processing
DetNet MPLS end systems, edge nodes, and relay nodes may operate at the DetNet service sub-layer with an understanding of DetNet services and their requirements 🧚 as mentioned earlier, when they work at this layer, these nodes can push, pop, or swap (pop then push) S-Labels. in every case, the F-Label(s) used for a DetNet service are always replaced, and the following procedures apply 🔥
when sending a DetNet flow, zero or more F-Labels MAY be pushed on top of an S-Label by the node pushing that S-Label 🌸 the F-Label(s) to be pushed when sending a particular DetNet service MUST be provisioned per outgoing S-Label through configuration, i.e., through the Controller Plane discussed in [RFC8938]. F-Label(s) can also provide context for an S-Label. to allow for omitting F-Label(s), an implementation SHOULD also allow an outgoing interface to be configured per S-Label 🍓
note that when PRF is supported, the same App-flow data gets sent over multiple outgoing DetNet member flows using forwarding sub-layer LSPs 💅 that means an implementation may be sending different sets of F-Labels per DetNet member flow, each with a different S-Label 🦋
when a single set of F-Labels is provisioned for a particular outgoing S-Label, that set MUST be pushed after the S-Label is pushed. the outgoing packet is then forwarded, as described below in Section 4.2.3.2. when a single outgoing interface is provisioned, the outgoing packet is then forwarded as described below in Section 4.2.3.2 too 🌈
when multiple sets of outgoing F-Labels or interfaces are provisioned for a particular DetNet service (i.e., for PRF), a copy of the outgoing packet, including the pushed member flow-specific S-Label, MUST be made per F-Label set and outgoing interface. each set of provisioned F-Labels then gets pushed onto a copy of the packet, and each copy is forwarded as described below in Section 4.2.3.2 ✨
as described in the previous section, when receiving a DetNet MPLS flow, an implementation identifies the DetNet service associated with the incoming packet based on the S-Label. when a node is using platform labels for S-Labels, any F-Labels can be popped, and the S-Label uniquely identifies the DetNet service 👑 in the case where platform labels are not used, incoming F-Label(s) and, optionally, the incoming interface MUST also be provisioned for a DetNet service 🫶
4.2.3.2. Common F-Label Processing ✨
Okay bestie, every DetNet-aware MPLS node handles F-Labels whenever it needs to, so the DetNet flow (or flows) riding inside the LSPs behind those labels get the service they were promised 💅. That means the usual push, pop, and swap ops. It's basically the same stuff we already do for TE LSPs, just with different service parameters or traffic specs 🎀. If an existing TE mechanism can already meet the DetNet service parameters, the forwarding sub-layer processing node MAY be a DetNet-unaware (aka standard) MPLS LSR 🦋. Those TE LSPs can provide LSP forwarding service as defined in, but not limited to, [RFC3209], [RFC3270], [RFC3272], [RFC3473], [RFC4875], [RFC5440], and [RFC8306] 🌸.
Next up, the DetNet forwarding sub-layer gives you explicit routes and allocated resources, and F-Labels are how you map to each one 🗺️. Explicit routes are supported based on the topmost (outermost) F-Label that gets pushed or swapped, plus the LSP that label points to. This topmost (outgoing) label MUST be associated with a provisioned outgoing interface and, for non-point-to-point outgoing interfaces, a next-hop LSR. Note that this information MUST be provisioned via configuration or the Controller Plane. In the special case I mentioned earlier, where there are no added F-Labels and the outgoing interface is not point-to-point, the outgoing interface MUST also be associated with a next-hop LSR. Bestie, do not skip this 😭.
Resources can be allocated in a hierarchical way for each LSP represented by each F-Label 🧚. Each LSP MAY be provisioned with a service parameter that dictates the specific traffic treatment the traffic on that LSP gets. Implementations of this document MUST ensure that traffic carried over each LSP represented by one or more F-Labels receives the traffic treatment provisioned for that LSP. Typical mechanisms for giving different treatment to different flows include allocating system resources (like queues and buffers) and provisioning related parameters (like shaping and policing). You'll find these in implementations of the Resource ReSerVation Protocol (RSVP) [RFC2205] and RSVP-TE [RFC3209] [RFC3473] 💜. Support can also come from an underlying network technology, such as IEEE 802.1 TSN [DetNet-MPLS-over-TSN]. The specific mechanisms a DetNet node picks to make sure DetNet service delivery requirements are met for supported DetNet flows are outside the scope of this document 🙈.
Now, packets that are marked in a way that doesn't match any allocated resources (like ones missing a provisioned F-Label) can totally wreck the QoS of properly reserved DetNet flows by stealing the resources allocated to them 💀. So the network nodes of a DetNet network:
- MUST defend the DetNet QoS by discarding or remarking (to an allocated DetNet flow or noncompeting non-DetNet flow) packets received that are not associated with a completed resource allocation. 🛡️
- MUST NOT use a DetNet allocated resource, e.g., a queue or shaper reserved for DetNet flows, for any packet that does match the corresponding DetNet flow. 🚫
- MUST ensure a QoS flow does not exceed its allocated resources or provisioned service level. 📏
- MUST ensure a CoS flow or service class does not impact the service delivered to other flows. This requirement is similar to the requirement for MPLS LSRs that CoS LSPs do not impact the resources allocated to TE LSPs, e.g., via [RFC3473]. 🫶
Subsequent sections give you more details on CoS (Section 4.6.1), QoS (Section 4.6.2), and aggregation (Section 4.4) 👑.
4.3. OAM Indication 🔍
OAM follows the procedures set out in [RFC5085], with the restriction that only Virtual Circuit Connectivity Verification (VCCV) type 1 is supported 💅.
As shown in Figure 3 of [RFC5085], when the first nibble of the d-CW is 0x0, the payload following the d-CW is normal user data. But when the first nibble of the d-CW is 0x1, the payload following the d-CW is an OAM payload, and the OAM type is indicated by the value in the d-CW Channel Type field 🦋.
If you want the full scoop on the Associated Channel mechanism, check out [RFC5085]. For more info on DetNet OAM, look at the DetNet work on OAM [DetNet-MPLS-OAM] ✨.
Additional considerations on DetNet-specific OAM are subjects for further study 🌈.
4.4. Flow Aggregation 🧩
Being able to aggregate individual flows and their associated resource control into a bigger aggregate is a major technique for scaling control in the data, management, and control planes 🔥. The DetNet data plane allows aggregation of DetNet flows to improve scaling. There are two methods of supporting flow aggregation, and both are covered in this section 💖.
The resource control and management side of aggregation (including configuring queuing, shaping, and policing) is the responsibility of the DetNet Controller Plane and is out of scope for this document 🎀. It's also the Controller Plane's job to make sure consistent aggregation methods are used 🫶.
4.4.1. Aggregation via LSP Hierarchy 🪜
DetNet flows forwarded via MPLS can use MPLS-TE's existing support for hierarchical LSPs (H-LSPs); see [RFC4206] 🌸. H-LSPs are typically used to aggregate control and resources, and they may also be used to provide OAM or protection for the aggregated LSPs. Arbitrary levels of aggregation naturally fall out of the definition of hierarchy and the MPLS label stack [RFC3032], which is so neat 😍. DetNet nodes that support aggregation (LSP hierarchy) map one or more LSPs (labels) into and out of an H-LSP. Both carried LSPs and H-LSPs may or may not use the Traffic Class (TC) field. That means they can be L-LSPs (Label-Only-Inferred-PSC LSPs) or E-LSPs (EXP-Inferred-PSC LSPs [RFC3270], which were renamed to "Explicitly TC-encoded-PSC LSPs" in Section 2.2 of [RFC5462]) 🌈. Nodes like these will need to make sure individual LSPs and H-LSPs get the traffic treatment required to keep the required DetNet service preserved 💅.
More details on the traffic control capabilities a DetNet-aware node needs may be covered in the new service definitions mentioned above, or in separate future documents 📚. Controller Plane mechanisms will also need to make sure the service required on the aggregate flow is provided, which may include the discarding or remarking mentioned in the previous sections 🛡️.
4.4.2. Aggregating DetNet Flows as a New DetNet Flow 🧁
An aggregate can be built by layering DetNet flows, including both their S-Label and (when present) F-Labels, as shown below 🎂:
+---------------------------------+
| |
| DetNet Flow |
| Payload Packet |
| |
+---------------------------------+ <--\
| DetNet Control Word | |
+=================================+ |
| S-Label | |
+---------------------------------+ |
| [ F-Label(s) ] | +----DetNet data plane
+---------------------------------+ |
| DetNet Control Word | |
+=================================+ |
| A-Label | |
+---------------------------------+ |
| F-Label(s) | <--/
+---------------------------------+
| Data-Link |
+---------------------------------+
| Physical |
+---------------------------------+
Figure 6: DetNet Aggregation as a New DetNet FlowBoth the aggregation label, which is called an A-Label, and the individual flow's S-Label have their MPLS S bit set to indicate the bottom of the stack, and the d-CW lets the PREOF work 🙌. An A-Label is a special case of an S-Label, and its properties are only known at the aggregation and deaggregation end points 🕵️♀️.
It's a property of the A-Label that what follows is a d-CW followed by an MPLS label stack. A relay node processing the A-Label wouldn't know the underlying payload type, so the A-Label gets processed like a normal S-Label. Only a node that's a peer of the node imposing the S-Label would know this. But honestly there's no real need for it to know the payload type during aggregation processing, so it's fine 💁♀️.
Same as the last section, nodes that support this type of aggregation will need to make sure individual and aggregated flows get the traffic treatment required to keep the required DetNet service preserved 💜. Also, it's the Controller Plane's responsibility to make sure the service required on the aggregate flow is properly provisioned 👑.
4.5. Service Sub-Layer Considerations 🎀
The internal procedures for edge and relay nodes related to PREOF are implementation specific. The order of a packet elimination or replication is out of scope for this specification 🌸.
It's really important that the DetNet layer is configured so a DetNet node never receives its own replicated packets 🚨. If it did, the replication function would make the loop way more destructive to bandwidth than a conventional unicast loop would be. The TTL in the S-Label will eventually kill the packet during a transient loop, but given how sensitive applications are to packet latency, the impact on the DetNet application would be severe 😭. To avoid a transient forwarding loop, changes to an LSP supporting DetNet MUST be loop-free 🔁.
4.5.1. Edge Node Processing 🚪
A DetNet edge node operates in the DetNet forwarding sub-layer and the service sub-layer 🧚♀️. An edge node is responsible for matching incoming packets to the service they need and encapsulating them accordingly. An edge node may perform PRF, PEF, and/or POF. For details on encapsulation, see Section 4.2. For PRF, see Section 4.2.2.1. For PEF, see Section 4.2.2.2. And for POF, see Section 4.2.2.3 💖.
4.5.2. Relay Node Processing 🦋
okay so a DetNet relay node lives in two layers at once: the DetNet forwarding sub-layer AND the service sub-layer 💅. For DetNet over MPLS, the forwarding-related processing happens on the F-Label, and it's done inside an extended forwarder function ✨. Whether an incoming DetNet flow gets DetNet-specific processing totally depends on how the forwarding has been programmed 🎀. Some relay nodes are DetNet service aware for certain services, but for other services they can act like plain unmodified LSRs that only know how to switch MPLS-TE LSPs. That's basically a transit node, see Section 4.4 🌸. Again, it's all about how the forwarding was set up, bestie 🫶.
During elimination and replication, the sequence number of an incoming DetNet packet MUST be preserved and carried in the matching outgoing DetNet packet 🔥. Here's an example: a relay node doing both PEF and PRF runs PEF first on the incoming packets to make a compound flow. Then it runs PRF and copies the App-flow data and the d-CW into the packets for each outgoing DetNet member flow 💖.
The internal design of a relay node is out of scope for this document 🙈. BUT, the reader should definitely notice that any PREOF state has to be available to the packet processor(s) handling packets that need PREOF applied 👀. That state also has to stay around so it's available for the next packet in the DetNet flow, which could be a duplicate, a late packet, or just the next packet in sequence. Main character memory energy 🧠✨.
4.6. Forwarding Sub-Layer Considerations 🌈
4.6.1. Class of Service 💜
okay so CoS and QoS get used like they mean the same thing and it's honestly so confusing 😭. In DetNet land, CoS means mechanisms that give traffic forwarding treatment based on NON-flow-specific traffic classification, and QoS means mechanisms that give forwarding treatment based on DetNet flow-specific traffic classification 🎀. Examples of network-level CoS mechanisms that already exist include Differentiated Services (Diffserv), which is enabled by the IP header Differentiated Services Code Point (DSCP) field [RFC2474] and the MPLS label Traffic Class field [RFC5462], and at Layer 2 by the IEEE 802.1p Priority Code Point (PCP) 🦋.
CoS for DetNet flows carried in PWs and MPLS is provided using the existing MPLS Differentiated Services (Diffserv) architecture [RFC3270] 💅. Both E-LSP and L-LSP MPLS Diffserv modes MAY be used to support DetNet flows ✨. The Traffic Class field (formerly the EXP field) of an MPLS label follows the definition in [RFC5462] and [RFC3270] 🌸. The Uniform, Pipe, and Short Pipe Diffserv tunneling and TTL processing models are described in [RFC3270] and [RFC3443], and they MAY be used for MPLS LSPs supporting DetNet flows 🫶. MPLS Explicit Congestion Notification (ECN) MAY also be used, as defined in ECN [RFC5129] and updated by [RFC5462] 💜.
4.6.2. Quality of Service 👑
so besides explicit routes and packet replication and elimination (Section 4 above), DetNet also gives you zero congestion loss and bounded latency and jitter 🔥. As [RFC8655] explains, there are different mechanisms that can be used separately or combined to deliver a zero congestion loss service 💖. That includes QoS mechanisms at the MPLS layer, which can be combined with mechanisms from the underlying network layer, like IEEE 802.1 TSN 🧚.
QoS mechanisms for flow-specific traffic treatment usually come with a guarantee/agreement for the service and an allocation of resources to support it ✨. Example QoS mechanisms are discrete resource allocation, admission control, flow identification and isolation, and sometimes path control, traffic protection, shaping, policing, and remarking 💅. Example protocols that support QoS control include the Resource ReSerVation Protocol (RSVP) [RFC2205] and RSVP-TE [RFC3209] [RFC3473] 🎀. The existing MPLS mechanisms defined to support CoS [RFC3270] can also be used to reserve resources for specific traffic classes 🌈.
A baseline set of QoS capabilities for DetNet flows carried in PWs and MPLS can be provided by MPLS-TE [RFC3209] [RFC3473] 🦋. TE LSPs can also support explicit routes (path pinning) 📍. Current service definitions for packet TE LSPs can be found in "Specification of the Controlled-Load Network Element Service" [RFC2211], "Specification of Guaranteed Quality of Service" [RFC2212], and "Ethernet Traffic Parameters" [RFC6003] 🌸. Additional service definitions are expected in future documents to support the full range of DetNet services 🔮. In all cases, the existing label-based marking mechanisms defined for TE LSPs and even E-LSPs are used to support identifying flows that need DetNet QoS 💖✨.
5. Management and Control Information Summary 🎀
okay so the specific info needed to process each DetNet service depends on the DetNet node type and what functions that node is providing 🧠. This section sums that up based on the DetNet sub-layer and on whether the DetNet traffic is being sent or received 💅. ALL DetNet node types are DetNet forwarding sub-layer aware, while everything except transit nodes is also service sub-layer aware 🌸. This is shown in Figure 2 ✨.
Much like other MPLS labels, there are a bunch of options for advertising DetNet S-Labels and F-Labels to an upstream peer node 🦋. These include distributed signaling protocols (like RSVP-TE), centralized label distribution via a controller that manages both the sender and the receiver using the Network Configuration Protocol (NETCONF) and YANG, BGP, the Path Computation Element Communication Protocol (PCEP), etc., plus hybrid combos of the two 🫶. The details of the Controller Plane solution needed for label distribution and for managing the label number space are out of scope for this document 🙈. Specific DetNet considerations and requirements are discussed in [RFC8938] 📚. Conformance language isn't used in this summary, since it applies to future mechanisms, like the ones that may show up in signaling and YANG models, e.g., [DetNet-YANG] 💜.
5.1. Service Sub-Layer Information Summary 🌈
here's what's needed (per service) on nodes that are service sub-layer aware and TRANSMIT DetNet MPLS traffic 📤:
- App-flow identification information, e.g., IP information as defined in [DetNet-IP-over-MPLS] 🎀. Note that this information is not needed on DetNet relay nodes 🙅♀️.
- The sequence number length to be used for the service. Valid values include 0, 16, and 28 bits. 0 bits cannot be used when PEF or POF is configured for the service 🔢.
- If PRF is to be provided for the service 🦋.
- The outgoing S-Label for each of the service's outgoing DetNet (member) flows 🏷️.
- The forwarding sub-layer information associated with the output of the service sub-layer. Note that when PRF is provisioned, this information is per DetNet member flow. Logically, the forwarding sub-layer information is a pointer to further details of transmission of DetNet flows at the forwarding sub-layer 🌸.
here's what's needed (per service) on nodes that are service sub-layer aware and RECEIVE DetNet MPLS traffic 📥:
- The forwarding sub-layer information associated with the input of the service sub-layer. Note that when PEF is provisioned, this information is per DetNet member flow. Logically, the forwarding sub-layer information is a pointer to further details of the reception of DetNet flows at the forwarding sub-layer or A-Label 💖.
- The incoming S-Label for the service 🏷️.
- If PEF or POF is to be provided for the service ✨.
- The sequence number length to be used for the service. Valid values included 0, 16, and 28 bits. 0 bits cannot be used when PEF or POF are configured for the service 🔢.
- App-flow identification information, e.g., IP information as defined in [DetNet-IP-over-MPLS]. Note that this information is not needed on DetNet relay nodes 🙅♀️.
5.1.1. Service Aggregation Information Summary 🫧
nodes doing aggregation with A-Labels (per Section 4.4.2) need the extra info summarized in this section 🧩.
here's the additional info needed on a node that SENDS aggregated flows using A-Labels 📤:
- The S-Labels or F-Labels that are to be carried over each aggregated service.
- The A-Label associated with each aggregated service.
- The other S-Label information summarized above.
On the receiving node, the A-Label gives the forwarding context of an incoming interface or an F-Label, and it's used in later service or forwarding sub-layer receive processing, as appropriate 📥. Any related extra configuration is discussed elsewhere in this section 💜.
5.2. Forwarding Sub-Layer Information Summary 🌷
here's what's needed (per forwarding-sub-layer flow) on nodes that are forwarding sub-layer aware and SEND DetNet MPLS traffic 📤:
- The outgoing F-Label stack to be pushed. The stack may include H-LSP labels 🏷️.
- The traffic parameters associated with a specific label in the stack. Note that there may be multiple sets of traffic parameters associated with specific labels in the stack, e.g., when H-LSPs are used 📊.
- Outgoing interface and, for unicast traffic, the next-hop information 🛣️.
- Sub-network-specific parameters on a technology-specific basis. For example, see [DetNet-MPLS-over-TSN] 🌐.
here's what's needed (per forwarding-sub-layer flow) on nodes that are forwarding sub-layer aware and RECEIVE DetNet MPLS traffic 📥:
- The incoming interface. For some implementations and deployment scenarios, this information may not be needed 🙃.
- The incoming F-Label stack to be popped. The stack may include H-LSP labels 🏷️.
- How the incoming forwarding sub-layer flow is to be handled, i.e., forwarded as a transit node or provided to the service sub-layer 🔀.
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 each flow's service requirements call for 👑. This applies to aggregated and individual flows alike 🫶✨.
6. Security Considerations 🔐✨
Okay bestie, security time 😭🔒 The detailed DetNet security stuff is all cataloged in [DetNet-Security], and the general security vibes are in [RFC8655]. This section only covers the security stuff that's specific to the DetNet MPLS data plane 💅. The MPLS concerns for networks in general from [RFC5920] apply to the DetNet MPLS data plane too, no cap.
The unique DetNet security goal is protecting the special QoS promises DetNet makes, which are mainly delivering data flows with extremely low packet loss and bounded end-to-end delivery latency 🦋. Honestly, those guarantees may not be possible against a highly capable adversary, like the one in the Internet Threat Model of BCP 72 [RFC3552], who can arbitrarily drop or delay any or all traffic 💀. So to make these security considerations meaningful, we look at a somewhat weaker attacker. This attacker doesn't control the physical links of the DetNet domain, but may have the ability to control a network node inside the DetNet domain boundary 🙈.
Another DetNet data plane goal is keeping data integrity and making sure the DetNet service still gets delivered as it crosses the network 🫶. Application flows can be protected by whatever the underlying technology provides. For example, encryption may be used, like the kind IPsec [RFC4301] gives IP flows, and/or an underlying sub-network using MACsec [IEEE802.1AE-2018] for IP over Ethernet (Layer 2) flows 🔐. MPLS doesn't provide any native security services for confidentiality and integrity, so it's giving "bring your own protection" 🙃.
From a data plane perspective, this document doesn't add or modify any application header information 🌸.
At the management and control level, DetNet flows are identified on a per-flow basis 👀. That may give Controller Plane attackers extra information about the data flows, compared to Controller Planes that don't include per-flow identification. This is an inherent property of DetNet with security implications, so think it through when you're deciding if DetNet is a good fit for your use case 🧐.
To keep the DetNet service uninterrupted, provisions can be made against DoS attacks and delay attacks 🛡️. To protect against DoS attacks, excess traffic from malicious or malfunctioning devices is prevented or mitigated with existing mechanisms, like policing and shaping incoming traffic 🚧. To stop DetNet packets from having their delay manipulated by an external entity, precautions need to be taken to make sure all devices on an LSP are the ones the network operator intended to be there, and that they're well behaved 👑. Besides physical security, technical methods like authentication and authorization of network equipment, plus instrumentation and monitoring of LSP packet delay, may be used ✅. If a delay attack is suspected, traffic may be moved to an alternate path, for example by changing the LSP or managing the PREOF configuration 🏃♀️.
Heads up, bestie: if you suspect a delay attack, don't just sit there. Reroute the traffic 🚨
7. IANA Considerations 🌈
Quick one: this document has no IANA actions 🎀 Nothing to register here, bestie 💅.
8. References ✨
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, DOI 10.17487/RFC2211,
September 1997, <https://www.rfc-editor.org/info/rfc2211>.
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification
of Guaranteed Quality of Service", RFC 2212,
DOI 10.17487/RFC2212, September 1997,
<https://www.rfc-editor.org/info/rfc2212>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, DOI 10.17487/RFC3270, May 2002,
<https://www.rfc-editor.org/info/rfc3270>.
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
in Multi-Protocol Label Switching (MPLS) Networks",
RFC 3443, DOI 10.17487/RFC3443, January 2003,
<https://www.rfc-editor.org/info/rfc3443>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206,
DOI 10.17487/RFC4206, October 2005,
<https://www.rfc-editor.org/info/rfc4206>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
Circuit Connectivity Verification (VCCV): A Control
Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
December 2007, <https://www.rfc-editor.org/info/rfc5085>.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
2008, <https://www.rfc-editor.org/info/rfc5129>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/info/rfc5586>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane
Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
<https://www.rfc-editor.org/info/rfc8938>.8.2. Informative References ✨
Okay bestie, this is the reference list for the stuff the doc leans on but doesn't require 💅 Every entry keeps its exact details (authors, titles, numbers, dates, and links), so you can track down anything you need 🔍
[DetNet-IP-over-MPLS] Varga, B., Ed., Berger, L., Fedyk, D., Bryant, S., and J. Korhonen, "DetNet Data Plane: IP over MPLS", Work in Progress, Internet-Draft, draft-ietf-detnet-ip-over-mpls- 09, 11 October 2020, <https://tools.ietf.org/html/draft- ietf-detnet-ip-over-mpls-09>.
[DetNet-MPLS-OAM] Mirsky, G. and M. Chen, "Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with MPLS Data Plane", Work in Progress, Internet-Draft, draft- ietf-detnet-mpls-oam-02, 15 January 2021, <https://tools.ietf.org/html/draft-ietf-detnet-mpls-oam- 02>.
[DetNet-MPLS-over-TSN] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, "DetNet Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking (TSN)", Work in Progress, Internet-Draft, draft-ietf-detnet-mpls-over-tsn-05, 13 December 2020, <https://tools.ietf.org/html/draft-ietf-detnet-mpls-over- tsn-05>.
[DetNet-Security] Grossman, E., Ed., Mizrahi, T., and A. Hacker, "Deterministic Networking (DetNet) Security Considerations", Work in Progress, Internet-Draft, draft- ietf-detnet-security-13, 11 December 2020, <https://tools.ietf.org/html/draft-ietf-detnet-security- 13>.
[DetNet-YANG] Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Rahman, R., and Z. Li, "Deterministic Networking (DetNet) Configuration YANG Model", Work in Progress, Internet-Draft, draft-ietf- detnet-yang-09, 16 November 2020, <https://tools.ietf.org/html/draft-ietf-detnet-yang-09>.
[IEEE802.1AE-2018] IEEE, "IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security", IEEE 802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December 2018, <https://ieeexplore.ieee.org/document/8585421>.
[IEEE802.1CB-2017] IEEE, "IEEE Standard for Local and metropolitan area networks-- Frame Replication and Elimination for Reliability", IEEE 802.1CB-2017, DOI 10.1109/IEEESTD.2017.8091139, October 2017, <https://ieeexplore.ieee.org/document/8091139>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, <https://www.rfc-editor.org/info/rfc3272>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <https://www.rfc-editor.org/info/rfc3985>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, <https://www.rfc-editor.org/info/rfc4448>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, <https://www.rfc-editor.org/info/rfc4875>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, <https://www.rfc-editor.org/info/rfc5921>.
[RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", RFC 6003, DOI 10.17487/RFC6003, October 2010, <https://www.rfc-editor.org/info/rfc6003>.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, DOI 10.17487/RFC6073, January 2011, <https://www.rfc-editor.org/info/rfc6073>.
[RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 8306, DOI 10.17487/RFC8306, November 2017, <https://www.rfc-editor.org/info/rfc8306>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>.
[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/info/rfc8939>.
Acknowledgements 🫶
The authors wanted to thank a whole squad of people for their contributions to this work: Pat Thaler, Norman Finn, Loa Anderson, David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig Gunther, George Swallow, Yuanlong Jiang, Jeong-dong Ryoo, and Carlos J. Bernardos. Iconic behaviour, honestly 👑
Contributors 🌸
The editor of this document wanted to shout out one person who contributed a lot to the content and should be considered a coauthor:
Don Fedyk LabN Consulting, L.L.C.
Email: dfedyk@labn.net
Authors' Addresses 🦋
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
Jouni Korhonen
Email: jouni.nospam@gmail.com
That's the whole doc, bestie!! 🧚💖 The authors are the real MVPs for putting all this together, and you're officially caught up on DetNet over MPLS 🎀✨
📦 where this page comes from
- ietf: rfc8964 2021-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms