摘要

以太网L2VPN服务的广泛采用和该技术的新应用的出现（例如数据中心互连）导致了新的要求集，而当前的虚拟专用局域网服务（Virtual Private LAN Service，VPLS）解决方案无法轻松解决这些要求。特别是，不支持具有全活转发的多宿主，并且还没有现有的解决方案可以利用多点到多点（Multipoint-to-Multipoint，MP2MP）标签交换路径（Label Switched Paths，LSP）来优化多目标帧的传递。此外，即使在基于BGP的自动发现的情况下，VPLS的配置也要求网络运营商在访问配置之上指定各种网络参数。本文档指定了解决上述问题的以太网VPN（Ethernet VPN，EVPN）解决方案的要求。

该备忘录的状态

本文档不是Internet Standards Track规范，它被发布仅供参考。

本文档是Internet工程任务组（Internet Engineering Task Force，IETF）的产品，它代表了IETF社区的共识。它已获得公众审查，并已由Internet工程指导小组（Internet Engineering Steering Group，IESG）批准发布。并非所有IESG批准的文件都可以成为任何级别的Internet标准的候选人；请参阅[RFC 5741-RFC Streams, Headers, and Boilerplates]的第2节。

有关本文档当前状态，任何勘误以及如何提供反馈的信息，请访问。

1、简介

[RFC4664- Framework for Layer 2 Virtual Private Networks (L2VPNs)]，[RFC4761- Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling]和[RFC4762- Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling]中定义的虚拟专用局域网服务（VPLS）是一种经过验证且广泛部署的技术。但是，现有解决方案在冗余性、多播优化和配置简便性方面有许多限制。此外，新的应用程序正在推动其他L2VPN服务的一些新要求，例如以太网树（Ethernet Tree，E-Tree）和虚拟专线服务（Virtual Private Wire Service，VPWS）。

在多宿主方面，例如，如[VPLS-BGP-MH]中所述，当前的VPLS仅支持单活冗余模式（在第3节中定义）的多宿主。当前的VPLS解决方案不支持具有全活冗余模式（在第3节中定义）的灵活多宿主。

在组播优化领域，[RFC7117-Multicast in Virtual Private LAN Service (VPLS)]描述了如何将组播LSP与VPLS结合使用。但是，此解决方案仅限于点对多点（Point-to-Multipoint，P2MP）LSP，因为还没有使用VPLS来利用多点对多点（MP2MP）LSP的已定义解决方案。

在配置简化方面，当前的VPLS确实通过依赖基于BGP的服务自动发现[RFC4761] [RFC6074-Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)]提供了一种单面配置机制。但是，这仍然需要操作员在访问侧以太网配置的基础上配置许多网络侧参数。

在数据中心互连领域，应用程序推动了对新服务接口类型的需求，这些服务接口类型是VLAN捆绑和基于VLAN的服务接口的混合组合。这些被称为“VLAN感知绑定”的服务接口。

虚拟化应用程序也推动了网络要处理的MAC（Media Access Control，介质访问控制）地址数量的增加。这就提出了使网络在发生故障时重新收敛的要求与服务商边缘设备（Provider Edge，PE）获知的MAC地址的数量无关。需要最小化多目标框架的泛洪量并将泛洪局限在给定站点的范围内。

除了VPLS和分层VPLS（Hierarchical VPLS，H-VPLS）当前涵盖的内容以外，还需要支持灵活的VPN拓扑和策略。

本文档的重点是定义新解决方案的要求，即解决上述问题的以太网VPN（EVPN）。

第4节讨论了冗余要求，第5节介绍了组播优化要求，第6节明确规定了配置要求的难易程度，第7节重点介绍新的服务接口要求，第8节重点介绍了快速收敛的要求，第9节描述了泛洪抑制要求，最后第10节讨论了支持灵活VPN拓扑和策略的要求。

2、要求说明

本文档中的关键字“必须”，“不得”，“必须”，“应”，“应禁止”，“应”，“不应”，“建议”，“可以”和“可选”是如[RFC2119-Key words for use in RFCs to Indicate Requirement Levels]中所述进行解释。

本文档不是协议规范，并且本文档中的关键字用于阐明和强调需求语言。

3、术语

AS：Autonomous System，自治系统

