rfc8938xml2.original.xml   rfc8938.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info"
docName="draft-ietf-detnet-data-plane-framework-06" number="8938"
ipr="trust200902" submissionType="IETF" consensus="true" obsoletes=""
updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 2.46.0 -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info"
docName="draft-ietf-detnet-data-plane-framework-06"
ipr="trust200902"
submissionType="IETF">
<front> <front>
<title abbrev="DetNet Data Plane Framework"> <title abbrev="DetNet Data Plane Framework">
DetNet Data Plane Framework</title> Deterministic Networking (DetNet) Data Plane Framework</title>
<author role="editor" fullname="Bal&aacute;zs Varga" initials="B." surname=" <seriesInfo name="RFC" value="8938"/>
Varga"> <author role="editor" fullname="Balázs Varga" initials="B." surname="Varga">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Magyar Tudosok krt. 11.</street> <street>Magyar Tudosok krt. 11.</street>
<city>Budapest</city> <city>Budapest</city>
<country>Hungary</country> <country>Hungary</country>
<code>1117</code> <code>1117</code>
</postal> </postal>
<email>balazs.a.varga@ericsson.com</email> <email>balazs.a.varga@ericsson.com</email>
</address> </address>
</author> </author>
<author fullname="János Farkas" initials="J." surname="Farkas">
<author fullname="J&aacute;nos Farkas" initials="J." surname="Farkas">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Magyar Tudosok krt. 11.</street> <street>Magyar Tudosok krt. 11.</street>
<city>Budapest</city> <city>Budapest</city>
<country>Hungary</country> <country>Hungary</country>
<code>1117</code> <code>1117</code>
</postal> </postal>
<email>janos.farkas@ericsson.com</email> <email>janos.farkas@ericsson.com</email>
</address> </address>
skipping to change at line 46 skipping to change at line 41
<address> <address>
<postal> <postal>
<street>Magyar Tudosok krt. 11.</street> <street>Magyar Tudosok krt. 11.</street>
<city>Budapest</city> <city>Budapest</city>
<country>Hungary</country> <country>Hungary</country>
<code>1117</code> <code>1117</code>
</postal> </postal>
<email>janos.farkas@ericsson.com</email> <email>janos.farkas@ericsson.com</email>
</address> </address>
</author> </author>
<author fullname="Lou Berger" initials="L." surname="Berger"> <author fullname="Lou Berger" initials="L." surname="Berger">
<organization>LabN Consulting, L.L.C.</organization> <organization>LabN Consulting, L.L.C.</organization>
<address> <address>
<email>lberger@labn.net</email> <email>lberger@labn.net</email>
</address> </address>
</author> </author>
<author fullname="Andrew G. Malis" initials="A." surname="Malis">
<author fullname="Andrew G. Malis" initials="A.G." surname="Malis">
<organization>Malis Consulting</organization> <organization>Malis Consulting</organization>
<address> <address>
<email>agmalis@gmail.com</email> <email>agmalis@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Stewart Bryant" initials="S." surname="Bryant"> <author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization>Futurewei Technologies</organization> <organization>Futurewei Technologies</organization>
<address> <address>
<email>stewart.bryant@gmail.com</email> <email>sb@stewartbryant.com</email>
</address> </address>
</author> </author>
<date month="November" year="2020"/>
<!-- <author fullname="Jouni Korhonen" initials="J." surname="Korhonen">
//organization abbrev="Nordic">Nordic Semiconductor</organization
<address>
<email>jouni.nospam@gmail.com</email>
</address>
</author> -->
<date />
<workgroup>DetNet</workgroup>
<abstract> <abstract>
<t> <t>
This document provides an overall framework for the DetNet This document provides an overall framework for the Deterministic
Networking (DetNet)
data plane. It covers concepts and considerations that data plane. It covers concepts and considerations that
are generally common to any Deterministic Networking data plane are generally common to any DetNet data plane
specification. It describes related controller plane specification. It describes related Controller Plane
considerations as well. considerations as well.
</t> </t>
</abstract> </abstract>
</front> </front>
<!--
***********************************************
IESG review comment resolutions in this version:
DONE
- Sabrina Tanamal, IANA, (03-12), OK
- Christer Holmberg, (03-15), Ready with Nits
- Yoshifumi Nishida, (04-07), Ready with Nits
- Murray Kucherawy (04-12), Editorial nits mostly
- Barry Leiba, (04-15), Editorial comments
To be discussed:
- Chris Lonvick, (03-13), Ready with Issues (Ready, as soon as
I-D.ietf-detnet-security is reviewed and becomes an RFC.)
***********************************************
<middle> <middle>
<section title="Introduction" anchor="sec_intro"> <section anchor="sec_intro" numbered="true" toc="default">
<name>Introduction</name>
<t> <t>
DetNet (Deterministic Networking) provides a capability 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 concepts delivery latency. A description of the general background and concepts
of DetNet can be found in <xref target="RFC8655"/>. of DetNet can be found in <xref target="RFC8655" format="default"/>.
</t> </t>
<t> <t>
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 and provides considerations for any corresponding
implementation. It covers the building blocks that provide the DetNet implementation. It covers the building blocks that provide the DetNet
service, the DetNet service sub-layer and the DetNet forwarding service, the DetNet service sub&nbhy;layer, and the DetNet forwarding
sub-layer functions as described in the DetNet Architecture. sub&nbhy;layer functions as described in the DetNet architecture
<xref target="RFC8655"/>.
</t> </t>
<t> <t>
The DetNet Architecture models the DetNet related data plane functions The DetNet architecture models the DetNet-related data plane functions
as being decomposed into two sub-layers: a service sub-layer and a forwa as being decomposed into two sub&nbhy;layers: a service sub&nbhy;layer a
rding nd a forwarding
sub-layer. The service sub-layer is used to provide DetNet service sub&nbhy;layer. The service sub&nbhy;layer is used to provide DetNet se
protection and reordering. The forwarding sub-layer leverages Traffic rvice
Engineering mechanisms and provides congestion protection (low loss, protection and reordering. The forwarding sub&nbhy;layer leverages traff
ic
engineering mechanisms and provides congestion protection (low loss,
assured latency, and limited out-of-order delivery). A particular assured latency, and limited out-of-order delivery). A particular
forwarding sub-layer may have capabilities that are not available on forwarding sub&nbhy;layer may have capabilities that are not available o
other forwarding-sub layers. DetNet makes use of the existing n
forwarding sub-layers with their respective capabilities and does not other forwarding sub&nbhy;layers. DetNet makes use of the existing
require 1:1 equivalence between different forwarding sub-layer forwarding sub&nbhy;layers with their respective capabilities and does n
ot
require 1:1 equivalence between different forwarding sub&nbhy;layer
capabilities. capabilities.
</t> </t>
<t> <t>
As part of the service sub-layer functions, this document describes As part of the service sub&nbhy;layer functions, this document describes
typical DetNet node data plane operation. It describes the functionality typical DetNet node data plane operation. It describes the functionality
and operation of the Packet Replication (PRF), Packet Elimination and operation of the Packet Replication Function (PRF), the Packet
(PEF), and the Packet Ordering (POF) functions within the service Elimination Function (PEF), and the Packet Ordering Function (POF) withi
sub-layer. Furthermore, it describes the forwarding sub-layer. n the service
sub&nbhy;layer. Furthermore, it describes the forwarding sub&nbhy;layer.
</t> </t>
<t> <t>
As defined in <xref target="RFC8655"/>, As defined in <xref target="RFC8655" format="default"/>,
DetNet flows may be carried over network technologies that can pr DetNet flows may be carried over network technologies that can provide
ovide service characteristics required by DetNet. For example, DetNet MPLS fl
the DetNet required service characteristics. For example, DetNet MPLS ows can be carried over IEEE 802.1 Time-Sensitive
flows can be carried over IEEE 802.1 Time Sensitive Network (TSN) <xref Networking (TSN) sub-networks <xref target="IEEE802.1TSNTG"
target="IEEE802.1TSNTG"/> sub-networks. However, IEEE 802.1 TSN format="default"/>. However, IEEE 802.1 TSN support is not required in
support is not required in DetNet. TSN frame preemption is an example DetNet. TSN frame preemption is an example of a forwarding layer capability
of a forwarding layer capability that is typically not replicated in that is typically not replicated in other forwarding technologies. Most of
other forwarding technologies. Most of DetNet benefits can be gained by DetNet's benefits can be gained by running over a data-link layer that has
running over a data link layer that has not been specifically enhanced not been specifically enhanced to support all TSN capabilities, but for such
to support all TSN capabilities but for such networks and traffic networks and traffic mixes, delay and jitter performance may vary due to the
mixes delay and jitter performance may vary due to the forwarding forwarding sub&nbhy;layer's intrinsic properties.
sub-layer intrinsic properties.
</t> </t>
<t> <t>
Different application flows, such as Ethernet or IP, can be mapped Different application flows, such as Ethernet or IP, can be mapped
on top of DetNet. DetNet can optionally reuse header information on top of DetNet. DetNet can optionally reuse header information
provided by, or shared with, applications. An example of shared header provided by, or shared with, applications. An example of shared header
fields can be found in <xref target="I-D.ietf-detnet-ip"/>. fields can be found in <xref target="RFC8939" format="default"/>.
</t> </t>
<t> <t>
This document also covers This document also covers
basic concepts related to the controller plane and Operations, basic concepts related to the Controller Plane and Operations,
Administration, and Maintenance (OAM). Administration, and Maintenance (OAM).
Data plane OAM specifics are out of scope for this document. Data plane OAM specifics are out of scope for this document.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Terminology"> <name>Terminology</name>
<section title="Terms Used in This Document"> <section numbered="true" toc="default">
<name>Terms Used in This Document</name>
<t> <t>
This document uses the terminology established in the DetNet This document uses the terminology established in the DetNet
architecture <xref target="RFC8655"/>, architecture <xref target="RFC8655" format="default"/>, and
and the reader is assumed to be familiar with that document it is assumed that the reader is familiar with that document
and its terminology. and its terminology.
</t> </t>
</section> </section>
<?rfc subcompact="yes" ?> <section numbered="true" toc="default">
<section title="Abbreviations"> <name>Abbreviations</name>
<t> <t>
The following abbreviations are used in this document: The following abbreviations are used in this document:
<list style="hanging" hangIndent="14">
<t hangText="BGP">Border Gateway Protocol.</t>
<t hangText="d-CW">DetNet Control Word.</t>
<t hangText="DetNet">Deterministic Networking.</t>
<t hangText="DN">DetNet.</t>
<t hangText="GMPLS">Generalized Multiprotocol Label Switching.</t>
<t hangText="GRE">Generic Routing Encapsulation.</t>
<t hangText="IPSec">IP Security.</t>
<t hangText="L2">Layer 2.</t>
<t hangText="LSP">Label Switched Path.</t>
<t hangText="MPLS">Multiprotocol Label Switching.</t>
<t hangText="OAM">Operations, Administration, and Maintenance.</t>
<t hangText="PCEP">Path Computation Element Communication Protocol.<
/t>
<t hangText="PEF">Packet Elimination Function.</t>
<t hangText="PRF">Packet Replication Function.</t>
<t hangText="PREOF">Packet Replication, Elimination and Ordering Fun
ctions.</t>
<t hangText="POF">Packet Ordering Function.</t>
<t hangText="PSN">Packet Switched Network.</t>
<t hangText="QoS">Quality of Service.</t>
<t hangText="S-Label">DetNet "service" label.</t>
<t hangText="TDM">Time-Division Multiplexing.</t>
<t hangText="TSN">Time-Sensitive Network.</t>
<t hangText="YANG">Yet Another Next Generation.</t>
</list>
</t> </t>
<dl newline="false" indent="12">
<dt>BGP</dt>
<dd>Border Gateway Protocol</dd>
<dt>CoS</dt>
<dd>Class of Service</dd>
<dt>d-CW</dt>
<dd>DetNet Control Word</dd>
<dt>DetNet</dt>
<dd>Deterministic Networking</dd>
<dt>DN</dt>
<dd>DetNet</dd>
<dt>GMPLS</dt>
<dd>Generalized Multiprotocol Label Switching</dd>
<dt>GRE</dt>
<dd>Generic Routing Encapsulation</dd>
<dt>IPsec</dt>
<dd>IP Security</dd>
<dt>L2</dt>
<dd>Layer 2</dd>
<dt>LSP</dt>
<dd>Label Switched Path</dd>
<dt>MPLS</dt>
<dd>Multiprotocol Label Switching</dd>
<dt>OAM</dt>
<dd>Operations, Administration, and Maintenance</dd>
<dt>PCEP</dt>
<dd>Path Computation Element Communication Protocol</dd>
<dt>PEF</dt>
<dd>Packet Elimination Function</dd>
<dt>POF</dt>
<dd>Packet Ordering Function</dd>
<dt>PREOF</dt>
<dd>Packet Replication, Elimination, and Ordering Functions</dd>
<dt>PRF</dt>
<dd>Packet Replication Function</dd>
<dt>PSN</dt>
<dd>Packet Switched Network</dd>
<dt>QoS</dt>
<dd>Quality of Service</dd>
<dt>S-Label</dt>
<dd>DetNet "service" label</dd>
<dt>TDM</dt>
<dd>Time-Division Multiplexing</dd>
<dt>TSN</dt>
<dd>Time-Sensitive Networking</dd>
<dt>YANG</dt>
<dd>Yet Another Next Generation</dd>
</dl>
</section> </section>
</section> <!-- end of terminology --> </section>
<?rfc subcompact="no" ?> <section anchor="sec_dt_dp" numbered="true" toc="default">
<section title="DetNet Data Plane Overview" anchor="sec_dt_dp"> <name>Overview of the DetNet Data Plane</name>
<t> <t>
This document describes how application flows, or app-flows, are This document describes how application flows, or App-flows <xref
carried over DetNet networks. The DetNet Architecture <xref target="RFC8655"/>, are
target="RFC8655"/> models the DetNet-related carried over DetNet networks. The DetNet architecture <xref target="RFC8
data plane functions as decomposed into two sub-layers: a service 655" format="default"/> models the DetNet-related
sub-layer and a forwarding sub-layer. data plane functions as decomposed into two sub&nbhy;layers: a s
</t> ervice
sub&nbhy;layer and a forwarding sub&nbhy;layer.
<t> </t>
<xref target="ProtStack1"/>, reproduced from <xref target="RFC8655"/>, <t>
shows a logical DetNet service with the two sub-layers. <xref target="ProtStack1" format="default"/>, reproduced from <xref targ
et="RFC8655" format="default"/>,
shows a logical DetNet service with the two sub&nbhy;layers.
</t> </t>
<figure align="center" anchor="ProtStack1" <figure anchor="ProtStack1">
title="DetNet data plane protocol stack"> <name>DetNet Data Plane Protocol Stack</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
| 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 |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| Service sub-layer: | | Service sub-layer: | | Service sub-layer: | | Service sub-layer: |
| Packet sequencing | | Duplicate elimination | | Packet sequencing | | Duplicate elimination |
| Flow replication | | Flow merging | | Flow replication | | Flow merging |
| Packet encoding | | Packet decoding | | Packet encoding | | Packet decoding |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| 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 ^
\_________________________/ \_________________________/]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t> The DetNet forwarding sub&nbhy;layer may be directly provided by the De
The DetNet forwarding sub-layer may be directly provided by the DetNet tNet
service sub-layer, for example by IP tunnels or MPLS. service sub&nbhy;layer -- for example, by IP tunnels or MPLS.
Alternatively, an overlay approach Alternatively, an overlay approach
may be used in which the packet is natively carried between key nodes may be used in which the packet is natively carried between key nodes
within the DetNet network (say between PREOF nodes) and a sub-layer is within the DetNet network (say, between PREOF nodes), and a sub&nbhy;la yer is
used to provide the information needed to reach the next hop in the used to provide the information needed to reach the next hop in the
overlay. overlay.
</t> </t>
<t> <t>
The forwarding sub-layer provides the QoS related functions needed by The forwarding sub&nbhy;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 call the assistance of its underlying connectivity. For example, it may call
upon Ethernet TSN capabilities defined in IEEE 802.1 TSN <xref upon Ethernet TSN capabilities defined in IEEE 802.1 TSN <xref target="
target="IEEE802.1TSNTG"/>. The forwarding sub-layer uses IEEE802.1TSNTG" format="default"/>. The forwarding sub&nbhy;layer uses
buffer resources for packet queuing, as well as reservation and buffer resources for packet queuing, as well as reservation and
allocation of bandwidth capacity resources. allocation of bandwidth capacity resources.
</t> </t>
<t> <t>
The service sub-layer provides additional support beyond the The service sub&nbhy;layer provides additional support beyond the
connectivity function of the forwarding sub-layer. See <xref connectivity function of the forwarding sub&nbhy;layer. See
target="PREOF"/> as an example for Packet Replication, Elimination, <xref target="PREOF" format="default"/> regarding PREOF. The POF uses
and Ordering functions. The ordering function (POF) uses sequen sequence numbers
ce numbers added to packets, enabling a range of packet order protection from
added to packets enabling a range of packet order protection from
simple ordering and dropping out-of-order packets to more complex simple ordering and dropping out-of-order packets to more complex
reordering of a fixed number of out-of-order, minimally delayed reordering of a fixed number of out-of-order, minimally delayed
packets. Reordering requires buffer resources and has impact on the packets. Reordering requires buffer resources and has an impact on the
delay and jitter of packets in the DetNet flow. delay and jitter of packets in the DetNet flow.
</t> </t>
<t> <t>
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 particular DetNet data plane method, and more than one approach may
may be applicable to a given network type.
be applicable to a given network type. </t>
</t> <section anchor="sec_dp_char" numbered="true" toc="default">
<name>Data Plane Characteristics</name>
<section title="Data Plane Characteristics" anchor="sec_dp_char">
<t> <t>
There are two major characteristics to the data plane: the technology an d The data plane has two major characteristics: the technology and
the encapsulation, as discussed below. the encapsulation, as discussed below.
</t> </t>
<section title="Data Plane Technology" anchor="sec_dp_tech"> <section anchor="sec_dp_tech" numbered="true" toc="default">
<t> <name>Data Plane Technology</name>
The DetNet data plane is provided by the DetNet service and forwarding <t>
sub layers. The DetNet data plane is provided by the DetNet service and forwarding
The DetNet service sub-layer sub&nbhy;layers.
The DetNet service sub&nbhy;layer
generally provides its functions for the DetNet application flows by us ing or applying generally provides its functions for the DetNet application flows by us ing or applying
existing standardized headers and/or encapsulations. The Detnet existing standardized headers and/or encapsulations. The DetNet
forwarding sub-layer may provide capabilities leveraging that same forwarding sub&nbhy;layer may provide capabilities leveraging that same
header or encapsulation technology (e.g., DN IP or DN MPLS) or it header or encapsulation technology (e.g., DN IP or DN MPLS), or it
may be achieved by other technologies as shown in <xref may be achieved via other technologies, as shown in <xref
target="dn_svc_encaps"/>. target="dn_svc_encaps" format="default"/> below.
DetNet is currently defined for operation over packet-switched (IP) DetNet is currently defined for operation over packet-switched (IP)
networks or label-switched (MPLS) networks. networks or label-switched (MPLS) networks.
</t> </t>
</section> </section>
<section title="Encapsulation" anchor="sec_dp_enc <section anchor="sec_dp_encap" numbered="true" toc="default">
ap"> <name>Encapsulation</name>
<t> <t>
DetNet encodes specific flow attributes DetNet encodes specific flow attributes
(flow identity and sequence number) in packets. (flow identity and sequence number) in packets.
For example, in DetNet IP, For example, in DetNet IP,
zero encapsulation is used and no sequence number zero encapsulation is used, and no sequence number
is available, and in DetNet MPLS, DetNet-specific information may be a is available; in DetNet MPLS, DetNet-specific information may be added
dded explicitly to the packets in the form of an S-Label and a d-CW
explicitly to the packets in the form of S-label and d-CW <xref target="DetNet-MPLS" format="default"/>.
<xref target="I-D.ietf-detnet-mpls"/> . </t>
</t> <t>
<t>
The encapsulation of a DetNet flow allows it to be sent over a The encapsulation of a DetNet flow allows it to be sent over a
data plane technology other than its native type. data plane technology other than its native type.
DetNet uses header information to perform traffic classificatio n, DetNet uses header information to perform traffic classificatio n,
i.e., identify DetNet flows, and provide DetNet service and i.e., identify DetNet flows, and provide DetNet service and
forwarding functions. As mentioned above, DetNet may add header s, forwarding functions. As mentioned above, DetNet may add header s,
as is the case for DN MPLS, or may use headers that are already as is the case for DN MPLS, or may use headers that are already
present, as is the case in DN IP. present, as is the case for DN IP.
<xref target="dn_svc_encaps"/> illustrates some relationships <xref target="dn_svc_encaps" format="default"/> illustrates some rela
tionships
between the components. between the components.
</t> </t>
<figure anchor="dn_svc_encaps">
<figure anchor="dn_svc_encaps" align="center" <name>DetNet Service Examples</name>
title="DetNet Service Examples"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
+-----+ +-----+
| TSN | | TSN |
+-------+ +-+-----+-+ +-------+ +-+-----+-+
| DN IP | | DN MPLS | | DN IP | | DN MPLS |
+--+--+----+----+ +-+---+-----+-+ +--+--+----+----+ +-+---+-----+-+
| TSN | DN MPLS | | TSN | DN IP | | TSN | DN MPLS | | TSN | DN IP |
+-----+---------+ +-----+-------+ +-----+---------+ +-----+-------+]]></artwork>
</figure>
]]></artwork> <t>
</figure>
<t>
The use of encapsulation is also required if additional information The use of encapsulation is also required if additional information
(metadata) is needed by the DetNet data plane and there is either (metadata) is needed by the DetNet data plane and either (1)&nbsp;the
no ability to include it in the client data packet, or the re is
no ability to include it in the client data packet or (2)&nbsp;the
specification of the client data plane does not permit the specification of the client data plane does not permit the
modification of the packet to include additional data. An example of modification of the packet to include additional data. An example of
such metadata is the inclusion of a sequence number required by the such metadata is the inclusion of a sequence number required by
PREOF function. PREOF.
</t> </t>
<t> <t>
Encapsulation may also be used to carry or aggregate flows for equipm ent with limited Encapsulation may also be used to carry or aggregate flows for equipm ent with limited
DetNet capability. DetNet capability.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sec_dp_metadata" numbered="true" toc="default">
<section title="DetNet-specific Metadata" anchor="sec_dp_metadata"> <name>DetNet-Specific Metadata</name>
<t> <t>
The DetNet data plane can provide or carry the following metadata: The DetNet data plane can provide or carry the following metadata:
<list style="numbers"> </t>
<t> <ol spacing="normal" type="1">
<li>
Flow-ID Flow-ID
</t> </li>
<t> <li>
Sequence Number Sequence number
</t> </li>
</list> </ol>
</t> <t>
<t> The DetNet data plane framework supports a Flow-ID (for identification
The DetNet data plane framework supports a Flow-ID (for identi of the
fication of the flow or aggregate flow) and/or a sequence number (for PREOF) for each
flow or aggregate flow) and/or a Sequence Number (for PREOF) f DetNet flow. The Flow-ID is used by both the service and forwarding su
or each b&nbhy;layers,
DetNet flow. The Flow-ID is used by both the service and forwa but the sequence number is only used by the service layer. Metadata ca
rding sub-layers, n also be
but the sequence number is only used by the ser used for OAM indications and instrumentation of DetNet data plane
vice layer. Metadata can also be operation.
used for OAM indications and instrumentation of DetNet data pl </t>
ane <t>
operation. Metadata inclusion can be implicit or explicit. Explicit inclusions
</t> involve a dedicated header field that is used to include metadata
<t> in a DetNet packet. In the implicit method, part of an already-existi
Metadata inclusion can be implicit or explicit. Explicit incl ng
usions header field is used to encode the metadata.
involve a dedicated header field that is used t </t>
o include metadata <t>
in a DetNet packet. In the implicit method, pa
rt of an already existing
header field is used to encode the metadata.
</t>
<t>
Explicit inclusion of metadata is possible through the use of Explicit inclusion of metadata is possible through the use of
IP options or IP extension headers. New IP options are almost impossib le IP options or IP extension headers. New IP options are almost impossib le
to get standardized or to deploy in an operational network and will to get standardized or to deploy in an operational network and will
not be discussed further in this text. IPv6 extensions headers are not be discussed further in this text. IPv6 extension headers are
finding popularity in current IPv6 development work, particularly finding popularity in current IPv6 development work, particularly
in connection with Segment Routing of IPv6 (SRv6) and IP OAM. The desi gn in connection with Segment Routing of IPv6 (SRv6) and IP OAM. The desi gn
of a new IPv6 extension header or the modification of an existing one is of a new IPv6 extension header or the modification of an existing one is
a technique available in the tool box of the DetNet IP data plane desi gner. a technique available in the toolbox of the DetNet IP data plane desig ner.
</t> </t>
<t> <t>
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 d-CW,
Control Word using one of the methods for carrying MPLS over IP <xref using one of the methods for carrying MPLS over IP <xref target="DetNe
target="I-D.ietf-detnet-mpls-over-udp-ip"/>. This is described t-MPLS-over-UDP-IP" format="default"/>. This is described in more
in more detail in <xref target="subnet_considerations" format="default"/>.
detail in <xref target="subnet_considerations"/>.
</t> </t>
<t> <t>
Implicit metadata in IP can be included through the use of the network Implicit metadata in IP can be included through the use of the network
programming paradigm <xref programming paradigm <xref target="SRv6-Network-Prog" format="default"
target="I-D.ietf-spring-srv6-network-programming"/> in which t />, in which the
he
suffix of an IPv6 address is used to encode additional information suffix of an IPv6 address is used to encode additional information
for use by the network of the receiving host. for use by the network of the receiving host.
</t> </t>
<t> <t>
An MPLS example of explicit metadata is the sequence number An MPLS example of explicit metadata is the sequence number
used by the PREOF function, or even the case where all the used by PREOF, or even the case where all the
essential information being included into the DetNet over MPLS essential information is included in the DetNet-over-MPLS
label stack (the DetNet Control Word and the DetNet Service lab label stack (the d-CW and the DetNet S-Label).
el). </t>
</t>
</section> </section>
<section anchor="sec_dt_ip_dp" numbered="true" toc="default">
<section title="DetNet IP Data Plane" anchor="sec_dt_ip_dp"> <name>DetNet IP Data Plane</name>
<t> <t>
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. encapsulation.
Many types of IP encapsulation can satisfy DetNet requirements Many types of IP encapsulation can satisfy DetNet requirements,
and it is anticipated that more than one encapsulation and it is anticipated that more than one encapsulation
may be deployed, for example GRE, IPSec. may be deployed -- for example, GRE, IPsec.
</t> </t>
<t> <t>
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-layer and higher-layer protocol headers.
General background on the use of IP headers, and "6-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 QoS can be found in
<xref target="RFC3670"/>. <xref target="RFC7657"/> provides <xref target="RFC3670" format="default"/>. The extra field in the
useful background on differentiated services (DiffServ) 6-tuple is the DSCP field in the packet. <xref target="RFC7657" format=
and "tuple" based flow identification. DetNet flow aggregation may "default"/> provides
be enabled via the use of wildcards, masks, prefixes and ranges. The useful background on differentiated services (Diffserv)
operation of this method is described in detail in <xref and tuple-based flow identification. DetNet flow aggregation may
target="I-D.ietf-detnet-ip"/>. be enabled via the use of wildcards, masks, prefixes, and ranges. The
operation of this method is described in detail in <xref target="RFC89
39" format="default"/>.
</t> </t>
<t> <t>
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&nbhy;laye r
that is responsible for providing resource allocation and explicit that is responsible for providing resource allocation and explicit
routes. It is possible to include such information in a native IP pac routes. It is possible to include such information in a native IP
ket packet either explicitly or implicitly.
explicitly, or implicitly.
</t> </t>
</section> </section>
<section title="DetNet MPLS Data Plane" anchor="sec_dt_mpls_dp"> <section anchor="sec_dt_mpls_dp" numbered="true" toc="default">
<name>DetNet MPLS Data Plane</name>
<t> <t>
MPLS provides a forwarding sub-layer for traffic over implicit MPLS provides a forwarding sub&nbhy;layer for traffic over implicit
and explicit paths to the point in the network where the next and explicit paths to the point in the network where the next
DetNet service sub-layer action needs to take place. It does this DetNet service sub&nbhy;layer action needs to take place. It does this
through the use of a stack of one or more labels with various through the use of a stack of one or more labels with various
forwarding semantics. forwarding semantics.
</t> </t>
<t> <t>
MPLS also provides the ability to identify a service instance MPLS also provides the ability to identify a service instance
that is used to process the packet through the use of a label that that is used to process the packet through the use of a label that
maps the packet to a service instance. maps the packet to a service instance.
</t> </t>
<t> <t>
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 <xref target="I-D.ietf-detne packet at the service sub&nbhy;layer, the d-CW <xref
t-mpls"/>, target="DetNet-MPLS" format="default"/> can be used. Although such d-
<xref target="RFC4385"/> can be used. CWs
Although such d-CWs
are frequently 32 bits long, there is no architectural constraint on are frequently 32 bits long, there is no architectural constraint on
the size of this structure, only the requirement that it is fully the size of this structure -- only the requirement that it be fully
understood by all parties operating on it in the DetNet service understood by all parties operating on it in the DetNet service
sub-layer. The operation of this method is described in detail in sub&nbhy;layer. The operation of this method is described in detail i
<xref target="I-D.ietf-detnet-mpls"/>. n
<xref target="DetNet-MPLS" format="default"/>.
</t> </t>
</section> </section>
<section anchor="further_dn_dp_consid" numbered="true" toc="default">
<section title="Further DetNet Data Plane Considerations" anchor="further_dn_dp_ <name>Further DetNet Data Plane Considerations</name>
consid"> <t>
<t>
This section provides informative considerations related to This section provides informative considerations related to
providing DetNet service to flows which are identified providing DetNet service to flows that are identified
based on their header information. based on their header information.
</t> </t>
<section title="Per Flow Related Functions" anchor="further_dn_dp_pf"> <section anchor="further_dn_dp_pf" numbered="true" toc="default">
<t> <name>Functions Provided on a Per-Flow Basis</name>
At a high level, the following functions are provided on a per flow basi <t>
s. At a high level, the following functions are provided on a per-flow basi
</t> s.
<section title="Reservation and Allocation of resources"> </t>
<t> <section numbered="true" toc="default">
<name>Reservation and Allocation of Resources</name>
<t>
Resources might be reserved in order to make them available for allocati on to specific DetNet Resources might be reserved in order to make them available for allocati on to specific DetNet
flows. This can eliminate packet contention and packet loss for D etNet flows. This can eliminate packet contention and packet loss for DetNet
traffic. This also can reduce jitter for DetNet traffic. Resources traffic. This also can reduce jitter for DetNet traffic. Resources
allocated to a DetNet flow protect it from other traffic flows. On the allocated to a DetNet flow protect it from other traffic flows. On the
other hand, DetNet flows are assumed to behave with respect to the other hand, it is assumed that DetNet flows behave in accordance with th
reserved traffic profile. e
It must be possible to detect misbehaving DetNet flows reserved traffic profile. It must be possible to detect misbehaving DetN
and to ensure that they do not compromise QoS of other flows. et flows
and to ensure that they do not compromise QoS of other flows.
Queuing, policing, and shaping policies can be used to ensure Queuing, policing, and shaping policies can be used to ensure
that the allocation of resources reserved for DetNet is met. that the allocation of resources reserved for DetNet is met.
</t> </t>
</section> </section>
<section title="Explicit routes"> <section numbered="true" toc="default">
<t> <name>Explicit Routes</name>
A flow can be routed over a specific, pre-computed path. This allows con <t>
trol of the network A flow can be routed over a specific, precomputed path. This allows cont
rol of network
delay by steering the packet with the ability to influence the physical delay by steering the packet with the ability to influence the physical
path. Explicit routes complement reservation by ensuring that a path. Explicit routes complement reservation by ensuring that a
consistent path can be associated with its resources for the duration consistent path can be associated with its resources for the duration
of that path. Coupled with the traffic mechanism, this limits of that path. Coupled with the traffic mechanism, this limits
misordering and bounds latency. Explicit route computation can misordering and bounds latency. Explicit route computation can
encompass a wide set of constraints and can optimize the path for a cert ain encompass a wide set of constraints and can optimize the path for a cert ain
characteristic, e.g., highest bandwidth or lowest jitter. In these case s characteristic, e.g., highest bandwidth or lowest jitter. In these case s,
the "best" path for any set of characteristics may not be a shortest the "best" path for any set of characteristics may not be a shortest
path. The selection of path can take into account multiple network path. The selection of the path can take into account multiple network
metrics. Some of these metrics are measured and distributed by the metrics. Some of these metrics are measured and distributed by the
routing system as traffic engineering metrics. routing system as traffic engineering metrics.
</t> </t>
</section> </section>
<section title="Service protection"> <section numbered="true" toc="default">
<t> <name>Service Protection</name>
Service protection involves use of multiple packet streams using multipl <t>
e paths, for example 1+1 or Service protection involves the use of multiple packet streams using
multiple paths -- for example, 1+1 or
1:1 linear protection. For DetNet, this primarily relates to packet 1:1 linear protection. For DetNet, this primarily relates to packet
replication and elimination capabilities. replication and elimination capabilities.
MPLS offers a number of protection schemes. MPLS offers a number of protection schemes.
MPLS hitless protection can be used to switch traffic to an already esta blished path MPLS hitless protection can be used to switch traffic to an already-esta blished path
in order to restore delivery rapidly after a failure. in order to restore delivery rapidly after a failure.
Path changes, even in the case of failure recovery, can lead to the out Path changes, even in the case of failure recovery, can lead to the out-
of of-order delivery of data requiring POFs either
order delivery of data requiring packet ordering functions either
within the DetNet service or at a high layer in the application within the DetNet service or at a high layer in the application
traffic. Establishment of new paths after a failure is out of scope traffic. Establishment of new paths after a failure is out of scope
for DetNet services. for DetNet services.
</t> </t>
</section> </section>
<section title="Network Coding"> <section numbered="true" toc="default">
<t> <name>Network Coding</name>
Network Coding <xref target="nwcrg"/>, <t>
Network Coding <xref target="nwcrg" format="default"/>,
not to be confused with network programming, not to be confused with network programming,
comprises comprises
several techniques where multiple data flows are encoded. These several techniques where multiple data flows are encoded. These
resulting flows can then be sent on different paths. The encoding resulting flows can then be sent on different paths. The encoding
operation can combine flows and error recovery information. When the operation can combine flows and error recovery information. When the
encoded flows are decoded and recombined the original flows can be encoded flows are decoded and recombined, the original flows can be
recovered. Note that Network coding uses an alternative to packet by recovered. Note that Network Coding uses an alternative to
packet PREOF. Therefore, for certain network topologies and traffic packet-by-packet PREOF. Therefore, for certain network topologies and tr
affic
loads, Network Coding can be used to improve a network's throughput, loads, Network Coding can be used to improve a network's throughput,
efficiency, latency, and scalability, as well as resilience to efficiency, latency, and scalability, as well as resilience to
partition, attacks, and eavesdropping, as compared to traditional partition, attacks, and eavesdropping, as compared to traditional
methods. DetNet could use Network coding as an alternative to methods. DetNet could use Network Coding as an alternative to
other protection means. Network coding is often applied in wireless other means of protection. Network Coding is often applied in wireless
networks and is being explored for other network types. networks and is being explored for other network types.
</t> </t>
</section> </section>
<section title="Load sharing"> <section numbered="true" toc="default">
<t> <name>Load-Sharing</name>
Use of packet-by-packet load sharing of the same DetNet flow over <t>
multiple paths is not recommended except for the cases listed above The use of packet-by-packet load-sharing of the same DetNet flow over
where PREOF is utilized to improve protection of traffic and maintain or multiple paths is not recommended, except for the cases listed above
der. where PREOF are utilized to improve protection of traffic and maintain o
Packet-by-packet load sharing, e.g., via ECMP or UCMP, impacts ordering rder.
and Packet-by-packet load-sharing, e.g., via Equal-Cost Multipath (ECMP)
possibly jitter. or Unequal-Cost Multipath (UCMP), impacts ordering and,
</t> possibly, jitter.
<!-- I think this section below should refer to OAM for the various underl </t>
ying
technology the one area that may be for consideration is how detnet c
an identify
specific tunneled traffic. Of course that allows for security vulnera
bilities -->
</section> </section>
<section title="Troubleshooting"> <section numbered="true" toc="default">
<t> <name>Troubleshooting</name>
Detnet leverages many different forwarding sub-layers, each of which <t>
supports various tools to troubleshoot connectivity, for example DetNet leverages many different forwarding sub&nbhy;layers, each of which
identification of misbehaving flows. The DetNet Service layer can supports various tools to troubleshoot connectivity -- for example,
identification of misbehaving flows. The DetNet service layer can
leverage existing mechanisms to troubleshoot or monitor flows, such as leverage existing mechanisms to troubleshoot or monitor flows, such as
those in use by IP and MPLS networks. At the Application layer a clie nt those in use by IP and MPLS networks. At the Application layer, a cli ent
of a DetNet service can use existing techniques to detect and monitor of a DetNet service can use existing techniques to detect and monitor
delay and loss. delay and loss.
</t> </t>
</section> </section>
<section title="Flow recognition for analytics"> <section numbered="true" toc="default">
<t> <name>Flow Recognition for Analytics</name>
Network analytics can be inherited from the technologies of the Service <t>
and Forwarding sub-layers. At the DetNet service edge, packet and bit Network analytics can be inherited from the technologies of the service
counters (e.g. sent, received, dropped, and out-of-sequence) can be and forwarding sub&nbhy;layers. At the DetNet service edge, packet an
d bit
counters (e.g., sent, received, dropped, out of sequence) can be
maintained. maintained.
</t> </t>
</section> </section>
<section title="Correlation of events with flows"> <section numbered="true" toc="default">
<t> <name>Correlation of Events with Flows</name>
<t>
The provider of a DetNet service may provide other capabilities to The provider of a DetNet service may provide other capabilities to
monitor flows, such as more detailed loss statistics and time stamping monitor flows, such as more detailed loss statistics and timestamping
of events. The details of these capabilities are out of scope of events. Details regarding these capabilities are out of scope
for this document. for this document.
</t> </t>
</section> </section>
</section> <!-- End of Per Flow Related Functions --> </section>
<section numbered="true" toc="default">
<section title="Service Protection"> <name>Service Protection</name>
<t> <t>
Service protection allows DetNet services to increase reliability and Service protection allows DetNet services to increase reliability and
maintain a DetNet Service Assurance in the case of network congestion or maintain a desired level of service assurance in the case of network
network failure. Detnet relies on the underlying technology capabilities congestion or network failure. DetNet relies on the underlying technology
capabilities
for various protection schemes. Protection schemes enable partial or for various protection schemes. Protection schemes enable partial or
complete coverage of the network paths and active protection with complete coverage of the network paths and active protection with
combinations of PRF, PEF, and POF. combinations of the PRF, PEF, and POF.
</t> </t>
<section numbered="true" toc="default">
<section title="Linear Service Protection"> <name>Linear Service Protection</name>
<t> <t>
An example DetNet MPLS network fragment and packet flow is illustrated i An example DetNet MPLS network fragment and its packet flow are illustra
n ted in
<xref target="dn_protection_flow"/>. <xref target="dn_protection_flow" format="default"/>.
</t> </t>
<figure anchor="dn_protection_flow">
<figure anchor="dn_protection_flow" align="center" <name>Example of Packet Flow Protected by DetNet</name>
title="Example Packet Flow in DetNet Protected Network"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
1 1.1 1.1 1.2.1 1.2.1 1.2.2 1 1.1 1.1 1.2.1 1.2.1 1.2.2
CE1----EN1--------R1-------R2-------R3--------EN2-----CE2 CE1----EN1--------R1-------R2-------R3--------EN2-----CE2
\ 1.2.1 / / \ 1.2.1 / /
\1.2 /-----+ / \1.2 /------+ /
+------R4------------------------+ +------R4------------------------+
1.2.2 1.2.2]]></artwork>
]]></artwork> </figure>
</figure>
<t> <t>
In <xref target="dn_protection_flow"/> the numbers are used to identify the In <xref target="dn_protection_flow" format="default"/>, the numbers are us
instance of a packet. Packet 1 is the original packet, and packets 1.1, an ed to identify the
d instance of a packet. Packet 1 is the original packet. Packets 1.1 and
1.2 are two first generation copies of packet 1. Packet 1.2.1 is a second 1.2 are two first-generation copies of packet 1, packet 1.2.1 is a
generation copy of packet 1.2, etc. Note that these numbers never appear i second-generation copy of packet 1.2, and so on. Note that these numbers n
n ever appear in
the packet, and are not to be confused with sequence numbers, labels or any the packet and are not to be confused with sequence numbers, labels, or any
other identifier that appears in the packet. They simply indicate the other identifiers that appear in the packet. They simply indicate the
generation number of the original packet so that its passage through the generation number of the original packet so that its passage through the
network fragment can be identified to the reader. network fragment can be identified for the reader.
</t> </t>
<t> <t>
Customer Equipment CE1 sends a packet into the DetNet enabled network. Thi Customer Equipment device CE1 sends a packet into the DetNet-enabled networ
s k. This
is packet (1). Edge Node EN1 encapsulates the packet as a DetNet packet an is packet 1. Edge Node EN1 encapsulates the packet as a DetNet packet and
d sends it to Relay Node R1 (packet 1.1). EN1 makes a copy of the packet
sends it to Relay node R1 (packet 1.1). EN1 makes a copy of the packet (1.2), encapsulates it, and sends this copy to Relay Node R4.
(1.2), encapsulates it and sends this copy to Relay node R4. </t>
</t> <t>
<t> Note that R1 may be directly attached to EN1, or there may be one or more
Note that along the path from EN1 to R1 there may be zero or more nodes nodes on the path that, for clarity, are not shown in <xref
which, for clarity, are not shown. The same is true for any other path target="dn_protection_flow" format="default"/>. The same
between two DetNet entities shown in <xref target="dn_protection_flow"/>. holds true for any other path between two DetNet entities as shown in
</t> the figure.
<t> </t>
Relay node R4 has been configured to send one copy of the packet to Relay <t>
Relay Node R4 has been configured to send one copy of the packet to Relay
Node R2 (packet 1.2.1) and one copy to Edge Node EN2 (packet 1.2.2). Node R2 (packet 1.2.1) and one copy to Edge Node EN2 (packet 1.2.2).
</t> </t>
<t> <t>
R2 receives packet copy 1.2.1 before packet copy 1.1 arrives, and, having R2 receives packet copy 1.2.1 before packet copy 1.1 arrives and, having
been configured to perform packet elimination on this DetNet flow, forwards been configured to perform packet elimination on this DetNet flow, forwards
packet 1.2.1 to Relay Node R3. Packet copy 1.1 is of no further use and so packet 1.2.1 to Relay Node R3. Packet copy 1.1 is of no further use and so
is discarded by R2. is discarded by R2.
</t> </t>
<t> <t>
Edge Node EN2 receives packet copy 1.2.2 from R4 before it receives packet 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 any DetNet 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 packet to CE2. When 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 discarded. EN2 receives packet copy 1.2.1 later on, the copy is discarded.
</t> </t>
<t> <t>
The above is of course illustrative of many network scenarios that can be The above is of course illustrative of many network scenarios that can be
configured. configured.
</t> </t>
<t> <t>
This example also illustrates 1:1 protection scheme meaning there is This example also illustrates a 1:1 protection scheme, meaning there is
traffic over each segment of the end-to-end path. Local DetNet traffic over each segment of the end-to-end path. Local DetNet
relay nodes determine which packets are eliminated and which packets are relay nodes determine which packets are eliminated and which packets are
forwarded. A 1+1 scheme where only one path is used for traffic at a 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 is no PRF function time could use the same topology. In this case, there is no PRF,
<!-- we have a comment that PRF function is redundant, a F alreaady means funct
ion -->
and traffic is switched upon detection of failure. An OAM scheme that and traffic is switched upon detection of failure. An OAM scheme that
monitors the paths to detect the loss of path or traffic is required to monitors the paths to detect the loss of a path or traffic is required to
initiate the switch. A POF may still be used in this case to initiate the switch. A POF may still be used in this case to
prevent misordering of packets. In both cases the protection paths are prevent misordering of packets. In both cases, the protection paths are
established and maintained for the duration of the DetNet service. established and maintained for the duration of the DetNet service.
</t> </t>
</section> </section>
<section title="Path Differential Delay"> <section numbered="true" toc="default">
<t> <name>Path Differential Delay</name>
In the preceding example, proper working of duplicate <t>
elimination and reordering of packets are dependent In the preceding example, proper operation of duplicate
elimination and the reordering of packets are dependent
on the number of out-of-order packets that can be on the number of out-of-order packets that can be
buffered and the delay difference of arriving packets. buffered and the difference in delay of the arriving packets.
DetNet uses flow-specific requirements (e.g., maximum DetNet uses flow-specific requirements (e.g., maximum
number of out-of-order packets, maximum latency number of out-of-order packets, maximum latency
of the flow) for configuration of POF-related buffers. of the flow) for configuration of POF-related buffers.
If the differential delay between paths is excessively large If the differential delay between paths is excessively large
or there is excessive mis-ordering of the packets, then packets may or there is excessive misordering of the packets, then packets may
be dropped instead of being reordered. be dropped instead of being reordered.
Likewise, PEF Likewise, the PEF
uses the sequence number to identify duplicate packets, and large uses the sequence number to identify duplicate packets, and large
differential delays combined with high numbers of packets may exceed differential delays combined with high numbers of packets may exceed
the ability of the PEF to work properly. the PEF's ability to work properly.
</t> </t>
</section> </section>
<section title="Ring Service Protection"> <section numbered="true" toc="default">
<t> <name>Ring Service Protection</name>
<t>
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 normally supports it. Many of the same concepts apply; however, rings are normally
1+1 protection for data efficiency reasons. <xref target="RFC8227"/> is an 1+1 protection for data efficiency reasons. <xref target="RFC8227" format="
example of MPLS-TP data plane that supports Ring protection. default"/> provides an example of an MPLS Transport Profile (MPLS-TP) data plane
</t> that supports ring protection.
</section> </t>
</section> </section>
</section>
<section title="Aggregation Considerations" anchor = "aggregation"> <section anchor="aggregation" numbered="true" toc="default">
<t> <name>Aggregation Considerations</name>
<t>
The DetNet data plane also allows for the aggregation of DetNet flows, which The DetNet data plane also allows for the aggregation of DetNet flows, which
can improve scalability by reducing the per-hop state. How this is accomplish ed is data can improve scalability by reducing the per-hop state. How this is accomplish ed is data
plane or control plane dependent. When DetNet flows are aggregated, transit plane or control plane dependent. When DetNet flows are aggregated, transit
nodes provide service to the aggregate and not on a per-DetNet flow basis. nodes provide service to the aggregate and not on a per-DetNet-flow basis.
When aggregating DetNet flows, the flows should be compatible, i.e., the same or When aggregating DetNet flows, the flows should be compatible, i.e., the same or
very similar QoS and CoS characteristics. In this case, nodes performing very similar QoS and CoS characteristics. In this case, nodes performing
aggregation will ensure that per-flow service requirements are achieved. aggregation will ensure that per-flow service requirements are achieved.
</t> </t>
<t> <t>
If bandwidth reservations are used, the reservation should be the If bandwidth reservations are used, the reservation should be the
sum of all the individual reservations; in other words, the reservations sum of all the individual reservations; in other words, the reservations
should not add up to an over-subscription of bandwidth reservation. If should not add up to an oversubscription of bandwidth reservation. If
maximum delay bounds are used, the system should ensure that the aggregate maximum delay bounds are used, the system should ensure that the aggregate
does not exceed the delay bounds of the individual flows. does not exceed the delay bounds of the individual flows.
</t> </t>
<t> <t>
<!-- DetNet encapsulation is a data plane mechanism that can be used to aggreg When
ate
traffic. Encapsulation can either be in the same service type or in a
different service type see <xref target="dn_svc_encaps"/> for example.--> When
an encapsulation is used, the choice of reserving a maximum resource level and an encapsulation is used, the choice of reserving a maximum resource level and
then tracking the services in the aggregated service or adjusting the then tracking the services in the aggregated service or adjusting the
aggregated resources as the services are added is implementation and aggregated resources as the services are added is implementation and
technology specific. technology specific.
</t> </t>
<t> <t>
DetNet flows at edges must be able to handle rejection to an aggregation DetNet flows at edges must be able to handle rejection to an aggregation
group due to lack of resources as well as conditions where group due to lack of resources as well as conditions where
requirements are not satisfied. requirements are not satisfied.
</t> </t>
<section title="IP Aggregation" anchor = "ip-agg"> <section anchor="ip-agg" numbered="true" toc="default">
<t> <name>IP Aggregation</name>
IP aggregation has both data plane and controller plane aspects. For the <t>
IP aggregation has both data plane and Controller Plane aspects. For the
data plane, flows may be aggregated for treatment based on shared data plane, flows may be aggregated for treatment based on shared
characteristics such as 6-tuple <xref target="I-D.ietf-detnet-ip"/>. characteristics such as 6-tuple <xref target="RFC8939" format="default"/>.
Alternatively, an IP encapsulation may be Alternatively, an IP encapsulation may be
used to tunnel an aggregate number of DetNet Flows between relay nodes. used to tunnel an aggregate number of DetNet flows between relay nodes.
</t> </t>
</section> </section>
<section title="MPLS Aggregation" anchor = "mpls-agg"> <section anchor="mpls-agg" numbered="true" toc="default">
<t> <name>MPLS Aggregation</name>
MPLS aggregation also has data plane and controller plane aspects. MPLS <t>
flows are often tunneled in a forwarding sub-layer, under the reservation MPLS aggregation also has data plane and Controller Plane aspects. MPLS
flows are often tunneled in a forwarding sub&nbhy;layer, under the reservatio
n
associated with that MPLS tunnel. associated with that MPLS tunnel.
</t> </t>
</section> </section>
</section> </section>
<section title="End-System-Specific Considerations"> <section numbered="true" toc="default">
<t> <name>End-System-Specific Considerations</name>
Data-flows requiring DetNet service are generated and terminated on <t>
end-systems. Encapsulation depends on the application and its Data flows requiring DetNet service are generated and terminated on
preferences. For example, in a DetNet MPLS domain the sub-layer functions use end systems. Encapsulation depends on the application and its
the d-CWs, preferences. For example, in a DetNet MPLS domain, the sub&nbhy;layer functio
S-Labels and F-Labels to provide DetNet services. However, an ns use the d-CWs,
application may exchange further flow related parameters (e.g., S-Labels, and F-Labels <xref target="DetNet-MPLS"/> to provide DetNet service
time-stamp), which are not provided by DetNet functions. s. However, an
</t> application may exchange further flow-related parameters (e.g.,
timestamps) that are not provided by DetNet functions.
</t>
<t> <t>
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 DetNet flows, and the DetNet domain does not mandate the
end-system or edge node encapsulation format. Unless there is a encapsulation format for end systems or edge nodes. Unless
proxy of some form present, end-systems peer with similar end-systems some form of proxy is present, end systems peer with similar end systems
using the same application encapsulation format. For example, as using the same application encapsulation format. For example, as
shown in <xref target="fig_es_connect"/>, IP applications peer with shown in <xref target="fig_es_connect" format="default"/>, IP applications pe
IP applications and Ethernet applications peer with Ethernet er with
IP applications, and Ethernet applications peer with Ethernet
applications. applications.
</t> </t>
<figure anchor="fig_es_connect">
<figure title="End-Systems and The DetNet MPLS Domain" anchor="fig_es_connect" <name>End Systems and the DetNet MPLS Domain</name>
> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
+-----+ +-----+
| X | +-----+ | X | +-----+
+-----+ | X | +-----+ | X |
| Eth | ________ +-----+ | Eth | ________ +-----+
+-----+ _____ / \ | Eth | +-----+ _____ / \ | Eth |
\ / \__/ \___ +-----+ \ / \__/ \___ +-----+
\ / \ / \ / \ /
0======== tunnel-1 ========0_ 0======== tunnel-1 ========0_
| \ | \
\ | \ |
0========= tunnel-2 =========0 0========= tunnel-2 =========0
/ \ __/ \ / \ __/ \
+-----+ \__ DetNet MPLS domain / \ +-----+ \__ DetNet MPLS domain / \
| X | \ __ / +-----+ | X | \ __ / +-----+
+-----+ \_______/ \_____/ | X | +-----+ \_______/ \_____/ | X |
| IP | +-----+ | IP | +-----+
+-----+ | IP | +-----+ | IP |
+-----+ +-----+]]></artwork>
]]> </figure>
</artwork></figure> </section>
<section anchor="subnet_considerations" numbered="true" toc="default">
</section> <name>Sub-network Considerations</name>
<section title="Sub-Network Considerations" anchor="subnet_considerations"> <t>
<t>
Any of the DetNet service types may be transported by another Any of the DetNet service types may be transported by another
DetNet service. MPLS nodes may be interconnected by different sub-network DetNet service. MPLS nodes may be interconnected by different sub-network
technologies, which may include point-to-point links. Each of these technologies, which may include point-to-point links. Each of these
sub-network technologies needs to provide appropriate service to DetNet sub-network technologies needs to provide appropriate service to DetNet
flows. In some cases, e.g., on dedicated point-to-point links or TDM 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 appropriately technologies, all that is required is for a DetNet node to appropriately
queue its output traffic. In other cases, DetNet nodes will need to map queue its output traffic. In other cases, DetNet nodes will need to map
DetNet flows to the flow semantics (i.e., identifiers) and mechanisms used DetNet flows to the flow semantics (i.e., identifiers) and mechanisms used
by an underlying sub-network technology. <xref by an underlying sub-network technology. <xref
target="fig_dn_mpls_sn_ex"/> shows several examples of header target="fig_dn_mpls_sn_ex" format="default"/> shows several examples of
formats that can be used to carry DetNet MPLS flows over different sub-network encapsulations that can be used to carry DetNet MPLS flows over
sub-network technologies. L2 represents a generic layer-2 encapsulation different
sub-network technologies. L2 represents a generic Layer 2 encapsulation
that might be used on a point-to-point link. TSN represents the that might be used on a point-to-point link. TSN represents the
encapsulation used on an IEEE 802.1 TSN network, as described in <xref encapsulation used on an IEEE 802.1 TSN network, as described in <xref targ
target="I-D.ietf-detnet-mpls-over-tsn"/>. UDP/IP represents the en et="DetNet-MPLS-over-TSN" format="default"/>. UDP/IP represents the encapsulati
capsulation on
used on a DetNet IP PSN, as described in <xref used on a DetNet IP PSN, as described in <xref target="DetNet-MPLS-over-UDP
target="I-D.ietf-detnet-mpls-over-udp-ip"/>. -IP" format="default"/>.
</t> </t>
<figure anchor="fig_dn_mpls_sn_ex">
<figure title="Example DetNet MPLS Sub-Network Formats" anchor="fig_dn_mpls_sn <name>Example DetNet MPLS Encapsulations in Sub-networks</name>
_ex"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
+------+ +------+ +------+ +------+ +------+ +------+
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 |
+------+ +------+ +------+ +------+ +------+ +------+
| IP | | IP |
+------+ +------+
| L2 | | L2 |
+------+ +------+]]></artwork>
]]> </figure>
</artwork></figure> </section>
</section> </section>
</section> </section>
<section anchor="cp_considerations" numbered="true" toc="default">
</section> <name>Controller Plane (Management and Control) Considerations</name>
<!-- ================================================================= --> <section anchor="control-management-requirements" numbered="true" toc="def
ault">
<section title="Controller Plane (Management and Control) <name>DetNet Controller Plane Requirements</name>
Considerations" anchor="cp_considerations"> <t>
<section title="DetNet Controller Plane Requirements"
anchor="control-management-requirements">
<t>
The Controller Plane corresponds to the aggregation of the Control and The Controller Plane corresponds to the aggregation of the Control and
Management Planes discussed in <xref target="RFC7426"/> and Management Planes discussed in <xref target="RFC7426" format="default"/>
<xref target="RFC8655"/>. While more details of any DetNet controller and
plane are out of the scope of this document, there are particular <xref target="RFC8655" format="default"/>. While more details regarding
considerations and requirements for such that result from the unique any DetNet Controller
Plane are out of scope for this document, there are particular
considerations and requirements for the Controller Plane that result fro
m the unique
characteristics of the DetNet architecture and characteristics of the DetNet architecture and
data plane as defined herein. data plane as defined herein.
</t> </t>
<t> <t>
The primary requirements of the DetNet controller plane are The primary requirements of the DetNet Controller Plane are
that it must be able to: that it must be able to:
<list style="symbols"> </t>
<t> <ul spacing="normal">
Instantiate DetNet flows in a DetNet domain (which may <li>
include some or all of explicit path determination, link Instantiate DetNet flows in a DetNet domain (which may, for example,
include some or all of the following: explicit path determination, l
ink
bandwidth reservations, restricting flows to IEEE 802.1 TSN bandwidth reservations, restricting flows to IEEE 802.1 TSN
links, node buffer and other resource reservations, links, node buffer and other resource reservations,
specification of required queuing disciplines along the specification of required queuing disciplines along the
path, ability to manage bidirectional flows, etc.) as needed path, ability to manage bidirectional flows, etc.) as needed
for a flow. for a flow.
</t> </li>
<t> <li>
In the case of MPLS, manage DetNet S-Label and F-Label allocation In the case of MPLS, manage DetNet S-Label and F-Label allocation
and distribution, where the DetNet MPLS encapsulation is in use see and distribution. In cases where the DetNet MPLS encapsulation is
<xref target="I-D.ietf-detnet-mpls"/>. being used, see <xref target="DetNet-MPLS" format="default"/>.
</t> </li>
<t> <li>
Support DetNet flow aggregation. Support DetNet flow aggregation.
</t> </li>
<t> <li>
Advertise static and dynamic node and link resources such Advertise static and dynamic node and link resources such
as capabilities and adjacencies to other network nodes (for as capabilities and adjacencies to other network nodes (for
dynamic signaling approaches) or to network controllers (for dynamic signaling approaches) or to network controllers (for
centralized approaches). centralized approaches).
</t> </li>
<t> <li>
Scale to handle the number of DetNet flows expected in a Scale to handle the number of DetNet flows expected in a
domain (which may require per-flow signaling or domain (which may require per-flow signaling or
provisioning). provisioning).
</t> </li>
<t> <li>
Provision flow identification information at each of the nodes Provision flow identification information at each of the nodes
along the path. Flow identification may differ depending on the along the path. Flow identification may differ, depending on the
location in the network and the DetNet functionality (e.g. transit location in the network and the DetNet functionality (e.g., transit
node vs. relay node). node vs. relay node).
</t> </li>
</list> </ul>
</t> <t>
<t>
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), distributed control protocol signaling (such as RSVP-TE),
centralized network management provisioning mechanisms (such as centralized network management provisioning mechanisms (BGP, PCEP, YANG,
BGP, PCEP, YANG <xref <xref target="I-D.ietf-detnet-flow-information-model" format="default"/>, etc.)
target="I-D.ietf-detnet-flow-information-model"/>, etc.) or hybrid , 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.
</t> </t>
<t> <t>
In the abstract, the results of either distributed signaling In the abstract, the results of either distributed signaling
or centralized provisioning are equivalent from a DetNet data or centralized provisioning are equivalent from a DetNet data plane
plane perspective - flows are instantiated, explicit routes perspective -- flows are instantiated, explicit routes
are determined, resources are reserved, and packets are are determined, resources are reserved, and packets are
forwarded through the domain using the DetNet data plane. forwarded through the domain using the DetNet data plane.
</t> </t>
<t> <t>
However, from a practical and implementation standpoint, controller plan However, from a practical and implementation standpoint, Controller Plan
e alternatives are not e alternatives are not
equivalent at all. Some approaches are more scalable than others in equivalent at all. Some approaches are more scalable than others in
terms of signaling load on the network. Some alternatives can take advan tage of terms of signaling load on the network. Some alternatives can take advan tage of
global tracking of resources in the DetNet domain for better overall global tracking of resources in the DetNet domain for better overall
network resource optimization. Some solutions are more resilient than ot hers if network resource optimization. Some solutions are more resilient than ot hers if
link, node, or management equipment failures occur. While a detailed link, node, or management equipment failures occur. While a detailed
analysis of the control plane alternatives is out of the scope of this analysis of the control plane alternatives is out of scope for this
document, the requirements from this document can be used as the basis document, the requirements from this document can be used as the basis
of a later analysis of the alternatives. of a future analysis of the alternatives.
</t> </t>
</section> </section>
<section anchor="gen_cp_considerations" numbered="true" toc="default">
<section title="Generic Controller Plane Considerations" anchor="gen_cp_consid <name>Generic Controller Plane Considerations</name>
erations"> <t>
<t>
This section covers control plane considerations that are This section covers control plane considerations that are
independent of the data plane technology used for DetNet service independent of the data plane technology used for DetNet service
delivery. delivery.
</t> </t>
<t> <t>
While the management plane and control planes are traditionally While the management plane and the control plane are traditionally
considered separately, from the 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 <xref information, and the DetNet architecture <xref target="RFC8655" format="de
target="RFC8655"/> refers to these collectively fault"/> refers to these collectively
as the 'Controller Plane'. This document therefore does not as the "Controller Plane". This document therefore does not
distinguish between information provided by distributed control distinguish between information provided by distributed control plane prot
plane protocols, e.g., RSVP-TE <xref target="RFC3209"/> and <xref ocols (e.g., RSVP-TE <xref target="RFC3209" format="default"/> <xref target="RFC
target="RFC3473"/>, or by centralized network management mechanisms, 3473" format="default"/>) or centralized network management mechanisms
e.g., RestConf <xref target="RFC8040"/>, YANG <xref (e.g., RESTCONF <xref target="RFC8040" format="default"/>, YANG <xref targ
target="RFC7950"/>, and the Path Computation Element Communication et="RFC7950" format="default"/>, PCEP <xref target="I-D.ietf-pce-pcep-extension-
Protocol (PCEP) <xref for-pce-controller" format="default"/>), or any
target="I-D.ietf-pce-pcep-extension-for-pce-controller"/> or any
combination thereof. Specific considerations and requirements for combination thereof. Specific considerations and requirements for
the DetNet Controller Plane are discussed in <xref the DetNet Controller Plane are discussed in <xref target="control-managem
target="control-management-requirements"/>. ent-requirements" format="default"/>.
</t> </t>
<t> <t>
Each respective data plane document also covers the control plane consider ations Each respective data plane document also covers the control plane consider ations
for that technology. For example, <xref target="I-D.ietf-detnet-ip"/> cov for that technology. For example, <xref target="RFC8939"
ers IP format="default"/> also covers IP
control plane normative considerations and <xref control plane normative considerations, and <xref target="DetNet-MPLS"
target="I-D.ietf-detnet-mpls"/> covers MPLS control plane format="default"/> also covers MPLS control plane
normative considerations. normative considerations.
</t> </t>
<section numbered="true" toc="default">
<section title="Flow Aggregation Control"> <name>Flow Aggregation Control</name>
<t> <t>
Flow aggregation means that multiple app-flows are served by a single ne Flow aggregation means that multiple App-flows are served by a single ne
w DetNet w DetNet
flow. There are many techniques to achieve aggregation. For example, flow. There are many techniques to achieve aggregation. For example,
in the case of IP, IP flows that share 6-tuple attributes or flo in the case of IP, IP flows that share 6-tuple attributes or flo
w w
identifiers at the DetNet sub-layer can be grouped. identifiers at the DetNet sub&nbhy;layer can be grouped.
Another example includes aggregation accomplished through the us e of Another example includes aggregation accomplished through the us e of
hierarchical LSPs in MPLS and tunnels. hierarchical LSPs in MPLS and tunnels.
</t> </t>
<t> <t>
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 may Aggregation may use some or all of these capabilities, and the order may
vary: vary:
<list style="symbols"> </t>
<t> Traffic engineering resource collection and distribution: <dl newline="true" spacing="normal">
<list style="empty"> <dt>Traffic engineering resource collection and distribution:</dt>
<t> <dd>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.</dd>
</t> <dt>Path computation and resource allocation:</dt>
</list> <dd>When DetNet services are provisioned or requested, one or more
</t>
<t> Path computation and resource allocation:
<list style="empty">
<t>
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.</dd>
</t> <dt>Resource assignment and data plane coordination:</dt>
</list> <dd>The assignment of resources along the path depends on the techn
</t> ology and
<t> Resource assignment and data plane co-ordination: includes assignment of specific links, coordination of
<list style="empty"> queuing, and other traffic management capabilities such as policing a
<t> nd shaping.</dd>
The assignment of resources along the path depends on the technol <dt>Assigned resource recording and updating:</dt>
ogy and <dd>Depending on the specific technology, the assigned resources ar
includes assignment of specific links, coordination of e
queueing, and other traffic management capabilities su updated and distributed in the databases, preventing oversubscription
ch as policing and shaping. .</dd>
</t> </dl>
</list> </section>
</t> <section numbered="true" toc="default">
<t> Assigned Resource recording and updating: <name>Explicit Routes</name>
<list style="empty"> <t>
<t>
Depending on the specific technology, the assigned resources are
updated and distributed in the databases, preventing over-sub
scription.
</t>
</list>
</t>
</list>
</t>
</section>
<section title="Explicit Routes">
<t>
Explicit routes are used to ensure that packets are routed through the Explicit routes are used to ensure that packets are routed through the
resources that have been reserved for them, and hence provide 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 has identified DetNet IP flow to a path through the DetNet domain that has
been assigned the required per-node resources. This provides the been assigned the required per-node resources. This provides the
appropriate traffic treatment for the flow and also includes particular appropriate traffic treatment for the flow and also includes particular
links as a part of the path that are able to support the DetNet flow. 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 discussed in For example, by using IEEE 802.1 TSN links (as discussed in
<xref target="I-D.ietf-detnet-mpls-over-tsn"/> ) DetNet parameters can b e maintained. <xref target="DetNet-MPLS-over-TSN" format="default"/>), DetNet paramete rs can be maintained.
Further considerations and requirements for the DetNet Controller Plane Further considerations and requirements for the DetNet Controller Plane
are discussed in <xref target="control-management-requirements"/>. are discussed in <xref target="control-management-requirements" format="
</t> default"/>.
<t> </t>
Whether configuring, calculating and instantiating these <t>
routes is a single-stage or multi-stage process, or in a Whether configuring, calculating, and instantiating these
centralized or distributed manner, is out of scope of this routes is a single-stage or multi-stage process, or is performed in a
centralized or distributed manner, is out of scope for this
document. document.
</t> </t>
<t> <t>
There are several approaches that could be used to provide There are several approaches that could be used to provide
explicit routes and resource allocation in the DetNet explicit routes and resource allocation in the DetNet
forwarding sub-layer. For example: forwarding sub&nbhy;layer. For example:
<list style="symbols"> </t>
<t> <ul spacing="normal">
The path could be explicitly set up by a controller which <li>
The path could be explicitly set up by a controller that
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.
</t> </li>
<t> <li>
The path could use a distributed control plane such as The path could use a distributed control plane such as
<xref target="RFC2205">RSVP</xref> or RSVP-TE <xref <xref target="RFC2205" format="default">RSVP</xref> or RSVP-TE <xref
target="RFC3473"/> extended to support DetNet IP flows. target="RFC3473" format="default"/> extended to support DetNet IP flows.
</t> </li>
<t> <li>
The path could be implemented using IPv6-based segment The path could be implemented using IPv6-based segment
routing when extended to support resource allocation. routing when extended to support resource allocation.
</t> </li>
</list> </ul>
See <xref target="control-management-requirements"/> for <t>
See <xref target="control-management-requirements" format="default"/> fo
r
further discussion of these alternatives. In addition, further discussion of these alternatives. In addition,
<xref target="RFC2386"/> contains useful background information <xref target="RFC2386" format="default"/> contains useful background inf
on QoS-based routing, and <xref target="RFC5575"/> (being ormation
updated by <xref target="I-D.ietf-idr-rfc5575bis"/>) discusses on QoS-based routing, and <xref target="RFC5575" format="default"/>
a specific mechanism used by BGP for traffic flow specification (which will be
and policy-based routing. updated by <xref target="I-D.ietf-idr-rfc5575bis" format="default"/>) di
</t> scusses
</section> a specific mechanism used by BGP for traffic flow specification
<section title="Contention Loss and Jitter Reduction"> and policy-based routing.
<t> </t>
As discussed in <xref target="sec_intro"/>, this document does </section>
not specify the mechanisms needed to eliminate packet contention, packet <section numbered="true" toc="default">
loss <name>Contention Loss and Jitter Reduction</name>
or reduce jitter for DetNet flows at the DetNet forwarding <t>
sub-layer. The ability to manage node and link resources to This document does
not specify the mechanisms needed to eliminate packet contention or pack
et loss
or to reduce jitter for DetNet flows at the DetNet forwarding
sub&nbhy;layer. The ability to manage node and link resources to
be able to provide these functions is a necessary part of be able to provide these functions is a necessary part of
the DetNet controller plane. It is also necessary to be the DetNet Controller Plane. It is also necessary to be
able to control the required queuing mechanisms used to able to control the required queuing mechanisms used to
provide these functions along a flow's path through the provide these functions along a flow's path through the
network. See <xref target="I-D.ietf-detnet-ip"/> and <xref network. See <xref target="RFC8939" format="default"/> and <xref target
target="control-management-requirements"/> for further ="control-management-requirements" format="default"/> for further
discussion of these requirements. Some forms of protection discussion of these requirements. Some forms of protection
may minimize packet loss or change may minimize packet loss or change
jitter characteristics in the cases where packets are reordered when out jitter characteristics in the cases where packets are reordered when out
-of-order packets are received at the service sub-layer. -of-order packets are received at the service sub&nbhy;layer.
</t> </t>
</section> </section>
<section title="Bidirectional Traffic"> <section numbered="true" toc="default">
<t> <name>Bidirectional Traffic</name>
In many cases DetNet flows can be considered unidirectional and <t>
In many cases, DetNet flows can be considered unidirectional and
independent. However, there are cases where the DetNet service requires independent. However, there are cases where the DetNet service requires
bidirectional traffic from a DetNet application service perspective. IP and bidirectional traffic from a DetNet application service perspective. 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. The IETF MPLS Working Group has
traffic requirements and the MPLS definitions from <xref studied bidirectional traffic requirements. The definitions provided in <xref ta
target="RFC5654"/> are useful to illustrate terms such as rget="RFC5654" format="default"/> are useful to illustrate terms such as
associated bidirectional flows and co-routed bidirectional flows. MPLS associated bidirectional flows and co-routed bidirectional flows.
MPLS
defines a point-to-point associated bidirectional LSP as consisting of defines a point-to-point associated bidirectional LSP as consisting of
two unidirectional point-to-point LSPs, one from A to B and the other two unidirectional point-to-point LSPs, one from A to B and the other
from B to A, which are regarded as providing a single logical from B to A, which are regarded as providing a single logical
bidirectional forwarding path. This is analogous to standard IP bidirectional forwarding path. This is analogous to standard IP
routing. MPLS defines a point-to-point co-routed bidirectional LSP as routing. MPLS defines a point-to-point co-routed bidirectional LSP as
an associated bidirectional LSP which satisfies the additional an associated bidirectional LSP that satisfies the additional
constraint that its two unidirectional component LSPs follow the same constraint that its two unidirectional component LSPs follow the same
path (in terms of both nodes and links) in both directions. An path (in terms of both nodes and links) in both directions. An
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 direction. bidirectional LSPs, resource reservations may differ in each direction.
The concepts of associated bidirectional flows and co-routed The concepts of associated bidirectional flows and co&nbhy;routed
bidirectional flows can also be applied to DetNet IP flows. bidirectional flows can also be applied to DetNet IP flows.
</t> </t>
<t> <t>
While the DetNet IP data plane must support bidirectional While the DetNet IP data plane must support bidirectional
DetNet flows, there are no special bidirectional features with DetNet flows, there are no special bidirectional features with
respect to the data plane other than the need for the two respect to the data plane other than the need for the two
directions of a co-routed bidirectional flow to take the same directions of a co&nbhy;routed bidirectional flow to take the same
path. That is to say that bidirectional DetNet flows are path. That is to say, bidirectional DetNet flows are
solely represented at the management and control plane levels, solely represented at the management plane and control plane levels,
without specific support or knowledge within the DetNet data without specific support or knowledge within the DetNet data
plane. Fate sharing and associated or co-routed plane. Fate-sharing and associated or co&nbhy;routed
bidirectional flows, can be managed at the control level. bidirectional flows can be managed at the control level.
</t> </t>
<t> <t>
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&nbhy;routi
bidirectional flows, since if PREOF is used, then the replicatio ng
n points bidirectional flows, because if PREOF are used, the replication points
in one direction would have to match the elimination points in t in one direction would have to match the elimination points in the
he other direction, and vice versa. In such cases, the optimal points for
other direction, and vice versa. In such cases the optimal point these functions in one direction may not match the optimal points in
s for the other, due to network and traffic constraints.
these functions in one direction may not match the optimal point Furthermore, due to the per-packet service protection nature,
s in bidirectional forwarding may not be ensured.
the other, due to 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 The first packet of received member flows is selected by the
elimination function independently of which path it has taken elimination function independently of which path it has taken
through the network. through the network.
</t> </t>
<t> <t>
Control and management mechanisms need to support bidirectional flows, Control and management mechanisms need to support bidirectional flows,
but the specification of such mechanisms are out of scope of this but the specification of such mechanisms is out of scope for this
document. Example control plane solutions for MPLS can be found in <xref document. Example control plane solutions for MPLS can be found in <xref
target="RFC3473"/> , <xref target="RFC6387"/> and <xref target="RFC3473" format="default"/>, <xref target="RFC6387" format="default"/>,
target="RFC7551"/>. These requirements are included in <xref and <xref target="RFC7551" format="default"/>. These requirements are included
target="control-management-requirements"/>. in <xref target="control-management-requirements" format="default"/>.
</t> </t>
<!--
-->
</section> </section>
</section> </section>
<section anchor="PREOF" numbered="true" toc="default">
<section title="Packet Replication, Elimination, and Ordering (PREOF)" ancho <name>Packet Replication, Elimination, and Ordering Functions (PREOF)</n
r="PREOF"> ame>
<t> <t>
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 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 particular flow, optimal packet replication and elimination
points in the DetNet domain requires explicit support. There may points in the DetNet domain requires explicit support. There may
be existing capabilities that can be used, or extended, for example GMPL be existing capabilities that can be used or extended -- for example, GM
S PLS
end-to-end recovery <xref target="RFC4872"/> and GMPLS segment end-to-end recovery <xref target="RFC4872" format="default"/> and GMPLS
recovery <xref target="RFC4873"/>. segment
</t> recovery <xref target="RFC4873" format="default"/>.
</t>
</section>
</section> </section>
</section> <section numbered="true" toc="default">
<name>Security Considerations</name>
<!-- ===================================================================== - <t>
->
<section title="Security Considerations">
<t>
Security considerations for DetNet are described in detail in Security considerations for DetNet are described in detail in
<xref target="I-D.ietf-detnet-security"/>. General security considerations <xref target="DetNet-Security" format="default"/>. General security consider
for DetNet architecture are described in <xref target="RFC8655"/>. This sect ations
ion for the DetNet architecture are described in <xref target="RFC8655" format="
default"/>. This section
considers architecture-level DetNet security considerations applicable to al l data planes. considers architecture-level DetNet security considerations applicable to al l data planes.
</t> </t>
<t> <t>
Part of what makes DetNet unique is its ability to provide specific and Part of what makes DetNet unique is its ability to provide specific and
reliable quality of service (delivering data flows with extremely low reliable QoS (delivering data flows with extremely low
packet loss rates and bounded end-to-end delivery latency), and the packet loss rates and bounded end-to-end delivery latency), and the
security-related aspects of protecting that quality of service are security-related aspects of protecting that QoS are
similarly unique. similarly unique.
</t> </t>
<t> <t>
As for all communications protocols, As for all communications protocols,
the primary consideration for the data plane is to maintain the primary consideration for the data plane is to maintain
integrity of data and delivery of the associated DetNet service traversing integrity of data and delivery of the associated DetNet service traversing
the DetNet network. the DetNet network.
Application flows can be protected through whatever means is Application flows can be protected through whatever means is
provided by the underlying technology. For example, encryption may be provided by the underlying technology. For example, encryption may be
used, such as that provided by IPSec <xref target="RFC4301"/> for IP used, such as that provided by IPsec <xref target="RFC4301" format="default
flows and/or by an underlying sub-net using MACSec "/> for IP
<xref target="IEEE802.1AE-2018"/> for Ethernet (Layer-2) flows. flows and/or by an underlying sub-network using MACsec
</t> <xref target="IEEE802.1AE-2018" format="default"/> for Ethernet (Layer 2) f
<t> lows.
At the management and control level DetNet flows are identified on a </t>
per-flow basis, which may provide controller plane <t>
At the management and control levels, DetNet flows are identified on a
per-flow basis, which may provide Controller Plane
attackers with additional information about the data flows (when attackers with additional information about the data flows (when
compared to controller planes that do not include per-flow identification). compared to Controller Planes that do not include per-flow identification).
This is an inherent property of DetNet which has security This is an inherent property of DetNet that has security
implications that should be considered when determining if DetNet is implications that should be considered when determining if DetNet is
a suitable technology for any given use case. a suitable technology for any given use case.
</t> </t>
<t> <t>
To provide uninterrupted availability of the DetNet To provide uninterrupted availability of the DetNet
service, provisions can be made against DOS attacks and delay service, provisions can be made against DoS attacks and delay
attacks. To protect against DOS attacks, excess traffic due to attacks. To protect against DoS attacks, excess traffic due to
malicious or malfunctioning devices can be prevented or mitigated, malicious or malfunctioning devices can be prevented or mitigated --
for example through the use of existing mechanisms such as policing and sha for example, through the use of existing mechanisms such as policing and sh
ping applied at aping applied at
the input of a DetNet domain. To prevent DetNet packets from the input of a DetNet domain. To prevent DetNet packets from
being delayed by an entity external to a DetNet domain, DetNet being delayed by an entity external to a DetNet domain, DetNet
technology definition can allow for the mitigation of technology definitions can allow for the mitigation of
Man-In-The-Middle attacks, for example through use of man-in-the-middle attacks -- for example, through the use of
authentication and authorization of devices within the DetNet domain. authentication and authorization of devices within the DetNet domain.
</t> </t>
<t> <t>
In order to prevent or mitigate DetNet attacks on other networks via In order to prevent or mitigate DetNet attacks on other networks via
flow escape, edge devices can for example use existing mechanism such flow escape, edge devices can, for example, use existing mechanisms suc h
as policing and shaping applied at the output of a DetNet domain. as policing and shaping applied at the output of a DetNet domain.
</t> </t>
</section> </section>
<section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
This document has no IANA actions.
</t>
</section>
</middle>
<back>
<section anchor="iana" title="IANA Considerations"> <displayreference target="I-D.ietf-pce-pcep-extension-for-pce-controller" to="PC
<t> ECC"/>
This document makes no IANA requests. <displayreference target="I-D.ietf-detnet-flow-information-model" to="DetNet-Flo
</t> w-Info"/>
</section> <displayreference target="I-D.ietf-idr-rfc5575bis" to="Flow-Spec-Rules"/>
<section anchor="acks" title="Acknowledgements"> <references>
<t> <name>References</name>
The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, David <references>
Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig <name>Normative References</name>
Gunther, George Swallow, Yuanlong Jiang and Carlos J. Bernardos for their <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8655.
various contributions to this work. xml"/>
</t> </references>
</section> <references>
<section anchor="contrib" title="Contributors"> <name>Informative References</name>
<t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3209.
The following people contributed substantially to the content of this xml"/>
document: <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3473.
<?rfc subcompact="yes" ?> xml"/>
<list style=""> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2205.
<t> Don Fedyk </t> xml"/>
<t> Jouni Korhonen</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2386.
</list> xml"/>
<?rfc subcompact="no" ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4872.
</t> xml"/>
</section> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4873.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7657.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3670.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5575.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5654.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6387.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7551.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8227.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4301.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7426.
xml"/>
</middle> <!-- draft-ietf-pce-pcep-extension-for-pce-controller (I-D Exists) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pce-pcep-e
xtension-for-pce-controller.xml"/>
<back> <!-- draft-ietf-detnet-flow-information-model (Waiting for Writeup) -->
<references title="Normative References"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-detnet-flo
<?rfc include="reference.RFC.8655"?> w-information-model.xml"/>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3209"?>
<?rfc include="reference.RFC.3473"?>
<?rfc include="reference.RFC.4385"?>
<?rfc include="reference.RFC.2205"?>
<?rfc include="reference.RFC.2386"?>
<?rfc include="reference.RFC.4872"?>
<?rfc include="reference.RFC.4873"?>
<?rfc include="reference.RFC.7657"?>
<?rfc include="reference.RFC.3670"?>
<?rfc include="reference.RFC.5575"?>
<?rfc include="reference.RFC.5654"?>
<?rfc include="reference.RFC.6387"?>
<?rfc include="reference.RFC.7950"?>
<?rfc include="reference.RFC.7551"?>
<?rfc include="reference.RFC.8040"?>
<?rfc include="reference.RFC.8227"?>
<?rfc include="reference.RFC.4301"?>
<?rfc include="reference.RFC.7426"?>
<?rfc include="reference.I-D.ietf-pce-pcep-extension-for-pce-controller"?>
<?rfc include="reference.I-D.ietf-detnet-flow-information-model"?>
<?rfc include="reference.I-D.ietf-detnet-ip"?>
<?rfc include="reference.I-D.ietf-detnet-mpls"?>
<?rfc include="reference.I-D.ietf-detnet-mpls-over-tsn"?>
<?rfc include="reference.I-D.ietf-detnet-mpls-over-udp-ip"?>
<?rfc include="reference.I-D.ietf-detnet-security"?>
<?rfc include="reference.I-D.ietf-idr-rfc5575bis"?>
<!--reference anchor='I-D.ietf-detnet-ip-over-tsn'> <!-- draft-ietf-detnet-ip (RFC 8939) -->
<front> <reference anchor="RFC8939" target="https://www.rfc-editor.org/info/rfc8939">
<title>DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (T <front>
SN) <title>Deterministic Networking (DetNet) Data Plane: IP</title>
</title> <author initials="B" surname="Varga" fullname="Balazs Varga" role="editor">
<author> <organization/>
<organization>Korhonen, J., Varga, B.</organization> </author>
</author> <author initials="J" surname="Farkas" fullname="Janos Farkas">
<date year='2018' /> <organization/>
</front> </author>
</reference--> <author initials="L" surname="Berger" fullname="Lou Berger">
<organization/>
</author>
<author initials="D" surname="Fedyk" fullname="Don Fedyk">
<organization/>
</author>
<author initials="S" surname="Bryant" fullname="Stewart Bryant">
<organization/>
</author>
<date month='November' year='2020'/>
</front>
<seriesInfo name="RFC" value="8939"/>
<seriesInfo name="DOI" value="10.17487/RFC8939"/>
</reference>
<?rfc include="reference.I-D.ietf-spring-srv6-network-programming"?> <!-- draft-ietf-detnet-mpls (RFC-EDITOR) -->
<!-- Have to do long way; Balazs Varga is an editor -->
<reference anchor="DetNet-MPLS" target="https://tools.ietf.org/html/draf
t-ietf-detnet-mpls-13">
<front>
<title>DetNet Data Plane: MPLS</title>
<author initials="B" surname="Varga" fullname="Balazs Varga" role="e
ditor">
<organization/>
</author>
<author initials="J" surname="Farkas" fullname="Janos Farkas">
<organization/>
</author>
<author initials="L" surname="Berger" fullname="Lou Berger">
<organization/>
</author>
<author initials="A" surname="Malis" fullname="Andrew Malis">
<organization/>
</author>
<author initials="S" surname="Bryant" fullname="Stewart Bryant">
<organization/>
</author>
<author initials="J" surname="Korhonen" fullname="Jouni Korhonen">
<organization/>
</author>
<date month="October" day="11" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-detnet-mpls-13"/>
</reference>
<!--reference anchor="IEEE8021Q" <!-- draft-ietf-detnet-mpls-over-tsn (I-D Exists) -->
target="http://standards.ieee.org/about/get/"> <!-- Have to do long way; Balazs Varga is an editor -->
<front> <reference anchor="DetNet-MPLS-over-TSN" target="https://tools.ietf.org/
<title>Standard for Local and metropolitan area networks-Bridges and Bridg html/draft-ietf-detnet-mpls-over-tsn-04">
ed Networks (IEEE Std 802.1Q-2014) <front>
</title> <title>DetNet Data Plane: MPLS over IEEE 802.1 Time Sensitive Networ
<author> king (TSN)</title>
<organization>IEEE 802.1</organization> <author initials="B" surname="Varga" fullname="Balazs Varga" role="e
</author> ditor">
<date year="2014"/> <organization/>
</front> </author>
<format type="PDF" target="http://standards.ieee.org/about/get/"/> <author initials="J" surname="Farkas" fullname="Janos Farkas">
</reference--> <organization/>
<reference anchor="IEEE802.1TSNTG" target="http://www.ieee802.org/1/tsn"> </author>
<front> <author initials="A" surname="Malis" fullname="Andrew Malis">
<title>IEEE 802.1 Time-Sensitive Networking Task Group</title> <organization/>
<author> </author>
<organization>IEEE Standards Association</organization> <author initials="S" surname="Bryant" fullname="Stewart Bryant">
</author> <organization/>
<date></date> </author>
</front> <date month="November" day="2" year="2020"/>
</reference> </front>
<reference anchor="IEEE802.1AE-2018" target="https://ieeexplore.ieee.org/doc <seriesInfo name="Internet-Draft" value="draft-ietf-detnet-mpls-over-t
ument/8585421"> sn-04"/>
<front> </reference>
<title>IEEE Std 802.1AE-2018 MAC Security (MACsec)</title>
<author>
<organization>IEEE Standards Association</organization>
</author>
<date year="2018" />
</front>
</reference>
<reference anchor="nwcrg" target="https://datatracker.ietf.org/rg/nwcrg/abou
t">
<front>
<title>Coding for efficient NetWork Communications Research Group (nwcrg
)</title>
<author>
<organization>IRTF</organization>
</author>
<date year="" />
</front>
</reference>
<!--reference anchor="IEEE8021CB" <!-- draft-ietf-detnet-mpls-over-udp-ip (Waiting for Writeup) -->
target="http://www.ieee802.org/1/files/private/cb-drafts/d2/802-1CB-d2-1.pdf <!-- Have to do long way; Balazs Varga is an editor -->
"> <reference anchor="DetNet-MPLS-over-UDP-IP" target="https://tools.ietf.o
<front> rg/html/draft-ietf-detnet-mpls-over-udp-ip-07">
<title>Draft Standard for Local and metropolitan area networks - Seamles <front>
s Redundancy</title> <title>DetNet Data Plane: MPLS over UDP/IP</title>
<author initials="N. F." surname="Finn" fullname="Norman Finn"> <author initials="B" surname="Varga" fullname="Balazs Varga" role="e
<organization>IEEE 802.1</organization> ditor">
</author> <organization/>
<date month="December" year="2015"/> </author>
</front> <author initials="J" surname="Farkas" fullname="Janos Farkas">
<seriesInfo name="IEEE P802.1CB /D2.1" value="P802.1CB"/> <organization/>
<format type="PDF" target="http://www.ieee802.org/1/files/private/cb-drafts/ </author>
d2/802-1CB-d2-1.pdf"/> <author initials="L" surname="Berger" fullname="Lou Berger">
</reference--> <organization/>
</author>
<author initials="A" surname="Malis" fullname="Andrew Malis">
<organization/>
</author>
<author initials="S" surname="Bryant" fullname="Stewart Bryant">
<organization/>
</author>
<date month="October" day="11" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-detnet-mpls-over-u
dp-ip-07"/>
</reference>
<!--reference anchor="G.8275.1" <!-- draft-ietf-detnet-security (Waiting for Writeup) -->
target="https://www.itu.int/rec/T-REC-G.8275.1/en"> <!-- Have to do long way; Ethan Grossman is an editor -->
<front> <reference anchor="DetNet-Security" target="https://tools.ietf.org/html/
<title>Precision time protocol telecom profile for phase/time synchroniza draft-ietf-detnet-security-12">
tion with full timing support from the network</title> <front>
<author> <title>Deterministic Networking (DetNet) Security Considerations</ti
<organization>International Telecommunication Union</organization> tle>
</author> <author initials="E" surname="Grossman" fullname="Ethan Grossman" r
<date month="June" year="2016"/> ole="editor">
</front> <organization/>
<seriesInfo name="ITU-T G.8275.1/Y.1369.1" value="G.8275.1"/> </author>
</reference--> <author initials="T" surname="Mizrahi" fullname="Tal Mizrahi">
<organization/>
</author>
<author initials="A" surname="Hacker" fullname="Andrew Hacker">
<organization/>
</author>
<date month="October" day="2" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-detnet-security-12
"/>
</reference>
<!--reference anchor="G.8275.2" <!-- draft-ietf-idr-rfc5575bis (MISSREF) -->
target="https://www.itu.int/rec/T-REC-G.8275.2/en"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-idr-rfc557
<front> 5bis.xml"/>
<title>Precision time protocol telecom profile for phase/time synchroniza
tion with partial timing support from the network</title>
<author>
<organization>International Telecommunication Union</organization>
</author>
<date month="June" year="2016"/>
</front>
<seriesInfo name="ITU-T G.8275.2/Y.1369.2" value="G.8275.2"/>
</reference-->
</references> <!-- draft-ietf-spring-srv6-network-programming (ESG Eval::AD Followup) -->
<!-- Had to do long way; 2 coauthors are also editors -->
<reference anchor="SRv6-Network-Prog" target="https://tools.ietf.org/html/dra
ft-ietf-spring-srv6-network-programming-24">
<front>
<title>SRv6 Network Programming</title>
<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
role="editor">
<organization/>
</author>
<author initials="P" surname="Camarillo" fullname="Pablo Camarillo"
role="editor">
<organization/>
</author>
<author initials="J" surname="Leddy" fullname="John Leddy">
<organization/>
</author>
<author initials="D" surname="Voyer" fullname="Daniel Voyer">
<organization/>
</author>
<author initials="S" surname="Matsushima" fullname="Satoru Matsushim
a">
<organization/>
</author>
<author initials="Z" surname="Li" fullname="Zhenbin Li">
<organization/>
</author>
<date month="October" day="7" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-spring-srv6-networ
k-programming-24"/>
</reference>
</back> <reference anchor="IEEE802.1TSNTG" target="https://1.ieee802.org/tsn/">
<front>
<title>Time-Sensitive Networking (TSN) Task Group</title>
<author>
<organization>IEEE</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="IEEE802.1AE-2018" target="https://ieeexplore.ieee.org
/document/8585421">
<front>
<title>IEEE Standard for Local and metropolitan area
networks-Media Access Control (MAC) Security</title>
<author>
<organization>IEEE</organization>
</author>
<date month="December" year="2018"/>
</front>
<seriesInfo name='IEEE Std' value='802.1AE-2018' />
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8585421"/>
</reference>
<reference anchor="nwcrg" target="https://datatracker.ietf.org/rg/nwcrg/
about">
<front>
<title>Coding for efficient NetWork Communications Research Group (n
wcrg)</title>
<author>
<organization>IRTF</organization>
</author>
<!-- <date year=""/> -->
</front>
</reference>
</references>
</references>
<section anchor="acks" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
The authors wish to thank <contact fullname="Pat Thaler"/>, <contact
fullname="Norman Finn"/>, <contact fullname="Loa Andersson"/>, <contact
fullname="David Black"/>, <contact fullname="Rodney Cummings"/>, <contact
fullname="Ethan Grossman"/>, <contact fullname="Tal Mizrahi"/>, <contact
fullname="David Mozes"/>, <contact fullname="Craig Gunther"/>, <contact
fullname="George Swallow"/>, <contact fullname="Yuanlong Jiang"/>, and
<contact fullname="Carlos J. Bernardos"/> for their various contributions
to this work.
</t>
</section>
<section anchor="contrib" numbered="false" toc="default">
<name>Contributors</name>
<t>
The following people contributed substantially to the content of this
document:</t>
<ul empty="true" spacing="compact">
<li><t><contact fullname="Don Fedyk"/></t></li>
<li><t><contact fullname="Jouni Korhonen"/></t></li>
</ul>
</section>
</back>
</rfc> </rfc>
 End of changes. 204 change blocks. 
981 lines changed or deleted 1086 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/