<?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-pof-11"
number="9550"
ipr="trust200902"
         submissionType="IETF">
submissionType="IETF"
consensus="true"
obsoletes=""
updates=""
xml:lang="en"
tocInclude="true"
symRefs="true"
sortRefs="true"
version="3">

<!-- [rfced] This is a question for Stephan and Tobias. Would you like to use
a shortened form of your affiliation in the first-page header and then
the full name in the Authors' Addresses section? Please review the
first-page header in each of the output formats (txt, html, and pdf), and
let us know your thoughts.
-->

  <front>
    <title abbrev="DetNet POF">
    Deterministic Networking (DetNet): Packet Ordering Function</title>
    <seriesInfo name="RFC" value="9550"/>
    <author role="editor" 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="Stephan Kehrer" initials="S." surname="Kehrer">
      <organization>Hirschmann Automation and Control GmbH</organization>
      <address>
        <postal>
          <street>Stuttgarter Strasse 45-51.</street>
          <city>Neckartenzlingen</city>
          <country>Germany</country>
          <code>72654</code>
        </postal>
        <email>Stephan.Kehrer@belden.com</email>
      </address>
    </author>
    <author fullname="Tobias Heer" initials="T." surname="Heer">
      <organization>Hirschmann Automation and Control GmbH</organization>
      <address>
        <postal>
          <street>Stuttgarter Strasse 45-51.</street>
          <city>Neckartenzlingen</city>
          <country>Germany</country>
          <code>72654</code>
        </postal>
        <email>Tobias.Heer@belden.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="March" year="2024"/>

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

<abstract>

      <t>
     Replication
     The replication and Elimination elimination functions of DetNet Architecture the Deterministic Networking
     (DetNet) architecture can result in out-of-order packets, which is not
     acceptable for some time-sensitive applications. The Packet Ordering
     Function (POF) algorithm algorithms described herein enables to restore in this document enable restoration
     of the correct packet order when the replication and elimination
     functions are used in DetNet networks.  The POF only provides ordering within
     the latency bound of a DetNet flow,
	 and flow; it does not provide any additional
     reliability.
      </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
     <xref target="RFC8655" format="default"/> defines the Packet Replication
     Function (PRF) and packet
	 elimination Packet Elimination Function (PEF) functions in DetNet for
     achieving extremely low packet loss. The PRF and PEF are described in <xref target="RFC8655"/> and provide service
     protection for DetNet flows. This 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 model is
     defined in <xref target="IEEEP8021CBcv"/>. target="IEEEP8021CBcv" format="default"/>.
      </t>

      <t>
     In general, use of per packet per-packet replication and elimination functions can
     result in out-of-order delivery of packets, which is not acceptable for
     some deterministic applications. Correcting packet order is not a trivial task, therefore
     task; therefore, details of a Packet Ordering Function (POF) are
     specified herein. The IETF DetNet WG has defined in this document. <xref target="RFC8655"/> target="RFC8655" format="default"/>
     defines the external observable result of a POF function, i.e., (i.e., that
     packets are
	 reordered, reordered) but without does not specify any implementation details.
      </t>
      <t>
     So far in packet networks, out-of-order delivery situations were have been handled
	 at higher OSI layers at the end-points/hosts endpoints/hosts (e.g., in the TCP stack when
	 packets are sent to the application layer) and not within a network in nodes
	 acting at the Layer-2 Layer 2 or Layer-3 Layer 3 OSI layers.
      </t>
      <t>
     <xref target="PREOF-scene"/> target="PREOF-scene" format="default"/> shows a DetNet flow on which packet
	 replication, elimination Packet
	 Replication, Elimination, and ordering Ordering Functions (PREOF) functions
	 are applied during forwarding from source to 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----O1---+ dst|
+----+       |        |                 E2-------+          +----+
             +-------R2                 |
                      +-----------------+

