RFC 5063 - Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart 日本語訳

URL : https://tools.ietf.org/html/rfc5063
タイトル : RFC 5063 - GMPLSリソース予約プロトコル（RSVP）グレースフルリスタートの拡張
翻訳編集 : 自動生成

Network Working Group                              A. Satyanarayana, Ed.
Request for Comments: 5063                                R. Rahman, Ed.
Updates: 2961, 3473                                        Cisco Systems
Category: Standards Track                                   October 2007

        Extensions to GMPLS Resource Reservation Protocol (RSVP)
                            Graceful Restart

Status of This Memo

このメモのステータス

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

Abstract

抽象

This document describes extensions to the Resource Reservation Protocol (RSVP) Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted.

この文書は、RFC 3473.に拡張機能を定義されたメカニズムは、最後に再起動されるノードによって送信されたPathメッセージに基づいて、RSVPシグナリング状態の回復を可能リソース予約プロトコル（RSVP）グレースフルリスタートへの拡張を記述しています。

Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. Those mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects.

以前にデータプレーンは再起動を横切っ関連フォワーディング状態を保持したときに隣接ノードからの状態シグナリングの回復を可能にし、また、ノード障害からの回復と呼ばれるグレースフルリスタートメカニズムを、定義されました。これらのメカニズムは完全には入口ノードまたはすべてのRSVPオブジェクトの回復の状態の回復を知らせるサポートしていません。

The extensions defined in this document build on the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. Using these extensions, the restarting node can recover all previously transmitted Path state, including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node.

この文書で定義された拡張は、RSVPこんにちはRFC 3209で定義された拡張機能、およびこれらの拡張機能を使用してRFC 3473.で定義されたリンパ節障害の状態の回復のための拡張機能上に構築、再開ノードは、明示的経路オブジェクトを含むすべての以前に送信パスの状態を回復することができますそして下流（発信）インタフェース識別子。拡張機能は、また、入口ノードの再起動後の状態をシグナリング回復するために使用することができます。

These extensions are not used to create or restore data plane state.

これらの拡張機能は、データプレーンの状態を作成または復元するために使用されていません。

The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more Label Switched Paths (LSPs).

拡張機能は、必要に応じて再起動ノードは、1つ以上のラベルのローカル状態をシグナリングする回復したときに回復段階の間に交換されるメッセージの数を減らすためにRFC 2961で定義された概要リフレッシュの使用をサポートするパス（LSPを）スイッチ。

Table of Contents

   1. Introduction ....................................................3
   2. Conventions Used in This Document ...............................5
   3. Terminology .....................................................5
   4. Extensions to Nodal Fault Handling ..............................5
      4.1. RecoveryPath Message Format ................................5
      4.2. Capability Object ..........................................6
           4.2.1. Conformance .........................................7
      4.3. Related Procedures .........................................7
      4.4. Procedures for the Capability Object .......................8
           4.4.1. Procedures for the Downstream Neighbor ..............8
           4.4.2. Procedures for the Restarting Node ..................8
      4.5. Procedures for the RecoveryPath Message ....................9
           4.5.1. Procedures for the Downstream Neighbor ..............9
           4.5.2. Procedures for the Restarting Node .................10
                  4.5.2.1. Path and RecoveryPath Message Procedures ..11
                  4.5.2.2. Re-Synchronization Procedures .............12
                  4.5.2.3. Procedures on Expiration of
                           Recovery Period ...........................13
      4.6. Compatibility .............................................13
   5. RecoveryPath Summary Refresh ...................................14
      5.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects ...........15
      5.2. RecoveryPath Srefresh Capable Bit .........................16
           5.2.1. Procedures .........................................16
           5.2.2. Compatibility ......................................17
      5.3. RecoveryPath Summary Refresh Procedures ...................17
           5.3.1. Generation of RecoveryPath-Related Srefresh
                  Messages ...........................................17
           5.3.2. RecoveryPath-Related Srefresh Receive
                  Processing and NACK Generation .....................19
           5.3.3. RecoveryPath-Related MESSAGE_ID NACK
                  Receive Processing .................................19
   6. Security Considerations ........................................20
   7. Acknowledgments ................................................21
   8. IANA Considerations ............................................21
   9. Normative References ...........................................22

1. Introduction

1. はじめに

RSVP Graceful Restart is defined in [RFC3473] and uses mechanisms defined in [RFC3209]. When data/forwarding plane state can be retained across the restart of the RSVP agent that established such state, RSVP Graceful Restart provides the ability for the RSVP agent to resynchronize its state based on updates received from its neighboring RSVP agents, and, reconcile such state with the retained data/forwarding plane state. [RFC3209] describes a mechanism, using RSVP Hello messages, to detect the state of an adjacent RSVP agent. [RFC3473] extends this mechanism to advertise the capability of retaining data/forwarding plane state across the restart of a node or a "nodal fault". [RFC3473] also defines the Recovery Label object for use in the Path message of the RSVP neighbor upstream of a restarting node, to indicate that the Path message is for existing data plane state.

RSVPグレースフルリスタートは、[RFC3473]で定義されて、[RFC3209]で定義されたメカニズムを使用しています。データ/転送プレーンの状態は、このような状態を確立RSVPエージェントの再起動を横切って保持することができる場合には、グレースフルリスタートをRSVP更新に基づいて、その状態を再同期するRSVPエージェントの能力を提供し、そのような状態を調整、その隣接RSVPエージェントから受信し、及び保持されたデータ/転送プレーン状態に。 [RFC3209]は、隣接するRSVPエージェントの状態を検出するために、RSVP Helloメッセージを使用して、機構を記載しています。 [RFC3473]は、ノードまたは「ノード障害」の再起動を介してデータ/転送プレーンの状態を保持する能力をアドバタイズするためにこのメカニズムを拡張します。 [RFC3473]もPathメッセージは、データプレーン状態を既存のためのものであることを示すために、上流の再開ノードのRSVP隣人のPathメッセージで使用するための回復ラベルオブジェクトを定義します。

This document presents extensions to address two aspects of graceful restart not previously supported. The presented extensions enable a restarting node to recover all objects in previously transmitted Path messages, including the Explicit Route Object (ERO), from its downstream neighbors, thus recovering the control plane state. The extensions do not facilitate the recovery or creation of data/forwarding plane state, and can only be used to reestablish control plane state that matches in-place data/forwarding state. The extensions also enable graceful restart of an ingress node that does not preserve full RSVP state across restarts. The presented extensions are equally applicable to LSPs of various switching types as defined in [RFC3471].

この文書は、以前にサポートされていませんグレースフル・リスタートの二つの側面に対処するための拡張機能を提供します。提示の拡張は、このように、制御プレーンの状態を回復、その下流の近隣から、明示的ルート・オブジェクト（ERO）を含む、以前に送信されたPathメッセージ内のすべてのオブジェクトを回復するために再起動ノードを有効にします。拡張子は、平面状態を転送/データの回復または作成を容易にしていない、とだけインプレースデータ/フォワーディングステートに一致するコントロールプレーンの状態を再確立するために使用することができます。拡張子はまた、再起動しても、完全なRSVP状態が保持されない入口ノードのグレースフルリスタートを有効にします。 [RFC3471]で定義されるように提示される拡張機能は、様々なスイッチングタイプのLSPに等しく適用可能です。

Per [RFC3473], a restarting node can distinguish Path messages associated with LSPs being recovered by the presence of the Recovery Label object. To determine the downstream (outgoing) interface and associated label(s), the restarting node must consult the data plane. This may not be possible for all types of nodes. Furthermore, data plane information is not sufficient to reconstruct all previously transmitted Path state. In these cases, the only source of RSVP state is the downstream RSVP neighbor.

パー[RFC3473]は、再起動ノードが回復ラベルオブジェクトの存在によって回収されたLSPに関連したPathメッセージを区別することができます。下流側（発信）インターフェイス及び関連ラベル（複数可）を決定するために、再起動ノードは、データ・プレーンに相談しなければなりません。これは、ノードのすべてのタイプのためにできない場合があります。また、データプレーン情報は、すべての以前に送信されたパスの状態を再構築するのに十分ではありません。これらのケースでは、RSVP状態の唯一の源は、川下のRSVP隣人です。

For example, when the restarting node is an ingress node, all previously transmitted Path state may need to be recovered. Such Path state may include (but is not restricted to) the Protection object, the Admin Status object, the Session Attribute object, the Notify Request object, and the Sender Tspec object. A restarting transit node may have modified received Path state in its previously transmitted Path message, which cannot be reconstructed internally during recovery.

例えば、再起動ノードが入口ノードである場合、すべての以前に送信されたパスの状態が回復される必要があるかもしれません。このようなパスの状態は、保護対象、管理ステータスオブジェクト、セッション属性オブジェクト、通知Requestオブジェクト、および送信者のTSPECオブジェクトを含むこともできる（ただし、これらに限定されるものではありません）。再始動トランジットノードは、リカバリ中に内部で再構成することができない、その以前に送信Pathメッセージにおいて受信されたパスの状態を変更してもよいです。

Another example of state that cannot be completely recovered from the data plane in some cases is the previously transmitted ERO. Recovery of the previously transmitted ERO minimizes subsequent change of downstream LSP state. On a restarting ingress node, the ERO may have been based on configuration or the result of a previous path computation. A restarting transit node may have previously performed some form of path computation as a result of not receiving an ERO or receiving a loose hop in the ERO. In addition to the ERO, the restarting node may have modified other received Path state in its previously transmitted Path state, which cannot be reconstructed internally during recovery.

完全にいくつかのケースでは、データプレーンから回収することができない状態の別の例は、以前に送信EROあります。以前に送信EROの回収は下流LSP状態のその後の変化を最小限に抑えます。再開入口ノードに、EROは、構成または以前経路計算の結果に基づいてされていてもよいです。再始動トランジットノードは、以前にEROを受信するか、EROにルーズホップを受けていない結果として、経路計算のいくつかのフォームを行っていてもよいです。 EROに加えて、再起動ノードは、リカバリ中に内部的に再構成することができない、その以前に送信パス状態で他の受信されたパスの状態を変更してもよいです。

The defined extensions provide a restarting upstream node with all information previously transmitted by the node in Path messages. This is accomplished by the downstream RSVP neighbor sending a new message for every Path message it has previously received from the restarting node, after reestablishing RSVP communication with a restarted node that supports the recovery procedures defined in Section 4.5.2 of this document.

定義された拡張は、以前にPathメッセージ内のノードによって送信されたすべての情報を再起動し、上流ノードを提供しています。これは、それが以前にこのドキュメントのセクション4.5.2で定義された復旧手順をサポートして再開したノードとのRSVP通信を再確立した後、再起動ノードから受信したすべてのPathメッセージの新しいメッセージを送信し、下流のRSVP隣人によって達成されます。

