rfc8964xml2.original.xml   rfc8964.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">
]>
<?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="std"
docName="draft-ietf-detnet-mpls-13"
ipr="trust200902"
submissionType="IETF">
<front>
<title abbrev="DetNet MPLS">
DetNet Data Plane: MPLS</title>
<author role="editor" fullname="Bal&aacute;zs Varga" initials="B." surname="Va <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
rga"> docName="draft-ietf-detnet-mpls-13" number="8964" ipr="trust200902"
<organization>Ericsson</organization> submissionType="IETF" category="std" consensus="true" obsoletes=""
<address> updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true"
<postal> version="3">
<!-- xml2rfc v2v3 conversion 3.3.0 -->
<front>
<title abbrev="DetNet Data Plane: MPLS">
Deterministic Networking (DetNet) Data Plane: MPLS</title>
<seriesInfo name="RFC" value="8964"/>
<author role="editor" fullname="Balázs Varga" initials="B." surname="Varga">
<organization>Ericsson</organization>
<address>
<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 45 skipping to change at line 39
<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>
<author fullname="Jouni Korhonen" initials="J." surname="Korhonen"> <author fullname="Jouni Korhonen" initials="J." surname="Korhonen">
<!--organization abbrev="Nordic">Nordic Semiconductor</organization--> <address> <email>jouni.nospam@gmail.com</email>
<address>
<email>jouni.nospam@gmail.com</email>
</address> </address>
</author> </author>
<date year="2021" month="January"/>
<workgroup>DetNet</workgroup>
<!--author fullname="Donald Fauntleroy Duck" initials="D. F." surname="Duck"> <abstract>
<organization abbrev="Royal Bros.">Royal Bros.</organization> <t>
<address> This document specifies the Deterministic Networking (DetNet) data plane
<postal>
<street>13 Paradise Road</street>
<city>Duckburg</city>
<region>Calisota</region>
<country>USA</country>
</postal>
</address>
</author-->
<date />
<workgroup>DetNet</workgroup>
<abstract>
<t>
This document specifies the Deterministic Networking data plane
when operating over an MPLS Packet Switched Network. It leverages when operating over an MPLS Packet Switched Network. It leverages
existing pseudowire (PW) encapsulations and MPLS Traffic existing pseudowire (PW) encapsulations and MPLS Traffic Engineering
Engineering encapsulations and mechanisms. This document builds on (MPLS-TE) encapsulations and mechanisms. This document builds on the
the DetNet Architecture and Data Plane Framework. DetNet architecture and data plane framework.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section anchor="sec_intro" numbered="true" toc="default">
<section title="Introduction" anchor="sec_intro"> <name>Introduction</name>
<!-- Note: There are no dedicated section to procedures like "DetNet IP Data Pla
ne Procedures" here. Do we need it like in DetNet-IP document ??? -->
<t> <t>
Deterministic Networking (DetNet) is a service that can be offered by a Deterministic Networking (DetNet) is a service that can be offered by a
network to DetNet flows. network to DetNet flows.
DetNet provides a capability for the delivery of data flows with DetNet provides a capability for the delivery of data flows with
extremely low packet loss rates and bounded end-to-end delivery extremely low packet loss rates and bounded end-to-end delivery
latency. latency.
General background and concepts of DetNet can be found in the DetNet General background and concepts of DetNet can be found in the DetNet
Architecture <xref target="RFC8655"/>. architecture <xref target="RFC8655" format="default"/>.
</t> </t>
<t> <t>
The purpose of this document is to describe the use of the MPLS The purpose of this document is to describe the use of the MPLS
data plane to establish and support DetNet flows. data plane to establish and support DetNet flows.
The DetNet Architecture models the DetNet related data plane The DetNet architecture models the DetNet-related data plane
functions decomposed into two sub-layers: a service sub-layer and a functions as being decomposed into two sub-layers: a service sub-layer and a
forwarding sub-layer. The service sub-layer is used to provide forwarding sub-layer. The service sub-layer is used to provide
DetNet service functions such as protection and reordering. At the DetNet service functions, such as protection and reordering. At the
DetNet data plane a new set of functions (PREOF) provide the service DetNet data plane, a new set of functions (Packet Replication, Elimination
sub-layer specific tasks. The forwarding sub-layer is used to provide and Ordering Functions (PREOF)) provide the tasks specific to the service
sub-layer. The forwarding sub-layer is used to provide
forwarding assurance (low loss, assured latency, and limited forwarding assurance (low loss, assured latency, and limited
out-of-order delivery). The use of the functionalities of the DetNet out-of-order delivery). The use of the functionalities of the DetNet
service sub-layer and the DetNet forwarding sub-layer require service sub-layer and the DetNet forwarding sub-layer require
careful design and control by the controller plane in addition to the careful design and control by the Controller Plane in addition to the
DetNet specific use of MPLS encapsulation as specified by this DetNet-specific use of MPLS encapsulation as specified by this
document. document.
</t> </t>
<t> <t>
This document specifies the DetNet data plane operation and the on-wire This document specifies the DetNet data plane operation and the on-wire
encapsulation of DetNet flows over an MPLS-based Packet Switched Network encapsulation of DetNet flows over an MPLS-based Packet Switched Network
(PSN) using the service reference model. MPLS encapsulation (PSN) using the service reference model. MPLS encapsulation
already provides a solid foundation of building blocks to enable the DetNet already provides a solid foundation of building blocks to enable the DetNet
service and forwarding sub-layer functions. MPLS encapsulated DetNet can service and forwarding sub-layer functions.
MPLS-encapsulated DetNet can
be carried over a variety of different network technologies that can be carried over a variety of different network technologies that can
provide the DetNet required level of service. However, the specific provide the level of service required for DetNet. However, the specific
details of how DetNet MPLS is carried over different network technologies details of how DetNet MPLS is carried over different network technologies
are out of scope of this document. are out of scope for this document.
</t> </t>
<t> <t>
MPLS encapsulated DetNet flows can carry different types of MPLS-encapsulated DetNet flows can carry different types of
traffic. The details of the types of traffic that are carried in traffic. The details of the types of traffic that are carried in
DetNet are also out of scope of this document. An example of IP DetNet are also out of scope for this document. An example of IP
using DetNet MPLS sub-networks can be found in <xref using DetNet MPLS sub-networks can be found in <xref target="RFC8939"
target="I-D.ietf-detnet-ip"/>. DetNet MPLS may use an associated controller format="default"/>. DetNet MPLS may use an associated controller
and Operations, Administration, and Maintenance (OAM) functions and Operations, Administration, and Maintenance (OAM) functions
that are defined outside of this document. that are defined outside of this document.
</t> </t>
<t> <t>
Background information common to all data planes for DetNet Background information common to all data planes for DetNet
can be found in the DetNet Data can be found in the DetNet data plane framework <xref target="RFC8938" forma
Plane Framework <xref target="I-D.ietf-detnet-data-plane-framework"/>. t="default"/>.
</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">
<t> <name>Terms Used in This Document</name>
<t>
This document uses the terminology established in the DetNet This document uses the terminology established in the DetNet
architecture <xref target="RFC8655"/> and architecture <xref target="RFC8655" format="default"/> and
the DetNet Data Plane Framework <xref the DetNet data plane framework <xref target="RFC8938" format="default"/>. Th
target="I-D.ietf-detnet-data-plane-framework"/>. The reader is e reader is
assumed to be familiar with these documents, any terminology assumed to be familiar with these documents, any terminology
defined therein and basic MPLS related terminologies in defined therein, and basic MPLS-related terminologies in
<xref target="RFC3031"/>. <xref target="RFC3031" format="default"/>.
</t> </t>
<t> <t>
The following terminology is introduced in this document: The following terminology is introduced in this document:
<list style="hanging" hangIndent="14"> </t>
<t hangText="F-Label"> <dl newline="false" spacing="normal" indent="14">
A Detnet "forwarding" label that identifies the LSP used to <dt>F-Label</dt>
<dd>
A DetNet "forwarding" label that identifies the Label Switched Path (LSP)
used to
forward a DetNet flow across an MPLS PSN, i.e., a hop-by-hop forward a DetNet flow across an MPLS PSN, i.e., a hop-by-hop
label used between label switching routers (LSR). label used between Label Switching Routers (LSRs).
</t> </dd>
<dt>S-Label</dt>
<t hangText="S-Label"> <dd>
A DetNet "service" label that is used between DetNet nodes that A DetNet "service" label that is used between DetNet nodes that
implement the DetNet service sub-layer functions. An S-Label implement the DetNet service sub-layer functions. An S-Label
is used to identify a DetNet flow at DetNet service is used to identify a DetNet flow at the DetNet service
sub-layer at a receiving DetNet node. sub-layer at a receiving DetNet node.
</t> </dd>
<dt>A-Label</dt>
<t hangText="A-Label"> <dd>
A special case of an S-Label, whose aggregation properties are known only at A special case of an S-Label, whose aggregation properties are known only at
the aggregation and deaggregation end-points. the aggregation and deaggregation end points.
</t> </dd>
<dt>d-CW</dt>
<t hangText="d-CW"> <dd>
A DetNet Control Word (d-CW) is used for sequencing information A DetNet Control Word (d-CW) that is used for sequencing information
of a DetNet flow at the DetNet of a DetNet flow at the DetNet
service sub-layer. service sub-layer.
</t> </dd>
</list> </dl>
</t> </section>
</section> <section numbered="true" toc="default">
<name>Abbreviations</name>
<section title="Abbreviations"> <t>
<t>
The following abbreviations are used in this document: The following abbreviations are used in this document:
<list style="hanging" hangIndent="14"> </t>
<t hangText="CoS">Class of Service.</t> <dl newline="false" spacing="normal" indent="14">
<t hangText="CW">Control Word.</t> <dt>CoS</dt>
<t hangText="DetNet">Deterministic Networking.</t> <dd>Class of Service</dd>
<t hangText="LSR">Label Switching Router.</t> <dt>CW</dt>
<t hangText="MPLS">Multiprotocol Label Switching.</t> <dd>Control Word</dd>
<t hangText="MPLS-TE">Multiprotocol Label Switching - Traffic Engineering.</ <dt>DetNet</dt>
t> <dd>Deterministic Networking</dd>
<t hangText="MPLS-TP">Multiprotocol Label Switching - Transport Profile.</t> <dt>LSR</dt>
<t hangText="OAM">Operations, Administration, and Maintenance.</t> <dd>Label Switching Router</dd>
<t hangText="PE">Provider Edge.</t> <dt>MPLS</dt>
<t hangText="PEF">Packet Elimination Function.</t> <dd>Multiprotocol Label Switching</dd>
<t hangText="PRF">Packet Replication Function.</t> <dt>MPLS-TE</dt>
<t hangText="PREOF">Packet Replication, Elimination and Ordering Functions.< <dd>Multiprotocol Label Switching Traffic Engineering</dd>
/t> <dt>MPLS-TP</dt>
<t hangText="POF">Packet Ordering Function.</t> <dd>Multiprotocol Label Switching Transport Profile</dd>
<t hangText="PSN">Packet Switched Network.</t> <dt>OAM</dt>
<t hangText="PW">PseudoWire.</t> <dd>Operations, Administration, and Maintenance</dd>
<t hangText="QoS">Quality of Service.</t> <dt>PE</dt>
<t hangText="S-PE">Switching Provider Edge.</t> <dd>Provider Edge</dd>
<t hangText="T-PE">Terminating Provider Edge.</t> <dt>PEF</dt>
<t hangText="TSN">Time-Sensitive Network.</t> <dd>Packet Elimination Function</dd>
</list> <dt>PRF</dt>
</t> <dd>Packet Replication Function</dd>
</section> <dt>PREOF</dt>
<dd>Packet Replication, Elimination and Ordering Functions</dd>
<section title="Requirements Language"> <dt>POF</dt>
<t> <dd>Packet Ordering Function</dd>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <dt>PSN</dt>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <dd>Packet Switched Network</dd>
"OPTIONAL" in this document are to be interpreted as described in <dt>PW</dt>
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and <dd>Pseudowire</dd>
only when, they appear in all capitals, as shown here. <dt>QoS</dt>
</t> <dd>Quality of Service</dd>
</section> <dt>S-PE</dt>
</section> <!-- end of terminology --> <dd>Switching Provider Edge</dd>
<dt>T-PE</dt>
<section title="DetNet MPLS Data Plane Overview" anchor="sec_dt_dp"> <dd>Terminating Provider Edge</dd>
<section title="Layers of DetNet Data Plane" anchor="sec_lay_dt_dp"> <dt>TSN</dt>
<t> <dd>Time-Sensitive Networking</dd>
MPLS provides a wide range of capabilities that can be utilised </dl>
by DetNet. A straight forward approach utilizing MPLS for a </section>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
</section>
<section anchor="sec_dt_dp" numbered="true" toc="default">
<name>Overview of the DetNet MPLS Data Plane</name>
<section anchor="sec_lay_dt_dp" numbered="true" toc="default">
<name>Layers of DetNet Data Plane</name>
<t>
MPLS provides a wide range of capabilities that can be utilized
by DetNet. A straight-forward approach utilizing MPLS for a
DetNet service sub-layer is based on the existing pseudowire (PW) DetNet service sub-layer is based on the existing pseudowire (PW)
encapsulations and by utilizing existing MPLS Traffic Engineering encapsulations and utilizes existing MPLS-TE
encapsulations and mechanisms. encapsulations and mechanisms.
Background on PWs can be found in <xref target="RFC3985"/> and <xref Background on PWs can be found in <xref target="RFC3985"
target="RFC3031"/>. Background on MPLS Traffic Engineering can be format="default"/>, <xref target="RFC3032"/>, and <xref target="RFC3031"
found in <xref target="RFC3272"/> and <xref target="RFC3209"/>. format="default"/>.
</t> Background on MPLS-TE can be
<figure anchor="dn_mpls_dp_approach" align="center" found in <xref target="RFC3272" format="default"/> and <xref target="RFC3209
title="DetNet Adaptation to MPLS Data Plane"> " format="default"/>.
<artwork align="center"><![CDATA[ </t>
<figure anchor="dn_mpls_dp_approach">
<name>DetNet Adaptation to MPLS Data Plane</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
DetNet MPLS DetNet MPLS
. .
Bottom of Stack . Bottom of Stack .
(inner label) +------------+ (inner label) +------------+
| Service | d-CW, S-Label (A-Label) | Service | d-CW, S-Label (A-Label)
+------------+ +------------+
| Forwarding | F-Label(s) | Forwarding | F-Label(s)
+------------+ +------------+
Top of Stack . Top of Stack .
(outer label) . (outer label) .
skipping to change at line 260 skipping to change at line 260
DetNet MPLS DetNet MPLS
. .
Bottom of Stack . Bottom of Stack .
(inner label) +------------+ (inner label) +------------+
| Service | d-CW, S-Label (A-Label) | Service | d-CW, S-Label (A-Label)
+------------+ +------------+
| Forwarding | F-Label(s) | Forwarding | F-Label(s)
+------------+ +------------+
Top of Stack . Top of Stack .
(outer label) . (outer label) .
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
<t>
The DetNet MPLS data plane representation is illustrated in The DetNet MPLS data plane representation is illustrated in
<xref target="dn_mpls_dp_approach"/>. <xref target="dn_mpls_dp_approach" format="default"/>.
The service sub-layer includes a DetNet control word (d-CW) and The service sub-layer includes a DetNet Control Word (d-CW) and
an identifying service label (S-Label). The DetNet control word an identifying service label (S-Label). The DetNet Control Word
(d-CW) conforms to the Generic PW MPLS Control Word (PWMCW) (d-CW) conforms to the Generic PW MPLS Control Word (PWMCW)
defined in <xref target="RFC4385"/>. An aggregation label (A-Label) is defined in <xref target="RFC4385" format="default"/>. An aggregation label ( A-Label) is
a special case of S-Label used for aggregation. a special case of S-Label used for aggregation.
</t> </t>
<t>
<t> A node operating on a received DetNet flow at the DetNet service
A node operating on a received DetNet flow at the Detnet service
sub-layer uses the local context associated with a received S-Label, sub-layer uses the local context associated with a received S-Label,
i.e., a received F-Label, to determine which local DetNet i.e., a received F-Label, to determine which local DetNet
operation(s) are applied to that packet. operation(s) are applied to that packet.
An S-Label may be taken from the platform label space An S-Label may be taken from the platform label space
<xref target="RFC3031"/>, making it unique, enabling DetNet <xref target="RFC3031" format="default"/>, making it unique and enabling Det Net
flow identification regardless of which input interface or flow identification regardless of which input interface or
LSP the packet arrives on. It is important to note that S-Label LSP the packet arrives on. It is important to note that S-Label
values are driven by the receiver, not the sender. values are driven by the receiver, not the sender.
</t> </t>
<t>
<t>
The DetNet forwarding sub-layer is supported by zero or more The DetNet forwarding sub-layer is supported by zero or more
forwarding labels (F-Labels). MPLS Traffic Engineering forwarding labels (F-Labels). MPLS-TE
encapsulations and mechanisms can be utilized to provide a encapsulations and mechanisms can be utilized to provide a
forwarding sub-layer that is responsible for providing resource forwarding sub-layer that is responsible for providing resource
allocation and explicit routes. allocation and explicit routes.
</t> </t>
</section>
</section> <section anchor="sec_mpls_dt_dp_scen" numbered="true" toc="default">
<name>DetNet MPLS Data Plane Scenarios</name>
<section title="DetNet MPLS Data Plane Scenarios" <figure anchor="fig_dn_mpls_detnet">
anchor="sec_mpls_dt_dp_scen"> <name>A DetNet MPLS Network</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure align="center" anchor="fig_dn_mpls_detnet"
title="A DetNet MPLS Network">
<artwork><![CDATA[
DetNet MPLS Relay Transit Relay DetNet MPLS DetNet MPLS Relay Transit Relay DetNet MPLS
End System Node Node Node End System End System Node Node Node End System
(T-PE) (S-PE) (LSR) (S-PE) (T-PE) (T-PE) (S-PE) (LSR) (S-PE) (T-PE)
+----------+ +----------+ +----------+ +----------+
| Appl. |<------------ End to End Service ----------->| Appl. | | Appl. |<------------ End-to-End Service ----------->| Appl. |
+----------+ +---------+ +---------+ +----------+ +----------+ +---------+ +---------+ +----------+
| Service |<--| Service |-- DetNet flow --| Service |-->| Service | | Service |<--| Service |-- DetNet flow --| Service |-->| Service |
+----------+ +---------+ +----------+ +---------+ +----------+ +----------+ +---------+ +----------+ +---------+ +----------+
|Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding| |Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding|
+-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+ +-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+
: Link : / ,-----. \ : Link : / ,-----. \ : Link : / ,-----. \ : Link : / ,-----. \
+........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+ +........+ +-[ Sub- ]-+ +......+ +-[ Sub- ]-+
[Network] [Network] [Network] [Network]
`-----' `-----' `-----' `-----'
|<- LSP -->| |<-------- LSP -----------| |<--- LSP -->| |<- LSP -->| |<-------- LSP -----------| |<--- LSP -->|
|<----------------- DetNet MPLS --------------------->| |<----------------- DetNet MPLS --------------------->|
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
<xref target="fig_dn_mpls_detnet"/> illustrates <xref target="fig_dn_mpls_detnet" format="default"/> illustrates
a hypothetical DetNet MPLS-only network a hypothetical DetNet MPLS-only network
composed of DetNet aware MPLS enabled end systems, operating over a composed of DetNet-aware MPLS-enabled end systems operating over a
DetNet aware MPLS network. In this figure, the relay nodes are PE DetNet-aware MPLS network. In this figure, the relay nodes are PE
devices that define the MPLS LSP boundaries and the transit nodes devices that define the MPLS LSP boundaries, and the transit nodes
are LSRs. are LSRs.
</t> </t>
<t> <t>
DetNet end systems and relay nodes understand the particular needs DetNet end systems and relay nodes understand the particular needs
of DetNet flows and provide both DetNet service and forwarding of DetNet flows and provide both DetNet service and forwarding
sub-layer functions. In the case of MPLS, DetNet service-aware nodes ad sub-layer functions. In the case of MPLS, DetNet service-aware nodes ad
d, remove d, remove,
and process d-CWs, S-Labels and F-labels as needed. and process d-CWs, S-Labels, and F-Labels as needed.
DetNet MPLS nodes provide functionality analogous to T-PEs when DetNet MPLS nodes provide functionality analogous to T-PEs when
they sit at the edge of an MPLS domain, and S-PEs when they are they sit at the edge of an MPLS domain and S-PEs when they are
in the middle of an MPLS domain, see <xref in the middle of an MPLS domain; see <xref target="RFC6073" format="defa
target="RFC6073"/>. ult"/>.
</t> </t>
<t> <t>
In a DetNet MPLS network, transit nodes may be DetNet service In a DetNet MPLS network, transit nodes may be DetNet-service-aware or
aware or may be DetNet unaware MPLS Label Switching Routers DetNet-unaware MPLS Label Switching Routers
(LSRs). In this latter case, such LSRs would be unaware of the (LSRs). In this latter case, such LSRs would be unaware of the
special requirements of the DetNet service sub-layer, but would special requirements of the DetNet service sub-layer but would
still provide traffic engineering functions and the QoS still provide traffic engineering functions and the QoS
capabilities needed to ensure that the (TE) LSPs meet the service capabilities needed to ensure that the (TE) LSPs meet the service
requirements of the carried DetNet flows. requirements of the carried DetNet flows.
</t> </t>
<t>
<t> The application of DetNet using MPLS supports a number of
The application of DetNet using MPLS supports a number of control control and management plane types. These types support certain MPLS
plane/management plane types. These types support certain MPLS data data plane deployments. For example, RSVP-TE, MPLS-TP, or MPLS Segment
plane deployments. For example RSVP-TE, MPLS-TP, or MPLS Segment
Routing (when extended to support resource allocation) are all valid Routing (when extended to support resource allocation) are all valid
MPLS deployment cases. MPLS deployment cases.
</t> </t>
<t>
<t> <xref target="fig_pw_detnet" format="default"/> illustrates how an end-t
<xref target="fig_pw_detnet"/> illustrates how an end-to-end MPLS-based o-end MPLS-based
DetNet service is provided in a more detail. In this figure, the DetNet service is provided in more detail.
customer end systems, CE1 and CE2, are able to send and receive MPLS In this figure, the
encapsulated DetNet flows, and R1, R2 and R3 are relay nodes in the Customer Edge (CE1 and CE2) are able to send and receive
middle of a DetNet network. The 'X' in the end systems, and relay MPLS-encapsulated DetNet flows, and R1, R2, and R3 are relay nodes in t
he
middle of a DetNet network. The 'X' in the end systems and relay
nodes represents potential DetNet compound flow packet replication and nodes represents potential DetNet compound flow packet replication and
elimination points. In this example, service protection is supported elimination points. In this example, service protection is supported
utilizing at least two DetNet member flows and TE LSPs. For a utilizing at least two DetNet member flows and TE LSPs. For a
unidirectional flow, R1 supports PRF and R3 supports PEF and POF. Note unidirectional flow, R1 supports PRF, and R3 supports PEF and POF. Note
that the relay nodes may change the underlying forwarding sub-layer, that the relay nodes may change the underlying forwarding sub-layer,
for example tunneling MPLS over IEEE 802.1 TSN <xref for example, tunneling MPLS over IEEE 802.1 TSN <xref
target="I-D.ietf-detnet-mpls-over-tsn"/>, or simply over interconnect target="I-D.ietf-detnet-mpls-over-tsn" format="default"/> or simply
network links. over interconnected network links.
</t> </t>
<figure align="center" anchor="fig_pw_detnet" <figure anchor="fig_pw_detnet">
title="MPLS-Based Native DetNet"> <name>MPLS-Based Native DetNet</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
DetNet DetNet DetNet DetNet
DetNet Service Transit Transit Service DetNet DetNet Service Transit Transit Service DetNet
MPLS | |<-Tnl->| |<-Tnl->| | MPLS MPLS | |<-Tnl->| |<-Tnl->| | MPLS
End | V 1 V V 2 V | End End | V 1 V V 2 V | End
System | +--------+ +--------+ +--------+ | System System | +--------+ +--------+ +--------+ | System
+---+ | | R1 |=======| R2 |=======| R3 | | +---+ +---+ | | R1 |=======| R2 |=======| R3 | | +---+
| X...DFa...|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|.DFa..|.X | | X...DFa...|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|.DFa..|.X |
|CE1|========| \ | | X | | / |======|CE2| |CE1|========| \ | | X | | / |======|CE2|
| | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | | | | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | |
+---+ | |=======| |=======| | +---+ +---+ | |=======| |=======| | +---+
^ +--------+ +--------+ +--------+ ^ ^ +--------+ +--------+ +--------+ ^
| Relay Node Relay Node Relay Node | | Relay Node Relay Node Relay Node |
| (S-PE) (S-PE) (S-PE) | | (S-PE) (S-PE) (S-PE) |
| | | |
|<---------------------- DetNet MPLS --------------------->| |<---------------------- DetNet MPLS --------------------->|
| | | |
|<--------------- End to End DetNet Service -------------->| |<--------------- End-to-End DetNet Service -------------->|
-------------------------- Data Flow -------------------------> -------------------------- Data Flow ------------------------->
X = Optional service protection (none, PRF, PREOF, PEF/POF)
DFx = DetNet member flow x over a TE LSP
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="6">
<dt>X</dt>
<dd>- Optional service protection (none, PRF, PREOF, PEF/POF)</dd>
<dt>DFx</dt>
<dd>- DetNet member flow x over a TE LSP</dd>
</dl>
</section>
</section> </section>
</section> <!-- end of data plane overview --> <section anchor="dn-dt-solution" numbered="true" toc="default">
<name>MPLS-Based DetNet Data Plane Solution</name>
<!-- ================================================================= --> <section anchor="dn-MPLS-en-comps" numbered="true" toc="default">
<!-- =================== MPLS Encap considerations ================ --> <name>DetNet over MPLS Encapsulation Components</name>
<!-- ================================================================= --> <t>
To carry DetNet over MPLS, the following is required:
<section title="MPLS-Based DetNet Data Plane Solution" anchor="dn-dt-solution">
<section title="DetNet Over MPLS Encapsulation Components" anchor="dn-MPLS-en-c </t>
omps"> <ol spacing="normal" type="1">
<t> <li>A method of identifying the MPLS payload type.</li>
To carry DetNet over MPLS the following is required: <li>A method of identifying the DetNet flow(s) to the processing eleme
nt.</li>
<li>A method of distinguishing DetNet OAM packets from DetNet data pac
kets.</li>
<li>A method of carrying the DetNet sequence number.</li>
<li>A suitable LSP to deliver the packet to the egress PE.</li>
<li>A method of carrying queuing and forwarding indication.</li>
</ol>
<list style="numbers"> <t>
<t>A method of identifying the MPLS payload type.</t> In this design, an MPLS service label (the S-Label) is similar to a
<t>A method of identifying the DetNet flow(s) to the processing element.</t> pseudowire (PW) label <xref target="RFC3985" format="default"/> and
<t>A method of distinguishing DetNet OAM packets from DetNet data packets.</t
>
<t>A method of carrying the DetNet sequence number.</t>
<t>A suitable LSP to deliver the packet to the egress PE.</t>
<t>A method of carrying queuing and forwarding indication.</t>
</list>
</t>
<t>
In this design an MPLS service label (the S-Label), is similar to a
pseudowire (PW) label <xref target="RFC3985"/>, and
is used to identify both the is used to identify both the
DetNet flow identity and the payload MPLS payload type satisfying DetNet flow identity and the MPLS payload type satisfying
(1) and (2) in the list above. (1) and (2) in the list above.
OAM traffic discrimination OAM traffic discrimination
happens through the use of the Associated Channel method described in happens through the use of the Associated Channel method described in
<xref target="RFC4385"/>. The DetNet sequence number is carried in <xref target="RFC4385" format="default"/>.
the DetNet Control word which carries the Data/OAM discriminator. To
simplify implementation and to maximize interoperability two sequence
number sizes are supported: a 16 bit sequence number and a 28 bit
sequence number. The 16 bit sequence number is needed to support
some types of legacy clients. The 28 bit sequence number is used in
situations where it is necessary ensure that in high speed networks
the sequence number space does not wrap whilst packets are in flight.
</t>
<t>
The LSP used to forward the DetNet packet is not restricted regarding
any method used for establishing that LSP (for example, MPLS-LDP, MPLS-TE,
MPLS-TP <xref target="RFC5921"/>, MPLS-SR <xref target="RFC8660"/>, etc.).
The LSP (F-Label) label(s)
and/or the S-Label may be used to indicate the required queue processing as
well as the forwarding parameters. Note that the possible use of
Penultimate Hop Popping (PHP) means that the S-Label may be the
only label received at the terminating DetNet service.
</t>
</section>
<section title="MPLS Data Plane Encapsulation" anchor="pwSolution"> The DetNet sequence number is carried in
<t> the DetNet Control Word, which also carries the Data/OAM discriminator. To
<xref target="fig_pw_mpls"/> illustrates a DetNet data plane MPLS simplify implementation and to maximize interoperability, two sequence
number sizes are supported: a 16-bit sequence number and a 28-bit
sequence number. The 16-bit sequence number is needed to support
some types of legacy clients. The 28-bit sequence number is used in
situations where it is necessary to ensure that, in high-speed networks,
the sequence number space does not wrap whilst packets are in flight.
</t>
<t>
The LSP used to forward the DetNet packet is not restricted regarding any
method used for establishing that LSP (for example, MPLS-LDP, MPLS-TE,
MPLS-TP <xref target="RFC5921" format="default"/>, MPLS Segment Routing
<xref target="RFC8660" format="default"/>, etc.). The F-Label(s) and the
S-Label may be used alone or together to indicate the required queue
processing as well as the forwarding parameters. Note that the possible
use of Penultimate Hop Popping (PHP) means that the S-Label may be the only
label received at the terminating DetNet service.
</t>
</section>
<section anchor="pwSolution" numbered="true" toc="default">
<name>MPLS Data Plane Encapsulation</name>
<t>
<xref target="fig_pw_mpls" format="default"/> illustrates a DetNet data plan
e MPLS
encapsulation. The MPLS-based encapsulation of the DetNet flows encapsulation. The MPLS-based encapsulation of the DetNet flows
is well suited for the scenarios described in is well suited for the scenarios described in
<xref target="I-D.ietf-detnet-data-plane-framework"/>. <xref target="RFC8938" format="default"/>.
Furthermore, an end-to-end DetNet Furthermore, an end-to-end DetNet
service i.e., native DetNet deployment (see <xref service, i.e., native DetNet deployment (see <xref
target="sec_mpls_dt_dp_scen"/>) is also possible if DetNet end target="sec_mpls_dt_dp_scen" format="default"/>), is also possible if
systems are capable of initiating and termination MPLS encapsulated DetNet end systems are capable of initiating and terminating
packets. MPLS-encapsulated packets.</t>
</t> <t>The MPLS-based DetNet data plane encapsulation consists of:</t>
<t> <ul spacing="normal">
The MPLS-based DetNet data plane encapsulation consists of:
<list style="symbols">
<t>
DetNet control word (d-CW) containing sequencing information for packet re
plication and
duplicate elimination purposes, and the OAM indicator.</t>
<t>
DetNet service Label (S-Label) that identifies a DetNet flow at
the receiving DetNet service sub-layer processing node.
</t>
<t>
Zero or more Detnet MPLS Forwarding label(s) (F-Label) used to direct the
packet along the label
switched path (LSP) to the next DetNet service sub-layer processing node a
long the path. When Penultimate Hop Popping is in
use there may be no label F-Label in the protocol stack on the final hop.
</t>
<t>
The necessary data-link encapsulation is then applied prior to transmissio
n over the physical
media.
</t>
</list>
</t>
<figure title="Encapsulation of a DetNet App-Flow in an MPLS PSN" anchor="fig_ <li>A DetNet Control Word (d-CW) containing sequencing information for
pw_mpls"> packet replication and duplicate elimination purposes, and the OAM
<artwork align="center"><![CDATA[ indicator.</li>
<li>A DetNet service label (S-Label) that identifies a DetNet flow at
the receiving DetNet service sub-layer processing node.</li>
<li>Zero or more DetNet MPLS forwarding label(s) (F-Label) used to
direct the packet along the Label Switched Path (LSP) to the next
DetNet service sub-layer processing node along the path. When
PHP is in use, there may be no F-Label in the
protocol stack on the final hop.</li>
<li>The necessary data-link encapsulation is then applied prior to
transmission over the physical media.</li>
</ul>
<figure anchor="fig_pw_mpls">
<name>Encapsulation of a DetNet App-Flow in an MPLS PSN</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
DetNet MPLS-based encapsulation DetNet MPLS-based encapsulation
+---------------------------------+ +---------------------------------+
| | | |
| DetNet App-Flow | | DetNet App-Flow |
| Payload Packet | | Payload Packet |
| | | |
+---------------------------------+ <--\ +---------------------------------+ <--\
| DetNet Control Word | | | DetNet Control Word | |
+---------------------------------+ +--> DetNet data plane +---------------------------------+ +--> DetNet data plane
| S-Label | | MPLS encapsulation | S-Label | | MPLS encapsulation
+---------------------------------+ | +---------------------------------+ |
| [ F-Label(s) ] | | | [ F-Label(s) ] | |
+---------------------------------+ <--/ +---------------------------------+ <--/
| Data-Link | | Data-Link |
+---------------------------------+ +---------------------------------+
| Physical | | Physical |
+---------------------------------+ +---------------------------------+
]]> ]]></artwork>
</artwork></figure> </figure>
<section anchor="dn-sn" numbered="true" toc="default">
<section title="DetNet Control Word and the DetNet Sequence Number" <name>DetNet Control Word and DetNet Sequence Number</name>
anchor="dn-sn"> <t>
<t> A DetNet Control Word (d-CW) conforms to the Generic PW MPLS Control
A DetNet control word (d-CW) conforms to the Generic PW MPLS Control Word (PWMCW) defined in <xref target="RFC4385" format="default"/>. The d-CW f
Word (PWMCW) defined in <xref target="RFC4385"/>. The d-CW formatted ormatted
as shown in <xref target="fig_detnet_cw"/> MUST be present in all as shown in <xref target="fig_detnet_cw" format="default"/> <bcp14>MUST</bcp1
DetNet packets containing app-flow data. 4> be present in all
This format of the d-CW was created in order (1) to allow larger sequence num DetNet packets containing App-flow data.
ber This format of the d-CW was created in order to (1) allow larger sequence num
ber
space to avoid sequence number rollover frequency in some applications space to avoid sequence number rollover frequency in some applications
and (2) to allow sequence numbering systems that include the value zero and (2) allow sequence numbering systems that include the value zero
as a valid sequence number, which simplifies implementation. as a valid sequence number, which simplifies implementation.
</t> </t>
<figure title="DetNet Control Word" anchor="fig_detnet_cw"> <figure anchor="fig_detnet_cw">
<artwork align="center"><![CDATA[ <name>DetNet Control Word</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Sequence Number | |0 0 0 0| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> ]]></artwork>
</artwork></figure> </figure>
<dl newline="true" spacing="normal">
<t> <dt>(bits 0 to 3)</dt>
<list style="hanging"> <dd>Per <xref target="RFC4385" format="default"/>,
<t hangText="(bits 0 to 3)"> <bcp14>MUST</bcp14> be set to zero (0).</dd>
<vspace blankLines="1"/> <dt>Sequence Number (bits 4 to 31)</dt>
Per <xref target="RFC4385"/>, MUST be set to zero (0). <dd>An unsigned value implementing the DetNet sequence number. The
</t> sequence number space is a circular one with no restriction on the
<t hangText="Sequence Number (bits 4 to 31)"> initial value.</dd>
<vspace blankLines="1"/> </dl>
An unsigned value implementing the DetNet sequence number. <t>
The sequence number space is a circular one with no A separate sequence number space <bcp14>MUST</bcp14> be maintained by
restriction on initial value. the node that adds the d-CW for each DetNet App-flow, i.e., DetNet service.
</t> The following Sequence Number field lengths <bcp14>MUST</bcp14> be supported:
</list> </t>
</t> <ul spacing="normal">
<t> <li>0 bits</li>
A separate sequence number space MUST be maintained by <li>16 bits</li>
the node that adds the d-CW for each DetNet app-flow, i.e., DetNet service. <li>28 bits</li>
The following sequence number field lengths MUST be supported: </ul>
<list style="bullets"> <t>The sequence number length <bcp14>MUST</bcp14> be provisioned on
<t>0 bits</t> a per-DetNet-service basis via configuration, i.e., via the
<t>16 bits</t> Controller Plane described in <xref target="RFC8938"
<t>28 bits</t> format="default"/>.
</list> </t>
The sequence number length MUST be provisioned on a per <t>
Detnet service basis via A 0-bit Sequence Number field length indicates that there is no
configuration, i.e., via the controller plane described in
<xref target="I-D.ietf-detnet-data-plane-framework"/>.
</t>
<t>
A 0 bit sequence number field length indicates that there is no
DetNet sequence number used for the flow. When the length is zero, DetNet sequence number used for the flow. When the length is zero,
the sequence number field MUST be set to zero (0) on all packets the Sequence Number field <bcp14>MUST</bcp14> be set to zero (0) on all pack ets
sent for the flow. sent for the flow.
</t> </t>
<t>
<t> When the Sequence Number field length is 16 or 28 bits for a flow,
When the sequence number field length is 16 or 28 bits for a flow, the sequence number <bcp14>MUST</bcp14> be incremented by one for each new A
the sequence number MUST be incremented by one for each new app-flow pp-flow
packet sent. When the field length is 16 bits, d-CW bits 4 to 15 packet sent. When the field length is 16 bits, d-CW bits 4 to 15
MUST be set to zero (0). The values carried in this field can wrap <bcp14>MUST</bcp14> be set to zero (0). The values carried in this field can wrap,
and it is important to note that zero (0) is a valid field value. and it is important to note that zero (0) is a valid field value.
For example, where the sequence number size is 16 bits, the sequence For example, where the sequence number size is 16 bits, the sequence
will contain: 65535, 0, 1, where zero (0) is an ordinary will contain: 65535, 0, 1, where zero (0) is an ordinary
sequence number. sequence number.
</t> </t>
<t> <t> It is important to note that this document differs from <xref
It is important to note that this document differs from <xref target="RFC4448" format="default"/>, where a sequence number of zero
target="RFC4448"/> where a sequence number of zero (0) is used to (0) is used to indicate that the sequence number check algorithm is
indicate that the sequence number check algorithm is not used. not used.
</t> </t>
<t> <t>The sequence number is optionally used during receive processing,
The sequence number is optionally used during receive processing as as described below in Sections <xref target="pef-requirements"
described below in <xref target="pef-requirements"/> and <xref format="counter"/> and <xref target="pof-requirements"
target="pof-requirements"/>. format="counter"/>.
</t> </t>
</section> </section>
<section anchor="flow-identification" title="S-Labels"> <section anchor="flow-identification" numbered="true" toc="default">
<t> <name>S-Labels</name>
<t>
A DetNet flow at the DetNet service sub-layer is identified by A DetNet flow at the DetNet service sub-layer is identified by
an S-Label. MPLS-aware DetNet end systems an S-Label. MPLS-aware DetNet end systems
and edge nodes, which are by definition MPLS ingress and egress and edge nodes, which are by definition MPLS ingress and egress
nodes, MUST add (push) and remove (pop) a DetNet service-specific d-CW and S nodes, <bcp14>MUST</bcp14> add (push) and remove (pop) a DetNet
-Label. Relay nodes MAY service-specific d-CW and S-Label. Relay nodes <bcp14>MAY</bcp14>
swap S-Label values when processing a DetNet flow, i.e., incoming and swap S-Label values when processing a DetNet flow, i.e., incoming and
outgoing S-Labels of a DetNet flow can be different. outgoing S-Labels of a DetNet flow can be different.
</t> </t>
<t> <t>
S-Label values MUST be provisioned per DetNet service via S-Label values <bcp14>MUST</bcp14> be provisioned per DetNet service via
configuration, i.e., via configuration, i.e., via
the controller plane described in the Controller Plane described in
<xref target="I-D.ietf-detnet-data-plane-framework"/>. <xref target="RFC8938" format="default"/>.
Note that S-Labels provide identification at the downstream Note that S-Labels provide identification at the downstream
DetNet service sub-layer receiver, not the sender. As such, DetNet service sub-layer receiver, not the sender. As such,
S-Labels MUST be allocated by the entity that controls the service S-Labels <bcp14>MUST</bcp14> be allocated by the entity that controls the se
sub-layer receiving node's label space, and MAY be allocated from rvice
the platform label space <xref target="RFC3031"/>. sub-layer receiving a node's label space and <bcp14>MAY</bcp14> be allocated
Because S-Labels are local to each node rather than being a from
the platform label space <xref target="RFC3031" format="default"/>.
Because S-Labels are local to each node, rather than being a
global identifier within a domain, they must be advertised to their global identifier within a domain, they must be advertised to their
upstream DetNet service-aware peer nodes (i.e., a DetNet MPLS End upstream DetNet service-aware peer nodes (i.e., a DetNet MPLS end
System or a DetNet Relay or Edge Node) and interpreted in the system or a DetNet relay or edge node) and interpreted in the
context of their received F-Label(s). context of their received F-Label(s).
In some PREOF topologies, the node performing replication will be In some PREOF topologies, the node performing replication will be
sending to multiple nodes performing PEF or POF, and may need to sending to multiple nodes performing PEF or POF and may need to
send different S-Label values for the different member flows for the send different S-Label values for the different member flows for the
same DetNet service. same DetNet service.
</t> </t>
<t> <t>
An S-Label will normally be at the bottom of the label stack once An S-Label will normally be at the bottom of the label stack once
the last F-Label is removed, immediately preceding the d-CW. the last F-Label is removed, immediately preceding the d-CW.
To support service sub-layer level OAM, an OAM Associated Channel To support OAM at the service sub-layer level, an OAM Associated Channel
Header (ACH) <xref target="RFC4385"/> Header (ACH) <xref target="RFC4385" format="default"/>
together with a Generic Associated Channel Label (GAL) <xref together with a Generic Associated Channel Label (GAL) <xref
target="RFC5586"/> MAY be used in place of a d-CW. target="RFC5586" format="default"/> <bcp14>MAY</bcp14> be used in place of
</t> a d-CW.
<t> </t>
Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) <xref <t>
target="RFC6790"/> MAY be carried below the S-Label in the label stack in Similarly, an Entropy Label Indicator (ELI) and Entropy Label (EL) <xref
target="RFC6790" format="default"/> <bcp14>MAY</bcp14> be carried below
the S-Label in the label stack in
networks where DetNet flows would otherwise receive ECMP treatment. When networks where DetNet flows would otherwise receive ECMP treatment. When
ELs are used, the same EL value SHOULD be used for all of the packets ELs are used, the same EL value <bcp14>SHOULD</bcp14> be used for all of the packets
sent using a specific S-Label to force the flow to follow the same path. sent using a specific S-Label to force the flow to follow the same path.
However, as outlined in <xref However, as outlined in <xref target="RFC8938" format="default"/>, the use o
target="I-D.ietf-detnet-data-plane-framework"/> the use of ECMP for DetNet f ECMP for DetNet
flows is NOT RECOMMENDED. ECMP MAY be used for non-DetNet flows within a flows is <bcp14>NOT RECOMMENDED</bcp14>. ECMP <bcp14>MAY</bcp14> be used for
non-DetNet flows within a
DetNet domain. DetNet domain.
</t> </t>
<t> <t>
When receiving a DetNet MPLS packet, an implementation MUST identify When receiving a DetNet MPLS packet, an implementation <bcp14>MUST</bcp14>
identify
the DetNet service associated with the incoming packet based on the the DetNet service associated with the incoming packet based on the
S-Label. When a node is using platform labels for S-Labels, no S-Label. When a node is using platform labels for S-Labels, no
additional information is needed as the S-label uniquely identifies additional information is needed, as the S-Label uniquely identifies
the DetNet service. In the case where platform labels are not used, zero the DetNet service. In the case where platform labels are not used, zero
or more F-Labels proceeding the S-Label MUST be used together with or more F-Labels proceeding the S-Label <bcp14>MUST</bcp14> be used togethe r with
the S-Label to uniquely identify the DetNet service associated with a the S-Label to uniquely identify the DetNet service associated with a
received packet. received packet.
The incoming interface MAY also be used together with The incoming interface <bcp14>MAY</bcp14> also be used together with
any present F-Label(s) and the S-Label to uniquely identify an any present F-Label(s) and the S-Label to uniquely identify an
incoming DetNet service, for example, in the case where PHP is used. Note incoming DetNet service, for example, in the case where PHP is used.
that choice to use platform label space Note that the choice to use the platform label space
for S-Label or S-Label plus one or more F-Labels to identify for an S-Label or an S-Label plus one or more F-Labels to identify
DetNet services is a local implementation choice, with one caveat. When on e DetNet services is a local implementation choice, with one caveat. When on e
or more F-labels, or incoming interface, is needed together with an or more F-Labels, or the incoming interface, is needed together with an
S-Label to uniquely identify a service, the controller plane must ensure th S-Label to uniquely identify a service, the Controller Plane must ensure th
at at
incoming DetNet MPLS packets arrive with the needed information incoming DetNet MPLS packets arrive with the needed information
(F-label(s) and/or incoming interface) and provision the needed (F-Label(s) and/or the incoming interface) and provision the needed
information. The provisioned information MUST then be used to information. The provisioned information <bcp14>MUST</bcp14> then be used t
o
identify incoming DetNet service based on the combination of S-Label identify incoming DetNet service based on the combination of S-Label
and F-Label(s) or incoming interface. and F-Label(s) or the incoming interface.
</t> </t>
<t> <t>
The use of platform labels for S-Labels matches other pseudowire The use of platform labels for S-Labels matches other pseudowire
encapsulations for consistency but there is no hard requirement in encapsulations for consistency, but there is no hard requirement in
this regard. this regard.
</t> </t>
<t> <t>Implementation details of PREOF are out of scope for
Implementation details of PREOF functions are out of scope for this documen this document. <xref target="IEEE802.1CB-2017" format="default"/>
t. defines equivalent replication and elimination-specific aspects,
<xref target="IEEE802.1CB-2017"/> defines equivalent replication and elimin which can be applied to PRF and PEF.</t>
ation <section anchor="prf-requirements" numbered="true" toc="default">
specific aspects, which can be applied to PRF and PEF. <name>Packet Replication Function Processing</name>
</t> <t>
The Packet Replication Function (PRF) <bcp14>MAY</bcp14> be supported
<section anchor="prf-requirements" title="Packet Replication Function
Processing">
<t>
The Packet Replication Function (PRF) function MAY be supported
by an implementation for outgoing DetNet flows. The use of the PRF by an implementation for outgoing DetNet flows. The use of the PRF
for a particular DetNet service MUST be provisioned via configuration, for a particular DetNet service <bcp14>MUST</bcp14> be provisioned via co
i.e., via the controller plane described in nfiguration,
<xref target="I-D.ietf-detnet-data-plane-framework"/>. When replication i.e., via the Controller Plane described in
is configured, the same app-flow data will be sent over multiple <xref target="RFC8938" format="default"/>. When replication
is configured, the same App-flow data will be sent over multiple
outgoing DetNet member flows using forwarding sub-layer LSPs. outgoing DetNet member flows using forwarding sub-layer LSPs.
An S-Label value MUST be configured per outgoing member flow. An S-Label value <bcp14>MUST</bcp14> be configured per outgoing member fl
The same d-CW field value MUST be used on all outgoing member flows for ow.
The same d-CW field value <bcp14>MUST</bcp14> be used on all outgoing mem
ber flows for
each replicated MPLS packet. each replicated MPLS packet.
<!-- PRF MUST NOT be used with DetNet services configured </t>
with a d-CW sequence number field length of 0 bits. </section>
[Note: What if multiple receivers? We may use the PRF for serving multipl <section anchor="pef-requirements" numbered="true" toc="default">
e end-points.] --> <name>Packet Elimination Function Processing</name>
</t> <t>
</section> Implementations <bcp14>MAY</bcp14> support the Packet Elimination Functio
<section anchor="pef-requirements" title="Packet Elimination Function n (PEF)
Processing">
<t>
Implementations MAY support the Packet Elimination Function (PEF)
for received DetNet MPLS flows. When supported, use of the PEF for received DetNet MPLS flows. When supported, use of the PEF
for a particular DetNet service MUST be provisioned via configuration, for a particular DetNet service <bcp14>MUST</bcp14> be provisioned via co
i.e., via the controller plane described in nfiguration,
<xref target="I-D.ietf-detnet-data-plane-framework"/>. i.e., via the Controller Plane described in
</t> <xref target="RFC8938" format="default"/>.
<t> </t>
<t>
After a DetNet service is identified for a received DetNet MPLS packet , After a DetNet service is identified for a received DetNet MPLS packet ,
as described above, if PEF is configured for that DetNet service, as described above, if PEF is configured for that DetNet service,
duplicate (replicated) instances of a particular sequence number MUST be duplicate (replicated) instances of a particular sequence number <bcp1 4>MUST</bcp14> be
discarded. discarded.
The specific mechanisms used for an implementation to identify which The specific mechanisms used for an implementation to identify which
received packets are duplicates and which are new is an received packets are duplicates and which are new is an
implementation choice. Note that per <xref target="dn-sn"/> implementation choice. Note that, per <xref target="dn-sn" format="defa
the sequence number field length may be 16 or 28 bits, and the ult"/>,
field value can wrap. PEF MUST NOT be used with DetNet flows configured the Sequence Number field length may be 16 or 28 bits, and the
with a d-CW sequence number field length of 0 bits. field value can wrap. PEF <bcp14>MUST NOT</bcp14> be used with DetNet flo
</t> ws configured
<t> with a d-CW Sequence Number field length of 0 bits.
An implementation MAY constrain the maximum number of sequence numbers </t>
that are tracked on either a platform-wide or per flow basis. <t>
Some implementations MAY support the provisioning of An implementation <bcp14>MAY</bcp14> constrain the maximum number of s
equence numbers
that are tracked on either a platform-wide or per-flow basis.
Some implementations <bcp14>MAY</bcp14> support the provisioning of
the maximum number of sequence numbers that are tracked on the maximum number of sequence numbers that are tracked on
either a platform-wide or per flow basis. either a platform-wide or per-flow basis.
</t> </t>
</section> </section>
<section anchor="pof-requirements" title="Packet Ordering Function <section anchor="pof-requirements" numbered="true" toc="default">
Processing"> <name>Packet Ordering Function Processing</name>
<t> <t>
A function that is related to in-order delivery is the Packet Ordering Fu nction A function that is related to in-order delivery is the Packet Ordering Fu nction
(POF). Implementations MAY support POF. When (POF). Implementations <bcp14>MAY</bcp14> support POF. When
supported, use of the POF for a particular DetNet service MUST be supported, use of the POF for a particular DetNet service <bcp14>MUST</bc
provisioned via configuration, i.e., via the controller plane p14> be
provisioned via configuration, i.e., via the Controller Plane
described by described by
<xref target="I-D.ietf-detnet-data-plane-framework"/>. <xref target="RFC8938" format="default"/>.
Implementations MAY require that PEF and POF be used in combination. Implementations <bcp14>MAY</bcp14> require that PEF and POF be used in co
There is no requirement related to the order of execution of the Packet mbination.
Elimination and Ordering Functions in an implementation. There is no requirement related to the order of execution of the PEF and
</t> POF in an implementation.
<t> </t>
After a DetNet service is identified for a received DetNet MPLS packet <t>
, After a DetNet service is identified for a received DetNet MPLS
as described above, if POF is configured for that DetNet service, pack packet, as described above, if POF is configured for that DetNet
ets service, packets <bcp14>MUST</bcp14> be processed in the order
MUST be processed in the order indicated in the received d-CW sequence indicated in the received d-CW Sequence Number field, which may not
number field, which may not be in the order the packets are received. be in the order the packets are received.
As defined in As defined in <xref
<xref target="dn-sn"/> the sequence number field length may be 16 target="dn-sn" format="default"/>, the Sequence Number field length
or 28 bits, is incremented by one (1) for each new MPLS packet may be 16 or 28 bits, the sequence number is incremented by one (1) fo
sent for a particular DetNet service, and the field value can wrap. The r each new
specific mechanisms used MPLS packet sent for a particular DetNet service, and the field
for an implementation to identify the order of received packets value can wrap. The specific mechanisms used for an implementation
is an implementation choice. to identify the order of received packets is an implementation
</t> choice.
<t> </t>
An implementation MAY constrain the maximum number of out of order <t>
packets that can be processed, on either a platform-wide or per flow An implementation <bcp14>MAY</bcp14> constrain the maximum number of out-
basis. The number of out of order packets that can be processed also of-order
packets that can be processed on either a platform-wide or per-flow
basis. The number of out-of-order packets that can be processed also
impacts the latency of a flow. impacts the latency of a flow.
</t> </t>
<t> <t>
The latency impact on the system resources needed to support a The latency impact on the system resources needed to support a
specific DetNet flow will need to be evaluated by the controller plane specific DetNet flow will need to be evaluated by the Controller Plane
based on that flow's traffic specification. An example traffic based on that flow's traffic specification. An example traffic
specification that can be used with MPLS with Traffic Engineering specification that can be used with
(MPLS-TE) can be found in <xref target="RFC2212"/>. MPLS-TE can be found in <xref target="RFC2212" format="default"/>.
</t> </t>
<t> <t>
DetNet implementations can use flow-specific requirements (e.g., maximum DetNet implementations can use flow-specific requirements (e.g., maximum
number of out-of-order packets, maximum latency of the flow) for number of out-of-order packets and maximum latency of the flow) for
configuration of POF-related buffers. POF implementation details configuration of POF-related buffers. POF implementation details
are out-of-scope for this document and POF configuration paramete rs are out of scope for this document, and POF configuration paramet ers
are implementation specific. The Controller Plane identifies and are implementation specific. The Controller Plane identifies and
sets the POF configuration parameters. sets the POF configuration parameters.
</t> </t>
</section> </section>
</section> </section>
<section anchor="f-labels" title="F-Labels"> <section anchor="f-labels" numbered="true" toc="default">
<t> <name>F-Labels</name>
<t>
F-Labels support the DetNet forwarding sub-layer. F-Labels F-Labels support the DetNet forwarding sub-layer. F-Labels
are used to provide LSP-based connectivity between DetNet service are used to provide LSP-based connectivity between DetNet service
sub-layer processing nodes. sub-layer processing nodes.
</t> </t>
<section anchor="f-labels-ssl" <section anchor="f-labels-ssl" numbered="true" toc="default">
title="Service Sub-Layer Related Processing"> <name>Service Sub-Layer-Related Processing</name>
<t>
<t> DetNet MPLS end systems, edge nodes, and relay nodes may operate at
DetNet MPLS end systems, edge nodes and relay nodes may operate at
the DetNet service sub-layer with understanding of DetNet services and their the DetNet service sub-layer with understanding of DetNet services and their
requirements. As mentioned earlier, when operating at this layer requirements. As mentioned earlier, when operating at this layer,
such nodes can push, pop or swap (pop then push) S-Labels. In all such nodes can push, pop, or swap (pop then push) S-Labels. In all
cases, the F-Label(s) used for a DetNet service are always replaced an cases, the F-Label(s) used for a DetNet service are always replaced, a
d nd
the following procedures apply. the following procedures apply.
</t> </t>
<t> <t>
When sending a DetNet flow, zero or more F-Labels MAY be pushed When sending a DetNet flow, zero or more F-Labels <bcp14>MAY</bcp14> be
pushed
on top of an S-Label by the node pushing an S-Label. The on top of an S-Label by the node pushing an S-Label. The
F-Label(s) to be pushed when sending a particular DetNet service MUST F-Label(s) to be pushed when sending a particular DetNet service <bcp14 >MUST</bcp14>
be provisioned per outgoing S-Label via configuration, i.e., via the be provisioned per outgoing S-Label via configuration, i.e., via the
controller plane discussed in Controller Plane discussed in <xref target="RFC8938" format="default"/>
<xref target="I-D.ietf-detnet-data-plane-framework"/>. .
F-Label(s) can also provide context for an S-Label. F-Label(s) can also provide context for an S-Label. To
To allow for the omission of F-Label(s), an implementation <bcp14>SHOULD</
allow for the omission of F-Label(s), an implementation SHOULD bcp14>
also allow an outgoing interface to be configured per S-Label. also allow an outgoing interface to be configured per S-Label.
</t> </t>
<t> <t>
Note, when PRF Note that when PRF
is supported, the same app-flow data will be sent over multiple is supported, the same App-flow data will be sent over multiple
outgoing DetNet member flows using forwarding sub-layer outgoing DetNet member flows using forwarding sub-layer
LSPs. This means that LSPs. This means that an
implementation may be sending different sets of implementation may be sending different sets of
F-Labels per DetNet member flow, each with a different S-Label. F-Labels per DetNet member flow, each with a different S-Label.
</t> </t>
<t> <t>
When a single set of F-Labels is provisioned for a particular When a single set of F-Labels is provisioned for a particular
outgoing S-Label, that set of F-labels MUST be pushed after outgoing S-Label, that set of F-Labels <bcp14>MUST</bcp14> be pushed afte r
the S-Label is pushed. the S-Label is pushed.
The outgoing packet is then forwarded as The outgoing packet is then forwarded, as
described below in <xref target="f-labels-all"/>. When a single described below in <xref target="f-labels-all" format="default"/>. When a
single
outgoing interface is provisioned, the outgoing packet is then outgoing interface is provisioned, the outgoing packet is then
forwarded as described below in <xref target="f-labels-all"/>. forwarded, as described below in <xref target="f-labels-all" format="defa
</t> ult"/>.
<t> </t>
<t>
When multiple sets of outgoing F-Labels or interfaces are provisioned for When multiple sets of outgoing F-Labels or interfaces are provisioned for
a particular DetNet service (i.e., for PRF), a copy of the outgoing packe t, including a particular DetNet service (i.e., for PRF), a copy of the outgoing packe t, including
the pushed member flow-specific S-Label, MUST be made per F-label set and outgoing the pushed member flow-specific S-Label, <bcp14>MUST</bcp14> be made per F-Label set and outgoing
interface. Each set of provisioned F-Labels are then pushed onto interface. Each set of provisioned F-Labels are then pushed onto
a copy of the packet. Each copy is then forwarded as described a copy of the packet. Each copy is then forwarded, as described
below in <xref target="f-labels-all"/>. below in <xref target="f-labels-all" format="default"/>.
</t> </t>
<t> <t>
As described in the previous section, when receiving a DetNet MPLS flow, an implementation As described in the previous section, when receiving a DetNet MPLS flow, an implementation
identifies the DetNet service associated with the incoming packet based identifies the DetNet service associated with the incoming packet based
on the S-Label. When a node is using platform labels for on the S-Label. When a node is using platform labels for
S-Labels, any F-Labels can be popped and the S-label uniquely S-Labels, any F-Labels can be popped, and the S-Label uniquely
identifies the DetNet service. In the case where platform labels are identifies the DetNet service. In the case where platform labels are
not used, incoming F-Label(s) and, optionally, the incoming interface MUS T also be provisioned for a not used, incoming F-Label(s) and, optionally, the incoming interface <bc p14>MUST</bcp14> also be provisioned for a
DetNet service. DetNet service.
</t> </t>
</section> </section>
<section anchor="f-labels-all" <section anchor="f-labels-all" numbered="true" toc="default">
title="Common F-Label Processing"> <name>Common F-Label Processing</name>
<t> <t>
All DetNet aware MPLS nodes process F-Labels as needed to meet All DetNet-aware MPLS nodes process F-Labels as needed to meet
the service requirements of the DetNet flow or flows carried in the service requirements of the DetNet flow or flows carried in
the LSPs represented by the F-Labels. This includes normal the LSPs represented by the F-Labels. This includes normal
push, pop and swap operations. Such processing is essentially push, pop, and swap operations. Such processing is essentially
the same type of processing provided for TE LSPs, although the the same type of processing provided for TE LSPs, although the
specific service parameters, or traffic specification, can specific service parameters, or traffic specification, can
differ. When the DetNet service parameters of the DetNet flow or differ. When the DetNet service parameters of the DetNet flow or
flows carried in an LSP represented by an F-Label can be met by flows carried in an LSP represented by an F-Label can be met by
an existing TE mechanism, the forwarding sub-layer processing an existing TE mechanism, the forwarding sub-layer processing
node MAY be a DetNet unaware, i.e., standard, MPLS LSR. Such node <bcp14>MAY</bcp14> be a DetNet-unaware, i.e., standard, MPLS LSR. Such
TE LSPs may provide LSP forwarding service as defined in, but TE LSPs may provide LSP forwarding service as defined in, but
not limited to, <xref target="RFC3209"/>, <xref not limited, to the following: <xref target="RFC3209" format="default"/
target="RFC3270"/>, <xref target="RFC3272"/>, <xref >, <xref
target="RFC3473"/>, <xref target="RFC4875"/>, <xref target="RFC3270" format="default"/>, <xref target="RFC3272"
target="RFC5440"/>, and <xref target="RFC8306"/>. format="default"/>, <xref target="RFC3473" format="default"/>, <xref
</t> target="RFC4875" format="default"/>, <xref target="RFC5440"
<t> format="default"/>, and <xref target="RFC8306" format="default"/>.
</t>
<t>
More specifically, as mentioned above, the DetNet forwarding More specifically, as mentioned above, the DetNet forwarding
sub-layer provides explicit routes and allocated resources, and sub-layer provides explicit routes and allocated resources, and
F-Labels are used to map to each. Explicit routes are F-Labels are used to map to each. Explicit routes are
supported based on the topmost (outermost) F-Label that is supported based on the topmost (outermost) F-Label that is
pushed or swapped and the LSP that corresponds to this label. pushed or swapped and the LSP that corresponds to this label.
This topmost (outgoing) label MUST be associated with a This topmost (outgoing) label <bcp14>MUST</bcp14> be associated with a
provisioned outgoing interface and, for non-point-to-point provisioned outgoing interface and, for non-point-to-point
outgoing interfaces, a next hop LSR. Note that this outgoing interfaces, a next-hop LSR. Note that this
information MUST be provisioned via configuration or the information <bcp14>MUST</bcp14> be provisioned via configuration or the
controller plane. In the previously mentioned special case Controller Plane. In the previously mentioned special case
where there are no added F-labels and the outgoing interface is where there are no added F-Labels and the outgoing interface is
not a point-to-point interface, the outgoing interface MUST not a point-to-point interface, the outgoing interface <bcp14>MUST</bcp
also be associated with a next hop LSR. 14>
</t> also be associated with a next-hop LSR.
<t> </t>
Resources may be allocated in a hierarchical fashion per LSP <t>
that is represented by each F-Label. Each LSP MAY be Resources may be allocated in a hierarchical fashion per each LSP
that is represented by each F-Label. Each LSP <bcp14>MAY</bcp14> be
provisioned with a service parameter that dictates the provisioned with a service parameter that dictates the
specific traffic treatment to be received by the traffic specific traffic treatment to be received by the traffic
carried over that LSP. Implementations of this document MUST carried over that LSP. Implementations of this document <bcp14>MUST</b cp14>
ensure that traffic carried over each LSP represented by one or more ensure that traffic carried over each LSP represented by one or more
F-Labels receives the traffic treatment provisioned for that F-Labels receives the traffic treatment provisioned for that
LSP. Typical mechanisms used to provide different treatment to LSP. Typical mechanisms used to provide different treatment to
different flows includes the allocation of system resources different flows include the allocation of system resources
(such as queues and buffers) and provisioning of related (such as queues and buffers) and provisioning of related
parameters (such as shaping, and policing) that may be found in parameters (such as shaping and policing) that may be found in
implementations of <xref target="RFC2205">Resource ReSerVation Protocol implementations of the Resource ReSerVation Protocol (RSVP) <xref
(RSVP)</xref> (RSVP) and RSVP-TE <xref target="RFC3209"/> and target="RFC2205" format="default"/> and RSVP-TE <xref
<xref target="RFC3473"/>. Support can also be target="RFC3209" format="default"/>
provided via an underlying network technology such IEEE802.1 <xref target="RFC3473" format="default"/>. Support can also be
TSN <xref target="I-D.ietf-detnet-mpls-over-tsn"/>. provided via an underlying network technology, such as IEEE 802.1
TSN <xref target="I-D.ietf-detnet-mpls-over-tsn" format="default"/>.
The specific mechanisms selected by a DetNet node to ensure DetNet The specific mechanisms selected by a DetNet node to ensure DetNet
service delivery requirements are met for supported DetNet service delivery requirements are met for supported DetNet
flows is outside the scope of this document. flows is outside the scope of this document.
</t> </t>
<t> <t>
Packets that are marked in a way that do not correspond to Packets that are marked in a way that do not correspond to
allocated resources, e.g., lack a provisioned F-Label, can allocated resources, e.g., lack a provisioned F-Label, can
disrupt the QoS offered to properly reserved DetNet flows by disrupt the QoS offered to properly reserved DetNet flows by
using resources allocated to the reserved flows. Therefore, using resources allocated to the reserved flows. Therefore,
the network nodes of a DetNet network: the network nodes of a DetNet network:
<list style="symbols"> </t>
<t> <ul spacing="normal">
MUST defend the DetNet QoS by discarding or remarking (to <li>
an allocated DetNet flow or non-competing non-DetNet flow) <bcp14>MUST</bcp14> defend the DetNet QoS by discarding or remarkin
g (to
an allocated DetNet flow or noncompeting non-DetNet flow)
packets received that are not associated with a completed packets received that are not associated with a completed
resource allocation. resource allocation.
</t> </li>
<t> <li>
MUST NOT use a DetNet allocated resource, e.g. a queue or <bcp14>MUST NOT</bcp14> use a DetNet allocated resource, e.g., a qu
eue or
shaper reserved for DetNet flows, for any packet that does shaper reserved for DetNet flows, for any packet that does
match the corresponding DetNet flow. match the corresponding DetNet flow.
</t> </li>
<t> <li>
MUST ensure a QoS flow does not exceed its allocated <bcp14>MUST</bcp14> ensure a QoS flow does not exceed its allocated
resources or provisioned service level, resources or provisioned service level.
</t> </li>
<t> <li>
MUST ensure a CoS flow or service class does not impact the <bcp14>MUST</bcp14> ensure a CoS flow or service class does not imp
act the
service delivered to other flows. This requirement is service delivered to other flows. This requirement is
similar to the requirement for MPLS LSRs that CoS LSPs do similar to the requirement for MPLS LSRs that CoS LSPs do
not impact the resources allocated to TE LSPs, e.g., via not impact the resources allocated to TE LSPs, e.g., via
<xref target="RFC3473"/>. <xref target="RFC3473" format="default"/>.
</t> </li>
</list> </ul>
</t> <t>
<t>
Subsequent sections provide additional considerations related Subsequent sections provide additional considerations related
to CoS (<xref target="CoS"/>), QoS (<xref target="QoS"/>) and to CoS (<xref target="CoS" format="default"/>), QoS (<xref target="QoS"
aggregation (<xref target="FAG"/>). format="default"/>), and
</t> aggregation (<xref target="FAG" format="default"/>).
</section> </t>
</section> </section>
</section>
</section> </section>
<section anchor="oam-indication" numbered="true" toc="default">
<name>OAM Indication</name>
<section anchor="oam-indication" title="OAM Indication">
<!-- LB: why only type 1, if keep it, need conformance language -->
<t> <t>
OAM follows the procedures set out in <xref target="RFC5085"/> with the OAM follows the procedures set out in <xref target="RFC5085" format="default "/> with the
restriction that only Virtual Circuit Connectivity Verification restriction that only Virtual Circuit Connectivity Verification
(VCCV) type 1 is supported.</t> (VCCV) type 1 is supported.</t>
<t>As shown in Figure 3 of <xref target="RFC5085" format="default"/>, wh
<t>As shown in Figure 3 of <xref target="RFC5085"/> when the first nibble of en the first nibble of
the d-CW is 0x0 the payload following the d-CW is normal user the d-CW is 0x0, the payload following the d-CW is normal user
data. However, when the first nibble of the d-CW is 0x1, the data. However, when the first nibble of the d-CW is 0x1, the
payload that follows the d-CW is an OAM payload with the OAM payload that follows the d-CW is an OAM payload with the OAM
type indicated by the value in the d-CW Channel Type field.</t> type indicated by the value in the d-CW Channel Type field.</t>
<t>The reader is referred to <xref target="RFC5085"/> for a more detailed <t>The reader is referred to <xref target="RFC5085" format="default"/> f
description of the Associated Channel mechanism, and to the or a more detailed
DetNet work on OAM for more information DetNet OAM. description of the Associated Channel mechanism and to the
</t> DetNet work on OAM <xref target="I-D.ietf-detnet-mpls-oam" format="default"/
<t> Additional considerations on DetNet-specific OAM are subjects > for more information about DetNet OAM.
</t>
<t> Additional considerations on DetNet-specific OAM are subjects
for further study. for further study.
</t> </t>
</section> </section>
<section anchor="FAG" numbered="true" toc="default">
<section anchor="FAG" title="Flow Aggregation"> <name>Flow Aggregation</name>
<t> <t>
The ability to aggregate individual flows, and their associated The ability to aggregate individual flows and their associated
resource control, into a larger aggregate is an important technique resource control into a larger aggregate is an important technique
for improving scaling of control in the data, management and control for improving scaling of control in the data, management, and control
planes. The DetNet data plane allows for the aggregation of DetNet flows, planes. The DetNet data plane allows for the aggregation of DetNet flows
to improved scaling. There are two methods of supporting flow to improved scaling. There are two methods of supporting flow
aggregation covered in this section. aggregation covered in this section.
</t> </t>
<t> <t>
The resource control and management aspects of aggregation The resource control and management aspects of aggregation
(including the configuration of queuing, shaping, and policing) are (including the configuration of queuing, shaping, and policing) are
the responsibility of the DetNet controller plane and is out of scope of thi the responsibility of the DetNet Controller Plane and are out of scope for t
s his
documents. It is also the responsibility of the controller document. It is also the responsibility of the Controller
plane to ensure that consistent aggregation methods are used. Plane to ensure that consistent aggregation methods are used.
</t> </t>
<section anchor="aggregation-at-the-lsp" title="Aggregation Via LSP Hierarchy <section anchor="aggregation-at-the-lsp" numbered="true" toc="default">
"> <name>Aggregation via LSP Hierarchy</name>
<t> <t>
DetNet flows forwarded via MPLS can leverage MPLS-TE's existing DetNet flows forwarded via MPLS can leverage MPLS-TE's existing
support for hierarchical LSPs (H-LSPs), see <xref target="RFC4206"/>. H-LS support for hierarchical LSPs (H-LSPs); see <xref target="RFC4206" format="
Ps are default"/>. H-LSPs are
typically used to aggregate control and resources, they may also be typically used to aggregate control and resources; they may also be
used to provide OAM or protection for the aggregated LSPs. Arbitrary used to provide OAM or protection for the aggregated LSPs. Arbitrary
levels of aggregation naturally falls out of the definition for levels of aggregation naturally fall out of the definition for
hierarchy and the MPLS label stack <xref target="RFC3032"/>. DetNet nodes hierarchy and the MPLS label stack <xref target="RFC3032" format="default"/
which >. DetNet nodes that
support aggregation (LSP hierarchy) map one or more LSPs (labels) support aggregation (LSP hierarchy) map one or more LSPs (labels)
into and from an H-LSP. Both carried LSPs and H-LSPs may or may not into and from an H-LSP.
use the TC field, i.e., L-LSPs or E-LSPs <xref target="RFC3270"/>. Such no Both carried LSPs and H-LSPs may or may not
des will need to use the Traffic Class (TC) field, i.e., L-LSPs (Label-Only-Inferred-PSC LSP
s)
or E-LSPs (EXP-Inferred-PSC LSPs <xref
target="RFC3270" format="default"/>, which were renamed to "Explicitly TC-e
ncoded-PSC LSPs" in <xref target="RFC5462" format="default" sectionFormat="of" s
ection="2.2"/>). Such nodes will need to
ensure that individual LSPs and H-LSPs receive the traffic ensure that individual LSPs and H-LSPs receive the traffic
treatment required to ensure the required treatment required to ensure the required
DetNet service is preserved. DetNet service is preserved.
</t> </t>
<t> <t>
Additional details of the traffic control capabilities needed at a Additional details of the traffic control capabilities needed at a
DetNet-aware node may be covered in the new service definitions DetNet-aware node may be covered in the new service definitions
mentioned above or in separate future documents. Controller plane mentioned above or in separate future documents. Controller Plane
mechanisms will also need to ensure that the service required on mechanisms will also need to ensure that the service required on
the aggregate flow are provided, which may include the discarding the aggregate flow are provided, which may include the discarding
or remarking mentioned in the previous sections. or remarking mentioned in the previous sections.
</t> </t>
</section> </section>
<section anchor="aggregating-detnet-flows-as-a-new-detnet-flow" <section anchor="aggregating-detnet-flows-as-a-new-detnet-flow" numbered
title="Aggregating DetNet Flows as a new DetNet flow"> ="true" toc="default">
<t> <name>Aggregating DetNet Flows as a New DetNet Flow</name>
<t>
An aggregate can be built by layering DetNet flows, including both An aggregate can be built by layering DetNet flows, including both
their S-Label and, when present, F-Labels as shown below: their S-Label and (when present) F-Labels, as shown below:
</t> </t>
<figure title="DetNet Aggregation as a new DetNet Flow" anchor="fig_detnet_a <figure anchor="fig_detnet_agg_flow">
gg_flow"> <name>DetNet Aggregation as a New DetNet Flow</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
+---------------------------------+ +---------------------------------+
| | | |
| DetNet Flow | | DetNet Flow |
| Payload Packet | | Payload Packet |
| | | |
+---------------------------------+ <--\ +---------------------------------+ <--\
| DetNet Control Word | | | DetNet Control Word | |
+=================================+ | +=================================+ |
| S-Label | | | S-Label | |
+---------------------------------+ | +---------------------------------+ |
skipping to change at line 1016 skipping to change at line 997
| DetNet Control Word | | | DetNet Control Word | |
+=================================+ | +=================================+ |
| A-Label | | | A-Label | |
+---------------------------------+ | +---------------------------------+ |
| F-Label(s) | <--/ | F-Label(s) | <--/
+---------------------------------+ +---------------------------------+
| Data-Link | | Data-Link |
+---------------------------------+ +---------------------------------+
| Physical | | Physical |
+---------------------------------+ +---------------------------------+
]]></artwork></figure> ]]></artwork>
</figure>
<t> <t>
Both the aggregation label, which is referred to as an A-Label, and the ind ividual flow's S-Label Both the aggregation label, which is referred to as an A-Label, and the ind ividual flow's S-Label
have their MPLS S bit have their MPLS S bit
set indicating bottom of stack, and the d-CW allows the PREOF set indicating the bottom of stack, and the d-CW allows the PREOF
to work. An A-Label is a special case of an S-Label, whose to work. An A-Label is a special case of an S-Label, whose
properties are known only at the aggregation and deaggregation properties are known only at the aggregation and deaggregation
end-points. end points.
</t> </t>
<t> <t>
It is a property of the A-Label that what follows is a d-CW It is a property of the A-Label that what follows is a d-CW
followed by an MPLS label stack. A followed by an MPLS label stack. A
relay node processing the A-Label would not know the underlying relay node processing the A-Label would not know the underlying
payload type, and the A-Label would be processed as a normal payload type, and the A-Label would be processed as a normal
S-Label. This would only be known to a node that was a peer of the S-Label. This would only be known to a node that was a peer of the
node imposing the S-Label. However there is no real need for it to node imposing the S-Label. However, there is no real need for it to
know the payload type during aggregation processing. know the payload type during aggregation processing.
</t> </t>
<t> <t>
As in the previous section, nodes supporting this type of As in the previous section, nodes supporting this type of
aggregation will need to ensure that individual and aggregated aggregation will need to ensure that individual and aggregated
flows receive the traffic treatment required to ensure the flows receive the traffic treatment required to ensure the
required DetNet service is preserved. Also, it is the controller required DetNet service is preserved. Also, it is the Controller
plane's responsibility to ensure that the service required on Plane's responsibility to ensure that the service required on
the aggregate flow are properly provisioned. the aggregate flow is properly provisioned.
</t> </t>
</section> </section>
</section> </section>
<section title="Service Sub-Layer Considerations"> <section numbered="true" toc="default">
<t> <name>Service Sub-Layer Considerations</name>
The edge and relay node internal procedures related to PREOF are <t>
The internal procedures for edge and relay nodes related to PREOF are
implementation specific. The order of a packet elimination or implementation specific. The order of a packet elimination or
replication is out of scope in this specification. replication is out of scope for this specification.
</t> </t>
<t> <t>
It is important that the DetNet layer is configured such that a It is important that the DetNet layer is configured such that a
DetNet node never receives its own replicated packets. If it were DetNet node never receives its own replicated packets. If it were
to receive such packets the replication function would make the to receive such packets, the replication function would make the
loop more destructive of bandwidth than a conventional unicast loop more destructive of bandwidth than a conventional unicast
loop. Ultimately the TTL in the S-Label will cause the packet to loop. Ultimately, the TTL in the S-Label will cause the packet to
die during a transient loop, but given the sensitivity of applications die during a transient loop, but given the sensitivity of applications
to packet latency the impact on the DetNet application would be to packet latency, the impact on the DetNet application would be
severe. severe.
To avoid the problem of a transient forwarding loop, changes to an To avoid the problem of a transient forwarding loop, changes to an
LSP supporting DetNet MUST be loop-free. LSP supporting DetNet <bcp14>MUST</bcp14> be loop-free.
</t> </t>
<section anchor="sec_t_pe" numbered="true" toc="default">
<section title="Edge Node Processing" anchor="sec_t_pe"> <name>Edge Node Processing</name>
<t> <t>
A DetNet Edge node operates in the DetNet forwarding sub-layer A DetNet edge node operates in the DetNet forwarding sub-layer
and service sub-layer. An edge node is responsible for matching and service sub-layer. An edge node is responsible for matching
incoming packets to the service they require and encapsulating incoming packets to the service they require and encapsulating
them accordingly. An edge node may perform PRF, PEF, and or POF. them accordingly. An edge node may perform PRF, PEF, and/or POF.
Details on encapsulation can be found in <xref Details on encapsulation can be found in <xref target="pwSolution"
target="pwSolution"/>; details on PRF can be found in <xref format="default"/>; details on PRF can be found in <xref
target="prf-requirements"/>; details on PEF can be found in <xref target="prf-requirements" format="default"/>; details on PEF can be
target="pef-requirements"/>; and details on POF can be found in found in <xref target="pef-requirements" format="default"/>; and
<xref target="pof-requirements"/>. details on POF can be found in
</t> <xref target="pof-requirements" format="default"/>.
</section> </t>
</section>
<section title="Relay Node Processing" anchor="sec_s_pe"> <section anchor="sec_s_pe" numbered="true" toc="default">
<t> <name>Relay Node Processing</name>
A DetNet Relay node operates in the DetNet forwarding sub-layer and servi <t>
ce sub-layer. For A DetNet relay node operates in the DetNet forwarding sub-layer and servi
DetNet using MPLS forwarding related processing is performed on the F-Lab ce sub-layer.
el. This For
DetNet using MPLS, forwarding-related processing is performed on the F-La
bel. This
processing is done within an extended forwarder function. Whether an processing is done within an extended forwarder function. Whether an
incoming DetNet flow receives DetNet specific processing depends incoming DetNet flow receives DetNet-specific processing depends
on how the forwarding is programmed. Some relay nodes may be DetNet on how the forwarding is programmed. Some relay nodes may be DetNet
service aware for certain DetNet services, while for other DetNet service s service aware for certain DetNet services, while, for other DetNet servic es,
these nodes may perform as unmodified LSRs that only understand these nodes may perform as unmodified LSRs that only understand
how to switch MPLS-TE LSPs, i.e., as a transit node, how to switch MPLS-TE LSPs, i.e., as a transit node;
see <xref target="FAG"/>. Again, this is entirely up to see <xref target="FAG" format="default"/>. Again, this is entirely up to
how the forwarding has been programmed. how the forwarding has been programmed.
</t> </t>
<t> <t>
During the elimination and replication process the During the elimination and replication process, the
sequence number of an incoming DetNet packet MUST be preserved and sequence number of an incoming DetNet packet <bcp14>MUST</bcp14> be prese
rved and
carried in the corresponding outgoing DetNet carried in the corresponding outgoing DetNet
packet. For example, a relay node that performs both PEF and PRF packet. For example, a relay node that performs both PEF and PRF
first performs PEF on incoming packets to create a compound first performs PEF on incoming packets to create a compound
flow. It then performs PRF and copies the app-flow data and the flow. It then performs PRF and copies the App-flow data and the
d-CW into packets for each outgoing DetNet member flow. d-CW into packets for each outgoing DetNet member flow.
</t> </t>
<t> <t>
The internal design of a relay node is out of scope of this The internal design of a relay node is out of scope for this
document. However the reader's attention is drawn to the need to document. However, the reader's attention is drawn to the need to
make any PREOF state available to the packet processor(s) dealing make any PREOF state available to the packet processor(s) dealing
with packets to which the PREOF functions must be applied, and to with packets to which PREOF must be applied and to
maintain that state is such a way that it is available to the maintain that state in such a way that it is available to the
packet processor operation on the next packet in the DetNet flow packet processor operation on the next packet in the DetNet flow
(which may be a duplicate, a late packet, or the next packet in (which may be a duplicate, a late packet, or the next packet in
sequence). sequence).
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<name>Forwarding Sub-Layer Considerations</name>
<section title="Forwarding Sub-Layer Considerations"> <section anchor="CoS" numbered="true" toc="default">
<!-- maybe move this to be under section 5? --> <name>Class of Service</name>
<section title="Class of Service" anchor="CoS"> <t>
<t> Class of Service (CoS) and Quality of Service (QoS) are terms that
Class and quality of service, i.e., CoS and QoS, are terms that are often used interchangeably and confused with each other.
are often used interchangeably and confused with each other. In In the context of DetNet, CoS is used to refer to mechanisms that provide
the context of DetNet, CoS is used to refer to mechanisms that traffic-forwarding treatment based on non-flow-specific traffic classification,
provide traffic forwarding treatment based on aggregate group and QoS is used to refer to mechanisms that provide traffic-forwarding
basis and QoS is used to refer to mechanisms that provide traffic treatment based on DetNet flow-specific traffic classification.
forwarding treatment based on a specific DetNet flow basis. Examples of existing network-level CoS mechanisms include
Examples of existing network level CoS mechanisms include Differentiated Services (Diffserv), which is enabled by the IP header Dif
DiffServ which is enabled by IP header differentiated services ferentiated Services
code point (DSCP) field <xref target="RFC2474"/> and MPLS label Code Point (DSCP) field <xref target="RFC2474" format="default"/> and MPL
traffic class field <xref target="RFC5462"/>, and at Layer-2, by S label
IEEE 802.1p priority code point (PCP). Traffic Class field <xref target="RFC5462" format="default"/> and at
</t> Layer 2 by IEEE 802.1p Priority Code Point (PCP).
<t> </t>
<t>
CoS for DetNet flows carried in PWs and MPLS is provided using CoS for DetNet flows carried in PWs and MPLS is provided using
the existing MPLS Differentiated Services (DiffServ) architecture the existing MPLS Differentiated Services (Diffserv) architecture
<xref target="RFC3270"/>. Both E-LSP and L-LSP MPLS DiffServ <xref target="RFC3270" format="default"/>. Both E-LSP and L-LSP MPLS Dif
modes MAY be used to support DetNet flows. The Traffic Class fserv
modes <bcp14>MAY</bcp14> be used to support DetNet flows. The Traffic Cl
ass
field (formerly the EXP field) of an MPLS label follows the field (formerly the EXP field) of an MPLS label follows the
definition of <xref target="RFC5462"/> and <xref definition of <xref target="RFC5462" format="default"/> and <xref
target="RFC3270"/>. The Uniform, Pipe, and Short Pipe DiffServ target="RFC3270" format="default"/>. The Uniform, Pipe, and Short Pipe
tunneling and TTL processing models are described in <xref Diffserv tunneling and TTL processing models are described in <xref
target="RFC3270"/> and <xref target="RFC3443"/> and MAY be used target="RFC3270" format="default"/> and <xref target="RFC3443"
for MPLS LSPs supporting DetNet flows. MPLS Explicit Congestion Notificat format="default"/> and <bcp14>MAY</bcp14> be used for MPLS LSPs
ion (ECN) MAY also be used supporting DetNet flows. MPLS Explicit Congestion Notification (ECN)
as defined in ECN <xref target="RFC5129"/> and updated by <xref <bcp14>MAY</bcp14> also be used, as defined in ECN <xref
target="RFC5462"/>. target="RFC5129" format="default"/> and updated by <xref
</t> target="RFC5462" format="default"/>.
</section> </t>
</section>
<section title="Quality of Service" anchor="QoS"> <section anchor="QoS" numbered="true" toc="default">
<t> <name>Quality of Service</name>
In addition to explicit routes, and packet replication and <t>
elimination, described in <xref target="dn-dt-solution"/> above, In addition to explicit routes and packet replication and
elimination (described in <xref target="dn-dt-solution" format="default"/
> above),
DetNet provides zero congestion loss and bounded latency and DetNet provides zero congestion loss and bounded latency and
jitter. As described in <xref jitter. As described in <xref target="RFC8655" format="default"/>, there
target="RFC8655"/>, there are different are different
mechanisms that may be used separately or in combination to mechanisms that may be used separately or in combination to
deliver a zero congestion loss service. This includes Quality of deliver a zero congestion loss service. This includes
Service (QoS) mechanisms at the MPLS layer, that may be combined QoS mechanisms at the MPLS layer, which may be combined
with the mechanisms defined by the underlying network layer such with the mechanisms defined by the underlying network layer, such
as 802.1TSN. as IEEE 802.1 TSN.
</t> </t>
<t> <t>
Quality of Service (QoS) mechanisms for flow specific traffic QoS mechanisms for flow-specific traffic
treatment typically includes a guarantee/agreement for the treatment typically include a guarantee/agreement for the
service, and allocation of resources to support the service. service and allocation of resources to support the service.
Example QoS mechanisms include discrete resource allocation, Example QoS mechanisms include discrete resource allocation,
admission control, flow identification and isolation, and admission control, flow identification and isolation, and
sometimes path control, traffic protection, shaping, policing and sometimes path control, traffic protection, shaping, policing, and
remarking. Example protocols that support QoS control include remarking. Example protocols that support QoS control include the
<xref target="RFC2205">Resource ReSerVation Protocol Resource ReSerVation Protocol (RSVP)
(RSVP)</xref> (RSVP) and RSVP-TE <xref target="RFC3209"/> and <xref target="RFC2205" format="default"/> and RSVP-TE <xref target="RFC32
<xref target="RFC3473"/>. The existing MPLS mechanisms defined 09" format="default"/>
to support CoS <xref target="RFC3270"/> can also be used to <xref target="RFC3473" format="default"/>. The existing MPLS mechanisms
defined
to support CoS <xref target="RFC3270" format="default"/> can also be used
to
reserve resources for specific traffic classes. reserve resources for specific traffic classes.
</t> </t>
<t> <t>
A baseline set of QoS capabilities for DetNet flows carried in PWs A baseline set of QoS capabilities for DetNet flows carried in PWs
and MPLS can be provided by MPLS with Traffic Engineering (MPLS-TE) and MPLS can be provided by MPLS-TE
<xref target="RFC3209"/> and <xref target="RFC3473"/>. TE LSPs can <xref target="RFC3209" format="default"/> <xref target="RFC3473" format="
default"/>. TE LSPs can
also support explicit routes (path pinning). Current service also support explicit routes (path pinning). Current service
definitions for packet TE LSPs can be found in "Specification of definitions for packet TE LSPs can be found in "Specification of
the Controlled Load Quality of Service", <xref target="RFC2211"/>, the Controlled-Load Network Element Service" <xref target="RFC2211" forma
"Specification of Guaranteed Quality of Service", <xref t="default"/>,
target="RFC2212"/>, and "Ethernet Traffic Parameters", <xref "Specification of Guaranteed Quality of Service" <xref
target="RFC6003"/>. Additional service definitions are expected in target="RFC2212" format="default"/>, and "Ethernet Traffic Parameters"
<xref target="RFC6003" format="default"/>. Additional service
definitions are expected in
future documents to support the full range of DetNet services. future documents to support the full range of DetNet services.
In all cases, the existing label-based marking mechanisms defined In all cases, the existing label-based marking mechanisms defined
for TE-LSPs and even E-LSPs are use to support the identification for TE LSPs and even E-LSPs are used to support the identification
of flows requiring DetNet QoS. of flows requiring DetNet QoS.
</t> </t>
</section> </section>
</section>
</section> </section>
</section>
<!-- ===================================================================== -->
<section anchor="mc_summary" <section anchor="mc_summary" numbered="true" toc="default">
title="Management and Control Information Summary"> <name>Management and Control Information Summary</name>
<t> <t>
The specific information needed for the processing of each DetNet The specific information needed for the processing of each DetNet
service depends on the DetNet node type and the functions being service depends on the DetNet node type and the functions being
provided on the node. This section summarizes based on the DetNet provided on the node. This section summarizes this information based on the DetNet
sub-layer and if the DetNet traffic is being sent or received. All sub-layer and if the DetNet traffic is being sent or received. All
DetNet node types are DetNet forwarding sub-layer aware, while all DetNet node types are DetNet forwarding sub-layer aware, while all
but transit nodes are service sub-layer aware. This is shown in <xref but transit nodes are service sub-layer aware. This is shown in <xref
target="fig_dn_mpls_detnet"/>. target="fig_dn_mpls_detnet" format="default"/>.
</t> </t>
<!-- LB: this seems duplicative
<t>
For DetNet management there are a number of approaches that could be use
d to provide
explicit routes and resource allocation in the MPLS forwarding sub-layer
:
<list style="symbols">
<t>
The path could be explicitly set up by a controller which
calculates the path and
explicitly configures each node along that path with the
appropriate forwarding and resource allocation information.
</t>
<t>
The path could be set up using RSVP-TE signaling.
</t>
<t>
The path could be implemented using
MPLS-based segment routing when extended to support resource
allocation.
</t>
</list>
</t>
-->
<t> <t>
Much like other MPLS labels, there are a number of alternatives Much like other MPLS labels, there are a number of alternatives
available for DetNet S-Label and F-Label advertisement to an available for DetNet S-Label and F-Label advertisement to an
upstream peer node. These include distributed signaling upstream peer node. These include distributed signaling
protocols such as RSVP-TE, centralized label distribution via a protocols (such as RSVP-TE), centralized label distribution via a
controller that manages both the sender and the receiver using controller that manages both the sender and the receiver using the
NETCONF/YANG, BGP, PCEP, etc., and hybrid combinations of the Network Configuration Protocol (NETCONF) and YANG, BGP, the Path Computa
two. The details of the controller plane solution required for tion
Element Communication Protocol (PCEP), etc., and hybrid combinations of t
he
two. The details of the Controller Plane solution required for
the label distribution and the management of the label number the label distribution and the management of the label number
space are out of scope of this document. space are out of scope for this document.
There are particular DetNet considerations and requirements that Particular DetNet considerations and requirements
are discussed in <xref target="I-D.ietf-detnet-data-plane-framework"/>. are discussed in <xref target="RFC8938" format="default"/>.
Conformance language is not used in the summary since it applies to Conformance language is not used in the summary, since it applies to
future mechanisms such as those that may be provided in signaling future mechanisms, such as those that may be provided in signaling
and YANG models, e.g., <xref target="I-D.ietf-detnet-yang"/>. and YANG models, e.g., <xref target="I-D.ietf-detnet-yang" format="default"/
</t> >.
<section anchor="mc_summary_ssl"
title="Service Sub-Layer Information Summary">
<t>
The following summarizes the information that is needed on service
sub-layer aware nodes that transmit DetNet MPLS traffic, on a per service ba
sis:
<list style="symbols">
<t>
App-Flow identification information, e.g., IP information as
defined in <xref target="I-D.ietf-detnet-ip-over-mpls"/>. Note,
this information is not needed on DetNet relay nodes.
</t>
<t>
The sequence number length to be used for the service. Valid
values include 0, 16 and 28 bits. 0 bits cannot be used when
PEF or POF is configured for the service.
</t>
<t>
If PRF is to be provided for the service.
</t>
<t>
The outgoing S-Label for each of the service's outgoing DetNet (member)
flows.
</t>
<t>
The forwarding sub-layer information associated with the output
of the service sub-layer. Note that when the PRF function is
provisioned, this information is per DetNet member flow.
Logically the forwarding sub-layer information is a pointer to
further details of
transmission of Detnet flows at the forwarding sub-layer.
</t>
</list>
</t>
<t>
The following summarizes the information that is needed on service
sub-layer aware nodes that receive DetNet MPLS traffic, on a per
service basis:
<list style="symbols">
<t>
The forwarding sub-layer information associated with the input
of the service sub-layer. Note that when the PEF function is
provisioned, this information is per DetNet member flow.
Logically the forwarding sub-layer information is a pointer to
further details of
the reception of Detnet flows at the forwarding sub-layer or
A-Label.
</t>
<t>
The incoming S-Label for the service.
</t>
<t>
If PEF or POF is to be provided for the service.
</t>
<t>
The sequence number length to be used for the service. Valid
values included 0, 16 and 28 bits. 0 bits cannot be used when
PEF or POF are configured for the service.
</t>
<t>
App-Flow identification information, e.g., IP information as
defined in <xref target="I-D.ietf-detnet-ip-over-mpls"/>. Note,
this information is not needed on DetNet relay nodes.
</t> </t>
</list> <section anchor="mc_summary_ssl" numbered="true" toc="default">
</t> <name>Service Sub-Layer Information Summary</name>
<section anchor="mc_summary_ssl_agg" <t>
title="Service Aggregation Information Summary"> The following summarizes the information that is needed (on a per-service
<t> basis) on nodes that are service sub-layer aware and transmit DetNet
Nodes performing aggregation using A-Labels, per Section <xref MPLS traffic:
target="aggregating-detnet-flows-as-a-new-detnet-flow"/>, require </t>
<ul spacing="normal">
<li>App-flow identification information, e.g., IP information as
defined in <xref target="I-D.ietf-detnet-ip-over-mpls"
format="default"/>. Note that this information is not needed on DetNet
relay nodes.</li>
<li>The sequence number length to be used for the service. Valid
values include 0, 16, and 28 bits. 0 bits cannot be used when PEF or
POF is configured for the service.</li>
<li>If PRF is to be provided for the service.</li>
<li>The outgoing S-Label for each of the service's outgoing DetNet
(member) flows.</li>
<li>The forwarding sub-layer information associated with the output
of the service sub-layer. Note that when PRF is
provisioned, this information is per DetNet member flow. Logically,
the forwarding sub-layer information is a pointer to further details
of transmission of DetNet flows at the forwarding sub-layer.</li>
</ul>
<t>
The following summarizes the information that is needed (on a per-service ba
sis) on nodes that are service
sub-layer aware and receive DetNet MPLS traffic:
</t>
<ul spacing="normal">
<li>The forwarding sub-layer information associated with the input
of the service sub-layer. Note that when PEF is
provisioned, this information is per DetNet member flow. Logically,
the forwarding sub-layer information is a pointer to further details
of the reception of DetNet flows at the forwarding sub-layer or
A-Label.</li>
<li>The incoming S-Label for the service.</li>
<li>If PEF or POF is to be provided for the service.</li>
<li>The sequence number length to be used for the service. Valid
values included 0, 16, and 28 bits. 0 bits cannot be used when PEF or
POF are configured for the service.</li>
<li>App-flow identification information, e.g., IP information as
defined in <xref target="I-D.ietf-detnet-ip-over-mpls"
format="default"/>. Note that this information is not needed on DetNet
relay nodes.</li>
</ul>
<section anchor="mc_summary_ssl_agg" numbered="true" toc="default">
<name>Service Aggregation Information Summary</name>
<t>
Nodes performing aggregation using A-Labels, per <xref target="aggregating
-detnet-flows-as-a-new-detnet-flow" format="default"/>, require
the additional information summarized in this section. the additional information summarized in this section.
</t> </t>
<t> <t>
The following summarizes the additional information that is needed on The following summarizes the additional information that is needed on
a node that sends aggregated flows using A-Labels: a node that sends aggregated flows using A-Labels:
<list style="symbols"> </t>
<t> <ul spacing="normal">
The S-Labels or F-Labels that are to be carried over each <li>The S-Labels or F-Labels that are to be carried over each
aggregated service. aggregated service.</li>
</t> <li>The A-Label associated with each aggregated service.</li>
<t>The A-Label associated with each aggregated service.</t> <li>The other S-Label information summarized above.</li>
<t>The other S-Label information summarized above.</t> </ul>
</list> <t>
</t>
<t>
On the receiving node, the A-Label provides the forwarding context On the receiving node, the A-Label provides the forwarding context
of an incoming interface or an F-Label and is used in subsequent of an incoming interface or an F-Label and is used in subsequent
service or forwarding sub-layer receive processing, as service or forwarding sub-layer receive processing, as
appropriated. The related additional configuration that may be appropriate. The related additional configuration that may be
provided is discussed elsewhere in this section. provided is discussed elsewhere in this section.
</t> </t>
</section> </section>
</section> </section>
<section anchor="mc_summary_fsl" <section anchor="mc_summary_fsl" numbered="true" toc="default">
title="Forwarding Sub-Layer Information Summary"> <name>Forwarding Sub-Layer Information Summary</name>
<t>
The following summarizes the information that is needed on
forwarding sub-layer aware nodes that send DetNet MPLS traffic, on
a per forwarding sub-layer flow basis:
<list style="symbols">
<t> <t>
The outgoing F-Label stack to be pushed. The stack may include The following summarizes the information that is needed (on a per-forwardi
H-LSP labels. ng-sub-layer-flow basis) on nodes that are
forwarding sub-layer aware and send DetNet MPLS traffic:
</t> </t>
<t> <ul spacing="normal">
<li>
The outgoing F-Label stack to be pushed. The stack may include
H-LSP labels.</li>
<li>
The traffic parameters associated with a specific label in The traffic parameters associated with a specific label in
the stack. Note that there may be multiple sets of traffic the stack. Note that there may be multiple sets of traffic
parameters associated with specific labels in the stack, e.g., parameters associated with specific labels in the stack, e.g.,
when H-LSPs are used. when H-LSPs are used.</li>
</t> <li>
<t> Outgoing interface and, for unicast traffic, the next-hop
Outgoing interface and, for unicast traffic, the next hop information.</li>
information. <li>
</t> Sub-network-specific parameters on a technology-specific
basis. For example, see <xref target="I-D.ietf-detnet-mpls-over-tsn"
format="default"/>.</li>
</ul>
<t> <t>
Sub-network specific parameters on a technology specific The following summarizes the information that is needed (on a
basis. For example, see <xref per-forwarding-sub-layer-flow basis) on nodes that are forwarding
target="I-D.ietf-detnet-mpls-over-tsn"/>. sub-layer aware and receive DetNet MPLS traffic:
</t> </t>
</list> <ul spacing="normal">
</t> <li>
<t>
The following summarizes the information that is needed on
forwarding sub-layer aware nodes that receive DetNet MPLS traffic, on
a per forwarding sub-layer flow basis:
<list style="symbols">
<t>
The incoming interface. For some implementations and The incoming interface. For some implementations and
deployment scenarios, this information may not be needed. deployment scenarios, this information may not be needed.</li>
</t> <li>
<t>
The incoming F-Label stack to be popped. The stack may include The incoming F-Label stack to be popped. The stack may include
H-LSP labels. H-LSP labels.</li>
</t> <li>
<t>
How the incoming forwarding sub-layer flow is to be handled, How the incoming forwarding sub-layer flow is to be handled,
i.e., forwarded as a transit node, or provided to the service i.e., forwarded as a transit node or provided to the service
sub-layer. sub-layer.</li>
</t> </ul>
</list> <t>
</t> It is the responsibility of the DetNet Controller Plane to
<t>
It is the responsibility of the DetNet controller plane to
properly provision both flow identification information and properly provision both flow identification information and
the flow-specific resources needed to provided the traffic the flow-specific resources needed to provide the traffic
treatment needed to meet each flow's service requirements. treatment needed to meet each flow's service requirements.
This applies for aggregated and individual flows. This applies for aggregated and individual flows.
</t> </t>
</section>
</section> </section>
</section>
<!-- ===================================================================== -->
<section title="Security Considerations"> <section numbered="true" toc="default">
<t> <name>Security Considerations</name>
<t>
Detailed security considerations for DetNet are cataloged in Detailed security considerations for DetNet are cataloged in
<xref target="I-D.ietf-detnet-security"/>, and more general security consider <xref target="I-D.ietf-detnet-security" format="default"/>, and more general
ations security considerations
are described in <xref target="RFC8655"/>. This section are described in <xref target="RFC8655" format="default"/>. This section
considers exclusively security considerations which are specific to the DetNe exclusively considers security considerations that are specific to the DetNet
t
MPLS data plane. The considerations raised related to MPLS networks MPLS data plane. The considerations raised related to MPLS networks
in general in <xref target="RFC5920"/> are equally applicable to the in general in <xref target="RFC5920" format="default"/> are equally applicabl e to
the DetNet MPLS data plane. the DetNet MPLS data plane.
</t> </t>
<t> <t>
Security aspects which are unique to DetNet are those whose aim is to Security aspects that are unique to DetNet are those whose aim is to
protect the support of specific quality of service aspects of DetNet, which a protect the support of specific QoS aspects of DetNet, which are
re
primarily to deliver data flows with extremely low packet loss rates primarily to deliver data flows with extremely low packet loss rates
and bounded end-to-end delivery latency. and bounded end-to-end delivery latency.
Achieving such loss rates and bounded latency may not be possible Achieving such loss rates and bounded latency may not be possible
in the face of a highly capable adversary, such as the one in the face of a highly capable adversary, such as the one
envisioned by the Internet Threat Model of BCP 72 that can envisioned by the Internet Threat Model of BCP 72 <xref target="RFC3552"/ > that can
arbitrarily drop or delay any or all traffic. In order to arbitrarily drop or delay any or all traffic. In order to
present meaningful security considerations, we consider a present meaningful security considerations, we consider a
somewhat weaker attacker who does not control the physical links somewhat weaker attacker who does not control the physical links
of the DetNet domain, but may have the ability to control a of the DetNet domain but may have the ability to control a
network node within the boundary of the DetNet domain. network node within the boundary of the DetNet domain.
</t> </t>
<t> <t>
An additional consideration for the DetNet data plane is to maintain An additional consideration for the DetNet 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 are Application flows can be protected through whatever means are
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 IP over Ethernet (Layer-2) flows. flows and/or by an underlying sub-network using MACsec
<xref target="IEEE802.1AE-2018" format="default"/> for IP over Ethernet
(Layer 2) flows.
MPLS doesn't provide any native security services to account for MPLS doesn't provide any native security services to account for
confidentiality and integrity. confidentiality and integrity.
</t> </t>
<t> <t>
From a data plane perspective this document does not add or modify any From a data plane perspective, this document does not add or modify any
application header information. application header information.
</t> </t>
<t> <t>
At the management and control level DetNet flows are identified on a At the management and control level, DetNet flows are identified on a
per-flow basis, which may provide controller plane 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 is prevented or mitigated malicious or malfunctioning devices is prevented or mitigated
through the use of existing mechanisms, for example by policing and through the use of existing mechanisms, for example, by policing and
shaping incoming traffic. To prevent DetNet packets shaping incoming traffic. To prevent DetNet packets from
having their delay manipulated by an external entity, precautions need having their delay manipulated by an external entity, precautions need
to be taken to ensure that all devices on an LSP are those intended to to be taken to ensure that all devices on an LSP are those intended to
be there by the network operator and that they are well behaved. In be there by the network operator and that they are well behaved. In
addition to physical security, technical methods such as authentication addition to physical security, technical methods, such as authentication
and authorization of network equipment and the instrumentation and and authorization of network equipment and the instrumentation and
monitoring of the LSP packet delay may be used. If a delay attack is monitoring of the LSP packet delay, may be used. If a delay attack is
suspected, traffic may be moved to an alternate path, for example suspected, traffic may be moved to an alternate path, for example,
through changing the LSP or management of the PREOF configuration. through changing the LSP or management of the PREOF configuration.
</t> </t>
</section> </section>
<section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section anchor="iana" title="IANA Considerations"> </middle>
<t> <back>
This document makes no IANA requests.
</t>
</section>
<section anchor="acks" title="Acknowledgements"> <displayreference target="I-D.ietf-detnet-ip-over-mpls" to="DetNet-IP-over-MPLS"
<t> />
The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, <displayreference target="I-D.ietf-detnet-mpls-over-tsn" to="DetNet-MPLS-over-TS
David Black, N"/>
Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig <displayreference target="I-D.ietf-detnet-security" to="DetNet-Security"/>
Gunther, <displayreference target="I-D.ietf-detnet-yang" to="DetNet-YANG"/>
George Swallow, Yuanlong Jiang, Jeong-dong Ryoo and Carlos J. Be <displayreference target="I-D.ietf-detnet-mpls-oam" to="DetNet-MPLS-OAM"/>
rnardos for their
various contributions to this work.
</t>
</section>
<section anchor="Contributors" title="Contributors"> <references>
<t> <name>References</name>
RFC7322 limits the number of authors listed on the front page of a <references>
draft to a maximum of 5. The editor wishes to thank and acknowledge <name>Normative References</name>
the following author for contributing text to this draft. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</t> FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2211.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2212.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3031.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3032.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3209.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3270.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3443.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3473.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4206.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5129.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5085.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5462.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5586.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4385.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6790.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8655.xml"/>
<figure> <artwork><![CDATA[ <xi:include
Don Fedyk href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8938.xml"/>
LabN Consulting, L.L.C.
Email: dfedyk@labn.net
]]></artwork>
</figure>
</section>
</middle> </references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2205.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2474.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3272.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3552.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3985.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4448.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4875.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4301.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5440.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5920.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5921.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6073.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6003.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8306.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8660.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8939.xml"/>
<back> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-i
<references title="Normative References"> etf-detnet-mpls-oam.xml"/>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2211"?>
<?rfc include="reference.RFC.2212"?>
<?rfc include="reference.RFC.3031"?>
<?rfc include="reference.RFC.3032"?>
<?rfc include="reference.RFC.3209"?>
<?rfc include="reference.RFC.3270"?>
<?rfc include="reference.RFC.3443"?>
<?rfc include="reference.RFC.3473"?>
<?rfc include="reference.RFC.4206"?>
<?rfc include="reference.RFC.5129"?>
<?rfc include="reference.RFC.5085"?>
<?rfc include="reference.RFC.5462"?>
<?rfc include="reference.RFC.5586"?>
<?rfc include="reference.RFC.4385"?>
<?rfc include="reference.RFC.6790"?>
<?rfc include="reference.RFC.8174"?>
<?rfc include="reference.RFC.8655"?>
<?rfc include="reference.I-D.ietf-detnet-data-plane-framework"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2205"?>
<?rfc include="reference.RFC.2474"?>
<?rfc include="reference.RFC.3272"?>
<?rfc include="reference.RFC.3985"?>
<?rfc include="reference.RFC.4448"?>
<?rfc include="reference.RFC.4875"?>
<?rfc include="reference.RFC.4301"?>
<?rfc include="reference.RFC.5440"?>
<?rfc include="reference.RFC.5920"?>
<?rfc include="reference.RFC.5921"?>
<?rfc include="reference.RFC.6073"?>
<?rfc include="reference.RFC.6003"?>
<?rfc include="reference.RFC.8306"?>
<?rfc include="reference.RFC.8660"?>
<?rfc include="reference.I-D.ietf-detnet-ip"?>
<?rfc include="reference.I-D.ietf-detnet-ip-over-mpls"?>
<?rfc include="reference.I-D.ietf-detnet-mpls-over-tsn"?>
<?rfc include="reference.I-D.ietf-detnet-security"?>
<?rfc include="reference.I-D.ietf-detnet-yang"?>
<reference anchor="IEEE802.1AE-2018"
target="https://ieeexplore.ieee.org/document/8585421">
<front>
<title>IEEE Std 802.1AE-2018 MAC Security (MACsec)</title>
<author>
<organization>IEEE Standards Association</organization>
</author>
<date year="2018" />
</front>
</reference>
<reference anchor="IEEE802.1CB-2017"
target="https://ieeexplore.ieee.org/document/8091139">
<front>
<title>IEEE Std 802.1CB-2017 Frame Replication and Elimination for
Reliability</title>
<author>
<organization>IEEE Standards Association</organization>
</author>
<date year="2017" />
</front>
</reference>
</references> <reference anchor='I-D.ietf-detnet-ip-over-mpls'>
<front>
<title>DetNet Data Plane: IP over MPLS</title>
<author initials='B' surname='Varga' fullname='Balazs Varga' role='editor'>
<organization />
</author>
<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>
<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-ip-over-mpls-09' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-detnet-ip-over-mpl
s-09.txt' />
</reference>
</back> <reference anchor='I-D.ietf-detnet-mpls-over-tsn'>
</rfc> <front>
<title>DetNet Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking (TSN)</
title>
<author initials='B' surname='Varga' fullname='Balazs Varga' role='editor'>
<organization />
</author>
<author initials='J' surname='Farkas' fullname='Janos Farkas'>
<organization />
</author>
<author initials='A' surname='Malis' fullname='Andrew Malis'>
<organization />
</author>
<author initials='S' surname='Bryant' fullname='Stewart Bryant'>
<organization />
</author>
<date month='December' day="13" year='2020' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-detnet-mpls-over-tsn-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-detnet-mpls-over-
tsn-05.txt' />
</reference>
<reference anchor='I-D.ietf-detnet-security'>
<front>
<title>Deterministic Networking (DetNet) Security Considerations</title>
<author initials='E' surname='Grossman' fullname='Ethan Grossman' role='editor'>
<organization />
</author>
<author initials='T' surname='Mizrahi' fullname='Tal Mizrahi'>
<organization />
</author>
<author initials='A' surname='Hacker' fullname='Andrew Hacker'>
<organization />
</author>
<date month='December' day="11" year='2020' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-detnet-security-13' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-detnet-security-1
3.txt' />
</reference>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-detnet-yang.xml"/>
<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" value="802.1AE-2018"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8585421"/>
</reference>
<reference anchor="IEEE802.1CB-2017" target="https://ieeexplore.ieee.org
/document/8091139">
<front>
<title>IEEE Standard for Local and metropolitan area networks--
Frame Replication and Elimination for Reliability</title>
<author>
<organization>IEEE</organization>
</author>
<date month="October" year="2017"/>
</front>
<seriesInfo name="IEEE" value="802.1CB-2017"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2017.8091139"/>
</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
Anderson"/>, <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"/>, <contact fullname="Jeong-dong
Ryoo"/>, and <contact fullname="Carlos J. Bernardos"/> for their
various contributions to this work.
</t>
</section>
<section anchor="Contributors" numbered="false" toc="default">
<name>Contributors</name>
<t>
The editor of this document wishes to thank and acknowledge the
following person who contributed substantially to the content of this
document and should be considered a coauthor:
</t>
<contact fullname="Don Fedyk">
<organization>LabN Consulting, L.L.C.</organization>
<address>
<postal/>
<email>dfedyk@labn.net</email>
</address>
</contact>
</section>
</back>
</rfc>
 End of changes. 233 change blocks. 
1133 lines changed or deleted 1136 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/