[要約] RFC 5495は、RSVP-TEの優雅な再起動手順について説明しています。このRFCの目的は、ネットワークの可用性を向上させるために、RSVP-TEの再起動時にトラフィックの中断を最小限に抑える方法を提供することです。
Network Working Group D. Li
Request for Comments: 5495 J. Gao
Category: Informational Huawei
A. Satyanarayana
Cisco
S. Bardalai
Fujitsu
March 2009
Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures
リソース予約プロトコルの説明 - トラフィックエンジニアリング（RSVP-TE）優雅な再起動手順
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic-engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) networks for state recovery of control channel or nodal faults.
リソース予約プロトコル（RSVP）のHelloメッセージは、マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）ネットワークに参加するラベルスイッチングルーター（LSR）の基本的なシグナリングノード隣接を確立および維持するために定義されています。Helloメッセージは、コントロールチャネルまたは節点障害の状態回復のための一般化されたMPL（GMPLS）ネットワークで使用するために拡張されています。
The GMPLS protocol definitions for RSVP also allow a restarting node to learn which label it previously allocated for use on a Label Switched Path (LSP).
RSVPのGMPLSプロトコル定義により、再起動ノードがラベルスイッチドパス（LSP）で使用するために以前に割り当てられたラベルを学習することもできます。
Further RSVP protocol extensions have been defined to enable a restarting node to recover full control plane state by exchanging RSVP messages with its upstream and downstream neighbors.
さらにRSVPプロトコル拡張は、RSVPメッセージを上流および下流の隣人と交換することにより、再起動ノードがフルコントロールプレーン状態を回復できるように定義されています。
This document provides an informational clarification of the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered in different scenarios where the order in which the nodes restart is different.
このドキュメントは、複数のノード障害がある場合のGMPLSネットワークの制御プレーン手順の情報明確化を提供し、ノードが再起動する順序が異なるさまざまなシナリオで、完全な制御プレーンの状態を回復する方法を説明します。
This document does not define any new processes or procedures. All protocol mechanisms are already defined in the referenced documents.
このドキュメントは、新しいプロセスや手順を定義しません。すべてのプロトコルメカニズムは、参照されたドキュメントで既に定義されています。
Table of Contents
目次
1. Introduction ....................................................3
2. Existing Procedures for Single Node Restart .....................4
2.1. Procedures Defined in RFC 3473 .............................4
2.2. Procedures Defined in RFC 5063 .............................5
3. Multiple Node Restart Scenarios .................................6
4. RSVP State ......................................................7
5. Procedures for Multiple Node Restart ............................7
5.1. Procedures for the Normal Node .............................8
5.2. Procedures for the Restarting Node .........................8
5.2.1. Procedures for Scenario 1 ...........................8
5.2.2. Procedures for Scenario 2 ...........................9
5.2.3. Procedures for Scenario 3 ..........................11
5.2.4. Procedures for Scenario 4 ..........................12
5.2.5. Procedures for Scenario 5 ..........................12
5.3. Consideration of the Reuse of Data Plane Resources ........12
5.4. Consideration of Management Plane Intervention ............13
6. Clarification of Restarting Node Procedure .....................13
7. Security Considerations ........................................15
8. Acknowledgments ................................................16
9. References .....................................................17
9.1. Normative References ......................................17
9.2. Informative References ....................................17
The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic-engineered (TE) network [RFC3209]. The Hello message has been extended for use in Generalized MPLS (GMPLS) networks for state recovery of control channel or nodal faults through the exchange of the Restart_Cap Object [RFC3473].
リソース予約プロトコル（RSVP）のHelloメッセージは、マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）ネットワーク[RFC3209]に参加するラベルスイッチングルーター（LSR）の基本的なシグナリングノード隣接を確立および維持するために定義されています。Helloメッセージは、RestART_CAPオブジェクト[RFC3473]の交換を通じて、コントロールチャネルまたは節点障害の状態回復のための一般化されたMPLS（GMPLS）ネットワークで使用するために拡張されています。
The GMPLS protocol definitions for RSVP [RFC3473] also allow a restarting node to learn which label it previously allocated for use on a Label Switched Path (LSP) through the Recovery_Label Object carried on a Path message sent to a restarting node from its upstream neighbor.
RSVP [RFC3473]のGMPLSプロトコル定義により、再起動ノードは、上流の隣人から再起動したノードに送信されたパスメッセージに送られたRecovery_Labelオブジェクトを介してラベルスイッチドパス（LSP）で使用するために以前に割り当てられたラベルを学習することを可能にします。
Further RSVP protocol extensions have been defined [RFC5063] to perform graceful restart and to enable a restarting node to recover full control plane state by exchanging RSVP messages with its upstream and downstream neighbors. State previously transmitted to the upstream neighbor (principally, the downstream label) is recovered from the upstream neighbor on a Path message (using the Recovery_Label Object as described in [RFC3473]). State previously transmitted to the downstream neighbor (including the upstream label, interface identifiers, and the explicit route) is recovered from the downstream neighbor using a RecoveryPath message.
さらにRSVPプロトコル拡張は定義されており[RFC5063]、優雅な再起動を実行し、RSVPメッセージをアップストリームおよびダウンストリームネイバーと交換することにより、再起動ノードがフルコントロールプレーン状態を回復できるようにします。以前に上流の隣人に送信された状態（主に、下流のラベル）は、パスメッセージ（[RFC3473]に記載されているようにRecover_Labelオブジェクトを使用して）上流の隣人から回収されます。以前に下流の隣人（上流のラベル、インターフェイス識別子、および明示的なルートを含む）に送信された状態は、RecoveryPathメッセージを使用して下流の隣人から回収されます。
[RFC5063] also extends the Hello message to exchange information about the ability to support the RecoveryPath message.
[RFC5063]は、Helloメッセージを拡張して、RecoveryPathメッセージをサポートする機能に関する情報を交換します。
The examples and procedures in [RFC3473] and [RFC5063] focus on the description of a single node restart when adjacent network nodes are operative. Although the procedures are equally applicable to multi-node restarts, no detailed explanation is provided for such a case.
[RFC3473]および[RFC5063]の例と手順は、隣接するネットワークノードが動作している場合の単一ノード再起動の説明に焦点を当てています。手順はマルチノードの再起動に等しく適用できますが、そのようなケースについては詳細な説明は提供されていません。
This document provides an informational clarification of the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered in different scenarios where the order in which the nodes restart is different.
このドキュメントは、複数のノード障害がある場合のGMPLSネットワークの制御プレーン手順の情報明確化を提供し、ノードが再起動する順序が異なるさまざまなシナリオで、完全な制御プレーンの状態を回復する方法を説明します。
This document does not define any new processes or procedures. All protocol mechanisms already defined in [RFC3473] and [RFC5063] are definitive.
このドキュメントは、新しいプロセスや手順を定義しません。[RFC3473]および[RFC5063]ですでに定義されているすべてのプロトコルメカニズムは決定的です。
This section documents for information the existing procedures defined in [RFC3473] and [RFC5063]. Those documents are definitive, and the description here is non-normative. It is provided for informational clarification only.
このセクションでは、[RFC3473]および[RFC5063]で定義されている既存の手順を情報について説明します。これらのドキュメントは決定的であり、ここでの説明は非規範的です。情報の説明のみが提供されます。
In the case of nodal faults, the procedures for the restarting node and the procedures for the neighbor of a restarting node are applied to the corresponding nodes. These procedures, described in [RFC3473], are summarized as follows:
節点障害の場合、再起動ノードの手順と再起動ノードの隣人の手順が対応するノードに適用されます。[RFC3473]に記載されているこれらの手順は、次のように要約されています。
For the Restarting Node:
再起動ノードの場合：
1) Tells its neighbors that state recovery is supported using the Hello message.
1) 隣人に、Helloメッセージを使用して状態の回復がサポートされていることを伝えます。
2) Recovers its RSVP state with the help of a Path message, received from its upstream neighbor, that carries the Recovery_Label Object.
2) RECOVERICE_LABELオブジェクトを運ぶ上流の隣人から受信したパスメッセージの助けを借りて、RSVP状態を回復します。
3) For bidirectional LSPs, uses the Upstream_Label Object on the received Path message to recover the corresponding RSVP state.
3) 双方向LSPの場合、受信したパスメッセージのupstream_labelオブジェクトを使用して、対応するRSVP状態を回復します。
4) If the corresponding forwarding state in the data plane does not exist, the node treats this as a setup for a new LSP. If the forwarding state in the data plane does exist, the forwarding state is bound to the LSP associated with the message, and the related forwarding state should be considered as valid and refreshed. In addition, if the node is not the tail-end of the LSP, the incoming label on the downstream interface is retrieved from the forwarding state on the restarting node and set in the Upstream_Label Object in the Path message sent to the downstream neighbor.
4) データプレーン内の対応する転送状態が存在しない場合、ノードはこれを新しいLSPのセットアップとして扱います。データプレーン内の転送状態が存在する場合、転送状態はメッセージに関連付けられたLSPに拘束され、関連する転送状態は有効で更新されていると見なされる必要があります。さらに、ノードがLSPのテールエンドではない場合、下流インターフェイスの着信ラベルは、再起動ノードの転送状態から取得され、下流の隣接に送信されたパスメッセージのアップストリーム_Labelオブジェクトに設定されます。
For the Neighbor of a Restarting Node:
再起動ノードの隣人の場合：
1) Sends a Path message with the Recovery_Label Object containing a label value corresponding to the label value received in the most recently received corresponding Resv message.
1) 最近受信した対応するRESVメッセージで受信されたラベル値に対応するラベル値を含むRecovery_Labelオブジェクトを使用してパスメッセージを送信します。
2) Resumes refreshing Path state with the restarting node.
2) 再起動ノードでさわやかなパス状態を再開します。
3) Resumes refreshing Resv state with the restarting node.
3) 再起動ノードでリフレッシュRESV状態を再開します。
A new message is introduced in [RFC5063] called the RecoveryPath message. This message is sent by the downstream neighbor of a restarting node to convey the contents of the last received Path message back to the restarting node.
RecoveryPathメッセージと呼ばれる[RFC5063]で新しいメッセージが導入されています。このメッセージは、再起動ノードの下流の隣人によって送信され、最後に受信したパスメッセージの内容を再起動ノードに戻すことができます。
The restarting node will receive the Path message with the Recovery_Label Object from its upstream neighbor and/or the RecoveryPath message from its downstream neighbor. The full RSVP state of the restarting node can be recovered from these two messages.
再起動ノードは、上流の隣人からRecover_Labelオブジェクトを使用してパスメッセージを受信し、および/または下流の隣人からRecoveryPathメッセージを受信します。再起動ノードの完全なRSVP状態は、これら2つのメッセージから回復できます。
The following state can be recovered from the received Path message:
次の状態は、受信したパスメッセージから回復できます。
o Upstream data interface (from RSVP_Hop Object)
o 上流のデータインターフェイス（rsvp_hopオブジェクトから）
o Label on the upstream data interface (from Recovery_Label Object)
o 上流のデータインターフェイスにラベル（Recovery_Labelオブジェクトから）
o Upstream label for bidirectional LSP (from Upstream_Label Object)
o 双方向LSPの上流ラベル（upstream_labelオブジェクトから）
The following state can be recovered from the received RecoveryPath message:
次の状態は、受信したRecoveryPathメッセージから回収できます。
o Downstream data interface (from RSVP_Hop Object)
o ダウンストリームデータインターフェイス（RSVP_HOPオブジェクトから）
o Label on the downstream data interface (from Recovery_Label Object) o Upstream direction label for bidirectional LSP (from Upstream_Label Object)
o ダウンストリームデータインターフェイスのラベル（Recovery_Labelオブジェクトから）o双方向LSPの上流方向ラベル（upstream_labelオブジェクトから）
The other objects originally exchanged on Path and Resv messages can be recovered from the regular Path and Resv refresh messages, or from the RecoveryPath.
元々PATHおよびRESVメッセージで交換されていた他のオブジェクトは、通常のパスおよびRESV更新メッセージ、またはRecoveryPathから回復できます。
We define the following terms for the different node types:
さまざまなノードタイプの次の用語を定義します。
Restarting - The node has restarted. Communication with its neighbor nodes is restored, and its RSVP state is under recovery.
再起動 - ノードが再起動しました。隣接ノードとの通信が復元され、そのRSVP状態は回復中です。
Delayed Restarting - The node has restarted, but the communication with a neighbor node is interrupted (for example, the neighbor node needs to restart).
再起動の遅延 - ノードが再起動しましたが、近隣ノードとの通信が中断されます（たとえば、隣のノードが再起動する必要があります）。
Normal - The normal node is the fully operational neighbor of a restarting or delayed restarting node.
通常 - 通常のノードは、再起動または再起動ノードの完全に動作する隣接です。
There are five scenarios for multi-node restart. We will focus on the different positions of a restarting node. As shown in Figure 1, an LSP starts from Node A, traverses Nodes B and C, and ends at Node D.
マルチノードの再起動には5つのシナリオがあります。再起動ノードのさまざまな位置に焦点を当てます。図1に示すように、LSPはノードAから始まり、ノードBとCをトラバースし、ノードDで終了します。
+-----+ Path +-----+ Path +-----+ Path +-----+
| PSB |------->| PSB |------->| PSB |------->| PSB |
| | | | | | | |
| RSB |<-------| RSB |<-------| RSB |<-------| RSB |
+-----+ Resv +-----+ Resv +-----+ Resv +-----+
Node A Node B Node C Node D
Figure 1: Two Neighbor Nodes Restart
図1：2つの隣接ノードが再起動します
1) A restarting node with downstream delayed restarting node. For example, in Figure 1, Nodes A and D are normal nodes, Node B is a restarting node, and Node C is a delayed restarting node.
1) 下流の遅延再起動ノードを備えた再起動ノード。たとえば、図1では、ノードAとDは通常のノード、ノードBは再起動ノード、ノードCは再起動ノードの遅延です。
2) A restarting node with upstream delayed restarting node. For example, in Figure 1, Nodes A and D are normal nodes, Node B is a delayed restarting node, and Node C is a restarting node.
2) 上流の遅延再起動ノードを備えた再起動ノード。たとえば、図1では、ノードAとDは通常のノードであり、ノードBは再起動ノード、ノードCは再起動ノードです。
3) A restarting node with downstream and upstream delayed restarting nodes. For example, in Figure 1, Node A is a normal node, Nodes B and D are delayed restarting nodes, and Node C is a restarting node.
3) 下流および上流の遅延再起動ノードを備えた再起動ノード。たとえば、図1では、ノードAは通常のノードであり、ノードBとDはノードの再起動の遅延、ノードCは再起動ノードです。
4) A restarting ingress node with downstream delayed restarting node. For example, in Figure 1, Node A is a restarting node and Node B is a delayed restarting node. Nodes C and D are normal nodes.
4) 下流の遅延再起動ノードを備えた再起動ノードの再起動。たとえば、図1では、ノードAは再起動ノードであり、ノードBは再起動ノードの遅延です。ノードCとDは通常のノードです。
5) A restarting egress node with upstream delayed restarting node. For example, in Figure 1, Nodes A and B are normal nodes, Node C is a delayed restarting node, and Node D is a restarting node.
5) 上流の遅延再起動ノードを備えた出力ノードの再起動。たとえば、図1では、ノードAとBは通常のノード、ノードCは再起動ノードの遅延、ノードDは再起動ノードです。
If the communication between two nodes is interrupted, the upstream node may think the downstream node is a delayed restarting node, or vice versa.
2つのノード間の通信が中断された場合、上流ノードは下流ノードが遅延再起動ノードであると考えるか、その逆も同様です。
Note that if multiple nodes that are not neighbors are restarted, the restart procedures could be applied as multiple separated restart procedures that are exactly the same as the procedures described in [RFC3473] and [RFC5063]. Therefore, these scenarios are not described in this document. For example, in Figure 1, Node A and Node C are normal nodes, and Node B and Node D are restarting nodes; therefore, Node B could be restarted through Node A and Node C, while Node D could be restarted through Node C separately.
近隣ではない複数のノードが再起動される場合、[RFC3473]および[RFC5063]で説明されている手順とまったく同じ複数の分離された再起動手順として再起動手順を適用できることに注意してください。したがって、これらのシナリオはこのドキュメントでは説明されていません。たとえば、図1では、ノードAとノードCは通常のノードであり、ノードBとノードDはノードの再起動です。したがって、ノードBはノードAおよびノードCを介して再起動できますが、ノードDはノードCを介して個別に再起動できます。
For each scenario, the RSVP state that needs to be recovered at the restarting nodes are the Path State Block (PSB) and Resv State Block (RSB), which are created when the node receives the corresponding Path message and Resv message.
各シナリオについて、再起動ノードで回復する必要があるRSVPの状態は、ノードが対応するパスメッセージとRESVメッセージを受信したときに作成されるパス状態ブロック（PSB）およびRESV状態ブロック（RSB）です。
According to [RFC2209], how to construct the PSB and RSB is really an implementation issue. In fact, there is no requirement to maintain separate PSB and RSB data structures. In GMPLS, there is a much closer tie between Path and Resv state so it is possible to combine the information into a single state block (the LSP state block). On the other hand, if point-to-multipoint is supported, it may be convenient to maintain separate upstream and downstream state. Note that the PSB and RSB are not upstream and downstream state since the PSB is responsible for receiving a Path from upstream and sending a Path to downstream.
[RFC2209]によると、PSBとRSBの構築方法は実際に実装の問題です。実際、個別のPSBおよびRSBデータ構造を維持するための要件はありません。GMPLSでは、PATHとRESV状態の間にはるかに近いネクタイがあるため、情報を単一の状態ブロック（LSP状態ブロック）に結合することができます。一方、ポイントツーマルチポイントがサポートされている場合、別々の上流と下流の状態を維持することが便利かもしれません。PSBは、PSBが上流からパスを受け取り、下流へのパスを送信する責任があるため、PSBとRSBは上流および下流の状態ではないことに注意してください。
Regardless of how the RSVP state is implemented, on recovery there are two logical pieces of state to be recovered and these correspond to the PSB and RSB.
RSVP状態がどのように実装されるかに関係なく、回復時に回復する2つの論理的な状態があり、これらはPSBとRSBに対応します。
In this document, all the nodes are assumed to have the graceful restart capabilities that are described in [RFC3473] and [RFC5063].
このドキュメントでは、すべてのノードに[RFC3473]および[RFC5063]で説明されている優雅な再起動機能があると想定されています。
When the downstream normal node detects its neighbor restarting, it must send a RecoveryPath message for each LSP associated with the restarting node for which it has previously sent a Resv message and which has not been torn down.
下流の通常のノードがネイバーの再起動を検出すると、以前にRESVメッセージを送信し、取り壊されていない再起動ノードに関連付けられた各LSPにRecoveryPathメッセージを送信する必要があります。
When the upstream normal node detects its neighbor restarting, it must send a Path message with a Recovery_Label Object containing a label value corresponding to the label value received in the most recently received corresponding Resv message.
上流の通常のノードが近隣の再起動を検出すると、最近受信した最近の対応するRESVメッセージで受信されたラベル値に対応するラベル値を含むRecovery_Labelオブジェクトを使用してパスメッセージを送信する必要があります。
This document does not modify the procedures for the normal node, which are described in [RFC3473] and [RFC5063].
このドキュメントでは、[RFC3473]および[RFC5063]で説明されている通常のノードの手順を変更しません。
This document does not modify the procedures for the restarting node, which are described in [RFC3473] and [RFC5063].
このドキュメントは、[RFC3473]および[RFC5063]で説明されている再起動ノードの手順を変更しません。
After the restarting node restarts, it starts a Recovery Timer. Any RSVP state that has not been resynchronized when the Recovery Timer expires should be cleared.
再起動ノードの再起動後、リカバリタイマーが開始されます。回復タイマーの有効期限が切れたときに再同期されていないRSVP状態をクリアする必要があります。
At the restarting node (Node B in the example), full resynchronization with the upstream neighbor (Node A) is possible because Node A is a normal node. The upstream Path information is recovered from the Path message received from Node A. Node B also recovers the upstream Resv information (that it had previously sent to Node A) from the Recovery_Label Object carried in the Path message received from Node A, but, obviously, some information (like the Recorded_Route Object) will be missing from the new Resv message generated by Node B and cannot be supplied until the downstream delayed restarting node (Node C) restarts and sends a Resv.
再起動ノード（例のノードB）では、ノードAが通常のノードであるため、上流の隣接（ノードA）との完全な再同期が可能です。上流のパス情報は、ノードAから受信したパスメッセージから回復されます。ノードBは、ノードAから受信したパスメッセージに掲載されたRecovery_Labelオブジェクトから上流のRESV情報（以前にノードaに送信した）も回復しますが、明らかに、明らかに、、いくつかの情報（録音された_Routeオブジェクトなど）は、ノードBによって生成された新しいRESVメッセージから欠落し、下流の遅延再起動ノード（ノードC）が再起動してRESVを送信するまで提供することはできません。
After the upstream Path information and upstream Resv information have been recovered by Node B, the normal refresh procedure with upstream Node A should be started.
上流のパス情報と上流のRESV情報がノードBによって回復された後、上流ノードAを備えた通常の更新手順を開始する必要があります。
As per [RFC5063], the restarting node (Node B) would normally expect to receive a RecoveryPath message from its downstream neighbor (Node C). It would use this to recover the downstream Path information, and would subsequently send a Path message to its downstream neighbor and receive a Resv message. But in this scenario, because the downstream neighbor has not restarted yet, Node B detects the communication with Node C is interrupted and must wait before resynchronizing with its downstream neighbor.
[RFC5063]によると、再起動ノード（ノードB）は通常、下流の隣人（ノードC）からRecoveryPathメッセージを受信すると予想されます。これを使用してダウンストリームパス情報を回復し、その後、下流の隣人にパスメッセージを送信し、RESVメッセージを受信します。しかし、このシナリオでは、下流の隣人がまだ再起動していないため、ノードBはノードCとの通信が中断され、下流の隣人と再同期する前に待つ必要があります。
In this case, the restarting node (Node B) follows the procedures in Section 9.3 of [RFC3473] and may run a Restart Timer to wait for the downstream neighbor (Node C) to restart. If its downstream neighbor (Node C) has not restarted before the timer expires, the corresponding LSPs may be torn down according to local policy [RFC3473]. Note, however, that the Restart Time value suggested in [RFC3473] is based on the previous Hello message exchanged with the node that has not restarted yet (Node C). Since this time value is unlikely to be available to the restarting node (Node B), a configured time value must be used if the timer is operated.
この場合、再起動ノード（ノードB）は[RFC3473]のセクション9.3の手順に従い、再起動タイマーを実行して下流の隣人（ノードC）が再起動するのを待つことができます。下流の隣人（ノードC）がタイマーの有効期限が切れる前に再起動していない場合、対応するLSPはローカルポリシー[RFC3473]に従って取り壊される可能性があります。ただし、[RFC3473]で提案されている再起動時間値は、まだ再起動していないノードと交換された以前のハローメッセージに基づいていることに注意してください（ノードC）。この時間値が再起動ノード（ノードB）で利用可能になる可能性は低いため、タイマーが動作している場合は構成された時間値を使用する必要があります。
The RSVP state must be reconciled with the retained data plane state if the cross-connect information can be retrieved from the data plane. In the event of any mismatches, local policy will dictate the action that must be taken, which could include:
RSVP状態は、データプレーンからクロス接続情報を取得できる場合、保持データプレーン状態と調整する必要があります。不一致が発生した場合、ローカルポリシーは、取得する必要があるアクションを決定します。
- reprogramming the data plane
- データプレーンの再プログラミング
- sending an alert to the management plane
- 管理プレーンにアラートを送信します
- tearing down the control plane state for the LSP
- LSPのコントロールプレーン状態を引き裂く
In the case that the delayed restarting node never comes back and a Restart Timer is not used to automatically tear down LSPs, the LSPs can be tidied up through the control plane using a PathTear from the upstream node (Node A). Note that if Node C restarts after this operation, the RecoveryPath message that it sends to Node B will not be matched with any state on Node B and will receive a PathTear as its response, resulting in the teardown of the LSP at all downstream nodes.
遅延再起動ノードが戻ってこない場合、再起動タイマーはLSPを自動的に解体するために使用されない場合、上流ノード（ノードA）からのPathTearを使用してLSPをコントロールプレーンに整えることができます。この操作後にノードCが再起動した場合、ノードBに送信するRecoveryPathメッセージはノードBのどの状態と一致せず、その応答としてPathTearを受信し、すべての下流ノードでLSPが分解されることに注意してください。
In this case, the restarting node (Node C) can recover full downstream state from its downstream neighbor (Node D), which is a normal node. The downstream Path state can be recovered from the RecoveryPath message, which is sent by Node D. This allows Node C to send a Path refresh message to Node D, and Node D will respond with a Resv message from which Node C can reconstruct the downstream Resv state.
この場合、再起動ノード（ノードC）は、下流の近隣（ノードD）から完全な下流状態を回復できます。これは通常のノードです。ダウンストリームパスの状態は、ノードDによって送信されるRecoveryPathメッセージから回復できます。これにより、ノードCはノードDにパス更新メッセージを送信でき、ノードDはノードCが下流を再構築できるRESVメッセージで応答します。RESV状態。
After the downstream Path information and downstream Resv information have been recovered in Node C, the normal refresh procedure with downstream Node D should be started.
ダウンストリームパス情報とダウンストリームRESV情報がノードCで回復した後、下流ノードDを使用した通常の更新手順を開始する必要があります。
The restarting node would normally expect to resynchronize with its upstream neighbor to re-learn the upstream Path and Resv state, but in this scenario, because the upstream neighbor (Node B) has not restarted yet, the restarting node (Node C) detects that the communication with upstream neighbor (Node B) is interrupted. The restarting node (Node C) follows the procedures in Section 9.3 of [RFC3473] and may run a Restart Timer to wait for the upstream neighbor (Node B) to restart. If its upstream neighbor (Node B) has not restarted before the Restart Timer expires, the corresponding LSPs may be torn down according to local policy [RFC3473]. Note, however, that the Restart Time value suggested in [RFC3473] is based on the previous Hello message exchanged with the node that has not restarted yet (Node B). Since this time value is unlikely to be available to the restarting node (Node C), a configured time value must be used if the timer is operated.
再起動ノードは通常、上流の隣人と再同期することを期待して上流のパスとRESV状態を再学習しますが、このシナリオでは、上流の隣人（ノードB）がまだ再起動していないため、再起動ノード（ノードC）はそれを検出することを検出します。上流の隣人（ノードB）との通信が中断されます。再起動ノード（ノードC）は、[RFC3473]のセクション9.3の手順に従い、再起動タイマーを実行して上流の近隣（ノードB）が再起動するのを待つことができます。上流の隣人（ノードB）が再起動タイマーの有効期限が切れる前に再起動していない場合、対応するLSPはローカルポリシー[RFC3473]に従って取り壊される可能性があります。ただし、[RFC3473]で提案されている再起動時間値は、まだ再起動していないノードと交換された以前のハローメッセージに基づいていることに注意してください（ノードB）。この時間値が再起動ノード（ノードC）で利用可能になる可能性は低いため、タイマーが操作されている場合は、構成された時間値を使用する必要があります。
Note that no Resv message is sent to the upstream neighbor (Node B), because it has not restarted.
再起動していないため、RESVメッセージは上流の隣人（ノードB）に送信されないことに注意してください。
The RSVP state must be reconciled with the retained data plane state if the cross-connect information can be retrieved from the data plane.
RSVP状態は、データプレーンからクロス接続情報を取得できる場合、保持データプレーン状態と調整する必要があります。
In the event of any mismatches, local policy will dictate the action that must be taken, which could include:
不一致が発生した場合、ローカルポリシーは、取得する必要があるアクションを決定します。
- reprogramming the data plane
- データプレーンの再プログラミング
- sending an alert to the management plane
- 管理プレーンにアラートを送信します
- tearing down the control plane state for the LSP
- LSPのコントロールプレーン状態を引き裂く
In the case that the delayed restarting node never comes back and a Restart Timer is not used to automatically tear down LSPs, the LSPs cannot be tidied up through the control plane using a PathTear from the upstream node (Node A), because there is no control plane connectivity to Node C from the upstream direction. There are two possibilities in [RFC3473]:
遅延再起動ノードが戻ってこない場合、再起動タイマーを使用して自動的にLSPを解体する場合、上流ノード（ノードA）からのパステアを使用してLSPをコントロールプレーンに整理することはできません。上流の方向からノードCへの制御プレーンの接続。[RFC3473]には2つの可能性があります。
- Management action may be taken at the restarting node to tear the LSP. This will result in the LSP being removed from Node C and a PathTear being sent downstream to Node D.
- 再起動ノードでは、LSPを引き裂くために管理アクションが実行される場合があります。これにより、LSPがノードCから削除され、PathTearが下流にノードDに送信されます。
- Management action may be taken at any downstream node (for example, Node D), resulting in a PathErr message with the Path_State_Removed flag set being sent to Node C to tear the LSP state.
- 管理アクションは、ダウンストリームノード（ノードDなど）で実行される場合があり、PATHE_STATE_REMOVEDフラグセットがNODE Cに送信されてLSP状態を引き裂くことができます。
Note that if Node B restarts after this operation, the Path message that it sends to Node C will not be matched with any state on Node C and will be treated as a new Path message, resulting in LSP setup. Node C should use the labels carried in the Path message (in the Upstream_Label Object and in the Recovery_Label Object) to drive its label allocation, but may use other labels according to normal LSP setup rules.
この操作後にノードBが再起動すると、ノードCに送信するパスメッセージはノードCのどの状態と一致せず、新しいパスメッセージとして扱われ、LSPセットアップになります。ノードCは、パスメッセージ（upstream_labelオブジェクトとrecovery_labelオブジェクト）にあるラベルの割り当てを駆動するが、通常のLSPセットアップルールに従って他のラベルを使用する場合があります。
In this example, the restarting node (Node C) is isolated. Its upstream and downstream neighbors have not restarted.
この例では、再起動ノード（ノードC）が分離されています。その上流および下流の隣人は再起動していません。
The restarting node (Node C) follows the procedures in Section 9.3 of [RFC3473] and may run a Restart Timer for each of its neighbors (Nodes B and D). If a neighbor has not restarted before its Restart Timer expires, the corresponding LSPs may be torn down according to local policy [RFC3473]. Note, however, that the Restart Time values suggested in [RFC3473] are based on the previous Hello message exchanged with the nodes that have not restarted yet. Since these time values are unlikely to be available to the restarting node (Node C), a configured time value must be used if the timer is operated.
再起動ノード（ノードC）は、[RFC3473]のセクション9.3の手順に従い、各近隣（ノードBおよびD）の再起動タイマーを実行する場合があります。再起動タイマーが期限切れになる前に隣人が再起動していない場合、対応するLSPはローカルポリシー[RFC3473]に従って取り壊される可能性があります。ただし、[RFC3473]で提案されている再起動時間値は、まだ再起動していないノードと交換された以前のハローメッセージに基づいていることに注意してください。これらの時間値が再起動ノード（ノードC）で利用可能になる可能性は低いため、タイマーが動作している場合は構成された時間値を使用する必要があります。
During the Recovery Time, if the upstream delayed restarting node has restarted, the procedure for scenario 1 can be applied.
回復時間中、上流の遅延再起動ノードが再起動した場合、シナリオ1の手順を適用できます。
During the Recovery Time, if the downstream delayed restarting node has restarted, the procedure for scenario 2 can be applied.
回復時間中、下流の遅延再起動ノードが再起動した場合、シナリオ2の手順を適用できます。
In the case that neither delayed restarting node ever comes back and a Restart Timer is not used to automatically tear down LSPs, management intervention is required to tidy up the control plane and the data plane on the node that is waiting for the failed device to restart.
どちらの再起動ノードの再起動の遅れも戻ってきていない場合、LSPを自動的に解体するために再起動タイマーを使用していない場合、管理介入がコントロールプレーンと障害のあるデバイスが再起動するのを待っているノードのデータプレーンを整理するために必要です。
If the downstream delayed restarting node restarts after the cleanup of LSPs at Node C, the RecoveryPath message from Node D will be responded to with a PathTear message. If the upstream delayed restarting node restarts after the cleanup of LSPs at Node C, the Path message from Node B will be treated as a new LSP setup request, but the setup will fail because Node D cannot be reached; Node C will respond with a PathErr message. Since this happens to Node B during its restart processing, it should follow the rules of [RFC5063] and tear down the LSP.
Node CでのLSPのクリーンアップ後に下流の再起動ノードの再起動が再起動すると、ノードDからのRecoverPathメッセージがPathTearメッセージで応答されます。ノードCでのLSPのクリーンアップ後に上流の遅延再起動ノードが再起動すると、ノードBからのパスメッセージは新しいLSPセットアップリクエストとして扱われますが、ノードDに到達できないため、セットアップは失敗します。ノードCはPatherrメッセージで応答します。これは再起動処理中にノードBに発生するため、[RFC5063]のルールに従い、LSPを取り壊す必要があります。
When the ingress node (Node A) restarts, it does not know which LSPs it caused to be created. Usually, however, this information is retrieved from the management plane or from the configuration requests stored in non-volatile form in the node in order to recover the LSP state.
イングレスノード（ノードA）が再起動すると、どのLSPが作成されるかわかりません。ただし、通常、この情報は、LSP状態を回復するために、ノードに不揮発性の形式で保存されている管理プレーンまたは構成要求から取得されます。
Furthermore, if the downstream node (Node B) is a normal node, according to the procedures in [RFC5063], the ingress will receive a RecoveryPath message and will understand that it was the ingress of the LSP.
さらに、[RFC5063]の手順によると、下流ノード（ノードB）が通常のノードである場合、侵入はRecoveryPathメッセージを受け取り、LSPの侵入であることを理解します。
However, in this scenario, the downstream node is a delayed restarting node, so Node A must either rely on the information from the management plane or stored configuration, or it must wait for Node B to restart.
ただし、このシナリオでは、ダウンストリームノードは再起動ノードの遅延であるため、ノードAは管理プレーンからの情報または保存された構成に依存するか、ノードBが再起動するのを待つ必要があります。
In the event that Node B never restarts, management plane intervention is needed at Node A to clean up any LSP control plane state restored from the management plane or from local configuration, and to release any data plane resources.
ノードBが再起動しない場合、ノードAで管理プレーンの介入が必要であり、管理プレーンまたはローカル構成から復元されたLSPコントロールプレーン状態をクリーンアップし、データプレーンリソースをリリースします。
In this scenario, the egress node (Node D) restarts, and its upstream neighbor (Node C) has not restarted. In this case, the egress node may have no control plane state relating to the LSPs. It has no downstream neighbor to help it and no management plane or configuration information, although there will be data plane state for the LSP. The egress node must simply wait until its upstream neighbor restarts and gives it the information in Path messages carrying Recovery_Label Objects.
このシナリオでは、出口ノード（ノードD）が再起動し、その上流の隣接（ノードC）が再起動していません。この場合、出力ノードにはLSPに関連する制御平面状態がない場合があります。LSPにはデータプレーン状態がありますが、それを支援する下流の隣人も管理プレーンや構成情報もありません。出力ノードは、上流の隣人が再起動し、Recovery_Labelオブジェクトを運ぶパスメッセージ内の情報を提供するまで待機する必要があります。
Fundamental to the processes described above is an understanding that data plane resources may remain in use (allocated and cross-connected) when control plane state has not been fully resynchronized because some control plane nodes have not restarted.
上記のプロセスの基本は、一部のコントロールプレーンノードが再起動していないために制御プレーンの状態が完全に再同期されていない場合、データプレーンリソースが使用されたままである可能性がある（割り当てられ、クロス接続された）ことです。
It is assumed that these data plane resources might be carrying traffic and should not be reconfigured except through application of operator-configured policy, or as a direct result of operator action.
これらのデータプレーンリソースがトラフィックを運んでいる可能性があり、オペレーターが構成されたポリシーの適用を除いて、またはオペレーターアクションの直接的な結果として再構成すべきではないと想定されています。
In particular, new LSP setup requests from the control plane or the management plane should not be allowed to use data plane resources that are still in use. Specific action must first be taken to release the resources.
特に、コントロールプレーンまたは管理プレーンからの新しいLSPセットアップリクエストは、まだ使用されているデータプレーンリソースを使用することを許可されてはなりません。最初にリソースをリリースするために特定のアクションをとる必要があります。
The management plane must always retain the ability to control data plane resources and to override the control plane. In this context, the management plane must always be able to release data plane resources that were previously in place for use by control-plane-established LSPs. Further, the management plane must always be able to instruct any control plane node to tear down any LSP.
管理プレーンは、常にデータプレーンのリソースを制御し、制御プレーンをオーバーライドする機能を保持する必要があります。これに関連して、管理プレーンは、コントロールプレーンが確立したLSPによって以前に使用されていたデータプレーンリソースを常にリリースできる必要があります。さらに、管理プレーンは常に、任意のコントロールプレーンノードにLSPを取り壊すように指示できる必要があります。
Operators should be aware of the risks of misconnection that could be caused by careless manipulation from the management plane of in-use data plane resources.
オペレーターは、使用中のデータプレーンリソースの管理面からの不注意な操作によって引き起こされる可能性のある誤解のリスクに注意する必要があります。
According to the current graceful restart procedure [RFC3473], after a node restarts its control plane, it needs its upstream node to send a PATH message with a recovery label in order to synchronize its RSVP state. If the restarted control plane becomes operational quickly, the upstream node may not detect the restarting of the downstream node and, therefore, may send a PATH message without a recovery label, causing errors and unwanted connection deletion.
現在の優雅な再起動手順[RFC3473]によると、ノードが制御プレーンを再起動した後、RSVP状態を同期するためにリカバリラベルを使用してパスメッセージを送信するには、上流のノードが必要です。再起動されたコントロールプレーンが迅速に動作する場合、アップストリームノードは下流ノードの再起動を検出できないため、回復ラベルなしでパスメッセージを送信し、エラーと不要な接続削除を引き起こす場合があります。
N1 N2
| |
| X (Restart start)
| HELLO |
|--------------->|
| |
| SRefresh |
|--------------->|
| |
| HELLO |
|--------------->|
| |
| X (Restart complete)
| SRefresh |
|--------------->|
| NACK |
|<---------------|
| Path without |
| recovery label |
|--------------->|
| X (resource allocation failed because the
| | resources are in use)
| PathErr |
|<---------------|
| PathTear |
|--------------->|
X(LSP deletion) X (LSP deletion)
| |
Figure 2: Message Flow for Accidental LSP Deletion
図2：偶発的なLSP削除のメッセージフロー
The sequence diagram above depicts one scenario where the LSP may get deleted.
上のシーケンス図は、LSPが削除される可能性のあるシナリオの1つを示しています。
In this sequence, N1 does not detect Hello failure and continues sending SRefreshes, which may get NACK'ed by N2 once restart completes because there is no Path state corresponding to the SRefresh message. This NACK causes a Path refresh message to be generated, but there is no Recovery_Label because N1 does not yet detect that N2 has restarted, as Hello exchanges have not yet started. The Path message is treated as "new" and fails to allocate the resources because they are still in use. This causes a PathErr message to be generated, which may lead to the teardown of the LSP.
このシーケンスでは、n1はhelloの障害を検出せず、srefreshesの送信を続けます。これは、Srefreshメッセージに対応するパス状態がないため、再起動が完了するとN2によってnackになる可能性があります。このNACKはパスリフレッシュメッセージを生成しますが、N1はまだN2が再起動したことを検出していないため、recovery_labelはありません。パスメッセージは「新しい」として扱われ、まだ使用されているため、リソースの割り当てに失敗します。これにより、Patherrメッセージが生成され、LSPの分解につながる可能性があります。
To resolve the aforementioned problem, the following procedures, which are implicit in [RFC3473] and [RFC5063], should be followed. These procedures work together with the recovery procedures documented in [RFC3473]. Here, it is assumed that the restarting node and the neighboring node(s) support the Hello extension as documented in [RFC3209] as well as the recovery procedures documented in [RFC3473].
前述の問題を解決するには、[RFC3473]および[RFC5063]に暗黙的な次の手順に従う必要があります。これらの手順は、[RFC3473]に文書化された回復手順と連携して機能します。ここでは、[RFC3209]で文書化されているように、[RFC3473]で文書化された回復手順と同様に、[RFC3209]で文書化されているように、再起動ノードと隣接ノードがHello Extensionをサポートすると想定されています。
After a node restarts its control plane, it should ignore and silently drop all RSVP-TE messages (except Hello messages) it receives from any neighbor to which no HELLO session has been established.
ノードがコントロールプレーンを再起動した後、すべてのRSVP-TEメッセージ（ハローメッセージを除く）を無視して静かにドロップするはずです。
The restarting node should follow [RFC3209] to establish Hello sessions with its neighbors, after its control plane becomes operational.
再起動ノードは、[RFC3209]に従って、コントロールプレーンが動作した後、隣人とのハローセッションを確立する必要があります。
The restarting node resumes processing of RSVP-TE messages sent from each neighbor to which the Hello session has been established.
再起動ノードは、Helloセッションが確立された各隣人から送信されたRSVP-TEメッセージの処理を再開します。
This document clarifies the procedures defined in [RFC3473] and [RFC5063] to be performed on RSVP agents that neighbor one or more restarting RSVP agents. It does not introduce any new procedures and, therefore, does not introduce any new security risks or issues.
このドキュメントでは、[RFC3473]および[RFC5063]で定義されている手順を明確にし、RSVPエージェントを1つまたは複数のRSVPエージェントを再起動するRSVPエージェントで実行されます。新しい手順は導入されておらず、したがって、新しいセキュリティリスクや問題は導入されません。
In the case of the control plane in general, and the RSVP agent in particular, where one or more nodes carrying one or more LSPs are restarted due to external attacks, the procedures defined in [RFC5063] and described in this document provide the ability for the restarting RSVP agents to recover the RSVP state in each restarting node corresponding to the LSPs, with the least possible perturbation to the rest of the network. These procedures can be considered to provide mechanisms by which the GMPLS network can recover from physical attacks or from attacks on remotely controlled power supplies.
一般的なコントロールプレーンの場合、特に1つまたは複数のLSPを運ぶ1つまたは複数のノードが外部攻撃のために再起動される場合、[RFC5063]で定義され、このドキュメントで説明されている手順は、RSVPエージェントを再起動して、LSPに対応する各再起動ノードでRSVP状態を回復し、ネットワークの残りの部分への摂動を最小限に抑えます。これらの手順は、GMPLSネットワークが物理的な攻撃または遠隔制御電源への攻撃から回復できるメカニズムを提供するために考慮することができます。
The procedures described are such that only the neighboring RSVP agents should notice the restart of a node, and hence only they need to perform additional processing. This allows for a network with active LSPs to recover LSP state gracefully from an external attack, without perturbing the data/forwarding plane state and without propagating the error condition in the control or data plane. In other words, the effect of the restart (which might be the result of an attack) does not spread into the network.
説明されている手順は、隣接するRSVPエージェントのみがノードの再起動に気付くべきであるため、追加の処理を実行する必要があるということです。これにより、アクティブなLSPを備えたネットワークが、データ/転送面の状態を摂動せず、コントロールまたはデータプレーンのエラー条件を伝播することなく、外部攻撃からLSP状態を優雅に回復することができます。言い換えれば、再起動の効果（これは攻撃の結果である可能性があります）はネットワークに広がりません。
Note that concern has been expressed about the vulnerability of a restarting node to false messages received from its neighbors. For example, a restarting node might receive a false Path message with a Recovery_Label Object from an upstream neighbor, or a false RecoveryPath message from its downstream neighbor. This situation might arise in one of four cases:
隣人から受信した誤ったメッセージに対するノードの再起動の脆弱性について懸念が表明されていることに注意してください。たとえば、再起動ノードは、上流の隣人からRecovery_Labelオブジェクトを使用した誤ったパスメッセージ、または下流の隣人からの誤ったRecoveryPathメッセージを受信する場合があります。この状況は、4つのケースのいずれかで発生する可能性があります。
- The message is spoofed and does not come from the neighbor at all.
- メッセージはスプーフィングされており、隣人からはまったく来ていません。
- The message has been modified as it was traveling from the neighbor.
- メッセージは、隣人から移動していたときに変更されました。
- The neighbor is defective and has generated a message in error.
- 隣人に欠陥があり、誤ってメッセージを生成しました。
- The neighbor has been subverted and has a "rogue" RSVP agent.
- 隣人は破壊されており、「不正な」RSVPエージェントを持っています。
The first two cases may be handled using standard RSVP authentication and integrity procedures [RFC3209], [RFC3473]. If the operator is particularly worried, the control plane may be operated using IPsec [RFC4301], [RFC4302], [RFC4835], [RFC4306], and [RFC2411].
最初の2つのケースは、標準のRSVP認証および整合性手順[RFC3209]、[RFC3473]を使用して処理できます。オペレーターが特に心配している場合、コントロールプレーンは、IPSEC [RFC4301]、[RFC4302]、[RFC4835]、[RFC4306]、および[RFC2411]を使用して操作できます。
Protection against defective or rogue RSVP implementations is generally hard-to-impossible. Neighbor-to-neighbor authentication and integrity validation is, by definition, ineffective in these situations. For example, if a neighbor node sends a Resv during normal LSP setup, and if that message carries a Generalized_Label Object carrying an incorrect label value, then the receiving LSR will use the supplied value and the LSP will be set up incorrectly. Alternatively, if a Path message is modified by an upstream LSR to change the destination and explicit route, there is no way for the downstream LSR to detect this, and the LSP may be set up to the wrong destination. Furthermore, the upstream LSR could disguise this fact by modifying the recorded route reported in the Resv message. Thus, these issues are in no way specific to the restart case, do not cause any greater or different problems from the normal case, and do not warrant specific security measures applicable to restart scenarios.
欠陥または不正なRSVP実装に対する保護は、一般に不可能です。近隣から隣人の認証と整合性の検証は、定義上、これらの状況では効果がありません。たとえば、近隣ノードが通常のLSPセットアップ中にRESVを送信し、そのメッセージに誤ったラベル値を持つ一般化された_Labelオブジェクトが搭載されている場合、受信LSRは供給値を使用し、LSPは正しく設定されます。あるいは、宛先と明示的なルートを変更するために上流のLSRによってパスメッセージが変更された場合、下流のLSRがこれを検出する方法はなく、LSPは間違った宛先に設定される場合があります。さらに、上流のLSRは、RESVメッセージで報告された記録されたルートを変更することにより、この事実を隠す可能性があります。したがって、これらの問題は、再起動ケースに固有のものではなく、通常のケースとは大きいまたは異なる問題を引き起こすことはなく、シナリオを再開するために適用される特定のセキュリティ対策を保証しません。
Note that the RSVP Policy_Data Object [RFC2205] provides a scope by which secure end-to-end checks could be applied. However, very little definition of the use of this object has been made to date.
RSVP Policy_Dataオブジェクト[RFC2205]は、安全なエンドツーエンドチェックを適用できる範囲を提供することに注意してください。ただし、このオブジェクトの使用の定義はこれまでに行われていません。
See [MPLS-SEC] for a wider discussion of security in MPLS and GMPLS networks.
MPLSおよびGMPLSネットワークのセキュリティについての幅広い議論については、[MPLS-SEC]を参照してください。
We would like to thank Adrian Farrel, Dimitri Papadimitriou, and Lou Berger for their useful comments.
エイドリアン・ファレル、ディミトリ・パパジミトリウ、ルー・バーガーの有用なコメントに感謝します。
[RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997.
[RFC2209] Braden、R。およびL. Zhang、「リソース予約プロトコル（RSVP） - バージョン1メッセージ処理ルール」、RFC 2209、1997年9月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、12月2001年。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC5063] Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, October 2007.
[RFC5063] Satyanarayana、A.、ed。、およびR. Rahman、ed。、「GMPLSリソース予約プロトコル（RSVP）Graceful Restartへの拡張」、RFC 5063、2007年10月。
[MPLS-SEC] Fang, L., "Security Framework for MPLS and GMPLS Networks", Work in Progress, November 2008.
[MPLS-SEC] Fang、L。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、2008年11月、Work in Progress。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411] Thayer、R.、Doraswamy、N。、およびR. Glenn、「IP Security Document Roadmap」、RFC 2411、1998年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、RFC 4306、2005年12月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835] Manral、V。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）をカプセル化するための暗号化アルゴリズムの実装要件」、RFC 4835、2007年4月。
Authors' Addresses
著者のアドレス
Dan Li Huawei Technologies F3-5-B R&D Center, Huawei Base, Shenzhen 518129, China
Dan Li Huawei Technologies F3-5-B R＆D Center、Huawei Base、Shenzhen 518129、中国
Phone: +86 755 28970230
EMail: danli@huawei.com
Jianhua Gao Huawei Technologies F3-5-B R&D Center, Huawei Base, Shenzhen 518129, China
Jianhua Gao Huawei Technologies F3-5-B R＆D Center、Huawei Base、Shenzhen 518129、中国
Phone: +86 755 28972902
EMail: gjhhit@huawei.com
Arun Satyanarayana Cisco Systems 170 West Tasman Dr San Jose, CA 95134, USA
Arun Satyanarayana Cisco Systems 170 West Tasman Dr San Jose、CA 95134、米国
Phone: +1 408 853-3206
EMail: asatyana@cisco.com
Snigdho C. Bardalai Fujitsu Network Communications 2801 Telecom Parkway Richardson, Texas 75082, USA
Snigdho C. Bardalai Fujitsu Network Communications 2801 Telecom Parkway Richardson、Texas 75082、米国
Phone: +1 972 479 2951
EMail: snigdho.bardalai@us.fujitsu.com