DetNet                                                          B. Varga
Internet-Draft                                                 J. Farkas
Intended status: Informational                                 G. Mirsky
Expires: 25 April 2022                                          Ericsson
                                                         22 October 2021


 Deterministic Networking (DetNet): OAM Functions for The Service Sub-
                                 Layer
              draft-varga-detnet-service-sub-layer-oam-01

Abstract

   Operation, Administration, and Maintenance (OAM) tools are essential
   for a deterministic network.  The DetNet architecture [RFC8655] has
   defined two sub-layers: (1) DetNet service sub-layer and (2) DetNet
   forwarding sub-layer.  OAM mechanisms exist for the DetNet forwarding
   sub-layer.  Nonetheless, OAM for the service sub-layer might require
   new extensions to the existing OAM protocols.  This draft presents an
   analysis of OAM procedures for the DetNet service sub-layer
   functions.

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 25 April 2022.

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



Varga, et al.             Expires 25 April 2022                 [Page 1]


Internet-Draft        DetNet Service-Sub-layer OAM          October 2021


   and restrictions with respect to this document.  Code Components
   extracted from this document must 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.  DetNet Service Sub-layer OAM Challenges . . . . . . . . . . .   4
     3.1.  Illustrative example  . . . . . . . . . . . . . . . . . .   4
     3.2.  DetNet Service Sub-layer Specifics for OAM  . . . . . . .   5
     3.3.  Information Needed during DetNet OAM Packet Processing  .   6
     3.4.  A Possible Format of DetNet Associated Channel Header
           (d-ACH) . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Requirements on OAM for DetNet Service Sub-layer  . . . . . .   7
   5.  DetNet PING . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  OAM processing at the DetNet service sub-layer  . . . . .   9
       5.2.1.  Relay node with PRF . . . . . . . . . . . . . . . . .   9
       5.2.2.  Relay node with PEF . . . . . . . . . . . . . . . . .   9
       5.2.3.  Relay node with POF . . . . . . . . . . . . . . . . .  10
       5.2.4.  Relay node without PREOF  . . . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  DetNet MPLS OAM Flags Registry  . . . . . . . . . . . . .  11
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   The DetNet Working Group has defined two sub-layers: (1) DetNet
   service sub-layer, at which a DetNet service (e.g., service
   protection) is provided and (2) DetNet forwarding sub-layer, which
   optionally provides resource allocation for DetNet flows over paths
   provided by the underlying network.  In [RFC8655] new DetNet-specific
   functions have been defined for the DetNet service sub-layer, namely
   PREOF (a collective name for Packet Replication, Elimination, and
   Ordering Functions).






Varga, et al.             Expires 25 April 2022                 [Page 2]


Internet-Draft        DetNet Service-Sub-layer OAM          October 2021


   Framework of Operations, Administration and Maintenance (OAM) for
   Deterministic Networking (DetNet) is described in
   [I-D.ietf-detnet-oam-framework].  OAM for the DetNet MPLS data plane
   is described in [I-D.ietf-detnet-mpls-oam] and OAM for the DetNet IP
   data plane is described in [I-D.ietf-detnet-mpls-oam].

   This draft has been submitted as an individual contribution to OAM
   discussions, in particular, to kick-off Working Group discussions on
   introducing OAM functions for the DetNet service sub-layer.  It is
   also up to the Working Group discussions to which draft parts of this
   contribution may go, if any.

   The OAM functions for the DetNet service sub-layer allow, for
   example, to recognize/discover DetNet relay nodes, to get information
   about their configuration, and to check their operation or status.
   Furthermore, the OAM functions for the DetNet service sub-layer need
   to meet new challenges (see section Section 3) and requirements (see
   section Section 4) introduced by PREOF.

   An approach described in this draft introduces a new OAM shim layer
   to achieve OAM for the DetNet service sub-layer.  In the rest of the
   draft, this approach is referred to as "DetNet PING", which is an in-
   band OAM approach, i.e., the OAM packets follow precisely the same
   path as the data packets of the corresponding DetNet flow(s) The OAM
   packets provide DetNet service sub-layer specific information, like:

   *  Identity of a DetNet service sub-layer node.

   *  Discover Ingress/Egress flow-specific configuration of a DetNet
      service sub-layer node.

   *  Detect the status of the flow-specific service sub-layer function.

   DetNet PING applies both to IP and MPLS DetNet data planes.

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.



