rfc9550xml2.original.xml   rfc9550.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
<?rfc symrefs="yes"?> category="info"
<?rfc sortrefs="yes"?> docName="draft-ietf-detnet-pof-11"
<?rfc iprnotified="no"?> number="9550"
<?rfc strict="yes"?> ipr="trust200902"
<?rfc compact="yes"?> submissionType="IETF"
<?rfc subcompact="no"?> consensus="true"
<rfc category="info" obsoletes=""
docName="draft-ietf-detnet-pof-11" updates=""
ipr="trust200902" xml:lang="en"
submissionType="IETF"> 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> <front>
<title abbrev="DetNet POF"> <title abbrev="DetNet POF">
Deterministic Networking (DetNet): Packet Ordering Function</title> Deterministic Networking (DetNet): Packet Ordering Function</title>
<seriesInfo name="RFC" value="9550"/>
<author role="editor" fullname="Balazs Varga" initials="B." surname="Varga"> <author role="editor" fullname="Balazs Varga" initials="B." surname="Varga">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Magyar Tudosok krt. 11.</street> <street>Magyar Tudosok krt. 11.</street>
<city>Budapest</city> <city>Budapest</city>
<country>Hungary</country> <country>Hungary</country>
<code>1117</code> <code>1117</code>
</postal> </postal>
<email>balazs.a.varga@ericsson.com</email> <email>balazs.a.varga@ericsson.com</email>
</address> </address>
</author> </author>
<author fullname="Janos Farkas" initials="J." surname="Farkas"> <author fullname="Janos Farkas" initials="J." surname="Farkas">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Magyar Tudosok krt. 11.</street> <street>Magyar Tudosok krt. 11.</street>
<city>Budapest</city> <city>Budapest</city>
<country>Hungary</country> <country>Hungary</country>
<code>1117</code> <code>1117</code>
</postal> </postal>
<email>janos.farkas@ericsson.com</email> <email>janos.farkas@ericsson.com</email>
skipping to change at line 45 skipping to change at line 60
<address> <address>
<postal> <postal>
<street>Magyar Tudosok krt. 11.</street> <street>Magyar Tudosok krt. 11.</street>
<city>Budapest</city> <city>Budapest</city>
<country>Hungary</country> <country>Hungary</country>
<code>1117</code> <code>1117</code>
</postal> </postal>
<email>janos.farkas@ericsson.com</email> <email>janos.farkas@ericsson.com</email>
</address> </address>
</author> </author>
<author fullname="Stephan Kehrer" initials="S." surname="Kehrer"> <author fullname="Stephan Kehrer" initials="S." surname="Kehrer">
<organization>Hirschmann Automation and Control GmbH</organization> <organization>Hirschmann Automation and Control GmbH</organization>
<address> <address>
<postal> <postal>
<street>Stuttgarter Strasse 45-51.</street> <street>Stuttgarter Strasse 45-51.</street>
<city>Neckartenzlingen</city> <city>Neckartenzlingen</city>
<country>Germany</country> <country>Germany</country>
<code>72654</code> <code>72654</code>
</postal> </postal>
<email>Stephan.Kehrer@belden.com</email> <email>Stephan.Kehrer@belden.com</email>
</address> </address>
</author> </author>
<author fullname="Tobias Heer" initials="T." surname="Heer"> <author fullname="Tobias Heer" initials="T." surname="Heer">
<organization>Hirschmann Automation and Control GmbH</organization> <organization>Hirschmann Automation and Control GmbH</organization>
<address> <address>
<postal> <postal>
<street>Stuttgarter Strasse 45-51.</street> <street>Stuttgarter Strasse 45-51.</street>
<city>Neckartenzlingen</city> <city>Neckartenzlingen</city>
<country>Germany</country> <country>Germany</country>
<code>72654</code> <code>72654</code>
</postal> </postal>
<email>Tobias.Heer@belden.com</email> <email>Tobias.Heer@belden.com</email>
</address> </address>
</author> </author>
<!-- <date month="March" year="2024"/>
<author fullname="James Bond" initials="J." surname="Bond">
<organization>MI6</organization>
<address>
<email>james@bond.com</email>
</address>
</author>
<date /> <area>RTG</area>
<workgroup>DetNet</workgroup> <workgroup>DetNet</workgroup>
<abstract> <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) algorith
m
described herein enables to restore the correct packet order when
replication and elimination functions are used in DetNet networks.
POF only provides ordering within the latency bound of a DetNet flow,
and does not provide any additional reliability.
</t>
</abstract>
</front>
<middle> <t>
<section title="Introduction" anchor="sec_intro"> The replication and elimination functions of the Deterministic Networking
<t> (DetNet) architecture can result in out-of-order packets, which is not
The DetNet Working Group has defined packet replication (PRF) and packet acceptable for some time-sensitive applications. The Packet Ordering
elimination (PEF) functions for achieving extremely low packet loss. PRF Function (POF) algorithms described in this document enable restoration
and of the correct packet order when the replication and elimination
PEF are described in <xref target="RFC8655"/> and provide service functions are used in DetNet networks. The POF only provides ordering with
protection for DetNet flows. This service protection method relies on in
copies of the same packet sent over multiple maximally disjoint paths the latency bound of a DetNet flow; it does not provide any additional
and uses sequencing information to eliminate duplicates. A possible reliability.
implementation of PRF and PEF functions is described in </t>
<xref target="IEEE8021CB"/> and the related YANG model is defined </abstract>
in <xref target="IEEEP8021CBcv"/>. </front>
</t> <middle>
<t> <section anchor="sec_intro" numbered="true" toc="default">
In general, use of per packet replication and elimination functions can <name>Introduction</name>
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="RFC865
5"/>
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 whe
n
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"> <t>
<artwork align="center"><![CDATA[ <xref target="RFC8655" format="default"/> defines the Packet Replication
Function (PRF) and Packet Elimination Function (PEF) in DetNet for
achieving extremely low packet loss. The PRF and PEF 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 is described in <xref
target="IEEE8021CB" format="default"/>, and the related YANG model is
defined in <xref target="IEEEP8021CBcv" format="default"/>.
</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 in this document. <xref target="RFC8655" format="default"/>
defines the external observable result of a POF (i.e., that
packets are reordered) but does not specify any implementation details.
</t>
<t>
So far in packet networks, out-of-order delivery situations have been handl
ed
at higher OSI layers at the endpoints/hosts (e.g., in the TCP stack when
packets are sent to the application layer) and not within a network in n
odes
acting at the Layer 2 or Layer 3 OSI layers.
</t>
<t>
<xref target="PREOF-scene" format="default"/> shows a DetNet flow on which
Packet
Replication, Elimination, and Ordering Functions (PREOF)
are applied during forwarding from source to destination.
</t>
<figure anchor="PREOF-scene">
<name>PREOF Scenario in a DetNet Network</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+------------+ +------------+
+-----------E1----+ | | +-----------E1----+ | |
+----+ | | +---R3---+ | +----+ +----+ | | +---R3---+ | +----+
|src |------R1 +---+ | E3----O1---+ dst| |src |------R1 +---+ | E3----O1---+ dst|
+----+ | | E2-------+ +----+ +----+ | | E2-------+ +----+
+-------R2 | +-------R2 |
+-----------------+ +-----------------+
R: replication point (PRF) R: replication point (PRF)
E: elimination point (PEF) E: elimination point (PEF)
O: ordering function (POF) O: ordering function (POF)
]]> ]]></artwork>
</artwork></figure> </figure>
<t> <t>
In general, the use of PREOF functions require sequencing information In general, the use of PREOF requires sequencing information
to be included in the packets of a DetNet compound flow. This can be 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 done by adding a sequence number as part of DetNet encapsulation
<xref target="RFC8655"/>. Sequencing information is typically added once, <xref target="RFC8655" format="default"/>. Sequencing information is typical ly added once,
at or close to the source. at or close to the source.
</t> </t>
<t> <t>
Important to note that different applications can react differently to out- It is important to note that different applications can react differently t
of-order o out-of-order
delivery. A single out-of-order packet (E.g., packet order: #1, #3, #2, 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 #4, #5) is interpreted by some application as a single error, but
some other applications treat it as 3 errors in-a-row situation. other applications treat it as three errors in a row.
For example, in industrial scenarios For example, in industrial scenarios,
3 errors in-a-row is a usual error threshold and can cause the three errors in a row is a typical error threshold and can cause the
application to stop (e.g., to go to a fail-safe state). application to stop (e.g., go to a fail-safe state).
</t> </t>
<t> <t>
POF ensures in-order delivery for packets being within The POF ensures in-order delivery for packets within
the latency bound of the (DetNet) flow. POF does not correct the latency bound of the DetNet flow. The POF does not correct
errors in the packet flow e.g., duplicate packets, too late packets. errors in the packet flow (e.g., duplicate packets or packets that are t
</t> oo late).
</t>
</section> <!-- end of introduction --> </section>
<section title="Terminology"> <section numbered="true" toc="default">
<section title="Terms Used in This Document"> <name>Terminology</name>
<t> <section numbered="true" toc="default">
<name>Terms Used in This Document</name>
<t>
This document uses the terminology established in the DetNet architecture This document uses the terminology established in the DetNet architecture
<xref target="RFC8655"/>, and the reader is assumed <xref target="RFC8655" format="default"/>; the reader is assumed
to be familiar with that document and its terminology. to be familiar with that document and its terminology.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Abbreviations"> <name>Abbreviations</name>
<t> <t>
The following abbreviations are used in this document: The following abbreviations are used in this document:
<list style="hanging" hangIndent="14"> </t>
<t hangText="DetNet">Deterministic Networking.</t> <dl newline="false" spacing="normal" indent="9">
<t hangText="PEF">Packet Elimination Function.</t> <dt>DetNet</dt>
<t hangText="POF">Packet Ordering Function.</t> <dd>Deterministic Networking</dd>
<t hangText="PREOF">Packet Replication, Elimination and Ordering Function <dt>PEF</dt>
s.</t> <dd>Packet Elimination Function</dd>
<t hangText="PRF">Packet Replication Function.</t> <dt>POF</dt>
</list> <dd>Packet Ordering Function</dd>
</t> <dt>PREOF</dt>
</section> <dd>Packet Replication, Elimination, and Ordering Functions</dd>
<dt>PRF</dt>
<dd>Packet Replication Function</dd>
</dl>
</section>
<!-- </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" numbered="true" toc="default">
<!-- ===================================================================== --> <name>Requirements for POF Implementations</name>
<t>
The requirements for POF implementations are:
</t>
<ul spacing="normal">
<li>
<t>To solve the out-of-order delivery problem of the replication
and elimination functions of DetNet networks. </t>
</li>
<li>
<t>To consider the delay bound requirement of a DetNet flow. </t>
</li>
<li>
<section anchor="req-on-pof" title="Requirements on POF Implementations"> <t>To be simple and to require only a minimum set of states,
<t> configuration parameters, and resources per DetNet flow in network
The requirements on a POF function are: nodes.
<list style="symbols"> </t>
<t>to solve the out-of-order delivery problem of the Replication </li>
and Elimination functions of DetNet networks. </t> <li>
<t>to consider the delay bound requirement of a DetNet Flow. </t> <t>To add minimal or no delay to the forwarding process
<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> of packets. </t>
<t>not to require synchronization between PREOF nodes. </t> </li>
</list> <li>
</t> <t>To not require synchronization between PREOF nodes. </t>
<t> </li>
Some aspects are explicitly out-of-scope for a POF function: </ul>
<list style="symbols"> <t>
<t>to eliminate the delay variation caused by the packet ordering. Some aspects are explicitly out of scope for a POF:
Dealing with delay variation is a DetNet forwarding sub-layer ta </t>
rget <ul spacing="normal">
and it can be achieved for example by placing a de-jitter buffer <li>
or flow regulator (e.g., shaping) function after the POF <t>To eliminate the delay variation caused by the packet ordering.
functionality.</t> Dealing with delay variation is a DetNet forwarding sub-layer
</list> target, and it can be achieved, for example, by placing a de-jitter
</t> buffer or flow regulator (e.g., shaping) function after the POF.</t>
</section> <!-- end of requirements --> </li>
</ul>
</section>
<section anchor="pof-alg" title="POF Algorithms"> <section anchor="pof-alg" numbered="true" toc="default">
<section anchor="preof-relations" title="Prerequisites and Assumptions"> <name>POF Algorithms</name>
<t> <section anchor="preof-relations" numbered="true" toc="default">
The POF Algorithm discussed in this document makes some assumptions and <name>Prerequisites and Assumptions</name>
tradeoffs regarding the characteristics of the sequence of received <t>
packets. In particular, the algorithm assumes that a Packet The POF algorithms discussed in this document make some assumptions and
Elimination Function (PEF) is performed on the incoming packets trade-offs regarding the characteristics of the sequence of received
before they are handed to the POF function. Hence, the sequence packets. In particular, the algorithms assume that a
of incoming packets can be out of order or incomplete but cannot PEF is performed on the incoming packets
contain duplicate packets. However, the PREOF functions run before they are handed to the POF. Hence, the sequence
of incoming packets can be out-of-order or incomplete but cannot
contain duplicate packets. However, the PREOF run
independently without any state exchange required between the independently without any state exchange required between the
PEF and the POF or the PRF and the POF. Error cases in which 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 duplicate packets are presented to the POF can lead to out-of-ord
order delivery of duplicate packets as well as to increased delay er delivery of duplicate packets and to increased delays.
s. </t>
</t> <t>
<t> The algorithms further require that the delay difference between two
The algorithm further requires that the delay difference between two
replicated packets that arrive at the PEF before the POF is bounded and 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 known. Error cases that violate this condition (e.g., a packet that
arrives later than this bound) will result in out-of order packets. arrives later than this bound) will result in out-of-order packets.
</t> </t>
<t> <t>
The algorithm also makes some tradeoffs. For simplicity, it is designed The algorithms also make some trade-offs. For simplicity, it is designed
in a way that allows for some out of order packets directly after to allow for some out-of-order packets directly after
initialization. If this is not acceptable, initialization. If this is not acceptable,
<xref target="enh-pof"/> provides an alternative initialization s cheme <xref target="enh-pof" format="default"/> provides an alternative initialization scheme
that prevents out-of-order packets in the initialization phase. that prevents out-of-order packets in the initialization phase.
</t> </t>
</section> <!-- end of POF assumptions --> </section>
<section anchor="pof-blocks" title="POF building blocks"> <section anchor="pof-blocks" numbered="true" toc="default">
<t> <name>POF Building Blocks</name>
The method described herein provides POF for DetNet networks. The <t>
configuration parameters of POF can be derived during engineering the The method described in this document provides a POF for DetNet networks. T
he
configuration parameters of the POF can be derived when engineering the
DetNet flow through the network. DetNet flow through the network.
</t> </t>
<t> <t>
The POF method is provided via: The POF method is provided via the following:
<list style="numbers"> </t>
<t>Delay calculator: calculates buffering time for out-of-order
packets. <dl newline="false" spacing="normal">
<dt>Delay calculator:</dt><dd>Calculates buffering time for out-of-o
rder packets.
Buffering time considers (i) the delay Buffering time considers (i) the delay
difference of paths used for forwarding the replicated packets difference of paths used for forwarding the replicated packets
and (ii) the bounded delay requirement of the given DetNet flow. and (ii) the bounded delay requirement of the given DetNet flow.
</t> </dd>
<t>Conditional buffer: for buffering the out-of-order packets of a <dt>Conditional delay buffer:</dt><dd>Used for buffering the out-of-
DetNet flow for a given time. </t> order packets of a
</list> DetNet flow for a given time. </dd>
</t> </dl>
<t> <t>
Note: the conditional buffer of POF increases the burstiness of the Note: The conditional delay buffer of the POF increases the burstiness of t
traffic as it adds delay only for some of the packets. he
</t> traffic as it only adds delay for some of the packets.
<t> </t>
<xref target="POF-blocks"/> shows the building blocks of a <t>
<xref target="POF-blocks" format="default"/> shows the building blocks of a
possible POF implementation. possible POF implementation.
</t> </t>
<figure anchor="POF-blocks">
<figure title="POF Building Blocks" anchor="POF-blocks"> <name>POF Building Blocks</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+------------+ +--------------+ +------------+ +--------------+
| Delay calc | | Conditional | | Delay calc | | Conditional |
+--| for packet >--->>---| Delay Buffer >--+ +--| for packet >--->>---| Delay Buffer >--+
| +------------+ +--------------+ | | +------------+ +--------------+ |
| | | |
+------^--------+ | +------^--------+ |
->>--| POF selector >---------------------------------+-->>---- ->>--| POF selector >---------------------------------+-->>----
| (Flow ident.) | | (Flow ident.) |
+---------------+ +---------------+
->>- packet flow ->>- packet flow
]]></artwork>
</figure>
</section>
]]> <section anchor="basic-pof" numbered="true" toc="default">
</artwork></figure> <name>The Basic POF Algorithm</name>
<t>
</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 The basic POF algorithm delays all out-of-order packets until all
previous packet arrives or a given time (POFMaxDelay) elapses. The previous packets arrive or a given time ("POFMaxDelay") elapses. The
basic POF algorithm works as follows: basic POF algorithm works as follows:
<list style="symbols"> </t>
<t>The sequence number of the last forwarded packet (POFLastSent) is <ul spacing="normal">
stored for each DetNet Flow. </t> <li>
<t>The sequence number (seq_num) of a received packet is compare <t>The sequence number of the last forwarded packet ("POFLastSent")
d to is
that of the last forwarded one (POFLastSent). </t> stored for each DetNet flow. </t>
<t>If (seq_num &#60;= POFLastSent + 1) </li>
<list style="symbols"> <li>
<t> Then the packet is forwarded without buffering and "POFLa <t>The sequence number (seq_num) of a received packet is compared to
stSent" that of the last forwarded one ("POFLastSent"). </t>
</li>
<li>
<t>If (seq_num &lt;= POFLastSent + 1)
</t>
<ul spacing="normal">
<li>
<t> Then the packet is forwarded without buffering, and "POFLast
Sent"
is updated (POFLastSent = seq_num). </t> is updated (POFLastSent = seq_num). </t>
<t> Else the received packet is buffered. </t> </li>
</list> <li>
</t> <t> Else, the received packet is buffered. </t>
<t>A buffered packet is forwarded from the buffer when its seq_n </li>
um </ul>
becomes equal to "POFLastSent +1," OR a predefined time ("POFMax </li>
Delay") <li>
<t>A buffered packet is forwarded from the buffer when its seq_num
becomes equal to "POFLastSent + 1" OR a predefined time ("POFMax
Delay")
elapses.</t> elapses.</t>
<t>When a packet is forwarded from the buffer "POFLastSent" is </li>
<li>
<t>When a packet is forwarded from the buffer, "POFLastSent" is
updated with its seq_num (POFLastSent = seq_num). </t> updated with its seq_num (POFLastSent = seq_num). </t>
</list> </li>
</t> </ul>
<t>
Note: the difference of sequence number in consecutive packets is bounded <t>Notes:</t>
due to the history window of the Elimination function before the POF. <ul spacing="normal">
Therefore "&#60;=" can be evaluated despite of the circular <li>The difference between sequence numbers in consecutive packets is bounded
sequence number space. A possible implementation of the PEF function and due to the history window of the elimination function before the POF.
the impact of the history window is described in <xref target="IEEE8021C Therefore, "&lt;=" can be evaluated despite the circular
B"/>. sequence number space. A possible implementation of the PEF and
</t> the impact of the history window are described in <xref target="IEEE8021
<t> CB" format="default"/>.
Note2: The algorithm can be extended to cope with multiple failure scena </li>
rios <li>The basic POF algorithm can be extended to cope with multiple failur
(i.e., simultaneous packet loss and out-of-order packets), when the expi e scenarios
ration (i.e., simultaneous packet loss and out-of-order packets) when the expir
of the timer for a packet with sequence number N trigger the release of ation
some of the timer for a packet with sequence number N triggers the release of
number of packets with sequence number smaller than N. some
</t> packets with a sequence number smaller than N.
<t> </li>
</ul>
<t>
The state used by the basic POF algorithm (i.e., "POFLastSent") needs The state used by the basic POF algorithm (i.e., "POFLastSent") needs
initialization and maintenance. This works as follows: initialization and maintenance. This works as follows:
<list style="symbols"> </t>
<t>The next received packet is forwarded and the POFLastSent <ul spacing="normal">
updated when the POF function was reset OR no packet was receive <li>
d <t>The next received packet is forwarded and the "POFLastSent"
updated when the POF is reset OR no packet is received
for a predefined time ("POFTakeAnyTime"). </t> for a predefined time ("POFTakeAnyTime"). </t>
<t>The reset of POF erases all packets from the time-based </li>
buffer used by POF. </t> <li>
</list> <t>The reset of the POF erases all packets from the time-based
</t> buffer used by the POF. </t>
<t> </li>
</ul>
<t>
The basic POF algorithm has two parameters to engineer: The basic POF algorithm has two parameters to engineer:
<list style="symbols"> </t>
<t>"POFMaxDelay", which cannot be smaller than the delay <ul spacing="normal">
<li>
<t>"POFMaxDelay", which cannot be smaller than the delay
difference of the paths used by the flow. </t> difference of the paths used by the flow. </t>
<t>"POFTakeAnyTime", which is calculated based on several factor </li>
s, <li>
for example the RECOVERY_TIMEOUT related settings of the <t>"POFTakeAnyTime", which is calculated based on several factors,
Elimination function(s) before the POF, the flow characteristics for example, the settings of the elimination function(s) relating
(e.g., inter packet time), and the delay difference of the to RECOVERY_TIMEOUT before the POF, the flow characteristics
paths used by the flow. </t> (e.g., inter-packet time), and the delay difference of the paths
</list> used by the flow. </t>
</t> </li>
<t> </ul>
Design of these parameters is out-of-scope in this document. <t>
</t> Design of these parameters is out of scope for this document.
<t> </t>
Note: multiple network failures can impact the POF function <t>
Note: Multiple network failures can impact the POF
(e.g., complete outage of all redundant paths). (e.g., complete outage of all redundant paths).
</t> </t>
<t>
<t>
The basic POF algorithm increases the delay of packets with maximum The basic POF algorithm increases the delay of packets with maximum
"POFMaxDelay" time. Packets being in order are not delayed. This basic "POFMaxDelay" time. In-order packets are not delayed. This basic
POF method can be applied in all network scenarios where the remaining 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" delay budget of a flow at the POF point is larger than "POFMaxDelay"
time. time.
</t> </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[
<t>
<xref target="delay-budget" format="default"/> shows the delay budget
situation at the POF point.
</t>
<figure anchor="delay-budget">
<name>Delay Budget Situation at the POF Point</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
Path delay Path delay
difference difference
/-------------/ /-------------/
<- path with min delay -> /-- remaining delay budget --/ <- path with min delay -> /-- remaining delay budget --/
|-----------------------|-------------|----------------------------| |-----------------------|-------------|----------------------------|
0 t1 t2 T 0 t1 t2 T
<-------- path with max delay --------> <-------- path with max delay -------->
/-------------------- delay budget at POF point -------------------/ /-------------------- delay budget at POF point -------------------/
]]></artwork>
</figure>
</section>
]]> <section anchor="adv-pof" numbered="true" toc="default">
</artwork></figure> <name>The Advanced POF Algorithm</name>
<t>
</section> <!-- end of basic POF --> In network scenarios where the remaining delay budget of a flow at the
POF point is smaller than "POFMaxDelay" time, the basic method needs
<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. extensions.
</t> </t>
<t> <t>
The issue is that packets on the longest path cannot be buffered in order 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 to keep the delay budget of the flow. It must be noted that such a packe t
(i.e., forwarded over the longest path) needs no buffering as it is the (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 last chance to deliver a packet with a given sequence number. This is
because all replicas are already arrived via shorter path(s). because all replicas already arrived via a shorter path(s).
</t> </t>
<t>
The advanced POF algorithm needs two extensions of the basic POF <t>
algorithm: The advanced POF algorithm requires extensions of the basic POF algorithm:
<list style="symbols"> </t>
<t>to identify the received packet's path at the POF location and </t> <ul spacing="normal">
<t>to make the value of "POFMaxDelay" for buffered packets path <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 dependent ("POFMaxDelay_i", where "i" notes the path the packet
has used). </t> has used). </t>
</list> </li>
</t> </ul>
<t> <t>
By identifying the path of a given packet, the POF algorithm can use this The advanced POF algorithm identifies the path of a given packet and uses this
information to select what predefined time "POFMaxDelay_i" to apply for information to select the predefined time ("POFMaxDelay_i") to apply for the
the buffered packet. So, in the advanced POF algorithm "POFMaxDelay" buffered packet. So, in the advanced POF algorithm, "POFMaxDelay" is an
is an array, that contains the predefined and path specific buffering array that contains the predefined and path-specific buffering time for each
time for each redundant path of a flow. Values in the "POFMaxDelay" redundant path of a flow. Values in the "POFMaxDelay" array are engineered
array are engineered to fulfill the delay budget requirement. to fulfill the delay budget requirement.
</t> </t>
<t> <t>
Design of these parameters is out-of-scope in this document. Design of these parameters is out of scope for this document.
</t> </t>
<t> <t>
Note: for the "Advanced POF Algorithm" the path dependent delays Note: For the advanced POF algorithm, the path-dependent delays
might result in multiple packets triggering the "maximum delay might result in multiple packets triggering the "maximum delay
reached" at exactly the same time. The transmission order of reached" at exactly the same time. The transmission order of
these packets then should be done in their seq_num order. these packets should be done in their seq_num order.
</t> </t>
<t>
The method for identification of the packet's path at the POF location <t>
depends on the network scenario. It can be implemented via various The method for identifying the packet's path at the POF location
techniques, for example using ingress interface information, encoding depends on the network scenario.
the path in the packet itself (e.g., replication functions can set It can be implemented via
different FlowID per egress what can be used as a PathID), or in other various techniques, for example, using ingress interface information,
means. Method for identification of the packet's path is out of scope encoding the path in the packet itself (e.g., replication functions
in this document. set a different FlowID per member flow at their egress and such
</t> a FlowID is used to identify the path of a packet at the POF), or
<t> other means.
Note: in case of using the advanced POF algorithm it might be Methods for identifying the packet's path are out of scope
for this document.
</t>
<t>
Note: When using the advanced POF algorithm, it might be
advantageous to combine PEF and POF locations in the DetNet network, as 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 this can simplify the method used for identifying the packet's path
at the POF location. at the POF location.
</t> </t>
</section> <!-- end of advanced POF --> </section>
<section anchor="enh-pof" title="Further enhancements of POF algorithms"> <section anchor="enh-pof" numbered="true" toc="default">
<t> <name>Further Enhancements of the POF Algorithms</name>
<t>
POF algorithms can be further enhanced by distinguishing the case of POF algorithms can be further enhanced by distinguishing the case of
initialization from normal operation at the price of more states and initialization from normal operation at the price of more states and
more sophisticated implementation. Such enhancements could for example more sophisticated implementation. Such enhancements could, for example,
react better after some failure scenarios (e.g., complete outage of all 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. paths of a DetNet flow) and can be dependent on the PEF implementation.
</t> </t>
<t>
The challenge for POF initialization is that for example after a reset it <t>
is not known whether the first received packet is in-order or The challenge for POF initialization is that it is not known whether the
out-of-order. The original initialization (see before) considers the first received packet is in-order or out-of-order (for example, after a
reset).
The original initialization (see <xref target="basic-pof"/>) considers the
first packet as in-order, so out-of-order packet(s) during first packet as in-order, so out-of-order packet(s) during
"POFMaxTime"/"POFMaxTime_path_i" time - after the first packet was "POFMaxTime"/"POFMaxTime_path_i" time -- after the first packet is
received - cannot be corrected. Motivation behind such an initialization received -- cannot be corrected.
is POF implementation simplicity.
</t> The motivation behind such an initialization
<t> is simplicity of POF implementation.
</t>
<t>
A possible enhancement of POF initialization works as follows: A possible enhancement of POF initialization works as follows:
<list style="symbols"> </t>
<t>After a reset all received packets are buffered with their <ul spacing="normal">
<li>
<t>After a reset, all received packets are buffered with their
predefined timer ("POFMaxTime"/"POFMaxTime_path_i"). </t> predefined timer ("POFMaxTime"/"POFMaxTime_path_i"). </t>
<t>No basic/advanced POF rules are applied until the first timer </li>
<li>
<t>No basic or advanced POF rules are applied until the first timer
expires. </t> expires. </t>
<t>When the first timer expires the packet with lowest seq_num i </li>
n <li>
buffer is selected, forwarded, and "POFLastSent" is set with its <t>When the first timer expires, the packet with lowest seq_num in t
he
buffer is selected and forwarded, and "POFLastSent" is set with
its
seq_num.</t> seq_num.</t>
<t>The basic/advanced POF rules are applied for the packet(s) in </li>
the <li>
<t>The basic or advanced POF rules are applied for the packet(s) in
the
buffer and the subsequently received packets.</t> buffer and the subsequently received packets.</t>
</list> </li>
</t> </ul>
</section> <!-- end of POF enhancement --> </section>
<section anchor="select-pof" title="Selecting and using the POF algorithm"> <section anchor="select-pof" numbered="true" toc="default">
<t> <name>Selecting and Using the POF Algorithms</name>
<t>
The selection of the POF algorithm depends on the network scenario and The selection of the POF algorithm depends on the network scenario and
the remaining delay budget of a flow. Using POF and calculating its the remaining delay budget of a flow. Using the POF algorithms and calcu lating their
parameters require proper design. Knowing the path delay difference is parameters require proper design. Knowing the path delay difference is
essential for the POF algorithms described here. Failure scenarios essential for the POF algorithms described here. Failure scenarios
breaking the design assumptions can impact the result of POF (e.g., breaking the design assumptions can impact the result of the POF (e.g.,
packet received out of the expected worst-case delay window packet received out of the expected worst-case delay window
- calculated based on the path delay difference - can result in unwanted -- calculated based on the path delay difference -- can result in unwant ed
out-of-order delivery). out-of-order delivery).
</t> </t>
<t> <t>
In DetNet scenarios there is always an Elimination function before the POF In DetNet scenarios, there is always an elimination function before the
(therefore duplicates are not considered by the POF). Implementing them POF (therefore, duplicates are not considered by the POF). Implementing
together in the same node allows POF to consider PEF events/states durin them together in the same node allows the POF to consider PEF events/states
g during the reordering. For example, under normal circumstances, the
the re-ordering. For example, under normal circumstances the difference difference between sequence numbers in consecutive packets is bounded due
of to the history window of the PEF. However, in some scenarios (e.g., reset
sequence number in consecutive packets is bounded due to the history of
window of PEF. However, in some scenarios (e.g., reset of sequence sequence number), the difference can be much larger than the size of the
number) the difference can be much larger than the history window size. history window.
</t> </t>
</section> <!-- end of POF selection --> </section>
</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>
<section anchor="iana" title="IANA Considerations"> <section anchor="ctrl-mngmnt-pof" numbered="true" toc="default">
<t> <name>Control and Management Plane Parameters for POF</name>
This document makes no IANA requests.
</t>
</section>
<section anchor="acks" title="Acknowledgements"> <t>POF algorithms require the following parameters to be set:
<t> </t>
Authors extend their appreciation to Gyorgy Miklos, Mohammadpour Ehsan, Ludov <ul spacing="normal">
ic Thomas, <li>
Greg Mirsky, Jeong-dong Ryoo, Shirley Yangfan, Toerless Eckert, Norman Finn a <t>Basic POF
nd Ethan </t>
Grossman for their insightful comments and productive discussion that helped <ul spacing="normal">
to improve <li>
the document. <t>"POFMaxDelay" </t>
</t> </li>
</section> <li>
<t>"POFTakeAnyTime" </t>
</li>
</ul>
</li>
<li>
<t>Advanced POF
</t>
<ul spacing="normal">
<li>
<t>"POFMaxDelay_i" for each possible path i </t>
</li>
<li>
<t>"POFTakeAnyTime" </t>
</li>
<li>
<t>Configuration(s) related to network path identification</t>
</li>
</ul>
</li>
</ul>
<t>
Note: In a proper design, "POFTakeAnyTime" is always larger than "POFMaxDel
ay".
</t>
</section>
</middle> <section numbered="true" toc="default">
<name>Security Considerations</name>
<t>
PREOF-related security considerations (including POF) are described in
<xref target="RFC9055" sectionFormat="of" section="3.3"/>. There are no
additional POF-related security considerations originating from this
document.
</t>
</section>
<section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.
</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
655.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
055.xml"/>
</references>
<references>
<name>Informative References</name>
<back> <reference anchor="IEEE8021CB" target="https://standards.ieee.org/standa
<references title="Normative References"> rd/802_1CB-2017.html">
<!-- <?rfc include="reference.RFC.2119"?> <front>
<?rfc include="reference.RFC.8174"?> --> <title>IEEE Standard for Local and metropolitan area
<?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 networks -- Frame Replication and Elimination for Reliability
</title> </title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date month="October" year="2017"/> <date month="October" year="2017"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2017.8091139" /> <seriesInfo name='IEEE Std' value='802.1CB-2017' />
</reference> <seriesInfo name="DOI" value="10.1109/IEEESTD.2017.8091139"/>
<reference anchor="IEEEP8021CBcv" </reference>
target="https://www.ieee802.org/1/files/private/cv-drafts/d1/802-1
CBcv-d1-2.pdf"> <reference anchor="IEEEP8021CBcv" target="https://standards.ieee.org/ieee/802.1C
<front> Bcv/7285/">
<title>FRER YANG Data Model and Management Information Base Module</ti <front>
tle> <title>IEEE Standard for Local and metropolitan area networks --
<author initials="S." surname="Kehrer" fullname="Stephan Kehrer"> Frame Replication and Elimination for Reliability - Amendment 1:
<organization>IEEE 802.1</organization> Information Model, YANG Data Model, and Management Information
</author> Base Module
<date month="March" year="2021"/> </title>
</front> <author>
<seriesInfo name="IEEE P802.1CBcv /D1.2" value="P802.1CBcv"/> <organization>IEEE</organization>
<format type="PDF" target="https://www.ieee802.org/1/files/private/cv-dr </author>
afts/d1/802-1CBcv-d1-2.pdf"/> <date month="February" year="2022"/>
</reference> </front>
</references> <seriesInfo name="IEEE Std" value="802.1CBcv-2001"/>
</back> <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> </rfc>
 End of changes. 81 change blocks. 
487 lines changed or deleted 574 lines changed or added

This html diff was produced by rfcdiff 1.48.