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
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
拆分网络虚拟化边缘（拆分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之间的一个或多个控制平面协议将其虚拟机网络状态分发给外部NVE以进行进一步处理。本文件说明了此类控制平面信令协议所需的功能，并概述了高级要求。总结虚拟机状态以及状态转换，以帮助澄清协议要求。
Status of This Memo
关于下段备忘
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/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.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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 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
+------------ Split-NVE ---------+
| |
| |
+-----------------|-----+ |
| +---------------|----+| |
| | +--+ \|/ || |
| | |V |TSI +-------+ || +------|-------------+
| | |M |-----+ | || | \|/ |
| | +--+ | | || |+--------+ |
| | +--+ | tNVE | ||-------------------|| | |
| | |V |TSI | | || || nNVE | |
| | |M |-----| | || || | |
| | +--+ +-------+ || |+--------+ |
| | || +--------------------+
| +-----Hypervisor-----+|
+-----------------------+
End Device External NVE
Figure 1: Split-NVE Structure
图1：拆分的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场景时始终使用术语“虚拟机监控程序”，其中部分NVE功能从包含连接到VN（虚拟网络）的VM（虚拟机）的“虚拟机监控程序”卸载到单独的设备。在此上下文中，术语“hypervisor”意指涵盖以这种方式卸载部分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
第3层网络虚拟化（NVO3）问题陈述[RFC7364]讨论了控制平面协议（一个或多个协议）的需要，以向每个NVE填充执行所需功能所需的状态。在一个场景中，NVE向共同驻留在同一终端设备上的NVE内的租户系统提供覆盖封装/去封装分组转发服务
(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].
（例如，当NVE嵌入虚拟机监控程序或网络服务设备中时）。在这种情况下，虚拟机监控程序和NVE之间不需要标准化协议，因为交互是通过单个设备上的软件实现的。但是，在图2至图4所示的拆分NVE体系结构场景中（参见第1.2节），虚拟机监控程序及其关联的外部NVE之间需要一个或多个控制平面协议，以便虚拟机监控程序将VM的网络状态分发给NVE进行进一步处理。该协议是一个NVE内部协议，在tNVE和nNVE逻辑实体之间运行。NVO3问题声明[RFC7364]第4.5节“第三工作区”文本中提到了该协议。
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需要采取特定操作的事件。此类事件可能对应于控制平面信令协议或协议在拆分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.
为了描述需求，本文档使用虚拟机作为租户系统的示例，即使虚拟机只是可能连接到VN的一种租户系统。例如，网络服务设备中的服务实例是另一种类型的租户系统，运行在操作系统级虚拟化技术（如容器）上的系统也是如此。虚拟机具有生命周期（例如，可以创建和销毁、可以移动、可以启动或停止）这一事实导致了一组通用的协议要求，其中大多数适用于其他形式的租户系统，尽管并非所有要求都适用于所有形式的租户系统。
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节描述了虚拟机状态和虚拟机生命周期中的状态转换。第3节介绍了从虚拟机操作和网络事件派生的虚拟机监控程序到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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照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.
拆分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。位于支持虚拟化的终端设备上的拆分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。位于网络设备上的拆分NVE功能部分，直接或间接连接到包含相应tNVE的终端设备。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.
Hypervisor：允许创建和运行服务器或服务设备虚拟化的软件、固件和/或硬件的逻辑集合。tNVE位于虚拟机监控程序下。在本文档中，术语“hypervisor”泛指支持虚拟化的终端设备。为了简单起见，我们还使用术语“hypervisor”来表示hypervisor和容器。
Container: Please see "Hypervisor:" above.
容器：请参阅上面的“Hypervisor:”。
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任何连接点的元数据（即，VAP（虚拟接入点）属性，该属性应用于与给定VN关联的所有VAP，并由NVE在向特定VN进出数据包时使用）。元数据可以包括访问控制列表（ACL）和QoS设置等信息。VN配置文件包含应用于整个VN的参数。NVE和NVA（网络虚拟化机构）之间的控制协议可以使用VN ID或VN名称来获取VN配置文件。
VSI: Virtual Station Interface. See [IEEE802.1Q].
虚拟站接口。参见[IEEE802.1Q]。
VDP: VSI Discovery and Configuration Protocol. See [IEEE802.1Q].
VDP:VSI发现和配置协议。参见[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给出了拆分NVE体系结构的示例场景。
Hypervisor Access Switch
+------------------+ +-----+-------+
| +--+ +-------+ | | | |
| |VM|---| | | VLAN | | |
| +--+ | tNVE |---------+ nNVE| +--- Underlying
| +--+ | | | Trunk | | | Network
| |VM|---| | | | | |
| +--+ +-------+ | | | |
+------------------+ +-----+-------+
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|---| | | | | | | |
| +--+ +----+ | | | | | |
+---------------+ +-----+ +----+---+
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 | | / | | | |
| +---------------+ | / | | | |
+-----------------------------+ +-----+-------+
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逻辑连接到外部NVE[RFC8014]。外部NVE可提供第2层或第3层转发。在拆分NVE架构中，外部NVE可以通过TSI到达多个媒体访问控制（MAC）地址和IP地址。IP地址可以是IPv4或IPv6格式。例如，提供网络服务的租户系统（如透明防火墙、负载平衡器或VPN网关）可能具有复杂的地址层次结构。这意味着，如果给定TSI从一个VN解除关联，则所有MAC和/或IP地址也解除关联。当TSI关闭或删除时，无需发出删除每个MAC或IP地址的信号。在大多数情况下，虚拟机将充当一个简单的主机，具有一个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显示了使用VLAN来分离tNVE和nNVE之间多个VN的流量；如果只涉及一个VN，则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的状态和转换。外部NVE对某些VM状态感兴趣。本节说明了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处于正常执行状态。作为将虚拟机转换到运行状态的一部分，虚拟机监控程序还必须为虚拟机的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地址。除了外部网络连接之外，虚拟机监控程序还可以为共同驻留在同一虚拟机监控程序上的其他虚拟机提供虚拟机的TSI和TSI之间的本地网络连接。当虚拟机监控程序内部或内部连接扩展到外部NVE时，应在虚拟机监控程序和外部NVE之间使用本地有效标记，例如VLAN ID，以区分每个VN的流量。虚拟机监控程序和外部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
实时迁移有时被称为“热”迁移，因为从外部的角度来看，虚拟机在迁移到另一台服务器时似乎会继续运行（例如，TCP连接通常会在此类迁移中存活）。相反，“冷”迁移
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执行并在另一台服务器上重新启动它。为简单起见，以下实时迁移的抽象摘要假定共享存储，以便源服务器和目标服务器可以访问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（如果有）以及提供TSI的其他网络相关参数，将迁移VM的TSI与其自身（即外部NVE）相关联。外部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不应同时处于运行状态。源虚拟机监控程序上的虚拟机在成功进入目标虚拟机监控程序上的运行状态之前不会转换到关闭状态。在目标虚拟机监控程序上的虚拟机进入运行状态后，源虚拟机监控程序上的虚拟机可能会保持迁移状态一段时间。
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终止有两种可能的原因：
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. 虚拟机已迁移到另一个虚拟机监控程序，源虚拟机监控程序上的虚拟机映像必须停止执行并关闭。
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.
在虚拟机终止中，连接到该虚拟机的外部NVE需要取消提供虚拟机，即删除与该虚拟机关联的网络参数。换句话说，外部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从运行状态转换为“暂停”状态。暂停状态表示虚拟机驻留在内存中，但虚拟机监控程序未计划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执行状态保存到持久存储中。在此状态下，虚拟机监控程序[RFC7666]不会安排虚拟机的CPU执行。
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.
在拆分的NVE体系结构中，外部NVE不应解除暂停或挂起的VM的关联，因为VM可以随时返回到运行状态。
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.
在拆分NVE场景中，终端设备（例如，虚拟机监控程序）和它使用的外部NVE之间需要一个协议，以使外部NVE了解终端设备内租户系统不断变化的VN成员资格要求。
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的静态配置的一个关键驱动因素是，在整个数据中心或外部云的各种虚拟机监控程序上启动、移动和关闭虚拟机时，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
图5显示了外部NVE上VAP的状态转换。支持虚拟机监控程序到NVE控制平面协议的NVE应该为每个活动VN支持一个状态机实例。外部NVE上的状态转换通常由
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.
面向虚拟机监控程序一侧的事件和行为。为了更好地解释整个过程，将对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; |
+----------------------+
+----------------+ 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应为每个连接到终端设备的VN提供本地标签值，以用于在终端设备和外部NVE之间交换数据包（例如，根据[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
此协议中的VN标识可以通过VN名称或VN ID进行。全局唯一的VN名称有助于租户虚拟数据中心的可移植性。曾经是一个外部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_Connect消息时，NVE需要一种方法来为给定的VN名称或VN ID（以及传输封装数据包所需的任何其他信息）获得分配的VN_上下文（或接收已分配的VN_上下文）。如何做到这一点是NVE到NVA协议的主题；参见[RFC7364]第4.5节中的“前两个工作领域”文本。外部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关联消息（见下一小节），该消息隐式表示其对连接到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地址与租户系统代表相应的VN转发到NVA的所有地址之间的映射。
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有两种方法可以发现要将帧转发到给定终端设备（并最终转发到该终端设备内的租户系统）的租户地址。
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. 虚拟机监控程序可以显式地向外部NVE发送TSI的地址关联信号。地址关联包括从虚拟机监控程序发送到外部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.
要使用上面的第二种方法，在虚拟机监控程序和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显示了TSI连接到外部NVE上VAP的状态转换示例。支持虚拟机监控程序到NVE控制平面协议的NVE可以为连接到给定VN的每个TSI支持一个状态机实例。
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;
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
外部NVE上TSI实例的关联状态表示该TSI的所有地址已经与给定端口上的外部NVE的VAP关联，例如，在给定VN的端口p上，但预期和允许不存在进出TSI的真实流量。NVE已为该TSI保留了所有必要的资源。外部NVE可向NVA报告其基线IP地址和相关TSI地址的映射，以及相关
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可以基于连接端口p上的关联TSI地址创建ACL或筛选规则，但尚未启用它们。应在端口p上设置与TSI实例对应的VN的本地标记以接收数据包。
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发送关联消息。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或筛选规则。必须在端口p上设置与TSI实例对应的VN的本地标记以接收数据包。
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.
激活消息使状态从Init或关联转换为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的交通通过。例如，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.
从关联或激活状态到初始状态，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暂停事件通常不会影响NVE上相关TSI实例的状态，因为VM预计很快会再次运行。
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和传入端口来区分两个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
尽管图6中所示的状态转换触发消息并不表示VM创建/关闭事件和VM迁移到达/离开事件之间的区别，但如果外部NVE获得此类信息，则可以进行优化。例如，如果NVE知道传入的激活消息是由迁移而不是VM创建引起的，则可以使用或触发一些机制来确保目标NVE上的动态配置或供应与迁移VM的源NVE上的动态配置或供应相同。例如，IGMP查询[RFC2236]可以由目标外部NVE触发到迁移的VM，从而迫使VM向其发送IGMP报告
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.
多播路由器。然后，对于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仅支持一个外部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：协议可支持终端设备同时使用多个外部NVE用于同一个VN（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相关的流量（例如，符合[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：协议应支持终端设备，该终端设备指示来自终端设备的关联或激活请求是VM热迁移事件的结果。
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在概念上近似于虚拟机连接到虚拟机监控程序的虚拟端口。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.
VDP需要一些扩展以满足本文件第4节中列出的要求。表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. |
+------+-----------+-----------------------------------------------+
| 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. |
+------+-----------+-----------------------------------------------+
+------+-----------+-----------------------------------------------+
| | |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：拆分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除了验证tNVE的nNVE之外，还验证nNVE。如果tNVE和nNVE之间需要一个安全通道来承载加密的拆分NVE控制平面协议，则可以使用现有机制，如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服务的虚拟机监控程序都得到适当授权。一个设计点是hypervisor是否应该
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提供外部NVE直接或间接使用的必要信息（例如VM地址、VN信息或其他参数）
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. 仅为相关VM提供VN ID和标识符（例如，其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可以直接使用从hypervisor检索的所有信息进行本地配置。它减轻了与信息检索和/或验证相关的外部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，“数据中心（DC）网络虚拟化框架”，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.，Schoenwaeld，J.，Shima，K.，和T.Tsou，“虚拟机监控程序控制的虚拟机管理信息库”，RFC 7666，DOI 10.17487/RFC7666，2015年10月<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，“第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标准：媒体访问控制（MAC）安全”，IEEE标准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]Kreeger，L.，Narten，T.，和D.Black，“网络虚拟化HYPERVISOR到NVE覆盖控制协议要求”，正在进行的工作，草稿-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之间的机制和信号”，正在进行的工作，草稿-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，“向网络虚拟化边缘发送虚拟机活动信号”，正在进行的工作，草稿-Kompella-NVO3-server2nve-022013年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，“通用唯一标识符（UUID）URN名称空间”，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，“问题陈述：网络虚拟化覆盖”，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发现、发现和配置协议；参见[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 ------------->|
+--------+--------+------+-----+--------+------+------+------+------+
|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.
基本上有四种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. 关联：关联请求创建并激活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。取消关联将释放由于先前针对该VSI实例的关联或预关联操作而保留的任何资源。
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-bit=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用户是否挂起。当VSI用户挂起时，可以发送S位为1的保持活动关联请求。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).
过滤器信息格式当前定义了四种类型。图8至图11中详细显示了每种类型的信息。“PCP”代表优先级代码点[IEEE802.1Q]。如果指定，EVB站将PCP值用作与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--->|
+----------+-------+--------+--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----------->|
+----------+--------------+-------+--------+---------+
| # 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----------->|
+----------+--------------+-------+--------+---------+
| # 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---------------->|
+----------+----------+-------------+-------+--------+---------+
| # 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
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.
VDP关联TLV中标识VM的VSI ID可以采用以下格式之一：IPv4地址、IPv6地址、MAC地址、通用唯一标识符（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
宜州利华为技术有限公司软件大道101号南京210012
Phone: +86-25-56625409
Email: liyizhou@huawei.com
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
美国马萨诸塞州米尔福德市海狸街155号唐纳德·伊斯特莱克第三华为研发部美国01757
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Lawrence Kreeger Arrcus, Inc.
劳伦斯·克雷格·阿卡斯公司。
Email: lkreeger@gmail.com
Email: lkreeger@gmail.com
Thomas Narten IBM
托马斯·纳腾IBM
Email: narten@us.ibm.com
Email: narten@us.ibm.com
David Black Dell EMC 176 South Street Hopkinton, MA 01748 United States of America
David Black Dell EMC美国马萨诸塞州霍普金顿南街176号01748
Email: david.black@dell.com
Email: david.black@dell.com