<?xml version="1.0" encoding="utf-8"?> encoding="UTF-8"?>

  <!-- xml2rfc v2v3 conversion 3.6.0 -->

<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
category="info"
ipr="trust200902"
docName="draft-ietf-detnet-oam-framework-11"
number="9551"
consensus="true"
obsoletes=""
updates=""
submissionType="IETF"
xml:lang="en"
tocInclude="true"
tocDepth="3"
symRefs="true"
sortRefs="true"
version="3">

  <!-- xml2rfc v2v3 conversion 3.6.0 -->

  <front>
    <title abbrev="Framework of OAM for DetNet">Framework of Operations, Administration Administration, and Maintenance (OAM) for Deterministic Networking (DetNet)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-detnet-oam-framework-11"/> name="RFC" value="9551"/>
    <author initials="G." surname="Mirsky" fullname="Greg Mirsky">
      <organization>Ericsson</organization>
      <address>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>

    <author initials="F." surname="Theoleyre" fullname="Fabrice Theoleyre">
      <organization>CNRS</organization>
      <address>
        <postal>
	  <extaddr>ICube Lab, Pole API</extaddr>
          <street>300 boulevard Sebastien Brant - CS 10413</street>
          <city>Illkirch - Strasbourg</city>
          <code>67400</code>
          <country>FRANCE</country>
          <country>France</country>
        </postal>
        <phone>+33 368 85 45 33</phone>
        <email>fabrice.theoleyre@cnrs.fr</email>
        <uri>https://fabrice.theoleyre.cnrs.fr/</uri>
      </address>
    </author>

    <author initials="G.Z." initials="G." surname="Papadopoulos" fullname="Georgios Z. Papadopoulos">
      <organization>IMT Atlantique</organization>
      <address>
        <postal>
          <street>Office B00 - 102A</street>
          <street>2 Rue de la Châtaigneraie</street>
          <city>Cesson-Sévigné - Rennes</city>
          <code>35510</code>
          <country>FRANCE</country>
          <country>France</country>
        </postal>
        <phone>+33 299 12 70 04</phone>
        <email>georgios.papadopoulos@imt-atlantique.fr</email>
      </address>
    </author>
    <author initials="CJ." surname="Bernardos" fullname="Carlos J. Bernardos">
      <organization abbrev="UC3M">
        Universidad Carlos III de Madrid
      </organization>
      <address>
        <postal>
          <street>Av. Universidad, 30</street>
          <city>Leganes, Madrid</city>
          <code>28911</code>
          <country>Spain</country>
        </postal>
        <phone>+34 91624 6236</phone>
        <email>cjbc@it.uc3m.es</email>
        <uri>http://www.it.uc3m.es/cjbc/</uri>
      </address>
    </author>

      <author fullname="Balazs Varga" initials="B." surname="Varga">
        <organization>Ericsson</organization>
        <address>
         <postal>
          <street>Magyar Tudosok krt. 11.</street>
          <city>Budapest</city>
          <country>Hungary</country>
          <code>1117</code>
         </postal>
         <email>balazs.a.varga@ericsson.com</email>
        </address>
        </author>

    <author fullname="Janos Farkas" initials="J." surname="Farkas">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Magyar Tudosok krt. 11.</street>
          <city>Budapest</city>
          <country>Hungary</country>
          <code>1117</code>
        </postal>
        <email>janos.farkas@ericsson.com</email>
      </address>
    </author>

    <date/>

    <date year="2024" month="March"/>

    <area>RTG</area>
    <workgroup>DetNet</workgroup>

    <abstract>
      <t>
    Deterministic
      <t>Deterministic Networking (DetNet), as defined in RFC 8655, aims to
      provide bounded end-to-end latency on top of the network infrastructure,
      comprising both Layer 2 bridged and Layer 3 routed segments.  This
      document's primary purpose is to detail the specific requirements of the Operation,
      Operations, Administration, and Maintenance (OAM) recommended to maintain
      a deterministic network. The document will be used in future work that
      defines the applicability of and extension of OAM protocols for a
      deterministic network.  With the implementation of the OAM framework in
      DetNet, an operator will have a real-time view of the network
      infrastructure regarding the network's ability to respect the Service
      Level
          Objective, Objective (SLO), such as packet delay, delay variation, and packet loss packet-loss
      ratio, assigned to each DetNet flow.

      </t>
    </abstract>
  </front>
  <middle>