The new message is called the RecoveryPath message. The message conveys the contents of the last received Path message back to the restarting node. The restarting node can use the RecoveryPath message, along with the state in the received Path message to associate control and data plane state and to validate the forwarding state with the state presented by the neighboring RSVP nodes.

新しいメッセージがRecoveryPathメッセージと呼ばれています。メッセージは、バック再開ノードに最後に受信したPathメッセージの内容を伝えます。再起動するノードは、制御及びデータプレーンの状態を関連付けると隣接RSVPノードによって提示された状態と転送状態を確認するために受信したPathメッセージにおける状態と共に、RecoveryPathメッセージを使用することができます。

The restarting node indicates its desire to receive and process the RecoveryPath message by including a new object called the Capability object with the RecoveryPath Desired bit set, in its Hello messages sent to the downstream RSVP neighbor. The downstream RSVP neighbor can indicate its ability to send RecoveryPath messages by including the Capability object with the RecoveryPath Transmit Enabled set in its Hello messages to the restarting node. Thus, both the restarting node and its RSVP neighbor, with the help of the Capability object, can detect if the RecoveryPath message extensions defined in this document can be used to recover signaling state after a restart.

再起動するノードが受信するようにその願望を示し、新しいオブジェクトを含めることによって、RecoveryPathメッセージを処理川下のRSVP隣人に送られたそのhelloメッセージには、RecoveryPath所望のビットがセットされた機能オブジェクトと呼ばれます。川下のRSVP隣人はRecoveryPath送信が再開ノードへのhelloメッセージに設定された有効にして機能オブジェクトを含むことにより、RecoveryPathメッセージを送信する能力を示すことができます。この文書で定義されたRecoveryPathメッセージの拡張が再起動した後の状態を知らせる回復するために使用することができるならばこのように、再起動ノードとそのRSVP隣人の両方が、機能オブジェクトの助けを借りて、検出することができます。

If the restarting node is a transit node, it will receive a Path message with a Recovery Label object from its upstream RSVP neighbor. In addition, the RecoveryPath message allows such transit nodes to reconstruct any state that was previously dynamically constructed by the node, e.g., ERO sub-objects. If the restarting node is an ingress node, all significant signaling state can be recovered based on the RecoveryPath message.

再起動するノードが中継ノードである場合は、その上流RSVP隣人からの回復ラベルオブジェクトにPathメッセージを受信します。また、RecoveryPathメッセージは、トランジットノードは、以前に動的ノード、例えば、EROサブオブジェクトで構成された任意の状態を再構築することを可能にします。再起動ノードが入口ノードである場合、すべての重要なシグナル伝達状態がRecoveryPathメッセージに基づいて回収することができます。

Selective transmission of the RecoveryPath message is supported by enhancing the Summary Refresh mechanisms defined in [RFC2961]. When Recovery Summary Refresh is supported, the restarting node can select the LSPs for which it would like to receive RecoveryPath messages. This is useful when the restarting node is able to locally recover the signaling state for a subset of the previously active LSPs.

RecoveryPathメッセージの選択的な送信は、[RFC2961]で定義されたサマリー・リフレッシュ・メカニズムを増強することによってサポートされています。復旧の概要リフレッシュがサポートされている場合は、再起動ノードは、それがRecoveryPathメッセージを受け取りたい対象のLSPを選択することができます。局所的に以前にアクティブLSPのサブセットのためのシグナリング状態を回復するために再起動ノードが可能である場合に有用です。

Restarting egress nodes, and Resv message processing are not impacted by the presented extensions, see [RFC3473] for details.

出口ノードを再起動し、Resvメッセージの処理が提示拡張機能の影響を受けていない、詳細は[RFC3473]を参照。

2. Conventions Used in This Document

この文書で使用される2.表記

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。

3. Terminology

3.用語

The reader is assumed to be familiar with the terminology defined in [RFC3209] and [RFC3473].

読者は[RFC3209]と[RFC3473]で定義される用語に精通しているものとします。

Throughout this document, the term "node", when used in the context of a restarting or restarted node, generally refers to the control plane component, which is the signaling controller for a data plane switch.

再起動または再起動ノードの文脈で使用される場合、本明細書を通して、用語「ノード」は、一般に、データプレーンスイッチのシグナリングコントローラである制御プレーンのコンポーネントを指します。

4. Extensions to Nodal Fault Handling

節点障害処理4.拡張

This section presents the protocol modifications to Section 9 of [RFC3473].

このセクションでは、[RFC3473]のセクション9にプロトコルの変更を提示します。

4.1. RecoveryPath Message Format

4.1. RecoveryPathメッセージフォーマット

The format of a RecoveryPath message is the same as the format of a Path message, as defined in [RFC3473], but uses a new message number (30) so that it can be identified correctly.

RecoveryPathメッセージのフォーマットは、[RFC3473]で定義されるように、Pathメッセージのフォーマットと同じであるが、それは正しく識別できるように、新たなメッセージ番号（30）を使用します。

      <RecoveryPath Message> ::= <Path Message>

The destination address used in the IP header of a RecoveryPath message MUST be the same as the destination address used in the IP header of the corresponding Resv message last generated by the sending node. Except as specified below, all objects in a RecoveryPath message are identical to the objects in the corresponding Path message last received by the sending node.

RecoveryPathメッセージのIPヘッダで使用される宛先アドレスは、最後の送信ノードによって生成された対応するResvメッセージのIPヘッダで使用される宛先アドレスと同じでなければなりません。以下に指定されている場合を除き、RecoveryPathメッセージ内のすべてのオブジェクトは、最後の送信ノードによって受信され、対応するPathメッセージ内のオブジェクトと同一です。

4.2. Capability Object

4.2. 能力オブジェクト

Capability objects are carried in RSVP Hello messages. The Capability object uses Class-Number 134 (of form 10bbbbbb) and C-Type of 1.

機能オブジェクトは、RSVP Helloメッセージで運ばれています。機能オブジェクトは、（フォーム10bbbbbbの）クラス番号134を使用し、1のC型。

The message format of a Hello message is modified to be:

Helloメッセージのメッセージ・フォーマットは、なるように修正されています。

      <Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
                          [ <RESTART_CAP> ] [ <CAPABILITY> ]

The format of a Capability object is:

機能オブジェクトの形式は次のとおりです。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             | Class-Num(134)|  C-Type  (1)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Reserved                        |T|R|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RecoveryPath Transmit Enabled (T): 1 bit

有効RecoveryPath送信（T）：1ビット

When set (1), indicates that the sending node is enabled to send RecoveryPath messages. Absence of the Capability object MUST be treated as if the T-bit is cleared (0).

（1）設定した場合、送信ノードがRecoveryPathメッセージを送信するために有効であることを示します。 Tビットがクリアされるかのように機能オブジェクトの不在（0）で処理しなければなりません。

RecoveryPath Desired (R): 1 bit

RecoveryPath所望の（R）：1ビット

When set (1), indicates that the sending node desires to receive RecoveryPath messages. Absence of the Capability object MUST be treated as if the R-bit is cleared (0).

（1）設定した場合、送信ノードがRecoveryPathメッセージを受信することを望むことを示しています。 Rビットがクリアされるかのように機能オブジェクトの不在（0）で処理しなければなりません。

RecoveryPath Srefresh Capable (S): 1 bit

RecoveryPath Srefresh可能な（S）：1ビット

When set (1), along with the R-bit, indicates that the sending node is capable of receiving and processing Srefresh messages with the RecoveryPath Flag set (1) in the MESSAGE_ID LIST object. Absence of the Capability object MUST be treated as if the S-bit is cleared (0). Related procedures are defined in Section 5.2.1.

設定されている場合（1）、Rビットとともに、送信ノードは、MESSAGE_IDリストオブジェクトでRecoveryPathフラグが設定（1）でSrefreshメッセージを受信して処理することが可能であることを示しています。 Sビットがクリアされるかのように機能オブジェクトの不在（0）で処理しなければなりません。関連手順は、5.2.1項で定義されています。

Reserved bits

予約ビット

Reserved bits MUST be set to zero on transmission and MUST be ignored on receipt.

予約ビットは、送信にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。

4.2.1. Conformance

4.2.1. 準拠

All nodes supporting the extensions defined in this document MUST be able to transmit, and properly receive and process RecoveryPath messages. All nodes MUST be able to set both the T and R bits. Both the T and R bits SHOULD be set (1) by default. A node MAY allow RecoveryPath message transmission and reception to be independently disabled based on local policy. When RecoveryPath message transmission is disabled, the T-bit MUST be set to zero (0). When RecoveryPath message reception is not desired, the R-bit MUST be set to zero (0).

この文書で定義された拡張をサポートするすべてのノードが送信することができ、かつ適切にRecoveryPathメッセージを受信して処理しなければなりません。すべてのノードは、TとRビットの両方を設定できなければなりません。両方のTとRビットは、デフォルトでは（1）に設定されるべきです。ノードがRecoveryPathメッセージの送受信は、独立して、ローカルポリシーに基づいて無効にすることを可能にすることができます。 RecoveryPathメッセージの送信を無効にすると、Tビットはゼロ（0）に設定しなければなりません。 RecoveryPathメッセージの受信を望まない場合、Rビットがゼロ（0）に設定しなければなりません。

Any node that supports the extensions defined in this document and sets the Refresh-Reduction-Capable bit [RFC2961] SHOULD support setting of the S-bit and support the mechanisms defined in Section 5.

この文書で定義された拡張機能をサポートし、リフレッシュ還元可能なビット[RFC2961]を設定する任意のノードは、Sビットの設定をサポートし、セクション5で定義されたメカニズムをサポートしなければなりません。

4.3. Related Procedures

4.3. 関連手順

This document does not modify existing procedures for sending and receiving RSVP Hello messages, as defined in [RFC3209], and the Restart_Cap object in RSVP Hello messages as defined in [RFC3473]. The procedures for control channel faults are defined in [RFC3473] and are not changed by this document.

この文書では、[RFC3209]で定義されるように、RSVP helloメッセージを送受信するための既存の手順を変更し、[RFC3473]で定義されているRSVP HelloメッセージでRestart_Capオブジェクトはありません。制御チャネルの障害のための手順は、[RFC3473]で定義され、この文書によって変更されません。

The presented extensions require the use of RSVP Hellos, as defined in [RFC3209], and the use of the Restart_Cap object extension as defined in [RFC3473]. The presented extensions address only "Nodal Faults" as defined in [RFC3473]. Control channel faults are fully addressed in [RFC3473].

