RFC 10014

Guidelines for Characterizing the Term "OAM"

📅 published June 2026, from ietf

Guidelines for Characterizing the Term "OAM" 🎀

Okay bestie, the paperwork first 📋✨ This is RFC 10014, a Best Current Practice (that's BCP 161 if you're keeping score 💅). It's written by C. Pignataro from Blue Fern Consulting, A. Farrel from Old Dog Consulting, and T. Mizrahi from Huawei 🫶. It's an IETF document, dated June 2026, with ISSN 2070-1721. It Updates RFC 6291 🦋, and the header doesn't list anything it obsoletes 🙈.

Abstract 💖

As the IETF keeps producing and standardizing different Operations, Administration, and Maintenance (OAM) protocols and technologies, all kinds of qualifiers and modifiers get stuck onto the OAM abbreviation 🌸. At first glance the most popular ones seem totally clear, but the same qualifier can mean different things in different contexts 🤔. A perfect example is "in-band" and "out-of-band". Those come from the radio world and got borrowed into other communication networks, and this document recommends not using those two terms when referring to OAM 🚫.

This document looks at some common qualifiers and modifiers that get attached to the OAM abbreviation within packet networks, and it lays out guidelines for using them in IETF documents ✨.

This document extends RFC 6291 by adding guidelines for using 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 https://www.rfc-editor.org/info/rfc10014 🔗.

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 (https://trustee.ietf.org/license-info) 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 📚

   1.  Introduction
     1.1.  Requirements Language
   2.  In-Band and Out-of-Band OAM
   3.  Terminology and Guidance
     3.1.  Recommendation
     3.2.  Active, Passive, and Hybrid OAM
     3.3.  Path-Congruent OAM
     3.4.  Packet-Forwarding-Treatment OAM
     3.5.  Using Multiple Criteria
     3.6.  Summary of Terms
     3.7.  Applicability and Conformance Statement
   4.  Security Considerations
   5.  IANA Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Appendix A.  Examples of the Use of the Term "In-Band"
   Acknowledgements
   Authors' Addresses

1. Introduction ✨

It's not unusual for historical and popular terms to have nuances in how people interpret them 🧐. That's exactly what happened with the abbreviation "OAM" for Operations, Administration, and Maintenance, and [RFC6291] gives guidelines for using it along with definitions of its parts 💅.

Qualifiers for "OAM" within packet networks run into similar interpretation problems, like the adjective phrases "in-band" and "out-of-band" (Section 2) 😬. This document looks at some common qualifiers and modifiers that get prepended to the OAM abbreviation, and it lays out guidelines for using them in future IETF work so everyone gets consistent, unambiguous characterizations (Section 3) 🎯.

This document focuses on qualifiers for the term "OAM", not on the definition of "OAM" or "OAM protocols". Readers should refer to [RFC6291] 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 Section 2.2.3 of [RFC7276] 📏.

While this document introduces new terminology, it does not update or change the meaning of terminology found in existing RFCs 🫶.

1.1. Requirements Language

Okay, this bit is serious 🚨 but still cute. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🔑.

2. In-Band and Out-of-Band OAM 🫧

Historically, "in-band" and "out-of-band" were used a lot in radio communications and in telephony signaling [RFC4733] 📻. In both of those cases there's an actual "Band" (i.e., a "Channel" or "Frequency") to be within or outside of 📡.

Those terms were useful because they were simple, and people kept using them to mean "within something" and "outside something". But IP communications and packet-switched networks (PSNs) are a challenge 🌐. They don't have a "band" per se, and they actually have multiple "somethings" that OAM traffic can be carried within or outside of 🤯. A really common case is using "in-band" to mean either in-data-packet or on-path 🛣️.

There are lots of examples of "in-band OAM" and "out-of-band OAM" across RFCs 📚. For instance, the term "in-band" shows up in both Virtual Circuit Connectivity Verification (VCCV) [RFC5085] and OAM for Deterministic Networking (DetNet) [RFC9551]. The context in each document is clear, but the term means something different in each case 🙃. Those two examples, plus other uses of "in-band" in other documents, are described in Appendix A 👀.

Generally speaking, within the IETF, "in-band" and "out-of-band" cannot be reliably and consistently understood in an unambiguous way 💀. Context-specific definitions of these terms are inconsistent, so they can't be generalized 🙈. Even worse, the terms aren't self-defining, and someone seeing them for the first time can't understand them, since there's no "band" in IP 😭.

When you're interpreting existing documents, it's important to understand what the term "band" refers to, and to be more explicit if those documents get updated 🔍. This document does not change the meaning of any terms in any prior RFCs 💖.

The applicability of the guidance in Section 3.1 is provided in Section 3.7 📌.

3. Terminology and Guidance 🧭

3.1. Recommendation

This document recommends avoiding the terms "in-band" and "out-of-band" when referring to OAM 🚫. Instead, it encourages more fine-grained and descriptive terminology ✨. It also presents alternative terms and definitions for use in future IETF documents that discuss OAM (including a reference to this document), without ruling out other precise, descriptive terms that don't rely on the "-band" convention 🦋.

The terminology in this section sorts OAM by three criteria: whether it operates in an active, passive, or hybrid mode (Section 3.2); whether it follows the same path as data traffic (Section 3.3); and whether it receives the same treatment as data traffic (Section 3.4) 🎀.

3.2. Active, Passive, and Hybrid OAM 🌈

[RFC7799] gives clear definitions for active and passive performance assessment, so metrics and methods can be described as either "Active" or "Passive" 📊. [RFC7799] doesn't explicitly use these terms as modifiers of "OAM", but they're widely used in practice, so they're included here for clarity 💅. The terms "Active", "Passive" and "Hybrid", as described below, are consistent with [RFC7799]. This document does not update or change the terms of [RFC7799] 🫶.

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. [RFC7799] makes a distinction between Hybrid Type I, which refers to a single stream of interest, and Hybrid Type II, which refers to two or more streams of interest 🧩.

This document defines the term "In-Data-Packet OAM" as a more specific, narrowly scoped instance within the broader category of Hybrid OAM 🔬. This new term gives a more fine-grained way to classify OAM mechanisms, because 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, since it's applied to a single stream of interest 📝.

The following examples show what Active, Passive, Hybrid, and In-Data-Packet OAM look like in practice 🍓:

  • The MPLS echo request/reply messages [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" 📬.
  • 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) [RFC9197] trace option that is incorporated into data packets of a single stream of interest 🧚. According to [RFC9197], 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 [RFC9341], 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 [RFC6374], in which user packets are not modified by the protocol. Instead, OAM packets carry 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 [RFC7799] 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 🦋.

3.3. Path-Congruent OAM 🦋

okay so first up, Path-Congruent OAM: the OAM info takes the exact same forwarding path as the data traffic it's watching. bestie, that's the whole vibe 💅

Non-Path-Congruent OAM: the OAM info is not guaranteed to follow the exact same forwarding path as the observed data traffic. so no promises it's on the same route 🙈

in this doc, "path-congruent packets" means packets that follow the exact same path (aka they go through the same nodes and links) inside a network. ngl this definition doesn't cover how the packets get treated in queues inside the nodes on that path, so that's a whole different convo ✨

an example of "Path-Congruent OAM" is Virtual Circuit Connectivity Verification (VCCV) Type 1 (Section 5.1.1 of [RFC5085]), which was also called "In-Band VCCV" 🌸 the word "congruent" also pops up in Section 2 of [RFC6669], in the context of path sharing 💜

3.4. Packet-Forwarding-Treatment OAM 🎀

Equal-Forwarding-Treatment OAM: the OAM packets get the same forwarding treatment (like QoS) as user data packets. ✨

Different-Forwarding-Treatment OAM: the OAM packets might get different forwarding treatment (like QoS) than user data packets. 🌀

okay the reason Equal-Forwarding-Treatment is so iconic is that we want OAM packets to feel the exact same network conditions as the user data they're monitoring 🧚 that means not just the same topological path, but also identical QoS treatment, like queuing, scheduling, and traffic shaping. when both topological and forwarding-treatment equivalence are achieved, the OAM packets are said to exhibit fate-sharing [RFC7276] with the data traffic 🔥 fate-sharing means any impairments or anomalies hitting the user traffic also show up in how the OAM packets behave, so the OAM results are way more operationally meaningful and actionable 🙌

without that equivalence, the treatment can differ and lead to misleading measurements or diagnostics, and even inadequate corrective actions 😭 which means the OAM mechanism is way less useful for performance monitoring, fault detection, and fault mitigation.

an example of "Equal-Forwarding-Treatment OAM" is in [RFC9551], in the Deterministic Networking (DetNet) OAM context: "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". (that property of "Equal-Forwarding-Treatment" is called "In-band OAM" in [RFC9551] 🫶)

3.5. Using Multiple Criteria 💖

OAM protocols and tools can be sorted using the three criteria from the previous sections. but not every criterion fits every OAM protocol, and not every combo is necessarily possible. for example:

  • Passive OAM relies solely on observing existing data traffic and does not generate dedicated OAM packets. so path congruence and forwarding treatment aren't relevant here, because no dedicated OAM packets get exchanged between the measurement points 👀
  • Non-Path-Congruent OAM, by nature, cannot be Equal-Forwarding-Treatment. 🙅‍♀️

when you're 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 by the first criterion, as Active, Passive, or Hybrid/In-Data-Packet. further classification by the other two criteria should be considered on a case-by-case basis 🧩

a few examples of OAM classification by the three criteria, because examples are everything 🤍

  • IP Ping, which uses ICMP Echo messages, can be classified as Active OAM. since it's not guaranteed to follow the same path or receive the same treatment as user data packets, it's classified as Non-Path-Congruent and, consequently, as Different-Forwarding-Treatment 🏓
  • when an IOAM trace option [RFC9197] is tucked into data packets, it can be classified as In-Data-Packet, Path-Congruent, and Equal-Forwarding-Treatment 🍓
  • VCCV [RFC5085], as discussed above, is classified as Active, Path-Congruent, and Different-Forwarding-Treatment 🌸
  • MPLS Inferred Loss Measurement (ILM) (Section 3 of [RFC6374]) uses specially generated test messages, so it can be classified as Active. it's also Path-Congruent and can be deployed as either Equal- or Different-Forwarding-Treatment OAM 🧁
  • MPLS Direct Loss Measurement (DLM) (Section 3 of [RFC6374]) uses OAM messages that carry counters which count user data traffic. hence it's classified as Hybrid Type I OAM, and just like ILM, it's 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) [RFC5880] control packets are often sent with the highest priority, which means they don't adhere to the Equal-Forwarding-Treatment property 🏎️

