Internet-Draft Characterizing OAM July 2024
Pignataro & Farrel Expires 30 January 2025 [Page]
Workgroup:
OPS Area Working Group
Internet-Draft:
draft-ietf-opsawg-oam-characterization-02
Updates:
6291 (if approved)
Published:
Intended Status:
Best Current Practice
Expires:
Authors:
C. Pignataro
NC State University
A. Farrel
Old Dog Consulting

Guidelines for Charactering "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 acronym. 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 acronym 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".

Status of This Memo

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 30 January 2025.

Table of Contents

1. Introduction

It is not uncommon for historical and popular terms to have fundamental nuances in how they are interpreted or understood. This was, for example, the case with the acronym 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, 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 acronym, and lays out guidelines for their use in future IETF work to achieve unambiguous characterization.

Additionally, this document recommends avoiding the creation and use of extended acronyms 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".

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].

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 said something", a challenge is presented for IP communications and packet switch networks (PSNs) which do not have a "band" per se, and, in fact, has multiple "somethings" that OAM can go within or outside. A frequently encountered case is the use of in-band to mean either in-packet or in-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 lack ability to 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 "*-band" 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.

Path:
OAM in relation to a path.
Path-Congruent 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 same path as the observed data traffic. This was sometimes referred to as "out-of-band".
[RFC6669] gives an example of "Path-Congruent OAM", and further describes that the OAM Packets "share their fate with data packets."
Packet:
OAM in relation to a user data packet.
Dedicated-Packet OAM:

The OAM information is carried in its own OAM packets, separate from data traffic. This was sometimes referred to as "out-of-band".
In-Packet OAM:

The OAM information is carried as part of data traffic. This was sometimes referred to as "in-band".
The MPLS echo request/reply messages [RFC8029] are an example of "Dedicated-Packet OAM", since they are described as "An MPLS echo request/reply is a (possibly 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.'
Initially, "in situ OAM" [IETF96-In-Band-OAM] 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", 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".
It is noteworthy that an In-Packet OAM cannot be Non-Path-Congruent OAM.
Packet Treatment:
OAM in relation to the treatment of user data packets, as for example QoS treatment.
Equal-QoS-Treatment OAM:

The OAM packets receive the same QoS treatment as user data packets. This was sometimes referred to as "in-band".
Different-QoS-Treatment OAM:

The OAM packets receive different QoS treatment as user data packets. This was sometimes referred to as "out-of-band".
For a case of either "Non-Path-Congruent OAM" or "Different-QoS-Treatment OAM", [I-D.ietf-detnet-oam-framework] says "Out-of-band OAM is an active OAM whose path through the DetNet domain is not topologically identical to the path of the monitored DetNet flow, or its test packets receive different QoS and/or PREOF treatment, or both." [I-D.ietf-raw-architecture] uses similar text.
Combined:
OAM in relation to multiple criteria. For example, in relation to both topological congruence and packet treatment. Examples include [I-D.ietf-detnet-oam-framework] and [I-D.ietf-raw-architecture].

[I-D.ietf-detnet-oam-framework] uses Combined OAM when it says "In-band OAM is an active OAM that is in-band within the monitored DetNet OAM domain when 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". [I-D.ietf-raw-architecture] uses similar text.

2.1. Historical Uses

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, the term "band" refers to the "Pseudowire data".

3. Active, Passive, Hybrid, and Compound 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 use in all future IETF documents that refer to OAM.

Active OAM:

Depends on dedicated instrumented OAM packets.
Passive OAM:

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 data packets themselves. [RFC9341] and [RFC9197] are examples labeled "Hybrid OAM" under this definition.
Compound 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 OAM packet). Note that [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 combination.

Compound OAM can further be characterized in a more explicit way, for nuanced use-cases.

  • Active-Passive OAM.

  • Active-Hybrid OAM.

  • Hybrid-Passive OAM.

  • Active-Hybrid-Passive OAM.

[RFC7799] adds to the confusion by describing "passive methods" as "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.

4. Extended OAM Acronyms

This document recommends avoiding the creation and use of extended acronyms 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 acronym "IOAM" for In situ Operations, Administration, and Maintenance (IOAM). While this document does not obsolete that acronym, it still recommends that the expanded "in situ OAM" is used instead to avoid potential ambiguity.

5. Node Processing OAM Packets

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:

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.

6. Security Considerations

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

7. IANA Considerations

This document has no IANA actions.

8. 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 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, and Henk Birkholz for their thorough review, supportive feedback, and useful comments that greatly improved this document.

9. References

9.1. Normative References

[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, , <https://www.rfc-editor.org/info/rfc6291>.

9.2. Informative References

[I-D.ietf-detnet-oam-framework]
Mirsky, G., Theoleyre, F., Papadopoulos, G. Z., Bernardos, C. J., Varga, B., and J. Farkas, "Framework of Operations, Administration and Maintenance (OAM) for Deterministic Networking (DetNet)", Work in Progress, Internet-Draft, draft-ietf-detnet-oam-framework-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-oam-framework-11>.
[I-D.ietf-raw-architecture]
Thubert, P., "Reliable and Available Wireless Architecture", Work in Progress, Internet-Draft, draft-ietf-raw-architecture-18, , <https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture-18>.
[I-D.kumar-ippm-ifa]
Kumar, J., Anubolu, S., Lemon, J., Manur, R., Holbrook, H., Ghanwani, A., Cai, D., Ou, H., Li, Y., and X. Wang, "Inband Flow Analyzer", Work in Progress, Internet-Draft, draft-kumar-ippm-ifa-08, , <https://datatracker.ietf.org/doc/html/draft-kumar-ippm-ifa-08>.
[I-D.song-opsawg-ifit-framework]
Song, H., Qin, F., Chen, H., Jin, J., and J. Shin, "Framework for In-situ Flow Information Telemetry", Work in Progress, Internet-Draft, draft-song-opsawg-ifit-framework-21, , <https://datatracker.ietf.org/doc/html/draft-song-opsawg-ifit-framework-21>.
[IETF96-In-Band-OAM]
Brockners, F., Bhandari, S., Dara, S., Pignataro, C., Gedler, H., Youell, S., and J. Leddy, "IETF 96, OPSWG: In-Band OAM", IETF-96 Proceedings, IETF-96 slides-96-opsawg-8.pdf, , <https://www.ietf.org/proceedings/96/slides/slides-96-opsawg-8.pdf>.
[P4-INT-2.1]
"In-band Network Telemetry (INT) Dataplane Specification, Version 2.1", , <https://p4.org/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, , <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>.
[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>.
[RFC9322]
Mizrahi, T., Brockners, F., Bhandari, S., Gafni, B., and M. Spiegel, "In Situ Operations, Administration, and Maintenance (IOAM) Loopback and Active Flags", RFC 9322, DOI 10.17487/RFC9322, , <https://www.rfc-editor.org/info/rfc9322>.
[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>.

Authors' Addresses

Carlos Pignataro
North Carolina State University
United States of America
Adrian Farrel
Old Dog Consulting
United Kingdom