<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info"
     docName="draft-varga-detnet-service-sub-layer-oam-03"
         ipr="trust200902"
         submissionType="IETF">
  <front>
    <title abbrev="DetNet Service-Sub-layer OAM">
    Deterministic Networking (DetNet): OAM Functions for The Service Sub-Layer</title>

  <author fullname="Bal&aacute;zs 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="J&aacute;nos 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>

    <author initials="G." surname="Mirsky" fullname="Greg Mirsky">
      <organization>Ericsson</organization>
      <address>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>

<!--
    <author fullname="James Bond" initials="J." surname="Bond">
      <organization>MI6</organization>
      <address>
        <email>james@bond.com</email>
      </address>
    </author>
-->

  <date />
  <workgroup>DetNet</workgroup>

  <abstract>
   <t>
     Operation, Administration, and Maintenance (OAM) tools are essential for 
	 a deterministic network.  The DetNet architecture 
	 <xref target="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. 
   </t>
  </abstract>
  </front>

 <middle>
 <section title="Introduction" anchor="sec_intro">
  <t>
     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 <xref target="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). 
  </t>
  <t>
     Framework of Operations, Administration and Maintenance (OAM) for
	 Deterministic Networking (DetNet) is described in 
	 <xref target="I-D.ietf-detnet-oam-framework"/>. OAM for the DetNet MPLS 
	 data plane is described in <xref target="I-D.ietf-detnet-mpls-oam"/> and 
	 OAM for the DetNet IP data plane  is described in 
	 <xref target="I-D.ietf-detnet-mpls-oam"/>.
  </t>
  <t>
     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.
  </t>
  <t> 
	 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 <xref target="cha-on-dss-oam"/>) and requirements
	 (see section <xref target="req-on-dss-oam"/>) introduced by PREOF.
  </t>
  <t>
     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:
	 <list style="symbols">
         <t>Identity of a DetNet service sub-layer node. </t>
		 <t>Discover Ingress/Egress flow-specific configuration of a DetNet 
		 service sub-layer node. </t>
         <t>Detect the status of the flow-specific service sub-layer 
		 function. </t>
     </list>
  </t>
 
  <t>
     DetNet PING applies both to IP and MPLS DetNet data planes.
  </t>  

</section> <!-- end of introduction -->

<section title="Terminology">
 <section title="Terms Used in This Document">
  <t>
   This document uses the terminology established in the DetNet architecture
   <xref target="RFC8655"/>, and the reader is assumed
   to be familiar with that document and its terminology.
  </t>
 </section>

 <section title="Abbreviations">
  <t>
   The following abbreviations are used in this document:
   <list style="hanging" hangIndent="14">
    <t hangText="DetNet">Deterministic Networking.</t>
    <t hangText="PEF">Packet Elimination Function.</t>
    <t hangText="POF">Packet Ordering Function.</t>
	<t hangText="PREOF">Packet Replication, Elimination and Ordering Functions.</t>
    <t hangText="PRF">Packet Replication Function.</t>
   </list>
  </t>
 </section>

 <section title="Requirements Language">
  <t>
    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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
    only when, they appear in all capitals, as shown here.
  </t>
 </section>
</section>  <!-- end of terminology -->

<!-- ===================================================================== -->


