Internet Engineering Task Force (IETF) H. Shah
Request for Comments: 7436 Cinea Corp.
Category: Historic E. Rosen
ISSN: 2070-1721 Juniper Networks
F. Le Faucheur
G. Heron
Cisco Systems
January 2015
Internet Engineering Task Force (IETF) H. Shah
Request for Comments: 7436 Cinea Corp.
Category: Historic E. Rosen
ISSN: 2070-1721 Juniper Networks
F. Le Faucheur
G. Heron
Cisco Systems
January 2015
IP-Only LAN Service (IPLS)
仅限IP的LAN服务（IPLS）
Abstract
摘要
A Virtual Private LAN Service (VPLS) is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems that are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destination Media Access Control (MAC) addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the MAC address learning procedures specified in the IEEE's "Media Access Control (MAC) Bridges". This document specifies the protocol extensions and procedures for support of the IPLS service.
虚拟专用LAN服务（VPLS）用于跨广域网或城域网互连系统，使其看起来好像位于专用LAN上。互连的系统本身可能是LAN交换机。但是，如果它们是IP主机或IP路由器，则可以对VPL的操作进行某些简化。我们将这种简化类型的VPLS称为“仅限IP的LAN服务”（IPLS）。在IPLS中，就像在VPLS中一样，LAN接口以混杂模式运行，帧根据其目标媒体访问控制（MAC）地址进行转发。然而，MAC转发表的维护是通过信令完成的，而不是通过IEEE的“媒体访问控制（MAC）网桥”中规定的MAC地址学习过程。本文件规定了支持IPLS服务的协议扩展和程序。
The original intent was to provide an alternate solution to VPLS for those Provider Edge (PE) routers that were not capable of learning MAC addresses through data plane. This became a non-issue with newer hardware. The concepts put forth by this document are still valuable and are adopted in one form or other by newer work such as Ethernet VPN in L2VPN working group and possible data center applications. At this point, no further action is planned to update this document and it is published simply as a historic record of the ideas.
最初的目的是为那些不能通过数据平面学习MAC地址的提供商边缘（PE）路由器提供VPLS的替代解决方案。这对于较新的硬件来说已经不是问题了。本文档提出的概念仍然很有价值，并以某种形式被更新的工作（如L2VPN工作组中的以太网VPN和可能的数据中心应用）采用。在这一点上，没有进一步的行动计划来更新本文件，它只是作为一个想法的历史记录发布。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for the historical record.
本文件不是互联网标准跟踪规范；它是为了历史记录而出版的。
This document defines a Historic Document for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档定义了互联网社区的历史文档。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7436.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7436.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Overview ........................................................4
1.1. Terminology ................................................7
2. Topology ........................................................9
3. Configuration ..................................................10
4. Discovery ......................................................10
4.1. CE Discovery ..............................................10
4.1.1. IPv4-Based CE Discovery ............................11
4.1.2. IPv6-Based CE Discovery (RFC 4861) .................11
5. PW Creation ....................................................11
5.1. Receive Unicast Multipoint-to-Point PW ....................11
5.2. Receive Multicast Multipoint-to-Point PW ..................12
5.3. Send Multicast Replication Tree ...........................13
1. Overview ........................................................4
1.1. Terminology ................................................7
2. Topology ........................................................9
3. Configuration ..................................................10
4. Discovery ......................................................10
4.1. CE Discovery ..............................................10
4.1.1. IPv4-Based CE Discovery ............................11
4.1.2. IPv6-Based CE Discovery (RFC 4861) .................11
5. PW Creation ....................................................11
5.1. Receive Unicast Multipoint-to-Point PW ....................11
5.2. Receive Multicast Multipoint-to-Point PW ..................12
5.3. Send Multicast Replication Tree ...........................13
6. Signaling ......................................................13
6.1. IPLS PW Signaling .........................................13
6.2. IPv6 Capability Advertisement .............................17
6.3. Signaling Advertisement Processing ........................18
7. IANA Considerations ............................................19
7.1. LDP Status Messages .......................................19
7.2. Interface Parameters ......................................19
8. Forwarding .....................................................20
8.1. Non-IP or Non-ARP Traffic .................................20
8.2. Unicast IP Traffic ........................................20
8.3. Broadcasts and Multicast IP Traffic .......................20
8.4. ARP Traffic ...............................................21
8.5. Discovery of IPv6 CE Devices ..............................21
8.5.1. Processing of Neighbor Solicitations ...............22
8.5.2. Processing of Neighbor Advertisements ..............22
8.5.3. Processing of Inverse Neighbor
Solicitations and Advertisement ....................22
8.5.4. Processing of Router Solicitations and
Advertisements .....................................23
8.6. Encapsulation .............................................23
9. Attaching to IPLS via ATM or Frame Relay (FR) ..................24
10. VPLS vs. IPLS .................................................24
11. IP Protocols ..................................................25
12. Dual-Homing with IPLS .........................................25
13. Proxy ARP Function ............................................26
13.1. ARP Proxy - Responder ....................................26
13.2. ARP Proxy - Generator ....................................26
14. Data Center Applicability .....................................27
15. Security Considerations .......................................27
15.1. Control-Plane Security ...................................27
15.2. Data-Plane Security ......................................28
16. References ....................................................29
16.1. Normative References .....................................29
16.2. Informative References ...................................30
Acknowledgements ..................................................31
Contributors ......................................................31
Authors' Addresses ................................................32
6. Signaling ......................................................13
6.1. IPLS PW Signaling .........................................13
6.2. IPv6 Capability Advertisement .............................17
6.3. Signaling Advertisement Processing ........................18
7. IANA Considerations ............................................19
7.1. LDP Status Messages .......................................19
7.2. Interface Parameters ......................................19
8. Forwarding .....................................................20
8.1. Non-IP or Non-ARP Traffic .................................20
8.2. Unicast IP Traffic ........................................20
8.3. Broadcasts and Multicast IP Traffic .......................20
8.4. ARP Traffic ...............................................21
8.5. Discovery of IPv6 CE Devices ..............................21
8.5.1. Processing of Neighbor Solicitations ...............22
8.5.2. Processing of Neighbor Advertisements ..............22
8.5.3. Processing of Inverse Neighbor
Solicitations and Advertisement ....................22
8.5.4. Processing of Router Solicitations and
Advertisements .....................................23
8.6. Encapsulation .............................................23
9. Attaching to IPLS via ATM or Frame Relay (FR) ..................24
10. VPLS vs. IPLS .................................................24
11. IP Protocols ..................................................25
12. Dual-Homing with IPLS .........................................25
13. Proxy ARP Function ............................................26
13.1. ARP Proxy - Responder ....................................26
13.2. ARP Proxy - Generator ....................................26
14. Data Center Applicability .....................................27
15. Security Considerations .......................................27
15.1. Control-Plane Security ...................................27
15.2. Data-Plane Security ......................................28
16. References ....................................................29
16.1. Normative References .....................................29
16.2. Informative References ...................................30
Acknowledgements ..................................................31
Contributors ......................................................31
Authors' Addresses ................................................32
As emphasized in [RFC4762], Ethernet has become popular as an access technology in metropolitan- and wide-area networks. [RFC4762] describes how geographically dispersed customer LANs can be interconnected over a service provider's network. The VPLS service is provided by Provider Edge (PE) devices that connect Customer Edge (CE) devices. The VPLS architecture provides this service by incorporating bridging functions such as MAC address learning in the PE devices.
正如[RFC4762]中所强调的，以太网已成为城域网和广域网中的一种接入技术。[RFC4762]描述了地理位置分散的客户LAN如何通过服务提供商的网络互连。VPLS服务由连接客户边缘（CE）设备的提供商边缘（PE）设备提供。VPLS体系结构通过在PE设备中加入桥接功能（如MAC地址学习）来提供此服务。
PE platforms are designed primarily to be IP routers rather than LAN switches. To add VPLS capability to a PE router, one has to add MAC-address-learning capabilities, along with aging and other mechanisms native to Ethernet switches [IEEE802.1D]. This may be fairly complex to add to the forwarding-plane architecture of an IP router. As discussed in [RFC4664], in scenarios where the CE devices are NOT LAN switches, but rather are IP hosts or IP routers, it is possible to provide the VPLS service without requiring MAC address learning and aging on the PE. Instead, a PE router has to have the capability to match the destination MAC address in a packet received from a CE to an outbound pseudowire (PW). The requirements for the IPLS service are described in [RFC4665]. The purpose of this document is to specify a solution optimized for IPLS.
PE平台主要设计为IP路由器，而不是LAN交换机。要向PE路由器添加VPLS功能，必须添加MAC地址学习功能，以及以太网交换机固有的老化和其他机制[IEEE802.1D]。要添加到IP路由器的转发平面架构中，这可能相当复杂。如[RFC4664]中所述，在CE设备不是LAN交换机而是IP主机或IP路由器的情况下，可以提供VPLS服务，而无需在PE上进行MAC地址学习和老化。相反，PE路由器必须能够将从CE接收的数据包中的目标MAC地址与出站伪线（PW）匹配。[RFC4665]中描述了IPLS服务的要求。本文档旨在指定针对IPL优化的解决方案。
IPLS provides a VPLS-like service using PE routers that are not designed to perform general LAN bridging functions. One must be willing to accept the restriction that an IPLS be used for IP traffic only, and not used to interconnect CE devices that are themselves LAN switches. This is an acceptable restriction in many environments, given that IP is the predominant type of traffic in today's networks.
IPLS使用PE路由器提供类似VPLS的服务，PE路由器的设计目的不是执行一般LAN桥接功能。人们必须愿意接受这样的限制，即IPL只能用于IP通信，而不能用于互连本身就是LAN交换机的CE设备。这在许多环境中都是可以接受的限制，因为IP是当今网络中的主要流量类型。
The original intent was to provide an alternate solution to VPLS for those PE routers that were not capable of learning MAC addresses in the data plane. This became a non-issue with newer hardware. The concepts put forth by this document are still valuable and are adopted in one form or other by newer work such as Ethernet VPN in the L2VPN working group and possible data center applications. At this point, no further action is planned to update this document and is published simply as a historic record of the ideas.
最初的目的是为那些不能在数据平面中学习MAC地址的PE路由器提供VPLS的替代解决方案。这对于较新的硬件来说已经不是问题了。本文件提出的概念仍然很有价值，并以某种形式被L2VPN工作组中的以太网VPN和可能的数据中心应用等较新工作采用。在这一点上，没有进一步的行动计划来更新本文件，只是作为想法的历史记录发布。
In IPLS, a PE device implements multipoint LAN connectivity for IP traffic using the following key functions:
在IPLS中，PE设备使用以下关键功能实现IP流量的多点LAN连接：
1. CE Address Discovery: Each PE device discovers the MAC address of the locally attached CE IP devices, for each IPLS instance configured on the PE device. In some configurations, the PE also learns the IP address of the CE device (when performing ARP proxy functions, described later in the document).
1. CE地址发现：对于PE设备上配置的每个IPLS实例，每个PE设备发现本地连接的CE IP设备的MAC地址。在一些配置中，PE还学习CE设备的IP地址（当执行ARP代理功能时，将在本文档后面介绍）。
2. Pseudowire (PW) for Unicast Traffic: For each locally attached CE device in a given IPLS instance, a PE device sets up a pseudowire (PW) to each of the other PEs that supports the same IPLS instance.
2. 用于单播通信的伪线（PW）：对于给定IPLS实例中的每个本地连接的CE设备，PE设备将伪线（PW）设置到支持相同IPLS实例的每个其他PE。
For instance, if PEx and PEy both support IPLS I, and PEy is locally attached to CEa and CEb, PEy will initiate the setup of two PWs between itself and PEx. One of these will be used to carry unicast traffic from any of PEx's CE devices to CEa. The other will be used to carry unicast traffic from any of PEx's CE devices to CEb.
例如，如果PEx和PEy都支持IPLS I，并且PEy本地连接到CEa和CEb，则PEy将启动自身和PEx之间的两个PWs设置。其中一个将用于从PEx的任何CE设备向CEa传输单播流量。另一个将用于从PEx的任何CE设备向CEb传输单播流量。
Note that these PWs carry traffic only in one direction. Further, while the PW implicitly identifies the destination CE of the traffic, it does not identify the source CE; packets from different source CEs bound to the same destination CE are sent on a single PW.
请注意，这些PW仅在一个方向上承载流量。此外，虽然PW隐式地标识业务的目的地CE，但它不标识源CE；来自绑定到同一目的地CE的不同源CE的数据包在单个PW上发送。
3. Pseudowires for Multicast Traffic: In addition, every PE supporting a given IPLS instance will set up a special 'multicast' pseudowire to every other PE in that IPLS instance. If, in the above example, one of PEx's CE devices sends a multicast packet, PEx would forward the multicast packet to PEy on the special 'multicast' pseudowire. PEy would then send a copy of that packet to CEa and a copy to CEb.
3. 用于多播通信的伪线：此外，支持给定IPLS实例的每个PE将为该IPLS实例中的每个其他PE设置一个特殊的“多播”伪线。在上述示例中，如果PEx的CE设备之一发送多播数据包，PEx将通过特殊的“多播”伪线将多播数据包转发给PEy。然后，佩伊将向CEa发送一份该数据包的副本，并向CEb发送一份副本。
The 'multicast' pseudowire carries Ethernet frames of multicast/broadcast IP, ARP, and ICMP (Inverse) Neighbor Discovery (ND/IND) packets for IPv6. Thus, when a PE sends a multicast packet across the network, it sends one copy to each remote PE (supporting the given IPLS instance). If a particular remote PE has more than one CE device in that IPLS instance, the remote PE must replicate the packet and send one copy to each of its local CEs.
“多播”伪线承载用于IPv6的多播/广播IP、ARP和ICMP（反向）邻居发现（ND/IND）数据包的以太网帧。因此，当PE通过网络发送多播数据包时，它会向每个远程PE发送一个副本（支持给定的IPLS实例）。如果特定远程PE在该IPLS实例中有多个CE设备，则远程PE必须复制该数据包并向其每个本地CE发送一个副本。
As with the pseudowires that are used for unicast traffic, packets travel in only one direction on these pseudowires, and packets from different sources may be freely intermixed.
和用于单播通信的伪线一样，数据包在这些伪线上只沿一个方向传输，来自不同来源的数据包可以自由混合。
4. Signaling: The necessary pseudowires can be set up and maintained using the signaling procedures based on the Label Distribution Protocol (LDP) described in [RFC4447].
4. 信令：可以使用基于[RFC4447]中描述的标签分发协议（LDP）的信令程序设置和维护必要的伪线。
A PE may assign the same label to each of the unicast pseudowires that lead to a given CE device, in effect creating a multipoint-to-point pseudowire.
PE可以将相同的标签分配给通向给定CE设备的每个单播伪线，实际上创建多点对点伪线。
Similarly, a PE may assign the same label to each of the 'multicast' pseudowires for a given IPLS instance, in effect creating a multipoint-to-point pseudowire. When setting up a pseudowire to be used for unicast traffic, the PE must also signal the MAC address of the corresponding CE device. It should also, optionally, advertise the IP address of the local CE device, especially when ARP proxy function is configured or simply for operational management purposes. Similarly, for IPv6 support, PE may optionally advertise the IPv6 addresses of the local CE device.
类似地，PE可以为给定IPLS实例的每个“多播”伪线分配相同的标签，实际上创建多点对点伪线。当设置用于单播通信的伪线时，PE还必须向相应CE设备的MAC地址发送信号。它还可以选择性地公布本地CE设备的IP地址，特别是在配置了ARP代理功能或仅出于操作管理目的时。类似地，对于IPv6支持，PE可以选择性地公布本地CE设备的IPv6地址。
5. ARP Packet Forwarding: ARP packets [RFC826] are forwarded from the attachment circuit (AC) to 'multicast' pseudowires in the Ethernet frame format as described by [RFC4448]. The following rules are observed when processing ARP packets:
5. ARP数据包转发：ARP数据包[RFC826]以[RFC4448]所述的以太网帧格式从连接电路（AC）转发到“多播”伪线。处理ARP数据包时遵守以下规则：
a. Both broadcast (request) and unicast (response) ARP packets are sent over the 'multicast' pseudowire.
a. 广播（请求）和单播（响应）ARP数据包都通过“多播”伪线发送。
b. When an ARP packet is received from an AC, the packet is copied to the control plane for the purpose of learning the MAC address of the CE. Optionally, an IP address is also learned to record the association of the IP and MAC address.
b. 当从AC接收到ARP分组时，该分组被复制到控制平面以用于学习CE的MAC地址。可选地，还学习IP地址以记录IP和MAC地址的关联。
c. All Ethernet packets, including ARP packets, received from the 'multicast' pseudowire are forwarded out to all the ACs associated with the IPLS instance. These packets are not copied to the control plane.
c. 从“多播”伪线接收的所有以太网数据包，包括ARP数据包，都被转发到与IPLS实例相关联的所有ACs。这些数据包不会复制到控制平面。
6. ICMP IPv6 ND/IND-related Packet Forwarding: ND/IND IPv6 packets from an AC are replicated and a copy is sent to other ACs and to 'multicast' PWs associated with the IPLS instance in the native Ethernet format, unchanged. A copy is also submitted to the control plane to learn the MAC address and, optionally, corresponding IPv6 addresses.
6. ICMP IPv6 ND/IND相关数据包转发：复制来自AC的ND/IND IPv6数据包，并将副本以本机以太网格式发送到其他AC和与IPLS实例关联的“多播”PW，未更改。还向控制平面提交一份副本，以了解MAC地址和相应的IPv6地址（可选）。
7. Multicast IP packet forwarding: An IP Ethernet frame received from an AC is replicated to other ACs and the 'multicast' PWs associated with the IPLS instance. An IP Ethernet frame received from a 'multicast' PW is replicated to all the egress ACs associated with the IPLS instance.
7. 多播IP包转发：从AC接收的IP以太网帧被复制到其他AC和与IPLS实例关联的“多播”PW。从“多播”PW接收的IP以太网帧被复制到与IPLS实例相关联的所有出口AC。
8. Unicast IP packet forwarding: An IP packet received from the AC is forwarded based on the destination MAC address lookup in the forwarding table. If a match is found, the packet is forwarded to the associated egress interface. If the egress interface is unicast PW, the packet is sent without a MAC header. If the egress interface is a local AC, the Ethernet frame is forwarded as such. An IP packet received from the unicast PW is forwarded to the egress AC with the MAC header prepended. The destination MAC address is derived from the forwarding table while the source MAC address is the MAC address of the PE.
8. 单播IP包转发：根据转发表中的目标MAC地址查找转发从AC接收的IP包。如果找到匹配项，则将数据包转发到关联的出口接口。如果出口接口是单播PW，则发送分组时不带MAC报头。如果出口接口是本地AC，则以太网帧被转发为本地AC。从单播PW接收的IP分组被转发到出口AC，并且MAC报头被预先设置。目标MAC地址来自转发表，而源MAC地址是PE的MAC地址。
Both VPLS [RFC4762] and IPLS require the ingress PE to forward a frame based on its destination MAC address. However, two key differences between VPLS and IPLS can be noted from the above description:
VPL[RFC4762]和IPL都要求入口PE根据其目标MAC地址转发帧。然而，从上述描述中可以看出VPLS和IPLS之间的两个关键区别：
- In VPLS, MAC entries are placed in the Forwarding Information Base (FIB) of the ingress PE as a result of MAC address learning (which occurs in the data plane); whereas, in IPLS, MAC entries are placed in the FIB as a result of PW signaling operations (control plane).
- 在VPLS中，由于MAC地址学习（发生在数据平面中），MAC条目被放置在入口PE的转发信息库（FIB）中；然而，在IPLS中，由于PW信令操作（控制平面），MAC条目被放置在FIB中。
- In VPLS, the egress PE looks up a frame's destination MAC address to determine the egress AC; in IPLS, the egress AC is determined entirely by the ingress PW label.
- 在VPLS中，出口PE查找帧的目的地MAC地址以确定出口AC；在IPLS中，出口AC完全由入口PW标签确定。
The following sections describe the details of the IPLS scheme.
以下各节介绍IPLS计划的详细信息。
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]中所述进行解释。
IPLS IPLS stands for IP-only LAN service (a type of Virtual Private LAN Service that is restricted to IP traffic only).
IPLS IPLS表示仅限IP的LAN服务（一种仅限IP流量的虚拟专用LAN服务）。
MP2P PW A Multipoint-to-Point Pseudowire is a PW that carries traffic from remote PE devices to a PE device that signals the PW. The signaling PE device advertises the same PW label to all remote PE devices that
MP2P PW多点对点伪线是一种PW，它将流量从远程PE设备传输到向PW发送信号的PE设备。信令PE设备向所有远程PE设备播发相同的PW标签
participate in the IPLS service instance. In IPLS, for a given IPLS instance, an MP2P PW used for IP unicast traffic is established by a PE for each CE device locally attached to that PE. It is a unidirectional tree whose leaves consist of the remote PE peers (which connect at least one AC associated with the same IPLS instance) and whose root is the signaling PE. Traffic flows from the leaves towards the root.
参与IPLS服务实例。在IPLS中，对于给定的IPLS实例，PE为本地连接到该PE的每个CE设备建立用于IP单播通信的MP2P PW。它是一个单向树，其叶子由远程PE对等点（连接至少一个与同一IPLS实例相关联的AC）组成，其根是信令PE。交通从树叶流向根部。
Multicast PW A Multicast/broadcast Pseudowire is a special kind of MP2P PW that carries IP multicast/broadcast traffic, all ARP frames and ICMP (I)ND frames for IPv6. In the IPLS architecture, for each IPLS instance supported by a PE, that PE device establishes exactly one multicast PW. Multicast PW uses Ethernet encapsulation.
多播PW多播/广播伪线是一种特殊的MP2P PW，用于承载IPv6的IP多播/广播流量、所有ARP帧和ICMP（I）ND帧。在IPLS体系结构中，对于PE支持的每个IPLS实例，该PE设备只建立一个多播PW。多播PW使用以太网封装。
Unicast PW A Unicast pseudowire carries IP unicast packets. A PE creates unicast PW for each locally attached CE. The unicast PW uses IP Layer 2 (L2) transport encapsulation.
单播伪线承载IP单播数据包。PE为每个本地连接的CE创建单播PW。单播PW使用IP层2（L2）传输封装。
CE In this document, a Customer Edge (CE) is any IP node (host or router) connected to the IPLS LAN service.
CE在本文档中，客户边缘（CE）是连接到IPLS LAN服务的任何IP节点（主机或路由器）。
Send The collection of all multicast PWs and ACs Multicast that are members of an IPLS service instance on a Replication given PE. When a PE receives a multicast/broadcast Tree packet from an AC, the PE device sends a copy of the packet to every multicast PW and AC of the Send Multicast Replication Tree, excluding the AC on which the packet was received. When a PE receives a packet from a multicast PW, the PE device sends a copy of the packet to all the ACs of the Send Multicast Replication Tree and never to other PWs.
发送作为复制给定PE上IPLS服务实例成员的所有多播PW和ACs多播的集合。当PE从AC接收多播/广播树分组时，PE设备将分组的副本发送到发送多播复制树的每个多播PW和AC，不包括接收分组的AC。当PE从多播PW接收到分组时，PE设备将该分组的副本发送到发送多播复制树的所有ac，而从不发送到其他PW。
(I)ND (Inverse) Neighbor Discovery in IPv6 uses ICMP Neighbor Solicitation (NS) and Neighbor Advertisement (NA) packets.
（一） IPv6中的ND（反向）邻居发现使用ICMP邻居请求（NS）和邻居通告（NA）数据包。
RS Router Solicitation is when hosts generate all-routers multicast ICMP packets to discover the IPv6 router on the local link.
RS路由器请求是指主机生成所有路由器的多播ICMP数据包，以发现本地链路上的IPv6路由器。
RA Router Advertisement occurs when a router generates all-nodes multicast ICMP packets to advertise its presence on the link. A unicast response is also sent when RS is received.
RA路由器播发发生在路由器生成所有节点多播ICMP数据包以播发其在链路上的存在时。当接收到RS时，也会发送单播响应。
NS Neighbor Solicitation in IPv6 uses (multicast) ICMP packets to resolve the association of the IPv6 interface address to the MAC address.
IPv6中的NS邻居请求使用（多播）ICMP数据包来解析IPv6接口地址与MAC地址的关联。
NA Neighbor Advertisement in IPv6 uses (unicast) ICMP packets to respond to NS.
IPv6中的NA邻居播发使用（单播）ICMP数据包响应NS。
The CE devices are IP nodes (hosts or routers) that are connected to PE devices either directly or via an Ethernet network. We assume that the PE/CE connection may be regarded by the PE as an "interface" to which one or more CEs are attached. This interface may be a physical LAN interface or a VLAN. The PE routers are MPLS Label Edge Routers (LERs) that serve as PW endpoints.
CE设备是直接或通过以太网连接到PE设备的IP节点（主机或路由器）。我们假设PE/CE连接可能被PE视为一个“接口”，一个或多个CE连接到该接口。该接口可以是物理LAN接口或VLAN。PE路由器是用作PW端点的MPLS标签边缘路由器（LER）。
+----+ +----+
+ S1 +---+ ........................... +---| S2 |
+----+ | | . . | +----+
IPa | | +----+ +----+ | IPe
+ +---| PE1|---MPLS and/or IP---| PE2|---+
/ \ +----+ |Network +----+ |
+----+ +---+ . | . | +----+
+ S1 + | S1| . +----+ . +---| S2 |
+----+ +---+ ..........| PE3|........... +----+
IPb IPc +----+ IPf
|
|
+----+
| S3 |
+----+
IPd
+----+ +----+
+ S1 +---+ ........................... +---| S2 |
+----+ | | . . | +----+
IPa | | +----+ +----+ | IPe
+ +---| PE1|---MPLS and/or IP---| PE2|---+
/ \ +----+ |Network +----+ |
+----+ +---+ . | . | +----+
+ S1 + | S1| . +----+ . +---| S2 |
+----+ +---+ ..........| PE3|........... +----+
IPb IPc +----+ IPf
|
|
+----+
| S3 |
+----+
IPd
In the above diagram, an IPLS instance is shown with three sites: site S1, site S2, and site S3. In site S3, the CE device is directly connected to its PE. In the other two sites, there are multiple CEs connected to a single PE. More precisely, the CEs at these sites are on an Ethernet (switched at site 1 and shared at site 2) network (or VLAN), and the PE is attached to that same Ethernet network or VLAN). We impose the following restriction: if one or more CEs attach to a PE by virtue of being on a common LAN or VLAN, there MUST NOT be more than one PE on that LAN or VLAN.
在上图中，IPLS实例显示了三个站点：站点S1、站点S2和站点S3。在站点S3中，CE设备直接连接到其PE。在其他两个站点中，有多个CE连接到单个PE。更准确地说，这些站点的CE位于以太网（在站点1交换并在站点2共享）网络（或VLAN）上，并且PE连接到相同的以太网网络或VLAN）。我们施加以下限制：如果一个或多个CE由于位于公共LAN或VLAN上而连接到PE，则该LAN或VLAN上不得有多个PE。
PE1, PE2, and PE3 are shown as connected via an MPLS network; however, other tunneling technologies, such as Generic Routing Encapsulation (GRE), Layer 2 Tunneling Protocol version 3 (L2TPv3), etc., could also be used to carry the PWs.
PE1、PE2和PE3显示为通过MPLS网络连接；然而，其他隧道技术，如通用路由封装（GRE）、第2层隧道协议版本3（L2TPv3）等，也可用于承载PWs。
An IPLS instance is a single broadcast domain, such that each IP end station (e.g., IPa) appears to be co-located with other IP end stations (e.g., IPb through IPf) on the same subnet. The IPLS service is transparent to the CE devices and requires no changes to them.
IPLS实例是单个广播域，因此每个IP端站（例如IPa）似乎与同一子网上的其他IP端站（例如IPb到IPf）位于同一位置。IPLS服务对CE设备是透明的，不需要对其进行更改。
Each PE router is configured with one or more IPLS service instances, and each IPLS service instance is associated with a unique VPN-ID. For a given IPLS service instance, a set of ACs is identified. Each AC can be associated with only one IPLS instance. An AC, in this document, is either a customer-facing Ethernet port, or a particular VLAN (identified by an IEEE 802.1Q VLAN ID) on a customer-facing Ethernet port.
每个PE路由器配置有一个或多个IPLS服务实例，每个IPLS服务实例与唯一的VPN-ID关联。对于给定的IPLS服务实例，标识一组ACs。每个AC只能与一个IPLS实例关联。在本文档中，AC是面向客户的以太网端口，或者是面向客户的以太网端口上的特定VLAN（由IEEE 802.1Q VLAN ID标识）。
The PE router can optionally be configured with a local MAC address to be used as a source MAC address when IP packets are forwarded from a PW to an AC. By default, a PE uses the MAC address of the customer-facing Ethernet interface for this purpose.
PE路由器可以选择性地配置本地MAC地址，当IP数据包从PW转发到AC时用作源MAC地址。默认情况下，PE为此目的使用面向客户的以太网接口的MAC地址。
The discovery process includes: - Remote PE discovery - VPN (i.e., IPLS) membership discovery - IP CE end station discovery
发现过程包括：-远程PE发现-VPN（即IPLS）成员身份发现-IP CE端站发现
This document does not discuss the remote PE discovery or VPN membership discovery. This information can either be user configured or can be obtained using auto-discovery techniques described in [RFC6074] or other methods. However, the discovery of the CE is an important operational step in the IPLS model and is described below.
本文档不讨论远程PE发现或VPN成员身份发现。该信息可以由用户配置，也可以使用[RFC6074]中描述的自动发现技术或其他方法获得。然而，CE的发现是IPLS模型中的一个重要操作步骤，如下所述。
Each PE actively detects the presence of local CEs by snooping IP and ARP frames received over the ACs. When an AC configured in an IPLS instance becomes operational, it enters the CE discovery phase. In this phase, the PE examines each multicast/broadcast Ethernet frame. For link-local IP broadcast/multicast frames (e.g., IPv4 packets with destination addresses within 224.0.0/24 [RFC5771]), the CE's (source) MAC address is extracted from the Ethernet header and the (source) IP address is obtained from the IP header.
每个PE通过监听通过ACs接收的IP和ARP帧来主动检测本地CE的存在。当在IPLS实例中配置的AC开始运行时，它将进入CE发现阶段。在此阶段，PE检查每个多播/广播以太网帧。对于链路本地IP广播/多播帧（例如，目标地址在224.0.0/24[RFC5771]范围内的IPv4数据包），CE（源）MAC地址从以太网报头提取，而（源）IP地址从IP报头获取。
For each CE, the PE maintains the following tuple: <Attachment Circuit identification info, VPN-ID, MAC address, IP address (optional)>.
对于每个CE，PE维护以下元组：<附件电路标识信息、VPN-ID、MAC地址、IP地址（可选）>。
As indicated earlier, a copy of each ARP frame received over the AC is submitted to the control plane. The PE learns the MAC address and optionally the IP address of the CE from the source address fields of the ARP PDU.
如前所述，通过AC接收的每个ARP帧的副本被提交到控制平面。PE从ARP PDU的源地址字段中学习MAC地址和可选的CE IP地址。
Once a CE is discovered, its status is monitored continuously by examining the received ARP frames and by periodically generating ARP requests. The absence of an ARP response from a CE after a configurable number of ARP requests is interpreted as loss of connectivity with the CE.
一旦发现CE，通过检查接收到的ARP帧和周期性生成ARP请求来持续监控其状态。在可配置数量的ARP请求之后，CE没有ARP响应被解释为失去与CE的连接。
A copy of Neighbor and Router Discovery frames received over the AC are submitted to the control plane in the PE.
通过AC接收到的邻居和路由器发现帧的副本被提交到PE中的控制平面。
If the PE receives an NS message, and the source IP address of the message is not the unspecified address, the PE learns the MAC address and optionally the IP address of the CE.
如果PE接收到NS消息，并且消息的源IP地址不是未指定的地址，则PE将学习MAC地址和CE的可选IP地址。
If the PE receives an unsolicited NA message, the PE learns the source MAC address and optionally the IP address of the CE.
如果PE接收到未经请求的NA消息，则PE学习源MAC地址和可选的CE的IP地址。
If the PE receives an RS, and the source IP address of the message is not the unspecified address, the PE learns source MAC address and optionally the IP address of the CE.
如果PE接收到RS，并且消息的源IP地址不是未指定的地址，则PE将学习源MAC地址和CE的可选IP地址。
If the PE receives an RA, it learns the source MAC address and optionally the IP address of the CE.
如果PE接收到RA，它将学习源MAC地址和CE的可选IP地址。
The PE will periodically generate NS messages for the IP address of the CE as a means of verifying the continued existence of the address and its MAC address binding. The absence of a response from the CE device for a given number of retries could be interpreted as a loss of connectivity with the CE.
PE将定期为CE的IP地址生成NS消息，作为验证地址及其MAC地址绑定是否继续存在的手段。对于给定的重试次数，CE设备没有响应可能被解释为与CE的连接丢失。
As the PE discovers each locally attached CE, a unicast multipoint-to-point pseudowire (MP2P PW) associated exclusively with that CE is created by distributing the MAC address and optionally the IP address of the CE along with a PW label to all the remote PE peers that participate in the same IPLS instance. Note that the same value of a
当PE发现每个本地连接的CE时，通过将CE的MAC地址和可选IP地址以及PW标签分发给参与相同IPLS实例的所有远程PE对等方，创建专门与该CE相关联的单播多点对点伪线（MP2P PW）。请注意，相同的
PW label SHOULD be distributed to all the remote PE peers for a given CE. The MP2P PW thus created is used by remote PEs to send unicast IP traffic to a specific CE.
PW标签应分发给给定CE的所有远程PE对等方。由此创建的MP2P PW被远程PEs用于向特定CE发送单播IP通信量。
(The same functionality can be provided by a set of point-to-point PWs, and the PE is not required to send the same PW label to all the other PEs. For convenience, however, we will use the term MP2P PWs, which may be implemented using a set of point-to-point PWs.)
（一组点到点PWs可以提供相同的功能，PE不需要向所有其他PE发送相同的PW标签。但是，为了方便起见，我们将使用术语MP2P PWs，可以使用一组点到点PWs来实现。）
The PE forwards a frame received over this MP2P PW to the associated AC.
PE将通过该MP2P PW接收的帧转发给相关联的AC。
The unicast PW uses IP Layer 2 Transport encapsulation as defined in [RFC4447].
单播PW使用[RFC4447]中定义的IP层2传输封装。
When a PE is configured to participate in an IPLS instance, it advertises a 'multicast' PW label to every other PE that is a member of the same IPLS. The advertised PW label value is the same for each PE, which creates an MP2P PW. There is only one such multicast MP2P PW per PE for each IPLS instance, and this PW is used exclusively to carry IP multicast/broadcast, ARP traffic, and (inverse) Neighbor Discovery packets for IPv6 from the remote PEs to this PE for this IPLS instance.
当一个PE被配置为参与IPLS实例时，它会向作为同一IPLS成员的每一个其他PE播发一个“多播”PW标签。每个PE的播发PW标签值相同，这将创建一个MP2P PW。对于每个IPLS实例，每个PE只有一个这样的多播MP2P PW，并且该PW专门用于将IPv6的IP多播/广播、ARP流量和（反向）邻居发现数据包从远程PE传送到此IPLS实例的PE。
Note that no special functionality is expected from this PW. We call it a 'multicast' PW because we use it to carry multicast and broadcast IP, ARP, and IPv6 Neighbor Discovery traffic. The PW itself need not provide any different service than any of the unicast PWs.
Note that no special functionality is expected from this PW. We call it a 'multicast' PW because we use it to carry multicast and broadcast IP, ARP, and IPv6 Neighbor Discovery traffic. The PW itself need not provide any different service than any of the unicast PWs.translate error, please retry
In particular, the Receive multicast MP2P PW does not perform any replication of frames itself. Rather, it is there to signify to the PE that the PE may need to replicate a copy of a frame received over this MP2P PW onto all the ACs that are associated with the IPLS instance of the MP2P PW.
特别地，接收多播MP2P PW本身不执行帧的任何复制。相反，这是为了向PE表示PE可能需要将通过该MP2P PW接收的帧的副本复制到与MP2P PW的IPLS实例相关联的所有ac上。
The multicast MP2P PW is considered the principal PW in the bundle of MP2P PWs that consists of one multicast MP2P PW and a variable number of unicast MP2P PWs for a given IPLS instance. In a principal role, multicast PW represents the IPLS instance. The life of all unicast PWs in the IPLS instance depends on the existence of the multicast PW. If, for some reason, multicast PWs cease to exist, all the associated unicast PWs in the bundle would be removed.
多播MP2P PW被认为是MP2P PW捆绑包中的主要PW，该捆绑包由一个多播MP2P PW和一个给定IPLS实例的可变数量的单播MP2P PW组成。在主体角色中，多播PW表示IPLS实例。IPLS实例中所有单播PW的寿命取决于多播PW的存在。如果由于某种原因，多播PW停止存在，那么捆绑包中所有相关的单播PW都将被删除。
The multicast PW uses Ethernet encapsulation as defined in [RFC4448].
多播PW使用[RFC4448]中定义的以太网封装。
The use of PWs that are specially optimized for multicast is for further study.
特别针对多播优化的PWs的使用有待进一步研究。
The PE creates a Send Multicast Replication Tree for each IPLS instance, which consists of the collection of all ACs and all the 'multicast' PWs of the IPLS instance.
PE为每个IPLS实例创建一个发送多播复制树，该树由IPLS实例的所有ACs和所有“多播”PW的集合组成。
Any ARP, Neighbor Discovery, or broadcast/multicast IP Ethernet frame received over an AC is replicated to the other ACs and to the MP2P multicast PW of the Send Multicast Replication Tree. The Send Multicast Replication Tree deals mostly with broadcast/multicast Ethernet MAC frames. One exception to this is unicast ARP and IPv6 Neighbor Discovery frame, the processing of which is described in the following section.
通过AC接收的任何ARP、邻居发现或广播/多播IP以太网帧被复制到其他AC和发送多播复制树的MP2P多播PW。发送多播复制树主要处理广播/多播以太网MAC帧。一个例外是单播ARP和IPv6邻居发现帧，其处理将在下一节中描述。
Any Ethernet frame received over the multicast PW is replicated to all the ACs of the Send Multicast Replication Tree of the IPLS instance associated with the incoming PW label: one exception is unicast ARP and Neighbor Discovery frames used for IPv6, the processing of which is described in the following section.
通过多播PW接收的任何以太网帧都将复制到与传入PW标签相关联的IPLS实例的发送多播复制树的所有ACs：一个例外是用于IPv6的单播ARP和邻居发现帧，其处理将在下一节中描述。
[RFC4447] uses LDP to exchange PW FECs in the Label Mapping message in a downstream unsolicited mode. The PW FEC comes in two forms; PWid and Generalized PWid FEC elements. These FEC elements define some fields that are common between them. The discussions below refer to these common fields for IPLS-related extensions. Note that the use of multipoint-to-point and unidirectional characteristics of the PW makes BGP the ideal candidate for PW FEC signaling. The use of BGP for such purposes is for future study.
[RFC4447]使用LDP在下游非请求模式下交换标签映射消息中的PW FEC。PW FEC有两种形式；PWid和广义PWid FEC元素。这些FEC元素定义了它们之间的一些公共字段。下面的讨论涉及IPLS相关扩展的这些公共字段。注意，PW多点对点和单向特性的使用使BGP成为PW FEC信令的理想候选。出于此类目的使用BGP是为了将来的研究。
An IPLS carries IP packets as payload over its unicast PWs and Ethernet frames as payload over its multicast PW. The PW type to be used for unicast PW is the IP PW, defined in [RFC4447] as IP Layer 2 Transport. The PW type to be used for multicast PW is the Ethernet PW as defined in [RFC4448]. The PW type values for these encapsulations are defined in [RFC4446].
IPLS通过其单播PW承载IP数据包作为有效载荷，通过其多播PW承载以太网帧作为有效载荷。用于单播PW的PW类型是IP PW，在[RFC4447]中定义为IP层2传输。用于多播PW的PW类型是[RFC4448]中定义的以太网PW。[RFC4446]中定义了这些封装的PW类型值。
When processing a received PW FEC, the PE matches the PW Id with the locally configured PW Id for the IPLS instance. If the PW type is Ethernet, the PW FEC is for multicast PWs. If the PW type is 'IP Layer 2 transport', the PW FEC is for unicast PWs.
处理接收到的PW FEC时，PE将PW Id与IPLS实例的本地配置PW Id相匹配。如果PW类型为以太网，则PW FEC用于多播PWs。如果PW类型为“IP层2传输”，则PW FEC用于单播PWs。
For unicast PWs, the PE must check the presence of a MAC Address TLV in the optional parameter fields of the Label Mapping message. If this parameter is absent, a Label Release message must be issued with a status code meaning "MAC Address of the CE is absent" (note: status code 0x000000XX is pending IANA allocation (see Section 7)), to reject the establishment of the unicast PW with the remote PE.
对于单播PW，PE必须检查标签映射消息的可选参数字段中是否存在MAC地址TLV。如果此参数不存在，则必须发出标签释放消息，其状态代码表示“CE的MAC地址不存在”（注：状态代码0x000000XX正在等待IANA分配（参见第7节）），以拒绝与远程PE建立单播PW。
The PE may optionally include an IP address TLV based on the user configuration for the advertising of the IP addresses of the local CE.
PE可以可选地包括基于用于本地CE的IP地址的广告的用户配置的IP地址TLV。
The processing of the Address List TLV is as follows.
地址列表TLV的处理如下所示。
o If a PW is configured for ACs with IPv4 CEs only, the PE should advertise an Address List TLV with an Address Family type of an IPv4 address. The PE should process the IPv4 address list TLV as described in this document.
o 如果仅为具有IPv4 CE的ACs配置PW，则PE应使用IPv4地址的地址族类型播发地址列表TLV。PE应按照本文档中的说明处理IPv4地址列表TLV。
o If a PW is configured for ACs with both IPv4 and IPv6 CEs, the PE should advertise IPv6 capability using the procedures described in the section below.
o 如果为同时具有IPv4和IPv6 CE的ACs配置了PW，则PE应使用以下部分中描述的过程公布IPv6功能。
o If a PE does not receive any IP Address List TLV or IPv6 capability advertisement, it MAY assume IPv4 behavior.
o 如果PE未收到任何IP地址列表TLV或IPv6功能播发，则它可能会采取IPv4行为。
The IPLS uses the Address List TLV as defined in [RFC5036] to signal the MAC (and optionally IP) address of the local CE. There are two TLVs defined below: the IP Address TLV and MAC Address TLV. The MAC Address TLV must be included in the optional parameter field of the Label Mapping message when establishing the unicast IP PW for IPLS.
IPLS使用[RFC5036]中定义的地址列表TLV向本地CE的MAC（和可选IP）地址发送信号。下面定义了两个TLV：IP地址TLV和MAC地址TLV。为IPL建立单播IP PW时，MAC地址TLV必须包含在标签映射消息的可选参数字段中。
When configured to support a specific type of IP traffic (IPv4 or IPv6), the PE verifies the type of IP traffic the PW will carry. If there is a mismatch between the received Address Family value and the expectation of an IPLS instance to which the PW belongs, the PE must issue a Label Release message with a status code meaning "IP Address type mismatch" (status code 0x0000004A) to reject the PW establishment.
当配置为支持特定类型的IP流量（IPv4或IPv6）时，PE验证PW将承载的IP流量类型。如果收到的地址系列值与PW所属IPLS实例的期望值不匹配，则PE必须发出一条状态代码为“IP地址类型不匹配”（状态代码0x0000004A）的标签释放消息，以拒绝PW建立。
The encoding of the IP Address TLV is as follows:
IP地址TLV的编码如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Address List (0x0101) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | CE IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE IP Address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Address List (0x0101) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | CE IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE IP Address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length When an Address Family is IPv4, the Length is equal to 6 bytes; 2 bytes for the Address Family and 4 bytes of IP address. The Length is 18 bytes when the Address Family is IPv6; 2 bytes for the Address Family and 16 bytes of IP address.
长度当地址族为IPv4时，长度等于6字节；地址系列为2字节，IP地址为4字节。地址族为IPv6时长度为18字节；地址系列为2字节，IP地址为16字节。
Address Family Two-octet quantity containing a value from the "Address Family Numbers" registry [ADDR-IANA] that encodes the addresses contained in the Addresses field.
地址族两个八位字节数量，包含来自“地址族编号”注册表[ADDR-IANA]的值，该注册表对地址字段中包含的地址进行编码。
CE IP Address IP address of the CE attached to the advertising PE. The encoding of the individual address depends on the Address Family.
CE IP地址附加到广告PE的CE的IP地址。单个地址的编码取决于地址族。
The following address encodings are defined by this version of the protocol:
此版本的协议定义了以下地址编码：
Address Family Address Encoding
地址族地址编码
IPv4 (1) 4-octet full IPv4 address
IPv4（1）4八位组完整IPv4地址
IPv6 (2) 16-octet full IPv6 address
IPv6（2）16八位组完整IPv6地址
Note that more than one instance of the IP address TLV may exist, especially when support for IPv6 is configured.
请注意，IP地址TLV可能存在多个实例，尤其是在配置了对IPv6的支持时。
The encoding of the MAC Address TLV is as follows:
MAC地址TLV的编码如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Address List (0x0101) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | CE's MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Address List (0x0101) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | CE's MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length The Length field is set to a value of 8 (2 bytes for the Address Family, 6 bytes for the MAC address)
长度长度字段设置为8（地址系列为2字节，MAC地址为6字节）
Address Family Two-octet quantity containing a value from the "Address Family Numbers" registry [ADDR-IANA] that encodes the addresses contained in the Addresses field.
地址族两个八位字节数量，包含来自“地址族编号”注册表[ADDR-IANA]的值，该注册表对地址字段中包含的地址进行编码。
CE's MAC Address MAC address of the CE attached to the advertising PE. The encoding of the individual address depends on the Address Family.
CE的MAC地址连接到广告PE的CE的MAC地址。单个地址的编码取决于地址族。
The following address encodings are defined by this version of the protocol:
此版本的协议定义了以下地址编码：
Address Family Address Encoding
地址族地址编码
MAC (6) 6-octet full Ethernet MAC address
MAC（6）6八位全以太网MAC地址
The IPv4 address of the CE is also supplied in the optional parameters field of the LDP Notification message along with the PW FEC. The LDP Notification message is used to signal any change in the status of the CE's IPv4 address.
CE的IPv4地址也与PW FEC一起提供在LDP通知消息的可选参数字段中。LDP通知消息用于表示CE IPv4地址状态的任何更改。
Note that Notification message does not apply to the MAC Address TLV since an update to the MAC address of the CE should result in label withdrawal followed by establishment of a new PW with a new MAC address of the CE. However, advertisement of IP address(es) of the CE is optional, and changes may become known after the establishment of unicast PW.
注意，通知消息不适用于MAC地址TLV，因为对CE的MAC地址的更新应导致标签撤销，然后使用CE的新MAC地址建立新PW。然而，CE的IP地址（es）的广告是可选的，并且在单播PW建立之后可以知道改变。
The encoding of the LDP Notification message is as follows.
LDP通知消息的编码如下所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address List TLV (as defined above) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWId FEC or Generalized ID FEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address List TLV (as defined above) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWId FEC or Generalized ID FEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Status TLV status code is set to 0x0000002C "IP address of CE", to indicate that an IP address update follows. Since this notification does not refer to any particular message, the Message ID and Message Type fields are set to 0.
状态TLV状态代码设置为0x0000002C“CE的IP地址”，以指示随后的IP地址更新。由于此通知不引用任何特定消息，因此消息ID和消息类型字段设置为0。
The PW FEC TLV SHOULD NOT include the interface parameters as they are ignored in the context of this message.
PW FEC TLV不应包括接口参数，因为在该消息的上下文中会忽略这些参数。
A 'Stack Capability' Interface Parameter sub-TLV is signaled by the two PEs so that they can agree which stack(s) they should be using. It is assumed, by default, that the IP PW will always be capable of carrying IPv4 packets. Thus, this capability sub-TLV is used to indicate if other stacks need to be supported concurrently with IPv4.
“Stack Capability”接口参数sub TLV由两个PE发出信号，以便他们能够商定应使用的堆栈。默认情况下，假定IP PW始终能够承载IPv4数据包。因此，此功能子TLV用于指示是否需要与IPv4同时支持其他堆栈。
The 'Stack Capability' sub-TLV is part of the interface parameters of the PW FEC. The proposed format for the 'Stack Capability' Interface Parameter sub-TLV is as follows:
“堆栈能力”子TLV是PW FEC接口参数的一部分。“堆栈能力”接口参数sub-TLV的建议格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter ID | Length | Stack Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter ID | Length | Stack Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter ID = 0x16
参数ID=0x16
Length = 4
Length = 4
Stack Capability = 0x000X to indicate IPv6 stack capability
堆栈能力=0x000X，表示IPv6堆栈能力
The value of Stack Capability is dependent on the PW type context. For IP PW type, a setting of 0x000X indicates IPv6 stack capability.
堆栈能力的值取决于PW类型上下文。对于IP PW类型，0x000X的设置表示IPv6堆栈能力。
A PE that supports IPv6 on an IP PW MUST signal the 'Stack Capability' sub-TLV in the initial Label Mapping message for the PW. The PE nodes compare the value advertised by the remote PE with the local configuration and only use a capability that is advertised by both. If a PE that supports IPv6 does not receive a 'Stack Capability' sub-TLV from the far-end PE in the initial Label Mapping message, or one is received but it is set to a reserved value, the PE MUST send an unsolicited release for the PW label with the LDP status code meaning "IP Address type mismatch" (status code 0x0000004A).
在IP PW上支持IPv6的PE必须在PW的初始标签映射消息中通知“堆栈能力”子TLV。PE节点将远程PE公布的值与本地配置进行比较，并且仅使用由两者公布的功能。如果支持IPv6的PE在初始标签映射消息中未从远端PE接收到“堆栈能力”子TLV，或者接收到一个子TLV，但将其设置为保留值，则PE必须发送一个未经请求的PW标签释放，LDP状态代码表示“IP地址类型不匹配”（状态代码0x0000004A）。
The behavior of a PE that does not understand an interface parameter sub-TLV is specified in RFC 4447 [RFC4447].
RFC 4447[RFC4447]中规定了不理解接口参数sub TLV的PE的行为。
A PE should process a received [RFC4447] advertisement with a PW type of IP Layer 2 Transport for IPLS as follows:
PE应处理接收到的[RFC4447]播发，其IP层2传输的PW类型为IPL，如下所示：
- Verify the IPLS VPN membership by matching the VPN-ID signaled in the Attachment Group Identifier (AGI) field or the PWid field with all the VPN-IDs configured in the PE. Discard and release the PW label if VPN-ID is not found.
- 通过将附件组标识符（AGI）字段或PWid字段中发送的VPN-ID与PE中配置的所有VPN ID相匹配，验证IPLS VPN成员身份。如果找不到VPN-ID，则丢弃并释放PW标签。
- Program the FIB such that when a unicast IP packet is received from an AC with its destination MAC address matching the advertised MAC address, the packet is forwarded out over the tunnel to the advertising PE with the advertised PW label as the inner label.
- 对FIB进行编程，使得当从AC接收到其目的地MAC地址与广告MAC地址匹配的单播IP分组时，该分组通过隧道转发到广告PE，广告PW标签作为内部标签。
A PE should process a received [RFC4447] advertisement with the PW type of Ethernet for IPLS as follows:
PE应按照以下方式处理接收到的[RFC4447]公告，其中包含IPL的PW类型以太网：
- Verify the IPLS VPN membership by matching the VPN-ID signaled in the AGI field or the PWid field with all the VPN-IDs configured in the PE. Discard and release the PW label if VPN-ID is not found.
- 通过将AGI字段或PWid字段中发送的VPN-ID与PE中配置的所有VPN ID相匹配，验证IPLS VPN成员身份。如果找不到VPN-ID，则丢弃并释放PW标签。
- Add the PW label to the send broadcast replication tree for the VPN-ID. This enables the sending of a copy of a multicast/broadcast IP Ethernet frame, ARP Ethernet frame, or Neighbor Discovery frame from the AC to this PW.
- 将PW标签添加到VPN-ID的发送广播复制树中。这允许将多播/广播IP以太网帧、ARP以太网帧或邻居发现帧的副本从AC发送到此PW。
Since this document is being published as Historic, no registration of IANA code points is necessary. However, in the future, if interest to pursue this proposal arises, the following IANA code registrations would become necessary.
由于本文件作为历史文件发布，无需注册IANA代码点。然而，在未来，如果有兴趣继续此提案，则有必要进行以下IANA代码注册。
This document uses a new LDP status code. IANA already maintains the "Status Code Name Space" registry defined by [RFC5036]. The following allocation would be needed from the LDP Status Code Name Space.
本文件使用新的LDP状态码。IANA已经维护了[RFC5036]定义的“状态代码名称空间”注册表。需要从LDP状态代码名称空间进行以下分配。
0x000000XX "MAC Address of CE is absent"
0x000000XX“缺少CE的MAC地址”
This document proposes a new Interface Parameters sub-TLV, to be assigned from the "Pseudowire Interface Parameters Sub-TLV type Registry". The following allocation would be needed for the Parameter ID:
本文件提出了一个新的接口参数子TLV，将从“伪线接口参数子TLV类型注册表”中分配。参数ID需要以下分配：
0xXX "Stack Capability"
0xXX“堆栈能力”
IANA would also be requested to set up an "L2VPN PE Stack Capabilities" registry. This is a 16-bit field. The Stack Capability value (0x000X) is specified in Section 6.2 of this document. The remaining bit field values (0x0002,..,0x8000) would be assigned by IANA using the "IETF Consensus" policy defined in [RFC5226].
IANA还将被要求建立一个“L2VPN PE堆栈功能”注册表。这是一个16位字段。本文件第6.2节规定了堆栈能力值（0x000X）。IANA将使用[RFC5226]中定义的“IETF共识”策略分配剩余的位字段值（0x0002，…，0x8000）。
L2VPN PE Stack Capabilities:
L2VPN PE堆栈功能：
Bit (Value) Description
=============== ==========================================
Bit 0 (0x000X) IPv6 stack capability
Bit 1 (0x000X) Reserved
Bit 2 (0x000X) Reserved
.
.
.
Bit 14 (0xX000) Reserved
Bit 15 (0xX000) Reserved
Bit (Value) Description
=============== ==========================================
Bit 0 (0x000X) IPv6 stack capability
Bit 1 (0x000X) Reserved
Bit 2 (0x000X) Reserved
.
.
.
Bit 14 (0xX000) Reserved
Bit 15 (0xX000) Reserved
In an IPLS VPN, a PE forwards only IP and ARP traffic. All other frames are dropped silently. If the CEs must pass non-IP traffic to each other, they must do so through IP tunnels that terminate at the CEs themselves.
在IPLS VPN中，PE仅转发IP和ARP流量。所有其他帧都以静默方式删除。如果CEs必须相互传递非IP流量，则它们必须通过终止于CEs自身的IP隧道来传递。
In IPLS, IP traffic is forwarded from the AC to the PW based on the destination MAC address of the L2 frame (and not based on the IP header).
在IPLS中，IP通信量基于L2帧的目标MAC地址（而不是基于IP报头）从AC转发到PW。
The PE identifies the FIB associated with an IPLS instance based on the AC or the PW label. When a frame is received from an AC, the PE uses the destination MAC address as the lookup key. When a frame is received from a PW, the PE uses the PW label as the lookup key. The frame is dropped if the lookup fails.
PE根据AC或PW标签识别与IPLS实例关联的FIB。当从AC接收到帧时，PE使用目标MAC地址作为查找密钥。当从PW接收到帧时，PE使用PW标签作为查找键。如果查找失败，将删除该帧。
For IPv6 support, the unicast IP ICMP frame of Neighbor Discovery Protocol [RFC4861] is bi-casted; one copy is submitted to the control plane and other copy to the PW, based on the destination MAC address.
对于IPv6支持，邻居发现协议[RFC4861]的单播IP ICMP帧是双向广播的；根据目标MAC地址，一份提交给控制平面，另一份提交给PW。
When the destination MAC address is either broadcast or multicast, a copy of the frame is sent to the control plane for CE discovery purposes (see Section 4.1). It is important to note that stricter rate-limiting criteria is applied to frames sent to the control plane, in order to avoid overwhelming it under adverse conditions such as DoS attacks. The service provider should also provide a configurable limitation to prevent the overflowing of the learned source addresses in a given IPLS instance. Also, caution must be used such that only link-local multicasts and broadcast IP packets are sent to the control plane.
当目标MAC地址为广播或多播时，帧的副本被发送到控制平面，用于CE发现（参见第4.1节）。需要注意的是，发送到控制平面的帧采用了更严格的速率限制标准，以避免在DoS攻击等不利条件下压倒控制平面。服务提供商还应提供一个可配置的限制，以防止已知IPLS实例中学习的源地址溢出。此外，必须注意，只有链路本地多播和广播IP数据包被发送到控制平面。
When a multicast/broadcast IP packet is received from an AC, the PE replicates it onto the Send Multicast Replication Tree (see Section 5.3). When a multicast/broadcast IP Ethernet frame is received from a PW, the PE forwards a copy of the frame to all the ACs associated with the respective IPLS VPN instance. Note that 'multicast' PW uses Ethernet encapsulation; hence, it does not require additional header manipulations.
当从AC接收到多播/广播IP数据包时，PE将其复制到发送多播复制树上（参见第5.3节）。当从PW接收到多播/广播IP以太网帧时，PE将该帧的副本转发给与相应IPLS VPN实例相关联的所有ACs。注意，“多播”PW使用以太网封装；因此，它不需要额外的标头操作。
When a broadcast ARP frame is received over the AC, a copy of the frame is sent to the control plane for CE discovery purposes. The PE replicates the frame onto the Send Multicast Replication Tree (see Section 5.3), which results in a copy to be delivered to all the remote PEs on the 'multicast' PW and other local CEs through the egress ACs.
当通过AC接收到广播ARP帧时，帧的副本被发送到控制平面以用于CE发现目的。PE将帧复制到发送多播复制树（参见第5.3节）上，从而通过出口ACs将副本发送到“多播”PW上的所有远程PE和其他本地CE。
When a broadcast Ethernet ARP frame is received over the 'multicast' PW, a copy of the Ethernet ARP frame is sent to all the ACs associated with the IPLS instance.
当通过“多播”PW接收到广播以太网ARP帧时，以太网ARP帧的副本被发送到与IPLS实例相关联的所有ACs。
When a unicast Ethernet ARP frame is received over the AC, a copy of the frame is sent to the control plane for CE discovery purposes. The PE may optionally do destination MAC address lookup in the forwarding table and send the ARP frame to a specific egress interface (AC or 'multicast' PW to a remote PE) or replicate the frame onto the Send Multicast Replication Tree (see Section 5.3).
当通过AC接收到单播以太网ARP帧时，帧的副本被发送到控制平面以用于CE发现目的。PE可以选择在转发表中查找目的地MAC地址，并将ARP帧发送到特定出口接口（AC或“多播”PW到远程PE），或将帧复制到发送多播复制树上（参见第5.3节）。
When a unicast ARP Ethernet frame is received over the 'multicast' PW, the PE may optionally do destination MAC address lookup in the forwarding table and forward it to the AC where the CE is located. If the CE is not accessible through any local AC, the frame is dropped. Conversely, the PE may simply forward the frame to all the ACs associated with that IPLS instance without any lookup in the forwarding table.
当通过“多播”PW接收到单播ARP以太网帧时，PE可以选择性地在转发表中查找目的地MAC地址，并将其转发到CE所在的AC。如果无法通过任何本地AC访问CE，则会丢弃帧。相反，PE可以简单地将帧转发给与该IPLS实例相关联的所有ac，而不在转发表中进行任何查找。
A PE device that supports IPv6 MUST be capable of:
支持IPv6的PE设备必须能够：
- Intercepting ICMPv6 Neighbor Discovery [RFC4861] packets received over the AC.
- 拦截通过AC接收的ICMPv6邻居发现[RFC4861]数据包。
- Recording the IPv6 interface addresses and CE link-layer addresses present in these packets
- 记录这些数据包中存在的IPv6接口地址和CE链路层地址
- Forwarding them towards the original destination. A PE device may also intercept Router Discovery packets in order to discover the link-layer address and IPv6 interface address(es) of the CE. The following sections describe the details.
- 将它们转发到原始目的地。PE设备还可以拦截路由器发现分组，以便发现CE的链路层地址和IPv6接口地址。以下各节介绍了详细信息。
The PE device MUST learn the link-layer address of the local CE and be able to use it when forwarding traffic between CEs. The PE MAY also wish to monitor the source link-layer address of data packets
PE设备必须了解本地CE的链路层地址，并能够在CE之间转发流量时使用该地址。PE还可能希望监视数据分组的源链路层地址
received from the CE and discard packets not matching its learned CE link-layer address. The PE device may also optionally learn a list of CE IPv6 interface addresses for its directly attached CE.
从CE接收并丢弃与其读入的CE链路层地址不匹配的数据包。PE设备还可以可选地学习其直接连接的CE的CE IPv6接口地址列表。
When a multicast NS frame is received over the AC, a copy of the frame is sent to the control plane for CE discovery purposes. The PE replicates the frame onto the Send Multicast Replication Tree (see Section 5.3), which results in a copy to be delivered to all the remote PEs on the 'multicast' PW and other local CEs through the egress ACs. The PE may optionally learn an IPv6 interface address (If provided -- this will not be the case for Duplicate Address Detection) when present.
当通过AC接收到多播NS帧时，帧的副本被发送到控制平面以用于CE发现目的。PE将帧复制到发送多播复制树（参见第5.3节）上，从而通过出口ACs将副本发送到“多播”PW上的所有远程PE和其他本地CE。当存在IPv6接口地址时，PE可以选择性地学习该地址（如果提供了，则不会进行重复地址检测）。
When a multicast Ethernet NS frame is received over the 'multicast' PW, a copy is sent to all the ACs associated with the IPLS instance.
当通过“多播”PW接收到多播以太网NS帧时，将向与IPLS实例关联的所有ACs发送副本。
When a unicast NA is received over the AC, a copy of the frame is sent to the control plane for the CE discovery purposes. The PE may optionally do destination MAC address lookup in the forwarding table and send the NA frame to a specific egress interface (AC or 'multicast' PW to a remote PE) or replicate the frame onto the Send Multicast Replication Tree (see Section 5.3).
当通过AC接收到单播NA时，帧的副本被发送到控制平面以用于CE发现目的。PE可以选择在转发表中查找目的地MAC地址，并将NA帧发送到特定出口接口（AC或“多播”PW到远程PE），或将该帧复制到发送多播复制树上（参见第5.3节）。
Optionally, the PE could learn the IPv6 Interface address of the CE.
可选地，PE可以学习CE的IPv6接口地址。
When a unicast NA frame is received over the 'multicast' PW, the PE may optionally do destination MAC address lookup in the forwarding table and forward it to the AC where the CE is located. If the CE is not accessible through any local AC, the frame is dropped. Conversely, the PE may simply forward the frame to all the ACs associated with that IPLS instance without any lookup in the forwarding table.
当通过“多播”PW接收到单播NA帧时，PE可以选择性地在转发表中进行目的地MAC地址查找，并将其转发到CE所在的AC。如果无法通过任何本地AC访问CE，则会丢弃帧。相反，PE可以简单地将帧转发给与该IPLS实例相关联的所有ac，而不在转发表中进行任何查找。
Inverse Neighbor Discovery is typically used on non-broadcast links, but is allowed on broadcast links as well [RFC3122]. A PE may optionally intercept Inverse Neighbor Solicitation and Advertisement and learn the MAC and IPv6 interface address list of the attached CE from the copy of the frame sent to the control plane. The PE may optionally do destination MAC address lookup in the forwarding table and send another copy of the frame to a specific egress interface (AC or 'multicast' PW to a remote PE) or replicate the frame onto the Send Multicast Replication Tree (see Section 5.3).
反向邻居发现通常用于非广播链路，但也允许用于广播链路[RFC3122]。PE可以选择性地截获反向邻居请求和广告，并从发送到控制平面的帧的副本中学习所附CE的MAC和IPv6接口地址列表。PE可以选择在转发表中查找目的地MAC地址，并将帧的另一个副本发送到特定出口接口（AC或“多播”PW到远程PE），或将帧复制到发送多播复制树上（参见第5.3节）。
RSs are multicast while RAs can be unicast or multicast Ethernet frames. The PE could optionally intercept RS and RA frames and send a copy to the control plane. The PE may learn the MAC address and a list of interface addresses for the attached CE.
RSs是多播，而RAs可以是单播或多播以太网帧。PE可以选择性地截获RS和RA帧，并向控制平面发送副本。PE可以学习所附CE的MAC地址和接口地址列表。
For unicast RA, the PE may optionally do destination MAC address lookup in the forwarding table and send the RA frame to a specific egress interface (AC or 'multicast' PW to a remote PE) or replicate the frame onto the Send Multicast Replication Tree (see Section 5.3). The multicast RA and RS Ethernet frames are replicated using the Send Multicast Replication Tree as described in Section 5.3.
对于单播RA，PE可以选择在转发表中查找目标MAC地址，并将RA帧发送到特定出口接口（AC或“多播”PW到远程PE），或将帧复制到发送多播复制树上（参见第5.3节）。如第5.3节所述，使用发送多播复制树复制多播RA和RS以太网帧。
The Ethernet MAC header of a unicast IP packet received from an AC is stripped before forwarding the frame to the unicast PW. However, the MAC header is retained for the following cases,
从AC接收的单播IP分组的以太网MAC报头在将帧转发到单播PW之前被剥离。但是，在以下情况下，将保留MAC头：，
- when a frame is a unicast IP packet that is directed to a local AC.
- 当帧是定向到本地AC的单播IP分组时。
- when a frame is a broadcast/multicast IP packet
- 当帧是广播/多播IP数据包时
- when a frame is an ARP packet
- 当一帧是ARP数据包时
- when a frame is Neighbor/Router Solicitation/Advertisement
- 当帧是邻居/路由器请求/播发时
An IP frame received over a unicast PW is prepended with a MAC header before transmitting it on the appropriate AC(s). The fields in the MAC header are filled in as follows:
通过单播PW接收的IP帧在发送到适当的AC（s）上之前被预先加上MAC报头。MAC头中的字段填写如下：
- The destination MAC address is the MAC address associated with the PW label in the FIB.
- 目标MAC地址是与FIB中的PW标签相关联的MAC地址。
- The source MAC address is the PE's own local MAC address or a MAC address that has been specially configured on the PE for this use.
- 源MAC地址是PE自己的本地MAC地址，或者是PE上为此用途专门配置的MAC地址。
- The Ethernet Type field is 0x0800 if IPv4 or 0x86DD if IPv6 [RFC2464].
- 以太网类型字段为0x0800（如果是IPv4）或0x86DD（如果是IPv6）[RFC2464]。
- The frame may be IEEE 802.1Q tagged based on the VLAN information associated with the AC.
- 该帧可以基于与AC相关联的VLAN信息被IEEE 802.1Q标记。
A Frame Check Sequence (FCS) is appended to the frame.
帧检查序列（FCS）附加到帧。
In addition to (i) an Ethernet port and a (ii) combination of Ethernet port and a VLAN ID, an AC to IPLS may also be (iii) an ATM or FR Virtual Circuit (VC) carrying encapsulated bridged Ethernet frames or (iv) the combination of an ATM or FR VC and a VLAN ID.
除了（i）以太网端口和（ii）以太网端口和VLAN ID的组合之外，AC-to-IPLS还可以是（iii）承载封装桥接以太网帧的ATM或FR虚拟电路（VC），或者（iv）ATM或FR-VC和VLAN ID的组合。
The ATM/FR VC is just used as a way to transport Ethernet frames between a customer site and the PE. The PE terminates the ATM/FR VC and operates on the encapsulated Ethernet frames exactly as if those were received on a local Ethernet interface. When a frame is propagated from PW to an ATM or FR VC, the PE prepends the Ethernet frame with the appropriate bridged encapsulation header as defined in [RFC2684] and [RFC2427], respectively. Operation of an IPLS over ATM/FR VC is exactly as described above, with the exception that the AC is then identified via the ATM VCI/VPI or Frame Relay Data Link Connection Identifier (DLCI) (instead of via a local Ethernet port ID), or a combination of those with a VLAN ID.
ATM/FR VC仅用于在客户站点和PE之间传输以太网帧。PE终止ATM/FR VC，并在封装的以太网帧上操作，就像在本地以太网接口上接收到的帧一样。当帧从PW传播到ATM或FR VC时，PE分别使用[RFC2684]和[RFC2427]中定义的适当桥接封装报头为以太网帧进行前置。ATM/FR VC上IPLS的操作与上述完全相同，但AC随后通过ATM VCI/VPI或帧中继数据链路连接标识符（DLCI）（而不是通过本地以太网端口ID）或具有VLAN ID的组合来识别。
The VPLS approach proposed in [RFC4762] provides VPN services for IP as well as other protocols. The IPLS approach described in this document is similar to VPLS in many respects:
[RFC4762]中提出的VPLS方法为IP以及其他协议提供VPN服务。本文件中描述的IPLS方法在许多方面与VPLS类似：
- It provides a Provider-Provisioned Virtual LAN service with multipoint capability where a CE connected via a single attachment circuit can reach many remote CEs
- 它提供了提供商提供的具有多点功能的虚拟LAN服务，其中通过单个连接电路连接的CE可以到达多个远程CE
- It appears as a broadcast domain and a single subnet
- 它显示为广播域和单个子网
- Forwarding is based on destination MAC addresses
- 转发基于目标MAC地址
However, unlike VPLS, IPLS is restricted to IP traffic only. By restricting the scope of the service to the predominant type of traffic in today's environment, IPLS eliminates the need for service provider edge routers to implement some bridging functions such as MAC address learning in the data path (by, instead, distributing MAC information in the control plane). Thus, this solution offers a number of benefits:
但是，与VPLS不同，IPLS仅限于IP流量。通过将服务范围限制在当今环境中的主要流量类型，IPLS消除了服务提供商边缘路由器在数据路径中实现某些桥接功能（如MAC地址学习）的需要（相反，通过在控制平面中分发MAC信息）。因此，此解决方案提供了许多好处：
- It facilitates Virtual LAN services in instances where PE devices cannot or cannot efficiently (or are specifically configured not to) perform MAC address learning.
- 在PE设备不能或不能有效（或专门配置为不）执行MAC地址学习的情况下，它有助于虚拟LAN服务。
- Unknown Unicast frames are never flooded as would be the case in VPLS.
- 未知的单播帧永远不会像VPLS中那样被淹没。
- Encapsulation is more efficient (the MAC header is stripped) for unicast IP packets while traversing the backbone network.
- 对于单播IP数据包，在穿越主干网络时，封装更有效（MAC报头被剥离）。
- PE devices are not burdened with the processing overhead associated with traditional bridging (e.g., Spanning Tree Protocol (STP) processing, etc.). Note, however, that some of these overheads (e.g., STP processing) could optionally be turned off with a VPLS solution in the case where it is known that only IP devices are interconnected.
- PE设备不承担与传统桥接相关的处理开销（例如，生成树协议（STP）处理等）。然而，请注意，在已知只有IP设备互连的情况下，可以选择使用VPLS解决方案关闭其中一些开销（例如STP处理）。
- Loops (perhaps through backdoor links) are minimized since a PE could easily reject (via label release) a duplicate IP to MAC address advertisement.
- 循环（可能通过后门链接）被最小化，因为PE可以轻松拒绝（通过标签发布）重复的IP到MAC地址广告。
- Greater control over CE topology distribution is available.
- 可以更好地控制CE拓扑分布。
The solution described in this document offers IPLS service for IPv4 and IPv6 traffic only. For this reason, the MAC header is not carried over the unicast PW. It is reconstructed by the PE when receiving a packet from a unicast PW and the Ethertype 0x0800 or 0x86DD is used in the MAC header since IPv4 or IPv6, respectively, is assumed.
本文档中描述的解决方案仅为IPv4和IPv6流量提供IPLS服务。因此，MAC报头不通过单播PW携带。当从单播PW接收数据包时，它由PE重构，并且由于假定分别为IPv4或IPv6，所以在MAC报头中使用以太网类型0x0800或0x86DD。
However, this solution may be extended to carry other types of important traffic such as IS-IS , which does not use Ethernet-II, an EtherType-based header. In order to permit the propagation of such packets correctly, one may create a separate set of PWs, or pass protocol information in the "control word" of a "multiprotocol" PW, or encapsulate the Ethernet MAC header in the PW. The selection of appropriate multiplexing/demultiplexing schemes is the subject of future study. The current document focuses on IPLS service for IPv4 and IPv6 traffic.
但是，此解决方案可以扩展到承载其他类型的重要流量，例如IS-IS，它不使用以太网II（基于以太网类型的报头）。为了允许此类分组的正确传播，可以创建一组单独的PW，或者在“多协议”PW的“控制字”中传递协议信息，或者在PW中封装以太网MAC报头。选择合适的复用/解复用方案是未来研究的主题。当前文档的重点是IPv4和IPv6流量的IPLS服务。
As stated in previous sections, IPLS prohibits the connection of a common LAN or VLAN to more than one PE. However, the CE device itself can connect to more than one instance of IPLS through two separate LAN or VLAN connections to separate PEs. To the CE IP device, these separate connections appear as connections to two IP subnets. The failure of reachability through one subnet is then resolved via the other subnet using IP routing protocols.
如前几节所述，IPLS禁止将公共LAN或VLAN连接到多个PE。但是，CE设备本身可以通过两个单独的LAN或VLAN连接到单独的PE连接到多个IPL实例。对于CE IP设备，这些单独的连接显示为与两个IP子网的连接。然后使用IP路由协议通过另一个子网解决通过一个子网的可达性故障。
The earlier version of this proposal used IP-PW to carry both the broadcast/multicast and unicast IP traffic. It also discussed how PE proxy functionality responds to the ARP requests of the local CE on behalf of remote CE. The current version of the document eliminated these functions and instead uses Ethernet PW to carry broadcast, multicast and ARP frames to remote PEs. The motivation to use Ethernet PW and propagate ARP frames in the current version is to support configuration like back-to-back IPLS (similar to Inter-AS option-A configurations in [RFC4364]).
该方案的早期版本使用IP-PW承载广播/多播和单播IP流量。还讨论了PE代理功能如何代表远程CE响应本地CE的ARP请求。当前版本的文档取消了这些功能，而是使用以太网PW将广播、多播和ARP帧传送到远程PE。在当前版本中使用以太网PW和传播ARP帧的动机是支持像背靠背IPL这样的配置（类似于[RFC4364]中的Inter-AS option-A配置）。
The termination and controlled propagation of ARP frames is still a desirable option for security, DoS, and other purposes. For these reasons, we reintroduce the ARP Proxy [RFC925] function in this revision as an optional feature. The following sections describe this option.
ARP帧的终止和受控传播仍然是出于安全、DoS和其他目的的理想选择。出于这些原因，我们在本版本中重新引入ARP代理[RFC925]功能作为可选功能。以下各节介绍此选项。
As a local configuration, a PE can enable the ARP Proxy Responder function. In this mode, the local PE responds to ARP requests received over the Attachment Circuit via learned IP and MAC address associations, which are advertised by the remote PEs. In addition, the PE may utilize local policies to determine if ARP requests should be responded based on the source of the ARP request, rate at which the ARP requests are generated, etc. In a nutshell, when this feature is enabled, ARP requests are not propagated to remote PE routers that are members of the same IPLS instance.
作为本地配置，PE可以启用ARP代理响应程序功能。在此模式下，本地PE通过远程PE播发的学习IP和MAC地址关联响应通过连接电路接收的ARP请求。此外，PE可利用本地策略，根据ARP请求的来源、ARP请求的生成速率等确定是否应响应ARP请求。简言之，当启用此功能时，ARP请求不会传播到属于同一IPLS实例的远程PE路由器。
As a local configuration, a PE can enable the ARP Proxy Generator function. In this mode, the PE generates an ARP request for each IP and MAC address association received from the remote PEs. The remote CE's IP and MAC address is used as the source information in the ARP request while the destination IP address in the request is obtained from the local configuration (that is, user needs to configure an IP address when this feature is enabled). The ARP request is sent on the ACs that have ARP Proxy Generator enabled and is associated with the given IPLS instance.
作为本地配置，PE可以启用ARP代理生成器功能。在此模式下，PE为从远程PE接收的每个IP和MAC地址关联生成ARP请求。远程CE的IP和MAC地址用作ARP请求中的源信息，而请求中的目标IP地址是从本地配置获得的（即，启用此功能时，用户需要配置IP地址）。ARP请求在启用了ARP代理生成器并与给定IPLS实例关联的ACs上发送。
In addition, the PE may utilize local policies to determine which IP/MAC addresses are candidate for ARP request generation.
此外，PE可以利用本地策略来确定哪些IP/MAC地址是ARP请求生成的候选地址。
The ARP Proxy Generator feature is required to support back-to-back IPLS configuration when any member of the IPLS instance is using the ARP Proxy Responder function. An example of a back-to-back IPLS is a
当IPLS实例的任何成员正在使用ARP代理响应程序功能时，需要ARP代理生成器功能来支持背对背的IPLS配置。背对背IPLS的一个示例是
configuration where PE-1 (ASBR) in an IPLS cloud in one Autonomous System (say, AS-1) is connected via an AC to another PE-2 (ASBR) in an IPLS cloud in another Autonomous System (say, AS- 2) where each PE appears as CE to each other. Such configuration is described in [RFC4364] as option-A for inter-AS connectivity. The Proxy ARP Responder feature prevents propagation of ARP requests to PE-1 (ASBR) in AS-1. This necessitates that PE-1 (ASBR) in AS-1 generates an ARP request on behalf of each CE connected to the IPLS instance in AS-1 as a mean to 'advertise' the reachability to IPLS cloud in AS-2.
一个自治系统（如AS-1）中IPLS云中的PE-1（ASBR）通过AC连接到另一个自治系统（如AS-2）中IPLS云中的另一个PE-2（ASBR）的配置，其中每个PE彼此显示为CE。[RFC4364]将此类配置描述为as间连接的选项A。代理ARP响应程序功能可防止ARP请求传播到AS-1中的PE-1（ASBR）。这就需要AS-1中的PE-1（ASBR）代表连接到AS-1中IPLS实例的每个CE生成ARP请求，作为“宣传”AS-2中IPLS云的可达性的一种手段。
The resurgence of interest in providing an IP/MPLS-based solution for Data Center Networks (DCNs) deserves another look at the IPLS methodologies described in this document. The key requirement of a DCN to permit Virtual Machine (VM) mobility within or across a DCN necessitates extending the reachability of IP subnet over a LAN, transparently. In addition, VMs tendency to generate frequent gratuitous ARPs for location discovery necessitates a solution that curbs broadcasts closest to the source.
人们对为数据中心网络（DCN）提供基于IP/MPLS的解决方案的兴趣重新兴起，值得我们再看看本文档中描述的IPLS方法。DCN允许虚拟机（VM）在DCN内或跨DCN移动的关键要求是必须透明地在LAN上扩展IP子网的可达性。此外，虚拟机倾向于频繁生成免费的ARP用于位置发现，因此需要一种解决方案来限制距离源最近的广播。
The IPLS solution facilitates VM mobility by the PE closest to the new location signaling the MAC address to all remote peers. In addition, control-plane-based MAC learning mechanisms prevent flooding of unknown unicast across a DCN. The optional ARP proxy mechanisms further reduce ARP broadcast floods by preventing its reach across a local PE.
IPLS解决方案通过最靠近新位置的PE向所有远程对等方发送MAC地址信号，促进VM移动。此外，基于控制平面的MAC学习机制可防止未知单播在DCN上泛滥。可选的ARP代理机制通过防止ARP广播覆盖本地PE，进一步减少ARP广播洪水。
A more comprehensive description of the security issues involved in L2VPNs are covered in [RFC4111]. Most of the security issues can be avoided through implementation of appropriate guards. The security aspect of this solution is addressed for two planes: the control plane and data plane.
[RFC4111]对L2VPN中涉及的安全问题进行了更全面的描述。大多数安全问题都可以通过实施适当的防护措施来避免。此解决方案的安全方面针对两个平面：控制平面和数据平面。
The control-plane security pertains to establishing the LDP connection, PW establishment and CE's IP and MAC address distribution. The LDP connection between two trusted PEs can be achieved by each PE verifying the incoming connection against the configured peer's address and authenticating the LDP messages by verifying keyed digests. The PW establishments between two secure LDP peers do not pose security issue but mis-wiring could occur due to configuration error. Some checks, such as, proper PW type and other PW options may prevent mis-wiring due to configuration errors.
控制平面安全涉及建立LDP连接、PW建立和CE的IP和MAC地址分配。两个受信任的PE之间的LDP连接可以通过每个PE根据配置的对等方的地址验证传入连接并通过验证密钥摘要来验证LDP消息来实现。两个安全LDP对等点之间的PW建立不会造成安全问题，但由于配置错误，可能会发生错误接线。一些检查，例如，正确的PW类型和其他PW选项，可能会防止由于配置错误而导致接线错误。
The learning of the appropriate CE's IP and MAC address can be a security issue. It is expected that the local attachment circuit to CE be physically secured. If this is a concern, the PE must be configured with the CE's IP and MAC address. During each ARP frame processing, the PE must verify the received information against the configuration before accepting. This prevents theft of service, denial of service to a subscriber, or DoS attacks to all subscribers by malicious use of network services.
了解相应CE的IP和MAC地址可能是一个安全问题。预计本地连接电路将被物理固定。如果这是一个问题，PE必须配置CE的IP和MAC地址。在每个ARP帧处理期间，PE必须在接受之前根据配置验证接收到的信息。这可以防止恶意使用网络服务对所有订阅者进行窃取服务、拒绝服务或DoS攻击。
The IPLS also provides MAC anti-spoofing by preventing the use of already known MAC address. For instance, if a PE has already learned a presence of a CE through a local connection or from another PE, and subsequently an advertisement for the same MAC and/or IP address is received from a different PE, the receiving PE can terminate service to that CE (either through label release and/or removing the ARP entry from the FIB) and raise the alarm.
IPLS还通过防止使用已知的MAC地址来提供MAC反欺骗。例如，如果一个PE已经通过本地连接或从另一个PE了解到CE的存在，并且随后从另一个PE接收到相同MAC和/或IP地址的广告，则接收PE可以终止对该CE的服务（通过标签释放和/或从FIB中删除ARP条目）并发出警报。
The IPLS learns and distributes CE reachability through the control plane. This provides greater control over CE topology distribution through the application of local policies.
IPLS通过控制平面学习和分配CE可达性。这通过应用本地策略提供了对CE拓扑分布的更大控制。
The data traffic between the CE and PE is not encrypted. In an insecure environment, it is possible that a malicious user may tap into the CE-to-PE connection and could conduct an active or passive attack. An example of an active attack would be generating traffic using the spoofed destination MAC address on the Ethernet Attachment Circuit and a passive attack could include targeted or passive monitoring between the CE and PE. In order to avoid such hijacking, the local PE may verify the source MAC address of the received frame against the MAC address of the admitted connection. The frame is forwarded to the PW only when authenticity is verified. When spoofing is detected, the PE must sever the connection with the local CE, tear down the PW, and start over.
CE和PE之间的数据通信未加密。在不安全的环境中，恶意用户可能会侵入CE-to-PE连接并进行主动或被动攻击。主动攻击的一个示例是使用以太网连接电路上的伪造目的地MAC地址生成流量，被动攻击可能包括CE和PE之间的目标或被动监控。为了避免这种劫持，本地PE可以对照所允许的连接的MAC地址来验证所接收帧的源MAC地址。只有在验证真实性时，帧才会转发到PW。当检测到欺骗时，PE必须断开与本地CE的连接，拆除PW，然后重新启动。
Each IPLS instance uses its own FIB. This prevents leaking of one customer data into another.
每个IPLS实例都使用自己的FIB。这样可以防止一个客户数据泄漏到另一个客户数据中。
[IEEE802.1D] ISO/IEC 10038, ANSI/IEEE Std 15802-3:1998, "MAC Bridges".
[IEEE802.1D]ISO/IEC 10038，ANSI/IEEE标准15802-3:1998，“MAC网桥”。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982, <http://www.rfc-editor.org/info/rfc826>.
[RFC826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月<http://www.rfc-editor.org/info/rfc826>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998, <http://www.rfc-editor.org/info/rfc2464>.
[RFC2464]Crawford，M.，“通过以太网传输IPv6数据包”，RFC 2464，1998年12月<http://www.rfc-editor.org/info/rfc2464>.
[RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", RFC 3122, June 2001, <http://www.rfc-editor.org/info/rfc3122>.
[RFC3122]Conta，A.，“反向发现规范对IPv6邻居发现的扩展”，RFC3122，2001年6月<http://www.rfc-editor.org/info/rfc3122>.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006, <http://www.rfc-editor.org/info/rfc4446>.
[RFC4446]Martini，L.“伪线边到边仿真（PWE3）的IANA分配”，BCP 116，RFC 4446，2006年4月<http://www.rfc-editor.org/info/rfc4446>.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006, <http://www.rfc-editor.org/info/rfc4447>.
[RFC4447]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月<http://www.rfc-editor.org/info/rfc4447>.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006, <http://www.rfc-editor.org/info/rfc4448>.
[RFC4448]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，和G.Heron，“通过MPLS网络传输以太网的封装方法”，RFC 4448，2006年4月<http://www.rfc-editor.org/info/rfc4448>.
[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007, <http://www.rfc-editor.org/info/rfc4762>.
[RFC4762]Lasserre，M.，Ed.，和V.Kompella，Ed.，“使用标签分发协议（LDP）信令的虚拟专用LAN服务（VPLS）”，RFC 4762，2007年1月<http://www.rfc-editor.org/info/rfc4762>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年10月<http://www.rfc-editor.org/info/rfc5036>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[ADDR-IANA] IANA, "Address Family Numbers", http://www.iana.org/assignments/address-family-numbers/.
[ADDR-IANA]IANA，“地址系列编号”，http://www.iana.org/assignments/address-family-numbers/.
[RFC925] Postel, J., "Multi-LAN address resolution", RFC 925, October 1984, <http://www.rfc-editor.org/info/rfc925>.
[RFC925]Postel，J.，“多局域网地址解析”，RFC 925，1984年10月<http://www.rfc-editor.org/info/rfc925>.
[RFC2427] Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", STD 55, RFC 2427, September 1998, <http://www.rfc-editor.org/info/rfc2427>.
[RFC2427]Brown，C.和A.Malis，“帧中继上的多协议互连”，STD 55，RFC 2427，1998年9月<http://www.rfc-editor.org/info/rfc2427>.
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999, <http://www.rfc-editor.org/info/rfc2684>.
[RFC2684]Grossman，D.和J.Heinanen，“ATM适配层5上的多协议封装”，RFC 2684，1999年9月<http://www.rfc-editor.org/info/rfc2684>.
[RFC4111] Fang, L., Ed., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005, <http://www.rfc-editor.org/info/rfc4111>.
[RFC4111]Fang，L.，Ed.“提供商提供的虚拟专用网络（PPVPN）的安全框架”，RFC 4111，2005年7月<http://www.rfc-editor.org/info/rfc4111>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月<http://www.rfc-editor.org/info/rfc4364>.
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006, <http://www.rfc-editor.org/info/rfc4664>.
[RFC4664]Andersson，L.，Ed.，和E.Rosen，Ed.，“第二层虚拟专用网络（L2VPN）框架”，RFC 4664，2006年9月<http://www.rfc-editor.org/info/rfc4664>.
[RFC4665] Augustyn, W., Ed., and Y. Serbest, Ed., "Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks", RFC 4665, September 2006, <http://www.rfc-editor.org/info/rfc4665>.
[RFC4665]Augustyn，W.，Ed.，和Y.Serbest，Ed.，“第2层提供商提供的虚拟专用网络的服务要求”，RFC 46652006年9月<http://www.rfc-editor.org/info/rfc4665>.
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, March 2010, <http://www.rfc-editor.org/info/rfc5771>.
[RFC5771]Cotton，M.，Vegoda，L.，和D.Meyer，“IPv4多播地址分配的IANA指南”，BCP 51，RFC 57712010年3月<http://www.rfc-editor.org/info/rfc5771>.
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011, <http://www.rfc-editor.org/info/rfc6074>.
[RFC6074]Rosen，E.，Davie，B.，Radoaca，V.，和W.Luo，“第二层虚拟专用网络（L2VPN）中的资源调配、自动发现和信令”，RFC 6074，2011年1月<http://www.rfc-editor.org/info/rfc6074>.
Acknowledgements
致谢
Authors would like to thank Alp Dibirdi from Alcatel, Xiaohu Xu from Huawei, and other L2VPN working group members for their valuable comments.
作者要感谢阿尔卡特的Alp Dibirdi、华为的Xiaohu和L2VPN工作组其他成员的宝贵意见。
Contributors
贡献者
This document is the combined effort of the following individuals and many others who have carefully reviewed this document and provided the technical clarifications.
本文件是以下人员和许多其他人员的共同努力，他们仔细审查了本文件并提供了技术澄清。
K. Arvind Fortress Vach Kompella Alcatel-Lucent Matthew Bocci Alcatel-Lucent Shane Amante Apple
阿尔卡特朗讯阿尔卡特城堡酒店
Authors' Addresses
作者地址
Himanshu Shah Ciena Corp 3939 North 1st Street San Jose, CA 95110 United States
Himanshu Shah Ciena公司美国加利福尼亚州圣何塞北第一街3939号，邮编95110
EMail: hshah@ciena.com
EMail: hshah@ciena.com
Eric Rosen Juniper Networks, Inc. 10 Technology Park Drive Westford, MA, 01886 United States
Eric Rosen Juniper Networks，Inc.美国马萨诸塞州韦斯特福德科技园大道10号，邮编01886
EMail: erosen@juniper.net
EMail: erosen@juniper.net
Francois Le Faucheur Cisco Systems, Inc. Batiment D, 45 Allee des Ormes 06254 Mougins France
Francois Le Faucheur Cisco Systems，Inc.巴蒂门特D，45 Allee des Ormes 06254 Mougins France
EMail: flefauch@cisco.com
EMail: flefauch@cisco.com
Giles Heron Cisco Systems 9-11 New Square Bedfont Lakes Feltham Middlesex TW14 8HA United Kingdom
Giles Heron Cisco Systems 9-11 New Square Bedfont Lakes Feltham Middlesex TW14 8HA英国
EMail: giheron@cisco.com
EMail: giheron@cisco.com