Network Working Group J.P. Lang, Ed.
Request for Comments: 4872 Sonos
Updates: 3471 Y. Rekhter, Ed.
Category: Standards Track Juniper
D. Papadimitriou, Ed.
Alcatel
May 2007
Network Working Group J.P. Lang, Ed.
Request for Comments: 4872 Sonos
Updates: 3471 Y. Rekhter, Ed.
Category: Standards Track Juniper
D. Papadimitriou, Ed.
Alcatel
May 2007
RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery
支持端到端通用多协议标签交换（GMPLS）恢复的RSVP-TE扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426.
本文档描述了通用多协议标签交换（GMPLS）资源预留协议-流量工程（RSVP-TE）信令的协议特定程序和扩展，以支持表示保护和恢复的端到端标签交换路径（LSP）恢复。有关GMPLS恢复的一般功能说明，请参阅配套文件RFC 4426。
Table of Contents
目录
1. Introduction .....................................................3
2. Conventions Used in This Document ...............................5
3. Relationship to Fast Reroute (FRR) ..............................5
4. Definitions .....................................................6
4.1. LSP Identification .........................................6
4.2. Recovery Attributes ........................................7
4.2.1. LSP Status ..........................................7
4.2.2. LSP Recovery ........................................8
4.3. LSP Association ............................................9
5. 1+1 Unidirectional Protection ...................................9
5.1. Identifiers ...............................................10
1. Introduction .....................................................3
2. Conventions Used in This Document ...............................5
3. Relationship to Fast Reroute (FRR) ..............................5
4. Definitions .....................................................6
4.1. LSP Identification .........................................6
4.2. Recovery Attributes ........................................7
4.2.1. LSP Status ..........................................7
4.2.2. LSP Recovery ........................................8
4.3. LSP Association ............................................9
5. 1+1 Unidirectional Protection ...................................9
5.1. Identifiers ...............................................10
6. 1+1 Bidirectional Protection ...................................10
6.1. Identifiers ...............................................11
6.2. End-to-End Switchover Request/Response ....................11
7. 1:1 Protection with Extra-Traffic ..............................13
7.1. Identifiers ...............................................14
7.2. End-to-End Switchover Request/Response ....................15
7.3. 1:N (N > 1) Protection with Extra-Traffic .................16
8. Rerouting without Extra-Traffic ................................17
8.1. Identifiers ...............................................19
8.2. Signaling Primary LSPs ....................................19
8.3. Signaling Secondary LSPs ..................................19
9. Shared-Mesh Restoration ........................................20
9.1. Identifiers ...............................................22
9.2. Signaling Primary LSPs ....................................22
9.3. Signaling Secondary LSPs ..................................23
10. LSP Preemption ................................................23
11. (Full) LSP Rerouting ..........................................25
11.1. Identifiers ..............................................25
11.2. Signaling Reroutable LSPs ................................26
12. Reversion .....................................................26
13. Recovery Commands .............................................29
14. PROTECTION Object .............................................31
14.1. Format ...................................................31
14.2. Processing ...............................................33
15. PRIMARY_PATH_ROUTE Object .....................................33
15.1. Format ...................................................34
15.2. Subobjects ...............................................34
15.3. Applicability ............................................35
15.4. Processing ...............................................36
16. ASSOCIATION Object ............................................37
16.1. Format ...................................................37
16.2. Processing ...............................................38
17. Updated RSVP Message Formats ..................................39
18. Security Considerations .......................................40
19. IANA Considerations ...........................................41
20. Acknowledgments ...............................................43
21. References ....................................................43
21.1. Normative References .....................................43
21.2. Informative References ...................................44
22. Contributors ..................................................45
6. 1+1 Bidirectional Protection ...................................10
6.1. Identifiers ...............................................11
6.2. End-to-End Switchover Request/Response ....................11
7. 1:1 Protection with Extra-Traffic ..............................13
7.1. Identifiers ...............................................14
7.2. End-to-End Switchover Request/Response ....................15
7.3. 1:N (N > 1) Protection with Extra-Traffic .................16
8. Rerouting without Extra-Traffic ................................17
8.1. Identifiers ...............................................19
8.2. Signaling Primary LSPs ....................................19
8.3. Signaling Secondary LSPs ..................................19
9. Shared-Mesh Restoration ........................................20
9.1. Identifiers ...............................................22
9.2. Signaling Primary LSPs ....................................22
9.3. Signaling Secondary LSPs ..................................23
10. LSP Preemption ................................................23
11. (Full) LSP Rerouting ..........................................25
11.1. Identifiers ..............................................25
11.2. Signaling Reroutable LSPs ................................26
12. Reversion .....................................................26
13. Recovery Commands .............................................29
14. PROTECTION Object .............................................31
14.1. Format ...................................................31
14.2. Processing ...............................................33
15. PRIMARY_PATH_ROUTE Object .....................................33
15.1. Format ...................................................34
15.2. Subobjects ...............................................34
15.3. Applicability ............................................35
15.4. Processing ...............................................36
16. ASSOCIATION Object ............................................37
16.1. Format ...................................................37
16.2. Processing ...............................................38
17. Updated RSVP Message Formats ..................................39
18. Security Considerations .......................................40
19. IANA Considerations ...........................................41
20. Acknowledgments ...............................................43
21. References ....................................................43
21.1. Normative References .....................................43
21.2. Informative References ...................................44
22. Contributors ..................................................45
Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to include support for Layer-2 Switch Capable (L2SC), Time-Division Multiplex (TDM), Lambda Switch Capable (LSC), and Fiber Switch Capable (FSC) interfaces. GMPLS recovery uses control plane mechanisms (i.e., signaling, routing, and link management mechanisms) to support data plane fault recovery. Note that the analogous (data plane) fault detection mechanisms are required to be present in support of the control plane mechanisms. In this document, the term "recovery" is generically used to denote both protection and restoration; the specific terms "protection" and "restoration" are only used when differentiation is required. The subtle distinction between protection and restoration is made based on the resource allocation done during the recovery phase (see [RFC4427]).
通用多协议标签交换（GMPLS）扩展了MPLS，包括支持第二层交换机（L2SC）、时分复用（TDM）、Lambda交换机（LSC）和光纤交换机（FSC）接口。GMPLS恢复使用控制平面机制（即信令、路由和链路管理机制）支持数据平面故障恢复。请注意，需要提供类似（数据平面）故障检测机制以支持控制平面机制。在本文件中，“恢复”一词一般用于表示保护和恢复；特定术语“保护”和“恢复”仅在需要区分时使用。保护和恢复之间的细微区别基于恢复阶段完成的资源分配（请参见[RFC4427]）。
A functional description of GMPLS recovery is provided in [RFC4426] and should be considered as a companion document. The present document describes the protocol-specific procedures for GMPLS RSVP-TE (Resource ReSerVation Protocol - Traffic Engineering) signaling (see [RFC3473]) to support end-to-end recovery. End-to-end recovery refers to the recovery of an entire LSP from its head-end (ingress node endpoint) to its tail-end (egress node endpoint). With end-to-end recovery, working LSPs are assumed to be resource-disjoint (where a resource is a link, node, or Shared Risk Link Group (SRLG)) in the network so that they do not share any failure probability, but this is not mandatory. With respect to a given set of network resources, a pair of working/protecting LSPs SHOULD be resource disjoint in case of dedicated recovery type (see below). On the other hand, in case of shared recovery (see below), a group of working LSPs SHOULD be mutually resource-disjoint in order to allow for a (single and commonly) shared protecting LSP, itself resource-disjoint from each of the working LSPs. Note that resource disjointness is a necessary (but not sufficient) condition to ensure LSP recoverability.
[RFC4426]中提供了GMPLS恢复的功能说明，应将其视为配套文件。本文件描述了GMPLS RSVP-TE（资源预留协议-流量工程）信令（参见[RFC3473]）的协议特定程序，以支持端到端恢复。端到端恢复是指将整个LSP从其前端（入口节点端点）恢复到其后端（出口节点端点）。对于端到端恢复，工作LSP被假定为网络中的资源不相交（其中资源是链路、节点或共享风险链路组（SRLG）），因此它们不会共享任何故障概率，但这不是强制性的。对于给定的一组网络资源，在专用恢复类型的情况下，一对工作/保护LSP应该是资源不相交的（见下文）。另一方面，在共享恢复（见下文）的情况下，一组工作LSP应该是相互资源不相交的，以便允许（单个和常见的）共享保护LSP，其自身资源与每个工作LSP不相交。请注意，资源不相交是确保LSP可恢复性的必要（但不是充分）条件。
The present document addresses four types of end-to-end LSP recovery: 1) 1+1 (unidirectional/bidirectional) protection, 2) 1:N (N >= 1) LSP protection with extra-traffic, 3) pre-planned LSP rerouting without extra-traffic (including shared mesh), and 4) full LSP rerouting.
本文档介绍了四种类型的端到端LSP恢复：1）1+1（单向/双向）保护，2）1:N（N>=1）具有额外流量的LSP保护，3）没有额外流量的预先计划的LSP重路由（包括共享网格），以及4）完全LSP重路由。
1) The simplest notion of end-to-end LSP protection is 1+1 unidirectional protection. Using this type of protection, a protecting LSP is signaled over a dedicated resource-disjoint alternate path to protect an associated working LSP. Normal traffic is simultaneously sent on both LSPs and a selector is used at the egress node to receive traffic from one of the LSPs. If a failure occurs along one of the LSPs, the egress node selects the
1) 端到端LSP保护的最简单概念是1+1单向保护。使用这种类型的保护，通过专用资源不相交的备用路径向保护LSP发送信号，以保护相关的工作LSP。在两个LSP上同时发送正常流量，并且在出口节点处使用选择器来接收来自其中一个LSP的流量。如果沿其中一个LSP发生故障，则出口节点选择
traffic from the valid LSP. No coordination is required between the end nodes when a failure/switchover occurs.
来自有效LSP的流量。发生故障/切换时，端节点之间不需要协调。
In 1+1 bidirectional protection, a protecting LSP is signaled over a dedicated resource-disjoint alternate path to protect the working LSP. Normal traffic is simultaneously sent on both LSPs (in both directions), and a selector is used at both ingress/egress nodes to receive traffic from the same LSP. This requires coordination between the end-nodes when switching to the protecting LSP.
在1+1双向保护中，保护LSP通过专用资源不相交的备用路径发送信号，以保护工作LSP。在两个LSP上（在两个方向上）同时发送正常流量，并且在两个入口/出口节点处使用选择器来接收来自同一LSP的流量。这需要终端节点在切换到保护LSP时进行协调。
2) In 1:N (N >= 1) protection with extra-traffic, the protecting LSP is a fully provisioned and resource-disjoint LSP from the N working LSPs, that allows for carrying extra-traffic. The N working LSPs MAY be mutually resource-disjoint. Coordination between end-nodes is required when switching from one of the working LSPs to the protecting LSP. As the protecting LSP is fully provisioned, default operations during protection switching are specified for a protecting LSP carrying extra-traffic, but this is not mandatory. Note that M:N protection is out of scope of this document (though mechanisms it defines may be extended to cover it).
2) 在具有额外流量的1:N（N>=1）保护中，保护LSP是一个完全配置且资源与N个工作LSP不相交的LSP，允许承载额外流量。N个工作lsp可以是相互不相交的。从一个工作LSP切换到保护LSP时，需要端节点之间的协调。由于完全配置了保护LSP，因此为承载额外流量的保护LSP指定了保护切换期间的默认操作，但这不是强制性的。请注意，M:N保护不在本文档的范围内（尽管它定义的机制可能会扩展以涵盖它）。
3) Pre-planned LSP rerouting (or restoration) relies on the establishment between the same pair of end-nodes of a working LSP and a protecting LSP that is link/node/SRLG disjoint from the working one. Here, the recovery resources for the protecting LSP are pre-reserved but explicit action is required to activate (i.e., commit resource allocation at the data plane) a specific protecting LSP instantiated during the (pre-)provisioning phase. Since the protecting LSP is not "active" (i.e., fully instantiated), it cannot carry any extra-traffic. This does not mean that the corresponding resources cannot be used by other LSPs. Therefore, this mechanism protects against working LSP(s) failure(s) but requires activation of the protecting LSP after working LSP failure occurrence. This requires restoration signaling along the protecting path. "Shared-mesh" restoration can be seen as a particular case of pre-planned LSP rerouting that reduces the recovery resource requirements by allowing multiple protecting LSPs to share common link and node resources. The recovery resources are pre-reserved but explicit action is required to activate (i.e., commit resource allocation at the data plane) a specific protecting LSP instantiated during the (pre-) provisioning phase. This procedure requires restoration signaling along the protecting path.
3) 预先计划的LSP重路由（或恢复）依赖于在工作LSP的同一对终端节点和链路/节点/SRLG与工作LSP不相交的保护LSP之间建立。这里，保护LSP的恢复资源是预保留的，但需要显式操作来激活（即，在数据平面上提交资源分配）在（预）配置阶段实例化的特定保护LSP。由于保护LSP不是“活动的”（即完全实例化），因此它不能承载任何额外的流量。这并不意味着其他LSP不能使用相应的资源。因此，该机制可防止工作LSP故障，但需要在工作LSP故障发生后激活保护LSP。这需要沿保护路径发送恢复信令。“共享网格”恢复可以看作是预先计划的LSP重新路由的一种特殊情况，它通过允许多个保护LSP共享公共链路和节点资源来减少恢复资源需求。恢复资源是预保留的，但需要显式操作来激活（即，在数据平面上提交资源分配）在（预）配置阶段实例化的特定保护LSP。此过程需要沿保护路径发送恢复信令。
Note that in both cases, bandwidth pre-reserved for a protecting (but not activated) LSP can be made available for carrying extra traffic. LSPs for extra-traffic (with lower holding priority than the protecting LSP) can then be established using the bandwidth pre-reserved for the protecting LSP. Also, any lower priority LSP that use the pre-reserved resources for the protecting LSP(s) must be preempted during the activation of the protecting LSP.
请注意，在这两种情况下，为保护（但未激活）LSP预留的带宽可用于承载额外流量。然后，可以使用为保护LSP预先保留的带宽来建立额外流量的LSP（保持优先级低于保护LSP）。此外，在激活保护LSP期间，必须抢占使用预保留资源用于保护LSP的任何低优先级LSP。
4) Full LSP rerouting (or restoration) switches normal traffic to an alternate LSP that is not even partially established until after the working LSP failure occurs. The new alternate route is selected at the LSP head-end node, it may reuse resources of the failed LSP at intermediate nodes and may include additional intermediate nodes and/or links.
4) 完全LSP重新路由（或恢复）将正常通信量切换到备用LSP，该备用LSP在工作LSP故障发生之前甚至未部分建立。在LSP头端节点处选择新的备用路由，它可以在中间节点处重用失败的LSP的资源，并且可以包括额外的中间节点和/或链路。
Crankback signaling (see [CRANK]) and LSP segment recovery (see [RFC4873]) are further detailed in dedicated companion documents.
回退信令（见[CRANK]）和LSP段恢复（见[RFC4873]）在专用配套文件中有进一步详细说明。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In addition, the reader is assumed to be familiar with the terminology used in [RFC3945], [RFC3471], [RFC3473] and referenced as well as in [RFC4427] and [RFC4426].
此外，假定读者熟悉[RFC3945]、[RFC3471]、[RFC3473]中使用和引用的术语以及[RFC4427]和[RFC4426]中的术语。
There is no impact to RSVP-TE Fast Reroute (FRR) [RFC4090] introduced by end-to-end GMPLS recovery i.e., it is possible to use either method defined in FRR with end-to-end GMPLS recovery.
对端到端GMPLS恢复引入的RSVP-TE快速重路由（FRR）[RFC4090]没有影响，即可以使用FRR中定义的任何一种方法进行端到端GMPLS恢复。
The objects used and/or newly introduced by end-to-end recovery will be ignored by [RFC4090] conformant implementations, and FRR can operate on a per LSP basis as defined in [RFC4090].
[RFC4090]一致性实现将忽略端到端恢复使用和/或新引入的对象，并且FRR可以按照[RFC4090]中定义的每个LSP进行操作。
This section reviews terms previously defined in [RFC2205], [RFC3209], and [RFC3473]. LSP tunnels are identified by a combination of the SESSION and SENDER_TEMPLATE objects (see also [RFC3209]). The relevant fields are as follows:
本节回顾了[RFC2205]、[RFC3209]和[RFC3473]中先前定义的术语。LSP隧道由会话和发送方模板对象的组合标识（另请参见[RFC3209]）。相关字段如下所示：
IPv4 (or IPv6) tunnel endpoint 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 (or 16-byte) identifier used in the SESSION that remains constant over the life of the tunnel. Normally set to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-egress pair MAY place their IPv4 (or IPv6) address here as a globally unique identifier.
会话中使用的32位（或16字节）标识符，在隧道的整个生命周期内保持不变。通常设置为全零。希望将会话范围缩小到入口-出口对的入口节点可以在此处将其IPv4（或IPv6）地址作为全局唯一标识符。
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 FILTER_SPEC that can be changed to allow a sender to share resources with itself.
发送方模板和筛选器规范中使用的16位标识符，可以更改以允许发送方与其自身共享资源。
The first three fields are carried in the SESSION object (Path and Resv message) and constitute the basic identification of the LSP tunnel.
前三个字段包含在会话对象（Path和Resv消息）中，构成LSP隧道的基本标识。
The last two fields are carried in the SENDER_TEMPLATE (Path message) and FILTER_SPEC objects (Resv message). The LSP ID is used to differentiate LSPs that belong to the same LSP Tunnel (as identified by its Tunnel ID).
最后两个字段包含在SENDER_模板（路径消息）和FILTER_SPEC对象（Resv消息）中。LSP ID用于区分属于同一LSP隧道（由其隧道ID标识）的LSP。
The recovery attributes include all the parameters that determine the status of an LSP within the recovery scheme to which it is associated. These attributes are part of the PROTECTION object introduced in Section 14.
恢复属性包括所有参数，这些参数确定与LSP关联的恢复方案中LSP的状态。这些属性是第14节中介绍的保护对象的一部分。
The following bits are used in determining resource allocation and status of the LSP within the group of LSPs forming the protected entity:
以下比特用于确定构成受保护实体的LSP组内LSP的资源分配和状态：
- S (Secondary) bit: enables distinction between primary and secondary LSPs. A primary LSP is a fully established LSP for which the resource allocation has been committed at the data plane (i.e., full cross-connection has been performed). Both working and protecting LSPs can be primary LSPs. A secondary LSP is an LSP that has been provisioned in the control plane only, and for which resource selection MAY have been done but for which the resource allocation has not been committed at the data plane (for instance, no cross-connection has been performed). Therefore, a secondary LSP is not immediately available to carry any traffic (thus requiring additional signaling to be available). A secondary LSP can only be a protecting LSP. The (data plane) resources allocated for a secondary LSP MAY be used by other LSPs until the primary LSP fails over to the secondary LSP.
- S（辅助）位：启用主LSP和辅助LSP之间的区别。主LSP是完全建立的LSP，其资源分配已在数据平面上提交（即，已执行完全交叉连接）。工作LSP和保护LSP都可以是主LSP。辅助LSP是仅在控制平面中设置的LSP，并且可能已经对其进行了资源选择，但是尚未在数据平面上提交资源分配（例如，没有执行交叉连接）。因此，次要LSP不能立即用于承载任何业务（因此需要额外的信令可用）。辅助LSP只能是保护LSP。分配给次要LSP的（数据平面）资源可由其他LSP使用，直到主要LSP故障转移到次要LSP为止。
- P (Protecting) bit: enables distinction between working and protecting LSPs. A working LSP must be a primary LSP whilst a protecting LSP can be either a primary or a secondary LSP. When protecting LSP(s) are associated with working LSP(s), one also refers to the latter as protected LSPs.
- P（保护）位：允许区分工作LSP和保护LSP。工作LSP必须是主LSP，而保护LSP可以是主LSP或辅助LSP。当保护LSP与工作LSP关联时，也可将后者称为受保护LSP。
Note: The combination "secondary working" is not valid (only protecting LSPs can be secondary LSPs). Working LSPs are always primary LSPs (i.e., fully established) whilst primary LSPs can be either working or protecting LSPs.
注：“二次加工”组合无效（只有保护LSP可以是二次LSP）。工作LSP始终是主LSP（即完全建立），而主LSP可以是工作LSP，也可以是保护LSP。
- O (Operational) bit: this bit is set when a protecting LSP is carrying the normal traffic after protection switching (i.e., applies only in case of dedicated LSP protection or LSP protection with extra-traffic; see Section 4.2.2).
- O（操作）位：当保护LSP在保护切换后承载正常流量时设置该位（即，仅适用于专用LSP保护或具有额外流量的LSP保护；参见第4.2.2节）。
In this document, the PROTECTION object uses as a basis the PROTECTION object defined in [RFC3471] and [RFC3473] and defines additional fields within it. The fields defined in [RFC3471] and [RFC3473] are unchanged by this document.
在本文件中，保护对象使用[RFC3471]和[RFC3473]中定义的保护对象作为基础，并在其中定义其他字段。[RFC3471]和[RFC3473]中定义的字段不受本文档的影响。
The following classification is used to distinguish the LSP Protection Type with which LSPs can be associated at end-nodes (a distinct value is associated with each Protection Type in the PROTECTION object; see Section 14):
以下分类用于区分LSP保护类型，LSP可在终端节点与之关联（不同的值与保护对象中的每个保护类型关联；参见第14节）：
- Full LSP Rerouting: set if a primary working LSP is dynamically recoverable using (non pre-planned) head-end rerouting.
- 完全LSP重路由：设置主工作LSP是否可以使用（非预先计划的）头端重路由动态恢复。
- Pre-planned LSP Rerouting without Extra-traffic: set if a protecting LSP is a secondary LSP that allows sharing of the pre-reserved recovery resources between one or more than one <sender;receiver> pair. When the secondary LSPs resources are not pre-reserved for a single <sender;receiver> pair, this type is referred to as "shared mesh" recovery.
- 无额外通信量的预先计划的LSP重新路由：如果保护LSP是允许在一个或多个发送方之间共享预先保留的恢复资源的辅助LSP，则设置；接收器>配对。当辅助LSP资源未预先保留给单个发送方时；接收器>配对，这种类型称为“共享网格”恢复。
- LSP Protection with Extra-traffic: set if a protecting LSP is a dedicated primary LSP that allows for extra-traffic transport and thus precludes any sharing of the recovery resources between more than one <sender;receiver> pair. This type includes 1:N LSP protection with extra-traffic.
- 具有额外流量的LSP保护：如果保护LSP是一个专用的主LSP，允许额外流量传输，从而阻止多个发送方之间共享恢复资源，则设置该保护；接收器>配对。这种类型包括1:N LSP保护和额外流量。
- Dedicated LSP Protection: set if a protecting LSP does not allow sharing of the recovery resources nor the transport of extra-traffic (implying in the present context, duplication of the signal over both working and protecting LSPs as in 1+1 dedicated protection). Note also that this document makes a distinction between 1+1 unidirectional and bidirectional dedicated LSP protection.
- 专用LSP保护：如果保护LSP不允许共享恢复资源或传输额外流量（在当前上下文中，这意味着在工作和保护LSP上复制信号，如1+1专用保护中所述），则设置专用LSP保护。还要注意，本文件对1+1单向和双向专用LSP保护进行了区分。
For LSP protection, in particular, when the data plane provides automated protection-switching capability (see for instance ITU-T [G.841] Recommendation), a Notification (N) bit is defined in the PROTECTION object. It allows for distinction between protection switching signaling via the control plane or the data plane.
对于LSP保护，尤其是当数据平面提供自动保护交换能力（例如，参见ITU-T[G.841]建议）时，在保护对象中定义通知（N）位。它允许通过控制平面或数据平面区分保护切换信号。
Note: this document assumes that Protection Type values have end-to-end significance and that the same value is sent over the protected and the protecting path. In this context, shared-mesh (for instance) appears from the end-nodes perspective as being simply an LSP rerouting without extra-traffic services. The net result of this is that a single bit (the S bit alone) does not allow determining whether resource allocation should be performed with respect to the status of the LSP within the protected entity. The introduction of the P bit solves this problem unambiguously. These bits MUST be processed on a hop-by-hop basis (independently of the LSP Protection Type context). This allows for an easier implementation of reversion
注意：本文档假设保护类型值具有端到端的重要性，并且在受保护路径和保护路径上发送相同的值。在这种情况下，从终端节点的角度来看，共享网格（例如）只是一个LSP重路由，没有额外的流量服务。这样做的最终结果是，单个位（仅S位）不允许确定是否应针对受保护实体内的LSP状态执行资源分配。P位的引入明确地解决了这个问题。必须逐跳处理这些位（独立于LSP保护类型上下文）。这允许更容易地实现恢复
signaling (see Section 12) but also facilitates the transparent delivery of protected services since any intermediate node is not required to know the semantics associated with the incoming LSP Protection Type value.
信令（参见第12节），但也有助于受保护服务的透明交付，因为任何中间节点都不需要知道与传入LSP保护类型值相关联的语义。
The ASSOCIATION object, introduced in Section 16, is used to associate the working and protecting LSPs.
第16节介绍的关联对象用于关联工作和保护LSP。
When used for signaling the working LSP, the Association ID of the ASSOCIATION object (see Section 16) identifies the protecting LSP. When used for signaling the protecting LSP, this field identifies the LSP protected by the protecting LSP.
当用于向工作LSP发信号时，关联对象的关联ID（参见第16节）标识保护LSP。当用于向保护LSP发送信号时，此字段标识受保护LSP保护的LSP。
One of the simplest notions of end-to-end LSP protection is 1+1 unidirectional protection.
端到端LSP保护的最简单概念之一是1+1单向保护。
Consider the following network topology:
考虑下面的网络拓扑：
A---B---C---D
\ /
E---F---G
A---B---C---D
\ /
E---F---G
The paths [A,B,C,D] and [A,E,F,G,D] are node and link disjoint, ignoring the ingress/egress nodes A and D. A 1+1 protected path is established from A to D over [A,B,C,D] and [A,E,F,G,D], and traffic is transmitted simultaneously over both component paths (i.e., LSPs).
路径[A、B、C、D]和[A、E、F、G、D]是节点和链路不相交的，忽略入口/出口节点A和D。通过[A、B、C、D]和[A、E、F、G、D]建立从A到D的1+1保护路径，并通过两个组件路径（即LSP）同时传输业务。
During the provisioning phase, both LSPs are fully instantiated (and thus activated) so that no resource sharing can be done along the protecting LSP (nor can any extra-traffic be transported). It is also RECOMMENDED to set the N bit since no protection-switching signaling is assumed in this case.
在供应阶段，两个LSP都被完全实例化（并因此被激活），这样就不能沿着保护LSP进行资源共享（也不能传输任何额外的流量）。还建议设置N位，因为在这种情况下假定没有保护切换信令。
When a failure occurs (say, at node B) and is detected at end-node D, the receiver at D selects the normal traffic from the other LSP. From this perspective, 1+1 unidirectional protection can be seen as an uncoordinated protection-switching mechanism acting independently at both endpoints. Also, for the LSP under failure condition, it is RECOMMENDED to not set the Path_State_Removed Flag of the ERROR_SPEC object (see [RFC3473]) upon PathErr message generation.
当发生故障（例如，在节点B处）并且在终端节点D处检测到故障时，D处的接收器从另一LSP选择正常业务。从这个角度来看，1+1单向保护可被视为在两个端点独立作用的不协调保护切换机制。此外，对于故障条件下的LSP，建议不要在生成PathErr消息时设置ERROR_SPEC对象的Path_State_Removed标志（请参见[RFC3473]）。
Note: it is necessary that both paths are SRLG disjoint to ensure recoverability; otherwise, a single failure may impact both working and protecting LSPs.
注意：两条路径必须是SRLG不相交的，以确保可恢复性；否则，单个故障可能会影响LSP的工作和保护。
To simplify association operations, both LSPs belong to the same session. Thus, the SESSION object MUST be the same for both LSPs. The LSP ID, however, MUST be different to distinguish between the two LSPs.
为了简化关联操作，两个LSP属于同一会话。因此，两个LSP的会话对象必须相同。但是，LSP ID必须不同才能区分这两个LSP。
A new PROTECTION object (see Section 14) is included in the Path message. This object carries the desired end-to-end LSP Protection Type -- in this case, "1+1 Unidirectional". This LSP Protection Type value is applicable to both uni- and bidirectional LSPs.
Path消息中包含一个新的保护对象（见第14节）。此对象携带所需的端到端LSP保护类型——在本例中为“1+1单向”。此LSP保护类型值适用于单向和双向LSP。
To allow distinguishing the working LSP (from which the signal is taken) from the protecting LSP, the working LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the protecting LSP_ID. The protecting LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated protected LSP_ID.
为了允许区分工作LSP（从中获取信号）和保护LSP，通过在保护对象中将S位设置为0，将P位设置为0，并在关联对象中设置，向工作LSP发送信号，保护LSP_ID的关联ID。通过在保护对象中将S位设置为0，将P位设置为1，以及在关联对象中将关联ID设置为关联的受保护LSP_ID，可以发出保护LSP的信号。
After protection switching completes, and after reception of the PathErr message, to keep track of the LSP from which the signal is taken, the protecting LSP SHOULD be signaled with the O bit set. The formerly working LSP MAY be signaled with the A bit set in the ADMIN_STATUS object (see [RFC3473]). This process assumes the tail-end node has notified the head-end node that traffic selection switchover has occurred.
保护切换完成后，在收到PathErr消息后，为了跟踪接收信号的LSP，应使用O位设置向保护LSP发送信号。以前工作的LSP可以用ADMIN_STATUS对象中设置的位发出信号（参见[RFC3473]）。此过程假定后端节点已通知前端节点已发生流量选择切换。
1+1 bidirectional protection is a scheme that provides end-to-end protection for bidirectional LSPs.
1+1双向保护是为双向LSP提供端到端保护的方案。
Consider the following network topology:
考虑下面的网络拓扑：
A---B---C---D
\ /
E---F---G
A---B---C---D
\ /
E---F---G
The LSPs [A,B,C,D] and [A,E,F,G,D] are node and link disjoint, ignoring the ingress/egress nodes A and D. A bidirectional LSP is established from A to D over each path, and traffic is transmitted simultaneously over both LSPs. In this scheme, both endpoints must receive traffic over the same LSP. Note also that both LSPs are fully instantiated (and thus activated) so that no resource sharing can be done along the protection path (nor can any extra-traffic be transported).
LSP[A、B、C、D]和[A、E、F、G、D]是节点和链路不相交的，忽略入口/出口节点A和D。在每个路径上从A到D建立双向LSP，并且在两个LSP上同时传输业务。在此方案中，两个端点必须通过相同的LSP接收流量。还请注意，这两个LSP都已完全实例化（并因此被激活），因此无法沿保护路径进行资源共享（也无法传输任何额外流量）。
When a failure is detected by one or both endpoints of the LSP, both endpoints must select traffic from the other LSP. This action must be coordinated between node A and D. From this perspective, 1+1 bidirectional protection can be seen as a coordinated protection-switching mechanism between both endpoints.
当LSP的一个或两个端点检测到故障时，两个端点都必须从另一个LSP选择流量。此操作必须在节点A和D之间协调。从这个角度来看，1+1双向保护可以看作是两个端点之间的协调保护切换机制。
Note: it is necessary that both paths are SRLG disjoint to ensure recoverability; otherwise, a single failure may impact both working and protecting LSPs.
注意：两条路径必须是SRLG不相交的，以确保可恢复性；否则，单个故障可能会影响LSP的工作和保护。
To simplify association operations, both LSPs belong to the same session. Thus, the SESSION object MUST be the same for both LSPs. The LSP ID, however, MUST be different to distinguish between the two LSPs.
为了简化关联操作，两个LSP属于同一会话。因此，两个LSP的会话对象必须相同。但是，LSP ID必须不同才能区分这两个LSP。
A new PROTECTION object (see Section 14) is included in the Path message. This object carries the desired end-to-end LSP Protection Type -- in this case, "1+1 Bidirectional". This LSP Protection Type value is only applicable to bidirectional LSPs.
Path消息中包含一个新的保护对象（见第14节）。此对象携带所需的端到端LSP保护类型——在本例中为“1+1双向”。此LSP保护类型值仅适用于双向LSP。
It is also desirable to allow distinguishing the working LSP (from which the signal is taken) from the protecting LSP. This is achieved for the working LSP by setting in the PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the protecting LSP_ID. The protecting LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object the Association ID to the associated protected LSP_ID.
还希望允许区分工作LSP（从中获取信号）和保护LSP。通过在保护对象中将S位设置为0，将P位设置为0，并在关联对象中将关联ID设置为保护LSP_ID来实现工作LSP。通过在保护对象中将S位设置为0，将P位设置为1，来发出保护LSP的信号，在关联对象中，将关联ID设置为关联的受保护LSP_ID。
To coordinate the switchover between endpoints, an end-to-end switchover request/response exchange is needed since a failure affecting one of the LSPs results in both endpoints switching to the other LSP (resulting in receiving traffic from the other LSP) in their respective directions.
为了协调端点之间的切换，需要进行端到端切换请求/响应交换，因为影响其中一个LSP的故障会导致两个端点在各自的方向上切换到另一个LSP（导致从另一个LSP接收流量）。
The procedure is as follows:
程序如下：
1. If an end-node (A or D) detects the failure of the working LSP (or a degradation of signal quality over the working LSP) or receives a Notify message including its SESSION object within the <upstream/downstream session list> (see [RFC3473]), and the new error code/sub-code "Notify Error/ LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object, it MUST begin receiving on the protecting LSP. Note that the <sender descriptor> or <flow
1. 如果终端节点（A或D）检测到工作LSP的故障（或工作LSP上的信号质量下降），或接收到一条通知消息，其中包括<upstream/downstream SESSION list>（参见[RFC3473]）中的会话对象，以及（If_ID）_error_SPEC对象中的新错误代码/子代码“Notify error/LSP Local Failed”（通知错误/LSP本地故障），它必须在保护LSP上开始接收。请注意，<sender descriptor>或<flow
descriptor> is also present in the Notify message that resolves any ambiguity and race condition since identifying (together with the SESSION object) the LSP under failure condition.
descriptor>也出现在Notify消息中，该消息解决了由于在故障条件下识别（与会话对象一起）LSP而产生的任何歧义和争用条件。
Note: (IF_ID)_ERROR_SPEC indicates that either the ERROR_SPEC (C-Type 1/2) or the ERROR_SPEC (C-Type 3/4, defined in [RFC3473]) can be used.
注：（如果ID）_ERROR_SPEC表示可以使用ERROR_SPEC（C-Type 1/2）或ERROR_SPEC（C-Type 3/4，在[RFC3473]中定义）。
This node MUST reliably send a Notify message, including the MESSAGE_ID object, to the other end-node (D or A, respectively) with the new error code/sub-code "Notify Error/LSP Failure" (Switchover Request) indicating the failure of the working LSP. This Notify message MUST be sent with the ACK_Desired flag set in the MESSAGE_ID object to request the receiver to send an acknowledgment for the message (see [RFC2961]).
此节点必须向另一个终端节点（分别为D或a）可靠地发送通知消息（包括消息_ID对象），新的错误代码/子代码“Notify error/LSP Failure”（切换请求）指示工作LSP的故障。发送此通知消息时，必须在message_ID对象中设置ACK_Desired标志，以请求接收方发送消息确认（请参见[RFC2961]）。
This (switchover request) Notify message MAY indicate the identity of the failed link or any other relevant information using the IF_ID ERROR_SPEC object (see [RFC3473]). In this case, the IF_ID ERROR_SPEC object replaces the ERROR_SPEC object in the Notify message; otherwise, the corresponding (data plane) information SHOULD be received in the PathErr/ResvErr message.
此（切换请求）通知消息可使用IF_ID ERROR_SPEC对象（参见[RFC3473]）指示故障链路的标识或任何其他相关信息。在这种情况下，IF_ID ERROR_SPEC对象将替换通知消息中的ERROR_SPEC对象；否则，应在PathErr/ResvErr消息中接收相应的（数据平面）信息。
2. Upon receipt of the (switchover request) Notify message, the end-node (D or A, respectively) MUST begin receiving from the protecting LSP.
2. 在收到（切换请求）通知消息后，终端节点（分别为D或A）必须开始从保护LSP接收。
This node MUST reliably send a Notify message, including the MESSAGE_ID object, to the other end-node (A or D, respectively). This (switchover response) Notify message MUST also include a MESSAGE_ID_ACK object to acknowledge reception of the (switchover request) Notify message.
此节点必须向另一个终端节点（分别为a或D）可靠地发送通知消息，包括消息\ ID对象。此（切换响应）通知消息还必须包括消息ID确认对象，以确认（切换请求）通知消息的接收。
This (switchover response) Notify message MAY indicate the identity of the failed link or any other relevant information using the IF_ID ERROR_SPEC object (see [RFC3473]).
此（切换响应）通知消息可使用IF_ID ERROR_SPEC对象（参见[RFC3473]）指示故障链路的标识或任何其他相关信息。
Note: upon receipt of the (switchover response) Notify message, the end-node (A or D, respectively) MUST send an Ack message to the other end-node to acknowledge its reception.
注意：在收到（切换响应）通知消息后，终端节点（分别为A或D）必须向另一个终端节点发送Ack消息以确认其接收。
Since the intermediate nodes (B, C, E, F, and G) are assumed to be GMPLS RSVP-TE signaling capable, each node adjacent to the failure MAY generate a Notify message directed either to the LSP head-end (upstream direction), or the LSP tail-end (downstream direction), or even both. Therefore, it is expected that these LSP terminating nodes (that MAY also detect the failure of the LSP from the data
由于中间节点（B、C、E、F和G）被假定为具有GMPLS RSVP-TE信令能力，因此与故障相邻的每个节点可以生成定向到LSP前端（上游方向）或LSP后端（下游方向）或甚至两者的通知消息。因此，预期这些LSP终止节点（也可以从数据中检测LSP故障
plane) provide either the right correlation mechanism to avoid repetition of the above procedure or just discard subsequent Notify messages corresponding to the same Session. In addition, for the LSP under failure condition, it is RECOMMENDED to not set the Path_State_ Removed Flag of the ERROR_SPEC object (see [RFC3473]) upon PathErr message generation.
平面）提供正确的关联机制，以避免重复上述过程，或仅放弃对应于同一会话的后续通知消息。此外，对于故障条件下的LSP，建议在生成PathErr消息时不要设置ERROR_SPEC对象的Path_State_Removed标志（请参见[RFC3473]）。
After protection switching completes (step 2), and after reception of the PathErr message, to keep track of the LSP from which the signal is taken, the protecting LSP SHOULD be signaled with the O bit set. The formerly working LSP MAY be signaled with the A bit set in the ADMIN_STATUS object (see [RFC3473]).
保护切换完成（步骤2）后，在收到PathErr消息后，为了跟踪接收信号的LSP，应使用O位设置向保护LSP发送信号。以前工作的LSP可以用ADMIN_STATUS对象中设置的位发出信号（参见[RFC3473]）。
Note: when the N bit is set, the end-to-end switchover request/ response exchange described above only provides control plane coordination (no actions are triggered at the data plane level).
注：设置N位时，上述端到端切换请求/响应交换仅提供控制平面协调（在数据平面级别不触发任何操作）。
The most common case of end-to-end 1:N protection is to establish, between the same endpoints, an end-to-end working LSP (thus, N = 1) and a dedicated end-to-end protecting LSP that are mutually link/ node/SRLG disjoint. This protects against working LSP failure(s).
端到端1:N保护最常见的情况是在相同的端点之间建立一个端到端工作LSP（因此，N=1）和一个专用的端到端保护LSP，它们相互链接/节点/SRLG不相交。这可以防止工作LSP故障。
The protecting LSP is used for switchover when the working LSP fails. GMPLS RSVP-TE signaling allows for the pre-provisioning of protecting LSPs by indicating in the Path message (in the PROTECTION object; see Section 14) that the LSPs are of type protecting. Here, working and protecting LSPs are signaled as primary LSPs; both are fully instantiated during the provisioning phase.
保护LSP用于在工作LSP出现故障时进行切换。GMPLS RSVP-TE信令通过在路径消息（在保护对象中；参见第14节）中指示LSP为保护类型，允许预先提供保护LSP。在这里，工作和保护LSP作为主LSP发出信号；在资源调配阶段，两者都被完全实例化。
Although the resources for the protecting LSP are pre-allocated, preemptable traffic may be carried end-to-end using this LSP. Thus, the protecting LSP is capable of carrying extra-traffic with the caveat that this traffic will be preempted if the working LSP fails.
尽管用于保护LSP的资源是预先分配的，但是可以使用该LSP端到端地承载可抢占业务。因此，保护LSP能够承载额外的通信量，但需要注意的是，如果工作LSP失败，该通信量将被抢占。
The setup of the working LSP SHOULD indicate that the LSP head-end and tail-end node wish to receive Notify messages using the NOTIFY REQUEST object. The node upstream to the failure (upstream in terms of the direction an Path message traverses) SHOULD send a Notify message to the LSP head-end node, and the node downstream to the failure SHOULD send an Notify message to the LSP tail-end node. Upon receipt of the Notify messages, both the end-nodes MUST switch the (normal) traffic from the working LSP to the pre-configured protecting LSP (see Section 7.2). Moreover, some coordination is required if extra-traffic is carried over the end-to-end protecting
工作LSP的设置应指示LSP前端和后端节点希望使用Notify请求对象接收Notify消息。故障上游的节点（就路径消息穿过的方向而言）应向LSP前端节点发送Notify消息，故障下游的节点应向LSP后端节点发送Notify消息。在收到通知消息后，两个终端节点必须将（正常）通信量从工作LSP切换到预配置的保护LSP（参见第7.2节）。此外，如果额外的流量通过端到端网络传输，则需要进行一些协调
LSP. Note that if the working and the protecting LSP are established between the same end-nodes, no further notification is required to indicate that the working LSPs are no longer protected.
LSP。注意，如果在相同的终端节点之间建立了工作和保护LSP，则不需要进一步的通知来指示工作LSP不再受到保护。
Consider the following topology:
考虑下面的拓扑结构：
A---B---C---D
\ /
E---F---G
A---B---C---D
\ /
E---F---G
The working LSP [A,B,C,D] could be protected by the protecting LSP [A,E,F,G,D]. Both LSPs are fully instantiated (resources are allocated for both working and protecting LSPs) and no resource sharing can be done along the protection path since the primary protecting LSP can carry extra-traffic.
工作LSP[A，B，C，D]可由保护LSP[A，E，F，G，D]保护。两个LSP都是完全实例化的（为工作和保护LSP分配资源），并且由于主保护LSP可以承载额外的流量，因此无法沿保护路径进行资源共享。
Note: it is necessary that both paths are SRLG disjoint to ensure recoverability; otherwise, a single failure may impact both working and protecting LSPs.
注意：两条路径必须是SRLG不相交的，以确保可恢复性；否则，单个故障可能会影响LSP的工作和保护。
To simplify association operations, both LSPs belong to the same session. Thus, the SESSION object MUST be the same for both LSPs. The LSP ID, however, MUST be different to distinguish between the protected LSP carrying working traffic and the protecting LSP that can carry extra-traffic.
为了简化关联操作，两个LSP属于同一会话。因此，两个LSP的会话对象必须相同。但是，LSP ID必须不同，以区分承载工作流量的受保护LSP和能够承载额外流量的受保护LSP。
A new PROTECTION object (see Section 14) is included in the Path message used to set up the two LSPs. This object carries the desired end-to-end LSP Protection Type -- in this case, "1:N Protection with Extra-Traffic". This LSP Protection Type value is applicable to both uni- and bidirectional LSPs.
用于设置两个LSP的路径消息中包含了一个新的保护对象（见第14节）。此对象携带所需的端到端LSP保护类型——在本例中为“1:N额外流量保护”。此LSP保护类型值适用于单向和双向LSP。
The working LSP is signaled by setting in the new PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the protecting LSP_ID.
通过在新的保护对象中将S位设置为0，将P位设置为0，并在关联对象中将关联ID设置为保护LSP_ID，从而发出工作LSP的信号。
The protecting LSP is signaled by setting in the new PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated protected LSP_ID.
通过在新的保护对象中将S位设置为0，将P位设置为1，并在关联对象中将关联ID设置为关联的受保护LSP_ID，从而发出保护LSP的信号。
To coordinate the switchover between endpoints, an end-to-end switchover request/response is needed such that the affected LSP is moved to the protecting LSP. Protection switching from the working to the protecting LSP (implying preemption of extra-traffic carried over the protecting LSP) must be initiated by one of the end-nodes (A or D).
为了协调端点之间的切换，需要端到端切换请求/响应，以便将受影响的LSP移动到保护LSP。必须由一个终端节点（A或D）启动从工作到保护LSP的保护切换（意味着抢占通过保护LSP承载的额外流量）。
The procedure is as follows:
程序如下：
1. If an end-node (A or D) detects the failure of the working LSP (or a degradation of signal quality over the working LSP) or receives a Notify message including its SESSION object within the <upstream/downstream session list> (see [RFC3473]), and the new error code/sub-code "Notify Error/LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object, it disconnects the extra-traffic from the protecting LSP. Note that the <sender descriptor> or <flow descriptor> is also present in the Notify message that resolves any ambiguity and race condition since identifying (together with the SESSION object) the LSP under failure condition.
1. 如果终端节点（A或D）检测到工作LSP的故障（或工作LSP上的信号质量下降），或接收到一条通知消息，其中包括<upstream/downstream SESSION list>（参见[RFC3473]）中的会话对象，以及（If_ID）_error_SPEC对象中的新错误代码/子代码“Notify error/LSP Local Failed”（通知错误/LSP本地故障），它将断开额外流量与保护LSP的连接。请注意，<sender descriptor>或<flow descriptor>也出现在Notify消息中，该消息解决了自识别（与会话对象一起）故障条件下的LSP以来的任何歧义和争用条件。
This node MUST reliably send a Notify message, including the MESSAGE_ID object, to the other end-node (D or A, respectively) with the new error code/sub-code "Notify Error/LSP Failure" (Switchover Request) indicating the failure of the working LSP. This Notify message MUST be sent with the ACK_Desired flag set in the MESSAGE_ID object to request the receiver to send an acknowledgment for the message (see [RFC2961]).
此节点必须向另一个终端节点（分别为D或a）可靠地发送通知消息（包括消息_ID对象），新的错误代码/子代码“Notify error/LSP Failure”（切换请求）指示工作LSP的故障。发送此通知消息时，必须在message_ID对象中设置ACK_Desired标志，以请求接收方发送消息确认（请参见[RFC2961]）。
This (switchover request) Notify message MAY indicate the identity of the failed link or any other relevant information using the IF_ID ERROR_SPEC object (see [RFC3473]). In this case, the IF_ID ERROR_SPEC object replaces the ERROR_SPEC object in the Notify message; otherwise, the corresponding (data plane) information SHOULD be received in the PathErr/ResvErr message.
此（切换请求）通知消息可使用IF_ID ERROR_SPEC对象（参见[RFC3473]）指示故障链路的标识或任何其他相关信息。在这种情况下，IF_ID ERROR_SPEC对象将替换通知消息中的ERROR_SPEC对象；否则，应在PathErr/ResvErr消息中接收相应的（数据平面）信息。
2. Upon receipt of the (switchover request) Notify message, the end-node (D or A, respectively) MUST disconnect the extra-traffic from the protecting LSP and begin sending/receiving normal traffic out/from the protecting LSP.
2. 在收到（切换请求）通知消息后，终端节点（分别为D或A）必须断开额外流量与保护LSP的连接，并开始从保护LSP发送/接收正常流量。
This node MUST reliably send a Notify message, including the MESSAGE_ID object, to the other end-node (A or D, respectively). This (switchover response) Notify message MUST
此节点必须向另一个终端节点（分别为a或D）可靠地发送通知消息，包括消息\ ID对象。此（切换响应）通知消息必须
also include a MESSAGE_ID_ACK object to acknowledge reception of the (switchover request) Notify message.
还包括一个MESSAGE_ID_ACK对象，用于确认（切换请求）Notify消息的接收。
This (switchover response) Notify message MAY indicate the identity of the failed link or any other relevant information using the IF_ID ERROR_SPEC object (see [RFC3473]).
此（切换响应）通知消息可使用IF_ID ERROR_SPEC对象（参见[RFC3473]）指示故障链路的标识或任何其他相关信息。
Note: since the Notify message generated by the other end-node (A or D, respectively) is distinguishable from the one generated by an intermediate node, there is no possibility of connecting the extra-traffic to the working LSP due to the receipt of a Notify message from an intermediate node.
注意：由于由另一个终端节点（分别为A或D）生成的通知消息与由中间节点生成的通知消息是可区分的，因此不可能由于从中间节点接收到通知消息而将额外流量连接到工作LSP。
3. Upon receipt of the (switchover response) Notify message, the end-node (A or D, respectively) MUST begin receiving normal traffic from or sending normal traffic out the protecting LSP.
3. 在收到（切换响应）通知消息后，终端节点（分别为A或D）必须开始从保护LSP接收正常通信量或从保护LSP发送正常通信量。
This node MUST also send an Ack message to the other end-node (D or A, respectively) to acknowledge the reception of the (switchover response) Notify message.
该节点还必须向另一端节点（分别为D或A）发送Ack消息，以确认（切换响应）Notify消息的接收。
Note 1: a 2-phase protection-switching signaling is used in the present context; a 3-phase signaling (see [RFC4426]) that would imply a notification message, a switchover request, and a switchover response messages is not considered here. Also, when the protecting LSPs do not carry extra-traffic, protection-switching signaling (as defined in Section 6.2) MAY be used instead of the procedure described in this section.
当前1-2信令用于保护；此处不考虑暗示通知消息、切换请求和切换响应消息的3阶段信令（参见[RFC4426]）。此外，当保护LSP不承载额外流量时，可使用保护切换信令（如第6.2节所定义）代替本节所述的程序。
Note 2: when the N bit is set, the above end-to-end switchover request/response exchange only provides control plane coordination (no actions are triggered at the data plane level).
注2：当设置N位时，上述端到端切换请求/响应交换仅提供控制平面协调（在数据平面级别不触发任何动作）。
After protection switching completes (step 3), and after reception of the PathErr message, to keep track of the LSP from which the normal traffic is taken, the protecting LSP SHOULD be signaled with the O bit set. In addition, the formerly working LSP MAY be signaled with the A bit set in the ADMIN_STATUS object (see [RFC3473]).
保护切换完成（步骤3）后，在接收到PathErr消息后，为了跟踪接收正常通信量的LSP，应使用O位设置向保护LSP发送信号。此外，以前工作的LSP可以用ADMIN_STATUS对象中设置的位发出信号（参见[RFC3473]）。
1:N (N > 1) protection with extra-traffic assumes that the fully provisioned protecting LSP is resource-disjoint from the N working LSPs. This protecting LSP thereby allows for carrying extra-traffic. Note that the N working LSPs and the protecting LSP are all between the same pair of endpoints. In addition, the N working LSPs (considered as identical in terms of traffic parameters) MAY be
1:N（N>1）具有额外流量的保护假定完全配置的保护LSP与N个工作LSP资源不相交。因此，这种保护LSP允许承载额外的流量。请注意，N个工作LSP和保护LSP都位于同一对端点之间。此外，N个工作lsp（在业务参数方面被认为是相同的）可以是
mutually resource-disjoint. Coordination between end-nodes is required when switching from one of the working to the protecting LSP.
相互不相交。从一个工作LSP切换到保护LSP时，需要终端节点之间的协调。
Each working LSP is signaled with both S bit and P bit set to 0. The LSP Protection Type is set to 0x04 (1:N Protection with Extra-Traffic) during LSP setup. Each Association ID points to the protecting LSP ID.
每个工作LSP都通过S位和P位设置为0的方式发送信号。LSP设置期间，LSP保护类型设置为0x04（1:N额外流量保护）。每个关联ID都指向保护LSP ID。
The protecting LSP (carrying extra-traffic) is signaled with the S bit set to 0 and the P bit set to 1. The LSP Protection Type is set to 0x04 (1:N Protection with Extra-Traffic) during LSP setup. The Association ID MUST be set by default to the LSP ID of the protected LSP corresponding to N = 1.
保护LSP（承载额外流量）通过S位设置为0，P位设置为1发出信号。LSP设置期间，LSP保护类型设置为0x04（1:N额外流量保护）。默认情况下，关联ID必须设置为与N=1对应的受保护LSP的LSP ID。
Any signaling procedure applicable to 1:1 protection with extra-traffic equally applies to 1:N protection with extra-traffic.
适用于1:1额外流量保护的任何信号程序同样适用于1:N额外流量保护。
End-to-end (pre-planned) rerouting without extra-traffic relies on the establishment between the same pair of end-nodes of a working LSP and a protecting LSP that is link/node/SRLG disjoint from the working LSP. However, in this case the protecting LSP is not fully instantiated; thus, it cannot carry any extra-traffic (note that this does not mean that the corresponding resources cannot be used by other LSPs). Therefore, this mechanism protects against working LSP failure(s) but requires activation of the protecting LSP after failure occurrence.
无额外通信量的端到端（预先计划）重路由依赖于工作LSP的同一对端节点和与工作LSP不相交的链路/节点/SRLG的保护LSP之间的建立。然而，在这种情况下，保护LSP没有完全实例化；因此，它不能承载任何额外的流量（请注意，这并不意味着其他LSP不能使用相应的资源）。所以，该机制可以防止LSP出现工作故障，但需要在故障发生后激活保护LSP。
Signaling is performed by indicating in the Path message (in the PROTECTION object; see Section 14) that the LSPs are of type working and protecting, respectively. Protecting LSPs are used for fast switchover when working LSPs fail. In this case, working and protecting LSPs are signaled as primary LSP and secondary LSP, respectively. Thus, only the working LSP is fully instantiated during the provisioning phase, and for the protecting LSPs, no resources are committed at the data plane level (they are pre-reserved at the control plane level only). The setup of the working LSP SHOULD indicate (using the NOTIFY REQUEST object as specified in Section 4 of [RFC3473]) that the LSP head-end node (and possibly the tail-end node) wish to receive a Notify message upon LSP failure occurrence. Upon receipt of the Notify message, the head-end node MUST switch the (normal) traffic from the working LSP to the protecting LSP after its activation. Note that since the working and the protecting LSPs are established between the same end-nodes, no further notification is required to indicate that the working LSPs are without protection.
通过在路径消息（在保护对象中；参见第14节）中指示LSP分别为工作和保护类型来执行信令。保护LSP用于工作LSP故障时的快速切换。在这种情况下，工作和保护LSP分别作为主LSP和辅助LSP发出信号。因此，在供应阶段，只有工作LSP被完全实例化，而对于保护LSP，在数据平面级别没有提交任何资源（它们仅在控制平面级别预先保留）。工作LSP的设置应表明（使用[RFC3473]第4节中规定的NOTIFY REQUEST对象），LSP前端节点（可能还有后端节点）希望在LSP故障发生时接收NOTIFY消息。在收到通知消息后，前端节点必须在激活后将（正常）通信量从工作LSP切换到保护LSP。注意，由于工作和保护lsp是在相同的终端节点之间建立的，因此不需要进一步的通知来指示工作lsp没有保护。
To make bandwidth pre-reserved for a protecting (but not activated) LSP available for extra-traffic, this bandwidth could be included in the advertised Unreserved Bandwidth at priority lower (means numerically higher) than the Holding Priority of the protecting LSP. In addition, the Max LSP Bandwidth field in the Interface Switching Capability Descriptor sub-TLV should reflect the fact that the bandwidth pre-reserved for the protecting LSP is available for extra traffic. LSPs for extra-traffic then can be established using the bandwidth pre-reserved for the protecting LSP by setting (in the Path message) the Setup Priority field of the SESSION_ATTRIBUTE object to X (where X is the Setup Priority of the protecting LSP), and the Holding Priority field to at least X+1. Also, if the resources pre-reserved for the protecting LSP are used by lower-priority LSPs, these LSPs MUST be preempted when the protecting LSP is activated (see Section 10).
为了使为保护（但未激活）LSP预先保留的带宽可用于额外的业务，该带宽可以以低于保护LSP的保持优先级（意味着数字更高）的优先级包括在广告的未保留带宽中。此外，接口交换能力描述符子TLV中的最大LSP带宽字段应反映为保护LSP预留的带宽可用于额外流量的事实。然后，通过将会话_属性对象的设置优先级字段设置为X（其中X是保护LSP的设置优先级），并将保持优先级字段设置为至少X+1，可以使用为保护LSP预先保留的带宽来建立额外流量的LSP。此外，如果为保护LSP预先保留的资源由低优先级LSP使用，则在激活保护LSP时必须抢占这些LSP（参见第10节）。
Consider the following topology:
考虑下面的拓扑结构：
A---B---C---D
\ /
E---F---G
A---B---C---D
\ /
E---F---G
The working LSP [A,B,C,D] could be protected by the protecting LSP [A,E,F,G,D]. Only the protected LSP is fully instantiated (resources are only allocated for the working LSP). Therefore, the protecting LSP cannot carry any extra-traffic. When a failure is detected on the working LSP (say, at B), the error is propagated and/or notified (using a Notify message with the new error code/sub-code "Notify Error/LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object) to the ingress node (A). Upon reception, the latter activates the secondary protecting LSP instantiated during the (pre-)provisioning phase. This requires:
工作LSP[A，B，C，D]可由保护LSP[A，E，F，G，D]保护。只有受保护的LSP被完全实例化（资源仅分配给工作LSP）。因此，保护LSP不能承载任何额外的业务。当在工作LSP上检测到故障（例如，在B处）时，错误将传播和/或通知（使用带有（IF_ID）_error_SPEC对象中的新错误代码/子代码“Notify error/LSP local Failed”的通知消息）到入口节点（a）。接收后，后者激活在（预）供应阶段实例化的辅助保护LSP。这需要：
(1) the ability to identify a "secondary protecting LSP" (hereby called the "secondary LSP") used to recover another primary working LSP (hereby called the "protected LSP") (2) the ability to associate the secondary LSP with the protected LSP (3) the capability to activate a secondary LSP after failure occurrence.
(1) 识别用于恢复另一主工作LSP（以下称为“受保护LSP”）的“二级保护LSP”（以下称为“二级LSP”）的能力；（2）将二级LSP与受保护LSP关联的能力（3）在故障发生后激活二级LSP的能力。
In the following subsections, these features are described in more detail.
在以下小节中，将更详细地描述这些功能。
To simplify association operations, both LSPs (i.e., the protected and the secondary LSPs) belong to the same session. Thus, the SESSION object MUST be the same for both LSPs. The LSP ID, however, MUST be different to distinguish between the protected LSP carrying working traffic and the secondary LSP that cannot carry extra-traffic.
为了简化关联操作，两个LSP（即受保护LSP和辅助LSP）都属于同一会话。因此，两个LSP的会话对象必须相同。但是，LSP ID必须不同，以区分承载工作流量的受保护LSP和无法承载额外流量的辅助LSP。
A new PROTECTION object (see Section 14) is used to set up the two LSPs. This object carries the desired end-to-end LSP Protection Type (in this case, "Rerouting without Extra-Traffic"). This LSP Protection Type value is applicable to both uni- and bidirectional LSPs.
使用新的保护对象（见第14节）设置两个LSP。此对象携带所需的端到端LSP保护类型（在本例中为“无额外流量的重新路由”）。此LSP保护类型值适用于单向和双向LSP。
The new PROTECTION object is included in the Path message during signaling of the primary working LSP, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic".
在主工作LSP的信令期间，新的保护对象包括在路径消息中，端到端LSP保护类型值设置为“无额外流量的重新路由”。
Primary working LSPs are signaled by setting in the new PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the associated secondary protecting LSP_ID.
通过在新的保护对象中将S位设置为0，将P位设置为0，并在关联对象中将关联ID设置为关联的二级保护LSP_ID，来通知主要工作LSP。
The new PROTECTION object is included in the Path message during signaling of secondary protecting LSPs, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic".
在二级保护LSP的信令期间，新的保护对象包含在路径消息中，端到端LSP保护类型值设置为“无额外流量的重新路由”。
Secondary protecting LSPs are signaled by setting in the new PROTECTION object the S bit and the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated primary working LSP_ID, which MUST be known before signaling of the secondary LSP.
通过将新保护对象中的S位和P位设置为1，并将关联对象中的关联ID设置为关联的主要工作LSP_ID，二次保护LSP发出信号，在二次LSP发出信号之前必须知道该ID。
With this setting, the resources for the secondary LSP SHOULD be pre-reserved, but not committed at the data plane level, meaning that the internals of the switch need not be established until explicit action is taken to activate this secondary LSP. Activation of a secondary LSP is done using a modified Path message with the S bit set to 0 in the PROTECTION object. At this point, the link and node resources must be allocated for this LSP that becomes a primary LSP (ready to carry normal traffic).
通过此设置，辅助LSP的资源应预先保留，但不在数据平面级别提交，这意味着在采取明确措施激活此辅助LSP之前，不需要建立交换机的内部。辅助LSP的激活使用修改的路径消息完成，保护对象中的S位设置为0。此时，必须为此LSP分配链路和节点资源，该LSP将成为主LSP（准备承载正常流量）。
From [RFC3945], the secondary LSP is set up with resource pre-reservation but with or without label pre-selection (both allowing sharing of the recovery resources). In the former case (defined as the default), label allocation during secondary LSP signaling does not require any specific procedure compared to [RFC3473]. However, in the latter case, label (and thus resource) re-allocation MAY occur during the secondary LSP activation. This means that during the LSP activation phase, labels MAY be reassigned (with higher precedence over existing label assignment; see also [RFC3471]).
从[RFC3945]中，辅助LSP通过资源预保留进行设置，但有或没有标签预选择（两者都允许共享恢复资源）。在前一种情况下（定义为默认情况），与[RFC3473]相比，次要LSP信令期间的标签分配不需要任何特定程序。然而，在后一种情况下，标签（以及由此产生的资源）重新分配可在辅助LSP激活期间发生。这意味着在LSP激活阶段，可能会重新分配标签（优先于现有标签分配；另请参见[RFC3471]）。
Note: under certain circumstances (e.g., when pre-reserved protecting resources are used by lower-priority LSPs), it MAY be desirable to perform the activation of the secondary LSP in the upstream direction (Resv trigger message) instead of using the default downstream activation. In this case, any mis-ordering and any mis-interpretation between a refresh Resv (along the lower-priority LSP) and a trigger Resv message (along the secondary LSP) MUST be avoided at any intermediate node. For this purpose, upon reception of the Path message, the egress node MAY include the PROTECTION object in the Resv message. The latter is then processed on a hop-by-hop basis to activate the secondary LSP until reaching the ingress node. The PROTECTION object included in the Path message MUST be set as specified in this section. In this case, the PROTECTION object with the S bit MUST be set to 0 and included in the Resv message sent in the upstream direction. The upstream activation behavior SHOULD be configurable on a local basis. Details concerning lower-priority LSP preemption upon secondary LSP activation are provided in Section 10.
注意：在某些情况下（例如，当低优先级LSP使用预保留的保护资源时），可能需要在上游方向（Resv触发消息）执行辅助LSP的激活，而不是使用默认的下游激活。在这种情况下，必须在任何中间节点上避免刷新Resv（沿较低优先级LSP）和触发Resv消息（沿辅助LSP）之间的任何错误排序和错误解释。为此，在接收到路径消息时，出口节点可以在Resv消息中包括保护对象。然后在逐跳的基础上处理后者，以激活辅助LSP，直到到达入口节点。必须按照本节的规定设置路径消息中包含的保护对象。在这种情况下，具有S位的保护对象必须设置为0，并包含在向上游方向发送的Resv消息中。上游激活行为应在本地基础上进行配置。第10节提供了有关次要LSP激活时低优先级LSP抢占的详细信息。
An approach to reduce recovery resource requirements is to have protection LSPs sharing network resources when the working LSPs that they protect are physically (i.e., link, node, SRLG, etc.) disjoint. This mechanism is referred to as shared mesh restoration and is described in [RFC4426]. Shared-mesh restoration can be seen as a particular case of pre-planned LSP rerouting (see Section 8) that reduces the recovery resource requirements by allowing multiple protecting LSPs to share common link and node resources. Here also, the recovery resources for the protecting LSPs are pre-reserved during the provisioning phase, thus an explicit signaling action is required to activate (i.e., commit resource allocation at the data plane) a specific protecting LSP instantiated during the (pre-) provisioning phase. This requires restoration signaling along the protecting LSP.
减少恢复资源需求的一种方法是，当保护LSP所保护的工作LSP在物理上（即链路、节点、SRLG等）不相交时，让保护LSP共享网络资源。这种机制称为共享网格恢复，在[RFC4426]中进行了描述。共享网格恢复可以看作是预先计划的LSP重新路由的一种特殊情况（参见第8节），它通过允许多个保护LSP共享公共链路和节点资源来减少恢复资源需求。这里，用于保护LSP的恢复资源在供应阶段期间被预先保留，因此需要显式信令动作来激活（即，在数据平面上提交资源分配）在（预）供应阶段期间实例化的特定保护LSP。这需要沿保护LSP发送恢复信令。
To make bandwidth pre-reserved for a protecting (but not activated) LSP, available for extra-traffic this bandwidth could be included in the advertised Unreserved Bandwidth at priority lower (means
为了使带宽预先保留给保护（但未激活）LSP，可用于额外流量，此带宽可包含在优先级较低的广告未保留带宽中（意味着
numerically higher) than the Holding Priority of the protecting LSP. In addition, the Max LSP Bandwidth field in the Interface Switching Capability Descriptor sub-TLV should reflect the fact that the bandwidth pre-reserved for the protecting LSP is available for extra traffic. LSPs for extra-traffic then can be established using the bandwidth pre-reserved for the protecting LSP by setting (in the Path message) the Setup Priority field of the SESSION_ATTRIBUTE object to X (where X is the Setup Priority of the protecting LSP) and the Holding Priority field to at least X+1. Also, if the resources pre-reserved for the protecting LSP are used by lower priority LSPs, these LSPs MUST be preempted when the protecting LSP is activated (see Section 10). Further, if the recovery resources are shared between multiple protecting LSPs, the corresponding working LSPs head-end nodes must be informed that they are no longer protected when the protecting LSP is activated to recover the normal traffic for the working LSP under failure.
数字上高于）保护LSP的保持优先级。此外，接口交换能力描述符子TLV中的最大LSP带宽字段应反映为保护LSP预留的带宽可用于额外流量的事实。然后，通过将会话_属性对象的设置优先级字段设置为X（其中X是保护LSP的设置优先级），并将保持优先级字段设置为至少X+1，可以使用为保护LSP预先保留的带宽来建立额外流量的LSP。此外，如果为保护LSP预先保留的资源由低优先级LSP使用，则在激活保护LSP时必须抢占这些LSP（参见第10节）。此外，如果恢复资源在多个保护LSP之间共享，则当激活保护LSP以恢复故障下工作LSP的正常通信量时，必须通知相应的工作LSP头端节点它们不再受到保护。
Consider the following topology:
考虑下面的拓扑结构：
A---B---C---D
\ /
E---F---G
/ \
H---I---J---K
A---B---C---D
\ /
E---F---G
/ \
H---I---J---K
The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by [A,E,F,G,D] and [H,E,F,G,K], respectively. Per [RFC3209], in order to achieve resource sharing during the signaling of these protecting LSPs, they must have the same Tunnel Endpoint Address (as part of their SESSION object). However, these addresses are not the same in this example. Resource sharing along E, F, and G can only be achieved if the nodes E, F, and G recognize that the LSP Protection Type of the secondary LSP is set to "Rerouting without Extra-Traffic" (see PROTECTION object, Section 14) and acts accordingly. In this case, the protecting LSPs are not merged (which is useful since the paths diverge at G), but the resources along E, F, G can be shared.
工作lsp[A，B，C，D]和[H，I，J，K]可分别受到[A，E，F，G，D]和[H，E，F，G，K]的保护。根据[RFC3209]，为了在这些保护LSP的信令期间实现资源共享，它们必须具有相同的隧道端点地址（作为其会话对象的一部分）。但是，在本例中，这些地址不相同。只有当节点E、F和G认识到辅助LSP的LSP保护类型被设置为“无额外流量的重新路由”（参见保护对象，第14节）并相应地采取行动时，才能实现沿E、F和G的资源共享。在这种情况下，不合并保护lsp（这是有用的，因为路径在G处发散），但是可以共享沿E、F、G的资源。
When a failure is detected on one of the working LSPs (say, at B), the error is propagated and/or notified (using a Notify message with the new error code/sub-code "Notify Error/LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object) to the ingress node (A). Upon reception, the latter activates the secondary protecting LSP (see Section 8). At this point, it is important that a failure on the other LSP (say, at J) does not cause the other ingress (H) to send the data down the protecting LSP since the resources are already in use. This can be achieved by node E using the following procedure. When the capacity is first reserved for the protecting LSP, E should verify that the LSPs being protected ([A,B,C,D] and [H,I,J,K], respectively) do not
当在其中一个工作LSP上检测到故障时（例如，在B），错误将传播和/或通知到入口节点（a）（使用带有新错误代码/子代码“Notify error/LSP Local Failed”（如果ID）\u error\u SPEC对象）的Notify消息）。接收后，后者激活辅助保护LSP（见第8节）。此时，重要的是，另一个LSP（例如，在J）上的故障不会导致其他入口（H）将数据发送到保护LSP，因为资源已经在使用中。这可以通过节点E使用以下过程来实现。当首次为保护LSP保留容量时，E应验证被保护的LSP（分别为[A、B、C、D]和[H、I、J、K]）不存在
share any common resources. Then, when a failure occurs (say, at B) and the protecting LSP [A,E,F,G,D] is activated, E should notify H that the resources for the protecting LSP [H,E,F,G,K] are no longer available.
共享任何公共资源。然后，当发生故障（例如，在B）并且保护LSP[a，E，F，G，D]被激活时，E应当通知H用于保护LSP[H，E，F，G，K]的资源不再可用。
The following subsections detail how shared mesh restoration can be implemented in an interoperable fashion using GMPLS RSVP-TE extensions (see [RFC3473]). This includes:
以下小节详细介绍了如何使用GMPLS RSVP-TE扩展以可互操作的方式实现共享网格恢复（请参见[RFC3473]）。这包括：
(1) the ability to identify a "secondary protecting LSP" (hereby called the "secondary LSP") used to recover another primary working LSP (hereby called the "protected LSP") (2) the ability to associate the secondary LSP with the protected LSP (3) the capability to include information about the resources used by the protected LSP while instantiating the secondary LSP. (4) the capability to instantiate during the provisioning phase several secondary LSPs in an efficient manner. (5) the capability to activate a secondary LSP after failure occurrence.
(1) 识别用于恢复另一个主要工作LSP（以下称为“受保护LSP”）的“二级保护LSP”（以下称为“二级LSP”）的能力（2）将二级LSP与受保护LSP关联的能力（3）在实例化辅助LSP时，包含有关受保护LSP使用的资源的信息的能力。（4） 能够在供应阶段以高效的方式实例化多个辅助LSP。（5） 发生故障后激活辅助LSP的能力。
In the following subsections, these features are described in detail.
在以下小节中，将详细描述这些功能。
To simplify association operations, both LSPs (i.e., the protected and the secondary LSPs) belong to the same session. Thus, the SESSION object MUST be the same for both LSPs. The LSP ID, however, MUST be different to distinguish between the protected LSP carrying working traffic and the secondary LSP that cannot carry extra-traffic.
为了简化关联操作，两个LSP（即受保护LSP和辅助LSP）都属于同一会话。因此，两个LSP的会话对象必须相同。但是，LSP ID必须不同，以区分承载工作流量的受保护LSP和无法承载额外流量的辅助LSP。
A new PROTECTION object (see Section 14) is used to set up the two LSPs. This object carries the desired end-to-end LSP Protection Type -- in this case, "Rerouting without Extra-Traffic". This LSP Protection Type value is applicable to both uni- and bidirectional LSPs.
使用新的保护对象（见第14节）设置两个LSP。此对象携带所需的端到端LSP保护类型——在本例中为“无额外流量的重新路由”。此LSP保护类型值适用于单向和双向LSP。
The new PROTECTION object is included in the Path message during signaling of the primary working LSPs, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic".
在主工作LSP的信令期间，新的保护对象包括在路径消息中，端到端LSP保护类型值设置为“无额外流量的重新路由”。
Primary working LSPs are signaled by setting in the new PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the associated secondary protecting LSP_ID.
通过在新的保护对象中将S位设置为0，将P位设置为0，并在关联对象中将关联ID设置为关联的二级保护LSP_ID，来通知主要工作LSP。
The new PROTECTION object is included in the Path message during signaling of the secondary protecting LSPs, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic".
在二级保护LSP的信令期间，新的保护对象包括在路径消息中，端到端LSP保护类型值设置为“无额外流量的重新路由”。
Secondary protecting LSPs are signaled by setting in the new PROTECTION object the S bit and the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated primary working LSP_ID, which MUST be known before signaling of the secondary LSP. Moreover, the Path message used to instantiate the secondary LSP SHOULD include at least one PRIMARY_PATH_ROUTE object (see Section 15) that further allows for recovery resource sharing at each intermediate node along the secondary path.
通过将新保护对象中的S位和P位设置为1，并将关联对象中的关联ID设置为关联的主要工作LSP_ID，二次保护LSP发出信号，在二次LSP发出信号之前必须知道该ID。此外，用于实例化次LSP的路径消息应包括至少一个主路径路由对象（参见第15节），该对象进一步允许沿次路径的每个中间节点处的恢复资源共享。
With this setting, the resources for the secondary LSP SHOULD be pre-reserved, but not committed at the data plane level, meaning that the internals of the switch need not be established until explicit action is taken to activate this LSP. Activation of a secondary LSP is done using a modified Path message with the S bit set to 0 in the PROTECTION object. At this point, the link and node resources must be allocated for this LSP that becomes a primary LSP (ready to carry normal traffic).
使用此设置时，辅助LSP的资源应预先保留，但不在数据平面级别提交，这意味着在采取明确措施激活此LSP之前，不需要建立交换机的内部。辅助LSP的激活使用修改的路径消息完成，保护对象中的S位设置为0。此时，必须为此LSP分配链路和节点资源，该LSP将成为主LSP（准备承载正常流量）。
From [RFC3945], the secondary LSP is set up with resource pre-reservation but with or without label pre-selection (both allowing sharing of the recovery resources). In the former case (defined as the default), label allocation during secondary LSP signaling does not require any specific procedure compared to [RFC3473]. However, in the latter case, label (and thus resource) re-allocation MAY occur during the secondary LSP activation. This means that, during the LSP activation phase, labels MAY be reassigned (with higher precedence over existing label assignment; see also [RFC3471]).
从[RFC3945]中，辅助LSP通过资源预保留进行设置，但有或没有标签预选择（两者都允许共享恢复资源）。在前一种情况下（定义为默认情况），与[RFC3473]相比，次要LSP信令期间的标签分配不需要任何特定程序。然而，在后一种情况下，标签（以及由此产生的资源）重新分配可在辅助LSP激活期间发生。这意味着，在LSP激活阶段，可以重新分配标签（优先于现有标签分配；另请参见[RFC3471]）。
When protecting resources are only pre-reserved for the secondary LSPs, they MAY be used to set up lower-priority LSPs. In this case, these resources MUST be preempted when the protecting LSP is activated. An additional condition raises from misconnection avoidance between the secondary protecting LSP being activated and the low-priority LSP(s) being preempted. Procedure to be applied when the secondary protecting LSP (i.e., the preempting LSP) Path message reaches a node using the resources for lower-priority LSP(s) (i.e., preempted LSP(s)) is as follows:
当保护资源仅为辅助LSP预先保留时，它们可用于设置低优先级LSP。在这种情况下，当保护LSP被激活时，这些资源必须被抢占。另一种情况是，在被激活的辅助保护LSP和被抢占的低优先级LSP之间避免错误连接。当二级保护LSP（即抢占LSP）路径消息到达使用低优先级LSP（即抢占LSP）资源的节点时要应用的过程如下：
1. De-allocate resources to be used by the preempting LSP and release the cross-connection. Note that if the preempting LSP is bidirectional, these resources may come from one or two lower-priority LSPs, and if from two LSPs, they may be uni- or bi-directional. The preempting node SHOULD NOT send the Path message before the de-allocation of resources has completed since this may lead to the downstream path becoming misconnected if the downstream node is able to reassign the resources more quickly.
1. 取消分配抢占LSP使用的资源并释放交叉连接。注意，如果抢占LSP是双向的，则这些资源可能来自一个或两个低优先级LSP，如果来自两个LSP，则它们可能是单向的或双向的。抢占节点不应在资源取消分配完成之前发送路径消息，因为如果下游节点能够更快地重新分配资源，这可能会导致下游路径连接错误。
2. Send PathTear and PathErr messages with the new error code/sub-code "Policy Control failure/Hard preempted" and the Path_State_Removed flag set for the preempted LSP(s).
2. 发送带有新错误代码/子代码“策略控制失败/硬抢占”和为抢占LSP设置的Path_State_Removed标志的PathTerre和PathErr消息。
3. Reserve the preempted resources for the protecting LSP. The preempting node MUST NOT cross-connect the upstream resources of a bidirectional preempting LSP.
3. 为保护LSP保留抢占资源。抢占节点不得交叉连接双向抢占LSP的上游资源。
4. Send the Path message.
4. 发送路径消息。
5. Upon reception of a trigger Resv message from the downstream node, cross-connect the downstream path resources, and if the preempting LSP is bidirectional, perform cross-connection for the upstream path resources.
5. 在接收到来自下游节点的触发Resv消息时，交叉连接下游路径资源，并且如果抢占LSP是双向的，则对上游路径资源执行交叉连接。
Note that step 1 may cause alarms to be raised for the preempted LSP. If alarm suppression is desired, the preempting node MAY insert the following steps before step 1.
请注意，步骤1可能会导致针对抢占LSP发出警报。如果需要报警抑制，抢占节点可以在步骤1之前插入以下步骤。
1a. Before de-allocating resources, send a Resv message, including an ADMIN_STATUS object, to disable alarms for the preempted LSP. 1b. Receive a Path message indicating that alarms are disabled.
1a。在取消分配资源之前，发送Resv消息，包括ADMIN_STATUS对象，以禁用抢占LSP的警报。1b。接收指示报警已禁用的路径消息。
At the downstream node (with respect to the preempting LSP), the processing is RECOMMENDED to be as follows:
在下游节点（关于抢占LSP），建议如下处理：
1. Receive PathTear (and/or PathErr) message for the preempted LSP(s).
1. 接收抢占LSP的Path催泪（和/或PathErr）消息。
2a. Release the resources associated with the LSP on the interface to the preempting LSP, remove any cross-connection, and release all other resources associated with the preempted LSP. 2b. Forward the PathTear (and/or PathErr) message per [RFC3473].
2a。在与抢占LSP的接口上释放与LSP关联的资源，删除任何交叉连接，并释放与抢占LSP关联的所有其他资源。2b。根据[RFC3473]转发PathTrain（和/或PathErr）消息。
3. Receive the Path message for the preempting LSP and process as normal, forwarding it to the downstream node.
3. 接收抢占LSP的路径消息，并正常处理，将其转发到下游节点。
4. Receive the Resv message for the preempting LSP and process as normal, forwarding it to the upstream node.
4. 接收抢占LSP的Resv消息，并正常处理，将其转发到上游节点。
LSP rerouting, on the other hand, switches normal traffic to an alternate LSP that is fully established only after failure occurrence. The new (alternate) route is selected at the LSP head-end and may reuse intermediate nodes included in the original route; it may also include additional intermediate nodes. For strict-hop routing, TE requirements can be directly applied to the route computation, and the failed node or link can be avoided. However, if the failure occurred within a loose-routed hop, the head-end node may not have enough information to reroute the LSP around the failure. Crankback signaling (see [CRANK]) and route exclusion techniques (see [RFC4874]) MAY be used in this case.
另一方面，LSP重路由将正常通信量切换到仅在故障发生后才完全建立的备用LSP。在LSP头端选择新（备用）路由，并且可以重用包括在原始路由中的中间节点；它还可以包括额外的中间节点。对于严格的跳数路由，TE要求可以直接应用于路由计算，并且可以避免失败的节点或链路。但是，如果故障发生在松散路由的跃点内，则前端节点可能没有足够的信息来围绕故障重新路由LSP。在这种情况下，可使用回退信令（见[CRANK]）和路由排除技术（见[RFC4874]）。
The alternate route MAY be either computed on demand (that is, when the failure occurs; this is referred to as full LSP rerouting) or pre-computed and stored for use when the failure is reported. The latter offers faster restoration time. There is, however, a risk that the alternate route will become out of date through other changes in the network; this can be mitigated to some extent by periodic recalculation of idle alternate routes.
备用路由可以按需计算（即，发生故障时；这称为完全LSP重新路由），也可以预先计算并存储，以便在报告故障时使用。后者提供更快的恢复时间。然而，由于网络中的其他变化，存在备用路线过时的风险；这可以通过定期重新计算空闲备用路线在一定程度上缓解。
(Full) LSP rerouting will be initiated by the head-end node that has either detected the LSP failure or received a Notify message and/or a PathErr message with the new error code/sub-code "Notify Error/LSP Locally Failed" for this LSP. The new LSP resources can be established using the make-before-break mechanism, where the new LSP is set up before the old LSP is torn down. This is done by using the mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit (SE) reservation style (see [RFC3209]). Both the new and old LSPs can share resources at common nodes.
（完整）LSP重新路由将由检测到LSP故障或接收到此LSP的Notify消息和/或带有新错误代码/子代码“Notify error/LSP LOCAL Failed”的PathErr消息的前端节点启动。新的LSP资源可以使用先生成后分解机制来建立，其中新的LSP是在旧的LSP被拆除之前建立的。这是通过使用SESSION_属性对象和共享显式（SE）保留样式的机制实现的（请参见[RFC3209]）。新旧LSP都可以在公共节点上共享资源。
Note that the make-before-break mechanism is not used to avoid disruption to the normal traffic flow (the latter has already been broken by the failure that is being repaired). However, it is valuable to retain the resources allocated on the original LSP that will be reused by the new alternate LSP.
请注意，先通后断机制不用于避免正常交通流中断（后者已因正在修复的故障而中断）。但是，保留在原始LSP上分配的资源是很有价值的，这些资源将被新的备用LSP重用。
The Tunnel Endpoint Address, Tunnel ID, Extended Tunnel ID, and Tunnel Sender Address uniquely identify both the old and new LSPs. Only the LSP_ID value differentiates the old from the new alternate LSP. The new alternate LSP is set up before the old LSP is torn down using Shared-Explicit (SE) reservation style. This ensures that the new (alternate) LSP is established without double-counting resource requirements along common segments.
隧道端点地址、隧道ID、扩展隧道ID和隧道发送方地址可唯一标识新旧LSP。只有LSP_ID值区分新旧备用LSP。新的备用LSP是在使用共享显式（SE）保留样式拆下旧LSP之前设置的。这确保了新（备用）LSP的建立不会重复计算公共段的资源需求。
The alternate LSP MAY be set up before any failure occurrence with SE-style resource reservation, the latter shares the same Tunnel End Point Address, Tunnel ID, Extended Tunnel ID, and Tunnel Sender Address with the original LSP (i.e., only the LSP ID value MUST be different).
备用LSP可以在任何故障发生之前使用SE样式的资源保留设置，后者与原始LSP共享相同的隧道端点地址、隧道ID、扩展隧道ID和隧道发送方地址（即，只有LSP ID值必须不同）。
In both cases, the Association ID of the ASSOCIATION object MUST be set to the LSP ID value of the signaled LSP.
在这两种情况下，关联对象的关联ID必须设置为发信号的LSP的LSP ID值。
A new PROTECTION object is included in the Path message during signaling of dynamically reroutable LSPs, with the end-to-end LSP Protection Type value set to "Full Rerouting". These LSPs that can be either uni- or bidirectional are signaled by setting in the PROTECTION object the S bit to 0, the P bit to 0, and the Association ID value to the LSP_ID value of the signaled LSP. Any specific action to be taken during the provisioning phase is up to the end-node local policy.
在动态可重路由LSP的信令期间，路径消息中包含一个新的保护对象，端到端LSP保护类型值设置为“完全重路由”。通过在保护对象中将S位设置为0、P位设置为0以及将关联ID值设置为发信号的LSP的LSP_ID值，可以是单向或双向的LSP发出信号。在资源调配阶段要采取的任何特定操作都取决于终端节点本地策略。
Note: when the end-to-end LSP Protection Type is set to "Unprotected", both S and P bit MUST be set to 0, and the LSP SHOULD NOT be rerouted at the head-end node after failure occurrence. The Association_ID value MUST be set to the LSP_ID value of the signaled LSP. This does not mean that the Unprotected LSP cannot be re-established for other reasons such as path re-optimization and bandwidth adjustment driven by policy conditions.
注意：当端到端LSP保护类型设置为“Unprotected”时，S和P位都必须设置为0，发生故障后不应在前端节点重新路由LSP。关联ID值必须设置为信号LSP的LSP ID值。这并不意味着由于其他原因，例如路径重新优化和由策略条件驱动的带宽调整，无法重新建立未受保护的LSP。
Reversion refers to a recovery switching operation, where the normal traffic returns to (or remains on) the working LSP when it has recovered from the failure. Reversion implies that resources remain allocated to the LSP that was originally routed over them even after a failure. It is important to have mechanisms that allow reversion to be performed with minimal service disruption and reconfiguration.
恢复是指一种恢复切换操作，当正常业务从故障中恢复时，它将返回（或保持打开）工作LSP。恢复意味着即使在发生故障后，资源仍然分配给最初通过它们路由的LSP。重要的是要有一种机制，允许在最小的服务中断和重新配置的情况下执行恢复。
For "1+1 bidirectional Protection", reversion to the recovered LSP occurs by using the following sequence:
对于“1+1双向保护”，使用以下顺序恢复到恢复的LSP：
1. Clear the A bit of the ADMIN_STATUS object if set for the recovered LSP.
1. 如果为恢复的LSP设置了ADMIN_STATUS对象，则清除该对象的A位。
2. Then, apply the method described below to switch normal traffic back from the protecting to the recovered LSP. This is performed by using the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request).
2. 然后，应用下面描述的方法将正常通信量从保护切换回恢复的LSP。这是通过使用新的错误代码/子代码“Notify error/LSP Recovered”（返回请求）执行的。
The procedure is as follows:
程序如下：
1) The initiating (source) node sends the normal traffic onto both the working and the protecting LSPs. Once completed, the source node sends reliably a Notify message to the destination with the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request). This Notify message includes the MESSAGE_ID object. The ACK_Desired flag MUST be set in this object to request the receiver to send an acknowledgment for the message (see [RFC2961]).
1) 发起（源）节点将正常流量发送到工作和保护LSP。一旦完成，源节点将可靠地向目标发送通知消息，其中包含新的错误代码/子代码“Notify error/LSP Recovered”（切换请求）。此通知消息包括消息\u ID对象。必须在此对象中设置ACK_Desired标志，以请求接收方发送消息确认（请参见[RFC2961]）。
2) Upon receipt of this message, the destination selects the traffic from the working LSP. At the same time, it transmits the traffic onto both the working and protecting LSP.
2) 收到此消息后，目的地从工作LSP中选择通信量。同时，它将流量传输到工作LSP和保护LSP。
The destination then sends reliably a Notify message to the source confirming the completion of the operation. This message includes the MESSAGE_ID_ACK object to acknowledge reception of the received Notify message. This Notify message also includes the MESSAGE_ID object. The ACK_Desired flag MUST be set in this object to request the receiver to send an acknowledgment for the message (see [RFC2961]).
然后，目的地向源可靠地发送通知消息，确认操作完成。此消息包括消息\u ID\u ACK对象，用于确认接收到的Notify消息的接收。此通知消息还包括消息\u ID对象。必须在此对象中设置ACK_Desired标志，以请求接收方发送消息确认（请参见[RFC2961]）。
3) When the source node receives this Notify message, it switches to receive traffic from the working LSP.
3) 当源节点收到此通知消息时，它将切换为从工作LSP接收流量。
The source node then sends an Ack message to the destination node confirming that the LSP has been reverted.
然后，源节点向目标节点发送确认LSP已恢复的Ack消息。
3. Finally, clear the O bit of the PROTECTION object sent over the protecting LSP.
3. 最后，清除通过保护LSP发送的保护对象的O位。
For "1:N Protection with Extra-traffic", reversion to the recovered LSP occurs by using the following sequence:
对于“具有额外流量的1:N保护”，使用以下顺序恢复到恢复的LSP：
1. Clear the A bit of the ADMIN_STATUS object if set for the recovered LSP.
1. 如果为恢复的LSP设置了ADMIN_STATUS对象，则清除该对象的A位。
2. Then, apply the method described below to switch normal traffic back from the protecting to the recovered LSP. This is performed by using the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request).
2. 然后，应用下面描述的方法将正常通信量从保护切换回恢复的LSP。这是通过使用新的错误代码/子代码“Notify error/LSP Recovered”（返回请求）执行的。
The procedure is as follows:
程序如下：
1) The initiating (source) node sends the normal traffic onto both the working and the protecting LSPs. Once completed, the source node sends reliably a Notify message to the destination
1) 发起（源）节点将正常流量发送到工作和保护LSP。一旦完成，源节点将可靠地向目标发送通知消息
with the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request). This Notify message includes the MESSAGE_ID object. The ACK_Desired flag MUST be set in this object to request the receiver to send an acknowledgment for the message (see [RFC2961]).
使用新的错误代码/子代码“通知错误/LSP已恢复”（切换请求）。此通知消息包括消息\u ID对象。必须在此对象中设置ACK_Desired标志，以请求接收方发送消息确认（请参见[RFC2961]）。
2) Upon receipt of this message, the destination selects the traffic from the working LSP. At the same time, it transmits the traffic onto both the working and protecting LSP.
2) 收到此消息后，目的地从工作LSP中选择通信量。同时，它将流量传输到工作LSP和保护LSP。
The destination then sends reliably a Notify message to the source confirming the completion of the operation. This message includes the MESSAGE_ID_ACK object to acknowledge reception of the received Notify message. This Notify message also includes the MESSAGE_ID object. The ACK_Desired flag MUST be set in this object to request the receiver to send an acknowledgment for the message (see [RFC2961]).
然后，目的地向源可靠地发送通知消息，确认操作完成。此消息包括消息\u ID\u ACK对象，用于确认接收到的Notify消息的接收。此通知消息还包括消息\u ID对象。必须在此对象中设置ACK_Desired标志，以请求接收方发送消息确认（请参见[RFC2961]）。
3) When the source node receives this Notify message, it switches to receive traffic from the working LSP, and stops transmitting traffic on the protecting LSP.
3) 当源节点收到此通知消息时，它切换到从工作LSP接收流量，并停止在保护LSP上传输流量。
The source node then sends an Ack message to the destination node confirming that the LSP has been reverted.
然后，源节点向目标节点发送确认LSP已恢复的Ack消息。
4) Upon receipt of this message, the destination node stops transmitting traffic along the protecting LSP.
4) 在接收到该消息后，目的地节点停止沿保护LSP传输业务。
3. Finally, clear the O bit of the PROTECTION object sent over the protecting LSP.
3. 最后，清除通过保护LSP发送的保护对象的O位。
For "Rerouting without Extra-traffic" (including the shared recovery case), reversion implies that the formerly working LSP has not been torn down by the head-end node upon PathErr message reception, i.e., the head-end node kept refreshing the working LSP under failure condition. This ensures that the exact same resources are retrieved after reversion switching (except if the working LSP required re-signaling). Re-activation is performed using the following sequence:
对于“无额外流量的重新路由”（包括共享恢复情况），恢复意味着在接收PathErr消息时，前端节点没有拆掉以前工作的LSP，即在故障情况下，前端节点一直刷新工作的LSP。这可确保在反向切换后检索到完全相同的资源（除非工作LSP需要重新信令）。使用以下顺序执行重新激活：
1. Clear the A bit of the ADMIN_STATUS object if set for the recovered LSP.
1. 如果为恢复的LSP设置了ADMIN_STATUS对象，则清除该对象的A位。
2. Then, apply the method described below to switch normal traffic back from the protecting to the recovered LSP. This is performed by using the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request).
2. 然后，应用下面描述的方法将正常通信量从保护切换回恢复的LSP。这是通过使用新的错误代码/子代码“Notify error/LSP Recovered”（返回请求）执行的。
The procedure is as follows:
程序如下：
1) The initiating (source) node sends the normal traffic onto both the working and the protecting LSPs. Once completed, the source node sends reliably a Notify message to the destination with the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request). This Notify message includes the MESSAGE_ID object. The ACK_Desired flag MUST be set in this object to request the receiver to send an acknowledgment for the message (see [RFC2961]).
1) 发起（源）节点将正常流量发送到工作和保护LSP。一旦完成，源节点将可靠地向目标发送通知消息，其中包含新的错误代码/子代码“Notify error/LSP Recovered”（切换请求）。此通知消息包括消息\u ID对象。必须在此对象中设置ACK_Desired标志，以请求接收方发送消息确认（请参见[RFC2961]）。
2) Upon receipt of this message, the destination selects the traffic from the working LSP. At the same time, it transmits the traffic onto both the working and protecting LSP.
2) 收到此消息后，目的地从工作LSP中选择通信量。同时，它将流量传输到工作LSP和保护LSP。
The destination then sends reliably a Notify message to the source confirming the completion of the operation. This message includes the MESSAGE_ID_ACK object to acknowledge reception of the received Notify message. This Notify message also includes the MESSAGE_ID object. The ACK_Desired flag MUST be set in this object to request the receiver to send an acknowledgment for the message (see [RFC2961]).
然后，目的地向源可靠地发送通知消息，确认操作完成。此消息包括消息\u ID\u ACK对象，用于确认接收到的Notify消息的接收。此通知消息还包括消息\u ID对象。必须在此对象中设置ACK_Desired标志，以请求接收方发送消息确认（请参见[RFC2961]）。
3) When the source node receives this Notify message, it switches to receive traffic from the working LSP, and stops transmitting traffic on the protecting LSP.
3) 当源节点收到此通知消息时，它切换到从工作LSP接收流量，并停止在保护LSP上传输流量。
The source node then sends an Ack message to the destination node confirming that the LSP has been reverted.
然后，源节点向目标节点发送确认LSP已恢复的Ack消息。
4) Upon receipt of this message, the destination node stops transmitting traffic along the protecting LSP.
4) 在接收到该消息后，目的地节点停止沿保护LSP传输业务。
3. Finally, de-activate the protecting LSP by setting the S bit to 1 in the PROTECTION object sent over the protecting LSP.
3. 最后，通过将通过保护LSP发送的保护对象中的S位设置为1来停用保护LSP。
This section specifies the control plane behavior when using several commands (see [RFC4427]) that can be used to influence the recovery operations.
本节指定了使用可用于影响恢复操作的多个命令（请参见[RFC4427]）时的控制平面行为。
A. Lockout of recovery LSP:
A.恢复LSP的锁定：
The Lockout (L) bit of the ADMIN_STATUS object is used following the rules defined in Section 8 of [RFC3471] and Section 7 of [RFC3473]. The L bit must be set together with the Reflect (R) bit in the ADMIN_STATUS object sent in the Path message. Upon reception of the
ADMIN_STATUS对象的锁定（L）位按照[RFC3471]第8节和[RFC3473]第7节中定义的规则使用。L位必须与路径消息中发送的ADMIN_STATUS对象中的Reflect（R）位一起设置。在收到
Resv message with the L bit set, this forces the recovery LSP to be temporarily unavailable to transport traffic (either normal or extra-traffic). Unlock is performed by clearing the L bit, following the rules defined in Section 7 of [RFC3473]. This procedure is only applicable when the LSP Protection Type Flag is set to either 0x04 (1:N Protection with Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 Bidirectional Protection).
设置了L位的Resv消息，这将强制恢复LSP对传输流量（正常或额外流量）暂时不可用。按照[RFC3473]第7节中定义的规则，通过清除L位来执行解锁。仅当LSP保护类型标志设置为0x04（具有额外流量的1:N保护）或0x08（1+1单向保护）或0x10（1+1双向保护）时，此过程才适用。
The updated format of the ADMIN_STATUS object to include the L bit is as follows:
包含L位的ADMIN_STATUS对象的更新格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(196)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |L|I|C|T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(196)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |L|I|C|T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lockout (L): 1 bit
锁定（L）：1位
When set, forces the recovery LSP to be temporarily unavailable to transport traffic (either normal or extra traffic).
设置后，强制恢复LSP对传输流量（正常或额外流量）暂时不可用。
The R (Reflect), T (Testing), A (Administratively down), and D (Deletion in progress) bits are defined in [RFC3471]. The C (Call control) bit is defined in [GMPLS-CALL], and the I (Inhibit alarm communication) bit in [RFC4783].
[RFC3471]中定义了R（反射）、T（测试）、A（管理性下降）和D（正在删除）位。C（呼叫控制）位在[GMPLS-Call]中定义，I（禁止报警通信）位在[RFC4783]中定义。
B. Lockout of normal traffic:
B.正常交通的锁定：
The O bit of the PROTECTION object is set to 1 to force the recovery LSP to be temporarily unavailable to transport normal traffic. This operation MUST NOT occur unless the working LSP is carrying the normal traffic. Unlock is performed by clearing the O bit over the protecting LSP. This procedure is only applicable when the LSP Protection Type Flag is set to either 0x04 (1:N Protection with Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 Bidirectional Protection).
保护对象的O位设置为1，以强制恢复LSP暂时不可用于传输正常流量。除非工作LSP承载正常通信量，否则不得进行此操作。解锁通过清除保护LSP上的O位来执行。仅当LSP保护类型标志设置为0x04（具有额外流量的1:N保护）或0x08（1+1单向保护）或0x10（1+1双向保护）时，此过程才适用。
C. Forced switch for normal traffic:
C.正常交通的强制开关：
Recovery signaling is initiated that switches normal traffic to the recovery LSP following the procedures defined in Section 6, 7, 8, and 9.
启动恢复信令，按照第6、7、8和9节中定义的程序将正常通信量切换到恢复LSP。
D. Requested switch for normal traffic:
D.正常交通的请求交换机：
Recovery signaling is initiated that switches normal traffic to the recovery LSP following the procedures defined in Section 6, 7, 8, and 9. This happens unless a fault condition exists on other LSPs or spans (including the recovery LSP), or a switch command of equal or higher priority is in effect.
启动恢复信令，按照第6、7、8和9节中定义的程序将正常通信量切换到恢复LSP。除非其他LSP或跨度（包括恢复LSP）上存在故障条件，或同等或更高优先级的切换命令生效，否则会发生这种情况。
E. Requested switch for recovery LSP:
E.恢复LSP的请求交换机：
Recovery signaling is initiated that switches normal traffic to the working LSP following the procedure defined in Section 12. This request is executed except if a fault condition exists on the working LSP or an equal or higher priority switch command is in effect.
启动恢复信令，按照第12节中定义的程序将正常业务切换到工作LSP。除非工作LSP上存在故障或同等或更高优先级的开关命令生效，否则将执行此请求。
This section describes the extensions to the PROTECTION object to broaden its applicability to end-to-end LSP recovery.
本节介绍保护对象的扩展，以扩大其适用性，实现端到端LSP恢复。
The format of the PROTECTION Object (Class-Num = 37, C-Type = 2) is as follows:
保护对象（类别Num=37，C-Type=2）的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(37) | C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(37) | C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Secondary (S): 1 bit
辅助：1位
When set to 1, this bit indicates that the requested LSP is a secondary LSP. When set to 0 (default), it indicates that the requested LSP is a primary LSP.
当设置为1时，此位表示请求的LSP是辅助LSP。当设置为0（默认值）时，表示请求的LSP是主LSP。
Protecting (P): 1 bit
保护（P）：1位
When set to 1, this bit indicates that the requested LSP is a protecting LSP. When set to 0 (default), it indicates that the requested LSP is a working LSP. The combination, S set to 1 with P set to 0 is not valid.
当设置为1时，此位表示请求的LSP是保护LSP。当设置为0（默认值）时，表示请求的LSP是工作LSP。S设置为1，P设置为0的组合无效。
Notification (N): 1 bit
通知（N）：1位
When set to 1, this bit indicates that the control plane message exchange is only used for notification during protection switching. When set to 0 (default), it indicates that the control plane message exchanges are used for protection-switching purposes. The N bit is only applicable when the LSP Protection Type Flag is set to either 0x04 (1:N Protection with Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 Bidirectional Protection). The N bit MUST be set to 0 in any other case.
当设置为1时，该位表示控制平面消息交换仅用于保护切换期间的通知。当设置为0（默认值）时，表示控制平面消息交换用于保护切换目的。仅当LSP保护类型标志设置为0x04（具有额外流量的1:N保护）或0x08（1+1单向保护）或0x10（1+1双向保护）时，N位才适用。在任何其他情况下，N位必须设置为0。
Operational (O): 1 bit
操作（O）：1位
When set to 1, this bit indicates that the protecting LSP is carrying the normal traffic after protection switching. The O bit is only applicable when the P bit is set to 1, and the LSP Protection Type Flag is set to either 0x04 (1:N Protection with Extra-Traffic), or 0x08 (1+1 Unidirectional Protection) or 0x10 (1+1 Bidirectional Protection). The O bit MUST be set to 0 in any other case.
当设置为1时，该位表示保护LSP在保护切换后承载正常业务。O位仅在P位设置为1时适用，并且LSP保护类型标志设置为0x04（具有额外流量的1:N保护）或0x08（1+1单向保护）或0x10（1+1双向保护）。在任何其他情况下，O位必须设置为0。
Reserved: 5 bits
保留：5位
This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be passed through unmodified by transit nodes.
此字段是保留的。传输时必须将其设置为零，接收时必须忽略。这些位应在传输节点未修改的情况下通过。
LSP (Protection Type) Flags: 6 bits
LSP（保护类型）标志：6位
Indicates the desired end-to-end LSP recovery type. A value of 0 implies that the LSP is "Unprotected". Only one value SHOULD be set at a time. The following values are defined. All other values are reserved.
指示所需的端到端LSP恢复类型。值为0表示LSP“未受保护”。一次只能设置一个值。定义了以下值。所有其他值均保留。
0x00 Unprotected 0x01 (Full) Rerouting 0x02 Rerouting without Extra-Traffic 0x04 1:N Protection with Extra-Traffic 0x08 1+1 Unidirectional Protection 0x10 1+1 Bidirectional Protection
0x00未受保护的0x01（完整）重路由0x02无额外流量重路由0x04 1:N有额外流量的保护0x08 1+1单向保护0x10 1+1双向保护
Reserved: 10 bits
保留：10位
This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be passed through unmodified by transit nodes.
此字段是保留的。传输时必须将其设置为零，接收时必须忽略。这些位应在传输节点未修改的情况下通过。
Link Flags: 6 bits
链接标志：6位
Indicates the desired link protection type (see [RFC3471]).
指示所需的链路保护类型（请参阅[RFC3471]）。
Reserved field: 32 bits
保留字段：32位
Encoding of this field is detailed in [RFC4873].
[RFC4873]中详细说明了该字段的编码。
Intermediate and egress nodes processing a Path message containing a PROTECTION object MUST verify that the requested LSP Protection Type can be satisfied by the incoming interface. If it cannot, the node MUST generate a PathErr message, with the new error code/sub-code "Routing problem/Unsupported LSP Protection".
处理包含保护对象的路径消息的中间节点和出口节点必须验证传入接口是否能够满足请求的LSP保护类型。如果不能，则节点必须生成一条PathErr消息，其中包含新的错误代码/子代码“路由问题/不支持的LSP保护”。
Intermediate nodes processing a Path message containing a PROTECTION object with the LSP Protection Type 0x02 (Rerouting without Extra-Traffic) value set and a PRIMARY_PATH_ROUTE object (see Section 15) MUST verify that the requested LSP Protection Type can be supported by the outgoing interface. If it cannot, the node MUST generate a PathErr message with the new error code/sub-code "Routing problem/Unsupported LSP Protection".
处理包含设置了LSP保护类型0x02（无额外流量的重新路由）值的保护对象和主路径路由对象（参见第15节）的路径消息的中间节点必须验证传出接口是否支持请求的LSP保护类型。如果不能，则节点必须生成带有新错误代码/子代码“路由问题/不支持的LSP保护”的PathErr消息。
The PRIMARY_PATH_ROUTE object (PPRO) is defined to inform nodes along the path of a secondary protecting LSP about which resources (link/nodes) are being used by the associated primary protected LSP (as specified by the Association ID field). If the LSP Protection Type value is set to 0x02 (Rerouting without Extra-Traffic), this object SHOULD be present in the Path message for the pre-provisioning of the secondary protecting LSP to enable recovery resource sharing between one or more secondary protecting LSPs (see Section 9). This document does not assume or preclude any other usage for this object.
主路径路由对象（PPRO）被定义为通知辅助保护LSP路径上的节点相关联的主保护LSP正在使用哪些资源（链路/节点）（由关联ID字段指定）。如果LSP保护类型值设置为0x02（在无额外流量的情况下重新路由），则此对象应出现在路径消息中，用于预设置辅助保护LSP，以启用一个或多个辅助保护LSP之间的恢复资源共享（请参阅第9节）。本文档不假定或排除此对象的任何其他用途。
PRIMARY_PATH_ROUTE objects carry information extracted from the EXPLICIT ROUTE object and/or the RECORD ROUTE object of the primary working LSPs they protect. Selection of the PPRO content is up to local policy of the head-end node that initiates the request. Therefore, the information included in these objects can be used as policy-based admission control to ensure that recovery resources are only shared between secondary protecting LSPs whose associated primary LSPs have link/node/SRLG disjoint paths.
主路径路由对象携带从其保护的主工作LSP的显式路由对象和/或记录路由对象提取的信息。PPRO内容的选择取决于发起请求的前端节点的本地策略。因此，这些对象中包含的信息可以用作基于策略的许可控制，以确保恢复资源仅在辅助保护LSP之间共享，这些辅助保护LSP的关联主LSP具有链路/节点/SRLG不相交路径。
The primary path route is specified via the PRIMARY_PATH_ROUTE object (PPRO). The Primary Path Route Class Number (Class-Num) of form 0bbbbbbb 38.
主路径路由通过主路径路由对象（PPRO）指定。表0BBB 38的主路径路由类别编号（类别编号）。
Currently one C-Type (Class-Type) is defined, Type 1, Primary Path Route. The PRIMARY_PATH_ROUTE object has the following format:
目前定义了一个C类型（类类型），类型1，主路径路由。主路径路由对象具有以下格式：
Class-Num = 38 (of the form 0bbbbbbb), C-Type = 1
类别编号=38（形式为0BBB），C类型=1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of a PRIMARY_PATH_ROUTE object are a series of variable-length data items called subobjects (see Section 15.3).
主路径路由对象的内容是一系列称为子对象的可变长度数据项（见第15.3节）。
To signal a secondary protecting LSP, the Path message MAY include one or multiple PRIMARY_PATH_ROUTE objects, where each object is meaningful. The latter is useful when a given secondary protecting LSP must be link/node/SRLG disjoint from more than one primary LSP (i.e., is protecting more than one primary LSP).
为了向辅助保护LSP发送信号，路径消息可以包括一个或多个主路径路由对象，其中每个对象都是有意义的。当给定的辅助保护LSP必须与多个主LSP（即，保护多个主LSP）断开链路/节点/SRLG时，后者非常有用。
The PRIMARY_PATH_ROUTE object is defined as a list of variable-length data items called subobjects. These subobjects are derived from the subobjects of the EXPLICIT ROUTE and/or RECORD ROUTE object of the primary working LSP(s).
主路径路由对象定义为称为子对象的可变长度数据项列表。这些子对象派生自主工作LSP的显式路由和/或记录路由对象的子对象。
Each subobject has its own length field. The length contains the total length of the subobject in bytes, including the Type and Length fields. The length MUST always be a multiple of 4, and at least 4.
每个子对象都有自己的长度字段。长度包含子对象的总长度（字节），包括类型和长度字段。长度必须始终为4的倍数，且至少为4。
The following subobjects are currently defined for the PRIMARY_PATH_ROUTE object:
当前为主路径路由对象定义了以下子对象：
- Sub-Type 1: IPv4 Address (see [RFC3209]) - Sub-Type 2: IPv6 Address (see [RFC3209]) - Sub-Type 3: Label (see [RFC3473]) - Sub-Type 4: Unnumbered Interface (see [RFC3477])
- 子类型1：IPv4地址（请参见[RFC3209]）-子类型2：IPv6地址（请参见[RFC3209]）-子类型3：标签（请参见[RFC3473]）-子类型4：未编号接口（请参见[RFC3477]）
An empty PPRO with no subobjects is considered illegal. If there is no first subobject, the corresponding Path message is also in error, and the receiving node SHOULD return a PathErr message with the new error code/sub-code "Routing Problem/Bad PRIMARY_PATH_ROUTE object".
没有子对象的空PPRO被视为非法。如果没有第一个子对象，则相应的路径消息也会出错，并且接收节点应返回一条PathErr消息，其中包含新的错误代码/子代码“Routing Problem/Bad PRIMARY_Path_ROUTE object”。
Note: an intermediate node processing a PPRO can derive SRLG identifiers from the local IGP-TE database using its Type 1, 2, or 4 subobject values as pointers to the corresponding TE Links (assuming each of them has an associated SRLG TE attribute).
注意：处理PPRO的中间节点可以使用其类型1、2或4子对象值作为指向相应TE链接的指针，从本地IGP-TE数据库派生SRLG标识符（假设它们中的每一个都有关联的SRLG TE属性）。
The PRIMARY_PATH_ROUTE object MAY only be used when all GMPLS nodes along the path support the PRIMARY_PATH_ROUTE object and a secondary protecting LSP is being requested. The PRIMARY_PATH_ROUTE object is assigned a class value of the form 0bbbbbbb. Receiving GMPLS nodes along the path that do not support this object MUST return a PathErr message with the "Unknown Object Class" error code (see [RFC2205]).
只有当路径上的所有GMPLS节点都支持主路径路由对象并且正在请求辅助保护LSP时，才能使用主路径路由对象。主路径路由对象被指定一个0bbb形式的类值。沿路径接收不支持此对象的GMPLS节点时，必须返回带有“未知对象类”错误代码的PathErr消息（请参见[RFC2205]）。
Also, the following restrictions MUST be applied with respect to the PPRO usage:
此外，PPRO的使用必须遵守以下限制：
- PPROs MAY only be included in Path messages when signaling secondary protecting LSPs (S bit = 1 and P bit = 1) and when the LSP Protection Type value is set to 0x02 (without Rerouting Extra-Traffic) in the PROTECTION object (see Section 14).
- 当向二级保护LSP（S位=1和P位=1）发送信号时，以及当保护对象中的LSP保护类型值设置为0x02（无需重新路由额外流量）时，PPRO只能包含在路径消息中（见第14节）。
- PRROs SHOULD be present in the Path message for the pre-provisioning of the secondary protecting LSP to enable recovery resource sharing between one or more secondary protecting LSPs (see Section 15.4).
- PRROs应出现在路径消息中，用于预配置辅助保护LSP，以实现一个或多个辅助保护LSP之间的恢复资源共享（参见第15.4节）。
- PPROs MUST NOT be used in any other conditions. In particular, if a PPRO is received when the S bit is set to 0 in the PROTECTION object, the receiving node MUST return a PathErr message with the new error code/sub-code "Routing Problem/PRIMARY_PATH_ROUTE object not applicable".
- 不得在任何其他条件下使用PPRO。特别是，如果在保护对象中将S位设置为0时接收到PPRO，则接收节点必须返回带有新错误代码/子代码“路由问题/主路径\路由对象不适用”的PathErr消息。
- Crossed exchanges of PPROs over primary LSPs are forbidden (i.e., their usage is restricted to a single set of protected LSPs).
- 禁止在主LSP上交叉交换PPRO（即，它们的使用仅限于一组受保护的LSP）。
- The PPRO's content MUST NOT include subobjects coming from other PPROs. In particular, received PPROs MUST NOT be reused to establish other working or protecting LSPs.
- PPRO的内容不得包含来自其他PPRO的子对象。特别是，不得重复使用收到的PPRO来建立其他工作或保护LSP。
The PPRO enables sharing recovery resources between a given secondary protecting LSP and one or more secondary protecting LSPs if their corresponding primary working LSPs have mutually (link/node/SRLG) disjoint paths. Consider a node N through which n secondary protecting LSPs (say, P[1],...,P[n]) have already been established that protect n primary working LSPs (say, P'[1],...,P'[n]). Suppose also that these n secondary working LSPs share a given outgoing link resource (say r).
如果给定的辅助保护LSP和一个或多个辅助保护LSP的对应主工作LSP具有相互（链路/节点/SRLG）不相交的路径，则PPRO允许在它们之间共享恢复资源。考虑一个节点N，通过N个二次保护LSPs（例如，P（1），…，P[N]）已经被建立来保护N主工作LSPs（例如，p′（1），…，p′[n]）。还假设这n个辅助工作lsp共享给定的传出链路资源（例如r）。
Now, suppose that node N receives a Path message for an additional secondary protecting LSP (say, Q, protecting Q'). The PPRO carried by this Path message is processed as follows:
现在，假设节点N接收到用于附加辅助保护LSP（例如，Q，protecting Q'）的路径消息。此路径消息携带的PPRO处理如下：
- N checks whether the primary working LSPs P'[1],...,P'[n] associated with the LSPs P[1],...,P[n], respectively, have any link, node, and SLRG in common with the primary working Q' (associated with Q) by comparing the stored PPRO subobjects associated with P'[1],...,P'[n] with the PPRO subobjects associated with Q' received in the Path message.
- N通过将与P'[1]、…、P'[N]关联的存储PPRO子对象与路径消息中接收到的与Q'关联的PPRO子对象进行比较，检查分别与LSP P'[1]、…、P'[N]关联的主工作LSP P'[1]、…、P'[N]是否具有与主工作Q'（与Q关联）相同的任何链路、节点和SLRG。
- If this is the case, N SHOULD NOT attempt to share the outgoing link resource r between P[1],...,P[n] and Q. However, upon local policy decision, N MAY allocate another available (shared) link other than r for use by Q. If this is not the case (upon the local policy decision that no other link is allowed to be allocated for Q) or if no other link is available for Q, N SHOULD return a PathErr message with the new error code/sub-code "Admission Control Failure/LSP Admission Failure".
- 如果是这种情况，N不应尝试在P[1]、…、P[N]和Q之间共享传出链路资源r。但是，根据本地策略决定，N可以分配r以外的另一个可用（共享）链路供Q使用。如果不是这种情况（根据本地策略决定，不允许为Q分配任何其他链路）或者，如果没有其他链接可用于Q，则N应返回一条PathErr消息，其中包含新的错误代码/子代码“准入控制失败/LSP准入失败”。
- Otherwise (if P'[1],...,P'[n] and Q' are fully disjoint), the link r selected by N for the LSP Q MAY be exactly the same as the one selected for the LSPs P[1],...,P[n]. This happens after verifying (from the node's local policy) that the selected link r can be shared between these LSPs. If this is not the case (for instance, the sharing ratio has reached its maximum for that link), and if upon local policy decision, no other link is allowed to be allocated for Q, N SHOULD return a PathErr message with the error code/sub-code "Admission Control Failure/Requested Bandwidth Unavailable" (see [RFC2205]). Otherwise (if no other link is available), N SHOULD return a PathErr message with the new error code/sub-code "Admission Control Failure/LSP Admission Failure".
- 否则（如果P'[1]、…、P'[n]和Q'完全不相交），则n为LSP Q选择的链路r可以与为LSP P[1]、…、P[n]选择的链路r完全相同。这是在验证（从节点的本地策略）所选链路r可以在这些LSP之间共享之后发生的。如果情况并非如此（例如，该链路的共享率已达到其最大值），并且如果根据本地策略决定，不允许为Q分配其他链路，则N应返回错误代码/子代码为“准入控制失败/请求的带宽不可用”的PathErr消息（请参阅[RFC2205]）。否则（如果没有其他链接可用），N应返回带有新错误代码/子代码“准入控制失败/LSP准入失败”的PathErr消息。
Note that the process, through which m out of the n (m =< n) secondary protecting LSPs' PPROs may be selected on a local basis to perform the above comparison and subsequent link selection, is out of scope of this document.
请注意，可以在本地基础上选择n个（m=<n）二级保护LSP的PPRO中的m个来执行上述比较和后续链路选择的过程不在本文档的范围内。
The ASSOCIATION object is used to associate LSPs with each other. In the context of end-to-end LSP recovery, the association MUST only identify LSPs that support the same Tunnel ID as well as the same tunnel sender address and tunnel endpoint address. The Association Type, Association Source, and Association ID fields of the object together uniquely identify an association. The object uses an object class number of the form 11bbbbbb to ensure compatibility with non-supporting nodes.
关联对象用于将LSP彼此关联。在端到端LSP恢复的上下文中，关联必须仅标识支持相同隧道ID以及相同隧道发送方地址和隧道端点地址的LSP。对象的关联类型、关联源和关联ID字段一起唯一标识关联。该对象使用11bbbb形式的对象类编号，以确保与非支持节点的兼容性。
The ASSOCIATION object is used to associate LSPs with each other.
关联对象用于将LSP彼此关联。
The IPv4 ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = 1) has the format:
IPv4关联对象（11bbbbbb格式的类Num，值=199，C-Type=1）的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(199)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(199)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = 2) has the format:
IPv6关联对象（11bbbbbb格式的类Num，值=199，C-Type=2）的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(199)| C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Association Source |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(199)| C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Association Source |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Association Type: 16 bits
关联类型：16位
Indicates the type of association being identified. Note that this value is considered when determining association. The following are values defined in this document.
指示要标识的关联的类型。请注意，在确定关联时会考虑此值。以下是本文档中定义的值。
Value Type
----- ----
0 Reserved
1 Recovery (R)
Value Type
----- ----
0 Reserved
1 Recovery (R)
Association ID: 16 bits
关联ID:16位
A value assigned by the LSP head-end. When combined with the Association Type and Association Source, this value uniquely identifies an association.
由LSP头端指定的值。当与关联类型和关联源组合时，此值唯一标识关联。
Association Source: 4 or 16 bytes
关联源：4或16字节
An IPv4 or IPv6 address, respectively, that is associated to the node that originated the association.
分别与发起关联的节点关联的IPv4或IPv6地址。
In the end-to-end LSP recovery context, the ASSOCIATION object is used to associate a recovery LSP with the LSP(s) it is protecting or a protected LSP(s) with its recovery LSP. The object is carried in Path messages. More than one object MAY be carried in a single Path message.
在端到端LSP恢复上下文中，关联对象用于将恢复LSP与其保护的LSP或受保护的LSP与其恢复LSP关联。对象在路径消息中携带。单个路径消息中可以携带多个对象。
Transit nodes MUST transmit, without modification, any received ASSOCIATION object in the corresponding outgoing Path message.
传输节点必须在不进行修改的情况下传输相应传出路径消息中接收到的任何关联对象。
An ASSOCIATION object with an Association Type set to the value "Recovery" is used to identify an LSP-Recovery-related association. Any node associating a recovery LSP MUST insert an ASSOCIATION object with the following setting:
关联类型设置为值“Recovery”的关联对象用于标识与LSP恢复相关的关联。与恢复LSP关联的任何节点都必须插入具有以下设置的关联对象：
- The Association Type MUST be set to the value "Recovery" in the Path message of the recovery LSP.
- 关联类型必须设置为恢复LSP路径消息中的值“Recovery”。
- The (IPv4/IPv6) Association Source MUST be set to the tunnel sender address of the LSP being protected.
- （IPv4/IPv6）关联源必须设置为受保护LSP的隧道发送方地址。
- The Association ID MUST be set to the LSP ID of the LSP being protected by this LSP or the LSP protecting this LSP. If unknown, this value is set to its own signaled LSP_ID value (default). Also, the value of the Association ID MAY change during the lifetime of the LSP.
- 关联ID必须设置为受此LSP保护的LSP或保护此LSP的LSP的LSP ID。如果未知，此值将设置为其自己的信号LSP_ID值（默认值）。此外，关联ID的值可以在LSP的生存期期间改变。
Terminating nodes use received ASSOCIATION object(s) with the Association Type set to the value "Recovery" to associate a recovery LSP with its matching working LSP. This information is used to bind the appropriate working and recovery LSPs together. Such nodes MUST ensure that the received Path messages, including ASSOCIATION object(s), are processed with the appropriate PROTECTION object settings, if present (see Section 14 for PROTECTION object processing). Otherwise, this node MUST return a PathErr message with the new error code/sub-code "LSP Admission Failure/Bad Association Type". Similarly, terminating nodes receiving a Path message with a
终止节点使用接收到的关联类型设置为值“Recovery”的关联对象将恢复LSP与其匹配的工作LSP关联。此信息用于将适当的工作和恢复LSP绑定在一起。此类节点必须确保接收到的路径消息（包括关联对象）使用适当的保护对象设置（如果存在）进行处理（有关保护对象处理，请参阅第14节）。否则，此节点必须返回带有新错误代码/子代码“LSP准入失败/错误关联类型”的PathErr消息。类似地，使用
PROTECTION object requiring association between working and recovery LSPs MUST include an ASSOCIATION object. Otherwise, such nodes MUST return a PathErr message with the new error code/sub-code "Routing Problem/PROTECTION object not Applicable".
需要工作LSP和恢复LSP之间关联的保护对象必须包含关联对象。否则，此类节点必须返回带有新错误代码/子代码“路由问题/保护对象不适用”的PathErr消息。
This section presents the RSVP message-related formats as modified by this document. Unmodified RSVP message formats are not listed.
本节介绍本文件修改的RSVP消息相关格式。未修改的RSVP消息格式未列出。
The format of a Path message is as follows:
Path消息的格式如下所示：
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ... ]
[ <ADMIN_STATUS> ]
[ <ASSOCIATION> ... ]
[ <PRIMARY_PATH_ROUTE> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ... ]
[ <ADMIN_STATUS> ]
[ <ASSOCIATION> ... ]
[ <PRIMARY_PATH_ROUTE> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
The format of the <sender descriptor> for unidirectional and bidirectional LSPs is not modified by the present document.
单向和双向LSP的<sender descriptor>格式不受本文件的修改。
The format of a Resv message is as follows:
Resv消息的格式如下所示：
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <PROTECTION> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <PROTECTION> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> is not modified by this document.
<flow descriptor list>未被本文档修改。
The security threats identified in [RFC4426] may be experienced due to the exchange of RSVP messages and information as detailed in this document. The following security mechanisms apply.
[RFC4426]中确定的安全威胁可能由于交换本文件详述的RSVP消息和信息而受到影响。以下安全机制适用。
RSVP signaling MUST be able to provide authentication and integrity. Authentication is required to ensure that the signaling messages are originating from the right place and have not been modified in transit.
RSVP信令必须能够提供身份验证和完整性。需要进行身份验证，以确保信令消息来自正确的位置，并且在传输过程中未被修改。
For this purpose, [RFC2747] provides the required RSVP message authentication and integrity for hop-by-hop RSVP message exchanges. For non hop-by-hop RSVP message exchanges the standard IPsec-based integrity and authentication can be used as explained in [RFC3473].
为此，[RFC2747]为逐跳RSVP消息交换提供所需的RSVP消息身份验证和完整性。对于非逐跳RSVP消息交换，可以使用标准的基于IPsec的完整性和身份验证，如[RFC3473]中所述。
Moreover, this document makes use of the Notify message exchange. This precludes RSVP's hop-by-hop integrity and authentication model. In the case, when the same level of security provided by [RFC2747] is desired, the standard IPsec based integrity and authentication can be used as explained in [RFC3473].
此外，本文档还使用了Notify消息交换。这排除了RSVP的逐跳完整性和身份验证模型。在这种情况下，当需要[RFC2747]提供相同级别的安全性时，可以使用标准的基于IPsec的完整性和身份验证，如[RFC3473]中所述。
To prevent the consequences of poorly applied protection and the increased risk of misconnection, in particular, when extra-traffic is involved, that would deliver the wrong traffic to the wrong destination, specific mechanisms have been put in place as described in Section 7.2, 8.3, and 10.
为了防止应用不当保护的后果和误连接风险的增加，特别是当涉及额外流量时，将错误的流量传送到错误的目的地，已经按照第7.2、8.3和10节中的描述建立了特定的机制。
IANA assigns values to RSVP protocol parameters. Within the current document, a PROTECTION object (new C-Type), a PRIMARY_PATH_ROUTE object, and an ASSOCIATION object are defined. In addition, new Error code/sub-code values are defined in this document. Finally, registration of the ADMIN_STATUS object bits is requested.
IANA为RSVP协议参数赋值。在当前文档中，定义了一个保护对象（新的C类型）、一个主路径路由对象和一个关联对象。此外，本文件中还定义了新的错误代码/子代码值。最后，请求注册ADMIN_状态对象位。
Two RSVP Class Numbers (Class-Num) and three Class Types (C-Types) values have to be defined by IANA in registry:
IANA必须在注册表中定义两个RSVP类别编号（类别编号）和三个类别类型（C类型）值：
http://www.iana.org/assignments/rsvp-parameters
http://www.iana.org/assignments/rsvp-parameters
1) PROTECTION object (defined in Section 14.1)
1) 保护对象（定义见第14.1节）
o PROTECTION object: Class-Num = 37
o 保护对象：Class Num=37
- Type 2: C-Type = 2
- 类型2:C-Type=2
2) PRIMARY_PATH_ROUTE object (defined in Section 15.1)
2) 主路径路由对象（定义见第15.1节）
o PRIMARY_PATH_ROUTE object: Class-Num = 38 (of the form 0bbbbbbb),
o 主路径路由对象：类Num=38（形式为0bbb），
- Primary Path Route: C-Type = 1
- 主路径路由：C-Type=1
3) ASSOCIATION object (defined in Section 16.1)
3) 关联对象（定义见第16.1节）
o ASSOCIATION object: Class-Num = 199 (of the form 11bbbbbb)
o 关联对象：类Num=199（形式为11bbbbbb）
- IPv4 Association: C-Type = 1 - IPv6 Association: C-Type = 2
- IPv4关联：C-Type=1-IPv6关联：C-Type=2
o Association Type
o 关联类型
The following values defined for the Association Type (16 bits) field of the ASSOCIATION object.
为关联对象的关联类型（16位）字段定义的以下值。
Value Type
----- ----
0 Reserved
1 Recovery (R)
Value Type
----- ----
0 Reserved
1 Recovery (R)
Assignment of values (from 2 to 65535) by IANA are subject to IETF expert review process, i.e., IETF Standards Track RFC Action.
IANA的赋值（从2到65535）受IETF专家评审程序的约束，即IETF标准跟踪RFC行动。
4) Error Code/Sub-code values
4) 错误代码/子代码值
The following Error code/sub-code values are defined in this document:
本文件中定义了以下错误代码/子代码值：
Error Code = 01: "Admission Control Failure" (see [RFC2205])
错误代码=01：“准入控制失败”（参见[RFC2205]）
o "Admission Control Failure/LSP Admission Failure" (4) o "Admission Control Failure/Bad Association Type" (5)
o “准入控制失败/LSP准入失败”（4）o“准入控制失败/不良关联类型”（5）
Error Code = 02: "Policy Control Failure" (see [RFC2205])
错误代码=02：“策略控制失败”（请参阅[RFC2205]）
o "Policy Control failure/Hard Pre-empted" (20)
o “策略控制失败/硬抢占”（20）
Error Code = 24: "Routing Problem" (see [RFC3209])
错误代码=24：“路由问题”（请参阅[RFC3209]）
o "Routing Problem/Unsupported LSP Protection" (17)
o "Routing Problem/PROTECTION object not applicable" (18)
o "Routing Problem/Bad PRIMARY_PATH_ROUTE object" (19)
o "Routing Problem/PRIMARY_PATH_ROUTE object not applicable" (20)
o "Routing Problem/Unsupported LSP Protection" (17)
o "Routing Problem/PROTECTION object not applicable" (18)
o "Routing Problem/Bad PRIMARY_PATH_ROUTE object" (19)
o "Routing Problem/PRIMARY_PATH_ROUTE object not applicable" (20)
Error Code = 25: "Notify Error" (see [RFC3209])
错误代码=25：“通知错误”（参见[RFC3209]）
o "Notify Error/LSP Failure" (9) o "Notify Error/LSP Recovered" (10) o "Notify Error/LSP Locally Failed" (11)
o “通知错误/LSP失败”（9）o“通知错误/LSP已恢复”（10）o“通知错误/LSP本地失败”（11）
5) Registration of the ADMIN_STATUS object bits
5) 管理状态对象位的注册
The ADMIN_STATUS object (Class-Num = 196, C-Type = 1) is defined in [RFC3473].
[RFC3473]中定义了管理状态对象（类Num=196，C-Type=1）。
IANA is also requested to track the ADMIN_STATUS bits extended by this document. For this purpose, the following new registry entries have been created:
IANA还被要求跟踪本文档扩展的管理状态位。为此，已创建以下新注册表项：
http://www.iana.org/assignments/gmpls-sig-parameters
http://www.iana.org/assignments/gmpls-sig-parameters
- ADMIN_STATUS bits:
- 管理单元状态位：
Name: ADMIN_STATUS bits
Format: 32-bit vector of bits
Position:
[0] Reflect (R) bit defined in [RFC3471]
[1..25] To be assigned by IANA via IETF Standards
Track RFC Action.
[26] Lockout (L) bit is defined in Section 13
[27] Inhibit alarm communication (I) in [RFC4783]
Name: ADMIN_STATUS bits
Format: 32-bit vector of bits
Position:
[0] Reflect (R) bit defined in [RFC3471]
[1..25] To be assigned by IANA via IETF Standards
Track RFC Action.
[26] Lockout (L) bit is defined in Section 13
[27] Inhibit alarm communication (I) in [RFC4783]
[28] Call control (C) bit is defined in
[GMPLS-CALL]
[29] Testing (T) bit is defined in [RFC3471]
[30] Administratively down (A) bit is defined in
[RFC3471]
[31] Deletion in progress (D) bit is defined in
[RFC3471]
[28] Call control (C) bit is defined in
[GMPLS-CALL]
[29] Testing (T) bit is defined in [RFC3471]
[30] Administratively down (A) bit is defined in
[RFC3471]
[31] Deletion in progress (D) bit is defined in
[RFC3471]
The authors would like to thank John Drake for his active collaboration, Adrian Farrel for his contribution to this document (in particular, to the Section 10 and 11) and his thorough review of the document, Bart Rousseau (for editorial review), Dominique Verchere, and Stefaan De Cnodder. Thanks also to Ichiro Inoue for his valuable comments.
作者要感谢约翰·德雷克（John Drake）的积极合作，阿德里安·法雷尔（Adrian Farrel）对本文件的贡献（特别是对第10节和第11节的贡献）以及他对本文件的全面审查，巴特·卢梭（编辑审查）、多米尼克·弗切尔（Dominique Verchere）和斯特凡·德克诺德（Stefaan De Cnodder）。还感谢井上一郎的宝贵评论。
The authors would also like to thank Lou Berger for the time and effort he spent together with the design team, in contributing to the present document.
作者还要感谢Lou Berger，感谢他与设计团队一起为本文件贡献的时间和精力。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961]Berger，L.，Gan，D.，Swallow，G.，Pan，P.，Tommasi，F.，和S.Molendini，“RSVP刷新开销减少扩展”，RFC 29612001年4月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477]Kompella，K.和Y.Rekhter，“资源预留协议中未编号链路的信令-流量工程（RSVP-TE）”，RFC 3477，2003年1月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[RFC4426] Lang, J., Rajagopalan, B., and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, March 2006.
[RFC4426]Lang，J.，Rajagopalan，B.，和D.Papadimitriou，“通用多协议标签交换（GMPLS）恢复功能规范”，RFC 4426，2006年3月。
[RFC4873] Berger, L., Bryskin, I., Papdimitriou, D., and A. Farrel, "GMPLS Segment Recovery," RFC 4873, May 2007.
[RFC4873]Berger，L.，Bryskin，I.，Papdimitriou，D.，和A.Farrel，“GMPLS段恢复”，RFC 4873，2007年5月。
[RFC4783] Berger, L., "GMPLS - Communication of Alarm Information", RFC 4783, December 2006.
[RFC4783]Berger，L.，“GMPLS-报警信息通信”，RFC 4783，2006年12月。
[CRANK] Farrel, A., Ed., "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", Work in Progress, January 2007.
[CRANK]Farrel，A.，Ed.，“MPLS和GMPLS RSVP-TE的回退信令扩展”，正在进行的工作，2007年1月。
[GMPLS-CALL] Papadimitriou, D., Ed., and A. Farrel, Ed., "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls", Work in Progress, January 2007.
[GMPLS-CALL]Papadimitriou，D.，Ed.，和A.Farrel，Ed.，“支持呼叫的通用MPLS（GMPLS）RSVP-TE信令扩展”，正在进行的工作，2007年1月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4427]Mannie，E.，Ed.和D.Papadimitriou，Ed.“通用多协议标签交换（GMPLS）的恢复（保护和恢复）术语”，RFC 4427，2006年3月。
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4874]Lee，CY.，Farrel，A.和S.De Cnodder，“排除路由-资源预留协议流量工程（RSVP-TE）的扩展”，RFC 48742007年4月。
[G.841] ITU-T, "Types and Characteristics of SDH Network Protection Architectures," Recommendation G.841, October 1998, available from http://www.itu.int.
[G.841]ITU-T，“SDH网络保护体系结构的类型和特征”，建议G.841，1998年10月，可从http://www.itu.int.
This document is the result of the CCAMP Working Group Protection and Restoration design team joint effort. The following are the authors that contributed to the present document:
本文件是CCAMP工作组保护和修复设计团队共同努力的结果。以下是编写本文件的作者：
Deborah Brungard (AT&T) Rm. D1-3C22 - 200, S. Laurel Ave. Middletown, NJ 07748, USA EMail: dbrungard@att.com
德博拉·布伦加德（美国电话电报公司）Rm。D1-3C22-200，美国新泽西州米德尔敦S.Laurel大道，邮编07748电子邮件：dbrungard@att.com
Sudheer Dharanikota EMail: sudheer@ieee.org
Sudheer Dharanikota电子邮件：sudheer@ieee.org
Guangzhi Li (AT&T) 180 Park Avenue Florham Park, NJ 07932, USA EMail: gli@research.att.com
李广志（AT&T）美国新泽西州弗洛勒姆公园公园大道180号，邮编07932电子邮件：gli@research.att.com
Eric Mannie (Perceval) Rue Tenbosch, 9 1000 Brussels, Belgium Phone: +32-2-6409194 EMail: eric.mannie@perceval.net
Eric Mannie（Perceval）Lue Tenbosch，9 1000比利时布鲁塞尔电话：+32-2-6409194电子邮件：Eric。mannie@perceval.net
Bala Rajagopalan (Intel Broadband Wireless Division) 2111 NE 25th Ave. Hillsboro, OR 97124, USA EMail: bala.rajagopalan@intel.com
巴拉·拉贾戈帕兰（英特尔宽带无线事业部）美国希尔斯博罗东北25大道2111号，邮编：97124电子邮件：巴拉。rajagopalan@intel.com
Editors' Addresses
编辑地址
Jonathan P. Lang Sonos 506 Chapala Street Santa Barbara, CA 93101, USA
美国加利福尼亚州圣巴巴拉查帕拉街506号乔纳森·P·朗·索诺斯，邮编：93101
EMail: jplang@ieee.org
EMail: jplang@ieee.org
Yakov Rekhter Juniper 1194 N. Mathilda Avenue Sunnyvale, CA 94089, USA
美国马蒂尔巴耶克山巴勒大街1199号
EMail: yakov@juniper.net
EMail: yakov@juniper.net
Dimitri Papadimitriou Alcatel Copernicuslaan 50 B-2018, Antwerpen, Belgium
迪米特里·帕帕迪米特里奥·阿尔卡特·哥白尼公司50 B-2018，比利时安特卫普
EMail: dimitri.papadimitriou@alcatel-lucent.be
EMail: dimitri.papadimitriou@alcatel-lucent.be
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。