Varga, et al.             Expires 25 April 2022                 [Page 3]


Internet-Draft        DetNet Service-Sub-layer OAM          October 2021


   PEF           Packet Elimination Function.

   POF           Packet Ordering Function.

   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.  DetNet Service Sub-layer OAM Challenges

3.1.  Illustrative example

   This section introduces an example that is used to explain the DetNet
   Service Sub-layer OAM challenges.  Figure 1 shows a DetNet flow on
   which PREOF functions are applied during forwarding from source to
   destination.



























Varga, et al.             Expires 25 April 2022                 [Page 4]


Internet-Draft        DetNet Service-Sub-layer OAM          October 2021


        <------------------------ App Flow ----------------------->

                /-------------- DetNet domain -----------------/
                 <-------------- DetNet flow ----------------->

                                                P6
                     P1              P4   +------------+
                +--------------E1----+    |  P7        |
   +----+       |               |    +---R3---+        |  P9      +----+
   |src |------R1           +---+             |        E3----O1---+ dst|
   +----+       |    P2     |  P3             E2-------+          +----+
                +----------R2        P5       |   P8
                            +-----------------+

                 <----- P1 ---->  <- P4 -> <--- P6 ----> <-P9->
                 <-- P2 -->  <P3> <- P4 -> <P7> <- P8 -> <-P9->
                 <-- P2 -->  <----- P5 ------>  <- P8 -> <-P9->

                |------------ G1 DetNet graph ---------------->

   R: replication point (PRF)              P: forwarding sub-layer path
   E: elimination point (PEF)              G: service sub-layer graph
   O: ordering function (POF)



                Figure 1: PREOF scenario in a DetNet network

   DetNet service sub-layer nodes are interconnected by DetNet
   forwarding sub-layer paths.  DetNet forwarding sub-layer path (e.g.,
   P1 = R1->E1 path, P4 = E1->R3 path) may contain multiple transit
   nodes.  A DetNet forwarding sub-layer path is used by a member flow
   and terminated by relay nodes (see [RFC8655] for relay node
   definition).

   A DetNet service sub-layer graph includes all relay nodes and the
   interconnecting forwarding sub-layer paths.  This graph can be also
   called as "PREOF graph" and it describes the compound flow as a
   whole.

3.2.  DetNet Service Sub-layer Specifics for OAM

   Several DetNet Service Sub-layer specifics have to be considered for
   OAM.

   1.  The service sub-layer graph is segmented into multiple parts, as
       forwarding sub-layer paths are terminated at DetNet relay nodes.




Varga, et al.             Expires 25 April 2022                 [Page 5]


Internet-Draft        DetNet Service-Sub-layer OAM          October 2021


   2.  These are particular characteristics of DetNet PW:

       1.  PREOF acts as per-packet protection.  PEF is a brand-new
           functionality at network layer, due to the per-packet merge
           action.

       2.  All paths are active and forward traffic.  These paths may
           have a different number of hops.

       3.  Mandatory usage of a sequence number.

   The above specifics have to be considered in combination with the
   requirement that DetNet OAM and DetNet data flows MUST receive the
   same treatment.  OAM packets MUST follow precisely the same graph as
   the monitored DetNet flow(s).