R: replication point (PRF)
E: elimination point (PEF)
O: ordering function (POF)
]]>
 </artwork></figure>
]]></artwork>
      </figure>

      <t>
    In general, the use of PREOF functions require requires sequencing information
    to be included in the packets of a DetNet compound flow.  This can be
    done by adding a sequence number as part of DetNet encapsulation
    <xref target="RFC8655"/>. target="RFC8655" format="default"/>. Sequencing information is typically added once,
	at or close to the source.
      </t>
      <t>
     Important
     It is important to note that different applications can react differently to out-of-order
	 delivery. A single out-of-order packet (E.g., (e.g., packet order: order #1, #3, #2,
	 #4, #5) is interpreted by some application as a single error, but
	 some
	 other applications treat it as 3 three errors in-a-row situation. in a row.
	 For example, in industrial scenarios
	 3 scenarios,
	 three errors in-a-row in a row is a usual typical error threshold and can cause the
	 application to stop (e.g., to go to a fail-safe state).
      </t>
      <t>
     The POF ensures in-order delivery for packets being within
	 the latency bound of the (DetNet) DetNet flow. The POF does not correct
	 errors in the packet flow e.g., (e.g., duplicate packets, packets or packets that are too late packets. late).
      </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"/>, and target="RFC8655" format="default"/>; 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="9">
          <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>
 </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> Function</dd>
        </dl>
      </section>
-->

</section>  <!-- end of terminology -->

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

<section anchor="req-on-pof" title="Requirements on numbered="true" toc="default">

  <name>Requirements for POF Implementations"> Implementations</name>
      <t>
     The requirements on a for POF function implementations are:
	 <list style="symbols">
         <t>to
      </t>
      <ul spacing="normal">
        <li>
          <t>To solve the out-of-order delivery problem of the Replication replication
		 and Elimination elimination functions of DetNet networks. </t>
         <t>to
        </li>
        <li>
          <t>To consider the delay bound requirement of a DetNet Flow. flow. </t>
         <t>to
        </li>
        <li>

          <t>To be simple and to require in network nodes only a minimum set of states/configuration parameters states,
          configuration parameters, and resources per DetNet
		 Flow. flow in network
          nodes.
	  </t>
		 <t>to
        </li>
        <li>
          <t>To add only minimal or no delay to the forwarding process
		 of packets. </t>
		 <t>not to
        </li>
        <li>
          <t>To not require synchronization between PREOF nodes. </t>
     </list>
  </t>
        </li>
      </ul>
      <t>
     Some aspects are explicitly out-of-scope out of scope for a POF function:
	 <list style="symbols">
         <t>to POF:
      </t>
      <ul spacing="normal">
        <li>
          <t>To eliminate the delay variation caused by the packet ordering.
          Dealing with delay variation is a DetNet forwarding sub-layer target
          target, and it can be achieved achieved, for example example, by placing a de-jitter
          buffer or flow regulator (e.g., shaping) function after the POF
		 functionality.</t>
     </list>
  </t> POF.</t>
        </li>
      </ul>
    </section>  <!-- end of requirements -->

<section anchor="pof-alg" title="POF Algorithms"> numbered="true" toc="default">
      <name>POF Algorithms</name>
      <section anchor="preof-relations" title="Prerequisites numbered="true" toc="default">
        <name>Prerequisites and Assumptions"> Assumptions</name>
        <t>
        The POF Algorithm algorithms discussed in this document makes make some assumptions and
        tradeoffs
        trade-offs regarding the characteristics of the sequence of received
        packets. In particular, the algorithm assumes algorithms assume that a Packet
        Elimination Function (PEF)
        PEF is performed on the incoming packets
        before they are handed to the POF function. POF. Hence, the sequence
        of incoming packets can be out of order out-of-order or incomplete but cannot
		contain duplicate packets. However, the PREOF functions run
        independently without any state exchange required between the
        PEF and the POF or the PRF and the POF. Error cases in which
		duplicate packets are presented to the POF can lead to out of
		order out-of-order delivery of duplicate packets as well as and to increased delays.
        </t>
        <t>
        The algorithm algorithms further requires require that the delay difference between two
        replicated packets that arrive at the PEF before the POF is bounded and
        known. Error cases that violate this condition (e.g., a packet that
        arrives later than this bound) will result in out-of order out-of-order packets.
        </t>
        <t>
        The algorithm algorithms also makes make some tradeoffs. trade-offs. For simplicity, it is designed
        in a way that allows
        to allow for some out of order out-of-order packets directly after
        initialization. If this is not acceptable,
		<xref target="enh-pof"/> target="enh-pof" format="default"/> provides an alternative initialization scheme
        that prevents out-of-order packets in the initialization phase.
        </t>
      </section>  <!-- end of POF assumptions -->

 <section anchor="pof-blocks" title="POF building blocks"> numbered="true" toc="default">
        <name>POF Building Blocks</name>
        <t>
     The method described herein in this document provides a POF for DetNet networks. The
	 configuration parameters of the POF can be derived during when engineering the
	 DetNet flow through the network.
        </t>
        <t>
     The POF method is provided via:
	 <list style="numbers">
		 <t>Delay calculator: calculates via the following:
        </t>

	<dl newline="false" spacing="normal">
            <dt>Delay calculator:</dt><dd>Calculates buffering time for out-of-order packets.
		 Buffering time considers (i) the delay
		 difference of paths used for forwarding the replicated packets
		 and (ii) the bounded delay requirement of the given DetNet flow. </t>
         <t>Conditional buffer:
          </dd>
            <dt>Conditional delay buffer:</dt><dd>Used for buffering the out-of-order packets of a
		 DetNet flow for a given time. </t>
     </list>
  </t> </dd>
</dl>
        <t>
     Note: the The conditional delay buffer of the POF increases the burstiness of the
	 traffic as it only adds delay only for some of the packets.
        </t>
        <t>
     <xref target="POF-blocks"/> target="POF-blocks" format="default"/> shows the building blocks of a
	 possible POF implementation.
        </t>
        <figure title="POF Building Blocks" anchor="POF-blocks">
          <name>POF Building Blocks</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
               +------------+        +--------------+
               | Delay calc |        | Conditional  |
            +--| for packet >--->>---| Delay Buffer >--+
            |  +------------+        +--------------+  |
            |                                          |
     +------^--------+                                 |
->>--| POF selector  >---------------------------------+-->>----
     | (Flow ident.) |
     +---------------+

->>- packet flow

]]>
 </artwork></figure>
]]></artwork>
        </figure>
      </section>  <!-- end of POF blocks -->

 <section anchor="basic-pof" title="The numbered="true" toc="default">
        <name>The Basic POF Algorithm"> Algorithm</name>
        <t>
     The basic POF algorithm delays all out-of-order packets until all
	 previous packet arrives packets arrive or a given time (POFMaxDelay) ("POFMaxDelay") elapses. The
	 basic POF algorithm works as follows:
	 <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>The sequence number of the last forwarded packet (POFLastSent) ("POFLastSent") is
		 stored for each DetNet Flow. flow. </t>
          </li>
          <li>
            <t>The sequence number (seq_num) of a received packet is compared to
		 that of the last forwarded one (POFLastSent). ("POFLastSent"). </t>
          </li>
          <li>
            <t>If (seq_num &#60;= &lt;= POFLastSent + 1)
			<list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t> Then the packet is forwarded without buffering buffering, and "POFLastSent"
				is updated (POFLastSent = seq_num). </t>
              </li>
              <li>
                <t> Else Else, the received packet is buffered. </t>
			</list>
		 </t>
              </li>
            </ul>
          </li>
          <li>
            <t>A buffered packet is forwarded from the buffer when its seq_num
		 becomes equal to "POFLastSent +1," + 1" OR a predefined time ("POFMaxDelay")
		 elapses.</t>
          </li>
          <li>
            <t>When a packet is forwarded from the buffer buffer, "POFLastSent" is
		 updated with its seq_num (POFLastSent = seq_num). </t>
	 </list>
  </t>
  <t>
     Note: the
          </li>
        </ul>

<t>Notes:</t>
<ul spacing="normal">
<li>The difference of between sequence number numbers in consecutive packets is bounded
	 due to the history window of the Elimination elimination function before the POF.
	 Therefore "&#60;="
	 Therefore, "&lt;="  can be evaluated despite of the circular
	 sequence number space. A possible implementation of the PEF function and
	 the impact of the history window is are described in <xref target="IEEE8021CB"/>.
  </t>
  <t>
	 Note2: The target="IEEE8021CB" format="default"/>.
        </li>
        <li>The basic POF algorithm can be extended to cope with multiple failure scenarios
	 (i.e., simultaneous packet loss and out-of-order packets), packets) when the expiration
	 of the timer for a packet with sequence number N trigger triggers the release of some
	 number of
	 packets with a sequence number smaller than N.
  </t>
        </li>
