< draft-ietf-detnet-mpls-00.txt   draft-ietf-detnet-mpls-01.txt >
DetNet B. Varga, Ed. DetNet B. Varga, Ed.
Internet-Draft J. Farkas Internet-Draft J. Farkas
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: November 6, 2019 L. Berger Expires: January 2, 2020 L. Berger
D. Fedyk D. Fedyk
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
A. Malis A. Malis
S. Bryant S. Bryant
Huawei Technologies Futurewei Technologies
J. Korhonen J. Korhonen
May 5, 2019 July 1, 2019
DetNet Data Plane: MPLS DetNet Data Plane: MPLS
draft-ietf-detnet-mpls-00 draft-ietf-detnet-mpls-01
Abstract Abstract
This document specifies the Deterministic Networking data plane when This document specifies the Deterministic Networking data plane when
operating over an MPLS Packet Switched Networks. operating over an MPLS Packet Switched Networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 6, 2019. This Internet-Draft will expire on January 2, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5
4. DetNet MPLS Data Plane Overview . . . . . . . . . . . . . . . 5 3. DetNet MPLS Data Plane Overview . . . . . . . . . . . . . . . 5
4.1. Layers of DetNet Data Plane . . . . . . . . . . . . . . . 5 3.1. Layers of DetNet Data Plane . . . . . . . . . . . . . . . 5
4.2. DetNet MPLS Data Plane Scenarios . . . . . . . . . . . . 6 3.2. DetNet MPLS Data Plane Scenarios . . . . . . . . . . . . 6
5. MPLS-Based DetNet Data Plane Solution . . . . . . . . . . . . 8 4. MPLS-Based DetNet Data Plane Solution . . . . . . . . . . . . 8
5.1. DetNet Over MPLS Encapsulation Components . . . . . . . . 8 4.1. DetNet Over MPLS Encapsulation Components . . . . . . . . 8
5.2. MPLS Data Plane Encapsulation . . . . . . . . . . . . . . 9 4.2. MPLS Data Plane Encapsulation . . . . . . . . . . . . . . 9
5.2.1. DetNet Control Word and the DetNet Sequence Number . 10 4.2.1. DetNet Control Word and the DetNet Sequence Number . 10
5.2.2. S-Labels . . . . . . . . . . . . . . . . . . . . . . 12 4.2.2. S-Labels . . . . . . . . . . . . . . . . . . . . . . 11
5.2.3. F-Labels . . . . . . . . . . . . . . . . . . . . . . 14 4.2.3. F-Labels . . . . . . . . . . . . . . . . . . . . . . 14
5.3. OAM Indication . . . . . . . . . . . . . . . . . . . . . 17 4.3. OAM Indication . . . . . . . . . . . . . . . . . . . . . 16
5.4. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 17 4.4. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 17
5.4.1. Aggregation at the LSP . . . . . . . . . . . . . . . 17 4.4.1. Aggregation Via LSP Hierarchy . . . . . . . . . . . . 17
5.4.2. Aggregating DetNet Flows as a new DetNet flow . . . . 18 4.4.2. Aggregating DetNet Flows as a new DetNet flow . . . . 17
5.4.3. Simple Aggregation at the DetNet Layer . . . . . . . 19 4.5. Service Sub-Layer Considerations . . . . . . . . . . . . 19
5.5. Service Sub-Layer Considerations . . . . . . . . . . . . 19 4.5.1. Edge Node Processing . . . . . . . . . . . . . . . . 19
5.5.1. Edge Node Processing . . . . . . . . . . . . . . . . 20 4.5.2. Relay Node Processing . . . . . . . . . . . . . . . . 19
5.5.2. Relay Node Processing . . . . . . . . . . . . . . . . 20 4.6. Forwarding Sub-Layer Considerations . . . . . . . . . . . 20
5.6. Forwarding Sub-Layer Considerations . . . . . . . . . . . 20 4.6.1. Class of Service . . . . . . . . . . . . . . . . . . 20
5.6.1. Class of Service . . . . . . . . . . . . . . . . . . 20 4.6.2. Quality of Service . . . . . . . . . . . . . . . . . 20
5.6.2. Quality of Service . . . . . . . . . . . . . . . . . 21 5. Management and Control Information Summary . . . . . . . . . 21
6. Flow Identification Management and Control Information . . . 22 5.1. Service Sub-Layer Information Summary . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5.1.1. Service Aggregation Information Summary . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5.2. Forwarding Sub-Layer Information Summary . . . . . . . . 23
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . 26 9.1. Normative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 9.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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 these flows extremely low a network to DetNet flows. DetNet provides these flows extremely low
packet loss rates and assured maximum end-to-end delivery latency. packet loss rates and assured maximum end-to-end delivery latency.
General background and concepts of DetNet can be found in General background and concepts of DetNet can be found in
[I-D.ietf-detnet-architecture]. [I-D.ietf-detnet-architecture].
skipping to change at page 4, line 10 skipping to change at page 4, line 10
F-Label A Detnet "forwarding" label that identifies the LSP F-Label A Detnet "forwarding" label that identifies the LSP
used to forward a DetNet flow across an MPLS PSN, e.g., used to forward a DetNet flow across an MPLS PSN, e.g.,
a hop-by-hop label used between label switching routers a hop-by-hop label used between label switching routers
(LSR). (LSR).
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 also the DetNet service sub-layer nodes that implement also the DetNet service sub-layer
functions. An S-Label is also used to identify a functions. An S-Label is also used to identify a
DetNet flow at DetNet service sub-layer. DetNet flow at DetNet service sub-layer.
A-Label A special case of an S-Label, whose aggregation
properties are known only at the aggregation and
deaggregation end-points.
d-CW A DetNet Control Word (d-CW) is used for sequencing d-CW A DetNet Control Word (d-CW) is used for sequencing
information of a DetNet flow at the DetNet service sub- information of a DetNet flow at the DetNet service sub-
layer. layer.
2.2. Abbreviations 2.2. Abbreviations
The following abbreviations are used in this document: The following abbreviations are used in this document:
AC Attachment Circuit.
CE Customer Edge equipment.
CoS Class of Service. CoS Class of Service.
CW Control Word. CW Control Word.
DetNet Deterministic Networking. DetNet Deterministic Networking.
DF DetNet Flow.
DN-IWF DetNet Inter-Working Function.
L2 Layer 2.
L2VPN Layer 2 Virtual Private Network.
L3 Layer 3.
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.
MS-PW Multi-Segment PseudoWire (MS-PW).
NSP Native Service Processing.
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.
skipping to change at page 5, line 25 skipping to change at page 5, line 11
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 Network.
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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
4. DetNet MPLS Data Plane Overview 3. DetNet MPLS Data Plane Overview
4.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 utilised 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 by utilizing existing MPLS Traffic Engineering
encapsulations and mechanisms. Background on PWs can be found in encapsulations and mechanisms. Background on PWs can be found in
[RFC3985] and [RFC3031]. Background on MPLS Traffic Engineering can [RFC3985] and [RFC3031]. Background on MPLS Traffic Engineering can
be found in [RFC3272] and [RFC3209]. be found in [RFC3272] and [RFC3209].
DetNet MPLS DetNet MPLS
. .
Bottom of Stack . Bottom of Stack .
(inner label) +------------+ (inner label) +------------+
| Service | d-CW, S-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 a The service sub-layer includes a DetNet control word (d-CW) and a
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]. [RFC4385]. An aggregation label (A-Label) is a special case of
S-Label used for aggregation.
A node operating on a DetNet flow in the Detnet service sub- A node operating on a DetNet flow in the Detnet service sub-
layer,uses the local context associated with that S-Label, provided layer,uses the local context associated with that S-Label, provided
by a received F-Label, to determine what local DetNet operation(s) by a received F-Label, to determine what local DetNet operation(s)
are applied to that packet. An S-Label may be taken from the are applied to that packet. An S-Label may be taken from the
platform label space [RFC3031], making it unique, enabling DetNet platform label space [RFC3031], making it unique, enabling DetNet
flow identification regardless of which input interface or LSP the flow identification regardless of which input interface or LSP the
packet arrives on. packet arrives on.
The DetNet forwarding sub-layer is supported by one 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 Traffic Engineering
encapsulations and mechanisms can be utilized to provide a forwarding encapsulations and mechanisms can be utilized to provide a forwarding
sub-layer that is responsible for providing resource allocation and sub-layer that is responsible for providing resource allocation and
explicit routes. explicit routes.
4.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|
+-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+ +-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+
skipping to change at page 7, line 31 skipping to change at page 6, line 48
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 system and relay nodes understand the particular needs of DetNet end system 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 nodes add, remove and process functions. In the case of MPLS, DetNet service-aware nodes add,
d-CWs, S-Labels and F-labels as needed. DetNet MPLS nodes provide remove and process d-CWs, S-Labels and F-labels as needed. DetNet
functionality analogous to T-PEs when they sit at the edge of an MPLS MPLS nodes provide functionality analogous to T-PEs when they sit at
domain, and S-PEs when they are in the middle of an MPLS domain, see the edge of an MPLS domain, and S-PEs when they are in the middle of
[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 may be DetNet unaware MPLS Label Switching Routers (LSRs). In
this latter case, such LSRs would be unaware of the special this latter case, such LSRs would be unaware of the special
requirements of the DetNet service sub-layer, but would still provide requirements of the DetNet service sub-layer, but would still provide
traffic engineering functions and the QoS capabilities needed to traffic engineering functions and the QoS capabilities needed to
ensure that the (TE) LSPs meet the service requirements of the ensure that the (TE) LSPs meet the service requirements of the
carried DetNet flows. carried DetNet flows.
The application of DetNet using MPLS supports a number of control The application of DetNet using MPLS supports a number of control
skipping to change at page 8, line 12 skipping to change at page 7, line 28
Routing (when extended to support resource allocation) are all valid Routing (when extended to support resource allocation) are all valid
MPLS deployment cases. MPLS 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 a more detail. In this figure, the customer end systems,
CE1 and CE2, are able to send and receive MPLS encapsulated DetNet CE1 and CE2, are able to send and receive MPLS encapsulated DetNet
flows, and R1, R2 and R3 are relay nodes in the middle of a DetNet flows, and R1, R2 and R3 are relay nodes in the middle of a DetNet
network. The 'X' in the end systems, and relay nodes represents network. The 'X' in the end systems, and relay nodes represents
potential DetNet compound flow packet replication and elimination potential DetNet compound flow packet replication and elimination
points. In this example, service protection is supported utilizing points. In this example, service protection is supported utilizing
least two DetNet member flows and TE LSPs. For a unidirectional at least two DetNet member flows and TE LSPs. For a unidirectional
flow, R1 supports PRF and R3 supports PEF and POF. Note that the flow, R1 supports PRF and R3 supports PEF and POF. Note that the
relay nodes may change the underlying forwarding sub-layer, for relay nodes may change the underlying forwarding sub-layer, for
example tunneling MPLS over IEEE 802.1 TSN example tunneling MPLS over IEEE 802.1 TSN
[I-D.ietf-detnet-mpls-over-tsn], or simply over interconnect network [I-D.ietf-detnet-mpls-over-tsn], or simply over interconnect network
links. links.
DetNet DetNet DetNet DetNet
MPLS Service Transit Transit Service MPLS MPLS Service Transit Transit Service MPLS
DetNet | |<-Tnl->| |<-Tnl->| | DetNet DetNet | |<-Tnl->| |<-Tnl->| | DetNet
End | V 1 V V 2 V | End End | V 1 V V 2 V | End
skipping to change at page 8, line 44 skipping to change at page 8, line 30
| | | |
|<--------------- End to End DetNet Service -------------->| |<--------------- End to End DetNet Service -------------->|
-------------------------- Data Flow -------------------------> -------------------------- Data Flow ------------------------->
X = Optional service protection (none, PRF, PREOF, PEF/POF) X = Optional service protection (none, PRF, PREOF, PEF/POF)
DFx = DetNet member flow x over a TE LSP DFx = DetNet member flow x over a TE LSP
Figure 3: MPLS-Based Native DetNet Figure 3: MPLS-Based Native DetNet
5. MPLS-Based DetNet Data Plane Solution 4. MPLS-Based DetNet Data Plane Solution
5.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 group to the processing 2. A method of identifying the DetNet flow group 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.
skipping to change at page 9, line 39 skipping to change at page 9, line 23
space does not wrap whilst packets are in flight. space does not wrap whilst packets are in flight.
The LSP used to forward the DetNet packet may be of any type (MPLS- The LSP used to forward the DetNet packet may be of any type (MPLS-
LDP, MPLS-TE, MPLS-TP [RFC5921], or MPLS-SR LDP, MPLS-TE, MPLS-TP [RFC5921], or MPLS-SR
[I-D.ietf-spring-segment-routing-mpls]). The LSP (F-Label) label [I-D.ietf-spring-segment-routing-mpls]). The LSP (F-Label) label
and/or the S-Label may be used to indicate the queue processing as and/or the S-Label may be used to indicate the queue processing as
well as the forwarding parameters. Note that the possible use of well as the forwarding parameters. Note that the possible use of
Penultimate Hop Popping (PHP) means that the S-Label may be the only Penultimate Hop Popping (PHP) means that the S-Label may be the only
label received at the terminating DetNet service. label received at the terminating DetNet service.
5.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 [I-D.ietf-detnet-data-plane-framework].
Furthermore, an end to end DetNet service i.e., native DetNet Furthermore, an end to end DetNet service i.e., native DetNet
deployment (see Section 4.2) is also possible if DetNet end systems deployment (see Section 3.2) is also possible if DetNet end systems
are capable of initiating and termination MPLS encapsulated packets. are capable of initiating and termination 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 o 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 o 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.
skipping to change at page 10, line 29 skipping to change at page 10, line 17
+---------------------------------+ +---------------------------------+
| | | |
| DetNet App-Flow | | DetNet App-Flow |
| Payload Packet | | Payload Packet |
| | | |
+---------------------------------+ <--\ +---------------------------------+ <--\
| DetNet Control Word | | | DetNet Control Word | |
+---------------------------------+ +--> DetNet data plane +---------------------------------+ +--> DetNet data plane
| S-Label | | MPLS encapsulation | S-Label | | MPLS encapsulation
+---------------------------------+ | +---------------------------------+ |
| F-Label(s) | | | [ F-Label(s) ] | |
+---------------------------------+ <--/ +---------------------------------+ <--/
| Data-Link | | Data-Link |
+---------------------------------+ +---------------------------------+
| Physical | | Physical |
+---------------------------------+ +---------------------------------+
Figure 4: Encapsulation of a DetNet App-Flow in an MPLS(-TP) PSN Figure 4: Encapsulation of a DetNet App-Flow in an MPLS PSN
5.2.1. DetNet Control Word and the DetNet Sequence Number 4.2.1. DetNet Control Word and the 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. data.
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 |
skipping to change at page 11, line 31 skipping to change at page 11, line 15
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. The following sequence adds the d-CW for each DetNet app-flow. The following sequence
number field lengths MUST be supported: 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 (configured) on a per The sequence number length MUST be provisioned on a per app-flow
app-flow basis via configuration, e.g., the controller plane basis via configuration, i.e., via the controller plane described in
described in [I-D.ietf-detnet-data-plane-framework]. [I-D.ietf-detnet-data-plane-framework].
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). This 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, were the sequence number size is 16 bits, the sequence For example, were the sequence number size is 16 bits, the sequence
will contain: 65535, 0, 1. In this case, zero (0) is an ordinary will contain: 65535, 0, 1, where zero (0) is an ordinary sequence
sequence number. This differs from [RFC4448] where a sequence number number.
of zero (0) does not indicate that no sequence number field value is
in use. It is important to note that this document differs from [RFC4448]
where a sequence number of zero (0) is used to indicate that the
sequence number check algorithm is not used.
The sequence number is optionally used during receive processing as The sequence number is optionally used during receive processing as
described below in Section 5.2.2.1 and Section 5.2.2.2. described below in Section 4.2.2.1 and Section 4.2.2.2.
5.2.2. S-Labels 4.2.2. S-Labels
App-flow identification at a DetNet service sub-layer is realized by App-flow identification at a DetNet service sub-layer is realized by
an S-Label. Each app-flow MUST be sent by the node that adds a d-CW an S-Label. MPLS-aware DetNet end systems and edge nodes, which are
with a single specific S-Label value. MPLS-aware DetNet end systems by definition MPLS ingress and egress nodes, MUST add and remove an
and edge nodes, which are by definition MPLS ingress and egress app-flow specific d-CW and S-Label. Relay nodes MAY swap S-Label
nodes, MUST add and remove the d-CW and S-Label. Relay nodes MAY values when processing an app-flow.
swap S-Label values when processing an app-flow.
The S-Label value MUST be provisioned per app-flow via configuration, The S-Label value MUST be provisioned per app-flow via configuration,
e.g., via the controller plane described in e.g., via the controller plane described in
[I-D.ietf-detnet-data-plane-framework]. Note that S-Labels provide [I-D.ietf-detnet-data-plane-framework]. Note that S-Labels provide
app-flow identification at the downstream DetNet service sub-layer app-flow identification at the downstream DetNet service sub-layer
receiver, not the sender. As such, S-Labels MUST be allocated by the receiver, not the sender. As such, S-Labels MUST be allocated by the
entity that controls the service sub-layer receiving node's label entity that controls the service sub-layer receiving node's label
space, and MAY be allocated from the platform label space [RFC3031]. space, and MAY be allocated from the platform label space [RFC3031].
Because S-Labels are local to each node rather than being a global
identifier within a domain, they must be advertised to their upstream
DetNet service-aware peer nodes (e.g., a DetNet MPLS End System or a
DetNet Relay or Edge Node and interpreted in the context of their
received F-Label.
The S-Label will normally be at the bottom of the label stack once The 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 the last F-Label is removed, immediately preceding the d-CW. To
support service sub-layer level OAM, an OAM Associated Channel Header support service sub-layer level OAM, an OAM Associated Channel Header
(ACH) [RFC4385] together with a Generic Associated Channel Label (ACH) [RFC4385] together with a Generic Associated Channel Label
(GAL) [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/Entropy Label (ELI/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 received ECMP treatment. networks where DetNet flows would otherwise received ECMP treatment.
skipping to change at page 12, line 45 skipping to change at page 12, line 32
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 outlines in same path. However, as outlines in
[I-D.ietf-detnet-data-plane-framework] the use of ECMP for DetNet [I-D.ietf-detnet-data-plane-framework] the use of ECMP for DetNet
flows is NOT RECOMMENDED. ECMP MAY be used for non-DetNet flows flows is NOT RECOMMENDED. ECMP MAY be used for non-DetNet flows
within a DetNet domain. within a DetNet domain.
When receiving a DetNet MPLS flow, an implementation MUST identify When receiving a DetNet MPLS flow, an implementation MUST identify
the app-flow associated with the incoming packet based on the the app-flow 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 app-flow. In the case where platform labels are not used, one or the app-flow. In the case where platform labels are not used, zero
more F-Labels proceeding the S-Label MUST be used together with the or more F-Labels and optionally, the incoming interface, proceeding
S-Label to uniquely identify the incoming app-flows. When PHP is the S-Label MUST be used together with the S-Label to uniquely
used, the incoming interface MAY also be used to together with any identify the app-flows associated with a received packet. The
present F-Label(s) and the S-Label to uniquely identify an incoming incoming interface MAY also be used to together with any present
app-flows. Note that choice to use platform label space for S-Label F-Label(s) and the S-Label to uniquely identify an incoming app-
or S-Label plus one or more F-Labels to identify app flows is a local flows, for example, to in the case where PHP is used. Note that
implementation choice, with one caveat. When one or more F-labels, choice to use platform label space for S-Label or S-Label plus one or
or incoming interface, is needed together with an S-Label to uniquely more F-Labels to identify app flows is a local implementation choice,
identify, the controller plane MUST ensure that incoming DetNet MPLS with one caveat. When one or more F-labels, or incoming interface,
packets arrive with the needed information (F-label(s) and/or is needed together with an S-Label to uniquely identify, the
incoming interface); the details of such are outside the scope of controller plane MUST ensure that incoming DetNet MPLS packets arrive
this document. with the needed information (F-label(s) and/or incoming interface);
the details of such are outside the scope of this document.
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.
5.2.2.1. Packet Elimination Function Processing 4.2.2.1. 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 app-flow MUST be provisioned via configuration, e.g., via particular app-flow MUST be provisioned via configuration, e.g., via
the controller plane described in the controller plane described in
[I-D.ietf-detnet-data-plane-framework]. [I-D.ietf-detnet-data-plane-framework].
After an app-flow is identified for a received DetNet MPLS packet, as After an app-flow is identified for a received DetNet MPLS packet, as
described above, an implementation MUST check if PEF is configured described above, an implementation MUST check if PEF is configured
for that app-flow. When configured the implementation MUST track the for that app-flow. When configured, the implementation MUST track
sequence number contained in received d-CWs and MUST ensure that the sequence number contained in received d-CWs and MUST ensure that
duplicate (replicated) instances of a particular sequence number are duplicate (replicated) instances of a particular sequence number are
discarded. The specific mechanisms used for an implementation to discarded. The specific mechanisms used for an implementation to
identify which received packets are duplicates and which are new is identify which received packets are duplicates and which are new is
an implementation choice. Note that per Section 5.2.1 the sequence an implementation choice. Note that per Section 4.2.1 the sequence
number field length may be 16 or 28 bits, and the field value can number field length may be 16 or 28 bits, and the field value can
wrap. wrap.
Note that an implementation MAY wish to constrain the maximum number Note that an implementation MAY wish to constrain the maximum number
sequence numbers that are tracked, on platform-wide or per flow sequence numbers that are tracked, on platform-wide or per flow
basis. Some implementations MAY support the provisioning of the basis. Some implementations MAY support the provisioning of the
maximum number sequence numbers that are tracked number on either a maximum number sequence numbers that are tracked number on either a
platform-wide or per flow basis. platform-wide or per flow basis.
5.2.2.2. Packet Ordering Function Processing 4.2.2.2. Packet Ordering Function Processing
A function that is related to PEF is the Packet Ordering Function A function that is related to in-order delivery is the Packet
(POF). Implementations MAY support POF. When supported, use of the Ordering Function (POF). Implementations MAY support POF. When
POF for a particular app-flow MUST be provisioned via configuration, supported, use of the POF for a particular app-flow MUST be
e.g., via the controller plane described by provisioned via configuration, e.g., via the controller plane
[I-D.ietf-detnet-data-plane-framework]. Implementations MAY required described by [I-D.ietf-detnet-data-plane-framework]. Implementations
that PEF and POF be used in combination. There is no requirement MAY required that PEF and POF be used in combination. There is no
related to the order of execution of the Packet Elimination and requirement related to the order of execution of the Packet
Ordering Functions in an implementation. Elimination and Ordering Functions in an implementation.
After an app-flow is identified for a received DetNet MPLS packet, as After an app-flow is identified for a received DetNet MPLS packet, as
described above, an implementation MUST check if POF is configured described above, an implementation MUST check if POF is configured
for that app-flow. When configured the implementation MUST track the for that app-flow. When configured, the implementation MUST track
sequence number contained in received d-CWs and MUST ensure that the sequence number contained in received d-CWs and MUST ensure that
packets are processed in the order indicated in the received d-CW packets are processed in the order indicated in the received d-CW
sequence number field, which may not be in the order the packets are sequence number field, which may not be in the order the packets are
received. As defined in Section 5.2.1 the sequence number field received. As defined in Section 4.2.1 the sequence number field
length may be 16 or 28 bits, is incremented by one (1) for each new length may be 16 or 28 bits, is incremented by one (1) for each new
app-flow packet sent, and the field value can wrap. The specific app-flow packet sent, and the field value can wrap. The specific
mechanisms used for an implementation to identify the order of mechanisms used for an implementation to identify the order of
received packets is an implementation choice. received packets is an implementation choice.
Note that an implementation MAY wish to constrain the maximum number Note that an implementation MAY wish to constrain the maximum number
of out of order packets that can be processed, on platform-wide or of out of order packets that can be processed, on platform-wide or
per flow basis. Some implementations MAY support the provisioning of per flow basis. Some implementations MAY support the provisioning of
this number on either a platform-wide or per flow basis. The number this number on either a platform-wide or per flow basis. The number
of out of order packets that can be processed also impacts the of out of order packets that can be processed also impacts the
latency of a flow. latency of a flow.
5.2.3. F-Labels 4.2.3. F-Labels
F-Labels are supported the DetNet forwarding sub-layer. F-Labels are F-Labels are supported the DetNet forwarding sub-layer. F-Labels are
used to provide LSP-based connectivity between DetNet service sub- used to provide LSP-based connectivity between DetNet service sub-
layer processing nodes. layer processing nodes.
5.2.3.1. Service Sub-Layer and Packet Replication Function Processing 4.2.3.1. Service Sub-Layer and Packet Replication Function 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 understand of app-flows and their the DetNet service sub-layer with understand of app-flows and their
requirements. As mentioned earlier, when operating at this layer requirements. As mentioned earlier, when operating at this layer
such nodes can push, pop or swap (pop then push) S-Labels. In all such nodes can push, pop or swap (pop then push) S-Labels. In all
cases, the F-Labels used for the app-flow are always replaced and the cases, the F-Labels used for the app-flow are always replaced and the
following procedures apply. following procedures apply.
When sending a DetNet flow, Zero or more F-Labels MAY be added on top When sending a DetNet flow, zero or more F-Labels MAY be pushed on
of an S-Label by the node pushing an S-Label. The F-Labels to be top of an S-Label by the node pushing an S-Label. The F-Labels to be
pushed when sending a particular app-flow MUST be provisioned per pushed when sending a particular app-flow MUST be provisioned per
app-flow via configuration, e.g., via the controller plane discussed app-flow via configuration, e.g., via the controller plane discussed
in [I-D.ietf-detnet-data-plane-framework]. To allow for the omission in [I-D.ietf-detnet-data-plane-framework]. F-Labels can also provide
of F-Labels, an implementation SHOULD also allow an outgoing context for an S-Label. To allow for the omission of F-Labels, an
interface to be provisioned. implementation SHOULD also allow an outgoing interface to be used.
The Packet Replication Function (PRF) function MAY be supported by an The Packet Replication Function (PRF) function MAY be supported by an
implementation for outgoing DetNet flows. When replication is implementation for outgoing DetNet flows. When replication is
supported, the same app-flow data will be sent over multiple outgoing supported, the same app-flow data will be sent over multiple outgoing
forwarding sub-layer LSPs. To support PRF an implementation MUST forwarding sub-layer LSPs. To support PRF an implementation MUST
support the setting of different sets of F-Labels. Therefore, to support the setting of different sets of F-Labels. To allow for the
allow for the omission of F-Labels, an implementation SHOULD also omission of F-Labels, an implementation SHOULD also allow multiple
allow multiple outgoing interfaces to be provisioned. PRF MUST NOT outgoing interfaces to be provisioned. PRF MUST NOT be used with
be used with app-flows configured with a d-CW sequence number field app-flows configured with a d-CW sequence number field length of 0
length of 0 bits. bits.
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 app-flow, that set of F-labels MUST be pushed after the outgoing app-flow, 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 5.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 5.2.3.2. below in Section 4.2.3.2.
When multiple sets of F-Labels or interfaces are provisioned for a When multiple sets of F-Labels or interfaces are provisioned for a
particular outgoing app-flow, a copy of the outgoing packet, particular outgoing app-flow, a copy of the outgoing packet,
including the pushed S-Label, MUST be made per F-label set and including the pushed S-Label, MUST be made per F-label set and
outgoing interface. Each set of provisioned F-Labels are then pushed outgoing interface. Each set of provisioned F-Labels are then pushed
onto a copy of the packet. Each copy is then forwarded as described onto a copy of the packet. Each copy is then forwarded as described
below in Section 5.2.3.2. 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 app-flow associated with the flow, an implementation identifies the app-flow associated with the
incoming packet based on the S-Label. When a node is using platform incoming packet based on the S-Label. When a node is using platform
labels for S-Labels, any F-Labels can be popped and the S-label labels for S-Labels, any F-Labels can be popped and the S-label
uniquely identifies the app-flow. In the case where platform labels uniquely identifies the app-flow. In the case where platform labels
are not used, F-Label(s) MUST also be provisioned for incoming app- are not used, F-Label(s) and, optionally, the incoming interface MUST
flows. When PHP is used, incoming interface MUST be provisioned. also be provisioned for incoming app-flows. The provisioned
The provisioned information MUST then be used to identify incoming information MUST then be used to identify incoming app-flows based on
app-flows based on the combination of S-Label and F-Label(s) or the combination of S-Label and F-Label(s) or incoming interface.
incoming interface.
5.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 swap
operations. Such processing is essentially the same type of operations. Such processing is essentially the same type of
processing enabled 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 app-flow or flows carried in an LSP service parameters of the app-flow or flows carried in an LSP
represented by an F-Label can be met by an exiting TE mechanism, the represented by an F-Label can be met by an exiting 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, [RFC3209], [RFC3270], [RFC3272],
[RFC3473], [RFC4875], [RFC5440], and [RFC6006]. [RFC3473], [RFC4875], [RFC5440], and [RFC6006].
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 is 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 next
hop LSR. hop LSR.
Resources may be allocated in a hierarchical fashion per LSP that is Resources may be allocated in a hierarchical fashion per LSP that is
represented by each F-Label. Each LSP MAY be provisioned with a represented by each F-Label. Each LSP MAY be provisioned with a
service parameters that dictates the specific traffic treatment to be service parameters that dictates the specific traffic treatment to be
received by the traffic carried over that LSP. Implementations of received by the traffic carried over that LSP. Implementations of
this document MUST ensure that traffic carried over each LSP this document MUST ensure that traffic carried over each LSP
represented by an F-Label receives the traffic treatment provisioned represented by one or more F-Labels receives the traffic treatment
for that LSP. Typical mechanisms used to provide different treatment provisioned for that LSP. Typical mechanisms used to provide
to different flows includes the allocation of system resources (such different treatment to different flows includes the allocation of
as queues and buffers) and provisioning or related parameters (such system resources (such as queues and buffers) and provisioning or
as shaping, and policing). Support can also be provided via an related parameters (such as shaping, and policing). Support can also
underlying network technology such IEEE802.1 TSN be provided via an underlying network technology such IEEE802.1 TSN
[I-D.ietf-detnet-mpls-over-tsn]. Other than in the TSN case, the [I-D.ietf-detnet-mpls-over-tsn]. The specific mechanisms used by a
specific mechanisms used by a DetNet node to ensure DetNet service DetNet node to ensure DetNet service delivery requirements are met
delivery requirements are met for supported DetNet flows is outside for supported DetNet flows is outside the scope of this document.
the scope of this document.
Packets that are marked in a way that does not correspond to Packets that are marked in a way that do not correspond to allocated
allocated resources, e.g., lack a provisioned F-Label, can disrupt resources, e.g., lack a provisioned F-Label, can disrupt the QoS
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 o 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 non-competing 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 o 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
skipping to change at page 17, line 6 skipping to change at page 16, line 40
o MUST ensure a QoS flow does not exceed its allocated resources or o 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 o 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
requirement for MPLS LSRs to that CoS LSPs do not impact the requirement for MPLS LSRs to 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 5.6.1), QoS (Section 5.6.2) and aggregation (Section 5.4). (Section 4.6.1), QoS (Section 4.6.2) and aggregation (Section 4.4).
5.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-DW is an OAM payload with the OAM type indicated by the value the d-DW 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. for more information DetNet OAM.
5.4. Flow Aggregation 4.4. Flow Aggregation
[Author's note: need to revisit this section and ensure that we cover
(and fully specify) desired types of aggregation.]
1. Aggregate at the LSP (Forwarding)
2. Aggregating DetNet flows as a new DetNet flow
3. Simple Aggregation at the DetNet layer
The resource control and management aspects of aggregation (including
the queuing/shaping/ policing implications) will be covered in other
documents.
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 three methods of introducing flows, to improved scaling. There are two methods of supporting flow
flow aggregation: aggregation covered in this section.
5.4.1. Aggregation at the LSP The resource control and management aspects of aggregation (including
the configuration of queuing, shaping, and policing) are the
responsibility of the DetNet controller plane and is out of scope of
this documents. It is also the responsibility of the controller
plane to ensure that consistent aggregation methods are used.
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 falls out of the definition for
hierarchy and the MPLS label stack [RFC3032]. DetNet nodes which hierarchy and the MPLS label stack [RFC3032]. DetNet nodes which
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. Such nodes will need to use the TC field, i.e., L-LSPs or E-LSPs. Such nodes will need to
ensure that traffic from aggregated LSPs are placed (shaped/policed/ ensure that individual LSPs and H-LSPs receive the traffic treatment
enqueued) onto the H-LSPs in a fashion that ensures the required required to ensure the required DetNet service is preserved.
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 descriptions 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 (H-LSP or DSCP) are provided, which may include the aggregate flow are provided, which may include the discarding or
discarding or remarking mentioned in the previous sections. remarking mentioned in the previous sections.
5.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 as shown below: An aggregate can be built by layering DetNet flows, including both
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 | |
+---------------------------------+ +----DetNet data plane +---------------------------------+ |
| DetNet Control Word | | MPLS encapsulation | [ F-Label(s) ] | +----DetNet data plane
+---------------------------------+ |
| DetNet Control Word | |
+=================================+ | +=================================+ |
| 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 (A) label and the S-Label have their MPLS S bit Both the aggregation label, which is referred to as an A-Label, and
set indicating bottom of stack, and the d-CW allows the PREOF to the individual flow's S-Label have their MPLS S bit set indicating
work. bottom of stack, and the d-CW allows the PREOF to work. An A-Label
is a special case of an S-Label, whose properties are known only at
It is a property of the A-label that what follows is d-CW followed by the aggregation and deaggregation end-points.
an S-Label. A relay node processing the A-label would not know the
underlying payload type. This would only be known to a node 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 processing.
5.4.3. Simple Aggregation at the DetNet Layer
Another approach would be not to include a d-CW for the aggregated
flow. This would be functionally similar to aggregation at the
forwarding sub-layer using H-LSPs, but would confine knowledge of the
aggregation to the DetNet layer. Such an approach shares the
disadvantage that PREOF operations would not be possible. OAM
operation in this mode is for further study.
+---------------------------------+ 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
| DetNet Flow | not know the underlying payload type, and the A-Label would be
| Payload Packet | process 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 no
+---------------------------------+ <--\ real need for it to know the payload type during aggregation
| DetNet Control Word | | processing.
+=================================+ |
| S-Label | +----DetNet data plane
+---------------------------------+ | MPLS encapsulation
| A-Label | |
+---------------------------------+ |
| F-Label(s) | <--/
+---------------------------------+
| Data-Link |
+---------------------------------+
| Physical |
+---------------------------------+
Figure 7: Simple DetNet Aggregation As in the previous section, nodes supporting this type of aggregation
will need to ensure that individual and aggregated flows receive the
traffic treatment required to ensure the required DetNet service is
preserved. Also, it is the controller plane's responsibility to to
ensure that the service required on the aggregate flow are properly
provisioned.
5.5. Service Sub-Layer Considerations 4.5. Service Sub-Layer Considerations
The edge and relay node internal procedures related to PREOF are The edge and relay node internal procedures 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 in 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 during
a transient loop, but given the sensitivity of applications to packet a transient loop, but given the sensitivity of applications to packet
latency the impact on the DetNet application would be severe. latency the impact on the DetNet application would be severe. To
avoid the problem of a transient forwarding loop, changes to an LSP
supporting DetNet MUST be loop-free.
5.5.1. Edge Node Processing 4.5.1. Edge Node Processing
An edge node is responsible for matching ingress packets to the An edge node is responsible for matching ingress packets to the
service they require and encapsulating them accordingly. An edge service they require and encapsulating them accordingly. An edge
node may participate in the packet replication and duplicate packet node may participate in the packet replication and duplicate packet
elimination. elimination.
The DetNet-aware forwarder selects the egress DetNet member flow The DetNet-aware forwarder selects the egress DetNet member flow
segment based on the flow identification. The mapping of ingress segment based on the flow identification. The mapping of ingress
DetNet member flow segment to egress DetNet member flow segment may DetNet member flow segment to egress DetNet member flow segment may
be statically or dynamically configured. Additionally the DetNet- be statically or dynamically configured. Additionally the DetNet-
skipping to change at page 20, line 31 skipping to change at page 19, line 47
member flow. 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 of this document.
However the reader's attention is drawn to the need to make any PREOF However the reader's attention is drawn to the need to make any PREOF
state available to the packet processor(s) dealing with packets to state available to the packet processor(s) dealing with packets to
which the PREOF functions must be applied, and to maintain that state which the PREOF functions must be applied, and to maintain that state
is such as way that it is available to the packet processor operation is such as way that it is available to the packet processor operation
on the next packet in the DetNet flow (which may be a duplicate, a on the next packet in the DetNet flow (which may be a duplicate, a
late packet, or the next packet in sequence. late packet, or the next packet in sequence.
5.5.2. Relay Node Processing 4.5.2. Relay Node Processing
A DetNet Relay node operates in the DetNet forwarding sub-layer . A DetNet Relay node operates in the DetNet forwarding sub-layer .
For DetNet using MPLS this processing is performed on the F-Label. For DetNet using MPLS this processing is performed on the F-Label.
This processing is done within an extended forwarder function. This processing is done within an extended forwarder function.
Whether an ingress DetNet member flow receives DetNet specific Whether an ingress DetNet member flow receives DetNet specific
processing depends on how the forwarding is programmed. Some relay processing depends on how the forwarding is programmed. Some relay
nodes may be DetNet service aware, while others may be unmodified nodes may be DetNet service aware, while others may be unmodified
LSRs that only understand how to swicth MPLS-TE LSPs. LSRs that only understand how to switch MPLS-TE LSPs.
It is also possible to treat the relay node as a transit node, see It is also possible to treat the relay node as a transit node, see
Section 5.4. Again, this is entirely up to how the forwarding has Section 4.4. Again, this is entirely up to how the forwarding has
been programmed. been programmed.
5.6. Forwarding Sub-Layer Considerations 4.6. Forwarding Sub-Layer Considerations
5.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 and quality of service, i.e., CoS and QoS, are terms that are
often used interchangeably and confused with each other. In the 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 aggregate group basis and QoS
is used to refer to mechanisms that provide traffic forwarding is used to refer to mechanisms that provide traffic forwarding
treatment based on a specific DetNet flow basis. Examples of treatment based on a specific DetNet flow basis. Examples of
existing network level CoS mechanisms include DiffServ which is existing network level CoS mechanisms include DiffServ which is
enabled by IP header differentiated services code point (DSCP) field enabled by IP header differentiated services code point (DSCP) field
[RFC2474] and MPLS label traffic class field [RFC5462], and at Layer- [RFC2474] and MPLS label traffic class field [RFC5462], and at Layer-
skipping to change at page 21, line 21 skipping to change at page 20, line 37
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 ECN MAY also MAY be used for MPLS LSPs supporting DetNet flows. MPLS ECN MAY also
be used as defined in ECN [RFC5129] and updated by [RFC5462]. be used as defined in ECN [RFC5129] and updated by [RFC5462].
5.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, described in Section 5 above, DetNet provides zero elimination, described in Section 4 above, DetNet provides zero
congestion loss and bounded latency and jitter. As described in congestion loss and bounded latency and jitter. As described in
[I-D.ietf-detnet-architecture], there are different mechanisms that [I-D.ietf-detnet-architecture], there are different mechanisms that
maybe used separately or in combination to deliver a zero congestion maybe used separately or in combination to deliver a zero congestion
loss service. This includes Quality of Service (QoS) mechanisms at loss service. This includes Quality of Service (QoS) mechanisms at
the MPLS layer, that may be combined with the mechanisms defined by the MPLS layer, that may be combined with the mechanisms defined by
the underlying network layer such as 802.1TSN. the underlying network layer such as 802.1TSN.
Quality of Service (QoS) mechanisms for flow specific traffic Quality of Service (QoS) mechanisms for flow specific traffic
treatment typically includes a guarantee/agreement for the service, treatment typically includes a guarantee/agreement for the service,
and allocation of resources to support the service. Example QoS and allocation of resources to support the service. Example QoS
skipping to change at page 22, line 8 skipping to change at page 21, line 24
(path pinning). Current service definitions for packet TE LSPs can (path pinning). Current service definitions for packet TE LSPs can
be found in "Specification of the Controlled Load Quality of be found in "Specification of the Controlled Load Quality of
Service", [RFC2211], "Specification of Guaranteed Quality of Service", [RFC2211], "Specification of Guaranteed Quality of
Service", [RFC2212], and "Ethernet Traffic Parameters", [RFC6003]. Service", [RFC2212], and "Ethernet Traffic Parameters", [RFC6003].
Additional service definitions are expected in future documents to Additional service definitions are expected in future documents to
support the full range of DetNet services. In all cases, the support the full range of DetNet services. In all cases, the
existing label-based marking mechanisms defined for TE-LSPs and even existing label-based marking mechanisms defined for TE-LSPs and even
E-LSPs are use to support the identification of flows requiring E-LSPs are use to support the identification of flows requiring
DetNet QoS. DetNet QoS.
6. Flow Identification Management and Control Information 5. Management and Control Information Summary
[Editor's Note] The following will summarize the set of information The specific information needed for the processing of each DetNet
that is needed to support the MPLS DetNet data plane. service depends on the DetNet node type and the functions being
provided on the node. This section summarizes based on the DetNet
sub-layer and if the DetNet traffic is being sent or received. All
DetNet node types are DetNet forwarding sub-layer aware, while all
but transit nodes are service sub-layer aware. This is shown in
Figure 2.
7. Security Considerations Much like other MPLS labels, there are a number of alternatives
available for DetNet S-Label and F-Label advertisement to an upstream
peer node. These include distributed signaling protocols such as
RSVP-TE, centralized label distribution via a controller that manages
both the sender and the receiver using NETCONF/YANG, BGP, PCEP, etc.,
and hybrid combinations of the two. The details of the controller
plane solution required for the label distribution and the management
of the label number space are out of scope of this document. There
are particular DetNet considerations and requirements that are
discussed in [I-D.ietf-detnet-data-plane-framework].
The security considerations of DetNet in general are discussed in 5.1. Service Sub-Layer Information Summary
[I-D.ietf-detnet-architecture] and [I-D.sdt-detnet-security]. Other
security considerations will be added in a future version of this
draft.
8. IANA Considerations The following summarizes the information that is needed on service
sub-layer aware nodes that send DetNet MPLS traffic, on a per service
basis:
This document makes no IANA requests. o App-Flow identification information, e.g., an incoming service on
a relay node or IP information as defined in
[I-D.ietf-detnet-ip-over-mpls].
9. Contributors o The sequence number length to be used for the service. Valid
values included 0, 16 and 28 bits. 0 bits cannot be used when PRF
is configured for the service.
RFC7322 limits the number of authors listed on the front page of a o The S-Label for the service.
draft to a maximum of 5, far fewer than the many individuals below
who made important contributions to this draft. The editor wishes to
thank and acknowledge each of the following authors for contributing
text to this draft. See also Section 10.
Loa Andersson o If PRF is to be provided for the service.
Huawei
Email: loa@pi.nu
Yuanlong Jiang o The forwarding sub-layer information associated with the output of
Huawei the service sub-layer. Note that when the PRF function is
Email: jiangyuanlong@huawei.com provisioned, this information is per DetNet member flow.
Logically this is a pointer to details provided below for
transmission of Detnet flows at the forwarding sub-layer.
Norman Finn The following summarizes the information that is needed on service
Huawei sub-layer aware nodes that receives DetNet MPLS traffic, on a per
3101 Rio Way service basis:
Spring Valley, CA 91977
USA
Email: norman.finn@mail01.huawei.com
Janos Farkas o The forwarding sub-layer information associated with the input of
Ericsson the service sub-layer. Note that when the PEF function is
Magyar Tudosok krt. 11. provisioned, this information is per DetNet member flow.
Budapest 1117 Logically this is a pointer to details provided below related to
Hungary the reception of Detnet flows at the forwarding sub-layer or
Email: janos.farkas@ericsson.com A-Label.
Carlos J. Bernardos o The S-Label for the received service.
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Email: cjbc@it.uc3m.es
Tal Mizrahi o If PEF or POF is to be provided for the service.
Marvell
6 Hamada st.
Yokneam
Israel
Email: talmi@marvell.com
Lou Berger o The sequence number length to be used for the service. Valid
LabN Consulting, L.L.C. values included 0, 16 and 28 bits. 0 bits cannot be used when PEF
Email: lberger@labn.net or POF are configured for the service.
Stewart Bryant 5.1.1. Service Aggregation Information Summary
Huawei Technologies
Email: stewart.bryant@gmail.com
Mach Chen Nodes performing aggregation using A-Labels, per
Huawei Technologies Section Section 4.4.2, require the additional information summarized
Email: mach.chen@huawei.com in this section.
Andrew G. Malis The following summarizes the information that is needed on a node
Huawei Technologies that sends aggregated flows using A-Labels:
Email: agmalis@gmail.com
Don Fedyk o The S-Labels or F-Labels that are to be carried over each
LabN Consulting, L.L.C. aggregated service.
Email: dfedyk@labn.net
10. Acknowledgements o The A-Label associated with each aggregated service.
The author(s) ACK and NACK. o The other S-Label information summarized above.
The following people were part of the DetNet Data Plane Solution On the receiving node, the A-Label provides the forwarding context of
Design Team: an incoming interface or an F-Label and is used in subsequent service
or forwarding sub-layer receive processing, as appropriated. The
related addition configuration that may be provided discussed
elsewhere in this section.
Jouni Korhonen 5.2. Forwarding Sub-Layer Information Summary
Janos Farkas The following summarizes the information that is needed on forwarding
sub-layer aware nodes that send DetNet MPLS traffic, on a per
forwarding sub-layer flow basis:
Norman Finn o The outgoing F-Label stack to be pushed. The stack may include
Balazs Varga H-LSP labels.
Loa Andersson o The traffic parameters associated with a specific label in the
stack. Note that there may be multiple sets of traffic paramters
associated with specific labels in the stack, e.g., when H-LSPs
are used.
Tal Mizrahi o Outgoing interface and, for unicast traffic, the next hop
information.
David Mozes o Sub-network specific parameters on a technology specific basis.
For example, see [I-D.ietf-detnet-mpls-over-tsn].
Yuanlong Jiang The following summarizes the information that is needed on forwarding
sub-layer aware nodes that receive DetNet MPLS traffic, on a per
forwarding sub-layer flow basis:
Andrew Malis o The incoming interface. For some implementations and deployment
scenarios, this information may not be needed.
Carlos J. Bernardos o The incoming F-Label stack to be popped. The stack may include
H-LSP labels.
The DetNet chairs serving during the DetNet Data Plane Solution o How the incoming forwarding sub-layer flow is to be handled, i.e.,
Design Team: forwarded as a transit node, or provided to the service sub-layer.
Lou Berger It is the responsibility of the DetNet controller plane to properly
provision both flow identification information and the flow specific
resources needed to provided the traffic treatment needed to meet
each flow's service requirements. This applies for aggregated and
individual flows.
Pat Thaler 6. Security Considerations
Thanks for Stewart Bryant for his extensive review of the previous Security considerations for DetNet are described in detail in
versions of the document. [I-D.ietf-detnet-security]. General security considerations are
described in [I-D.ietf-detnet-architecture]. This section considers
exclusively security considerations which are specific to the DetNet
MPLS data plane.
11. References Security aspects which are unique to DetNet are those whose aim is to
provide the specific quality of service aspects of DetNet, which are
primarily to deliver data flows with extremely low packet loss rates
and bounded end-to-end delivery latency.
11.1. Normative References The primary considerations for the data plane is to maintain
integrity of data and delivery of the associated DetNet service
traversing the DetNet network. Application flows can be protected
through whatever means is provided by the underlying technology. 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
[IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows.
From a data plane perspective this document does not add or modify
any header information.
At the management and control level DetNet flows are identified on a
per-flow basis, which may provide controller plane attackers with
additional information about the data flows (when compared to
controller planes that do not include per-flow identification). This
is an inherent property of DetNet which has security implications
that should be considered when determining if DetNet is a suitable
technology for any given use case.
To provide uninterrupted availability of the DetNet service,
provisions can be made against DOS attacks and delay attacks. To
protect against DOS attacks, excess traffic due to malicious or
malfunctioning devices can be prevented or mitigated, for example
through the use of existing mechanism such as policing and shaping
applied at the input of a DetNet domain. To prevent DetNet packets
from being delayed by an entity external to a DetNet domain, DetNet
technology definition can allow for the mitigation of Man-In-The-
Middle attacks, for example through use of authentication and
authorization of devices within the DetNet domain.
7. IANA Considerations
This document makes no IANA requests.
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 and Carlos J.
Bernardos for their various contributions to this work.
9. References
9.1. Normative References
[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 26, line 14 skipping to change at page 26, line 45
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/info/rfc5462>. 2009, <https://www.rfc-editor.org/info/rfc5462>.
[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>.
11.2. Informative References 9.2. Informative References
[I-D.ietf-detnet-architecture] [I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas, Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf- "Deterministic Networking Architecture", draft-ietf-
detnet-architecture-12 (work in progress), March 2019. detnet-architecture-13 (work in progress), May 2019.
[I-D.ietf-detnet-data-plane-framework] [I-D.ietf-detnet-data-plane-framework]
Korhonen, J., Varga, B., "DetNet Data Plane Framework", Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
2019. Bryant, S., and J. Korhonen, "DetNet Data Plane
Framework", draft-ietf-detnet-data-plane-framework-00
(work in progress), May 2019.
[I-D.ietf-detnet-ip-over-mpls]
Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S.,
and J. Korhonen, "DetNet Data Plane: IP over MPLS", draft-
ietf-detnet-ip-over-mpls-00 (work in progress), May 2019.
[I-D.ietf-detnet-mpls-over-tsn] [I-D.ietf-detnet-mpls-over-tsn]
Korhonen, J., Varga, B., "DetNet MPLS over IEEE 802.1 TSN Varga, B., Farkas, J., Malis, A., Bryant, S., and J.
Sub-Networks", 2019. Korhonen, "DetNet Data Plane: MPLS over IEEE 802.1 Time
Sensitive Networking (TSN)", draft-ietf-detnet-mpls-over-
tsn-00 (work in progress), May 2019.
[I-D.ietf-detnet-security]
Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,
J., Austad, H., Stanton, K., and N. Finn, "Deterministic
Networking (DetNet) Security Considerations", draft-ietf-
detnet-security-04 (work in progress), March 2019.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-22 data plane", draft-ietf-spring-segment-routing-mpls-22
(work in progress), May 2019. (work in progress), May 2019.
[I-D.sdt-detnet-security] [IEEE802.1AE-2018]
Mizrahi, T., Grossman, E., Hacker, A., Das, S., IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC
"Deterministic Networking (DetNet) Security Security (MACsec)", 2018,
Considerations, draft-sdt-detnet-security, work in <https://ieeexplore.ieee.org/document/8585421>.
progress", 2017.
[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,
skipping to change at page 27, line 15 skipping to change at page 28, line 15
[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>.
[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
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS "Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
<https://www.rfc-editor.org/info/rfc4448>. <https://www.rfc-editor.org/info/rfc4448>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to- Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875, Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007, DOI 10.17487/RFC4875, May 2007,
skipping to change at page 28, line 42 skipping to change at page 30, line 4
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: lberger@labn.net Email: lberger@labn.net
Don Fedyk Don Fedyk
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: dfedyk@labn.net Email: dfedyk@labn.net
Andrew G. Malis Andrew G. Malis
Huawei Technologies Futurewei Technologies
Email: agmalis@gmail.com Email: agmalis@gmail.com
Stewart Bryant Stewart Bryant
Huawei Technologies Futurewei Technologies
Email: stewart.bryant@gmail.com Email: stewart.bryant@gmail.com
Jouni Korhonen Jouni Korhonen
Email: jouni.nospam@gmail.com Email: jouni.nospam@gmail.com
 End of changes. 126 change blocks. 
335 lines changed or deleted 388 lines changed or added

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