Internet Engineering Task Force (IETF) H. Sitaraman
Request for Comments: 8577 V. Beeram
Category: Standards Track Juniper Networks
ISSN: 2070-1721 T. Parikh
Verizon
T. Saad
Cisco Systems
April 2019
Internet Engineering Task Force (IETF) H. Sitaraman
Request for Comments: 8577 V. Beeram
Category: Standards Track Juniper Networks
ISSN: 2070-1721 T. Parikh
Verizon
T. Saad
Cisco Systems
April 2019
Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane
在共享MPLS转发平面上信令RSVP-TE隧道
Abstract
摘要
As the scale of MPLS RSVP-TE networks has grown, the number of Label Switched Paths (LSPs) supported by individual network elements has increased. Various implementation recommendations have been proposed to manage the resulting increase in the amount of control-plane state information.
随着MPLS RSVP-TE网络规模的增长，单个网元支持的标签交换路径（LSP）的数量也在增加。已经提出了各种实施建议，以管理由此导致的控制平面状态信息量的增加。
However, those changes have had no effect on the number of labels that a transit Label Switching Router (LSR) has to support in the forwarding plane. That number is governed by the number of LSPs transiting or terminated at the LSR and is directly related to the total LSP state in the control plane.
但是，这些更改对中转标签交换路由器（LSR）在转发平面中必须支持的标签数量没有影响。该数目由在LSR处传递或终止的LSP的数目控制，并且与控制平面中的总LSP状态直接相关。
This document defines a mechanism to prevent the maximum size of the label space limit on an LSR from being a constraint to control-plane scaling on that node. It introduces the notion of preinstalled 'per-TE link labels' that can be shared by MPLS RSVP-TE LSPs that traverse these TE links. This approach significantly reduces the forwarding-plane state required to support a large number of LSPs. This couples the feature benefits of the RSVP-TE control plane with the simplicity of the Segment Routing (SR) MPLS forwarding plane.
本文档定义了一种机制，以防止LSR上标签空间限制的最大大小成为控制该节点上平面缩放的约束。它引入了预安装的“每TE链路标签”的概念，该标签可由穿过这些TE链路的MPLS RSVP-TE LSP共享。这种方法显著降低了支持大量LSP所需的转发平面状态。这将RSVP-TE控制平面的功能优势与段路由（SR）MPLS转发平面的简单性结合起来。
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 https://www.rfc-editor.org/info/rfc8577.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8577.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
3. Allocation of TE Link Labels . . . . . . . . . . . . . . . . 6
4. Segment Routed RSVP-TE Tunnel Setup . . . . . . . . . . . . . 6
5. Delegating Label Stack Imposition . . . . . . . . . . . . . . 8
5.1. Stacking at the Ingress . . . . . . . . . . . . . . . . . 8
5.1.1. Stack to Reach Delegation Hop . . . . . . . . . . . . 9
5.1.2. Stack to Reach Egress . . . . . . . . . . . . . . . . 10
5.2. Explicit Delegation . . . . . . . . . . . . . . . . . . . 11
5.3. Automatic Delegation . . . . . . . . . . . . . . . . . . 11
5.3.1. Effective Transport Label-Stack Depth (ETLD) . . . . 11
6. Mixing TE Link Labels and Regular Labels in an RSVP-TE Tunnel 13
7. Construction of Label Stacks . . . . . . . . . . . . . . . . 14
8. Facility Backup Protection . . . . . . . . . . . . . . . . . 14
8.1. Link Protection . . . . . . . . . . . . . . . . . . . . . 14
9. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 15
9.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 15
9.2. Attribute Flags TLV: TE Link Label . . . . . . . . . . . 16
9.3. RRO Label Sub-object Flag: TE Link Label . . . . . . . . 16
9.4. Attribute Flags TLV: LSI-D . . . . . . . . . . . . . . . 16
9.5. RRO Label Sub-object Flag: Delegation Label . . . . . . . 17
9.6. Attributes Flags TLV: LSI-D-S2E . . . . . . . . . . . . . 17
9.7. Attributes TLV: ETLD . . . . . . . . . . . . . . . . . . 18
10. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11.1. Attribute Flags: TE Link Label, LSI-D, LSI-D-S2E . . . . 19
11.2. Attribute TLV: ETLD . . . . . . . . . . . . . . . . . . 19
11.3. Record Route Label Sub-object Flags: TE Link Label,
Delegation Label . . . . . . . . . . . . . . . . . . . . 20
11.4. Error Codes and Error Values . . . . . . . . . . . . . . 20
12. Security Considerations . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
3. Allocation of TE Link Labels . . . . . . . . . . . . . . . . 6
4. Segment Routed RSVP-TE Tunnel Setup . . . . . . . . . . . . . 6
5. Delegating Label Stack Imposition . . . . . . . . . . . . . . 8
5.1. Stacking at the Ingress . . . . . . . . . . . . . . . . . 8
5.1.1. Stack to Reach Delegation Hop . . . . . . . . . . . . 9
5.1.2. Stack to Reach Egress . . . . . . . . . . . . . . . . 10
5.2. Explicit Delegation . . . . . . . . . . . . . . . . . . . 11
5.3. Automatic Delegation . . . . . . . . . . . . . . . . . . 11
5.3.1. Effective Transport Label-Stack Depth (ETLD) . . . . 11
6. Mixing TE Link Labels and Regular Labels in an RSVP-TE Tunnel 13
7. Construction of Label Stacks . . . . . . . . . . . . . . . . 14
8. Facility Backup Protection . . . . . . . . . . . . . . . . . 14
8.1. Link Protection . . . . . . . . . . . . . . . . . . . . . 14
9. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 15
9.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 15
9.2. Attribute Flags TLV: TE Link Label . . . . . . . . . . . 16
9.3. RRO Label Sub-object Flag: TE Link Label . . . . . . . . 16
9.4. Attribute Flags TLV: LSI-D . . . . . . . . . . . . . . . 16
9.5. RRO Label Sub-object Flag: Delegation Label . . . . . . . 17
9.6. Attributes Flags TLV: LSI-D-S2E . . . . . . . . . . . . . 17
9.7. Attributes TLV: ETLD . . . . . . . . . . . . . . . . . . 18
10. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11.1. Attribute Flags: TE Link Label, LSI-D, LSI-D-S2E . . . . 19
11.2. Attribute TLV: ETLD . . . . . . . . . . . . . . . . . . 19
11.3. Record Route Label Sub-object Flags: TE Link Label,
Delegation Label . . . . . . . . . . . . . . . . . . . . 20
11.4. Error Codes and Error Values . . . . . . . . . . . . . . 20
12. Security Considerations . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
The scaling of RSVP-TE [RFC3209] control-plane implementations can be improved by adopting the guidelines and mechanisms described in [RFC2961] and [RFC8370]. These documents do not affect the forwarding-plane state required to handle the control-plane state. The forwarding-plane state remains unchanged and is directly proportional to the total number of Label Switching Paths (LSPs) supported by the control plane.
通过采用[RFC2961]和[RFC8370]中描述的指南和机制，可以改进RSVP-TE[RFC3209]控制平面实现的缩放。这些文档不会影响处理控制平面状态所需的转发平面状态。转发平面状态保持不变，并与控制平面支持的标签交换路径（LSP）的总数成正比。
This document describes a mechanism that prevents the size of the platform-specific label space on a Label Switching Router (LSR) from being a constraint to pushing the limits of control-plane scaling on that node.
本文档描述了一种机制，该机制可防止标签交换路由器（LSR）上特定于平台的标签空间的大小成为该节点上控制平面缩放限制的约束。
This work introduces the notion of preinstalled 'per-TE link labels' that are allocated by an LSR. Each such label is installed in the MPLS forwarding plane with a 'pop' operation and instructions to forward the received packet over the TE link. An LSR advertises this label in the Label object of a Resv message as LSPs are set up, and they are recorded hop by hop in the Record Route Object (RRO) of the Resv message as it traverses the network. The ingress Label Edge Router (LER) constructs and pushes a stack of labels [RFC3031] using the labels received in the RRO. These 'TE link labels' can be shared by MPLS RSVP-TE LSPs that traverse the same TE link.
这项工作引入了由LSR分配的预安装“每TE链路标签”的概念。每个这样的标签安装在MPLS转发平面中，带有通过TE链路转发接收到的分组的“pop”操作和指令。LSR在设置LSP时在Resv消息的label对象中播发此标签，并在Resv消息穿越网络时在Resv消息的Record Route object（RRO）中逐跳记录这些标签。入口标签边缘路由器（LER）使用在RRO中接收的标签构造并推送标签堆栈[RFC3031]。这些“TE链路标签”可由穿过同一TE链路的MPLS RSVP-TE LSP共享。
This forwarding-plane behavior fits in the MPLS architecture [RFC3031] and is the same as that exhibited by Segment Routing (SR) [RFC8402] when using an MPLS forwarding plane and a series of adjacency segments [SEG-ROUTING]. This work couples the feature benefits of the RSVP-TE control plane with the simplicity of the SR MPLS forwarding plane.
此转发平面行为符合MPLS体系结构[RFC3031]，并且与使用MPLS转发平面和一系列相邻段[SEG-Routing]时段路由（SR）[RFC8402]显示的行为相同。这项工作将RSVP-TE控制平面的特性优势与SR MPLS转发平面的简单性结合起来。
RSVP-TE using a shared MPLS forwarding plane offers the following benefits:
使用共享MPLS转发平面的RSVP-TE具有以下优点：
1. Shared labels: The transit label on a TE link is shared among RSVP-TE tunnels traversing the link and is used independently of the ingress and egress of the LSPs.
1. 共享标签：TE链路上的传输标签在穿过链路的RSVP-TE隧道之间共享，并独立于LSP的入口和出口使用。
2. Faster LSP setup time: No forwarding-plane state needs to be programmed during LSP setup and teardown, resulting in faster provisioning and deprovisioning of LSPs.
2. 更快的LSP设置时间：在LSP设置和拆卸期间无需编程转发平面状态，从而加快LSP的设置和取消设置。
3. Hitless rerouting: New transit labels are not required during make-before-break (MBB) in scenarios where the new LSP instance traverses the exact same path as the old LSP instance. This saves the ingress LER and the services that use the tunnel from
3. 无故障重路由：在新LSP实例通过与旧LSP实例完全相同的路径的情况下，在先通后断（MBB）期间不需要新的传输标签。这将从中保存入口LER和使用隧道的服务
needing to update the forwarding plane with new tunnel labels, thereby making MBB events faster. Periodic MBB events are relatively common in networks that deploy the 'auto-bandwidth' feature on RSVP-TE LSPs to monitor bandwidth utilization and periodically adjust LSP bandwidth.
需要用新的隧道标签更新转发平面，从而使MBB事件更快。在RSVP-TE LSP上部署“自动带宽”功能以监控带宽利用率和定期调整LSP带宽的网络中，周期性MBB事件相对常见。
4. Mix-and-match labels: Both 'TE link labels' and regular labels can be used on transit hops for a single RSVP-TE tunnel (see Section 6). This allows backward compatibility with transit LSRs that provide regular labels in Resv messages.
4. 混合和匹配标签：“TE链路标签”和常规标签均可用于单个RSVP-TE隧道的运输跃点（见第6节）。这允许与在Resv消息中提供常规标签的传输LSR向后兼容。
No additional extensions to routing protocols are required in order to support key functionalities such as bandwidth admission control, LSP priorities, preemption, and auto-bandwidth on this shared MPLS forwarding plane. This document also discusses how Fast Reroute [RFC4090] via facility backup link protection using regular bypass tunnels can be supported on this forwarding plane.
无需对路由协议进行额外扩展，即可支持关键功能，如带宽许可控制、LSP优先级、抢占和此共享MPLS转发平面上的自动带宽。本文件还讨论了如何在此转发平面上通过使用常规旁路隧道的设施备份链路保护快速重新路由[RFC4090]。
The signaling procedures and extensions discussed in this document do not apply to Point to Multipoint (P2MP) RSVP-TE tunnels.
本文件中讨论的信令程序和扩展不适用于点对多点（P2MP）RSVP-TE隧道。
The following terms are used in this document:
本文件中使用了以下术语：
TE link label: An incoming label at an LSR that will be popped by the LSR with the packet being forwarded over a specific outgoing TE link to a neighbor.
TE链路标签：LSR上的传入标签，LSR将弹出该标签，数据包通过特定的传出TE链路转发到邻居。
Shared MPLS forwarding plane: An MPLS forwarding plane where every participating LSR uses TE link labels on every LSP.
共享MPLS转发平面：MPLS转发平面，其中每个参与的LSR在每个LSP上使用TE链路标签。
Segment Routed RSVP-TE tunnel: An MPLS RSVP-TE tunnel that requests the use of a shared MPLS forwarding plane at every hop of the LSP. The corresponding LSPs are referred to as "Segment Routed RSVP-TE LSPs".
段路由RSVP-TE隧道：一种MPLS RSVP-TE隧道，请求在LSP的每个跃点使用共享MPLS转发平面。相应的LSP称为“段路由RSVP-TE LSP”。
Delegation hop: A transit hop of a Segment Routed RSVP-TE LSP that is selected to assist in the imposition of the label stack in scenarios where the ingress LER cannot impose the full label stack. There can be multiple delegation hops along the path of a Segment Routed RSVP-TE LSP.
委派跃点：段路由RSVP-TE LSP的中转跃点，选择该跃点是为了在入口LER无法施加完整标签堆栈的情况下协助施加标签堆栈。沿段路由RSVP-TE LSP的路径可以有多个委派跃点。
Delegation label: A label assigned at the delegation hop to represent a set of labels that will be pushed at this hop.
委派标签：在委派跃点分配的标签，表示将在此跃点推送的一组标签。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
An LSR that participates in a shared MPLS forwarding plane MUST allocate a unique TE link label for each TE link. When an LSR encounters a TE link label at the top of the label stack, it MUST pop the label and forward the packet over the TE link to the downstream neighbor on the RSVP-TE tunnel.
参与共享MPLS转发平面的LSR必须为每个TE链路分配唯一的TE链路标签。当LSR遇到标签堆栈顶部的TE链路标签时，它必须弹出标签并通过TE链路将数据包转发到RSVP-TE隧道上的下游邻居。
Multiple TE link labels MAY be allocated for the TE link to accommodate tunnels requesting protection.
可为TE链路分配多个TE链路标签，以适应请求保护的隧道。
Implementations that maintain per-label bandwidth accounting at each hop must aggregate the reservations made for all the LSPs using the shared TE link label.
在每个跃点维护每个标签带宽记帐的实现必须使用共享TE链路标签聚合为所有LSP所做的保留。
This section provides an example of how the RSVP-TE signaling procedure works to set up a tunnel utilizing a shared MPLS forwarding plane. The sample topology below is used to explain the example. Labels shown at each node are TE link labels that, when present at the top of the label stack, indicate that they should be popped and that the packet should be forwarded on the TE link to the neighbor.
本节提供了RSVP-TE信令过程如何利用共享MPLS转发平面建立隧道的示例。下面的示例拓扑用于解释该示例。每个节点上显示的标签都是TE链路标签，当标签堆栈顶部出现时，这些标签表示应该弹出标签，并且数据包应该在TE链路上转发到邻居。
+---+100 +---+150 +---+200 +---+250 +---+
| A |-----| B |-----| C |-----| D |-----| E |
+---+ +---+ +---+ +---+ +---+
|110 |450 |550 |650 |850
| | | | |
| |400 |500 |600 |800
| +---+ +---+ +---+ +---+
+-------| F |-----|G |-----|H |-----|I |
+---+300 +---+350 +---+700 +---+
+---+100 +---+150 +---+200 +---+250 +---+
| A |-----| B |-----| C |-----| D |-----| E |
+---+ +---+ +---+ +---+ +---+
|110 |450 |550 |650 |850
| | | | |
| |400 |500 |600 |800
| +---+ +---+ +---+ +---+
+-------| F |-----|G |-----|H |-----|I |
+---+300 +---+350 +---+700 +---+
Figure 1: Sample Topology -- TE Link Labels
图1：示例拓扑--TE链接标签
Consider two tunnels:
考虑两条隧道：
RSVP-TE tunnel T1: From A to E on path A-B-C-D-E
RSVP-TE T1隧道：路径A-B-C-D-E上从A到E
RSVP-TE tunnel T2: From F to E on path F-B-C-D-E
RSVP-TE T2隧道：在F-B-C-D-E路径上从F到E
Both tunnels share the TE links B-C, C-D, and D-E.
两条隧道共用TE链路B-C、C-D和D-E。
RSVP-TE is used to signal the setup of tunnel T1 (using the TE link label attributes flag defined in Section 9.2). When LSR D receives the Resv message from the egress LER E, it checks the next-hop TE link (D-E) and provides the TE link label (250) in the Resv message for the tunnel placing the label value in the Label object. It also provides the TE link label (250) in the Label sub-object carried in the RRO and sets the TE link label flag as defined in Section 9.3.
RSVP-TE用于向隧道T1的设置发送信号（使用第9.2节中定义的TE链路标签属性标志）。当LSR D从出口LER E接收到Resv消息时，它检查下一跳TE链路（D-E），并在Resv消息中为隧道提供TE链路标签（250），将标签值放置在标签对象中。它还在RRO中携带的标签子对象中提供TE链接标签（250），并设置第9.3节中定义的TE链接标签标志。
Similarly, LSR C provides the TE link label (200) for the TE link C-D, and LSR B provides the TE link label (150) for the TE link B-C.
类似地，LSR C为TE链路C-D提供TE链路标签（200），LSR B为TE链路B-C提供TE链路标签（150）。
For tunnel T2, the transit LSRs provide the same TE link labels as described for tunnel T1 as the links B-C, C-D, and D-E are common between the two LSPs.
对于T2隧道，运输LSR提供与T1隧道相同的TE链路标签，因为两个LSP之间的链路B-C、C-D和D-E是共用的。
The ingress LERs (A and F) will push the same stack of labels (from top of stack to bottom of stack) {150, 200, 250} for tunnels T1 and T2, respectively.
入口LER（A和F）将分别为隧道T1和T2推送相同的标签堆栈（从堆栈顶部到堆栈底部）{150、200、250}。
It should be noted that a transit LSR does not swap the top TE link label on an incoming packet (the label that it advertised in the Resv message it sent); all it has to do is pop the top label and forward the packet.
应该注意的是，传输LSR不会交换传入数据包上的顶部TE链路标签（它在发送的Resv消息中公布的标签）；它所要做的就是弹出顶部标签并转发数据包。
The values in the Label sub-objects in the RRO are of interest to the ingress LERs when constructing the stack of labels to impose on the packets.
当构建标签堆栈以施加在数据包上时，RRO中标签子对象中的值是入口LER感兴趣的。
If, in this example, there were another RSVP-TE tunnel T3 from F to I on path F-B-C-D-E-I, then this tunnel would also share the TE links B-C, C-D, and D-E and traverse link E-I. The label stack used by F would be {150, 200, 250, 850}. Hence, regardless of where the LSPs start and end, they will share LSR labels at shared hops in the shared MPLS forwarding plane.
在本例中，如果在路径F-B-C-D-E-I上有另一个从F到I的RSVP-TE隧道T3，则该隧道还将共享TE链路B-C、C-D和D-E以及遍历链路E-I。F使用的标签堆栈将是{150、200、250、850}。因此，无论LSP从何处开始和结束，它们都将在共享MPLS转发平面中的共享跃点处共享LSR标签。
There MAY be a local operator policy at the ingress LER that influences the maximum depth of the label stack that can be pushed for a Segment Routed RSVP-TE tunnel. Prior to signaling the LSP, the ingress LER may determine that it is unable to push a label stack containing one label for each hop along the path. In some scenarios,
入口LER处可能存在影响标签堆栈最大深度的本地操作员策略，该标签堆栈可为段路由RSVP-TE隧道推送。在发信号通知LSP之前，入口LER可确定其无法沿路径上的每个跳推包含一个标签的标签栈。在某些情况下，
the ingress LER may not have sufficient information to make that determination. In these cases, the LER SHOULD adopt the techniques described in Section 5.
入口LER可能没有足够的信息进行该确定。在这些情况下，LER应采用第5节所述的技术。
One or more transit LSRs can assist the ingress LER by imposing part of the label stack required for the path. Consider the example in Figure 2 with an RSVP-TE tunnel from A to L on path A-B-C-D-E-F-G-H-I-J-K-L. In this case, the LSP is too long for LER A to impose the full label stack, so it uses the assistance of delegation hops LSR D and LSR I to impose parts of the label stack.
一个或多个中转LSR可以通过施加路径所需的标签堆栈的一部分来协助入口LER。考虑图2中的示例，从A到L的路径上的A -B-C-D-E-G-G-H-i-J-K-L。在这种情况下，LSP太长，使LER A不施加全标签堆栈，因此它使用委托跳LSR D和LSR I的辅助来强加标签堆栈的部分。
Each delegation hop allocates a delegation label to represent a set of labels that will be pushed at this hop. When a packet arrives at a delegation hop LSR with a delegation label, the LSR pops the label and pushes a set of labels before forwarding the packet.
每个委派跃点分配一个委派标签，以表示将在此跃点推送的一组标签。当数据包到达带有委派标签的委派跳LSR时，LSR弹出标签并在转发数据包之前推送一组标签。
1250d
+---+100p +---+150p +---+200p +---+250p +---+300p +---+
| A |------| B |------| C |------| D |------| E |------| F |
+---+ +---+ +---+ +---+ +---+ +---+
|350p
|
1500d |
+---+ 600p+---+ 550p+---+ 500p+---+ 450p+---+ 400p+---+
| L |------| K |------| J |------| I |------| H |------+ G +
+---+ +---+ +---+ +---+ +---+ +---+
1250d
+---+100p +---+150p +---+200p +---+250p +---+300p +---+
| A |------| B |------| C |------| D |------| E |------| F |
+---+ +---+ +---+ +---+ +---+ +---+
|350p
|
1500d |
+---+ 600p+---+ 550p+---+ 500p+---+ 450p+---+ 400p+---+
| L |------| K |------| J |------| I |------| H |------+ G +
+---+ +---+ +---+ +---+ +---+ +---+
Notation: <Label>p - TE link label
<Label>d - Delegation label
Notation: <Label>p - TE link label
<Label>d - Delegation label
Figure 2: Delegating Label Stack Imposition
图2：委派标签堆栈
When delegation labels come into play, there are two stacking approaches from which the ingress can choose. Section 7 explains how the label stack can be constructed.
当委托标签发挥作用时，入口可以选择两种堆叠方法。第7节解释了如何构造标签堆栈。
In this approach, the stack pushed by the ingress carries a set of labels that will take the packet to the first delegation hop. When this approach is employed, the set of labels represented by a delegation label at a given delegation hop will include the corresponding delegation label from the next delegation hop. As a result, this delegation label can only be shared among LSPs that are destined to the same egress and traverse the same downstream path.
在这种方法中，入口推送的堆栈携带一组标签，这些标签将把数据包带到第一个委派跳。当采用这种方法时，由给定委派跃点处的委派标签表示的标签集将包括来自下一委派跃点的相应委派标签。因此，此委派标签只能在目的地为同一出口并穿过同一下游路径的LSP之间共享。
This approach is shown in Figure 3. The delegation label 1250 represents the stack {300, 350, 400, 450, 1500}, and the delegation label 1500 represents the label stack {550, 600}.
这种方法如图3所示。委托标签1250表示堆栈{300、350、400、450、1500}，委托标签1500表示标签堆栈{550、600}。
+---+ +---+ +---+
| A |-----.....-----| D |-----.....-----| I |-----.....
+---+ +---+ +---+
+---+ +---+ +---+
| A |-----.....-----| D |-----.....-----| I |-----.....
+---+ +---+ +---+
Pop 1250 & Pop 1500 &
Push Push Push
...... ...... ......
: 150: 1250->: 300: 1500->: 550:
: 200: : 350: : 600:
:1250: : 400: ......
...... : 450:
:1500:
......
Pop 1250 & Pop 1500 &
Push Push Push
...... ...... ......
: 150: 1250->: 300: 1500->: 550:
: 200: : 350: : 600:
:1250: : 400: ......
...... : 450:
:1500:
......
Figure 3: Stack to Reach Delegation Hop
图3：到达委派跃点的堆栈
With this approach, the ingress LER A will push {150, 200, 1250} for the tunnel in Figure 2. At LSR D, the delegation label 1250 will get popped, and {300, 350, 400, 450, 1500} will get pushed. At LSR I, the delegation label 1500 will get popped, and the remaining set of labels {550, 600} will get pushed.
通过这种方法，入口LER A将推动图2中隧道的{1502001250}。在LSRD，将弹出委派标签1250，{3003504004501500}。在lsri，将弹出委托标签1500，并推送剩余的标签集{550600}。
In this approach, the stack pushed by the ingress carries a set of labels that will take the packet all the way to the egress so that all the delegation labels are part of the stack. When this approach is employed, the set of labels represented by a delegation label at a given delegation hop will not include the corresponding delegation label from the next delegation hop. As a result, this delegation label can be shared among all LSPs traversing the segment between the two delegation hops.
在这种方法中，入口推送的堆栈携带一组标签，这些标签将把数据包一直带到出口，以便所有委派标签都是堆栈的一部分。当采用这种方法时，由给定委派跃点处的委派标签表示的标签集将不包括来自下一委派跃点的相应委派标签。因此，该委派标签可以在穿过两个委派跳之间的段的所有LSP之间共享。
The downside of this approach is that the number of hops that the LSP can traverse is dictated by the label stack push limit of the ingress.
这种方法的缺点是LSP可以通过的跃点数由入口的标签堆栈推送限制决定。
This approach is shown in Figure 4. The delegation label 1250 represents the stack {300, 350, 400, 450}, and the delegation label 1500 represents the label stack {550, 600}.
这种方法如图4所示。委托标签1250表示堆栈{300、350、400、450}，委托标签1500表示标签堆栈{550、600}。
+---+ +---+ +---+
| A |-----.....-----| D |-----.....-----| I |-----.....
+---+ +---+ +---+
+---+ +---+ +---+
| A |-----.....-----| D |-----.....-----| I |-----.....
+---+ +---+ +---+
Pop 1250 & Pop 1500 &
Push Push Push
...... ...... ......
: 150: 1250->: 300: 1500->: 550:
: 200: : 350: : 600:
:1250: : 400: ......
:1500: : 450:
...... ......
|1500|
......
Pop 1250 & Pop 1500 &
Push Push Push
...... ...... ......
: 150: 1250->: 300: 1500->: 550:
: 200: : 350: : 600:
:1250: : 400: ......
:1500: : 450:
...... ......
|1500|
......
Figure 4: Stack to Reach Egress
图4：到达出口的烟囱
With this approach, the ingress LER A will push {150, 200, 1250, 1500} for the tunnel in Figure 2. At LSR D, the delegation label 1250 will get popped, and {300, 350, 400, 450} will get pushed. At LSR I, the delegation label 1500 will get popped, and the remaining set of labels {550, 600} will get pushed. The signaling extension required for the ingress to indicate the chosen stacking approach is defined in Section 9.6.
通过这种方法，入口LER A将推动图2中隧道的{15020012501500}。在LSRD，将弹出委派标签1250，{300350400450}。在lsri，将弹出委托标签1500，并推送剩余的标签集{550600}。第9.6节定义了入口指示所选堆叠方法所需的信号扩展。
In this delegation option, the ingress LER can explicitly delegate one or more specific transit LSRs to handle pushing labels for a certain number of their downstream hops. In order to accurately pick the delegation hops, the ingress needs to be aware of the label stack depth push limit (total number of MPLS labels that can be imposed, including all service/transport/special labels) of each of the transit LSRs prior to initiating the signaling sequence. The mechanism by which the ingress or controller (hosting the path computation element) learns this information is outside the scope of this document. Base MPLS Imposition MSD (BMI-MSD) advertisement, specified in [RFC8491], is an example of such a mechanism.
在该委派选项中，入口LER可以显式委派一个或多个特定的运输LSR，以处理特定数量的下游跃点的推送标签。为了准确地拾取委派跳数，入口需要在启动信令序列之前知道每个中转lsr的标签堆栈深度推送限制（可施加的MPLS标签的总数，包括所有服务/传输/特殊标签）。入口或控制器（承载路径计算元素）学习此信息的机制不在本文档范围内。[RFC8491]中规定的基本MPLS强加MSD（BMI-MSD）广告就是此类机制的一个示例。
The signaling extension required for the ingress LER to explicitly delegate one or more specific transit hops is defined in Section 9.4. The extension required for the delegation hop to indicate that the recorded label is a delegation label is defined in Section 9.5.
第9.4节定义了入口LER明确委派一个或多个特定传输跃点所需的信令扩展。第9.5节定义了授权跃点所需的扩展，以表明记录的标签是授权标签。
In this approach, the ingress LER lets the downstream LSRs automatically pick suitable delegation hops during the initial signaling sequence. The ingress does not need to be aware up front of the label stack depth push limit of each of the transit LSRs. This approach SHOULD be used if there are loose hops [RFC3209] in the explicit route. The delegation hops are picked based on a per-hop signaled attribute called the Effective Transport Label-Stack Depth (ETLD), as described in the next section.
在这种方法中，入口LER允许下游LSR在初始信令序列期间自动选择合适的委派跳。入口不需要预先知道每个运输LSR的标签堆栈深度推送限制。如果显式路由中存在松散跃点[RFC3209]，则应使用此方法。如下一节所述，委派跃点是基于称为有效传输标签堆栈深度（ETLD）的每跃点信号属性选择的。
The ETLD is signaled as a per-hop recorded attribute in the Path message [RFC7570]. When automatic delegation is requested, the ingress MUST populate the ETLD with the maximum number of transport labels that it can potentially send to its downstream hop. This value is then decremented at each successive hop. If a node is reached and it is determined that this hop cannot support automatic delegation, then it MUST NOT use TE link labels and use regular labels instead. If a node is reached where the ETLD set from the previous hop is 1, then that node MUST select itself as the delegation hop. If a node is reached and it is determined that this hop cannot receive more than one transport label, then that node MUST select itself as the delegation hop. If there is a node or a sequence of nodes along the path of the LSP that do not support ETLD, then the immediate hop that supports ETLD MUST select itself as the delegation hop. The ETLD MUST be decremented at each non-delegation transit hop by either 1 or some appropriate number based on the local
ETLD作为路径消息[RFC7570]中每跳记录的属性发出信号。当请求自动委派时，入口必须向ETLD填充最大数量的传输标签，该标签可能会发送到其下游跃点。然后，该值在每个连续跃点处递减。如果到达一个节点，并且确定该跃点不能支持自动委派，则它不能使用TE链接标签，而必须使用常规标签。如果到达上一跳的ETLD集为1的节点，则该节点必须选择自身作为委派跳。如果到达一个节点，并且确定该跃点不能接收多个传输标签，则该节点必须选择自身作为委派跃点。如果LSP路径上有一个节点或一系列节点不支持ETLD，那么支持ETLD的立即跃点必须选择自己作为委派跃点。ETLD必须在每个非委托传输跃点处递减1或基于本地数据的某个适当数字
policy. For example, consider a transit node with a local policy that mandates it to take the label stack read limit into account when decrementing the ETLD. With this policy, the ETLD is decremented in such a way that the transit hop does not receive more labels in the stack than it can read. At each delegation hop, the ETLD MUST be reset to the maximum number of transport labels that the hop can send, and the ETLD decrements start again at each successive hop until either a new delegation hop is selected or the egress is reached. As a result, by the time the Path message reaches the egress, all delegation hops are selected. During the Resv processing, at each delegation hop, a suitable delegation label is selected (either an existing label is reused or a new label is allocated) and recorded in the Resv message.
政策例如，考虑一个带有本地策略的转接节点，它规定在递减ETLD时考虑标签堆栈读取限制。使用此策略，ETLD将以这样的方式递减，即传输跃点在堆栈中接收的标签不会超过其可以读取的数量。在每个委派跃点处，必须将ETLD重置为该跃点可以发送的最大传输标签数，并且在每个连续跃点处再次开始ETLD递减，直到选择新委派跃点或到达出口。结果，当路径消息到达出口时，所有委派跳都被选中。在Resv处理过程中，在每个委派跃点，选择合适的委派标签（重用现有标签或分配新标签）并记录在Resv消息中。
Consider the example shown in Figure 5. Let's assume ingress LER A can push up to three transport labels while the remaining nodes can push up to five transport labels. The ingress LER A signals the initial Path message with ETLD set to 3. The ETLD value is adjusted at each successive hop and signaled downstream as shown. By the time the Path message reaches the egress LER L, LSRs D and I are automatically selected as delegation hops.
考虑图5中所示的示例。假设入口LER A最多可以推送三个传输标签，而其余节点最多可以推送五个传输标签。入口LER A向初始路径消息发送信号，ETLD设置为3。ETLD值在每个连续跃点处调整，并向下游发送信号，如图所示。当路径消息到达出口LER L时，LSR D和I被自动选择为委派跳。
ETLD:3 ETLD:2 ETLD:1 ETLD:5 ETLD:4
-----> -----> -----> -----> ----->
1250d
+---+100p +---+150p +---+200p +---+250p +---+300p +---+
| A |-----| B |-----| C |-----| D |-----| E |-----| F | ETLD:3
+---+ +---+ +---+ +---+ +---+ +---+ |
|350p |
| |
1500d | |
+---+ 600p+---+ 550p+---+ 500p+---+ 450p+---+ 400p+---+ v
| L |-----| K |-----| J |-----| I |-----| H |-----+ G +
+---+ +---+ +---+ +---+ +---+ +---+
ETLD:3 ETLD:2 ETLD:1 ETLD:5 ETLD:4
-----> -----> -----> -----> ----->
1250d
+---+100p +---+150p +---+200p +---+250p +---+300p +---+
| A |-----| B |-----| C |-----| D |-----| E |-----| F | ETLD:3
+---+ +---+ +---+ +---+ +---+ +---+ |
|350p |
| |
1500d | |
+---+ 600p+---+ 550p+---+ 500p+---+ 450p+---+ 400p+---+ v
| L |-----| K |-----| J |-----| I |-----| H |-----+ G +
+---+ +---+ +---+ +---+ +---+ +---+
ETLD:3 ETLD:4 ETLD:5 ETLD:1 ETLD:2
<----- <----- <----- <----- <-----
ETLD:3 ETLD:4 ETLD:5 ETLD:1 ETLD:2
<----- <----- <----- <----- <-----
Figure 5: ETLD
图5:ETLD
When an LSP that requests automatic delegation also requests facility backup protection [RFC4090], the ingress or the delegation hop MUST account for the bypass tunnel's label(s) when populating the ETLD. Hence, when a regular bypass tunnel is used to protect the facility, the ETLD that gets populated on these nodes is one less than what gets populated for a corresponding unprotected LSP.
当请求自动委派的LSP也请求设施备份保护[RFC4090]时，入口或委派跃点必须在填充ETLD时说明旁路隧道的标签。因此，当使用常规旁路隧道来保护设施时，在这些节点上填充的ETLD比为相应的未受保护的LSP填充的ETLD少一个。
Signaling extension for the ingress LER to request automatic delegation is defined in Section 9.4. The extension for signaling the ETLD is defined in Section 9.7. The extension required for the delegation hop to indicate that the recorded label is a delegation label is defined in Section 9.5.
第9.4节定义了入口LER请求自动授权的信令扩展。第9.7节定义了ETLD的信号扩展。第9.5节定义了授权跃点所需的扩展，以表明记录的标签是授权标签。
Labels can be mixed across transit hops in a single MPLS RSVP-TE LSP. Certain LSRs can use TE link labels and others can use regular labels. The ingress can construct a label stack appropriately based on what type of label is recorded from every transit LSR.
标签可以在单个MPLS RSVP-TE LSP中跨传输跃点混合。某些LSR可以使用TE链接标签，而其他LSR可以使用常规标签。入口可以根据从每个运输LSR记录的标签类型适当地构建标签堆栈。
(#) (#)
+---+100 +---+150 +---+200 +---+250 +---+
| A |-----| B |-----| C |-----| D |-----| E |
+---+ +---+ +---+ +---+ +---+
|110 |450 |550 |650 |850
| | | | |
| |400 |500 |600 |800
| +---+ +---+ +---+ +---+
+-------| F |-----|G |-----|H |-----|I |
+---+300 +---+350 +---+700 +---+
(#) (#)
+---+100 +---+150 +---+200 +---+250 +---+
| A |-----| B |-----| C |-----| D |-----| E |
+---+ +---+ +---+ +---+ +---+
|110 |450 |550 |650 |850
| | | | |
| |400 |500 |600 |800
| +---+ +---+ +---+ +---+
+-------| F |-----|G |-----|H |-----|I |
+---+300 +---+350 +---+700 +---+
Notation: (#) denotes regular labels Other labels are TE link labels
符号：（#）表示常规标签，其他标签为TE链接标签
Figure 6: Sample Topology -- TE Link Labels and Regular Labels
图6：示例拓扑--TE链接标签和常规标签
If the transit LSR allocates a regular label to be sent upstream in the Resv, then the label operation at the LSR is a swap to the label received from the downstream LSR. If the transit LSR is using a TE link label to be sent upstream in the Resv, then the label operation at the LSR is a pop and forward regardless of any label received from the downstream LSR. There is no change in the behavior of a penultimate hop popping (PHP) LSR [RFC3031].
如果运输LSR分配了一个要在Resv中向上游发送的常规标签，则LSR处的标签操作是对从下游LSR接收的标签的交换。如果运输LSR使用要在Resv中向上游发送的TE链路标签，则LSR处的标签操作是pop和forward，而不管从下游LSR接收到任何标签。倒数第二跳弹出（PHP）LSR[RFC3031]的行为没有变化。
Section 7 explains how the label stack can be constructed. For example, the LSP from A to I using path A-B-C-D-E-I will use a label stack of {150, 200}.
第7节解释了如何构造标签堆栈。例如，使用路径A-B-C-D-E-I的从A到I的LSP将使用{150200}的标签堆栈。
The ingress LER or delegation hop MUST check the type of label received from each transit hop as recorded in the RRO in the Resv message and generate the appropriate label stack to reach the next delegation hop or the egress.
入口LER或委派跃点必须检查从每个中转跃点接收的标签类型，如Resv消息中的RRO中记录的，并生成适当的标签堆栈以到达下一个委派跃点或出口。
The following logic is used by the node constructing the label stack:
构建标签堆栈的节点使用以下逻辑：
Each RRO label sub-object MUST be processed starting with the label sub-object from the first downstream hop. Any label provided by the first downstream hop MUST always be pushed on the label stack regardless of the label type. If the label type is a TE link label, then any label from the next downstream hop MUST also be pushed on the constructed label stack. If the label type is a regular label, then any label from the next downstream hop MUST NOT be pushed on the constructed label stack. If the label type is a delegation label, then the type of stacking approach chosen by the ingress for this LSP (Section 5.1) MUST be used to determine how the delegation labels are pushed in the label stack.
必须从第一个下游跃点的标签子对象开始处理每个RRO标签子对象。无论标签类型如何，必须始终将第一个下游跃点提供的任何标签推送到标签堆栈上。如果标签类型是TE链接标签，则来自下一个下游跃点的任何标签也必须推送到构造的标签堆栈上。如果标签类型是常规标签，则不得将来自下一个下游跃点的任何标签推送到构造的标签堆栈上。如果标签类型是委派标签，则必须使用入口为此LSP（第5.1节）选择的堆叠方法类型来确定如何将委派标签推入标签堆栈。
The following section describes how link protection works with facility backup protection [RFC4090] using regular bypass tunnels for the Segment Routed RSVP-TE tunnels. The procedures for supporting node protection are not discussed in this document. The use of Segment Routed bypass tunnels for providing facility protection is left for further study.
下节介绍链路保护如何与设施备份保护[RFC4090]一起工作，该保护使用常规旁路隧道，用于段路由RSVP-TE隧道。本文档中不讨论支持节点保护的过程。使用分段路由旁路隧道提供设施保护的问题有待进一步研究。
To provide link protection at a Point of Local Repair (PLR) with a shared MPLS forwarding plane, the LSR MUST allocate a separate TE link label for the TE link that will be used for RSVP-TE tunnels that request link protection from the ingress. No signaling extensions are required to support link protection for RSVP-TE tunnels over the shared MPLS forwarding plane.
为了使用共享MPLS转发平面在本地修复点（PLR）提供链路保护，LSR必须为TE链路分配单独的TE链路标签，该标签将用于从入口请求链路保护的RSVP-TE隧道。不需要信令扩展来支持共享MPLS转发平面上RSVP-TE隧道的链路保护。
At each LSR, link-protected TE link labels can be allocated for each TE link, and a link-protecting facility backup LSP can be created to protect the TE link. The link-protected TE link label can be sent by the LSR for LSPs requesting link protection over the specific TE link. Since the facility backup terminates at the next hop (merge point), the incoming label on the packet will be what the merge point expects.
在每个LSR处，可以为每个TE链路分配链路保护的TE链路标签，并且可以创建链路保护设施备份LSP来保护TE链路。链路保护的TE链路标签可由LSR发送给请求通过特定TE链路进行链路保护的LSP。由于设备备份在下一个跃点（合并点）终止，因此数据包上的传入标签将是合并点所期望的。
Consider the network shown in Figure 7. LSR B can install a facility backup LSP for the link-protected TE link label 151. When the TE link B-C is up, LSR B will pop 151 and send the packet to C. If the TE link B-C is down, the LSR can pop 151 and send the packet via the facility backup to C.
考虑图7所示的网络。LSR B可以为链路保护TE链路标签151安装设施备份LSP。当TE链路B-C打开时，LSR B将弹出151并将数据包发送给C。如果TE链路B-C关闭，LSR可以弹出151并通过设备备份将数据包发送给C。
101(*) 151(*) 201(*) 251(*)
+---+100 +---+150 +---+200 +---+250 +---+
| A |------| B |------| C |------| D |------| E |
+---+ +---+ +---+ +---+ +---+
|110 |450 |550 |650 |850
| | | | |
| |400 |500 |600 |800
| +---+ +---+ +---+ +---+
+--------| F |------|G |------|H |------|I |
+---+300 +---+350 +---+700 +---+
101(*) 151(*) 201(*) 251(*)
+---+100 +---+150 +---+200 +---+250 +---+
| A |------| B |------| C |------| D |------| E |
+---+ +---+ +---+ +---+ +---+
|110 |450 |550 |650 |850
| | | | |
| |400 |500 |600 |800
| +---+ +---+ +---+ +---+
+--------| F |------|G |------|H |------|I |
+---+300 +---+350 +---+700 +---+
Notation: (*) denotes link-protected TE link labels
符号：（*）表示受链接保护的TE链接标签
Figure 7: Link Protection Topology
图7：链路保护拓扑
The functionality discussed in this document imposes the following requirements on the signaling protocol.
本文档中讨论的功能对信令协议提出了以下要求。
o The ingress of the LSP needs to have the ability to mandate/ request the use and recording of TE link labels at all hops along the path of the LSP.
o LSP的入口需要能够强制/请求在沿着LSP路径的所有跃点处使用和记录TE链路标签。
o When the use of TE link labels is mandated/requested for the path:
o 当强制/请求为路径使用TE链接标签时：
* the node recording the TE link label needs to have the ability to indicate whether the recorded label is a TE link label.
* 记录TE链接标签的节点需要能够指示记录的标签是否为TE链接标签。
* the ingress needs to have the ability to delegate label stack imposition by:
* 入口需要能够通过以下方式委托标签堆栈施加：
+ explicitly mandating specific hops to be delegation hops, or
+ 明确指定特定跃点为委派跃点，或
+ requesting automatic delegation.
+ 请求自动授权。
* When explicit delegation is mandated or automatic delegation is requested:
* 当强制执行显式委派或请求自动委派时：
+ the ingress needs to have the ability to indicate the chosen stacking approach, and
+ 入口需要能够指示选择的堆叠方法，以及
+ the delegation hop needs to have the ability to indicate that the recorded label is a delegation label.
+ 委派跃点需要能够指示记录的标签是委派标签。
Bit Number 16: TE Link Label
位号16:TE链路标签
The presence of this flag in the LSP_ATTRIBUTES/ LSP_REQUIRED_ATTRIBUTES object [RFC5420] of a Path message indicates that the ingress has requested/mandated the use and recording of TE link labels at all hops along the path of this LSP. When a node that recognizes this flag but does not cater to the mandate because of local policy receives a Path message carrying the LSP_REQUIRED_ATTRIBUTES object with this flag set, it MUST send a PathErr message with an error code of 'Routing Problem (24)' and an error value of 'TE link label usage failure (70)'. A transit hop that caters to this request/mandate MUST also check for the presence of other Attribute Flags introduced in this document (Sections 9.4 and 9.6) and process them as specified. An ingress LER that sets this bit MUST also set the "label recording desired" flag [RFC3209] in the SESSION_ATTRIBUTE object.
路径消息的LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES对象[RFC5420]中存在此标志表示入口已请求/强制在该LSP路径上的所有跃点处使用和记录TE链路标签。当识别此标志但由于本地策略而不符合授权的节点接收到带有此标志集的LSP_REQUIRED_ATTRIBUTES对象的路径消息时，它必须发送一条PathErr消息，错误代码为“路由问题（24）”，错误值为“TE链路标签使用失败（70）”。满足此请求/授权的传输跃点还必须检查是否存在本文件（第9.4节和第9.6节）中介绍的其他属性标志，并按照规定进行处理。设置该位的入口LER还必须在会话_属性对象中设置“标签记录所需”标志[RFC3209]。
Flag (0x02): TE Link Label
标志（0x02）：TE链接标签
The presence of this flag indicates that the recorded label is a TE link label. This flag MUST be used by a node only if the use and recording of TE link labels are requested/mandated for the LSP.
此标志的存在表示记录的标签是TE链接标签。仅当请求/强制LSP使用和记录TE链路标签时，节点才能使用此标志。
Bit Number 17: Label Stack Imposition - Delegation (LSI-D)
位号17：标签堆栈施加-委托（LSI-D）
Automatic Delegation: The presence of this flag in the LSP_ATTRIBUTES object of a Path message indicates that the ingress has requested automatic delegation of label stack imposition. This flag MUST be set in the LSP_ATTRIBUTES object of a Path message only if the use and recording of TE link labels are requested/mandated for this LSP. If the transit hop does not support this flag, it MUST NOT use TE link labels and use regular labels instead. If the use of TE link
自动委派：路径消息的LSP_ATTRIBUTES对象中存在此标志表示入口已请求标签堆栈的自动委派。仅当针对该LSP请求/强制使用和记录TE链路标签时，才能在路径消息的LSP_ATTRIBUTES对象中设置该标志。如果传输跃点不支持此标志，则不得使用TE链接标签，而应使用常规标签。如果使用TE链接
labels was mandated in the LSP_REQUIRED_ATTRIBUTES object, it MUST send a PathErr message with an error code of 'Routing Problem (24)' and an error value of 'TE link label usage failure (70)'.
标签在LSP_REQUIRED_ATTRIBUTES对象中被强制使用，它必须发送一条PathErr消息，错误代码为“路由问题（24）”，错误值为“TE链路标签使用失败（70）”。
Explicit Delegation: The presence of this flag in the HOP_ATTRIBUTES sub-object [RFC7570] of an Explicit Route Object (ERO) in the Path message indicates that the hop identified by the preceding IPv4 or IPv6 or Unnumbered Interface ID sub-object has been picked as an explicit delegation hop. The HOP_ATTRIBUTES sub-object carrying this flag MUST have the R (Required) bit set. This flag MUST be set in the HOP_ATTRIBUTES sub-object of an ERO object in the Path message only if the use and recording of TE link labels are requested/ mandated for this LSP. If the hop recognizes this flag but is not able to comply with this mandate because of local policy, it MUST send a PathErr message with an error code of 'Routing Problem (24)' and an error value of 'Label stack imposition failure (71)'.
显式委派：路径消息中显式路由对象（ERO）的HOP_ATTRIBUTES子对象[RFC7570]中存在此标志表示已将前面IPv4或IPv6或未编号接口ID子对象标识的跃点选为显式委派跃点。携带此标志的HOP_ATTRIBUTES子对象必须设置R（必需）位。仅当针对该LSP请求/强制使用和记录TE链路标签时，必须在路径消息中ERO对象的HOP_ATTRIBUTES子对象中设置该标志。如果跃点识别此标志，但由于本地策略而无法遵守此授权，则它必须发送一条PathErr消息，错误代码为“路由问题（24）”，错误值为“标签堆栈强制设置失败（71）”。
Flag (0x04): Delegation Label
标志（0x04）：委派标签
The presence of this flag indicates that the recorded label is a delegation label. This flag MUST be used by a node only if the use and recording of TE link labels and delegation are requested/mandated for the LSP.
此标志的存在表示记录的标签是委派标签。仅当请求/强制LSP使用和记录TE链路标签和委派时，节点才能使用此标志。
Bit Number 18: Label Stack Imposition - Delegation - Stack to Reach Egress (LSI-D-S2E)
位号18：标签堆栈施加-授权-堆栈到达出口（LSI-D-S2E）
The presence of this flag in the LSP_ATTRIBUTES object of a Path message indicates that the ingress has chosen to use the "Stack to reach egress" approach for stacking. The absence of this flag in the LSP_ATTRIBUTES object of a Path message indicates that the ingress has chosen to use the "Stack to reach delegation hop" approach for stacking. This flag MUST be set in the LSP_ATTRIBUTES object of a Path message only if the use and recording of TE link labels and delegation are requested/mandated for this LSP. If the transit hop is not able to support the "Stack to reach egress" approach, it MUST send a PathErr message with an error code of 'Routing Problem (24)' and an error value of 'Label stack imposition failure (71)'.
路径消息的LSP_ATTRIBUTES对象中存在该标志表示入口已选择使用“堆栈到达出口”方法进行堆栈。路径消息的LSP_ATTRIBUTES对象中缺少此标志表示入口已选择使用“堆栈到达委派跃点”方法进行堆栈。仅当针对该LSP请求/强制使用和记录TE链接标签和委派时，才能在路径消息的LSP_ATTRIBUTES对象中设置该标志。如果传输跃点无法支持“堆栈到达出口”方法，则它必须发送一条PathErr消息，错误代码为“路由问题（24）”，错误值为“标签堆栈施加失败（71）”。
The format of the ETLD Attributes TLV is shown in Figure 8. The Attribute TLV Type is 6.
ETLD属性TLV的格式如图8所示。属性TLV类型为6。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | ETLD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | ETLD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: The ETLD Attributes TLV
图8:ETLD属性TLV
The presence of this TLV in the HOP_ATTRIBUTES sub-object of an RRO object in the Path message indicates that the hop identified by the preceding IPv4 or IPv6 or Unnumbered Interface ID sub-object supports automatic delegation. This attribute MUST be used only if the use and recording of TE link labels are requested/mandated and automatic delegation is requested for the LSP.
路径消息中RRO对象的HOP_ATTRIBUTES子对象中存在此TLV表示由前面的IPv4或IPv6或未编号的接口ID子对象标识的跃点支持自动委派。只有在请求/强制使用TE链接标签并请求LSP自动委派时，才能使用此属性。
The ETLD field specifies the effective number of transport labels that this hop (in relation to its position in the path) can potentially send to its downstream hop. It MUST be set to a non-zero value.
ETLD字段指定此跃点（相对于其在路径中的位置）可能发送到其下游跃点的传输标签的有效数量。必须将其设置为非零值。
The Reserved field is for future specification. It SHOULD be set to zero on transmission and MUST be ignored on receipt to ensure future compatibility.
保留字段用于将来的规范。传输时应将其设置为零，接收时必须忽略，以确保将来的兼容性。
MPLS LSP ping and traceroute [RFC8029] are applicable for Segment Routed RSVP-TE tunnels. The existing procedures allow for the label stack imposed at a delegation hop to be reported back in the Label Stack Sub-TLV in the MPLS echo reply for traceroute.
MPLS LSP ping和跟踪路由[RFC8029]适用于段路由RSVP-TE隧道。现有的过程允许将在委派跃点施加的标签堆栈报告回跟踪路由的MPLS回送回复中的标签堆栈子TLV中。
IANA manages the 'Attribute Flags' subregistry as part of the 'Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters' registry located at <http://www.iana.org/assignments/ rsvp-te-parameters>. This document introduces three new Attribute Flags:
IANA管理“属性标志”子区，作为“资源预留协议流量工程（RSVP-TE）参数”注册表的一部分，该注册表位于<http://www.iana.org/assignments/ rsvp te参数>。本文档介绍了三个新的属性标志：
Bit Name Attribute Attribute RRO ERO Reference No Flags Path Flags Resv
位名称属性属性RRO ERO引用无标志路径标志Resv
16 TE Link Label Yes No No No [RFC8577], Section 9.2
16 TE链路标签是否[RFC8577]，第9.2节
17 LSI-D Yes No No Yes [RFC8577], Section 9.4
17 LSI-D是否是[RFC8577]，第9.4节
18 LSI-D-S2E Yes No No No [RFC8577], Section 9.6
18 LSI-D-S2E是否[RFC8577]，第9.6节
IANA manages the "Attribute TLV Space" registry as part of the 'Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters' registry located at <http://www.iana.org/assignments/ rsvp-te-parameters>. This document introduces a new Attribute TLV.
IANA管理“属性TLV空间”注册表，作为位于的“资源预留协议流量工程（RSVP-TE）参数”注册表的一部分<http://www.iana.org/assignments/ rsvp te参数>。本文档介绍了一个新属性TLV。
Type Name Allowed on Allowed on Allowed on Reference LSP_ATTRIBUTES LSP_REQUIRED LSP Hop _ATTRIBUTES Attributes
引用LSP_属性LSP_必需的LSP跃点属性上允许的类型名称
6 ETLD No No Yes [RFC8577], Section 9.7
6 ETLD否是[RFC8577]，第9.7节
11.3. Record Route Label Sub-object Flags: TE Link Label, Delegation Label
11.3. 记录路由标签子对象标志：TE链接标签、委派标签
IANA manages the "Record Route Object Sub-object Flags" registry as part of the "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" registry located at <http://www.iana.org/assignments/ rsvp-te-parameters>. Prior to this document, this registry did not include Label Sub-object Flags. This document creates the addition of a new subregistry for Label Sub-object Flags as shown below.
IANA管理“记录路由对象子对象标志”注册表，作为位于的“资源预留协议流量工程（RSVP-TE）参数”注册表的一部分<http://www.iana.org/assignments/ rsvp te参数>。在此文档之前，此注册表不包括标签子对象标志。本文档为标签子对象标志创建了一个新的子区域，如下所示。
Flag Name Reference
标志名称引用
0x1 Global Label [RFC3209] 0x02 TE Link Label [RFC8577], Section 9.3 0x04 Delegation Label [RFC8577], Section 9.5
0x1全局标签[RFC3209]0x02 TE链接标签[RFC8577]，第9.3节0x04委派标签[RFC8577]，第9.5节
IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a subregistry called "Error Codes and Globally-Defined Error Value Sub-Codes". Within this subregistry is a definition of the "Routing Problem" Error Code (24). The definition lists a number of error values that may be used with this error code. IANA has allocated further error values for use with this Error Code as described in this document. The resulting entry in the registry is as follows.
IANA维护一个名为“资源保留协议（RSVP）参数”的注册表，该注册表具有一个名为“错误代码和全局定义的错误值子代码”的子区域。在该分区域中，定义了“路由问题”错误代码（24）。该定义列出了许多可能与此错误代码一起使用的错误值。IANA已经分配了更多的错误值，以便与本文档中描述的错误代码一起使用。注册表中的结果项如下所示。
24 Routing Problem [RFC3209]
24路由问题[RFC3209]
This Error Code has the following globally defined Error Value sub-codes:
此错误代码具有以下全局定义的错误值子代码：
70 = TE link label usage failure [RFC8577] 71 = Label stack imposition failure [RFC8577]
70=TE链路标签使用故障[RFC8577]71=标签堆栈强制设置故障[RFC8577]
This document does not introduce new security issues. The security considerations pertaining to the original RSVP protocol [RFC2205] and RSVP-TE [RFC3209] and those that are described in [RFC5920] remain relevant.
本文档不会引入新的安全问题。与原始RSVP协议[RFC2205]和RSVP-TE[RFC3209]以及[RFC5920]中描述的安全注意事项相关的安全注意事项仍然相关。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://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, <https://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月<https://www.rfc-editor.org/info/rfc2205>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 3031，DOI 10.17487/RFC3031，2001年1月<https://www.rfc-editor.org/info/rfc3031>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc3209>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, <https://www.rfc-editor.org/info/rfc4090>.
[RFC4090]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE的快速重路由扩展”，RFC 4090，DOI 10.17487/RFC4090，2005年5月<https://www.rfc-editor.org/info/rfc4090>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc5420>.
[RFC7570] Margaria, C., Ed., Martinelli, G., Balls, S., and B. Wright, "Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)", RFC 7570, DOI 10.17487/RFC7570, July 2015, <https://www.rfc-editor.org/info/rfc7570>.
[RFC7570]Margaria，C.，Ed.，Martinelli，G.，Balls，S.，和B.Wright，“显式路由对象（ERO）中的标签交换路径（LSP）属性”，RFC 7570，DOI 10.17487/RFC7570，2015年7月<https://www.rfc-editor.org/info/rfc7570>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, <https://www.rfc-editor.org/info/rfc8029>.
[RFC8029]Kompella，K.，Swallow，G.，Pignataro，C.，Ed.，Kumar，N.，Aldrin，S.，和M.Chen，“检测多协议标签交换（MPLS）数据平面故障”，RFC 8029，DOI 10.17487/RFC8029，2017年3月<https://www.rfc-editor.org/info/rfc8029>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, <https://www.rfc-editor.org/info/rfc2961>.
[RFC2961]Berger，L.，Gan，D.，Swallow，G.，Pan，P.，Tommasi，F.，和S.Molendini，“RSVP刷新开销减少扩展”，RFC 2961，DOI 10.17487/RFC29612001年4月<https://www.rfc-editor.org/info/rfc2961>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，DOI 10.17487/RFC5920，2010年7月<https://www.rfc-editor.org/info/rfc5920>.
[RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and T. Saad, "Techniques to Improve the Scalability of RSVP-TE Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, <https://www.rfc-editor.org/info/rfc8370>.
[RFC8370]Beeram，V.，Ed.，Minei，I.，Shakir，R.，Pacella，D.，和T.Saad，“提高RSVP-TE部署可扩展性的技术”，RFC 8370，DOI 10.17487/RFC8370，2018年5月<https://www.rfc-editor.org/info/rfc8370>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8402]Filsfils，C.，Ed.，Previdi，S.，Ed.，Ginsberg，L.，Decarene，B.，Litkowski，S.，和R.Shakir，“段路由架构”，RFC 8402，DOI 10.17487/RFC8402，2018年7月<https://www.rfc-editor.org/info/rfc8402>.
[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, DOI 10.17487/RFC8491, November 2018, <https://www.rfc-editor.org/info/rfc8491>.
[RFC8491]Tantsura，J.，Chunduri，U.，Aldrin，S.，和L.Ginsberg，“使用IS-IS发出最大SID深度（MSD）信号”，RFC 8491，DOI 10.17487/RFC8491，2018年11月<https://www.rfc-editor.org/info/rfc8491>.
[SEG-ROUTING] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", Work in Progress, draft-ietf-spring-segment-routing-mpls-18, December 2018.
[SEG-ROUTING]Bashandy，A.，Ed.，Filsfils，C.，Ed.，Previdi，S.，DeClaene，B.，Litkowski，S.，和R.Shakir，“使用MPLS数据平面的段路由”，正在进行的工作，草案-ietf-spring-Segment-ROUTING-MPLS-18，2018年12月。
Acknowledgements
致谢
The authors would like to thank Adrian Farrel, Kireeti Kompella, Markus Jork, and Ross Callon for their input from discussions. Adrian Farrel provided a review and a text suggestion for clarity and readability.
作者要感谢Adrian Farrel、Kireeti Kompella、Markus Jork和Ross Callon在讨论中提供的意见。阿德里安·法雷尔（Adrian Farrel）为清晰易读提供了评论和文本建议。
Contributors
贡献者
The following individuals contributed to this document:
以下个人对本文件作出了贡献：
Raveendra Torvi Juniper Networks Email: rtorvi@juniper.net
Raveendra Torvi Juniper Networks电子邮件：rtorvi@juniper.net
Chandra Ramachandran Juniper Networks Email: csekar@juniper.net
Chandra Ramachandran Juniper Networks电子邮件：csekar@juniper.net
George Swallow Email: swallow.ietf@gmail.com
乔治·斯沃恩电子邮件：斯沃恩。ietf@gmail.com
Authors' Addresses
作者地址
Harish Sitaraman Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 United States of America
Harish Sitaraman Juniper Networks 1133 Innovation Way Sunnyvale，加利福尼亚州，美国94089
Email: harish.ietf@gmail.com
Email: harish.ietf@gmail.com
Vishnu Pavan Beeram Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States of America
Vishnu Pavan Beeram Juniper Networks美国马萨诸塞州韦斯特福德科技园大道10号，邮编01886
Email: vbeeram@juniper.net
Email: vbeeram@juniper.net
Tejal Parikh Verizon 400 International Parkway Richardson, TX 75081 United States of America
Tejal Parikh Verizon 400国际大道Richardson，德克萨斯州75081美利坚合众国
Email: tejal.parikh@verizon.com
Email: tejal.parikh@verizon.com
Tarek Saad Cisco Systems 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada
加拿大安大略省卡纳塔市塔瑞克萨阿德思科系统2000创新大道K2K 3E8
Email: tsaad.net@gmail.com
Email: tsaad.net@gmail.com