Internet Engineering Task Force (IETF) K. Kompella
Request for Comments: 6624 Juniper Networks
Category: Informational B. Kothari
ISSN: 2070-1721 Cisco Systems
R. Cherukuri
Juniper Networks
May 2012
Internet Engineering Task Force (IETF) K. Kompella
Request for Comments: 6624 Juniper Networks
Category: Informational B. Kothari
ISSN: 2070-1721 Cisco Systems
R. Cherukuri
Juniper Networks
May 2012
Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling
使用BGP进行自动发现和信令的第2层虚拟专用网络
Abstract
摘要
Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular. Traditional L2VPNs often required a separate Service Provider infrastructure for each type and yet another for the Internet and IP VPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional L2VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs, and the Internet, as well as a common provisioning methodology for all services.
基于帧中继或ATM电路的第二层虚拟专用网（L2VPN）已经存在很长时间；最近，以太网VPN（包括虚拟专用LAN服务）变得流行起来。传统的L2VPN通常需要为每种类型提供单独的服务提供商基础设施，为Internet和IP VPN提供另一种基础设施。此外，L2VPN配置也很麻烦。本文档介绍了一种解决L2VPN服务问题的新方法，其中L2VPN客户的体验与传统L2VPN提供的体验几乎相同，但服务提供商可以为L2VPN、IP VPN和Internet维护单一网络，以及所有服务的通用配置方法。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6624.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6624.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................6
1.1.1. Conventions Used in This Document ...................6
1.2. Advantages of Layer 2 VPNs .................................6
1.2.1. Separation of Administrative Responsibilities .......7
1.2.2. Migrating from Traditional Layer 2 VPNs .............7
1.2.3. Privacy of Routing ..................................7
1.2.4. Layer 3 Independence ................................7
1.2.5. PE Scaling ..........................................8
1.2.6. Ease of Configuration ...............................8
1.3. Advantages of Layer 3 VPNs .................................9
1.3.1. Layer 2 Independence ................................9
1.3.2. SP Routing as Added Value ..........................10
1.3.3. Class of Service ...................................10
1.4. Multicast Routing .........................................10
2. Operation of a Layer 2 VPN .....................................11
2.1. Network Topology ..........................................11
2.2. Configuration .............................................13
2.2.1. CE Configuration ...................................14
2.2.2. PE Configuration ...................................15
2.2.3. Adding a New Site ..................................15
2.2.4. Deleting a Site ....................................16
2.2.5. Managing CE ID Mappings ............................16
2.2.6. Managing Label Blocks ..............................16
2.3. Operations, Administration, and Maintenance (OAM) .........17
3. PE Information Exchange ........................................17
3.1. Circuit Status Vector .....................................19
3.2. Generalizing the VPN Topology .............................20
4. Layer 2 Interworking ...........................................21
5. Packet Transport ...............................................22
5.1. Layer 2 MTU ...............................................22
5.2. Layer 2 Frame Format ......................................22
5.3. IP-Only Layer 2 Interworking ..............................23
6. Security Considerations ........................................23
7. IANA Considerations ............................................23
8. Acknowledgments ................................................24
9. Contributors ...................................................24
10. References ....................................................24
10.1. Normative References .....................................24
10.2. Informative References ...................................25
1. Introduction ....................................................3
1.1. Terminology ................................................6
1.1.1. Conventions Used in This Document ...................6
1.2. Advantages of Layer 2 VPNs .................................6
1.2.1. Separation of Administrative Responsibilities .......7
1.2.2. Migrating from Traditional Layer 2 VPNs .............7
1.2.3. Privacy of Routing ..................................7
1.2.4. Layer 3 Independence ................................7
1.2.5. PE Scaling ..........................................8
1.2.6. Ease of Configuration ...............................8
1.3. Advantages of Layer 3 VPNs .................................9
1.3.1. Layer 2 Independence ................................9
1.3.2. SP Routing as Added Value ..........................10
1.3.3. Class of Service ...................................10
1.4. Multicast Routing .........................................10
2. Operation of a Layer 2 VPN .....................................11
2.1. Network Topology ..........................................11
2.2. Configuration .............................................13
2.2.1. CE Configuration ...................................14
2.2.2. PE Configuration ...................................15
2.2.3. Adding a New Site ..................................15
2.2.4. Deleting a Site ....................................16
2.2.5. Managing CE ID Mappings ............................16
2.2.6. Managing Label Blocks ..............................16
2.3. Operations, Administration, and Maintenance (OAM) .........17
3. PE Information Exchange ........................................17
3.1. Circuit Status Vector .....................................19
3.2. Generalizing the VPN Topology .............................20
4. Layer 2 Interworking ...........................................21
5. Packet Transport ...............................................22
5.1. Layer 2 MTU ...............................................22
5.2. Layer 2 Frame Format ......................................22
5.3. IP-Only Layer 2 Interworking ..............................23
6. Security Considerations ........................................23
7. IANA Considerations ............................................23
8. Acknowledgments ................................................24
9. Contributors ...................................................24
10. References ....................................................24
10.1. Normative References .....................................24
10.2. Informative References ...................................25
The earliest Virtual Private Networks (VPNs) were based on Layer 2 circuits: X.25, Frame Relay, and ATM (see [Kosiur]). More recently, multipoint VPNs based on Ethernet Virtual Local Area Networks (VLANs) and Virtual Private LAN Service (VPLS) [RFC4761][RFC4762] have become quite popular. In contrast, the VPNs described in this document are point-to-point, and usually called Virtual Private Wire Service (VPWS). All of these come under the classification of Layer 2 VPNs (L2VPNs), as the customer-to-Service-Provider hand-off is at Layer 2.
最早的虚拟专用网络（VPN）基于第2层电路：X.25、帧中继和ATM（见[Kosiur]）。最近，基于以太网虚拟局域网（VLAN）和虚拟专用局域网服务（VPLS）[RFC4761][RFC4762]的多点VPN变得非常流行。相反，本文档中描述的VPN是点对点的，通常称为虚拟专用线服务（VPWS）。所有这些都属于第2层VPN（L2VPN）的类别，因为客户与服务提供商的交接是在第2层进行的。
There are at least two factors that adversely affected the cost of offering L2VPNs. The first is that the easiest way to offer an L2VPN of a given type of Layer 2 was over an infrastructure of the same type. This approach required that the Service Provider build a separate infrastructure for each Layer 2 encapsulation, e.g., an ATM infrastructure for ATM VPNs, an Ethernet infrastructure for Ethernet VPNs, etc. In addition, a separate infrastructure was needed for the Internet and IP VPNs [RFC4364], and possibly yet another for voice services. Going down this path meant a proliferation of networks.
至少有两个因素会对提供L2VPN的成本产生不利影响。首先，提供给定类型的第2层L2VPN的最简单方法是通过相同类型的基础设施。该方法要求服务提供商为每个第2层封装构建单独的基础设施，例如，用于ATM VPN的ATM基础设施、用于以太网VPN的以太网基础设施等。此外，互联网和IP VPN需要单独的基础设施[RFC4364]，语音服务可能还需要另一个基础设施。沿着这条路走下去意味着网络的扩散。
The other is that each of these networks had different provisioning methodologies. Furthermore, the provisioning of an L2VPN was fairly complex. It is important to distinguish between a single Layer 2 circuit, which connects two customer sites, and a Layer 2 VPN, which is a set of circuits that connect sites belonging to the same customer. The fact that two different circuits belonged to the same VPN was typically known only to the provisioning system, not to the switches offering the service; this complicated the setting up, and subsequently, the troubleshooting, of an L2VPN. Also, each switch offering the service had to be provisioned with the address of every other switch in the same VPN, requiring, in the case of full-mesh VPN connectivity, provisioning proportional to the square of the number of sites. This made full-mesh L2VPN connectivity prohibitively expensive for the Service Provider (SP) and thus also for customers. Finally, even setting up an individual circuit often required the provisioning of every switch along the path.
另一个是，这些网络中的每一个都有不同的资源调配方法。此外，L2VPN的配置相当复杂。区分连接两个客户站点的单个第2层电路和连接属于同一客户站点的一组电路的第2层VPN非常重要。两个不同的电路属于同一个VPN的事实通常只有供应系统知道，而不是提供服务的交换机知道；这使L2VPN的设置和随后的故障排除变得复杂。此外，提供服务的每个交换机都必须配置同一VPN中其他交换机的地址，在全网状VPN连接的情况下，需要与站点数量的平方成比例的配置。这使得全网状L2VPN连接对服务提供商（SP）以及客户来说都非常昂贵。最后，即使设置一个单独的电路，通常也需要沿路径配置每个交换机。
Of late, there has been much progress in network "convergence", whereby Layer 2 traffic, Internet traffic, and IP VPN traffic can be carried over a single, consolidated network infrastructure based on IP/MPLS tunnels; this is made possible by techniques such as those described in [RFC4448], [RFC4618], [RFC4619], and [RFC4717] for Layer 2 traffic and in [RFC4364] for IP VPN traffic. This development goes a long way toward addressing the problem of network proliferation. This document goes one step further and shows how a Service Provider can offer Layer 2 VPNs using protocol and provisioning methodologies similar to that used for VPLS [RFC4761] and IP VPNs [RFC4364],
最近，在网络“融合”方面取得了很大进展，第2层流量、互联网流量和IP VPN流量可以通过基于IP/MPLS隧道的单一整合网络基础设施进行传输；这是通过[RFC4448]、[RFC4618]、[RFC4619]和[RFC4717]中描述的用于第2层流量和[RFC4364]中描述的用于IP VPN流量的技术实现的。这一发展对解决网络扩散问题有很大帮助。本文档进一步说明了服务提供商如何使用与VPLS[RFC4761]和IP VPN[RFC4364]类似的协议和配置方法提供第2层VPN，
thereby achieving a significant degree of operational convergence as well. In particular, all of these methodologies include the notion of a VPN identifier that serves to unify components of a given VPN and the concept of auto-discovery, which simplifies the provisioning of dense VPN topologies (for example, a full mesh). In addition, similar techniques are used in all of the above-mentioned VPN technologies to offer inter-AS and inter-provider VPNs (i.e., VPNs whose sites are connected to multiple Autonomous Systems (ASes) or Service Providers).
从而实现了相当程度的业务融合。特别是，所有这些方法都包括用于统一给定VPN组件的VPN标识符的概念和自动发现的概念，这简化了密集VPN拓扑（例如，全网状）的供应。此外，在所有上述VPN技术中使用类似的技术来提供AS间和提供商间VPN（即，其站点连接到多个自治系统（AS）或服务提供商的VPN）。
Technically, the approach proposed here uses the concepts and solution described in [RFC4761], which describes a method for VPLS, a particular form of a Layer 2 VPN. That document, in turn, borrowed much from [RFC4364], including the use of BGP for auto-discovery and "demultiplexor" (see below) exchange and the concepts of Route Distinguishers to make VPN advertisements unique and Route Targets to control VPN topology. In addition, all three documents share the idea that routers not directly connected to VPN customers should carry no VPN state, restricting the provisioning of individual connections to just the edge devices. This is achieved using tunnels to carry the data, with a demultiplexor that identifies individual VPN circuits. These tunnels could be based on MPLS, GRE, or any other tunnel technology that offers a demultiplexing field; the signaling of these tunnels is outside the scope of this document. The specific approach taken here is to use an MPLS label as the demultiplexor.
从技术上讲，本文提出的方法使用了[RFC4761]中描述的概念和解决方案，其中描述了VPLS的方法，VPLS是第2层VPN的一种特殊形式。该文件反过来借鉴了[RFC4364]的许多内容，包括使用BGP进行自动发现和“解复用器”（见下文）交换，以及路由识别器的概念，以使VPN广告独特，并将路由目标用于控制VPN拓扑。此外，所有三份文件都有一个共同的想法，即未直接连接到VPN客户的路由器不应携带任何VPN状态，从而限制仅向边缘设备提供单个连接。这是通过使用隧道传输数据来实现的，带有识别单个VPN电路的解复用器。这些隧道可以基于MPLS、GRE或提供解复用领域的任何其他隧道技术；这些隧道的信号不在本文件范围内。这里采用的具体方法是使用MPLS标签作为解复用器。
Layer 2 VPNs typically require that all sites in the VPN connect to the SP with the same Layer 2 encapsulation. To ease this restriction, this document proposes a limited form of Layer 2 interworking, by restricting the Layer 3 protocol to IP only (see Section 4).
第2层VPN通常要求VPN中的所有站点使用相同的第2层封装连接到SP。为了缓解这一限制，本文件提出了一种有限形式的第2层互通，将第3层协议仅限于IP（见第4节）。
It may be instructive to compare the approach described in [RFC4447] and [RFC6074] (these are the IETF-approved technologies for the functions described in this document, albeit using two separate protocols) with the one described here. To comply with IETF standards, it is recommended that devices implementing the solution described in this document also implement the approach in [RFC4447] and [RFC6074].
将[RFC4447]和[RFC6074]中描述的方法（这些是IETF批准的技术，用于本文件中描述的功能，尽管使用了两个单独的协议）与此处描述的方法进行比较可能会有所启发。为符合IETF标准，建议实现本文件所述解决方案的设备也采用[RFC4447]和[RFC6074]中的方法。
The rest of this section discusses the relative merits of Layer 2 and Layer 3 VPNs. Section 2 describes the operation of a Layer 2 VPN. Section 3 describes PE information exchange. Section 4 describes IP-only Layer 2 interworking. Section 5 describes how the L2 packets are transported across the SP network.
本节其余部分将讨论第2层和第3层VPN的相对优点。第2节描述了第2层VPN的操作。第3节描述了PE信息交换。第4节描述了仅限IP的第2层互通。第5节描述了如何通过SP网络传输L2数据包。
The terminology used is from [RFC4761] and [RFC4364]; it is briefly repeated here. A "customer" is a customer of a Service Provider seeking to interconnect their various "sites" (each an independent network) at Layer 2 through the Service Provider's network, while maintaining privacy of communication and address space. The device in a customer site that connects to a Service Provider router is termed the CE (customer edge) device; this device may be a router or a switch. The Service Provider router to which a CE connects is termed a PE (provider edge). A router in the Service Provider's network that doesn't connect directly to any CE is termed P ("provider" device). Every pair of PEs is connected by a "tunnel"; within a tunnel, VPN data is distinguished by a "demultiplexor", which in this document is an MPLS label.
使用的术语来自[RFC4761]和[RFC4364]；这里简单地重复一下。“客户”是指服务提供商的客户，他们寻求通过服务提供商的网络在第2层互连其各个“站点”（每个站点都是独立的网络），同时维护通信和地址空间的隐私。客户站点中连接到服务提供商路由器的设备称为CE（客户边缘）设备；此设备可以是路由器或交换机。CE连接到的服务提供商路由器称为PE（提供商边缘）。服务提供商网络中不直接连接到任何CE的路由器称为P（“提供商”设备）。每对PEs通过“隧道”连接；在隧道内，VPN数据通过“解复用器”进行区分，在本文档中，解复用器是MPLS标签。
Each CE within a VPN is assigned a CE ID, a number that uniquely identifies a CE within an L2VPN. More accurately, the CE ID identifies a physical connection from the CE device to the PE, since a CE may be connected to multiple PEs (or multiply connected to a PE); in such a case, the CE would have a CE ID for each connection. A CE may also be part of many L2VPNs; it would need one (or more) CE ID(s) for each L2VPN of which it is a member. The number space for CE IDs is scoped to a given VPN.
VPN中的每个CE都分配了一个CE ID，一个唯一标识L2VPN中CE的数字。更准确地说，CE ID识别从CE设备到PE的物理连接，因为CE可以连接到多个PE（或多个连接到PE）；在这种情况下，CE将为每个连接都有一个CE ID。CE也可能是许多L2VPN的一部分；对于它所属的每个L2VPN，它需要一个（或多个）CE ID。CE ID的数字空间限定为给定的VPN。
In the case of inter-provider L2VPNs, there needs to be some coordination of allocation of CE IDs. One solution is to allocate ranges for each SP. Other solutions may be forthcoming.
在提供商间L2VPN的情况下，需要对CE ID的分配进行一些协调。一种解决方案是为每个SP分配范围。其他解决方案可能即将推出。
Within each physical connection from a CE to a PE, there may be multiple virtual circuits. These will be referred to as Attachment Circuits (ACs), following [RFC3985]. Similarly, the entity that connects two attachment circuits across the Service Provider network is called a pseudowire (PW).
在从CE到PE的每个物理连接中，可能存在多个虚拟电路。在[RFC3985]之后，这些将被称为连接电路（ACs）。类似地，跨服务提供商网络连接两个连接电路的实体称为伪线（PW）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
A Layer 2 VPN is one where a Service Provider provides Layer 2 connectivity to the customer. The Service Provider does not participate in the customer's Layer 3 network, especially in the routing, resulting in several advantages to the SP as a whole and to PE routers in particular.
第2层VPN是服务提供商向客户提供第2层连接的VPN。服务提供商不参与客户的第3层网络，尤其是在路由中，这对SP整体，尤其是PE路由器带来了一些优势。
In a Layer 2 VPN, the Service Provider is responsible for Layer 2 connectivity; the customer is responsible for Layer 3 connectivity, which includes routing. If the customer says that host x in site A cannot reach host y in site B, the Service Provider need only demonstrate that site A is connected to site B. The details of how routes for host y reach host x are the customer's responsibility.
在第2层VPN中，服务提供商负责第2层连接；客户负责第3层连接，包括路由。如果客户表示站点A中的主机x无法到达站点B中的主机y，则服务提供商只需证明站点A已连接到站点B。主机y如何到达主机x的详细信息由客户负责。
Another important factor is that once a PE provides Layer 2 connectivity to its connected CE, its job is done. A misbehaving CE can at worst flap its interface, but route flaps in the customer network have little effect on the SP network. On the other hand, a misbehaving CE in a Layer 3 VPN can flap its routes, leading to instability of the PE router or even the entire SP network. Thus, when offering a Layer 3 VPN, an SP should proactively protect itself from Layer 3 instability in the CE network.
另一个重要因素是，一旦PE向其连接的CE提供第2层连接，其工作就完成了。行为不端的CE在最坏的情况下可以调整其接口，但客户网络中的路由调整对SP网络几乎没有影响。另一方面，第3层VPN中行为不正常的CE会改变其路由，导致PE路由器甚至整个SP网络不稳定。因此，在提供第3层VPN时，SP应主动保护自己免受CE网络中第3层不稳定的影响。
Since "traditional" Layer 2 VPNs (i.e., real Frame Relay circuits connecting sites) are indistinguishable from tunnel-based VPNs from the customer's point of view, migrating from one to the other raises few issues. Layer 3 VPNs, on the other hand, require a considerable redesign of the customer's Layer 3 routing architecture. Furthermore, with Layer 3 VPNs, special care has to be taken that routes within the traditional VPN are not preferred over the Layer 3 VPN routes (the so-called "backdoor routing" problem, whose solution requires protocol changes that are somewhat ad hoc).
由于从客户的角度来看，“传统”第2层VPN（即连接站点的真实帧中继电路）与基于隧道的VPN无法区分，因此从一个VPN迁移到另一个VPN会带来一些问题。另一方面，第3层VPN需要对客户的第3层路由架构进行大量重新设计。此外，对于第3层VPN，必须特别注意，传统VPN内的路由不优于第3层VPN路由（所谓的“后门路由”问题，其解决方案需要进行某种特殊的协议更改）。
In an L2VPN, the privacy of customer routing is a natural fallout of the fact that the Service Provider does not participate in routing. The SP routers need not do anything special to keep customer routes separate from other customers or from the Internet; there is no need for per-VPN routing tables and the additional complexity this imposes on PE routers.
在L2VPN中，客户路由的隐私是服务提供商不参与路由这一事实的自然后果。SP路由器不需要做任何特殊的事情来将客户路由与其他客户或互联网分开；不需要每VPN路由表，这会增加PE路由器的复杂性。
Since the Service Provider simply provides Layer 2 connectivity, the customer can run any Layer 3 protocols they choose. If the SP were participating in customer routing, it would be vital that the customer and SP both use the same Layer 3 protocol(s) and routing protocols.
由于服务提供商只提供第2层连接，因此客户可以运行他们选择的任何第3层协议。如果SP参与客户路由，则客户和SP必须使用相同的第3层协议和路由协议。
Note that IP-only Layer 2 interworking doesn't have this benefit as it restricts the Layer 3 to IP only.
请注意，仅限IP的第2层互通没有此好处，因为它将第3层限制为仅限IP。
In the Layer 2 VPN scheme described below, each PE transmits a single small chunk of information about every CE that the PE is connected to every other PE. That means that each PE need only maintain a single chunk of information from each CE in each VPN and keep a single "route" to every site in every VPN. This means that both the Forwarding Information Base and the Routing Information Base scale well with the number of sites and number of VPNs. Furthermore, the scaling properties are independent of the customer: the only germane quantity is the total number of VPN sites.
在下面描述的第2层VPN方案中，每个PE发送关于该PE连接到每个其他PE的每个CE的单个小信息块。这意味着每个PE只需要维护来自每个VPN中每个CE的单个信息块，并保留到每个VPN中每个站点的单个“路由”。这意味着转发信息库和路由信息库都会随着站点数量和VPN数量的增加而扩展。此外，扩展属性独立于客户：唯一密切相关的数量是VPN站点的总数。
This is to be contrasted with Layer 3 VPNs, where each CE in a VPN may have an arbitrary number of routes that need to be carried by the SP. This leads to two issues. First, both the information stored at each PE and the number of routes installed by the PE for a CE in a VPN can be (in principle) unbounded, which means in practice that a PE must restrict itself to installing routes associated with the VPNs of which it is currently a member. Second, a CE can send a large number of routes to its PE, which means that the PE must protect itself against such a condition. Thus, the SP must enforce limits on the number of routes accepted from a CE; this, in turn, requires the PE router to offer such control.
这与第3层VPN形成对比，在第3层VPN中，VPN中的每个CE可能有任意数量的路由需要由SP承载。这会导致两个问题。首先，存储在每个PE的信息和PE为VPN中的CE安装的路由数（原则上）可以是无限制的，这意味着实际上，PE必须限制自己安装与其当前是其成员的VPN相关联的路由。其次，CE可以向其PE发送大量路由，这意味着PE必须保护自己不受这种情况的影响。因此，SP必须对CE接受的路线数量实施限制；这反过来又要求PE路由器提供这种控制。
The scaling issues of Layer 3 VPNs come into sharp focus at a BGP route reflector (RR). An RR cannot keep all the advertised routes in every VPN since the number of routes will be too large. The following solutions/extensions are needed to address this issue:
第3层VPN的缩放问题在BGP路由反射器（RR）上成为焦点。RR无法在每个VPN中保留所有播发的路由，因为路由数量太多。需要以下解决方案/扩展来解决此问题：
1. RRs could be partitioned so that each RR services a subset of VPNs so that no single RR has to carry all the routes.
1. 可以对RRs进行分区，以便每个RR为VPN的一个子集提供服务，从而使单个RR不必承载所有路由。
2. An RR could use a preconfigured list of Route Targets for its inbound route filtering. The RR may choose to perform Route Target Filtering, described in [RFC4684].
2. RR可以使用预先配置的路由目标列表进行入站路由筛选。RR可选择执行[RFC4684]中所述的路由目标过滤。
Configuring traditional Layer 2 VPNs with dense topologies was a burden primarily because of the O(n*n) nature of the task. If there are n CEs in a Frame Relay VPN, say full-mesh connected, n*(n-1)/2 DLCI (Data Link Connection Identifier) Permanent Virtual Circuits (PVCs) must be provisioned across the SP network. At each CE, (n-1) DLCIs must be configured to reach each of the other CEs. Furthermore, when a new CE is added, n new DLCI PVCs must be
使用密集拓扑配置传统的第2层VPN是一个负担，主要是因为任务的O（n*n）性质。如果帧中继VPN中有n个CE，例如全网状连接，则必须在SP网络上提供n*（n-1）/2个DLCI（数据链路连接标识符）永久虚拟电路（PVC）。在每个CE，必须将（n-1）个DLCI配置为到达每个其他CE。此外，添加新CE时，必须添加n个新DLCI PVC
provisioned; also, each existing CE must be updated with a new DLCI to reach the new CE. Finally, each PVC requires state in every transit switch.
供应；此外，必须使用新的DLCI更新每个现有CE以到达新CE。最后，每个PVC需要每个传输开关中的状态。
In our proposal, PVCs are tunneled across the SP network. The tunnels used are provisioned independently of the L2VPNs, using signaling protocols (in the case of MPLS, LDP or RSVP - Traffic Engineering (RSVP-TE) can be used), or set up by configuration; the number of tunnels is independent of the number of L2VPNs. This reduces a large part of the provisioning burden.
在我们的方案中，PVC通过SP网络进行隧道传输。所使用的隧道使用信令协议（在MPLS、LDP或RSVP的情况下，可以使用流量工程（RSVP-TE））独立于L2VPN进行供应，或通过配置进行设置；隧道的数量与L2VPN的数量无关。这减少了很大一部分资源调配负担。
Furthermore, we assume that DLCIs at the CE edge are relatively cheap and that VPN labels in the SP network are cheap. This allows the SP to "overprovision" VPNs, for example, allocate 50 CEs to a VPN when only 20 are needed. With this overprovisioning, adding a new CE to a VPN requires configuring just the new CE and its associated PE; existing CEs and their PEs need not be reconfigured. Note that if DLCIs at the CE edge are expensive, e.g., if these DLCIs are provisioned across a switched network, one could provision them as and when needed, at the expense of extra configuration. This need not still result in extra state in the SP network, i.e., an intelligent implementation can allow overprovisioning of the pool of VPN labels.
此外，我们假设CE边缘的DLCI相对便宜，SP网络中的VPN标签也便宜。这允许SP“过度提供”VPN，例如，当只需要20个CE时，为VPN分配50个CE。通过这种过度配置，将新CE添加到VPN需要只配置新CE及其关联的PE；现有CE及其PE无需重新配置。请注意，如果CE边缘的DLCI非常昂贵，例如，如果这些DLCI是通过交换网络配置的，则可以在需要时配置它们，而不需要额外配置。这仍然不需要在SP网络中产生额外的状态，即智能实现可以允许过度提供VPN标签池。
Layer 3 VPNs ([RFC4364] in particular) offer a good solution when the customer traffic is wholly IP, customer routing is reasonably simple, and the customer sites connect to the SP with a variety of Layer 2 technologies.
第3层VPN（特别是[RFC4364]）提供了一个很好的解决方案，当客户流量完全是IP，客户路由相当简单，客户站点使用各种第2层技术连接到SP时。
One major restriction in a Layer 2 VPN is that the Layer 2 media with which the various sites of a single VPN connect to the SP must be uniform. On the other hand, the various sites of a Layer 3 VPN can connect to the SP with any supported media; for example, some sites may connect with Frame Relay circuits and others with Ethernet.
第2层VPN中的一个主要限制是，单个VPN的各个站点连接到SP的第2层介质必须是统一的。另一方面，第三层VPN的各个站点可以使用任何支持的媒体连接到SP；例如，一些站点可以与帧中继电路连接，而另一些站点可以与以太网连接。
This restriction of Layer 2 VPN is alleviated by the IP-only Layer 2 interworking proposed in this document. This comes at the cost of losing the Layer 3 independence.
本文件中提出的仅限IP的第2层互通缓解了第2层VPN的限制。这是以失去第3层独立性为代价的。
A corollary to this is that the number of sites that can be in a Layer 2 VPN is determined by the number of Layer 2 circuits that the Layer 2 technology provides. For example, if the Layer 2 technology is Frame Relay with 2-octet DLCIs, a CE can at most connect to about a thousand other CEs in a VPN.
由此推论，第2层VPN中可以存在的站点数量由第2层技术提供的第2层电路的数量决定。例如，如果第2层技术是具有2个八位组DLCI的帧中继，则一个CE最多可以连接到VPN中的大约1000个其他CE。
Another problem with Layer 2 VPNs is that the CE router in a VPN must be able to deal with having N routing peers, where N is the number of sites in the VPN. This can be alleviated by manipulating the topology of the VPN. For example, a hub-and-spoke VPN architecture means that only one CE router (the hub) need deal with N neighbors. However, in a Layer 3 VPN, a CE router need only deal with one neighbor, the PE router. Thus, the SP can offer Layer 3 VPNs as a value-added service to its customers.
第2层VPN的另一个问题是VPN中的CE路由器必须能够处理N个路由对等点，其中N是VPN中的站点数。这可以通过操纵VPN的拓扑结构来缓解。例如，中心辐射VPN体系结构意味着只有一个CE路由器（中心）需要处理N个邻居。然而，在第3层VPN中，CE路由器只需要处理一个邻居，即PE路由器。因此，SP可以将第3层VPN作为增值服务提供给客户。
Moreover, with Layer 2 VPNs, it is up to a customer to build and operate the whole network. With Layer 3 VPNs, a customer is just responsible for building and operating routing within each site, which is likely to be much simpler than building and operating routing for the whole VPN. That, in turn, makes Layer 3 VPNs more suitable for customers who don't have sufficient routing expertise, again allowing the SP to provide added value.
此外，使用第2层VPN，整个网络的构建和运营由客户决定。对于第3层VPN，客户只需负责在每个站点内构建和操作路由，这可能比构建和操作整个VPN的路由简单得多。这反过来又使第3层VPN更适合于没有足够路由专业知识的客户，从而使SP能够提供附加值。
As mentioned later, multicast routing and forwarding is another value-added service that an SP can offer.
如后所述，多播路由和转发是SP可以提供的另一项增值服务。
Class-of-Service (CoS) issues have been addressed for Layer 3 VPNs. Since the PE router has visibility into the network Layer (IP), the PE router can take on the tasks of CoS classification and routing. This restriction on Layer 2 VPNs is again eased in the case of IP-only Layer 2 interworking, as the PE router has visibility into the network Layer (IP).
已针对第3层VPN解决了服务类别（CoS）问题。由于PE路由器对网络层（IP）具有可见性，因此PE路由器可以承担CoS分类和路由任务。在仅使用IP的第2层互通的情况下，对第2层VPN的这种限制再次得到缓解，因为PE路由器可以看到网络层（IP）。
There are two aspects to multicast routing that we will consider. On the protocol front, supporting IP multicast in a Layer 3 VPN requires PE routers to participate in the multicast routing instance of the customer and thus keep some related state information.
我们将考虑组播路由的两个方面。在协议方面，在第三层VPN中支持IP多播需要PE路由器参与客户的多播路由实例，从而保留一些相关的状态信息。
In the Layer 2 VPN case, the CE routers run native multicast routing directly. The SP network just provides pipes to connect the CE routers; PEs are unaware whether the CEs run multicast or not and thus do not have to participate in multicast protocols or keep multicast state information.
在第2层VPN情况下，CE路由器直接运行本机多播路由。SP网络仅提供连接CE路由器的管道；PEs不知道CEs是否运行多播，因此不必参与多播协议或保留多播状态信息。
On the forwarding front, in a Layer 3 VPN, CE routers do not replicate multicast packets; thus, the CE-PE link carries only one copy of a multicast packet. Whether replication occurs at the ingress PE or somewhere within the SP network depends on the
在转发方面，在第3层VPN中，CE路由器不复制多播数据包；因此，CE-PE链路仅携带多播分组的一个副本。复制是发生在入口PE还是SP网络中的某个位置取决于
sophistication of the Layer 3 VPN multicast solution. The simple solution where a PE replicates packets for each of its CEs may place considerable burden on the PE. More complex solutions may require VPN multicast state in the SP network but may significantly reduce the traffic in the SP network by delaying packet replication until needed.
第3层VPN多播解决方案的复杂性。PE为其每个CE复制数据包的简单解决方案可能会给PE带来相当大的负担。更复杂的解决方案可能需要SP网络中的VPN多播状态，但通过延迟数据包复制直到需要时，可能会显著减少SP网络中的流量。
In a Layer 2 VPN, packet replication occurs at the CE. This has the advantage of distributing the burden of replication among the CEs rather than focusing it on the PE to which they are attached and thus will scale better. However, the CE-PE link will need to carry multiple copies of multicast packets. However, in the case of Virtual Private LAN Service (a specific type of L2VPN; see [RFC4761]), the CE-PE link need transport only one copy of a multicast packet.
在第2层VPN中，数据包复制发生在CE上。这样做的优点是将复制负担分散在CE之间，而不是集中在它们所连接的PE上，因此可以更好地扩展。然而，CE-PE链路将需要承载多播数据包的多个副本。然而，在虚拟专用LAN服务（L2VPN的一种特定类型；请参见[RFC4761]）的情况下，CE-PE链路只需要传输多播数据包的一个副本。
Thus, just as in the case of unicast routing, the SP has the choice to offer a value-added service (multicast routing and forwarding) at some cost (multicast state and packet replication) using a Layer 3 VPN or to keep it simple and use a Layer 2 VPN.
因此，与单播路由的情况一样，SP可以选择使用第3层VPN以一定成本（多播状态和数据包复制）提供增值服务（多播路由和转发），或者保持简单并使用第2层VPN。
The following simple example of a customer with four sites connected to three PE routers in a Service Provider network will hopefully illustrate the various aspects of the operation of a Layer 2 VPN. For simplicity, we assume that a full-mesh topology is desired.
下面是一个简单的客户示例，该客户的四个站点连接到服务提供商网络中的三个PE路由器，希望能够说明第2层VPN操作的各个方面。为简单起见，我们假设需要全网格拓扑。
In what follows, Frame Relay serves as the Layer 2 media, and each CE has multiple DLCIs to its PE, each connecting to another CE in the VPN. If the Layer 2 media were ATM, then each CE would have multiple VPIs/VCIs (Virtual Path Identifiers/Virtual Channel Identifiers) to connect to other CEs. For Point-to-Point Protocol (PPP) and Cisco High-Level Data Link Control (HDLC), each CE would have multiple physical interfaces to connect to other CEs. In the case of IP-only Layer 2 interworking, each CE could have a mix of one or more of the above Layer 2 media to connect to other CEs.
在下面的内容中，帧中继用作第2层介质，每个CE都有多个到其PE的DLCI，每个DLCI都连接到VPN中的另一个CE。如果第2层介质是ATM，则每个CE将具有多个VPI/VCI（虚拟路径标识符/虚拟信道标识符）以连接到其他CE。对于点对点协议（PPP）和Cisco高级数据链路控制（HDLC），每个CE将有多个物理接口连接到其他CE。在仅IP第2层互通的情况下，每个CE可以混合使用一个或多个上述第2层介质来连接到其他CE。
Consider a Service Provider network with edge routers PE0, PE1, and PE2. Assume that PE0 and PE1 are IGP neighbors, and PE2 is more than one hop away from PE0.
考虑具有边缘路由器PE0、PE1和PE2的服务提供商网络。假设PE0和PE1是IGP邻居，PE2与PE0的距离超过一跳。
Suppose that a customer C has four sites S0, S1, S2, and S3, that C wants to connect via the Service Provider's network using Frame Relay. Site S0 has CE0 and CE1 both connected to PE0. Site S1 has CE2 connected to PE0. Site S2 has CE3 connected to PE1 and CE4
假设客户C有四个站点S0、S1、S2和S3，C希望使用帧中继通过服务提供商的网络连接这些站点。站点S0的CE0和CE1均连接至PE0。站点S1将CE2连接到PE0。站点S2的CE3与PE1和CE4相连
connected to PE2. Site S3 has CE5 connected to PE2. (See Figure 1 below.) Suppose further that C wants to "overprovision" each current site, in expectation that the number of sites will grow to at least 10 in the near future. However, CE4 is only provisioned with nine DLCIs. (Note that the signaling mechanism discussed in Section 3.2 of [RFC4761] will allow a site to grow in terms of connectivity to other sites at a later point of time at the cost of additional signaling, i.e., overprovisioning is not a must but a recommendation).
连接到PE2。站点S3将CE5连接到PE2。（参见下面的图1。）进一步假设C想要“过度提供”每个当前站点，期望在不久的将来站点的数量将增长到至少10个。但是，CE4仅配置了九个DLCI。（请注意，[RFC4761]第3.2节中讨论的信令机制将允许一个站点在以后的时间点以额外信令的成本在与其他站点的连接方面增长，即，过度提供不是必须的，而是建议）。
Finally, suppose that the CEs have been provisioned with DLCIs as per the following:
最后，假设CEs已按照以下要求配备DLCI：
CE# | Provisioned DLCIs
--------------------------------------------------------
0 | 100 through 109
1 | 200 through 209
2 | 100 through 109
3 | 200 through 209
4 | 107, 209, 265, 301, 414, 555, 654, 777, and 888
5 | 417 through 426
CE# | Provisioned DLCIs
--------------------------------------------------------
0 | 100 through 109
1 | 200 through 209
2 | 100 through 109
3 | 200 through 209
4 | 107, 209, 265, 301, 414, 555, 654, 777, and 888
5 | 417 through 426
S0 S3
.............. ..............
. . . .
. +-----+ . . .
. | CE0 |-----------+ . +-----+ .
. +-----+ . | . | CE5 | .
. . | . +--+--+ .
. +-----+ . | . | .
. | CE1 |-------+ | .......|......
. +-----+ . | | /
. . | | /
.............. | | /
| | SP Network /
.....|...|.............................../.....
. | | / .
. +-+---+-+ +-------+ / .
. | PE0 |-------| P |-- | .
. +-+---+-+ +-------+ \ | .
. / \ \ +---+---+ .
. | -----+ --| PE2 | .
. | | +---+---+ .
. | +---+---+ / .
. | | PE1 | / .
. | +---+---+ / .
. | \ / .
...|.............|.............../.............
| | /
| | /
| | /
S1 | | S2 /
.............. | ........|........../......
. . | . | | .
. +-----+ . | . +--+--+ +--+--+ .
. | CE2 |-----+ . | CE3 | | CE4 | .
. +-----+ . . +-----+ +-----+ .
. . . .
.............. ..........................
S0 S3
.............. ..............
. . . .
. +-----+ . . .
. | CE0 |-----------+ . +-----+ .
. +-----+ . | . | CE5 | .
. . | . +--+--+ .
. +-----+ . | . | .
. | CE1 |-------+ | .......|......
. +-----+ . | | /
. . | | /
.............. | | /
| | SP Network /
.....|...|.............................../.....
. | | / .
. +-+---+-+ +-------+ / .
. | PE0 |-------| P |-- | .
. +-+---+-+ +-------+ \ | .
. / \ \ +---+---+ .
. | -----+ --| PE2 | .
. | | +---+---+ .
. | +---+---+ / .
. | | PE1 | / .
. | +---+---+ / .
. | \ / .
...|.............|.............../.............
| | /
| | /
| | /
S1 | | S2 /
.............. | ........|........../......
. . | . | | .
. +-----+ . | . +--+--+ +--+--+ .
. | CE2 |-----+ . | CE3 | | CE4 | .
. +-----+ . . +-----+ +-----+ .
. . . .
.............. ..........................
Figure 1: Example Network Topology
图1：示例网络拓扑
The following sub-sections detail the configuration that is needed to provision the above VPN. For the purpose of exposition, we assume that the customer will connect to the SP with Frame Relay circuits.
以下小节详细介绍了配置上述VPN所需的配置。为了便于说明，我们假设客户将使用帧中继电路连接到SP。
While we focus primarily on the configuration that an SP has to do, we touch upon the configuration requirements of CEs as well. The main point of contact in CE-PE configuration is that both must agree on the DLCIs that will be used on the interface connecting them.
虽然我们主要关注SP必须进行的配置，但我们也会涉及CEs的配置要求。CE-PE配置中的主要接触点是，双方必须就将在连接它们的接口上使用的DLCI达成一致。
If the PE-CE connection is Frame Relay, it is recommended to run Link Management Interface (LMI) between the PE and CE. For the case of ATM VCs, Operations, Administration, and Maintenance (OAM) cells may be used. For PPP and Cisco HDLC, keepalives may be used directly between CEs; however, in this case, PEs would not have visibility as to the liveness of customers circuits.
如果PE-CE连接为帧中继，建议在PE和CE之间运行链路管理接口（LMI）。对于ATM VCs，可以使用操作、管理和维护（OAM）信元。对于PPP和Cisco HDLC，可在CEs之间直接使用keepalives；然而，在这种情况下，PEs将无法了解客户电路的活跃程度。
In the case of IP-only Layer 2 interworking, if CE1, attached to PE0, connects to CE3, attached to PE1, via an L2VPN circuit, the Layer 2 media between CE1 and PE0 is independent of the Layer 2 media between CE3 and PE1. Each side will run its own Layer-2-specific link management protocol, e.g., LMI, Link Control Protocol (LCP), etc. PE0 will inform PE1 about the status of its local circuit to CE1 via the circuit status vector TLV defined in Section 3.1. Similarly, PE1 will inform PE0 about the status of its local circuit to CE3.
在仅IP层2互通的情况下，如果连接到PE0的CE1通过L2VPN电路连接到连接到PE1的CE3，则CE1和PE0之间的第2层介质独立于CE3和PE1之间的第2层介质。每一方将运行其自己的第2层特定链路管理协议，例如LMI、链路控制协议（LCP）等。PE0将通过第3.1节中定义的电路状态向量TLV将其本地电路的状态通知PE1至CE1。同样，PE1将通知PE0其连接至CE3的本地电路的状态。
Each CE that belongs to a VPN is given a "CE ID". CE IDs must be unique in the context of a VPN. For the example, we assume that the CE ID for CE-k is k.
属于VPN的每个CE都被赋予一个“CE ID”。CE ID在VPN上下文中必须是唯一的。例如，我们假设CE-k的CE-ID是k。
Each CE is configured to communicate with its corresponding PE with the set of DLCIs given above, for example, CE0 is configured with DLCIs 100 through 109. In general, a CE is configured with a list of circuits, all with the same Layer 2 encapsulation type, e.g., DLCIs, VCIs, physical PPP interface, etc. (IP-only Layer 2 interworking allows a mix of Layer 2 encapsulation types.) The size of this list/ set determines the number of remote CEs with which a given CE can communicate. Denote the size of this list/set as the CE's range. A CE's range must be at least the number of remote CEs that the CE will connect to in a given VPN; if the range exceeds this, then the CE is overprovisioned, in anticipation of growth of the VPN.
每个CE被配置为使用上面给出的dlci集与其对应的PE通信，例如，CE0被配置为具有dlci 100到109。通常，CE配置有电路列表，所有电路都具有相同的第2层封装类型，例如DLCI、VCI、物理PPP接口等（仅IP第2层互通允许混合第2层封装类型）。此列表/集合的大小决定了给定CE可以与之通信的远程CE的数量。将此列表/集合的大小表示为CE的范围。CE的范围必须至少是CE将在给定VPN中连接到的远程CE的数量；如果范围超过此范围，则CE将过度配置，以应对VPN的增长。
Each CE also "knows" which DLCI connects it to every other CE. The methodology followed in this example is to use the CE ID of the other CE as an index into the DLCI list this CE has (with zero-based indexing, i.e., 0 is the first index). For example, CE0 is connected to CE3 through its fourth DLCI, 103; CE4 is connected to CE2 by the third DLCI in its list, namely 265. This is just the methodology used in the description here; the actual methodology used to pick the DLCI to be used is a local matter. The key factor is that CE-k may communicate with CE-m using a different DLCI from the DLCI that CE-m
每个CE还“知道”哪个DLCI将其连接到每个其他CE。本示例中遵循的方法是使用另一个CE的CE ID作为该CE拥有的DLCI列表的索引（使用基于零的索引，即0是第一个索引）。例如，CE0通过其第四DLCI 103连接到CE3；CE4通过其列表中的第三个DLCI（即265）连接到CE2。这只是本文描述中使用的方法；用于选择要使用的DLCI的实际方法是本地问题。关键因素是CE-k可以使用不同于CE-m使用的DLCI与CE-m通信
uses to communicate to CE-k, i.e., the SP network effectively acts as a giant Frame Relay switch. This is very important, as it decouples the DLCIs used at each CE site, making for much simpler provisioning.
用于与CE-k通信，即SP网络有效地充当巨型帧中继交换机。这一点非常重要，因为它将每个CE站点上使用的DLCI解耦，从而使资源调配更加简单。
Each PE is configured with the VPNs in which it participates. Each VPN is associated with one or more Route Target communities [RFC4360] that serve to define the topology of the VPN. For each VPN, the PE must determine a Route Distinguisher (RD) to use; this may either be configured or chosen by the PE. RDs do not have to be unique across the VPN. For each CE attached to the PE in a given VPN, the PE must know the set of virtual circuits (DLCI, VCI/VPI, or VLAN) connecting it to the CE and a CE ID identifying the CE within the VPN. CE IDs must be unique in the context of a given VPN.
每个PE都配置有其参与的VPN。每个VPN都与一个或多个路由目标社区[RFC4360]关联，这些社区用于定义VPN的拓扑结构。对于每个VPN，PE必须确定要使用的路由识别器（RD）；这可以由PE配置或选择。RDs在VPN中不必是唯一的。对于给定VPN中连接到PE的每个CE，PE必须知道将其连接到CE的虚拟电路集（DLCI、VCI/VPI或VLAN）以及标识VPN中CE的CE ID。CE ID在给定VPN的上下文中必须是唯一的。
The first step in adding a new site to a VPN is to pick a new CE ID. If all current members of the VPN are overprovisioned, i.e., their range includes the new CE ID, adding the new site is a purely local task. Otherwise, the sites whose range doesn't include the new CE ID and that wish to communicate directly with the new CE must have their ranges increased by allocating additional local circuits to incorporate the new CE ID.
向VPN添加新站点的第一步是选择一个新的CE ID。如果VPN的所有当前成员都配置过度，即其范围包括新的CE ID，则添加新站点纯粹是本地任务。否则，其范围不包括新CE ID且希望直接与新CE通信的站点必须通过分配额外的本地电路以合并新CE ID来增加其范围。
The next step is ensuring that the new site has the required connectivity. This usually requires adding a new virtual circuit between the PE and CE; in most cases, this configuration is limited to the PE in question.
下一步是确保新站点具有所需的连接。这通常需要在PE和CE之间添加新的虚拟电路；在大多数情况下，此配置仅限于所讨论的PE。
The rest of the configuration is a local matter between the new CE and the PE to which it is attached. At this point, the PE can signal to other PEs that it has a new site in the VPN by advertising a BGP Layer 2 route, and traffic connectivity will be set up.
配置的其余部分是新CE与其连接的PE之间的本地事务。此时，PE可以通过公布BGP第2层路由向其他PE发出信号，表示其在VPN中有一个新站点，并将建立流量连接。
It bears repeating that the key to making additions easy is overprovisioning and the algorithm for mapping a CE ID to a DLCI that is used for connecting to the corresponding CE. However, what is being overprovisioned is the number of DLCIs/VCIs that connect the CE to the PE. This is a local matter between the PE and CE; it does not affect other PEs or CEs.
值得重复的是，简化添加的关键是过度配置和将CE ID映射到用于连接到相应CE的DLCI的算法。但是，过度提供的是将CE连接到PE的DLCI/VCI的数量。这是PE和CE之间的本地事务；它不会影响其他PE或CE。
Deleting a site consists first of removing the CE ID of the site from the configuration of the PE to which the site is attached. The PE will then signal to other PEs that it no longer has access to that site by withdrawing its previously advertised BGP Layer 2 route. Connectivity to the deleted site will cease.
删除站点首先包括从站点所连接的PE的配置中删除站点的CE ID。然后，PE将通过撤回其先前公布的BGP第2层路由，向其他PE发出信号，表示其不再有权访问该站点。与已删除站点的连接将停止。
The next steps are bookkeeping: decommissioning the attachment circuit from the PE to the CE that corresponds to the site being removed and noting that the CE ID is now free for future allocation. Note that each PE is now (further) overprovisioned; one may choose to actively "reap" CE IDs if desired.
接下来的步骤是记账：解除从PE到CE的连接电路，该连接电路对应于要移除的站点，并注意CE ID现在是免费的，可供将来分配。请注意，每个PE现在（进一步）过度提供；如果需要，可以选择主动“收获”CE ID。
In the data plane, an attachment circuit, identified say by a DLCI, is mapped to a label via the control plane abstraction of a CE ID. At the egress PE, the label is mapped back to an attachment circuit via the same CE ID. It is up to the VPN administrator
在数据平面中，由DLCI标识的连接电路通过CE ID的控制平面抽象映射到标签。在出口PE，标签通过相同的CE ID映射回连接电路。这取决于VPN管理员
o to provision attachment circuits (e.g., DLCIs);
o 提供连接电路（如DLCI）；
o to allocate CE IDs; and
o 分配CE ID；和
o to keep a clear mapping of CE IDs to attachment circuits (and reflect this in PE configurations).
o 保持CE ID到连接电路的清晰映射（并在PE配置中反映这一点）。
The PEs manage the mappings between attachment circuits and labels, i.e., the data plane mappings.
PEs管理连接电路和标签之间的映射，即数据平面映射。
Note that in the N-to-one modes listed in Table 1, a single attachment circuit may correspond to several Layer 2 virtual circuits. Nevertheless, there is a one-to-one mapping between an attachment circuit and a CE ID (and thus a label).
注意，在表1中列出的N对1模式中，单个连接电路可能对应于多个第2层虚拟电路。然而，在连接电路和CE ID（以及标签）之间存在一对一映射。
Label blocks and label values are managed by the PEs. As sites get added and removed, labels are allocated and released. The easiest way to manage these is to use fixed-size label blocks rather than variable-size blocks, although the signaling described here supports either. If an implementation uses fixed-size blocks, then allocating a label for a new site may requiring allocating a new block; similarly, freeing a label may require freeing a block.
标签块和标签值由PEs管理。随着站点的添加和删除，标签被分配和发布。管理这些功能的最简单方法是使用固定大小的标签块，而不是可变大小的块，尽管这里描述的信令支持这两种功能。如果实现使用固定大小的块，则为新站点分配标签可能需要分配新块；类似地，释放标签可能需要释放块。
If the implementation requires fixed-size blocks, there is probably a default block size, but the implementation SHOULD allow the administrator to choose a size. Larger label block sizes mean more potential "wasted" labels but less signaling overhead, a trade-off that the administrator might want to control.
如果实现需要固定大小的块，则可能存在默认块大小，但实现应允许管理员选择大小。较大的标签块大小意味着更多潜在的“浪费”标签，但信令开销较小，这是管理员可能想要控制的一种权衡。
Also, as sites get added and deleted, a PE may receive packets with a label that reflects a site that has been deleted locally but not yet processed by remote PEs or that reflects a new site added remotely but not processed locally. In either of these cases, the PE SHOULD silently discard the packet; it may choose to log the event once for each such label, but not for every such packet.
此外，随着站点的添加和删除，PE可能会收到带有标签的数据包，该标签反映了已在本地删除但尚未由远程PE处理的站点，或反映了远程添加但未在本地处理的新站点。在这两种情况下，PE都应该默默地丢弃数据包；它可以选择为每个这样的标签记录一次事件，但不是为每个这样的数据包记录一次事件。
Many Layer 2 mediums have OAM mechanisms. For example, the PPP has Echo Request and Echo Reply messages; Frame Relay has the Local Management Interface. Among other things, OAM is used for troubleshooting and as keepalives.
许多第2层介质具有OAM机制。例如，PPP具有回显请求和回显回复消息；帧中继具有本地管理接口。其中，OAM用于故障排除和保持。
There are two ways to carry OAM information across Layer 2 VPNs. The first is to convey OAM packets as any other Layer 2 packets across the VPN. This is the most general method; it maintains full Layer 2 transparency and preserves all OAM information. The other method applies only to the link liveness aspect of OAM; it consists of transmitting the status of each attachment circuit across the control plane using the circuit status vector (Section 3.1). This method is the only one applicable to Layer 2 Interworking VPNs (Section 4), since OAM packets are not IP frames and thus cannot be transmitted across such Layer 2 VPNs.
有两种方法可以跨第2层VPN传输OAM信息。第一种方法是将OAM数据包作为任何其他第2层数据包在VPN上传输。这是最普遍的方法；它保持完全的第2层透明度，并保留所有OAM信息。另一种方法仅适用于OAM的链路活跃度方面；它包括使用电路状态向量（第3.1节）在控制平面上传输每个附件电路的状态。此方法是唯一适用于第2层互通VPN（第4节）的方法，因为OAM数据包不是IP帧，因此无法通过此类第2层VPN传输。
When a PE is configured with all the required information for a CE, it advertises to other PEs the fact that it is participating in a VPN via BGP messages, as per [RFC4761], Section 3. BGP was chosen as the means for exchanging L2VPN information for two reasons: it offers mechanisms for both auto-discovery and signaling, and it allows for operational convergence, as explained in Section 1. A bonus for using BGP is a robust inter-AS solution for L2VPNs.
根据[RFC4761]第3节的规定，当一个PE配置了CE所需的所有信息时，它会通过BGP消息向其他PE通告它正在参与VPN的事实。选择BGP作为交换L2VPN信息的手段有两个原因：它提供了自动发现和信令机制，并允许运营融合，如第1节所述。使用BGP的一个好处是为L2VPN提供了一个健壮的inter-AS解决方案。
There are two modifications to the formatting of messages. The first is that the set of Encaps Types carried in the L2-info extended community has been expanded to include those from Table 1. The value of the Encaps Type field identifies the Layer 2 encapsulation, e.g., ATM, Frame Relay, etc.
消息的格式有两种修改。首先，L2信息扩展社区中包含的一组封装类型已经扩展到包括表1中的类型。Encaps Type字段的值标识第2层封装，例如ATM、帧中继等。
+-----------+-------------------------------------------+-----------+
| Encaps | Description | Reference |
| Type | | |
+-----------+-------------------------------------------+-----------+
| 0 | Reserved | - |
| | | |
| 1 | Frame Relay | RFC 4446 |
| | | |
| 2 | ATM AAL5 SDU VCC transport | RFC 4446 |
| | | |
| 3 | ATM transparent cell transport | RFC 4816 |
| | | |
| 4 | Ethernet (VLAN) Tagged Mode | RFC 4448 |
| | | |
| 5 | Ethernet Raw Mode | RFC 4448 |
| | | |
| 6 | Cisco HDLC | RFC 4618 |
| | | |
| 7 | PPP | RFC 4618 |
| | | |
| 8 | SONET/SDH Circuit Emulation Service | RFC 4842 |
| | | |
| 9 | ATM n-to-one VCC cell transport | RFC 4717 |
| | | |
| 10 | ATM n-to-one VPC cell transport | RFC 4717 |
| | | |
| 11 | IP Layer 2 Transport | RFC 3032 |
| | | |
| 15 | Frame Relay Port mode | RFC 4619 |
| | | |
| 17 | Structure-agnostic E1 over packet | RFC 4553 |
| | | |
| 18 | Structure-agnostic T1 (DS1) over packet | RFC 4553 |
| | | |
| 19 | VPLS | RFC 4761 |
| | | |
| 20 | Structure-agnostic T3 (DS3) over packet | RFC 4553 |
| | | |
| 21 | Nx64kbit/s Basic Service using | RFC 5086 |
| | Structure-aware | |
| | | |
| 25 | Frame Relay DLCI | RFC 4619 |
| | | |
| 40 | Structure-agnostic E3 over packet | RFC 4553 |
| | | |
| 41 (1) | Octet-aligned payload for | RFC 4553 |
| | Structure-agnostic DS1 circuits | |
| | | |
+-----------+-------------------------------------------+-----------+
| Encaps | Description | Reference |
| Type | | |
+-----------+-------------------------------------------+-----------+
| 0 | Reserved | - |
| | | |
| 1 | Frame Relay | RFC 4446 |
| | | |
| 2 | ATM AAL5 SDU VCC transport | RFC 4446 |
| | | |
| 3 | ATM transparent cell transport | RFC 4816 |
| | | |
| 4 | Ethernet (VLAN) Tagged Mode | RFC 4448 |
| | | |
| 5 | Ethernet Raw Mode | RFC 4448 |
| | | |
| 6 | Cisco HDLC | RFC 4618 |
| | | |
| 7 | PPP | RFC 4618 |
| | | |
| 8 | SONET/SDH Circuit Emulation Service | RFC 4842 |
| | | |
| 9 | ATM n-to-one VCC cell transport | RFC 4717 |
| | | |
| 10 | ATM n-to-one VPC cell transport | RFC 4717 |
| | | |
| 11 | IP Layer 2 Transport | RFC 3032 |
| | | |
| 15 | Frame Relay Port mode | RFC 4619 |
| | | |
| 17 | Structure-agnostic E1 over packet | RFC 4553 |
| | | |
| 18 | Structure-agnostic T1 (DS1) over packet | RFC 4553 |
| | | |
| 19 | VPLS | RFC 4761 |
| | | |
| 20 | Structure-agnostic T3 (DS3) over packet | RFC 4553 |
| | | |
| 21 | Nx64kbit/s Basic Service using | RFC 5086 |
| | Structure-aware | |
| | | |
| 25 | Frame Relay DLCI | RFC 4619 |
| | | |
| 40 | Structure-agnostic E3 over packet | RFC 4553 |
| | | |
| 41 (1) | Octet-aligned payload for | RFC 4553 |
| | Structure-agnostic DS1 circuits | |
| | | |
| 42 (2) | E1 Nx64kbit/s with CAS using | RFC 5086 |
| | Structure-aware | |
| | | |
| 43 | DS1 (ESF) Nx64kbit/s with CAS using | RFC 5086 |
| | Structure-aware | |
| | | |
| 44 | DS1 (SF) Nx64kbit/s with CAS using | RFC 5086 |
| | Structure-aware | |
+-----------+-------------------------------------------+-----------+
| 42 (2) | E1 Nx64kbit/s with CAS using | RFC 5086 |
| | Structure-aware | |
| | | |
| 43 | DS1 (ESF) Nx64kbit/s with CAS using | RFC 5086 |
| | Structure-aware | |
| | | |
| 44 | DS1 (SF) Nx64kbit/s with CAS using | RFC 5086 |
| | Structure-aware | |
+-----------+-------------------------------------------+-----------+
Table 1: Encaps Types
表1：包裹类型
Note (1): Allocation of a separate code point for Encaps Type eliminates the need for Time Division Multiplexer (TDM) payload size.
注（1）：为Encaps类型分配单独的代码点消除了时分复用器（TDM）有效负载大小的需要。
Note (2): Having separate code points for Encaps Types 42-44 allows specifying the trunk framing (i.e., E1, T1 ESF, or T1 SF) with Channel Associated Signaling (CAS).
注（2）：对于42-44类型的封装具有单独的代码点允许使用信道相关信令（CAS）指定中继帧（即E1、T1 ESF或T1 SF）。
The second is the introduction of TLVs (Type-Length-Value triplets) in the VPLS NLRI (Network Layer Reachability Information). L2VPN TLVs can be added to extend the information carried in the NLRI, using the format shown in Figure 2. In L2VPN TLVs, Type is 1 octet, and Length is 2 octets and represents the size of the Value field in bits. L2VPN TLVs, if present, occur as the last element of a VPLS NLRI. The length of the NLRI includes the total length of the TLVs, including their headers.
第二个是在VPLS NLRI（网络层可达性信息）中引入TLV（类型-长度-值三元组）。可以使用图2所示的格式添加L2VPN TLV以扩展NLRI中携带的信息。在L2VPN TLV中，类型为1个八位字节，长度为2个八位字节，以位表示值字段的大小。L2VPN TLV（如果存在）作为VPLS NLRI的最后一个元素出现。NLRI的长度包括TLV的总长度，包括其标头。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (continued, if needed) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (continued, if needed) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of TLVs
图2：TLV的格式
This sub-TLV carries the status of an L2VPN PVC between a pair of PEs. Note that an L2VPN PVC is bidirectional, composed of two simplex connections going in opposite directions. A simplex connection consists of three segments: 1) the local access circuit between the source CE and the ingress PE, 2) the tunnel Label Switched Path (LSP) between the ingress and egress PEs, and 3) the access circuit between the egress PE and the destination CE.
此子TLV在一对PE之间承载L2VPN PVC的状态。请注意，L2VPN PVC是双向的，由两个方向相反的单工连接组成。单工连接包括三个部分：1）源CE和入口PE之间的本地接入电路，2）入口和出口PE之间的隧道标签交换路径（LSP），以及3）出口PE和目标CE之间的接入电路。
To monitor the status of a PVC, a PE needs to monitor the status of both simplex connections. Since it knows the status of its access circuit and the status of the tunnel towards the remote PE, it can inform the remote PE of these two. Similarly, the remote PE can inform the status of its access circuit to its local CE and the status of the tunnel to the first PE. Combining the local and the remote information, a PE can determine the status of a PVC.
为了监控PVC的状态，PE需要监控两个单工连接的状态。因为它知道其接入电路的状态和通向远程PE的隧道的状态，所以它可以将这两种情况通知远程PE。类似地，远程PE可以向其本地CE通知其接入电路的状态，并向第一PE通知隧道的状态。结合本地和远程信息，PE可以确定PVC的状态。
The basic unit of advertisement in L2VPN for a given CE is a label block. Each label within a label block corresponds to a PVC on the CE. The local status information for all PVCs corresponding to a label block is advertised along with the NLRI for the label block using the status vector TLV. The Type field of this TLV is 1. The Length field of the TLV specifies the length of the value field in bits. The Value field of this TLV is a bit-vector, each bit of which indicates the status of the PVC associated with the corresponding label in the label block. Bit value 0 corresponds to the PVC associated with the first label in the label block and indicates that the local circuit and the tunnel LSP to the remote PE is up, while a value of 1 indicates that either or both of them are down. The Value field is padded to the nearest octet boundary.
L2VPN中给定CE的广告的基本单元是标签块。标签块内的每个标签对应于CE上的PVC。与标签块对应的所有PVC的本地状态信息与使用状态向量TLV的标签块的NLRI一起发布。此TLV的类型字段为1。TLV的长度字段以位为单位指定值字段的长度。该TLV的值字段是位向量，其每一位表示与标签块中相应标签相关联的PVC的状态。位值0对应于与标签块中的第一个标签相关联的PVC，表示本地电路和到远程PE的隧道LSP向上，而值1表示其中一个或两个向下。值字段填充到最近的八位字节边界。
A PE can determine the status of a PVC from one of its CEs to a remote CE as follows. Say PE A has CE n in VPN X, and PE A gets an advertisement from PE B for remote CE m also in VPN X; this advertisement includes a label block and a circuit status vector. To determine which label to use for CE m, PE A must determine the index corresponding to CE m in the label block that PE B advertised. The status of the PVC between CE n and CE m can be obtained by looking at the bit in the circuit status vector corresponding to this index.
PE可以确定PVC从其一个CE到远程CE的状态，如下所示。假设PE A在vpnx中具有CE n，并且PE A从PE B获得也在vpnx中的远程CE m的广告；该广告包括标签块和电路状态向量。要确定用于CE m的标签，PE A必须确定PE B播发的标签块中对应于CE m的索引。通过查看与该索引对应的电路状态向量中的位，可以获得CE n和CE m之间的PVC的状态。
+----------+-----------------------+
| TLV Type | Description |
+----------+-----------------------+
| 1 | Circuit Status Vector |
+----------+-----------------------+
+----------+-----------------------+
| TLV Type | Description |
+----------+-----------------------+
| 1 | Circuit Status Vector |
+----------+-----------------------+
Table 2: TLV Types
表2：TLV类型
In the above, we assumed for simplicity that the VPN was a full mesh. To allow for more general VPN topologies, a mechanism based on filtering of BGP extended communities can be used.
在上面，为了简单起见，我们假设VPN是一个完整的网格。为了允许更通用的VPN拓扑，可以使用基于BGP扩展社区过滤的机制。
As defined so far in this document, all CE-PE connections for a given Layer 2 VPN must use the same Layer 2 encapsulation, e.g., they must all be Frame Relay. This is often a burdensome restriction. One answer is to use an existing Layer 2 interworking mechanism, for example, Frame Relay-ATM interworking.
正如本文档中迄今为止所定义的，给定第2层VPN的所有CE-PE连接必须使用相同的第2层封装，例如，它们都必须是帧中继。这通常是一项繁重的限制。一个答案是使用现有的第2层互通机制，例如帧中继ATM互通。
In this document, we take a different approach: we postulate that the network Layer is IP and base Layer 2 interworking on that. Thus, one can choose between pure Layer 2 VPNs, with a stringent Layer 2 restriction but with Layer 3 independence, or Layer 2 interworking VPNs, where there is no restriction on Layer 2, but Layer 3 must be IP. Of course, a PE may choose to implement Frame Relay-ATM interworking. For example, an ATM Layer 2 VPN could have some CEs connect via Frame Relay links, if their PE could translate Frame Relay to ATM transparently to the rest of the VPN. This would be private to the CE-PE connection, and such a course is outside the scope of this document.
在本文档中，我们采用了一种不同的方法：我们假设网络层是IP，基础层2在此基础上进行交互。因此，您可以选择具有严格的第2层限制但具有第3层独立性的纯第2层VPN，或对第2层没有限制但第3层必须为IP的第2层互通VPN。当然，PE可以选择实现帧中继ATM互通。例如，如果ATM第2层VPN的PE可以将帧中继透明地转换为ATM，则其某些CE可以通过帧中继链路进行连接。这将是CE-PE连接的私有内容，此类课程不在本文件范围内。
For Layer 2 interworking as defined here, when an IP packet arrives at a PE, its Layer 2 address is noted, then all Layer 2 overhead is stripped, leaving just the IP packet. Next, a VPN label is added, and the packet is encapsulated in the PE-PE tunnel (as required by the tunnel technology). Finally, the packet is forwarded. Note that the forwarding decision is made on the basis of the Layer 2 information, not the IP header. At the egress, the VPN label determines to which CE the packet must be sent and over which virtual circuit; from this, the egress PE can also determine the Layer 2 encapsulation to place on the packet once the VPN label is stripped.
对于此处定义的第2层互通，当IP数据包到达PE时，记录其第2层地址，然后剥离所有第2层开销，只留下IP数据包。接下来，添加VPN标签，并将数据包封装在PE-PE隧道中（根据隧道技术的要求）。最后，数据包被转发。请注意，转发决定是基于第2层信息而不是IP报头做出的。在出口处，VPN标签确定分组必须发送到哪个CE以及通过哪个虚拟电路；由此，出口PE还可以确定一旦剥离VPN标签就要放置在分组上的第2层封装。
An added benefit of restricting interworking to IP only as the Layer 3 technology is that the provider's network can provide IP Diffserv or any other IP-based QoS mechanism to the L2VPN customer. The ingress PE can set up IP/TCP/UDP-based classifiers to do Diffserv marking and other functions like policing and shaping on the L2 circuits of the VPN customer. Note the division of labor: the CE determines the destination CE and encodes that in the Layer 2 address. The ingress PE thus determines the egress PE and VPN label based on the Layer 2 address supplied by the CE, but the ingress PE can choose the tunnel to reach the egress PE (in the case that there are different tunnels for each CoS/Diffserv code point) or the CoS bits to place in the tunnel (in the case where a single tunnel carries multiple CoS/Diffserv code points) based on its own classification of the packet.
作为第3层技术，将互通限制为IP的另一个好处是，提供商的网络可以向L2VPN客户提供IP区分服务或任何其他基于IP的QoS机制。ingress PE可以设置基于IP/TCP/UDP的分类器，以便在VPN客户的L2电路上执行区分服务标记和其他功能，如监控和整形。注意分工：CE确定目标CE并在第2层地址中对其进行编码。因此，入口PE基于CE提供的第2层地址确定出口PE和VPN标签，但是入口PE可以选择到达出口PE的隧道（在每个CoS/Diffserv码点存在不同隧道的情况下）或放置在隧道中的CoS比特（在单个隧道承载多个CoS/Diffserv码点的情况下）基于其自身的分组分类。
When a packet arrives at a PE from a CE in a Layer 2 VPN, the Layer 2 address of the packet identifies to which remote attachment circuit (and thus remote CE) the packet is destined. The procedure outlined above installs a route that maps the Layer 2 address to a tunnel (which identifies the PE to which the destination CE is attached) and a VPN label (which identifies the destination AC). If the egress PE is the same as the ingress PE, no tunnel or VPN label is needed.
当分组从第2层VPN中的CE到达PE时，分组的第2层地址标识分组的目的地是哪个远程连接电路（从而是远程CE）。上面概述的过程安装了一个路由，该路由将第2层地址映射到一个隧道（用于标识目标CE连接到的PE）和一个VPN标签（用于标识目标AC）。如果出口PE与入口PE相同，则不需要隧道或VPN标签。
The packet may then be modified (depending on the Layer 2 encapsulation). In case of IP-only Layer 2 interworking, the Layer 2 header is completely stripped off up to the IP header. Then, a VPN label and tunnel encapsulation are added as specified by the route described above, and the packet is sent to the egress PE.
然后可以修改分组（取决于第2层封装）。在仅限IP的第2层互通的情况下，第2层报头完全剥离到IP报头。然后，按照上述路由的规定添加VPN标签和隧道封装，并且将分组发送到出口PE。
If the egress PE is the same as the ingress, the packet "arrives" with no labels. Otherwise, the packet arrives with the VPN label, which is used to determine which CE is the destination CE. The packet is restored to a fully formed Layer 2 packet and then sent to the CE.
如果出口PE与入口PE相同，则数据包“到达”时没有标签。否则，数据包到达时带有VPN标签，该标签用于确定哪个CE是目标CE。该分组被恢复为完全形成的第2层分组，然后被发送到CE。
This document requires that the Layer 2 MTU configured on all the access circuits connecting CEs to PEs in an L2VPN be the same. This can be ensured by passing the configured Layer 2 MTU in the Layer2- info extended community when advertising L2VPN label blocks. On receiving an L2VPN label block from remote PEs in a VPN, the MTU value carried in the Layer2-info extended community should be compared against the configured value for the VPN. If they don't match, then the label block should be ignored.
本文件要求在L2VPN中连接CEs和PEs的所有接入电路上配置的第2层MTU相同。在发布L2VPN标签块时，可通过在Layer2-info扩展社区中传递配置的Layer2 MTU来确保这一点。从VPN中的远程PE接收L2VPN标签块时，应将Layer2信息扩展社区中携带的MTU值与VPN的配置值进行比较。如果它们不匹配，则应忽略标签块。
The MTU on the Layer 2 access links MUST be chosen such that the size of the L2 frames plus the L2VPN header does not exceed the MTU of the SP network. Layer 2 frames that exceed the MTU after encapsulation MUST be dropped. For the case of IP-only Layer 2 interworking, the IP MTU on the Layer 2 access link must be chosen such that the size of the IP packet and the L2VPN header does not exceed the MTU of the SP network.
必须选择第2层访问链路上的MTU，以便L2帧加上L2VPN报头的大小不超过SP网络的MTU。封装后超过MTU的第2层帧必须丢弃。对于仅限IP的第2层互通，必须选择第2层接入链路上的IP MTU，以便IP数据包和L2VPN报头的大小不超过SP网络的MTU。
The modification to the Layer 2 frame depends on the Layer 2 type. This document requires that the encapsulation methods used in transporting Layer 2 frames over tunnels be the same as described in [RFC4448], [RFC4618], [RFC4619], and [RFC4717], except in the case of IP-only Layer 2 Interworking, which is described next.
对第2层框架的修改取决于第2层类型。本文件要求在隧道上传输第2层帧时使用的封装方法与[RFC4448]、[RFC4618]、[RFC4619]和[RFC4717]中所述的相同，但仅在IP层2互通的情况下使用的封装方法除外，下文将对此进行描述。
+-----------------------------------+
| PSN Transport | VPN | IP | VPN label is the
| Header | Label | Packet | demultiplexing field
+-----------------------------------+
+-----------------------------------+
| PSN Transport | VPN | IP | VPN label is the
| Header | Label | Packet | demultiplexing field
+-----------------------------------+
Figure 3: Format of IP-Only Layer 2 Interworking Packet
图3：仅限IP的第2层互通数据包的格式
At the ingress PE, an L2 frame's L2 header is completely stripped off and is carried over as an IP packet within the SP network (Figure 3). The forwarding decision is still based on the L2 address of the incoming L2 frame. At the egress PE, the IP packet is encapsulated back in an L2 frame and transported over to the destination CE. The forwarding decision at the egress PE is based on the VPN label as before. The L2 technology between egress PE and CE is independent of the L2 technology between ingress PE and CE.
在入口PE处，L2帧的L2报头被完全剥离，并作为IP数据包在SP网络中传输（图3）。转发决定仍然基于传入L2帧的L2地址。在出口PE处，IP分组被封装回L2帧中并传输到目的地CE。出口PE处的转发决策如前所述基于VPN标签。出口PE和CE之间的L2技术独立于入口PE和CE之间的L2技术。
RFC 4761 [RFC4761], on which this document is based, has a detailed discussion of security considerations. As in RFC 4761, the focus here is the privacy of customer VPN data (as opposed to confidentiality, integrity, or authentication of said data); to achieve the latter, one can use the methods suggested in RFC 4761. The techniques described in RFC 4761 for securing the control plane and protecting the forwarding path apply equally to L2VPNs, as do the remarks regarding multi-AS operation. The mitigation strategies and the analogies with RFC 4364 [RFC4364] also apply here.
本文件所依据的RFC 4761[RFC4761]详细讨论了安全注意事项。与RFC 4761一样，此处的重点是客户VPN数据的隐私（与所述数据的机密性、完整性或认证相反）；为了实现后者，可以使用RFC 4761中建议的方法。RFC 4761中描述的用于保护控制平面和保护转发路径的技术同样适用于L2VPN，关于多as操作的说明也是如此。缓解策略和与RFC 4364[RFC4364]的类比也适用于此。
RFC 4761 perhaps should have discussed Denial-of-Service attacks based on the fact that VPLS PEs have to learn Media Access Control (MAC) addresses and replicate packets (for flooding and multicast). However, those considerations don't apply here, as neither of those actions are required of PEs implementing the procedures in this document.
RFC 4761可能应该讨论拒绝服务攻击，因为VPLS PE必须了解媒体访问控制（MAC）地址并复制数据包（用于泛洪和多播）。但是，这些注意事项不适用于本文件，因为PEs实施本文件中的程序不需要这些措施。
IANA has created two new registries: the first is for the one-octet Encaps Type field of the L2-info extended community. The name of the registry is "BGP Layer 2 Encapsulation Types"; the values already allocated are in Table 1 of Section 3. The allocation policy for new entries up to and including value 127 is "Expert Review" [RFC5226]. The allocation policy for values 128 through 251 is "First Come First Served". The values from 252 through 255 are for "Experimental Use".
IANA已经创建了两个新的注册表：第一个是L2信息扩展社区的“一个八位字节的封装类型”字段。注册表名称为“BGP第2层封装类型”；已分配的值见第3节表1。小于等于127的新条目的分配政策为“专家评审”[RFC5226]。值128到251的分配策略为“先到先得”。252到255之间的值用于“实验用途”。
The second registry is for the one-octet Type field of the TLVs of the VPLS NLRI. The name of the registry is "BGP L2 TLV Types"; the sole allocated value is in Table 2 of Section 3. The allocation policy for new entries up to and including value 127 is "Expert Review". The allocation policy for values 128 through 251 is "First Come First Served". The values from 252 through 255 are for "Experimental Use".
第二个注册表用于VPLS NLRI的TLV的一个八位组类型字段。注册表名称为“BGP L2 TLV类型”；唯一的分配值见第3节表2。对于小于等于127的新条目，分配政策为“专家评审”。值128到251的分配策略为“先到先得”。252到255之间的值用于“实验用途”。
The authors would like to thank Chaitanya Kodeboyina, Dennis Ferguson, Der-Hwa Gan, Dave Katz, Nischal Sheth, John Stewart, and Paul Traina for the enlightening discussions that helped shape the ideas presented here. The authors also thank Ross Callon for his valuable comments.
作者要感谢柴坦尼亚·科德博伊纳、丹尼斯·弗格森、德华·甘、戴夫·卡茨、尼查尔·谢斯、约翰·斯图尔特和保罗·特拉纳，感谢他们进行了富有启发性的讨论，帮助形成了本文中提出的观点。作者还感谢Ross Callon的宝贵评论。
The idea of using extended communities for more general connectivity of a Layer 2 VPN was a contribution by Yakov Rekhter, who also gave many useful comments on the text. Many thanks to him.
Yakov Rekhter提出了将扩展社区用于第2层VPN的更通用连接的想法，他还对文本提出了许多有用的意见。非常感谢他。
The following individuals contributed to this document.
以下个人对本文件作出了贡献。
Manoj Leelanivas, Juniper Networks Quaizar Vohra, Juniper Networks Javier Achirica, Consultant Ronald Bonica, Juniper Networks Dave Cooper, Global Crossing Chris Liljenstolpe, Telstra Eduard Metz, KPN Dutch Telecom Hamid Ould-Brahim, Nortel Chandramouli Sargor Himanshu Shah, Ciena Vijay Srinivasan Zhaohui Zhang, Juniper Networks
Manoj Leelanivas、Juniper Networks Quaizar Vohra、Juniper Networks Javier Achirica、顾问Ronald Bonica、Juniper Networks Dave Cooper、环球穿越Chris Liljenstolpe、Telstra Eduard Metz、KPN荷兰电信Hamid Ould Brahim、Nortel Chandramouli Sargor Himanshu Shah、Ciena Vijay Srinivasan Zhaohi、Juniper Networks
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[RFC4360]Sangli，S.，Tappan，D.和Y.Rekhter，“BGP扩展社区属性”，RFC 4360，2006年2月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446]Martini，L.，“伪线边到边仿真（PWE3）的IANA分配”，BCP 116，RFC 4446，2006年4月。
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[RFC4448]Martini，L.，Rosen，E.，El Aawar，N.，和G.Heron，“通过MPLS网络传输以太网的封装方法”，RFC 4448，2006年4月。
[RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, September 2006.
[RFC4618]Martini，L.，Rosen，E.，Heron，G.，和A.Malis，“通过MPLS网络传输PPP/高级数据链路控制（HDLC）的封装方法”，RFC 4618，2006年9月。
[RFC4619] Martini, L., Kawa, C., and A. Malis, "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", RFC 4619, September 2006.
[RFC4619]Martini，L.，Kawa，C.，和A.Malis，“多协议标签交换（MPLS）网络上帧中继传输的封装方法”，RFC 4619，2006年9月。
[RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., Brayley, J., and G. Koleyni, "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", RFC 4717, December 2006.
[RFC4717]Martini，L.，Jayakumar，J.，Bocci，M.，El-Aawar，N.，Brayley，J.，和G.Koleyni，“MPLS网络上异步传输模式（ATM）传输的封装方法”，RFC 47172006年12月。
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.
[RFC4761]Kompella，K.和Y.Rekhter，“使用BGP进行自动发现和信令的虚拟专用LAN服务（VPLS）”，RFC 4761，2007年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[Kosiur] Kosiur, D., "Building and Managing Virtual Private Networks", Wiley Computer Publishing, 1998.
[Kosiur]Kosiur，D.，“构建和管理虚拟专用网络”，威利计算机出版社，1998年。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]Bryant，S.和P.Pate，“伪线仿真边到边（PWE3）架构”，RFC 39852005年3月。
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]Martini，L.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006.
[RFC4684]Marques，P.，Bonica，R.，Fang，L.，Martini，L.，Raszuk，R.，Patel，K.，和J.Guichard，“边界网关协议/多协议标签交换（BGP/MPLS）互联网协议（IP）虚拟专用网络（VPN）的受限路由分布”，RFC 46842006年11月。
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007.
[RFC4762]Lasserre，M.和V.Kompella，“使用标签分发协议（LDP）信令的虚拟专用LAN服务（VPLS）”，RFC 4762，2007年1月。
[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.
[RFC6074]Rosen，E.，Davie，B.，Radoaca，V.，和W.Luo，“第二层虚拟专用网络（L2VPN）中的资源调配、自动发现和信令”，RFC 6074，2011年1月。
Authors' Addresses
作者地址
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
Kireeti Kompella Juniper Networks 1194 N.Mathilda Ave.Sunnyvale，加利福尼亚州94089
EMail: kireeti@juniper.net
EMail: kireeti@juniper.net
Bhupesh Kothari Cisco Systems 3750 Cisco Way San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市思科路3750号，邮编95134
EMail: bhupesh@cisco.com
EMail: bhupesh@cisco.com
Rao Cherukuri Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
Rao Cherukuri Juniper Networks 1194 N.Mathilda Ave.Sunnyvale，加利福尼亚州94089
EMail: cherukuri@juniper.net
EMail: cherukuri@juniper.net