[要約] 要約： RFC 5852は、GMPLS対応のトランスポートネットワークにおいて、LSPのハンドオーバーを管理面から制御面に行うためのRSVP-TEシグナリング拡張について説明しています。目的： このRFCの目的は、管理面から制御面へのLSPハンドオーバーを実現するためのRSVP-TEシグナリングの拡張方法を提案し、GMPLSネットワークの効率と信頼性を向上させることです。
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に変換する能力、およびその逆の能力は、実際にデータプレーンのトラフィックに影響を与えることなく、それを引き継がれていますが、要件です。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.
このメモは、管理プレーンとコントロールプレーン間の接続所有権の転送を可能にする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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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によって制御されているネットワーク）の採用は、制御されたハンドオーバーを調整できる手順の必要性を導入します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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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]で定義されている要件を満たす単純で非常に低いインパクトのある手順の定義です。このような手順は、トランスポートネットワークオペレーターに、NMSがMPからCPにプロビジョニングした既存のLSPの所有権を引き渡す機会を提供することを目的としています。MPからCPへのハンドオーバー（つまり、既存のDP接続の所有権と制御がMPからCPへと渡される場合）は必須要件として定義されていますが、反対の操作である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".
次の段落では、「H BIT」と呼ばれる新たに定義されたビットの使用に基づいて、「MPからCPへのハンドオーバー」および「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には、次のホップの詳細がパスメッセージを処理するときにLSPに沿って各ノードによって決定する必要があるように、より少ない情報が含まれる場合があります。このアプローチは、MPからHandoverを開始する際にMPが完全な情報を利用できない場合、またはHeadEndノードに渡すことができない場合に望ましい場合があります。
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の場合、発信パスメッセージで使用されるupstream_labelオブジェクトを作成することを意味します。
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が所有する既存のクロス接続リソースに関連付けている必要があります（例：Lambdas、Time Timeスロット、または予約帯域幅）と同時に、所有権を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.
オペレーターは、Ingressノードに、MPからCPへの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.
ingressは、admin_statusオブジェクトにHビットとrビットが設定されたパスメッセージを使用してLSPを信号します。このハンドオーバーモードでは、パスメッセージには、各ホップで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.
各ラベルスイッチングルーター（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はパス状態（セット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.
Ingress 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の長さを移動し、通常の処理[RFC3473]に従ってHビットクリアでRESVが戻ってきます。その結果、各トランジットLSRおよび出力LSRの保存された経路状態でHビットがクリアされます。各LSRは、LSPに関連する関連するMP状態をHit Quelyでパスメッセージを受信したときにリリースする必要がありますが、将来の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.
Ingressが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の障害または通信障害の2つの異なる原因によるものです。いずれにせよ、LSPの所有権は、ハンドオーバー手順の前のものに直ちに戻ってくる必要があります。各組み合わせのセクションは、以下で分析されます。
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
Figure 1: MP2CP - Path Msg and DP Failure
図1：MP2CP-パスMSGおよび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メッセージで受信パスメッセージに応答する必要があり、ハンドオーバー手順を中止する必要があります。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状態がハンドオーバーが進行中であることを示している場合（パスメッセージのHビットに基づいて）、LSRはLSPの所有権をMPに戻す必要があります。
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)
図2：MP2CP-パスMSGと通信障害（信頼できる配達）
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は構成可能な回数のパスメッセージを再送信し、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]メッセージは使用されません。
| 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-パスMSGと通信障害（信頼できる配達なし）
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）、つまりローカルパス状態をインストールしたノードは、その状態が削除されたときにPATHTEARを送信することに注意してください（[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]を送信する必要があります。Patherrメッセージは、セクション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
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で発生します。パステアメッセージがBに送信され、PatherRメッセージ（エラーコードが「ハンドオーバー手順障害」に設定されています）が上流方向に送信されます。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ビット設定を備えたパス状態があるときにパストイアを受信するノードは、パス状態を削除する必要がありますが、データプレーンの状態を変更してはなりません。LSPの所有権をMPに返す必要があります。
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メッセージが上流のノードの1つ以上に到達できない場合、プロシージャはパスメッセージについて以前に見たものと非常に似ています。この場合でも、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のノードに沿ったパスメッセージの正しい転送の後、出力LSRはRESVメッセージを反対方向に送信します。RESVメッセージがIngressラベルエッジルーター（LER）またはLSRに到達しないことが起こる可能性があります。LSRA。LSRBは、構成可能な回数の回数を再度送信する必要があり、その後、配信が成功しない場合は、配信が成功しない場合、採用手順は（有効期限タイマーを介して）中止されます。
| 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
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.
ノードの再起動と優雅な再起動が有効になっている場合、次のシナリオの1つが発生します。
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が再起動すると仮定します。Ingress 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
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を参照]を参照）は、送信者のコントロールプレーンの再起動が不確定な間隔で発生する可能性があることを示しています。シーケンスは前のものと非常に似ています。このシーケンスでは、RESTARTタイマーは無限に実行されるため、LSR Bでは期限切れになりません。代わりに、LSR A Aが再起動した後、LSR Bは回復タイマーを開始する必要があります。リカバリタイマーは、LSRから受け取った回復ラベルが登場した場合、Ingressノードがハンドオーバープロセスを中止した後にローカルパス状態を既に削除していたため、パスメッセージがないため、期限切れになります。したがって、LSR Bは、下流のメッセージとPathersメッセージを上流にPathTearメッセージを生成することにより、MPリソースをCPに変換するために使用されている特定の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
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.
この場合、Ingress Lerはハンドオーバープロセスを中止しません。LSR Aが再起動すると、イングレスは再起動を検出し、ハンドオーバーを再開するために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がパスメッセージを受信すると、メッセージにHビットが設定されているのが表示され、HITが独自の状態に設定されており、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を返し、下流の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
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セッション情報を削除する必要があり、相互接続されたリソースに影響を与えないでください。
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はRSVP-TEの制御下にありなくなり、LSP自体を「見る」ことができません。CPからMPのハンドオーバー手順は、[RFC3473]のセクション7.2.1で説明されているように、標準のLSP削除手順でなければなりません。この手順は、MPエンティティによってLSPのイングレスノードで開始されます。Ingressノードと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.
Ingressノードは、ハンドオーバーで下流の方向にパスメッセージを送信し、Admin_Statusオブジェクトにセットされたビットを反映する必要があります。DPに対するアクションは行われず、Transit LSRはそのようなメッセージを出口ノードに転送する必要があります。すべてのノードは、ローカルパスおよびRESV状態にHビットを保存する手順を追跡する必要があります。次に、すべてのノードがHビットが関連するRESVメッセージ内で受信されるのを待ちます。RESVメッセージがIngress LERによって受信された後、ノードのRSVP-TEデータ構造に記録されたLSP情報全体をクリアするためにPathTearメッセージを送信する必要があります。下流ノードHビットセットでパスメッセージに従う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_Statusオブジェクトを含むadmin_statusオブジェクトを含むRESVメッセージ。[RFC3473]のさまざまな処理が必要です。hビットはパス状態に設定されていますが、障害が検出されたときにノードはPATHTEARを送信してはなりません。代わりに、障害はPatherrを使用して上流に報告されます。PathTearを送信できる唯一のノードはIngressノードであり、このドキュメントで指定された手順のステップとしてのみこれを行うことができます。これは、MP-To-CPとCP-To-MPの両方のハンドオーバーに適用されます。Ingressノードは、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のハンドオーバー手順は、PathTearの紛失またはノードダウンの2つの原因のためにも失敗する可能性があります。前者の場合、有効期限タイマーが経過した後にLSPがMP制御下にない場合、ネットワークオペレーターからの手動介入が要求されますが、後者の場合、さまざまなシナリオが発生する可能性があります。
- CASE I - Path message and node down
- ケースI-パスメッセージとノードダウン
| 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 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.
[RFC3473]、セクション7.2.2に従って、イングレスノードは構成可能な時間（デフォルトで30秒）を待ってから、PathTearメッセージを送信する必要があります。この場合、通常の削除手順に従う必要はありません。有効期限タイマーが経過すると、ネットワークオペレーターからの手動介入が要求され、通常、CPからMPへのハンドオーバー、LSP処理が継続されます。
- CASE II - Resv message and node down
- ケース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.
従うべき手順は、ケースIに描かれているのと同じです。ネットワーク演算子は、失敗したノードが戻ってきた後、自動CPからMPの手順を再度求めることができます。[RFC3473]、セクション7.2、ノードは新しいパスとRESVメッセージを正しく転送します。
- CASE III - PathTear message and node down
- ケースIII-パステアメッセージとノードダウン
| 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-パステアメッセージとノードダウン
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 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に渡される場合に発生します。セクション4で説明されているように、すべてのLSP情報（ラベルを含む）を収集してEROにフォーマットする代わりに、最小限の情報から始めることができます。完全なEROメソッドと部分/NO 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.
Ingressノードでは、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.
Ingress Lerで入手可能な情報から、そのIngressノードの発信インターフェイスIDについて開始すると、次のホップの着信インターフェイス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.
したがって、パスメッセージは、label_setオブジェクト（[rfc3473]）とupstream_labelオブジェクト（[rfc3473]）で構築されます。ここで、LSPのイングレス発信インターフェイスの上流ラベルと下流ラベルがこれらの2つのオブジェクトに含まれています。上記のオブジェクトに加えて、PATHメッセージには、詳細なEROベースの手続き方法の前の章で既に定義されているように、H BITセットのAdmin_Statusオブジェクトを含める必要があります。このようなハンドオーバーパスは、次のホップの着信インターフェイスに送信されます。このパスメッセージが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の次のホップを記述するパラメーターを決定した後、送信される発信パスメッセージは、rabel_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に沿った各トランジットノードのこの手順を繰り返すことにより、DP上に配置されているLSPに従って、ハンドオーバーパスメッセージに出口ノードに到達することができます。この場合、EROはオプションのオブジェクトとしてパスメッセージに含めることができ、インターフェイス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.
変更には、admin_statusとerror_specオブジェクトの2つのRSVPオブジェクトに関するものが必要です。
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.
障害は、上流の方向にあるPatherrメッセージと下流方向のPathTearメッセージによって通知されます。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
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_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
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.
エイドリアン・ファレル、ルー・バーガー、アラン・エルダー、ベン・キャンベルに感謝し、この文書を出版のために準備するための貴重なアドバイスに感謝します。また、このドキュメントの初期段階に貢献してくれたニコラシウリ（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
Shan Zhu Fujitsu Network Communications Inc. 2801 Telecom Parkway、Richardson、TX 75082 USAメール：shan.zhu@us.fujitsu.com Tel：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 Optical Networking Inc 7926 Jones Branch Drive、Suite 615 McLean、VA 22102 USAメール：ibryskin@advaoptical.com
Francesco Fondelli Ericsson Via Negrone 1A Genova - 16145 Italy EMail: francesco.fondelli@ericsson.com
Negrone 1A Genova経由のFrancesco Fondelli Ericsson -16145イタリアメール：francesco.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 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] Berger、L.、Gan、D.、Swallow、G.、Pan、P.、Tommasi、F.、およびS. Molendini、「RSVP Refrend Overhead Recotion Extensions」、RFC 2961、2001年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 3945、2004年10月。
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", RFC 4003, February 2005.
[RFC4003] Berger、L。、「GMPLS Signaling Procedure for Eugress Control」、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、4月2009年。
[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.ネグロン1a Genova -Sestri Ponente 16153 Italy
EMail: diego.caviglia@ericsson.com
Daniele Ceccarelli Ericsson Via A. Negrone 1A Genova - Sestri Ponente 16153 Italy
Daniele Ceccarelli Ericsson via A. Negrone 1a Genova -Sestri Ponente 16153 Italy
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
Dan Li Huawei Technologies F3-5-B R＆D Center、Huawei Base Shenzhen 518129 P.R. China
EMail: danli@huawei.com
Snigdho Bardalai Fujitsu Network 2801 Telecom Parkway Richardson, TX 75082 USA
Snigdho Bardalai Fujitsu Network 2801 Telecom Parkway Richardson、TX 75082 USA
EMail: sbardalai@gmail.com