<?xmlversion="1.0" encoding="US-ASCII"?>version='1.0' encoding='UTF-8'?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?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>ReplicationThe replication andEliminationelimination functions ofDetNet Architecturethe 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 describedhereinin this document enablesto restorerestoration 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 DetNetflow, andflow; it does not provide any additional reliability. </t> </abstract> </front> <middle> <sectiontitle="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 <xreftarget="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 <xreftarget="IEEE8021CB"/>target="IEEE8021CB" format="default"/>, and the related YANG model is defined in <xreftarget="IEEEP8021CBcv"/>.target="IEEEP8021CBcv" format="default"/>. </t> <t> In general, use ofper packetper-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 trivialtask, thereforetask; therefore, details of a Packet Ordering Function (POF) are specifiedherein. Thein this document. In <xref target="RFC8655" format="default"/>, the IETF DetNetWG hasWorking Group definedin <xref target="RFC8655"/>the external observable result of a POFfunction, i.e.,function (i.e., that packets arereordered,reordered), but without any implementation details. </t> <t> So far in packet networks, out-of-order delivery situationswerehave been handled at higher OSI layers at theend-points/hostsendpoints/hosts (e.g., in the TCP stack when packets are sent to the application layer) and not within a network in nodes acting at theLayer-2Layer 2 orLayer-3Layer 3 OSI layers. </t> <t> <xreftarget="PREOF-scene"/>target="PREOF-scene" format="default"/> shows a DetNet flow on whichpacket replication, eliminationPacket Replication, Elimination, andorderingOrdering Functions (PREOF)functionsare applied during forwarding from source to destination. </t> <figuretitle="PREOF scenarioanchor="PREOF-scene"> <name>PREOF Scenario in a DetNetnetwork" anchor="PREOF-scene">Network</name> <artworkalign="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 functionsrequirerequires 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 <xreftarget="RFC8655"/>.target="RFC8655" format="default"/>. Sequencing information is typically added once, at or close to the source. </t> <t>ImportantIt 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., packetorder:order #1, #3, #2, #4, #5) is interpreted by some application as a single error, butsomeother applications treat it as3three errorsin-a-row situation.in a row. For example, in industrialscenarios 3scenarios, three errorsin-a-rowin a row is ausualtypical error threshold and can cause the application to stop (e.g.,togo 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 flowe.g.,(e.g., duplicatepackets,packets or packets that are toolate packets.late). </t> </section><!-- end of introduction --><sectiontitle="Terminology">numbered="true" toc="default"> <name>Terminology</name> <sectiontitle="Termsnumbered="true" toc="default"> <name>Terms Used in ThisDocument">Document</name> <t> This document uses the terminology established in the DetNet architecture <xreftarget="RFC8655"/>, andtarget="RFC8655" format="default"/>; the reader is assumed to be familiar with that document and its terminology. </t> </section> <sectiontitle="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 EliminationFunction.</t> <t hangText="POF">PacketFunction</dd> <dt>POF</dt> <dd>Packet OrderingFunction.</t> <t hangText="PREOF">PacketFunction</dd> <dt>PREOF</dt> <dd>Packet Replication,EliminationElimination, and OrderingFunctions.</t> <t hangText="PRF">PacketFunctions</dd> <dt>PRF</dt> <dd>Packet ReplicationFunction.</t> </list> </t>Function</dd> </dl> </section> </section><!--<sectiontitle="Requirements Language"> <t>anchor="req-on-pof" numbered="true" toc="default"> <!-- [rfced] Thekey 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 inthis document are tothe section uses "POF function". Should these beinterpreted 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="Requirementsconsistent? Original: 3. Requirements on POFImplementations"> <t>Implementations The requirements on a POF function are:<list style="symbols"> <t>toPerhaps: 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 theReplicationreplication andEliminationelimination functions of DetNet networks. </t><t>to</li> <li> <t>To consider the delay bound requirement of a DetNetFlow.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 addonlyminimal 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 explicitlyout-of-scopeout 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-layertargettarget, and it can beachievedachieved, forexampleexample, 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="Prerequisitesnumbered="true" toc="default"> <name>Prerequisites andAssumptions">Assumptions</name> <t> The POFAlgorithmalgorithm discussed in this document makes some assumptions andtradeoffstrade-offs regarding the characteristics of the sequence of received packets. In particular, the algorithm assumes that aPacket 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 beout of orderout-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 toout of orderout-of-order delivery of duplicate packetsas well asand 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 inout-of orderout-of-order packets. </t> <t> The algorithm also makes sometradeoffs.trade-offs. For simplicity, it is designedin a way that allowsto allow for someout of orderout-of-order packets directly after initialization. If this is not acceptable, <xreftarget="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 describedhereinin this document provides POF for DetNet networks. The configuration parameters of POF can be derivedduringwhen engineering the DetNet flow through the network. </t> <t> The POF method is providedvia: <list style="numbers"> <t>Delay calculator: calculatesvia 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:theThe conditional buffer of POF increases the burstiness of the traffic as it only adds delayonlyfor some of the packets. </t> <t> <xreftarget="POF-blocks"/>target="POF-blocks" format="default"/> shows the building blocks of a possible POF implementation. </t> <figuretitle="POF Building Blocks"anchor="POF-blocks"> <name>POF Building Blocks</name> <artworkalign="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="Thenumbered="true" toc="default"> <name>The Basic POFAlgorithm">Algorithm</name> <t> The basic POF algorithm delays all out-of-order packets until all previouspacket arrivespackets 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 DetNetFlow.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<=<= POFLastSent + 1)<list style="symbols"></t> <ul spacing="normal"> <li> <t> Then the packet is forwarded withoutbufferingbuffering, and "POFLastSent" is updated (POFLastSent = seq_num). </t> </li> <li> <t>ElseElse, 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 thebufferbuffer, "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 "<="... 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, "<=" can be evaluated despiteofthe circular sequence number space. A possible implementation of the PEF function and the impact of the history windowisare described in <xreftarget="IEEE8021CB"/>. </t> <t> Note2: Thetarget="IEEE8021CB" format="default"/>. </li> <li>The algorithm can be extended to cope with multiple failure scenarios (i.e., simultaneous packet loss and out-of-orderpackets),packets) when the expiration of the timer for a packet with sequence number Ntriggertriggers the release of somenumber ofpackets 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 functionwasis reset OR no packetwasis 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, forexampleexample, theRECOVERY_TIMEOUT relatedsettings of theEliminationelimination function(s) relating to RECOVERY_TIMEOUT before the POF, the flow characteristics (e.g.,inter packetinter-packet time), and the delay difference of the paths used by the flow. </t></list> </t></li> </ul> <t> Design of these parameters isout-of-scope inout of scope for this document. </t> <t> Note:multipleMultiple 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 orderIn-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> <xreftarget="delay-budget"/>target="delay-budget" format="default"/> shows the delay budget relations at the POF point. </t> <figuretitle="Delayanchor="delay-budget"> <name>Delay Budget Relations at the POFPoint" anchor="delay-budget">Point</name> <artworkalign="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="Thenumbered="true" toc="default"> <name>The Advanced POFAlgorithm">Algorithm</name> <t> In networkscenarioscenarios where the remaining delay budget of a flow at the POF point is smaller than "POFMaxDelay"timetime, 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 replicasarealready 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 POFalgorithmalgorithm, "POFMaxDelay" is anarray,array that contains the predefined andpath specificpath-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 isout-of-scope inout of scope for this document. </t> <t> Note:forFor the"Advancedadvanced POFAlgorithm"algorithm, thepath dependentpath-dependent delays might result in multiple packets triggering the "maximum delay reached" at exactly the same time. The transmission order of these packetsthenshould 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 foridentification ofidentifying the packet's path at the POF location depends on the network scenario. It can be implemented via various techniques, forexampleexample, 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), orinother means.MethodMethods foridentification ofidentifying the packet's pathisare out of scopeinfor this document. </t> <t> Note:in case ofWhen using the advanced POFalgorithmalgorithm, it might be advantageous to combine PEF and POF locations in the DetNet network, asitthis can simplify the method used foridentification ofidentifying the packet's path at the POF location. </t> </section><!-- end of advanced POF --><section anchor="enh-pof"title="Further enhancementsnumbered="true" toc="default"> <name>Further Enhancements of POFalgorithms">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 enhancementscouldcould, forexampleexample, 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 POFimplementation 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 aresetreset, 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 timerexpiresexpires, the packet with lowest seq_num in the buffer isselected,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="Selectingnumbered="true" toc="default"> <name>Selecting andusingUsing the POFalgorithm">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 DetNetscenariosscenarios, there is always anEliminationelimination 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 there-ordering.reordering. For example, under normalcircumstancescircumstances, 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 sequencenumber)number), the difference can be much larger than the size of the historywindow size.window. </t> </section><!-- end of POF selection --></section><!-- end of POF algorithms --><section anchor="ctrl-mngmnt-pof"title="Controlnumbered="true" toc="default"> <name>Control and Management Plane Parameters forPOF"> <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) relatedconfiguration(s) </t> </list> </t> </list> </t>to network path identification</t> </li> </ul> </li> </ul> <t>Note, that inNote: In a properdesigndesign, "POFTakeAnyTime" is always larger than "POFMaxDelay". </t> </section><!-- end of POF management --> <!-- ===================================================================== --><sectiontitle="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>PREOF relatedPREOF-related security considerations (including POF) are described insection 3.3 of<xreftarget="RFC9055"/>.target="RFC9055" sectionFormat="of" section="3.3"/>. There are no additionalPOF relatedPOF-related security considerations originating from this document. </t> </section> <section anchor="iana"title="IANA Considerations"> <t> Thisnumbered="true" toc="default"> <name>IANA Considerations</name> <t>This documentmakeshas no IANArequests. </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> <seriesInfoname="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>