</ul>
        <t>
     The state used by the basic POF algorithm (i.e., "POFLastSent") needs
	 initialization and maintenance. This works as follows:
	 <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>The next received packet is forwarded and the POFLastSent "POFLastSent"
		 updated when the POF function was is reset OR no packet was is received
		 for a predefined time ("POFTakeAnyTime"). </t>
          </li>
          <li>
            <t>The reset of the POF erases all packets from the time-based
		 buffer used by the POF. </t>
	 </list>
  </t>
          </li>
        </ul>
        <t>
     The basic POF algorithm has two parameters to engineer:
	 <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>"POFMaxDelay", which cannot be smaller than the delay
		 difference of the paths used by the flow. </t>
          </li>
          <li>
            <t>"POFTakeAnyTime", which is calculated based on several factors,
            for example example, the RECOVERY_TIMEOUT related settings of the
		 Elimination elimination function(s) relating
            to RECOVERY_TIMEOUT before the POF, the flow characteristics
            (e.g., inter packet inter-packet time), and the delay difference of the paths
            used by the flow.  </t>
	 </list>
  </t>
          </li>
        </ul>
        <t>
     Design of these parameters is out-of-scope in out of scope for this document.
        </t>
        <t>
     Note: multiple Multiple network failures can impact the POF function
	 (e.g., complete outage of all redundant paths).
        </t>

        <t>
     The basic POF algorithm increases the delay of packets with maximum
	 "POFMaxDelay" time. Packets being in order In-order packets are not delayed. This basic
	 POF method can be applied in all network scenarios where the remaining
	 delay budget of a flow at the POF point is larger than "POFMaxDelay"
	 time.
        </t>

        <t>
     <xref target="delay-budget"/> target="delay-budget" format="default"/> shows the delay budget relations
     situation at the POF point.
        </t>
        <figure title="Delay anchor="delay-budget">
          <name>Delay Budget Relations Situation at the POF Point" anchor="delay-budget"> Point</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
                          Path delay
                          difference
                        /-------------/