<section numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        Deterministic Networking (DetNet) <xref target="RFC8655" format="default"/> has proposed to provide a bounded end-to-end latency
        on top of the network infrastructure, comprising both Layer 2 bridged and Layer 3 routed segments.
        That work encompasses the data plane, OAM, time synchronization, management, control, and security aspects.
      </t>
      <t>
        Operations, Administration, and Maintenance (OAM) Tools tools are of primary importance
        for IP networks <xref target="RFC7276" format="default"/>.
        DetNet OAM should provide a toolset for fault detection, localization, and performance measurement.
      </t>
      <t>
        This document's primary purpose is to detail the specific requirements of the OAM features recommended to maintain a
	deterministic/reliable network.  Specifically, it investigates the requirements for a deterministic network, supporting
network that supports critical flows.

      </t>
      <t>
      	In this document, the term OAM "OAM" will be used according to its definition specified
      	in <xref target="RFC6291" format="default"/>. DetNet expects is expected to implement an OAM framework to maintain a real-time
      	view of the network infrastructure, and its ability to respect the Service Level
          Objectives (SLOs), such as in-order packet delivery, packet delay, delay variation, and packet loss packet-loss ratio, assigned to each DetNet flow.
      </t>
      <t>
    This
      <t>This document lists the OAM functional requirements toward OAM for a DetNet domain.
    The list can further be used for gap analysis of available OAM tools to identify
   possible identify:</t>
    <ul><li>possible enhancements of existing or whether tools, or</li>
    <li>whether new OAM tools are required to
   support proactive and on-demand path monitoring and service validation.
      </t> validation.</li></ul>

      <section anchor="define-sec" numbered="true" toc="default">
        <name>Definitions</name>
        <t>
            This document uses definitions, particularly of a DetNet flow, provided in Section 2.1 of <xref target="RFC8655"/>. target="RFC8655" sectionFormat="of" section="2.1"/>.
            The following terms are used throughout this document as defined below:
        </t>
        <ul
        <dl spacing="normal">
                  <li>
                  <dt>
                    DetNet OAM domain: a domain:</dt><dd>a DetNet network used by the monitored DetNet flow. A DetNet OAM domain
                    (also referred to in this document as "OAM domain") may have MEPs Maintenance End Points (MEPs) on its edge and MIPs Maintenance Intermediate Points (MIPs) within.
                   </li>
          <li>
                    DetNet
                   </dd>

                    <dt>DetNet OAM instance: a instance:</dt><dd>a function that monitors a DetNet flow for defects and/or measures its performance metrics. Within this document,
                    a
                    the shorter version, OAM instance, version "OAM instance" is used interchangeably.
                   </li>
               <li>
                   Maintenance
                   </dd>

                   <dt>Maintenance End Point (MEP): an (MEP):</dt><dd>an OAM instance that is capable of generating OAM test packets
                   in the particular sub-layer of the DetNet OAM domain.
               </li>
          <li>
                   Maintenance
               </dd>

                   <dt>Maintenance Intermediate Point (MIP): an (MIP):</dt><dd>an OAM instance along the DetNet flow  in the particular sub-layer of the DetNet OAM domain.
An active MIP MUST <bcp14>MUST</bcp14> respond to an OAM message generated by the MEP at its sub-layer of the same DetNet OAM domain.
               </li>
          <li>
               Control
               </dd>
          <dt>Control and management plane: the plane:</dt><dd>the control and management planes are used to configure and control the network.
               Relative to a DetNet flow, the control and/or management plane can be out-of-band.
                   </li>
          <li>
               Active out of band.
                   </dd>
          <dt>Active measurement methods (as methods:</dt><dd>(as defined in <xref target="RFC7799" format="default"/>)
                  these methods modify a DetNet flow by injecting specially constructed test packets <xref target="RFC2544" format="default"/>).
                  </li>
          <li>Passive format="default"/>.
                  </dd>
          <dt>Passive measurement methods methods:</dt> <dd>(as defined in <xref target="RFC7799" format="default"/> format="default"/>) these methods infer information by observing unmodified existing flows.</li>
          <li>Hybrid flows.</dd>
          <dt>Hybrid measurement methods methods:</dt><dd>(as defined in <xref target="RFC7799" format="default"/> is format="default"/>) the combination of elements of both active and passive measurement methods.</li>
          <li>
             In-band OAM is an methods.</dd>
          <dt>In-band OAM:</dt><dd>an active OAM method that is in-band in band within the monitored
      DetNet OAM domain when it traverses the same set of links and
      interfaces receiving the same QoS and Packet Replication,
      Elimination, and Ordering Functions (PREOF) treatment as the
      monitored DetNet flow.
