<?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>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

<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
	 described herein in this document enables to restore restoration of the correct packet order when the
	 replication and elimination functions are used in DetNet networks.
	 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">
  <t> anchor="sec_intro" numbered="true" toc="default">
      <name>Introduction</name>

<!-- [rfced] Would it be helpful to revise this sentence to state that
"[RFC8655] defines" rather than "The DetNet Working Group has defined"?
In addition, please clarify "but without any implementation details" in
the second sentence below.

Original:
   The DetNet Working Group has defined packet replication (PRF) and
   packet elimination (PEF) functions for achieving extremely low packet
   loss.  PRF and PEF are described in [RFC8655] and provide service
   protection for DetNet flows.
   ...
   The IETF DetNet WG has defined
   in [RFC8655] the external observable result of a POF function, i.e.,
   that packets are reordered, but without any implementation details.

Perhaps:
   [RFC8655] defines the Packet Replication Function
   (PRF) and Packet Elimination Function (PEF) in DetNet for achieving extremely
   low packet loss. PRF and PEF provide service protection for DetNet flows.
   ...
   [RFC8655] defines the external observable result of a POF
   function (i.e., that packets are reordered) but does not specify any implementation
   details.
-->

      <t>
     The DetNet Working Group has defined the Packet Replication Function (PRF) and Packet
	 Elimination Function (PEF) for achieving extremely low packet loss. PRF and
	 PEF are described in <xref target="RFC8655"/> target="RFC8655" format="default"/> 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 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 in this document. In <xref target="RFC8655" format="default"/>, the IETF DetNet WG has Working Group defined in <xref target="RFC8655"/>
	 the external observable result of a POF function, i.e., function (i.e., that packets are
	 reordered,
	 reordered), but without 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>
<!-- [rfced] Please confirm that [RFC8655] is correct here. We believe it is
correct, but we want to make sure. We see "sequence number" and
"encapsulation" in RFC 8655 but not used together.

Original:
   This can be
   done by adding a sequence number as part of DetNet encapsulation
   [RFC8655].
-->

      <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>
<!-- [rfced] Are the parentheses needed here with "DetNet"?

Original:
   POF ensures in-order delivery for packets being within the latency bound of
   the (DetNet) flow.

Perhaps:
   POF ensures in-order delivery for packets within the latency bound of
   the DetNet flow.
-->

      <t>
     POF ensures in-order delivery for packets within
	 the latency bound of the (DetNet) flow. 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> Function</dd>
        </dl>
      </section>

</section>

<!--

<section title="Requirements Language">
  <t> anchor="req-on-pof" numbered="true" toc="default">
<!-- [rfced] The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
    "OPTIONAL" title of Section 3 uses "POF Implementations", but the first
sentence in this document are to the section uses "POF function". Should these 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 consistent?

Original:
   3.  Requirements on POF Implementations">
  <t> Implementations

      The requirements on a POF function are:
	 <list style="symbols">
         <t>to

Perhaps:
   3.  Requirements for POF Implementations

      The requirements for POF implementations are:
-->

  <name>Requirements for POF Implementations</name>
      <t>
     The requirements for a POF function are:
      </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>
<!-- [rfced] Would moving "in network nodes" to the end of the sentence
improve readability? Also, please review "states/configuration parameters
and resources". Specifically, is "states" separate from "configuration
parameters", or does "states/configuration" describe the type of
parameters?

Original:
   *  to be simple and to require in network nodes only a minimum set of
      states/configuration parameters and resources per DetNet Flow.

Perhaps:
   *  To be simple and to require only a minimum set of
      states, configuration parameters, and resources per DetNet flow in network nodes.

Or ("states" to "state"):
   *  To be simple and to require only a minimum set of
      state/configuration parameters and resources per DetNet flow in network nodes.