<- path with min delay ->             /-- remaining delay budget --/

|-----------------------|-------------|----------------------------|
0                       t1            t2                           T

<-------- path with max delay -------->

/-------------------- delay budget at POF point -------------------/

]]>
 </artwork></figure>
]]></artwork>
        </figure>
      </section>  <!-- end of basic POF -->

 <section anchor="adv-pof" title="The numbered="true" toc="default">
        <name>The Advanced POF Algorithm"> Algorithm</name>
        <t>
     In network scenario scenarios where the remaining delay budget of a flow at the
	 POF point is smaller than "POFMaxDelay" time time, the basic method needs
	 extensions.
        </t>
        <t>
     The issue is that packets on the longest path cannot be buffered in order
	 to keep the delay budget of the flow. It must be noted that such a packet
	 (i.e., forwarded over the longest path) needs no buffering as it is the
	 "last chance"
	 last chance to deliver a packet with a given sequence number. This is
	 because all replicas are already arrived via a shorter path(s).
        </t>

        <t>
The advanced POF algorithm needs two requires extensions of the basic POF algorithm:
	 <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>to identify the received packet's path at the POF location and </t>
          </li>
          <li>
            <t>to make the value of "POFMaxDelay" for buffered packets path
		 dependent ("POFMaxDelay_i", where "i" notes the path the packet
		 has used). </t>
	 </list>
  </t>
          </li>
        </ul>
        <t>
     By identifying
  The advanced POF algorithm identifies the path of a given packet, the POF algorithm can use packet and uses this
  information to select what the predefined time "POFMaxDelay_i" ("POFMaxDelay_i") to apply for the
  buffered packet.  So, in the advanced POF algorithm algorithm, "POFMaxDelay" is an array,
  array that contains the predefined and path specific path-specific buffering time for each
  redundant path of a flow. Values in the "POFMaxDelay" array are engineered
  to fulfill the delay budget requirement.
        </t>
        <t>
     Design of these parameters is out-of-scope in out of scope for this document.
        </t>
        <t>
     Note: for For the "Advanced advanced POF Algorithm" algorithm, the path dependent path-dependent delays
	 might result in multiple packets triggering the "maximum delay
	 reached" at exactly the same time. The transmission order of
	 these packets then should be done in their seq_num order.
        </t>

        <t>
     The method for identification of identifying the packet's path at the POF location
     depends on the network scenario.
  It can be implemented via
  various techniques, for example example, using ingress interface information,
  encoding the path in the packet itself (e.g., replication functions can
  set a different FlowID per member flow at their egress what can be and such
  a FlowID is used as to identify the path of a PathID), packet at the POF), or in
  other means. Method
     Methods for identification of identifying the packet's path is are out of scope
	 in
	 for this document.
        </t>
        <t>
     Note: in case of When using the advanced POF algorithm algorithm, it might be
	 advantageous to combine PEF and POF locations in the DetNet network, as
	 it
	 this can simplify the method used for identification of identifying the packet's path
	 at the POF location.
        </t>
      </section>  <!-- end of advanced POF -->

 <section anchor="enh-pof" title="Further enhancements numbered="true" toc="default">
        <name>Further Enhancements of the POF algorithms"> Algorithms</name>

        <t>
     POF algorithms can be further enhanced by distinguishing the case of
	 initialization from normal operation at the price of more states and
	 more sophisticated implementation. Such enhancements could could, for example example,
	 react better after some failure scenarios (e.g., complete outage of all
	 paths of a DetNet flow) and can be dependent on the PEF implementation.
        </t>

        <t>
  The challenge for POF initialization is that for example after a reset it is not known whether the
  first received packet is in-order or
	 out-of-order. out-of-order (for example, after a
  reset).

  The original initialization (see before) <xref target="basic-pof"/>) considers the
	 first packet as in-order, so out-of-order packet(s) during
	 "POFMaxTime"/"POFMaxTime_path_i" time - -- after the first packet was is
	 received - -- cannot be corrected. Motivation

	 The motivation behind such an initialization
	 is simplicity of POF implementation simplicity. implementation.
        </t>
        <t>
     A possible enhancement of POF initialization works as follows:
	 <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>After a reset reset, all received packets are buffered with their
		 predefined timer ("POFMaxTime"/"POFMaxTime_path_i"). </t>
          </li>
          <li>
            <t>No basic/advanced basic or advanced POF rules are applied until the first timer
		 expires. </t>
          </li>
          <li>
            <t>When the first timer expires expires, the packet with lowest seq_num in the
		 buffer is selected, selected and forwarded, and "POFLastSent" is set with its
		 seq_num.</t>
          </li>
          <li>
            <t>The basic/advanced basic or advanced POF rules are applied for the packet(s) in the
		 buffer and the subsequently received packets.</t>
	 </list>
  </t>
          </li>
        </ul>
      </section>  <!-- end of POF enhancement -->

 <section anchor="select-pof" title="Selecting numbered="true" toc="default">
        <name>Selecting and using Using the POF algorithm"> Algorithms</name>
        <t>
     The selection of the POF algorithm depends on the network scenario and
	 the remaining delay budget of a flow. Using the POF algorithms and calculating its their
	 parameters require proper design. Knowing the path delay difference is
	 essential for the POF algorithms described here. Failure scenarios
	 breaking the design assumptions can impact the result of the POF (e.g.,
	 packet received out of the expected worst-case delay window
	 -
	 -- calculated based on the path delay difference - -- can result in unwanted
	 out-of-order delivery).
        </t>
        <t>
     In DetNet scenarios scenarios, there is always an Elimination elimination function before the
     POF
	 (therefore (therefore, duplicates are not considered by the POF). Implementing
     them together in the same node allows the POF to consider PEF events/states
     during the re-ordering. reordering. For example, under normal circumstances circumstances, the
     difference of between sequence number numbers in consecutive packets is bounded due
     to the history window of the PEF.  However, in some scenarios (e.g., reset of
     sequence
	 number) number), the difference can be much larger than the size of the
     history window size. window.
        </t>
      </section>  <!-- end of POF selection -->
