[要約] RFC 9326 は、IOAM Direct Exporting を導入し、IOAM データを直接エクスポートまたはローカルに集約するための新しいオプションタイプを提供します。IOAM の目的は、ネットワークを横断するデータパケットにテレメトリデータをプッシュすることです。
Internet Engineering Task Force (IETF) H. Song
Request for Comments: 9326 Futurewei
Category: Standards Track B. Gafni
ISSN: 2070-1721 Nvidia
F. Brockners
Cisco
S. Bhandari
Thoughtspot
T. Mizrahi
Huawei
November 2022
In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting
現場操作、管理、およびメンテナンス（IOAM）直接輸出
Abstract
概要
In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, IOAM allows telemetry data to be pushed into data packets while they traverse the network. This document introduces a new IOAM option type (denoted IOAM-Option-Type) called the "IOAM Direct Export (DEX) Option-Type". This Option-Type is used as a trigger for IOAM data to be directly exported or locally aggregated without being pushed into in-flight data packets. The exporting method and format are outside the scope of this document.
in situ操作、管理、およびメンテナンス（IOAM）は、運用情報とテレメトリ情報の記録と収集に使用されます。具体的には、IOAMを使用すると、ネットワークを横断する間、テレメトリデータをデータパケットに押し込むことができます。このドキュメントでは、「IOAM Direct Export（DEX）Option-Type」と呼ばれる新しいIOAMオプションタイプ（IOAM-Option-Typeを示します）を紹介します。このオプションタイプは、IOAMデータが直接エクスポートされるか、飛行中のデータパケットにプッシュされることなく局所的に集約されるトリガーとして使用されます。エクスポート方法とフォーマットは、このドキュメントの範囲外です。
Status of This Memo
本文書の位置付け
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/rfc9326.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9326で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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ライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. Conventions
2.1. Requirements Language
2.2. Terminology
3. The Direct Exporting (DEX) IOAM-Option-Type
3.1. Overview
3.1.1. DEX Packet Selection
3.1.2. Responding to the DEX Trigger
3.2. The DEX Option-Type Format
4. IANA Considerations
4.1. IOAM Type
4.2. IOAM DEX Flags
4.3. IOAM DEX Extension-Flags
5. Performance Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Notes about the History of This Document
Acknowledgments
Contributors
Authors' Addresses
IOAM [RFC9197] is used for monitoring traffic in the network and for incorporating IOAM data fields (denoted IOAM-Data-Fields) into in-flight data packets.
IOAM [RFC9197]は、ネットワーク内のトラフィックを監視し、IOAMデータフィールド（IOAM-DATA-FIELDS）を飛行中のデータパケットに組み込むために使用されます。
IOAM makes use of four possible IOAM-Option-Types, defined in [RFC9197]: Pre-allocated Trace, Incremental Trace, Proof of Transit (POT), and Edge-to-Edge.
IOAMは、[RFC9197]で定義されている4つの可能なIOAM-Option-Typesを使用しています：事前に割り当てられたトレース、増分トレース、トランジットの証明（POT）、およびエッジツーエッジ。
This document defines a new IOAM-Option-Type called the "IOAM Direct Export (DEX) Option-Type". This Option-Type is used as a trigger for IOAM nodes to locally aggregate and process IOAM data and/or to export it to a receiving entity (or entities). Throughout the document, this functionality is referred to as "collection" and/or "exporting". In this context, a "receiving entity" is an entity that resides within the IOAM domain such as a collector, analyzer, controller, decapsulating node, or software module in one of the IOAM nodes.
このドキュメントでは、「IOAM Direct Export（DEX）Option-Type」と呼ばれる新しいIOAM-Option-Typeを定義しています。このオプションタイプは、IOAMノードのトリガーとして使用され、IOAMデータを局所的に集約および処理したり、受信エンティティ（またはエンティティ）にエクスポートしたりします。ドキュメント全体で、この機能は「コレクション」および/または「エクスポート」と呼ばれます。これに関連して、「受信エンティティ」は、IOAMノードの1つにあるコレクター、アナライザー、コントローラー、脱カプセンティングノード、またはソフトウェアモジュールなどのIOAMドメイン内にあるエンティティです。
Note that even though the IOAM-Option-Type is called "Direct Export", it depends on the deployment whether the receipt of a packet with a DEX Option-Type leads to the creation of another packet. Some deployments might simply use the packet with the DEX Option-Type to trigger local processing of Operations, Administration, and Maintenance (OAM) data. The functionality of this local processing is not within the scope of this document.
IOAM-Option-Typeは「直接エクスポート」と呼ばれている場合でも、DEXオプションタイプのパケットの受領が別のパケットの作成につながるかどうかは展開に依存することに注意してください。一部の展開では、DEXオプションタイプでパケットを使用して、運用、管理、およびメンテナンス（OAM）データのローカル処理をトリガーするだけです。このローカル処理の機能は、このドキュメントの範囲内ではありません。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
Abbreviations used in this document:
このドキュメントで使用されている略語：
IOAM: In situ Operations, Administration, and Maintenance
IOAM：現場での操作、管理、およびメンテナンス
OAM: Operations, Administration, and Maintenance [RFC6291]
OAM：運用、管理、メンテナンス[RFC6291]
DEX: Direct Exporting
DEX：直接エクスポート
The DEX Option-Type is used as a trigger for collecting IOAM data locally or exporting it to a receiving entity (or entities). Specifically, the DEX Option-Type can be used as a trigger for collecting IOAM data by an IOAM node and locally aggregating it; thus, this aggregated data can be periodically pushed to a receiving entity or pulled by a receiving entity on-demand.
DEXオプションタイプは、IOAMデータをローカルに収集するか、受信エンティティ（またはエンティティ）にエクスポートするためのトリガーとして使用されます。具体的には、DEXオプションタイプは、IOAMノードによってiOAMデータを収集し、ローカルに集約するためのトリガーとして使用できます。したがって、この集計されたデータは、定期的に受信エンティティにプッシュされたり、受信エンティティがオンデマンドで引き抜かれたりすることができます。
This Option-Type is incorporated into data packets by an IOAM encapsulating node and removed by an IOAM decapsulating node, as illustrated in Figure 1. The Option-Type can be read, but not modified, by transit nodes. Note that the terms "IOAM encapsulating node", "IOAM decapsulating node", and "IOAM transit node" are as defined in [RFC9197].
このオプションタイプは、図1に示すように、IOAMカプセル化ノードによってデータパケットに組み込まれ、IOAM脱カプセンティングノードによって削除されます。「ノードをカプセル化するIOAM」という用語、「IOAM脱カプセンティングノード」、および「IOAMトランジットノード」という用語は、[RFC9197]で定義されているとおりであることに注意してください。
^
|Exported IOAM data
|
|
|
+--------------+------+-------+--------------+
| | | |
| | | |
User +---+----+ +---+----+ +---+----+ +---+----+
packets |Encapsu-| | Transit| | Transit| |Decapsu-|
--------->|lating |====>| Node |====>| Node |====>|lating |---->
|Node | | A | | B | |Node |
+--------+ +--------+ +--------+ +--------+
Insert DEX Export Export Remove DEX
option and IOAM data IOAM data option and
export data export data
Figure 1: DEX Architecture
図1：DEXアーキテクチャ
The DEX Option-Type is used as a trigger to collect and/or export IOAM data. The trigger applies to transit nodes, the decapsulating node, and the encapsulating node:
DEXオプションタイプは、IOAMデータを収集および/またはエクスポートするトリガーとして使用されます。トリガーは、トランジットノード、脱カプセンティングノード、およびカプセル化ノードに適用されます。
* An IOAM encapsulating node configured to incorporate the DEX Option-Type encapsulates the packets (or possibly a subset of the packets) it forwards with the DEX Option-Type and MAY export and/ or collect the requested IOAM data immediately. Only IOAM encapsulating nodes are allowed to add the DEX Option-Type to a packet. An IOAM encapsulating node can generate probe packets that incorporate the DEX Option-Type. These probe packets can be generated periodically or on-demand (for example, triggered by the management plane). The specification of such probe packets is outside the scope of this document.
* DEXオプションタイプを組み込むように構成されたIOAMカプセル化ノードは、パケット（またはパケットのサブセット）をDEXオプションタイプで転送し、要求されたIOAMデータをすぐにエクスポートおよび/または収集する場合があります。IOAMカプセル化ノードのみが、PacketにDEXオプションタイプを追加できます。IOAMカプセル化ノードは、DEXオプションタイプを組み込んだプローブパケットを生成できます。これらのプローブパケットは、定期的にまたはオンデマンド（たとえば、管理プレーンによってトリガーされる）を生成できます。このようなプローブパケットの仕様は、このドキュメントの範囲外です。
* A transit node that processes a packet with the DEX Option-Type MAY export and/or collect the requested IOAM data.
* DEXオプションタイプでパケットを処理するトランジットノードは、要求されたiOAMデータをエクスポートおよび/または収集することができます。
* An IOAM decapsulating node that processes a packet with the DEX Option-Type MAY export and/or collect the requested IOAM data and MUST decapsulate the IOAM header.
* DEXオプションタイプでパケットを処理するIOAM脱カプセンティングノードは、要求されたIOAMデータをエクスポートおよび/または収集し、IOAMヘッダーを脱カプセル化する必要があります。
As in [RFC9197], the DEX Option-Type can be incorporated into all or a subset of the traffic that is forwarded by the encapsulating node, as further discussed in Section 3.1.1. Moreover, IOAM nodes respond to the DEX trigger by exporting and/or collecting IOAM data either for all traversing packets that carry the DEX Option-Type or selectively only for a subset of these packets, as further discussed in Section 3.1.2.
[RFC9197]のように、DEXオプションタイプは、セクション3.1.1でさらに説明したように、カプセル化ノードによって転送されるトラフィックのすべてまたはサブセットに組み込むことができます。さらに、IOAMノードは、セクション3.1.2でさらに説明したように、これらのパケットのサブセットに対してDEXオプションタイプを運ぶすべてのトラバースパケットのいずれかについて、IOAMデータをエクスポートおよび/または収集することにより、DEXトリガーに応答します。
If an IOAM encapsulating node incorporates the DEX Option-Type into all the traffic it forwards, it may lead to an excessive amount of exported data, which may overload the network and the receiving entity. Therefore, an IOAM encapsulating node that supports the DEX Option-Type MUST support the ability to incorporate the DEX Option-Type selectively into a subset of the packets that are forwarded by the IOAM encapsulating node.
IOAMのカプセル化ノードに、DEXオプションタイプがすべてのトラフィックに組み込まれている場合、ネットワークと受信エンティティに過負荷になる可能性のあるエクスポートデータが過剰な量につながる可能性があります。したがって、DEXオプションタイプをサポートするIOAMカプセル化ノードは、DEXオプションタイプを選択的に組み込む機能をサポートする必要があります。
Various methods of packet selection and sampling have been previously defined, such as [RFC7014] and [RFC5475]. Similar techniques can be applied by an IOAM encapsulating node to apply DEX to a subset of the forwarded traffic.
[RFC7014]や[RFC5475]など、パケットの選択とサンプリングのさまざまな方法が以前に定義されています。同様の手法は、IOAMカプセル化ノードによって適用され、DEXを転送されたトラフィックのサブセットに適用できます。
The subset of traffic that is forwarded or transmitted with a DEX Option-Type SHOULD NOT exceed 1/N of the interface capacity on any of the IOAM encapsulating node's interfaces. It is noted that this requirement applies to the total traffic that incorporates a DEX Option-Type, including traffic that is forwarded by the IOAM encapsulating node and probe packets that are generated by the IOAM encapsulating node. In this context, N is a parameter that can be configurable by network operators. If there is an upper bound, M, on the number of IOAM transit nodes in any path in the network, then it is RECOMMENDED to use an N such that N >> M (i.e., N is much greater than M). The rationale is that a packet that includes a DEX Option-Type may trigger an exported packet from each IOAM transit node along the path for a total of M exported packets. Thus, if N >> M, then the number of exported packets is significantly lower than the number of data packets forwarded by the IOAM encapsulating node. If there is no prior knowledge about the network topology or size, it is RECOMMENDED to use N>100.
DEXオプションタイプで転送または送信されるトラフィックのサブセットは、IOAMカプセル化ノードのインターフェイスのいずれかのインターフェイス容量の1/nを超えてはなりません。この要件は、IOAMカプセル化ノードとプローブパケットによって転送されるトラフィックを含む、DEXオプションタイプを組み込んだ総トラフィックに適用されることに注意してください。これに関連して、nはネットワーク演算子が構成できるパラメーターです。ネットワーク内の任意のパス内のIOAMトランジットノードの数に上限mがある場合、n >> m（つまり、nはmよりもはるかに大きい）になるようにnを使用することをお勧めします。理論的根拠は、DEXオプションタイプを含むパケットが、各iOAMトランジットノードからパスに沿ってエクスポートされたパケットをトリガーする可能性があるということです。したがって、n >> mの場合、エクスポートされたパケットの数は、IOAMカプセル化ノードによって転送されるデータパケットの数よりも大幅に低くなります。ネットワークトポロジまたはサイズに関する事前の知識がない場合は、n> 100を使用することをお勧めします。
The DEX Option-Type specifies which IOAM-Data-Fields should be exported and/or collected, as specified in Section 3.2. As mentioned above, the data can be locally collected, aggregated, and/or exported to a receiving entity proactively or on-demand. If IOAM data is exported, the format and encapsulation of the packet that contains the exported data is not within the scope of the current document. For example, the export format can be based on [IOAM-RAWEXPORT].
DEXオプションタイプは、セクション3.2で指定されているように、IOAM-Data-Fieldsをエクスポートおよび/または収集する必要があるかを指定します。上記のように、データは、局所的に収集、集約、および/または受信エンティティに積極的またはオンデマンドにエクスポートすることができます。IOAMデータがエクスポートされる場合、エクスポートされたデータを含むパケットの形式とカプセル化は、現在のドキュメントの範囲内ではありません。たとえば、エクスポート形式は[ioam-rawexport]に基づいています。
An IOAM node that performs DEX-triggered exporting MUST support the ability to limit the rate of the exported packets. The rate of exported packets SHOULD be limited so that the number of exported packets is significantly lower than the number of packets that are forwarded by the device. The exported data rate SHOULD NOT exceed 1/ N of the interface capacity on any of the IOAM node's interfaces. It is RECOMMENDED to use N>100. Depending on the IOAM node's architecture considerations, the export rate may be limited to a lower number in order to avoid loading the IOAM node. An IOAM node MAY maintain a counter or a set of counters that count the events in which the IOAM node receives a packet with the DEX Option-Type and does not collect and/or export data due to the rate limits.
DEXトリガーされたエクスポートを実行するIOAMノードは、エクスポートされたパケットのレートを制限する機能をサポートする必要があります。エクスポートされたパケットのレートは、エクスポートされたパケットの数がデバイスによって転送されるパケットの数よりも大幅に低くなるように制限する必要があります。エクスポートされたデータレートは、IOAMノードのインターフェイスのいずれかのインターフェイス容量の1/ nを超えてはなりません。n> 100を使用することをお勧めします。IOAMノードのアーキテクチャの考慮事項に応じて、IOAMノードの読み込みを避けるために、エクスポートレートが低い数に制限される場合があります。IOAMノードは、IOAMノードがDEXオプションタイプでパケットを受信し、レート制限のためにデータを収集および/またはエクスポートしないイベントをカウントするカウンターまたはカウンターのセットを維持できます。
IOAM nodes SHOULD NOT be configured to export packets over a path or a tunnel that is subject to IOAM direct exporting. Furthermore, IOAM encapsulating nodes that can identify a packet as an IOAM exported packet MUST NOT push a DEX Option-Type into such a packet. This requirement is intended to prevent nested exporting and/or exporting loops.
IOAMノードは、IOAMダイレクトエクスポートの対象となるパスまたはトンネルを介してパケットをエクスポートするように構成しないでください。さらに、IOAMエクスポートパケットとしてパケットを識別できるIOAMカプセル化ノードは、DEXオプションタイプをそのようなパケットに押し込んではなりません。この要件は、ネストされたエクスポートおよび/またはエクスポートループを防ぐことを目的としています。
A transit or decapsulating IOAM node that receives an unknown IOAM-Option-Type ignores it (as defined in [RFC9197]); specifically, nodes that do not support the DEX Option-Type ignore it. As per [RFC9197], note that a decapsulating node removes the IOAM encapsulation and all its IOAM-Option-Types. Specifically, this applies to the case where one of these options is a (possibly unknown) DEX Option-Type. The ability to skip over a (possibly unknown) DEX Option-Type in the parsing or in the decapsulation procedure is dependent on the specific encapsulation, which is outside the scope of this document. For example, when IOAM is encapsulated in IPv6 [IOAM-IPV6-OPTIONS], the DEX Option-Type is incorporated either in a Hop-by-Hop options header or in a Destination options header; thus, it can be skipped using the length field in the options header.
未知のioam-option-typeを受信する輸送または脱カプセンティングioamノードはそれを無視します（[rfc9197]で定義されています）。具体的には、DEXオプションタイプをサポートしていないノードは無視します。[RFC9197]によると、脱カプセンシングノードはIOAMカプセル化とそのすべてのIOAMオプションタイプを削除することに注意してください。具体的には、これは、これらのオプションの1つが（おそらく未知の）DEXオプションタイプである場合に適用されます。解析または脱カプセル化手順で（おそらく未知の）DEXオプションタイプをスキップする機能は、このドキュメントの範囲外である特定のカプセル化に依存します。たとえば、IOAMがIPv6 [IOAM-IPV6-OPTIONS]にカプセル化されている場合、DEXオプションタイプは、ホップバイホップオプションヘッダーまたは宛先オプションヘッダーのいずれかに組み込まれます。したがって、オプションヘッダーの長さフィールドを使用してスキップできます。
The format of the DEX Option-Type is depicted in Figure 2. The length of the DEX Option-Type is at least 8 octets. The DEX Option-Type MAY include one or more optional fields. The existence of the optional fields is indicated by the corresponding flags in the Extension-Flags field. Two optional fields are defined in this document: the Flow ID and Sequence Number fields. Every optional field MUST be exactly 4 octets long. Thus, the Extension-Flags field explicitly indicates the length of the DEX Option-Type. Defining a new optional field requires an allocation of a corresponding flag in the Extension-Flags field, as specified in Section 4.2.
DEXオプションタイプの形式を図2に示します。DEXオプションタイプの長さは少なくとも8オクテットです。DEXオプションタイプには、1つ以上のオプションフィールドが含まれる場合があります。オプションのフィールドの存在は、拡張フラグフィールドの対応するフラグによって示されます。このドキュメントでは、2つのオプションフィールドが定義されています。フローIDとシーケンス番号フィールドです。すべてのオプションフィールドは、正確に4オクテットの長さでなければなりません。したがって、拡張フラグフィールドは、DEXオプションタイプの長さを明示的に示します。新しいオプションフィールドを定義するには、セクション4.2で指定されているように、拡張フラグフィールドに対応するフラグの割り当てが必要です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | Flags |Extension-Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow ID (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: DEX Option-Type Format
図2：DEXオプションタイプ形式
Namespace-ID: A 16-bit identifier of the IOAM namespace, as defined in [RFC9197].
名前空間ID：[RFC9197]で定義されているIOAMネームスペースの16ビット識別子。
Flags: An 8-bit field, comprised of 8 1-bit subfields. Flags are allocated by IANA, as defined in Section 4.2.
フラグ：8ビットのフィールド、8つの1ビットサブフィールドで構成されています。セクション4.2で定義されているように、フラグはIANAによって割り当てられます。
Extension-Flags: An 8-bit field, comprised of 8 1-bit subfields. Extension-Flags are allocated by IANA, as defined in Section 4.3. Every bit in the Extension-Flag field that is set to 1 indicates the existence of a corresponding optional 4-octet field. An IOAM node that receives a DEX Option-Type with an unknown flag set to 1 MUST ignore the corresponding optional field.
拡張フラグ：8ビットのサブフィールドで構成される8ビットフィールド。セクション4.3で定義されているように、拡張フラグはIANAによって割り当てられます。1に設定されている拡張フラグフィールドのすべてのビットは、対応するオプションの4-OCTETフィールドの存在を示します。1に設定されている未知のフラグを持つDEXオプションタイプを受信するIOAMノードは、対応するオプションフィールドを無視する必要があります。
IOAM-Trace-Type: A 24-bit identifier that specifies which IOAM-Data-Fields should be exported. The format of this field is as defined in [RFC9197]. Specifically, the bit that corresponds to the Checksum Complement IOAM-Data-Field SHOULD be assigned to be zero by the IOAM encapsulating node and ignored by transit and decapsulating nodes. The reason for this is that the Checksum Complement is intended for in-flight packet modifications and is not relevant for direct exporting.
IOAM-TRACE-TYPE：IOAM-Data-Fieldをエクスポートする必要がある24ビット識別子。このフィールドの形式は、[RFC9197]で定義されています。具体的には、チェックサム補体ioam-data-fieldに対応するビットは、IOAMカプセル化ノードによってゼロに割り当てられ、トランジットと脱カプセル化ノードによって無視される必要があります。この理由は、チェックサム補体が飛行中のパケットの変更を目的としており、直接エクスポートには関係がないためです。
Reserved: This field MUST be ignored by the receiver.
予約済み：このフィールドは、受信機によって無視する必要があります。
Optional fields: The optional fields, if present, reside after the Reserved field. The order of the optional fields is according to the order of the respective bits, starting from the most significant bit, that are enabled in the Extension-Flags field. Each optional field is 4 octets long.
オプションのフィールド：オプションのフィールドは、存在する場合、予約済みフィールドの後に存在します。オプションのフィールドの順序は、最も重要なビットから始まるそれぞれのビットの順序に従って、拡張フラグフィールドで有効になっています。各オプションのフィールドの長さは4オクターです。
Flow ID: An optional 32-bit field representing the flow identifier. If the actual Flow ID is shorter than 32 bits, it is zero padded in its most significant bits. The field is set at the encapsulating node. The Flow ID can be used to correlate the exported data of the same flow from multiple nodes and from multiple packets. Flow ID values are expected to be allocated in a way that avoids collisions. For example, random assignment of Flow ID values can be subject to collisions, while centralized allocation can avoid this problem. The specification of the Flow ID allocation method is not within the scope of this document.
フローID：フロー識別子を表すオプションの32ビットフィールド。実際のフローIDが32ビットより短い場合、最も重要なビットでゼロパッドがパッドになります。フィールドは、カプセル化ノードに設定されています。フローIDを使用して、複数のノードと複数のパケットから同じフローのエクスポートデータを相関させることができます。フローID値は、衝突を回避する方法で割り当てられると予想されます。たとえば、フローID値のランダムな割り当ては衝突の影響を受ける可能性がありますが、集中配分はこの問題を回避できます。フローID割り当て方法の指定は、このドキュメントの範囲内ではありません。
Sequence Number: An optional 32-bit sequence number starting from 0 and incremented by 1 for each packet from the same flow at the encapsulating node that includes the DEX option. The Sequence Number, when combined with the Flow ID, provides a convenient approach to correlate the exported data from the same user packet.
シーケンス番号：DEXオプションを含むカプセル化ノードの同じフローからの各パケットに対して、0から始まり、各パケットに対して1 x 1 x拡大されたオプションの32ビットシーケンス番号。シーケンス番号は、フローIDと組み合わせると、同じユーザーパケットからエクスポートされたデータを相関させる便利なアプローチを提供します。
The "IOAM Option-Type" registry is defined in Section 7.1 of [RFC9197]. IANA has allocated the following code point from the "IOAM Option-Type" registry as follows:
「IOAMオプションタイプ」レジストリは、[RFC9197]のセクション7.1で定義されています。IANAは、次のように「ioam option-type」レジストリから次のコードポイントを割り当てました。
Code Point: 4
コードポイント：4
Name IOAM Direct Export (DEX) Option-Type
名前IOAM Direct Export（DEX）オプションタイプ
Description: Direct exporting
説明：直接エクスポート
Reference: This document
参照：このドキュメント
IANA has created the "IOAM DEX Flags" registry. This registry includes 8 flag bits. Allocation is based on the "IETF Review" procedure defined in [RFC8126].
IANAは「IOAM Dex Flags」レジストリを作成しました。このレジストリには8つのフラグビットが含まれます。割り当ては、[RFC8126]で定義されている「IETFレビュー」手順に基づいています。
New registration requests MUST use the following template:
新しい登録リクエストは、次のテンプレートを使用する必要があります。
Bit: Desired bit to be allocated in the 8-bit Flags field of the DEX Option-Type.
BIT：DEXオプションタイプの8ビットフラグフィールドに割り当てられる必要があります。
Description: Brief description of the newly registered bit.
説明：新しく登録されたビットの簡単な説明。
Reference: Reference to the document that defines the new bit.
参照：新しいビットを定義するドキュメントへの参照。
IANA has created the "IOAM DEX Extension-Flags" registry. This registry includes 8 flag bits. Bit 0 (the most significant bit) and bit 1 in the registry are allocated by this document and described in Section 3.2. Allocation of the other bits should be performed based on the "IETF Review" procedure defined in [RFC8126].
IANAは「IOAM Dex拡張機能」レジストリを作成しました。このレジストリには8つのフラグビットが含まれます。ビット0（最も重要なビット）とレジストリのビット1は、このドキュメントによって割り当てられ、セクション3.2で説明されています。他のビットの割り当ては、[RFC8126]で定義されている「IETFレビュー」手順に基づいて実行する必要があります。
Bit 0: "Flow ID [RFC9326]"
ビット0：「フローID [RFC9326]」
Bit 1: "Sequence Number [RFC9326]"
ビット1：「シーケンス番号[RFC9326]」
New registration requests MUST use the following template:
新しい登録リクエストは、次のテンプレートを使用する必要があります。
Bit: Desired bit to be allocated in the 8-bit Extension-Flags field of the DEX Option-Type.
BIT：DEXオプションタイプの8ビット拡張機能フィールドフィールドに割り当てられる必要があります。
Description: Brief description of the newly registered bit.
説明：新しく登録されたビットの簡単な説明。
Reference: Reference to the document that defines the new bit.
参照：新しいビットを定義するドキュメントへの参照。
The DEX Option-Type triggers IOAM data to be collected and/or exported packets to be exported to a receiving entity (or entities). In some cases, this may impact the receiving entity's performance or the performance along the paths leading to it.
DEXオプションタイプは、収集されるIOAMデータをトリガーし、/またはエクスポートされたパケットを受信エンティティ（またはエンティティ）にエクスポートします。場合によっては、これは受信エンティティのパフォーマンスまたはそれにつながるパスに沿ったパフォーマンスに影響を与える可能性があります。
Therefore, the performance impact of these exported packets is limited by taking two measures: at the encapsulating nodes by selective DEX encapsulation (Section 3.1.1) and at the transit nodes by limiting exporting rate (Section 3.1.2). These two measures ensure that direct exporting is used at a rate that does not significantly affect the network bandwidth and does not overload the receiving entity. Moreover, it is possible to load balance the exported data among multiple receiving entities, although the exporting method is not within the scope of this document.
したがって、これらのエクスポートされたパケットのパフォーマンスへの影響は、2つの測定値を取ることで制限されます。選択的DEXカプセル化（セクション3.1.1）により、エクスポートレートを制限することによりトランジットノードでカプセル化ノードを使用します（セクション3.1.2）。これらの2つの測定により、直接エクスポートがネットワーク帯域幅に大きな影響を与えず、受信エンティティに過負荷にならないレートで使用されることが保証されます。さらに、エクスポート方法はこのドキュメントの範囲内ではありませんが、複数の受信エンティティ間でエクスポートデータのバランスを負担することができます。
It should be noted that, in some networks, DEX data may be exported over an out-of-band network in which a large volume of exported traffic does not compromise user traffic. In this case, an operator may choose to disable the exporting rate limiting.
一部のネットワークでは、DEXデータは、大量のエクスポートされたトラフィックがユーザートラフィックを侵害しないバンド外ネットワーク上でエクスポートされる場合があることに注意してください。この場合、オペレーターはエクスポートレートの制限を無効にすることを選択できます。
The security considerations of IOAM in general are discussed in [RFC9197]. Specifically, an attacker may try to use the functionality that is defined in this document to attack the network.
一般にIOAMのセキュリティ上の考慮事項は[RFC9197]で説明されています。具体的には、攻撃者は、ネットワークを攻撃するためにこのドキュメントで定義されている機能を使用しようとする場合があります。
An attacker may attempt to overload network devices by injecting synthetic packets that include the DEX Option-Type. Similarly, an on-path attacker may maliciously incorporate the DEX Option-Type into transit packets or maliciously remove it from packets in which it is incorporated.
攻撃者は、DEXオプションタイプを含む合成パケットを注入することにより、ネットワークデバイスをオーバーロードしようとする場合があります。同様に、パス上の攻撃者は、DEXオプションタイプをトランジットパケットに悪意を持って組み込むか、組み込まれたパケットから悪意を持って削除する場合があります。
Forcing DEX, either in synthetic packets or in transit packets, may overload the IOAM nodes and/or the receiving entity (or entities). Since this mechanism affects multiple devices along the network path, it potentially amplifies the effect on the network bandwidth, the storage of the devices that collect the data, and the receiving entity's load.
合成パケットまたはトランジットパケットのいずれかでDEXを強制すると、IOAMノードおよび/または受信エンティティ（またはエンティティ）にオーバーロードされる場合があります。このメカニズムは、ネットワークパスに沿った複数のデバイスに影響を与えるため、ネットワーク帯域幅への影響、データを収集するデバイスのストレージ、および受信エンティティの負荷を増幅する可能性があります。
The amplification effect of DEX may be worse in wide area networks in which there are multiple IOAM-Domains. For example, if DEX is used in IOAM-Domain 1 for exporting IOAM data to a receiving entity, then the exported packets of IOAM-Domain 1 can be forwarded through IOAM-Domain 2, in which they are subject to DEX. In turn, the exported packets of IOAM-Domain 2 may be forwarded through another IOAM domain (or through IOAM-Domain 1); theoretically, this recursive amplification may continue infinitely.
DEXの増幅効果は、複数のIOAMドメインがある広いエリアネットワークで悪化する可能性があります。たとえば、IOAM-Domain 1でIOAMデータを受信エンティティにエクスポートするために使用される場合、IOAM-Domain 1のエクスポートパケットは、DEXの対象となるIOAMドメイン2を介して転送できます。次に、IOAM-Domain 2のエクスポートされたパケットは、別のIOAMドメイン（またはIOAMドメイン1を介して）を介して転送できます。理論的には、この再帰増幅は無限に続く可能性があります。
In order to mitigate the attacks described above, the following requirements (Section 3) have been defined:
上記の攻撃を軽減するために、次の要件（セクション3）が定義されています。
* Selective DEX (Section 3.1.1) is applied by IOAM encapsulating nodes in order to limit the potential impact of DEX attacks to a small fraction of the traffic.
* 選択的DEX（セクション3.1.1）は、DEX攻撃の少数のトラフィックへの潜在的な影響を制限するために、IOAMカプセル化ノードによって適用されます。
* Rate limiting of exported traffic (Section 3.1.2) is applied by IOAM nodes in order to prevent overloading attacks and to significantly limit the scale of amplification attacks.
* エクスポートされたトラフィックのレート制限（セクション3.1.2）は、過負荷攻撃を防ぎ、増幅攻撃のスケールを大幅に制限するために、IOAMノードによって適用されます。
* IOAM encapsulating nodes are required to avoid pushing the DEX Option-Type into IOAM exported packets (Section 3.1.2), thus preventing some of the amplification and export loop scenarios.
* IOAMカプセル化ノードは、DEXオプションタイプをIOAMエクスポートパケットに押し込むことを避けるために必要であり（セクション3.1.2）、増幅およびエクスポートループシナリオの一部を防ぎます。
Although the exporting method is not within the scope of this document, any exporting method MUST secure the exported data from the IOAM node to the receiving entity in order to protect the confidentiality and guarantee the integrity of the exported data. Specifically, an IOAM node that performs DEX exporting MUST send the exported data to a pre-configured trusted receiving entity that is in the same IOAM-Domain as the exporting IOAM node. Furthermore, an IOAM node MUST gain explicit consent to export data to a receiving entity before starting to send exported data.
エクスポート方法はこのドキュメントの範囲内ではありませんが、エクスポート方法は、機密性を保護し、エクスポートされたデータの整合性を保証するために、IOAMノードから受信エンティティへのエクスポートデータを保護する必要があります。具体的には、DEXエクスポートを実行するIOAMノードは、エクスポートされたIOAMノードと同じIOAMドメインにある事前に構成された信頼できる受信エンティティにエクスポートデータを送信する必要があります。さらに、IOAMノードは、エクスポートされたデータの送信を開始する前に、データを受信エンティティにエクスポートすることに明示的な同意を得る必要があります。
An attacker may keep track of the information sent in DEX headers as a means of reconnaissance. This form of recon can be mitigated to some extent by careful allocation of the Flow ID and Sequence Number space in a way that does not compromise privacy aspects, such as customer identities.
攻撃者は、偵察手段としてDexヘッダーで送信された情報を追跡することができます。この形式の偵察は、顧客のアイデンティティなどのプライバシーの側面を妥協しない方法で、フローIDとシーケンス番号スペースを慎重に割り当てることにより、ある程度緩和できます。
The integrity of the DEX Option-Type can be protected through a mechanism of the encapsulating protocol. While [IOAM-DATA-INTEGRITY] introduces an integrity protection mechanism that protects the integrity of IOAM-Data-Fields, the DEX Option-Type does not include IOAM-Data-Fields; therefore, these integrity protection mechanisms are not applicable to the DEX Option-Type. As discussed in the threat analysis of [IOAM-DATA-INTEGRITY], injection or modification of IOAM-Option-Type headers are threats that are not addressed in IOAM.
DEXオプションタイプの整合性は、カプセル化プロトコルのメカニズムを通じて保護できます。[IOAM-Data-Integrity]は、IOAM-DATAフィールドの整合性を保護する完全性保護メカニズムを導入しますが、DEXオプションタイプにはIOAM-DATAフィールドは含まれません。したがって、これらの整合性保護メカニズムは、DEXオプションタイプには適用されません。[IOAM-data-Integrity]の脅威分析で説明したように、IOAM-Option-Typeヘッダーの注入または修正は、IOAMで対処されていない脅威です。
IOAM is assumed to be deployed in a restricted administrative domain, thus limiting the scope of the threats above and their effect. This is a fundamental assumption with respect to the security aspects of IOAM, as further discussed in [RFC9197].
IOAMは制限された管理ドメインに展開されていると想定されているため、上記の脅威の範囲とその効果が制限されています。これは、[RFC9197]でさらに議論されているように、IOAMのセキュリティ側面に関する基本的な仮定です。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<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>.
[RFC9197] Brockners、F.、ed。、Bhandari、S.、ed。、およびT. Mizrahi、ed。、「現場操作、管理、およびメンテナンスのためのデータフィールド（IOAM）」、RFC 9197、DOI 10.17487/RFC9197、2022年5月、<https://www.rfc-editor.org/info/rfc9197>。
[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-02, 5 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-integrity-02>.
[IOAM-Data-Integrity] Brockners、F.、Bhandari、S.、Mizrahi、T。、およびJ. Iurman、「In-situ OAMデータフィールドの完全性」、進行中の作業、インターネットドラフト、ドラフト-iitf-IPPM-IOAM-Data-Integrity-02、2022年7月5日、<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-integrity-02>。
[IOAM-IPV6-OPTIONS] Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-ipv6-options-09, 11 October 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-ipv6-options-09>.
[IOAM-IPV6-OPTIONS] Bhandari、S。およびF. Brockners、「In-situ OAM IPv6オプション」、Work in Progress、Internet-Draft、Draft-ITPM-IOAM-IPV6-OPTIONS-09、2022年10月11日、<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-ipv6-options-09>。
[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-Rawexport] Spiegel、M.、Brockners、F.、Bhandari、S。、およびR. Sivakolundu、「In-situ oam oam raw data export with ipfix」、作業中、インターネットドラフト、ドラフトスピエゲル-Ippm-ioam-rawexport-06、2022年2月21日、<https://datatracker.ietf.org/doc/html/draft-spiegel-ippm-ioam-rawexport-06>。
[POSTCARD-BASED-TELEMETRY] Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou, T., Li, Z., Graf, T., Mishra, G. S., Shin, J., and K. Lee, "Marking-based Direct Export for On-path Telemetry", Work in Progress, Internet-Draft, draft-song-ippm-postcard-based-telemetry-14, 7 September 2022, <https://datatracker.ietf.org/doc/html/draft-song-ippm-postcard-based-telemetry-14>.
[ポストカードベースのテレメトリー] Song、H.、Mirsky、G.、Filsfils、C.、Abdelsalam、A.、Zhou、T.、Li、Z.、Graf、T.、Mishra、G.S.、Shin、J。、およびK. Lee、「マークベースのパステレメトリ向けの直接エクスポート」は、進行中の作業、インターネットドラフト、ドラフトソン-Postcardベースのテレメトリー-14、2022年9月7日、<https：//datatracker.ietf.org/doc/html/draft-song-postcardベースのテレメトリー14>。
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, <https://www.rfc-editor.org/info/rfc5475>.
[RFC5475] Zseby、T.、Molina、M.、Duffield、N.、Niccolini、S。、およびF. Raspall、「IPパケット選択のためのサンプリングとフィルタリング技術」、RFC 5475、DOI 10.17487/RFC5475、2009年3月、<https://www.rfc-editor.org/info/rfc5475>。
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, DOI 10.17487/RFC6291, June 2011, <https://www.rfc-editor.org/info/rfc6291>.
[RFC6291] Andersson、L.、Van Helvoort、H.、Bonica、R.、Romascanu、D。、およびS. Mansfield、「IETFでの「OAM」頭字語のガイドライン」、BCP 161、RFC 6291、doi 10.17487/rfc6291、2011年6月、<https://www.rfc-editor.org/info/rfc6291>。
[RFC7014] D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow Selection Techniques", RFC 7014, DOI 10.17487/RFC7014, September 2013, <https://www.rfc-editor.org/info/rfc7014>.
[RFC7014] D'Antonio、S.、Zseby、T.、Henke、C。、およびL. Peluso、「Flow Selection Techniques」、RFC 7014、DOI 10.17487/RFC7014、2013年9月、<https：//www.rfcc-editor.org/info/rfc7014>。
[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>.
[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https：// wwwwwwwwwwwwwwwwwwww.rfc-editor.org/info/rfc8126>。
[RFC9322] Mizrahi, T., Brockners, F., Bhandari, S., Gafni, B., and M. Spiegel, "In Situ Operations, Administration, and Maintanence (IOAM) Loopback and Active Flags", RFC 9322, DOI 10.17487/RFC9322, November 2022, <https://www.rfc-editor.org/info/rfc9322>.
[RFC9322] Mizrahi、T.、Brockners、F.、Bhandari、S.、Gafni、B。、およびM. Spiegel、「In in situ Operations、管理、および維持（IOAM）ループバックとアクティブフラグ」、RFC 9322、doi10.17487/rfc9322、2022年11月、<https://www.rfc-editor.org/info/rfc9322>。
This document evolved from combining some of the concepts of PBT-I from [POSTCARD-BASED-TELEMETRY] with immediate exporting from early versions of [RFC9322].
このドキュメントは、[PBT-Iの概念の一部を[ポストカードベース]テレメトリからの概念と[RFC9322]の初期バージョンからの即時エクスポートから組み合わせることから進化しました。
In order to help correlate and order the exported packets, it is possible to include the Hop_Lim/Node_ID IOAM-Data-Field in exported packets. If the IOAM-Trace-Type [RFC9197] has the Hop_Lim/Node_ID bit set, then exported packets include the Hop_Lim/Node_ID IOAM-Data-Field, which contains the TTL/Hop Limit value from a lower layer protocol. An alternative approach was considered during the design of this document, according to which a 1-octet Hop Count field would be included in the DEX header (presumably by claiming some space from the Flags field). The Hop Limit would start from 0 at the encapsulating node and be incremented by each IOAM transit node that supports the DEX Option-Type. In this approach, the Hop Count field value would also be included in the exported packet.
エクスポートされたパケットの相関と注文を支援するために、エクスポートされたパケットにhop_lim/node_id ioam-data-fieldを含めることができます。IOAM-TRACE-TYPE [RFC9197]にhop_lim/node_idビットセットがある場合、エクスポートされたパケットには、下層プロトコルからのTTL/ホップ制限値を含むhop_lim/node_id ioam-data-fieldが含まれます。このドキュメントの設計中に別のアプローチが考慮されました。これによると、1オクテットのホップカウントフィールドはDexヘッダーに含まれます（おそらくフラグフィールドからいくつかのスペースを主張することにより）。ホップ制限は、カプセル化ノードで0から開始され、DEXオプションタイプをサポートする各iOAMトランジットノードによってインクリメントされます。このアプローチでは、ホップカウントフィールド値もエクスポートパケットに含まれます。
Acknowledgments
謝辞
The authors thank Martin Duke, Tommy Pauly, Meral Shirazipour, Colin Perkins, Stephen Farrell, Linda Dunbar, Justin Iurman, Greg Mirsky, and other members of the IPPM working group for many helpful comments.
著者は、マーティン・デューク、トミー・ポーリー、マラル・シラジポール、コリン・パーキンス、スティーブン・ファレル、リンダ・ダンバー、ジャスティン・イールマン、グレッグ・ミルスキー、およびIPPMワーキンググループの他のメンバーに多くの有益なコメントに感謝します。
Contributors
貢献者
The Editors would like to recognize the contributions of the following individuals to this document.
編集者は、この文書への以下の個人の貢献を認識したいと考えています。
Tianran Zhou Huawei 156 Beiqing Rd. Beijing 100095 China Email: zhoutianran@huawei.com
Tianran Zhou Huawei 156 Beiqing Rd。北京100095中国メール：zhoutianran@huawei.com
Zhenbin Li Huawei 156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com
Zhenbin Li Huawei 156 Beiqing Rd。北京100095中国メール：lizhenbin@huawei.com
Ramesh Sivakolundu Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 United States of America Email: sramesh@cisco.com
Ramesh Sivakolundu Cisco Systems、Inc。170 West Tasman Dr. San Jose、CA 95134アメリカ合衆国電子メール：sramesh@cisco.com
Authors' Addresses
著者のアドレス
Haoyu Song Futurewei 2330 Central Expressway Santa Clara, 95050 United States of America Email: haoyu.song@futurewei.com
Haoyu Song Futurewei 2330 Central Expressway Santa Clara、95050 United States of America Email：haoyu.song@futurewei.com
Barak Gafni Nvidia Suite 100 350 Oakmead Parkway Sunnyvale, CA 94085 United States of America Email: gbarak@nvidia.com
Barak Gafni Nvidia Suite 100 350 Oakmead Parkway Sunnyvale、CA 94085アメリカ合衆国電子メール：gbarak@nvidia.com
Frank Brockners Cisco Systems, Inc. Hansaallee 249 40549 Duesseldorf Germany Email: fbrockne@cisco.com
Frank Brockners Cisco Systems、Inc。Hansaallee 249 40549 Duesseldorfドイツメール：fbrockne@cisco.com
Shwetha Bhandari Thoughtspot 3rd Floor, Indiqube Orion, Garden Layout, HSR Layout 24th Main Rd Bangalore 560 102 Karnataka India Email: shwetha.bhandari@thoughtspot.com
Shwetha Bhandari Thoughtspot 3階、Indiqube Orion、Garden Layout、HSR Layout 24th Main Rd Bangalore 560 102 Karnataka India：shwetha.bhandari@thoughtspot.com
Tal Mizrahi Huawei 8-2 Matam Haifa 3190501 Israel Email: tal.mizrahi.phd@gmail.com
TAL MIZRAHI HUAWEI 8-2 MATAM HAIFA 3190501イスラエルメール：tal.mizrahi.phd@gmail.com