draft-ietf-detnet-data-plane-framework-00.txt   draft-ietf-detnet-data-plane-framework-01.txt 
DetNet B. Varga, Ed. DetNet B. Varga, Ed.
Internet-Draft J. Farkas Internet-Draft J. Farkas
Intended status: Informational Ericsson Intended status: Informational 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 Framework DetNet Data Plane Framework
draft-ietf-detnet-data-plane-framework-00 draft-ietf-detnet-data-plane-framework-01
Abstract Abstract
This document provides an overall framework for the Deterministic This document provides an overall framework for the Deterministic
Networking data plane. It covers concepts and considerations that Networking data plane. It covers concepts and considerations that
are generally common to any Deterministic Networking data plane are generally common to any Deterministic Networking data plane
specification. specification.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Terms Used in This Document . . . . . . . . . . . . . . . 4 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
3. DetNet Data Plane Overview . . . . . . . . . . . . . . . . . 5 3. DetNet Data Plane Overview . . . . . . . . . . . . . . . . . 4
3.1. Data Plane Characteristics . . . . . . . . . . . . . . . 6 3.1. Data Plane Characteristics . . . . . . . . . . . . . . . 6
3.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. DetNet Specific Metadata . . . . . . . . . . . . . . . . 7
3.4. DetNet IP Data Plane . . . . . . . . . . . . . . . . . . 8 3.4. DetNet IP Data Plane . . . . . . . . . . . . . . . . . . 8
3.5. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . 8 3.5. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . 8
3.6. Further DetNet Data Plane Considerations . . . . . . . . 9 3.6. Further DetNet Data Plane Considerations . . . . . . . . 9
3.6.1. Service Protection . . . . . . . . . . . . . . . . . 11 3.6.1. Service Protection . . . . . . . . . . . . . . . . . 11
3.6.2. Aggregation Considerations . . . . . . . . . . . . . 13 3.6.2. Aggregation Considerations . . . . . . . . . . . . . 13
3.6.3. End-System Specific Considerations . . . . . . . . . 14 3.6.3. End-System Specific Considerations . . . . . . . . . 14
3.6.4. Sub-Network Considerations . . . . . . . . . . . . . 14 3.6.4. Sub-Network Considerations . . . . . . . . . . . . . 14
4. Controller Plane (Management and Control) 4. Controller Plane (Management and Control)
Considerations . . . . . . . . . . . . . . . . . . . . . . . 15 Considerations . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. DetNet Controller Plane Requirements . . . . . . . . . . 15 4.1. DetNet Controller Plane Requirements . . . . . . . . . . 15
4.2. Generic Controller Plane Considerations . . . . . . . . . 16 4.2. Generic Controller Plane Considerations . . . . . . . . . 16
4.2.1. Flow Aggregation Control . . . . . . . . . . . . . . 17 4.2.1. Flow Aggregation Control . . . . . . . . . . . . . . 17
4.2.2. Explicit Routes . . . . . . . . . . . . . . . . . . . 18 4.2.2. Explicit Routes . . . . . . . . . . . . . . . . . . . 18
4.2.3. Contention Loss and Jitter Reduction . . . . . . . . 19 4.2.3. Contention Loss and Jitter Reduction . . . . . . . . 19
4.2.4. Bidirectional Traffic . . . . . . . . . . . . . . . . 19 4.2.4. Bidirectional Traffic . . . . . . . . . . . . . . . . 19
4.3. IP-Specific Controller Plane Considerations . . . . . . . 20 4.3. Packet Replication, Elimination, and Ordering (PREOF) . . 20
4.3.1. Flow Identification and Aggregation . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
4.4. MPLS-Specific Controller Plane Considerations . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
4.4.1. S-Label and F-Label Assignment and Distribution . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
4.5. Packet Replication, Elimination, and Ordering (PREOF) . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.6. Contention Loss and Jitter Reduction . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Deterministic Networking (DetNet) provides a capability to carry Deterministic Networking (DetNet) provides a capability to carry
specified unicast or multicast data flows for real-time applications specified unicast or multicast data flows for real-time applications
with extremely low packet loss rates and assured maximum end-to-end with extremely low packet loss rates and assured maximum end-to-end
delivery latency. A description of the general background and delivery latency. A description of the general background and
concepts of DetNet can be found in [I-D.ietf-detnet-architecture]. concepts of DetNet can be found in [I-D.ietf-detnet-architecture].
This document describes the concepts needed by any DetNet data plane This document describes the concepts needed by any DetNet data plane
specification and provides considerations for any corresponding specification and provides considerations for any corresponding
implementation. It covers the building blocks that provide the implementation. It covers the building blocks that provide the
DetNet service, the forwarding sub-layer functions, and the flow DetNet service, the DetNet service sub-layer and the DetNet
identification as described in the DetNet Architecture. forwarding sub-layer functions as described in the DetNet
Architecture.
The DetNet Architecture models the DetNet related data plane The DetNet Architecture models the DetNet related data plane
functions decomposed into two sub-layers: a service sub-layer and a functions decomposed into two sub-layers: a service sub-layer and a
forwarding sub-layer. The service sub-layer is used to provide forwarding sub-layer. The service sub-layer is used to provide
DetNet service protection and reordering. The forwarding sub-layer DetNet service protection and reordering. The forwarding sub-layer
is used to provide congestion protection (low loss, assured latency, is used to provide congestion protection (low loss, assured latency,
and limited reordering) and leverages Traffic Engineering mechanisms. and limited out-of-order delivery) and leverages Traffic Engineering
mechanisms.
As part of the service sub-layer functions, this document describes As part of the service sub-layer functions, this document describes
typical DetNet node data plane operation. It describes the function typical DetNet node data plane operation. It describes the function
and operation of the Packet Replication (PRF) Packet Elimination and operation of the Packet Replication (PRF) Packet Elimination
(PEF) and the Packet Ordering (POF) functions within the service sub- (PEF) and the Packet Ordering (POF) functions within the service sub-
layer. It also describes the forwarding sub-layer that is used to layer. It also describes the forwarding sub-layer that is used to
eliminate (or reduce) contention loss and provide bounded latency for eliminate (or reduce) contention loss and provide bounded latency for
DetNet flows. DetNet flows.
DetNet flows may be carried over network technologies that can DetNet flows may be carried over network technologies that can
provide the DetNet required level of service. For example, DetNet provide the DetNet required service characteristics. For example,
MPLS flows can be carried over IEEE 802.1 Time Sensitive Network DetNet MPLS flows can be carried over IEEE 802.1 Time Sensitive
(TSN) [IEEE802.1TSNTG] sub-networks. However, IEEE 802.1 TSN support Network (TSN) [IEEE802.1TSNTG] sub-networks. However, IEEE 802.1 TSN
is not required and some of the DetNet benefits can be gained by support is not required and some of the DetNet benefits can be gained
running over a data link layer that has not been specifically by running over a data link layer that has not been specifically
enhanced to support TSN. enhanced to support TSN.
Different traffic types, or application flows, can be mapped on top Different traffic types, or application flows, can be mapped on top
of DetNet. DetNet can optionally reuse header information provided of DetNet. DetNet can optionally reuse header information provided
by, or shared with, applications. An example of shared header fields by, or shared with, applications. An example of shared header fields
can be found in [I-D.ietf-detnet-ip]. can be found in [I-D.ietf-detnet-ip].
This document also covers concepts related to the controller plane This document also covers concepts related to the controller plane
and Operations, Administration, and Maintenance (OAM) functions. and Operations, Administration, and Maintenance (OAM) functions
related to the control plane. Data plane OAM specifics are out of
scope for this docuement.
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 [I-D.ietf-detnet-architecture], and the reader is architecture [I-D.ietf-detnet-architecture], and the reader is
assumed to be familiar with that document and its terminology. assumed to be familiar with that document and its terminology.
2.2. Abbreviations 2.2. Abbreviations
The following abbreviations are used in this document: The following abbreviations are used in this document:
CW Control Word. CW Control Word.
DetNet Deterministic Networking. DetNet Deterministic Networking.
L2 Layer 2. GRE Generic Routing Encapsulation.
L2VPN Layer 2 Virtual Private Network. IPSec IP Security.
L2 Layer 2.
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.
OAM Operations, Administration, and Maintenance. OAM Operations, Administration, and Maintenance.
PEF Packet Elimination Function. PEF Packet Elimination Function.
skipping to change at page 5, line 38 skipping to change at page 5, line 27
| Explicit routes | | Explicit routes | | Explicit routes | | Explicit routes |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| Lower layers | | Lower layers | | Lower layers | | Lower layers |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
v ^ v ^
\_________________________/ \_________________________/
Figure 1: DetNet data plane protocol stack Figure 1: DetNet data plane protocol stack
The DetNet forwarding sub-layer may be directly provided by the The DetNet forwarding sub-layer may be directly provided by the
DetNet service sub-layer, for example by IP or MPLS. Alternatively DetNet service sub-layer, for example by IP tunnels or MPLS.
an overlay approach may be used in which the packet is natively Alternatively, an overlay approach may be used in which the packet is
carried between key nodes within the DetNet network (say between natively carried between key nodes within the DetNet network (say
PREOF nodes) and a sub-layer is used to provide the information between PREOF nodes) and a sub-layer is used to provide the
needed to reach the next hop in the overlay. information needed to reach the next hop in the overlay.
This forwarding sub-layer provides the quality underpin needed by the The forwarding sub-layer provides the quality underpin needed by the
DetNet Service sub-layer. It may do this directly through the use of DetNet flow. It may do this directly through the use of queuing
queuing techniques and traffic engineering methods, or it may do this techniques and traffic engineering methods, or it may do this through
through the assistance of its underlying connectivity. For example the assistance of its underlying connectivity. For example it may
it may call upon Ethernet TSN capabilities defined in IEEE 802.1 TSN call upon Ethernet TSN capabilities defined in IEEE 802.1 TSN
[IEEE802.1TSNTG]. [IEEE802.1TSNTG].
The service sub-layer provides additional support beyond the The service sub-layer provides additional support beyond the
connectivity function of the forwarding sub-layer. An example of connectivity function of the forwarding sub-layer. An example of
this is Packet Replication, Elimination, and Ordering (PREOF) this is Packet Replication, Elimination, and Ordering (PREOF)
function see Section 4.5. functions see Section 4.3.
The method of instantiating each of the layers is specific to the The method of instantiating each of the layers is specific to the
particular DetNet data plane method. There may be more than approach particular DetNet data plane method. There may be more than one
that is applicable to a given bearer network type. approach that is applicable to a given bearer network type.
3.1. Data Plane Characteristics 3.1. Data Plane Characteristics
There are two major characteristics to the data plane: There are two major characteristics to the data plane:
1. How the data plane is constructed: The DetNet service sub-layer 1. Data plane technology: The DetNet data plane is provided by the
provides its functions for the DetNet application flows by using DetNet service and forwarding sub layers. The DetNet service
or applying existing standardized headers and/or encapsulations. sub-layer generally provides its functions for the DetNet
The Detnet forwarding sub-layer may provide capabilities application flows by using or applying existing standardized
leveraging that same header or encapsulation technology e.g. headers and/or encapsulations. The Detnet forwarding sub-layer
Figure 2 or it may be achieved by other standardized technologies may provide capabilities leveraging that same header or
e.g. Figure 3. encapsulation technology e.g. Figure 2 or it may be achieved by
other technologies e.g. Figure 3. DetNet is currently defined
for operation over packet switched (IP) networks or label
switched (MPLS) networks.
2. Extensibility of that Data Plane: Whether or not the DetNet data 2. Encapsulation format: DetNet encodes specific flow attributes
plane includes the facility to carry additional information (namely flow identity and sequence number) in packets. For
(metadata) that can be used to provide an enhanced service to the example, in DetNet IP, zero encapsulation may be used and no
DetNet packet. sequence number is available, and in DetNet MPLS, DetNet specific
information may be added explicitly to the packets in the format
of S-label and d-CW.
DetNet +-------+ +---------+ +-------+ +---------+
Services | DN IP | | DN MPLS | | DN IP | | DN MPLS |
+-------+ +---------+ +-------+ +---------+
Figure 2: DetNet Services Figure 2: DetNet Services
+-----+ +-----+
| TSN | | TSN |
+-------+ +-+-----+-+ +-------+ +-+-----+-+
DetNet | DN IP | | DN MPLS | | DN IP | | DN MPLS |
Service +--+--+----+----+ +-+---+-----+-+ +--+--+----+----+ +-+---+-----+-+
Examples | TSN | DN MPLS | | TSN | DN IP | | TSN | DN MPLS | | TSN | DN IP |
+-----+---------+ +-----+-------+ +-----+---------+ +-----+-------+
Figure 3: DetNet Service Encapsulations Figure 3: DetNet Service Examples
3.2. Encapsulation 3.2. Encapsulation
The encapsulation of the DetNet flows allows them to be sent over a The encapsulation of the DetNet flows allows them to be sent over a
data plane of a type other than their native type. Encapsulation is data plane technology other than their native type. Encapsulation is
essential if, for example, it is required to send Ethernet TSN stream essential if, for example, it is required to send Ethernet TSN stream
as a DetNet Application over a data plane such as MPLS. Figure 3 as a DetNet Application over a data plane such as MPLS. Figure 3
illustrates some encapsulation combinations. illustrates some relationships between the components.
The use of encapsulation is also required if additional information The use of encapsulation is also required if additional information
(meta-data) is needed by the DetNet data plane and their is either no (meta-data) is needed by the DetNet data plane and there is either no
ability to include it in the client data packet, or the specification ability to include it in the client data packet, or the specification
of the client data plane does not permit the modification of the of the client data plane does not permit the modification of the
packet to include additional data. An example of such meta-data is packet to include additional data. An example of such meta-data is
the inclusion of a sequence number required by the PREOF function. the inclusion of a sequence number required by the PREOF function.
Encapsulation is also needed if the DetNet flow or aggregate flow is Encapsulation may also be used to carry or aggregate flows for
not easily recognised from its encapsulation. equipment with limited DetNet capability.
3.3. Metadata 3.3. DetNet Specific Metadata
The DetNet data plane can provide or carry meta-data:
1. Flow-ID
2. Sequence Number
Both of these metadata are required for DetNet service sub-layer
specific functions (e.g., PREOF). DetNet forwarding sub-layer
related functions require only Flow-ID.
Metadata can be a useful way of identifying packets that need to be Metadata can be a useful way of identifying packets that need to be
treated as a flow or flow aggregate. It is also useful as a way of treated as a flow or flow aggregate. It is also useful as a way of
including a sequence number the packet for use by the PREOF function including a sequence number the packet for use by the PREOF function
or as a place to carry OAM indications or OAM information to or as a place to carry OAM indications or OAM information to
instrument DetNet data plane operation. instrument DetNet data plane operation.
Explicit inclusion of metadata is possible through the use of IP Explicit inclusion of metadata is possible through the use of IP
options or IP extension headers. New IP options are almost options or IP extension headers. New IP options are almost
impossible to get standardized or to deploy in an operational network impossible to get standardized or to deploy in an operational network
and will not be discussed further in this text. IPv6 extensions and will not be discussed further in this text. IPv6 extensions
headers are finding popularity in current IPv6 development work, headers are finding popularity in current IPv6 development work,
particularly in connection with Segment Routing of IPv6 (SRv6) and IP particularly in connection with Segment Routing of IPv6 (SRv6) and IP
OAM. The design of a new IPv6 extension header or the modification OAM. The design of a new IPv6 extension header or the modification
of an existing one is a technique available in the tool box of the of an existing one is a technique available in the tool box of the
DetNet IP data plane designer. DetNet IP data plane designer.
Explicit inclusion of metadata in an IP packet is also possible Explicit inclusion of metadata in an IP packet is also possible
through the inclusion of an MPLS label stack and the MPLS DetNet through the inclusion of an MPLS label stack and the MPLS DetNet
Control Word using one of the methods for carrying MPLS over IP Control Word using one of the methods for carrying MPLS over IP
[I-D.mpls-over-udp-ip]. This is described in more detail in [I-D.ietf-detnet-mpls-over-udp-ip]. This is described in more detail
Section 3.6.4. in Section 3.6.4.
Implicit metadata can be included through the use of the network Implicit metadata in IP can be included through the use of the
programming paradigm [I-D.spring-srv6-network-programming] in which network programming paradigm
the suffix of an IPv6 address is used to encode additional [I-D.ietf-spring-srv6-network-programming] in which the suffix of an
information for use by the network of the receiving host. Examples IPv6 address is used to encode additional information for use by the
of such information include the sequence number for use by the PREOF network of the receiving host.
function, or even all the essential information being included into
the DetNet over MPLS label stack (the DetNet Control Word and the Some MPLS examples of implicit metadata include the sequence number
DetNet Service label). for use by the PREOF function, or even all the essential information
being included into the DetNet over MPLS label stack (the DetNet
Control Word and the DetNet Service label).
3.4. DetNet IP Data Plane 3.4. DetNet IP Data Plane
An IP data plane may operate natively or through the use of an An IP data plane may operate natively or through the use of an
encapsulation. There are many IP encapsulations that may be encapsulation. Many types of IP encapsulation can satisfy DetNet
interposed between the DetNet data plane IP header and the DetNet requirements and it is anticipated that more than one encapsulation
payload, and it is anticipated that more than one encapsulation may may be deployed for example GRE, IPSec etc.
be deployed.
One method of operating an IP DetNet data plane without encapsulation One method of operating an IP DetNet data plane without encapsulation
is to use "6-tuple" based flow identification, where "6-tuple" refers is to use "6-tuple" based flow identification, where "6-tuple" refers
to information carried in IP and higher layer protocol headers. to information carried in IP and higher layer protocol headers.
General background on the use of IP headers, and "5-tuples", to General background on the use of IP headers, and "6-tuples", to
identify flows and support Quality of Service (QoS) can be found in identify flows and support Quality of Service (QoS) can be found in
[RFC3670]. [RFC7657] also provides useful background on the delivery [RFC3670]. [RFC7657] also provides useful background on the delivery
differentiated services (DiffServ) and "tuple" based flow differentiated services (DiffServ) and "tuple" based flow
identification. DetNet flow aggregation may be enabled via the use identification. DetNet flow aggregation may be enabled via the use
of wildcards, masks, prefixes and ranges. The operation of this of wildcards, masks, prefixes and ranges. The operation of this
method is described in detail in [I-D.ietf-detnet-ip]. method is described in detail in [I-D.ietf-detnet-ip].
The DetNet forwarding plane may use explicit route capabilities and The DetNet forwarding plane may use explicit route capabilities and
traffic engineering capabilities to provide a forwarding sub-layer traffic engineering capabilities to provide a forwarding sub-layer
that is responsible for providing resource allocation and explicit that is responsible for providing resource allocation and explicit
routes. It is possible to include metadata in a native IP packet routes. It is possible to include such information in a native IP
explicitly, or implicitly. packet explicitly, or implicitly.
3.5. DetNet MPLS Data Plane 3.5. DetNet MPLS Data Plane
MPLS provides the ability to forward traffic over implicit and MPLS provides the ability to forward traffic over implicit and
explicit paths to the point in the network where the next DetNet explicit paths to the point in the network where the next DetNet
service sub-layer action needs to take place. It does this through service sub-layer action needs to take place. It does this through
the use of a stack of one or more labels with various forwarding the use of a stack of one or more labels with various forwarding
semantics. semantics.
MPLS also provides the ability to identify a service instance that is MPLS also provides the ability to identify a service instance that is
used to process the packet through the use of a label that maps the used to process the packet through the use of a label that maps the
packet to a service instance. packet to a service instance.
In cases where metadata is needed to process an MPLS encapsulated In cases where metadata is needed to process an MPLS encapsulated
packet at the service sub-layer, this has been been provided through packet at the service sub-layer, a shim layer also called a control
the use of a shim layer also called a control word (CW) [RFC4385]. word (CW) [RFC4385] can be used. Although such CWs are frequently 32
Although such CWs are frequently 32 bits long, there is no bits long, there is no architectural constraint on its size of this
architectural constraint on its size of this structure, only the structure, only the requirement that it is fully understood by all
requirement that it is fully understood by all parties operating on parties operating on it in the DetNet service sub-layer. The
it in the DetNet service sub-layer. The operation of this method is operation of this method is described in detail in
described in detail in [I-D.ietf-detnet-mpls]. [I-D.ietf-detnet-mpls].
3.6. Further DetNet Data Plane Considerations 3.6. Further DetNet Data Plane Considerations
This section needs further work.
This section provides informative considerations related to providing This section provides informative considerations related to providing
DetNet service to flows which are identified based on their header DetNet service to flows which are identified based on their header
information. At a high level, the following are provided on a per information. At a high level, the following are provided on a per
flow basis: flow basis:
Reservation and Allocation of resources: Reservation and Allocation of resources:
Reservation of resources can allocate resources to specific DetNet Reservation of resources can allocate resources to specific DetNet
flows. This can eliminate packet contention and loss for DetNet flows. This can eliminate packet contention and loss for DetNet
traffic. This also can reduce jitter for the DetNet traffic. traffic. This also can reduce jitter for the DetNet traffic.
skipping to change at page 9, line 47 skipping to change at page 10, line 7
bandwidth or lowest jitter. In these cases the "best" path for bandwidth or lowest jitter. In these cases the "best" path for
any set of characteristics may not be a shortest path. The any set of characteristics may not be a shortest path. The
selection of path can take into account multiple network metrics. selection of path can take into account multiple network metrics.
Some of these metrics are measured and distributed by the routing Some of these metrics are measured and distributed by the routing
system as traffic engineering metrics. system as traffic engineering metrics.
Service protection: Service protection:
Use of multiple packet streams using multiple paths, for example Use of multiple packet streams using multiple paths, for example
1+1 or 1:1 linear protection. For DetNet this primarily relates 1+1 or 1:1 linear protection. For DetNet this primarily relates
to packet replication and elimination capabilities. Changing the to packet replication and elimination capabilities. MPLS offers a
explicit path after a failure is detected to an already number of protection schemes. MPLS hitless protection can be used
established path in order to restore delivery of the required to switch traffic to an already established path in order to
DetNet service characteristics is another protection mechanism for restore delivery rapidly after a failure. Path changes, even in
example MPLS hitless protection. Path changes, even in the case the case of failure recovery, can lead to the out of order
of failure recovery, can lead to the out of order delivery of data delivery of data requiring packet ordering functions either within
requiring packet ordering functions either within the DetNet the DetNet service or at a high layer in the application traffic.
service or at a high layer in the application traffic.
Establishment of new paths after a failure is out of scope for Establishment of new paths after a failure is out of scope for
DetNet services. DetNet services.
Network Coding: Network Coding:
Network Coding, not to be confused with network programming, Network Coding, not to be confused with network programming,
comprises several techniques where multiple data flows are comprises several techniques where multiple data flows are
encoded. These resulting flows can then be sent on different encoded. These resulting flows can then be sent on different
paths. The encoding operation can combine flows and error paths. The encoding operation can combine flows and error
recovery information. When the encoded flows are decoded and recovery information. When the encoded flows are decoded and
skipping to change at page 12, line 27 skipping to change at page 12, line 33
flow, forwards packet 1.2.1 to Relay Node R3. Packet copy 1.1 is of flow, forwards packet 1.2.1 to Relay Node R3. Packet copy 1.1 is of
no further use and so is discarded by R2. no further use and so is discarded by R2.
Edge Node EN2 receives packet copy 1.2.2 from R4 before it receives Edge Node EN2 receives packet copy 1.2.2 from R4 before it receives
packet copy 1.2.1 from R2 via relay Node R3. EN2 therefore strips packet copy 1.2.1 from R2 via relay Node R3. EN2 therefore strips
any DetNet encapsulation from packet copy 1.2.2 and forwards the any DetNet encapsulation from packet copy 1.2.2 and forwards the
packet to CE2. When EN2 receives the later packet copy 1.2.1 this is packet to CE2. When EN2 receives the later packet copy 1.2.1 this is
discarded. discarded.
The above is of course illustrative of many network scenarios that The above is of course illustrative of many network scenarios that
can be configured. Between a pair of relay nodes there may be one or can be configured.
more transit nodes that simply forward the DetNet traffic, but these
are omitted for clarity.
This example also illustrates 1:1 protection scheme meaning there is This example also illustrates 1:1 protection scheme meaning there is
traffic and path for each segment of the end to end path. Local traffic and path for each segment of the end to end path. Local
DetNet relay nodes determine which packets are eliminated and which DetNet relay nodes determine which packets are eliminated and which
packets are forwarded. A 1+1 scheme where only one path is used for packets are forwarded. A 1+1 scheme where only one path is used for
traffic at a time, could use the same topology. In this case there traffic at a time, could use the same topology. In this case there
is no PRF function and traffic is switched upon detection of failure. is no PRF function and traffic is switched upon detection of failure.
An OAM scheme that monitors the paths detects the loss of path or An OAM scheme that monitors the paths detects the loss of path or
traffic is required to initiate the switch. A POF may still be used traffic is required to initiate the switch. A POF may still be used
in this case to prevent misordering of packets. In both cases the in this case to prevent misordering of packets. In both cases the
skipping to change at page 13, line 9 skipping to change at page 13, line 11
Ring protection may also be supported if the underlying technology Ring protection may also be supported if the underlying technology
supports it. Many of the same concepts apply however Rings are supports it. Many of the same concepts apply however Rings are
normally 1+1 protection for data efficiency reasons. [RFC8227] is an normally 1+1 protection for data efficiency reasons. [RFC8227] is an
example of MPLS-TP data plane that supports Ring protection. example of MPLS-TP data plane that supports Ring protection.
3.6.2. Aggregation Considerations 3.6.2. Aggregation Considerations
The DetNet data plane also allows for the aggregation of DetNet The DetNet data plane also allows for the aggregation of DetNet
flows, to improved scaling by reducing the state per hop. How this flows, to improved scaling by reducing the state per hop. How this
is done is data plane or control plane dependent. When DetNet flows is accomplished is data plane or control plane dependent. When
are aggregated, transit nodes provide service to the aggregate and DetNet flows are aggregated, transit nodes provide service to the
not on a per-DetNet flow basis. When aggregating DetNet flows the aggregate and not on a per-DetNet flow basis. When aggregating
flows should be compatible i.e. the same or very similar QoS and CoS DetNet flows the flows should be compatible i.e. the same or very
characteristics. In this case, nodes performing aggregation will similar QoS and CoS characteristics. In this case, nodes performing
ensure that per-flow service requirements are achieved. aggregation will ensure that per-flow service requirements are
achieved.
If bandwidth reservations are used, the sum of the reservations If bandwidth reservations are used, the sum of the reservations
should be the sum of all the individual reservations, in other words, should be the sum of all the individual reservations, in other words,
the reservations should not create an over subscription of bandwidth the reservations should not create an over subscription of bandwidth
reservation. If maximum delay bounds are used the system should reservation. If maximum delay bounds are used the system should
ensure that the aggregate does not exceed the delay bounds of the ensure that the aggregate does not exceed the delay bounds of the
component flows. individual flows.
DetNet encapsulation is a data plane mechanism that can be used to DetNet encapsulation is a data plane mechanism that can be used to
aggregate traffic. Encapsulation can either be in the same service aggregate traffic. Encapsulation can either be in the same service
type or in a different service type see Figure 3 for examples. When type or in a different service type see Figure 3 for example. When
an encapsulation is used the choice of reserving a maximum resource an encapsulation is used the choice of reserving a maximum resource
level and then tracking the services in the aggregated service or level and then tracking the services in the aggregated service or
adjusting the aggregated resources as the services are added is adjusting the aggregated resources as the services are added is
implementation and technology specific. implementation and technology specific.
DetNet flows at edges must be able to handle rejection to an DetNet flows at edges must be able to handle rejection to an
aggregation group due to lack of resources as well as conditions aggregation group due to lack of resources as well as conditions
where general requirements are not satisfied. where general requirements are not satisfied.
3.6.2.1. IP Aggregation 3.6.2.1. IP Aggregation
IP aggregation has both data plane and controller plane aspects. For IP aggregation has both data plane and controller plane aspects. For
the data plane flows may be aggregated for treatment based on shared the data plane flows may be aggregated for treatment based on shared
characteristics such as 5-tuple. Alternatively, an IP encapsulation characteristics such as 6-tuple. Alternatively, an IP encapsulation
may be used to tunnel an aggregate number of DetNet Flows between may be used to tunnel an aggregate number of DetNet Flows between
relay nodes. relay nodes.
3.6.2.2. MPLS Aggregation 3.6.2.2. MPLS Aggregation
MPLS aggregation similarly has data plane and controller plane MPLS aggregation similarly has data plane and controller plane
aspects. In the case of MPLS flows are often tunneled in a aspects. In the case of MPLS flows are often tunneled in a
forwarding sub-layer and reservation is associated with that MPLS forwarding sub-layer and reservation is associated with that MPLS
tunnel. tunnel.
3.6.3. End-System Specific Considerations 3.6.3. End-System Specific Considerations
Data-flows requiring DetNet service are generated and terminated on Data-flows requiring DetNet service are generated and terminated on
end-systems. Encapsulation depends on application and its end-systems. Encapsulation depends on the application and its
preferences. For example, a DetNet MPLS domain the DN functions use preferences. For example, a DetNet MPLS domain the DN functions use
the d-CWs, S-Labels and F-Labels to provide DetNet services. the d-CWs, S-Labels and F-Labels to provide DetNet services.
However, an application may exchange further flow related parameters However, an application may exchange further flow related parameters
(e.g., time-stamp), which are not provided by DN functions. (e.g., time-stamp), which are not provided by DN functions.
As a general rule, DetNet domains are capable of forwarding any As a general rule, DetNet domains are capable of forwarding any
DetNet flows and the DetNet domain does not mandate the end-system or DetNet flows and the DetNet domain does not mandate the end-system or
edge system encapsulation format. Unless there is a proxy of some edge system encapsulation format. Unless there is a proxy of some
form present, end-systems peer with similar end-systems using the form present, end-systems peer with similar end-systems using the
same application encapsulation format. For example, as shown in same application encapsulation format. For example, as shown in
Figure 5, IP applications peer with IP applications and Ethernet Figure 5, IP applications peer with IP applications and Ethernet
L2VPN applications peer with Ethernet L2VPN applications. applications peer with Ethernet applications.
+-----+ +-----+
| X | +-----+ | X | +-----+
+-----+ | X | +-----+ | X |
| Eth | ________ +-----+ | Eth | ________ +-----+
+-----+ _____ / \ | Eth | +-----+ _____ / \ | Eth |
\ / \__/ \___ +-----+ \ / \__/ \___ +-----+
\ / \ / \ / \ /
0======== tunnel-1 ========0_ 0======== tunnel-1 ========0_
| \ | \
skipping to change at page 15, line 11 skipping to change at page 15, line 11
DetNet flows. In some cases, e.g., on dedicated point-to-point links DetNet flows. In some cases, e.g., on dedicated point-to-point links
or TDM technologies, all that is required is for a DetNet node to or TDM technologies, all that is required is for a DetNet node to
appropriately queue its output traffic. In other cases, DetNet nodes appropriately queue its output traffic. In other cases, DetNet nodes
will need to map DetNet flows to the flow semantics (i.e., will need to map DetNet flows to the flow semantics (i.e.,
identifiers) and mechanisms used by an underlying sub-network identifiers) and mechanisms used by an underlying sub-network
technology. Figure 6 shows several examples of header formats that technology. Figure 6 shows several examples of header formats that
can be used to carry DetNet MPLS flows over different sub-network can be used to carry DetNet MPLS flows over different sub-network
technologies. L2 represent a generic layer-2 encapsulation that technologies. L2 represent a generic layer-2 encapsulation that
might be used on a point-to-point link. TSN represents the might be used on a point-to-point link. TSN represents the
encapsulation used on an IEEE 802.1 TSN network, as described in encapsulation used on an IEEE 802.1 TSN network, as described in
[I-D.mpls-over-tsn]. UDP/IP represents the encapsulation used on a [I-D.ietf-detnet-mpls-over-tsn]. UDP/IP represents the encapsulation
DetNet IP PSN, as described in [I-D.mpls-over-udp-ip]. used on a DetNet IP PSN, as described in
[I-D.ietf-detnet-mpls-over-udp-ip].
+------+ +------+ +------+ +------+ +------+ +------+
App-Flow | X | | X | | X | App-Flow | X | | X | | X |
+-----+======+--+======+--+======+-----+ +-----+======+--+======+--+======+-----+
DetNet-MPLS | d-CW | | d-CW | | d-CW | DetNet-MPLS | d-CW | | d-CW | | d-CW |
+------+ +------+ +------+ +------+ +------+ +------+
|Labels| |Labels| |Labels| |Labels| |Labels| |Labels|
+-----+======+--+======+--+======+-----+ +-----+======+--+======+--+======+-----+
Sub-Network | L2 | | TSN | | UDP | Sub-Network | L2 | | TSN | | UDP |
+------+ +------+ +------+ +------+ +------+ +------+
skipping to change at page 16, line 5 skipping to change at page 16, line 5
The primary requirements of the DetNet controller plane are that it The primary requirements of the DetNet controller plane are that it
must be able to: must be able to:
o Instantiate DetNet flows in a DetNet domain (which may include o Instantiate DetNet flows in a DetNet domain (which may include
some or all of explicit path determination, link bandwidth some or all of explicit path determination, link bandwidth
reservations, restricting flows to IEEE 802.1 TSN links, node reservations, restricting flows to IEEE 802.1 TSN links, node
buffer and other resource reservations, specification of required buffer and other resource reservations, specification of required
queuing disciplines along the path, ability to manage queuing disciplines along the path, ability to manage
bidirectional flows, etc.) as needed for a flow. bidirectional flows, etc.) as needed for a flow.
o In the case of MPLS Manage DetNet S-Label and F-Label allocation o In the case of MPLS, manage DetNet S-Label and F-Label allocation
and distribution, where the DetNet MPLS encapsulation is in use and distribution, where the DetNet MPLS encapsulation is in use
see Section 4.4. see [I-D.ietf-detnet-mpls].
o The ability to support DetNet flow aggregation. o Support DetNet flow aggregation.
o Advertise static and dynamic node and link resources such as o Advertise static and dynamic node and link resources such as
capabilities and adjacencies to other network nodes (for dynamic capabilities and adjacencies to other network nodes (for dynamic
signaling approaches) or to network controllers (for centralized signaling approaches) or to network controllers (for centralized
approaches). approaches).
o Scale to handle the number of DetNet flows expected in a domain o Scale to handle the number of DetNet flows expected in a domain
(which may require per-flow signaling or provisioning). (which may require per-flow signaling or provisioning).
o Provision flow identification information at each of the nodes o Provision flow identification information at each of the nodes
skipping to change at page 17, line 19 skipping to change at page 17, line 19
[I-D.ietf-detnet-architecture] refers to these collectively as the [I-D.ietf-detnet-architecture] refers to these collectively as the
'Controller Plane'. This document therefore does not distinguish 'Controller Plane'. This document therefore does not distinguish
between information provided by distributed control plane protocols, between information provided by distributed control plane protocols,
e.g., RSVP-TE [RFC3209] and [RFC3473], or by centralized network e.g., RSVP-TE [RFC3209] and [RFC3473], or by centralized network
management mechanisms, e.g., RestConf [RFC8040], YANG [RFC7950], and management mechanisms, e.g., RestConf [RFC8040], YANG [RFC7950], and
the Path Computation Element Communication Protocol (PCEP) the Path Computation Element Communication Protocol (PCEP)
[I-D.ietf-pce-pcep-extension-for-pce-controller] or any combination [I-D.ietf-pce-pcep-extension-for-pce-controller] or any combination
thereof. Specific considerations and requirements for the DetNet thereof. Specific considerations and requirements for the DetNet
Controller Plane are discussed in Section 4.1. Controller Plane are discussed in Section 4.1.
Each respective data plane document also covers the control plane
considerations for that technology. For example [I-D.ietf-detnet-ip]
covers IP control plane normative considerations and
[I-D.ietf-detnet-mpls] covers MPLS control plane normative
considerations.
4.2.1. Flow Aggregation Control 4.2.1. Flow Aggregation Control
Flow aggregation includes aggregation accomplished through the use of Flow aggregation includes aggregation accomplished through the use of
hierarchical LSPs in MPLS and tunnels, in the case of IP, MPLS and hierarchical LSPs in MPLS and tunnels, in the case of IP, MPLS and
TSN, both of which aggregate multiple DetNet flows into a single new TSN, all of which aggregate multiple DetNet flows into a single new
DetNet flow. It can also be grouping of IP flows that share 5-tuple DetNet flow. Aggregation can also be grouping of IP flows that share
of 6-tuple attributes or flow identifiers at the DetNet sub-layer. 6-tuple attributes or flow identifiers at the DetNet sub-layer.
Control of aggregation involves a set of procedures not necessarily Control of aggregation involves a set of procedures listed here.
in a strict order: Aggregation may use some or all of these capabilities and the order
may vary:
o Traffic engineering resource collection and distribution: o Traffic engineering resource collection and distribution:
Available resources are tracked through control plane or Available resources are tracked through control plane or
management plane databases and distributed amongst controllers management plane databases and distributed amongst controllers
or nodes that can manage resources. or nodes that can manage resources.
o Path computation and resource allocation: o Path computation and resource allocation:
When DetNet services are provisioned or requested one or more When DetNet services are provisioned or requested one or more
paths meeting the requirements are selected and the resources paths meeting the requirements are selected and the resources
verified and recorded. verified and recorded.
o Resource assignment and data plane co-ordination: o Resource assignment and data plane co-ordination:
The assignment of resources along the path depends on the The assignment of resources along the path depends on the
technology and it includes assignment of specific links and technology and it includes assignment of specific links and
coordination of the queuing and other traffic management coordination of the queuing and other traffic management
capabilities. capabilities such as policing and shaping.
o Assigned Resource recording and updating: o Assigned Resource recording and updating:
Depending on the specific technology the assigned resources are Depending on the specific technology the assigned resources are
updated and distributed in the databases preventing over updated and distributed in the databases preventing over
subscription. subscription.
4.2.2. Explicit Routes 4.2.2. Explicit Routes
Explicit routes are used to ensure that packets are routed through Explicit routes are used to ensure that packets are routed through
the resources that have been reserved for them, and hence provide the the resources that have been reserved for them, and hence provide the
DetNet application with the required service. A requirement for the DetNet application with the required service. A requirement for the
DetNet Controller Plane will be the ability to assign a particular DetNet Controller Plane will be the ability to assign a particular
identified DetNet IP flow to a path through the DetNet domain that identified DetNet IP flow to a path through the DetNet domain that
has been assigned the required nodal resources. This provides the has been assigned the required nodal resources. This provides the
appropriate traffic treatment for the flow and also includes appropriate traffic treatment for the flow and also includes
particular links as a part of the path that are able to support the particular links as a part of the path that are able to support the
DetNet flow. For example, by using IEEE 802.1 TSN links (as DetNet flow. For example, by using IEEE 802.1 TSN links (as
discussed in [I-D.mpls-over-tsn] ) DetNet parameters can be discussed in [I-D.ietf-detnet-mpls-over-tsn] ) DetNet parameters can
maintained. Further considerations and requirements for the DetNet be maintained. Further considerations and requirements for the
Controller Plane are discussed in Section 4.1. DetNet Controller Plane are discussed in Section 4.1.
Whether configuring, calculating and instantiating these routes is a Whether configuring, calculating and instantiating these routes is a
single-stage or multi-stage process, or in a centralized or single-stage or multi-stage process, or in a centralized or
distributed manner, is out of scope of this document. distributed manner, is out of scope of this document.
There are several of approaches that could be used to provide There are several approaches that could be used to provide explicit
explicit routes and resource allocation in the DetNet forwarding sub- routes and resource allocation in the DetNet forwarding sub-layer.
layer. For example: For example:
o The path could be explicitly set up by a controller which o The path could be explicitly set up by a controller which
calculates the path and explicitly configures each node along that calculates the path and explicitly configures each node along that
path with the appropriate forwarding and resource allocation path with the appropriate forwarding and resource allocation
information. information.
o The path could use a distributed control plane such as RSVP o The path could use a distributed control plane such as RSVP
[RFC2205] or RSVP-TE [RFC3473] extended to support DetNet IP [RFC2205] or RSVP-TE [RFC3473] extended to support DetNet IP
flows. flows.
skipping to change at page 19, line 14 skipping to change at page 19, line 14
4.2.3. Contention Loss and Jitter Reduction 4.2.3. Contention Loss and Jitter Reduction
As discussed in Section 1, this document does not specify the As discussed in Section 1, this document does not specify the
mechanisms needed to eliminate packet contention, packet loss or mechanisms needed to eliminate packet contention, packet loss or
reduce jitter for DetNet flows at the DetNet forwarding sub-layer. reduce jitter for DetNet flows at the DetNet forwarding sub-layer.
The ability to manage node and link resources to be able to provide The ability to manage node and link resources to be able to provide
these functions is a necessary part of the DetNet controller plane. these functions is a necessary part of the DetNet controller plane.
It is also necessary to be able to control the required queuing It is also necessary to be able to control the required queuing
mechanisms used to provide these functions along a flow's path mechanisms used to provide these functions along a flow's path
through the network. See [I-D.ietf-detnet-ip] --> and Section 4.1 through the network. See [I-D.ietf-detnet-ip] and Section 4.1 for
for further discussion of these requirements. further discussion of these requirements.
4.2.4. Bidirectional Traffic 4.2.4. Bidirectional Traffic
DetNet applications typically generate bidirectional traffic. IP and DetNet applications typically generate bidirectional traffic. IP and
MPLS typically treat each direction separately and do not force MPLS typically treat each direction separately and do not force
interdependence of each direction. MPLS has considered bidirectional interdependence of each direction. MPLS has considered bidirectional
traffic requirements and the MPLS definitions from [RFC5654] are traffic requirements and the MPLS definitions from [RFC5654] are
useful to illustrate terms such as associated bidirectional flows and useful to illustrate terms such as associated bidirectional flows and
co-routed bidirectional flows. MPLS defines a point-to-point co-routed bidirectional flows. MPLS defines a point-to-point
associated bidirectional LSP as consisting of two unidirectional associated bidirectional LSP as consisting of two unidirectional
skipping to change at page 20, line 6 skipping to change at page 20, line 5
and control plane levels, without specific support or knowledge and control plane levels, without specific support or knowledge
within the DetNet data plane. Fate sharing and associated or co- within the DetNet data plane. Fate sharing and associated or co-
routed bidirectional flows, can be managed at the control level. routed bidirectional flows, can be managed at the control level.
DetNet's use of PREOF may increase the complexity of using co-routing DetNet's use of PREOF may increase the complexity of using co-routing
bidirectional flows, since if PREOF is used, then the replication bidirectional flows, since if PREOF is used, then the replication
points in one direction would have to match the elimination points in points in one direction would have to match the elimination points in
the other direction, and vice versa, and the optimal points for these the other direction, and vice versa, and the optimal points for these
functions in one direction may not match the optimal points in the functions in one direction may not match the optimal points in the
other subsequent to the network and traffic constraints. other subsequent to the network and traffic constraints.
Furthermore, due to the per packet service protection nature,
bidirectional forwarding per packet may not be ensured. The first
packet of received member flows is selected by the elimination
function independently of which path it has taken through the
network.
Control and management mechanisms need to support bidirectional Control and management mechanisms need to support bidirectional
flows, but the specification of such mechanisms are out of scope of flows, but the specification of such mechanisms are out of scope of
this document. An example control plane solution for MPLS can be this document. An example control plane solution for MPLS can be
found in . Related control plan mechanisms have been defined in found in [RFC3473] , [RFC6387] and [RFC7551]. These requirements are
[RFC3473] , [RFC6387] and [RFC7551]. included in Section 4.1.
This is further discussed in Section 4.1.
4.3. IP-Specific Controller Plane Considerations
This section covers IP data plane specific control plane
considerations.
4.3.1. Flow Identification and Aggregation
Section 3 discussed the use of the IP "6-tuple" for flow
identification, and goes on to discuss how identified flows use
specific QoS mechanisms for flow-specific traffic treatment,
including path control and resource allocation. [I-D.ietf-detnet-ip]
contains detailed DetNet IP flow identification procedures. Flow
identification will play an important role for the DetNet controller
plane.
Section 3.6.2 and Section 3.6.2.1 discuss the use of flow aggregation
in DetNet. Flow aggregation can be accomplished using any of the
6-tuple fields defined in [I-D.ietf-detnet-ip] , using a DSCP
identified traffic class or other field. It will be the
responsibility of the DetNet controller plane to be able to properly
provision the use of these aggregation mechanisms. These
requirements are included in Section 4.1.
4.4. MPLS-Specific Controller Plane Considerations
This section covers MPLS data plane specific control plane
considerations. This section needs generalizing.
4.4.1. S-Label and F-Label Assignment and Distribution
[Editor's note - we may need additional text on resource allocation
in this section.]
DetNet S-Labels [I-D.ietf-detnet-mpls] for their definition) are
similar to other MPLS service labels that denote the contents of the
MPLS packet payload such as a layer 2 pseudowire, an IP packet that
is routed in a VPN context with a private address, or an Ethernet
virtual private network (EVPN) service.
S-Labels are expected to be allocated in the same manner as any other
service labels. S-Labels uniquely identify a particular DetNet flow,
and are local to the node on which the label is allocated. In the
DetNet service sub-layer the explicit route consists of the set of
Relay Nodes that the DetNet flow must traverse. They can be used to
identify the DetNet flow that a packet belongs to as it traverses a
particular node in a DetNet domain. Because 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.
As discussed in Section 3, the forwarding sub-layer uses one or more
F-Labels to forward DetNet packets between DetNet service-aware nodes
along explicitly defined routes at the DetNet forwarding sub-layer,
which in the context of this document is MPLS. F-Labels can also
provide context for an S-Label. In the DetNet Forwarding (MPLS) sub-
layer the explicit route consists of the set of DetNet nodes which
are LSRs, links, and possibly link bundle members and queues that the
DetNet packets of a flow must traverse between nodes in the DetNet
service sub-layer (i.e. between a specific Edge Node and the next hop
Relay Node, between specific Relay Nodes, and between a specific
Relay node and the egress Edge Node. Resource allocation
corresponding to the set of Services supported over the forwarding
sub-layer, which may or may not include aggregation, is required at
this sub-layer. Explicit routes are used to ensure that packets are
routed through the resources that have been reserved for them, and
hence provide the DetNet application with the required service.
Multiple F-Labels may be pushed after an S-Label and there is no
requirement for all F-Labels to be controlled via the same controller
mechanisms. For example in EVPN, some labels are distributed using
BGP while others are distributed using LDP or RSVP.
Whether configuring, calculating and instantiating these routes is a
single-stage or multi-stage process, or in a centralized or
distributed manner, is out of scope of this document.
There are a number of approaches that could be used to provide
explicit routes and resource allocation in the MPLS forwarding sub-
layer:
o The path could be explicitly set up by a controller which
calculates the path and explicitly configures each node along that
path with the appropriate forwarding and resource allocation
information.
o The path could be set up using RSVP-TE signaling.
o The path could be implemented using MPLS-based segment routing
when extended to support resource allocation.
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, but as
mentioned above, there are particular DetNet considerations and
requirements that are discussed in Section 4.1.
4.5. Packet Replication, Elimination, and Ordering (PREOF) 4.3. Packet Replication, Elimination, and Ordering (PREOF)
The controller plane protocol solution required for managing the The controller plane protocol solution required for managing the
PREOF processing is outside the scope of this document. That said, PREOF processing is outside the scope of this document. That said,
it should be noted that the ability to determine, for a particular it should be noted that the ability to determine, for a particular
flow, optimal packet replication and elimination points in the DetNet flow, optimal packet replication and elimination points in the DetNet
domain requires explicit support. There are be capabilities that can domain requires explicit support. There may be capabilities that can
be used, or extended, for example GMPLS end-to-end recovery [RFC4872] be used, or extended, for example GMPLS end-to-end recovery [RFC4872]
and GMPLS segment recovery [RFC4873]. and GMPLS segment recovery [RFC4873].
4.6. Contention Loss and Jitter Reduction
As discussed in Section 1, this document does not specify the
mechanisms needed to eliminate contention loss or reduce jitter for
DetNet flows at the DetNet forwarding sub-layer. The ability to
manage node and link resources to be able to provide these functions
will be a necessary part of the DetNet controller plane. It will
also be necessary to be able to control the required queuing
mechanisms used to provide these functions along a flow's path
through the network. See Section 4.1 for further discussion of these
requirements.
5. Security Considerations 5. Security Considerations
The security considerations of DetNet in general are discussed in Security considerations for DetNet are described in detail in
[I-D.ietf-detnet-architecture] and [I-D.sdt-detnet-security]. Other [I-D.ietf-detnet-security]. General security considerations are
security considerations will be added in a future version of this described in [I-D.ietf-detnet-architecture]. This section considers
draft. general security considerations applicable to all data planes.
6. IANA Considerations
This document makes no IANA requests.
7. Contributors
RFC7322 limits the number of authors listed on the front page of a
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 8.
Loa Andersson
Huawei
Email: loa@pi.nu
Yuanlong Jiang
Huawei
Email: jiangyuanlong@huawei.com
Norman Finn
Huawei
3101 Rio Way
Spring Valley, CA 91977
USA
Email: norman.finn@mail01.huawei.com
Janos Farkas
Ericsson
Magyar Tudosok krt. 11.
Budapest 1117
Hungary
Email: janos.farkas@ericsson.com
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Email: cjbc@it.uc3m.es
Tal Mizrahi
Marvell
6 Hamada st.
Yokneam
Israel
Email: talmi@marvell.com
Lou Berger
LabN Consulting, L.L.C.
Email: lberger@labn.net
Stewart Bryant
Huawei Technologies
Email: stewart.bryant@gmail.com
Mach Chen
Huawei Technologies
Email: mach.chen@huawei.com
Andrew G. Malis
Huawei Technologies
Email: agmalis@gmail.com
Don Fedyk
LabN Consulting, L.L.C.
Email: dfedyk@labn.net
8. Acknowledgements
The author(s) ACK and NACK.
The following people were part of the DetNet Data Plane Solution
Design Team:
Jouni Korhonen
Janos Farkas
Norman Finn
Balazs Varga
Loa Andersson 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.
Tal Mizrahi 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 Ethernet (Layer-2) flows.
David Mozes From a data plane perspective DetNet does not add or modify any
header information.
Yuanlong Jiang 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.
Andrew Malis 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.
Carlos J. Bernardos 6. IANA Considerations
The DetNet chairs serving during the DetNet Data Plane Solution This document makes no IANA requests.
Design Team:
Lou Berger 7. Acknowledgements
Pat Thaler 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 8. References
9.1. Normative References 8.1. Normative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol- Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003, DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>. <https://www.rfc-editor.org/info/rfc3473>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <https://www.rfc-editor.org/info/rfc4385>. February 2006, <https://www.rfc-editor.org/info/rfc4385>.
9.2. Informative References 8.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-flow-information-model] [I-D.ietf-detnet-flow-information-model]
Farkas, J., Varga, B., Cummings, R., and Y. Jiang, "DetNet Farkas, J., Varga, B., Cummings, R., and Y. Jiang, "DetNet
Flow Information Model", draft-ietf-detnet-flow- Flow Information Model", draft-ietf-detnet-flow-
information-model-03 (work in progress), March 2019. information-model-03 (work in progress), March 2019.
[I-D.ietf-detnet-ip] [I-D.ietf-detnet-ip]
Korhonen, J., Varga, B., "DetNet Data Plane: IP", 2019. Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: IP",
draft-ietf-detnet-ip-00 (work in progress), May 2019.
[I-D.ietf-detnet-mpls] [I-D.ietf-detnet-mpls]
Korhonen, J., Varga, B., "DetNet Data Plane: MPLS", 2019. Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",
draft-ietf-detnet-mpls-00 (work in progress), May 2019.
[I-D.ietf-detnet-mpls-over-tsn]
Varga, B., Farkas, J., Malis, A., Bryant, S., and J.
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-mpls-over-udp-ip]
Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S.,
and J. Korhonen, "DetNet Data Plane: MPLS over IP", draft-
ietf-detnet-mpls-over-udp-ip-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-pce-pcep-extension-for-pce-controller] [I-D.ietf-pce-pcep-extension-for-pce-controller]
Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures
and Protocol Extensions for Using PCE as a Central and Protocol Extensions for Using PCE as a Central
Controller (PCECC) of LSPs", draft-ietf-pce-pcep- Controller (PCECC) of LSPs", draft-ietf-pce-pcep-
extension-for-pce-controller-01 (work in progress), extension-for-pce-controller-01 (work in progress),
February 2019. February 2019.
[I-D.mpls-over-tsn] [I-D.ietf-spring-srv6-network-programming]
Korhonen, J., Varga, B., "DetNet Data Plane: MPLS over Filsfils, C., Camarillo, P., Leddy, J.,
IEEE 802.1 Time Sensitive Networking (TSN)", 2019. daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-ietf-spring-srv6-network-
[I-D.mpls-over-udp-ip] programming-00 (work in progress), April 2019.
Korhonen, J., Varga, B., "DetNet Data Plane: MPLS over
IP", 2019.
[I-D.sdt-detnet-security]
Mizrahi, T., Grossman, E., Hacker, A., Das, S.,
"Deterministic Networking (DetNet) Security
Considerations, draft-sdt-detnet-security, work in
progress", 2017.
[I-D.spring-srv6-network-programming] [IEEE802.1AE-2018]
Filsfils, C., Camarillo, P., "SRv6 Network Programming, IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC
draft-filsfils-spring-srv6-network-programming, work in Security (MACsec)", 2018,
progress", 2019. <https://ieeexplore.ieee.org/document/8585421>.
[IEEE802.1TSNTG] [IEEE802.1TSNTG]
IEEE Standards Association, "IEEE 802.1 Time-Sensitive IEEE Standards Association, "IEEE 802.1 Time-Sensitive
Networking Task Group", <http://www.ieee802.org/1/tsn>. Networking Task Group", <http://www.ieee802.org/1/tsn>.
[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>.
[RFC2386] Crawley, E., Nair, R., Rajagopalan, B., and H. Sandick, "A [RFC2386] Crawley, E., Nair, R., Rajagopalan, B., and H. Sandick, "A
Framework for QoS-based Routing in the Internet", Framework for QoS-based Routing in the Internet",
RFC 2386, DOI 10.17487/RFC2386, August 1998, RFC 2386, DOI 10.17487/RFC2386, August 1998,
<https://www.rfc-editor.org/info/rfc2386>. <https://www.rfc-editor.org/info/rfc2386>.
[RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and [RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and
W. Weiss, "Information Model for Describing Network Device W. Weiss, "Information Model for Describing Network Device
QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670, QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670,
January 2004, <https://www.rfc-editor.org/info/rfc3670>. January 2004, <https://www.rfc-editor.org/info/rfc3670>.
[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>.
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in Support of End-to-End Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS) Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
<https://www.rfc-editor.org/info/rfc4872>. <https://www.rfc-editor.org/info/rfc4872>.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
May 2007, <https://www.rfc-editor.org/info/rfc4873>. May 2007, <https://www.rfc-editor.org/info/rfc4873>.
skipping to change at page 28, line 34 skipping to change at page 25, line 23
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. 81 change blocks. 
384 lines changed or deleted 257 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/