<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!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 xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-ietf-detnet-mpls-over-ip-preof-11" number="9566" ipr="trust200902"
         submissionType="IETF"> submissionType="IETF" obsoletes="" updates="" xml:lang="en" tocInclude="true" consensus="true" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev=" abbrev="DetNet PREOF DetNet IP"> via MPLS over UDP/IP">
    Deterministic Networking (DetNet): DetNet PREOF (DetNet) Packet Replication, Elimination, and Ordering 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>
          <city>Budapest</city>
          <country>Hungary</country>
          <code>1117</code>
        </postal>
        <email>balazs.a.varga@ericsson.com</email>
      </address>
    </author>
    <author fullname="Janos Farkas" initials="J." surname="Farkas">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Magyar Tudosok krt. 11.</street>
          <city>Budapest</city>
          <country>Hungary</country>
          <code>1117</code>
        </postal>
        <email>janos.farkas@ericsson.com</email>
      </address>
    </author>
    <author fullname="Andrew G. Malis" initials="A." surname="Malis">
      <organization>Malis Consulting</organization>
      <address>
        <email>agmalis@gmail.com</email>
      </address>
    </author>

<!--
    <author fullname="James Bond" initials="J." surname="Bond">
      <organization>MI6</organization>
      <address>
        <email>james@bond.com</email>
      </address>
    </author>
-->

  <date /> month="April" year="2024"/>

  <area>RTG</area>
    <workgroup>DetNet</workgroup>

<keyword>DetNet</keyword>
<keyword>IP Data Plane</keyword>
<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
	 the existing MPLS PREOF solution defined for the DetNet MPLS
	 Data Plane
	 data plane and the mechanisms defined by MPLS-over-UDP technology.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="sec_intro"> anchor="sec_intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
     The DetNet Working Group has defined Packet Replication (PRF), Packet
	 Elimination (PEF) (PEF), and Packet Ordering (POF) functions Functions
	 (represented as PREOF) to provide
	 service protection by the DetNet service sub-layer
	 <xref target="RFC8655"/>. target="RFC8655" format="default"/>. The PREOF service protection method relies on
	 copies of the same packet sent over multiple maximally disjoint paths
	 and uses sequencing information to eliminate duplicates. A possible
	 implementation of the PRF and PEF functions is described in
	 <xref target="IEEE8021CB"/> target="IEEE8021CB" format="default"/>, and the related YANG data model is defined
	 in <xref target="IEEEP8021CBcv"/>. target="IEEE8021CBcv" format="default"/>. A possible implementation of the POF
	 function
	 is described in <xref target="I-D.ietf-detnet-pof"/>. target="RFC9550" format="default"/>.
     <xref target="PREOF-scene"/> target="PREOF-scene" format="default"/> shows a DetNet flow on which PREOF functions
	 are applied during forwarding from the source to the destination.
      </t>
      <figure title="PREOF scenario anchor="PREOF-scene">
        <name>PREOF Scenario in a DetNet network" anchor="PREOF-scene"> Network</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
                                      +------------+
            +---------------E1---+    |            |
+---+       |               |    +---R3---+        |          +---+
|src|------R1           +---+             |        E3----O----+dst|
+---+       |           |                 E2-------+          +---+
            +----------R2                 |
                        +-----------------+

R: replication function Replication Function (PRF)
E: elimination function Elimination Function (PEF)
O: ordering function Ordering Function (POF)
]]>
 </artwork></figure>
]]></artwork>
      </figure>
      <t>
     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
	 by adding a sequence number or time stamp timestamp as part of DetNet encapsulation.
	 Sequencing information is typically added once, at or close to the source.
      </t>
      <t>
     The DetNet MPLS data plane <xref target="RFC8964"/> target="RFC8964" format="default"/> specifies how
	 sequencing information is encoded in the MPLS header. However, the DetNet
	 IP data plane described in <xref target="RFC8939"/> target="RFC8939" format="default"/> does not specify how
	 sequencing information can be encoded in the IP packet. This document
	 provides sequencing information to DetNet IP nodes, so it results
     in an improved version of the DetNet IP data plane. As suggested by
	 <xref target="RFC8938"/>, target="RFC8938" format="default"/>, the solution uses existing standardized headers
	 and encapsulations. The improvement is achieved by re-using reusing the DetNet
	 MPLS over UDP/IP
	 MPLS-over-UDP/IP data plane <xref target="RFC9025"/> target="RFC9025" format="default"/> with the restriction
	 of using zero F-labels. F-Labels.
      </t>
    </section> <!-- end of introduction -->

