<- RFC Index (10001..10100)
(also BCP 161)
Updates RFC 6291
Internet Engineering Task Force (IETF) C. Pignataro
Request for Comments: 10014 Blue Fern Consulting
BCP: 161 A. Farrel
Updates: 6291 Old Dog Consulting
Category: Best Current Practice T. Mizrahi
ISSN: 2070-1721 Huawei
June 2026
Guidelines for Characterizing the Term "OAM"
Abstract
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
https://www.rfc-editor.org/info/rfc10014.
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
(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 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 [RFC6291] 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" (Section 2). 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 (Section 3).
This document focuses on qualifiers for the term "OAM", not 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
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, the terms "in-band" and "out-of-band" were used
extensively in radio communications as well as in telephony signaling
[RFC4733]. 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) [RFC5085] and OAM for
Deterministic Networking (DetNet) [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 other documents are described in Appendix A.
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 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 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 (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] 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
[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 [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,
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 [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 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 [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
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 (Section 5.1.1 of [RFC5085]),
which was also referred to as "In-Band VCCV". The term "congruent"
also appears in Section 2 of [RFC6669] in the context of path
sharing.
3.4. 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 [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, fault detection, and fault
mitigation.
An example of "Equal-Forwarding-Treatment OAM" is presented in
[RFC9551] 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 [RFC9551] as "In-band
OAM".)
3.5. 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 [RFC9197] is incorporated in 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 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) (Section 3 of [RFC6374]) 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) [RFC5880] 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.
3.6. 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. [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. 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
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
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 is improved when terms are used with precision, and their
definitions are unambiguous.
5. IANA Considerations
This document has no IANA actions.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/info/rfc6291>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
6.2. Informative References
[P4-INT-2.1]
The P4.org Applications Working Group, "In-band Network
Telemetry (INT) Dataplane Specification", Version 2.1, 11
November 2020, <https://p4.org/wp-
content/uploads/sites/53/p4-spec/docs/INT_v2_1.pdf>.
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals", RFC 4733,
DOI 10.17487/RFC4733, December 2006,
<https://www.rfc-editor.org/info/rfc4733>.
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
Circuit Connectivity Verification (VCCV): A Control
Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
December 2007, <https://www.rfc-editor.org/info/rfc5085>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011,
<https://www.rfc-editor.org/info/rfc6374>.
[RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations,
Administration, and Maintenance (OAM) Toolset for MPLS-
Based Transport Networks", RFC 6669, DOI 10.17487/RFC6669,
July 2012, <https://www.rfc-editor.org/info/rfc6669>.
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014,
<https://www.rfc-editor.org/info/rfc7276>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
Ed., "Data Fields for In Situ Operations, Administration,
and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
May 2022, <https://www.rfc-editor.org/info/rfc9197>.
[RFC9232] Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and
A. Wang, "Network Telemetry Framework", RFC 9232,
DOI 10.17487/RFC9232, May 2022,
<https://www.rfc-editor.org/info/rfc9232>.
[RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
and T. Zhou, "Alternate-Marking Method", RFC 9341,
DOI 10.17487/RFC9341, December 2022,
<https://www.rfc-editor.org/info/rfc9341>.
[RFC9551] Mirsky, G., Theoleyre, F., Papadopoulos, G., Bernardos,
CJ., Varga, B., and J. Farkas, "Framework of Operations,
Administration, and Maintenance (OAM) for Deterministic
Networking (DetNet)", RFC 9551, DOI 10.17487/RFC9551,
March 2024, <https://www.rfc-editor.org/info/rfc9551>.
Appendix A. 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" [RFC9197] was also referred to as "In-band
OAM", but was renamed due to the overloaded meaning of "In-band OAM".
Further, [RFC9232] also intertwines the terms "in-band" with "in
situ". Other similar documents, including [P4-INT-2.1], still use
variations of "in-band", "in band", or "inband".
Path-Congruent OAM was sometimes referred to as "in-band". As
described in [RFC5085], "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 Section 2 of [RFC6669]
with the same meaning. Non-Path-Congruent OAM was referred to in
[RFC5085] as "Out-of-Band".
The property of "Equal-Forwarding-Treatment" is referred to in
[RFC9551] as "In-band OAM". Similarly, the property of "Different-
Forwarding-Treatment OAM" can be found in the following definition in
[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
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: 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 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, 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 for their
thorough review and useful feedback comments that greatly improved
this document.
Authors' Addresses
Carlos Pignataro
Blue Fern Consulting
United States of America / Spain
Email: carlos@bluefern.consulting
Adrian Farrel
Old Dog Consulting
United Kingdom
Email: adrian@olddog.co.uk
Tal Mizrahi
Huawei
Matam
Haifa 3190501
Israel
Email: tal.mizrahi.phd@gmail.com