[要約] RFC 8800は、異なる経路制約をシグナリングするためのPath Computation Element Communication Protocol（PCEP）拡張です。このRFCの目的は、ラベルスイッチパス（LSP）の多様性制約をサポートし、ネットワークリソースの最適な利用を可能にすることです。
Internet Engineering Task Force (IETF) S. Litkowski
Request for Comments: 8800 Cisco Systems, Inc.
Category: Standards Track S. Sivabalan
ISSN: 2070-1721 Ciena Corporation
C. Barth
Juniper Networks
M. Negi
RtBrick India
July 2020
Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling
ラベルスイッチドパス（LSP）の多様性制約シグナリング用のパス計算要素通信プロトコル（PCEP）拡張
Abstract
概要
This document introduces a simple mechanism to associate a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element Communication Protocol (PCEP) with the purpose of computing diverse (disjointed) paths for those LSPs. The proposed extension allows a Path Computation Client (PCC) to advertise to a Path Computation Element (PCE) that a particular LSP belongs to a particular Disjoint Association Group; thus, the PCE knows that the LSPs in the same group need to be disjoint from each other.
このドキュメントでは、パス計算要素通信プロトコル（PCEP）の拡張機能を介して、ラベルスイッチドパス（LSP）のグループを、それらのLSPの多様な（ばらばらな）パスを計算する目的で関連付ける簡単なメカニズムを紹介します。提案された拡張機能により、パス計算クライアント（PCC）は、特定のLSPが特定のDisjoint Association Groupに属することをパス計算要素（PCE）に通知できます。したがって、PCEは、同じグループ内のLSPを互いに切り離す必要があることを認識しています。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。これは公開レビューを受けており、Internet Engineering Steering Group（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/rfc8800.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8800で入手できます。
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. Motivation 4. Applicability 5. Protocol Extension 5.1. Association Group 5.2. Disjoint TLVs 5.3. Disjointness Objective Functions 5.4. Relationship to SVEC 5.4.1. SVEC and OF 5.5. P Flag Considerations 5.6. Disjointness Computation Issues 6. Security Considerations 7. IANA Considerations 7.1. Association Type 7.2. PCEP TLVs 7.3. Objective Functions 7.4. NO-PATH-VECTOR Bit Flags 7.5. PCEP-ERROR Codes 8. Manageability Considerations 8.1. Control of Function and Policy 8.2. Information and Data Models 8.3. Liveness Detection and Monitoring 8.4. Verification of Correct Operations 8.5. Requirements on Other Protocols 8.6. Impact on Network Operations 9. References 9.1. Normative References 9.2. Informative References Acknowledgments Contributors Authors' Addresses
1. はじめに1.1。要件言語2.用語3.動機4.適用性5.プロトコル拡張5.1。協会グループ5.2。ディスジョイントTLV 5.3。素性の目的関数5.4。 SVEC 5.4.1との関係。 SVECおよびOF 5.5。 Pフラグに関する考慮事項5.6。素の計算の問題6.セキュリティの考慮事項7. IANAの考慮事項7.1。関連タイプ7.2。 PCEP TLV 7.3。目的関数7.4。 NO-PATH-VECTORビットフラグ7.5。 PCEP-ERRORコード8.管理性に関する考慮事項8.1。機能とポリシーの制御8.2。情報とデータモデル8.3。活性検出と監視8.4。正しい操作の確認8.5。その他のプロトコルの要件8.6。ネットワーク運用への影響9.参考資料9.1。規範的な参考文献9.2。有益な参考文献謝辞寄稿者著者のアドレス
[RFC5440] describes the Path Computation Element Communication Protocol (PCEP), which enables the communication between a Path Computation Client (PCC) and a Path Control Element (PCE) or between two PCEs based on the PCE architecture [RFC4655].
[RFC5440]は、パス計算クライアント（PCC）とパス制御要素（PCE）の間、またはPCEアーキテクチャ[RFC4655]に基づく2つのPCE間の通信を可能にするパス計算要素通信プロトコル（PCEP）について説明しています。
The PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of extensions to PCEP to enable active control of MPLS-TE and GMPLS tunnels. [RFC8281] describes the setup and teardown of PCE-initiated LSPs under the active stateful PCE model, without the need for local configuration on the PCC, thus allowing for a dynamic network.
ステートフルPCEモデルのPCEP拡張[RFC8231]は、MPLS-TEおよびGMPLSトンネルのアクティブ制御を可能にするPCEPへの一連の拡張について説明しています。 [RFC8281]は、PCCでのローカル構成を必要とせず、動的なネットワークを可能にする、アクティブなステートフルPCEモデルでのPCEによって開始されたLSPのセットアップとティアダウンについて説明しています。
[RFC8697] introduces a generic mechanism to create a grouping of LSPs in the context of a PCE that can then be used to define associations between a set of LSPs and a set of attributes (such as configuration parameters or behaviors) and is equally applicable to the active and passive modes of a stateful PCE [RFC8231] or a stateless PCE [RFC4655].
[RFC8697]は、PCEのコンテキストでLSPのグループを作成する一般的なメカニズムを導入します。これを使用して、LSPのセットと属性のセット（構成パラメーターや動作など）の間の関連付けを定義し、同等に適用できます。ステートフルPCE [RFC8231]またはステートレスPCE [RFC4655]のアクティブモードとパッシブモード。
This document specifies a PCEP extension to signal that a set of LSPs in a particular group should use diverse (disjointed) paths, including the requested type of diversity. Sections 3 and 4 describe the property and use of a Disjoint Association Group. A PCC can use this extension to signal to a PCE that a particular LSP belongs to a particular Disjoint Association Group. When a PCE receives LSP states belonging to the same Disjoint Association Group from some PCCs, the PCE should ensure that the LSPs within the group are disjoint from each other.
このドキュメントでは、特定のグループの一連のLSPが、要求された種類の多様性を含む多様な（ばらばらの）パスを使用する必要があることを通知するPCEP拡張を指定します。セクション3と4では、Disjoint Association Groupの特性と使用法について説明します。 PCCはこの拡張を使用して、特定のLSPが特定のDisjoint Association Groupに属していることをPCEに通知できます。 PCEが一部のPCCから同じディスジョイントアソシエーショングループに属するLSP状態を受信した場合、PCEはグループ内のLSPが互いにディスジョイントであることを確認する必要があります。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The following terminology is used in this document.
このドキュメントでは、次の用語が使用されています。
DAT: Disjoint Association Type
DAT：Disjoint Association Type
DAG: Disjoint Association Group
DAY：ディスジョイントアソシエーショングループ
MPLS: Multiprotocol Label Switching
MPLS：マルチプロトコルラベルスイッチング
OF: Objective Function
OF：目的関数
PCC: Path Computation Client. Any client application requesting a path computation to be performed by a Path Computation Element.
PCC：パス計算クライアント。パス計算要素によって実行されるパス計算を要求するクライアントアプリケーション。
PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
PCE：パス計算要素。ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用できるエンティティ（コンポーネント、アプリケーション、またはネットワークノード）。
PCEP: Path Computation Element Communication Protocol
PCEP：パス計算要素通信プロトコル
PLSP-ID: PCEP-specific identifier for the LSP
PLSP-ID：LSPのPCEP固有の識別子
SRLG: Shared Risk Link Group
SRLG：共有リスクリンクグループ
Path diversity is a very common use case in today's IP/MPLS networks, especially for layer 2 transport over MPLS. A customer may request that the operator provide two end-to-end disjoint paths across the operator's IP/MPLS core. The customer may use these paths as primary/backup or active/active configuration.
パスダイバーシティは、今日のIP / MPLSネットワークで非常に一般的な使用例であり、特にMPLSを介したレイヤ2トランスポートの場合です。顧客は、オペレーターに、オペレーターのIP / MPLSコア全体に2つのエンドツーエンドのばらばらのパスを提供するよう要求することができます。お客様はこれらのパスをプライマリ/バックアップまたはアクティブ/アクティブ構成として使用できます。
Different levels of disjointness may be offered:
さまざまなレベルのバラバラさが提供される場合があります。
* Link disjointness: the paths of the associated LSPs should transit different links (but may use common nodes or different links that may have some shared fate).
* リンクの不整合：関連付けられたLSPのパスは異なるリンクを通過する必要があります（ただし、共通のノードまたは共有された運命を持つ可能性のある異なるリンクを使用する場合があります）
* Node disjointness: the paths of the associated LSPs should transit different nodes (but may use different links that may have some shared fate).
* ノードの素性：関連するLSPのパスは異なるノードを通過する必要があります（ただし、共有された運命を持つ可能性のある異なるリンクを使用する場合があります）。
* SRLG disjointness: the paths of the associated LSPs should transit different links that do not share fate (but may use common transit nodes).
* SRLGの不整合：関連するLSPのパスは、運命を共有しない異なるリンクを通過する必要があります（ただし、共通の通過ノードを使用する場合があります）。
* Node+SRLG disjointness: the paths of the associated LSPs should transit different links that do not have any common shared fate and should transit different nodes.
* ノード+ SRLGの不整合：関連するLSPのパスは、共通の共有運命を持たない異なるリンクを通過し、異なるノードを通過する必要があります。
The associated LSPs may originate from the same or different head end(s) and may terminate at the same or different tail end(s).
関連付けられたLSPは、同じまたは異なるヘッドエンドから発生し、同じまたは異なるテールエンドで終了する場合があります。
_________________________________________
/ \
/ +------+ \
| | PCE | |
| +------+ |
| |
| ***********************> |
| +------+ 10 +------+ |
CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2
| +------+ | | +------+ |
| | | |
| | | |
| +------+ | | +------+ |
CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4
| +------+ ***********************> +------+ |
| |
\ /
\_________________________________________/
Figure 1: Disjoint Paths with Different Head Ends and Tail Ends
図1：異なるヘッドエンドとテールエンドを持つばらばらのパス
In the figure above, let us consider that the customer wants to have two disjoint paths, one between CE1 and CE2 and one between CE3 and CE4. From an IP/MPLS network point view, in this example, the CEs are connected to different PEs to maximize their disjointness. When LSPs originate from different head ends, distributed computation of diverse paths can be difficult, whereas computation via a centralized PCE ensures path disjointness, correctness, and simplicity.
上の図で、カスタマーが2つのばらばらのパスを持ちたいと考えているとします。この例では、IP / MPLSネットワークポイントビューから、CEを異なるPEに接続して、それらの不整合を最大化します。 LSPが異なるヘッドエンドから発信された場合、多様なパスの分散計算は困難になる可能性がありますが、集中型PCEによる計算では、パスの素性、正確性、および単純さが保証されます。
Section 5.4 describes the relationship between the Disjoint Association Group (DAG) and Synchronization VECtor (SVEC) object.
セクション5.4では、Disjoint Association Group（DAG）とSynchronization VECtor（SVEC）オブジェクトの関係について説明します。
The PCEP extension for stateful PCE [RFC8231] defined new PCEP messages -- Path Computation Report (PCRpt), Path Computation Update (PCUpd), and Path Computation Initiate (PCInitiate) [RFC8281]. These messages use a PLSP-ID in the LSP object for identification. Moreover, to allow diversity between LSPs originating from different PCCs, the generic mechanism to create a grouping of LSPs that is equally applicable to the active and passive modes of a stateful PCE is described in [RFC8697].
ステートフルPCE [RFC8231]のPCEP拡張は、新しいPCEPメッセージを定義しました-パス計算レポート（PCRpt）、パス計算更新（PCUpd）、およびパス計算開始（PCInitiate）[RFC8281]。これらのメッセージは、LSPオブジェクトのPLSP-IDを使用して識別します。さらに、異なるPCCから発信されたLSP間の多様性を可能にするために、ステートフルPCEのアクティブモードとパッシブモードに等しく適用できるLSPのグループを作成する一般的なメカニズムが[RFC8697]で説明されています。
Using the extension to PCEP defined in this document, the PCC uses the extension defined in [RFC8697] to indicate that a group of LSPs are required to be disjoint; such indication should include disjointness parameters like the type of disjointness, the Disjoint Association Group identifiers, and any customization parameters according to the configured local policy.
PCCは、このドキュメントで定義されているPCEPの拡張を使用して、[RFC8697]で定義されている拡張を使用して、LSPのグループを分離する必要があることを示します。このような表示には、不整合のタイプ、不整合アソシエーショングループ識別子、構成されたローカルポリシーに基づくカスタマイズパラメータなどの不整合パラメータを含める必要があります。
The management of the Disjoint Association Group IDs will be a key point for the operator as the Association ID field is limited to 65535. The local configuration of the IPv4/IPv6 Association Source, or Global Association Source/Extended Association ID, can overcome this limitation, as described in [RFC8697]. When a PCC or PCE initiates all the LSPs in a particular Disjoint Association Group, it can set the IPv4/IPv6 Association Source as one of its own IP address. When disjoint LSPs are initiated from different head ends, the Association Source could be the PCE address or any other unique value to identify the DAG.
アソシエーションIDフィールドは65535に制限されているため、Disjoint Association Group IDの管理はオペレーターにとって重要なポイントになります。IPv4/ IPv6アソシエーションソース、またはグローバルアソシエーションソース/拡張アソシエーションIDのローカル構成は、この制限を克服できます。 [RFC8697]で説明されているように。 PCCまたはPCEが特定のディスジョイントアソシエーショングループ内のすべてのLSPを開始すると、IPv4 / IPv6アソシエーションソースを独自のIPアドレスの1つとして設定できます。ディスジョイントLSPが異なるヘッドエンドから開始される場合、関連付けソースは、DAEを識別するためのPCEアドレスまたは他の一意の値になる可能性があります。
Initiate Disjoint LSPs
|
| PCReq/PCRpt
V {DAG Y}
+-----+ ----------------> +-----+
_ _ _ _ _ _| PCE | | | PCE |
| +-----+ | ----------> +-----+
| PCInitiate | | PCReq/PCRpt
|{DAG X} | | {DAG Y}
| | |
| .-----. | | .-----.
| ( ) | +-----+ ( )
| .--( )--. | |PCC 2|--.--( )--.
V ( ) | +-----+ ( )
+---+ ( ) | ( )
|PCC|----( (G)MPLS network ) +-----+ ( (G)MPLS network )
+---+ ( ) |PCC 1|-----( )
{DAG X} ( ) +-----+ ( )
'--( )--' ( )--'
( ) ( )
'-----' '-----'
Case 1: Disjointness initiated by Case 2: Disjointness initiated by PCE and enforced by PCC PCC and enforced by PCE
ケース1：ケース2によって開始された不整合：PCEによって開始され、PCCによって実施され、PCEによって実施される不整合
Figure 2: Sample Use Cases for Carrying Disjoint Association Group over PCEP Session
図2：PCEPセッションでのばらばらのアソシエーショングループの実行の使用例
The Disjoint Association Group within a PCEP messages is used for:
PCEPメッセージ内のDisjoint Association Groupは、次の目的で使用されます。
* Configuration: Used to communicate the configured disjoint requirement to a PCEP peer.
* 構成：構成済みのばらばらの要件をPCEPピアに通信するために使用されます。
* Status: Used to communicate the status of the computed disjointness.
* ステータス：計算されたバラバラのステータスを伝えるために使用されます。
As per [RFC8697], LSPs are associated with other LSPs with which they interact by adding them to a common association group. As described in [RFC8697], the association group is uniquely identified by the combination of the following fields in the ASSOCIATION object: Association Type, Association ID, Association Source, and (if present) Global Association Source or Extended Association ID.
[RFC8697]によると、LSPは、共通の関連付けグループに追加することにより、相互作用する他のLSPに関連付けられます。 [RFC8697]で説明されているように、アソシエーショングループは、ASSOCIATIONオブジェクトの次のフィールドの組み合わせによって一意に識別されます：アソシエーションタイプ、アソシエーションID、アソシエーションソース、および（存在する場合は）グローバルアソシエーションソースまたは拡張アソシエーションID。
This document defines a new Association type, called "Disjoint Association" (2), based on the generic ASSOCIATION object. This new Association type is also called "DAT", for "Disjoint Association Type".
このドキュメントは、一般的なASSOCIATIONオブジェクトに基づいて、 "Disjoint Association"（2）と呼ばれる新しいAssociationタイプを定義します。この新しいアソシエーションタイプは、「Disjoint Association Type」の「DAT」とも呼ばれます。
[RFC8697] specifies the mechanism for the capability advertisement of the Association types supported by a PCEP speaker by defining an ASSOC-Type-List TLV to be carried within an OPEN object. This capability exchange for the DAT (2) MUST be done before using the disjoint association. Thus, the PCEP speaker MUST include the DAT in the ASSOC-Type-List TLV and MUST receive the same from the PCEP peer before using the Disjoint Association Group (DAG) in PCEP messages.
[RFC8697]は、OPENオブジェクト内で伝送されるASSOC-Type-List TLVを定義することにより、PCEPスピーカーによってサポートされるアソシエーションタイプの機能アドバタイズメントのメカニズムを指定します。 DAT（2）のこの機能交換は、ディスジョイントアソシエーションを使用する前に行う必要があります。したがって、PCEPスピーカーは、DSSOをASSOC-Type-List TLVに含める必要があり、PCEPメッセージでDisjoint Association Group（DAG）を使用する前に、PCEPピアから同じものを受信する必要があります。
This Association type is considered to be both dynamic and operator-configured in nature. As per [RFC8697], the association group could be manually created by the operator on the PCEP peers, and the LSPs belonging to this association are conveyed via PCEP messages to the PCEP peer; alternately, the association group could be created dynamically by the PCEP speaker, and both the association group information and the LSPs belonging to the association group are conveyed to the PCEP peer. The Operator-configured Association Range MUST be set for this association-type to mark a range of Association Identifiers that are used for operator-configured associations to avoid any Association Identifier clash within the scope of the Association Source. (Refer to [RFC8697].)
このアソシエーションタイプは、動的であり、オペレーターによって構成されていると見なされます。 [RFC8697]によると、アソシエーショングループはPCEPピアのオペレーターによって手動で作成でき、このアソシエーションに属するLSPはPCEPメッセージを介してPCEPピアに伝達されます。あるいは、アソシエーショングループはPCEPスピーカーによって動的に作成でき、アソシエーショングループ情報とアソシエーショングループに属するLSPの両方がPCEPピアに伝達されます。オペレーターが設定した関連付けに使用される関連付け識別子の範囲をマークして、関連付けソースのスコープ内での関連付け識別子の衝突を回避するために、この関連付けタイプにオペレーター設定の関連付け範囲を設定する必要があります。 （[RFC8697]を参照してください。）
A Disjoint Association Group can have two or more LSPs, but a PCE may be limited in the number of LSPs it can take into account when computing disjointness. If a PCE receives more LSPs in the group than it can handle in its computation algorithm, it SHOULD apply disjointness computation to only a subset of LSPs in the group. The subset of disjoint LSPs will be decided by PCE as a local policy. Local polices MAY define the computational behavior for the other LSPs in the group. For example, the PCE may provide no path, a shortest path, or a constrained path based on relaxing disjointness, etc. The disjoint status of the computed path is informed to the PCC via the DISJOINTNESS-STATUS TLV (see Section 5.2).
Disjoint Association Groupには2つ以上のLSPを含めることができますが、PCEは、ディスジョイントを計算するときに考慮できるLSPの数が制限されている場合があります。 PCEが計算アルゴリズムで処理できる数よりも多くのLSPをグループで受信する場合、グループ内のLSPのサブセットのみに素性計算を適用する必要があります（SHOULD）。ばらばらのLSPのサブセットは、ローカルポリシーとしてPCEによって決定されます。ローカルポリシーは、グループ内の他のLSPの計算動作を定義する場合があります。たとえば、PCEはパスを提供しない、最短パス、またはばらばらの緩和に基づく制約パスなどを提供します。計算されたパスのばらばら状態はDISJOINTNESS-STATUS TLVを介してPCCに通知されます（セクション5.2を参照）。
There are different types of disjointness identified by the flags (T, S, N, and L) in the DISJOINTNESS-CONFIGURATION TLV (see Section 5.2). All LSPs in a particular Disjoint Association Group MUST use the same combination of T, S, N, and L flags in the DISJOINTNESS-CONFIGURATION TLV. If a PCEP peer receives a PCEP message for LSPs belonging to the same Disjoint Association Group but having an inconsistent combination of T, S, N, and L flags, the PCEP peer MUST NOT add the LSPs to the Disjoint Association Group and MUST reply with a PCErr with Error-Type 26 (Association Error) and Error-value 6 (Association information mismatch).
DISJOINTNESS-CONFIGURATION TLV内のフラグ（T、S、N、およびL）によって識別されるさまざまなタイプのばらばらさがあります（セクション5.2を参照）。特定のDisjoint Association GroupのすべてのLSPは、DISJOINTNESS-CONFIGURATION TLVでT、S、N、およびLフラグの同じ組み合わせを使用する必要があります。 PCEPピアが同じDisjoint Association Groupに属しているが、T、S、N、およびLフラグの組み合わせに一貫性がないLSPのPCEPメッセージを受信する場合、PCEPピアはLSPをDisjoint Association Groupに追加してはならず、応答する必要があります。エラータイプ26（関連付けエラー）およびエラー値6（関連付け情報の不一致）を持つPCErr。
A particular LSP MAY be associated to multiple Disjoint Association Groups, but in that case, the PCE SHOULD try to consider all the Disjoint Association Groups during path computation, if possible. Otherwise, a local policy MAY define the computational behavior. If a PCE does not support such a path computation, it MUST NOT add the LSP into the association group and MUST return a PCErr with Error-Type 26 (Association Error) and Error-value 7 (Cannot join the association group).
特定のLSPは複数のばらばらなアソシエーショングループに関連付けられる場合がありますが、その場合、PCEは、可能であれば、パスの計算中にすべてのばらばらなアソシエーショングループを検討する必要があります（SHOULD）。それ以外の場合は、ローカルポリシーが計算動作を定義する場合があります。 PCEがそのようなパス計算をサポートしない場合、LSPを関連付けグループに追加してはならず（MUST）、エラータイプ26（関連付けエラー）およびエラー値7（関連付けグループに参加できない）のPCErrを返さなければなりません（MUST）。
The Disjoint Association Group (ASSOCIATION object with Association type = 2 for DAT) MUST carry the following TLV:
Disjoint Association Group（DATのAssociation type = 2のASSOCIATIONオブジェクト）は、次のTLVを運ぶ必要があります。
* DISJOINTNESS-CONFIGURATION TLV: Used to communicate some disjointness configuration parameters. This is applicable for all PCEP messages that include DAG.
* DISJOINTNESS-CONFIGURATION TLV：いくつかのバラバラな構成パラメーターを通信するために使用されます。これは、DAGを含むすべてのPCEPメッセージに適用されます。
In addition, the Disjoint Association Group (ASSOCIATION object with Association type = 2 for DAT) MAY carry the following TLVs:
さらに、Disjoint Association Group（DATのAssociation type = 2のASSOCIATIONオブジェクト）は、次のTLVを運ぶことができます：
* DISJOINTNESS-STATUS TLV: Used to communicate the status of the computed disjointness. This is applicable for messages from a PCE to a PCC only (i.e., PCUpd, PCInitiate, or PCRep messages).
* DISJOINTNESS-STATUS TLV：計算された素性のステータスを伝えるために使用されます。これは、PCEからPCCへのメッセージにのみ適用されます（つまり、PCUpd、PCInitiate、またはPCRepメッセージ）。
* VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor-specific behavioral information, described in [RFC7470].
* VENDOR-INFORMATION-TLV：[RFC7470]で説明されている、ベンダー固有の任意の動作情報を伝達するために使用されます。
* OF-List TLV: Used to communicate the disjointness objective function. See Section 5.3.
* OFリストTLV：ばらばらの目的関数を伝えるために使用されます。セクション5.3を参照してください。
The DISJOINTNESS-CONFIGURATION TLV is shown in the following figure:
DISJOINTNESS-CONFIGURATION 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 = 46 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |T|P|S|N|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DISJOINTNESS-CONFIGURATION TLV
図3：DISJOINTNESS-CONFIGURATION TLV
Type: 46
タイプ：46
Length: Fixed value of 4 bytes.
長さ：4バイトの固定値。
Flags:
フラグ：
L (Link Diverse) bit: When set, this indicates that the computed paths within the Disjoint Association Group MUST NOT have any link in common.
L（Link Diverse）ビット：設定されている場合、これはDisjoint Association Group内の計算されたパスに共通のリンクがあってはならないことを示します。
N (Node Diverse) bit: When set, this indicates that the computed paths within the Disjoint Association Group MUST NOT have any node in common.
N（ノードダイバース）ビット：セットされている場合、これは、ディスジョイントアソシエーショングループ内の計算されたパスに共通のノードがあってはならないことを示します。
S (SRLG Diverse) bit: When set, this indicates that the computed paths within the Disjoint Association Group MUST NOT share any SRLG (Shared Risk Link Group).
S（SRLGダイバース）ビット：設定されている場合、Disjoint Association Group内の計算されたパスがSRLG（共有リスクリンクグループ）を共有してはならないことを示します。
P (Shortest Path) bit: When set, this indicates that the computed path of the LSP SHOULD satisfy all the constraints and objective functions first without considering the diversity constraint. This means that all of the LSPs with P flag set in the association group are computed first, as if the disjointness constraint has not been configured; then, with those LSPs fixed, the other LSPs with P flag unset in the association group are computed by taking into account the disjointness constraint. The role of P flag is further described with examples in Section 5.5.
P（Shortest Path）ビット：セットされている場合、これはLSPの計算されたパスが多様性制約を考慮せずにすべての制約と目的関数を最初に満たすべきであることを示しますつまり、結合グループにPフラグが設定されているすべてのLSPが最初に計算されます。次に、それらのLSPが固定された状態で、関連付けグループでPフラグが設定されていない他のLSPが、互いに素な制約を考慮して計算されます。 Pフラグの役割については、セクション5.5の例でさらに説明します。
T (Strict Disjointness) bit: When set, if disjoint paths cannot be found, the PCE MUST return no path for LSPs that could not be disjoint. When unset, the PCE is allowed to relax disjointness by either applying a requested objective function (cf. Section 5.3) or using the local policy if no objective function is requested (e.g., using a lower disjoint type (link instead of node) or fully relaxing disjointness constraint). See Section 5.6 for further details.
T（Strict Disjointness）ビット：セットされている場合、ディスジョイントパスが見つからない場合、PCEはディスジョイントできなかったLSPのパスを返さない必要があります。設定を解除すると、PCEは、要求された目的関数を適用する（セクション5.3を参照）か、目的関数が要求されていない場合はローカルポリシーを使用（たとえば、より低い非結合型（ノードではなくリンク）を使用）するか、完全に解放することで、ばらばらさを緩和できます。ばらばらの制約を緩和する）。詳細については、セクション5.6を参照してください。
Unassigned bits: Unassigned bits are considered reserved. They MUST be set to 0 on transmission and MUST be ignored on receipt.
未割り当てビット：未割り当てビットは予約済みと見なされます。送信時には0に設定する必要があり、受信時には無視する必要があります。
If a PCEP speaker receives a Disjoint Association Group (ASSOCIATION object with Association type = 2 for DAT) without the DISJOINTNESS-CONFIGURATION TLV, it SHOULD reply with a PCErr Error-Type 6 (Mandatory Object missing) and Error-value 15 (DISJOINTNESS-CONFIGURATION TLV missing).
PCEPスピーカーがDISJOINTNESS-CONFIGURATION TLVなしでディスジョイントアソシエーショングループ（DATのアソシエーションタイプ= 2のASSOCIATIONオブジェクト）を受信した場合、PCErrエラータイプ6（必須オブジェクトがありません）およびエラー値15（DISJOINTNESS- CONFIGURATION TLVがありません）。
The DISJOINTNESS-STATUS TLV uses the same format as the DISJOINTNESS-CONFIGURATION TLV with a different type 47 (in the TLV). The L, N, and S flags are set if the respective disjointness criterion was requested and the computed paths meet it. The P flag indicates that the computed path is the shortest path (computed first without taking disjointness constraints into consideration but considering other constraints).
DISJOINTNESS-STATUS TLVは、異なるタイプ47（TLV内）を持つDISJOINTNESS-CONFIGURATION TLVと同じ形式を使用します。 L、N、およびSフラグは、それぞれの素性基準が要求され、計算されたパスがそれを満たしている場合に設定されます。 Pフラグは、計算されたパスが最短パスであることを示します（素の制約を考慮せずに他の制約を考慮せずに最初に計算されます）。
The T flag has no meaning in the DISJOINTNESS-STATUS TLV and MUST NOT be set while sending and MUST be ignored on receipt.
TフラグはDISJOINTNESS-STATUS TLVでは意味がなく、送信中は設定してはならず、受信時には無視する必要があります。
Any document defining a new flag for the DISJOINTNESS-CONFIGURATION TLV automatically defines a new flag with the same name and in the same location in DISJOINTNESS-STATUS TLV; the semantics of the flag in the DISJOINTNESS-STATUS TLV MUST be specified in the document that specifies the flag in the DISJOINTNESS-CONFIGURATION TLV.
DISJOINTNESS-CONFIGURATION TLVの新しいフラグを定義するドキュメントは、自動的に同じ名前でDISJOINTNESS-STATUS TLVの同じ場所に新しいフラグを定義します。 DISJOINTNESS-STATUS TLVのフラグのセマンティクスは、DISJOINTNESS-CONFIGURATION TLVのフラグを指定するドキュメントで指定する必要があります。
An objective function (OF) MAY be applied to the disjointness computation to drive the PCE computation behavior. In this case, the OF-List TLV (defined in [RFC5541]) is used as an optional TLV in the ASSOCIATION object. Whereas the PCEP OF-List TLV allows multiple OF-codes inside the TLV, a sender SHOULD include a single OF-code in the OF-List TLV when included in the Association Group, and the receiver MUST consider the first OF-code only and ignore others if included.
PCE計算動作を駆動するために、目的関数（OF）を素の計算に適用してもよい（MAY）。この場合、OF-List TLV（[RFC5541]で定義）は、ASSOCIATIONオブジェクトのオプションのTLVとして使用されます。 PCEP OFリストTLVはTLV内で複数のOFコードを許可しますが、送信者はアソシエーショングループに含まれる場合、OFリストTLVに単一のOFコードを含める必要があり、受信者は最初のOFコードのみを考慮しなければなりません。含まれている場合は他を無視します
To minimize the common shared resources (Node, Link, or SRLG) between a set of paths during path computation, three new OF-codes are defined:
パス計算中に一連のパス間の共通の共有リソース（ノード、リンク、またはSRLG）を最小限に抑えるために、3つの新しいOFコードが定義されています。
MSL
MSL
Name: Minimize the number of Shared (common) Links. Objective Function Code: 15 Description: Find a set of paths such that it passes through the least number of shared (common) links. - A network comprises a set of N links {Li, (i=1...N)}. - A path P passes through K links {Lpi,(i=1...K)}. - A set of paths {P1...Pm} have L links that are common to more than one path {Lci,(i=1...L)}. - Find a set of paths such that the value of L is minimized.
名前：共有（共通）リンクの数を最小限に抑えます。目的関数コード：15説明：最小数の共有（共通）リンクを通過するようなパスのセットを見つけます。 -ネットワークは、N個のリンクのセット{Li、（i = 1 ... N）}で構成されます。 -パスPはKリンク{Lpi、（i = 1 ... K）}を通過します。 -パスのセット{P1 ... Pm}には、複数のパス{Lci、（i = 1 ... L）}に共通のLリンクがあります。 -Lの値が最小になるようなパスのセットを見つけます。
MSS
MSS
Name: Minimize the number of Shared (common) SRLGs. Objective Function Code: 16 Description: Find a set of paths such that it passes through the least number of shared (common) SRLGs. - A network comprises a set of N links {Li, (i=1...N)}. - A path P passes through K links {Lpi,(i=1...K)} belonging to unique M SRLGs {Spi,(i=1..M)}. - A set of paths {P1...Pm} have L SRLGs that are common to more than one path {Sci,(i=1...L)}. - Find a set of paths such that the value of L is minimized.
名前：共有（共通）SRLGの数を最小限に抑えます。目的関数コード：16説明：共有（共通）SRLGの最小数を通過するようなパスのセットを見つけます。 -ネットワークは、N個のリンクのセット{Li、（i = 1 ... N）}で構成されます。 -パスPは、一意のM SRLG {Spi、（i = 1..M）}に属するKリンク{Lpi、（i = 1 ... K）}を通過します。 -パスのセット{P1 ... Pm}には、複数のパス{Sci、（i = 1 ... L）}に共通のL個のSRLGがあります。 -Lの値が最小になるようなパスのセットを見つけます。
MSN
MSN
Name: Minimize the number of Shared (common) Nodes. Objective Function Code: 17 Description: Find a set of paths such that they pass through the least number of shared (common) nodes. - A network comprises a set of N nodes {Ni, (i=1...N)}. - A path P passes through K nodes {Npi,(i=1...K)}. - A set of paths {P1...Pm} have L nodes that are common to more than one path {Nci,(i=1...L)}. - Find a set of paths such that the value of L is minimized.
名前：共有（共通）ノードの数を最小限に抑えます。目的関数コード：17説明：最小数の共有（共通）ノードを通過するようなパスのセットを見つけます。 -ネットワークは、N個のノードのセット{Ni、（i = 1 ... N）}で構成されます。 -パスPは、K個のノード{Npi、（i = 1 ... K）}を通過します。 -パスのセット{P1 ... Pm}には、複数のパス{Nci、（i = 1 ... L）}に共通のLノードがあります。 -Lの値が最小になるようなパスのセットを見つけます。
If the OF-List TLV is included in the ASSOCIATION object, the first OF-code inside the OF object MUST be one of the disjoint OFs defined in this document. If this condition is not met, the PCEP speaker MUST respond with a PCErr message with Error-Type 10 (Reception of an invalid object) and Error-value 32 (Incompatible OF code).
OFリストTLVがASSOCIATIONオブジェクトに含まれている場合、OFオブジェクト内の最初のOFコードは、このドキュメントで定義されているばらばらのOFの1つである必要があります。この条件が満たされない場合、PCEPスピーカーは、エラータイプ10（無効なオブジェクトの受信）およびエラー値32（互換性のないOFコード）のPCErrメッセージで応答する必要があります。
[RFC5440] defines a mechanism for the synchronization of a set of path computation requests by using the SVEC 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 path computation requests, 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 describes a number of usage scenarios for SVEC lists within single-domain and multi-domain environments.
[RFC5440]は、SVECオブジェクトを使用して、パス計算要求のセットを同期するためのメカニズムを定義します。これは、依存することも独立することもできる同期された要求のリストを指定します。 SVECオブジェクトは、RP（Request Parameters）オブジェクトの「Request-ID-number」で識別される一連のパス計算要求間の関係を識別します。 [RFC6007]は、従属要求を計算するときの同期パス計算のためのSVECリストの使用をさらに明確にし、単一ドメインおよびマルチドメイン環境内のSVECリストのいくつかの使用シナリオについて説明します。
The SVEC object includes a Flags field that indicates the potential dependency between the set of path computation requests in a similar way as the Flags field in the TLVs defined in this document. The path computation request in the Path Computation Request (PCReq) message MAY use both the SVEC and ASSOCIATION objects to identify the related path computation request, as well as the DAG. The PCE MUST try to find a path that meets both the constraints. It is possible that the diversity requirement in the association group is different from the one in the SVEC object. The PCE MUST consider both the objects (including the flags set inside the objects) as per the processing rules and aim to find a path that meets both of these constraints. In case no such path is possible, the PCE MUST send a Path Computation Reply (PCRep) with a NO-PATH object indicating path computation failure, as per [RFC5440]. It should be noted that the LSPs in the association group can be fully same or partially overlapping with the LSPs grouped by the SVEC object in PCReq message.
SVECオブジェクトには、このドキュメントで定義されているTLVのFlagsフィールドと同様の方法で、パス計算要求のセット間の潜在的な依存関係を示すFlagsフィールドが含まれています。パス計算要求（PCReq）メッセージのパス計算要求は、SVECオブジェクトとASSOCIATIONオブジェクトの両方を使用して、関連するパス計算要求とDAGを識別できます（MAY）。 PCEは、両方の制約を満たすパスを見つけようとする必要があります。関連グループの多様性要件がSVECオブジェクトの要件と異なる可能性があります。 PCEは、処理ルールに従って両方のオブジェクト（オブジェクト内に設定されたフラグを含む）を考慮し、これらの制約の両方を満たすパスを見つけることを目的とする必要があります。そのようなパスが不可能な場合、PCEは、[RFC5440]のように、パス計算の失敗を示すNO-PATHオブジェクトを含むパス計算応答（PCRep）を送信する必要があります。アソシエーショングループ内のLSPは、PCReqメッセージ内のSVECオブジェクトによってグループ化されたLSPと完全に同じか、部分的に重複している可能性があることに注意してください。
Some examples of usage are listed below:
以下に使用例をいくつか示します。
* PCReq with SVEC object with node-diverse bit=1 (LSP1,LSP2) and DAG with S=1 (LSP1,LSP2) - both node- and SRLG-diverse path between LSP1 and LSP2.
* node-diverse bit = 1（LSP1、LSP2）のSVECオブジェクトを持つPCReqおよびS = 1（LSP1、LSP2）のDAG-LSP1とLSP2の間のノードとSRLGの両方のパス。
* PCReq with SVEC object with link-diverse bit=1 (LSP1,LSP2) and DAG with L=1 (LSP1,LSP3) - link-diverse paths between LSP1 and LSP2 and between LSP1 and LSP3. If the DAG is part of the stateful database, any future change in LSP3 will have an impact on LSP1. But any future change in LSP2 will have no impact on LSP1, as LSP2 is part of SVEC object (which is considered once on receipt of the PCReq message only).
* リンクダイバースビット= 1（LSP1、LSP2）のSVECオブジェクトを持つPCReqおよびL = 1（LSP1、LSP3）のDAG-LSP1とLSP2の間、およびLSP1とLSP3間のリンクダイバースパスDAGがステートフルデータベースの一部である場合、LSP3の将来の変更はLSP1に影響を与えます。ただし、LSP2はSVECオブジェクトの一部であるため、LSP2の将来の変更はLSP1に影響を与えません（PCReqメッセージの受信時に1度だけ考慮されます）。
This document defines three new OF-codes in Section 5.3 to maximize diversity as much as possible. In other words, new OF-codes allow specification of minimization of common shared resources (Node, Link, or SRLG) among a set of paths during path computation.
このドキュメントでは、セクション5.3で3つの新しいOFコードを定義して、多様性を可能な限り最大化しています。言い換えると、新しいOFコードを使用すると、パス計算中にパスのセット間で共通の共有リソース（ノード、リンク、またはSRLG）を最小化することができます。
It may be interesting to note that the diversity flags in the SVEC object and OF for diversity can be used together. Some examples of usage are listed below:
SVECオブジェクトのダイバーシティフラグとダイバーシティのOFを一緒に使用できることに注意してください。以下に使用例をいくつか示します。
* SVEC object with node-diverse bit=1 - ensure full node diversity.
* node-diverse bit = 1のSVECオブジェクト-完全なノードダイバーシティを保証します。
* SVEC object with node-diverse bit=1 and OF=MSS - full node diversity with as much SRLG diversity as possible.
* node-diverse bit = 1およびOF = MSSのSVECオブジェクト-可能な限り多くのSRLGダイバーシティを持つ完全なノードダイバーシティ。
* SVEC object with domain-diverse bit=1 [RFC8685]; node-diverse bit=1, and OF=MSS - full domain and node diversity with as much SRLG diversity as possible.
* domain-diverse bit = 1のSVECオブジェクト[RFC8685]; node-diverse bit = 1、およびOF = MSS-可能な限り多くのSRLGダイバーシティを持つ完全なドメインおよびノードダイバーシティ。
* SVEC object with node-diverse bit=1 and OF=MSN - ensure full node diversity.
* node-diverse bit = 1およびOF = MSNのSVECオブジェクト-完全なノードダイバーシティを保証します。
In the last example above, it is interesting to note that "OF" becomes redundant as "SVEC object" ensures full node diversity; however, this specification does not prohibit redundant constraints while using "SVEC object" and "OF" together for diversity.
上記の最後の例では、「SVECオブジェクト」が完全なノードダイバーシティを保証するため、「OF」が冗長になることに注意してください。ただし、この仕様では、多様性のために「SVECオブジェクト」と「OF」を一緒に使用する際の冗長な制約は禁止されていません。
As mentioned in Section 5.2, the P flag (when set) indicates that the computed path of the LSP SHOULD satisfy all constraints and objective functions first without considering the diversity constraint.
セクション5.2で述べたように、Pフラグ（設定されている場合）は、LSPの計算パスが多様性制約を考慮せずにすべての制約と目的関数を最初に満たす必要があることを示します。
This means that an LSP with the P flag set should be placed first, as if the disjointness constraint has not been configured, while the other LSPs in the association with the P flag unset should be placed by taking into account the disjointness constraint. Setting the P flag changes the relationship between LSPs to a one-sided relationship (LSP 1 with P=0 depends on LSP 2 with P=1, but LSP 2 with P=1 does not depend on LSP 1 with P=0). Multiple LSPs in the same Disjoint Association Group may have the P flag set. In such a case, those LSPs may not be disjoint from each other but will be disjoint from other LSPs in the group that have the P flag unset.
これは、Pフラグが設定されたLSPが最初に配置される必要があることを意味します。これは、ばらばらの制約が構成されていない場合と同様に、Pフラグが設定されていない他のLSPは、ばらばらの制約を考慮して配置する必要があります。 Pフラグを設定すると、LSP間の関係が片側の関係に変更されます（P = 0のLSP 1はP = 1のLSP 2に依存しますが、P = 1のLSP 2はP = 0のLSP 1に依存しません）。同じDisjoint Association Group内の複数のLSPには、Pフラグが設定されている場合があります。そのような場合、それらのLSPは互いに分離していない可能性がありますが、Pフラグが設定されていないグループ内の他のLSPから分離しています。
This could be required in some primary/backup scenarios where the primary path should use the more optimal path available (taking into account the other constraints). When disjointness is computed, it is important for the algorithm to know that it should try to optimize the path of one or more LSPs in the Disjoint Association Group (for instance, the primary path), while other paths are allowed to be costlier (compared to a similar path without the disjointness constraint). Without such a hint, the disjointness algorithm may set a path for all LSPs that may not completely fulfill the customer's requirement.
これは、（他の制約を考慮して）プライマリパスが利用可能なより最適なパスを使用する必要がある一部のプライマリ/バックアップシナリオで必要になる場合があります。不整合が計算されるとき、他のパスの方がコストが高い（比較される）ことが許可されている一方で、不整合関連グループ内の1つ以上のLSPのパス（たとえば、プライマリパス）を最適化する必要があることをアルゴリズムが認識することが重要です素性制約のない同様のパスに）。このようなヒントがないと、不整合アルゴリズムは、顧客の要件を完全には満たさない可能性があるすべてのLSPのパスを設定する可能性があります。
_________________________________________
/ \
/ +------+ \
| | PCE | |
| +------+ |
| |
| |
| +------+ 10 +------+ |
CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2
| +------+ | | +------+ |
| | | |
| | | |
| +------+ | | +------+ |
CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4
| +------+ \ | / +------+ |
| \ | 10 / |
\ +-- R5 --------- R6 /
\_________________________________________/
Figure 4: Example Topology with Six Internal Routers
図4：6つの内部ルーターを含むトポロジの例
Note: In Figure 4, the cost of all the links is 1, unless explicitly marked otherwise.
注：図4では、特に明記されていない限り、すべてのリンクのコストは1です。
In the figure above, a customer has two dual-homed sites (CE1/CE3 and CE2/CE4). Let us consider that this customer wants two link disjoint paths between the two sites. Due to physical meshing, the customer wants to use CE1 and CE2 as the primary (and CE3 and CE4 are hosted in a remote site for redundancy purpose).
上の図では、顧客に2つのデュアルホームサイト（CE1 / CE3およびCE2 / CE4）があります。この顧客が2つのサイト間の2つのリンク分離パスを必要としていると考えてみましょう。物理的なメッシュのため、お客様はCE1とCE2をプライマリとして使用することを望んでいます（CE3とCE4は冗長性の目的でリモートサイトでホストされています）。
Without any hint (constraint) provided, the PCE may compute the two link disjoint LSPs together, leading to PE1->PE2 using path PE1->R1->R2->PE2 and PE3->PE4 using PE3->R3->R4->PE4. In this case, even if the disjointness constraint is fulfilled, the path from PE1 to PE2 does not use the best optimal path available in the network (path delay may be higher); the customer requirement is thus not completely fulfilled.
ヒント（制約）が指定されていない場合、PCEは2つのリンクのディスジョイントLSPを一緒に計算し、パスPE1-> R1-> R2-> PE2を使用してPE1-> PE2に、PE3-> R3-> R4を使用してPE3-> PE4を導きます。 -> PE4。この場合、ばらばらの制約が満たされている場合でも、PE1からPE2へのパスは、ネットワークで利用可能な最適な最適パスを使用しません（パス遅延が大きくなる可能性があります）。したがって、顧客の要求は完全には満たされません。
The usage of the P flag allows the PCE to know that a particular LSP should be tied to the best path, as if the disjointness constraint was not requested.
Pフラグを使用すると、PCEは、ばらばらの制約が要求されなかったかのように、特定のLSPを最適パスに関連付ける必要があることを認識できます。
In our example, if the P flag is set to the LSP PE1->PE2, the PCE should use the path PE1->R1->R3->R4->R2->PE2 for this LSP, while the other LSP should be link disjoint from this path. The second LSP will be placed on PE3->R5->R6->PE4, as it is allowed to be costlier.
この例では、PフラグがLSP PE1-> PE2に設定されている場合、PCEはこのLSPにパスPE1-> R1-> R3-> R4-> R2-> PE2を使用する必要がありますが、他のLSPはこのパスから切り離されたリンク。 2番目のLSPは、PE3-> R5-> R6-> PE4に配置されます。
Driving the PCE disjointness computation may be done in other ways, for instance, setting a metric boundary reflecting a path delay boundary. Other constraints may also be used.
PCEディスジョイントネス計算の駆動は、他の方法で実行できます。たとえば、パス遅延境界を反映するメトリック境界を設定します。他の制約を使用することもできます。
The P flag allows to simply express that the disjointness constraint should not make the LSP worst.
Pフラグを使用すると、ばらばらの制約によってLSPが最悪にならないようにすることができます。
Any constraint added to a path disjointness computation may reduce the chance to find suitable paths. The usage of the P flag, as any other constraint, may prevent finding a disjoint path. In the example above, if we consider that router R5 is down and if PE1->PE2 has the P flag set, there is no room available to place PE3->PE4 (the link disjointness constraint cannot be fulfilled). If PE1->PE2 has the P flag unset, the algorithm may be able to place PE1->PE2 on the R1->R2 link leaving room for PE3->PE4 using the R3->R4 link. When using the P flag or any additional constraint on top of the disjointness constraint, the user should be aware that there is less chance to fulfill the disjointness constraint.
パスの素性の計算に制約を追加すると、適切なパスを見つける機会が減る可能性があります。他の制約と同様に、Pフラグを使用すると、ばらばらのパスを見つけることができなくなる場合があります。上記の例で、ルータR5がダウンしていると見なし、PE1-> PE2にPフラグが設定されている場合、PE3-> PE4を配置するためのスペースがありません（リンクの不整合制約を満たすことができません）。 PE1-> PE2のPフラグが設定されていない場合、アルゴリズムはR1-> R2リンクにPE1-> PE2を配置して、R3-> R4リンクを使用してPE3-> PE4の余地を残すことができます。素性制約の上にPフラグまたは追加の制約を使用する場合、素性制約を満たす可能性が少ないことに注意する必要があります。
_________________________________________
/ \
/ +------+ \
| | PCE | |
| +------+ |
| |
| |
| +------+ 10 +------+ |
CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2
| +------+ | \ | +------+ |
| | \2 | |
| | \ | |
| +------+ | \ | +------+ |
CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4
| +------+ +------+ |
| |
\ /
\_________________________________________/
Figure 5: Example Topology with Four Internal Routers
図5：4つの内部ルーターを使用したトポロジの例
Note: In Figure 5, the cost of all the links is 1, unless explicitly marked otherwise.
注：図5では、特に明記されていない限り、すべてのリンクのコストは1です。
In the figure above, we still consider the same previous requirements, so PE1->PE2 LSP should be optimized (P flag set), while PE3->PE4 should be link disjoint and may use a costlier path.
上の図では、以前と同じ要件を考慮しているため、PE1-> PE2 LSPを最適化（Pフラグを設定）する必要がありますが、PE3-> PE4はリンクを切り離して、コストのかかるパスを使用する必要があります。
Regarding PE1->PE2, there are two paths that are satisfying the constraints (ECMP): PE1->R1->R4->R2->PE2 (path 1) and PE1->R1->R3->R4->R2->PE2 (path 2). An implementation may choose one of the paths.
PE1-> PE2に関しては、制約（ECMP）を満たす2つのパスがあります。PE1-> R1-> R4-> R2-> PE2（パス1）とPE1-> R1-> R3-> R4-> R2 -> PE2（パス2）。実装では、パスの1つを選択できます。
If the implementation elects only one path, there is a chance that picking up one path may prevent link disjointness. In our example, if path 2 is used for PE1->PE2, there is no room left for PE3->PE4, while if path 1 is used, PE3->PE4 can be placed on R3->R4 link.
実装が1つのパスのみを選択する場合、1つのパスを選択することでリンクの不整合が防止される可能性があります。この例では、パス2がPE1-> PE2に使用されている場合、PE3-> PE4の余地はありませんが、パス1が使用されている場合、PE3-> PE4はR3-> R4リンクに配置できます。
When the P flag is set for an LSP and when ECMPs are available, an implementation should aim to select a path that allows disjointness.
LSPにPフラグが設定されていて、ECMPが使用可能な場合、実装は、ばらばらになるパスを選択することを目的とする必要があります。
There may be some cases where the PCE is not able to provide a set of disjoint paths for one or more LSPs in the association.
PCEが関連付けの1つ以上のLSPに一連のばらばらのパスを提供できない場合があります。
When the T flag is set (Strict disjointness), if disjointness cannot be ensured for one or more LSPs, the PCE MUST reply to a PCReq with a PCRep message containing a NO-PATH object. In case of a PCRpt message, the PCE MUST return a PCErr message with Error-Type 26 (Association Error) and Error-value 7 (Cannot join the association group).
Tフラグが設定されている場合（厳密な不整合）、1つ以上のLSPの不整合が保証できない場合、PCEは、NO-PATHオブジェクトを含むPCRepメッセージでPCReqに応答する必要があります。 PCRptメッセージの場合、PCEは、エラータイプ26（アソシエーションエラー）およびエラー値7（アソシエーショングループに参加できない）のPCErrメッセージを返さなければなりません（MUST）。
In case of a network event leading to an impossible strict disjointness, the PCE MUST send a PCUpd message containing an empty Explicit Route Object (ERO) to the corresponding PCCs. In addition to the empty ERO object, the PCE MAY add the NO-PATH-VECTOR TLV [RFC5440] in the LSP object.
不可能な厳密なバラバラにつながるネットワークイベントの場合、PCEは空の明示ルートオブジェクト（ERO）を含むPCUpdメッセージを対応するPCCに送信する必要があります。空のEROオブジェクトに加えて、PCEはLSPオブジェクトにNO-PATH-VECTOR TLV [RFC5440]を追加してもよい（MAY）。
This document adds new bits in the Flags field of the NO-PATH-VECTOR TLV:
このドキュメントでは、NO-PATH-VECTOR TLVのフラグフィールドに新しいビットを追加します。
* bit 11: When set, the PCE indicates that it could not find a disjoint path for this LSP.
* ビット11：セットされている場合、PCEは、このLSPのばらばらのパスが見つからなかったことを示します。
* bit 10: When set, the PCE indicates that it does not support the requested disjointness computation.
* ビット10：セットされている場合、PCEは、要求されたばらの計算をサポートしていないことを示します。
When the T flag is unset, the PCE is allowed to relax disjointness by applying a requested objective function (Section 5.3) if specified. Otherwise, if no objective function is specified, the PCE is allowed to reduce the required level of disjointness as it deems fit. The actual level of disjointness of the paths computed by the PCE can be reported through the DISJOINTNESS-STATUS TLV by setting the appropriate flags in the TLV. While the DISJOINTNESS-CONFIGURATION TLV defines the desired level of disjointness required by configuration, the DISJOINTNESS-STATUS TLV defines the achieved level of disjointness computed.
Tフラグが設定されていない場合、PCEは、指定されている場合は、要求された目的関数（セクション5.3）を適用することにより、素性を緩和できます。それ以外の場合、目的関数が指定されていなければ、PCEは、必要とされるばらばらさのレベルを、それが適切であると見なしたときに減らすことができます。 PCEによって計算されたパスの実際の不整合のレベルは、TLVに適切なフラグを設定することにより、DISJOINTNESS-STATUS TLVを介して報告できます。 DISJOINTNESS-CONFIGURATION TLVは構成に必要な望ましいばらばらさのレベルを定義しますが、DISJOINTNESS-STATUS TLVは計算されたばらばらさの達成レベルを定義します。
There are some cases where the PCE may need to completely relax the disjointness constraint in order to provide a path to all the LSPs that are part of the association. A mechanism that allows the PCE to fully relax a constraint is considered by the authors as more global to PCEP rather than linked to the disjointness use case. As a consequence, it is considered out of scope of the document. See [PCE-OPTIONAL] for a proposed mechanism.
関連付けの一部であるすべてのLSPへのパスを提供するために、PCEが分離制約を完全に緩和する必要がある場合があります。 PCEが制約を完全に緩和できるようにするメカニズムは、不整合のユースケースにリンクされるのではなく、PCEPに対してよりグローバルであると著者は考えています。結果として、ドキュメントの範囲外と見なされます。提案されたメカニズムについては、[PCE-OPTIONAL]を参照してください。
This document defines one new PCEP Association type, which by itself does not add any new security concerns beyond those discussed in [RFC5440], [RFC8231], [RFC7470], and [RFC8697]. But adding of a spurious LSP into the Disjoint Association Group could lead to recomputation and setup of all LSPs in the group, which could be used to overwhelm the PCE and the network.
このドキュメントは、1つの新しいPCEPアソシエーションタイプを定義します。それ自体は、[RFC5440]、[RFC8231]、[RFC7470]、および[RFC8697]で説明されているものを超える新しいセキュリティ問題を追加しません。しかし、偽のLSPをDisjoint Association Groupに追加すると、グループ内のすべてのLSPの再計算とセットアップにつながり、PCEとネットワークを圧倒するために使用される可能性があります。
A spurious LSP can have flags that are inconsistent with those of the legitimate LSPs of the group and thus cause LSP allocation for the legitimate LSPs to fail with an error. Also, certain combinations of flags (notably, the 'T' bit) can result in conflicts that cannot be resolved.
偽のLSPには、グループの正当なLSPのフラグと一致しないフラグがあり、正当なLSPへのLSP割り当てがエラーで失敗する可能性があります。また、フラグの特定の組み合わせ（特に、「T」ビット）は、解決できない競合を引き起こす可能性があります。
Also, as stated in [RFC8697], much of the information carried in the ASSOCIATION object reflects information that can also be derived from the LSP database, but association provides a much easier grouping of related LSPs and messages. This holds true for the DAT as well; thus, this could provide an adversary with the opportunity to eavesdrop on the relationship between the LSPs and understand the network topology.
また、[RFC8697]で述べられているように、ASSOCIATIONオブジェクトで運ばれる情報の多くは、LSPデータベースからも得られる情報を反映していますが、関連付けにより、関連するLSPとメッセージをはるかに簡単にグループ化できます。これはDATにも当てはまります。したがって、これは敵対者にLSP間の関係を盗聴し、ネットワークトポロジを理解する機会を提供する可能性があります。
Thus, securing the PCEP session using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in BCP 195 [RFC7525], is RECOMMENDED.
したがって、BCP 195 [RFC7525]の推奨事項と現在のベストプラクティスに従って、トランスポート層セキュリティ（TLS）[RFC8253]を使用してPCEPセッションを保護することをお勧めします。
This document defines a new Association type, originally described in [RFC8697]. IANA has assigned the following new value in the "ASSOCIATION Type Field" subregistry [RFC8697] within the "Path Computation Element Protocol (PCEP) Numbers" registry:
このドキュメントは、元々[RFC8697]で記述された新しい関連タイプを定義します。 IANAは、「Path Computation Element Protocol（PCEP）Numbers」レジストリ内の「ASSOCIATION Type Field」サブレジストリ[RFC8697]に次の新しい値を割り当てました。
+======+======================+===========+
| Type | Name | Reference |
+======+======================+===========+
| 2 | Disjoint Association | RFC 8800 |
+------+----------------------+-----------+
Table 1: ASSOCIATION Type Field
表1：ASSOCIATIONタイプフィールド
This document defines two new PCEP TLVs. IANA has assigned the following values in the "PCEP TLV Type Indicators" subregistry within the "Path Computation Element Protocol (PCEP) Numbers" registry:
このドキュメントでは、2つの新しいPCEP TLVを定義しています。 IANAは、「Path Computation Element Protocol（PCEP）Numbers」レジストリ内の「PCEP TLV Type Indicators」サブレジストリに次の値を割り当てました。
+==========+============================+===========+
| TLV Type | TLV Name | Reference |
+==========+============================+===========+
| 46 | DISJOINTNESS-CONFIGURATION | RFC 8800 |
+----------+----------------------------+-----------+
| 47 | DISJOINTNESS-STATUS | RFC 8800 |
+----------+----------------------------+-----------+
Table 2: PCEP TLV Type Indicators
表2：PCEP TLVタイプインジケーター
IANA has created a new subregistry, named "DISJOINTNESS-CONFIGURATION TLV Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flags field in the DISJOINTNESS-CONFIGURATION TLV. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
IANAは、「パス計算要素プロトコル（PCEP）番号」レジストリ内に「DISJOINTNESS-CONFIGURATION TLVフラグフィールド」という名前の新しいサブレジストリを作成し、DISJOINTNESS-CONFIGURATION TLVのフラグフィールドを管理します。新しい値は、標準アクション[RFC8126]によって割り当てられます。各ビットは、次の品質で追跡する必要があります。
* Bit number (count from 0 as the most significant bit)
* ビット番号（0から最上位ビットとしてカウント）
* Flag Name
* フラグ名
* Reference
* 参照
The initial contents of this subregistry are shown below:
このサブレジストリの最初の内容を以下に示します。
+======+=========================+===========+
| Bit | Name | Reference |
+======+=========================+===========+
| 31 | L - Link Diverse | RFC 8800 |
+------+-------------------------+-----------+
| 30 | N - Node Diverse | RFC 8800 |
+------+-------------------------+-----------+
| 29 | S - SRLG Diverse | RFC 8800 |
+------+-------------------------+-----------+
| 28 | P - Shortest Path | RFC 8800 |
+------+-------------------------+-----------+
| 27 | T - Strict Disjointness | RFC 8800 |
+------+-------------------------+-----------+
| 0-26 | Unassigned | |
+------+-------------------------+-----------+
Table 3: DISJOINTNESS-CONFIGURATION TLV Flag Field
表3：DISJOINTNESS-CONFIGURATION TLVフラグフィールド
This document defines three new objective functions. IANA has made the following allocations in the "Objective Function" subregistry within the "Path Computation Element Protocol (PCEP) Numbers" registry:
このドキュメントでは、3つの新しい目的関数を定義しています。 IANAは、「パス計算要素プロトコル（PCEP）番号」レジストリ内の「目的関数」サブレジストリに次の割り当てを行いました。
+============+=======================+===========+
| Code Point | Name | Reference |
+============+=======================+===========+
| 15 | Minimize the number | RFC 8800 |
| | of Shared Links (MSL) | |
+------------+-----------------------+-----------+
| 16 | Minimize the number | RFC 8800 |
| | of Shared SRLGs (MSS) | |
+------------+-----------------------+-----------+
| 17 | Minimize the number | RFC 8800 |
| | of Shared Nodes (MSN) | |
+------------+-----------------------+-----------+
Table 4: Objective Function
表4：目的関数
This document defines new bits for the NO-PATH-VECTOR TLV in the "NO-PATH-VECTOR TLV Flag Field" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry. IANA has made the following allocations:
このドキュメントでは、「パス計算要素プロトコル（PCEP）番号」レジストリの「NO-PATH-VECTOR TLVフラグフィールド」サブレジストリで、NO-PATH-VECTOR TLVの新しいビットを定義しています。 IANAは次の割り当てを行いました。
+============+===========================+===========+
| Bit Number | Name | Reference |
+============+===========================+===========+
| 11 | Disjoint path not found | RFC 8800 |
+------------+---------------------------+-----------+
| 10 | Requested disjoint | RFC 8800 |
| | computation not supported | |
+------------+---------------------------+-----------+
Table 5: NO-PATH-VECTOR TLV Flag Field
表5：NO-PATH-VECTOR TLVフラグフィールド
This document defines two new Error-values within existing Error-Types related to disjoint association. IANA has allocated the following new Error-values in the "PCEP-ERROR Object Error Types and Values" subregistry within the "Path Computation Element Protocol (PCEP) Numbers" registry:
このドキュメントでは、非結合に関連する既存のエラータイプ内に2つの新しいエラー値を定義しています。 IANAは、「パス計算要素プロトコル（PCEP）番号」レジストリ内の「PCEP-ERRORオブジェクトエラータイプと値」サブレジストリに次の新しいエラー値を割り当てました。
+============+===========+============================+===========+
| Error-Type | Meaning | Error-value | Reference |
+============+===========+============================+===========+
| 6 | Mandatory | | [RFC5440] |
| | Object | | |
| | missing | | |
+------------+-----------+----------------------------+-----------+
| | | 15: DISJOINTNESS- | RFC 8800 |
| | | CONFIGURATION TLV missing | |
+------------+-----------+----------------------------+-----------+
| 10 | Reception | | [RFC5440] |
| | of an | | |
| | invalid | | |
| | object | | |
+------------+-----------+----------------------------+-----------+
| | | 32: Incompatible OF code | RFC 8800 |
+------------+-----------+----------------------------+-----------+
Table 6: PCEP-ERROR Object Error Types and Values
表6：PCEP-ERRORオブジェクトのエラータイプと値
An operator SHOULD be allowed to configure the Disjoint Association Groups and disjoint parameters at the PCEP peers and associate them with the LSPs. The operator MUST be allowed to set the Operator-configured Association Range. The operator SHOULD be allowed to set the local policies to define various disjoint computational behavior at the PCE.
オペレーターは、PCEPピアでDisjoint Association Groupsとdisjointパラメーターを構成し、それらをLSPに関連付けることが許可されるべきです（SHOULD）。オペレーターは、オペレーターが設定した関連範囲の設定を許可する必要があります。オペレーターは、PCEでさまざまなばらばらの計算動作を定義するローカルポリシーを設定できる必要があります（SHOULD）。
An implementation SHOULD allow the operator to view the disjoint associations configured or created dynamically. Furthermore, implementations SHOULD allow to view disjoint associations reported by each peer and the current set of LSPs in this association. The PCEP YANG module [PCEP-YANG] includes association group information.
実装は、オペレーターが動的に構成または作成されたばらばらの関連付けを表示できるようにする必要があります（SHOULD）。さらに、実装は、各ピアによって報告されたばらばらの関連付けと、この関連付けの現在のLSPセットを表示できるようにする必要があります（SHOULD）。 PCEP YANGモジュール[PCEP-YANG]には、関連グループ情報が含まれています。
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].
このドキュメントで定義されているメカニズムは、[RFC5440]にすでにリストされているものに加えて、新しい活性検出および監視の要件を意味するものではありません。
Apart from the operation verification requirements already listed in [RFC5440], a PCEP implementation SHOULD provide parameters related to disjoint path computation, such as number of DAG, number of disjoint path computation failures, etc. A PCEP implementation SHOULD log failure events (e.g., incompatible Flags).
[RFC5440]にすでにリストされている動作検証要件とは別に、PCEP実装は、DAGの数、非結合パス計算の失敗数など、非結合パス計算に関連するパラメーターを提供する必要があります（SHOULD）。PCEP実装は、失敗イベント（たとえば、互換性のないフラグ）。
Mechanisms defined in this document do not imply any new requirements on other protocols.
このドキュメントで定義されているメカニズムは、他のプロトコルに対する新しい要件を意味するものではありません。
Mechanisms defined in Section 8.6 of [RFC5440] also apply to PCEP extensions defined in this document. Additionally, a PCEP implementation SHOULD allow a limit to be placed on the number of LSPs that can belong to a DAG.
[RFC5440]のセクション8.6で定義されているメカニズムは、このドキュメントで定義されているPCEP拡張機能にも適用されます。さらに、PCEP実装では、DAGに属することができるLSPの数に制限を設定できるようにする必要があります（SHOULD）。
[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、Ed。、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<https://www.rfc-editor.org/info/rfc5440>。
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, June 2009, <https://www.rfc-editor.org/info/rfc5541>.
[RFC5541] Le Roux、JL。、Vasseur、JP。、およびY. Lee、「Encoding of Objective Functions in the Path Computation Element Communication Protocol（PCEP）」、RFC 5541、DOI 10.17487 / RFC5541、2009年6月、<https： //www.rfc-editor.org/info/rfc5541>。
[RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, <https://www.rfc-editor.org/info/rfc7470>.
[RFC7470] Zhang、F。およびA. Farrel、「経路計算要素通信プロトコルにおけるベンダー固有の制約の伝達」、RFC 7470、DOI 10.17487 / RFC7470、2015年3月、<https://www.rfc-editor.org / info / rfc7470>。
[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>。
[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>。
[RFC8685] Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R., and D. King, "Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture", RFC 8685, DOI 10.17487/RFC8685, December 2019, <https://www.rfc-editor.org/info/rfc8685>.
[RFC8685] Zhang、F.、Zhao、Q.、Gonzalez de Dios、O.、Casellas、R.、and D. King、 "Path Computation Element Communication Protocol（PCEP）Extensions for the Hierarchical Path Computation Element（H-PCE ）アーキテクチャ」、RFC 8685、DOI 10.17487 / RFC8685、2019年12月、<https://www.rfc-editor.org/info/rfc8685>。
[RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., Dhody, D., and Y. Tanaka, "Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, <https://www.rfc-editor.org/info/rfc8697>.
[RFC8697] Minei、I.、Crabbe、E.、Sivabalan、S.、Ananthakrishnan、H.、Dhody、D。、およびY. Tanaka、「ラベルのセット間の関係を確立するためのパス計算要素通信プロトコル（PCEP）拡張」スイッチドパス（LSP）」、RFC 8697、DOI 10.17487 / RFC8697、2020年1月、<https://www.rfc-editor.org/info/rfc8697>。
[PCE-OPTIONAL] Li, C., Zheng, H., and S. Litkowski, "Extension for Stateful PCE to allow Optional Processing of PCEP Objects", Work in Progress, Internet-Draft, draft-dhody-pce-stateful-pce-optional-06, 9 July 2020, <https://tools.ietf.org/html/draft-dhody-pce-stateful-pce-optional-06>.
[PCE-OPTIONAL] Li、C.、Zheng、H。、およびS. Litkowski、「PCEPオブジェクトのオプション処理を可能にするステートフルPCEの拡張機能」、進行中の作業、インターネットドラフト、draft-dhody-pce-stateful- pce-optional-06、2020年7月9日、<https://tools.ietf.org/html/draft-dhody-pce-stateful-pce-optional-06>。
[PCEP-YANG] Dhody, D., 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-14, 7 July 2020, <https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-14>.
[PCEP-YANG] Dhody、D.、Hardwick、J.、Beeram、V。、およびJ. Tantsura、「パス計算要素通信プロトコル（PCEP）のYANGデータモデル」、作業中、インターネットドラフト、ドラフト-ietf-pce-pcep-yang-14、2020年7月7日、<https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-14>。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<https：// www.rfc-editor.org/info/rfc4655>。
[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>。
[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>。
[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>。
Acknowledgments
謝辞
A special thanks to the authors of [RFC8697]; this document borrows some text from it. The authors would also like to thank Adrian Farrel and Julien Meuric for the valuable comments.
[RFC8697]の作者に特に感謝します。このドキュメントはそこからいくつかのテキストを借りています。著者はまた、貴重なコメントを提供してくれたAdrian FarrelとJulien Meuricにも感謝します。
Thanks to Emmanuel Baccelli for the RTGDIR review.
RTGDIRのレビューをしてくれたEmmanuel Baccelliに感謝します。
Thanks to Dale Worley for a detailed GENART review.
詳細なGENARTレビューを提供してくれたDale Worleyに感謝します。
Thanks to Alvaro Retana, Benjamin Kaduk, Suresh Krishnan, Roman Danyliw, Alissa Cooper, and Éric Vyncke for the IESG review.
IESGのレビューを提供してくれたAlvaro Retana、Benjamin Kaduk、Suresh Krishnan、Roman Danyliw、Alissa Cooper、ÉricVynckeに感謝します。
Contributors
貢献者
Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefiled Bangalore 560066 Karnataka India
Dhruv Dodhu Huayveli Technologies Divyashree Techno Park、Whitfield Field ೫೬೦೦೬೬カルナータカ州インド
Email: dhruv.ietf@gmail.com
Authors' Addresses
著者のアドレス
Stephane Litkowski Cisco Systems, Inc.
Stephane Litkowski Cisco Systems、Inc.
Email: slitkows.ietf@gmail.com
Siva Sivabalan Ciena Corporation
Shiva Sivabalan Saina Corporation
Email: msiva282@gmail.com
Colby Barth Juniper Networks
コルビーバースジュニパーネットワークス
Email: cbarth@juniper.net
Mahendra Singh Negi RtBrick India N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3 Bangalore 560102 Karnataka India
Mahendra Singh Negi RtBrick India N-17L、Floor-1、18th Cross Rd、HSR Layout Sector-3 Bangalore 560102 India Karnataka India
Email: mahend.ietf@gmail.com