[要約] RFC 7551は、関連する双方向のラベルスイッチパス（LSP）のためのRSVP-TE拡張に関するものです。このRFCの目的は、関連する双方向のLSPをサポートするための拡張機能を提供することです。
Internet Engineering Task Force (IETF) F. Zhang, Ed.
Request for Comments: 7551 Huawei
Category: Standards Track R. Jing
ISSN: 2070-1721 China Telecom
R. Gandhi, Ed.
Cisco Systems
May 2015
RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)
関連する双方向ラベルスイッチドパス（LSP）のRSVP-TE拡張
Abstract
概要
This document describes Resource Reservation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single-sided provisioning. The REVERSE_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single-sided provisioning case.
このドキュメントでは、2つのポイントツーポイントの単方向ラベルスイッチドパス（LSP）を関連付けられた双方向LSPにバインドするためのリソース予約プロトコル（RSVP）拡張について説明します。関連付けは、ASSOCIATIONおよび拡張ASSOCIATIONオブジェクトで使用するための新しい関連付けタイプを定義することによって実現されます。これらのタイプの1つは、関連する双方向LSPの独立したプロビジョニングを両側で可能にし、もう一方は片側のプロビジョニングを可能にします。 REVERSE_LSPオブジェクトも定義され、単一のエンドポイントがリバースLSPの作成をトリガーし、片側プロビジョニングの場合にリバースLSPのパラメーターを指定できるようになります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7551.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7551で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................5
2.1. Key Word Definitions .......................................5
2.2. Reverse Unidirectional LSPs ................................5
2.3. Message Formats ............................................5
3. Overview ........................................................6
3.1. Provisioning Model Overview ................................6
3.1.1. Single-Sided Provisioning ...........................6
3.1.2. Double-Sided Provisioning ...........................6
3.2. Association Signaling Overview .............................6
3.2.1. Single-Sided Provisioning ...........................7
3.2.2. Double-Sided Provisioning ...........................7
3.3. Asymmetric Bandwidth Signaling Overview ....................8
3.3.1. Single-Sided Provisioning ...........................8
3.3.2. Double-Sided Provisioning ...........................8
3.4. Recovery LSP Overview ......................................8
4. Message and Object Definitions ..................................9
4.1. RSVP Message Formats .......................................9
4.2. ASSOCIATION Object .........................................9
4.3. Extended ASSOCIATION Object ...............................10
4.4. REVERSE_LSP Object Definition .............................11
4.4.1. REVERSE_LSP Object Format ..........................11
4.4.2. REVERSE_LSP Subobjects .............................11
5. Processing Rules ...............................................12
5.1. Rules for ASSOCIATION Object ..............................12
5.1.1. Compatibility for ASSOCIATION Object ...............14
5.2. Rules for REVERSE_LSP Object ..............................14
5.2.1. Compatibility for REVERSE_LSP Object ...............16
6. IANA Considerations ............................................16
6.1. Association Types .........................................16
6.2. REVERSE_LSP Object ........................................16
6.3. Reverse LSP Failure PathErr Sub-code ......................17
7. Security Considerations ........................................17
8. References .....................................................18
8.1. Normative References ......................................18
8.2. Informative References ....................................19
Acknowledgements ..................................................20
Contributors ......................................................20
Authors' Addresses ................................................20
The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] specifies that MPLS-TP MUST support associated bidirectional point-to-point Label Switched Paths (LSPs). These requirements are given in Section 2.1 ("General Requirements") of that document and are partially rephrased below:
MPLSトランスポートプロファイル（MPLS-TP）要件ドキュメント[RFC5654]は、MPLS-TPが関連する双方向ポイントツーポイントラベルスイッチドパス（LSP）をサポートする必要があることを指定しています。これらの要件は、そのドキュメントのセクション2.1（「一般要件」）に記載されており、部分的に以下に言い換えられます。
7. MPLS-TP MUST support associated bidirectional point-to-point LSPs.
7. MPLS-TPは、関連する双方向ポイントツーポイントLSPをサポートする必要があります。
11. The end points of an associated bidirectional LSP MUST be aware of the pairing relationship of the forward and reverse LSPs used to support the bidirectional service.
11. 関連する双方向LSPのエンドポイントは、双方向サービスをサポートするために使用されるフォワードLSPとリバースLSPのペアリング関係を認識している必要があります。
12. Nodes on the LSP of an associated bidirectional LSP where both the forward and backward directions transit the same node in the same (sub)layer as the LSP SHOULD be aware of the pairing relationship of the forward and the backward directions of the LSP.
12. LSPが順方向と逆方向の両方で同じ（サブ）レイヤーの同じノードを通過する、関連付けられた双方向LSPのLSP上のノードは、LSPがLSPの順方向と逆方向のペアリング関係を認識している必要があります。
50. The MPLS-TP control plane MUST support establishing associated bidirectional P2P LSP including configuration of protection functions and any associated maintenance functions.
50. MPLS-TPコントロールプレーンは、保護機能と関連するメンテナンス機能の構成を含む、関連する双方向P2P LSPの確立をサポートする必要があります。
The above requirements are also repeated in [RFC6373].
上記の要件は、[RFC6373]でも繰り返されます。
Furthermore, an associated bidirectional LSP is also useful for protection-switching for Operations, Administration, and Maintenance (OAM) messages that require a return path.
さらに、関連する双方向LSPは、リターンパスが必要な運用、管理、および保守（OAM）メッセージの保護切り替えにも役立ちます。
A variety of applications, such as Internet services and the return paths of OAM messages, exist and may have different upstream and downstream bandwidth requirements. [RFC5654] specifies an asymmetric bandwidth requirement in Section 2.1 ("General Requirements"), and it is repeated below:
インターネットサービスやOAMメッセージのリターンパスなど、さまざまなアプリケーションが存在し、アップストリームとダウンストリームの帯域幅要件が異なる場合があります。 [RFC5654]は、セクション2.1（「一般要件」）で非対称帯域幅要件を指定しており、以下に繰り返します。
14. MPLS-TP MUST support bidirectional LSPs with asymmetric bandwidth requirements, i.e., the amount of reserved bandwidth differs between the forward and backward directions.
14. MPLS-TPは、非対称の帯域幅要件を持つ双方向LSPをサポートする必要があります。つまり、予約された帯域幅の量は、順方向と逆方向で異なります。
The approach for supporting asymmetric bandwidth co-routed bidirectional LSPs is defined in [RFC6387].
非対称帯域幅コルーテッド双方向LSPをサポートするためのアプローチは、[RFC6387]で定義されています。
The method of association and the corresponding Resource Reservation Protocol (RSVP) ASSOCIATION Object are defined in [RFC4872], [RFC4873], and [RFC6689]. In that context, the ASSOCIATION Object is used to associate a recovery LSP with the LSP it is protecting. This object also has broader applicability as a mechanism to associate RSVP states. [RFC6780] defines the Extended ASSOCIATION Objects that can be more generally applied for this purpose. This document uses the term "(Extended) ASSOCIATION Objects" to refer collectively to the ASSOCIATION Objects defined in [RFC4872] and the Extended ASSOCIATION Objects defined in [RFC6780].
関連付けの方法と対応するリソース予約プロトコル（RSVP）ASSOCIATIONオブジェクトは、[RFC4872]、[RFC4873]、および[RFC6689]で定義されています。そのコンテキストでは、ASSOCIATIONオブジェクトを使用して、回復LSPを保護しているLSPに関連付けます。このオブジェクトは、RSVP状態を関連付けるメカニズムとしてより広い適用性も持っています。 [RFC6780]は、より一般的にこの目的に適用できる拡張ASSOCIATIONオブジェクトを定義しています。このドキュメントでは、「（拡張）ASSOCIATIONオブジェクト」という用語を使用して、[RFC4872]で定義されているASSOCIATIONオブジェクトと、[RFC6780]で定義されている拡張ASSOCIATIONオブジェクトを総称します。
This document specifies mechanisms for binding two reverse unidirectional LSPs into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in (Extended) ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs, while the other enables single-sided provisioning. The REVERSE_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single-sided provisioning case. For example, the REVERSE_LSP Object allow asymmetric upstream and downstream bandwidths for the associated bidirectional LSP.
このドキュメントでは、2つの逆単方向LSPを関連付けられた双方向LSPにバインドするメカニズムを指定します。関連付けは、（拡張）ASSOCIATIONオブジェクトで使用するための新しい関連付けタイプを定義することによって実現されます。これらのタイプの1つは、関連する双方向LSPの独立したプロビジョニングを可能にし、もう1つのタイプは片面プロビジョニングを可能にします。 REVERSE_LSPオブジェクトも定義され、単一のエンドポイントがリバースLSPの作成をトリガーし、片側プロビジョニングの場合にリバースLSPのパラメーターを指定できるようになります。たとえば、REVERSE_LSPオブジェクトは、関連付けられた双方向LSPに対して非対称のアップストリームおよびダウンストリーム帯域幅を許可します。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Two reverse unidirectional LSPs are setup in the opposite directions between a pair of source and destination nodes to form an associated bidirectional LSP. A reverse unidirectional LSP originates on the same node where the forward unidirectional LSP terminates, and it terminates on the same node where the forward unidirectional LSP originates.
関連付けられた双方向LSPを形成するために、送信元ノードと宛先ノードのペア間で2つの逆単方向LSPが反対方向にセットアップされます。逆方向単方向LSPは、順方向単方向LSPが終了する同じノードで発生し、順方向単方向LSPが発生する同じノードで終了します。
This document uses the Routing Backus-Naur Form (RBNF) to define message formats as defined in [RFC5511].
このドキュメントでは、Routing Backus-Naur Form（RBNF）を使用して、[RFC5511]で定義されているメッセージ形式を定義しています。
This section provides an overview and definition of the models for provisioning associated bidirectional LSPs.
このセクションでは、関連する双方向LSPをプロビジョニングするためのモデルの概要と定義について説明します。
The associated bidirectional LSP's forward and reverse unidirectional LSPs are established, monitored, and protected independently as specified by [RFC5654]. Configuration information regarding the LSPs can be provided at one or both endpoints of the associated bidirectional LSP. Depending on the method chosen, there are two models of creating an associated bidirectional LSP -- single-sided provisioning and double-sided provisioning.
[RFC5654]で指定されているように、関連付けられた双方向LSPの順方向および逆方向単方向LSPが個別に確立、監視、保護されます。 LSPに関する構成情報は、関連する双方向LSPの一方または両方のエンドポイントで提供できます。選択した方法に応じて、関連する双方向LSPを作成する2つのモデルがあります。片側プロビジョニングと両面プロビジョニングです。
For the single-sided provisioning, the Traffic Engineering (TE) tunnel is configured only on one endpoint. An LSP for this tunnel is initiated by the initiating endpoint with the (Extended) ASSOCIATION and REVERSE_LSP Objects inserted in the Path message. The other endpoint then creates the corresponding reverse TE tunnel and signals the reverse LSP in response using information from the REVERSE_LSP Object and other objects present in the received Path message.
片側プロビジョニングの場合、トラフィックエンジニアリング（TE）トンネルは1つのエンドポイントでのみ構成されます。このトンネルのLSPは、（拡張された）ASSOCIATIONおよびREVERSE_LSPオブジェクトがPathメッセージに挿入された開始エンドポイントによって開始されます。次に、他のエンドポイントは、対応するリバースTEトンネルを作成し、受信したPathメッセージに存在するREVERSE_LSPオブジェクトおよび他のオブジェクトからの情報を使用して、応答としてリバースLSPに通知します。
For the double-sided provisioning, two unidirectional TE tunnels are configured independently, one on each endpoint. The LSPs for the tunnels are signaled with (Extended) ASSOCIATION Objects inserted in the Path message by both endpoints to indicate that the two LSPs are to be associated to form a bidirectional LSP.
両面プロビジョニングの場合、2つの単方向TEトンネルが、各エンドポイントに1つずつ独立して構成されます。トンネルのLSPは、2つのLSPが関連付けられて双方向LSPを形成することを示すために、両方のエンドポイントによってPathメッセージに挿入された（拡張）ASSOCIATIONオブジェクトで通知されます。
This section provides an overview of the association signaling methods for the associated bidirectional LSPs.
このセクションでは、関連付けられた双方向LSPの関連付けシグナリング方法の概要を説明します。
Three scenarios exist for binding two unidirectional LSPs together to form an associated bidirectional LSP. These are:
2つの単方向LSPをバインドして、関連する双方向LSPを形成するシナリオは3つあります。これらは：
1) Neither unidirectional LSP exists, and both must be established.
1）どちらの単方向LSPも存在せず、両方を確立する必要があります。
2) Both unidirectional LSPs exist, but the association must be established.
2）両方の単方向LSPが存在しますが、関連付けを確立する必要があります。
3) One LSP exists, but the reverse associated LSP must be established.
3）LSPは1つ存在しますが、逆に関連付けられたLSPを確立する必要があります。
The following sections describe the applicable provisioning models for each of these scenarios.
次のセクションでは、これらの各シナリオに適用可能なプロビジョニングモデルについて説明します。
Path Computation Element (PCE)-based approaches [RFC4655] may be used for path computation of an associated bidirectional LSP. However, these approaches are outside the scope of this document.
パス計算要素（PCE）ベースのアプローチ[RFC4655]は、関連する双方向LSPのパス計算に使用できます。ただし、これらのアプローチはこのドキュメントの範囲外です。
Consider the topology described in Figure 1. LSP1 from node A to B, takes the path A,D,B, and LSP2 from node B to A takes the path B,D,C,A. These two LSPs, once established and associated, form an associated bidirectional LSP between nodes A and B.
図1で説明されているトポロジを検討してください。ノードAからBへのLSP1はパスA、D、Bをとり、ノードBからAへのLSP2はパスB、D、C、Aをとります。これらの2つのLSPは、いったん確立されて関連付けられると、ノードAとBの間の関連付けられた双方向LSPを形成します。
LSP1 -->
A-------D-------B
\ / <-- LSP2
\ /
\ /
C
Figure 1: An Example of Associated Bidirectional LSP
図1：関連する双方向LSPの例
For the single-sided provisioning model, creation of reverse LSP1 shown in Figure 1 is triggered by LSP2, or creation of reverse LSP2 is triggered by LSP1. When creation of reverse LSP2 is triggered by LSP1, LSP1 is provisioned first (or refreshed, if LSP1 already exists) at node A. LSP1 is then signaled with an (Extended) ASSOCIATION, and REVERSE_LSP Objects are inserted in the Path message. The Association Type indicates single-sided provisioning. Upon receiving this Path message for LSP1, node B establishes reverse LSP2. The (Extended) ASSOCIATION Object inserted in LSP2's Path message is the same as that received in LSP1's Path message.
片側プロビジョニングモデルの場合、図1に示すリバースLSP1の作成はLSP2によってトリガーされるか、リバースLSP2の作成はLSP1によってトリガーされます。 LSP1によってリバースLSP2の作成がトリガーされると、LSP1が最初にノードAでプロビジョニングされます（LSP1が既に存在する場合は更新されます）。次に、LSP1が（拡張）ASSOCIATIONで通知され、REVERSE_LSPオブジェクトがパスメッセージに挿入されます。関連タイプは、片面プロビジョニングを示します。 LSP1のこのPathメッセージを受信すると、ノードBはリバースLSP2を確立します。 LSP2のPathメッセージに挿入された（拡張）ASSOCIATIONオブジェクトは、LSP1のPathメッセージで受信したものと同じです。
A similar procedure is used if LSP2 is provisioned first at node B, and the creation of reverse LSP1 at node A is triggered by LSP2. In both scenarios, the two unidirectional LSPs are bound together to form an associated bidirectional LSP based on identical (Extended) ASSOCIATION Objects in the two LSPs' Path messages.
LSP2が最初にノードBでプロビジョニングされ、ノードAでの逆LSP1の作成がLSP2によってトリガーされる場合も、同様の手順が使用されます。どちらのシナリオでも、2つの単方向LSPがバインドされ、2つのLSPのパスメッセージ内の同一の（拡張）ASSOCIATIONオブジェクトに基づいて、関連付けられた双方向LSPが形成されます。
For the double-sided provisioning model, both LSP1 and LSP2 shown in Figure 1 are signaled independently with (Extended) ASSOCIATION Objects inserted in the Path messages, in which the Association Type indicating double-sided provisioning is included. In this case, the two unidirectional LSPs are bound together to form an associated bidirectional LSP based on identical (Extended) ASSOCIATION Objects in the two LSPs' Path messages. In all three scenarios described in Section 3.2, the LSPs to be selected for the association are provisioned by the management action applied at both endpoints.
両面プロビジョニングモデルの場合、図1に示すLSP1とLSP2の両方は、Pathメッセージに挿入された（拡張）ASSOCIATIONオブジェクトを使用して個別に通知されます。この場合、両面プロビジョニングを示すアソシエーションタイプが含まれます。この場合、2つの単方向LSPがバインドされ、2つのLSPのパスメッセージ内の同一の（拡張）ASSOCIATIONオブジェクトに基づいて、関連付けられた双方向LSPが形成されます。セクション3.2で説明されている3つすべてのシナリオでは、関連付けに選択されるLSPは、両方のエンドポイントで適用される管理アクションによってプロビジョニングされます。
This section provides an overview of the methods for signaling asymmetric upstream and downstream bandwidths for the associated bidirectional LSPs.
このセクションでは、関連する双方向LSPの非対称アップストリームおよびダウンストリーム帯域幅をシグナリングする方法の概要を説明します。
A new REVERSE_LSP Object for use in the single-sided provisioning model is defined in this document, in Section 4.4. The REVERSE_LSP Object allows the initiating node of the single-sided provisioned LSP to trigger creation of the reverse LSP on the remote node. When the single-sided provisioning model is used, a SENDER_TSPEC Object can be added in the REVERSE_LSP Object as a subobject in the initiating LSP's Path message to specify a different bandwidth for the reverse LSP. As described in Section 4.4, addition of the REVERSE_LSP Object also allows the initiating node to control other aspects of the reverse LSP (such as its path) by including other objects in a REVERSE_LSP Object.
片側プロビジョニングモデルで使用する新しいREVERSE_LSPオブジェクトは、このドキュメントのセクション4.4で定義されています。 REVERSE_LSPオブジェクトを使用すると、片側プロビジョニングされたLSPの開始ノードが、リモートノードでリバースLSPの作成をトリガーできます。片側プロビジョニングモデルを使用する場合、SENDER_TSPECオブジェクトをREVERSE_LSPオブジェクトに、開始LSPのパスメッセージのサブオブジェクトとして追加して、逆LSPに異なる帯域幅を指定できます。セクション4.4で説明したように、REVERSE_LSPオブジェクトを追加すると、REVERSE_LSPオブジェクトに他のオブジェクトを含めることで、開始ノードがリバースLSPの他の側面（パスなど）を制御できるようになります。
Consider again the topology described in Figure 1, where the creation of reverse LSP2 is triggered by LSP1. Node A signals LSP1 with the (Extended) ASSOCIATION Object with Association Type indicating single-sided provisioning and inserts a SENDER_TSPEC subobject for use by LSP2 in the REVERSE_LSP Object in the Path message. Node B then establishes the LSP2 in the reverse direction using the asymmetric bandwidth thus specified by LSP1 and allows node A to control the reverse LSP2.
逆LSP2の作成がLSP1によってトリガーされる、図1で説明されているトポロジをもう一度考えてみます。ノードAは、LSP1に（拡張）ASSOCIATIONオブジェクトを関連付けタイプで示し、片側プロビジョニングを示し、LSP2が使用するSENDER_TSPECサブオブジェクトをパスメッセージのREVERSE_LSPオブジェクトに挿入します。ノードBは、LSP1によって指定された非対称帯域幅を使用してLSP2を逆方向に確立し、ノードAが逆方向のLSP2を制御できるようにします。
When the double-sided provisioning model is used, the two unidirectional LSPs are established with separate bandwidths, which may or may not be identical. However, these LSPs are associated purely based on the identical contents of their (Extended) ASSOCIATION Objects.
両面プロビジョニングモデルを使用する場合、2つの単方向LSPは別々の帯域幅で確立されます。これは、同一の場合も同一でない場合もあります。ただし、これらのLSPは、それらの（拡張）ASSOCIATIONオブジェクトの同一の内容に基づいて純粋に関連付けられています。
Recovery of each unidirectional LSP forming the bidirectional LSP is independent [RFC5654] and is based on the parameters signaled in their respective RSVP Path messages.
双方向LSPを形成する各単方向LSPの回復は独立しており[RFC5654]、それぞれのRSVPパスメッセージで通知されたパラメータに基づいています。
Recovery LSP association is based on the identical content of the (Extended) ASSOCIATION Objects signaled in their Path messages during the initial LSP setup for both single-sided and double-sided provisioning. As defined in [RFC6780], multiple ASSOCIATION Objects may be present in the signaling of a single LSP.
リカバリLSPアソシエーションは、片側プロビジョニングと両側プロビジョニングの両方の初期LSPセットアップ中にパスメッセージで通知された（拡張）ASSOCIATIONオブジェクトの同一のコンテンツに基づいています。 [RFC6780]で定義されているように、単一のLSPのシグナリングに複数のASSOCIATIONオブジェクトが存在する場合があります。
This section presents the RSVP message-related formats as modified by this document. Unmodified RSVP message formats are not listed.
このセクションでは、このドキュメントによって変更されたRSVPメッセージ関連の形式を示します。変更されていないRSVPメッセージ形式は表示されません。
The format of a Path message is as follows:
Pathメッセージの形式は次のとおりです。
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ... ]
[ <ADMIN_STATUS> ]
[ <ASSOCIATION> ... ]
[ <REVERSE_LSP> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
The format of the <sender descriptor> is not modified by this document.
<送信記述子>の形式は、このドキュメントでは変更されていません。
The ASSOCIATION Object is populated using the rules defined below for associating two reverse unidirectional LSPs to form an associated bidirectional LSP.
ASSOCIATIONオブジェクトは、2つの逆単方向LSPを関連付けて関連する双方向LSPを形成するために、以下に定義されたルールを使用して入力されます。
Association Types:
関連タイプ：
In order to bind two reverse unidirectional LSPs to be an associated bidirectional LSP, the Association Type MUST be set to indicate either single-sided or double-sided LSPs.
関連付けられた双方向LSPになるように2つの逆単方向LSPをバインドするには、関連付けタイプを設定して、片面または両面LSPを示す必要があります。
The new Association Types are defined as follows:
新しい関連タイプは次のように定義されています。
Value Type
----- -----
3 Double-Sided Associated Bidirectional LSP (D)
4 Single-Sided Associated Bidirectional LSP (A)
Association ID:
協会ID：
For both single-sided and double-sided provisioning, Association ID MUST be set to a value assigned by the node that originates the association for the bidirectional LSP.
片側と両側のプロビジョニングの場合、アソシエーションIDは、双方向LSPのアソシエーションを開始するノードによって割り当てられた値に設定する必要があります。
Association Source:
関連ソース：
Association Source MUST be set to an address selected by the node that originates the association for the bidirectional LSP. For example, this may be a management entity or, in the case of single-sided provisioning, an address assigned to the node that originates the LSP.
アソシエーションソースは、双方向LSPのアソシエーションを開始するノードによって選択されたアドレスに設定する必要があります。たとえば、これは管理エンティティ、または片側プロビジョニングの場合は、LSPを発信するノードに割り当てられたアドレスです。
The Extended ASSOCIATION Object is populated using the rules defined below for associating two reverse unidirectional LSPs to form a bidirectional LSP.
拡張ASSOCIATIONオブジェクトは、2つの逆単方向LSPを関連付けて双方向LSPを形成するために以下に定義されたルールを使用して入力されます。
The Association Type, Association ID, and Association Source MUST be set as defined for the ASSOCIATION Object in Section 4.1.
アソシエーションタイプ、アソシエーションID、およびアソシエーションソースは、セクション4.1でASSOCIATIONオブジェクトに対して定義されたとおりに設定する必要があります。
Global Association Source:
グローバルアソシエーションソース：
For both single-sided and double-sided provisioning, Global Association Source, when used, MUST be set to the Global_ID [RFC6370] of the node that originates the association for the bidirectional LSP.
片側と両側の両方のプロビジョニングで、グローバルアソシエーションソースを使用する場合は、双方向LSPのアソシエーションを開始するノードのGlobal_ID [RFC6370]に設定する必要があります。
Extended Association ID:
拡張アソシエーションID：
For both single-sided and double-sided provisioning, Extended Association ID, when used, MUST be set to a value selected by the node that originates the association for the bidirectional LSP.
片側と両側のプロビジョニングの両方で、拡張アソシエーションIDを使用する場合は、双方向LSPのアソシエーションを開始するノードが選択した値に設定する必要があります。
The REVERSE_LSP Object is carried in the Path message of a forward LSP to provide information to be used by the reverse LSP. The object also indicates that the LSP is the forward LSP of a single-sided associated bidirectional LSP.
REVERSE_LSPオブジェクトは、フォワードLSPのPathメッセージで伝達され、リバースLSPで使用される情報を提供します。このオブジェクトは、LSPが片側に関連付けられた双方向LSPの転送LSPであることも示しています。
The Object has the following format:
オブジェクトの形式は次のとおりです。
Class_Num = 203, C_Type = 1.
Class_Num = 203、C_Type = 1。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subobjects are used to override the default contents of a Path message of a reverse LSP; see Section 5.2. The contents of a REVERSE_LSP Object is zero or more variable-length subobjects that have the same format as RSVP Objects; see Section 3.1.2 of [RFC2205]. Any object that may be carried in a Path message MAY be carried in the REVERSE_LSP Object. Subobject ordering MUST follow any Path message Object ordering requirements.
サブオブジェクトは、逆LSPのPathメッセージのデフォルトの内容を上書きするために使用されます。セクション5.2を参照してください。 REVERSE_LSPオブジェクトの内容は、RSVPオブジェクトと同じ形式のゼロ以上の可変長サブオブジェクトです。 [RFC2205]のセクション3.1.2をご覧ください。 Pathメッセージで運ばれるかもしれないどんなオブジェクトでもREVERSE_LSPオブジェクトで運ばれるかもしれません。サブオブジェクトの順序付けは、パスメッセージオブジェクトの順序付け要件に従う必要があります。
Examples of the Path message Objects that can be carried in the REVERSE_LSP Object are (but not limited to):
REVERSE_LSPオブジェクトで伝送できるパスメッセージオブジェクトの例を次に示します（ただし、これらに限定されません）。
- SENDER_TSPEC [RFC2205] - EXPLICIT_ROUTE Object (ERO) [RFC3209] - SESSION_ATTRIBUTE Object [RFC3209] - ADMIN_STATUS Object [RFC3473] - LSP_REQUIRED_ATTRIBUTES Object [RFC5420] - PROTECTION Object [RFC3473] [RFC4872]
- SENDER_TSPEC [RFC2205]-EXPLICIT_ROUTEオブジェクト（ERO）[RFC3209]-SESSION_ATTRIBUTEオブジェクト[RFC3209]-ADMIN_STATUSオブジェクト[RFC3473]-LSP_REQUIRED_ATTRIBUTESオブジェクト[RFC5420]-PROTECTIONオブジェクト[RFC3473] [RFC4872]
In general, the processing rules for the ASSOCIATION Object are as specified in [RFC4872], and those for the Extended ASSOCIATION Object are as specified in [RFC6780]. The following sections describe the rules for processing (Extended) ASSOCIATION Objects for both double-sided and single-sided associated bidirectional LSPs and REVERSE_LSP Objects for single-sided associated bidirectional LSPs.
一般に、ASSOCIATIONオブジェクトの処理規則は[RFC4872]で指定されているとおりであり、拡張ASSOCIATIONオブジェクトの処理規則は[RFC6780]で指定されているとおりです。次のセクションでは、両面および片面の関連付けられた双方向LSPの（拡張）ASSOCIATIONオブジェクトと、片面の関連付けられた双方向LSPのREVERSE_LSPオブジェクトを処理するためのルールについて説明します。
This section defines the processing for the association of two unidirectional LSPs to form an associated bidirectional LSP. Such association is based on the use of an (Extended) ASSOCIATION Object.
このセクションでは、関連する双方向LSPを形成するための2つの単方向LSPの関連付けの処理を定義します。このような関連付けは、（拡張）ASSOCIATIONオブジェクトの使用に基づいています。
The procedures related to the actual identification of associations between LSPs based on (Extended) ASSOCIATION Objects are defined in [RFC6780]. [RFC6780] specifies that in the absence of rules for identifying the association that are specific to the Association Type, the included (Extended) ASSOCIATION Objects in the LSPs MUST be identical in order for an association to exist. This document adds no specific rules for the new Association Types defined, and the identification of an LSP association therefore proceeds as specified in [RFC6780].
（拡張）ASSOCIATIONオブジェクトに基づくLSP間の関連付けの実際の識別に関連する手順は、[RFC6780]で定義されています。 [RFC6780]は、アソシエーションタイプに固有のアソシエーションを識別するためのルールがない場合、アソシエーションが存在するためには、LSPに含まれる（拡張）ASSOCIATIONオブジェクトが同一でなければならないことを指定しています。このドキュメントは、定義された新しいアソシエーションタイプに特定のルールを追加しません。したがって、LSPアソシエーションの識別は、[RFC6780]で指定されているとおりに進行します。
As described in [RFC6780], association of LSPs can be upstream or downstream initiated, as indicated by (Extended) ASSOCIATION Objects in Path or Resv Messages. The association of bidirectional LSPs is always upstream initiated; therefore, the Association Types defined in this document are only to be interpreted in Path Messages. These types SHOULD NOT be used in ASSOCIATION Objects carried in Resv messages and SHOULD be ignored if present.
[RFC6780]で説明されているように、パスまたはResvメッセージ内の（拡張）ASSOCIATIONオブジェクトによって示されるように、LSPの関連付けはアップストリームまたはダウンストリームで開始できます。双方向LSPの関連付けは、常にアップストリームで開始されます。したがって、このドキュメントで定義されている関連タイプは、パスメッセージでのみ解釈されます。これらのタイプは、RESVメッセージで運ばれるASSOCIATIONオブジェクトでは使用してはならず（SHOULD NOT）、存在する場合は無視する必要があります（SHOULD）。
To indicate an associated bidirectional LSP, an ingress node MUST insert an (Extended) ASSOCIATION Object into the Path message of the unidirectional LSP that is part of the associated bidirectional LSP it initiates. If either Global Association Source or Extended Association Address is required, then an Extended ASSOCIATION Object [RFC6780] MUST be inserted in the Path message. Otherwise, an ASSOCIATION Object MAY be used. (Extended) ASSOCIATION Objects with both single-sided and double-sided Association Types MUST NOT be added or sent in the same Path message.
関連する双方向LSPを示すために、入口ノードは、開始する関連する双方向LSPの一部である単方向LSPのPathメッセージに（拡張）ASSOCIATIONオブジェクトを挿入する必要があります。グローバルアソシエーションソースまたは拡張アソシエーションアドレスのいずれかが必要な場合は、拡張ASSOCIATIONオブジェクト[RFC6780]をパスメッセージに挿入する必要があります。それ以外の場合は、ASSOCIATIONオブジェクトを使用できます。 （拡張）片面と両面の両方の関連タイプを持つASSOCIATIONオブジェクトは、同じPathメッセージで追加または送信してはなりません（MUST NOT）。
The ingress node MUST set the Association Type field in the (Extended) ASSOCIATION Object to "Single-Sided Associated Bidirectional LSP" when single-sided provisioning is used, and to "Double-Sided Associated Bidirectional LSP" when double-sided provisioning is used.
入力ノードは、（拡張）ASSOCIATIONオブジェクトのAssociation Typeフィールドを、片面プロビジョニングが使用されている場合は「片面関連双方向LSP」に、両面プロビジョニングが使用されている場合は「両面関連双方向LSP」に設定する必要があります。 。
A transit node MAY identify the unidirectional LSPs of an associated bidirectional LSP based on (Extended) ASSOCIATION Objects, with the Association Type values defined in this document, carried in Path messages. Clearly, such associations are only possible when the LSPs transit the node. As mentioned above, such associations are made per the rules defined in [RFC6780].
トランジットノードは、（拡張）ASSOCIATIONオブジェクトに基づいて、関連する双方向LSPの単方向LSPを識別できます（MAY）。このドキュメントで定義されているアソシエーションタイプの値は、パスメッセージで伝送されます。明らかに、そのような関連付けは、LSPがノードを通過するときにのみ可能です。上述したように、そのような関連付けは[RFC6780]で定義されたルールに従って行われます。
Egress nodes that support the Association Types defined in this document identify the unidirectional LSPs of an associated bidirectional LSP based on (Extended) ASSOCIATION Objects carried in Path messages. Note that an ingress node will normally be the ingress for one of the unidirectional LSPs that make up an associated bidirectional LSP. When an egress node receives a Path message containing an (Extended) ASSOCIATION Object with one of the Association Types defined in this document, it MUST attempt to identify other LSPs (including ones for which it is an ingress node) with which the LSP being processed is associated. As defined above, such associations are made per the rules defined in [RFC6780]. An LSP not being associated at the time of signaling (for example, during rerouting or re-optimization) on an egress node is not necessarily considered an error condition.
このドキュメントで定義されているアソシエーションタイプをサポートする出力ノードは、パスメッセージで伝送される（拡張）ASSOCIATIONオブジェクトに基づいて、関連付けられた双方向LSPの単方向LSPを識別します。通常、入力ノードは、関連付けられた双方向LSPを構成する単方向LSPの1つの入力になります。出力ノードが、このドキュメントで定義されている関連タイプの1つを持つ（拡張）ASSOCIATIONオブジェクトを含むPathメッセージを受信すると、LSPが処理されている他のLSP（それが入力ノードであるものを含む）を識別しようとする必要があります。関連しています。上で定義されたように、そのような関連付けは[RFC6780]で定義されたルールに従って行われます。出力ノードでのシグナリング時に（たとえば、再ルーティング中または再最適化中）LSPが関連付けられていない場合、必ずしもエラー状態とは見なされません。
Associated bidirectional LSP teardown follows the standard procedures defined in [RFC3209] and [RFC3473] either without or with the administrative status. Generally, the teardown procedures of the unidirectional LSPs forming an associated bidirectional LSP are independent of each other, so it is possible that while one LSP follows graceful teardown with administrative status, the reverse LSP is torn down without administrative status (using PathTear/ResvTear/PathErr with state removal). See Section 5.2 for additional rules related to LSPs established using single-sided provisioning.
関連付けられた双方向LSPティアダウンは、[RFC3209]および[RFC3473]で定義されている標準的な手順に従い、管理ステータスの有無にかかわらず。一般に、関連付けられた双方向LSPを形成する単方向LSPのティアダウン手順は互いに独立しているため、1つのLSPが管理ステータスでグレースフルティアダウンを実行している間に、逆LSPが管理ステータスなしでティアダウンされる（PathTear / ResvTear /を使用）状態が削除されたPathErr）。片側プロビジョニングを使用して確立されたLSPに関連する追加のルールについては、セクション5.2を参照してください。
When an LSP signaled with a Path message containing an (Extended) ASSOCIATION Object with an Association Type defined in this document is torn down, the processing node SHALL remove the binding of the LSP to any previously identified associated bidirectional LSP.
このドキュメントで定義されたアソシエーションタイプを持つ（拡張）ASSOCIATIONオブジェクトを含むPathメッセージで信号を送られたLSPが破棄されると、処理ノードは、以前に識別された関連する双方向LSPへのLSPのバインディングを削除するものとします（SHALL）。
No additional processing is needed for Path messages with an (Extended) ASSOCIATION Object containing an Association Type field set to "Double-Sided Associated Bidirectional LSP".
関連タイプフィールドが「両面関連付けられた双方向LSP」に設定された（拡張）ASSOCIATIONオブジェクトを含むパスメッセージの場合、追加の処理は必要ありません。
The ASSOCIATION Object has been defined in [RFC4872] and the Extended ASSOCIATION Object has been defined in [RFC6780], both with class numbers in the form 11bbbbbb, which ensures compatibility with non-supporting nodes. Per [RFC2205], such nodes will ignore the object but forward it without modification.
ASSOCIATIONオブジェクトは[RFC4872]で定義され、拡張ASSOCIATIONオブジェクトは[RFC6780]で定義されています。どちらも11bbbbbb形式のクラス番号で、サポートされていないノードとの互換性を保証します。 [RFC2205]に従い、そのようなノードはオブジェクトを無視しますが、変更せずに転送します。
Operators wishing to use a function supported by a particular Association Type SHOULD ensure that the type is supported on any node that is expected to act on the association [RFC6780].
特定のアソシエーションタイプでサポートされている関数を使用したいオペレータは、そのタイプがアソシエーションで動作することが期待されるすべてのノードでサポートされていることを保証する必要があります[RFC6780]。
An egress node that does not support the Association Types defined in this document is expected to return a PathErr with Error Code "Admission Control Failure" (1) [RFC2205] and Sub-code "Bad Association Type" (5) [RFC4872].
このドキュメントで定義されているアソシエーションタイプをサポートしない出力ノードは、エラーコード「Admission Control Failure」（1）[RFC2205]およびサブコード「Bad Association Type」（5）[RFC4872]のPathErrを返すことが期待されています。
LSP recovery as defined in [RFC4872] and [RFC4873] is not impacted by this document. The recovery mechanisms defined in [RFC4872] and [RFC4873] rely on the use of the (Extended) ASSOCIATION Objects, but they use a different value for Association Type; multiple ASSOCIATION Objects can be present in the LSP Path message and can coexist with the procedures defined in this document.
[RFC4872]と[RFC4873]で定義されているLSPリカバリは、このドキュメントの影響を受けません。 [RFC4872]と[RFC4873]で定義されている回復メカニズムは、（拡張）ASSOCIATIONオブジェクトの使用に依存していますが、アソシエーションタイプには異なる値を使用しています。 LSPパスメッセージには複数のASSOCIATIONオブジェクトを含めることができ、このドキュメントで定義されている手順と共存できます。
When a node initiates setup of an LSP using a Path message containing an ASSOCIATION or Extended ASSOCIATION Object, and the Association Type set to "Single-Sided Associated Bidirectional LSP", the Path message MUST carry the REVERSE_LSP Object to trigger creation of a reverse LSP on the egress node.
ノードがASSOCIATIONまたは拡張ASSOCIATIONオブジェクトを含むPathメッセージを使用してLSPのセットアップを開始し、Association Typeが "Single-Sided Associated Bidirectional LSP"に設定されている場合、PathメッセージはREVERSE_LSPオブジェクトを伝達してリバースLSPの作成をトリガーする必要があります出力ノード。
The REVERSE_LSP subobject MAY contain any of the objects that the initiating node desires to have included in the Path message for the associated reverse LSP. The REVERSE_LSP Object SHOULD NOT be included in a REVERSE_LSP Object.
REVERSE_LSPサブオブジェクトには、開始ノードが関連する逆LSPのPathメッセージに含めたいオブジェクトのいずれかが含まれる場合があります。 REVERSE_LSPオブジェクトはREVERSE_LSPオブジェクトに含まれるべきではありません。
A transit node receiving a valid Path message containing a REVERSE_LSP Object MUST forward the REVERSE_LSP Object unchanged in the outgoing Path message.
REVERSE_LSPオブジェクトを含む有効なPathメッセージを受信するトランジットノードは、発信PathメッセージでREVERSE_LSPオブジェクトを変更せずに転送する必要があります。
An egress node, upon receiving a Path message containing an REVERSE_LSP Object MUST verify that the Path message contains an ASSOCIATION or Extended ASSOCIATION Object with the Association Type set to "Single-Sided Associated Bidirectional LSP". If it does not, the Path message MUST NOT trigger a reverse LSP. This verification failure SHOULD NOT trigger any RSVP message but can be logged locally, and perhaps reported through network management mechanisms.
出力ノードは、REVERSE_LSPオブジェクトを含むPathメッセージを受信すると、そのPathメッセージに、関連付けタイプが「片面関連付けられた双方向LSP」に設定されたASSOCIATIONまたはExtended ASSOCIATIONオブジェクトが含まれていることを確認する必要があります。そうでない場合、Pathメッセージは逆LSPをトリガーしてはなりません（MUST NOT）。この検証の失敗は、RSVPメッセージをトリガーするべきではありませんが、ローカルでログに記録でき、おそらくネットワーク管理メカニズムを通じて報告できます。
Once validated, the egress node MUST create an LSP in the reverse direction or reject the Path message. If the creation of a reverse LSP fails, the egress node MUST return a PathErr with Error Code "Admission Control Failure" (1) [RFC2205] and Sub-code "Reverse LSP Failure" (6) defined in this document. Note that normal Resv processing SHOULD NOT be impacted by the presence of an ASSOCIATION Object with an Association Type set to "Single-Sided Associated Bidirectional LSP".
検証されると、出口ノードは逆方向にLSPを作成するか、Pathメッセージを拒否する必要があります。リバースLSPの作成が失敗した場合、出力ノードは、このドキュメントで定義されているエラーコード「Admission Control Failure」（1）[RFC2205]とサブコード「Reverse LSP Failure」（6）のPathErrを返す必要があります。通常のResv処理は、関連付けタイプが「片面の関連付けられた双方向LSP」に設定されたASSOCIATIONオブジェクトの存在によって影響されるべきではないことに注意してください。
The egress node MUST use the subobjects contained in the REVERSE_LSP Object for initiating the reverse LSP. When a subobject is not present in the received REVERSE_LSP Object, the egress node SHOULD initiate the reverse LSP based on the information contained in the received Path message of the forward LSP as follows:
出口ノードは、リバースLSPを開始するためにREVERSE_LSPオブジェクトに含まれるサブオブジェクトを使用する必要があります。サブオブジェクトが受信したREVERSE_LSPオブジェクトに存在しない場合、出力ノードは、次のように受信したフォワードLSPのPathメッセージに含まれる情報に基づいてリバースLSPを開始する必要があります（SHOULD）。
o The egress node SHOULD copy the information from the received SESSION_ATTRIBUTE, CLASS_TYPE, LABEL_REQUEST, ASSOCIATION, ADMIN_STATUS, and PROTECTION Objects in the forward LSP Path message to form the Path message of the reverse LSP when the object is not present in the received REVERSE_LSP Object.
o 出力ノードは、オブジェクトが受信したREVERSE_LSPオブジェクトに存在しない場合、受信したSESSION_ATTRIBUTE、CLASS_TYPE、LABEL_REQUEST、ASSOCIATION、ADMIN_STATUS、およびPROTECTIONオブジェクトから情報をコピーして、転送LSPパスメッセージのオブジェクトをリバースLSPのパスメッセージに形成します。
o The IP address in the reverse LSP's SESSION Object SHOULD be set to the IP address carried in the received SENDER_TEMPLATE Object; and conversely, the IP address in the SENDER_TEMPLATE Object SHOULD be set to the IP address carried in the received SESSION Object. There are no additional requirements related to the IDs carried in the SESSION and SENDER_TEMPLATE Objects.
o リバースLSPのSESSIONオブジェクトのIPアドレスは、受信したSENDER_TEMPLATEオブジェクトで運ばれるIPアドレスに設定する必要があります（SHOULD）。逆に、SENDER_TEMPLATEオブジェクトのIPアドレスは、受信したSESSIONオブジェクトで搬送されるIPアドレスに設定する必要があります（SHOULD）。 SESSIONおよびSENDER_TEMPLATEオブジェクトで伝達されるIDに関連する追加の要件はありません。
o When the forward LSP Path message contains a RECORD_ROUTE Object, the egress node SHOULD include the received RECORD_ROUTE Object in the reverse LSP Path message. Local node information SHOULD also be recorded per standard Path message processing.
o フォワードLSPパスメッセージにRECORD_ROUTEオブジェクトが含まれている場合、出力ノードは受信したRECORD_ROUTEオブジェクトをリバースLSPパスメッセージに含める必要があります（SHOULD）。ローカルノード情報は、標準のPathメッセージ処理ごとに記録する必要もあります（SHOULD）。
o There are no specific requirements related to other objects.
o 他のオブジェクトに関連する特定の要件はありません。
The resulting Path message is used to create the reverse LSP. From this point on, standard Path message processing is used in processing the resulting Path message.
結果のPathメッセージは、逆LSPを作成するために使用されます。これ以降、結果のパスメッセージの処理には標準のパスメッセージ処理が使用されます。
Note that the contents of a forward LSP, including a carried REVERSE_LSP Object, may change over the life of an LSP, and such changes MUST result in corresponding changes in the reverse LSP. In particular, any object or subobject that was copied during the creation of the initial reverse LSP's Path message MUST be copied when modified in the forward LSP, and a trigger Path message MUST be processed.
運ばれたREVERSE_LSPオブジェクトを含むフォワードLSPのコンテンツは、LSPの存続期間中に変更される可能性があり、そのような変更はリバースLSPの対応する変更をもたらす必要があることに注意してください。特に、最初のリバースLSPのPathメッセージの作成中にコピーされたオブジェクトまたはサブオブジェクトは、フォワードLSPで変更されたときにコピーされなければならず、トリガーPathメッセージが処理されなければなりません（MUST）。
The removal of the REVERSE_LSP Object in the received Path message SHOULD cause the egress node to tear down any previously established reverse LSP.
受信したPathメッセージのREVERSE_LSPオブジェクトを削除すると、出力ノードは以前に確立されたリバースLSPをすべて破棄する必要があります（SHOULD）。
When the egress node receives a PathTear message for the forward LSP or whenever the forward LSP is torn down, the node MUST remove the associated reverse LSP using standard PathTear message processing. Teardown of the reverse LSP for other reasons SHOULD NOT trigger removal of the initiating LSP, but it SHOULD result in the egress node sending a PathErr with Error Code "Admission Control Failure" (1) [RFC2205] and Sub-code "Reverse LSP Failure" (6) defined in this document.
出力ノードがフォワードLSPのPathTearメッセージを受信するとき、またはフォワードLSPが破棄されるときは常に、ノードは標準のPathTearメッセージ処理を使用して、関連するリバースLSPを削除する必要があります。その他の理由によるリバースLSPのティアダウンは、開始LSPの削除をトリガーしてはいけません（SHOULD NOT）。ただし、出力ノードは、エラーコード「Admission Control Failure」（1）[RFC2205]およびサブコード「Reverse LSP Failure」でPathErrを送信する必要があります"（6）このドキュメントで定義されています。
The REVERSE_LSP Object is defined with class numbers in the form 11bbbbbb, which ensures compatibility with non-supporting nodes. Per [RFC2205], such nodes will ignore the object but forward it without modification.
REVERSE_LSPオブジェクトは、11bbbbbbという形式のクラス番号で定義されます。これにより、サポートされていないノードとの互換性が確保されます。 [RFC2205]に従い、そのようなノードはオブジェクトを無視しますが、変更せずに転送します。
IANA has registered values for the namespace defined in this document and summarized in this section.
IANAは、このドキュメントで定義され、このセクションで要約されている名前空間の値を登録しています。
IANA maintains the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry (see <http://www.iana.org/assignments/gmpls-sig-parameters>). The "Association Type" subregistry is included in this registry.
IANAは「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Parameters」レジストリ（<http://www.iana.org/assignments/gmpls-sig-parameters>を参照）を維持しています。 「関連付けタイプ」サブレジストリは、このレジストリに含まれています。
This registry has been updated by new Association Types for ASSOCIATION and Extended ASSOCIATION Objects defined in this document as follows:
このレジストリは、このドキュメントで次のように定義されたASSOCIATIONおよび拡張ASSOCIATIONオブジェクトの新しい関連タイプによって更新されました。
Value Name Reference 3 Double-Sided Associated Bidirectional LSP (D) Section 4.2 4 Single-Sided Associated Bidirectional LSP (A) Section 4.2
値名リファレンス3両面関連双方向LSP（D）セクション4.2 4片面関連双方向LSP（A）セクション4.2
IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" registry (see <http://www.iana.org/assignments/rsvp-parameters>). The "Class Names, Class Numbers, and Class Types" subregistry is included in this registry.
IANAは「リソース予約プロトコル（RSVP）パラメータ」レジストリを維持します（<http://www.iana.org/assignments/rsvp-parameters>を参照）。 「クラス名、クラス番号、およびクラスタイプ」サブレジストリは、このレジストリに含まれています。
This registry has been extended for new Class Number (Class-Num) and Class Type (C-type) for RSVP REVERSE_LSP Object requested in the 11bbbbbb range defined in this document as follows:
このレジストリは、このドキュメントで次のように定義されている11bbbbbbの範囲で要求されたRSVP REVERSE_LSPオブジェクトの新しいクラス番号（Class-Num）およびクラスタイプ（C-type）に拡張されています。
Class Number Class Name Reference 203 REVERSE_LSP Section 4.4
クラス番号クラス名リファレンス203 REVERSE_LSPセクション4.4
o REVERSE_LSP : Class Type or C-type = 1
o REVERSE_LSP：クラスタイプまたはCタイプ= 1
IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" registry (see <http://www.iana.org/assignments/rsvp-parameters>). The "Error Codes and Globally-Defined Error Value Sub-Codes" subregistry is included in this registry.
IANAは「リソース予約プロトコル（RSVP）パラメータ」レジストリを維持します（<http://www.iana.org/assignments/rsvp-parameters>を参照）。 「エラーコードとグローバルに定義されたエラー値のサブコード」サブレジストリは、このレジストリに含まれています。
This registry has been extended for the new PathErr Sub-code defined in this document as follows:
このレジストリは、このドキュメントで定義されている新しいPathErrサブコード用に次のように拡張されています。
Error Code = 01: "Admission Control Failure" (see [RFC2205])
エラーコード= 01：「アドミッションコントロールの失敗」（[RFC2205]を参照）
o "Reverse LSP Failure" (6)
o 「逆LSP障害」（6）
This document introduces two new Association Types for the (Extended) ASSOCIATION Object, Double-Sided Associated Bidirectional LSP and Single-Sided Associated Bidirectional LSP. These types, by themselves, introduce no additional information to signaling. Related security considerations are already covered for this in RFC 6780.
このドキュメントでは、（拡張）ASSOCIATIONオブジェクトの2つの新しい関連タイプである両面関連双方向LSPと片面関連双方向LSPを紹介します。これらのタイプ自体は、シグナリングに追加情報を導入しません。関連するセキュリティ上の考慮事項は、RFC 6780で既にカバーされています。
The REVERSE_LSP Object is carried in the Path message of a forward LSP of the single-sided associated bidirectional LSP. It can carry parameters for the reverse LSP. This does allow for additional information to be conveyed, but this information is not fundamentally different from the information that is already carried in a bidirectional LSP message. The processing of such messages is already subject to local policy as well as security considerations discussions. For a general discussion on MPLS- and GMPLS-related security issues, see the MPLS/GMPLS security framework [RFC5920].
REVERSE_LSPオブジェクトは、片側に関連付けられた双方向LSPの転送LSPのPathメッセージで伝達されます。リバースLSPのパラメータを伝送できます。これにより、追加の情報を伝達できますが、この情報は、双方向LSPメッセージですでに伝送されている情報と基本的には異なりません。そのようなメッセージの処理は、ローカルポリシーとセキュリティの考慮事項の議論の対象となっています。 MPLSおよびGMPLS関連のセキュリティ問題に関する一般的な説明については、MPLS / GMPLSセキュリティフレームワーク[RFC5920]を参照してください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <http://www.rfc-editor.org/info/rfc2205>.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、and S. Jamin、 "Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification"、RFC 2205、DOI 10.17487 / RFC2205、1997年9月、<http://www.rfc-editor.org/info/rfc2205>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<http://www.rfc-editor.org/info/rfc3209>。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473] Berger、L.、Ed。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、DOI 10.17487 / RFC3473、2003年1月、<http： //www.rfc-editor.org/info/rfc3473>。
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, <http://www.rfc-editor.org/info/rfc4872>.
[RFC4872] Lang、J。、編、Rekhter、Y。、編、およびD. Papadimitriou、編、「エンドツーエンドの汎用マルチプロトコルラベルスイッチング（GMPLS）リカバリをサポートするRSVP-TE拡張"、RFC 4872、DOI 10.17487 / RFC4872、2007年5月、<http://www.rfc-editor.org/info/rfc4872>。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, May 2007, <http://www.rfc-editor.org/info/rfc4873>.
[RFC4873] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「GMPLS Segment Recovery」、RFC 4873、DOI 10.17487 / RFC4873、2007年5月、<http：//www.rfc-editor .org / info / rfc4873>。
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <http://www.rfc-editor.org/info/rfc5511>.
[RFC5511] Farrel、A。、「Routing Backus-Naur Form（RBNF）：A Syntax Using Forming Encoding Rules in Various Routing Protocol Specifications」、RFC 5511、DOI 10.17487 / RFC5511、2009年4月、<http：// www。 rfc-editor.org/info/rfc5511>。
[RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP ASSOCIATION Object Extensions", RFC 6780, DOI 10.17487/RFC6780, October 2012, <http://www.rfc-editor.org/info/rfc6780>.
[RFC6780] Berger、L.、Le Faucheur、F。、およびA. Narayanan、「RSVP ASSOCIATION Object Extensions」、RFC 6780、DOI 10.17487 / RFC6780、2012年10月、<http://www.rfc-editor.org/ info / rfc6780>。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<http：// www.rfc-editor.org/info/rfc4655>。
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, February 2009, <http://www.rfc-editor.org/info/rfc5420>.
[RFC5420] Farrel、A.、Ed。、Papadimitriou、D.、Vasseur、JP。、およびA. Ayyangarps、「Resource Reservation Protocol Traffic Engineering（RSVP-TE）を使用したMPLS LSP確立のための属性のエンコーディング」、RFC 5420、 DOI 10.17487 / RFC5420、2009年2月、<http://www.rfc-editor.org/info/rfc5420>。
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, DOI 10.17487/RFC5654, September 2009, <http://www.rfc-editor.org/info/rfc5654>.
[RFC5654] Niven-Jenkins、B.、Ed。、Brungard、D.、Ed。、Betts、M.、Ed。、Sprecher、N.、and S. Ueno、 "Requirements of an MPLS Transport Profile"、RFC 5654 、DOI 10.17487 / RFC5654、2009年9月、<http://www.rfc-editor.org/info/rfc5654>。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<http://www.rfc-editor.org/info/rfc5920>。
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, DOI 10.17487/RFC6370, September 2011, <http://www.rfc-editor.org/info/rfc6370>.
[RFC6370] Bocci、M.、Swallow、G。、およびE. Gray、「MPLS Transport Profile（MPLS-TP）Identifiers」、RFC 6370、DOI 10.17487 / RFC6370、2011年9月、<http：//www.rfc- editor.org/info/rfc6370>。
[RFC6373] Andersson, L., Ed., Berger, L., Ed., Fang, L., Ed., Bitar, N., Ed., and E. Gray, Ed., "MPLS Transport Profile (MPLS-TP) Control Plane Framework", RFC 6373, DOI 10.17487/RFC6373, September 2011, <http://www.rfc-editor.org/info/rfc6373>.
[RFC6373] Andersson、L.、Ed。、Berger、L.、Ed。、Fang、L.、Ed。、Bitar、N.、Ed。、and E. Gray、Ed。、 "MPLS Transport Profile（MPLS- TP）コントロールプレーンフレームワーク」、RFC 6373、DOI 10.17487 / RFC6373、2011年9月、<http://www.rfc-editor.org/info/rfc6373>。
[RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC 6387, DOI 10.17487/RFC6387, September 2011, <http://www.rfc-editor.org/info/rfc6387>.
[RFC6387] Takacs、A.、Berger、L.、Caviglia、D.、Fedyk、D。、およびJ. Meuric、「GMPLS非対称帯域幅双方向ラベルスイッチドパス（LSP）」、RFC 6387、DOI 10.17487 / RFC6387、9月2011、<http://www.rfc-editor.org/info/rfc6387>。
[RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC 6689, DOI 10.17487/RFC6689, July 2012, <http://www.rfc-editor.org/info/rfc6689>.
[RFC6689] Berger、L。、「RSVP ASSOCIATIONオブジェクトの使用」、RFC 6689、DOI 10.17487 / RFC6689、2012年7月、<http://www.rfc-editor.org/info/rfc6689>。
Acknowledgements
謝辞
The authors would like to thank Lou Berger and George Swallow for their great guidance in this work; Jie Dong for the discussion of the recovery LSP; Lamberto Sterling for his valuable comments about asymmetric bandwidth signaling; Attila Takacs for the discussion of the provisioning model; Siva Sivabalan, Eric Osborne, and Robert Sawaya for the discussions on the ASSOCIATION Object; and Matt Hartley for providing useful suggestions on the document. At the same time, the authors would like to acknowledge the contributions of Bo Wu, Xihua Fu, and Lizhong Jin for the initial discussions; Wenjuan He for the prototype implementation; and Lou Berger, Daniel King, and Deborah Brungard for the review of the document.
著者は、この作業の優れたガイダンスを提供してくれたLou BergerとGeorge Swallowに感謝します。回復LSPの議論のためのJie Dong; Lamberto Sterling氏は、非対称帯域幅シグナリングに関する貴重なコメントを寄せてくれました。プロビジョニングモデルの説明についてはAttila Takacs氏。 ASSOCIATIONオブジェクトに関する議論については、Siva Sivabalan、Eric Osborne、Robert Sawayaの各氏。そして、ドキュメントに関する有用な提案を提供してくれたMatt Hartley氏。同時に、著者たちは、Bo Wu、Xihua Fu、およびLizhong Jinの最初の議論への貢献を認めたいと思います。 Wenjuan彼はプロトタイプの実装を担当しました。文書のレビューには、Lou Berger、Daniel King、Deborah Brungard。
Contributors
貢献者
Fan Yang ZTE
ヤンZTEファン
EMail: yang.fan240347@gmail.com
Weilian Jiang ZTE
ジャンZT Eとウェイ
EMail: jiang.weilian@gmail.com
Authors' Addresses
著者のアドレス
Fei Zhang (editor) Huawei
Fe i Zhang（editor）hu A is
EMail: zhangfei7@huawei.com
Ruiquan Jing China Telecom
中国通信
EMail: jingrq@ctbri.com.cn
Rakesh Gandhi (editor) Cisco Systems
Rakesh Gandhi（編集者）Cisco Systems
EMail: rgandhi@cisco.com