CE：Customer Edge，客户侧边缘设备

E-Tree: Ethernet Tree，以太网树

MAC地址：Media Access Control address，介质访问控制地址，也称为MAC

LSP：Label Switched Path，标签交换路径

PE：Provider Edge，服务提供商边缘设备

MP2MP：Multipoint to Multipoint，多点到多点

VPLS：Virtual Private LAN Service，虚拟专用局域网服务

单活冗余模式：当一台设备或一个网络被多宿主到两个或多个PE的组中，并且当该冗余组中只有一个PE可以向/从给定VLAN的多宿主设备或网络转发流量时，例如多宿主称为“单活”。

全活冗余模式：将一台设备多宿主到两个或多个PE的组中，并且当该冗余组中的所有PE可以向/从给定VLAN的多宿主设备或网络转发通信时，这种多宿主称为“全活”。

4、冗余要求4.1、基于流的负载平衡

用于将CE节点多宿主到一组PE节点的常见机制涉及利用基于[802.1AX]的多机箱以太网链路聚合组（link aggregation groups，LAG）。[PWE3-ICCP]描述了一种这样的方案。在以太网链路聚合中，CE通过负载均衡算法在连接到PE的连接电路上分配流量的方法非常灵活。唯一的要求是该算法确保给定流量的有序逐帧传递。在典型的实现中，这些算法涉及基于散列函数在捆绑中选择出站链接，该散列函数基于以下一个或多个字段来标识流：

i. 第2层：源MAC地址，目的MAC地址，VLAN

ii. 第3层：源IP地址，目的IP地址

iii. 第4层：UDP或TCP源端口，目的端口

这里要注意的关键点是[802.1AX]没有为以太网束定义标准的负载平衡算法，因此，不同的实现方式会有不同的动作。实际上，即使在链路上存在非对称负载平衡的情况下，绑定也可以正常运行。在这种情况下，全主动多宿主的第一个要求是能够容纳来自基于L2、L3和/或L4标头字段的来自CE节点的基于流的灵活负载平衡的能力。

（R1a）解决方案必须能够如上所述支持来自CE的灵活的基于流量的负载平衡。

（R1b）即使CE连接到多个PE上，解决方案也必须能够支持针对CE的流量的基于流的负载平衡。因此，该解决方案必须能够使用连接到CE的多个链路，而不用考虑CE连接到的PE的数量。

应该注意的是，当一个CE多宿主到多个PE时，从每个远程PE到每个多宿主PE可能会有多个等价多径（Equal-Cost Multipath，ECMP）路径。此外，对于全活动多宿主CE，远程PE可以选择任何多宿主PE来发送发往多宿主CE的流量。因此，当一个解决方案支持全活多宿主时，它必须为目的地为多宿主CE的流量使用尽可能多的这些路径。

（R1c）解决方案应该支持PE之间的基于流的负载平衡，而这些PE是跨越多个自治系统的冗余组的成员。

4.2、基于流的多路径

满足第4.1节中描述的全活冗余模式（例如，基于流的负载平衡）的任何解决方案，也都需要在给定的一对PE之间使用多条路径。例如，如果远程PE和全活动冗余组中的一对PE之间有两个或多个LSP，则该解决方案需要能够按流量针对这些流量在这些LSP之间负载均衡负载到冗余组中的PE。此外，如果远程PE和冗余组中的PE之间有两个或更多ECMP路径，则该解决方案需要利用所有等价LSP。对于后者，该解决方案还可以利用基于熵标签[RFC6790-The Use of Entropy Labels in MPLS Forwarding]的负载平衡功能。

（R2a）解决方案必须能够使用全活多宿主在远程PE和冗余组中的所有PE之间使用所有LSP。

（R2b）解决方案必须能够使用全活多宿主在远程PE与冗余组中的任何PE之间行使所有ECMP路径。

例如，考虑一种场景，其中CE1多宿主到PE1和PE2，而CE2多宿主到PE3和PE4，以全活冗余模式运行。此外，请考虑在CE1和CE2的多宿主PE之间存在三个ECMP路径，从CE1到CE2的流量可以通过MPLS / IP核心在12条不同的路径上转发如下：CE1负载均衡到PE1和PE2的流量，PE1和PE2分别具有到PE3和PE4的三个ECMP路径，总共十二个路径。最后，当流量到达PE3和PE4时，它会通过以太网通道（也称为链路绑定）转发到CE2。

