[要約] RFC 6780は、RSVP ASSOCIATIONオブジェクトの拡張に関する規格であり、RSVPプロトコルの機能を拡張するために使用されます。目的は、RSVPメッセージに関連情報を追加し、ネットワークリソースの予約と制御を改善することです。
Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 6780 LabN
Updates: 2205, 3209, 3473, 4872 F. Le Faucheur
Category: Standards Track A. Narayanan
ISSN: 2070-1721 Cisco
October 2012
RSVP ASSOCIATION Object Extensions
RSVP ASSOCIATIONオブジェクト拡張
Abstract
概要
The RSVP ASSOCIATION object was 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 object also has broader applicability as a mechanism to associate RSVP state. This document defines how the ASSOCIATION object can be more generally applied. This document also defines Extended ASSOCIATION objects that, in particular, can be used in the context of the MPLS Transport Profile (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the definition of the Association ID field defined in RFC 4872.
RSVP ASSOCIATIONオブジェクトは、GMPLS制御のラベルスイッチドパス（LSP）のコンテキストで定義されました。このコンテキストでは、オブジェクトは、回復LSPと保護LSPを関連付けるために使用されます。このオブジェクトには、RSVP状態を関連付けるメカニズムとしての幅広い適用性もあります。このドキュメントでは、ASSOCIATIONオブジェクトをより一般的に適用する方法を定義します。このドキュメントでは、特にMPLSトランスポートプロファイル（MPLS-TP）のコンテキストで使用できる拡張ASSOCIATIONオブジェクトも定義しています。このドキュメントは、RFC 2205、RFC 3209、およびRFC 3473を更新します。また、RFC 4872で定義されているアソシエーションIDフィールドの定義を一般化します。
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/rfc6780.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6780で入手できます。
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
1.1. Conventions Used in This Document ..........................4
2. Generalized Association ID Field Definition .....................4
3. Non-GMPLS and Non-Recovery Usage ................................4
3.1. Upstream Initiated Association .............................5
3.1.1. Path Message Format .................................5
3.1.2. Path Message Processing .............................6
3.2. Downstream Initiated Association ...........................7
3.2.1. Resv Message Format .................................8
3.2.2. Resv Message Processing .............................8
3.3. Association Types ..........................................9
3.3.1. Resource Sharing Association Type ...................9
3.3.2. Unknown Association Types ..........................10
4. IPv4 and IPv6 Extended ASSOCIATION Objects .....................10
4.1. IPv4 and IPv6 Extended ASSOCIATION Object Format ..........11
4.2. Processing ................................................13
5. Compatibility ..................................................14
6. Security Considerations ........................................14
7. IANA Considerations ............................................15
7.1. IPv4 and IPv6 Extended ASSOCIATION Objects ................15
7.2. Resource Sharing Association Type .........................15
8. Acknowledgments ................................................16
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................16
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. Additional narrative on how such associations are to be identified is provided in [RFC6689].
エンドツーエンドおよびセグメントの回復は、[RFC4872]および[RFC4873]でそれぞれGMPLS制御のラベルスイッチドパス（LSP）に対して定義されています。どちらの定義も、ASSOCIATIONオブジェクトを使用して、回復LSPと保護LSPを関連付けます。そのような関連をどのように特定するかに関する追加の説明は、[RFC6689]で提供されています。
This document expands the possible usage of the ASSOCIATION object to non-GMPLS and non-recovery contexts. The expanded usage applies equally to GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209], and non-LSP RSVP sessions [RFC2205] [RFC2207] [RFC3175] [RFC4860]. This document also reviews how associations should be made in the case in which the object is carried in a Path message; additionally, it defines usage with Resv messages. This section also discusses usage of the ASSOCIATION object outside the context of GMPLS LSPs.
このドキュメントでは、ASSOCIATIONオブジェクトの可能な使用法を非GMPLSおよび非回復コンテキストに拡張しています。拡張された使用法は、GMPLS LSP [RFC3473]、MPLS LSP [RFC3209]、および非LSP RSVPセッション[RFC2205] [RFC2207] [RFC3175] [RFC4860]に等しく適用されます。このドキュメントでは、オブジェクトがPathメッセージで運ばれる場合の関連付けの方法についても説明します。さらに、Resvメッセージの使用法を定義します。このセクションでは、GMPLS LSPのコンテキスト外でのASSOCIATIONオブジェクトの使用についても説明します。
Some examples of non-LSP association being used to enable resource sharing are:
リソース共有を可能にするために使用されている非LSPアソシエーションのいくつかの例は次のとおりです。
o Voice Call-Waiting:
o 音声通話待機：
A bidirectional voice call between two endpoints, A and B, is signaled using two separate unidirectional RSVP reservations for the flows A->B and B->A. If endpoint A wishes to put the A-B call on hold and join a separate A-C call, it is desirable that network resources on common links be shared between the A-B and A-C calls. The B->A and C->A subflows of the call can share resources using existing RSVP sharing mechanisms, but only if they use the same destination IP addresses and ports. Since by definition, the RSVP reservations for the subflows A->B and A->C of the call must have different IP addresses in the SESSION objects, this document defines a new mechanism to associate the subflows and allow them to share resources.
2つのエンドポイントAとBの間の双方向音声通話は、フローA-> BとB-> Aの2つの個別の単方向RSVP予約を使用してシグナリングされます。エンドポイントAがA-Bコールを保留にして別のA-Cコールに参加する場合、共通リンク上のネットワークリソースをA-BコールとA-Cコール間で共有することが望ましいです。コールのB-> AおよびC-> Aサブフローは、既存のRSVP共有メカニズムを使用してリソースを共有できますが、それらが同じ宛先IPアドレスとポートを使用する場合のみです。定義により、コールのサブフローA-> BおよびA-> CのRSVP予約はSESSIONオブジェクトで異なるIPアドレスを持つ必要があるため、このドキュメントでは、サブフローを関連付けてリソースを共有できるようにする新しいメカニズムを定義します。
o Voice Shared Line:
o 音声共有回線：
A voice shared line is a single number that rings multiple endpoints (which may be geographically diverse), such as phone lines to a manager's desk and to their assistant. A Voice over IP (VoIP) system that models these calls as multiple point-to-point unicast pre-ring reservations would result in significantly over-counting bandwidth on shared links, since RSVP unicast reservations to different endpoints cannot share bandwidth. So, a new mechanism is defined in this document to allow separate unicast reservations to be associated and to share resources.
音声共有回線は、マネージャのデスクやアシスタントへの電話回線など、複数のエンドポイント（地理的に異なる場合があります）を呼び出す単一の番号です。複数のポイントツーポイントユニキャストプレリング予約としてこれらのコールをモデル化するVoice over IP（VoIP）システムは、異なるエンドポイントへのRSVPユニキャスト予約が帯域幅を共有できないため、共有リンクで帯域幅を大幅にカウントします。そのため、このドキュメントでは、個別のユニキャスト予約を関連付けてリソースを共有できるようにする新しいメカニズムを定義しています。
o Symmetric NAT:
o 対称NAT：
RSVP permits sharing of resources between multiple flows addressed to the same destination D, even from different senders S1 and S2. However, if D is behind a NAT operating in symmetric mode [RFC5389], it is possible that the destination port of the flows S1->D and S2->D may be different outside the NAT. In this case, these flows cannot share resources using RSVP, since the SESSION objects for these two flows outside the NAT have different destination ports. This document defines a new mechanism to associate these flows and allow them to share resources.
RSVPでは、異なる送信元S1とS2からであっても、同じ宛先Dにアドレス指定された複数のフロー間でリソースを共有できます。ただし、Dが対称モード[RFC5389]で動作するNATの背後にある場合、フローS1-> DおよびS2-> Dの宛先ポートがNATの外部で異なる可能性があります。この場合、NAT外のこれら2つのフローのSESSIONオブジェクトには異なる宛先ポートがあるため、これらのフローはRSVPを使用してリソースを共有できません。このドキュメントでは、これらのフローを関連付けてリソースを共有できるようにする新しいメカニズムを定義します。
In order to support the wider usage of the ASSOCIATION object, this document generalizes the definition of the Association ID field defined in RFC 4872. This generalization has no impact on existing implementations. When using the procedures defined below, association is identified based on exact ASSOCIATION object matching. Some of the other matching mechanisms defined in RFC 4872, e.g., matching based on Session IDs, are not generalized. This document allows for, but does not specify, association type-specific processing.
ASSOCIATIONオブジェクトの幅広い使用をサポートするために、このドキュメントでは、RFC 4872で定義されているアソシエーションIDフィールドの定義を一般化しています。この一般化は、既存の実装に影響を与えません。以下に定義する手順を使用する場合、関連付けは、ASSOCIATIONオブジェクトの完全一致に基づいて識別されます。 RFC 4872で定義されている他のマッチングメカニズムの一部、たとえば、セッションIDに基づくマッチングは、一般化されていません。このドキュメントでは、アソシエーションタイプ固有の処理は許可されていますが、指定されていません。
This document also defines the Extended ASSOCIATION objects that can be used in the context of MPLS-TP. The scope of the Extended ASSOCIATION objects is not limited to MPLS-TP.
このドキュメントでは、MPLS-TPのコンテキストで使用できる拡張ASSOCIATIONオブジェクトも定義しています。拡張ASSOCIATIONオブジェクトのスコープは、MPLS-TPに限定されません。
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]で説明されているように解釈されます。
The Association ID field is carried in the IPv4 and IPv6 ASSOCIATION objects defined in [RFC4872]. The [RFC4872] definition of the field reads:
アソシエーションIDフィールドは、[RFC4872]で定義されているIPv4およびIPv6 ASSOCIATIONオブジェクトで伝達されます。フィールドの[RFC4872]定義は次のとおりです。
A value assigned by the LSP head-end. When combined with the Association Type and Association Source, this value uniquely identifies an association.
LSPヘッドエンドによって割り当てられた値。関連タイプおよび関連ソースと組み合わせると、この値は関連を一意に識別します。
This document allows for the origination of ASSOCIATION objects by nodes other than "the LSP head-end". As such, the definition of the Association ID field needs to be generalized to accommodate such usage. This document defines the Association ID field of the IPv4 and IPv6 ASSOCIATION objects as:
このドキュメントでは、「LSPヘッドエンド」以外のノードによるASSOCIATIONオブジェクトの生成が可能です。そのため、このような使用法に対応するには、Association IDフィールドの定義を一般化する必要があります。このドキュメントでは、IPv4およびIPv6 ASSOCIATIONオブジェクトのAssociation IDフィールドを次のように定義しています。
A value assigned by the node that originated the association. When combined with the other fields carried in the object, this value uniquely identifies an association.
関連付けを開始したノードによって割り当てられた値。オブジェクトに含まれる他のフィールドと組み合わせると、この値は関連付けを一意に識別します。
This change in definition does not impact the procedures or mechanisms defined in [RFC4872] or [RFC4873], nor does it impact the existing implementations of [RFC4872] or [RFC4873].
この定義の変更は、[RFC4872]または[RFC4873]で定義された手順やメカニズムに影響を与えず、[RFC4872]または[RFC4873]の既存の実装にも影響を与えません。
While the ASSOCIATION object [RFC4872] is defined in the context of GMPLS recovery, the object can have wider application. [RFC4872] defines the object to be used to "associate LSPs with each other", and then defines an Association Type field to identify the type of association being identified. It also specifies that the Association Type field is to be considered when determining association, i.e., there may be type-specific association rules. As defined by [RFC4872] and reviewed in [RFC6689], this is the case for recovery type ASSOCIATION objects. [RFC6689], notably the text related to resource sharing types, can also be used as the foundation for a generic method for associating LSPs when there is no type-specific association defined.
ASSOCIATIONオブジェクト[RFC4872]はGMPLSリカバリーのコンテキストで定義されますが、オブジェクトはより幅広いアプリケーションを持つことができます。 [RFC4872]は、「LSPを相互に関連付ける」ために使用されるオブジェクトを定義し、次に、関連付けタイプフィールドを定義して、識別される関連付けのタイプを識別します。また、関連付けを決定するときに[関連付けタイプ]フィールドを考慮する必要があることも指定します。つまり、タイプ固有の関連付けルールが存在する場合があります。 [RFC4872]で定義され、[RFC6689]でレビューされているように、これは回復タイプASSOCIATIONオブジェクトの場合です。 [RFC6689]、特にリソース共有タイプに関連するテキストは、タイプ固有の関連付けが定義されていない場合にLSPを関連付ける一般的な方法の基礎としても使用できます。
The remainder of this section defines the general rules to be followed when processing ASSOCIATION objects. Object usage in both Path and Resv messages is discussed. The usage applies equally to GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209], and non-LSP RSVP sessions [RFC2205] [RFC2207] [RFC3175] [RFC4860]. As described below, association is always done based on matching either Path state to Path state, or Resv state to Resv state, but not Path state to Resv State. This section applies to the ASSOCIATION objects defined in [RFC4872].
このセクションの残りの部分では、ASSOCIATIONオブジェクトを処理するときに従うべき一般的な規則を定義します。 PathメッセージとResvメッセージの両方でのオブジェクトの使用について説明します。使用法は、GMPLS LSP [RFC3473]、MPLS LSP [RFC3209]、および非LSP RSVPセッション[RFC2205] [RFC2207] [RFC3175] [RFC4860]に等しく適用されます。以下で説明するように、関連付けは常に、パスの状態とパスの状態、またはResvの状態とResvの状態のいずれかに一致することに基づいて行われますが、パスの状態とResvの状態は一致しません。このセクションは、[RFC4872]で定義されているASSOCIATIONオブジェクトに適用されます。
Upstream-initiated association is represented in ASSOCIATION objects carried in Path messages and can be used to associate RSVP Path state across MPLS Tunnels / RSVP sessions. (Note, per [RFC3209], an MPLS tunnel is represented by an RSVP SESSION object, and multiple LSPs may be represented within a single tunnel.) Cross-LSP association based on Path state is defined in [RFC4872]. This section extends that definition by specifying generic association rules and usage for non-LSP uses. This section does not modify processing required to support [RFC4872] and [RFC4873], which is reviewed in Section 3 of [RFC6689]. The use of an ASSOCIATION object in a single session is not precluded.
アップストリームで開始された関連付けは、Pathメッセージで伝達されるASSOCIATIONオブジェクトで表され、MPLSトンネル/ RSVPセッション全体でRSVPパス状態を関連付けるために使用できます。 （[RFC3209]によると、MPLSトンネルはRSVP SESSIONオブジェクトで表され、複数のLSPが単一のトンネル内で表される場合があります。）パス状態に基づくクロスLSPアソシエーションは[RFC4872]で定義されています。このセクションでは、一般的な関連付けルールとLSP以外の使用法を指定することにより、その定義を拡張します。このセクションでは、[RFC4872]と[RFC4873]をサポートするために必要な処理を変更しません。[RFC6689]のセクション3で確認します。単一セッションでのASSOCIATIONオブジェクトの使用は除外されません。
This section provides the Backus-Naur Form (BNF), see [RFC5511], for Path messages containing ASSOCIATION objects. BNF is provided for both MPLS and for non-LSP session usage. Unmodified RSVP message formats and some optional objects are not listed.
このセクションでは、ASSOCIATIONオブジェクトを含むPathメッセージについて、バッカスナウアフォーム（BNF）を提供します（[RFC5511]を参照）。 BNFは、MPLSと非LSPセッションの両方で使用できます。変更されていないRSVPメッセージ形式と一部のオプションオブジェクトは表示されません。
The formats for MPLS and GMPLS sessions are unmodified from [RFC4872] and can be represented based on the BNF in [RFC3209] as:
MPLSおよびGMPLSセッションのフォーマットは[RFC4872]から変更されておらず、[RFC3209]のBNFに基づいて次のように表すことができます。
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <ASSOCIATION> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
The format for non-LSP sessions as based on the BNF in [RFC2205] is:
[RFC2205]のBNFに基づく非LSPセッションの形式は次のとおりです。
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <ASSOCIATION> ... ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
In general, relative ordering of ASSOCIATION objects with respect to each other, as well as with respect to other objects, is not significant. Relative ordering of ASSOCIATION objects of the same type SHOULD be preserved by transit nodes.
一般に、ASSOCIATIONオブジェクトの互いに対する、および他のオブジェクトに対する相対的な順序は重要ではありません。同じタイプのASSOCIATIONオブジェクトの相対的な順序は、中継ノードによって保持されるべきです（SHOULD）。
This section is based on, and extends, the processing rules described in [RFC4872] and [RFC4873], which is reviewed in [RFC6689]. This section applies equally to GMPLS LSPs, MPLS LSPs, and non-LSP session state. Note, as previously stated, this section does not modify processing required to support [RFC4872] and [RFC4873].
このセクションは、[RFC6689]でレビューされている[RFC4872]および[RFC4873]で説明されている処理規則に基づいており、拡張されています。このセクションは、GMPLS LSP、MPLS LSP、および非LSPセッション状態に等しく適用されます。前述のとおり、このセクションでは、[RFC4872]と[RFC4873]をサポートするために必要な処理は変更されないことに注意してください。
A node sending a Path message chooses when an ASSOCIATION object is to be included in the outgoing Path message. To indicate association between multiple sessions, an appropriate ASSOCIATION object MUST be included in the outgoing Path messages corresponding to each of the associated sessions. In the absence of Association-Type-specific rules for identifying association, the included ASSOCIATION object MUST be identical. When there is an Association-Type-specific definition of association rules, the definition SHOULD allow for association based on identical ASSOCIATION objects. This document does not define any Association-Type-specific rules. (See Section 3 of [RFC6689] for a review of Association-Type-specific rules derived from [RFC4872].)
Pathメッセージを送信するノードは、ASSOCIATIONオブジェクトを送信Pathメッセージに含める時期を選択します。複数のセッション間の関連付けを示すには、関連付けられた各セッションに対応する発信Pathメッセージに適切なASSOCIATIONオブジェクトを含める必要があります。アソシエーションを識別するためのアソシエーションタイプ固有のルールがない場合、含まれるASSOCIATIONオブジェクトは同一である必要があります。アソシエーションタイプ固有のアソシエーションルールの定義がある場合、その定義では、同一のASSOCIATIONオブジェクトに基づくアソシエーションを許可する必要があります（SHOULD）。このドキュメントでは、関連タイプ固有のルールは定義されていません。 （[RFC4872]から派生したアソシエーションタイプ固有のルールについては、[RFC6689]のセクション3をご覧ください）。
When creating an ASSOCIATION object, the originator MUST format the object as defined in Section 16.1 of [RFC4872]. The originator MUST set the Association Type field based on the type of association being identified. The Association ID field MUST be set to a value that uniquely identifies the specific association within the context of the Association Source field. The Association Source field MUST be set to a unique address assigned to the node originating the association.
ASSOCIATIONオブジェクトを作成するとき、発信者は[RFC4872]のセクション16.1で定義されているようにオブジェクトをフォーマットする必要があります。発信者は、識別される関連のタイプに基づいて、関連タイプフィールドを設定する必要があります。関連IDフィールドは、関連ソースフィールドのコンテキスト内で特定の関連を一意に識別する値に設定する必要があります。 Association Sourceフィールドは、関連付けを開始するノードに割り当てられた一意のアドレスに設定する必要があります。
A downstream node can identify an upstream-initiated association by performing the following checks. When a node receives a Path message, it MUST check each ASSOCIATION object received in the Path message to determine if the object contains an Association Type field value supported by the node. For each ASSOCIATION object containing a supported association type, the node MUST then check to see if the object matches an ASSOCIATION object received in any other Path message. To perform this matching, a node MUST examine the Path state of all other sessions and compare the fields contained in the newly received ASSOCIATION object with the fields contained in the Path state's ASSOCIATION objects. An association is deemed to exist when the same values are carried in all fields of the ASSOCIATION objects being compared. Type-specific processing of ASSOCIATION objects is outside the scope of this document.
ダウンストリームノードは、次のチェックを実行することにより、アップストリームによって開始された関連付けを識別できます。ノードがPathメッセージを受信すると、Pathメッセージで受信した各ASSOCIATIONオブジェクトをチェックして、ノードがサポートするAssociation Typeフィールド値がオブジェクトに含まれているかどうかを確認する必要があります。サポートされている関連タイプを含む各ASSOCIATIONオブジェクトについて、ノードはオブジェクトが他のPathメッセージで受信したASSOCIATIONオブジェクトと一致するかどうかを確認する必要があります。このマッチングを実行するには、ノードは他のすべてのセッションのパス状態を調べ、新しく受信したASSOCIATIONオブジェクトに含まれているフィールドを、パス状態のASSOCIATIONオブジェクトに含まれているフィールドと比較する必要があります。比較されるASSOCIATIONオブジェクトのすべてのフィールドに同じ値が含まれている場合、関連付けは存在すると見なされます。 ASSOCIATIONオブジェクトのタイプ固有の処理は、このドキュメントの範囲外です。
Note that as more than one association may exist, the described matching MUST continue after a match is identified and MUST be performed against all local Path state. It is also possible for there to be no match identified.
複数のアソシエーションが存在する可能性があるため、記述されたマッチングは、マッチングが識別された後も継続する必要があり、すべてのローカルパス状態に対して実行する必要があります。一致が識別されない場合もあります。
Unless there are type-specific processing rules, downstream nodes MUST forward all ASSOCIATION objects received in a Path message in any corresponding outgoing Path messages without modification. This processing MUST be followed for unknown Association Type field values.
タイプ固有の処理ルールがない限り、ダウンストリームノードは、Pathメッセージで受信したすべてのASSOCIATIONオブジェクトを変更せずに、対応する発信Pathメッセージで転送する必要があります。不明なアソシエーションタイプフィールド値については、この処理に従う必要があります。
Downstream-initiated association is represented in ASSOCIATION objects carried in Resv messages and can be used to associate RSVP Resv state across MPLS Tunnels/RSVP sessions. Cross-LSP association, based on Path state, is defined in [RFC4872]. This section defines cross-session association based on Resv state. This section places no additional requirements on implementations supporting [RFC4872] and [RFC4873]. Note, the use of an ASSOCIATION object in a single session is not precluded.
ダウンストリームで開始された関連付けは、Resvメッセージで伝達されるASSOCIATIONオブジェクトで表され、MPLSトンネル/ RSVPセッション全体でRSVP Resv状態を関連付けるために使用できます。パス状態に基づくクロスLSPアソシエーションは、[RFC4872]で定義されています。このセクションでは、Resv状態に基づいてクロスセッションアソシエーションを定義します。このセクションでは、[RFC4872]と[RFC4873]をサポートする実装に追加の要件はありません。単一セッションでのASSOCIATIONオブジェクトの使用は除外されないことに注意してください。
This section provides the Backus-Naur Form (BNF), see [RFC5511], for Resv messages containing ASSOCIATION objects. BNF is provided for both MPLS and for non-LSP session usage. Unmodified RSVP message formats and some optional objects are not listed.
このセクションでは、ASSOCIATIONオブジェクトを含むResvメッセージについて、バッカスナウアフォーム（BNF）を提供します（[RFC5511]を参照）。 BNFは、MPLSと非LSPセッションの両方で使用できます。変更されていないRSVPメッセージ形式と一部のオプションオブジェクトは表示されません。
The formats for MPLS, GMPLS, and non-LSP sessions are identical and are represented based on the BNF in [RFC2205] and [RFC3209]:
MPLS、GMPLS、および非LSPセッションのフォーマットは同一であり、[RFC2205]および[RFC3209]のBNFに基づいて表されます。
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <ASSOCIATION> ... ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
Relative ordering of ASSOCIATION objects with respect to each other, as well as with respect to other objects, is not currently significant. Relative ordering of ASSOCIATION objects of the same type SHOULD be preserved by transit nodes.
ASSOCIATIONオブジェクトの互いに対する、および他のオブジェクトに対する相対的な順序は、現時点では重要ではありません。同じタイプのASSOCIATIONオブジェクトの相対的な順序は、中継ノードによって保持されるべきです（SHOULD）。
This section applies equally to GMPLS LSPs, MPLS LSPs, and non-LSP session state.
このセクションは、GMPLS LSP、MPLS LSP、および非LSPセッション状態に等しく適用されます。
A node sending a Resv message chooses when an ASSOCIATION object is to be included in the outgoing Resv message. A node that wishes to allow upstream nodes to associate Resv state across RSVP sessions MUST include an ASSOCIATION object in the outgoing Resv messages corresponding to the RSVP sessions to be associated. In the absence of Association-Type-specific rules for identifying association, the included ASSOCIATION objects MUST be identical. When there is an Association-Type-specific definition of association rules, the definition SHOULD allow for association based on identical ASSOCIATION objects. This document does not define any Association-Type-specific rules.
Resvメッセージを送信するノードは、ASSOCIATIONオブジェクトを送信Resvメッセージに含めるタイミングを選択します。上流ノードがRSVPセッション全体でResv状態を関連付けることを許可するノードは、関連付けられるRSVPセッションに対応する発信ResvメッセージにASSOCIATIONオブジェクトを含める必要があります。関連付けを識別するためのAssociation-Type固有のルールがない場合、含まれるASSOCIATIONオブジェクトは同一である必要があります。アソシエーションタイプ固有のアソシエーションルールの定義がある場合、その定義では、同一のASSOCIATIONオブジェクトに基づくアソシエーションを許可する必要があります（SHOULD）。このドキュメントでは、関連タイプ固有のルールは定義されていません。
When creating an ASSOCIATION object, the originator MUST format the object as defined in Section 16.1 of [RFC4872]. The originator MUST set the Association Type field based on the type of association being identified. The Association ID field MUST be set to a value that uniquely identifies the specific association within the context of the Association Source field. The Association Source field MUST be set to a unique address assigned to the node originating the association.
ASSOCIATIONオブジェクトを作成するとき、発信者は[RFC4872]のセクション16.1で定義されているようにオブジェクトをフォーマットする必要があります。発信者は、識別される関連のタイプに基づいて、関連タイプフィールドを設定する必要があります。関連IDフィールドは、関連ソースフィールドのコンテキスト内で特定の関連を一意に識別する値に設定する必要があります。 Association Sourceフィールドは、関連付けを開始するノードに割り当てられた一意のアドレスに設定する必要があります。
An upstream node can identify a downstream-initiated association by performing the following checks. When a node receives a Resv message, it MUST check each ASSOCIATION object received in the Resv message to determine if the object contains an Association Type field value supported by the node. For each ASSOCIATION object containing a supported association type, the node MUST then check to see if the object matches an ASSOCIATION object received in any other Resv message. To perform this matching, a node MUST examine the Resv state of all other sessions and compare the fields contained in the newly received ASSOCIATION object with the fields contained in the Resv state's ASSOCIATION objects. An association is deemed to exist when the same values are carried in all fields of the ASSOCIATION objects being compared. Type-specific processing of ASSOCIATION objects is outside the scope of this document.
上流ノードは、次のチェックを実行することにより、下流側で開始された関連付けを識別できます。ノードがResvメッセージを受信すると、ノードは、Resvメッセージで受信した各ASSOCIATIONオブジェクトをチェックして、ノードがサポートするAssociation Typeフィールド値がオブジェクトに含まれているかどうかを判断する必要があります。サポートされている関連付けタイプを含む各ASSOCIATIONオブジェクトについて、ノードはオブジェクトが他のResvメッセージで受信したASSOCIATIONオブジェクトと一致するかどうかを確認する必要があります。このマッチングを実行するには、ノードは他のすべてのセッションのResv状態を調べ、新しく受信したASSOCIATIONオブジェクトに含まれているフィールドとResv状態のASSOCIATIONオブジェクトに含まれているフィールドを比較する必要があります。比較されるASSOCIATIONオブジェクトのすべてのフィールドに同じ値が含まれている場合、関連付けは存在すると見なされます。 ASSOCIATIONオブジェクトのタイプ固有の処理は、このドキュメントの範囲外です。
Note that as more than one association may exist, the described matching MUST continue after a match is identified and MUST be performed against all local Resv state. It is also possible for there to be no match identified.
複数のアソシエーションが存在する可能性があるため、記述されたマッチングは、マッチングが識別された後も継続する必要があり、すべてのローカルResv状態に対して実行する必要があることに注意してください。一致が識別されない場合もあります。
Unless there are type-specific processing rules, upstream nodes MUST forward all ASSOCIATION objects received in a Resv message in any corresponding outgoing Resv messages without modification. This processing MUST be followed for unknown Association Type field values.
タイプ固有の処理ルールがない限り、上流ノードは、Resvメッセージで受信したすべてのASSOCIATIONオブジェクトを、対応する発信Resvメッセージで変更せずに転送する必要があります。不明なアソシエーションタイプフィールド値については、この処理に従う必要があります。
Two association types are currently defined: recovery and resource sharing. Recovery type association is only applicable within the context of recovery [RFC4872] [RFC4873]. Resource sharing is applicable to any context and its general use is defined in this section.
現在、2つの関連付けタイプが定義されています。リカバリとリソース共有です。回復タイプの関連付けは、回復のコンテキスト内でのみ適用できます[RFC4872] [RFC4873]。リソース共有はあらゆるコンテキストに適用でき、その一般的な使用法はこのセクションで定義されています。
The Resource Sharing Association Type was defined in [RFC4873] and was defined within the context of GMPLS and upstream-initiated association. This section presents a definition of the resource sharing association that allows for its use with any RSVP session type and in both Path and Resv messages. This definition is consistent with the definition of the resource sharing association type in [RFC4873] and no changes are required by this section in order to support [RFC4873]. The Resource Sharing Association Type MUST be supported by any implementation compliant with this document.
リソース共有アソシエーションタイプは[RFC4873]で定義され、GMPLSおよびアップストリーム開始アソシエーションのコンテキスト内で定義されました。このセクションでは、RSVPセッションタイプおよびPathメッセージとResvメッセージの両方で使用できるリソース共有関連付けの定義を示します。この定義は、[RFC4873]のリソース共有アソシエーションタイプの定義と一致しており、[RFC4873]をサポートするためにこのセクションを変更する必要はありません。 Resource Sharing Association Typeは、このドキュメントに準拠するすべての実装でサポートされている必要があります。
The Resource Sharing Association Type is used to enable resource sharing across RSVP sessions. Per [RFC4873], resource sharing uses the Association Type field value of 2. ASSOCIATION objects with an Association Type with the value Resource Sharing MAY be carried in Path and Resv messages. Association for the Resource Sharing type MUST follow the procedures defined in Section 3.1.2 for upstream-initiated (Path message) association and Section 3.2.1 for downstream-initiated (Resv message) association. There are no type-specific association rules, processing rules, or ordering requirements. Note that, as is always the case with association as enabled by this document, no associations are made across Path and Resv state.
リソース共有アソシエーションタイプは、RSVPセッション全体でリソース共有を有効にするために使用されます。 [RFC4873]に従い、リソース共有は2のアソシエーションタイプフィールド値を使用します。値がリソース共有のアソシエーションタイプを持つASSOCIATIONオブジェクトは、PathおよびResvメッセージで伝送される場合があります。リソース共有タイプの関連付けは、アップストリーム開始（パスメッセージ）アソシエーションのセクション3.1.2およびダウンストリーム開始（Resvメッセージ）アソシエーションのセクション3.2.1で定義された手順に従う必要があります。タイプ固有の相関ルール、処理ルール、または順序付け要件はありません。このドキュメントで有効になっている関連付けでは常にそうであるように、Path状態とResv状態の間で関連付けは行われません。
Once an association is identified, resources MUST be considered as shared across the identified sessions by the admission-control function. Since the implementation specifics of the admission-control function is outside the scope of RSVP, we observe that how resource sharing is actually reflected may vary according to specific implementations (e.g., depending on the specific admission-control and resource-management algorithm, or on how local policy is taken into account).
アソシエーションが識別されたら、リソースは、アドミッションコントロール機能によって、識別されたセッション全体で共有されていると見なす必要があります。アドミッションコントロール機能の実装の詳細はRSVPの範囲外であるため、リソース共有が実際にどのように反映されるかは、特定の実装（たとえば、特定のアドミッションコントロールおよびリソース管理アルゴリズム、またはローカルポリシーがどのように考慮されるか）。
As required by Sections 3.1.2 and 3.2.2 above, a node that receives an ASSOCIATION object containing an unknown ASSOCIATION type forwards all received ASSOCIATION objects as defined above. The node MAY also identify associations per the defined processing, e.g., to make this information available via a management interface.
上記のセクション3.1.2および3.2.2で要求されているように、不明なASSOCIATIONタイプを含むASSOCIATIONオブジェクトを受信するノードは、上記で定義されているように、受信したすべてのASSOCIATIONオブジェクトを転送します。ノードはまた、例えば、この情報を管理インターフェースを介して利用可能にするために、定義された処理ごとに関連付けを識別してもよい（MAY）。
[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 ASSOCIATION object. As defined, these objects each contain an Association Source field and a 16-bit Association ID field. As previously described, the contents of the object uniquely identify an association. Because the Association ID field is a 16-bit field, an association source can allocate up to 65536 different associations and no more. There are scenarios where this number is insufficient (for example, where the association identification is best known and identified by a fairly centralized entity, and therefore may be involved in a large number of associations).
[RFC4872]は、IPv4 ASSOCIATIONオブジェクトとIPv6 ASSOCIATIONオブジェクトを定義します。定義されているように、これらのオブジェクトにはそれぞれ、Association Sourceフィールドと16ビットのAssociation IDフィールドが含まれています。前述のように、オブジェクトのコンテンツは関連付けを一意に識別します。アソシエーションIDフィールドは16ビットフィールドであるため、アソシエーションソースは最大65536までのアソシエーションを割り当てることができ、それ以上はできません。この数では不十分なシナリオがあります（たとえば、関連付けの識別が最もよく知られ、かなり集中化されたエンティティによって識別されるため、多数の関連付けに関与する場合があります）。
An additional case that cannot be supported using the existing ASSOCIATION objects is presented by MPLS-TP LSPs. Per [RFC6370], MPLS-TP LSPs can be identified based on an operator-unique global identifier. As defined in [RFC6370], "global identifier", or Global_ID, is based on [RFC5003] and includes the operator's Autonomous System Number (ASN).
既存のASSOCIATIONオブジェクトを使用してサポートできない追加のケースは、MPLS-TP LSPによって提示されます。 [RFC6370]によれば、MPLS-TP LSPは、オペレーター固有のグローバル識別子に基づいて識別できます。 [RFC6370]で定義されているように、「グローバル識別子」またはGlobal_IDは[RFC5003]に基づいており、オペレーターの自律システム番号（ASN）が含まれています。
This section defines new ASSOCIATION objects to support extended identification in order to address the previously described limitations. Specifically, the IPv4 Extended ASSOCIATION object and IPv6 Extended ASSOCIATION object are defined below. Both new objects include the fields necessary to enable identification of a larger number of associations as well as MPLS-TP-required identification.
このセクションでは、前述の制限に対処するために拡張識別をサポートする新しいASSOCIATIONオブジェクトを定義します。具体的には、IPv4拡張ASSOCIATIONオブジェクトとIPv6拡張ASSOCIATIONオブジェクトを以下に定義します。どちらの新しいオブジェクトにも、より多くの関連付けの識別を可能にするために必要なフィールドと、MPLS-TPで必要な識別が含まれています。
The IPv4 Extended ASSOCIATION object and IPv6 Extended ASSOCIATION object SHOULD be supported by an implementation compliant with this document. The processing rules for the IPv4 and IPv6 Extended ASSOCIATION object are described below and are based on the rules for the IPv4 and IPv6 ASSOCIATION objects as previously described.
IPv4拡張ASSOCIATIONオブジェクトとIPv6拡張ASSOCIATIONオブジェクトは、このドキュメントに準拠した実装でサポートされるべきです（SHOULD）。 IPv4およびIPv6拡張ASSOCIATIONオブジェクトの処理規則は以下に説明されており、前述のIPv4およびIPv6 ASSOCIATIONオブジェクトの規則に基づいています。
The IPv4 Extended ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = 3) has the format:
IPv4拡張ASSOCIATIONオブジェクト（11bbbbbbという形式のクラス番号、値= 199、Cタイプ= 3）の形式は次のとおりです。
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(199)| C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: . :
: Extended Association ID :
: . :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 Extended ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = 4) has the format:
IPv6拡張ASSOCIATIONオブジェクト（11bbbbbbという形式のクラス番号、値= 199、Cタイプ= 4）の形式は次のとおりです。
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(199)| C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Association Source |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: . :
: Extended Association ID :
: . :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Association Type: 16 bits
関連付けタイプ：16ビット
Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872].
IPv4およびIPv6 ASSOCIATIONオブジェクトの場合と同じです。[RFC4872]を参照してください。
Association ID: 16 bits
アソシエーションID：16ビット
Same as for IPv4 and IPv6 ASSOCIATION objects, see Section 2.
IPv4およびIPv6 ASSOCIATIONオブジェクトの場合と同じです。セクション2を参照してください。
Association Source: 4 or 16 bytes
アソシエーションソース：4または16バイト
Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872].
IPv4およびIPv6 ASSOCIATIONオブジェクトの場合と同じです。[RFC4872]を参照してください。
Global Association Source: 4 bytes
グローバルアソシエーションソース：4バイト
This field contains a value that is a unique global identifier or the special value zero (0). When non-zero and not overridden by local policy, the Global_ID as defined in [RFC6370] SHALL be used. The special value zero indicates that no global identifier is present. Use of the special value zero SHOULD be limited to entities contained within a single operator.
このフィールドには、一意のグローバル識別子である値または特別な値ゼロ（0）が含まれます。ゼロ以外でローカルポリシーによってオーバーライドされない場合、[RFC6370]で定義されているGlobal_IDを使用する必要があります（SHALL）。特別な値0は、グローバルIDが存在しないことを示します。特殊な値ゼロの使用は、単一の演算子に含まれるエンティティに限定する必要があります（SHOULD）。
If the Global Association Source field value is derived from a 2-octet ASN, then the two high-order octets of this 4-octet field MUST be set to zero.
グローバルアソシエーションソースフィールドの値が2オクテットASNから導出される場合、この4オクテットフィールドの2つの高次オクテットはゼロに設定する必要があります。
Extended Association ID: variable, 4-byte aligned
拡張アソシエーションID：可変、4バイト境界で整列
This field contains data that is additional information to support unique identification. The length and contents of this field is scoped by the Association Source. The length of this field is derived from the object Length field and as such MUST have a length of zero or be 4-byte aligned. A length of zero indicates that this field is omitted.
このフィールドには、一意の識別をサポートするための追加情報であるデータが含まれています。このフィールドの長さと内容は、関連ソースによってスコープされます。このフィールドの長さは、オブジェクトの長さフィールドから導出されるため、長さがゼロであるか、4バイトで整列している必要があります。長さがゼロの場合、このフィールドは省略されています。
The processing of an IPv4 or IPv6 Extended ASSOCIATION object MUST be identical to the processing of an IPv4 or IPv6 ASSOCIATION object as previously described, except as extended by this section. This section applies to ASSOCIATION objects included in both Path and Resv messages.
IPv4またはIPv6拡張ASSOCIATIONオブジェクトの処理は、このセクションで拡張されていることを除いて、前述のIPv4またはIPv6 ASSOCIATIONオブジェクトの処理と同じでなければなりません。このセクションは、PathメッセージとResvメッセージの両方に含まれるASSOCIATIONオブジェクトに適用されます。
The following are the modified procedures for Extended ASSOCIATION object processing:
以下は、拡張ASSOCIATIONオブジェクト処理の変更された手順です。
o When creating an Extended ASSOCIATION object, the originator MUST format the object as defined in this document.
o 拡張ASSOCIATIONオブジェクトを作成するとき、発信者はこのドキュメントで定義されているようにオブジェクトをフォーマットする必要があります。
o The originator MUST set the Association Type, Association ID, and Association Source fields as described in Section 4.
o 発信者は、セクション4で説明されているように、関連タイプ、関連ID、および関連ソースフィールドを設定する必要があります。
o When ASN-based global identification of the Association Source is desired, the originator MUST set the Global Association Source field. When ASN-based global identification is not desired, the originator MUST set the Global Association Source field to zero (0).
o アソシエーションソースのASNベースのグローバル識別が必要な場合、発信者はグローバルアソシエーションソースフィールドを設定する必要があります。 ASNベースのグローバルIDが不要な場合、発信者はグローバルアソシエーションソースフィールドをゼロ（0）に設定する必要があります。
o The Extended ASSOCIATION object originator MAY include the Extended Association ID field. The field is included based on local policy. The field MUST be included when the Association ID field is insufficient to uniquely identify association within the scope of the source of the association. When included, this field MUST be set to a value that, when taken together with the other fields in the object, uniquely identifies the association being identified.
o Extended ASSOCIATIONオブジェクトの作成者は、Extended Association IDフィールドを含めることができます。このフィールドは、ローカルポリシーに基づいて含まれています。アソシエーションのソースのスコープ内でアソシエーションを一意に識別するにはアソシエーションIDフィールドが不十分な場合、このフィールドを含める必要があります。含まれる場合、このフィールドは、オブジェクトの他のフィールドと一緒に使用されると、識別される関連付けを一意に識別する値に設定する必要があります。
o The object Length field is set based on the length of the Extended Association ID field. When the Extended Association ID field is omitted, the object Length field MUST be set to 16 or 28 for the IPv4 and IPv6 ASSOCIATION objects, respectively. When the Extended Association ID field is present, the object Length field MUST be set to indicate the additional bytes carried in the Extended Association ID field, including pad bytes.
o オブジェクトの長さフィールドは、拡張アソシエーションIDフィールドの長さに基づいて設定されます。拡張アソシエーションIDフィールドが省略されている場合、オブジェクトの長さフィールドは、IPv4およびIPv6 ASSOCIATIONオブジェクトに対してそれぞれ16または28に設定する必要があります。拡張アソシエーションIDフィールドが存在する場合、オブジェクトの長さフィールドを設定して、パッドバイトを含む、拡張アソシエーションIDフィールドで伝送される追加のバイトを示す必要があります。
Note: Per [RFC2205], the object Length field is set to the total object length in bytes, is always a multiple of 4, and is at least 4.
注：[RFC2205]によると、オブジェクトの長さフィールドは、オブジェクトの長さの合計（バイト単位）に設定され、常に4の倍数であり、少なくとも4です。
The procedures related to association identification are not modified by this section. It is important to note that Section 4 defines the identification of associations based on ASSOCIATION object matching and that such matching, in the absence of type-specific comparison rules, is based on the comparison of all fields in an ASSOCIATION object. This applies equally to ASSOCIATION objects and Extended ASSOCIATION objects.
関連付けの識別に関連する手順は、このセクションでは変更されません。セクション4は、ASSOCIATIONオブジェクトの一致に基づく関連付けの識別を定義し、そのような一致は、タイプ固有の比較ルールがない場合、ASSOCIATIONオブジェクトのすべてのフィールドの比較に基づくことに注意することが重要です。これは、ASSOCIATIONオブジェクトと拡張ASSOCIATIONオブジェクトに等しく適用されます。
Per [RFC4872], the ASSOCIATION object uses an object class number of the form 11bbbbbb to ensure compatibility with non-supporting nodes. Per [RFC2205], such nodes will ignore the object but forward it without modification. This is also the action taken for unknown association types as discussed above in Section 3.1.2, 3.2.2, and 3.3.2.
[RFC4872]に従い、ASSOCIATIONオブジェクトは11bbbbbb形式のオブジェクトクラス番号を使用して、サポートされていないノードとの互換性を確保します。 [RFC2205]に従い、そのようなノードはオブジェクトを無視しますが、変更せずに転送します。これは、セクション3.1.2、3.2.2、および3.3.2で前述したように、不明な関連付けタイプに対して実行されるアクションでもあります。
Per [RFC4872], transit nodes that support the ASSOCIATION object but not the Extended Association C-Types will "transmit, without modification, any received ASSOCIATION object in the corresponding outgoing Path message". Per [RFC2205], an egress node that supports the ASSOCIATION object but not the Extended Association C-Types, may generate an "Unknown object C-Type" error. This error will propagate to the ingress node for standard error processing.
[RFC4872]に従い、ASSOCIATIONオブジェクトをサポートするが拡張アソシエーションCタイプをサポートしないトランジットノードは、「対応する発信パスメッセージで受信したASSOCIATIONオブジェクトを変更せずに送信します」。 [RFC2205]に従って、ASSOCIATIONオブジェクトをサポートするが拡張アソシエーションCタイプをサポートしない出力ノードは、「不明なオブジェクトCタイプ」エラーを生成する場合があります。このエラーは、標準エラー処理のために入力ノードに伝播します。
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.
特定のアソシエーションタイプでサポートされている関数を使用したいオペレータは、そのタイプがアソシエーションで動作すると予想されるすべてのノードでサポートされていることを確認する必要があります。
A portion of this document reviews procedures defined in [RFC4872] and [RFC4873] and does not define new procedures. As such, no new security considerations are introduced in this portion of the document.
このドキュメントの一部では、[RFC4872]と[RFC4873]で定義されている手順を確認し、新しい手順は定義していません。そのため、このドキュメントのこの部分では、セキュリティに関する新しい考慮事項は紹介されていません。
Section 3 defines broader usage of the ASSOCIATION object, but does not fundamentally expand on the association function that was previously defined in [RFC4872] and [RFC4873]. Section 4 increases the number of bits that are carried in an ASSOCIATION object (by 32), and similarly does not expand on the association function that was previously defined. This broader definition does allow for additional information to be conveyed, but this information is not fundamentally different from the information that is already carried in RSVP. Therefore, there are no new risks or security considerations introduced by this document.
セクション3では、ASSOCIATIONオブジェクトのより広範な使用法を定義していますが、以前に[RFC4872]および[RFC4873]で定義されていた関連付け関数を根本的に拡張していません。セクション4は、ASSOCIATIONオブジェクトで運ばれるビット数を（32ずつ）増やし、同様に、以前に定義された関連付け関数を拡張しません。このより広い定義では、追加の情報を伝達できますが、この情報は、RSVPですでに伝達されている情報と根本的に異なるわけではありません。したがって、このドキュメントで紹介されている新しいリスクやセキュリティに関する考慮事項はありません。
For a general discussion on MPLS- and GMPLS-related security issues, including RSVP's chain of trust security model, see the MPLS/GMPLS security framework [RFC5920].
RSVPのトラストセキュリティモデルを含むMPLSおよびGMPLS関連のセキュリティ問題に関する一般的な説明については、MPLS / GMPLSセキュリティフレームワーク[RFC5920]を参照してください。
IANA has assigned new values for namespaces defined in this document and they are summarized in this section.
IANAは、このドキュメントで定義されている名前空間に新しい値を割り当てました。それらは、このセクションで要約されています。
Per this document, IANA has assigned two new C-Types (which are defined in Section 3.1) for the existing ASSOCIATION object in the "Class Names, Class Numbers, and Class Types" section of the "Resource Reservation Protocol (RSVP) Parameters" registry located at http://www.iana.org/assignments/rsvp-parameters:
このドキュメントに従って、IANAは、「リソース予約プロトコル（RSVP）パラメータ」の「クラス名、クラス番号、およびクラスタイプ」セクションで、既存のASSOCIATIONオブジェクトに2つの新しいCタイプ（セクション3.1で定義）を割り当てましたhttp://www.iana.org/assignments/rsvp-parametersにあるレジストリ：
199 ASSOCIATION [RFC4872]
199協会[RFC4872]
Class Types or C-Types
クラスタイプまたはCタイプ
3 Type 3 IPv4 Extended Association [RFC6780] 4 Type 4 IPv6 Extended Association [RFC6780]
3タイプ3 IPv4拡張アソシエーション[RFC6780] 4タイプ4 IPv6拡張アソシエーション[RFC6780]
This document also broadens the potential usage of the Resource Sharing Association Type defined in [RFC4873]. As such, IANA has updated the reference of the Resource Sharing Association Type included in the associated registry. Per this document, IANA has also corrected the duplicate usage of '(R)' in this registry. In particular, the "Association Type" registry found at http://www.iana.org/assignments/gmpls-sig-parameters/ has been updated as follows:
このドキュメントはまた、[RFC4873]で定義されたResource Sharing Association Typeの潜在的な使用法を広げます。そのため、IANAは、関連するレジストリに含まれるResource Sharing Association Typeの参照を更新しました。このドキュメントに従って、IANAはこのレジストリでの「（R）」の重複使用も修正しました。特に、http：//www.iana.org/assignments/gmpls-sig-parameters/にある「Association Type」レジストリが次のように更新されました。
OLD: 2 Resource Sharing (R) [RFC4873]
OLD：2リソース共有（R）[RFC4873]
NEW: 2 Resource Sharing (S) [RFC4873][RFC6780]
新規：2リソース共有（S）[RFC4873] [RFC6780]
There are no other IANA considerations introduced by this document.
このドキュメントで紹介されている他のIANAの考慮事項はありません。
Valuable comments and input were received from Dimitri Papadimitriou, Fei Zhang, and Adrian Farrel. We thank Subha Dhesikan for her contribution to the early work on sharing of resources across RSVP reservations.
Dimitri Papadimitriou、Fei Zhang、Adrian Farrelから貴重なコメントと意見を受け取りました。 RSVP予約全体でのリソースの共有に関する初期の作業に貢献してくれたSubha Dhesikanに感謝します。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、and S. Jamin、 "Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification"、RFC 2205、September 1997年
[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月。
[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月。
[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.
[RFC4872] Lang、J。、編、Rekhter、Y。、編、およびD. Papadimitriou、編、「エンドツーエンドの汎用マルチプロトコルラベルスイッチング（GMPLS）リカバリをサポートするRSVP-TE拡張"、RFC 4872、2007年5月。
[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月。
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009.
[RFC5511] Farrel、A。、「Routing Backus-Naur Form（RBNF）：A Syntax Using Forming Encoding Rules in Various Routing Protocol Specifications」、RFC 5511、2009年4月。
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RFC2207] Berger、L。およびT. O'Malley、「IPSECデータフローのRSVP拡張機能」、RFC 2207、1997年9月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RFC3175]ベイカー、F。、イトゥラルデ、C。、ルフォシェール、F。、およびB.デイビー、「RSVP for IPv4 and IPv6 Reservations」、RFC 3175、2001年9月。
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", RFC 4860, May 2007.
[RFC4860] Le Faucheur、F.、Davie、B.、Bose、P.、Christou、C。、およびM. Davenport、「Generic Aggregate Resource ReSerVation Protocol（RSVP）Reservations」、RFC 4860、2007年5月。
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007.
[RFC5003] Metz、C.、Martini、L.、Balus、F。、およびJ. Sugimoto、「Attachment Individual Identifier（AII）Types for Aggregation」、RFC 5003、2007年9月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「Session Traversal Utilities for NAT（STUN）」、RFC 5389、2008年10月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC6370] Bocci、M.、Swallow、G。、およびE. Gray、「MPLS Transport Profile（MPLS-TP）Identifiers」、RFC 6370、2011年9月。
[RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC 6689, July 2012.
[RFC6689] Berger、L。、「RSVP ASSOCIATIONオブジェクトの使用」、RFC 6689、2012年7月。
Authors' Addresses
著者のアドレス
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
Francois Le Faucheur Cisco Systems Greenside, 400 Avenue de Roumanille Sophia Antipolis 06410 France EMail: flefauch@cisco.com
Francois Le Faucheur Cisco Systems Greenside、400 Avenue de Roumanille Sophia Antipolis 06410 Franceメール：flefauch@cisco.com
Ashok Narayanan Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 United States EMail: ashokn@cisco.com
Ashok Narayanan Cisco Systems 300 Beaver Brook Road Boxborough、MA 01719 United States Eメール：ashokn@cisco.com