Internet Engineering Task Force (IETF) D. Caviglia
Request for Comments: 5852 D. Ceccarelli
Category: Standards Track D. Bramanti
ISSN: 2070-1721 Ericsson
D. Li
Huawei Technologies
S. Bardalai
Fujitsu Network
April 2010
Internet Engineering Task Force (IETF) D. Caviglia
Request for Comments: 5852 D. Ceccarelli
Category: Standards Track D. Bramanti
ISSN: 2070-1721 Ericsson
D. Li
Huawei Technologies
S. Bardalai
Fujitsu Network
April 2010
RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network
在启用GMPLS的传输网络中，用于从管理平面到控制平面的LSP切换的RSVP-TE信令扩展
Abstract
摘要
In a transport network scenario, Data Plane connections controlled by either a Generalized Multiprotocol Label Switching (GMPLS) Control Plane (Soft Permanent Connections - SPC) or a Management System (Permanent Connections - PC) may independently coexist. The ability of transforming an existing PC into an SPC and vice versa -- without actually affecting Data Plane traffic being carried over it -- is a requirement. The requirements for the conversion between permanent connections and switched connections in a GMPLS Network are defined in RFC 5493.
在传输网络场景中，由通用多协议标签交换（GMPLS）控制平面（软永久连接-SPC）或管理系统（永久连接-PC）控制的数据平面连接可以独立共存。将现有PC转换为SPC或SPC的能力是一项要求，而不影响通过PC传输的数据平面流量。RFC 5493中定义了GMPLS网络中永久连接和交换连接之间的转换要求。
This memo describes an extension to GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling that enables the transfer of connection ownership between the Management and the Control Planes. Such a transfer is referred to as a Handover. This document defines all Handover-related procedures. This includes the handling of failure conditions and subsequent reversion to original state. A basic premise of the extension is that the Handover procedures must never impact an already established Data Plane connection.
本备忘录描述了GMPLS资源预留协议-流量工程（RSVP-TE）信令的扩展，该信令支持管理层和控制层之间的连接所有权转移。这种转移称为移交。本文件规定了所有移交相关程序。这包括故障条件的处理和随后恢复到原始状态。扩展的一个基本前提是，切换过程决不能影响已建立的数据平面连接。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5852.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5852.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Dedication .................................................4
2. Terminology .....................................................4
3. Motivation ......................................................4
4. Procedures ......................................................5
4.1. MP-to-CP Handover: LSP Ownership Transfer from
Management Plane to Control Plane ..........................6
4.2. MP-to-CP Handover Procedure Failure Handling ...............7
4.2.1. MP-to-CP Handover Failure - Path Failure ............8
4.2.1.1. MP-to-CP Handover Failure - Path
Message and Data Plane Failure .............8
4.2.1.2. MP-to-CP Handover Failure - Path
Message and Communication Failure ..........8
4.2.2. MP-to-CP Handover Failure - Resv Error ..............9
4.2.2.1. MP-to-CP Handover Failure - Resv
Error and Data Plane Failure ...............9
4.2.2.2. MP-to-CP Handover Failure - Resv
Error and Communication Failure ...........10
4.2.2.3. MP-to-CP Handover Failure - Node
Graceful Restart ..........................12
4.3. CP-to-MP Handover: LSP Ownership Transfer from
Control Plane to Management Plane .........................15
4.4. CP-to-MP Handover Procedure Failure .......................16
5. Minimum Information for MP-to-CP Handover ......................17
6. RSVP Message Formats ...........................................19
7. Objects Modification ...........................................19
7.1. Administrative Status Object ..............................19
7.2. Error Spec Object .........................................19
8. Compatibility ..................................................20
9. Security Considerations ........................................20
10. IANA Considerations ...........................................20
11. Acknowledgments ...............................................21
12. Contributors ..................................................21
13. References ....................................................21
13.1. Normative References .....................................21
13.2. Informative References ...................................22
1. Introduction ....................................................4
1.1. Dedication .................................................4
2. Terminology .....................................................4
3. Motivation ......................................................4
4. Procedures ......................................................5
4.1. MP-to-CP Handover: LSP Ownership Transfer from
Management Plane to Control Plane ..........................6
4.2. MP-to-CP Handover Procedure Failure Handling ...............7
4.2.1. MP-to-CP Handover Failure - Path Failure ............8
4.2.1.1. MP-to-CP Handover Failure - Path
Message and Data Plane Failure .............8
4.2.1.2. MP-to-CP Handover Failure - Path
Message and Communication Failure ..........8
4.2.2. MP-to-CP Handover Failure - Resv Error ..............9
4.2.2.1. MP-to-CP Handover Failure - Resv
Error and Data Plane Failure ...............9
4.2.2.2. MP-to-CP Handover Failure - Resv
Error and Communication Failure ...........10
4.2.2.3. MP-to-CP Handover Failure - Node
Graceful Restart ..........................12
4.3. CP-to-MP Handover: LSP Ownership Transfer from
Control Plane to Management Plane .........................15
4.4. CP-to-MP Handover Procedure Failure .......................16
5. Minimum Information for MP-to-CP Handover ......................17
6. RSVP Message Formats ...........................................19
7. Objects Modification ...........................................19
7.1. Administrative Status Object ..............................19
7.2. Error Spec Object .........................................19
8. Compatibility ..................................................20
9. Security Considerations ........................................20
10. IANA Considerations ...........................................20
11. Acknowledgments ...............................................21
12. Contributors ..................................................21
13. References ....................................................21
13.1. Normative References .....................................21
13.2. Informative References ...................................22
In a typical traditional transport network scenario, Data Plane (DP) connections between two endpoints are controlled by means of a Network Management System (NMS) operating within the Management Plane (MP). NMS/MP is the owner of such transport connections, being responsible for their setup, teardown, and maintenance.
在典型的传统传输网络场景中，两个端点之间的数据平面（DP）连接由在管理平面（MP）内运行的网络管理系统（NMS）控制。NMS/MP是此类传输连接的所有者，负责其设置、拆卸和维护。
The adoption of a Generalized MPLS (GMPLS) [RFC3945] Control Plane (CP) in a network that is already in service -- controlled by the NMS at the MP level -- introduces the need for a procedure able to coordinate a controlled Handover of a Data Plane connection from the MP to the CP.
在已经投入使用的网络中采用通用MPLS（GMPLS）[RFC3945]控制平面（CP）——由MP级别的NMS控制——需要一个能够协调从MP到CP的数据平面连接的受控切换的过程。
In addition, the control Handover in the opposite direction, from CP to MP should be possible as well. The procedures described in this memo can be applied to a Label Switched Path (LSP) in any DP switching technology and any network architecture.
此外，从CP到MP的相反方向的控制移交也应该是可能的。本备忘录中描述的程序可应用于任何DP交换技术和任何网络架构中的标签交换路径（LSP）。
This memo describes an extension to GMPLS Resource reSerVation Protocol - Traffic Engineering (RSVP-TE) [RFC3471] [RFC3473] signaling that enables the Handover of connection ownership between the Management and the Control Planes. All Handover-related procedures are defined below. This includes the handling of failure conditions and subsequent reversion to original state. A basic premise of the extension is that the Handover procedures must never impact the exchange of user data on LSPs that are already established in the DP.
本备忘录描述了GMPLS资源预留协议-流量工程（RSVP-TE）[RFC3471][RFC3473]信令的扩展，该信令支持管理层和控制层之间连接所有权的移交。所有移交相关程序定义如下。这包括故障条件的处理和随后恢复到原始状态。扩展的一个基本前提是，移交程序不得影响DP中已建立的LSP上的用户数据交换。
We would like to dedicate this work to our friend and colleague Dino Bramanti, who passed away at the early age of 38. Dino has been involved in this work since its beginning.
我们想把这项工作献给我们的朋友和同事迪诺·布拉曼蒂，他在38岁时去世。迪诺从一开始就参与了这项工作。
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]中所述进行解释。
The main motivation behind this work is the definition of a simple and very low-impact procedure that satisfies the requirements defined in [RFC5493]. Such a procedure is aimed at giving the transport network operators the chance to hand over the ownership of existing LSPs provisioned by NMS from the MP to the CP without disrupting user
这项工作背后的主要动机是定义一个简单且影响非常小的程序，以满足[RFC5493]中定义的要求。这样一个程序旨在使传输网络运营商有机会将NMS提供的现有LSP的所有权从MP移交给CP，而不会中断用户
traffic flowing on them. Handover from the MP to the CP (i.e., when existing DP connection ownership and control is passed from the MP to the CP) has been defined as a mandatory requirement, while the opposite operation, CP-to-MP Handover, has been considered as a nice-to-have feature that can be seen as an emergency procedure to disable the CP and take manual control of the LSP. For more details on requirements and motivations, please refer to [RFC5493].
车辆在他们身上流动。从MP到CP的切换（即，当现有DP连接所有权和控制权从MP转移到CP时）已被定义为强制性要求，而相反的操作，即CP到MP的切换，已被认为是一个很好的功能，可被视为禁用CP并手动控制LSP的紧急程序。有关要求和动机的更多详细信息，请参阅[RFC5493]。
The modification defined in this document refers only to the ADMIN_STATUS Object, that is, the message flow is left unmodified for both LSP setup and deletion. Moreover, a new Error Value is defined to identify the failure of a Handover procedure.
本文档中定义的修改仅涉及ADMIN_STATUS对象，即对于LSP设置和删除，消息流保持不变。此外，定义了一个新的错误值来识别切换过程的失败。
The following paragraphs give detailed description of the "MP-to-CP Handover" and "CP-to-MP Handover" procedures, based on the use of a newly defined bit called "H bit".
以下段落详细描述了“MP到CP切换”和“CP到MP切换”过程，基于使用新定义的位，称为“H位”。
Just as when setting up an LSP using the CP [RFC3473], the Path message may contain full information about the explicit route including the links and labels traversed by the LSP. This information is encoded in the Explicit Route Object (ERO), and must be supplied by the MP using details recorded when the LSP was provisioned, or collected by the MP by inspecting the nodes along the path.
正如使用CP[RFC3473]设置LSP时一样，Path消息可能包含有关显式路由的完整信息，包括LSP所穿越的链路和标签。此信息编码在显式路由对象（ERO）中，并且必须由MP使用在供应LSP时记录的详细信息提供，或者由MP通过沿路径检查节点来收集。
Alternatively, and also just as when setting up an LSP using the CP [RFC3473], the ERO may include less information such that the details of the next hop have to be determined by each node along the LSP as it processes the Path message. This approach may be desirable when the full information is not available to the MP or cannot be passed to the head-end node when initiating the Handover from the MP to the CP.
或者，并且也如同使用CP[RFC3473]设置LSP时一样，ERO可以包括较少的信息，使得下一跳的细节必须由LSP上的每个节点在处理路径消息时确定。当MP无法获得全部信息或在启动从MP到CP的切换时无法将其传递给前端节点时，这种方法可能是可取的。
This section (Section 4) describes the general procedures and protocol extensions for MP-to-CP Handover, and it uses the case of a fully detailed ERO to describe the mechanism. Section 5 describes how each node behaves in the case of a limited amount of information in the ERO.
本节（第4节）描述了MP到CP切换的一般程序和协议扩展，并使用了一个完全详细的ERO案例来描述该机制。第5节描述了在ERO中信息量有限的情况下，每个节点的行为。
Note that when Handover is being performed for a bidirectional LSP and the ERO contains full information including labels, the ERO SHOULD include both upstream and downstream labels. Per Section 5.1.1 of [RFC3473], the labels are indicated on an output basis; this means that the labels are used by the upstream node to create the LABEL_SET Object and, for bidirectional LSPs, the UPSTREAM_LABEL Object used in the outgoing Path message.
注意，当为双向LSP执行切换时，ERO包含包括标签在内的完整信息，ERO应包括上游和下游标签。根据[RFC3473]第5.1.1节，标签以输出为基础显示；这意味着上游节点使用标签创建LABEL_SET对象，对于双向LSP，则创建传出路径消息中使用的上游_LABEL对象。
4.1. MP-to-CP Handover: LSP Ownership Transfer from Management Plane to Control Plane
4.1. MP到CP移交：LSP所有权从管理平面转移到控制平面
The MP-to-CP Handover procedure MUST create an RSVP-TE session along the path of the LSP to be moved from the MP to the CP, associating it with the existing cross-connected resources owned by the MP (e.g., lambdas, time slots, or reserved bandwidth) and at the same time transferring their ownership to the CP.
MP到CP切换过程必须沿要从MP移动到CP的LSP路径创建RSVP-TE会话，将其与MP拥有的现有交叉连接资源（例如，lambda、时隙或保留带宽）关联，同时将其所有权转移到CP。
The operator instructs the ingress node to hand over control of the LSP from the MP to the CP. In this Handover mode, it supplies the exact path of the LSP including any resource reservation and label information.
操作员指示入口节点将LSP的控制权从MP移交给CP。在此移交模式下，它提供LSP的确切路径，包括任何资源保留和标签信息。
The ingress MUST check that no corresponding Path state exists and that corresponding Data Plane state does exist. If there is an error, this MUST be reported to the operator and further protocol action MUST NOT be taken.
入口必须检查是否不存在相应的路径状态，以及是否存在相应的数据平面状态。如果出现错误，必须向操作员报告，不得采取进一步的协议措施。
The ingress signals the LSP using a Path message with the H bit and R bit set in the ADMIN_STATUS Object. In this mode of Handover, the Path message also carries an ERO that includes Label subobjects indicating the labels used by the LSP at each hop. The ingress MUST start the Expiration timer (see Section 4.2.1.2 for expiration of this timer). Such a timer SHOULD be configurable per LSP and have a default value of 30 seconds.
入口使用路径消息向LSP发送信号，该消息在ADMIN_STATUS对象中设置了H位和R位。在这种切换模式中，路径消息还携带一个ERO，该ERO包括指示LSP在每个跃点使用的标签的标签子对象。入口必须启动过期计时器（该计时器的过期见第4.2.1.2节）。此类计时器应可根据LSP进行配置，并具有30秒的默认值。
Each Label Switching Router (LSR) that receives a Path message with the H bit set checks to see whether there is any matching Path state.
每个标签交换路由器（LSR）接收一个H位设置的路径消息，检查是否有任何匹配的路径状态。
o If matching Path state is found with the H bit set, this is a Path refresh and should be treated accordingly [RFC3473].
o 如果在H位设置中找到匹配的路径状态，则这是路径刷新，应相应地进行处理[RFC3473]。
o If matching Path state is found with the H bit clear, this is an error and MUST be treated according to the error case description in Section 4.2.1.1.
o 如果在清除H位的情况下发现匹配路径状态，则这是一个错误，必须根据第4.2.1.1节中的错误案例说明进行处理。
o If no Path state is found, the LSR goes on to check whether there is any matching Data Plane state.
o 如果没有找到路径状态，LSR将继续检查是否存在任何匹配的数据平面状态。
o If no matching Data Plane state is found (including only partially matching Data Plane state), this is an error or a race condition. It MUST be handled according to the description in Section 4.2.1.1.
o 如果未找到匹配的数据平面状态（仅包括部分匹配的数据平面状态），则这是错误或竞争条件。必须按照第4.2.1.1节的说明进行处理。
o If matching Data Plane state is found, the LSR MUST save the Path state (including the set H bit), and it MUST forward the Path message to the egress. The LSR MUST retain any MP state associated with the LSP at this point.
o 如果找到匹配的数据平面状态，LSR必须保存路径状态（包括set H位），并且必须将路径消息转发到出口。此时，LSR必须保留与LSP关联的任何MP状态。
An egress LSR MUST act as any other LSR, except that there is no downstream node to which to forward the Path message. If all checks are passed, the egress MUST respond with a Resv with the H bit set.
出口LSR必须充当任何其他LSR，除非没有要转发路径消息的下游节点。如果所有检查都通过，出口必须以设置了H位的Resv响应。
A transit LSR MUST process each Resv according to the normal rules of [RFC3473].
运输LSR必须根据[RFC3473]的正常规则处理每个Resv。
When an ingress LSR receives a Resv message carrying the H bit set, it checks the Expiration timer.
当入口LSR接收到携带H位集的Resv消息时，它会检查过期计时器。
o If the timer is not running, the Resv is treated as a refresh and no special action is taken [RFC3473].
o 如果计时器未运行，则Resv将被视为刷新，并且不采取任何特殊操作[RFC3473]。
o If the timer is running, the ingress MUST cancel the timer and SHOULD notify the operator that the first stage of Handover is complete. The ingress MUST send a Path message that is no different from the previous message except that the H bit MUST be clear.
o 如果计时器正在运行，入口必须取消计时器，并通知操作员第一阶段的移交已完成。入口必须发送与前一条消息相同的路径消息，但H位必须清除。
The Path message with the H bit clear will travel the length of the LSP and will result in the return of a Resv with the H bit clear according to normal processing [RFC3473]. As a result, the H bit will be cleared in the stored Path state at each transit LSR and at the egress LSR. Each LSR SHOULD release any associated MP state associated with the LSP when it receives the Path message with H bit clear, but MAY retain the information according to local policy for use in future MP processing.
具有H位清除的路径消息将沿LSP的长度传播，并将导致根据正常处理返回具有H位清除的Resv[RFC3473]。结果，在每个传输LSR和出口LSR处，H位将在存储路径状态中被清除。每个LSR在接收到带有H位清除的Path消息时，应释放与LSP关联的任何关联MP状态，但可以根据本地策略保留信息，以供将来MP处理使用。
When the ingress receives a Resv with the H bit clear, the Handover is completed. The ingress SHOULD notify the operator that the Handover is correctly completed.
当入口接收到清除H位的Resv时，切换完成。入口应通知操作员已正确完成移交。
In the case of MP-to-CP Handover, two different failure scenarios can happen: Path Failure and Resv Failure. Moreover, each failure can be due to two different causes: DP Failure or Communication Failure. In any case, the LSP ownership MUST be immediately rolled back to the one previous to the Handover procedure. A section for each combination will be analyzed in the following.
在MP到CP切换的情况下，可能会发生两种不同的故障情况：路径故障和Resv故障。此外，每个故障可能由两个不同的原因造成：DP故障或通信故障。在任何情况下，LSP所有权必须立即回滚到移交程序之前的所有权。下面将分析每个组合的一个部分。
4.2.1.1. MP-to-CP Handover Failure - Path Message and Data Plane Failure
4.2.1.1. MP到CP切换失败-路径消息和数据平面故障
In the following paragraph, we will analyze the case where the Handover procedure fails during the Path message processing.
在下一段中，我们将分析在路径消息处理过程中切换过程失败的情况。
| Path | | |
|--------------->| Path | |
| |---------------X| |
| | PathErr | |
| PathErr |<---------------| |
|<---------------| | |
| | | |
Ingress LER LSR A LSR B Egress LER
| Path | | |
|--------------->| Path | |
| |---------------X| |
| | PathErr | |
| PathErr |<---------------| |
|<---------------| | |
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 1: MP2CP - Path Msg and DP Failure
图1:MP2CP-路径消息和DP故障
If an error occurs, the node detecting the error MUST respond to the received Path message with a PathErr message, and MUST abort the Handover procedure. The PathErr message SHOULD have the Path_State_Removed flag set [RFC3473], but implementations MAY retain their local state and wait for Path state timeout as per normal RSVP processing.
如果发生错误，检测到错误的节点必须使用PathErr消息响应接收到的Path消息，并且必须中止切换过程。PathErr消息应设置Path_State_Removed标志[RFC3473]，但实现可能保留其本地状态，并根据正常RSVP处理等待Path State超时。
Nodes receiving a PathErr message MUST follow standard PathErr message processing and the associated DP resources MUST NOT be impacted. If the local CP state indicates that a Handover is in progress (based on the H bit in the Path message), the LSR MUST revert the LSP ownership to the MP.
接收PathErr消息的节点必须遵循标准PathErr消息处理，并且关联的DP资源不得受到影响。如果本地CP状态指示正在进行切换（基于Path消息中的H位），则LSR必须将LSP所有权恢复给MP。
4.2.1.2. MP-to-CP Handover Failure - Path Message and Communication Failure
4.2.1.2. MP到CP切换失败-路径消息和通信失败
Other possible scenarios are shown in the following figures and are based on the inability to reach a node along the path of the LSP.
其他可能的场景如下图所示，基于无法沿着LSP路径到达节点。
The below scenario postulates the use of a reliable message delivery based on the mechanism defined in [RFC2961].
下面的场景假设使用基于[RFC2961]中定义的机制的可靠消息传递。
| Path | | |
|--------------->| Path | |
| |---------------X| |
| |---------------X| |
| | ... | |
| |---------------X| |
| | | |
Ingress LER LSR A LSR B Egress LER
| Path | | |
|--------------->| Path | |
| |---------------X| |
| |---------------X| |
| | ... | |
| |---------------X| |
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 2: MP2CP - Path Msg and Communication Failure (Reliable Delivery)
图2:MP2CP-路径消息和通信故障（可靠交付）
The Path message sent from LSR A towards LSR B is lost or does not reach the destination for any reason. As a reliable delivery mechanism is implemented, LSR A retransmits the Path message for a configurable number of times, and if no ack is received, the Handover procedure will be aborted (via the Expiration timer).
从LSR A发送到LSR B的路径消息丢失或由于任何原因未到达目的地。由于实现了可靠的传递机制，LSR a将以可配置的次数重新传输路径消息，并且如果没有接收到ack，则切换过程将中止（通过到期计时器）。
In the next scenario RSVP-TE messages are sent without reliable message delivery, that is, no [RFC2961] MessageID procedure is used.
在下一个场景中，发送RSVP-TE消息时没有可靠的消息传递，即不使用[RFC2961]MessageID过程。
| Path | | |
|--------------->| Path | |
| |----------X | |
| | | |
TIMER EXPIRES | | |
| Path Tear | Path Tear | Path Tear |
|--------------->|--------------->|--------------->|
| | | |
Ingress LER LSR A LSR B Egress LER
| Path | | |
|--------------->| Path | |
| |----------X | |
| | | |
TIMER EXPIRES | | |
| Path Tear | Path Tear | Path Tear |
|--------------->|--------------->|--------------->|
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 3: MP2CP - Path Msg and Communication Failure (No Reliable Delivery)
图3:MP2CP-路径消息和通信故障（无可靠交付）
If the Resv message is not received before the expiration of the Expiration timer, the Handover procedure is aborted as described in Section 4.2.1.1. Please note that any node that has forwarded a Path (LSR A), i.e., has installed local path state, will send a PathTear when that state is removed (according to [RFC2205]).
如果在到期计时器到期之前未收到Resv消息，则按照第4.2.1.1节的说明中止移交程序。请注意，已转发路径（LSR a）的任何节点，即已安装本地路径状态的节点，在移除该状态时（根据[RFC2205]）都将发送Path撕裂。
In the case of a failure occurrence during the Resv message processing (in case there has been any change in the Data Plane during the signaling), the node MUST send a PathErr message [RFC2205] in the upstream direction. The PathErr message is constructed and
在Resv消息处理期间发生故障的情况下（在信令期间数据平面发生任何变化的情况下），节点必须在上游方向发送PathErr消息[RFC2205]。PathErr消息被构造并
processed as defined above in Section 4.2.1.1. The failure detection node MUST also send a PathTear message downstream. The PathTear message is constructed and processed as defined above in Section 4.2.1.1.
按照上述第4.2.1.1节的规定进行处理。故障检测节点还必须向下游发送PathTear消息。PathTear消息的构造和处理如上文第4.2.1.1节所述。
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| |X---------------| |
| PathErr | PathTear | PathTear |
|<---------------|--------------->|--------------->|
| | | |
Ingress LER LSR A LSR B Egress LER
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| |X---------------| |
| PathErr | PathTear | PathTear |
|<---------------|--------------->|--------------->|
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 4: MP2CP - Resv Error and DP Failure
图4:MP2CP-Resv错误和DP故障
In the case shown in Figure 4, the failure occurs in LSR A. A PathTear message is sent towards B and a PathErr message (with ErrorCode set to "Handover Procedure Failure") is sent in the upstream direction. The PathErr and PathTear messages remove the Path state established by the Path messages along the nodes of the LSP and abort the Handover procedure.
在图4所示的情况下，故障发生在LSR A中。Path催泪消息发送到B，PathErr消息（ErrorCode设置为“切换过程故障”）发送到上游方向。PathErr和PathTear消息删除路径消息沿LSP节点建立的路径状态，并中止切换过程。
Please note that the failure occurred after the Handover procedure was successfully completed in LSR B, but Handover state will still be maintained locally as, per Section 4.1, a Path message with the H bit clear will have not yet been sent or received. A node that receives a PathTear when it has Path state with the H bit set MUST remove Path state, but MUST NOT change Data Plane state. It MUST return LSP ownership to the MP.
请注意，故障发生在LSR B中成功完成移交程序后，但移交状态仍将在本地保持，因为根据第4.1节，尚未发送或接收H位清除的路径消息。当具有设置为H位的路径状态时接收Path撕裂的节点必须移除路径状态，但不得更改数据平面状态。它必须将LSP所有权返回给MP。
4.2.2.2. MP-to-CP Handover Failure - Resv Error and Communication Failure
4.2.2.2. MP到CP切换失败-Resv错误和通信失败
When a Resv message cannot reach one or more of the upstream nodes, the procedure is quite similar to the one previously seen about the Path message. Even in this case, it is possible to distinguish two different scenarios.
当Resv消息无法到达一个或多个上游节点时，该过程与之前看到的关于Path消息的过程非常相似。即使在这种情况下，也可以区分两种不同的场景。
In the first scenario we consider the utilization of a reliable message delivery based on the mechanism defined in [RFC2961]. After a correct forwarding of the Path message along the nodes of the LSP, the Egress LSR sends a Resv message in the opposite direction. It might happen that the Resv message does not reach the ingress Label Edge Router (LER) or an LSR, say LSR A. LSR B MUST send a Resv message again for a configurable number of times and then, if the delivery does not succeed, the adoption procedure will be aborted (via the Expiration timer).
在第一种情况下，我们考虑利用基于[RCF961]中定义的机制的可靠消息传递。在沿着LSP的节点正确转发路径消息之后，出口LSR以相反方向发送Resv消息。可能会发生Resv消息未到达入口标签边缘路由器（LER）或LSR（例如LSR A）的情况。LSR B必须再次发送Resv消息，发送次数可配置，然后，如果发送未成功，则采用过程将中止（通过过期计时器）。
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| | X---------| |
| | X---------| |
| | ... | |
| | X---------| |
| | | |
Ingress
LSR A LSR B Egress LER
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| | X---------| |
| | X---------| |
| | ... | |
| | X---------| |
| | | |
Ingress
LSR A LSR B Egress LER
Figure 5: MP2CP - Resv Error and Communication Failure (Reliable Delivery)
图5:MP2CP-Resv错误和通信故障（可靠交付）
Considering that the Resv message did not manage to reach LSR A, it is highly probable that the PathErr would fail too. Due to this fact, the Expiration timer is used on the ingress LER after sending the path and on LSR A after forwarding it. When the timer expires, if no Resv or PathErr message is received, the Handover procedure is aborted as described in Section 4.2.1.1 and the LSP ownership is returned to the Management Plane.
考虑到Resv消息没有成功到达LSR A，PathErr也很可能会失败。由于这一事实，在发送路径后在入口LER上使用过期计时器，在转发路径后在LSR A上使用过期计时器。计时器到期时，如果未收到Resv或PathErr消息，则按照第4.2.1.1节中的说明中止切换过程，并将LSP所有权返回给管理平面。
Figure 6, on the other hand, shows the scenario in which no reliable delivery mechanism is implemented.
另一方面，图6显示了没有实现可靠交付机制的场景。
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| | X---------| |
TIMER EXPIRES | | |
| Path Tear | Path Tear | Path Tear |
|--------------->|--------------->|--------------->|
| | | |
Ingress LER LSR A LSR B Egress LER
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| | X---------| |
TIMER EXPIRES | | |
| Path Tear | Path Tear | Path Tear |
|--------------->|--------------->|--------------->|
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 6: MP2CP - Resv Error and Communication Failure (No Reliable Delivery)
图6:MP2CP-Resv错误和通信故障（无可靠交付）
If no Resv message is received before the Expiration timer expires, the ingress LER follows the same procedure defined in Section 4.1.
如果在到期计时器到期之前未收到Resv消息，则进入LER遵循第4.1节中定义的相同程序。
If node restart and graceful restart are enabled, then one of the following scenarios will happen.
如果启用了节点重新启动和优雅重新启动，则将发生以下情况之一。
Case I - Finite Restart Time
案例一-有限重启时间
In this case, the Restart Time (see [RFC3473]) is finite, i.e., not a value of 0xffffffff. In the sequence diagram below, assume LSR A restarts. If the ingress LER does not receive the Resv message in time, it MUST abort the Handover process by generating a PathTear message downstream. Also, if LSR A does not complete the restart process within the restart time interval, then LSR B MUST start tearing down all LSPs between LSR A and LSR B and this includes the LSP that is being used to carry out the Handover of MP resources to the CP. LSP B MUST generate a PathTear message downstream and a PathErr message upstream. Both LSR B and the egress LER MUST NOT release the DP resources because, in both nodes, the H bit is set in the local Path state.
在这种情况下，重启时间（参见[RFC3473]）是有限的，即不是0xFFFFFF的值。在下面的序列图中，假设LSR A重新启动。如果入口LER没有及时接收到Resv消息，它必须通过在下游生成PathTear消息来中止切换过程。此外，如果LSR A未在重启时间间隔内完成重启过程，则LSR B必须开始拆除LSR A和LSR B之间的所有LSP，这包括用于将MP资源移交给CP的LSP。LSP B必须在下游生成PathTear消息，在上游生成PathErr消息。LSR B和出口LER都不能释放DP资源，因为在这两个节点中，H位都设置为本地路径状态。
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| X X---------| |
| PathTear | |
|-------X Restart Timer |
| Expires |
| PathErr | PathTear |
| X--------|--------------->|
| | |
| X | |
| | | |
Ingress LER LSR A LSR B Egress LER
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| X X---------| |
| PathTear | |
|-------X Restart Timer |
| Expires |
| PathErr | PathTear |
| X--------|--------------->|
| | |
| X | |
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 7: MP2CP - Node Graceful Restart - Case I
Figure 7: MP2CP - Node Graceful Restart - Case I
Case II - Infinite Restart Time
案例二-无限重启时间
In this case, the Restart Time (see [RFC3473]) indicates that the restart of the sender's Control Plane may occur over an indeterminate interval, i.e., is 0xffffffff. The sequence is quite similar to the previous one. In this sequence, the restart timer will not expire in LSR B since it is run infinitely. Instead, after LSR A restarts, LSR B MUST start the recovery timer. The recovery timer will expire since there will be no Path message with the RECOVERY LABEL received from LSR A given the ingress node had already removed the local Path state after it aborts the Handover process. Thus, LSR B MUST tear down the specific LSP that is being used to convert the MP resources to CP by generating a PathTear message downstream and PathErr message upstream. Similarly to the previous case, both LSR B and the egress LER MUST NOT release the DP resources because the H bit is set in the local Path state.
在这种情况下，重新启动时间（参见[RFC3473]）表示发送方控制平面的重新启动可能在不确定的时间间隔内发生，即0xFFFFFF。这个序列与前一个非常相似。在这个序列中，重启计时器不会在LSR B中过期，因为它是无限运行的。相反，在LSR A重新启动后，LSR B必须启动恢复计时器。恢复计时器将过期，因为如果入口节点在中止切换过程后已删除本地路径状态，则不会收到带有从LSR A接收的恢复标签的路径消息。因此，LSR B必须通过在下游生成PathTear消息，在上游生成PathErr消息，来拆除用于将MP资源转换为CP的特定LSP。与前面的情况类似，LSR B和出口LER都不能释放DP资源，因为H位设置在本地路径状态。
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| X X---------| |
| PathTear | |
|-------X | |
| | |
| X | |
| | | |
| | Recovery Timer |
| | Expires |
| PathErr | PathErr | PathTear |
|<---------------|<---------------|--------------->|
| | | |
Ingress LER LSR A LSR B Egress LER
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| X X---------| |
| PathTear | |
|-------X | |
| | |
| X | |
| | | |
| | Recovery Timer |
| | Expires |
| PathErr | PathErr | PathTear |
|<---------------|<---------------|--------------->|
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 8: MP2CP - Node Graceful Restart - Case II
Figure 8: MP2CP - Node Graceful Restart - Case II
Case III
案例三
In this case, the ingress LER does not abort the Handover process. When LSR A restarts, the ingress LER detects the restart and MUST re-generate the Path message with the H bit set in order to restart the Handover.
在这种情况下，入口LER不会中止切换过程。当LSR A重新启动时，入口LER检测到重新启动，并且必须使用设置的H位重新生成路径消息，以便重新启动切换。
When LSR B receives the Path message, it sees the H-bit set on the message and also sees that it has the H-bit set in its own state and that it has sent the Resv. But it is also aware that LSR A has restarted and could have sent a Path message with a RECOVERY LABEL object. LSR B may attempt to resume the Handover process or may abort the Handover. This choice is made according to local policy.
当LSR B接收到Path消息时，它会看到消息上设置的H位，也会看到它在自己的状态下设置了H位，并且它已经发送了Resv。但它也知道LSR A已重新启动，可能已发送带有恢复标签对象的路径消息。LSR B可尝试恢复切换过程或中止切换。这一选择是根据当地政策作出的。
If resuming the Handover, LSR B MUST treat the received Path message as a retransmission, and MUST retransmit its Resv. If aborting Handover, LSR B MUST return a PathErr and MUST send a PathTear downstream. In both cases, LSR B MUST NOT modify the DP state.
如果恢复切换，LSR B必须将接收到的路径消息视为重传，并且必须重传其Resv。如果中止切换，LSR B必须返回一个PathErr，并且必须向下游发送一个Path催泪弹。在这两种情况下，LSR B不得修改DP状态。
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| X X---------| |
| | |
| X | |
| | | |
| Path | Path | |
|--------------->|--------------->| |
| PathErr | PathErr | PathTear |
|<---------------|<---------------|--------------->|
| | | |
Ingress LER LSR A LSR B Egress LER
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| X X---------| |
| | |
| X | |
| | | |
| Path | Path | |
|--------------->|--------------->| |
| PathErr | PathErr | PathTear |
|<---------------|<---------------|--------------->|
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 9: MP2CP - Node Graceful Restart - Case III
Figure 9: MP2CP - Node Graceful Restart - Case III
4.3. CP-to-MP Handover: LSP Ownership Transfer from Control Plane to Management Plane
4.3. CP到MP移交：LSP所有权从控制平面转移到管理平面
Let's now consider the case of LSP ownership transfer from Control Plane to Management Plane. Also in this section, we will analyze the Handover procedure success and failure.
现在让我们考虑LSP所有权从控制平面转移到管理平面的情况。在本节中，我们还将分析移交程序的成功与失败。
The scenario is still a DP connection between two nodes acting as ingress and egress for a LSP, but in this case, the CP has the ownership and control of the LSP. The CP-to-MP Handover procedure MUST delete the existing RSVP-TE session information and MUST NOT affect the cross-connected resources, but just move their ownership to the MP.
该场景仍然是两个节点之间的DP连接，充当LSP的入口和出口，但在这种情况下，CP拥有LSP的所有权和控制权。CP到MP的切换过程必须删除现有的RSVP-TE会话信息，并且不得影响交叉连接的资源，而只是将其所有权转移到MP。
In other words, after LSP ownership transfer from CP to MP, the LSP is no longer under the control of RSVP-TE, which is no more able to "see" the LSP itself. The CP-to-MP Handover procedure MUST be a standard LSP deletion procedure as described in Section 7.2.1 of [RFC3473]. The procedure is initiated at the ingress node of the LSP by an MP entity. The ingress node and MP exchange the relevant information for this task and then propagate it over CP by means of RSVP-TE tear down signaling as described below.
换句话说，LSP所有权从CP转移到MP后，LSP不再受RSVP-TE的控制，RSVP-TE无法“看到”LSP本身。CP到MP的移交程序必须是[RFC3473]第7.2.1节所述的标准LSP删除程序。该过程由MP实体在LSP的入口节点启动。入口节点和MP交换该任务的相关信息，然后通过如下所述的RSVP-TE分解信令在CP上传播该信息。
The ingress node MUST send a Path message in the downstream direction with Handover and Reflect bits set in the ADMIN_STATUS Object. No action is taken over the DP and transit LSRs must forward such message towards the egress node. All of the nodes MUST keep track of the procedure storing the H bit in their local Path and Resv states. Then, every node waits for the H bit to be received within the related Resv message. After the Resv message is received by the ingress LER, it MUST send a PathTear message in order to clear the
入口节点必须在下游方向发送带有切换的Path消息，并反映ADMIN_STATUS对象中设置的位。未对DP采取任何行动，中转LSR必须将此类消息转发至出口节点。所有节点都必须跟踪在其本地路径和Resv状态中存储H位的过程。然后，每个节点等待在相关Resv消息内接收H位。入口LER接收到Resv消息后，它必须发送一条PathTear消息以清除
whole LSP information recorded on the RSVP-TE data structures of the nodes. Downstream nodes processing a PathTear message that follows a Path message with the H bit set, MUST NOT remove any associated Data Plane state. In other words, a normal LSP tear down signaling is exchanged between nodes traversed by the LSP, but the H bit set in the Path message indicates that no DP action has to correspond to CP signaling.
记录在节点RSVP-TE数据结构上的整个LSP信息。在设置了H位的Path消息之后处理PathTear消息的下游节点不得删除任何关联的数据平面状态。换句话说，在LSP穿越的节点之间交换正常的LSP分解信令，但是路径消息中设置的H位指示没有DP动作必须对应于CP信令。
Failures during CP-to-MP Handover procedure MUST NOT result in the removal of any associated Data Plane state. To that end, when a Resv message containing an ADMIN_STATUS Object with the H bit not received during the period of time described in Section 7.2.2. of [RFC3473] different processing is required. While the H bit is set in the Path state, a node MUST NOT send a PathTear when a failure is detected. Instead, the failure is reported upstream using a PathErr. The only node that can send a PathTear is the ingress node, and it can only do this as a step in the procedures specified in this document. This applies to both MP-to-CP and CP-to-MP Handover. The ingress node MAY choose to report the failure in the CP-to-MP Handover procedure via the MP.
CP至MP移交过程中的故障不得导致删除任何相关数据平面状态。为此，当在第7.2.2节所述的时间段内未接收到包含具有H位的ADMIN_状态对象的Resv消息时。对于[RFC3473]，需要进行不同的处理。当H位设置为Path状态时，当检测到故障时，节点不得发送PATHTRAR。相反，使用PathErr向上游报告故障。唯一可以发送Path撕裂的节点是入口节点，它只能作为本文档中指定的过程中的一个步骤来执行此操作。这适用于MP到CP和CP到MP的切换。入口节点可以选择通过MP在CP到MP切换过程中报告故障。
The CP-to-MP Handover procedure can also fail due to two causes: PathTear lost or node down. In the former case, if the LSP is not under MP control after the Expiration timer elapses, a manual intervention from the network operator is requested, while in the latter case, different scenarios may happen:
CP到MP的切换过程也可能由于两个原因而失败：路径撕裂丢失或节点关闭。在前一种情况下，如果LSP在过期计时器过期后不在MP控制下，则请求网络运营商进行手动干预，而在后一种情况下，可能会发生不同的情况：
- CASE I - Path message and node down
- 案例一-路径消息和节点关闭
| Path | Path X |
|--------------->|--------------X |
| | |
| | X |
| | | |
| | | |
Ingress LER LSR A LSR B Egress LER
| Path | Path X |
|--------------->|--------------X |
| | |
| | X |
| | | |
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 10: Case I - Path Message and Node Down
图10：案例I-路径消息和节点关闭
Per [RFC3473], Section 7.2.2, the ingress node should wait for a configurable amount of time (30 seconds by default) and then send a PathTear message. In this case, the normal deletion procedure MUST
根据[RFC3473]第7.2.2节，入口节点应等待可配置的时间量（默认为30秒），然后发送Path催泪消息。在这种情况下，必须执行正常的删除过程
NOT be followed. When the Expiration timer elapses, a manual intervention from network operator is requested and normal, i.e., pre-CP-to-MP Handover, LSP processing continues.
不要被跟踪。当过期计时器过期时，请求网络运营商进行手动干预，并正常进行，即CP到MP切换前，LSP处理继续进行。
- CASE II - Resv message and node down
- 案例二-Resv消息和节点关闭
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| X X---------| |
| | |
| X | |
| | | |
Ingress LER LSR A LSR B Egress LER
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| X X---------| |
| | |
| X | |
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 11: Case II - Resv Message and Node Down
图11：案例II-Resv消息和节点关闭
The procedure to be followed is the same depicted in CASE I. The network operator can ask for the automatic CP-to-MP procedure again after the failed node comes back up. Per [RFC3473], section 7.2, the nodes will forward the new Path and Resv messages correctly.
要遵循的程序与案例I中描述的程序相同。网络运营商可以在故障节点恢复后再次请求自动CP-to-MP程序。根据[RFC3473]第7.2节，节点将正确转发新路径和Resv消息。
- CASE III - PathTear message and node down
- 案例三-路径撕裂消息和节点关闭
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| Resv | Resv | Resv |
|<---------------|<---------------|<---------------|
| PathTear | | |
|--------------->| PathTear X |
| |------------X |
| | X |
| | | |
Ingress LER LSR A LSR B Egress LER
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| Resv | Resv | Resv |
|<---------------|<---------------|<---------------|
| PathTear | | |
|--------------->| PathTear X |
| |------------X |
| | X |
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 12: Case III - PathTear Message and Node Down
图12：案例III-Path撕裂消息和节点关闭
This scenario can be managed as a normal PathTear lost described above in this section.
此场景可以作为本节上文所述的正常路径进行管理。
As described in Section 4, it is also possible for the ERO to contain less than the full set of path information for the LSP being handed over. This arises when only a minimal set of information is handed
如第4节所述，ERO也可能包含少于正在移交的LSP的完整路径信息集。当只传递一组最小的信息时，就会出现这种情况
to the CP by the MP at the LSP's head-end. Instead of collecting all of the LSP information (including the labels) and formatting it into an ERO, as described in Section 4, it is possible to start with a minimum amount of information. The full ERO method and the partial/no ERO method are not mutually exclusive; support of both methods is required.
由LSP前端的MP发送至CP。与收集所有LSP信息（包括标签）并将其格式化为ERO（如第4节所述）不同，可以从最少的信息量开始。完全ERO方法和部分/无ERO方法并不相互排斥；这两种方法都需要支持。
At the ingress node, the information needed to specify the LSP is the outgoing interface ID, upstream label, and downstream label of this interface and egress node ID. The remaining information about an existing LSP can then be collected hop by hop, as the signaling is going on, by looking up the cross-connection table in the DP at each node along the LSP path.
在入口节点，指定LSP所需的信息是该接口的输出接口ID、上游标签和下游标签以及出口节点ID。然后，随着信令的进行，可以逐跳收集关于现有LSP的剩余信息，通过在沿着LSP路径的每个节点的DP中查找交叉连接表。
Starting from the information available at the ingress LER about the outgoing interface ID of that ingress node, the incoming interface ID of the next hop can be found by looking up the link resource table/ database in the LER itself.
从入口LER处关于该入口节点的传出接口ID的可用信息开始，可以通过查找LER自身中的链路资源表/数据库来找到下一跳的传入接口ID。
The Path message is hence built with the LABEL_SET Object ([RFC3473]) and the UPSTREAM_LABEL Object ([RFC3473]), where the upstream label and downstream label of ingress outgoing interface of the LSP are included in these two objects. In addition to the above mentioned objects, the Path message MUST include the ADMIN_STATUS Object with the H bit set, as already defined in previous chapters for the detailed ERO-based way of proceeding. Such a Handover Path is sent to the incoming interface of the next hop. When this Path message reaches the second node along the LSP, the information about incoming interface ID and the upstream and downstream labels of this interface is extracted from it, and it is used to find next hop outgoing interface ID and the upstream/downstream labels by looking up the DP cross-connection table.
因此，使用LABEL_SET对象（[RFC3473]）和上游_LABEL对象（[RFC3473]）构建路径消息，其中LSP的入口-输出接口的上游标签和下游标签包括在这两个对象中。除上述对象外，路径消息还必须包括设置了H位的ADMIN_STATUS对象，如前几章中针对基于ERO的详细处理方式所定义的。这样的切换路径被发送到下一跳的传入接口。当该路径消息沿着LSP到达第二个节点时，将从中提取有关传入接口ID和该接口的上下游标签的信息，并通过查找DP交叉连接表来查找下一跳传出接口ID和上下游标签。
After having determined, in this way, the parameters describing the LSPs next hop, the outgoing Path message to be sent is built replacing the LABEL_SET Object and UPSTREAM_LABEL Object content with the looked-up values of upstream and downstream labels.
在以这种方式确定了描述lsp下一跳的参数之后，构建要发送的传出路径消息，用上游和下游标签的查找值替换标签设置对象和上游标签对象内容。
By repeating this procedure for each transit node along the LSP, it is possible to make the Handover Path message reach the egress node, exactly following the LSP that is in place over DP. The ERO MAY, in this case, be included in the Path message as an optional object, and MAY be filled with the LSP-relevant information down to either the port level with the interface ID or the label level with upstream and downstream labels. The ERO can be used to check the consistency of resource in the DP down to the port level or label level at each intermediate node along the LSP.
通过对LSP上的每个中转节点重复该过程，可以使切换路径消息到达出口节点，正好跟随在DP上的LSP。在这种情况下，ERO可以作为可选对象被包括在路径消息中，并且可以用LSP相关信息填充，直至具有接口ID的端口级或具有上游和下游标签的标签级。ERO可用于检查DP中资源的一致性，直至LSP上每个中间节点的端口级别或标签级别。
Where the DP path continues beyond the egress, by indicating the Egress label at the head-end of an LSP, the traffic can be directed to the right destination. The GMPLS signaling procedure for egress control is described in [RFC4003]
在DP路径继续超出出口的情况下，通过在LSP的前端指示出口标签，可以将业务定向到正确的目的地。[RFC4003]中描述了出口控制的GMPLS信号程序
This memo does not introduce any modification in RSVP messages object composition.
本备忘录未对RSVP消息对象组合进行任何修改。
The modifications required concern two RSVP objects: the ADMIN_STATUS and ERROR_SPEC Objects.
所需的修改涉及两个RSVP对象：ADMIN_STATUS和ERROR_SPEC对象。
This memo introduces a new flag into the ADMIN_STATUS Object. The ADMIN_STATUS Object is defined in [RFC3473]. This document uses the H bit of the ADMIN_STATUS Object. The bit is bit number 25.
此备忘录在ADMIN_STATUS对象中引入了一个新标志。管理员状态对象在[RFC3473]中定义。此文档使用ADMIN_状态对象的H位。该位是位号25。
It is possible that a failure, such as the loss of the Data Communication Network (DCN) connection or the restart of a node, occurs during the LSP ownership handing over. In this case, the LSP Handover procedure is interrupted, the ownership of the LSP must remain with the ownership prior to the initiation of the Handover procedure. It is important that the transaction failure not affect the DP. The LSP is kept in place and no traffic hit occurs.
LSP所有权移交期间可能发生故障，例如数据通信网络（DCN）连接丢失或节点重新启动。在这种情况下，LSP移交过程被中断，LSP的所有权必须在移交过程开始之前保留在该所有权上。重要的是，事务失败不会影响DP。LSP保持在原位，不会发生交通堵塞。
The failure is signaled by a PathErr message in the upstream direction and PathTear messages in the downstream direction. The PathErr messages include an ERROR_SPEC Object specifying the causes of the failure.
故障由上游方向的PathErr消息和下游方向的PathTear消息发出信号。PathErr消息包含一个错误规范对象，指定失败的原因。
This memo introduces a new Error Code (with different Error Values) into the ERROR_SPEC Object, defined in [RFC2205].
此备忘录在[RFC2205]中定义的Error_SPEC对象中引入了一个新的错误代码（具有不同的错误值）。
The defined Error Code is "Handover Procedure Failure", and its value is 35. For this Error Code, the following Error Value sub-codes are defined:
定义的错误代码为“移交程序失败”，其值为35。对于此错误代码，定义了以下错误值子代码：
1 = Cross-connection mismatch
1 = Cross-connection mismatch
2 = Other failure
2 = Other failure
The main requirement for the Handover procedure to work is that all nodes along the path MUST support the extension defined in this document. This requirement translates to an administrative requirement as it is not enforced at the protocol level. As defined, non-supporting nodes will simply propagate the H bit without setting local state. This may result in an impact on data traffic during the Handover procedure.
移交程序工作的主要要求是，路径上的所有节点必须支持本文件中定义的扩展。此要求转化为管理要求，因为它不是在协议级别强制执行的。根据定义，非支持节点将只传播H位，而不设置本地状态。这可能会对切换过程中的数据流量造成影响。
The procedures described in this document rely completely on RSVP-TE messages and mechanism. The use of the H bit being set in the ADMIN_STATUS Object basically informs the receiving entity that no operations are to be done over the DP as a consequence of such special signaling flow. Using specially flagged signaling messages, we want to limit the function of setup and teardown messages to the CP, making them ineffective over related DP resource usage.
本文档中描述的过程完全依赖于RSVP-TE消息和机制。在ADMIN_STATUS对象中设置的H位的使用基本上通知接收实体，由于这种特殊的信令流，不需要在DP上执行任何操作。使用特别标记的信令消息，我们希望将设置和拆卸消息的功能限制在CP上，使它们在相关DP资源使用上无效。
However, the Handover procedures allow the Control Plane to be used to take an LSP out of the control of the Management Plane. This could cause considerable disruption and could introduce a new security concern. As a consequence, the use of GMPLS security techniques is more important. For RSVP-TE security, please refer to [RFC3473], for the GMPLS security framework, please refer to [sec-fwk].
然而，移交程序允许使用控制平面将LSP从管理平面的控制中移除。这可能会造成相当大的干扰，并可能带来新的安全问题。因此，GMPLS安全技术的使用更为重要。关于RSVP-TE安全，请参考[RFC3473]，关于GMPLS安全框架，请参考[sec fwk]。
IANA manages the bit allocations for the ADMIN_STATUS Object ([RFC3473]). This document requires the allocation of the Handover bit: the H bit. IANA has allocated a bit for this purpose.
IANA管理ADMIN_状态对象（[RFC3473]）的位分配。本文件要求分配移交位：H位。IANA为此目的分配了一个bit。
Bit Number Hex Value Name Reference
---------- ----------- --------------------------------- ---------
25 0x00000040 Handover (H) [RFC5852]
Bit Number Hex Value Name Reference
---------- ----------- --------------------------------- ---------
25 0x00000040 Handover (H) [RFC5852]
IANA has also allocated a new Error Code:
IANA还分配了一个新的错误代码：
35 Handover failure
35切换失败
This Error Code has the following globally defined Error Value sub-codes:
此错误代码具有以下全局定义的错误值子代码：
1 = Cross-connection mismatch 2 = Other failure
1=交叉连接不匹配2=其他故障
We wish to thank Adrian Farrel, Lou Berger, Alan Elder, and Ben Campbell for their assistance and precious advice to prepare this document for publication. We also wish to thank Nicola Ciulli (Nextworks) who contributed to the initial stage of this document.
我们要感谢Adrian Farrel、Lou Berger、Alan Elder和Ben Campbell在准备本文件出版时提供的帮助和宝贵建议。我们还要感谢Nicola Ciulli（Nextworks），她为本文件的初始阶段做出了贡献。
Shan Zhu Fujitsu Network Communications Inc. 2801 Telecom Parkway, Richardson, TX 75082 USA EMail: Shan.Zhu@us.fujitsu.com Tel: +1-972-479-2041
山竹富士通网络通信有限公司，地址：美国德克萨斯州理查森市电信大道2801号，邮编75082。电子邮件：山竹。Zhu@us.fujitsu.com电话：+1-972-479-2041
Igor Bryskin ADVA Optical Networking Inc 7926 Jones Branch Drive, Suite 615 McLean, VA 22102 USA EMail: ibryskin@advaoptical.com
Igor Bryskin ADVA光纤网络公司美国弗吉尼亚州麦克莱恩615室琼斯分支大道7926号邮编：22102电子邮件：ibryskin@advaoptical.com
Francesco Fondelli Ericsson Via Negrone 1A Genova - 16145 Italy EMail: francesco.fondelli@ericsson.com
弗朗西斯科·丰德利·爱立信通过内格罗内1A Genova-16145意大利电子邮件：弗朗西斯科。fondelli@ericsson.com
Lou Berger LabN Consulting, LLC Phone: +1 301 468 9228 EMail: lberger@labn.net
Lou Berger LabN Consulting，LLC电话：+1 301 468 9228电子邮件：lberger@labn.net
[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, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[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月。
[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月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", RFC 4003, February 2005.
[RFC4003]Berger，L.，“出口控制的GMPLS信号程序”，RFC 4003，2005年2月。
[RFC5493] Caviglia, D., Bramanti, D., Li, D., and D. McDysan, "Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network", RFC 5493, April 2009.
[RFC5493]Caviglia，D.，Bramanti，D.，Li，D.，和D.McDysan，“通用多协议标签交换（GMPLS）网络中永久连接和交换连接之间转换的要求”，RFC 5493，2009年4月。
[sec-fwk] Fang, L. and M. Behringer, "Security Framework for MPLS and GMPLS Networks", Work in Progress, March 2010.
[sec fwk]Fang，L.和M.Behringer，“MPLS和GMPLS网络的安全框架”，正在进行的工作，2010年3月。
Authors' Addresses
作者地址
Diego Caviglia Ericsson Via A. Negrone 1A Genova - Sestri Ponente 16153 Italy
Diego Caviglia Ericsson途经A.Negrone 1A Genova-Sestri Ponente 16153意大利
EMail: diego.caviglia@ericsson.com
EMail: diego.caviglia@ericsson.com
Daniele Ceccarelli Ericsson Via A. Negrone 1A Genova - Sestri Ponente 16153 Italy
Daniele Ceccarelli Ericsson途经A.Negrone 1A Genova-Sestri Ponente 16153意大利
EMail: daniele.ceccarelli@ericsson.com
EMail: daniele.ceccarelli@ericsson.com
Dino Bramanti Ericsson
迪诺·布拉曼蒂·爱立信
Dan Li Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 P.R. China
中国深圳华为基地华为技术F3-5-B研发中心，邮编：518129
EMail: danli@huawei.com
EMail: danli@huawei.com
Snigdho Bardalai Fujitsu Network 2801 Telecom Parkway Richardson, TX 75082 USA
美国德克萨斯州理查森电信大道2801号斯尼格多·巴达莱富士通网络公司，邮编75082
EMail: sbardalai@gmail.com
EMail: sbardalai@gmail.com