-->

          <t>To be simple and to require, in network nodes, only a minimum
		 set of state/configuration parameters and resources per DetNet
		 flow. </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
      </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>
        </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 algorithm discussed in this document makes some assumptions and
        tradeoffs
        trade-offs regarding the characteristics of the sequence of received
        packets. In particular, the algorithm assumes that a Packet
        Elimination Function (PEF)
        PEF is performed on the incoming packets
        before they are handed to the POF function. 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 further requires 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 also makes 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 POF for DetNet networks. The
	 configuration parameters of 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>
<!-- [rfced] The text above Figure 2 uses "Conditional buffer", but Figure 2
uses "Conditional Delay Buffer". Should the figure be updated for
consistency with the text or vice versa?
-->

	<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 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 buffer of 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) 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) 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). </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>
          </li>
        </ul>
<!-- [rfced] Please review "the difference of sequence number" in these
sentences. Is the intended meaning "the difference between sequence
numbers"?

Original:
   Note: the difference of sequence number in consecutive packets is
   bounded due to the history window of the Elimination function before
   the POF.
	 Therefore "&#60;="
   ...
   For example, under normal
   circumstances the difference of sequence number in consecutive
   packets is bounded due to the history window of PEF.

Perhaps:
   The difference between sequence numbers in consecutive packets is
   bounded due to the history window of the elimination function
   before the POF.
   ...
   For example, under normal
   circumstances, the difference between sequence numbers in consecutive
   packets is bounded due to the history window of PEF.
-->

<t>Notes:</t>
<ul spacing="normal">
<li>The difference of sequence number in consecutive packets is bounded
	 due to the history window of the elimination function before the POF.
	 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 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
		 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 POF erases all packets from the time-based
		 buffer used by 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>
<!-- [rfced] We updated "Packets being in order" as shown below. Please review.

Original:
   Packets being in order are not delayed.

Updated:
   In-order packets are not delayed.
-->

        <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>
<!-- [rfced] Please confirm that "relations" is the correct word choice here.

Original:
   Figure 3 shows the delay budget relations at the POF point.
   ...
   Figure 3: Delay Budget Relations at the POF Point

Perhaps:
   Figure 3 shows the relationship between delay budgets at the POF point.
   ...
   Figure 3: Relationship between Delay Budgets at the POF Point
-->

        <t>
     <xref target="delay-budget"/> target="delay-budget" format="default"/> shows the delay budget relations at
	 the POF point.
        </t>
        <figure title="Delay anchor="delay-budget">
          <name>Delay Budget Relations 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>
<!-- [rfced] In the text introducing the list, may we update "needs two
extensions of" in one of the following ways to improve clarity?

Original:
   The advanced POF algorithm needs two extensions of the basic POF
   algorithm:

   *  to identify the received packet's path at the POF location and

   *  to make the value of "POFMaxDelay" for buffered packets path
      dependent ("POFMaxDelay_i", where "i" notes the path the packet
      has used).

Perhaps:
   The advanced POF algorithm extends the basic POF
   algorithm:

   *  to identify the received packet's path at the POF location and

   *  to make the value of "POFMaxDelay" for buffered packets path
      dependent ("POFMaxDelay_i", where "i" notes the path the packet
      has used).

Or:
   The advanced POF algorithm requires extensions of the basic POF
   algorithm:

   *  to identify the received packet's path at the POF location and

   *  to make the value of "POFMaxDelay" for buffered packets path
      dependent ("POFMaxDelay_i", where "i" notes the path the packet
      has used).
-->

        <t>
     The advanced POF algorithm needs two 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>
<!-- [rfced] How may we clarify the beginning of this sentence (i.e.,
"By....information")? Also, should "POFMaxDelay_i" appear in parentheses?

Original:
   By identifying the path of a given packet, the POF algorithm can use
   this information to select what predefined time "POFMaxDelay_i" to
   apply for the buffered packet.

Perhaps:
   The POF algorithm identifies the path of a given packet and uses
   this information to select the predefined time ("POFMaxDelay_i") to
   apply for the buffered packet.
-->

        <t>
     By identifying the path of a given packet, the POF algorithm can use this
	 information to select what predefined time "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>
