[要約] RFC 6689は、RSVP ASSOCIATIONオブジェクトの使用方法に関するガイドラインです。このRFCの目的は、RSVPプロトコルの拡張機能を提供し、ネットワークリソースの効率的な利用を促進することです。
Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 6689 LabN
Category: Informational July 2012
ISSN: 2070-1721
Usage of the RSVP ASSOCIATION Object
RSVP ASSOCIATIONオブジェクトの使用
Abstract
概要
The Resource Reservation Protocol (RSVP) ASSOCIATION object is defined in the context of GMPLS-controlled label switched paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This document reviews how the association is to be provided in the context of GMPLS recovery. No new procedures or mechanisms are defined by this document, and it is strictly informative in nature.
リソース予約プロトコル（RSVP）ASSOCIATIONオブジェクトは、GMPLS制御のラベルスイッチドパス（LSP）のコンテキストで定義されます。このコンテキストでは、オブジェクトは、回復LSPと保護LSPを関連付けるために使用されます。このドキュメントでは、GMPLSリカバリのコンテキストで関連付けがどのように提供されるかについて説明します。このドキュメントでは新しい手順やメカニズムは定義されておらず、本質的に情報提供のみを目的としています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc6689.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6689で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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 ....................................................2
2. Background ......................................................2
2.1. LSP Association ............................................3
2.2. End-to-End Recovery LSP Association ........................4
2.3. Segment Recovery LSP Association ...........................7
2.4. Resource Sharing LSP Association ...........................8
3. Association of GMPLS Recovery LSPs ..............................8
4. Security Considerations ........................................10
5. Acknowledgments ................................................10
6. References .....................................................10
6.1. Normative References ......................................10
6.2. Informative References ....................................11
End-to-end and segment recovery are defined for GMPLS-controlled label switched paths (LSPs) in [RFC4872] and [RFC4873], respectively. Both definitions use the ASSOCIATION object to associate recovery LSPs with the LSP they are protecting. This document provides additional narrative on how such associations are to be identified. This document does not define any new procedures or mechanisms and is strictly informative in nature.
エンドツーエンドとセグメントの回復は、[RFC4872]と[RFC4873]でそれぞれGMPLS制御のラベルスイッチドパス（LSP）に対して定義されています。どちらの定義も、ASSOCIATIONオブジェクトを使用して、回復LSPと保護LSPを関連付けます。このドキュメントは、そのような関連付けがどのように識別されるかに関する追加の説明を提供します。このドキュメントでは、新しい手順やメカニズムは定義されておらず、本質的に情報提供のみを目的としています。
It may not be immediately obvious to the informed reader why this document is necessary; however, questions were repeatedly raised in the Common Control and Measurement Plane (CCAMP) working group on the proper interpretation of the ASSOCIATION object in the context of end-to-end and segment recovery, and the working group agreed that this document should be produced in order to close the matter. This document formalizes the explanation provided in an e-mail to the working group authored by Adrian Farrel, see [AF-EMAIL]. This document in no way modifies the normative definitions of end-to-end and segment recovery, see [RFC4872] or [RFC4873].
このドキュメントが必要な理由は、十分な情報を得た読者にはすぐにはわからない場合があります。ただし、共通制御および測定面（CCAMP）ワーキンググループでは、エンドツーエンドおよびセグメントリカバリのコンテキストでのASSOCIATIONオブジェクトの適切な解釈について質問が繰り返し出され、ワーキンググループはこの文書を作成する必要があることに同意しました問題を解決するために。このドキュメントは、Adrian Farrelによって作成されたワーキンググループへの電子メールで提供される説明を形式化しています。[AF-EMAIL]を参照してください。このドキュメントは、エンドツーエンドおよびセグメントリカバリの標準的な定義を決して変更しません。[RFC4872]または[RFC4873]を参照してください。
This section reviews the definition of LSP association in the contexts of end-to-end and segment recovery as defined in [RFC4872] and [RFC4873]. This section merely reiterates what has been defined; if differences exist between this text and [RFC4872] or [RFC4873], the earlier RFCs provide the authoritative text.
このセクションでは、[RFC4872]と[RFC4873]で定義されているエンドツーエンドとセグメントの回復のコンテキストにおけるLSPアソシエーションの定義をレビューします。このセクションでは、定義されている内容を単に繰り返します。このテキストと[RFC4872]または[RFC4873]の間に相違がある場合、以前のRFCが信頼できるテキストを提供します。
[RFC4872] introduces the concept and mechanisms to support the association of one LSP to another LSP across different RSVP - Traffic Engineering (RSVP-TE) sessions. Such association is enabled via the introduction of the ASSOCIATION object. The ASSOCIATION object is defined in Section 16 of [RFC4872]. It is explicitly defined as having both general application and specific use within the context of recovery. End-to-end recovery usage is defined in [RFC4872] and is covered in Section 2.2 of this document. Segment recovery usage is defined in [RFC4873] and is covered in Section 2.3 of this document. Resource sharing type LSP association is also defined in [RFC4873]. While strictly speaking, such association is beyond the scope of this document, it is covered in Section 2.4 of this document for completeness. The remainder of this section covers generic usage of the ASSOCIATION object.
[RFC4872]は、異なるRSVP-トラフィックエンジニアリング（RSVP-TE）セッション全体で、あるLSPと別のLSPの関連付けをサポートするための概念とメカニズムを紹介しています。このような関連付けは、ASSOCIATIONオブジェクトの導入によって有効になります。 ASSOCIATIONオブジェクトは、[RFC4872]のセクション16で定義されています。これは、リカバリのコンテキスト内で一般的なアプリケーションと特定の用途の両方を持つことを明示的に定義されています。エンドツーエンドのリカバリの使用法は[RFC4872]で定義されており、このドキュメントのセクション2.2で説明されています。セグメント回復の使用法は[RFC4873]で定義されており、このドキュメントのセクション2.3で説明されています。リソース共有タイプLSPアソシエーションも[RFC4873]で定義されています。厳密に言えば、そのような関連付けはこのドキュメントの範囲を超えていますが、完全を期すために、このドキュメントのセクション2.4で取り上げています。このセクションの残りの部分では、ASSOCIATIONオブジェクトの一般的な使用法について説明します。
In general, LSP association using the ASSOCIATION object can take place based on the values carried in the ASSOCIATION object. This means that association between LSPs can take place independently of and across different sessions. This is a significant enhancement from the association of LSPs that is possible in base MPLS [RFC3209] and GMPLS [RFC3473].
一般に、ASSOCIATIONオブジェクトを使用したLSP関連付けは、ASSOCIATIONオブジェクトに含まれる値に基づいて実行できます。つまり、LSP間の関連付けは、異なるセッションとは無関係に、また異なるセッション間で行うことができます。これは、基本MPLS [RFC3209]およびGMPLS [RFC3473]で可能なLSPの関連付けからの重要な拡張です。
When using the ASSOCIATION object, LSP association is always initiated by an upstream node that inserts appropriate ASSOCIATION objects in the Path message of LSPs that are to be associated. Downstream nodes then correlate LSPs based on received ASSOCIATION objects. Multiple types of LSP association are supported by the ASSOCIATION object, and downstream correlation is made based on the type.
ASSOCIATIONオブジェクトを使用する場合、LSPアソシエーションは常に、関連付けられるLSPのPathメッセージに適切なASSOCIATIONオブジェクトを挿入する上流ノードによって開始されます。次に、ダウンストリームノードは、受信したASSOCIATIONオブジェクトに基づいてLSPを関連付けます。 ASSOCIATIONオブジェクトでは複数のタイプのLSPアソシエーションがサポートされており、ダウンストリーム相関はタイプに基づいて行われます。
[RFC4872] defines Class Types (C-Types) 1 and 2 of the ASSOCIATION object. Both objects have essentially the same semantics, only differing in the type of address carried (IPv4 and IPv6). The defined objects carry multiple fields. The fields, taken together, enable the identification of which LSPs are in association with one another. The [RFC4872]-defined fields are:
[RFC4872]は、ASSOCIATIONオブジェクトのクラスタイプ（Cタイプ）1および2を定義します。両方のオブジェクトは本質的に同じセマンティクスを持ち、運ばれるアドレスのタイプ（IPv4とIPv6）のみが異なります。定義されたオブジェクトには複数のフィールドがあります。これらのフィールドを組み合わせることで、相互に関連付けられているLSPを識別できます。 [RFC4872]で定義されているフィールドは次のとおりです。
o Association Type: This field identifies the usage, or application, of the ASSOCIATION object. The currently defined values are "Recovery" [RFC4872] and "Resource Sharing" [RFC4873]. This field also scopes the interpretation of the object. In other words, the type field is included when matching LSPs (i.e., the type fields must match), and the way associations are identified may be type dependent.
o 関連タイプ：このフィールドは、ASSOCIATIONオブジェクトの使用法またはアプリケーションを識別します。現在定義されている値は、「回復」[RFC4872]と「リソース共有」[RFC4873]です。このフィールドは、オブジェクトの解釈のスコープにもなります。言い換えると、タイプフィールドはLSPの一致時に含まれます（つまり、タイプフィールドは一致する必要があります）。関連付けの識別方法はタイプに依存する場合があります。
o Association Source: This field is used to provide global scope (within the address space) to the identified association. There are no specific rules in the general case for which an address should be used by a node creating an ASSOCIATION object beyond that the address is "associated to the node that originated the association", see [RFC4872].
o Association Source：このフィールドは、識別された関連付けに（アドレス空間内の）グローバルスコープを提供するために使用されます。 ASSOCIATIONオブジェクトを作成するノードがアドレスを使用する一般的なケースでは、アドレスが「関連付けを開始したノードに関連付けられている」という特定の規則はありません。[RFC4872]を参照してください。
o Association ID: This field provides an "identifier" that further scopes an association. Again, this field is combined with the other ASSOCIATION object fields to support identification of associated LSPs. The generic definition does not provide any specific rules on how matching is to be done, so such rules are governed by the Association Type. Note that the definition permits the association of an arbitrary number of LSPs.
o 関連付けID：このフィールドは、関連付けの範囲をさらに広げる「識別子」を提供します。ここでも、このフィールドは他のASSOCIATIONオブジェクトフィールドと組み合わされて、関連付けられたLSPの識別をサポートします。一般的な定義では、マッチングの実行方法に関する特定のルールは提供されないため、そのようなルールは関連タイプによって管理されます。この定義では、任意の数のLSPを関連付けることができます。
As defined, the ASSOCIATION object may only be carried in a Path message, so LSP association takes place based on the Path state. The definition permits one or more objects to be present. The support for multiple objects enables an LSP to be associated with other LSPs in more than one way at a time. For example, an LSP may carry one ASSOCIATION object to associate the LSP with another LSP for end-to-end recovery, and at the same time carry a second ASSOCIATION object to associate the LSP with another LSP for segment recovery, and at the same time carry a third ASSOCIATION object to associate the LSP with yet another LSP for resource sharing.
定義されているように、ASSOCIATIONオブジェクトはPathメッセージでのみ伝送される可能性があるため、LSPアソシエーションはPath状態に基づいて行われます。この定義により、1つ以上のオブジェクトが存在できるようになります。複数のオブジェクトのサポートにより、LSPを一度に複数の方法で他のLSPに関連付けることができます。たとえば、LSPは1つのASSOCIATIONオブジェクトを運んでLSPを別のLSPに関連付けてエンドツーエンドの回復を行い、同時に2番目のASSOCIATIONオブジェクトを運んでLSPを別のLSPに関連付けてセグメントの回復を行うことができます。 LSPをリソース共有のためのさらに別のLSPに関連付けるために、3番目のASSOCIATIONオブジェクトを持ちます。
The association of LSPs in support of end-to-end LSP recovery is defined in Section 16.2 of [RFC4872]. There are also several additional related conformance statements (i.e., use of [RFC2119] defined key words) in Sections 7.3, 8.3, 9.3, and 11.1 of [RFC4872]. When analyzing the definition, as with any Standards Track RFC, it is critical to note and differentiate which statements are made using [RFC2119] defined key words, which relate to conformance, and which statements are made without such key words, and are thereby only informative in nature.
エンドツーエンドのLSPリカバリをサポートするLSPの関連付けは、[RFC4872]のセクション16.2で定義されています。 [RFC4872]のセクション7.3、8.3、9.3、および11.1には、いくつかの追加の関連適合ステートメント（つまり、[RFC2119]で定義されたキーワードの使用）もあります。標準トラックRFCと同様に、定義を分析するときは、[RFC2119]で定義されたキーワードを使用して作成されたステートメント、適合性に関連するステートメント、およびそのようなキーワードなしで作成されたため、本質的に有益。
As defined in Section 16.2, end-to-end recovery-related LSP association may take place in two distinct forms:
セクション16.2で定義されているように、エンドツーエンドのリカバリ関連のLSPアソシエーションは、2つの異なる形式で行われる場合があります。
a. Between multiple (one or more) working LSPs and a single shared (associated) recovery LSP. This form essentially matches the shared 1:N (N >= 1) recovery type described in the other sections of [RFC4872].
a. 複数の（1つ以上の）動作中のLSPと単一の共有（関連付けられた）回復LSPの間。この形式は基本的に、[RFC4872]の他のセクションで説明されている共有1：N（N> = 1）回復タイプと一致します。
b. Between a single working LSP and multiple (one or more) recovery LSPs. This form essentially matches all other recovery types described in [RFC4872].
b. 単一の動作中のLSPと複数（1つ以上）の回復LSPの間。この形式は基本的に、[RFC4872]で説明されている他のすべての回復タイプと一致します。
Both forms share the same Association Type (Recovery) and the same Association Source (the working LSP's tunnel sender address). They also share the same definition of the Association ID, which is (quoting [RFC4872]):
どちらの形式も、同じアソシエーションタイプ（回復）と同じアソシエーションソース（動作中のLSPのトンネル送信者アドレス）を共有します。また、アソシエーションIDの同じ定義（[RFC4872]を引用）も共有しています。
The Association ID MUST be set to the LSP ID of the LSP being protected by this LSP or the LSP protecting this LSP. If unknown, this value is set to its own signaled LSP_ID value (default). Also, the value of the Association ID MAY change during the lifetime of the LSP.
アソシエーションIDは、このLSPによって保護されているLSPまたはこのLSPを保護しているLSPのLSP IDに設定する必要があります。不明な場合、この値は、それ自体のシグナル送信されたLSP_ID値に設定されます（デフォルト）。また、Association IDの値は、LSPの有効期間中に変更される場合があります。
The interpretation of the above is fairly straightforward. The Association ID carries one of three values: - The LSP ID of the LSP being protected. - The LSP ID of the protection LSP. - In the case where the matching LSP is not yet known (i.e., initiated), the LSP ID value of the LSP itself.
上記の解釈はかなり簡単です。アソシエーションIDには、次の3つの値のいずれかが含まれます。-保護されているLSPのLSP ID。 -保護LSPのLSP ID。 -一致するLSPがまだ知られていない（つまり、開始されている）場合、LSP自体のLSP ID値。
The text also explicitly allows for changing the Association ID during the lifetime of an LSP. However, this is only an option, and is neither required (i.e., "MUST") nor recommended (i.e., "SHOULD"). It should be noted that [RFC4872] does not describe when such a change should be initiated or the procedures for executing such a change. Clearly, care needs to be taken when changing the Association ID to ensure that the old association is not lost during the transition to a new association.
このテキストでは、LSPの有効期間中にアソシエーションIDを変更することも明示的に許可されています。ただし、これはオプションにすぎず、必須（「MUST」）でも推奨（「SHOULD」）でもありません。 [RFC4872]は、そのような変更をいつ開始するか、またはそのような変更を実行する手順については説明していないことに注意してください。明らかに、新しいアソシエーションへの移行中に古いアソシエーションが失われないように、アソシエーションIDを変更するときは注意が必要です。
The text does not preclude, and it is therefore assumed, that one or more ASSOCIATION objects may also be added to an LSP that was originated without any ASSOCIATION objects. Again, this is a case that is not explicitly discussed in [RFC4872].
このテキストは除外するものではないため、1つ以上のASSOCIATIONオブジェクトを、ASSOCIATIONオブジェクトなしで作成されたLSPに追加することもできます。繰り返しますが、これは[RFC4872]で明示的に説明されていないケースです。
From the above, this means that the following combinations may occur:
上記から、これは次の組み合わせが発生する可能性があることを意味します：
Case 1. When the ASSOCIATION object of the LSP being protected is initialized before the ASSOCIATION objects of any recovery LSPs are initialized, the Association ID in the LSP being protected and any recovery LSPs will carry the same value, and this value will be the LSP ID value of the LSP being protected.
ケース1.保護されているLSPのASSOCIATIONオブジェクトが初期化されてから、回復LSPのASSOCIATIONオブジェクトが初期化される場合、保護されているLSPのアソシエーションIDと回復LSPは同じ値を持ち、この値がLSPになります。保護されているLSPのID値。
Case 2. When the ASSOCIATION object of a recovery LSP is initialized before the ASSOCIATION object of any protected LSP is initialized, the Association ID in the recovery LSP and any LSPs being protected by that LSP will carry the same value, and this value will be the LSP ID value of the recovery LSP.
ケース2.保護LSPのASSOCIATIONオブジェクトが初期化される前に回復LSPのASSOCIATIONオブジェクトが初期化されると、回復LSPのアソシエーションIDとそのLSPによって保護されているすべてのLSPは同じ値を持ち、この値はリカバリLSPのLSP ID値。
Case 3. When the ASSOCIATION objects of both the LSP being protected and the recovery LSP are concurrently initialized, the value of the Association ID carried in the LSP being protected is the LSP ID value of the recovery LSP, and the value of the Association ID carried in the recovery LSP is the LSP ID value of the LSP being protected. As this case can only be applied to LSPs with matching tunnel sender addresses, the scope of this case is limited to end-to-end recovery. Note that this is implicit in [RFC4872], as its scope is limited to end-to-end recovery.
ケース3.保護されているLSPとリカバリLSPの両方のASSOCIATIONオブジェクトが同時に初期化される場合、保護されているLSPで伝送されるアソシエーションIDの値は、リカバリLSPのLSP ID値とアソシエーションIDの値です。回復LSPに含まれるのは、保護されているLSPのLSP ID値です。このケースは一致するトンネル送信者アドレスを持つLSPにのみ適用できるため、このケースの範囲はエンドツーエンドの回復に限定されます。これは[RFC4872]で暗黙的に行われていることに注意してください。その範囲はエンドツーエンドの回復に限定されているためです。
In practical terms, Case 2 will only occur when using the shared 1:N (N >= 1) end-to-end recovery type, and Case 1 will occur with all other end-to-end recovery types. Case 3 is allowed, and it is subject to interpretation as to how often it will occur. Some believe that this will be the common case and, furthermore, that working and recovery LSPs will often first be initiated without any ASSOCIATION objects, and then Case 3 objects will be added once the LSPs are established. Others believe that Case 3 will rarely, if ever occur. Such perspectives have little impact on interoperability, as an [RFC4872]-compliant implementation needs to properly handle (identify associations for) all three cases.
実際的には、ケース2は共有1：N（N> = 1）エンドツーエンドリカバリタイプを使用する場合にのみ発生し、ケース1は他のすべてのエンドツーエンドリカバリタイプで発生します。ケース3は許可され、それがどのくらいの頻度で発生するかに関する解釈の対象となります。これが一般的なケースであると信じている人もいます。さらに、作業およびリカバリLSPは多くの場合、最初にASSOCIATIONオブジェクトなしで開始され、LSPが確立されるとケース3オブジェクトが追加されると信じています。また、ケース3が発生することはまれであると信じている人もいます。 [RFC4872]に準拠した実装では3つのケースすべてを適切に処理する（関連付けを識別する）必要があるため、このような視点は相互運用性にほとんど影響を与えません。
It is important to note that Section 16.2 of [RFC4872] provides no further requirements on how or when the Association ID value is to be selected. The other sections of the document do provide further narrative and three additional requirements. In general, the narrative highlights Case 3 identified above but does not preclude the other cases. The three additional requirements are, by [RFC4872] section number:
[RFC4872]のセクション16.2では、アソシエーションIDの値を選択する方法とタイミングについての追加の要件は提供されていないことに注意してください。ドキュメントの他のセクションでは、さらに説明と3つの追加要件を提供します。一般的に、ナラティブは上記で識別されたケース3を強調していますが、他のケースを排除するものではありません。 [RFC4872]セクション番号による3つの追加要件は次のとおりです。
o Section 7.3 -- "The Association ID MUST be set by default to the LSP ID of the protected LSP corresponding to N = 1."
o セクション7.3-「アソシエーションIDは、デフォルトで、N = 1に対応する保護されたLSPのLSP IDに設定する必要があります。」
When considering this statement together with the three cases enumerated above, it can be seen that this statement clarifies which LSP ID value should be used when a single shared protection LSP is established simultaneously with Case 3, or after Case 2, and with more than one LSP to be protected.
このステートメントを上記の3つのケースと一緒に検討すると、このステートメントは、単一の共有保護LSPがケース3と同時に、またはケース2の後に確立され、複数のLSP ID値が使用される場合に、どのLSP ID値を使用する必要があるかを明らかにすることがわかります。保護するLSP。
o Section 8.3 -- "Secondary protecting LSPs are signaled by setting in the new PROTECTION object the S bit and the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated primary working LSP_ID, which MUST be known before signaling of the secondary LSP."
o セクション8.3-「セカンダリ保護LSPは、新しいPROTECTIONオブジェクトでSビットとPビットを1に設定し、ASSOCIATIONオブジェクトで、関連付けられたプライマリワーキングLSP_IDへのアソシエーションIDを通知します。セカンダリLSP。」
This requirement clarifies that when using the "Rerouting without Extra-Traffic" type of recovery, it is required to follow either Case 1 or 3, but not 2, as enumerated above.
この要件は、「追加トラフィックなしの再ルーティング」タイプのリカバリを使用する場合、上記で列挙したように、2ではなく、ケース1または3のいずれかに従う必要があることを明確にします。
o Section 9.3 -- "Secondary protecting LSPs are signaled by setting in the new PROTECTION object the S bit and the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated primary working LSP_ID, which MUST be known before signaling of the secondary LSP."
o セクション9.3-「2次保護LSPは、新しいPROTECTIONオブジェクトでSビットとPビットを1に設定することによって通知され、ASSOCIATIONオブジェクトでは、関連付けられたプライマリの動作LSP_IDへのアソシエーションIDが通知されます。セカンダリLSP。」
This requirement clarifies that when using the "Shared-Mesh Restoration" type of recovery, it is required to follow either Case 1 or 3, but not 2, as enumerated above.
この要件は、「共有メッシュ復元」タイプのリカバリを使用する場合、上記で列挙したように、2ではなく、ケース1または3のいずれかに従う必要があることを明確にします。
o Section 11.1 -- "In both cases, the Association ID of the ASSOCIATION object MUST be set to the LSP ID value of the signaled LSP."
o セクション11.1-「どちらの場合でも、ASSOCIATIONオブジェクトのアソシエーションIDは、シグナリングされたLSPのLSP ID値に設定する必要があります。」
This requirement clarifies that when using the "LSP Rerouting" type of recovery, it is required to follow either Case 1 or 3, but not 2, as enumerated above.
この要件は、「LSP Rerouting」タイプのリカバリを使用する場合、上記で列挙したように、2ではなくCase 1または3のいずれかに従う必要があることを明確にします。
GMPLS segment recovery is defined in [RFC4873]. Segment recovery reuses the LSP association mechanisms, including the Association Type field value, defined in [RFC4872]. The primary text to this effect in [RFC4873] is:
GMPLSセグメントの回復は[RFC4873]で定義されています。セグメント回復は、[RFC4872]で定義されているAssociation Typeフィールド値を含むLSPアソシエーションメカニズムを再利用します。 [RFC4873]におけるこの効果の主要なテキストは次のとおりです。
3.2.1. Recovery Type Processing
3.2.1. 回復タイプの処理
Recovery type processing procedures are the same as those defined in [RFC4872], but processing and identification occur with respect to segment recovery LSPs. Note that this means that multiple ASSOCIATION objects of type recovery may be present on an LSP.
回復タイプの処理手順は[RFC4872]で定義されているものと同じですが、処理と識別はセグメント回復LSPに関して行われます。これは、回復タイプの複数のASSOCIATIONオブジェクトがLSPに存在する可能性があることを意味することに注意してください。
This statement means that Case 2, as enumerated above, is to be followed; furthermore, the Association Source is set to the tunnel sender address of the segment recovery LSPs. The explicit exclusion of Case 3 is not listed, as its non-applicability is considered obvious to the informed reader. (Perhaps having this exclusion explicitly identified would have obviated the need for this document.)
このステートメントは、上記で列挙したケース2に従うことを意味します。さらに、アソシエーションソースは、セグメントリカバリLSPのトンネル送信者アドレスに設定されます。ケース3の明示的な除外は、その非適用性が情報を得た読者に明白であると見なされるため、リストされていません。 （おそらく、この除外が明示的に識別されていれば、このドキュメントの必要性はなくなります。）
Section 3.2.2 of [RFC4873] defines an additional type of LSP association that is used for "Resource Sharing". Resource sharing enables the sharing of resources across LSPs with different SESSION objects. Without this object, only sharing across LSPs with a shared SESSION object is possible, see [RFC3209].
[RFC4873]のセクション3.2.2は、「リソース共有」に使用される追加タイプのLSPアソシエーションを定義しています。リソース共有により、異なるSESSIONオブジェクトを持つLSP間でリソースを共有できます。このオブジェクトがなければ、共有されたSESSIONオブジェクトを持つLSP間の共有のみが可能です。[RFC3209]を参照してください。
Resource sharing is indicated using a new Association Type value. As the Association Type field value is not the same as what is used in recovery type LSP association, the semantics used for the association of LSPs using an ASSOCIATION object containing the new type differs from recovery type LSP association.
リソースの共有は、新しいAssociation Type値を使用して示されます。 Association Typeフィールドの値は、リカバリタイプLSPアソシエーションで使用されるものと同じではないため、新しいタイプを含むASSOCIATIONオブジェクトを使用したLSPのアソシエーションに使用されるセマンティクスは、リカバリタイプLSPアソシエーションとは異なります。
Section 3.2.2 of [RFC4873] states the following rules for the construction of an ASSOCIATION object in support of resource sharing type LSP association:
[RFC4873]のセクション3.2.2は、リソース共有タイプLSPアソシエーションをサポートするASSOCIATIONオブジェクトの構築に関する次のルールを述べています。
o The Association Type value is set to "Resource Sharing".
o 関連タイプの値は「リソース共有」に設定されています。
o Association Source is set to the originating node's router address.
o アソシエーションソースは、発信元ノードのルーターアドレスに設定されます。
o The Association ID is set to a value that uniquely identifies the set of LSPs to be associated.
o アソシエーションIDは、関連付けられる一連のLSPを一意に識別する値に設定されます。
The setting of the Association ID value to the working LSP's LSP ID value is mentioned, but using the "MAY" key word. Per [RFC2119], this translates to the use of the LSP ID value as being completely optional and that the choice of Association ID is truly up to the originating node.
アソシエーションID値から現用LSPのLSP ID値への設定について説明していますが、「MAY」キーワードを使用しています。 [RFC2119]によれば、これはLSP ID値の使用が完全にオプションであり、アソシエーションIDの選択は本当に発信元ノード次第であると解釈されます。
Additionally, the identical ASSOCIATION object is used for all LSPs that should be associated using Resource Sharing. This differs from recovery type LSP association where it is possible for the LSPs to carry different Association ID fields and still be associated (see Case 3 in Section 2.2).
さらに、リソース共有を使用して関連付ける必要があるすべてのLSPに、同じASSOCIATIONオブジェクトが使用されます。これは、LSPが異なるアソシエーションIDフィールドを保持していても関連付けられている可能性があるリカバリタイプLSPアソシエーションとは異なります（セクション2.2のケース3を参照）。
The previous section reviews the construction of an ASSOCIATION object, including the selection of the value used in the Association ID field, as defined in [RFC4872] and [RFC4873]. This section reviews how a downstream receiver identifies that one LSP is associated within another LSP based on ASSOCIATION objects. Note that this section in no way modifies the normative definitions of end-to-end and segment recovery, see [RFC4872] or [RFC4873].
前のセクションでは、[RFC4872]と[RFC4873]で定義されている、Association IDフィールドで使用される値の選択を含む、ASSOCIATIONオブジェクトの構築について説明しました。このセクションでは、ダウンストリームレシーバーが、ASSOCIATIONオブジェクトに基づいて、あるLSPが別のLSP内に関連付けられていることを識別する方法について説明します。このセクションは、エンドツーエンドおよびセグメント回復の規範的な定義を決して変更しないことに注意してください。[RFC4872]または[RFC4873]を参照してください。
As the ASSOCIATION object is only carried in Path messages, such identification only takes place based on Path state. In order to support the identification of the recovery type association between LSPs, a downstream receiver needs to be able to handle all three cases identified in Section 2.2. Cases 1 and 2 are simple, as the associated LSPs will carry the identical ASSOCIATION object. This is also always true for resource sharing type LSP association, see Section 2.4. Case 3 is more complicated, as it is possible for the LSPs to carry different Association ID fields and still be associated. The receiver also needs to allow for changes in the set of ASSOCIATION objects included in an LSP.
ASSOCIATIONオブジェクトはPathメッセージでのみ伝送されるため、そのような識別はPath状態に基づいてのみ行われます。 LSP間の回復タイプの関連付けの識別をサポートするために、ダウンストリームレシーバーはセクション2.2で識別された3つのケースすべてを処理できる必要があります。関連付けられたLSPは同一のASSOCIATIONオブジェクトを運ぶため、ケース1と2は単純です。これは、リソース共有タイプのLSPアソシエーションにも常に当てはまります。セクション2.4を参照してください。ケース3は、LSPが異なるアソシエーションIDフィールドを保持していても関連付けられている可能性があるため、より複雑です。受信者は、LSPに含まれるASSOCIATIONオブジェクトのセットの変更を許可する必要もあります。
Based on the [RFC4872] and [RFC4873] definitions related to the ASSOCIATION object, the following behavior can be followed to ensure that a receiver always properly identifies the association between LSPs:
ASSOCIATIONオブジェクトに関連する[RFC4872]および[RFC4873]の定義に基づいて、次の動作に従って、受信者がLSP間の関連付けを常に適切に識別できるようにします。
o Covering Cases 1 and 2 and resource sharing type LSP association:
o ケース1と2、およびリソース共有タイプのLSP関連付けについて説明します。
For ASSOCIATION objects with the Association Type field values of "Recovery" (1) and "Resource Sharing" (2), the association between LSPs is identified by comparing all fields of each of the ASSOCIATION objects carried in the Path messages associated with each LSP. An association is deemed to exist when the same values are carried in all fields of an ASSOCIATION object carried in each LSP's Path message. As more than one association may exist (e.g., in support of different association types or end-to-end and segment recovery), all carried ASSOCIATION objects need to be examined.
「リカバリー」（1）および「リソース共有」（2）のアソシエーションタイプフィールド値を持つASSOCIATIONオブジェクトの場合、LSP間の関連付けは、各LSPに関連付けられたパスメッセージに含まれる各ASSOCIATIONオブジェクトのすべてのフィールドを比較することによって識別されます。 。各LSPのパスメッセージに含まれるASSOCIATIONオブジェクトのすべてのフィールドに同じ値が含まれる場合、関連付けが存在すると見なされます。複数のアソシエーションが存在する可能性があるため（たとえば、さまざまなアソシエーションタイプやエンドツーエンドおよびセグメントリカバリをサポートするため）、運ばれたすべてのASSOCIATIONオブジェクトを調べる必要があります。
o Covering Case 3:
o カバーケース3：
Any ASSOCIATION object with the Association Type field value of "Recovery" (1) that does not yield an association in the prior comparison needs to be checked to see if a Case 3 association is indicated. As this case only applies to end-to-end recovery, the first step is to locate any other LSPs with the identical SESSION object fields and the identical tunnel sender address fields as the LSP carrying the ASSOCIATION object. If such LSPs exist, a case 3 association is identified by comparing the value of the Association ID field with the LSP ID field of the other LSP. If the values are identical, then an end-to-end recovery association exists. As this behavior only applies to end-to-end recovery, this check need only be performed at the egress.
関連付けタイプフィールドの値が "Recovery"（1）で、以前の比較で関連付けを生成しないASSOCIATIONオブジェクトは、ケース3の関連付けが示されているかどうかを確認する必要があります。このケースはエンドツーエンドの回復にのみ適用されるため、最初のステップは、ASSOCIATIONオブジェクトを伝送するLSPと同じSESSIONオブジェクトフィールドと同じトンネル送信者アドレスフィールドを持つ他のLSPを見つけることです。そのようなLSPが存在する場合、Association IDフィールドの値を他のLSPのLSP IDフィールドと比較することにより、ケース3の関連付けが識別されます。値が同じ場合は、エンドツーエンドのリカバリー関連付けが存在します。この動作はエンドツーエンドの回復にのみ適用されるため、このチェックは出口でのみ実行する必要があります。
No additional behavior is needed in order to support changes in the set of ASSOCIATION objects included in an LSP, as long as the change represents either a new association or a change in identifiers made as described in Section 2.2.
LSPに含まれるASSOCIATIONオブジェクトのセットの変更をサポートするために、変更が新しい関連付けまたはセクション2.2で説明されているように行われた識別子の変更のいずれかを表す限り、追加の動作は必要ありません。
This document reviews procedures defined in [RFC4872] and [RFC4873] and does not define any new procedures. As such, no new security considerations are introduced in this document.
このドキュメントは、[RFC4872]と[RFC4873]で定義された手順をレビューし、新しい手順を定義していません。そのため、このドキュメントではセキュリティに関する新しい考慮事項は紹介されていません。
This document formalizes the explanation provided in an e-mail to the working group authored by Adrian Farrel, see [AF-EMAIL]. This document was written in response to questions raised in the CCAMP working group by Nic Neate <nhn@dataconnection.com>. Valuable comments and input were also received from Dimitri Papadimitriou, Francois Le Faucheur, and Ashok Narayanan.
このドキュメントは、Adrian Farrelによって作成されたワーキンググループへの電子メールで提供される説明を形式化しています。[AF-EMAIL]を参照してください。このドキュメントは、Nic Neate <nhn@dataconnection.com>がCCAMPワーキンググループで提起した質問への回答に基づいて作成されました。 Dimitri Papadimitriou、Francois Le Faucheur、Ashok Narayananからも貴重なコメントと意見が寄せられました。
[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月。
[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, May 2007. Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE
[RFC4872] Lang、J。、編、Rekhter、Y。、編、D。Papadimitriou、編、「エンドツーエンドの汎用マルチプロトコルラベルスイッチング（GMPLS）リカバリをサポートするRSVP-TE拡張"、RFC 4872、2007年5月。Lang、J.、Rekhter、Y。、およびPapadimitriou、D。、" RSVP-TE
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「GMPLS Segment Recovery」、RFC 4873、2007年5月。
[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：Extensions for RSVP for LSP Tunnels」、RFC 3209、12月2001年。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、Ed。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、2003年1月。
[AF-EMAIL] Farrel, A. "Re: Clearing up your misunderstanding of the Association ID", CCAMP working group mailing list, http://www.ietf.org/mail-archive/web/ccamp/ current/msg00644.html, November 18, 2008.
[AF-EMAIL] Farrel、A。「Re：アソシエーションIDの誤解を解消する」、CCAMPワーキンググループメーリングリスト、http：//www.ietf.org/mail-archive/web/ccamp/current/msg00644。 html、2008年11月18日。
Author's Address
著者のアドレス
Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net
Lou Berger LabNコンサルティング、L.L.C。電話：+ 1-301-468-9228メール：lberger@labn.net