</li>
<li>
   Out-of-band OAM is an flow.</dd>
<dt>Out-of-band OAM:</dt><dd>an active OAM method whose path through the DetNet domain is may not be topologically identical to the
   path of the monitored DetNet flow, or its test packets may receive different QoS and/or PREOF treatment, or both.
      </li>
      <li>
      On-path
      </dd>
      <dt>On-path telemetry:</dt><dd>on-path telemetry can be realized as a hybrid OAM method. The origination of the telemetry information
      is inherently in-band in band as packets in a DetNet flow are used as triggers. Collection of the on-path telemetry information
      can be performed using in-band or out-of-band OAM methods.
      </li>
         	</ul>
      </section>
      <section anchor="acronyms-sec" numbered="true" toc="default">
        <name>Abbreviations</name>
        <t>OAM:                   Operations, Administration, and Maintenance</t>
        <t>DetNet:               Deterministic Networking</t>
        <t>PREOF:              Packet Replication, Elimination and Ordering Functions</t>
        <t>SLO:                    Service Level Objective</t>
      </dd>
         	</dl>
      </section>

      <section numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
   "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/>
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
   The requirements language is used in Sections <xref target="define-sec"/>, target="define-sec" format="counter"/> and <xref target="req-list"/>, target="req-list" format="counter"/>,
   and applies to the implementations of DetNet OAM.
        </t>
      </section>
    </section>
    <!-- INTEREST OF OAM          -->
<section numbered="true" toc="default">
      <name>Role of OAM in DetNet</name>
      <t>
	DetNet networks expect are expected to provide communications with predictable low packet delay, packet loss, and packet misordering.  Most critical applications will define
a set of SLOs to be required for the DetNet flows it generates. they generate.
</t>
<t>
To respect strict guarantees, DetNet can use an orchestrator able to
monitor and maintain the network. Typically, a Software-Defined
Network (SDN) controller places DetNet flows in the deployed network
based on their SLOs. Thus, resources have to be provisioned a
priori for the regular operation of the network.
</t>
<t>
Most of the existing OAM tools can be used in DetNet networks,
but they can only cover some aspects of deterministic networking.
Fulfilling strict guarantees is essential for DetNet flows,
resulting in new DetNet-specific functionalities that must be covered with OAM.
Filling these gaps is inevitable and needs accurate consideration of
DetNet specifics. Similar to DetNet flows, their OAM also needs careful
end-to-end engineering.
</t>
<t>
For example, appropriate placing of MEPs along the path of a DetNet flow is
not always a trivial task and may require proper design, design together with the
design of the service component of a given DetNet flow.
</t>
<t>
There are several DetNet-specific challenges for OAM. Bounded network
characteristics (e.g., delay, loss) are inseparable service parameters;
therefore, Performance Monitoring (PM) OAM is a key topic for DetNet. OAM tools are needed to monitor each
SLO without impacting the DetNet flow characteristics. A further challenge
is strict resource allocation. Resources used by OAM must be considered
and allocated to avoid disturbing DetNet flows.
</t>
<t>
The DetNet Working Group has defined two sub-layers:
</t>
<ul empty="true" spacing="normal">
<li>
The DetNet service sub-layer, sub-layer at which a DetNet service (e.g., service
protection) is provided.
</li>
<li>
The DetNet forwarding sub-layer, which
optionally provides resource allocation for DetNet flows over paths
provided by the underlying network.
</li>
</ul>
<t>
OAM mechanisms exist for the
DetNet forwarding sub-layer, but the service
sub-layer requires new OAM procedures. These new OAM functions
must allow, for example, to recognize/discover recognizing/discovering DetNet relay
nodes, to get getting information about their configuration, and to
check
checking their operation or status.
</t>

