Internet Engineering Task Force (IETF) T. Saad, Ed.
Request for Comments: 8149 R. Gandhi, Ed.
Category: Standards Track Z. Ali
ISSN: 2070-1721 Cisco Systems, Inc.
R. Venator
Defense Information Systems Agency
Y. Kamite
NTT Communications Corporation
April 2017
Internet Engineering Task Force (IETF) T. Saad, Ed.
Request for Comments: 8149 R. Gandhi, Ed.
Category: Standards Track Z. Ali
ISSN: 2070-1721 Cisco Systems, Inc.
R. Venator
Defense Information Systems Agency
Y. Kamite
NTT Communications Corporation
April 2017
RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)
用于重新优化松散路由的点对多点流量工程标签交换路径（LSP）的RSVP扩展
Abstract
摘要
The reoptimization of a Point-to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) may be triggered based on the need to reoptimize an individual source-to-leaf (S2L) sub-LSP or a set of S2L sub-LSPs, both using the Sub-Group-based reoptimization method, or the entire P2MP-TE LSP tree using the Make-Before-Break (MBB) method. This document discusses the application of the existing mechanisms for path reoptimization of loosely routed Point-to-Point (P2P) TE LSPs to the P2MP-TE LSPs, identifies issues in doing so, and defines procedures to address them. When reoptimizing a large number of S2L sub-LSPs in a tree using the Sub-Group-based reoptimization method, the S2L sub-LSP descriptor list may need to be semantically fragmented. This document defines the notion of a fragment identifier to help recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP descriptor list.
点对多点（P2MP）业务工程（TE）标签交换路径（LSP）的重新优化可基于对单个源到叶（S2L）子LSP或一组S2L子LSP的重新优化的需要来触发，两者均使用基于子组的重新优化方法，或使用先通后断（MBB）方法来触发整个P2MP-TE LSP树。本文件讨论了将松散路由点对点（P2P）TE LSP的路径重新优化现有机制应用于P2MP-TE LSP的问题，并确定了解决这些问题的程序。当使用基于子组的重新优化方法重新优化树中的大量S2L子LSP时，S2L子LSP描述符列表可能需要在语义上分段。本文档定义了片段标识符的概念，以帮助接收方节点明确地重建片段化的S2L子LSP描述符列表。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8149.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8149.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
2.1. Key Word Definitions .......................................4
2.2. Abbreviations ..............................................4
2.3. Terminology ................................................4
3. Overview ........................................................5
3.1. Loosely Routed Inter-domain P2MP-TE LSP Tree ...............5
3.2. Existing Mechanism for Tree-Based P2MP-TE LSP
Reoptimization .............................................6
3.3. Existing Mechanism for Sub-Group-Based P2MP-TE LSP
Reoptimization .............................................7
4. Signaling Extensions for Loosely Routed P2MP-TE LSP
Reoptimization ..................................................8
4.1. Tree-Based Reoptimization ..................................8
4.2. Sub-Group-Based Reoptimization Using Fragment Identifier ...9
5. Message and Object Definitions .................................11
5.1. "P2MP-TE Tree Re-evaluation Request" Flag .................11
5.2. "Preferable P2MP-TE Tree Exists" Path Error Sub-code ......11
5.3. Fragment Identifier for S2L Sub-LSP Descriptor ............11
6. Compatibility ..................................................12
7. IANA Considerations ............................................13
7.1. "P2MP-TE Tree Re-evaluation Request" Flag .................13
7.2. "Preferable P2MP-TE Tree Exists" Path Error Sub-code ......13
7.3. Fragment Identifier for S2L Sub-LSP Descriptor ............14
8. Security Considerations ........................................14
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................16
Acknowledgments ...................................................16
Authors' Addresses ................................................17
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
2.1. Key Word Definitions .......................................4
2.2. Abbreviations ..............................................4
2.3. Terminology ................................................4
3. Overview ........................................................5
3.1. Loosely Routed Inter-domain P2MP-TE LSP Tree ...............5
3.2. Existing Mechanism for Tree-Based P2MP-TE LSP
Reoptimization .............................................6
3.3. Existing Mechanism for Sub-Group-Based P2MP-TE LSP
Reoptimization .............................................7
4. Signaling Extensions for Loosely Routed P2MP-TE LSP
Reoptimization ..................................................8
4.1. Tree-Based Reoptimization ..................................8
4.2. Sub-Group-Based Reoptimization Using Fragment Identifier ...9
5. Message and Object Definitions .................................11
5.1. "P2MP-TE Tree Re-evaluation Request" Flag .................11
5.2. "Preferable P2MP-TE Tree Exists" Path Error Sub-code ......11
5.3. Fragment Identifier for S2L Sub-LSP Descriptor ............11
6. Compatibility ..................................................12
7. IANA Considerations ............................................13
7.1. "P2MP-TE Tree Re-evaluation Request" Flag .................13
7.2. "Preferable P2MP-TE Tree Exists" Path Error Sub-code ......13
7.3. Fragment Identifier for S2L Sub-LSP Descriptor ............14
8. Security Considerations ........................................14
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................16
Acknowledgments ...................................................16
Authors' Addresses ................................................17
This document defines Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [RFC2205] [RFC3209] signaling extensions for reoptimizing loosely routed Point-to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Paths (LSPs) [RFC4875] in a Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) [RFC3473] network.
本文档定义了资源预留协议-流量工程（RSVP-TE）[RFC2205][RFC3209]信令扩展，用于在多协议标签交换（MPLS）或通用MPLS（GMPLS）[RFC3473]网络中重新优化松散路由的点对多点（P2MP）流量工程（TE）标签交换路径（LSP）[RFC4875]。
A P2MP-TE LSP is comprised of one or more source-to-leaf (S2L) sub-LSPs. A loosely routed P2MP-TE S2L sub-LSP is defined as one whose path does not contain the full explicit route identifying each node along the path to the egress node at the time of its signaling by the ingress node. Such an S2L sub-LSP is signaled with no Explicit Route Object (ERO) [RFC3209], with an ERO that contains at least one "loose next hop", or with an ERO that contains an abstract node that identifies more than one node. This is often the case with inter-domain P2MP-TE LSPs where a Path Computation Element (PCE) is not used [RFC5440].
P2MP-TE LSP由一个或多个源到叶（S2L）子LSP组成。松散路由的P2MP-TE S2L子LSP被定义为其路径不包含在入口节点发信号时识别沿路径到出口节点的每个节点的完整显式路由的子LSP。这样的S2L子LSP不使用显式路由对象（ERO）[RFC3209]，使用包含至少一个“松散下一跳”的ERO，或使用包含标识多个节点的抽象节点的ERO来发信号。这通常是域间P2MP-TE LSP的情况，其中未使用路径计算元素（PCE）[RFC5440]。
As per [RFC4875], an ingress node may reoptimize the entire P2MP-TE LSP tree by re-signaling all its S2L sub-LSPs using the Make-Before-Break (MBB) method, or it may reoptimize an individual S2L sub-LSP or a set of S2L sub-LSPs, i.e., an individual destination or a set of destinations, both using the Sub-Group-based reoptimization method.
根据[RFC4875]，入口节点可以通过使用先通后断（MBB）方法重新发送其所有S2L子LSP来重新优化整个P2MP-TE LSP树，或者可以使用基于子组的重新优化方法来重新优化单个S2L子LSP或一组S2L子LSP，即单个目的地或一组目的地。
[RFC4736] defines an RSVP signaling procedure for reoptimizing the path(s) of loosely routed Point-to-Point (P2P) TE LSP(s). The mechanisms listed in [RFC4736] include a method for the ingress node to trigger a new path re-evaluation request and a method for the midpoint node to send a notification regarding the availability of a preferred path. This document discusses the application of those mechanisms to the reoptimization of loosely routed P2MP-TE LSPs, identifies issues in doing so, and defines procedures to address them.
[RFC4736]定义了一个RSVP信令过程，用于重新优化松散路由的点对点（P2P）TE LSP的路径。[RFC4736]中列出的机制包括入口节点触发新路径重新评估请求的方法和中点节点发送关于首选路径可用性的通知的方法。本文档讨论了这些机制在重新优化松散路由P2MP-TE LSP中的应用，确定了执行过程中的问题，并定义了解决这些问题的程序。
For reoptimizing a group of S2L sub-LSPs in a tree using the Sub-Group-based reoptimization method, an S2L sub-LSP descriptor list can be used to signal one or more S2L sub-LSPs in an RSVP message. This RSVP message may need to be semantically fragmented when a large number of S2L sub-LSPs are added to the descriptor list. This document defines the notion of a fragment identifier to help recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP descriptor list.
为了使用基于子组的重新优化方法来重新优化树中的一组S2L子LSP，可以使用S2L子LSP描述符列表来向RSVP消息中的一个或多个S2L子LSP发送信号。当大量S2L子LSP添加到描述符列表时，可能需要对该RSVP消息进行语义分段。本文档定义了片段标识符的概念，以帮助接收方节点明确地重建片段化的S2L子LSP描述符列表。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
ABR: Area Border Router.
区域边界路由器。
ERO: Explicit Route Object.
ERO：显式路由对象。
LSP: Label Switched Path.
标签交换路径。
LSR: Label Switching Router.
标签交换路由器。
RRO: Record Route Object.
记录路由对象。
S2L sub-LSP: Source-to-leaf sub-LSP.
S2L子LSP：源到叶子LSP。
TE LSP: Traffic Engineering LSP.
TE LSP：交通工程LSP。
This document defines the following terms:
本文件定义了以下术语：
o Ingress node: Head-end / source node of the TE LSP.
o 入口节点：TE LSP的前端/源节点。
o Egress node: Tail-end / destination node of the TE LSP.
o 出口节点：TE LSP的尾端/目的地节点。
It is assumed that the reader is also familiar with the terminology in [RFC4736] and [RFC4875].
假定读者也熟悉[RFC4736]和[RFC4875]中的术语。
[RFC4736] defines RSVP signaling extensions for reoptimizing loosely routed P2P TE LSPs as follows:
[RFC4736]定义RSVP信令扩展，用于重新优化松散路由的P2P TE LSP，如下所示：
o A midpoint LSR that expands loose next hop(s) sends a solicited or unsolicited PathErr with Notify error code 25 (as defined in [RFC3209]), with sub-code 6 to indicate "Preferable Path Exists" to the ingress node.
o 扩展松散下一跳的中点LSR发送请求的或未请求的路径，通知错误代码为25（如[RFC3209]中所定义），子代码为6，以向入口节点指示“存在优选路径”。
o An ingress node triggers a path re-evaluation request at all midpoint LSRs that expand loose next hop(s) by setting the "Path Re-evaluation Request" flag (0x20) in the SESSION_ATTRIBUTES object in the Path message.
o 入口节点通过在路径消息中的会话_属性对象中设置“路径重新评估请求”标志（0x20），在扩展松散下一跳的所有中点LSR处触发路径重新评估请求。
o The ingress node, upon receiving this PathErr with the Notify error code (either solicited or unsolicited), initiates the reoptimization of the LSP, using the MBB method with a different LSP-ID.
o 入口节点在收到带有Notify错误代码（请求或未请求）的此PathErr后，使用具有不同LSP-ID的MBB方法启动LSP的重新优化。
The following sections discuss the issues that may arise when applying the mechanisms defined in [RFC4736] for reoptimizing loosely routed P2MP-TE LSPs.
以下各节讨论了应用[RFC4736]中定义的机制重新优化松散路由P2MP-TE LSP时可能出现的问题。
An example of a loosely routed inter-domain P2MP-TE LSP tree is shown in Figure 1. In this example, the P2MP-TE LSP tree consists of three S2L sub-LSPs, to destinations (i.e., leafs) R10, R11, and R12 from the ingress node (i.e., source) R1. Nodes R2 and R5 are branch nodes, and nodes ABR3, ABR4, ABR7, ABR8, and ABR9 are ABRs. For the S2L sub-LSP to destination R10, nodes ABR3, ABR7, and R10 are defined as loose next hops. For the S2L sub-LSP to destination R11, nodes ABR3, ABR8, and R11 are defined as loose next hops. For the S2L sub-LSP to destination R12, nodes ABR4, ABR9, and R12 are defined as loose next hops.
图1显示了松散路由的域间P2MP-TE LSP树的示例。在此示例中，P2MP-TE LSP树由三个S2L子LSP组成，从入口节点（即源）R1到目的地（即叶）R10、R11和R12。节点R2和R5是分支节点，节点ABR3、ABR4、ABR7、ABR8和ABR9是ABR。对于到目的地R10的S2L子LSP，节点ABR3、ABR7和R10被定义为松散下一跳。对于到目的地R11的S2L子LSP，节点ABR3、ABR8和R11被定义为松散下一跳。对于到目的地R12的S2L子LSP，节点ABR4、ABR9和R12被定义为松散下一跳。
<--area1--><--area0--><-area2->
<--area1--><--area0--><-area2->
ABR7---R10
/
/
ABR3---R5
/ \
/ \
R1---R2 ABR8---R11
\
\
ABR4---R6
\
\
ABR9---R12
ABR7---R10
/
/
ABR3---R5
/ \
/ \
R1---R2 ABR8---R11
\
\
ABR4---R6
\
\
ABR9---R12
Figure 1: Example of Loosely Routed Inter-domain P2MP-TE LSP Tree
图1：松散路由的域间P2MP-TE LSP树示例
The mechanisms defined in [RFC4736] can be easily applied to trigger the reoptimization of an individual S2L sub-LSP or a group of S2L sub-LSPs. However, to apply those mechanisms for triggering the reoptimization of a P2MP-TE LSP tree, an ingress node needs to send path re-evaluation requests on all (typically hundreds) of the S2L sub-LSPs, and the midpoint LSR needs to send PathErrs with the Notify error code for all S2L sub-LSPs. Such mechanisms may lead to the following issues:
[RFC4736]中定义的机制可轻松应用于触发单个S2L子LSP或一组S2L子LSP的重新优化。然而，为了应用这些机制来触发P2MP-TE LSP树的重新优化，入口节点需要在所有（通常数百个）S2L子LSP上发送路径重新评估请求，并且中点LSR需要为所有S2L子LSP发送带有通知错误代码的路径。这种机制可能导致以下问题：
o A midpoint LSR that expands loose next hop(s) may have to accumulate the received path re-evaluation request(s) for all S2L sub-LSPs (e.g., by using a wait timer) and interpret them as a reoptimization request for the whole P2MP-TE LSP tree. Otherwise, a midpoint LSR may prematurely send a "Preferable Path Exists" notification for one S2L sub-LSP or a subset of S2L sub-LSPs.
o 扩展松散下一跳的中点LSR可能必须累积所有S2L子LSP的接收路径重新评估请求（例如，通过使用等待计时器），并将其解释为整个P2MP-TE LSP树的重新优化请求。否则，中点LSR可以提前发送一个S2L子LSP或S2L子LSP的子集的“优选路径存在”通知。
o Similarly, the ingress node may have to heuristically determine when to perform P2MP-TE LSP tree reoptimization and when to perform S2L sub-LSP reoptimization. For example, an implementation may choose to delay reoptimization long enough to allow all PathErrs to be received. Such timer-based procedures may produce undesired results.
o 类似地，入口节点可能必须试探性地确定何时执行P2MP-TE LSP树再优化以及何时执行S2L子LSP再优化。例如，实现可以选择将重新优化延迟足够长的时间，以允许接收所有路径。这种基于计时器的程序可能会产生不期望的结果。
o The ingress node that receives (un)solicited PathErr(s) with the Notify error code for one or more individual S2L sub-LSPs may prematurely start reoptimizing the subset of S2L sub-LSPs. However, as mentioned in [RFC4875], Section 14.2, such a Sub-Group-based reoptimization procedure may result in data
o 接收（未）请求的带有一个或多个单独S2L子lsp的Notify错误代码的路径的入口节点可以过早地开始重新优化S2L子lsp的子集。然而，如[RFC4875]第14.2节所述，这种基于子组的再优化程序可能会导致数据丢失
duplication that can be avoided if the entire P2MP-TE LSP tree is reoptimized using the MBB method with a different LSP-ID, especially if the ingress node eventually receives PathErrs with the Notify error code for all S2L sub-LSPs of the P2MP-TE LSP tree.
如果使用具有不同LSP-ID的MBB方法重新优化整个P2MP-TE LSP树，尤其是如果入口节点最终接收到带有P2MP-TE LSP树的所有S2L子LSP的Notify错误代码的路径，则可以避免重复。
In order to address the above-mentioned issues and to align the reoptimization of P2MP-TE LSPs with P2P LSPs [RFC4736], a mechanism is needed to trigger the reoptimization of the LSP tree by re-signaling all S2L sub-LSPs with a different LSP-ID. To meet this requirement, this document defines RSVP-TE signaling extensions for the ingress node to trigger the re-evaluation of the P2MP LSP tree on every hop that has a next hop defined as a loose or abstract hop for one or more S2L sub-LSP paths, and a midpoint LSR to signal to the ingress node that a preferable LSP tree exists (compared to the current path) or that the whole P2MP-TE LSP must be reoptimized (because of maintenance required on the TE LSP path) (see Section 4.1).
为了解决上述问题，并使P2MP-TE LSP的重新优化与P2P LSP[RFC4736]保持一致，需要一种机制，通过使用不同的LSP-ID重新发送所有S2L子LSP的信号来触发LSP树的重新优化。为满足此要求，本文档定义了入口节点的RSVP-TE信令扩展，用于在每个跃点上触发P2MP LSP树的重新评估，该跃点具有定义为一个或多个S2L子LSP路径的松散或抽象跃点的下一个跃点，以及向入口节点发信号表示存在优选LSP树（与当前路径相比）的中点LSR或者必须重新优化整个P2MP-TE LSP（因为TE LSP路径需要维护）（参见第4.1节）。
Applying the procedures discussed in [RFC4736] in conjunction with the Sub-Group-based reoptimization procedures ([RFC4875], Section 14.2), an ingress node MAY trigger path re-evaluation requests for a set of S2L sub-LSPs in a single Path message using an S2L sub-LSP descriptor list. Similarly, a midpoint LSR may send a PathErr with Notify error code 25 and sub-code 6 ("Preferable Path Exists") containing a list of S2L sub-LSPs transiting through the LSR using an S2L sub-LSP descriptor list to notify the ingress node. This method can be used for reoptimizing a sub-group of S2L sub-LSPs within an LSP tree using the same LSP-ID. This method can alleviate the scaling issue associated with sending RSVP messages for individual S2L sub-LSPs. However, this procedure can lead to the following issues when used to reoptimize the LSP tree:
应用[RFC4736]中讨论的程序以及基于子组的再优化程序（[RFC4875]，第14.2节），入口节点可使用S2L子LSP描述符列表在单个路径消息中触发一组S2L子LSP的路径重新评估请求。类似地，中点LSR可以发送具有通知错误代码25和子代码6（“优选路径存在”）的路径，该路径包含使用S2L子LSP描述符列表通过LSR传递的S2L子LSP列表，以通知入口节点。此方法可用于使用相同的LSP-ID重新优化LSP树中S2L子LSP的子组。此方法可缓解与发送单个S2L子LSP的RSVP消息相关的缩放问题。但是，当使用此过程重新优化LSP树时，可能会导致以下问题：
o A Path message that is intended to carry the path re-evaluation request as defined in [RFC4736] with a full list of S2L sub-LSPs in an S2L sub-LSP descriptor list will be decomposed at branching LSRs, and only a subset of the S2L sub-LSPs that are routed over the same next hop will be added in the descriptor list of the Path message propagated to downstream midpoint LSRs. Consequently, when a preferable path exists at such midpoint LSRs, the PathErr with the Notify error code can only include the subset of S2L sub-LSPs traversing the LSR. In this case, at the ingress node there is no way to distinguish which mode of reoptimization to invoke, i.e., Sub-Group-based reoptimization using the same LSP-ID or tree-based reoptimization using a different LSP-ID.
o 用于承载[RFC4736]中定义的路径重新评估请求以及S2L子LSP描述符列表中S2L子LSP的完整列表的路径消息将在分支LSR处分解，并且只有在同一下一跳上路由的S2L子lsp的子集将被添加到传播到下游中点lsr的路径消息的描述符列表中。因此，当在这样的中点LSR处存在优选路径时，具有Notify错误代码的PathErr只能包括穿过LSR的S2L子lsp的子集。在这种情况下，在入口节点处，无法区分要调用哪种重新优化模式，即使用相同LSP-ID的基于子组的重新优化或使用不同LSP-ID的基于树的重新优化。
o An LSR may semantically fragment a large RSVP message (when a combined message may not be large enough to fit all S2L sub-LSPs). In this case, the ingress node may receive multiple PathErrs with subsets of S2L sub-LSPs in each (due to either the combined Path message getting fragmented or the combined PathErr message getting fragmented) and would require additional logic to determine how to reoptimize the LSP tree (for example, waiting for some time to aggregate all possible PathErr messages before taking an action). When fragmented, RSVP messages may arrive out of order, and the receiver has no way of knowing the beginning and end of the S2L sub-LSP list.
o LSR可以在语义上对大型RSVP消息进行分段（当组合消息可能不足以容纳所有S2L子LSP时）。在这种情况下，入口节点可以接收多个路径，每个路径中都有S2L子LSP子集（由于组合路径消息变得碎片化或组合路径消息变得碎片化），并且需要额外的逻辑来确定如何重新优化LSP树（例如，在采取行动之前等待一段时间来聚合所有可能的PathErr消息）。当出现碎片时，RSVP消息可能会无序到达，并且接收方无法知道S2L子LSP列表的开始和结束。
In order to address the above-mentioned issues caused by semantic fragmentation of an RSVP message, this document defines a new fragment identifier object for the S2L sub-LSP descriptor list when combining a large number of S2L sub-LSPs in an RSVP message (see Section 4.2).
为了解决由RSVP消息的语义碎片引起的上述问题，本文件在RSVP消息中组合大量S2L子LSP时，为S2L子LSP描述符列表定义了一个新的碎片标识符对象（见第4.2节）。
To evaluate a P2MP-TE LSP tree on midpoint LSRs that expand loose next hop(s), an ingress node MAY send a Path message with the "P2MP-TE Tree Re-evaluation Request" flag set (bit number 14 in the Attribute Flags TLV) as defined in this document. The ingress node selects one of the S2L sub-LSPs of the P2MP-TE LSP tree transiting a midpoint LSR to trigger the re-evaluation request. The ingress node MAY send a re-evaluation request to each border LSR on the path of the LSP tree.
为了评估展开下一跳的中点LSR上的P2MP-TE LSP树，入口节点可以发送路径消息，其中设置了本文档中定义的“P2MP-TE树重新评估请求”标志（属性标志TLV中的位号14）。入口节点选择P2MP-TE LSP树的S2L子LSP之一，该子LSP传递中点LSR以触发重新评估请求。入口节点可以向LSP树路径上的每个边界LSR发送重新评估请求。
A midpoint LSR that expands loose next hop(s) for one or more S2L sub-LSP paths does the following upon receiving a Path message with the "P2MP-TE Tree Re-evaluation Request" flag set:
为一个或多个S2L子LSP路径扩展松散下一跳的中点LSR在接收到设置了“P2MP-TE树重新评估请求”标志的路径消息时执行以下操作：
o The midpoint LSR MUST check for a preferable P2MP-TE LSP tree by re-evaluating all S2L sub-LSPs that are expanded paths of the loose next hops of the P2MP-TE LSP.
o 中点LSR必须通过重新评估作为P2MP-TE LSP的松散下一跳的扩展路径的所有S2L子LSP来检查优选的P2MP-TE LSP树。
o If a preferable P2MP-TE LSP tree is found, the midpoint LSR MUST send to the ingress node an RSVP PathErr with Notify error code 25 [RFC3209] and sub-code 13 ("Preferable P2MP-TE Tree Exists)" as defined in this document. The midpoint LSR, in turn, SHOULD NOT propagate the "P2MP-TE Tree Re-evaluation Request" flag in the subsequent RSVP Path messages sent downstream for the re-evaluated P2MP-TE LSP.
o 如果找到优选P2MP-TE LSP树，中点LSR必须向入口节点发送一个RSVP路径，通知错误代码为25[RFC3209]，子代码为13（“优选P2MP-TE树存在”），如本文档中所定义。反过来，中点LSR不应在为重新评估的P2MP-TE LSP向下游发送的后续RSVP路径消息中传播“P2MP-TE树重新评估请求”标志。
o If no preferable tree for P2MP-TE LSPs can be found, the midpoint LSR that expands loose next hop(s) for one or more S2L sub-LSP paths MUST propagate the request downstream by setting the "P2MP-TE Tree Re-evaluation Request" flag in the LSP_ATTRIBUTES object of the RSVP Path message.
o 如果找不到P2MP-TE LSP的首选树，则为一个或多个S2L子LSP路径扩展松散下一跳的中点LSR必须通过在RSVP路径消息的LSP_属性对象中设置“P2MP-TE树重新评估请求”标志，将请求传播到下游。
A midpoint LSR MAY send an unsolicited PathErr with the Notify error code and the "Preferable P2MP-TE Tree Exists" sub-code to the ingress node to notify the ingress node of a preferred P2MP-TE LSP tree when it determines that it exists. In this case, the midpoint LSR that expands loose next hop(s) for one or more S2L sub-LSP paths selects one of the S2L sub-LSPs of the P2MP-TE LSP tree to send this PathErr message to the ingress node. The midpoint LSR SHOULD consider how frequently it chooses to send such a PathErr, considering that both (1) a PathErr may be lost during its transit to the ingress node and (2) the ingress node may choose not to reoptimize the LSP when such a PathErr is received.
中点LSR可以向入口节点发送带有通知错误代码和“优选P2MP-TE树存在”子代码的未经请求的路径，以在入口节点确定优选P2MP-TE LSP树存在时通知其入口节点。在这种情况下，为一个或多个S2L子LSP路径扩展松散下一跳的中点LSR选择P2MP-TE LSP树的S2L子LSP之一以将该PathErr消息发送到入口节点。中点LSR应该考虑它选择发送这样的PaTrr的频率，考虑到两个（1）PaTrr在其进入入口节点期间可能丢失，并且（2）当接收到这样的PaTrr时，入口节点可以选择不重新优化LSP。
The sending of an RSVP PathErr with the Notify error code and the "Preferable P2MP-TE Tree Exists" sub-code to the ingress node notifies the ingress node of the existence of a preferable P2MP-TE LSP tree, and upon receiving this PathErr, the ingress node SHOULD trigger the reoptimization of the LSP, using the MBB method with a different LSP-ID.
向入口节点发送带有通知错误代码和“优选P2MP-TE树存在”子代码的RSVP路径通知入口节点优选P2MP-TE LSP树的存在，并且在接收到该路径时，入口节点应使用具有不同LSP-ID的MBB方法触发LSP的重新优化。
It might be preferable, as per [RFC4875], to reoptimize the entire P2MP-TE LSP by re-signaling all of its S2L sub-LSPs (Section 14.1 ("Make-before-Break") in [RFC4875]) or to reoptimize an individual S2L sub-LSP or a group of S2L sub-LSPs, i.e., an individual destination or a group of destinations (Section 14.2 ("Sub-Group-Based Re-Optimization") in [RFC4875]), both using the same LSP-ID. For loosely routed S2L sub-LSPs, this can be achieved by using the procedures defined in [RFC4736] to reoptimize one or more S2L sub-LSPs of the P2MP-TE LSP.
根据[RFC4875]，通过在[RFC4875]中重新发送其所有S2L子LSP（第14.1节（“先通后断”）来重新优化整个P2MP-TE LSP，或者重新优化单个S2L子LSP或一组S2L子LSP，即单个目的地或一组目的地（第14.2节（“基于子组的重新优化”）在[RFC4875]中，两者都使用相同的LSP-ID。对于松散路由的S2L子LSP，这可以通过使用[RFC4736]中定义的程序来实现，以重新优化P2MP-TE LSP的一个或多个S2L子LSP。
An ingress node may trigger path re-evaluation requests using the procedures defined in [RFC4736] for a set of S2L sub-LSPs by combining multiple Path messages using an S2L sub-LSP descriptor list [RFC4875]. An S2L sub-LSP descriptor list is created using a series of S2L_SUB_LSP objects as defined in [RFC4875]. Similarly, a midpoint LSR may send a PathErr with Notify error code 25 and sub-code 6 ("Preferable Path Exists") containing a list of S2L sub-LSPs transiting through the LSR using an S2L sub-LSP descriptor list to notify the ingress node of preferable paths available.
入口节点可以通过使用S2L子LSP描述符列表[RFC4875]组合多个路径消息，使用[RFC4736]中为一组S2L子LSP定义的过程触发路径重新评估请求。S2L子LSP描述符列表是使用[RFC4875]中定义的一系列S2L_子LSP对象创建的。类似地，中点LSR可以发送具有通知错误代码25和子代码6（“优选路径存在”）的路径，该路径包含使用S2L子LSP描述符列表通过LSR传递的S2L子LSP的列表，以通知入口节点可用的优选路径。
The S2L_SUB_LSP_FRAG object defined in this document is optional, with the following exceptions:
本文件中定义的S2L_SUB_LSP_FRAG对象是可选的，但以下情况除外：
o As per [RFC4875], Section 5.2.3 ("Transit Fragmentation of Path State Information"), when a Path message is not large enough to fit all S2L sub-LSPs in the descriptor list, an LSR may semantically fragment the message. In this case, the LSR MUST add the S2L_SUB_LSP_FRAG object defined in this document for each fragment in the S2L sub-LSP descriptor to be able to rebuild the list from the received fragments that may arrive out of order.
o 根据[RFC4875]第5.2.3节（“路径状态信息的传输分段”），当路径消息不足以容纳描述符列表中的所有S2L子LSP时，LSR可以对消息进行语义分段。在这种情况下，LSR必须为S2L子LSP描述符中的每个片段添加本文档中定义的S2L_子LSP_FRAG对象，以便能够根据可能无序到达的接收片段重建列表。
o In any other situation where an RSVP message needs to be fragmented, an LSR MUST add the S2L_SUB_LSP_FRAG object for each fragment in the S2L sub-LSP descriptor.
o 在RSVP消息需要分段的任何其他情况下，LSR必须为S2L子LSP描述符中的每个分段添加S2L_子LSP_FRAG对象。
A midpoint LSR SHOULD wait to accumulate all S2L sub-LSPs before attempting to re-evaluate a preferable path when a Path message for "Path Re-evaluation Request" is received with the S2L_SUB_LSP_FRAG object. If a midpoint LSR does not receive all fragments of the Path message (for example, when fragments are lost) within a configurable time interval, it SHOULD trigger the re-evaluation of all S2L sub-LSPs of the P2MP-TE LSP transiting on the node. A midpoint LSR MUST receive at least one fragment of the Path message to trigger this behavior.
当使用S2L_sub_LSP_FRAG对象接收到“路径重新评估请求”的路径消息时，中点LSR应等待累积所有S2L子LSP，然后再尝试重新评估优选路径。如果中点LSR在可配置的时间间隔内未接收到路径消息的所有片段（例如，当片段丢失时），则它应触发重新评估在节点上传输的P2MP-TE LSP的所有S2L子LSP。中点LSR必须至少接收路径消息的一个片段才能触发此行为。
An ingress node SHOULD wait to accumulate all S2L sub-LSPs before attempting to trigger reoptimization when a PathErr with the Notify error code and the "Preferable Path Exists" sub-code is received with an S2L_SUB_LSP_FRAG object. If an ingress node does not receive all fragments of the PathErr message (for example, when fragments are lost) within a configurable time interval, it SHOULD trigger the reoptimization of all S2L sub-LSPs of the P2MP-TE LSP transiting on the midpoint node that had sent the PathErr message. An ingress node MUST receive at least one fragment of the PathErr message to trigger this behavior.
当使用S2L_sub_LSP_FRAG对象接收到带有Notify错误代码和“Preferred Path Exists”（首选路径存在）子代码的路径错误时，入口节点应等待累积所有S2L子LSP，然后再尝试触发重新优化。如果入口节点未在可配置的时间间隔内接收到PathErr消息的所有片段（例如，当片段丢失时），则应触发在发送PathErr消息的中点节点上传输的P2MP-TE LSP的所有S2L子LSP的重新优化。入口节点必须至少接收一段PathErr消息才能触发此行为。
The S2L_SUB_LSP_FRAG object defined in this document has a wider applicability in addition to the P2MP-TE LSP reoptimization. It can also be used (in Path and Resv messages) to set up a new P2MP-TE LSP and to send other PathErr messages as well as Path Tear and Resv Tear messages for a set of S2L sub-LSPs. This is outside the scope of this document.
除P2MP-TE LSP再优化外，本文件中定义的S2L_SUB_LSP_FRAG对象具有更广泛的适用性。它还可用于（在Path和Resv消息中）设置新的P2MP-TE LSP，并发送其他PathErr消息以及一组S2L子LSP的Path Tear和Resv Tear消息。这超出了本文件的范围。
In order to trigger a tree re-evaluation request, a new flag in the Attribute Flags TLV of the LSP_ATTRIBUTES object [RFC5420] is defined by this document:
为了触发树重新评估请求，本文档定义了LSP_属性对象[RFC5420]的属性标志TLV中的新标志：
Bit Number 14: "P2MP-TE Tree Re-evaluation Request" flag
位号14：“P2MP-TE树重新评估请求”标志
The "P2MP-TE Tree Re-evaluation Request" flag is meaningful in a Path message of a P2MP-TE S2L sub-LSP and is inserted by the ingress node using the message format defined in [RFC6510].
“P2MP-TE树重新评估请求”标志在P2MP-TE S2L子LSP的路径消息中有意义，并且由入口节点使用[RFC6510]中定义的消息格式插入。
In order to indicate to an ingress node that a preferable P2MP-TE LSP tree exists, the following new sub-code for PathErr messages with Notify error code 25 [RFC3209] is defined by this document:
为了向入口节点指示存在优选的P2MP-TE LSP树，本文档定义了具有通知错误代码25[RFC3209]的PathErr消息的以下新子代码：
Sub-code 13: "Preferable P2MP-TE Tree Exists" sub-code
子代码13：“存在P2MP-TE树”子代码
When a preferable path for a P2MP-TE LSP tree exists, the midpoint LSR sends a solicited or unsolicited "Preferable P2MP-TE Tree Exists" sub-code with a PathErr message with Notify error code 25 to the ingress node of the P2MP-TE LSP.
当P2MP-TE LSP树的优选路径存在时，中点LSR向P2MP-TE LSP的入口节点发送请求的或非请求的“优选P2MP-TE树存在”子代码以及带有通知错误代码25的PathErr消息。
The S2L_SUB_LSP object [RFC4875] identifies a particular S2L sub-LSP belonging to the P2MP-TE LSP. An S2L sub-LSP descriptor list is created using a series of S2L_SUB_LSP objects as defined in [RFC4875]. The RSVP message may need to be semantically fragmented [RFC4875] due to a large number of S2L sub-LSPs added in the descriptor list, and such fragments may be received out of order. To be able to rebuild the fragmented S2L sub-LSP descriptor list correctly, the following object is defined to identify the fragments:
S2L_SUB_LSP对象[RFC4875]标识属于P2MP-TE LSP的特定S2L SUB LSP。S2L子LSP描述符列表是使用[RFC4875]中定义的一系列S2L_子LSP对象创建的。由于在描述符列表中添加了大量S2L子LSP，RSVP消息可能需要在语义上分段[RFC4875]，并且这些分段可能被无序接收。为了能够正确重建分段的S2L子LSP描述符列表，定义了以下对象来标识分段：
S2L_SUB_LSP_FRAG: Class Number 204
S2L_子_LSP_框架：类别编号204
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (8 bytes) | Class Num 204 | C-Type 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment ID | Fragments Tot.| Fragment Num. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (8 bytes) | Class Num 204 | C-Type 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment ID | Fragments Tot.| Fragment Num. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fragment ID: 16-bit integer in the range of 1 to 65535.
片段ID:1到65535范围内的16位整数。
This value is incremented for each new RSVP message that needs to be semantically fragmented. The fragment ID is reset to 1 when it reaches the maximum value of 65535. The scope of the fragment ID is limited to the RSVP message type (e.g., Path) carrying the fragment. In other words, fragment IDs do not have any correlation between different RSVP message types (e.g., Path and PathErr). The receiver does not check to ensure that the consecutive new RSVP messages (e.g., Path messages) are received with fragment IDs incremented by 1.
对于每个需要进行语义分段的新RSVP消息，该值都会递增。片段ID在达到最大值65535时重置为1。片段ID的范围仅限于携带片段的RSVP消息类型（例如路径）。换句话说，片段ID在不同的RSVP消息类型（例如Path和PathErr）之间没有任何关联。接收器不检查以确保接收到的连续新RSVP消息（例如，路径消息）的片段ID增加1。
Fragments Total: 8-bit integer in the range of 1 to 255.
碎片总数：1到255范围内的8位整数。
This value indicates the number of fragments sent for the given RSVP message. This value MUST be the same in all fragmented RSVP messages with a common fragment ID.
此值表示为给定RSVP消息发送的片段数。此值在所有具有公共片段ID的分段RSVP消息中必须相同。
Fragment Number: 8-bit integer in the range of 1 to 255.
片段编号：1到255范围内的8位整数。
This value indicates the position of this fragment in the given RSVP message.
此值指示此片段在给定RSVP消息中的位置。
The format of an S2L sub-LSP descriptor message is as follows:
S2L子LSP描述符消息的格式如下：
<S2L sub-LSP descriptor> ::=
[ <S2L_SUB_LSP_FRAG> ]
<S2L_SUB_LSP>
[ <P2MP SECONDARY_EXPLICIT_ROUTE> ]
<S2L sub-LSP descriptor> ::=
[ <S2L_SUB_LSP_FRAG> ]
<S2L_SUB_LSP>
[ <P2MP SECONDARY_EXPLICIT_ROUTE> ]
The S2L_SUB_LSP_FRAG object is added before adding the S2L_SUB_LSP object in the semantically fragmented RSVP message.
在语义分段的RSVP消息中添加S2L_SUB_LSP_FRAG对象之前，先添加S2L_SUB_LSP_FRAG对象。
The LSP_ATTRIBUTES object has been defined in [RFC5420] and its message formats in [RFC6510] with class numbers in the form 11bbbbbb, which ensures compatibility with non-supporting nodes. Per [RFC2205], nodes not supporting this extension will ignore the new flag defined for this object in this document and will forward it without modification.
LSP_ATTRIBUTES对象在[RFC5420]中定义，其消息格式在[RFC6510]中定义，类号格式为11BBBB，这确保了与非支持节点的兼容性。根据[RFC2205]，不支持此扩展的节点将忽略在此文档中为此对象定义的新标志，并将转发它而不进行修改。
The S2L_SUB_LSP_FRAG object has been defined with class numbers in the form 11bbbbbb, which ensures compatibility with non-supporting nodes. Per [RFC2205], nodes not supporting this object will ignore the object and will forward it without modification.
S2L_SUB_LSP_FRAG对象已使用11bbbb格式的类编号定义，这确保了与非支持节点的兼容性。根据[RFC2205]，不支持该对象的节点将忽略该对象，并将在不进行修改的情况下转发该对象。
IANA has performed the actions described below.
IANA已执行了下述操作。
IANA maintains the "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" registry (see <http://www.iana.org/assignments/rsvp-te-parameters>). Per Section 5.1 of this document, IANA has registered a new flag in the "Attribute Flags" registry. This new flag is defined for the Attribute Flags TLV in the LSP_ATTRIBUTES object [RFC5420].
IANA维护“资源预留协议流量工程（RSVP-TE）参数”注册表（参见<http://www.iana.org/assignments/rsvp-te-parameters>). 根据本文件第5.1节，IANA已在“属性标志”注册表中注册了一个新标志。此新标志是为LSP_ATTRIBUTES对象[RFC5420]中的属性标志TLV定义的。
+-----+---------------+----------+----------+-----+-----+-----------+
| Bit | Name | Attribute| Attribute| RRO | ERO | Reference |
| No | | Flags | Flags | | | |
| | | Path | Resv | | | |
+-----+---------------+----------+----------+-----+-----+-----------+
| | P2MP-TE Tree | Yes | No | No | No | This |
| 14 | Re-evaluation | | | | | document |
| | Request | | | | | |
+-----+---------------+----------+----------+-----+-----+-----------+
+-----+---------------+----------+----------+-----+-----+-----------+
| Bit | Name | Attribute| Attribute| RRO | ERO | Reference |
| No | | Flags | Flags | | | |
| | | Path | Resv | | | |
+-----+---------------+----------+----------+-----+-----+-----------+
| | P2MP-TE Tree | Yes | No | No | No | This |
| 14 | Re-evaluation | | | | | document |
| | Request | | | | | |
+-----+---------------+----------+----------+-----+-----+-----------+
IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" registry (see <http://www.iana.org/assignments/rsvp-parameters>). Per Section 5.2 of this document, IANA has registered a new error code in the "Sub-Codes - 25 Notify Error" sub-registry of the "Error Codes and Globally-Defined Error Value Sub-Codes" registry.
IANA维护“资源预留协议（RSVP）参数”注册表（请参阅<http://www.iana.org/assignments/rsvp-parameters>). 根据本文件第5.2节，IANA已在“错误代码和全局定义的错误值子代码”注册表的“子代码-25通知错误”子注册表中注册了新的错误代码。
As defined in [RFC3209], error code 25 in the ERROR_SPEC object corresponds to a PathErr with the Notify error. This document adds a new "Preferable P2MP-TE Tree Exists" sub-code for this PathErr as follows:
如[RFC3209]中所定义，error_SPEC对象中的错误代码25对应于具有Notify错误的PathErr。本文档为此PathErr添加了新的“首选P2MP-TE树存在”子代码，如下所示：
+----------+--------------------+---------+---------+-----------+
| Value | Description | PathErr | PathErr | Reference |
| | | Code | Name | |
+----------+--------------------+---------+---------+-----------+
| 13 | Preferable P2MP-TE | 25 | Notify | This |
| | Tree Exists | | Error | document |
+----------+--------------------+---------+---------+-----------+
+----------+--------------------+---------+---------+-----------+
| Value | Description | PathErr | PathErr | Reference |
| | | Code | Name | |
+----------+--------------------+---------+---------+-----------+
| 13 | Preferable P2MP-TE | 25 | Notify | This |
| | Tree Exists | | Error | document |
+----------+--------------------+---------+---------+-----------+
IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" registry (see <http://www.iana.org/assignments/rsvp-parameters>). Per Section 5.3 of this document, IANA has registered a new class number in the "Class Names, Class Numbers, and Class Types" registry.
IANA维护“资源预留协议（RSVP）参数”注册表（请参阅<http://www.iana.org/assignments/rsvp-parameters>). 根据本文件第5.3节，IANA在“类名、类号和类类型”注册表中注册了一个新的类号。
+-----------------+---------------------------+-----------------+
| Class Number | Class Name | Reference |
+-----------------+---------------------------+-----------------+
| 204 | S2L_SUB_LSP_FRAG | This document |
+-----------------+---------------------------+-----------------+
+-----------------+---------------------------+-----------------+
| Class Number | Class Name | Reference |
+-----------------+---------------------------+-----------------+
| 204 | S2L_SUB_LSP_FRAG | This document |
+-----------------+---------------------------+-----------------+
IANA has also created the "Class Types or C-Types - 204 S2L_SUB_LSP_FRAG" registry and populated it as follows:
IANA还创建了“类别类型或C类型-204 S2L_SUB_LSP_FRAG”注册表，并将其填充如下：
+-----------------+---------------------------+-----------------+
| Value | Description | Reference |
+-----------------+---------------------------+-----------------+
| 1 | S2L_SUB_LSP_FRAG | This document |
+-----------------+---------------------------+-----------------+
+-----------------+---------------------------+-----------------+
| Value | Description | Reference |
+-----------------+---------------------------+-----------------+
| 1 | S2L_SUB_LSP_FRAG | This document |
+-----------------+---------------------------+-----------------+
This document defines RSVP-TE signaling extensions to allow an ingress node of a P2MP-TE LSP to request the re-evaluation of the LSP tree downstream of a node and to allow a midpoint LSR to notify the ingress node of the existence of a preferable tree by sending a PathErr message. As per [RFC4736], in the case of a P2MP-TE LSP S2L sub-LSP spanning multiple domains, it may be desirable for a midpoint LSR to modify the RSVP PathErr message to preserve confidentiality across domains.
本文档定义了RSVP-TE信令扩展，以允许P2MP-TE LSP的入口节点请求重新评估节点下游的LSP树，并允许中点LSR通过发送PathErr消息通知入口节点存在优选树。根据[RFC4736]，在P2MP-TE LSP S2L子LSP跨越多个域的情况下，中点LSR可能需要修改RSVP PathErr消息以保持跨域的机密性。
This document also defines a fragment identifier for the S2L sub-LSP descriptor when combining a large number of S2L sub-LSPs in an RSVP message and the message needs to be semantically fragmented. The introduction of the fragment identifier, by itself, introduces no additional information to signaling. For a general discussion on security issues related to MPLS and GMPLS, see the MPLS/GMPLS security framework [RFC5920].
当在RSVP消息中组合大量S2L子LSP时，本文档还定义了S2L子LSP描述符的片段标识符，并且该消息需要进行语义分段。片段标识符的引入本身不会给信令带来额外的信息。有关MPLS和GMPLS相关安全问题的一般性讨论，请参阅MPLS/GMPLS安全框架[RFC5920]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <http://www.rfc-editor.org/info/rfc2205>.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源保留协议（RSVP）——版本1功能规范”，RFC 2205，DOI 10.17487/RFC2205，1997年9月<http://www.rfc-editor.org/info/rfc2205>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<http://www.rfc-editor.org/info/rfc3209>.
[RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, DOI 10.17487/RFC4736, November 2006, <http://www.rfc-editor.org/info/rfc4736>.
[RFC4736]Vasseur，JP.，Ed.，Ikejiri，Y.，和R.Zhang，“多协议标签交换（MPLS）流量工程（TE）松路由标签交换路径（LSP）的再优化”，RFC 4736，DOI 10.17487/RFC4736，2006年11月<http://www.rfc-editor.org/info/rfc4736>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, <http://www.rfc-editor.org/info/rfc4875>.
[RFC4875]Aggarwal，R.，Ed.，Papadimitriou，D.，Ed.，和S.Yasukawa，Ed.，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 4875，DOI 10.17487/RFC4875，2007年5月<http://www.rfc-editor.org/info/rfc4875>.
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, February 2009, <http://www.rfc-editor.org/info/rfc5420>.
[RFC5420]Farrel，A.，Ed.，Papadimitriou，D.，Vasseur，JP.，和A.Ayangarps，“使用资源预留协议流量工程（RSVP-TE）对MPLS LSP建立的属性进行编码”，RFC 5420，DOI 10.17487/RFC5420，2009年2月<http://www.rfc-editor.org/info/rfc5420>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，DOI 10.17487/RFC3473，2003年1月<http://www.rfc-editor.org/info/rfc3473>.
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>.
[RFC5440]Vasseur，JP.，Ed.，和JL。Le Roux主编，“路径计算元件（PCE）通信协议（PCEP）”，RFC 5440，DOI 10.17487/RFC5440，2009年3月<http://www.rfc-editor.org/info/rfc5440>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，DOI 10.17487/RFC5920，2010年7月<http://www.rfc-editor.org/info/rfc5920>.
[RFC6510] Berger, L. and G. Swallow, "Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects", RFC 6510, DOI 10.17487/RFC6510, February 2012, <http://www.rfc-editor.org/info/rfc6510>.
[RFC6510]Berger，L.和G.Swallow，“标签交换路径（LSP）属性对象的资源预留协议（RSVP）消息格式”，RFC 6510，DOI 10.17487/RFC6510，2012年2月<http://www.rfc-editor.org/info/rfc6510>.
Acknowledgments
致谢
The authors would like to thank Loa Andersson, Sriganesh Kini, Curtis Villamizar, Dimitri Papadimitriou, Nobo Akiya, Vishnu Pavan Beeram, and Joel M. Halpern for reviewing this document and providing many useful comments and suggestions. The authors would also like to thank Ling Zeng with Cisco Systems for implementing the mechanisms defined in this document. A special thanks to Adrian Farrel for his thorough review of this document.
作者感谢Loa Andersson、Sriganesh Kini、Curtis Villamizar、Dimitri Papadimitriou、Nobo Akiya、Vishnu Pavan Beeram和Joel M.Halpern对本文件进行了审查，并提供了许多有用的意见和建议。作者还想感谢Cisco Systems的凌增实施本文件中定义的机制。特别感谢阿德里安·法雷尔对本文件的全面审查。
Authors' Addresses
作者地址
Tarek Saad (editor) Cisco Systems, Inc.
塔瑞克·萨阿德（编辑）思科系统公司。
Email: tsaad@cisco.com
Email: tsaad@cisco.com
Rakesh Gandhi (editor) Cisco Systems, Inc.
拉凯什·甘地（编辑）思科系统公司。
Email: rgandhi@cisco.com
Email: rgandhi@cisco.com
Zafar Ali Cisco Systems, Inc.
扎法尔·阿里思科系统公司。
Email: zali@cisco.com
Email: zali@cisco.com
Robert H. Venator Defense Information Systems Agency
罗伯特·H·维纳纳国防信息系统局
Email: robert.h.venator.civ@mail.mil
Email: robert.h.venator.civ@mail.mil
Yuji Kamite NTT Communications Corporation
Yuji Kamite NTT通信公司
Email: y.kamite@ntt.com
Email: y.kamite@ntt.com