Framework for Data Center （DC） Network Virtualization，October 2014
梗概
本文档提供了数据中心 （Data Center，DC） 3 层网络虚拟化 （Network Virtualization over Layer 3，NVO3） 的框架，并定义了参考模型以及设计解决方案所需的逻辑组件。
本备忘录的状态
本文档不是 Internet Standards Track 规范；它是为了信息目的而发布的。
本文档是互联网工程任务组 （Internet Engineering Task Force，IETF） 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已被互联网工程指导组 （Internet Engineering Steering Group，IESG） 批准出版。并非所有 IESG 批准的文件都适用于任何级别的互联网标准；请参阅 RFC 5741 的第 2 节。
有关本文档当前状态、任何勘误以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc7365。
版权声明
版权所有 （c） 2014 IETF Trust 和确定为文档作者的人员。版权所有。
本文档受 BCP 78 和 IETF 信托与 IETF 文档相关的法律规定 （http://trustee.ietf.org/license-info） 的约束，该规定在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。
1、 简介
本文档为数据中心 （DC）在3 层网络虚拟化（NVO3）隧道上的实现提供了框架。该框架旨在帮助标准化协议和机制，以支持数据中心的大规模网络虚拟化。
[RFC7364]问题陈述：网络虚拟化overlay 定义了使用overlay网络构建大型多租户数据中心网络的基本原理。这些大型数据中心经常使用计算、存储和网络虚拟化来支持大量的通信域和终端系统。
本文档提供了数据中心overlay网络的参考模型和功能组件，以及必须解决的技术问题的讨论。
1.1、 一般术语
本文档使用以下术语：
NVO3 网络：使用 NVO3 工作组定义的架构和协议，通过 L3 underlay网络向租户系统提供第 2 层（L2）或第 3 层（L3）服务的overlay网络。
网络虚拟化边缘（Network Virtualization Edge，NVE）：NVE 是位于underlay网络边缘并实现 L2 和/或 L3 网络虚拟化功能的网络实体。NVE 面向网络的一侧使用underlay L3 网络将租户帧隧道传输到其他 NVE 或从其他 NVE 传输。NVE 面向租户的一侧向各个租户系统发送和接收以太网帧。NVE 可以作为虚拟机管理程序、物理交换机或路由器或网络服务设备中的虚拟交换机的一部分来实现，也可以跨多个设备进行拆分。
虚拟网络 （Virtual Network，VN）：VN 是为一组租户系统提供 L2 或 L3 网络服务的物理网络的逻辑抽象。VN 也称为封闭用户组（Closed User Group，CUG）。
虚拟网络实例 （Virtual Network Instance，VNI）：从 NVE 的角度来看的 VN 的特定实例。
虚拟网络上下文（Virtual Network Context，VN 上下文）标识符：overlay封装头中的字段，用于标识数据包所属的特定 VN。出口 NVE 使用 VN 上下文标识符将数据包传送到正确的租户系统。VN 上下文标识符可以是本地有效标识符或全局唯一标识符。
underlay或underlay网络：在 NVE 之间提供连接并且 NVO3 数据包通过隧道传输的网络，其中 NVO3 数据包携带 NVO3 overlay标头，后跟一个租户数据包。underlay网络不需要知道它正在携带 NVO3 数据包。underlay网络上的地址在封装的 NVO3 数据包中显示为“外部地址”。通常，underlay网络可以使用与overlay层完全不同的协议（和地址族）。在 NVO3 的情况下，underlay网络是 IP。
数据中心（Data Center，DC）：包含物理服务器、网络交换机和路由器、网络服务设备和网络存储的物理综合体。数据中心的目的是提供应用程序、计算和/或存储服务。其中一种服务是虚拟化基础设施数据中心服务，也称为“基础设施即服务”。
虚拟数据中心（Virtual DC）：用于虚拟化计算、存储和网络服务的容器。虚拟 DC 与单个租户相关联，并且可以包含多个 VN 和连接到这些 VN 中的一个或多个的租户系统。
虚拟机（Virtual Machine，VM）：运行程序的物理机的软件实现，就像它们在物理、非虚拟化机器上执行一样。应用程序（通常）不知道它们在 VM 上运行，而不是在“裸机”主机或服务器上运行，尽管有些系统提供了半虚拟化环境，允许操作系统或应用程序知道存在用于优化目的的虚拟化。
管理程序（Hypervisor）：运行在服务器上的软件，允许多个虚拟机在同一物理服务器上运行。管理程序管理并提供共享计算、内存和存储服务以及与其托管的 VM 的网络连接。管理程序通常嵌入一个虚拟交换机（见下文）。
服务器（Server）：运行用户应用程序的物理终端主机。独立（或“裸机”）服务器运行托管单租户应用程序的传统操作系统。虚拟化服务器运行支持一个或多个 VM 的管理程序。
虚拟交换机 （Virtual Switch，vSwitch）：管理程序中的一项功能（通常以软件实现），可为物理以太网交换机提供类似的转发服务。vSwitch 在运行在同一台服务器上的 VM 之间或在 VM 和将服务器连接到物理以太网交换机或路由器的物理网络接口卡 （Network Interface Card，NIC） 之间转发以太网帧。vSwitch 还强制执行策略不允许彼此通信的 VM 之间的网络隔离（例如，通过遵守 VLAN）。在主机服务器上启用 NVE 时，可能会绕过 vSwitch。
租户（Tenant）：使用虚拟网络和任何相关资源（例如，计算、存储和网络）的客户。租户可以是企业或企业内的部门/组织。
租户系统（Tenant System）：一种物理或虚拟系统，可以充当主机或转发元素，例如路由器、交换机、防火墙等。它属于单个租户，并连接到该租户的一个或多个 VN。
租户隔离（Tenant Separation）：指隔离不同租户的流量，使得来自一个租户的流量不可见或传递给另一个租户，除非策略允许。租户分离也指地址空间分离，不同租户可以使用相同的地址空间而不会发生冲突。
虚拟接入点 （Virtual Access Points，VAP）：NVE 上的逻辑连接点，用于将租户系统连接到虚拟网络。租户系统通过 VAP 连接到 NVE 处的 VNI。VAP 可以是通过逻辑接口标识符（例如，VLAN ID 或连接到 VM 的内部 vSwitch 接口 ID）标识的物理端口或虚拟端口。
终端设备（End Device）：直接连接到 DC underlay网络的物理设备。这与连接到相应租户 VN 的租户系统形成对比。终端设备由 DC 运营商而非租户管理，是 DC 基础设施的一部分。终端设备可以实现 NVO3 技术以支持 NVO3 功能。终端设备的示例包括主机（例如，服务器或服务器刀片）、存储系统（例如，文件服务器和 iSCSI 存储系统）和网络设备（例如，防火墙、负载平衡器和 IPsec 网关）。
网络虚拟化机构 （Network Virtualization Authority，NVA）：向 NVE 提供可达性和转发信息的实体。
1.2、 DC网络架构
数据中心的通用架构如图 1 所示：
图 1：数据中心的通用架构
图 1 显示了多层 DC 网络架构的示例。它提供了 DC 内部物理组件的视图。
DC网络通常由DC内网络和网络服务、DC间网络和网络连接服务组成。
DC 网络元素可以充当严格的 L2 交换机和/或提供 IP 路由功能，包括网络服务虚拟化。
在某些 DC 架构中，某些层可以提供 L2 和/或 L3 服务。此外，某些层可能会被折叠，互联网连接、DC 间连接和 VPN 支持可能由较少数量的节点处理。然而，人们可以假设 DC 中的网络功能块适合图 1 所示的架构。
DC 中可以存在以下组件：
- 接入交换机：基于硬件的以太网交换机聚合来自机架中终端设备的所有以太网链路，代表主机的物理 DC 网络的入口点。例如，它还可以提供路由功能、虚拟 IP 网络连接或 IP 上的第 2 层隧道。接入交换机通常多宿主到数据中心内网络中的汇聚交换机。接入交换机的典型示例是架顶式 （Top-of-Rack，ToR） 交换机。其他部署场景可能会在 ToR 之前使用中间刀片交换机或行尾 （End-of-Row，EoR） 交换机，以提供与 ToR 类似的功能。
- DC 内网：由大容量核心节点（以太网交换机/路由器）组成的网络。核心节点可以提供虚拟以太网桥接和/或 IP 路由服务。
- DC 网关 （DC GW）：通往外部世界的网关，为 Internet 和 VPN 客户提供 DC 互连和连接。在当前的 DC 网络模型中，这可能只是一个连接到 Internet 的路由器和/或 IP VPN/L2VPN PE。一些网络实现可能将 DC GW 专用于不同的连接类型（例如，一个 DC GW 用于互联网，另一个用于 VPN）。
请注意，终端设备可能是单宿主或多宿主以访问交换机。
2、 参考模型
2.1、 通用参考模型
图 2 描绘了网络虚拟化overlay的 DC 参考模型，其中 NVE 在属于特定 VN 的租户系统之间提供逻辑互连。
图 2：DC 网络虚拟化叠加的通用参考模型
为了获得可达性信息，NVE 可以通过控制平面协议在它们之间直接交换信息。在这种情况下，控制平面模块驻留在每个 NVE 中。
NVE 还可以与外部网络虚拟化机构 （NVA） 通信以获取可达性和转发信息。在这种情况下，NVE 和 NVA 之间使用协议来交换信息。
应该注意的是，NVA 可以在集群中组织以实现冗余和可扩展性，并且可以作为一个逻辑上集中的控制器出现。在这种情况下，需要 NVA 间通信来同步集群内节点之间的状态或跨集群共享信息。同一集群的 NVA 之间交换的信息可能与跨集群交换的信息不同。
租户系统可以通过多种方式连接到 NVE：
- 在本地，通过位于同一终端设备中
- 远程，通过点对点连接或交换网络
当 NVE 与租户系统位于同一地点时，无需协议协助即可确定租户系统的状态。例如，VM 的运行状态可以通过本地 API 进行通信。当 NVE 远程连接到租户系统时，租户系统或 NVE 的状态需要直接或通过管理实体、使用控制平面协议或 API、或直接通过数据平面协议进行交换。
图 2 中的功能组件不一定直接映射到图 1 中描述的物理组件。例如，终端设备可以是带有 VM 和虚拟交换机的服务器刀片。VM 可以是租户系统，NVE 功能可以由主机服务器执行。在这种情况下，租户系统和 NVE 功能位于同一位置。另一个例子是终端设备是租户系统，NVE功能可以通过连接的ToR来实现。在这种情况下，租户系统和 NVE 功能不在同一位置。
underlay节点利用 L3 技术互连 NVE 节点。这些节点基于外部 L3 头信息执行转发，并且通常不维护每个租户服务的状态，尽管某些应用程序（例如，组播）可能需要与租户、租户组有关的控制平面或转发平面信息，租户服务，或属于一个或多个租户的一组服务。可能需要控制underlay中保持的状态量的机制。
2.2、 NVE 参考模型
图 3 描述了 NVE 参考模型。一个或多个 VNI 可以在 NVE 上实例化。租户系统通过 VAP 与相应的 VNI 接口。overlay模块提供隧道overlay功能（例如，租户流量的封装和解封装、租户识别和映射等）。
图 3：通用 NVE 参考模型
请注意，一些 NVE 功能（例如，数据平面和控制平面功能）可能驻留在一个设备中，也可能在不同的设备中单独实现。
2.3、 NVE 服务类型
NVE 为多个租户提供不同类型的虚拟化网络服务，即 L2 服务或 L3 服务。请注意，NVE 可能能够为租户提供 L2 和 L3 服务。本节定义服务类型和相关属性。
2.3.1. L2 NVE 提供以太网类 LAN 服务
L2 NVE 实现以太网 LAN 仿真，这是一种基于以太网的多点服务，类似于 IETF 虚拟专用 LAN 服务 （Virtual Private LAN Service，VPLS） [RFC4761][RFC4762] 或以太网 VPN （Ethernet VPN，EVPN）[EVPN]服务，其中租户系统似乎通过 LAN 互连L3 overlay上的环境。因此，L2 NVE 提供跨underlay的租户媒体访问控制 （Media Access Control，MAC） 帧的每租户虚拟交换实例 （L2 VNI） 和 L3 （IP/MPLS） 隧道封装。请注意，L2 NVE 的控制平面可以在 NVE 本地实现，也可以在单独的控制实体中实现。
2.3.2、 L3 NVE 提供类似 IP/VRF 的服务
从服务定义的角度来看，L3 NVE 提供虚拟化 IP 转发服务，类似于 IETF IP VPN（例如，BGP/MPLS IP VPN [RFC4364]）。也就是说，L3 NVE 提供跨underlay租户 IP 数据包的每租户转发和路由实例 （L3 VNI） 和 L3 （IP/MPLS） 隧道封装。请注意，路由可以在 NVE 本地执行或在单独的控制实体中执行。
2.4、 运营管理注意事项
NVO3 服务是基于 IP underlay的overlay服务。
就 IP underlay而言，使用现有的 IP 操作、管理和维护 （Operations, Administration, and Maintenance，OAM） 设施。
对于 NVO3 overlay，可以提供 L2 和 L3 服务。预计将使用现有的故障和性能 OAM 设施。第 4.1 和 4.2.6 节进一步讨论了要考虑的其他故障和性能管理问题。
就配置而言，DC 环境是由快速提供新服务的需要驱动的，并且通常非常动态，特别是在虚拟化服务的上下文中。因此，自动化 NVO3 服务的配置至关重要。
3、 功能组件
本节将网络虚拟化架构分解为图 3 中描述的功能组件，以便更轻松地讨论这些组件的解决方案选项。
3.1、 服务虚拟化组件
3.1.1、 虚拟接入点 （VAP）
租户系统通过虚拟接入点 （VAP） 连接到 VNI。
VAP 可以是通过逻辑接口标识符（例如，连接到 VM 的 VLAN ID 和内部 vSwitch 接口 ID）标识的物理端口或虚拟端口。
3.1.2、 虚拟网络实例 （VNI）
VNI 是 NVE 上的特定 VN 实例。每个 VNI 定义一个转发上下文，其中包含可达性信息和策略。
3.1.3、 overlay模块和 VN 上下文
需要用于识别每个租户服务的机制，以允许多个租户服务同时overlay在同一underlay L3 网络拓扑上。在数据平面中，每个 NVE 在发送租户数据包时，除了 L3 隧道信息（例如，标识源 NVE 的源 IP 地址和标识源 NVE 的目标 IP 地址之外，还必须能够编码目标 NVE 的 VN 上下文。目的地 NVE 或 MPLS 标签）。这允许目标 NVE 识别租户服务实例，从而适当地处理和转发租户数据包。
overlay模块提供隧道overlay功能：隧道启动/终止，如状态隧道（参见第 3.1.4 节）和/或来自 VAP/L3 underlay的帧的封装/解封装。
在多租户环境中，隧道聚合来自/到不同 VNI 的帧。租户识别和流量解复用基于 VN 上下文标识符。
可以考虑以下方法：
- 每个租户的 VN 上下文标识符：这是一个全局唯一的（在每个 DC 管理域上）VN 标识符，用于标识相应的 VNI。现有技术中此类标识符的示例是 IEEE VLAN ID 和服务实例 ID （I-SID），它们分别在使用 IEEE 802.1Q 和 IEEE 802.1ah 时标识虚拟 L2 域。请注意，多个 VN 标识符可以属于一个租户。
- 每个 VNI 一个 VN 上下文标识符：每个 VNI 值由出口 NVE 或与该 NVE 关联的控制平面自动生成，并且通常由控制平面协议分发给所有相关的 NVE。这种方法的一个例子是在 IP VPN [RFC4364] 中使用 per-VRF MPLS 标签。因此，VNI 值对于出口 NVE 是本地重要的。
- 每个 VAP 一个 VN 上下文标识符：对 NVE 本地重要的值被分配并通常由控制平面协议分发以标识 VAP。这种方法的一个例子是在 IP VPN [RFC4364] 中使用 per-CE MPLS 标签。
请注意，当每个 VNI 或每个 VAP 使用一个 VN 上下文时，控制平面可以使用额外的全局标识符（例如，VN 标识符或名称）来标识租户上下文。
3.1.4、 隧道overlay和封装选项
一旦将 VN 上下文标识符添加到帧中，就会使用 L3 隧道封装将帧传输到目标 NVE。
可以使用不同的 IP 隧道选项（例如，通用路由封装（Generic Routing Encapsulation，GRE）、2 层隧道协议 （Layer 2 Tunneling Protocol，L2TP） 和 IPsec）和 MPLS 隧道。隧道可以是无状态的或有状态的。无状态隧道仅需要将租户数据包与另一个报头封装，以便通过underlay转发数据包（例如，IP underlay上的 IP 隧道）。另一方面，有状态隧道需要在隧道端点（即 NVE）维护隧道状态。然后，入口 NVE 上的租户数据包可以通过这样的隧道传输到目的地（出口）NVE，方法是使用相应的隧道报头封装数据包。端点处的隧道状态可以被配置或动态建立。解决方案应指定使用的隧道技术以及它是有状态的还是无状态的。然而，在本文档中，隧道和隧道封装可互换使用，仅表示租户数据包与隧道报头的封装，以便在入口 NVE 和出口 NVE 之间跨underlay承载数据包。应该注意的是，有状态隧道，尤其是在涉及配置时，确实会带来管理开销和规模限制。当需要保密时，可以使用机会安全 [OPPSEC] 作为无状态隧道解决方案。
3.1.5、 控制平面组件
3.1.5.1、 分布式与集中式控制平面
控制和管理平面实体可以是集中式或分布式的。这两种方法过去都被广泛使用。Internet 的路由模型是分布式方法的一个很好的例子。传输网络通常使用集中式方法来管理传输路径。
也可以结合这两种方法，即使用混合模型。网络状态的全局视图有很多好处，但并不排除在网络内使用分布式协议。集中式模型提供了一种工具来维护全局状态并将该状态分发到网络。当与分布式协议结合使用时，可以实现更高的网络效率、更高的可靠性和健壮性。特定于域和/或部署的约束定义了集中式和分布式方法之间的平衡。
3.1.5.2、 自动配置和服务发现
NVE 必须能够为每个租户系统识别适当的 VNI。这是基于通常由外部实体提供的状态信息。例如，在 VM 是租户系统的环境中，此信息由 VM 编排系统提供，因为这些是唯一可以了解哪个 VM 属于哪个租户的实体。
需要一种将此信息传达给 NVE 的机制。必须创建 VAP 并将其映射到适当的 VNI。根据实施情况，可以使用租户系统与其本地 NVE 之间的自动发现协议或通过管理实体来实施此控制接口。在任何一种情况下，都需要适当的安全和身份验证机制来验证租户系统信息没有被欺骗或更改。这是在系统中提供完整性和租户隔离的一个关键方面。
NVE 可以通过在 NVE 之间交换此类信息的控制协议或通过管理控制实体了解其他 NVE 上 VNI 的可达性信息。
3.1.5.3、 地址通告和隧道映射
当流量到达 VAP 上的入口 NVE 时，将执行查找以确定数据包需要发送到哪个 NVE 或本地 VAP。如果该数据包要发送到另一个 NVE，则该数据包将使用包含出口 NVE 的目标信息（目标 IP 地址或 MPLS 标签）的隧道头进行封装。中间节点（在入口和出口 NVE 之间）根据隧道目的地信息交换或路由流量。
上述过程中的一个关键步骤包括识别数据包要通过隧道传送到的目的地 NVE。NVE 负责维护一组转发或映射表，其中包含目标 VM 和出口 NVE 地址之间的绑定。填充这些表的几种方法是可能的：控制平面驱动、管理平面驱动或数据平面驱动。
当使用控制平面协议来分发地址可达性和隧道信息时，自动提供和服务发现可以由同一协议完成。在这种情况下，自动供应和服务发现可以与（从）地址通告和相关隧道映射相结合（推断出）。此外，同时携带 MAC 和 IP 地址的控制平面协议消除了对地址解析协议 （Address Resolution Protocol，ARP） 的需求，因此解决了 [RFC6820] 中讨论的爆炸性 ARP 处理问题之一。
3.1.5.4.叠加隧道
对于overlay隧道，根据用于封装租户系统数据包的隧道技术，在隧道封装报头的源和目标字段中分配和使用一个或多个本地 NVE 地址可能就足够了。作为隧道封装报头一部分的其他信息可能也需要配置。在某些情况下，本地 NVE 配置可能就足够了，而在其他情况下，一些隧道相关的信息可能需要在 NVE 之间共享。需要共享的信息将取决于技术。例如，潜在信息可以包括隧道标识、封装类型和/或隧道资源。在某些情况下，例如在underlay使用 IP 组播时，可能需要建立互连 NVE 的隧道。当需要在 NVE 之间交换或共享隧道信息时，可能需要控制平面协议。例如，可能需要提供 NVE 之间的活动/备用状态信息、上/下状态信息、组播隧道的修剪/嫁接信息等。
此外，某些隧道技术可能需要控制平面来建立隧道路径。这适用于单播和组播隧道。
3.2、 多宿主
多宿主技术可用于提高 NVO3 网络的可靠性。确保考虑到 NVO3 网络中的物理多样性以避免单点故障也很重要。
可以在各种节点中启用多宿主，从租户系统到 ToR，从 ToR 到核心交换机/路由器，以及从核心节点到 DC GW。
NVO3 underlay节点（即从 NVE 到 DC GW）依靠 IP 路由技术或 MPLS 重新路由功能作为在发生故障时重新路由流量的手段。
当租户系统与 NVE 位于同一位置时，租户系统通过虚拟端口有效地单宿主到 NVE。当Tenant System和NVE分离时，Tenant System通过VLAN等逻辑L2结构连接到NVE，可以多宿主到各种NVE。NVE 可以向端系统提供 L2 服务或 L3 服务。NVE 可以多宿主到 DC 中 L2 或 L3 的下一层。当 NVE 提供 L2 服务且未与端系统位于同一位置时，必须使用环路避免技术。同样，当NVE提供L3服务时，可以使用类似的双归技术。当NVE向端系统提供L3服务时，端系统和NVE之间可能没有启用动态路由协议。终端系统可以通过多个接口多宿主到多个物理分离的 L3 NVE。当连接到 NVE 的链路之一出现故障时，其他接口可用于到达终端系统。
来自 DC 的外部连接可由两个或多个 DC 网关处理。每个网关都提供对外部网络（例如 VPN 或 Internet）的访问。网关可以连接到外部网络中的两个或多个边缘节点以实现冗余。当与上游节点的连接丢失时，使用替代连接，并撤消失败的路由。
3.3、 虚拟机迁移
在使用 VM 技术的 DC 环境中，一个重要特性是 VM 可以以无缝方式从一台服务器迁移到同一或不同 L2 物理域（在 DC 内或跨 DC）中的另一台服务器。
VM 可以在停止或挂起状态（“冷”VM 迁移）或运行/活动状态（“热”VM 迁移）下从一台服务器迁移到另一台服务器。对于“热”迁移，需要保留 VM L2 和 L3 地址。对于“冷”迁移，可能需要至少保留 VM L3 地址。
在“热”迁移的情况下，需要在迁移 VM 时保持连接的解决方案。这意味着保留了 VM 之间的连接。例如，对于 L2 VN，ARP 缓存会相应地更新。
在 VM 迁移时，必须维护定义 VM 之间连接的 NVE 策略。
在 VM 迁移期间，预计到 VM 默认网关的路径可以确保 VM 应用程序有足够的 QoS，即 QoS 与这些应用程序的预期服务级别协议相匹配。
4、 overlay网络的关键方面
本节的目的是强调建议的overlay解决方案需要解决的具体问题。
4.1、 利弊
overlay网络是物理网络之上的一层虚拟网络拓扑。
overlay网络具有以下主要优势：
在网络边缘（在 NVE）处理单播隧道状态管理和租户系统可达性的关联。中间传输节点不知道这种状态。请注意，当在underlay网络中启用组播为租户 VN 构建组播树时，underlay核心网络中将有更多与租户相关的状态。
隧道用于聚合流量并从underlay网络隐藏租户地址，因此提供了最小化underlay网络内所需的转发状态量的优势。
将 VM 使用的overlay地址（MAC 和 IP）与underlay网络解耦提供租户分离以及租户地址空间与underlay地址空间的分离。
overlay网络支持大量虚拟网络标识符。
overlay网络也带来了一些挑战：
overlay网络通常无法控制underlay网络并且缺乏underlay网络信息（例如，underlay利用率）：
*overlay网络和/或其关联的管理实体通常会探测网络以测量链路或路径属性，例如可用带宽或丢包率。很难准确评估网络属性。underlay网络最好公开使用和性能信息。
*overlay网络和underlay网络之间的错误通信或缺乏协调会导致网络资源的低效使用。
*当多个叠加共存于一个公共underlay网络之上时，叠加之间缺乏协调会导致性能问题和/或资源使用效率低下。
通过overlay层传输的流量可能无法穿越防火墙和 NAT 设备。
组播服务可扩展性：在underlay网络中可能需要组播支持以解决租户泛洪控制或有效的组播处理。underlay可能还需要在每个租户的基础上或什至在给定租户的每个单独的组播流上维护组播状态。NVE 的入口复制消除了underlay核心中的额外组播状态，但根据组播流量，它可能会导致带宽使用效率低下。
4.2、 要考虑的叠加问题
4.2.1、 数据平面与控制平面驱动
在 L2 NVE 的情况下，可以针对 VAP 动态学习 MAC 地址。此类地址也可能通过 L2 NVE 和 L3 NVE 的管理或控制协议获知和控制。动态数据平面学习意味着支持未知目的地的泛洪，因此意味着支持广播和/或组播或使用入口复制，如第 4.2.3 节所述。用于动态学习的underlay网络中的组播可能会导致显着的可扩展性限制。必须强制执行特定的转发规则以防止发生循环。这可以使用生成树、最短路径树或水平分割网格来实现。
需要注意的是，要分配的状态量取决于网络拓扑和虚拟机的数量。还可以利用不同形式的缓存来最小化各种元素之间的状态分布。控制平面不应要求 NVE 来维护其 VN 不在 NVE 上的所有租户系统的位置。使用控制平面并不意味着 NVE 上的数据平面必须保持控制平面中的所有转发状态。
4.2.2、 数据平面和控制平面之间的协调
对于 L2 NVE，NVE 需要能够确定通过 VAP 连接的租户系统的 MAC 地址。这可以通过数据平面学习或控制平面来实现。对于 L3 NVE，NVE 需要能够确定通过 VAP 连接的租户系统的 IP 地址。
在这两种情况下，都需要与 NVE 控制协议进行协调，以便当 NVE 确定 VAP 后面的地址集已更改时，它会触发 NVE 控制平面将此信息分发给其对等方。
4.2.3、 处理广播、未知单播和组播流量
有多种选项可以支持广播、未知单播和组播（Broadcast, Unknown Unicast, and Multicast，BUM）所需的数据包复制。典型的方法包括：
- 入口复制
- 使用underlay组播树
这两种方法之间存在带宽与状态的权衡。根据所需的复制程度（即每组主机的数量）和要维护的组播状态量，应考虑为状态交易带宽。
当每组的主机数量很大时，使用underlay组播树可能更合适。当主机数量较少（例如 2-3 台）和/或组播流量较小时，入口复制可能不是问题。
根据数据中心网络的规模以及 （S,G） 条目的数量以及组播流的持续时间，underlay组播树的使用可能是一个挑战。
当流众所周知时，可以预先提供这样的组播树。但是，通常很难提前预测应用程序流；因此，对短期流的 （S,G） 条目进行编程可能是不切实际的。
一种可能的权衡是在underlay共享组播树中使用，而不是专用组播树。
4.2.4、 路径 MTU
使用overlay隧道时，会将外部报头添加到原始帧中。这可能会导致超出通往出口隧道端点的路径的 MTU。
出于性能原因，通常不希望依赖 IP 分段。理想情况下，租户系统所看到的接口 MTU 被调整为不需要碎片。
MTU 可以手动配置或动态发现。存在各种路径 MTU 发现技术，以确定要使用的正确 MTU 大小：
- 基于经典 ICMP 的路径 MTU 发现 [RFC1191] [RFC1981]
租户系统依靠 ICMP 消息来发现到其目的地的端到端路径的 MTU。这种方法并不总是可行的，例如在遍历出于安全原因禁用 ICMP 的中间件（例如防火墙）时。
- 扩展路径 MTU 发现技术，例如 [RFC4821] 中定义的那些技术
租户系统发送不同大小的探测数据包，并依靠接收方对接收或未接收的确认来允许发送方发现端到端路径的 MTU。
虽然也可以依靠 NVE 来执行分段和重组操作，而无需依靠租户系统来了解端到端的 MTU，但这会导致不希望的性能和拥塞问题，并显着增加复杂性缓冲和重组逻辑所需的硬件 NVE。
优选地，underlay网络的设计方式应使 MTU 可以容纳额外的隧道和可能的额外 NVO3 报头封装开销。
4.2.5、 NVE 位置权衡
在 DC 流量的情况下，源自 VM 的流量是本地以太网流量。此流量可以由本地虚拟交换机或 ToR 交换机交换，然后由 DC 网关交换。NVE 功能可以嵌入到这些元素中的任何一个中。
在决定 NVE 功能应该发生的位置时，有几个标准需要考虑：
- 处理和内存要求
*数据路径（例如，查找、过滤和封装/解封装）
*控制平面处理（例如，路由、信令和 OAM）以及应启用特定控制平面功能的位置
- FIB/RIB 尺寸
- 组播支持
*路由/信令协议
*数据包复制能力
*组播FIB
- 碎片化支持
- QoS 支持（例如，标记、监管和排队）
- 弹性
4.2.6、 网络overlay和underlay之间的交互
当多个overlay在公共underlay网络之上共存时，应提供资源（例如带宽）以确保可以容纳来自overlay的流量并满足 QoS 目标。叠加层可以有部分重叠的路径（节点和链接）。
每个叠加层本质上都是自私的。它发送流量以优化自身性能而不考虑对其他overlay的影响，除非underlay路径是基于每个overlay进行流量设计以避免underlay资源拥塞。
通过提供机制在underlay和overlay层之间交换性能和活跃度信息或通过协调系统使用此类信息，可以实现overlay层和underlay之间更好的可见性，或在underlay网络上放置overlay需求的一般协调.此类信息可能包括：
- 性能指标（吞吐量、延迟、丢失、抖动），如在 [RFC3148]、[RFC2679]、[RFC2680] 和 [RFC3393] 中定义。
- 成本指标
5、 安全考虑
在考虑 NVO3 的安全性时，有三个观点。首先，服务提供商通过 NVO3 技术向租户提供的服务必须满足双方同意的安全要求。其次，实施 NVO3 的网络必须能够信任与从租户接收的数据包相关联的虚拟网络身份。第三，NVO3 网络必须考虑与在underlay网络中作为overlay层运行相关的安全性。
为了满足租户的安全要求，NVO3 服务必须将来自租户的数据包传送到overlay网络和外部网络中指定的目的地。NVO3 服务通过数据分离提供数据机密性。NVE 同时使用 VNI 和租户流量隧道可确保 NVO3 数据保存在单独的上下文中，从而与其他租户流量分开。支持 NVO3 服务的基础设施（例如，管理系统、NVE、NVA 和中间underlay网络）应仅限于授权访问，以便可以预期数据完整性。如果租户要求其数据保密，那么租户系统可能会选择在将其数据传输到 NVO3 服务之前对其进行加密。
NVO3 服务必须能够验证从租户收到的数据包上收到的 VNI。为确保这一点，不仅租户数据而且 NVO3 控制数据都必须受到保护（例如，控制 NVA 和 NVE 之间、NVA 之间以及 NVE 之间的流量）。由于 NVE 和 NVA 在 NVO3 中发挥着核心作用，因此确保对 NVE 和 NVA 的安全访问是至关重要的，以免未经授权的访问成为可能。如第 3.1.5.2 节所述，租户系统的识别基于通常由管理系统（例如，虚拟化环境中的 VM 编排系统）提供的状态。还必须确保对此类管理系统的安全访问。当 NVE 从租户系统接收数据时，需要验证租户身份，以保证其有权访问相应的 VN。在某些情况下，这可以通过识别针对特定 VAP 的传入数据包来实现。在其他情况下，可能需要进行身份验证。完成此验证后，将允许数据包进入 NVO3 overlay，并且不会对overlay数据包封装（例如，VNI、目标 NVE 等）提供完整性保护。
由于 NVO3 服务可以跨不同的underlay网络运行，因此当underlay网络至少不能提供数据完整性时，需要进行数据加密以确保正确的数据包传送。
还需要限制可在 NVO3 服务和underlay网络之间交换的信息类型（例如，第 4.2.6 节中讨论的拓扑信息），基于它们商定的安全要求。
6、 参考资料
[EVPN] Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN", Work in Progress, draft-ietf-l2vpn-evpn-10, October 2014. [OPPSEC] Dukhovni, V. "Opportunistic Security: Some Protection Most of the Time", Work in Progress, draft-dukhovni-opportunistic-security-04, August 2014. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990, <http://www.rfc-editor.org/info/rfc1191>. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996, <http://www.rfc-editor.org/info/rfc1981>. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999, <http://www.rfc-editor.org/info/rfc2679>. [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999, <http://www.rfc-editor.org/info/rfc2680>. [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 2001, <http://www.rfc-editor.org/info/rfc3148>. [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics （IPPM）", RFC 3393, November 2002, <http://www.rfc-editor.org/info/rfc3393>. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks （VPNs）", RFC 4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>. [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service （VPLS） Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007, <http://www.rfc-editor.org/info/rfc4761>. [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service （VPLS） Using Label Distribution Protocol （LDP） Signaling", RFC 4762, January 2007, <http://www.rfc-editor.org/info/rfc4762>. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>. [RFC6820] Narten, T., Karir, M., and I. Foo, "Address Resolution Problems in Large Data Center Networks", RFC 6820, January 2013, <http://www.rfc-editor.org/info/rfc6820>. [RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L., Kreeger, L., and M. Napierala, "Problem Statement: Overlays for Network Virtualization", RFC 7364, October 2014, <http://www.rfc-editor.org/info/rfc7364>.
致谢
除作者外，以下人员为本文档做出了贡献：Dimitrios Stiliadis、Rotem Salomonovitch、Lucy Yong、Thomas Narten、Larry Kreeger 和 David Black。