值得指出的是，基于流的多路径完善了上一节中描述的基于流的负载平衡。

4.3、地理冗余PE节点

提供到CE或接入网络的多宿主连接的PE节点可以位于同一物理位置（位于同一位置），也可以不在同一物理位置（例如，在不同的中心局（Central Offices，CO）或接入点（Points of Presence，POP）中）。提供地理冗余解决方案时需要后者，以确保在断电，自然灾害等情况下关键应用程序的业务连续性。全活多宿主机制需要同时支持同一地点和异地冗余部署PE。从成本的角度来看，后一种情况通常意味着，对于多宿主机制的操作，在PE之间需要专用的线路而不是主要考虑成本原因。此外，在双归属设置中从远程PE到一对PE的IGP成本不能假定是相同的，因为后者的PE是地理冗余的。

（R3a）解决方案必须支持全活多宿主，而无需在多宿主组中的PE之间建立专用的控制/数据链路。

（R3b）解决方案必须支持从远程PE到多宿主组中的每个PE的不同IGP成本。

（R3c）解决方案必须支持同一自治系统中不同IGP域之间的多宿主。

（R3d）解决方案应支持跨多个自治系统的多宿主。

4.4、最佳流量转发

在典型的网络中，当考虑一对指定的PE时，通常会发现连接到这些PE的单宿主CE和多宿主CE。

（R4）全活动的多宿主解决方案应支持以下所有方案的单播流量最佳转发。所谓“最佳转发”，是指除非目的地CE连接到多宿主PE之一，否则不会在属于多宿主组的PE设备之间转发流量。

i. 单宿主CE到多宿主CE

ii. 多宿主CE到单宿主CE

iii. 多宿主CE到多宿主CE

对于地理冗余的PE来说，将流量从同一多宿主组中的一个PE转发到另一个PE会引入额外的延迟，而在PE节点和核心节点的交换容量使用效率低下，需要着重考虑。多宿主组（也称为跨设备链路聚合）是一组支持多宿主CE的PE。

4.5、支持灵活的冗余分组

（R5）为了支持灵活的冗余分组，多宿主机制应该允许将PE节点任意分组为冗余组，其中每个冗余组代表共享同一PE组的所有多宿主设备/网络。

最好用一个示例来解释：假设有三个PE节点，PE1、PE2和PE3，多宿主机制必须允许指定的PE（例如PE1）同时成为多个冗余组的一部分。例如，可以有一个组（PE1，PE2），一个组（PE1，PE3）和另一个组（PE2，PE3），其中CE可以多宿主到这三个冗余组中的任何一个。

4.6、多宿主网络

有些应用需要将以太网而不是单个设备多宿主到一组PE。以太网通常会运行弹性机制，例如多生成树协议（Multiple Spanning Tree Protocol）[802.1Q]或以太网环保护交换（Ethernet Ring Protection Switching）[G.8032]。PE可能会也可能不会参与以太网网络的控制协议。对于运行[802.1Q]或[G.8032]的多宿主网络，这些协议要求每个VLAN仅在多宿主链路之一上处于活动状态。

（R6a）解决方案必须以单活冗余模式支持多宿主网络连接，其中所有VLAN在一个PE上均处于活动状态。

（R6b）解决方案还必须支持具有单活冗余模式的多宿主网络，其中不相交的VLAN集在不同的PE上处于活动状态。

（R6c）解决方案应该支持PE之间的单活冗余模式，PE是跨越多个AS的冗余组的成员。

（R6d）解决方案可以通过基于MAC的负载平衡为多宿主网络支持全活动冗余模式（即，通过不同的PE可以访问VLAN上的不同MAC地址）。

5、组播优化要求

在某些环境中，可能需要使用MP2MP LSP来优化多播，广播和未知单播流量，以减少核心路由器中的多播状态数量。[RFC7117]禁止使用MP2MP LSP，因为当前的VPLS解决方案需要出口PE在通过LSP接收到未知单播数据包时执行学习。使用MP2MP LSP时，这是具有挑战性的，因为它们不具有识别发送者的固有机制，如果不再需要标识用于执行学习的发送方，则可以轻松地将MP2MP LSP用于多播优化。

