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

原文URL : https://datatracker.ietf.org/doc/html/rfc5063
タイトル : RFC 5063 - GMPLSリソース予約プロトコル（RSVP）の優雅な再起動への拡張
翻訳編集 : 自動生成

[要約] 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

GMPLSリソース予約プロトコル（RSVP）の優雅な再起動への拡張

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で定義されているリソース予約プロトコル（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.

NODAL断層からの回復とも呼ばれる以前に定義されていた優雅な再起動メカニズムは、データプレーンが再起動全体で関連する転送状態を保持している場合、隣接するノードからのシグナリング状態の回復を可能にします。これらのメカニズムは、すべての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.

このドキュメントで定義されている拡張機能は、RFC 3209で定義されたRSVP Hello Extensionsと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).

拡張機能はオプションで、RFC 2961で定義されている要約リフレッシュの使用をサポートし、再起動ノードが1つ以上のラベルスイッチ付きパス（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 Graceful Restartは[RFC3473]で定義され、[RFC3209]で定義されているメカニズムを使用します。そのような状態を確立したRSVPエージェントの再起動全体にデータ/転送面の状態を保持できる場合、RSVP Graceful Restartは、RSVPエージェントが隣接するRSVPエージェントから受け取った更新に基づいて状態を再同期させる能力を提供し、そのような状態を調整する能力を提供します保持されたデータ/転送面の状態。[RFC3209]は、RSVP Helloメッセージを使用して、隣接するRSVPエージェントの状態を検出するメカニズムを説明しています。[RFC3473]は、このメカニズムを拡張して、ノードまたは「ノーダル障害」の再起動全体にデータ/転送面の状態を保持する能力を宣伝します。[RFC3473]は、再起動ノードの上流のRSVPネイバーのパスメッセージで使用する回復ラベルオブジェクトを定義し、パスメッセージが既存のデータプレーン状態のものであることを示します。

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].

このドキュメントでは、以前にサポートされていなかった優雅な再起動の2つの側面に対処するための拡張機能を提示します。提示された拡張機能により、再起動するノードは、下流の隣人から明示的なルートオブジェクト（ERO）を含む以前に送信されたパスメッセージのすべてのオブジェクトを回復し、コントロールプレーン状態を回復できます。拡張は、データ/転送面の状態の回復または作成を容易にするものではなく、インプレースデータ/転送状態と一致するコントロールプレーン状態を再確立するためにのみ使用できます。また、拡張機能により、再起動全体で完全な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]に従って、再起動ノードは、Recoveryラベルオブジェクトの存在によって回復されるLSPに関連するパスメッセージを区別できます。ダウンストリーム（発信）インターフェイスと関連ラベルを決定するには、再起動ノードはデータプレーンを参照する必要があります。これは、すべてのタイプのノードでは不可能かもしれません。さらに、以前に送信されたすべてのパス状態を再構築するには、データプレーン情報では十分ではありません。これらの場合、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.

たとえば、再起動ノードが侵入ノードである場合、以前に送信されたすべてのパス状態を回復する必要がある場合があります。このようなパス状態には、保護オブジェクト、管理ステータスオブジェクト、セッション属性オブジェクト、Notifyリクエストオブジェクト、および送信者TSPECオブジェクトが含まれる（ただし制限されていません）。再起動トランジットノードは、以前に送信されたパスメッセージで受信パス状態を変更した可能性があります。パスメッセージは、回復中に内部で再構築することはできません。

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.

定義された拡張機能は、パスメッセージ内のノードによって以前に送信されたすべての情報を使用して、上流ノードの再起動を提供します。これは、このドキュメントのセクション4.5.2で定義されている回復手順をサポートする再起動ノードとRSVP通信を再確立した後、下流の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メッセージと呼ばれます。このメッセージは、最後に受信したパスメッセージの内容を再起動ノードに戻します。再起動ノードは、RecoveryPathメッセージを使用して、受信したパスメッセージの状態を使用して、アソシエイトコントロールおよびデータプレーン状態になり、近隣のRSVPノードによって提示された状態で転送状態を検証します。

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.

