[要約] RFC 8394は、Split-NVE制御プレーンの要件に関するものであり、ネットワーク仮想化エッジの分割に関する情報を提供します。このRFCの目的は、Split-NVE制御プレーンの設計と実装に必要な要件を定義することです。
Internet Engineering Task Force (IETF) Y. Li
Request for Comments: 8394 D. Eastlake 3rd
Category: Informational Huawei Technologies
ISSN: 2070-1721 L. Kreeger
Arrcus, Inc.
T. Narten
IBM
D. Black
Dell EMC
May 2018
Split Network Virtualization Edge (Split-NVE) Control-Plane Requirements
分割ネットワーク仮想化エッジ（Split-NVE）コントロールプレーンの要件
Abstract
概要
In the Split Network Virtualization Edge (Split-NVE) architecture, the functions of the NVE are split across a server and a piece of external network equipment that is called an "External NVE". The server-resident control-plane functionality resides in control software, which may be part of hypervisor or container-management software; for simplicity, this document refers to the hypervisor as the "location" of this software.
スプリットネットワークバーチャライゼーションエッジ（Split-NVE）アーキテクチャでは、NVEの機能はサーバーと、「外部NVE」と呼ばれる外部ネットワーク機器に分割されます。サーバー常駐のコントロールプレーン機能は、ハイパーバイザーまたはコンテナー管理ソフトウェアの一部である可能性があるコントロールソフトウェアに常駐します。簡単にするために、このドキュメントでは、ハイパーバイザをこのソフトウェアの「場所」と呼びます。
One or more control-plane protocols between a hypervisor and its associated External NVE(s) are used by the hypervisor to distribute its virtual-machine networking state to the External NVE(s) for further handling. This document illustrates the functionality required by this type of control-plane signaling protocol and outlines the high-level requirements. Virtual-machine states as well as state transitioning are summarized to help clarify the protocol requirements.
ハイパーバイザーとそれに関連付けられている外部NVE間の1つ以上のコントロールプレーンプロトコルは、ハイパーバイザーによって使用され、仮想マシンのネットワーク状態を外部NVEに分散してさらに処理します。このドキュメントでは、このタイプのコントロールプレーンシグナリングプロトコルに必要な機能を説明し、高レベルの要件の概要を説明します。仮想マシンの状態と状態遷移は、プロトコル要件を明確にするために要約されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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/rfc8394.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8394で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Target Scenarios ...........................................6
2. VM Lifecycle ....................................................7
2.1. VM Creation Event ..........................................8
2.2. VM Live Migration Event ....................................8
2.3. VM Termination Event .......................................9
2.4. VM Pause, Suspension, and Resumption Events ...............10
3. Hypervisor-to-NVE Control-Plane Protocol Functionality .........10
3.1. VN_Connect and VN_Disconnect ..............................10
3.2. TSI Associate and Activate ................................12
3.3. TSI De-Associate and Deactivate ...........................15
4. Hypervisor-to-NVE Control-Plane Protocol Requirements ..........16
5. VDP Applicability and Enhancement Needs ........................17
6. Security Considerations ........................................19
7. IANA Considerations ............................................20
8. References .....................................................21
8.1. Normative References ......................................21
8.2. Informative References ....................................22
Appendix A. VDP Illustrations (per IEEE 802.1Q) (for Information
Only) .................................................23
Acknowledgements ..................................................25
Authors' Addresses ................................................26
In the Split Network Virtualization Edge (Split-NVE) architecture shown in Figure 1, the functionality of the NVE is split across an end device supporting virtualization and an external network device that is called an "External NVE". The portion of the NVE functionality located on the end device is called the "tNVE" (terminal-side NVE), and the portion located on the External NVE is called the "nNVE" (network-side NVE) in this document. Overlay encapsulation/decapsulation functions are normally offloaded to the nNVE on the External NVE.
図1に示すSplit Network Virtualization Edge（Split-NVE）アーキテクチャでは、NVEの機能は、仮想化をサポートするエンドデバイスと、「外部NVE」と呼ばれる外部ネットワークデバイスに分割されます。このドキュメントでは、エンドデバイスにあるNVE機能の部分を「tNVE」（端末側NVE）と呼び、外部NVEにある部分を「nNVE」（ネットワーク側NVE）と呼びます。オーバーレイのカプセル化/カプセル化解除機能は、通常、外部NVE上のnNVEにオフロードされます。
+------------ Split-NVE ---------+
| |
| |
+-----------------|-----+ |
| +---------------|----+| |
| | +--+ \|/ || |
| | |V |TSI +-------+ || +------|-------------+
| | |M |-----+ | || | \|/ |
| | +--+ | | || |+--------+ |
| | +--+ | tNVE | ||-------------------|| | |
| | |V |TSI | | || || nNVE | |
| | |M |-----| | || || | |
| | +--+ +-------+ || |+--------+ |
| | || +--------------------+
| +-----Hypervisor-----+|
+-----------------------+
End Device External NVE
Figure 1: Split-NVE Structure
図1：Split-NVE構造
The tNVE is normally implemented as a part of a hypervisor or container and/or a virtual switch in a virtualized end device. This document uses the term "hypervisor" throughout when describing the Split-NVE scenario where part of the NVE functionality is offloaded to a separate device from the "hypervisor" that contains a VM (Virtual Machine) connected to a VN (Virtual Network). In this context, the term "hypervisor" is meant to cover any device type where part of the NVE functionality is offloaded in this fashion, e.g., a Network Service Appliance or Linux Container.
tNVEは通常、仮想化されたエンドデバイスのハイパーバイザーまたはコンテナー、あるいは仮想スイッチの一部として実装されます。このドキュメントでは、NVE機能の一部が、VN（仮想ネットワーク）に接続されたVM（仮想マシン）を含む「ハイパーバイザー」から別のデバイスにオフロードされる分割NVEシナリオを説明する際に、「ハイパーバイザー」という用語を使用します。このコンテキストでは、「ハイパーバイザー」という用語は、NVE機能の一部がこの方法でオフロードされるデバイスタイプ（ネットワークサービスアプライアンスやLinuxコンテナーなど）をカバーすることを意味します。
The Network Virtualization over Layer 3 (NVO3) problem statement [RFC7364] discusses the need for a control-plane protocol (or protocols) to populate each NVE with the state needed to perform the required functions. In one scenario, an NVE provides overlay encapsulation/decapsulation packet-forwarding services to Tenant Systems that are co-resident within the NVE on the same end device (e.g., when the NVE is embedded within a hypervisor or a Network Service Appliance). In such cases, there is no need for a standardized protocol between the hypervisor and the NVE, as the interaction is implemented via software on a single device. However, in the Split-NVE architecture scenarios shown in Figures 2 through 4 (see Section 1.2), one or more control-plane protocols between a hypervisor and its associated External NVE(s) are required for the hypervisor to distribute the VM's networking states to the NVE(s) for further handling. The protocol is an NVE-internal protocol and runs between tNVE and nNVE logical entities. This protocol is mentioned in the "third work area" text in Section 4.5 of the NVO3 problem statement [RFC7364].
Network Virtualization over Layer 3（NVO3）の問題ステートメント[RFC7364]では、必要な機能を実行するために必要な状態を各NVEに入力するためのコントロールプレーンプロトコル（1つまたは複数）の必要性について説明しています。 1つのシナリオでは、NVEは同じエンドデバイス上のNVE内に共存するテナントシステムにオーバーレイカプセル化/カプセル化解除パケット転送サービスを提供します（たとえば、NVEがハイパーバイザーまたはネットワークサービスアプライアンスに組み込まれている場合）。このような場合、相互作用は単一のデバイス上のソフトウェアを介して実装されるため、ハイパーバイザーとNVE間の標準化されたプロトコルは必要ありません。ただし、図2から4（セクション1.2を参照）に示すSplit-NVEアーキテクチャのシナリオでは、ハイパーバイザーとVMのネットワーク状態を分散するためにハイパーバイザーに関連付けられた外部NVE間の1つ以上のコントロールプレーンプロトコルが必要です。さらに処理するためにNVEに送信します。プロトコルはNVE内部プロトコルであり、tNVEとnNVEの論理エンティティ間で実行されます。このプロトコルは、NVO3問題ステートメント[RFC7364]のセクション4.5の「3番目の作業領域」のテキストで言及されています。
VM states and state transitioning are summarized in this document, showing events where the NVE needs to take specific actions. Such events might correspond to actions that the control-plane signaling protocol or protocols need to take between the tNVE and the nNVE in the Split-NVE scenario. The high-level requirements to be fulfilled are listed in Section 4.
このドキュメントでは、VMの状態と状態の遷移について要約し、NVEが特定のアクションを実行する必要があるイベントを示しています。このようなイベントは、コントロールプレーンシグナリングプロトコルが、Split-NVEシナリオのtNVEとnNVEの間で実行する必要があるアクションに対応している場合があります。満たすべき高レベルの要件は、セクション4にリストされています。
To describe the requirements, this document uses VMs as an example of Tenant Systems, even though a VM is just one type of Tenant System that may connect to a VN. For example, a service instance within a Network Service Appliance is another type of Tenant System, as are systems running on OS-level virtualization technologies like containers. The fact that VMs have lifecycles (e.g., can be created and destroyed, can be moved, and can be started or stopped) results in a general set of protocol requirements, most of which are applicable to other forms of Tenant Systems, although not all of the requirements are applicable to all forms of Tenant Systems.
要件を説明するために、このドキュメントではVMをテナントシステムの例として使用していますが、VMはVNに接続できるテナントシステムの一種にすぎません。たとえば、ネットワークサービスアプライアンス内のサービスインスタンスは、コンテナーなどのOSレベルの仮想化テクノロジーで実行されるシステムと同様に、別のタイプのテナントシステムです。 VMにライフサイクルがある（たとえば、作成および破棄、移動、開始または停止が可能）という事実により、プロトコル要件の一般的なセットが発生します。そのほとんどは、すべてではありませんが、他の形式のテナントシステムに適用できます。要件のすべてがすべての形式のテナントシステムに適用されます。
Section 2 describes VM states and state transitioning in the VM's lifecycle. Section 3 introduces hypervisor-to-NVE control-plane protocol functionality derived from VM operations and network events. Section 4 outlines the requirements of the control-plane protocol to achieve the required functionality.
セクション2では、VMの状態とVMのライフサイクルでの状態遷移について説明します。セクション3では、VMの操作とネットワークイベントから派生したハイパーバイザーとNVEのコントロールプレーンプロトコル機能を紹介します。セクション4では、必要な機能を実現するためのコントロールプレーンプロトコルの要件について説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document uses the same terminology as the terminology found in [RFC7365]. This section defines additional terminology used by this document.
このドキュメントでは、[RFC7365]で使用されている用語と同じ用語を使用しています。このセクションでは、このドキュメントで使用される追加の用語を定義します。
Split-NVE: A type of NVE (Network Virtualization Edge) where the functionalities are split across an end device supporting virtualization and an external network device.
Split-NVE：NVE（ネットワーク仮想化エッジ）の一種で、仮想化をサポートするエンドデバイスと外部ネットワークデバイスに機能が分割されます。
tNVE: Terminal-side NVE. The portion of Split-NVE functionalities located on the end device supporting virtualization. The tNVE interacts with a Tenant System through an internal interface in the end device.
tNVE：端末側NVE。仮想化をサポートするエンドデバイスにあるSplit-NVE機能の一部。 tNVEは、エンドデバイスの内部インターフェイスを介してテナントシステムと対話します。
nNVE: Network-side NVE. The portion of Split-NVE functionalities located on the network device that is directly or indirectly connected to the end device that contains the corresponding tNVE. The nNVE normally performs encapsulation to and decapsulation from the overlay network.
nNVE：ネットワーク側NVE。対応するtNVEを含むエンドデバイスに直接または間接的に接続されているネットワークデバイスにあるSplit-NVE機能の一部。 nNVEは通常、オーバーレイネットワークとの間のカプセル化とカプセル化解除を実行します。
External NVE: The physical network device that contains the nNVE.
外部NVE：nNVEを含む物理ネットワークデバイス。
Hypervisor: The logical collection of software, firmware, and/or hardware that allows the creation and running of server or service appliance virtualization. The tNVE is located under a hypervisor. The term "hypervisor" is loosely used in this document to refer to the end device supporting the virtualization. For simplicity, we also use the term "hypervisor" to represent both the hypervisor and the container.
ハイパーバイザー：サーバーまたはサービスアプライアンスの仮想化の作成と実行を可能にするソフトウェア、ファームウェア、ハードウェアの論理的な集まり。 tNVEはハイパーバイザーの下にあります。このドキュメントでは、「ハイパーバイザ」という用語を大まかに使用して、仮想化をサポートするエンドデバイスを指します。簡単にするために、「ハイパーバイザ」という用語を使用して、ハイパーバイザとコンテナの両方を表します。
Container: Please see "Hypervisor:" above.
コンテナ：上記の「ハイパーバイザー：」を参照してください。
VN Profile: Metadata that is associated with a VN and applied to any attachment point to the VN (i.e., VAP (Virtual Access Point) properties that are applied to all VAPs associated with a given VN and used by an NVE when ingressing/egressing packets to/from a specific VN). Metadata could include such information as Access Control Lists (ACLs) and QoS settings. The VN Profile contains parameters that apply to the VN as a whole. Control protocols between the NVE and the NVA (Network Virtualization Authority) could use the VN ID or VN Name to obtain the VN Profile.
VNプロファイル：VNに関連付けられ、VNへの任意のアタッチメントポイントに適用されるメタデータ（つまり、特定のVNに関連付けられたすべてのVAPに適用され、パケットの入出力時にNVEによって使用されるVAP（仮想アクセスポイント）プロパティ特定のVNへ/から）。メタデータには、アクセス制御リスト（ACL）やQoS設定などの情報を含めることができます。 VNプロファイルには、VN全体に適用されるパラメータが含まれています。 NVEとNVA（Network Virtualization Authority）間の制御プロトコルは、VN IDまたはVN名を使用して、VNプロファイルを取得できます。
VSI: Virtual Station Interface. See [IEEE802.1Q].
VSI：Virtual Station Interface。 [IEEE802.1Q]を参照してください。
VDP: VSI Discovery and Configuration Protocol. See [IEEE802.1Q].
VDP：VSI Discovery and Configuration Protocol。 [IEEE802.1Q]を参照してください。
In the Split-NVE architecture, an External NVE can provide offloading of the encapsulation/decapsulation functions and network policy enforcement as well as offloading of overhead from the VN overlay protocol. This offloading may improve performance and/or save resources in the end device (e.g., hypervisor) using the External NVE.
スプリットNVEアーキテクチャでは、外部NVEはカプセル化/カプセル化解除機能とネットワークポリシー実施のオフロード、およびVNオーバーレイプロトコルからのオーバーヘッドのオフロードを提供できます。このオフロードにより、パフォーマンスが向上し、外部NVEを使用してエンドデバイス（ハイパーバイザーなど）のリソースを節約できます。
Figures 2 through 4 give example scenarios for the Split-NVE architecture.
図2〜4は、Split-NVEアーキテクチャのシナリオ例を示しています。
Hypervisor Access Switch
+------------------+ +-----+-------+
| +--+ +-------+ | | | |
| |VM|---| | | VLAN | | |
| +--+ | tNVE |---------+ nNVE| +--- Underlying
| +--+ | | | Trunk | | | Network
| |VM|---| | | | | |
| +--+ +-------+ | | | |
+------------------+ +-----+-------+
Figure 2: Hypervisor with an External NVE
図2：外部NVEを備えたハイパーバイザー
Hypervisor L2 Switch
+---------------+ +-----+ +----+---+
| +--+ +----+ | | | | | |
| |VM|---| | |VLAN | |VLAN | | |
| +--+ |tNVE|-------+ +-----+nNVE| +--- Underlying
| +--+ | | |Trunk| |Trunk| | | Network
| |VM|---| | | | | | | |
| +--+ +----+ | | | | | |
+---------------+ +-----+ +----+---+
Figure 3: Hypervisor with an External NVE Connected through an Ethernet Access Switch
図3：イーサネットアクセススイッチを介して接続された外部NVEを備えたハイパーバイザー
Network Service Appliance Access Switch
+-----------------------------+ +-----+-------+
| +---------------+ | \ | | | |
| |Network Service|----| \ | | | |
| |Instance | | \ | VLAN | | |
| +---------------+ |tNVE| |------+nNVE | +--- Underlying
| +---------------+ | | | Trunk| | | Network
| |Network Service|----| / | | | |
| |Instance | | / | | | |
| +---------------+ | / | | | |
+-----------------------------+ +-----+-------+
Figure 4: Physical Network Service Appliance with an External NVE
図4：外部NVEを備えた物理ネットワークサービスアプライアンス
Tenant Systems connect to External NVEs via a Tenant System Interface (TSI). The TSI logically connects to the External NVE via a VAP [RFC8014]. The External NVE may provide Layer 2 or Layer 3 forwarding. In the Split-NVE architecture, the External NVE may be able to reach multiple Media Access Control (MAC) addresses and IP addresses via a TSI. An IP address can be in either IPv4 or IPv6 format. For example, Tenant Systems that are providing network services (such as a transparent firewall, load balancer, or VPN gateway) are likely to have a complex address hierarchy. This implies that if a given TSI de-associates from one VN, all the MAC and/or IP addresses are also de-associated. There is no need to signal the deletion of every MAC or IP address when the TSI is brought down or deleted. In the majority of cases, a VM will be acting as a simple host that will have a single TSI as well as a single MAC and IP address visible to the External NVE.
テナントシステムは、テナントシステムインターフェイス（TSI）を介して外部NVEに接続します。 TSIは、VAP [RFC8014]を介して外部NVEに論理的に接続します。外部NVEは、レイヤー2またはレイヤー3の転送を提供します。 Split-NVEアーキテクチャでは、外部NVEがTSIを介して複数のメディアアクセス制御（MAC）アドレスおよびIPアドレスに到達できる場合があります。 IPアドレスは、IPv4またはIPv6形式のいずれかです。たとえば、ネットワークサービス（透過ファイアウォール、ロードバランサー、VPNゲートウェイなど）を提供しているテナントシステムは、複雑なアドレス階層を持つ可能性があります。これは、特定のTSIが1つのVNから関連付けを解除すると、すべてのMACアドレスまたはIPアドレス、あるいはその両方も関連付けが解除されることを意味します。 TSIがダウンまたは削除されたときに、すべてのMACまたはIPアドレスの削除を通知する必要はありません。ほとんどの場合、VMは単一のTSIと、外部NVEから見える単一のMACおよびIPアドレスを持つ単純なホストとして機能します。
Figures 2 through 4 show the use of VLANs to separate traffic for multiple VNs between the tNVE and the nNVE; VLANs are not strictly necessary if only one VN is involved, but multiple VNs are expected in most cases. Hence, this document assumes the presence of VLANs.
図2〜4は、tNVEとnNVEの間の複数のVNのトラフィックを分離するためのVLANの使用を示しています。 VNが1つだけの場合、VLANは厳密には必要ありませんが、ほとんどの場合、複数のVNが想定されます。したがって、このドキュメントではVLANの存在を想定しています。
Figure 2 of [RFC7666] shows the states and transitions of a VM. Some of the VM states are of interest to the External NVE. This section illustrates the relevant phases and events in the VM lifecycle. Note that the following subsections do not give exhaustive descriptions of VM lifecycle states. Rather, they are intended as illustrative examples that are relevant to the Split-NVE architecture and not as prescriptive text; the goal is to capture sufficient detail to set a context for the signaling-protocol functionality and requirements described in the following sections.
[RFC7666]の図2は、VMの状態と遷移を示しています。 VMの状態の一部は、外部NVEに関係しています。このセクションでは、VMライフサイクルの関連するフェーズとイベントについて説明します。以下のサブセクションでは、VMライフサイクルの状態を完全に説明しているわけではありません。むしろ、それらは分割NVEアーキテクチャに関連する説明的な例として意図されており、規範的なテキストとして意図されていません。目標は、次のセクションで説明するシグナリングプロトコル機能と要件のコンテキストを設定するために十分な詳細をキャプチャすることです。
The VM creation event causes the VM state to transition from the "preparing" state to the "shutdown" state and then to the "running" state [RFC7666]. The end device allocates and initializes local virtual resources like storage in the VM's preparing state. In the shutdown state, the VM has everything ready, except that CPU execution is not scheduled by the hypervisor and the VM's memory is not resident in the hypervisor. The transition from the shutdown state to the running state normally requires human action or a system-triggered event. The running state indicates that the VM is in the normal execution state. As part of transitioning the VM to the running state, the hypervisor must also provision network connectivity for the VM's TSI(s) so that Ethernet frames can be sent and received correctly. Initially, when in the running state, no ongoing migration, suspension, or shutdown is in process.
VM作成イベントにより、VMの状態が「準備中」状態から「シャットダウン」状態に移行し、次に「実行中」状態に移行します[RFC7666]。エンドデバイスは、VMの準備状態のストレージなどのローカル仮想リソースを割り当てて初期化します。シャットダウン状態では、ハイパーバイザーによってCPUの実行がスケジュールされておらず、VMのメモリがハイパーバイザーに常駐していないことを除いて、VMはすべて準備が整っています。シャットダウン状態から実行状態への移行には、通常、人間のアクションまたはシステムによってトリガーされるイベントが必要です。実行状態は、VMが通常の実行状態であることを示します。ハイパーバイザーは、VMを実行状態に移行する一環として、イーサネットフレームを正しく送受信できるように、VMのTSIのネットワーク接続もプロビジョニングする必要があります。最初は、実行状態のとき、進行中の移行、一時停止、またはシャットダウンは実行されていません。
In the VM creation phase, the VM's TSI has to be associated with the External NVE. "Association" here indicates that the hypervisor and the External NVE have signaled each other and reached some form of agreement. Relevant networking parameters or information have been provisioned properly. The External NVE should be informed of the VM's TSI MAC address and/or IP address. In addition to external network connectivity, the hypervisor may provide local network connectivity between the VM's TSI and TSIs for other VMs that are co-resident on the same hypervisor. When the intra- or inter-hypervisor connectivity is extended to the External NVE, a locally significant tag, e.g., VLAN ID, should be used between the hypervisor and the External NVE to differentiate each VN's traffic. Both the hypervisor and External NVE sides must agree on that tag value for traffic identification, isolation, and forwarding.
VM作成フェーズでは、VMのTSIを外部NVEに関連付ける必要があります。ここでの「関連付け」とは、ハイパーバイザーと外部NVEが互いに信号を送って何らかの形で合意に達したことを示します。関連するネットワークパラメータまたは情報が適切にプロビジョニングされている。外部NVEには、VMのTSI MACアドレスまたはIPアドレス、あるいはその両方を通知する必要があります。外部ネットワーク接続に加えて、ハイパーバイザーは、VMのTSIと、同じハイパーバイザー上に共存する他のVMのTSI間のローカルネットワーク接続を提供する場合があります。ハイパーバイザー内またはハイパーバイザー間接続が外部NVEに拡張される場合、各VNのトラフィックを区別するために、ローカルで重要なタグ（VLAN IDなど）をハイパーバイザーと外部NVEの間で使用する必要があります。ハイパーバイザー側と外部NVE側の両方が、トラフィックの識別、分離、および転送のためにそのタグ値について合意する必要があります。
The External NVE may need to do some preparation before it signals successful association with the TSI. Such preparation may include locally saving the states and binding information of the TSI and its VN or communicating with the NVA for network provisioning.
外部NVEは、TSIとの関連付けが成功したことを示す前に、いくつかの準備を行う必要がある場合があります。そのような準備には、TSIとそのVNの状態とバインディング情報をローカルに保存すること、またはネットワークプロビジョニングのためにNVAと通信することが含まれます。
A TSI association should be performed before the VM enters the running state, preferably in the shutdown state. If the association with an External NVE fails, the VM should not go into the running state.
TSIアソシエーションは、VMが実行状態になる前に、できればシャットダウン状態で実行する必要があります。外部NVEとの関連付けが失敗した場合、VMは実行状態にならないはずです。
Live migration is sometimes referred to as "hot" migration in that, from an external viewpoint, the VM appears to continue to run while being migrated to another server (e.g., TCP connections generally survive this class of migration). In contrast, "cold" migration consists of shutting down VM execution on one server and restarting it on another. For simplicity, the following abstract summary of live migration assumes shared storage, so that the VM's storage is accessible to the source and destination servers. Assume that the VM "live migrates" from hypervisor 1 to hypervisor 2. Such a migration event involves state transitions on both source hypervisor 1 and destination hypervisor 2. The VM state on source hypervisor 1 transitions from the running state to the "migrating" state and then to the shutdown state [RFC7666]. The VM state on destination hypervisor 2 transitions from the shutdown state to the migrating state and then to the running state.
ライブマイグレーションは、「ホット」マイグレーションと呼ばれることもあります。外部から見ると、VMは別のサーバーに移行されている間も実行を続けているように見えます（たとえば、TCP接続は通常、このクラスの移行に耐えます）。対照的に、「コールド」移行は、あるサーバーでのVMの実行をシャットダウンし、別のサーバーで再起動することで構成されます。簡単にするために、次のライブマイグレーションの要約では、共有ストレージを想定しているため、VMのストレージにソースサーバーと宛先サーバーからアクセスできます。 VMがハイパーバイザー1からハイパーバイザー2に「ライブマイグレーション」するとします。このような移行イベントには、ソースハイパーバイザー1と宛先ハイパーバイザー2の両方の状態遷移が含まれます。ソースハイパーバイザー1のVM状態は、実行状態から「移行中」状態に遷移しますそしてシャットダウン状態に[RFC7666]。宛先ハイパーバイザー2のVMの状態は、シャットダウン状態から移行中状態に移行してから、実行中状態に移行します。
The External NVE connected to destination hypervisor 2 has to associate the migrating VM's TSI with itself (i.e., the External NVE) by discovering the TSI's MAC and/or IP addresses, discovering its VN, discovering its locally significant VLAN ID (if any), and provisioning other network-related parameters of the TSI. The External NVE may be informed about the VM's peer VMs, storage devices, and other network appliances with which the VM needs to communicate or is communicating. The migrated VM on destination hypervisor 2 should not go to the running state until all the network provisioning and binding have been done.
宛先ハイパーバイザー2に接続された外部NVEは、TSIのMACアドレスまたはIPアドレス、あるいはその両方を検出し、VNを検出し、ローカルで重要なVLAN ID（存在する場合）を検出することにより、移行するVMのTSIをそれ自体（つまり、外部NVE）に関連付ける必要があります。 TSIの他のネットワーク関連パラメーターのプロビジョニング。外部NVEは、VMのピアVM、ストレージデバイス、およびVMが通信する必要のある、または通信している他のネットワークアプライアンスについて通知される場合があります。移行先のハイパーバイザー2に移行されたVMは、すべてのネットワークのプロビジョニングとバインドが完了するまで実行状態にならないはずです。
The VM state on both the source hypervisor and the destination hypervisor will be the migrating state during the transfer of VM execution. The migrating VM should not be in the running state at the same time on the source hypervisor and destination hypervisor during migration. The VM on the source hypervisor does not transition to the shutdown state until the VM successfully enters the running state on the destination hypervisor. It is possible that the VM on the source hypervisor stays in the migrating state for a while after the VM on the destination hypervisor enters the running state.
ソースハイパーバイザーとターゲットハイパーバイザーの両方のVMの状態は、VM実行の転送中は移行中の状態になります。移行中のVMは、移行中にソースハイパーバイザーとターゲットハイパーバイザーで同時に実行状態であってはなりません。ソースハイパーバイザー上のVMは、VMがデスティネーションハイパーバイザーで実行状態になるまで、シャットダウン状態に移行しません。ソースハイパーバイザーのVMが移行中の状態になった後、しばらくの間、移行元のハイパーバイザーのVMが移行状態のままになる可能性があります。
A VM termination event is also referred to as "powering off" a VM. A VM termination event leads to the VM's transition to the shutdown state. Per [RFC7666], there are two possible causes of VM termination:
VM終了イベントは、VMの「電源オフ」とも呼ばれます。 VM終了イベントにより、VMがシャットダウン状態に移行します。 [RFC7666]によると、VMの終了には次の2つの原因が考えられます。
1. A running VM has undergone a normal "power-off".
1. 実行中のVMは通常の「電源オフ」を受けました。
2. The VM has been migrated to another hypervisor, and the VM image on the source hypervisor has to stop executing and be shut down.
2. VMは別のハイパーバイザーに移行されており、ソースハイパーバイザー上のVMイメージは実行を停止してシャットダウンする必要があります。
In VM termination, the External NVE connecting to that VM needs to deprovision the VM, i.e., delete the network parameters associated with that VM. In other words, the External NVE has to de-associate the VM's TSI.
VMの終了では、そのVMに接続している外部NVEがVMをプロビジョニング解除する、つまり、そのVMに関連付けられているネットワークパラメータを削除する必要があります。つまり、外部NVEはVMのTSIの関連付けを解除する必要があります。
A VM pause event leads to the VM transitioning from the running state to the "paused" state. The paused state indicates that the VM is resident in memory but that CPU execution is not scheduled by the hypervisor [RFC7666]. The VM can be easily reactivated from the paused state to the running state.
VM一時停止イベントにより、VMが実行状態から「一時停止」状態に移行します。一時停止状態は、VMがメモリに常駐しているが、CPUの実行がハイパーバイザー[RFC7666]によってスケジュールされていないことを示します。 VMは一時停止状態から実行状態に簡単に再アクティブ化できます。
A VM suspension event leads to the VM transitioning from the running state to the "suspended" state. A VM resumption event leads to the VM transitioning from the suspended state to the running state. In the suspended state, the memory and CPU execution state of the VM are saved to persistent storage. During this state, CPU execution for the VM is not scheduled by the hypervisor [RFC7666].
VMの一時停止イベントにより、VMが実行状態から「一時停止」状態に移行します。 VM再開イベントにより、VMが中断状態から実行状態に移行します。一時停止状態では、VMのメモリとCPUの実行状態が永続ストレージに保存されます。この状態の間、VMのCPU実行はハイパーバイザー[RFC7666]によってスケジュールされません。
In the Split-NVE architecture, the External NVE should not de-associate the paused or suspended VM, as the VM can return to the running state at any time.
VMはいつでも実行中の状態に戻る可能性があるため、Split-NVEアーキテクチャでは、一時停止または一時停止されたVMの関連付けを外部NVEで解除しないでください。
The following subsections show illustrative examples of the state transitions of an External NVE that are relevant to hypervisor-to-NVE signaling-protocol functionality. Note: This is not prescriptive text for the full state machine.
次のサブセクションでは、ハイパーバイザーからNVEへのシグナリングプロトコル機能に関連する外部NVEの状態遷移の例を示します。注：これは完全なステートマシンの説明文ではありません。
In the Split-NVE scenario, a protocol is needed between the end device (e.g., hypervisor) and the External NVE it is using, in order to make the External NVE aware of the changing VN membership requirements of the Tenant Systems within the end device.
Split-NVEシナリオでは、エンドデバイス内のテナントシステムのVNメンバーシップ要件の変化を外部NVEに認識させるために、エンドデバイス（ハイパーバイザーなど）とそれが使用している外部NVEとの間にプロトコルが必要です。 。
A key driver for using a protocol rather than using static configuration of the External NVE is that the VN connectivity requirements can change frequently as VMs are brought up, moved, and brought down on various hypervisors throughout the data center or external cloud.
外部NVEの静的構成を使用するのではなく、プロトコルを使用するための重要なドライバーは、VMがデータセンターまたは外部クラウド全体のさまざまなハイパーバイザーで起動、移動、および停止されるときに、VN接続要件が頻繁に変更される可能性があることです。
Figure 5 shows the state transition for a VAP on the External NVE. An NVE that supports the hypervisor-to-NVE control-plane protocol should support one instance of the state machine for each active VN. The state transition on the External NVE is normally triggered by events and behaviors on the hypervisor-facing side. Some of the interleaved interactions between the NVE and the NVA will be illustrated to better explain the whole procedure, while other interactions will not be shown.
図5は、外部NVE上のVAPの状態遷移を示しています。ハイパーバイザーからNVEへのコントロールプレーンプロトコルをサポートするNVEは、アクティブなVNごとに状態マシンの1つのインスタンスをサポートする必要があります。外部NVEの状態遷移は、通常、ハイパーバイザー側のイベントと動作によってトリガーされます。 NVEとNVAの間の交互配置された相互作用の一部は、手順全体をよりよく説明するために示されますが、他の相互作用は示されません。
+----------------+ Receive VN_Connect; +----------------------+
|VN_Disconnected | return Local_Tag value |VN_Connected |
+----------------+ for VN if successful; +----------------------+
|VN_ID; |-------------------------->|VN_ID; |
|VN_State= | |VN_State=VN_Connected;|
|VN_Disconnected;| |Num_TSI_Associated; |
| |<--Receive VN_Disconnect---|Local_Tag; |
+----------------+ |VN_Context; |
+----------------------+
Figure 5: State Transition Example of a VAP Instance on an External NVE
図5：外部NVE上のVAPインスタンスの状態遷移の例
The External NVE must be notified when an end device requires a connection to a particular VN and when it no longer requires a connection. Connection cleanup for the failed devices should be employed. Note that this topic is out of scope for the protocol specified in this document.
エンドデバイスが特定のVNへの接続を必要とするとき、および接続が不要になったときに、外部NVEに通知する必要があります。故障したデバイスの接続クリーンアップを使用する必要があります。このトピックは、このドキュメントで指定されているプロトコルの範囲外であることに注意してください。
In addition, the External NVE should provide a local tag value for each connected VN to the end device to use for exchanging packets between the end device and the External NVE (e.g., a locally significant tag value per [IEEE802.1Q]). How "local" the significance is depends on whether
さらに、外部NVEは、エンドデバイスと外部NVEの間でパケットを交換するために使用するエンドデバイスに接続された各VNのローカルタグ値を提供する必要があります（[IEEE802.1Q]ごとのローカルで重要なタグ値など）。重要性がどの程度「ローカル」であるかは、
1. the hypervisor has a direct physical connection to the External NVE (in which case the significance is local to the physical link) or
1. ハイパーバイザーが外部NVEに直接物理的に接続している（この場合、重要性は物理リンクに対してローカルです）または
2. there is an Ethernet switch (e.g., a blade switch) connecting the hypervisor to the NVE (in which case the significance is local to the intervening switch and all the links connected to it).
2. ハイパーバイザーをNVEに接続するイーサネットスイッチ（ブレードスイッチなど）があります（この場合、重要なのは、介在するスイッチとそれに接続されているすべてのリンクに対してローカルです）。
These VLAN tags are used to differentiate between different VNs as packets cross the shared-access network to the External NVE. When the External NVE receives packets, it uses the VLAN tag to identify their VN coming from a given TSI, strips the tag, adds the appropriate overlay encapsulation for that VN, and sends it towards the corresponding remote NVE across the underlying IP network.
これらのVLANタグは、パケットが共有アクセスネットワークを通過して外部NVEに到達するときに、異なるVNを区別するために使用されます。外部NVEはパケットを受信すると、VLANタグを使用して特定のTSIからのVNを識別し、タグを取り除き、そのVNに適切なオーバーレイカプセル化を追加して、基盤となるIPネットワークを介して対応するリモートNVEに送信します。
The Identification of the VN in this protocol could be through either a VN Name or a VN ID. A globally unique VN Name facilitates portability of a tenant's virtual data center. Once an External NVE receives a VN_Connect message, the NVE needs a way to get a VN_Context allocated (or to receive the already-allocated VN_Context) for a given VN Name or VN ID (as well as any other information needed to transmit encapsulated packets). How this is done is the subject of the NVE-to-NVA protocol; see the "first two areas of work" text in Section 4.5 of [RFC7364]. The External NVE needs to synchronize the mapping information of the local tag and VN Name or VN ID with the NVA.
このプロトコルでのVNの識別は、VN名またはVN IDのいずれかを通じて行うことができます。グローバルに一意のVN名は、テナントの仮想データセンターの移植性を促進します。外部NVEがVN_Connectメッセージを受信すると、NVEは、所定のVN名またはVN ID（およびカプセル化されたパケットを送信するために必要なその他の情報）に割り当てられたVN_Contextを取得する（またはすでに割り当てられたVN_Contextを受信する）方法を必要とします。これがどのように行われるかは、NVE-to-NVAプロトコルの主題です。 [RFC7364]のセクション4.5の「最初の2つの作業分野」のテキストを参照してください。外部NVEは、ローカルタグとVN名またはVN IDのマッピング情報をNVAと同期する必要があります。
The VN_Connect message can be explicit or implicit. "Explicit" means that the hypervisor sends a request message explicitly for the connection to a VN. "Implicit" means that the External NVE receives other messages, e.g., the very first TSI Associate message (see the next subsection) for a given VN, that implicitly indicate its interest in connecting to a VN.
VN_Connectメッセージは、明示的または暗黙的にすることができます。 「明示的」とは、ハイパーバイザーがVNへの接続に対して明示的に要求メッセージを送信することを意味します。 「暗黙的」とは、外部NVEが他のメッセージ、たとえば、所定のVNの最初のTSI Associateメッセージ（次のサブセクションを参照）を受信することを意味し、VNへの接続への関心を暗黙的に示します。
A VN_Disconnect message indicates that the NVE can release all the resources for that disconnected VN and transition to the VN_Disconnected state. The local tag assigned for that VN can possibly be reclaimed for use by another VN.
VN_Disconnectメッセージは、NVEが切断されたVNのすべてのリソースを解放し、VN_Disconnected状態に移行できることを示します。そのVNに割り当てられたローカルタグは、別のVNで使用するために再利用できます。
Typically, a TSI is assigned a single MAC address, and all frames transmitted and received on that TSI use that single MAC address. As mentioned earlier, it is also possible for a Tenant System to exchange frames using multiple MAC addresses or packets with multiple IP addresses.
通常、TSIには単一のMACアドレスが割り当てられ、そのTSIで送受信されるすべてのフレームはその単一のMACアドレスを使用します。前述のように、テナントシステムは、複数のMACアドレスまたは複数のIPアドレスを持つパケットを使用してフレームを交換することもできます。
Particularly in the case of a Tenant System that is forwarding frames or packets from other Tenant Systems, the External NVE will need to communicate the mapping between the NVE's IP address on the underlying network and ALL the addresses the Tenant System is forwarding on behalf of the corresponding VN to the NVA.
特に、他のテナントシステムからフレームまたはパケットを転送しているテナントシステムの場合、外部NVEは、基盤となるネットワーク上のNVEのIPアドレスと、テナントシステムが転送するすべてのアドレスとの間のマッピングを通信する必要があります。 NVAに対応するVN。
The NVE has two ways it can discover the tenant addresses for which frames are to be forwarded to a given end device (and ultimately to the Tenant System within that end device).
NVEには、フレームが所定のエンドデバイス（最終的にはそのエンドデバイス内のテナントシステム）に転送されるテナントアドレスを検出する方法が2つあります。
1. It can glean the addresses by inspecting the source addresses in packets it receives from the end device.
1. エンドデバイスから受信したパケットの送信元アドレスを検査することで、アドレスを収集できます。
2. The hypervisor can explicitly signal the address associations of a TSI to the External NVE. An address association includes all the MAC and/or IP addresses possibly used as source addresses in a packet sent from the hypervisor to the External NVE. The External NVE may further use this information to filter the future traffic from the hypervisor.
2. ハイパーバイザーは、TSIのアドレスの関連付けを外部NVEに明示的に通知できます。アドレスの関連付けには、ハイパーバイザーから外部NVEに送信されるパケットの送信元アドレスとして使用される可能性のあるすべてのMACアドレスやIPアドレスが含まれます。外部NVEは、この情報をさらに使用して、ハイパーバイザーからの将来のトラフィックをフィルタリングできます。
To use the second approach above, the control-plane protocol running between the hypervisor and the NVE must support end devices communicating new tenant-address associations for a given TSI within a given VN.
上記の2番目のアプローチを使用するには、ハイパーバイザーとNVEの間で実行されるコントロールプレーンプロトコルが、特定のVN内の特定のTSIの新しいテナントアドレスアソシエーションを通信するエンドデバイスをサポートする必要があります。
Figure 6 shows an example of a state transition for a TSI connecting to a VAP on the External NVE. An NVE that supports the hypervisor-to-NVE control-plane protocol may support one instance of the state machine for each TSI connecting to a given VN.
図6は、外部NVE上のVAPに接続するTSIの状態遷移の例を示しています。ハイパーバイザーからNVEへのコントロールプレーンプロトコルをサポートするNVEは、特定のVNに接続するTSIごとに、状態マシンの1つのインスタンスをサポートする場合があります。
De-Associate +--------+ De-Associate
+--------------->| Init |<--------------------+
| +--------+ |
| | | |
| | | |
| +--------+ |
| | | |
| Associate | | Activate |
| +-----------+ +-----------+ |
| | | |
| | | |
| \|/ \|/ |
+--------------------+ +---------------------+
| Associated | | Activated |
+--------------------+ +---------------------+
|TSI_ID; | |TSI_ID; |
|Port; |-----Activate---->|Port; |
|VN_ID; | |VN_ID; |
|State=Associated; | |State=Activated; |-+
+-|Num_Of_Addr; |<---Deactivate ---|Num_Of_Addr; | |
| |List_Of_Addr; | |List_Of_Addr; | |
| +--------------------+ +---------------------+ |
| /|\ /|\ |
| | | |
+---------------------+ +-------------------+
add/remove/updt addr; add/remove/updt addr;
or update port; or update port;
Figure 6: State Transition Example of a TSI Instance on an External NVE
図6：外部NVE上のTSIインスタンスの状態遷移の例
The Associated state of a TSI instance on an External NVE indicates that all the addresses for that TSI have already associated with the VAP of the External NVE on a given port, e.g., on port p for a given VN, but no real traffic to and from the TSI is expected and allowed to pass through. An NVE has reserved all the necessary resources for that TSI. An External NVE may report the mappings of its underlay IP address and the associated TSI addresses to the NVA, and relevant network nodes may save such information to their mapping tables but not their forwarding tables. An NVE may create ACLs or filter rules based on the associated TSI addresses on that attached port p but not enable them yet. The local tag for the VN corresponding to the TSI instance should be provisioned on port p to receive packets.
外部NVE上のTSIインスタンスの関連付けられた状態は、そのTSIのすべてのアドレスが、特定のポート（たとえば、特定のVNのポートp）の外部NVEのVAPにすでに関連付けられているが、 TSIから期待され、通過することが許可されています。 NVEはそのTSIに必要なすべてのリソースを予約しています。外部NVEは、そのアンダーレイIPアドレスと関連するTSIアドレスのマッピングをNVAに報告し、関連するネットワークノードはそのような情報をマッピングテーブルに保存しますが、転送テーブルには保存しません。 NVEは、接続されているポートpの関連するTSIアドレスに基づいてACLまたはフィルタールールを作成しますが、まだ有効にしていない場合があります。 TSIインスタンスに対応するVNのローカルタグは、パケットを受信するためにポートpでプロビジョニングする必要があります。
The VM migration event (discussed in Section 2) may cause the hypervisor to send an Associate message to the NVE connected to the destination hypervisor of the migration. A VM creation event may also trigger the same scenario.
VM移行イベント（セクション2で説明）により、ハイパーバイザーは、移行の宛先ハイパーバイザーに接続されているNVEにAssociateメッセージを送信する場合があります。 VM作成イベントも同じシナリオをトリガーする可能性があります。
The Activated state of a TSI instance on an External NVE indicates that all the addresses for that TSI are functioning correctly on a given port, e.g., port p, and traffic can be received from and sent to that TSI via the NVE. The mappings of the NVE's underlay IP address and the associated TSI addresses should be added to the forwarding table rather than the mapping table on relevant network nodes. ACLs or filter rules based on the associated TSI addresses on the attached port p on the NVE are enabled. The local tag for the VN corresponding to the TSI instance must be provisioned on port p to receive packets.
外部NVE上のTSIインスタンスのアクティブ化状態は、そのTSIのすべてのアドレスが特定のポート（ポートpなど）で正しく機能しており、NVEを介してそのTSIからトラフィックを送受信できることを示します。 NVEのアンダーレイIPアドレスと関連するTSIアドレスのマッピングは、関連するネットワークノードのマッピングテーブルではなく、転送テーブルに追加する必要があります。 NVEの接続されたポートpの関連付けられたTSIアドレスに基づくACLまたはフィルタールールが有効になります。パケットを受信するには、TSIインスタンスに対応するVNのローカルタグをポートpでプロビジョニングする必要があります。
The Activate message makes the state transition from Init or Associated to Activated. VM creation, VM migration, and VM resumption events (discussed in Section 2) may trigger sending the Activate message from the hypervisor to the External NVE.
Activateメッセージは、InitまたはAssociatedからActivatedへの状態遷移を行います。 VMの作成、VMの移行、およびVMの再開イベント（セクション2で説明）により、ハイパーバイザーから外部NVEへのアクティブ化メッセージの送信がトリガーされる場合があります。
TSI information may get updated in either the Associated state or the Activated state. The following are considered updates to the TSI information: add or remove the associated addresses, update the current associated addresses (for example, update the IP address for a given MAC address), and update the NVE port information based on where the NVE receives messages. Such updates do not change the state of the TSI. When any address associated with a given TSI changes, the NVE should inform the NVA to update the mapping information for the NVE's underlying address and the associated TSI addresses. The NVE should also change its local ACLs or filter settings accordingly for the relevant addresses. Port information updates will cause the provisioning of the local tag for the VN corresponding to the TSI instance on the new port and removal from the old port.
TSI情報は、関連付けられた状態またはアクティブ化された状態で更新されます。以下は、TSI情報の更新と見なされます。関連アドレスの追加または削除、現在の関連アドレスの更新（たとえば、特定のMACアドレスのIPアドレスの更新）、およびNVEがメッセージを受信する場所に基づいてNVEポート情報を更新。そのような更新はTSIの状態を変更しません。特定のTSIに関連付けられているアドレスが変更された場合、NVEはNVAに、NVEの基礎となるアドレスと関連するTSIアドレスのマッピング情報を更新するよう通知する必要があります。 NVEは、関連するアドレスに応じて、ローカルACLまたはフィルター設定も適宜変更する必要があります。ポート情報の更新により、新しいポートのTSIインスタンスに対応するVNのローカルタグがプロビジョニングされ、古いポートから削除されます。
De-Associate and Deactivate behaviors are conceptually the reverse of Associate and Activate.
関連付け解除と非アクティブ化の動作は、概念的には関連付けとアクティブ化の逆です。
From the Activated state to the Associated state, the External NVE needs to make sure the resources are still reserved but the addresses associated with the TSI are not functioning. No traffic to or from the TSI is expected or allowed to pass through. For example, the NVE needs to tell the NVA to remove the relevant information regarding address mapping from the forwarding and routing tables. ACLs and filter rules regarding the relevant addresses should be disabled.
アクティブ化された状態から関連付けられた状態へ、外部NVEはリソースがまだ予約されていることを確認する必要がありますが、TSIに関連付けられたアドレスは機能していません。 TSIへの、またはTSIからのトラフィックは、通過することは想定されておらず、通過も許可されません。たとえば、NVEはNVAに、アドレスマッピングに関する関連情報を転送テーブルとルーティングテーブルから削除するように指示する必要があります。関連するアドレスに関するACLとフィルター規則は無効にする必要があります。
From the Associated or Activated state to the Init state, the NVE releases all the resources relevant to TSI instances. The NVE should also inform the NVA to remove the relevant entries from the mapping table. ACLs or filter rules regarding the relevant addresses should be removed. Local tag provisioning on the connecting port on the NVE should be cleared.
AssociatedまたはActivated状態からInit状態に、NVEはTSIインスタンスに関連するすべてのリソースを解放します。 NVEは、関連するエントリをマッピングテーブルから削除するようにNVAにも通知する必要があります。関連するアドレスに関するACLまたはフィルター規則は削除する必要があります。 NVEの接続ポートでのローカルタグのプロビジョニングをクリアする必要があります。
A VM suspension event (discussed in Section 2) may cause the relevant TSI instance(s) on the NVE to transition from the Activated state to the Associated state.
VMの一時停止イベント（セクション2で説明）により、NVE上の関連するTSIインスタンスがアクティブ化された状態から関連付けられた状態に移行する場合があります。
A VM pause event normally does not affect the state of the relevant TSI instance(s) on the NVE, as the VM is expected to run again soon.
VMがまもなく実行されることが予想されるため、VMの一時停止イベントは通常、NVE上の関連するTSIインスタンスの状態には影響しません。
A VM shutdown event will normally cause the relevant TSI instance(s) on the NVE to transition to the Init state from the Activated state. All resources should be released.
通常、VMシャットダウンイベントにより、NVE上の関連するTSIインスタンスがアクティブ化状態から初期化状態に移行します。すべてのリソースを解放する必要があります。
A VM migration will cause the TSI instance on the source NVE to leave the Activated state. When a VM migrates to another hypervisor connecting to the same NVE, i.e., the source and destination NVE are the same, the NVE should use the TSI_ID and the incoming port to differentiate two TSI instances.
VMを移行すると、ソースNVE上のTSIインスタンスがアクティブ化された状態のままになります。 VMが同じNVEに接続する別のハイパーバイザーに移行する場合、つまり、ソースと宛先のNVEが同じである場合、NVEはTSI_IDと受信ポートを使用して2つのTSIインスタンスを区別する必要があります。
Although the triggering messages for the state transition shown in Figure 6 do not indicate the difference between a VM creation/shutdown event and a VM migration arrival/departure event, the External NVE can make optimizations if it is given such information. For example, if the NVE knows that the incoming Activate message is caused by migration rather than VM creation, some mechanisms may be employed or triggered to make sure the dynamic configurations or provisionings on the destination NVE are the same as those on the source NVE for the migrated VM. For example, an IGMP query [RFC2236] can be triggered by the destination External NVE to the migrated VM so that the VM is forced to send an IGMP report to the multicast router. The multicast router can then correctly route the multicast traffic to the new External NVE for those multicast groups the VM joined before the migration.
図6に示されている状態遷移のトリガーメッセージは、VM作成/シャットダウンイベントとVM移行の到着/出発イベントの違いを示していませんが、外部NVEがそのような情報を提供されている場合、最適化を行うことができます。たとえば、着信アクティベートメッセージがVMの作成ではなく移行によって引き起こされていることをNVEが認識している場合、宛先NVEの動的構成またはプロビジョニングがソースNVEのそれらと同じであることを確認するために、いくつかのメカニズムが採用またはトリガーされます。移行されたVM。たとえば、IGMPクエリ[RFC2236]は、移行されたVMへの宛先外部NVEによってトリガーされ、VMが強制的にIGMPレポートをマルチキャストルーターに送信するようにできます。マルチキャストルーターは、移行前にVMが参加したマルチキャストグループの新しい外部NVEにマルチキャストトラフィックを正しくルーティングできます。
Req-1: The protocol MUST support a bridged network connecting end devices to the External NVE.
Req-1：プロトコルは、エンドデバイスを外部NVEに接続するブリッジネットワークをサポートする必要があります。
Req-2: The protocol MUST support multiple end devices sharing the same External NVE via the same physical port across a bridged network.
Req-2：プロトコルは、ブリッジされたネットワーク全体で同じ物理ポートを介して同じ外部NVEを共有する複数のエンドデバイスをサポートする必要があります。
Req-3: The protocol MAY support an end device using multiple External NVEs simultaneously, but only one External NVE for each VN (active-standby External NVE case for a VN).
Req-3：プロトコルは、複数の外部NVEを同時に使用するエンドデバイスをサポートする場合がありますが、VNごとに1つの外部NVE（VNのアクティブスタンバイ外部NVEケース）のみをサポートします。
Req-4: The protocol MAY support an end device using multiple External NVEs simultaneously for the same VN (active-active External NVE case for a VN).
Req-4：プロトコルは、同じVNに対して複数の外部NVEを同時に使用するエンドデバイスをサポートする場合があります（VNのアクティブ-アクティブ外部NVEケース）。
Req-5: The protocol MUST allow the end device to initiate a request to its associated External NVE to be connected/disconnected to a given VN.
Req-5：プロトコルは、エンドデバイスが関連する外部NVEへのリクエストを開始して、特定のVNに接続/切断することを許可する必要があります。
Req-6: The protocol MUST allow an External NVE initiating a request to its connected end devices to be disconnected from a given VN.
Req-6：プロトコルは、接続されたエンドデバイスへのリクエストを開始する外部NVEが特定のVNから切断されることを許可する必要があります。
Req-7: When a Tenant System attaches to a VN, the protocol MUST allow for an end device and its External NVE to negotiate one or more locally significant tags for carrying traffic associated with a specific VN (e.g., tags per [IEEE802.1Q]).
Req-7：テナントシステムがVNに接続する場合、プロトコルは、エンドデバイスとその外部NVEが特定のVNに関連付けられたトラフィックを運ぶためのローカルで重要なタグを1つ以上ネゴシエートできるようにする必要があります（たとえば、[IEEE802.1Q ]）。
Req-8: The protocol MUST allow an end device initiating a request to associate/de-associate and/or activate/deactivate some or all addresses of a TSI instance to a VN on an NVE port.
Req-8：プロトコルは、TSIインスタンスの一部またはすべてのアドレスをNVEポート上のVNに関連付け/関連付け解除および/またはアクティブ化/非アクティブ化する要求を開始するエンドデバイスを許可する必要があります。
Req-9: The protocol MUST allow the External NVE initiating a request to de-associate and/or deactivate some or all addresses of a TSI instance to a VN on an NVE port.
Req-9：プロトコルは、外部NVEがTSIインスタンスの一部またはすべてのアドレスをNVEポート上のVNに関連付け解除または非アクティブ化する要求を開始できるようにする必要があります。
Req-10: The protocol MUST allow an end device initiating a request to add, remove, or update address(es) associated with a TSI instance on the External NVE. Addresses can be expressed in different formats -- for example, MAC, IP, or IP-MAC pair.
Req-10：プロトコルは、外部NVE上のTSIインスタンスに関連付けられたアドレスを追加、削除、または更新する要求を開始するエンドデバイスを許可する必要があります。アドレスは、MAC、IP、IP-MACペアなど、さまざまな形式で表現できます。
Req-11: The protocol MUST allow the External NVE and the connected end device to authenticate each other.
Req-11：プロトコルは、外部NVEと接続されたエンドデバイスが互いに認証することを許可する必要があります。
Req-12: The protocol MUST be able to run over Layer 2 links between the end device and its External NVE.
Req-12：プロトコルは、エンドデバイスとその外部NVE間のレイヤー2リンク上で実行できる必要があります。
Req-13: The protocol SHOULD support an end device that indicates that an Associate or Activate request from the end device is the result of a VM hot migration event.
Req-13：プロトコルは、エンドデバイスからのAssociateまたはActivate要求がVMホットマイグレーションイベントの結果であることを示すエンドデバイスをサポートする必要があります（SHOULD）。
The Virtual Station Interface (VSI) Discovery and Configuration Protocol (VDP) [IEEE802.1Q] can be the control-plane protocol running between the hypervisor and the External NVE. Appendix A provides informative VDP illustrations for the reader.
仮想ステーションインターフェイス（VSI）検出および構成プロトコル（VDP）[IEEE802.1Q]は、ハイパーバイザーと外部NVEの間で実行されるコントロールプレーンプロトコルにすることができます。付録Aは、読者に有益なVDPの図を提供します。
VDP facilitates the automatic discovery and configuration of Edge Virtual Bridging (EVB) stations and EVB bridges. An EVB station is normally an end station running multiple VMs. In this document, it is considered conceptually equivalent to a hypervisor. An EVB bridge is conceptually equivalent to the External NVE.
VDPは、エッジ仮想ブリッジング（EVB）ステーションとEVBブリッジの自動検出と構成を容易にします。 EVBステーションは通常、複数のVMを実行しているエンドステーションです。このドキュメントでは、概念的にはハイパーバイザーと同等と見なされます。 EVBブリッジは概念的に外部NVEと同等です。
VDP is able to pre-associate/associate/de-associate a VSI on an EVB station with a port on the EVB bridge. In the context of this document, a VSI is conceptually approximate to a virtual port by which a VM connects to the hypervisor. The EVB station and the EVB bridge can reach agreement on VLAN ID(s) assigned to a VSI via a VDP message exchange. Other configuration parameters can be exchanged via VDP as well. VDP is carried over the Edge Control Protocol (ECP) [IEEE802.1Q], which provides reliable transportation over a Layer 2 network.
VDPは、EVBステーションのVSIをEVBブリッジのポートと事前に関連付ける/関連付ける/関連付けることができます。このドキュメントのコンテキストでは、VSIは概念的には、VMがハイパーバイザーに接続する仮想ポートに近似しています。 EVBステーションとEVBブリッジは、VDPメッセージ交換を介してVSIに割り当てられたVLAN IDについて合意に達することができます。他の構成パラメーターもVDPを介して交換できます。 VDPは、エッジコントロールプロトコル（ECP）[IEEE802.1Q]を介して伝送されます。これにより、レイヤー2ネットワーク上で信頼性の高い転送が提供されます。
VDP needs some extensions to fulfill the requirements listed in Section 4 of this document. Table 1 shows the needed extensions and/or clarifications in the NVO3 context.
このドキュメントのセクション4に記載されている要件を満たすには、VDPにいくつかの拡張機能が必要です。表1は、NVO3コンテキストで必要な拡張機能と説明を示しています。
+------+-----------+-----------------------------------------------+
| Req | Supported | Remarks |
| | by VDP? | |
+------+-----------+-----------------------------------------------+
| Req-1| | |
+------+ |Needs extension. Must be able to send to a |
| Req-2| |specific unicast MAC, and should be able to |
+------+ Partially |send to a non-reserved well-known multicast |
| Req-3| |address other than the nearest customer bridge |
+------+ |address. |
| Req-4| | |
+------+-----------+-----------------------------------------------+
| Req-5| Yes |The VN is indicated by GroupID. |
+------+-----------+-----------------------------------------------+
| Req-6| Yes |The bridge sends a De-Associate. |
+------+-----------+------------------------+----------------------+
| | |VID==NULL in the request. The bridge returns |
| | |the assigned VLAN ID (VID) value in the |
| Req-7| Yes |response. GroupID, which is optionally present|
| | |in the request, is equivalent to the VN ID in |
| | |the context of NVO3. Multiple VLANs per group |
| | |are allowed. |
+------+-----------+------------------------+----------------------+
| | | Requirements | VDP Equivalent |
| | +------------------------+----------------------+
| Req-8| Partially | Associate/De-Associate |Pre-Assoc/De-Associate|
| | | Activate/Deactivate |Associate/De-Associate|
| | +------------------------+----------------------|
| | |Needs extension to allow Associate->Pre-Assoc. |
+------+-----------+------------------------+----------------------+
| Req-9| Yes |The VDP bridge initiates a De-Associate. |
+------+-----------+-----------------------------------------------+
|Req-10| Partially |Needs extension for an IPv4/IPv6 address. |
| | |Add a new "filter information format" type. |
+------+-----------+-----------------------------------------------+
| | |An out-of-band mechanism is preferred, e.g., |
| | |MACsec or 802.1X. Implicit authentication |
|Req-11| No |based on control of physical connectivity |
| | |exists in VDP when the External NVE connects to|
| | |the end device directly and is reachable with |
| | |the nearest customer bridge address. |
+------+-----------+-----------------------------------------------+
|Req-12| Yes |VDP naturally runs on the Layer 2 protocol. |
+------+-----------+-----------------------------------------------+
| | |A migration event may cause the M-bit to be set|
| | |to 1 in the VDP request to the migration |
| | |destination hypervisor and the S-bit to be set |
| | |to 1 in the VDP request to the migration source|
| | |hypervisor. However, a setting of M-bit = 0 or|
|Req-13| Partially |S-bit = 0 can indicate that no information is |
| | |available regarding migration or that the |
| | |events in question are not caused by migration.|
| | |To fully meet the requirement, this ambiguity |
| | |would need to be fixed so that migration or no |
| | |migration could be safely inferred from the |
| | |M-bit or S-bit settings. |
+------+-----------+-----------------------------------------------+
Table 1: Comparison of Split-NVE Requirements and VDP Capabilities
表1：Split-NVE要件とVDP機能の比較
By simply adding the ability to carry Layer 3 addresses as per Req-10, VDP can provide most of the hypervisor-to-NVE control-plane functionality required.
Req-10のようにレイヤー3アドレスを伝送する機能を追加するだけで、VDPは必要なハイパーバイザーからNVEまでのコントロールプレーン機能のほとんどを提供できます。
External NVEs must ensure that only properly authorized Tenant Systems are allowed to join and become a part of any particular VN. In some cases, the tNVE may want to connect to the nNVE for provisioning purposes. This may require that the tNVE authenticate the nNVE in addition to the nNVE authenticating the tNVE. If a secure channel is required between the tNVE and the nNVE to carry the encrypted Split-NVE control-plane protocol, then existing mechanisms such as MACsec [IEEE802.1AE] can be used. In some deployments, authentication may be implicit, based on control of physical connectivity, e.g., if the nNVE is located in the bridge that is directly connected to the server that contains the tNVE. The use of the "nearest customer bridge address" in VDP [IEEE802.1Q] is an example of where this sort of implicit authentication is possible, although explicit authentication also applies in that case.
外部NVEは、適切に承認されたテナントシステムのみが特定のVNに参加し、その一部になることを許可する必要があります。場合によっては、プロビジョニングのためにtNVEがnNVEに接続することがあります。これには、tNVEを認証するnNVEに加えて、tNVEがnNVEを認証する必要がある場合があります。暗号化されたSplit-NVEコントロールプレーンプロトコルを伝送するためにtNVEとnNVEの間に安全なチャネルが必要な場合は、MACsec [IEEE802.1AE]などの既存のメカニズムを使用できます。一部の展開では、物理接続の制御に基づいて、認証が暗黙的に行われる場合があります。たとえば、nNVEが、tNVEを含むサーバーに直接接続されているブリッジにある場合などです。 VDP [IEEE802.1Q]での「最も近いカスタマーブリッジアドレス」の使用は、この種の暗黙的な認証が可能な例ですが、その場合は明示的な認証も適用されます。
As the control-plane protocol results in configuration changes for both the tNVE and the nNVE, tNVE and nNVE implementations should log all state changes, including those described in Section 3. Implementations should also log significant protocol events, such as the establishment or loss of control-plane protocol connectivity between the tNVE and the nNVE, as well as authentication results.
コントロールプレーンプロトコルの結果、tNVEとnNVEの両方の構成が変更されるため、tNVEとnNVEの実装では、セクション3で説明されているものを含め、すべての状態変更をログに記録する必要があります。 tNVEとnNVEの間のコントロールプレーンプロトコル接続、および認証結果。
In addition, External NVEs will need appropriate mechanisms to ensure that any hypervisor wishing to use the services of an NVE is properly authorized to do so. One design point is whether the hypervisor should
さらに、外部NVEには、NVEのサービスを使用することを希望するハイパーバイザーがそうすることを適切に承認されていることを確認するための適切なメカニズムが必要です。設計上のポイントの1つは、ハイパーバイザーが
1. supply the External NVE with necessary information (e.g., VM addresses, VN information, or other parameters) that the External NVE uses directly or
1. 外部NVEが直接使用する必要な情報（例：VMアドレス、VN情報、またはその他のパラメーター）を外部NVEに提供する
2. only supply a VN ID and an identifier for the associated VM (e.g., its MAC address), with the External NVE using that information to obtain the information needed to validate the hypervisor-provided parameters or obtain related parameters in a secure manner.
2. VN IDと関連付けられたVMの識別子（そのMACアドレスなど）のみを提供し、外部NVEはその情報を使用して、ハイパーバイザー提供のパラメーターを検証するために必要な情報を取得するか、関連するパラメーターを安全な方法で取得します。
The former approach can be used in a trusted environment so that the External NVE can directly use all the information retrieved from the hypervisor for local configuration. It relieves the External NVE side of effort related to information retrieval and/or validation. The latter approach gives more reliable information, as the External NVE needs to retrieve it from a management-system database. In particular, some network-related parameters, such as VLAN IDs, can be passed back to the hypervisor to be used as a form of provisioning that is more authoritative. However, in certain cases it is difficult or inefficient for an External NVE to be granted rights to access or query information on those management systems. The External NVE then has to obtain the information from the hypervisor.
前者のアプローチは信頼できる環境で使用できるため、外部NVEはハイパーバイザーから取得したすべての情報をローカル設定に直接使用できます。情報の取得や検証に関連する作業の外部NVE側を軽減します。後者のアプローチは、外部NVEが管理システムデータベースから情報を取得する必要があるため、より信頼できる情報を提供します。特に、VLAN IDなどの一部のネットワーク関連パラメーターは、より信頼できるプロビジョニングの形式として使用するために、ハイパーバイザーに戻すことができます。ただし、場合によっては、外部NVEにこれらの管理システムの情報にアクセスしたり、情報を照会したりする権限を付与することが困難または非効率的です。次に、外部NVEはハイパーバイザーから情報を取得する必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[IEEE802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks", IEEE Standard 802.1Q-2014, DOI 10.1109/IEEESTD.2014.6991462.
[IEEE802.1Q] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準-ブリッジおよびブリッジネットワーク」、IEEE標準802.1Q-2014、DOI 10.1109 / IEEESTD.2014.6991462。
[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>。
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for Data Center (DC) Network Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 2014, <https://www.rfc-editor.org/info/rfc7365>.
[RFC7365] Lasserre、M.、Balus、F.、Morin、T.、Bitar、N。、およびY. Rekhter、「Framework for Data Center（DC）Network Virtualization」、RFC 7365、DOI 10.17487 / RFC7365、2014年10月、<https://www.rfc-editor.org/info/rfc7365>。
[RFC7666] Asai, H., MacFaden, M., Schoenwaelder, J., Shima, K., and T. Tsou, "Management Information Base for Virtual Machines Controlled by a Hypervisor", RFC 7666, DOI 10.17487/RFC7666, October 2015, <https://www.rfc-editor.org/info/rfc7666>.
[RFC7666] Asai、H.、MacFaden、M.、Schoenwaelder、J.、Shima、K。、およびT. Tsou、「ハイパーバイザによって制御される仮想マシンの管理情報ベース」、RFC 7666、DOI 10.17487 / RFC7666、10月2015、<https://www.rfc-editor.org/info/rfc7666>。
[RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. Narten, "An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3)", RFC 8014, DOI 10.17487/RFC8014, December 2016, <https://www.rfc-editor.org/info/rfc8014>.
[RFC8014] Black、D.、Hudson、J.、Kreeger、L.、Lasserre、M。、およびT. Narten、「An Layer for Data-Center Network Virtualization over Layer 3（NVO3）」、RFC 8014、DOI 10.17487 / RFC8014、2016年12月、<https://www.rfc-editor.org/info/rfc8014>。
[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>。
[IEEE802.1AE] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Security", IEEE Standard 802.1AE-2006, DOI 10.1109/IEEESTD.2006.245590.
[IEEE802.1AE] IEEE、「IEEE Standard for Local and Metropolitan Area Networks：Media Access Control（MAC）Security」、IEEE Standard 802.1AE-2006、DOI 10.1109 / IEEESTD.2006.245590。
[NVO3-HYPERVISOR-NVE-CP] Kreeger, L., Narten, T., and D. Black, "Network Virtualization Hypervisor-to-NVE Overlay Control Protocol Requirements", Work in Progress, draft-kreeger-nvo3- hypervisor-nve-cp-01, February 2013.
[NVO3-HYPERVISOR-NVE-CP]クリーガー、L。、ナルテン、T。、およびD.ブラック、「ネットワーク仮想化ハイパーバイザーからNVEオーバーレイ制御プロトコルの要件」、作業中、draft-kreeger-nvo3- hypervisor- nve-cp-01、2013年2月。
[NVO3-TES-NVE] Yingjie, G. and L. Yizhou, "The mechanism and signalling between TES and NVE", Work in Progress, draft-gu-nvo3-tes-nve-mechanism-01, October 2012.
[NVO3-TES-NVE] Yingjie、G.およびL. Yizhou、「メカニズムとTESとNVEの間のシグナリング」、Work in Progress、draft-gu-nvo3-tes-nve-mechanism-01、2012年10月。
[NVO3-VM-NVE] Kompella, K., Rekhter, Y., Morin, T., and D. Black, "Signaling Virtual Machine Activity to the Network Virtualization Edge", Work in Progress, draft-kompella-nvo3-server2nve-02, April 2013.
[NVO3-VM-NVE] Kompella、K.、Rekhter、Y.、Morin、T。、およびD. Black、「ネットワーク仮想化エッジへの仮想マシンアクティビティのシグナリング」、作業中、draft-kompella-nvo3-server2nve -02、2013年4月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, <https://www.rfc-editor.org/info/rfc2236>.
[RFC2236] Fenner、W。、「インターネットグループ管理プロトコル、バージョン2」、RFC 2236、DOI 10.17487 / RFC2236、1997年11月、<https://www.rfc-editor.org/info/rfc2236>。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc4122>.
[RFC4122] Leach、P.、Mealling、M。、およびR. Salz、「Universally Unique IDentifier（UUID）URN Namespace」、RFC 4122、DOI 10.17487 / RFC4122、2005年7月、<https：//www.rfc- editor.org/info/rfc4122>。
[RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L., Kreeger, L., and M. Napierala, "Problem Statement: Overlays for Network Virtualization", RFC 7364, DOI 10.17487/RFC7364, October 2014, <https://www.rfc-editor.org/info/rfc7364>.
[RFC7364] Narten、T.、Ed。、Gray、E.、Ed。、Black、D.、Fang、L.、Kreeger、L。、およびM. Napierala、「Problem Statement：Overlays for Network Virtualization」、RFC 7364、DOI 10.17487 / RFC7364、2014年10月、<https://www.rfc-editor.org/info/rfc7364>。
Appendix A. VDP Illustrations (per IEEE 802.1Q) (for Information Only)
付録A. VDPの図（IEEE 802.1Qに準拠）（情報提供のみ）
VDP (the VSI Discovery and Discovery and Configuration Protocol; see Clause 41 of [IEEE802.1Q]) can be considered as a controlling protocol running between the hypervisor and the external bridge. The VDP association TLV structure is formatted as shown in Figure 7.
VDP（VSI DiscoveryおよびDiscovery and Configuration Protocol。[IEEE802.1Q]の41項を参照）は、ハイパーバイザーと外部ブリッジ間で実行される制御プロトコルと見なすことができます。 VDPアソシエーションTLV構造は、図7に示すようにフォーマットされます。
+--------+--------+------+-----+--------+------+------+------+------+
|TLV Type|TLV Info|Status|VSI |VSI Type|VSI ID|VSI ID|Filter|Filter|
| |String | |Type |Version |Format| |Info |Info |
| |Length | |ID | | | |Format| |
+--------+--------+------+-----+--------+------+------+------+------+
| | |<--VSI Type and instance--->|<--Filter--->|
| | |<-------------VSI attributes------------->|
|<--TLV header--->|<-----------TLV information string ------------->|
Figure 7: VDP Association TLV
図7：VDPアソシエーションTLV
There are basically four TLV types.
基本的に4つのTLVタイプがあります。
1. Pre-Associate: The Pre-Associate is used to Pre-Associate a VSI instance with a bridge port. The bridge validates the request and returns a failure status in the case of errors. A successful Pre-Associate does not imply that the indicated VSI Type or provisioning will be applied to any traffic flowing through the VSI. By allowing the bridge to obtain the VSI Type prior to an association, the Pre-Associate enables faster response to an Associate.
1. 事前関連付け：事前関連付けは、VSIインスタンスをブリッジポートに事前関連付けするために使用されます。ブリッジはリクエストを検証し、エラーの場合は失敗ステータスを返します。事前関連付けが成功しても、示されたVSIタイプまたはプロビジョニングがVSIを通過するトラフィックに適用されることを意味するものではありません。アソシエーションの前にブリッジがVSIタイプを取得できるようにすることで、プレアソシエイトはアソシエートへのより迅速な応答を可能にします。
2. Pre-Associate with Resource Reservation: The Pre-Associate with Resource Reservation involves the same steps as those for the Pre-Associate, but on success it also reserves resources in the bridge to prepare for a subsequent Associate request.
2. リソース予約との事前関連付け：リソース予約との事前関連付けには、事前関連付けと同じ手順が含まれますが、成功すると、ブリッジ内のリソースが予約され、後続の関連付けリクエストに備えて準備されます。
3. Associate: The Associate request creates and activates an association between a VSI instance and a bridge port. A bridge allocates any required bridge resources for the referenced VSI. The bridge activates the configuration for the VSI Type ID. This association is then applied to the traffic flow to/from the VSI instance.
3. Associate：Associate要求は、VSIインスタンスとブリッジポート間の関連付けを作成してアクティブにします。ブリッジは、参照されるVSIに必要なすべてのブリッジリソースを割り当てます。ブリッジは、VSIタイプIDの構成をアクティブにします。この関連付けは、VSIインスタンスとの間のトラフィックフローに適用されます。
4. De-Associate: The De-Associate is used to remove an association between a VSI instance and a bridge port. Pre-associated and associated VSIs can be de-associated. The De-Associate releases any resources that were reserved as a result of prior Associate or Pre-Associate operations for that VSI instance.
4. 関連付け解除：関連付け解除は、VSIインスタンスとブリッジポート間の関連付けを削除するために使用されます。事前関連付けおよび関連付けられたVSIは、関連付けを解除できます。 De-Associateは、そのVSIインスタンスに対する以前のAssociateまたはPre-Associate操作の結果として予約されたすべてのリソースを解放します。
The De-Associate can be initiated by either side, and the other types can only be initiated by the server side.
関連付け解除はどちらの側でも開始でき、他のタイプはサーバー側でのみ開始できます。
Some important flag values in the VDP Status field are as follows:
VDPステータスフィールドのいくつかの重要なフラグ値は次のとおりです。
1. M-bit (Bit 5): M-bit = 1: indicates that the user of the VSI (e.g., the VM) is migrating. M-bit = 0: no indication of whether the VSI user is migrating. The M-bit is used as an indicator relative to the VSI to which the user is migrating.
1. Mビット（ビット5）：Mビット= 1：VSIのユーザー（VMなど）が移行していることを示します。 Mビット= 0：VSIユーザーが移行しているかどうかの表示なし。 Mビットは、ユーザーの移行先のVSIに対するインジケーターとして使用されます。
2. S-bit (Bit 6): S-bit = 1: indicates that the VSI user (e.g., the VM) is suspended. S-bit = 0: no indication of whether the VSI user is suspended. A keep-alive Associate request with S-bit = 1 can be sent when the VSI user is suspended. The S-bit is used as an indicator relative to the VSI from which the user is migrating.
2. Sビット（ビット6）：Sビット= 1：VSIユーザー（VMなど）が一時停止されていることを示します。 Sビット= 0：VSIユーザーが一時停止されているかどうかは示されません。 SSIビットが1のキープアライブアソシエート要求は、VSIユーザーが一時停止されているときに送信できます。 Sビットは、ユーザーの移行元のVSIに関連するインジケーターとして使用されます。
The filter information format currently defines four types. Information for each of these types is shown in detail in Figures 8 through 11. "PCP" stands for Priority Code Point [IEEE802.1Q]. The PCP value, if specified, is used by the EVB station as the default PCP value associated with the VSI and VID. The filter information contains a PCP Significant (PS) bit associated with each PCP field, indicating whether the PCP field carries a PCP value (binary 1) or does not carry a PCP value (binary 0).
現在、フィルター情報フォーマットは4つのタイプを定義しています。これらの各タイプの情報は、図8〜11に詳細に示されています。「PCP」は、優先コードポイント[IEEE802.1Q]を表します。 PCP値が指定されている場合、EVBステーションはVSIおよびVIDに関連付けられたデフォルトのPCP値として使用します。フィルター情報には、各PCPフィールドに関連付けられたPCP有意（PS）ビットが含まれ、PCPフィールドがPCP値を運ぶ（バイナリ1）か、PCP値を運ばない（バイナリ0）かを示します。
+----------+-------+--------+--0------+
| # of | PS | PCP | VID |
|entries |(1 bit)|(3 bits)|(12 bits)|
|(2 octets)| | | |
+----------+-------+--------+---------+
|<---Repeated per entry--->|
Figure 8: VID Filter Information Format
図8：VIDフィルター情報フォーマット
+----------+--------------+-------+--------+---------+
| # of | MAC address | PS | PCP | VID |
|entries | (6 octets) |(1 bit)|(3 bits)|(12 bits)|
|(2 octets)| | | | |
+----------+--------------+-------+--------+---------+
|<----------Repeated per entry----------->|
Figure 9: MAC/VID Filter Information Format
図9：MAC / VIDフィルター情報フォーマット
+----------+--------------+-------+--------+---------+
| # of | GroupID | PS | PCP | VID |
|entries | (4 octets) |(1 bit)|(3 bits)|(12 bits)|
|(2 octets)| | | | |
+----------+--------------+-------+--------+---------+
|<----------Repeated per entry----------->|
Figure 10: GroupID/VID Filter Information Format
図10：GroupID / VIDフィルター情報フォーマット
+----------+----------+-------------+-------+--------+---------+
| # of | GroupID | MAC address | PS | PCP | VID |
|entries |(4 octets)| (6 octets) |(1 bit)|(3 bits)|(12 bits)|
|(2 octets)| | | | | |
+----------+----------+-------------+-------+--------+---------+
|<---------------Repeated per entry---------------->|
Figure 11: GroupID/MAC/VID Filter Information Format
The null VID can be used in the VDP Request sent from the station to the external bridge. The null VID indicates that the set of VID values associated with the VSI is expected to be supplied by the bridge. The set of VID values is returned to the station via the VDP Response. The returned VID values can be locally significant values. When GroupID is used, it is equivalent to the VN ID in NVO3. GroupID will be provided by the station to the bridge. The bridge maps GroupID to a locally significant VLAN ID.
ヌルVIDは、ステーションから外部ブリッジに送信されるVDP要求で使用できます。 null VIDは、VSIに関連付けられたVID値のセットがブリッジによって提供されることが期待されることを示します。 VID値のセットは、VDP応答を介してステーションに返されます。返されるVID値は、ローカルで重要な値になる場合があります。 GroupIDを使用する場合、NVO3のVN IDと同等です。 GroupIDはステーションからブリッジに提供されます。ブリッジは、GroupIDをローカルで有効なVLAN IDにマップします。
The VSI ID in the VDP association TLV that identifies a VM can be in one of the following formats: IPv4 address, IPv6 address, MAC address, Universally Unique Identifier (UUID) [RFC4122], or locally defined.
VMを識別するVDPアソシエーションTLVのVSI IDは、IPv4アドレス、IPv6アドレス、MACアドレス、Universally Unique Identifier（UUID）[RFC4122]、またはローカルで定義された形式のいずれかです。
Acknowledgements
謝辞
This document was initiated based on the merger of the following documents: [NVO3-HYPERVISOR-NVE-CP], [NVO3-TES-NVE], and [NVO3-VM-NVE]. Thanks to all the coauthors and contributing members of those documents.
このドキュメントは、[NVO3-HYPERVISOR-NVE-CP]、[NVO3-TES-NVE]、および[NVO3-VM-NVE]のドキュメントの統合に基づいて開始されました。これらのドキュメントのすべての共著者と寄稿者に感謝します。
The authors would like to specially thank Lucy Yong and Jon Hudson for their generous help in improving this document.
このドキュメントの改善に多大なご協力をいただいたLucy YongとJon Hudsonに特に感謝いたします。
Authors' Addresses
著者のアドレス
Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China
Y I週l IH UAはテクノロジー101ソフトウェアアベニューNaNjing 210012中国
Phone: +86-25-56625409
Email: liyizhou@huawei.com
Donald Eastlake 3rd Huawei R&D USA 155 Beaver Street Milford, MA 01757 United States of America
ドナルドイーストレイク3rd Huawei R＆D USA 155 Beaver Street Milford、MA 01757アメリカ合衆国
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Lawrence Kreeger Arrcus, Inc.
Lawrence Kreeger Arrcus、Inc.
Email: lkreeger@gmail.com
Thomas Narten IBM
Thomas Narten IBM
Email: narten@us.ibm.com
David Black Dell EMC 176 South Street Hopkinton, MA 01748 United States of America
デビッドブラックDell EMC 176サウスストリートホプキントン、MA 01748アメリカ合衆国
Email: david.black@dell.com