<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [

<!ENTITY RFC.6291 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6291.xml">
<!ENTITY RFC.9197 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9197.xml">
<!ENTITY RFC.6669 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6669.xml">
<!ENTITY RFC.5085 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5085.xml">
<!ENTITY RFC.7799 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml">
<!ENTITY RFC.9232 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9232.xml">
<!ENTITY RFC.9341 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9341.xml">
<!ENTITY RFC.4733 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4733.xml">
<!ENTITY RFC.8029 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml">
<!ENTITY RFC.9551 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9551.xml">
<!ENTITY RFC.6374 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6374.xml">
<!ENTITY RFC.7276 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7276.xml">
<!ENTITY I-D.ietf-raw-architecture SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-raw-architecture.xml">
<!ENTITY I-D.song-opsawg-ifit-framework SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.song-opsawg-ifit-framework.xml">
<!ENTITY I-D.kumar-ippm-ifa SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.kumar-ippm-ifa.xml">


]>
<?rfc toc="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no" ?>
<?rfc symrefs="yes"?>
<rfc category="bcp" consensus="true"
     docName="draft-ietf-opsawg-oam-characterization-09" ipr="trust200902"
     submissionType="IETF" updates="6291">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc compact="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title abbrev="Characterizing OAM">Guidelines for Characterizing
    "OAM"</title>

    <author fullname="Carlos Pignataro" initials="C." surname="Pignataro">
      <organization abbrev="Blue Fern Consulting">Blue Fern
      Consulting</organization>

      <address>
        <postal>
          <country>US</country>
        </postal>

        <email>cpignata@gmail.com</email>

        <email>carlos@bluefern.consulting</email>
      </address>
    </author>

    <author fullname="Adrian Farrel" initials="A." surname="Farrel">
      <organization>Old Dog Consulting</organization>

      <address>
        <postal>
          <country>UK</country>
        </postal>

        <email>adrian@olddog.co.uk</email>
      </address>
    </author>

    <author fullname="Tal Mizrahi" initials="T." surname="Mizrahi">
      <organization abbrev="">Huawei</organization>

      <address>
        <postal>
          <street>Matam</street>

          <city>Haifa</city>

          <code>3190501</code>

          <country>Israel</country>
        </postal>

        <email>tal.mizrahi.phd@gmail.com</email>
      </address>
    </author>

    <date/>

    <area>Ops Area</area>

    <workgroup>OPS Area Working Group</workgroup>

    <abstract>
      <t>As the IETF continues to produce and standardize different
      Operations, Administration, and Maintenance (OAM) protocols and
      technologies, various qualifiers and modifiers are prepended to the OAM
      abbreviation. While, at first glance, the most used appear to be well
      understood, the same qualifier may be interpreted differently in
      different contexts. A case in point is the qualifiers "in-band" and
      "out-of-band" which have their origins in the radio lexicon, and which
      have been extrapolated into other communication networks.</t>

      <t>This document considers some common qualifiers and modifiers that are
      prepended, within the context of packet networks, to the OAM
      abbreviation and lays out guidelines for their use in future IETF
      work.</t>

      <t>This document updates RFC 6291 by adding to the guidelines for the
      use of the term "OAM". It does not modify any other part of RFC
      6291.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>It is not uncommon for historical and popular terms to have nuances
      in how they are interpreted or understood. This was, for example, the
      case with the abbreviation for Operations, Administration, and
      Maintenance, "OAM", and <xref target="RFC6291"/> provided guidelines for
      its use as well as definitions of its constituent parts.</t>

      <t>Characterizations or qualifiers for "OAM" within packet networks
      often encounter similar problems of interpretation, such as with the
      adjective phrases "in-band" and "out-of-band". This document considers
      some common qualifiers and modifiers that are prepended to the OAM
      abbreviation, and lays out guidelines for their use in future IETF work
      to achieve consistent and unambiguous characterization.</t>

      <t>This document updates <xref target="RFC6291"/> by adding to the
      guidelines for the use of the term "OAM". It does not modify any other
      part of <xref target="RFC6291"/>.</t>
    </section>

    <section anchor="band" title="In-Band and Out-of-Band OAM">
      <t>Historically, the terms "in-band" and "out-of-band" were used
      extensively in radio communications as well as in telephony signaling
      <xref target="RFC4733"/>. In both these cases, there is an actual "Band"
      (i.e., a "Channel" or "Frequency") to be within or outside.</t>

      <t>While those terms, useful in their simplicity, continued to be
      broadly used to mean "within something" and "outside something", a
      challenge is presented for IP communications and packet-switched
      networks (PSNs) which do not have a "band" per se, and, in fact, have
      multiple "somethings" that OAM traffic can be carried within or outside.
      A frequently encountered case is the use of "in-band" to mean either
      In-Packet or on-path.</t>

      <t>Within the IETF, the terms "in-band" and "out-of-band" cannot be
      reliably understood consistently and unambiguously. Context-specific
      definitions of these terms are inconsistent and therefore cannot be
      generalized. More importantly, the terms are not self-defining to any
      further extent and cannot be understood by someone exposed to them for
      the first time, since there is no "band" in IP.</t>

      <t>There are many examples of "in-band OAM" and "out-of-band OAM" in
      published RFCs. For instance, the term "in-band" appears in both 
      Virtual Circuit Connectivity Verification (VCCV) <xref
      target="RFC5085"/> and OAM for Deterministic Networking (DetNet) <xref 
      target="RFC9551"/>. While the context in each of these documents is 
      clear, the term carries different meanings in each case. These two 
      examples, as well as other examples of uses of the term "in-band" in 
      previous documents are described throughout <xref target="terms"/>.</t>

      <t>While interpreting existing documents, it is important to understand
      the semantics of what "band" is a proxy for, and to be more explicit if
      those documents are updated. This document does not change the meaning
      of any terms in any prior RFCs.</t>
    </section>

    <section anchor="terms" title="Terminology and Guidance">
      <t>This document recommends avoiding the terms "in-band" and
      "out-of-band" when referring to OAM. Instead, it encourages the use of
      more fine-grained and descriptive terminology. The document also
      presents alternative terms and definitions for use in future IETF
      documents referencing OAM, without precluding the use of other precise,
      descriptive terms that do not rely on the "-band" convention.</t>

      <t>The terminology presented in this section classifies OAM according to
      three criteria: whether it operates in an active, passive, or hybrid 
      mode; whether it follows the same path as data traffic; and whether it 
      receives the same treatment as data traffic.</t>

      <section title="Active, Passive, Hybrid, and In-Packet OAM">
        <t><xref target="RFC7799"/> provides clear definitions for active and
        passive performance assessment, enabling the construction of metrics
        and methods to be described as either "Active" or "Passive". Even
        though <xref target="RFC7799"/> does not explicitly use these terms as
        modifiers of "OAM", they are widely used in practice and are included
        here for clarity. The terms "Active", "Passive" and "Hybrid", as
        described below, are consistent with <xref target="RFC7799"/>. <list
            style="hanging">
            <t hangText="Active OAM:"><br/> Depends on dedicated OAM
            packets.</t>

            <t hangText="Passive OAM:"><br/> Depends solely on the observation
            of one or more existing data packet streams and does not use
            dedicated OAM packets.</t>

            <t hangText="Hybrid OAM:"><br/> Uses augmentation or modification
            of the packet stream. Examples of protocols classified as "Hybrid
            OAM" include Alternate Marking <xref target="RFC9341"/>, In situ 
            OAM (IOAM) <xref target="RFC9197"/>, and MPLS Loss Measurement 
            <xref target="RFC6374"/>. Hybrid OAM can be implemented by
            piggybacking OAM-related information onto data packets, as
            described in <xref target="RFC9197"/>, or by utilizing reserved
            fields in the packet header or specific values of existing header
            fields, as proposed in <xref target="RFC9341"/>. Direct loss
            measurment <xref target="RFC6374"/> is an example of "Hybrid OAM"
            in which user packets are not modified by the protocol. Instead,
            OAM packets are used to exchange information about user packet
            counters, allowing for packet loss computation.</t>
          </list></t>

        <t>This document defines the term In-Packet OAM as a more specific and
        narrowly scoped instance within the broader category of Hybrid
        OAM.</t>

        <t>
          <list style="hanging">
            <t hangText="In-Packet OAM:"><br/>The OAM information is carried
            in the packets that also carry the data traffic. This is a 
            specific case of Hybrid OAM. It was sometimes referred to as 
            "in-band".</t>
          </list>
        </t>

        <t>The MPLS echo request/reply messages <xref target="RFC8029"/> are
        an example of "Active OAM", since they are described as "An MPLS echo
        request/reply is a (possibly MPLS-labeled) IPv4 or IPv6 UDP
        packet".</t>

        <t>IOAM <xref target="RFC9197"/> is an example of "Hybrid OAM"
        that is also "In-Packet OAM", given that it: '...records OAM
        information within the packet while the packet traverses a particular
        network domain. The term "in situ" refers to the fact that the OAM
        data is added to the data packets rather than being sent within
        packets specifically dedicated to OAM.' Another example of In-Packet
        OAM is Alternate Marking <xref target="RFC9341"/>, in which a small 
        number of bits in the packet header is used for marking a subset of 
        packets in a flow.</t>

        <t>An example of "Hybrid OAM" which is not classified as "In-Packet
        OAM" is Direct loss measurement <xref target="RFC6374"/>.</t>

        <t>Initially, "In situ OAM" <xref target="RFC9197"/> was also referred
        to as "In-band OAM", but was renamed due to the overloaded meaning of
        "In-band OAM". Further, <xref target="RFC9232"/> also intertwines the
        terms "in-band" with "in situ", though <xref
        target="I-D.song-opsawg-ifit-framework"/> settled on using "in Situ".
        Other similar uses, including <xref target="P4-INT-2.1"/> and <xref
        target="I-D.kumar-ippm-ifa"/>, still use variations of "in-band", "in
        band", or "inband".</t>

        <!--
