Network Working Group L. Berger
Request for Comments: 4873 LabN Consulting
Updates: 3473, 4872 I. Bryskin
Category: Standards Track ADVA Optical
D. Papadimitriou
Alcatel
A. Farrel
Old Dog Consulting
May 2007
Network Working Group L. Berger
Request for Comments: 4873 LabN Consulting
Updates: 3473, 4872 I. Bryskin
Category: Standards Track ADVA Optical
D. Papadimitriou
Alcatel
A. Farrel
Old Dog Consulting
May 2007
GMPLS Segment Recovery
GMPLS段恢复
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 for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration. These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872). Implications and interactions with fast reroute are also addressed. This document also updates the handling of NOTIFY_REQUEST objects.
本文档描述了GMPLS（通用多协议标签交换）RSVP-TE（资源预留协议-流量工程）信令扩展的协议特定程序，以支持标签交换路径（LSP）段保护和恢复。这些扩展旨在补充并与端到端GMPLS恢复的RSVP-TE扩展（RFC 4872）保持一致。还讨论了快速重路由的含义和交互作用。本文档还更新了NOTIFY_请求对象的处理。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Segment Recovery ................................................4
2.1. Segment Protection .........................................6
2.2. Segment Re-routing and Restoration .........................6
3. ASSOCIATION Object ..............................................6
3.1. Format .....................................................7
3.2. Procedures .................................................7
3.2.1. Recovery Type Processing ............................7
3.2.2. Resource Sharing Association Type Processing ........7
4. Explicit Control of LSP Segment Recovery ........................8
4.1. Secondary Explicit Route Object Format .....................8
4.1.1. Protection Subobject ................................8
4.2. Explicit Control Procedures ................................9
4.2.1. Branch Failure Handling ............................10
4.2.2. Resv Message Processing ............................11
4.2.3. Admin Status Change ................................12
4.2.4. Recovery LSP Teardown ..............................12
4.3. Teardown From Non-Ingress Nodes ...........................12
4.3.1. Modified NOTIFY_REQUEST Object Processing ..........13
4.3.2. Modified Notify and Error Message Processing .......14
5. Secondary Record Route Objects .................................14
5.1. Format ....................................................14
5.2. Path Processing ...........................................15
5.3. Resv Processing ...........................................15
6. Dynamic Control of LSP Segment Recovery ........................16
6.1. Modified PROTECTION Object Format .........................16
6.2. Dynamic Control Procedures ................................17
7. Updated RSVP Message Formats ...................................18
8. Security Considerations ........................................20
9. IANA Considerations ............................................21
9.1. New Association Type Assignment ...........................21
9.2. Definition of PROTECTION Object Reserved Bits .............21
9.3. Secondary Explicit Route Object ...........................21
9.4. Secondary Record Route Object .............................21
9.5. New Error Code ............................................22
9.6. Use of PROTECTION Object C-type ...........................22
10. References ....................................................23
10.1. Normative References .....................................23
10.2. Informative References ...................................23
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Segment Recovery ................................................4
2.1. Segment Protection .........................................6
2.2. Segment Re-routing and Restoration .........................6
3. ASSOCIATION Object ..............................................6
3.1. Format .....................................................7
3.2. Procedures .................................................7
3.2.1. Recovery Type Processing ............................7
3.2.2. Resource Sharing Association Type Processing ........7
4. Explicit Control of LSP Segment Recovery ........................8
4.1. Secondary Explicit Route Object Format .....................8
4.1.1. Protection Subobject ................................8
4.2. Explicit Control Procedures ................................9
4.2.1. Branch Failure Handling ............................10
4.2.2. Resv Message Processing ............................11
4.2.3. Admin Status Change ................................12
4.2.4. Recovery LSP Teardown ..............................12
4.3. Teardown From Non-Ingress Nodes ...........................12
4.3.1. Modified NOTIFY_REQUEST Object Processing ..........13
4.3.2. Modified Notify and Error Message Processing .......14
5. Secondary Record Route Objects .................................14
5.1. Format ....................................................14
5.2. Path Processing ...........................................15
5.3. Resv Processing ...........................................15
6. Dynamic Control of LSP Segment Recovery ........................16
6.1. Modified PROTECTION Object Format .........................16
6.2. Dynamic Control Procedures ................................17
7. Updated RSVP Message Formats ...................................18
8. Security Considerations ........................................20
9. IANA Considerations ............................................21
9.1. New Association Type Assignment ...........................21
9.2. Definition of PROTECTION Object Reserved Bits .............21
9.3. Secondary Explicit Route Object ...........................21
9.4. Secondary Record Route Object .............................21
9.5. New Error Code ............................................22
9.6. Use of PROTECTION Object C-type ...........................22
10. References ....................................................23
10.1. Normative References .....................................23
10.2. Informative References ...................................23
[RFC4427] covers multiple types of protection, including end-to-end and segment-based approaches. "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery" [RFC4872] defines a set of extensions to support multiple types of recovery. The supported types include 1+1 unidirectional/ 1+1 bidirectional protection, LSP protection with extra-traffic (including 1:N protection with extra-traffic), pre-planned LSP re-routing without extra-traffic (including shared mesh), and full LSP re-routing. In all cases, the recovery is provided on an end-to-end basis, i.e., the ingress and egress nodes of both the protected and the protecting LSP are the same.
[RFC4427]涵盖多种类型的保护，包括端到端和基于段的方法。“支持端到端通用多协议标签交换（GMPLS）恢复的RSVP-TE扩展”[RFC4872]定义了一组支持多种恢复类型的扩展。支持的类型包括1+1单向/1+1双向保护、具有额外流量的LSP保护（包括具有额外流量的1:N保护）、没有额外流量的预先计划的LSP重路由（包括共享网格）和完全LSP重路由。在所有情况下，恢复都是在端到端的基础上提供的，即，受保护和受保护LSP的入口和出口节点都是相同的。
[RFC4090] provides a form of segment recovery for packet MPLS-TE networks. Two methods of fast reroute are defined in [RFC4090]. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point that is shared by multiple LSPs and uses label stacking. Neither approach supports the full set of recovery types supported by [RFC4872]. Additionally, the facility backup method is not applicable to most non-PSC (packet switch capable) switching technologies.
[RFC4090]为数据包MPLS-TE网络提供了一种段恢复形式。[RFC4090]中定义了两种快速重路由方法。一对一备份方法在每个可能的本地修复点为每个受保护的LSP创建迂回LSP。设施备份方法创建一个旁路通道，以保护多个LSP共享的潜在故障点，并使用标签堆叠。这两种方法都不支持[RFC4872]支持的全套恢复类型。此外，设施备份方法不适用于大多数非PSC（支持分组交换）交换技术。
The extensions defined in this document allow for support of the full set of recovery types supported by [RFC4872], but on a segment, or portion of the LSP, basis. The extensions allow (a) the signaling of desired LSP segment protection type, (b) upstream nodes to optionally identify where segment protection starts and stops, (c) the optional identification of hops used on protection segments, and (d) the reporting of paths used to protect an LSP. The extensions also widen the topological scope over which protection can be supported. They allow recovery segments that protect against an arbitrary number of nodes and links. They enable overlapping protection and nested protection. These extensions are intended to be compatible with fast reroute, and in some cases used with fast reroute.
本文档中定义的扩展允许支持[RFC4872]支持的全套恢复类型，但以LSP的一部分为基础。扩展允许（a）所需LSP段保护类型的信令，（b）上游节点可选地标识段保护开始和停止的位置，（c）可选地标识保护段上使用的跳，以及（d）报告用于保护LSP的路径。扩展还扩大了可支持保护的拓扑范围。它们允许对任意数量的节点和链接进行保护的恢复段。它们支持重叠保护和嵌套保护。这些扩展旨在与快速重路由兼容，并且在某些情况下与快速重路由一起使用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In addition, the reader is assumed to be familiar with the terminology used in [RFC3209], [RFC3471], and [RFC3473], as well as [RFC4427], [RFC4426], [RFC4872], and [RFC4090].
此外，假定读者熟悉[RFC3209]、[RFC3471]和[RFC3473]以及[RFC4427]、[RFC4426]、[RFC4872]和[RFC4090]中使用的术语。
Segment recovery is used to provide protection and restoration over a portion of an end-to-end LSP. Such segment protection and restoration is useful to protect against a span failure, a node failure, or failure over a particular portion of a network used by an LSP.
段恢复用于对端到端LSP的一部分提供保护和恢复。这种段保护和恢复对于防止跨距故障、节点故障或LSP使用的网络的特定部分上的故障是有用的。
Consider the following topology:
考虑下面的拓扑结构：
A---B---C---D---E---F
\ /
G---I
A---B---C---D---E---F
\ /
G---I
In this topology, end-to-end protection and recovery is not possible for an LSP going between node A and node F, but it is possible to protect/recover a portion of the LSP. Specifically, if the LSP uses a working path of [A,B,C,D,E,F], then a protection or restoration LSP can be established along the path [C,G,I,E]. This LSP protects against failures on spans {C,D} and {D,E}, as well as a failure of node D. This form of protection/restoration is referred to as Segment Protection and Segment Restoration, or as Segment Recovery, collectively. The LSP providing the protection or restoration is referred to as a segment protection LSP or a segment restoration LSP. The term "segment recovery LSP" is used to cover either a segment protection LSP or a segment restoration LSP. The term "branch node" is used to refer to a node that initiates a recovery LSP, e.g., node C in the figure shown above. This is equivalent to the point of local repair (PLR) used in [RFC4090]. As with [RFC4090], the term "merge node" is used to refer to a node that terminates a recovery LSP, e.g., node E in the figure shown above.
在此拓扑中，对于在节点A和节点F之间的LSP，不可能进行端到端保护和恢复，但是可以保护/恢复LSP的一部分。具体地，如果LSP使用工作路径[a、B、C、D、E、F]，则可以沿着路径[C、G、I、E]建立保护或恢复LSP。此LSP可防止跨距{C，D}和{D，E}上的故障以及节点D的故障。这种形式的保护/恢复统称为段保护和段恢复，或段恢复。提供保护或恢复的LSP称为段保护LSP或段恢复LSP。术语“段恢复LSP”用于涵盖段保护LSP或段恢复LSP。术语“分支节点”用于指发起恢复LSP的节点，例如上图中的节点C。这相当于[RFC4090]中使用的局部维修点（PLR）。与[RFC4090]一样，术语“合并节点”用于指终止恢复LSP的节点，例如上图中的节点e。
Segment protection or restoration is signaled using a working LSP and one or more segment recovery LSPs. Each segment recovery LSP is signaled as an independent LSP. Specifically, the Sender_Template object uses the IP address of the node originating the recovery path, e.g., node C in the topology shown above, and the Session object contains the IP address of the node terminating the recovery path, e.g., node E shown above. There is no specific requirement on LSP ID value, Tunnel ID, and Extended Tunnel ID. Values for these fields are selected normally, including consideration for the make-before-break concept (as described in [RFC3209]). Intermediate nodes follow standard signaling procedures when processing segment recovery LSPs. A segment recovery LSP may be protected itself using segment or end-to-end protection/restoration. Note, in PSC environments, it may be desirable to construct the Sender_Template and Session objects per [RFC4090].
段保护或恢复使用工作LSP和一个或多个段恢复LSP发出信号。每个段恢复LSP作为独立的LSP发送信号。具体地说，发送方\模板对象使用发起恢复路径的节点的IP地址，例如上面所示的拓扑中的节点C，会话对象包含终止恢复路径的节点的IP地址，例如上面所示的节点e。对LSP ID值、隧道ID和扩展隧道ID没有具体要求。通常选择这些字段的值，包括考虑先通后断概念（如[RFC3209]中所述）。中间节点在处理段恢复LSP时遵循标准信令过程。可以使用段或端到端保护/恢复来保护段恢复LSP本身。注意，在PSC环境中，可能需要按照[RFC4090]构造发送方_模板和会话对象。
When [RFC4090] isn't being used, the association between segment recovery LSPs with other LSPs is indicated using the ASSOCIATION object defined in [RFC4872]. The ASSOCIATION object is used to associate recovery LSPs with the LSP they are protecting. Working and protecting LSPs, as well as primary and secondary LSPs, are identified using LSP Status as described in [RFC4872]. The O-bit in the segment flags portion of the PROTECTION object is used to identify when a recovery LSP is carrying the normal (active) traffic.
不使用[RFC4090]时，使用[RFC4872]中定义的关联对象指示段恢复LSP与其他LSP之间的关联。关联对象用于将恢复LSP与其保护的LSP关联。使用[RFC4872]中所述的LSP状态识别工作和保护LSP以及主LSP和辅助LSP。保护对象的段标志部分中的O位用于识别恢复LSP何时承载正常（活动）通信量。
An upstream node can permit downstream nodes to dynamically identify branch and merge points by setting the desired LSP segment protection bits in the PROTECTION object. These bits are defined below.
上游节点可以允许下游节点通过在保护对象中设置所需的LSP段保护位来动态识别分支和合并点。这些位定义如下。
Optionally, an upstream node, usually the ingress node, can identify the endpoints of a segment recovery LSP. This is accomplished using a new object. This object uses the same format as an Explicit Route Object (ERO) and is referred to as a Secondary Explicit Route object (SERO); see Section 4.1. SEROs also support a new subobject to indicate the type of protection or restoration to be provided. At a minimum, an SERO will indicate a recovery LSP's initiator, protection/restoration type and terminator. Standard ERO semantics (see [RFC3209]) can optionally be used within and SERO to explicitly control the recovery LSP. A Secondary Record Route object (SRRO) is defined for recording the path of a segment recovery LSP; see Section 5.
可选地，上游节点（通常为入口节点）可以识别段恢复LSP的端点。这是使用新对象完成的。该对象使用与显式路由对象（ERO）相同的格式，称为次显式路由对象（SERO）；见第4.1节。SEROs还支持一个新的子对象，以指示要提供的保护或恢复类型。至少，SERO将指示恢复LSP的发起方、保护/恢复类型和终止方。标准ERO语义（请参见[RFC3209]）可以选择性地在和SERO中使用，以显式控制恢复LSP。定义二次记录路由对象（SRRO），用于记录段恢复LSP的路径；见第5节。
SEROs are carried between the node creating the SERO, typically the ingress, and the node initiating a recovery LSP. The node initiating a recovery LSP uses the SERO to create the ERO for the recovery LSP. At this (branch) node, all local objects are removed, and the new protection subobject is used to create the PROTECTION object for the recovery LSP. It is also possible to control the handling of a failure to establish a recovery LSP.
血清在创建血清（通常为入口）的节点和启动恢复LSP的节点之间携带。发起恢复LSP的节点使用SERO为恢复LSP创建ERO。在此（分支）节点上，将删除所有本地对象，并使用新的保护子对象为恢复LSP创建保护对象。还可以控制建立恢复LSP的故障处理。
SRROs are carried in Path messages between the node terminating a recovery LSP, the merge node, and the egress. SRROs are used in Resv messages between a branch node and the ingress. The merge node of a recovery LSP creates an SRRO by copying the RRO from the Path message of the associated recovery LSP into a new SRRO object. Any SRROs present in the recovery LSP's Path message are also copied. The branch node of a recovery LSP creates an SRRO by copying the RRO from the Resv message of associated recovery LSP into a new SRRO object. Any SRROs present in the recovery LSP's Resv message are also copied.
SRRO在终止恢复LSP的节点、合并节点和出口之间的路径消息中携带。SRRO用于分支节点和入口之间的Resv消息中。恢复LSP的合并节点通过将RRO从关联恢复LSP的路径消息复制到新的SRRO对象中来创建SRRO。恢复LSP路径消息中存在的任何SRRO也会被复制。恢复LSP的分支节点通过将相关恢复LSP的Resv消息中的RRO复制到新的SRRO对象中来创建SRRO。恢复LSP的Resv消息中存在的任何SRRO也会被复制。
Notify request processing is also impacted by LSP segment recovery. Per [RFC3473], only one NOTIFY_REQUEST object is meaningful and should be propagated. Additional NOTIFY_REQUEST objects are used to identify recovery LSP branch nodes.
通知请求处理还受到LSP段恢复的影响。根据[RFC3473]，只有一个NOTIFY_请求对象有意义，应该传播。其他NOTIFY_请求对象用于标识恢复LSP分支节点。
Three approaches for end-to-end protection are defined in [RFC4872]: 1+1 Unidirectional Protection (Section 5), 1+1 Bidirectional Protection (Section 6), and 1:1 Protection With Extra-Traffic (Section 7). The segment protection forms of these protection approaches all operate much like their end-to-end counterparts. Each behaves just like its end-to-end counterpart, with the exception that the protection LSP protects only a portion of the working LSP. The type of protection to be used on a segment protection LSP is indicated, to the protection LSP's ingress, using the protection SERO subobject defined in Section 4.1.
[RFC4872]中定义了三种端到端保护方法：1+1单向保护（第5节）、1+1双向保护（第6节）和1:1额外流量保护（第7节）。这些保护方法的段保护形式都与端到端的保护方式非常相似。除保护LSP仅保护工作LSP的一部分外，每个LSP的行为与其端到端对应物一样。使用第4.1节中定义的保护血清子对象，向保护LSP入口指示分段保护LSP上使用的保护类型。
The switch-over processing for segment 1+1 Bidirectional protection and 1:1 Protection With Extra-Traffic follows the same procedures as end-to-end protection forms; see Sections 6.2 and 7.2 of [RFC4872] for details.
段1+1双向保护和1:1额外流量保护的切换处理程序与端到端保护形式相同；详见[RFC4872]第6.2节和第7.2节。
Three re-routing and restoration approaches are defined in [RFC4872]: Re-routing without Extra-Traffic (Section 8), Shared-Mesh Restoration (Section 9), (Full) LSP Re-routing (Section 11). As with protection, these approaches are supported on a segment basis. The segment forms of re-routing and restoration operate exactly like their end-to-end counterparts, with the exception that the restoration LSP recovers only a portion of the working LSP. The type of re-routing or restoration to be used on a segment restoration LSP is indicated, to the restoration LSP's ingress, using the new protection SERO subobject.
[RFC4872]中定义了三种重路由和恢复方法：无额外流量重路由（第8节）、共享网格恢复（第9节），（完整）LSP重路由（第11节）。与保护一样，这些方法在分部基础上得到支持。除了恢复LSP仅恢复工作LSP的一部分之外，重路由和恢复的段形式与它们的端到端对应部分完全相同。要在段恢复LSP上使用的重路由或恢复类型将使用新的protection SERO子对象指示给恢复LSP的入口。
The ASSOCIATION object is used for the association of segment protection LSPs when [RFC4090] isn't being used. The ASSOCIATION object is defined in [RFC4872]. In this document, we define a new Association Type field value to support make-before-break; the formats and procedures defined in [RFC4872] are not otherwise modified.
当[RFC4090]未被使用时，关联对象用于段保护LSP的关联。关联对象在[RFC4872]中定义。在本文中，我们定义了一个新的关联类型字段值，以支持先生成后终止；[RFC4872]中定义的格式和程序不作其他修改。
Association Type: 16 bits
关联类型：16位
Value Type
----- ----
2 Resource Sharing (R)
Value Type
----- ----
2 Resource Sharing (R)
See [RFC4872] for the definition of other fields and values.
有关其他字段和值的定义，请参见[RFC4872]。
The ASSOCIATION object is used to associate different LSPs with each other. In the protection and restoration context, the object is used to associate a recovery LSP with the LSP it is protecting. The ASSOCIATION object is also used to support resource sharing during make-before-break. This object MUST NOT be used when association is made according to the methods defined in [RFC4090].
关联对象用于将不同的LSP相互关联。在保护和恢复上下文中，对象用于将恢复LSP与其保护的LSP关联。关联对象还用于支持先通后断期间的资源共享。当根据[RFC4090]中定义的方法进行关联时，不得使用此对象。
Recovery type processing procedures are the same as those defined in [RFC4872], but processing and identification occur with respect to segment recovery LSPs. Note that this means that multiple ASSOCIATION objects of type recovery may be present on an LSP.
恢复类型处理程序与[RFC4872]中定义的程序相同，但处理和识别与段恢复LSP有关。请注意，这意味着LSP上可能存在多个恢复类型的关联对象。
The ASSOCIATION object with an Association Type with the value Resource Sharing is used to enable resource sharing during make-before-break. Resource sharing during make-before-break is defined in [RFC3209]. The defined support only works with LSPs that share the same LSP egress. With the introduction of segment recovery LSPs, it is now possible for an LSP endpoint to change during make-before-break.
具有“资源共享”值的关联类型的关联对象用于在“先通后断”期间启用资源共享。[RFC3209]中定义了先通后断期间的资源共享。定义的支持仅适用于共享相同LSP出口的LSP。随着段恢复LSP的引入，LSP端点现在可以在“先通后断”的过程中更改。
A node includes an ASSOCIATION object with a Resource Sharing Association Type in an outgoing Path message when it wishes to indicate resource sharing across an associated set of LSPs. The Association Source is set to the originating node's router address. The Association ID MUST be set to a value that uniquely identifies the association of LSPs. This MAY be set to the working LSP's LSP ID. Once included, an ASSOCIATION object with a Resource Sharing Association Type SHOULD NOT be removed from the Path messages associated with an LSP.
当节点希望指示跨相关联的LSP集的资源共享时，它在传出路径消息中包括具有资源共享关联类型的关联对象。关联源设置为发起节点的路由器地址。关联ID必须设置为唯一标识LSP关联的值。这可以设置为工作LSP的LSP ID。一旦包含，具有资源共享关联类型的关联对象不应从与LSP关联的路径消息中删除。
Any node processing a Path message for which the node does not have a matching state, and which contains an ASSOCIATION object with a Resource Sharing type, examines existing LSPs for matching Association Type, Association Source, and Association ID values. If any match is found, then [RFC3209] style resource sharing SHOULD be provided between the new and old LSPs. See [RFC3209] for additional details.
任何处理路径消息的节点，如果该节点没有匹配状态，并且包含具有资源共享类型的关联对象，则会检查现有LSP以查找匹配的关联类型、关联源和关联ID值。如果找到任何匹配项，则应在新LSP和旧LSP之间提供[RFC3209]样式的资源共享。有关更多详细信息，请参见[RFC3209]。
Secondary Explicit Route objects, or SEROs, are defined in this document. They may be used to indicate the branch and merge nodes of recovery LSPs. They may also provide additional information that is to be carried in a recovery LSP's ERO. When upstream control of branch and merge nodes is not desired, SEROs are not used.
次级显式路由对象或SEROs在本文档中定义。它们可用于指示恢复LSP的分支和合并节点。它们还可以提供恢复LSP的ERO中要携带的附加信息。当不需要分支和合并节点的上游控制时，不使用SEROs。
The format of a SECONDARY_EXPLICIT_ROUTE object is the same as an EXPLICIT_ROUTE object. This includes the definition of subobjects defined for EXPLICIT_ROUTE object. The class of the SECONDARY_EXPLICIT_ROUTE object is 200 (of the form 11bbbbbb).
次显式路由对象的格式与显式路由对象的格式相同。这包括为显式布线对象定义的子对象的定义。次要_显式_路由对象的类为200（形式为11bbbb）。
A new subobject, called the protection subobject, is defined for use in the SECONDARY_EXPLICIT_ROUTE object. As mentioned above, the new protection subobject is used to create the PROTECTION object for the recovery LSP. Specific procedures related to the protection subobject are provided in Section 4.2. The protection subobject is not valid for use with the Explicit and Record Route objects and MUST NOT be included in those objects.
定义了一个称为“保护”子对象的新子对象，以便在次路由对象中使用。如上所述，新的保护子对象用于为恢复LSP创建保护对象。第4.2节提供了与保护子对象相关的具体程序。保护子对象对于显式路由对象和记录路由对象无效，并且不能包含在这些对象中。
The format of the protection subobject is defined as follows:
保护子对象的格式定义如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROTECTION Object Contents |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROTECTION Object Contents |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L-bit
L位
This is defined in [RFC3209] and MUST be set to zero for protection subobjects.
这在[RFC3209]中定义，并且必须为保护子对象设置为零。
Type
类型
37 Protection
37保护
Length
长
As defined in [RFC3209], Section 4.3.3.
如[RFC3209]第4.3.3节所定义。
Reserved
含蓄的
This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt.
此字段是保留的。传输时必须将其设置为零，接收时必须忽略。
C-Type
C型
The C-Type of the included PROTECTION object.
包含的保护对象的C类型。
PROTECTION Object Contents
保护对象内容
The contents of the PROTECTION object, with the format matching the indicated C-Type, excluding the object header.
匹配对象类型，不包括所指示的对象保护的内容。
SEROs are carried in Path messages and indicate at which node a recovery LSP is to be initiated relative to the LSP carrying the SERO. More than one SERO MAY be present in a Path message.
在路径消息中携带血清，并指示相对于携带血清的LSP将在哪个节点启动恢复LSP。Path消息中可能存在多个SERO。
To indicate the branch and merge nodes of a recovery LSP, an SERO is created and added to the Path message of the LSP being recovered. The decision to create and insert an SERO is a local matter and outside the scope of this document.
要指示恢复LSP的分支和合并节点，将创建一个SERO并将其添加到正在恢复的LSP的路径消息中。创建和插入SERO的决定属于本地事务，不在本文件范围内。
An SERO SHOULD contain at least three subobjects. The first subobject MUST indicate the node that is to originate the recovery LSP, i.e. the segment branch node. The address used SHOULD also be listed in the ERO or another SERO. This ensures that the branch node is along the LSP path. The second subobject SHOULD be a protection subobject and should indicate the protection or restoration to be provided by the recovery LSP. When the protection subobject is present, the LSP Segment Recovery Flags in the protection subobject MUST be ignored. The final subobject in the SERO MUST be the merge node of the recovery LSP, and MAY have the L-bit set. Standard ERO subobjects MAY be inserted between the protection subobject and the final subobject. These subobjects MAY be loose or strict.
血清应至少包含三个子对象。第一个子对象必须指示要发起恢复LSP的节点，即段分支节点。也应在SERO中使用另一个地址。这确保分支节点沿着LSP路径。第二个子对象应为保护子对象，并应指示恢复LSP将提供的保护或恢复。当保护子对象存在时，必须忽略保护子对象中的LSP段恢复标志。SERO中的最后一个子对象必须是恢复LSP的合并节点，并且可以设置L位。标准ERO子对象可以插入到保护子对象和最终子对象之间。这些子对象可能是松散的，也可能是严格的。
A node receiving a Path message containing one or more SEROs SHOULD examine each SERO to see if it indicates a local branch point. This
接收包含一个或多个SERO的路径消息的节点应检查每个SERO，以查看它是否指示本地分支点。这
determination is made by examining the first object of each SERO and seeing if the address indicated in the subobject can be associated with the local node. If any of indicated addresses are associated with the local node, then the local node is a branch node. If the local node is not a branch node, all received SEROs MUST be transmitted, without modification, in the corresponding outgoing Path message.
通过检查每个SERO的第一个对象并查看子对象中指示的地址是否可以与本地节点关联来进行确定。如果指示的任何地址与本地节点关联，则本地节点是分支节点。如果本地节点不是分支节点，则必须在相应的传出路径消息中传输所有接收到的sero，无需修改。
At a branch node, the SERO, together with the Path message of LSP being recovered, provides the information to create the recovery LSP. The Path message for the recovery LSP is created at the branch node by cloning the objects carried in the incoming Path message of the LSP being protected. Certain objects are replaced or modified in the recovery LSP's outgoing Path message. The Sender_template object MUST be updated to use an address (in its Tunnel Sender Address field) on the local node, and the LSP ID MUST be updated to ensure uniqueness. The Session object MUST be updated to use the address indicated in the final subobject of the SERO as the tunnel endpoint address, the tunnel ID MAY be updated, and the extended tunnel ID MUST be set to the local node address. The PROTECTION object is replaced with the contents of the matching SERO protection subobject, when present. In all cases, the R-bit of a new PROTECTION object is reset (0). Any RROs and EROs present in the incoming Path message MUST NOT be included in the recovery LSP. A new ERO MUST be included, with the contents of the SERO that indicated a local branch. As with all EROs, no local information (local address and any protection subobjects) is carried in the ERO carried in the recovery LSP's outgoing Path message. The SERO that indicated a local branch MUST be omitted from the recovery LSP's outgoing Path message. Note, by default, all other received SEROs are passed in the recovery LSP's outgoing Path message. SEROs MAY be omitted, from the recovery LSP's outgoing Path message as well as the outgoing Path message for the LSP being protected, when the SERO does not relate to the outgoing path message.
在分支节点上，SERO与正在恢复的LSP的路径消息一起提供创建恢复LSP的信息。恢复LSP的路径消息是通过克隆受保护LSP的传入路径消息中携带的对象在分支节点上创建的。某些对象在恢复LSP的传出路径消息中被替换或修改。必须更新Sender_template对象以使用本地节点上的地址（在其隧道Sender address字段中），并且必须更新LSP ID以确保唯一性。必须更新会话对象，以使用SERO的最终子对象中指示的地址作为隧道端点地址，可以更新隧道ID，并且必须将扩展隧道ID设置为本地节点地址。保护对象将替换为匹配的血清保护子对象（如果存在）的内容。在所有情况下，新保护对象的R位均被重置（0）。传入路径消息中存在的任何RRO和ERO不得包含在恢复LSP中。必须包括一个新的ERO，其内容包括表明当地分支机构的血清。与所有ERO一样，恢复LSP的传出路径消息中携带的ERO中不携带任何本地信息（本地地址和任何保护子对象）。必须从恢复LSP的传出路径消息中忽略指示本地分支的SERO。注意，默认情况下，在恢复LSP的传出路径消息中传递所有其他接收到的SERO。当SERO与传出路径消息不相关时，可以从恢复LSP的传出路径消息以及被保护LSP的传出路径消息中省略SEROs。
The resulting Path message is used to create the recovery LSP. From this point on, Standard Path message processing is used in processing the resulting Path message.
生成的路径消息用于创建恢复LSP。从这一点开始，标准路径消息处理将用于处理生成的路径消息。
During setup, it is possible that a processing node will be unable to support a requested branch. Additionally, during setup and normal operation, PathErr messages may be received at a branch node. The processing of these events depend on a number of factors.
在安装过程中，处理节点可能无法支持请求的分支。此外，在设置和正常操作期间，可能会在分支节点接收PathErr消息。这些事件的处理取决于许多因素。
When a failure or received PathErr message is associated with the LSP being protected, the event is first processed per standard processing
当故障或收到的PathErr消息与受保护的LSP关联时，首先按照标准处理程序处理该事件
rules. This includes generation of a standard PathErr message. When LSP state is removed due to a local failure or a PathErr message with the Path_State_Removed flag set (1), the node MUST send a PathTear message downstream on all other branches.
规则。这包括生成标准PathErr消息。当由于本地故障或设置了Path_state_removed标志（1）的PathErr消息而删除LSP状态时，节点必须在所有其他分支上向下游发送Path催泪消息。
When a failure or received PathErr message is associated with a recovery LSP, processing is based on the R-bit in addition to the Path_State_Removed flag. In all cases, a received PathErr message is first processed per standard processing rules and the failure or received PathErr message SHOULD trigger the generation of a PathErr message upstream for the LSP being protected. The outgoing PathErr message SHOULD indicate an error of "Routing Problem/LSP Segment Protection Failed". The outgoing PathErr message MUST include any SEROs carried in a received PathErr message. If no SERO is present in a received PathErr message or when the failure is local, then an SERO that matches the errored LSP or failed branch MUST be added to the outgoing PathErr message.
当故障或接收到的PathErr消息与恢复LSP关联时，除Path_State_Removed标志外，还将基于R位进行处理。在所有情况下，首先按照标准处理规则处理收到的PathErr消息，故障或收到的PathErr消息应触发为受保护的LSP生成上游PathErr消息。传出的PathErr消息应指示“路由问题/LSP段保护失败”错误。传出的PathErr消息必须包括接收到的PathErr消息中携带的任何SEROs。如果收到的PathErr消息中不存在SERO，或者当故障为本地故障时，则必须将与出错LSP或故障分支匹配的SERO添加到传出PathErr消息中。
When a PathErr message with the Path_State_Removed flag cleared (0) is received, the outgoing (upstream) PathErr message SHOULD be sent with the Path_State_Removed flag cleared (0).
当接收到清除了Path_State_Removed标志（0）的PathErr消息时，应发送清除了Path_State_Removed标志（0）的传出（上游）PathErr消息。
When a PathErr message for a recovery LSP with the Path_State_Removed flag set (1) is received, the processing node MUST examine the R-bit (as defined below) of the LSP being protected. The R-bit is carried in the PROTECTION object that triggered the initiation of the recovery LSP. When the R-bit is not set (0), the outgoing (upstream) PathErr message SHOULD be sent with the Path_State_Removed flag cleared (0). When the R-bit is set (1), the outgoing (upstream) PathErr message MUST be sent with the Path_State_Removed flag set (1).
当接收到恢复LSP的PathErr消息且设置了Path_State_Removed标志（1）时，处理节点必须检查受保护LSP的R位（定义如下）。R位携带在触发恢复LSP启动的保护对象中。未设置R位（0）时，发送传出（上游）PathErr消息时应清除Path_State_Removed标志（0）。当R位设置为（1）时，发送传出（上游）PathErr消息时必须设置Path_State_Removed标志（1）。
In all cases where an outgoing (upstream) PathErr message is sent with the Path_State_Removed flag set (1), all path state for the LSP being protected MUST be removed, and the node MUST send a PathTear message downstream on all active branches.
在发送传出（上游）PathErr消息时，如果设置了Path_State_Removed标志（1），则必须删除受保护LSP的所有路径状态，并且节点必须在所有活动分支上向下游发送Path催泪消息。
Branch nodes will process Resv messages for both recovery LSPs and LSPs being protected. Resv messages are propagated upstream of branch nodes only after a Resv message is received for the protected LSP. Resv messages on recovery LSPs will typically not trigger transmission of upstream Resv messages (for the LSP being protected). Exceptions to this include when RROs/SRROs are being collected and during certain ADMIN_STATUS object processing. See below for more information on related processing.
分支节点将处理恢复LSP和受保护LSP的Resv消息。只有在收到受保护LSP的Resv消息后，才会将Resv消息传播到分支节点的上游。恢复LSP上的Resv消息通常不会触发上游Resv消息的传输（对于受保护的LSP）。例外情况包括在收集RRO/SRRO时以及在某些管理状态对象处理期间。有关相关处理的更多信息，请参见下文。
In general, objects in a recovery LSP are created based on the corresponding objects in the LSP being protected. The ADMIN_STATUS object is created the same way, but it also requires some special coordination at branch nodes. Specifically, in addition to normal processing, a branch node that receives an ADMIN_STATUS object in a Path message also MUST relay the ADMIN_STATUS object in a Path on every recovery LSP. All Path messages MAY be concurrently sent downstream.
通常，恢复LSP中的对象是基于受保护的LSP中的相应对象创建的。ADMIN_STATUS对象的创建方式相同，但它还需要在分支节点上进行一些特殊的协调。具体地说，除了正常处理之外，在路径消息中接收ADMIN_状态对象的分支节点还必须在每个恢复LSP的路径中中继ADMIN_状态对象。所有路径消息可以并发地发送到下游。
Downstream nodes process the change in the ADMIN_STATUS object per [RFC3473], including generation of Resv messages. When the most recently received upstream ADMIN_STATUS object has the R bit set, branch nodes wait for a Resv message with a matching ADMIN_STATUS object to be received on all branches before relaying a corresponding Resv message upstream.
下游节点根据[RFC3473]处理管理状态对象中的更改，包括生成Resv消息。当最近接收到的上游ADMIN_STATUS对象设置了R位时，分支节点等待在所有分支上接收到具有匹配ADMIN_STATUS对象的Resv消息，然后再向上游中继相应的Resv消息。
Recovery LSP removal follows standard procedures defined in [RFC3209] and [RFC3473]. This includes with and without setting the administrative status.
回收LSP的去除遵循[RFC3209]和[RFC3473]中定义的标准程序。这包括设置管理状态和不设置管理状态。
The node initiating the teardown originates a PathTear message. Each node that receives a PathTear message processes the PathTear message per standard processing (see [RFC3209] and [RFC2205]), and MUST also relay a PathTear on every recovery LSP. All PathTear messages (received from upstream and locally originated) may be concurrently sent downstream.
发起拆卸的节点会生成一条PathTear消息。每个接收PathTear消息的节点按照标准处理方式处理PathTear消息（请参见[RFC3209]和[RFC2205]），并且还必须在每个恢复LSP上中继PathTear。所有PathTear消息（从上游接收和本地发起）都可以并发地发送到下游。
Per [RFC3473], the ingress node originates a Path message with the D and R bits set in the ADMIN_STATUS object. The admin status change procedure defined in Section 4.2.3 MUST then be followed. Once the ingress receives all expected Resv messages, it MUST follow the teardown procedure described in Section 4.2.4.1.
根据[RFC3473]，入口节点使用ADMIN_STATUS对象中设置的D和R位生成路径消息。然后必须遵循第4.2.3节中定义的管理员状态更改程序。一旦入口接收到所有预期的Resv消息，它必须遵循第4.2.4.1节中描述的拆卸程序。
As with any LSP, any node along a recovery LSP may initiate removal of the recovery LSP. To do this, the node initiating the teardown sends a PathErr message with the appropriate Error Code and the Path_State_Removed flag cleared (0) toward the LSP ingress. As described above, the recovery LSP ingress will propagate the error to
与任何LSP一样，恢复LSP上的任何节点都可以启动恢复LSP的移除。为此，发起拆卸的节点向LSP入口发送一条PathErr消息，其中包含适当的错误代码和清除的Path_State_Removed标志（0）。如上所述，恢复LSP入口将把错误传播到
the LSP ingress, which can then signal the removal of the recovery LSP.
LSP进入，然后可以发出删除恢复LSP的信号。
It is also possible for the node initiating the teardown to remove a Recovery LSP in a non-graceful manner. In this case, the initiator sends a PathTear message downstream and a PathErr message with a "Confirmation" indication (error code and value set to zero), and the Path_State_Removed flag set (1) toward the LSP ingress node. This manner of non-ingress node teardown is NOT RECOMMENDED because in some cases it can result in the removal of the LSP being protected.
发起拆卸的节点也可以以非优雅的方式移除恢复LSP。在这种情况下，发起者向LSP入口节点向下游发送Path催泪消息和带有“确认”指示（错误代码和值设置为零）的PathErr消息，以及路径状态移除标志集（1）。不建议采用这种非入口节点拆卸方式，因为在某些情况下，这种方式可能会导致删除受保护的LSP。
A parallel set of rules are applied at branch and merge nodes to enable the branch or merge node to add a NOTIFY_REQUEST object to the Path and Resv messages of protected and recovery LSPs. Branch nodes add NOTIFY_REQUEST objects to Path messages, and merge nodes add NOTIFY_REQUEST objects to Resv messages.
在分支和合并节点上应用一组并行规则，以使分支或合并节点能够向受保护和恢复LSP的路径和Resv消息添加NOTIFY_请求对象。分支节点将NOTIFY_请求对象添加到路径消息，合并节点将NOTIFY_请求对象添加到Resv消息。
When a node is branching or merging a recovery LSP, the node SHOULD include a single NOTIFY_REQUEST object in the Path message of the recovery LSP, in the case of a branch node, or the Resv message of the recovery LSP, in the case of a merge node. The notify node address MUST be set to the router address of the processing node.
当节点分支或合并恢复LSP时，对于分支节点，该节点应在恢复LSP的路径消息中包含单个NOTIFY_请求对象；对于合并节点，该节点应在恢复LSP的Resv消息中包含单个NOTIFY_请求对象。通知节点地址必须设置为处理节点的路由器地址。
Branch and merge nodes SHOULD also add a NOTIFY_REQUEST object to the LSP being protected. For branch nodes, the notify node address is set to the address used in the sender template object of the associated recovery LSP. For merge nodes, the notify node address is set to the address used in the session object of the associated recovery LSP. A locally added NOTIFY_REQUEST object MUST be listed first in an outgoing message; any received NOTIFY_REQUEST objects MUST then be listed in the message in the order that they were received. Note that this can result in a stack (or ordered list) of objects.
分支和合并节点还应向受保护的LSP添加NOTIFY_请求对象。对于分支节点，通知节点地址设置为关联恢复LSP的发送方模板对象中使用的地址。对于合并节点，通知节点地址设置为关联恢复LSP的会话对象中使用的地址。本地添加的NOTIFY_请求对象必须首先在传出消息中列出；然后，所有接收到的NOTIFY_请求对象必须按照接收顺序列在消息中。请注意，这可能会导致对象的堆栈（或有序列表）。
Normal notification procedures are then followed for the LSP being protected. That is, the notifying node MUST issue a Notify message to the recipient indicated by the notify address of the first listed NOTIFY_REQUEST object. Under local policy control, a node issuing a Notify message MAY also send a Notify message to the Notify Node Address indicated in the last, or any other, NOTIFY_REQUEST object carried in the Path or Resv message.
然后，受保护的LSP将遵循正常的通知程序。也就是说，通知节点必须向第一个列出的Notify_请求对象的Notify地址所指示的收件人发出Notify消息。在本地策略控制下，发出Notify消息的节点还可以将Notify消息发送到最后一个Notify节点地址，或路径或Resv消息中携带的任何其他Notify_请求对象。
Recovery LSP merge and branch nodes remove the object added by the recovery branch or merge node from outgoing Path and Resv messages for the LSP being protected. This is done by removing the NOTIFY_REQUEST object that, in the case of a merge node, matches the
恢复LSP合并和分支节点从要保护的LSP的传出路径和Resv消息中删除恢复分支或合并节点添加的对象。这是通过删除NOTIFY_请求对象来完成的，对于合并节点，该对象与
source address of the recovery LSP and, in the case of a branch node, matches the tunnel endpoint address of the recovery LSP. The matching NOTIFY_REQUEST object will normally be the first of the listed NOTIFY_REQUEST objects. Note, to cover certain backwards compatibility scenarios, the NOTIFY_REQUEST object SHOULD NOT be removed if it is the sole NOTIFY_REQUEST object.
恢复LSP的源地址，如果是分支节点，则与恢复LSP的隧道端点地址匹配。匹配的NOTIFY_请求对象通常是列出的NOTIFY_请求对象中的第一个。注意，为了涵盖某些向后兼容性场景，如果NOTIFY_请求对象是唯一的NOTIFY_请求对象，则不应删除它。
Note this requires the following change to [RFC3473], Section 4.2.1:
注：这需要对[RFC3473]第4.2.1节进行以下更改：
o old text: If a message contains multiple NOTIFY_REQUEST objects, only the first object is meaningful. Subsequent NOTIFY_REQUEST objects MAY be ignored and SHOULD NOT be propagated.
o 旧文本：如果消息包含多个NOTIFY_请求对象，则只有第一个对象有意义。随后的NOTIFY_请求对象可能会被忽略，不应传播。
o new text: If a message contains multiple NOTIFY_REQUEST objects, only the first object used is in notification. Subsequent NOTIFY_REQUEST objects MUST be propagated in the order received.
o 新文本：如果消息包含多个NOTIFY_请求对象，则只有使用的第一个对象在notification中。后续的NOTIFY_请求对象必须按接收的顺序传播。
Branch and merge nodes MUST support the following modification to Notify message processing. When a branch or merge node receives notification of an LSP failure and it is unable to recover from that failure, it MUST notify the node indicated in the first NOTIFY_REQUEST object received in the Path message (for branch nodes) or Resv message (for merge nodes) associated with the LSP.
分支和合并节点必须支持以下修改以通知消息处理。当分支或合并节点收到LSP故障通知且无法从该故障中恢复时，它必须通知在与LSP关联的Path消息（对于分支节点）或Resv消息（对于合并节点）中接收的第一个notify_请求对象中指示的节点。
Secondary Record Route objects, or SRROs, are used to record the path used by recovery LSPs.
辅助记录路由对象（SRRO）用于记录恢复LSP使用的路径。
The format of a SECONDARY_RECORD_ROUTE object is the same as a RECORD_ROUTE object, Class number 21. This includes the definition of subobjects defined for RECORD_ROUTE object. The class of the SECONDARY_RECORD_ROUTE object is 201 (of the form 11bbbbbb).
辅助记录路由对象的格式与类别号为21的记录路由对象的格式相同。这包括为记录路由对象定义的子对象的定义。次要_记录_路由对象的类为201（形式为11bbbb）。
The protection subobject defined above can also be used in SECONDARY_RECORD_ROUTE objects.
上述定义的保护子对象也可用于辅助记录路由对象。
SRROs may be carried in Path messages and indicate the presence of upstream recovery LSPs. More than one SRRO MAY be added and present in a Path message.
SRRO可在路径消息中携带，并指示存在上游恢复LSP。一条Path消息中可以添加并显示多个SRRO。
Any received SRRO MUST be transmitted by transit nodes, without modification, in the corresponding outgoing Path message.
任何接收到的SRRO必须由传输节点在相应的传出路径消息中传输，无需修改。
SRROs are inserted in Path messages by recovery LSP merge nodes. The SRRO is created by copying the contents of an RRO received by the recovery LSP into a new SRRO object. This SRRO is added to the outgoing Path message of the recovered LSP. Note that multiple SRROs may be present. The collection of SRROs is controlled via the segment-recording-desired flag in the SESSION_ATTRIBUTE object. This flag MAY be set even when SEROs are not used.
SRRO由恢复LSP合并节点插入路径消息中。SRRO是通过将恢复LSP接收到的RRO内容复制到新的SRRO对象中来创建的。此SRRO被添加到已恢复LSP的传出路径消息中。请注意，可能存在多个SRRO。SRRO的收集通过会话_属性对象中记录所需标志的段进行控制。即使未使用血清，也可以设置此标志。
SRROs may be carried in Resv messages and indicate the presence of downstream recovery LSPs. More than one SRRO MAY be added and present in a Resv message.
SRROs可在Resv消息中携带，并指示下游恢复LSP的存在。可以在Resv消息中添加并显示多个SRRO。
Any received SRRO MUST be transmitted by transit nodes, without modification, in the corresponding outgoing Resv message. When Resv messages are merged, the resulting merged Resv SHOULD contain all SRROs received in downstream Resv messages.
任何接收到的SRRO必须由传输节点在相应的传出Resv消息中传输，无需修改。合并Resv消息时，生成的合并Resv应包含下游Resv消息中接收到的所有SRRO。
SRROs are inserted in Resv messages by branch nodes of recovery LSPs. The SRRO SHOULD be created with the first two objects being the local node address, followed by a protection subobject with the contents of the recovery LSP's PROTECTION object. The remainder of the SRRO SHOULD be created by copying the contents of the RRO received by the recovery LSP. This SRRO SHOULD be added to the outgoing Resv message of the recovered LSP. Again, multiple SRROs may be present.
SRRO由恢复LSP的分支节点插入到Resv消息中。创建SRRO时，前两个对象应为本地节点地址，然后是包含恢复LSP保护对象内容的保护子对象。SRRO的其余部分应通过复制恢复LSP接收的RRO内容来创建。应将此SRRO添加到已恢复LSP的传出Resv消息中。同样，可能存在多个SRRO。
If the newly added SRRO causes the message to be too big to fit in a Resv message, SRRO subobjects SHOULD be removed from any present SRROs. When removing subobjects, the first two subobjects and the last subobject in an SRRO MUST NOT be removed. Note that the subobject that followed a removed subobject MUST be updated with the L-bit set (1). If after removing all but the first and last subobjects in all SRROs the resulting message is still too large to fit, then whole SRROs SHOULD be removed until the message does fit.
如果新添加的SRRO导致消息太大，无法放入Resv消息中，则应从任何现有SRRO中删除SRRO子对象。删除子对象时，不得删除SRRO中的前两个子对象和最后一个子对象。请注意，必须使用L位集（1）更新删除的子对象之后的子对象。如果删除所有SRRO中除第一个子对象和最后一个子对象以外的所有子对象后，生成的消息仍然太大，无法容纳，则应删除整个SRRO，直到消息容纳为止。
Dynamic identification of branch and merge nodes is supported via the LSP Segment Recovery Flags carried in the PROTECTION object. The LSP Segment Recovery Flags are carried within one of the Reserved fields defined in the PROTECTION object defined in [RFC4872]. LSP Segment Recovery Flags are used to indicate when LSP segment recovery is desired. When these bits are set, branch and merge nodes are dynamically identified.
支持通过保护对象中携带的LSP段恢复标志动态标识分支和合并节点。LSP段恢复标志携带在[RFC4872]中定义的保护对象中定义的一个保留字段中。LSP段恢复标志用于指示何时需要LSP段恢复。设置这些位后，将动态标识分支和合并节点。
Note, the procedures defined in this section parallel the explicit control procedures defined above in Section 4.2. The primary difference is in the creation of a recovery LSP's ERO.
注：本节中定义的程序与上文第4.2节中定义的明确控制程序平行。主要区别在于恢复LSP的ERO的创建。
LSP Segment Recovery Flags are carried in the PROTECTION object of the same C-Type defined in [RFC4872]. The format of the flags are:
LSP段恢复标志携带在[RFC4872]中定义的相同C类型的保护对象中。标志的格式为：
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|R| Reserved | Seg.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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|R| Reserved | Seg.Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In-Place (I): 1 bit
就地（I）：1位
When set (1) indicates that the desired segment recovery type indicated in the LSP Segment Recovery Flag is already in place for the associated LSP.
当设置为（1）时，表示LSP段恢复标志中指示的所需段恢复类型已适用于相关LSP。
Required (R): 1 bit
必需（R）：1位
When set (1) indicates that failure to establish the indicated protection should result in a failure of the LSP being protected.
当set（1）指示未能建立指示的保护时，应导致被保护的LSP发生故障。
Segment Recovery Flags (Seg.Flags): 6 bits
段恢复标志（段标志）：6位
This field is used to indicate when an upstream node desires LSP Segment recovery to be dynamically initiated where possible. The values used in this field are identical to the values defined for LSP Flags; see [RFC4872].
此字段用于指示上游节点希望在可能的情况下动态启动LSP段恢复的时间。此字段中使用的值与为LSP标志定义的值相同；参见[RFC4872]。
See [RFC4872] for the definition of other fields.
其他字段的定义参见[RFC4872]。
LSP Segment Recovery Flags are set to indicate that LSP segment recovery is desired for the LSP being signaled. The type of recovery desired is indicated by the flags. The decision to set the LSP Segment Recovery Flags is a local matter and outside the scope of this document. A value of zero (0) means that no dynamic identification of segment recovery branch nodes are needed for the associated LSP. When the In-Place bit is set, it means that the desired type of recovery is already in place for that particular LSP.
LSP段恢复标志被设置为指示所发信号的LSP需要LSP段恢复。所需的恢复类型由标志指示。设置LSP段恢复标志的决定是本地事务，不在本文档范围内。值为零（0）意味着相关LSP不需要段恢复分支节点的动态标识。当设置就地位时，意味着该特定LSP的所需恢复类型已经就位。
A transit node receiving a Path message containing a PROTECTION object with a non-zero LSP Segment Recovery Flags value and the In-Place bit clear (0) SHOULD consider if it can support the indicated recovery type and if it can identify an appropriate merge node for a recovery LSP. Dynamic identification MUST NOT be done when the processing node is identified as a branch node in an SERO. If a node is unable to provide the indicated recovery type or identify a merge node, the Path message MUST be processed normally, and the LSP Segment Recovery Flags MUST NOT be modified.
接收包含具有非零LSP段恢复标志值的保护对象的路径消息和过期位清除（0）的过境节点应该考虑它是否能够支持所指示的恢复类型，并且如果它能够标识用于恢复LSP的合适的合并节点。当处理节点被标识为SERO中的分支节点时，不得进行动态标识。如果节点无法提供指定的恢复类型或标识合并节点，则必须正常处理路径消息，并且不得修改LSP段恢复标志。
When a node dynamically identifies itself as a branch node and identifies the merge node for the type of recovery indicated in the LSP Segment Recovery Flags, it attempts to setup a recovery LSP. The dynamically identified information, together with the Path message of LSP being recovered, is used to create the recovery LSP.
当节点动态地将自己标识为分支节点并根据LSP段恢复标志中指示的恢复类型标识合并节点时，它将尝试设置恢复LSP。动态标识的信息与正在恢复的LSP的路径消息一起用于创建恢复LSP。
The Path message for the recovery LSP is created at the branch node by cloning the objects carried in the incoming Path message of the LSP being protected. Certain objects are replaced or modified in the recovery LSP's outgoing Path message. The Sender_template object MUST be updated to use an address (in its Tunnel Sender Address field) on the local node, and the LSP ID MUST be updated to ensure uniqueness. The Session object MUST be updated to use the address of the dynamically identified merge node as the tunnel endpoint address, the tunnel ID MAY be updated, and the extended tunnel ID MUST be set to the local node address. The PROTECTION object is updated with the In-Place bit set (1). Any RROs and EROs present in the incoming Path message MUST NOT be included in the recovery LSP. A new ERO MAY be created based on any path information dynamically computed by the local node.
恢复LSP的路径消息是通过克隆受保护LSP的传入路径消息中携带的对象在分支节点上创建的。某些对象在恢复LSP的传出路径消息中被替换或修改。必须更新Sender_template对象以使用本地节点上的地址（在其隧道Sender address字段中），并且必须更新LSP ID以确保唯一性。必须更新会话对象，以使用动态标识的合并节点的地址作为隧道端点地址，可以更新隧道ID，并且必须将扩展隧道ID设置为本地节点地址。保护对象使用在位位集（1）进行更新。传入路径消息中存在的任何RRO和ERO不得包含在恢复LSP中。可以基于本地节点动态计算的任何路径信息来创建新的ERO。
The resulting Path message is used to create the recovery LSP. While the recovery LSP exists, the PROTECTION object in the original Path message (unless overridden by local policy) MUST also be updated with the In-Place bit set (1). From this point on, Standard Path message processing is used in processing the resulting and original Path messages.
生成的路径消息用于创建恢复LSP。当恢复LSP存在时，原始路径消息中的保护对象（除非被本地策略覆盖）也必须使用就地位集（1）进行更新。从这一点开始，标准路径消息处理用于处理结果和原始路径消息。
The merge node of a dynamically controlled recovery LSP SHOULD reset (0) the In-Place bit in the PROTECTION object of the outgoing Path message associated with the terminated recovery LSP.
动态控制恢复LSP的合并节点应重置（0）与终止的恢复LSP关联的传出路径消息的保护对象中的就地位。
Unlike with explicit control, if the creation of a dynamically identified recovery LSP fails for any reason, the recovery LSP is removed, and no error message or indication is sent upstream. With this exception, all the other procedures for explicitly controlled recovery LSPs apply to dynamically controlled recovery LSPs. These other procedures are defined above in Sections 4.2.1 through 4.2.4.
与显式控制不同，如果动态标识的恢复LSP的创建因任何原因失败，将删除恢复LSP，并且不会向上游发送错误消息或指示。除此之外，显式控制的恢复LSP的所有其他过程都适用于动态控制的恢复LSP。上述第4.2.1节至第4.2.4节规定了这些其他程序。
This section presents the RSVP message related formats as modified by this document. Where they differ, formats for unidirectional LSPs are presented separately from bidirectional LSPs.
本节介绍本文件修改的RSVP消息相关格式。在不同之处，单向LSP的格式与双向LSP的格式是分开的。
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> ... ]
[ <SECONDARY_EXPLICIT_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> ... ]
[ <SECONDARY_EXPLICIT_ROUTE> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
The format of the sender description for unidirectional LSPs is:
单向LSP的发送方说明格式为：
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
[ <SECONDARY_RECORD_ROUTE> ... ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
[ <SECONDARY_RECORD_ROUTE> ... ]
The format of the sender description for bidirectional LSPs is:
双向LSP的发送方描述格式为：
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
<UPSTREAM_LABEL>
[ <SECONDARY_RECORD_ROUTE> ... ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
<UPSTREAM_LABEL>
[ <SECONDARY_RECORD_ROUTE> ... ]
The format of a PathErr message is as follows:
PathErr消息的格式如下所示：
<PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <SECONDARY_EXPLICIT_ROUTE> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <SECONDARY_EXPLICIT_ROUTE> ... ]
[ <POLICY_DATA> ... ]
<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> ]
[ <NOTIFY_REQUEST> ... ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <NOTIFY_REQUEST> ... ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC>
<LABEL> [ <RECORD_ROUTE> ]
[ <SECONDARY_RECORD_ROUTE> ... ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC>
<LABEL> [ <RECORD_ROUTE> ]
[ <SECONDARY_RECORD_ROUTE> ... ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
[ <SECONDARY_RECORD_ROUTE> ... ]
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
[ <SECONDARY_RECORD_ROUTE> ... ]
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
[ <SECONDARY_RECORD_ROUTE> ... ]
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
[ <SECONDARY_RECORD_ROUTE> ... ]
This document introduces new message objects for use in GMPLS signaling [RFC3473]. It does not introduce any new signaling messages, nor change the relationship between LSRs that are adjacent in the control plane.
本文档介绍了GMPLS信令[RFC3473]中使用的新消息对象。它不会引入任何新的信令消息，也不会改变控制平面中相邻的LSR之间的关系。
The procedures defined in this document result in an increase in the amount of topology information carried in signaling messages since the presence of SEROs and SRROs necessarily means that there is more information about LSP paths carried than in simple EROs and RROs. Thus, in the event of the interception of a signaling message, slightly more could be deduced about the state of the network than was previously the case, but this is judged to be a very minor security risk as this information is already available via routing.
本文件中定义的程序导致信令消息中承载的拓扑信息量增加，因为SEROs和SRROs的存在必然意味着比简单ERO和RRO中承载的LSP路径信息更多。因此，在信令消息被截获的情况下，可以推断出比以前稍微多一些的网络状态，但是这被认为是非常小的安全风险，因为该信息已经通过路由可用。
Otherwise, this document introduces no additional security considerations. See [RFC3473] for relevant security considerations.
否则，本文档不会引入其他安全注意事项。有关安全注意事项，请参见[RFC3473]。
IANA has assigned the following values for the namespaces defined in this document and reviewed in this section.
IANA已为本文档中定义的名称空间分配了以下值，并在本节中进行了审查。
IANA has made the following assignment to the "GMPLS Signaling Parameters" Registry (see [RFC4872]) located at http://www.iana.org/assignments/gmpls-sig-parameters.
IANA已向位于以下地址的“GMPLS信令参数”注册表（见[RFC4872]）进行了以下分配：http://www.iana.org/assignments/gmpls-sig-parameters.
Value Type
----- ----
2 Resource Sharing (R) [RFC4873]
Value Type
----- ----
2 Resource Sharing (R) [RFC4873]
This document defines bits carried in the Reserved field of the PROTECTION object defined in [RFC4872]. As no IANA registry for these bits is requested in [RFC4872], no IANA action is required related to this definition.
本文件定义了[RFC4872]中定义的保护对象的保留字段中携带的位。由于[RFC4872]中没有请求这些位的IANA注册表，因此不需要与此定义相关的IANA操作。
IANA has made the following assignments in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters.
IANA在位于的“RSVP参数”注册表的“类名、类号和类类型”部分进行了以下分配：http://www.iana.org/assignments/rsvp-parameters.
A new class named SECONDARY_EXPLICIT_ROUTE has been created in the 11bbbbbb range (200) with the following definition: Class Types or C-types:
在11bbbbbb范围（200）中创建了一个名为SECONDARY_EXPLICIT_ROUTE的新类，其定义如下：类类型或C类型：
Same values as EXPLICIT_ROUTE object (C-Num 20)
与显式路由对象相同的值（C-Num 20）
For Class 1, C-Type 1, the following additional Subobject type is defined:
对于类别1，C类型1，定义了以下附加子对象类型：
37 PROTECTION [RFC4873]
37保护[RFC4873]
IANA has made the following assignments in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters.
IANA在位于的“RSVP参数”注册表的“类名、类号和类类型”部分进行了以下分配：http://www.iana.org/assignments/rsvp-parameters.
A new class named SECONDARY_RECORD_ROUTE has been created in the 11bbbbbb range (201) with the following definition:
在11bbbbbb范围（201）中创建了一个名为SECONDARY_RECORD_ROUTE的新类，其定义如下：
Class Types or C-types:
类别类型或C类型：
Same values as RECORD_ROUTE object (C-Num 21)
与记录路由对象（C-Num 21）的值相同
For Class 1, C-Type 1, the following additional Subobject type is defined:
对于类别1，C类型1，定义了以下附加子对象类型：
37 PROTECTION [RFC4873]
37保护[RFC4873]
IANA has made the following assignments in the "Routing Problem" subsection of "Error Codes and Values" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters.
IANA在“RSVP参数”注册表的“错误代码和值”部分的“路由问题”小节中进行了以下分配，该注册表位于http://www.iana.org/assignments/rsvp-parameters.
21 = LSP Segment Protection Failed [RFC4873]
21=LSP段保护失败[RFC4873]
This document modifies the PROTECTION object, class number 37, C-Type 2 (defined in Section 14.1. of [RFC4872]).
本文件修改了保护对象，类别编号37，C型2（定义见[RFC4872]第14.1节）。
[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月。
[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., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令-资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872]Lang，J.P.，Ed.，Rekhter，Y.，Ed.，和D.Papadimitriou，Ed.，“支持端到端通用多协议标签交换（GMPLS）恢复的RSVP-TE扩展”，RFC 4872，2007年5月。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Swallow，G.，和A.Atlas，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification," RFC 4426, March 2006.
[RFC4426]Lang，J.，Ed.，Rajagopalan，B.，Ed.，和D.Papadimitriou，Ed.，“通用多协议标签交换（GMPLS）恢复功能规范”，RFC 4426，2006年3月。
[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月。
Authors' Addresses
作者地址
Lou Berger LabN Consulting, L.L.C.
Lou Berger LabN咨询公司，L.L.C。
Phone: +1 301-468-9228
EMail: lberger@labn.net
Phone: +1 301-468-9228
EMail: lberger@labn.net
Igor Bryskin ADVA Optical 7926 Jones Branch Drive Suite 615 McLean VA, 22102
Igor Bryskin ADVA光学7926琼斯分支驱动器套件615 McLean VA，22102
EMail: IBryskin@advaoptical.com
EMail: IBryskin@advaoptical.com
Dimitri Papadimitriou Alcatel Francis Wellesplein 1 B-2018 Antwerpen, Belgium
迪米特里·帕帕迪米特里奥·阿尔卡特弗朗西斯·韦勒斯普林1 B-2018比利时安特卫普
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel-lucent.be
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel-lucent.be
Adrian Farrel Old Dog Consulting
阿德里安·法雷尔老狗咨询公司
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
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编辑功能的资金目前由互联网协会提供。