<!-- [rfced] We are having trouble understanding the text in the parenthetical
(i.e., "e.g., replication...PathID"). Please clarify.

Original:
   It can be implemented via
   various techniques, for example using ingress interface information,
   encoding the path in the packet itself (e.g., replication functions
   can set different FlowID per egress what can be used as a PathID), or
   in other means.

Perhaps:
   It can be implemented via
   various techniques, for example, using ingress interface information,
   encoding the path in the packet itself (e.g., replication functions
   can set a different FlowID per egress, which can be used as a PathID), or
   other means.
-->

        <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
	 different FlowID per egress what can be used as a PathID), 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 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>
<!-- [rfced] Please review "for example" here. Is it needed, or would it be
more clear if placed elsewhere in the sentence?

Original:
   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.

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

<!-- [rfced] Should "(see before)" be updated to a specific section? If not,
we will update to "(see above)".

Original:
   The original initialization (see before) considers
   the first packet as in-order, so out-of-order packet(s) during
   "POFMaxTime"/"POFMaxTime_path_i" time - after the first packet was
   received - cannot be corrected. Motivation
-->

        <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. The original initialization (see before) considers the
	 first packet as in-order, so out-of-order packet(s) during
	 "POFMaxTime"/"POFMaxTime_path_i" time -- after the first packet is
	 received -- cannot be corrected. 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>
<!-- [rfced] Will "basic/advanced" be clear to readers?

Original:
   *  No basic/advanced POF rules are applied until the first timer
      expires.
      ...
   *  The basic/advanced POF rules are applied for the packet(s) in the
      buffer and the subsequently received packets.

Perhaps:
   *  No basic or advanced POF rules are applied until the first timer
      expires.
      ...
   *  The basic or advanced POF rules are applied for the packet(s) in the
      buffer and the subsequently received packets.
-->

        <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 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 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"> Algorithm</name>
        <t>
     The selection of the POF algorithm depends on the network scenario and
	 the remaining delay budget of a flow. Using POF and calculating its
	 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 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 POF to consider PEF events/states during
	 the re-ordering. reordering. For example, under normal circumstances circumstances, the difference of
	 sequence number in consecutive packets is bounded due to the history
	 window of 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</name>

<!-- [rfced] How may we update "needs setting of" in this sentence?

Original:
   POF algorithms needs setting of the following parameters:
	 <list style="symbols">

Perhaps:
   The following parameters should be set for POF algorithms:

Or:
   POF algorithms require the following parameters to be set:
-->

      <t>
     POF algorithms need setting of the following parameters:
      </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>

<!-- [rfced] We tried to access the URL in this reference entry, but it is
behind a sign-in wall. Also, it looks like this reference entry points to
a draft that has now been published. May use one of the following URLs
and update the rest of the entry accordingly (e.g., title, DOI, and
date)?

Possible URLs:
https://standards.ieee.org/ieee/802.1CBcv/7285/
https://ieeexplore.ieee.org/document/9715061

Original:
   [IEEEP8021CBcv]
              Kehrer, S., "FRER YANG Data Model and Management
              Information Base Module", IEEE P802.1CBcv
              /D1.2 P802.1CBcv, March 2021,
              <https://www.ieee802.org/1/files/private/cv-drafts/d1/802-
              1CBcv-d1-2.pdf>.

Perhaps:
   [IEEEP8021CBcv]
             IEEE, "IEEE Standard for Local and metropolitan area networks - Frame
             Replication and Elimination for Reliability - Amendment 1: Information
	     Model, YANG Data Model, and Management Information Base Module,
             IEEE Std 802.1CBcv-2001, DOI 10.1109/IEEESTD.2022.9715061, February 2022,
             <https://standards.ieee.org/ieee/802.1CBcv/7285/>.
-->
<reference anchor="IEEEP8021CBcv" target="https://www.ieee802.org/1/files/private/cv-drafts/d1/802-1CBcv-d1-2.pdf">
          <front>
            <title>FRER YANG Data Model and Management Information Base Module</title>
            <author initials="S." surname="Kehrer" fullname="Stephan Kehrer">
              <organization>IEEE 802.1</organization>
            </author>
            <date month="March" year="2021"/>
          </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"/>
        </reference>
      </references>
    </references>
    <section anchor="acks" numbered="false" toc="default">
      <name>Acknowledgements</name>
