Blue Fern Consulting

United States of America / Spain carlos@bluefern.consulting

Old Dog Consulting

United Kingdom adrian@olddog.co.uk

Huawei

Matam Haifa 3190501 Israel tal.mizrahi.phd@gmail.com

OPS opsawg OAM in-band out-of-band path-congruent active OAM passive OAM hybrid OAM in-data-packet forwarding treatment 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 qualifiers 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. This document recommends not to use these two terms when referring to OAM. 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 IETF documents. This document extends RFC 6291 by adding to the guidelines for the use of the term "OAM" with qualifiers. It does not modify any part of RFC 6291.

Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2026 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
  • .  Requirements Language
• .  In-Band and Out-of-Band OAM
• .  Terminology and Guidance
  • .  Recommendation
  • .  Active, Passive, and Hybrid OAM
  • .  Path-Congruent OAM
  • .  Packet-Forwarding-Treatment OAM
  • .  Using Multiple Criteria
  • .  Summary of Terms
  • .  Applicability and Conformance Statement
• .  Security Considerations
• .  IANA Considerations
• .  References
  • .  Normative References
  • .  Informative References
• .  Examples of the Use of the Term "In-Band"
• Acknowledgements
• Authors' Addresses

Introduction 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 provides guidelines for its use as well as definitions of its constituent parts. 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 it lays out guidelines for their use in future IETF work to achieve consistent and unambiguous characterization (). This document focuses on qualifiers for the term "OAM", not the definition of "OAM" or "OAM protocols". Readers should refer to for an overview of OAM scope. This document does not extend or restrict that scope. The term "OAM protocols" refers to protocols used for implementing measurement or diagnostic OAM functions as defined in . While this document introduces new terminology, it does not update or change the meaning of terminology found in existing RFCs.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

In-Band and Out-of-Band OAM Historically, the terms "in-band" and "out-of-band" were used extensively in radio communications as well as in telephony signaling . In both these cases, there is an actual "Band" (i.e., a "Channel" or "Frequency") to be within or outside. 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-data-packet or on-path. There are many examples of "in-band OAM" and "out-of-band OAM" in RFCs. For instance, the term "in-band" appears in both Virtual Circuit Connectivity Verification (VCCV) and OAM for Deterministic Networking (DetNet) . 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 other documents are described in . Generally speaking, 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. While interpreting existing documents, it is important to understand the semantics of what the term "band" refers to, and to be more explicit if those documents are updated. This document does not change the meaning of any terms in any prior RFCs. The applicability of the guidance in is provided in .

Terminology and Guidance

Recommendation 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 that discuss OAM (including a reference to this document), without precluding the use of other precise, descriptive terms that do not rely on the "-band" convention. 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 ().

Active, Passive, and Hybrid OAM 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 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 . This document does not update or change the terms of .

Active OAM:

Uses dedicated OAM packets.

Passive OAM:

Relies on the observation of one or more existing data packet streams and does not use dedicated OAM packets and does not modify data packets.

Hybrid OAM:

Uses a combination of Active Methods and Passive Methods, which may include augmentation or modification of the stream of interest. makes a distinction between Hybrid Type I, referring to a single stream of interest, and Hybrid Type II, referring to two or more streams of interest.

This document defines the term "In-Data-Packet OAM" as a more specific and narrowly scoped instance within the broader category of Hybrid OAM. This new term allows for a more fine-grained classification of OAM mechanisms, as the broad category of Hybrid OAM includes a diverse set of possible OAM methods.

In-Data-Packet OAM:

OAM-related 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".

Note that In-Data-Packet OAM is a specific case of Hybrid Type I, as it is applied to a single stream of interest. The following examples illustrate the terms Active, Passive, Hybrid, and In-Data-Packet OAM:

• The MPLS echo request/reply messages 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".
• Monitoring a packet stream by maintaining counters for the packets within the stream is an example of "Passive OAM".
• An example of "Hybrid Type I OAM" that is also "In-Data-Packet OAM", is an IOAM (In Situ OAM) trace option that is incorporated into data packets of a single stream of interest. According to , IOAM '...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 "Hybrid Type I OAM" that is also "In-Data-Packet OAM" is Alternate Marking , when applied to data packets of a single stream. In this case, a small number of bits in the packet header is used for marking a subset of packets in a flow.
• An example of "Hybrid Type I OAM" that is not classified as "In-Data-Packet OAM" is Direct Loss Measurement , in which user packets are not modified by the protocol. Instead, OAM packets are used for carrying information about observed network characteristics -- namely, user packet counter values that allow for packet loss computation.
• Another example of "Hybrid Type I OAM" that is not "In-Data-Packet OAM" is the case where a packet stream is (actively) generated while an existing stream of interest is (passively) observed. This example was introduced in as a Hybrid Type I method. Extending this example, if the packets of the active stream include an IOAM trace option, the method is characterized by the more general term, Hybrid Type I.

