Internet-Draft DetNet Service-Sub-layer OAM October 2021
Varga, et al. Expires 25 April 2022 [Page]
Workgroup:
DetNet
Internet-Draft:
draft-varga-detnet-service-sub-layer-oam-01
Published:
Intended Status:
Informational
Expires:
Authors:
B. Varga
Ericsson
J. Farkas
Ericsson
G. Mirsky
Ericsson

Deterministic Networking (DetNet): OAM Functions for The Service Sub-Layer

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.

Table of Contents

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

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:

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


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

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

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.

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:

  • 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

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.ietf.org/archive/id/draft-ietf-detnet-mpls-oam-05.txt>.
[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, , <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, , <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, , <https://standards.ieee.org/standard/802_1CB-2017.html>.

Authors' Addresses

Balázs Varga
Ericsson
Budapest
Magyar Tudosok krt. 11.
1117
Hungary
János Farkas
Ericsson
Budapest
Magyar Tudosok krt. 11.
1117
Hungary
Greg Mirsky
Ericsson