[要約] RFC 9359 は、IOAM-Domain内で使用されるエコーリクエスト/リプライメカニズムのための汎用フォーマットを説明しており、IOAMエンカプセレーティングノードが各IOAMトランジットおよびIOAMデカプセレーティングノードの有効なIOAM機能を発見することを可能にします。この汎用フォーマットは、IPv6、MPLS、Service Function Chain（SFC）、およびBit Index Explicit Replication（BIER）などのさまざまなデータプレーンと共に使用することを意図しています。
Internet Engineering Task Force (IETF) X. Min
Request for Comments: 9359 ZTE Corp.
Category: Standards Track G. Mirsky
ISSN: 2070-1721 Ericsson
L. Bo
China Telecom
April 2023
This document describes a generic format for use in echo request/ reply mechanisms, which can be used within an IOAM-Domain, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. The generic format is intended to be used with a variety of data planes such as IPv6, MPLS, Service Function Chain (SFC), and Bit Index Explicit Replication (BIER).
このドキュメントでは、IOAMドメイン内で使用できるエコーリクエスト/返信メカニズムで使用するための一般的な形式について説明します。これにより、IOAMカプセル化ノードが各iOAMトランジットの有効化されたiOAM機能とIOAMの脱カプセル化ノードの有効なiOAM機能を発見できます。一般的な形式は、IPv6、MPLS、サービス関数チェーン（SFC）、ビットインデックス明示的複製（BIER）などのさまざまなデータプレーンで使用することを目的としています。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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 Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc9359.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9359で取得できます。
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
2.1. Requirements Language
2.2. Abbreviations
3. IOAM Capabilities Formats
3.1. IOAM Capabilities Query Container
3.2. IOAM Capabilities Response Container
3.2.1. IOAM Pre-allocated Tracing Capabilities Object
3.2.2. IOAM Incremental Tracing Capabilities Object
3.2.3. IOAM Proof of Transit Capabilities Object
3.2.4. IOAM Edge-to-Edge Capabilities Object
3.2.5. IOAM DEX Capabilities Object
3.2.6. IOAM End-of-Domain Object
4. Operational Guide
5. IANA Considerations
5.1. IOAM SoP Capability Registry
5.2. IOAM TSF Capability Registry
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses
In situ Operations, Administration, and Maintenance (IOAM) ([RFC9197] [RFC9326]) defines data fields that record OAM information within the packet while the packet traverses a particular network domain, called an "IOAM-Domain". IOAM can complement or replace other OAM mechanisms, such as ICMP or other types of probe packets.
in situ操作、管理、およびメンテナンス（IOAM）（[RFC9197] [RFC9326]）は、パケットが「IOAMドメイン」と呼ばれる特定のネットワークドメインを横断する一方で、パケット内でOAM情報を記録するデータフィールドを定義します。IOAMは、ICMPや他のタイプのプローブパケットなど、他のOAMメカニズムを補完または交換できます。
As specified in [RFC9197], within the IOAM-Domain, the IOAM data may be updated by network nodes that the packet traverses. The device that adds an IOAM header to the packet is called an "IOAM encapsulating node". In contrast, the device that removes an IOAM header is referred to as an "IOAM decapsulating node". Nodes within the domain that are aware of IOAM data and that read, write, and/or process IOAM data are called "IOAM transit nodes". IOAM encapsulating or decapsulating nodes can also serve as IOAM transit nodes at the same time. IOAM encapsulating or decapsulating nodes are also referred to as IOAM-Domain "edge devices", which can be hosts or network devices. [RFC9197] defines four IOAM option types, and [RFC9326] introduces a new IOAM option type called the "Direct Export (DEX) Option-Type", which is different from the other four IOAM option types defined in [RFC9197] regarding how to collect the operational and telemetry information defined in [RFC9197].
[RFC9197]で指定されているように、IOAMドメイン内で、IOAMデータは、パケットが横断するネットワークノードによって更新される場合があります。IOAMヘッダーをパケットに追加するデバイスは、「IOAMカプセル化ノード」と呼ばれます。対照的に、IOAMヘッダーを削除するデバイスは、「IOAM脱カプセンティングノード」と呼ばれます。IOAMデータを認識し、読み取り、書き込み、および/またはIOAMデータを処理するドメイン内のノードは、「IOAMトランジットノード」と呼ばれます。IOAMは、ノードをカプセル化または脱カプセル化することも、同時にIOAMトランジットノードとして機能する可能性があります。ノードのカプセル化または脱カプセル化ノードは、ホストまたはネットワークデバイスである可能性のあるIOAMドメイン「エッジデバイス」とも呼ばれます。[RFC9197]は4つのIOAMオプションタイプを定義し、[RFC9326]は「Direct Export（DEX）オプションタイプ」と呼ばれる新しいIOAMオプションタイプを導入します。[RFC9197]で定義されている運用およびテレメトリー情報を収集します。
As specified in [RFC9197], IOAM is focused on "limited domains" as defined in [RFC8799]. In a limited domain, a control entity that has control over every IOAM device may be deployed. If that's the case, the control entity can provision both the explicit transport path and the IOAM header applied to the data packet at every IOAM encapsulating node.
[RFC9197]で指定されているように、IOAMは[RFC8799]で定義されている「限定ドメイン」に焦点を当てています。限られたドメインでは、すべてのIOAMデバイスを制御する制御エンティティが展開される場合があります。その場合、制御エンティティは、明示的な輸送パスと、すべてのIOAMカプセル化ノードでデータパケットに適用されるIOAMヘッダーの両方を提供できます。
In a case when a control entity that has control over every IOAM device is not deployed in the IOAM-Domain, the IOAM encapsulating node needs to discover the enabled IOAM capabilities at the IOAM transit and decapsulating nodes: for example, what types of IOAM tracing data can be added or exported by the transit nodes along the transport path of the data packet IOAM is applied to. The IOAM encapsulating node can then add the correct IOAM header to the data packet according to the discovered IOAM capabilities. Specifically, the IOAM encapsulating node first identifies the types and lengths of IOAM options included in the IOAM data fields according to the discovered IOAM capabilities. Then the IOAM encapsulating node can add the IOAM header to the data packet based on the identified types and lengths of IOAM options included in the IOAM data fields. The IOAM encapsulating node may use NETCONF/YANG or IGP to discover these IOAM capabilities. However, NETCONF/YANG or IGP has some limitations:
すべてのIOAMデバイスを制御する制御エンティティがiOAMドメインに展開されていない場合、IOAMカプセル化ノードは、IOAMトランジットおよび脱カプセンティングノードで有効なIOAM機能を発見する必要があります。たとえば、どのタイプのIOAMトレースデータパケットIOAMの輸送パスに沿ったトランジットノードによってデータを追加またはエクスポートできます。IOAMカプセル化ノードは、発見されたIOAM機能に従って、正しいIOAMヘッダーをデータパケットに追加できます。具体的には、IOAMカプセル化ノードは、最初に、発見されたIOAM機能に従ってIOAMデータフィールドに含まれるIOAMオプションのタイプと長さを識別します。次に、IOAMのカプセル化ノードは、IOAMデータフィールドに含まれるIOAMオプションの識別されたタイプと長さに基づいて、IOAMヘッダーをデータパケットに追加できます。IOAMのカプセル化ノードは、NetConf/YangまたはIGPを使用してこれらのIOAM機能を発見する場合があります。ただし、NetConf/YangまたはIGPにはいくつかの制限があります。
* When NETCONF/YANG is used in this scenario, each IOAM encapsulating node (including the host when it takes the role of an IOAM encapsulating node) needs to implement a NETCONF Client, and each IOAM transit and IOAM decapsulating node (including the host when it takes the role of an IOAM decapsulating node) needs to implement a NETCONF Server, so complexity can be an issue. Furthermore, each IOAM encapsulating node needs to establish a NETCONF Connection with each IOAM transit and IOAM decapsulating node, so scalability can be an issue.
* このシナリオでNetConf/Yangを使用する場合、各iOAMカプセル化ノード（ホストを含むIOAMカプセル化ノードの役割を含む）は、NetConfクライアントを実装する必要があります。NetConfサーバーを実装するためには、IOAM脱カプセンティングノードの役割を取得するため、複雑さが問題になる可能性があります。さらに、各IOAMカプセル化ノードは、各IOAMトランジットおよびIOAM脱カプセンティングノードとのネットコン接続を確立する必要があるため、スケーラビリティが問題になる可能性があります。
* When IGP is used in this scenario, the IGP and IOAM-Domains don't always have the same coverage. For example, when the IOAM encapsulating node or the IOAM decapsulating node is a host, the availability can be an issue. Furthermore, it might be too challenging to reflect enabled IOAM capabilities at the IOAM transit and IOAM decapsulating node if these are controlled by a local policy depending on the identity of the IOAM encapsulating node.
* このシナリオでIGPを使用する場合、IGPとIOAMドメインは常に同じカバレッジを持っているわけではありません。たとえば、IOAMカプセル化ノードまたはIOAM脱カプセンティングノードがホストである場合、可用性が問題になる可能性があります。さらに、IOAMトランジットおよびIOAM脱カプセンティングノードで有効なIOAM機能を反映するにはあまりにも困難である可能性があります。
This document specifies formats and objects that can be used in the extension of echo request/reply mechanisms used in IPv6 (including Segment Routing over IPv6 (SRv6) data plane), MPLS (including Segment Routing over MPLS (SR-MPLS) data plane), Service Function Chain (SFC), and Bit Index Explicit Replication (BIER) environments, which can be used within the IOAM-Domain, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node.
このドキュメントは、IPv6（IPv6（SRV6）データプレーンを介したセグメントルーティングを含む）、MPLS（MPLS（SR-MPLS）データプレーンを介したセグメントルーティングを含む）で使用されるエコー要求/返信メカニズムの拡張で使用できる形式とオブジェクトを指定します。、サービス関数チェーン（SFC）、およびビットインデックス明示的複製（BIER）環境。これはiOAMドメイン内で使用できるため、IOAMカプセル化ノードが各iOAMトランジットの有効なiOAM機能とIOAM脱カプセンシングノードの有効なiOAM機能を発見できるようにします。
The following documents contain references to the echo request/reply mechanisms used in IPv6 (including SRv6), MPLS (including SR-MPLS), SFC, and BIER environments:
以下のドキュメントには、IPv6（SRV6を含む）、MPLS（SR-MPLSを含む）、SFC、およびビア環境で使用されるエコー要求/返信メカニズムへの参照が含まれています。
* "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" [RFC4443]
* 「インターネット制御メッセージプロトコル（ICMPV6）インターネットプロトコルバージョン6（IPv6）仕様」[RFC4443]
* "IPv6 Node Information Queries" [RFC4620]
* 「IPv6ノード情報クエリ」[RFC4620]
* "Extended ICMP to Support Multi-Part Messages" [RFC4884]
* 「マルチパートメッセージをサポートするためにICMPを拡張」[RFC4884]
* "PROBE: A Utility for Probing Interfaces" [RFC8335]
* 「プローブ：インターフェイスの調査のユーティリティ」[RFC8335]
* "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures" [RFC8029]
* 「マルチプロトコルラベルの切り替え（MPLS）データプレーン障害の検出」[RFC8029]
* "Active OAM for Service Function Chaining (SFC)" [OAM-for-SFC]
* 「サービス機能チェーンのアクティブOAM（SFC）」[OAM-For-SFC]
* "BIER Ping and Trace" [BIER-PING]
* 「Bier ping and trace」[Bier-ping]
It is expected that the specification of the instantiation of each of these extensions will be done in the form of an RFC jointly designed by the working group that develops or maintains the echo request/ reply protocol and the IETF IP Performance Measurement (IPPM) Working Group.
これらの各拡張機能のインスタンス化の仕様は、エコーリクエスト/返信プロトコルとIETF IPパフォーマンス測定（IPPM）ワーキンググループを開発または維持するワーキンググループが共同で設計したRFCの形で行われることが予想されます。。
In this document, note that the echo request/reply mechanism used in IPv6 does not mean ICMPv6 Echo Request/Reply [RFC4443] but does mean IPv6 Node Information Query/Reply [RFC4620].
このドキュメントでは、IPv6で使用されるエコー要求/返信メカニズムは、ICMPV6エコーリクエスト/応答[RFC4443]を意味するのではなく、IPv6ノード情報クエリ/返信[RFC4620]を意味することに注意してください。
Fate sharing is a common requirement for all kinds of active OAM packets, including echo requests. In this document, that means an echo request is required to traverse the path of an IOAM data packet. This requirement can be achieved by, e.g., applying the same explicit path or ECMP processing to both echo request and IOAM data packets. Specifically, the same ECMP processing can be applied to both echo request and IOAM data packets, by populating the same value or values in any ECMP affecting fields of the packets.
運命共有は、エコーリクエストを含むあらゆる種類のアクティブなOAMパケットの一般的な要件です。このドキュメントでは、IOAMデータパケットのパスを横断するためにエコー要求が必要であることを意味します。この要件は、たとえば、同じ明示的なパスまたはECMP処理をECHOリクエストとIOAMデータパケットの両方に適用することによって達成できます。具体的には、パケットのフィールドに影響を与えるECMPの同じ値または値を入力することにより、同じECMP処理をEcho RequestとIOAMデータパケットの両方に適用できます。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
BIER:
ビア：
Bit Index Explicit Replication
ビットインデックス明示的な複製
BGP:
BGP：
Border Gateway Protocol
ボーダーゲートウェイプロトコル
DEX:
デックス：
Direct Export
直接輸出
ECMP:
ECMP：
Equal-Cost Multipath
等しいコストマルチパス
E2E:
E2E：
Edge to Edge
隅々まで
ICMP:
ICMP：
Internet Control Message Protocol
インターネット制御メッセージプロトコル
IGP:
IGP：
Interior Gateway Protocol
インテリアゲートウェイプロトコル
IOAM:
ioam：
In situ Operations, Administration, and Maintenance
in situ操作、管理、およびメンテナンス
LSP:
LSP：
Label Switched Path
ラベルスイッチ付きパス
MPLS:
MPLS：
Multiprotocol Label Switching
マルチプロトコルラベルスイッチング
MTU:
MTU：
Maximum Transmission Unit
最大送信ユニット
NETCONF:
NetConf：
Network Configuration Protocol
ネットワーク構成プロトコル
NTP:
NTP：
Network Time Protocol
ネットワークタイムプロトコル
OAM:
OAM：
Operations, Administration, and Maintenance
運用、管理、およびメンテナンス
PCEP:
PCEP：
Path Computation Element Communication Protocol
パス計算要素通信プロトコル
POSIX:
POSIX：
Portable Operating System Interface
ポータブルオペレーティングシステムインターフェイス
POT:
ポット：
Proof of Transit
輸送の証明
PTP:
PTP：
Precision Time Protocol
精密時間プロトコル
SoP:
SOP：
Size of POT
ポットのサイズ
SR-MPLS:
sr-mpls：
Segment Routing over MPLS
MPLS上のセグメントルーティング
SRv6:
SRV6：
Segment Routing over IPv6
IPv6を介したセグメントルーティング
SFC:
SFC：
Service Function Chain
サービス機能チェーン
TTL:
TTL：
Time to Live (this is also the Hop Limit field in the IPv6 header)
ライブの時間（これはIPv6ヘッダーのホップリミットフィールドでもあります）
TSF:
TSF：
TimeStamp Format
タイムスタンプ形式
For echo requests, the IOAM Capabilities Query uses a container that has the following format:
エコーリクエストの場合、IOAM機能クエリは、次の形式を持つコンテナを使用します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IOAM Capabilities Query Container Header .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. List of IOAM Namespace-IDs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IOAM Capabilities Query Container of an Echo Request
図1：IOAM機能エコーリクエストのクエリコンテナ
When this container is present in the echo request sent by an IOAM encapsulating node, the IOAM encapsulating node requests that the receiving node reply with its enabled IOAM capabilities. If there is no IOAM capability to be reported by the receiving node, then this container MUST be ignored by the receiving node. This means the receiving node MUST send an echo reply without IOAM capabilities or no echo reply, in the light of whether the echo request includes containers other than the IOAM Capabilities Query Container. A list of IOAM Namespace-IDs (one or more Namespace-IDs) MUST be included in this container in the echo request; if present, the Default-Namespace-ID 0x0000 MUST be placed at the beginning of the list of IOAM Namespace-IDs. The IOAM encapsulating node requests only the enabled IOAM capabilities that match one of the Namespace-IDs. Inclusion of the Default-Namespace-ID 0x0000 elicits replies only for capabilities that are configured with the Default-Namespace-ID 0x0000. The Namespace-ID has the same definition as what's specified in Section 4.3 of [RFC9197].
このコンテナがIOAMカプセル化ノードによって送信されたエコー要求に存在する場合、IOAMカプセル化ノードは、有効化されたIOAM機能を使用して受信ノードが応答することを要求します。受信ノードによって報告されるIOAM機能がない場合、このコンテナは受信ノードで無視する必要があります。これは、Echo要求にIOAM機能クエリコンテナ以外のコンテナが含まれているかどうかに照らして、受信ノードがIOAM機能またはエコー応答なしでエコー応答を送信する必要があることを意味します。IOAM Namespace-ID（1つ以上のNamespace-ID）のリストをECHO要求にこのコンテナに含める必要があります。存在する場合、デフォルトのnamespace-id 0x0000は、ioam namespace-idsのリストの先頭に配置する必要があります。IOAMカプセル化ノードは、名前空間IDの1つに一致する有効なIOAM機能のみを要求します。Default-NamesPace-ID 0x0000を誘発するedyは、デフォルトのnamespace-id 0x0000で構成されている機能に対してのみ回答します。名前空間IDは、[RFC9197]のセクション4.3で指定されているものと同じ定義を持っています。
The IOAM Capabilities Query Container has a container header that is used to identify the type and, optionally, the length of the container payload. The container payload (List of IOAM Namespace-IDs) is zero-padded to align with a 4-octet boundary. Since the Default-Namespace-ID 0x0000 is mandated to appear first in the list, any other occurrences of 0x0000 MUST be disregarded.
IOAM機能クエリコンテナには、タイプを識別するために使用されるコンテナヘッダーがあり、オプションではコンテナペイロードの長さがあります。コンテナペイロード（IOAM NameSpace-IDのリスト）は、4オクテットの境界に合わせてゼロパッドされています。デフォルトのnamespace-id 0x0000はリストに最初に表示されることが義務付けられているため、0x0000のその他の発生は無視する必要があります。
The length, structure, and definition of the IOAM Capabilities Query Container Header depend on the specific deployment environment.
IOAM機能の長さ、構造、および定義クエリコンテナヘッダーは、特定の展開環境に依存します。
For echo replies, the IOAM Capabilities Response uses a container that has the following format:
エコー応答の場合、IOAM機能応答は、次の形式を持つコンテナを使用します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IOAM Capabilities Response Container Header .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. List of IOAM Capabilities Objects .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IOAM Capabilities Response Container for an Echo Reply
図2：エコー応答用のioam機能応答コンテナ
When this container is present in the echo reply sent by an IOAM transit node or IOAM decapsulating node, the IOAM function is enabled at this node, and this container contains the enabled IOAM capabilities of the sender. A list of IOAM capabilities objects (one or more objects) that contains the enabled IOAM capabilities MUST be included in this container of the echo reply unless the sender encounters an error (e.g., no matched Namespace-ID).
このコンテナがIOAMトランジットノードまたはIOAM脱カプセンティングノードによって送信されたエコー応答に存在する場合、iOAM関数はこのノードで有効になり、このコンテナには送信者の有効化されたiOAM機能が含まれています。有効なIOAM機能を含むIOAM機能オブジェクト（1つまたは複数のオブジェクト）のリストは、送信者がエラーに遭遇しない限り（例えば、一致した名前空間IDなし）、エコー応答のこのコンテナに含める必要があります。
The IOAM Capabilities Response Container has a container header that is used to identify the type and, optionally, the length of the container payload. The container header MUST be defined such that it falls on a 4-octet boundary.
IOAM機能応答コンテナには、タイプを識別するために使用されるコンテナヘッダーがあり、オプションではコンテナペイロードの長さがあります。コンテナヘッダーは、4オクテットの境界に該当するように定義する必要があります。
The length, structure, and definition of the IOAM Capabilities Response Container Header depends on the specific deployment environment.
IOAM機能応答コンテナヘッダーの長さ、構造、および定義は、特定の展開環境に依存します。
Based on the IOAM data fields defined in [RFC9197] and [RFC9326], six types of objects are defined in this document. The same type of object MAY be present in the IOAM Capabilities Response Container more than once, only if listed with a different Namespace-ID.
[RFC9197]および[RFC9326]で定義されているIOAMデータフィールドに基づいて、このドキュメントで6種類のオブジェクトが定義されています。同じタイプのオブジェクトが、IOAM機能応答コンテナに、別の名前空間IDでリストされている場合にのみ、複数回応答コンテナに存在する場合があります。
Similar to the container, each object has an object header that is used to identify the type and length of the object payload. The object payload MUST be defined such that it falls on a 4-octet boundary.
コンテナと同様に、各オブジェクトには、オブジェクトペイロードのタイプと長さを識別するために使用されるオブジェクトヘッダーがあります。オブジェクトペイロードは、4オクテットの境界に該当するように定義する必要があります。
The length, structure, and definition of the object header depends on the specific deployment environment.
オブジェクトヘッダーの長さ、構造、および定義は、特定の展開環境に依存します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IOAM Pre-allocated Tracing Capabilities Object Header .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved |W|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | Ingress_MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress_if_id (short or wide format) ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IOAM Pre-allocated Tracing Capabilities Object
図3：IOAM事前に割り当てられたトレース機能オブジェクト
When the IOAM Pre-allocated Tracing Capabilities Object is present in the IOAM Capabilities Response Container, the sending node is an IOAM transit node, and the IOAM pre-allocated tracing function is enabled at this IOAM transit node.
IOAM事前に割り当てられたトレース機能オブジェクトがIOAM機能応答コンテナに存在する場合、送信ノードはIOAMトランジットノードであり、このIOAMトランジットノードでIOAM事前に割り当てられたトレース機能が有効になります。
The IOAM-Trace-Type field has the same definition as what's specified in Section 4.4 of [RFC9197].
IOAM-TRACEタイプのフィールドは、[RFC9197]のセクション4.4で指定されているものと同じ定義を持っています。
The Reserved field MUST be zeroed on transmission and ignored on receipt.
予約済みのフィールドは、送信時にゼロになり、受領時に無視する必要があります。
The W flag indicates whether Ingress_if_id is in short or wide format. The W-bit is set if the Ingress_if_id is in wide format. The W-bit is clear if the Ingress_if_id is in short format.
wフラグは、ingress_if_idが略しているのか幅の広い形式であるかを示します。ingress_if_idがワイド形式の場合、Wビットは設定されます。ingress_if_idが短い形式の場合、Wビットは明確です。
The Namespace-ID field has the same definition as what's specified in Section 4.3 of [RFC9197]. It MUST be one of the Namespace-IDs listed in the IOAM Capabilities Query Object of the echo request.
名前空間IDフィールドは、[RFC9197]のセクション4.3で指定されているものと同じ定義を持っています。これは、ECHOリクエストのiOAM機能クエリオブジェクトにリストされている名前空間IDの1つでなければなりません。
The Ingress_MTU field has 16 bits and specifies the MTU (in octets) of the ingress interface from which the sending node received the echo request.
ingress_mtuフィールドには16ビットがあり、送信ノードがエコーリクエストを受信したイングレスインターフェイスのMTU（オクテット）を指定します。
The Ingress_if_id field has 16 bits (in short format) or 32 bits (in wide format) and specifies the identifier of the ingress interface from which the sending node received the echo request. If the W-bit is cleared, the Ingress_if_id field has 16 bits; then the 16 bits following the Ingress_if_id field are reserved for future use, MUST be set to zero, and MUST be ignored when non-zero.
ingress_if_idフィールドには16ビット（短い形式）または32ビット（ワイド形式）があり、送信ノードがエコーリクエストを受信したイングレスインターフェイスの識別子を指定します。w-bitがクリアされている場合、ingress_if_idフィールドには16ビットがあります。その後、ingress_if_idフィールドに続く16ビットは将来の使用のために予約され、ゼロに設定する必要があり、ゼロ以外の場合は無視する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IOAM Incremental Tracing Capabilities Object Header .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved |W|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | Ingress_MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress_if_id (short or wide format) ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IOAM Incremental Tracing Capabilities Object
図4：IOAM増分トレース機能オブジェクト
When the IOAM Incremental Tracing Capabilities Object is present in the IOAM Capabilities Response Container, the sending node is an IOAM transit node, and the IOAM incremental tracing function is enabled at this IOAM transit node.
IOAMのインクリメンタルトレース機能オブジェクトがIOAM機能応答コンテナに存在する場合、送信ノードはIOAMトランジットノードであり、このIOAMトランジットノードでIOAM増分トレース機能が有効になっています。
The IOAM-Trace-Type field has the same definition as what's specified in Section 4.4 of [RFC9197].
IOAM-TRACEタイプのフィールドは、[RFC9197]のセクション4.4で指定されているものと同じ定義を持っています。
The Reserved field MUST be zeroed on transmission and ignored on receipt.
予約済みのフィールドは、送信時にゼロになり、受領時に無視する必要があります。
The W flag indicates whether Ingress_if_id is in short or wide format. The W-bit is set if the Ingress_if_id is in wide format. The W-bit is clear if the Ingress_if_id is in short format.
wフラグは、ingress_if_idが略しているのか幅の広い形式であるかを示します。ingress_if_idがワイド形式の場合、Wビットは設定されます。ingress_if_idが短い形式の場合、Wビットは明確です。
The Namespace-ID field has the same definition as what's specified in Section 4.3 of [RFC9197]. It MUST be one of the Namespace-IDs listed in the IOAM Capabilities Query Object of the echo request.
名前空間IDフィールドは、[RFC9197]のセクション4.3で指定されているものと同じ定義を持っています。これは、ECHOリクエストのiOAM機能クエリオブジェクトにリストされている名前空間IDの1つでなければなりません。
The Ingress_MTU field has 16 bits and specifies the MTU (in octets) of the ingress interface from which the sending node received the echo request.
ingress_mtuフィールドには16ビットがあり、送信ノードがエコーリクエストを受信したイングレスインターフェイスのMTU（オクテット）を指定します。
The Ingress_if_id field has 16 bits (in short format) or 32 bits (in wide format) and specifies the identifier of the ingress interface from which the sending node received the echo request. If the W-bit is cleared, the Ingress_if_id field has 16 bits; then the 16 bits following the Ingress_if_id field are reserved for future use, MUST be set to zero, and MUST be ignored when non-zero.
ingress_if_idフィールドには16ビット（短い形式）または32ビット（ワイド形式）があり、送信ノードがエコーリクエストを受信したイングレスインターフェイスの識別子を指定します。w-bitがクリアされている場合、ingress_if_idフィールドには16ビットがあります。その後、ingress_if_idフィールドに続く16ビットは将来の使用のために予約され、ゼロに設定する必要があり、ゼロ以外の場合は無視する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IOAM Proof of Transit Capabilities Object Header .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | IOAM-POT-Type |SoP| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IOAM Proof of Transit Capabilities Object
図5：IOAMトランジット機能の証明オブジェクト
When the IOAM Proof of Transit Capabilities Object is present in the IOAM Capabilities Response Container, the sending node is an IOAM transit node and the IOAM Proof of Transit function is enabled at this IOAM transit node.
IOAMのトランジット機能の証明オブジェクトがIOAM機能応答コンテナに存在する場合、送信ノードはIOAMトランジットノードであり、このIOAMトランジットノードでIOAMトランジット機能の証明が有効になっています。
The Namespace-ID field has the same definition as what's specified in Section 4.3 of [RFC9197]. It MUST be one of the Namespace-IDs listed in the IOAM Capabilities Query Object of the echo request.
名前空間IDフィールドは、[RFC9197]のセクション4.3で指定されているものと同じ定義を持っています。これは、ECHOリクエストのiOAM機能クエリオブジェクトにリストされている名前空間IDの1つでなければなりません。
The IOAM-POT-Type field has the same definition as what's specified in Section 4.5 of [RFC9197].
IOAM-POTタイプフィールドは、[RFC9197]のセクション4.5で指定されているものと同じ定義を持っています。
The SoP (Size of POT) field has two bits that indicate the size of "PktID" and "Cumulative" data, which are specified in Section 4.5 of [RFC9197]. This document defines SoP as follows:
SOP（ポットのサイズ）フィールドには、[RFC9197]のセクション4.5で指定されている「PKTID」および「累積」データのサイズを示す2つのビットがあります。このドキュメントは、SOPを次のように定義しています。
0b00:
0B00：
64-bit "PktID" and 64-bit "Cumulative" data
64ビット「PKTID」および64ビットの「累積」データ
0b01~0b11:
0B01〜0B11：
reserved for future standardization
将来の標準化のために予約されています
The Reserved field MUST be zeroed on transmission and ignored on receipt.
予約済みのフィールドは、送信時にゼロになり、受領時に無視する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IOAM Edge-to-Edge Capabilities Object Header .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | IOAM-E2E-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TSF| Reserved | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: IOAM Edge-to-Edge Capabilities Object
図6：IOAMエッジツーエッジ機能オブジェクト
When the IOAM Edge-to-Edge Capabilities Object is present in the IOAM Capabilities Response Container, the sending node is an IOAM decapsulating node and IOAM edge-to-edge function is enabled at this IOAM decapsulating node.
IOAMエッジからエッジの機能オブジェクトがIOAM機能応答コンテナに存在する場合、送信ノードはIOAMの脱カプセンティングノードであり、IOAMエッジツーエッジ関数はこのIOAMの脱カプセンティングノードで有効になります。
The Namespace-ID field has the same definition as what's specified in Section 4.3 of [RFC9197]. It MUST be one of the Namespace-IDs listed in the IOAM Capabilities Query Object of the echo request.
名前空間IDフィールドは、[RFC9197]のセクション4.3で指定されているものと同じ定義を持っています。これは、ECHOリクエストのiOAM機能クエリオブジェクトにリストされている名前空間IDの1つでなければなりません。
The IOAM-E2E-Type field has the same definition as what's specified in Section 4.6 of [RFC9197].
IOAM-E2E型フィールドは、[RFC9197]のセクション4.6で指定されているものと同じ定義を持っています。
The TSF field specifies the timestamp format used by the sending node. Aligned with three possible timestamp formats specified in Section 5 of [RFC9197], this document defines TSF as follows:
TSFフィールドは、送信ノードで使用されるタイムスタンプ形式を指定します。[RFC9197]のセクション5で指定された3つの可能なタイムスタンプ形式と一致して、このドキュメントはTSFを次のように定義します。
0b00:
0B00：
PTP truncated timestamp format
PTPが切り捨てられたタイムスタンプ形式
0b01:
0B01：
NTP 64-bit timestamp format
NTP 64ビットタイムスタンプ形式
0b10:
0B10：
POSIX-based timestamp format
POSIXベースのタイムスタンプ形式
0b11:
0B11：
Reserved for future standardization
将来の標準化のために予約されています
The Reserved field MUST be zeroed on transmission and ignored on receipt.
予約済みのフィールドは、送信時にゼロになり、受領時に無視する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IOAM DEX Capabilities Object Header .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: IOAM DEX Capabilities Object
図7：IOAM DEX機能オブジェクト
When the IOAM DEX Capabilities Object is present in the IOAM Capabilities Response Container, the sending node is an IOAM transit node and the IOAM direct exporting function is enabled at this IOAM transit node.
IOAM DEX機能オブジェクトがIOAM機能応答コンテナに存在する場合、送信ノードはIOAMトランジットノードであり、このIOAMトランジットノードでIOAM直接エクスポート機能が有効になっています。
The IOAM-Trace-Type field has the same definition as what's specified in Section 3.2 of [RFC9326].
IOAM-TRACEタイプのフィールドは、[RFC9326]のセクション3.2で指定されているものと同じ定義を持っています。
The Namespace-ID field has the same definition as what's specified in Section 4.3 of [RFC9197]. It MUST be one of the Namespace-IDs listed in the IOAM Capabilities Query Object of the echo request.
名前空間IDフィールドは、[RFC9197]のセクション4.3で指定されているものと同じ定義を持っています。これは、ECHOリクエストのiOAM機能クエリオブジェクトにリストされている名前空間IDの1つでなければなりません。
The Reserved field MUST be zeroed on transmission and ignored on receipt.
予約済みのフィールドは、送信時にゼロになり、受領時に無視する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IOAM End-of-Domain Object Header .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: IOAM End-of-Domain Object
図8：IOAMドメインの終了オブジェクト
When the IOAM End-of-Domain Object is present in the IOAM Capabilities Response Container, the sending node is an IOAM decapsulating node. Unless the IOAM Edge-to-Edge Capabilities Object is present, which also indicates that the sending node is an IOAM decapsulating node, the IOAM End-of-Domain Object MUST be present in the IOAM Capabilities Response Container sent by an IOAM decapsulating node. When the IOAM edge-to-edge function is enabled at the IOAM decapsulating node, including only the IOAM Edge-to-Edge Capabilities Object, not the IOAM End-of-Domain Object, is RECOMMENDED.
IOAM domainの終了オブジェクトがIOAM機能応答コンテナに存在する場合、送信ノードはIOAM脱カプセンティングノードです。IOAMのエッジからエッジの機能オブジェクトが存在しない限り、送信ノードがIOAM脱カプセンティングノードであることを示していない場合、IOAM機能の織り縁止めノードによって送信されたIOAM機能応答コンテナにIOAM domainオブジェクトが存在する必要があります。IOAMエッジツーエッジの機能オブジェクトのみを含むIOAMの脱カプセンシングノードでIOAMエッジツーエッジ関数が有効になっている場合、IOAMドメインの終了オブジェクトではなく、推奨されます。
The Namespace-ID field has the same definition as what's specified in Section 4.3 of [RFC9197]. It MUST be one of the Namespace-IDs listed in the IOAM Capabilities Query Container.
名前空間IDフィールドは、[RFC9197]のセクション4.3で指定されているものと同じ定義を持っています。IOAM機能クエリコンテナにリストされている名前空間IDの1つでなければなりません。
Reserved field MUST be zeroed on transmission and ignored on receipt.
予約済みフィールドは、送信時にゼロになり、受領時に無視する必要があります。
Once the IOAM encapsulating node is triggered to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node, the IOAM encapsulating node will send echo requests that include the IOAM Capabilities Query Container as follows:
IOAMのカプセル化ノードがトリガーされると、各iOAMトランジットとIOAMの脱カプセンティングノードの有効なIOAM機能が発見されると、IOAMカプセル化ノードは、次のようにIOAM機能クエリコンテナを含むエコーリクエストを送信します。
* First, with TTL equal to 1 to reach the closest node (which may or may not be an IOAM transit node).
* まず、TTLが1に等しく、最も近いノードに到達します（IOAMトランジットノードである場合とそうでない場合があります）。
* Then, with TTL equal to 2 to reach the second-nearest node (which also may or may not be an IOAM transit node).
* 次に、TTLが2に等しく、2番目に非控えめなノードに到達します（IOAMトランジットノードである場合とそうでない場合もあります）。
* Then, further increasing by 1 the TTL every time the IOAM encapsulating node sends a new echo request, until the IOAM encapsulating node receives an echo reply sent by the IOAM decapsulating node (which contains the IOAM Capabilities Response Container including the IOAM Edge-to-Edge Capabilities Object or the IOAM End-of-Domain Object).
* 次に、IOAMがカプセル化するノードが新しいエコー要求を送信するたびに、さらに増加します。IOAMカプセル化ノードがIOAM脱カプセンシングノード（IOAM機能応答コンテナを含むIOAM機能応答コンテナが含まれるIOAMの脱カプセル化ノード）によって送信されるエコー応答が受信されるまで、新しいエコー要求が送信されます。エッジ機能オブジェクトまたはIOAM domainオブジェクト）。
As a result, the echo requests sent by the IOAM encapsulating node will reach all nodes one by one along the transport path of IOAM data packet.
その結果、IOAMカプセル化ノードによって送信されたエコー要求は、IOAMデータパケットの輸送パスに沿ってすべてのノードに1つずつ到達します。
Alternatively, if the IOAM encapsulating node knows precisely all the IOAM transit and IOAM decapsulating nodes beforehand, once the IOAM encapsulating node is triggered to discover the enabled IOAM capabilities, it can send an echo request to each IOAM transit and IOAM decapsulating node directly, without TTL expiration.
代わりに、IOAMカプセル化ノードがすべてのIOAMトランジットとIOAMの脱カプセンシングノードを事前に正確に知っている場合、IOAMのカプセル化ノードがトリガーされると、IOAM機能を発見するようにトリガーされた場合、IOAMトランジットとIOAMの脱カプセル化ノードに直接エコーリクエストを送信できます。TTLの有効期限。
The IOAM encapsulating node may be triggered by the device administrator, the network management system, the network controller, or data traffic. The specific triggering mechanisms are outside the scope of this document.
IOAMカプセル化ノードは、デバイス管理者、ネットワーク管理システム、ネットワークコントローラー、またはデータトラフィックによってトリガーされる場合があります。特定のトリガーメカニズムは、このドキュメントの範囲外です。
Each IOAM transit and IOAM decapsulating node that receives an echo request containing the IOAM Capabilities Query Container will send an echo reply to the IOAM encapsulating node. For the echo reply, there is an IOAM Capabilities Response Container containing one or more Objects. The IOAM Capabilities Query Container of the echo request would be ignored by the receiving node unaware of IOAM.
IOAM機能クエリコンテナを含むエコー要求を受信するIOAMトランジットおよびIOAM脱カプセンティングノードは、IOAMカプセル化ノードへのエコー返信を送信します。エコー応答には、1つ以上のオブジェクトを含むIOAM機能応答コンテナがあります。ECHO要求のIOAM機能クエリコンテナは、IOAMを知らない受信ノードによって無視されます。
Note that the mechanism defined in this document applies to all kinds of IOAM option types, whether the four types of IOAM options defined in [RFC9197] or the DEX type of IOAM option defined in [RFC9326]. Specifically, when applied to the IOAM DEX option, the mechanism allows the IOAM encapsulating node to discover which nodes along the transport path support IOAM direct exporting and which trace data types are supported to be directly exported at these nodes.
このドキュメントで定義されているメカニズムは、[RFC9197]で定義されている4つのタイプのIOAMオプションであろうと、[RFC9326]で定義されたDEXタイプのIOAMオプションにかかわらず、あらゆる種類のIOAMオプションタイプに適用されることに注意してください。具体的には、IOAM DEXオプションに適用すると、メカニズムにより、IOAMカプセル化ノードが輸送パスに沿ったIOAM直接エクスポートをサポートするノードと、これらのノードで直接エクスポートされるようにサポートされているトレースデータ型をサポートすることができます。
IANA has created a registry named "In Situ OAM (IOAM) Capabilities".
IANAは、「In Situ OAM（IOAM）機能」という名前のレジストリを作成しました。
This registry includes the following subregistries:
このレジストリには、次のサブレジストリが含まれています。
* IOAM SoP Capability
* IOAM SOP機能
* IOAM TSF Capability
* IOAM TSF機能
The subsequent subsections detail the registries herein contained.
後続のサブセクションには、ここに含まれるレジストリが詳細に記載されています。
Considering the Containers/Objects defined in this document that would be carried in different types of Echo Request/Reply messages, such as ICMPv6 or LSP Ping, it is intended that the registries for Container/Object Type would be requested in subsequent documents.
このドキュメントで定義されているコンテナ/オブジェクトを、ICMPv6やLSP Pingなどのさまざまなタイプのエコーリクエスト/返信メッセージで携帯することを考慮すると、コンテナ/オブジェクトタイプのレジストリが後続のドキュメントで要求されることを意図しています。
This registry defines four codepoints for the IOAM SoP Capability field for identifying the size of "PktID" and "Cumulative" data as explained in Section 4.5 of [RFC9197].
このレジストリは、[RFC9197]のセクション4.5で説明されているように、「PKTID」データと「累積」データのサイズを識別するためのIOAM SOP機能フィールドの4つのコードポイントを定義します。
A new entry in this registry requires the following fields:
このレジストリの新しいエントリには、次のフィールドが必要です。
* SoP (Size of POT): a 2-bit binary field as defined in Section 3.2.3.
* SOP（ポットのサイズ）：セクション3.2.3で定義されている2ビットバイナリフィールド。
* Description: a terse description of the meaning of this SoP value.
* 説明：このSOP値の意味の簡潔な説明。
The registry initially contains the following value:
レジストリには最初に次の値が含まれています。
+======+=============================================+
| SoP | Description |
+======+=============================================+
| 0b00 | 64-bit "PktID" and 64-bit "Cumulative" data |
+------+---------------------------------------------+
Table 1: SoP and Description
表1：SOPと説明
0b01 - 0b11 are available for assignment via the IETF Review process as per [RFC8126].
0B01-0B11は、[RFC8126]に従って、IETFレビュープロセスを介して割り当て可能です。
This registry defines four codepoints for the IOAM TSF Capability field for identifying the timestamp format as explained in Section 5 of [RFC9197].
このレジストリは、[RFC9197]のセクション5で説明されているように、タイムスタンプ形式を識別するためのIOAM TSF機能フィールドの4つのコードポイントを定義します。
A new entry in this registry requires the following fields:
このレジストリの新しいエントリには、次のフィールドが必要です。
* TSF (TimeStamp Format): a 2-bit binary field as defined in Section 3.2.4.
* TSF（タイムスタンプ形式）：セクション3.2.4で定義されている2ビットバイナリフィールド。
* Description: a terse description of the meaning of this TSF value.
* 説明：このTSF値の意味の簡潔な説明。
The registry initially contains the following values:
レジストリには最初に次の値が含まれています。
+======+================================+
| TSF | Description |
+======+================================+
| 0b00 | PTP Truncated Timestamp Format |
+------+--------------------------------+
| 0b01 | NTP 64-bit Timestamp Format |
+------+--------------------------------+
| 0b10 | POSIX-based Timestamp Format |
+------+--------------------------------+
Table 2: TSF and Description
表2：TSFと説明
0b11 is available for assignment via the IETF Review process as per [RFC8126].
0B11は、[RFC8126]に従って、IETFレビュープロセスを介して割り当て可能です。
Overall, the security needs for IOAM capabilities query mechanisms used in different environments are similar.
全体として、IOAM機能のセキュリティニーズは、さまざまな環境で使用されるメカニズムのクエリメカニズムも似ています。
To avoid potential Denial-of-Service (DoS) attacks, it is RECOMMENDED that implementations apply rate-limiting to incoming echo requests and replies.
潜在的なサービス拒否（DOS）攻撃を回避するには、実装が着信のエコーリクエストと返信にレート制限を適用することをお勧めします。
To protect against unauthorized sources using echo request messages to obtain IOAM Capabilities information, implementations MUST provide a means of checking the source addresses of echo request messages against an access list before accepting the message.
ECHO要求メッセージを使用してIOAM機能情報を取得するために不正なソースから保護するには、メッセージを受け入れる前にアクセスリストに対してECHO要求メッセージのソースアドレスをチェックする手段を提供する必要があります。
A deployment MUST ensure that border-filtering drops inbound echo requests with an IOAM Capabilities Container Header from outside of the domain and that drops outbound echo requests or replies with IOAM Capabilities Headers leaving the domain.
展開は、ドメインの外側からIOAM機能コンテナヘッダーを使用してボーダーフィルタリングがインバウンドエコーリクエストをドロップし、ドメインを離れるIOAM機能ヘッダーでアウトバウンドエコー要求または返信をドロップすることを保証する必要があります。
A deployment MUST support the configuration option to enable or disable the IOAM Capabilities Discovery feature defined in this document. By default, the IOAM Capabilities Discovery feature MUST be disabled.
展開は、このドキュメントで定義されているIOAM機能発見機能を有効または無効にするための構成オプションをサポートする必要があります。デフォルトでは、IOAM機能の発見機能を無効にする必要があります。
The integrity protection on IOAM Capabilities information carried in echo reply messages can be achieved by the underlying transport. For example, if the environment is an IPv6 network, the IP Authentication Header [RFC4302] or IP Encapsulating Security Payload Header [RFC4303] can be used.
Echo Replyメッセージに掲載されたIOAM機能情報の整合性保護は、基礎となる輸送によって実現できます。たとえば、環境がIPv6ネットワークの場合、IP認証ヘッダー[RFC4302]またはセキュリティペイロードヘッダー[RFC4303]をカプセル化するIPを使用できます。
The collected IOAM Capabilities information by queries may be considered confidential. An implementation can use secure underlying transport of echo requests or replies to provide privacy protection. For example, if the environment is an IPv6 network, confidentiality can be achieved by using the IP Encapsulating Security Payload Header [RFC4303].
クエリごとに収集されたIOAM機能情報は、機密と見なされる場合があります。実装では、エコーリクエストまたは返信の安全な基礎となる輸送を使用して、プライバシー保護を提供できます。たとえば、環境がIPv6ネットワークの場合、IPカプセル化セキュリティペイロードヘッダー[RFC4303]を使用して、機密性を達成できます。
An implementation can also directly secure the data carried in echo requests and replies if needed, the specific mechanism on how to secure the data is beyond the scope of this document.
実装は、必要に応じてエコーリクエストと返信で伝達されるデータを直接保護することもできます。データを保護する方法に関する特定のメカニズムは、このドキュメントの範囲を超えています。
An implementation can also check whether the fields in received echo requests and replies strictly conform to the specifications, e.g., whether the list of IOAM Namespace-IDs includes duplicate entries and whether the received Namespace-ID is an operator-assigned or IANA-assigned one, once a check fails, an exception event indicating the checked field should be reported to the management.
実装は、受信したエコーリクエストと返信のフィールドが仕様に厳密に準拠しているかどうかを確認できます。、チェックが失敗したら、チェックされたフィールドを示す例外イベントを管理に報告する必要があります。
Except for what's described above, the security issues discussed in [RFC9197] provide good guidance on implementation of this specification.
上記のことを除いて、[RFC9197]で議論されているセキュリティの問題は、この仕様の実装に関する適切なガイダンスを提供します。
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[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>.
[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>.
[BIER-PING]
Nainar, N. K., Pignataro, C., Akiya, N., Zheng, L., Chen,
M., and G. Mirsky, "BIER Ping and Trace", Work in
Progress, Internet-Draft, draft-ietf-bier-ping-08, 6 March
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
bier-ping-08>.
[OAM-for-SFC]
Mirsky, G., Meng, W., Ao, T., Khasnabish, B., Leung, K.,
and G. Mishra, "Active OAM for Service Function Chaining
(SFC)", Work in Progress, Internet-Draft, draft-ietf-sfc-
multi-layer-oam-23, 23 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-sfc-
multi-layer-oam-23>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC4620] Crawford, M. and B. Haberman, Ed., "IPv6 Node Information
Queries", RFC 4620, DOI 10.17487/RFC4620, August 2006,
<https://www.rfc-editor.org/info/rfc4620>.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884,
DOI 10.17487/RFC4884, April 2007,
<https://www.rfc-editor.org/info/rfc4884>.
[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>.
[RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M.
Boucadair, "PROBE: A Utility for Probing Interfaces",
RFC 8335, DOI 10.17487/RFC8335, February 2018,
<https://www.rfc-editor.org/info/rfc8335>.
[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>.
The authors would like to acknowledge Tianran Zhou, Dhruv Dhody, Frank Brockners, Cheng Li, Gyan Mishra, Marcus Ihlar, Martin Duke, Chris Lonvick, Éric Vyncke, Alvaro Retana, Paul Wouters, Roman Danyliw, Lars Eggert, Warren Kumari, John Scudder, Robert Wilton, Erik Kline, Zaheduzzaman Sarker, Murray Kucherawy, and Donald Eastlake 3rd for their careful review and helpful comments.
著者は、ティアン・ナウ、ドルフ・ドディ、フランク・ブロックナー、チェン・リー、ギャン・ミシュラ、マーカス・イラー、マーティン・デューク、クリス・ロンヴィック、エリック・ヴィンケ、アルバロ・レタナ、ポール・ウェイター、ロマン・ダニリウ、ラーレン・クマリ、ジョン・スカッダー・スカッダー、ロバート・ウィルトン、エリック・クライン、ザヘダッツァマン・サルカー、マレー・クチェラウィ、ドナルド・イーストレイクは、慎重なレビューと有益なコメントについて3番目に。
The authors appreciate the f2f discussion with Frank Brockners on this document.
著者は、この文書でフランクブロックナーとのF2Fの議論に感謝しています。
The authors would like to acknowledge Tommy Pauly and Ian Swett for their good suggestion and guidance.
著者は、彼らの良い提案とガイダンスについて、トミー・ポーリーとイアン・スウェットに認めたいと考えています。
Xiao Min
ZTE Corp.
Nanjing
China
Phone: +86 25 88013062
Email: xiao.min2@zte.com.cn
Greg Mirsky
Ericsson
United States of America
Email: gregimirsky@gmail.com
Lei Bo
China Telecom
Beijing
China
Phone: +86 10 50902903
Email: leibo@chinatelecom.cn