Network Working Group Y. Kamite, Ed.
Request for Comments: 5501 NTT Communications
Category: Informational Y. Wada
NTT
Y. Serbest
AT&T
T. Morin
France Telecom
L. Fang
Cisco Systems, Inc.
March 2009
Network Working Group Y. Kamite, Ed.
Request for Comments: 5501 NTT Communications
Category: Informational Y. Wada
NTT
Y. Serbest
AT&T
T. Morin
France Telecom
L. Fang
Cisco Systems, Inc.
March 2009
Requirements for Multicast Support in Virtual Private LAN Services
虚拟专用LAN服务中对多播支持的要求
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines.
本文档提供了支持虚拟专用LAN服务（VPLS）上的多播的网络解决方案的功能要求。它从最终用户和服务提供商的角度规定了要求。预期潜在解决方案将使用这些要求作为指南。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. Scope of This Document .....................................4
2. Conventions Used in This Document ...............................5
2.1. Terminology ................................................5
2.2. Conventions ................................................6
3. Problem Statements ..............................................6
3.1. Motivation .................................................6
3.2. Multicast Scalability ......................................7
3.3. Application Considerations .................................8
3.3.1. Two Perspectives of the Service .....................8
4. General Requirements ............................................9
4.1. Scope of Transport .........................................9
4.1.1. Traffic Types .......................................9
4.1.1.1. Multicast and Broadcast ....................9
4.1.1.2. Unknown Destination Unicast ................9
4.1.2. Multicast Packet Types ..............................9
4.1.3. MAC Learning Consideration .........................11
4.2. Static Solutions ..........................................11
4.3. Backward Compatibility ....................................11
5. Customer Requirements ..........................................12
5.1. CE-PE Protocol ............................................12
5.1.1. Layer-2 Aspect .....................................12
5.1.2. Layer-3 Aspect .....................................12
5.2. Multicast Domain ..........................................13
5.3. Quality of Service (QoS) ..................................14
5.4. SLA Parameters Measurement ................................14
5.5. Security ..................................................15
5.5.1. Isolation from Unicast .............................15
5.5.2. Access Control .....................................15
5.5.3. Policing and Shaping on Multicast ..................15
5.6. Access Connectivity .......................................15
5.7. Multi-Homing ..............................................15
5.8. Protection and Restoration ................................15
5.9. Minimum MTU ...............................................16
5.10. Frame Reordering Prevention ..............................16
5.11. Fate-Sharing between Unicast and Multicast ...............16
6. Service Provider Network Requirements ..........................18
6.1. Scalability ...............................................18
6.1.1. Trade-Off of Optimality and State Resource .........18
6.1.2. Key Metrics for Scalability ........................19
6.2. Tunneling Requirements ....................................20
6.2.1. Tunneling Technologies .............................20
6.2.2. MTU of MDTunnel ....................................20
6.3. Robustness ................................................20
6.4. Discovering Related Information ...........................21
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. Scope of This Document .....................................4
2. Conventions Used in This Document ...............................5
2.1. Terminology ................................................5
2.2. Conventions ................................................6
3. Problem Statements ..............................................6
3.1. Motivation .................................................6
3.2. Multicast Scalability ......................................7
3.3. Application Considerations .................................8
3.3.1. Two Perspectives of the Service .....................8
4. General Requirements ............................................9
4.1. Scope of Transport .........................................9
4.1.1. Traffic Types .......................................9
4.1.1.1. Multicast and Broadcast ....................9
4.1.1.2. Unknown Destination Unicast ................9
4.1.2. Multicast Packet Types ..............................9
4.1.3. MAC Learning Consideration .........................11
4.2. Static Solutions ..........................................11
4.3. Backward Compatibility ....................................11
5. Customer Requirements ..........................................12
5.1. CE-PE Protocol ............................................12
5.1.1. Layer-2 Aspect .....................................12
5.1.2. Layer-3 Aspect .....................................12
5.2. Multicast Domain ..........................................13
5.3. Quality of Service (QoS) ..................................14
5.4. SLA Parameters Measurement ................................14
5.5. Security ..................................................15
5.5.1. Isolation from Unicast .............................15
5.5.2. Access Control .....................................15
5.5.3. Policing and Shaping on Multicast ..................15
5.6. Access Connectivity .......................................15
5.7. Multi-Homing ..............................................15
5.8. Protection and Restoration ................................15
5.9. Minimum MTU ...............................................16
5.10. Frame Reordering Prevention ..............................16
5.11. Fate-Sharing between Unicast and Multicast ...............16
6. Service Provider Network Requirements ..........................18
6.1. Scalability ...............................................18
6.1.1. Trade-Off of Optimality and State Resource .........18
6.1.2. Key Metrics for Scalability ........................19
6.2. Tunneling Requirements ....................................20
6.2.1. Tunneling Technologies .............................20
6.2.2. MTU of MDTunnel ....................................20
6.3. Robustness ................................................20
6.4. Discovering Related Information ...........................21
6.5. Operation, Administration, and Maintenance ................21
6.5.1. Activation .........................................21
6.5.2. Testing ............................................22
6.5.3. Performance Management .............................22
6.5.4. Fault Management ...................................23
6.6. Security ..................................................24
6.6.1. Security Threat Analysis ...........................24
6.6.2. Security Requirements ..............................25
6.7. Hierarchical VPLS support .................................28
6.8. L2VPN Wholesale ...........................................28
7. Security Considerations ........................................28
8. Acknowledgments ................................................28
9. References .....................................................29
9.1. Normative References ......................................29
9.2. Informative References ....................................29
6.5. Operation, Administration, and Maintenance ................21
6.5.1. Activation .........................................21
6.5.2. Testing ............................................22
6.5.3. Performance Management .............................22
6.5.4. Fault Management ...................................23
6.6. Security ..................................................24
6.6.1. Security Threat Analysis ...........................24
6.6.2. Security Requirements ..............................25
6.7. Hierarchical VPLS support .................................28
6.8. L2VPN Wholesale ...........................................28
7. Security Considerations ........................................28
8. Acknowledgments ................................................28
9. References .....................................................29
9.1. Normative References ......................................29
9.2. Informative References ....................................29
VPLS (Virtual Private LAN Service) is a provider service that emulates the full functionality of a traditional Local Area Network (LAN). VPLS interconnects several customer LAN segments over a packet switched network (PSN) backbone, creating a multipoint-to-multipoint Ethernet VPN. For customers, their remote LAN segments behave as one single LAN.
VPLS（虚拟专用LAN服务）是一种模拟传统局域网（LAN）全部功能的提供商服务。VPLS通过分组交换网络（PSN）主干网互连多个客户LAN段，创建多点到多点以太网VPN。对于客户来说，他们的远程LAN段的行为就像一个单独的LAN。
In a VPLS, the provider network emulates a learning bridge, and forwarding takes place based on Ethernet MAC (media access control) learning. Hence, a VPLS requires MAC address learning/aging on a per-PW (pseudowire) basis, where forwarding decisions treat the PW as a "bridge port".
在VPLS中，提供商网络模拟学习网桥，并基于以太网MAC（媒体访问控制）学习进行转发。因此，VPLS需要基于每PW（伪线）的MAC地址学习/老化，其中转发决策将PW视为“网桥端口”。
VPLS is a Layer-2 (L2) service. However, it provides two applications from the customer's point of view:
VPLS是第二层（L2）服务。但是，从客户的角度来看，它提供了两个应用程序：
- LAN Routing application: providing connectivity between customer routers
- LAN路由应用程序：提供客户路由器之间的连接
- LAN Switching application: providing connectivity between customer Ethernet switches
- LAN交换应用：提供客户以太网交换机之间的连接
Thus, in some cases, customers across MAN/WAN have transparent Layer-2 connectivity while their main goal is to run Layer-3 applications within their routing domain. As a result, different requirements arise from their variety of applications.
因此，在某些情况下，跨MAN/WAN的客户具有透明的第2层连接，而他们的主要目标是在其路由域内运行第3层应用程序。因此，不同的应用程序会产生不同的需求。
Originally, PEs (Provider Edges) in VPLS transport broadcast/ multicast Ethernet frames by replicating all multicast/broadcast frames received from an Attachment Circuit (AC) to all PW's corresponding to a particular Virtual Switching Instance (VSI). Such a technique has the advantage of keeping the P (Provider Router) and PE devices completely unaware of IP multicast-specific issues. Obviously, however, it has quite a few scalability drawbacks in terms of bandwidth consumption, which will lead to increased cost in large-scale deployment.
最初，VPLS中的PEs（提供商边缘）通过将从连接电路（AC）接收的所有多播/广播帧复制到对应于特定虚拟交换实例（VSI）的所有PW来传输广播/多播以太网帧。这种技术的优点是使P（提供者路由器）和PE设备完全不知道IP多播特定的问题。然而，很明显，它在带宽消耗方面存在很多可伸缩性缺陷，这将导致大规模部署的成本增加。
Meanwhile, there is a growing need for support of multicast-based services such as IP TV. This commercial trend makes it necessary for most VPLS deployments to support multicast more efficiently than before. It is also necessary as customer routers are now likely to be running IP multicast protocols, and those routers are connected to switches that will be handling large amounts of multicast traffic.
同时，人们越来越需要支持基于多播的服务，如IP电视。这种商业趋势使得大多数VPLS部署都需要比以前更高效地支持多播。这也是必要的，因为客户路由器现在可能正在运行IP多播协议，并且这些路由器连接到将处理大量多播流量的交换机。
Therefore, it is desirable to have more efficient techniques to support IP multicast over VPLS.
因此，希望有更有效的技术来支持VPLS上的IP多播。
This document provides functional requirements for network solutions that support IP multicast in VPLS [RFC4761] [RFC4762]. It identifies requirements that MAY apply to the existing base VPLS architecture in order to optimize IP multicast. It also complements the generic L2VPN requirements document [RFC4665], by specifying additional requirements specific to the deployment of IP multicast in VPLS.
本文档提供了支持VPLS[RFC4761][RFC4762]中IP多播的网络解决方案的功能要求。它确定了可能适用于现有基本VPLS体系结构的需求，以优化IP多播。它还补充了通用L2VPN需求文档[RFC4665]，具体规定了VPLS中IP多播部署的额外需求。
The technical specifications are outside the scope of this document. In this document, there is no intent to specify either solution-specific details or application-specific requirements. Also, this document does NOT aim to express multicast-inferred requirements that are not specific to VPLS. It does NOT aim to express any requirements for native Ethernet specifications, either.
技术规范不在本文件范围内。在本文档中，无意指定特定于解决方案的详细信息或特定于应用程序的要求。此外，本文档的目的不是表达非特定于VPL的多播推断需求。它的目的也不是表达对本机以太网规范的任何要求。
This document is proposed as a solution guideline and a checklist of requirements for solutions, by which we will evaluate how each solution satisfies the requirements.
本文件是作为解决方案指南和解决方案需求清单提出的，我们将根据该清单评估每个解决方案如何满足需求。
This document clarifies the needs from both VPLS customer as well as provider standpoints and formulates the problems that should be addressed by technical solutions while staying solution agnostic.
本文件阐明了VPLS客户和供应商的需求，并阐述了技术解决方案应解决的问题，同时保持解决方案不可知。
A technical solution and corresponding service that supports this document's requirements are hereinafter called a "multicast VPLS".
支持本文件要求的技术解决方案和相应服务在下文中称为“多播VPLS”。
The reader is assumed to be familiar with the terminology, reference models, and taxonomy defined in [RFC4664] and [RFC4665]. For readability purposes, we repeat some of the terms here.
假定读者熟悉[RFC4664]和[RFC4665]中定义的术语、参考模型和分类法。为了便于阅读，我们在这里重复一些术语。
Moreover, we also propose some other terms needed when IP multicast support in VPLS is discussed.
此外，在讨论VPLS中的IP多播支持时，我们还提出了一些其他术语。
- ASM: Any Source Multicast. One of the two multicast service models where each corresponding service can have an arbitrary number of senders.
- ASM：任何源多播。两种多播服务模型之一，其中每个对应的服务可以有任意数量的发送者。
- G: denotes a multicast group.
- G：表示多播组。
- MDTunnel: Multicast Distribution Tunnel, the means by which the customer's multicast traffic will be conveyed across the Service Provider (SP) network. This is meant in a generic way: such tunnels can be point-to-point, point-to-multipoint, or multipoint-to-multipoint. Although this definition may seem to assume that distribution tunnels are unidirectional, the wording encompasses bidirectional tunnels as well.
- MDTunnel：多播分发隧道，客户的多播流量将通过服务提供商（SP）网络传输的方式。这是一种通用方式：此类隧道可以是点对点、点对多点或多点对多点。尽管该定义似乎假定配电隧道是单向的，但该措辞也包括双向隧道。
- Multicast Channel: In the multicast SSM (Source Specific Multicast) model [RFC4607], a "multicast channel" designates traffic from a specific source S to a multicast group G. Also denominated as "(S,G)".
- 多播信道：在多播SSM（源特定多播）模型[RFC4607]中，“多播信道”指定从特定源S到多播组G的通信量。也称为“（S，G）”。
- Multicast domain: An area in which multicast data is transmitted. In this document, this term has a generic meaning that can refer to Layer-2 and Layer-3. Generally, the Layer-3 multicast domain is determined by the Layer-3 multicast protocol used to establish reachability between all potential receivers in the corresponding domain. The Layer-2 multicast domain can be the same as the Layer-2 broadcast domain (i.e., VLAN), but it may be restricted to being smaller than the Layer-2 broadcast domain if an additional control protocol is used.
- 多播域：传输多播数据的区域。在本文件中，该术语具有泛指第2层和第3层的一般含义。通常，第三层多播域由第三层多播协议确定，该协议用于在相应域中的所有潜在接收器之间建立可达性。第二层多播域可以与第二层广播域（即VLAN）相同，但如果使用附加控制协议，则可以限制其小于第二层广播域。
- CE: Customer Edge Device.
- CE：客户边缘设备。
- PE: Provider Edge.
- PE：提供者边缘。
- P: Provider Router.
- 提供商路由器。
- S: denotes a multicast source.
- S：表示多播源。
- SP: Service Provider.
- SP：服务提供商。
- SSM: Source Specific Multicast. One of the two multicast service models where each corresponding service relies upon the use of a single source.
- SSM：特定于源的多播。两种多播服务模型中的一种，其中每个对应的服务都依赖于单个源的使用。
- U-PE/N-PE: The device closest to the customer/user is called the User-facing PE (U-PE) and the device closest to the core network is called the Network-facing PE (N-PE).
- U-PE/N-PE：最接近客户/用户的设备称为面向用户的PE（U-PE），最接近核心网络的设备称为面向网络的PE（N-PE）。
- VPLS instance: A service entity manageable in VPLS architecture. All CE devices participating in a single VPLS instance appear to be on the same LAN, composing a VPN across the SP's network. A VPLS instance corresponds to a group of VSIs that are interconnected using PWs (pseudowires).
- VPLS实例：在VPLS体系结构中可管理的服务实体。参与单个VPLS实例的所有CE设备似乎位于同一LAN上，构成了SP网络上的VPN。VPLS实例对应于使用PWs（伪线）互连的一组VSI。
- VSI: Virtual Switching Instance. A VSI is a logical entity in a PE that maps multiple ACs (Attachment Circuits) to multiple PWs. The VSI is populated in much the same way as a standard bridge populates its forwarding table. Each PE device may have multiple VSIs, where each VSI belongs to a different VPLS instance.
- 虚拟交换实例。VSI是PE中将多个ACs（连接电路）映射到多个PW的逻辑实体。VSI的填充方式与标准网桥填充其转发表的方式大致相同。每个PE设备可能有多个VSI，其中每个VSI属于不同的VPLS实例。
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]中所述进行解释。
Today, many kinds of IP multicast services are becoming available. Over their Layer-2 VPN service, particularly over VPLS, customers would often like to operate their multicast applications to remote sites. Also, VPN service providers using an IP-based network expect that such Layer-2 network infrastructure will efficiently support multicast data traffic.
今天，许多类型的IP多播服务都变得可用。通过第2层VPN服务，特别是通过VPLS，客户通常希望将其多播应用程序操作到远程站点。此外，使用基于IP的网络的VPN服务提供商期望这样的第二层网络基础设施将有效地支持多播数据通信。
However, VPLS has a shortcoming as it relates to multicast scalability as mentioned below because of the replication mechanisms intrinsic to the original architecture. Accordingly, the primary goal for technical solutions is to solve this issue partially or completely, and provide efficient ways to support IP multicast services over VPLS.
然而，由于原始体系结构固有的复制机制，VPLS在多播可伸缩性方面有一个缺点，如下所述。因此，技术解决方案的主要目标是部分或完全解决这个问题，并提供有效的方法来支持VPLS上的IP多播服务。
In VPLS, replication occurs at an ingress PE (in the hierarchical VPLS (H-VPLS) case, at N-PE) when a CE sends (1) Broadcast, (2) Multicast, or (3) Unknown destination unicast. There are two well-known issues with this approach:
在VPLS中，当CE发送（1）广播、（2）多播或（3）未知目标单播时，复制发生在入口PE（在分层VPLS（H-VPLS）情况下，在N-PE）。这种方法有两个众所周知的问题：
Issue A: Replication to non-member site:
问题A：复制到非成员站点：
In cases (1) and (3), the upstream PE has to transmit packets to all of the downstream PEs that belong to the common VPLS instance. You cannot decrease the number of members, so this is basically an inevitable situation for most VPLS deployments.
在情况（1）和（3）中，上游PE必须向属于公共VPLS实例的所有下游PE发送分组。您无法减少成员的数量，因此对于大多数VPLS部署来说，这基本上是不可避免的情况。
In case (2), however, there is an issue that multicast traffic is sent to sites with no members. Usually, this is caused when the upstream PE does not maintain downstream membership information. The upstream PE simply floods frames to all downstream PEs, and the downstream PEs forward them to directly connected CEs; however, those CEs might not be the members of any multicast group. From the perspective of customers, they might suffer from pressure on their own resources due to unnecessary traffic. From the perspective of SPs, they would not like wasteful over-provisioning to cover such traffic.
然而，在案例（2）中，存在一个问题，即多播流量被发送到没有成员的站点。通常，这是因为上游PE不维护下游成员信息。上游PE向所有下游PE发送帧，下游PE将帧转发给直接连接的CE；但是，这些CE可能不是任何多播组的成员。从客户的角度来看，他们可能会因为不必要的流量而承受自身资源的压力。从SP的角度来看，他们不希望浪费过多的资源调配来覆盖此类流量。
Issue B: Replication of PWs on shared physical path:
问题B：在共享物理路径上复制PWs：
In VPLS, a VSI associated with each VPLS instance behaves as a logical emulated bridge that can transport Ethernet across the PSN backbone using PWs. In principle, PWs are designed for unicast traffic.
在VPLS中，与每个VPLS实例关联的VSI充当逻辑模拟网桥，可以使用PWs跨PSN主干传输以太网。原则上，PWs是为单播通信量设计的。
In all cases, (1), (2), and (3), Ethernet frames are replicated on one or more PWs that belong to that VSI. This replication is often inefficient in terms of bandwidth usage if those PWs are traversing shared physical links in the backbone.
在所有情况下，（1）、（2）和（3），以太网帧在属于该VSI的一个或多个PW上复制。如果这些PW正在穿越主干网中的共享物理链路，那么这种复制通常在带宽使用方面效率低下。
For instance, suppose there are 20 remote PEs belonging to a particular VPLS instance, and all PWs happen to be traversing over the same link from one local PE to its next-hop P. In this case, even if a CE sends 50 Mbps to the local PE, the total bandwidth of that link will be to 1000 Mbps.
例如，假设有20个远程PE属于一个特定的VPLS实例，并且所有PW恰好通过同一链路从一个本地PE到其下一个跃点P。在这种情况下，即使CE向本地PE发送50 Mbps，该链路的总带宽也将达到1000 Mbps。
Note that while traditional 802.1D Ethernet switches replicate broadcast/multicast flows once at most per output interface, VPLS often needs to transmit one or more flows duplicated over the same output interface.
请注意，虽然传统的802.1D以太网交换机在每个输出接口上最多复制一次广播/多播流，但VPL通常需要在同一输出接口上传输一个或多个复制流。
From the perspective of customers, there is no serious issue because they do not know what happens in the core. However, from the perspective of SPs, unnecessary replication brings the risk of resource exhaustion when the number of PWs increases.
从客户的角度来看，没有严重的问题，因为他们不知道核心发生了什么。但是，从SP的角度来看，当PW数量增加时，不必要的复制会带来资源耗尽的风险。
In both Issues A and B, these undesirable situations will become obvious with the wide-spread use of IP multicast applications by customers. Naturally, the problem will become more serious as the number of sites grows. In other words, there are concerns over the scalability of multicast in VPLS today.
在问题A和问题B中，随着客户广泛使用IP多播应用程序，这些不良情况将变得明显。当然，随着网站数量的增加，问题会变得更加严重。换句话说，现在VPLS中的多播的可伸缩性令人担忧。
When it comes to IP multicast over VPLS, there are two different aspects in terms of service provisioning. They are closely related to the functional requirements from two technical standpoints:
当谈到VPLS上的IP多播时，在服务提供方面有两个不同的方面。它们从两个技术角度与功能需求密切相关：
Layer-2 and Layer-3.
第二层和第三层。
- Native Ethernet service aspect
- 本机以太网服务方面
This aspect mainly affects Ethernet network service operators. Their main interest is to solve the issue that existing VPLS deployments cannot always handle multicast/broadcast frames efficiently.
这方面主要影响以太网网络服务运营商。他们的主要兴趣是解决现有VPLS部署不能始终有效地处理多播/广播帧的问题。
Today, wide-area Ethernet services are becoming popular, and VPLS can be utilized to provide wide-area LAN services. As customers come to use various kinds of content distribution applications that use IP multicast (or other protocols that lead to multicast/ broadcast in the Ethernet layer), the total amount of traffic will also grow. In addition, considerations of Operations, Administration, and Management (OAM), security and other related points in multicast in view of Layer-2 are important.
今天，广域以太网服务变得越来越流行，VPLS可以用来提供广域局域网服务。随着客户开始使用使用IP多播（或导致以太网层多播/广播的其他协议）的各种内容分发应用程序，流量总量也将增加。此外，从第2层的角度考虑多播中的操作、管理和管理（OAM）、安全性和其他相关点也很重要。
In such circumstances, the native VPLS specification would not always be satisfactory if multicast traffic is more dominant in total resource utilization than before. The scalability issues mentioned in the previous section are expected to be solved.
在这种情况下，如果多播流量在总资源利用率中比以前更占主导地位，则本机VPLS规范将不总是令人满意的。上一节提到的可伸缩性问题有望得到解决。
- IP multicast service aspect
- IP多播服务方面
This aspect mainly affects both IP service providers and end users. Their main interest is to provide IP multicast services transparently but effectively by means of VPLS as a network infrastructure.
这方面主要影响IP服务提供商和最终用户。他们的主要兴趣是通过VPLS作为网络基础设施，透明而有效地提供IP多播服务。
SPs might expect VPLS as an access/metro network to deliver multicast traffic (such as Triple-play (Video, Voice, Data) and Multicast IP VPNs) in an efficient way.
SPs可能期望VPLS作为接入/城域网络以高效的方式提供多播流量（如三网融合（视频、语音、数据）和多播IP VPN）。
We assume the basic requirements for VPLS written in [RFC4665] are fulfilled unless otherwise specified in this document.
除非本文件另有规定，否则我们假设满足[RFC4665]中所述VPL的基本要求。
As described before, any solution is expected to have mechanisms for efficient transport of IP multicast. Multicast is related to both Issues A and B (see Section 3.2); however, broadcast is related to Issue B only because it does not need membership control.
如前所述，任何解决方案都应具有有效传输IP多播的机制。多播与问题A和B都相关（见第3.2节）；然而，广播仅与问题B相关，因为它不需要成员资格控制。
- A multicast VPLS solution SHOULD attempt to solve both Issues A and B, if possible. However, since some applications prioritize solving one issue over the other, the solution MUST identify which Issue (A or B) it is attempting to solve. The solution SHOULD provide a basis for evaluating how well it solves the issue(s) it is targeting, if it is providing an approximate solution.
- 如果可能，多播VPLS解决方案应尝试解决问题A和问题B。但是，由于某些应用程序优先解决一个问题而不是另一个问题，因此解决方案必须确定它试图解决的问题（A或B）。如果该解决方案提供了近似解决方案，则该解决方案应为评估其解决目标问题的效果提供依据。
Unknown destination MAC unicast requires flooding, but its characteristics are quite different from multicast/broadcast. When the unicast MAC address is learned, the PE changes its forwarding behavior from flooding over all PWs into sending over one PW. Thereby, it will require different technical studies from multicast/ broadcast, which is out of scope of this document.
未知目的MAC单播需要泛洪，但其特性与多播/广播有很大不同。当学习到单播MAC地址时，PE将其转发行为从在所有PW上泛滥更改为在一个PW上发送。因此，需要对多播/广播进行不同的技术研究，这超出了本文件的范围。
Ethernet multicast is used for conveying Layer-3 multicast data. When IP multicast is encapsulated by an Ethernet frame, the IP multicast group address is mapped to the Ethernet destination MAC address. In IPv4, the mapping uses the lower 23 bits of the (32-bit) IPv4 multicast address and places them as the lower 23 bits of a destination MAC address with the fixed header of 01-00-5E in hex. Since this mapping is ambiguous (i.e., there is a multiplicity of 1 Ethernet address to 32 IPv4 addresses), MAC-based forwarding is not ideal for IP multicast because some hosts might possibly receive packets they are not interested in, which is inefficient in traffic
以太网组播用于传输第三层组播数据。当IP多播被以太网帧封装时，IP多播组地址映射到以太网目标MAC地址。在IPv4中，映射使用（32位）IPv4多播地址的较低23位，并将其作为目标MAC地址的较低23位，固定标头为01-00-5E（十六进制）。由于此映射不明确（即，存在1个以太网地址到32个IPv4地址的多重性），因此基于MAC的转发对于IP多播并不理想，因为某些主机可能会接收到他们不感兴趣的数据包，这在通信量方面效率低下
delivery and has an impact on security. On the other hand, if the solution tracks IP addresses rather than MAC addresses, this concern can be prevented. The drawback of this approach is, however, that the network administration becomes slightly more complicated.
交付并对安全性有影响。另一方面，如果解决方案跟踪IP地址而不是MAC地址，则可以防止这种问题。然而，这种方法的缺点是，网络管理变得稍微复杂一些。
Ethernet multicast is also used for Layer-2 control frames. For example, BPDU (Bridge Protocol Data Unit) for IEEE 802.1D Spanning Trees uses a multicast destination MAC address (01-80-C2-00-00-00). Also, some of IEEE 802.1ag [802.1ag] Connectivity Fault Management (CFM) messages use a multicast destination MAC address dependent on their message type and application. From the perspective of IP multicast, however, it is necessary in VPLS to flood such control frames to all participating CEs, without requiring any membership controls.
以太网多播也用于第2层控制帧。例如，IEEE 802.1D生成树的BPDU（网桥协议数据单元）使用多播目标MAC地址（01-80-C2-00-00-00）。此外，一些IEEE 802.1ag[802.1ag]连接故障管理（CFM）消息根据其消息类型和应用程序使用多播目标MAC地址。然而，从IP多播的角度来看，在VPLS中有必要将这样的控制帧泛洪到所有参与的CE，而不需要任何成员控制。
As for a multicast VPLS solution, it can only use Ethernet-related information, if you stand by the strict application of the basic requirement: "a L2VPN service SHOULD be agnostic to customer's Layer 3 traffic" [RFC4665]. This means no Layer-3 information should be checked for transport. However, it is obvious this is an impediment to solve Issue A.
对于多播VPLS解决方案，如果严格遵守基本要求：“L2VPN服务应与客户的第3层流量无关”[RFC4665]，则只能使用与以太网相关的信息。这意味着不应检查传输的第3层信息。然而，这显然是解决问题A的障碍。
Consequently, a multicast VPLS can be allowed to make use of some Layer-3-related supplementary information in order to improve transport efficiency. In fact, today's LAN-switch implementations often support such approaches and snoop upper-layer protocols and examine IP multicast memberships (e.g., Protocol Independent Multicast (PIM) snooping and IGMP/MLD (Multicast Listener Discovery) snooping [RFC4541]). This will implicitly suggest that VPLS may adopt similar techniques although this document does NOT state Layer-3 snooping is mandatory. If such an approach is taken, careful consideration of Layer-3 state maintenance is necessary. In addition, note that snooping approaches sometimes have disadvantages in the system's transparency; that is, one particular protocol's snooping solution might hinder other (especially future) protocol's working (e.g., an IGMPv2-snooping switch vs. a new IGMPv3-snooping one). Also, note that there are potential alternatives to snooping:
因此，可以允许多播vpl利用一些与第3层相关的补充信息来提高传输效率。事实上，今天的LAN交换机实现通常支持此类方法和嗅探上层协议，并检查IP多播成员身份（例如，协议独立多播（PIM）嗅探和IGMP/MLD（多播侦听器发现）嗅探[RFC4541]）。这将暗示VPL可能采用类似的技术，尽管本文件未说明第3层窥探是强制性的。如果采用这种方法，则有必要仔细考虑第3层状态维护。此外，请注意，窥探方法有时在系统的透明度方面有缺点；也就是说，一个特定协议的窥探解决方案可能会妨碍其他（特别是未来）协议的工作（例如，IGMPv2窥探交换机与新的IGMPv3窥探交换机）。此外，请注意，除了窥探，还有其他可能的替代方法：
- Static configuration of multicast Ethernet addresses and ports/ interfaces.
- 多播以太网地址和端口/接口的静态配置。
- Multicast control protocol based on Layer-2 technology that signals mappings of multicast addresses to ports/interfaces, such as Generic Attribute Registration Protocol / GARP Multicast Registration Protocol (GARP/GMRP) [802.1D], Cisco Group Management Protocol [CGMP], and Router-port Group Management Protocol (RGMP) [RFC3488].
- 基于第二层技术的多播控制协议，该技术向端口/接口发送多播地址映射信号，例如通用属性注册协议/GARP多播注册协议（GARP/GMRP）[802.1D]、Cisco组管理协议[CGMP]和路由器端口组管理协议（RGMP）[RFC3488]。
On the basis described above, general requirements about packet types are given as follows:
在上述基础上，对包类型的一般要求如下：
- A solution SHOULD support a way to facilitate IP multicast forwarding of the customers. It MAY observe Layer-3 information (i.e., multicast routing protocols and state) to the degree necessary, but any information irrelevant to multicast transport SHOULD NOT be consulted.
- 解决方案应该支持一种促进客户IP多播转发的方法。它可以在必要的程度上观察第三层信息（即多播路由协议和状态），但不应参考任何与多播传输无关的信息。
- In a solution, Layer-2 control frames (e.g., BPDU, 802.1ag CFM) SHOULD be flooded to all PE/CEs in a common VPLS instance. A solution SHOULD NOT change or limit the flooding scope to remote PE/CEs in terms of end-point reachability.
- 在解决方案中，第2层控制帧（例如，BPDU、802.1ag CFM）应被淹没到公共VPLS实例中的所有PE/CE。解决方案不应改变或限制远程PE/CE在端点可达性方面的泛洪范围。
- In a solution, Layer-2 frames that encapsulate Layer-3 multicast control packets (e.g., PIM, IGMP (for IPv4), and MLD (for IPv6)) MAY be flooded only to relevant members, with the goal of limiting flooding scope. However, Layer-2 frames that encapsulate other Layer-3 control packets (e.g., OSPF, IS-IS) SHOULD be flooded to all PE/CEs in a VPLS instance.
- 在解决方案中，封装第3层多播控制分组（例如，PIM、IGMP（用于IPv4）和MLD（用于IPv6））的第2层帧可以仅被泛洪到相关成员，目的是限制泛洪范围。但是，封装其他第3层控制数据包（例如，OSPF、IS-IS）的第2层帧应被淹没到VPLS实例中的所有PE/CE。
In a common VPLS architecture, MAC learning is carried out by PEs based on the incoming frame's source MAC address, independently of the destination MAC address (i.e., regardless of whether it is unicast, multicast, or broadcast). This is the case with the multicast VPLS solution's environment too. In this document, the improvement of MAC learning scalability is beyond the scope. It will be covered in future work.
在公共VPLS体系结构中，MAC学习由PEs基于传入帧的源MAC地址执行，独立于目标MAC地址（即，无论是单播、多播还是广播）。多播VPLS解决方案的环境也是如此。在本文中，MAC学习可伸缩性的改进超出了范围。这将在今后的工作中讨论。
A solution SHOULD allow static configuration to account for various operator policies, where the logical multicast topology does not change dynamically in conjunction with a customer's multicast routing.
解决方案应允许静态配置考虑各种操作员策略，其中逻辑多播拓扑不会随客户的多播路由而动态更改。
A solution SHOULD be backward compatible with the existing VPLS solution. It SHOULD allow a case where a common VPLS instance is composed of both PEs supporting the solution and PEs not supporting it, and the multicast optimization (both forwarding and receiving) is achieved between the compliant PEs.
解决方案应与现有VPLS解决方案向后兼容。在这种情况下，公共VPLS实例由支持解决方案的PE和不支持解决方案的PE组成，并且在兼容的PE之间实现多播优化（转发和接收）。
Note again that the existing VPLS solutions already have a simple flooding capability. Thus, this backward compatibility will give customers and SPs the improved efficiency of multicast forwarding incrementally as the solution is deployed.
再次注意，现有的VPLS解决方案已经具有简单的泛洪功能。因此，这种向后兼容性将使客户和SP在部署解决方案时逐步提高多播转发的效率。
A solution SHOULD allow transparent operation of Ethernet control protocols employed by customers (e.g., Spanning Tree Protocol [802.1D]) and their seamless operation with multicast data transport.
解决方案应允许客户使用的以太网控制协议（例如，生成树协议[802.1D]）的透明操作及其与多播数据传输的无缝操作。
Solutions MAY examine Ethernet multicast control frames for the purpose of efficient dynamic transport (e.g., GARP/GMRP [802.1D]). However, solutions MUST NOT assume all CEs are always running such protocols (typically in the case where a CE is a router and is not aware of Layer-2 details).
解决方案可以检查以太网多播控制帧以实现高效的动态传输（例如，GARP/GMRP[802.1D]）。但是，解决方案不得假设所有CE始终运行此类协议（通常在CE是路由器且不知道第2层细节的情况下）。
A whole Layer-2 multicast frame (whether for data or control) SHOULD NOT be altered from a CE to CE(s) EXCEPT for the VLAN ID field, ensuring that it is transparently transported. If VLAN IDs are assigned by the SP, they can be altered. Note, however, when VLAN IDs are changed, Layer-2 protocols may be broken in some cases, such as Multiple Spanning Trees [802.1s]. Also, if the Layer-2 frame is encapsulating a Layer-3 multicast control packet (e.g., PIM/IGMP) and customers allow it to be regenerated at the PE (aka proxy: see Section 5.1.2), then the MAC address for that frame MAY be altered to the minimum necessary (e.g., use PE's own MAC address as a source).
除VLAN ID字段外，不应将整个第2层多播帧（无论用于数据还是控制）从CE更改为CE，以确保其传输透明。如果VLAN ID由SP分配，则可以对其进行更改。但是，请注意，当VLAN ID发生更改时，在某些情况下可能会破坏第2层协议，例如多个生成树[802.1s]。此外，如果第2层帧封装第3层多播控制分组（例如，PIM/IGMP），并且客户允许在PE处重新生成该分组（又名代理：参见第5.1.2节），则该帧的MAC地址可以更改为所需的最小值（例如，使用PE自己的MAC地址作为源）。
Again, a solution MAY examine the customer's Layer-3 multicast protocol packets for the purpose of efficient and dynamic transport. If it does, supported protocols SHOULD include:
同样，为了高效和动态传输的目的，解决方案可以检查客户的第3层多播协议分组。如果有，受支持的协议应包括：
o PIM-SM (Sparse Mode) [RFC4601], PIM-SSM (Source-Specific Multicast) [RFC4607], bidirectional PIM [RFC5015], and PIM-DM (Dense Mode) [RFC3973].
o PIM-SM（稀疏模式）[RFC4601]、PIM-SSM（源特定多播）[RFC4607]、双向PIM[RFC5015]和PIM-DM（密集模式）[RFC3973]。
o IGMP (v1 [RFC1112], v2 [RFC2236], and v3 [RFC3376]) (for IPv4 solutions).
o IGMP（v1[RFC1112]、v2[RFC2236]和v3[RFC3376]）（用于IPv4解决方案）。
o Multicast Listener Discovery Protocol (MLD) (v1 [RFC2710] and v2 [RFC3810]) (for IPv6 solutions).
o 多播侦听器发现协议（MLD）（v1[RFC2710]和v2[RFC3810]）（用于IPv6解决方案）。
A solution MUST NOT require any special Layer-3 multicast protocol packet processing by the end users. However, it MAY require some configuration changes (e.g., turning explicit tracking on/off in the PIM).
解决方案不得要求终端用户进行任何特殊的第3层多播协议数据包处理。但是，它可能需要一些配置更改（例如，在PIM中打开/关闭显式跟踪）。
A whole Layer-3 multicast packet (whether for data or control), which is encapsulated inside a Layer-2 frame, SHOULD NOT be altered from a CE to CE(s), ensuring that it is transparently transported. However, as for Layer-3 multicast control (like PIM Join/Prune/Hello and IGMP Query/Report packet), it MAY be altered to the minimum necessary if such partial non-transparency is acceptable from point of view of the multicast service. Similarly, a PE MAY consume such Layer-3 multicast control packets and regenerate an entirely new packet if partial non-transparency is acceptable with legitimate reason for customers (aka proxy).
封装在第2层帧内的整个第3层多播数据包（无论用于数据还是控制）不应从CE更改为CE，以确保其传输透明。然而，对于第3层多播控制（如PIM Join/Prune/Hello和IGMP查询/报告包），如果从多播服务的角度来看这种部分非透明性是可接受的，则可以将其更改为最低限度。类似地，如果出于客户的合法理由（aka代理）部分不透明是可接受的，则PE可以使用这样的第3层多播控制分组并重新生成一个全新的分组。
As noted in Section 2.1, the term "multicast domain" is used in a generic context for Layer-2 and Layer-3.
如第2.1节所述，术语“多播域”在第2层和第3层的通用上下文中使用。
A solution SHOULD NOT alter the boundaries of customer multicast domains. It MUST ensure that the provided Ethernet multicast domain always encompasses the corresponding customer Layer-3 multicast domain.
解决方案不应改变客户多播域的边界。它必须确保提供的以太网多播域始终包含相应的客户第3层多播域。
A solution SHOULD optimize those domains' coverage sizes, i.e., a solution SHOULD ensure that unnecessary traffic is not sent to CEs with no members. Ideally, the provided domain size will be close to that of the customer's Layer-3 multicast membership distribution; however, it is OPTIONAL to achieve such absolute optimality from the perspective of Layer-3.
解决方案应优化这些域的覆盖范围大小，即，解决方案应确保不必要的流量不会发送到没有成员的CEs。理想情况下，提供的域大小将接近客户的第3层多播成员分布的域大小；然而，从第三层的角度来看，实现这种绝对最优是可选的。
If a customer uses VLANs and a VLAN ID as a service delimiter (i.e., each VPLS instance is represented by a unique customer VLAN tag carried by a frame through the User Network Interface (UNI) port), a solution MUST provide a separate multicast domain for each VLAN ID. Note that if VLAN ID translation is provided (i.e., if a customer VLAN at one site is mapped into a different customer VLAN at a different site), multicast domains will be created per set of VLAN IDs that are associated with translation.
如果客户使用VLAN和VLAN ID作为服务分隔符（即，每个VPLS实例由帧通过用户网络接口（UNI）端口携带的唯一客户VLAN标记表示），则解决方案必须为每个VLAN ID提供单独的多播域。请注意，如果提供VLAN ID转换（即，如果一个站点的客户VLAN映射到另一个站点的另一个客户VLAN），将为与转换相关联的每组VLAN ID创建多播域。
If a customer uses VLANs but a VLAN ID is not a service delimiter (i.e., the VPN disregards customer VLAN IDs), a solution MAY provide a separate multicast domain for each VLAN ID. An SP is not mandatorily required to provide a separate multicast domain for each VLAN ID, but it may be considered beneficial to do so.
如果客户使用VLAN，但VLAN ID不是服务分隔符（即，VPN忽略客户VLAN ID），则解决方案可以为每个VLAN ID提供单独的多播域。SP不必强制要求为每个VLAN ID提供单独的多播域，但这样做可能是有益的。
A solution MAY build multicast domains based on Ethernet MAC addresses. It MAY also build multicast domains based on the IP addresses inside Ethernet frames. That is, PEs in each VPLS instance might control forwarding behavior and provide different multicast frame reachability depending on each MAC/IP destination address separately. If IP multicast channels are fully considered in a solution, the provided domain size will be closer to actual channel reachability.
解决方案可以基于以太网MAC地址构建多播域。它还可以基于以太网帧内的IP地址构建多播域。也就是说，每个VPLS实例中的PE可能控制转发行为，并分别根据每个MAC/IP目标地址提供不同的多播帧可达性。如果在解决方案中充分考虑IP多播信道，则提供的域大小将更接近实际的信道可达性。
Customers require that multicast quality of service MUST be at least on par with what exists for unicast traffic. Moreover, as multicast is often used to deliver high-quality services such as TV broadcast, delay-, jitter-, and loss-sensitive traffic MUST be supported over multicast VPLS.
客户要求多播服务质量必须至少与单播业务存在的一致性。此外，由于多播通常用于提供高质量服务，如电视广播，因此必须通过多播VPL支持延迟、抖动和丢失敏感流量。
To accomplish this, the solution MAY have additional features to support high QoS such as bandwidth reservation and flow admission control. Also, multicast VPLS deployment SHALL benefit from IEEE 802.1p Class-of-Service (CoS) techniques [802.1D] and Diffserv [RFC2475] mechanisms.
为了实现这一点，该解决方案可以具有支持高QoS的附加特性，例如带宽预留和流许可控制。此外，多播VPLS部署应受益于IEEE 802.1p服务类（CoS）技术[802.1D]和区分服务[RFC2475]机制。
Moreover, multicast traffic SHOULD NOT affect the QoS that unicast traffic receives and vice versa. That is, separation of multicast and unicast traffic in terms of QoS is necessary.
此外，多播流量不应影响单播流量接收的QoS，反之亦然。也就是说，就QoS而言，多播和单播业务的分离是必要的。
Since SLA parameters are part of the service sold to customers, they simply want to verify their application performance by measuring the parameters SP(s) provide.
由于SLA参数是销售给客户的服务的一部分，他们只想通过测量SP提供的参数来验证其应用程序性能。
Multicast specific characteristics that may be monitored are, for instance, multicast statistics per stream (e.g., total/incoming/ outgoing/dropped traffic by period of time), one-way delay, jitter and group join/leave delay (time to start receiving traffic from a multicast group across the VPN since the join/leave was issued). An operator may also wish to compare the difference in one-way delay for a solitary multicast group/stream from a single, source PE to multiple receiver PEs.
可以监控的组播特定特性是，例如，每个流的组播统计信息（例如，按时间段划分的总/传入/传出/丢弃流量）、单向延迟、抖动和组加入/离开延迟（自发出加入/离开后开始通过VPN接收来自多播组的流量的时间）。运营商还可能希望比较从单个源PE到多个接收器PE的单独多播组/流的单向延迟差异。
A solution SHOULD provide these parameters with Ethernet multicast group level granularity. (For example, a multicast MAC address will be one of those entries for classifying flows with statistics, delay, and so on.) However, if a solution is aimed at IP multicast transport efficiency, it MAY support IP multicast-level granularity.
解决方案应提供具有以太网多播组级粒度的这些参数。（例如，多播MAC地址将是使用统计信息、延迟等对流进行分类的条目之一。）但是，如果解决方案旨在提高IP多播传输效率，则它可能支持IP多播级别的粒度。
(For example, multicast IP address/channel will be entries for latency time.)
（例如，多播IP地址/通道将作为延迟时间的条目。）
In order to monitor them, standard interfaces for statistics gathering SHOULD also be provided (e.g., standard Simple Network Management Protocol (SNMP) MIB Modules).
为了对其进行监控，还应提供统计数据收集的标准接口（例如，标准简单网络管理协议（SNMP）MIB模块）。
A solution MUST provide customers with architectures that give the same level of security both for unicast and multicast.
解决方案必须为客户提供为单播和多播提供相同安全级别的体系结构。
Solutions SHOULD NOT affect any forwarding information base, throughput, or resiliency, etc., of unicast frames; that is, they SHOULD provide isolation from unicast.
解决方案不应影响单播帧的任何转发信息库、吞吐量或弹性等；也就是说，它们应该提供与单播的隔离。
A solution MAY filter multicast traffic inside a VPLS, upon the request of an individual customer, (for example, MAC/VLAN filtering, IP multicast channel filtering, etc.).
解决方案可以根据单个客户的请求过滤VPLS内的多播通信量（例如，MAC/VLAN过滤、IP多播信道过滤等）。
A solution SHOULD support policing and shaping multicast traffic on a per-customer basis and on a per-AC (Attachment Circuit) basis. This is intended to prevent multicast traffic from exhausting resources for unicast inside a common customer's VPN. This might also be beneficial for QoS separation (see Section 5.3).
解决方案应支持在每个客户和每个AC（连接电路）的基础上对多播流量进行管理和塑造。这是为了防止多播通信耗尽公共客户VPN内单播的资源。这也可能有利于QoS分离（见第5.3节）。
First and foremost, various physical connectivity types described in [RFC4665] MUST be supported.
首先，必须支持[RFC4665]中描述的各种物理连接类型。
A multicast VPLS MUST allow a situation in which a CE is dual-homed to two different SPs via diverse access networks -- one is supporting multicast VPLS but the other is not supporting it, (because it is an existing VPLS or 802.1Q/QinQ network).
多播VPLS必须允许CE通过不同的接入网络双驻留到两个不同SP的情况——一个支持多播VPLS，但另一个不支持多播VPLS（因为它是现有的VPLS或802.1Q/QinQ网络）。
A multicast VPLS infrastructure SHOULD allow redundant paths to assure high availability.
多播VPLS基础设施应允许冗余路径，以确保高可用性。
Multicast forwarding restoration time MUST NOT be greater than the time it takes a customer's Layer-3 multicast protocols to detect a failure in the VPLS infrastructure. For example, if a customer uses PIM with default configuration, the hello hold timer is 105 seconds, and solutions are required to restore a failure no later than this period. To achieve this, a solution might need to support providing alternative multicast paths.
多播转发恢复时间不得大于客户的第3层多播协议检测VPLS基础结构中的故障所需的时间。例如，如果客户使用具有默认配置的PIM，hello hold计时器为105秒，并且需要解决方案在不晚于此时间段内恢复故障。要实现这一点，解决方案可能需要支持提供替代多播路径。
Moreover, if multicast forwarding was not successfully restored (e.g., in case of no redundant paths), a solution MAY raise alarms to provide outage notification to customers before such a hold timer expires.
此外，如果多播转发未成功恢复（例如，在没有冗余路径的情况下），则解决方案可能会发出警报，以便在此类保持计时器到期之前向客户提供中断通知。
Multicast applications are often sensitive to packet fragmentation and reassembly, so the requirement to avoid fragmentation might be stronger than the existing VPLS solution.
多播应用程序通常对数据包碎片和重组非常敏感，因此避免碎片的要求可能比现有的VPLS解决方案更高。
A solution SHOULD provide customers with enough committed minimum MTU (i.e., service MTU) for multicast Ethernet frames to ensure that IP fragmentation between customer sites never occurs. It MAY give different MTU sizes to multicast and unicast.
解决方案应为客户提供足够多播以太网帧的承诺最小MTU（即服务MTU），以确保客户站点之间不会出现IP碎片。它可以为多播和单播提供不同的MTU大小。
A solution SHOULD attempt to prevent frame reordering when delivering customer multicast traffic. Likewise, for unicast and unknown unicast traffic, it SHOULD attempt not to increase the likelihood of reordering compared with existing VPLS solutions.
解决方案应尝试在交付客户多播流量时防止帧重新排序。同样，对于单播和未知单播流量，与现有的VPLS解决方案相比，它应尽量不增加重新排序的可能性。
It is to be noted that delivery of out-of-order frames is not avoidable in certain cases. Specifically, if a solution adopts some MDTunnels (see Section 6.2) and dynamically selects them for optimized delivery (e.g., switching from one aggregate tree to another), end-to-end data delivery is prone to be out of order. This fact can be considered a trade-off between bandwidth optimization and network stability. Therefore, such a solution is expected to promote awareness about this kind of drawback.
需要注意的是，在某些情况下，无法避免交付无序框架。具体而言，如果解决方案采用一些MDTunnel（参见第6.2节）并动态选择它们以进行优化交付（例如，从一个聚合树切换到另一个聚合树），则端到端数据交付容易出现故障。这一事实可以被认为是带宽优化和网络稳定性之间的权衡。因此，这种解决方案有望提高人们对这种缺陷的认识。
In native Ethernet, multicast and unicast connectivity are often managed together. For instance, an 802.1ag CFM Continuity Check message is forwarded by multicast as a periodic heartbeat, but it is supposed to check the "whole" traffic continuity regardless of unicast or multicast, at the same time. Hence, the aliveness of
在本机以太网中，多播和单播连接通常一起管理。例如，802.1ag CFM连续性检查消息由多播作为周期心跳转发，但它应该同时检查“整个”流量连续性，而不管是单播还是多播。因此，这项技术的活力
unicast and multicast is naturally coupled (i.e., fate-shared) in this customer's environment.
单播和多播在该客户的环境中自然耦合（即命运共享）。
A multicast VPLS solution may decouple the path that a customer's unicast and multicast traffic follow through a SP's backbone, in order to provide the most optimal path for multicast data traffic. This may cause concern among some multicast VPLS customers who desire that, during a failure in the SP's network, both unicast and multicast traffic fail concurrently.
多播VPLS解决方案可以将客户的单播和多播流量通过SP主干的路径解耦，以便为多播数据流量提供最佳路径。这可能会引起一些多播VPLS客户的担忧，他们希望在SP的网络发生故障期间，单播和多播流量同时发生故障。
Therefore, there will be an additional requirement that makes both unicast and multicast connectivity coupled. This means that if either one of them have a failure, the other is also disabled. If one of the services (either unicast or multicast) becomes operational, the other is also activated simultaneously.
因此，将有一个额外的要求，使单播和多播连接耦合。这意味着，如果其中一个出现故障，另一个也将被禁用。如果其中一个服务（单播或多播）开始运行，另一个服务也会同时激活。
- It SHOULD be identified if the solution can provide customers with fate-sharing between unicast and multicast connectivity for their LAN switching application. It MAY have a configurable mechanism for SPs to provide that on behalf of customers, e.g., aliveness synchronization, but its use is OPTIONAL.
- 应该确定该解决方案是否可以为客户的LAN交换应用程序提供单播和多播连接之间的命运共享。它可能有一个SPs可配置的机制，以代表客户提供该机制，例如，有效性同步，但其使用是可选的。
This policy will benefit customers. Some customers would like to detect failure soon at CE side and restore full connectivity by switching over to their backup line, rather than to keep poor half connectivity (i.e., either unicast or multicast being in fail). Even if either unicast or multicast is kept alive, it is just disadvantageous to the customer's application protocols that need both types of traffic. Fate-sharing policy contributes to preventing such a complicated situation.
这项政策将使客户受益。一些客户希望很快在CE端检测到故障，并通过切换到其备份线路来恢复完全连接，而不是保持较差的半连接（即单播或多播失败）。即使单播或多播保持活动状态，这对需要这两种类型流量的客户应用程序协议也是不利的。命运分享政策有助于防止出现如此复杂的局面。
Note that how serious this issue is depends on each customer's stance in Ethernet operation. If all CEs are IP routers, i.e., if VPLS is provided for a LAN routing application, the customer might not care about it because both unicast and multicast connectivity is assured in the IP layer. If the CE routers are running an IGP (e.g., OSPF/ IS-IS) and a multicast routing protocol (e.g., PIM), then aliveness of both the unicast and multicast paths will be detected by the CEs. This does not guarantee that unicast and multicast traffic are to follow the same path in the SP's backbone network, but does mitigate this issue to some degree.
请注意，此问题的严重程度取决于每个客户在以太网操作中的立场。如果所有CE都是IP路由器，即如果为LAN路由应用程序提供VPL，则客户可能不关心它，因为单播和多播连接都在IP层得到保证。如果CE路由器正在运行IGP（例如，OSPF/IS-IS）和多播路由协议（例如，PIM），则CEs将检测单播和多播路径的有效性。这并不保证单播和多播流量在SP的主干网络中遵循相同的路径，但在一定程度上缓解了这一问题。
The existing VPLS architecture has major advantages in scalability. For example, P-routers are free from maintaining customers' information because customer traffic is encapsulated in PSN tunnels. Also, a PW's split-horizon technique can prevent loops, making PE routers free from maintaining complicated spanning trees.
现有的VPLS体系结构在可扩展性方面具有主要优势。例如，P路由器不需要维护客户信息，因为客户流量封装在PSN隧道中。此外，PW的分割地平线技术可以防止循环，使PE路由器不必维护复杂的生成树。
However, a multicast VPLS needs additional scalability considerations related to its expected enhanced mechanisms. [RFC3809] lists common L2VPN sizing and scalability requirements and metrics, which are applicable in multicast VPLS too. Accordingly, this section deals with specific requirements related to scalability.
然而，多播VPLS需要考虑与其预期的增强机制相关的额外可伸缩性。[RFC3809]列出了常见的L2VPN大小和可扩展性要求和指标，这些要求和指标也适用于多播VPL。因此，本节讨论与可伸缩性相关的特定需求。
A solution needs to improve the scalability of multicast as is shown in Section 3:
解决方案需要提高多播的可伸缩性，如第3节所示：
Issue A: Replication to non-member site.
问题A：复制到非成员站点。
Issue B: Replication of PWs on shared physical path.
问题B：在共享物理路径上复制PWs。
For both issues, the optimization of physical resources (i.e., link bandwidth usage and router duplication performance) will become a major goal. However, there is a trade-off between optimality and state resource consumption.
对于这两个问题，优化物理资源（即链路带宽使用和路由器复制性能）将成为一个主要目标。然而，在优化和国家资源消耗之间存在着权衡。
In order to solve Issue A, a PE might have to maintain multicast group information for CEs that was not kept in the existing VPLS solutions. This will present scalability concerns about state resources (memory, CPU, etc.) and their maintenance complexity.
为了解决问题A，PE可能必须维护现有VPLS解决方案中未保存的CE的多播组信息。这将提出有关状态资源（内存、CPU等）及其维护复杂性的可伸缩性问题。
In order to solve Issue B, PE and P routers might have to have knowledge of additional membership information for remote PEs, and possibly additional tree topology information, when they are using point-to-multipoint (P2MP) techniques (PIM tree, P2MP-LSP (Label Switched Path), etc.).
为了解决问题B，PE和P路由器在使用点对多点（P2MP）技术（PIM树、P2MP-LSP（标签交换路径）等）时，可能必须了解远程PE的附加成员信息，以及可能的附加树拓扑信息。
Consequently, the scalability evaluation of multicast VPLS solutions needs a careful trade-off analysis between bandwidth optimality and state resource consumption.
因此，多播VPLS解决方案的可伸缩性评估需要在带宽优化和状态资源消耗之间进行仔细的权衡分析。
(Note: This part has a number of similar characteristics to requirements for Layer-3 Multicast VPN [RFC4834].)
（注：本部分具有许多与第三层多播VPN[RFC4834]要求类似的特征。）
A multicast VPLS solution MUST be designed to scale well with an increase in the number of any of the following metrics:
多播VPLS解决方案的设计必须能够随着以下指标数量的增加而良好扩展：
- the number of PEs
- PEs的数量
- the number of VPLS instances (total and per PE)
- VPLS实例数（总数和每个PE）
- the number of PEs and sites in any VPLS instance
- 任何VPLS实例中的PE和站点数
- the number of client VLAN IDs
- 客户端VLAN ID的数量
- the number of client Layer-2 MAC multicast groups
- 客户端第2层MAC多播组的数量
- the number of client Layer-3 multicast channels (groups or source-groups)
- 客户端第3层多播通道（组或源组）的数量
- the number of PWs and PSN Tunnels (MDTunnels) (total and per PE)
- PWs和PSN隧道（MDTunnels）的数量（总数和每个PE）
Each multicast VPLS solution SHALL document its scalability characteristics in quantitative terms. A solution SHOULD quantify the amount of state that a PE and a P device has to support.
每个多播VPLS解决方案应以定量方式记录其可扩展性特征。解决方案应量化PE和P设备必须支持的状态量。
The scalability characteristics SHOULD include:
可伸缩性特征应包括：
- the processing resources required by the control plane in managing PWs (neighborhood or session maintenance messages, keepalives, timers, etc.)
- 控制平面在管理PWs（邻居或会话维护消息、keepalives、计时器等）时所需的处理资源
- the processing resources required by the control plane in managing PSN tunnels
- 管理PSN隧道时控制平面所需的处理资源
- the memory resources needed for the control plane
- 控制平面所需的内存资源
- the amount of protocol information transmitted to manage a multicast VPLS (e.g., signaling throughput)
- 为管理多播VPLS而传输的协议信息量（例如，信令吞吐量）
- the amount of Layer-2/Layer-3 multicast information a P/PE router consumes (e.g., traffic rate of join/leave, keepalives, etc.)
- P/PE路由器消耗的第2层/第3层多播信息量（例如，加入/离开、保留等的通信速率）
- the number of multicast IP addresses used (if IP multicast in ASM mode is proposed as a multicast distribution tunnel)
- 使用的多播IP地址数（如果ASM模式下的IP多播被建议作为多播分发隧道）
- other particular elements inherent to each solution that impact scalability
- 每个解决方案固有的影响可伸缩性的其他特定元素
Another metric for scalability is operational complexity. Operations will naturally become more complicated if the number of managed objects (e.g., multicast groups) increases, or the topology changes occur more frequently. A solution SHOULD note the factors that lead to additional operational complexity.
可伸缩性的另一个指标是操作复杂性。如果托管对象（例如，多播组）的数量增加，或者拓扑更改更频繁，那么操作自然会变得更加复杂。解决方案应注意导致额外操作复杂性的因素。
An MDTunnel denotes a multicast distribution tunnel. This is a generic term for tunneling where customer multicast traffic is carried over a provider's network. In the L2VPN service context, it will correspond to a PSN tunnel.
MDTunnel表示多播分发隧道。这是隧道的通用术语，其中客户多播流量通过提供商的网络传输。在L2VPN服务上下文中，它将对应于PSN隧道。
A solution SHOULD be able to use a range of tunneling technologies, including point-to-point (unicast oriented) and point-to-multipoint/ multipoint-to-multipoint (multicast oriented). For example, today there are many kinds of protocols for tunneling such as L2TP, IP, (including multicast IP trees), MPLS (including P2MP-LSP [RFC4875], and P2MP/MP2MP-LSP [LDP-P2MP]), etc.
解决方案应该能够使用一系列隧道技术，包括点对点（面向单播）和点对多点/多点对多点（面向多播）。例如，目前有许多种隧道协议，如L2TP、IP（包括多播IP树）、MPLS（包括P2MP-LSP[RFC4875]和P2MP/MP2MP-LSP[LDP-P2MP]）等。
Note that which variant, point-to-point, point-to-multipoint, or multipoint-to-multipoint, is used depends largely on the trade-offs mentioned above and the targeted network and applications. Therefore, this document does not mandate any specific protocols. A solution, however, SHOULD state reasonable criteria if it adopts a specific kind of tunneling protocol.
请注意，使用哪种变体，即点对点、点对多点或多点对多点，在很大程度上取决于上述权衡以及目标网络和应用程序。因此，本文件不强制执行任何特定协议。但是，如果解决方案采用特定类型的隧道协议，则应说明合理的标准。
From the view of an SP, it is not acceptable to have fragmentation/ reassembly so often while packets are traversing a MDTunnel. Therefore, a solution SHOULD support a method that provides the minimum path MTU of the MDTunnel in order to accommodate the service MTU.
从SP的角度来看，在数据包穿越MDT隧道时如此频繁地进行碎片/重组是不可接受的。因此，解决方案应支持提供MDTunnel的最小路径MTU的方法，以适应服务MTU。
Multicast VPLS solutions SHOULD avoid single points of failures or propose technical solutions that make it possible to implement a failover mechanism.
多播VPLS解决方案应避免单点故障，或提出能够实现故障切换机制的技术解决方案。
The operation of a multicast VPLS solution SHALL be as light as possible, and providing automatic configuration and discovery SHOULD be considered a high priority.
多播VPLS解决方案的操作应尽可能轻，提供自动配置和发现应被视为高优先级。
Therefore, in addition to the L2VPN discovery requirements in [RFC4665], a multicast VPLS solution SHOULD provide a method that dynamically allows multicast membership information to be discovered by PEs if the solution supports (A), as defined in Section 3.2. This means, a PE needs to discover multicast membership (e.g., join group addresses) that is controlled dynamically from the sites connected to that PE. In addition, a PE needs to discover such information automatically from other remote PEs as well in order to limit flooding scope across the backbone.
因此，除了[RFC4665]中的L2VPN发现要求外，多播VPLS解决方案还应提供一种方法，如果该解决方案支持第3.2节中定义的（a），则该方法应动态允许PEs发现多播成员信息。这意味着，PE需要发现从连接到该PE的站点动态控制的多播成员身份（例如，加入组地址）。此外，PE还需要从其他远程PE自动发现此类信息，以限制主干上的泛洪范围。
The activation of multicast enhancement in a solution MUST be possible:
必须能够在解决方案中激活多播增强功能：
o with a VPLS instance granularity.
o 具有VPLS实例粒度。
o with an Attachment Circuit granularity (i.e., with a PE-CE Ethernet port granularity, or with a VLAN ID granularity when it is a service delimiter).
o 具有连接电路粒度（即，具有PE-CE以太网端口粒度，或具有VLAN ID粒度（当它是服务分隔符时）。
Also it SHOULD be possible:
还应可能：
o with a CE granularity (when multiple CEs of the same VPN are associated with a common VPLS instance).
o 具有CE粒度（当同一VPN的多个CE与公共VPLS实例关联时）。
o with a distinction between multicast reception and emission.
o 区分多播接收和发射。
o with a multicast MAC address granularity.
o 具有多播MAC地址粒度。
o with a customer IP multicast group and/or channel granularity (when Layer-3 information is consulted).
o 使用客户IP多播组和/或通道粒度（当参考第3层信息时）。
Also it MAY be possible:
也有可能：
o with a VLAN ID granularity when it is not a service delimiter.
o 当不是服务分隔符时，使用VLAN ID粒度。
A solution MUST provide a mechanism for testing multicast data connectivity and verifying the associated information. Examples that SHOULD be supported that are specific to multicast are:
解决方案必须提供用于测试多播数据连接和验证相关信息的机制。应支持的特定于多播的示例有：
- Testing connectivity per multicast MAC address
- 测试每个多播MAC地址的连接性
- Testing connectivity per multicast Layer-3 group/channel
- 测试每个多播第3层组/通道的连接性
- Verifying data plane and control plane integrity (e.g., PW, MDTunnel)
- 验证数据平面和控制平面的完整性（如PW、MDT）
- Verifying multicast membership-relevant information (e.g., multicast MAC-addresses/PW-ports associations, Layer-3 group associations)
- 验证多播成员资格相关信息（例如，多播MAC地址/PW端口关联、第3层组关联）
Operators usually want to test if an end-to-end multicast user's connectivity is OK before and after activation. Such end-to-end multicast connectivity checking SHOULD enable the end-to-end testing of the data path used by that customer's multicast data packets. Specifically, end-to-end checking will have a CE-to-CE path test and PE-to-PE path test. A solution MUST support the PE-to-PE path test and MAY support the CE-to-CE path test.
运营商通常希望在激活前后测试端到端多播用户的连接是否正常。这种端到端多播连接检查应该能够对该客户的多播数据包使用的数据路径进行端到端测试。具体来说，端到端检查将进行CE到CE路径测试和PE到PE路径测试。解决方案必须支持PE到PE路径测试，并且可能支持CE到CE路径测试。
Also, operators will want to make use of a testing mechanism for diagnosis and troubleshooting. In particular, a solution SHOULD be able to monitor information describing how client multicast traffic is carried over the SP network. Note that if a solution supports frequent dynamic membership changes with optimized transport, troubleshooting within the SP's network will tend to be difficult.
此外，操作员还希望利用测试机制进行诊断和故障排除。特别是，解决方案应该能够监控描述客户端多播通信如何通过SP网络传输的信息。请注意，如果解决方案支持频繁的动态成员身份更改和优化的传输，则SP网络内的故障排除将变得困难。
Mechanisms to monitor multicast-specific parameters and statistics MUST be offered to the SP.
必须向SP提供监控多播特定参数和统计信息的机制。
(Note: This part has a number of similar characteristics to requirements for Layer 3 Multicast VPN [RFC4834].)
（注：本部分具有许多与第3层多播VPN[RFC4834]要求类似的特征。）
A solution MUST provide SPs with access to:
解决方案必须使SP能够访问：
- Multicast traffic statistics (total traffic forwarded, incoming, outgoing, dropped, etc., by period of time).
- 多播流量统计（按时间段划分的转发、传入、传出、丢弃等总流量）。
A solution SHOULD provide access to:
解决方案应提供以下访问权限：
- Information about a customer's multicast resource usage (the amount of multicast state and throughput).
- 有关客户多播资源使用情况的信息（多播状态量和吞吐量）。
- Performance information related to multicast traffic usage, e.g., one-way delay, jitter, loss, delay variations (the difference in one-way delay for a solitary multicast group/stream from a single, source PE to multiple receiver PEs), etc.
- 与多播流量使用相关的性能信息，例如单向延迟、抖动、丢失、延迟变化（单个多播组/流从单个源PE到多个接收器PE的单向延迟差异）等。
- Alarms when limits are reached on such resources.
- 当此类资源达到限制时发出警报。
- Statistics on decisions related to how client traffic is carried on MDTunnels (e.g., "How much traffic was switched onto a multicast tree dedicated to such groups or channels").
- 有关如何在MDTunnels上承载客户端流量的决策的统计信息（例如，“有多少流量被切换到专用于此类组或通道的多播树上”）。
- Statistics on parameters that could help the provider to evaluate its optimality/state trade-off.
- 可帮助供应商评估其最佳性/状态权衡的参数统计数据。
All or part of this information SHOULD be made available through standardized SNMP MIB Modules (Management Information Base).
所有或部分信息应通过标准化SNMP MIB模块（管理信息库）提供。
A multicast VPLS solution needs to consider those management steps taken by SPs below:
多播VPLS解决方案需要考虑以下SPS所采取的管理步骤：
o Fault detection
o 故障检测
A solution MUST provide tools that detect group membership/ reachability failure and traffic looping for multicast transport. It is anticipated that such tools are coordinated with the testing mechanisms mentioned in Section 6.5.2.
解决方案必须提供检测组成员资格/可达性故障和多播传输流量循环的工具。预计此类工具将与第6.5.2节中提到的测试机制相协调。
In particular, such mechanisms SHOULD be able to detect a multicast failure quickly, (on par with unicast cases). It SHOULD also avoid situations where multicast traffic has been in a failure state for a relatively long time while unicast traffic remains operational. If such a situation were to occur, it would end up causing problems with customer applications that depend on a combination of unicast and multicast forwarding.
特别是，这样的机制应该能够快速检测多播失败（与单播情况相一致）。它还应该避免在单播通信保持运行的情况下，多播通信已经处于故障状态相当长的时间。如果出现这种情况，最终会导致依赖单播和多播转发组合的客户应用程序出现问题。
With multicast, there may be many receivers associated with a particular multicast stream/group. As the number of receivers increases, the number of places (typically nearest the receivers) required to detect a fault will increase proportionately. This raises concerns over the scalability of
对于多播，可能有许多接收器与特定多播流/组相关联。随着接收器数量的增加，检测故障所需的位置（通常离接收器最近）数量将成比例增加。这引起了对
fault detection in large multicast deployments. Consequently, a fault detection solution SHOULD scale well; in particular, a solution should consider key metrics for scalability as described in Section 6.1.2.
大型多播部署中的故障检测。因此，故障检测解决方案应具有良好的可扩展性；特别是，解决方案应考虑可伸缩性的关键度量，如6.1.2节所述。
o Fault notification
o 故障通知
A solution MUST also provide fault notification and trouble tracking mechanisms (e.g., SNMP-trap and syslog).
解决方案还必须提供故障通知和故障跟踪机制（例如SNMP陷阱和系统日志）。
In case of multicast, one point of failure often affects a number of downstream routers/receivers that might be able to raise a notification. Hence, notification messages MAY be summarized or compressed for operators' ease of management.
在多播的情况下，一个故障点通常会影响许多下游路由器/接收器，这些路由器/接收器可能会发出通知。因此，为了便于操作员管理，可以对通知消息进行汇总或压缩。
o Fault isolation
o 故障隔离
A solution MUST provide diagnostic/troubleshooting tools for multicast as well. Also, it is anticipated that such tools are coordinated with the testing mechanisms mentioned in Section 6.5.2.
解决方案还必须为多播提供诊断/故障排除工具。此外，预计此类工具将与第6.5.2节中提到的测试机制相协调。
In particular, a solution needs to correctly identify the area inside a multicast group impacted by the failure. A solution SHOULD be able to diagnose if an entire multicast group is faulty or if some specific destinations are still alive.
特别是，解决方案需要正确识别受故障影响的多播组内的区域。解决方案应该能够诊断整个多播组是否出现故障，或者某些特定目的地是否仍处于活动状态。
In multicast VPLS, there is a concern that one or more customer nodes (presumably untrusted) might cause multicast-related attacks to the SP network. There is a danger that it might compromise some components that belong to the whole system.
在多播VPLS中，一个或多个客户节点（可能不受信任）可能会对SP网络造成多播相关攻击。它可能会危及属于整个系统的某些组件。
This subsection states possible security threats relevant to the system and whether or not they are protected against.
本小节说明了与系统相关的可能的安全威胁，以及它们是否受到保护。
General security consideration about a base VPLS (as part of L2VPNs) is referred to in [RFC4665]. The following is the threat analysis list that is inherent to multicast VPLS.
关于基本VPL（作为L2VPN的一部分）的一般安全考虑，请参见[RFC4665]。以下是多播VPL固有的威胁分析列表。
(a) Attack by a huge amount of multicast control packets.
(a) 由大量多播控制数据包发起的攻击。
There is a threat that a CE joins too many multicast groups and causes Denial of Service (DoS). This is caused by sending a large number of join/prune messages in a short time and/or
CE加入过多的多播组并导致拒绝服务（DoS）是一种威胁。这是由于在短时间内和/或
putting a large variety of group addresses in join/prune messages. This attack will waste PE's control resources (e.g., CPU, memory) that examine customer control messages (for solving Issue A in Section 3.2), and it will not continue expected services for other trusted customers.
在加入/删除消息中放入大量组地址。此攻击将浪费PE检查客户控制消息（用于解决第3.2节中的问题A）的控制资源（如CPU、内存），并且不会继续为其他受信任客户提供预期服务。
(b) Attack by invalid/malformed multicast control packets.
(b) 由无效/格式错误的多播控制数据包发起的攻击。
There is a threat that a CE sends invalid or malformed control packets that might corrupt PE, which will cause a DoS attack. In particular, a CE might be spoofing legitimate source/group IP multicast addresses in such control packets (in PIM, IGMP, etc.) and source/destination MAC addresses as Layer-2 frames.
存在一种威胁，即CE发送可能损坏PE的无效或格式错误的控制数据包，这将导致DoS攻击。具体地，CE可能在诸如控制分组（在PIM、IGMP等中）中欺骗合法的源/组IP多播地址，并将源/目的MAC地址欺骗为第2层帧。
(c) Attack by rapid state change of multicast.
(c) 通过快速改变组播状态进行攻击。
If a malicious CE changes multicast state by sending control packets in an extremely short period, this might affect PE's control resources (e.g., CPU, memory) to follow such state changes. Besides, it might also affect PE/P's control resources if MDTunnel inside the core is dynamically created in conjunction with customer's multicast group.
如果恶意CE通过在极短时间内发送控制包来更改多播状态，这可能会影响PE的控制资源（例如CPU、内存）以跟踪此类状态更改。此外，如果核心内的MDTunnel与客户的多播组一起动态创建，也可能会影响PE/P的控制资源。
(d) Attack by high volume of multicast/broadcast data traffic.
(d) 通过大量多播/广播数据流量进行攻击。
A malicious CE might send a very high volume of multicast and/or broadcast data to a PE. If that PE does not provide any safeguards, it will cause excessive replication in the SP network and the bandwidth resources for other trusted customers might be exhausted.
恶意CE可能会向PE发送大量多播和/或广播数据。如果该PE不提供任何保护措施，将导致SP网络中的复制过多，并且其他受信任客户的带宽资源可能会耗尽。
(e) Attack by high volume of unknown destination unicast data traffic.
(e) 由大量未知目标单播数据流量发起的攻击。
A malicious CE can send a high volume of unknown unicast to a PE. Generally, according to VPLS architecture, that PE must flood such unknown traffic to all corresponding PEs in the same VPN. A variety of unknown destinations and huge amount of such frames might cause excess traffic in SP network unless there is an appropriate safeguard provided.
恶意CE可向PE发送大量未知单播。通常，根据VPLS体系结构，PE必须将此类未知流量涌入同一VPN中的所有相应PE。除非提供适当的保护措施，否则各种未知目的地和大量此类帧可能会导致SP网络中的流量过大。
Based on the analysis in the previous subsection, the security requirements from the SP's perspective are shown as follows.
根据上一小节的分析，SP的安全要求如下所示。
An SP network MUST be invulnerable to malformed or maliciously constructed customer traffic. This applies to both multicast data packets and multicast control packets.
SP网络必须不受格式错误或恶意构造的客户流量的影响。这适用于多播数据包和多播控制包。
Moreover, because multicast, broadcast, and unknown-unicast need more resources than unicast, an SP network MUST have safeguards against unwanted or malicious multicast traffic. This applies to both multicast data packets and multicast control packets.
此外，由于多播、广播和未知单播比单播需要更多的资源，因此SP网络必须具有防止有害或恶意多播流量的保护措施。这适用于多播数据包和多播控制包。
Specifically, a multicast VPLS solution SHOULD have mechanisms to protect an SP network from:
具体而言，多播VPLS解决方案应具有保护SP网络免受以下影响的机制：
(1) invalid multicast MAC addresses
(1) 无效的多播MAC地址
(2) invalid multicast IP addresses
(2) 无效的多播IP地址
(3) malformed Ethernet multicast control protocol frames
(3) 格式错误的以太网多播控制协议帧
(4) malformed IP multicast control protocol packets
(4) 格式错误的IP多播控制协议数据包
(5) high volumes of
(5) 大量的
* valid/invalid customer control packets
* 有效/无效的客户控制数据包
* valid/invalid customer data packets (broadcast/multicast/ unknown-unicast)
* 有效/无效的客户数据包（广播/多播/未知单播）
Depending on each solution's actual approach to tackle with Issue A, or B, or both (see Section 3.2.), there are relationships to be highlighted about each item's importance listed above. First off, protection against (3) and (4) becomes significantly important if a solution supports solving Issue A, and PEs are processing customer's Ethernet/IP multicast control messages from CE. Moreover, protection against (2) should also be much focused because PIM/IGMP snooping will usually require that PE's data forwarding be based on IP addresses. By contrast, however, if a solution is solving only Issue B, not A, then PEs might never process the customer's multicast control messages at all; they do not perform IP address-based forwarding, but they do perform native Ethernet forwarding. If so, there is relatively less danger about (2), (3), and (4) compared to the first case.
根据每个解决方案解决问题A、B或二者的实际方法（见第3.2节），以上列出的每个项目的重要性都有需要强调的关系。首先，如果解决方案支持解决问题a，并且PEs正在处理来自CE的客户以太网/IP多播控制消息，那么针对（3）和（4）的保护就变得非常重要。此外，针对（2）的保护也应重点关注，因为PIM/IGMP侦听通常要求PE的数据转发基于IP地址。然而，相比之下，如果解决方案只解决问题B而不是问题a，那么PEs可能根本不会处理客户的多播控制消息；它们不执行基于IP地址的转发，但执行本机以太网转发。如果是这样，与第一种情况相比，（2）、（3）和（4）的危险性相对较小。
The following are a few additional guidelines in detail.
以下是一些详细的附加指南。
For protecting against threat (a), a solution SHOULD support imposing some bounds on the quantity of state used by a VPN to be imposed in order to prevent state resource exhaustion (i.e., lack of memory, CPU etc.). In this case, the bounds MUST be
为了防止威胁（a），解决方案应支持对VPN使用的状态数量施加一些限制，以防止状态资源耗尽（即内存、CPU不足等）。在这种情况下，边界必须为
configurable per VPN basis, not the total of various VPNs so that SP can isolate the resource waste that is caused by any malicious customer.
每个VPN可配置，而不是各种VPN的总和，以便SP可以隔离任何恶意客户造成的资源浪费。
For protecting against threat (d) and (e), a solution SHOULD support performing traffic policing to limit the unwanted data traffic shown above. In this case, while policing MAY be configurable to the sum of unicast, multicast, broadcast, and unknown unicast traffic, it SHOULD also be configurable to each such type of traffic individually in order to prevent physical resource exhaustion (i.e., lack of bandwidth and degradation of throughput). If the policing limit is configured on total traffic only, there will be a concern that one customer's huge multicast might close other irrelevant unicast traffic. If it can be configured individually, this concern will be avoided. Moreover, such a policing mechanism MUST be configurable per VPN basis, not the total of various VPNs to isolate malicious customer's traffic from others.
为了防止威胁（d）和（e），解决方案应支持执行流量监控，以限制上述不需要的数据流量。在这种情况下，虽然监控可以配置为单播、多播、广播和未知单播通信量的总和，但也应该单独配置为每种此类通信量，以防止物理资源耗尽（即，带宽不足和吞吐量降低）。如果仅在总流量上配置了监控限制，则会担心一个客户的大型多播可能会关闭其他不相关的单播流量。如果可以单独配置，则可以避免此问题。此外，这种监控机制必须基于每个VPN进行配置，而不是各种VPN的总和，以将恶意客户的流量与其他流量隔离开来。
For protecting against threat (c), a solution SHOULD be able to limit frequent changes of group membership by customers. For example, PEs might support a dampening mechanism that throttles their multicast state changes if the customers are changing too excessively. Also, if MDTunnel is provided being tightly coupled to dynamic changes of customer's multicast domain, it is also effective to delay building the tunnel when customer's state is changed frequently.
为了防止威胁（c），解决方案应该能够限制客户频繁更改组成员身份。例如，PEs可能支持一种阻尼机制，如果客户的多播状态变化过大，则该机制会限制其多播状态的变化。此外，如果MDTunnel与客户的多播域的动态变化紧密耦合，那么当客户的状态频繁变化时，延迟构建隧道也是有效的。
Protecting against threat (b) might not be an easy task. Generally, checking the legitimacy of a customer's IP multicast control packets will eventually require the authentication between PE and CE in Layer-3; however, L2VPN (including VPLS) by its nature does not usually assume Layer-3-based security mechanism supported at PE-CE level.
防范威胁（b）可能不是一项容易的任务。通常，检查客户的IP多播控制数据包的合法性最终需要第三层PE和CE之间的身份验证；然而，L2VPN（包括VPLS）本质上通常不采用PE-CE级别支持的基于第三层的安全机制。
The ramification of this fact is that there remains a possibility that a PE's control plain might be badly affected by corrupted multicast control packets that the PE is examining. Hence, each PE implementation will need to make an effort to minimize this impact from malicious customers and isolate it from other trusted customers as much as possible.
这一事实的后果是，PE的控制平面仍有可能受到PE正在检查的损坏的多播控制数据包的严重影响。因此，每个PE实现都需要努力将恶意客户的影响降至最低，并尽可能将其与其他受信任客户隔离开来。
Nevertheless, it is possible to mitigate this threat to some degree. For example, a PE MAY support a filter mechanism about MAC and IP addresses in a Layer-2/Layer-3 header and a filter mechanism about source/group addresses in the multicast join/prune messages. This will help a PE to validate customers' control messages, to a certain extent.
然而，在某种程度上缓解这一威胁是可能的。例如，PE可以支持关于第2层/第3层报头中的MAC和IP地址的过滤机制以及关于多播加入/删减消息中的源/组地址的过滤机制。这将在一定程度上帮助PE验证客户的控制消息。
A VPLS multicast solution SHOULD allow a hierarchical VPLS (H-VPLS) [RFC4762] service model. In other words, a solution is expected to operate seamlessly with existing hub and spoke PW connectivity.
VPLS多播解决方案应允许分层VPLS（H-VPLS）[RFC4762]服务模型。换句话说，解决方案有望与现有的集线器和辐条PW连接无缝运行。
Note that it is also important to take into account the case of redundant spoke connections between U-PEs and N-PEs.
请注意，考虑U-PEs和N-PEs之间冗余轮辐连接的情况也很重要。
A solution MUST allow a situation where one SP is offering L2VPN services to another SP. One example here is a wholesale model where one VPLS interconnects other SPs' VPLS or 802.1D network islands. For customer SPs, their multicast forwarding can be optimized by making use of multicast VPLS in the wholesaler SP.
解决方案必须允许一个SP向另一个SP提供L2VPN服务。这里的一个示例是一个批发模型，其中一个VPL互连其他SP的VPL或802.1D网络孤岛。对于客户SP，可以通过使用批发商SP中的多播VPL优化其多播转发。
Security concerns and requirements for a base VPLS solution are described in [RFC4665].
[RFC4665]中描述了基本VPLS解决方案的安全问题和要求。
In addition, there are security considerations specific to multicast VPLS. Thus, a set of security issues have been identified that MUST be addressed when considering the design and deployment of multicast VPLS. Such issues have been described in Sections 5.5 and 6.6.
此外，还存在多播VPL特有的安全注意事项。因此，在考虑多播VPL的设计和部署时，必须解决一组安全问题。此类问题已在第5.5节和第6.6节中描述。
In particular, security requirements from the view of customers are shown in Section 5.5. Security requirements from the view of providers are shown in Section 6.6. Section 6.6.1 conducts security threat analysis about the provider's whole system. Section 6.6.2 explains how each threat can be addressed or mitigated.
具体而言，第5.5节显示了客户的安全要求。供应商的安全要求见第6.6节。第6.6.1节对供应商的整个系统进行安全威胁分析。第6.6.2节解释了如何应对或缓解每种威胁。
The authors thank the contributors of [RFC4834] since the structure and content of this document were, for some sections, largely inspired by [RFC4834].
作者感谢[RFC4834]的贡献者，因为本文档的结构和内容在某些章节中主要受[RFC4834]的启发。
The authors also thank Yuichi Ikejiri, Jerry Ash, Bill Fenner, Vach Kompella, Shane Amante, Ben Niven-Jenkins, and Venu Hemige for their valuable reviews and feedback.
作者还感谢Yuichi Ikejiri、Jerry Ash、Bill Fenner、Vach Kompella、Shane Amante、Ben Niven Jenkins和Venu Hemige的宝贵评论和反馈。
[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月。
[RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks", RFC 4665, September 2006.
[RFC4665]Augustyn，W.和Y.Serbest，“第2层提供商提供的虚拟专用网络的服务要求”，RFC 46652006年9月。
[802.1D] IEEE Std 802.1D-2004, "IEEE Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges", 2004.
[802.1D]IEEE标准802.1D-2004，“局域网和城域网IEEE标准：媒体访问控制（MAC）网桥”，2004年。
[802.1ag] IEEE Std 802.1ag-2007, "Virtual Bridged Local Area Networks - Amendment 5: Connectivity Fault Management", 2007.
[802.1ag]IEEE标准802.1ag-2007，“虚拟桥接局域网-修改件5：连接故障管理”，2007年。
[802.1s] IEEE Std 802.1s-2002, "Virtual Bridged Local Area Networks - Amendment 3: Multiple Spanning Trees", 2002.
[802.1s]IEEE标准802.1s-2002，“虚拟桥接局域网-修改件3：多生成树”，2002年。
[CGMP] Farinacci, D., Tweedly, A., and T. Speakman, "Cisco Group Management Protocol (CGMP)", 1996/1997, <ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt>.
[CGMP]Farinaci，D.，Tweedy，A.，和T.Speakman，“思科集团管理协议（CGMP）”，1996/1997<ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt>.
[LDP-P2MP] Minei, I., Ed., Kompella, K., Wijnands, I., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Work in Progress, May 2008.
[LDP-P2MP]Minei，I.，Ed.，Kompella，K.，Wijnands，I.，和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，正在进行的工作，2008年5月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236]Fenner，W.，“互联网组管理协议，第2版”，RFC 2236，1997年11月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]Deering，S.，Fenner，W.，和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group Management Protocol (RGMP)", RFC 3488, February 2003.
[RFC3488]Wu，I.和T.Eckert，“思科系统路由器端口组管理协议（RGMP）”，RFC 3488，2003年2月。
[RFC3809] Nagarajan, A., "Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 2004.
[RFC3809]Nagarajan，A.，“提供商提供的虚拟专用网络（PPVPN）的一般要求”，RFC 3809，2004年6月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[RFC3973]Adams，A.，Nicholas，J.，和W.Siadak，“协议独立多播-密集模式（PIM-DM）：协议规范（修订版）”，RFC 3973，2005年1月。
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.
[RFC4541]Christensen，M.，Kimball，K.，和F.Solensky，“互联网组管理协议（IGMP）和多播侦听器发现（MLD）窥探交换机的注意事项”，RFC 4541，2006年5月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月。
[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月。
[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月。
[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月。
[RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4834, April 2007.
[RFC4834]Morin，T.，Ed.“第3层提供商提供的虚拟专用网络（PPVPN）中的多播要求”，RFC 4834，2007年4月。
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875]Aggarwal，R.，Papadimitriou，D.，和S.Yasukawa，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 4875，2007年5月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015]Handley，M.，Kouvelas，I.，Speakman，T.，和L.Vicisano，“双向协议独立多播（BIDIR-PIM）”，RFC 50152007年10月。
Authors' Addresses
作者地址
Yuji Kamite (editor) NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan EMail: y.kamite@ntt.com
龟井裕二（编辑）NTT通信公司格兰帕克大厦3-4-1号，东京弥敦区Shibaura 108-8118日本电子邮件：y。kamite@ntt.com
Yuichiro Wada NTT 3-9-11 Midori-cho Musashino-shi Tokyo 180-8585 Japan EMail: wada.yuichiro@lab.ntt.co.jp
和田Yuichiro NTT 3-9-11 Midori cho Musashino shi东京180-8585日本电子邮件：和田。yuichiro@lab.ntt.co.jp
Yetik Serbest AT&T Labs 9505 Arboretum Blvd. Austin, TX 78759 USA EMail: yetik_serbest@labs.att.com
Yetik Serbest AT&T实验室植物园大道9505号。德克萨斯州奥斯汀78759美国电子邮件：yetik_serbest@labs.att.com
Thomas Morin France Telecom R&D 2, avenue Pierre-Marzin 22307 Lannion Cedex France EMail: thomas.morin@francetelecom.com
Thomas Morin法国电信研发2号，Pierre Marzin大街22307 Lannion Cedex France电子邮件：Thomas。morin@francetelecom.com
Luyuan Fang Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: lufang@cisco.com
卢元芳思科系统有限公司美国马萨诸塞州博克斯伯勒市比弗布鲁克路300号邮编01719电子邮件：lufang@cisco.com