<t>
DetNet service sub-layer functions use a sequence number for PREOF. That PREOF, which creates
a challenge for inserting OAM packets in the DetNet flow.
</t>
<t>
Fault tolerance also assumes that multiple paths could be provisioned
to maintain an end-to-end circuit by adapting to the existing conditions.
The DetNet Controller Plane, e.g., central controller/orchestrator, controls the PREOF on a node. OAM is expected to support monitoring and
troubleshooting PREOF on a particular node and within the domain.
</t>
<t>
Note that a distributed architecture of the DetNet Control Plane can also control PREOF
in those scenarios where DetNet solutions involve more than one single central controller.
</t>
<t>
The DetNet forwarding sub-layer is based on preexisting technologies and has
much better coverage regarding OAM. However, the forwarding sub-layer
is terminated at DetNet relay nodes, so the end-to-end OAM state of forwarding
may be created only based on the status of multiple forwarding sub-layer segments
serving a given DetNet flow (e.g., in case of DetNet MPLS, there may be
no end-to-end LSP below the DetNet Pseudowire). pseudowire).
</t>
<!--
      <t>
      It is undwerstood that the existing OAM tools broadly used in networks can be used in DetNet domains.
      At the same time, it is expected that addressiing specific DetNet use case, for example,
      PREOF, will require extensions to the existing OAM protocols.
      </t>
      -->

    </section>
    <!--  OPERATION          -->