提示拡張は[RFC3209]で定義されるように、RSVPハローズの使用を必要とし、[RFC3473]で定義されるようRestart_Capオブジェクト拡張の使用。 [RFC3473]で定義されて提示拡張子は「節点障害」を扱います。制御チャネルの障害は完全に[RFC3473]で扱われています。

Note: There are no changes to the procedures defined in Section 9.5.3 in [RFC3473] (Procedures for the Neighbor of a Restarting node). There are no changes to the procedures defined in Section 9.5.2 in [RFC3473] if the restarting node is an egress node.

注：[RFC3473]（再開ノードの近隣のための手順）で、セクション9.5.3で定義された手順に変更はありません。再開ノードが出口ノードである場合、[RFC3473]セクション9.5.2で定義された手順に変更はありません。

There are no changes to the procedures with respect to the data/forwarding plane as described in [RFC3473]. In particular, a restarting node MUST NOT create data/forwarding plane state as the result of any of the extensions defined in this document.

[RFC3473]に記載されているように、データ/転送面に対して手順の変更はありません。具体的には、再起動ノードは、この文書で定義された拡張機能のいずれかの結果として、平面状態を転送/データを作成してはいけません。

The following sections assume previously defined procedures are followed, except where explicitly modified.

以下のセクションでは、明示的に修飾された場合を除いて、先に定義された手順に従っていると仮定する。

4.4. Procedures for the Capability Object

4.4. 能力オブジェクトのための手順

4.4.1. Procedures for the Downstream Neighbor

4.4.1. ダウンストリームネイバーの手順

If a node is capable of sending RecoveryPath messages, it MUST include the Capability object with the RecoveryPath Transmit Enabled (T) bit set (1) in all its Hello messages.

ノードがRecoveryPathメッセージを送信することが可能である場合、それは、（1）すべてのハローメッセージ内に設定ビットRecoveryPath送信イネーブル（T）との機能オブジェクトを含まなければなりません。

If the downstream RSVP neighbor receives Hello messages from a restarting node, with the Restart_Cap object, as defined in [RFC3473], and with the Capability object with the RecoveryPath Desired (R) bit set (1), it MUST treat the restarting node as capable of receiving and processing RecoveryPath messages as defined in this document.

下流RSVP隣人はRestart_Capオブジェクトと、[RFC3473]で定義されるように、および（R）理想RecoveryPath有する機能オブジェクトと、再起動ノードからHelloメッセージを受信した場合（1）ビットセットは、のように再開ノードを扱わなければなりませんこの文書で定義されるように受信し、RecoveryPathメッセージを処理することができます。

If the downstream RSVP neighbor receives a Capability object in a Hello message with the RecoveryPath Desired (R) bit set (1), but without the Restart_Cap object, it MUST process the Hello message as if the RecoveryPath Receive Desired (R) bit is cleared (0) in the Hello message.

下流のRSVP隣人が（R）理想RecoveryPath有するHelloメッセージの機能オブジェクトを受信した場合（1）ビットセットが、RecoveryPathが望まれた場合（R）ビットがクリアされるようRestart_Capオブジェクトせず、それはHelloメッセージを処理しなければなりません（0）Helloメッセージインチ

If the downstream RSVP neighbor does not receive the Capability object in Hello messages sent by the restarting node or the RecoveryPath Desired (R) bit is cleared (0) in the Capability object, it MUST treat the restarting node as not capable of supporting the RecoveryPath message procedures defined in this document, and MUST revert to recovery procedures as defined in [RFC3473].

川下のRSVP隣人が再開ノードまたは所望のRecoveryPathにより送信されたHelloメッセージの機能オブジェクトを受信しない場合（R）ビットは（0）能力オブジェクトで、それはRecoveryPathをサポートすることができないとして、再起動ノードを扱わなければなりませんクリアされますメッセージ手順は、この文書で定義され、[RFC3473]で定義されるようにリカバリ手順に復帰しなければなりません。

4.4.2. Procedures for the Restarting Node

4.4.2. 再起動ノードのための手順

A node that expects to recover RSVP state by the receipt and processing of RecoveryPath messages according to procedures defined in this document, MUST include the Capability object with the RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to its neighbors. The node MUST also include the Restart_Cap object, as defined in [RFC3473], in all those Hello messages.

この文書で定義された手順に従ってRecoveryPathメッセージの受信および処理によってRSVP状態を回復することを期待ノードは、（1）そのRSVPハローその近隣へのメッセージに設定ビット（R）理想RecoveryPath有する機能オブジェクトを含まなければなりません。これらすべてのHelloメッセージに、[RFC3473]で定義されるように、ノードはまた、Restart_Capオブジェクトを含まなければなりません。

If the Recovery Time is zero (0) or the restarting node does not support/desire the use of RecoveryPath messages, the RecoveryPath Desired (R) bit MUST be cleared (0) in the Capability object included in Hello messages, or the Capability object MAY be omitted from Hello messages sent by the restarting node.

回復時間はゼロ（0）または再開ノードは/ RecoveryPathメッセージの使用を希望サポートしていない、RecoveryPath希望（R）ビットをクリアしなければならない（0）機能オブジェクトにHelloメッセージに含まれ、または機能オブジェクトである場合再開ノードによって送信されたHelloメッセージから省略されるかもしれません。

During the Recovery Period, if the restarting node receives Hello messages from a downstream RSVP neighbor with the RecoveryPath Transmit Enabled (T) bit set (1) in the Capability object and the Restart_Cap object, as defined in [RFC3473], it MUST treat the downstream RSVP neighbor as capable of sending RecoveryPath messages according to procedures defined in Section 4.5.1. If the restarting node expects to recover RSVP state by the receipt and processing of RecoveryPath messages, it MUST follow procedures defined in Section 4.5.2, with the downstream RSVP neighbor.

再起動ノード（T）が有効RecoveryPath送信下流RSVP隣人からHelloメッセージを受信した場合、[RFC3473]で定義されるように回復期間中、機能オブジェクトとRestart_Capオブジェクト（1）ビットセットは、治療しなければなりません4.5.1項で定義された手順に従ってRecoveryPathメッセージを送信するようなことが可能な下流のRSVP隣人。再開ノードがRecoveryPathメッセージの受信と処理によってRSVP状態を回復するために想定している場合、それは下流のRSVP隣人で、4.5.2項で定義された手順に従わなければなりません。

During the Recovery Period, if the restarting node receives Hello messages from a downstream RSVP neighbor with the RecoveryPath Transmit Enabled (T) bit cleared (0) in the Capability object, or, with the Capability object not present, it MUST treat the downstream RSVP neighbor as not capable of the RecoveryPath message procedures defined in this document, and, it MUST revert to the recovery procedures defined in [RFC3473] immediately, with the downstream RSVP neighbor.

再起動するノードは、（T）を有効RecoveryPath送信と下流のRSVP隣人からHelloメッセージを受信した場合の回復期間中、機能オブジェクトと、機能オブジェクトに（0）クリア、またはビット存在しない、それが下流のRSVPを扱わなければなりませんこのドキュメントで定義されたRecoveryPathメッセージ手順のできる、としない隣人、それが下流のRSVP隣人と、すぐに[RFC3473]で定義されたリカバリ手順に復帰しなければなりません。

4.5. Procedures for the RecoveryPath Message

4.5. RecoveryPathメッセージのための手順

4.5.1. Procedures for the Downstream Neighbor

4.5.1. ダウンストリームネイバーの手順

After a downstream RSVP neighbor has detected that its upstream node has restarted, is capable of recovery as defined in [RFC3473], and, is capable of receiving RecoveryPath messages as defined in Section 4.4, the downstream RSVP neighbor MUST send a RecoveryPath message for each LSP associated with the restarting node for which it has sent a Resv message. During the Recovery Period, if the downstream RSVP neighbor detects that the restarting node is not capable of receiving RecoveryPath messages by the absence of the Capability object or the RecoveryPath Desired (R) bit cleared (0) in the Capability object in the restarting node's Hello messages, the downstream RSVP neighbor SHOULD NOT send the RecoveryPath messages to the restarting node.

下流RSVP隣人がその上流のノードが再起動したことを検出した後、[RFC3473]で定義されるように回復することが可能であり、そして、セクション4.4で定義されるようにRecoveryPathメッセージを受信することができる、下流RSVP隣人は、それぞれについてRecoveryPathメッセージを送らなければなりませんそれはResvメッセージを送信したために再起動したノードに関連付けられたLSP。川下のRSVP隣人が再開ノードは、機能オブジェクトまたは（R）理想のRecoveryPathの不在によってRecoveryPathメッセージを受信できないことを検出した場合の回復期間中、再開ノードのHelloの機能オブジェクトに（0）ビットをクリアメッセージは、川下のRSVP隣人は再開ノードにRecoveryPathメッセージを送るべきではありません。

The RecoveryPath message is constructed by copying all objects from the last received associated Path message, with the following exceptions:

RecoveryPathメッセージは、次の例外を除いて、最後に受信した関連するPathメッセージからすべてのオブジェクトをコピーすることによって構築されます。

The MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects are not copied. Any MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects used in RecoveryPath messages are generated based on procedures defined in [RFC2961].

MESSAGE_ID、MESSAGE_ID_ACKとMESSAGE_ID_NACKオブジェクトがコピーされません。 RecoveryPathメッセージで使用される任意のMESSAGE_ID、MESSAGE_ID_ACKとMESSAGE_ID_NACKオブジェクトは[RFC2961]で定義された手順に基づいて生成されます。

The Integrity object is not copied. Any Integrity objects used in RecoveryPath messages are generated based on procedures defined in [RFC2747].

整合性のオブジェクトがコピーされません。 RecoveryPathメッセージで使用される任意のIntegrityオブジェクトは[RFC2747]で定義された手順に基づいて生成されます。

The RSVP Hop object is copied from the most recent associated Resv message sent to the restarted node for the LSP being recovered.

RSVPホップオブジェクトが回収されるLSPを再起動ノードに送信された最新の関連Resvメッセージからコピーされます。

In the sender descriptor, the Recovery Label object MUST be included, with the label value copied from the label value in the Label object in the most recent associated Resv message sent to the restarted node, for the LSP being recovered.

送信者の記述では、回復ラベルオブジェクトは、LSPが回収されているため、再開ノードに送信された最新の関連するResvメッセージ内のラベルオブジェクト内のラベル値からコピーされたラベル値に含まれなければなりません。

All other objects from the most recent received Path message MUST be included in the RecoveryPath message.

最も最近受信したPathメッセージから他のすべてのオブジェクトは、RecoveryPathメッセージに含まれなければなりません。