<section title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>
      <section title="Terms numbered="true" toc="default">
        <name>Terms Used in This Document"> Document</name>
        <t>
   This document uses the terminology established in the DetNet architecture
   <xref target="RFC8655"/>, target="RFC8655" format="default"/>, and it is assumed that the reader is assumed
   to be
   familiar with that document and its terminology.
        </t>
      </section>
      <section title="Abbreviations"> numbered="true" toc="default">
        <name>Abbreviations</name>
        <t>
   The following abbreviations are used in this document:
   <list style="hanging" hangIndent="14">
    <t hangText="DetNet">Deterministic Networking.</t>
    <t hangText="PEF">Packet
        </t>
        <dl newline="false" spacing="normal" indent="14">
          <dt>DetNet</dt>
          <dd>Deterministic Networking</dd>
          <dt>PEF</dt>
          <dd>Packet Elimination Function.</t>
    <t hangText="POF">Packet Function</dd>
          <dt>POF</dt>
          <dd>Packet Ordering Function.</t>
	<t hangText="PREOF">Packet Function</dd>
          <dt>PREOF</dt>
          <dd>Packet Replication, Elimination Elimination, and Ordering Functions.</t>
    <t hangText="PRF">Packet Functions</dd>
          <dt>PRF</dt>
          <dd>Packet Replication Function.</t>
   </list>
  </t> Function</dd>
        </dl>
      </section>

<!-- <section title="Requirements Language">
  <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
    "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 numbered="true" toc="default">
      <name>Requirements for adding Adding PREOF to DetNet IP"> IP</name>
      <t>
     The requirements for adding PREOF to DetNet IP are:
	 <list style="symbols">
      </t>
      <ul spacing="normal">
        <li>
          <t>to reuse existing DetNet data plane solutions (e.g.,
		 <xref target="RFC8964"/>, target="RFC8964" format="default"/>, <xref target="RFC9025"/>). </t> target="RFC9025" format="default"/>), and</t>
        </li>
        <li>
          <t>to allow the DetNet service sub-layer for IP packet switched packet-switched
		 networks with minimal implementation effort. </t>
     </list>
  </t>
        </li>
      </ul>
      <t>
     The described solution practically gains from leverages MPLS header fields without
	 requiring the support of the MPLS forwarding plane.
      </t>
    </section>  <!-- end of requirements -->

<section anchor="pof-alg" title="Adding numbered="true" toc="default">
      <name>Adding PREOF to DetNet IP"> IP</name>
      <section anchor="preof-relations" title="Solution Basics"> numbered="true" toc="default">
        <name>Solution Basics</name>
        <t>
	  The DetNet IP encapsulation supporting the DetNet Service service sub-layer is based
	  on the "UDP tunneling" concept. The solution creates a set of underlay
	  UDP/IP tunnels between an overlay set of DetNet relay nodes.
        </t>
        <t>
	  At the edge of a PREOF capable PREOF-capable DetNet IP
	  domain
	  domain, the DetNet flow is encapsulated in an a UDP packet containing the
	  sequence number used by PREOF functions within the domain. This solution
	  maintains the 6-tuple-based DetNet flow identification in DetNet transit
	  nodes, which operate at the DetNet forwarding sub-layer between the DetNet
	  service sub-layer nodes; therefore, it is compatible with
	  <xref target="RFC8939"/>. target="RFC8939" format="default"/>. <xref target="PREOF-IP-basics"/> target="PREOF-IP-basics" format="default"/> shows how the
	  PREOF capable
	  PREOF-capable DetNet IP data plane fits into the DetNet sub-layers.
        </t>
        <figure title="PREOF capable anchor="PREOF-IP-basics">
          <name>PREOF-Capable DetNet IP data plane" anchor="PREOF-IP-basics"> Data Plane</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
   DetNet          IP
      .
      .
