[要約] RFC 9378 は、IOAMがネットワーク内のパス上でパケットを通過する際に運用情報とテレメトリ情報を収集するためのフレームワークを提供し、IOAMの展開に関する考慮事項とガイダンスを提供します。
Internet Engineering Task Force (IETF) F. Brockners, Ed.
Request for Comments: 9378 Cisco
Category: Informational S. Bhandari, Ed.
ISSN: 2070-1721 Thoughtspot
D. Bernier
Bell Canada
T. Mizrahi, Ed.
Huawei
April 2023
In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document provides a framework for IOAM deployment and provides IOAM deployment considerations and guidance.
in situ操作、管理、およびメンテナンス（IOAM）は、パケット内の動作およびテレメトリ情報を収集し、パケットはネットワーク内の2つのポイント間のパスを横断します。このドキュメントは、IOAM展開のフレームワークを提供し、IOAMの展開の考慮事項とガイダンスを提供します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。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/rfc9378.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9378で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions
3. IOAM Deployment: Domains and Nodes
4. Types of IOAM
4.1. Per-Hop Tracing IOAM
4.2. Proof of Transit IOAM
4.3. E2E IOAM
4.4. Direct Export IOAM
5. IOAM Encapsulations
5.1. IPv6
5.2. NSH
5.3. BIER
5.4. GRE
5.5. Geneve
5.6. Segment Routing
5.7. Segment Routing for IPv6
5.8. VXLAN-GPE
6. IOAM Data Export
7. IOAM Deployment Considerations
7.1. IOAM-Namespaces
7.2. IOAM Layering
7.3. IOAM Trace Option-Types
7.4. Traffic-Sets That IOAM Is Applied To
7.5. Loopback Flag
7.6. Active Flag
7.7. Brown Field Deployments: IOAM-Unaware Nodes
8. IOAM Manageability
9. IANA Considerations
10. Security Considerations
11. Informative References
Acknowledgements
Authors' Addresses
In situ Operations, Administration, and Maintenance (IOAM) collects 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. IOAM complements mechanisms such as Ping, Traceroute, or other active probing mechanisms. In terms of "active" or "passive" OAM, IOAM can be considered a hybrid OAM type. In situ mechanisms do not require extra packets to be sent. IOAM adds information to the already available data packets and, therefore, cannot be considered passive. In terms of the classification given in [RFC7799], IOAM could be portrayed as Hybrid Type I. IOAM mechanisms can be leveraged where mechanisms using, e.g., ICMP do not apply or do not offer the desired results. These situations could include:
現場操作、管理、およびメンテナンス（IOAM）は、パケットが特定のネットワークドメインを通過する間、パケット内でOAM情報を収集します。「in situ」という用語は、OAM専用のパケット内で送信されるのではなく、OAMデータがデータパケットに追加されるという事実を指します。IOAMは、Ping、Traceroute、またはその他のアクティブプロービングメカニズムなどのメカニズムを補完します。「アクティブ」または「パッシブ」OAMに関しては、IOAMはハイブリッドOAMタイプと見なすことができます。現場メカニズムでは、追加のパケットを送信する必要はありません。iOAMは、既に利用可能なデータパケットに情報を追加するため、受動的と見なすことはできません。[RFC7799]に与えられた分類に関しては、IOAMはハイブリッドタイプIとして描写できます。IOAMメカニズムは、たとえばICMPが適用されないか、望ましい結果を提供しない場合、IOAMメカニズムを活用できます。これらの状況には以下が含まれます。
* proving that a certain traffic flow takes a predefined path,
* 特定のトラフィックフローが事前に定義されたパスを取ることを証明する、
* verifying the Service Level Agreement (SLA) verification for the live data traffic,
* ライブデータトラフィックのサービスレベル契約（SLA）検証の検証、
* providing detailed statistics on traffic distribution paths in networks that distribute traffic across multiple paths, or
* 複数のパスにトラフィックを分配するネットワーク内のトラフィック配布パスに関する詳細な統計を提供する、または
* providing scenarios in which probe traffic is potentially handled differently from regular data traffic by the network devices.
* プローブトラフィックが、ネットワークデバイスによる通常のデータトラフィックとは異なる方法で処理される可能性があるシナリオを提供します。
Abbreviations used in this document:
このドキュメントで使用されている略語：
BIER:
ビア：
Bit Index Explicit Replication [RFC8279]
ビットインデックス明示的複製[RFC8279]
Geneve:
Geneve：
Generic Network Virtualization Encapsulation [RFC8926]
一般的なネットワーク仮想化カプセル化[RFC8926]
GRE:
GRE：
Generic Routing Encapsulation [RFC2784]
一般的なルーティングカプセル化[RFC2784]
IOAM:
ioam：
In situ Operations, Administration, and Maintenance
in situ操作、管理、およびメンテナンス
MTU:
MTU：
Maximum Transmission Unit
最大送信ユニット
NSH:
NSH：
Network Service Header [RFC8300]
ネットワークサービスヘッダー[RFC8300]
OAM:
OAM：
Operations, Administration, and Maintenance
運用、管理、およびメンテナンス
POT:
ポット：
Proof of Transit
輸送の証明
VXLAN-GPE:
vxlan-gpe：
Virtual eXtensible Local Area Network - Generic Protocol Extension [VXLAN-GPE]
仮想拡張可能なローカルエリアネットワーク - ジェネリックプロトコル拡張[VXLAN -GPE]
[RFC9197] defines the scope of IOAM as well as the different types of IOAM nodes. For improved readability, this section provides a brief overview of where IOAM applies, along with explaining the main roles of nodes that employ IOAM. Please refer to [RFC9197] for further details.
[RFC9197]は、IOAMの範囲と、さまざまなタイプのIOAMノードを定義します。読みやすさを改善するために、このセクションでは、iOAMが適用される場所の簡単な概要と、iOAMを使用するノードの主要な役割を説明します。詳細については、[RFC9197]を参照してください。
IOAM is focused on "limited domains", as defined in [RFC8799]. IOAM is not targeted for a deployment on the global Internet. The part of the network that employs IOAM is referred to as the "IOAM-Domain". For example, an IOAM-Domain can include an enterprise campus using physical connections between devices or an overlay network using virtual connections or tunnels for connectivity between said devices. An IOAM-Domain is defined by its perimeter or edge. The operator of an IOAM-Domain is expected to put provisions in place to ensure that packets that contain IOAM data fields do not leak beyond the edge of an IOAM-Domain, e.g., using packet filtering methods. The operator should consider the potential operational impact of IOAM on mechanisms such as ECMP load-balancing schemes (e.g., load-balancing schemes based on packet length could be impacted by the increased packet size due to IOAM), path MTU (i.e., ensure that the MTU of all links within a domain is sufficiently large enough to support the increased packet size due to IOAM), and ICMP message handling.
IOAMは、[RFC8799]で定義されているように、「限定ドメイン」に焦点を当てています。IOAMは、グローバルインターネット上の展開をターゲットにしていません。IOAMを採用するネットワークの一部は、「IOAMドメイン」と呼ばれます。たとえば、IOAMドメインには、デバイス間の物理的な接続を使用したエンタープライズキャンパスまたは、仮想接続またはトンネルを使用して上記のデバイス間の接続を使用してオーバーレイネットワークを使用することができます。IOAMドメインは、その境界またはエッジによって定義されます。IOAMドメインのオペレーターは、IOAMデータフィールドを含むパケットがIOAMドメインの端を越えて漏れないことを保証するために規定を導入することが期待されています。たとえば、パケットフィルタリング方法を使用します。オペレーターは、ECMP負荷バランススキームなどのメカニズムに対するIOAMの潜在的な運用上の影響を考慮する必要があります（たとえば、パケットの長さに基づく負荷分散スキームは、IOAMによるパケットサイズの増加によって影響を受ける可能性があります）。ドメイン内のすべてのリンクのMTUは、IOAMによるパケットサイズの増加をサポートするのに十分な大きさです）、およびICMPメッセージ処理。
An IOAM-Domain consists of "IOAM encapsulating nodes", "IOAM decapsulating nodes", and "IOAM transit nodes". The role of a node (i.e., encapsulating, transit, decapsulating) is defined within an IOAM-Namespace (see below). A node can have different roles in different IOAM-Namespaces.
IOAMドメインは、「ノードをカプセル化するIOAM」、「IOAM脱カプセンティングノード」、および「IOAMトランジットノード」で構成されています。ノードの役割（つまり、カプセル化、トランジット、脱カプセンティング）は、IOAM-Namespace内で定義されます（以下を参照）。ノードは、ioam-namespacesの異なる役割を異なる可能性があります。
An IOAM encapsulating node incorporates one or more IOAM Option-Types into packets that IOAM is enabled for. If IOAM is enabled for a selected subset of the traffic, the IOAM encapsulating node is responsible for applying the IOAM functionality to the selected subset.
IOAMカプセル化ノードには、IOAMが有効になっているパケットに1つ以上のIOAMオプションタイプが組み込まれています。トラフィックの選択されたサブセットに対してIOAMが有効になっている場合、IOAMカプセル化ノードは、選択したサブセットにIOAM機能を適用する責任があります。
An IOAM transit node updates one or more of the IOAM-Data-Fields. If both the Pre-allocated and the Incremental Trace Option-Types are present in the packet, each IOAM transit node will update at most one of these Option-Types. Note that in case both Trace Option-Types are present in a packet, it is up to the IOAM data processing systems (see Section 6) to integrate the data from the two Trace Option-Types to form a view of the entire journey of the packet. A transit node does not add new IOAM Option-Types to a packet and does not change the IOAM-Data-Fields of an IOAM Edge-to-Edge (E2E) Option-Type.
IOAMトランジットノードは、1つ以上のIOAM-DATAフィールドを更新します。パケットに事前に割り当てられたトレースオプションタイプの両方が存在する場合、各iOAMトランジットノードはこれらのオプションタイプのせいぜい1つで更新されます。両方のトレースオプションタイプがパケットに存在する場合、IOAMデータ処理システム（セクション6を参照）次第であり、2つのTRACEオプションタイプのデータを統合して、パケット。トランジットノードは、新しいiOAMオプションタイプをパケットに追加せず、IOAMエッジツーエッジ（E2E）オプションタイプのIOAM-DATAフィールドを変更しません。
An IOAM decapsulating node removes any IOAM Option-Types from packets.
IOAM脱カプセンティングノードは、パケットからIOAMオプションタイプを削除します。
The role of an IOAM encapsulating, IOAM transit, or IOAM decapsulating node is always performed within a specific IOAM-Namespace. This means that an IOAM node that is, e.g., an IOAM decapsulating node for IOAM-Namespace "A" but not for IOAM-Namespace "B" will only remove the IOAM Option-Types for IOAM-Namespace "A" from the packet. An IOAM decapsulating node situated at the edge of an IOAM-Domain removes all IOAM Option-Types and associated encapsulation headers for all IOAM-Namespaces from the packet.
IOAMのカプセル化、IOAMトランジット、またはIOAM脱カプセンティングノードの役割は、常に特定のIOAMネームズスペース内で実行されます。これは、IOAM-NamesSpace "A"のIOAM脱カプセンティングノード、つまりiOam-namespace "B"のIOAM脱カプセンシングノードであるIOAMノードは、IOAM-NamesSpace "a"のIOAMオプションタイプのみを削除することを意味します。IOAMドメインの端にあるIOAM脱カプセンティングノードは、パケットからすべてのiOAM-ネームススペースのすべてのIOAMオプションタイプと関連するカプセル化ヘッダーを削除します。
IOAM-Namespaces allow for a namespace-specific definition and interpretation of IOAM-Data-Fields. Please refer to Section 7.1 for a discussion of IOAM-Namespaces.
IOAM-NamesSpacesは、iOAM-data-fieldsの名前空間固有の定義と解釈を可能にします。IOAM-NamesSpacesの議論については、セクション7.1を参照してください。
Export of Export of Export of Export of
IOAM data IOAM data IOAM data IOAM data
(optional) (optional) (optional) (optional)
^ ^ ^ ^
| | | |
| | | |
User +---+----+ +---+----+ +---+----+ +---+----+
packets |Encapsu-| | Transit| | Transit| |Decapsu-|
-------->|lating |====>| Node |====>| Node |====>|lating |-->
|Node | | A | | B | |Node |
+--------+ +--------+ +--------+ +--------+
Figure 1: Roles of IOAM Nodes
図1：IOAMノードの役割
IOAM nodes that add or remove the IOAM-Data-Fields can also update the IOAM-Data-Fields at the same time. Or, in other words, IOAM encapsulating or decapsulating nodes can also serve as IOAM transit nodes at the same time. Note that not every node in an IOAM-Domain needs to be an IOAM transit node. For example, a deployment might require that packets traverse a set of firewalls that support IOAM. In that case, only the set of firewall nodes would be IOAM transit nodes rather than all nodes.
IOAM-Data-Fieldsを追加または削除するIOAMノードは、IOAM-Data-Fieldsを同時に更新することもできます。または、言い換えれば、IOAMはノードをカプセル化または脱カプセル化することも、同時にIOAMトランジットノードとして機能する可能性があります。IOAMドメイン内のすべてのノードは、IOAMトランジットノードである必要はないことに注意してください。たとえば、展開では、パケットがiOAMをサポートするファイアウォールのセットを横断する必要がある場合があります。その場合、ファイアウォールノードのセットのみが、すべてのノードではなくIOAMトランジットノードになります。
IOAM supports different modes of operation. These modes are differentiated by the type of IOAM data fields that are being carried in the packet, the data being collected, the type of nodes that collect or update data, and if and how nodes export IOAM information.
IOAMは、さまざまな動作モードをサポートしています。これらのモードは、パケットに携帯されているIOAMデータフィールドのタイプ、収集されるデータ、データを収集または更新するノードのタイプ、およびノードのIOAM情報をエクスポートするかどうかによって区別されます。
Per-hop tracing:
ホップストレース：
OAM information about each IOAM node a packet traverses is collected and stored within the user data packet as the packet progresses through the IOAM-Domain. Potential uses of IOAM per-hop tracing include:
各iOAMノードに関するOAM情報パケットトラバースが収集され、IOAMドメインを介してパケットが進むにつれてユーザーデータパケット内に保存されます。IOAMパーホップトレースの潜在的な用途には次のものがあります。
* Understanding the different paths that different packets traverse between an IOAM encapsulating node and an IOAM decapsulating node in a network that uses load balancing, such as Equal Cost Multi-Path (ECMP). This information could be used to tune the algorithm for ECMP for optimized network resource usage.
* 異なるパケットがIOAMをカプセル化するノードと、等しいコストマルチパス（ECMP）などのロードバランスを使用するネットワーク内のIOAMデカプシングノードとの間に横断するさまざまなパスを理解します。この情報は、最適化されたネットワークリソース使用量のためにECMPのアルゴリズムをチューニングするために使用できます。
* With regard to operations and troubleshooting, understanding which path a particular packet or set of packets take as well as what amount of jitter and delay different IOAM nodes in the path contribute to the overall delay and jitter between the IOAM encapsulating node and the IOAM decapsulating node.
* 操作とトラブルシューティングに関して、特定のパケットまたはパケットのセットがどのパスをとるか、パス内のさまざまなIOAMノードの量のジッターと遅延を理解することは、ノードをカプセル化するIOAMとIOAMデカプシュレーションのノードとの間の全体的な遅延とジッターに寄与します。
Proof of Transit:
輸送の証明：
Information that a verifier node can use to verify whether a packet has traversed all nodes that it is supposed to traverse is stored within the user data packet. For example, Proof of Transit could be used to verify that a packet indeed passes through all services of a service function chain (e.g., verify whether a packet indeed traversed the set of firewalls that it is expected to traverse) or whether a packet indeed took the expected path.
検証装置ノードが使用できる情報パケットが、トラバースを実行するはずのすべてのノードがユーザーデータパケット内に保存されているかどうかを確認します。たとえば、トランジットの証明を使用して、パケットが実際にサービス関数チェーンのすべてのサービスを通過することを確認できます（たとえば、パケットが実際に移動すると予想されるファイアウォールのセットを実際に通過したかどうかを確認します）、またはパケットが実際に取ったかどうかを確認できます。予想されるパス。
Edge-to-Edge (E2E):
エッジツーエッジ（E2E）：
OAM information that is specific to the edges of an IOAM-Domain is collected and stored within the user data packet. E2E OAM could be used to gather operational information about a particular network domain, such as the delay and jitter incurred by that network domain or the traffic matrix of the network domain.
IOAMドメインのエッジに固有のOAM情報は、ユーザーデータパケット内に収集され、保存されます。E2E OAMは、そのネットワークドメインまたはネットワークドメインのトラフィックマトリックスによって発生した遅延やジッターなど、特定のネットワークドメインに関する運用情報を収集するために使用できます。
Direct Export:
直接輸出：
OAM information about each IOAM node a packet traverses is collected and immediately exported to a collector. Direct Export could be used in situations where per-hop tracing information is desired, but gathering the information within the packet -- as with per-hop tracing -- is not feasible. Rather than automatically correlating the per-hop tracing information, as done with per-hop tracing, Direct Export requires a collector to correlate the information from the individual nodes. In addition, all nodes enabled for Direct Export need to be capable of exporting the IOAM information to the collector.
各iOAMノードに関するOAM情報パケットトラバースが収集され、すぐにコレクターにエクスポートされます。直接エクスポートは、ホップごとのトレース情報が必要な状況で使用できますが、パケット内の情報を収集することは、PERホップトレースと同様に、実行不可能です。HOPごとのトレース情報を自動的に相関させるのではなく、ホップごとのトレースで行うように、直接エクスポートには、個々のノードからの情報を相関させるためにコレクターが必要です。さらに、直接エクスポートのために有効になっているすべてのノードは、IOAM情報をコレクターにエクスポートできる必要があります。
"IOAM tracing data" is expected to be collected at every IOAM transit node that a packet traverses to ensure visibility into the entire path that a packet takes within an IOAM-Domain. In other words, in a typical deployment, all nodes in an IOAM-Domain would participate in IOAM and, thus, be IOAM transit nodes, IOAM encapsulating nodes, or IOAM decapsulating nodes. If not all nodes within a domain are IOAM capable, IOAM tracing information (i.e., node data, see below) will only be collected on those nodes that are IOAM capable. Nodes that are not IOAM capable will forward the packet without any changes to the IOAM-Data-Fields. The maximum number of hops and the minimum path MTU of the IOAM-Domain are assumed to be known.
「IOAMトレースデータ」は、パケットが横断するIOAMトランジットノードごとに収集され、IOAMドメイン内でパケットが取るパス全体への可視性を確保することが期待されています。言い換えれば、典型的な展開では、IOAMドメイン内のすべてのノードはiOAMに参加し、したがって、IOAMトランジットノード、ノードのカプセル化、またはIOAMの脱カプセル化ノードになります。ドメイン内のすべてのノードがIOAM能力ではない場合、IOAMトレース情報（つまり、ノードデータ、以下を参照）は、IOAM対応のノードでのみ収集されます。IOAMが使用できないノードは、IOAM-Data-Fieldsに変更なしでパケットを転送します。ホップの最大数とIOAMドメインの最小パスMTUは、わかっていると想定されています。
IOAM offers two different Trace Option-Types: the "Incremental" Trace Option-Type and the "Pre-allocated" Trace Option-Type. For a discussion about which of the two option types is the most suitable for an implementation and/or deployment, see Section 7.3.
IOAMは、2つの異なるトレースオプションタイプを提供します。「インクリメンタル」トレースオプションタイプと「事前に割り当てられた」トレースオプションタイプです。2つのオプションタイプのどれが実装および/または展開に最も適しているかについての議論については、セクション7.3を参照してください。
Every node data entry holds information for a particular IOAM transit node that is traversed by a packet. The IOAM decapsulating node removes any IOAM Option-Types and processes and/or exports the associated data. All IOAM-Data-Fields are defined in the context of an IOAM-Namespace.
すべてのノードデータ入力には、パケットによって移動される特定のIOAMトランジットノードの情報が保持されます。IOAM脱カプセンティングノードは、IOAMオプションタイプとプロセスを削除し、関連するデータをエクスポートします。すべてのIOAM-DATAフィールドは、IOAM-NamesSpaceのコンテキストで定義されます。
IOAM tracing can, for example, collect the following types of information:
IOAMトレースは、たとえば、次の種類の情報を収集できます。
* Identification of the IOAM node. An IOAM node identifier can match to a device identifier or a particular control point or subsystem within a device.
* IOAMノードの識別。IOAMノード識別子は、デバイス識別子またはデバイス内の特定の制御ポイントまたはサブシステムに一致させることができます。
* Identification of the interface that a packet was received on, i.e., ingress interface.
* パケットが受信されたインターフェイス、つまりイングレスインターフェイスの識別。
* Identification of the interface that a packet was sent out on, i.e., egress interface.
* パケットが送信されたインターフェイス、つまり出口インターフェイスの識別。
* Time of day when the packet was processed by the node as well as the transit delay. Different definitions of processing time are feasible and expected, though it is important that all devices of an IOAM-Domain follow the same definition.
* パケットがノードとトランジット遅延によって処理された時刻。処理時間のさまざまな定義が実現可能であり、期待されますが、ioamドメインのすべてのデバイスが同じ定義に従うことが重要です。
* Generic data, which is format-free information, where the syntax and semantics of the information are defined by the operator in a specific deployment. For a specific IOAM-Namespace, all IOAM nodes should interpret the generic data the same way. Examples for generic IOAM data include geolocation information (location of the node at the time the packet was processed), buffer queue fill level or cache fill level at the time the packet was processed, or even a battery charge level.
* 情報の構文とセマンティクスは、特定の展開でオペレーターによって定義される形式のない情報である一般的なデータ。特定のIOAM-NamesSpaceの場合、すべてのIOAMノードは一般的なデータを同じように解釈する必要があります。一般的なIOAMデータの例には、ジオロケーション情報（パケットが処理された時点でのノードの位置）、バッファキューの塗りつぶしレベルまたはパケットが処理された時点でのキャッシュ充填レベル、またはバッテリー充電レベルさえ含まれます。
* Information to detect whether IOAM trace data was added at every hop or whether certain hops in the domain weren't IOAM transit nodes.
* IOAMトレースデータがすべてのホップで追加されたかどうか、またはドメイン内の特定のホップがIOAMトランジットノードではなかったかどうかを検出するための情報。
* Data that relates to how the packet traversed a node (transit delay, buffer occupancy in case the packet was buffered, and queue depth in case the packet was queued).
* パケットがノードを通過する方法に関連するデータ（トランジット遅延、パケットがバッファリングされた場合のバッファー占有率、およびパケットがキューに掲載された場合のキューの深さ）。
The Incremental Trace Option-Type and Pre-allocated Trace Option-Type are defined in [RFC9197].
インクリメンタルトレースオプションタイプと事前に割り当てられたトレースオプションタイプは、[RFC9197]で定義されています。
The IOAM Proof of Transit Option-Type is to support path or service function chain [RFC7665] verification use cases. Proof of transit could use methods like nested hashing or nested encryption of the IOAM data.
IOAMのトランジットオプションタイプの証明は、パスまたはサービス機能チェーン[RFC7665]検証ユースケースをサポートすることです。トランジットの証明は、ネストされたハッシュまたはIOAMデータのネストされた暗号化などの方法を使用できます。
The IOAM Proof of Transit Option-Type consists of a fixed-size "IOAM Proof of Transit Option header" and "IOAM Proof of Transit Option data fields". For details, see [RFC9197].
IOAMのトランジットオプションタイプの証明は、固定サイズの「IOAM輸送オプションヘッダーの証明」および「TransitオプションデータフィールドのIOAM証明」で構成されています。詳細については、[RFC9197]を参照してください。
The IOAM E2E Option-Type is to carry the data that is added by the IOAM encapsulating node and interpreted by IOAM decapsulating node. The IOAM transit nodes may process the data but must not modify it.
IOAM E2Eオプションタイプは、IOAMカプセル化ノードによって追加され、IOAM脱カプセンティングノードによって解釈されるデータを携帯することです。IOAMトランジットノードは、データを処理する場合がありますが、変更してはなりません。
The IOAM E2E Option-Type consists of a fixed-size "IOAM Edge-to-Edge Option-Type header" and "IOAM Edge-to-Edge Option-Type data fields". For details, see [RFC9197].
IOAM E2Eオプションタイプは、固定サイズの「IOAMエッジツーエッジオプションタイプヘッダー」および「IOAMエッジツーエッジオプションタイプのデータフィールド」で構成されています。詳細については、[RFC9197]を参照してください。
Direct Export is an IOAM mode of operation within which IOAM data are to be directly exported to a collector rather than be collected within the data packets. The IOAM Direct Export Option-Type consists of a fixed-size "IOAM direct export option header". Direct Export for IOAM is defined in [RFC9326].
直接エクスポートは、IOAMデータをデータパケット内で収集するのではなく、IOAMデータをコレクターに直接エクスポートするIOAMモードです。IOAMダイレクトエクスポートオプションタイプは、固定サイズの「IOAMダイレクトエクスポートオプションヘッダー」で構成されています。IOAMの直接輸出は[RFC9326]で定義されています。
IOAM data fields and associated data types for IOAM are defined in [RFC9197]. The IOAM data field can be transported by a variety of transport protocols, including NSH, Segment Routing, Geneve, BIER, IPv6, etc.
IOAMデータフィールドとIOAMの関連データ型は、[RFC9197]で定義されています。IOAMデータフィールドは、NSH、セグメントルーティング、Geneve、Bier、IPv6などを含むさまざまな輸送プロトコルによって輸送できます。
IOAM encapsulation for IPv6 is defined in [IOAM-IPV6-OPTIONS], which also discusses IOAM deployment considerations for IPv6 networks.
IPv6のIOAMカプセル化は[IOAM-IPV6-Options]で定義されており、IPv6ネットワークのIOAM展開に関する考慮事項についても説明しています。
IOAM encapsulation for NSH is defined in [IOAM-NSH].
NSHのIOAMカプセル化は、[IOAM-NSH]で定義されています。
IOAM encapsulation for BIER is defined in [BIER-IOAM].
BierのIOAMカプセル化は[Bier-Ioam]で定義されています。
IOAM encapsulation for GRE is outlined as part of the "EtherType Protocol Identification of In-situ OAM Data" in [IOAM-ETH].
GREのIOAMカプセル化は、[IOAM-ETH]の「in-situ OAMデータのEtherTypeプロトコル識別」の一部として概説されています。
IOAM encapsulation for Geneve is defined in [IOAM-GENEVE].
GeneveのIOAMカプセル化は、[ioam-geneve]で定義されています。
IOAM encapsulation for Segment Routing is defined in [MPLS-IOAM].
セグメントルーティングのIOAMカプセル化は、[MPLS-IOAM]で定義されています。
IOAM encapsulation for Segment Routing over IPv6 is defined in [IOAM-SRV6].
IPv6を介したセグメントルーティングのIOAMカプセル化は、[IOAM-SRV6]で定義されています。
IOAM encapsulation for VXLAN-GPE is defined in [IOAM-VXLAN-GPE].
VXLAN-GPEのIOAMカプセル化は、[IOAM-VXLAN-GPE]で定義されています。
IOAM nodes collect information for packets traversing a domain that supports IOAM. IOAM decapsulating nodes, as well as IOAM transit nodes, can choose to retrieve IOAM information from the packet, process the information further, and export the information using, e.g., IP Flow Information Export (IPFIX).
iOAMノードは、iOAMをサポートするドメインを横断するパケットの情報を収集します。IOAM脱カプセンティングノードとIOAMトランジットノードは、IOAM情報をパケットから取得し、情報をさらに処理し、IPフロー情報エクスポート（IPFIX）などを使用して情報をエクスポートすることを選択できます。
Raw data export of IOAM data using IPFIX is discussed in [IOAM-RAWEXPORT]. "Raw export of IOAM data" refers to a mode of operation where a node exports the IOAM data as it is received in the packet. The exporting node does not interpret, aggregate, or reformat the IOAM data before it is exported. Raw export of IOAM data is to support an operational model where the processing and interpretation of IOAM data is decoupled from the operation of encapsulating/updating/decapsulating IOAM data, which is also referred to as "IOAM data-plane operation". Figure 2 shows the separation of concerns for IOAM export. Exporting IOAM data is performed by the "IOAM node", which performs IOAM data-plane operation, whereas the interpretation of IOAM data is performed by one or several IOAM data processing systems. The separation of concerns is to offload interpretation, aggregation, and formatting of IOAM data from the node that performs data-plane operations. In other words, a node that is focused on data-plane operations, i.e., forwarding of packets and handling IOAM data, will not be tasked to also interpret the IOAM data. Instead, that node can leave this task to another system or a set of systems. For scalability reasons, a single IOAM node could choose to export IOAM data to several systems that process IOAM data. Similarly, several monitoring systems or analytics systems can be used to further process the data received from the IOAM preprocessing systems. Figure 2 shows an overview of IOAM export, including IOAM data processing systems and monitoring and analytics systems.
IPFIXを使用したIOAMデータの生データエクスポートについては、[IOAM-Rawexport]で説明しています。「IOAMデータのRAWエクスポート」とは、ノードがパケットで受信されたIOAMデータをエクスポートする操作モードを指します。エクスポートノードは、IOAMデータをエクスポートする前に解釈、集約、または再フォーマットしません。IOAMデータのRAWエクスポートは、IOAMデータの処理と解釈が、「IOAMデータプレーン操作」とも呼ばれるIOAMデータのカプセル化/更新/脱カプセル化の操作から切り離される運用モデルをサポートするためです。図2は、IOAM輸出の懸念の分離を示しています。IOAMデータのエクスポートは、IOAMデータプレーン操作を実行する「IOAMノード」によって実行されますが、IOAMデータの解釈は1つまたは複数のIOAMデータ処理システムによって実行されます。懸念の分離は、データプレーン操作を実行するノードからのIOAMデータの解釈、集約、およびフォーマットをオフロードすることです。言い換えれば、データ平面操作に焦点を当てたノード、つまりパケットの転送とIOAMデータの処理は、IOAMデータも解釈するように任されません。代わりに、そのノードはこのタスクを別のシステムまたは一連のシステムに任せることができます。スケーラビリティの理由により、単一のIOAMノードは、IOAMデータをIOAMデータを処理するいくつかのシステムにエクスポートすることを選択できます。同様に、いくつかの監視システムまたは分析システムを使用して、IOAM前処理システムから受信したデータをさらに処理できます。図2は、IOAMデータ処理システムや監視および分析システムを含むIOAMエクスポートの概要を示しています。
+--------------+
+-------------+ |
| Monitoring/ | |
| Analytics | |
| system(s) |-+
+-------------+
^
| Processed/interpreted/
| aggregated IOAM data
|
+--------------+
+-------------+ |
| IOAM data | |
| processing | |
| system(s) |-+
+-------------+
^
| Raw export of
| IOAM data
|
+--------------+-------+------+--------------+
| | | |
| | | |
User +---+----+ +---+----+ +---+----+ +---+----+
packets |Encapsu-| | Transit| | Transit| |Decapsu-|
-------->|lating |====>| Node |====>| Node |====>|lating |-->
|Node | | A | | B | |Node |
+--------+ +--------+ +--------+ +--------+
Figure 2: IOAM Framework with Data Export
図2：データエクスポートを備えたIOAMフレームワーク
This section describes several concepts of IOAM and provides considerations that need to be taken into account when implementing IOAM in a network domain. This includes concepts like IOAM-Namespaces, IOAM Layering, traffic-sets that IOAM is applied to, and IOAM Loopback. For a definition of IOAM-Namespaces and IOAM Layering, please refer to [RFC9197]. IOAM Loopback is defined in [RFC9322].
このセクションでは、IOAMのいくつかの概念について説明し、ネットワークドメインにiOAMを実装する際に考慮する必要がある考慮事項を提供します。これには、IOAM-NamesSpaces、IOAM階層化、IOAMが適用されるトラフィックセット、IOAMループバックなどの概念が含まれます。IOAM-NamesSpacesとIOAM層の定義については、[RFC9197]を参照してください。IOAMループバックは[RFC9322]で定義されています。
IOAM-Namespaces add further context to IOAM Option-Types and associated IOAM-Data-Fields. IOAM-Namespaces are defined in Section 4.3 of [RFC9197]. The Namespace-ID is part of the IOAM Option-Type definition. See Section 4.4 of [RFC9197] for IOAM Trace Option-Types or Section 4.6 of [RFC9197] for the IOAM E2E Option-Type. IOAM-Namespaces support several uses:
ioam-namespacesは、ioamオプションタイプと関連するioam-data-fieldsにさらにコンテキストを追加します。IOAM-NamesSpacesは、[RFC9197]のセクション4.3で定義されています。名前空間IDは、IOAMオプションタイプの定義の一部です。IOAMトレースオプションタイプについては、[RFC9197]のセクション4.4またはIOAM E2Eオプションタイプについては[RFC9197]のセクション4.6を参照してください。ioam-namespacesはいくつかの用途をサポートしています：
* IOAM-Namespaces can be used by an operator to distinguish between different operational domains. Devices at domain edges can filter on Namespace-IDs to provide for proper IOAM-Domain isolation.
* IOAM-NamesSpacesは、オペレーターが異なる運用ドメインを区別するために使用できます。ドメインエッジのデバイスは、名前空間IDでフィルタリングして、適切なiOAMドメイン分離を提供できます。
* IOAM-Namespaces provide additional context for IOAM-Data-Fields; thus, they ensure that IOAM-Data-Fields are unique and can be interpreted properly by management stations or network controllers. While, for example, the node identifier field does not need to be unique in a deployment (e.g., an operator may wish to use different node identifiers for different IOAM layers, even within the same device; or node identifiers might not be unique for other organizational reasons, such as after a merger of two formerly separated organizations), the combination of node_id and Namespace-ID should always be unique. Similarly, IOAM-Namespaces can be used to define how certain IOAM-Data-Fields are interpreted. IOAM offers three different timestamp format options. The Namespace-ID can be used to determine the timestamp format. IOAM-Data-Fields (e.g., buffer occupancy) that do not have a unit associated are to be interpreted within the context of an IOAM-Namespace. The Namespace-ID could also be used to distinguish between different types of interfaces. An interface-id could, for example, point to a physical interface (e.g., to understand which physical interface of an aggregated link is used when receiving or transmitting a packet). Whereas, in another case, an interface-id could refer to a logical interface (e.g., in case of tunnels). Namespace-IDs could be used to distinguish between the different types of interfaces.
* ioam-namespacesは、ioam-data-fieldsに追加のコンテキストを提供します。したがって、IOAM-Data-Fieldがユニークであり、管理ステーションまたはネットワークコントローラーによって適切に解釈できることを保証します。たとえば、ノード識別子フィールドは展開で一意である必要はありません（たとえば、オペレーターは、同じデバイス内であっても、異なるiOAMレイヤーに異なるノード識別子を使用することを希望する場合があります。以前に2つの分離された組織の合併後などの組織的な理由）、node_idとnamespace-idの組み合わせは常に一意でなければなりません。同様に、IOAM-NamesSpacesを使用して、特定のIOAM-DATAフィールドがどのように解釈されるかを定義できます。IOAMには、3つの異なるタイムスタンプ形式のオプションがあります。名前空間IDを使用して、タイムスタンプ形式を決定できます。ユニットが関連付けられていないioam-data-fields（例：バッファー占有率）は、ioam-namespaceのコンテキスト内で解釈されるべきです。名前空間IDを使用して、異なるタイプのインターフェイスを区別することもできます。たとえば、インターフェイスIDは、物理インターフェイスを指すことができます（たとえば、パケットを受信または送信するときに集約されたリンクの物理インターフェイスが使用されるかを理解するため）。一方、別のケースでは、インターフェイスIDは論理インターフェイスを参照できます（たとえば、トンネルの場合）。名前空間IDを使用して、さまざまな種類のインターフェイスを区別できます。
* IOAM-Namespaces can be used to identify different sets of devices (e.g., different types of devices) in a deployment. If an operator desires to insert different IOAM-Data-Fields based on the device, the devices could be grouped into multiple IOAM-Namespaces. This could be due to the fact that the IOAM feature set differs between different sets of devices, or it could be for reasons of optimized space usage in the packet header. It could also stem from hardware or operational limitations on the size of the trace data that can be added and processed, preventing collection of a full trace for a flow.
* IOAM-NamesSpacesを使用して、展開中にさまざまなデバイス（さまざまな種類のデバイス）を識別できます。オペレーターがデバイスに基づいて異なるIOAM-DATAフィールドを挿入したい場合、デバイスは複数のIOAM名宇宙にグループ化できます。これは、IOAM機能セットがデバイスの異なるセット間で異なるか、パケットヘッダーで最適化されたスペース使用の理由である可能性があるためです。また、追加および処理できるトレースデータのサイズのハードウェアまたは動作制限に起因する可能性があり、フローの完全なトレースの収集を防ぐことができます。
- Assigning different IOAM Namespace-IDs to different sets of nodes or network partitions and using the Namespace-ID as a selector at the IOAM encapsulating node, a full trace for a flow could be collected and constructed via partial traces in different packets of the same flow. For example, an operator could choose to group the devices of a domain into two IOAM-Namespaces in a way that, on average, only every second hop would be recorded by any device. To retrieve a full view of the deployment, the captured IOAM-Data-Fields of the two IOAM-Namespaces need to be correlated.
- さまざまなIOAM NameSpace-IDをさまざまなノードまたはネットワークパーティションのセットに割り当て、IOAMカプセル化ノードのセレクターとしてNamespace-IDを使用すると、同じフローの異なるパケットの部分トレースを介してフローの完全なトレースを収集および構築できます。。たとえば、オペレーターは、ドメインのデバイスを2つのiOam-Namespacesにグループ化することを選択できます。展開の完全なビューを取得するには、2つのiOam-namespacesのキャプチャされたioam-data-fieldsを相関させる必要があります。
- Assigning different IOAM Namespace-IDs to different sets of nodes or network partitions and using a separate instance of an IOAM Option-Type for each Namespace-ID, a full trace for a flow could be collected and constructed via partial traces from each IOAM Option-Type in each of the packets in the flow. For example, an operator could choose to group the devices of a domain into two IOAM-Namespaces in a way that each IOAM-Namespace is represented by one of two IOAM Option-Types in the packet. Each node would record data only for the IOAM-Namespace that it belongs to, ignoring the other IOAM Option-Type with an IOAM-Namespace it doesn't belong to. To retrieve a full view of the deployment, the captured IOAM-Data-Fields of the two IOAM-Namespaces need to be correlated.
- さまざまなIOAM namespace-idを異なるノードまたはネットワークパーティションのセットに割り当て、各namespace-idのIOAMオプションタイプの個別のインスタンスを使用して、フローの完全なトレースを各iOAMオプションからの部分トレースで収集および構築できます。フロー内の各パケットを入力します。たとえば、オペレーターは、各IOAM-NamesSpaceがパケット内の2つのIOAMオプションタイプのいずれかで表されるように、ドメインのデバイスを2つのiOAM名空間にグループ化することを選択できます。各ノードは、属するiOam-namespaceのみのデータを記録し、属していないioam-namespaceで他のioamオプションタイプを無視します。展開の完全なビューを取得するには、2つのiOam-namespacesのキャプチャされたioam-data-fieldsを相関させる必要があります。
If several encapsulation protocols (e.g., in case of tunneling) are stacked on top of each other, IOAM-Data-Fields could be present in different protocol fields at different layers. Layering allows operators to instrument the protocol layer they want to measure. The behavior follows the ships-in-the-night model, i.e., IOAM-Data-Fields in one layer are independent of IOAM-Data-Fields in another layer. Or in other words, even though the term "layering" often implies there is some form of hierarchy and relationship, in IOAM, layers are independent of each other and don't assume any relationship among them. The different layers could, but do not have to, share the same IOAM encapsulation mechanisms. Similarly, the semantics of the IOAM-Data-Fields can, but do not have to, be associated to cross different layers. For example, a node that inserts node-id information into two different layers could use "node-id=10" for one layer and "node-id=1000" for the second layer.
いくつかのカプセル化プロトコル（トンネリングの場合など）が互いに積み重ねられている場合、異なる層の異なるプロトコルフィールドにIOAM-DATAフィールドが存在する可能性があります。レイヤー化により、オペレーターは測定したいプロトコル層を計測できます。動作は、夜間の船モデルに従います。つまり、ある層のiOAM-data-fieldsは、別の層のioam-data-fieldsに依存しません。または言い換えれば、「レイヤー」という用語はしばしば階層と関係の形があることを意味しますが、ioamでは、レイヤーは互いに独立しており、それらの間の関係を想定していません。異なる層は、同じIOAMカプセル化メカニズムを共有する必要はありませんが、必要はありません。同様に、ioam-data-fieldsのセマンティクスは、異なる層を横断することに関連付ける必要はありませんが、必要はありません。たとえば、ノードID情報を2つの異なるレイヤーに挿入するノードは、1つのレイヤーに「ノードID = 10」、2番目のレイヤーに「ノードID = 1000」を使用できます。
Figure 3 shows an example of IOAM Layering. The figure shows a Geneve tunnel carried over IPv6, which starts at node A and ends at node D. IOAM information is encapsulated in IPv6 as well as in Geneve. At the IPv6 layer, node A is the IOAM encapsulating node (into IPv6), node D is the IOAM decapsulating node, and nodes B and C are IOAM transit nodes. At the Geneve layer, node A is the IOAM encapsulating node (into Geneve), and node D is the IOAM decapsulating node (from Geneve). The use of IOAM at both layers, as shown in the example here, could be used to reveal which nodes of an underlay (here the IPv6 network) are traversed by a tunneled packet in an overlay (here the Geneve network) -- which assumes that the IOAM information encapsulated by nodes A and D into Geneve and IPv6 is associated to each other.
図3は、IOAMレイヤーの例を示しています。この図は、ノードAで始まり、ノードDで終了するIPv6の上に運ばれたGeneveトンネルを示しています。IPv6レイヤーでは、ノードAはIOAMカプセル化ノード（IPv6へ）、ノードDはIOAM脱カプセンティングノード、ノードBとCはIOAMトランジットノードです。Geneve層では、ノードAはIOAMカプセル化ノード（Geneve）であり、ノードDはIOAM脱カプセンティングノード（Geneveから）です。ここの例に示すように、両方のレイヤーでのIOAMの使用は、アンダーレイ（ここではIPv6ネットワーク）のどのノードがオーバーレイ（ここではGeneveネットワーク）のトンネルパケットによって横断されるかを明らかにするために使用できます。ノードAとDによってカプセル化されたIOAM情報がGeneveとIPv6にカプセル化されていることは、互いに関連付けられていること。
+---+----+ +---+----+
User |Geneve | |Geneve |
packets |Encapsu-| |Decapsu-|
-------->|lating |==================================>|lating |-->
| Node | | Node |
| A | | D |
+--------+ +--------+
^ ^
| |
v v
+--------+ +--------+ +--------+ +--------+
|IPv6 | | IPv6 | | IPv6 | |IPv6 |
|Encapsu-| | Transit| | Transit| |Decapsu-|
|lating |====>| Node |====>| Node |====>|lating |
| Node | | | | | | Node |
| A | | B | | C | | D |
+--------+ +--------+ +--------+ +--------+
Figure 3: IOAM Layering Example
図3：IOAMレイヤーの例
IOAM offers two different IOAM Option-Types for tracing: "Incremental" Trace Option-Type and "Pre-allocated" Trace Option-Type. "Incremental" refers to a mode of operation where the packet is expanded at every IOAM node that adds IOAM-Data-Fields. "Pre-allocated" describes a mode of operation where the IOAM encapsulating node allocates room for all IOAM-Data-Fields in the entire IOAM-Domain. More specifically:
IOAMは、トレース用の2つの異なるIOAMオプションタイプを提供します：「インクリメンタル」トレースオプションタイプと「事前に割り当てられた」トレースオプションタイプ。「インクリメンタル」とは、ioam-data-fieldsを追加するすべてのioamノードでパケットが展開される操作モードを指します。「Pre-Allocated」では、IOAMカプセル化ノードがIOAMドメイン全体のすべてのIOAM-DATAフィールドに部屋を割り当てる操作モードについて説明します。すなわち：
Pre-allocated Trace Option:
事前に割り当てられたトレースオプション：
This trace option is defined as a container of node data fields with pre-allocated space for each node to populate its information. This option is useful for implementations where it is efficient to allocate the space once and index into the array to populate the data during transit (e.g., software forwarders often fall into this class).
このトレースオプションは、各ノードが情報を入力するために事前に割り当てられたスペースを持つノードデータフィールドのコンテナとして定義されます。このオプションは、スペースを一度割り当ててアレイにインデックスを付けて、トランジット中にデータを入力するのが効率的な実装に役立ちます（たとえば、ソフトウェアの転送者がこのクラスに分類されることが多い）。
Incremental Trace Option:
インクリメンタルトレースオプション：
This trace option is defined as a container of node data fields where each node allocates and pushes its node data immediately following the option header.
このトレースオプションは、各ノードがオプションヘッダーの直後にノードデータを割り当ててプッシュするノードデータフィールドのコンテナとして定義されます。
Which IOAM Trace Option-Types can be supported is not only a function of operator-defined configuration but may also be limited by protocol constraints unique to a given encapsulating protocol. For encapsulating protocols that support both IOAM Trace Option-Types, the operator decides, by means of configuration, which Trace Option-Type(s) will be used for a particular domain. In this case, deployments can mix devices that include either the Incremental Trace Option-Type or the Pre-allocated Trace Option-Type. For example, if different types of packet forwarders and associated different types of IOAM implementations exist in a deployment and the encapsulating protocol supports both IOAM Trace Option-Types, a deployment can mix devices that include either the Incremental Trace Option-Type or the Pre-allocated Trace Option-Type. As a result, both Option-Types can be present in a packet. IOAM decapsulating nodes remove both types of Trace Option-Types from the packet.
IOAM TRACEオプションタイプをサポートできるのは、オペレーター定義の構成の関数であるだけでなく、特定のカプセル化プロトコルに固有のプロトコル制約によって制限される場合もあります。両方のIOAMトレースオプションタイプをサポートするプロトコルをカプセル化する場合、オペレーターは、特定のドメインにトレースオプションタイプが使用される構成によって決定されます。この場合、展開は、増分トレースオプションタイプまたは事前に割り当てられたトレースオプションタイプのいずれかを含むデバイスを組み合わせることができます。たとえば、さまざまな種類のパケット転送ターと関連するさまざまなタイプのIOAM実装が展開に存在し、カプセル化プロトコルが両方のIOAMトレースオプションタイプをサポートする場合、展開は、インクルミングルトレースオプションタイプまたは前のいずれかを含むデバイスを組み合わせることができます。割り当てられたトレースオプションタイプ。その結果、両方のオプションタイプがパケットに存在する可能性があります。IOAM脱カプセンティングノードは、パケットから両方のタイプのトレースオプションタイプを削除します。
The two different Option-Types cater to different packet-forwarding infrastructures and allow an optimized implementation of IOAM tracing:
2つの異なるオプションタイプは、さまざまなパケットフォワードインフラストラクチャに対応し、IOAMトレースの最適化された実装を可能にします。
Pre-allocated Trace Option:
事前に割り当てられたトレースオプション：
For some implementations of packet forwarders, it is efficient to allocate the space for the maximum number of nodes that IOAM Trace Data-Fields should be collected from and insert/update information in the packet at flexible locations based on a pointer retrieved from a field in the packet. The IOAM encapsulating node allocates an array of the size of the maximum number of nodes that IOAM Trace Data-Fields should be collected from. IOAM transit nodes index into the array to populate the data during transit. Software forwarders often fall into this class of packet-forwarder implementations. The maximum number of nodes that IOAM information could be collected from is configured by the operator on the IOAM encapsulating node. The operator has to ensure that the packet with the pre-allocated array that carries the IOAM Data-Fields does not exceed the MTU of any of the links in the IOAM-Domain.
パケットフォワーダーのいくつかの実装では、IOAMトレースデータフィールドから最大数のノードにスペースを割り当てることが効率的です。パケット。IOAMカプセル化ノードは、IOAMトレースデータフィールドを収集する必要があるノードの最大数のサイズの配列を割り当てます。IOAMトランジットノードはアレイにインデックスを付けて、トランジット中にデータを入力します。ソフトウェアのフォワーダーは、多くの場合、このクラスのパケットフォワードの実装に分類されます。IOAM情報から収集できるノードの最大数は、IOAMカプセル化ノードの演算子によって構成されています。オペレーターは、IOAMデータフィールドを運ぶ事前に割り当てられた配列を備えたパケットが、iOAMドメインのリンクのいずれのMTUを超えないことを確認する必要があります。
Incremental Trace Option:
インクリメンタルトレースオプション：
Looking up a pointer contained in the packet and inserting/updating information at a flexible location in the packet as a result of the pointer lookup is costly for some forwarding infrastructures. Hardware-based packet-forwarding infrastructures often fall into this category. Consequently, hardware-based packet forwarders could choose to support the IOAM Incremental Trace Option-Type. The IOAM Incremental Trace Option-Type eliminates the need for the IOAM transit nodes to read the full array in the Trace Option-Type and allows packets to grow to the size of the MTU of the IOAM-Domain. IOAM transit nodes will expand the packet and insert the IOAM-Data-Fields as long as there is space available in the packet, i.e., as long as the size of the packet stays within the bounds of the MTU of the links in the IOAM-Domain. There is no need for the operator to configure the IOAM encapsulation node with the maximum number of nodes that IOAM information could be collected from. The operator has to ensure that the minimum MTU of the links in the IOAM-Domain is known to all IOAM transit nodes.
パケットに含まれるポインターを検索し、ポインター検索の結果としてパケット内の柔軟な場所で情報を挿入/更新することは、一部の転送インフラストラクチャの費用がかかります。ハードウェアベースのパケットフォードインフラストラクチャは、多くの場合、このカテゴリに分類されます。したがって、ハードウェアベースのパケットフォワーダーは、IOAM増分トレースオプションタイプをサポートすることを選択できます。IOAM増分トレースオプションタイプは、IOAMトランジットノードがTRACEオプションタイプの完全な配列を読み取る必要がなくなり、IOAMドメインのMTUのサイズにパケットが成長できるようにします。IOAMトランジットノードは、パケットを展開し、パケットに使用できるスペースがある限り、つまり、パケットのサイズがiOAM-のリンクのMTUの範囲内にとどまる限り、IOAM-DATAフィールドを挿入します。ドメイン。IOAM情報を収集できるノードの最大数でIOAMカプセル化ノードを構成するオペレーターは必要ありません。オペレーターは、IOAMドメインのリンクの最小MTUがすべてのIOAMトランジットノードに対して知られていることを確認する必要があります。
IOAM can be deployed on all or only on subsets of the live user traffic, e.g., per interface, based on an access control list or flow specification defining a specific set of traffic, etc.
IOAMは、特定のトラフィックセットなどを定義するアクセス制御リストまたはフロー仕様に基づいて、インターフェイスごとに、ライブユーザートラフィックのサブセットにすべてまたは唯一のサブセットに展開できます。
IOAM Loopback is used to trigger each transit device along the path of a packet to send a copy of the data packet back to the source. Loopback allows an IOAM encapsulating node to trace the path to a given destination and to receive per-hop data about both the forward and the return path. Loopback is enabled by the encapsulating node setting the Loopback flag. Looped-back packets use the source address of the original packet as a destination address and the address of the node that performs the Loopback operation as source address. Nodes that loop back a packet clear the Loopback flag before sending the copy back towards the source. Loopack applies to IOAM deployments where the encapsulating node is either a host or the start of a tunnel. For details on IOAM Loopback, please refer to [RFC9322].
IOAMループバックは、パケットのパスに沿って各トランジットデバイスをトリガーするために、データパケットのコピーをソースに送信します。Loopbackを使用すると、IOAMをカプセル化するノードを使用して、特定の宛先へのパスをトレースし、フォワードパスとリターンパスの両方に関するホップごとのデータを受信できます。ループバックは、ループバックフラグを設定するカプセル化ノードによって有効になります。ループバックパケットは、元のパケットのソースアドレスを宛先アドレスとして使用し、ループバック操作をソースアドレスとして実行するノードのアドレスを使用します。コピーをソースに送り返す前に、パケットをループバックバックするノードはループバックフラグをクリアします。Loopackは、カプセル化ノードがホストまたはトンネルの開始のいずれかであるIOAM展開に適用されます。iOAMループバックの詳細については、[RFC9322]を参照してください。
The Active flag indicates that a packet is an active OAM packet as opposed to regular user data traffic. Active flag is expected to be used for active measurement using IOAM. For details on the Active flag, please refer to [RFC9322].
アクティブフラグは、通常のユーザーデータトラフィックとは対照的に、パケットがアクティブなOAMパケットであることを示しています。アクティブフラグは、iOAMを使用したアクティブ測定に使用されることが予想されます。アクティブフラグの詳細については、[RFC9322]を参照してください。
Example use cases for the Active flag include:
アクティブフラグの例のユースケースは次のとおりです。
Endpoint detailed active measurement:
エンドポイントの詳細なアクティブ測定：
Synthetic probe packets are sent between the source and destination. These probe packets include a Trace Option-Type (i.e., either incremental or pre-allocated). Since the probe packets are sent between the endpoints, these packets are treated as data packets by the IOAM-Domain and do not require special treatment at the IOAM layer. The source, which is also the IOAM encapsulating node, can choose to set the Active flag, providing an explicit indication that these probe packets are meant for telemetry collection.
合成プローブパケットは、ソースと宛先の間に送信されます。これらのプローブパケットには、トレースオプションタイプ（つまり、インクリメンタルまたは事前に割り当てられた）が含まれます。プローブパケットはエンドポイント間で送信されるため、これらのパケットはiOAMドメインによってデータパケットとして扱われ、iOAM層での特別な処理は必要ありません。IOAMカプセル化ノードでもあるソースは、アクティブフラグを設定することを選択でき、これらのプローブパケットがテレメトリーコレクション用に対象とすることを明示的に示しています。
IOAM active measurement using probe packets:
プローブパケットを使用したIOAMアクティブ測定：
Probe packets are generated and transmitted by an IOAM encapsulating node towards a destination that is also the IOAM decapsulating node. Probe packets include a Trace Option-Type (i.e., either incremental or pre-allocated) that has its Active flag set.
プローブパケットは、IOAMカプセル化ノードに向けてIOAMカプセル化ノードをカプセル化するIOAMによって生成および送信されます。プローブパケットには、アクティブなフラグセットを備えたTRACEオプションタイプ（つまり、インクリメンタルまたは事前に割り当てられた）が含まれます。
IOAM active measurement using replicated data packets:
複製されたデータパケットを使用したIOAMアクティブ測定：
Probe packets are created by an IOAM encapsulating node by selecting some or all of the en route data packets and replicating them. A selected data packet that is replicated and its (possibly truncated) copy are forwarded with one or more IOAM options, while the original packet is forwarded, normally, without IOAM options. To the extent possible, the original data packet and its replica are forwarded through the same path. The replica includes a Trace Option-Type that has its Active flag set, indicating that the IOAM decapsulating node should terminate it. In this case, the IOAM Active flag ensures that the replicated traffic is not forwarded beyond the IOAM-Domain.
プローブパケットは、IOAMカプセル化ノードによって作成されます。これは、途中のデータパケットの一部またはすべてを選択して複製することにより、ノードをカプセル化します。複製された選択されたデータパケットとその（おそらく切り捨てられた）コピーには、1つ以上のIOAMオプションが転送されますが、通常はIOAMオプションなしで元のパケットが転送されます。可能な限り、元のデータパケットとそのレプリカは同じパスから転送されます。レプリカには、アクティブなフラグセットを備えたトレースオプションタイプが含まれており、IOAM脱カプセンティングノードが終了することを示しています。この場合、IOAMアクティブフラグは、複製されたトラフィックがIOAMドメインを超えて転送されないことを保証します。
A network can consist of a mix of IOAM-aware and IOAM-unaware nodes. The encapsulation of IOAM-Data-Fields into different protocols (see also Section 5) are defined such that data packets that include IOAM-Data-Fields do not get dropped by IOAM-unaware nodes. For example, packets that contain the IOAM Trace Option-Types in IPv6 Hop-by-Hop extension headers are defined with bits to indicate "00 - skip over this option and continue processing the header". This will ensure that when an IOAM-unaware node receives a packet with IOAM-Data-Fields included, it does not drop the packet.
ネットワークは、IOAMを意識したノードとIOAMに同意するノードの組み合わせで構成できます。IOAM-DATA-FIELDSの異なるプロトコルへのカプセル化（セクション5も参照）は、IOAM-DATAフィールドを含むデータパケットがIOAMに使用されたノードによって削除されないように定義されています。たとえば、IPv6ホップバイホップエクステンションヘッダーにIOAMトレースオプションタイプを含むパケットは、「00-このオプションをスキップしてヘッダーの処理を継続する」を示すビットで定義されます。これにより、iOAM-unawareノードがioam-data-fieldsを含むパケットを受信した場合、パケットをドロップしないことが保証されます。
Deployments that leverage the IOAM Trace Option-Type(s) could benefit from the ability to detect the presence of IOAM-unaware nodes, i.e., nodes that forward the packet but do not update or add IOAM-Data-Fields in IOAM Trace Option-Types. The node data that is defined as part of the IOAM Trace Option-Type(s) includes a Hop_Lim field associated to the node identifier to detect missed nodes, i.e., "holes" in the trace. Monitoring/Analytics systems could utilize this information to account for the presence of IOAM-unaware nodes in the network.
IOAMトレースオプションタイプを活用する展開は、IOAMに不名誉なノードの存在を検出する能力、つまりパケットを転送するノードではなく、IOAMトレースオプションにIOAM-Data-Fieldsを更新または追加しないノードから利益を得ることができます。種類。IOAMトレースオプションタイプの一部として定義されるノードデータには、ノード識別子に関連付けられたhop_limフィールドが含まれており、見逃したノード、つまりトレースの「穴」を検出します。監視/分析システムは、この情報を利用して、ネットワーク内のIOAMに不名誉なノードの存在を説明できます。
The YANG model for configuring IOAM in network nodes that support IOAM is defined in [IOAM-YANG].
IOAMをサポートするネットワークノードにIOAMを構成するためのYangモデルは、[ioam-yang]で定義されています。
A deployment can leverage IOAM profiles to limit the scope of IOAM features, allowing simpler implementation, verification, and interoperability testing in the context of specific use cases that do not require the full functionality of IOAM. An IOAM profile defines a use case or a set of use cases for IOAM and an associated set of rules that restrict the scope and features of the IOAM specification, thereby limiting it to a subset of the full functionality. IOAM profiles are defined in [IOAM-PROFILES].
展開はIOAMプロファイルを活用してIOAM機能の範囲を制限し、IOAMの完全な機能を必要としない特定のユースケースのコンテキストで、より簡単な実装、検証、および相互運用性テストを可能にします。IOAMプロファイルは、IOAMのユースケースまたはユースケースのセットと、IOAM仕様の範囲と機能を制限する関連する一連のルールセットを定義し、それによりそれを完全な機能のサブセットに制限します。IOAMプロファイルは[ioamプロファイル]で定義されています。
For deployments where the IOAM capabilities of a node are unknown, [RFC9359] could be used to discover the enabled IOAM capabilities of nodes.
ノードのIOAM機能が不明な展開の場合、[RFC9359]を使用して、ノードの有効なIOAM機能を発見できます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
As discussed in [RFC7276], a successful attack on an OAM protocol in general and, specifically, on IOAM can prevent the detection of failures or anomalies or can create a false illusion of nonexistent ones.
[RFC7276]で説明したように、一般的なOAMプロトコルに対する攻撃の成功、特にIOAMでの攻撃は、障害や異常の検出を防ぐことができたり、存在しないものの誤った幻想を引き起こす可能性があります。
The Proof of Transit Option-Type (Section 4.2) is used for verifying the path of data packets. The security considerations of POT are further discussed in [PROOF-OF-TRANSIT].
トランジットオプションタイプの証明（セクション4.2）は、データパケットのパスの検証に使用されます。ポットのセキュリティ上の考慮事項については、[トランシットの証明]でさらに説明します。
Security considerations related to the use of IOAM flags, particularly the Loopback flag, are found in [RFC9322].
IOAMフラグ、特にループバックフラグの使用に関連するセキュリティ上の考慮事項は、[RFC9322]にあります。
IOAM data can be subject to eavesdropping. Although the confidentiality of the user data is not at risk in this context, the IOAM data elements can be used for network reconnaissance, allowing attackers to collect information about network paths, performance, queue states, buffer occupancy, and other information. Recon is an improbable security threat in an IOAM deployment that is within a confined physical domain. However, in deployments that are not confined to a single LAN but span multiple interconnected sites (for example, using an overlay network), the inter-site links are expected to be secured (e.g., by IPsec) in order to avoid external eavesdropping and introduction of malicious or false data. Another possible mitigation approach is to use "Direct Exporting" [RFC9326]. In this case, the IOAM-related trace information would not be available in the customer data packets but would trigger the exporting of (secured) packet-related IOAM information at every node. IOAM data export and securing IOAM data export is outside the scope of this document.
IOAMデータは、盗聴の対象となります。このコンテキストでは、ユーザーデータの機密性は危険にさらされていませんが、IOAMデータ要素をネットワーク偵察に使用できるため、攻撃者はネットワークパス、パフォーマンス、キュー状態、バッファー占有率、その他の情報に関する情報を収集できます。偵察は、限られた物理ドメイン内にあるIOAM展開におけるありそうもないセキュリティの脅威です。ただし、単一のLANに限定されていないが、複数の相互接続されたサイト（オーバーレイネットワークを使用する）に及ぶ展開では、外部盗聴を避けるために（IPSECなど）保護されると予想されます。悪意のあるまたは誤ったデータの導入。別の可能な緩和アプローチは、「直接輸出」[RFC9326]を使用することです。この場合、IOAM関連のトレース情報は顧客データパケットで使用できませんが、すべてのノードで（セキュリティ）パケット関連のiOAM情報のエクスポートをトリガーします。IOAMデータのエクスポートとIOAMデータエクスポートの保護は、このドキュメントの範囲外です。
IOAM can be used as a means for implementing or amplifying Denial-of-Service (DoS) attacks. For example, a malicious attacker can add an IOAM header to packets or modify an IOAM header in en route packets in order to consume the resources of network devices that take part in IOAM or collectors that analyze the IOAM data. Another example is a packet-length attack, in which an attacker pushes headers associated with IOAM Option-Types into data packets, causing these packets to be increased beyond the MTU size, resulting in fragmentation or in packet drops. Such DoS attacks can be mitigated by deploying IOAM in confined administrative domains and by limiting the rate and/or the percentage of packets that an IOAM encapsulating node adds IOAM information to as well as limiting rate and/or percentage of packets that an IOAM transit or an IOAM decapsulating node creates to export IOAM information extracted from the data packets that carry IOAM information.
IOAMは、サービス拒否（DOS）攻撃を実装または増幅する手段として使用できます。たとえば、悪意のある攻撃者は、IOAMヘッダーをパケットに追加するか、IOAMデータを分析するIOAMまたはコレクターに参加するネットワークデバイスのリソースを消費するために、途中のパケットのIOAMヘッダーを変更することができます。もう1つの例は、パケット長攻撃です。この攻撃では、攻撃者がIOAMオプションタイプに関連付けられたヘッダーをデータパケットに押し込み、MTUサイズを超えてこれらのパケットを増やし、断片化またはパケットドロップになります。このようなDOS攻撃は、限られた管理ドメインにIOAMを展開し、IOAMがノードをカプセル化するレートおよび/またはIOAM情報を追加するパケットの割合および/または割合を制限することにより、IOAMトランジットまたはIOAMトランジットまたはパケットの割合および/または割合を制限することにより、軽減できます。IOAM脱カプセンティングノードは、iOAM情報を運ぶデータパケットから抽出されたIOAM情報をエクスポートするために作成されます。
Even though IOAM focused on limited domains [RFC8799], there might be deployments for which it is important for IOAM transit nodes and IOAM decapsulating nodes to know that the data received haven't been tampered with. In those cases, the IOAM data should be integrity protected. Integrity protection of IOAM data fields is described in [IOAM-DATA-INTEGRITY]. In addition, since IOAM options may include timestamps, if network devices use synchronization protocols, then any attack on the time protocol [RFC7384] can compromise the integrity of the timestamp-related data fields. Synchronization attacks can be mitigated by combining a secured time distribution scheme, e.g., [RFC8915], and by using redundant clock sources [RFC5905] and/or redundant network paths for the time distribution protocol [RFC8039].
IOAMは限られたドメイン[RFC8799]に焦点を合わせていましたが、IOAMトランジットノードとIOAMの脱カプセル化ノードにとって重要である展開がある可能性があります。そのような場合、IOAMデータは整合性保護されている必要があります。IOAMデータフィールドの整合性保護は、[IOAM-Data-Integrity]で説明されています。さらに、IOAMオプションにはタイムスタンプが含まれる可能性があるため、ネットワークデバイスが同期プロトコルを使用する場合、TIMEプロトコル[RFC7384]に対する攻撃は、タイムスタンプ関連のデータフィールドの整合性を損なう可能性があります。同期攻撃は、[RFC8915]などの安全な時間分布スキームを組み合わせ、時間分布プロトコル[RFC8039]の冗長なクロックソース[RFC5905]および/または冗長ネットワークパスを使用することにより、軽減できます。
At the management plane, attacks may be implemented by misconfiguring or by maliciously configuring IOAM-enabled nodes in a way that enables other attacks. Thus, IOAM configuration should be secured in a way that authenticates authorized users and verifies the integrity of configuration procedures.
管理面では、攻撃は、他の攻撃を可能にする方法でIOAM対応ノードを悪意を持って構成することにより、攻撃を実装できます。したがって、IOAM構成は、認定されたユーザーを認証し、構成手順の整合性を検証する方法で保護する必要があります。
Notably, IOAM is expected to be deployed in limited network domains [RFC8799], thus, confining the potential attack vectors within the limited domain. Indeed, in order to limit the scope of threats within the current network domain, the network operator is expected to enforce policies that prevent IOAM traffic from leaking outside the IOAM-Domain and prevent an attacker from introducing malicious or false IOAM data to be processed and used within the IOAM-Domain. IOAM data leakage could lead to privacy issues. Consider an IOAM encapsulating node that is a home gateway in an operator's network. A home gateway is often identified with an individual. Revealing IOAM data, such as "IOAM node identifier" or geolocation information outside of the limited domain, could be harmful for that user. Note that Direct Exporting [RFC9326] can mitigate the potential threat of IOAM data leaking through data packets.
特に、IOAMは限られたネットワークドメイン[RFC8799]に展開されると予想されているため、限られたドメイン内の潜在的な攻撃ベクトルを閉じ込めます。実際、現在のネットワークドメイン内の脅威の範囲を制限するために、ネットワークオペレーターは、IOAMトラフィックがIOAMドメインの外側に漏れないようにするポリシーを実施し、攻撃者が悪意のあるまたは偽のIOAMデータを処理するのを防ぐことが期待され、iOAMドメイン内で使用されます。IOAMデータリークは、プライバシーの問題につながる可能性があります。オペレーターのネットワーク内のホームゲートウェイであるIOAMカプセル化ノードを検討してください。多くの場合、ホームゲートウェイは個人と識別されます。「IOAMノード識別子」や限られたドメイン外の地理的情報などのIOAMデータを明らかにすることは、そのユーザーにとって有害である可能性があります。直接エクスポート[RFC9326]は、データパケットを介してIOAMデータの潜在的な脅威を軽減できることに注意してください。
[BIER-IOAM]
Min, X., Zhang, Z., Liu, Y., Nainar, N., and C. Pignataro,
"BIER Encapsulation for IOAM Data", Work in Progress,
Internet-Draft, draft-xzlnp-bier-ioam-05, 27 January 2023,
<https://datatracker.ietf.org/doc/html/draft-xzlnp-bier-
ioam-05>.
[IOAM-DATA-INTEGRITY]
Brockners, F., Bhandari, S., Mizrahi, T., and J. Iurman,
"Integrity of In-situ OAM Data Fields", Work in Progress,
Internet-Draft, draft-ietf-ippm-ioam-data-integrity-03, 24
November 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-ippm-ioam-data-integrity-03>.
[IOAM-ETH] Weis, B., Ed., Brockners, F., Ed., Hill, C., Bhandari, S.,
Govindan, V., Pignataro, C., Ed., Nainar, N., Ed.,
Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A.,
Gafni, B., Lapukhov, P., and M. Spiegel, "EtherType
Protocol Identification of In-situ OAM Data", Work in
Progress, Internet-Draft, draft-weis-ippm-ioam-eth-05, 21
February 2022, <https://datatracker.ietf.org/doc/html/
draft-weis-ippm-ioam-eth-05>.
[IOAM-GENEVE]
Brockners, F., Ed., Bhandari, S., Govindan, V., Pignataro,
C., Ed., Nainar, N., Ed., Gredler, H., Leddy, J., Youell,
S., Mizrahi, T., Lapukhov, P., Gafni, B., Kfir, A., and M.
Spiegel, "Geneve encapsulation for In-situ OAM Data", Work
in Progress, Internet-Draft, draft-brockners-ippm-ioam-
geneve-05, 19 November 2020,
<https://datatracker.ietf.org/doc/html/draft-brockners-
ippm-ioam-geneve-05>.
[IOAM-IPV6-OPTIONS]
Bhandari, S., Ed. and F. Brockners, Ed., "In-situ OAM IPv6
Options", Work in Progress, Internet-Draft, draft-ietf-
ippm-ioam-ipv6-options-10, 28 February 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
ioam-ipv6-options-10>.
[IOAM-NSH] Brockners, F., Ed. and S. Bhandari, Ed., "Network Service
Header (NSH) Encapsulation for In-situ OAM (IOAM) Data",
Work in Progress, Internet-Draft, draft-ietf-sfc-ioam-nsh-
11, 30 September 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-sfc-
ioam-nsh-11>.
[IOAM-PROFILES]
Mizrahi, T., Brockners, F., Bhandari, S., Ed.,
Sivakolundu, R., Pignataro, C., Kfir, A., Gafni, B.,
Spiegel, M., and T. Zhou, "In Situ OAM Profiles", Work in
Progress, Internet-Draft, draft-mizrahi-ippm-ioam-profile-
06, 17 February 2022,
<https://datatracker.ietf.org/doc/html/draft-mizrahi-ippm-
ioam-profile-06>.
[IOAM-RAWEXPORT]
Spiegel, M., Brockners, F., Bhandari, S., and R.
Sivakolundu, "In-situ OAM raw data export with IPFIX",
Work in Progress, Internet-Draft, draft-spiegel-ippm-ioam-
rawexport-06, 21 February 2022,
<https://datatracker.ietf.org/doc/html/draft-spiegel-ippm-
ioam-rawexport-06>.
[IOAM-SRV6]
Ali, Z., Gandhi, R., Filsfils, C., Brockners, F., Nainar,
N., Pignataro, C., Li, C., Chen, M., and G. Dawra,
"Segment Routing Header encapsulation for In-situ OAM
Data", Work in Progress, Internet-Draft, draft-ali-spring-
ioam-srv6-06, 10 July 2022,
<https://datatracker.ietf.org/doc/html/draft-ali-spring-
ioam-srv6-06>.
[IOAM-VXLAN-GPE]
Brockners, F., Bhandari, S., Govindan, V., Pignataro, C.,
Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A.,
Gafni, B., Lapukhov, P., and M. Spiegel, "VXLAN-GPE
Encapsulation for In-situ OAM Data", Work in Progress,
Internet-Draft, draft-brockners-ipxpm-ioam-vxlan-gpe-03, 4
November 2019, <https://datatracker.ietf.org/doc/html/
draft-brockners-ippm-ioam-vxlan-gpe-03>.
[IOAM-YANG]
Zhou, T., Ed., Guichard, J., Brockners, F., and S.
Raghavan, "A YANG Data Model for In-Situ OAM", Work in
Progress, Internet-Draft, draft-ietf-ippm-ioam-yang-06, 27
February 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-ippm-ioam-yang-06>.
[MPLS-IOAM]
Gandhi, R., Ed., Brockners, F., Wen, B., Decraene, B., and
H. Song, "MPLS Data Plane Encapsulation for In Situ OAM
Data", Work in Progress, Internet-Draft, draft-gandhi-
mpls-ioam-10, 10 March 2023,
<https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-
ioam-10>.
[PROOF-OF-TRANSIT]
Brockners, F., Ed., Bhandari, S., Ed., Mizrahi, T., Ed.,
Dara, S., and S. Youell, "Proof of Transit", Work in
Progress, Internet-Draft, draft-ietf-sfc-proof-of-transit-
08, 31 October 2020,
<https://datatracker.ietf.org/doc/html/draft-ietf-sfc-
proof-of-transit-08>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[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>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
[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>.
[RFC8039] Shpiner, A., Tse, R., Schelp, C., and T. Mizrahi,
"Multipath Time Synchronization", RFC 8039,
DOI 10.17487/RFC8039, December 2016,
<https://www.rfc-editor.org/info/rfc8039>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/info/rfc8799>.
[RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Sundblad, "Network Time Security for the Network Time
Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
<https://www.rfc-editor.org/info/rfc8915>.
[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
"Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/info/rfc8926>.
[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>.
[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, November 2022,
<https://www.rfc-editor.org/info/rfc9322>.
[RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T.
Mizrahi, "In Situ Operations, Administration, and
Maintenance (IOAM) Direct Exporting", RFC 9326,
DOI 10.17487/RFC9326, November 2022,
<https://www.rfc-editor.org/info/rfc9326>.
[RFC9359] Min, X., Mirsky, G., and L. Bo, "Echo Request/Reply for
Enabled In Situ OAM (IOAM) Capabilities", RFC 9359,
DOI 10.17487/RFC9359, April 2023,
<https://www.rfc-editor.org/info/rfc9359>.
[VXLAN-GPE]
Maino, F., Ed., Kreeger, L., Ed., and U. Elzur, Ed.,
"Generic Protocol Extension for VXLAN (VXLAN-GPE)", Work
in Progress, Internet-Draft, draft-ietf-nvo3-vxlan-gpe-12,
22 September 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-nvo3-vxlan-gpe-12>.
The authors would like to thank Tal Mizrahi, Eric Vyncke, Nalini Elkins, Srihari Raghavan, Ranganathan T S, Barak Gafni, Karthik Babu Harichandra Babu, Akshaya Nadahalli, LJ Wobker, Erik Nordmark, Vengada Prasad Govindan, Andrew Yourtchenko, Aviv Kfir, Tianran Zhou, Zhenbin (Robin), Joe Clarke, Al Morton, Tom Herbet, Haoyu Song, and Mickey Spiegel for the comments and advice on IOAM.
著者は、Tal Mizrahi、Eric Vyncke、Nalini Elkins、Srihari Raghavan、Ranganathan T S、Barak Gafni、Karthik Babu Harichandra Babu、Akshaya Nadahalli、LJ Wobker、Erik Nordmark、Vengada Prasad Govindan、Andew、Andew、Anderik、、Zhenbin（Robin）、Joe Clarke、Al Morton、Tom Herbet、Haoyu Song、Mickey Spiegelについてのコメントとアドバイスについて。
Frank Brockners (editor)
Cisco Systems, Inc.
Hansaallee 249, 3rd Floor
40549 DUESSELDORF
Germany
Email: fbrockne@cisco.com
Shwetha Bhandari (editor)
Thoughtspot
3rd Floor, Indiqube Orion
Garden Layout, HSR Layout
24th Main Rd
Bangalore 560 102
KARNATAKA
India
Email: shwetha.bhandari@thoughtspot.com
Daniel Bernier
Bell Canada
Canada
Email: daniel.bernier@bell.ca
Tal Mizrahi (editor)
Huawei
8-2 Matam
Haifa 3190501
Israel
Email: tal.mizrahi.phd@gmail.com