[要約] 要約：RFC 8697は、ラベルスイッチドパス（LSP）のセット間の関係を確立するためのPath Computation Element Communication Protocol（PCEP）の拡張について説明しています。目的：このRFCの目的は、PCEPを使用してLSPのセット間の関係を効果的に確立し、ネットワークのパフォーマンスと効率を向上させることです。
Internet Engineering Task Force (IETF) I. Minei
Request for Comments: 8697 Google, Inc.
Category: Standards Track E. Crabbe
ISSN: 2070-1721 Individual Contributor
S. Sivabalan
Cisco Systems, Inc.
H. Ananthakrishnan
Netflix
D. Dhody
Huawei
Y. Tanaka
NTT Communications Corporation
January 2020
Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)
ラベルスイッチドパス（LSP）のセット間の関係を確立するためのパス計算要素通信プロトコル（PCEP）拡張
Abstract
概要
This document introduces a generic mechanism to create a grouping of Label Switched Paths (LSPs) in the context of a Path Computation Element (PCE). This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and it is equally applicable to the stateful PCE (active and passive modes) and the stateless PCE.
このドキュメントでは、パス計算エレメント（PCE）のコンテキストでラベルスイッチドパス（LSP）のグループを作成するための一般的なメカニズムを紹介します。次に、このグループ化を使用して、LSPのセット間またはLSPのセットと属性のセット（構成パラメーターや動作など）の間の関連付けを定義できます。これは、ステートフルPCE（アクティブモードとパッシブモード）およびステートレスPCE。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8697.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8697で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
2. Terminology
3. Architectural Overview
3.1. Motivations
3.2. Relationship to the SVEC List
3.3. Operational Overview
3.4. Operator-Configured Association Range
4. Discovery of Supported Association Types
4.1. ASSOC-Type-List TLV
4.1.1. Procedure
5. Operator-Configured Association Range TLV
5.1. Procedure
6. ASSOCIATION Object
6.1. Object Definition
6.1.1. Global Association Source TLV
6.1.2. Extended Association ID TLV
6.1.3. Association Source
6.1.4. Unique Identification for an Association Group
6.2. Relationship to the RSVP ASSOCIATION Object
6.3. Object Encoding in PCEP Messages
6.3.1. Stateful PCEP Messages
6.3.2. Request Message
6.3.3. Reply Message
6.4. Processing Rules
7. IANA Considerations
7.1. PCEP Object
7.2. PCEP TLV
7.3. Association Flags
7.4. Association Type
7.5. PCEP-Error Object
8. Security Considerations
9. Manageability Considerations
9.1. Control of Function and Policy
9.2. Information and Data Models
9.3. Liveness Detection and Monitoring
9.4. Verifying Correct Operation
9.5. Requirements on Other Protocols
9.6. Impact on Network Operations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Example of an Operator-Configured Association Range
Acknowledgments
Contributors
Authors' Addresses
[RFC5440] describes the Path Computation Element (PCE) Communication Protocol (PCEP). PCEP enables communication between a Path Computation Client (PCC) and a PCE, or between a PCE and another PCE, for the purpose of the computation of Multiprotocol Label Switching (MPLS) as well as Generalized MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP) characteristics.
[RFC5440]は、Path Computation Element（PCE）Communication Protocol（PCEP）について説明しています。 PCEPは、マルチプロトコルラベルスイッチング（MPLS）および一般化MPLS（GMPLS）トラフィックエンジニアリングラベルスイッチドパス（ TE LSP）の特性。
[RFC8231] specifies a set of extensions to PCEP to enable stateful control of TE LSPs within and across PCEP sessions in compliance with [RFC4657]. It includes mechanisms to effect LSP State Synchronization between PCCs and PCEs, delegation of control over LSPs to PCEs, and PCE control of timing and sequence of path computations within and across PCEP sessions. The operational model whereby LSPs are initiated from the PCE is described in [RFC8281].
[RFC8231]は、PCEPの拡張セットを指定して、[RFC4657]に準拠してPCEPセッション内およびPCEPセッション全体でTE LSPのステートフル制御を可能にします。これには、PCCとPCEの間のLSP状態の同期、LSPからPCEへの制御の委任、PCEPセッション内およびPCEPセッション間でのパス計算のタイミングとシーケンスのPCE制御を行うメカニズムが含まれます。 LSPがPCEから開始される運用モデルは、[RFC8281]で説明されています。
[RFC4872] defines the RSVP ASSOCIATION object, which was defined in the context of GMPLS-controlled LSPs to be used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state. [RFC6780] describes how the ASSOCIATION object can be more generally applied by defining the Extended ASSOCIATION object.
[RFC4872]は、RSVP ASSOCIATIONオブジェクトを定義します。これは、回復LSPを保護しているLSPに関連付けるために使用されるGMPLS制御LSPのコンテキストで定義されました。このオブジェクトには、RSVP状態を関連付けるメカニズムとしての幅広い適用性もあります。 [RFC6780]では、拡張ASSOCIATIONオブジェクトを定義することにより、ASSOCIATIONオブジェクトをより一般的に適用する方法について説明しています。
This document introduces a generic mechanism to create a grouping of LSPs. This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and it is equally applicable to the stateful PCE (active and passive modes) and the stateless PCE. The associations could be created dynamically and conveyed to a PCEP peer within PCEP, or they could be configured manually by an operator on the PCEP peers. Refer to Section 3.3 for more details.
このドキュメントでは、LSPのグループを作成するための一般的なメカニズムを紹介します。次に、このグループ化を使用して、LSPのセット間またはLSPのセットと属性（構成パラメーターや動作など）のセット間の関連付けを定義できます。これは、ステートフルPCE（アクティブモードとパッシブモード）およびステートレスPCE。アソシエーションは動的に作成され、PCEP内のPCEPピアに伝達されるか、またはPCEPピアのオペレーターが手動で構成できます。詳細については、セクション3.3を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document uses the following terms defined in [RFC5440]:
このドキュメントでは、[RFC5440]で定義されている次の用語を使用します。
* PCC
* PCC
* PCE
* PCE
* PCEP Peer
* PCEPピア
* Path Computation Request (PCReq)
* パス計算リクエスト（PCReq）
* Path Computation Reply (PCRep)
* パス計算応答（PCRep）
* PCEP Error (PCErr)
* PCEPエラー（PCErr）
This document uses the following terms defined in [RFC8051]:
このドキュメントでは、[RFC8051]で定義されている次の用語を使用します。
* Stateful PCE
* ステートフルPCE
* Active Stateful PCE
* アクティブなステートフルPCE
* Passive Stateful PCE
* パッシブステートフルPCE
* Delegation
* 委任
This document uses the following terms defined in [RFC8231]:
このドキュメントでは、[RFC8231]で定義されている次の用語を使用します。
* LSP State Report (PCRpt)
* LSP状態レポート（PCRpt）
* LSP Update Request (PCUpd)
* LSP更新要求（PCUpd）
* State Timeout Interval
* 状態タイムアウト間隔
This document uses the following terms defined in [RFC8281]:
このドキュメントでは、[RFC8281]で定義されている次の用語を使用します。
* PCE-initiated LSP
* PCEによって開始されたLSP
* LSP Initiate Request (PCInitiate)
* LSP開始要求（PCInitiate）
A stateful PCE provides the ability to update existing LSPs and to instantiate new ones. There are various situations where several LSPs need to share common information. For example, to support PCE-controlled make-before-break, an association between the original path and the reoptimized path is desired. Similarly, for end-to-end protection, an association between working and protection LSPs is required (see [PCE-PROTECTION]). For diverse paths, an association between a group of LSPs could be used (see [PCE-DIVERSITY]). Another use for an LSP grouping would be to apply a common set of configuration parameters or behaviors to a set of LSPs.
ステートフルPCEは、既存のLSPを更新し、新しいLSPをインスタンス化する機能を提供します。複数のLSPが共通の情報を共有する必要があるさまざまな状況があります。たとえば、PCE制御のmake-before-breakをサポートするには、元のパスと再最適化されたパスの関連付けが必要です。同様に、エンドツーエンド保護の場合、現用LSPと保護LSPの間の関連付けが必要です（[PCE-PROTECTION]を参照）。多様なパスの場合、LSPのグループ間の関連付けを使用できます（[PCE-DIVERSITY]を参照）。 LSPグループ化のもう1つの使用法は、LSPのセットに構成パラメーターまたは動作の共通セットを適用することです。
For a stateless PCE, it might be useful to associate a PCReq message to an association group, thus enabling it to associate a common set of policies, configuration parameters, or behaviors with the request.
ステートレスPCEの場合、PCReqメッセージをアソシエーショングループに関連付けて、ポリシー、構成パラメーター、または動作の共通セットを要求に関連付けることができるようにすると便利な場合があります。
Some associations could be created dynamically, such as an association between the working and protection LSPs of a tunnel, whereas some associations could be created by the operator manually, such as a policy-based association where the LSP could join an operator-configured existing association.
トンネルの現用LSPと保護LSP間の関連付けなど、一部の関連付けは動的に作成できますが、LSPがオペレーターが構成した既存の関連付けに参加できるポリシーベースの関連付けなど、一部の関連付けはオペレーターが手動で作成できます。 。
Rather than creating separate mechanisms for each use case, this document defines a generic mechanism that can be reused as needed.
このドキュメントでは、ユースケースごとに個別のメカニズムを作成するのではなく、必要に応じて再利用できる汎用メカニズムを定義します。
Note that [RFC5440] defines a mechanism for the synchronization of a set of PCReq messages by using the SVEC (Synchronization VECtor) object, which specifies the list of synchronized requests that can be either dependent or independent. The SVEC object identifies the relationship between the set of PCReq messages, identified by "Request-ID-number" in the RP (Request Parameters) object. [RFC6007] further clarifies the use of the SVEC list for synchronized path computations when computing dependent requests, and it describes a number of usage scenarios for SVEC lists within single-domain and multi-domain environments.
[RFC5440]は、SVEC（Synchronization VECtor）オブジェクトを使用してPCReqメッセージのセットを同期するためのメカニズムを定義していることに注意してください。これは、依存または独立の同期要求のリストを指定します。 SVECオブジェクトは、RP（Request Parameters）オブジェクトの「Request-ID-number」で識別されるPCReqメッセージのセット間の関係を識別します。 [RFC6007]は、従属要求を計算するときの同期パス計算のためのSVECリストの使用をさらに明確にし、単一ドメインおよびマルチドメイン環境内でのSVECリストの多数の使用シナリオについて説明します。
The motivations behind the association group defined in this document and the SVEC object are quite different, though some use cases may overlap. PCEP extensions that define a new Association Type should clarify the relationship between the SVEC object and the Association Type, if any.
このドキュメントで定義されている関連グループとSVECオブジェクトの背後にある動機はまったく異なりますが、一部のユースケースは重複する場合があります。新しいアソシエーションタイプを定義するPCEP拡張は、SVECオブジェクトとアソシエーションタイプの間の関係を明確にします（存在する場合）。
LSPs are associated with other LSPs with which they interact by adding them to a common association group. Association groups as defined in this document can be applied to LSPs originating at the same headend or different headends.
LSPは、共通の関連付けグループに追加することで相互に作用する他のLSPに関連付けられます。このドキュメントで定義されているアソシエーショングループは、同じヘッドエンドまたは異なるヘッドエンドで発信されたLSPに適用できます。
Some associations could be created dynamically by a PCEP speaker, and the associations (along with the set of LSPs) are conveyed to a PCEP peer. Whereas some associations are configured by the operator beforehand on the PCEP peers in question, a PCEP speaker could then ask an LSP to join the Operator-configured Association. Usage of dynamic and configured associations is usually dependent on the type of association.
一部の関連付けは、PCEPスピーカーによって動的に作成でき、関連付けは（LSPのセットとともに）PCEPピアに伝達されます。一部のアソシエーションは、問題のPCEPピアでオペレーターによって事前に構成されていますが、PCEPスピーカーは、オペレーターが構成したアソシエーションに参加するようにLSPに要求できます。動的で構成された関連付けの使用は、通常、関連付けのタイプによって異なります。
For Operator-configured Associations, the association parameters, such as the Association Identifier (Association ID), Association Type, and the Association Source IP address, are manually configured by the operator. In the case of a dynamic association, the association parameters, such as the Association ID, are allocated dynamically by the PCEP speaker. The Association Source is set as the local PCEP speaker address unless local policy dictates otherwise, in which case the Association Source is set based on the local policy.
オペレーター設定の関連付けの場合、関連付け識別子（関連付けID）、関連付けタイプ、関連付けソースIPアドレスなどの関連付けパラメーターは、オペレーターが手動で設定します。動的関連付けの場合、関連付けIDなどの関連付けパラメーターは、PCEPスピーカーによって動的に割り当てられます。アソシエーションソースは、ローカルポリシーで特に指定されていない限り、ローカルPCEPスピーカーアドレスとして設定されます。その場合、アソシエーションソースはローカルポリシーに基づいて設定されます。
The dynamically created association can be reported to the PCEP peer via the PCEP messages as per the stateful extensions. When the Operator-configured Association is known to the PCEP peer beforehand, a PCEP peer could ask an LSP to join the Operator-configured Association via the stateful PCEP messages.
動的に作成された関連付けは、ステートフル拡張に従って、PCEPメッセージを介してPCEPピアに報告できます。オペレーター構成の関連付けがPCEPピアに事前に認識されている場合、PCEPピアはLSPに、ステートフルPCEPメッセージを介してオペレーター構成の関連付けに参加するように要求できます。
The associations are properties of the LSP and thus could be stored in the LSP state database. The dynamic association exists as long as the LSP state exists. In the case of PCEP session termination, the LSP state cleanup MUST also take care of associations.
関連付けはLSPのプロパティであるため、LSP状態データベースに格納できます。 LSP状態が存在する限り、動的関連付けは存在します。 PCEPセッション終了の場合、LSP状態のクリーンアップも関連付けを処理する必要があります。
Multiple types of associations can exist, each with its own Association ID space. The definition of the different Association Types and their behaviors is outside the scope of this document. The establishment and removal of the association relationship can be done on a per-LSP basis. An LSP may join multiple association groups that have the same Association Type or different Association Types.
それぞれ独自のアソシエーションIDスペースを持つ複数のタイプのアソシエーションが存在できます。さまざまな関連タイプとその動作の定義は、このドキュメントの範囲外です。アソシエーション関係の確立と削除は、LSPごとに行うことができます。 LSPは、同じアソシエーションタイプまたは異なるアソシエーションタイプを持つ複数のアソシエーショングループに参加できます。
Some Association Types are dynamic, some are operator configured, and some could be both. For the Association Types that could be both dynamic and operator configured and use the same Association Source, it is necessary to distinguish a range of Association IDs that are marked for Operator-configured Associations, to avoid any Association ID clashes within the scope of the Association Source. This document assumes that these two ranges are configured.
一部の関連タイプは動的であり、一部はオペレーター構成であり、一部は両方である可能性があります。動的とオペレーターの両方で構成でき、同じアソシエーションソースを使用できるアソシエーションタイプの場合、オペレーターが構成したアソシエーション用にマークされているアソシエーションIDの範囲を区別して、アソシエーションのスコープ内でアソシエーションIDの衝突を回避する必要があります。ソース。このドキュメントでは、これら2つの範囲が構成されていることを前提としています。
A range of Association IDs for each Association Type (and Association Source) is kept for the Operator-configured Associations. Dynamic associations MUST NOT use the Association ID from this range.
各アソシエーションタイプ（およびアソシエーションソース）のアソシエーションIDの範囲は、オペレーターが設定したアソシエーションに対して保持されます。動的関連付けでは、この範囲の関連付けIDを使用してはなりません（MUST NOT）。
This range, as set at the PCEP speaker (a PCC or PCE, as an Association Source), needs to be communicated to a PCEP peer in the Open message. A new TLV is defined in this specification for this purpose (Section 5). See Appendix A for an example.
PCEPスピーカー（PCCまたはPCE、アソシエーションソース）で設定されたこの範囲は、OpenメッセージでPCEPピアに通信する必要があります。この目的のために、この仕様では新しいTLVが定義されています（セクション5）。例については、付録Aを参照してください。
The Association ID range for sources other than the PCEP speaker (for example, a Network Management System (NMS)) is not communicated in PCEP, and the procedure for Operator-configured Association Range settings is outside the scope of this document.
PCEPスピーカー以外のソース（たとえば、ネットワーク管理システム（NMS））のアソシエーションID範囲はPCEPで通信されず、オペレーターが構成したアソシエーション範囲設定の手順はこのドキュメントの範囲外です。
This section defines PCEP extensions so as to support the capability advertisement of the Association Types supported by a PCEP speaker.
このセクションでは、PCEPスピーカーによってサポートされるアソシエーションタイプの機能アドバタイズメントをサポートするために、PCEP拡張を定義します。
A new PCEP ASSOC-Type-List (Association Types list) TLV is defined. The PCEP ASSOC-Type-List TLV is carried within an OPEN object. This way, during the PCEP session-setup phase, a PCEP speaker can advertise to a PCEP peer the list of supported Association Types.
新しいPCEP ASSOC-Type-List（アソシエーションタイプリスト）TLVが定義されています。 PCEP ASSOC-Type-List TLVは、OPENオブジェクト内で伝送されます。このように、PCEPセッションのセットアップフェーズ中に、PCEPスピーカーは、サポートされているアソシエーションタイプのリストをPCEPピアにアドバタイズできます。
The PCEP ASSOC-Type-List TLV is OPTIONAL. It MAY be carried within an OPEN object sent by a PCEP speaker in an Open message to a PCEP peer so as to indicate the list of supported Association Types.
PCEP ASSOC-Type-List TLVはオプションです。サポートされるアソシエーションタイプのリストを示すために、PCEPスピーカーがOpenメッセージでPCEPピアに送信するOPENオブジェクト内で運ばれる場合があります。
The PCEP ASSOC-Type-List TLV format is compliant with the PCEP TLV format defined in [RFC5440]. That is, the TLV is composed of 2 octets for the type, 2 octets specifying the TLV length, and a Value field. The Length field defines the length of the value portion in octets. The TLV is padded to 4-octet alignment, and padding is not included in the Length field (e.g., a 3-octet value would have a length of three, but the total size of the TLV would be 8 octets).
PCEP ASSOC-Type-List TLV形式は、[RFC5440]で定義されているPCEP TLV形式に準拠しています。つまり、TLVはタイプの2オクテット、TLV長を指定する2オクテット、および値フィールドで構成されます。長さフィールドは、値の部分の長さをオクテットで定義します。 TLVは4オクテットアライメントにパディングされ、パディングは[長さ]フィールドに含まれません（たとえば、3オクテットの値の長さは3ですが、TLVの合計サイズは8オクテットになります）。
The PCEP ASSOC-Type-List TLV has the following format:
PCEP ASSOC-Type-List TLVの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assoc-Type #1 | Assoc-Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assoc-Type #N | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The ASSOC-Type-List TLV Format
図1：ASSOC-Type-List TLV形式
Type: 35
タイプ：35
Length: N * 2 (where N is the number of Association Types).
長さ：N * 2（Nは関連タイプの数）。
Value: List of 2-byte Association Type code points, identifying the Association Types supported by the sender of the Open message.
値：2バイトのアソシエーションタイプコードポイントのリスト。Openメッセージの送信者がサポートするアソシエーションタイプを識別します。
Assoc-Type (2 bytes): Association Type code point identifier. IANA manages the "ASSOCIATION Type Field" code point registry (see Section 7.4).
Assoc-Type（2バイト）：関連タイプコードポイント識別子。 IANAは、「ASSOCIATION Type Field」コードポイントレジストリを管理します（セクション7.4を参照）。
An ASSOC-Type-List TLV within an OPEN object in an Open message is included by a PCEP speaker in order to advertise a set of one or more supported Association Types. The ASSOC-Type-List TLV MUST NOT appear more than once in an OPEN object. If it appears more than once, the PCEP session MUST be rejected with Error-Type 1 and Error-value 1 (PCEP session establishment failure / Reception of an invalid Open message). As specified in [RFC5440], a PCEP peer that does not recognize the ASSOC-Type-List TLV will silently ignore it.
OpenメッセージのOPENオブジェクト内のASSOC-Type-List TLVは、サポートされている1つ以上の関連タイプのセットをアドバタイズするために、PCEPスピーカーによって含まれます。 ASSOC-Type-List TLVは、OPENオブジェクトで複数回使用してはなりません（MUST NOT）。複数回表示される場合は、PCEPセッションをエラータイプ1およびエラー値1（PCEPセッションの確立の失敗/無効なOpenメッセージの受信）で拒否する必要があります。 [RFC5440]で指定されているように、ASSOC-Type-List TLVを認識しないPCEPピアは黙ってそれを無視します。
The Association Type (to be defined in future documents) can specify if the Association Type advertisement is mandatory for it. Thus, the ASSOC-Type-List TLV MUST be included if at least one mandatory Association Type needs to be advertised, and the ASSOC-Type-List TLV MAY be included otherwise. For an Association Type that specifies that the advertisement is mandatory, a missing Assoc-Type in the ASSOC-Type-List TLV (or a missing ASSOC-Type-List TLV) is to be interpreted as meaning that the Association Type is not supported by the PCEP speaker.
関連タイプ（将来のドキュメントで定義される予定）は、関連タイプの提供が必須かどうかを指定できます。したがって、少なくとも1つの必須のアソシエーションタイプをアドバタイズする必要がある場合はASSOC-Type-List TLVを含める必要があり、そうでない場合はASSOC-Type-List TLVを含める必要があります。アドバタイズメントが必須であることを指定するアソシエーションタイプの場合、ASSOC-Type-List TLVに欠落しているAssoc-Type（または欠落しているASSOC-Type-List TLV）は、関連タイプがサポートされていないことを意味すると解釈されます。 PCEPスピーカー。
The absence of the ASSOC-Type-List TLV in an OPEN object MUST be interpreted as an absence of information in the list of supported Association Types (rather than an indication that the Association Type is not supported). In this case, the PCEP speaker could still use the ASSOCIATION object: if the peer does not support the association, it will react as per the procedure described in Section 6.4.
OPENオブジェクトにASSOC-Type-List TLVがないことは、サポートされるアソシエーションタイプのリストに情報がないことと解釈する必要があります（アソシエーションタイプがサポートされていないことを示すものではありません）。この場合、PCEPスピーカーは引き続きASSOCIATIONオブジェクトを使用できます。ピアが関連付けをサポートしていない場合は、セクション6.4で説明されている手順に従って反応します。
If the use of the ASSOC-Type-List TLV is triggered by support for a mandatory Association Type, then it is RECOMMENDED that the PCEP implementation include all supported Association Types (including optional types) to ease the operations of the PCEP peer.
ASSOC-Type-List TLVの使用が必須のアソシエーションタイプのサポートによってトリガーされる場合、PCEP実装がサポートされているすべてのアソシエーションタイプ（オプションのタイプを含む）を含み、PCEPピアの操作を容易にすることが推奨されます。
This section defines a PCEP extension to support the advertisement of the Operator-configured Association Range used for an Association Type by the PCEP speaker (as an Association Source).
このセクションでは、PCEPスピーカーが（アソシエーションソースとして）アソシエーションタイプに使用するオペレーター構成のアソシエーション範囲のアドバタイズをサポートするPCEP拡張を定義します。
A new PCEP OP-CONF-ASSOC-RANGE (Operator-configured Association Range) TLV is defined. The PCEP OP-CONF-ASSOC-RANGE TLV is carried within an OPEN object. This way, during the PCEP session-setup phase, a PCEP speaker can advertise to a PCEP peer the Operator-configured Association Range for an Association Type.
新しいPCEP OP-CONF-ASSOC-RANGE（オペレーターが構成した関連付け範囲）TLVが定義されています。 PCEP OP-CONF-ASSOC-RANGE TLVは、OPENオブジェクト内で伝送されます。このように、PCEPセッションのセットアップフェーズ中に、PCEPスピーカーは、アソシエーションタイプのオペレーター設定のアソシエーション範囲をPCEPピアにアドバタイズできます。
The PCEP OP-CONF-ASSOC-RANGE TLV is OPTIONAL. It MAY be carried within an OPEN object sent by a PCEP speaker in an Open message to a PCEP peer. The OP-CONF-ASSOC-RANGE TLV format is compliant with the PCEP TLV format defined in [RFC5440]. That is, the TLV is composed of 2 bytes for the type, 2 bytes specifying the TLV length, and a Value field. The Length field defines the length of the value portion in bytes.
PCEP OP-CONF-ASSOC-RANGE TLVはオプションです。 PCEPスピーカーにOpenメッセージでPCEPピアに送信されたOPENオブジェクト内で運ばれる場合があります。 OP-CONF-ASSOC-RANGE TLV形式は、[RFC5440]で定義されているPCEP TLV形式に準拠しています。つまり、TLVは、タイプの2バイト、TLVの長さを指定する2バイト、および値フィールドで構成されます。長さフィールドは、値部分の長さをバイト単位で定義します。
The PCEP OP-CONF-ASSOC-RANGE TLV has the following format:
PCEP OP-CONF-ASSOC-RANGE TLVの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Assoc-Type #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Assoc-ID #1 | Range #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Assoc-Type #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Assoc-ID #N | Range #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The OP-CONF-ASSOC-RANGE TLV Format
図2：OP-CONF-ASSOC-RANGE TLV形式
Type: 29
タイプ：29
Length: N * 8 (where N is the number of Association Types).
長さ：N * 8（Nは関連タイプの数）。
Value: Includes the following fields, repeated for each Association Type:
値：関連付けの種類ごとに繰り返される以下のフィールドが含まれます。
Reserved (2 bytes): MUST be set to 0 on transmission and MUST be ignored on receipt.
予約済み（2バイト）：送信時に0に設定する必要があり、受信時に無視する必要があります。
Assoc-Type (2 bytes): The Association Type (Section 7.4). The Association Types will be defined in future documents.
Assoc-Type（2バイト）：関連タイプ（セクション7.4）。関連タイプは、将来のドキュメントで定義されます。
Start-Assoc-ID (2 bytes): The "start association" identifier for the Operator-configured Association Range for the particular Association Type. The values 0 and 0xffff MUST NOT be used; on receipt of these values in the TLV, the session is rejected, and an error message is sent (see Section 5.1).
Start-Assoc-ID（2バイト）：特定のアソシエーションタイプのオペレーター設定のアソシエーション範囲の「開始アソシエーション」識別子。値0および0xffffを使用してはなりません（MUST NOT）。 TLVでこれらの値を受信すると、セッションは拒否され、エラーメッセージが送信されます（セクション5.1を参照）。
Range (2 bytes): The number of associations marked for the Operator-configured Associations. Range MUST be greater than 0, and it MUST be such that (Start-Assoc-ID + Range) does not cross the largest Association ID value of 0xffff. If this condition is not satisfied, the session is rejected, and an error message is sent (see Section 5.1).
範囲（2バイト）：オペレーター設定の関連付け用にマークされた関連付けの数。範囲は0より大きくなければならず、（Start-Assoc-ID + Range）が最大のアソシエーションID値である0xffffを超えないようにする必要があります。この条件が満たされない場合、セッションは拒否され、エラーメッセージが送信されます（セクション5.1を参照）。
A PCEP speaker MAY include an OP-CONF-ASSOC-RANGE TLV within an OPEN object in an Open message sent to a PCEP peer in order to advertise the Operator-configured Association Range for an Association Type. The OP-CONF-ASSOC-RANGE TLV MUST NOT appear more than once in an OPEN object. If it appears more than once, the PCEP session MUST be rejected with Error-Type 1 and Error-value 1 (PCEP session establishment failure / Reception of an invalid Open message).
PCEPスピーカーは、関連付けタイプのオペレーター設定の関連付け範囲を通知するために、PCEPピアに送信されるOpenメッセージのOPENオブジェクト内にOP-CONF-ASSOC-RANGE TLVを含めることができます（MAY）。 OP-CONF-ASSOC-RANGE TLVは、OPENオブジェクトで複数回使用することはできません。複数回表示される場合は、PCEPセッションをエラータイプ1およびエラー値1（PCEPセッションの確立の失敗/無効なOpenメッセージの受信）で拒否する必要があります。
As specified in [RFC5440], a PCEP peer that does not recognize the OP-CONF-ASSOC-RANGE TLV will silently ignore it.
[RFC5440]で指定されているように、OP-CONF-ASSOC-RANGE TLVを認識しないPCEPピアは、それを黙って無視します。
The Operator-configured Association Range SHOULD be included for each Association Type that could be both dynamic and operator configured. For Association Types that are only dynamic or only operator configured, this TLV MAY be skipped, in which case the full range of Association IDs is considered dynamic or operator configured, respectively. Each Association Type (to be defined in future documents) can specify the default value for its Operator-configured Association Range.
オペレーターが設定した関連範囲は、動的とオペレーターの両方が設定できる関連タイプごとに含める必要があります（SHOULD）。動的のみまたはオペレーターのみが構成されている関連タイプの場合、このTLVはスキップされる場合があります。その場合、関連IDの全範囲は、それぞれ動的またはオペレーターが構成されていると見なされます。各アソシエーションタイプ（将来のドキュメントで定義される予定）は、オペレーターが設定したアソシエーション範囲のデフォルト値を指定できます。
The absence of the OP-CONF-ASSOC-RANGE TLV in an OPEN object MUST be interpreted as an absence of an explicit Operator-configured Association Range at the PCEP peer. In this case, the default behavior as per each Association Type applies. If the Association Source is not a PCEP speaker, the default value for the Operator-configured Association Range is used for the Association Source.
OPENオブジェクトにOP-CONF-ASSOC-RANGE TLVがないことは、PCEPピアでオペレーターが設定した明示的なアソシエーション範囲がないことと解釈する必要があります。この場合、各関連タイプによるデフォルトの動作が適用されます。アソシエーションソースがPCEPスピーカーでない場合、オペレーター設定のアソシエーション範囲のデフォルト値がアソシエーションソースに使用されます。
If the Assoc-Type is not recognized or supported by the PCEP speaker, it MUST ignore that respective (Start-Assoc-ID + Range). If the Assoc-Type is recognized/supported but Start-Assoc-ID or Range is set incorrectly, the PCEP session MUST be rejected with Error-Type 1 and Error-value 1 (PCEP session establishment failure / Reception of an invalid Open message). The incorrect range includes the case when the (Start-Assoc-ID + Range) crosses the largest Association ID value of 0xffff.
Assoc-TypeがPCEPスピーカーで認識またはサポートされていない場合は、それぞれの（Start-Assoc-ID + Range）を無視する必要があります。 Assoc-Typeが認識/サポートされているが、Start-Assoc-IDまたはRangeが正しく設定されていない場合、PCEPセッションはError-Type 1およびError-value 1（PCEPセッションの確立の失敗/無効なOpenメッセージの受信）で拒否される必要があります。 。誤った範囲には、（Start-Assoc-ID + Range）が最大のアソシエーションID値である0xffffを超える場合が含まれます。
A given Assoc-Type MAY appear more than once in the OP-CONF-ASSOC-RANGE TLV in the case of a non-contiguous Operator-configured Association Range. The PCEP speaker originating this TLV MUST NOT send overlapping ranges for an Association Type. If a PCEP peer receives overlapping ranges for an Association Type, it MUST consider the Open message malformed and MUST reject the PCEP session with Error-Type 1 and Error-value 1 (PCEP session establishment failure / Reception of an invalid Open message).
特定のAssoc-Typeは、隣接するオペレーター設定の関連範囲の場合、OP-CONF-ASSOC-RANGE TLVに複数回出現する場合があります。このTLVを発信するPCEPスピーカーは、アソシエーションタイプの重複する範囲を送信してはなりません。 PCEPピアがアソシエーションタイプの重複範囲を受信する場合、それは不正なオープンメッセージを考慮しなければならず、エラータイプ1およびエラー値1（PCEPセッションの確立の失敗/無効なオープンメッセージの受信）でPCEPセッションを拒否する必要があります。
There may be cases where an Operator-configured Association was configured with association parameters (such as an Association ID, Association Type, and Association Source) at the local PCEP speaker, and the PCEP session is later established with the Association Source and a new operator-configured range is learned during session establishment. At this time, the local PCEP speaker MUST remove any associations that are not in the new operator-configured range (by disassociating any LSPs that are part of it (and notifying the PCEP peer of this change)). If a PCEP speaker receives an association for an Operator-configured Association and the Association ID is not in the Operator-configured Association Range for the Association Type and Association Source, it MUST generate an error (as described in Section 6.4).
オペレーター設定の関連付けがローカルPCEPスピーカーで関連付けパラメーター（関連付けID、関連付けタイプ、関連付けソースなど）を使用して設定され、PCEPセッションが関連付けソースと新しいオペレーターで後で確立される場合があります。 -構成された範囲は、セッションの確立中に学習されます。このとき、ローカルのPCEPスピーカーは、新しいオペレーターが構成した範囲にないすべての関連付けを削除する必要があります（その一部であるLSPの関連付けを解除します（この変更をPCEPピアに通知します）。） PCEPスピーカーがオペレーターが設定したアソシエーションのアソシエーションを受信し、アソシエーションIDがアソシエーションタイプとアソシエーションソースのオペレーターが設定したアソシエーション範囲にない場合、エラーを生成する必要があります（セクション6.4を参照）。
Association groups and their memberships are defined using a new ASSOCIATION object.
関連グループとそのメンバーシップは、新しいASSOCIATIONオブジェクトを使用して定義されます。
The ASSOCIATION Object-Class value is 40.
ASSOCIATIONオブジェクトクラスの値は40です。
The ASSOCIATION Object-Type value is 1 for IPv4, and its format is shown in Figure 3:
ASSOCIATION Object-Type値はIPv4の場合1で、その形式を図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The IPv4 ASSOCIATION Object Format
図3：IPv4 ASSOCIATIONオブジェクト形式
The ASSOCIATION Object-Type value is 2 for IPv6, and its format is shown in Figure 4:
ASSOCIATION Object-Type値はIPv6の場合2であり、その形式を図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Association Source |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The IPv6 ASSOCIATION Object Format
図4：IPv6 ASSOCIATIONオブジェクト形式
Reserved (2 bytes): MUST be set to 0 and ignored upon receipt.
予約済み（2バイト）：0に設定する必要があり、受信時に無視されます。
Flags (2 bytes): The following flag is currently defined:
フラグ（2バイト）：現在、次のフラグが定義されています。
R (Removal - 1 bit): When set, the requesting PCEP peer requires the removal of an LSP from the association group. When unset, the PCEP peer indicates that the LSP is added or retained as part of the association group. This flag is used for the ASSOCIATION object in the Path Computation Report (PCRpt) and Path Computation Update (PCUpd) messages. It is ignored in other PCEP messages.
R（削除-1ビット）：設定すると、要求側のPCEPピアは、関連付けグループからのLSPの削除を要求します。設定を解除すると、PCEPピアは、LSPが関連付けグループの一部として追加または保持されることを示します。このフラグは、パス計算レポート（PCRpt）およびパス計算更新（PCUpd）メッセージのASSOCIATIONオブジェクトに使用されます。他のPCEPメッセージでは無視されます。
The unassigned flags MUST be set to 0 on transmission and MUST be ignored on receipt.
割り当てられていないフラグは送信時に0に設定する必要があり、受信時には無視する必要があります。
Association Type (2 bytes): The Association Type (Section 7.4). The Association Types will be defined in future documents.
関連タイプ（2バイト）：関連タイプ（セクション7.4）。関連タイプは、将来のドキュメントで定義されます。
Association ID (2 bytes): The identifier of the association group. When combined with other association parameters, such as an Association Type and Association Source, this value uniquely identifies an association group. The values 0xffff and 0x0 are reserved. The value 0xffff is used to indicate all association groups and could be used with the R flag to indicate removal for all associations for the LSP within the scope of the Association Type and Association Source.
関連ID（2バイト）：関連グループの識別子。関連タイプや関連ソースなどの他の関連パラメーターと組み合わせると、この値は関連グループを一意に識別します。値0xffffおよび0x0は予約されています。値0xffffはすべてのアソシエーショングループを示すために使用され、Rフラグと一緒に使用して、アソシエーションタイプとアソシエーションソースのスコープ内のLSPのすべてのアソシエーションの削除を示すことができます。
Association Source: Contains a valid IPv4 address (4 bytes) if the ASSOCIATION Object-Type is 1 or a valid IPv6 address (16 bytes) if the ASSOCIATION Object-Type is 2. The address provides scoping for the Association ID. See Section 6.1.3 for details.
アソシエーションソース：ASSOCIATIONオブジェクトタイプが1の場合は有効なIPv4アドレス（4バイト）が含まれ、ASSOCIATIONオブジェクトタイプが2の場合は有効なIPv6アドレス（16バイト）が含まれます。アドレスはアソシエーションIDのスコープを提供します。詳細については、セクション6.1.3を参照してください。
Optional TLVs: The optional TLVs follow the PCEP TLV format defined in [RFC5440]. This document defines two optional TLVs. Other documents can define more TLVs in the future.
オプションのTLV：オプションのTLVは、[RFC5440]で定義されているPCEP TLV形式に従います。このドキュメントでは、2つのオプションのTLVを定義しています。他のドキュメントでは、今後さらに多くのTLVを定義できます。
The Global Association Source TLV is an optional TLV for use in the ASSOCIATION object. The meaning and usage of the Global Association Source TLV are as per Section 4 of [RFC6780].
グローバルアソシエーションソースTLVは、ASSOCIATIONオブジェクトで使用するオプションのTLVです。 Global Association Source TLVの意味と使用法は、[RFC6780]のセクション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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The Global Association Source TLV Format
図5：グローバルアソシエーションソースTLV形式
Type: 30
タイプ：30
Length: Fixed value of 4 bytes.
長さ：4バイトの固定値。
Global Association Source: As defined in Section 4 of [RFC6780].
グローバルアソシエーションソース：[RFC6780]のセクション4で定義されています。
The Extended Association ID TLV is an optional TLV for use in the ASSOCIATION object. The meaning and usage of the Extended Association ID TLV are as per Section 4 of [RFC6780].
拡張アソシエーションID TLVは、ASSOCIATIONオブジェクトで使用するオプションのTLVです。拡張アソシエーションID TLVの意味と使用法は、[RFC6780]のセクション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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Extended Association ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: The Extended Association ID TLV Format
図6：拡張アソシエーションID TLV形式
Type: 31
タイプ：31
Length: Variable.
長さ：可変。
Extended Association ID: As defined in Section 4 of [RFC6780].
拡張アソシエーションID：[RFC6780]のセクション4で定義されています。
The Association Source field in the ASSOCIATION object is set to a valid IP address to identify the node that originated the association. In the case of dynamic associations, the Association Source is usually set as the local PCEP speaker address unless local policy dictates otherwise, in which case the Association Source is set based on the local policy. In the case of PCE redundancy, local policy could set the source as a virtual IP address that identifies all instances of the PCE. In the case of Operator-configured Associations, the Association Source is manually configured, and it could be set as one of the PCEP speakers, an NMS, or any other valid IP address that scopes the Association ID for the Association Type.
ASSOCIATIONオブジェクトのAssociation Sourceフィールドは、関連付けを開始したノードを識別するために有効なIPアドレスに設定されています。ダイナミックアソシエーションの場合、ローカルポリシーが特に指示しない限り、アソシエーションソースはローカルPCEPスピーカーアドレスとして設定されます。その場合、アソシエーションソースはローカルポリシーに基づいて設定されます。 PCE冗長性の場合、ローカルポリシーは、ソースをPCEのすべてのインスタンスを識別する仮想IPアドレスとして設定できます。オペレーター設定の関連付けの場合、関連付けソースは手動で設定され、PCEPスピーカー、NMS、または関連付けタイプの関連付けIDをスコープとするその他の有効なIPアドレスの1つとして設定できます。
The combination of the mandatory fields Association Type, Association ID, and Association Source in the ASSOCIATION object uniquely identifies the association group. If the optional TLVs (Global Association Source and Extended Association ID) are included, then they MUST be included in combination with mandatory fields to uniquely identify the association group. In this document, all these fields are collectively called "association parameters". Note that the ASSOCIATION object MAY include other optional TLVs (not defined in this document) based on the Association Types. These TLVs provide "information" related to the Association Type. This document refers to this information as "association information".
ASSOCIATIONオブジェクトの必須フィールドAssociation Type、Association ID、Association Sourceの組み合わせにより、関連グループが一意に識別されます。オプションのTLV（グローバルアソシエーションソースと拡張アソシエーションID）が含まれている場合、それらを必須フィールドと組み合わせて含めて、アソシエーショングループを一意に識別する必要があります。このドキュメントでは、これらすべてのフィールドをまとめて「関連付けパラメーター」と呼びます。 ASSOCIATIONオブジェクトには、関連タイプに基づく他のオプションのTLV（このドキュメントでは定義されていません）が含まれる場合があります。これらのTLVは、アソシエーションタイプに関連する「情報」を提供します。このドキュメントでは、この情報を「関連付け情報」と呼びます。
The format of the PCEP ASSOCIATION object defined in this document is aligned with the RSVP ASSOCIATION object [RFC6780]. Various Association Types related to RSVP association are defined in [RFC4872], [RFC4873], and [RFC7551]. The PCEP extensions that define new Association Types should clarify how the PCEP associations would work with RSVP associations and vice versa.
このドキュメントで定義されているPCEP ASSOCIATIONオブジェクトの形式は、RSVP ASSOCIATIONオブジェクト[RFC6780]と整合しています。 RSVPアソシエーションに関連するさまざまなアソシエーションタイプが[RFC4872]、[RFC4873]、および[RFC7551]で定義されています。新しいアソシエーションタイプを定義するPCEP拡張機能は、PCEPアソシエーションがRSVPアソシエーションとどのように連携するか、またその逆も明確にする必要があります。
Message formats in this document are expressed using Routing BNF (RBNF) as used in [RFC5440] and defined in [RFC5511].
このドキュメントのメッセージ形式は、[RFC5440]で使用され、[RFC5511]で定義されているルーティングBNF（RBNF）を使用して表現されています。
The ASSOCIATION object MAY be carried in the PCUpd, PCRpt, and Path Computation Initiate (PCInitiate) messages.
ASSOCIATIONオブジェクトは、PCUpd、PCRpt、およびPath Computation Initiate（PCInitiate）メッセージで伝達される場合があります。
When carried in a PCRpt message, this object is used to report the association group membership pertaining to an LSP to a stateful PCE. The PCRpt message is used for initial State Synchronization operations (Section 5.6 of [RFC8231]), as well as whenever the state of the LSP changes. If the LSP belongs to an association group, then the associations MUST be included during the State Synchronization operations.
PCRptメッセージで伝送される場合、このオブジェクトは、LSPに関連するアソシエーショングループメンバーシップをステートフルPCEに報告するために使用されます。 PCRptメッセージは、初期状態同期操作（[RFC8231]のセクション5.6）と、LSPの状態が変化するたびに使用されます。 LSPが関連グループに属している場合、その関連は状態同期操作中に含める必要があります。
The PCRpt message can also be used to remove an LSP from one or more association groups by setting the R flag to 1 in the ASSOCIATION object.
PCRptメッセージを使用して、ASSOCIATIONオブジェクトのRフラグを1に設定することにより、1つ以上の関連付けグループからLSPを削除することもできます。
When an LSP is first reported to the PCE, the PCRpt message MUST include all the association groups that it belongs to. Any subsequent PCRpt message SHOULD include only the associations that are being modified or removed.
LSPが最初にPCEに報告されるとき、PCRptメッセージには、それが属するすべてのアソシエーショングループが含まれている必要があります。後続のPCRptメッセージには、変更または削除される関連付けのみを含める必要があります（SHOULD）。
The PCRpt message is defined in [RFC8231] and updated as shown below:
PCRptメッセージは[RFC8231]で定義され、以下に示すように更新されます。
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
ただし：
<state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
[<association-list>]
<path>
Where:
ただし：
<path>::= <intended-path>
[<actual-attribute-list><actual-path>]
<intended-attribute-list>
<association-list> ::= <ASSOCIATION> [<association-list>]
When an LSP is delegated to a stateful PCE, the stateful PCE can create a new association group for this LSP or associate it with one or more existing association groups. This is done by including the ASSOCIATION object in a PCUpd message. A stateful PCE can also remove a delegated LSP from one or more association groups by setting the R flag to 1 in the ASSOCIATION object.
LSPがステートフルPCEに委任されると、ステートフルPCEはこのLSPの新しい関連付けグループを作成するか、または1つ以上の既存の関連付けグループに関連付けることができます。これは、PCUpdメッセージにASSOCIATIONオブジェクトを含めることによって行われます。ステートフルPCEは、ASSOCIATIONオブジェクトでRフラグを1に設定することにより、1つ以上の関連付けグループから委任されたLSPを削除することもできます。
The PCUpd message SHOULD include the association groups that are being modified or removed. There is no need to include associations that remain unchanged.
PCUpdメッセージには、変更または削除される関連グループを含める必要があります（SHOULD）。変更されないままの関連付けを含める必要はありません。
The PCUpd message is defined in [RFC8231] and updated as shown below:
PCUpdメッセージは[RFC8231]で定義され、以下のように更新されます。
<PCUpd Message> ::= <Common Header>
<update-request-list>
Where:
ただし：
<update-request-list> ::= <update-request>[<update-request-list>]
<update-request> ::= <SRP>
<LSP>
[<association-list>]
<path>
Where:
ただし：
<path>::= <intended-path><intended-attribute-list>
<association-list> ::= <ASSOCIATION> [<association-list>]
Unless a PCEP speaker wants to delete an association from an LSP or make changes to the association, it does not need to include the ASSOCIATION object in future stateful messages.
PCEPスピーカーがLSPから関連付けを削除したり、関連付けを変更したりしない限り、将来のステートフルメッセージにASSOCIATIONオブジェクトを含める必要はありません。
A PCE initiating a new LSP can also include the association groups that this LSP belongs to. This is done by including the ASSOCIATION object in a PCInitiate message. The PCInitiate message MUST include all the association groups that it belongs to. The PCInitiate message is defined in [RFC8281] and updated as shown below:
新しいLSPを開始するPCEには、このLSPが属するアソシエーショングループを含めることもできます。これは、PCInitiateメッセージにASSOCIATIONオブジェクトを含めることによって行われます。 PCInitiateメッセージには、それが属するすべての関連グループを含める必要があります。 PCInitiateメッセージは[RFC8281]で定義され、以下に示すように更新されます。
<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list>
Where:
ただし：
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|
<PCE-initiated-lsp-deletion>)
<PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP>
[<END-POINTS>]
<ERO>
[<association-list>]
[<attribute-list>]
Where:
ただし：
<association-list> ::= <ASSOCIATION> [<association-list>]
In the case of a passive (stateful or stateless) PCE, the ASSOCIATION object is OPTIONAL and MAY be carried in the PCReq message.
パッシブ（ステートフルまたはステートレス）PCEの場合、ASSOCIATIONオブジェクトはオプションであり、PCReqメッセージで搬送される場合があります。
When carried in a PCReq message, the ASSOCIATION object is used to associate the path computation request to an association group. The association (and the other LSPs) should be known to the PCE beforehand. These could be operator configured or dynamically learned beforehand via stateful PCEP messages. The R flag in the ASSOCIATION object within a PCReq message MUST be set to 0 while sending and ignored on receipt.
PCReqメッセージで伝送される場合、ASSOCIATIONオブジェクトは、パス計算要求を関連グループに関連付けるために使用されます。関連付け（およびその他のLSP）は、事前にPCEに認識されている必要があります。これらは、オペレーターが構成するか、ステートフルPCEPメッセージを介して事前に動的に学習できます。 PCReqメッセージ内のASSOCIATIONオブジェクトのRフラグは、送信中に0に設定し、受信時に無視する必要があります。
The PCReq message is defined in [RFC5440] and updated in [RFC8231]. It is further updated below for association groups:
PCReqメッセージは[RFC5440]で定義され、[RFC8231]で更新されます。関連グループについては、以下でさらに更新されます。
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
Where:
ただし：
<svec-list>::= <SVEC>[<svec-list>]
<request-list>::= <request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSP>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<association-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
Where:
ただし：
<association-list> ::= <ASSOCIATION> [<association-list>]
Note that the LSP object MAY be present for the passive stateful PCE mode.
LSPオブジェクトがパッシブステートフルPCEモードに存在してもよいことに注意してください。
In the case of a passive (stateful or stateless) PCE, the ASSOCIATION object is OPTIONAL and MAY be carried in the PCRep message with the NO-PATH object. The ASSOCIATION object in the PCRep message indicates the association group that caused the PCE to fail to find a path.
パッシブ（ステートフルまたはステートレス）PCEの場合、ASSOCIATIONオブジェクトはオプションであり、NO-PATHオブジェクトを使用してPCRepメッセージで搬送される場合があります。 PCRepメッセージ内のASSOCIATIONオブジェクトは、PCEがパスを見つけられない原因となった関連グループを示しています。
The PCRep message is defined in [RFC5440] and updated in [RFC8231]. It is further updated below for association groups:
PCRepメッセージは[RFC5440]で定義され、[RFC8231]で更新されます。関連グループについては、以下でさらに更新されます。
<PCRep Message> ::= <Common Header>
<response-list>
Where:
ただし：
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<LSP>]
[<NO-PATH>]
[<association-list>]
[<attribute-list>]
[<path-list>]
Where:
ただし：
<association-list> ::= <ASSOCIATION> [<association-list>]
Note that the LSP object MAY be present for the passive stateful PCE mode.
LSPオブジェクトがパッシブステートフルPCEモードに存在してもよいことに注意してください。
Association groups can be operator configured on the necessary PCEP speakers, and the PCEP speakers can join the existing association groups. In addition, a PCC or a PCE can create association groups dynamically, and the PCEP speaker can also report the associations to its peer via PCEP messages. The Operator-configured Associations are created via configurations (where all association parameters are manually set) and exist until explicitly removed via configurations. The PCEP speaker can add LSPs to these configured associations and provide this information via stateful PCEP messages. The dynamic associations are created dynamically by the PCEP speaker (where all association parameters are populated dynamically). The association group is attached to the LSP state, and the association group exists until there is at least one LSP as part of the association. As described in Section 6.1.4, the association parameters are the combination of Association Type, Association ID, and Association Source, as well as the optional Global Association Source and Extended Association ID TLVs; this combination uniquely identifies an association group. The information related to the Association Types encoded via the TLVs of a particular Association Type (not described in this document) is the association information (Section 6.1.4).
アソシエーショングループは、必要なPCEPスピーカーでオペレーター設定でき、PCEPスピーカーは既存のアソシエーショングループに参加できます。さらに、PCCまたはPCEは関連付けグループを動的に作成でき、PCEPスピーカーはPCEPメッセージを介してその関連付けをピアに報告することもできます。オペレーターが設定した関連付けは、設定（すべての関連付けパラメーターが手動で設定される）を介して作成され、設定を介して明示的に削除されるまで存在します。 PCEPスピーカーは、これらの構成された関連付けにLSPを追加し、ステートフルPCEPメッセージを介してこの情報を提供できます。動的関連付けは、PCEPスピーカーによって動的に作成されます（すべての関連付けパラメーターが動的に入力されます）。アソシエーショングループはLSP状態にアタッチされ、アソシエーションの一部として少なくとも1つのLSPが存在するまでアソシエーショングループは存在します。セクション6.1.4で説明したように、関連付けパラメーターは、関連付けタイプ、関連付けID、関連付けソース、およびオプションのグローバル関連付けソースと拡張関連付けID TLVの組み合わせです。この組み合わせにより、関連グループが一意に識別されます。特定のアソシエーションタイプ（このドキュメントでは説明されていません）のTLVを介してエンコードされたアソシエーションタイプに関連する情報は、アソシエーション情報です（セクション6.1.4）。
If a PCEP speaker does not recognize the ASSOCIATION object in the stateful message, it will return a PCErr message with Error-Type "Unknown Object" as described in [RFC5440]. In the case of a PCReq message, the PCE would react based on the P flag as per [RFC5440]. If a PCEP speaker understands the ASSOCIATION object but does not support the Association Type, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 1 "Association Type is not supported". If any association parameters are invalid in the ASSOCIATION object, the PCEP speaker would consider this object malformed and process it as a malformed message [RFC5440]. On receiving a PCEP message with an ASSOCIATION object, if a PCEP speaker finds that too many LSPs belong to the association group, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 2 "Too many LSPs in the association group". If a PCEP speaker cannot handle a new association, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 3 "Too many association groups". These numbers MAY be set by the operator or chosen based on a local policy.
PCEPスピーカーがステートフルメッセージ内のASSOCIATIONオブジェクトを認識しない場合、[RFC5440]で説明されているように、エラータイプが「不明なオブジェクト」のPCErrメッセージが返されます。 PCReqメッセージの場合、PCEは[RFC5440]のようにPフラグに基づいて反応します。 PCEPスピーカーがASSOCIATIONオブジェクトを理解してもアソシエーションタイプをサポートしていない場合は、エラータイプ26「アソシエーションエラー」およびエラー値1「アソシエーションタイプはサポートされていません」のPCErrメッセージを返す必要があります。 ASSOCIATIONオブジェクトで関連付けパラメーターが無効な場合、PCEPスピーカーはこのオブジェクトが不正な形式であると見なし、不正なメッセージ[RFC5440]として処理します。 ASSOCIATIONオブジェクトを含むPCEPメッセージを受信したときに、PCEPスピーカーが関連付けグループに属するLSPが多すぎる場合、エラータイプ26「関連付けエラー」とエラー値2「LSOが多すぎる」というPCErrメッセージを返す必要があります。関連グループ」。 PCEPスピーカーが新しい関連付けを処理できない場合は、エラータイプ26「関連付けエラー」とエラー値3「関連付けグループが多すぎます」を含むPCErrメッセージを返す必要があります。これらの番号は、オペレーターによって設定されるか、ローカルポリシーに基づいて選択される場合があります。
If a PCE peer is unwilling or unable to process the ASSOCIATION object in the stateful message, it MUST return a PCErr message with the Error-Type "Not supported object" and follow the relevant procedures described in [RFC5440]. In the case of a PCReq message, the PCE would react based on the P flag as per [RFC5440]. On receiving a PCEP message with an ASSOCIATION object, if a PCEP speaker could not add the LSP to the association group for any reason, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 7 "Cannot join the association group".
PCEピアがステートフルメッセージ内のASSOCIATIONオブジェクトを処理することを望まない、または処理できない場合は、エラータイプ「サポートされていないオブジェクト」を含むPCErrメッセージを返し、[RFC5440]で説明されている関連手順に従う必要があります。 PCReqメッセージの場合、PCEは[RFC5440]のようにPフラグに基づいて反応します。 ASSOCIATIONオブジェクトを含むPCEPメッセージを受信すると、PCEPスピーカーが何らかの理由で関連付けグループにLSPを追加できなかった場合、エラータイプ26「関連付けエラー」およびエラー値7「参加できないPCErrメッセージを返す必要があります関連グループ」。
If a PCEP speaker receives an ASSOCIATION object for an Operator-configured Association and the Association ID is not in the Operator-configured Association Range for the Association Type and Association Source, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 8 "Association ID not in range".
PCEPスピーカーがオペレーターが設定した関連付けのASSOCIATIONオブジェクトを受信し、関連付けIDが関連付けタイプと関連付けソースのオペレーターが設定した関連付け範囲にない場合、エラータイプ26「関連付けエラー」のPCErrメッセージを返す必要がありますエラー値8「関連付けIDが範囲内にありません」。
If a PCEP speaker receives an ASSOCIATION object in a PCReq message and the association is not known (the association is not configured, was not created dynamically, or was not learned from a PCEP peer), it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 4 "Association unknown".
PCEPスピーカーがPCReqメッセージでASSOCIATIONオブジェクトを受信し、関連付けが不明である場合（関連付けが構成されていない、動的に作成されていない、またはPCEPピアから学習されていない場合）、エラータイプのPCErrメッセージを返す必要があります26 "Association Error"およびエラー値4 "Association unknown"。
If the association information (related to the association group as a whole) received from the peer does not match the local operator-configured information, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 5 "Operator-configured association information mismatch". On receiving association information (related to the association group as a whole) that does not match the association information previously received about the same association from a peer, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 6 "Association information mismatch". Note that information related to each LSP within the association as part of the association information TLVs could be different.
ピアから受信した（アソシエーショングループ全体に関連する）アソシエーション情報がローカルのオペレーター構成情報と一致しない場合は、エラータイプ26「アソシエーションエラー」とエラー値5「オペレーターを含むPCErrメッセージを返さなければなりません（MUST）。 -構成された関連付け情報の不一致」。以前にピアから同じアソシエーションについて受信したアソシエーション情報と一致しないアソシエーション情報（アソシエーショングループ全体に関連）を受信すると、エラータイプ26「アソシエーションエラー」とエラー値を含むPCErrメッセージを返さなければなりません（MUST） 6 "関連付け情報の不一致"。アソシエーション情報TLVの一部としてアソシエーション内の各LSPに関連する情報は異なる場合があることに注意してください。
If a PCEP speaker receives an ASSOCIATION object with the R bit set for removal and the association group (identified by association parameters) is not known, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 4 "Association unknown".
PCEPスピーカーが削除用にRビットが設定されたASSOCIATIONオブジェクトを受信し、関連付けグループ（関連付けパラメーターで識別される）が不明の場合、エラータイプ26「関連付けエラー」およびエラー値4のPCErrメッセージを返す必要があります不明な関連付け」。
The dynamic associations are cleared along with the LSP state information as per [RFC8231]. When a PCEP session is terminated, after expiry of the State Timeout Interval at the PCC, the LSP state associated with that PCEP session is reverted to operator-defined default parameters or behaviors. The same procedure is also followed for the association groups. On session termination at the PCE, when the LSP state reported by the PCC is cleared, the association groups are also cleared. When there are no LSPs in an association group, the association is considered empty and thus deleted.
[RFC8231]に従って、ダイナミックアソシエーションはLSP状態情報とともにクリアされます。 PCEPセッションが終了すると、PCCで状態タイムアウト間隔が満了すると、そのPCEPセッションに関連付けられたLSP状態は、オペレーターが定義したデフォルトのパラメーターまたは動作に戻ります。同じ手順が関連グループにも適用されます。 PCEでのセッション終了時に、PCCによって報告されたLSP状態がクリアされると、アソシエーショングループもクリアされます。関連付けグループにLSPがない場合、関連付けは空と見なされ、削除されます。
If the LSP is delegated to another PCE on session failure, the associations (and association information) set by the PCE remain intact, unless updated by the new PCE that takes over.
セッション障害時にLSPが別のPCEに委任された場合、引き継ぐ新しいPCEによって更新されない限り、PCEによって設定された関連付け（および関連付け情報）はそのまま残ります。
Upon LSP delegation revocation, the PCC MAY clear the association created by the PCE, but in order to avoid traffic loss, it SHOULD perform this action in a make-before-break fashion (same as [RFC8231]).
LSP委任の取り消し時に、PCCはPCEによって作成された関連付けをクリアできますが、トラフィックの損失を回避するために、このアクションをmake-before-break方式で実行する必要があります（[RFC8231]と同じ）。
IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" registry at <https://www.iana.org/assignments/pcep>.
IANAでは、<https://www.iana.org/assignments/pcep>に「Path Computation Element Protocol（PCEP）Numbers」レジストリを保持しています。
The "Path Computation Element Protocol (PCEP) Numbers" registry contains a subregistry called "PCEP Objects". IANA has allocated the following code point in the "PCEP Objects" registry.
「パス計算要素プロトコル（PCEP）番号」レジストリには、「PCEPオブジェクト」と呼ばれるサブレジストリが含まれています。 IANAは、「PCEPオブジェクト」レジストリに次のコードポイントを割り当てました。
+--------------------+-------------+-------------+-----------+
| Object-Class Value | Name | Object-Type | Reference |
+====================+=============+=============+===========+
| 40 | ASSOCIATION | 0: Reserved | RFC 8697 |
| | +-------------+-----------+
| | | 1: IPv4 | RFC 8697 |
| | +-------------+-----------+
| | | 2: IPv6 | RFC 8697 |
+--------------------+-------------+-------------+-----------+
Table 1: PCEP Object
表1：PCEPオブジェクト
IANA has allocated the following code points in the "PCEP TLV Type Indicators" registry.
IANAは、「PCEP TLV Type Indicators」レジストリに次のコードポイントを割り当てました。
+-------+---------------------------------------+-----------+
| Value | Meaning | Reference |
+=======+=======================================+===========+
| 29 | Operator-configured Association Range | RFC 8697 |
+-------+---------------------------------------+-----------+
| 30 | Global Association Source | RFC 8697 |
+-------+---------------------------------------+-----------+
| 31 | Extended Association ID | RFC 8697 |
+-------+---------------------------------------+-----------+
Table 2: PCEP TLV Type Indicators
表2：PCEP TLVタイプインジケーター
IANA has corrected the capitalization in the meaning for value 31 in the above registry to "Extended Association ID"; it was previously listed as "Extended Association Id".
IANAは、上記のレジストリの値31の意味での大文字の使用を「Extended Association ID」に修正しました。以前は「Extended Association Id」としてリストされていました。
IANA has made a new assignment in the existing "PCEP TLV Type Indicators" registry as follows:
IANAは、既存の「PCEP TLV Type Indicators」レジストリに次のように新しい割り当てを行いました。
+-------+-----------------+-----------+
| Value | Meaning | Reference |
+=======+=================+===========+
| 35 | ASSOC-Type-List | RFC 8697 |
+-------+-----------------+-----------+
Table 3: ASSOC-Type-List PCEP TLV Type Indicator
表3：ASSOCタイプリストPCEP TLVタイプインジケーター
Per this document, IANA has created a subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry for the bits carried in the Flags field of the ASSOCIATION object. The subregistry is called "ASSOCIATION Flag Field". New values are assigned by Standards Action [RFC8126]. Each bit is tracked with the following qualities:
このドキュメントに従って、IANAは、ASSOCIATIONオブジェクトのFlagsフィールドで伝送されるビット用に、「Path Computation Element Protocol（PCEP）Numbers」レジストリのサブレジストリを作成しました。サブレジストリは「ASSOCIATIONフラグフィールド」と呼ばれます。新しい値は、標準アクション[RFC8126]によって割り当てられます。各ビットは次の品質で追跡されます。
* Bit number (counting from bit 0 as the most significant bit)
* ビット番号（ビット0を最上位ビットとして数えます）
* Capability description
* 機能の説明
* Defining RFC
* RFCの定義
+-----+-------------+-----------+
| Bit | Description | Reference |
+=====+=============+===========+
| 15 | R (Removal) | RFC 8697 |
+-----+-------------+-----------+
Table 4: New ASSOCIATION Flag Field
表4：新しいASSOCIATIONフラグフィールド
Per this document, IANA has created a subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry for the Association Type field of the ASSOCIATION object. The subregistry is called "ASSOCIATION Type Field". New values are assigned by Standards Action [RFC8126]. Each value is tracked with the following qualities:
このドキュメントに従って、IANAは、ASSOCIATIONオブジェクトのAssociation Typeフィールドに「Path Computation Element Protocol（PCEP）Numbers」レジストリのサブレジストリを作成しました。サブレジストリは「ASSOCIATION Type Field」と呼ばれます。新しい値は、標準アクション[RFC8126]によって割り当てられます。各値は、次の品質で追跡されます。
* Type
* タイプ
* Name
* 名前
* Reference
* 参照
+------+----------+-----------+
| Type | Name | Reference |
+======+==========+===========+
| 0 | Reserved | RFC 8697 |
+------+----------+-----------+
Table 5: New ASSOCIATION Type Field
表5：新しいASSOCIATIONタイプフィールド
Values 2-65535 are Unassigned. Future documents should request the assignment of Association Types from this subregistry.
値2〜65535は割り当てられていません。今後のドキュメントでは、このサブレジストリから関連タイプの割り当てを要求する必要があります。
IANA has allocated the following code points within the "PCEP-ERROR Object Error Types and Values" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry as follows:
IANAは、「パス計算エレメントプロトコル（PCEP）番号」レジストリの「PCEP-ERRORオブジェクトエラータイプと値」サブレジストリ内に次のコードポイントを次のように割り当てました。
+------------+-------------+------------------------+-----------+
| Error-Type | Meaning | Error-value | Reference |
+============+=============+========================+===========+
| 26 | Association | 0: Unassigned | RFC 8697 |
| | Error +------------------------+-----------+
| | | 1: Association Type is | RFC 8697 |
| | | not supported | |
| | +------------------------+-----------+
| | | 2: Too many LSPs in | RFC 8697 |
| | | the association group | |
| | +------------------------+-----------+
| | | 3: Too many | RFC 8697 |
| | | association groups | |
| | +------------------------+-----------+
| | | 4: Association unknown | RFC 8697 |
| | +------------------------+-----------+
| | | 5: Operator-configured | RFC 8697 |
| | | association | |
| | | information mismatch | |
| | +------------------------+-----------+
| | | 6: Association | RFC 8697 |
| | | information mismatch | |
| | +------------------------+-----------+
| | | 7: Cannot join the | RFC 8697 |
| | | association group | |
| | +------------------------+-----------+
| | | 8: Association ID not | RFC 8697 |
| | | in range | |
+------------+-------------+------------------------+-----------+
Table 6: PCEP-ERROR Types and Names
表6：PCEP-ERRORのタイプと名前
The security considerations described in [RFC8231] and [RFC5440] apply to the extensions described in this document as well. Additional considerations related to a malicious PCEP speaker are introduced, as associations could be spoofed and could be used as an attack vector. An attacker could attempt to create too many associations in an attempt to load the PCEP peer. The PCEP peer responds with a PCErr message as described in Section 6.4. An attacker could impact LSP operations by creating bogus associations. Further, association groups could provide an adversary with the opportunity to eavesdrop on the relationship between the LSPs. Thus, securing the PCEP session using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in [RFC7525], is RECOMMENDED.
[RFC8231]および[RFC5440]で説明されているセキュリティの考慮事項は、このドキュメントで説明されている拡張機能にも適用されます。アソシエーションがスプーフィングされ、攻撃ベクトルとして使用される可能性があるため、悪意のあるPCEPスピーカーに関する追加の考慮事項が導入されています。攻撃者は、PCEPピアを読み込もうとして、非常に多くのアソシエーションを作成しようとする可能性があります。 PCEPピアは、セクション6.4で説明されているPCErrメッセージで応答します。攻撃者は偽のアソシエーションを作成することにより、LSP操作に影響を与える可能性があります。さらに、関連グループは、LSP間の関係を盗聴する機会を敵に提供する可能性があります。したがって、トランスポート層セキュリティ（TLS）[RFC8253]を使用してPCEPセッションを保護することは、[RFC7525]の推奨事項と現在のベストプラクティスに従って、推奨されます。
Much of the information carried in the ASSOCIATION object as per this document is not extra sensitive. It often reflects information that can also be derived from the LSP database, but the association provides a much easier grouping of related LSPs and messages. Implementations and operators can, and should, use indirect values in the ASSOCIATION object as a way to hide any sensitive business relationships.
このドキュメントのように、ASSOCIATIONオブジェクトに含まれる情報の多くは、それほど機密性が高くありません。多くの場合、LSPデータベースから取得できる情報も反映されますが、関連付けにより、関連するLSPとメッセージをはるかに簡単にグループ化できます。実装とオペレーターは、機密のビジネス関係を隠す方法として、ASSOCIATIONオブジェクトの間接値を使用できます。
All manageability requirements and considerations listed in [RFC5440] and [RFC8231] apply to PCEP protocol extensions defined in this document. In addition, requirements and considerations listed in this section apply.
[RFC5440]と[RFC8231]にリストされているすべての管理要件と考慮事項は、このドキュメントで定義されているPCEPプロトコル拡張に適用されます。さらに、このセクションにリストされている要件と考慮事項が適用されます。
A PCE or PCC implementation MUST allow Operator-configured Associations and SHOULD allow the setting of the Operator-configured Association Range (Section 3.4) as described in this document.
PCEまたはPCCの実装では、オペレーターが設定した関連付けを許可する必要があり、このドキュメントで説明されているように、オペレーターが設定した関連付けの範囲（セクション3.4）の設定を許可する必要があります（SHOULD）。
The PCEP YANG module is defined in [PCEP-YANG]. In the future, this YANG module should be extended or augmented to provide the following additional information related to association groups.
PCEP YANGモジュールは[PCEP-YANG]で定義されています。将来的には、このYANGモジュールを拡張または拡張して、関連グループに関連する以下の追加情報を提供する必要があります。
An implementation SHOULD allow the operator to view the associations configured or created dynamically. Future implementations SHOULD allow the viewing of associations reported by each peer and the current set of LSPs in the association.
実装は、オペレーターが動的に構成または作成された関連付けを表示できるようにする必要があります（SHOULD）。将来の実装では、各ピアから報告されたアソシエーションと、アソシエーション内の現在のLSPセットを表示できるようにする必要があります（SHOULD）。
It might also be useful to find out how many associations for each Association Type currently exist and to know how many free Association IDs are available for a particular Association Type and source.
また、現在存在している各アソシエーションタイプのアソシエーションの数を調べ、特定のアソシエーションタイプとソースで使用可能な無料のアソシエーションIDの数を知ることも役立つ場合があります。
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].
このドキュメントで定義されているメカニズムは、[RFC5440]にすでにリストされているものに加えて、新しい活性検出および監視の要件を意味するものではありません。
Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440] and [RFC8231].
このドキュメントで定義されているメカニズムは、[RFC5440]と[RFC8231]にすでにリストされているメカニズムに加えて、新しい動作検証要件を意味するものではありません。
Mechanisms defined in this document do not imply any new requirements on other protocols.
このドキュメントで定義されているメカニズムは、他のプロトコルに対する新しい要件を意味するものではありません。
Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP extensions defined in this document.
[RFC5440]と[RFC8231]で定義されているメカニズムは、このドキュメントで定義されているPCEP拡張にも適用されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5440] Vasseur、JP。、Ed。とJL。 Le Roux編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<https://www.rfc-editor.org/info/rfc5440>。
[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, <https://www.rfc-editor.org/info/rfc5511>.
[RFC5511] Farrel、A。、「Routing Backus-Naur Form（RBNF）：A Syntax Rules to Form Encoding Rules in Various Routing Protocol Specifications」、RFC 5511、DOI 10.17487 / RFC5511、2009年4月、<https：// 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, <https://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月、<https://www.rfc-editor.org/ info / rfc6780>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<https://www.rfc-editor.org/info/rfc7525>。
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, <https://www.rfc-editor.org/info/rfc8051>.
[RFC8051]張、X。、エド。 I. Minei、編、「ステートフルパス計算エレメント（PCE）の適用性」、RFC 8051、DOI 10.17487 / RFC8051、2017年1月、<https://www.rfc-editor.org/info/rfc8051>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/info/rfc8231>.
[RFC8231] Crabbe、E.、Minei、I.、Medved、J。、およびR. Varga、「Pathful Computation Element Communication Protocol（PCEP）Extensions for Stateful PCE」、RFC 8231、DOI 10.17487 / RFC8231、2017年9月、< https://www.rfc-editor.org/info/rfc8231>。
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, <https://www.rfc-editor.org/info/rfc8281>.
[RFC8281] Crabbe、E.、Minei、I.、Sivabalan、S。、およびR. Varga、「ステートフルPCEモデルでのPCEによって開始されるLSPセットアップのパス計算要素通信プロトコル（PCEP）拡張」、RFC 8281、DOI 10.17487 / RFC8281、2017年12月、<https://www.rfc-editor.org/info/rfc8281>。
[RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC4657] Ash、J.、Ed。およびJ.L. Le Roux、Ed。、「Path Computation Element（PCE）Communication Protocol Generic Requirements」、RFC 4657、DOI 10.17487 / RFC4657、2006年9月、<https://www.rfc-editor.org/info/rfc4657>。
[RFC4872] Lang, J.P., 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, <https://www.rfc-editor.org/info/rfc4872>.
[RFC4872] Lang、JP、編、Rekhter、Y、編、D。Papadimitriou、編、「エンドツーエンドの汎用マルチプロトコルラベルスイッチング（GMPLS）リカバリをサポートするRSVP-TE拡張機能」 、RFC 4872、DOI 10.17487 / RFC4872、2007年5月、<https://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, <https://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月、<https：//www.rfc-editor .org / info / rfc4873>。
[RFC6007] Nishioka, I. and D. King, "Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations", RFC 6007, DOI 10.17487/RFC6007, September 2010, <https://www.rfc-editor.org/info/rfc6007>.
[RFC6007] Nishioka、I. and D. King、 "Use of the Synchronization VECtor（SVEC）List for Synchronized Dependent Path Computations"、RFC 6007、DOI 10.17487 / RFC6007、September 2010、<https：//www.rfc-editor .org / info / rfc6007>。
[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, <https://www.rfc-editor.org/info/rfc7551>.
[RFC7551] Zhang、F。、編、Jing、R。、およびR. Gandhi、編、「RSVP-TE Extensions for Associated Bidirectional Label Switched Paths（LSPs）」、RFC 7551、DOI 10.17487 / RFC7551、2015年5月、<https://www.rfc-editor.org/info/rfc7551>。
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, <https://www.rfc-editor.org/info/rfc8253>.
[RFC8253] Lopez、D.、Gonzalez de Dios、O.、Wu、Q。、およびD. Dhody、「PCEPS：TLSの使用によるパス計算要素通信プロトコル（PCEP）のセキュアなトランスポートの提供」、RFC 8253 、DOI 10.17487 / RFC8253、2017年10月、<https://www.rfc-editor.org/info/rfc8253>。
[PCEP-YANG] Dhody, D., Ed., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, Internet-Draft, draft-ietf-pce-pcep-yang-13, 31 October 2019, <https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13>.
[PCEP-YANG] Dhody、D.、Ed。、Hardwick、J.、Beeram、V.、J。Tantsura、「パス計算要素通信プロトコル（PCEP）のYANGデータモデル」、作業中、インターネット- Draft、draft-ietf-pce-pcep-yang-13、2019年10月31日、<https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13>。
[PCE-PROTECTION] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I., and M. Negi, "PCEP Extensions for Associating Working and Protection LSPs with Stateful PCE", Work in Progress, Internet-Draft, draft-ietf-pce-stateful-path-protection-11, 25 September 2019, <https://tools.ietf.org/html/draft-ietf-pce-stateful-path-protection-11>.
[PCE保護] Ananthakrishnan、H.、Sivabalan、S.、Barth、C.、Minei、I。、およびM. Negi、「作業および保護LSPとステートフルPCEを関連付けるためのPCEP拡張機能」、Work in Progress、インターネットDraft、draft-ietf-pce-stateful-path-protection-11、2019年9月25日、<https://tools.ietf.org/html/draft-ietf-pce-stateful-path-protection-11>。
[PCE-DIVERSITY] Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, "Path Computation Element Communication Protocol (PCEP) Extension for LSP Diversity Constraint Signaling", Work in Progress, Internet-Draft, draft-ietf-pce-association-diversity-14, 26 January 2020, <https://tools.ietf.org/html/draft-ietf-pce-association-diversity-14>.
[PCE-DIVERSITY] Litkowski、S.、Sivabalan、S.、Barth、C。、およびM. Negi、「LSP Diversity Constraint SignalingのPath Computation Element Communication Protocol（PCEP）Extension」、Work in Progress、Internet-Draft、 draft-ietf-pce-association-diversity-14、2020年1月26日、<https://tools.ietf.org/html/draft-ietf-pce-association-diversity-14>。
Consider an Association Type T1 (which allows both dynamic and Operator-configured Associations with a default range of <0x1000, 0xffff>). Consider that, because of the needs of the network, the PCE needs to create more dynamic associations and would like to change the Association Range to <0xbffe, 0xffff> instead. During PCEP session establishment, the PCE would advertise the new range. The PCC could skip advertising, as the default values are used. If a PCC is creating a dynamic association (with the PCC as the Association Source), it needs to pick a free Association ID for type T1 in the range <0x1, 0x0fff>, whereas if a PCE is creating a dynamic association (with the PCE as the Association Source), it needs to pick a free Association ID from the range <0x1, 0xbffd>. Similarly, if an Operator-configured Association is manually configured with the PCC as the Association Source, it should be from the range <0x1000, 0xffff>, whereas if the PCE is the Association Source, it should be from the range <0xbffe, 0xffff>. If the Association Source is not a PCEP peer (for example, an NMS), then the default range of <0x1000, 0xffff> is considered.
アソシエーションタイプT1を検討してください（デフォルトの範囲が<0x1000、0xffff>の動的アソシエーションとオペレーター構成アソシエーションの両方を許可します）。 PCEはネットワークのニーズのために、より動的な関連付けを作成する必要があり、代わりにAssociation Rangeを<0xbffe、0xffff>に変更したいと考えています。 PCEPセッションの確立中に、PCEは新しい範囲をアドバタイズします。デフォルト値が使用されているため、PCCは広告をスキップできます。 PCCが（PCCをアソシエーションソースとして）動的アソシエーションを作成している場合は、<0x1、0x0fff>の範囲でタイプT1の無料のアソシエーションIDを選択する必要があります。アソシエーションソースとしてのPCE）では、<0x1、0xbffd>の範囲から無料のアソシエーションIDを選択する必要があります。同様に、オペレーター設定の関連付けがPCCを関連付けソースとして手動で設定されている場合は、<0x1000、0xffff>の範囲からである必要があります。一方、PCEが関連付けソースの場合は、範囲<0xbffe、0xffffからのものである必要があります。 >。アソシエーションソースがPCEPピア（たとえば、NMS）ではない場合、デフォルト範囲の<0x1000、0xffff>が考慮されます。
Acknowledgments
謝辞
We would like to thank Yuji Kamite and Joshua George for their contributions to this document. Thanks also to Venugopal Reddy, Cyril Margaria, Rakesh Gandhi, Mike Koldychev, and Adrian Farrel for their useful comments.
このドキュメントへの貢献に対して、神手裕二氏とジョージジョシュアジョージ氏に感謝します。 Venugopal Reddy、Cyril Margaria、Rakesh Gandhi、Mike Koldychev、およびAdrian Farrelの有益なコメントにも感謝します。
We would like to thank Julien Meuric for shepherding this document and providing comments with text suggestions.
このドキュメントを提出し、コメントをテキストで提供してくれたJulien Meuricに感謝します。
Thanks to Stig Venaas for the RTGDIR review comments.
RTGDIRレビューコメントについてStig Venaasに感謝します。
Thanks to Alvaro Retana, Mirja Kühlewind, Martin Vigoureux, Barry Leiba, Eric Vyncke, Suresh Krishnan, and Benjamin Kaduk for the IESG comments.
IESGのコメントを提供してくれたAlvaro Retana、MirjaKühlewind、Martin Vigoureux、Barry Leiba、Eric Vyncke、Suresh Krishnan、Benjamin Kadukに感謝します。
Contributors
貢献者
Stephane Litkowski Orange
ステファンリトコウスキーオレンジ
Email: stephane.litkowski@orange.com
Xian Zhang Huawei Technologies F3-1-B RnD Center, Huawei Base Bantian, Longgang District Shenzhen, 518129 China
X Ian Zhang hu AはテクノロジーF3-1-br NDセンター、hu Aは基本禁止日、長いギャング地区は非常に現実的、518129中国
Email: zhang.xian@huawei.com
Mustapha Aissaoui Nokia
ムスタファイサウィノキア
Email: mustapha.aissaoui@nokia.com
Authors' Addresses
著者のアドレス
Ina Minei Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Ina Minei Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Email: inaminei@google.com
Edward Crabbe Individual Contributor
Edward Crabbe個人貢献者
Email: edward.crabbe@gmail.com
Siva Sivabalan Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 United States of America
Siva Sivabalan Cisco Systems、Inc. 170 West Tasman Dr. San Jose、CA 95134アメリカ合衆国
Email: msiva@cisco.com
Hariharan Ananthakrishnan Netflix
ハリハラ・アナンタクリシュナン・ネットフリックス
Email: hari@netflix.com
Dhruv Dhody Huawei Divyashree Techno Park, Whitefield Bangalore 560066 KA India
Dhruv Dhoday Huawei Divyashree Techno Park、Whitefield Bangalore 56006 Kaインド
Email: dhruv.ietf@gmail.com
Yosuke Tanaka NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku, Tokyo 108-8118 Japan
よすけ たなか んっｔ こっむにかちおんｓ こｒぽらちおん Ｇらんぱｒｋ とうぇｒ ３ー４ー１ しばうら、 みなとーく、 ときょ １０８ー８１１８ じゃぱん
Email: yosuke.tanaka@ntt.com