rfc9566xml2.original.xml   rfc9566.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info"
docName="draft-ietf-detnet-mpls-over-ip-preof-11"
ipr="trust200902"
submissionType="IETF">
<front>
<title abbrev=" PREOF DetNet IP">
Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP</title>
<author fullname="Balazs Varga" initials="B." surname="Varga"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i
<organization>Ericsson</organization> etf-detnet-mpls-over-ip-preof-11" number="9566" ipr="trust200902" submissionType
<address> ="IETF" obsoletes="" updates="" xml:lang="en" tocInclude="true" consensus="true"
<postal> symRefs="true" sortRefs="true" version="3">
<front>
<title abbrev="DetNet PREOF via MPLS over UDP/IP">
Deterministic Networking (DetNet) Packet Replication, Elimination, and Order
ing Functions (PREOF) via MPLS over UDP/IP</title>
<seriesInfo name="RFC" value="9566"/>
<author fullname="Balazs 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="Janos Farkas" initials="J." surname="Farkas"> <author fullname="Janos 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>
skipping to change at line 45 skipping to change at line 40
<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="Andrew G. Malis" initials="A." surname="Malis"> <author fullname="Andrew G. Malis" initials="A." 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>
<!-- <date month="April" year="2024"/>
<author fullname="James Bond" initials="J." surname="Bond">
<organization>MI6</organization>
<address>
<email>james@bond.com</email>
</address>
</author>
<date /> <area>RTG</area>
<workgroup>DetNet</workgroup> <workgroup>DetNet</workgroup>
<abstract> <keyword>DetNet</keyword>
<t> <keyword>IP Data Plane</keyword>
This document describes how DetNet IP data plane can support the Packet <keyword>Service sub-layer</keyword>
<keyword>Replication</keyword>
<keyword>Elimination</keyword>
<keyword>Ordering</keyword>
<abstract>
<t>
This document describes how the DetNet IP data plane can support the Packet
Replication, Elimination, and Ordering Functions (PREOF) built on Replication, Elimination, and Ordering Functions (PREOF) built on
the existing MPLS PREOF solution defined for DetNet MPLS the existing MPLS PREOF solution defined for the DetNet MPLS
Data Plane and the mechanisms defined by MPLS-over-UDP technology. data plane and the mechanisms defined by MPLS-over-UDP technology.
</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>
<t> <t>
The DetNet Working Group has defined Packet Replication (PRF), Packet The DetNet Working Group has defined Packet Replication (PRF), Packet
Elimination (PEF) and Packet Ordering (POF) functions Elimination (PEF), and Packet Ordering (POF) Functions
(represented as PREOF) to provide (represented as PREOF) to provide
service protection by the DetNet service sub-layer service protection by the DetNet service sub-layer
<xref target="RFC8655"/>. The PREOF service protection method relies on <xref target="RFC8655" format="default"/>. The PREOF service protection method relies on
copies of the same packet sent over multiple maximally disjoint paths copies of the same packet sent over multiple maximally disjoint paths
and uses sequencing information to eliminate duplicates. A possible and uses sequencing information to eliminate duplicates. A possible
implementation of the PRF and PEF functions is described in implementation of PRF and PEF is described in
<xref target="IEEE8021CB"/> and the related YANG data model is defined <xref target="IEEE8021CB" format="default"/>, and the related YANG data
in <xref target="IEEEP8021CBcv"/>. A possible implementation of the POF model is defined
function is described in <xref target="I-D.ietf-detnet-pof"/>. in <xref target="IEEE8021CBcv" format="default"/>. A possible implementa
<xref target="PREOF-scene"/> shows a DetNet flow on which PREOF functions tion of POF
is described in <xref target="RFC9550" format="default"/>.
<xref target="PREOF-scene" format="default"/> shows a DetNet flow on which
PREOF
are applied during forwarding from the source to the destination. are applied during forwarding from the source to the destination.
</t> </t>
<figure anchor="PREOF-scene">
<figure title="PREOF scenario in a DetNet network" anchor="PREOF-scene"> <name>PREOF Scenario in a DetNet Network</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+------------+ +------------+
+---------------E1---+ | | +---------------E1---+ | |
+---+ | | +---R3---+ | +---+ +---+ | | +---R3---+ | +---+
|src|------R1 +---+ | E3----O----+dst| |src|------R1 +---+ | E3----O----+dst|
+---+ | | E2-------+ +---+ +---+ | | E2-------+ +---+
+----------R2 | +----------R2 |
+-----------------+ +-----------------+
R: replication function (PRF) R: Replication Function (PRF)
E: elimination function (PEF) E: Elimination Function (PEF)
O: ordering function (POF) O: Ordering Function (POF)
]]> ]]></artwork>
</artwork></figure> </figure>
<t>
<t> In general, the use of PREOF require sequencing information to
In general, the use of PREOF functions require sequencing information to
be included in the packets of a DetNet compound flow. This can be done be included in the packets of a DetNet compound flow. This can be done
by adding a sequence number or time stamp as part of DetNet encapsulatio n. by adding a sequence number or timestamp as part of DetNet encapsulation .
Sequencing information is typically added once, at or close to the sourc e. Sequencing information is typically added once, at or close to the sourc e.
</t> </t>
<t> <t>
The DetNet MPLS data plane <xref target="RFC8964"/> specifies how The DetNet MPLS data plane <xref target="RFC8964" format="default"/> specif
ies how
sequencing information is encoded in the MPLS header. However, the DetNe t sequencing information is encoded in the MPLS header. However, the DetNe t
IP data plane described in <xref target="RFC8939"/> does not specify how IP data plane described in <xref target="RFC8939" format="default"/> doe s not specify how
sequencing information can be encoded in the IP packet. This document sequencing information can be encoded in the IP packet. This document
provides sequencing information to DetNet IP nodes, so it results provides sequencing information to DetNet IP nodes, so it results
in an improved version of the DetNet IP data plane. As suggested by in an improved version of the DetNet IP data plane. As suggested by
<xref target="RFC8938"/>, the solution uses existing standardized header <xref target="RFC8938" format="default"/>, the solution uses existing st
s andardized headers
and encapsulations. The improvement is achieved by re-using the DetNet and encapsulations. The improvement is achieved by reusing the DetNet
MPLS over UDP/IP data plane <xref target="RFC9025"/> with the restrictio MPLS-over-UDP/IP data plane <xref target="RFC9025" format="default"/> wi
n th the restriction
of using zero F-labels. of using zero F-Labels.
</t> </t>
</section>
</section> <!-- end of introduction -->
<section title="Terminology"> <section numbered="true" toc="default">
<section title="Terms Used in This Document"> <name>Terminology</name>
<t> <section numbered="true" toc="default">
<name>Terms Used in This Document</name>
<t>
This document uses the terminology established in the DetNet architecture This document uses the terminology established in the DetNet architecture
<xref target="RFC8655"/>, and the reader is assumed <xref target="RFC8655" format="default"/>, and it is assumed that the reader
to be familiar with that document and its terminology. is
</t> familiar with that document and its terminology.
</section> </t>
</section>
<section title="Abbreviations"> <section numbered="true" toc="default">
<t> <name>Abbreviations</name>
<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="DetNet">Deterministic Networking.</t> <dl newline="false" spacing="normal" indent="14">
<t hangText="PEF">Packet Elimination Function.</t> <dt>DetNet</dt>
<t hangText="POF">Packet Ordering Function.</t> <dd>Deterministic Networking</dd>
<t hangText="PREOF">Packet Replication, Elimination and Ordering Function <dt>PEF</dt>
s.</t> <dd>Packet Elimination Function</dd>
<t hangText="PRF">Packet Replication Function.</t> <dt>POF</dt>
</list> <dd>Packet Ordering Function</dd>
</t> <dt>PREOF</dt>
</section> <dd>Packet Replication, Elimination, and Ordering Functions</dd>
<dt>PRF</dt>
<!-- <section title="Requirements Language"> <dd>Packet Replication Function</dd>
<t> </dl>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", </section>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and </section>
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
only when, they appear in all capitals, as shown here.
</t>
</section> -->
</section> <!-- end of terminology -->
<!-- ===================================================================== -->
<section anchor="req-on-pof" title="Requirements for adding PREOF to DetNet IP"> <section anchor="req-on-pof" numbered="true" toc="default">
<t> <name>Requirements for Adding PREOF to DetNet IP</name>
<t>
The requirements for adding PREOF to DetNet IP are: The requirements for adding PREOF to DetNet IP are:
<list style="symbols"> </t>
<t>to reuse existing DetNet data plane solutions (e.g., <ul spacing="normal">
<xref target="RFC8964"/>, <xref target="RFC9025"/>). </t> <li>
<t>to allow the DetNet service sub-layer for IP packet switched <t>to reuse existing DetNet data plane solutions (e.g.,
<xref target="RFC8964" format="default"/>, <xref target="RFC9025
" format="default"/>), and</t>
</li>
<li>
<t>to allow the DetNet service sub-layer for IP packet-switched
networks with minimal implementation effort. </t> networks with minimal implementation effort. </t>
</list> </li>
</t> </ul>
<t> <t>
The described solution practically gains from MPLS header fields without The described solution leverages MPLS header fields without
requiring the support of the MPLS forwarding plane. requiring the support of the MPLS forwarding plane.
</t> </t>
</section> <!-- end of requirements --> </section>
<section anchor="pof-alg" title="Adding PREOF to DetNet IP"> <section anchor="pof-alg" numbered="true" toc="default">
<section anchor="preof-relations" title="Solution Basics"> <name>Adding PREOF to DetNet IP</name>
<t> <section anchor="preof-relations" numbered="true" toc="default">
The DetNet IP encapsulation supporting DetNet Service sub-layer is base <name>Solution Basics</name>
d <t>
The DetNet IP encapsulation supporting the DetNet service sub-layer is
based
on the "UDP tunneling" concept. The solution creates a set of underlay on the "UDP tunneling" concept. The solution creates a set of underlay
UDP/IP tunnels between an overlay set of DetNet relay nodes. UDP/IP tunnels between an overlay set of DetNet relay nodes.
</t> </t>
<t> <t>
At the edge of a PREOF capable DetNet IP At the edge of a PREOF-capable DetNet IP
domain the DetNet flow is encapsulated in an UDP packet containing the domain, the DetNet flow is encapsulated in a UDP packet containing the
sequence number used by PREOF functions within the domain. This solutio sequence number used by PREOF within the domain. This solution
n
maintains the 6-tuple-based DetNet flow identification in DetNet transi t maintains the 6-tuple-based DetNet flow identification in DetNet transi t
nodes, which operate at the DetNet forwarding sub-layer between the Det Net nodes, which operate at the DetNet forwarding sub-layer between the Det Net
service sub-layer nodes; therefore, it is compatible with service sub-layer nodes; therefore, it is compatible with
<xref target="RFC8939"/>. <xref target="PREOF-IP-basics"/> shows how th <xref target="RFC8939" format="default"/>. <xref target="PREOF-IP-basic
e s" format="default"/> shows how the
PREOF capable DetNet IP data plane fits into the DetNet sub-layers. PREOF-capable DetNet IP data plane fits into the DetNet sub-layers.
</t> </t>
<figure anchor="PREOF-IP-basics">
<figure title="PREOF capable DetNet IP data plane" anchor="PREOF-IP-basics"> <name>PREOF-Capable DetNet IP Data Plane</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
DetNet IP DetNet IP
. .
. .
+------------+ +------------+
| Service | d-CW, Service-ID (S-label) | Service | d-CW, Service-ID (S-Label)
+------------+ +------------+
| Forwarding | UDP/IP Header | Forwarding | UDP/IP Header
+------------+ +------------+
*d-CW: DetNet Control Word *d-CW: DetNet Control Word
]]> ]]></artwork>
</artwork></figure> </figure>
</section>
</section> <!-- end of Solution basics -->
<section anchor="pof-blocks" title="Encapsulation"> <section anchor="pof-blocks" numbered="true" toc="default">
<t> <name>Encapsulation</name>
The PREOF capable DetNet IP encapsulation builds on encapsulating <t>
DetNet PseudoWire (PW) directly over UDP. That is, it combines DetNet MP The PREOF-capable DetNet IP encapsulation builds on encapsulating
LS DetNet pseudowire (PW) directly over UDP. That is, it combines DetNet MP
<xref target="RFC8964"/> with DetNet MPLS-in-UDP <xref target="RFC9025"/ LS
>, <xref target="RFC8964" format="default"/> with DetNet MPLS-in-UDP <xref
without using any F-Labels as shown in <xref target="PREOF-IP-encap"/>. target="RFC9025" format="default"/>,
without using any F-Labels, as shown in <xref target="PREOF-IP-encap" fo
rmat="default"/>.
DetNet flows are identified at the receiving DetNet service sub-layer DetNet flows are identified at the receiving DetNet service sub-layer
processing node via the S-Label and/or the UDP/IP header information. processing node via the S-Label and/or the UDP/IP header information.
Sequencing information for PREOF is provided by the DetNet Control Word Sequencing information for PREOF is provided by the DetNet Control Word
(d-CW) as per <xref target="RFC8964"/>. The S-label is used to identify (d-CW) per <xref target="RFC8964" format="default"/>. The S-Label is use d to identify
both the DetNet flow and the DetNet App-flow type. The UDP tunnel is use d both the DetNet flow and the DetNet App-flow type. The UDP tunnel is use d
to direct the packet across the DetNet domain to the next DetNet service to direct the packet across the DetNet domain to the next DetNet service
sub-layer processing node. sub-layer processing node.
</t> </t>
<figure anchor="PREOF-IP-encap">
<figure title="PREOF capable DetNet IP encapsulation" anchor="PREOF-IP-encap"> <name>PREOF-Capable DetNet IP Encapsulation</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+---------------------------------+ +---------------------------------+
| | | |
| DetNet App-Flow | | DetNet App-Flow |
| (original IP) Packet | | (Original IP) Packet |
| | | |
+---------------------------------+ <--\ +---------------------------------+ <--\
| DetNet Control Word | | | DetNet Control Word | |
+---------------------------------+ +--> PREOF capable +---------------------------------+ +--> PREOF-capable
| Service-ID (S-Label) | | DetNet IP data | Service-ID (S-Label) | | DetNet IP data
+---------------------------------+ | plane encapsulation +---------------------------------+ | plane encapsulation
| UDP Header | | | UDP Header | |
+---------------------------------+ | +---------------------------------+ |
| IP Header | | | IP Header | |
+---------------------------------+ <--/ +---------------------------------+ <--/
| Data-Link | | Data-Link |
+---------------------------------+ +---------------------------------+
| Physical | | Physical |
+---------------------------------+ +---------------------------------+
]]> ]]></artwork>
</artwork></figure> </figure>
</section>
</section> <!-- end of Encapsulation -->
<section anchor="PREOF-IP-proc" title="Packet Processing"> <section anchor="PREOF-IP-proc" numbered="true" toc="default">
<t> <name>Packet Processing</name>
IP ingress and egress nodes of the PREOF capable DetNet IP domain <t>
IP ingress and egress nodes of the PREOF-capable DetNet IP domain
add and remove a DetNet service-specific d-CW and Service-ID (i.e., add and remove a DetNet service-specific d-CW and Service-ID (i.e.,
S-Label). Relay nodes can change Service-ID values when processing a S-Label). Relay nodes can change Service-ID values when processing a
DetNet flow, i.e., incoming and outgoing Service-IDs of a DetNet flow DetNet flow, i.e., incoming and outgoing Service-IDs of a DetNet flow
can be different. Service-ID values are provisioned per DetNet can be different. Service-ID values are provisioned per DetNet
service via configuration, e.g., via the Controller Plane described in service via configuration, e.g., via the Controller Plane described in
<xref target="RFC8938"/>. In some PREOF topologies, the node performing <xref target="RFC8938" format="default"/>. In some PREOF topologies, the
replication sends the packets to multiple nodes performing e.g., PEF or node performing
POF and replication sends the packets to multiple nodes performing, e.g., PEF or
POF, and
the replication node can use different Service-ID values for the the replication node can use different Service-ID values for the
different member flows for the same DetNet service. different member flows for the same DetNet service.
</t> </t>
<t> <t>
Note, that Service-IDs is a local ID on the receiver side providing identif Note that the Service-ID is a local ID on the receiver side that identifies
ication the DetNet flow at the downstream DetNet service sub-layer receiver.
of the DetNet flow at the downstream DetNet service sub-layer receiver. </t>
</t> </section>
</section> <!-- end of Packet processing -->
<section anchor="aggr" title="Flow Aggregation"> <section anchor="aggr" numbered="true" toc="default">
<t> <name>Flow Aggregation</name>
<t>
Two methods can be used for flow aggregation: Two methods can be used for flow aggregation:
<list style="symbols"> </t>
<t>aggregation using same UDP tunnel, </t> <ul spacing="normal">
<t>aggregating DetNet flows as a new DetNet flow. </t> <li>
</list> <t>aggregation using same UDP tunnel, and </t>
</t> </li>
<t> <li>
In the first case, the different DetNet PseudoWires use the same UDP tunnel <t>aggregation of DetNet flows as a new DetNet flow. </t>
, so they </li>
</ul>
<t>
In the first method, the different DetNet pseudowires use the same UDP tunn
el, so they
are treated as a single (aggregated) flow at the forwarding sub-layer. A t the are treated as a single (aggregated) flow at the forwarding sub-layer. A t the
service sub-layer, each flow uses a different Service ID service sub-layer, each flow uses a different Service-ID
(see <xref target="PREOF-IP-encap"/> ). (see <xref target="PREOF-IP-encap" format="default"/>).
</t> </t>
<t> <t>
For the second option, an additional hierarchy is created thanks to an For the second method, an additional hierarchy is created by
additional Service-ID and d-CW tuple added to the encapsulation. adding an additional Service-ID and d-CW tuple to the encapsulation.
The Aggregate-ID is a special case of a Service-ID, The Aggregate-ID is a special case of a Service-ID,
whose properties are known only at the aggregation and de-aggregation whose properties are known only at the aggregation and deaggregation
end points. It is a property of the Aggregate-ID that it is followed by a end points. It is a property of the Aggregate-ID that it is followed by a
d-CW followed by a Service-ID/d-CW tuple. d-CW followed by a Service-ID/d-CW tuple.
<xref target="PREOF-IP-aggr"/> shows the encapsulation in case of <xref target="PREOF-IP-aggr" format="default"/> shows the encapsulation in the case of
aggregation. aggregation.
</t> </t>
<figure anchor="PREOF-IP-aggr">
<figure title="Aggregating DetNet flows as a new DetNet flow" anchor="PREOF-IP- <name>Aggregating DetNet Flows as a New DetNet Flow</name>
aggr"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
+---------------------------------+ +---------------------------------+
| | | |
| DetNet App-Flow | | DetNet App-Flow |
| Payload Packet | | Payload Packet |
| | | |
+---------------------------------+ <--\ +---------------------------------+ <--\
| DetNet Control Word | | | DetNet Control Word | |
+---------------------------------+ +--> PREOF capable +---------------------------------+ +--> PREOF-capable
| Service-ID (S-Label) | | DetNet IP data | Service-ID (S-Label) | | DetNet IP data
+---------------------------------+ | plane encapsulation +---------------------------------+ | plane encapsulation
| DetNet Control Word | | | DetNet Control Word | |
+---------------------------------+ | +---------------------------------+ |
| Aggregate-ID (A-Label) | | | Aggregate-ID (A-Label) | |
+---------------------------------+ | +---------------------------------+ |
| UDP Header | | | UDP Header | |
+---------------------------------+ | +---------------------------------+ |
| IP Header | | | IP Header | |
+---------------------------------+ <--/ +---------------------------------+ <--/
| Data-Link | | Data-Link |
+---------------------------------+ +---------------------------------+
| Physical | | Physical |
+---------------------------------+ +---------------------------------+
]]> ]]></artwork>
</artwork></figure> </figure>
<t> <t>
The option used for aggregation is known by configuration of the The aggregation method is configured in the
aggregation/de-aggregation nodes. aggregation/deaggregation nodes.
</t> </t>
<t> <t>
If several Detnet flows are aggregated in a single UDP tunnel, they all need If several DetNet flows are aggregated in a single UDP tunnel, they all need
to follow the same path in the network. to follow the same path in the network.
</t> </t>
</section> <!-- end of Flow Aggregation --> </section>
<section anchor="PREOF-proc" title="PREOF Processing"> <section anchor="PREOF-proc" numbered="true" toc="default">
<t> <name>PREOF Processing</name>
<t>
A node operating on a received DetNet flow at the DetNet service sub-layer A node operating on a received DetNet flow at the DetNet service sub-layer
uses the local context associated with a received Service-ID to determin e uses the local context associated with a received Service-ID to determin e
which local DetNet operation(s) are applied to received packet. A Servi which local DetNet operation(s) are applied to the received packet. A u
ce-ID nique Service-ID
can be allocated to be unique and enabling DetNet flow identification can be allocated and can be used to identify a DetNet flow
regardless of which input interface or UDP tunnel the packet is received regardless of which input interface or UDP tunnel receives the packet.
.
It is important to note that Service-ID values are driven by the receive r, It is important to note that Service-ID values are driven by the receive r,
not the sender. not the sender.
</t> </t>
<t> <t>
The DetNet forwarding sub-layer is supported by the UDP tunnel and is The DetNet forwarding sub-layer is supported by the UDP tunnel and is
responsible for providing resource allocation and explicit routes. responsible for providing resource allocation and explicit routes.
</t> </t>
<t> <t>
The outgoing PREOF encapsulation and processing can be implemented The outgoing PREOF encapsulation and processing can be implemented
via the provisioning of UDP and IP header information. via the provisioning of UDP and IP header information.
Note, when PRF is performed at the DetNet service sub-layer, Note, when PRF is performed at the DetNet service sub-layer,
there are multiple member flows, and each member flow requires there are multiple member flows, and each member flow requires
their own Service-ID, UDP and IP header information. The headers for its own Service-ID, UDP header information, and IP header information. T he headers for
each outgoing packet are formatted according to the configuration each outgoing packet are formatted according to the configuration
information, and the UDP Source Port value is set to uniquely identify information, and the UDP Source Port value is set to uniquely identify
the DetNet flow. The packet is then handled as a PREOF capable DetNet the DetNet flow. The packet is then handled as a PREOF-capable DetNet
IP packet. IP packet.
</t> </t>
<t> <t>
The incoming PREOF processing can be implemented via the provisioning The incoming PREOF processing can be implemented by assigning
of received Service-ID, UDP and IP header information. The a Service-ID to the received DetNet flow and processing the information
provisioned information is used to identify incoming app-flows based in the UDP and IP headers. The
provisioned information is used to identify incoming App-flows based
on the combination of Service-ID and/or incoming encapsulation header on the combination of Service-ID and/or incoming encapsulation header
information. information.
</t> </t>
</section> <!-- end of PREOF procedures --> </section>
<section anchor="PREOF-IP-domain" title="PREOF capable DetNet IP domain">
<t>
<xref target="PREOF-domain"/> shows using PREOF in a PREOF capable DetNe
t
IP network, where service protection is provided end to end, an not only
within sub-networks like depicted in Figure 4 of <xref target="RFC8939"/
>.
</t>
<figure title="PREOF capable DetNet IP domain" anchor="PREOF-domain">
<artwork align="center"><![CDATA[
<---------- PREOF capable DetNet IP ---------------> <section anchor="PREOF-IP-domain" numbered="true" toc="default">
<name>PREOF-Capable DetNet IP Domain</name>
<t>
<xref target="PREOF-domain" format="default"/> shows using PREOF in a PR
EOF-capable DetNet
IP network, where service protection is provided end to end, and not onl
y
within sub-networks, as is depicted in <eref target="https://www.rfc-edi
tor.org/rfc/rfc8939#figure-4" brackets="angle">Figure 4</eref> of <xref target="
RFC8939" format="default"/>.
</t>
<figure anchor="PREOF-domain">
<name>PREOF-Capable DetNet IP Domain</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
<---------- PREOF-capable DetNet IP --------------->
______ ______
____ / \__ ____ / \__
____ / \__/ \____________ ____ / \__/ \____________
+----+ __/ \____/ \ +----+ +----+ __/ \____/ \ +----+
|src |_____/ \___| dst| |src |_____/ \___| dst|
+----+ \_______ DetNet network __________/ +----+ +----+ \_______ DetNet network __________/ +----+
\_______ _/ \_______ _/
\ __ __/ \ __ __/
\_______/ \___/ \_______/ \___/
+------------+ +------------+
+---------------E1---+ | | +---------------E1---+ | |
+----+ | | +---R3---+ | +----+ +----+ | | +---R3---+ | +----+
|src |------R1 +---+ | E3----O----+ dst| |src |------R1 +---+ | E3----O----+ dst|
+----+ | | E2-------+ +----+ +----+ | | E2-------+ +----+
+----------R2 | +----------R2 |
+-----------------+ +-----------------+
]]> ]]></artwork>
</artwork></figure> </figure>
</section>
</section> <!-- end of PREOF capable DetNet IP domain --> </section>
</section> <!-- end of Adding PREOF to DetNet IP -->
<section anchor="ctrl-mngmnt-PREOF-IP" title="Control and Management Plane Param <section anchor="ctrl-mngmnt-PREOF-IP" numbered="true" toc="default">
eters"> <name>Control and Management Plane Parameters</name>
<t> <t>
The information needed to identify individual and aggregated DetNet flows The information needed to identify individual and aggregated DetNet flows
is summarized as follows: is summarized as follows:
<list style="symbols"> </t>
<t>Service-ID information to be mapped to UDP/IP flows. Note that, for <ul spacing="normal">
<li>
<t>Service-ID information to be mapped to UDP/IP flows. Note that, for
example, a single Service-ID can map to multiple sets of UDP/IP example, a single Service-ID can map to multiple sets of UDP/IP
information when PREOF is used.</t> information when PREOF is used.</t>
<t>IPv4 or IPv6 source address field.</t> </li>
<t>IPv4 or IPv6 source address prefix length, where a zero <li>
<t>IPv4 or IPv6 Source Address field.</t>
</li>
<li>
<t>IPv4 or IPv6 source address prefix length, where a zero
(0) value effectively means that the address field is (0) value effectively means that the address field is
ignored.</t> ignored.</t>
<t>IPv4 or IPv6 destination address field.</t> </li>
<t>IPv4 or IPv6 destination address prefix length, where a <li>
<t>IPv4 or IPv6 Destination Address field.</t>
</li>
<li>
<t>IPv4 or IPv6 destination address prefix length, where a
zero (0) effectively means that the address field is zero (0) effectively means that the address field is
ignored.</t> ignored.</t>
<t>IPv6 flow label field.</t> </li>
<t>IPv4 protocol field being equal to "UDP". </t> <li>
<t>IPv6 (last) next header field being equal to "UDP".</t> <t>IPv6 Flow Label field.</t>
<t>For the IPv4 Type of Service and IPv6 Traffic Class </li>
Fields: <li>
<list style="symbols"> <t>IPv4 Protocol field being equal to "UDP". </t>
<t>Whether or not the DSCP field is used in flow identification </li>
<li>
<t>IPv6 (last) Next Header field being equal to "UDP".</t>
</li>
<li>
<t>For the IPv4 Type of Service and IPv6 Traffic Class
fields:
</t>
<ul spacing="normal">
<li>
<t>Whether or not the Differentiated Services Code Point (DSCP) fi
eld is used in flow identification,
as the use of the DSCP field for flow identificat ion is optional.</t> as the use of the DSCP field for flow identificat ion is optional.</t>
<t>If the DSCP field is used to identify a flow, then the flow </li>
<li>
<t>If the DSCP field is used to identify a flow, then the flow
identification information (for that flow) includ es a list of identification information (for that flow) includ es a list of
DSCPs used by the given DetNet flow.</t> DSCPs used by the given DetNet flow.</t>
</list></t> </li>
<t>UDP Source Port. Support for both exact and wildcard matching is </ul>
</li>
<li>
<t>UDP Source Port. Support for both exact and wildcard matching is
required. Port ranges can optionally be used.</t> required. Port ranges can optionally be used.</t>
<t>UDP Destination Port. Support for both exact and wildcard matching is </li>
<li>
<t>UDP Destination Port. Support for both exact and wildcard matching
is
required. Port ranges can optionally be used.</t> required. Port ranges can optionally be used.</t>
<t>For end systems, an optional maximum IP packet size </li>
<li>
<t>For end systems, an optional maximum IP packet size
that should be used for that outgoing DetNet IP flow.</t> that should be used for that outgoing DetNet IP flow.</t>
</list> </li>
</ul>
<t>
This information is provisioned per DetNet flow via This information is provisioned per DetNet flow via
configuration, e.g., via the controller plane. configuration, e.g., via the Controller Plane.
</t> </t>
<t> <t>
Ordering of the set of information used to identify an individual Ordering of the set of information used to identify an individual
DetNet flow can, for example, be used to DetNet flow can, for example, be used to
provide a DetNet service for a specific UDP flow, with unique Source and provide a DetNet service for a specific UDP flow, with unique Source and
Destination Port field values, while providing a different service for t he Destination Port field values, while providing a different service for t he
aggregate of all other flows with that same UDP Destination Port value. aggregate of all other flows with that same UDP Destination Port value.
</t> </t>
<t> <t>
The minimum set of information for the configuration of the DetNet service The minimum set of information for the configuration of the DetNet service
sub-layer is summarized as follows: sub-layer is summarized as follows:
<list style="symbols"> </t>
<t>App-flow identification information. </t> <ul spacing="normal">
<t>Sequence number length.</t> <li>
<t>PREOF + related Service-ID(s).</t> <t>App-flow identification information </t>
<t>Associated forwarding sub-layer information.</t> </li>
<t>Service aggregation information.</t> <li>
</list> <t>Sequence number length</t>
</t> </li>
<t> <li>
<t>Type of PREOF to be executed on the DetNet flow</t>
</li>
<li>
<t>Service-ID(s) used by the member flows</t>
</li>
<li>
<t>Associated forwarding sub-layer information</t>
</li>
<li>
<t>Service aggregation information</t>
</li>
</ul>
<t>
The minimum set of information for the configuration of the DetNet forwardi ng The minimum set of information for the configuration of the DetNet forwardi ng
sub-layer is summarized as follows: sub-layer is summarized as follows:
<list style="symbols"> </t>
<t>UDP tunnel specific information. </t> <ul spacing="normal">
<t>Traffic parameters.</t> <li>
</list> <t>UDP tunnel-specific information </t>
</t> </li>
<t> <li>
These parameters are defined in the DetNet Flow and Service information <t>Traffic parameters</t>
model </li>
<xref target="RFC9016"/> and the DetNet YANG model. </ul>
</t> <t>
<t> These parameters are defined in the DetNet flow and service information
Note: this document focuses on the use of MPLS over UDP/IP encapsulation th model
roughout an <xref target="RFC9016" format="default"/> and the DetNet YANG model.
entire DetNet IP network, making MPLS-based DetNet OAM techniques applic </t>
able <t>
<xref target="I-D.ietf-detnet-mpls-oam"/>. Note: this document focuses on the use of MPLS-over-UDP/IP encapsulation th
roughout an
entire DetNet IP network, making MPLS-based DetNet Operations, Administr
ation, and Maintenance (OAM) techniques applicable
<xref target="RFC9546" format="default"/>.
Using the described encapsulation only for a portion of a DetNet IP netw ork Using the described encapsulation only for a portion of a DetNet IP netw ork
that handles the PREOF functionality would complicate OAM. that handles PREOF would complicate OAM.
</t> </t>
</section>
</section> <!-- end of PREOF-IP management -->
<!-- ===================================================================== -->
<section title="Security Considerations">
<t>
There are no new DetNet related security considerations introduced by
this solution. Security considerations of DetNet MPLS <xref target="RFC8
964"/> and
DetNet MPLS over UDP/IP <xref target="RFC9025"/> apply.
</t>
</section>
<section anchor="iana" title="IANA Considerations"> <section numbered="true" toc="default">
<t> <name>Security Considerations</name>
This document makes no IANA requests. <t>
</t> There are no new DetNet-related security considerations introduced by
</section> this solution. Security considerations of DetNet MPLS <xref target="RFC8
964" format="default"/> and
DetNet MPLS over UDP/IP <xref target="RFC9025" format="default"/> apply.
<section anchor="acks" title="Acknowledgements"> </t>
<t> </section>
Authors extend their appreciation to Stewart Bryant, Pascal Thubert, David Bl <section anchor="iana" numbered="true" toc="default">
ack, <name>IANA Considerations</name>
Shirley Yangfan and Greg Mirsky for their insightful comments and productive <t>
discussion that helped to improve the document. This document has no IANA actions.
</t> </t>
</section> </section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.86
55.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
938.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
939.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
964.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
016.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
025.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
546.xml"/>
</references>
<references>
<name>Informative References</name>
</middle> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 550.xml"/>
<back> <reference anchor="IEEE8021CB">
<references title="Normative References"> <front>
<!-- <?rfc include="reference.RFC.2119"?> <title>IEEE Standard for Local and metropolitan area
<?rfc include="reference.RFC.8174"?> -->
<?rfc include="reference.RFC.8655"?>
<?rfc include="reference.RFC.8938"?>
<?rfc include="reference.RFC.8939"?>
<?rfc include="reference.RFC.8964"?>
<?rfc include="reference.RFC.9016"?>
<?rfc include="reference.RFC.9025"?>
<?rfc include="reference.I-D.ietf-detnet-mpls-oam"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-detnet-pof"?>
<reference anchor="IEEE8021CB"
target="https://standards.ieee.org/standard/802_1CB-2017.
html">
<front>
<title>IEEE Standard for Local and metropolitan area
networks -- Frame Replication and Elimination for Reliability networks -- Frame Replication and Elimination for Reliability
</title> </title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date month="October" year="2017"/> <date month="October" year="2017"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2017.8091139" /> <seriesInfo name="IEEE Std" value="802.1CB-2017"/>
</reference> <seriesInfo name="DOI" value="10.1109/IEEESTD.2017.8091139"/>
<reference anchor="IEEEP8021CBcv" </reference>
target="https://www.ieee802.org/1/files/private/cv-drafts/d1/802-1 <reference anchor="IEEE8021CBcv">
CBcv-d1-2.pdf"> <front>
<front> <title>IEEE Standard for Local and metropolitan area networks -- Fra
<title>FRER YANG Data Model and Management Information Base Module</ti me Replication and Elimination for Reliability - Amendment 1: Information Model,
tle> YANG Data Model, and Management Information Base Module</title>
<author initials="S." surname="Kehrer" fullname="Stephan Kehrer"> <author>
<organization>IEEE 802.1</organization> <organization>IEEE</organization>
</author> </author>
<date month="March" year="2021"/> <date month="February" year="2022"/>
</front> </front>
<seriesInfo name="IEEE P802.1CBcv /D1.2" value="P802.1CBcv"/> <refcontent>Amendment to IEEE Std 802.1CB-2017</refcontent>
<format type="PDF" target="https://www.ieee802.org/1/files/private/cv-dr <seriesInfo name="IEEE Std" value="802.1CBcv-2021"/>
afts/d1/802-1CBcv-d1-2.pdf"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2022.9715061"/>
</reference> </reference>
</references> </references>
</back> </references>
<section anchor="acks" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
Authors extend their appreciation to <contact fullname="Stewart Bryant"/>, <c
ontact fullname="Pascal Thubert"/>, <contact fullname="David Black"/>,
<contact fullname="Shirley Yangfan"/>, and <contact fullname="Greg Mirsky"/>
for their insightful comments and productive
discussion that helped to improve the document.
</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 80 change blocks. 
381 lines changed or deleted 444 lines changed or added

This html diff was produced by rfcdiff 1.48.