draft-ietf-detnet-mpls-13.txt   rfc8964.txt 
DetNet B. Varga, Ed. Internet Engineering Task Force (IETF) B. Varga, Ed.
Internet-Draft J. Farkas Request for Comments: 8964 J. Farkas
Intended status: Standards Track Ericsson Category: Standards Track Ericsson
Expires: April 14, 2021 L. Berger ISSN: 2070-1721 L. Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
A. Malis A. Malis
Malis Consulting Malis Consulting
S. Bryant S. Bryant
Futurewei Technologies Futurewei Technologies
J. Korhonen J. Korhonen
October 11, 2020 January 2021
DetNet Data Plane: MPLS Deterministic Networking (DetNet) Data Plane: MPLS
draft-ietf-detnet-mpls-13
Abstract Abstract
This document specifies the Deterministic Networking data plane when This document specifies the Deterministic Networking (DetNet) data
operating over an MPLS Packet Switched Network. It leverages plane when operating over an MPLS Packet Switched Network. It
existing pseudowire (PW) encapsulations and MPLS Traffic Engineering leverages existing pseudowire (PW) encapsulations and MPLS Traffic
encapsulations and mechanisms. This document builds on the DetNet Engineering (MPLS-TE) encapsulations and mechanisms. This document
Architecture and Data Plane Framework. builds on the DetNet architecture and data plane framework.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on April 14, 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8964.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
2.1. Terms Used in This Document . . . . . . . . . . . . . . . 4 2.1. Terms Used in This Document
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Abbreviations
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.3. Requirements Language
3. DetNet MPLS Data Plane Overview . . . . . . . . . . . . . . . 5 3. Overview of the DetNet MPLS Data Plane
3.1. Layers of DetNet Data Plane . . . . . . . . . . . . . . . 5 3.1. Layers of DetNet Data Plane
3.2. DetNet MPLS Data Plane Scenarios . . . . . . . . . . . . 6 3.2. DetNet MPLS Data Plane Scenarios
4. MPLS-Based DetNet Data Plane Solution . . . . . . . . . . . . 8 4. MPLS-Based DetNet Data Plane Solution
4.1. DetNet Over MPLS Encapsulation Components . . . . . . . . 8 4.1. DetNet over MPLS Encapsulation Components
4.2. MPLS Data Plane Encapsulation . . . . . . . . . . . . . . 9 4.2. MPLS Data Plane Encapsulation
4.2.1. DetNet Control Word and the DetNet Sequence Number . 10 4.2.1. DetNet Control Word and DetNet Sequence Number
4.2.2. S-Labels . . . . . . . . . . . . . . . . . . . . . . 12 4.2.2. S-Labels
4.2.3. F-Labels . . . . . . . . . . . . . . . . . . . . . . 15 4.2.3. F-Labels
4.3. OAM Indication . . . . . . . . . . . . . . . . . . . . . 17 4.3. OAM Indication
4.4. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 18 4.4. Flow Aggregation
4.4.1. Aggregation Via LSP Hierarchy . . . . . . . . . . . . 18 4.4.1. Aggregation via LSP Hierarchy
4.4.2. Aggregating DetNet Flows as a new DetNet flow . . . . 19 4.4.2. Aggregating DetNet Flows as a New DetNet Flow
4.5. Service Sub-Layer Considerations . . . . . . . . . . . . 20 4.5. Service Sub-Layer Considerations
4.5.1. Edge Node Processing . . . . . . . . . . . . . . . . 20 4.5.1. Edge Node Processing
4.5.2. Relay Node Processing . . . . . . . . . . . . . . . . 20 4.5.2. Relay Node Processing
4.6. Forwarding Sub-Layer Considerations . . . . . . . . . . . 21 4.6. Forwarding Sub-Layer Considerations
4.6.1. Class of Service . . . . . . . . . . . . . . . . . . 21 4.6.1. Class of Service
4.6.2. Quality of Service . . . . . . . . . . . . . . . . . 21 4.6.2. Quality of Service
5. Management and Control Information Summary . . . . . . . . . 22 5. Management and Control Information Summary
5.1. Service Sub-Layer Information Summary . . . . . . . . . . 23 5.1. Service Sub-Layer Information Summary
5.1.1. Service Aggregation Information Summary . . . . . . . 24 5.1.1. Service Aggregation Information Summary
5.2. Forwarding Sub-Layer Information Summary . . . . . . . . 24 5.2. Forwarding Sub-Layer Information Summary
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 7. IANA Considerations
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 8. References
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 8.1. Normative References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.2. Informative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 27 Acknowledgements
10.2. Informative References . . . . . . . . . . . . . . . . . 29 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses
1. Introduction 1. Introduction
Deterministic Networking (DetNet) is a service that can be offered by Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows. DetNet provides a capability for the a network to DetNet flows. DetNet provides a capability for the
delivery of data flows with extremely low packet loss rates and delivery of data flows with extremely low packet loss rates and
bounded end-to-end delivery latency. General background and concepts bounded end-to-end delivery latency. General background and concepts
of DetNet can be found in the DetNet Architecture [RFC8655]. of DetNet can be found in the DetNet architecture [RFC8655].
The purpose of this document is to describe the use of the MPLS data The purpose of this document is to describe the use of the MPLS data
plane to establish and support DetNet flows. The DetNet Architecture plane to establish and support DetNet flows. The DetNet architecture
models the DetNet related data plane functions decomposed into two models the DetNet-related data plane functions as being decomposed
sub-layers: a service sub-layer and a forwarding sub-layer. The into two sub-layers: a service sub-layer and a forwarding sub-layer.
service sub-layer is used to provide DetNet service functions such as The service sub-layer is used to provide DetNet service functions,
protection and reordering. At the DetNet data plane a new set of such as protection and reordering. At the DetNet data plane, a new
functions (PREOF) provide the service sub-layer specific tasks. The set of functions (Packet Replication, Elimination and Ordering
forwarding sub-layer is used to provide forwarding assurance (low Functions (PREOF)) provide the tasks specific to the service sub-
loss, assured latency, and limited out-of-order delivery). The use layer. The forwarding sub-layer is used to provide forwarding
of the functionalities of the DetNet service sub-layer and the DetNet assurance (low loss, assured latency, and limited out-of-order
forwarding sub-layer require careful design and control by the delivery). The use of the functionalities of the DetNet service sub-
controller plane in addition to the DetNet specific use of MPLS layer and the DetNet forwarding sub-layer require careful design and
encapsulation as specified by this document. control by the Controller Plane in addition to the DetNet-specific
use of MPLS encapsulation as specified by this document.
This document specifies the DetNet data plane operation and the on- This document specifies the DetNet data plane operation and the on-
wire encapsulation of DetNet flows over an MPLS-based Packet Switched wire encapsulation of DetNet flows over an MPLS-based Packet Switched
Network (PSN) using the service reference model. MPLS encapsulation Network (PSN) using the service reference model. MPLS encapsulation
already provides a solid foundation of building blocks to enable the already provides a solid foundation of building blocks to enable the
DetNet service and forwarding sub-layer functions. MPLS encapsulated DetNet service and forwarding sub-layer functions. MPLS-encapsulated
DetNet can be carried over a variety of different network DetNet can be carried over a variety of different network
technologies that can provide the DetNet required level of service. technologies that can provide the level of service required for
However, the specific details of how DetNet MPLS is carried over DetNet. However, the specific details of how DetNet MPLS is carried
different network technologies are out of scope of this document. over different network technologies are out of scope for this
document.
MPLS encapsulated DetNet flows can carry different types of traffic. MPLS-encapsulated DetNet flows can carry different types of traffic.
The details of the types of traffic that are carried in DetNet are The details of the types of traffic that are carried in DetNet are
also out of scope of this document. An example of IP using DetNet also out of scope for this document. An example of IP using DetNet
MPLS sub-networks can be found in [I-D.ietf-detnet-ip]. DetNet MPLS MPLS sub-networks can be found in [RFC8939]. DetNet MPLS may use an
may use an associated controller and Operations, Administration, and associated controller and Operations, Administration, and Maintenance
Maintenance (OAM) functions that are defined outside of this (OAM) functions that are defined outside of this document.
document.
Background information common to all data planes for DetNet can be Background information common to all data planes for DetNet can be
found in the DetNet Data Plane Framework found in the DetNet data plane framework [RFC8938].
[I-D.ietf-detnet-data-plane-framework].
2. Terminology 2. Terminology
2.1. Terms Used in This Document 2.1. Terms Used in This Document
This document uses the terminology established in the DetNet This document uses the terminology established in the DetNet
architecture [RFC8655] and the DetNet Data Plane Framework architecture [RFC8655] and the DetNet data plane framework [RFC8938].
[I-D.ietf-detnet-data-plane-framework]. The reader is assumed to be The reader is assumed to be familiar with these documents, any
familiar with these documents, any terminology defined therein and terminology defined therein, and basic MPLS-related terminologies in
basic MPLS related terminologies in [RFC3031]. [RFC3031].
The following terminology is introduced in this document: The following terminology is introduced in this document:
F-Label A Detnet "forwarding" label that identifies the LSP F-Label A DetNet "forwarding" label that identifies the Label
used to forward a DetNet flow across an MPLS PSN, i.e., Switched Path (LSP) used to forward a DetNet flow
a hop-by-hop label used between label switching routers across an MPLS PSN, i.e., a hop-by-hop label used
(LSR). between Label Switching Routers (LSRs).
S-Label A DetNet "service" label that is used between DetNet S-Label A DetNet "service" label that is used between DetNet
nodes that implement the DetNet service sub-layer nodes that implement the DetNet service sub-layer
functions. An S-Label is used to identify a DetNet functions. An S-Label is used to identify a DetNet
flow at DetNet service sub-layer at a receiving DetNet flow at the DetNet service sub-layer at a receiving
node. DetNet node.
A-Label A special case of an S-Label, whose aggregation A-Label A special case of an S-Label, whose aggregation
properties are known only at the aggregation and properties are known only at the aggregation and
deaggregation end-points. deaggregation end points.
d-CW A DetNet Control Word (d-CW) is used for sequencing d-CW A DetNet Control Word (d-CW) that is used for
information of a DetNet flow at the DetNet service sub- sequencing information of a DetNet flow at the DetNet
layer. service sub-layer.
2.2. Abbreviations 2.2. Abbreviations
The following abbreviations are used in this document: The following abbreviations are used in this document:
CoS Class of Service. CoS Class of Service
CW Control Word. CW Control Word
DetNet Deterministic Networking. DetNet Deterministic Networking
LSR Label Switching Router. LSR Label Switching Router
MPLS Multiprotocol Label Switching. MPLS Multiprotocol Label Switching
MPLS-TE Multiprotocol Label Switching - Traffic Engineering. MPLS-TE Multiprotocol Label Switching Traffic Engineering
MPLS-TP Multiprotocol Label Switching - Transport Profile. MPLS-TP Multiprotocol Label Switching Transport Profile
OAM Operations, Administration, and Maintenance. OAM Operations, Administration, and Maintenance
PE Provider Edge. PE Provider Edge
PEF Packet Elimination Function. PEF Packet Elimination Function
PRF Packet Replication Function. PRF Packet Replication Function
PREOF Packet Replication, Elimination and Ordering Functions. PREOF Packet Replication, Elimination and Ordering Functions
POF Packet Ordering Function. POF Packet Ordering Function
PSN Packet Switched Network. PSN Packet Switched Network
PW PseudoWire. PW Pseudowire
QoS Quality of Service. QoS Quality of Service
S-PE Switching Provider Edge. S-PE Switching Provider Edge
T-PE Terminating Provider Edge. T-PE Terminating Provider Edge
TSN Time-Sensitive Network. TSN Time-Sensitive Networking
2.3. Requirements Language 2.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. DetNet MPLS Data Plane Overview 3. Overview of the DetNet MPLS Data Plane
3.1. Layers of DetNet Data Plane 3.1. Layers of DetNet Data Plane
MPLS provides a wide range of capabilities that can be utilised by MPLS provides a wide range of capabilities that can be utilized by
DetNet. A straight forward approach utilizing MPLS for a DetNet DetNet. A straight-forward approach utilizing MPLS for a DetNet
service sub-layer is based on the existing pseudowire (PW) service sub-layer is based on the existing pseudowire (PW)
encapsulations and by utilizing existing MPLS Traffic Engineering encapsulations and utilizes existing MPLS-TE encapsulations and
encapsulations and mechanisms. Background on PWs can be found in mechanisms. Background on PWs can be found in [RFC3985], [RFC3032],
[RFC3985] and [RFC3031]. Background on MPLS Traffic Engineering can and [RFC3031]. Background on MPLS-TE can be found in [RFC3272] and
be found in [RFC3272] and [RFC3209]. [RFC3209].
DetNet MPLS DetNet MPLS
. .
Bottom of Stack . Bottom of Stack .
(inner label) +------------+ (inner label) +------------+
| Service | d-CW, S-Label (A-Label) | Service | d-CW, S-Label (A-Label)
+------------+ +------------+
| Forwarding | F-Label(s) | Forwarding | F-Label(s)
+------------+ +------------+
Top of Stack . Top of Stack .
(outer label) . (outer label) .
Figure 1: DetNet Adaptation to MPLS Data Plane Figure 1: DetNet Adaptation to MPLS Data Plane
The DetNet MPLS data plane representation is illustrated in Figure 1. The DetNet MPLS data plane representation is illustrated in Figure 1.
The service sub-layer includes a DetNet control word (d-CW) and an The service sub-layer includes a DetNet Control Word (d-CW) and an
identifying service label (S-Label). The DetNet control word (d-CW) identifying service label (S-Label). The DetNet Control Word (d-CW)
conforms to the Generic PW MPLS Control Word (PWMCW) defined in conforms to the Generic PW MPLS Control Word (PWMCW) defined in
[RFC4385]. An aggregation label (A-Label) is a special case of [RFC4385]. An aggregation label (A-Label) is a special case of
S-Label used for aggregation. S-Label used for aggregation.
A node operating on a received DetNet flow at the Detnet service sub- A node operating on a received DetNet flow at the DetNet service sub-
layer uses the local context associated with a received S-Label, layer uses the local context associated with a received S-Label,
i.e., a received F-Label, to determine which local DetNet i.e., a received F-Label, to determine which local DetNet
operation(s) are applied to that packet. An S-Label may be taken operation(s) are applied to that packet. An S-Label may be taken
from the platform label space [RFC3031], making it unique, enabling from the platform label space [RFC3031], making it unique and
DetNet flow identification regardless of which input interface or LSP enabling DetNet flow identification regardless of which input
the packet arrives on. It is important to note that S-Label values interface or LSP the packet arrives on. It is important to note that
are driven by the receiver, not the sender. S-Label values are driven by the receiver, not the sender.
The DetNet forwarding sub-layer is supported by zero or more The DetNet forwarding sub-layer is supported by zero or more
forwarding labels (F-Labels). MPLS Traffic Engineering forwarding labels (F-Labels). MPLS-TE encapsulations and mechanisms
encapsulations and mechanisms can be utilized to provide a forwarding can be utilized to provide a forwarding sub-layer that is responsible
sub-layer that is responsible for providing resource allocation and for providing resource allocation and explicit routes.
explicit routes.
3.2. DetNet MPLS Data Plane Scenarios 3.2. DetNet MPLS Data Plane Scenarios
DetNet MPLS Relay Transit Relay DetNet MPLS DetNet MPLS Relay Transit Relay DetNet MPLS
End System Node Node Node End System End System Node Node Node End System
(T-PE) (S-PE) (LSR) (S-PE) (T-PE) (T-PE) (S-PE) (LSR) (S-PE) (T-PE)
+----------+ +----------+ +----------+ +----------+
| Appl. |<------------ End to End Service ----------->| Appl. | | Appl. |<------------ End-to-End Service ----------->| Appl. |
+----------+ +---------+ +---------+ +----------+ +----------+ +---------+ +---------+ +----------+
| Service |<--| Service |-- DetNet flow --| Service |-->| Service | | Service |<--| Service |-- DetNet flow --| Service |-->| Service |
+----------+ +---------+ +----------+ +---------+ +----------+ +----------+ +---------+ +----------+ +---------+ +----------+
|Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding| |Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding|
+-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+ +-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+
: Link : / ,-----. \ : Link : / ,-----. \ : Link : / ,-----. \ : Link : / ,-----. \
+........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+ +........+ +-[ Sub- ]-+ +......+ +-[ Sub- ]-+
[Network] [Network] [Network] [Network]
`-----' `-----' `-----' `-----'
|<- LSP -->| |<-------- LSP -----------| |<--- LSP -->| |<- LSP -->| |<-------- LSP -----------| |<--- LSP -->|
|<----------------- DetNet MPLS --------------------->| |<----------------- DetNet MPLS --------------------->|
Figure 2: A DetNet MPLS Network Figure 2: A DetNet MPLS Network
Figure 2 illustrates a hypothetical DetNet MPLS-only network composed Figure 2 illustrates a hypothetical DetNet MPLS-only network composed
of DetNet aware MPLS enabled end systems, operating over a DetNet of DetNet-aware MPLS-enabled end systems operating over a DetNet-
aware MPLS network. In this figure, the relay nodes are PE devices aware MPLS network. In this figure, the relay nodes are PE devices
that define the MPLS LSP boundaries and the transit nodes are LSRs. that define the MPLS LSP boundaries, and the transit nodes are LSRs.
DetNet end systems and relay nodes understand the particular needs of DetNet end systems and relay nodes understand the particular needs of
DetNet flows and provide both DetNet service and forwarding sub-layer DetNet flows and provide both DetNet service and forwarding sub-layer
functions. In the case of MPLS, DetNet service-aware nodes add, functions. In the case of MPLS, DetNet service-aware nodes add,
remove and process d-CWs, S-Labels and F-labels as needed. DetNet remove, and process d-CWs, S-Labels, and F-Labels as needed. DetNet
MPLS nodes provide functionality analogous to T-PEs when they sit at MPLS nodes provide functionality analogous to T-PEs when they sit at
the edge of an MPLS domain, and S-PEs when they are in the middle of the edge of an MPLS domain and S-PEs when they are in the middle of
an MPLS domain, see [RFC6073]. an MPLS domain; see [RFC6073].
In a DetNet MPLS network, transit nodes may be DetNet service aware In a DetNet MPLS network, transit nodes may be DetNet-service-aware
or may be DetNet unaware MPLS Label Switching Routers (LSRs). In or DetNet-unaware MPLS Label Switching Routers (LSRs). In this
this latter case, such LSRs would be unaware of the special latter case, such LSRs would be unaware of the special requirements
requirements of the DetNet service sub-layer, but would still provide of the DetNet service sub-layer but would still provide traffic
traffic engineering functions and the QoS capabilities needed to engineering functions and the QoS capabilities needed to ensure that
ensure that the (TE) LSPs meet the service requirements of the the (TE) LSPs meet the service requirements of the carried DetNet
carried DetNet flows. flows.
The application of DetNet using MPLS supports a number of control The application of DetNet using MPLS supports a number of control and
plane/management plane types. These types support certain MPLS data management plane types. These types support certain MPLS data plane
plane deployments. For example RSVP-TE, MPLS-TP, or MPLS Segment deployments. For example, RSVP-TE, MPLS-TP, or MPLS Segment Routing
Routing (when extended to support resource allocation) are all valid (when extended to support resource allocation) are all valid MPLS
MPLS deployment cases. deployment cases.
Figure 3 illustrates how an end-to-end MPLS-based DetNet service is Figure 3 illustrates how an end-to-end MPLS-based DetNet service is
provided in a more detail. In this figure, the customer end systems, provided in more detail. In this figure, the Customer Edge (CE1 and
CE1 and CE2, are able to send and receive MPLS encapsulated DetNet CE2) are able to send and receive MPLS-encapsulated DetNet flows, and
flows, and R1, R2 and R3 are relay nodes in the middle of a DetNet R1, R2, and R3 are relay nodes in the middle of a DetNet network.
network. The 'X' in the end systems, and relay nodes represents The 'X' in the end systems and relay nodes represents potential
potential DetNet compound flow packet replication and elimination DetNet compound flow packet replication and elimination points. In
points. In this example, service protection is supported utilizing this example, service protection is supported utilizing at least two
at least two DetNet member flows and TE LSPs. For a unidirectional DetNet member flows and TE LSPs. For a unidirectional flow, R1
flow, R1 supports PRF and R3 supports PEF and POF. Note that the supports PRF, and R3 supports PEF and POF. Note that the relay nodes
relay nodes may change the underlying forwarding sub-layer, for may change the underlying forwarding sub-layer, for example,
example tunneling MPLS over IEEE 802.1 TSN tunneling MPLS over IEEE 802.1 TSN [DetNet-MPLS-over-TSN] or simply
[I-D.ietf-detnet-mpls-over-tsn], or simply over interconnect network over interconnected network links.
links.
DetNet DetNet DetNet DetNet
DetNet Service Transit Transit Service DetNet DetNet Service Transit Transit Service DetNet
MPLS | |<-Tnl->| |<-Tnl->| | MPLS MPLS | |<-Tnl->| |<-Tnl->| | MPLS
End | V 1 V V 2 V | End End | V 1 V V 2 V | End
System | +--------+ +--------+ +--------+ | System System | +--------+ +--------+ +--------+ | System
+---+ | | R1 |=======| R2 |=======| R3 | | +---+ +---+ | | R1 |=======| R2 |=======| R3 | | +---+
| X...DFa...|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|.DFa..|.X | | X...DFa...|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|.DFa..|.X |
|CE1|========| \ | | X | | / |======|CE2| |CE1|========| \ | | X | | / |======|CE2|
| | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | | | | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | |
+---+ | |=======| |=======| | +---+ +---+ | |=======| |=======| | +---+
^ +--------+ +--------+ +--------+ ^ ^ +--------+ +--------+ +--------+ ^
| Relay Node Relay Node Relay Node | | Relay Node Relay Node Relay Node |
| (S-PE) (S-PE) (S-PE) | | (S-PE) (S-PE) (S-PE) |
| | | |
|<---------------------- DetNet MPLS --------------------->| |<---------------------- DetNet MPLS --------------------->|
| | | |
|<--------------- End to End DetNet Service -------------->| |<--------------- End-to-End DetNet Service -------------->|
-------------------------- Data Flow -------------------------> -------------------------- Data Flow ------------------------->
X = Optional service protection (none, PRF, PREOF, PEF/POF) Figure 3: MPLS-Based Native DetNet
DFx = DetNet member flow x over a TE LSP
Figure 3: MPLS-Based Native DetNet X - Optional service protection (none, PRF, PREOF, PEF/POF)
DFx - DetNet member flow x over a TE LSP
4. MPLS-Based DetNet Data Plane Solution 4. MPLS-Based DetNet Data Plane Solution
4.1. DetNet Over MPLS Encapsulation Components 4.1. DetNet over MPLS Encapsulation Components
To carry DetNet over MPLS the following is required: To carry DetNet over MPLS, the following is required:
1. A method of identifying the MPLS payload type. 1. A method of identifying the MPLS payload type.
2. A method of identifying the DetNet flow(s) to the processing 2. A method of identifying the DetNet flow(s) to the processing
element. element.
3. A method of distinguishing DetNet OAM packets from DetNet data 3. A method of distinguishing DetNet OAM packets from DetNet data
packets. packets.
4. A method of carrying the DetNet sequence number. 4. A method of carrying the DetNet sequence number.
5. A suitable LSP to deliver the packet to the egress PE. 5. A suitable LSP to deliver the packet to the egress PE.
6. A method of carrying queuing and forwarding indication. 6. A method of carrying queuing and forwarding indication.
In this design an MPLS service label (the S-Label), is similar to a In this design, an MPLS service label (the S-Label) is similar to a
pseudowire (PW) label [RFC3985], and is used to identify both the pseudowire (PW) label [RFC3985] and is used to identify both the
DetNet flow identity and the payload MPLS payload type satisfying (1) DetNet flow identity and the MPLS payload type satisfying (1) and (2)
and (2) in the list above. OAM traffic discrimination happens in the list above. OAM traffic discrimination happens through the
through the use of the Associated Channel method described in use of the Associated Channel method described in [RFC4385]. The
[RFC4385]. The DetNet sequence number is carried in the DetNet DetNet sequence number is carried in the DetNet Control Word, which
Control word which carries the Data/OAM discriminator. To simplify also carries the Data/OAM discriminator. To simplify implementation
implementation and to maximize interoperability two sequence number and to maximize interoperability, two sequence number sizes are
sizes are supported: a 16 bit sequence number and a 28 bit sequence supported: a 16-bit sequence number and a 28-bit sequence number.
number. The 16 bit sequence number is needed to support some types The 16-bit sequence number is needed to support some types of legacy
of legacy clients. The 28 bit sequence number is used in situations clients. The 28-bit sequence number is used in situations where it
where it is necessary ensure that in high speed networks the sequence is necessary to ensure that, in high-speed networks, the sequence
number space does not wrap whilst packets are in flight. number space does not wrap whilst packets are in flight.
The LSP used to forward the DetNet packet is not restricted regarding The LSP used to forward the DetNet packet is not restricted regarding
any method used for establishing that LSP (for example, MPLS-LDP, any method used for establishing that LSP (for example, MPLS-LDP,
MPLS-TE, MPLS-TP [RFC5921], MPLS-SR [RFC8660], etc.). The LSP MPLS-TE, MPLS-TP [RFC5921], MPLS Segment Routing [RFC8660], etc.).
(F-Label) label(s) and/or the S-Label may be used to indicate the The F-Label(s) and the S-Label may be used alone or together to
required queue processing as well as the forwarding parameters. Note indicate the required queue processing as well as the forwarding
that the possible use of Penultimate Hop Popping (PHP) means that the parameters. Note that the possible use of Penultimate Hop Popping
S-Label may be the only label received at the terminating DetNet (PHP) means that the S-Label may be the only label received at the
service. terminating DetNet service.
4.2. MPLS Data Plane Encapsulation 4.2. MPLS Data Plane Encapsulation
Figure 4 illustrates a DetNet data plane MPLS encapsulation. The Figure 4 illustrates a DetNet data plane MPLS encapsulation. The
MPLS-based encapsulation of the DetNet flows is well suited for the MPLS-based encapsulation of the DetNet flows is well suited for the
scenarios described in [I-D.ietf-detnet-data-plane-framework]. scenarios described in [RFC8938]. Furthermore, an end-to-end DetNet
Furthermore, an end-to-end DetNet service i.e., native DetNet service, i.e., native DetNet deployment (see Section 3.2), is also
deployment (see Section 3.2) is also possible if DetNet end systems possible if DetNet end systems are capable of initiating and
are capable of initiating and termination MPLS encapsulated packets. terminating MPLS-encapsulated packets.
The MPLS-based DetNet data plane encapsulation consists of: The MPLS-based DetNet data plane encapsulation consists of:
o DetNet control word (d-CW) containing sequencing information for * A DetNet Control Word (d-CW) containing sequencing information for
packet replication and duplicate elimination purposes, and the OAM packet replication and duplicate elimination purposes, and the OAM
indicator. indicator.
o DetNet service Label (S-Label) that identifies a DetNet flow at * A DetNet service label (S-Label) that identifies a DetNet flow at
the receiving DetNet service sub-layer processing node. the receiving DetNet service sub-layer processing node.
o Zero or more Detnet MPLS Forwarding label(s) (F-Label) used to * Zero or more DetNet MPLS forwarding label(s) (F-Label) used to
direct the packet along the label switched path (LSP) to the next direct the packet along the Label Switched Path (LSP) to the next
DetNet service sub-layer processing node along the path. When DetNet service sub-layer processing node along the path. When PHP
Penultimate Hop Popping is in use there may be no label F-Label in is in use, there may be no F-Label in the protocol stack on the
the protocol stack on the final hop. final hop.
o The necessary data-link encapsulation is then applied prior to * The necessary data-link encapsulation is then applied prior to
transmission over the physical media. transmission over the physical media.
DetNet MPLS-based encapsulation DetNet MPLS-based encapsulation
+---------------------------------+ +---------------------------------+
| | | |
| DetNet App-Flow | | DetNet App-Flow |
| Payload Packet | | Payload Packet |
| | | |
+---------------------------------+ <--\ +---------------------------------+ <--\
skipping to change at page 10, line 42 skipping to change at line 442
+---------------------------------+ | +---------------------------------+ |
| [ F-Label(s) ] | | | [ F-Label(s) ] | |
+---------------------------------+ <--/ +---------------------------------+ <--/
| Data-Link | | Data-Link |
+---------------------------------+ +---------------------------------+
| Physical | | Physical |
+---------------------------------+ +---------------------------------+
Figure 4: Encapsulation of a DetNet App-Flow in an MPLS PSN Figure 4: Encapsulation of a DetNet App-Flow in an MPLS PSN
4.2.1. DetNet Control Word and the DetNet Sequence Number 4.2.1. DetNet Control Word and DetNet Sequence Number
A DetNet control word (d-CW) conforms to the Generic PW MPLS Control A DetNet Control Word (d-CW) conforms to the Generic PW MPLS Control
Word (PWMCW) defined in [RFC4385]. The d-CW formatted as shown in Word (PWMCW) defined in [RFC4385]. The d-CW formatted as shown in
Figure 5 MUST be present in all DetNet packets containing app-flow Figure 5 MUST be present in all DetNet packets containing App-flow
data. This format of the d-CW was created in order (1) to allow data. This format of the d-CW was created in order to (1) allow
larger sequence number space to avoid sequence number rollover larger sequence number space to avoid sequence number rollover
frequency in some applications and (2) to allow sequence numbering frequency in some applications and (2) allow sequence numbering
systems that include the value zero as a valid sequence number, which systems that include the value zero as a valid sequence number, which
simplifies implementation. simplifies implementation.
0 1 2 3 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 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 | |0 0 0 0| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DetNet Control Word Figure 5: DetNet Control Word
skipping to change at page 11, line 14 skipping to change at line 462
0 1 2 3 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 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 | |0 0 0 0| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DetNet Control Word Figure 5: DetNet Control Word
(bits 0 to 3) (bits 0 to 3)
Per [RFC4385], MUST be set to zero (0). Per [RFC4385], MUST be set to zero (0).
Sequence Number (bits 4 to 31) Sequence Number (bits 4 to 31)
An unsigned value implementing the DetNet sequence number. The An unsigned value implementing the DetNet sequence number. The
sequence number space is a circular one with no restriction on sequence number space is a circular one with no restriction on the
initial value. initial value.
A separate sequence number space MUST be maintained by the node that 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 adds the d-CW for each DetNet App-flow, i.e., DetNet service. The
following sequence number field lengths MUST be supported: following Sequence Number field lengths MUST be supported:
0 bits * 0 bits
16 bits * 16 bits
28 bits * 28 bits
The sequence number length MUST be provisioned on a per Detnet The sequence number length MUST be provisioned on a per-DetNet-
service basis via configuration, i.e., via the controller plane service basis via configuration, i.e., via the Controller Plane
described in [I-D.ietf-detnet-data-plane-framework]. described in [RFC8938].
A 0 bit sequence number field length indicates that there is no A 0-bit Sequence Number field length indicates that there is no
DetNet sequence number used for the flow. When the length is zero, 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 the Sequence Number field MUST be set to zero (0) on all packets sent
for the flow. for the flow.
When the sequence number field length is 16 or 28 bits for a 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 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 packet sent. When the field length is 16 bits, d-CW bits 4 to 15
MUST be set to zero (0). The values carried in this field can wrap MUST be set to zero (0). The values carried in this field can wrap,
and it is important to note that zero (0) is a valid field value. and it is important to note that zero (0) is a valid field value.
For example, where the sequence number size is 16 bits, the sequence For example, where the sequence number size is 16 bits, the sequence
will contain: 65535, 0, 1, where zero (0) is an ordinary sequence will contain: 65535, 0, 1, where zero (0) is an ordinary sequence
number. number.
It is important to note that this document differs from [RFC4448] It is important to note that this document differs from [RFC4448],
where a sequence number of zero (0) is used to indicate that the where a sequence number of zero (0) is used to indicate that the
sequence number check algorithm is not used. sequence number check algorithm is not used.
The sequence number is optionally used during receive processing as The sequence number is optionally used during receive processing, as
described below in Section 4.2.2.2 and Section 4.2.2.3. described below in Sections 4.2.2.2 and 4.2.2.3.
4.2.2. S-Labels 4.2.2. S-Labels
A DetNet flow at the DetNet service sub-layer is identified by an A DetNet flow at the DetNet service sub-layer is identified by an
S-Label. MPLS-aware DetNet end systems and edge nodes, which are by S-Label. MPLS-aware DetNet end systems and edge nodes, which are by
definition MPLS ingress and egress nodes, MUST add (push) and remove definition MPLS ingress and egress nodes, MUST add (push) and remove
(pop) a DetNet service-specific d-CW and S-Label. Relay nodes MAY (pop) a DetNet service-specific d-CW and S-Label. Relay nodes MAY
swap S-Label values when processing a DetNet flow, i.e., incoming and swap S-Label values when processing a DetNet flow, i.e., incoming and
outgoing S-Labels of a DetNet flow can be different. outgoing S-Labels of a DetNet flow can be different.
S-Label values MUST be provisioned per DetNet service via S-Label values MUST be provisioned per DetNet service via
configuration, i.e., via the controller plane described in configuration, i.e., via the Controller Plane described in [RFC8938].
[I-D.ietf-detnet-data-plane-framework]. Note that S-Labels provide Note that S-Labels provide identification at the downstream DetNet
identification at the downstream DetNet service sub-layer receiver, service sub-layer receiver, not the sender. As such, S-Labels MUST
not the sender. As such, S-Labels MUST be allocated by the entity be allocated by the entity that controls the service sub-layer
that controls the service sub-layer receiving node's label space, and receiving a node's label space and MAY be allocated from the platform
MAY be allocated from the platform label space [RFC3031]. Because label space [RFC3031]. Because S-Labels are local to each node,
S-Labels are local to each node rather than being a global identifier rather than being a global identifier within a domain, they must be
within a domain, they must be advertised to their upstream DetNet advertised to their upstream DetNet service-aware peer nodes (i.e., a
service-aware peer nodes (i.e., a DetNet MPLS End System or a DetNet DetNet MPLS end system or a DetNet relay or edge node) and
Relay or Edge Node) and interpreted in the context of their received interpreted in the context of their received F-Label(s). In some
F-Label(s). In some PREOF topologies, the node performing PREOF topologies, the node performing replication will be sending to
replication will be sending to multiple nodes performing PEF or POF, multiple nodes performing PEF or POF and may need to send different
and may need to send different S-Label values for the different S-Label values for the different member flows for the same DetNet
member flows for the same DetNet service. service.
An S-Label will normally be at the bottom of the label stack once the An S-Label will normally be at the bottom of the label stack once the
last F-Label is removed, immediately preceding the d-CW. To support last F-Label is removed, immediately preceding the d-CW. To support
service sub-layer level OAM, an OAM Associated Channel Header (ACH) OAM at the service sub-layer level, an OAM Associated Channel Header
[RFC4385] together with a Generic Associated Channel Label (GAL) (ACH) [RFC4385] together with a Generic Associated Channel Label
[RFC5586] MAY be used in place of a d-CW. (GAL) [RFC5586] MAY be used in place of a d-CW.
Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) Similarly, an Entropy Label Indicator (ELI) and Entropy Label (EL)
[RFC6790] MAY be carried below the S-Label in the label stack in [RFC6790] MAY be carried below the S-Label in the label stack in
networks where DetNet flows would otherwise receive ECMP treatment. networks where DetNet flows would otherwise receive ECMP treatment.
When ELs are used, the same EL value SHOULD be used for all of the When ELs are used, the same EL value SHOULD be used for all of the
packets sent using a specific S-Label to force the flow to follow the packets sent using a specific S-Label to force the flow to follow the
same path. However, as outlined in same path. However, as outlined in [RFC8938], the use of ECMP for
[I-D.ietf-detnet-data-plane-framework] the use of ECMP for DetNet DetNet flows is NOT RECOMMENDED. ECMP MAY be used for non-DetNet
flows is NOT RECOMMENDED. ECMP MAY be used for non-DetNet flows flows within a DetNet domain.
within a DetNet domain.
When receiving a DetNet MPLS packet, an implementation MUST identify When receiving a DetNet MPLS packet, an implementation MUST identify
the DetNet service associated with the incoming packet based on the the DetNet service associated with the incoming packet based on the
S-Label. When a node is using platform labels for S-Labels, no S-Label. When a node is using platform labels for S-Labels, no
additional information is needed as the S-label uniquely identifies additional information is needed, as the S-Label uniquely identifies
the DetNet service. In the case where platform labels are not used, the DetNet service. In the case where platform labels are not used,
zero or more F-Labels proceeding the S-Label MUST be used together zero or more F-Labels proceeding the S-Label MUST be used together
with the S-Label to uniquely identify the DetNet service associated with the S-Label to uniquely identify the DetNet service associated
with a received packet. The incoming interface MAY also be used with a received packet. The incoming interface MAY also be used
together with any present F-Label(s) and the S-Label to uniquely together with any present F-Label(s) and the S-Label to uniquely
identify an incoming DetNet service, for example, in the case where identify an incoming DetNet service, for example, in the case where
PHP is used. Note that choice to use platform label space for PHP is used. Note that the choice to use the platform label space
S-Label or S-Label plus one or more F-Labels to identify DetNet for an S-Label or an S-Label plus one or more F-Labels to identify
services is a local implementation choice, with one caveat. When one DetNet services is a local implementation choice, with one caveat.
or more F-labels, or incoming interface, is needed together with an When one or more F-Labels, or the incoming interface, is needed
S-Label to uniquely identify a service, the controller plane must together with an S-Label to uniquely identify a service, the
ensure that incoming DetNet MPLS packets arrive with the needed Controller Plane must ensure that incoming DetNet MPLS packets arrive
information (F-label(s) and/or incoming interface) and provision the with the needed information (F-Label(s) and/or the incoming
needed information. The provisioned information MUST then be used to interface) and provision the needed information. The provisioned
identify incoming DetNet service based on the combination of S-Label information MUST then be used to identify incoming DetNet service
and F-Label(s) or incoming interface. based on the combination of S-Label and F-Label(s) or the incoming
interface.
The use of platform labels for S-Labels matches other pseudowire The use of platform labels for S-Labels matches other pseudowire
encapsulations for consistency but there is no hard requirement in encapsulations for consistency, but there is no hard requirement in
this regard. this regard.
Implementation details of PREOF functions are out of scope for this Implementation details of PREOF are out of scope for this document.
document. [IEEE802.1CB-2017] defines equivalent replication and [IEEE802.1CB-2017] defines equivalent replication and elimination-
elimination specific aspects, which can be applied to PRF and PEF. specific aspects, which can be applied to PRF and PEF.
4.2.2.1. Packet Replication Function Processing 4.2.2.1. Packet Replication Function Processing
The Packet Replication Function (PRF) function MAY be supported by an The Packet Replication Function (PRF) MAY be supported by an
implementation for outgoing DetNet flows. The use of the PRF for a implementation for outgoing DetNet flows. The use of the PRF for a
particular DetNet service MUST be provisioned via configuration, particular DetNet service MUST be provisioned via configuration,
i.e., via the controller plane described in i.e., via the Controller Plane described in [RFC8938]. When
[I-D.ietf-detnet-data-plane-framework]. When replication is replication is configured, the same App-flow data will be sent over
configured, the same app-flow data will be sent over multiple multiple outgoing DetNet member flows using forwarding sub-layer
outgoing DetNet member flows using forwarding sub-layer LSPs. An LSPs. An S-Label value MUST be configured per outgoing member flow.
S-Label value MUST be configured per outgoing member flow. The same The same d-CW field value MUST be used on all outgoing member flows
d-CW field value MUST be used on all outgoing member flows for each for each replicated MPLS packet.
replicated MPLS packet.
4.2.2.2. Packet Elimination Function Processing 4.2.2.2. Packet Elimination Function Processing
Implementations MAY support the Packet Elimination Function (PEF) for Implementations MAY support the Packet Elimination Function (PEF) for
received DetNet MPLS flows. When supported, use of the PEF for a received DetNet MPLS flows. When supported, use of the PEF for a
particular DetNet service MUST be provisioned via configuration, particular DetNet service MUST be provisioned via configuration,
i.e., via the controller plane described in i.e., via the Controller Plane described in [RFC8938].
[I-D.ietf-detnet-data-plane-framework].
After a DetNet service is identified for a received DetNet MPLS After a DetNet service is identified for a received DetNet MPLS
packet, as described above, if PEF is configured for that DetNet packet, as described above, if PEF is configured for that DetNet
service, duplicate (replicated) instances of a particular sequence service, duplicate (replicated) instances of a particular sequence
number MUST be discarded. The specific mechanisms used for an number MUST be discarded. The specific mechanisms used for an
implementation to identify which received packets are duplicates and implementation to identify which received packets are duplicates and
which are new is an implementation choice. Note that per which are new is an implementation choice. Note that, per
Section 4.2.1 the sequence number field length may be 16 or 28 bits, Section 4.2.1, the Sequence Number field length may be 16 or 28 bits,
and the field value can wrap. PEF MUST NOT be used with DetNet flows and the field value can wrap. PEF MUST NOT be used with DetNet flows
configured with a d-CW sequence number field length of 0 bits. configured with a d-CW Sequence Number field length of 0 bits.
An implementation MAY constrain the maximum number of sequence An implementation MAY constrain the maximum number of sequence
numbers that are tracked on either a platform-wide or per flow basis. numbers that are tracked on either a platform-wide or per-flow basis.
Some implementations MAY support the provisioning of the maximum Some implementations MAY support the provisioning of the maximum
number of sequence numbers that are tracked on either a platform-wide number of sequence numbers that are tracked on either a platform-wide
or per flow basis. or per-flow basis.
4.2.2.3. Packet Ordering Function Processing 4.2.2.3. Packet Ordering Function Processing
A function that is related to in-order delivery is the Packet A function that is related to in-order delivery is the Packet
Ordering Function (POF). Implementations MAY support POF. When Ordering Function (POF). Implementations MAY support POF. When
supported, use of the POF for a particular DetNet service MUST be supported, use of the POF for a particular DetNet service MUST be
provisioned via configuration, i.e., via the controller plane provisioned via configuration, i.e., via the Controller Plane
described by [I-D.ietf-detnet-data-plane-framework]. Implementations described by [RFC8938]. Implementations MAY require that PEF and POF
MAY require that PEF and POF be used in combination. There is no be used in combination. There is no requirement related to the order
requirement related to the order of execution of the Packet of execution of the PEF and POF in an implementation.
Elimination and Ordering Functions in an implementation.
After a DetNet service is identified for a received DetNet MPLS After a DetNet service is identified for a received DetNet MPLS
packet, as described above, if POF is configured for that DetNet packet, as described above, if POF is configured for that DetNet
service, packets MUST be processed in the order indicated in the service, packets MUST be processed in the order indicated in the
received d-CW sequence number field, which may not be in the order received d-CW Sequence Number field, which may not be in the order
the packets are received. As defined in Section 4.2.1 the sequence the packets are received. As defined in Section 4.2.1, the Sequence
number field length may be 16 or 28 bits, is incremented by one (1) Number field length may be 16 or 28 bits, the sequence number is
for each new MPLS packet sent for a particular DetNet service, and incremented by one (1) for each new MPLS packet sent for a particular
the field value can wrap. The specific mechanisms used for an DetNet service, and the field value can wrap. The specific
implementation to identify the order of received packets is an mechanisms used for an implementation to identify the order of
implementation choice. received packets is an implementation choice.
An implementation MAY constrain the maximum number of out of order An implementation MAY constrain the maximum number of out-of-order
packets that can be processed, on either a platform-wide or per flow packets that can be processed on either a platform-wide or per-flow
basis. The number of out of order packets that can be processed also basis. The number of out-of-order packets that can be processed also
impacts the latency of a flow. impacts the latency of a flow.
The latency impact on the system resources needed to support a The latency impact on the system resources needed to support a
specific DetNet flow will need to be evaluated by the controller specific DetNet flow will need to be evaluated by the Controller
plane based on that flow's traffic specification. An example traffic Plane based on that flow's traffic specification. An example traffic
specification that can be used with MPLS with Traffic Engineering specification that can be used with MPLS-TE can be found in
(MPLS-TE) can be found in [RFC2212]. [RFC2212].
DetNet implementations can use flow-specific requirements (e.g., DetNet implementations can use flow-specific requirements (e.g.,
maximum number of out-of-order packets, maximum latency of the flow) maximum number of out-of-order packets and maximum latency of the
for configuration of POF-related buffers. POF implementation details flow) for configuration of POF-related buffers. POF implementation
are out-of-scope for this document and POF configuration parameters details are out of scope for this document, and POF configuration
are implementation specific. The Controller Plane identifies and parameters are implementation specific. The Controller Plane
sets the POF configuration parameters. identifies and sets the POF configuration parameters.
4.2.3. F-Labels 4.2.3. F-Labels
F-Labels support the DetNet forwarding sub-layer. F-Labels are used F-Labels support the DetNet forwarding sub-layer. F-Labels are used
to provide LSP-based connectivity between DetNet service sub-layer to provide LSP-based connectivity between DetNet service sub-layer
processing nodes. processing nodes.
4.2.3.1. Service Sub-Layer Related Processing 4.2.3.1. Service Sub-Layer-Related Processing
DetNet MPLS end systems, edge nodes and relay nodes may operate at DetNet MPLS end systems, edge nodes, and relay nodes may operate at
the DetNet service sub-layer with understanding of DetNet services the DetNet service sub-layer with understanding of DetNet services
and their requirements. As mentioned earlier, when operating at this and their requirements. As mentioned earlier, when operating at this
layer such nodes can push, pop or swap (pop then push) S-Labels. In layer, such nodes can push, pop, or swap (pop then push) S-Labels.
all cases, the F-Label(s) used for a DetNet service are always In all cases, the F-Label(s) used for a DetNet service are always
replaced and the following procedures apply. replaced, and the following procedures apply.
When sending a DetNet flow, zero or more F-Labels MAY be pushed on When sending a DetNet flow, zero or more F-Labels MAY be pushed on
top of an S-Label by the node pushing an S-Label. The F-Label(s) to top of an S-Label by the node pushing an S-Label. The F-Label(s) to
be pushed when sending a particular DetNet service MUST be be pushed when sending a particular DetNet service MUST be
provisioned per outgoing S-Label via configuration, i.e., via the provisioned per outgoing S-Label via configuration, i.e., via the
controller plane discussed in [I-D.ietf-detnet-data-plane-framework]. Controller Plane discussed in [RFC8938]. F-Label(s) can also provide
F-Label(s) can also provide context for an S-Label. To allow for the context for an S-Label. To allow for the omission of F-Label(s), an
omission of F-Label(s), an implementation SHOULD also allow an implementation SHOULD also allow an outgoing interface to be
outgoing interface to be configured per S-Label. configured per S-Label.
Note, when PRF is supported, the same app-flow data will be sent over Note that when PRF is supported, the same App-flow data will be sent
multiple outgoing DetNet member flows using forwarding sub-layer over multiple outgoing DetNet member flows using forwarding sub-layer
LSPs. This means that implementation may be sending different sets LSPs. This means that an implementation may be sending different
of F-Labels per DetNet member flow, each with a different S-Label. 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 When a single set of F-Labels is provisioned for a particular
outgoing S-Label, that set of F-labels MUST be pushed after the outgoing S-Label, that set of F-Labels MUST be pushed after the
S-Label is pushed. The outgoing packet is then forwarded as S-Label is pushed. The outgoing packet is then forwarded, as
described below in Section 4.2.3.2. When a single outgoing interface described below in Section 4.2.3.2. When a single outgoing interface
is provisioned, the outgoing packet is then forwarded as described is provisioned, the outgoing packet is then forwarded, as described
below in Section 4.2.3.2. below in Section 4.2.3.2.
When multiple sets of outgoing F-Labels or interfaces are provisioned When multiple sets of outgoing F-Labels or interfaces are provisioned
for a particular DetNet service (i.e., for PRF), a copy of the for a particular DetNet service (i.e., for PRF), a copy of the
outgoing packet, including the pushed member flow-specific S-Label, outgoing packet, including the pushed member flow-specific S-Label,
MUST be made per F-label set and outgoing interface. Each set of MUST be made per F-Label set and outgoing interface. Each set of
provisioned F-Labels are then pushed onto a copy of the packet. Each provisioned F-Labels are then pushed onto a copy of the packet. Each
copy is then forwarded as described below in Section 4.2.3.2. copy is then forwarded, as described below in Section 4.2.3.2.
As described in the previous section, when receiving a DetNet MPLS As described in the previous section, when receiving a DetNet MPLS
flow, an implementation identifies the DetNet service associated with flow, an implementation identifies the DetNet service associated with
the incoming packet based on the S-Label. When a node is using 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 platform labels for S-Labels, any F-Labels can be popped, and the
S-label uniquely identifies the DetNet service. In the case where S-Label uniquely identifies the DetNet service. In the case where
platform labels are not used, incoming F-Label(s) and, optionally, platform labels are not used, incoming F-Label(s) and, optionally,
the incoming interface MUST also be provisioned for a DetNet service. the incoming interface MUST also be provisioned for a DetNet service.
4.2.3.2. Common F-Label Processing 4.2.3.2. Common F-Label Processing
All DetNet aware MPLS nodes process F-Labels as needed to meet the All DetNet-aware MPLS nodes process F-Labels as needed to meet the
service requirements of the DetNet flow or flows carried in the LSPs service requirements of the DetNet flow or flows carried in the LSPs
represented by the F-Labels. This includes normal push, pop and swap represented by the F-Labels. This includes normal push, pop, and
operations. Such processing is essentially the same type of swap operations. Such processing is essentially the same type of
processing provided for TE LSPs, although the specific service processing provided for TE LSPs, although the specific service
parameters, or traffic specification, can differ. When the DetNet parameters, or traffic specification, can differ. When the DetNet
service parameters of the DetNet flow or flows carried in an LSP service parameters of the DetNet flow or flows carried in an LSP
represented by an F-Label can be met by an existing TE mechanism, the represented by an F-Label can be met by an existing TE mechanism, the
forwarding sub-layer processing node MAY be a DetNet unaware, i.e., forwarding sub-layer processing node MAY be a DetNet-unaware, i.e.,
standard, MPLS LSR. Such TE LSPs may provide LSP forwarding service standard, MPLS LSR. Such TE LSPs may provide LSP forwarding service
as defined in, but not limited to, [RFC3209], [RFC3270], [RFC3272], as defined in, but not limited, to the following: [RFC3209],
[RFC3473], [RFC4875], [RFC5440], and [RFC8306]. [RFC3270], [RFC3272], [RFC3473], [RFC4875], [RFC5440], and [RFC8306].
More specifically, as mentioned above, the DetNet forwarding sub- More specifically, as mentioned above, the DetNet forwarding sub-
layer provides explicit routes and allocated resources, and F-Labels layer provides explicit routes and allocated resources, and F-Labels
are used to map to each. Explicit routes are supported based on the are used to map to each. Explicit routes are supported based on the
topmost (outermost) F-Label that is pushed or swapped and the LSP topmost (outermost) F-Label that is pushed or swapped and the LSP
that corresponds to this label. This topmost (outgoing) label MUST that corresponds to this label. This topmost (outgoing) label MUST
be associated with a provisioned outgoing interface and, for non- be associated with a provisioned outgoing interface and, for non-
point-to-point outgoing interfaces, a next hop LSR. Note that this point-to-point outgoing interfaces, a next-hop LSR. Note that this
information MUST be provisioned via configuration or the controller information MUST be provisioned via configuration or the Controller
plane. In the previously mentioned special case where there are no Plane. In the previously mentioned special case where there are no
added F-labels and the outgoing interface is not a point-to-point added F-Labels and the outgoing interface is not a point-to-point
interface, the outgoing interface MUST also be associated with a next interface, the outgoing interface MUST also be associated with a
hop LSR. next-hop LSR.
Resources may be allocated in a hierarchical fashion per LSP that is Resources may be allocated in a hierarchical fashion per each LSP
represented by each F-Label. Each LSP MAY be provisioned with a that is represented by each F-Label. Each LSP MAY be provisioned
service parameter that dictates the specific traffic treatment to be with a service parameter that dictates the specific traffic treatment
received by the traffic carried over that LSP. Implementations of to be received by the traffic carried over that LSP. Implementations
this document MUST ensure that traffic carried over each LSP of this document MUST ensure that traffic carried over each LSP
represented by one or more F-Labels receives the traffic treatment represented by one or more F-Labels receives the traffic treatment
provisioned for that LSP. Typical mechanisms used to provide provisioned for that LSP. Typical mechanisms used to provide
different treatment to different flows includes the allocation of different treatment to different flows include the allocation of
system resources (such as queues and buffers) and provisioning of system resources (such as queues and buffers) and provisioning of
related parameters (such as shaping, and policing) that may be found related parameters (such as shaping and policing) that may be found
in implementations of Resource ReSerVation Protocol (RSVP) [RFC2205] in implementations of the Resource ReSerVation Protocol (RSVP)
(RSVP) and RSVP-TE [RFC3209] and [RFC3473]. Support can also be [RFC2205] and RSVP-TE [RFC3209] [RFC3473]. Support can also be
provided via an underlying network technology such IEEE802.1 TSN provided via an underlying network technology, such as IEEE 802.1 TSN
[I-D.ietf-detnet-mpls-over-tsn]. The specific mechanisms selected by [DetNet-MPLS-over-TSN]. The specific mechanisms selected by a DetNet
a DetNet node to ensure DetNet service delivery requirements are met node to ensure DetNet service delivery requirements are met for
for supported DetNet flows is outside the scope of this document. supported DetNet flows is outside the scope of this document.
Packets that are marked in a way that do not correspond to allocated Packets that are marked in a way that do not correspond to allocated
resources, e.g., lack a provisioned F-Label, can disrupt the QoS resources, e.g., lack a provisioned F-Label, can disrupt the QoS
offered to properly reserved DetNet flows by using resources offered to properly reserved DetNet flows by using resources
allocated to the reserved flows. Therefore, the network nodes of a allocated to the reserved flows. Therefore, the network nodes of a
DetNet network: DetNet network:
o MUST defend the DetNet QoS by discarding or remarking (to an * MUST defend the DetNet QoS by discarding or remarking (to an
allocated DetNet flow or non-competing non-DetNet flow) packets allocated DetNet flow or noncompeting non-DetNet flow) packets
received that are not associated with a completed resource received that are not associated with a completed resource
allocation. allocation.
o MUST NOT use a DetNet allocated resource, e.g. a queue or shaper * MUST NOT use a DetNet allocated resource, e.g., a queue or shaper
reserved for DetNet flows, for any packet that does match the reserved for DetNet flows, for any packet that does match the
corresponding DetNet flow. corresponding DetNet flow.
o MUST ensure a QoS flow does not exceed its allocated resources or * MUST ensure a QoS flow does not exceed its allocated resources or
provisioned service level, provisioned service level.
o MUST ensure a CoS flow or service class does not impact the * MUST ensure a CoS flow or service class does not impact the
service delivered to other flows. This requirement is similar to service delivered to other flows. This requirement is similar to
the requirement for MPLS LSRs that CoS LSPs do not impact the the requirement for MPLS LSRs that CoS LSPs do not impact the
resources allocated to TE LSPs, e.g., via [RFC3473]. resources allocated to TE LSPs, e.g., via [RFC3473].
Subsequent sections provide additional considerations related to CoS Subsequent sections provide additional considerations related to CoS
(Section 4.6.1), QoS (Section 4.6.2) and aggregation (Section 4.4). (Section 4.6.1), QoS (Section 4.6.2), and aggregation (Section 4.4).
4.3. OAM Indication 4.3. OAM Indication
OAM follows the procedures set out in [RFC5085] with the restriction OAM follows the procedures set out in [RFC5085] with the restriction
that only Virtual Circuit Connectivity Verification (VCCV) type 1 is that only Virtual Circuit Connectivity Verification (VCCV) type 1 is
supported. supported.
As shown in Figure 3 of [RFC5085] when the first nibble of the d-CW 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. However, is 0x0, the payload following the d-CW is normal user data. However,
when the first nibble of the d-CW is 0x1, the payload that follows when the first nibble of the d-CW is 0x1, the payload that follows
the d-CW is an OAM payload with the OAM type indicated by the value the d-CW is an OAM payload with the OAM type indicated by the value
in the d-CW Channel Type field. in the d-CW Channel Type field.
The reader is referred to [RFC5085] for a more detailed description The reader is referred to [RFC5085] for a more detailed description
of the Associated Channel mechanism, and to the DetNet work on OAM of the Associated Channel mechanism and to the DetNet work on OAM
for more information DetNet OAM. [DetNet-MPLS-OAM] for more information about DetNet OAM.
Additional considerations on DetNet-specific OAM are subjects for Additional considerations on DetNet-specific OAM are subjects for
further study. further study.
4.4. Flow Aggregation 4.4. Flow Aggregation
The ability to aggregate individual flows, and their associated The ability to aggregate individual flows and their associated
resource control, into a larger aggregate is an important technique resource control into a larger aggregate is an important technique
for improving scaling of control in the data, management and control for improving scaling of control in the data, management, and control
planes. The DetNet data plane allows for the aggregation of DetNet planes. The DetNet data plane allows for the aggregation of DetNet
flows, to improved scaling. There are two methods of supporting flow flows to improved scaling. There are two methods of supporting flow
aggregation covered in this section. aggregation covered in this section.
The resource control and management aspects of aggregation (including The resource control and management aspects of aggregation (including
the configuration of queuing, shaping, and policing) are the the configuration of queuing, shaping, and policing) are the
responsibility of the DetNet controller plane and is out of scope of responsibility of the DetNet Controller Plane and are out of scope
this documents. It is also the responsibility of the controller for this document. It is also the responsibility of the Controller
plane to ensure that consistent aggregation methods are used. Plane to ensure that consistent aggregation methods are used.
4.4.1. Aggregation Via LSP Hierarchy 4.4.1. Aggregation via LSP Hierarchy
DetNet flows forwarded via MPLS can leverage MPLS-TE's existing DetNet flows forwarded via MPLS can leverage MPLS-TE's existing
support for hierarchical LSPs (H-LSPs), see [RFC4206]. H-LSPs are support for hierarchical LSPs (H-LSPs); see [RFC4206]. H-LSPs are
typically used to aggregate control and resources, they may also be typically used to aggregate control and resources; they may also be
used to provide OAM or protection for the aggregated LSPs. Arbitrary used to provide OAM or protection for the aggregated LSPs. Arbitrary
levels of aggregation naturally falls out of the definition for levels of aggregation naturally fall out of the definition for
hierarchy and the MPLS label stack [RFC3032]. DetNet nodes which hierarchy and the MPLS label stack [RFC3032]. DetNet nodes that
support aggregation (LSP hierarchy) map one or more LSPs (labels) support aggregation (LSP hierarchy) map one or more LSPs (labels)
into and from an H-LSP. Both carried LSPs and H-LSPs may or may not into and from an H-LSP. Both carried LSPs and H-LSPs may or may not
use the TC field, i.e., L-LSPs or E-LSPs [RFC3270]. Such nodes will use the Traffic Class (TC) field, i.e., L-LSPs (Label-Only-Inferred-
need to ensure that individual LSPs and H-LSPs receive the traffic PSC LSPs) or E-LSPs (EXP-Inferred-PSC LSPs [RFC3270], which were
treatment required to ensure the required DetNet service is renamed to "Explicitly TC-encoded-PSC LSPs" in Section 2.2 of
preserved. [RFC5462]). Such nodes will need to ensure that individual LSPs and
H-LSPs receive the traffic treatment required to ensure the required
DetNet service is preserved.
Additional details of the traffic control capabilities needed at a Additional details of the traffic control capabilities needed at a
DetNet-aware node may be covered in the new service definitions DetNet-aware node may be covered in the new service definitions
mentioned above or in separate future documents. Controller plane mentioned above or in separate future documents. Controller Plane
mechanisms will also need to ensure that the service required on the mechanisms will also need to ensure that the service required on the
aggregate flow are provided, which may include the discarding or aggregate flow are provided, which may include the discarding or
remarking mentioned in the previous sections. remarking mentioned in the previous sections.
4.4.2. Aggregating DetNet Flows as a new DetNet flow 4.4.2. Aggregating DetNet Flows as a New DetNet Flow
An aggregate can be built by layering DetNet flows, including both An aggregate can be built by layering DetNet flows, including both
their S-Label and, when present, F-Labels as shown below: their S-Label and (when present) F-Labels, as shown below:
+---------------------------------+ +---------------------------------+
| | | |
| DetNet Flow | | DetNet Flow |
| Payload Packet | | Payload Packet |
| | | |
+---------------------------------+ <--\ +---------------------------------+ <--\
| DetNet Control Word | | | DetNet Control Word | |
+=================================+ | +=================================+ |
| S-Label | | | S-Label | |
skipping to change at page 19, line 33 skipping to change at line 857
+=================================+ | +=================================+ |
| A-Label | | | A-Label | |
+---------------------------------+ | +---------------------------------+ |
| F-Label(s) | <--/ | F-Label(s) | <--/
+---------------------------------+ +---------------------------------+
| Data-Link | | Data-Link |
+---------------------------------+ +---------------------------------+
| Physical | | Physical |
+---------------------------------+ +---------------------------------+
Figure 6: DetNet Aggregation as a new DetNet Flow Figure 6: DetNet Aggregation as a New DetNet Flow
Both the aggregation label, which is referred to as an A-Label, and Both the aggregation label, which is referred to as an A-Label, and
the individual flow's S-Label have their MPLS S bit set indicating the individual flow's S-Label have their MPLS S bit set indicating
bottom of stack, and the d-CW allows the PREOF to work. An A-Label the bottom of stack, and the d-CW allows the PREOF to work. An
is a special case of an S-Label, whose properties are known only at A-Label is a special case of an S-Label, whose properties are known
the aggregation and deaggregation end-points. only at the aggregation and deaggregation end points.
It is a property of the A-Label that what follows is a d-CW followed It is 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 would by an MPLS label stack. A relay node processing the A-Label would
not know the underlying payload type, and the A-Label would be not know the underlying payload type, and the A-Label would be
processed as a normal S-Label. This would only be known to a node processed as a normal S-Label. This would only be known to a node
that was a peer of the node imposing the S-Label. However there is that was a peer of the node imposing the S-Label. However, there is
no real need for it to know the payload type during aggregation no real need for it to know the payload type during aggregation
processing. processing.
As in the previous section, nodes supporting this type of aggregation As in the previous section, nodes supporting this type of aggregation
will need to ensure that individual and aggregated flows receive the will need to ensure that individual and aggregated flows receive the
traffic treatment required to ensure the required DetNet service is traffic treatment required to ensure the required DetNet service is
preserved. Also, it is the controller plane's responsibility to preserved. Also, it is the Controller Plane's responsibility to
ensure that the service required on the aggregate flow are properly ensure that the service required on the aggregate flow is properly
provisioned. provisioned.
4.5. Service Sub-Layer Considerations 4.5. Service Sub-Layer Considerations
The edge and relay node internal procedures related to PREOF are The internal procedures for edge and relay nodes related to PREOF are
implementation specific. The order of a packet elimination or implementation specific. The order of a packet elimination or
replication is out of scope in this specification. replication is out of scope for this specification.
It is important that the DetNet layer is configured such that a It is important that the DetNet layer is configured such that a
DetNet node never receives its own replicated packets. If it were to DetNet node never receives its own replicated packets. If it were to
receive such packets the replication function would make the loop receive such packets, the replication function would make the loop
more destructive of bandwidth than a conventional unicast loop. more destructive of bandwidth than a conventional unicast loop.
Ultimately the TTL in the S-Label will cause the packet to die during Ultimately, the TTL in the S-Label will cause the packet to die
a transient loop, but given the sensitivity of applications to packet during a transient loop, but given the sensitivity of applications to
latency the impact on the DetNet application would be severe. To packet latency, the impact on the DetNet application would be severe.
avoid the problem of a transient forwarding loop, changes to an LSP To avoid the problem of a transient forwarding loop, changes to an
supporting DetNet MUST be loop-free. LSP supporting DetNet MUST be loop-free.
4.5.1. Edge Node Processing 4.5.1. Edge Node Processing
A DetNet Edge node operates in the DetNet forwarding sub-layer and A DetNet edge node operates in the DetNet forwarding sub-layer and
service sub-layer. An edge node is responsible for matching incoming service sub-layer. An edge node is responsible for matching incoming
packets to the service they require and encapsulating them packets to the service they require and encapsulating them
accordingly. An edge node may perform PRF, PEF, and or POF. Details accordingly. An edge node may perform PRF, PEF, and/or POF. Details
on encapsulation can be found in Section 4.2; details on PRF can be on encapsulation can be found in Section 4.2; details on PRF can be
found in Section 4.2.2.1; details on PEF can be found in found in Section 4.2.2.1; details on PEF can be found in
Section 4.2.2.2; and details on POF can be found in Section 4.2.2.3. Section 4.2.2.2; and details on POF can be found in Section 4.2.2.3.
4.5.2. Relay Node Processing 4.5.2. Relay Node Processing
A DetNet Relay node operates in the DetNet forwarding sub-layer and A DetNet relay node operates in the DetNet forwarding sub-layer and
service sub-layer. For DetNet using MPLS forwarding related service sub-layer. For DetNet using MPLS, forwarding-related
processing is performed on the F-Label. This processing is done processing is performed on the F-Label. This processing is done
within an extended forwarder function. Whether an incoming DetNet within an extended forwarder function. Whether an incoming DetNet
flow receives DetNet specific processing depends on how the flow receives DetNet-specific processing depends on how the
forwarding is programmed. Some relay nodes may be DetNet service forwarding is programmed. Some relay nodes may be DetNet service
aware for certain DetNet services, while for other DetNet services aware for certain DetNet services, while, for other DetNet services,
these nodes may perform as unmodified LSRs that only understand how these nodes may perform as unmodified LSRs that only understand how
to switch MPLS-TE LSPs, i.e., as a transit node, see Section 4.4. to switch MPLS-TE LSPs, i.e., as a transit node; see Section 4.4.
Again, this is entirely up to how the forwarding has been programmed. Again, this is entirely up to how the forwarding has been programmed.
During the elimination and replication process the sequence number of During the elimination and replication process, the sequence number
an incoming DetNet packet MUST be preserved and carried in the of an incoming DetNet packet MUST be preserved and carried in the
corresponding outgoing DetNet packet. For example, a relay node that corresponding outgoing DetNet packet. For example, a relay node that
performs both PEF and PRF first performs PEF on incoming packets to performs both PEF and PRF first performs PEF on incoming packets to
create a compound flow. It then performs PRF and copies the app-flow create a compound flow. It then performs PRF and copies the App-flow
data and the d-CW into packets for each outgoing DetNet member flow. data and the d-CW into packets for each outgoing DetNet member flow.
The internal design of a relay node is out of scope of this document. The internal design of a relay node is out of scope for this
However the reader's attention is drawn to the need to make any PREOF document. However, the reader's attention is drawn to the need to
state available to the packet processor(s) dealing with packets to make any PREOF state available to the packet processor(s) dealing
which the PREOF functions must be applied, and to maintain that state with packets to which PREOF must be applied and to maintain that
is such a way that it is available to the packet processor operation state in such a way that it is available to the packet processor
on the next packet in the DetNet flow (which may be a duplicate, a operation on the next packet in the DetNet flow (which may be a
late packet, or the next packet in sequence). duplicate, a late packet, or the next packet in sequence).
4.6. Forwarding Sub-Layer Considerations 4.6. Forwarding Sub-Layer Considerations
4.6.1. Class of Service 4.6.1. Class of Service
Class and quality of service, i.e., CoS and QoS, are terms that are Class of Service (CoS) and Quality of Service (QoS) are terms that
often used interchangeably and confused with each other. In the are often used interchangeably and confused with each other. In the
context of DetNet, CoS is used to refer to mechanisms that provide context of DetNet, CoS is used to refer to mechanisms that provide
traffic forwarding treatment based on aggregate group basis and QoS traffic-forwarding treatment based on non-flow-specific traffic
is used to refer to mechanisms that provide traffic forwarding classification, and QoS is used to refer to mechanisms that provide
treatment based on a specific DetNet flow basis. Examples of traffic-forwarding treatment based on DetNet flow-specific traffic
existing network level CoS mechanisms include DiffServ which is classification. Examples of existing network-level CoS mechanisms
enabled by IP header differentiated services code point (DSCP) field include Differentiated Services (Diffserv), which is enabled by the
[RFC2474] and MPLS label traffic class field [RFC5462], and at Layer- IP header Differentiated Services Code Point (DSCP) field [RFC2474]
2, by IEEE 802.1p priority code point (PCP). and MPLS label Traffic Class field [RFC5462] and at Layer 2 by IEEE
802.1p Priority Code Point (PCP).
CoS for DetNet flows carried in PWs and MPLS is provided using the CoS for DetNet flows carried in PWs and MPLS is provided using the
existing MPLS Differentiated Services (DiffServ) architecture existing MPLS Differentiated Services (Diffserv) architecture
[RFC3270]. Both E-LSP and L-LSP MPLS DiffServ modes MAY be used to [RFC3270]. Both E-LSP and L-LSP MPLS Diffserv modes MAY be used to
support DetNet flows. The Traffic Class field (formerly the EXP support DetNet flows. The Traffic Class field (formerly the EXP
field) of an MPLS label follows the definition of [RFC5462] and field) of an MPLS label follows the definition of [RFC5462] and
[RFC3270]. The Uniform, Pipe, and Short Pipe DiffServ tunneling and [RFC3270]. The Uniform, Pipe, and Short Pipe Diffserv tunneling and
TTL processing models are described in [RFC3270] and [RFC3443] and TTL processing models are described in [RFC3270] and [RFC3443] and
MAY be used for MPLS LSPs supporting DetNet flows. MPLS Explicit MAY be used for MPLS LSPs supporting DetNet flows. MPLS Explicit
Congestion Notification (ECN) MAY also be used as defined in ECN Congestion Notification (ECN) MAY also be used, as defined in ECN
[RFC5129] and updated by [RFC5462]. [RFC5129] and updated by [RFC5462].
4.6.2. Quality of Service 4.6.2. Quality of Service
In addition to explicit routes, and packet replication and In addition to explicit routes and packet replication and elimination
elimination, described in Section 4 above, DetNet provides zero (described in Section 4 above), DetNet provides zero congestion loss
congestion loss and bounded latency and jitter. As described in and bounded latency and jitter. As described in [RFC8655], there are
[RFC8655], there are different mechanisms that may be used separately different mechanisms that may be used separately or in combination to
or in combination to deliver a zero congestion loss service. This deliver a zero congestion loss service. This includes QoS mechanisms
includes Quality of Service (QoS) mechanisms at the MPLS layer, that at the MPLS layer, which may be combined with the mechanisms defined
may be combined with the mechanisms defined by the underlying network by the underlying network layer, such as IEEE 802.1 TSN.
layer such as 802.1TSN.
Quality of Service (QoS) mechanisms for flow specific traffic QoS mechanisms for flow-specific traffic treatment typically include
treatment typically includes a guarantee/agreement for the service, a guarantee/agreement for the service and allocation of resources to
and allocation of resources to support the service. Example QoS support the service. Example QoS mechanisms include discrete
mechanisms include discrete resource allocation, admission control, resource allocation, admission control, flow identification and
flow identification and isolation, and sometimes path control, isolation, and sometimes path control, traffic protection, shaping,
traffic protection, shaping, policing and remarking. Example policing, and remarking. Example protocols that support QoS control
protocols that support QoS control include Resource ReSerVation include the Resource ReSerVation Protocol (RSVP) [RFC2205] and RSVP-
Protocol (RSVP) [RFC2205] (RSVP) and RSVP-TE [RFC3209] and [RFC3473]. TE [RFC3209] [RFC3473]. The existing MPLS mechanisms defined to
The existing MPLS mechanisms defined to support CoS [RFC3270] can support CoS [RFC3270] can also be used to reserve resources for
also be used to reserve resources for specific traffic classes. specific traffic classes.
A baseline set of QoS capabilities for DetNet flows carried in PWs A baseline set of QoS capabilities for DetNet flows carried in PWs
and MPLS can be provided by MPLS with Traffic Engineering (MPLS-TE) and MPLS can be provided by MPLS-TE [RFC3209] [RFC3473]. TE LSPs can
[RFC3209] and [RFC3473]. TE LSPs can also support explicit routes also support explicit routes (path pinning). Current service
(path pinning). Current service definitions for packet TE LSPs can definitions for packet TE LSPs can be found in "Specification of the
be found in "Specification of the Controlled Load Quality of Controlled-Load Network Element Service" [RFC2211], "Specification of
Service", [RFC2211], "Specification of Guaranteed Quality of Guaranteed Quality of Service" [RFC2212], and "Ethernet Traffic
Service", [RFC2212], and "Ethernet Traffic Parameters", [RFC6003]. Parameters" [RFC6003]. Additional service definitions are expected
Additional service definitions are expected in future documents to in future documents to support the full range of DetNet services. In
support the full range of DetNet services. In all cases, the all cases, the existing label-based marking mechanisms defined for TE
existing label-based marking mechanisms defined for TE-LSPs and even LSPs and even E-LSPs are used to support the identification of flows
E-LSPs are use to support the identification of flows requiring requiring DetNet QoS.
DetNet QoS.
5. Management and Control Information Summary 5. Management and Control Information Summary
The specific information needed for the processing of each DetNet The specific information needed for the processing of each DetNet
service depends on the DetNet node type and the functions being service depends on the DetNet node type and the functions being
provided on the node. This section summarizes based on the DetNet provided on the node. This section summarizes this information based
sub-layer and if the DetNet traffic is being sent or received. All on the DetNet sub-layer and if the DetNet traffic is being sent or
DetNet node types are DetNet forwarding sub-layer aware, while all received. All DetNet node types are DetNet forwarding sub-layer
but transit nodes are service sub-layer aware. This is shown in aware, while all but transit nodes are service sub-layer aware. This
Figure 2. is shown in Figure 2.
Much like other MPLS labels, there are a number of alternatives Much like other MPLS labels, there are a number of alternatives
available for DetNet S-Label and F-Label advertisement to an upstream available for DetNet S-Label and F-Label advertisement to an upstream
peer node. These include distributed signaling protocols such as peer node. These include distributed signaling protocols (such as
RSVP-TE, centralized label distribution via a controller that manages RSVP-TE), centralized label distribution via a controller that
both the sender and the receiver using NETCONF/YANG, BGP, PCEP, etc., manages both the sender and the receiver using the Network
and hybrid combinations of the two. The details of the controller Configuration Protocol (NETCONF) and YANG, BGP, the Path Computation
plane solution required for the label distribution and the management Element Communication Protocol (PCEP), etc., and hybrid combinations
of the label number space are out of scope of this document. There of the two. The details of the Controller Plane solution required
are particular DetNet considerations and requirements that are for the label distribution and the management of the label number
discussed in [I-D.ietf-detnet-data-plane-framework]. Conformance space are out of scope for this document. Particular DetNet
language is not used in the summary since it applies to future considerations and requirements are discussed in [RFC8938].
mechanisms such as those that may be provided in signaling and YANG Conformance language is not used in the summary, since it applies to
models, e.g., [I-D.ietf-detnet-yang]. future mechanisms, such as those that may be provided in signaling
and YANG models, e.g., [DetNet-YANG].
5.1. Service Sub-Layer Information Summary 5.1. Service Sub-Layer Information Summary
The following summarizes the information that is needed on service The following summarizes the information that is needed (on a per-
sub-layer aware nodes that transmit DetNet MPLS traffic, on a per service basis) on nodes that are service sub-layer aware and transmit
service basis: DetNet MPLS traffic:
o App-Flow identification information, e.g., IP information as * App-flow identification information, e.g., IP information as
defined in [I-D.ietf-detnet-ip-over-mpls]. Note, this information defined in [DetNet-IP-over-MPLS]. Note that this information is
is not needed on DetNet relay nodes. not needed on DetNet relay nodes.
o The sequence number length to be used for the service. Valid * 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 values include 0, 16, and 28 bits. 0 bits cannot be used when PEF
or POF is configured for the service. or POF is configured for the service.
o If PRF is to be provided for the service. * If PRF is to be provided for the service.
o The outgoing S-Label for each of the service's outgoing DetNet * The outgoing S-Label for each of the service's outgoing DetNet
(member) flows. (member) flows.
o The forwarding sub-layer information associated with the output of * The forwarding sub-layer information associated with the output of
the service sub-layer. Note that when the PRF function is the service sub-layer. Note that when PRF is provisioned, this
provisioned, this information is per DetNet member flow. information is per DetNet member flow. Logically, the forwarding
Logically the forwarding sub-layer information is a pointer to sub-layer information is a pointer to further details of
further details of transmission of Detnet flows at the forwarding transmission of DetNet flows at the forwarding sub-layer.
sub-layer.
The following summarizes the information that is needed on service The following summarizes the information that is needed (on a per-
sub-layer aware nodes that receive DetNet MPLS traffic, on a per service basis) on nodes that are service sub-layer aware and receive
service basis: DetNet MPLS traffic:
o The forwarding sub-layer information associated with the input of * The forwarding sub-layer information associated with the input of
the service sub-layer. Note that when the PEF function is the service sub-layer. Note that when PEF is provisioned, this
provisioned, this information is per DetNet member flow. information is per DetNet member flow. Logically, the forwarding
Logically the forwarding sub-layer information is a pointer to sub-layer information is a pointer to further details of the
further details of the reception of Detnet flows at the forwarding reception of DetNet flows at the forwarding sub-layer or A-Label.
sub-layer or A-Label.
o The incoming S-Label for the service. * The incoming S-Label for the service.
o If PEF or POF is to be provided for the service. * If PEF or POF is to be provided for the service.
o The sequence number length to be used for the service. Valid * 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 values included 0, 16, and 28 bits. 0 bits cannot be used when PEF
or POF are configured for the service. or POF are configured for the service.
o App-Flow identification information, e.g., IP information as * App-flow identification information, e.g., IP information as
defined in [I-D.ietf-detnet-ip-over-mpls]. Note, this information defined in [DetNet-IP-over-MPLS]. Note that this information is
is not needed on DetNet relay nodes. not needed on DetNet relay nodes.
5.1.1. Service Aggregation Information Summary 5.1.1. Service Aggregation Information Summary
Nodes performing aggregation using A-Labels, per Nodes performing aggregation using A-Labels, per Section 4.4.2,
Section Section 4.4.2, require the additional information summarized require the additional information summarized in this section.
in this section.
The following summarizes the additional information that is needed on The following summarizes the additional information that is needed on
a node that sends aggregated flows using A-Labels: a node that sends aggregated flows using A-Labels:
o The S-Labels or F-Labels that are to be carried over each * The S-Labels or F-Labels that are to be carried over each
aggregated service. aggregated service.
o The A-Label associated with each aggregated service. * The A-Label associated with each aggregated service.
o The other S-Label information summarized above. * The other S-Label information summarized above.
On the receiving node, the A-Label provides the forwarding context of On the receiving node, the A-Label provides the forwarding context of
an incoming interface or an F-Label and is used in subsequent service an incoming interface or an F-Label and is used in subsequent service
or forwarding sub-layer receive processing, as appropriated. The or forwarding sub-layer receive processing, as appropriate. The
related additional configuration that may be provided is discussed related additional configuration that may be provided is discussed
elsewhere in this section. elsewhere in this section.
5.2. Forwarding Sub-Layer Information Summary 5.2. Forwarding Sub-Layer Information Summary
The following summarizes the information that is needed on forwarding The following summarizes the information that is needed (on a per-
sub-layer aware nodes that send DetNet MPLS traffic, on a per forwarding-sub-layer-flow basis) on nodes that are forwarding sub-
forwarding sub-layer flow basis: layer aware and send DetNet MPLS traffic:
o The outgoing F-Label stack to be pushed. The stack may include * The outgoing F-Label stack to be pushed. The stack may include
H-LSP labels. H-LSP labels.
o The traffic parameters associated with a specific label in the * The traffic parameters associated with a specific label in the
stack. Note that there may be multiple sets of traffic parameters stack. Note that there may be multiple sets of traffic parameters
associated with specific labels in the stack, e.g., when H-LSPs associated with specific labels in the stack, e.g., when H-LSPs
are used. are used.
o Outgoing interface and, for unicast traffic, the next hop * Outgoing interface and, for unicast traffic, the next-hop
information. information.
o Sub-network specific parameters on a technology specific basis. * Sub-network-specific parameters on a technology-specific basis.
For example, see [I-D.ietf-detnet-mpls-over-tsn]. For example, see [DetNet-MPLS-over-TSN].
The following summarizes the information that is needed on forwarding The following summarizes the information that is needed (on a per-
sub-layer aware nodes that receive DetNet MPLS traffic, on a per forwarding-sub-layer-flow basis) on nodes that are forwarding sub-
forwarding sub-layer flow basis: layer aware and receive DetNet MPLS traffic:
o The incoming interface. For some implementations and deployment * The incoming interface. For some implementations and deployment
scenarios, this information may not be needed. scenarios, this information may not be needed.
o The incoming F-Label stack to be popped. The stack may include * The incoming F-Label stack to be popped. The stack may include
H-LSP labels. H-LSP labels.
o How the incoming forwarding sub-layer flow is to be handled, i.e., * 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. forwarded as a transit node or provided to the service sub-layer.
It is the responsibility of the DetNet controller plane to properly It is the responsibility of the DetNet Controller Plane to properly
provision both flow identification information and the flow-specific provision both flow identification information and the flow-specific
resources needed to provided the traffic treatment needed to meet resources needed to provide the traffic treatment needed to meet each
each flow's service requirements. This applies for aggregated and flow's service requirements. This applies for aggregated and
individual flows. individual flows.
6. Security Considerations 6. Security Considerations
Detailed security considerations for DetNet are cataloged in Detailed security considerations for DetNet are cataloged in
[I-D.ietf-detnet-security], and more general security considerations [DetNet-Security], and more general security considerations are
are described in [RFC8655]. This section considers exclusively described in [RFC8655]. This section exclusively considers security
security considerations which are specific to the DetNet MPLS data considerations that are specific to the DetNet MPLS data plane. The
plane. The considerations raised related to MPLS networks in general considerations raised related to MPLS networks in general in
in [RFC5920] are equally applicable to the the DetNet MPLS data [RFC5920] are equally applicable to the DetNet MPLS data plane.
plane.
Security aspects which are unique to DetNet are those whose aim is to Security aspects that are unique to DetNet are those whose aim is to
protect the support of specific quality of service aspects of DetNet, protect the support of specific QoS aspects of DetNet, which are
which are primarily to deliver data flows with extremely low packet primarily to deliver data flows with extremely low packet loss rates
loss rates and bounded end-to-end delivery latency. Achieving such and bounded end-to-end delivery latency. Achieving such loss rates
loss rates and bounded latency may not be possible in the face of a and bounded latency may not be possible in the face of a highly
highly capable adversary, such as the one envisioned by the Internet capable adversary, such as the one envisioned by the Internet Threat
Threat Model of BCP 72 that can arbitrarily drop or delay any or all Model of BCP 72 [RFC3552] that can arbitrarily drop or delay any or
traffic. In order to present meaningful security considerations, we all traffic. In order to present meaningful security considerations,
consider a somewhat weaker attacker who does not control the physical we consider a somewhat weaker attacker who does not control the
links of the DetNet domain, but may have the ability to control a physical links of the DetNet domain but may have the ability to
network node within the boundary of the DetNet domain. control a network node within the boundary of the DetNet domain.
An additional consideration for the DetNet data plane is to maintain An additional consideration for the DetNet data plane is to maintain
integrity of data and delivery of the associated DetNet service integrity of data and delivery of the associated DetNet service
traversing the DetNet network. Application flows can be protected traversing the DetNet network. Application flows can be protected
through whatever means are provided by the underlying technology. through whatever means are provided by the underlying technology.
For example, encryption may be used, such as that provided by IPsec For example, encryption may be used, such as that provided by IPsec
[RFC4301] for IP flows and/or by an underlying sub-net using MACSec [RFC4301] for IP flows and/or by an underlying sub-network using
[IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. MPLS MACsec [IEEE802.1AE-2018] for IP over Ethernet (Layer 2) flows. MPLS
doesn't provide any native security services to account for doesn't provide any native security services to account for
confidentiality and integrity. confidentiality and integrity.
From a data plane perspective this document does not add or modify From a data plane perspective, this document does not add or modify
any application header information. any application header information.
At the management and control level DetNet flows are identified on a At the management and control level, DetNet flows are identified on a
per-flow basis, which may provide controller plane attackers with per-flow basis, which may provide Controller Plane attackers with
additional information about the data flows (when compared to additional information about the data flows (when compared to
controller planes that do not include per-flow identification). This Controller Planes that do not include per-flow identification). This
is an inherent property of DetNet which has security implications is an inherent property of DetNet that has security implications that
that should be considered when determining if DetNet is a suitable should be considered when determining if DetNet is a suitable
technology for any given use case. technology for any given use case.
To provide uninterrupted availability of the DetNet service, To provide uninterrupted availability of the DetNet service,
provisions can be made against DOS attacks and delay attacks. To provisions can be made against DoS attacks and delay attacks. To
protect against DOS attacks, excess traffic due to malicious or protect against DoS attacks, excess traffic due to malicious or
malfunctioning devices is prevented or mitigated through the use of malfunctioning devices is prevented or mitigated through the use of
existing mechanisms, for example by policing and shaping incoming existing mechanisms, for example, by policing and shaping incoming
traffic. To prevent DetNet packets having their delay manipulated by traffic. To prevent DetNet packets from having their delay
an external entity, precautions need to be taken to ensure that all manipulated by an external entity, precautions need to be taken to
devices on an LSP are those intended to be there by the network ensure that all devices on an LSP are those intended to be there by
operator and that they are well behaved. In addition to physical the network operator and that they are well behaved. In addition to
security, technical methods such as authentication and authorization physical security, technical methods, such as authentication and
of network equipment and the instrumentation and monitoring of the authorization of network equipment and the instrumentation and
LSP packet delay may be used. If a delay attack is suspected, monitoring of the LSP packet delay, may be used. If a delay attack
traffic may be moved to an alternate path, for example through is suspected, traffic may be moved to an alternate path, for example,
changing the LSP or management of the PREOF configuration. through changing the LSP or management of the PREOF configuration.
7. IANA Considerations 7. IANA Considerations
This document makes no IANA requests. This document has no IANA actions.
8. Acknowledgements
The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson,
David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David
Mozes, Craig Gunther, George Swallow, Yuanlong Jiang, Jeong-dong Ryoo
and Carlos J. Bernardos for their various contributions to this
work.
9. Contributors
RFC7322 limits the number of authors listed on the front page of a
draft to a maximum of 5. The editor wishes to thank and acknowledge
the following author for contributing text to this draft.
Don Fedyk
LabN Consulting, L.L.C.
Email: dfedyk@labn.net
10. References
10.1. Normative References 8. References
[I-D.ietf-detnet-data-plane-framework] 8.1. Normative References
Varga, B., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "DetNet Data Plane Framework", draft-ietf-detnet-
data-plane-framework-06 (work in progress), May 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load [RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, DOI 10.17487/RFC2211, Network Element Service", RFC 2211, DOI 10.17487/RFC2211,
September 1997, <https://www.rfc-editor.org/info/rfc2211>. September 1997, <https://www.rfc-editor.org/info/rfc2211>.
skipping to change at page 29, line 10 skipping to change at line 1281
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655, "Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019, DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>. <https://www.rfc-editor.org/info/rfc8655>.
10.2. Informative References [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>.
[I-D.ietf-detnet-ip] 8.2. Informative References
Varga, B., Farkas, J., Berger, L., Fedyk, D., and S.
Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-07
(work in progress), July 2020.
[I-D.ietf-detnet-ip-over-mpls] [DetNet-IP-over-MPLS]
Varga, B., Berger, L., Fedyk, D., Bryant, S., and J. Varga, B., Ed., Berger, L., Fedyk, D., Bryant, S., and J.
Korhonen, "DetNet Data Plane: IP over MPLS", draft-ietf- Korhonen, "DetNet Data Plane: IP over MPLS", Work in
detnet-ip-over-mpls-08 (work in progress), September 2020. 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>.
[I-D.ietf-detnet-mpls-over-tsn] [DetNet-MPLS-OAM]
Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet Mirsky, G. and M. Chen, "Operations, Administration and
Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking Maintenance (OAM) for Deterministic Networks (DetNet) with
(TSN)", draft-ietf-detnet-mpls-over-tsn-03 (work in MPLS Data Plane", Work in Progress, Internet-Draft, draft-
progress), June 2020. ietf-detnet-mpls-oam-02, 15 January 2021,
<https://tools.ietf.org/html/draft-ietf-detnet-mpls-oam-
02>.
[I-D.ietf-detnet-security] [DetNet-MPLS-over-TSN]
Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant,
Networking (DetNet) Security Considerations", draft-ietf- "DetNet Data Plane: MPLS over IEEE 802.1 Time Sensitive
detnet-security-12 (work in progress), October 2020. 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>.
[I-D.ietf-detnet-yang] [DetNet-Security]
Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Li, Z., and R. Grossman, E., Ed., Mizrahi, T., and A. Hacker,
Rahman, "Deterministic Networking (DetNet) Configuration "Deterministic Networking (DetNet) Security
YANG Model", draft-ietf-detnet-yang-07 (work in progress), Considerations", Work in Progress, Internet-Draft, draft-
July 2020. 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] [IEEE802.1AE-2018]
IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC IEEE, "IEEE Standard for Local and metropolitan area
Security (MACsec)", 2018, networks-Media Access Control (MAC) Security", IEEE
<https://ieeexplore.ieee.org/document/8585421>. 802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December
2018, <https://ieeexplore.ieee.org/document/8585421>.
[IEEE802.1CB-2017] [IEEE802.1CB-2017]
IEEE Standards Association, "IEEE Std 802.1CB-2017 Frame IEEE, "IEEE Standard for Local and metropolitan area
Replication and Elimination for Reliability", 2017, 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>. <https://ieeexplore.ieee.org/document/8091139>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>. September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X.
Xiao, "Overview and Principles of Internet Traffic Xiao, "Overview and Principles of Internet Traffic
Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002,
<https://www.rfc-editor.org/info/rfc3272>. <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 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985, Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005, DOI 10.17487/RFC3985, March 2005,
<https://www.rfc-editor.org/info/rfc3985>. <https://www.rfc-editor.org/info/rfc3985>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
skipping to change at page 31, line 27 skipping to change at line 1417
Engineering Label Switched Paths", RFC 8306, Engineering Label Switched Paths", RFC 8306,
DOI 10.17487/RFC8306, November 2017, DOI 10.17487/RFC8306, November 2017,
<https://www.rfc-editor.org/info/rfc8306>. <https://www.rfc-editor.org/info/rfc8306>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660, Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019, DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>. <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 wish to thank Pat Thaler, Norman Finn, Loa Anderson,
David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David
Mozes, Craig Gunther, George Swallow, Yuanlong Jiang, Jeong-dong
Ryoo, and Carlos J. Bernardos for their various contributions to this
work.
Contributors
The editor of this document wishes to thank and acknowledge the
following person who contributed substantially to the content of this
document and should be considered a coauthor:
Don Fedyk
LabN Consulting, L.L.C.
Email: dfedyk@labn.net
Authors' Addresses Authors' Addresses
Balazs Varga (editor) Balázs Varga (editor)
Ericsson Ericsson
Budapest
Magyar Tudosok krt. 11. Magyar Tudosok krt. 11.
Budapest 1117 1117
Hungary Hungary
Email: balazs.a.varga@ericsson.com Email: balazs.a.varga@ericsson.com
Janos Farkas János Farkas
Ericsson Ericsson
Budapest
Magyar Tudosok krt. 11. Magyar Tudosok krt. 11.
Budapest 1117 1117
Hungary Hungary
Email: janos.farkas@ericsson.com Email: janos.farkas@ericsson.com
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: lberger@labn.net Email: lberger@labn.net
Andrew G. Malis Andrew G. Malis
Malis Consulting Malis Consulting
Email: agmalis@gmail.com Email: agmalis@gmail.com
Stewart Bryant Stewart Bryant
Futurewei Technologies Futurewei Technologies
Email: stewart.bryant@gmail.com Email: sb@stewartbryant.com
Jouni Korhonen Jouni Korhonen
Email: jouni.nospam@gmail.com Email: jouni.nospam@gmail.com
 End of changes. 228 change blocks. 
625 lines changed or deleted 643 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/