+------------+
|  Service   | d-CW, Service-ID (S-label) (S-Label)
+------------+
| Forwarding | UDP/IP Header
+------------+

               *d-CW: DetNet Control Word
]]>
 </artwork></figure>
]]></artwork>
        </figure>
      </section>  <!-- end of Solution basics -->

 <section anchor="pof-blocks" title="Encapsulation"> numbered="true" toc="default">
        <name>Encapsulation</name>
        <t>
     The PREOF capable PREOF-capable DetNet IP encapsulation builds on encapsulating
	 DetNet PseudoWire pseudowire (PW) directly over UDP. That is, it combines DetNet MPLS
	 <xref target="RFC8964"/> target="RFC8964" format="default"/> with DetNet MPLS-in-UDP <xref target="RFC9025"/>, target="RFC9025" format="default"/>,
	 without using any F-Labels F-Labels, as shown in <xref target="PREOF-IP-encap"/>. target="PREOF-IP-encap" format="default"/>.
	 DetNet flows are identified at the receiving DetNet service sub-layer
	 processing node via the S-Label and/or the UDP/IP header information.
	 Sequencing information for PREOF is provided by the DetNet Control Word
	 (d-CW) as per <xref target="RFC8964"/>. target="RFC8964" format="default"/>. The S-label S-Label is used to identify
	 both the DetNet flow and the DetNet App-flow type. The UDP tunnel is used
	 to direct the packet across the DetNet domain to the next DetNet service
	 sub-layer processing node.
        </t>
        <figure title="PREOF capable anchor="PREOF-IP-encap">
          <name>PREOF-Capable DetNet IP encapsulation" anchor="PREOF-IP-encap"> Encapsulation</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
+---------------------------------+
|                                 |
|         DetNet App-Flow         |
|       (original       (Original IP) Packet      |
|                                 |
+---------------------------------+ <--\
|       DetNet Control Word       |    |
+---------------------------------+    +--> PREOF capable PREOF-capable
|       Service-ID (S-Label)      |    |    DetNet IP data
+---------------------------------+    |    plane encapsulation
|            UDP Header           |    |
+---------------------------------+    |
|            IP Header            |    |
+---------------------------------+ <--/
|            Data-Link            |
+---------------------------------+
|             Physical            |
+---------------------------------+
]]>
 </artwork></figure>
]]></artwork>
        </figure>
      </section>  <!-- end of Encapsulation -->

 <section anchor="PREOF-IP-proc" title="Packet Processing"> numbered="true" toc="default">
        <name>Packet Processing</name>
        <t>
     IP ingress and egress nodes of the PREOF capable PREOF-capable DetNet IP domain
	 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
	 DetNet flow, i.e., incoming and outgoing Service-IDs of a DetNet flow
	 can be different. Service-ID values are provisioned per DetNet
	 service via configuration, e.g., via the Controller Plane described in
	 <xref target="RFC8938"/>. target="RFC8938" format="default"/>. In some PREOF topologies, the node performing
	 replication sends the packets to multiple nodes performing performing, e.g., PEF or POF POF, and
	 the replication node can use different Service-ID values for the
	 different member flows for the same DetNet service.
        </t>
        <t>
     Note,
     Note that Service-IDs the Service-ID is a local ID on the receiver side providing identification
	 of that identifies
	 the DetNet flow at the downstream DetNet service sub-layer receiver.
        </t>
      </section>  <!-- end of Packet processing -->

 <section anchor="aggr" title="Flow Aggregation"> numbered="true" toc="default">
        <name>Flow Aggregation</name>
        <t>
     Two methods can be used for flow aggregation:
	 <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>aggregation using same UDP tunnel, and </t>
		 <t>aggregating
          </li>
          <li>
            <t>aggregation of DetNet flows as a new DetNet flow. </t>
	 </list>
  </t>
          </li>
        </ul>
        <t>
     In the first case, method, the different DetNet PseudoWires pseudowires use the same UDP tunnel, so they
	 are treated as a single (aggregated) flow at the forwarding sub-layer. At the
	 service sub-layer, each flow uses a different Service ID Service-ID
	 (see <xref target="PREOF-IP-encap"/> ). target="PREOF-IP-encap" format="default"/>).
        </t>
        <t>
	 For the second option, method, an additional hierarchy is created thanks to by
	 adding an additional Service-ID and d-CW tuple added to the encapsulation.
	 The Aggregate-ID is a special case of a Service-ID,
	 whose properties are known only at the aggregation and de-aggregation deaggregation
	 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.
	 <xref target="PREOF-IP-aggr"/> target="PREOF-IP-aggr" format="default"/> shows the encapsulation in the case of
	 aggregation.
        </t>
        <figure title="Aggregating anchor="PREOF-IP-aggr">
          <name>Aggregating DetNet flows Flows as a new New DetNet flow" anchor="PREOF-IP-aggr"> Flow</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