this multidimensional classification gives us a more precise and consistent understanding of OAM mechanisms, and honestly that's so satisfying 🥹

3.6. Summary of Terms 🌷

this section is the recap, so here's the terminology in one place 📚

Active OAM: uses dedicated OAM packets. 📮

Passive OAM: relies on observing one or more existing data packet streams, 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. [RFC7799] 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, and 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. 🌀

3.7. Applicability and Conformance Statement 💅

okay so the definitions here SHOULD be used by IETF documents that qualify the term "OAM" 🫡 IETF documents that explicitly want to create different characterizations beyond the definitions in this document can introduce such terms, as long as they're different from the ones defined here, for clarity's sake. see also Section 3.1.

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>

4. Security Considerations 🔐

security gets a glow-up when terms are used with precision and their definitions are unambiguous 💎 no shade, just facts 🙌

5. IANA Considerations 🌈

this document has no IANA actions, so there's nothing to register here 🧚

6. References 📚

6.1. Normative References 💜

6.2. Informative References ✨

Okay bestie, here are the informative refs 📚🫶 They aren't strictly required to implement, but they're the background reading that makes everything click.

Appendix A. Examples of the Use of the Term "In-Band" 🎀

Okay, so this appendix is basically a receipts page 🧾 It shows how different docs use the word "in-band", and honestly it's giving chaos, which is exactly why the guidelines in this document exist. 💅

