Internet Engineering Task Force (IETF) S. Boutros, Ed.
Request for Comments: 9638 Ciena Corporation
Category: Informational D. Eastlake 3rd, Ed.
ISSN: 2070-1721 Independent
September 2024
The IETF Network Virtualization Overlays (NVO3) Working Group developed considerations for a common encapsulation that addresses various network virtualization overlay technical concerns. This document provides a record, for the benefit of the IETF community, of the considerations arrived at by the NVO3 Working Group starting from the output of the NVO3 encapsulation Design Team. These considerations may be helpful with future deliberations by working groups over the choice of encapsulation formats.
IETFネットワーク仮想化オーバーレイ（NVO3）ワーキンググループは、さまざまなネットワーク仮想化に対処する一般的なカプセル化について考慮事項を開発しました。このドキュメントは、IETFコミュニティの利益のために、NVO3カプセル化設計チームの出力から始まるNVO3ワーキンググループが到達した考慮事項の記録を提供します。これらの考慮事項は、カプセル化形式の選択に関するワーキンググループによる将来の審議に役立つ場合があります。
There are implications of having different encapsulations in real environments consisting of both software and hardware implementations and within and spanning multiple data centers. For example, Operations, Administration, and Maintenance (OAM) functions such as path MTU discovery become challenging with multiple encapsulations along the data path.
ソフトウェアとハードウェアの実装の両方で構成される実際の環境、および複数のデータセンター内および範囲内で構成される実際の環境で異なるカプセルを持っていることには影響があります。たとえば、Path MTU発見などの操作、管理、およびメンテナンス（OAM）機能は、データパスに沿った複数のカプセルで挑戦的になります。
Based on these considerations, the NVO3 Working Group determined that Generic Network Virtualization Encapsulation (Geneve) with a few modifications is the common encapsulation. This document provides more details, particularly in Section 7.
これらの考慮事項に基づいて、NVO3ワーキンググループは、いくつかの変更を伴うジェネリックネットワーク仮想化カプセル化（Geneve）が一般的なカプセル化であると判断しました。このドキュメントは、特にセクション7で詳細を提供します。
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/rfc9638.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9638で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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. Design Team and Working Group Process
3. Terminology
4. Abbreviations, Acronyms, and Definitions
5. Encapsulation Issues and Background
5.1. Geneve
5.2. Generic UDP Encapsulation (GUE)
5.3. Generic Protocol Extension (GPE) for VXLAN
6. Common Encapsulation Considerations
6.1. Current Encapsulations
6.2. Useful Extensions Use Cases
6.2.1. Telemetry Extensions
6.2.2. Security/Integrity Extensions
6.2.3. Group-Based Policy
6.3. Hardware Considerations
6.4. Extension Size
6.5. Ordering of Extension Headers
6.6. TLV versus Bit Fields
6.7. Control Plane Considerations
6.8. Split NVE
6.9. Larger VNI Considerations
7. Recommendations
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Encapsulation Comparison
A.1. Overview
A.2. Extensibility
A.2.1. Innate Extensibility Support
A.2.2. Extension Parsing
A.2.3. Critical Extensions
A.2.4. Maximal Header Length
A.3. Encapsulation Header
A.3.1. Virtual Network Identifier (VNI)
A.3.2. Next Protocol
A.3.3. Other Header Fields
A.4. Comparison Summary
Acknowledgements
Contributors
Authors' Addresses
The NVO3 Working Group is chartered to gather requirements and develop solutions for network virtualization data planes based on encapsulation of virtual network traffic over an IP-based underlay data plane. Requirements include due consideration for OAM and security. Based on these requirements, the WG was to select, extend, and/or develop one or more data plane encapsulation formats.
NVO3ワーキンググループは、IPベースのアンダーレイデータプレーンでの仮想ネットワークトラフィックのカプセル化に基づいて、要件を収集し、ネットワーク仮想化データプレーンのソリューションを開発するようにチャーターされています。要件には、OAMとセキュリティの適切な考慮が含まれます。これらの要件に基づいて、WGは、1つのデータプレーンカプセル化形式を選択、拡張、および/または開発することでした。
This led to WG Internet-Drafts and an RFC describing three encapsulations as follows:
これにより、WGインターネットドラフトと、次の3つのカプセルを説明するRFCが発生しました。
* "Geneve: Generic Network Virtualization Encapsulation" [RFC8926]
* 「Geneve：Generic Network Virtualization capsulation」[RFC8926]
* "Generic UDP Encapsulation" [GUE]
* 「ジェネリックUDPカプセル化」[gue]
* "Generic Protocol Extension for VXLAN (VXLAN-GPE)" [VXLAN-GPE]
* 「VXLANの一般的なプロトコル拡張（VXLAN-GPE）」[VXLAN-GPE]
Discussion on the list and in face-to-face meetings identified a number of technical problems with each of these encapsulations. Furthermore, there was a clear consensus at the 96th IETF meeting in Berlin that the working group should progress only one data plane encapsulation, to maximize interoperability. In order to overcome a deadlock on the encapsulation decision, the WG consensus was to form a Design Team [RFC2418] to resolve this issue and provide initial considerations.
リストに関する議論と対面会議で、これらの各カプセルに関する多くの技術的な問題が特定されました。さらに、ベルリンでの第96回IETF会議で、ワーキンググループは、相互運用性を最大化するために、1つのデータプレーンカプセル化のみを進めるべきであるという明確なコンセンサスがありました。カプセル化決定のデッドロックを克服するために、WGコンセンサスは、この問題を解決し、最初の考慮事項を提供するために設計チーム[RFC2418]を形成することでした。
The Design Team was to select one of the proposed encapsulations and enhance it to address the technical concerns. The goals were simple evolution of deployed networks as well as applicability to all locations in the NVO3 architecture. The Design Team was to specifically select a design that allows for future extensibility but is not burdensome on hardware implementations. The selected design also needed to operate well with the Internet Control Message Protocol (ICMP) and in Equal-Cost Multipath (ECMP) environments. If further extensibility is required, then it should be done in such a manner that it does not require the consent of an entity outside of the IETF.
設計チームは、提案されたカプセルの1つを選択し、技術的な懸念に対処するためにそれを強化することでした。目標は、展開されたネットワークの単純な進化と、NVO3アーキテクチャのすべての場所への適用性でした。設計チームは、将来の拡張性を可能にするが、ハードウェアの実装では負担ではないデザインを具体的に選択することでした。選択された設計では、インターネット制御メッセージプロトコル（ICMP）および等しいマルチパス（ECMP）環境でうまく動作する必要がありました。さらに拡張性が必要な場合は、IETF以外のエンティティの同意を必要としないような方法で行う必要があります。
The output of the Design Team was then processed through the working group, resulting in a working group consensus for this document.
その後、設計チームの出力はワーキンググループを通じて処理され、このドキュメントのワーキンググループコンセンサスが生じました。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The following abbreviations and acronyms are used in this document:
このドキュメントでは、次の略語と頭字語が使用されています。
ACL:
ACL:
Access Control List
アクセス制御リスト
ECMP:
ECMP：
Equal-Cost Multipath
等しいコストマルチパス
EVPN:
EVPN：
Ethernet VPN [RFC8365]
イーサネットVPN [RFC8365]
Geneve:
Geneve：
Generic Network Virtualization Encapsulation [RFC8926]
一般的なネットワーク仮想化カプセル化[RFC8926]
GPE:
GPE:
Generic Protocol Extension
一般的なプロトコル拡張
GUE:
GUE:
Generic UDP Encapsulation [GUE]
ジェネリックUDPカプセル化[gue]
HMAC:
hmac：
Hash-Based Message Authentication Code [RFC2104]
ハッシュベースのメッセージ認証コード[RFC2104]
IEEE:
IEEE：
Institute for Electrical and Electronic Engineers (<https://www.ieee.org/>)
電気エンジニアのための研究所（<https://www.ieee.org/>）
NIC:
NIC:
Network Interface Card (refers to network interface hardware that is not necessarily a discrete "card")
ネットワークインターフェイスカード（必ずしも個別の「カード」ではないネットワークインターフェイスハードウェアを指します）
NSH:
NSH:
Network Service Header [RFC8300]
ネットワークサービスヘッダー[RFC8300]
NVA:
NVA:
Network Virtualization Authority
ネットワーク仮想化権限
NVE:
NVE:
Network Virtual Edge (refers to an NVE device)
ネットワーク仮想エッジ（NVEデバイスを指します）
NVO3:
NVO3：
Network Virtualization over Layer 3
レイヤー3上のネットワーク仮想化
OAM:
OAM:
Operations, Administration, and Maintenance [RFC6291]
運用、管理、およびメンテナンス[RFC6291]
PWE3:
PWE3：
Pseudowire Emulation Edge-to-Edge
Pseudowireエミュレーションエッジとエッジ
TCAM:
TCAM：
Ternary Content-Addressable Memory
三元コンテンツアドレス可能なメモリ
TLV:
TLV:
Type-Length-Value
タイプ長価値
Transit device:
トランジットデバイス：
Refers to underlay network devices between NVEs.
NVE間のネットワークデバイスの下層を指します。
UUID:
uuid：
Universally Unique Identifier
普遍的に一意の識別子
VNI:
VNI:
Virtual Network Identifier
仮想ネットワーク識別子
VXLAN:
vxlan：
Virtual eXtensible Local Area Network [RFC7348]
仮想拡張可能なローカルエリアネットワーク[RFC7348]
The following subsections describe issues with current encapsulations as discussed by the NVO3 WG. Numerous extensions and options have been designed for GUE and Geneve that may help resolve some of these issues, but these have not yet been validated by the WG.
以下のサブセクションでは、NVO3 WGで説明されている現在のカプセルの問題について説明しています。これらの問題のいくつかを解決するのに役立つかもしれないGueとGeneveのために多数の拡張とオプションが設計されていますが、これらはまだWGによって検証されていません。
Also included are diagrams and information on the candidate encapsulations. These are mostly copied from other documents. Since each protocol is assumed to be sent over UDP, an initial UDP header is shown that would be preceded by an IPv4 or IPv6 header.
また、候補者のカプセルに関する図と情報も含まれています。これらは主に他のドキュメントからコピーされています。各プロトコルはUDPを介して送信されると想定されるため、IPv4またはIPv6ヘッダーが先行する最初のUDPヘッダーが示されています。
The Geneve packet format, taken from [RFC8926], is shown in Figure 1 below.
[RFC8926]から取得したGeneveパケット形式を以下の図1に示します。
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
Outer UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port = 6081 Geneve |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Geneve Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| Opt Len |O|C| Rsvd. | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Variable-Length Options ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Geneve Header
図1：Geneveヘッダー
The type of payload being carried is indicated by an Ethertype [RFC9542] in the Protocol Type field in the Geneve header; Ethernet itself is represented by Ethertype 0x6558. See [RFC8926] for details concerning UDP header fields. The O bit indicates an OAM packet. The Geneve C bit is the "Critical" bit, which means that the options must be processed or the packet discarded.
運ばれるペイロードのタイプは、GeneveヘッダーのプロトコルタイプフィールドのEtherType [RFC9542]によって示されます。イーサネット自体は、EtherType 0x6558で表されます。UDPヘッダーフィールドに関する詳細については、[RFC8926]を参照してください。OビットはOAMパケットを示します。Geneve Cビットは「クリティカル」ビットです。つまり、オプションを処理するか、パケットを破棄する必要があります。
Issues with Geneve [RFC8926] are as follows:
Geneve [RFC8926]の問題は次のとおりです。
* Geneve can't be implemented cost-effectively in all use cases because the variable-length header and order of the TLVs make it costly (in terms of number of gates) to implement in hardware.
* Geneveは、すべてのユースケースで費用対効果に実装できません。これは、TLVの可変長ヘッダーと順序により、ハードウェアに実装するために（ゲートの数の点で）費用がかかるためです。
* The header doesn't fit into the largest commonly available parse buffer (256 bytes in a NIC). Thus, doubling the buffer size can't be justified unless it is mandatory for hardware to process additional option fields.
* ヘッダーは、一般的に利用可能な最大のパースバッファー（NICで256バイト）に収まりません。したがって、ハードウェアが追加のオプションフィールドを処理することが必須でない限り、バッファサイズを2倍にすることはできません。
The selection of Geneve despite these issues may be the result of the Geneve design effort, assuming that the Geneve header would typically be delivered to a server and parsed in software.
これらの問題にもかかわらず、Geneveの選択は、Geneveヘッダーが通常サーバーに配信され、ソフトウェアで解析されると仮定して、Geneve Designの取り組みの結果である可能性があります。
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
UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port = 6080 GUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GUE Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |C| Hlen | Proto/ctype | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Extensions Fields (optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: GUE Header
図2：gueヘッダー
The type of payload being carried is indicated by an IANA protocol number in the Proto/ctype field. The GUE C bit (Control bit) indicates a control packet.
運ばれるペイロードのタイプは、Proto/CTYPEフィールドのIANAプロトコル番号によって示されます。Gue Cビット（コントロールビット）は、コントロールパケットを示します。
Issues with GUE [GUE] are as follows:
Gue [gue]の問題は次のとおりです。
* There were a significant number of objections to GUE related to the complexity of its implementation in hardware, similar to those noted for Geneve above, such as the variable length and possible high maximum length of the header.
* ハードウェアでのその実装の複雑さに関連するGueにはかなりの数の異議がありました。これは、上記のGeneveに記載されているものと同様に、さまざまな長さやヘッダーの最大長さの可能性などです。
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
Outer UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port = 4790 GPE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VXLAN-GPE Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|Ver|I|P|B|O| Reserved | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: GPE Header
図3：GPEヘッダー
The type of payload being carried is indicated by the Next Protocol field using a registry specific to VXLAN-GPE. The I bit indicates that the VNI is valid. The P bit indicates that the Next Protocol field is valid. The B bit indicates that the packet is an ingress replicated Broadcast, Unknown Unicast, or Multicast packet. The O bit indicates an OAM packet.
運ばれるペイロードのタイプは、VXLAN-GPEに固有のレジストリを使用して、次のプロトコルフィールドで示されます。Iビットは、VNIが有効であることを示します。Pビットは、次のプロトコルフィールドが有効であることを示します。Bビットは、パケットがイングレス複製ブロードキャスト、不明なユニキャスト、またはマルチキャストパケットであることを示しています。OビットはOAMパケットを示します。
Issues with VXLAN-GPE [VXLAN-GPE] are as follows:
VXLAN-GPE [VXLAN-GPE]の問題は次のとおりです。
* GPE is not day one backwards compatible with VXLAN [RFC7348]. Although the frame format is similar, it uses a different UDP port, so it would require changes to existing implementations even if the rest of the GPE frame were the same.
* GPEは、VXLAN [RFC7348]と互換性がある初日はありません。フレーム形式は似ていますが、異なるUDPポートを使用するため、GPEフレームの残りの部分が同じであっても、既存の実装の変更が必要になります。
* GPE is insufficiently extensible. It adds a Next Protocol field and some flag bits to the VXLAN header but is not otherwise extensible.
* GPEの拡張が不十分です。次のプロトコルフィールドといくつかのフラグビットをVXLANヘッダーに追加しますが、それ以外の場合は拡張できません。
* As discussed in Section 6.2.2, security (e.g., of the VNI) has not been addressed by GPE. Although a shim header could be added for security and to support other extensions, this has not been defined yet. More study would be needed to understand the implication of such a shim on offloading in NICs.
* セクション6.2.2で説明したように、セキュリティ（例：VNIの）はGPEによって対処されていません。セキュリティのために、および他の拡張機能をサポートするためにシムヘッダーを追加できますが、これはまだ定義されていません。NICでのオフロードに関するこのようなシムの意味を理解するには、さらに研究が必要になります。
Appendix A includes a detailed comparison between the three proposed encapsulations. The comparison indicates several common properties but also three major differences among the encapsulations:
付録Aには、3つの提案されたカプセルの詳細な比較が含まれています。この比較は、いくつかの一般的な特性を示していますが、カプセルの間の3つの大きな違いも示しています。
* Extensibility: Geneve and GUE were defined with built-in extensibility, while VXLAN-GPE is not inherently extensible. Note that any of the three encapsulations can be extended using the Network Service Header (NSH) [RFC8300].
* 拡張性：GeneveとGueは組み込みの拡張性で定義されましたが、VXLAN-GPEは本質的に拡張できません。ネットワークサービスヘッダー（NSH）[RFC8300]を使用して、3つのカプセルのいずれかを拡張できることに注意してください。
* Extension method: Geneve is extensible using Type-Length-Value (TLV) fields, while GUE uses a small set of possible extensions and a set of flags that indicate which extensions are present.
* 拡張方法：Geneveは型長さ（TLV）フィールドを使用して拡張可能ですが、Gueは、可能な拡張機能の小さなセットと、どの拡張機能が存在するかを示すフラグのセットを使用します。
* Length field: Geneve and GUE include a Length field, indicating the length of the encapsulation header, while VXLAN-GPE does not include such a field. Thus, it may be harder to skip the encapsulation header with VXLAN-GPE
* 長さフィールド：GeneveとGueには長さフィールドが含まれ、カプセル化ヘッダーの長さを示しますが、VXLAN-GPEにはそのようなフィールドは含まれません。したがって、vxlan-gpeでカプセル化ヘッダーをスキップすることは難しいかもしれません
Extensions that are not vendor-specific, such as TLVs, MUST follow the standardization process. The following use cases for extensions show that there is a strong requirement to support variable-length extensions with possible different subtypes.
TLVなど、ベンダー固有の拡張機能は、標準化プロセスに従う必要があります。拡張の以下のユースケースは、可能な異なるサブタイプで可変長拡張機能をサポートするために強力な要件があることを示しています。
In several scenarios, it is beneficial to make information available to the operator about the path a packet took through the network or through a network device as well as information about associated telemetry.
いくつかのシナリオでは、パケットがネットワークまたはネットワークデバイスを介してとり、関連するテレメトリに関する情報をパケットがとるパスに関する情報をオペレーターに利用できるようにすることが有益です。
This includes not only tasks like debugging, troubleshooting, and network planning and optimization but also policy or service level agreement compliance checks.
これには、デバッグ、トラブルシューティング、ネットワークの計画と最適化などのタスクだけでなく、ポリシーまたはサービスレベルの契約コンプライアンスチェックも含まれます。
Packet scheduling algorithms, especially for balancing traffic across equal-cost paths or links, often leverage information contained within the packet, such as protocol number, IP address, or Message Authentication Code (MAC) address. Thus, probe packets would need to be either sent between the exact same endpoints with the exact same parameters or artificially constructed as "fake" packets and inserted along the path. Both approaches are often not feasible from an operational perspective because access to the end system is not feasible or the diversity of parameters and associated probe packets to be created is simply too large. An extension providing an in-band telemetry mechanism [RFC9197] is an alternative in those cases.
パケットスケジューリングアルゴリズム、特に等しいコストのパスまたはリンク全体のトラフィックのバランスをとるために、プロトコル番号、IPアドレス、またはメッセージ認証コード（MAC）アドレスなど、パケット内に含まれる情報を活用することがよくあります。したがって、プローブパケットは、まったく同じパラメーターを使用してまったく同じエンドポイント間で送信するか、「偽の」パケットとして人為的に構築され、パスに沿って挿入する必要があります。エンドシステムへのアクセスが実行不可能であるか、作成される関連プローブパケットの多様性が大きすぎるため、両方のアプローチは運用上の観点からは実行不可能であることがよくあります。これらの場合、帯域内のテレメトリメカニズム[RFC9197]を提供する拡張機能は代替です。
Since the currently proposed NVO3 encapsulations do not protect their headers, a single bit corruption in the VNI field could deliver a packet to the wrong tenant. Extension headers are needed to use any sophisticated security.
現在提案されているNVO3のカプセルはヘッダーを保護していないため、VNIフィールドでの単一の破損は、間違ったテナントにパケットを提供する可能性があります。洗練されたセキュリティを使用するには、拡張ヘッダーが必要です。
The possibility of VNI spoofing with an NVO3 protocol is exacerbated by using UDP. Systems typically have no restrictions on applications being able to send to any UDP port, so an unprivileged application can trivially spoof VXLAN [RFC7348] packets, using arbitrary VNIs, for instance.
NVO3プロトコルを使用したVNIスプーフィングの可能性は、UDPを使用して悪化します。システムは通常、任意のUDPポートに送信できるアプリケーションに制限がないため、任意のVNIを使用して、任意のVXLAN [RFC7348]パケットを実質的にスプーフィングすることができます。
One can envision support of an HMAC-like Message Authentication Code (MAC) [RFC2104] in an NVO3 extension to authenticate the header and the outer IP addresses, thereby preventing attackers from injecting packets with spoofed VNIs.
NVO3拡張機能でHMACのようなメッセージ認証コード（MAC）[RFC2104]のサポートを想像することができます。ヘッダーと外側のIPアドレスを認証するため、攻撃者がスプーフィングされたVNIでパケットを注入するのを防ぎます。
Another aspect of security is payload security. Essentially, this makes packets that look like the following:
セキュリティのもう1つの側面は、ペイロードセキュリティです。基本的に、これにより、次のように見えるパケットが作成されます。
IP|UDP|NVO3 Encap|DTLS/IPsec-ESP Extension|payload.
This is desirable because:
これは、次のように望ましいものです。
* we still have the UDP header for ECMP,
* ECMP用のUDPヘッダーはまだあります。
* the NVO3 header is in plain text so it can be read by network elements, and
* NVO3ヘッダーはプレーンテキストにあるため、ネットワーク要素で読むことができ、
* different security or other payload transforms can be supported on a single UDP port (we don't need a separate UDP port for DTLS/ IPsec; see [RFC9147] and [RFC6071], respectively).
* 異なるセキュリティまたはその他のペイロード変換は、単一のUDPポートでサポートできます（DTLS/ IPSECには個別のUDPポートは必要ありません。それぞれ[RFC9147]と[RFC6071]を参照）。
Another use case would be to carry the Group-Based Policy (GBP) source group information within a NVO3 header extension in a similar manner as has been implemented for VXLAN [VXLAN-GROUP]. This allows various forms of policy such as access control and QoS to be applied between abstract groups rather than coupled to specific endpoint addresses.
別のユースケースは、VXLAN [VXLAN-GROUP]に実装されているのと同様の方法で、NVO3ヘッダー拡張機能内でグループベースのポリシー（GBP）ソースグループ情報を携帯することです。これにより、特定のエンドポイントアドレスと結合するのではなく、アクセス制御やQoSなどのさまざまな形式のポリシーを抽象グループ間で適用できます。
Hardware restrictions should be taken into consideration along with future hardware enhancements that may provide more flexible metadata (MD) processing. However, the set of options that need to and will be implemented in hardware will be a subset of what is implemented in software. This is because software NVEs are likely to grow features, and hence option support, at a more rapid rate.
ハードウェアの制限は、より柔軟なメタデータ（MD）処理を提供する可能性のある将来のハードウェア強化とともに考慮に入れる必要があります。ただし、ハードウェアに必要なものと実装されるオプションのセットは、ソフトウェアに実装されているもののサブセットになります。これは、ソフトウェアNVEが機能を拡大し、したがってオプションサポートがより速いレートで成長する可能性が高いためです。
It is hard to predict which options will be implemented in which piece of hardware and when. That depends on whether the hardware will be in the form of:
どのオプションがどのハードウェアといつ実装されるかを予測することは困難です。これは、ハードウェアが次の形であるかどうかによって異なります。
* a NIC providing increasing offload capabilities to software NVEs, or
* ソフトウェアNVESに増加するオフロード機能を提供するNIC、または
* a switch chip being used as an NVE gateway towards non-NVO3 parts of the network, or even
* ネットワークの非NVO3部品に向けてNVEゲートウェイとして使用されているスイッチチップ、または
* a transit device that participates in the NVO3 data plane, e.g., for OAM purposes.
* NVO3データプレーンに参加するトランジットデバイス、たとえば、OAMの目的で。
A result of this is that it doesn't look useful to prescribe some order to the options so that the ones that are likely to be implemented in hardware come first. We can't decide such an order when we define the options; however, a control plane can enforce such an order for some hardware implementations.
その結果、オプションにいくつかの順序を処方することは役に立たないように見え、ハードウェアに実装される可能性が高いものが最初に来るようにします。オプションを定義するとき、そのような順序を決定することはできません。ただし、コントロールプレーンは、一部のハードウェア実装のこのような注文を強制することができます。
We do know that hardware initially needs to be able to efficiently skip over the NVO3 header to find the inner payload. That is needed both for NICs implementing various TCP offload mechanisms and for transit devices and NVEs applying policy or ACLs to the inner payload.
ハードウェアは、最初はNVO3ヘッダーを効率的にスキップして内部ペイロードを見つける必要があることを知っています。これは、さまざまなTCPオフロードメカニズムを実装するNICと、内部ペイロードにポリシーまたはACLを適用する輸送デバイスとNVEの両方に必要です。
Extension header length has a significant impact on hardware and software implementations. A maximum total header length that is too small will unnecessarily constrain software flexibility. A maximum total header length that is too large will place a nontrivial cost on hardware implementations. Thus, the DT recommends that there be a minimum and maximum total available extension header length specified. The maximum total header length is determined by the size of the bit field allocated for the total extension header length field. The risk with this approach is that it may be difficult to extend the total header size in the future. The minimum total header length is determined by a requirement in the specifications that all implementations must meet. The risk with this approach is that all implementations will only implement support for the minimum total header length, which would then become the de facto maximum total header length.
拡張ヘッダーの長さは、ハードウェアとソフトウェアの実装に大きな影響を与えます。小さすぎる最大総ヘッダー長は、ソフトウェアの柔軟性を不必要に制約します。大きすぎる最大総ヘッダー長は、ハードウェアの実装に非些細なコストを課します。したがって、DTは、指定された最小および最大利用可能な拡張ヘッダー長があることを推奨しています。最大総ヘッダー長は、総拡張ヘッダー長フィールドに割り当てられたビットフィールドのサイズによって決定されます。このアプローチのリスクは、将来的に総ヘッダーサイズを拡張することが難しいかもしれないということです。最小総ヘッダー長は、すべての実装が満たさなければならない仕様の要件によって決定されます。このアプローチのリスクは、すべての実装が最小総ヘッダー長のサポートのみを実装し、それが事実上最大総ヘッダー長になることです。
The recommended minimum total available header length is 64 bytes.
推奨される最小総利用可能なヘッダー長は64バイトです。
The size of an extension header should always be 4-byte aligned.
拡張ヘッダーのサイズは常に4バイトアライメントする必要があります。
The maximum length of a single option should be large enough to meet the different extension use case requirements, e.g., for in-band telemetry and future use.
単一のオプションの最大長さは、バンド内のテレメトリや将来の使用のために、異なる拡張ユースケースの要件を満たすのに十分な大きさである必要があります。
To support hardware nodes at the target NVE or at a transit device that can process one or a few extension headers in TCAM, a control plane in such a deployment could signal a capability to ensure that a specific extension header will always appear in a specific order, for example, that such a specific extension header appear first in the packet.
ターゲットNVEまたはTCAMで1つまたはいくつかの拡張ヘッダーを処理できるトランジットデバイスでハードウェアノードをサポートするために、このような展開の制御プレーンは、特定の拡張ヘッダーが常に特定の順序で表示されることを確認する機能を信号する可能性があります、たとえば、このような特定の拡張ヘッダーがパケットに最初に表示されること。
The order of the extension headers should be hardware friendly for both the sender and the receiver and possibly some transit devices as well. This may require that the extension headers and their order be determined dynamically based on the hardware of those devices.
拡張ヘッダーの順序は、送信者と受信機の両方にとってハードウェアに優しいものでなければなりません。これには、これらのデバイスのハードウェアに基づいて、拡張ヘッダーとその順序を動的に決定する必要があります。
Transit devices don't participate in control plane communication between the endpoints and are not required to process the extension headers; however, if they do, they may need to process only a small subset of the extension headers that will be consumed by target NVEs.
トランジットデバイスは、エンドポイント間のコントロールプレーン通信に参加せず、拡張ヘッダーを処理する必要はありません。ただし、もしそうなら、ターゲットNVEによって消費される拡張ヘッダーの小さなサブセットのみを処理する必要がある場合があります。
If there is a well-known initial set of options that is likely to be implemented in software and in hardware, it can be efficient to use the bit fields approach to indicate the presence of extensions as in GUE. However, as described in Section 6.3, if options are added over time and different subsets of options are likely to be implemented in different pieces of hardware, then it would be hard for the IETF to specify which options should get the early bit fields. TLVs are a lot more flexible, which avoids the need to determine the relative importance of different options. However, general TLVs of arbitrary order, size, and repetition are difficult to implement in hardware. A middle ground is to use TLVs with restrictions on their size and alignment, observing that individual TLVs can have a fixed length, and to support via the control plane a method such that an NVE will only receive options that it needs and implements. The control plane approach can potentially be used to control the order of the TLVs sent to a particular NVE. Note that transit devices are not likely to participate in the control plane; hence, to the extent that they need to participate in option processing, some other method must be used. Transit devices would have issues with future GUE bit fields being defined for future options as well.
ソフトウェアやハードウェアに実装される可能性が高いオプションのよく知られた初期セットがある場合、BITフィールドアプローチを使用して、GUEのように拡張機能の存在を示すことが効率的です。ただし、セクション6.3で説明したように、オプションが時間の経過とともに追加され、オプションの異なるサブセットが異なるハードウェアに実装される可能性が高い場合、IETFが早期ビットフィールドを取得するオプションを指定するのは困難です。TLVははるかに柔軟性があり、異なるオプションの相対的な重要性を判断する必要性を回避します。ただし、任意の順序、サイズ、および繰り返しの一般的なTLVは、ハードウェアに実装することが困難です。中間点は、サイズとアラインメントに制限を備えたTLVを使用し、個々のTLVが固定された長さを持つことができることを観察し、NVEが必要なオプションのみを受け取るように制御プレーンを介してサポートすることです。コントロールプレーンアプローチは、特定のNVEに送信されるTLVの順序を制御するために潜在的に使用できます。トランジットデバイスはコントロールプレーンに参加する可能性は低いことに注意してください。したがって、オプション処理に参加する必要がある限り、他の方法を使用する必要があります。トランジットデバイスには、将来のオプションについても定義されている将来のGueビットフィールドに関する問題があります。
A benefit of TLVs from a hardware perspective is that they are self describing, i.e., all the information is in the TLV. In a bit field approach, the hardware needs to look up the bit to determine the length of the data associated with the bit through some separate table, which would add hardware complexity.
ハードウェアの観点からのTLVの利点は、それらが自己記述していること、つまりすべての情報がTLVにあることです。ビットフィールドアプローチでは、ハードウェアはビットを検索して、ハードウェアの複雑さを追加する別のテーブルを介して、ビットに関連付けられたデータの長さを決定する必要があります。
There are use cases where multiple modules of software are running on an NVE. These can be modules such as a diagnostic module by one vendor that does packet sampling and another module from a different vendor that implements a firewall. Using a TLV format, it is easier to have different software modules process different TLVs without conflicting with each other. Such TLVs could be standard extensions or vendor-specific extensions. This can help with hardware modularity as well. There are some implementations with options that allow different software modules, like MAC learning and security, to process different options.
ソフトウェアの複数のモジュールがNVEで実行されているユースケースがあります。これらは、パケットサンプリングを行う1つのベンダーによる診断モジュールなどのモジュールと、ファイアウォールを実装する別のベンダーからの別のモジュールです。TLV形式を使用すると、異なるソフトウェアモジュールが異なるTLVを互いに競合することなく処理する方が簡単です。このようなTLVは、標準の拡張機能またはベンダー固有の拡張機能です。これは、ハードウェアのモジュール性にも役立ちます。Mac LearningやSecurityなどのさまざまなソフトウェアモジュールがさまざまなオプションを処理できるようにするオプションを備えたいくつかの実装があります。
Given that we want to allow considerable flexibility and extensibility (e.g., for software NVEs), yet want to be able to support important extensions in less flexible contexts such as hardware NVEs, it is useful to consider the control plane. By control plane in this section we mean protocols, such as EVPN [RFC8365] and others, and deployment-specific configurations.
かなりの柔軟性と拡張性（ソフトウェアNVEの場合）を許可したいが、ハードウェアNVEなどの柔軟性の低いコンテキストで重要な拡張機能をサポートできるようにしたいと考えているため、コントロールプレーンを検討すると便利です。このセクションの制御面とは、EVPN [RFC8365]などのプロトコルを意味し、展開固有の構成を意味します。
If each NVE can express in the control plane that it only supports certain extensions (which could be a single extension, or a few), and the source NVEs only include supported extensions in the NVO3 packets, then the target NVE can use a simpler parser (e.g., a TCAM might be usable to look for a single NVO3 extension) and the depth of the inner payload in the NVO3 packet will be minimized. Furthermore, if the target NVE cares about a few extensions and can express in the control plane the desired order of those extensions in the NVO3 packets, then the deployment can provide useful functionality with simplified hardware requirements for the target NVE.
各NVEは、制御プレーンで特定の拡張機能のみをサポートしていることを表現できます（単一の拡張機能、または少数である可能性があります）、ソースNVEにはNVO3パケットのサポートされた拡張機能のみが含まれている場合、ターゲットNVEはよりシンプルなパーサーを使用できます。（たとえば、TCAMは単一のNVO3拡張機能を探すために使用できる場合があります）、NVO3パケットの内部ペイロードの深さが最小限に抑えられます。さらに、ターゲットNVEがいくつかの拡張機能を重視し、コントロールプレーンでNVO3パケット内のこれらの拡張機能の目的の順序を表現できる場合、展開はターゲットNVEの単純化されたハードウェア要件で有用な機能を提供できます。
Transit devices that are not aware of the NVO3 extensions somewhat benefit from such an approach, since the inner payload is less deep in the packet if no extraneous extension headers are included in the packet. In general, a transit device is not likely to participate in the NVO3 control plane. However, configuration mechanisms can take into account limitations of the transit devices used in particular deployments.
NVO3拡張機能を認識していないトランジットデバイスは、このようなアプローチから多少メリットがあります。これは、内側のペイロードがパケットに含まれていない場合、パケットの奥深くないためです。一般に、トランジットデバイスはNVO3コントロールプレーンに参加する可能性は低いです。ただし、構成メカニズムは、特定の展開で使用されるトランジットデバイスの制限を考慮することができます。
Note that with this approach, different NVEs could desire different extensions or sets of extensions, which means that the source NVE needs to be able to place different sets of extensions in different NVO3 packets, and perhaps in a different order. It also assumes that underlay multicast or replication servers are not used together with NVO3 extension headers.
このアプローチでは、異なるNVEが異なる拡張または拡張セットを要求する可能性があることに注意してください。つまり、ソースNVEは、異なるNVO3パケットに異なる拡張機能を配置できる必要があることを意味します。また、アンダーレイマルチキャストまたは複製サーバーがNVO3拡張ヘッダーと一緒に使用されないことを想定しています。
There is a need to consider mandatory extensions versus optional extensions. Mandatory extensions require the receiver to drop the packet if the extension is unknown. A control plane mechanism can prevent the need for dropping unknown extensions, since they would not be included to target NVEs that do not support them.
必須の拡張機能とオプションの拡張機能を考慮する必要があります。必須の拡張機能では、拡張機能が不明な場合は、受信機がパケットをドロップする必要があります。制御プレーンメカニズムは、それらをサポートしていないNVEをターゲットに含めることはないため、未知の拡張機能を削除する必要性を防ぐことができます。
The control planes defined today need to add the ability to describe the different encapsulations. Thus, perhaps EVPN [RFC8365] and any other control plane protocol that the IETF defines should have a way to indicate the supported NVO3 extensions and their order for each of the encapsulations supported.
今日定義されているコントロールプレーンは、さまざまなカプセルを記述する機能を追加する必要があります。したがって、おそらく、IETFが定義するEVPN [RFC8365]およびその他のコントロールプレーンプロトコルは、サポートされているNVO3拡張機能と、サポートされている各カプセルの順序を示す方法を持つ必要があります。
Developing a separate document on guidance for option processing and control plane participation should be considered. This should provide examples and guidance on the range of usage models and deployment scenarios for specific options. It should also provide examples of option ordering that are relevant for that specific deployment. This includes endpoints and middleboxes that are using the options. Having the control plane negotiate the constraints is the most appropriate and flexible way to address these requirements.
オプション処理および制御プレーンの参加に関するガイダンスに関する個別のドキュメントを作成することを検討する必要があります。これにより、特定のオプションの使用モデルと展開シナリオの範囲に関する例とガイダンスが提供されるはずです。また、その特定の展開に関連するオプション順序の例を提供する必要があります。これには、オプションを使用しているエンドポイントとミドルボックスが含まれます。制御プレーンに制約を交渉することは、これらの要件に対処するための最も適切で柔軟な方法です。
If there is a need for hosts to send and receive options in a split NVE case [RFC8394], this is possible using any of the existing extensible encapsulations (GPE with NSH, GUE, or Geneve) by defining a way to carry those over other transports. An NSH can already be used over different transports.
スプリットNVEケース[RFC8394]でホストがオプションを送信および受信する必要がある場合、これは、他の人の上にそれらを運ぶ方法を定義することにより、既存の拡張可能なカプセル（NSH、gue、またはgeneve）のいずれかを使用して可能です輸送。NSHは、さまざまな輸送ですでに使用できます。
If this is needed with other encapsulations, it can be done by defining an Ethertype so that it can be carried over Ethernet and IEEE Std 802.1Q [IEEE802.1Q].
これが他のカプセルで必要な場合は、イーサネットおよびIEEE STD 802.1Q [IEEE802.1Q]を介して持ち運ぶことができるように、EtherTypeを定義することで実行できます。
If there is a need to carry other encapsulations over MPLS, it would require an EVPN control plane to signal that other encapsulation headers and options will be present in front of the Layer 2 (L2) packet. The VNI can be ignored in the header, and the MPLS label will be the one used to identify the EVPN L2 instance.
MPLSで他のカプセルを携帯する必要がある場合、他のカプセル化ヘッダーとオプションがレイヤー2（L2）パケットの前に存在することを示すためにEVPNコントロールプレーンが必要です。VNIはヘッダーで無視でき、MPLSラベルはEVPN L2インスタンスを識別するために使用されます。
Whether we should make the VNI 32 bits or larger was one of the topics considered. The benefit of a 24-bit VNI would be to avoid unnecessary changes with existing proposals and implementations that are almost all, if not all, using a 24-bit VNI. If we need a larger VNI, perhaps for a telemetry case, an extension can be used to support that.
VNI 32ビット以上を作成する必要があるかどうかは、考慮されるトピックの1つでした。24ビットVNIの利点は、24ビットVNIを使用して、すべてではないにしても、ほぼすべてである既存の提案と実装による不必要な変更を回避することです。おそらくテレメトリの場合、より大きなVNIが必要な場合は、それをサポートするために拡張機能を使用できます。
The Design Team reported that Geneve was most suitable as a starting point for a proposed standard for network virtualization, for the following reasons given below. This conclusion was supported by the NVO3 Working Group.
デザインチームは、以下に示す以下の理由により、ネットワーク仮想化の提案された基準の出発点としてGeneveが最も適していると報告しました。この結論は、NVO3ワーキンググループによってサポートされていました。
1. On whether the VNI should be in the base header or in an extension header and whether it should be a 24-bit or 32-bit field (see Section 6.9), it was agreed that the VNI is critical information for network virtualization and MUST be present in all packets. It was also agreed that a 24-bit VNI, which is supported by Geneve, matches the existing widely used encapsulation formats, i.e., VXLAN [RFC7348] and Network Virtualization Using Generic Routing Encapsulation (NVGRE) [RFC7637], and hence is more suitable to use going forward.
1. VNIがベースヘッダーであるか拡張ヘッダーにあるか、24ビットまたは32ビットフィールドであるか（セクション6.9を参照）かどうかについて、VNIはネットワーク仮想化の重要な情報であり、すべてのパケットに存在します。また、Geneveによってサポートされている24ビットVNIが、既存の広く使用されているカプセル化形式、つまりVXLAN [RFC7348]と一般的なルーティングカプセル化（NVGRE）[RFC7637]を使用したネットワーク仮想化と一致することも同意しました。今後使用する。
2. The Geneve header has the total options length, which allows skipping over the options for NIC offload operations and transit devices to view flow information in the inner payload.
2. Geneveヘッダーには合計オプション長があり、NICオフロード操作とトランジットデバイスのオプションをスキップして、内部ペイロード内のフロー情報を表示できます。
3. The option of using an NSH [RFC8300] with VXLAN-GPE was considered, but given that an NSH is targeted at service chaining and contains service chaining information, it is less suitable for the network virtualization use case. The other downside of VXLAN-GPE was the lack of a header length in VXLAN-GPE, which makes skipping over the headers to process inner payloads more difficult. A total options length is present in Geneve. It is not possible to skip any options in the middle with VXLAN-GPE. In principle, a split between a base header and a header with options is interesting (whether that options header is an NSH or some new header without ties to a service path). Whether it would make sense to either use an NSH for this or define a new NVO3 options header was explored. However, this makes it slightly harder to find the inner payload since the Length field is not in the NVO3 header itself. Thus, one more field would have to be extracted to compute the start of the inner payload. Also, if the experience with IPv6 extension headers is a guide, there would be a risk that key pieces of hardware might not implement the options header, resulting in future calls to deprecate its use. Making the options part of the base NVO3 header has less of those issues. Even though the implementation of any particular option can't be predicted ahead of time, the option mechanism and ability to skip the options is likely to be broadly implemented.
3. VXLAN-GPEを使用してNSH [RFC8300]を使用するオプションを考慮しましたが、NSHがサービスチェーンをターゲットにし、サービスチェーン情報を含むことを考えると、ネットワーク仮想化の使用ケースにはそれほど適していません。VXLAN-GPEのもう1つの欠点は、VXLAN-GPEのヘッダー長がないことでした。これにより、ヘッダーをスキップして内部ペイロードを処理することがより困難になります。Geneveには合計オプションの長さが存在します。vxlan-gpeで中央のオプションをスキップすることはできません。原則として、オプションを備えたベースヘッダーとヘッダーの間の分割は興味深いものです（そのオプションヘッダーがNSHであるか、サービスパスとの関係のない新しいヘッダーであるかどうか）。これにNSHを使用するか、新しいNVO3オプションヘッダーを定義することが理にかなっているかどうかが調査されました。ただし、長さフィールドはNVO3ヘッダー自体にないため、内部ペイロードを見つけるのが少し難しくなります。したがって、内部ペイロードの開始を計算するために、もう1つのフィールドを抽出する必要があります。また、IPv6拡張ヘッダーのエクスペリエンスがガイドである場合、ハードウェアの重要な部分がオプションヘッダーを実装しない可能性があり、その使用を非難するための将来の呼び出しをもたらすリスクがあります。ベースNVO3ヘッダーのオプションの一部にするには、これらの問題が少なくなります。特定のオプションの実装を事前に予測することはできませんが、オプションのメカニズムとオプションをスキップする能力は広く実装される可能性があります。
4. The TLV style and bit field style of extension mechanisms were compared. It was deemed that parsing either TLVs or bit fields is expensive, and while bit fields may be simpler to parse, they are also more restrictive and require guessing which extensions will be widely implemented in order to get early bit assignments. Given that half the bits are already assigned in GUE, a widely deployed extension may appear in a flag extension, and this will require extra processing to dig the flag from the flag extension and then look for the extension itself. Also, bit fields are not flexible enough to address the requirements from OAM, telemetry, and security extensions for variable-length options and different subtypes of the same option. While TLVs are more flexible, a control plane can restrict the number of option TLVs as well as the order and size of the TLVs to limit this flexibility and make the TLVs simpler for a data plane implementation to handle.
4. 拡張メカニズムのTLVスタイルとビットフィールドスタイルを比較しました。TLVまたはビットフィールドのいずれかの解析は高価であると考えられており、ビットフィールドは解析がより簡単になる可能性がありますが、より制限的であり、早期ビットの割り当てを取得するためにどの拡張機能が広く実装されるかを推測する必要があります。ビットの半分がすでにGueに割り当てられていることを考えると、広く展開されている拡張機能がフラグ拡張機能に表示される場合があり、これにはフラグ拡張からフラグを掘り、拡張自体を探すために追加の処理が必要になります。また、ビットフィールドは、さまざまな長さのオプションと同じオプションの異なるサブタイプのOAM、テレメトリ、セキュリティ拡張機能の要件に対処するほど柔軟ではありません。TLVはより柔軟ですが、コントロールプレーンは、この柔軟性を制限し、データプレーンの実装を処理するためにTLVをより簡単にするために、TLVの順序とサイズを制御できます。
5. The multi-vendor NVE case was briefly discussed, as was the need to allow vendors to put their own extensions in the NVE header. This is possible with TLVs.
5. マルチベンダーNVEケースについては、ベンダーが独自の拡張機能をNVEヘッダーに配置できるようにする必要があるように、簡単に議論されました。これはTLVで可能です。
6. It was agreed that the C bit (Critical bit) in Geneve is helpful. This bit indicates that the header includes options that must be parsed, or else the packet must be discarded. The bit allows a receiver NVE to easily decide whether or not to process options (such as a UUID-based packet trace) and decide how an optional extension can be ignored. Thus, a Critical bit makes it easy for the NVE to skip over the options not marked with such a bit. Thus, the C bit should remain as defined in Geneve.
6. GeneveのCビット（クリティカルビット）が役立つことが合意されました。このビットは、ヘッダーに解析する必要があるオプションが含まれているか、パケットを破棄する必要があることを示しています。ビットにより、レシーバーNVEは、オプション（UUIDベースのパケットトレースなど）を処理するかどうかを簡単に決定し、オプションの拡張機能を無視する方法を決定できます。したがって、重要なビットにより、NVEがそれほどマークされていないオプションを簡単にスキップできます。したがって、Cビットは、Geneveで定義されているとおりのままでなければなりません。
7. There are already some extensions of varying sizes that are being discussed (see Section 6.2). By using Geneve options, it is possible to get in-band parameters like switch id, ingress port, egress port, internal delay, and queue size using TLV extensions for telemetry purposes from switches. It is also possible to add security extension TLVs like HMAC [RFC2104] and DTLS/IPsec (see [RFC9147] and [RFC6071], respectively) to authenticate the Geneve packet header and secure the Geneve packet payload by software or hardware tunnel endpoints. A Group-Based Policy extension TLV can be carried as well.
7. 議論されているさまざまなサイズのいくつかの拡張機能がすでにあります（セクション6.2を参照）。Geneveオプションを使用することにより、スイッチからTLV拡張機能を使用して、スイッチID、イングレスポート、出力ポート、内部遅延、キューサイズなどのバンド内パラメーターを取得することができます。また、HMAC [RFC2104]やDTLS/IPSEC（それぞれ[RFC9147]および[RFC6071]を参照）などのセキュリティ拡張TLVを追加して、Geneveパケットヘッダーを認証し、ソフトウェアまたはハードウェアトンネルエンドポイントによるGeneveパケットペイロードを確保することも可能です。グループベースのポリシー拡張TLVも運ぶことができます。
8. There are already implementations of Geneve options deployed in production networks. There is new hardware supporting Geneve TLV parsing as well. In addition, an In-band Telemetry (INT) specification [INT] is being developed by P4.org that illustrates the option of INT metadata carried over Geneve. Open Virtual Network (OVN) and Open vSwitch (OVS) [OVN] have also defined one or more option TLVs for Geneve.
8. 生産ネットワークに展開されているGeneveオプションの実装がすでにあります。Geneve TLVの解析もサポートする新しいハードウェアがあります。さらに、INバンドテレメトリ（INT）仕様[INT]がP4.ORGによって開発されており、Geneveを引き継いだINTメタデータのオプションを示しています。Open Virtual Network（OVN）およびOpen Vswitch（OVS）[OVN]は、Geneveの1つ以上のオプションTLVも定義しています。
9. Usage requirements (see Section 6) have been addressed while also considering requirements and implementations in general (including those for software and hardware).
9. 使用法の要件（セクション6を参照）に対処されている間、一般的な要件と実装（ソフトウェアとハードウェアを含む）も考慮しています。
There seems to be interest in standardizing some well-known secure option TLVs to secure the header and payload to guarantee encapsulation header integrity and tenant data privacy. The working group should consider standardizing such option(s).
有名な安全なオプションTLVを標準化して、ヘッダーとペイロードを保護して、カプセル化ヘッダーの整合性とテナントデータプライバシーを保証することに関心があるようです。ワーキンググループは、そのようなオプションの標準化を検討する必要があります。
The following enhancements to Geneve are recommended to make it more suitable to hardware and yet provide flexibility for software:
GeneVeの以下の機能強化は、ハードウェアにより適したものにし、ソフトウェアに柔軟性を提供するために推奨されます。
* The following sort of text is recommended in Geneve documents: while TLVs are more flexible, a control plane can restrict the number of option TLVs as well as the order and size of the TLVs to make it simpler for a data plane implementation in software or hardware to handle. For example, there may be some critical information such as a secure hash that must be processed in a certain order at lowest latency.
* Geneveドキュメントでは、次の種類のテキストが推奨されます。TLVはより柔軟ですが、コントロールプレーンは、ソフトウェアまたはハードウェアのデータプレーンの実装のために簡単にするためにTLVの順序とサイズを制限することができます。処理する。たとえば、最も低いレイテンシで特定の順序で処理する必要がある安全なハッシュなどの重要な情報がある場合があります。
* A control plane can negotiate a subset of option TLVs and certain TLV ordering, as well as limiting the total number of option TLVs present in the packet, for example, to allow for hardware capable of processing fewer options. Hence, the control plane needs to have the ability to describe the supported TLVs subset and their order.
* コントロールプレーンは、オプションTLVのサブセットと特定のTLV順序をネゴシエートするだけでなく、パケットに存在するオプションTLVの総数を制限することができます。たとえば、より少ないオプションを処理できるハードウェアを可能にします。したがって、コントロールプレーンには、サポートされているTLVSサブセットとその順序を記述する能力が必要です。
* The Geneve documents should specify that the subset and order of option TLVs SHOULD be configurable for each remote NVE in the absence of a protocol control plane.
* Geneveドキュメントは、プロトコル制御プレーンがない場合、オプションTLVのサブセットと順序が各リモートNVEに対して構成可能であることを指定する必要があります。
* Geneve should follow fragmentation recommendations in overlay services like PWE3 and the L2/L3 VPN recommendations to guarantee larger MTUs for the tunnel overhead ([RFC3985], Section 5.3).
* Geneveは、PWE3やL2/L3 VPNの推奨事項などのオーバーレイサービスの断片化の推奨事項に従って、トンネルオーバーヘッドのより大きなMTUを保証する必要があります（[RFC3985]、セクション5.3）。
* The Geneve documents should provide a recommendation for C bit (Critical bit) processing. This text could specify how critical bits can be used with control planes and specify the critical options.
* Geneveドキュメントは、Cビット（クリティカルビット）処理の推奨事項を提供する必要があります。このテキストは、コントロールプレーンで重要なビットをどのように使用できるかを指定し、重要なオプションを指定できます。
* Given that there is a telemetry option use case for a length of 256 bytes, it is recommended that Geneve increase the single TLV option length to 256.
* 256バイトの長さのテレメトリーオプションユースケースがあることを考えると、Geneveは単一のTLVオプションの長さを256に増やすことをお勧めします。
* Geneve address requirements for OAM considerations for alternate marking and for performance measurements that need a 2-bit field in the header should be considered and the need for the current OAM bit in the Geneve header should be clarified.
* Geneveは、ヘッダーに2ビットフィールドを必要とする代替マーキングとパフォーマンス測定のOAM考慮事項の要件を考慮する必要があり、Geneveヘッダーの現在のOAMビットの必要性を明確にする必要があります。
* The WG should work on security options for Geneve.
* WGは、Geneveのセキュリティオプションに取り組む必要があります。
This document does not introduce any additional security constraints; however, Section 6.2.2 discusses security/integrity extensions and this document suggests, in Section 7, that the NVO3 WG work on security options for Geneve.
このドキュメントでは、追加のセキュリティ制約は導入されていません。ただし、セクション6.2.2では、セキュリティ/整合性の拡張機能について説明しており、このドキュメントはセクション7で、NVO3 WGがGeneveのセキュリティオプションに取り組んでいることを示唆しています。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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>.
[GUE] Herbert, T., Yong, L., and O. Zia, "Generic UDP
Encapsulation", Work in Progress, Internet-Draft, draft-
ietf-intarea-gue-09, 26 October 2019,
<https://datatracker.ietf.org/doc/html/draft-ietf-intarea-
gue-09>.
[GUE-ENCAPSULATION]
Yong, L., Herbert, T., and O. Zia, "Generic UDP
Encapsulation (GUE) for Network Virtualization Overlay",
Work in Progress, Internet-Draft, draft-hy-nvo3-gue-4-nvo-
04, 28 October 2016,
<https://datatracker.ietf.org/doc/html/draft-hy-nvo3-gue-
4-nvo-04>.
[GUE-EXTENSIONS]
Herbert, T., Yong, L., and F. Templin, "Extensions for
Generic UDP Encapsulation", Work in Progress, Internet-
Draft, draft-ietf-intarea-gue-extensions-06, 8 March 2019,
<https://datatracker.ietf.org/doc/html/draft-ietf-intarea-
gue-extensions-06>.
[IEEE802.1Q]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks--Bridges and Bridged Networks", IEEE Std 802.1Q-
2022, DOI 10.1109/IEEESTD.2022.10004498, December 2022,
<https://doi.org/10.1109/IEEESTD.2022.10004498>.
[INT] P4.org Applications Working Group, "In-band Network
Telemetry (INT) Dataplane Specification", November 2020,
<https://p4.org/p4-spec/docs/INT_v2_1.pdf>.
[OVN] Linux Foundation, "Open vSwitch",
<https://www.openvswitch.org/>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418,
September 1998, <https://www.rfc-editor.org/info/rfc2418>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005,
<https://www.rfc-editor.org/info/rfc3985>.
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
DOI 10.17487/RFC6071, February 2011,
<https://www.rfc-editor.org/info/rfc6071>.
[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>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015,
<https://www.rfc-editor.org/info/rfc7637>.
[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>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.
[RFC8394] Li, Y., Eastlake 3rd, D., Kreeger, L., Narten, T., and D.
Black, "Split Network Virtualization Edge (Split-NVE)
Control-Plane Requirements", RFC 8394,
DOI 10.17487/RFC8394, May 2018,
<https://www.rfc-editor.org/info/rfc8394>.
[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>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
[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>.
[RFC9542] Eastlake 3rd, D., Abley, J., and Y. Li, "IANA
Considerations and IETF Protocol and Documentation Usage
for IEEE 802 Parameters", BCP 141, RFC 9542,
DOI 10.17487/RFC9542, April 2024,
<https://www.rfc-editor.org/info/rfc9542>.
[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-13,
4 November 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-nvo3-vxlan-gpe-13>.
[VXLAN-GROUP]
Smith, M. and L. Kreeger, "VXLAN Group Policy Option",
Work in Progress, Internet-Draft, draft-smith-vxlan-group-
policy-05, 22 October 2018,
<https://datatracker.ietf.org/doc/html/draft-smith-vxlan-
group-policy-05>.
This section presents a comparison of the three NVO3 encapsulation proposals: Geneve [RFC8926], GUE [GUE], and VXLAN-GPE [VXLAN-GPE]. The three encapsulations use an outer UDP/IP transport. Geneve and VXLAN-GPE use an 8-octet header, while GUE uses a 4-octet header. In addition to the base header, optional extensions may be included in the encapsulation, as discussed in Appendix A.2 below.
このセクションでは、3つのNVO3カプセル化提案の比較：Geneve [RFC8926]、Gue [Gue]、およびVXLAN-GPE [VXLAN-GPE]。3つのカプセルは、外側のUDP/IPトランスポートを使用しています。GeneveとVXLAN-GPEは8オクテットのヘッダーを使用し、Gueは4-OCTETヘッダーを使用します。ベースヘッダーに加えて、以下の付録A.2で説明するように、オプションの拡張機能をカプセル化に含めることができます。
The Geneve and GUE encapsulations both enable optional headers to be incorporated at the end of the base encapsulation header.
GeneveとGueのカプセル化により、ベースカプセル化ヘッダーの端にオプションのヘッダーを組み込むことができます。
VXLAN-GPE does not provide innate support for header extensions. However, as discussed in [VXLAN-GPE], extensibility can be attained to some extent if the Network Service Header (NSH) [RFC8300] is used immediately following the VXLAN-GPE header. The NSH supports either a fixed-size extension (MD Type 1) or a variable-size TLV-based extension (MD Type 2). Note that NSH-over-VXLAN-GPE implies an additional overhead of the 8-octet NSH, in addition to the VXLAN-GPE header.
VXLAN-GPEは、ヘッダー拡張機能に生来のサポートを提供しません。ただし、[VXLAN-GPE]で説明したように、VXLAN-GPEヘッダーの直後にネットワークサービスヘッダー（NSH）[RFC8300]が使用される場合、ある程度拡張性を達成できます。NSHは、固定サイズ拡張（MDタイプ1）または可変サイズのTLVベースの拡張（MDタイプ2）のいずれかをサポートします。NSH-Over-Vxlan-GPEは、VXLAN-GPEヘッダーに加えて、8-OCTET NSHの追加のオーバーヘッドを意味することに注意してください。
The Geneve variable-length options are defined as Type-Length-Value (TLV) extensions. Similarly, VXLAN-GPE, when using an NSH, can include NSH TLV-based extensions. In contrast, GUE defines a small set of possible extension fields (proposed in [GUE-EXTENSIONS] and [GUE-ENCAPSULATION]), and a set of flags in the GUE header that indicate for each extension type whether it is present or not.
Geneve可変長オプションは、型長値（TLV）拡張機能として定義されます。同様に、VXLAN-GPEは、NSHを使用する場合、NSH TLVベースの拡張機能を含めることができます。対照的に、Gueは、可能な拡張フィールドの小さなセット（[Gue-Extensions]および[Gue-Encapsulation]で提案）と、各拡張タイプに存在するかどうかを示すGueヘッダーのフラグのセットを定義します。
TLV-based extensions, as defined in Geneve, provide the flexibility for a large number of possible extension types. Similar behavior can be supported in NSH-over-VXLAN-GPE when using MD Type 2. The flag-based approach taken in GUE strives to simplify implementations by defining a small number of possible extensions used in a fixed order.
Geneveで定義されているTLVベースの拡張機能は、多数の可能な拡張タイプの柔軟性を提供します。MD Type 2を使用する場合、NSH-Over-Vxlan-GPEで同様の動作をサポートできます。Gueで撮影されたフラグベースのアプローチは、固定順序で使用される少数の可能な拡張機能を定義することにより、実装を簡素化するよう努めています。
The Geneve and GUE headers both include a Length field that defines the total length of the encapsulation, including the optional extensions. This Length field simplifies the parsing by transit devices that skip the encapsulation header without parsing its extensions.
GeneveとGueのヘッダーには、オプションの拡張機能を含むカプセル化の全長を定義する長さフィールドが含まれています。この長さのフィールドは、拡張機能を解析せずにカプセル化ヘッダーをスキップするトランジットデバイスによる解析を簡素化します。
The Geneve encapsulation header includes the C field, which indicates whether the current Geneve header includes critical options, that is to say, options which must be parsed by the target NVE. If the endpoint is not able to process a critical option, the packet is discarded.
Geneveカプセル化ヘッダーには、Cフィールドが含まれています。これには、現在のGeneveヘッダーに重要なオプションが含まれているかどうか、つまりターゲットNVEによって解析する必要があるオプションが含まれています。エンドポイントが重要なオプションを処理できない場合、パケットは破棄されます。
The maximal header length in Geneve, including options, is 260 octets. GUE defines the maximal header to be 128 octets. VXLAN-GPE uses a fixed-length header of 8 octets, unless NSH-over-VXLAN-GPE is used, yielding an encapsulation header of up to 264 octets.
オプションを含むGeneveの最大ヘッダー長は260オクテットです。Gueは、最大ヘッダーを128オクテットと定義します。VXLAN-GPEは、NSH-Over-Vxlan-GPEを使用しない限り、8オクテットの固定長ヘッダーを使用し、最大264オクテットのカプセル化ヘッダーを生成します。
The Geneve and VXLAN-GPE headers both include a 24-bit VNI field. GUE, on the other hand, enables the use of a 32-bit field called VNID; this field is not included in the GUE header but was defined as an optional extension in [GUE-ENCAPSULATION].
GeneveおよびVXLAN-GPEヘッダーには、24ビットVNIフィールドが含まれます。一方、Gueは、VNIDと呼ばれる32ビットフィールドを使用できます。このフィールドは、Gueヘッダーには含まれていませんが、[Gue-Capsulation]のオプションの拡張機能として定義されています。
The VXLAN-GPE header includes the I bit, indicating that the VNI field is valid in the current header. A similar indicator is defined as a flag in the GUE header [GUE-EXTENSIONS].
VXLAN-GPEヘッダーにはI BITが含まれており、VNIフィールドが現在のヘッダーで有効であることを示しています。同様のインジケーターは、Gueヘッダー[Gue-Extensions]のフラグとして定義されます。
All three encapsulation headers include a field that specifies the type of the next protocol header, which resides after the NVO3 encapsulation header. The Geneve header includes a 16-bit field that uses the IEEE Ethertype convention. GUE uses an 8-bit field, which uses the IANA protocol numbering. The VXLAN-GPE header incorporates an 8-bit Next Protocol field, using a registry specific to VXLAN-GPE, defined in [VXLAN-GPE].
3つのカプセル化ヘッダーには、NVO3カプセル化ヘッダーの後にある次のプロトコルヘッダーのタイプを指定するフィールドが含まれています。Geneveヘッダーには、IEEE EtherTypeコンベンションを使用する16ビットフィールドが含まれています。Gueは、IANAプロトコル番号を使用する8ビットフィールドを使用します。VXLAN-GPEヘッダーには、[VXLAN-GPE]で定義されたVXLAN-GPEに固有のレジストリを使用して、8ビットの次のプロトコルフィールドを組み込みます。
The VXLAN-GPE header also includes the P bit, which explicitly indicates whether the Next Protocol field is present in the current header.
VXLAN-GPEヘッダーにはP BITも含まれており、次のプロトコルフィールドが現在のヘッダーに存在するかどうかを明示的に示します。
The OAM bit, which is defined in Geneve and in VXLAN-GPE, indicates whether the current packet is an OAM packet. The GUE header includes a similar field but uses different terminology; the GUE C bit (Control bit) specifies whether the current packet is a control packet. Note that the GUE C bit can potentially be used in a large set of protocols that are not OAM protocols. However, the control packet examples discussed in [GUE] are related to OAM.
GeneveおよびVXLAN-GPEで定義されているOAMビットは、現在のパケットがOAMパケットであるかどうかを示します。Gueヘッダーには同様のフィールドが含まれていますが、異なる用語を使用します。Gue Cビット（コントロールビット）は、現在のパケットがコントロールパケットであるかどうかを指定します。Gue Cビットは、OAMプロトコルではない大規模なプロトコルで使用できる可能性があることに注意してください。ただし、[gue]で説明されているコントロールパケットの例は、OAMに関連しています。
Each of the three NVO3 encapsulation headers includes a 2-bit Version field, which is currently defined to be zero.
3つのNVO3カプセル化ヘッダーのそれぞれには、現在ゼロと定義されている2ビットバージョンフィールドが含まれています。
The Geneve and VXLAN-GPE headers include reserved fields; 14 bits in the Geneve header and 27 bits in the VXLAN-GPE header are reserved.
GeneveおよびVXLAN-GPEヘッダーには、予約済みフィールドが含まれています。Geneveヘッダーの14ビット、VXLAN-GPEヘッダーの27ビットが予約されています。
The following table summarizes the comparison between the three NVO3 encapsulations. In some cases, a plus sign ("+") or minus sign ("-") is used to indicate that the header is stronger or weaker in an area, respectively.
次の表は、3つのNVO3カプセルの比較をまとめたものです。場合によっては、プラス記号（ "+"）またはマイナスサイン（ " - "）を使用して、ヘッダーがそれぞれエリアでそれぞれ強いまたは弱いことを示します。
+===============+=================+=============+===================+
| | Geneve | GUE | VXLAN-GPE |
+===============+=================+=============+===================+
| Outer | UDP/IP 6081 | UDP/IP 6080 | UDP/IP 4790 |
| transport UDP | | | |
| Port Number | | | |
+---------------+-----------------+-------------+-------------------+
| Base header | 8 octets | 4 octets | 8 octets (16 |
| length | | | octets using |
| | | | an NSH) |
+---------------+-----------------+-------------+-------------------+
| Extensibility | Variable-length | Extension | No innate |
| | options | fields | extensibility. |
| | | | Might use an |
| | | | NSH. |
+---------------+-----------------+-------------+-------------------+
| Extension | TLV-based | Flag-based | TLV-based |
| parsing | | | (using an NSH |
| method | | | with MD Type |
| | | | 2) |
+---------------+-----------------+-------------+-------------------+
| Extension | Variable | Fixed | Variable |
| order | | | (using an NSH) |
+---------------+-----------------+-------------+-------------------+
| Length field | + | + | - |
+---------------+-----------------+-------------+-------------------+
| Max header | 260 octets | 128 octets | 8 octets (264 |
| length | | | using an NSH) |
+---------------+-----------------+-------------+-------------------+
| Critical | + | - | - |
| extension bit | | | |
+---------------+-----------------+-------------+-------------------+
| VNI field | 24 bits | 32 bits | 24 bits |
| size | | (extension) | |
+---------------+-----------------+-------------+-------------------+
| Next Protocol | 16 bits | 8 bits | 8 bits New |
| field | Ethertype | Internet | registry |
| | registry | protocol | |
| | | registry | |
+---------------+-----------------+-------------+-------------------+
| Next protocol | - | - | + |
| indicator | | | |
+---------------+-----------------+-------------+-------------------+
| OAM / Control | OAM bit | Control bit | OAM bit |
| field | | | |
+---------------+-----------------+-------------+-------------------+
| Version field | 2 bits | 2 bits | 2 bits |
+---------------+-----------------+-------------+-------------------+
| Reserved bits | 14 bits | none | 27 bits |
+---------------+-----------------+-------------+-------------------+
Table 1: Encapsulations Comparison
表1：カプセルの比較
The authors would like to thank Tom Herbert for providing the motivation for the security/integrity extension and for his valuable comments; T. Sridhar for his valuable comments and feedback; Anoop Ghanwani for his extensive comments; and Ignas Bagdonas.
著者は、セキュリティ/整合性の拡張の動機を提供してくれたトムハーバートと彼の貴重なコメントに感謝したいと思います。T. Sridharの貴重なコメントとフィードバックについて。彼の広範なコメントについてアヌープ・ガンワニ。イグナス・バグドナス。
The following coauthors have contributed to this document:
次の共著者がこの文書に貢献しています。
Ilango Ganga
Intel
Email: ilango.s.ganga@intel.com
Pankaj Garg
Microsoft
Email: pankajg@microsoft.com
Rajeev Manur
Broadcom
Email: rajeev.manur@broadcom.com
Tal Mizrahi
Huawei
Email: tal.mizrahi.phd@gmail.com
David Mozes
Email: mosesster@gmail.com
Erik Nordmark
ZEDEDA
Email: nordmark@sonic.net
Michael Smith
Cisco
Email: michsmit@cisco.com
Sam Aldrin
Google
Email: aldrin.ietf@gmail.com
Sami Boutros (editor)
Ciena Corporation
United States of America
Email: sboutros@ciena.com
Donald E. Eastlake 3rd (editor)
Independent
2386 Panoramic Circle
Apopka, FL 32703
United States of America
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com