<section anchor="cha-on-dss-oam" title="DetNet Service Sub-layer OAM Challenges">
 <section anchor="dss-example" title="Illustrative example"> 
  <t>
     This section introduces an example that is used to explain the DetNet
	 Service Sub-layer OAM challenges. <xref target="PREOF-scene"/> shows a 
	 DetNet flow on which PREOF functions are applied during forwarding from 
	 source to destination. 
  </t>  

 <figure title="PREOF scenario in a DetNet network" anchor="PREOF-scene">
 <artwork align="center"><![CDATA[

     <------------------------ 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)

]]>
 </artwork></figure>

  <t>
     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 <xref target="RFC8655"/> for relay node 
	 definition). 
  </t>
  <t>
     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.
  </t>
 </section>  

 <section anchor="dss-specifics" title="DetNet Service Sub-layer Specifics for OAM"> 
  <t>
     Several DetNet Service Sub-layer specifics have to be considered for OAM.
	 <list style="numbers">
         <t>The service sub-layer graph is segmented into multiple parts, as 
		 forwarding sub-layer paths are terminated at DetNet relay nodes. </t>
         <t>These are particular characteristics of DetNet PW:	
			<list style="numbers">
			<t>PREOF acts as per-packet protection. PEF is a brand-new 
			functionality at network layer, due to the per-packet merge action.</t>
			<t>All paths are active and forward traffic. These paths may have 
			a different number of hops.</t>
			<t>Mandatory usage of a sequence number.</t>
			</list>
		 </t>
     </list>
  </t>
  <t>
     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).
  </t>
 </section>  

 <section anchor="dss-oam-packet-infos" title="Information Needed during DetNet OAM Packet Processing"> 
  <t>
     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.
  </t>
  <t>
     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 <xref target="detnet-ping"/>.) 
  </t>
  <t>
	 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 <xref target="detnet-ping"/>.
  </t>
  <t>
     Note: the question list is non-exhaustive.
  </t>
 </section>  

 <section anchor="dss-oam-dACH" title="A Possible Format of DetNet Associated Channel Header (d-ACH)"> 
  <t>
     [Editor's note: The content of this section has been discussed and the 
	 outcome of the discussion has been documented in 
	 <xref target="I-D.ietf-detnet-mpls-oam"/>.]
  </t>
 </section>
</section>  <!-- end of challenges -->

<section anchor="req-on-dss-oam" title="Requirements on OAM for DetNet Service Sub-layer">
  <t>
     [Editor's note: The content of this section has been discussed and the 
	 outcome of the discussion has been documented in 
	 <xref target="I-D.ietf-detnet-oam-framework"/>.]
  </t>
</section>  <!-- end of requirements -->


<section anchor="detnet-ping" title="DetNet PING">
 <section anchor="dping-overview" title="Overview"> 
  <t>
     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.
  </t>
  <t>
     The following relay node roles can be distinguished:
	 <list style="numbers">
         <t>DetNet PING originator node,</t>
         <t>Intermediate DetNet service sub-layer node,</t>
         <t>DetNet PING targeted node.</t>
     </list>
  </t>
  <t>
     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.
  </t>
  <t>
     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 <xref target="OAM-processing"/>).
  </t>
  <t>
     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).
  </t>
 </section>  <!-- end of DetNet PING overview -->

 <section anchor="OAM-processing" title="OAM processing at the DetNet service sub-layer">
  <t>
     Detailed OAM packet processing rules of various DetNet relay nodes are 
	 described in the following sections.
  </t>
   <section anchor="relay-PRF" title="Relay node with PRF">
    <t>
       A DetNet relay node with PRF processes DetNet OAM packets in a stateless manner.
    </t>
    <t>
       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).
    </t>  
    <t>
       A DetNet Echo-Reply packet MUST contain the following information:
  	   <list style="symbols">
         <t>Identities related to the DetNet service sub-layer node 
		 (e.g., Node-ID, local Flow-ID),</t>
         <t>Ingress/Egress flow related configuration (e.g., in/out member 
		 flow specific information (including forwarding sub-layer specifics)),</t>
         <t>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 
		 <xref target="IEEE8021CB"/>).</t>
       </list>
    </t>  
    <t>
       A DetNet Echo-Reply packet MAY contain the following information:
  	   <list style="symbols">
         <t>PRF related local counters.</t>
	   </list>
    </t>  
   </section>  <!-- end of Relay with PRF -->

   <section anchor="relay-PEF" title="Relay node with PEF">
    <t>
       A DetNet relay node with PEF processes DetNet OAM packets in a stateful manner.
    </t>
    <t>
       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.
    </t>  
    <t>
       Note, PEF MAY use a simplified elimination algorithm for 
	   DetNet Echo-Request packets (e.g., "MatchRecoveryAlgorithm" in 
	   <xref target="IEEE8021CB"/>) as OAM is a slow protocol.
    </t>
    <t>
       A DetNet-Echo-Reply packet MUST contain the following information:
  	   <list style="symbols">
         <t>Identities related to the DetNet service sub-layer node 
		 (e.g., Node-ID, local Flow-ID),</t>
         <t>Ingress/Egress flow related configuration (e.g., in/out member 
		 flow specific information (including forwarding sub-layer specifics))
		 ,</t>
         <t>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 
		 <xref target="IEEE8021CB"/>).</t>
       </list>
    </t>  
    <t>
       A DetNet Echo-Reply packet MAY contain the following information:
  	   <list style="symbols">
         <t>PEF-related local counters.</t>
	   </list>
    </t>  
   </section>  <!-- end of Relay with PEF -->

   <section anchor="relay-POF" title="Relay node with POF">
    <t>
       A DetNet relay node with POF processes DetNet OAM packets in a stateless manner.
    </t>
    <t>
       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. 
    </t>  
    <t>
       A DetNet Echo-Reply packet MUST contain the following information:
  	   <list style="symbols">
         <t>Identities of the DetNet service sub-layer node (e.g., Node-ID, 
		 local Flow-ID),</t>
         <t>Ingress/Egress flow related configuration (e.g., in/out member 
		 flow specific information (including forwarding sub-layer specifics))
		 ,</t>
         <t>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 
		 <xref target="I-D.varga-detnet-pof"/>).</t>
       </list>
    </t>  
    <t>
       A DetNet Echo-Reply packet MAY contain the following information:
  	   <list style="symbols">
         <t>POF-related local counters.</t>
	   </list>
    </t>  
   </section>  <!-- end of Relay with POF -->

   <section anchor="relay-without-PREOF" title="Relay node without PREOF">
    <t>
       A DetNet relay node without PREOF processes DetNet OAM packets in a stateless 
	   manner.
    </t>
    <t>
       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). 
    </t>  
    <t>
       A DetNet Echo-Reply packet MUST contain the following information:
  	   <list style="symbols">
         <t>Identities of the DetNet service sub-layer node (e.g., Node-ID, 
		 local Flow-ID),</t>
         <t>Ingress/Egress flow-related configuration (e.g., in/out member 
		 flow specific information (including forwarding sub-layer specifics))
		 .</t>
       </list>
    </t>  
   </section>  <!-- end of Relay without PREOF -->

 </section>  <!-- end of DetNet PING processing -->