再起動ノードは、ダウンストリームRSVP隣人に送信されたHelloメッセージに、RecoveryPathの希望ビットセットを含む機能オブジェクトと呼ばれる新しいオブジェクトを含めることにより、RecoveryPathメッセージを受信して処理したいという要望を示します。ダウンストリームRSVPネイバーは、RecoveryPath Transmit EnabledセットにHello Messageに設定された[再起動]ノードに設定されたRecoveryPathオブジェクトを含めることにより、RecoveryPathメッセージを送信する機能を示すことができます。したがって、機能オブジェクトの助けを借りて、再起動ノードとそのRSVPネイバーの両方が、このドキュメントで定義されているRecoveryPathメッセージ拡張機能を使用して、再起動後にシグナリング状態を回復できるかどうかを検出できます。

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隣接から回復ラベルオブジェクトを含むパスメッセージが受信されます。さらに、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]で定義されている要約リフレッシュメカニズムを強化することによりサポートされます。Recovery Summaryの更新がサポートされている場合、再起動ノードは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].

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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]で定義されているように、パスメッセージの形式と同じですが、新しいメッセージ番号（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メッセージ内のすべてのオブジェクトは、送信ノードが最後に受信した対応するパスメッセージのオブジェクトと同一です。

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 Messagesで運ばれます。機能オブジェクトは、クラス番号134（フォーム10bbbbbbb）と1のC型を使用します。

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

