Network Working Group S. Yasukawa, Ed.
Request for Comments: 4461 NTT
Category: Informational April 2006
Network Working Group S. Yasukawa, Ed.
Request for Comments: 4461 NTT
Category: Informational April 2006
Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)
点对多点流量工程MPLS标签交换路径（LSP）的信令要求
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic-Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs).
本文件提出了一套建立和维护点对多点（P2MP）流量工程（TE）多协议标签交换（MPLS）标签交换路径（LSP）的要求。
There is no intent to specify solution-specific details or application-specific requirements in this document.
本文档无意指定特定于解决方案的详细信息或特定于应用程序的要求。
The requirements presented in this document not only apply to packet-switched networks under the control of MPLS protocols, but also encompass the requirements of Layer Two Switching (L2SC), Time Division Multiplexing (TDM), lambda, and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS.
本文件中提出的要求不仅适用于MPLS协议控制下的分组交换网络，还包括由通用MPLS（GMPLS）协议管理的第二层交换（L2SC）、时分复用（TDM）、lambda和端口交换网络的要求。为满足本文件规定的要求而开发的协议解决方案必须尝试同样适用于MPLS和GMPLS。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Non-Objectives .............................................6
2. Definitions .....................................................6
2.1. Acronyms ...................................................6
2.2. Terminology ................................................6
2.2.1. Terminology for Partial LSPs ........................8
2.3. Conventions ................................................9
3. Problem Statement ...............................................9
3.1. Motivation .................................................9
3.2. Requirements Overview ......................................9
4. Detailed Requirements for P2MP TE Extensions ...................11
4.1. P2MP LSP ..................................................11
4.2. P2MP Explicit Routing .....................................12
4.3. Explicit Path Loose Hops and Widely Scoped
Abstract Nodes ............................................13
4.4. P2MP TE LSP Establishment, Teardown, and
Modification Mechanisms ...................................14
4.5. Fragmentation .............................................14
4.6. Failure Reporting and Error Recovery ......................15
4.7. Record Route of P2MP TE LSP ...............................16
4.8. Call Admission Control (CAC) and QoS Control
Mechanism of P2MP TE LSPs .................................17
4.9. Variation of LSP Parameters ...............................17
4.10. Re-Optimization of P2MP TE LSPs ..........................18
4.11. Merging of Tree Branches .................................18
4.12. Data Duplication .........................................19
4.13. IPv4/IPv6 Support ........................................20
4.14. P2MP MPLS Label ..........................................20
4.15. Advertisement of P2MP Capability .........................20
4.16. Multi-Access LANs ........................................21
4.17. P2MP MPLS OAM ............................................21
4.18. Scalability ..............................................21
4.18.1. Absolute Limits ..................................22
4.19. Backwards Compatibility ..................................24
4.20. GMPLS ....................................................24
4.21. P2MP Crankback Routing ...................................25
5. Security Considerations ........................................25
6. Acknowledgements ...............................................26
7. References .....................................................26
7.1. Normative References ......................................26
7.2. Informative References ....................................26
1. Introduction ....................................................3
1.1. Non-Objectives .............................................6
2. Definitions .....................................................6
2.1. Acronyms ...................................................6
2.2. Terminology ................................................6
2.2.1. Terminology for Partial LSPs ........................8
2.3. Conventions ................................................9
3. Problem Statement ...............................................9
3.1. Motivation .................................................9
3.2. Requirements Overview ......................................9
4. Detailed Requirements for P2MP TE Extensions ...................11
4.1. P2MP LSP ..................................................11
4.2. P2MP Explicit Routing .....................................12
4.3. Explicit Path Loose Hops and Widely Scoped
Abstract Nodes ............................................13
4.4. P2MP TE LSP Establishment, Teardown, and
Modification Mechanisms ...................................14
4.5. Fragmentation .............................................14
4.6. Failure Reporting and Error Recovery ......................15
4.7. Record Route of P2MP TE LSP ...............................16
4.8. Call Admission Control (CAC) and QoS Control
Mechanism of P2MP TE LSPs .................................17
4.9. Variation of LSP Parameters ...............................17
4.10. Re-Optimization of P2MP TE LSPs ..........................18
4.11. Merging of Tree Branches .................................18
4.12. Data Duplication .........................................19
4.13. IPv4/IPv6 Support ........................................20
4.14. P2MP MPLS Label ..........................................20
4.15. Advertisement of P2MP Capability .........................20
4.16. Multi-Access LANs ........................................21
4.17. P2MP MPLS OAM ............................................21
4.18. Scalability ..............................................21
4.18.1. Absolute Limits ..................................22
4.19. Backwards Compatibility ..................................24
4.20. GMPLS ....................................................24
4.21. P2MP Crankback Routing ...................................25
5. Security Considerations ........................................25
6. Acknowledgements ...............................................26
7. References .....................................................26
7.1. Normative References ......................................26
7.2. Informative References ....................................26
Existing MPLS traffic engineering (MPLS-TE) allows for strict QoS guarantees, resource optimization, and fast failure recovery, but it is limited to point-to-point (P2P) LSPs. There is a desire to support point-to-multipoint (P2MP) services using traffic-engineered LSPs, and this clearly motivates enhancements of the base MPLS-TE tool box in order to support P2MP MPLS-TE LSPs.
现有的MPLS流量工程（MPLS-TE）允许严格的QoS保证、资源优化和快速故障恢复，但仅限于点对点（P2P）LSP。人们希望使用流量工程LSP支持点对多点（P2MP）服务，这显然推动了基本MPLS-TE工具箱的增强，以支持P2MP MPLS-TE LSP。
A P2MP TE LSP is a TE LSP (per [RFC2702] and [RFC3031]) that has a single ingress LSR and one or more egress LSRs, and is unidirectional. P2MP services (that deliver data from a single source to one or more receivers) may be supported by any combination of P2P and P2MP LSPs depending on the degree of optimization required within the network, and such LSPs may be traffic-engineered again depending on the requirements of the network. Further, multipoint-to-multipoint (MP2MP) services (which deliver data from more than one source to one or more receivers) may be supported by a combination of P2P and P2MP LSPs.
P2MP TE LSP是一种TE LSP（根据[RFC2702]和[RFC3031]），它具有一个入口LSR和一个或多个出口LSR，并且是单向的。P2MP服务（将数据从单个源传送到一个或多个接收器）可由P2P和P2MP lsp的任何组合支持，这取决于网络内所需的优化程度，并且可根据网络的要求再次对此类lsp进行流量工程。此外，多点对多点（MP2MP）服务（将数据从多个源传送到一个或多个接收器）可由P2P和P2MP lsp的组合支持。
[RFC2702] specifies requirements for traffic engineering over MPLS. In Section 2, it describes traffic engineering in some detail, and those definitions are equally applicable to traffic engineering in a point-to-multipoint service environment. They are not repeated here, but it is assumed that the reader is fully familiar with them.
[RFC2702]规定了MPLS上流量工程的要求。在第2节中，它详细描述了流量工程，这些定义同样适用于点对多点服务环境中的流量工程。此处不再重复，但假定读者完全熟悉它们。
Section 3.0 of [RFC2702] also explains how MPLS is particularly suited to traffic engineering; it presents the following eight reasons.
[RFC2702]第3.0节还解释了MPLS如何特别适合于流量工程；它提出了以下八个理由。
1. Explicit label switched paths that are not constrained by the destination-based forwarding paradigm can be easily created through manual administrative action or through automated action by the underlying protocols. 2. LSPs can potentially be maintained efficiently. 3. Traffic trunks can be instantiated and mapped onto LSPs. 4. A set of attributes can be associated with traffic trunks that modulate their behavioral characteristics. 5. A set of attributes can be associated with resources that constrain the placement of LSPs and traffic trunks across them. 6. MPLS allows for both traffic aggregation and disaggregation, whereas classical destination-only-based IP forwarding permits only aggregation. 7. It is relatively easy to integrate a "constraint-based routing" framework with MPLS. 8. A good implementation of MPLS can offer significantly lower overhead than competing alternatives for traffic engineering.
1. 不受基于目的地的转发范例约束的显式标签交换路径可以通过手动管理操作或底层协议的自动操作轻松创建。2.LSP可能会得到有效维护。3.交通干线可以实例化并映射到LSP。4.一组属性可以与调整其行为特征的交通干线相关联。5.一组属性可以与资源相关联，这些资源约束LSP的位置和它们之间的交通干线。6.MPLS允许流量聚合和分解，而传统的基于目的地的IP转发只允许聚合。7.将“基于约束的路由”框架与MPLS集成起来相对容易。8.MPLS的良好实现可以提供比流量工程竞争对手更低的开销。
These points are equally applicable to point-to-multipoint traffic engineering. Points 1 and 7 are particularly important. Note that point 3 implies that the concept of a point-to-multipoint traffic trunk is defined and is supported by (or mapped onto) P2MP LSPs.
这些点同样适用于点对多点流量工程。第1点和第7点特别重要。请注意，第3点意味着定义了点对多点流量中继的概念，并由P2MP LSP支持（或映射到P2MP LSP上）。
That is, the traffic flow for a point-to-multipoint LSP is not constrained to the path or paths that it would follow during multicast routing or shortest path destination-based routing, but it can be explicitly controlled through manual or automated action.
也就是说，点对多点LSP的业务流不受多播路由或基于目的地的最短路径路由期间它将遵循的一条或多条路径的约束，但它可以通过手动或自动操作进行显式控制。
Further, the explicit paths that are used may be computed using algorithms based on a variety of constraints to produce all manner of tree shapes. For example, an explicit path may be cost-based [STEINER], shortest path, or QoS-based, or it may use some fair-cost QoS algorithm.
此外，可以使用基于各种约束的算法来计算所使用的显式路径，以生成各种树形状。例如，显式路径可以是基于成本的[STEINER]、最短路径或基于QoS的，或者它可以使用一些公平成本的QoS算法。
[RFC2702] also describes the functional capabilities required to fully support traffic engineering over MPLS in large networks.
[RFC2702]还描述了在大型网络中完全支持MPLS流量工程所需的功能能力。
This document presents a set of requirements for Point-to-Multipoint (P2MP) traffic engineering (TE) extensions to Multiprotocol Label Switching (MPLS). It specifies functional requirements for solutions to deliver P2MP TE LSPs.
本文档介绍了多协议标签交换（MPLS）的点对多点（P2MP）流量工程（TE）扩展的一组要求。它规定了交付P2MP TE LSP的解决方案的功能要求。
Solutions that specify procedures for P2MP TE LSP setup MUST satisfy these requirements. There is no intent to specify solution-specific details or application-specific requirements in this document.
指定P2MP TE LSP设置程序的解决方案必须满足这些要求。本文档无意指定特定于解决方案的详细信息或特定于应用程序的要求。
The requirements presented in this document apply equally to packet-switched networks under the control of MPLS protocols and to packet-switched, TDM, lambda, and port-switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document MUST attempt to be equally applicable to MPLS and GMPLS.
本文件中提出的要求同样适用于MPLS协议控制下的分组交换网络以及由通用MPLS（GMPLS）协议管理的分组交换、TDM、lambda和端口交换网络。为满足本文件规定的要求而开发的协议解决方案必须尝试同样适用于MPLS和GMPLS。
Existing MPLS TE mechanisms such as [RFC3209] do not support P2MP TE LSPs, so new mechanisms need to be developed. This SHOULD be achieved with maximum re-use of existing MPLS protocols.
现有的MPLS TE机制（如[RFC3209]）不支持P2MP TE LSP，因此需要开发新的机制。这应该通过最大限度地重用现有MPLS协议来实现。
Note that there is a separation between routing and signaling in MPLS TE. In particular, the path of the MPLS TE LSP is determined by performing a constraint-based computation (such as CSPF) on a traffic engineering database (TED). The contents of the TED may be collected through a variety of mechanisms.
注意，在MPLS-TE中，路由和信令是分离的。具体地，MPLS TE LSP的路径是通过在流量工程数据库（TED）上执行基于约束的计算（例如CSPF）来确定的。TED的内容可以通过多种机制收集。
This document focuses on requirements for establishing and maintaining P2MP MPLS TE LSPs through signaling protocols; routing protocols are out of scope. No assumptions are made about how the TED used as the basis for path computations for P2MP LSPs is formed.
本文件重点介绍通过信令协议建立和维护P2MP MPLS TE LSP的要求；路由协议超出范围。对于如何形成TED作为P2MP LSP路径计算的基础，未作任何假设。
This requirements document assumes the following conditions for P2MP MPLS TE LSP establishment and maintenance:
本要求文件假设P2MP MPLS TE LSP建立和维护的条件如下：
o A P2MP TE LSP will be set up with TE constraints and will allow efficient packet or data replication at various branching points in the network. Although replication is a data plane issue, it is the responsibility of the control plane (acting in conjunction with the path computation component) to install LSPs in the network such that replication can be performed efficiently. Note that the notion of "efficient" replication is relative and may have different meanings depending on the objectives (see Section 4.2).
o P2MP TE LSP将使用TE约束进行设置，并允许在网络中的各个分支点进行有效的数据包或数据复制。尽管复制是一个数据平面问题，但控制平面（与路径计算组件一起工作）有责任在网络中安装LSP，以便能够有效地执行复制。请注意，“高效”复制的概念是相对的，根据不同的目标可能有不同的含义（参见第4.2节）。
o P2MP TE LSP setup mechanisms must include the ability to add/remove receivers to/from the P2MP service supported by an existing P2MP TE LSP.
o P2MP TE LSP设置机制必须包括在现有P2MP TE LSP支持的P2MP服务中添加/删除接收器的功能。
o Tunnel endpoints of P2MP TE LSP will be modified by adding/removing egress LSRs to/from an existing P2MP TE LSP. It is assumed that the rate of change of leaves of a P2MP LSP (that is, the rate at which new egress LSRs join, or old egress LSRs are pruned) is "not so high" because P2MP TE LSPs are assumed to be utilized for TE applications. This issue is discussed at greater length in Section 4.18.1.
o P2MP TE LSP的隧道端点将通过在现有P2MP TE LSP中添加/删除出口LSR进行修改。对于LSP的“连接”或“退出”应用程序，假定其以较高的速率被剪除，因此对于LSP的“退出”应用程序，假定其以较高的速率被剪除。第4.18.1节对此问题进行了详细讨论。
o A P2MP TE LSP may be protected by fast error recovery mechanisms to minimize disconnection of a P2MP service.
o P2MP TE LSP可通过快速错误恢复机制进行保护，以最小化P2MP服务的断开。
o A set of attributes of the P2MP TE LSP (e.g., bandwidth, etc.) may be modified by some mechanism (e.g., make-before-break, etc.) to accommodate attribute changes to the P2MP service without impacting data traffic. These issues are discussed in Sections 4.6 and 4.10.
o P2MP TE LSP的一组属性（例如，带宽等）可以通过某种机制（例如，先通后断等）进行修改，以适应P2MP服务的属性更改而不影响数据流量。第4.6节和第4.10节讨论了这些问题。
It is not a requirement that the ingress LSR must control the addition or removal of leaves from the P2MP tree.
不要求入口LSR必须控制P2MP树叶片的添加或移除。
It is this document's objective that a solution compliant to the requirements set out in this document MUST operate these P2MP TE capabilities in a scalable fashion.
本文件的目标是，符合本文件规定要求的解决方案必须以可扩展的方式运行这些P2MP TE功能。
For clarity, this section lists some items that are out of scope of this document.
为清楚起见，本节列出了一些超出本文件范围的项目。
It is assumed that some information elements describing the P2MP TE LSP are known to the ingress LSR prior to LSP establishment. For example, the ingress LSRs know the IP addresses that identify the egress LSRs of the P2MP TE LSP. The mechanisms by which the ingress LSR obtains this information is outside the scope of P2MP TE signaling and so is not included in this document. Other documents may complete the description of this function by providing automated, protocol-based ways of passing this information to the ingress LSR.
假设在LSP建立之前，入口LSR已知描述P2MP TE LSP的一些信息元素。例如，入口lsr知道标识P2MP TE LSP的出口lsr的IP地址。入口LSR获取此信息的机制不在P2MP TE信令的范围内，因此不包括在本文档中。其他文档可以通过提供自动的、基于协议的方式将此信息传递给入口LSR来完成此功能的描述。
This document does not specify any requirements for the following functions.
本文件未规定以下功能的任何要求。
- Non-TE LSPs (such as per-hop, routing-based LSPs). - Discovery of egress leaves for a P2MP LSP. - Hierarchical P2MP LSPs. - OAM for P2MP LSPs. - Inter-area and inter-AS P2MP TE LSPs. - Applicability of P2MP MPLS TE LSPs to service scenarios. - Specific application or application requirements. - Algorithms for computing P2MP distribution trees. - Multipoint-to-point LSPs. - Multipoint-to-multipoint LSPs. - Routing protocols. - Construction of the traffic engineering database. - Distribution of the information used to construct the traffic engineering database.
- 非TE LSP（例如每跳、基于路由的LSP）。-发现P2MP LSP的出口叶片。-分级P2MP LSP。-P2MP LSP的OAM。-区域间和区域间AS P2MP TE LSP。-P2MP MPLS TE LSP对服务场景的适用性。-具体应用或应用要求。-计算P2MP分布树的算法。-多点对点LSP。-多点对多点LSP。-路由协议交通工程数据库的建设用于构建交通工程数据库的信息分布。
P2P: Point-to-point
P2P：点对点
P2MP: Point-to-multipoint
P2MP：点对多点
The reader is assumed to be familiar with the terminology in [RFC3031] and [RFC3209].
假定读者熟悉[RFC3031]和[RFC3209]中的术语。
The following terms are defined for use in the context of P2MP TE LSPs only.
以下术语的定义仅适用于P2MP TE LSP。
P2MP tree:
P2MP树：
The ordered set of LSRs and TE links that comprise the path of a P2MP TE LSP from its ingress LSR to all of its egress LSRs.
LSR和TE链路的有序集合，构成P2MP TE LSP从其入口LSR到其所有出口LSR的路径。
ingress LSR:
入口LSR：
The LSR that is responsible for initiating the signaling messages that set up the P2MP TE LSP.
负责启动设置P2MP TE LSP的信令消息的LSR。
egress LSR:
出口LSR：
One of potentially many destinations of the P2MP TE LSP. Egress LSRs may also be referred to as leaf nodes or leaves.
P2MP TE LSP的潜在多个目的地之一。出口lsr也可被称为叶节点或叶。
bud LSR:
巴德LSR：
An LSR that is an egress LSR, but also has one or more directly connected downstream LSRs.
一种LSR，其为出口LSR，但也具有一个或多个直接连接的下游LSR。
branch LSR:
分支LSR：
An LSR that has more than one directly connected downstream LSR.
具有多个直接连接下游LSR的LSR。
P2MP-ID (P2ID):
P2MP-ID（P2ID）：
A unique identifier of a P2MP TE LSP, which is constant for the whole LSP regardless of the number of branches and/or leaves.
P2MP TE LSP的唯一标识符，无论分支和/或叶数多少，该标识符对于整个LSP都是常量。
source:
资料来源：
The sender of traffic that is carried on a P2MP service supported by a P2MP LSP. The sender is not necessarily the ingress LSR of the P2MP LSP.
P2MP LSP支持的P2MP服务上承载的通信量的发送方。发送方不一定是P2MP LSP的入口LSR。
receiver:
接收人：
A recipient of traffic carried on a P2MP service supported by a P2MP LSP. A receiver is not necessarily an egress LSR of the P2MP LSP. Zero, one, or more receivers may receive data through a given egress LSR.
P2MP LSP支持的P2MP服务上承载的流量的接收者。接收机不一定是P2MP LSP的出口LSR。零个、一个或多个接收机可通过给定出口LSR接收数据。
It is convenient to sub-divide P2MP trees for functional and representational reasons. A tree may be divided in two dimensions:
出于功能和代表性原因，可以方便地细分P2MP树。一棵树可以分为两个维度：
- A division may be made along the length of the tree. For example, the tree may be split into two components each running from the ingress LSR to a discrete set of egress LSRs. Upstream LSRs (for example, the ingress LSR) may be members of both components.
- 可以沿着树的长度进行划分。例如，树可以被分成两个组件，每个组件从入口LSR运行到一组离散的出口LSR。上游LSR（例如，入口LSR）可以是这两个组件的成员。
- A tree may be divided at a branch LSR (or any transit LSR) to produce a component of the tree that runs from the branch (or transit) LSR to all egress LSRs downstream of this point.
- 可在分支LSR（或任何运输LSR）处分割树，以产生从分支（或运输）LSR到该点下游所有出口LSR的树组件。
These two methods of splitting the P2MP tree can be combined, so it is useful to introduce some terminology to allow the partitioned trees to be clearly described.
这两种分割P2MP树的方法可以结合使用，因此引入一些术语以清晰地描述已分割的树是很有用的。
Use the following designations:
使用以下名称：
Source (ingress) LSR - S Leaf (egress) LSR - L Branch LSR - B Transit LSR - X (any single, arbitrary LSR that is not a source, leaf or branch) All - A Partial (i.e., not all) - P
源（入口）LSR-S叶（出口）LSR-L分支LSR-B传输LSR-X（不是源、叶或分支的任何单个、任意LSR）全部-部分（即非全部）-P
Define a new term:
定义一个新术语：
Sub-LSP: A segment of a P2MP TE LSP that runs from one of the LSP's LSRs to one or more of its other LSRs.
子LSP：P2MP TE LSP的一段，从一个LSP的LSR运行到另一个或多个LSR。
Using these new concepts, we can define any combination or split of the P2MP tree. For example:
使用这些新概念，我们可以定义P2MP树的任何组合或拆分。例如：
S2L sub-LSP: The path from the source to one specific leaf.
S2L子LSP：从源到一个特定叶的路径。
S2PL sub-LSP: The path from the source to a set of leaves.
S2PL子LSP：从源到一组叶子的路径。
B2AL sub-LSP: The path from a branch LSR to all downstream leaves.
B2AL子LSP：从分支LSR到所有下游叶片的路径。
X2X sub-LSP: A component of the P2MP LSP that is a simple path that does not branch.
X2X子LSP：P2MP LSP的一个组件，它是一个不分支的简单路径。
Note that the S2AL sub-LSP is equivalent to the P2MP LSP.
注意，S2AL子LSP等同于P2MP LSP。
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]中所述进行解释。
As described in Section 1, traffic engineering and constraint-based routing (including Call Admission Control (CAC), explicit source routing, and bandwidth reservation) are required to enable efficient resource usage and strict QoS guarantees. Such mechanisms also make it possible to provide services across a congested network where conventional "shortest path first" forwarding paradigms would fail.
如第1节所述，需要流量工程和基于约束的路由（包括呼叫允许控制（CAC）、显式源路由和带宽预留），以实现高效的资源使用和严格的QoS保证。这种机制还使得在传统的“最短路径优先”转发模式将失败的拥挤网络上提供服务成为可能。
Existing MPLS TE mechanisms [RFC3209] and GMPLS TE mechanisms [RFC3473] only provide support for P2P TE LSPs. While it is possible to provide P2MP TE services using P2P TE LSPs, any such approach is potentially suboptimal since it may result in data replication at the ingress LSR, or in duplicate data traffic within the network.
现有的MPLS TE机制[RFC3209]和GMPLS TE机制[RFC3473]仅支持P2P TE LSP。虽然可以使用P2P-TE-lsp提供P2MP-TE服务，但是任何这样的方法都可能是次优的，因为它可能导致入口LSR处的数据复制，或者导致网络内的重复数据流量。
Hence, to provide P2MP MPLS TE services in a fully efficient manner, it is necessary to specify specific requirements. These requirements can then be used when defining mechanisms for the use of existing protocols and/or extensions to existing protocols and/or new protocols.
因此，为了以完全有效的方式提供P2MP MPLS TE服务，有必要指定特定的要求。然后，在定义使用现有协议和/或扩展现有协议和/或新协议的机制时，可以使用这些需求。
This document states basic requirements for the setup of P2MP TE LSPs. The requirements apply to the signaling techniques only, and no assumptions are made about which routing protocols are run within the network, or about how the information that is used to construct the Traffic Engineering Database (TED) is distributed. These factors are out of the scope of this document.
本文件说明了P2MP TE LSP设置的基本要求。这些要求仅适用于信令技术，没有对网络中运行的路由协议或用于构建流量工程数据库（TED）的信息如何分布做出任何假设。这些因素不在本文件的范围内。
A P2MP TE LSP path computation will take into account various constraints such as bandwidth, affinities, required level of protection and so on. The solution MUST allow for the computation of P2MP TE LSP paths that satisfy constraints, with the objective of
P2MP TE LSP路径计算将考虑各种约束，如带宽、亲和力、所需的保护级别等。该解决方案必须允许计算满足约束的P2MP TE LSP路径，目标是
supporting various optimization criteria such as delays, bandwidth consumption in the network, or any other combinations. This is likely to require the presence of a TED, as well as the ability to signal the explicit path of an LSP.
支持各种优化标准，如延迟、网络中的带宽消耗或任何其他组合。这可能需要TED的存在，以及向LSP的显式路径发送信号的能力。
A desired requirement is also to maximize the re-use of existing MPLS TE techniques and protocols where doing so does not adversely impact the function, simplicity, or scalability of the solution.
一个期望的要求也是最大限度地重用现有的MPLS TE技术和协议，这样做不会对解决方案的功能、简单性或可伸缩性产生不利影响。
This document does not restrict the choice of signaling protocol used to set up a P2MP TE LSP, but note that [RFC3468] states
本文件不限制用于设置P2MP TE LSP的信令协议的选择，但请注意，[RFC3468]规定
...the consensus reached by the Multiprotocol Label Switching (MPLS) Working Group within the IETF to focus its efforts on "Resource Reservation Protocol (RSVP)-TE: Extensions to RSVP for Label-Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS signalling protocol for traffic engineering applications...
…IETF内的多协议标签交换（MPLS）工作组达成的共识，将其工作重点放在“资源预留协议（RSVP）-TE：标签交换路径（LSP）隧道的RSVP扩展”（RFC 3209）上，作为流量工程应用的MPLS信令协议。。。
The P2MP TE LSP setup mechanism MUST include the ability to add/remove egress LSRs to/from an existing P2MP TE LSP and MUST allow for the support of all the TE LSP management procedures already defined for P2P TE LSP. Further, when new TE LSP procedures are developed for P2P TE LSPs, equivalent or identical procedures SHOULD be developed for P2MP TE LSPs.
P2MP TE LSP设置机制必须包括向现有P2MP TE LSP添加/删除出口LSR的能力，并且必须允许支持已经为P2P TE LSP定义的所有TE LSP管理过程。此外，当为P2P TE LSP开发新的TE LSP程序时，应为P2MP TE LSP开发等效或相同的程序。
The computation of P2MP trees is implementation dependent and is beyond the scope of the solutions that are built with this document as a guideline.
P2MP树的计算取决于实现，超出了以本文档为指导构建的解决方案的范围。
Consider the following figure.
考虑下面的数字。
Source 1 (S1)
|
I-LSR1
| |
| |
R2----E-LSR3--LSR1 LSR2---E-LSR2--Receiver 1 (R1)
| :
R3----E-LSR4 E-LSR5
| :
| :
R4 R5
Source 1 (S1)
|
I-LSR1
| |
| |
R2----E-LSR3--LSR1 LSR2---E-LSR2--Receiver 1 (R1)
| :
R3----E-LSR4 E-LSR5
| :
| :
R4 R5
Figure 1
图1
Figure 1 shows a single ingress LSR (I-LSR1), and four egress LSRs (E-LSR2, E-LSR3, E-LSR4, and E-LSR5). I-LSR1 is attached to a traffic source that is generating traffic for a P2MP application.
图1显示了一个入口LSR（I-LSR1）和四个出口LSR（E-LSR2、E-LSR3、E-LSR4和E-LSR5）。I-LSR1连接到为P2MP应用程序生成流量的流量源。
Receivers R1, R2, R3, and R4 are attached to E-LSR2, E-LSR3, and E-LSR4.
接收机R1、R2、R3和R4连接到E-LSR2、E-LSR3和E-LSR4。
The following are the objectives of P2MP LSP establishment and use.
以下是P2MP LSP建立和使用的目标。
a) A P2MP tree that satisfies various constraints is pre-determined, and details are supplied to I-LSR1.
a) 预先确定满足各种约束的P2MP树，并向I-LSR1提供详细信息。
Note that no assumption is made about whether the tree is provided to I-LSR1 or computed by I-LSR1. The solution SHOULD also allow for the support of a partial path by means of loose routing.
注意，对于树是提供给I-LSR1还是由I-LSR1计算，没有做出任何假设。该解决方案还应允许通过松散路由支持部分路径。
Typical constraints are bandwidth requirements, resource class affinities, fast rerouting, and preemption. There should not be any restriction on the possibility of supporting the set of constraints already defined for point-to-point TE LSPs. A new constraint may specify which LSRs should be used as branch LSRs for the P2MP LSR in order to take into account LSR capabilities or network constraints.
典型的约束是带宽需求、资源类相关性、快速重路由和抢占。对于支持已经为点到点TE LSP定义的约束集的可能性不应有任何限制。新的约束可以指定哪些LSR应该用作P2MP LSR的分支LSR，以便考虑LSR能力或网络约束。
b) A P2MP TE LSP is set up from I-LSR1 to E-LSR2, E-LSR3, and E-LSR4 using the tree information.
b) 使用树信息从I-LSR1到E-LSR2、E-LSR3和E-LSR4设置P2MP TE LSP。
c) In this case, the branch LSR1 should replicate incoming packets or data and send them to E-LSR3 and E-LSR4.
c) 在这种情况下，分支LSR1应该复制传入的数据包或数据，并将它们发送到E-LSR3和E-LSR4。
d) If a new receiver (R5) expresses an interest in receiving traffic, a new tree is determined, and a B2L sub-LSP from LSR2 to E-LSR5 is grafted onto the P2MP TE LSP. LSR2 becomes a branch LSR.
d) 如果新的接收器（R5）表示对接收业务感兴趣，则确定新的树，并且将从LSR2到E-LSR5的B2L子LSP嫁接到P2MP TE LSP上。LSR2成为一个分支LSR。
The P2MP TE extensions MUST be applicable to the signaling of LSPs for different switching types. For example, it MUST be possible to signal a P2MP TE LSP in any switching medium, whether it is packet or non-packet based (including frame, cell, TDM, lambda, etc.).
P2MP TE扩展必须适用于不同交换类型的LSP信令。例如，必须能够在任何交换介质中向P2MP TE LSP发送信号，无论其是基于分组的还是基于非分组的（包括帧、小区、TDM、lambda等）。
As with P2P MPLS technology [RFC3031], traffic is classified with a FEC in this extension. All packets that belong to a particular FEC and that travel from a particular node MUST follow the same P2MP tree.
与P2P MPLS技术[RFC3031]一样，流量在该扩展中使用FEC进行分类。属于特定FEC且从特定节点传输的所有数据包必须遵循相同的P2MP树。
In order to scale to a large number of branches, P2MP TE LSPs SHOULD be identified by a unique identifier (the P2MP ID or P2ID) that is constant for the whole LSP regardless of the number of branches and/or leaves.
为了扩展到大量分支，P2MP TE LSP应通过唯一标识符（P2MP ID或P2ID）进行标识，该标识符对于整个LSP而言是恒定的，无论分支和/或叶的数量如何。
Various optimizations in P2MP tree formation need to be applied to meet various QoS requirements and operational constraints.
P2MP树形成中的各种优化需要应用于满足各种QoS要求和操作约束。
Some P2MP applications may request a bandwidth-guaranteed P2MP tree that satisfies end-to-end delay requirements. And some operators may want to set up a cost-minimum P2MP tree by specifying branch LSRs explicitly.
一些P2MP应用程序可能会请求满足端到端延迟要求的带宽保证P2MP树。一些运营商可能希望通过明确指定分支LSR来建立成本最低的P2MP树。
The P2MP TE solution therefore MUST provide a means of establishing arbitrary P2MP trees under the control of an external tree computation process, path configuration process, or dynamic tree computation process located on the ingress LSR. Figure 2 shows two typical examples.
因此，P2MP TE解决方案必须提供在入口LSR上的外部树计算过程、路径配置过程或动态树计算过程的控制下建立任意P2MP树的方法。图2显示了两个典型示例。
A A
| / \
B B C
| / \ / \
C D E F G
| / \ / \/ \ / \
D--E*-F*-G*-H*-I*-J*-K*--L H I J KL M N O
A A
| / \
B B C
| / \ / \
C D E F G
| / \ / \/ \ / \
D--E*-F*-G*-H*-I*-J*-K*--L H I J KL M N O
Steiner P2MP tree SPF P2MP tree
Steiner P2MP树SPF P2MP树
Figure 2: Examples of P2MP TE LSP topology
图2:P2MP TE LSP拓扑的示例
One example is the Steiner P2MP tree (cost-minimum P2MP tree) [STEINER]. This P2MP tree is suitable for constructing a cost-minimum P2MP tree so as to minimize the bandwidth consumption in the core. To realize this P2MP tree, several intermediate LSRs must be both MPLS data terminating LSRs and transit LSRs (LSRs E, F, G, H, I, J, and K in Figure 2). Therefore, the P2MP TE solution MUST support a mechanism that can set up this kind of bud LSR between an ingress LSR and egress LSRs. Note that this includes constrained Steiner trees that allow for the computation of a minimal cost trees with some other constraints such as a bounded delay between the source and every receiver.
一个例子是Steiner P2MP树（成本最小P2MP树）[Steiner]。该P2MP树适用于构造成本最小的P2MP树，以最小化核心中的带宽消耗。为了实现这个P2MP树，几个中间LSR必须是MPLS数据终止LSR和传输LSR（图2中的LSR E、F、G、H、I、J和K）。因此，P2MP TE解决方案必须支持在入口LSR和出口LSR之间建立此类bud LSR的机制。请注意，这包括受约束的Steiner树，该树允许计算最小成本树以及一些其他约束，例如源和每个接收器之间的有界延迟。
Another example is a CSPF (Constraint Shortest Path First) P2MP tree. By some metric (which can be set upon any specific criteria like the delay, bandwidth, or a combination of those), one can calculate a shortest-path P2MP tree. This P2MP tree is suitable for carrying real-time traffic.
另一个例子是CSPF（约束最短路径优先）P2MP树。通过某种度量（可以根据任何特定标准设置，如延迟、带宽或它们的组合），可以计算最短路径P2MP树。此P2MP树适合承载实时流量。
The solution MUST allow the operator to make use of any tree computation technique. In the former case, an efficient/optimal tree is defined as a minimal cost tree (Steiner tree), whereas in the later case, it is defined as the tree that provides shortest path between the source and any receiver.
解决方案必须允许操作员使用任何树计算技术。在前一种情况下，有效/最优树被定义为最小成本树（Steiner树），而在后一种情况下，它被定义为在源和任何接收器之间提供最短路径的树。
To support explicit setup of any reasonable P2MP tree shape, a P2MP TE solution MUST support some form of explicit source-based control of the P2MP tree that can explicitly include particular LSRs as branch LSRs. This can be used by the ingress LSR to set up the P2MP TE LSP. For instance, a P2MP TE LSP can be represented simply as a whole tree or by its individual branches.
为了支持任何合理的P2MP树形状的显式设置，P2MP TE解决方案必须支持P2MP树的某种形式的基于源代码的显式控制，该控制可以显式地将特定的LSR包括为分支LSR。入口LSR可使用此设置P2MP TE LSP。例如，P2MP TE LSP可以简单地表示为一棵整棵树，也可以表示为它的各个分支。
A P2MP tree is completely specified if all the required branches and hops between a sender and leaf LSR are indicated.
如果指定了发送方和叶LSR之间所需的所有分支和跃点，则完全指定P2MP树。
A P2MP tree is partially specified if only a subset of intermediate branches and hops is indicated. This may be achieved using loose hops in the explicit path, or using widely scoped abstract nodes (that is, abstract nodes that are not simple [RFC3209]) such as IPv4 prefixes shorter than 32 bits, or AS numbers. A partially specified P2MP tree might be particularly useful in inter-area and inter-AS situations, although P2MP requirements for inter-area and inter-AS are beyond the scope of this document.
如果仅指示中间分支和跃点的子集，则部分指定P2MP树。这可以通过使用显式路径中的松散跃点，或使用范围广泛的抽象节点（即，非简单[RFC3209]的抽象节点），例如短于32位的IPv4前缀，或作为数字来实现。部分指定的P2MP树在区域间和区域间AS情况下可能特别有用，尽管区域间和区域间AS的P2MP要求超出了本文档的范围。
Protocol solutions SHOULD include a way to specify loose hops and widely scoped abstract nodes in the explicit source-based control of the P2MP tree as defined in the previous section. Where this support is provided, protocol solutions MUST allow downstream LSRs to apply further explicit control to the P2MP tree to resolve a partially specified tree into a (more) completely specified tree.
协议解决方案应包括一种在P2MP树的显式源代码控制中指定松散跃点和范围广泛的抽象节点的方法，如前一节所定义。在提供此支持的情况下，协议解决方案必须允许下游LSR对P2MP树应用进一步的显式控制，以将部分指定的树解析为（更）完全指定的树。
Protocol solutions MUST allow the P2MP tree to be completely specified at the ingress LSR where sufficient information exists to allow the full tree to be computed and where policies along the path (such as at domain boundaries) support full specification.
协议解决方案必须允许在入口LSR完全指定P2MP树，其中有足够的信息允许计算完整的树，并且路径上的策略（如域边界）支持完整的规范。
In all cases, the egress LSRs of the P2MP TE LSP must be fully specified either individually or through some collective identifier. Without this information, it is impossible to know where the TE LSP should be routed to.
在所有情况下，P2MP TE LSP的出口LSR必须单独或通过某种集体标识符完全指定。没有这些信息，就不可能知道TE LSP应该路由到哪里。
In case of a tree being computed by some downstream LSRs (e.g., the case of hops specified as loose hops), the solution MUST provide protocol mechanisms for the ingress LSR of the P2MP TE LSP to learn the full P2MP tree. Note that this information may not always be obtainable owing to policy considerations, but where part of the path remains confidential, it MUST be reported through aggregation (for example, using an AS number).
如果树由一些下游LSR计算（例如，指定为松散跳数的跳数），则解决方案必须为P2MP TE LSP的入口LSR提供协议机制，以学习完整的P2MP树。请注意，出于政策考虑，这些信息可能并不总是可以获得的，但如果部分路径仍然保密，则必须通过聚合（例如，使用AS编号）进行报告。
The P2MP TE solution MUST support establishment, maintenance, and teardown of P2MP TE LSPs in a manner that is at least scalable in a linear way. This MUST include both the existence of very many LSPs at once, and the existence of very many destinations for a single P2MP LSP.
P2MP TE解决方案必须以至少可线性扩展的方式支持P2MP TE LSP的建立、维护和拆卸。这必须包括同时存在非常多的LSP，以及单个P2MP LSP存在非常多的目的地。
In addition to P2MP TE LSP establishment and teardown mechanisms, the solution SHOULD support a partial P2MP tree modification mechanism.
除了P2MP TE LSP建立和拆卸机制外，解决方案还应支持部分P2MP树修改机制。
For the purpose of adding sub-P2MP TE LSPs to an existing P2MP TE LSP, the extensions SHOULD support a grafting mechanism. For the purpose of deleting a sub-P2MP TE LSPs from an existing P2MP TE LSP, the extensions SHOULD support a pruning mechanism.
为了将子P2MP TE LSP添加到现有P2MP TE LSP，扩展应支持嫁接机制。为了从现有P2MP TE LSP中删除子P2MP TE LSP，扩展应该支持修剪机制。
It is RECOMMENDED that these grafting and pruning operations cause no additional processing in nodes that are not along the path to the grafting or pruning node, or that are downstream of the grafting or pruning node toward the grafted or pruned leaves. Moreover, both grafting and pruning operations MUST NOT disrupt traffic currently forwarded along the P2MP tree.
建议这些嫁接和修剪操作不会在不沿嫁接或修剪节点路径的节点中，或在嫁接或修剪节点下游朝向嫁接或修剪叶片的节点中引起额外处理。此外，嫁接和修剪操作不得中断当前沿P2MP树转发的流量。
There is no assumption that the explicitly routed P2MP LSP remains on an optimal path after several grafts and prunes have occurred. In this context, scalable refers to the signaling process for the P2MP TE LSP. The TE nature of the LSP allows that re-optimization may take place from time to time to restore the optimality of the LSP.
没有假设显式路由的P2MP LSP在经过多次嫁接和修剪后仍保持在最佳路径上。在此上下文中，scalable指的是P2MP TE LSP的信令过程。LSP的TE性质允许不时进行重新优化，以恢复LSP的最佳性。
The P2MP TE solution MUST handle the situation where a single protocol message cannot contain all the information necessary to signal the establishment of the P2MP LSP. It MUST be possible to establish the LSP in these circumstances.
P2MP TE解决方案必须处理单个协议消息不能包含所有必要信息以发出P2MP LSP建立信号的情况。在这些情况下，必须能够建立LSP。
This situation may arise in either of the following circumstances.
这种情况可能出现在以下任一情况下。
a. The ingress LSR cannot signal the whole tree in a single message.
a. 入口LSR不能在单个消息中向整个树发送信号。
b. The information in a message expands to be too large (or is discovered to be too large) at some transit node. This may occur because of some increase in the information that needs to be signaled or because of a reduction in the size of signaling message that is supported.
b. 消息中的信息在某个传输节点上扩展得太大（或被发现太大）。这可能是因为需要发送信号的信息有所增加，或者是因为所支持的信号消息的大小有所减小。
The solution to these problems SHOULD NOT rely on IP fragmentation of protocol messages, and it is RECOMMENDED to rely on some protocol procedures specific to the signaling solution.
这些问题的解决方案不应依赖于协议消息的IP分段，建议依赖于特定于信令解决方案的一些协议过程。
In the event that fragmented IP packets containing protocol messages are received, it is NOT RECOMMENDED that they are reassembled at the receiving LSR.
如果接收到包含协议消息的分段IP数据包，建议不要在接收LSR处重新组装这些数据包。
Failure events may cause egress LSRs or sub-P2MP LSPs to become detached from the P2MP TE LSP. These events MUST be reported upstream as for a P2P LSP.
故障事件可能导致出口LSR或次级P2MP LSP与P2MP TE LSP分离。对于P2P LSP，必须向上游报告这些事件。
The solution SHOULD provide recovery techniques, such as protection and restoration, allowing recovery of any impacted sub-P2MP TE LSPs. In particular, a solution MUST provide fast protection mechanisms applicable to P2MP TE LSP similar to the solutions specified in [RFC4090] for P2P TE LSPs. Note also that no assumption is made about whether backup paths for P2MP TE LSPs should or should not be shared with P2P TE LSPs backup paths.
解决方案应提供恢复技术，如保护和恢复，允许恢复任何受影响的sub-P2MP TE LSP。特别是，解决方案必须提供适用于P2MP TE LSP的快速保护机制，类似于[RFC4090]中为P2P TE LSP指定的解决方案。还请注意，对于P2MP TE lsp的备份路径是否应该与P2P TE lsp备份路径共享，没有做出任何假设。
Note that the functions specified in [RFC4090] are currently specific to packet environments and do not apply to non-packet environments. Thus, while solutions MUST provide fast protection mechanisms similar to those specified in [RFC4090], this requirement is limited to the subset of the solution space that applies to packet-switched networks only.
请注意，[RFC4090]中指定的功能目前特定于数据包环境，不适用于非数据包环境。因此，虽然解决方案必须提供类似于[RFC4090]中规定的快速保护机制，但该要求仅限于仅适用于分组交换网络的解决方案空间子集。
Note that the requirements expressed in this document are general to all MPLS TE P2MP signaling, and any solution that meets them will therefore be general. Specific applications may have additional requirements or may want to relax some requirements stated in this document. This may lead to variations in the solution.
请注意，本文档中表达的要求对所有MPLS TE P2MP信令都是通用的，因此满足这些要求的任何解决方案都是通用的。特定应用可能有额外要求，或者可能希望放宽本文件中规定的某些要求。这可能会导致解决方案的变化。
The solution SHOULD also support the ability to meet other network recovery requirements such as bandwidth protection and bounded propagation delay increase along the backup path during failure.
该解决方案还应支持满足其他网络恢复要求的能力，如带宽保护和故障期间沿备份路径增加的有界传播延迟。
A P2MP TE solution MUST support the P2MP fast protection mechanism to handle P2MP applications sensitive to traffic disruption.
P2MP TE解决方案必须支持P2MP快速保护机制，以处理对流量中断敏感的P2MP应用程序。
If the ingress LSR is informed of the failure of delivery to fewer than all the egress LSRs, this SHOULD NOT cause automatic teardown of the P2MP TE LSP. That is, while some egress LSRs remain connected to the P2MP tree, it SHOULD be a matter of local policy at the ingress LSR whether the P2MP LSP is retained.
如果入口LSR被告知无法传送到少于所有出口LSR，这不应导致P2MP TE LSP的自动拆卸。也就是说，虽然一些出口LSR保持与P2MP树的连接，但是否保留P2MP LSP应该是入口LSR的本地策略问题。
When all egress LSRs downstream of a branch LSR have become disconnected from the P2MP tree, and some branch LSR is unable to restore connectivity to any of them by means of some recovery or protection mechanisms, the branch LSR MAY remove itself from the P2MP tree provided that it is not also an egress LSR (that is, a bud). Since the faults that severed the various downstream egress LSRs from the P2MP tree may be disparate, the branch LSR MUST report all such errors to its upstream neighbor. An upstream LSR or the ingress LSR can then decide to re-compute the path to those particular egress LSRs around the failure point.
当分支LSR下游的所有出口LSR已与P2MP树断开连接，并且一些分支LSR无法通过一些恢复或保护机制恢复到它们中的任何一个的连接时，分支LSR可以从P2MP树中移除自身，前提是它不是出口LSR（即，bud）。由于将各种下游出口LSR与P2MP树断开的故障可能不同，因此分支LSR必须向其上游邻居报告所有此类错误。然后，上游LSR或入口LSR可以决定重新计算故障点周围那些特定出口LSR的路径。
Solutions MAY include the facility for transit LSRs and particularly branch LSRs to recompute sub-P2MP trees to restore them after failures. In the event of successful repair, error notifications SHOULD NOT be reported to upstream nodes, but the new paths are reported if route recording is in use. Crankback requirements are discussed in Section 4.21.
解决方案可能包括运输LSR设施，特别是分支LSR设施，用于重新计算子P2MP树，以便在故障后恢复它们。在修复成功的情况下，不应向上游节点报告错误通知，但如果正在使用路由记录，则会报告新路径。第4.21节讨论了拖转要求。
Being able to identify the established topology of P2MP TE LSP is very important for various purposes such as management and operation of some local recovery mechanisms like Fast Reroute [RFC4090]. A network operator uses this information to manage P2MP TE LSPs.
能够识别P2MP TE LSP的已建立拓扑对于各种目的非常重要，例如管理和操作一些本地恢复机制，如快速重路由[RFC4090]。网络运营商使用此信息管理P2MP TE LSP。
Therefore, the P2MP TE solution MUST support a mechanism that can collect and update P2MP tree topology information after the P2MP LSP establishment and modification process.
因此，P2MP TE解决方案必须支持在P2MP LSP建立和修改过程之后收集和更新P2MP树拓扑信息的机制。
It is RECOMMENDED that the information is collected in a data format that allows easy recognition of the P2MP tree topology.
建议以便于识别P2MP树拓扑的数据格式收集信息。
The solution MUST support mechanisms for the recording of both outgoing interfaces and node-ids.
解决方案必须支持记录传出接口和节点ID的机制。
The solution MUST gracefully handle scaling issues concerned with the collection of P2MP tree information, including the case where the collected information is too large to be carried in a single protocol message.
解决方案必须优雅地处理与P2MP树信息收集有关的缩放问题，包括收集的信息太大而无法在单个协议消息中携带的情况。
4.8. Call Admission Control (CAC) and QoS Control Mechanism of P2MP TE LSPs
4.8. P2MP-TE-lsp的呼叫接纳控制（CAC）和QoS控制机制
P2MP TE LSPs may share network resource with P2P TE LSPs. Therefore, it is important to use CAC and QoS in the same way as P2P TE LSPs for easy and scalable operation.
P2MP-TE-lsp可以与P2P-TE-lsp共享网络资源。因此，重要的是要以与P2P-TE-lsp相同的方式使用CAC和QoS，以实现简单且可扩展的操作。
P2MP TE solutions MUST support both resource sharing and exclusive resource utilization to facilitate coexistence with other LSPs to the same destination(s).
P2MP TE解决方案必须支持资源共享和独占资源利用，以促进与其他LSP共存到同一目的地。
P2MP TE solutions MUST be applicable to DiffServ-enabled networks that can provide consistent QoS control in P2MP LSP traffic.
P2MP TE解决方案必须适用于支持区分服务的网络，这些网络可以在P2MP LSP流量中提供一致的QoS控制。
Any solution SHOULD also satisfy the DS-TE requirements [RFC3564] and interoperate smoothly with current P2P DS-TE protocol specifications.
任何解决方案也应满足DS-TE要求[RFC3564]，并与当前的P2P DS-TE协议规范顺利互操作。
Note that this requirement document does not make any assumption on the type of bandwidth pool used for P2MP TE LSPs, which can either be shared with P2P TE LSP or be dedicated for P2MP use.
请注意，本需求文件未对P2MP TE LSP使用的带宽池类型做出任何假设，该带宽池可以与P2P TE LSP共享，也可以专用于P2MP使用。
Certain parameters (such as priority and bandwidth) are associated with an LSP. The parameters are installed by the signaling exchanges associated with establishing and maintaining the LSP.
某些参数（如优先级和带宽）与LSP关联。这些参数由与建立和维护LSP相关的信令交换机安装。
Any solution MUST NOT allow for variance of these parameters within a single P2MP LSP. That is:
任何解决方案都不得允许这些参数在单个P2MP LSP内发生变化。即:
- No attributes set and signaled by the ingress LSR of a P2MP LSP may be varied by downstream LSRs. - There MUST be homogeneous QoS from the root to all leaves of a single P2MP LSP.
- P2MP LSP的入口LSR设置和发出信号的属性不能因下游LSR而改变。-从根到单个P2MP LSP的所有叶必须具有相同的QoS。
Changing the parameters for the whole tree MAY be supported, but the change MUST apply to the whole tree from ingress LSR to all egress LSRs.
可能支持更改整个树的参数，但更改必须应用于从入口LSR到所有出口LSR的整个树。
The detection of a more optimal path (for example, one with a lower overall cost) is an example of a situation where P2MP TE LSP re-routing may be required. While re-routing is in progress, an important requirement is to avoid double bandwidth reservation (over the common parts between the old and new LSP) thorough the use of resource sharing.
检测更优化的路径（例如，具有较低总体成本的路径）是可能需要P2MP-TE-LSP重新路由的情况的示例。当重新路由正在进行时，一个重要的要求是通过使用资源共享避免双重带宽保留（在新旧LSP之间的公共部分上）。
Make-before-break MUST be supported for a P2MP TE LSP to ensure that there is minimal traffic disruption when the P2MP TE LSP is re-routed.
P2MP TE LSP必须支持先通后断，以确保重新路由P2MP TE LSP时的通信中断最小。
Make-before-break that only applies to a sub-P2MP tree without impacting the data on all the other parts of the P2MP tree MUST be supported.
必须支持只适用于子P2MP树而不影响P2MP树所有其他部分数据的先通后断。
The solution SHOULD allow for make-before-break re-optimization of any subdivision of the P2MP LSP (S2PL sub-LSP, S2X sub-LSP, S2L sub-LSP, X2AL sub-LSP, B2PL sub-LSP, X2AL sub-LSP, or B2AL tree). Further, it SHOULD do so by minimizing the signaling impact on the rest of the P2MP LSP, and without affecting the ability of the management plane to manage the LSP.
该解决方案应允许对P2MP LSP（S2PL子LSP、S2X子LSP、S2L子LSP、X2AL子LSP、B2PL子LSP、X2AL子LSP或B2AL树）的任何细分进行先通后断的重新优化。此外，它应该通过最小化对P2MP LSP的其余部分的信令影响，并且不影响管理平面管理LSP的能力来做到这一点。
The solution SHOULD also provide the ability for the ingress LSR to have strict control over the re-optimization process. The ingress LSR SHOULD be able to limit all re-optimization to be source-initiated.
该解决方案还应提供入口LSR对重新优化过程进行严格控制的能力。入口LSR应能够限制源启动的所有重新优化。
Where sub-LSP re-optimization is allowed by the ingress LSR, such re-optimization MAY be initiated by a downstream LSR that is the root of the sub-LSP that is to be re-optimized. Sub-LSP re-optimization initiated by a downstream LSR MUST be carried out with the same regard to minimizing the impact on active traffic as was described above for other re-optimization.
在入口LSR允许子LSP重新优化的情况下，这种重新优化可以由作为要重新优化的子LSP的根的下游LSR发起。下游LSR启动的子LSP重新优化必须按照与上述其他重新优化相同的考虑，以最小化对活动流量的影响。
It is possible for a single transit LSR to receive multiple signaling messages for the same P2MP LSP but for different sets of destinations. These messages may be received from the same or different upstream nodes and may need to be passed on to the same or different downstream nodes.
对于同一个P2MP LSP，但对于不同的目的地集，单个传输LSR可以接收多个信令消息。这些消息可以从相同或不同的上游节点接收，并且可能需要传递到相同或不同的下游节点。
This situation may arise as the result of the signaling solution definition or implementation options within the signaling solution. Further, it may happen during make-before-break re-optimization (Section 4.10).
这种情况可能是由于信令解决方案中的信令解决方案定义或实现选项导致的。此外，这可能发生在先通后断的重新优化过程中（第4.10节）。
It is even possible that it is necessary to construct distinct upstream branches in order to achieve the correct label choices in certain switching technologies managed by GMPLS (for example, photonic cross-connects where the selection of a particular lambda for the downstream branches is only available on different upstream switches).
甚至有可能需要构造不同的上游分支，以便在GMPLS管理的某些交换技术中实现正确的标签选择（例如，光子交叉连接，其中下游分支的特定λ选择仅在不同的上游交换机上可用）。
The solution MUST support the case where multiple signaling messages for the same P2MP LSP are received at a single transit LSR and refer to the same upstream interface. In this case, the result of the protocol procedures SHOULD be a single data flow on the upstream interface.
该解决方案必须支持在单个传输LSR处接收同一P2MP LSP的多个信令消息并引用同一上游接口的情况。在这种情况下，协议过程的结果应该是上游接口上的单个数据流。
The solution SHOULD support the case where multiple signaling messages for the same P2MP LSP are received at a single transit LSR and refer to different upstream interfaces, and where each signaling message results in the use of different downstream interfaces. This case represents data flows that cross at the LSR but that do not merge.
该解决方案应支持在单个传输LSR处接收相同P2MP LSP的多个信令消息并引用不同的上游接口，以及每个信令消息导致使用不同的下游接口的情况。本例表示在LSR处交叉但不合并的数据流。
The solution MAY support the case where multiple signaling messages for the same P2MP LSP are received at a single transit LSR and refer to different upstream interfaces, and where the downstream interfaces are shared across the received signaling messages. This case represents the merging of data flows. A solution that supports this case MUST ensure that data is not replicated on the downstream interfaces.
该解决方案可支持以下情况：在单个传输LSR处接收相同P2MP LSP的多个信令消息并参考不同的上游接口，以及在接收到的信令消息之间共享下游接口。本例表示数据流的合并。支持这种情况的解决方案必须确保数据不会在下游接口上复制。
An alternative to supporting this last case is for the signaling protocol to indicate an error such that the merge may be resolved by the upstream LSRs.
支持最后一种情况的替代方案是，信令协议指示错误，使得合并可以由上游lsr解决。
Data duplication refers to the receipt by any recipient of duplicate instances of the data. In a packet environment, this means the receipt of duplicate packets. Although small-scale packet duplication (that is, a few packets over a relatively short period of time) should be a harmless (if inefficient) situation, certain existing and deployed applications will not tolerate packet duplication. Sustained packet duplication is, at best, a waste of network and processing resources and, at worst, may cause congestion and the inability to process the data correctly.
数据重复是指任何收件人收到重复的数据实例。在数据包环境中，这意味着接收重复的数据包。虽然小规模的数据包复制（即在相对较短的时间内复制几个数据包）应该是无害的（如果效率低下的话），但某些现有和部署的应用程序将无法容忍数据包复制。持续的数据包复制充其量是对网络和处理资源的浪费，最坏的情况是可能导致拥塞和无法正确处理数据。
In a non-packet environment, data duplication means the duplication of some part of the signal that may lead to the replication of data or to the scrambling of data.
在非分组环境中，数据复制指的是可能导致数据复制或数据置乱的信号部分的复制。
Data duplication may legitimately arise in various scenarios including re-optimization of active LSPs as described in the previous section, and protection of LSPs. Thus, it is impractical to regulate against data duplication in this document.
在各种情况下可能会合法地出现数据复制，包括如前一节所述的活动LSP的重新优化，以及LSP的保护。因此，在本文件中规定防止数据重复是不切实际的。
Instead, the solution:
相反，解决方案是：
- SHOULD limit to bounded transitory conditions the cases where network bandwidth is wasted by the existence of duplicate delivery paths.
- 应将网络带宽因存在重复传输路径而浪费的情况限制在有限的临时条件下。
- MUST limit the cases where duplicate data is delivered to an application to bounded transitory conditions.
- 必须将向应用程序交付重复数据的情况限制为有界的临时条件。
Any P2MP TE solution MUST support IPv4 and IPv6 addressing.
任何P2MP TE解决方案都必须支持IPv4和IPv6寻址。
A P2MP TE solution MUST allow the continued use of existing techniques to establish P2P LSPs (TE and otherwise) within the same network, and MUST allow the coexistence of P2P LSPs within the same network as P2MP TE LSPs.
P2MP TE解决方案必须允许继续使用现有技术在同一网络内建立P2P LSP（TE和其他），并且必须允许P2P LSP与P2MP TE LSP在同一网络内共存。
A P2MP TE solution MUST be specified in such a way that it allows P2MP and P2P TE LSPs to be signaled on the same interface.
P2MP TE解决方案的指定方式必须允许P2MP和P2P TE LSP在同一接口上发出信号。
Several high-level requirements have been identified to determine the capabilities of LSRs within a P2MP network. The aim of such information is to facilitate the computation of P2MP trees using TE constraints within a network that contains LSRs that do not all have the same capability levels with respect to P2MP signaling and data forwarding.
已经确定了几个高层需求，以确定P2MP网络中LSR的能力。此类信息的目的是在包含LSR的网络中使用TE约束来促进P2MP树的计算，这些LSR在P2MP信令和数据转发方面并不都具有相同的能力级别。
These capabilities include, but are not limited to:
这些能力包括但不限于：
- The ability of an LSR to support branching. - The ability of an LSR to act as an egress LSR and a branch LSR for the same LSP. - The ability of an LSR to support P2MP MPLS-TE signaling.
- LSR支持分支的能力。-LSR作为同一LSP的出口LSR和分支LSR的能力。-LSR支持P2MP MPLS-TE信令的能力。
P2MP MPLS TE may be used to traverse network segments that are provided by multi-access media such as Ethernet. In these cases, it is also possible that the entry point to the network segment is a branch LSR of the P2MP LSP.
P2MP MPLS TE可用于遍历由多接入媒体（如以太网）提供的网段。在这些情况下，网段的入口点也可能是P2MP LSP的分支LSR。
Two options clearly exist:
显然存在两种选择：
- the branch LSR replicates the data and transmits multiple copies onto the segment. - the branch LSR sends a single copy of the data to the segment and relies on the exit points to determine whether to receive and forward the data.
- 分支LSR复制数据并将多个副本传输到段上。-分支LSR向段发送数据的单个副本，并依赖出口点确定是否接收和转发数据。
The first option has a significant data plane scaling issue since all replicated data must be sent through the same port and carried on the same segment. Thus, a solution SHOULD provide a mechanism for a branch LSR to send a single copy of the data onto a multi-access network to reach multiple (adjacent) downstream nodes. The second option may have control plane scaling issues.
第一个选项有一个重要的数据平面扩展问题，因为所有复制的数据必须通过同一端口发送并在同一段上携带。因此，解决方案应该为分支LSR提供一种机制，将数据的单个副本发送到多址网络，以到达多个（相邻）下游节点。第二个选项可能存在控制平面缩放问题。
The MPLS and GMPLS MIB modules MUST be enhanced to provide P2MP TE LSP management in line with whatever signaling solutions are developed.
必须增强MPLS和GMPLS MIB模块，以便根据开发的任何信令解决方案提供P2MP TE LSP管理。
In order to facilitate correct management, P2MP TE LSPs MUST have unique identifiers, since otherwise it is impossible to determine which LSP is being managed.
为了便于正确管理，P2MP TE LSP必须具有唯一标识符，否则无法确定正在管理的LSP。
Further discussions of OAM are out of scope for this document. See [P2MP-OAM] for more details.
关于OAM的进一步讨论超出了本文件的范围。有关更多详细信息，请参见[P2MP-OAM]。
Scalability is a key requirement in P2MP MPLS systems. Solutions MUST be designed to scale well with an increase in the number of any of the following:
可扩展性是P2MP MPLS系统中的一个关键要求。解决方案的设计必须能够随着以下任何一项数量的增加而很好地扩展：
- the number of recipients - the number of egress LSRs - the number of branch LSRs - the number of branches
- 收件人数量-出口LSR数量-分支LSR数量-分支数量
Both scalability of control plane operation (setup, maintenance, modification, and teardown) MUST be considered.
必须考虑控制平面操作的可伸缩性（设置、维护、修改和拆卸）。
Key considerations MUST include:
关键考虑因素必须包括：
- the amount of refresh processing associated with maintaining a P2MP TE LSP. - the amount of protocol state that must be maintained by ingress and transit LSRs along a P2MP tree. - the number of protocol messages required to set up or tear down a P2MP LSP as a function of the number of egress LSRs. - the number of protocol messages required to repair a P2MP LSP after failure or to perform make-before-break. - the amount of protocol information transmitted to manage a P2MP TE LSP (i.e., the message size). - the amount of additional data distributed in potential routing extensions. - the amount of additional control plane processing required in the network to detect whether an add/delete of a new branch is required, and in particular, the amount of processing in steady state when no add/delete is requested - the amount of control plane processing required by the ingress, transit, and egress LSRs to add/delete a branch LSP to/from an existing P2MP LSP.
- 与维护P2MP TE LSP相关的刷新处理量。-必须由入口和传输LSR沿P2MP树维护的协议状态量。-设置或拆除P2MP LSP所需的协议消息数量，作为出口LSR数量的函数。-故障后修复P2MP LSP或在中断前执行接通所需的协议消息数。-为管理P2MP TE LSP而传输的协议信息量（即消息大小）。-潜在路由扩展中分布的附加数据量。-网络中检测是否需要添加/删除新分支所需的额外控制平面处理量，尤其是在不请求添加/删除时稳定状态下的处理量-入口、传输、传输所需的控制平面处理量，和出口lsr，以向现有P2MP LSP添加/删除分支LSP。
It is expected that the applicability of each solution will be evaluated with regards to the aforementioned scalability criteria.
预计将根据上述可扩展性标准评估每个解决方案的适用性。
In order to achieve the best solution for the problem space, it is helpful to clarify the boundaries for P2MP TE LSPs.
为了获得问题空间的最佳解决方案，有助于澄清P2MP TE LSP的边界。
- Number of egress LSRs.
- 出口LSR的数量。
A scaling bound is placed on the solution mechanism such that a P2MP TE LSP MUST reduce to similar scaling properties as a P2P LSP when the number of egress LSRs reduces to one. That is, establishing a P2MP TE LSP to a single egress LSR should cost approximately as much as establishing a P2P LSP.
在解决方案机制上设置缩放边界，使得当出口lsr的数量减少到一个时，P2MP TE LSP必须减少到与P2P LSP类似的缩放属性。也就是说，建立到单个出口LSR的P2MP TE LSP的成本应该与建立P2P LSP的成本大致相同。
It is important to classify the issues of scaling within the context of traffic engineering. It is anticipated that the initial deployments of P2MP TE LSPs will be limited to a maximum of around a hundred egress LSRs, but that within five years deployments may increase this to several hundred, and that future deployments may require significantly larger numbers.
在交通工程的背景下对缩放问题进行分类是很重要的。预计P2MP TE LSP的初始部署将限制在最多100个出口LSR左右，但在五年内部署可能会增加到数百个，未来部署可能需要更多数量。
An acceptable upper bound for a solution, therefore, is one that scales linearly with the number of egress LSRs. It is expected that solutions will scale better than linearly.
因此，解决方案的可接受上限是与出口LSR数量成线性比例的上限。预计解决方案的可扩展性将优于线性。
Solutions that scale worse than linearly (that is, exponentially or polynomially) are not acceptable whatever the number of egress LSRs they could support.
无论可以支持多少个出口LSR，比线性（即指数或多项式）更糟糕的解决方案都是不可接受的。
- Number of branch LSRs.
- 分支LSR的数量。
Solutions MUST support all possibilities from one extreme of a single branch LSR that forks to all leaves on a separate branch, to the greatest number of branch LSRs which is (n-1) for n egress LSRs. Assumptions MUST NOT be made in the solution regarding which topology is more common, and the solution MUST be designed to ensure scalability in all topologies.
解决方案必须支持所有可能的情况，从分叉到独立分支上所有叶的单个分支LSR的一个极端，到n个出口LSR的最大分支LSR数量（n-1）。在解决方案中不能假设哪种拓扑更常见，解决方案的设计必须确保所有拓扑中的可伸缩性。
- Dynamics of P2MP tree.
- P2MP树的动力学。
Recall that the mechanisms for determining which egress LSRs should be added to an LSP and for adding and removing egress LSRs from that group are out of the scope of this document. Nevertheless, it is useful to understand the expected rates of arrival and departure of egress LSRs, since this can impact the selection of solution techniques.
回想一下，用于确定应将哪些出口LSR添加到LSP以及用于从该组中添加和移除出口LSR的机制不在本文档的范围内。然而，了解出口LSR的预期到达率和离开率是有用的，因为这会影响解决方案技术的选择。
Again, this document is limited to traffic engineering, and in this model the rate of change of LSP egress LSRs may be expected to be lower than the rate of change of recipients in an IP multicast group.
同样，本文档仅限于流量工程，并且在该模型中，LSP出口lsr的变化率可能预期低于IP多播组中的接收者的变化率。
Although the absolute number of egress LSRs coming and going is the important element for determining the scalability of a solution, note that a percentage may be a more comprehensible measure, but that this is not as significant for LSPs with a small number of recipients.
尽管进出的出口LSR的绝对数量是确定解决方案可伸缩性的重要因素，但请注意，百分比可能是一个更容易理解的衡量标准，但这对于具有少量接收者的LSP来说并不重要。
A working figure for an established P2MP TE LSP is less than 10% churn per day; that is, a relatively slow rate of churn.
已建立的P2MP TE LSP的工作数据低于每天10%的客户流失率；也就是说，流失率相对较低。
We could say that a P2MP LSP would be shared by multiple multicast groups, so the dynamics of the P2MP LSP would be relatively small.
我们可以说P2MP LSP将由多个多播组共享，因此P2MP LSP的动态相对较小。
Solutions MUST optimize for such relatively low rates of change and are not required to optimize for significantly higher rates of change.
解决方案必须针对相对较低的变化率进行优化，而不需要针对显著较高的变化率进行优化。
- Rate of change within the network.
- 网络内的变化率。
It is also important to understand the scaling with regard to changes within the network. That is, one of the features of a P2MP TE LSP is that it can be robust or protected against network
了解网络内变化的比例也很重要。也就是说，P2MP TE LSP的一个特性是，它可以是健壮的，或者针对网络进行保护
failures, and it can be re-optimized to take advantage of newly available network resources.
它可以重新优化以利用新的可用网络资源。
It is more important that a solution be optimized for scaling with respect to recovery and re-optimization of the LSP than for change in the egress LSRs, because P2MP is used as a TE tool.
与出口LSR的变化相比，针对LSP的恢复和重新优化的缩放优化解决方案更为重要，因为P2MP用作TE工具。
The solution MUST follow this distinction and optimize accordingly.
解决方案必须遵循这一区别，并进行相应的优化。
It SHOULD be an aim of any P2MP solution to offer as much backward compatibility as possible. An ideal that is probably impossible to achieve would be to offer P2MP services across legacy MPLS networks without any change to any LSR in the network.
任何P2MP解决方案的目标都应该是提供尽可能多的向后兼容性。一个可能不可能实现的理想是在不改变网络中任何LSR的情况下，跨传统MPLS网络提供P2MP服务。
If this ideal cannot be achieved, the aim SHOULD be to use legacy nodes as both transit non-branch LSRs and egress LSRs.
如果无法实现这一理想，那么目标应该是将遗留节点用作传输非分支LSR和出口LSR。
It is a further requirement for the solution that any LSR that implements the solution SHALL NOT be prohibited by that act from supporting P2P TE LSPs using existing signaling mechanisms. That is, unless doing so is administratively prohibited, P2P TE LSPs MUST be supported through a P2MP network.
该解决方案的另一个要求是，该法案不得禁止实现该解决方案的任何LSR使用现有信令机制支持P2P TE LSP。也就是说，除非管理禁止这样做，否则必须通过P2MP网络支持P2P TE lsp。
Also, it is a requirement that P2MP TE LSPs MUST be able to coexist with IP unicast and IP multicast networks.
此外，还要求P2MP TE LSP必须能够与IP单播和IP多播网络共存。
The requirement for P2MP services for non-packet switch interfaces is similar to that for Packet-Switch Capable (PSC) interfaces. Therefore, it is a requirement that reasonable attempts must be made to make all the features/mechanisms (and protocol extensions) that will be defined to provide MPLS P2MP TE LSPs equally applicable to P2MP PSC and non-PSC TE-LSPs. If the requirements of non-PSC networks over-complicate the PSC solution a decision may be taken to separate the solutions.
非分组交换接口对P2MP服务的要求与支持分组交换（PSC）接口的要求类似。因此，要求必须做出合理的尝试，使所有功能/机制（和协议扩展）能够定义为提供MPLS P2MP TE LSP，使其同样适用于P2MP PSC和非PSC TE LSP。如果非PSC网络的要求使PSC解决方案复杂化，则可决定将解决方案分开。
Solutions for MPLS P2MP TE-LSPs, when applied to GMPLS P2MP PSC or non-PSC TE-LSPs, MUST be compatible with the other features of GMPLS including:
MPLS P2MP TE LSP解决方案应用于GMPLS P2MP PSC或非PSC TE LSP时，必须与GMPLS的其他功能兼容，包括：
- control and data plane separation; - full support of numbered and unnumbered TE links; - use of the arbitrary labels and labels for specific technologies, as well as negotiation of labels, where necessary, to support limited label processing and swapping capabilities;
- 控制和数据平面分离；-完全支持编号和未编号的TE链接；-使用任意标签和特定技术的标签，以及在必要时协商标签，以支持有限的标签处理和交换能力；
- the ability to apply external control to the labels selected on each hop of the LSP, and to control the next hop label/port/interface for data after it reaches the egress LSR; - support for graceful and alarm-free enablement and termination of LSPs; - full support for protection including link-level protection, end-to-end protection, and segment protection; - the ability to teardown an LSP from a downstream LSR, in particular, from the egress LSR; - handling of Graceful Deletion procedures; and - support for failure and restart or reconnection of the control plane without any disruption of the data plane.
- 对LSP的每个跃点上选择的标签应用外部控制的能力，以及在数据到达出口LSR后控制下一个跃点标签/端口/接口的能力；-支持优雅且无警报的LSP启用和终止；-全面支持保护，包括链路级保护、端到端保护和段保护；-从下游LSR，特别是从出口LSR拆卸LSP的能力；-处理删除程序；和-在不中断数据平面的情况下支持控制平面的故障、重启或重新连接。
In addition, since non-PSC TE-LSPs may have to be processed in environments where the "P2MP capability" could be limited, specific constraints may also apply during the P2MP TE Path computation. Being technology specific, these constraints are outside the scope of this document. However, technology-independent constraints (i.e., constraints that are applicable independently of the LSP class) SHOULD be allowed during P2MP TE LSP message processing. It has to be emphasized that path computation and management techniques shall be as close as possible to those being used for PSC P2P TE LSPs and P2MP TE LSPs.
此外，由于非PSC TE LSP可能必须在“P2MP能力”可能受到限制的环境中处理，因此在P2MP TE路径计算期间也可能应用特定约束。由于技术的特殊性，这些限制超出了本文档的范围。但是，在P2MP TE LSP消息处理过程中，应允许技术独立约束（即独立于LSP类适用的约束）。必须强调的是，路径计算和管理技术应尽可能接近用于PSC P2P TE LSP和P2MP TE LSP的技术。
P2MP solutions SHOULD support crankback requirements as defined in [CRANKBACK]. In particular, they SHOULD provide sufficient information to a branch LSR from downstream LSRs to allow the branch LSR to re-route a sub-LSP around any failures or problems in the network.
P2MP解决方案应支持[回退]中定义的回退要求。特别是，它们应该从下游LSR向分支LSR提供足够的信息，以允许分支LSR围绕网络中的任何故障或问题重新路由子LSP。
This requirements document does not define any protocol extensions and does not, therefore, make any changes to any security models.
本需求文档未定义任何协议扩展，因此未对任何安全模型进行任何更改。
It is a requirement that any P2MP solution developed to meet some or all of the requirements expressed in this document MUST include mechanisms to enable the secure establishment and management of P2MP MPLS-TE LSPs. This includes, but is not limited to:
要求为满足本文件所述部分或全部要求而开发的任何P2MP解决方案必须包括能够安全建立和管理P2MP MPLS-TE LSP的机制。这包括但不限于：
- mechanisms to ensure that the ingress LSR of a P2MP LSP is identified; - mechanisms to ensure that communicating signaling entities can verify each other's identities; - mechanisms to ensure that control plane messages are protected against spoofing and tampering;
- 确保识别P2MP LSP入口LSR的机制；-确保通信信令实体能够验证彼此身份的机制；-确保控制平面消息免受欺骗和篡改的机制；
- mechanisms to ensure that unauthorized leaves or branches are not added to the P2MP LSP; and - mechanisms to protect signaling messages from snooping.
- 确保未经授权的叶或分支不会添加到P2MP LSP的机制；和-保护信令消息免受窥探的机制。
Note that P2MP signaling mechanisms built on P2P RSVP-TE signaling are likely to inherit all the security techniques and problems associated with RSVP-TE. These problems may be exacerbated in P2MP situations where security relationships may need to maintained between an ingress LSR and multiple egress LSRs. Such issues are similar to security issues for IP multicast.
请注意，基于P2P RSVP-TE信令的P2MP信令机制可能继承与RSVP-TE相关的所有安全技术和问题。在P2MP情况下，这些问题可能会加剧，其中可能需要在入口LSR和多个出口LSR之间保持安全关系。这些问题类似于IP多播的安全问题。
It is a requirement that documents offering solutions for P2MP LSPs MUST have detailed security sections.
要求提供P2MP LSP解决方案的文档必须有详细的安全部分。
The authors would like to thank George Swallow, Ichiro Inoue, Dean Cheng, Lou Berger, and Eric Rosen for their review and suggestions.
作者要感谢George Swallow、井上一郎、郑院长、Lou Berger和Eric Rosen的评论和建议。
Thanks to Loa Andersson for his help resolving the final issues in this document and to Harald Alvestrand for a thorough GenArt review.
感谢Loa Andersson帮助解决本文件中的最终问题，并感谢Harald Alvestrand对GenArt的全面审查。
[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月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702]Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.，和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
[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月。
[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月。
[RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols", RFC 3468, February 2003.
[RFC3468]Andersson，L.和G.Swallow，“多协议标签交换（MPLS）工作组关于MPLS信令协议的决定”，RFC 3468，2003年2月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[RFC3564]Le Faucheur，F.和W.Lai，“支持区分服务的MPLS流量工程的要求”，RFC 3564，2003年7月。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Swallow，G.，和A.Atlas，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[STEINER] H. Salama, et al., "Evaluation of Multicast Routing Algorithm for Real-Time Communication on High-Speed Networks," IEEE Journal on Selected Area in Communications, pp.332-345, 1997.
[STEINER]H.Salama等人，“高速网络实时通信中多播路由算法的评估”，《IEEE通信选定领域杂志》，第332-345页，1997年。
[CRANKBACK] A. Farrel, A. Satyanarayana, A. Iwata, N. Fujita, G. Ash, S. Marshall, "Crankback Signaling Extensions for MPLS Signaling", Work in Progress, May 2005.
[回退]A.Farrel，A.Satyanarayana，A.Iwata，N.Fujita，G.Ash，S.Marshall，“MPLS信令的回退信令扩展”，正在进行的工作，2005年5月。
[P2MP-OAM] S. Yasukawa, A. Farrel, D. King, and T. Nadeau, "OAM Requirements for Point-to-Multipoint MPLS Networks", Work in Progress, February 2006.
[P2MP-OAM]S.Yasukawa，A.Farrel，D.King和T.Nadeau，“点对多点MPLS网络的OAM要求”，正在进行的工作，2006年2月。
Editor's Address
编辑地址
Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585, Japan
日本东京武藏町3-Chome-Musashino Shi Midori Cho 3-Chome Yasukawa NTT公司9-11号，东京180-8585
Phone: +81 422 59 4769
EMail: yasukawa.seisho@lab.ntt.co.jp
Phone: +81 422 59 4769
EMail: yasukawa.seisho@lab.ntt.co.jp
Authors' Addresses
作者地址
Dimitri Papadimitriou Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium
迪米特里·帕帕迪米特里奥·阿尔卡特·弗朗西斯·韦伦斯普林1号，B-2018比利时安特卫普
Phone : +32 3 240 8491
EMail: dimitri.papadimitriou@alcatel.be
Phone : +32 3 240 8491
EMail: dimitri.papadimitriou@alcatel.be
JP Vasseur Cisco Systems, Inc. 300 Beaver Brook Road
JP Vasseur Cisco Systems，Inc.海狸溪路300号
Boxborough, MA 01719, USA
美国马萨诸塞州伯斯堡01719
EMail: jpv@cisco.com
EMail: jpv@cisco.com
Yuji Kamite NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo 163-1421, Japan
Yuji Kamite NTT通信公司东京歌剧城3-20-2号楼，新宿，新宿，东京163-1421
EMail: y.kamite@ntt.com
EMail: y.kamite@ntt.com
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089
Rahul Aggarwal Juniper Networks加利福尼亚州桑尼维尔北马蒂尔达大道1194号，邮编94089
EMail: rahul@juniper.net
EMail: rahul@juniper.net
Alan Kullberg Motorola Computer Group 120 Turnpike Rd. Southborough, MA 01772 EMail: alan.kullberg@motorola.com
Alan Kullberg摩托罗拉计算机集团马萨诸塞州南部收费公路120号邮编01772电子邮件：Alan。kullberg@motorola.com
Adrian Farrel Old Dog Consulting
阿德里安·法雷尔老狗咨询公司
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Markus Jork Quarry Technologies 8 New England Executive Park Burlington, MA 01803
马库斯·乔克采石场技术8新英格兰行政公园伯灵顿，马萨诸塞州01803
EMail: mjork@quarrytech.com
EMail: mjork@quarrytech.com
Andrew G. Malis Tellabs 2730 Orchard Parkway San Jose, CA 95134
加利福尼亚州圣何塞市乌节公园路2730号，安德鲁·G·马里斯·特拉伯斯，邮编95134
Phone: +1 408 383 7223
EMail: andy.malis@tellabs.com
Phone: +1 408 383 7223
EMail: andy.malis@tellabs.com
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France
Jean-Louis Le Roux法国电信2号，Pierre Marzin大街22307兰尼昂塞德斯法国
EMail: jeanlouis.leroux@francetelecom.com
EMail: jeanlouis.leroux@francetelecom.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。