All RecoveryPath messages SHOULD be sent at least once within approximately 1/2 of the Recovery Time advertised by the restarted neighbor. If there are many LSPs to be recovered by the restarted node, the downstream RSVP neighbor should avoid sending RecoveryPath messages in a short time interval to avoid overloading the restarted node's CPU. Instead, it should spread the messages across 1/2 the Recovery Time interval. The range of Recovery Time is dependent on many factors including, but not limited to, the CPU processing power on the restarting node as well as the upstream and downstream neighbors, the amount of CPU available for processing RSVP recovery procedures, and the implementation specifics that affect the amount of time taken to verify the received recovery state against existing forwarding plane state. Such discussion is out of scope of this document.

すべてのRecoveryPathメッセージを再開隣人によってアドバタイズ回復時間の約1/2以内に少なくとも一度送ってください。再開したノードによって回収することが多くのLSPがある場合、下流のRSVP隣人が再開ノードのCPUの過負荷を避けるために、短い時間間隔でRecoveryPathメッセージを送信することは避けてください。代わりに、それは1/2のリカバリ時間間隔全体にメッセージを広める必要があります。回復時間の範囲は、以下を含む多くの要因に依存して、これらに限定されないが、再起動ノード上のCPUの処理能力、ならびに上流および下流の隣人、処理RSVP回復手順のために利用可能なCPUの量、および実装仕様その既存のフォワーディングプレーンの状態に対して受信回復状態を確認するためにかかる時間の量に影響を与えます。このような議論は、この文書の範囲外です。

After sending a RecoveryPath message and during the Recovery Period, the node SHOULD periodically resend the RecoveryPath message until it receives a corresponding response. A corresponding response is a Message ID acknowledgment or a Path message for the LSP the RecoveryPath message represents. Each such resend attempt is at the end of any Message ID rapid retransmissions, if the Message ID mechanism is used. If the Message ID mechanism is not in use, the period between resend attempts SHOULD be such that at least 3 attempts are completed before the expiry of 3/4 the Recovery Time interval. Each such resend attempt MUST treat the RecoveryPath message as a new message and update the MESSAGE_ID object according to procedures defined in [RFC2961]. Note, per [RFC3473], Resv messages are suppressed during this recovery period until a corresponding Path message is received.

それが対応する応答を受信するまでRecoveryPathメッセージを送信した後および回復期間中、ノードは、定期的にRecoveryPathメッセージを再送すべきです。対応する応答は、メッセージID確認またはRecoveryPathメッセージが表すLSPのパスメッセージです。メッセージIDメカニズムが使用されている場合、それぞれのそのような再送の試みは、任意のメッセージID急速な再送信の終わりです。メッセージIDの機構が使用されていない場合、再送試行の間の期間は、少なくとも3つの試みが3/4回復時間間隔の満了前に完了しているようなものであるべきです。このような各再送試行が新しいメッセージとしてRecoveryPathメッセージを処理し、[RFC2961]で定義された手順に従ってMESSAGE_IDオブジェクトを更新する必要があります。対応するPathメッセージが受信されるまでメモを、[RFC3473]あたり、RESVメッセージは、この回復期間中に抑制されます。

4.5.2. Procedures for the Restarting Node

4.5.2. 再起動ノードのための手順

These procedures apply during the "state recovery process" and "Recovery Period" as defined in Section 9.5.2 of [RFC3473]. Any RecoveryPath message received after the Recovery Period has expired SHOULD be matched against local LSP state. If matching fully resynchronized state is located, the node SHOULD send a Path message downstream. If non-resynchronized or no LSP state matching the RecoveryPath message is located, the restarted node MAY send a PathTear message constructed from the RecoveryPath message to expedite the cleanup of unrecovered RSVP and associated forwarding state downstream of the restarted node. The restarting node MUST NOT create data plane or forwarding state to match the received RecoveryPath message.

[RFC3473]のセクション9.5.2で定義されているこれらの手順は、「状態の回復プロセス」と「回復期」の間に適用されます。回復期間が終了した後に受信した任意のRecoveryPathメッセージは、ローカルのLSP状態と照合されるべきである（SHOULD）。一致完全再同期状態が配置されている場合、ノードは、下流のPathメッセージを送信すべきです。非再同期またはRecoveryPathメッセージに一致するLSPの状態が配置されていない場合、再起動ノードが再起動ノードの下流未回収RSVPのクリーンアップおよび関連する転送状態を迅速にRecoveryPathメッセージから構築PathTearメッセージを送信することができます。再開ノードは、データ・プレーンを作成したり、受信したRecoveryPathメッセージに一致するように状態を転送してはいけません。

The remaining procedures are broken down into three sub-sections. The term "resynchronized state", originally defined in [RFC3473], is used and modified in these sections. This term refers to LSP state that is fully recovered.

残りの手順は、三つのサブセクションに分解されます。元々[RFC3473]で定義された用語「再同期化状態」は、使用され、これらのセクションに修正されます。この用語は、完全に回復されたLSPの状態をいいます。

Signaling state may be recovered from sources other than the mechanisms defined in this document. The restarting node SHOULD consider signaling state as resynchronized for all such LSPs and follow corresponding procedures defined below. Further, recovery procedures defined below may be overridden by local policy.

シグナリング状態は、この文書で定義されたメカニズム以外の供給源から回収することができます。再起動するノードは、すべてのそのようなLSPのための再同期化のような状態をシグナリング考慮し、以下に定義される対応する手順に従うべきです。さらに、以下に定義する回復手順は、ローカルポリシーによって上書きされることがあります。

Again, there are no changes to the procedures defined in Section 9.5.2 in [RFC3473] if the restarting node is an egress node.

再度、再起動ノードが出口ノードである場合、[RFC3473]セクション9.5.2で定義された手順に変更はありません。

4.5.2.1. Path and RecoveryPath Message Procedures

4.5.2.1。パスとRecoveryPathメッセージ手順

When a node receives a RecoveryPath message during the Recovery Period, the node first checks if it has resynchronized RSVP state associated with the message. If there is resynchronized state, and when both reliable message delivery [RFC2961] is supported and a MESSAGE_ID object is present in the RecoveryPath message, the node MUST follow Message ID acknowledgment procedures, as defined in [RFC2961], and consider the message as processed. If there is resynchronized state and there is no MESSAGE_ID object or reliable message delivery [RFC2961] is not supported, the node SHOULD send a trigger Path message, and, consider the message as processed.

それはメッセージに関連付けられたRSVPの状態を再同期している場合、ノードは、回復期間中にノードを最初にチェックをRecoveryPathメッセージを受信した場合。そこに状態を再同期され、両方の信頼性の高いメッセージ配信[RFC2961]がサポートされ、MESSAGE_IDオブジェクトがRecoveryPathメッセージ内に存在する場合、ノードは[RFC2961]で定義されるように、メッセージID確認手順に従わなければならない、そして処理されたメッセージを検討します。再同期状態が存在するとNO MESSAGE_IDオブジェクトまたは信頼性のあるメッセージの配信がない場合は[RFC2961]がサポートされていない、ノードは、トリガPathメッセージを送ります、そして、処理されたメッセージを検討します。

If a non-resynchronized state is found or the node is the ingress, the node saves the information contained in the RecoveryPath message and continues with processing as defined in Section 4.5.2.2.

非再同期状態が見つからないか、ノードが入力されている場合、ノードはRecoveryPathメッセージに含まれる情報を保存し、セクション4.5.2.2で定義されるように処理を継続します。

If no associated RSVP state is found and the node is not the ingress node, the node saves the information contained in the RecoveryPath message for later use.

全く関連RSVP状態が見つからないとノードが入口ノードでない場合、ノードは、後で使用するためにRecoveryPathメッセージに含まれる情報を保存します。

Note the following modifies Section 9.5.2 of [RFC3473]:

[RFC3473]の以下の修正セクション9.5.2に注意してください。

When a node receives a Path message during the Recovery Period, the node first locates any RSVP state associated with the message. If resynchronized RSVP state is found, then the node handles this message according to previously defined procedures.

ノードは回復期間中Pathメッセージを受信すると、ノードは、最初のメッセージに関連付けられた任意のRSVP状態を突き止めます。再同期RSVP状態が検出された場合、そのノードは、以前に定義された手順に従って、このメッセージを処理します。

If a non-resynchronized state is found, the node saves the information contained in the Path message, including the Recovery_Label object, and continues with processing as defined in Section 4.5.2.2.

非再同期状態が検出された場合、ノードはRecovery_Labelオブジェクトを含むPathメッセージに含まれる情報を保存し、セクション4.5.2.2で定義されるように処理を継続します。

Per [RFC3473], if matching RSVP state is not found, and the message does not carry a Recovery_Label object, the node treats this as a setup for a new LSP, and handles it according to previously defined procedures.

[RFC3473]、一致RSVP状態が見つからない場合、メッセージが新しいLSPの設定としてRecovery_Labelオブジェクト、ノード扱い、これを運び、そして以前に定義された手順に従ってそれを処理しないこと。

If a matching RSVP state is not found and the message carries a Recovery_Label object, the node saves the information contained in the Path message, including the Recovery_Label object for later use.

マッチングRSVP状態が見つかり、メッセージがRecovery_Labelオブジェクトを搬送されていない場合、ノードは、後で使用するためRecovery_Labelオブジェクトを含むPathメッセージに含まれる情報を、保存します。

4.5.2.2. Re-Synchronization Procedures

4.5.2.2。再同期手順

After receipt of the RecoveryPath message and, for non-ingress LSPs, the corresponding Path message with a Recovery Label object, the restarting node SHOULD locate and associate corresponding forwarding state using the received information. The restarting node associates the corresponding active forwarding plane state from the following signaled information:

RecoveryPathメッセージと、非入口のLSPのために、回復ラベルオブジェクトと対応する経路メッセージを受信した後、再起動ノードが見つけと関連付ける受信された情報を使用して転送状態に対応するべきです。再起動ノード仲間は以下から対応するアクティブ転送プレーン状態情報をシグナリング。

The upstream data interface is recovered from the RSVP HOP object in the received Path message.

上りデータインターフェースは、受信したPathメッセージにRSVPホップオブジェクトから回収されます。

The label on the upstream data interface is recovered from the Recovery Label object in the received Path message. If the LSP is bidirectional, the label for the upstream direction is recovered from the Upstream Label object in the received Path message.

アップストリームデータインタフェース上のラベルには、受信したPathメッセージで回復ラベルオブジェクトから回収されます。 LSPが双方向である場合に、上り方向のラベルは、受信したPathメッセージで上流のラベルオブジェクトから回収されます。

The downstream data interface is recovered from the RSVP HOP object in the received RecoveryPath message.

下りデータインターフェースは、受信されたRecoveryPathメッセージにRSVPホップオブジェクトから回収されます。

The label on the downstream data interface is recovered from the Recovery Label object in the received RecoveryPath message. If the LSP is bidirectional, the label for the upstream direction is recovered from the Upstream Label object in the RecoveryPath message.