In-Data-Packet OAM was sometimes called "in-band". Then "In situ OAM" [RFC9197] was also called "In-band OAM" at first, but it got renamed because "In-band OAM" was already overloaded and meant too many things. 😭 [RFC9232] mixes "in-band" up with "in situ" too. Other docs, including [P4-INT-2.1], still use "in-band", "in band", or "inband". Iconic, right? 🙃

Path-Congruent OAM was sometimes called "in-band" as well. As [RFC5085] puts it, "The VCCV message travels in-band with the Session and follows the exact same path as the user data for the session". [RFC6669] uses "in-band" in Section 2 with the same meaning. Meanwhile, Non-Path-Congruent OAM was called "Out-of-Band" in [RFC5085]. 🦋

The property of "Equal-Forwarding-Treatment" is called "In-band OAM" in [RFC9551]. Then the property of "Different-Forwarding-Treatment OAM" shows up in this definition from [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." 🧚

Acknowledgements ✨

So this doc was born because the authors kept seeing the same mailing-list fight over what these terms mean and how to shorten them. 🙈 The people in that thread, listed alphabetically, were: 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. 🫶

The authors also want to thank, in chronological order, everyone who gave thorough reviews and useful feedback that made this document so much better: Hesham Elbakoury, Michael Richardson, Stewart Bryant, Greg Mirsky, Med Boucadair, Loa Andersson, Thomas Graf, Alex Huang-Feng, Xiao Min, Dhruv Dhody, Henk Birkholz, Tom Petch, Roni Even, Tim Chown, Marcus Ihlar, Med Boucadair, Benoit Claise, Chongfeng Xie, Robert Sparks, Kyle Rose, Mach Chen, Roman Danyliw, Gorry Fairhurst, Éric Vyncke, Andy Newton, Deb Cooley, Ketan Talaulikar, and Gunter Van de Velde. 👑🌈

Authors' Addresses 💌

Carlos Pignataro (they really did the reviewing marathon 💖)

Carlos Pignataro
Blue Fern Consulting
United States of America / Spain
Email: carlos@bluefern.consulting

Adrian Farrel

Adrian Farrel
Old Dog Consulting
United Kingdom
Email: adrian@olddog.co.uk

Tal Mizrahi

Tal Mizrahi
Huawei
Matam
Haifa 3190501
Israel
Email: tal.mizrahi.phd@gmail.com
📦 where this page comes from