<section numbered="true" toc="default">
      <name>Operation</name>
      <t>
    	OAM features will enable DetNet with robust operation both for forwarding and routing
    	purposes.
      </t>

        <t>
			It is worth noting that the test and data packets are expected to follow the same
            path, i.e., connectivity verification has to be conducted in-band in band without
            impacting data traffic.
            It is expected that test packets share fate with the monitored data traffic
            without introducing congestion in normal network conditions.
        </t>

    <section numbered="true" toc="default">
        <name>Information Collection</name>
        <t>
               Information about the state of the network can be collected using several mechanisms. Some protocols,
              e.g., the Simple Network Management Protocol, polls Protocol (SNMP), poll for updated data.
              Other protocols, such as YANG-Push <xref target="RFC8641"/>, can be used
              to set up subscriptions for the data defined in the YANG data models
              to be published periodically or when the underlying data changes.
              In either
              Either way, information is collected and sent using the DetNet Controller Plane.
        </t>
        <t>
               Also, we can characterize methods of transporting OAM information relative to the path of data.
               For instance, OAM information may be transported in-band in band or out-of-band out of band relative to the DetNet flow.
               In the case of the former, the telemetry information uses resources allocated for the monitored DetNet flow.
               If an in-band method of transporting telemetry is used, the amount of generated information needs
               to be carefully analyzed, and additional resources must be reserved. <xref target="RFC9197"/> defines the in-band
               transport mechanism where telemetry information is collected in the data packet on which information is generated.
        Two tracing methods are described - end-to-end, described:</t>
	<ul>
	  <li>end-to-end, i.e., from the ingress and egress nodes,
               and hop-by-hop,
          and</li>
	  <li>hop-by-hop, i.e., like end-to-end with additional information from transit nodes.
               <xref nodes.</li></ul>
               <t><xref target="RFC9326"/> and <xref target="I-D.mirsky-ippm-hybrid-two-step"/> target="I-D.ietf-ippm-hybrid-two-step"/> are examples of out-of-band
               telemetry transport. In the former case, information is transported by each node traversed
               by the data packet of the monitored DetNet flow in a specially constructed packet. In the latter,
               information is collected in a sequence of follow-up packets that traverse the same path as the data packet of the monitored DetNet flow.
               In both methods, transport of the telemetry can avoid using resources allocated for the DetNet domain.

        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Continuity Check</name>
        <t>
			Continuity
			A continuity check is used to monitor the continuity of a path, i.e.,
            that there exists a way to deliver packets between
            MEP A and MEP B. The continuity check detects a network failure in one direction, direction:
            from the MEP transmitting test packets to the remote egress MEP. Continuity The continuity check in a DetNet OAM domain
           monitors the DetNet forwarding sub-layer and thus sub-layer; thus, it is not affected
           by a PREOF that operates at the DetNet service sub-layer (<xref target="RFC8655"/>. target="RFC8655"/>).
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Connectivity Verification</name>
        <t>
            In addition to the Continuity Check, DetNet solutions have to verify connectivity.
            This verification considers an additional constraint, i.e, constraint: the absence of
            misconnection. The misconnection error state is entered after several consecutive test packets
            from other DetNet flows are received. The definition of the conditions for entry and exit of a misconnection
            error state is outside the scope of this document. Connectivity verification in a DetNet OAM domain
           monitors the DetNet forwarding sub-layer and thus sub-layer; thus, it is not affected
           by PREOF that operates at the DetNet service sub-layer (<xref target="RFC8655"/>. target="RFC8655"/>).
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Route Tracing</name>
        <t>
       		Ping and traceroute are two ubiquitous tools that help localize and characterize a failure in the network
       		using an echo request/reply mechanism.
       		They help to identify a subset of the routers in the path.
       		However, to be predictable, resources are reserved per flow in DetNet.
       		Thus, DetNet needs to define route tracing tools able to trace the route for a
       		specific flow. Also, tracing can be used for the discovery of the Path Maximum Transmission Unit (PMTU) or location of elements of PREOF
       		for the particular route in the DetNet domain.
        </t>
        <t>
			DetNet is not expected to use Equal-Cost Multipath (ECMP) <xref target="RFC8939" format="default"/>.
			As the a result, DetNet OAM in an ECMP environment is outside the scope of this document.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Fault Verification/Detection</name>
        <t>
      		DetNet expects to operate fault-tolerant networks.
      		Thus, mechanisms able to detect faults before they impact network performance are needed.
        </t>
        <t>
     		The network has to detect when a fault has occurred, i.e., the network has deviated
             from its expected behavior. Fault detection can be based on proactive OAM protocols
             like continuity check or on-demand methods like ping.
     		While the network must report an alarm, the cause may not be identified
     		precisely.
     		Examples of such alarms are significant degradation of the end-to-end reliability, reliability or when a
     		buffer overflow occurs.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Fault Localization and Characterization</name>
        <t>
        	An
        	The ability to localize a network defect and provide its characterization are necessary elements of network operation.
        </t>
        	        <ul empty="true"

        	        <dl spacing="normal">
          <li>Fault localization, a
          <dt>Fault localization:</dt><dd>a process of deducing the location of a network failure from a set of observed failure indications, indications.
        	For example, this might be achieved, for example, achieved by tracing the route of the DetNet flow in which the network failure was detected.
        	Another method of fault localization can correlate reports of failures from a set of interleaved sessions monitoring path continuity.</li>
        	<li>
          Fault characterization is a continuity.</dd>
        	<dt>Fault characterization:</dt><dd>a process of identifying the root cause of the problem. For instance, misconfiguration or malfunction of PREOF elements
          can be the cause of erroneous packet
        	replication or extra packets being flooded in the DetNet domain.
        	</li>
        </ul>
        	</dd>
        </dl>

      </section>
      <section anchor="hybrid-oam" numbered="true" toc="default">
        <name>Use of Hybrid OAM in DetNet</name>
        <t>Hybrid OAM methods are used in performance monitoring and defined in <xref target="RFC7799" format="default"/> as: as follows:
</t>
        <ul empty="true" spacing="normal">
          <li>Hybrid
        <blockquote>
          <t>Hybrid Methods are Methods of Measurement that use a combination of
   Active Methods and Passive Methods.</li>
        </ul> Methods.</t>
        </blockquote>
        <t>
A hybrid measurement method can produce metrics as close to measured using a passive measurement method.
The passive methods measure metrics closest to the network's actual conditions. A hybrid method,
even if it alters something in a data packet, even if that is as little as the value of a designated field in the packet encapsulation,
is considered an approximation of a passive measurement method.
  One example of such a hybrid measurement method
   is the Alternate Marking method Alternate-Marking Method (AMM) described in <xref target="RFC9341" format="default"/>.
   As with all on-path telemetry methods, AMM in a DetNet domain with the IP data plane is natively in-band is, by design, in band
  with respect to the monitored DetNet flow. Because the marking is applied to a data flow,
  measured metrics are directly applicable to the DetNet flow. AMM minimizes the additional load on
  the DetNet domain by using nodal collection and computation of performance metrics optionally in combination with
  optionally
  using out-of-band telemetry collection for further network analysis.
        </t>
      </section>
    </section>
    <!--    ADMINISTRATION          -->