ダウンストリームデータインタフェース上のラベルは、受信されたRecoveryPathメッセージで回復ラベルオブジェクトから回収されます。 LSPが双方向である場合に、上り方向のラベルは、RecoveryPathメッセージで上流のラベルオブジェクトから回収されます。

If complete forwarding state is located, the restarted node MUST treat the LSP as resynchronized and MUST send a trigger Path message downstream. The Explicit Route object in the Path message SHOULD match the Explicit Route object received in the RecoveryPath message. In addition, the restarted node SHOULD recover state from the other objects received in the RecoveryPath message. Optimally, the resulting Path message should not cause any redundant or unnecessary reprocessing of state along the remaining downstream nodes. Ideally, except for MESSAGE_ID processing and recovery processing, the transmitted Path message will be treated as a refresh by the downstream RSVP neighbor (and hence, should not trigger any generation of Path messages with changed state further downstream).

完全な転送状態が配置されている場合、再起動ノードは、再同期としてLSPを処理しなければならないと下流トリガPathメッセージを送らなければなりません。 Pathメッセージに明示的経路オブジェクトは、RecoveryPathメッセージで受信された明示的経路オブジェクトと一致する必要があります。また、再起動ノードがRecoveryPathメッセージで受信した他のオブジェクトの状態を回復するべきです。最適には、得られたPathメッセージは、残りの下流のノードに沿った状態のいずれかの冗長又は不要な再処理を引き起こすべきではありません。理想的には、MESSAGE_ID処理と回復処理を除いて、送信されたPathメッセージは、下流RSVP隣人によってリフレッシュとして扱われる（したがって、さらに下流変更された状態とPathメッセージの生成をトリガするべきではありません）。

If no forwarding state is located, the node treats the received Path message as a setup request for a new LSP. The outgoing interface and label(s) indicated in the RecoveryPath message SHOULD be reused when possible. All other information contained in the RecoveryPath message MAY also be used. That is, forwarding state MUST NOT be created except after receipt of a Path message from upstream or, at an ingress node, the receipt of a command from the management plane. Further, the forwarding state created is subject to local policy and the information received from downstream in the RecoveryPath message is treated only as advisory.

全く転送状態が配置されていない場合、ノードは新しいLSPの設定要求として受信したPathメッセージを処理します。 RecoveryPathメッセージに示された発信インターフェイスおよびラベル（S）が可能な場合に再利用されるべきです。 RecoveryPathメッセージに含まれる他のすべての情報を使用することもできます。その状態は、上流または入口ノードでのPathメッセージ、管理プレーンからのコマンドの受信の受領後を除いて作成されてはいけません転送です。さらに、作成した転送状態は、ローカルポリシーに従うものとRecoveryPathメッセージに下流から受信した情報のみ顧問として扱われます。

4.5.2.3. Procedures on Expiration of Recovery Period

4.5.2.3。回復期間の満了の手順

There are several cleanup steps to follow at the end of the Recovery Period. At the end of the Recovery Period, any state that was installed as the result of a received RecoveryPath message that is not resynchronized SHOULD be discarded.

回復期間の終わりに従うようにいくつかのクリーンアップステップがあります。回復期間の終わりに、再同期されていない受信されたRecoveryPathメッセージの結果としてインストールされた任意の状態が廃棄されるべきです。

Any Path messages that were received containing a Recovery_Label that has not been resynchronized, MUST be treated as being received during the Recovery Period and processed as per [RFC3473].

再同期されていないRecovery_Labelを含む受信された任意のPathメッセージは、回復期間中に受信されているものとして扱われ、[RFC3473]に従って処理されなければなりません。

Per [RFC3473], any other state that is not resynchronized during the Recovery Period SHOULD be removed at the end of the Period.

[RFC3473]あたり、回復期間中に再同期されていない任意の他の状態は、期間終了時に除去しなければなりません。

4.6. Compatibility

4.6. 適合

This document introduces a new RSVP signaling message called the RecoveryPath message to be generated by the downstream RSVP neighbor of a restarting node. To advertise the capability of sending and receiving RecoveryPath messages, this document introduces the Capability object to be included in Hello messages by a restarting node and its downstream RSVP neighbors.

この文書では、再開ノードの下流RSVP隣人によって生成されるRecoveryPathメッセージと呼ばれる新しいRSVPシグナリング・メッセージを紹介します。 RecoveryPathメッセージを送受信する機能をアドバタイズするには、この文書には、再起動ノードとその下流のRSVP隣人によってHelloメッセージに含まれる機能オブジェクトを紹介します。

If a restarting node does not support the Capability object, it will discard the object, as the Class-Number is of the form 10bbbbbb, and revert to recovery processing as defined in [RFC3473]. The restarting node will not include the Capability object in its Hello messages. Hence, all downstream RSVP neighbors that detect that the restarting node is not capable of supporting the extensions defined in this document will not send the RecoveryPath messages to the restarting node and will revert to recovery processing as defined in [RFC3473].

再起動ノードが機能オブジェクトをサポートしていない場合、クラスの数がフォーム10bbbbbbであるように、それは、オブジェクトを破棄し、[RFC3473]で定義されるように回復処理に戻します。再起動するノードは、そのHelloメッセージの機能オブジェクトが含まれていません。したがって、再起動ノードは、この文書で定義された拡張機能をサポートすることができないことを検出し、すべての下流RSVP隣人が再開ノードにRecoveryPathメッセージを送信しないと[RFC3473]で定義されるように回復処理に戻ります。

If a downstream RSVP neighbor does not support the Capability object, it will discard the object received in Hello messages and revert to recovery processing as defined in [RFC3473]. The downstream RSVP neighbor will not include the Capability object in its Hello messages. Hence, the restarting node will detect that the downstream RSVP neighbor is not capable of supporting the extensions defined in this document and will revert to recovery processing as defined in [RFC3473].

川下のRSVP隣人が機能オブジェクトをサポートしていない場合、それはHelloメッセージで受信したオブジェクトを破棄し、[RFC3473]で定義されているリカバリ処理に戻ります。川下のRSVP隣人は、そのHelloメッセージの機能オブジェクトが含まれていません。したがって、再起動ノードは、下流のRSVP隣人がこの文書で定義された拡張機能をサポートすることができないことを検出して、[RFC3473]で定義されるように回復処理に戻ります。

5. RecoveryPath Summary Refresh

5. RecoveryPath概要更新

This section describes a mechanism to control which LSP state is communicated in RecoveryPath messages. This mechanism enhances the Summary Refresh mechanism defined in [RFC2961], and uses the RecoveryPath Srefresh Capable (S) bit in the Capability object, as defined in Section 4.2, carried in the Hello message defined in [RFC3209] and [RFC3473]. The described mechanism is referred to as RecoveryPath Summary Refresh.

このセクションでは、RecoveryPathメッセージで通信されるLSP状態を制御するための機構を記載しています。このメカニズムは、[RFC2961]で定義された概要リフレッシュ機構を高め、[RFC3209]及び[RFC3473]で定義されたHelloメッセージで運ばれ、セクション4.2で定義されるように、機能オブジェクトにRecoveryPath Srefresh可能な（S）ビットを使用します。説明されたメカニズムはRecoveryPath概要リフレッシュと呼ばれています。

Selective transmission of RecoveryPath messages is controlled much the same way transmission of Path or Resv messages is controlled with standard Summary Refresh, see [RFC2961]. In standard Summary Refresh, an Srefresh message is sent by a node to identify to its neighbor about Path and Resv state that is locally installed and available. The receiver of the Srefresh message can then attempt to locate matching Path and Resv state. If no matching state is found, the receiver can request that the missing state be sent to it by sending an Srefresh NACK to the sender of the Srefresh message. When the Srefresh NACK is received, the corresponding Path or Resv message is sent. MESSAGE_ID information is used to identify Path and Resv state in this process.

RecoveryPathメッセージを選択的に透過はパスまたはRESVメッセージの送信は、標準的な概要を更新して制御されているのとほぼ同じ方法で制御されて、[RFC2961]を参照してください。標準概要更新において、Srefreshメッセージは、パスとローカルにインストールされたResv状態及び利用可能な程度にそのネイバーに識別するために、ノードによって送信されます。 Srefreshメッセージの受信機は、次に、マッチングパスとのResv状態を見つけることを試みることができます。一致する状態が見つからない場合、受信機は、欠落している状態がSrefreshメッセージの送信者にSrefresh NACKを送信することによってそれに送信することを要求することができます。 Srefresh NACKが受信されると、対応するパスまたはResvメッセージが送信されます。 MESSAGE_ID情報は、この過程でパスとのResv状態を識別するために使用されます。

The mechanism described in this section extends the Summary Refresh process to the Path state that can be represented in RecoveryPath messages. In this case, the Srefresh messages represent previously received Path messages, rather than previously transmitted Path messages. This is the primary difference between standard Summary Refresh and RecoveryPath Summary Refresh described in this section.

このセクションで説明されたメカニズムはRecoveryPathメッセージに表すことができるパス状態に要約リフレッシュ処理を拡張します。この場合、Srefreshメッセージではなく、以前に送信されたPathメッセージよりも先に受信したPathメッセージを表します。これは、このセクションで説明する標準の概要更新とRecoveryPath概要更新の主な違いです。

When a node restarts, and is capable of supporting the mechanisms described in this section, it includes the Capability object with the RecoveryPath Desired (R) bit set and the RecoveryPath Srefresh Capable (S) bit set in Hello messages it sends to its RSVP neighbors.

ノードが再起動し、このセクションで説明するメカニズムをサポートすることができるが、それは（R）理想RecoveryPath有する機能オブジェクトを含む場合にビットセットとすることができるRecoveryPath Srefresh（S）は、そのRSVP隣人に送信するHelloメッセージに設定されたビット。

When a neighbor of the restarting node detects a restart (see [RFC3209]), it detects that the restarted node is capable of receiving RecoveryPath messages, as defined in Section 4.4, and that the restarted node is requesting RecoveryPath Srefresh messages by the RecoveryPath Srefresh Capable (S) bit set in the Capability object. When such an indication is found, the neighbor generates one or more Srefresh messages. Each message indicates the Path state that can be represented in a RecoveryPath message. Within such Srefresh messages, the Path state that can be represented in RecoveryPath messages is represented using MESSAGE_ID information, and this information is communicated within MESSAGE_ID LIST objects. To indicate that the MESSAGE_ID LIST object is for recovery purposes, a new flag is set in the MESSAGE_ID LIST object. This flag is called the RecoveryPath Flag and is defined below.

