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
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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メッセージは、汎用MPLS（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メッセージは、汎用MPLS（GMPLS）Restart_Capオブジェクト[RFC3473]の交換を介して、制御チャネルまたはノード障害の状態回復のためにネットワークで使用するために拡張されています。
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プロトコル定義はまた、再起動ノードはそれが以前にその上流隣接から再開ノードに送信されたPathメッセージに担持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
さらにRSVPプロトコル拡張は、グレースフルリスタートを実行するために、その上流および下流隣人とRSVPメッセージを交換することによって、完全な制御プレーンの状態を回復するために再起動ノードを有効にするには、[RFC5063]を定義されています。以前に上流隣接（主に、下流ラベル）に送信された状態を使用して（Pathメッセージで上流隣接から回収されます
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.
[RFC3473]に記載されているように）オブジェクトRecovery_Label。以前に（上流ラベル、インタフェース識別子、及び明示的経路を含む）下流の近隣に送信状態がRecoveryPathメッセージを使用して、下流の隣接から回収されます。
[RFC5063] also extends the Hello message to exchange information about the ability to support the RecoveryPath message.
[RFC5063]もRecoveryPathメッセージをサポートする機能についての情報を交換するHelloメッセージを拡張します。
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）Recovery_Labelオブジェクトを担持その上流隣接から受信し、Pathメッセージの助けを借りてそのRSVP状態を回復します。
3) For bidirectional LSPs, uses the Upstream_Label Object on the received Path message to recover the corresponding RSVP state.
3）双方向のLSPのために、対応するRSVP状態を回復するために受信したPathメッセージにUPSTREAM_LABELオブジェクトを使用します。
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の末尾でない場合に加えて、下流インタフェースの着信ラベルが再開ノードに転送状態から取得され、下流の近隣に送信されたPathメッセージにUPSTREAM_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オブジェクトとPathメッセージを送信します。
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.
新しいメッセージは[RFC5063]で導入されたRecoveryPathメッセージと呼ばれています。このメッセージは、バック再開ノードに最後に受信したPathメッセージの内容を伝えるために再起動ノードの下流の隣人によって送信されます。
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.
再起動するノードは、その上流隣接及び/又はその下流の隣接からRecoveryPathメッセージからRecovery_LabelオブジェクトとPathメッセージを受信します。再起動するノードの完全なRSVP状態では、これら二つのメッセージから回収することができます。
The following state can be recovered from the received Path message:
以下の状態では、受信したPathメッセージから回収することができます。
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（UPSTREAM_LABELオブジェクトからの）双方向LSPのための上り方向のラベルO（Recovery_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.
他のオブジェクトは、もともとパス上で交換し、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：二つの隣接ノードの再起動
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は、ノードを再起動されます。ノードDは、別々に、ノードCを介して再開することができつつ、ノードBは、ノードAとノード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状態は、ノードが、対応するPathメッセージ及び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においては、単一の状態ブロック（LSP状態ブロック）に情報を組み合わせることが可能であるので、パスとのResv状態との間ずっと近いタイがあります。ポイント・ツー・マルチポイントがサポートされている一方、別個の上流および下流の状態を維持するために便利です。 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状態が実装されている方法の、回復に回収し、これらは、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オブジェクトでPathメッセージを送信する必要があります。
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.
ノードAは通常ノードであるため、再起動ノード（この例ではノードB）では、上流隣接（ノードA）との完全な再同期が可能です。アップストリームパス情報は、Pathメッセージから回収され、また、明らかに、ノードAから受信したPathメッセージで運ばRecovery_Labelオブジェクトから（それが以前にノードAに送信されたこと）上流のResv情報を回復するが、ノードAのノードBから受信、（Recorded_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
[RFC5063]に従って、再開ノード（ノードB）は、通常、その下流隣接（ノードC）からRecoveryPathメッセージを受け取ることを期待します。これは、下流のパス情報を回復するために、これを使用し、その後、その下流の隣人にPathメッセージを送信し、Resvメッセージを受け取ることになります。下流の隣人がまだ再起動されていないので、しかし、このシナリオでは、ノードBは、との通信を検知します
Node C is interrupted and must wait before resynchronizing with its downstream neighbor.
ノード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]前Helloメッセージに基づいて、まだ再起動していないノード（ノード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をティアダウンするために使用されていない場合には、LSPは、上流ノード（ノードA）からPathTearを用いて、制御プレーンを介して片付けすることができます。ノードCは、この操作の後に再起動した場合、それはノードBに送信するRecoveryPathメッセージは、ノードB上の任意の状態と一致しないであろうと、すべての下流ノードにおけるLSPのティアダウンをもたらす、その応答としてPathTearを受信することに注意してください。
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）から完全下流状態を回復することができます。下流パス状態これは、ノードCがノードDへのパス更新メッセージを送信することができ、およびノードDは、ノードCが下流を復元することができ、そこからResvメッセージで応答するノードDによって送信されるRecoveryPathメッセージから回収することができます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]前Helloメッセージに基づいて、まだ再起動していないノード（ノード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をティアダウンするために使用されていない場合には、LSPは、上流ノード（ノードA）からPathTearを用いて、制御プレーンを介して片付けすることができません上流方向からノード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とノードDの下流に送信されるPathTearから除去されることになります
- 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.
- 管理アクションは、LSPの状態を引き裂くためにノードCに送信されるPath_State_Removedフラグが設定されたPathErrメッセージをもたらす、任意の下流ノード（例えば、ノードD）で採取されてもよいです。
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に送信するPathメッセージをノードC上の任意の状態に一致されず、LSPセットアップをもたらす、新たなPathメッセージとして扱われることに留意されたいです。ノードCは、そのラベル割り当てを駆動する（UPSTREAM_LABELオブジェクトおよびRecovery_Labelオブジェクトで）Pathメッセージで運ばれたラベルを使用すべきであるが、通常の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]で提案されている再起動時間の値が前回のHelloメッセージに基づいていること、しかし、注意してくださいまだ再起動していないノードと交換しました。これらの時間値は、再開ノード（ノード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.
下流の遅延再起動ノードがノードCでのLSPのクリーンアップ後に再起動した場合、ノードDからRecoveryPathメッセージはPathTearメッセージによって応答します。上流ノードCにおけるLSPのクリーンアップ後にノードを再起動を再起動遅延した場合、ノードBからのPathメッセージは、新しい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.
下流ノード（ノードB）は、通常のノードであればさらに、[RFC5063]の手順に従って、入口は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が再起動したことがない場合には、管理プレーンの介入は管理面から、またはローカル設定から復元されたすべてのLSP制御プレーンの状態をクリーンアップするために、および任意のデータ・プレーンのリソースを解放するためにノードAで必要とされています。
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オブジェクトを運ぶPathメッセージ内の情報を提供しなければなりません。
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状態を同期させるために回復ラベルでPATHメッセージを送信するために、その上流のノードを必要とします。再開制御プレーンはすぐに動作可能になった場合、上流のノードは、下流ノードの再起動を検出しないことと、そのため、エラーと不要な接続の削除を引き起こし、回復ラベルなしPATHメッセージを送信することができます。
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は、ハロー障害を検出し、SRefreshメッセージに対応するパスの状態が存在しないため、再起動が完了するとN2によってNACK'edれるかもしれSRefreshesを送信し続けていません。このNACKは、Pathリフレッシュメッセージが生成されますが、N1はまだこんにちは交換はまだ開始していないようN2は、再起動したことを検出していないので、何のRecovery_Labelはありません。 Pathメッセージは、「新しい」として扱われ、彼らはまだ使用中であるため、リソースの割り当てに失敗しています。このことは、LSPのティアダウンにつながる可能性が発生するのPathErrメッセージを引き起こします。
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
上記課題を解決するために、[RFC3473]及び[RFC5063]で暗黙である次の手順は、従うべきです。これらの手順は、[RFC3473]で文書の復旧手順と連携して動作します。ここでは、再起動することが想定されます
node and the neighboring node(s) support the Hello extension as documented in [RFC3209] as well as the recovery procedures documented in [RFC3473].
ノードと隣接ノード（S）[RFC3209]に記載されているようにハロー拡張をサポートするだけでなく、[RFC3473]に記載リカバリ手順。
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メッセージ（Helloメッセージを除く）をドロップしなければなりません。
The restarting node should follow [RFC3209] to establish Hello sessions with its neighbors, after its control plane becomes operational.
そのコントロールプレーンが動作になった後に再起動するノードは、その隣人とのHelloセッションを確立するために、[RFC3209]を従ってください。
The restarting node resumes processing of RSVP-TE messages sent from each neighbor to which the Hello session has been established.
再起動するノードは、こんにちはセッションが確立されているに各ネイバーから送信された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.
この文書は、その隣接一つ以上の再始動RSVP剤RSVPエージェント上で実行される[RFC3473]及び[RFC5063]で定義された手順を明確にしています。これは、任意の新しい手順を導入しないと、そのため、新たなセキュリティリスクや問題を導入しません。
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.
一つ以上のLSPを運ぶ1つ以上のノードが外的攻撃に再開され、一般に、制御プレーン、特にRSVP剤の場合には、この文書に[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
隣国から受けた懸念が偽のメッセージに再開ノードの脆弱性について表明されていることに注意してください。例えば、再開ノードが持つ偽のPathメッセージを受け取ることがあります
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:
上流隣接、又はその下流隣人から偽RecoveryPathメッセージからオブジェクトRecovery_Label。この状況は、4例1で発生する可能性：
- 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を送信した場合、そのメッセージが誤ったラベル値を運ぶGeneralized_Labelオブジェクトを搬送する場合、受信LSRは、供給された値を使用し、LSPが誤って設定されます。 Pathメッセージが宛先と明示的経路を変更する上流の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は、セキュアなエンド・ツー・エンドのチェックを適用することができたことにより、スコープを提供する[RFC2205]をオブジェクトPOLICY_DATAことに留意されたいです。しかし、このオブジェクトの使用はほとんどの定義は、これまでに行われています。
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.
私たちは彼らの有益なコメントをエードリアンファレル、ディミトリPapadimitriou、およびルー・バーガーに感謝したいと思います。
[RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997.
[RFC2209]ブレーデン、R.とL.チャン、 "資源予約プロトコル（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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "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]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（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.編、およびR.ラーマン、エド。、RFC 5063、2007年10月、 "GMPLSリソース予約プロトコル（RSVP）グレースフルリスタートへの拡張"。
[MPLS-SEC] Fang, L., "Security Framework for MPLS and GMPLS Networks", Work in Progress, November 2008.
[MPLS-SEC]牙、L.、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク"、進歩、2008年11月の作業。
[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]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411]セイヤー、R.、Doraswamy、N.、およびR.グレン、 "IPセキュリティドキュメントロードマップ"、RFC 2411、1998年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、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.、RFC 4835、2007年4月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）のための暗号アルゴリズム実装要件"。
Authors' Addresses
著者のアドレス
Dan Li Huawei Technologies F3-5-B R&D Center, Huawei Base, Shenzhen 518129, China
技術F3-5-BR＆DセンターとしてダンL IH UA、ベースのHU Aは、Sは、中国518129真であります
Phone: +86 755 28970230 EMail: danli@huawei.com
電話：+86 755 28970230 Eメール：danli@huawei.com
Jianhua Gao Huawei Technologies F3-5-B R&D Center, Huawei Base, Shenzhen 518129, China
G技術F3-5-BR＆DセンターとしてJイアン花ああUA OH、HU塩基のA、Sは518129真であり、中国
Phone: +86 755 28972902 EMail: gjhhit@huawei.com
電話：+86 755 28972902 Eメール：gjhhit@huawei.com
Arun Satyanarayana Cisco Systems 170 West Tasman Dr San Jose, CA 95134, USA
このようシスコシステムズ170西タスマン博士セン、95134、そのようアルンSatyanarayana
Phone: +1 408 853-3206 EMail: asatyana@cisco.com
電話：+1 408 853-3206 Eメール：asatyana@cisco.com
Snigdho C. Bardalai Fujitsu Network Communications 2801 Telecom Parkway Richardson, Texas 75082, USA
Snigdho C. Bardalai富士通ネットワークコミュニケーションズ2801テレコムパークウェイリチャードソン、テキサス州75082、USA
Phone: +1 972 479 2951 EMail: snigdho.bardalai@us.fujitsu.com
電話：+1 972 479 2951 Eメール：snigdho.bardalai@us.fujitsu.com