DetNet Working Group G. Mirsky
Internet-Draft ZTE Corp.
Intended status: Informational June 2, 2018
Expires: December 4, 2018

Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet)


This document lists functional requirements for Operations, Administration and Maintenance (OAM) toolset in Deterministic Networks (DetNet) and, using these requirements, and analyzes possible DetNet data plane solutions.

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

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 December 4, 2018.

Copyright Notice

Copyright (c) 2018 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 ( 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 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

[I-D.ietf-detnet-architecture] introduces and explains Deterministic Networks (DetNet) architecture and how the Packet Replication and Elimination function (PREF) can be used to ensure low packet drop ratio in DetNet domain.

Operations, Administration and Maintenance (OAM) protocols are used to detect, localize defects in the network, and monitor network performance. Some OAM functions, e.g., failure detection, work in the network proactively, while others, e.g., defect localization, usually performed on-demand. These tasks achieved by a combination of active and hybrid, as defined in [RFC7799], OAM methods.

This document lists the functional requirements toward OAM for DetNet domain. The list can further be used to for gap analysis of available OAM tools to identify possible enhancements of existing or whether new OAM tools are required to support proactive and on-demand path monitoring and service validation.

2. Conventions used in this document

2.1. Terminology

The term "DetNet OAM" used in this document interchangeably with longer version "set of OAM protocols, methods and tools for Deterministic Networks".

AC Associated Channel

CW Control Word

DetNet Deterministic Networks

d-CW DetNet Control Word

OAM: Operations, Administration and Maintenance

PREF Packet Replication and Elimination Function

PW Pseudowire

RDI Remote Defect Indication

Underlay Network or Underlay Layer: The network that provides connectivity between the DetNet nodes. MPLS network providing LSP connectivity between DetNet nodes is an example of underlay layer.

DetNet Node - a node that is an actor in the DetNet domain. DetNet domain edge node and node that performs PREF within the domain are examples of DetNet node.

2.2. Keywords

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

This section lists requirements for OAM in DetNet domain:

  1. The listed requirements MUST be supported with any type of underlay network over which a DetNet domain can be realized.
  2. It MUST be possible to initiate DetNet OAM session from any DetNet node towards another DetNet node(s) within given domain.
  3. It SHOULD be possible to initialize DetNet OAM session from a centralized controller.
  4. DetNet OAM MUST support proactive and on-demand OAM monitoring and measurement methods.
  5. DetNet OAM packets MUST be in-band, i.e. follow exactly the same path as DetNet data plane traffic both for unidirectional and bi-directional DetNet paths.
  6. DetNet OAM MUST support unidirectional OAM methods, continuity check, connectivity verification, and performance measurement.
  7. DetNet OAM MUST support bi-directional OAM methods. Such OAM methods MAY combine in-band monitoring or measurement in the forward direction and out-of-bound notification in the reverse direction, i.e. from egress to ingress end point of the OAM test session.
  8. DetNet OAM MUST support proactive monitoring of a DetNet node availability in the given DetNet domain.
  9. DetNet OAM MUST support Path Maximum Transmission Unit discovery.
  10. DetNet OAM MUST support Remote Defect Indication (RDI) notification to the DetNet node performing continuity checking.
  11. DetNet OAM MUST support performance measurement methods.
  12. DetNet OAM MUST support unidirectional performance measurement methods. Calculated performance metrics MUST include but are not limited to throughput, loss, delay and delay variation metrics. [RFC6374] provides great details on performance measurement and performance metrics.
  13. DetNet OAM MUST support defect notification mechanism, like Alarm Indication Signal. Any DetNet node in the given DetNet domain MAY originate a defect notification addressed to any subset of nodes within the domain.
  14. DetNet OAM MUST support methods to enable survivability of the DetNet domain. These recovery methods MAY use protection switching and restoration.

4. DetNet Data Plane in Support of Active OAM

OAM protocols and mechanisms act within the data plane of the particular networking layer. And thus it is critical that the data plane encapsulation supports OAM mechanisms in such a way to comply with the above-listed requirements. One of such examples that require special consideration is requirement #5:

The data plane encapsulation for DetNet specified in [I-D.ietf-detnet-dp-sol] has been analyzed in details in [I-D.bryant-detnet-mpls-dp] and [I-D.malis-detnet-ip-dp] for use in MPLS and IP networks respectively. For the MPLS underlay network DetNet flows to be encapsulated analogous to pseudowires (PW) over MPLS packet switched network, as described in [RFC3985], [RFC4385]. Generic PW MPLS Control Word (CW), defined in [RFC4385], for DetNet displayed in Figure 1.


     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 0|                Sequence Number                        |

Figure 1: DetNet Control Word Format

PREF in the DetNet domain composed by a combination of nodes that perform replication and elimination sub-functions. The elimination sub-function always uses packet sequencing information, e.g., value in the Sequence Number field of DetNet CW (d-CW). The replication sub-function uses one of two options: Figure 2 presents an example of PREF in DetNet domain regardless of how the replication sub-function realized in the domain.

For data packets


      1111   11111111  111111   112212   112212     132213
            \2          22222/                 3 /
             \2222222  /----+                 3 /

Figure 2: DetNet Data Plane Based on PW

4.1. DetNet Active OAM Encapsulation

DetNet OAM, like PW OAM, uses PW Associated Channel Header defined in [RFC4385]. Figure 3 displays encapsulation of a DetNet active OAM packet. Figure 4 displays format of the DetNet Associated Channel (AC).

     |                                 |
     |           DetNet  Flow          |
     |           OAM   Packet          |
     |                                 |
     +---------------------------------+ <--\
     |    DetNet Associated Channel    |    |
     +=================================+    +--> DetNet OAM data plane
     |             S-Label             |    |    MPLS encapsulation
     +---------------------------------+ <--/
     |           T-Label(s)            |
     |           Data-Link             |
     |           Physical              |

Figure 3: DetNet PW OAM Packet Encapsulation


    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|0 0 0 0|0 0 0 0 0 0 0 0|         Channel Type          |

Figure 4: DetNet Associated Channel Header Format

4.2. DetNet PREF Interaction with Active OAM

Consider the scenario when EN1 injects DetNet active OAM packet with the same S-Label as the DetNet service reflected in Figure 2. EN1 is the first node with the replication sub-function. If the replication uses S-Label information and the sequencing information in d-CW (the first option), then EN1 will only forward the OAM packet without replicating it because OAM encapsulation doesn't include d-CW. The path that active OAM packet traverses through the DetNet domain presented in Figure 5 with 'O'. The figure clearly demonstrates that the DetNet OAM packet does not traverse all the segments that are traversed by the DetNet data packet as displayed in Figure 2.

                 O       O        O        O
            \                /                   /
             \         /----+                   /

Figure 5: OAM in DetNet Data Plane Based on PW

If the replication is based solely on S-Label (the second option), EN1 node will replicate the OAM packet accordingly. The replicated packet will be processed by the replication function at R4. As result, the same OAM packet will be forwarded and another copy injected into the network. This case displayed in Figure 6. The OAM packet does traverse all links and nodes that the DetNet data packet of the monitored flow traverses but the egress node EN2 receives multiple, three in this example, copies of the same packet because the elimination function cannot be applied to the DetNet active OAM packet.


             O          O         OO       OO
            \O              O/                  O/
             \        O/----+                   /

Figure 6: Over-Replication of Active OAM Packets

4.3. Alternative Encapsulation for DetNet

Introduction of DetNet header, that includes all necessary characteristic information to efficiently, among other scenarios, use multipath underlay, perform PERF, as part of DetNet service layer encapsulation allows DetNet active OAM packets to be in-band with the monitored DetNet data flow. Figure 7 presents the format of DetNet packet with MPLS encapsulation.

     |                                 |
     |           DetNet Flow           |
     |          Payload or OAM         |
     |              Packet             |
     |          DetNet Header          |
     ~                                 ~
     |                                 |
     |             S-Label             |
     |           T-Label(s)            |
     |           Data-Link             |
     |           Physical              |

Figure 7: DetNet Packet with DetNet Header Encapsulation over MPLS Underlay

Demultiplexing of type of the payload encapsulated in the DetNet packet achieved using a field that explicitly identifies, e.g., OAM, Ethernet, or IPvX.

5. Use of Hybrid OAM in DetNet

Hybrid OAM methods are used in performance monitoring and defined in [RFC7799] as: [RFC8321]. Reserving the field for the Alternate Marking method in the DetNet Header will enhance available to an operator set of DetNet OAM tools.

A hybrid measurement method may produce metrics as close to passive but it still alters something in a data packet even if that is value of a designated field in the packet encapsulation. One example of such hybrid measurement method is the Alternate Marking method described in

6. IANA Considerations

This document does not propose any IANA consideration. This section may be removed.

7. Security Considerations

This document lists the OAM requirements for a DetNet domain and does not raise any security concerns or issues in addition to ones common to networking.

8. Acknowledgment


9. References

9.1. Normative References

[I-D.bryant-detnet-mpls-dp] Bryant, S. and M. Chen, "Operation of Deterministic Networks over MPLS", Internet-Draft draft-bryant-detnet-mpls-dp-00, March 2018.
[I-D.ietf-detnet-architecture] Finn, N., Thubert, P., Varga, B. and J. Farkas, "Deterministic Networking Architecture", Internet-Draft draft-ietf-detnet-architecture-05, May 2018.
[I-D.ietf-detnet-dp-sol] Korhonen, J., Andersson, L., Jiang, Y., Finn, N., Varga, B., Farkas, J., Bernardos, C., Mizrahi, T. and L. Berger, "DetNet Data Plane Encapsulation", Internet-Draft draft-ietf-detnet-dp-sol-04, March 2018.
[I-D.malis-detnet-ip-dp] Malis, A., Bryant, S., Chen, M. and B. Varga, "DetNet IP Encapsulation", Internet-Draft draft-malis-detnet-ip-dp-00, March 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

9.2. Informational References

[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005.
[RFC4385] Bryant, S., Swallow, G., Martini, L. and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016.
[RFC8321] Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G. and T. Mizrahi, "Alternate-Marking Method for Passive and Hybrid Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, January 2018.

Author's Address

Greg Mirsky ZTE Corp. EMail: