draft-ietf-detnet-data-plane-framework-05.txt   draft-ietf-detnet-data-plane-framework-06.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: October 25, 2020 L. Berger Expires: November 7, 2020 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
April 23, 2020 May 6, 2020
DetNet Data Plane Framework DetNet Data Plane Framework
draft-ietf-detnet-data-plane-framework-05 draft-ietf-detnet-data-plane-framework-06
Abstract Abstract
This document provides an overall framework for the DetNet data This document provides an overall framework for the DetNet data
plane. It covers concepts and considerations that are generally plane. It covers concepts and considerations that are generally
common to any Deterministic Networking data plane specification. common to any Deterministic Networking data plane specification. It
describes related controller plane considerations as well.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 25, 2020. This Internet-Draft will expire on November 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 15 skipping to change at page 3, line 15
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. 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 as being decomposed into two sub-layers: a service sub-
forwarding sub-layer. The service sub-layer is used to provide layer and a forwarding sub-layer. The service sub-layer is used to
DetNet service protection and reordering. The forwarding sub-layer provide DetNet service protection and reordering. The forwarding
leverages Traffic Engineering mechanisms and provides congestion sub-layer leverages Traffic Engineering mechanisms and provides
protection (low loss, assured latency, and limited out-of-order congestion protection (low loss, assured latency, and limited out-of-
delivery). A particular forwarding sub-layer may have capabilities order delivery). A particular forwarding sub-layer may have
that are not available on other forwarding-sub layers. DetNet makes capabilities that are not available on other forwarding-sub layers.
use of the existing forwarding sub-layers with their respective DetNet makes use of the existing forwarding sub-layers with their
capabilities and does not require 1:1 equivalence between different respective capabilities and does not require 1:1 equivalence between
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 (PRF), Packet functionality and operation of the Packet Replication (PRF), Packet
Elimination (PEF), and the Packet Ordering (POF) functions within the Elimination (PEF), and the Packet Ordering (POF) functions within the
service sub-layer. Furthermore, it describes the forwarding sub- service sub-layer. Furthermore, it describes the forwarding sub-
layer. 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 the DetNet required service technologies that can provide the DetNet required service
characteristics. For example, DetNet MPLS flows can be carried over characteristics. For example, DetNet MPLS flows can be carried over
IEEE 802.1 Time Sensitive Network (TSN) [IEEE802.1TSNTG] sub- IEEE 802.1 Time Sensitive Network (TSN) [IEEE802.1TSNTG] sub-
networks. However, IEEE 802.1 TSN support is not required in DetNet. networks. However, IEEE 802.1 TSN support is not required in DetNet.
TSN frame preemption is an example of a forwarding layer capability TSN frame preemption is an example of a forwarding layer capability
that is typically not replicated in other forwarding technologies. that is typically not replicated in other forwarding technologies.
Most of DetNet benefits can be gained by running over a data link Most of DetNet benefits can be gained by running over a data link
layer that has not been specifically enhanced to support all TSN layer that has not been specifically enhanced to support all TSN
capabilities but for certain networks and traffic mixes delay and capabilities but for such networks and traffic mixes delay and jitter
jitter performance may vary due to the forwarding sub-layer intrinsic performance may vary due to the forwarding sub-layer intrinsic
properties. 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 [I-D.ietf-detnet-ip]. header fields can be found in [I-D.ietf-detnet-ip].
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.
skipping to change at page 5, line 43 skipping to change at page 5, line 43
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
techniques and traffic engineering methods, or it may do this through techniques and traffic engineering methods, or it may do this through
the assistance of its underlying connectivity. For example it may the assistance of its underlying connectivity. For example 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]. The forwarding sub-layer uses buffer resources for [IEEE802.1TSNTG]. The forwarding sub-layer uses buffer resources for
packet queuing, as well as reservation and allocation of bandwidth packet queuing, as well as reservation and allocation of bandwidth
capacity resources. capacity resources.
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. See Section 4.3
this is Packet Replication, Elimination, and Ordering functions see as an example for Packet Replication, Elimination, and Ordering
Section 4.3. The ordering function (POF) uses sequence numbers added functions. The ordering function (POF) uses sequence numbers added
to packets enabling a range of packet order protection from simple to packets enabling a range of packet order protection from simple
ordering and dropping out-of-order packets to more complex reordering ordering and dropping out-of-order packets to more complex reordering
of a fixed number of out-of-order, minimally delayed packets. of a fixed number of out-of-order, minimally delayed packets.
Reordering requires buffer resources and has impact on the delay and Reordering requires buffer resources and has impact on the delay and
jitter of packets in the DetNet flow. jitter 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 bearer network type. be applicable to a given network type.
3.1. Data Plane Characteristics 3.1. Data Plane Characteristics
There are two major characteristics to the data plane: the technology There are two major characteristics to the data plane: the technology
and the encapsulation, as discussed below. and the 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 by other technologies (e.g., Figure 2). DetNet is it may be achieved by other technologies as shown in Figure 2.
currently defined for operation over packet-switched (IP) networks or DetNet is currently defined for operation over packet-switched (IP)
label-switched (MPLS) networks. 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, and in DetNet MPLS, DetNet- used and no sequence number is available, and 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
format of S-label and d-CW [I-D.ietf-detnet-mpls] . form of S-label and d-CW [I-D.ietf-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 in DN IP. or may use headers that are already present, as is the case in DN IP.
Figure 2 illustrates some relationships between the components. Figure 2 illustrates some relationships between the components.
+-----+ +-----+
skipping to change at page 7, line 25 skipping to change at page 7, line 25
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 DetNet Service sub- Number (for PREOF) for each DetNet flow. The Flow-ID is used by both
layer requires both; the DetNet forwarding sub-layer requires only the service and forwarding sub-layers, but the sequence number is
Flow-ID. Metadata can also be used for OAM indications and only used by the service layer. Metadata can also be used for OAM
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 extensions and will not be discussed further in this text. IPv6 extensions
skipping to change at page 8, line 9 skipping to change at page 8, line 9
[I-D.ietf-detnet-mpls-over-udp-ip]. This is described in more detail [I-D.ietf-detnet-mpls-over-udp-ip]. This is described in more detail
in Section 3.5.5. in 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 network programming paradigm
[I-D.ietf-spring-srv6-network-programming] in which the suffix of an [I-D.ietf-spring-srv6-network-programming] in which the suffix of an
IPv6 address is used to encode additional information for use by the IPv6 address is used to encode additional information for use by the
network of the receiving host. network of the receiving host.
Some MPLS examples of implicit metadata include the sequence number An MPLS example of explicit metadata is the sequence number used by
for use by the PREOF function, or even all the essential information the PREOF function, or even the case where all the essential
being included into the DetNet over MPLS label stack (the DetNet information being included into the DetNet over MPLS label stack (the
Control Word and the DetNet Service label). DetNet Control Word and the DetNet Service label).
3.3. DetNet IP Data Plane 3.3. 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. Many types of IP encapsulation can satisfy DetNet encapsulation. Many types of IP encapsulation can satisfy DetNet
requirements and it is anticipated that more than one encapsulation requirements and it is anticipated that more than one encapsulation
may be deployed, for example GRE, IPSec. may be deployed, for example GRE, IPSec.
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
skipping to change at page 10, line 38 skipping to change at page 10, line 38
and traffic loads, Network Coding can be used to improve a network's and traffic loads, Network Coding can be used to improve a network's
throughput, efficiency, latency, and scalability, as well as throughput, efficiency, latency, and scalability, as well as
resilience to partition, attacks, and eavesdropping, as compared to resilience to partition, attacks, and eavesdropping, as compared to
traditional methods. DetNet could use Network coding as an traditional methods. DetNet could use Network coding as an
alternative to other protection means. Network coding is often alternative to other protection means. Network coding is often
applied in wireless networks and is being explored for other network applied in wireless networks and is being explored for other network
types. types.
3.5.1.5. Load sharing 3.5.1.5. Load sharing
Use of packet-by-packet distribution of the same DetNet flow over Use of packet-by-packet load sharing of the same DetNet flow over
multiple paths is not recommended except for the cases listed above multiple paths is not recommended except for the cases listed above
where PREOF is utilized to improve protection of traffic and maintain where PREOF is utilized to improve protection of traffic and maintain
order. Packet by packet load sharing, e.g., via ECMP or UCMP, order. Packet-by-packet load sharing, e.g., via ECMP or UCMP,
impacts ordering and possibly jitter. impacts ordering and possibly jitter.
3.5.1.6. Troubleshooting 3.5.1.6. Troubleshooting
Detnet leverages many different forwarding sub-layers, each of which Detnet leverages many different forwarding sub-layers, each of which
supports various tools to troubleshoot connectivity, for example supports various tools to troubleshoot connectivity, for example
identification of misbehaving flows. The DetNet Service layer can identification of misbehaving flows. The DetNet Service layer can
leverage existing mechanisms to troubleshoot or monitor flows, such leverage existing mechanisms to troubleshoot or monitor flows, such
as those in use by IP and MPLS networks. At the Application layer a as those in use by IP and MPLS networks. At the Application layer a
client of a DetNet service can use existing techniques to detect and client of a DetNet service can use existing techniques to detect and
skipping to change at page 13, line 49 skipping to change at page 13, line 49
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. Alternatively, an IP encapsulation characteristics such as 6-tuple [I-D.ietf-detnet-ip]. Alternatively,
may be used to tunnel an aggregate number of DetNet Flows between an IP encapsulation may be used to tunnel an aggregate number of
relay nodes. DetNet 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
skipping to change at page 16, line 47 skipping to change at page 16, line 47
[I-D.ietf-detnet-flow-information-model], etc.) or hybrid [I-D.ietf-detnet-flow-information-model], etc.) or hybrid
combinations of the two, and could also make use of MPLS-based combinations of the two, and could also make use of MPLS-based
segment routing. 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 determined, perspective - flows are instantiated, explicit routes are determined,
resources are reserved, and packets are forwarded through the domain resources are reserved, and packets are forwarded through the domain
using the DetNet data plane. using the DetNet data plane.
However, from a practical and implementation standpoint, they are not However, from a practical and implementation standpoint, controller
equivalent at all. Some approaches are more scalable than others in plane alternatives are not equivalent at all. Some approaches are
terms of signaling load on the network. Some can take advantage of more scalable than others in terms of signaling load on the network.
global tracking of resources in the DetNet domain for better overall Some alternatives can take advantage of global tracking of resources
network resource optimization. Some are more resilient than others in the DetNet domain for better overall network resource
if link, node, or management equipment failures occur. While a optimization. Some solutions are more resilient than others if link,
detailed analysis of the control plane alternatives is out of the node, or management equipment failures occur. While a detailed
scope of this document, the requirements from this document can be analysis of the control plane alternatives is out of the scope of
used as the basis of a later analysis of the alternatives. this document, the requirements from this document can be used as the
basis of a later 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 control planes are traditionally While the management plane and control planes are traditionally
considered separately, from the data plane perspective there is no considered separately, from the 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
skipping to change at page 18, line 29 skipping to change at page 18, line 31
are updated and distributed in the databases, preventing over- are 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 per-node 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.ietf-detnet-mpls-over-tsn] ) DetNet parameters can discussed in [I-D.ietf-detnet-mpls-over-tsn] ) DetNet parameters can
be maintained. Further considerations and requirements for the be maintained. Further considerations and requirements for the
DetNet 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.
skipping to change at page 19, line 10 skipping to change at page 19, line 14
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.
o The path could be implemented using IPv6-based segment routing o The path could be implemented using IPv6-based segment routing
when extended to support resource allocation. when extended to support resource allocation.
See Section 4.1 for further discussion of these alternatives. In See Section 4.1 for further discussion of these alternatives. In
addition, [RFC2386] contains useful background information on QoS- addition, [RFC2386] contains useful background information on QoS-
based routing, and [RFC5575] discusses a specific mechanism used by based routing, and [RFC5575] (being updated by
BGP for traffic flow specification and policy-based routing. [I-D.ietf-idr-rfc5575bis]) discusses a specific mechanism used by BGP
for traffic flow specification and policy-based routing.
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
skipping to change at page 20, line 38 skipping to change at page 20, line 41
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 (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 may be capabilities that can domain requires explicit support. There may be existing capabilities
be used, or extended, for example GMPLS end-to-end recovery [RFC4872] that can be used, or extended, for example GMPLS end-to-end recovery
and GMPLS segment recovery [RFC4873]. [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
[I-D.ietf-detnet-security]. General security considerations for [I-D.ietf-detnet-security]. General security considerations for
DetNet architecture are described in [RFC8655]. This section DetNet architecture are described in [RFC8655]. This section
considers general security considerations applicable to all data considers architecture-level DetNet security considerations
planes. applicable to all data planes.
Security aspects which are unique to DetNet are those whose aim is to Part of what makes DetNet unique is its ability to provide specific
provide the specific quality of service aspects of DetNet, which are and reliable quality of service (delivering data flows with extremely
primarily to deliver data flows with extremely low packet loss rates low packet loss rates and bounded end-to-end delivery latency), and
and bounded end-to-end delivery latency. the security-related aspects of protecting that quality of service
are similarly unique.
The primary consideration for the data plane is to maintain integrity As for all communications protocols, the primary consideration for
of data and delivery of the associated DetNet service traversing the the data plane is to maintain integrity of data and delivery of the
DetNet network. Application flows can be protected through whatever associated DetNet service traversing the DetNet network. Application
means is provided by the underlying technology. For example, flows can be protected through whatever means is provided by the
encryption may be used, such as that provided by IPSec [RFC4301] for underlying technology. For example, encryption may be used, such as
IP flows and/or by an underlying sub-net using MACSec that provided by IPSec [RFC4301] for IP flows and/or by an underlying
[IEEE802.1AE-2018] for Ethernet (Layer-2) flows. sub-net using MACSec [IEEE802.1AE-2018] for Ethernet (Layer-2) flows.
At the management and control level DetNet flows are identified on a At the management and control level DetNet flows are identified on a
per-flow basis, which may provide controller plane attackers with per-flow basis, which may provide controller plane attackers with
additional information about the data flows (when compared to additional information about the data flows (when compared to
controller planes that do not include per-flow identification). This controller planes that do not include per-flow identification). This
is an inherent property of DetNet which has security implications is an inherent property of DetNet which has security implications
that should be considered when determining if DetNet is a suitable that 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,
skipping to change at page 22, line 17 skipping to change at page 22, line 17
The following people contributed substantially to the content of this The following people contributed substantially to the content of this
document: document:
Don Fedyk Don Fedyk
Jouni Korhonen Jouni Korhonen
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655, "Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019, DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>. <https://www.rfc-editor.org/info/rfc8655>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-detnet-flow-information-model] [I-D.ietf-detnet-flow-information-model]
Farkas, J., Varga, B., Cummings, R., Jiang, Y., and D. Farkas, J., Varga, B., Cummings, R., Jiang, Y., and D.
Fedyk, "DetNet Flow Information Model", draft-ietf-detnet- Fedyk, "DetNet Flow Information Model", draft-ietf-detnet-
skipping to change at page 23, line 28 skipping to change at page 23, line 10
Varga, B., Farkas, J., Berger, L., Malis, A., and S. Varga, B., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "DetNet Data Plane: MPLS over UDP/IP", draft-ietf- Bryant, "DetNet Data Plane: MPLS over UDP/IP", draft-ietf-
detnet-mpls-over-udp-ip-05 (work in progress), February detnet-mpls-over-udp-ip-05 (work in progress), February
2020. 2020.
[I-D.ietf-detnet-security] [I-D.ietf-detnet-security]
Mizrahi, T. and E. Grossman, "Deterministic Networking Mizrahi, T. and E. Grossman, "Deterministic Networking
(DetNet) Security Considerations", draft-ietf-detnet- (DetNet) Security Considerations", draft-ietf-detnet-
security-09 (work in progress), March 2020. security-09 (work in progress), March 2020.
[I-D.ietf-idr-rfc5575bis]
Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules",
draft-ietf-idr-rfc5575bis-24 (work in progress), April
2020.
[I-D.ietf-pce-pcep-extension-for-pce-controller] [I-D.ietf-pce-pcep-extension-for-pce-controller]
Zhao, Q., Li, Z., Negi, M., Peng, S., and C. Zhou, "PCEP Zhao, Q., Li, Z., Negi, M., Peng, S., and C. Zhou, "PCEP
Procedures and Protocol Extensions for Using PCE as a Procedures and Protocol Extensions for Using PCE as a
Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep- Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep-
extension-for-pce-controller-04 (work in progress), March extension-for-pce-controller-04 (work in progress), March
2020. 2020.
[I-D.ietf-spring-srv6-network-programming] [I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming", Matsushima, S., and Z. Li, "SRv6 Network Programming",
skipping to change at page 24, line 15 skipping to change at page 24, line 5
[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>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>.
[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 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[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>.
 End of changes. 27 change blocks. 
82 lines changed or deleted 92 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/