<section numbered="true" toc="default">
      <name>Administration</name>
      <t>
      The ability to expose a collection of metrics to support an operator's decision-making is essential.
      The following performance metrics are useful:

      </t>
      <ul spacing="normal">
        <li>
            Queuing Delay: the
      <dl>
        <dt>Queuing Delay:</dt><dd>the time elapsed between enqueuing a packet and its transmission to the next hop.
            </li>
        <li>
            Buffer occupancy: the
            </dd>
        <dt>Buffer occupancy:</dt><dd>the number of packets present in the buffer, buffer for each of the existing flows.
            </li>
        <li>
            Per
            </dd>
        <dt>Per DetNet flow, a flow:</dt><dd>a metric reflecting end-to-end performance for a given flow.
            Each of the paths has to be isolated in a multipath routing environment.
            </li>
        <li>
            Per path, detection
            </dd>
        <dt>Per-path:</dt><dd>detection of a misbehaving path(s) path or paths when multiple paths are used for the service protection.
            </li>
        <li>
            Per device, detection
            </dd>
        <dt>Per-device:</dt><dd>detection of a misbehaving device.
            </li>
      </ul>
            </dd>
      </dl>
      <section numbered="true" toc="default">
        <name>Collection of metrics</name> Metrics</name>
        <t>
             It is important to optimize the volume and frequency of statistics/measurement collection,
             whether the mechanisms are distributed, centralized, or both. Periodic and
             event-triggered collection information characterizing the state of a network is
             an example of mechanisms to achieve the optimization.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Worst-case metrics</name>
        <name>Worst-Case Metrics</name>
        <t>
         DetNet aims to enable real-time communications on top of a heterogeneous multi-hop architecture.
         To make correct decisions, the DetNet Controller Plane <xref target="RFC8655"/> needs timely information
         about packet losses/delays for each flow, flow and each hop of the paths.
         In other words, just the average end-to-end statistics are not enough.
         The collected information must be sufficient to allow a system to predict the worst-case scenario.
        </t>
      </section>
    </section>
    <!--   MAINTENANCE          -->

<!-- speak about predictive maintenance? -->

   <section numbered="true" toc="default">
      <name>Maintenance</name>
      <t>
      Service protection (provided by the DetNet Service sub-layer) is designed to mitigate simple network failures more rapidly
 	than the expected response time of the DetNet Controller Plane.
 	In the face of events that impact network operation (e.g., link up/down,
         device crash/reboot, flows starting and ending), the ending), the DetNet Controller Plane needs to perform
         repair and re-optimization reoptimization actions in order to permanently ensure
         SLOs of all active flows with flows with minimal waste of resources.
         The Controller Plane is expected to be able to continuously retrieve the state of the network,
         to evaluate conditions and trends about the relevance of a reconfiguration, quantifying: quantifying the following:
      </t>
      <ul
      <dl spacing="normal">
        <li> the
        <dt>the cost of the sub-optimality: resources suboptimality:</dt><dd>resources may not be used optimally (i.e., a better path exists).
            </li>
        <li>
               the
            </dd>
        <dt>the reconfiguration cost: the cost:</dt><dd>the DetNet Controller Plane needs an ability to trigger some reconfigurations.
               For this transient period, resources may be twice reserved, and control packets have to be transmitted.
            </li>
      </ul>
            </dd>
      </dl>
      <t>
         Thus, reconfiguration may only be triggered if the gain is significant.
      </t>

      <section numbered="true" toc="default">
        <name>Replication / Elimination</name>
        <name>Replication/Elimination</name>
        <t>