（R7a）解决方案必须能够提供一种机制，当通过MP2MP LSP接收到数据包时，不需要针对MPLS LSP进行MAC学习。

（R7b）解决方案应该能够提供使用MP2MP LSP的过程，以优化多播，广播和未知单播流量的传递。

6、易于配置的要求

随着L2VPN技术扩展到企业部署中，易于配置变得至关重要。即使当前的VPLS具有自动发现机制，该机制可以通过MPLS / IP核心网络自动发现属于给定VPN实例的成员PE，但仍需要进一步简化，如下所述：

（R8a）解决方案务必支持MPLS / IP核心网上的VPN成员PE的自动发现，类似于[RFC4761]和[RFC6074]中描述的VPLS自动发现机制。

（R8b）解决方案应支持自动发现属于给定冗余或多宿主组的PE。

（R8c）解决方案应该支持多宿主设备或网络的站点ID的自动感知，并支持基于站点ID的冗余组ID的自动生成。

（R8d）解决方案应支持参与冗余（多宿主）组的PE之间的自动指定转发器（Designated Forwarder，DF）选举，并能够在冗余组的成员PE之间划分服务实例（例如VLAN）。

（R8e）对于VLAN标识符在MPLS网络中是全局的部署（即网络服务最多限制为4K），PE设备应从VLAN标识符派生MPLS特定的属性（例如，VPN ID，BGP路由目标等）。这样，对于网络运营商来说，为接入电路配置VLAN标识符就足够了，并且在核心网络上建立服务所需的所有MPLS和BGP参数将自动获得，而无需进行显式配置。

（R8f）实现应恢复为对没有配置新值的参数使用默认值。

7、新服务接口要求

[MEF]和[802.1Q]指定了以下服务：

-端口模式：在此模式下，端口上的所有流量都映射到单个网桥域和单个对应的L2VPN服务实例，客户VLAN透明性是端到端的保证。

-VLAN模式：在此模式下，端口上的每个VLAN都映射到唯一的网桥域和相应的L2VPN服务实例。此模式允许通过端口进行服务多路复用，并支持可选的VLAN转换。

-VLAN捆绑：在此模式下，端口上的一组VLAN共同映射到唯一的网桥域和相应的L2VPN服务实例。客户MAC地址在映射到同一服务实例的所有VLAN上必须唯一。

对于上述每个服务，在支持关联服务的PE上为每个服务实例分配一个桥域。例如，在端口模式下，将为属于该服务实例的所有端口分配一个网桥域，而不管通过这些端口的VLAN数量如何。

值得注意的是，如上所使用的术语“桥接域”是指在IEEE桥接模型中定义的MAC转发表，并不表示或暗示任何特定的实现。

[RFC4762]基于“离散和集中学习”定义了两种类型的VPLS服务，它们分别分别映射到端口模式和VLAN模式。

（R9a）解决方案必须支持以上三种服务类型（端口模式，VLAN模式和VLAN捆绑）。

对于用于数据中心互连的托管应用程序，网络运营商要求能够使用单个L2VPN实例在WAN上扩展以太网VLAN，同时保持与该实例关联的各个VLAN之间的数据平面分隔。这称为“支持VLAN的捆绑服务”。

（R9b）解决方案可以支持支持VLAN的捆绑服务。

这产生了两种新的服务接口类型：不带转换的可识别VLAN的绑定和带转换的可识别VLAN的绑定。

无需转换即可识别VLAN的捆绑服务接口具有以下特征：

-服务接口可将客户VLAN捆绑到单个L2VPN服务实例中。

-服务接口可确保客户VLAN端到端的透明性。

-服务接口可维护客户VLAN之间的数据平面分隔（即，为每个VLAN创建专用的网桥域）。

在多对一捆绑的特殊情况下，服务接口不得假定客户VLAN具有任何先验知识。换句话说，不应在PE上配置客户VLAN；相反，接口的配置应该像基于端口的服务一样。

具有识别功能的VLAN绑定的服务接口具有以下特征：

-服务接口可将客户VLAN捆绑到单个L2VPN服务实例中。

-服务接口可维护客户VLAN之间的数据平面分隔（即为每个VLAN创建专用的网桥域）。

