[要約] RFC 8745は、状態を持つPCEと関連付けるためのPCEP拡張機能に関するものです。その目的は、作業用と保護用のLSPを関連付けることで、ネットワークの信頼性と効率を向上させることです。
Internet Engineering Task Force (IETF) H. Ananthakrishnan
Request for Comments: 8745 Netflix
Category: Standards Track S. Sivabalan
ISSN: 2070-1721 Cisco
C. Barth
Juniper Networks
I. Minei
Google, Inc
M. Negi
Huawei Technologies
March 2020
Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE
ワーキングおよびプロテクションラベルスイッチドパス（LSP）をステートフルPCEに関連付けるためのパス計算要素通信プロトコル（PCEP）拡張
Abstract
概要
An active stateful Path Computation Element (PCE) is capable of computing as well as controlling via Path Computation Element Communication Protocol (PCEP) Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Label Switched Paths (LSPs). Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs. This document defines the PCEP extension to associate two or more LSPs to provide end-to-end path protection.
アクティブなステートフルパス計算エレメント（PCE）は、パス計算エレメント通信プロトコル（PCEP）マルチプロトコルラベルスイッチングトラフィックエンジニアリング（MPLS-TE）ラベルスイッチドパス（LSP）を介して計算および制御することができます。さらに、アクティブなステートフルPCEがLSPを作成、維持、および削除することも可能です。このドキュメントでは、2つ以上のLSPを関連付けてエンドツーエンドのパス保護を提供するPCEP拡張を定義します。
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/rfc8745.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8745で入手できます。
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. PCEP Extensions
3.1. Path Protection Association Type
3.2. Path Protection Association TLV
4. Operation
4.1. State Synchronization
4.2. PCC-Initiated LSPs
4.3. PCE-Initiated LSPs
4.4. Session Termination
4.5. Error Handling
5. Other Considerations
6. IANA Considerations
6.1. Association Type
6.2. Path Protection Association TLV
6.3. PCEP Errors
7. Security Considerations
8. Manageability Considerations
8.1. Control of Function and Policy
8.2. Information and Data Models
8.3. Liveness Detection and Monitoring
8.4. Verify 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
[RFC5440] describes Path Computation Element Communication Protocol (PCEP) for communication between a Path Computation Client (PCC) and a PCE or between a pair of PCEs as per [RFC4655]. A PCE computes paths for MPLS-TE Label Switched Paths (LSPs) based on various constraints and optimization criteria.
[RFC5440]は、[RFC4655]のように、パス計算クライアント（PCC）とPCEの間、またはPCEのペアの間で通信するためのパス計算要素通信プロトコル（PCEP）について説明しています。 PCEは、さまざまな制約と最適化基準に基づいて、MPLS-TEラベルスイッチドパス（LSP）のパスを計算します。
Stateful PCE [RFC8231] specifies a set of extensions to PCEP to enable stateful control of paths such as MPLS-TE LSPs between and across PCEP sessions in compliance with [RFC4657]. It includes mechanisms to affect LSP state synchronization between PCCs and PCEs, delegation of control of LSPs to PCEs, and PCE control of timing and sequence of path computations within and across PCEP sessions. The focus is on a model where LSPs are configured on the PCC, and control over them is delegated to the stateful PCE. Furthermore, [RFC8281] specifies a mechanism to dynamically instantiate LSPs on a PCC based on the requests from a stateful PCE or a controller using stateful PCE.
ステートフルPCE [RFC8231]は、PCEPの拡張セットを指定して、[RFC4657]に準拠してPCEPセッション間およびPCEPセッション全体でMPLS-TE LSPなどのパスのステートフル制御を可能にします。これには、PCCとPCE間のLSP状態の同期、LSPの制御のPCEへの委任、PCEPセッション内およびPCEPセッション間でのパス計算のタイミングとシーケンスのPCE制御に影響を与えるメカニズムが含まれます。 LSPがPCCで構成されているモデルに焦点が当てられ、LSPの制御はステートフルPCEに委任されます。さらに、[RFC8281]は、ステートフルPCEまたはステートフルPCEを使用するコントローラーからの要求に基づいて、PCCでLSPを動的にインスタンス化するメカニズムを指定します。
Path protection [RFC4427] refers to a paradigm in which the working LSP is protected by one or more protection LSP(s). When the working LSP fails, protection LSP(s) is/are activated. When the working LSPs are computed and controlled by the PCE, there is benefit in a mode of operation where protection LSPs are also computed and controlled by the same PCE. [RFC8051] describes the applicability of path protection in PCE deployments.
パス保護[RFC4427]は、現用LSPが1つ以上の保護LSPによって保護されるパラダイムを指します。機能しているLSPに障害が発生すると、保護LSPがアクティブ化されます。現用LSPがPCEによって計算および制御される場合、保護LSPも同じPCEによって計算および制御される動作モードに利点があります。 [RFC8051]は、PCE展開におけるUPSRの適用性を説明しています。
This document specifies a stateful PCEP extension to associate two or more LSPs for the purpose of setting up path protection. The extension defined in this document covers the following scenarios:
このドキュメントでは、UPSRを設定する目的で2つ以上のLSPを関連付けるステートフルPCEP拡張を指定しています。このドキュメントで定義されている拡張機能は、次のシナリオに対応しています。
* A PCC initiates a protection LSP and retains the control of the LSP. The PCC computes the path itself or makes a request for path computation to a PCE. After the path setup, it reports the information and state of the path to the PCE. This includes the association group identifying the working and protection LSPs. This is the passive stateful mode [RFC8051].
* PCCは保護LSPを開始し、LSPの制御を保持します。 PCCはパス自体を計算するか、PCEへのパス計算を要求します。パスのセットアップ後、パスの情報と状態をPCEに報告します。これには、現用および保護LSPを識別する関連グループが含まれます。これはパッシブステートフルモードです[RFC8051]。
* A PCC initiates a protection LSP and delegates the control of the LSP to a stateful PCE. During delegation, the association group identifying the working and protection LSPs is included. The PCE computes the path for the protection LSP and updates the PCC with the information about the path as long as it controls the LSP. This is the active stateful mode [RFC8051].
* PCCは保護LSPを開始し、LSPの制御をステートフルPCEに委任します。委任中、作業および保護LSPを識別する関連付けグループが含まれます。 PCEは、LSPを制御する限り、保護LSPのパスを計算し、パスに関する情報でPCCを更新します。これはアクティブなステートフルモードです[RFC8051]。
* A protection LSP could be initiated by a stateful PCE, which retains the control of the LSP. The PCE is responsible for computing the path of the LSP and updating to the PCC with the information about the path. This is the PCE-Initiated mode [RFC8281].
* 保護LSPは、LSPの制御を保持するステートフルPCEによって開始できます。 PCEは、LSPのパスを計算し、パスに関する情報を使用してPCCを更新します。これはPCE開始モード[RFC8281]です。
Note that a protection LSP can be established (signaled) before the failure (in which case the LSP is said to be either in standby mode [RFC4427] or a primary LSP [RFC4872]) or after failure of the corresponding working LSP (known as a secondary LSP [RFC4872]). Whether to establish it before or after failure is according to operator choice or policy.
障害の前（この場合、LSPはスタンバイモード[RFC4427]またはプライマリLSP [RFC4872]のいずれかであると言われます）または対応する動作中のLSP（既知のセカンダリLSP [RFC4872]）。障害の前または後に確立するかどうかは、オペレーターの選択またはポリシーに従います。
[RFC8697] introduces a generic mechanism to create a grouping of LSPs, which can then be used to define associations between a set of LSPs. The mechanism is equally applicable to stateful PCE (active and passive modes) and stateless PCE.
[RFC8697]は、LSPのグループを作成する一般的なメカニズムを導入しています。これを使用して、LSPのセット間の関連付けを定義できます。このメカニズムは、ステートフルPCE（アクティブモードとパッシブモード）とステートレスPCEに等しく適用できます。
This document specifies a PCEP extension to associate one working LSP with one or more protection LSPs using the generic association mechanism.
このドキュメントでは、一般的なアソシエーションメカニズムを使用して、1つの動作中のLSPを1つ以上の保護LSPに関連付けるPCEP拡張を指定します。
This document describes a PCEP extension to associate protection LSPs by creating the Path Protection Association Group (PPAG) and encoding this association in PCEP messages for stateful PCEP sessions.
このドキュメントでは、Path Protection Association Group（PPAG）を作成し、ステートフルPCEPセッションのPCEPメッセージでこの関連付けをエンコードすることにより、保護LSPを関連付けるPCEP拡張について説明します。
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]で説明されているように解釈されます。
The following terms are used in this document:
このドキュメントでは、次の用語が使用されています。
ERO: Explicit Route Object
ERO：明示的なルートオブジェクト
LSP: Label Switched Path
LSP：ラベルスイッチドパス
PCC: Path Computation Client
PCC：パス計算クライアント
PCE: Path Computation Element
PCE：パス計算要素
PCEP: Path Computation Element Communication Protocol
PCEP：パス計算要素通信プロトコル
PPAG: Path Protection Association Group
PPAG：UPSR保護グループ
TLV: Type, Length, and Value
TLV：タイプ、長さ、値
As per [RFC8697], LSPs are not associated by listing the other LSPs with which they interact but, rather, by making them belong to an association group. All LSPs join an association group individually. The generic ASSOCIATION object is used to associate two or more LSPs as specified in [RFC8697]. This document defines a new Association type called "Path Protection Association Type" of value 1 and a "Path Protection Association Group" (PPAG). A member LSP of a PPAG can take the role of working or protection LSP. A PPAG can have one working LSP and/or one or more protection LSPs. The source, destination, Tunnel ID (as carried in LSP-IDENTIFIERS TLV [RFC8231], with description as per [RFC3209]), and Protection Type (PT) (in Path Protection Association TLV) of all LSPs within a PPAG MUST be the same. As per [RFC3209], a TE tunnel is used to associate a set of LSPs during reroute or to spread a traffic trunk over multiple paths.
[RFC8697]によると、LSPは、それらが相互作用する他のLSPをリストすることによって関連付けられるのではなく、関連グループに所属させることによって関連付けられます。すべてのLSPは関連付けグループに個別に参加します。汎用ASSOCIATIONオブジェクトは、[RFC8697]で指定されているように、2つ以上のLSPを関連付けるために使用されます。このドキュメントでは、値1の「パス保護アソシエーションタイプ」と呼ばれる新しいアソシエーションタイプと「パス保護アソシエーショングループ」（PPAG）を定義しています。 PPAGのメンバーLSPは、ワーキングLSPまたは保護LSPの役割を果たすことができます。 PPAGには、1つの現用LSPまたは1つ以上の保護LSPを含めることができます。 PPAG内のすべてのLSPの送信元、宛先、トンネルID（LSP-IDENTIFIERS TLV [RFC8231]、[RFC3209]による説明付き）、および保護タイプ（PT）（パス保護協会TLV）は、同じ。 [RFC3209]によると、TEトンネルは、再ルーティング中に一連のLSPを関連付けるため、またはトラフィックトランクを複数のパスに分散するために使用されます。
The format of the ASSOCIATION object used for PPAG is specified in [RFC8697].
PPAGに使用されるASSOCIATIONオブジェクトの形式は、[RFC8697]で指定されています。
[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 Association type described in this document (i.e., Path Protection Association Type) MAY be done before using this association, i.e., the PCEP speaker MAY include the Path Protection Association Type (1) in the ASSOC-Type-List TLV before using the PPAG in the PCEP messages.
[RFC8697]は、OPENオブジェクト内で伝送されるASSOC-Type-List TLVを定義することにより、PCEPスピーカーによってサポートされるアソシエーションタイプの機能アドバタイズメントのメカニズムを指定します。このドキュメントで説明されているアソシエーションタイプ（パス保護アソシエーションタイプ）のこの機能交換は、このアソシエーションを使用する前に行うことができます。つまり、PCEPスピーカーはASSOC-Type-List TLVにパス保護アソシエーションタイプ（1）を含めることができます（MAY）。 PCEPメッセージでPPAGを使用する前。
This Association type is dynamic in nature and created by the PCC or PCE for the LSPs belonging to the same TE tunnel (as described in [RFC3209]) originating at the same head node and terminating at the same destination. These associations are conveyed via PCEP messages to the PCEP peer. As per [RFC8697], the association source is set to the local PCEP speaker address that created the association unless local policy dictates otherwise. Operator-configured Association Range MUST NOT be set for this Association type and MUST be ignored.
このアソシエーションタイプは本質的に動的であり、同じ[TEC3209]で説明されているように同じTEトンネルに属し、同じ宛先ノードで終了するLSPのPCCまたはPCEによって作成されます。これらの関連付けは、PCEPメッセージを介してPCEPピアに伝達されます。 [RFC8697]によると、ローカルポリシーで他の指示がない限り、関連付けのソースは、関連付けを作成したローカルPCEPスピーカーアドレスに設定されます。オペレーターが設定したアソシエーション範囲は、このアソシエーションタイプに設定してはならず、無視する必要があります。
The Path Protection Association TLV is an optional TLV for use in the ASSOCIATION object with the Path Protection Association Type. The Path Protection Association TLV MUST NOT be present more than once. If it appears more than once, only the first occurrence is processed and any others MUST be ignored.
パス保護関連付けTLVは、パス保護関連付けタイプのASSOCIATIONオブジェクトで使用するオプションのTLVです。パス保護アソシエーションTLVは2回以上存在してはなりません。それが複数回出現する場合、最初の発生のみが処理され、その他は無視されなければなりません（MUST）。
The Path Protection Association TLV follows the PCEP TLV format of [RFC5440].
UPSR TLVは、[RFC5440]のPCEP TLV形式に従います。
The Type (16 bits) of the TLV is 38. The Length field (16 bits) has a fixed value of 4.
TLVのタイプ（16ビット）は38です。長さフィールド（16ビット）の値は4に固定されています。
The value is comprised of a single field, the Path Protection Association Flags (32 bits), where each bit represents a flag option.
値は、単一のフィールドであるUPSRフラグ（32ビット）で構成され、各ビットはフラグオプションを表します。
The format of the Path Protection Association TLV (Figure 1) is as follows:
UPSR TLV（図1）の形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 38 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT | Unassigned Flags |S|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Path Protection Association TLV Format
図1：UPSR TLVフォーマット
Path Protection Association Flags (32 bits)
UPSRフラグ（32ビット）
The following flags are currently defined:
現在、次のフラグが定義されています。
* Protecting (P): 1 bit - This bit is as defined in Section 14.1 of [RFC4872] to indicate if the LSP is a working (0) or protection (1) LSP.
* 保護（P）：1ビット-このビットは、[RFC4872]のセクション14.1で定義されているとおりであり、LSPが機能している（0）か、保護（1）のLSPであるかを示します。
* Secondary (S): 1 bit - This bit is as defined in Section 14.1 of [RFC4872] to indicate if the LSP is a primary (0) or secondary (1) LSP. The S flag is ignored if the P flag is not set.
* セカンダリ（S）：1ビット-このビットは、[RFC4872]のセクション14.1で定義されているとおり、LSPがプライマリ（0）かセカンダリ（1）のLSPかを示します。 Pフラグが設定されていない場合、Sフラグは無視されます。
* Protection Type (PT): 6 bits - This field is as defined in Section 14.1 of [RFC4872] (as "LSP (Protection Type) Flags") to indicate the LSP protection type in use. Any type already defined or that could be defined in the future for use in the RSVP-TE PROTECTION object is acceptable in this TLV unless explicitly stated otherwise.
* 保護タイプ（PT）：6ビット-このフィールドは、[RFC4872]のセクション14.1で定義されているとおり（「LSP（保護タイプ）フラグ」として）、使用中のLSP保護タイプを示します。特に明記されていない限り、すでに定義されているタイプ、またはRSVP-TE PROTECTIONオブジェクトで使用するために将来定義される可能性のあるタイプは、このTLVで受け入れられます。
* Unassigned bits are considered reserved. They MUST be set to 0 on transmission and MUST be ignored on receipt.
* 割り当てられていないビットは予約済みと見なされます。送信時には0に設定し、受信時には無視する必要があります。
If the TLV is missing in the PPAG ASSOCIATION object, it is considered that the LSP is a working LSP (i.e., as if the P bit is unset).
TLVがPPAG ASSOCIATIONオブジェクトにない場合、LSPは動作しているLSPであると見なされます（つまり、Pビットが設定されていないかのように）。
An LSP is associated with other LSPs with which it interacts by adding them to a common association group via the ASSOCIATION object. All procedures and error handling for the ASSOCIATION object is as per [RFC8697].
LSPは、ASSOCIATIONオブジェクトを介して共通の関連付けグループに追加することにより、相互作用する他のLSPに関連付けられます。 ASSOCIATIONオブジェクトのすべての手順とエラー処理は、[RFC8697]に準拠しています。
During state synchronization, a PCC reports all the existing LSP states as described in [RFC8231]. The association group membership pertaining to an LSP is also reported as per [RFC8697]. This includes PPAGs.
状態の同期中、PCCは、[RFC8231]で説明されているように、すべての既存のLSP状態を報告します。 LSPに関連するアソシエーショングループのメンバーシップも[RFC8697]に従って報告されます。これにはPPAGが含まれます。
A PCC can associate a set of LSPs under its control for path protection purposes. Similarly, the PCC can remove one or more LSPs under its control from the corresponding PPAG. In both cases, the PCC reports the change in association to PCE(s) via a Path Computation Report (PCRpt) message. A PCC can also delegate the working and protection LSPs to an active stateful PCE, where the PCE would control the LSPs. The stateful PCE could update the paths and attributes of the LSPs in the association group via a Path Computation Update (PCUpd) message. A PCE could also update the association to the PCC via a PCUpd message. These procedures are described in [RFC8697].
PCCは、パス保護のために、その制御下にある一連のLSPを関連付けることができます。同様に、PCCは、その制御下にある1つ以上のLSPを対応するPPAGから削除できます。どちらの場合も、PCCはパス計算レポート（PCRpt）メッセージを介してPCEに関連する変更を報告します。 PCCは、動作中のLSPと保護LSPをアクティブなステートフルPCEに委任することもでき、PCEはLSPを制御します。ステートフルPCEは、パス計算更新（PCUpd）メッセージを介して、関連付けグループ内のLSPのパスと属性を更新できます。 PCEは、PCUpdメッセージを介してPCCへの関連付けを更新することもできます。これらの手順は[RFC8697]で説明されています。
It is expected that both working and protection LSPs are delegated together (and to the same PCE) to avoid any race conditions. Refer to [STATE-PCE-SYNC] for the problem description.
競合状態を回避するために、動作中のLSPと保護LSPの両方が（および同じPCEに）委任されることが期待されています。問題の説明については、[STATE-PCE-SYNC]を参照してください。
A PCE can create/update working and protection LSPs independently. As specified in [RFC8697], Association Groups can be created by both the PCE and the PCC. Furthermore, a PCE can remove a protection LSP from a PPAG as specified in [RFC8697]. The PCE uses PCUpd or Path Computation Initiate (PCInitiate) messages to communicate the association information to the PCC.
PCEは、動作および保護LSPを個別に作成/更新できます。 [RFC8697]で指定されているように、関連グループはPCEとPCCの両方で作成できます。さらに、[RFC8697]で指定されているように、PCEはPPAGから保護LSPを削除できます。 PCEは、PCUpdまたはPath Computation Initiate（PCInitiate）メッセージを使用して、関連付け情報をPCCに伝達します。
As per [RFC8697], the association information is cleared along with the LSP state information. When a PCEP session is terminated, after expiry of State Timeout Interval at the PCC, the LSP state associated with that PCEP session is reverted to operator-defined default parameters or behaviors as per [RFC8231]. The same procedure is also followed for the association information. On session termination at the PCE, when the LSP state reported by PCC is cleared, the association information is also cleared as per [RFC8697]. Where there are no LSPs in an association group, the association is considered to be deleted.
[RFC8697]に従い、関連付け情報はLSP状態情報とともにクリアされます。 PCEPセッションが終了すると、PCCでの状態タイムアウト間隔の満了後、そのPCEPセッションに関連付けられたLSP状態は、[RFC8231]に従って、オペレーターが定義したデフォルトのパラメーターまたは動作に戻ります。関連付け情報についても同じ手順に従います。 PCEでのセッション終了時に、PCCによって報告されたLSP状態がクリアされると、[RFC8697]に従って関連付け情報もクリアされます。関連付けグループにLSPがない場合、関連付けは削除されたと見なされます。
As per the processing rules specified in Section 6.4 of [RFC8697], if a PCEP speaker does not support this Path Protection Association Type, it would return a PCErr message with Error-Type 26 "Association Error" and Error-Value 1 "Association type is not supported".
[RFC8697]のセクション6.4で指定されている処理ルールに従って、PCEPスピーカーがこのUPSR関連付けタイプをサポートしていない場合、エラータイプ26「関連付けエラー」およびエラー値1「関連付けタイプ」のPCErrメッセージを返します。はサポートされていません。」
All LSPs (working or protection) within a PPAG MUST belong to the same TE tunnel (as described in [RFC3209]) and have the same source and destination. If a PCEP speaker attempts to add or update an LSP to a PPAG and the Tunnel ID (as carried in the LSP-IDENTIFIERS TLV [RFC8231], with a description as per [RFC3209]) or source or destination of the LSP is different from the LSP(s) in the PPAG, the PCEP speaker MUST send PCErr with Error-Type 26 (Association Error) [RFC8697] and Error-Value 9 (Tunnel ID or endpoints mismatch for Path Protection Association). In case of Path Protection, an LSP-IDENTIFIERS TLV SHOULD be included for all LSPs (including Segment Routing (SR) [RFC8664]). If the Protection Type (PT) (in the Path Protection Association TLV) is different from the LSPs in the PPAG, the PCEP speaker MUST send PCErr with Error-Type 26 (Association Error) [RFC8697] and Error-Value 6 (Association information mismatch) as per [RFC8697].
PPAG内のすべてのLSP（動作または保護）は（[RFC3209]で説明されているように）同じTEトンネルに属し、同じ送信元と宛先を持っている必要があります。 PCEPスピーカーがLSPをPPAGおよびトンネルIDに追加または更新しようとした場合（LSP-IDENTIFIERS TLV [RFC8231]で運ばれ、[RFC3209]による説明付き）またはLSPのソースまたは宛先が異なる場合PPAGのLSP、PCEPスピーカーは、エラータイプ26（アソシエーションエラー）[RFC8697]およびエラー値9（パス保護アソシエーションのトンネルIDまたはエンドポイントの不一致）を含むPCErrを送信する必要があります。パス保護の場合は、LSP-IDENTIFIERS TLVをすべてのLSP（セグメントルーティング（SR）[RFC8664]を含む）に含める必要があります（SHOULD）。 （Path Protection Association TLVの）保護タイプ（PT）がPPAGのLSPと異なる場合、PCEPスピーカーはエラータイプ26（アソシエーションエラー）[RFC8697]およびエラー値6（アソシエーション情報）でPCErrを送信する必要があります不一致）[RFC8697]による。
When the PCEP peer does not support the protection type set in PPAG, the PCEP peer MUST send PCErr with Error-Type 26 (Association Error) [RFC8697] and Error-Value 11 (Protection type is not supported).
PCEPピアがPPAGで設定された保護タイプをサポートしない場合、PCEPピアはPCErrをエラータイプ26（アソシエーションエラー）[RFC8697]およびエラー値11（保護タイプはサポートされていません）で送信する必要があります。
A given LSP MAY belong to more than one PPAG. If there is a conflict between any of the two PPAGs, the PCEP peer MUST send PCErr with Error-Type 26 (Association Error) [RFC8697] and Error-Value 6 (Association information mismatch) as per [RFC8697].
特定のLSPは複数のPPAGに属してもよい（MAY）。 2つのPPAGのいずれかに競合がある場合、PCEPピアは[RFC8697]に従って、エラータイプ26（関連付けエラー）[RFC8697]およびエラー値6（関連付け情報の不一致）を含むPCErrを送信する必要があります。
When the protection type is set to 1+1 (i.e., protection type=0x08 or 0x10), there MUST be at maximum only one working LSP and one protection LSP within a PPAG. If a PCEP speaker attempts to add another working/protection LSP, the PCEP peer MUST send PCErr with Error-Type 26 (Association Error) [RFC8697] and Error-Value 10 (Attempt to add another working/protection LSP for Path Protection Association).
保護タイプが1 + 1に設定されている場合（つまり、保護タイプ= 0x08または0x10）、PPAG内には最大で1つの作業LSPと1つの保護LSPのみが存在する必要があります。 PCEPスピーカーが別の現用/保護LSPを追加しようとする場合、PCEPピアはエラータイプ26（アソシエーションエラー）[RFC8697]およびエラー値10（パス保護アソシエーション用に別の現用/保護LSPを追加しようとする）のPCErrを送信する必要があります。
When the protection type is set to 1:N (i.e., protection type=0x04), there MUST be at maximum only one protection LSP, and the number of working LSPs MUST NOT be more than N within a PPAG. If a PCEP speaker attempts to add another working/protection LSP, the PCEP peer MUST send PCErr with Error-Type 26 (Association Error) [RFC8697] and Error-Value 10 (Attempt to add another working/protection LSP for Path Protection Association).
保護タイプが1：Nに設定されている場合（つまり、保護タイプ= 0x04）、保護LSPは最大で1つだけである必要があり、機能しているLSPの数はPPAG内でNを超えてはなりません。 PCEPスピーカーが別の現用/保護LSPを追加しようとする場合、PCEPピアはエラータイプ26（アソシエーションエラー）[RFC8697]およびエラー値10（パス保護アソシエーション用に別の現用/保護LSPを追加しようとする）のPCErrを送信する必要があります。
During the make-before-break (MBB) procedure, two paths will briefly coexist. The error handling related to the number of LSPs allowed in a PPAG MUST NOT be applied during MBB.
make-before-break（MBB）の手順では、2つのパスが一時的に共存します。 PPAGで許可されるLSPの数に関連するエラー処理は、MBB中に適用してはなりません（MUST NOT）。
All processing as per [RFC8697] continues to apply.
[RFC8697]によるすべての処理が引き続き適用されます。
The working and protection LSPs are typically resource disjoint (e.g., node, Shared Risk Link Group [SRLG] disjoint). This ensures that a single failure will not affect both the working and protection LSPs. The disjoint requirement for a group of LSPs is handled via another Association type called "Disjointness Association" as described in [PCEP-LSP-EXT]. The diversity requirements for the protection LSP are also handled by including both ASSOCIATION objects identifying both the protection association group and the disjoint association group for the group of LSPs. The relationship between the Synchronization VECtor (SVEC) object and the Disjointness Association is described in Section 5.4 of [PCEP-LSP-EXT].
ワーキングLSPとプロテクションLSPは通常、リソースの分離（ノード、共有リスクリンクグループ[SRLG]の分離）などです。これにより、単一の障害が現用LSPと保護LSPの両方に影響を与えることがなくなります。 [PCEP-LSP-EXT]で説明されているように、LSPのグループのばらばらの要件は、「ばらばらの関連付け」と呼ばれる別の関連付けタイプを介して処理されます。保護LSPのダイバーシティ要件は、LSPのグループの保護アソシエーショングループとディスジョイントアソシエーショングループの両方を識別する両方のASSOCIATIONオブジェクトを含めることによっても処理されます。 Synchronization VECtor（SVEC）オブジェクトとDisjointness Associationの間の関係は、[PCEP-LSP-EXT]のセクション5.4で説明されています。
[RFC4872] introduces the concept and mechanisms to support the association of one LSP to another LSP across different RSVP Traffic Engineering (RSVP-TE) sessions using the ASSOCIATION and PROTECTION object. The information in the Path Protection Association TLV in PCEP as received from the PCE is used to trigger the signaling of the working LSP and protection LSP, with the Path Protection Association Flags mapped to the corresponding fields in the PROTECTION object in RSVP-TE.
[RFC4872]では、ASSOCIATIONおよびPROTECTIONオブジェクトを使用して、さまざまなRSVPトラフィックエンジニアリング（RSVP-TE）セッション全体で、あるLSPから別のLSPへの関連付けをサポートする概念とメカニズムを紹介しています。 PCEから受信したPCEPのUPSR TLVの情報は、RSVP-TEのPROTECTIONオブジェクトの対応するフィールドにマッピングされたUPSRフラグを使用して、現用LSPおよび保護LSPのシグナリングをトリガーするために使用されます。
This document defines a new Association type, originally defined in [RFC8697], for path protection. IANA has assigned new value in the "ASSOCIATION Type Field" subregistry (created by [RFC8697]) as follows:
このドキュメントは、パス保護のために、元々[RFC8697]で定義された新しいアソシエーションタイプを定義します。 IANAは、[ASSOCIATION Type Field]サブレジストリ（[RFC8697]によって作成）に次のように新しい値を割り当てました。
+------+-----------------------------+-----------+
| Type | Name | Reference |
+======+=============================+===========+
| 1 | Path Protection Association | RFC 8745 |
+------+-----------------------------+-----------+
Table 1: ASSOCIATION Type Field
表1：ASSOCIATIONタイプフィールド
This document defines a new TLV for carrying the additional information of LSPs within a path protection association group. IANA has assigned a new value in the "PCEP TLV Type Indicators" subregistry as follows:
このドキュメントでは、UPSRアソシエーショングループ内のLSPの追加情報を伝送するための新しいTLVを定義しています。 IANAは、「PCEP TLVタイプインジケーター」サブレジストリに次の新しい値を割り当てました。
+-------+---------------------------------------+-----------+
| Value | Description | Reference |
+=======+=======================================+===========+
| 38 | Path Protection Association Group TLV | RFC 8745 |
+-------+---------------------------------------+-----------+
Table 2: PCEP TLV Type Indicators
表2：PCEP TLVタイプインジケーター
Per this document, a new subregistry named "Path protection Association Group TLV Flag Field" has been created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field in the Path Protection Association Group TLV. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
このドキュメントに従って、「Path Protection Association Group TLV Flag Field」という名前の新しいサブレジストリが「Path Computation Element Protocol（PCEP）Numbers」レジストリ内に作成され、Path Protection Association Group TLVのFlagフィールドを管理します。新しい値は、標準アクション[RFC8126]によって割り当てられます。各ビットは、次の品質で追跡する必要があります。
* Bit number (count from 0 as the most significant bit)
* ビット番号（0から最上位ビットとしてカウント）
* Name of the flag
* 旗の名前
* Reference
* 参照
+------+-----------------------+-----------+
| Bit | Name | Reference |
+======+=======================+===========+
| 31 | P - PROTECTION-LSP | RFC 8745 |
+------+-----------------------+-----------+
| 30 | S - SECONDARY-LSP | RFC 8745 |
+------+-----------------------+-----------+
| 6-29 | Unassigned | RFC 8745 |
+------+-----------------------+-----------+
| 0-5 | Protection Type Flags | RFC 8745 |
+------+-----------------------+-----------+
Table 3: Path Protection Association Group TLV Flag Field
表3：UPSRアソシエーショングループのTLVフラグフィールド
This document defines new Error-Values related to path protection association for Error-type 26 "Association Error" defined in [RFC8697]. IANA has allocated new error values within the "PCEP-ERROR Object Error Types and Values" subregistry of the PCEP Numbers registry as follows:
このドキュメントでは、[RFC8697]で定義されているエラータイプ26「アソシエーションエラー」のUPSRアソシエーションに関連する新しいエラー値を定義しています。 IANAは、PCEP番号レジストリの「PCEP-ERRORオブジェクトエラータイプと値」サブレジストリ内に、次のように新しいエラー値を割り当てました。
+------------+-------------+---------------------------+-----------+
| Error-Type | Meaning | Error-value | Reference |
+============+=============+===========================+===========+
| 26 | Association | | [RFC8697] |
| | Error | | |
+------------+-------------+---------------------------+-----------+
| | | 9: Tunnel ID or endpoints | RFC 8745 |
| | | mismatch for Path | |
| | | Protection Association | |
+------------+-------------+---------------------------+-----------+
| | | 10: Attempt to add | RFC 8745 |
| | | another working/ | |
| | | protection LSP for Path | |
| | | Protection Association | |
+------------+-------------+---------------------------+-----------+
| | | 11: Protection type is | RFC 8745 |
| | | not supported | |
+------------+-------------+---------------------------+-----------+
Table 4: PCEP-ERROR Object Error Types and Values
表4：PCEP-ERRORオブジェクトのエラータイプと値
The security considerations described in [RFC8231], [RFC8281], and [RFC5440] apply to the extensions described in this document as well. Additional considerations related to associations where a malicious PCEP speaker could be spoofed and could be used as an attack vector by creating associations are described in [RFC8697]. Adding a spurious protection LSP to the Path Protection Association group could give a false sense of network reliability, which leads to issues when the working LSP is down and the protection LSP fails as well. 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.
[RFC8231]、[RFC8281]、および[RFC5440]で説明されているセキュリティの考慮事項は、このドキュメントで説明されている拡張機能にも適用されます。悪意のあるPCEPスピーカーが偽装され、関連付けを作成することにより攻撃ベクトルとして使用される可能性がある関連付けに関する追加の考慮事項は、[RFC8697]で説明されています。パス保護アソシエーショングループに偽の保護LSPを追加すると、ネットワークの信頼性が誤って認識される可能性があり、動作中のLSPがダウンしていて、保護LSPも失敗した場合に問題が発生します。したがって、BCP 195 [RFC7525]の推奨事項と現在のベストプラクティスに従って、トランスポート層セキュリティ（TLS）[RFC8253]を使用してPCEPセッションを保護することをお勧めします。
Mechanisms defined in this document do not imply any control or policy requirements in addition to those already listed in [RFC5440], [RFC8231], and [RFC8281].
このドキュメントで定義されているメカニズムは、[RFC5440]、[RFC8231]、および[RFC8281]にすでにリストされているメカニズムに加えて、制御またはポリシーの要件を意味するものではありません。
[RFC7420] describes the PCEP MIB; there are no new MIB Objects for this document.
[RFC7420]はPCEP MIBについて説明しています。このドキュメントの新しいMIBオブジェクトはありません。
The PCEP YANG module [PCEP-YANG] supports associations.
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], [RFC8231], and [RFC8281].
このドキュメントで定義されているメカニズムは、[RFC5440]、[RFC8231]、および[RFC8281]にすでにリストされているものに加えて、新しい活性検出および監視の要件を意味するものではありません。
Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440], [RFC8231], and [RFC8281].
このドキュメントで定義されているメカニズムは、[RFC5440]、[RFC8231]、および[RFC8281]にすでにリストされているものに加えて、新しい動作検証要件を意味するものではありません。
Mechanisms defined in this document do not imply any new requirements on other protocols.
このドキュメントで定義されているメカニズムは、他のプロトコルに対する新しい要件を意味するものではありません。
Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440], [RFC8231], and [RFC8281].
このドキュメントで定義されているメカニズムは、[RFC5440]、[RFC8231]、および[RFC8281]にすでにリストされているメカニズムに加えて、ネットワーク操作に影響を与えません。
[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>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。
[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>。
[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、March 2009、<https://www.rfc-editor.org/info/rfc5440>
[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>。
[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>。
[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>。
[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）拡張」 Switched Paths（LSPs）」、RFC 8697、DOI 10.17487 / RFC8697、2020年1月、<https://www.rfc-editor.org/info/rfc8697>。
[PCEP-LSP-EXT] 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>.
[PCEP-LSP-EXT] Litkowski、S.、Sivabalan、S.、Barth、C。、およびM. Negi、「LSP Diversity Constraint SignalingのPath Computation Element Communication Protocol（PCEP）Extension」、Work in Progress、Internet-ドラフト、draft-ietf-pce-association-diversity-14、2020年1月26日、<https://tools.ietf.org/html/draft-ietf-pce-association-diversity-14>。
[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-13, 31 October 2019, <https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13>.
[PCEP-YANG] Dhody、D.、Hardwick、J.、Beeram、V。、およびJ. Tantsura、「パス計算要素通信プロトコル（PCEP）のYANGデータモデル」、作業中、インターネットドラフト、ドラフト-ietf-pce-pcep-yang-13、2019年10月31日、<https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13>。
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, DOI 10.17487/RFC4427, March 2006, <https://www.rfc-editor.org/info/rfc4427>.
[RFC4427]マニー、E、エド。およびD. Papadimitriou、Ed。、「Recovery（Protection and Restoration）Terminology for Generalized Multi-Protocol Label Switching（GMPLS）」、RFC 4427、DOI 10.17487 / RFC4427、2006年3月、<https：//www.rfc-editor。 org / info / rfc4427>。
[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>。
[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>。
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014, <https://www.rfc-editor.org/info/rfc7420>.
[RFC7420] Koushik、A.、Stephan、E.、Zhao、Q.、King、D。、およびJ. Hardwick、「Path Computation Element Communication Protocol（PCEP）Management Information Base（MIB）Module」、RFC 7420、DOI 10.17487 / RFC7420、2014年12月、<https://www.rfc-editor.org/info/rfc7420>。
[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、編、「Stateful Path Computation Element（PCE）の適用性」、RFC 8051、DOI 10.17487 / RFC8051、2017年1月、<https://www.rfc-editor.org/info/rfc8051>。
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", RFC 8664, DOI 10.17487/RFC8664, December 2019, <https://www.rfc-editor.org/info/rfc8664>.
[RFC8664] Sivabalan、S.、Filsfils、C.、Tantsura、J.、Henderickx、W.、and J. Hardwick、 "Path Computation Element Communication Protocol（PCEP）Extensions for Segment Routing"、RFC 8664、DOI 10.17487 / RFC8664 、2019年12月、<https://www.rfc-editor.org/info/rfc8664>。
[STATE-PCE-SYNC] Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter Stateful Path Computation Element (PCE) Communication Procedures.", Work in Progress, Internet-Draft, draft-litkowski-pce-state-sync-07, 11 January 2020, <https://tools.ietf.org/html/draft-litkowski-pce-state-sync-07>.
[STATE-PCE-SYNC] Litkowski、S.、Sivabalan、S.、Li、C。、およびH. Zheng、「Inter Stateful Path Computation Element（PCE）Communication Procedures。」、Work in Progress、Internet-Draft、draft -litkowski-pce-state-sync-07、2020年1月11日、<https://tools.ietf.org/html/draft-litkowski-pce-state-sync-07>。
Acknowledgments
謝辞
We would like to thank Jeff Tantsura, Xian Zhang, and Greg Mirsky for their contributions to this document.
このドキュメントへの貢献に対して、Jeff Tantsura、Xian Zhang、およびGreg Mirskyに感謝します。
Thanks to Ines Robles for the RTGDIR review.
RTGDIRのレビューをしてくれたInes Roblesに感謝します。
Thanks to Pete Resnick for the GENART review.
GENARTのレビューをしてくれたPete Resnickに感謝します。
Thanks to Donald Eastlake for the SECDIR review.
SECDIRレビューを提供してくれたDonald Eastlakeに感謝します。
Thanks to Barry Leiba, Benjamin Kaduk, Éric Vyncke, and Roman Danyliw for the IESG review.
IESGのレビューを提供してくれたBarry Leiba、Benjamin Kaduk、ÉricVyncke、Roman Danyliwに感謝します。
Contributors
貢献者
Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore 560066 Karnataka India
Dhruv Dhodoi Huawei Technologies Divyashari Techno Park、Whitfished Bangalore 2008 Karnataka India
Email: dhruv.ietf@gmail.com
Raveendra Torvi Juniper Networks 1194 N Mathilda Ave Sunnyvale, CA 94086 United States of America
Raveendra Torvi Juniper Networks 1194 N Mathilda Ave Sunnyvale、CA 94086アメリカ合衆国
Email: rtorvi@juniper.net
Edward Crabbe Individual Contributor
Edward Crabbe個人貢献者
Email: edward.crabbe@gmail.com
Authors' Addresses
著者のアドレス
Hariharan Ananthakrishnan Netflix United States of America
Hariharan Ananthakrishnan Netflixアメリカ合衆国
Email: hari@netflix.com
Siva Sivabalan Cisco 2000 Innovation Drive Kanata Ontario K2K 3E8 Canada
Civa Sivabalan Cisco T00イノベーションドライブカナダオンタリオK2K3A ৮カナダ
Email: msiva@cisco.com
Colby Barth Juniper Networks 1194 N Mathilda Ave Sunnyvale, CA 94086 United States of America
Colby Barth Juniper Networks 1194 N Mathilda Aveサニーベール、カリフォルニア州94086アメリカ合衆国
Email: cbarth@juniper.net
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
Mahendra Singh Negi Huawei Technologies Divyashree Techno Park, Whitefield Bangalore 560066 Karnataka India
Mahendra Singh Negi Huawei Technologies Divyashree Techno Park、Whitefield Bangaloreインド56008カルナータカ州
Email: mahend.ietf@gmail.com