<!-- [rfced] We updated these names in the Acknowledgements section. Please
review and let us know any concerns.

a) Per https://datatracker.ietf.org/person/ehsan.mohammadpour@swisscom.com:

Original:
  Mohammadpour Ehsan

Updated:
  Ehsan Mohammadpour

b) Per https://datatracker.ietf.org/person/shirley.yangfan@huawei.com:

Original:
  Shirley Yangfan

Updated:
  Fan Yang
-->

      <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>

<!-- [rfced] Should "algorithm" be updated to "algorithms" (plural) in the
following sentences as both a basic and advanced POF algorithm are
defined in Section 4? Or in some of these instances (perhaps the last two
below), is the intent to say "the basic POF algorithm" or "the advanced
POF algorithm"?

Original:
   The Packet Ordering Function (POF)
   algorithm described herein enables to restore the correct packet
   order when replication and elimination functions are used in DetNet
   networks.
   ...
   4.6.  Selecting and using the POF algorithm
   ...
   The POF Algorithm discussed in this document makes some assumptions
   and tradeoffs regarding the characteristics of the sequence of
   received packets.
   ...
   In particular, the algorithm assumes that a Packet
   Elimination Function (PEF) is performed on the incoming packets
   before they are handed to the POF function.
   ...
   The algorithm further requires that the delay difference between two
   replicated packets that arrive at the PEF before the POF is bounded
   and known.
   ...
   The algorithm also makes some tradeoffs.
   ...
   Note2: The algorithm can be extended to cope with multiple failure
   scenarios (i.e., simultaneous packet loss and out-of-order packets), ...
   ...
   By identifying the path of a given packet, the POF algorithm can use
   this information to select what predefined time "POFMaxDelay_i" to
   apply for the buffered packet.
-->

<!-- [rfced] Terminology

a) We see inconsistency in the capitalization of the following. We updated to
use the lowercase form. Please let us know any objections.

Replication and Elimination function
replication and elimination functions
replication function
Elimination function

b) Should "function" be removed in these instances because the expansion of
the acronym already includes the word "Function"? For example, if expanded,
"POF function" would read "Packet Ordering Function function".

PEF function
POF function
PREOF functions

c) Use of quotation marks for the following terms is inconsistent. Please
review and let us know how to update for consistency.

"POFLastSent" vs. POFLastSent

"POFMaxDelay" vs. POFMaxDelay

"POFMaxDelay_i"

"POFMaxTime"/"POFMaxTime_path_i"

"POFTakeAnyTime"

d) Please review the usage of the articles "a" or "the" with PEF, PRF, and POF
when used as a noun. An article is used in some instances but not others. Are
any updates needed, or is the current usage acceptable? This may be on a
case-by-case basis. A few examples with and without the article are listed
below.

Some examples with article (the POF, the POF, the PEF):

   Note: the difference of sequence number in consecutive packets is
   bounded due to the history window of the Elimination function before
   the POF.

   Error cases in which duplicate packets are
   presented to the POF can lead to out of order delivery of duplicate
   packets as well as to increased delays.

   The algorithm further requires that the delay difference between two
   replicated packets that arrive at the PEF before the POF is bounded
   and known.

Some examples with no article (PEF, POF, POF):

   For example, under normal
   circumstances the difference of sequence number in consecutive
   packets is bounded due to the history window of PEF.

   POF only provides ordering within the latency bound of a
   DetNet flow, and does not provide any additional reliability.

   POF ensures in-order delivery for packets being within the latency
   bound of the (DetNet) flow.  POF does not correct errors in the
   packet flow e.g., duplicate packets, too late packets.
-->

<!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Note that our script did not
flag any words in particular, but this should still be reviewed as a best
practice.
-->

  </back>
</rfc>