<t>
  It is noteworthy that In-Packet OAM cannot be Non-Path-Congruent OAM.
</t>
-->
      </section>

      <section title="Path Followed OAM">
        <t>
          <list style="hanging">
            <t hangText="Path-Congruent OAM:"><br/>The OAM information follows
            the exact same path as the observed data traffic. This was
            sometimes referred to as "in-band".</t>

            <t hangText="Non-Path-Congruent OAM:"><br/>The OAM information
            does not follow the exact same path as the observed data traffic.
            This can also be called Path-Incongruent OAM, and was sometimes
            referred to as "out-of-band".</t>
          </list>
        </t>

        <t>In this document, the term "path-congruent packets" describes
        packets that follow the exact same path (i.e., traverse the same nodes
        and links) within a network. Note that this definition does not
        describe how the packets are treated in queues within the nodes on the
        path. A further concept, "equal-forwarding-treatment" describes how
        path-congruent packets receive the same forwarding treatment (e.g.,
        Quality of Service (QoS)).</t>

        <t>An example of "Path-Congruent OAM" is the Virtual Circuit
        Connectivity Verification (VCCV), described is <xref
        target="RFC5085"/> as "The VCCV message travels in-band with the
        Session and follows the exact same path as the user data for the
        session". Thus, the term "in-band" in <xref target="RFC5085"/> refers
        to using the same path as the user data. This term is also used in
        Section 2 of <xref target="RFC6669"/> with the same meaning, and the
        word "congruent" is mentioned as synonymous.</t>
      </section>

      <section title="Packet Forwarding Treatment OAM">
        <t>
          <list style="hanging">
            <t hangText="Equal-Forwarding-Treatment OAM:"><br/>The OAM packets
            receive the same forwarding (e.g., QoS) treatment as user data
            packets. This was sometimes referred to as "in-band".</t>

            <t hangText="Different-Forwarding-Treatment OAM:"><br/>The OAM
            packets receive different forwarding (e.g., QoS) treatment as user
            data packets. This was sometimes referred to as "out-of-band".</t>
          </list>
        </t>

        <t>The motivation for Equal-Forwarding-Treatment OAM lies in the
        desire to ensure that OAM packets experience the same network
        conditions as the user data they are intended to monitor. This
        includes not only traversing the same topological path but also
        receiving identical Quality of Service (QoS) treatment, such as
        queuing, scheduling, and traffic shaping. When both topological and
        forwarding treatment equivalence are achieved, the OAM packets are
        said to exhibit fate-sharing <xref target="RFC7276"/> with the data
        traffic. Fate-sharing ensures that any impairments or anomalies
        affecting the user traffic are also reflected in the behavior of the
        OAM packets, thereby making the results of the OAM observations more
        operationally meaningful and actionable. Without such equivalence,
        discrepancies in treatment could lead to misleading measurements or
        diagnostics, and even inadequate corrective actions, reducing the 
        utility of the OAM mechanism for performance monitoring and fault 
        detection.</t>

        <t>An example of "Equal-Forwarding-Treatment OAM" is presented in
        <xref target="RFC9551"/> in the context of DetNet OAM: "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". This is classified in 
        <xref target="RFC9551"/> as "In-band OAM". Similarly, the property of 
        "Different-Forwarding-Treatment OAM" can be found in the following 
        definition in <xref target="RFC9551"/>: "Out-of-band OAM: an active 
        OAM method whose path through the DetNet domain may not be 
        topologically identical to the path of the monitored DetNet flow, its 
        test packets may receive different QoS and/or PREOF treatment, or 
        both." <xref target="I-D.ietf-raw-architecture"/> uses similar text.
        </t>
      </section>

      <section title="Using Multiple Criteria">
        <t>OAM protocols and tools can be classified according to the three
        criteria that were described in the previous sections. However, not
        all criteria are applicable to all OAM protocols, and not all
        combinations are necessarily possible.</t> 

        <t>When defining a new OAM protocol or analyzing an existing one, it
        is recommended to explicitly consider which of these criteria are
        applicable and to describe the protocol accordingly. As a first step,
        all OAM mechanisms can be classified according to the first criterion,
        as Active, Passive, or Hybrid/In-Packet. Further classification
        according to the other two criteria should be considered on a 
        case-by-case basis.</t>

        <t>In some cases, certain criteria are not relevant, or not all 
        combinations are possible. For example:</t>

        <t>
          <list style="symbols">
            <t>Passive OAM relies solely on observing existing data traffic
            and does not generate dedicated OAM packets. As such, the
            path congruence and forwarding treatment criteria are not 
            relevant, since no dedicated OAM packets are exchanged between the
            measurment points.</t>

            <t>Non-Path-Congruent OAM, by nature, cannot be
            Equal-Forwarding-Treatment.</t>
          </list>
        </t>


        <t>A few example of OAM classification according to the three criteria
        are presented below:</t>

        <t>
          <list style="symbols">
            <t>IP Ping, which uses ICMP Echo messages, can be classified as
            Active OAM. Since it is not guaranteed to follow
            the same path or receive the same treatment as user data packets,
            it is classified as Non-Path-Congruent and, consequently, 
            as Different-Forwarding-Treatment.</t>

            <t>When IOAM <xref target="RFC9197"/> is incorporated in data
            packets it can be classified as In-Packet, Path-Congruent and
            Equal-Forwarding-Treatment.</t>

            <t>VCCV <xref target="RFC5085"/>, as discussed above, is
            classified as Active, Path-Congruent and
            Different-Forwarding-Treatment.</t>

            <t>MPLS inferred loss measurement <xref target="RFC6374"/> uses
            specially generated test messages, and therefore can be classified
            as Active. It is also Path-Congruent, and can be deployed either
            as Equal- or Different-Forwarding-Treatment OAM. MPLS direct loss
            measurement <xref target="RFC6374"/> uses OAM messages that
            exchange counters that count user data traffic. Hence, it is
            classified as Hybrid OAM, and as in the inferred mode, it is
            Path-Congruent, and can be either Equal- or
            Different-Forwarding-Treatment OAM.</t>
          </list>
        </t>

        <t>This multi-dimensional classification enables a more precise and
        consistent understanding of OAM mechanisms.</t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>Security is improved when terms are used with precision, and their
      definitions are unambiguous.</t>
    </section>

    <section title="IANA Considerations">
      <t>This document has no IANA actions.</t>
    </section>

    <section title="Acknowledgements">
      <t>The creation of this document was triggered when observing one of
      many on-mailing-list discussions of what these terms mean, and how to
      abbreviate them. Participants on that mailing thread include,
      alphabetically: Adrian Farrel, Alexander Vainshtein, Florian Kauer,
      Frank Brockners, Greg Mirsky, Italo Busi, Loa Andersson, Med Boucadair,
      Michael Richardson, Quan Xiong, Stewart Bryant, Tom Petch, Eduard
      Vasilenko, and Xiao Min.</t>

      <t>The authors wish to thank, chronologically, Hesham Elbakoury, Michael
      Richardson, Stewart Bryant, Greg Mirsky, Med Boucadair, Loa Andersson,
      Thomas Graf, Alex Huang Feng, Xiao Min, Dhruv Dhody, Henk Birkholz, Alex
      Huang Feng, Tom Petch, Roni Even, Tim Chown, Marcus Ihlar, Med
      Boucadair, and Benoit Claise for their thorough review and useful
      feedback comments that greatly improved this document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC.6291;
    </references>

    <references title="Informative References">
      &RFC.7799;

      &RFC.9197;

      &RFC.6669;

      &RFC.6374;

      &RFC.5085;

      &RFC.9232;

      &RFC.8029;

      &RFC.9341;

      &RFC.4733;

      &RFC.7276;

      &I-D.ietf-raw-architecture;

      &I-D.song-opsawg-ifit-framework;

      &RFC.9551;

      &I-D.kumar-ippm-ifa;

      <reference anchor="P4-INT-2.1"
                 target="https://p4.org/p4-spec/docs/INT_v2_1.pdf">
        <front>
          <title>In-band Network Telemetry (INT) Dataplane Specification,
          Version 2.1</title>

          <author fullname="The P4.org Applications Working Group" initials=""
                  surname=""/>

          <date day="11" month="11" year="2020"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
