Network Working Group P. Pan, Ed.
Request for Comments: 4090 Hammerhead Systems
Category: Standards Track G. Swallow, Ed.
Cisco Systems
A. Atlas, Ed.
Avici Systems
May 2005
Network Working Group P. Pan, Ed.
Request for Comments: 4090 Hammerhead Systems
Category: Standards Track G. Swallow, Ed.
Cisco Systems
A. Atlas, Ed.
Avici Systems
May 2005
Fast Reroute Extensions to RSVP-TE for LSP Tunnels
LSP隧道RSVP-TE的快速重路由扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure.
本文档定义了RSVP-TE扩展，以建立备份标签交换路径（LSP）隧道，用于本地修复LSP隧道。这些机制可以在发生故障时在10毫秒内将流量重新定向到备份LSP通道。
Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network.
这里定义了两种方法。一对一备份方法在每个可能的本地修复点为每个受保护的LSP创建迂回LSP。设施备份方法创建旁通隧道，以保护潜在故障点；通过利用MPLS标签堆叠，此旁路隧道可以保护具有类似备份约束的一组LSP。这两种方法都可用于在网络故障期间保护链路和节点。所描述的RSVP行为和扩展允许节点实现其中一种方法或两种方法，并在混合网络中进行互操作。
Table of Contents
目录
1. Introduction ...................................................3
1.1. Background ...............................................4
2. Terminology ....................................................4
3. Local Repair Techniques ........................................6
3.1. One-to-One Backup ........................................6
3.2. Facility Backup ..........................................7
4. RSVP Extensions ................................................8
4.1. FAST_REROUTE Object ......................................8
4.2. DETOUR Object ...........................................11
4.2.1. DETOUR Object for IPv4 Address ...................11
4.2.2. DETOUR Object for IPv6 Address ...................12
4.3. SESSION_ATTRIBUTE Flags .................................13
4.4. RRO IPv4/IPv6 Sub-object Flags ..........................14
5. Head-End Behavior .............................................15
6. Point of Local Repair (PLR) Behavior ..........................16
6.1. Signaling a Backup Path .................................17
6.1.1. Backup Path Identification: Sender
Template-Specific ................................19
6.1.2. Backup Path Identification: Path-Specific ........19
6.2. Procedures for Backup Path Computation ..................20
6.3. Signaling Backups for One-to-One Protection .............21
6.3.1. Make-before-Break with Detour LSPs ...............22
6.3.2. Message Handling .................................23
6.3.3. Local Reroute of Traffic onto Detour LSP .........23
6.4. Signaling for Facility Protection .......................24
6.4.1. Discovering Downstream Labels ....................24
6.4.2. Procedures for the PLR before Local Repair .......24
6.4.3. Procedures for the PLR during Local Repair .......25
6.4.4. Processing Backup Tunnel's ERO ...................26
6.5. PLR Procedures during Local Repair ......................26
6.5.1. Notification of Local Repair .....................26
6.5.2. Revertive Behavior ...............................27
7. Merge Node Behavior ...........................................28
7.1. Handling Backup Path Messages before Failure ............28
7.1.1. Merging Backup Paths using the Sender
Template-Specific Method .........................29
7.1.2. Merging Detours using the Path-Specific Method ...29
7.1.3. Message Handling for Merged Detours ..............31
7.2. Handling Failures .......................................31
8. Behavior of All LSRs ..........................................32
8.1. Merging Detours in the Path-Specific Method .............32
9. Security Considerations .......................................33
10. IANA Considerations ...........................................33
11. Contributors ..................................................35
12. Acknowledgments ...............................................36
13. Normative References ..........................................36
1. Introduction ...................................................3
1.1. Background ...............................................4
2. Terminology ....................................................4
3. Local Repair Techniques ........................................6
3.1. One-to-One Backup ........................................6
3.2. Facility Backup ..........................................7
4. RSVP Extensions ................................................8
4.1. FAST_REROUTE Object ......................................8
4.2. DETOUR Object ...........................................11
4.2.1. DETOUR Object for IPv4 Address ...................11
4.2.2. DETOUR Object for IPv6 Address ...................12
4.3. SESSION_ATTRIBUTE Flags .................................13
4.4. RRO IPv4/IPv6 Sub-object Flags ..........................14
5. Head-End Behavior .............................................15
6. Point of Local Repair (PLR) Behavior ..........................16
6.1. Signaling a Backup Path .................................17
6.1.1. Backup Path Identification: Sender
Template-Specific ................................19
6.1.2. Backup Path Identification: Path-Specific ........19
6.2. Procedures for Backup Path Computation ..................20
6.3. Signaling Backups for One-to-One Protection .............21
6.3.1. Make-before-Break with Detour LSPs ...............22
6.3.2. Message Handling .................................23
6.3.3. Local Reroute of Traffic onto Detour LSP .........23
6.4. Signaling for Facility Protection .......................24
6.4.1. Discovering Downstream Labels ....................24
6.4.2. Procedures for the PLR before Local Repair .......24
6.4.3. Procedures for the PLR during Local Repair .......25
6.4.4. Processing Backup Tunnel's ERO ...................26
6.5. PLR Procedures during Local Repair ......................26
6.5.1. Notification of Local Repair .....................26
6.5.2. Revertive Behavior ...............................27
7. Merge Node Behavior ...........................................28
7.1. Handling Backup Path Messages before Failure ............28
7.1.1. Merging Backup Paths using the Sender
Template-Specific Method .........................29
7.1.2. Merging Detours using the Path-Specific Method ...29
7.1.3. Message Handling for Merged Detours ..............31
7.2. Handling Failures .......................................31
8. Behavior of All LSRs ..........................................32
8.1. Merging Detours in the Path-Specific Method .............32
9. Security Considerations .......................................33
10. IANA Considerations ...........................................33
11. Contributors ..................................................35
12. Acknowledgments ...............................................36
13. Normative References ..........................................36
This document extends RSVP [RSVP] to establish backup label-switched path (LSP) tunnels for the local repair of LSP tunnels. This extension will meet the needs of real-time applications such as voice over IP, for which user traffic should be redirected onto backup LSP tunnels in 10s of milliseconds. This timing requirement can be satisfied by computing and signaling backup LSP tunnels in advance of failure and by re-directing traffic as close to the failure point as possible. In this way, the time for redirection includes no path computation and no signaling delays, including delays to propagate failure notification between label-switched routers (LSRs). Speed of repair is the primary advantage of the methods and extensions described here. The term local repair is used when referring to techniques that re-direct traffic to a backup LSP tunnel in response to a local failure.
本文档扩展了RSVP[RSVP]以建立备份标签交换路径（LSP）隧道，用于本地修复LSP隧道。此扩展将满足实时应用程序（如IP语音）的需要，对于这些应用程序，用户流量应在10毫秒内重定向到备份LSP隧道。通过在故障之前计算备用LSP隧道并发送信号，以及通过尽可能在故障点附近重新定向流量，可以满足此定时要求。这样，重定向的时间不包括路径计算和信令延迟，包括在标签交换路由器（lsr）之间传播故障通知的延迟。修复速度是本文介绍的方法和扩展的主要优点。术语“本地修复”是指响应本地故障将通信量重新定向到备用LSP隧道的技术。
A protected LSP is an explicitly-routed LSP that is provided with protection. The repair methods described here are applicable only to explicitly-routed LSPs. Application of these methods to LSPs that dynamically change their routes, such as LSPs used in unicast IGP routing, is beyond the scope of this document.
受保护的LSP是提供保护的显式路由LSP。此处描述的修复方法仅适用于显式路由LSP。将这些方法应用于动态更改其路由的LSP，例如单播IGP路由中使用的LSP，超出了本文档的范围。
Section 2 covers new terminology used in this document. Section 3 describes two basic methods for creating backup LSPs. Section 4 describes the RSVP protocol extensions to support local protection. Section 5 presents the behavior of an LSR that seeks to request local protection for an LSP. The behavior of a potential point of local repair (PLR) is given in Section 6, which describes how to determine the appropriate strategy for protecting an LSP and how to implement each of the strategies. Section 7 describes the behavior of a merge node, the LSR where a protected LSP and its backup LSP rejoin. Finally, Section 8 discusses the required behavior of other nodes in the network.
第2节介绍了本文件中使用的新术语。第3节介绍了创建备份LSP的两种基本方法。第4节描述了支持本地保护的RSVP协议扩展。第5节介绍了寻求为LSP请求本地保护的LSR的行为。第6节给出了潜在局部修复点（PLR）的行为，描述了如何确定保护LSP的适当策略以及如何实施每种策略。第7节描述了合并节点的行为，即受保护LSP及其备份LSP重新加入的LSR。最后，第8节讨论了网络中其他节点所需的行为。
The methods discussed in this document depend upon three assumptions:
本文件中讨论的方法取决于三个假设：
o An LSR that is on the path of a protected LSP should always assume that it is a merge point. This is necessary because the facility backup method does not signal backups through a bypass tunnel before failure.
o 位于受保护LSP路径上的LSR应始终假定它是合并点。这是必要的，因为设施备份方法不会在故障前通过旁路隧道发出备份信号。
o If the one-to-one backup method is used and a DETOUR object is included, the LSRs in the traffic-engineered network should support the DETOUR object. This is necessary so that the Path message containing the DETOUR object is not rejected.
o 如果使用一对一备份方法并包含迂回对象，则交通工程网络中的LSR应支持迂回对象。这是必要的，以便包含迂回对象的路径消息不会被拒绝。
o Understanding the DETOUR object is required to support the path-specific method, which requires that LSRs in the traffic-engineered network be capable of merging detours.
o 理解绕行目标需要支持路径特定方法，这要求交通工程网络中的LSR能够合并绕行。
Several years before work began on this document, operational networks had deployed two independent methods of doing fast reroute; these methods are called here one-to-one backup and facility backup. Vendors trying to support both methods experienced compatibility problems in attempting to produce a single implementation capable of interoperating with both methods. There are technical tradeoffs between the methods. These tradeoffs are so topologically dependent that the community has not converged on a single approach.
在本文件开始工作的几年前，作战网络部署了两种独立的快速重路由方法；这些方法在这里称为一对一备份和设备备份。尝试支持这两种方法的供应商在尝试生成能够与这两种方法互操作的单个实现时遇到兼容性问题。两种方法之间存在技术上的权衡。这些权衡在拓扑上是如此的依赖，以至于社区并没有集中在一个单一的方法上。
This document rationalizes the RSVP signaling for both methods so that any implementation can recognize all fast reroute requests and clearly respond. The response may be positive if the method can be performed, or it may be a clear error to inform the requester to seek alternate backup means. This document also allows a single implementation to support both methods, thereby providing a range of capabilities. The described behavior and extensions to RSVP allow LERs and LSRs to implement either method or both.
本文档对这两种方法的RSVP信令进行了合理化，以便任何实现都可以识别所有快速重路由请求并明确响应。如果可以执行该方法，则响应可能是肯定的，或者通知请求者寻求备用方法可能是明显的错误。本文档还允许单个实现支持这两种方法，从而提供了一系列功能。所描述的RSVP行为和扩展允许LER和LSR实现其中一种方法或同时实现这两种方法。
While the two methods could in principle be used in a single network, it is expected that operators will continue to deploy either one or the other. The goal of this document is to standardize the RSVP signaling so that a network composed of LSRs that implement both methods or a network composed of some LSRs that support one method and others that support both can properly signal among those LSRs to achieve fast restoration.
虽然这两种方法原则上可以在单个网络中使用，但预计运营商将继续部署其中一种。本文档的目标是使RSVP信令标准化，以便由实现两种方法的LSR组成的网络或由支持一种方法的一些LSR和同时支持两种方法的其他LSR组成的网络可以在这些LSR之间正确地发送信号，以实现快速恢复。
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 [RFC-WORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC2119【RFC-WORKS】中的说明进行解释。
The reader is assumed to be familiar with the terminology in [RSVP] and [RSVP-TE].
假定读者熟悉[RSVP]和[RSVP-TE]中的术语。
LSR: Label-Switch Router.
标签交换路由器。
LSP: An MPLS Label-Switched Path. In this document, an LSP will always be explicitly routed.
LSP：MPLS标签交换路径。在本文档中，LSP将始终显式路由。
Local Repair: Techniques used to repair LSP tunnels quickly when a node or link along the LSP's path fails.
局部修复：用于在LSP路径上的节点或链路出现故障时快速修复LSP隧道的技术。
PLR: Point of Local Repair. The head-end LSR of a backup tunnel or a detour LSP.
PLR：局部维修点。备用隧道或迂回LSP的前端LSR。
One-to-One Backup: A local repair method in which a backup LSP is separately created for each protected LSP at a PLR.
一对一备份：一种本地修复方法，其中在PLR处为每个受保护的LSP分别创建一个备份LSP。
Facility Backup: A local repair method in which a bypass tunnel is used to protect one or more protected LSPs that traverse the PLR, the resource being protected, and the Merge Point in that order.
设施备份：一种本地修复方法，其中使用旁路隧道来保护一个或多个受保护的LSP，这些LSP依次穿过PLR、受保护的资源和合并点。
Protected LSP: An LSP is said to be protected at a given hop if it has one or multiple associated backup tunnels originating at that hop.
受保护的LSP：如果LSP具有一个或多个源自该跃点的关联备份隧道，则称其在给定跃点受到保护。
Detour LSP: The LSP that is used to re-route traffic around a failure in one-to-one backup.
迂回LSP：用于在一对一备份中围绕故障重新路由流量的LSP。
Bypass Tunnel: An LSP that is used to protect a set of LSPs passing over a common facility.
旁通隧道：用于保护通过公共设施的一组LSP的LSP。
Backup Tunnel: The LSP that is used to backup up one of the many LSPs in many-to-one backup.
备份隧道：用于备份多对一备份中多个LSP之一的LSP。
NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A backup tunnel that bypasses a single link of the protected LSP.
NHOP旁路隧道：下一跳旁路隧道。绕过受保护LSP的单个链路的备份隧道。
NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel that bypasses a single node of the protected LSP.
NNHOP旁路隧道：下一跳旁路隧道。绕过受保护LSP的单个节点的备份隧道。
Backup Path: The LSP that is responsible for backing up one protected LSP. A backup path refers to either a detour LSP or a backup tunnel.
备份路径：负责备份一个受保护LSP的LSP。备份路径是指迂回LSP或备份隧道。
MP: Merge Point. The LSR where one or more backup tunnels rejoin the path of the protected LSP downstream of the potential failure. The same LSR may be both an MP and a PLR simultaneously.
MP：合并点。LSR，其中一个或多个备用隧道重新连接潜在故障下游受保护LSP的路径。相同的LSR可以同时是MP和PLR。
DMP: Detour Merge Point. In the case of one-to-one backup, this is an LSR where multiple detours converge. Only one detour is signaled beyond that LSR.
DMP：迂回合并点。在一对一备份的情况下，这是一个LSR，其中多条弯路会聚在一起。只有一条绕道在该LSR之外发出信号。
Reroutable LSP: Any LSP for which the head-end LSR requests local protection. See Section 5 for more detail.
可重新运行LSP：前端LSR请求本地保护的任何LSP。详见第5节。
CSPF: Constraint-based Shortest Path First.
CSPF：基于约束的最短路径优先。
SRLG Disjoint: A path is considered to be SRLG disjoint from a given link or node if the path does not use any links or nodes which belong to the same SRLG as that given link or node.
SRLG不相交：如果路径不使用与给定链接或节点属于同一SRLG的任何链接或节点，则认为该路径与给定链接或节点不相交。
Two different methods for local protection are described. In the one-to-one backup method, a PLR computes a separate backup LSP, called a detour LSP, for each LSP that the PLR protects. In the facility backup method, the PLR creates a single bypass tunnel that can be used to protect multiple LSPs.
描述了两种不同的局部保护方法。在一对一备份方法中，PLR为PLR保护的每个LSP计算单独的备份LSP，称为迂回LSP。在设施备份方法中，PLR创建一个可用于保护多个LSP的旁通隧道。
In the one-to-one backup method, a label-switched path is established that intersects the original LSP somewhere downstream of the point of link or node failure. A separate backup LSP is established for each LSP that is backed up.
在一对一备份方法中，建立了一条标签交换路径，该路径在链路或节点故障点下游某个位置与原始LSP相交。为备份的每个LSP建立单独的备份LSP。
[R1]----[R2]----[R3]------[R4]------[R5]
\ \ \ / \ /
[R6]----[R7]----[R8]------[R9]
[R1]----[R2]----[R3]------[R4]------[R5]
\ \ \ / \ /
[R6]----[R7]----[R8]------[R9]
Protected LSP: [R1->R2->R3->R4->R5]
R1's Backup: [R1->R6->R7->R8->R3]
R2's Backup: [R2->R7->R8->R4]
R3's Backup: [R3->R8->R9->R5]
R4's Backup: [R4->R9->R5]
Protected LSP: [R1->R2->R3->R4->R5]
R1's Backup: [R1->R6->R7->R8->R3]
R2's Backup: [R2->R7->R8->R4]
R3's Backup: [R3->R8->R9->R5]
R4's Backup: [R4->R9->R5]
Example 1. One-to-One Backup Technique
例1。一对一备份技术
In the simple topology shown in Example 1, the protected LSP runs from R1 to R5. R2 can provide user traffic protection by creating a partial backup LSP that merges with the protected LSP at R4. We refer to a partial one-to-one backup LSP [R2->R7->R8->R4] as a detour.
在示例1所示的简单拓扑中，受保护的LSP从R1运行到R5。R2可以通过创建与R4受保护LSP合并的部分备份LSP来提供用户流量保护。我们将部分一对一备份LSP[R2->R7->R8->R4]称为绕道。
To protect an LSP that traverses N nodes fully, there could be as many as (N - 1) detours. Example 1 shows the paths for the detours necessary to protect fully the LSP in the example. To minimize the number of LSPs in the network, it is desirable to merge a detour back to its protected LSP, when feasible. When a detour LSP intersects its protected LSP at an LSR with the same outgoing interface, it will be merged.
为了保护一个完全穿越N个节点的LSP，可以有多达（N-1）条绕道。示例1显示了示例中完全保护LSP所需的绕行路径。为了尽量减少网络中的LSP数量，在可行的情况下，最好将迂回路线合并回其受保护的LSP。当迂回LSP在具有相同输出接口的LSR处与其受保护LSP相交时，它将合并。
When a failure occurs along the protected LSP, the PLR redirects traffic onto the local detour. For instance, if the link [R2->R3] fails in Example 1, R2 will switch traffic received from R1 onto the protected LSP along link [R2->R7], using the label received when R2 created the detour. When R4 receives traffic with the label provided for R2's detour, R4 will switch that traffic onto link [R4-R5], using the label received from R5 for the protected LSP. At no point does the depth of the label stack increase as a result of the detour. While R2 is using its detour, traffic will take the path [R1->R2->R7->R8->R4->R5].
当沿着受保护的LSP发生故障时，PLR将流量重定向到本地绕道。例如，如果在示例1中链接[R2->R3]失败，R2将使用R2创建迂回路线时收到的标签，沿链接[R2->R7]将从R1接收的流量切换到受保护的LSP。当R4接收到带有为R2绕行提供的标签的流量时，R4将使用从R5接收到的用于受保护LSP的标签将该流量切换到链路[R4-R5]。在任何情况下，绕行都不会增加标签堆栈的深度。R2使用其迂回路线时，流量将采用路径[R1->R2->R7->R8->R4->R5]。
The facility backup method takes advantage of the MPLS label stack. Instead of creating a separate LSP for every backed-up LSP, a single LSP is created that serves to back up a set of LSPs. We call such an LSP tunnel a bypass tunnel.
设施备份方法利用MPLS标签堆栈。不再为每个备份的LSP创建单独的LSP，而是创建一个用于备份一组LSP的LSP。我们称这种LSP隧道为旁路隧道。
The bypass tunnel must intersect the path of the original LSP(s) somewhere downstream of the PLR. Naturally, this constrains the set of LSPs being backed up via that bypass tunnel to those that pass through some common downstream node. All LSPs that pass through the point of local repair and through this common node that do not also use the facilities involved in the bypass tunnel are candidates for this set of LSPs.
旁通隧道必须在PLR下游某处与原始LSP的路径相交。自然，这将通过该旁路隧道备份的LSP集限制为通过某个公共下游节点的LSP集。所有通过本地维修点和该公共节点（不使用旁通隧道中涉及的设施）的LSP都是这组LSP的候选。
[R8]
\
[R1]---[R2]----[R3]-----[R4]---[R5]
\ / \
[R6]===[R7] [R9]
[R8]
\
[R1]---[R2]----[R3]-----[R4]---[R5]
\ / \
[R6]===[R7] [R9]
Protected LSP 1: [R1->R2->R3->R4->R5]
Protected LSP 2: [R8->R2->R3->R4]
Protected LSP 3: [R2->R3->R4->R9]
Bypass LSP Tunnel: [R2->R6->R7->R4]
Protected LSP 1: [R1->R2->R3->R4->R5]
Protected LSP 2: [R8->R2->R3->R4]
Protected LSP 3: [R2->R3->R4->R9]
Bypass LSP Tunnel: [R2->R6->R7->R4]
Example 2. Facility Backup Technique
例2。设施备份技术
In Example 2, R2 has built a bypass tunnel that protects against the failure of link [R2->R3] and node [R3]. The doubled lines represent this tunnel. This technique provides a scalability improvement, in that the same bypass tunnel can also be used to protect LSPs from any of R1, R2, or R8 to any of R4, R5, or R9. Example 2 describes three different protected LSPs that are using the same bypass tunnel for protection.
在示例2中，R2构建了一个旁路隧道，用于防止链路[R2->R3]和节点[R3]发生故障。双线代表这条隧道。此技术提供了可伸缩性改进，因为相同的旁路隧道也可用于保护从R1、R2或R8到R4、R5或R9的LSP。示例2描述了三个不同的受保护LSP，它们使用相同的旁通隧道进行保护。
As with the one-to-one method, there could be as many as (N-1) bypass tunnels to fully protect an LSP that traverses N nodes. However, each of those bypass tunnels could protect a set of LSPs.
与一对一方法一样，可以有多达（N-1）个旁路隧道来完全保护穿越N个节点的LSP。然而，每个旁通隧道都可以保护一组LSP。
When a failure occurs along a protected LSP, the PLR redirects traffic into the appropriate bypass tunnel. For instance, if link [R2->R3] fails in Example 2, R2 will switch traffic received from R1 on the protected LSP onto link [R2->R6]. The label will be switched for one which will be understood by R4 to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto the label-stack of the redirected packets. If penultimate-hop-popping is used, the merge point in Example 2, R4, will receive the redirected packet with a label indicating the protected LSP that the packet is to follow. If penultimate-hop-popping is not used, R4 will pop the bypass tunnel's label and examine the label underneath to determine the protected LSP that the packet is to follow. When R2 is using the bypass tunnel for protected LSP 1, the traffic takes the path [R1->R2->R6->R7->R4->R5]; the bypass tunnel is the connection between R2 and R4.
当沿着受保护的LSP发生故障时，PLR将流量重定向到相应的旁通隧道。例如，如果在示例2中链接[R2->R3]失败，R2将把从受保护LSP上的R1接收的流量切换到链接[R2->R6]。标签将被切换为R4可以理解的标签，以指示受保护的LSP，然后旁路隧道的标签将被推送到重定向数据包的标签堆栈上。如果使用倒数第二跳弹出，则示例2中的合并点R4将接收重定向的数据包，该数据包带有一个标签，指示该数据包将遵循的受保护LSP。如果未使用倒数第二跳弹出，R4将弹出旁路隧道的标签，并检查下面的标签，以确定数据包将遵循的受保护LSP。当R2为受保护的LSP 1使用旁路隧道时，通信量采用路径[R1->R2->R6->R7->R4->R5]；旁通隧道是R2和R4之间的连接。
This specification defines two additional objects, FAST_REROUTE and DETOUR, to extend RSVP-TE for fast-reroute signaling. These new objects are backward compatible with LSRs that do not recognize them (see section 3.10 in [RSVP]). Both objects can only be carried in RSVP Path messages.
本规范定义了另外两个对象，FAST_REROUTE和DETOUR，用于扩展RSVP-TE以实现快速重路由信令。这些新对象与无法识别它们的LSR向后兼容（见[RSVP]第3.10节）。这两个对象只能在RSVP路径消息中携带。
The SESSION_ATTRIBUTE and RECORD_ROUTE objects are also extended to support bandwidth and node protection features.
SESSION_属性和RECORD_ROUTE对象也进行了扩展，以支持带宽和节点保护功能。
The FAST_REROUTE object is used to control the backup used for the protected LSP. This specifies the setup and hold priorities, session attribute filters, and bandwidth to be used for protection. It also allows a specific local protection method to be requested. This object MUST only be inserted into the PATH message by the head-end LER and MUST NOT be changed by downstream LSRs. The FAST_REROUTE object has the following format:
FAST_REROUTE对象用于控制用于受保护LSP的备份。这将指定用于保护的设置和保持优先级、会话属性筛选器和带宽。它还允许请求特定的本地保护方法。此对象只能由前端LER插入PATH消息，且不能由下游LSR更改。FAST_REROUTE对象具有以下格式：
Class-Num = 205 C-Type = 1
类别编号=205 C型=1
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Setup Prio | Hold Prio | Hop-limit | Flags |
+-------------+-------------+-------------+-------------+
| Bandwidth |
+-------------+-------------+-------------+-------------+
| Include-any |
+-------------+-------------+-------------+-------------+
| Exclude-any |
+-------------+-------------+-------------+-------------+
| Include-all |
+-------------+-------------+-------------+-------------+
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Setup Prio | Hold Prio | Hop-limit | Flags |
+-------------+-------------+-------------+-------------+
| Bandwidth |
+-------------+-------------+-------------+-------------+
| Include-any |
+-------------+-------------+-------------+-------------+
| Exclude-any |
+-------------+-------------+-------------+-------------+
| Include-all |
+-------------+-------------+-------------+-------------+
Setup Priority
设置优先级
The priority of the backup path with respect to taking resources, in the range 0 to 7. The value 0 is the highest priority. Setup Priority is used in deciding whether this session can preempt another session. See [RSVP-TE] for the usage on priority.
备份路径相对于获取资源的优先级，范围为0到7。值0是最高优先级。设置优先级用于决定此会话是否可以抢占另一个会话。有关优先级的用法，请参见[RSVP-TE]。
Holding Priority
持有优先权
The priority of the backup path with respect to holding resources, in the range 0 to 7. The value 0 is the highest priority. Holding Priority is used in deciding whether this session can be preempted by another session. See [RSVP-TE] for the usage on priority.
备份路径相对于保留资源的优先级，范围为0到7。值0是最高优先级。保持优先级用于决定此会话是否可以被另一个会话抢占。有关优先级的用法，请参见[RSVP-TE]。
Hop-limit
跳数限制
The maximum number of extra hops the backup path is allowed to take, from current node (a PLR) to an MP, with PLR and MP excluded from the count. For example, hop-limit of 0 means that only direct links between PLR and MP can be considered.
备份路径允许从当前节点（PLR）到MP的最大额外跃点数，PLR和MP不包括在计数中。例如，跳数限制为0意味着只能考虑PLR和MP之间的直接链路。
Flags
旗帜
0x01 One-to-One Backup Desired
0x01需要一对一备份
Requests protection via the one-to-one backup method.
通过一对一备份方法请求保护。
0x02 Facility Backup Desired
需要0x02设备备份
Requests protection via the facility backup method.
通过设备备份方法请求保护。
Bandwidth
带宽
Bandwidth estimate; 32-bit IEEE floating point integer, in bytes per second.
带宽估计；32位IEEE浮点整数，以字节/秒为单位。
Exclude-any
排除任何
A 32-bit vector representing a set of attribute filters associated with a backup path, any of which renders a link unacceptable.
表示与备份路径关联的一组属性筛选器的32位向量，其中任何一个都会导致链接不可接受。
Include-any
包括任何
A 32-bit vector representing a set of attribute filters associated with a backup path, any of which renders a link acceptable (with respect to this test). A null set (all bits set to zero) automatically passes.
一个32位向量，表示一组与备份路径关联的属性过滤器，其中任何一个都会使链接可接受（关于此测试）。空集（所有位均设置为零）自动传递。
Include-all
包括所有
A 32-bit vector representing a set of attribute filters associated with a backup path, all of which must be present for a link to be acceptable (with respect to this test). A null set (all bits set to zero) automatically passes.
一个32位向量，表示一组与备份路径关联的属性过滤器，所有这些过滤器都必须存在，链接才能被接受（关于此测试）。空集（所有位均设置为零）自动传递。
The two high-order bits of the Class-Num (11) cause nodes that do not understand the object to ignore it and pass it forward unchanged.
类Num（11）的两个高阶位导致不理解对象的节点忽略该对象，并将其原封不动地向前传递。
For informational purposes, a different C-Type value and format for the FAST_REROUTE object are specified below. This is used by legacy implementations. The meaning of the fields is the same as that described for C-Type 1.
为了便于参考，下面为FAST_REROUTE对象指定了不同的C类型值和格式。这是由遗留实现使用的。字段的含义与C-Type 1所述的含义相同。
Class-Num = 205 C-Type = 7
类别编号=205 C型=7
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Setup Prio | Hold Prio | Hop-limit | Reserved |
+-------------+-------------+-------------+-------------+
| Bandwidth |
+-------------+-------------+-------------+-------------+
| Include-any |
+-------------+-------------+-------------+-------------+
| Exclude-any |
+-------------+-------------+-------------+-------------+
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Setup Prio | Hold Prio | Hop-limit | Reserved |
+-------------+-------------+-------------+-------------+
| Bandwidth |
+-------------+-------------+-------------+-------------+
| Include-any |
+-------------+-------------+-------------+-------------+
| Exclude-any |
+-------------+-------------+-------------+-------------+
Unknown C-Types should be treated as specified in [RSVP] Section 3.10.
未知C型应按照[RSVP]第3.10节的规定进行处理。
The DETOUR object is used in the one-to-one backup method to identify detour LSPs.
DETOUR对象在一对一备份方法中用于标识DETOUR LSP。
Class-Num = 63 C-Type = 7
类别编号=63 C类型=7
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 |
+-------------+-------------+-------------+-------------+
// .... //
+-------------+-------------+-------------+-------------+
| PLR_ID n |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID n |
+-------------+-------------+-------------+-------------+
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 |
+-------------+-------------+-------------+-------------+
// .... //
+-------------+-------------+-------------+-------------+
| PLR_ID n |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID n |
+-------------+-------------+-------------+-------------+
PLR_ID (1 - n)
PLR_ID（1-n）
IPv4 address identifying the PLR that is the beginning point of the detour. Any local address on the PLR can be used.
IPv4地址，标识作为迂回起点的PLR。可以使用PLR上的任何本地地址。
Avoid_Node_ID (1 - n)
避免节点ID（1-n）
IPv4 address identifying the immediate downstream node that the PLR is trying to avoid. Any local address of the downstream node can be used. This field is mandatory and is used by the MP for the merging rules discussed below.
IPv4地址，标识PLR试图避免的直接下游节点。可以使用下游节点的任何本地地址。此字段是必填字段，MP用于下面讨论的合并规则。
Class-Num = 63 C-Type = 8
类别编号=63 C类型=8
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
// .... //
+-------------+-------------+-------------+-------------+
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
// .... //
+-------------+-------------+-------------+-------------+
PLR_ID (1 - n)
PLR_ID（1-n）
An IPv6 128-bit unicast host address identifying the PLR that is the beginning point of the detour. Any local address on the PLR can be used.
IPv6 128位单播主机地址，标识作为迂回起点的PLR。可以使用PLR上的任何本地地址。
Avoid_Node_ID (1 - n)
避免节点ID（1-n）
An IPv6 128-bit unicast host address identifying the immediate downstream node that the PLR is trying to avoid. Any local address on the downstream node can be used. This field is
IPv6 128位单播主机地址，标识PLR试图避免的直接下游节点。可以使用下游节点上的任何本地地址。这个领域是
mandatory and is used by the MP for the merging rules discussed below.
强制性，由MP用于下面讨论的合并规则。
There can be more than one pair of (PLR_ID, Avoid_Node_ID) entries in a DETOUR object. If detour merging is desired, after each merging operation, the Detour Merge Point should combine all the merged detours in subsequent Path messages.
一个迂回对象中可以有多对（PLR\u ID、回避\u节点\u ID）条目。如果需要迂回合并，则在每次合并操作后，迂回合并点应在后续路径消息中合并所有合并的迂回。
The high-order bit of the Class-Num is zero; LSRs that do not support the DETOUR objects MUST reject any Path message containing a DETOUR object and send a PathErr to notify the PLR. This PathErr SHOULD be generated as specified in [RSVP] for unknown objects with a Class-Num of the form "0bbbbbbb".
Num类的高阶位为零；不支持迂回对象的LSR必须拒绝包含迂回对象的任何路径消息，并发送PathErr通知PLR。对于类号为“0bbb”的未知对象，应按照[RSVP]中的指定生成此PathErr。
Unknown C-Types should be treated as specified in [RSVP] Section 3.10.
未知C型应按照[RSVP]第3.10节的规定进行处理。
To request bandwidth and node protection explicitly, two new flags are defined in the SESSION_ATTRIBUTE object.
为了明确请求带宽和节点保护，在会话_属性对象中定义了两个新标志。
For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has the following flags defined [RSVP-TE]:
对于C-Type 1和7，会话_属性对象当前定义了以下标志[RSVP-TE]：
Local protection desired: 0x01
需要本地保护：0x01
This flag permits transit routers to use a local repair mechanism that may result in violation of the explicit route object. When a fault is detected on an adjacent downstream link or node, a transit node may reroute traffic for fast service restoration.
此标志允许传输路由器使用可能导致违反显式路由对象的本地修复机制。当在相邻的下游链路或节点上检测到故障时，传输节点可以重新路由业务以快速恢复服务。
Label recording desired: 0x02
需要标签记录：0x02
This flag indicates that label information should be included when doing a route record.
此标志表示在进行路线记录时应包括标签信息。
SE Style desired: 0x04
所需SE样式：0x04
This flag indicates that the tunnel ingress node may choose to reroute this tunnel without tearing it down. A tunnel egress node SHOULD use the SE Style when responding with a Resv message. When requesting fast reroute, the head-end LSR SHOULD set this flag; this is not necessary for the path-specific method of the one-to-one backup method.
此标志表示隧道入口节点可以选择重新路由此隧道，而无需将其拆除。隧道出口节点在响应Resv消息时应使用SE样式。当请求快速重路由时，前端LSR应设置此标志；对于一对一备份方法的特定路径方法，这不是必需的。
The following new flags are defined:
定义了以下新标志：
Bandwidth protection desired: 0x08
需要的带宽保护：0x08
This flag indicates to the PLRs along the protected LSP path that a backup path with a bandwidth guarantee is desired. The bandwidth to be guaranteed is that of the protected LSP, if no FAST_REROUTE object is included in the PATH message; if a FAST_REROUTE object is in the PATH message, then the bandwidth specified therein is to be guaranteed.
该标志向沿受保护LSP路径的PLR指示需要具有带宽保证的备份路径。如果路径消息中不包括快速重新路由对象，则要保证的带宽是受保护LSP的带宽；如果路径消息中存在快速重新路由对象，则需要保证其中指定的带宽。
Node protection desired: 0x10
需要节点保护：0x10
This flag indicates to the PLRs along a protected LSP path that a backup path that bypasses at least the next node of the protected LSP is desired.
该标志向沿受保护LSP路径的PLR指示需要至少绕过受保护LSP的下一个节点的备份路径。
To report whether bandwidth and/or node protection are provided as requested, we define two new flags in the RRO IPv4 sub-object.
为了报告是否按照请求提供了带宽和/或节点保护，我们在RRO IPv4子对象中定义了两个新标志。
The RRO IPv4 and IPv6 address sub-objects currently have the following flags defined [RSVP-TE]:
RRO IPv4和IPv6地址子对象当前定义了以下标志[RSVP-TE]：
Local protection available: 0x01
可用的本地保护：0x01
Indicates that the link downstream of this node is protected via a local repair mechanism, which can be either one-to-one or facility backup.
指示此节点下游的链路通过本地修复机制受到保护，该机制可以是一对一或设施备份。
Local protection in use: 0x02
正在使用的本地保护：0x02
Indicates that a local repair mechanism is in use to maintain this tunnel (usually in the face of an outage of the link it was previously routed over, or an outage of the neighboring node).
指示正在使用本地修复机制来维护此隧道（通常在其先前路由的链路中断或相邻节点中断时）。
Two new flags are defined:
定义了两个新标志：
Bandwidth protection: 0x04
带宽保护：0x04
The PLR will set this bit when the protected LSP has a backup path that is guaranteed to provide the desired bandwidth that is specified in the FAST_REROUTE object or the bandwidth of the protected LSP, if no FAST_REROUTE object was included. The PLR may set this whenever the desired bandwidth is guaranteed; the PLR MUST set this flag when the desired bandwidth is guaranteed
当受保护LSP有一个备份路径时，PLR将设置该位，该备份路径保证提供在FAST_REROUTE对象中指定的所需带宽或受保护LSP的带宽（如果不包括FAST_REROUTE对象）。PLR可在保证所需带宽时设置该值；当所需带宽得到保证时，PLR必须设置此标志
and the "bandwidth protection desired" flag was set in the SESSION_ATTRIBUTE object. If the requested bandwidth is not guaranteed, the PLR MUST NOT set this flag.
并且在会话_属性对象中设置了“所需带宽保护”标志。如果请求的带宽没有保证，PLR不得设置此标志。
Node protection: 0x08
节点保护：0x08
The PLR will set this bit when the protected LSP has a backup path that provides protection against a failure of the next LSR along the protected LSP. The PLR may set this whenever node protection is provided by the protected LSP's backup path; the PLR MUST set this flag when the node protection is provided and the "node protection desired" flag was set in the SESSION_ATTRIBUTE object. If node protection is not provided, the PLR MUST NOT set this flag. Thus, if a PLR could only set up a link-protection backup path, the "Local protection available" bit will be set, but the "Node protection" bit will be cleared.
当受保护的LSP有一个备份路径提供保护，防止受保护LSP上的下一个LSR出现故障时，PLR将设置该位。只要受保护的LSP的备份路径提供节点保护，PLR就可以设置该节点保护；当提供节点保护且在会话_属性对象中设置了“需要节点保护”标志时，PLR必须设置此标志。如果未提供节点保护，PLR不得设置此标志。因此，如果PLR只能设置链路保护备份路径，则将设置“本地保护可用”位，但“节点保护”位将被清除。
The head-end of an LSP determines whether local protection should be requested for that LSP and which local protection method is desired for the protected LSP. The head-end also determines what constraints should be requested for the backup paths of a protected LSP.
LSP的前端确定是否应为该LSP请求本地保护，以及受保护LSP需要哪种本地保护方法。前端还确定应为受保护LSP的备份路径请求哪些约束。
To indicate that an LSP should be locally protected, the head-end LSR MUST either set the "local protection desired" flag in the SESSION_ATTRIBUTE object or include a FAST_REROUTE object in the PATH message, or both. The "local protection desired" flag in the SESSION_ATTRIBUTE object SHOULD always be set. If a head-end LSR signals a FAST_REROUTE object, it MUST be stored for Path refreshes.
要指示LSP应受到本地保护，前端LSR必须在会话_属性对象中设置“需要本地保护”标志，或在路径消息中包含快速_重路由对象，或两者兼而有之。应始终设置会话_属性对象中的“需要本地保护”标志。如果前端LSR发出快速重新路由对象的信号，则必须将其存储以进行路径刷新。
The head-end LSR of a protected LSP MUST set the "label recording desired" flag in the SESSION_ATTRIBUTE object. This facilitates the use of the facility backup method. If node protection is desired, the head-end LSR should set the "node protection desired" flag in the SESSION_ATTRIBUTE object; otherwise, this flag should be cleared. Similarly, if a guarantee of bandwidth protection is desired, then the "bandwidth protection desired" flag in the SESSION_ATTRIBUTE object should be set; otherwise, this flag should be cleared. If the head-end LSR determines that control of the backup paths for the protected LSP is desired, then the LSR should include the FAST_REROUTE object. The PLRs will use the attribute filters, bandwidth, hop-limit, and priorities to determine the backup paths.
受保护LSP的前端LSR必须在SESSION_属性对象中设置“label recording desired”标志。这便于使用设施备份方法。如果需要节点保护，则前端LSR应在会话_属性对象中设置“需要节点保护”标志；否则，应清除此标志。类似地，如果需要带宽保护的保证，则应设置会话_属性对象中的“需要带宽保护”标志；否则，应清除此标志。如果前端LSR确定需要对受保护LSP的备份路径进行控制，则LSR应包括FAST_REROUTE对象。PLR将使用属性过滤器、带宽、跃点限制和优先级来确定备份路径。
If the head-end LSR desires that the one-to-one backup method be used for the protected LSP, then the head-end LSR should include a FAST_REROUTE object and set the "one-to-one backup desired" flag. If
如果前端LSR希望对受保护的LSP使用一对一备份方法，则前端LSR应包括快速重新路由对象，并设置“所需一对一备份”标志。如果
the head-end LSR desires that the protected LSP be protected via the facility backup method, then the head-end LSR should include a FAST_REROUTE object and set the "facility backup desired" flag. The lack of a FAST_REROUTE object, or having both these flags clear, should be treated by PLRs as a lack of preference. If both flags are set, a PLR may use either method or both.
前端LSR希望通过设备备份方法来保护受保护的LSP，那么前端LSR应该包括一个FAST_REROUTE对象，并设置“facility backup desired”标志。PLR应将缺少快速重新路由对象或清除这两个标志视为缺少首选项。如果设置了两个标志，PLR可以使用其中一种方法，也可以同时使用这两种方法。
The head-end LSR of a protected LSP MUST support the additional flags defined in Section 4.4 being set or clear in the RRO IPv4 and IPv6 sub-objects. The head-end LSR of a protected LSP MUST support the RRO Label sub-object.
受保护LSP的前端LSR必须支持在RRO IPv4和IPv6子对象中设置或清除第4.4节中定义的附加标志。受保护LSP的前端LSR必须支持RRO标签子对象。
If the head-end LSR of an LSP determines that local protection is newly desired, this SHOULD be signaled via make-before-break.
如果LSP的前端LSR确定新需要本地保护，则应通过先通后断发出信号。
Every LSR along a protected LSP (except the egress) MUST follow the PLR behavior described in this document.
受保护LSP沿线的每个LSR（出口除外）必须遵循本文档中描述的PLR行为。
A PLR SHOULD support the FAST_REROUTE object, the "local protection desired", "label recording desired", "node protection desired", and "bandwidth protection desired" flags in the SESSION_ATTRIBUTE object, and the "local protection available", "local protection in use", "bandwidth protection", and "node protection" flags in the RRO IPv4 and IPv6 sub-objects. A PLR MAY support the DETOUR object.
PLR应支持FAST_重路由对象、会话_属性对象中的“需要本地保护”、“需要标签记录”、“需要节点保护”和“需要带宽保护”标志，以及“可用本地保护”、“使用中的本地保护”、“带宽保护”和“节点保护”RRO IPv4和IPv6子对象中的标志。PLR可支持迂回目标。
A PLR MUST consider an LSP to have asked for local protection if the "local protection desired" flag is set in the SESSION_ATTRIBUTE object and/or the FAST_REROUTE object is included. If the FAST_REROUTE object is included, a PLR SHOULD consider providing one-to-one protection if the "one-to-one desired" is set, and it SHOULD consider providing facility backup if the "facility backup desired" flag is set. If the "node protection desired" flag is set, the PLR SHOULD try to provide node protection; if this is not feasible, the PLR SHOULD then try to provide link protection. If the "bandwidth protection guaranteed" flag is set, the PLR SHOULD try to provide a bandwidth guarantee; if this is not feasible, the PLR SHOULD then try to provide a backup without a guarantee of the full bandwidth.
如果在SESSIONTION属性对象中设置了“本地保护期望”标志和/或FASTHORE ReRouTE对象，PLR必须考虑LSP请求本地保护。如果包含FASTH-ReRouTE对象，PLR应该考虑设置“一对一期望”时的一对一保护，并且如果设置了“设备备份期望”标志，则应该考虑提供设备备份。如果设置了“需要节点保护”标志，PLR应尝试提供节点保护；如果这不可行，PLR应尝试提供链路保护。如果设置了“带宽保护保证”标志，则PLR应尝试提供带宽保证；如果这不可行，PLR应尝试在不保证全部带宽的情况下提供备份。
The following treatment for the RRO IPv4 or IPv6 sub-object's flags must be followed if an RRO is included in the protected LSP's RESV message. Based on this additional information, the head-end may take appropriate actions.
如果受保护LSP的RESV消息中包含RRO，则必须遵循以下对RRO IPv4或IPv6子对象标志的处理方法。根据此附加信息，前端可采取适当措施。
- Until a PLR has a backup path available, the PLR MUST clear the relevant four flags in the corresponding RRO IPv4 or IPv6 sub-object.
- 在PLR具有可用的备份路径之前，PLR必须清除相应RRO IPv4或IPv6子对象中的相关四个标志。
- Whenever the PLR has a backup path available, the PLR MUST set the "local protection available" flag. If no established one-to-one backup LSP or bypass tunnel exists, or if the one-to-one LSP and the bypass tunnel is in "DOWN" state, the PLR MUST clear the "local protection available" flag in its IPv4 (or IPv6) address sub-object of the RRO and SHOULD send the updated RESV.
- 只要PLR有可用的备份路径，PLR必须设置“本地保护可用”标志。如果不存在已建立的一对一备份LSP或旁路隧道，或者一对一LSP和旁路隧道处于“关闭”状态，则PLR必须清除RRO的IPv4（或IPv6）地址子对象中的“本地保护可用”标志，并应发送更新的RESV。
- The PLR MUST clear the "local protection in use" flag unless it is actively redirecting traffic into the backup path instead of along the protected LSP.
- PLR必须清除“本地保护正在使用”标志，除非它正在将流量主动重定向到备份路径，而不是沿着受保护的LSP。
- The PLR SHOULD also set the "node protection" flag if the backup path protects against the failure of the immediate downstream node, and, if the path does not, the PLR SHOULD clear the "node protection" flag. This MUST be done if the "node protection desired" flag was set in the SESSION_ATTRIBUTE object.
- 如果备份路径可防止直接下游节点发生故障，PLR还应设置“节点保护”标志，如果路径不起作用，PLR应清除“节点保护”标志。如果在会话_属性对象中设置了“需要节点保护”标志，则必须执行此操作。
- The PLR SHOULD set the "bandwidth protection" flag if the backup path offers a bandwidth guarantee, and, if the path does not, the PLR SHOULD clear the "bandwidth protection" flag. This MUST be done if the "bandwidth protection desired" flag was set in the SESSION_ATTRIBUTE object.
- 如果备份路径提供带宽保证，PLR应设置“带宽保护”标志，如果路径不提供带宽保证，PLR应清除“带宽保护”标志。如果在会话_属性对象中设置了“所需带宽保护”标志，则必须执行此操作。
A number of objectives must be met to obtain a satisfactory signaling solution. These are summarized as follows:
为了获得令人满意的信令解决方案，必须满足许多目标。总结如下：
1. Unambiguously and uniquely identifying backup paths.
1. 明确且唯一地标识备份路径。
2. Unambiguously associating protected LSPs with their backup paths.
2. 将受保护的LSP与其备份路径明确关联。
3. Working with both global and non-global label spaces.
3. 使用全局和非全局标签空间。
4. Allowing merging of backup paths.
4. 允许合并备份路径。
5. Maintaining RSVP state during and after fail-over.
5. 在故障转移期间和之后保持RSVP状态。
LSP tunnels are identified by a combination of the SESSION and SENDER_TEMPLATE objects [RSVP-TE]. The relevant fields are as follows.
LSP隧道由会话和发送方模板对象[RSVP-TE]的组合标识。相关字段如下所示。
IPv4 (or IPv6) tunnel end point address
IPv4（或IPv6）隧道端点地址
IPv4 (or IPv6) address of the egress node for the tunnel.
隧道出口节点的IPv4（或IPv6）地址。
Tunnel ID
隧道ID
A 16-bit identifier used in the SESSION that remains constant over the life of the tunnel.
会话中使用的16位标识符，在隧道的整个生命周期内保持不变。
Extended Tunnel ID
扩展隧道ID
A 32-bit (IPv4) or 128-bit (IPv6) identifier used in the SESSION that remains constant over the life of the tunnel. Normally it is set to all zero. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-egress pair may place their IP address here as a globally unique identifier.
会话中使用的32位（IPv4）或128位（IPv6）标识符，在隧道的生命周期内保持不变。通常它被设置为全零。希望将会话范围缩小到入口-出口对的入口节点可将其IP地址作为全局唯一标识符放置在此处。
IPv4 (or IPv6) tunnel sender address
IPv4（或IPv6）隧道发送方地址
IPv4 (or IPv6) address for a sender node.
发送方节点的IPv4（或IPv6）地址。
LSP ID
LSP ID
A 16-bit identifier used in the SENDER_TEMPLATE and the FILTER_SPEC, which can be changed to allow a sender to share resources with itself.
发送方模板和筛选器规范中使用的16位标识符，可更改为允许发送方与其自身共享资源。
The first three of these are in the SESSION object and are the basic identification for the tunnel. Setting the "Extended Tunnel ID" to an IP address of the head-end LSR allows the scope of the SESSION to be narrowed to only LSPs sent by that LSR. A backup LSP is considered part of the same session as its protected LSP; therefore these three cannot be varied.
前三个在会话对象中，是隧道的基本标识。将“扩展隧道ID”设置为前端LSR的IP地址可以将会话范围缩小到仅由该LSR发送的LSP。备份LSP被视为与其受保护LSP属于同一会话的一部分；因此，这三种情况不能改变。
The last two are in the SENDER_TEMPLATE. Multiple LSPs in the same SESSION may be protected and may take different routes; this is common when a tunnel is rerouted using make-before-break. A backup path must be clearly identified with its protected LSP to allow correct merging and state treatment. Therefore, a backup path must inherit its LSP ID from the associated protected LSP. Thus, the only field in the SESSION and SENDER_TEMPLATE objects that could be varied between a backup path and a protected LSP is the "IPv4 (or IPv6) tunnel sender address" in the SENDER_TEMPLATE.
最后两个在SENDER_模板中。同一会话中的多个LSP可能受到保护，并且可能采用不同的路由；这在使用先通后断重新路由隧道时很常见。备份路径必须用其受保护的LSP明确标识，以允许正确的合并和状态处理。因此，备份路径必须从关联的受保护LSP继承其LSP ID。因此，会话和发送方_模板对象中唯一可以在备份路径和受保护LSP之间变化的字段是发送方_模板中的“IPv4（或IPv6）隧道发送方地址”。
There are two different methods to uniquely identify a backup path, described below.
有两种不同的方法来唯一标识备份路径，如下所述。
In this approach, the SESSION object and the LSP_ID are copied from the protected LSP. The "IPv4 tunnel sender address" is set to an address of the PLR. If the head-end of a tunnel is also acting as the PLR, it MUST choose an IP address different from the one used in the SENDER_TEMPLATE of the original LSP tunnel.
在这种方法中，会话对象和LSP_ID是从受保护的LSP复制的。“IPv4隧道发送方地址”设置为PLR的地址。如果隧道的前端也充当PLR，则它必须选择与原始LSP隧道的发送方_模板中使用的IP地址不同的IP地址。
When the sender template-specific approach is used, the protected LSPs and the backup paths SHOULD use the Shared Explicit (SE) style. This allows bandwidth sharing between multiple backup paths. The backup paths and the protected LSP MAY be merged by the Detour Merge Points, when the ERO from the MP to the egress is the same on each LSP to be merged, as specified in [RSVP-TE].
使用特定于发送方模板的方法时，受保护的LSP和备份路径应使用共享显式（SE）样式。这允许在多个备份路径之间共享带宽。按照[RSVP-TE]中的规定，当从MP到出口的ERO在每个要合并的LSP上相同时，可通过迂回合并点合并备份路径和受保护的LSP。
In this approach, rather than vary the SESSION or SENDER_TEMPLATE objects, an implementation uses a new object, the DETOUR object, to distinguish between PATH messages for a backup path and the protected LSP.
在这种方法中，实现使用一个新对象，即迂回对象来区分备份路径和受保护LSP的路径消息，而不是改变会话或发送方模板对象。
Thus, the backup paths use the same SESSION and SENDER_TEMPLATE objects as the ones used in the protected LSP. The presence of a DETOUR object in Path messages signifies a backup path; the presence of a FAST_REROUTE object and/or the "local protection requested" flag in the SESSION_ATTRIBUTE object indicates a protected LSP.
因此，备份路径使用与受保护LSP中使用的会话和发送方模板对象相同的会话和发送方模板对象。路径消息中存在迂回对象表示备份路径；会话_属性对象中存在快速_重路由对象和/或“本地保护请求”标志表示受保护的LSP。
In the path message-specific approach, an LSR merges Path messages that are received with the same SESSION and SENDER_TEMPLATE objects and that also have the same next-hop object. Without this behavior, it would be impossible to associate the multiple RESV messages with the backup paths. However, this merging behavior reduces the total number of RSVP states inside the network at the expense of merging LSPs with different EROs.
在特定于路径消息的方法中，LSR合并使用相同会话和发送方模板对象接收的路径消息，以及具有相同下一跳对象的路径消息。如果没有这种行为，就不可能将多个RESV消息与备份路径相关联。但是，这种合并行为减少了网络内RSVP状态的总数，但代价是将LSP与不同的ERO合并。
Before a PLR can create a detour or a bypass tunnel, the desired explicit route must be determined. This can be done using a CSPF (Constraint-based Shortest Path First) computation. Before this CSPF computation, the following information must be collected at a PLR:
在PLR可以创建绕道或旁通隧道之前，必须确定所需的明确路线。这可以使用CSPF（基于约束的最短路径优先）计算来完成。在计算CSPF之前，必须在PLR上收集以下信息：
- The list of downstream nodes that the protected LSP passes through. This information is readily available from the RECORD_ROUTE objects during LSP setup. This information is also available from the ERO. However, if the ERO contains loose sub-objects, the ERO may not provide adequate information.
- 受保护LSP通过的下游节点列表。在LSP设置期间，可以从记录路由对象中随时获取此信息。该信息也可从能源监管局获得。但是，如果ERO包含松散的子对象，则ERO可能无法提供足够的信息。
- The downstream links/nodes that we want to protect against. Once again, this information is learned from the RECORD_ROUTE objects. Whether node protection is desired is determined by the "node protection" flag in the SESSION_ATTRIBUTE object and local policy.
- 我们要保护的下游链路/节点。该信息再次从记录路由对象中学习。是否需要节点保护由会话_属性对象和本地策略中的“节点保护”标志确定。
- The upstream uni-directional links that the protected LSP passes through. This information is learned from the RECORD_ROUTE objects; it is only needed for setting up one-to-one protection. In the path-specific method, it is necessary to avoid the detour and the protected LSP sharing a common next-hop upstream of the failure. In the sender template-specific mode, this same restriction is necessary to avoid sharing bandwidth between the detour and its protected LSP, where that bandwidth has been reserved only once.
- 受保护LSP通过的上游单向链路。该信息从记录路由对象中获取；它仅用于设置一对一保护。在路径特定方法中，必须避免绕道和受保护的LSP共享故障上游的公共下一跳。在特定于发送方模板的模式中，同样的限制是必要的，以避免在绕道与其受保护的LSP之间共享带宽，其中该带宽仅保留了一次。
- The link attribute filters to be applied. These are derived from the FAST_REROUTE object, if it is included in the PATH message, or from the SESSION_ATTRIBUTE object otherwise.
- 要应用的链接属性过滤器。如果路径消息中包含FAST_REROUTE对象，则从该对象派生，否则从SESSION_属性对象派生。
- The bandwidth to be used is found in the FAST_REROUTE object, if it is included in the PATH message, or in the SESSION_ATTRIBUTE object otherwise. Local policy may modify the bandwidth to be reserved.
- 如果要使用的带宽包含在PATH消息中，则可以在FAST_REROUTE对象中找到，否则可以在SESSION_属性对象中找到。本地策略可能会修改要保留的带宽。
- The hop-limit, if a FAST_REROUTE object was included in the PATH message.
- 如果路径消息中包含快速重新路由对象，则跃点限制。
When a CSPF algorithm is used to compute the backup route, the following constraints must be satisfied:
当使用CSPF算法计算备份路由时，必须满足以下约束：
- For detour LSPs, the destination MUST be the tail-end of the protected LSP. For bypass tunnels (Section 7), the destination MUST be the address of the MP.
- 对于迂回LSP，目的地必须是受保护LSP的尾端。对于旁通隧道（第7节），目的地必须是MP的地址。
- When one-to-one protection is set up by using the path-specific method, a detour MUST not traverse the upstream links of the protected LSP in the same direction. This prevents the possibility of early merging of the detour into the protected LSP. When one-to-one protection is set up using the sender-template-specific method, a detour should not traverse the upstream links of the protected LSP in the same direction. This prevents sharing the bandwidth between a protected LSP and its backup upstream of the failure where the bandwidth would be used twice in the event of a failure.
- 当使用特定路径方法设置一对一保护时，迂回不得沿同一方向穿过受保护LSP的上游链路。这可防止迂回线提前合并到受保护的LSP中。当使用特定于发送方模板的方法设置一对一保护时，迂回不应沿同一方向穿过受保护LSP的上游链路。这防止了受保护的LSP与其故障上游备份之间共享带宽，而在发生故障时，带宽将被使用两次。
- The backup LSP cannot traverse the downstream node and/or link whose failure is being protected against. Note that if the PLR is the penultimate hop, node protection is not possible, and only the downstream link can be avoided. The backup path may be computed to be SRLG disjoint from the downstream node and/or link being avoided.
- 备份LSP无法遍历其故障受到保护的下游节点和/或链路。注意，如果PLR是倒数第二个跃点，则节点保护是不可能的，并且只能避免下游链路。备份路径可被计算为与下游节点和/或被避免的链路分离的SRLG。
- The backup path must satisfy the resource requirements of the protected LSP. This includes the link attribute filters, bandwidth, and hop limits determined from the FAST_REROUTE object and the SESSION_ATTRIBUTE object.
- 备份路径必须满足受保护LSP的资源要求。这包括从FAST_REROUTE对象和SESSION_属性对象确定的链路属性筛选器、带宽和跃点限制。
If such computation succeeds, the PLR should attempt to establish a backup path. The PLR may schedule a re-computation at a later time to discover better paths that might have emerged. If for any reason, the PLR is unable to bring up a backup path, it must schedule a retry at a later time.
如果此类计算成功，PLR应尝试建立备份路径。PLR可在稍后时间安排重新计算以发现可能出现的更好路径。如果出于任何原因，PLR无法启动备份路径，则必须安排稍后重试。
Once a PLR has decided to protect an LSP locally with one-to-one backup and has identified the desired path, it signals for the detour.
一旦PLR决定使用一对一备份在本地保护LSP并确定所需路径，它就会发出绕道信号。
The following describes the transformation to be performed upon the protected LSP's PATH message to create the detour LSP's PATH message.
以下描述了对受保护LSP的PATH消息执行的转换，以创建迂回LSP的PATH消息。
- If the sender template-specific method is to be used, then the PLR MUST change the "IPv4 (or IPv6) tunnel sender address" of the SENDER_TEMPLATE to an address belonging to the PLR that is not the same as that used for the protected LSP. Additionally, the DETOUR object MAY be added to the PATH message.
- 如果要使用特定于发送方模板的方法，则PLR必须将发送方模板的“IPv4（或IPv6）隧道发送方地址”更改为属于PLR的地址，该地址与用于受保护LSP的地址不同。此外，可以将迂回对象添加到路径消息中。
- If the path-specific method is to be used, then the PLR MUST add a DETOUR object to the PATH message.
- 如果要使用特定于路径的方法，则PLR必须将迂回对象添加到路径消息中。
- The SESSION_ATTRIBUTE flags "Local protection desired", "Bandwidth protection desired", and "Node protection desired" MUST be cleared. The "Label recording desired" flag MAY be modified. If the Path Message contained a FAST_REROUTE object and the ERO is not completely strict, the Include-any, Exclude-any, and Include-all fields of the FAST_REROUTE object SHOULD be copied to the corresponding fields of the SESSION_ATTRIBUTE object.
- 会话_属性标志“需要本地保护”、“需要带宽保护”和“需要节点保护”必须清除。可以修改“标签记录所需”标志。如果路径消息包含FAST_REROUTE对象且ERO不完全严格，则应将FAST_REROUTE对象的Include any、Exclude any和Include all字段复制到SESSION_属性对象的相应字段中。
- If the protected LSP's Path message contained a FAST_REROUTE object, this object MUST be removed from the detour LSP's PATH message.
- 如果受保护LSP的Path消息包含FAST_REROUTE对象，则必须从绕行LSP的Path消息中删除此对象。
- The PLR MUST generate an EXPLICIT_ROUTE object toward the egress. First, the PLR must remove all sub-objects preceding the first address belonging to the Merge Point. Then the PLR SHOULD add sub-objects corresponding to the desired backup path between the PLR and the MP.
- PLR必须向出口生成一个明确的_路线对象。首先，PLR必须删除属于合并点的第一个地址之前的所有子对象。然后，PLR应在PLR和MP之间添加与所需备份路径对应的子对象。
- The SENDER_TSPEC object SHOULD contain the bandwidth information from the received FAST_REROUTE object, if included in the protected LSP's PATH message.
- 发送方\u TSPEC对象应包含来自接收到的快速\u重路由对象的带宽信息（如果包含在受保护的LSP路径消息中）。
- The RSVP_HOP object containing one of the PLR's IP address.
- 包含PLR IP地址之一的RSVP_-HOP对象。
- The detour LSPs MUST use the same reservation style as the protected LSP. This must be correctly reflected in the SESSION_ATTRIBUTE object.
- 绕行LSP必须使用与受保护LSP相同的保留样式。这必须正确反映在会话_属性对象中。
Detour LSPs operate like regular LSPs. Once a detour path is successfully computed and the detour LSP is established, the PLR need not compute detour routes again, unless (1) the contents of FAST_REROUTE have changed or (2) the downstream interface and/or the nexthop router for a protected LSP has changed. The PLR may recompute detour routes at any time.
迂回LSP的运行方式与常规LSP相同。成功计算绕行路径并建立绕行LSP后，PLR无需再次计算绕行路由，除非（1）快速重新路由的内容已更改或（2）受保护LSP的下游接口和/或下一个路由器已更改。PLR可随时重新计算绕行路线。
If the sender template-specific method is used, it is possible to do make-before-break with detour LSPs. This is done using two different IP addresses belonging to the PLR (which were not used in the SENDER_TEMPLATE of the protected LSP). If the current detour LSP uses the first IP address in its SENDER_TEMPLATE, then the new detour LSP should be signaled by using the second IP address in its SENDER_TEMPLATE. Once the new detour LSP has been created, the current detour LSP can be torn down. By alternating the use of these IP addresses, the current and new detour LSPs will have different SENDER_TEMPLATES and, thus, different state in the downstream LSRs.
如果使用特定于发送方模板的方法，则可以使用迂回LSP进行先通后断。这是使用属于PLR的两个不同IP地址完成的（在受保护LSP的发送方_模板中未使用）。如果当前迂回LSP使用其发送方\模板中的第一个IP地址，则应使用其发送方\模板中的第二个IP地址通知新迂回LSP。创建新的绕行LSP后，可以拆除当前的绕行LSP。通过交替使用这些IP地址，当前和新的迂回LSP将具有不同的发送方_模板，从而在下游LSR中具有不同的状态。
This make-before-break mechanism, which changes the PLR IP address in the DETOUR object instead, is not feasible with the path-specific method, as the PATH messages for new and current detour LSPs may be merged if they share a common next-hop.
这种先通后断机制（改为更改迂回对象中的PLR IP地址）对于路径特定方法是不可行的，因为如果新迂回LSP和当前迂回LSP共享一个公共下一跳，则它们的路径消息可能会合并。
LSRs must process the detour LSPs independently of the protected LSPs to avoid triggering the LSP loop detection procedure described in [RSVP-TE].
LSR必须独立于受保护的LSP处理绕行LSP，以避免触发[RSVP-TE]中所述的LSP环路检测程序。
The PLR MUST not mix the messages for the protected and the detour LSPs. When a PLR receives Resv, ResvTear, and PathErr messages from the downstream detour destination, the messages MUST not be forwarded upstream. Similarly, when a PLR receives ResvErr and ResvConf messages from a protected LSP, it MUST not propagate them onto the associated detour LSP.
PLR不得将受保护和绕行LSP的信息混合。当PLR从下游绕行目的地接收到Resv、ResvTear和PathErr消息时，不得将消息转发到上游。类似地，当PLR从受保护的LSP接收ResvErr和ResvConf消息时，不得将其传播到相关的绕行LSP上。
A session tear-down request is normally originated by the sender via PathTear messages. When a PLR node receives a PathTear message from upstream, it MUST delete both the protected and the detour LSPs. The PathTear messages MUST propagate to both protected and detour LSPs. During error conditions, the LSRs may send ResvTear messages to fix problems on the failing path. When a PLR node receives the ResvTear messages from downstream for a protected LSP, as long as a detour is up, the ResvTear messages MUST not be sent further upstream. PathErrs should be treated similarly.
会话中断请求通常由发送方通过PathTear消息发起。当PLR节点从上游接收到PathTear消息时，它必须同时删除受保护的LSP和迂回LSP。PathTear消息必须传播到受保护的LSP和迂回LSP。在错误情况下，LSR可能会发送ResvTear消息以修复故障路径上的问题。当PLR节点接收到来自下游的受保护LSP的ResvTear消息时，只要绕道开始，ResvTear消息就不能再向上游发送。应该以同样的方式对待探路者。
When the PLR detects a failure on the protected LSP, the PLR MUST rapidly switch packets to the protected LSP's backup LSP instead of to the protected LSP's normal out-segment. The goal of this method is to effect the redirection within 10s of milliseconds.
当PLR在受保护LSP上检测到故障时，PLR必须快速将数据包切换到受保护LSP的备份LSP，而不是切换到受保护LSP的正常输出段。此方法的目标是在10毫秒内实现重定向。
L32 L33 L34 L35
R1-------R2-------R3-------R4-------R5
| |
L46 | | L44
| L47 |
R6----------------R7
L32 L33 L34 L35
R1-------R2-------R3-------R4-------R5
| |
L46 | | L44
| L47 |
R6----------------R7
Protected LSP: [R1->R2->R3->R4->R5]
Detour LSP: [R2->R6->R7->R4]
Protected LSP: [R1->R2->R3->R4->R5]
Detour LSP: [R2->R6->R7->R4]
Example 3. Redirect to Detour
例3。改道
In Example 3, if the link [R2->R3] fails, R2 would do the following. Any traffic received on link [R1->R2] with label L32 would be sent on link [R2->R6] with label L46 (along the detour LSP) instead of on link [R3->R4] with label L34 (along the protected LSP). The merge point R4 would recognize that packets received on link [R7->R4] with label L44 should be sent on link [R4->R5] with label L35 and that they should be merged with the protected LSP.
在示例3中，如果链接[R2->R3]失败，R2将执行以下操作。在带有标签L32的链路[R1->R2]上接收的任何通信量将在带有标签L46的链路[R2->R6]上（沿着绕行LSP）发送，而不是在带有标签L34的链路[R3->R4]上（沿着受保护LSP）。合并点R4将识别在标签为L44的链路[R7->R4]上接收的数据包应该在标签为L35的链路[R4->R5]上发送，并且它们应该与受保护的LSP合并。
A PLR may use one or more bypass tunnels to protect against the failure of a link and/or a node. These bypass tunnels may be set up in advance or may be dynamically created as new protected LSPs are signaled.
PLR可以使用一个或多个旁路隧道来防止链路和/或节点的故障。这些旁通隧道可以提前设置，也可以在发出新的受保护LSP信号时动态创建。
To support facility backup, the PLR must determine a label that will indicate to the MP that packets received with that label should be switched along the protected LSP. This can be done without explicitly signaling the backup path if the MP uses a label space global to that LSR.
为了支持设施备份，PLR必须确定一个标签，该标签将向MP指示使用该标签接收的数据包应沿受保护的LSP交换。如果MP使用该LSR的全局标签空间，则无需显式地向备份路径发送信号即可完成此操作。
As described in Section 6, the head-end LSR MUST set the "label recording requested" flag in the SESSION_ATTRIBUTE object for LSPs requesting local protection. This will cause (as specified in [RSVP-TE]) all LSRs to record their INBOUND labels and to note via a flag whether the label is global to the LSR. Thus, when a protected LSP is first signaled through a PLR, the PLR can examine the RRO in the Resv message and learn about the incoming labels that are used by all downstream nodes for this LSP
如第6节所述，前端LSR必须在会话_属性对象中为请求本地保护的LSP设置“标签记录请求”标志。这将导致（按照[RSVP-TE]中的规定）所有LSR记录其入站标签，并通过标志说明标签是否是LSR的全局标签。因此，当受保护的LSP第一次通过PLR发信号时，PLR可以检查Resv消息中的RRO，并了解所有下游节点用于该LSP的传入标签
When MPs use per-interface label spaces, the PLR must send Path messages (for each protected LSP using a bypass tunnel) via that bypass tunnel prior to the failure in order to discover the appropriate MP label. The signaling procedures for this are in Section 6.4.3 below.
当MPs使用每个接口标签空间时，PLR必须在故障发生之前通过该旁路隧道发送路径消息（对于使用旁路隧道的每个受保护LSP），以便发现适当的MP标签。下文第6.4.3节介绍了这方面的信号程序。
A PLR that determines to use facility-backup to protect a given LSP should select a bypass tunnel to use, taking into account whether node protection is to be provided, what bandwidth was requested, whether a bandwidth guarantee is desired, and what link attribute filters were specified in the FAST_REROUTE object. The selection of a bypass tunnel for a protected LSP is performed by the PLR when the LSP is first set up.
确定使用设施备份来保护给定LSP的PLR应选择要使用的旁路隧道，同时考虑是否提供节点保护、请求的带宽、是否需要带宽保证以及在FAST_REROUTE对象中指定的链路属性筛选器。当LSP首次设置时，PLR将为受保护的LSP选择旁通隧道。
When the PLR detects a link or/and node failure condition, it has to reroute the data traffic onto the bypass tunnel and to start sending the control traffic for the protected LSP onto the bypass tunnel.
当PLR检测到链路或/和节点故障情况时，它必须将数据流量重新路由到旁路隧道，并开始将受保护LSP的控制流量发送到旁路隧道。
The backup tunnel is identified by using the sender template-specific method. The procedures to follow are similar to those described in Section 6.3.
通过使用特定于发送方模板的方法来标识备份隧道。遵循的程序与第6.3节所述的程序类似。
- The SESSION is unchanged.
- 会议没有改变。
- The SESSION_ATTRIBUTE is unchanged except as follows: The "Local protection desired", "Bandwidth protection desired", and "Node protection desired" flags SHOULD be cleared. The "Label recording desired" MAY be modified.
- 会话_属性不变，但如下情况除外：“需要本地保护”、“需要带宽保护”和“需要节点保护”标志应清除。可以修改“所需标签记录”。
- The IPv4 (or IPv6) tunnel sender address of the SENDER_TEMPLATE is set to an address belonging to the PLR.
- 发送方\模板的IPv4（或IPv6）隧道发送方地址设置为属于PLR的地址。
- The RSVP_HOP object MUST contain an IP source address belonging to the PLR. Consequently, the MP will send messages back to the PLR with that IP address as the destination.
- RSVP_-HOP对象必须包含属于PLR的IP源地址。因此，MP将以该IP地址作为目的地向PLR发送消息。
- The PLR MUST generate an EXPLICIT_ROUTE object toward the egress. Detailed ERO processing is described below.
- PLR必须向出口生成一个明确的_路线对象。下面描述详细的ERO处理。
- The RRO object may have to be updated as described in Section 6.5.
- 如第6.5节所述，可能必须更新RRO对象。
The PLR sends Path, PathTear, and ResvConf messages via the backup tunnel. The MP sends Resv, ResvTear, and PathErr messages by sending them directly to the address in the RSVP_HOP object, as specified in [RSVP].
PLR通过备份通道发送Path、PATHTRARE和ResvConf消息。MP通过将Resv、ResvTear和PathErr消息直接发送到RSVP_-HOP对象中的地址来发送它们，如[RSVP]中所指定。
If it is necessary to signal the backup prior to failure to determine the MP label to use, then the same Path message is sent. In this case, the PLR SHOULD continue to send Path messages for the protected LSP along the normal route. PathTear messages should be duplicated, with one sent along the normal route and one sent through the bypass tunnel. The MP should duplicate the Resv and ResvTear messages and send them to both the PLR and the LSR indicated by the protected LSP's RSVP_HOP object.
如果必须在确定要使用的MP标签失败之前向备份发送信号，则会发送相同的路径消息。在这种情况下，PLR应继续沿正常路由发送受保护LSP的路径消息。PathTear消息应该是重复的，一条沿着正常路径发送，另一条通过旁路隧道发送。MP应复制Resv和ResvTear消息，并将它们发送到PLR和受保护LSP的RSVP_HOP对象指示的LSR。
Procedures for ERO processing are described in [RSVP-TE]. This section describes additional ERO update procedures for Path messages that are sent over bypass tunnels. If normal ERO processing rules were followed, the Merge Point would examine the first sub-object and likely reject it (Bad initial sub-object). This is because the unmodified ERO might contain the IP address of a bypassed node (in the case of a NNHOP Bypass Tunnel) or of an interface that is currently down (in the case of a NHOP Backup Tunnel). For this reason, the PLR invokes the following ERO procedures before sending a Path message via a bypass tunnel.
ERO处理程序见[RSVP-TE]。本节介绍通过旁路隧道发送的路径消息的其他ERO更新过程。如果遵循正常的ERO处理规则，合并点将检查第一个子对象并可能拒绝它（错误的初始子对象）。这是因为未修改的ERO可能包含被绕过节点（在NNHOP旁路隧道的情况下）或当前关闭的接口（在NHOP备份隧道的情况下）的IP地址。因此，PLR在通过旁路隧道发送路径消息之前调用以下ERO过程。
Sub-objects belonging to abstract nodes that precede the Merge Point are removed, along with the first sub-object belonging to the MP. A sub-object identifying the Backup Tunnel destination is then added.
属于合并点之前的抽象节点的子对象与属于MP的第一个子对象一起被删除。然后添加标识备份隧道目标的子对象。
More specifically, the PLR MUST:
更具体地说，PLR必须：
- remove all the sub-objects proceeding the first address belonging to the MP, and
- 删除属于MP的第一个地址的所有子对象，以及
- replace this first MP address with an IP address of the MP. (Note that this could be same address that was just removed.)
- 用MP的IP地址替换第一个MP地址。（请注意，这可能是刚刚删除的同一地址。）
In addition to the method-specific signaling and packet treatment, there is common signaling that should be followed.
除了特定于方法的信令和分组处理之外，还应遵循通用信令。
During fast reroute, for each protected LSP containing an RRO object, the PLR obtains the RRO from the protected LSP's stored RESV. The PLR MUST update the IPv4 or IPv6 sub-object it inserted into the RRO by setting the "Local protection in use" and "Local Protection Available" flags.
在快速重路由期间，对于每个包含RRO对象的受保护LSP，PLR从受保护LSP存储的RESV获取RRO。PLR必须通过设置“本地保护正在使用”和“本地保护可用”标志来更新插入到RRO中的IPv4或IPv6子对象。
In many situations, the route used during local repair will be less than optimal. The purpose of local repair is to keep high priority and loss-sensitive traffic flowing while a more optimal re-routing of the tunnel can be effected by the head-end of the tunnel. Thus, the head-end has to know of the failure so that it may re-signal an optimal LSP.
在许多情况下，局部维修期间使用的路线将不是最佳路线。局部修复的目的是保持高优先级和对损失敏感的交通流，而隧道的前端可以实现更优化的隧道重新布线。因此，前端必须知道故障，以便可以重新发送最优LSP信号。
To provide this notification, the PLR SHOULD send a Path Error message with error code of "Notify" (Error code = 25) and an error value field of ss00 cccc cccc cccc, where ss=00 and the sub-code = 3 ("Tunnel locally repaired") (see [RSVP-TE]).
为提供此通知，PLR应发送路径错误消息，错误代码为“Notify”（错误代码=25），错误值字段为ss00 cccc，其中ss=00，子代码=3（“隧道本地修复”）（见[RSVP-TE]）。
Additionally, a head-end may detect that an LSP has to be moved to a more optimal path by noticing failures reported via the IGP. Note that in the case of inter-area TE LSP (TE LSP spanning areas), the head-end LSR will have to rely exclusively on Path Error messages to be informed of failures in another area.
此外，前端可以通过注意经由IGP报告的故障来检测LSP必须移动到更优化的路径。注意，在区域间TE-LSP（TE-LSP跨区域）的情况下，前端LSR必须完全依赖路径错误消息，以通知另一个区域中的故障。
Upon a failure event, a protected TE LSP is locally repaired by the PLR. There are two basic strategies for restoring the TE LSP to a full working path.
一旦发生故障事件，受保护的TE LSP将由PLR进行本地修复。将TE LSP恢复为完整工作路径有两种基本策略。
- Global revertive mode: The head-end LSR of each tunnel is responsible for reoptimizing the TE LSPs that used the failed resource. There are several potential reoptimization triggers: RSVP error messages, inspection of OSPF LSAs or ISIS LSPs, and timers. Note that this re-optimization process may proceed as soon as the failure is detected. It is not tied to the restoration of the failed resource.
- 全局恢复模式：每个隧道的前端LSR负责重新优化使用故障资源的TE LSP。有几种潜在的重新优化触发因素：RSVP错误消息、OSPF LSA或ISIS LSP检查以及定时器。请注意，一旦检测到故障，此重新优化过程可能会继续进行。它与故障资源的恢复无关。
- Local revertive mode: Upon detecting that the resource is restored, the PLR re-signals each of the TE LSPs that used to be routed over the restored resource. Every TE LSP successfully re-signaled along the restored resource is switched back.
- 本地恢复模式：在检测到资源已恢复后，PLR重新向每个TE LSP发送信号，这些LSP过去在恢复的资源上路由。成功地沿恢复的资源重新发送信号的每个TE LSP被切换回。
There are several circumstances in which a local revertive mode might not be desirable. In the case of resource flapping (not an uncommon failure type), this could generate multiple traffic disruptions. Therefore, in the local revertive mode, the PLR should implement a means to dampen the re-signaling process in order to limit potential disruptions due to flapping.
在某些情况下，可能不需要使用局部恢复模式。在资源摆动的情况下（并非罕见的故障类型），这可能会导致多个通信中断。因此，在局部回复模式中，PLR应实施抑制再发信号过程的方法，以限制由于拍打而造成的潜在中断。
In the local revertive mode, any TE LSP will be switched back, without any distinction, whereas in the global revertive mode, the decision to reuse the restored resource is made by the head-end LSR based on the TE LSP attributes. When the head-end learns of the failure, it may reoptimize the protected LSP tunnel along a different and more optimal path, as it has a more complete view of the resources and TE LSP constraints. This means that the old LSP that has been reverted to may no longer be optimal. Note that in the case of inter-area LSP, where the TE LSP path computation might be done on some Path Computation Element, the reoptimization process can
在本地恢复模式下，任何TE LSP都将被无区别地切换回，而在全局恢复模式下，由前端LSR根据TE LSP属性决定是否重用恢复的资源。当前端得知故障时，它可能会沿着不同且更优化的路径重新优化受保护的LSP隧道，因为它对资源和TE LSP约束有更完整的视图。这意味着已恢复为的旧LSP可能不再是最优的。注意，在区域间LSP的情况下，其中TE LSP路径计算可能在某个路径计算元素上完成，可以执行重新优化过程
still be triggered on the Head-End LSP. The local revertive mode is optional.
仍将在前端LSP上触发。本地恢复模式是可选的。
However, there are circumstances in which the head-end does not have the ability to reroute the TE LSP (e.g., if the protected LSP is pinned down, as may be desirable if the paths are determined by using an off-line optimization tool), or if the head-end does not have the complete TE topology information (depending on the path computation scenario). In those cases, the local revertive mode might be an interesting option.
然而，在某些情况下，前端不具备重新路由TE-LSP的能力（例如，如果受保护LSP被固定，如果路径是通过使用离线优化工具确定的，这可能是可取的），或者如果前端没有完整的TE拓扑信息（取决于路径计算场景）. 在这些情况下，本地恢复模式可能是一个有趣的选择。
The globally revertive mode SHOULD always be used. Note that a link or node "failure" may be due to the facility being permanently taken out of service. Local revertive mode is optional. When used in combination, the global mode may rely solely on timers to do the reoptimization. When local revertive mode is not used, head-end LSRs SHOULD react to RSVP error messages and/or IGP indications in order to make a timely response.
应始终使用全局还原模式。请注意，链路或节点“故障”可能是由于设施永久停止使用所致。本地恢复模式是可选的。当组合使用时，全局模式可能仅依赖计时器进行重新优化。当不使用本地回复模式时，前端LSR应响应RSVP错误消息和/或IGP指示，以便及时做出响应。
Interoperability: If a PLR is configured with the local revertive mode but the MP is not, any attempt from the PLR to resignal the TE LSP over the restored resource will fail, as the MP will not send any Resv message. The PLR will still refresh the TE LSP over the backup tunnel. The TE LSP will not revert to the restored resource; instead, it will continue to use the backup until it is re-optimized.
互操作性：如果PLR配置了本地恢复模式，但MP没有，则PLR通过恢复的资源重新签名TE LSP的任何尝试都将失败，因为MP不会发送任何Resv消息。PLR仍将通过备份通道刷新TE LSP。TE LSP不会恢复到恢复的资源；相反，它将继续使用备份，直到重新优化。
An LSR is a Merge Point if it receives the Path message for a protected LSP and one or more messages for a backup LSP that is merged into that protected LSP. In the one-to-one backup method, the LSR is aware that it is a merge node prior to failure. In the facility backup method, the LSR may not know that it is a Merge Point until a failure occurs and it receives a backup LSP's Path message. Therefore, an LSR that is on the path of a protected LSP SHOULD always assume that it is a merge point.
如果LSR接收到受保护LSP的路径消息以及合并到该受保护LSP中的备份LSP的一条或多条消息，则LSR是合并点。在一对一备份方法中，LSR在发生故障之前知道它是一个合并节点。在协作室备份方法中，LSR可能不知道它是合并点，直到发生故障并接收到备份LSP的Path消息。因此，位于受保护LSP路径上的LSR应始终假定它是合并点。
When a MP receives a backup LSP's Path message through a bypass tunnel, the Send_TTL in the Common Header may not match the TTL of the IP packet within which the Path message was transported. This is expected behavior.
当MP通过旁路隧道接收到备份LSP的Path消息时，公共报头中的发送TTL可能与传输Path消息的IP数据包的TTL不匹配。这是预期的行为。
There are two circumstances in which a Merge Point will receive Path messages for a backup path prior to failure. In the first case, if a PLR is providing local protection via the one-to-one backup method, the detour will be signaled and must be properly handled by the MP.
在两种情况下，合并点将在发生故障之前接收备份路径的路径消息。在第一种情况下，如果PLR通过一对一备份方法提供本地保护，则绕道将发出信号，并且必须由MP正确处理。
In this case, the backup LSP may be signaled via the sender template-specific method or via the path-specific method.
在这种情况下，可以通过发送方模板特定方法或路径特定方法来通知备份LSP。
In the second case, if the Merge Point does not provide labels global to the MP and record them in a Label sub-object of the RRO, or if the PLR does not use such recorded information, the PLR may signal the backup path as described in Section 6.4.1. This will determine the label to use if the PLR is providing protection according to the facility backup method. In this case, the backup LSP is signaled via the sender template-specific method.
在第二种情况下，如果合并点未向MP提供全局标签并将其记录在RRO的标签子对象中，或者如果PLR未使用此类记录的信息，则PLR可按照第6.4.1节所述向备份路径发送信号。如果PLR根据设施备份方法提供保护，这将确定要使用的标签。在这种情况下，备份LSP通过特定于发送方模板的方法发出信号。
The reception of a backup LSP's path message does not indicate that a failure has occurred or that the incoming protected LSP will no longer be used.
接收到备份LSP的path消息并不表示发生了故障或传入的受保护LSP将不再使用。
An LSR may receive multiple Path messages for one or more backup LSPs and, possibly, for the protected LSP. Each of these Path messages will have a different SENDER_TEMPLATE. The protected LSP can be recognized because it will include the FAST_REROUTE object or have the "local protection desired" flag set in the SESSION_ATTRIBUTE object, or both.
LSR可以接收一个或多个备份LSP的多路径消息，也可能接收受保护LSP的多路径消息。这些路径消息中的每一条都将有一个不同的发件人模板。可以识别受保护的LSP，因为它将包括FAST_REROUTE对象或在SESSION_属性对象中设置“local protection desired”标志，或两者兼而有之。
If the outgoing interface and next-hop LSR are the same, then the Path messages are eligible for merging. Similarly to the specification in [RSVP-TE] for merging of RESV messages, only Path messages whose ERO from that LSR to the egress is the same can be merged. If merging occurs and one of the Path messages merged was for the protected LSP, then the final Path message to be sent MUST be that of the protected LSP. This merges the backup LSPs into the protected LSP at that LSR. Once the final Path message has been identified, the MP MUST start to refresh it downstream periodically.
如果传出接口和下一跳LSR相同，则路径消息可以合并。与[RSVP-TE]中关于合并RESV消息的规范类似，只能合并从该LSR到出口的ERO相同的路径消息。如果发生合并并且合并的路径消息之一是针对受保护LSP的，则要发送的最终路径消息必须是受保护LSP的路径消息。这会将备份LSP合并到该LSR的受保护LSP中。一旦确定了最终路径消息，MP必须开始定期在下游刷新它。
If merging occurs and all the Path messages were for backup LSPs, then the DETOUR object, if any, should be altered as specified in Section 8.1
如果发生合并，且所有路径消息都用于备份LSP，则应按照第8.1节的规定更改迂回对象（如果有）
An LSR (that is, an MP) may receive multiple Path messages from different interfaces with identical SESSION and SENDER_TEMPLATE objects. In this case, Path state merging is REQUIRED. The merging rule is as follows:
LSR（即MP）可以从具有相同会话和发送方模板对象的不同接口接收多路径消息。在这种情况下，需要合并路径状态。合并规则如下：
If all Path messages have neither a FAST_REROUTE nor a DETOUR object, or if the MP is the egress of the LSP, no merging is required. The messages are processed according to [RSVP-TE].
如果所有路径消息既没有快速重新路由也没有迂回对象，或者如果MP是LSP的出口，则不需要合并。根据[RSVP-TE]处理消息。
Otherwise, the MP MUST record the Path state and the incoming interface. If the Path messages do not share an outgoing interface and a next-hop LSR, the MP MUST consider them to be independent LSPs and MUST NOT merge them.
否则，MP必须记录路径状态和传入接口。如果PATH消息不共享输出接口和下一跳LSR，MP必须认为它们是独立LSP，并且不能合并它们。
For all the Path messages that share the same outgoing interface and next-hop LSR, the MP runs the following procedure to create a Path message to forward downstream.
对于共享同一传出接口和下一跳LSR的所有Path消息，MP运行以下过程来创建要转发到下游的Path消息。
1. If one or more of the Path messages is for the protected LSP (a protected LSP is one originated from this node, or with the FAST_REROUTE object, or without the DETOUR object), one of these must become the chosen Path message. There could be more than one; in that case, which one to forward is a local decision. Quit.
1. 如果一个或多个路径消息用于受保护的LSP（受保护的LSP是来自此节点的消息，或带有FAST_REROUTE对象，或没有DETOUR对象），则其中一个必须成为所选路径消息。可能不止一个；在这种情况下，转发哪个是本地决定。退出
2. From the remaining set of Detour Path messages, eliminate from consideration those that traverse nodes that others want to avoid.
2. 从剩余的迂回路径消息集中，排除那些遍历其他人希望避免的节点的消息。
3. If several still remain, which one to forward is a local decision. If none remain, then the MP MAY try to find a new route that avoids all nodes that merging Detour Paths want to avoid; it will forward a Path message with that ERO.
3. 如果仍有几个，则转发哪一个是本地决定。如果没有剩余，则MP可以尝试找到一条新路由，该路由避免合并迂回路径想要避免的所有节点；它将与该ERO一起转发路径消息。
Once the final Path message has been identified, the MP MUST start to refresh it downstream periodically. Other LSPs are considered merged at this node. For bandwidth reservations on the outgoing link, any merging should be considered to have occurred before bandwidth is reserved. Thus, even though Fixed Filter style is specified, multiple detours and/or their protected LSP (which are to be merged due to sharing an outgoing interface and next-hop LSR) will reserve only the bandwidth of the final Path message on that outgoing interface.
一旦确定了最终路径消息，MP必须开始定期在下游刷新它。其他LSP被视为在此节点处合并。对于传出链路上的带宽保留，应将任何合并视为在保留带宽之前发生。因此，即使指定了固定过滤器样式，多个迂回和/或其受保护的LSP（由于共享传出接口和下一跳LSR而合并）将仅保留该传出接口上最终路径消息的带宽。
If no merged Path message can be constructed, the MP SHOULD send a PathErr in response to the most recently received detour Path message. If a protected Path is chosen to be forwarded but it traverses nodes that some detours want to avoid, PathErrs SHOULD be sent in response to those detour Paths which cannot merge.
如果无法构造合并路径消息，MP应发送PathErr以响应最近收到的迂回路径消息。如果选择了要转发的受保护路径，但它穿越了某些迂回路径希望避免的节点，则应发送路径错误以响应无法合并的迂回路径。
R7---R8---R9-\
| | | \
R1---R2---R3---R4---R5---R6
R7---R8---R9-\
| | | \
R1---R2---R3---R4---R5---R6
Protected LSP: [R1->R2->R3->R4->R5->R6]
R2's Detour: [R2->R7->R8->R9->R4->R5->R6]
R3's Detour: [R3->R8->R9->R5->R6]
Protected LSP: [R1->R2->R3->R4->R5->R6]
R2's Detour: [R2->R7->R8->R9->R4->R5->R6]
R3's Detour: [R3->R8->R9->R5->R6]
Example 4. Path Message Merging
例4。路径消息合并
In Example 4, R8 will receive Path messages that have the same SESSION and SENDER_TEMPLATE from detours for R2 and R3. During merging at R8, because detour R3 has a shorter ERO path length (that is, ERO is [R9->R5->R6], and path length is 3), R8 will select it as the final LSP and will only propagate its Path messages downstream. Upon receiving a Resv (or a ResvTear) message, R8 must relay the messages toward both R2 and R3.
在示例4中，R8将从R2和R3的迂回路线接收具有相同会话和发送者_模板的路径消息。在R8处合并期间，由于绕道R3的ERO路径长度较短（即ERO为[R9->R5->R6]，路径长度为3），因此R8将选择它作为最终LSP，并且只向下游传播其路径消息。接收到Resv（或ResvTear）消息后，R8必须向R2和R3中继消息。
R5 has to merge as well, and it will select the main LSP, since it has the FAST_REROUTE object. Thus, the detour LSP terminates at R5.
R5也必须合并，并且它将选择主LSP，因为它有FAST_REROUTE对象。因此，迂回LSP终止于R5。
When an LSR receives a ResvTear for an LSP, the LSR must determine whether it has an alternate associated LSP. For instance, if the ResvTear was received for a protected LSP but an associated backup LSP has not received a ResvTear, then the LSR has an alternate associated LSP. If the LSR does not have an alternate associated LSP, then the MP MUST propagate the ResvTear toward the LSP's ingress, and, for each backup LSP merged into that LSP at this LSR, the ResvTear SHOULD also be propagated along the backup LSP.
当LSR收到LSP的ResvTear时，LSR必须确定其是否具有备用关联LSP。例如，如果收到受保护LSP的ResvTear，但关联的备份LSP尚未收到ResvTear，则LSR具有备用关联LSP。如果LSR没有备用关联LSP，则MP必须向LSP入口传播ResvTear，并且，对于在该LSR处合并到该LSP中的每个备份LSP，ResvTear也应沿备份LSP传播。
The MP may receive PathTear messages for some of the merging LSPs. PathTear messages SHOULD NOT be propagated downstream until the MP has received PathTear messages for each of the merged LSPs. However, the fact that one or more of the merged LSPs has been torn down should be reflected in the downstream message, such as by changing the DETOUR object, if there is one.
MP可能会接收一些合并LSP的Path撕裂消息。在MP接收到每个合并LSP的PathTear消息之前，不应向下游传播PathTear消息。但是，一个或多个合并的LSP已被拆除的事实应反映在下游消息中，例如通过更改迂回对象（如果存在）来反映。
When a downstream LSR detects a local link failure, for any protected LSPs routed over the failed link, Path and Resv state MUST NOT be cleared, and PathTear and ResvErr messages MUST NOT be sent immediately. If this is not the case, then the facility backup method will not work. Furthermore, a downstream LSR SHOULD reset the
当下游LSR检测到本地链路故障时，对于通过故障链路路由的任何受保护LSP，不得清除Path和Resv状态，也不得立即发送PATHTRARE和ResvErr消息。如果不是这样，那么设施备份方法将不起作用。此外，下游LSR应重置
refresh timers for these LSPs as if they had just been refreshed. This is to allow time for the PLR to begin refreshing state via the bypass tunnel. State MUST be removed if it has not been refreshed before the refresh timer expires. This allows the facility backup method to work without requiring that it signal backup paths through the bypass tunnel before failure.
刷新这些LSP的计时器，就像它们刚刚被刷新一样。这是为了让PLR有时间通过旁通通道开始刷新状态。如果在刷新计时器过期之前未刷新状态，则必须将其删除。这使得设施备份方法能够工作，而无需在故障前通过旁通隧道向备份路径发送信号。
After a failure has occurred, the MP must still send Resv messages for the backup LSPs associated with the protected LSPs that have failed. If the backup LSP was sent through a bypass tunnel, then the PHOP object in its Path message will have the IP address of the associated PLR. This will ensure that Resv state is refreshed.
发生故障后，MP仍必须为与发生故障的受保护LSP关联的备份LSP发送Resv消息。如果备份LSP是通过旁路隧道发送的，则其Path消息中的PHOP对象将具有相关PLR的IP地址。这将确保刷新Resv状态。
Once the local link has recovered, the MP may or may not accept Path messages for existing protected LSPs that had failed over to their backup.
本地链路恢复后，MP可能会也可能不会接受故障转移到其备份的现有受保护LSP的路径消息。
The objects and methods defined in this document require behavior from all LSRs in the traffic-engineered network, even if an LSR is not along the path of a protected LSP.
本文档中定义的对象和方法需要流量工程网络中所有LSR的行为，即使LSR不在受保护LSP的路径上。
First, if a DETOUR object is included in the backup LSP's path message for the sender template-specific method, the LSRs in the traffic-engineered network should support the DETOUR object.
首先，如果发送方模板特定方法的备份LSP路径消息中包含迂回对象，则流量工程网络中的LSR应支持迂回对象。
Second, if the path-specific method is to be supported for the one-to-one backup method, it is necessary that the LSRs in the traffic-engineered network be capable of merging detours as specified in Section 8.1.
其次，如果一对一备份方法支持路径特定方法，则交通工程网络中的LSR必须能够按照第8.1节的规定合并绕道。
It is possible to avoid specific LSRs that do not support this behavior by assigning a link attribute to all the links of those LSPs and then requesting that backup paths exclude this link attribute.
通过为这些LSP的所有链接分配链接属性，然后请求备份路径排除此链接属性，可以避免不支持此行为的特定LSR。
If multiple Path Messages for different detours are received with the same SESSION, SENDER_TEMPLATE, outgoing interface, and next-hop LSR, then the LSR must function as a Detour Merge Point and merge the detour Path Messages. This merging should occur as specified in Section 7.1.2 and shown in Example 4.
如果使用同一会话、发送方\模板、传出接口和下一跳LSR接收到不同绕行的多条路径消息，则LSR必须用作绕行合并点并合并绕行路径消息。该合并应按照第7.1.2节的规定和示例4所示进行。
In addition, it is necessary to update the DETOUR object to reflect the merging that has taken place. This is done using the following algorithm to format the outgoing DETOUR object for the final LSP:
此外，有必要更新迂回对象以反映已发生的合并。使用以下算法为最终LSP格式化传出绕行对象：
- Combine all the (PLR_ID, Avoid_Node_ID) pairs from all the DETOUR objects of all merged LSPs into a new object. Ordering is insignificant.
- 将所有合并LSP的所有迂回对象中的所有（PLR_ID、回避_节点_ID）对合并为一个新对象。排序无关紧要。
This document does not introduce new security issues. The security considerations pertaining to the original RSVP protocol [RSVP] remain relevant.
本文档不会引入新的安全问题。与原始RSVP协议[RSVP]相关的安全注意事项仍然相关。
Note that the facility backup method requires that a PLR and its selected merge point trust RSVP messages received from each other.
请注意，设施备份方法要求PLR及其所选合并点信任从彼此接收的RSVP消息。
IANA [RFC-IANA] has assigned the following RSVP Class Numbers for objects defined in this document.
IANA[RFC-IANA]已为本文档中定义的对象分配了以下RSVP类编号。
IANA has assigned:
IANA已分配：
63 DETOUR
63绕道
Class Types or C-Types:
类别类型或C类型：
7 IPv4 8 IPv6
7 IPv4 8 IPv6
Future C-Types will be assigned using the following guidelines:
未来的C类型将使用以下指南进行分配：
C-Types 0 through 127 are assigned by Standards Action.
C类型0到127由标准行动分配。
C-Types 128 through 191 are assigned by Expert Review.
C型128至191由专家评审分配。
C-Types 192 through 255 are reserved for Vendor Private Use.
C型192至255保留供供应商私人使用。
For C-Types in the range 192 through 255, the first four octets of the DETOUR object after the C-Type must be the Vendor's SMI Network Management Private Enterprise Code (see [ENT]) in network byte order.
对于范围从192到255的C-Type，C-Type之后的迂回对象的前四个八位字节必须是供应商的SMI网络管理专用企业代码（请参见[ENT]），按网络字节顺序排列。
IANA has assigned:
IANA已分配：
205 FAST_REROUTE
205快速重新路由
Class Types or C-Types:
类别类型或C类型：
1 FAST_REROUTE Type 1 7 RESERVED
1快速路由类型1 7保留
In the FAST_REROUTE object, C-Type 7 is reserved as it is still used by pre-standard implementations. Future C-Types will be assigned using the following guidelines:
在FAST_REROUTE对象中，C-type7是保留的，因为它仍然被标准前的实现使用。未来的C类型将使用以下指南进行分配：
C-Types 0 through 127 are assigned by Standards Action.
C类型0到127由标准行动分配。
C-Types 128 through 191 are assigned by Expert Review.
C型128至191由专家评审分配。
C-Types 192 through 255 are reserved for Vendor Private Use.
C型192至255保留供供应商私人使用。
For C-Types in the range 192 through 255, the first four octets of the FAST_REROUTE object after the C-Type must be the Vendor's SMI Network Management Private Enterprise Code (see [ENT]) in network byte order.
对于范围从192到255的C类型，C类型之后的FAST_REROUTE对象的前四个八位字节必须是供应商的SMI网络管理专用企业代码（请参见[ENT]），按网络字节顺序排列。
This document was written by George Swallow, Ping Pan, Alia Atlas, Jean Philippe Vasseur, Markus Jork, Der-Hwa Gan, and Dave Cooper.
本文件由乔治·斯沃恩、潘平、艾莉亚·阿特拉斯、让·菲利普·瓦瑟尔、马库斯·乔克、德华根和戴夫·库珀撰写。
Jean Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
Jean-Philippe Vasseur Cisco Systems，Inc.美国马萨诸塞州博克斯伯勒市海弗布鲁克路300号，邮编01719
Phone: +1 978 497 6238
EMail: jpv@cisco.com
Phone: +1 978 497 6238
EMail: jpv@cisco.com
Markus Jork Quarry Technologies 8 New England Executive Park Burlington, MA 01803 USA
美国马萨诸塞州伯灵顿市新英格兰行政公园8号马库斯·乔克采石场技术公司01803
Phone: +1 781 359 5071
EMail: mjork@quarrytech.com
Phone: +1 781 359 5071
EMail: mjork@quarrytech.com
Der-Hwa Gan Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 USA
美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号德华根杜松网络公司，邮编94089
Phone: +1 408 745 2074
EMail: dhg@juniper.net
Phone: +1 408 745 2074
EMail: dhg@juniper.net
Dave Cooper Global Crossing 960 Hamlin Court Sunnyvale, CA 94089 USA
美国加利福尼亚州桑尼维尔哈姆林法院960号戴夫·库珀环球交叉路口，邮编94089
Phone: +1 916 415 0437
EMail: dcooper@gblx.net
Phone: +1 916 415 0437
EMail: dcooper@gblx.net
We would like to acknowledge input and helpful comments from Rob Goguen, Tony Li, Yakov Rekhter and Curtis Villamizar. Especially, we thank those, who have been involved in interoperability testing and field trails, and provided invaluable ideas and suggestions. They are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan, Richard Southern, and Bijan Jabbari.
我们感谢Rob Goguen、Tony Li、Yakov Rekhter和Curtis Villamizar的意见和帮助。我们特别感谢那些参与互操作性测试和现场试验并提供宝贵意见和建议的人。他们是罗布·高根、卡罗尔·伊图拉尔德、布鲁克·贝利、萨法·哈桑、理查德·南特和比扬·贾巴里。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RSVP-TE]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-WORDS]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC-IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC-IANA]Narten，T.和H.Alvestrand，“在RFC中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[ENT] IANA PRIVATE ENTERPRISE NUMBERS,
http://www.iana.org/assignments/enterprise-numbers
[ENT] IANA PRIVATE ENTERPRISE NUMBERS,
http://www.iana.org/assignments/enterprise-numbers
Authors' Addresses
作者地址
George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
George Swallow Cisco Systems，Inc.美国马萨诸塞州Boxborough市比弗布鲁克路300号，邮编01719
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Ping Pan Hammerhead Systems 640 Clyde Court Mountain View, CA 94043 USA
平盘锤头系统美国加利福尼亚州克莱德苑山景640号，邮编94043
EMail: ppan@hammerheadsystems.com
EMail: ppan@hammerheadsystems.com
Alia Atlas Avici Systems 101 Billerica Avenue N. Billerica, MA 01862 USA
Alia Atlas Avici Systems 101美国马萨诸塞州比勒里卡大道N.比勒里卡01862号
Phone: +1 978 964 2070
EMail: aatlas@avici.com
Phone: +1 978 964 2070
EMail: aatlas@avici.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。