再開ノードの隣人が（[RFC3209]を参照）、再起動を検出すると、それはセクション4.4で定義されるように再開ノードは、RecoveryPathメッセージを受信することが可能であることを検出し、再開ノードがRecoveryPath SrefreshによってRecoveryPath Srefreshメッセージを要求していること可能な（S）ビットは、能力オブジェクトに設定されました。そのような指示が検出された場合、ネイバーは、一つ以上のSrefreshメッセージを生成します。各メッセージはRecoveryPathメッセージに表すことができるパスの状態を示しています。そのようなSrefreshメッセージ内に、RecoveryPathメッセージに表すことができるパス状態はMESSAGE_ID情報を使用して表現され、この情報は、MESSAGE_IDリストオブジェクト内に伝達されます。 MESSAGE_IDリストオブジェクトは、回復の目的であることを示すために、新しいフラグがMESSAGE_IDリストオブジェクトに設定されています。このフラグは、RecoveryPath旗と呼ばれ、以下に定義されます。

The restarted node can then use the Srefresh message and the MESSAGE_ID LIST object to try to identify matching transmitted Path state. The node identifies local state by matching Epoch and Message ID tuples against Path messages transmitted downstream prior to the restart.

再開ノードは、次に、マッチング伝送路状態を識別しようとするSrefreshメッセージとMESSAGE_IDリストオブジェクトを使用することができます。ノードが再起動する下流前に送信Pathメッセージに対するエポックとメッセージIDタプルを照合することによってローカル状態を識別する。

If matching state is located, then the restarted node operates as if a RecoveryPath message has been received, per Section 4.5.2. If no matching state can be located, the restarted node generates a Srefresh NACK, see Section 5.4 of [RFC2961]. The Srefresh NACK is also marked with the new RecoveryPath Flag to indicate that the NACK is related to RecoveryPath messages.

一致状態が存在する場合RecoveryPathメッセージは、セクション4.5.2あたり、受信されたかのように、その後、再起動ノードが動作します。一致する状態に配置できない場合、再起動ノードがSrefresh NACKを生成し、[RFC2961]のセクション5.4を参照。 Srefresh NACKは、NACKがRecoveryPathメッセージに関連していることを示すために新しいRecoveryPath旗が付いています。

Upon receiving a Srefresh NACK, the downstream node generates a RecoveryPath message for the Path state indicated by each entry in the MESSAGE_ID LIST. The procedures defined in Section 4 above are then followed by the restarted node and the downstream RSVP neighbor.

Srefresh NACKを受信すると、下流ノードは、MESSAGE_IDリストの各エントリが示すパスの状態のためのRecoveryPathメッセージを生成します。上のセクション4で定義された手順を再度開始ノードと下流RSVP隣人が続きます。

5.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects

5.1. MESSAGE_ID ACK / NACKとMESSAGE_ID LISTオブジェクト

The MESSAGE_ID ACK/NACK objects and the MESSAGE_ID LIST object, defined in [RFC2961], are updated by this document. A new bit within the existing Flags field of each object is defined. This bit indicates that the object carries MESSAGE_ID information related to Path state that can be recovered using RecoveryPath messages. The same flag value is used in all the objects for consistency.

[RFC2961]で定義されたMESSAGE_ID ACK / NACKオブジェクトとMESSAGE_IDリストオブジェクトは、このドキュメントによって更新されます。各オブジェクトの既存のフラグフィールド内の新しいビットが定義されています。このビットは、オブジェクトがRecoveryPathメッセージを使用して回収することができるパスの状態に関連MESSAGE_ID情報を運ぶことを示しています。同じフラグ値が一貫性のために、すべてのオブジェクトに使用されます。

MESSAGE_ID_ACK object MESSAGE_ID_NACK object

MESSAGE_ID_ACKオブジェクトMESSAGE_ID_NACKオブジェクト

See Section 4.3 of [RFC2961] for definition of other fields.

他のフィールドの定義については、[RFC2961]のセクション4.3を参照してください。

MESSAGE_ID LIST object

MESSAGE_ID LISTオブジェクト

See Section 5.1 of [RFC2961] for definition of other fields.

他のフィールドの定義については、[RFC2961]のセクション5.1を参照してください。

Flags: 8 bits

フラグ：8ビット

0x02: RecoveryPath Flag

0×02：RecoveryPath旗

Indicates that the associated object carries MESSAGE_ID information related to one or more Path messages that can be recovered using a RecoveryPath message.

関連するオブジェクトがRecoveryPathメッセージを使用して回収することができる1つ以上のPathメッセージに関連MESSAGE_ID情報を運ぶことを示しています。

5.2. RecoveryPath Srefresh Capable Bit

5.2. 復旧パスの更新が可能なビット

The Capability object and the RecoveryPath Srefresh Capable (S) bit are defined in Section 4.2.

機能オブジェクトとRecoveryPath Srefresh可能な（S）ビットは、セクション4.2で定義されています。

5.2.1. Procedures

5.2.1. 手順

To support the selective receipt of RecoveryPath messages as defined in this section, a restarting node MUST support the receipt and processing of RecoveryPath messages as defined in Section 4.5.2, and MUST indicate this capability by including the Capability object with the RecoveryPath Desired (R) bit set as defined in Section 4.4.2 in its Hello messages.

このセクションで定義されるようにRecoveryPathメッセージの選択的な受信をサポートするために、再起動ノードは、セクション4.5.2で定義されるようにRecoveryPathメッセージの受信と処理をサポートしなければならない、とRecoveryPath有する機能オブジェクトはR（必要含めることによってこの能力を示さなければなりませんそのHelloメッセージに4.4.2項で定義されている）ビットセット。

To indicate to an RSVP neighbor that selective transmission of RecoveryPath messages is desired, a node MUST set (1) the S-bit in the Capability object in all Hello messages it sends. When the restarting node does not desire the receipt of RecoveryPath messages (see Section 4.4.2) or the selective transmission mechanism defined in this section, it MUST clear (0) the S-bit in the Capability object if included in Hello messages.

RecoveryPathメッセージの選択的透過が所望されることRSVP隣人に示すために、ノードは、それが送信するすべてのHelloメッセージの機能オブジェクト（1）Sビットを設定しなければなりません。 Helloメッセージに含まれた場合に再起動ノードがRecoveryPathメッセージの受信を希望しない場合、またはこのセクションで定義された選択透過機構（セクション4.4.2を参照）、それは、能力オブジェクト内（0）Sビットをクリアしなければなりません。

The downstream RSVP neighbor checks the R-bit and the S-bit upon detecting a restart of a node that supports state recovery with RecoveryPath messages. Detection of neighbor restarts with state recovery using RecoveryPath messages is defined in Section 4. If both the R-bit and the S-bit are set, then the procedures defined below in Section 5.3.1 MUST be followed. If the S-bit is cleared, the downstream RSVP neighbor MUST revert to normal procedures defined in Section 4.5.1. If the R-bit is cleared, but the S-bit is set, the

下流RSVP隣人はRecoveryPathメッセージで状態の回復をサポートするノードの再起動を検出すると、RビットとSビットをチェックします。ネイバーの検出はRecoveryPathメッセージを使用して状態の回復をRビットとSビットの両方が設定されている場合、第5.3.1節で以下に定義された手順に従わなければならない第4項に定義されていると再開する。 Sビットがクリアされた場合に、下流RSVP隣人はセクション4.5.1で定義された通常の手順に復帰しなければなりません。 Rビットがクリアされますが、Sビットがセットされている場合は、

downstream RSVP neighbor MUST treat it as if the Capability object was received with the S-bit cleared. See Section 4.4 for handling of Hello messages without the Capability object.

Sビットがクリアで機能オブジェクトが受信されたかのように川下のRSVP隣人はそれを扱わなければなりません。能力オブジェクトなしHelloメッセージの取り扱いについては、セクション4.4を参照してください。

5.2.2. Compatibility

5.2.2. 適合

There are no compatibility issues introduced in the procedures defined in Section 5.2.1.

5.2.1項で定義された手順で導入された互換性の問題はありません。

The restarting node will detect that its neighbor does not support selective transmission of RecoveryPath messages when a RecoveryPath message is received prior to the receipt of a Srefresh message containing a MESSAGE_ID LIST object with the RecoveryPath Flag set (1). When this occurs, any received RecoveryPath messages MUST be processed as defined in Section 4.

再起動ノードがRecoveryPathメッセージがRecoveryPathフラグが設定されたMESSAGE_IDリストオブジェクトを含むSrefreshメッセージの受信前に受信されたときに、そのネイバーがRecoveryPathメッセージの選択的な送信をサポートしていないことを検出する（1）。これが発生すると、セクション4で定義されるように、任意の受信されたRecoveryPathメッセージを処理しなければなりません。

5.3. RecoveryPath Summary Refresh Procedures

5.3. RecoveryPath概要更新手続き

Related processing occurs in the following logical order:

関連の処理は、次の論理的な順序で発生します。

o Generation of RecoveryPath-related Srefresh messages

回復経路に関連する最新の情報に更新メッセージのOジェネレーション

o RecoveryPath-related Srefresh message receive processing and NACK generation

O回復経路に関連する最新の情報に更新メッセージを処理し、BACK世代を受け取ります

o Message ID NACK receive processing and generation of RecoveryPath messages

OメッセージID NACKはRecoveryPathメッセージの処理および生成を受け取ります

o Receive processing of RecoveryPath messages

O RecoveryPathメッセージの受信処理

Actual processing MAY result in the above occurring in an interlaced fashion when multiple LSPs are being recovered. Both the restarted node and the downstream RSVP neighbor MUST be able to process in this fashion.

複数のLSPが回収されているとき、実際の処理は、インターレース方式で発生する上記もたらし得ます。再開ノードと下流RSVP隣人の両方は、この様式で処理できなければなりません。

5.3.1. Generation of RecoveryPath-Related Srefresh Messages

5.3.1. RecoveryPath関連のSrefreshメッセージの生成

A neighbor of a restarting node generates one or more RecoveryPath-related Srefresh messages when the S-bit is set in the restarted node's Hello messages as described in Section 5.2.1. The procedures for generating an Srefresh message are defined in [RFC2961]. Only modifications to these procedures are described in this section. Also, Srefresh message transmit and receive processing may occur simultaneously during the Recovery Period and are not impacted by the procedures defined in this section.

5.2.1項で説明したようにSビットが再起動ノードのHelloメッセージに設定されているときに再開ノードの隣人は、一つ以上のRecoveryPath関連のSrefreshメッセージを生成します。 Srefreshメッセージを生成するための手順は、[RFC2961]で定義されています。これらの手順に対する唯一の修正は、このセクションに記載されています。また、Srefreshメッセージの送信および受信処理は、回復期間中に同時に発生することがあり、このセクションで定義された手順によって影響を受けません。