When multiple paths are reserved between two MEPs,
  packet replication may be used to introduce redundancy and alleviate transmission errors and collisions.
              For instance, in <xref target="fig_replication" format="default"/>, the source device S transmits
              a packet to devices A and B to reach the destination node R.
        </t>
        <figure anchor="fig_replication">
          <name>Packet Replication and Elimination Functions</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[

               ===> (A) => (C) => (E) ===
             //        \\//   \\//       \\
   source (S)          //\\   //\\         (R) (root)
             \\       //  \\ //  \\      //
               ===> (B) => (D) => (F) ===
            ]]></artwork>
        </figure>
      </section>
      <section numbered="true" toc="default">
        <name>Resource Reservation</name>
        <t>

            Because
        <t>Because the quality of service criteria associated with a path may degrade, the network has
            to provision additional resources along the path.
        </t>
      </section>
    </section>

    <section anchor="req-list" numbered="true" toc="default">
      <name>Requirements</name>

      <t>
      According to <xref target="RFC8655"/>, DetNet functionality is divided into forwarding and service sub-layers.
      The DetNet forwarding sub-layer includes DetNet transit nodes and may allocate resources for a DetNet flow over paths provided by the underlay network.
      The DetNet service sub-layer includes DetNet relay nodes and provides a DetNet service (e.g., service protection).
  This section lists general requirements for DetNet OAM as well as requirements in each of the DetNet sub-layers of a DetNet domain.
      </t>

           <ol spacing="normal" type="1">

      <li>
          It MUST <bcp14>MUST</bcp14> be possible to initiate a DetNet OAM session from a MEP located at a
          DetNet node towards MEP(s) a MEP or MEPs downstream from that DetNet node
          within the given domain at a particular DetNet sub-layer.
  </li>
        <li>
  It MUST <bcp14>MUST</bcp14> be possible to initiate a DetNet OAM session from using any of the DetNet Controller Plane solutions, e.g., a centralized controller.
  </li>
        <li>
  DetNet OAM MUST <bcp14>MUST</bcp14> support proactive OAM monitoring and measurement methods.
  </li>
          <li>
  DetNet OAM MUST <bcp14>MUST</bcp14> support on-demand OAM monitoring and measurement methods.
  </li>
        <li>
  DetNet OAM MUST <bcp14>MUST</bcp14> support unidirectional OAM methods, continuity check, checks,
  connectivity verification, and performance measurement. measurements.
  </li>
  <!--

        <li>
    DetNet OAM methods MAY combine in-band monitoring or measurement in the forward direction and out-of-band
  notification in the reverse direction, i.e., towards the ingress MEP.
  </li>
  -->
        <li>
    DetNet OAM MUST <bcp14>MUST</bcp14> support bi-directional bidirectional DetNet flows,
    but it is not required to support bi-directional bidirectional OAM methods for bi-directional bidirectional DetNet flows.
    DetNet OAM test packets used for monitoring and measurements
    of a bi-directional bidirectional DetNet flow MUST <bcp14>MUST</bcp14> be in-band in band in both directions.
   </li>
        <li>
DetNet OAM MUST <bcp14>MUST</bcp14> support proactive monitoring of a DetNet device device's reachability for a given DetNet flow.
</li>
        <li>
  DetNet OAM MUST <bcp14>MUST</bcp14> support hybrid performance measurement methods.
  </li>
        <li>
Calculated performance metrics MUST include <bcp14>MUST</bcp14> include, but are not limited to to, throughput, packet loss, out of order, packet-loss, out-of-order,
delay, and delay variation delay-variation metrics. <xref target="RFC6374" format="default"/> provides detailed information on performance
measurement and performance metrics.
</li>
      </ol>

        <section anchor="req-on-dfs-oam" title="For the DetNet Forwarding Sub-layer">
    <t>DetNet OAM <bcp14>MUST</bcp14> support:</t>
      <ol spacing="normal" type="1">

        <li>
DetNet OAM MUST support Path Maximum Transmission Unit

        <li>PMTU discovery.
</li>

        <li>
DetNet OAM MUST support Remote

        <li>Remote Defect Indication (RDI) notification to the DetNet OAM instance
 performing continuity checking.
