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.
または管理システム（固定接続 - PC）独立して共存していてもよい - トランスポートネットワークのシナリオでは、データプレーンの接続は、いずれかの汎用マルチプロトコルラベルスイッチング（GMPLS）制御プレーン（SPCソフト固定接続）によって制御されます。実際にその上に実施されているデータプレーンのトラフィックに影響を与えずに - - SPCおよびその逆に、既存のPCを変換する能力が必要条件です。永久的な接続とGMPLSネットワークにおける交換接続との間の変換のための要件は、RFC 5493で定義されています。
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.
管理プレーンとコントロールプレーンとの間の接続の所有権の移転を可能にトラフィックエンジニアリング（RSVP-TE）シグナリング - このメモはGMPLSリソース予約プロトコルの拡張機能について説明します。そのような転送はハンドオーバと呼ばれます。この文書では、すべてのハンドオーバ関連の手続きを定義しています。これは、障害状態と元の状態に復帰以降の処理を含みます。拡張の基本的な前提は、ハンドオーバ手順は、すでに確立されているデータプレーンの接続に影響を与えることはありませんしなければならないということです。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
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.
典型的な伝統的なトランスポート・ネットワークのシナリオでは、2つのエンドポイント間のデータプレーン（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によって制御は - の制御されたハンドオーバを調整することができる手順の必要性を紹介しますCPへのMPからのデータプレーン接続。
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ディノの早い年齢で亡くなった私たちの友人や同僚ディーノBramanti、この作品を捧げたいです。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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 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].
この研究の背後にある主な動機は、[RFC5493]で定義された要件を満たす単純かつ非常に低衝撃手順の定義です。このような手順は、トランスポートネットワーク事業者はそれらに流れるユーザトラフィックを中断することなくCPにMPからNMSでプロビジョニングされた既存のLSPの所有権を引き渡す機会を与えることを目指しています。 CPへのMPからのハンドオーバ（すなわち、DP接続の所有権を、既存の制御がCPにMPから渡されたとき）逆の操作、CP-TO-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ハンドオーバ」と「Hビット」と呼ばれる新たに定義されたビットの使用に基づく「CP-に-MPハンドオーバ」手順の詳細な説明を与えます。
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）で符号化され、LSPが経路に沿ってノードを検査することによって、プロビジョニング、またはMPによって収集されたときに記録された詳細を使用して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は、Pathメッセージを処理するように次のホップの詳細は、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のために、送信Pathメッセージに使用UPSTREAM_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へMPから移動するLSPの経路に沿ったRSVP-TEセッションを作成する必要がありますスロット、又は予約帯域）と同時に、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.
オペレータは、CPのMPからのLSPの制御を引き渡すために入口ノードに指示します。このハンドオーバモードでは、任意のリソース予約とラベル情報を含む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.
入口はHビットでPathメッセージを使用してLSPを信号およびRはADMIN_STATUSオブジェクトに設定ビット。ハンドオーバのこのモードでは、Pathメッセージは、各ホップでLSPによって使用されるラベルを示すラベルサブオブジェクトを含むEROを運びます。進入は（このタイマーの満了については、セクション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.
HビットセットをチェックしてPathメッセージを受信する各ラベルスイッチングルータ（LSR）は、任意のマッチング路状態が存在するかどうかを確認します。
o If matching Path state is found with the H bit set, this is a Path refresh and should be treated accordingly [RFC3473].
マッチングパスの状態をHビットセットで見つかった場合、O、これは、パスの更新であり、したがって、[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.
マッチングパスの状態をHビットクリアで見つかった場合、O、これはエラーであり、セクション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は、（セットHビットを含む）は、パス状態を保存する必要があり、それが出口にPathメッセージを転送しなければなりません。 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は、Pathメッセージを転送するには、No下流ノードが存在しないことを除いて、他の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ビットが明確でなければならないことを除いて、前のメッセージと変わらないPathメッセージを送らなければなりません。
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ビットとPathメッセージクリアLSPの長さを移動すると、通常の処理[RFC3473]に記載のクリアHビットとのResvのリターンをもたらすであろう。その結果、Hビットは、各中継LSRに格納されたパスの状態および出口LSR時にクリアされます。各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ハンドオーバの場合では、2つの異なる障害シナリオが発生する可能性があります：パス障害との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 | | |
|--------------->| 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処理に従ってパス状態のタイムアウトを待つことができます。
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は、MPへのLSPの所有権を元に戻す必要があります。
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
Figure 2: MP2CP - Path Msg and Communication Failure
(Reliable Delivery)
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 Bに向けてLSR Aから送信されたPathメッセージが失われたか、何らかの理由で宛先に到達しません。信頼性のある配信メカニズムが実装されているように、LSR Aは時間の構成可能な数のパスメッセージを再送信、およびNO ACKが受信されない場合、ハンドオーバ手順は、（有効期限タイマーによって）中断されます。
In the next scenario RSVP-TE messages are sent without reliable message delivery, that is, no [RFC2961] MessageID procedure is used.
次のシナリオではRSVP-TEメッセージは、すなわち、NO [RFC2961]メッセージID手順が使用されない、信頼性の高いメッセージ配信せずに送信されます。
| 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)
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で説明したように、ハンドオーバ手順が中止されます。その状態が除去されたときPathTearを送信する、すなわちパス（LSR A）を、転送した任意のノードは、ローカルパスの状態がインストールされていることに注意してください（によると、[RFC2205]）。
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 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.
Resvメッセージの処理中に障害が発生した場合には（場合におけるシグナリングの間にデータプレーン内の任意の変化があった）、ノードは、上流方向のPathErrメッセージ[RFC2205]を送信しなければなりません。セクション4.2.1.1に上記で定義した通りのPathErrメッセージが構築されて処理されます。故障検出ノードは、下流PathTearメッセージを送らなければなりません。 PathTearメッセージを構築し、セクション4.2.1.1に上記で定義したように処理されます。
| 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. A PathTearメッセージはBとのPathErrメッセージに向かって送られるで起こる（ErrorCodeが「ハンドオーバ手順の失敗」に設定して）アップストリーム方向に送信されます。 PathErrとPathTearメッセージは、LSPのノードに沿ってPathメッセージによって確立されたパスの状態を削除し、ハンドオーバ手順を中止します。
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ビットクリアとPathメッセージはまだ送信または受信していないだろう、とハンドオーバ状態がまだローカルに保持された後、障害が発生したことに注意してください。それはHビットセットとパス状態を有するときPathTearを受信したノードは、パス状態を削除する必要がありますが、データプレーンの状態を変更しないでください。これは、MPへのLSPの所有権を返さなければなりません。
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メッセージについて見られるものに非常に類似しています。この場合であっても、2つの異なるシナリオを区別することが可能です。
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).
最初のシナリオでは、[RFC2961]で定義されたメカニズムに基づいた信頼性の高いメッセージ配信の活用を検討してください。 LSPのノードに沿ってPathメッセージの正しい転送後、出口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
Figure 5: MP2CP - Resv Error and Communication Failure
(Reliable Delivery)
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があまりにも失敗する可能性が高いです。この事実により、有効期限タイマーは、それを転送した後、パスを送った後とLSR Aに進入LERに使用されています。タイマーが満了したときに何の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
Figure 6: MP2CP - Resv Error and Communication Failure
(No Reliable Delivery)
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
ケースI - 有限再起動時間
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]を参照）、値0xFFFFFFFF有限すなわち、ではありません。以下のシーケンス図では、LSR Aが再起動を想定します。イングレスLERが時間内にResvメッセージを受信しない場合、下流のPathTearメッセージを生成することによって、ハンドオーバープロセスを中止しなければなりません。 LSR Aが再起動時間間隔内に再起動プロセスを完了しない場合にも、その後LSR BはLSR AとLSR Bとの間のすべてのLSPを切断開始する必要があり、これはにMPリソースのハンドオーバを実行するために使用されているLSPを含みますCP。 LSP Bは、上流下流PathTearメッセージとのPathErrメッセージを生成しなければなりません。両方のノードに、Hビットがローカルパス状態に設定されている、ためLSR Bおよび出口LERの両方がDPリソースを解放してはいけません。
| 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
図7：MP2CP - ノードのグレースフルリスタート - ケースI
Case II - Infinite Restart Time
ケースII - 無限の再起動時間
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]を参照）、送信者のコントロールプレーンの再起動が不定間隔にわたって発生する可能性があることを示し、すなわち、0xFFFFFFFFのです。シーケンスは、前のものと非常によく似ています。それは無限に実行されているので、このシーケンスでは、再起動タイマーはLSR Bに期限切れになりません。代わりに、LSR Aが再起動した後、LSR Bは回復タイマーを起動する必要があります。それはハンドオーバープロセスを中止した後に与えられた入口ノードが既にローカルパスの状態を削除していたLSRから受信RECOVERYのLABELとはPathメッセージは存在しませんので、回復タイマーが期限切れになります。従って、LSR Bは、上流下流PathTearメッセージとのPathErrメッセージを生成することによってCPにMPリソースを変換するために使用されている特定のLSPをティアダウンしなければなりません。 Hビットがローカルパス状態に設定されているため、同様に、前の場合と同様に、LSR B及び出口LERの両方がDPリソースを解放してはいけません。
| 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
図8：MP2CP - ノードのグレースフルリスタート - ケースII
Case III
ケース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がハンドオーバを再開するために設定されたビットがPathメッセージを再生成しなければなりません。
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が再起動したと回復LABELオブジェクトにPathメッセージを送信した可能性があることも認識しています。 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は、再送信として、受信したPathメッセージを扱わなければならない、とのResvを再送しなければなりません。ハンドオーバを中止した場合、LSR BはのPathErrを返さなければならないし、下流PathTearを送らなければなりません。どちらの場合も、LSR Bは、DPの状態を変更してはいけません。
| 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
図9：MP2CP - ノードのグレースフルリスタート - ケース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.
シナリオは依然としてLSPのための入口および出口として作用する2つのノード間のDP接続であるが、この場合、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.
換言すれば、CPからMPへLSP所有権の移転後、LSPはもはやLSP自体を「見る」ことができるRSVP-TEの制御下にはなくなりました。 [RFC3473]のセクション7.2.1に記載したようにCP-に-MPハンドオーバ手順は、標準的な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 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.
入口ノードは、ハンドオーバ下流方向にPathメッセージを送信し、ADMIN_STATUSオブジェクトに設定されたビットを反映しなければなりません。 DPとトランジットのLSRにわたって取られるアクションは出口ノードに向かってそのようなメッセージを転送してはなりません。すべてのノードは、ローカルパスとのResv状態のHビットを格納手順を追跡する必要があります。 Hビットが関連Resvメッセージ内に受容されるように、次いで、すべてのノードが待機します。 Resvメッセージが入口LERによって受信された後、それはノードのRSVP-TEのデータ構造に記録された全LSP情報をクリアするためにPathTearメッセージを送らなければなりません。 Hビットが設定されたPathメッセージを次のPathTearメッセージを処理する下流ノードは、関連するデータ・プレーンの状態を削除してはいけません。換言すれば、通常のLSPは、シグナリングは、LSPによって横断ノード間で交換される取り壊すが、Pathメッセージに設定された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ハンドオーバ手順中の障害は、任意の関連するデータプレーン状態の除去をもたらしてはいけません。そのために、場合Resvメッセージは、セクション7.2.2に記載した時間の期間中に受信していないHビットとADMIN_STATUSオブジェクトを含みます。 [RFC3473]異なる処理が必要です。 Hビットがパス状態に設定されている間、障害が検出された場合、ノードはPathTearを送ってはいけません。代わりに、失敗はのPathErrを使用して上流に報告されます。 PathTearを送ることができる唯一のノードは入力ノードであり、それだけで、この文書で指定された手順のステップとしてこれを行うことができます。これは、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ハンドオーバ手順はまた、2つの原因に失敗することがあります。PathTearはダウン紛失またはノード。 LSPは、有効期限タイマーが経過後にMPの制御下にない場合は、後者の場合には、異なるシナリオが発生する可能性がありながら、前者の場合、ネットワークオペレータからの手動介入が要求されます。
- CASE I - Path message and node down
- CASE I - Pathメッセージとノードダウン
| 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秒）、その後、PathTearメッセージを送信する必要があります。この場合、通常の削除手順のMUST
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-TO-MPハンドオーバ、LSP処理が継続されます。
- CASE II - Resv message and node down
- CASE II - Resvメッセージとノードダウン
| 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.
従うべき手順が失敗したノードが復旧した後に、ネットワークオペレータは、再び自動CP-に-MP手順を求めることができCASE Iに示されたと同じです。パー[RFC3473]、セクション7.2、ノードが正常に新しいパスとRESVメッセージを転送します。
- CASE III - PathTear message and node down
- CASE III - ダウンPathTearメッセージ及びノード
| 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 - PathTearメッセージおよびノード停止
This scenario can be managed as a normal PathTear lost described above in this section.
このシナリオでは、このセクションで前述した失われた通常のPathTearとして管理することができます。
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 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.
セクション4で説明したように、EROがハンドオーバされるLSPのためのパス情報の完全なセットより少ない含有することも可能です。情報の唯一の最小セットは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の経路に沿って各ノードでDPにおけるクロスコネクトテーブルを参照して、起こっているように既存のLSPに関する残りの情報は、ホップバイホップを収集することができます。
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.
その入口ノードの発信インタフェースID約入口LERで入手可能な情報から出発し、次のホップの受信インタフェースIDは、LER自体でリンクリソーステーブル/データベースを検索することによって見出すことができます。
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.
Pathメッセージは、従って、上流ラベルとLSPの入口発信インターフェイスの下流ラベルは、これら二つのオブジェクトに含まれるLABEL_SETオブジェクト（[RFC3473]）とUPSTREAM_LABELオブジェクト（[RFC3473]）で構築されています。上記目的に加えて、Pathメッセージは、既に進行の詳細なEROベースの方法のために前の章で定義されたHビットが設定されたADMIN_STATUSオブジェクトを含まなければなりません。そのようなハンドオーバパスは次のホップの着信インターフェイスに送られます。このPathメッセージは、LSPに沿って第2のノードに到達すると、着信インターフェイスのIDに関する情報と、このインタフェースの上流側と下流ラベルはそれから抽出され、次のホップの発信インターフェイスIDによって上流/下流のラベルを見つけるために使用されていますDPクロスコネクションテーブルを検索します。
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の次のホップを記述するパラメータは、送信すべき送信Pathメッセージは、上流と下流のラベルのルックアップ値とLABEL_SETオブジェクトとUPSTREAM_LABELオブジェクトコンテンツを置き換える構築されます。
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に沿った各トランジットノードに対してこの手順を繰り返すことにより、ハンドオーバPathメッセージが正確にDPを超える場所にあるLSP以下、出口ノードに到達させることができます。 ERO MAYは、この場合には、オプションのオブジェクトとしてPathメッセージに含まれ、インタフェースIDを有するポートレベルまたは上流および下流のラベルをラベルレベルのいずれかまでのLSP関連情報を充填することができます。 EROは、LSPに沿った各中間ノードにおけるポート・レベルまたはラベルレベルまでDPにおけるリソースの整合性をチェックするために使用することができます。
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のヘッドエンドにおける出口ラベルを示すことによって、トラフィックが正しい宛先に向けることができます。出力制御の手順をGMPLSシグナリングは、[RFC4003]に記載されています
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.
修正に必要な関心事2つの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オブジェクトに新しいフラグを紹介します。 ADMIN_STATUSオブジェクトは[RFC3473]で定義されています。この文書では、ADMIN_STATUSオブジェクトの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.
このようなデータ通信ネットワーク（DCN）接続の損失またはノードの再起動などの障害が、LSPの所有取り扱い上の間に起こる可能性があります。この場合、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.
故障は、下流方向上流方向とPathTearメッセージ内のPathErrメッセージによってシグナリングされます。たPathErrメッセージは、失敗の原因を指定するERROR_SPECオブジェクトが含まれます。
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 =クロス接続の不一致
2 = Other failure
2 =その他の障害
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のメッセージとメカニズムに完全に依存しています。 HビットがADMIN_STATUSオブジェクトに設定された使用は、基本的には操作がそのような特別なシグナリングフローの結果としてDPを介して行われるべきではない受信エンティティに通知します。特別にシグナリング・メッセージにフラグを使用して、我々は、関連するDPのリソース使用量を超えるそれらを無効作り、CPにセットアップとティアダウンメッセージの機能を制限したいです。
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のセキュリティを確保するため、GMPLSのセキュリティフレームワークのために、[秒-fwk]を参照してください、[RFC3473]を参照してください。
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_STATUSオブジェクト（[RFC3473]）のためのビット割り当てを管理します。 Hビット：この文書では、ハンドオーバビットの割り当てが必要です。 IANAは、この目的のためにビットを割り当てています。
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
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.
私たちは、彼らの支援と公表のため、この文書を準備するための貴重なアドバイスをエードリアンファレル、ルー・バーガー、アラン・エルダー、ベン・キャンベルに感謝したいです。また、このドキュメントの初期段階に貢献したニコラ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テレコムパークウェイ、リチャードソン、TX 75082 USA電子メール：Shan.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
イゴールBryskin ADVA社株式会社7926・ジョーンズ支店ドライブ、スイート615マクリーン、VA 22102 USA電子メール：ibryskin@advaoptical.com
Francesco Fondelli Ericsson Via Negrone 1A Genova - 16145 Italy EMail: francesco.fondelli@ericsson.com
フランチェスコFondelliエリクソンNegrone 1Aジェノヴァ経由 - イタリア16145電子メール：francesco.fondelli@ericsson.com
Lou Berger LabN Consulting, LLC Phone: +1 301 468 9228 EMail: lberger@labn.net
ルー・バーガーLabNコンサルティング、LLC電話：+1 301 468 9228 Eメール：lberger@labn.net
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年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]バーガー、L.、ガン、D.、ツバメ、G.、パン、P.、Tommasi、F.、及びS. Molendini、 "RSVPリフレッシュオーバーヘッド削減拡張"、RFC 2961、2001年4月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、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]バーガー、L.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]マニー、E.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ"、RFC 3945、2004年10月。
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", RFC 4003, February 2005.
"出力制御のためのGMPLSシグナリング手順" [RFC4003]バーガー、L.、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.、李、D.、およびD. McDysan、 "（GMPLS）ネットワークスイッチング汎用マルチプロトコルラベルで固定接続とスイッチ接続の間の変換のための要件"、RFC 5493、4月2009。
[sec-fwk] Fang, L. and M. Behringer, "Security Framework for MPLS and GMPLS Networks", Work in Progress, March 2010.
[秒-fwk]牙、L.およびM.ベリンガー、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク" が進歩、2010年3月での作業。
Authors' Addresses
著者のアドレス
Diego Caviglia Ericsson Via A. Negrone 1A Genova - Sestri Ponente 16153 Italy
ディエゴ・CavigliaエリクソンのVia A. Negrone 1Aジェノヴァ - セストリポネンテイタリア16153
EMail: diego.caviglia@ericsson.com
メールアドレス：diego.caviglia@ericsson.com
Daniele Ceccarelli Ericsson Via A. Negrone 1A Genova - Sestri Ponente 16153 Italy
ダニエルCeccarelliエリクソンA. Negrone 1Aジェノヴァ - セストリポネンテイタリア16153
EMail: daniele.ceccarelli@ericsson.com
メールアドレス：daniele.ceccarelli@ericsson.com
Dino Bramanti Ericsson
ディノBramantiエリクソン
Dan Li Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 P.R. China
ダンL IH UA技術F3-5-BR＆Dセンターとして、HU Aは518129 P.R.中国塩基についても同様です
EMail: danli@huawei.com
メールアドレス：danli@huawei.com
Snigdho Bardalai Fujitsu Network 2801 Telecom Parkway Richardson, TX 75082 USA
Snigdho Bardalai富士通ネットワーク2801テレコムパークウェイ・リチャードソン、TX 75082 USA
EMail: sbardalai@gmail.com
メールアドレス：sbardalai@gmail.com