To generate RecoveryPath-related Srefresh messages, a node must identify which Path state can be represented in RecoveryPath messages and which Srefresh message or messages can be used to carry the related information. As previously mentioned, the Path state that can be represented in RecoveryPath messages is indicated in Srefresh messages using the MESSAGE_ID information from the most recently received Path message associated with the state.

RecoveryPath関連のSrefreshメッセージを生成するために、ノードがRecoveryPathメッセージに表すことができるパス状態及びSrefreshメッセージまたはメッセージは、関連情報を搬送するために使用することができる識別しなければなりません。先に述べたように、RecoveryPathメッセージに表すことができるパス状態は、状態に関連する最も最近に受信したPathメッセージからMESSAGE_ID情報を用いて、Srefreshメッセージに示されています。

After processing the S-bit as described in Section 5.2.1, the node identifies all state associated with Path messages received from the restarted neighbor. Only a Path state that has not been updated since the restart may be represented in the Srefresh messages. Received Path state containing a MESSAGE_ID object whose Epoch value matches the Epoch received in the most recent Hello message is considered as updated after the upstream neighbor has restarted. Such Path state MUST NOT be represented in the Srefresh messages. Each Srefresh message contains one or more MESSAGE_ID LIST objects. Each such MESSAGE_ID LIST object MUST have the RecoveryPath Flag set (1).

セクション5.2.1に記載したようにSビットを処理した後、ノードは、メッセージが再起動ネイバーから受信したパスに関連するすべての状態を識別する。再起動してから更新されていない唯一のパス状態がSrefreshメッセージで表現することができます。エポック値と一致するエポックは、上流の隣人が再起動した後に更新として考えられている最新のHelloメッセージで受信しMESSAGE_IDオブジェクトを含む受信パスの状態。このようなパスの状態がSrefreshメッセージで表現されてはなりません。それぞれのSrefreshメッセージは、1つまたは複数のMESSAGE_IDリストオブジェクトが含まれています。このような各MESSAGE_IDリストオブジェクトは、RecoveryPathフラグが設定（1）が必要。

Multiple MESSAGE_ID LIST objects MAY be included in order to accommodate multiple Epoch values. The MESSAGE_ID LIST objects represent the identified, non-updated, Path state. A Message_Identifier field created for each identified, non-updated Path state MUST be included in an appropriate MESSAGE_ID LIST object. The Message_Identifier field is created based on the MESSAGE_ID object from the most recently received Path message associated with identified Path state. If any identified Path state does not have an associated MESSAGE_ID object, this state MUST be processed as defined above in Section 4.5.1.

複数のMESSAGE_IDリストオブジェクトは、複数のエポック値に対応するために含まれるかもしれません。 MESSAGE_ID LISTのオブジェクトが識別、非更新、パスの状態を表しています。識別されたそれぞれのために作成Message_Identifierフィールド、非更新パス状態は、適切なMESSAGE_IDリストオブジェクトに含まれなければなりません。 Message_Identifierフィールドが識別されたパスの状態に関連する最も最近受信したPathメッセージからMESSAGE_IDオブジェクトに基づいて作成されます。任意の識別されたパスの状態は、関連MESSAGE_IDオブジェクトを持っていない場合、セクション4.5.1に上記で定義され、この状態が処理されなければなりません。

The source IP address for the Srefresh message SHOULD be the source IP address in the IP header of the corresponding Resv messages previously sent to the restarted node. The Srefresh message SHOULD be destined to the IP address in the HOP object in the corresponding Path messages. This may result in multiple Srefresh messages being generated. Per [RFC2961], implementations may choose to limit each Srefresh message to the MTU size of the outgoing link, and to not bundle Srefresh messages. RecoveryPath-related Srefresh messages SHOULD be sent using reliable delivery, as defined in [RFC2961].

Srefreshメッセージの送信元IPアドレスが以前に再開ノードに送信された対応するRESVメッセージのIPヘッダ内の送信元IPアドレスでなければなりません。 Srefreshメッセージは、対応するPathメッセージでHOPオブジェクト内のIPアドレス宛てれるべきです。これは、生成された複数のSrefreshメッセージが表示されることがあります。 [RFC2961]あたり、実装は、発信リンクのMTUサイズに各Srefreshメッセージを制限することを選択することができる、とSrefreshメッセージをバンドルしないように。 [RFC2961]で定義されるようにRecoveryPath関連のSrefreshメッセージは、信頼できる配信を使用して送信されるべきです。

During the Recovery Period, unacknowledged RecoveryPath-related Srefresh messages SHOULD be periodically transmitted. The retransmission algorithm used can be the same algorithm used for retransmitting RecoveryPath messages during the Recovery Period (see Section 4.5.1). Note that prior to each such periodic retransmission, the Srefresh message SHOULD be updated to exclude the Message ID's of Path state that has been updated by the receipt of a Path message.

回復期間中、未確認RecoveryPath関連のSrefreshメッセージが定期的に送信されるべきである（SHOULD）。回復期間中RecoveryPathメッセージを再送信するために使用同じアルゴリズム可能使用再送アルゴリズムは、（4.5.1項を参照してください）。その前に、このような各定期的な再送信に注意し、SrefreshメッセージはPathメッセージの受信によって更新されたメッセージのパス状態のIDを除外するために更新する必要があります。

To allow sufficient processing time for the restarted node, the downstream RSVP neighbor MAY choose to generate multiple RecoveryPath-related Srefresh messages containing partial but mutually exclusive sets of Message Identifiers spread across 1/4 of the Recovery Time advertised by the restarted node.

再開ノードのための十分な処理時間を可能にするには、川下のRSVP隣人は、メッセージ識別子の部分が、相互に排他的なセットを含む複数のRecoveryPath関連のSrefreshメッセージ再開したノードによってアドバタイズ回復時間の1/4に広がっ生成するのに選ぶかもしれません。

5.3.2. RecoveryPath-Related Srefresh Receive Processing and NACK Generation

5.3.2. 回復パス関連のリフレッシュ処理とBACK世代を受け取ります

Upon receiving an Srefresh message containing a MESSAGE_ID LIST object with the RecoveryPath Flag set), the restarted node attempts to locate matching previously transmitted Path state. The Epoch in the MESSAGE_ID LIST object, along with each Message Identifier in the object, is used to match against the MESSAGE_ID object in Path messages previously transmitted to the downstream RSVP neighbor. For each Message Identifier in the MESSAGE_ID LIST:

）RecoveryPathフラグが設定されたMESSAGE_IDリストオブジェクトを含むSrefreshメッセージを受信すると、再開ノードは、以前に送信されたパスの状態を一致見つけよう。 MESSAGE_IDリストオブジェクト内のエポックは、オブジェクト内の各メッセージ識別子とともに、先に下流RSVP隣人に送信PathメッセージでMESSAGE_IDオブジェクトに対して一致させるために使用されます。 MESSAGE_IDリスト内の各メッセージ識別子のための：

If matching transmitted Path state is found, the restarting node treats the corresponding LSP state as having received and processed a RecoveryPath message and perform any further processing necessary as defined in Section 4.5.2. Specifically, it MUST generate a trigger Path message for the LSP as defined in Section 4.5.2.2. The restarted node MAY spread the transmission of such trigger Path messages across 1/2 of the remaining Recovery Period to allow the downstream RSVP neighbor sufficient processing time.

送信パス状態に一致することが見出された場合、再起動ノードは、受信したように、対応するLSPの状態を扱い、RecoveryPathメッセージを処理し、セクション4.5.2で定義されるように必要な更なる処理を行います。セクション4.5.2.2で定義されるように具体的には、LSPのトリガPathメッセージを生成しなければなりません。再開ノードは、下流のRSVP隣人十分な処理時間を可能にするために、残りの回復期間の1/2を横切ってそのようなトリガPathメッセージの送信を拡散することができます。

If matching transmitted Path state is not found, the restarting node MUST generate a MESSAGE_ID NACK as defined in [RFC2961]. Each generated MESSAGE_ID NACK MUST have the RecoveryPath Flag set (1).

マッチング伝送路状態が見つからない場合は[RFC2961]で定義されるように、再起動ノードは、MESSAGE_ID NACKを生成しなければなりません。各生成されたMESSAGE_ID NACKはRecoveryPathフラグが設定（1）が必要。

It is recommended that the restarted node combine multiple such MESSAGE_ID NACKs into a single ACK message, per [RFC2961].

再起動ノードは[RFC2961]あたり、単一のACKメッセージに、複数のそのようなMESSAGE_ID NACKを組み合わせることをお勧めします。

5.3.3. RecoveryPath-Related MESSAGE_ID NACK Receive Processing

5.3.3. RecoveryPath関連MESSAGE_ID NACKは、受信処理

This section defines the procedures associated with the processing of received MESSAGE_ID NACKs that have the RecoveryPath Flag set (1). Procedures for processing of MESSAGE_ID NACKs without the RecoveryPath Flag present are defined in [RFC2961] and not modified in this document. Processing of MESSAGE_ID NACKs with the RecoveryPath Flag set (1) also follows procedures defined in [RFC2961] unless explicitly modified in this section.

このセクションでは、RecoveryPathフラグが設定（1）を有する受信MESSAGE_ID NACKの処理に関連する手順を定義します。 RecoveryPathフラグが存在しないMESSAGE_ID NACKの処理の手順は、[RFC2961]で定義されており、本書では変更されません。 RecoveryPathフラグが設定（1）とMESSAGE_ID NACKの処理はまた、明示的にこのセクションで変更しない限り、[RFC2961]で定義された手順に従います。

For each MESSAGE_ID NACK with the RecoveryPath Flag set (1), the downstream RSVP neighbor must locate the matching received Path message. If a matching Path message is found, the downstream RSVP neighbor MUST generate a RecoveryPath message as defined in Section 4.5.1. If a matching Path message is not found, the MESSAGE_ID NACK is ignored. An example where this may occur is when the restarted node has already generated an updated Path message after its restart.

RecoveryPathフラグが設定（1）各MESSAGE_ID NACKのために、下流のRSVP隣人はマッチング受信したPathメッセージを見つけなければなりません。マッチングPathメッセージが見つかった場合は、セクション4.5.1で定義されるように、下流RSVP隣人はRecoveryPathメッセージを生成しなければなりません。マッチングPathメッセージが見つからない場合は、MESSAGE_ID NACKは無視されます。再起動ノードが既に再起動後に更新されたPathメッセージを生成したときに、これが発生する可能性例です。

6. Security Considerations

6.セキュリティの考慮事項

This document introduces a new RSVP message that is restricted to one RSVP hop. This document introduces no new security considerations beyond those already addressed for existing RSVP hop-by-hop messages.