Path-Congruent OAM

Path-Congruent OAM:

The OAM information follows the exact same forwarding path as the observed data traffic.

Non-Path-Congruent OAM:

The OAM information is not guaranteed to follow the exact same forwarding path as the observed data traffic.

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. An example of "Path-Congruent OAM" is the Virtual Circuit Connectivity Verification (VCCV) Type 1 (), which was also referred to as "In-Band VCCV". The term "congruent" also appears in in the context of path sharing.

Packet-Forwarding-Treatment OAM

Equal-Forwarding-Treatment OAM:

The OAM packets receive the same forwarding treatment (e.g., QoS) as user data packets.

Different-Forwarding-Treatment OAM:

The OAM packets might receive different forwarding treatment (e.g., QoS) than user data packets.

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 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, fault detection, and fault mitigation. An example of "Equal-Forwarding-Treatment OAM" is presented in in the context of Deterministic Networking (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". (The property of "Equal-Forwarding-Treatment" is referred to in as "In-band OAM".)

Using Multiple Criteria 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. For example:

• 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, because no dedicated OAM packets are exchanged between the measurement points.
• Non-Path-Congruent OAM, by nature, cannot be Equal-Forwarding-Treatment.

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

• 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.
• When an IOAM trace option is incorporated in data packets, it can be classified as In-Data-Packet, Path-Congruent, and Equal-Forwarding-Treatment.
• VCCV , as discussed above, is classified as Active, Path-Congruent, and Different-Forwarding-Treatment.
• MPLS Inferred Loss Measurement (ILM) () 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 (DLM) () uses OAM messages that carry counters that count user data traffic. Hence, it is classified as Hybrid Type I OAM, and as in the Inferred Loss Measurement, it is Path-Congruent and can be either Equal- or Different-Forwarding-Treatment OAM.

In measurement protocols, accurate results depend on Path-Congruence and Equal-Forwarding-Treatment. In contrast, these properties are not always required in other OAM protocols. For example, Bidirectional Forwarding Detection (BFD) control packets are often sent with the highest priority, which means they do not adhere to the Equal-Forwarding-Treatment property. This multidimensional classification enables a more precise and consistent understanding of OAM mechanisms.

Summary of Terms This section summarizes the terminology.

Active OAM:

Uses dedicated OAM packets.

Passive OAM:

Relies on the observation of one or more existing data packet streams and does not use dedicated OAM packets and does not modify data packets.

Hybrid OAM:

Uses a combination of Active Methods and Passive Methods, which may include augmentation or modification of the stream of interest. makes a distinction between Hybrid Type I, referring to a single stream of interest, and Hybrid Type II, referring to two or more streams of interest.

In-Data-Packet OAM:

OAM-related 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".

Path-Congruent OAM:

The OAM information follows the exact same forwarding path as the observed data traffic.

Non-Path-Congruent OAM:

The OAM information is not guaranteed to follow the exact same forwarding path as the observed data traffic.

Equal-Forwarding-Treatment OAM:

The OAM packets receive the same forwarding treatment (e.g., QoS) as user data packets.

Different-Forwarding-Treatment OAM:

The OAM packets might receive different forwarding treatment (e.g., QoS) than user data packets.

Applicability and Conformance Statement The definitions here SHOULD be used by IETF documents qualifying the term "OAM". IETF documents that explicitly want to create different characterizations beyond the definitions of the terms in this document, can introduce such terms provided they are different from the ones defined in this document for clarity's sake. See also . Authors who follow the terms as defined in this document SHOULD incorporate the following in the document (typically in the terminology section): <BEGIN TEMPLATE TEXT> OAM terms [INSERT TERMS] are to be interpreted as described in [RFC10014]. <END TEMPLATE TEXT>

Security Considerations Security is improved when terms are used with precision, and their definitions are unambiguous.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. At first glance, the acronym "OAM" seems to be well-known and well-understood. Looking at the acronym a bit more closely reveals a set of recurring problems that are revisited time and again. This document provides a definition of the acronym "OAM" (Operations, Administration, and Maintenance) for use in all future IETF documents that refer to OAM. There are other definitions and acronyms that will be discussed while exploring the definition of the constituent parts of the "OAM" term. This memo documents an Internet Best Current Practice. This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The P4.org Applications Working Group Version 2.1 This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets. It obsoletes RFC 2833. This memo captures and expands upon the basic framework defined in RFC 2833, but retains only the most basic event codes. It sets up an IANA registry to which other event code assignments may be added. Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events. The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use. This document provides a number of clarifications to the original document. However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. This memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events. [STANDARDS-TRACK] This document describes Virtual Circuit Connectivity Verification (VCCV), which provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions (such as connectivity verification) to be used over that control channel. VCCV applies to all supported access circuit and transport types currently defined for PWs. [STANDARDS-TRACK] This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK] Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. [STANDARDS-TRACK] This document provides an overview of the Operations, Administration, and Maintenance (OAM) toolset for MPLS-based transport networks. The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data plane) that are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels. This overview includes a brief recap of the MPLS Transport Profile (MPLS-TP) OAM requirements and functions and the generic mechanisms created in the MPLS data plane that allow the OAM packets to run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group documents), which are referenced by this document. This document is not an Internet Standards Track specification; it is published for informational purposes. Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years, various OAM tools have been defined for various layers in the protocol stack. This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), pseudowires, and Transparent Interconnection of Lots of Links (TRILL). This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document. The target audience of this document includes network equipment vendors, network operators, and standards development organizations. This document can be used as an index to some of the main OAM tools defined in the IETF. At the end of the document, a list of the OAM toolsets and a list of the OAM functions are presented as a summary. This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults. This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122. In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for IOAM. IOAM-Data-Fields can be encapsulated into a variety of protocols, such as Network Service Header (NSH), Segment Routing, Generic Network Virtualization Encapsulation (Geneve), or IPv6. IOAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets. Network telemetry is a technology for gaining network insight and facilitating efficient and automated network management. It encompasses various techniques for remote data generation, collection, correlation, and consumption. This document describes an architectural framework for network telemetry, motivated by challenges that are encountered as part of the operation of networks and by the requirements that ensue. This document clarifies the terminology and classifies the modules and components of a network telemetry system from different perspectives. The framework and taxonomy help to set a common ground for the collection of related work and provide guidance for related technique and standard developments. This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic. This technology can be applied in various situations and for different protocols. According to the classification defined in RFC 7799, it could be considered Passive or Hybrid depending on the application. This document obsoletes RFC 8321. 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 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 (SLO), such as packet delay, delay variation, and packet-loss ratio, assigned to each DetNet flow.

