Network Working Group R. Aggarwal, Ed.
Request for Comments: 4875 Juniper Networks
Category: Standards Track D. Papadimitriou, Ed.
Alcatel
S. Yasukawa, Ed.
NTT
May 2007
Network Working Group R. Aggarwal, Ed.
Request for Comments: 4875 Juniper Networks
Category: Standards Track D. Papadimitriou, Ed.
Alcatel
S. Yasukawa, Ed.
NTT
May 2007
Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)
资源预留协议的扩展.点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described.
本文档描述了资源预留协议-流量工程（RSVP-TE）的扩展，用于在多协议标签交换（MPLS）和通用MPLS（GMPLS）网络中建立流量工程（TE）点对多点（P2MP）标签交换路径（LSP）。该解决方案依赖于RSVP-TE，而不需要服务提供商核心中的多播路由协议。描述了该解决方案的协议元素和程序。
There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document.
P2MP TE LSP可以有多种应用，如IP多播。此类应用程序如何使用P2MP TE LSP的规范不在本文档范围内。
Table of Contents
目录
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................4
3. Terminology .....................................................4
4. Mechanism .......................................................5
4.1. P2MP Tunnels ...............................................5
4.2. P2MP LSP ...................................................5
4.3. Sub-Groups .................................................5
4.4. S2L Sub-LSPs ...............................................6
4.4.1. Representation of an S2L Sub-LSP ....................6
4.4.2. S2L Sub-LSPs and Path Messages ......................7
4.5. Explicit Routing ...........................................7
5. Path Message ....................................................9
5.1. Path Message Format ........................................9
5.2. Path Message Processing ...................................11
5.2.1. Multiple Path Messages .............................11
5.2.2. Multiple S2L Sub-LSPs in One Path Message ..........12
5.2.3. Transit Fragmentation of Path State Information ....14
5.2.4. Control of Branch Fate Sharing .....................15
5.3. Grafting ..................................................15
6. Resv Message ...................................................16
6.1. Resv Message Format .......................................16
6.2. Resv Message Processing ...................................17
6.2.1. Resv Message Throttling ............................18
6.3. Route Recording ...........................................19
6.3.1. RRO Processing .....................................19
6.4. Reservation Style .........................................19
7. PathTear Message ...............................................20
7.1. PathTear Message Format ...................................20
7.2. Pruning ...................................................20
7.2.1. Implicit S2L Sub-LSP Teardown ......................20
7.2.2. Explicit S2L Sub-LSP Teardown ......................21
8. Notify and ResvConf Messages ...................................21
8.1. Notify Messages ...........................................21
8.2. ResvConf Messages .........................................23
9. Refresh Reduction ..............................................24
10. State Management ..............................................24
10.1. Incremental State Update .................................25
10.2. Combining Multiple Path Messages .........................25
11. Error Processing ..............................................26
11.1. PathErr Messages .........................................27
11.2. ResvErr Messages .........................................27
11.3. Branch Failure Handling ..................................28
12. Admin Status Change ...........................................29
13. Label Allocation on LANs with Multiple Downstream Nodes .......29
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................4
3. Terminology .....................................................4
4. Mechanism .......................................................5
4.1. P2MP Tunnels ...............................................5
4.2. P2MP LSP ...................................................5
4.3. Sub-Groups .................................................5
4.4. S2L Sub-LSPs ...............................................6
4.4.1. Representation of an S2L Sub-LSP ....................6
4.4.2. S2L Sub-LSPs and Path Messages ......................7
4.5. Explicit Routing ...........................................7
5. Path Message ....................................................9
5.1. Path Message Format ........................................9
5.2. Path Message Processing ...................................11
5.2.1. Multiple Path Messages .............................11
5.2.2. Multiple S2L Sub-LSPs in One Path Message ..........12
5.2.3. Transit Fragmentation of Path State Information ....14
5.2.4. Control of Branch Fate Sharing .....................15
5.3. Grafting ..................................................15
6. Resv Message ...................................................16
6.1. Resv Message Format .......................................16
6.2. Resv Message Processing ...................................17
6.2.1. Resv Message Throttling ............................18
6.3. Route Recording ...........................................19
6.3.1. RRO Processing .....................................19
6.4. Reservation Style .........................................19
7. PathTear Message ...............................................20
7.1. PathTear Message Format ...................................20
7.2. Pruning ...................................................20
7.2.1. Implicit S2L Sub-LSP Teardown ......................20
7.2.2. Explicit S2L Sub-LSP Teardown ......................21
8. Notify and ResvConf Messages ...................................21
8.1. Notify Messages ...........................................21
8.2. ResvConf Messages .........................................23
9. Refresh Reduction ..............................................24
10. State Management ..............................................24
10.1. Incremental State Update .................................25
10.2. Combining Multiple Path Messages .........................25
11. Error Processing ..............................................26
11.1. PathErr Messages .........................................27
11.2. ResvErr Messages .........................................27
11.3. Branch Failure Handling ..................................28
12. Admin Status Change ...........................................29
13. Label Allocation on LANs with Multiple Downstream Nodes .......29
14. P2MP LSP and Sub-LSP Re-Optimization ..........................29
14.1. Make-before-Break ........................................29
14.2. Sub-Group-Based Re-Optimization ..........................29
15. Fast Reroute ..................................................30
15.1. Facility Backup ..........................................31
15.1.1. Link Protection ...................................31
15.1.2. Node Protection ...................................31
15.2. One-to-One Backup ........................................32
16. Support for LSRs That Are Not P2MP Capable ....................33
17. Reduction in Control Plane Processing with LSP Hierarchy ......34
18. P2MP LSP Re-Merging and Cross-Over ............................35
18.1. Procedures ...............................................36
18.1.1. Re-Merge Procedures ...............................36
19. New and Updated Message Objects ...............................39
19.1. SESSION Object ...........................................39
19.1.1. P2MP LSP Tunnel IPv4 SESSION Object ...............39
19.1.2. P2MP LSP Tunnel IPv6 SESSION Object ...............40
19.2. SENDER_TEMPLATE Object ...................................40
19.2.1. P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object .......41
19.2.2. P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object .......42
19.3. S2L_SUB_LSP Object .......................................43
19.3.1. S2L_SUB_LSP IPv4 Object ...........................43
19.3.2. S2L_SUB_LSP IPv6 Object ...........................43
19.4. FILTER_SPEC Object .......................................43
19.4.1. P2MP LSP_IPv4 FILTER_SPEC Object ..................43
19.4.2. P2MP LSP_IPv6 FILTER_SPEC Object ..................44
19.5. P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) ..............44
19.6. P2MP SECONDARY_RECORD_ROUTE Object (SRRO) ................44
20. IANA Considerations ...........................................44
20.1. New Class Numbers ........................................44
20.2. New Class Types ..........................................44
20.3. New Error Values .........................................45
20.4. LSP Attributes Flags .....................................46
21. Security Considerations .......................................46
22. Acknowledgements ..............................................47
23. References ....................................................47
23.1. Normative References .....................................47
23.2. Informative References ...................................48
Appendix A. Example of P2MP LSP Setup .............................49
Appendix B. Contributors ..........................................50
14. P2MP LSP and Sub-LSP Re-Optimization ..........................29
14.1. Make-before-Break ........................................29
14.2. Sub-Group-Based Re-Optimization ..........................29
15. Fast Reroute ..................................................30
15.1. Facility Backup ..........................................31
15.1.1. Link Protection ...................................31
15.1.2. Node Protection ...................................31
15.2. One-to-One Backup ........................................32
16. Support for LSRs That Are Not P2MP Capable ....................33
17. Reduction in Control Plane Processing with LSP Hierarchy ......34
18. P2MP LSP Re-Merging and Cross-Over ............................35
18.1. Procedures ...............................................36
18.1.1. Re-Merge Procedures ...............................36
19. New and Updated Message Objects ...............................39
19.1. SESSION Object ...........................................39
19.1.1. P2MP LSP Tunnel IPv4 SESSION Object ...............39
19.1.2. P2MP LSP Tunnel IPv6 SESSION Object ...............40
19.2. SENDER_TEMPLATE Object ...................................40
19.2.1. P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object .......41
19.2.2. P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object .......42
19.3. S2L_SUB_LSP Object .......................................43
19.3.1. S2L_SUB_LSP IPv4 Object ...........................43
19.3.2. S2L_SUB_LSP IPv6 Object ...........................43
19.4. FILTER_SPEC Object .......................................43
19.4.1. P2MP LSP_IPv4 FILTER_SPEC Object ..................43
19.4.2. P2MP LSP_IPv6 FILTER_SPEC Object ..................44
19.5. P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) ..............44
19.6. P2MP SECONDARY_RECORD_ROUTE Object (SRRO) ................44
20. IANA Considerations ...........................................44
20.1. New Class Numbers ........................................44
20.2. New Class Types ..........................................44
20.3. New Error Values .........................................45
20.4. LSP Attributes Flags .....................................46
21. Security Considerations .......................................46
22. Acknowledgements ..............................................47
23. References ....................................................47
23.1. Normative References .....................................47
23.2. Informative References ...................................48
Appendix A. Example of P2MP LSP Setup .............................49
Appendix B. Contributors ..........................................50
[RFC3209] defines a mechanism for setting up point-to-point (P2P) Traffic Engineered (TE) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. [RFC3473] defines extensions to [RFC3209] for setting up P2P TE LSPs in Generalized MPLS (GMPLS) networks. However these specifications do not provide a mechanism for building point-to-multipoint (P2MP) TE LSPs.
[RFC3209]定义了一种机制，用于在多协议标签交换（MPLS）网络中设置点对点（P2P）流量工程（TE）标签交换路径（LSP）。[RFC3473]定义了[RFC3209]的扩展，用于在通用MPLS（GMPLS）网络中设置P2P TE LSP。然而，这些规范并未提供构建点对多点（P2MP）TE LSP的机制。
This document defines extensions to the RSVP-TE protocol ([RFC3209] and [RFC3473]) to support P2MP TE LSPs satisfying the set of requirements described in [RFC4461].
本文件定义了RSVP-TE协议（[RFC3209]和[RFC3473]）的扩展，以支持满足[RFC4461]中所述要求的P2MP TE LSP。
This document relies on the semantics of the Resource Reservation Protocol (RSVP) that RSVP-TE inherits for building P2MP LSPs. A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between the ingress and egress LSRs and are appropriately combined by the branch LSRs using RSVP semantics to result in a P2MP TE LSP. One Path message may signal one or multiple S2L sub-LSPs for a single P2MP LSP. Hence the S2L sub-LSPs belonging to a P2MP LSP can be signaled using one Path message or split across multiple Path messages.
本文档依赖于RSVP-TE为构建P2MP LSP而继承的资源保留协议（RSVP）的语义。P2MP LSP由多个源到叶（S2L）子LSP组成。这些S2L子LSP设置在入口和出口lsr之间，并由分支lsr使用RSVP语义适当组合，以产生P2MP TE LSP。一条路径消息可以向单个P2MP LSP的一个或多个S2L子LSP发送信号。因此，属于P2MP LSP的S2L子LSP可以使用一条路径消息来发信号，或者在多条路径消息之间分割。
There are various applications for P2MP TE LSPs and the signaling techniques described in this document can be used, sometimes in combination with other techniques, to support different applications.
P2MP TE LSP有各种应用，本文档中描述的信令技术可用于支持不同的应用，有时可与其他技术结合使用。
Specification of how applications will use P2MP TE LSPs and how the paths of P2MP TE LSPs are computed is outside the scope of this document.
应用程序如何使用P2MP TE LSP以及如何计算P2MP TE 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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document uses terminologies defined in [RFC2205], [RFC3031], [RFC3209], [RFC3473], [RFC4090], and [RFC4461].
本文件使用[RFC2205]、[RFC3031]、[RFC3209]、[RFC3473]、[RFC4090]和[RFC4461]中定义的术语。
This document describes a solution that optimizes data replication by allowing non-ingress nodes in the network to be replication/branch nodes. A branch node is an LSR that replicates the incoming data on to one or more outgoing interfaces. The solution relies on RSVP-TE in the network for setting up a P2MP TE LSP.
本文档描述了一种通过允许网络中的非入口节点成为复制/分支节点来优化数据复制的解决方案。分支节点是将传入数据复制到一个或多个传出接口上的LSR。该解决方案依赖于网络中的RSVP-TE来设置P2MP TE LSP。
The P2MP TE LSP is set up by associating multiple S2L sub-LSPs and relying on data replication at branch nodes. This is described further in the following sub-sections by describing P2MP tunnels and how they relate to S2L sub-LSPs.
P2MP TE LSP是通过关联多个S2L子LSP并依靠分支节点上的数据复制来建立的。以下小节将通过描述P2MP隧道及其与S2L子LSP的关系对其进行进一步描述。
The defining feature of a P2MP TE LSP is the action required at branch nodes where data replication occurs. Incoming MPLS labeled data is replicated to outgoing interfaces which may use different labels for the data.
P2MP TE LSP的定义特性是发生数据复制的分支节点所需的操作。传入的MPLS标记数据被复制到传出接口，这些接口可能会对数据使用不同的标签。
A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is identified by a P2MP SESSION object. This object contains the identifier of the P2MP Session, which includes the P2MP Identifier (P2MP ID), a tunnel Identifier (Tunnel ID), and an extended tunnel identifier (Extended Tunnel ID). The P2MP ID is a four-octet number and is unique within the scope of the ingress LSR.
P2MP TE隧道包括一个或多个P2MP LSP。P2MP TE隧道由P2MP会话对象标识。此对象包含P2MP会话的标识符，其中包括P2MP标识符（P2MP ID）、隧道标识符（隧道ID）和扩展隧道标识符（扩展隧道ID）。P2MP ID是一个四个八位组的数字，在入口LSR的范围内是唯一的。
The <P2MP ID, Tunnel ID, Extended Tunnel ID> tuple provides an identifier for the set of destinations of the P2MP TE Tunnel.
<P2MP ID，Tunnel ID，Extended Tunnel ID>元组为P2MP TE隧道的目的地集提供标识符。
The fields of the P2MP SESSION object are identical to those of the SESSION object defined in [RFC3209] except that the Tunnel Endpoint Address field is replaced by the P2MP ID field. The P2MP SESSION object is defined in section 19.1
P2MP会话对象的字段与[RFC3209]中定义的会话对象的字段相同，只是隧道端点地址字段替换为P2MP ID字段。P2MP会话对象在第19.1节中定义
A P2MP LSP is identified by the combination of the P2MP ID, Tunnel ID, and Extended Tunnel ID that are part of the P2MP SESSION object, and the tunnel sender address and LSP ID fields of the P2MP SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is defined in section 19.2.
P2MP LSP由P2MP会话对象中的P2MP ID、隧道ID和扩展隧道ID以及P2MP发送者\模板对象的隧道发送者地址和LSP ID字段的组合来标识。第19.2节定义了新的P2MP SENDER_模板对象。
As with all other RSVP controlled LSPs, P2MP LSP state is managed using RSVP messages. While the use of RSVP messages is the same, P2MP LSP state differs from P2P LSP state in a number of ways. A
与所有其他RSVP控制的LSP一样，P2MP LSP状态使用RSVP消息进行管理。虽然RSVP消息的使用是相同的，但P2MP LSP状态在许多方面不同于P2P LSP状态。A.
P2MP LSP comprises multiple S2L Sub-LSPs, and as a result of this, it may not be possible to represent full state in a single IP packet. It must also be possible to efficiently add and remove endpoints to and from P2MP TE LSPs. An additional issue is that the P2MP LSP must also handle the state "re-merge" problem, see [RFC4461] and section 18.
P2MP LSP包括多个S2L子LSP，因此，可能无法在单个IP分组中表示完整状态。还必须能够有效地向P2MP TE LSP添加端点和从P2MP TE LSP中删除端点。另一个问题是P2MP LSP还必须处理状态“重新合并”问题，请参见[RFC4461]和第18节。
These differences in P2MP state are addressed through the addition of a sub-group identifier (Sub-Group ID) and sub-group originator (Sub-Group Originator ID) to the SENDER_TEMPLATE and FILTER_SPEC objects. Taken together, the Sub-Group ID and Sub-Group Originator ID are referred to as the Sub-Group fields.
P2MP状态中的这些差异通过向发送者模板和过滤器规范对象添加子组标识符（子组ID）和子组发起人（子组发起人ID）来解决。总之，子组ID和子组发起人ID被称为子组字段。
The Sub-Group fields, together with the rest of the SENDER_TEMPLATE and SESSION objects, are used to represent a portion of a P2MP LSP's state. This portion of a P2MP LSP's state refers only to signaling state and not data plane replication or branching. For example, it is possible for a node to "branch" signaling state for a P2MP LSP, but to not branch the data associated with the P2MP LSP. Typical applications for generation and use of multiple sub-groups are (1) addition of an egress and (2) semantic fragmentation to ensure that a Path message remains within a single IP packet.
子组字段以及发送方模板和会话对象的其余部分用于表示P2MP LSP状态的一部分。P2MP LSP状态的这一部分仅指信令状态，而不是数据平面复制或分支。例如，节点可以“分支”P2MP LSP的信令状态，但不分支与P2MP LSP相关联的数据。生成和使用多个子组的典型应用是（1）添加出口和（2）语义分段，以确保路径消息保留在单个IP数据包中。
A P2MP LSP is constituted of one or more S2L sub-LSPs.
P2MP LSP由一个或多个S2L子LSP组成。
An S2L sub-LSP exists within the context of a P2MP LSP. Thus, it is identified by the P2MP ID, Tunnel ID, and Extended Tunnel ID that are part of the P2MP SESSION, the tunnel sender address and LSP ID fields of the P2MP SENDER_TEMPLATE object, and the S2L sub-LSP destination address that is part of the S2L_SUB_LSP object. The S2L_SUB_LSP object is defined in section 19.3.
S2L子LSP存在于P2MP LSP的上下文中。因此，它由作为P2MP会话一部分的P2MP ID、隧道ID和扩展隧道ID、P2MP发送者_模板对象的隧道发送者地址和LSP ID字段以及作为S2L_子_LSP对象一部分的S2L子LSP目的地地址来标识。S2L_SUB_LSP对象在第19.3节中定义。
An EXPLICIT_ROUTE Object (ERO) or P2MP_SECONDARY_EXPLICIT_ROUTE Object (SERO) is used to optionally specify the explicit route of a S2L sub-LSP. Each ERO or SERO that is signaled corresponds to a particular S2L_SUB_LSP object. Details of explicit route encoding are specified in section 4.5. The SECONDARY_EXPLICIT_ROUTE Object is defined in [RFC4873], a new P2MP SECONDARY_EXPLICIT_ROUTE Object C-type is defined in section 19.5, and a matching P2MP_SECONDARY_RECORD_ROUTE Object C-type is defined in section 19.6.
显式路由对象（ERO）或P2MP次显式路由对象（SERO）用于可选地指定S2L子LSP的显式路由。发出信号的每个ERO或SERO对应于特定的S2L_SUB_LSP对象。第4.5节规定了显式路由编码的详细信息。[RFC4873]中定义了次显式路由对象，第19.5节定义了新的P2MP次显式路由对象C类型，第19.6节定义了匹配的P2MP次显式记录路由对象C类型。
The mechanism in this document allows a P2MP LSP to be signaled using one or more Path messages. Each Path message may signal one or more S2L sub-LSPs. Support for multiple Path messages is desirable as one Path message may not be large enough to contain all the S2L sub-LSPs; and they also allow separate manipulation of sub-trees of the P2MP LSP. The reason for allowing a single Path message to signal multiple S2L sub-LSPs is to optimize the number of control messages needed to set up a P2MP LSP.
本文档中的机制允许使用一个或多个Path消息向P2MP LSP发送信号。每个路径消息可以向一个或多个S2L子lsp发送信号。支持多路径消息是可取的，因为一条路径消息可能不足以包含所有S2L子lsp；它们还允许单独操纵P2MP LSP的子树。允许单路径消息向多个S2L子LSP发送信号的原因是优化设置P2MP LSP所需的控制消息数量。
When a Path message signals a single S2L sub-LSP (that is, the Path message is only targeting a single leaf in the P2MP tree), the EXPLICIT_ROUTE object encodes the path to the egress LSR. The Path message also includes the S2L_SUB_LSP object for the S2L sub-LSP being signaled. The < [<EXPLICIT_ROUTE>], <S2L_SUB_LSP> > tuple represents the S2L sub-LSP and is referred to as the sub-LSP descriptor. The absence of the ERO should be interpreted as requiring hop-by-hop routing for the sub-LSP based on the S2L sub-LSP destination address field of the S2L_SUB_LSP object.
当路径消息向单个S2L子LSP发送信号时（即，路径消息仅针对P2MP树中的单个叶），显式路由对象对到出口LSR的路径进行编码。路径消息还包括用于被发信号的S2L子LSP的S2L_子LSP对象。<S2L\u SUB\u LSP>>元组表示S2L子LSP，称为子LSP描述符。ERO的缺失应解释为要求基于S2L_sub_LSP对象的S2L sub LSP目的地地址字段逐跳路由子LSP。
When a Path message signals multiple S2L sub-LSPs, the path of the first S2L sub-LSP to the egress LSR is encoded in the ERO. The first S2L sub-LSP is the one that corresponds to the first S2L_SUB_LSP object in the Path message. The S2L sub-LSPs corresponding to the S2L_SUB_LSP objects that follow are termed as subsequent S2L sub-LSPs.
当路径消息向多个S2L子LSP发送信号时，第一S2L子LSP到出口LSR的路径在ERO中编码。第一S2L子LSP是对应于路径消息中的第一S2L_子_LSP对象的子LSP。与随后的S2L_sub_LSP对象相对应的S2L子LSP被称为后续S2L子LSP。
The path of each subsequent S2L sub-LSP is encoded in a P2MP_SECONDARY_EXPLICIT_ROUTE object (SERO). The format of the SERO is the same as an ERO (as defined in [RFC3209] and [RFC3473]). Each subsequent S2L sub-LSP is represented by tuples of the form < [<P2MP SECONDARY_EXPLICIT_ROUTE>], <S2L_SUB_LSP> >. An SERO for a particular S2L sub-LSP includes only the path from a branch LSR to the egress LSR of that S2L sub-LSP. The branch MUST appear as an explicit hop in the ERO or some other SERO. The absence of an SERO should be interpreted as requiring hop-by-hop routing for that S2L sub-LSP. Note that the destination address is carried in the S2L sub-LSP object. The encoding of the SERO and S2L_SUB_LSP object is described in detail in section 19.
每个后续S2L子LSP的路径编码在P2MP_次要_显式_路由对象（SERO）中。SERO的格式与ERO相同（定义见[RFC3209]和[RFC3473]）。每个后续S2L子LSP由以下形式的元组表示<[<P2MP SECONDARY\u EXPLICIT\u ROUTE>]，<S2L\u sub\u LSP>>。特定S2L子LSP的SERO仅包括从分支LSR到该S2L子LSP的出口LSR的路径。分支必须在ERO或其他血清中显示为显式跃点。不存在SERO应解释为需要针对该S2L子LSP逐跳路由。注意，在S2L子LSP对象中携带目的地地址。第19节详细描述了SERO和S2L_SUB_LSP对象的编码。
In order to avoid the potential repetition of path information for the parts of S2L sub-LSPs that share hops, this information is deduced from the explicit routes of other S2L sub-LSPs using explicit route compression in SEROs.
为了避免共享跳数的部分S2L子LSP的路径信息的潜在重复，该信息是使用SEROs中的显式路由压缩从其他S2L子LSP的显式路由推导出来的。
A
|
|
B
|
|
C----D----E
| | |
| | |
F G H-------I
| |\ |
| | \ |
J K L M
| | | |
| | | |
N O P Q--R
A
|
|
B
|
|
C----D----E
| | |
| | |
F G H-------I
| |\ |
| | \ |
J K L M
| | | |
| | | |
N O P Q--R
Figure 1. Explicit Route Compression
图1。显式路由压缩
Figure 1 shows a P2MP LSP with LSR A as the ingress LSR and six egress LSRs: (F, N, O, P, Q and R). When all six S2L sub-LSPs are signaled in one Path message, let us assume that the S2L sub-LSP to LSR F is the first S2L sub-LSP, and the rest are subsequent S2L sub-LSPs. The following encoding is one way for the ingress LSR A to encode the S2L sub-LSP explicit routes using compression:
图1显示了一个P2MP LSP，其中LSR a作为入口LSR，六个出口LSR：（F、N、O、P、Q和R）。当所有六个S2L子LSP在一条路径消息中发信号时，让我们假设S2L子LSP到LSR F是第一个S2L子LSP，其余是后续的S2L子LSP。以下编码是入口LSR A使用压缩编码S2L子LSP显式路由的一种方法：
S2L sub-LSP-F: ERO = {B, E, D, C, F}, <S2L_SUB_LSP> object-F
S2L sub-LSP-N: SERO = {D, G, J, N}, <S2L_SUB_LSP> object-N
S2L sub-LSP-O: SERO = {E, H, K, O}, <S2L_SUB_LSP> object-O
S2L sub-LSP-P: SERO = {H, L, P}, <S2L_SUB_LSP> object-P
S2L sub-LSP-Q: SERO = {H, I, M, Q}, <S2L_SUB_LSP> object-Q
S2L sub-LSP-R: SERO = {Q, R}, <S2L_SUB_LSP> object-R
S2L sub-LSP-F: ERO = {B, E, D, C, F}, <S2L_SUB_LSP> object-F
S2L sub-LSP-N: SERO = {D, G, J, N}, <S2L_SUB_LSP> object-N
S2L sub-LSP-O: SERO = {E, H, K, O}, <S2L_SUB_LSP> object-O
S2L sub-LSP-P: SERO = {H, L, P}, <S2L_SUB_LSP> object-P
S2L sub-LSP-Q: SERO = {H, I, M, Q}, <S2L_SUB_LSP> object-Q
S2L sub-LSP-R: SERO = {Q, R}, <S2L_SUB_LSP> object-R
After LSR E processes the incoming Path message from LSR B it sends a Path message to LSR D with the S2L sub-LSP explicit routes encoded as follows:
在LSR E处理来自LSR B的传入路径消息之后，它向LSR D发送路径消息，其中S2L子LSP显式路由编码如下：
S2L sub-LSP-F: ERO = {D, C, F}, <S2L_SUB_LSP> object-F
S2L sub-LSP-N: SERO = {D, G, J, N}, <S2L_SUB_LSP> object-N
S2L sub-LSP-F: ERO = {D, C, F}, <S2L_SUB_LSP> object-F
S2L sub-LSP-N: SERO = {D, G, J, N}, <S2L_SUB_LSP> object-N
LSR E also sends a Path message to LSR H, and the following is one way to encode the S2L sub-LSP explicit routes using compression:
LSR E还向LSR H发送路径消息，以下是使用压缩对S2L子LSP显式路由进行编码的一种方法：
S2L sub-LSP-O: ERO = {H, K, O}, <S2L_SUB_LSP> object-O
S2L sub-LSP-P: SERO = {H, L, P}, S2L_SUB_LSP object-P
S2L sub-LSP-Q: SERO = {H, I, M, Q}, <S2L_SUB_LSP> object-Q
S2L sub-LSP-R: SERO = {Q, R}, <S2L_SUB_LSP> object-R
S2L sub-LSP-O: ERO = {H, K, O}, <S2L_SUB_LSP> object-O
S2L sub-LSP-P: SERO = {H, L, P}, S2L_SUB_LSP object-P
S2L sub-LSP-Q: SERO = {H, I, M, Q}, <S2L_SUB_LSP> object-Q
S2L sub-LSP-R: SERO = {Q, R}, <S2L_SUB_LSP> object-R
After LSR H processes the incoming Path message from E, it sends a Path message to LSR K, LSR L, and LSR I. The encoding for the Path message to LSR K is as follows:
LSR H处理来自E的传入路径消息后，向LSR K、LSR L和LSR I发送路径消息。向LSR K发送路径消息的编码如下：
S2L sub-LSP-O: ERO = {K, O}, <S2L_SUB_LSP> object-O
S2L sub-LSP-O: ERO = {K, O}, <S2L_SUB_LSP> object-O
The encoding of the Path message sent by LSR H to LSR L is as follows:
LSR H发送到LSR L的路径消息的编码如下：
S2L sub-LSP-P: ERO = {L, P}, <S2L_SUB_LSP> object-P
S2L sub-LSP-P: ERO = {L, P}, <S2L_SUB_LSP> object-P
The following encoding is one way for LSR H to encode the S2L sub-LSP explicit routes in the Path message sent to LSR I:
以下编码是LSR H对发送到LSR I的路径消息中的S2L子LSP显式路由进行编码的一种方法：
S2L sub-LSP-Q: ERO = {I, M, Q}, <S2L_SUB_LSP> object-Q
S2L sub-LSP-R: SERO = {Q, R}, <S2L_SUB_LSP> object-R
S2L sub-LSP-Q: ERO = {I, M, Q}, <S2L_SUB_LSP> object-Q
S2L sub-LSP-R: SERO = {Q, R}, <S2L_SUB_LSP> object-R
The explicit route encodings in the Path messages sent by LSRs D and Q are left as an exercise for the reader.
LSR D和Q发送的路径消息中的显式路由编码留给读取器作为练习。
This compression mechanism reduces the Path message size. It also reduces extra processing that can result if explicit routes are encoded from ingress to egress for each S2L sub-LSP. No assumptions are placed on the ordering of the subsequent S2L sub-LSPs and hence on the ordering of the SEROs in the Path message. All LSRs need to process the ERO corresponding to the first S2L sub-LSP. An LSR needs to process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP only if the first hop in the corresponding SERO is a local address of that LSR. The branch LSR that is the first hop of an SERO propagates the corresponding S2L sub-LSP downstream.
这种压缩机制减少了路径消息的大小。它还减少了对每个S2L子LSP从入口到出口的显式路由进行编码时可能导致的额外处理。没有对后续S2L子LSP的顺序进行假设，因此也没有对Path消息中血清的顺序进行假设。所有LSR都需要处理与第一个S2L子LSP对应的ERO。仅当相应SERO中的第一跳是该LSR的本地地址时，LSR才需要为后续S2L子LSP处理S2L子LSP描述符。作为SERO的第一跳的分支LSR向下游传播相应的S2L子LSP。
This section describes modifications made to the Path message format as specified in [RFC3209] and [RFC3473]. The Path message is enhanced to signal one or more S2L sub-LSPs. This is done by including the S2L sub-LSP descriptor list in the Path message as shown below.
本节描述了对[RFC3209]和[RFC3473]中规定的路径消息格式所做的修改。路径消息被增强以向一个或多个S2L子lsp发送信号。这是通过在路径消息中包括S2L子LSP描述符列表来实现的，如下所示。
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
[<S2L sub-LSP descriptor list>]
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
[<S2L sub-LSP descriptor list>]
The following is the format of the S2L sub-LSP descriptor list.
以下是S2L子LSP描述符列表的格式。
<S2L sub-LSP descriptor list> ::= <S2L sub-LSP descriptor>
[ <S2L sub-LSP descriptor list> ]
<S2L sub-LSP descriptor list> ::= <S2L sub-LSP descriptor>
[ <S2L sub-LSP descriptor list> ]
<S2L sub-LSP descriptor> ::= <S2L_SUB_LSP>
[ <P2MP SECONDARY_EXPLICIT_ROUTE> ]
<S2L sub-LSP descriptor> ::= <S2L_SUB_LSP>
[ <P2MP SECONDARY_EXPLICIT_ROUTE> ]
Each LSR MUST use the common objects in the Path message and the S2L sub-LSP descriptors to process each S2L sub-LSP represented by the S2L_SUB_LSP object and the SECONDARY-/EXPLICIT_ROUTE object combination.
每个LSR必须使用路径消息中的公共对象和S2L子LSP描述符来处理由S2L_子LSP对象和次/显式路由对象组合表示的每个S2L子LSP。
Per the definition of <S2L sub-LSP descriptor>, each S2L_SUB_LSP object MAY be followed by a corresponding SERO. The first S2L_SUB_LSP object is a special case, and its explicit route is specified by the ERO. Therefore, the first S2L_SUB_LSP object SHOULD NOT be followed by an SERO, and if one is present, it MUST be ignored.
根据<S2L sub LSP descriptor>的定义，每个S2L_sub_LSP对象后面可以跟一个对应的SERO。第一个S2L_SUB_LSP对象是一种特殊情况，其显式路由由ERO指定。因此，第一个S2L_SUB_LSP对象后面不应该有SERO，如果有SERO，则必须忽略它。
The RRO in the sender descriptor contains the upstream hops traversed by the Path message and applies to all the S2L sub-LSPs signaled in the Path message.
发送方描述符中的RRO包含路径消息所经过的上行跃点，并应用于路径消息中发出信号的所有S2L子LSP。
An IF_ID RSVP_HOP object MUST be used on links where there is not a one-to-one association of a control channel to a data channel [RFC3471]. An RSVP_HOP object defined in [RFC2205] SHOULD be used otherwise.
如果控制通道与数据通道之间没有一对一的关联，则必须在链路上使用IF_ID RSVP_HOP对象[RFC3471]。否则应使用[RFC2205]中定义的RSVP_-HOP对象。
Path message processing is described in the next section.
路径消息处理将在下一节中介绍。
The ingress LSR initiates the setup of an S2L sub-LSP to each egress LSR that is a destination of the P2MP LSP. Each S2L sub-LSP is associated with the same P2MP LSP using common P2MP SESSION object and <Sender Address, LSP-ID> fields in the P2MP SENDER_TEMPLATE object. Hence, it can be combined with other S2L sub-LSPs to form a P2MP LSP. Another S2L sub-LSP belonging to the same instance of this S2L sub-LSP (i.e., the same P2MP LSP) SHOULD share resources with this S2L sub-LSP. The session corresponding to the P2MP TE tunnel is determined based on the P2MP SESSION object. Each S2L sub-LSP is identified using the S2L_SUB_LSP object. Explicit routing for the S2L sub-LSPs is achieved using the ERO and SEROs.
入口LSR向作为P2MP LSP的目的地的每个出口LSR发起S2L子LSP的设置。每个S2L子LSP使用公共P2MP会话对象和P2MP Sender_模板对象中的<Sender Address，LSP-ID>字段与相同的P2MP LSP相关联。因此，它可以与其他S2L子LSP组合以形成P2MP LSP。属于该S2L子LSP的相同实例的另一S2L子LSP（即，相同P2MP LSP）应与该S2L子LSP共享资源。根据P2MP会话对象确定与P2MP TE隧道对应的会话。使用S2L_sub_LSP对象识别每个S2L子LSP。S2L子LSP的显式路由是使用ERO和SEROs实现的。
As mentioned earlier, it is possible to signal S2L sub-LSPs for a given P2MP LSP in one or more Path messages, and a given Path message can contain one or more S2L sub-LSPs. An LSR that supports RSVP-TE signaled P2MP LSPs MUST be able to receive and process multiple Path messages for the same P2MP LSP and multiple S2L sub-LSPs in one Path message. This implies that such an LSR MUST be able to receive and process all objects listed in section 19.
如前所述，可以在一个或多个路径消息中向给定P2MP LSP的S2L子LSP发送信号，并且给定路径消息可以包含一个或多个S2L子LSP。支持RSVP-TE信号P2MP LSP的LSR必须能够在一条路径消息中接收和处理同一P2MP LSP和多个S2L子LSP的多条路径消息。这意味着此类LSR必须能够接收和处理第19节中列出的所有对象。
As described in section 4, either the < [<EXPLICIT_ROUTE>]
<S2L_SUB_LSP> > or the < [<P2MP SECONDARY_EXPLICIT_ROUTE>]
<S2L_SUB_LSP> > tuple is used to specify an S2L sub-LSP. Multiple
Path messages can be used to signal a P2MP LSP. Each Path message
can signal one or more S2L sub-LSPs. If a Path message contains only
one S2L sub-LSP, each LSR along the S2L sub-LSP follows [RFC3209]
procedures for processing the Path message besides the S2L_SUB_LSP
object processing described in this document.
As described in section 4, either the < [<EXPLICIT_ROUTE>]
<S2L_SUB_LSP> > or the < [<P2MP SECONDARY_EXPLICIT_ROUTE>]
<S2L_SUB_LSP> > tuple is used to specify an S2L sub-LSP. Multiple
Path messages can be used to signal a P2MP LSP. Each Path message
can signal one or more S2L sub-LSPs. If a Path message contains only
one S2L sub-LSP, each LSR along the S2L sub-LSP follows [RFC3209]
procedures for processing the Path message besides the S2L_SUB_LSP
object processing described in this document.
Processing of Path messages containing more than one S2L sub-LSP is described in section 5.2.2.
第5.2.2节描述了包含多个S2L子LSP的路径消息的处理。
An ingress LSR MAY use multiple Path messages for signaling a P2MP LSP. This may be because a single Path message may not be large enough to signal the P2MP LSP. Or it may be that when new leaves are added to the P2MP LSP, they are signaled in a new Path message. Or an ingress LSR MAY choose to break the P2MP tree into separate manageable P2MP trees. These trees share the same root and may share the trunk and certain branches. The scope of this management decomposition of P2MP trees is bounded by a single tree (the P2MP Tree) and multiple trees with a single leaf each (S2L sub-LSPs). Per [RFC4461], a P2MP LSP MUST have consistent attributes across all portions of a tree. This implies that each Path message that is used to signal a P2MP LSP is signaled using the same signaling attributes
入口LSR可使用多路径消息来发信号通知P2MP LSP。这可能是因为单路径消息可能不够大，无法向P2MP LSP发送信号。或者，当新叶添加到P2MP LSP时，它们会在新路径消息中发出信号。或者入口LSR可以选择将P2MP树拆分为单独的可管理P2MP树。这些树共用同一根，可能共用树干和某些树枝。P2MP树的这种管理分解的范围由一棵树（P2MP树）和多棵树（每棵树有一片叶子）（S2L子LSP）限定。根据[RFC4461]，P2MP LSP必须在树的所有部分具有一致的属性。这意味着用于向P2MP LSP发送信号的每个路径消息都使用相同的信号属性发送信号
with the exception of the S2L sub-LSP descriptors and Sub-Group identifier.
S2L子LSP描述符和子组标识符除外。
The resulting sub-LSPs from the different Path messages belonging to the same P2MP LSP SHOULD share labels and resources where they share hops to prevent multiple copies of the data being sent.
来自属于同一P2MP LSP的不同路径消息的结果子LSP应共享标签和资源，以防止发送多个数据副本。
In certain cases, a transit LSR may need to generate multiple Path messages to signal state corresponding to a single received Path message. For instance ERO expansion may result in an overflow of the resultant Path message. In this case, the message can be decomposed into multiple Path messages such that each message carries a subset of the X2L sub-tree carried by the incoming message.
在某些情况下，传输LSR可能需要生成多条路径消息，以向对应于单个接收路径消息的状态发送信号。例如，ERO扩展可能导致结果路径消息溢出。在这种情况下，可以将消息分解为多个路径消息，使得每个消息携带由传入消息携带的X2L子树的子集。
Multiple Path messages generated by an LSR that signal state for the same P2MP LSP are signaled with the same SESSION object and have the same <Source address, LSP-ID> in the SENDER_TEMPLATE object. In order to disambiguate these Path messages, a <Sub-Group Originator ID, Sub- Group ID> tuple is introduced (also referred to as the Sub-Group fields) and encoded in the SENDER_TEMPLATE object. Multiple Path messages generated by an LSR to signal state for the same P2MP LSP have the same Sub-Group Originator ID and have a different sub-Group ID. The Sub-Group Originator ID MUST be set to the TE Router ID of the LSR that originates the Path message. Cases when a transit LSR may change the Sub-Group Originator ID of an incoming Path message are described below. The Sub-Group Originator ID is globally unique. The Sub-Group ID space is specific to the Sub-Group Originator ID.
LSR生成的多路径消息，其信号状态为同一P2MP LSP，用同一会话对象发出信号，并且在发送方模板对象中具有相同的<Source address，LSP-ID>。为了消除这些路径消息的歧义，引入了<Sub-Group-Originator-ID，Sub-Group-ID>元组（也称为子组字段），并在SENDER_-TEMPLATE对象中编码。LSR为同一P2MP LSP生成的多条路径消息的信号状态具有相同的子组发起者ID和不同的子组ID。子组发起者ID必须设置为发起路径消息的LSR的TE路由器ID。传输LSR可能更改传入路径消息的子组发起者ID的情况如下所述。子组发起人ID是全局唯一的。子组ID空间特定于子组发起人ID。
The S2L sub-LSP descriptor list allows the signaling of one or more S2L sub-LSPs in one Path message. Each S2L sub-LSP descriptor describes a single S2L sub-LSP.
S2L子LSP描述符列表允许在一条路径消息中发送一个或多个S2L子LSP的信令。每个S2L子LSP描述符描述单个S2L子LSP。
All LSRs MUST process the ERO corresponding to the first S2L sub-LSP if the ERO is present. If one or more SEROs are present, an ERO MUST be present. The first S2L sub-LSP MUST be propagated in a Path message by each LSR along the explicit route specified by the ERO, if the ERO is present. Else it MUST be propagated using hop-by-hop routing towards the destination identified by the S2L_SUB_LSP object.
如果存在ERO，则所有LSR必须处理与第一个S2L子LSP对应的ERO。如果存在一个或多个血清，则必须存在ERO。如果存在ERO，则每个LSR必须沿ERO指定的显式路由在路径消息中传播第一个S2L子LSP。否则，必须使用逐跳路由将其传播到S2L_SUB_LSP对象标识的目的地。
An LSR MUST process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP as follows:
LSR必须为后续S2L子LSP处理S2L子LSP描述符，如下所示：
If the S2L_SUB_LSP object is followed by an SERO, the LSR MUST check the first hop in the SERO:
如果S2L_SUB_LSP对象后面跟着一个SERO，则LSR必须检查SERO中的第一个跃点：
- If the first hop of the SERO identifies a local address of the LSR, and the LSR is also the egress identified by the S2L_SUB_LSP object, the descriptor MUST NOT be propagated downstream, but the SERO may be used for egress control per [RFC4003].
- 如果SERO的第一跳标识LSR的本地地址，并且LSR也是由S2L_SUB_LSP对象标识的出口，则描述符不得向下游传播，但根据[rfc403]，SERO可用于出口控制。
- If the first hop of the SERO identifies a local address of the LSR, and the LSR is not the egress as identified by the S2L_SUB_LSP object, the S2L sub-LSP descriptor MUST be included in a Path message sent to the next-hop determined from the SERO.
- 如果SERO的第一跳标识LSR的本地地址，并且LSR不是由S2L_SUB_LSP对象标识的出口，则S2L SUB LSP描述符必须包括在发送到根据SERO确定的下一跳的路径消息中。
- If the first hop of the SERO is not a local address of the LSR, the S2L sub-LSP descriptor MUST be included in the Path message sent to the LSR that is the next hop to reach the first hop in the SERO. This next hop is determined by using the ERO or other SEROs that encode the path to the SERO's first hop.
- 如果SERO的第一跳不是LSR的本地地址，则S2L子LSP描述符必须包括在发送到LSR的路径消息中，该路径消息是到达SERO中的第一跳的下一跳。该下一跳通过使用ERO或其他SERO来确定，ERO或其他SERO对SERO第一跳的路径进行编码。
If the S2L_SUB_LSP object is not followed by an SERO, the LSR MUST examine the S2L_SUB_LSP object:
如果S2L_SUB_LSP对象后面没有SERO，则LSR必须检查S2L_SUB_LSP对象：
- If this LSR is the egress as identified by the S2L_SUB_LSP object, the S2L sub-LSP descriptor MUST NOT be propagated downstream.
- 如果该LSR是由S2L_SUB_LSP对象标识的出口，则S2L SUB LSP描述符不得向下游传播。
- If this LSR is not the egress as identified by the S2L_SUB_LSP object, the LSR MUST make a routing decision to determine the next hop towards the egress, and MUST include the S2L sub-LSP descriptor in a Path message sent to the next-hop towards the egress. In this case, the LSR MAY insert an SERO into the S2L sub-LSP descriptor.
- 如果该LSR不是由S2L_SUB_LSP对象标识的出口，则LSR必须作出路由决定以确定朝向出口的下一跳，并且必须在发送到朝向出口的下一跳的路径消息中包括S2L SUB LSP描述符。在这种情况下，LSR可以将SERO插入到S2L子LSP描述符中。
Hence, a branch LSR MUST only propagate the relevant S2L sub-LSP descriptors to each downstream hop. An S2L sub-LSP descriptor list that is propagated on a downstream link MUST only contain those S2L sub-LSPs that are routed using that hop. This processing MAY result in a subsequent S2L sub-LSP in an incoming Path message becoming the first S2L sub-LSP in an outgoing Path message.
因此，分支LSR必须仅将相关的S2L子LSP描述符传播到每个下游跳。在下游链路上传播的S2L子LSP描述符列表必须仅包含使用该跳路由的S2L子LSP。该处理可导致传入路径消息中的后续S2L子LSP成为传出路径消息中的第一S2L子LSP。
Note that if one or more SEROs contain loose hops, expansion of such loose hops MAY result in overflowing the Path message size. section 5.2.3 describes how signaling of the set of S2L sub-LSPs can be split across more than one Path message.
请注意，如果一个或多个sero包含松散跃点，则此类松散跃点的扩展可能会导致路径消息大小溢出。第5.2.3节描述了S2L子LSP集的信令如何跨多条路径消息进行分割。
The RECORD_ROUTE Object (RRO) contains the hops traversed by the Path message and applies to all the S2L sub-LSPs signaled in the Path message. A transit LSR MUST append its address in an incoming RRO and propagate it downstream. A branch LSR MUST form a new RRO for each of the outgoing Path messages by copying the RRO from the
记录路由对象（RRO）包含路径消息所经过的跃点，并应用于路径消息中发出信号的所有S2L子LSP。传输LSR必须将其地址附加到传入的RRO中，并将其传播到下游。分支LSR必须通过从中复制RRO，为每个传出路径消息形成新的RRO
incoming Path message and appending its address. Each such updated RRO MUST be formed using the rules in [RFC3209] (and updated by [RFC3473]), as appropriate.
传入路径消息并附加其地址。必须使用[RFC3209]中的规则（并由[RFC3473]酌情更新）形成每个此类更新的RRO。
If an LSR is unable to support an S2L sub-LSP in a Path message (for example, it is unable to route towards the destination using the SERO), a PathErr message MUST be sent for the impacted S2L sub-LSP, and normal processing of the rest of the P2MP LSP SHOULD continue. The default behavior is that the remainder of the LSP is not impacted (that is, all other branches are allowed to set up) and the failed branches are reported in PathErr messages in which the Path_State_Removed flag MUST NOT be set. However, the ingress LSR may set an LSP Integrity flag to request that if there is a setup failure on any branch, the entire LSP should fail to set up. This is described further in sections 5.2.4 and 11.
如果LSR无法支持Path消息中的S2L子LSP（例如，它无法使用SERO路由到目的地），则必须为受影响的S2L子LSP发送PathErr消息，并且应继续正常处理P2MP LSP的其余部分。默认行为是LSP的其余部分不受影响（即，允许设置所有其他分支），并且在PathErr消息中报告失败的分支，其中不得设置Path_State_Removed标志。然而，入口LSR可设置LSP完整性标志，以请求如果任何分支上存在设置失败，则整个LSP应设置失败。第5.2.4节和第11节对此作了进一步说明。
In certain cases, a transit LSR may need to generate multiple Path messages to signal state corresponding to a single received Path message. For instance, ERO expansion may result in an overflow of the resultant Path message. RSVP [RFC2205] disallows the use of IP fragmentation, and thus IP fragmentation MUST be avoided in this case. In order to achieve this, the multiple Path messages generated by the transit LSR are signaled with the Sub-Group Originator ID set to the TE Router ID of the transit LSR and with a distinct Sub-Group ID for each Path message. Thus, each distinct Path message that is generated by the transit LSR for the P2MP LSP carries a distinct <Sub-Group Originator ID, Sub-Group ID> tuple.
在某些情况下，传输LSR可能需要生成多条路径消息，以向对应于单个接收路径消息的状态发送信号。例如，ERO扩展可能导致结果路径消息溢出。RSVP[RFC2205]不允许使用IP碎片，因此在这种情况下必须避免IP碎片。为了实现这一点，使用设置为传输LSR的TE路由器ID的子组发起者ID和每个路径消息的不同子组ID来通知由传输LSR生成的多路径消息。因此，由传输LSR为P2MP LSP生成的每个不同路径消息携带不同的<Sub-Group Originator ID，Sub-Group ID>元组。
When multiple Path messages are used by an ingress or transit node, each Path message SHOULD be identical with the exception of the S2L sub-LSP related descriptor (e.g., SERO), message and hop information (e.g., INTEGRITY, MESSAGE_ID, and RSVP_HOP), and the Sub-Group fields of the SENDER_TEMPLATE objects. Except when a make-before-break operation is being performed (as specified in section 14.1), the tunnel sender address and LSP ID fields MUST be the same in each message. For transit nodes, they MUST be the same as the values in the received Path message.
当入口或传输节点使用多条路径消息时，除了S2L子LSP相关描述符（例如，SERO）、消息和跃点信息（例如，完整性、消息ID和RSVP跃点）以及发送方模板对象的子组字段外，每条路径消息都应相同。除非执行先通后断操作（如第14.1节所述），否则每条消息中的隧道发送方地址和LSP ID字段必须相同。对于传输节点，它们必须与接收到的路径消息中的值相同。
As described above, one case in which the Sub-Group Originator ID of a received Path message is changed is that of fragmentation of a Path message at a transit node. Another case is when the Sub-Group Originator ID of a received Path message may be changed in the outgoing Path message and set to that of the LSR originating the Path message based on a local policy. For instance, an LSR may decide to
如上所述，改变接收到的路径消息的子组发起方ID的一种情况是在传输节点处对路径消息进行分段的情况。另一种情况是，当接收到的路径消息的子组发起方ID可以在传出路径消息中改变，并且基于本地策略设置为发起路径消息的LSR的子组发起方ID。例如，LSR可能决定
always change the Sub-Group Originator ID while performing ERO expansion. The Sub-Group ID MUST not be changed if the Sub-Group Originator ID is not changed.
执行ERO扩展时，始终更改子组发起人ID。如果子组发起人ID未更改，则不得更改子组ID。
An ingress LSR can control the behavior of an LSP if there is a failure during LSP setup or after an LSP has been established. The default behavior is that only the branches downstream of the failure are not established, but the ingress may request 'LSP integrity' such that any failure anywhere within the LSP tree causes the entire P2MP LSP to fail.
如果LSP设置期间或LSP建立后出现故障，则入口LSR可以控制LSP的行为。默认行为是，只有故障下游的分支未建立，但入口可能会请求“LSP完整性”，因此LSP树中的任何故障都会导致整个P2MP LSP故障。
The ingress LSP may request 'LSP integrity' by setting bit 3 of the Attributes Flags TLV. The bit is set if LSP integrity is required.
入口LSP可通过设置属性标志TLV的第3位来请求“LSP完整性”。如果需要LSP完整性，则设置该位。
It is RECOMMENDED to use the LSP_REQUIRED_ATTRIBUTES object [RFC4420].
建议使用LSP_REQUIRED_ATTRIBUTES对象[RFC4420]。
A branch LSR that supports the Attributes Flags TLV and recognizes this bit MUST support LSP integrity or reject the LSP setup with a PathErr message carrying the error "Routing Error"/"Unsupported LSP Integrity".
支持属性标志TLV并识别此位的分支LSR必须支持LSP完整性，或使用带有错误“路由错误”/“不支持的LSP完整性”的PathErr消息拒绝LSP设置。
The operation of adding egress LSR(s) to an existing P2MP LSP is termed grafting. This operation allows egress nodes to join a P2MP LSP at different points in time.
将出口LSR添加到现有P2MP LSP的操作称为嫁接。此操作允许出口节点在不同的时间点加入P2MP LSP。
There are two methods to add S2L sub-LSPs to a P2MP LSP. The first is to add new S2L sub-LSPs to the P2MP LSP by adding them to an existing Path message and refreshing the entire Path message. Path message processing described in section 4 results in adding these S2L sub-LSPs to the P2MP LSP. Note that as a result of adding one or more S2L sub-LSPs to a Path message, the ERO compression encoding may have to be recomputed.
有两种方法可将S2L子LSP添加到P2MP LSP。第一种方法是将新的S2L子LSP添加到P2MP LSP，方法是将它们添加到现有的Path消息并刷新整个Path消息。第4节中描述的路径消息处理导致将这些S2L子LSP添加到P2MP LSP。注意，作为向路径消息添加一个或多个S2L子lsp的结果，可能必须重新计算ERO压缩编码。
The second is to use incremental updates described in section 10.1. The egress LSRs can be added by signaling only the impacted S2L sub-LSPs in a new Path message. Hence, other S2L sub-LSPs do not have to be re-signaled.
第二种方法是使用第10.1节中描述的增量更新。可以通过在新路径消息中仅发信号通知受影响的S2L子lsp来添加出口lsr。因此，其他S2L子LSP不必重新发信号。
The Resv message follows the [RFC3209] and [RFC3473] format:
Resv消息采用[RFC3209]和[RFC3473]格式：
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<FF flow descriptor list> ::= <FF flow descriptor>
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor list> ::= <FF flow descriptor>
| <FF flow descriptor list>
<FF flow descriptor>
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
The FF flow descriptor and SE filter spec are modified as follows to identify the S2L sub-LSPs that they correspond to:
FF流描述符和SE过滤器规范修改如下，以识别其对应的S2L子LSP：
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<S2L sub-LSP flow descriptor list> ::=
<S2L sub-LSP flow descriptor>
[ <S2L sub-LSP flow descriptor list> ]
<S2L sub-LSP flow descriptor list> ::=
<S2L sub-LSP flow descriptor>
[ <S2L sub-LSP flow descriptor list> ]
<S2L sub-LSP flow descriptor> ::= <S2L_SUB_LSP>
[ <P2MP_SECONDARY_RECORD_ROUTE> ]
<S2L sub-LSP flow descriptor> ::= <S2L_SUB_LSP>
[ <P2MP_SECONDARY_RECORD_ROUTE> ]
FILTER_SPEC is defined in section 19.4.
第19.4节定义了过滤器规格。
The S2L sub-LSP flow descriptor has the same format as S2L sub-LSP descriptor in section 4.1 with the difference that a P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP SECONDARY_EXPLICIT_ROUTE object. The P2MP_SECONDARY_RECORD_ROUTE objects follow the same compression mechanism as the P2MP SECONDARY_EXPLICIT_ROUTE objects. Note that a Resv message can signal multiple S2L sub-LSPs that may belong to the same FILTER_SPEC object or different FILTER_SPEC objects. The same label SHOULD be allocated if the <Sender Address, LSP-ID> fields of the FILTER_SPEC object are the same.
S2L子LSP流描述符的格式与第4.1节中的S2L子LSP描述符相同，不同之处在于使用P2MP_次要_记录_路由对象代替P2MP次要_显式_路由对象。P2MP_次要_记录_路由对象遵循与P2MP次要_显式_路由对象相同的压缩机制。请注意，Resv消息可以向可能属于同一过滤器规格对象或不同过滤器规格对象的多个S2L子LSP发送信号。如果FILTER_SPEC对象的<Sender Address，LSP-ID>字段相同，则应分配相同的标签。
However different labels MUST be allocated if the <Sender Address, LSP-ID> of the FILTER_SPEC object is different, as that implies that the FILTER_SPEC refers to a different P2MP LSP.
但是，如果FILTER_SPEC对象的<Sender Address，LSP-ID>不同，则必须分配不同的标签，因为这意味着FILTER_SPEC引用不同的P2MP LSP。
The egress LSR MUST follow normal RSVP procedures while originating a Resv message. The format of Resv messages is as defined in section 6.1. As usual, the Resv message carries the label allocated by the egress LSR.
在发出Resv消息时，出口LSR必须遵循正常的RSVP程序。Resv消息的格式如第6.1节所述。与往常一样，Resv消息携带由出口LSR分配的标签。
A node upstream of the egress node MUST allocate its own label and pass it upstream in the Resv message. The node MAY combine multiple flow descriptors, from different Resv messages received from downstream, in one Resv message sent upstream. A Resv message MUST NOT be sent upstream until at least one Resv message has been received from a downstream neighbor. When the integrity bit is set in the LSP_REQUIRED_ATTRIBUTE object, Resv message MUST NOT be sent upstream until all Resv messages have been received from the downstream neighbors.
出口节点上游的节点必须分配自己的标签，并在Resv消息中向上游传递。节点可以将来自从下游接收的不同Resv消息的多个流描述符组合在向上游发送的一个Resv消息中。在从下游邻居收到至少一条Resv消息之前，不得向上游发送Resv消息。在LSP_REQUIRED_属性对象中设置完整性位时，在从下游邻居接收到所有Resv消息之前，不得向上游发送Resv消息。
Each Fixed-Filter (FF) flow descriptor or Shared-Explicit (SE) filter spec sent upstream in a Resv message includes an S2L sub-LSP descriptor list. Each such FF flow descriptor or SE filter spec for the same P2MP LSP (whether on one or multiple Resv messages) on the same Resv MUST be allocated the same label, and FF flow descriptors or SE filter specs SHOULD use the same label across multiple Resv messages.
在Resv消息中向上游发送的每个固定筛选器（FF）流描述符或共享显式（SE）筛选器规范包括S2L子LSP描述符列表。同一Resv上相同P2MP LSP（无论是在一条还是多条Resv消息上）的每个FF流描述符或SE过滤器规范必须分配相同的标签，并且FF流描述符或SE过滤器规范应在多条Resv消息中使用相同的标签。
The node that sends the Resv message, for a P2MP LSP, upstream MUST associate the label assigned by this node with all the labels received from downstream Resv messages, for that P2MP LSP. Note that a transit node may become a replication point in the future when a branch is attached to it. Hence, this results in the setup of a P2MP LSP from the ingress LSR to the egress LSRs.
对于P2MP LSP，上游发送Resv消息的节点必须将此节点分配的标签与从该P2MP LSP下游Resv消息接收的所有标签相关联。请注意，将来连接分支时，传输节点可能会成为复制点。因此，这导致从入口LSR到出口LSR的P2MP LSP的设置。
The ingress LSR may need to understand when all desired egresses have been reached. This is achieved using S2L_SUB_LSP objects.
入口LSR可能需要了解何时达到所有所需出口。这是使用S2L_SUB_LSP对象实现的。
Each branch node MAY forward a single Resv message upstream for each received Resv message from a downstream receiver. Note that there may be a large number of Resv messages at and close to the ingress LSR for an LSP with many receivers. A branch LSR SHOULD combine Resv state from multiple receivers into a single Resv message to be sent upstream (see section 6.2.1). However, note that this may result in overflowing the Resv message, particularly as the number of receivers downstream of any branch LSR increases as the LSR is closer to the ingress LSR. Thus, a branch LSR MAY choose to send more than one Resv message upstream and partition the Resv state between the messages.
每个分支节点可以针对从下游接收器接收到的每个Resv消息向上游转发单个Resv消息。注意，对于具有多个接收器的LSP，在入口LSR处和附近可能存在大量Resv消息。分支LSR应将来自多个接收器的Resv状态合并为一条向上游发送的Resv消息（见第6.2.1节）。然而，请注意，这可能导致Resv消息溢出，特别是当任何分支LSR下游的接收器数量随着LSR更接近入口LSR而增加时。因此，分支LSR可以选择向上游发送多个Resv消息，并在消息之间划分Resv状态。
When a transit node sets the Sub-Group Originator field in a Path message, it MUST replace the Sub-Group fields received in the FILTER_SPEC objects of any associated Resv messages with the value that it originally received in the Sub-Group fields of the Path message from the upstream neighbor.
当传输节点在路径消息中设置子组发起人字段时，它必须将在任何关联Resv消息的筛选器规范对象中接收的子组字段替换为它最初在路径消息的子组字段中从上游邻居接收的值。
ResvErr message generation is unmodified. Nodes propagating a received ResvErr message MUST use the Sub-Group field values carried in the corresponding Resv message.
ResvErr消息生成未经修改。传播接收到的ResvErr消息的节点必须使用相应Resv消息中包含的子组字段值。
A branch node may have to send a revised Resv message upstream whenever there is a change in a Resv message for an S2L sub-LSP received from one of the downstream neighbors. This can result in excessive Resv messages sent upstream, particularly when the S2L sub-LSPs are first established. In order to mitigate this situation, branch nodes can limit their transmission of Resv messages. Specifically, in the case where the only change being sent in a Resv message is in one or more P2MP_SECONDARY_RECORD_ROUTE objects (SRROs), the branch node SHOULD transmit the Resv message only after a delay time has passed since the transmission of the previous Resv message for the same session. This delayed Resv message SHOULD include SRROs for all branches. A suggested value for the delay time is thirty seconds, and delay times SHOULD generally be longer than 1 second. Specific mechanisms for Resv message throttling and delay timer settings are implementation dependent and are outside the scope of this document.
每当从下游邻居之一接收的S2L子LSP的Resv消息中存在变化时，分支节点可能必须向上游发送修改后的Resv消息。这可能导致向上游发送过多的Resv消息，特别是在首次建立S2L子lsp时。为了缓解这种情况，分支节点可以限制其Resv消息的传输。具体地说，在Resv消息中发送的唯一更改是在一个或多个P2MP_次要_记录_路由对象（srro）中的情况下，分支节点应仅在自针对相同会话的先前Resv消息的传输以来经过延迟时间之后才传输Resv消息。此延迟的Resv消息应包括所有分支的SRROs。延迟时间的建议值为30秒，延迟时间通常应大于1秒。Resv消息限制和延迟计时器设置的特定机制取决于实现，不在本文档的范围内。
A Resv message for a P2P LSP contains a recorded route if the ingress LSR requested route recording by including an RRO in the original Path message. The same rule is used during signaling of P2MP LSPs. That is, inclusion of an RRO in the Path message used to signal one or more S2L sub-LSPs triggers the inclusion of a recorded route for each sub-LSP in the Resv message.
如果入口LSR通过在原始路径消息中包含RRO请求记录路由，则P2P LSP的Resv消息包含记录的路由。在P2MP LSP的信令期间使用相同的规则。即，在用于向一个或多个S2L子LSP发送信号的路径消息中包含RRO触发在Resv消息中包含每个子LSP的记录路由。
The recorded route of the first S2L sub-LSP is encoded in the RRO. Additional recorded routes for the subsequent S2L sub-LSPs are encoded in P2MP_SECONDARY_RECORD_ROUTE objects (SRROs). Their format is specified in section 19.5. Each S2L_SUB_LSP object in a Resv is associated with an RRO or SRRO. The first S2L_SUB_LSP object (for the first S2L sub-LSP) is associated with the RRO. Subsequent S2L_SUB_LSP objects (for subsequent S2L sub-LSPs) are each followed by an SRRO that contains the recorded route for that S2L sub-LSP from the leaf to a branch. The ingress node can then use the RRO and SRROs to determine the end-to-end path for each S2L sub-LSP.
第一S2L子LSP的记录路由在RRO中编码。后续S2L子LSP的其他记录路由编码在P2MP_次要_记录_路由对象（SRROs）中。第19.5节规定了其格式。Resv中的每个S2L_SUB_LSP对象都与一个RRO或SRRO相关联。第一S2L_SUB_LSP对象（对于第一S2L SUB LSP）与RRO相关联。后续S2L_SUB_LSP对象（对于后续S2L SUB LSP）后面各有一个SRRO，其中包含该S2L SUB LSP从叶到分支的记录路由。入口节点然后可以使用RRO和SRROs来确定每个S2L子LSP的端到端路径。
Considerations about the reservation style in a Resv message apply as described in [RFC3209]. The reservation style in the Resv messages can be either FF or SE. All P2MP LSPs that belong to the same P2MP Tunnel MUST be signaled with the same reservation style. Irrespective of whether the reservation style is FF or SE, the S2L sub-LSPs that belong to the same P2MP LSP SHOULD share labels where they share hops. If the S2L sub-LSPs that belong to the same P2MP LSP share labels then they MUST share resources. If the reservation style is FF, then S2L sub-LSPs that belong to different P2MP LSPs MUST NOT share resources or labels. If the reservation style is SE, then S2L sub-LSPs that belong to different P2MP LSPs and the same P2MP tunnel SHOULD share resources where they share hops, but they MUST not share labels in packet environments.
关于Resv消息中保留样式的注意事项如[RFC3209]所述适用。Resv消息中的保留样式可以是FF或SE。属于同一P2MP隧道的所有P2MP LSP必须使用相同的保留样式发出信号。无论保留样式是FF还是SE，属于同一P2MP LSP的S2L子LSP应在共享跃点的位置共享标签。如果属于相同P2MP LSP的S2L子LSP共享标签，则它们必须共享资源。如果保留样式为FF，则属于不同P2MP LSP的S2L子LSP不得共享资源或标签。如果保留样式为SE，则属于不同P2MP LSP和相同P2MP隧道的S2L子LSP应在共享跃点的位置共享资源，但不得在数据包环境中共享标签。
The format of the PathTear message is as follows:
PathTear消息的格式如下所示：
<PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
[ [ <MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK> ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
[ <sender descriptor> ]
[ <S2L sub-LSP descriptor list> ]
<PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
[ [ <MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK> ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
[ <sender descriptor> ]
[ <S2L sub-LSP descriptor list> ]
<S2L sub-LSP descriptor list> ::= <S2L_SUB_LSP>
[ <S2L sub-LSP descriptor list> ]
<S2L sub-LSP descriptor list> ::= <S2L_SUB_LSP>
[ <S2L sub-LSP descriptor list> ]
The definition of <sender descriptor> is not changed by this document.
本文档未更改<sender descriptor>的定义。
The operation of removing egress LSR(s) from an existing P2MP LSP is termed as pruning. This operation allows egress nodes to be removed from a P2MP LSP at different points in time. This section describes the mechanisms to perform pruning.
从现有P2MP LSP中移除出口LSR的操作称为修剪。此操作允许在不同的时间点从P2MP LSP删除出口节点。本节介绍执行修剪的机制。
Implicit teardown uses standard RSVP message processing. Per standard RSVP processing, an S2L sub-LSP may be removed from a P2MP TE LSP by sending a modified message for the Path or Resv message that previously advertised the S2L sub-LSP. This message MUST list all S2L sub-LSPs that are not being removed. When using this approach, a node processing a message that removes an S2L sub-LSP from a P2MP TE LSP MUST ensure that the S2L sub-LSP is not included in any other Path state associated with session before interrupting the data path to that egress. All other message processing remains unchanged.
隐式拆卸使用标准RSVP消息处理。根据标准RSVP处理，可以通过发送用于先前通告S2L子LSP的路径的修改消息或Resv消息，从P2MP TE LSP移除S2L子LSP。此消息必须列出所有未删除的S2L子LSP。当使用该方法时，处理从P2MP TE LSP移除S2L子LSP的消息的节点必须确保在中断到该出口的数据路径之前，S2L子LSP不包括在与会话相关联的任何其他路径状态中。所有其他消息处理保持不变。
When implicit teardown is used to delete one or more S2L sub-LSPs, by modifying a Path message, a transit LSR may have to generate a PathTear message downstream to delete one or more of these S2L sub-LSPs. This can happen if as a result of the implicit deletion of S2L sub-LSP(s) there are no remaining S2L sub-LSPs to send in the corresponding Path message downstream.
当使用隐式拆卸来删除一个或多个S2L子LSP时，通过修改Path消息，中转LSR可能必须在下游生成PATHTRAL消息以删除这些S2L子LSP中的一个或多个。如果由于S2L子LSP的隐式删除，没有剩余的S2L子LSP可在相应的路径消息下游发送，则可能发生这种情况。
Explicit S2L Sub-LSP teardown relies on generating a PathTear message for the corresponding Path message. The PathTear message is signaled with the SESSION and SENDER_TEMPLATE objects corresponding to the P2MP LSP and the <Sub-Group Originator ID, Sub-Group ID> tuple corresponding to the Path message. This approach SHOULD be used when all the egresses signaled by a Path message need to be removed from the P2MP LSP. Other S2L sub-LSPs, from other sub-groups signaled using other Path messages, are not affected by the PathTear.
显式S2L子LSP拆卸依赖于为相应的Path消息生成PathTear消息。PathTear消息通过与P2MP LSP对应的会话和发送方模板对象以及与路径消息对应的<Sub-Group Originator ID，Sub-Group ID>元组发出信号。当需要从P2MP LSP中删除路径消息发出的所有出口信号时，应使用此方法。来自使用其他路径消息发信号的其他子组的其他S2L子LSP不受PathTrain的影响。
A transit LSR that propagates the PathTear message downstream MUST ensure that it sets the <Sub-Group Originator ID, Sub-Group ID> tuple in the PathTear message to the values used in the Path message that was used to set up the S2L sub-LSPs being torn down. The transit LSR may need to generate multiple PathTear messages for an incoming PathTear message if it had performed transit fragmentation for the corresponding incoming Path message.
向下游传播Path催泪消息的传输LSR必须确保将Path催泪消息中的<Sub Group Originator ID，Sub Group ID>元组设置为用于设置要拆除的S2L子LSP的路径消息中使用的值。如果传输LSR已对相应的传入路径消息执行传输分段，则可能需要为传入的PathTear消息生成多个PathTear消息。
When a P2MP LSP is removed by the ingress, a PathTear message MUST be generated for each Path message used to signal the P2MP LSP.
当入口移除P2MP LSP时，必须为每个用于向P2MP LSP发送信号的路径消息生成Path催泪消息。
The Notify Request object and Notify message are described in [RFC3473]. Both object and message SHALL be supported for delivery of upstream and downstream notification. Processing not detailed in this section MUST comply to [RFC3473].
[RFC3473]中描述了Notify请求对象和Notify消息。上游和下游通知的传递应支持对象和消息。本节未详细说明的处理必须符合[RFC3473]。
1. Upstream Notification
1. 上游通知
If a transit LSR sets the Sub-Group Originator ID in the SENDER_TEMPLATE object of a Path message to its own address, and the incoming Path message carries a Notify Request object, then this LSR MUST change the Notify node address in the Notify Request object to its own address in the Path message that it sends.
如果传输LSR将Path消息的发送者_模板对象中的子组发起者ID设置为其自己的地址，并且传入的Path消息包含Notify请求对象，则此LSR必须将Notify请求对象中的Notify节点地址更改为其发送的Path消息中的自己地址。
If this LSR subsequently receives a corresponding Notify message from a downstream LSR, then it MUST:
如果此LSR随后从下游LSR接收到相应的Notify消息，则它必须：
- send a Notify message upstream toward the Notify node address that the LSR received in the Path message.
- 向LSR在Path消息中接收的Notify节点地址上游发送Notify消息。
- process the Sub-Group fields of the SENDER_TEMPLATE object on the received Notify message, and modify their values, in the Notify message that is forwarded, to match the Sub-Group field values in the original Path message received from upstream.
- 处理接收到的Notify消息上的SENDER_TEMPLATE对象的子组字段，并在转发的Notify消息中修改其值，以匹配从上游接收的原始Path消息中的子组字段值。
The receiver of an (upstream) Notify message MUST identify the state referenced in this message based on the SESSION and SENDER_TEMPLATE.
（上游）通知消息的接收者必须根据会话和发送者模板标识此消息中引用的状态。
2. Downstream Notification
2. 下游通知
A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC object(s) of a Resv message to the value that was received in the corresponding Path message. If the incoming Resv message carries a Notify Request object, then:
传输LSR将Resv消息的筛选器规范对象中的子组发起人ID设置为相应路径消息中接收到的值。如果传入的Resv消息包含Notify请求对象，则：
- If there is at least another incoming Resv message that carries a Notify Request object, and the LSR merges these Resv messages into a single Resv message that is sent upstream, the LSR MUST set the Notify node address in the Notify Request object to its Router ID.
- 如果至少存在另一个携带Notify Request对象的传入Resv消息，并且LSR将这些Resv消息合并为向上游发送的单个Resv消息，则LSR必须将Notify Request对象中的Notify node地址设置为其路由器ID。
- Else if the LSR sets the Sub-Group Originator ID (in the outgoing Path message that corresponds to the received Resv message) to its own address, the LSR MUST set the Notify node address in the Notify Request object to its Router ID.
- 否则，如果LSR将子组发起人ID（在与接收到的Resv消息相对应的传出路径消息中）设置为其自己的地址，则LSR必须将Notify Request对象中的Notify node地址设置为其路由器ID。
- Else the LSR MUST propagate the Notify Request object unchanged, in the Resv message that it sends upstream.
- 否则，LSR必须在其向上游发送的Resv消息中传播Notify Request对象，保持不变。
If this LSR subsequently receives a corresponding Notify message from an upstream LSR, then it MUST:
如果此LSR随后从上游LSR接收到相应的Notify消息，则它必须：
- process the Sub-Group fields of the FILTER_SPEC object in the received Notify message, and modify their values, in the Notify message that is forwarded, to match the Sub-Group field values in the original Path message sent downstream by this LSR.
- 处理接收到的Notify消息中FILTER_SPEC对象的子组字段，并在转发的Notify消息中修改其值，以匹配此LSR向下游发送的原始Path消息中的子组字段值。
- send a Notify message downstream toward the Notify node address that the LSR received in the Resv message.
- 向LSR在Resv消息中接收到的通知节点地址下游发送通知消息。
The receiver of a (downstream) Notify message MUST identify the state referenced in the message based on the SESSION and FILTER_SPEC objects.
（下游）Notify消息的接收者必须基于会话和筛选器规范对象识别消息中引用的状态。
The consequence of these rules for a P2MP LSP is that an upstream Notify message generated on a branch will result in a Notify being delivered to the upstream Notify node address. The receiver of the Notify message MUST NOT assume that the Notify message applies to all
P2MP LSP的这些规则的结果是，在分支上生成的上游通知消息将导致向上游通知节点地址发送通知。Notify消息的接收者不得假定Notify消息适用于所有
downstream egresses, but MUST examine the information in the message to determine to which egresses the message applies.
下游出口，但必须检查消息中的信息，以确定消息适用于哪个出口。
Downstream Notify messages MUST be replicated at branch LSRs according to the Notify Request objects received on Resv messages. Some downstream branches might not request Notify messages, but all that have requested Notify messages MUST receive them.
下游Notify消息必须根据在Resv消息上接收的Notify请求对象在分支LSR上复制。一些下游分支可能不会请求Notify消息，但所有请求Notify消息的分支都必须接收它们。
ResvConf messages are described in [RFC2205]. ResvConf processing in [RFC3473] and [RFC3209] is taken directly from [RFC2205]. An egress LSR MAY include a RESV_CONFIRM object that contains the egress LSR's address. The object and message SHALL be supported for the confirmation of receipt of the Resv message in P2MP TE LSPs. Processing not detailed in this section MUST comply to [RFC2205].
[RFC2205]中描述了ResvConf消息。[RFC3473]和[RFC3209]中的ResvConf处理直接取自[RFC2205]。出口LSR可以包括包含出口LSR地址的RESV_确认对象。P2MP TE LSP中的Resv消息接收确认应支持对象和消息。本节未详细说明的处理必须符合[RFC2205]。
A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC object(s) of a Resv message to the value that was received in the corresponding Path message. If any of the incoming Resv messages corresponding to a single Path message carry a RESV_CONFIRM object, then the LSR MUST include a RESV_CONFIRM object in the corresponding Resv message that it sends upstream. If the Sub-Group Originator ID is its own address, then it MUST set the receiver address in the RESV_CONFIRM object to this address, else it MUST propagate the object unchanged.
传输LSR将Resv消息的筛选器规范对象中的子组发起人ID设置为相应路径消息中接收到的值。如果与单路径消息对应的任何传入Resv消息携带Resv_确认对象，则LSR必须在其向上游发送的相应Resv消息中包含Resv_确认对象。如果子组发起人ID是其自己的地址，则它必须将RESV_CONFIRM对象中的接收方地址设置为该地址，否则它必须不更改地传播该对象。
A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC object(s) of a Resv message to the value that was received in the corresponding Path message. If an incoming Resv message corresponding to a single Path message carries a RESV_CONFIRM object, then the LSR MUST include a RESV_CONFIRM object in the corresponding Resv message that it sends upstream and:
传输LSR将Resv消息的筛选器规范对象中的子组发起人ID设置为相应路径消息中接收到的值。如果对应于单路径消息的传入Resv消息携带Resv_确认对象，则LSR必须在其向上游发送的相应Resv消息中包含Resv_确认对象，并且：
- If there is at least another incoming Resv message that carries a RESV_CONFIRM object, and the LSR merges these Resv messages into a single Resv message that is sent upstream, the LSR MUST set the receiver address in the RESV_CONFIRM object to its Router ID.
- 如果至少有另一个传入的Resv消息携带一个Resv_确认对象，并且LSR将这些Resv消息合并为一个向上游发送的Resv消息，则LSR必须将Resv_确认对象中的接收方地址设置为其路由器ID。
- If the LSR sets the Sub-Group Originator ID (in the outgoing Path message that corresponds to the received Resv message) to its own address, the LSR MUST set the receiver address in the RESV_CONFIRM object to its Router ID.
- 如果LSR将子组发起人ID（在与接收到的Resv消息相对应的传出路径消息中）设置为其自己的地址，则LSR必须将Resv_确认对象中的接收方地址设置为其路由器ID。
- Else the LSR MUST propagate the RESV_CONFIRM object unchanged, in the Resv message that it sends upstream.
- 否则，LSR必须在其向上游发送的RESV消息中传播未更改的RESV_确认对象。
If this LSR subsequently receives a corresponding ResvConf message from an upstream LSR, then it MUST:
如果此LSR随后从上游LSR接收到相应的ResvConf消息，则它必须：
- process the Sub-Group fields of the FILTER_SPEC object in the received ResvConf message, and modify their values, in the ResvConf message that is forwarded, to match the Sub-Group field values in the original Path message sent downstream by this LSR.
- 处理接收到的ResvConf消息中FILTER_SPEC对象的子组字段，并在转发的ResvConf消息中修改其值，以匹配此LSR向下游发送的原始Path消息中的子组字段值。
- send a ResvConf message downstream toward the receiver address that the LSR received in the RESV_CONFIRM object in the Resv message.
- 向LSR在RESV消息中的RESV_确认对象中接收到的接收方地址下游发送ResvConf消息。
The receiver of a ResvConf message MUST identify the state referenced in this message based on the SESSION and FILTER_SPEC objects.
ResvConf消息的接收者必须基于会话和筛选器规范对象标识此消息中引用的状态。
The consequence of these rules for a P2MP LSP is that a ResvConf message generated at the ingress will result in a ResvConf message being delivered to the branch and then to the receiver address in the original RESV_CONFIRM object. The receiver of a ResvConf message MUST NOT assume that the ResvConf message should be sent to all downstream egresses, but it MUST replicate the message according to the RESV_CONFIRM objects received in Resv messages. Some downstream branches might not request ResvConf messages, and ResvConf messages SHOULD NOT be sent on these branches. All downstream branches that requested ResvConf messages MUST be sent such a message.
P2MP LSP的这些规则的结果是，在入口生成的ResvConf消息将导致ResvConf消息被传递到分支，然后传递到原始RESV_CONFIRM对象中的接收方地址。ResvConf消息的接收方不得假设ResvConf消息应发送至所有下游出口，但必须根据RESV_确认消息中接收的对象复制消息。某些下游分支可能不请求ResvConf消息，并且不应在这些分支上发送ResvConf消息。所有请求ResvConf消息的下游分支都必须发送这样的消息。
The refresh reduction procedures described in [RFC2961] are equally applicable to P2MP LSPs described in this document. Refresh reduction applies to individual messages and the state they install/maintain, and that continues to be the case for P2MP LSPs.
[RFC2961]中描述的刷新减少程序同样适用于本文档中描述的P2MP LSP。刷新减少适用于单个消息及其安装/维护的状态，P2MP LSP仍然如此。
State signaled by a P2MP Path message is identified by a local implementation using the <P2MP ID, Tunnel ID, Extended Tunnel ID> tuple as part of the SESSION object and the <Tunnel Sender Address, LSP ID, Sub-Group Originator ID, Sub-Group ID> tuple as part of the SENDER_TEMPLATE object.
由P2MP Path消息发出信号的状态由本地实现使用<P2MP ID，Tunnel ID，Extended Tunnel ID>元组作为会话对象的一部分和<Tunnel Sender Address，LSP ID，Sub Group Originator ID，Sub Group ID>元组作为Sender\u TEMPLATE对象的一部分来标识。
Additional information signaled in the Path/Resv message is part of the state created by a local implementation. This includes PHOP/NHOP and SENDER_TSPEC/FILTER_SPEC objects.
Path/Resv消息中的附加信息是本地实现创建的状态的一部分。这包括PHOP/NHOP和SENDER\u TSPEC/FILTER\u SPEC对象。
RSVP (as defined in [RFC2205] and as extended by RSVP-TE [RFC3209] and GMPLS [RFC3473]) uses the same basic approach to state communication and synchronization -- namely, full state is sent in each state advertisement message. Per [RFC2205], Path and Resv messages are idempotent. Also, [RFC2961] categorizes RSVP messages into two types (trigger and refresh messages) and improves RSVP message handling and scaling of state refreshes, but does not modify the full state advertisement nature of Path and Resv messages. The full state advertisement nature of Path and Resv messages has many benefits, but also has some drawbacks. One notable drawback is when an incremental modification is being made to a previously advertised state. In this case, there is the message overhead of sending the full state and the cost of processing it. It is desirable to overcome this drawback and add/delete S2L sub-LSPs to/from a P2MP LSP by incrementally updating the existing state.
RSVP（如[RFC2205]中所定义，并由RSVP-TE[RFC3209]和GMPLS[RFC3473]扩展）使用相同的基本方法进行状态通信和同步，即在每个状态公告消息中发送完整状态。根据[RFC2205]，Path和Resv消息是幂等的。此外，[RFC2961]将RSVP消息分为两种类型（触发器消息和刷新消息），并改进了RSVP消息处理和状态刷新的缩放，但不修改Path和Resv消息的完整状态播发性质。Path和Resv消息的全状态广告特性有许多优点，但也有一些缺点。一个显著的缺点是对以前公布的状态进行增量修改。在这种情况下，存在发送完整状态的消息开销和处理该状态的成本。希望通过增量更新现有状态来克服该缺点并向P2MP LSP添加/从P2MP LSP删除S2L子LSP。
It is possible to use the procedures described in this document to allow S2L sub-LSPs to be incrementally added to or deleted from the P2MP LSP by allowing a Path or a PathTear message to incrementally change the existing P2MP LSP Path state.
可以使用本文档中描述的过程，通过允许路径或PATHTRAL消息增量更改现有P2MP LSP路径状态，允许向P2MP LSP添加S2L子LSP或从P2MP LSP中删除S2L子LSP。
As described in section 5.2, multiple Path messages can be used to signal a P2MP LSP. The Path messages are distinguished by different <Sub-Group Originator ID, Sub-Group ID> tuples in the SENDER_TEMPLATE object. In order to perform incremental S2L sub-LSP state addition, a separate Path message with a new Sub-Group ID is used to add the new S2L sub-LSPs, by the ingress LSR. The Sub-Group Originator ID MUST be set to the TE Router ID [RFC3477] of the node that sets the Sub-Group ID.
如第5.2节所述，多路径消息可用于向P2MP LSP发送信号。路径消息通过发送方模板对象中不同的<Sub-Group-Originator-ID，Sub-Group-ID>元组来区分。为了执行增量S2L子LSP状态添加，入口LSR使用具有新子组ID的单独路径消息来添加新的S2L子LSP。必须将子组发起人ID设置为设置子组ID的节点的TE路由器ID[RFC3477]。
This maintains the idempotent nature of RSVP Path messages, avoids keeping track of individual S2L sub-LSP state expiration, and provides the ability to perform incremental P2MP LSP state updates.
这保持了RSVP路径消息的幂等性质，避免了跟踪单个S2L子LSP状态过期，并提供了执行增量P2MP LSP状态更新的能力。
There is a tradeoff between the number of Path messages used by the ingress to maintain the P2MP LSP and the processing imposed by full state messages when adding S2L sub-LSPs to an existing Path message. It is possible to combine S2L sub-LSPs previously advertised in different Path messages in a single Path message in order to reduce the number of Path messages needed to maintain the P2MP LSP. This can also be done by a transit node that performed fragmentation and that at a later point is able to combine multiple Path messages that it generated into a single Path message. This may happen when one or more S2L sub-LSPs are pruned from the existing Path states.
在入口用于维护P2MP LSP的路径消息的数量与将S2L子LSP添加到现有路径消息时由全状态消息施加的处理之间存在折衷。可以将先前在不同路径消息中通告的S2L子LSP组合在单个路径消息中，以减少维护P2MP LSP所需的路径消息的数量。这也可以由执行分段的传输节点来完成，该节点稍后能够将其生成的多条路径消息合并为一条路径消息。当从现有路径状态修剪一个或多个S2L子LSP时，可能会发生这种情况。
The new Path message is signaled by the node that is combining multiple Path messages with all the S2L sub-LSPs that are being combined in a single Path message. This Path message MAY contain new Sub-Group ID field values. When a new Path and Resv message that is signaled for an existing S2L sub-LSP is received by a transit LSR, state including the new instance of the S2L sub-LSP is created.
新路径消息由正在将多个路径消息与正在被组合在单个路径消息中的所有S2L子lsp组合的节点发信号通知。此路径消息可能包含新的子组ID字段值。当传输LSR接收到针对现有S2L子LSP发信号的新路径和Resv消息时，创建包括S2L子LSP的新实例的状态。
The S2L sub-LSP SHOULD continue to be advertised in both the old and new Path messages until a Resv message listing the S2L sub-LSP and corresponding to the new Path message is received by the combining node. Hence, until this point, state for the S2L sub-LSP SHOULD be maintained as part of the Path state for both the old and the new Path message (see section 3.1.3 of [RFC2205]). At that point the S2L sub-LSP SHOULD be deleted from the old Path state using the procedures of section 7.
S2L子LSP应继续在旧路径消息和新路径消息中通告，直到合并节点接收到列出S2L子LSP并对应于新路径消息的Resv消息。因此，在此之前，S2L子LSP的状态应保持为旧路径消息和新路径消息的路径状态的一部分（参见[RFC2205]第3.1.3节）。此时，应使用第7节的程序将S2L子LSP从旧路径状态中删除。
A Path message with a Sub-Group_ID(n) may signal a set of S2L sub-LSPs that belong partially or entirely to an already existing Sub-Group_ID(i), or a strictly non-overlapping new set of S2L sub-LSPs. A newly received Path message that matches SESSION object and Sender Tunnel Address, LSP ID, Sub-Group Originator ID> with existing Path state carrying the same or different Sub-Group_ID, referred to Sub-Group_ID(n) is processed as follows:
具有子组_ID（n）的路径消息可以向部分或全部属于已经存在的子组_ID（i）的一组S2L子lsp或严格不重叠的新的S2L子lsp组发送信号。新接收的路径消息将会话对象和发送方隧道地址、LSP ID、子组发起方ID>与携带相同或不同子组_ID（称为子组_ID（n））的现有路径状态相匹配，处理如下：
1) If Sub-Group_ID(i) = Sub-Group_ID(n), then S2L Sub-LSPs that are in both Sub-Group_ID(i) and Sub-Group_ID(n) are refreshed. New S2L Sub-LSPs are added to Sub-Group_ID(i) Path state and S2L Sub-LSPs that are in Sub-Group_ID(i) but not in Sub-Group_ID(n) are deleted from the Sub-Group_ID(i) Path state.
1) 如果子组_ID（i）=子组_ID（n），则刷新子组_ID（i）和子组_ID（n）中的S2L子LSP。新的S2L子LSP添加到子组_ID（i）路径状态，并且从子组_ID（i）路径状态中删除子组_ID（i）中但不在子组_ID（n）中的S2L子LSP。
2) If Sub-Group_ID(i) != Sub-Group_ID(n), then a new Sub-Group_ID(n) Path state is created for S2L Sub-LSPs signaled by Sub-Group_ID(n). S2L Sub-LSPs in existing Sub-Group_IDs(i) Path state (that are or are not in the newly received Path message Sub-Group_ID(n)) are left unmodified (see above).
2) 如果子组ID（i）！=子组_ID（n），然后为由子组_ID（n）发信号的S2L子lsp创建新的子组_ID（n）路径状态。现有子组_ID（i）路径状态（在新接收到的路径消息子组_ID（n）中）中的S2L子LSP保持不变（见上文）。
PathErr and ResvErr messages are processed as per RSVP-TE procedures. Note that an LSR, on receiving a PathErr/ResvErr message for a particular S2L sub-LSP, changes the state only for that S2L sub-LSP. Hence other S2L sub-LSPs are not impacted. If the ingress node requests 'LSP integrity', an error reported on a branch of a P2MP TE LSP for a particular S2L sub-LSP may change the state of any other S2L sub-LSP of the same P2MP TE LSP. This is explained further in section 11.3.
PathErr和ResvErr消息按照RSVP-TE程序处理。请注意，LSR在接收特定S2L子LSP的PathErr/ResvErr消息时，仅更改该S2L子LSP的状态。因此，其他S2L子LSP不受影响。如果入口节点请求“LSP完整性”，则针对特定S2L子LSP在P2MP TE LSP的分支上报告的错误可改变相同P2MP TE LSP的任何其他S2L子LSP的状态。第11.3节对此作了进一步解释。
The PathErr message will include one or more S2L_SUB_LSP objects. The resulting modified format for a PathErr message is:
PathErr消息将包括一个或多个S2L_SUB_LSP对象。PathErr消息的最终修改格式为：
<PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
[ <S2L sub-LSP descriptor list> ]
<PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
[ <S2L sub-LSP descriptor list> ]
PathErr message generation is unmodified, but nodes that set the Sub-Group Originator field and propagate a received PathErr message upstream MUST replace the Sub-Group fields received in the PathErr message with the value that was received in the Sub-Group fields of the Path message from the upstream neighbor. Note the receiver of a PathErr message is able to identify the errored outgoing Path message, and outgoing interface, based on the Sub-Group fields received in the PathErr message. The S2L sub-LSP descriptor list is defined in section 5.1.
Paterr消息生成未经修改，但设置子组发起人字段并向上游传播接收到的Paterr消息的节点必须将Paterr消息中接收到的子组字段替换为路径消息的子组字段中从上游邻居接收到的值。注意：PathErr消息的接收者能够根据PathErr消息中接收到的子组字段识别出错的传出路径消息和传出接口。S2L子LSP描述符列表在第5.1节中定义。
The ResvErr message will include one or more S2L_SUB_LSP objects. The resulting modified format for a ResvErr Message is:
ResvErr消息将包括一个或多个S2L_SUB_LSP对象。ResvErr消息的最终修改格式为：
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ]
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ]
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
ResvErr message generation is unmodified, but nodes that set the Sub-Group Originator field and propagate a received ResvErr message downstream MUST replace the Sub-Group fields received in the ResvErr message with the value that was set in the Sub-Group fields of the Path message sent to the downstream neighbor. Note the receiver of a ResvErr message is able to identify the errored outgoing Resv
ResvErr消息生成未经修改，但设置子组发起人字段并向下游传播接收到的ResvErr消息的节点必须将ResvErr消息中接收到的子组字段替换为发送到下游邻居的路径消息的子组字段中设置的值。注：ResvErr消息的接收者能够识别出错的传出Resv
message, and outgoing interface, based on the Sub-Group fields received in the ResvErr message. The flow descriptor list is defined in section 6.1.
消息和传出接口，基于在ResvErr消息中接收的子组字段。第6.1节定义了流量描述符列表。
During setup and during normal operation, PathErr messages may be received at a branch node. In all cases, a received PathErr message is first processed per standard processing rules. That is, the PathErr message is sent hop-by-hop to the ingress/branch LSR for that Path message. Intermediate nodes until this ingress/branch LSR MAY inspect this message but take no action upon it. The behavior of a branch LSR that generates a PathErr message is under the control of the ingress LSR.
在设置和正常操作期间，可能会在分支节点上接收PathErr消息。在所有情况下，首先按照标准处理规则处理收到的PathErr消息。也就是说，PathErr消息逐跳发送到该路径消息的入口/分支LSR。在此入口/分支LSR之前的中间节点可以检查此消息，但不对其采取任何操作。生成PathErr消息的分支LSR的行为受入口LSR的控制。
The default behavior is that the PathErr message does not have the Path_State_Removed flag set. However, if the ingress LSR has set the LSP integrity flag on the Path message (see LSP_REQUIRED_ATTRIBUTEs object in section 5.2.4), and if the Path_State_Removed flag is supported, the LSR generating a PathErr to report the failure of a branch of the P2MP LSP SHOULD set the Path_State_Removed flag.
默认行为是PathErr消息未设置Path_State_Removed标志。但是，如果入口LSR在路径消息上设置了LSP完整性标志（请参阅第5.2.4节中的LSP_REQUIRED_ATTRIBUTEs对象），并且如果支持Path_State_Removed标志，则生成路径报告P2MP LSP分支故障的LSR应设置Path_State_Removed标志。
A branch LSR that receives a PathErr message during LSP setup with the Path_State_Removed flag set MUST act according to the wishes of the ingress LSR. The default behavior is that the branch LSR clears the Path_State_Removed flag on the PathErr and sends it further upstream. It does not tear any other branches of the LSP. However, if the LSP integrity flag is set on the Path message, the branch LSR MUST send PathTear on all other downstream branches and send the PathErr message upstream with the Path_State_Removed flag set.
在LSP设置期间接收PathErr消息且设置了Path_State_Removed标志的分支LSR必须根据入口LSR的意愿进行操作。默认行为是分支LSR清除PathErr上的Path_State_Removed标志，并将其发送到更远的上游。它不会撕裂LSP的任何其他分支。但是，如果在Path消息上设置了LSP完整性标志，则分支LSR必须在所有其他下游分支上发送PATHTRARE，并在设置了Path_State_Removed标志的情况下向上游发送PathErr消息。
A branch LSR that receives a PathErr message with the Path_State_Removed flag clear MUST act according to the wishes of the ingress LSR. The default behavior is that the branch LSR forwards the PathErr upstream and takes no further action. However, if the LSP integrity flag is set on the Path message, the branch LSR MUST send PathTear on all downstream branches and send the PathErr upstream with the Path_State_Removed flag set (per [RFC3473]).
接收路径状态为清除标志的PathErr消息的分支LSR必须根据入口LSR的意愿进行操作。默认行为是分支LSR向上游转发PathErr，并且不采取进一步的操作。但是，如果在Path消息上设置了LSP完整性标志，则分支LSR必须在所有下游分支上发送PathTear，并在设置了Path_State_Removed标志的情况下向上游发送PathErr（根据[RFC3473]）。
In all cases, the PathErr message forwarded by a branch LSR MUST contain the S2L sub-LSP identification and explicit routes of all branches that are reported by received PathErr messages and all branches that are explicitly torn by the branch LSR.
在所有情况下，分支LSR转发的PathErr消息必须包含S2L子LSP标识和接收到的PathErr消息报告的所有分支以及分支LSR显式撕裂的所有分支的显式路由。
A branch node that receives an ADMIN_STATUS object processes it normally and also relays the ADMIN_STATUS object in a Path on every branch. All Path messages may be concurrently sent to the downstream neighbors.
接收ADMIN_状态对象的分支节点正常处理该对象，并在每个分支上的路径中中继ADMIN_状态对象。所有路径消息可以同时发送到下游邻居。
Downstream nodes process the change in the ADMIN_STATUS object per [RFC3473], including generation of Resv messages. When the last received upstream ADMIN_STATUS object had the R bit set, branch nodes wait for a Resv message with a matching ADMIN_STATUS object to be received (or a corresponding PathErr or ResvTear message) on all branches before relaying a corresponding Resv message upstream.
下游节点根据[RFC3473]处理管理状态对象中的更改，包括生成Resv消息。当上一次接收到的上游ADMIN_STATUS对象设置了R位时，分支节点等待所有分支上接收到具有匹配ADMIN_STATUS对象的Resv消息（或相应的PathErr或ResvTear消息），然后再向上游中继相应的Resv消息。
A branch LSR of a P2MP LSP on an Ethernet LAN segment SHOULD send one copy of the data traffic per downstream LSR connected on that LAN for that P2MP LSP. Procedures for preventing MPLS labeled traffic replication in such a case is beyond the scope of this document.
以太网LAN段上P2MP LSP的分支LSR应为该P2MP LSP在该LAN上连接的每个下游LSR发送一份数据流量副本。在这种情况下，防止MPLS标记的流量复制的过程超出了本文档的范围。
It is possible to change the path used by P2MP LSPs to reach the destinations of the P2MP tunnel. There are two methods that can be used to accomplish this. The first is make-before-break, defined in [RFC3209], and the second uses the sub-groups defined above.
可以更改P2MP LSP用于到达P2MP隧道目的地的路径。有两种方法可以用来实现这一点。第一个是[RFC3209]中定义的先通后断，第二个使用上面定义的子组。
In this case, all the S2L sub-LSPs are signaled with a different LSP ID by the ingress LSR and follow the make-before-break procedure defined in [RFC3209]. Thus, a new P2MP LSP is established. Each S2L sub-LSP is signaled with a different LSP ID, corresponding to the new P2MP LSP. After moving traffic to the new P2MP LSP, the ingress can tear down the old P2MP LSP. This procedure can be used to re-optimize the path of the entire P2MP LSP or the paths to a subset of the destinations of the P2MP LSP. When modifying just a portion of the P2MP LSP, this approach requires the entire P2MP LSP to be re-signaled.
在这种情况下，所有S2L子LSP由入口LSR以不同的LSP ID发出信号，并遵循[RFC3209]中定义的先通后断程序。因此，建立了一个新的P2MP LSP。每个S2L子LSP用不同的LSP ID发信号，对应于新的P2MP LSP。在将流量移动到新的P2MP LSP后，入口可以拆除旧的P2MP LSP。此过程可用于重新优化整个P2MP LSP的路径或到P2MP LSP目的地子集的路径。当仅修改P2MP LSP的一部分时，此方法要求重新发送整个P2MP LSP的信号。
Any node may initiate re-optimization of a set of S2L sub-LSPs by using incremental state update and then, optionally, combining multiple path messages.
任何节点都可以通过使用增量状态更新，然后可选地组合多个路径消息来发起对一组S2L子lsp的重新优化。
To alter the path taken by a particular set of S2L sub-LSPs, the node initiating the path change initiates one or more separate Path messages for the same P2MP LSP, each with a new sub-Group ID. The generation of these Path messages, each with one or more S2L sub-LSPs, follows procedures in section 5.2. As is the case in section 10.2, a particular egress continues to be advertised in both the old and new Path messages until a Resv message listing the egress and corresponding to the new Path message is received by the re-optimizing node. At that point, the egress SHOULD be deleted from the old Path state using the procedures of section 7. Sub-tree re-optimization is then completed.
为了改变一组特定S2L子LSP所采用的路径，发起路径更改的节点为同一P2MP LSP启动一个或多个单独的路径消息，每个消息都具有新的子组ID。这些路径消息的生成，每个消息都具有一个或多个S2L子LSP，遵循第5.2节中的程序。与第10.2节中的情况一样，在重新优化节点接收到列出出口并对应于新路径消息的Resv消息之前，在旧路径消息和新路径消息中继续通告特定出口。此时，应使用第7节的程序将出口从旧路径状态中删除。然后完成子树的重新优化。
Sub-Group-based re-optimization may result in transient data duplication as the new Path messages for a set of S2L sub-LSPs may transit one or more nodes with the old Path state for the same set of S2L sub-LSPs.
基于子组的重新优化可导致瞬时数据重复，因为一组S2L子lsp的新路径消息可针对同一组S2L子lsp传输具有旧路径状态的一个或多个节点。
As is always the case, a node may choose to combine multiple path messages as described in section 10.2.
通常情况下，节点可以选择组合多路径消息，如第10.2节所述。
[RFC4090] extensions can be used to perform fast reroute for the mechanism described in this document when applied within packet networks. GMPLS introduces other protection techniques that can be applied to packet and non-packet environments [RFC4873], but which are not discussed further in this document. This section only applies to LSRs that support [RFC4090].
[RFC4090]当在分组网络中应用时，扩展可用于执行本文档中描述的机制的快速重路由。GMPLS介绍了可应用于数据包和非数据包环境的其他保护技术[RFC4873]，但在本文档中不作进一步讨论。本节仅适用于支持[RFC4090]的LSR。
This section uses terminology defined in [RFC4090], and fast reroute procedures defined in [RFC4090] MUST be followed unless specified below. The head-end and transit LSRs MUST follow the SESSION_ATTRIBUTE and FAST_REROUTE object processing as specified in [RFC4090] for each Path message and S2L sub-LSP of a P2MP LSP. Each S2L sub-LSP of a P2MP LSP MUST have the same protection characteristics. The RRO processing MUST apply to SRRO as well unless modified below.
本节使用[RFC4090]中定义的术语，除非下文另有规定，否则必须遵循[RFC4090]中定义的快速重路由程序。对于P2MP LSP的每个路径消息和S2L子LSP，前端和传输LSR必须遵循[RFC4090]中规定的会话_属性和快速_重路由对象处理。P2MP LSP的每个S2L子LSP必须具有相同的保护特性。RRO处理也必须适用于SRRO，除非以下修改。
The sections that follow describe how fast reroute may be applied to P2MP MPLS TE LSPs in all of the principal operational scenarios. This document does not describe the detailed processing steps for every imaginable usage case, and they may be described in future documents, as needed.
以下各节描述了在所有主要操作场景中，如何将快速重路由应用于P2MP MPLS TE LSP。本文档并没有描述每个可想象的用例的详细处理步骤，将来可能会根据需要在文档中描述这些步骤。
Facility backup can be used for link or node protection of LSRs on the path of a P2MP LSP. The downstream labels MUST be learned by the Point of Local Repair (PLR), as specified in [RFC4090], from the label corresponding to the S2L sub-LSP in the RESV message. Processing of SEROs signaled in a backup tunnel MUST follow backup tunnel ERO processing described in [RFC4090].
设施备份可用于P2MP LSP路径上LSR的链路或节点保护。按照[RFC4090]中的规定，下游标签必须由本地维修点（PLR）从与RESV消息中S2L子LSP对应的标签中识别。对备份通道中发出信号的血清的处理必须遵循[RFC4090]中所述的备份通道ERO处理。
If link protection is desired, a bypass tunnel MUST be used to protect the link between the PLR and next-hop. Thus all S2L sub-LSPs that use the link SHOULD be protected in the event of link failure. Note that all such S2L sub-LSPs belonging to a particular instance of a P2MP tunnel SHOULD share the same outgoing label on the link between the PLR and the next-hop as per section 5.2.1. This is the P2MP LSP label on the link. Label stacking is used to send data for each P2MP LSP into the bypass tunnel. The inner label is the P2MP LSP label allocated by the next-hop.
如果需要链路保护，则必须使用旁路隧道来保护PLR和下一跳之间的链路。因此，在发生链路故障的情况下，应保护使用链路的所有S2L子LSP。请注意，根据第5.2.1节，属于P2MP隧道特定实例的所有此类S2L子LSP应在PLR和下一跳之间的链路上共享相同的传出标签。这是链接上的P2MP LSP标签。标签堆叠用于将每个P2MP LSP的数据发送到旁通隧道。内部标签是由下一跳分配的P2MP LSP标签。
During failure, Path messages for each S2L sub-LSP that is affected, MUST be sent to the Merge Point (MP) by the PLR. It is RECOMMENDED that the PLR uses the sender template-specific method to identify these Path messages. Hence, the PLR will set the source address in the sender template to a local PLR address.
故障期间，受影响的每个S2L子LSP的路径消息必须由PLR发送到合并点（MP）。建议PLR使用特定于发送方模板的方法来识别这些路径消息。因此，PLR将发送方模板中的源地址设置为本地PLR地址。
The MP MUST use the LSP-ID to identify the corresponding S2L sub-LSPs. The MP MUST NOT use the <Sub-Group Originator ID, Sub-Group ID> tuple while identifying the corresponding S2L sub-LSPs. In order to further process an S2L sub-LSP the MP MUST determine the protected S2L sub-LSP using the LSP-ID and the S2L_SUB_LSP object.
MP必须使用LSP-ID识别相应的S2L子LSP。MP在识别相应的S2L子LSP时不得使用<Sub Group Originator ID，Sub Group ID>元组。为了进一步处理S2L子LSP，MP必须使用LSP-ID和S2L_子_LSP对象确定受保护的S2L子LSP。
If node protection is desired the PLR SHOULD use one or more P2P bypass tunnels to protect the set of S2L sub-LSPs that transit the protected node. Each of these P2P bypass tunnels MUST intersect the path of the S2L sub-LSPs that they protect on an LSR that is downstream from the protected node. This constrains the set of S2L sub-LSPs being backed- up via that bypass tunnel to those S2L sub-LSPs that pass through a common downstream MP. This MP is the destination of the bypass tunnel. When the PLR forwards incoming data for a P2MP LSP into the bypass tunnel, the outer label is the bypass tunnel label and the inner label is the label allocated by the MP to the set of S2L sub-LSPs belonging to that P2MP LSP.
如果需要节点保护，PLR应使用一个或多个P2P旁路隧道来保护通过受保护节点的S2L子LSP集。这些P2P旁路隧道中的每一个都必须与它们在受保护节点下游的LSR上保护的S2L子lsp的路径相交。这将通过该旁路隧道备份的S2L子LSP集限制为通过公共下游MP的S2L子LSP集。该MP是旁通隧道的目的地。当PLR将P2MP LSP的传入数据转发到旁路隧道中时，外部标签是旁路隧道标签，内部标签是MP分配给属于该P2MP LSP的S2L子LSP集的标签。
After detecting failure of the protected node the PLR MUST send one or more Path messages for all protected S2L sub-LSPs to the MP of the protected S2L sub-LSP. It is RECOMMENDED that the PLR use the sender template specific method to identify these Path messages. Hence the PLR will set the source address in the sender template to a local PLR address. The MP MUST use the LSP-ID to identify the corresponding S2L sub-LSPs. The MP MUST NOT use the <Sub-Group Originator ID, Sub-Group ID> tuple while identifying the corresponding S2L sub-LSPs because the Sub-Group Originator ID might be changed by some LSR that is bypassed by the bypass tunnel. In order to further process an S2L sub-LSP the MP MUST determine the protected S2L sub-LSP using the LSP-ID and the S2L_SUB_LSP object.
在检测到一个或多个受保护的LSS2L子节点的LSMP路径故障后，必须将受保护的LSL子节点的一条或多条消息发送到受保护的LSL子节点。建议PLR使用特定于发送方模板的方法来识别这些路径消息。因此，PLR将发送方模板中的源地址设置为本地PLR地址。MP必须使用LSP-ID识别相应的S2L子LSP。MP在识别相应的S2L子LSP时不得使用<Sub Group Originator ID，Sub Group ID>元组，因为旁路隧道绕过的某个LSR可能会更改子组Originator ID。为了进一步处理S2L子LSP，MP必须使用LSP-ID和S2L_子_LSP对象确定受保护的S2L子LSP。
Note that node protection MAY require the PLR to be branch capable in the data plane, as multiple bypass tunnels may be required to back up the set of S2L sub-LSPs passing through the protected node. If the PLR is not branch capable, the node protection mechanism described here is applicable to only those cases where all the S2L sub-LSPs passing through the protected node also pass through a single MP that is downstream from the protected node. A PLR MUST set the Node protection flag in the RRO/SRRO as specified in [RFC4090]. If a PLR is not branch capable, and one or more S2L sub-LSPs are added to a P2MP tree, and these S2L sub-LSPs do not transit the existing MP downstream of the protected node, then the PLR MUST reset this flag.
注意，节点保护可能要求PLR在数据平面中具有分支能力，因为可能需要多个旁路隧道来备份通过受保护节点的S2L子lsp的集合。如果PLR不具有分支能力，则这里描述的节点保护机制仅适用于通过受保护节点的所有S2L子lsp也通过受保护节点下游的单个MP的情况。PLR必须按照[RFC4090]中的规定在RRO/SRRO中设置节点保护标志。如果PLR不支持分支，并且一个或多个S2L子LSP被添加到P2MP树，并且这些S2L子LSP不传输受保护节点的现有MP下游，则PLR必须重置此标志。
It is to be noted that procedures in this section require P2P bypass tunnels. Procedures for using P2MP bypass tunnels are for further study.
需要注意的是，本节中的程序需要P2P旁通隧道。P2MP旁通隧道的使用程序有待进一步研究。
One-to-one backup, as described in [RFC4090], can be used to protect a particular S2L sub-LSP against link and next-hop failure. Protection may be used for one or more S2L sub-LSPs between the PLR and the next-hop. All the S2L sub-LSPs corresponding to the same instance of the P2MP tunnel between the PLR and the next-hop SHOULD share the same P2MP LSP label, as per section 5.2.1. All such S2L sub-LSPs belonging to a P2MP LSP MUST be protected.
如[RFC4090]中所述，一对一备份可用于保护特定S2L子LSP免受链路和下一跳故障的影响。保护可用于PLR和下一跳之间的一个或多个S2L子lsp。根据第5.2.1节，与PLR和下一跳之间P2MP隧道的相同实例相对应的所有S2L子LSP应共享相同的P2MP LSP标签。属于P2MP LSP的所有此类S2L子LSP必须受到保护。
The backup S2L sub-LSPs may traverse different next-hops at the PLR. Thus, the set of outgoing labels and next-hops for a P2MP LSP, at the PLR, may change once protection is triggered. Consider a P2MP LSP that is using a single next-hop and label between the PLR and the next-hop of the PLR. This may no longer be the case once protection is triggered. This MAY require a PLR to be branch capable in the data plane. If the PLR is not branch capable, the one-to-one backup mechanisms described here are only applicable to those cases where all the backup S2L sub-LSPs pass through the same next-hop downstream
备份S2L子lsp可以在PLR处穿越不同的下一跳。因此，一旦触发保护，PLR处P2MP LSP的传出标签和下一跳的集合可能改变。考虑一个PMP LSP，它使用PLR和PLR的下一跳之间的单个下一跳和标签。一旦触发保护，情况可能不再如此。这可能需要PLR在数据平面中具有分支能力。如果PLR不支持分支，则这里描述的一对一备份机制仅适用于所有备份S2L子lsp通过相同的下一跳下游的情况
of the PLR. Procedures for one-to-one backup when a PLR is not branch capable and when all the backup S2L sub-LSPs do not pass through the same downstream next-hop are for further study.
PLR的一部分。当PLR不具备分支能力时，以及当所有备份S2L子LSP未通过同一下游下一跳时，一对一备份的程序有待进一步研究。
It is recommended that the path-specific method be used to identify a backup S2L sub-LSP. Hence, the DETOUR object SHOULD be inserted in the backup Path message. A backup S2L sub-LSP MUST be treated as belonging to a different P2MP tunnel instance than the one specified by the LSP-ID. Furthermore multiple backup S2L sub-LSPs MUST be treated as part of the same P2MP tunnel instance if they have the same LSP-ID and the same DETOUR objects. Note that, as specified in section 4, S2L sub-LSPs between different P2MP tunnel instances use different labels.
建议使用特定于路径的方法来识别备份S2L子LSP。因此，应该在备份路径消息中插入DETOUR对象。备份S2L子LSP必须被视为属于不同于LSP-ID指定的P2MP隧道实例。此外，如果多个备份S2L子LSP具有相同的LSP-ID和相同的迂回对象，则必须将其视为同一P2MP隧道实例的一部分。注意，如第4节所述，不同P2MP隧道实例之间的S2L子LSP使用不同的标签。
If there is only one S2L sub-LSP in the Path message, the DETOUR object applies to that sub-LSP. If there are multiple S2L sub-LSPs in the Path message, the DETOUR object applies to all the S2L sub-LSPs.
如果路径消息中只有一个S2L子LSP，则迂回对象将应用于该子LSP。如果路径消息中存在多个S2L子LSP，则迂回对象将应用于所有S2L子LSP。
It may be that some LSRs in a network are capable of processing the P2MP extensions described in this document, but do not support P2MP branching in the data plane. If such an LSR is requested to become a branch LSR by a received Path message, it MUST respond with a PathErr message carrying the Error Code "Routing Error" and Error Value "Unable to Branch".
网络中的某些LSR可能能够处理本文档中描述的P2MP扩展，但不支持数据平面中的P2MP分支。如果接收到的Path消息请求此类LSR成为分支LSR，则它必须使用带有错误代码“路由错误”和错误值“无法分支”的PathErr消息进行响应。
It is also conceivable that some LSRs, in a network deploying P2MP capability, may not support the extensions described in this document. If a Path message for the establishment of a P2MP LSP reaches such an LSR, it will reject it with a PathErr because it will not recognize the C-Type of the P2MP SESSION object.
还可以想象，在部署P2MP功能的网络中，某些LSR可能不支持本文档中描述的扩展。如果用于建立P2MP LSP的路径消息到达这样的LSR，它将使用PathErr拒绝该消息，因为它无法识别P2MP会话对象的C类型。
LSRs that do not support the P2MP extensions in this document may be included as transit LSRs by the use of LSP stitching [LSP-STITCH] and LSP hierarchy [RFC4206]. Note that LSRs that are required to play any other role in the network (ingress, branch or egress) MUST support the extensions defined in this document.
本文件中不支持P2MP扩展的LSR可通过使用LSP缝合[LSP-STITCH]和LSP层次结构[RFC4206]作为运输LSR。请注意，需要在网络中扮演任何其他角色（入口、分支或出口）的LSR必须支持本文档中定义的扩展。
The use of LSP stitching and LSP hierarchy [RFC4206] allows P2MP LSPs to be built in such an environment. A P2P LSP segment is signaled from the last P2MP-capable hop that is upstream of a legacy LSR to the first P2MP-capable hop that is downstream of it. This assumes that intermediate legacy LSRs are transit LSRs: they cannot act as P2MP branch points. Transit LSRs along this LSP segment do not process control plane messages associated with the P2MP LSP. Furthermore, these transit LSRs also do not need to have P2MP data
LSP缝合和LSP层次结构[RFC4206]的使用允许在这样的环境中构建P2MP LSP。P2P LSP段从遗留LSR上游的最后一个支持P2MP的跳向其下游的第一个支持P2MP的跳发送信号。这假设中间遗留LSR是运输LSR：它们不能充当P2MP分支点。沿着此LSP段的传输LSR不处理与P2MP LSP相关联的控制平面消息。此外，这些运输LSR也不需要P2MP数据
plane capabilities as they only need to process data belonging to the P2P LSP segment. Hence, these transit LSRs do not need to support P2MP MPLS. This P2P LSP segment is stitched to the incoming P2MP LSP. After the P2P LSP segment is established, the P2MP Path message is sent to the next P2MP-capable LSR as a directed Path message. The next P2MP-capable LSR stitches the P2P LSP segment to the outgoing P2MP LSP.
平面功能，因为它们只需要处理属于P2P LSP段的数据。因此，这些传输LSR不需要支持P2MP MPLS。此P2P LSP段缝合到传入的P2MP LSP。建立P2P LSP段后，P2MP Path消息作为定向路径消息发送到下一个支持P2MP的LSR。下一个支持P2MP的LSR将P2P LSP段缝合到传出的P2MP LSP。
In packet networks, the S2L sub-LSPs may be nested inside the outer P2P LSP. Hence, label stacking can be used to enable use of the same LSP segment for multiple P2MP LSPs. Stitching and nesting considerations and procedures are described further in [LSP-STITCH] and [RFC4206].
在分组网络中，S2L子LSP可以嵌套在外部P2P LSP内。因此，标签堆叠可用于使同一LSP段可用于多个P2MP LSP。[LSP-STITCH]和[RFC4206]中进一步描述了缝合和嵌套注意事项和程序。
There maybe overhead for an operator to configure the P2P LSP segments in advance, when it is desired to support legacy LSRs. It may be desirable to do this dynamically. The ingress can use IGP extensions to determine P2MP-capable LSRs [TE-NODE-CAP]. It can use this information to compute S2L sub-LSP paths such that they avoid legacy non-P2MP-capable LSRs. The explicit route object of an S2L sub-LSP path may contain loose hops if there are legacy LSRs along the path. The corresponding explicit route contains a list of objects up to the P2MP-capable LSR that is adjacent to a legacy LSR followed by a loose object with the address of the next P2MP-capable LSR. The P2MP-capable LSR expands the loose hop using its Traffic Engineering Database (TED). When doing this it determines that the loose hop expansion requires a P2P LSP to tunnel through the legacy LSR. If such a P2P LSP exists, it uses that P2P LSP. Else it establishes the P2P LSP. The P2MP Path message is sent to the next P2MP-capable LSR using non-adjacent signaling.
当需要支持传统LSR时，运营商可能需要预先配置P2P LSP段。可能需要动态地执行此操作。入口可以使用IGP扩展来确定支持P2MP的LSR[TE-NODE-CAP]。它可以使用此信息计算S2L子LSP路径，以避免遗留的不支持P2MP的LSR。如果沿路径存在遗留LSR，则S2L子LSP路径的显式路由对象可能包含松散跳。相应的显式路由包含一个对象列表，该列表最多包含一个支持P2MP的LSR，该LSR与一个遗留LSR相邻，后面是一个松散对象，该对象的地址为下一个支持P2MP的LSR。支持P2MP的LSR使用其流量工程数据库（TED）扩展松散跃点。执行此操作时，它确定松跃点扩展需要P2P LSP通过遗留LSR进行隧道传输。如果存在这样的P2P LSP，它将使用该P2P LSP。否则它将建立P2P LSP。P2MP Path消息使用非相邻信令发送到下一个支持P2MP的LSR。
The P2MP-capable LSR that initiates the non-adjacent signaling message to the next P2MP-capable LSR may have to employ a fast detection mechanism (such as [BFD] or [BFD-MPLS]) to the next P2MP-capable LSR. This may be needed for the directed Path message head-end to use node protection fast reroute when the protected node is the directed Path message tail.
向下一个支持P2MP的LSR发起非相邻信令消息的支持P2MP的LSR可能必须对下一个支持P2MP的LSR采用快速检测机制（例如[BFD]或[BFD-MPLS]）。当受保护节点是定向路径消息尾部时，定向路径消息前端可能需要使用节点保护快速重路由。
Note that legacy LSRs along a P2P LSP segment cannot perform node protection of the tail of the P2P LSP segment.
请注意，沿P2P LSP段的传统LSR无法对P2P LSP段的尾部执行节点保护。
It is possible to take advantage of LSP hierarchy [RFC4206] while setting up P2MP LSP, as described in the previous section, to reduce control plane processing along transit LSRs that are P2MP capable. This is applicable only in environments where LSP hierarchy can be used. Transit LSRs along a P2P LSP segment, being used by a P2MP
如前一节所述，在设置P2MP LSP时，可以利用LSP层次结构[RFC4206]，以减少沿着具有P2MP能力的运输LSR的控制平面处理。这仅适用于可以使用LSP层次结构的环境。沿着P2P LSP段传输LSR，供P2MP使用
LSP, do not process control plane messages associated with the P2MP LSP. In fact, they are not aware of these messages as they are tunneled over the P2P LSP segment. This reduces the amount of control plane processing required on these transit LSRs.
LSP，不处理与P2MP LSP关联的控制平面消息。事实上，他们并不知道这些消息，因为它们是通过P2P LSP段进行隧道传输的。这减少了这些运输LSR上所需的控制平面处理量。
Note that the P2P LSPs can be set up dynamically as described in the previous section or preconfigured. For example, in Figure 2 in section 24, PE1 can set up a P2P LSP to P1 and use that as a LSP segment. The Path messages for PE3 and PE4 can now be tunneled over the LSP segment. Thus, P3 is not aware of the P2MP LSP and does not process the P2MP control messages.
请注意，P2P LSP可以按照上一节所述动态设置或预配置。例如，在第24节的图2中，PE1可以将P2P LSP设置为P1，并将其用作LSP段。PE3和PE4的路径消息现在可以通过LSP段进行隧道传输。因此，P3不知道P2MP LSP，也不处理P2MP控制消息。
This section details the procedures for detecting and dealing with re-merge and cross-over. The term "re-merge" refers to the case of an ingress or transit node that creates a branch of a P2MP LSP, a re-merge branch, that intersects the P2MP LSP at another node farther down the tree. This may occur due to such events as an error in path calculation, an error in manual configuration, or network topology changes during the establishment of the P2MP LSP. If the procedures detailed in this section are not followed, data duplication will result.
本节详细介绍了检测和处理重新合并和交叉的过程。术语“重新合并”指的是入口或中转节点创建P2MP LSP分支的情况，即重新合并分支，该分支与树下另一节点处的P2MP LSP相交。这可能是由于路径计算错误、手动配置错误或P2MP LSP建立期间的网络拓扑更改等事件造成的。如果不遵循本节详述的步骤，将导致数据重复。
The term "cross-over" refers to the case of an ingress or transit node that creates a branch of a P2MP LSP, a cross-over branch, that intersects the P2MP LSP at another node farther down the tree. It is unlike re-merge in that, at the intersecting node, the cross-over branch has a different outgoing interface as well as a different incoming interface. This may be necessary in certain combinations of topology and technology; e.g., in a transparent optical network in which different wavelengths are required to reach different leaf nodes.
术语“交叉”指的是入口或中转节点创建P2MP LSP分支的情况，即交叉分支，该分支在树下更远的另一个节点处与P2MP LSP相交。与重新合并不同的是，在相交节点处，交叉分支具有不同的传出接口和不同的传入接口。这在拓扑和技术的某些组合中可能是必要的；e、 例如，在透明光网络中，需要不同的波长才能到达不同的叶节点。
Normally, a P2MP LSP has a single incoming interface on which all of the data for the P2MP LSP is received. The incoming interface is identified by the IF_ID RSVP_HOP object, if present, and by the interface over which the Path message was received if the IF_ID RSVP_HOP object is not present. However, in the case of dynamic LSP re-routing, the incoming interface may change.
通常，P2MP LSP有一个单一的传入接口，在该接口上接收P2MP LSP的所有数据。传入接口由IF_ID RSVP_HOP对象（如果存在）标识，如果IF_ID RSVP_HOP对象不存在，则由接收路径消息的接口标识。但是，在动态LSP重新路由的情况下，传入接口可能会更改。
Similarly, in both the re-merge and cross-over cases, a node will receive a Path message for a given P2MP LSP identifying a different incoming interface for the data, and the node needs to be able to distinguish between dynamic LSP re-routing and the re- merge/cross-over cases.
类似地，在重新合并和交叉情况下，节点将收到给定P2MP LSP的路径消息，该消息标识数据的不同传入接口，并且节点需要能够区分动态LSP重新路由和重新合并/交叉情况。
Make-before-break represents yet another similar but different case, in that the incoming interface associated with the make-before-break P2MP LSP may be different than that associated with the original P2MP LSP. However, the two P2MP LSPs will be treated as distinct (but related) LSPs because they will have different LSP ID field values in their SENDER_TEMPLATE objects.
先接通后断表示另一种类似但不同的情况，即与先接通后断P2MP LSP关联的传入接口可能不同于与原始P2MP LSP关联的接口。但是，这两个P2MP LSP将被视为不同（但相关）的LSP，因为它们在发送方模板对象中具有不同的LSP ID字段值。
When a node receives a Path message, it MUST check whether it has matching state for the P2MP LSP. Matching state is identified by comparing the SESSION and SENDER_TEMPLATE objects in the received Path message with the SESSION and SENDER_TEMPLATE objects of each locally maintained P2MP LSP Path state. The P2MP ID, Tunnel ID, and Extended Tunnel ID in the SESSION object and the sender address and LSP ID in the SENDER_TEMPLATE object are used for the comparison. If the node has matching state, and the incoming interface for the received Path message is different than the incoming interface of the matching P2MP LSP Path state, then the node MUST determine whether it is dealing with dynamic LSP rerouting or re-merge/cross-over.
当节点收到Path消息时，它必须检查是否具有P2MP LSP的匹配状态。通过将接收到的路径消息中的会话和发送方_模板对象与每个本地维护的P2MP LSP路径状态的会话和发送方_模板对象进行比较，识别匹配状态。会话对象中的P2MP ID、隧道ID和扩展隧道ID以及发送方模板对象中的发送方地址和LSP ID用于比较。如果节点具有匹配状态，并且接收到的路径消息的传入接口不同于匹配的P2MP LSP路径状态的传入接口，则节点必须确定它是处理动态LSP重新路由还是重新合并/交叉。
Dynamic LSP rerouting is identified by checking whether there is any intersection between the set of S2L_SUB_LSP objects associated with the matching P2MP LSP Path state and the set of S2L_SUB_LSP objects in the received Path message. If there is any intersection, then dynamic re-routing has occurred. If there is no intersection between the two sets of S2L_SUB_LSP objects, then either re-merge or cross-over has occurred. (Note that in the case of dynamic LSP rerouting, Path messages for the non-intersecting members of set of S2L_SUB_LSPs associated with the matching P2MP LSP Path state will be received subsequently on the new incoming interface.)
通过检查与匹配的P2MP LSP路径状态相关联的S2L_SUB_LSP对象集与接收到的路径消息中的S2L_SUB_LSP对象集之间是否存在交集来识别动态LSP重路由。如果存在任何交叉口，则发生了动态重新布线。如果两组S2L_SUB_LSP对象之间没有交集，则会发生重新合并或交叉。（注意，在动态LSP重路由的情况下，与匹配的P2MP LSP路径状态相关联的S2L_SUB_LSP集合的非相交成员的路径消息将随后在新的传入接口上接收。）
In order to identify the re-merge case, the node processing the received Path message MUST identify the outgoing interfaces associated with the matching P2MP Path state. Re-merge has occurred if there is any intersection between the set of outgoing interfaces associated with the matching P2MP LSP Path state and the set of outgoing interfaces in the received Path message.
为了识别重新合并情况，处理接收到的路径消息的节点必须识别与匹配的P2MP路径状态关联的传出接口。如果与匹配的P2MP LSP路径状态关联的传出接口集与接收到的路径消息中的传出接口集之间存在任何交集，则会发生重新合并。
There are two approaches to dealing with the re-merge case. In the first, the node detecting the re-merge case, i.e., the re-merge node, allows the re-merge case to persist, but data from all but one incoming interface is dropped at the re-merge node. In the second, the re-merge node initiates the removal of the re-merge branch(es) via signaling. Which approach is used is a matter of local policy.
处理重新合并案件有两种方法。在第一种情况下，检测到重新合并情况的节点（即，重新合并节点）允许重新合并情况持续存在，但是来自除一个传入接口之外的所有接口的数据都被丢弃在重新合并节点上。在第二种情况下，重新合并节点通过信令发起重新合并分支的移除。采用哪种方法取决于当地政策。
A node MUST support both approaches and MUST allow user configuration of which approach is to be used.
节点必须支持这两种方法，并且必须允许用户配置要使用的方法。
When configured to allow a re-merge case to persist, the re-merge node MUST validate consistency between the objects included in the received Path message and the matching P2MP LSP Path state. Any inconsistencies MUST result in a PathErr message sent to the previous hop of the received Path message. The Error Code is set to "Routing Problem", and the Error Value is set to "P2MP Re-Merge Parameter Mismatch".
当配置为允许重新合并案例持续存在时，重新合并节点必须验证接收到的路径消息中包含的对象与匹配的P2MP LSP路径状态之间的一致性。任何不一致都必须导致PathErr消息发送到所接收路径消息的上一个跃点。错误代码设置为“路由问题”，错误值设置为“P2MP重新合并参数不匹配”。
If there are no inconsistencies, the node logically merges, from the downstream perspective, the control state of incoming Path message with the matching P2MP LSP Path state. Specifically, procedures related to processing of messages received from upstream MUST NOT be modified from the upstream perspective; this includes processing related to refresh and state timeout. In addition to the standard upstream related procedures, the node MUST ensure that each object received from upstream is appropriately represented within the set of Path messages sent downstream. For example, the received <S2L sub-LSP descriptor list> MUST be included in the set of outgoing Path messages. If there are any NOTIFY_REQUEST objects present, then the procedures defined in section 8 MUST be followed for all Path and Resv messages. Special processing is also required for Resv processing. Specifically, any Resv message received from downstream MUST be mapped into an outgoing Resv message that is sent to the previous hop of the received Path message. In practice, this translates to decomposing the complete <S2L sub-LSP descriptor list> into subsets that match the incoming Path messages, and then constructing an outgoing Resv message for each incoming Path message.
如果不存在不一致性，则从下游的角度来看，节点在逻辑上将传入路径消息的控制状态与匹配的P2MP LSP路径状态合并。具体而言，不得从上游角度修改与处理从上游接收的消息相关的程序；这包括与刷新和状态超时相关的处理。除了标准的上游相关程序外，节点还必须确保从上游接收到的每个对象在向下游发送的路径消息集中得到适当的表示。例如，接收的<S2L子LSP描述符列表>必须包含在传出路径消息集中。如果存在任何NOTIFY_请求对象，则所有Path和Resv消息必须遵循第8节中定义的过程。Resv处理也需要特殊处理。具体而言，从下游接收的任何Resv消息必须映射到发送到接收到的Path消息的前一跳的传出Resv消息。实际上，这转化为将完整的<S2L子LSP描述符列表>分解为与传入路径消息匹配的子集，然后为每个传入路径消息构造传出Resv消息。
When configured to allow a re-merge case to persist, the re-merge node receives data associated with the P2MP LSP on multiple incoming interfaces, but it MUST only send the data from one of these interfaces to its outgoing interfaces. That is, the node MUST drop data from all but one incoming interface. This ensures that duplicate data is not sent on any outgoing interface. The mechanism used to select the incoming interface is implementation specific and is outside the scope of this document.
当配置为允许重新合并案例持续存在时，重新合并节点在多个传入接口上接收与P2MP LSP关联的数据，但它必须仅将这些接口之一的数据发送到其传出接口。也就是说，节点必须从除一个传入接口之外的所有接口中删除数据。这可确保不会在任何传出接口上发送重复数据。用于选择传入接口的机制是特定于实现的，不在本文档的范围内。
When configured to correct the re-merge branch via signaling, the re-merge node MUST send a PathErr message corresponding to the received Path message. The PathErr message MUST include all of the objects normally included in a PathErr message, as well as one or more S2L_SUB_LSP objects from the set of sub-LSPs associated with the matching P2MP LSP Path state. A minimum of three S2L_SUB_LSP objects is RECOMMENDED. This will allow the node that caused the re-merge to identify the outgoing Path state associated with the valid portion of
当配置为通过信令更正重新合并分支时，重新合并节点必须发送与接收到的Path消息相对应的PathErr消息。PathErr消息必须包括PathErr消息中通常包含的所有对象，以及与匹配P2MP LSP路径状态关联的子LSP集合中的一个或多个S2L_SUB_LSP对象。建议至少使用三个S2L_SUB_LSP对象。这将允许导致重新合并的节点识别与有效部分关联的传出路径状态
the P2MP LSP. The set of S2L_SUB_LSP objects in the received Path message MUST also be included. The PathErr message MUST include the Error Code "Routing Problem" and Error Value of "P2MP Re-Merge Detected". The node MAY set the Path_State_Removed flag [RFC3473]. As is always the case, the PathErr message is sent to the previous hop of the received Path message.
P2MP LSP。还必须包括接收到的路径消息中的S2L_SUB_LSP对象集。PathErr消息必须包括错误代码“路由问题”和错误值“检测到P2MP重新合并”。节点可以设置路径状态移除标志[RFC3473]。与往常一样，PathErr消息被发送到接收到的Path消息的上一个跃点。
A node that receives a PathErr message that contains the Error Value "Routing Problem/P2MP Re-Merge Detected" MUST determine if it is the node that created the re-merge case. This is done by checking whether there is any intersection between the set of S2L_SUB_LSP objects associated with the matching P2MP LSP Path state and the set of other-branch S2L_SUB_LSP objects in the received PathErr message. If there is, then the node created the re-merge case. Other-branch S2L_SUB_LSP objects are those S2L_SUB_LSP objects included, by the node detecting the re-merge case, in the PathErr message that were taken from the matching P2MP LSP Path state. Such S2L_SUB_LSP objects are identifiable as they will not be included in the Path message associated with the received PathErr message. See section 11.1 for more details on how such an association is identified.
接收包含错误值“Routing Problem/P2MP Re Merge Detected”的PathErr消息的节点必须确定是否是创建重新合并案例的节点。这是通过检查与匹配的P2MP LSP路径状态关联的S2L_SUB_LSP对象集与接收到的PathErr消息中的其他分支S2L_SUB_LSP对象集之间是否存在交集来完成的。如果存在，则节点创建了重新合并案例。其他分支S2L_SUB_LSP对象是检测重新合并情况的节点从匹配的P2MP LSP路径状态获取的PathErr消息中包括的那些S2L_SUB_LSP对象。此类S2L_SUB_LSP对象是可识别的，因为它们不会包含在与接收到的PathErr消息关联的路径消息中。有关如何识别此类关联的更多详细信息，请参见第11.1节。
The node SHOULD remove the re-merge case by moving the S2L_SUB_LSP objects included in the Path message associated with the received PathErr message to the outgoing interface associated with the matching P2MP LSP Path state. A trigger Path message for the moved S2L_SUB_LSP objects is then sent via that outgoing interface. If the received PathErr message did not have the Path_State_Removed flag set, the node SHOULD send a PathTear via the outgoing interface associated with the re-merge branch.
节点应通过将与接收到的PathErr消息关联的路径消息中包含的S2L_SUB_LSP对象移动到与匹配的P2MP LSP路径状态关联的传出接口来删除重新合并案例。移动的S2L_SUB_LSP对象的触发路径消息随后通过该传出接口发送。如果收到的PathErr消息未设置Path_State_Removed标志，则节点应通过与重新合并分支关联的传出接口发送Path撕裂。
If use of a new outgoing interface violates one or more SERO constraints, then a PathErr message containing the associated egresses and any identified S2L_SUB_LSP objects SHOULD be generated with the Error Code "Routing Problem" and Error Value of "ERO Resulted in Re-Merge".
如果使用新的传出接口违反一个或多个SERO约束，则应生成包含相关出口和任何已识别S2L_SUB_LSP对象的PathErr消息，错误代码为“Routing Problem”，错误值为“ERO Resulted in Re Merge”。
The only case where this process will fail is when all the listed S2L_SUB_LSP objects are deleted prior to the PathErr message propagating to the ingress. In this case, the whole process will be corrected on the next (refresh or trigger) transmission of the offending Path message.
此过程将失败的唯一情况是，在PathErr消息传播到入口之前删除所有列出的S2L_SUB_LSP对象。在这种情况下，整个过程将在下一次（刷新或触发）传输有问题的Path消息时得到纠正。
This section presents the RSVP object formats as modified by this document.
本节介绍本文档修改的RSVP对象格式。
A P2MP LSP SESSION object is used. This object uses the existing SESSION C-Num. New C-Types are defined to accommodate a logical P2MP destination identifier of the P2MP tunnel. This SESSION object has a similar structure as the existing point-to-point RSVP-TE SESSION object. However the destination address is set to the P2MP ID instead of the unicast Tunnel Endpoint address. All S2L sub-LSPs that are part of the same P2MP LSP share the same SESSION object. This SESSION object identifies the P2MP tunnel.
使用P2MP LSP会话对象。此对象使用现有会话C-Num。定义新的C-TYPE以容纳P2MP隧道的逻辑P2MP目标标识符。此会话对象的结构与现有的点对点RSVP-TE会话对象类似。但是，目标地址设置为P2MP ID，而不是单播隧道端点地址。属于同一P2MP LSP的所有S2L子LSP共享同一会话对象。此会话对象标识P2MP隧道。
The combination of the SESSION object, the SENDER_TEMPLATE object and the S2L_SUB_LSP object identifies each S2L sub-LSP. This follows the existing P2P RSVP-TE notion of using the SESSION object for identifying a P2P Tunnel, which in turn can contain multiple LSPs, each distinguished by a unique SENDER_TEMPLATE object.
会话对象、发送方_模板对象和S2L_子_LSP对象的组合标识每个S2L子LSP。这遵循了现有的P2P RSVP-TE概念，即使用会话对象来识别P2P隧道，而P2P隧道又可以包含多个LSP，每个LSP都由唯一的发送方\模板对象来区分。
Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = 13
类=会话，P2MP\U LSP\U隧道\U IPv4 C-Type=13
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P2MP ID A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. It encodes the P2MP Identifier that is unique within the scope of the ingress LSR.
P2MP ID会话对象中使用的32位标识符，在P2MP隧道的生命周期内保持不变。它编码在入口LSR范围内唯一的P2MP标识符。
Tunnel ID A 16-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel.
隧道ID会话对象中使用的16位标识符，在P2MP隧道的生命周期内保持不变。
Extended Tunnel ID A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. Ingress LSRs that wish to have a globally unique identifier for the P2MP tunnel SHOULD place their tunnel sender address here. A combination of this address, P2MP ID, and Tunnel ID provides a globally unique identifier for the P2MP tunnel.
扩展隧道ID会话对象中使用的32位标识符，在P2MP隧道的生命周期内保持不变。希望P2MP隧道具有全局唯一标识符的入口LSR应将其隧道发送方地址放在此处。此地址、P2MP ID和隧道ID的组合为P2MP隧道提供全局唯一标识符。
This is the same as the P2MP IPv4 LSP SESSION object with the difference that the extended tunnel ID may be set to a 16-byte identifier [RFC3209].
这与P2MP IPv4 LSP会话对象相同，不同之处在于扩展隧道ID可以设置为16字节标识符[RFC3209]。
Class = SESSION, P2MP_LSP_TUNNEL_IPv6 C-Type = 14
类=会话，P2MP\U LSP\U隧道\U IPv6 C-Type=14
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (16 bytes) |
| |
| ....... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (16 bytes) |
| |
| ....... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SENDER_TEMPLATE object contains the ingress LSR source address. The LSP ID can be changed to allow a sender to share resources with itself. Thus, multiple instances of the P2MP tunnel can be created, each with a different LSP ID. The instances can share resources with each other. The S2L sub-LSPs corresponding to a particular instance use the same LSP ID.
SENDER_TEMPLATE对象包含入口LSR源地址。可以更改LSP ID以允许发件人与其自身共享资源。因此，可以创建P2MP隧道的多个实例，每个实例具有不同的LSP ID。这些实例可以彼此共享资源。对应于特定实例的S2L子LSP使用相同的LSP ID。
As described in section 4.2, it is necessary to distinguish different Path messages that are used to signal state for the same P2MP LSP by using a <Sub-Group ID Originator ID, Sub-Group ID> tuple. The SENDER_TEMPLATE object is modified to carry this information as shown below.
如第4.2节所述，有必要通过使用<Sub-Group ID Originator ID，Sub-Group ID>元组来区分用于向同一P2MP LSP发送状态信号的不同路径消息。将修改SENDER_TEMPLATE对象以携带此信息，如下所示。
Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = 12
类=发送方\模板，P2MP\ LSP\隧道\ IPv4 C-Type=12
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Group Originator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub-Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Group Originator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub-Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 tunnel sender address See [RFC3209].
IPv4隧道发送方地址请参阅[RFC3209]。
Sub-Group Originator ID The Sub-Group Originator ID is set to the TE Router ID of the LSR that originates the Path message. This is either the ingress LSR or an LSR which re-originates the Path message with its own Sub-Group Originator ID.
子组发起人ID子组发起人ID设置为发起Path消息的LSR的TE路由器ID。这是入口LSR或使用其自己的子组发起人ID重新发起路径消息的LSR。
Sub-Group ID An identifier of a Path message used to differentiate multiple Path messages that signal state for the same P2MP LSP. This may be seen as identifying a group of one or more egress nodes targeted by this Path message.
子组ID路径消息的标识符，用于区分为同一P2MP LSP发送状态信号的多条路径消息。这可被视为识别该路径消息所针对的一个或多个出口节点的组。
LSP ID See [RFC3209].
LSP ID见[RFC3209]。
Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = 13
类=发送方\模板，P2MP\ LSP\隧道\ IPv6 C-Type=13
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Sub-Group Originator ID |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub-Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Sub-Group Originator ID |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub-Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 tunnel sender address See [RFC3209].
IPv6隧道发送方地址请参阅[RFC3209]。
Sub-Group Originator ID The Sub-Group Originator ID is set to the IPv6 TE Router ID of the LSR that originates the Path message. This is either the ingress LSR or an LSR which re-originates the Path message with its own Sub-Group Originator ID.
子组发起人ID子组发起人ID设置为发起路径消息的LSR的IPv6 TE路由器ID。这是入口LSR或使用其自己的子组发起人ID重新发起路径消息的LSR。
Sub-Group ID As above in section 19.2.1.
第19.2.1节中的子组ID。
LSP ID See [RFC3209].
LSP ID见[RFC3209]。
An S2L_SUB_LSP object identifies a particular S2L sub-LSP belonging to the P2MP LSP.
S2L_SUB_LSP对象标识属于P2MP LSP的特定S2L SUB LSP。
S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv4 C-Type = 1
S2L_SUB_LSP Class=50，S2L_SUB_LSP_IPv4 C-Type=1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 S2L Sub-LSP destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 S2L Sub-LSP destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Sub-LSP destination address IPv4 address of the S2L sub-LSP destination.
IPv4子LSP目标地址S2L子LSP目标的IPv4地址。
S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv6 C-Type = 2
S2L_SUB_LSP Class=50，S2L_SUB_LSP_IPv6 C-Type=2
This is the same as the S2L IPv4 Sub-LSP object, with the difference that the destination address is a 16-byte IPv6 address.
这与S2L IPv4子LSP对象相同，不同之处在于目标地址是一个16字节的IPv6地址。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 S2L Sub-LSP destination address (16 bytes) |
| .... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 S2L Sub-LSP destination address (16 bytes) |
| .... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE object.
FILTER_SPEC对象是P2MP SENDER_TEMPLATE对象的标准对象。
Class = FILTER_SPEC, P2MP LSP_IPv4 C-Type = 12
类别=过滤器规格，P2MP LSP\U IPv4 C类型=12
The format of the P2MP LSP_IPv4 FILTER_SPEC object is identical to the P2MP LSP_IPv4 SENDER_TEMPLATE object.
P2MP LSP_IPv4筛选器_规范对象的格式与P2MP LSP_IPv4发送者_模板对象的格式相同。
Class = FILTER_SPEC, P2MP LSP_IPv6 C-Type = 13
类=过滤器规格，P2MP LSP\U IPv6 C型=13
The format of the P2MP LSP_IPv6 FILTER_SPEC object is identical to the P2MP LSP_IPv6 SENDER_TEMPLATE object.
P2MP LSP_IPv6筛选器_规范对象的格式与P2MP LSP_IPv6发送者_模板对象的格式相同。
The P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) is defined as identical to the ERO. The class of the P2MP SERO is the same as the SERO defined in [RFC4873]. The P2MP SERO uses a new C-Type = 2. The sub-objects are identical to those defined for the ERO.
P2MP次要路由对象（SERO）定义为与ERO相同。P2MP血清的类别与[RFC4873]中定义的血清相同。P2MP血清使用新的C型=2。子对象与为ERO定义的子对象相同。
The P2MP SECONDARY_RECORD_ROUTE Object (SRRO) is defined as identical to the ERO. The class of the P2MP SRRO is the same as the SRRO defined in [RFC4873]. The P2MP SRRO uses a new C-Type = 2. The sub-objects are identical to those defined for the RRO.
P2MP次要记录路由对象（SRRO）定义为与ERO相同。P2MP SRRO的等级与[RFC4873]中定义的SRRO相同。P2MP SRRO使用新的C型=2。子对象与为RRO定义的子对象相同。
IANA has assigned the following Class Numbers for the new object classes introduced. The Class Types for each of them are to be assigned via standards action. The sub-object types for the P2MP SECONDARY_EXPLICIT_ROUTE and P2MP_SECONDARY_RECORD_ROUTE follow the same IANA considerations as those of the ERO and RRO [RFC3209].
IANA为引入的新对象类指定了以下类号。每个类的类类型将通过标准操作分配。P2MP次要_显式_路由和P2MP_次要_记录_路由的子对象类型遵循与ERO和RRO相同的IANA注意事项[RFC3209]。
50 Class Name = S2L_SUB_LSP
50类名称=S2L\U子\U LSP
C-Type 1 S2L_SUB_LSP_IPv4 C-Type 2 S2L_SUB_LSP_IPv6 C-Type
C-Type 1 S2L_SUB_LSP_IPv4 C-Type 2 S2L_SUB_LSP_IPv6 C-Type
IANA has assigned the following C-Type values:
IANA已分配以下C型值：
Class Name = SESSION
类名=会话
C-Type 13 P2MP_LSP_TUNNEL_IPv4 C-Type 14 P2MP_LSP_TUNNEL_IPv6 C-Type
C-Type 13 P2MP_LSP_TUNNEL_IPv4 C-Type 14 P2MP_LSP_TUNNEL_IPv6 C-Type
Class Name = SENDER_TEMPLATE
类名=发送方\模板
C-Type 12 P2MP_LSP_TUNNEL_IPv4 C-Type 13 P2MP_LSP_TUNNEL_IPv6 C-Type
C-Type 12 P2MP_LSP_TUNNEL_IPv4 C-Type 13 P2MP_LSP_TUNNEL_IPv6 C-Type
Class Name = FILTER_SPEC
类名=过滤器\规格
C-Type 12 P2MP LSP_IPv4 C-Type 13 P2MP LSP_IPv6 C-Type
C-Type 12 P2MP LSP_IPv4 C-Type 13 P2MP LSP_IPv6 C-Type
Class Name = SECONDARY_EXPLICIT_ROUTE (Defined in [RFC4873])
类名=次要显式路由（在[RFC4873]中定义）
C-Type 2 P2MP SECONDARY_EXPLICIT_ROUTE C-Type
C-Type 2 P2MP次级\u显式\u路由C-Type
Class Name = SECONDARY_RECORD_ROUTE (Defined in [RFC4873])
类名=辅助记录路由（在[RFC4873]中定义）
C-Type 2 P2MP_SECONDARY_RECORD_ROUTE C-Type
C-Type 2 P2MP_次要_记录_路线C-Type
Five new Error Values are defined for use with the Error Code "Routing Problem". IANA has assigned values for them as follows.
定义了五个新的错误值，用于错误代码“路由问题”。IANA为它们指定了如下值。
The Error Value "Unable to Branch" indicates that a P2MP branch cannot be formed by the reporting LSR. IANA has assigned value 23 to this Error Value.
错误值“无法分支”表示报告LSR无法形成P2MP分支。IANA已将值23指定给此错误值。
The Error Value "Unsupported LSP Integrity" indicates that a P2MP branch does not support the requested LSP integrity function. IANA has assigned value 24 to this Error Value.
错误值“Unsupported LSP Integrity”表示P2MP分支不支持请求的LSP Integrity函数。IANA已将值24指定给此错误值。
The Error Value "P2MP Re-Merge Detected" indicates that a node has detected re-merge. IANA has assigned value 25 to this Error Value.
错误值“P2MP检测到重新合并”表示节点检测到重新合并。IANA已将值25指定给此错误值。
The Error Value "P2MP Re-Merge Parameter Mismatch" is described in section 18. IANA has assigned value 26 to this Error Value.
第18节描述了错误值“P2MP重新合并参数不匹配”。IANA已将值26指定给此错误值。
The Error Value "ERO Resulted in Re-Merge" is described in section 18. IANA has assigned value 27 to this Error Value.
第18节描述了错误值“ERO导致重新合并”。IANA已将值27指定给此错误值。
IANA has been asked to manage the space of flags in the Attributes Flags TLV carried in the LSP_REQUIRED_ATTRIBUTES object [RFC4420]. This document defines a new flag as follows:
已要求IANA管理LSP_REQUIRED_Attributes对象[RFC4420]中携带的属性标志TLV中的标志空间。本文件定义了一个新标志，如下所示：
Bit Number: 3 Meaning: LSP Integrity Required Used in Attributes Flags on Path: Yes Used in Attributes Flags on Resv: No Used in Attributes Flags on RRO: No Referenced Section of this Doc: 5.2.4
位号：3意味着：路径上的属性标志中使用的LSP完整性要求：Resv上的属性标志中使用的是：RRO上的属性标志中使用的否：本文件的无引用部分：5.2.4
In principle this document does not introduce any new security issues above those identified in [RFC3209], [RFC3473], and [RFC4206]. [RFC2205] specifies the message integrity mechanisms for hop-by-hop RSVP signaling. These mechanisms apply to the hop-by-hop P2MP RSVP-TE signaling in this document. Further, [RFC3473] and [RFC4206] specify the security mechanisms for non hop-by-hop RSVP-TE signaling. These mechanisms apply to the non hop-by-hop P2MP RSVP-TE signaling specified in this document, particularly in sections 16 and 17.
原则上，本文件不会在[RFC3209]、[RFC3473]和[RFC4206]中确定的安全问题之上引入任何新的安全问题。[RFC2205]指定逐跳RSVP信令的消息完整性机制。这些机制适用于本文档中逐跳P2MP RSVP-TE信令。此外，[RFC3473]和[RFC4206]指定了非逐跳RSVP-TE信令的安全机制。这些机制适用于本文件特别是第16节和第17节中规定的非逐跳P2MP RSVP-TE信令。
An administration may wish to limit the domain over which P2MP TE tunnels can be established. This can be accomplished by setting filters on various ports to deny action on a RSVP path message with a SESSION object of type P2MP_LSP_IPv4 or P2MP_LSP_IPv6.
管理部门可能希望限制可以建立P2MP TE隧道的领域。这可以通过在各种端口上设置筛选器来实现，以拒绝对具有P2MP_LSP_IPv4或P2MP_LSP_IPv6类型的会话对象的RSVP path消息执行操作。
The ingress LSR of a P2MP TE LSP determines the leaves of the P2MP TE LSP based on the application of the P2MP TE LSP. The specification of how such applications will use a P2MP TE LSP is outside the scope of this document. Applications MUST provide a mechanism to notify the ingress LSR of the appropriate leaves for the P2MP LSP. Specifications of applications within the IETF MUST specify this mechanism in sufficient detail that an ingress LSR from one vendor can be used with an application implementation provided by another vendor. Manual configuration of security parameters when other parameters are auto-discovered is generally not sufficient to meet security and interoperability requirements of IETF specifications.
P2MP TE LSP的入口LSR根据P2MP TE LSP的应用确定P2MP TE LSP的叶。此类应用程序如何使用P2MP TE LSP的规范不在本文档范围内。应用程序必须提供一种机制来通知入口LSR P2MP LSP的适当叶。IETF内的应用程序规范必须详细说明该机制，以便一个供应商的入口LSR可以与另一个供应商提供的应用程序实现一起使用。当自动发现其他参数时，手动配置安全参数通常不足以满足IETF规范的安全性和互操作性要求。
This document is the product of many people. The contributors are listed in Appendix B.
这份文件是许多人的成果。贡献者在附录B中列出。
Thanks to Yakov Rekhter, Der-Hwa Gan, Arthi Ayyanger, and Nischal Sheth for their suggestions and comments. Thanks also to Dino Farninacci and Benjamin Niven for their comments.
感谢亚科夫·雷克特、德华根、阿尔西·艾扬格和尼沙尔·谢思的建议和评论。还要感谢迪诺·法尼纳奇和本杰明·尼文的评论。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，2005年10月。
[RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A. Ayyangar, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, February 2006.
[RFC4420]Farrel，A.，Ed.，Papadimitriou，D.，Vasseur，J.-P.，和A.Ayyangar，“使用资源预留协议流量工程（RSVP-TE）建立多协议标签交换（MPLS）标签交换路径（LSP）的属性编码”，RFC 4420，2006年2月。
[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月。
[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月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961]Berger，L.，Gan，D.，Swallow，G.，Pan，P.，Tommasi，F.，和S.Molendini，“RSVP刷新开销减少扩展”，RFC 29612001年4月。
[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月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477]Kompella，K.和Y.Rekhter，“资源预留协议中未编号链路的信令-流量工程（RSVP-TE）”，RFC 3477，2003年1月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, April 2007.
[RFC4873]Berger，L.，Bryskin，I.，Papadimitriou，D.，和A.Farrel，“GMPLS段恢复”，RFC 4873，2007年4月。
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[RFC4461]Yasukawa，S.，Ed.“点对多点流量工程MPLS标签交换路径（LSP）的信令要求”，RFC 4461，2006年4月。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, March 2007.
[BFD]Katz，D.和D.Ward，“双向转发检测”，正在进行的工作，2007年3月。
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD for MPLS LSPs", Work in Progress, March 2007.
[BFD-MPLS]Aggarwal，R.，Kompella，K.，Nadeau，T.，和G.Swallow，“MPLS LSP的BFD”，正在进行的工作，2007年3月。
[LSP-STITCH] Ayyanger, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", Work in Progress, March 2007.
[LSP-STITCH]Ayyanger，A.，Kompella，K.，Vasseur，JP.，和A.Farrel，“使用通用多协议标签交换流量工程（GMPLS TE）的标签交换路径缝合”，正在进行的工作，2007年3月。
[TE-NODE-CAP] Vasseur, JP., Ed., Le Roux, JL., Ed., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", Work in Progress, April 2007.
[TE-NODE-CAP]Vasseur，JP.，Ed.，Le Roux，JL.，Ed.，“用于发现流量工程节点能力的IGP路由协议扩展”，正在进行的工作，2007年4月。
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", RFC 4003, February 2005.
[RFC4003]Berger，L.，“出口控制的GMPLS信号程序”，RFC 4003，2005年2月。
The Following is one example of setting up a P2MP LSP using the procedures described in this document.
以下是使用本文档中描述的步骤设置P2MP LSP的一个示例。
Source 1 (S1)
|
PE1
| |
|L5 |
P3 |
| |
L3 |L1 |L2
R2----PE3--P1 P2---PE2--Receiver 1 (R1)
| L4
PE5----PE4----R3
|
|
R4
Source 1 (S1)
|
PE1
| |
|L5 |
P3 |
| |
L3 |L1 |L2
R2----PE3--P1 P2---PE2--Receiver 1 (R1)
| L4
PE5----PE4----R3
|
|
R4
Figure 2.
图2。
The mechanism is explained using Figure 2. PE1 is the ingress LSR. PE2, PE3, and PE4 are egress LSRs.
使用图2解释了该机制。PE1是入口LSR。PE2、PE3和PE4是出口LSR。
a) PE1 learns that PE2, PE3, and PE4 are interested in joining a P2MP tree with a P2MP ID of P2MP ID1. We assume that PE1 learns of the egress LSRs at different points in time.
a) PE1了解到PE2、PE3和PE4有兴趣加入P2MP ID为P2MP ID1的P2MP树。我们假设PE1在不同的时间点学习出口LSR。
b) PE1 computes the P2P path to reach PE2.
b) PE1计算到达PE2的P2P路径。
c) PE1 establishes the S2L sub-LSP to PE2 along <PE1, P2, PE2>.
c) PE1沿<PE1，P2，PE2>建立S2L子LSP至PE2。
d) PE1 computes the P2P path to reach PE3 when it discovers PE3. This path is computed to share the same links where possible with the sub-LSP to PE2 as they belong to the same P2MP session.
d) PE1在发现PE3时计算到达PE3的P2P路径。计算此路径以尽可能与PE2的子LSP共享相同的链路，因为它们属于相同的P2MP会话。
e) PE1 establishes the S2L sub-LSP to PE3 along <PE1, P3, P1, PE3>.
e) PE1沿<PE1，P3，P1，PE3>建立S2L子LSP至PE3。
f) PE1 computes the P2P path to reach PE4 when it discovers PE4. This path is computed to share the same links where possible with the sub-LSPs to PE2 and PE3 as they belong to the same P2MP session.
f) PE1在发现PE4时计算到达PE4的P2P路径。计算此路径以尽可能与PE2和PE3的子LSP共享相同的链路，因为它们属于相同的P2MP会话。
g) PE1 signals the Path message for PE4 sub-LSP along <PE1, P3, P1, PE4>.
g) PE1沿<PE1，P3，P1，PE4>向PE4子LSP的路径消息发送信号。
h) P1 receives a Resv message from PE4 with label L4. It had previously received a Resv message from PE3 with label L3. It had allocated a label L1 for the sub-LSP to PE3. It uses the same label and sends the Resv messages to P3. Note that it may send only one Resv message with multiple flow descriptors in the flow descriptor list. If this is the case, and FF style is used, the FF flow descriptor will contain the S2L sub-LSP descriptor list with two entries: one for PE4 and the other for PE3. For SE style, the SE filter spec will contain this S2L sub-LSP descriptor list. P1 also creates a label mapping of (L1 -> {L3, L4}). P3 uses the existing label L5 and sends the Resv message to PE1, with label L5. It reuses the label mapping of {L5 -> L1}.
h) P1从PE4接收带有标签L4的Resv消息。它以前曾从PE3收到标签为L3的Resv消息。它已将子LSP的标签L1分配给PE3。它使用相同的标签并将Resv消息发送到P3。注意，在流描述符列表中，它可能只发送一条带有多个流描述符的Resv消息。如果是这种情况，并且使用了FF样式，FF流描述符将包含S2L子LSP描述符列表，其中包含两个条目：一个用于PE4，另一个用于PE3。对于SE样式，SE过滤器规范将包含此S2L子LSP描述符列表。P1还创建（L1->{L3，L4}）的标签映射。P3使用现有标签L5并将Resv消息发送至PE1，标签为L5。它重用了{L5->L1}的标签映射。
John Drake Boeing EMail: john.E.Drake2@boeing.com
波音公司电子邮件：John.E。Drake2@boeing.com
Alan Kullberg Motorola Computer Group 120 Turnpike Road 1st Floor Southborough, MA 01772 EMail: alan.kullberg@motorola.com
Alan Kullberg摩托罗拉计算机集团马萨诸塞州南区收费公路120号1楼01772电子邮件：Alan。kullberg@motorola.com
Lou Berger LabN Consulting, L.L.C. EMail: lberger@labn.net
Lou Berger LabN Consulting，L.L.C.电子邮件：lberger@labn.net
Liming Wei Redback Networks 350 Holger Way San Jose, CA 95134 EMail: lwei@redback.com
Liming Wei Redback Networks加利福尼亚州圣何塞市霍尔格路350号95134电子邮件：lwei@redback.com
George Apostolopoulos Redback Networks 350 Holger Way San Jose, CA 95134 EMail: georgeap@redback.com
George Apostolopoulos Redback Networks 350 Holger Way San Jose，CA 95134电子邮件：georgeap@redback.com
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 EMail: kireeti@juniper.net
Kireeti Kompella Juniper Networks 1194 N.Mathilda Ave Sunnyvale，CA 94089电子邮件：kireeti@juniper.net
George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA EMail: swallow@cisco.com
George Swallow Cisco Systems，Inc.美国马萨诸塞州伯斯堡市海弗布鲁克路300号-01719电子邮件：swallow@cisco.com
JP Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA EMail: jpv@cisco.com Dean Cheng Cisco Systems Inc. 170 W Tasman Dr. San Jose, CA 95134 Phone 408 527 0677 EMail: dcheng@cisco.com
JP Vasseur Cisco Systems，Inc.马萨诸塞州伯斯堡市海弗布鲁克路300号-01719美国电子邮件：jpv@cisco.comDean Cheng Cisco Systems Inc.170 W Tasman Dr.San Jose，CA 95134电话408 527 0677电子邮件：dcheng@cisco.com
Markus Jork Avici Systems 101 Billerica Avenue N. Billerica, MA 01862 Phone: +1 978 964 2142 EMail: mjork@avici.com
马库斯·乔克·阿维奇系统公司马萨诸塞州比勒里卡北比勒里卡大道101号01862电话：+1 978 964 2142电子邮件：mjork@avici.com
Hisashi Kojima NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 6070 EMail: kojima.hisashi@lab.ntt.co.jp
Hisashi Kojima NTT Corporation 9-11，Midori Cho 3-Chome Musashino Shi，东京180-8585日本电话：+81 422 59 6070电子邮件：Kojima。hisashi@lab.ntt.co.jp
Andrew G. Malis Tellabs 2730 Orchard Parkway San Jose, CA 95134 Phone: +1 408 383 7223 EMail: Andy.Malis@tellabs.com
Andrew G.Malis Tellabs 2730 Orchard Parkway San Jose，CA 95134电话：+1408 383 7223电子邮件：Andy。Malis@tellabs.com
Koji Sugisono NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 2605 EMail: sugisono.koji@lab.ntt.co.jp
Koji Sugisono NTT Corporation 9-11，Midori Cho 3-Chome Musashino Shi，东京180-8585日本电话：+81 422 59 2605电子邮件：Sugisono。koji@lab.ntt.co.jp
Masanori Uga NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 4804 EMail: uga.masanori@lab.ntt.co.jp
佐治亚州立大学NTT公司9-11，Midori Cho 3-Chome Musashino Shi，东京180-8585日本电话：+81 422 59 4804电子邮件：佐治亚大学。masanori@lab.ntt.co.jp
Igor Bryskin Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102 ibryskin@movaz.com Adrian Farrel Old Dog Consulting Phone: +44 0 1978 860944 EMail: adrian@olddog.co.uk
Igor Bryskin Movaz Networks，Inc.地址：弗吉尼亚州麦克莱恩市琼斯支路615号7926室，邮编：22102ibryskin@movaz.comAdrian Farrel老狗咨询电话：+44 0 1978 860944电子邮件：adrian@olddog.co.uk
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France EMail: jeanlouis.leroux@francetelecom.com
Jean-Louis Le Roux法国电信2号，Pierre Marzin大街22307 Lannion Cedex France电子邮件：jeanlouis。leroux@francetelecom.com
Editors' Addresses
编辑地址
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: rahul@juniper.net
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave.Sunnyvale，CA 94089电子邮件：rahul@juniper.net
Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 4769 EMail: yasukawa.seisho@lab.ntt.co.jp
日本东京武藏寺町3-Chome-Musashino-Shi，靖川正雄NTT公司9-11电话：+81 422 59 4769电子邮件：靖川。seisho@lab.ntt.co.jp
Dimitri Papadimitriou Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: Dimitri.Papadimitriou@alcatel-lucent.be
Dimitri Papadimitriou Alcatel Francis Wellesplein 1，B-2018比利时安特卫普电话：+32 3 240-8491电子邮件：Dimitri。Papadimitriou@alcatel-朗讯
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。