ハローメッセージのメッセージ形式は、次のように変更されます。

      <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対応：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-bitとともに、送信ノードが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-BITの設定をサポートし、セクション5で定義されているメカニズムをサポートする必要があります。

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 Hellosの使用と、[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メッセージを送信できる場合、RecoveryPath送信（T）ビットセット（1）にすべてのハローメッセージに機能を含める必要があります。

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隣接は、[RFC3473]で定義されているRestART_CAPオブジェクトを使用して、RestART_CAPオブジェクトを使用して、recoveryPath（r）ビットセット（1）を使用して、再起動_CAPオブジェクトを使用して、再起動ノードからハローメッセージを受信した場合、再起動ノードを扱う必要があります。このドキュメントで定義されているように、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ネイバーが、recoveryPathが目的の（r）ビットセット（1）を使用してhelloメッセージの機能オブジェクトを受信しますが、restart_capオブジェクトがない場合、recoverypathが希望の（r）ビットがクリアされるかのようにハローメッセージを処理する必要があります（0）ハローメッセージ。

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ネイバーが再起動ノードによって送信されたハローメッセージの機能オブジェクトを受信しない場合、または希望する（r）ビットが機能オブジェクトでクリアされた（r）ビットがクリアされている場合、再起動ノードを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.

このドキュメントで定義されている手順に従ってRECOVERPATHメッセージの受領と処理によってRSVP状態を回復すると予想されるノードは、RSVP Helloメッセージに近隣へのRECOVERIBALITY PATH（R）ビットセット（1）を含む機能オブジェクトを含める必要があります。ノードには、[RFC3473]で定義されているように、すべてのHelloメッセージに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メッセージの使用をサポート/希望しない場合、Helloメッセージまたは機能オブジェクトに含まれる機能オブジェクトで、recoveryPath（r）ビットをクリアする必要があります（r）ビットをクリアする必要があります（0）再起動ノードによって送信された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.

回復期間中、再起動ノードが[RFC3473]で定義されているように、RecoveryPathが有効になっている（T）ビットセット（1）を使用して（T）ビットセット（1）を使用して、下流のRSVPネイバーからハローメッセージを受信した場合、[RFC3473]で定義されているように、それは処理する必要があります。セクション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.

回復期間中、再起動ノードが下流のRSVPネイバーからHelloメッセージを受信した場合、RecoveryPathが有効になっている（t）ビットクリア（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メッセージを受信できます。RESVメッセージを送信した再起動ノードに関連付けられています。回復期間中、下流のRSVPネイバーが再起動ノードが機能オブジェクトの不在によってRecoveryPathメッセージを受信できないことを検出した場合、または再起動ノードのHelloの機能オブジェクトで希望する（r）ビットクリア（0）を検出することを検出します。メッセージ、ダウンストリームRSVPネイバーは、RecoveryPathメッセージを再起動ノードに送信しないでください。

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

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

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メッセージで使用される完全性オブジェクトは、[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.

最新の受信パスメッセージの他のすべてのオブジェクトは、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以内に少なくとも1回送信する必要があります。再起動したノードによって回復する多くのLSPがある場合、下流のRSVPネイバーは、再起動したノードのCPUの過負荷を避けるために、短時間間隔でRecoveryPathメッセージを送信しないようにする必要があります。代わりに、回復時間間隔の1/2にメッセージを広める必要があります。回復時間の範囲は、再起動ノードのCPU処理能力、上流および下流の近隣の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メッセージを定期的に再送信する必要があります。対応する応答は、RecoveryPathメッセージが表すLSPのメッセージID確認またはパスメッセージです。メッセージIDメカニズムが使用されている場合、そのような再送信の各試行は、メッセージIDの迅速な再送信の最後にあります。メッセージIDメカニズムが使用されていない場合、ResEnd試行の間の期間は、回復時間間隔3/4の有効期限の前に少なくとも3回の試行が完了するようにする必要があります。このような各resEnd試行は、RecoveryPathメッセージを新しいメッセージとして扱い、[RFC2961]で定義されている手順に従ってmessage_idオブジェクトを更新する必要があります。[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状態と一致する必要があります。完全に再同期された状態を一致させる場合、ノードは下流のパスメッセージを送信する必要があります。RecoveryPathメッセージに一致するLSP状態ではない場合、またはLSP状態がない場合、再起動されたノードは、RecoveryPathメッセージから構築されたPATHTEARメッセージを送信して、回復されていないRSVPのクリーンアップと再起動ノードの下流に関連する転送状態を促進する場合があります。再起動ノードは、受信した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.

残りの手順は、3つのサブセクションに分類されます。元々[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.

ノードが回復期間中にRecoveryPathメッセージを受信すると、ノードは最初にメッセージに関連付けられたRSVP状態を再同期させたかどうかを確認します。再同期された状態があり、両方の信頼できるメッセージ配信[RFC2961]がサポートされ、RecoveryPathメッセージにMessage_IDオブジェクトが存在する場合、ノードは[RFC2961]で定義されているようにメッセージID確認手順に従う必要があり、メッセージを処理されたものとして検討する必要があります。。再同期された状態があり、message_idオブジェクトまたは信頼できるメッセージ配信[RFC2961]がサポートされていない場合、ノードはトリガーパスメッセージを送信し、メッセージを処理されたものと見なす必要があります。

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.

ノードが回復期間中にパスメッセージを受信すると、ノードは最初にメッセージに関連付けられた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オブジェクトを含むパスメッセージに含まれる情報を保存し、セクション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状態を一致させると、メッセージがRecovery_Labelオブジェクトを運ばない場合、ノードはこれを新しいLSPのセットアップとして扱い、以前に定義された手順に従って処理します。

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オブジェクトを含むパスメッセージに含まれる情報を保存します。

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の場合、Recoveryラベルオブジェクトを使用した対応するパスメッセージの場合、再起動ノードは、受信した情報を使用して対応する転送状態を見つけて関連付ける必要があります。再起動ノードは、対応するアクティブ転送面の状態を次のシグナル情報から関連付けます。

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

上流のデータインターフェイスは、受信したパスメッセージの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.

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

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メッセージのRecoveryラベルオブジェクトから回復されます。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を再同期として扱う必要があり、トリガーパスメッセージを下流に送信する必要があります。パスメッセージ内の明示的なルートオブジェクトは、RecoveryPathメッセージで受信した明示的なルートオブジェクトと一致する必要があります。さらに、再起動したノードは、RecoveryPathメッセージで受信した他のオブジェクトから状態を回復する必要があります。最適には、結果のパスメッセージは、残りの下流ノードに沿った状態の冗長または不必要な再処理を引き起こさないはずです。理想的には、Message_ID処理と回復処理を除き、送信されたパスメッセージは、下流のRSVP隣人による更新として扱われます（したがって、さらに下流の状態が変更されたパスメッセージをトリガーするべきではありません）。

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のセットアップリクエストとして扱います。RecoveryPathメッセージに示されている発信インターフェイスとラベルは、可能であれば再利用する必要があります。RecoveryPathメッセージに含まれる他のすべての情報も使用できます。つまり、上流からのパスメッセージを受信した後、またはイングレスノードで管理プレーンからコマンドを受信した後を除き、転送状態を作成してはなりません。さらに、作成された転送状態はローカルポリシーの対象となり、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を含む受信したパスメッセージは、回復期間中に受信され、[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].

再起動ノードが機能オブジェクトをサポートしていない場合、クラス数はフォーム10bbbbbbbであるため、オブジェクトを破棄し、[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隣人が機能オブジェクトをサポートしていない場合、[RFC3473]で定義されているように、Helloメッセージで受信されたオブジェクトを破棄し、回復処理に戻ります。下流の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]で定義されているハローメッセージで運ばれるセクション4.2で定義されているように、機能オブジェクトでrecoverPath srefreshビットを使用します。説明されているメカニズムは、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メッセージがノードによって送信され、ローカルにインストールされ利用可能なPATHと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メッセージは、以前に送信されたパスメッセージではなく、以前に受信されたパスメッセージを表します。これは、このセクションで説明されている標準要約の更新と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.

ノードが再起動し、このセクションで説明されているメカニズムをサポートできる場合、rsvpの隣人に送信するhelloメッセージに設定されたRecoveryPath（R）ビットセットとRecoveryPath Srefresh Biteを備えた機能オブジェクトが含まれています。。

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によるRecoveryPath Srefreshメッセージを要求していることを検出します。機能オブジェクトに設定された能力（s）ビット。そのような兆候が見つかった場合、隣人は1つ以上の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リストオブジェクトを使用して、一致する送信パス状態を識別しようとすることができます。ノードは、再起動前に下流に送信されたパスメッセージに対してエポックとメッセージ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.

一致する状態がある場合、セクション4.5.2に従って、RecoveryPathメッセージが受信されたかのように再起動されたノードが動作します。一致する状態がない場合、再起動されたノードは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リストオブジェクト

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メッセージを使用して回復できるPATH状態に関連するMessage_ID情報をCORMEDに伝えていることを示しています。一貫性のためにすべてのオブジェクトで同じフラグ値が使用されます。

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リストオブジェクト

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

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

Flags: 8 bits

フラグ：8ビット

0x02: RecoveryPath Flag

0x02：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つ以上のパスメッセージに関連するmessage_id情報を搭載していることを示します。

5.2. RecoveryPath Srefresh Capable Bit

5.2. RecoveryPath srefresh能力ビット

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

機能オブジェクトとRecoveryPath srefresh能力ビットは、セクション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 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.

RSVP隣人にRecoveryPathメッセージの選択的伝送が必要であることを示すために、ノードは（1）送信するすべてのハローメッセージの機能オブジェクトのSビットを設定する必要があります。再起動ノードがRecoveryPathメッセージの受信（セクション4.4.2を参照）またはこのセクションで定義されている選択的伝送メカニズムを望まない場合、ハローメッセージに含まれる場合は、機能オブジェクトの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 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.

ダウンストリームRSVP隣接は、RecoveryPathメッセージで状態回復をサポートするノードの再起動を検出する際に、RビットとSビットをチェックします。RecoveryPathメッセージを使用して状態回復を伴うネイバーの再起動の検出は、セクション4で定義されています。RビットとSビットの両方が設定されている場合、セクション5.3.1で以下に定義されている手順に従う必要があります。S-BITがクリアされている場合、下流のRSVP隣接はセクション4.5.1で定義された通常の手順に戻る必要があります。Rビットがクリアされているが、Sビットが設定されている場合、下流のRSVP隣接は、S-BITがクリアされた状態で受信されたかのようにそれを扱う必要があります。機能オブジェクトのないハローメッセージの処理については、セクション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フラグセット（1）を含むMessage_IDリストオブジェクトを含むSREFRESHメッセージを受信する前にRecoveryPathメッセージを受信する前に、その近隣がRecoveryPathメッセージの選択的伝送をサポートしていないことを検出します。これが発生した場合、受信したRecoveryPathメッセージは、セクション4で定義されているように処理する必要があります。

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 RecoveryPath関連のSREFRESHメッセージの生成

o RecoveryPath-related Srefresh message receive processing and NACK generation

o RecoveryPath関連のsrefreshメッセージ受信処理とNACK生成

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. 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ビットが設定されている場合、1つ以上の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メッセージで表すことができるパス状態は、状態に関連付けられた最近受信したパスメッセージからのメッセージ_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-BITを処理した後、ノードは再起動した隣人から受信したパスメッセージに関連付けられたすべての状態を識別します。再スフレッシュメッセージに再起動を表すことができるため、更新されていないパス状態のみ。エポック値が最新のHelloメッセージで受信したエポックと一致するメッセージ_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リストオブジェクトは、識別された、アップデーションされていないパス状態を表します。識別された各アップデートされたパス状態ごとに作成されたmessage_identifierフィールドは、適切なmessage_idリストオブジェクトに含める必要があります。message_identifierフィールドは、識別されたパス状態に関連付けられた最近受信したパスメッセージの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メッセージは、対応するパスメッセージのホップオブジェクトのIPアドレスに運命づけられる必要があります。これにより、複数のsrefreshメッセージが生成される可能性があります。[RFC2961]に従って、実装は、各SREFRESHメッセージを発信リンクのMTUサイズに制限し、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メッセージを定期的に送信する必要があります。使用される再送信アルゴリズムは、回復期間中にRecoveryPathメッセージを再送信するために使用される同じアルゴリズムである可能性があります（セクション4.5.1を参照）。このような定期的な再送信ごとに、Srefreshメッセージを更新して、PATHメッセージの受信によって更新された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近隣は、再起動したノードによって宣伝されている回復時間の1/4に広がる部分的で相互に排他的なメッセージ識別子を含む複数のRecoveralPath関連のSrefreshメッセージを生成することを選択できます。

5.3.2. RecoveryPath関連のsrefresh受信処理とNACK生成

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ネイバーに送信されたパスメッセージの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のトリガーパスメッセージを生成する必要があります。再起動されたノードは、残りの回復期間の1/2にこのようなトリガーパスメッセージの送信を拡大し、下流のRSVP隣接を十分に処理できるようにする場合があります。

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]ごとに、再起動したノードは複数のそのようなメッセージ_IDを単一のACKメッセージに組み合わせることをお勧めします。

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 nacksの処理の手順は[RFC2961]で定義されており、このドキュメントでは変更されていません。RecoveryPathフラグセット（1）を使用したmessage_id nacksの処理は、このセクションで明示的に変更されない限り、[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ネイバーは、一致する受信パスメッセージを見つける必要があります。一致するパスメッセージが見つかった場合、下流のRSVP隣接は、セクション4.5.1で定義されているようにRecoveryPathメッセージを生成する必要があります。一致するパスメッセージが見つからない場合、message_id nackは無視されます。これが発生する可能性のある例は、再起動したノードが再起動後に更新されたパスメッセージをすでに生成している場合です。

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エージェントで実行される新しい手順を紹介します。一般的なコントロールプレーン、特に1つ以上の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エージェントを再起動することで最小限に抑えることができます。そのため、その近隣は、回復期間中に通常他のコントロールプレーン機能を実行し続けながら、追加の処理を処理するのに十分な時間を提供されます。

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、Adrian Farrel、Nick Neate、およびPavan Bearamの有益なコメントとフィードバックに感謝します。

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.

Derek Atkinsは、Secdirレビュー中に有用な議論を提供しました。サム・ハートマンは、セキュリティ上の考慮事項とRSVP-TEセキュリティトラストモデルへの潜在的な影響について慎重に精査しました。

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

Adrian Farrelは、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.

このドキュメントのセクション4.2で定義されている、機能オブジェクトと呼ばれるクラス番号10bbbbbbbを使用した新しいRSVPオブジェクトが定義されています。クラス番号は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コンセンサスアクションを通じてIANAによって割り当てられます。IANAは、この名前空間のリポジトリとしても機能します。

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

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

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対応：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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

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

[RFC2205] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。

[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] Baker、F.、Lindell、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] Berger、L.、Gan、D.、Swallow、G.、Pan、P.、Tommasi、F.、およびS. Molendini、「RSVP Refrend Overhead Recotion Extensions」、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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「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] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。

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

[RFC3473] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソースリソースプロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。

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

Arun Satyanarayana（編集者）Cisco Systems、Inc。170 West Tasman Dr. San Jose、CA 95134 USA電話：1 408 853 3206メール：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 Rahman（編集者）Cisco Systems、Inc。2000 Innovation Dr. Kanata、Ontario K2K 3E8カナダ電話：613 254 3519メール：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

Dimitri Papadimitriou Alcatel Francis Wellesplein 1 B-2018 Antwerpen Belgium電話：32 3 240-8491メール：dimitri.papadimitriou@alcatel-lucent.be

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

Lou Berger Labn Consulting、L.L.C。電話：1 301 468 9228メール：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 Cisco Systems、Inc。2000 Innovation Dr. Kanata、Ontario K2K 3e8 Canada：613 254 3484メール：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 Cisco Systems、Inc。2000 Innovation Dr. Kanata、Ontario K2K 3E8 Canada：613 254 3693メール：jisrar@cisco.com

Full Copyright Statement

完全な著作権声明

著作権（c）The IETF Trust（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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。

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.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。