+---------------------------------+
|                                 |
|         DetNet App-Flow         |
|         Payload  Packet         |
|                                 |
+---------------------------------+ <--\
|       DetNet Control Word       |    |
+---------------------------------+    +--> PREOF capable PREOF-capable
|       Service-ID (S-Label)      |    |    DetNet IP data
+---------------------------------+    |    plane encapsulation
|       DetNet Control Word       |    |
+---------------------------------+    |
|      Aggregate-ID (A-Label)     |    |
+---------------------------------+    |
|           UDP Header            |    |
+---------------------------------+    |
|            IP Header            |    |
+---------------------------------+ <--/
|            Data-Link            |
+---------------------------------+
|             Physical            |
+---------------------------------+
]]>
 </artwork></figure>
]]></artwork>
        </figure>
        <t>
   The option used for aggregation method is known by configuration of configured in the
   aggregation/de-aggregation
   aggregation/deaggregation nodes.
        </t>
        <t>
   If several Detnet DetNet flows are aggregated in a single UDP tunnel, they all need
   to follow the same path in the network.
        </t>
      </section>  <!-- end of Flow Aggregation -->

 <section anchor="PREOF-proc" title="PREOF Processing"> numbered="true" toc="default">
        <name>PREOF Processing</name>
        <t>
     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 determine
	 which local DetNet operation(s) are applied to the received packet.  A unique Service-ID
	 can be allocated to be unique and enabling can be used to identify a DetNet flow identification
	 regardless of which input interface or UDP tunnel receives the packet is received. packet.
	 It is important to note that Service-ID values are driven by the receiver,
	 not the sender.
        </t>
        <t>
	 The DetNet forwarding sub-layer is supported by the UDP tunnel and is
	 responsible for providing resource allocation and explicit routes.
        </t>
        <t>
     The outgoing PREOF encapsulation and processing can be implemented
	 via the provisioning of UDP and IP header information.
	 Note, when PRF is performed at the DetNet service sub-layer,
	 there are multiple member flows, and each member flow requires
	 their
	 its own Service-ID, UDP header information, and IP header information. The headers for
	 each outgoing packet are formatted according to the configuration
	 information, and the UDP Source Port value is set to uniquely identify
	 the DetNet flow. The packet is then handled as a PREOF capable PREOF-capable DetNet
	 IP packet.
        </t>
        <t>
     The incoming PREOF processing can be implemented via by assigning
	 a Service-ID to the provisioning
	 of received Service-ID, DetNet flow and processing the information in the UDP and IP header information. headers. The
	 provisioned information is used to identify incoming app-flows App-flows based
	 on the combination of Service-ID and/or incoming encapsulation header
	 information.
        </t>
      </section>  <!-- end of PREOF procedures -->

 <section anchor="PREOF-IP-domain" title="PREOF capable numbered="true" toc="default">
        <name>PREOF-Capable DetNet IP domain"> Domain</name>
        <t>
	 <xref target="PREOF-domain"/> target="PREOF-domain" format="default"/> shows using PREOF in a PREOF capable PREOF-capable DetNet
	 IP network, where service protection is provided end to end, an and not only
	 within sub-networks like sub-networks, as is depicted in Figure 4 <eref target="https://www.rfc-editor.org/rfc/rfc8939#figure-4" brackets="angle">Figure 4</eref> of <xref target="RFC8939"/>. target="RFC8939" format="default"/>.
        </t>
        <figure title="PREOF capable anchor="PREOF-domain">
          <name>PREOF-Capable DetNet IP domain" anchor="PREOF-domain"> Domain</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
          <---------- PREOF capable PREOF-capable DetNet IP --------------->
                                    ______
                          ____     /      \__
               ____      /     \__/          \____________