</li>

          <li>
  DetNet OAM MUST support

          <li>the monitoring of levels of resources allocated for a particular DetNet flow.
  Such resources include include, but are not limited to to, buffer utilization and scheduler transmission calendar.
  </li>
        <li>
  DetNet OAM MUST support
        <li>the monitoring of any subset of paths traversed through the DetNet domain by a DetNet flow.
  </li>
      </ol>

        </section>

      <section anchor="req-on-dss-oam" title="For the DetNet Service Sub-layer">
        <t>
	 The OAM functions for the DetNet service sub-layer allow, for example, to
	 recognize/discover the
	 recognizing/discovery of DetNet relay nodes, to get the gathering of information about their
	 configuration, and to check the checking of their operation or status.
  </t>
  <t>
     The requirements on OAM for a DetNet relay node are: are that DetNet OAM <bcp14>MUST</bcp14>:
     </t>
	<ol spacing="normal" type="1">
         <li>DetNet OAM MUST provide
         <li>provide OAM functions for the DetNet service sub-layer. </li>
         <li>
         DetNet OAM MUST support
         <li>support the discovery of DetNet relay nodes in a DetNet network.
        </li>
        <li>
        DetNet OAM MUST support
        <li>support the discovery of PREOF locations in the domain.
        </li>
         <li>
         DetNet OAM MUST support
         <li>support the collection of information specific to the DetNet service sub-layer specific
         (configuration/operation/status) information from DetNet relay nodes.
		  </li>
		  <li>
		  DetNet OAM MUST support excercising
		  <li>support exercising functionality of PREOF in the domain.
		  </li>
		 <li>DetNet OAM MUST work
		 <li>work for DetNet data planes - planes: MPLS and IP. </li>
		<li>
DetNet OAM MUST support
		<li>support a defect notification mechanism, like Alarm Indication Signal.
Any DetNet relay node providing service for a given DetNet flow
MAY
<bcp14>MAY</bcp14> originate a defect notification addressed to any subset of DetNet relay nodes along that flow.
</li>
    <li>
DetNet OAM MUST be
    <li>be able to measure metrics (e.g. delay) inside a collection of OAM sessions, specially for complex DetNet flows, with PREOF features.
    </li>

     </ol>
</section>  <!-- end of service sub-layer requirements -->
    </section>

    <section anchor="iana-consider" numbered="true" toc="default">
      <name>IANA Considerations</name>

      <t>This document has no actionable requirements for IANA. This section can be removed before publication.</t> IANA actions.</t>
    </section>
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   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 and
   those specific to DetNet that are discussed in Section 9 of <xref target="RFC9055" format="default"/>. sectionFormat="of" section="9"/>.
      Furthermore, the analysis of OAM security concerns in Section 6 of <xref target="RFC7276"/> target="RFC7276" sectionFormat="of" section="6"/>
      also applies to DetNet OAM, including the use of OAM for network reconnaissance.</t>
    </section>
        <section anchor="privacy" numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>
  Privacy considerations of DetNet discussed in Section 13 of <xref target="RFC9055" format="default"/> sectionFormat="of" section="13"/>
  are also applicable to DetNet OAM. If any privacy mechanism is used for the monitored DetNet flow, then
  the same privacy method MUST <bcp14>MUST</bcp14> be applied to the active DetNet OAM used to monitor the flow.
      </t>
    </section>
    <section numbered="true" toc="default">
      <name>Acknowledgments</name>
      <t>
        The authors express their appreciation and gratitude to Pascal Thubert for the review, insightful questions, and helpful comments.
      </t>
    </section>
  </middle>

  <back>

  <displayreference target="I-D.ietf-ippm-hybrid-two-step" to="HYBRID-TWO-STEP"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <!-- Key words for use in RFCs to Indicate Requirement Levels  --> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <!-- Ambiguity of Uppercase vs Lowercase --> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/>
        <!-- Deterministic Networking Architecture --> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/>

    </references>

      <references>
        <name>Informative References</name>

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6291.xml"/>
        <!-- OAM definition --> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6291.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7276.xml"/>
        <!-- An Overview of Operations, Administration, and Maintenance (OAM) Tools --> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7276.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml"/>
        <!-- passive / active methods   --> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2544.xml"/>
        <!-- test packets   --> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2544.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8939.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8939.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6374.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6374.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9055.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9055.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8641.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8641.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9197.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9197.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9326.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9326.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-mirsky-ippm-hybrid-two-step.xml"/> href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ippm-hybrid-two-step.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9341.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9341.xml"/>

      </references>
    </references>
    <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
        The authors express their appreciation and gratitude to <contact  fullname="Pascal Thubert"/> for the review, insightful questions, and helpful comments.
      </t>
    </section>
</back>
</rfc>