Skip to main content

Deterministic Networking (DetNet): Packet Ordering Function
draft-varga-detnet-pof-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Balazs Varga , János Farkas , Stephan Kehrer , Tobias Heer
Last updated 2021-04-19
Replaced by draft-ietf-detnet-pof
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-varga-detnet-pof-00
DetNet                                                     B. Varga, Ed.
Internet-Draft                                                 J. Farkas
Intended status: Informational                                  Ericsson
Expires: October 21, 2021                                      S. Kehrer
                                                                 T. Heer
                                  Hirschmann Automation and Control GmbH
                                                          April 19, 2021

      Deterministic Networking (DetNet): Packet Ordering Function
                       draft-varga-detnet-pof-00

Abstract

   Replication and Elimination functions of DetNet [RFC8655] may result
   in out-of-order packets, which may not be acceptable for some time-
   sensitive applications.  The Packet Ordering Function (POF) algorithm
   described herein enables to restore the correct packet order when
   replication and elimination functions are used in DetNet networks.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 21, 2021.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must

Varga, et al.           Expires October 21, 2021                [Page 1]
Internet-Draft                 DetNet POF                     April 2021

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Terms Used in This Document . . . . . . . . . . . . . . .   3
     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   3.  Requirements on POF Implementations . . . . . . . . . . . . .   4
   4.  POF Algorithms  . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  POF building blocks . . . . . . . . . . . . . . . . . . .   4
     4.2.  The Basic POF Algorithm . . . . . . . . . . . . . . . . .   5
     4.3.  The Advanced POF Algorithm  . . . . . . . . . . . . . . .   7
     4.4.  Further enhancements of POF algorithms  . . . . . . . . .   7
     4.5.  Selecting and using the POF algorithm . . . . . . . . . .   8
   5.  Control and Management Plane Parameters for POF . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   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.  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
   [IEEE8021CB] and the related YANG model is defined in
   [IEEEP8021CBcv].

   In general, use of per packet replication and elimination functions
   may result in out-of-order delivery of packets, which may not be
   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 [RFC8655] the external observable result of a POF function, i.e.,
   that packets are reordered, but without any implementation details.

   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