+----+      __/    \____/                                 \    +----+
|src |_____/                                               \___| dst|
+----+     \_______            DetNet network    __________/   +----+
                   \_______                    _/
                           \         __     __/
                            \_______/  \___/

                                       +------------+
             +---------------E1---+    |            |
+----+       |               |    +---R3---+        |          +----+
|src |------R1           +---+             |        E3----O----+ dst|
+----+       |           |                 E2-------+          +----+
             +----------R2                 |
                         +-----------------+
]]>
 </artwork></figure>
]]></artwork>
        </figure>
      </section>  <!-- end of PREOF capable DetNet IP domain -->
</section>  <!-- end of Adding PREOF to DetNet IP -->

<section anchor="ctrl-mngmnt-PREOF-IP" title="Control numbered="true" toc="default">
      <name>Control and Management Plane Parameters"> Parameters</name>
      <t>
     The information needed to identify individual and aggregated DetNet flows
	 is summarized as follows:
     <list style="symbols">
      </t>
      <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
		 information when PREOF is used.</t>
        </li>
        <li>
          <t>IPv4 or IPv6 source address 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
         ignored.</t>
        </li>
        <li>
          <t>IPv4 or IPv6 destination address 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
         ignored.</t>
        </li>
        <li>
          <t>IPv6 flow label Flow Label field.</t>
        </li>
        <li>
          <t>IPv4 protocol Protocol field being equal to "UDP". </t>
        </li>
        <li>
          <t>IPv6 (last) next header Next Header field being equal to "UDP".</t>
        </li>
        <li>
          <t>For the IPv4 Type of Service and IPv6 Traffic Class
         Fields:
              <list style="symbols">
         fields:
          </t>
          <ul spacing="normal">
            <li>
              <t>Whether or not the DSCP Differentiated Services Code Point (DSCP) field is used in flow identification identification,
				as the use of the DSCP field for flow identification is optional.</t>
            </li>
            <li>
              <t>If the DSCP field is used to identify a flow, then the flow
				identification information (for that flow) includes a list of
				DSCPs used by the given DetNet flow.</t>
              </list></t>
            </li>
          </ul>
        </li>
        <li>
          <t>UDP Source Port. Support for both exact and wildcard matching is
         required. Port ranges can optionally be used.</t>
        </li>
        <li>
          <t>UDP Destination Port. Support for both exact and wildcard matching is
         required. Port ranges can optionally be used.</t>
        </li>
        <li>
          <t>For end systems, an optional maximum IP packet size
         that should be used for that outgoing DetNet IP flow.</t>
      </list>
        </li>
      </ul>
      <t>
      This information is provisioned per DetNet flow via
      configuration, e.g., via the controller plane. Controller Plane.
      </t>
      <t>
     Ordering of the set of information used to identify an individual
	 DetNet flow can, for example, be used to
	 provide a DetNet service for a specific UDP flow, with unique Source and
	 Destination Port field values, while providing a different service for the
	 aggregate of all other flows with that same UDP Destination Port value.
      </t>
      <t>
     The minimum set of information for the configuration of the DetNet service
	 sub-layer is summarized as follows:
      <list style="symbols">
      </t>
      <ul spacing="normal">
        <li>
          <t>App-flow identification information. information </t>
        </li>
        <li>
          <t>Sequence number length.</t>
        <t>PREOF + related Service-ID(s).</t> length</t>
        </li>
        <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> information</t>
        </li>
        <li>
          <t>Service aggregation information.</t>
     </list>
  </t> information</t>
        </li>
      </ul>
      <t>
     The minimum set of information for the configuration of the DetNet forwarding
	 sub-layer is summarized as follows:
      <list style="symbols">
      </t>
      <ul spacing="normal">
        <li>
          <t>UDP tunnel specific information. tunnel-specific information </t>
        </li>
        <li>
          <t>Traffic parameters.</t>
     </list>
  </t> parameters</t>
        </li>
      </ul>
      <t>
	 These parameters are defined in the DetNet Flow flow and Service service information model
	 <xref target="RFC9016"/> target="RFC9016" format="default"/> and the DetNet YANG model.
      </t>
      <t>
     Note: this document focuses on the use of MPLS over UDP/IP MPLS-over-UDP/IP encapsulation throughout an
	 entire DetNet IP network, making MPLS-based DetNet OAM Operations, Administration, and Maintenance (OAM) techniques applicable
	 <xref target="I-D.ietf-detnet-mpls-oam"/>. target="RFC9546" format="default"/>.
	 Using the described encapsulation only for a portion of a DetNet IP network
	 that handles the PREOF functionality would complicate OAM.
      </t>
    </section>  <!-- end of PREOF-IP management -->