</section>  <!-- end of POF algorithms -->

<section anchor="ctrl-mngmnt-pof" title="Control numbered="true" toc="default">
      <name>Control and Management Plane Parameters for POF">
  <t>
     POF POF</name>

      <t>POF algorithms needs setting of require the following parameters:
	 <list style="symbols"> parameters to be set:
      </t>
      <ul spacing="normal">
        <li>
          <t>Basic POF
		 <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>"POFMaxDelay" </t>
            </li>
            <li>
              <t>"POFTakeAnyTime" </t>
		 </list>
		 </t>
            </li>
          </ul>
        </li>
        <li>
          <t>Advanced POF
		 <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>"POFMaxDelay_i" for each possible path i </t>
            </li>
            <li>
              <t>"POFTakeAnyTime" </t>
			<t>Network path identification
            </li>
            <li>
              <t>Configuration(s) related configuration(s) </t>
		 </list>
		 </t>
	 </list>
  </t> to network path identification</t>
            </li>
          </ul>
        </li>
      </ul>
      <t>
     Note, that in
     Note: In a proper design design, "POFTakeAnyTime" is always larger than "POFMaxDelay".
      </t>
    </section>  <!-- end of POF management -->

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

<section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
     PREOF related
     PREOF-related security considerations (including POF) are described in
	 section 3.3 of
     <xref target="RFC9055"/>. target="RFC9055" sectionFormat="of" section="3.3"/>. There are no
     additional POF
	 related POF-related security considerations originating from this
     document.
      </t>
    </section>
    <section anchor="iana" title="IANA Considerations">
  <t>
   This 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 Gyorgy Miklos, Mohammadpour Ehsan, Ludovic Thomas,
   Greg Mirsky, Jeong-dong Ryoo, Shirley Yangfan, Toerless Eckert, Norman Finn and Ethan
   Grossman 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.9055"?>
    <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.9055.xml"/>
      </references>
  <references title="Informative References">
      <references>
        <name>Informative References</name>

        <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
            </title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date month="October" year="2017"/>
          </front>
	  <seriesInfo name="DOI" value="10.1109/IEEESTD.2017.8091139" name='IEEE Std' value='802.1CB-2017' />
          <seriesInfo name="DOI" 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"> target="https://standards.ieee.org/ieee/802.1CBcv/7285/">
          <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> Module
	    </title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date month="March" year="2021"/> month="February" year="2022"/>
          </front>
          <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-2001"/>
	  <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="Gyorgy Miklos"/>,
   <contact fullname="Ehsan Mohammadpour"/>, <contact fullname="Ludovic
   Thomas"/>, <contact fullname="Greg Mirsky"/>, <contact fullname="Jeong-dong
   Ryoo"/>, <contact fullname="Fan Yang"/>, <contact fullname="Toerless
   Eckert"/>, <contact fullname="Norman Finn"/>, and <contact fullname="Ethan
   Grossman"/> for their insightful comments and productive discussion that
   helped to improve the document.
      </t>
    </section>

  </back>
</rfc>