| Internet-Draft | Characterizing OAM | November 2024 |
| Pignataro & Farrel | Expires 15 May 2025 | [Page] |
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 15 May 2025.¶
Copyright (c) 2024 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.¶
Additionally, this document recommends avoiding the creation and use of extended abbreviation for the qualifiers of "OAM". For example, the first "O" in "OOAM" could mean out-of-band, overlay, or something else.¶
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].¶
Note that [RFC7799] defines terms for active and passive performance assessments through metrics and methods. That RFC does not substantially discuss OAM, and although the concepts are similar, this document does not modify the definitions in [RFC7799].¶
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 switch 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 redefinitions of these terms cannot be generalized and can be confused by participants from other contexts. 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. The definitions presented in this document are for use in all future IETF documents that refer to OAM, and the terms "in-band OAM" and "out-of-band OAM" are not to be used in future documents.¶
There are many examples of "in-band OAM" and "out-of-band OAM" in published RFCs. While interpreting those, 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.¶
For example, [RFC5085] says "as in-band traffic with the PW's data, or out-of-band", and "in-band (i.e., following the same data-plane faith as PW data)". Hence, in that specific case, the term "band" refers to the "Pseudowire data".¶
[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 use in all future IETF documents that refer to OAM.¶
Uses a combination of at least two of Active OAM, Passive OAM, and Hybrid OAM (i.e., a combination of atomic OAM packets, data packet modification for OAM, and no explicit OAM). Note that
Section 3.7 of [RFC7799] also uses the term "Hybrid" to refer to metric types
in-between active and passive, for OAM there are no in-betweens per se,
only active, passive, hybrid, or a compound combination.
Compound OAM can be characterized in a more explicit way, for
nuanced use-cases, and named according to the OAM types that
are combined:¶
When two or more OAM types are combined, it is simply the case
that both OAM types are used at once. For example, in Active-Passive
OAM both specific OAM packets and the observation of data packets
may be used to provide information about the data flow in the network.
Each component may supplement the total data.¶
Note that [RFC7799] describes "passive methods" as "out of band" which is contrary to the concept of "Passive OAM" as defined here because there are no OAM packets to be in-band or out-of-band. Following the guidelines of this document, OAM may be qualified according to the terms described in Sections 2 and 3 of this document, and the term "out of band OAM" is not to be used in future documents.¶
This document recommends avoiding the creation and use of extended abbreviations for the qualifiers of "OAM". For example, the first "O" in "OOAM" could mean out-of-band, overlay, or something else.¶
[RFC9197] and other dependent documents currently uses the abbreviations "IOAM" for In situ Operations, Administration, and Maintenance (IOAM). While this document does not obsolete that abbreviation, it still recommends that the expanded "in situ OAM" is used instead to avoid potential ambiguity.¶
There are multiple processing capabilities that nodes processing OAM packets can utilize. Some of those capabilities are explained in [RFC9197] for in situ OAM and are further generalized in this document.¶
Depending on the Type of OAM processing, nodes are categorized as follows. Please note that this characterization exists within the context of a particular OAM protocol instance, and a given node can support multiple types.¶
Hybrid OAM instruments or modifies data packet themselves. Consequently:¶
Active OAM uses dedicated OAM packets, separate from data packets. Consequently:¶
A node could be an OAM Source Node and an OAM Sink Node for Active OAM packets simultaneously.¶
In some use-cases, such as in situ OAM described in [RFC9322], Compound OAM is used. In the forward direction, Hybrid OAM is used with a single Encapsulating Node. Multiple Transit Nodes may process the OAM information, and this may trigger them to act as OAM Source Nodes for Active OAM sent back to the Encapsulating Node which serves as an OAM Sink Node.¶
Security is improved when terms are used with precision, and their definitions are unambiguous.¶
This document has no IANA actions.¶
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.¶