rfc9550.original   rfc9550.txt 
DetNet B. Varga, Ed. Internet Engineering Task Force (IETF) B. Varga, Ed.
Internet-Draft J. Farkas Request for Comments: 9550 J. Farkas
Intended status: Informational Ericsson Category: Informational Ericsson
Expires: 18 July 2024 S. Kehrer ISSN: 2070-1721 S. Kehrer
T. Heer T. Heer
Hirschmann Automation and Control GmbH Hirschmann Automation and Control GmbH
15 January 2024 March 2024
Deterministic Networking (DetNet): Packet Ordering Function Deterministic Networking (DetNet): Packet Ordering Function
draft-ietf-detnet-pof-11
Abstract Abstract
Replication and Elimination functions of DetNet Architecture can The replication and elimination functions of the Deterministic
result in out-of-order packets, which is not acceptable for some Networking (DetNet) architecture can result in out-of-order packets,
time-sensitive applications. The Packet Ordering Function (POF) which is not acceptable for some time-sensitive applications. The
algorithm described herein enables to restore the correct packet Packet Ordering Function (POF) algorithms described in this document
order when replication and elimination functions are used in DetNet enable restoration of the correct packet order when the replication
networks. POF only provides ordering within the latency bound of a and elimination functions are used in DetNet networks. The POF only
DetNet flow, and does not provide any additional reliability. provides ordering within the latency bound of a DetNet flow; it does
not provide any additional reliability.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 18 July 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9550.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
2.1. Terms Used in This Document . . . . . . . . . . . . . . . 4 2.1. Terms Used in This Document
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Abbreviations
3. Requirements on POF Implementations . . . . . . . . . . . . . 4 3. Requirements for POF Implementations
4. POF Algorithms . . . . . . . . . . . . . . . . . . . . . . . 5 4. POF Algorithms
4.1. Prerequisites and Assumptions . . . . . . . . . . . . . . 5 4.1. Prerequisites and Assumptions
4.2. POF building blocks . . . . . . . . . . . . . . . . . . . 5 4.2. POF Building Blocks
4.3. The Basic POF Algorithm . . . . . . . . . . . . . . . . . 6 4.3. The Basic POF Algorithm
4.4. The Advanced POF Algorithm . . . . . . . . . . . . . . . 8 4.4. The Advanced POF Algorithm
4.5. Further enhancements of POF algorithms . . . . . . . . . 9 4.5. Further Enhancements of the POF Algorithms
4.6. Selecting and using the POF algorithm . . . . . . . . . . 10 4.6. Selecting and Using the POF Algorithms
5. Control and Management Plane Parameters for POF . . . . . . . 10 5. Control and Management Plane Parameters for POF
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses
1. Introduction 1. Introduction
The DetNet Working Group has defined packet replication (PRF) and [RFC8655] defines the Packet Replication Function (PRF) and Packet
packet elimination (PEF) functions for achieving extremely low packet Elimination Function (PEF) in DetNet for achieving extremely low
loss. PRF and PEF are described in [RFC8655] and provide service packet loss. The PRF and PEF provide service protection for DetNet
protection for DetNet flows. This service protection method relies flows. This service protection method relies on copies of the same
on copies of the same packet sent over multiple maximally disjoint packet sent over multiple maximally disjoint paths and uses
paths and uses sequencing information to eliminate duplicates. A sequencing information to eliminate duplicates. A possible
possible implementation of PRF and PEF functions is described in implementation of the PRF and PEF is described in [IEEE8021CB], and
[IEEE8021CB] and the related YANG model is defined in the related YANG model is defined in [IEEEP8021CBcv].
[IEEEP8021CBcv].
In general, use of per packet replication and elimination functions In general, use of per-packet replication and elimination functions
can result in out-of-order delivery of packets, which is not can result in out-of-order delivery of packets, which is not
acceptable for some deterministic applications. Correcting packet acceptable for some deterministic applications. Correcting packet
order is not a trivial task, therefore details of a Packet Ordering order is not a trivial task; therefore, details of a Packet Ordering
Function (POF) are specified herein. The IETF DetNet WG has defined Function (POF) are specified in this document. [RFC8655] defines the
in [RFC8655] the external observable result of a POF function, i.e., external observable result of a POF (i.e., that packets are
that packets are reordered, but without any implementation details. reordered) but does not specify any implementation details.
So far in packet networks, out-of-order delivery situations were So far in packet networks, out-of-order delivery situations have been
handled at higher OSI layers at the end-points/hosts (e.g., in the handled at higher OSI layers at the endpoints/hosts (e.g., in the TCP
TCP stack when packets are sent to application layer) and not within stack when packets are sent to the application layer) and not within
a network in nodes acting at the Layer-2 or Layer-3 OSI layers. a network in nodes acting at the Layer 2 or Layer 3 OSI layers.
Figure 1 shows a DetNet flow on which packet replication, elimination Figure 1 shows a DetNet flow on which Packet Replication,
and ordering (PREOF) functions are applied during forwarding from Elimination, and Ordering Functions (PREOF) are applied during
source to destination. forwarding from source to destination.
+------------+ +------------+
+-----------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)
Figure 1: PREOF scenario in a DetNet network Figure 1: PREOF Scenario in a DetNet Network
In general, the use of PREOF functions require sequencing information In general, the use of PREOF requires sequencing information to be
to be included in the packets of a DetNet compound flow. This can be included in the packets of a DetNet compound flow. This can be done
done by adding a sequence number as part of DetNet encapsulation by adding a sequence number as part of DetNet encapsulation
[RFC8655]. Sequencing information is typically added once, at or [RFC8655]. Sequencing information is typically added once, at or
close to the source. close to the source.
Important to note that different applications can react differently It is important to note that different applications can react
to out-of-order delivery. A single out-of-order packet (E.g., packet differently to out-of-order delivery. A single out-of-order packet
order: #1, #3, #2, #4, #5) is interpreted by some application as a (e.g., packet order #1, #3, #2, #4, #5) is interpreted by some
single error, but some other applications treat it as 3 errors in- application as a single error, but other applications treat it as
a-row situation. For example, in industrial scenarios 3 errors in- three errors in a row. For example, in industrial scenarios, three
a-row is a usual error threshold and can cause the application to errors in a row is a typical error threshold and can cause the
stop (e.g., to go to a fail-safe state). application to stop (e.g., go to a fail-safe state).
POF ensures in-order delivery for packets being within the latency The POF ensures in-order delivery for packets within the latency
bound of the (DetNet) flow. POF does not correct errors in the bound of the DetNet flow. The POF does not correct errors in the
packet flow e.g., duplicate packets, too late packets. packet flow (e.g., duplicate packets or packets that are too late).
2. Terminology 2. Terminology
2.1. Terms Used in This Document 2.1. Terms Used in This Document
This document uses the terminology established in the DetNet This document uses the terminology established in the DetNet
architecture [RFC8655], and the reader is assumed to be familiar with architecture [RFC8655]; the reader is assumed to be familiar with
that document and its terminology. that document and its terminology.
2.2. Abbreviations 2.2. Abbreviations
The following abbreviations are used in this document: The following abbreviations are used in this document:
DetNet Deterministic Networking. DetNet Deterministic Networking
PEF Packet Elimination Function. PEF Packet Elimination Function
POF Packet Ordering Function. POF Packet Ordering Function
PREOF Packet Replication, Elimination and Ordering Functions. PREOF Packet Replication, Elimination, and Ordering Functions
PRF Packet Replication Function. PRF Packet Replication Function
3. Requirements on POF Implementations 3. Requirements for POF Implementations
The requirements on a POF function are: The requirements for POF implementations are:
* to solve the out-of-order delivery problem of the Replication and * To solve the out-of-order delivery problem of the replication and
Elimination functions of DetNet networks. elimination functions of DetNet networks.
* to consider the delay bound requirement of a DetNet Flow. * To consider the delay bound requirement of a DetNet flow.
* to be simple and to require in network nodes only a minimum set of * To be simple and to require only a minimum set of states,
states/configuration parameters and resources per DetNet Flow. configuration parameters, and resources per DetNet flow in network
nodes.
* to add only minimal or no delay to the forwarding process of * To add minimal or no delay to the forwarding process of packets.
packets.
* not to require synchronization between PREOF nodes. * To not require synchronization between PREOF nodes.
Some aspects are explicitly out-of-scope for a POF function: Some aspects are explicitly out of scope for a POF:
* to eliminate the delay variation caused by the packet ordering. * To eliminate the delay variation caused by the packet ordering.
Dealing with delay variation is a DetNet forwarding sub-layer Dealing with delay variation is a DetNet forwarding sub-layer
target and it can be achieved for example by placing a de-jitter target, and it can be achieved, for example, by placing a de-
buffer or flow regulator (e.g., shaping) function after the POF jitter buffer or flow regulator (e.g., shaping) function after the
functionality. POF.
4. POF Algorithms 4. POF Algorithms
4.1. Prerequisites and Assumptions 4.1. Prerequisites and Assumptions
The POF Algorithm discussed in this document makes some assumptions The POF algorithms discussed in this document make some assumptions
and tradeoffs regarding the characteristics of the sequence of and trade-offs regarding the characteristics of the sequence of
received packets. In particular, the algorithm assumes that a Packet received packets. In particular, the algorithms assume that a PEF is
Elimination Function (PEF) is performed on the incoming packets performed on the incoming packets before they are handed to the POF.
before they are handed to the POF function. Hence, the sequence of Hence, the sequence of incoming packets can be out-of-order or
incoming packets can be out of order or incomplete but cannot contain incomplete but cannot contain duplicate packets. However, the PREOF
duplicate packets. However, the PREOF functions run independently run independently without any state exchange required between the PEF
without any state exchange required between the PEF and the POF or and the POF or the PRF and the POF. Error cases in which duplicate
the PRF and the POF. Error cases in which duplicate packets are packets are presented to the POF can lead to out-of-order delivery of
presented to the POF can lead to out of order delivery of duplicate duplicate packets and to increased delays.
packets as well as to increased delays.
The algorithm further requires that the delay difference between two The algorithms further require that the delay difference between two
replicated packets that arrive at the PEF before the POF is bounded replicated packets that arrive at the PEF before the POF is bounded
and known. Error cases that violate this condition (e.g., a packet and known. Error cases that violate this condition (e.g., a packet
that arrives later than this bound) will result in out-of order that arrives later than this bound) will result in out-of-order
packets. packets.
The algorithm also makes some tradeoffs. For simplicity, it is The algorithms also make some trade-offs. For simplicity, it is
designed in a way that allows for some out of order packets directly designed to allow for some out-of-order packets directly after
after initialization. If this is not acceptable, Section 4.5 initialization. If this is not acceptable, Section 4.5 provides an
provides an alternative initialization scheme that prevents out-of- alternative initialization scheme that prevents out-of-order packets
order packets in the initialization phase. in the initialization phase.
4.2. POF building blocks 4.2. POF Building Blocks
The method described herein provides POF for DetNet networks. The The method described in this document provides a POF for DetNet
configuration parameters of POF can be derived during engineering the networks. The configuration parameters of the POF can be derived
DetNet flow through the network. when engineering the DetNet flow through the network.
The POF method is provided via: The POF method is provided via the following:
1. Delay calculator: calculates buffering time for out-of-order Delay calculator: Calculates buffering time for out-of-order
packets. Buffering time considers (i) the delay difference of packets. Buffering time considers (i) the delay difference of
paths used for forwarding the replicated packets and (ii) the paths used for forwarding the replicated packets and (ii) the
bounded delay requirement of the given DetNet flow. bounded delay requirement of the given DetNet flow.
2. Conditional buffer: for buffering the out-of-order packets of a Conditional delay buffer: Used for buffering the out-of-order
DetNet flow for a given time. packets of a DetNet flow for a given time.
Note: the conditional buffer of POF increases the burstiness of the Note: The conditional delay buffer of the POF increases the
traffic as it adds delay only for some of the packets. burstiness of the traffic as it only adds delay for some of the
packets.
Figure 2 shows the building blocks of a possible POF implementation. Figure 2 shows the building blocks of a possible POF implementation.
+------------+ +--------------+ +------------+ +--------------+
| 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
Figure 2: POF Building Blocks Figure 2: POF Building Blocks
4.3. The Basic POF Algorithm 4.3. The Basic POF Algorithm
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:
* The sequence number of the last forwarded packet (POFLastSent) is * The sequence number of the last forwarded packet ("POFLastSent")
stored for each DetNet Flow. is stored for each DetNet flow.
* The sequence number (seq_num) of a received packet is compared to * The sequence number (seq_num) of a received packet is compared to
that of the last forwarded one (POFLastSent). that of the last forwarded one ("POFLastSent").
* If (seq_num <= POFLastSent + 1) * If (seq_num <= POFLastSent + 1)
- Then the packet is forwarded without buffering and - Then the packet is forwarded without buffering, and
"POFLastSent" is updated (POFLastSent = seq_num). "POFLastSent" is updated (POFLastSent = seq_num).
- Else the received packet is buffered. - Else, the received packet is buffered.
* A buffered packet is forwarded from the buffer when its seq_num * A buffered packet is forwarded from the buffer when its seq_num
becomes equal to "POFLastSent +1," OR a predefined time becomes equal to "POFLastSent + 1" OR a predefined time
("POFMaxDelay") elapses. ("POFMaxDelay") elapses.
* When a packet is forwarded from the buffer "POFLastSent" is * When a packet is forwarded from the buffer, "POFLastSent" is
updated with its seq_num (POFLastSent = seq_num). updated with its seq_num (POFLastSent = seq_num).
Note: the difference of sequence number in consecutive packets is Notes:
bounded due to the history window of the Elimination function before
the POF. Therefore "<=" 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 [IEEE8021CB].
Note2: The algorithm can be extended to cope with multiple failure * The difference between sequence numbers in consecutive packets is
scenarios (i.e., simultaneous packet loss and out-of-order packets), bounded due to the history window of the elimination function
when the expiration of the timer for a packet with sequence number N before the POF. Therefore, "<=" can be evaluated despite the
trigger the release of some number of packets with sequence number circular sequence number space. A possible implementation of the
smaller than N. PEF and the impact of the history window are described in
[IEEE8021CB].
* The basic POF 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 triggers the release of some packets with a
sequence number smaller than N.
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:
* The next received packet is forwarded and the POFLastSent updated * The next received packet is forwarded and the "POFLastSent"
when the POF function was reset OR no packet was received for a updated when the POF is reset OR no packet is received for a
predefined time ("POFTakeAnyTime"). predefined time ("POFTakeAnyTime").
* The reset of POF erases all packets from the time-based buffer * The reset of the POF erases all packets from the time-based buffer
used by POF. used by the POF.
The basic POF algorithm has two parameters to engineer: The basic POF algorithm has two parameters to engineer:
* "POFMaxDelay", which cannot be smaller than the delay difference * "POFMaxDelay", which cannot be smaller than the delay difference
of the paths used by the flow. of the paths used by the flow.
* "POFTakeAnyTime", which is calculated based on several factors, * "POFTakeAnyTime", which is calculated based on several factors,
for example the RECOVERY_TIMEOUT related settings of the for example, the settings of the elimination function(s) relating
Elimination function(s) before the POF, the flow characteristics to RECOVERY_TIMEOUT before the POF, the flow characteristics
(e.g., inter packet time), and the delay difference of the paths (e.g., inter-packet time), and the delay difference of the paths
used by the flow. used by the flow.
Design of these parameters is out-of-scope in this document. Design of these parameters is out of scope for this document.
Note: multiple network failures can impact the POF function (e.g., Note: Multiple network failures can impact the POF (e.g., complete
complete outage of all redundant paths). outage of all redundant paths).
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 "POFMaxDelay" time. In-order packets are not delayed. This basic
basic POF method can be applied in all network scenarios where the POF method can be applied in all network scenarios where the
remaining delay budget of a flow at the POF point is larger than remaining delay budget of a flow at the POF point is larger than
"POFMaxDelay" time. "POFMaxDelay" time.
Figure 3 shows the delay budget relations at the POF point. Figure 3 shows the delay budget situation at the POF point.
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 -------------------/
Figure 3: Delay Budget Relations at the POF Point Figure 3: Delay Budget Situation at the POF Point
4.4. The Advanced POF Algorithm 4.4. The Advanced POF Algorithm
In network scenario where the remaining delay budget of a flow at the In network scenarios where the remaining delay budget of a flow at
POF point is smaller than "POFMaxDelay" time the basic method needs the POF point is smaller than "POFMaxDelay" time, the basic method
extensions. needs extensions.
The issue is that packets on the longest path cannot be buffered in 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 order to keep the delay budget of the flow. It must be noted that
packet (i.e., forwarded over the longest path) needs no buffering as such a packet (i.e., forwarded over the longest path) needs no
it is the "last chance" to deliver a packet with a given sequence buffering as it is the last chance to deliver a packet with a given
number. This is because all replicas are already arrived via shorter sequence number. This is because all replicas already arrived via a
path(s). shorter path(s).
The advanced POF algorithm needs two extensions of the basic POF The advanced POF algorithm requires extensions of the basic POF
algorithm: algorithm:
* to identify the received packet's path at the POF location and * to identify the received packet's path at the POF location and
* to make the value of "POFMaxDelay" for buffered packets path * 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). has used).
By identifying the path of a given packet, the POF algorithm can use The advanced POF algorithm identifies the path of a given packet and
this information to select what predefined time "POFMaxDelay_i" to uses this information to select the predefined time ("POFMaxDelay_i")
apply for the buffered packet. So, in the advanced POF algorithm to apply for the buffered packet. So, in the advanced POF algorithm,
"POFMaxDelay" is an array, that contains the predefined and path "POFMaxDelay" is an array that contains the predefined and path-
specific buffering time for each redundant path of a flow. Values in specific buffering time for each redundant path of a flow. Values in
the "POFMaxDelay" array are engineered to fulfill the delay budget the "POFMaxDelay" array are engineered to fulfill the delay budget
requirement. requirement.
Design of these parameters is out-of-scope in this document. Design of these parameters is out of scope for this document.
Note: for the "Advanced POF Algorithm" the path dependent delays Note: For the advanced POF algorithm, the path-dependent delays might
might result in multiple packets triggering the "maximum delay result in multiple packets triggering the "maximum delay reached" at
reached" at exactly the same time. The transmission order of these exactly the same time. The transmission order of these packets
packets then should be done in their seq_num order. should be done in their seq_num order.
The method for identification of the packet's path at the POF The method for identifying the packet's path at the POF location
location depends on the network scenario. It can be implemented via depends on the network scenario. It can be implemented via various
various techniques, for example using ingress interface information, techniques, for example, using ingress interface information,
encoding the path in the packet itself (e.g., replication functions 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 set a different FlowID per member flow at their egress and such a
in other means. Method for identification of the packet's path is FlowID is used to identify the path of a packet at the POF), or other
out of scope in this document. means. Methods for identifying the packet's path are out of scope
for this document.
Note: in case of using the advanced POF algorithm it might be Note: When using the advanced POF algorithm, it might be advantageous
advantageous to combine PEF and POF locations in the DetNet network, to combine PEF and POF locations in the DetNet network, as this can
as it can simplify the method used for identification of the packet's simplify the method used for identifying the packet's path at the POF
path at the POF location. location.
4.5. Further enhancements of POF algorithms 4.5. Further Enhancements of the POF Algorithms
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 more sophisticated implementation. Such enhancements could, for
example react better after some failure scenarios (e.g., complete 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 outage of all paths of a DetNet flow) and can be dependent on the PEF
implementation. implementation.
The challenge for POF initialization is that for example after a The challenge for POF initialization is that it is not known whether
reset it is not known whether the first received packet is in-order the first received packet is in-order or out-of-order (for example,
or out-of-order. The original initialization (see before) considers after a reset). The original initialization (see Section 4.3)
the first packet as in-order, so out-of-order packet(s) during considers the first packet as in-order, so out-of-order packet(s)
"POFMaxTime"/"POFMaxTime_path_i" time - after the first packet was during "POFMaxTime"/"POFMaxTime_path_i" time -- after the first
received - cannot be corrected. Motivation behind such an packet is received -- cannot be corrected. The motivation behind
initialization is POF implementation simplicity. such an initialization is simplicity of POF implementation.
A possible enhancement of POF initialization works as follows: A possible enhancement of POF initialization works as follows:
* After a reset all received packets are buffered with their * After a reset, all received packets are buffered with their
predefined timer ("POFMaxTime"/"POFMaxTime_path_i"). predefined timer ("POFMaxTime"/"POFMaxTime_path_i").
* No basic/advanced POF rules are applied until the first timer * No basic or advanced POF rules are applied until the first timer
expires. expires.
* When the first timer expires the packet with lowest seq_num in * When the first timer expires, the packet with lowest seq_num in
buffer is selected, forwarded, and "POFLastSent" is set with its the buffer is selected and forwarded, and "POFLastSent" is set
seq_num. with its seq_num.
* The basic/advanced POF rules are applied for the packet(s) in the * The basic or advanced POF rules are applied for the packet(s) in
buffer and the subsequently received packets. the buffer and the subsequently received packets.
4.6. Selecting and using the POF algorithm 4.6. Selecting and Using the POF Algorithms
The selection of the POF algorithm depends on the network scenario The selection of the POF algorithm depends on the network scenario
and the remaining delay budget of a flow. Using POF and calculating and the remaining delay budget of a flow. Using the POF algorithms
its parameters require proper design. Knowing the path delay and calculating their parameters require proper design. Knowing the
difference is essential for the POF algorithms described here. path delay difference is essential for the POF algorithms described
Failure scenarios breaking the design assumptions can impact the here. Failure scenarios breaking the design assumptions can impact
result of POF (e.g., packet received out of the expected worst-case the result of the POF (e.g., packet received out of the expected
delay window - calculated based on the path delay difference - can worst-case delay window -- calculated based on the path delay
result in unwanted out-of-order delivery). difference -- can result in unwanted out-of-order delivery).
In DetNet scenarios there is always an Elimination function before In DetNet scenarios, there is always an elimination function before
the POF (therefore duplicates are not considered by the POF). the POF (therefore, duplicates are not considered by the POF).
Implementing them together in the same node allows POF to consider Implementing them together in the same node allows the POF to
PEF events/states during the re-ordering. For example, under normal consider PEF events/states during the reordering. For example, under
circumstances the difference of sequence number in consecutive normal circumstances, the difference between sequence numbers in
packets is bounded due to the history window of PEF. However, in consecutive packets is bounded due to the history window of the PEF.
some scenarios (e.g., reset of sequence number) the difference can be However, in some scenarios (e.g., reset of sequence number), the
much larger than the history window size. difference can be much larger than the size of the history window.
5. Control and Management Plane Parameters for POF 5. Control and Management Plane Parameters for POF
POF algorithms needs setting of the following parameters: POF algorithms require the following parameters to be set:
* Basic POF * Basic POF
- "POFMaxDelay" - "POFMaxDelay"
- "POFTakeAnyTime" - "POFTakeAnyTime"
* Advanced POF * Advanced POF
- "POFMaxDelay_i" for each possible path i - "POFMaxDelay_i" for each possible path i
- "POFTakeAnyTime" - "POFTakeAnyTime"
- Network path identification related configuration(s) - Configuration(s) related to network path identification
Note, that in a proper design "POFTakeAnyTime" is always larger than Note: In a proper design, "POFTakeAnyTime" is always larger than
"POFMaxDelay". "POFMaxDelay".
6. Security Considerations 6. Security Considerations
PREOF related security considerations (including POF) are described PREOF-related security considerations (including POF) are described
in section 3.3 of [RFC9055]. There are no additional POF related in Section 3.3 of [RFC9055]. There are no additional POF-related
security considerations originating from this document. security considerations originating from this document.
7. IANA Considerations 7. IANA Considerations
This document makes no IANA requests. This document has no IANA actions.
8. Acknowledgements
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.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655, "Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019, DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>. <https://www.rfc-editor.org/info/rfc8655>.
[RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker, [RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker,
"Deterministic Networking (DetNet) Security "Deterministic Networking (DetNet) Security
Considerations", RFC 9055, DOI 10.17487/RFC9055, June Considerations", RFC 9055, DOI 10.17487/RFC9055, June
2021, <https://www.rfc-editor.org/info/rfc9055>. 2021, <https://www.rfc-editor.org/info/rfc9055>.
9.2. Informative References 8.2. Informative References
[IEEE8021CB] [IEEE8021CB]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks -- Frame Replication and Elimination for networks -- Frame Replication and Elimination for
Reliability", DOI 10.1109/IEEESTD.2017.8091139, October Reliability", IEEE Std 802.1CB-2017,
2017, DOI 10.1109/IEEESTD.2017.8091139, October 2017,
<https://standards.ieee.org/standard/802_1CB-2017.html>. <https://standards.ieee.org/standard/802_1CB-2017.html>.
[IEEEP8021CBcv] [IEEEP8021CBcv]
Kehrer, S., "FRER YANG Data Model and Management IEEE, "IEEE Standard for Local and metropolitan area
Information Base Module", IEEE P802.1CBcv networks -- Frame Replication and Elimination for
/D1.2 P802.1CBcv, March 2021, Reliability - Amendment 1: Information Model, YANG Data
<https://www.ieee802.org/1/files/private/cv-drafts/d1/802- Model, and Management Information Base Module", IEEE Std
1CBcv-d1-2.pdf>. 802.1CBcv-2001, DOI 10.1109/IEEESTD.2022.9715061, February
2022, <https://standards.ieee.org/ieee/802.1CBcv/7285/>.
Acknowledgements
Authors extend their appreciation to Gyorgy Miklos, Ehsan
Mohammadpour, Ludovic Thomas, Greg Mirsky, Jeong-dong Ryoo, Fan Yang,
Toerless Eckert, Norman Finn, and Ethan Grossman for their insightful
comments and productive discussion that helped to improve the
document.
Authors' Addresses Authors' Addresses
Balazs Varga (editor) Balazs Varga (editor)
Ericsson Ericsson
Budapest Budapest
Magyar Tudosok krt. 11. Magyar Tudosok krt. 11.
1117 1117
Hungary Hungary
Email: balazs.a.varga@ericsson.com Email: balazs.a.varga@ericsson.com
 End of changes. 91 change blocks. 
256 lines changed or deleted 261 lines changed or added

This html diff was produced by rfcdiff 1.48.