</section>  <!-- end of DetNet PING -->

<!-- ===================================================================== -->


<section title="Security Considerations">
  <t>
     Tbd.
  </t>
</section>


<section anchor="iana" title="IANA Considerations">
 <section anchor="iana-flag" title="DetNet MPLS OAM Flags Registry">
  <t>
     [Editor's note: The content of this section has been discussed and the 
	 outcome of the discussion has been documented in 
	 <xref target="I-D.ietf-detnet-mpls-oam"/>.]
  </t>
 </section>
</section>

<section anchor="acks" title="Acknowledgements">
 <t>
   Authors extend their appreciation to Janos Szabo and Gyorgy Miklos for 
   their insightful comments and productive discussion that helped to improve
   the document.
  </t>
</section>

</middle>

<back>
  <references title="Normative References">
   <?rfc include="reference.RFC.2119"?>
   <?rfc include="reference.RFC.4928"?>
   <?rfc include="reference.RFC.8126"?>
   <?rfc include="reference.RFC.8174"?>
   <?rfc include="reference.RFC.8655"?>
   <?rfc include="reference.RFC.8964"?>
  </references>
  <references title="Informative References">
   <?rfc include="reference.I-D.ietf-detnet-oam-framework"?>
   <?rfc include="reference.I-D.ietf-detnet-mpls-oam"?>
   <?rfc include="reference.I-D.ietf-detnet-ip-oam"?>
   <?rfc include="reference.I-D.varga-detnet-pof"?>
   <reference anchor="IEEE8021CB" 
			target="https://standards.ieee.org/standard/802_1CB-2017.html">
        <front>
         <title>IEEE Standard for Local and metropolitan area
          networks -- Frame Replication and Elimination for Reliability
		 </title>
         <author>
              <organization>IEEE</organization>
         </author>
         <date month="October" year="2017"/>
        </front>
		<seriesInfo name="DOI" value="10.1109/IEEESTD.2017.8091139" />
   </reference>
  </references>
 </back>
</rfc>