Examples of the Use of the Term "In-Band" This appendix provides a few examples of the use of the term "in-band". These are intended to highlight the varying interpretations of the term across different contexts, which led to the guidelines in this document. In-Data-Packet OAM was in some cases referred to as "in-band". Initially, "In situ OAM" was also referred to as "In-band OAM", but was renamed due to the overloaded meaning of "In-band OAM". Further, also intertwines the terms "in-band" with "in situ". Other similar documents, including , still use variations of "in-band", "in band", or "inband". Path-Congruent OAM was sometimes referred to as "in-band". As described in , "The VCCV message travels in-band with the Session and follows the exact same path as the user data for the session". The term "in-band" is also used in with the same meaning. Non-Path-Congruent OAM was referred to in as "Out-of-Band". The property of "Equal-Forwarding-Treatment" is referred to in as "In-band OAM". Similarly, the property of "Different-Forwarding-Treatment OAM" can be found in the following definition in : "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."

Acknowledgements 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 mail thread include, alphabetically: , , , , , , , , , , , , , and . The authors wish to thank, chronologically, , , , , , , , , , , , , , , , , , , , , , , , , , , , and for their thorough review and useful feedback comments that greatly improved this document.

Authors' Addresses Blue Fern Consulting

United States of America / Spain carlos@bluefern.consulting

Old Dog Consulting

United Kingdom adrian@olddog.co.uk

Huawei

Matam Haifa 3190501 Israel tal.mizrahi.phd@gmail.com