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.¶
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.¶
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.¶
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is
at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 16 November 2025.¶
Copyright (c) 2025 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.¶
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] provided 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 lays out guidelines for
their use in future IETF work to achieve consistent and unambiguous
characterization.¶
This document updates [RFC6291] by adding to the guidelines for the
use of the term "OAM". It does not modify any other part of [RFC6291].¶
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 can be carried within or outside. A frequently encountered case is the use of "in-band" to mean either in-packet or on-path.¶
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.¶
The guidance in this document is to avoid the terms "in-band" and "out-of-band" when refering to OAM, and instead find finer-granularity descriptive terms.
Alternative terms and definitions are presented in this document for future use in IETF documents that refer to OAM.¶
The OAM information follows the exact same path as the observed data traffic. This was sometimes referred to as "in-band".¶
Non-Path-Congruent OAM:
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".¶
An example of "Path-Congruent OAM" is the Virtual
Circuit Connectivity Verification (VCCV), described
is Section 6 of [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 [RFC5085] refers to using the same path as the user data.
This term is also used in Section 2 of [RFC6669] with the same meaning,
and the word "congruent" is mentioned as synonymous.¶
Active, Passive, Hybrid, and In-Packet OAM
[RFC7799] provides clear definitions for active and passive
performance assessment such that the construction of metrics and
methods can be described as either "Active" or "Passive". Even
though [RFC7799] does not include the specific terms "Active",
"Passive", or "Hybrid" as modifiers of "OAM", the following terms
are used in many RFCs and are provided here for clarity.¶
Depends solely on the observation of one
or more existing data packet streams and does not use dedicated OAM packets.¶
Hybrid OAM:
Uses instrumentation or modification of the data
stream. Examples of protocols classified as "Hybrid OAM"
include [RFC9341], [RFC9197], and [RFC6374]. Hybrid
OAM can be implemented by piggybacking OAM-related information onto data
packets, as described in [RFC9197], or by utilizing reserved
fields in the packet header or specific values of existing header fields,
as proposed in [RFC9341]. Direct loss measurment [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.¶
This document defines the term In-Packet OAM, which is a special case of Hybrid OAM:¶
In-Packet OAM:
The OAM information is carried in the packets that also carry the data traffic. This was sometimes referred to as "in-band".¶
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".¶
In situ OAM [RFC9197] is an example of "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.' On the other hand, direct loss measurement [RFC6374]
is an example of "Hybrid OAM" which is not classified as "In-Packet OAM".¶
Initially, "In situ OAM" [RFC9197] was also referred to as "In-band OAM" [I-D.brockners-inband-oam-data], but was renamed due to the overloaded meaning of "In-band OAM". Further, [RFC9232] also intertwines the terms "in-band" with "in situ", though [I-D.song-opsawg-ifit-framework] settled on using "in Situ". Other similar uses, including [P4-INT-2.1] and [I-D.kumar-ippm-ifa], still use variations of "in-band", "in band", or "inband".¶
Packet Forwarding Treatment OAM:
OAM in relation to the forwarding treatment of user data packets, as for example QoS treatment.¶
Equal-Forwarding-Treatment OAM:
The OAM packets receive the same forwarding (e.g., QoS) treatment as user data packets. This was sometimes referred to as "in-band".¶
Different-Forwarding-Treatment OAM:
The OAM packets receive different forwarding (e.g., QoS) treatment as user data packets. This was sometimes referred to as "out-of-band".¶
As an example, the behavior of "Equal-Forwarding-Treatment OAM" is described in [RFC9551] as "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 [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."
[I-D.ietf-raw-architecture] uses similar text.¶
Note that OAM can be classified in relation to multiple criteria, e.g., relating to both topological congruence and packet treatment, as well as other criteria, such as active, passive or hybrid [RFC7799].
For example, [RFC9551] classifies OAM both in terms of whether it is active or passive as well as in terms of whether it receives the same treatment as the user traffic.¶
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 [RFC5085] and [RFC9551]. While the context in each of these documents is clear, the term carries different meanings in each case.¶
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.¶
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.¶
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, and Roni Even for their thorough review and useful feedback comments that greatly improved this document.¶
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, , <https://www.rfc-editor.org/info/rfc6291>.
Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, DOI 10.17487/RFC4733, , <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, , <https://www.rfc-editor.org/info/rfc5085>.
[RFC6374]
Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, , <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, , <https://www.rfc-editor.org/info/rfc6669>.
[RFC7799]
Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, , <https://www.rfc-editor.org/info/rfc7799>.
[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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc9551>.