rfc8938v4.txt   rfc8938.txt 
skipping to change at line 13 skipping to change at line 13
Request for Comments: 8938 J. Farkas Request for Comments: 8938 J. Farkas
Category: Informational Ericsson Category: Informational Ericsson
ISSN: 2070-1721 L. Berger ISSN: 2070-1721 L. Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
A. Malis A. Malis
Malis Consulting Malis Consulting
S. Bryant S. Bryant
Futurewei Technologies Futurewei Technologies
November 2020 November 2020
Deterministic Networking (DetNet) Data-Plane Framework Deterministic Networking (DetNet) Data Plane Framework
Abstract Abstract
This document provides an overall framework for the Deterministic This document provides an overall framework for the Deterministic
Networking (DetNet) data plane. It covers concepts and Networking (DetNet) data plane. It covers concepts and
considerations that are generally common to any DetNet data-plane considerations that are generally common to any DetNet data plane
specification. It describes related Controller-Plane considerations specification. It describes related Controller Plane considerations
as well. as well.
Status of This Memo Status of This Memo
This document is not an Internet Standards Track specification; it is This document is not an Internet Standards Track specification; it is
published for informational purposes. published for informational purposes.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
skipping to change at line 61 skipping to change at line 61
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 1. Introduction
2. Terminology 2. Terminology
2.1. Terms Used in This Document 2.1. Terms Used in This Document
2.2. Abbreviations 2.2. Abbreviations
3. Overview of the DetNet Data Plane 3. Overview of the DetNet Data Plane
3.1. Data-Plane Characteristics 3.1. Data Plane Characteristics
3.1.1. Data-Plane Technology 3.1.1. Data Plane Technology
3.1.2. Encapsulation 3.1.2. Encapsulation
3.2. DetNet-Specific Metadata 3.2. DetNet-Specific Metadata
3.3. DetNet IP Data Plane 3.3. DetNet IP Data Plane
3.4. DetNet MPLS Data Plane 3.4. DetNet MPLS Data Plane
3.5. Further DetNet Data-Plane Considerations 3.5. Further DetNet Data Plane Considerations
3.5.1. Functions Provided on a Per-Flow Basis 3.5.1. Functions Provided on a Per-Flow Basis
3.5.2. Service Protection 3.5.2. Service Protection
3.5.3. Aggregation Considerations 3.5.3. Aggregation Considerations
3.5.4. End-System-Specific Considerations 3.5.4. End-System-Specific Considerations
3.5.5. Sub-network Considerations 3.5.5. Sub-network Considerations
4. Controller-Plane (Management and Control) Considerations 4. Controller Plane (Management and Control) Considerations
4.1. DetNet Controller-Plane Requirements 4.1. DetNet Controller Plane Requirements
4.2. Generic Controller-Plane Considerations 4.2. Generic Controller Plane Considerations
4.2.1. Flow Aggregation Control 4.2.1. Flow Aggregation Control
4.2.2. Explicit Routes 4.2.2. Explicit Routes
4.2.3. Contention Loss and Jitter Reduction 4.2.3. Contention Loss and Jitter Reduction
4.2.4. Bidirectional Traffic 4.2.4. Bidirectional Traffic
4.3. Packet Replication, Elimination, and Ordering Functions 4.3. Packet Replication, Elimination, and Ordering Functions
(PREOF) (PREOF)
5. Security Considerations 5. Security Considerations
6. IANA Considerations 6. IANA Considerations
7. References 7. References
7.1. Normative References 7.1. Normative References
skipping to change at line 99 skipping to change at line 99
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
DetNet (Deterministic Networking) provides the ability to carry DetNet (Deterministic Networking) provides the ability 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 [RFC8655]. concepts of DetNet can be found in [RFC8655].
This document describes the concepts needed by any DetNet data-plane This document describes the concepts needed by any DetNet data plane
specification (i.e., the DetNet-specific use of packet header fields) specification (i.e., the DetNet-specific use of packet header fields)
and provides considerations for any corresponding implementation. It and provides considerations for any corresponding implementation. It
covers the building blocks that provide the DetNet service, the covers the building blocks that provide the DetNet service, the
DetNet service sub-layer, and the DetNet forwarding sub-layer DetNet service sub-layer, and the DetNet forwarding sub-layer
functions as described in the DetNet architecture [RFC8655]. functions as described in the DetNet architecture [RFC8655].
The DetNet architecture models the DetNet-related data-plane The DetNet architecture models the DetNet-related data plane
functions as being decomposed into two sub-layers: a service functions as being decomposed into two sub-layers: a service
sub-layer and a forwarding sub-layer. The service sub-layer is used sub-layer and a forwarding sub-layer. The service sub-layer is used
to provide DetNet service protection and reordering. The forwarding to provide DetNet service protection and reordering. The forwarding
sub-layer leverages traffic engineering mechanisms and provides sub-layer leverages traffic engineering mechanisms and provides
congestion protection (low loss, assured latency, and limited out-of- congestion protection (low loss, assured latency, and limited out-of-
order delivery). A particular forwarding sub-layer may have order delivery). A particular forwarding sub-layer may have
capabilities that are not available on other forwarding sub-layers. capabilities that are not available on other forwarding sub-layers.
DetNet makes use of the existing forwarding sub-layers with their DetNet makes use of the existing forwarding sub-layers with their
respective capabilities and does not require 1:1 equivalence between respective capabilities and does not require 1:1 equivalence between
different forwarding sub-layer capabilities. different forwarding sub-layer capabilities.
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 typical DetNet node data plane operation. It describes the
functionality and operation of the Packet Replication Function (PRF), functionality and operation of the Packet Replication Function (PRF),
the Packet Elimination Function (PEF), and the Packet Ordering the Packet Elimination Function (PEF), and the Packet Ordering
Function (POF) within the service sub-layer. Furthermore, it Function (POF) within the service sub-layer. Furthermore, it
describes the forwarding sub-layer. describes the forwarding sub-layer.
As defined in [RFC8655], DetNet flows may be carried over network As defined in [RFC8655], DetNet flows may be carried over network
technologies that can provide service characteristics required by technologies that can provide service characteristics required by
DetNet. For example, DetNet MPLS flows can be carried over IEEE DetNet. For example, DetNet MPLS flows can be carried over IEEE
802.1 Time-Sensitive Networking (TSN) sub-networks [IEEE802.1TSNTG]. 802.1 Time-Sensitive Networking (TSN) sub-networks [IEEE802.1TSNTG].
However, IEEE 802.1 TSN support is not required in DetNet. TSN frame However, IEEE 802.1 TSN support is not required in DetNet. TSN frame
skipping to change at line 144 skipping to change at line 144
capabilities, but for such networks and traffic mixes, delay and capabilities, but for such networks and traffic mixes, delay and
jitter performance may vary due to the forwarding sub-layer's jitter performance may vary due to the forwarding sub-layer's
intrinsic properties. intrinsic properties.
Different application flows, such as Ethernet or IP, can be mapped on Different application flows, such as Ethernet or IP, can be mapped on
top of DetNet. DetNet can optionally reuse header information top of DetNet. DetNet can optionally reuse header information
provided by, or shared with, applications. An example of shared provided by, or shared with, applications. An example of shared
header fields can be found in [RFC8939]. header fields can be found in [RFC8939].
This document also covers basic concepts related to the Controller This document also covers basic concepts related to the Controller
Plane and Operations, Administration, and Maintenance (OAM). Data- Plane and Operations, Administration, and Maintenance (OAM). Data
plane OAM specifics are out of scope for this document. plane OAM specifics are out of scope for this document.
2. Terminology 2. Terminology
2.1. Terms Used in This Document 2.1. Terms Used in This Document
This document uses the terminology established in the DetNet This document uses the terminology established in the DetNet
architecture [RFC8655], and it is assumed that the reader is familiar architecture [RFC8655], and it is assumed that the reader is familiar
with that document and its terminology. with that document and its terminology.
skipping to change at line 209 skipping to change at line 209
TDM Time-Division Multiplexing TDM Time-Division Multiplexing
TSN Time-Sensitive Networking TSN Time-Sensitive Networking
YANG Yet Another Next Generation YANG Yet Another Next Generation
3. Overview of the DetNet Data Plane 3. Overview of the DetNet Data Plane
This document describes how application flows, or App-flows This document describes how application flows, or App-flows
[RFC8655], are carried over DetNet networks. The DetNet architecture [RFC8655], are carried over DetNet networks. The DetNet architecture
[RFC8655] models the DetNet-related data-plane functions as [RFC8655] models the DetNet-related data plane functions as
decomposed into two sub-layers: a service sub-layer and a forwarding decomposed into two sub-layers: a service sub-layer and a forwarding
sub-layer. sub-layer.
Figure 1, reproduced from [RFC8655], shows a logical DetNet service Figure 1, reproduced from [RFC8655], shows a logical DetNet service
with the two sub-layers. with the two sub-layers.
| packets going | ^ packets coming ^ | packets going | ^ packets coming ^
v down the stack v | up the stack | v down the stack v | up the stack |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| Source | | Destination | | Source | | Destination |
skipping to change at line 235 skipping to change at line 235
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| Forwarding sub-layer: | | Forwarding sub-layer: | | Forwarding sub-layer: | | Forwarding sub-layer: |
| Resource allocation | | Resource allocation | | Resource allocation | | Resource allocation |
| 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 tunnels or MPLS. DetNet service sub-layer -- for example, by IP tunnels or MPLS.
Alternatively, an overlay approach may be used in which the packet is Alternatively, an overlay approach may be used in which the packet is
natively carried between key nodes within the DetNet network (say, natively carried between key nodes within the DetNet network (say,
between PREOF nodes), and a sub-layer is used to provide the between PREOF nodes), and a sub-layer is used to provide the
information needed to reach the next hop in the overlay. information needed to reach the next hop in the overlay.
The forwarding sub-layer provides the QoS-related functions needed by The forwarding sub-layer provides the QoS-related functions needed by
the DetNet flow. It may do this directly through the use of queuing the DetNet flow. It may do this directly through the use of queuing
skipping to change at line 263 skipping to change at line 263
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. See Section 4.3 connectivity function of the forwarding sub-layer. See Section 4.3
regarding PREOF. The POF uses sequence numbers added to packets, regarding PREOF. The POF uses sequence numbers added to packets,
enabling a range of packet order protection from simple ordering and enabling a range of packet order protection from simple ordering and
dropping out-of-order packets to more complex reordering of a fixed dropping out-of-order packets to more complex reordering of a fixed
number of out-of-order, minimally delayed packets. Reordering number of out-of-order, minimally delayed packets. Reordering
requires buffer resources and has an impact on the delay and jitter requires buffer resources and has an impact on the delay and jitter
of packets in the DetNet flow. of packets in the DetNet flow.
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, and more than one approach may particular DetNet data plane method, and more than one approach may
be applicable to a given network type. be applicable to a given network type.
3.1. Data-Plane Characteristics 3.1. Data Plane Characteristics
The data plane has two major characteristics: the technology and the The data plane has two major characteristics: the technology and the
encapsulation, as discussed below. encapsulation, as discussed below.
3.1.1. Data-Plane Technology 3.1.1. Data Plane Technology
The DetNet data plane is provided by the DetNet service and The DetNet data plane is provided by the DetNet service and
forwarding sub-layers. The DetNet service sub-layer generally forwarding sub-layers. The DetNet service sub-layer generally
provides its functions for the DetNet application flows by using or provides its functions for the DetNet application flows by using or
applying existing standardized headers and/or encapsulations. The applying existing standardized headers and/or encapsulations. The
DetNet forwarding sub-layer may provide capabilities leveraging that DetNet forwarding sub-layer may provide capabilities leveraging that
same header or encapsulation technology (e.g., DN IP or DN MPLS), or same header or encapsulation technology (e.g., DN IP or DN MPLS), or
it may be achieved via other technologies, as shown in Figure 2 it may be achieved via other technologies, as shown in Figure 2
below. DetNet is currently defined for operation over packet- below. DetNet is currently defined for operation over packet-
switched (IP) networks or label-switched (MPLS) networks. switched (IP) networks or label-switched (MPLS) networks.
3.1.2. Encapsulation 3.1.2. Encapsulation
DetNet encodes specific flow attributes (flow identity and sequence DetNet encodes specific flow attributes (flow identity and sequence
number) in packets. For example, in DetNet IP, zero encapsulation is number) in packets. For example, in DetNet IP, zero encapsulation is
used, and no sequence number is available; in DetNet MPLS, DetNet- used, and no sequence number is available; in DetNet MPLS, DetNet-
specific information may be added explicitly to the packets in the specific information may be added explicitly to the packets in the
form of an S-Label and a d-CW [DetNet-MPLS]. form of an S-Label and a d-CW [DetNet-MPLS].
The encapsulation of a DetNet flow allows it to be sent over a data- The encapsulation of a DetNet flow allows it to be sent over a data
plane technology other than its native type. DetNet uses header plane technology other than its native type. DetNet uses header
information to perform traffic classification, i.e., identify DetNet information to perform traffic classification, i.e., identify DetNet
flows, and provide DetNet service and forwarding functions. As flows, and provide DetNet service and forwarding functions. As
mentioned above, DetNet may add headers, as is the case for DN MPLS, mentioned above, DetNet may add headers, as is the case for DN MPLS,
or may use headers that are already present, as is the case for DN or may use headers that are already present, as is the case for DN
IP. Figure 2 illustrates some relationships between the components. IP. Figure 2 illustrates some relationships between the components.
+-----+ +-----+
| TSN | | TSN |
+-------+ +-+-----+-+ +-------+ +-+-----+-+
skipping to change at line 328 skipping to change at line 328
equipment with limited DetNet capability. equipment with limited DetNet capability.
3.2. DetNet-Specific Metadata 3.2. DetNet-Specific Metadata
The DetNet data plane can provide or carry the following metadata: The DetNet data plane can provide or carry the following metadata:
1. Flow-ID 1. Flow-ID
2. Sequence number 2. Sequence number
The DetNet data-plane framework supports a Flow-ID (for The DetNet data plane framework supports a Flow-ID (for
identification of the flow or aggregate flow) and/or a sequence identification of the flow or aggregate flow) and/or a sequence
number (for PREOF) for each DetNet flow. The Flow-ID is used by both number (for PREOF) for each DetNet flow. The Flow-ID is used by both
the service and forwarding sub-layers, but the sequence number is the service and forwarding sub-layers, but the sequence number is
only used by the service layer. Metadata can also be used for OAM only used by the service layer. Metadata can also be used for OAM
indications and instrumentation of DetNet data-plane operation. indications and instrumentation of DetNet data plane operation.
Metadata inclusion can be implicit or explicit. Explicit inclusions Metadata inclusion can be implicit or explicit. Explicit inclusions
involve a dedicated header field that is used to include metadata in involve a dedicated header field that is used to include metadata in
a DetNet packet. In the implicit method, part of an already-existing a DetNet packet. In the implicit method, part of an already-existing
header field is used to encode the metadata. header field is used to encode the metadata.
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 extension and will not be discussed further in this text. IPv6 extension
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 toolbox of the of an existing one is a technique available in the toolbox 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 d-CW, using through the inclusion of an MPLS label stack and the MPLS d-CW, using
one of the methods for carrying MPLS over IP one of the methods for carrying MPLS over IP
[DetNet-MPLS-over-UDP-IP]. This is described in more detail in [DetNet-MPLS-over-UDP-IP]. This is described in more detail in
Section 3.5.5. Section 3.5.5.
Implicit metadata in IP can be included through the use of the Implicit metadata in IP can be included through the use of the
network programming paradigm [SRv6-Network-Prog], in which the suffix network programming paradigm [SRv6-Network-Prog], in which the suffix
of an IPv6 address is used to encode additional information for use of an IPv6 address is used to encode additional information for use
skipping to change at line 410 skipping to change at line 410
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, the d-CW [DetNet-MPLS] can be used. packet at the service sub-layer, the d-CW [DetNet-MPLS] can be used.
Although such d-CWs are frequently 32 bits long, there is no Although such d-CWs are frequently 32 bits long, there is no
architectural constraint on the size of this structure -- only the architectural constraint on the size of this structure -- only the
requirement that it be fully understood by all parties operating on requirement that it be fully understood by all parties operating on
it in the DetNet service sub-layer. The operation of this method is it in the DetNet service sub-layer. The operation of this method is
described in detail in [DetNet-MPLS]. described in detail in [DetNet-MPLS].
3.5. Further DetNet Data-Plane Considerations 3.5. Further DetNet Data Plane Considerations
This section provides informative considerations related to providing This section provides informative considerations related to providing
DetNet service to flows that are identified based on their header DetNet service to flows that are identified based on their header
information. information.
3.5.1. Functions Provided on a Per-Flow Basis 3.5.1. Functions Provided on a Per-Flow Basis
At a high level, the following functions are provided on a per-flow At a high level, the following functions are provided on a per-flow
basis. basis.
skipping to change at line 639 skipping to change at line 639
resource level and then tracking the services in the aggregated resource level and then tracking the services in the aggregated
service or adjusting the aggregated resources as the services are service or adjusting the aggregated resources as the services are
added is implementation and technology specific. added is 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 requirements are not satisfied. where requirements are not satisfied.
3.5.3.1. IP Aggregation 3.5.3.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 6-tuple [RFC8939]. Alternatively, an IP characteristics such as 6-tuple [RFC8939]. Alternatively, an IP
encapsulation may be used to tunnel an aggregate number of DetNet encapsulation may be used to tunnel an aggregate number of DetNet
flows between relay nodes. flows between relay nodes.
3.5.3.2. MPLS Aggregation 3.5.3.2. MPLS Aggregation
MPLS aggregation also has data-plane and Controller-Plane aspects. MPLS aggregation also has data plane and Controller Plane aspects.
MPLS flows are often tunneled in a forwarding sub-layer, under the MPLS flows are often tunneled in a forwarding sub-layer, under the
reservation associated with that MPLS tunnel. reservation associated with that MPLS tunnel.
3.5.4. End-System-Specific Considerations 3.5.4. 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 the application and its end systems. Encapsulation depends on the application and its
preferences. For example, in a DetNet MPLS domain, the sub-layer preferences. For example, in a DetNet MPLS domain, the sub-layer
functions use the d-CWs, S-Labels, and F-Labels [DetNet-MPLS] to functions use the d-CWs, S-Labels, and F-Labels [DetNet-MPLS] to
provide DetNet services. However, an application may exchange provide DetNet services. However, an application may exchange
skipping to change at line 726 skipping to change at line 726
+-----+======+--+======+--+======+-----+ +-----+======+--+======+--+======+-----+
Sub-network | L2 | | TSN | | UDP | Sub-network | L2 | | TSN | | UDP |
+------+ +------+ +------+ +------+ +------+ +------+
| IP | | IP |
+------+ +------+
| L2 | | L2 |
+------+ +------+
Figure 5: Example DetNet MPLS Encapsulations in Sub-networks Figure 5: Example DetNet MPLS Encapsulations in Sub-networks
4. Controller-Plane (Management and Control) Considerations 4. Controller Plane (Management and Control) Considerations
4.1. DetNet Controller-Plane Requirements 4.1. DetNet Controller Plane Requirements
The Controller Plane corresponds to the aggregation of the Control The Controller Plane corresponds to the aggregation of the Control
and Management Planes discussed in [RFC7426] and [RFC8655]. While and Management Planes discussed in [RFC7426] and [RFC8655]. While
more details regarding any DetNet Controller Plane are out of scope more details regarding any DetNet Controller Plane are out of scope
for this document, there are particular considerations and for this document, there are particular considerations and
requirements for the Controller Plane that result from the unique requirements for the Controller Plane that result from the unique
characteristics of the DetNet architecture and data plane as defined characteristics of the DetNet architecture and data plane as defined
herein. herein.
The primary requirements of the DetNet Controller Plane are that it The primary requirements of the DetNet Controller Plane are that it
skipping to change at line 774 skipping to change at line 774
location in the network and the DetNet functionality (e.g., location in the network and the DetNet functionality (e.g.,
transit node vs. relay node). transit node vs. relay node).
These requirements, as stated earlier, could be satisfied using These requirements, as stated earlier, could be satisfied using
distributed control protocol signaling (such as RSVP-TE), centralized distributed control protocol signaling (such as RSVP-TE), centralized
network management provisioning mechanisms (BGP, PCEP, YANG, network management provisioning mechanisms (BGP, PCEP, YANG,
[DetNet-Flow-Info], etc.), or hybrid combinations of the two, and [DetNet-Flow-Info], etc.), or hybrid combinations of the two, and
could also make use of MPLS-based segment routing. could also make use of MPLS-based segment routing.
In the abstract, the results of either distributed signaling or In the abstract, the results of either distributed signaling or
centralized provisioning are equivalent from a DetNet data-plane centralized provisioning are equivalent from a DetNet data plane
perspective -- flows are instantiated, explicit routes are perspective -- flows are instantiated, explicit routes are
determined, resources are reserved, and packets are forwarded through determined, resources are reserved, and packets are forwarded through
the domain using the DetNet data plane. the domain using the DetNet data plane.
However, from a practical and implementation standpoint, Controller- However, from a practical and implementation standpoint, Controller
Plane alternatives are not equivalent at all. Some approaches are Plane alternatives are not equivalent at all. Some approaches are
more scalable than others in terms of signaling load on the network. more scalable than others in terms of signaling load on the network.
Some alternatives can take advantage of global tracking of resources Some alternatives can take advantage of global tracking of resources
in the DetNet domain for better overall network resource in the DetNet domain for better overall network resource
optimization. Some solutions are more resilient than others if link, optimization. Some solutions are more resilient than others if link,
node, or management equipment failures occur. While a detailed node, or management equipment failures occur. While a detailed
analysis of the control-plane alternatives is out of scope for this analysis of the control plane alternatives is out of scope for this
document, the requirements from this document can be used as the document, the requirements from this document can be used as the
basis of a future analysis of the alternatives. basis of a future analysis of the alternatives.
4.2. Generic Controller-Plane Considerations 4.2. Generic Controller Plane Considerations
This section covers control-plane considerations that are independent This section covers control plane considerations that are independent
of the data-plane technology used for DetNet service delivery. of the data plane technology used for DetNet service delivery.
While the management plane and the control plane are traditionally While the management plane and the control plane are traditionally
considered separately, from a data-plane perspective, there is no considered separately, from a data plane perspective, there is no
practical difference based on the origin of flow-provisioning practical difference based on the origin of flow-provisioning
information, and the DetNet architecture [RFC8655] refers to these information, and the DetNet architecture [RFC8655] refers to these
collectively as the "Controller Plane". This document therefore does collectively as the "Controller Plane". This document therefore does
not distinguish between information provided by distributed control- not distinguish between information provided by distributed control
plane protocols (e.g., RSVP-TE [RFC3209] [RFC3473]) or centralized plane protocols (e.g., RSVP-TE [RFC3209] [RFC3473]) or centralized
network management mechanisms (e.g., RESTCONF [RFC8040], YANG network management mechanisms (e.g., RESTCONF [RFC8040], YANG
[RFC7950], PCEP [PCECC]), or any combination thereof. Specific [RFC7950], PCEP [PCECC]), or any combination thereof. Specific
considerations and requirements for the DetNet Controller Plane are considerations and requirements for the DetNet Controller Plane are
discussed in Section 4.1. discussed in Section 4.1.
Each respective data-plane document also covers the control-plane Each respective data plane document also covers the control plane
considerations for that technology. For example, [RFC8939] also considerations for that technology. For example, [RFC8939] also
covers IP control-plane normative considerations, and [DetNet-MPLS] covers IP control plane normative considerations, and [DetNet-MPLS]
also covers MPLS control-plane normative considerations. also covers MPLS control plane normative considerations.
4.2.1. Flow Aggregation Control 4.2.1. Flow Aggregation Control
Flow aggregation means that multiple App-flows are served by a single Flow aggregation means that multiple App-flows are served by a single
new DetNet flow. There are many techniques to achieve aggregation. new DetNet flow. There are many techniques to achieve aggregation.
For example, in the case of IP, IP flows that share 6-tuple For example, in the case of IP, IP flows that share 6-tuple
attributes or flow identifiers at the DetNet sub-layer can be attributes or flow identifiers at the DetNet sub-layer can be
grouped. Another example includes aggregation accomplished through grouped. Another example includes aggregation accomplished through
the use of hierarchical LSPs in MPLS and tunnels. the use of hierarchical LSPs in MPLS and tunnels.
Control of aggregation involves a set of procedures listed here. Control of aggregation involves a set of procedures listed here.
Aggregation may use some or all of these capabilities, and the order Aggregation may use some or all of these capabilities, and the order
may vary: may vary:
Traffic engineering resource collection and distribution: 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 or management plane databases and distributed amongst controllers or
nodes that can manage resources. nodes that can manage resources.
Path computation and resource allocation: 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.
Resource assignment and data-plane coordination: Resource assignment and data plane coordination:
The assignment of resources along the path depends on the The assignment of resources along the path depends on the
technology and includes assignment of specific links, coordination technology and includes assignment of specific links, coordination
of queuing, and other traffic management capabilities such as of queuing, and other traffic management capabilities such as
policing and shaping. policing and shaping.
Assigned resource recording and updating: 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 updated and distributed in the databases, preventing
oversubscription. oversubscription.
skipping to change at line 929 skipping to change at line 929
important property of co-routed bidirectional LSPs is that their important property of co-routed bidirectional LSPs is that their
unidirectional component LSPs share fate. In both types of unidirectional component LSPs share fate. In both types of
bidirectional LSPs, resource reservations may differ in each bidirectional LSPs, resource reservations may differ in each
direction. The concepts of associated bidirectional flows and direction. The concepts of associated bidirectional flows and
co-routed bidirectional flows can also be applied to DetNet IP flows. co-routed bidirectional flows can also be applied to DetNet IP flows.
While the DetNet IP data plane must support bidirectional DetNet While the DetNet IP data plane must support bidirectional DetNet
flows, there are no special bidirectional features with respect to flows, there are no special bidirectional features with respect to
the data plane other than the need for the two directions of a the data plane other than the need for the two directions of a
co-routed bidirectional flow to take the same path. That is to say, co-routed bidirectional flow to take the same path. That is to say,
bidirectional DetNet flows are solely represented at the management- bidirectional DetNet flows are solely represented at the management
plane and control-plane levels, without specific support or knowledge plane and control plane levels, without specific support or knowledge
within the DetNet data plane. Fate-sharing and associated or within the DetNet data plane. Fate-sharing and associated or
co-routed bidirectional flows can be managed at the control level. co-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, because if PREOF are used, the replication bidirectional flows, because if PREOF are used, 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. In such cases, the optimal the other direction, and vice versa. In such cases, the optimal
points for these functions in one direction may not match the optimal points for these functions in one direction may not match the optimal
points in the other, due to network and traffic constraints. points in the other, due to network and traffic constraints.
Furthermore, due to the per-packet service protection nature, Furthermore, due to the per-packet service protection nature,
bidirectional forwarding may not be ensured. The first packet of bidirectional forwarding may not be ensured. The first packet of
received member flows is selected by the elimination function received member flows is selected by the elimination function
independently of which path it has taken through the network. 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 is out of scope for flows, but the specification of such mechanisms is out of scope for
this document. Example control-plane solutions for MPLS can be found this document. Example control plane solutions for MPLS can be found
in [RFC3473], [RFC6387], and [RFC7551]. These requirements are in [RFC3473], [RFC6387], and [RFC7551]. These requirements are
included in Section 4.1. included in Section 4.1.
4.3. Packet Replication, Elimination, and Ordering Functions (PREOF) 4.3. Packet Replication, Elimination, and Ordering Functions (PREOF)
The Controller-Plane protocol solution required for managing the The Controller Plane protocol solution required for managing the
processing of PREOF is outside the scope of this document. That processing of PREOF is outside the scope of this document. That
said, it should be noted that the ability to determine, for a said, it should be noted that the ability to determine, for a
particular flow, optimal packet replication and elimination points in particular flow, optimal packet replication and elimination points in
the DetNet domain requires explicit support. There may be existing the DetNet domain requires explicit support. There may be existing
capabilities that can be used or extended -- for example, GMPLS end- capabilities that can be used or extended -- for example, GMPLS end-
to-end recovery [RFC4872] and GMPLS segment recovery [RFC4873]. to-end recovery [RFC4872] and GMPLS segment recovery [RFC4873].
5. Security Considerations 5. Security Considerations
Security considerations for DetNet are described in detail in Security considerations for DetNet are described in detail in
skipping to change at line 984 skipping to change at line 984
As for all communications protocols, the primary consideration for As for all communications protocols, the primary consideration for
the data plane is to maintain integrity of data and delivery of the the data plane is to maintain integrity of data and delivery of the
associated DetNet service traversing the DetNet network. Application associated DetNet service traversing the DetNet network. Application
flows can be protected through whatever means is provided by the flows can be protected through whatever means is provided by the
underlying technology. For example, encryption may be used, such as underlying technology. For example, encryption may be used, such as
that provided by IPsec [RFC4301] for IP flows and/or by an underlying that provided by IPsec [RFC4301] for IP flows and/or by an underlying
sub-network using MACsec [IEEE802.1AE-2018] for Ethernet (Layer 2) sub-network using MACsec [IEEE802.1AE-2018] for Ethernet (Layer 2)
flows. flows.
At the management and control levels, DetNet flows are identified on At the management and control levels, DetNet flows are identified on
a per-flow basis, which may provide Controller-Plane attackers with a per-flow basis, which may provide Controller Plane attackers with
additional information about the data flows (when compared to additional information about the data flows (when compared to
Controller Planes that do not include per-flow identification). This Controller Planes that do not include per-flow identification). This
is an inherent property of DetNet that has security implications that is an inherent property of DetNet that has security implications that
should be considered when determining if DetNet is a suitable should be considered when determining if DetNet is a suitable
technology for any given use case. technology for any given use case.
To provide uninterrupted availability of the DetNet service, To provide uninterrupted availability of the DetNet service,
provisions can be made against DoS attacks and delay attacks. To provisions can be made against DoS attacks and delay attacks. To
protect against DoS attacks, excess traffic due to malicious or protect against DoS attacks, excess traffic due to malicious or
malfunctioning devices can be prevented or mitigated -- for example, malfunctioning devices can be prevented or mitigated -- for example,
skipping to change at line 1052 skipping to change at line 1052
tsn-04>. tsn-04>.
[DetNet-MPLS-over-UDP-IP] [DetNet-MPLS-over-UDP-IP]
Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "DetNet Data Plane: MPLS over UDP/IP", Work in Bryant, "DetNet Data Plane: MPLS over UDP/IP", Work in
Progress, Internet-Draft, draft-ietf-detnet-mpls-over-udp- Progress, Internet-Draft, draft-ietf-detnet-mpls-over-udp-
ip-07, 11 October 2020, <https://tools.ietf.org/html/ ip-07, 11 October 2020, <https://tools.ietf.org/html/
draft-ietf-detnet-mpls-over-udp-ip-07>. draft-ietf-detnet-mpls-over-udp-ip-07>.
[DetNet-Security] [DetNet-Security]
Mizrahi, T. and E. Grossman, Ed., "Deterministic Grossman, E., Ed., Mizrahi, T., and A. Hacker,
Networking (DetNet) Security Considerations", Work in "Deterministic Networking (DetNet) Security
Progress, Internet-Draft, draft-ietf-detnet-security-12, 2 Considerations", Work in Progress, Internet-Draft, draft-
October 2020, <https://tools.ietf.org/html/draft-ietf- ietf-detnet-security-12, 2 October 2020,
detnet-security-12>. <https://tools.ietf.org/html/draft-ietf-detnet-security-
12>.
[Flow-Spec-Rules] [Flow-Spec-Rules]
Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules", Work Bacher, "Dissemination of Flow Specification Rules", Work
in Progress, Internet-Draft, draft-ietf-idr-rfc5575bis-27, in Progress, Internet-Draft, draft-ietf-idr-rfc5575bis-27,
15 October 2020, <https://tools.ietf.org/html/draft-ietf- 15 October 2020, <https://tools.ietf.org/html/draft-ietf-
idr-rfc5575bis-27>. idr-rfc5575bis-27>.
[IEEE802.1AE-2018] [IEEE802.1AE-2018]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
 End of changes. 39 change blocks. 
51 lines changed or deleted 52 lines changed or added

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