この文書では、1つのRSVPホップに制限されている新しいRSVPメッセージを紹介します。この文書では、既存のRSVPホップバイホップのメッセージに対処したものを超えてどんな新しいセキュリティ問題も紹介しません。

This document introduces a new RSVP object to be included in RSVP Hello messages. This document introduces no new security considerations beyond those already addressed for existing objects in RSVP Hello messages.

この文書では、RSVP Helloメッセージに含まれる新しいRSVPオブジェクトを紹介します。この文書は、既にRSVP Helloメッセージ内の既存のオブジェクトのために対処したものを超えてどんな新しいセキュリティ問題も紹介しません。

This document introduces new procedures to be performed on RSVP agents that neighbor a restarting RSVP agent. In situations where the control plane in general, and the RSVP agent in particular, of a node carrying one or more LSPs is restarted due to external attacks, the procedures introduced in this document provide the ability for the restarting RSVP agent to recover the RSVP state corresponding to the LSPs with the least possible perturbation to the rest of the network. Ideally, only the neighboring RSVP agents should notice the restart and hence 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.

この文書では、隣接再開RSVPエージェントRSVPエージェント上で実行される新しい手順を紹介します。一つ以上のLSPを搬送するノードの一般に制御プレーン、特にRSVP剤は、外的攻撃に再起動される状況では、この文書に導入手順は、RSVP状態を回復するために再起動RSVPエージェントの能力を提供しますネットワークの他の部分に最小限の摂動でのLSPに対応します。理想的には、唯一の隣接RSVPエージェントは再起動に気づく、したがって追加の処理を実行する必要がなければなりません。これは、データ/転送プレーンの状態を乱すことなく、外部からの攻撃から正常LSPの状態を回復するためにアクティブのLSPを使用してネットワークを可能にします。

[RFC2747] provides mechanisms to protect against external agents compromising the RSVP signaling state in an RSVP agent. These mechanisms, when used with the new message and procedures introduced in this document, provide the same degree of protection to the restarting RSVP agent against installing compromised signaling state from an external agent during its RSVP signaling state recovery.

[RFC2747]はRSVPエージェントの状態をRSVPシグナリングを損なう外部物質から保護するためのメカニズムを提供します。新しいメッセージと、この文書に導入手順を使用した場合、これらのメカニズムは、そのRSVPシグナリング状態の回復中に外部エージェントから損なわシグナリング状態をインストールに対して再開RSVP剤に対する保護の同程度を提供します。

Note that the procedures assume a full trust model between RSVP neighbors. That is, although the protocol exchanges before and after restart can be secured, and although it is possible to authenticate the identity of the neighbors, no mechanism is provided to verify that the restart information is correctly mapped from the protocol information exchanged before the restart. This is considered acceptable because a similar trust model is required for normal operation of the protocol.

手順はRSVP隣人との間に完全な信頼モデルを前提としています。それは、再起動前と後のプロトコル交換を確保することができるが、であり、それは隣人の身元を認証することは可能であるが、メカニズムは、再起動情報が正しく再起動する前に、交換プロトコル情報からマッピングされていることを確認するために提供されていません。同様の信頼モデルがプロトコルの正常動作のために必要とされるので、これは許容できると考えられます。

The procedures defined in this document introduce additional processing overhead for the RSVP agents that neighbor a restarting RSVP agent. If an RSVP agent restarts due to external attacks, such added processing on the neighboring RSVP agents may impact their ability to perform other control plane tasks, including any processing for other LSPs that do not involve the restarting node. Such impact can be minimalized by the restarting RSVP agent using a large enough Recovery Time, so that its neighbors are provided sufficient time to handle the additional processing involved while continuing to perform their other control plane functions normally during the Recovery Period.

この文書で定義された手順は、隣接再開RSVPエージェントRSVPエージェントの追加の処理オーバーヘッドをご紹介します。 RSVP剤が外的攻撃を再開した場合、隣接RSVPエージェントにそのような追加の処理が再開ノードを伴わない他のLSPのための任意の処理を含む他の制御プレーンのタスクを実行する能力に影響を与える可能性があります。その隣には回復期間中、通常、それらの他の制御プレーン機能を実行し続けながら関与する追加の処理を扱うために十分な時間を提供するようにそのような影響は、十分に大きな回復時間を使用して再起動RSVPエージェントによってminimalizedすることができます。

Note that the procedures defined in this document cannot be used to create false forwarding state. The restarting node that receives a RecoveryPath message that does not match the existing forwarding state MUST NOT create or modify its forwarding state to match. A restarting node SHOULD log such an event or otherwise notify the operator since it might represent an attack.

この文書で定義された手順は、偽の転送状態を作成するために使用することができないことに注意してください。既存の転送状態と一致しないRecoveryPathメッセージを受信した再起動ノードが一致するようにフォワーディングステートを作成または変更してはいけません。再開ノードは、イベントログまたはそれ以外の場合は、攻撃を表すかもしれないので、オペレータに通知すべきです。

7. Acknowledgments

7.謝辞

The authors would like to thank participants of the CCAMP WG for comments and suggestions. Also thanks to Arthi Ayyangar, Adrian Farrel, Nick Neate, and Pavan Beeram for their helpful comments and feedback.

著者は、コメントや提案をCCAMP WGの参加者に感謝したいと思います。また、彼らの有益なコメントやフィードバックのためArthi Ayyangar、エードリアンファレル、ニックNeate、およびPavan Beeramのおかげ。

Derek Atkins provided useful discussion during SecDir review. Sam Hartman gave careful scrutiny of the security considerations and the potential impact on the RSVP-TE security trust model.

デレク・アトキンスはSecDirレビューの間に有用な議論を提供します。サム・ハートマンは、セキュリティ上の考慮事項を慎重に精査し、RSVP-TEのセキュリティ信頼モデルへの潜在的な影響を与えました。

Adrian Farrel edited the final revisions of this document as it progressed through IESG review.

それはIESGのレビューを通じて進行するにつれて、エードリアンファレルは、このドキュメントの最後のリビジョンを編集しました。

8. IANA Considerations

8. IANAの考慮事項

[RFC2205] defines the Class-Number name space for RSVP objects. The name space is managed by IANA.

[RFC2205]はRSVPオブジェクトのためのクラス数の名前空間を定義します。名前空間はIANAによって管理されています。

A new RSVP object using a Class-Number of form 10bbbbbb called the Capability Object is defined in Section 4.2 in this document. The Class-Number is 134.

機能オブジェクトと呼ばれる10bbbbbbフォームのクラス数を使用して、新しいRSVPオブジェクトは、このドキュメントのセクション4.2で定義されています。クラス数は134です。

A new RSVP message type called a RecoveryPath message is defined in Section 4.1 of this document. The RSVP message type is 30.

RecoveryPathメッセージと呼ばれる新しいRSVPメッセージタイプは、このドキュメントのセクション4.1で定義されています。 RSVPメッセージタイプが30です。

This document creates a new name space in the Capability object defined in Section 4.2. The new name space is a 32-bit-wide field. New registrations in this name space are to be allocated by IANA through an IETF Consensus action, per [RFC2434]. IANA also serves as the repository for this name space.

この文書は、セクション4.2で定義された機能オブジェクトに新しい名前空間を作成します。新しい名前空間は32ビット幅のフィールドです。この名前空間の新規登録は、[RFC2434]あたりのIETF Consensus動作でIANAによって割り当てられることになっています。 IANAはまた、この名前空間のためのリポジトリとして機能します。

Section 4.2 defines the following bits in the 32-bit field of the Capability Object (134):

セクション4.2は、機能オブジェクト（134）の32ビットのフィールドで、次のビットを定義します。

RecoveryPath Transmit Enabled (T): 1 bit RecoveryPath Desired (R): 1 bit RecoveryPath Srefresh Capable (S): 1 bit

有効RecoveryPath送信（T）：1ビットRecoveryPath所望の（R）：1ビットRecoveryPath Srefresh可能な（S）：1ビット

9. Normative References

9.引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.

[RFC2205]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。

[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.

[RFC2747]ベーカー、F.、リンデル、B.、およびM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。

[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.

[RFC2961]バーガー、L.、ガン、D.、ツバメ、G.、パン、P.、Tommasi、F.、及びS. Molendini、 "RSVPリフレッシュオーバーヘッド削減拡張"、RFC 2961、2001年4月。

[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。

[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.

[RFC3471]バーガー、L.、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。

[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

[RFC3473]バーガー、L.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。

Editors' Addresses

エディタのアドレス

Arun Satyanarayana (editor) Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 USA Phone: +1 408 853 3206 EMail: asatyana@cisco.com

アルンSatyanarayana（エディタ）は、シスコシステムズ、株式会社170西タスマン博士サンノゼ、CA 95134 USA電話：+1 408 853 3206 Eメール：asatyana@cisco.com

Reshad Rahman (editor) Cisco Systems, Inc. 2000 Innovation Dr. Kanata, Ontario K2K 3E8 Canada Phone: 613 254 3519 EMail: rrahman@cisco.com

Reshadラーマン（エディタ）は、シスコシステムズ、株式会社2000年イノベーション博士カナタ、オンタリオK2K 3E8カナダ電話：613 254 3519 Eメール：rrahman@cisco.com

Authors' Addresses

著者のアドレス

Dimitri Papadimitriou Alcatel Francis Wellesplein 1 B-2018 Antwerpen Belgium Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel-lucent.be

ディミトリPapadimitriouアルカテルフランシスVellesplein 1 B-2018アントワープ、ベルギー電話：+ X2 3 240から8491 Eメール：δημήτρη.παπαδημητρίου@αλκατελ-λυκεντ.βε

Lou Berger LabN Consulting, L.L.C. Phone: +1 301 468 9228 EMail: lberger@labn.net

ルー・バーガーLabNコンサルティング、L.L.C.電話：+1 301 468 9228 Eメール：lberger@labn.net

Anca Zamfir Cisco Systems, Inc. 2000 Innovation Dr. Kanata, Ontario K2K 3E8 Canada Phone: 613 254 3484 EMail: ancaz@cisco.com

ANCA Zamfirシスコシステムズ株式会社2000年イノベーション博士カナタ、オンタリオK2K 3E8カナダ電話：613 254 3484 Eメール：ancaz@cisco.com

Junaid Israr Cisco Systems, Inc. 2000 Innovation Dr. Kanata, Ontario K2K 3E8 Canada Phone: 613 254 3693 EMail: jisrar@cisco.com

Junaid Israrシスコシステムズ株式会社2000年イノベーション博士カナタ、オンタリオK2K 3E8カナダ電話：613 254 3693 Eメール：jisrar@cisco.com

Full Copyright Statement

完全な著作権声明

著作権（C）IETFトラスト（2007）。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。