Varga, et al.           Expires October 21, 2021                [Page 2]
Internet-Draft                 DetNet POF                     April 2021

   TCP stack when ackets are sent to application layer) and not within a
   network in nodes acting at the Layer-2 or Layer-3 OSI layers.

   Figure 1 shows a DetNet flow on which PREOF functions are applied
   during forwarding from source to destination.

                                          +------------+
                +---------------E----+    |            |
   +----+       |               |    +----R---+        |          +----+
   |src |-------R           +---+             |        E-----O----+ dst|
   +----+       |           |                 E--------+          +----+
                +-----------R                 |
                            +-----------------+

   R: replication point (PRF)
   E: elimination point (PEF)
   O: ordering function (POF)

               Figure 1: PREOF scenario in a DetNet network

   Important to note, that application may react differently on out-of-
   order delivery.  A single out-of-order packet (E.g., packet order:
   #1, #3, #2, #4, #5) may be interpreted by some applications as a
   single error, but some other applications may treat it as a 3 errors
   in-a-row situation.  3 errors in-a-row is a usual error threshold and
   may cause the application to stop (e.g., to tranistion to a fail safe
   state).

2.  Terminology

2.1.  Terms Used in This Document

   This document uses the terminology established in the DetNet
   architecture [RFC8655], and the reader is assumed to be familiar with
   that document and its terminology.

2.2.  Abbreviations

   The following abbreviations are used in this document:

   DetNet        Deterministic Networking.

   PEF           Packet Elimination Function.

   POF           Packet Ordering Function.

Varga, et al.           Expires October 21, 2021                [Page 3]
Internet-Draft                 DetNet POF                     April 2021

   PREOF         Packet Replication, Elimination and Ordering Functions.

   PRF           Packet Replication Function.

2.3.  Requirements Language

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Requirements on POF Implementations

   The requirements on a POF function are:

   o  to solve the out-of-order delivery problem of the Replication and
      Elimination functions of DetNet networks.

   o  to consider the delay bound requirement of a DetNet Flow.

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

   o  to add only minimal or no delay to the forwarding process of
      packets.

   o  not to require synchronization between PREOF nodes.

4.  POF Algorithms

4.1.  POF building blocks

   The method described herein provides POF for DetNet networks.  The
   configuration parameters of POF can be derived during engineering the
   DetNet flow through the network.

   The POF method is provided via:

   1.  Conditional buffer: for buffering the out-of-order packets of a
       DetNet flow for a given time.

   2.  Delay calculator: buffering time considers (i) the latency
       difference of paths used for forwarding the replicated packets
       and (ii) the bounded delay requirement of the given DetNet flow.

   Figure 2 shows the building blocks of a possible POF implementation.

Varga, et al.           Expires October 21, 2021                [Page 4]
Internet-Draft                 DetNet POF                     April 2021

                    +------------+        +--------------+
                    | Delay calc |        | Conditional  |
                 +--| for packet >--->>---| Delay Buffer >---+
                 |  +------------+        +--------------+   |
                 |                                           |
          +------^--------+                                  |
     ->>--| POF selector  >----------------------------------+-->>----
          | (Flow ident.) |
          +---------------+

     ->>- packet flow

                       Figure 2: POF Building Blocks

4.2.  The Basic POF Algorithm

   The basic POF algorithm delays all out-of-order packets until all
   previous packet arrives or a given time (POFMaxDelay) elapses.  The
   basic POF algorithm works as follows:

   o  The sequence number of the last forwarded packet (POFLastSent) is
      stored for each DetNet Flow.

   o  The sequence number (seq_num) of a received packet is compared to
      that of the last forwarded one (POFLastSent).

   o  If (seq_num <= POFLastSent + 1)

      *  Then the packet is forwarded and "POFLastSent" is updated
         (POFLastSent = seq_num).

      *  Else the received packet is buffered until a predefined time
         ("POFMaxDelay") elapses OR its seq_num becomes equal to
         "POFLastSent + 1".

   o  When a packet is forwarded from the buffer "POFLastSent" is
      updated with its seq_num (POFLastSent = seq_num).

   Note: 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 despite of the circular
   sequence number space.

   The state used by the basic POF algorithm (i.e., "POFLastSent") needs
   initialization and maintenance.  This works as follows:

Varga, et al.           Expires October 21, 2021                [Page 5]
Internet-Draft                 DetNet POF                     April 2021

   o  The next received packet must be forwarded and the POFLastSent
      updated wheno the POF function was reset OR no packet was received
      for a predefined time ("POFTakeAnyTime").

   o  The reset of POF erases all frames/packets from the time-based
      buffer used by POF.

   The basic POF algorithm has two parameters to engineer:

   o  "POFMaxDelay", which cannot be smaller than the latency difference
      of the paths used by the flow.

   o  "POFTakeAnyTime", which is calculated based on several factors,
      for example the RECOVERY_TIMEOUT related settings of the
      Elimination function(s) before the POF, the flow characteristics
      (e.g., inter frame/packet time) and the latency difference of the
      paths used by the flow.

   Design of these parameters is out-of-scope in this document.

   Note: multiple network failures may impact the POF function (e.g.,
   complete outage of all redundant paths).

   The basic POF algorithm increases the latency of packets with maximum
   "POFMaxDelay" time.  Packets being in order are not delayed.  This
   basic POF method can be applied in all network scenarios where the
   remaining delay budget of a flow at the POF point is larger than
   "POFMaxDelay" time.

   Figure 3 shows the delay budget relations at the POF point.

                           Path latency
                            difference
                          /-------------/
  <-- fast path latency -->             /-- remaining latency budget --/

  |-----------------------|-------------|------------------------------|
  0                                                                    t

  <---------- slow path latency -------->

  /------------------- latency budget at POF point --------------------/

            Figure 3: Latency Budget Relations at the POF Point

Varga, et al.           Expires October 21, 2021                [Page 6]
Internet-Draft                 DetNet POF                     April 2021

4.3.  The Advanced POF Algorithm

   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.

   The issue is that packets on the longest path cannot be buffered in
   order to keep delay budget of the flow.  It must be noted that such a
   packet (i.e., forwarded over the longest path) needs no buffering as
   it is the "last chance" to deliver a packet with a given sequence
   number.  This is because all replicas already must be arrived via
   shorter path(s).

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

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

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

   By identifying the path of a given frame, the POF algorithm can use
   this information to select what predefined time "POFMaxDelay_i" to
   apply for the buffered frame/packet.  So, in the advanced POF
   algorithm "POFMaxDelay" is an array, that contains the predefined and
   path specific buffering time for each redundant path of a flow.
   Values in the "POFMaxDelay" array are engineered to fulfill the delay
   budget requirement.

   The method for identification of the packet's path at the POF
   location depends on the network scenario.  It can be implemented via
   various techniques, for example using ingress interface information,
   encoding the path in the packet itself (e.g., replication functions
   can set different FlowID per egress what can be used as a PathID), or
   in other means.  Method for identification of the packet's path is
   out of scope in this document.

   Note: in case of using the advanced POF algorithm it might be
   advantageous to combine PEF and POF locations in the DetNet network,
   as it can simplify the method used for identification of the packet's
   path at the POF location.

4.4.  Further enhancements of POF algorithms

   POF algorithms can be further enhanced by distinguishing the case of
   initialization from normal operation at the price of more states and
   more sophisticated implementation.  Such enhancements could for

Varga, et al.           Expires October 21, 2021                [Page 7]
Internet-Draft                 DetNet POF                     April 2021

   example react better after some failure scenarios (e.g., complete
   outage of all paths of a DetNet flow) and may be dependent on the PEF
   implementation.

4.5.  Selecting and using the POF algorithm

   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 may impact the
   result of POF (e.g., packet received out of the expected worst-case
   latency window - calculated based on the path delay difference - may
   result in unwanted out-of-order delivery).

   There is always an Elimination function before the POF (therefore
   duplicates are not considered by the POF).  Implementing them
   together in the same node allows POF to consider PEF events/states
   during the re-ordering.  For example, under normal circumstances the
   difference of sequence number in consecutive packets is bounded due
   to the history window of PEF.  However, in some scenarios (e.g.,
   reset of sequence number) the difference can be much larger than the
   history window size.

5.  Control and Management Plane Parameters for POF

   POF algorithms needs setting of the following parameters:

   o  Basic POF

      *  "POFMaxDelay"

      *  "POFTakeAnyTime"

   o  Advanced POF

      *  "POFMaxDelay_i"

      *  "POFTakeAnyTime"

      *  Network path identification related configuration(s)

   Note, that in a proper design "POFTakeAnyTime" must be always larger
   than "POFMaxDelay".

Varga, et al.           Expires October 21, 2021                [Page 8]
Internet-Draft                 DetNet POF                     April 2021

6.  Security Considerations

   There are no POF related security considerations for DetNet.

7.  IANA Considerations

   This document makes no IANA requests.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", RFC 8655,
              DOI 10.17487/RFC8655, October 2019,
              <https://www.rfc-editor.org/info/rfc8655>.

8.2.  Informative References

   [IEEE8021CB]
              IEEE 802.1, "Standard for Local and metropolitan area
              networks - Frame Replication and Elimination for
              Reliability (IEEE Std 802.1CB-2017)", 2017,
              <http://standards.ieee.org/about/get/>.

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

Authors' Addresses

Varga, et al.           Expires October 21, 2021                [Page 9]
Internet-Draft                 DetNet POF                     April 2021

   Balazs Varga (editor)
   Ericsson
   Magyar Tudosok krt. 11.
   Budapest  1117
   Hungary

   Email: balazs.a.varga@ericsson.com

   Janos Farkas
   Ericsson
   Magyar Tudosok krt. 11.
   Budapest  1117
   Hungary

   Email: janos.farkas@ericsson.com

   Stephan Kehrer
   Hirschmann Automation and Control GmbH
   Stuttgarter Strasse 45-51.
   Neckartenzlingen  72654
   Germany

   Email: Stephan.Kehrer@belden.com

   Tobias Heer
   Hirschmann Automation and Control GmbH
   Stuttgarter Strasse 45-51.
   Neckartenzlingen  72654
   Germany

   Email: Tobias.Heer@belden.com

Varga, et al.           Expires October 21, 2021               [Page 10]