[要約] RFC 10014は、OAMを修飾する用語が分野や文脈によって異なる意味を持つ問題を整理し、曖昧な「インバンド」「アウトオブバンド」の使用を避けるよう推奨します。代わりに、能動・受動・ハイブリッド、経路一致、パケット転送処理との関係など、意図する性質を明示する分類と記述指針を示します。
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
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.
IETF がさまざまな運用、管理、保守 (OAM) プロトコルとテクノロジーの作成と標準化を続けるにつれて、OAM の略語の前にさまざまな修飾子や修飾子が追加されます。一見すると、最もよく使用される修飾子はよく理解されているように見えますが、同じ修飾子でもコンテキストが異なれば解釈が異なる場合があります。その好例は、「インバンド」と「アウトオブバンド」という修飾語です。これらは、無線用語集に起源があり、他の通信ネットワークにも当てはめられています。このドキュメントでは、OAM に言及する場合、これら 2 つの用語を使用しないことをお勧めします。
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.
この文書では、パケット ネットワークのコンテキスト内で OAM 略語の前に追加されるいくつかの一般的な修飾子と修飾子を考慮し、IETF 文書でのそれらの使用に関するガイドラインを示します。
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.
この文書は、修飾子付きの「OAM」という用語の使用に関するガイドラインを追加することにより、RFC 6291 を拡張します。RFC 6291 のいかなる部分も変更しません。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。BCP の詳細については、RFC 7841 のセクション 2 を参照してください。
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.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10014 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。この文書から抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
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
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.
歴史的用語や一般的な用語には、その解釈や理解の仕方にニュアンスがあることは珍しくありません。これは、例えば、Operations、Administration、およびMaintenanceの略語である「OAM」の場合であり、[RFC6291]はその使用に関するガイドラインとその構成部分の定義を提供しています。
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).
パケットネットワーク内の「OAM」の特徴付けや修飾語は、「帯域内」や「帯域外」という形容詞句など、同様の解釈の問題に遭遇することがよくあります (セクション 2)。この文書では、OAM 略語の前に付加されるいくつかの一般的な修飾子と修飾子を考慮し、一貫性と明確な特徴付けを達成するために将来の IETF 作業でそれらを使用するためのガイドラインを示します (セクション 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].
このドキュメントでは、「OAM」または「OAM プロトコル」の定義ではなく、「OAM」という用語の修飾子に焦点を当てます。OAM スコープの概要については、[RFC6291] を参照してください。この文書はその範囲を拡張または制限するものではありません。「OAM プロトコル」という用語は、[RFC7276] のセクション 2.2.3 で定義されている測定または診断 OAM 機能を実装するために使用されるプロトコルを指します。
While this document introduces new terminology, it does not update or change the meaning of terminology found in existing RFCs.
この文書は新しい用語を導入していますが、既存の RFC にある用語の意味を更新または変更するものではありません。
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.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
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.
歴史的に、「インバンド」と「アウトオブバンド」という用語は、電話シグナリング [RFC4733] だけでなく無線通信でも広く使用されてきました。これらのどちらの場合も、実際の「帯域」(つまり、「チャネル」または「周波数」) が内部または外部に存在します。
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.
これらの用語は、その簡潔さゆえに便利であり、引き続き「何かの内部」と「何かの外部」を意味するために広く使用され続けていますが、IP 通信とパケット交換ネットワーク (PSN) には課題が提示されています。これらのネットワークには「帯域」自体がなく、実際には、OAM トラフィックを内部または外部で伝送できる複数の「何か」を持っています。よく遭遇するケースは、データパケット内またはパス上のいずれかを意味する「インバンド」の使用です。
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.
RFC には「帯域内 OAM」と「帯域外 OAM」の例が多数あります。たとえば、「インバンド」という用語は、Virtual Circuit Connectivity Verification (VCCV) [RFC5085] と OAM for Deterministic Networking (DetNet) [RFC9551] の両方に登場します。これらの各文書の文脈は明らかですが、この用語はそれぞれの場合で異なる意味を持ちます。これら 2 つの例と、他の文書での「インバンド」という用語の使用例については、付録 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.
一般に、IETF 内では、「帯域内」と「帯域外」という用語を一貫して明確に確実に理解することはできません。これらの用語のコンテキスト固有の定義には一貫性がないため、一般化することはできません。さらに重要なことは、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.
既存のドキュメントを解釈する際には、「バンド」という用語が何を指すのかを理解し、それらのドキュメントが更新された場合にはより明確にすることが重要です。この文書は、以前の RFC の用語の意味を変更するものではありません。
The applicability of the guidance in Section 3.1 is provided in Section 3.7.
セクション 3.1 のガイダンスの適用可能性については、セクション 3.7 に記載されています。
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.
このドキュメントでは、OAM に言及する場合、「インバンド」および「アウトオブバンド」という用語を避けることを推奨しています。代わりに、よりきめ細かく説明的な用語の使用を奨励します。この文書は、「-band」規約に依存しない他の正確で説明的な用語の使用を妨げることなく、OAM について議論する将来の IETF 文書 (この文書への参照を含む) で使用するための代替用語と定義も示しています。
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).
このセクションで説明する用語は、OAM を 3 つの基準に従って分類します。アクティブ モード、パッシブ モード、またはハイブリッド モード (セクション 3.2) で動作するかどうかです。データトラフィックと同じパスをたどるかどうか (セクション 3.3)。データ トラフィックと同じ扱いを受けるかどうか (セクション 3.4)。
[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].
[RFC7799] は、アクティブおよびパッシブのパフォーマンス評価の明確な定義を提供し、「アクティブ」または「パッシブ」のいずれかとして記述されるメトリクスおよびメソッドの構築を可能にします。[RFC7799] はこれらの用語を「OAM」の修飾語として明示的に使用していませんが、実際には広く使用されており、明確にするためにここに含めています。以下で説明する「アクティブ」、「パッシブ」、「ハイブリッド」という用語は [RFC7799] と一致しています。この文書は、[RFC7799] の条件を更新または変更するものではありません。
Active OAM:
アクティブな OAM:
Uses dedicated OAM packets.
専用の OAM パケットを使用します。
Passive OAM:
パッシブ 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.
1 つ以上の既存のデータ パケット ストリームの監視に依存し、専用の OAM パケットを使用せず、データ パケットを変更しません。
Hybrid OAM:
ハイブリッド 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.
アクティブ メソッドとパッシブ メソッドを組み合わせて使用します。これには、対象のストリームの拡張または変更が含まれる場合があります。[RFC7799] は、単一の対象ストリームを指すハイブリッド タイプ I と、2 つ以上の対象ストリームを指すハイブリッド タイプ II を区別しています。
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.
このドキュメントでは、「データパケット内 OAM」という用語を、ハイブリッド OAM のより広範なカテゴリ内の、より具体的で狭い範囲のインスタンスとして定義します。ハイブリッド OAM の広範なカテゴリには、可能な OAM メソッドの多様なセットが含まれるため、この新しい用語により、OAM メカニズムをより詳細に分類できるようになります。
In-Data-Packet OAM:
データパケット内 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".
OAM 関連の情報は、データ トラフィックも伝送するパケットで伝送されます。これはハイブリッド OAM の特殊なケースです。「インバンド」と呼ばれることもあります。
Note that In-Data-Packet OAM is a specific case of Hybrid Type I, as it is applied to a single stream of interest.
In-Data-Packet OAM は、対象となる単一のストリームに適用されるため、ハイブリッド タイプ I の特殊なケースであることに注意してください。
The following examples illustrate the terms Active, Passive, Hybrid, and In-Data-Packet OAM:
次の例は、アクティブ、パッシブ、ハイブリッド、およびデータパケット内 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".
* MPLS エコー要求/応答メッセージ [RFC8029] は、「MPLS エコー要求/応答は (おそらく MPLS ラベル付き) IPv4 または IPv6 UDP パケットである」と説明されているため、「アクティブ OAM」の一例です。
* Monitoring a packet stream by maintaining counters for the packets within the stream is an example of "Passive OAM".
* ストリーム内のパケットのカウンターを維持することによってパケット ストリームを監視することは、「パッシブ 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.'
* 「In-Data-Packet OAM」でもある「Hybrid Type I OAM」の例は、対象となる単一ストリームのデータ パケットに組み込まれる IOAM (In Situ OAM) [RFC9197] トレース オプションです。[RFC9197] によれば、IOAM は、パケットが特定のネットワーク ドメインを通過する間にパケット内に OAM 情報を記録します。「in situ」という用語は、OAM データが特に 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.
* 「データパケット内 OAM」でもある「ハイブリッド タイプ I OAM」の別の例は、単一ストリームのデータ パケットに適用される場合の代替マーキング [RFC9341] です。この場合、パケット ヘッダー内の少数のビットが、フロー内のパケットのサブセットをマークするために使用されます。
* 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.
* 「データパケット内 OAM」として分類されない「ハイブリッド タイプ I OAM」の例は、ユーザー パケットがプロトコルによって変更されない直接損失測定 [RFC6374] です。代わりに、OAM パケットは、観察されたネットワーク特性に関する情報、つまりパケット損失の計算を可能にするユーザー パケット カウンタ値を運ぶために使用されます。
* 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.
* 「In-Data-Packet OAM」ではない「Hybrid Type I OAM」のもう 1 つの例は、対象となる既存のストリームが (受動的に) 観察されている間に、パケット ストリームが (能動的に) 生成される場合です。この例は、ハイブリッド タイプ I メソッドとして [RFC7799] で導入されました。この例を拡張すると、アクティブ ストリームのパケットに IOAM トレース オプションが含まれる場合、この方法はより一般的な用語であるハイブリッド タイプ I によって特徴付けられます。
Path-Congruent OAM:
パス一致の OAM:
The OAM information follows the exact same forwarding path as the observed data traffic.
OAM 情報は、観測されたデータ トラフィックとまったく同じ転送パスに従います。
Non-Path-Congruent OAM:
パスが一致しない OAM:
The OAM information is not guaranteed to follow the exact same forwarding path as the observed data traffic.
OAM 情報は、観測されたデータ トラフィックとまったく同じ転送パスをたどるという保証はありません。
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.
「Path-Congruent OAM」の例は、Virtual Circuit Connectivity Verification (VCCV) Type 1 ([RFC5085] のセクション 5.1.1) であり、「In-Band VCCV」とも呼ばれます。「一致」という用語は、[RFC6669] のセクション 2 にもパス共有の文脈で登場します。
Equal-Forwarding-Treatment OAM:
同等の転送処理 OAM:
The OAM packets receive the same forwarding treatment (e.g., QoS) as user data packets.
OAM パケットは、ユーザー データ パケットと同じ転送処理 (QoS など) を受けます。
Different-Forwarding-Treatment OAM:
異なる転送処理 OAM:
The OAM packets might receive different forwarding treatment (e.g., QoS) than user data packets.
OAM パケットは、ユーザー データ パケットとは異なる転送処理 (QoS など) を受ける場合があります。
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.
Equal-Forwarding-Treatment OAM の動機は、OAM パケットが監視対象のユーザー データと同じネットワーク条件を経験するようにしたいという要望にあります。これには、同じトポロジ パスを通過するだけでなく、キューイング、スケジューリング、トラフィック シェーピングなどの同一のサービス品質 (QoS) 処理を受けることも含まれます。トポロジー処理と転送処理の両方の同等性が達成されると、OAM パケットはデータ トラフィックと運命共有 [RFC7276] を示すと言われます。運命共有により、ユーザー トラフィックに影響を与える障害や異常が OAM パケットの動作にも確実に反映されるため、OAM 観察の結果が運用上より意味のある、実用的なものになります。このような同等性がなければ、処理の不一致により、誤解を招く測定や診断、さらには不適切な修正措置につながる可能性があり、パフォーマンスの監視、障害検出、障害軽減のための OAM メカニズムの有用性が低下します。
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".)
「均等転送処理 OAM」の例は、Deterministic Networking (DetNet) OAM のコンテキストで [RFC9551] に示されています。「監視対象の DetNet フローと同じ QoS およびパケット複製、削除、および順序付け機能 (PREOF) 処理を受信する同じリンクとインターフェイスのセットを通過します」。(「Equal-Forwarding-Treatment」のプロパティは、[RFC9551] では「In-band OAM」と呼ばれています。)
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:
OAM プロトコルとツールは、前のセクションで説明した 3 つの基準に従って分類できます。ただし、すべての基準がすべての OAM プロトコルに適用できるわけではなく、すべての組み合わせが必ずしも可能であるとは限りません。例えば：
* 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.
* パッシブ OAM は既存のデータ トラフィックの監視のみに依存し、専用の OAM パケットは生成しません。したがって、測定ポイント間で専用の OAM パケットが交換されないため、パスの一致と転送処理の基準は関係ありません。
* Non-Path-Congruent OAM, by nature, cannot be Equal-Forwarding-Treatment.
* パス一致しない OAM は、本質的に、同等の転送処理を行うことができません。
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.
新しい OAM メカニズムを定義するとき、または既存のメカニズムを分析するときは、これらの基準のどれが適用できるかを明示的に検討し、それに応じてメカニズムを説明することをお勧めします。最初のステップとして、すべての OAM メカニズムは、最初の基準に従って、アクティブ、パッシブ、またはハイブリッド/データパケット内に分類できます。他の 2 つの基準に従ったさらなる分類は、ケースバイケースで検討する必要があります。
A few examples of OAM classification according to the three criteria are presented below:
3 つの基準に従った OAM 分類の例を以下にいくつか示します。
* 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.
* ICMP エコー メッセージを使用する IP Ping は、アクティブ OAM として分類できます。ユーザー データ パケットと同じパスをたどることや、同じ処理を受けることが保証されていないため、非パス一致として分類され、その結果、異なる転送処理として分類されます。
* 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.
* IOAM トレース オプション [RFC9197] がデータ パケットに組み込まれている場合、それは In-Data-Packet、Path-Congruent、および Equal-Forwarding-Treatment として分類できます。
* VCCV [RFC5085], as discussed above, is classified as Active, Path-Congruent, and Different-Forwarding-Treatment.
* VCCV [RFC5085] は、上で説明したように、アクティブ、パス一致、および異なる転送処理として分類されます。
* 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.
* MPLS Inferred Loss Measurement (ILM) ([RFC6374] のセクション 3) は、特別に生成されたテスト メッセージを使用するため、アクティブとして分類できます。また、パスが一致しており、同等または異なる転送処理 OAM として導入できます。MPLS 直接損失測定 (DLM) ([RFC6374] のセクション 3) は、ユーザー データ トラフィックをカウントするカウンタを伝送する OAM メッセージを使用します。したがって、これはハイブリッド タイプ I OAM として分類され、推定損失測定の場合と同様に、パスが一致しており、同等または異なる転送処理 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.
測定プロトコルでは、正確な結果はパス一致性と等価転送処理に依存します。対照的に、これらのプロパティは、他の OAM プロトコルでは必ずしも必要というわけではありません。たとえば、双方向転送検出 (BFD) [RFC5880] 制御パケットは、多くの場合、最高の優先順位で送信されます。これは、パケットが Equal-Forwarding-Treatment プロパティに準拠していないことを意味します。
This multidimensional classification enables a more precise and consistent understanding of OAM mechanisms.
この多次元分類により、OAM メカニズムをより正確かつ一貫して理解できるようになります。
This section summarizes the terminology.
このセクションでは用語を要約します。
Active OAM:
アクティブな OAM:
Uses dedicated OAM packets.
専用の OAM パケットを使用します。
Passive OAM:
パッシブ 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.
1 つ以上の既存のデータ パケット ストリームの監視に依存し、専用の OAM パケットを使用せず、データ パケットを変更しません。
Hybrid OAM:
ハイブリッド 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.
アクティブ メソッドとパッシブ メソッドを組み合わせて使用します。これには、対象のストリームの拡張または変更が含まれる場合があります。[RFC7799] は、単一の対象ストリームを指すハイブリッド タイプ I と、2 つ以上の対象ストリームを指すハイブリッド タイプ II を区別しています。
In-Data-Packet OAM:
データパケット内 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".
OAM 関連の情報は、データ トラフィックも伝送するパケットで伝送されます。これはハイブリッド OAM の特殊なケースです。「インバンド」と呼ばれることもあります。
Path-Congruent OAM:
パス一致の OAM:
The OAM information follows the exact same forwarding path as the observed data traffic.
OAM 情報は、観測されたデータ トラフィックとまったく同じ転送パスに従います。
Non-Path-Congruent OAM:
パスが一致しない OAM:
The OAM information is not guaranteed to follow the exact same forwarding path as the observed data traffic.
OAM 情報は、観測されたデータ トラフィックとまったく同じ転送パスをたどるという保証はありません。
Equal-Forwarding-Treatment OAM:
同等の転送処理 OAM:
The OAM packets receive the same forwarding treatment (e.g., QoS) as user data packets.
OAM パケットは、ユーザー データ パケットと同じ転送処理 (QoS など) を受けます。
Different-Forwarding-Treatment OAM:
異なる転送処理 OAM:
The OAM packets might receive different forwarding treatment (e.g., QoS) than user data packets.
OAM パケットは、ユーザー データ パケットとは異なる転送処理 (QoS など) を受ける場合があります。
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.
ここでの定義は、「OAM」という用語を修飾する IETF 文書で使用されるべきです (SHOULD)。この文書の用語の定義を超えて異なる特徴付けを明示的に作成することを希望する IETF 文書では、明確にするためにこの文書で定義されている用語と異なる場合に限り、そのような用語を導入できます。セクション 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>
Security is improved when terms are used with precision, and their definitions are unambiguous.
用語が正確に使用され、その定義が明確であれば、セキュリティは向上します。
This document has no IANA actions.
この文書には IANA のアクションはありません。
[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>.
[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>.
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".
In-Data-Packet OAM は、場合によっては「インバンド」と呼ばれていました。当初、「In situ OAM」[RFC9197] は「In-band OAM」とも呼ばれていましたが、「In-band OAM」の意味が重なりすぎたため、名前が変更されました。さらに、[RFC9232] では、「帯域内」という用語と「現場で」という用語も絡み合っています。[P4-INT-2.1] を含む他の同様の文書では、依然として「インバンド」、「インバンド」、または「インバンド」のバリエーションが使用されています。
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".
パス一致 OAM は、「帯域内」と呼ばれることもあります。[RFC5085] で説明されているように、「VCCV メッセージはセッションとともに帯域内を移動し、セッションのユーザー データとまったく同じパスをたどります」。「インバンド」という用語は、[RFC6669] のセクション 2 でも同じ意味で使用されています。非パス一致 OAM は、[RFC5085] では「アウトオブバンド」と呼ばれていました。
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."
「Equal-Forwarding-Treatment」のプロパティは、[RFC9551] では「In-band OAM」と呼ばれています。同様に、「Different-Forwarding-Treatment OAM」のプロパティは、[RFC9551] の次の定義にあります。「アウトオブバンド OAM: DetNet ドメインを通過するパスが、監視対象の DetNet フローのパスとトポロジ的に同一ではない可能性があるアクティブな OAM メソッド。そのテスト パケットは、異なる QoS および/または PREOF 処理、またはその両方を受ける可能性があります。」
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.
この文書の作成は、これらの用語の意味とその略語についてのメーリング リスト上の多くの議論の 1 つを観察したことがきっかけでした。このメール スレッドの参加者は、アルファベット順に、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、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.
著者は年代順に、ヘシャム・エルバコウリー、マイケル・リチャードソン、スチュワート・ブライアント、グレッグ・ミルスキー、メッド・ブーカデア、ロア・アンダーソン、トーマス・グラフ、アレックス・ファンフェン、シャオ・ミン、ドゥルヴ・ドーディ、ヘンク・バークホルツ、トム・ペッチ、ロニ・イーヴン、ティム・チョウン、マーカス・イーラー、メッド・ブーカデア、ブノワ・クレイズ、チョンフェン・シー、ロバートに感謝したい。Sparks、Kyle Rose、Mach Chen、Roman Danyliw、Gorry Fairhurst、Éric Vyncke、Andy Newton、Deb Cooley、Ketan Talaulikar、Gunter Van de Velde には、このドキュメントを大幅に改善するための徹底したレビューと有益なフィードバック コメントをいただきました。
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