-服务接口支持客户VLAN ID转换，以处理在不同接口上使用不同VLAN标识符（VID）来指定相同客户VLAN的情况。

这些新服务类型与先前定义的三种类型之间在服务提供商资源分配方面的主要区别在于，新服务需要为每个L2VPN服务实例分配多个网桥域（每个客户VLAN一个）。每个L2VPN服务实例的单个网桥域。

8、快速收敛

（R10a）对于多宿主设备和多宿主网络，解决方案必须提供从PE-CE连接电路故障以及PE节点故障中恢复的能力。

（R10b）恢复机制必须提供收敛时间，该收敛时间与PE获知的MAC地址数量无关。这在虚拟化应用程序的环境中尤为重要，因为虚拟化应用程序推动了第2层网络要处理的MAC地址数量的增加。

（R10c）此外，恢复机制应提供收敛时间，该收敛时间应与绑定在电路或PE关联的服务实例的数量无关。

9、泛洪抑制

（R11a）该解决方案应允许网络运营商选择是丢弃未知的单播帧还是对其进行泛洪。此属性需要基于每个服务实例进行配置。

（R11b）此外，对于将解决方案用于数据中心互连的情况，解决方案应将给定站点范围之外的广播帧泛洪降至最低。特别需要注意的是的是周期性的地址解析协议（ARP）流量。

（R11c）此外，该解决方案应消除拓扑更改时任何不必要的单播流量泛洪，尤其是在多宿主站点的情况下，其中PE对给定的MAC地址具有备份路径的先验知识。

10、支持灵活的VPN拓扑和策略

（R12a）解决方案必须能够支持不受该解决方案基础机制约束的灵活VPN拓扑。

一个示例是E-Tree拓扑，其中VPN中的一个或多个站点是根站点，其他站点是叶子站点。允许根将流量发送到其他根和叶，而叶只能与根进行通信。解决方案必须提供支持E-Tree拓扑的能力。

（R12b）该解决方案可以提供在MAC地址的粒度上应用策略的能力，以控制VPN中的哪些PE获知哪个MAC地址以及如何转发特定的MAC地址。应该可以应用策略，以仅允许VPN中的某些成员PE发送或接收特定MAC地址的流量。

（R12c）解决方案必须能够支持[RFC4364-BGP/MPLS IP Virtual Private Networks (VPNs)]中所述的AS间option-C和AS间option-B两种情况。

11、安全注意事项

为EVPN解决方案开发的任何协议扩展都应包括适当的安全性分析。除了在数据平面中执行MAC学习时[RFC4761]和[RFC4762]中涵盖的安全要求，以及在控制平面中进行MAC学习时[RFC4364]中涵盖的安全要求之外，还需要满足以下附加要求。

（R13）解决方案必须能够检测并正确处理同一MAC地址出现在两个不同以太网段后面（无论是无意还是恶意）的情况。

（R14）解决方案必须能够将MAC地址与特定的以太网段（也称为“粘性MAC”）相关联，以帮助限制针对该MAC地址进入网络的恶意流量。此功能可能会限制欺骗性MAC地址在网络上的出现。启用此功能后，将禁止此类粘性MAC地址的MAC移动性，并且必须丢弃来自任何其他以太网网段的此类MAC地址的流量。

12、规范性引用

[802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", Std. 802.1AX-2008, IEEE Computer Society, November 2008.

[802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks", Std. 802.1Q-2011, 2011.

[G.8032] ITU-T, "Ethernet ring protection switching", ITU-T Recommendation G.8032, February 2012.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4364] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method", RFC 4764, January 2007.

[RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.

[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007.

[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011.

13、信息性参考

[VPLS-BGP-MH]

Kothari, B., Kompella, K., Henderickx, W., Balue, F., Uttaro, J., Palislamovic, S., and W. Lin, "BGP based Multi-homing in Virtual Private LAN Service", Work in Progress, July 2013.

[PWE3-ICCP]

Martini, L., Salam, S., Sajassi, A., and S. Matsushima, "Inter-Chassis Communication Protocol for L2VPN PE Redundancy", Work in Progress, March 2014.

[MEF] Metro Ethernet Forum, "Ethernet Service Definitions", MEF 6.1 Technical Specification, April 2008.

[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.

[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, November 2012.

[RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, February 2014.