Network Working Group W. Augustyn, Ed.
Request for Comments: 4665 Y. Serbest, Ed.
Category: Informational AT&T
September 2006
Network Working Group W. Augustyn, Ed.
Request for Comments: 4665 Y. Serbest, Ed.
Category: Informational AT&T
September 2006
Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks
第2层提供商提供的虚拟专用网络的服务要求
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document provides requirements for Layer 2 Provider-Provisioned Virtual Private Networks (L2VPNs). It first provides taxonomy and terminology and states generic and general service requirements. It covers point-to-point VPNs, referred to as Virtual Private Wire Service (VPWS), as well as multipoint-to-multipoint VPNs, also known as Virtual Private LAN Service (VPLS). Detailed requirements are expressed from both a customer as well as a service provider perspectives.
本文档提供了第2层提供商提供的虚拟专用网络（L2VPN）的要求。它首先提供分类法和术语，并说明通用和一般服务要求。它包括点对点VPN，称为虚拟专用线服务（VPWS），以及多点对多点VPN，也称为虚拟专用局域网服务（VPLS）。从客户和服务提供商的角度表达了详细的需求。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Scope of This Document .....................................4
1.2. Outline ....................................................5
2. Conventions used in this document ...............................5
3. Contributing Authors ............................................5
4. Definitions and Taxonomy ........................................5
4.1. Definitions ................................................5
4.2. Taxonomy of L2VPN Types ....................................6
4.3. VPWS .......................................................6
4.4. VPLS .......................................................7
5. Service Requirements Common to Customers and Service Providers ..7
5.1. Scope of emulation .........................................8
5.2. Traffic Types ..............................................8
5.3. Topology ...................................................8
5.4. Isolated Exchange of Data and Forwarding Information .......9
5.5. Security ...................................................9
5.5.1. User Data Security .................................10
5.5.2. Access Control .....................................10
5.6. Addressing ................................................11
5.7. Quality of Service ........................................11
5.7.1. QoS Standards ......................................11
5.7.2. Service Models .....................................11
5.8. Service Level Specifications ..............................12
5.9. Protection and Restoration ................................12
5.10. CE-to-PE and PE-to-PE Link Requirements ..................12
5.11. Management ...............................................12
5.12. Interoperability .........................................12
5.13. Inter-working ............................................13
6. Customer Requirements ..........................................13
6.1. Service Provider Independence .............................13
6.2. Layer 3 Support ...........................................13
6.3. Quality of Service and Traffic Parameters .................14
6.4. Service Level Specification ...............................14
6.5. Security ..................................................14
6.5.1. Isolation ..........................................14
6.5.2. Access Control .....................................14
6.5.3. Value-Added Security Services ......................15
6.6. Network Access ............................................15
6.6.1. Physical/Link Layer Technology .....................15
6.6.2. Access Connectivity ................................15
6.7. Customer Traffic ..........................................17
6.7.1. Unicast, Unknown Unicast, Multicast, and
Broadcast forwarding ...............................17
6.7.2. Packet Re-ordering .................................17
6.7.3. Minimum MTU ........................................17
6.7.4. End-point VLAN Tag Translation .....................18
1. Introduction ....................................................4
1.1. Scope of This Document .....................................4
1.2. Outline ....................................................5
2. Conventions used in this document ...............................5
3. Contributing Authors ............................................5
4. Definitions and Taxonomy ........................................5
4.1. Definitions ................................................5
4.2. Taxonomy of L2VPN Types ....................................6
4.3. VPWS .......................................................6
4.4. VPLS .......................................................7
5. Service Requirements Common to Customers and Service Providers ..7
5.1. Scope of emulation .........................................8
5.2. Traffic Types ..............................................8
5.3. Topology ...................................................8
5.4. Isolated Exchange of Data and Forwarding Information .......9
5.5. Security ...................................................9
5.5.1. User Data Security .................................10
5.5.2. Access Control .....................................10
5.6. Addressing ................................................11
5.7. Quality of Service ........................................11
5.7.1. QoS Standards ......................................11
5.7.2. Service Models .....................................11
5.8. Service Level Specifications ..............................12
5.9. Protection and Restoration ................................12
5.10. CE-to-PE and PE-to-PE Link Requirements ..................12
5.11. Management ...............................................12
5.12. Interoperability .........................................12
5.13. Inter-working ............................................13
6. Customer Requirements ..........................................13
6.1. Service Provider Independence .............................13
6.2. Layer 3 Support ...........................................13
6.3. Quality of Service and Traffic Parameters .................14
6.4. Service Level Specification ...............................14
6.5. Security ..................................................14
6.5.1. Isolation ..........................................14
6.5.2. Access Control .....................................14
6.5.3. Value-Added Security Services ......................15
6.6. Network Access ............................................15
6.6.1. Physical/Link Layer Technology .....................15
6.6.2. Access Connectivity ................................15
6.7. Customer Traffic ..........................................17
6.7.1. Unicast, Unknown Unicast, Multicast, and
Broadcast forwarding ...............................17
6.7.2. Packet Re-ordering .................................17
6.7.3. Minimum MTU ........................................17
6.7.4. End-point VLAN Tag Translation .....................18
6.7.5. Transparency .......................................18
6.8. Support for Layer 2 Control Protocols .....................18
6.9. CE Provisioning ...........................................19
7. Service Provider Network Requirements ..........................19
7.1. Scalability ...............................................19
7.1.1. Service Provider Capacity Sizing Projections .......19
7.1.2. Solution-Specific Metrics ..........................19
7.2. Identifiers ...............................................19
7.3. Discovering L2VPN Related Information .....................19
7.4. Quality of Service (QoS) ..................................20
7.5. Isolation of Traffic and Forwarding Information ...........20
7.6. Security ..................................................21
7.7. Inter-AS/SP L2VPNs ........................................22
7.7.1. Management .........................................22
7.7.2. Bandwidth and QoS Brokering ........................22
7.8. L2VPN Wholesale ...........................................23
7.9. Tunneling Requirements ....................................23
7.10. Support for Access Technologies ..........................23
7.11. Backbone Networks ........................................24
7.12. Network Resource Partitioning and Sharing Between
L2VPNs ...................................................24
7.13. Interoperability .........................................24
7.14. Testing ..................................................25
7.15. Support on Existing PEs ..................................25
8. Service Provider Management Requirements .......................26
9. Engineering Requirements .......................................26
9.1. Control Plane Requirements ................................26
9.2. Data Plane Requirements ...................................27
9.2.1. Encapsulation ......................................27
9.2.2. Responsiveness to Congestion .......................27
9.2.3. Broadcast Domain ...................................27
9.2.4. Virtual Switching Instance .........................27
9.2.5. MAC Address Learning ...............................27
10. Security Considerations .......................................28
11. Acknowledgements ..............................................28
12. References ....................................................29
12.1. Normative References .....................................29
12.2. Informative References ...................................29
6.7.5. Transparency .......................................18
6.8. Support for Layer 2 Control Protocols .....................18
6.9. CE Provisioning ...........................................19
7. Service Provider Network Requirements ..........................19
7.1. Scalability ...............................................19
7.1.1. Service Provider Capacity Sizing Projections .......19
7.1.2. Solution-Specific Metrics ..........................19
7.2. Identifiers ...............................................19
7.3. Discovering L2VPN Related Information .....................19
7.4. Quality of Service (QoS) ..................................20
7.5. Isolation of Traffic and Forwarding Information ...........20
7.6. Security ..................................................21
7.7. Inter-AS/SP L2VPNs ........................................22
7.7.1. Management .........................................22
7.7.2. Bandwidth and QoS Brokering ........................22
7.8. L2VPN Wholesale ...........................................23
7.9. Tunneling Requirements ....................................23
7.10. Support for Access Technologies ..........................23
7.11. Backbone Networks ........................................24
7.12. Network Resource Partitioning and Sharing Between
L2VPNs ...................................................24
7.13. Interoperability .........................................24
7.14. Testing ..................................................25
7.15. Support on Existing PEs ..................................25
8. Service Provider Management Requirements .......................26
9. Engineering Requirements .......................................26
9.1. Control Plane Requirements ................................26
9.2. Data Plane Requirements ...................................27
9.2.1. Encapsulation ......................................27
9.2.2. Responsiveness to Congestion .......................27
9.2.3. Broadcast Domain ...................................27
9.2.4. Virtual Switching Instance .........................27
9.2.5. MAC Address Learning ...............................27
10. Security Considerations .......................................28
11. Acknowledgements ..............................................28
12. References ....................................................29
12.1. Normative References .....................................29
12.2. Informative References ...................................29
This section describes the scope and outline of the document.
本节介绍了本文件的范围和概要。
This document provides requirements for provider-provisioned Layer 2 Virtual Private Networks (L2VPN). It identifies requirements that MAY apply to one or more individual approaches that a Service Provider (SP) may use for the provisioning of a Layer 2 VPN service. The content of this document makes use of the terminology defined in [RFC4026] and common components for deploying L2VPNs described in [RFC4664].
本文档提供了提供商提供的第2层虚拟专用网络（L2VPN）的要求。它确定了可能适用于服务提供商（SP）用于提供第2层VPN服务的一个或多个单独方法的要求。本文档内容使用了[RFC4026]中定义的术语和[RFC4664]中描述的用于部署L2VPN的通用组件。
The technical specifications to provide L2VPN services are outside the scope of this document. The framework document [RFC4664] and several other documents, which explain technical approaches providing L2VPN services, such as [VPLS_LDP], [VPLS_BGP], and [IPLS], are available to cover this aspect.
提供L2VPN服务的技术规范不在本文档范围内。框架文件[RFC4664]和其他几个文件解释了提供L2VPN服务的技术方法，如[VPLS_LDP]、[VPLS_BGP]和[IPLS]，可用于涵盖这一方面。
This document describes requirements for two types of L2VPNs: (1) Virtual Private Wire Service (VPWS), and (2) Virtual Private LAN Service (VPLS). The approach followed in this document distinguishes L2VPN types as to how the connectivity is provided (point-point or multipoint-multipoint), as detailed in [RFC4664].
本文档描述了两种类型的L2VPN的要求：（1）虚拟专用线服务（VPWS）和（2）虚拟专用局域网服务（VPLS）。本文档中采用的方法区分了L2VPN类型，以确定如何提供连接（点-点或多点-多点），详见[RFC4664]。
This document is intended as a "checklist" of requirements that will provide a consistent way to evaluate and document how well each individual approach satisfies specific requirements. The applicability statement document for each individual approach should document the results of this evaluation.
本文件旨在作为需求的“检查表”，提供一致的方法来评估和记录每种方法满足特定需求的程度。每种方法的适用性声明文件应记录评估结果。
In the context of provider-provisioned VPNs, there are two entities involved in operation of such services, the Provider and the Customer. The Provider engages in a binding agreement with the Customer as to the behavior of the service in a normal situation as well as in exceptional situations. Such agreement is known as Service Level Specification (SLS), which is part of the Service Level Agreement (SLA) established between the Provider and the Customer.
在提供商提供的VPN环境中，有两个实体参与此类服务的运营，即提供商和客户。供应商与客户就正常情况和特殊情况下的服务行为签订了具有约束力的协议。这种协议称为服务水平规范（SLS），它是提供商和客户之间建立的服务水平协议（SLA）的一部分。
A proper design of L2VPNs aids formulation of SLSes in that it provides means for proper separation between Customer Edge (CE) and Provider Edge (PE), allows proper execution of the SLS offer, and supports a flexible and rich set of capabilities.
L2VPN的正确设计有助于SLSE的制定，因为它提供了在客户边缘（CE）和提供商边缘（PE）之间进行适当分离的方法，允许正确执行SLS产品，并支持灵活而丰富的功能集。
This document provides requirements from both the Provider's and the Customer's point of view. It begins with common customer's and service provider's point of view, followed by a customer's
本文件从供应商和客户的角度提供了要求。它从普通客户和服务提供商的观点开始，然后是客户的观点
perspective, and concludes with specific needs of an SP. These requirements provide high-level L2VPN features expected by an SP in provisioning L2VPNs, which include SP requirements for security, privacy, manageability, interoperability, and scalability.
这些需求提供了SP在提供L2VPN时所期望的高级L2VPN功能，其中包括SP对安全性、隐私性、可管理性、互操作性和可扩展性的要求。
The outline of the rest of this document is as follows. Section 4 provides definitions and taxonomy. Section 5 provides common requirements that apply to both customer and SP, respectively. Section 6 states requirements from a customer perspective. Section 7 states network requirements from an SP perspective. Section 8 states SP management requirements. Section 9 describes the engineering requirements, particularly control and data plane requirements. Section 10 provides security considerations. Section 11 lists acknowledgements. Section 12 provides a list of references cited herein.
本文件其余部分概述如下。第4节提供了定义和分类。第5节提供了分别适用于客户和SP的通用要求。第6节从客户的角度阐述了要求。第7节从SP的角度阐述了网络要求。第8节说明了SP管理要求。第9节描述了工程要求，特别是控制和数据平面要求。第10节提供了安全考虑。第11节列出了确认。第12节提供了本文引用的参考文献列表。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document was the combined effort of several individuals. The following are the authors that contributed to this document:
这份文件是几个人共同努力的结果。以下是对本文件作出贡献的作者：
Waldemar Augustyn Marco Carugi Giles Heron Vach Kompella Marc Lasserre Pascal Menezes Hamid Ould-Brahim Tissa Senevirathne Yetik Serbest
沃尔德马尔·奥古斯丁·马可·卡鲁吉·吉尔斯·赫隆·科佩拉·马克·拉塞尔·帕斯卡尔·哈米德·乌尔德·布拉希姆·蒂萨·耶提克·塞尔维特是塞尔维亚人
The terminology used in this document is defined in [RFC4026]. The L2VPN framework document [RFC4664] further describes these concepts in the context of a reference model that defines layered service relationships between devices and one or more levels of tunnels.
本文件中使用的术语定义见[RFC4026]。L2VPN框架文档[RFC4664]在参考模型的上下文中进一步描述了这些概念，该参考模型定义了设备和一个或多个隧道级别之间的分层服务关系。
The requirements distinguish two major L2VPN models, a Virtual Private Wire Service (VPWS), and a Virtual Private LAN Service (VPLS).
这些要求区分了两种主要的L2VPN模型：虚拟专用线服务（VPWS）和虚拟专用局域网服务（VPLS）。
The following diagram shows an L2VPN reference model.
下图显示了L2VPN参考模型。
+-----+ +-----+
+ CE1 +--+ +---| CE2 |
+-----+ | ........................ | +-----+
L2VPN A | +----+ +----+ | L2VPN A
+--| PE |--- Service ---| PE |--+
+----+ Provider +----+
/ . Backbone . \ - /\-_
+-----+ / . | . \ / \ / \ +-----+
+ CE4 +--+ . | . +--\ Access \----| CE5 |
+-----+ . +----+ . | Network | +-----+
L2VPN B .........| PE |......... \ / L2VPN B
+----+ ^ -------
| |
| |
+-----+ |
| CE3 | +-- Logical switching instance
+-----+
L2VPN A
+-----+ +-----+
+ CE1 +--+ +---| CE2 |
+-----+ | ........................ | +-----+
L2VPN A | +----+ +----+ | L2VPN A
+--| PE |--- Service ---| PE |--+
+----+ Provider +----+
/ . Backbone . \ - /\-_
+-----+ / . | . \ / \ / \ +-----+
+ CE4 +--+ . | . +--\ Access \----| CE5 |
+-----+ . +----+ . | Network | +-----+
L2VPN B .........| PE |......... \ / L2VPN B
+----+ ^ -------
| |
| |
+-----+ |
| CE3 | +-- Logical switching instance
+-----+
L2VPN A
Figure 1. L2VPN Reference Model
图1。L2VPN参考模型
The PE devices provide a logical interconnect such that a pair of CE devices appears to be connected by a single logical Layer 2 circuit. PE devices act as Layer 2 circuit switches. Layer 2 circuits are then mapped onto tunnels in the SP network. These tunnels can either be specific to a particular VPWS, or be shared among several services. VPWS applies for all services, including Ethernet, ATM, Frame Relay, etc. In Figure 1, L2VPN B represents a VPWS case.
PE设备提供逻辑互连，使得一对CE设备似乎通过单个逻辑层2电路连接。PE设备充当第2层电路开关。然后将第2层电路映射到SP网络中的隧道。这些隧道可以特定于特定的VPW，也可以在多个服务之间共享。VPWS适用于所有服务，包括以太网、ATM、帧中继等。在图1中，L2VPN B表示一种VPWS情况。
Each PE device is responsible for allocating customer Layer 2 frames to the appropriate VPWS and for proper forwarding to the intended destinations.
每个PE设备负责将客户第2层帧分配给适当的VPW，并适当转发到预期目的地。
In case of VPLS, the PE devices provide a logical interconnect such that CE devices belonging to a specific VPLS appear to be connected by a single LAN. End-to-end VPLS consists of a bridge module and a LAN emulation module ([RFC4664]). A VPLS can contain a single VLAN or multiple VLANs ([IEEE_802.1Q]). A variation of this service is IPLS ([RFC4664]), which is limited to supporting only customer IP traffic.
在VPL的情况下，PE设备提供逻辑互连，使得属于特定VPL的CE设备似乎通过单个LAN连接。端到端VPLS由网桥模块和LAN仿真模块（[RFC4664]）组成。VPLS可以包含单个VLAN或多个VLAN（[IEEE_802.1Q]）。此服务的一个变体是IPLS（[RFC4664]），它仅限于支持客户IP流量。
In a VPLS, a customer site receives Layer 2 service from the SP. The PE is attached via an access connection to one or more CEs. The PE performs forwarding of user data packets based on information in the Layer 2 header, such as a MAC destination address. In Figure 1, L2VPN A represents a VPLS case.
在VPLS中，客户站点从SP接收第2层服务。PE通过接入连接连接到一个或多个CE。PE基于层2报头中的信息（例如MAC目的地地址）执行用户数据分组的转发。在图1中，L2VPN A表示一种VPLS情况。
The details of VPLS reference model, which we summarize here, can be found in [RFC4664]. In VPLS, the PE can be viewed as containing a Virtual Switching Instance (VSI) for each L2VPN that it serves. A CE device attaches, possibly through an access network, to a bridge module of a PE. Within the PE, the bridge module attaches, through an Emulated LAN Interface to an Emulated LAN. For each VPLS, there is an Emulated LAN instance. The Emulated LAN consists of VPLS Forwarder module (one per PE per VPLS service instance) connected by pseudo wires (PW), where the PWs may be traveling through Packet Switched Network (PSN) tunnels over a routed backbone. VSI is a logical entity that contains a VPLS forwarder module and part of the bridge module relevant to the VPLS service instance [RFC4664]. Hence, the VSI terminates PWs for interconnection with other VSIs and also terminates Attachment Circuits (ACs) (see [RFC3985] for definition) for accommodating CEs. A VSI includes the forwarding information base for an L2VPN [RFC4664] which is the set of information regarding how to forward Layer 2 frames received over the AC from the CE to VSIs in other PEs supporting the same L2VPN service (and/or to other ACs), and it contains information regarding how to forward Layer 2 frames received from PWs to ACs. Forwarding information bases can be populated dynamically (such as by source MAC address learning) or statically (e.g., by configuration). Each PE device is responsible for proper forwarding of the customer traffic to the appropriate destination(s) based on the forwarding information base of the corresponding VSI.
我们在此总结的VPLS参考模型的详细信息可在[RFC4664]中找到。在VPLS中，PE可以被视为包含其服务的每个L2VPN的虚拟交换实例（VSI）。CE设备可能通过接入网络连接到PE的网桥模块。在PE中，桥接模块通过模拟LAN接口连接到模拟LAN。对于每个VPLS，都有一个模拟LAN实例。模拟LAN由虚拟线（PW）连接的VPLS转发器模块（每个VPLS服务实例每个PE一个）组成，其中PW可能通过路由主干上的分组交换网络（PSN）隧道传输。VSI是一个逻辑实体，包含VPLS转发器模块和与VPLS服务实例相关的网桥模块的一部分[RFC4664]。因此，VSI终止PWs以与其他VSI互连，并终止连接电路（ACs）（定义见[RFC3985]）以容纳CE。VSI包括L2VPN的转发信息库[RFC4664]，该信息库是关于如何将通过AC从CE接收的第2层帧转发到支持相同L2VPN服务的其他PE中的VSI（和/或转发到其他ACs）的信息集，并且它包含关于如何将从PWs接收的第2层帧转发到ACs的信息。转发信息库可以动态（如通过源MAC地址学习）或静态（如通过配置）填充。每个PE设备负责根据相应VSI的转发信息库将客户流量正确转发到适当的目的地。
This section contains requirements that apply to both the customer and the provider, or that are of an otherwise general nature.
本节包含适用于客户和提供商的要求，或其他一般性质的要求。
L2VPN protocols SHOULD NOT interfere with existing Layer 2 protocols and standards of the Layer 2 network the customer is managing. If they impact customer Layer 2 protocols that are sent over the VPLS, then these impacts MUST be documented.
L2VPN协议不应干扰客户正在管理的第二层网络的现有第二层协议和标准。如果它们影响通过VPL发送的客户第2层协议，则必须记录这些影响。
Some possibly salient differences between VPLS and a real LAN are:
VPLS和真实LAN之间可能存在的一些显著差异是：
- The reliability may likely be less, i.e., the probability that a message broadcast over the VPLS is not seen by one of the bridge modules in PEs is higher than in a true Ethernet.
- 可靠性可能较低，即，PEs中的网桥模块之一看不到VPLS上广播的消息的概率高于真实以太网。
- VPLS frames can get duplicated if the PW sequencing option isn't turned on. The data frames on the PWs are sent in IP datagrams, and under certain failure scenarios, IP networks can duplicate packets. If the PW data transmission protocol does not ensure sequence of data packets, frames can be duplicated or received out of sequence. If the customer's Bridge Protocol Data Unit (BPDU) frames are sent as data packets, then BPDU frames can be duplicated or mis-sequenced, although this may not create any problems for Real-Time Streaming Protocol (RSTP).
- 如果未启用PW排序选项，VPLS帧可能会被复制。PWs上的数据帧以IP数据报的形式发送，在某些故障情况下，IP网络可以复制数据包。如果PW数据传输协议不能确保数据包的顺序，则帧可能会被复制或接收顺序错误。如果客户的网桥协议数据单元（BPDU）帧作为数据包发送，则BPDU帧可能被复制或错误排序，尽管这可能不会对实时流协议（RSTP）造成任何问题。
- Delayed delivery of packets (e.g., more than half a second), rather than dropping them, could have adverse effect on the performance of the service.
- 数据包的延迟交付（例如，超过半秒），而不是丢弃数据包，可能会对服务的性能产生不利影响。
- 802.3x Pause frames will not be transported over a VPLS, as the bridge module ([RFC4664]) in the PE terminates them.
- 802.3x暂停帧不会通过VPLS传输，因为PE中的网桥模块（[RFC4664]）会终止它们。
- Since the IPLS solution aims at transporting encapsulated traffic (rather than Layer 2 frames themselves), the IPLS solution is NOT REQUIRED to preserve the Layer 2 Header transparently from CE to CE. For example, Source MAC address will probably not be preserved by the IPLS solution.
- 由于IPLS解决方案旨在传输封装的通信量（而不是层2帧本身），因此不需要IPLS解决方案将层2报头从CE透明地保存到CE。例如，IPLS解决方案可能不会保留源MAC地址。
A VPLS MUST support unicast, multicast, and broadcast traffic. Support for efficient replication of broadcast and multicast traffic is highly desirable.
VPLS必须支持单播、多播和广播流量。支持广播和多播通信的高效复制是非常理想的。
A SP network may be realized using one or more network tunnel topologies to interconnect PEs, ranging from simple point-to-point to distributed hierarchical arrangements. The typical topologies include:
SP网络可以使用一个或多个网络隧道拓扑来互连PE，范围从简单的点到点到分布式分层排列。典型拓扑包括：
- Point-to-point - Point-to-multipoint, a.k.a. hub and spoke - Any-to-any, a.k.a. full mesh - Mixed, a.k.a. partial mesh - Hierarchical
- 点对点-点对多点，也称为中心辐射-任意对任意，也称为全网格-混合，也称为部分网格-分层
Regardless of the SP topology employed, the service to the customers MUST retain the connectivity type implied by the type of L2VPN. For example, a VPLS MUST allow multipoint-to-multipoint connectivity even if it is implemented with point-to-point circuits. This requirement does not imply that all traffic characteristics (such as bandwidth, QoS, delay, etc.) necessarily be the same between any two end points of an L2VPN. It is important to note that SLS requirements of a service have a bearing on the type of topology that can be used.
无论采用何种SP拓扑，为客户提供的服务都必须保留L2VPN类型所隐含的连接类型。例如，VPLS必须允许多点对多点连接，即使它是通过点对点电路实现的。此要求并不意味着L2VPN任意两个端点之间的所有流量特性（如带宽、QoS、延迟等）都必须相同。需要注意的是，服务的SLS需求与可使用的拓扑类型有关。
To the extent possible, an L2VPN service SHOULD be capable of crossing multiple administrative boundaries.
在可能的范围内，L2VPN服务应该能够跨越多个管理边界。
To the extent possible, the L2VPN services SHOULD be independent of access network technology.
L2VPN服务应尽可能独立于接入网技术。
L2VPN solutions SHALL define means that prevent CEs in an L2VPN from interaction with unauthorized entities.
L2VPN解决方案应定义防止L2VPN中的CE与未授权实体交互的方法。
L2VPN solutions SHALL avoid introducing undesired forwarding information that could corrupt the L2VPN forwarding information base.
L2VPN解决方案应避免引入可能损坏L2VPN转发信息库的不需要的转发信息。
A means to constrain or isolate the distribution of addressed data to only those VPLS sites determined either by MAC learning and/or configuration MUST be provided.
必须提供一种方法，将寻址数据的分发限制或隔离到仅由MAC学习和/或配置确定的VPLS站点。
The internal structure of an L2VPN SHOULD not be advertised or discoverable from outside that L2VPN.
L2VPN的内部结构不应在该L2VPN外部公布或发现。
A range of security features MUST be supported by the suite of L2VPN solutions. Each L2VPN solution MUST state which security features it supports and how such features can be configured on a per-customer basis.
L2VPN解决方案套件必须支持一系列安全功能。每个L2VPN解决方案必须说明它支持哪些安全功能，以及如何根据每个客户配置这些功能。
A number of security concerns arise in the setup and operation of an L2VPN, ranging from misconfigurations to attacks that can be launched on an L2VPN and can strain network resources such as memory space, forwarding information base table, bandwidth, and CPU processing.
在L2VPN的设置和操作过程中会出现许多安全问题，从错误配置到可在L2VPN上发起的攻击，这些攻击可能会占用网络资源，如内存空间、转发信息基表、带宽和CPU处理。
This section lists some potential security hazards that can result due to mis-configurations and/or malicious attacks. There MUST be methods available to protect against the following situations.
本节列出了由于错误配置和/或恶意攻击而可能导致的一些潜在安全危害。必须有针对以下情况的可用方法。
- Protocol attacks o Excessive protocol adjacency setup/teardown o Excessive protocol signaling/withdrawal
- 协议攻击o过度的协议邻接设置/拆卸o过度的协议信令/退出
- Resource Utilization o Forwarding plane replication (VPLS) o Looping (VPLS primarily) o MAC learning table size limit (VPLS)
- 资源利用率o转发平面复制（VPLS）o循环（主要是VPLS）o MAC学习表大小限制（VPLS）
- Unauthorized access o Unauthorized member of VPN o Incorrect customer interface o Incorrect service delimiting VLAN tag o Unauthorized access to PE
- 未经授权的访问o未经授权的VPN成员o不正确的客户接口o不正确的服务划分VLAN标记o未经授权的PE访问
- Tampering with signaling o Incorrect FEC signaling o Incorrect PW label assignment o Incorrect signaled VPN parameters (e.g., QoS, MTU, etc.)
- 篡改信令o错误的FEC信令o错误的PW标签分配o错误的VPN参数（例如，QoS、MTU等）
- Tampering with data forwarding o Incorrect MAC learning entry o Incorrect PW label o Incorrect AC identifier o Incorrect customer facing encapsulation o Incorrect PW encapsulation o Hijacking PWs using the wrong tunnel o Incorrect tunnel encapsulation
- 篡改数据转发o不正确的MAC学习条目o不正确的PW标签o不正确的AC标识符o不正确的面向客户的封装o不正确的PW封装o使用错误的隧道劫持PWs o不正确的隧道封装
An L2VPN solution MUST provide traffic separation between different L2VPNs.
L2VPN解决方案必须在不同的L2VPN之间提供流量分离。
In case of VPLS, VLAN Ids MAY be used as service delimiters. When used in this manner, they MUST be honored and traffic separation MUST be provided.
对于VPL，VLAN ID可用作服务分隔符。以这种方式使用时，必须遵守这些规定，并且必须提供交通隔离。
An L2VPN solution MAY also have the ability to activate the appropriate filtering capabilities upon request of a customer.
L2VPN解决方案还可以根据客户的请求激活适当的过滤功能。
An L2VPN solution MUST support overlapping addresses of different L2VPNs. For instance, customers MUST NOT be prevented from using the same MAC addresses with different L2VPNs. If a service provider uses VLANs as service delimiters, the L2VPN solution MUST ensure that VLAN Ids cannot overlap. If VLANs are not used as service delimiters, L2VPN solutions MAY allow VLAN Ids to overlap.
L2VPN解决方案必须支持不同L2VPN的重叠地址。例如，不能阻止客户使用具有不同L2VPN的相同MAC地址。如果服务提供商使用VLAN作为服务分隔符，L2VPN解决方案必须确保VLAN ID不能重叠。如果VLAN未用作服务分隔符，L2VPN解决方案可能允许VLAN ID重叠。
To the extent possible, L2VPN QoS SHOULD be independent of the access network technology.
L2VPN QoS应尽可能独立于接入网技术。
As provided in [RFC3809], an L2VPN SHALL be able to support QoS in one or more of the following already standardized modes:
如[RFC3809]所述，L2VPN应能够在以下一种或多种已经标准化的模式下支持QoS：
- Best Effort (support mandatory for all provider-provisioned VPN types)
- 尽力而为（所有提供商提供的VPN类型都必须支持）
- Aggregate CE Interface Level QoS (i.e., 'hose' level)
- 聚合CE接口级QoS（即“软管”级）
- Site-to-site, or 'pipe' level QoS
- 站点到站点，或“管道”级QoS
Note that all cases involving QoS MAY require that the CE and/or PE perform shaping and/or policing.
注意，所有涉及QoS的情况都可能要求CE和/或PE执行成形和/或监管。
Mappings or translations of Layer 2 QoS parameters into PSN QoS (e.g., DSCPs or MPLS EXP field) as well as QoS mapping based on VC (e.g., FR/ATM or VLAN) MAY be performed in order to provide QoS transparency. The actual mechanisms for these mappings or translations are outside the scope of this document. In addition, the Diffserv support of underlying tunneling technologies (e.g., [RFC3270] or [RFC3308]) and the Intserv model ([RFC2205]) MAY be used. As such, the L2VPN SLS requirements SHOULD be supported by appropriate core mechanisms.
为了提供QoS透明性，可以将第2层QoS参数映射或转换为PSN QoS（例如，DSCP或MPLS EXP字段）以及基于VC的QoS映射（例如，FR/ATM或VLAN）。这些映射或转换的实际机制不在本文档的范围内。此外，可以使用底层隧道技术（例如，[RFC3270]或[RFC3308]）的区分服务支持和Intserv模型（[RFC2205]）。因此，L2VPN SLS要求应得到适当的核心机制的支持。
A service provider may desire to offer QoS service to a customer for at least the following generic service types: managed access VPN service or an edge-to-edge QoS service. The details of the service models can be found in [RFC3809] and in [RFC4031].
服务提供商可能希望至少为以下通用服务类型向客户提供QoS服务：托管访问VPN服务或边缘到边缘QoS服务。有关服务模型的详细信息，请参见[RFC3809]和[RFC4031]。
In L2VPN service, both DSCP ([RFC2474]) and 802.1p ([IEEE_802.1D]) fields may be used for this purpose.
在L2VPN服务中，DSCP（[RFC2474]）和802.1p（[IEEE_802.1D]）字段都可用于此目的。
For an L2VPN service, the capabilities for Service Level Specification (SLS) monitoring and reporting stated in [RFC3809] SHOULD be provided.
对于L2VPN服务，应提供[RFC3809]中规定的服务级别规范（SLS）监控和报告功能。
The L2VPN service infrastructure SHOULD provide redundant paths to ensure high availability. The reaction to failures SHOULD result in an attempt to restore the service using alternative paths.
L2VPN服务基础架构应提供冗余路径，以确保高可用性。对故障的反应应导致尝试使用替代路径恢复服务。
The intention is to keep the restoration time small. The restoration time MUST be less than the time it takes the CE devices, or customer Layer 2 control protocols as well as Layer 3 routing protocols, to detect a failure in the L2VPN.
其目的是使恢复时间缩短。恢复时间必须小于CE设备或客户第2层控制协议以及第3层路由协议检测L2VPN中故障所需的时间。
The CE-to-PE links MAY be
CE到PE的链接可能是
- direct physical links (e.g., 100BaseTX, and T1/E1 TDM), - logical links (e.g., ATM PVC, and RFC2427-encapsulated link), - transport networks carrying Ethernet, - a Layer 2 tunnel that goes through a Layer 3 network (e.g., L2TP sessions).
- 直接物理链路（例如100BaseTX和T1/E1 TDM）、逻辑链路（例如ATM PVC和RFC2427封装链路）、承载以太网的传输网络、穿过第3层网络的第2层隧道（例如L2TP会话）。
Layer 2 frames MAY be tunneled through a Layer 3 backbone from PE to PE, using one of a variety of tunneling technologies (e.g., IP-in-IP, GRE, MPLS, L2TP, etc.).
第2层帧可以使用多种隧道技术（例如，IP-in-IP、GRE、MPLS、L2TP等）中的一种通过第3层主干从PE隧道到PE。
Standard interfaces to manage L2VPN services MUST be provided (e.g., standard SNMP MIB Modules). These interfaces SHOULD provide access to configuration, verification and runtime monitoring protocols.
必须提供管理L2VPN服务的标准接口（例如，标准SNMP MIB模块）。这些接口应提供对配置、验证和运行时监控协议的访问。
Service management MAY include the TMN 'FCAPS' functionalities, as follows: Fault, Configuration, Accounting, Performance, and Security, as detailed in [ITU_Y.1311.1].
服务管理可包括TMN“FCAPS”功能，如下所示：故障、配置、计费、性能和安全，详见[ITU_Y.1311.1]。
Multi-vendor interoperability, which corresponds to similar network and service levels among different implementations, at the network element SHOULD be guaranteed. This will likely rely on the completeness of the corresponding standard.
应保证网元上的多供应商互操作性，这对应于不同实现之间的类似网络和服务级别。这可能取决于相应标准的完整性。
The technical solution MUST be multi-vendor interoperable, not only within the SP network infrastructure, but also with the customer's network equipment and services making use of the L2VPN service.
该技术解决方案必须是多供应商可互操作的，不仅在SP网络基础设施内，而且还可以与使用L2VPN服务的客户网络设备和服务进行互操作。
A L2VPN solution SHOULD NOT preclude different access technologies. For instance, customer access connections to an L2VPN service MAY be different at different CE devices (e.g., Frame Relay, ATM, 802.1D, MPLS).
L2VPN解决方案不应排除不同的访问技术。例如，到L2VPN服务的客户接入连接在不同的CE设备（例如，帧中继、ATM、802.1D、MPLS）上可能不同。
Inter-working scenarios among different solutions providing L2VPN services are highly desirable. It is possible to have cases that require inter-working or interconnection between customer sites, which span network domains with different L2VPN solutions or different implementations of the same approach. Inter-working SHOULD be supported in a scalable manner.
提供L2VPN服务的不同解决方案之间的互通场景是非常理想的。可能存在需要客户站点之间相互工作或互连的情况，这些站点跨越具有不同L2VPN解决方案或相同方法的不同实现的网络域。应以可扩展的方式支持交互工作。
Inter-working scenarios MUST consider at least traffic isolation, security, QoS, access, and management aspects. This requirement is essential in the case of network migration, to ensure service continuity among sites belonging to different portions of the network.
互操作场景必须至少考虑流量隔离、安全性、QoS、访问和管理方面。在网络迁移的情况下，这一要求至关重要，以确保属于网络不同部分的站点之间的服务连续性。
This section captures requirements from a customer perspective.
本节从客户的角度捕获需求。
Customers MAY require L2VPN service that spans multiple administrative domains or SP networks. Therefore, an L2VPN service MUST be able to span multiple AS and SP networks but still to act and to appear as a single, homogeneous L2VPN from a customer point of view.
客户可能需要跨多个管理域或SP网络的L2VPN服务。因此，L2VPN服务必须能够跨越多个AS和SP网络，但从客户的角度来看，仍然可以作为单一的、同质的L2VPN来运行和显示。
A customer might also start with an L2VPN provided in a single AS with a certain SLS but then ask for an expansion of the service spanning multiple ASes and/or multiple-SPs. In this case, as well as for all kinds of multi-AS and multiple-SP L2VPNs, L2VPN service SHOULD be able to deliver the same SLS to all sites in a VPN regardless of the AS/SP to which it homes.
客户也可以从单个AS中提供的L2VPN开始，并使用特定SLS，但随后要求扩展跨多个ASE和/或多个SP的服务。在这种情况下，对于所有类型的多as和多SP L2VPN，L2VPN服务应该能够向VPN中的所有站点提供相同的SLS，而不管其所在的as/SP如何。
With the exception of IPLS, an L2VPN service SHOULD be agnostic to customer's Layer 3 traffic (e.g., IP, IPX, Appletalk) encapsulated within Layer 2 frames.
除IPLS外，L2VPN服务应与封装在第2层帧内的客户第3层流量（例如，IP、IPX、Appletalk）无关。
IPLS MUST allow transport of customer's IPv4 and IPv6 traffic encapsulated within Layer 2 frames. IPLS SHOULD also allow CEs to run ISIS and MPLS protocols transparently among them when those are used in conjunction with IP.
IPLS必须允许传输封装在第2层帧中的客户IPv4和IPv6流量。当ISIS和MPLS协议与IP结合使用时，IPLS还应允许CE在它们之间透明地运行ISIS和MPLS协议。
QoS is expected to be an important aspect of an L2VPN service for some customers.
对于一些客户来说，QoS将是L2VPN服务的一个重要方面。
A customer requires that the L2VPN service provide the QoS applicable to his or her application, which can range from PWs (e.g., SONET emulation) to voice, interactive video, and multimedia applications. Hence, best-effort as well as delay and loss sensitive traffic MUST be supported over an L2VPN service. A customer application SHOULD experience consistent QoS independent of the access network technology used at different sites connected to the same L2VPN.
客户要求L2VPN服务提供适用于其应用程序的QoS，范围从PWs（例如SONET仿真）到语音、交互式视频和多媒体应用程序。因此，必须通过L2VPN服务支持尽力而为以及对延迟和丢失敏感的流量。客户应用程序应体验到与连接到同一L2VPN的不同站点使用的接入网络技术无关的一致QoS。
Most customers simply want their applications to perform well. A SLS is a vehicle for a customer to measure the quality of the service that SP(s) provide. Therefore, when purchasing a service, a customer requires access to the measures from the SP(s) that support the SLS.
大多数客户只是希望他们的应用程序性能良好。SLS是客户衡量SP提供的服务质量的工具。因此，在购买服务时，客户需要从支持SLS的SP访问度量值。
Standard interfaces to monitor usage of L2VPN services SHOULD be provided (e.g., standard SNMP MIB Modules).
应提供监控L2VPN服务使用情况的标准接口（例如，标准SNMP MIB模块）。
An L2VPN solution MUST provide traffic as well as forwarding information base isolation for customers similar to that obtained in private lines, FR, or ATM services.
L2VPN解决方案必须为客户提供流量以及转发信息基础隔离，类似于在专用线路、FR或ATM服务中获得的隔离。
An L2VPN service MAY use customer VLAN Ids as service delimiters. In that case, they MUST be honored, and traffic separation MUST be provided.
L2VPN服务可以使用客户VLAN ID作为服务分隔符。在这种情况下，他们必须得到尊重，必须提供交通隔离。
An L2VPN solution MAY have the mechanisms to activate the appropriate filtering capabilities upon request of a customer. For instance, MAC and/or VLAN filtering MAY be considered between CE and PE for a VPLS.
L2VPN解决方案可能具有在客户请求时激活适当过滤功能的机制。例如，对于VPLS，可以在CE和PE之间考虑MAC和/或VLAN过滤。
An L2VPN solution MAY provide value-added security services such as encryption and/or authentication of customer packets, certificate management, and similar services.
L2VPN解决方案可以提供增值安全服务，例如客户数据包的加密和/或身份验证、证书管理和类似服务。
L2VPN services MUST NOT interfere with the security mechanisms employed at Layer 3 and higher layers by customers. Layer 2 security mechanisms, such as 802.10b ([IEEE_802.10]) and 802.1AE ([IEEE_802.1AE]), MAY inhibit L2VPN services, when the service delimiting VLAN Ids are encrypted.
L2VPN服务不得干扰客户在第3层和更高层使用的安全机制。第2层安全机制，例如802.10b（[IEEE_802.10]）和802.1AE（[IEEE_802.1AE]），可以在对划定VLAN ID的服务进行加密时禁止L2VPN服务。
Every packet exchanged between the customer and the SP over the access connection MUST appear as it would on a private network providing an equivalent service to that offered by the L2VPN.
客户和SP之间通过接入连接交换的每个数据包都必须显示在专用网络上，该专用网络提供与L2VPN相同的服务。
L2VPN solutions SHOULD support a broad range of physical and link-layer access technologies, such as PSTN, ISDN, xDSL, cable modem, leased line, Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless local loop, mobile radio access, etc. The capacity and QoS achievable MAY be dependent on the specific access technology in use.
L2VPN解决方案应支持广泛的物理和链路层接入技术，如PSTN、ISDN、xDSL、电缆调制解调器、专线、以太网、以太网VLAN、ATM、帧中继、无线本地环路、移动无线电接入等。可实现的容量和QoS可能取决于使用的特定接入技术。
Various types of physical connectivity scenarios MUST be supported, such as multi-homed sites, backdoor links between customer sites, and devices homed to two or more SP networks. In case of VPLS, IEEE 802.3ad-2000 link aggregation SHOULD be supported. L2VPN solutions SHOULD support at least the types of physical or link-layer connectivity arrangements shown in Figures 2 - 4 (in addition to the case shown in Figure 1). As in Figure 2, a CE can be dual-homed to an SP or to two different SPs via diverse access networks.
必须支持各种类型的物理连接方案，例如多主站点、客户站点之间的后门链接以及驻留到两个或多个SP网络的设备。对于VPLS，应支持IEEE 802.3ad-2000链路聚合。L2VPN解决方案应至少支持图2-4所示的物理或链路层连接安排类型（除了图1所示的情况）。如图2所示，CE可以通过不同的接入网络双驻留到一个SP或两个不同的SP。
+---------------- +---------------
| |
+------+ +------+
+---------| PE | +---------| PE |
| |device| | |device| SP network
| +------+ | +------+
+------+ | +------+ |
| CE | | | CE | +---------------
|device| | SP network |device| +---------------
+------+ | +------+ |
| +------+ | +------+
| | PE | | | PE |
+---------|device| +---------|device| SP network
+------+ +------+
| |
+---------------- +---------------
(a) (b)
+---------------- +---------------
| |
+------+ +------+
+---------| PE | +---------| PE |
| |device| | |device| SP network
| +------+ | +------+
+------+ | +------+ |
| CE | | | CE | +---------------
|device| | SP network |device| +---------------
+------+ | +------+ |
| +------+ | +------+
| | PE | | | PE |
+---------|device| +---------|device| SP network
+------+ +------+
| |
+---------------- +---------------
(a) (b)
Figure 2. Dual-Homed Access of CE Devices
图2。CE设备的双宿访问
Resiliency of the L2VPN service can be further enhanced as shown in Figure 3, where CE's connected via a "back door" connection, connect to the same SP or to different SPs.
L2VPN服务的弹性可以进一步增强，如图3所示，其中CE通过“后门”连接，连接到同一SP或不同SP。
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network
+------+ +------+ +------+ +------+
| | | |
| Backdoor | | Backdoor +---------------
| link | SP network | link +---------------
| | | |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|device| |device|-----|device| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(a) (b)
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network
+------+ +------+ +------+ +------+
| | | |
| Backdoor | | Backdoor +---------------
| link | SP network | link +---------------
| | | |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|device| |device|-----|device| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(a) (b)
Figure 3. Backdoor Links Between CE Devices
图3。CE设备之间的后门链接
Arbitrary combinations of the above methods, with a few examples shown in Figure 4, SHOULD be supported by any L2VPN solution.
任何L2VPN解决方案都应该支持上述方法的任意组合（图4中显示了一些示例）。
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network
+------+\ +------+ +------+\ +------+
| \ | | \ |
|Back \ | |Back \ +-------------
|door \ | SP network |door \ +-------------
|link \ | |link \ |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|device| |device|-----|device| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(a) (b)
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network
+------+\ +------+ +------+\ +------+
| \ | | \ |
|Back \ | |Back \ +-------------
|door \ | SP network |door \ +-------------
|link \ | |link \ |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|device| |device|-----|device| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(a) (b)
Figure 4. Combination of Dual-Homing and Backdoor Links for CE Devices
图4。CE设备的双归位和后门链接组合
A VPLS MUST deliver every packet at least to its intended destination(s) within the scope of the VPLS, subject to the ingress policing and security policies.
VPLS必须根据入口策略和安全策略，将每个数据包至少传送到VPLS范围内的预期目的地。
During normal operation, the queuing and forwarding policies SHOULD preserve packet order for packets with the same QoS parameters.
在正常操作期间，对于具有相同QoS参数的数据包，排队和转发策略应保持数据包顺序。
A VPLS MUST support the theoretical MTU of the offered service.
VPLS必须支持所提供服务的理论MTU。
The committed minimum MTU size MUST be the same for a given VPLS instance. Different L2VPN services MAY have different committed MTU sizes. If the customer VLANs are used as service delimiters, all VLANs within a given VPLS MUST inherit the same MTU size.
对于给定的VPLS实例，提交的最小MTU大小必须相同。不同的L2VPN服务可能具有不同的提交MTU大小。如果客户VLAN用作服务分隔符，则给定VPL中的所有VLAN必须继承相同的MTU大小。
A VPLS MAY use IP fragmentation if it presents reassembled packets at VPLS customer edge devices.
如果VPLS在VPLS客户边缘设备上呈现重新组装的数据包，则VPLS可以使用IP分段。
The L2VPN service MAY support translation of customers' AC identifiers (e.g., VLAN tags, if the customer VLANs are used as service delimiters). Such service simplifies connectivity of sites that want to keep their AC assignments or sites that belong to different administrative domains. In the latter case, the connectivity is sometimes referred to as Layer 2 extranet. On the other hand, it should be noted that VLAN tag translation affects the support for multiple spanning trees (i.e., 802.1s [IEEE_802.1s]) and can break the proper operation.
L2VPN服务可能支持转换客户的AC标识符（例如，如果客户VLAN用作服务分隔符，则VLAN标记）。此类服务简化了希望保留其AC分配的站点或属于不同管理域的站点的连接。在后一种情况下，连接有时被称为第2层外联网。另一方面，应注意，VLAN标记转换影响对多个生成树（即802.1s[IEEE_802.1s]）的支持，并可能中断正确的操作。
The L2VPN service is intended to be transparent to Layer 2 customer networks. An L2VPN solution SHOULD NOT require any special packet processing by the end users before sending packets to the provider's network.
L2VPN服务旨在对第2层客户网络透明。L2VPN解决方案在将数据包发送到提供商的网络之前，不应要求终端用户进行任何特殊的数据包处理。
If VLAN Ids are assigned by the SP, then VLANs are not transparent. Transparency does not apply in this case, as it is the same as FR/ATM service model.
如果VLAN ID由SP分配，则VLAN是不透明的。透明度在这种情况下不适用，因为它与FR/ATM服务模型相同。
Since the IPLS solution aims at transporting encapsulated traffic (rather than Layer 2 frames themselves), the IPLS solution MUST not alter the packets encapsulated inside Layer 2 frames that are transported by the IPLS. However, the IPLS solution is NOT REQUIRED to preserve the Layer 2 header transparently from CE to CE. For example, Source MAC address might not be preserved by the IPLS solution. The IPLS solution MAY remove Layer 2 headers for transport over the backbone when those can be reconstructed on egress without compromising transport of encapsulated traffic.
由于IPLS解决方案旨在传输封装的流量（而不是第2层帧本身），因此IPLS解决方案不得改变由IPLS传输的第2层帧内封装的数据包。但是，IPLS解决方案不需要在CE之间透明地保留第2层标头。例如，IPLS解决方案可能不会保留源MAC地址。IPLS解决方案可移除用于骨干上传输的第2层报头，前提是这些报头可在出口上重建，而不会影响封装流量的传输。
The L2VPN solution SHOULD allow transparent operation of Layer 2 control protocols employed by customers.
L2VPN解决方案应允许客户使用的第2层控制协议的透明操作。
In case of VPLS, the L2VPN service MUST ensure that loops be prevented. This can be accomplished with a loop-free topology or appropriate forwarding rules. Control protocols such as Spanning Tree (STP) or similar protocols could be employed. The L2VPN solution MAY use indications from customer Layer 2 control protocols, e.g., STP BPDU snooping, to improve the operation of a VPLS.
对于VPLS，L2VPN服务必须确保防止环路。这可以通过无循环拓扑或适当的转发规则来实现。可以使用诸如生成树（STP）或类似协议之类的控制协议。L2VPN解决方案可以使用来自客户第2层控制协议的指示，例如STP BPDU窥探，以改进VPLS的操作。
The L2VPN solution MUST require only minimal or no configuration on the CE devices, depending on the type of CE device that connects into the infrastructure.
L2VPN解决方案必须只需要在CE设备上进行最小配置或不进行配置，具体取决于连接到基础架构的CE设备的类型。
This section describes requirements from an SP perspective.
本节从SP的角度描述需求。
This section contains projections regarding L2VPN sizing and scalability requirements and metrics specific to particular solutions.
本节包含有关L2VPN规模和可扩展性需求以及特定解决方案的指标的预测。
[RFC3809] lists projections regarding L2VPN sizing and scalability requirements and metrics. The examples are provided in [RFC3809].
[RFC3809]列出了有关L2VPN规模和可扩展性需求和指标的预测。[RFC3809]中提供了示例。
Each L2VPN solution SHALL document its scalability characteristics in quantitative terms.
每个L2VPN解决方案应以定量方式记录其可扩展性特征。
An SP domain MUST be uniquely identified at least within the set of all interconnected SP networks when supporting an L2VPN that spans multiple SPs. Ideally, this identifier SHOULD be globally unique (e.g., an AS number).
当支持跨越多个SP的L2VPN时，SP域必须至少在所有互连SP网络集中唯一标识。理想情况下，该标识符应该是全局唯一的（例如，AS编号）。
An identifier for each L2VPN SHOULD be unique, at least within each SP's network, as it MAY be used in auto-discovery, management (e.g., alarm and service correlation, troubleshooting, performance statistics collection), and signaling. Ideally, the L2VPN identifier SHOULD be globally unique to support the case, where an L2VPN spans multiple SPs (e.g., [RFC2685]). Globally unique identifiers facilitate the support of inter-AS/SP L2VPNs.
每个L2VPN的标识符应该是唯一的，至少在每个SP的网络中是唯一的，因为它可以用于自动发现、管理（例如，报警和服务关联、故障排除、性能统计数据收集）和信令。理想情况下，L2VPN标识符应该是全局唯一的，以支持L2VPN跨越多个SP（例如，[RFC2685]）的情况。全局唯一标识符有助于支持AS/SP间L2VPN。
Configuration of PE devices (i.e., U-PE and N-PE [RFC4664]) is a significant task for an SP. Solutions SHOULD provide methods that dynamically allow L2VPN information to be discovered by the PEs to minimize the configuration steps.
PE设备（即U-PE和N-PE[RFC4664]）的配置对于SP来说是一项重要任务。解决方案应提供动态允许PE发现L2VPN信息的方法，以最小化配置步骤。
Each device in an L2VPN SHOULD be able to determine which other devices belong to the same L2VPN. Such a membership discovery scheme MUST prevent unauthorized access, and it allows authentication of the source.
L2VPN中的每个设备都应该能够确定哪些其他设备属于同一L2VPN。这样的成员身份发现方案必须防止未经授权的访问，并允许对源进行身份验证。
Distribution of L2VPN information SHOULD be limited to those devices involved in that L2VPN. An L2VPN solution SHOULD employ discovery mechanisms to minimize the amount of operational information maintained by the SPs. For example, if an SP adds or removes a customer port on a given PE, the remaining PEs SHOULD determine the necessary actions to take without the SP's having to explicitly reconfigure those PEs.
L2VPN信息的分发应限于该L2VPN中涉及的设备。L2VPN解决方案应采用发现机制，以尽量减少SP维护的操作信息量。例如，如果SP在给定PE上添加或删除客户端口，则其余PE应确定要采取的必要操作，而无需SP显式重新配置这些PE。
A L2VPN solution SHOULD support the means for attached CEs to authenticate each other and to verify that the SP L2VPN is correctly connected.
L2VPN解决方案应支持连接的CE相互验证和验证SP L2VPN是否正确连接的方法。
The mechanism SHOULD respond to L2VPN membership changes in a timely manner. A "timely manner" is no longer than the provisioning timeframe, typically on the order of minutes, and MAY be as short as the timeframe required for "rerouting," typically on the order of seconds.
该机制应及时响应L2VPN成员资格的更改。“及时方式”不长于调配时间段，通常以分钟为单位，也可能与“重新路由”所需的时间段一样短，通常以秒为单位。
Dynamically creating, changing, and managing multiple L2VPN assignments to sites and/or customers is another aspect of membership that MUST be addressed in an L2VPN solution.
动态创建、更改和管理站点和/或客户的多个L2VPN分配是L2VPN解决方案中必须解决的成员身份的另一个方面。
A significant aspect of a provider-provisioned VPN is support for QoS. An SP has control over the provisioning of resources and configuration of parameters in at least the PE and P devices, and in some cases the CE devices as well. Therefore, the SP is to provide either managed QoS access service, or edge-to-edge QoS service, as defined in [RFC4031].
提供商提供的VPN的一个重要方面是对QoS的支持。SP至少可以控制PE和P设备中的资源供应和参数配置，在某些情况下还可以控制CE设备中的资源供应和参数配置。因此，SP将提供[RFC4031]中定义的托管QoS访问服务或边到边QoS服务。
From a high level SP perspective, an L2VPN MUST isolate the exchange of traffic and forwarding information to only those sites that are authenticated and authorized members of an L2VPN.
从高级SP的角度来看，L2VPN必须隔离流量交换，并仅将信息转发给经过身份验证和授权的L2VPN成员。
An L2VPN solution SHOULD provide a means for meeting provider-provisioned VPN QoS SLS requirements that isolates L2VPN traffic from the affects of traffic offered by non-VPN customers. Also, L2VPN solutions SHOULD provide a means so that traffic congestion produced by sites as part of one L2VPN does not affect another L2VPN.
L2VPN解决方案应提供一种满足提供商提供的VPN QoS SLS要求的方法，将L2VPN流量与非VPN客户提供的流量隔离开来。此外，L2VPN解决方案应提供一种方法，使站点作为一个L2VPN的一部分而产生的流量拥塞不会影响另一个L2VPN。
The security requirements are stated in Section 6.5. The security requirements provided in [RFC3809] SHOULD be met. The security requirements, except Layer 3 and higher-layer dependent ones, specified in [RFC4031], SHOULD be met.
安全要求见第6.5节。应满足[RFC3809]中规定的安全要求。应满足[RFC4031]中规定的安全要求（第3层和更高层相关要求除外）。
In addition, an SP network MUST be protected against malformed or maliciously constructed customer traffic. This includes but is not limited to duplicate or invalid Layer 2 addresses, customer side loops, short/long packets, spoofed management packets, spoofed VLAN tags, high volume traffic.
此外，必须保护SP网络不受格式错误或恶意构建的客户流量的影响。这包括但不限于重复或无效的第2层地址、客户端环路、短/长数据包、伪造的管理数据包、伪造的VLAN标记、高容量流量。
The SP network devices MUST NOT be accessible from any L2VPN, unless specifically authorized. The devices in the SP network SHOULD provide some means of reporting intrusion attempts to the SP, if the intrusion is detected.
除非特别授权，否则SP网络设备不得从任何L2VPN访问。如果检测到入侵，SP网络中的设备应提供一些向SP报告入侵企图的方法。
When an L2VPN solution operates over a part of the Internet, it should support a configurable option to support one or more of the following standard IPsec methods for securing a customer's VPN traffic:
当L2VPN解决方案在Internet的一部分上运行时，它应该支持一个可配置选项，以支持以下一个或多个标准IPsec方法来保护客户的VPN流量：
- Confidentiality, so that only authorized devices can decrypt it
- 保密性，因此只有经过授权的设备才能解密
- Integrity, to ensure that the data has not been altered
- 完整性，以确保数据未被更改
- Authentication, to ensure that the sender is indeed who he or she claims to be
- 身份验证，以确保发件人确实是他或她声称的人
- Replay attack prevention.
- 重放攻击预防。
The above functions SHOULD be applicable to "data traffic" of the customer, which includes the traffic exchanged between sites. It SHOULD also be possible to apply these functions to "control traffic", such as routing or signaling protocol exchanges, that is not necessarily perceived by the customer but is nevertheless essential to maintain his or her VPN.
上述功能应适用于客户的“数据流量”，包括站点之间交换的流量。还可以将这些功能应用于“控制流量”，例如路由或信令协议交换，这些功能不一定由客户感知，但对于维护其VPN来说是必不可少的。
Furthermore, such security methods MUST be configurable between different end-points, such as PE-PE and PE-MTU, only in the case where L2VPN data traffic is carried over IP [RFC4023]. Methods to secure data flows at the native service layer (Layer-2), from CE-CE, CE-MTU and CE-PE, are outside the scope of this document. It is also desirable to configure security on a per-VPN basis.
此外，只有在L2VPN数据流量通过IP传输的情况下，此类安全方法才能在不同的端点（如PE-PE和PE-MTU）之间配置[RFC4023]。来自CE-CE、CE-MTU和CE-PE的在本机服务层（第2层）保护数据流的方法不在本文档的范围内。还希望在每个VPN的基础上配置安全性。
A VPN solution MAY support one or more encryption schemes, including AES, and 3DES. Encryption, decryption, and key management SHOULD be included in profiles as part of the security management system.
VPN解决方案可以支持一个或多个加密方案，包括AES和3DE。加密、解密和密钥管理应作为安全管理系统的一部分包含在配置文件中。
All applicable SP requirements, such as traffic and forwarding information isolation, SLSes, management, security, provisioning, etc. MUST be preserved across adjacent ASes. The solution MUST describe the inter-SP network interface, encapsulation method(s), routing protocol(s), and all applicable parameters.
所有适用的SP要求，如流量和转发信息隔离、SLSE、管理、安全性、资源调配等，必须在相邻的ASE之间保留。解决方案必须描述SP间网络接口、封装方法、路由协议和所有适用参数。
An L2VPN solution MUST provide the specifics of offering L2VPN services spanning multiple ASes and/or SPs.
L2VPN解决方案必须提供跨多个ASE和/或SP提供L2VPN服务的细节。
An L2VPN solution MUST support proper dissemination of operational parameters to all elements of an L2VPN service in the presence of multiple ASes and/or SPs. A L2VPN solution MUST employ mechanisms for sharing operational parameters between different ASes.
L2VPN解决方案必须支持在存在多个ASE和/或SP的情况下向L2VPN服务的所有元素正确分发操作参数。L2VPN解决方案必须采用在不同ASE之间共享操作参数的机制。
An L2VPN solution SHOULD support policies for proper selection of operational parameters coming from different ASes. Similarly, an L2VPN solution SHOULD support policies for selecting information to be disseminated to different ASes.
L2VPN解决方案应支持正确选择来自不同ASE的操作参数的策略。类似地，L2VPN解决方案应支持选择要分发给不同ASE的信息的策略。
The general requirements for managing a single AS apply to a concatenation of ASes. A minimum subset of such capabilities is the following:
管理单个AS的一般要求适用于ASE的串联。此类能力的最小子集如下所示：
- Diagnostic tools
- 诊断工具
- Secured access to one AS management system by another
- 一个AS管理系统被另一个AS管理系统安全访问
- Configuration request and status query tools
- 配置请求和状态查询工具
- Fault notification and trouble tracking tools
- 故障通知和故障跟踪工具
When an L2VPN spans multiple ASes, there is a need for a brokering mechanism that requests certain SLS parameters, such as bandwidth and QoS, from the other domains and/or networks involved in transferring traffic to various sites. The essential requirement is that a solution MUST be able to determine whether a set of ASes can establish and guarantee uniform QoS in support of a provider-provisioned VPN.
当L2VPN跨越多个ASE时，需要一种代理机制，该机制从涉及将流量传输到各个站点的其他域和/或网络请求某些SLS参数，例如带宽和QoS。基本要求是，解决方案必须能够确定一组ASE是否能够建立并保证统一的QoS，以支持提供商提供的VPN。
The architecture MUST support the possibility of one SP's offering L2VPN service to another SP. One example is when one SP sells L2VPN service at wholesale to another SP, who then resells that L2VPN service to his or her customers.
该体系结构必须支持一个SP向另一个SP提供L2VPN服务的可能性。例如，一个SP向另一个SP批发L2VPN服务，然后由另一个SP将该L2VPN服务转售给其客户。
Connectivity between CE sites or PE devices in the backbone SHOULD be able to use a range of tunneling technologies, such as L2TP, GRE, IP-in-IP, MPLS, etc.
主干网中CE站点或PE设备之间的连接应能够使用一系列隧道技术，如L2TP、GRE、IP中的IP、MPLS等。
Every PE MUST support a tunnel setup protocol, if tunneling is used. A PE MAY support static configuration. If employed, a tunnel establishment protocol SHOULD be capable of conveying information, such as the following:
如果使用隧道，每个PE必须支持隧道设置协议。PE可以支持静态配置。如果采用，隧道建立协议应能够传输信息，例如：
- Relevant identifiers
- 相关标识符
- QoS/SLS parameters
- QoS/SLS参数
- Restoration parameters
- 恢复参数
- Multiplexing identifiers
- 多路复用标识符
- Security parameters
- 安全参数
There MUST be a means to monitor the following aspects of tunnels:
必须有一种方法来监控隧道的以下方面：
- Statistics, such as amount of time spent in the up and down state
- 统计信息，例如处于上升和下降状态的时间量
- Count of transitions between the up and down state
- 向上和向下状态之间的转换计数
- Events, such as transitions between the up and down states
- 事件，例如向上和向下状态之间的转换
The tunneling technology used by the VPN SP and its associated mechanisms for tunnel establishment, multiplexing, and maintenance MUST meet the requirements on scaling, isolation, security, QoS, manageability, etc.
VPN SP使用的隧道技术及其用于隧道建立、多路复用和维护的相关机制必须满足扩展、隔离、安全、QoS、可管理性等方面的要求。
Regardless of the tunneling choice, the existence of the tunnels and their operations MUST be transparent to the customers.
无论选择何种隧道，隧道的存在及其运营必须对客户透明。
The connectivity between PE and CE devices is referred to as an AC. ACs MAY span networks of other providers or public networks.
PE和CE设备之间的连接称为AC。ACs可以跨越其他提供商的网络或公共网络。
There are several choices for implementing ACs. Some popular choices include Ethernet, ATM (DSL), Frame Relay, MPLS-based virtual circuits etc.
实现ACs有多种选择。一些流行的选择包括以太网、ATM（DSL）、帧中继、基于MPLS的虚拟电路等。
In case of VPLS, the AC MUST use Ethernet frames as the Service Protocol Data Unit (SPDU).
对于VPLS，AC必须使用以太网帧作为服务协议数据单元（SPDU）。
A CE access connection over an AC MUST be bi-directional.
AC上的CE接入连接必须是双向的。
PE devices MAY support multiple ACs on a single physical interface. In such cases, PE devices MUST NOT rely on customer controlled parameters for distinguishing between different access connections. For example, if VLAN tags were used for that purpose, the provider would be controlling the assignment of the VLAN tag values and would strictly enforce compliance by the CEs.
PE设备可以在单个物理接口上支持多个AC。在这种情况下，PE设备不得依赖客户控制的参数来区分不同的接入连接。例如，如果VLAN标记用于此目的，则提供商将控制VLAN标记值的分配，并严格执行CEs的合规性。
An AC, whether direct or virtual, MUST maintain all committed characteristics of the customer traffic, such as QoS, priorities etc. The characteristics of an AC are only applicable to that connection.
AC，无论是直接的还是虚拟的，都必须保持客户流量的所有承诺特征，如QoS、优先级等。AC的特征仅适用于该连接。
Ideally, the backbone interconnecting the SP's PE and P devices SHOULD be independent of physical and link-layer technology. Nevertheless, the characteristics of backbone technology MUST be taken into account when specifying the QoS aspects of SLSes for VPN service offerings.
理想情况下，连接SP的PE和P设备的主干应独立于物理层和链路层技术。然而，在为VPN服务产品指定SLSE的QoS方面时，必须考虑主干技术的特点。
In case network resources such as memory space, forwarding information base table, bandwidth, and CPU processing are shared between L2VPNs, the solution SHOULD guarantee availability of resources necessary to prevent any specific L2VPN service instance from taking up available network resources and causing others to fail. The solution SHOULD be able to limit the resources consumed by an L2VPN service instance. The solution SHOULD guarantee availability of resources necessary to fulfill the obligation of committed SLSes.
如果L2VPN之间共享内存空间、转发信息基表、带宽和CPU处理等网络资源，则解决方案应保证必要资源的可用性，以防止任何特定L2VPN服务实例占用可用网络资源并导致其他实例失败。解决方案应该能够限制L2VPN服务实例所消耗的资源。解决方案应保证履行承诺的SLSE义务所需资源的可用性。
Service providers are interested in interoperability in at least the following scenarios:
服务提供商至少对以下场景中的互操作性感兴趣：
- To facilitate use of PE and managed CE devices within a single SP network
- 促进在单个SP网络中使用PE和受管CE设备
- To implement L2VPN services across two or more interconnected SP networks
- 跨两个或多个互连的SP网络实施L2VPN服务
- To achieve inter-working or interconnection between customer sites using different L2VPN solutions or different implementations of the same approach
- 使用不同的L2VPN解决方案或相同方法的不同实现在客户站点之间实现互操作或互连
Each approach MUST describe whether any of the above objectives can be met. If an objective can be met, the approach MUST describe how such interoperability could be achieved.
每种方法必须说明是否能够实现上述任何目标。如果能够实现一个目标，该方法必须描述如何实现这种互操作性。
The L2VPN solution SHOULD provide the ability to test and verify operational and maintenance activities on a per L2VPN service basis, and, in case of VPLS, on a per-VLAN basis if customer VLANs are used as service delimiters.
L2VPN解决方案应提供基于每个L2VPN服务的测试和验证操作和维护活动的能力，如果使用VPL，则应基于每个VLAN（如果客户VLAN用作服务分隔符）。
The L2VPN solution SHOULD provide mechanisms for connectivity verification, and for detecting and locating faults.
L2VPN解决方案应提供连接验证、检测和定位故障的机制。
Examples of testing mechanisms are as follows:
测试机制的示例如下：
- Checking connectivity between "service-aware" network nodes
- 检查“服务感知”网络节点之间的连接
- Verifying data plane and control plane integrity
- 验证数据平面和控制平面的完整性
- Verifying service membership
- 验证服务成员资格
The provided mechanisms MUST satisfy the following: the connectivity checking for a given customer MUST enable the end-to-end testing of the data path used by that of customer's data packets, and the test packets MUST not propagate beyond the boundary of the SP network.
提供的机制必须满足以下要求：给定客户的连接检查必须能够对客户数据包使用的数据路径进行端到端测试，并且测试数据包不得传播到SP网络的边界之外。
To the extent possible, the IPLS solution SHOULD facilitate support of IPLS on existing PE devices that may be already deployed by the SP and MAY have been designed primarily for Layer 3 services.
IPLS解决方案应尽可能有助于在现有PE设备上支持IPLS，这些设备可能已经由SP部署，并且可能主要为第3层服务而设计。
An SP desires to have a means to view the topology, operational state, and other parameters associated with each customer's L2VPN. Furthermore, the SP requires a means to view the underlying logical and physical topology, operational state, provisioning status, and other parameters associated with the equipment providing the L2VPN service(s) to its customers. Therefore, the devices SHOULD provide standards-based interfaces (e.g., L2VPN MIB Modules), wherever feasible.
SP希望能够查看拓扑、操作状态以及与每个客户的L2VPN相关的其他参数。此外，SP需要一种方法来查看底层逻辑和物理拓扑、操作状态、供应状态以及与向其客户提供L2VPN服务的设备相关的其他参数。因此，只要可行，设备应提供基于标准的接口（例如L2VPN MIB模块）。
The details of service provider management requirements for a Network Management System (NMS) in the traditional fault, configuration, accounting, performance, and security (FCAPS) management categories can be found in [ITU_Y.1311.1].
关于传统故障、配置、计费、性能和安全（FCAPS）管理类别中网络管理系统（NMS）的服务提供商管理要求的详细信息，请参见[ITU_Y.1311.1]。
These requirements are driven by implementation characteristics that make service and SP requirements achievable.
这些需求由实现特性驱动，这些特性使服务和SP需求可以实现。
An L2VPN service SHOULD be provisioned with minimum number of steps. Therefore, the control protocols SHOULD provide methods for signaling between PEs. The signaling SHOULD inform of membership, tunneling information, and other relevant parameters.
L2VPN服务应设置最少的步骤数。因此，控制协议应提供PEs之间的信令方法。信号应告知成员资格、隧道信息和其他相关参数。
The infrastructure MAY employ manual configuration methods to provide this type of information.
基础设施可采用手动配置方法来提供此类信息。
The infrastructure SHOULD use policies to scope the membership and reachability advertisements for a particular L2VPN service. A mechanism for isolating the distribution of reachability information to only those sites associated with an L2VPN MUST be provided.
基础设施应使用策略来确定特定L2VPN服务的成员资格和可达性广告的范围。必须提供一种机制，用于将可达性信息的分发隔离到仅与L2VPN关联的那些站点。
The control plane traffic increases with the growth of L2VPN membership. Similarly, the control plane traffic increases with the number of supported L2VPN services. The use of control plane resources MAY increase as the number of hosts connected to an L2VPN service grows.
控制平面流量随着L2VPN成员的增加而增加。类似地，控制平面流量随着支持的L2VPN服务数量的增加而增加。随着连接到L2VPN服务的主机数量的增加，控制平面资源的使用可能会增加。
An L2VPN solution SHOULD minimize control plane traffic and the consumption of control plane resources. The control plane MAY offer means for enforcing a limit on the number of customer hosts attached to an L2VPN service.
L2VPN解决方案应尽量减少控制平面流量和控制平面资源的消耗。控制平面可以提供对连接到L2VPN服务的客户主机的数量实施限制的方法。
An L2VPN solution SHOULD utilize the encapsulation techniques defined by PWE3 ([RFC3985]), and SHOULD not impose any new requirements on these techniques.
L2VPN解决方案应利用PWE3（[RFC3985]）定义的封装技术，且不应对这些技术提出任何新要求。
An L2VPN solution SHOULD utilize the congestion avoidance techniques defined by PWE3 ([RFC3985]).
L2VPN解决方案应利用PWE3（[RFC3985]）定义的拥塞避免技术。
A separate Broadcast Domain MUST be maintained for each VPLS.
必须为每个VPL维护单独的广播域。
In addition to VPLS Broadcast Domains, an L2VPN service MAY honor customer VLAN Broadcast Domains, if customer VLANs are used as service delimiters. In that case, the L2VPN solution SHOULD maintain a separate VLAN Broadcast Domain for each customer VLAN.
除了VPLS广播域之外，如果将客户VLAN用作服务分隔符，L2VPN服务还可以支持客户VLAN广播域。在这种情况下，L2VPN解决方案应该为每个客户VLAN维护一个单独的VLAN广播域。
L2VPN PE devices MUST maintain a separate VSI per VPLS. Each VSI MUST have capabilities to forward traffic based on customer's traffic parameters, such as MAC addresses, VLAN tags (if supported), etc. as well as local policies.
L2VPN PE设备必须为每个VPLS维护一个单独的VSI。每个VSI必须具有基于客户流量参数（如MAC地址、VLAN标记（如果支持）等）以及本地策略转发流量的能力。
L2VPN PE devices MUST have capabilities to classify incoming customer traffic into the appropriate VSI.
L2VPN PE设备必须能够将传入的客户流量分类到适当的VSI中。
Each VSI MUST have flooding capabilities for its Broadcast Domain to facilitate proper forwarding of Broadcast, Multicast, and Unknown Unicast customer traffic.
每个VSI必须具有其广播域的泛洪功能，以促进广播、多播和未知单播客户流量的正确转发。
A VPLS SHOULD derive all topology and forwarding information from packets originating at customer sites. Typically, MAC address learning mechanisms are used for this purpose. With IPLS, snooping of particular packets originating at customer sites and signaling might also be used.
VPLS应该从源自客户站点的数据包中派生所有拓扑和转发信息。通常，MAC地址学习机制用于此目的。对于IPL，也可以使用监听源自客户站点的特定数据包和信令。
Dynamic population of the forwarding information base (e.g., via MAC address learning) MUST take place on a per VSI basis; i.e., in the context of a VPLS and, if supported, in the context of VLANs therein.
转发信息库的动态填充（例如，通过MAC地址学习）必须基于每个VSI进行；i、 例如，在VPLS的上下文中，如果支持，在其中VLAN的上下文中。
Security considerations occur at several levels and dimensions within L2VPNs, as detailed within this document.
如本文档所述，L2VPN中存在多个级别和维度的安全注意事项。
The requirements based on security concerns and potential security hazards are detailed in Section 6.5. Further details on security requirements are given from the customer and service provider perspectives in Sections 6.5 and 7.6, respectively. In an analogous manner, further detail on traffic and routing isolation requirements are given from the customer and service provider perspectives in Sections 5.4 and 7.5, respectively. Safeguards to protect network resources such as CPU, memory, and bandwidth are required in Section 7.12.
第6.5节详细说明了基于安全问题和潜在安全危害的要求。第6.5节和第7.6节分别从客户和服务提供商的角度给出了有关安全要求的更多详细信息。类似地，第5.4节和第7.5节分别从客户和服务提供商的角度给出了流量和路由隔离要求的进一步详细信息。第7.12节要求提供保护网络资源（如CPU、内存和带宽）的安全措施。
IPsec can also be applied after tunneling Layer 2 traffic to provide additional security.
IPsec也可以在隧道层2通信后应用，以提供额外的安全性。
In the case where an L2VPN service is carried over IP [RFC4023], traverses multiple SP networks and passes through an unsecured SP, POP, NAP, or IX, then security mechanisms MUST be employed. These security mechanisms include encryption, authentication, and resource protection, as described in section 5.5. For example, a provider should consider using both authentication and encryption for a tunnel used as part of an L2VPN that traverses another service provider's network.
如果L2VPN服务通过IP[RFC4023]承载，穿越多个SP网络并通过不安全的SP、POP、NAP或IX，则必须采用安全机制。这些安全机制包括加密、身份验证和资源保护，如第5.5节所述。例如，提供商应该考虑使用作为跨L2VPN的一部分的隧道的认证和加密，该隧道遍历另一服务提供商的网络。
The authors would like to acknowledge extensive comments and contributions provided by Loa Andersson, Joel Halpern, Eric Rosen, Ali Sajassi, Muneyoshi Suzuki, Ananth Nagarajan, Dinesh Mohan, Yakov Rekhter, Matt Squire, Norm Finn, Scott Bradner, and Francois Le Faucheur. The authors also wish to extend their appreciation to their respective employers and various other people who volunteered to review this work and provided feedback. This work was done in consultation with the entire Layer 2 PPVPN design team. A lot of the text was adapted from the Layer 3 VPN requirements document produced by the Layer 3 VPN requirements design team.
作者希望感谢Loa Andersson、Joel Halpern、Eric Rosen、Ali Sajassi、Muneyoshi Suzuki、Ananth Nagarajan、Dinesh Mohan、Yakov Rekhter、Matt Squire、Norm Finn、Scott Bradner和Francois Le Faucher提供的广泛评论和贡献。作者还希望向他们各自的雇主以及自愿审查这项工作并提供反馈的其他人表示感谢。这项工作是与整个第2层PPVPN设计团队协商完成的。很多文本都是从第三层VPN需求设计团队制作的第三层VPN需求文档中改编而来的。
[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月。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026]Andersson，L.和T.Madsen，“提供商提供的虚拟专用网络（VPN）术语”，RFC 4026，2005年3月。
[VPLS_LDP] Lasserre, M., Kompella, V. "Virtual Private LAN Services over MPLS", Work in Progress.
[VPLS_LDP]Lasserre，M.，Kompella，V.“MPLS上的虚拟专用LAN服务”，正在进行中。
[VPLS_BGP] Kompella, K., Rekhter, Y. "Virtual Private LAN Service", Work in Progress.
[VPLS_BGP]Kompella，K.，Rekhter，Y.“虚拟专用局域网服务”，正在进行中。
[IPLS] Shah, H., et al. "IP-Only LAN Service (IPLS)", Work in Progress.
[IPLS]Shah，H.等人，“仅IP局域网服务（IPLS）”，正在进行中。
[IEEE_802.1Q] IEEE Std 802.1Q-1998, "Virtual Bridged Local Area Networks", 1998
[IEEE_802.1Q]IEEE标准802.1Q-1998，“虚拟桥接局域网”，1998年
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999.
[RFC2685]Fox，B.和B.Gleeson，“虚拟专用网络标识符”，RFC 26851999年9月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce, "Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension", RFC 3308, November 2002.
[RFC3308]Calhoun，P.，Luo，W.，McPherson，D.，和K.Peirce，“第二层隧道协议（L2TP）区分服务扩展”，RFC 33082002年11月。
[RFC3809] Nagarajan, A., "Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 2004.
[RFC3809]Nagarajan，A.，“提供商提供的虚拟专用网络（PPVPN）的一般要求”，RFC 3809，2004年6月。
[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月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023]Worster，T.，Rekhter，Y.，和E.Rosen，“在IP或通用路由封装（GRE）中封装MPLS”，RFC 4023，2005年3月。
[RFC4031] Carugi, M. and D. McDysan, "Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)", RFC 4031, April 2005.
[RFC4031]Carugi，M.和D.McDysan，“第3层提供商提供的虚拟专用网络（PPVPN）的服务要求”，RFC 4031，2005年4月。
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664]Andersson，L.和E.Rosen，“第二层虚拟专用网络（L2VPN）框架”，RFC 4664，2006年9月。
[IEEE_802.1D] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 Edition (Revision and redesignation of ISO/IEC 10038:98), "Part 3: Media Access Control (MAC) Bridges", 1998.
[IEEE_802.1D]ISO/IEC 15802-3:1998 ANSI/IEEE Std 802.1D，1998年版（ISO/IEC 10038:98的修订和重新命名），“第3部分：媒体访问控制（MAC）网桥”，1998年。
[ITU_Y.1311.1] Carugi, M. (editor), "Network Based IP VPN over MPLS architecture",Y.1311.1 ITU-T Recommendation, May 2001.
[ITU_Y.1311.1]Carugi，M.（编辑），“基于MPLS架构的基于网络的IP VPN”，Y.1311.1 ITU-T建议，2001年5月。
[IEEE_802.10] IEEE Std 802.10-1998 Edition (Revision IEEE Std 802.10-1992, incorporating IEEE Std 802.10b-1992, 802.10e-1993, 802.10f-1993, 802.10g-1995, and 802.10h-1997), "Standard for Interoperable LAN/MAN Security (SILS)", 1998.
[IEEE_802.10]IEEE标准802.10-1998版（修订版IEEE标准802.10-1992，包括IEEE标准802.10b-1992、802.10e-1993、802.10f-1993、802.10g-1995和802.10h-1997），“可互操作局域网/城域网安全（SILS）标准”，1998年。
[IEEE_802.1AE] IEEE 802.1AE/D5.1, "Draft Standard for Local and Metropolitan Area Networks - Media Access Control (MAC) Security", P802.1AE/D5.1, January 19, 2006.
[IEEE_802.1AE]IEEE 802.1AE/D5.1，“局域网和城域网标准草案-媒体访问控制（MAC）安全”，第802.1AE/D5.1页，2006年1月19日。
[IEEE_802.1s] IEEE Std 802.1s-2002, "Virtual Bridged Local Area Networks-Amendment 3: Multiple Spanning Trees", 2002.
[IEEE_802.1s]IEEE标准802.1s-2002，“虚拟桥接局域网修正案3：多生成树”，2002年。
Editors' Addresses
编辑地址
Waldemar Augustyn
瓦德马尔·奥古斯丁
EMail: waldemar@wdmsys.com
EMail: waldemar@wdmsys.com
Yetik Serbest AT&T Labs 9505 Arboretum Blvd. Austin, TX 78759
Yetik Serbest AT&T实验室植物园大道9505号。德克萨斯州奥斯汀78759
EMail: yetik_serbest@labs.att.com
EMail: yetik_serbest@labs.att.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。