<!-- ===================================================================== -->

<section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
     There are no new DetNet related DetNet-related security considerations introduced by
	 this solution. Security considerations of DetNet MPLS <xref target="RFC8964"/> target="RFC8964" format="default"/> and
     DetNet MPLS over UDP/IP <xref target="RFC9025"/> target="RFC9025" format="default"/> apply.

      </t>
    </section>
    <section anchor="iana" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
   This document makes has no IANA requests.
  </t>
</section>

<section anchor="acks" title="Acknowledgements">
 <t>
   Authors extend their appreciation to Stewart Bryant, Pascal Thubert, David Black,
   Shirley Yangfan and Greg Mirsky for their insightful comments and productive
   discussion that helped to improve the document. actions.
      </t>
    </section>
  </middle>
  <back>
  <references title="Normative References">
<!--   <?rfc include="reference.RFC.2119"?>
   <?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>
      <name>References</name>
      <references>
        <name>Normative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8938.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8939.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8964.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9016.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9025.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9546.xml"/>
      </references>
  <references title="Informative References">
   <?rfc include="reference.I-D.ietf-detnet-pof"?>
      <references>
        <name>Informative References</name>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9550.xml"/>

        <reference anchor="IEEE8021CB"
			target="https://standards.ieee.org/standard/802_1CB-2017.html"> anchor="IEEE8021CB">
          <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 Std" value="802.1CB-2017"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2017.8091139" /> value="10.1109/IEEESTD.2017.8091139"/>
        </reference>
        <reference anchor="IEEEP8021CBcv"
              target="https://www.ieee802.org/1/files/private/cv-drafts/d1/802-1CBcv-d1-2.pdf"> anchor="IEEE8021CBcv">
          <front>
          <title>FRER
            <title>IEEE Standard for Local and metropolitan area networks -- Frame Replication and Elimination for Reliability - Amendment 1: Information Model, YANG Data Model Model, and Management Information Base Module</title>
          <author initials="S." surname="Kehrer" fullname="Stephan Kehrer">
            <organization>IEEE 802.1</organization>
            <author>
              <organization>IEEE</organization>
            </author>
            <date month="March" year="2021"/> month="February" year="2022"/>
          </front>
          <refcontent>Amendment to IEEE Std 802.1CB-2017</refcontent>
          <seriesInfo name="IEEE P802.1CBcv /D1.2" value="P802.1CBcv"/>
        <format type="PDF" target="https://www.ieee802.org/1/files/private/cv-drafts/d1/802-1CBcv-d1-2.pdf"/> Std" value="802.1CBcv-2021"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2022.9715061"/>
        </reference>
      </references>
   </references>
     <section anchor="acks" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
   Authors extend their appreciation to <contact fullname="Stewart Bryant"/>, <contact 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>