3.3.  Information Needed during DetNet OAM Packet Processing

   This section collects some questions that have been already discussed
   by the DetNet WG and/or require further discussions by the WG.  The
   section is structured in the form of a question list.

   Question-1: Injecting OAM traffic in a DetNet flow?  A DetNet data
   flow has a continuous Sequence Number.  In order not to spoil that,
   the injected OAM packets require OAM-specific Sequence Number added.
   (See also Section Section 5.)

   Question-2: How to process OAM packets by DetNet service sub-layer
   nodes?  In order to cover the DetNet forwarding graph by OAM, PREOF
   has to be executed in an OAM specific manner (i.e., PREOF uses a
   separate SeqNum space for OAM.  See details in Section 5.

   Note: the question list is non-exhaustive.

3.4.  A Possible Format of DetNet Associated Channel Header (d-ACH)

   Figure 2 shows a possible format of the DetNet Associated Channel
   Header (d-ACH).



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1|Version|Sequence Number|         Channel Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Node ID               |Level|  Flags  |Ses.ID |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Varga, et al.             Expires 25 April 2022                 [Page 6]


Internet-Draft        DetNet Service-Sub-layer OAM          October 2021


             Figure 2: DetNet Associated Channel Header Format

   The d-ACH encodes the following fields:

   *  Bits 0..3 MUST be 0b0001.  This value of the first nibble allows
      the packet to be distinguished from an IP packet [RFC4928] and a
      DetNet data packet [RFC8964].

   *  Version: this is the version number of the d-ACH.  This
      specification defines version 0x1.

   *  Sequence Number: this is an unsigned eight-bit field.  The
      sequence number space is a circular one with no restriction on the
      initial value.  The originator DetNet node MUST set the value of
      the Sequence Number field before the transmission of a packet.
      The originator node MUST increase the value of the Sequence Number
      field by 1 for each active OAM packet.

   *  Channel Type: encodes the value of DetNet Associated Channel Type
      is one of the values defined in the IANA PW Associated Channel
      Type registry.

   *  Node ID: it is an unsigned 20-bits field.  The value of the Node
      ID field identifies the DetNet node that originated the packet.
      Methods to distribute Node ID are outside the scope of this
      specification.

   *  Level: is a 3-bit field.

   *  Flags: is a 5-bit field.  Section 7.1 creates an IANA registry for
      new flags to be defined.

   *  Session ID: is a 4-bit field.

   The DetNet flow, according to [RFC8964], is identified by the S-label
   that MUST be at the bottom of the stack.  An active DetNet OAM packet
   MUST include d-ACH immediately following the S-label.

4.  Requirements on OAM for DetNet Service Sub-layer

   [Editor's note: The content of this section has been discussed and
   the outcome of the discussion has been documented in
   [I-D.ietf-detnet-oam-framework].]

   The requirements on OAM for a DetNet relay node are:

   1.  to provide OAM functions for the DetNet service sub-layer.




Varga, et al.             Expires 25 April 2022                 [Page 7]


Internet-Draft        DetNet Service-Sub-layer OAM          October 2021


   2.  to discover DetNet relay nodes in a DetNet network.

   3.  to collect DetNet service sub-layer specific (e.g.,
       configuration/operation/status) information from DetNet relay
       nodes.

   4.  to work for both DetNet data planes: (1) MPLS and (2) IP.

5.  DetNet PING

5.1.  Overview

   The "DetNet PING" approach uses two types of OAM packets: (1) DetNet-
   Echo-Request and (2) DetNet-Echo-Reply.  Their encapsulation is
   identical to that of the corresponding DetNet data flow, so they
   follow precisely the same path as the packets of the corresponding
   DetNet data flow.  They target DetNet service sub-layer entities, so
   they may not be recognized as OAM packets by entities not
   implementing DetNet service sub-layer for a packet flow (e.g.,
   transit nodes).  Other entities treat them as packets belonging to
   the corresponding DetNet data flow.

   The following relay node roles can be distinguished:

   1.  DetNet PING originator node,

   2.  Intermediate DetNet service sub-layer node,

   3.  DetNet PING targeted node.

   An originator node sends (generates) DetNet-Echo-Request packet(s).
   DetNet-Echo-Request packet contains an OAM specific "PINGSeqNum",
   which can be used by the DetNet service sub-layer of relay nodes.
   Note that "PINGSeqNum" is originator specific.

   An intermediate DetNet service sub-layer node executes DetNet flow-
   specific service sub-layer functionality.  Packet processing may be
   done in an OAM specific manner (see details in Section 5.2).

   A targeted node answers with DetNet-Echo-Reply packet for each
   DetNet-Echo-Request.  DetNet-Echo-Reply packet provides DetNet
   service sub-layer specific information on (i) identities of DetNet
   service sub-layer node (e.g., Node-ID, local Flow-ID), (ii) ingress/
   egress flow related configuration (e.g., in/out member flow specific
   information (including forwarding sub-layer specifics)), and (iii)
   status of service sub-layer function (e.g., local PxF-ID, Action-
   Type=x, operational status, value of key state variable(s), function
   related counters).



Varga, et al.             Expires 25 April 2022                 [Page 8]


Internet-Draft        DetNet Service-Sub-layer OAM          October 2021


5.2.  OAM processing at the DetNet service sub-layer

   Detailed OAM packet processing rules of various DetNet relay nodes
   are described in the following sections.

5.2.1.  Relay node with PRF

   A DetNet relay node with PRF processes DetNet OAM packets in a
   stateless manner.

   If the relay node with PRF is the target of a DetNet-Echo-Request
   packet, then the DetNet-Echo-Request packet MUST NOT be further
   forwarded, and a DetNet Echo-Reply packet MUST be generated.  If the
   relay node with PRF is not the target of a DetNet Echo-Request
   packet, then the DetNet Echo-Request packet MUST be sent over all
   DetNet flow specific member flow paths (i.e., it is replicated).

   A DetNet Echo-Reply packet MUST contain the following information:

   *  Identities related to the DetNet service sub-layer node (e.g.,
      Node-ID, local Flow-ID),

   *  Ingress/Egress flow related configuration (e.g., in/out member
      flow specific information (including forwarding sub-layer
      specifics)),

   *  Status of service sub-layer function (e.g., local PRF-ID, Action-
      Type=Replication, operational status, value of the flow related
      key state variable (e.g., "GenSeqNum" in [IEEE8021CB]).

   A DetNet Echo-Reply packet MAY contain the following information:

   *  PRF related local counters.

5.2.2.  Relay node with PEF

   A DetNet relay node with PEF processes DetNet OAM packets in a
   stateful manner.

   If the relay node with PEF is the target of DetNet-Echo-Request
   packet, then the DetNet Echo-Request packet MUST NOT be further
   forwarded and an DetNet Echo-Reply packet MUST be generated.  If the
   relay node with PEF is not the target of DetNet Echo-Request packet,
   then elimination MUST be executed on the DetNet Echo-Request
   packet(s) using the OAM specific "PINGSeqNum" in the packet.  So only
   a single DetNet Echo-Request packet is forwarded and all further
   replicas (having the same originator's sequence number) MUST be
   discarded.



Varga, et al.             Expires 25 April 2022                 [Page 9]


Internet-Draft        DetNet Service-Sub-layer OAM          October 2021


   Note, PEF MAY use a simplified elimination algorithm for DetNet Echo-
   Request packets (e.g., "MatchRecoveryAlgorithm" in [IEEE8021CB]) as
   OAM is a slow protocol.

   A DetNet-Echo-Reply packet MUST contain the following information:

   *  Identities related to the DetNet service sub-layer node (e.g.,
      Node-ID, local Flow-ID),

   *  Ingress/Egress flow related configuration (e.g., in/out member
      flow specific information (including forwarding sub-layer
      specifics)) ,

   *  Status of service sub-layer function (e.g., local PEF-ID, Action-
      Type=Elimination, operational status, value of the flow related
      key state variable (e.g., "RecovSeqNum" in [IEEE8021CB]).

   A DetNet Echo-Reply packet MAY contain the following information:

   *  PEF-related local counters.

5.2.3.  Relay node with POF

   A DetNet relay node with POF processes DetNet OAM packets in a
   stateless manner.

   If the relay node with POF is the target of DetNet Echo-Request
   packet, then the DetNet Echo-Request packet MUST NOT be further
   forwarded and a DetNet Echo-Reply packet MUST be generated.  If the
   relay node with POF is not the target of DetNet-Echo-Request packet,
   then the DetNet Echo-Request packet(s) MUST be forwarded without any
   POF-specific action.

   A DetNet Echo-Reply packet MUST contain the following information:

   *  Identities of the DetNet service sub-layer node (e.g., Node-ID,
      local Flow-ID),

   *  Ingress/Egress flow related configuration (e.g., in/out member
      flow specific information (including forwarding sub-layer
      specifics)) ,

   *  Status of service sub-layer function (e.g., local POF-ID, Action-
      Type=Ordering, operational status, value of the flow related key
      state variable (e.g., "POFLastSent" in [I-D.varga-detnet-pof]).

   A DetNet Echo-Reply packet MAY contain the following information:




Varga, et al.             Expires 25 April 2022                [Page 10]


Internet-Draft        DetNet Service-Sub-layer OAM          October 2021


   *  POF-related local counters.

5.2.4.  Relay node without PREOF

   A DetNet relay node without PREOF processes DetNet OAM packets in a
   stateless manner.

   If the relay node without PREOF is the target of DetNet Echo-Request
   packet, then the DetNet Echo-Request packet MUST NOT be further
   forwarded and an DetNet Echo-Reply packet MUST be generated.  If the
   relay node without PREOF is not the target of DetNet-Echo-Request
   packet, then the DetNet-Echo-Request packet(s) MUST be forwarded (as
   any data packets of the related DetNet flow).

   A DetNet Echo-Reply packet MUST contain the following information:

   *  Identities of the DetNet service sub-layer node (e.g., Node-ID,
      local Flow-ID),

   *  Ingress/Egress flow-related configuration (e.g., in/out member
      flow specific information (including forwarding sub-layer
      specifics)) .

6.  Security Considerations

   Tbd.

7.  IANA Considerations

7.1.  DetNet MPLS OAM Flags Registry

   This document describes a new IANA-managed registry to identify
   DetNet MPLS OAM Flags Bits.  The registration procedure is "IETF
   Review" [RFC8126].  The registry name is "DetNet MPLS OAM Flags".
   There are five flags in the five-bit Flags field.

8.  Acknowledgements

   Authors extend their appreciation to Janos Szabo and Gyorgy Miklos
   for their insightful comments and productive discussion that helped
   to improve the document.

9.  References

9.1.  Normative References






Varga, et al.             Expires 25 April 2022                [Page 11]


Internet-Draft        DetNet Service-Sub-layer OAM          October 2021


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

   [RFC4928]  Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
              Cost Multipath Treatment in MPLS Networks", BCP 128,
              RFC 4928, DOI 10.17487/RFC4928, June 2007,
              <https://www.rfc-editor.org/info/rfc4928>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

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

   [RFC8964]  Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,
              S., and J. Korhonen, "Deterministic Networking (DetNet)
              Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January
              2021, <https://www.rfc-editor.org/info/rfc8964>.

9.2.  Informative References

   [I-D.ietf-detnet-ip-oam]
              Mirsky, G., Chen, M., and D. Black, "Operations,
              Administration and Maintenance (OAM) for Deterministic
              Networks (DetNet) with IP Data Plane", Work in Progress,
              Internet-Draft, draft-ietf-detnet-ip-oam-03, 19 September
              2021, <https://www.ietf.org/archive/id/draft-ietf-detnet-
              ip-oam-03.txt>.

   [I-D.ietf-detnet-mpls-oam]
              Mirsky, G. and M. Chen, "Operations, Administration and
              Maintenance (OAM) for Deterministic Networks (DetNet) with
              MPLS Data Plane", Work in Progress, Internet-Draft, draft-
              ietf-detnet-mpls-oam-05, 18 October 2021,
              <https://www.ietf.org/archive/id/draft-ietf-detnet-mpls-
              oam-05.txt>.





Varga, et al.             Expires 25 April 2022                [Page 12]


Internet-Draft        DetNet Service-Sub-layer OAM          October 2021


   [I-D.ietf-detnet-oam-framework]
              Mirsky, G., Theoleyre, F., Papadopoulos, G. Z., Bernardos,
              C. J., Varga, B., and J. Farkas, "Framework of Operations,
              Administration and Maintenance (OAM) for Deterministic
              Networking (DetNet)", Work in Progress, Internet-Draft,
              draft-ietf-detnet-oam-framework-05, 14 October 2021,
              <https://www.ietf.org/archive/id/draft-ietf-detnet-oam-
              framework-05.txt>.

   [I-D.varga-detnet-pof]
              Varga, B., Farkas, J., Kehrer, S., and T. Heer,
              "Deterministic Networking (DetNet): Packet Ordering
              Function", Work in Progress, Internet-Draft, draft-varga-
              detnet-pof-01, 21 May 2021,
              <https://www.ietf.org/archive/id/draft-varga-detnet-pof-
              01.txt>.

   [IEEE8021CB]
              IEEE, "IEEE Standard for Local and metropolitan area
              networks -- Frame Replication and Elimination for
              Reliability", DOI 10.1109/IEEESTD.2017.8091139, October
              2017,
              <https://standards.ieee.org/standard/802_1CB-2017.html>.

Authors' Addresses

   Balázs Varga
   Ericsson
   Budapest
   Magyar Tudosok krt. 11.
   1117
   Hungary

   Email: balazs.a.varga@ericsson.com


   János Farkas
   Ericsson
   Budapest
   Magyar Tudosok krt. 11.
   1117
   Hungary

   Email: janos.farkas@ericsson.com







Varga, et al.             Expires 25 April 2022                [Page 13]


Internet-Draft        DetNet Service-Sub-layer OAM          October 2021


   Greg Mirsky
   Ericsson

   Email: gregimirsky@gmail.com















































Varga, et al.             Expires 25 April 2022                [Page 14]