Internet Engineering Task Force (IETF) J. Le Roux, Ed.
Request for Comments: 6348 T. Morin, Ed.
Category: Historic France Telecom - Orange
ISSN: 2070-1721 September 2011
Internet Engineering Task Force (IETF) J. Le Roux, Ed.
Request for Comments: 6348 T. Morin, Ed.
Category: Historic France Telecom - Orange
ISSN: 2070-1721 September 2011
Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol
标签分发协议的点对多点扩展要求
Abstract
摘要
This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multiprotocol Label Switching (MPLS) infrastructure.
本文档列出了一组功能要求，这些功能要求作为标签分发协议（LDP）扩展设计的输入，用于设置点对多点（P2MP）标签交换路径（LSP），以便通过多协议标签交换（MPLS）基础设施交付点对多点应用程序。
This work was overtaken by the protocol solution developed by the MPLS working group, but that solution did not closely follow the requirements documented here. This document is published as a historic record of the ideas and requirements that shaped the protocol work.
MPLS工作组开发的协议解决方案取代了这项工作，但该解决方案没有严格遵循此处记录的要求。本文件作为形成协议工作的想法和要求的历史记录出版。
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/rfc6348.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6348.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Context and Motivations . . . . . . . . . . . . . . . . . 6
1.4. Document Scope . . . . . . . . . . . . . . . . . . . . . . 7
2. Requirements Overview . . . . . . . . . . . . . . . . . . . . 7
3. Application Scenario . . . . . . . . . . . . . . . . . . . . . 8
4. Detailed Requirements . . . . . . . . . . . . . . . . . . . . 9
4.1. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. P2MP LSP FEC . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. P2MP LDP Routing . . . . . . . . . . . . . . . . . . . . . 10
4.4. Setting Up, Tearing Down, and Modifying P2MP LSPs . . . . 10
4.5. Label Advertisement . . . . . . . . . . . . . . . . . . . 10
4.6. Data Duplication . . . . . . . . . . . . . . . . . . . . . 11
4.7. Detecting and Avoiding Loops . . . . . . . . . . . . . . . 11
4.8. P2MP LSP Rerouting . . . . . . . . . . . . . . . . . . . . 11
4.9. Support for Multi-Access Networks . . . . . . . . . . . . 12
4.10. Support for Encapsulation in P2P and P2MP TE Tunnels . . . 12
4.11. Label Spaces . . . . . . . . . . . . . . . . . . . . . . . 13
4.12. IPv4/IPv6 Support . . . . . . . . . . . . . . . . . . . . 13
4.13. Multi-Area/AS LSPs . . . . . . . . . . . . . . . . . . . . 13
4.14. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.15. Graceful Restart and Fault Recovery . . . . . . . . . . . 14
4.16. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 14
4.17. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14
4.18. Backward Compatibility . . . . . . . . . . . . . . . . . . 14
5. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Requirements for MP2MP LSPs . . . . . . . . . . . . . . . 15
6. Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . 16
6.1. Performance . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Complexity and Risks . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Contributing Authors . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Context and Motivations . . . . . . . . . . . . . . . . . 6
1.4. Document Scope . . . . . . . . . . . . . . . . . . . . . . 7
2. Requirements Overview . . . . . . . . . . . . . . . . . . . . 7
3. Application Scenario . . . . . . . . . . . . . . . . . . . . . 8
4. Detailed Requirements . . . . . . . . . . . . . . . . . . . . 9
4.1. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. P2MP LSP FEC . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. P2MP LDP Routing . . . . . . . . . . . . . . . . . . . . . 10
4.4. Setting Up, Tearing Down, and Modifying P2MP LSPs . . . . 10
4.5. Label Advertisement . . . . . . . . . . . . . . . . . . . 10
4.6. Data Duplication . . . . . . . . . . . . . . . . . . . . . 11
4.7. Detecting and Avoiding Loops . . . . . . . . . . . . . . . 11
4.8. P2MP LSP Rerouting . . . . . . . . . . . . . . . . . . . . 11
4.9. Support for Multi-Access Networks . . . . . . . . . . . . 12
4.10. Support for Encapsulation in P2P and P2MP TE Tunnels . . . 12
4.11. Label Spaces . . . . . . . . . . . . . . . . . . . . . . . 13
4.12. IPv4/IPv6 Support . . . . . . . . . . . . . . . . . . . . 13
4.13. Multi-Area/AS LSPs . . . . . . . . . . . . . . . . . . . . 13
4.14. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.15. Graceful Restart and Fault Recovery . . . . . . . . . . . 14
4.16. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 14
4.17. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14
4.18. Backward Compatibility . . . . . . . . . . . . . . . . . . 14
5. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Requirements for MP2MP LSPs . . . . . . . . . . . . . . . 15
6. Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . 16
6.1. Performance . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Complexity and Risks . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Contributing Authors . . . . . . . . . . . . . . . . . . . . . . . 20
This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP) [MLDP], in order to deliver point-to-multipoint applications over a Multiprotocol Label Switching (MPLS) infrastructure.
本文件列出了一组功能要求，这些功能要求作为标签分发协议（LDP）扩展设计的输入，用于设置点对多点（P2MP）标签交换路径（LSP）[MLDP]，以便通过多协议标签交换（MPLS）基础设施交付点对多点应用。
This work was overtaken by the protocol solution developed by the MPLS working group and documented in [MLDP]. That solution did not closely follow the requirements documented here, and it was recognized that this document had served its purpose in driving discussions of how the solution should be designed. At this point, no further action is planned to update this document in line with the protocol solution, and this document is published simply as a historic record of the ideas and requirements that shaped the protocol work.
这项工作被MPLS工作组开发的协议解决方案取代，并记录在[MLDP]中。该解决方案没有严格遵循此处记录的要求，并且人们认识到，本文件在推动关于解决方案应如何设计的讨论方面发挥了作用。在这一点上，没有计划根据协议解决方案更新本文件的进一步行动，本文件仅作为形成协议工作的想法和要求的历史记录发布。
The document is structured as follows:
该文件的结构如下：
o Section 2 is an overview of the requirements.
o 第2节是需求概述。
o Section 3 illustrates an application scenario.
o 第3节演示了一个应用程序场景。
o Section 4 addresses detailed requirements for P2MP LSPs.
o 第4节阐述了P2MP LSP的详细要求。
o Section 5 discusses requirements for shared trees and multipoint-to-multipoint (MP2MP) LSPs.
o 第5节讨论了共享树和多点对多点（MP2MP）LSP的要求。
o Section 6 presents criteria against which a solution can be evaluated.
o 第6节介绍了评估解决方案的标准。
This document is a historic requirements document. To clarify statement of requirements, key words are used as follows. 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]中所述进行解释。
P2P: Point-to-Point
P2P：点对点
MP2P: Multipoint-to-Point
MP2P：多点对点
P2MP: Point-to-Multipoint
P2MP：点对多点
MP2MP: Multipoint-to-Multipoint
MP2MP：多点对多点
LSP: Label Switched Path
标签交换路径
LSR: Label Switching Router
标签交换路由器
PE: Provider Edge
PE：提供程序边缘
P: Provider
P：提供者
IGP: Interior Gateway Protocol
内部网关协议
AS: Autonomous System
AS：自治系统
The reader is assumed to be familiar with the terminology in [RFC3031], [RFC5036], and [RFC4026].
假定读者熟悉[RFC3031]、[RFC5036]和[RFC4026]中的术语。
Ingress LSR: Router acting as a sender of an LSP
入口LSR：充当LSP发送方的路由器
Egress LSR: Router acting as a receiver of an LSP
出口LSR：充当LSP接收器的路由器
P2P LSP: An LSP that has one unique Ingress LSR and one unique Egress LSR
P2P LSP：具有一个唯一入口LSR和一个唯一出口LSR的LSP
MP2P LSP: An LSP that has one or more Ingress LSRs and one unique Egress LSR
MP2P LSP：具有一个或多个入口LSR和一个唯一出口LSR的LSP
P2MP LSP: An LSP that has one unique Ingress LSR and one or more Egress LSRs
P2MP LSP：具有一个唯一入口LSR和一个或多个出口LSR的LSP
MP2MP LSP: An LSP that has one or more Leaf LSRs acting indifferently as Ingress or Egress LSR
MP2MP LSP：具有一个或多个叶LSR作为入口或出口LSR的LSP
Leaf LSR: An Egress LSR of a P2MP LSP or an Ingress/Egress LSR of an MP2MP LSP
叶LSR：P2MP LSP的出口LSR或MP2MP LSP的入口/出口LSR
Transit LSR: An LSR of a P2MP or MP2MP LSP that has one or more downstream LSRs
运输LSR：具有一个或多个下游LSR的P2MP或MP2MP LSP的LSR
Branch LSR: An LSR of a P2MP or MP2MP LSP that has more than one downstream LSR
分支LSR：具有多个下游LSR的P2MP或MP2MP LSP的LSR
Bud LSR: An LSR of a P2MP or MP2MP LSP that is an Egress but also has one or more directly connected downstream LSR(s)
Bud LSR：P2MP或MP2MP LSP的LSR，是出口，但也有一个或多个直接连接的下游LSR
P2MP tree: The ordered set of LSRs and links that comprise the path of a P2MP LSP from its Ingress LSR to all of its Egress LSRs.
P2MP树：组成P2MP LSP从其入口LSR到其所有出口LSR的路径的LSR和链路的有序集。
LDP [RFC5036] has been deployed for setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs, in order to offer point-to-point services in MPLS backbones.
LDP[RFC5036]已部署用于建立点对点（P2P）和多点对点（MP2P）LSP，以便在MPLS主干网中提供点对点服务。
There are emerging requirements for supporting delivery of point-to-multipoint applications in MPLS backbones, such as those defined in [RFC4834] and [RFC5501].
在MPLS主干网中支持点对多点应用程序的交付有新的需求，如[RFC4834]和[RFC5501]中定义的需求。
For various reasons, including consistency with P2P applications, and taking full advantages of MPLS network infrastructure, it would be highly desirable to use MPLS LSPs for the delivery of multicast traffic. This could be implemented by setting up a group of P2P or MP2P LSPs, but such an approach may be inefficient since it would result in data replication at the Ingress LSR and duplicate data traffic within the network.
出于各种原因，包括与P2P应用程序的一致性，以及充分利用MPLS网络基础设施，非常希望使用MPLS lsp来交付多播流量。这可以通过设置一组P2P或MP2P lsp来实现，但是这种方法可能效率低下，因为它将导致入口LSR处的数据复制和网络内的重复数据流量。
Hence, new mechanisms are required that would allow traffic from an Ingress LSR to be efficiently delivered to a number of Egress LSRs in an MPLS backbone on a point-to-multipoint LSP (P2MP LSP), avoiding duplicate copies of a packet on a given link and relying on MPLS traffic replication at some Branch LSRs.
因此，需要新的机制来允许来自入口LSR的流量有效地传送到点对多点LSP（P2MP LSP）上MPLS主干中的多个出口LSR，从而避免给定链路上的数据包的重复副本，并依赖于某些分支LSR上的MPLS流量复制。
Resource Reservation Protocol - Traffic Engineering (RSVP-TE) extensions for setting up point-to-multipoint Traffic Engineered LSPs (P2MP TE LSPs) have been defined in [RFC4875]. They meet requirements expressed in [RFC4461]. This approach is useful in network environments where P2MP Traffic Engineering capabilities are needed (optimization, QoS, fast recovery).
[RFC4875]中定义了用于建立点对多点流量工程LSP（P2MP TE LSP）的资源预留协议-流量工程（RSVP-TE）扩展。它们满足[RFC4461]中规定的要求。这种方法在需要P2MP流量工程功能（优化、QoS、快速恢复）的网络环境中非常有用。
However, for operators who want to support point-to-multipoint traffic delivery on an MPLS backbone, without Traffic Engineering needs, and who have already deployed LDP for P2P traffic, an interesting and useful approach would be to rely on LDP extensions in order to set up point-to-multipoint (P2MP) LSPs. This would bring
然而，对于那些希望在MPLS主干上支持点对多点流量交付而不需要流量工程的运营商，以及那些已经为P2P流量部署了LDP的运营商，一种有趣而有用的方法是依靠LDP扩展来建立点对多点（P2MP）LSP。这将带来
consistency with P2P MPLS applications and would ease the delivery of point-to-multipoint services in an MPLS backbone.
与P2P MPLS应用程序保持一致，并将简化MPLS主干中点对多点服务的交付。
This document focuses on the LDP approach for setting up P2MP LSPs. It lists a detailed set of requirements for P2MP extensions to LDP, so as to deliver P2MP traffic over an LDP-enabled MPLS infrastructure. The original intent was that these requirements should be used as guidelines when specifying LDP extensions.
本文件重点介绍用于设置P2MP LSP的LDP方法。它列出了LDP的P2MP扩展的一组详细要求，以便通过支持LDP的MPLS基础设施提供P2MP流量。最初的目的是，在指定LDP扩展时，应将这些要求用作指南。
Note that generic requirements for P2MP extensions to MPLS are out of the scope of this document. Rather, this document describes solution-specific requirements related to LDP extensions in order to set up P2MP LSPs.
请注意，MPLS的P2MP扩展的一般要求不在本文档的范围内。相反，本文档描述了与LDP扩展相关的解决方案特定需求，以建立P2MP LSP。
Note also that other mechanisms could be used for setting up P2MP LSPs (for instance, PIM extensions), but these are out of the scope of this document. The objective is not to compare these mechanisms but rather to focus on the requirements for an LDP extension approach.
还请注意，可以使用其他机制来设置P2MP LSP（例如，PIM扩展），但这些机制不在本文档的范围内。目的不是比较这些机制，而是关注LDP扩展方法的要求。
The P2MP LDP mechanism MUST support setting up P2MP LSPs, i.e., LSPs with one Ingress LSR and one or more Egress LSRs, with traffic replication at some Branch LSRs.
P2MP LDP机制必须支持设置P2MP LSP，即具有一个入口LSR和一个或多个出口LSR的LSP，并在某些分支LSR处进行流量复制。
The P2MP LDP mechanism MUST allow the addition or removal of leaves associated with a P2MP LSP.
P2MP LDP机制必须允许添加或移除与P2MP LSP相关的叶片。
The P2MP LDP mechanism MUST coexist with current LDP mechanisms and inherit its capability sets from [RFC5036]. It is of paramount importance that the P2MP LDP mechanism MUST NOT impede the operation of existing P2P/MP2P LDP LSPs. Also, the P2MP LDP mechanism MUST coexist with P2P and P2MP RSVP-TE mechanisms [RFC3209] [RFC4875]. It is of paramount importance that the P2MP LDP mechanism MUST NOT impede the operation of existing P2P and P2MP RSVP-TE LSPs.
P2MP LDP机制必须与当前LDP机制共存，并从[RFC5036]继承其能力集。最重要的是，P2MP LDP机制不得妨碍现有P2P/MP2P LDP LSP的运行。此外，P2MP LDP机制必须与P2P和P2MP RSVP-TE机制共存[RFC3209][RFC4875]。最重要的是，P2MP LDP机制不得妨碍现有P2P和P2MP RSVP-TE LSP的运行。
The P2MP LDP mechanism MAY also allow setting up multipoint-to-multipoint (MP2MP) LSPs connecting a group of Leaf LSRs acting indifferently as Ingress LSR or Egress LSR. This may allow a reduction in the amount of LDP state that needs to be maintained by an LSR.
P2MP LDP机制还可允许建立多点对多点（MP2MP）LSP，以连接一组作为入口LSR或出口LSR的叶LSR。这可允许减少需要由LSR维持的LDP状态的量。
Figure 1 below illustrates an LDP-enabled MPLS provider network, used to carry both unicast and multicast traffic of VPN customers following, for instance, the architecture defined in [MVPN] for BGP/ MPLS VPNs or the one defined in [VPLS-MCAST].
下面的图1说明了一个支持LDP的MPLS提供商网络，该网络用于承载VPN客户的单播和多播流量，例如，遵循[MVPN]中为BGP/MPLS VPN定义的架构或[VPLS-MCAST]中定义的架构。
In this example, a set of MP2P LDP LSPs is set up between Provider Edge (PE) routers to carry unicast VPN traffic within the MPLS backbone (not represented in Figure 1).
在此示例中，在提供商边缘（PE）路由器之间设置一组MP2P LDP LSP，以在MPLS主干内承载单播VPN流量（图1中未表示）。
In this example, a set of P2MP LDP LSPs is set up between PE routers acting as Ingress LSRs and PE routers acting as Egress LSRs, so as to support multicast VPN traffic delivery within the MPLS backbone.
在该示例中，在充当入口lsr的PE路由器和充当出口lsr的PE路由器之间建立一组P2MP LDP lsp，以便支持MPLS主干内的多播VPN业务交付。
For instance, a P2MP LDP LSP is set up between Ingress LSR PE1 and Egress LSRs PE2, PE3, and PE4. It is used to transport multicast traffic from PE1 to PE2, PE3, and PE4. P1 is a Branch LSR; it replicates MPLS traffic sent by PE1 to P2, P3, and PE2. P2 and P3 are non-Branch Transit LSRs; they forward MPLS traffic sent by P1 to PE3 and PE4, respectively.
例如，在入口LSR PE1和出口LSR PE2、PE3和PE4之间建立P2MP LDP LSP。它用于将多播流量从PE1传输到PE2、PE3和PE4。P1是分支LSR；它将PE1发送的MPLS流量复制到P2、P3和PE2。P2和P3为非支线运输LSR；它们将P1发送的MPLS流量分别转发给PE3和PE4。
PE1
*| *** P2MP LDP LSP
*|*****
P1-----PE2
*/ \*
*/ \*
*****/ \******
PE3----P2 P3----PE4
| |
| |
| |
PE5 PE6
PE1
*| *** P2MP LDP LSP
*|*****
P1-----PE2
*/ \*
*/ \*
*****/ \******
PE3----P2 P3----PE4
| |
| |
| |
PE5 PE6
Figure 1: P2MP LSP from PE1 to PE2, PE3, PE4
图1：从PE1到PE2、PE3、PE4的P2MP LSP
If later there are new receivers attached to PE5 and PE6, then PE5 and PE6 join the P2MP LDP LSP. P2 and P3 become Branch LSRs and replicate traffic received from P1 to PE3 and PE5 and to PE4 and PE6, respectively (see Figure 2 below).
如果以后有新的接收机连接到PE5和PE6，则PE5和PE6加入P2MP LDP LSP。P2和P3成为分支LSR，并分别将从P1接收的流量复制到PE3和PE5以及PE4和PE6（参见下面的图2）。
PE1
*| *** P2MP LDP LSP
*|*****
P1-----PE2
*/ \*
*/ \*
*****/ \******
PE3----P2 P3----PE4
*| |*
*| |*
*| |*
PE5 PE6
PE1
*| *** P2MP LDP LSP
*|*****
P1-----PE2
*/ \*
*/ \*
*****/ \******
PE3----P2 P3----PE4
*| |*
*| |*
*| |*
PE5 PE6
Figure 2: Attachment of PE5 and PE6
图2:PE5和PE6的附件
The above example is provided for the sake of illustration. Note that P2MP LSPs Ingress and Egress LSRs may not necessarily be PE routers. Also, Branch LSRs may not necessarily be P routers.
提供上述示例是为了进行说明。注意，P2MP lsp入口和出口lsr不一定是PE路由器。此外，分支lsr不一定是P路由器。
The P2MP LDP mechanism MUST support setting up P2MP LSPs. Data plane aspects related to P2MP LSPs are those already defined in [RFC4461]. That is, a P2MP LSP has one Ingress LSR and one or more Egress LSRs. Traffic sent by the Ingress LSR is received by all Egress LSRs. The specific aspect related to P2MP LSPs is the action required at a Branch LSR, where data replication occurs. Incoming labeled data is appropriately replicated to several outgoing interfaces, which may use different labels.
P2MP LDP机制必须支持设置P2MP LSP。与P2MP LSP相关的数据平面方面已经在[RFC4461]中定义。即，P2MP LSP具有一个入口LSR和一个或多个出口LSR。入口LSR发送的流量由所有出口LSR接收。与P2MP LSP相关的特定方面是发生数据复制的分支LSR所需的操作。传入的标记数据被适当地复制到几个传出接口，这些接口可能使用不同的标签。
An LSR SHOULD NOT send more than one copy of a packet on any given link of a P2MP LSP. Exceptions to this are mentioned in Sections 4.9 and 4.18.
LSR不应在P2MP LSP的任何给定链路上发送多个数据包副本。例外情况见第4.9节和第4.18节。
A P2MP LSP MUST be identified by a constant and unique identifier within the whole LDP domain, whatever the number of leaves, which may vary dynamically. This identifier will be used so as to add/remove leaves to/from the P2MP tree.
P2MP LSP必须由整个LDP域内的一个常量和唯一标识符标识，无论叶子的数量是多少，这可能会动态变化。此标识符将用于在P2MP树中添加/删除叶子。
As with P2P MPLS technology [RFC5036], traffic MUST be classified into a Forwarding Equivalence Class (FEC) in this P2MP extension. All packets that belong to a particular P2MP FEC and that travel from a particular node MUST use the same P2MP LSP.
与P2P MPLS技术[RFC5036]一样，在该P2MP扩展中，流量必须分类为转发等价类（FEC）。属于特定P2MP FEC且从特定节点传输的所有数据包必须使用相同的P2MP LSP。
If existing FECs cannot be used for this purpose, a new LDP FEC that is suitable for P2MP forwarding MUST be specified.
如果现有FEC不能用于此目的，则必须指定适用于P2MP转发的新LDP FEC。
As with P2P and MP2P LDP LSPs, the P2MP LDP mechanism MUST support hop-by-hop LSP routing. P2MP LDP-based routing SHOULD rely upon the information maintained in LSR Routing Information Bases (RIBs).
与P2P和MP2P LDP LSP一样，P2MP LDP机制必须支持逐跳LSP路由。基于P2MP LDP的路由应依赖于LSR路由信息库（RIBs）中维护的信息。
It is RECOMMENDED that the P2MP LSP routing rely upon the unicast route to the Ingress LSR to build a reverse path tree.
建议P2MP LSP路由依赖到入口LSR的单播路由来构建反向路径树。
The P2MP LDP mechanism MUST support the establishment, maintenance, and teardown of P2MP LSPs in a scalable manner. This MUST include both the existence of a large number of P2MP LSPs within a single network and a large number of Leaf LSRs for a single P2MP LSP (see also Section 4.17 for scalability considerations and figures).
P2MP LDP机制必须以可扩展的方式支持P2MP LSP的建立、维护和拆卸。这必须包括单个网络中存在大量P2MP LSP，以及单个P2MP LSP中存在大量叶LSR（可扩展性注意事项和图请参见第4.17节）。
In order to scale well with a large number of leaves, it is RECOMMENDED to follow a leaf-initiated P2MP LSP setup approach. For that purpose, leaves will have to be aware of the P2MP LSP identifier. The ways a Leaf LSR discovers P2MP LSP identifiers rely on the applications that will use P2MP LSPs and are out of the scope of this document.
为了更好地适应大量叶片，建议采用叶片启动的P2MP LSP设置方法。为此，叶子必须知道P2MP LSP标识符。叶LSR发现P2MP LSP标识符的方式依赖于将使用P2MP LSP的应用程序，不在本文档的范围内。
The P2MP LDP mechanism MUST allow the dynamic addition and removal of leaves to and from a P2MP LSP, without any restriction (provided there is network connectivity). It is RECOMMENDED that these operations be leaf-initiated. These operations MUST NOT impact the data transfer (packet loss, duplication, delay) towards other leaves. It is RECOMMENDED that these operations do not cause any additional processing except on the path from the added/removed Leaf LSR to the Branch LSR.
P2MP LDP机制必须允许动态地向P2MP LSP添加和从P2MP LSP中移除叶子，而不受任何限制（前提是存在网络连接）。建议启动这些操作。这些操作不得影响向其他叶片的数据传输（数据包丢失、重复、延迟）。建议这些操作不会导致任何额外的处理，除了在从添加/删除的叶LSR到分支LSR的路径上。
The P2MP LDP mechanism MUST support downstream unsolicited label advertisement mode. This is well suited to a leaf-initiated approach and is consistent with P2P/MP2P LDP operations.
P2MP LDP机制必须支持下游未经请求的标签广告模式。这非常适合于叶子发起的方法，并且与P2P/MP2P LDP操作一致。
Other advertisement modes MAY also be supported.
还可以支持其他广告模式。
Data duplication refers to the receipt of multiple copies of a packet by any leaf. Although this may be a marginal situation, it may also be detrimental for certain applications. Hence, data duplication SHOULD be avoided as much as possible and limited to (hopefully rare) transitory conditions.
数据复制是指任何一个叶子接收一个数据包的多个副本。虽然这可能是一种边缘情况，但也可能对某些应用有害。因此，应尽可能避免数据重复，并将其限制在（希望很少的）暂时性条件下。
Note, in particular, that data duplication might occur if P2MP LSP rerouting is being performed (see also Section 4.8).
请特别注意，如果执行P2MP LSP重新路由，可能会发生数据重复（另请参见第4.8节）。
The P2MP LDP extension MUST have a mechanism to detect routing loops. This MAY rely on extensions to the LDP loop detection mechanism defined in [RFC5036]. A loop detection mechanism MAY require recording the set of LSRs traversed on the P2MP tree. The P2MP loop avoidance mechanism MUST NOT impact the scalability of the P2MP LDP solution.
P2MP LDP扩展必须具有检测路由循环的机制。这可能依赖于[RFC5036]中定义的LDP环路检测机制的扩展。循环检测机制可能需要记录在P2MP树上遍历的LSR集。P2MP环路避免机制不得影响P2MP LDP解决方案的可扩展性。
The P2MP LDP mechanism SHOULD have a mechanism to avoid routing loops in the data plane even during transient events.
P2MP LDP机制应具有一种即使在瞬态事件期间也能避免数据平面中的路由循环的机制。
Furthermore, the P2MP LDP mechanism MUST avoid routing loops in the data plane, which may trigger unexpected non-localized exponential growth of traffic.
此外，P2MP LDP机制必须避免数据平面中的路由循环，这可能会触发意外的非局部流量指数增长。
The P2MP LDP mechanism MUST support the rerouting of a P2MP LSP in the following cases:
在以下情况下，P2MP LDP机制必须支持P2MP LSP的重新路由：
o Network failure (link or node);
o 网络故障（链路或节点）；
o A better path exists (e.g., new link or metric change); and
o 存在更好的路径（例如，新链接或度量更改）；和
o Planned maintenance.
o 计划维护。
Given that P2MP LDP routing should rely on the RIB, the achievement of the following requirements relies on the underlying routing protocols (IGP, etc.).
鉴于P2MP LDP路由应依赖于RIB，以下要求的实现依赖于基础路由协议（IGP等）。
The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case of link or node failure(s) by relying upon update of the routes in the RIB. The rerouting time SHOULD be minimized as much as possible so as to reduce traffic disruption.
P2MP LDP机制必须允许在链路或节点故障的情况下，通过RIB中的路由更新，重新路由P2MP LSP。应尽可能减少改道时间，以减少交通中断。
A mechanism MUST be defined to prevent constant P2MP LSP teardown and rebuild, which may be caused by the instability of a specific link/ node in the network. This can rely on IGP dampening but may be completed by specific dampening at the LDP level.
必须定义一种机制，以防止因网络中特定链路/节点的不稳定性而导致的持续P2MP LSP拆卸和重建。这可以依赖于IGP阻尼，但可以通过LDP水平的特定阻尼来完成。
The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case a better path is created in the network, for instance, as a result of a metric change, a link repair, or the addition of links or nodes. This will rely on update of the routes in the RIB.
P2MP LDP机制必须允许P2MP LSP的重新路由，以防由于度量更改、链路修复或添加链路或节点而在网络中创建更好的路径。这将取决于加强筋中管线的更新。
The P2MP LDP mechanism MUST support planned maintenance operations. It MUST be possible to reroute a P2MP LSP before a link/node is deactivated for maintenance purposes. Traffic disruption and data duplication SHOULD be minimized as much as possible during such planned maintenance. P2MP LSP rerouting upon planned maintenance MAY rely on a make-before-break procedure.
P2MP LDP机制必须支持计划维护操作。在出于维护目的停用链路/节点之前，必须能够重新路由P2MP LSP。在此类计划维护期间，应尽可能减少交通中断和数据重复。计划维护时P2MP LSP重新路由可能依赖于先通后断程序。
The P2MP LDP mechanism SHOULD provide a way for a Branch LSR to send a single copy of the data onto an interface to a multi-access network (e.g., an Ethernet LAN) and reach multiple adjacent downstream nodes. This requires that the same label be negotiated with all downstream LSRs for the LSP.
P2MP LDP机制应为分支LSR提供一种方式，将数据的单个副本发送到多接入网络（例如，以太网LAN）的接口上，并到达多个相邻的下游节点。这要求与LSP的所有下游LSR协商相同的标签。
When there are several candidate upstream LSRs on an interface to a multi-access LAN, the P2MP LDP mechanism SHOULD provide a way for all downstream LSRs of a given P2MP LSP to select the same upstream LSR, so as to avoid traffic replication. In addition, the P2MP LDP mechanism SHOULD allow for an efficient balancing of a set of P2MP LSPs among a set of candidate upstream LSRs on a LAN interface.
当多址LAN接口上存在多个候选上游LSR时，P2MP LDP机制应为给定P2MP LSP的所有下游LSR提供一种选择相同上游LSR的方式，以避免流量复制。此外，P2MP LDP机制应允许在LAN接口上的一组候选上游LSR之间有效平衡一组P2MP LSP。
The P2MP LDP mechanism MUST support nesting P2MP LSPs into P2P and P2MP TE tunnels.
P2MP LDP机制必须支持将P2MP LSP嵌套到P2P和P2MP TE隧道中。
The P2MP LDP mechanism MUST provide a way for a Branch LSR of a P2MP LSP, which is also a Head End LSR of a P2MP TE tunnel, to send a single copy of the data onto the tunnel and reach all downstream LSRs on the P2MP LSP, which are also Egress LSRs of the tunnel. As with LAN interfaces, this requires that the same label be negotiated with all downstream LSRs of the P2MP LDP LSP.
P2MP LDP机制必须为P2MP LSP的分支LSR（也是P2MP TE隧道的前端LSR）提供一种方式，以将数据的单个副本发送到隧道并到达P2MP LSP上的所有下游LSR，这些LSR也是隧道的出口LSR。与LAN接口一样，这要求与P2MP LDP LSP的所有下游LSR协商相同的标签。
Labels for P2MP LSPs and P2P/MP2P LSPs MAY be assigned from shared or dedicated label spaces.
P2MP LSP和P2P/MP2P LSP的标签可以从共享或专用标签空间分配。
Note that dedicated label spaces will require the establishment of separate P2P and P2MP LDP sessions.
请注意，专用标签空间将需要建立单独的P2P和P2MP LDP会话。
The P2MP LDP mechanism MUST support the establishment of LDP sessions over both IPv4 and IPv6 control planes.
P2MP LDP机制必须支持在IPv4和IPv6控制平面上建立LDP会话。
The P2MP LDP mechanism MUST support the establishment of multi-area P2MP LSPs, i.e., LSPs whose leaves do not all reside in the same IGP area as the Ingress LSR. This SHOULD be possible without requiring the advertisement of Ingress LSRs' addresses across IGP areas.
P2MP LDP机制必须支持多区域P2MP LSP的建立，即，其叶不全部位于与入口LSR相同的IGP区域的LSP。这应该是可能的，无需在IGP区域内公布入口LSR的地址。
The P2MP LDP mechanism MUST also support the establishment of inter-AS P2MP LSPs, i.e., LSPs whose leaves do not all reside in the same AS as the Ingress LSR. This SHOULD be possible without requiring the advertisement of Ingress LSRs' addresses across ASes.
P2MP-LDP机制还必须支持建立作为P2MP-lsp的内部lsp，即，其叶不全部驻留在与入口LSR相同的位置的lsp。这应该是可能的，无需在ASE中公布入口LSR的地址。
LDP management tools ([RFC3815], etc.) will have to be enhanced to support P2MP LDP extensions. This may yield a new MIB module, which may possibly be inherited from the LDP MIB.
必须增强LDP管理工具（[RFC3815]等），以支持P2MP LDP扩展。这可能产生一个新的MIB模块，该模块可能从LDP MIB继承。
Built-in diagnostic tools MUST be defined to check the connectivity, trace the path, and ensure fast detection of data plane failures on P2MP LDP LSPs.
必须定义内置诊断工具，以检查连接性、跟踪路径，并确保快速检测P2MP LDP LSP上的数据平面故障。
Further and precise requirements and mechanisms for P2MP MPLS Operations, Administration, and Maintenance (OAM) purposes are out of the scope of this document and are addressed in [RFC4687].
用于P2MP MPLS操作、管理和维护（OAM）目的的进一步精确要求和机制不在本文件范围内，请参见[RFC4687]。
LDP Graceful Restart mechanisms [RFC3478] and Fault Recovery mechanisms [RFC3479] SHOULD be enhanced to support P2MP LDP LSPs.
应增强LDP优雅重启机制[RFC3478]和故障恢复机制[RFC3479]，以支持P2MP LDP LSP。
A solution MUST be designed to re-establish connectivity for P2MP and MP2MP LSPs in the event of failures, provided there exists network connectivity between ingress and egress nodes (i.e., designed without introducing single points of failure).
如果入口和出口节点之间存在网络连接（即设计时不引入单点故障），则必须设计解决方案，以便在发生故障时重新建立P2MP和MP2MP LSP的连接。
Scalability is a key requirement for the P2MP LDP mechanism. It MUST be designed to scale well with an increase in the number of any of the following:
可伸缩性是P2MP LDP机制的关键要求。其设计必须能够随着以下任何一项数量的增加而良好扩展：
o Number of Leaf LSRs per P2MP LSP;
o 每个P2MP LSP的叶LSR数量；
o Number of downstream LSRs per Branch LSR; and
o 每个分支LSR的下游LSR数量；和
o Number of P2MP LSPs per LSR.
o 每个LSR的P2MP LSP数。
In order to scale well with an increase in the number of leaves, it is RECOMMENDED that the size of a P2MP LSP state on an LSR, for one particular LSP, depend only on the number of adjacent LSRs on the LSP.
为了更好地随叶片数量的增加而扩展，建议对于一个特定LSP，LSR上P2MP LSP状态的大小仅取决于LSP上相邻LSR的数量。
Typical orders of magnitude that we expect should be supported are:
我们期望得到支持的典型数量级包括：
o Tens of thousands of P2MP trees spread out across core network routers; and
o 成千上万的P2MP树分布在核心网络路由器上；和
o Hundreds, or a few thousands, of leaves per tree.
o 每棵树有数百片或数千片叶子。
See also Section 4.2 of [RFC4834].
另见[RFC4834]第4.2节。
In order to allow for a smooth migration, the P2MP LDP mechanism SHOULD offer as much backward compatibility as possible. In particular, the solution SHOULD allow the setup of a P2MP LSP along non-Branch Transit LSRs that do not support P2MP LDP extensions.
为了实现平滑迁移，P2MP LDP机制应该提供尽可能多的向后兼容性。特别是，该解决方案应允许沿不支持P2MP LDP扩展的非分支传输LSR设置P2MP LSP。
Also, the P2MP LDP solution MUST coexist with current LDP mechanisms and inherit its capability sets from [RFC5036]. The P2MP LDP solution MUST NOT impede the operation of P2P/MP2P LSPs. A P2MP LDP solution MUST be designed in such a way that it allows P2P/MP2P and P2MP LSPs to be signaled on the same interface.
此外，P2MP LDP解决方案必须与当前LDP机制共存，并从[RFC5036]继承其功能集。P2MP LDP解决方案不得妨碍P2P/MP2P LSP的运行。P2MP LDP解决方案的设计必须确保其允许在同一接口上发送P2P/MP2P和P2MP LSP信号。
For traffic delivery between a group of N LSRs that act as egress and/or egress nodes on different P2MP flows, it may be useful to set up a shared tree connecting all these LSRs instead of having N P2MP LSPs. This would reduce the amount of control and forwarding state that has to be maintained on a given LSR.
对于充当不同P2MP流上的出口和/或出口节点的N个lsr组之间的流量交付，建立连接所有这些lsr的共享树而不是具有N个P2MP lsp可能是有用的。这将减少必须在给定LSR上维护的控制和转发状态的数量。
There are two main options for supporting such shared trees:
支持此类共享树有两个主要选项：
o Relying on the applications' protocols that use LDP LSPs. A shared tree could consist of the combination of an MP2P LDP LSP from Leaf LSRs to a given root node with a P2MP LSP from this root to Leaf LSRs. For instance, with Multicast L3 VPN applications, it would be possible to build a shared tree by combining (see [MVPN]):
o 依赖于使用LDP LSP的应用程序协议。共享树可以包括从叶LSR到给定根节点的MP2P LDP LSP与从该根到叶LSR的P2MP LSP的组合。例如，对于多播L3 VPN应用程序，可以通过组合来构建共享树（请参见[MVPN]）：
* An MP2P unicast LDP LSP, from each PE router of the group to a particular root PE router acting as tree root and
* MP2P单播LDP LSP，从组中的每个PE路由器到充当树根的特定根PE路由器，并
* A P2MP LDP LSP from this root PE router to each PE router of the group.
* 从根PE路由器到组中每个PE路由器的P2MP LDP LSP。
o Relying on a specific LDP mechanism allowing the setup of multipoint-to-multipoint MPLS LSPs (MP2MP LSPs).
o 依靠特定的LDP机制，允许设置多点到多点MPLS LSP（MP2MP LSP）。
The former approach (combination of MP2P and P2MP LSPs at the application level) is out of the scope of this document while the latter (MP2MP LSPs) is within the scope of this document. Requirements for the setup of MP2MP LSPs are listed below.
前一种方法（应用级MP2P和P2MP LSP的组合）不在本文件范围内，而后一种方法（MP2MP LSP）则在本文件范围内。MP2MP LSP的设置要求如下所示。
A multipoint-to-multipoint (MP2MP) LSP is an LSP connecting a group of Leaf LSRs acting as Egress and/or Ingress LSRs. Traffic sent by any Leaf LSR is received by all other Leaf LSRs of the group.
多点对多点（MP2MP）LSP是连接一组作为出口和/或入口LSR的叶LSR的LSP。任何叶LSR发送的流量由组的所有其他叶LSR接收。
Procedures for setting up MP2MP LSPs with LDP SHOULD be specified. An implementation that supports P2MP LDP LSPs MAY also support MP2MP LDP LSPs.
应规定使用LDP设置MP2MP LSP的程序。支持P2MP LDP LSP的实现也可以支持MP2MP LDP LSP。
The MP2MP LDP procedures MUST NOT impede the operations of P2MP LSP.
MP2MP LDP程序不得妨碍P2MP LSP的运行。
Requirements for P2MP LSPs, set forth in Section 4, apply equally to MP2MP LSPs. Particular attention should be given to the requirements below:
第4节中规定的P2MP LSP要求同样适用于MP2MP LSP。应特别注意以下要求：
o The solution MUST support recovery upon link and transit node failure and be designed to re-establish connectivity for MP2MP LSPs in the event of failures, provided network connectivity exists between ingress and egress nodes (i.e., designed without introducing single points of failure).
o 该解决方案必须支持链路和传输节点故障时的恢复，并设计为在发生故障时为MP2MP LSP重新建立连接，前提是入口和出口节点之间存在网络连接（即设计时不引入单点故障）。
o The size of MP2MP state on an LSR, for one particular MP2MP LSP, SHOULD only depend on the number of adjacent LSRs on the LSP.
o 对于一个特定的MP2MP LSP，LSR上MP2MP状态的大小应仅取决于LSP上相邻LSR的数量。
o Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that may trigger exponential growth of traffic. Note that this requirement is more challenging with MP2MP LSPs as an LSR may need to receive traffic for a given LSP on multiple interfaces.
o 此外，MP2MP LDP机制必须避免可能触发流量指数增长的路由循环。请注意，对于MP2MP LSP，此要求更具挑战性，因为LSR可能需要在多个接口上接收给定LSP的流量。
There are additional requirements specific to MP2MP LSPs:
MP2MP LSP有特定的附加要求：
o It is RECOMMENDED that an MP2MP MPLS LSP is built based on the unicast route to a specific LSR called root LSR.
o 建议基于到称为根LSR的特定LSR的单播路由构建MP2MP MPLS LSP。
o It is RECOMMENDED to define several root LSRs (e.g., a primary and a backup) to ensure redundancy upon root LSR failure.
o 建议定义几个根LSR（例如，一个主LSR和一个备份LSR），以确保根LSR故障时的冗余。
o The receiver SHOULD NOT receive back a packet it has sent on the MP2MP LSP.
o 接收器不应接收回它在MP2MP LSP上发送的数据包。
o The solution SHOULD avoid that all traffic between any pair of leaves is traversing a root LSR (similarly to PIM-Bidir trees) and SHOULD provide the operator with means to minimize the delay between two leaves.
o 该解决方案应避免任何一对叶子之间的所有通信量都通过根LSR（类似于PIM Bidir树），并应为操作员提供最小化两片叶子之间延迟的方法。
o It MUST be possible to check connectivity of an MP2MP LSP in both directions.
o 必须能够在两个方向上检查MP2MP LSP的连接。
The solution will be evaluated with respect to the following criteria:
将根据以下标准对解决方案进行评估：
(1) Efficiency of network resource usage;
(1) 网络资源使用效率；
(2) Time to add or remove a Leaf LSR;
(2) 添加或删除叶LSR的时间；
(3) Time to repair a P2MP LSP in case of link or node failure; and
(3) 链路或节点故障时修复P2MP LSP的时间；和
(4) Scalability (state size, number of messages, message size).
(4) 可伸缩性（状态大小、消息数量、消息大小）。
Particularly, the P2MP LDP mechanism SHOULD be designed with the key objective of minimizing the additional amount of state and additional processing required in the network.
特别是，P2MP LDP机制的设计应以最小化网络中所需的额外状态量和额外处理为主要目标。
Also, the P2MP LDP mechanism SHOULD be designed so that convergence times in case of link or node failure are minimized, in order to limit traffic disruption.
此外，P2MP LDP机制的设计应使链路或节点故障时的收敛时间最小化，以限制流量中断。
The proposed solution SHOULD NOT introduce complexity to the current LDP operations to such a degree that it would affect the stability and diminish the benefits of deploying such solution.
提议的解决方案不应将当前LDP操作的复杂性引入到会影响稳定性并降低部署此类解决方案的好处的程度。
It is expected that addressing the requirements defined in this document should not introduce any new security issues beyond those inherent to LDP and that a P2MP LDP solution will rely on the security mechanisms defined in [RFC5036] (e.g., TCP MD5 Signature).
除LDP固有的安全问题外，解决本文件中定义的要求不应引入任何新的安全问题，P2MP LDP解决方案将依赖于[RFC5036]中定义的安全机制（例如TCP MD5签名）。
An evaluation of the security features for MPLS networks may be found in [RFC5920], and where issues or further work is identified by that document, new security features or procedures for the MPLS protocols will need to be developed.
可在[RFC5920]中找到对MPLS网络安全特性的评估，如果该文件确定了问题或进一步工作，则需要为MPLS协议开发新的安全特性或程序。
We would like to thank Christian Jacquenet, Hitoshi Fukuda, Ina Minei, Dean Cheng, and Benjamin Niven-Jenkins for their highly useful comments and suggestions. We would like to thank Adrian Farrel for reviewing this document before publication.
我们要感谢Christian Jacquenet、Hitoshi Fukuda、Ina Minei、Cheng院长和Benjamin Niven Jenkins提出的非常有用的意见和建议。我们要感谢Adrian Farrel在本文件出版前对其进行了审阅。
We would also like to thank the authors of [RFC4461], which inspired some of the text in this document.
我们还要感谢[RFC4461]的作者，他们启发了本文件中的一些文本。
[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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, February 2003.
[RFC3478]Leelanivas，M.，Rekhter，Y.，和R.Aggarwal，“标签分发协议的优雅重启机制”，RFC 3478，2003年2月。
[RFC3479] Farrel, A., "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003.
[RFC3479]Farrel，A.，“标签分发协议（LDP）的容错”，RFC 3479，2003年2月。
[RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004.
[RFC3815]Cucchiara，J.，Sjostrand，H.，和J.Luciani，“多协议标签交换（MPLS）管理对象的定义，标签分发协议（LDP）”，RFC 3815，2004年6月。
[RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[RFC4461]Yasukawa，S.，“点对多点流量工程MPLS标签交换路径（LSP）的信令要求”，RFC 4461，2006年4月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Minei，I.，和B.Thomas，“LDP规范”，RFC 5036，2007年10月。
[MLDP] Minei, I., Wijnands, I., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Work in Progress, August 2011.
[MLDP]Minei，I.，Wijnands，I.，Kompella，K.，和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，正在进行的工作，2011年8月。
[MVPN] Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in MPLS/BGP IP VPNs", Work in Progress, January 2010.
[MVPN]Aggarwal，R.，Bandi，S.，Cai，Y.，Morin，T.，Rekhter，Y.，Rosen，E.，Wijnands，I.，和S.Yasukawa，“MPLS/BGP IP VPN中的多播”，正在进行中的工作，2010年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026]Andersson，L.和T.Madsen，“提供商提供的虚拟专用网络（VPN）术语”，RFC 4026，2005年3月。
[RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, "Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks", RFC 4687, September 2006.
[RFC4687]Yasukawa，S.，Farrel，A.，King，D.，和T.Nadeau，“点对多点MPLS网络的运营和管理（OAM）要求”，RFC 4687，2006年9月。
[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月。
[RFC5501] Kamite, Y., Wada, Y., Serbest, Y., Morin, T., and L. Fang, "Requirements for Multicast Support in Virtual Private LAN Services", RFC 5501, March 2009.
[RFC5501]Kamite，Y.，Wada，Y.，Serbest，Y.，Morin，T.，和L.Fang，“虚拟专用LAN服务中多播支持的要求”，RFC 5501，2009年3月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[VPLS-MCAST] Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter, "Multicast in VPLS", Work in Progress, July 2011.
[VPLS-MCAST]Aggarwal，R.，Kamite，Y.，Fang，L.，和Y.Rekhter，“VPLS中的多播”，正在进行的工作，2011年7月。
Contributing Authors
撰稿人
Vincent Parfait France Telecom - Orange, Orange Business Services
Vincent Parfait法国电信-橙色，橙色业务服务
EMail: vincent.parfait@orange-ftgroup.com
EMail: vincent.parfait@orange-ftgroup.com
Luyuan Fang Cisco Systems, Inc.
陆源方思科系统有限公司。
EMail: lufang@cisco.com
EMail: lufang@cisco.com
Lei Wang Telenor
雷王电信
EMail: lei.wang@telenor.com
EMail: lei.wang@telenor.com
Yuji Kamite NTT Communications Corporation
Yuji Kamite NTT通信公司
EMail: y.kamite@ntt.com
EMail: y.kamite@ntt.com
Shane Amante Level 3 Communications, LLC
Shane Amante三级通信有限责任公司
EMail: shane@level3.net
EMail: shane@level3.net
Authors' Addresses
作者地址
Jean-Louis Le Roux (editor) France Telecom - Orange
Jean-Louis Le Roux（编辑）法国电信-橙色
EMail: jeanlouis.leroux@orange-ftgroup.com
EMail: jeanlouis.leroux@orange-ftgroup.com
Thomas Morin (editor) France Telecom - Orange
托马斯·莫林（编辑）法国电信-橙色
EMail: thomas.morin@orange-ftgroup.com
EMail: thomas.morin@orange-ftgroup.com