<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info"
     docName="draft-ietf-detnet-pof-09"
         ipr="trust200902"
         submissionType="IETF">
  <front>
    <title abbrev="DetNet POF">
    Deterministic Networking (DetNet): Packet Ordering Function</title>

  <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 />
  <workgroup>DetNet</workgroup>

  <abstract>
   <t>
     Replication and Elimination functions of 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 enables to restore the correct packet order when
	 replication and elimination functions are used in DetNet networks.
   </t>
  </abstract>
  </front>

 <middle>
 <section title="Introduction" anchor="sec_intro">
  <t>
     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 <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 PRF and PEF functions is described in 
	 <xref target="IEEE8021CB"/> and the related YANG model is defined 
	 in <xref target="IEEEP8021CBcv"/>.
  </t>
  <t>
     In general, use of 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 details of a Packet Ordering Function (POF) are 
	 specified herein. The IETF DetNet WG has defined in <xref target="RFC8655"/> 
	 the external observable result of a POF function, i.e., that packets are 
	 reordered, but without any implementation details. 
  </t>
  <t>
     So far in packet networks, out-of-order delivery situations were handled 
	 at higher OSI layers at the end-points/hosts (e.g., in the TCP stack when 
	 packets are sent to application layer) and not within a network in nodes 
	 acting at the Layer-2 or Layer-3 OSI layers. 
  </t>
  <t>
     <xref target="PREOF-scene"/> shows a DetNet flow on which packet 
	 replication, elimination and ordering (PREOF) functions 
	 are applied during forwarding from source to destination. 
  </t>  

 <figure title="PREOF scenario in a DetNet network" anchor="PREOF-scene">
 <artwork align="center"><![CDATA[

                                    +------------+
             +-----------E1----+    |            |
+----+       |            |    +---R3---+        |          +----+
|src |------R1        +---+             |        E3----O1---+ dst|
+----+       |        |                 E2-------+          +----+
             +-------R2                 |
                      +-----------------+

R: replication point (PRF)
E: elimination point (PEF)
O: ordering function (POF)
]]>
 </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 as part of DetNet encapsulation 
    <xref target="RFC8655"/>. Sequencing information is typically added once, 
	at or close to the source.
  </t>
  <t>
     Important to note that different applications can react differently to out-of-order 
	 delivery. A single out-of-order packet (E.g., packet order: #1, #3, #2, 
	 #4, #5) is interpreted by some application as a single error, but 
	 some other applications treat it as 3 errors in-a-row situation. 
	 For example, in industrial scenarios 
	 3 errors in-a-row is a usual error threshold and can cause the 
	 application to stop (e.g., to go to a fail-safe state).
  </t>
  <t>
     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.
  </t>
  
</section> <!-- end of introduction -->

<section title="Terminology">
 <section title="Terms Used in This Document">
  <t>
   This document uses the terminology established in the DetNet architecture
   <xref target="RFC8655"/>, and the reader is assumed
   to be familiar with that document and its terminology.
  </t>
 </section>

 <section title="Abbreviations">
  <t>
   The following abbreviations are used in this document:
   <list style="hanging" hangIndent="14">
    <t hangText="DetNet">Deterministic Networking.</t>
    <t hangText="PEF">Packet Elimination Function.</t>
    <t hangText="POF">Packet Ordering Function.</t>
	<t hangText="PREOF">Packet Replication, Elimination and Ordering Functions.</t>
    <t hangText="PRF">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>
 </section>
--> 
 
</section>  <!-- end of terminology -->

<!-- ===================================================================== -->

<section anchor="req-on-pof" title="Requirements on POF Implementations">
  <t>
     The requirements on a POF function are: 
	 <list style="symbols">
         <t>to solve the out-of-order delivery problem of the Replication 
		 and Elimination functions of DetNet networks. </t>
         <t>to consider the delay bound requirement of a DetNet Flow. </t>
         <t>to be simple and to require in network nodes only a minimum 
		 set of states/configuration parameters and resources per DetNet 
		 Flow. </t>
		 <t>to add only minimal or no delay to the forwarding process 
		 of packets. </t>
		 <t>not to require synchronization between PREOF nodes. </t>
     </list>
  </t>
  <t>
     Some aspects are explicitly out-of-scope for a POF function: 
	 <list style="symbols">
         <t>to eliminate the delay variation caused by the packet ordering. 
		 Dealing with delay variation is a DetNet forwarding sub-layer target 
		 and it can be achieved for example by placing a de-jitter buffer 
		 or flow regulator (e.g., shaping) function after the POF 
		 functionality.</t>
     </list>
  </t>
</section>  <!-- end of requirements -->


<section anchor="pof-alg" title="POF Algorithms">
 <section anchor="preof-relations" title="Prerequisites and Assumptions"> 
    <t>
        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. Hence, the sequence
        of incoming packets can be 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 the
        POF is presented duplicate packets can lead to out of order delivery
        of duplicate packets as well as 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 packets.
    </t>
    <t>
        The algorithm also makes some tradeoffs. For simplicity, it is designed
        in a way that allows for some out of order packets directly after
        initialization. If this is not acceptable, 
		<xref target="enh-pof"/> 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">
  <t>
     The method described herein provides POF for DetNet networks. The 
	 configuration parameters of POF can be derived during engineering the 
	 DetNet flow through the network.
  </t>
  <t>
     The POF method is provided via: 
	 <list style="numbers">
		 <t>Delay calculator: 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: for buffering the out-of-order packets of a 
		 DetNet flow for a given time. </t>
     </list>  
  </t>  
  <t>
     Note: the conditional buffer of POF increases the burstiness of the 
	 traffic as it adds delay only for some of the packets. 
  </t>
  <t>
     <xref target="POF-blocks"/> shows the building blocks of a 
	 possible POF implementation. 
  </t>  

 <figure title="POF Building Blocks" anchor="POF-blocks">
 <artwork align="center"><![CDATA[

               +------------+        +--------------+
               | Delay calc |        | Conditional  |
            +--| for packet >--->>---| Delay Buffer >--+
            |  +------------+        +--------------+  |  
            |                                          |        
     +------^--------+                                 |
->>--| POF selector  >---------------------------------+-->>----  
     | (Flow ident.) |
     +---------------+

->>- packet flow

]]>
 </artwork></figure>

 </section>  <!-- end of POF blocks -->

 <section anchor="basic-pof" title="The Basic POF Algorithm">
  <t>
     The basic POF algorithm delays all out-of-order packets until all 
	 previous packet arrives or a given time (POFMaxDelay) elapses. The 
	 basic POF algorithm works as follows:
	 <list style="symbols">
         <t>The sequence number of the last forwarded packet (POFLastSent) is 
		 stored for each DetNet Flow. </t>
		 <t>The sequence number (seq_num) of a received packet is compared to 
		 that of the last forwarded one (POFLastSent). </t>
		 <t>If (seq_num &#60;= POFLastSent + 1)
			<list style="symbols">
		    <t> Then the packet is forwarded without buffering and "POFLastSent"
				is updated (POFLastSent = seq_num). </t>
			<t> Else the received packet is buffered. </t>
			</list>  
		 </t>
		 <t>A buffered packet is forwarded from the buffer when its seq_num 
		 becomes equal to "POFLastSent +1," OR a predefined time ("POFMaxDelay") 
		 elapses.</t>
		 <t>When a packet is forwarded from the buffer "POFLastSent" is 
		 updated with its seq_num (POFLastSent = seq_num). </t>
	 </list>  
  </t>
  <t>
     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;="  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 described in <xref target="IEEE8021CB"/>. 
  </t>
  <t>
	 Note2: The algorithm can be extended to cope with multiple failure scenarios 
	 (i.e., simultaneous packet loss and out-of-order packets), when the expiration 
	 of the timer for a packet with sequence number N trigger the release of some 
	 number of packets with sequence number smaller than N.
  </t>
  <t>
     The state used by the basic POF algorithm (i.e., "POFLastSent") needs 
	 initialization and maintenance. This works as follows:
	 <list style="symbols">
         <t>The next received packet is forwarded and the POFLastSent 
		 updated when the POF function was reset OR no packet was received 
		 for a predefined time ("POFTakeAnyTime"). </t>
		 <t>The reset of POF erases all packets from the time-based 
		 buffer used by POF. </t>
	 </list>  
  </t>
  <t>
     The basic POF algorithm has two parameters to engineer:
	 <list style="symbols">
         <t>"POFMaxDelay", which cannot be smaller than the delay 
		 difference of the paths used by the flow. </t>
		 <t>"POFTakeAnyTime", which is calculated based on several factors, 
		 for example the RECOVERY_TIMEOUT related settings of the 
		 Elimination function(s) before the POF, the flow characteristics 
		 (e.g., inter packet time), and the delay difference of the 
		 paths used by the flow.  </t>
	 </list>  
  </t>  
  <t>
     Design of these parameters is out-of-scope in this document.
  </t>
  <t>
     Note: 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 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"/> shows the delay budget relations at 
	 the POF point.
  </t>
 <figure title="Delay Budget Relations at the POF Point" anchor="delay-budget">
 <artwork align="center"><![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>
  
 </section>  <!-- end of basic POF -->

 <section anchor="adv-pof" title="The Advanced POF Algorithm">
 
  <t>
     In network scenario where the remaining delay budget of a flow at the 
	 POF point is smaller than "POFMaxDelay" time the basic method needs 
	 extensions. 
  </t>
  <t>
     The issue is that packets on the longest path cannot be buffered in order 
	 to keep 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" to deliver a packet with a given sequence number. This is 
	 because all replicas are already arrived via shorter path(s).
  </t>
  <t>
     The advanced POF algorithm needs two extensions of the basic POF 
	 algorithm:
	 <list style="symbols">
         <t>to identify the received packet's path at the POF location and </t>
		 <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>
  <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 "POFMaxDelay" 
	 is an array, that contains the predefined and 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 this document.
  </t>
  <t>
     Note: for the "Advanced POF Algorithm" the 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 the packet's path at the POF location 
	 depends on the network scenario. 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. Method for identification of the packet's path is out of scope 
	 in this document.
  </t>
  <t>
     Note: in case of using the advanced POF algorithm it might be 
	 advantageous to combine PEF and POF locations in the DetNet network, as 
	 it can simplify the method used for identification of the packet's path 
	 at the POF location.
  </t>
 </section>  <!-- end of advanced POF -->

 <section anchor="enh-pof" title="Further enhancements of POF algorithms">
  <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 for 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. 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 behind such an initialization 
	 is POF implementation simplicity.
  </t>
  <t>
     A possible enhancement of POF initialization works as follows:
	 <list style="symbols">
         <t>After a reset all received packets are buffered with their 
		 predefined timer ("POFMaxTime"/"POFMaxTime_path_i"). </t>
		 <t>No basic/advanced POF rules are applied until the first timer 
		 expires. </t>
		 <t>When the first timer expires the packet with lowest seq_num in 
		 buffer is selected, forwarded, and "POFLastSent" is set with its 
		 seq_num.</t>
		 <t>The basic/advanced POF rules are applied for the packet(s) in the 
		 buffer and the subsequently received packets.</t>
	 </list>  
  </t>
 </section>  <!-- end of POF enhancement -->

 <section anchor="select-pof" title="Selecting and using the POF algorithm">
  <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 there is always an Elimination function before the POF
	 (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. For example, under normal 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) the difference can be much larger than the history window size. 
  </t>
 </section>  <!-- end of POF selection -->

</section>  <!-- end of POF algorithms -->


<section anchor="ctrl-mngmnt-pof" title="Control and Management Plane Parameters for POF">
  <t>
     POF algorithms needs setting of the following parameters:
	 <list style="symbols">
         <t>Basic POF
		 <list style="symbols">
			<t>"POFMaxDelay" </t>
			<t>"POFTakeAnyTime" </t>
		 </list>  
		 </t>
		 <t>Advanced POF 
		 <list style="symbols">
			<t>"POFMaxDelay_i" for each possible path i </t>
			<t>"POFTakeAnyTime" </t>
			<t>Network path identification related configuration(s) </t>
		 </list>  
		 </t>
	 </list>  
  </t>
  <t>
     Note, that in a proper design "POFTakeAnyTime" is always larger 
	 than "POFMaxDelay". 
  </t>
 </section>  <!-- end of POF management -->


<!-- ===================================================================== -->


<section title="Security Considerations">
  <t>
     PREOF related security considerations (including POF) are described in 
	 section 3.3 of <xref target="RFC9055"/>. There are no additional POF 
	 related security considerations originating from this document.
  </t>
</section>


<section anchor="iana" title="IANA Considerations">
  <t>
   This document makes 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.
  </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>
  <references title="Informative References">
   <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" />
   </reference>
   <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>
 </back>
</rfc>
