[要約] RFC 8306は、PCEPを拡張し、ポイントツーマルチポイントトラフィックエンジニアリングのラベルスイッチパスをサポートするためのものです。目的は、PCEPを使用してポイントツーマルチポイントLSPの設定と制御を効率化することです。
Internet Engineering Task Force (IETF) Q. Zhao
Request for Comments: 8306 D. Dhody, Ed.
Obsoletes: 6006 R. Palleti
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 D. King
Old Dog Consulting
November 2017
Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
ポイントツーマルチポイントトラフィックエンジニアリングラベルスイッチドパス用のパス計算要素通信プロトコル（PCEP）の拡張
Abstract
概要
Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.
ポイントツーポイントマルチプロトコルラベルスイッチング（MPLS）および汎用MPLS（GMPLS）トラフィックエンジニアリングラベルスイッチドパス（TE LSP）は、シグナリング技術を使用して確立できますが、最初にそれらのパスを決定する必要があります。パス計算エレメント（PCE）は、ポイントツーマルチポイント（P2MP）TE LSPのパスを決定するための適切なテクノロジーとして識別されています。
This document describes extensions to the PCE Communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs.
このドキュメントでは、P2MP TE LSPのパスの計算に関する要求と応答を処理するためのPCE通信プロトコル（PCEP）の拡張について説明します。
This document obsoletes RFC 6006.
このドキュメントはRFC 6006を廃止します。
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/rfc8306.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8306で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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に記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Requirements Language ......................................5
2. PCC-PCE Communication Requirements ..............................5
3. Protocol Procedures and Extensions ..............................6
3.1. P2MP Capability Advertisement ..............................7
3.1.1. IGP Extensions for P2MP Capability Advertisement ....7
3.1.2. Open Message Extension ..............................7
3.2. Efficient Presentation of P2MP LSPs ........................8
3.3. P2MP Path Computation Request/Reply Message Extensions .....9
3.3.1. The Extension of the RP Object ......................9
3.3.2. The P2MP END-POINTS Object .........................11
3.4. Request Message Format ....................................13
3.5. Reply Message Format ......................................15
3.6. P2MP Objective Functions and Metric Types .................16
3.6.1. Objective Functions ................................16
3.6.2. METRIC Object-Type Values ..........................17
3.7. Non-Support of P2MP Path Computation ......................17
3.8. Non-Support by Back-Level PCE Implementations .............17
3.9. P2MP TE Path Reoptimization Request .......................17
3.10. Adding and Pruning Leaves to/from the P2MP Tree ..........18
3.11. Discovering Branch Nodes .................................22
3.11.1. Branch Node Object ................................22
3.12. Synchronization of P2MP TE Path Computation Requests .....22
3.13. Request and Response Fragmentation .......................23
3.13.1. Request Fragmentation Procedure ...................24
3.13.2. Response Fragmentation Procedure ..................24
3.13.3. Fragmentation Example .............................24
3.14. UNREACH-DESTINATION Object ...............................25
3.15. P2MP PCEP-ERROR Objects and Types ........................27
3.16. PCEP NO-PATH Indicator ...................................28
4. Manageability Considerations ...................................28
4.1. Control of Function and Policy ............................28
4.2. Information and Data Models ...............................28
4.3. Liveness Detection and Monitoring .........................29
4.4. Verifying Correct Operation ...............................29
4.5. Requirements for Other Protocols and Functional
Components ................................................29
4.6. Impact on Network Operation ...............................29
5. Security Considerations ........................................30
6. IANA Considerations ............................................31
6.1. PCEP TLV Type Indicators ..................................31
6.2. Request Parameter Bit Flags ...............................31
6.3. Objective Functions .......................................31
6.4. METRIC Object-Type Values .................................32
6.5. PCEP Objects ..............................................32
6.6. PCEP-ERROR Objects and Types ..............................34
6.7. PCEP NO-PATH Indicator ....................................35
6.8. SVEC Object Flag ..........................................35
6.9. OSPF PCE Capability Flag ..................................35
7. References .....................................................36
7.1. Normative References ......................................36
7.2. Informative References ....................................37
Appendix A. Summary of Changes from RFC 6006 ......................39
Appendix A.1. RBNF Changes from RFC 6006 ..........................39
Acknowledgements ..................................................41
Contributors ......................................................42
Authors' Addresses ................................................43
The Path Computation Element (PCE) as defined in [RFC4655] is an entity that is capable of computing a network path or route based on a network graph and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed.
[RFC4655]で定義されているパス計算要素（PCE）は、ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算制約を適用できるエンティティです。パス計算クライアント（PCC）は、パスを計算するようにPCEに要求する場合があります。
[RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
[RFC4875]は、マルチプロトコルラベルスイッチング（MPLS）および汎用MPLS（GMPLS）ネットワークで使用するポイントツーマルチポイント（P2MP）トラフィックエンジニアリングラベルスイッチドパス（TE LSP）を設定する方法を説明しています。
The PCE has been identified as a suitable application for the computation of paths for P2MP TE LSPs [RFC5671].
PCEは、P2MP TE LSP [RFC5671]のパスの計算に適したアプリケーションとして識別されています。
The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs for point-to-point (P2P) path computations and is defined in [RFC5440]. However, that specification does not provide a mechanism to request path computation of P2MP TE LSPs.
PCE通信プロトコル（PCEP）は、ポイントツーポイント（P2P）パス計算のためのPCCとPCE間の通信プロトコルとして設計されており、[RFC5440]で定義されています。ただし、その仕様では、P2MP TE LSPのパス計算を要求するメカニズムは提供されていません。
A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between ingress and egress Label Switching Routers (LSRs) and are appropriately overlaid to construct a P2MP TE LSP. During path computation, the P2MP TE LSP may be determined as a set of S2L sub-LSPs that are computed separately and combined to give the path of the P2MP LSP, or the entire P2MP TE LSP may be determined as a P2MP tree in a single computation.
P2MP LSPは、複数のソースからリーフ（S2L）サブLSPで構成されます。これらのS2LサブLSPは、入力と出力のラベルスイッチングルーター（LSR）の間に設定され、適切にオーバーレイされてP2MP TE LSPを構築します。パスの計算中、P2MP TE LSPは、個別に計算されて結合されてP2MP LSPのパスを与えるS2LサブLSPのセットとして決定されるか、またはP2MP TE LSP全体が単一のP2MPツリーとして決定されます。計算。
This document relies on the mechanisms of PCEP to request path computation for P2MP TE LSPs. One Path Computation Request message from a PCC may request the computation of the whole P2MP TE LSP, or the request may be limited to a subset of the S2L sub-LSPs. In the extreme case, the PCC may request the S2L sub-LSPs to be computed individually; the PCC is responsible for deciding whether to signal individual S2L sub-LSPs or combine the computation results to signal the entire P2MP TE LSP. Hence, the PCC may use one Path Computation Request message or may split the request across multiple path computation messages.
このドキュメントは、P2MP TE LSPのパス計算を要求するPCEPのメカニズムに依存しています。 PCCからの1つのパス計算要求メッセージは、P2MP TE LSP全体の計算を要求するか、要求がS2LサブLSPのサブセットに制限される場合があります。極端な場合、PCCはS2LサブLSPを個別に計算するよう要求する場合があります。 PCCは、個々のS2LサブLSPをシグナリングするか、計算結果を組み合わせてP2MP TE LSP全体をシグナリングするかを決定します。したがって、PCCは1つのパス計算要求メッセージを使用するか、要求を複数のパス計算メッセージに分割します。
This document obsoletes [RFC6006] and incorporates the following errata:
このドキュメントは[RFC6006]を廃止し、次のエラッタを組み込んでいます：
o Erratum IDs 3819, 3830, 3836, 4867, and 4868 for [RFC6006]
o [RFC6006]のエラッタID 3819、3830、3836、4867、および4868
o Erratum ID 4956 for [RFC5440]
o [RFC5440]のエラッタID 4956
All changes from [RFC6006] are listed in Appendix A.
[RFC6006]からのすべての変更は、付録Aにリストされています。
Terminology used in this document:
このドキュメントで使用される用語：
TE LSP: Traffic Engineering Label Switched Path.
TE LSP：トラフィックエンジニアリングラベルスイッチドパス。
LSR: Label Switching Router.
LSR：ラベルスイッチングルーター。
OF: Objective Function. A set of one or more optimization criteria used for the computation of a single path (e.g., path cost minimization) or for the synchronized computation of a set of paths (e.g., aggregate bandwidth consumption minimization).
OF：目的関数。単一のパスの計算（パスコストの最小化など）、またはパスのセットの同期計算（帯域幅の総消費量の最小化）に使用される1つ以上の最適化基準のセット。
P2MP: Point-to-Multipoint.
P2MP：ポイントツーマルチポイント。
P2P: Point-to-Point.
P2P：ポイントツーポイント。
This document also uses the terminology defined in [RFC4655], [RFC4875], and [RFC5440].
このドキュメントでは、[RFC4655]、[RFC4875]、および[RFC5440]で定義されている用語も使用しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This section summarizes the PCC-PCE communication requirements as met by the protocol extension specified in this document for P2MP MPLS-TE LSPs. The numbering system in the list below corresponds to the requirement numbers (e.g., R1, R2) used in [RFC5862].
このセクションでは、P2MP MPLS-TE LSPについて、このドキュメントで指定されているプロトコル拡張が満たすPCC-PCE通信要件をまとめています。以下のリストの番号付けシステムは、[RFC5862]で使用されている要件番号（R1、R2など）に対応しています。
1. The PCC MUST be able to specify that the request is a P2MP path computation request.
1. PCCは、要求がP2MPパス計算要求であることを指定できる必要があります。
2. The PCC MUST be able to specify that objective functions are to be applied to the P2MP path computation request.
2. PCCは、目的関数がP2MPパス計算要求に適用されることを指定できなければなりません（MUST）。
3. The PCE MUST have the capability to reject a P2MP path computation request and indicate non-support of P2MP path computation.
3. PCEは、P2MPパス計算要求を拒否し、P2MPパス計算がサポートされていないことを示す機能を備えている必要があります。
4. The PCE MUST provide an indication of non-support of P2MP path computation by back-level PCE implementations.
4. PCEは、バックレベルのPCE実装によるP2MPパス計算の非サポートの指示を提供する必要があります。
5. A P2MP path computation request MUST be able to list multiple destinations.
5. P2MPパス計算リクエストは、複数の宛先をリストできる必要があります。
6. A P2MP path computation response MUST be able to carry the path of a P2MP LSP.
6. P2MPパス計算応答は、P2MP LSPのパスを伝送できる必要があります。
7. By default, the path returned by the PCE SHOULD use the compressed format.
7. デフォルトでは、PCEによって返されるパスは圧縮形式を使用する必要があります（SHOULD）。
8. It MUST be possible for a single P2MP path computation request or response to be conveyed by a sequence of messages.
8. 単一のP2MPパス計算要求または応答が一連のメッセージによって伝達されることが可能でなければなりません（MUST）。
9. It MUST NOT be possible for a single P2MP path computation request to specify a set of different constraints, traffic parameters, or quality-of-service requirements for different destinations of a P2MP LSP.
9. 単一のP2MPパス計算要求で、P2MP LSPの異なる宛先に対する一連の異なる制約、トラフィックパラメータ、またはサービス品質要件を指定することはできません。
10. P2MP path modification and P2MP path diversity MUST be supported.
10. P2MPパス変更とP2MPパスダイバーシティをサポートする必要があります。
11. It MUST be possible to reoptimize existing P2MP TE LSPs.
11. 既存のP2MP TE LSPを再最適化できる必要があります。
12. It MUST be possible to add and remove P2MP destinations from existing paths.
12. 既存のパスからP2MP宛先を追加および削除できる必要があります。
13. It MUST be possible to specify a list of applicable branch nodes to use when computing the P2MP path.
13. P2MPパスを計算するときに使用する適切なブランチノードのリストを指定できる必要があります。
14. It MUST be possible for a PCC to discover P2MP path computation capability.
14. PCCがP2MPパス計算機能を発見できるようにする必要があります。
15. The PCC MUST be able to request diverse paths when requesting a P2MP path.
15. PCCは、P2MPパスを要求するときに、多様なパスを要求できる必要があります。
The following section describes the protocol extensions required to satisfy the requirements specified in Section 2 ("PCC-PCE Communication Requirements") of this document.
次のセクションでは、このドキュメントのセクション2（「PCC-PCE通信要件」）で指定された要件を満たすために必要なプロトコル拡張について説明します。
[RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF Router Information Link State Advertisement (LSA) as defined in [RFC7770] to facilitate PCE discovery using OSPF. [RFC5088] specifies that no new sub-TLVs may be added to the PCED TLV. This document defines a flag in the OSPF PCE Capability Flags to indicate the capability of P2MP computation.
[RFC5088]は、OSPFを使用したPCE検出を容易にするために、[RFC7770]で定義されているように、OSPFルーター情報リンク状態アドバタイズメント（LSA）で伝送されるPCE検出（PCED）TLVを定義します。 [RFC5088]は、PCED TLVに新しいサブTLVを追加できないことを指定しています。このドキュメントでは、OSPF PCE機能フラグのフラグを定義して、P2MP計算の機能を示します。
Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE discovery using IS-IS. This document will use the same flag for the OSPF PCE Capability Flags sub-TLV to allow IS-IS to indicate the capability of P2MP computation.
同様に、[RFC5089]は、IS-ISを使用したPCEディスカバリで使用するPCEDサブTLVを定義しています。このドキュメントでは、OSPF PCE機能フラグサブTLVに同じフラグを使用して、IS-ISがP2MP計算の機能を示すことができるようにします。
The IANA assignment for a shared OSPF and IS-IS P2MP Capability Flag is documented in Section 6.9 ("OSPF PCE Capability Flag") of this document.
共有されたOSPFおよびIS-IS P2MP機能フラグのIANA割り当てについては、このドキュメントのセクション6.9（「OSPF PCE機能フラグ」）に記載されています。
PCEs wishing to advertise that they support P2MP path computation would set the bit (10) accordingly. PCCs that do not understand this bit will ignore it (per [RFC5088] and [RFC5089]). PCEs that do not support P2MP will leave the bit clear (per the default behavior defined in [RFC5088] and [RFC5089]).
P2MPパス計算をサポートすることをアドバタイズするPCEは、それに応じてビット（10）を設定します。このビットを理解しないPCCはそれを無視します（[RFC5088]および[RFC5089]による）。 P2MPをサポートしないPCEは、ビットをクリアしたままにします（[RFC5088]および[RFC5089]で定義されているデフォルトの動作に従って）。
PCEs that set the bit to indicate support of P2MP path computation MUST follow the procedures in Section 3.3.2 ("The P2MP END-POINTS Object") to further qualify the level of support.
P2MPパス計算のサポートを示すビットを設定するPCEは、セクション3.3.2（「P2MP END-POINTSオブジェクト」）の手順に従って、サポートのレベルをさらに限定する必要があります。
Based on the Capabilities Exchange requirement described in [RFC5862], if a PCE does not advertise its P2MP capability during discovery, PCEP should be used to allow a PCC to discover, during the Open Message Exchange, which PCEs are capable of supporting P2MP path computation.
[RFC5862]で説明されている機能交換要件に基づいて、PCEがディスカバリー中にP2MP機能をアドバタイズしない場合、PCEPを使用して、PCCがOpen Message Exchange中に、どのPCEがP2MPパス計算をサポートできるかを発見できるようにする必要があります。 。
To satisfy this requirement, we extend the PCEP OPEN object by defining an optional TLV to indicate the PCE's capability to perform P2MP path computations.
この要件を満たすために、P2MPパス計算を実行するPCEの機能を示すオプションのTLVを定義して、PCEP OPENオブジェクトを拡張します。
IANA has allocated value 6 from the "PCEP TLV Type Indicators" subregistry, as documented in Section 6.1 ("PCEP TLV Type Indicators"). The description is "P2MP capable", and the length value is 2 bytes. The value field is set to default value 0.
セクション6.1（「PCEP TLVタイプインジケーター」）に記載されているように、IANAは「PCEP TLVタイプインジケーター」サブレジストリから値6を割り当てています。説明は「P2MP対応」で、長さの値は2バイトです。値フィールドはデフォルト値0に設定されています。
The inclusion of this TLV in an OPEN object indicates that the sender can perform P2MP path computations.
このTLVをOPENオブジェクトに含めることは、送信者がP2MPパス計算を実行できることを示しています。
The capability TLV is meaningful only for a PCE, so it will typically appear only in one of the two Open messages during PCE session establishment. However, in the case of PCE cooperation (e.g., inter-domain), when a PCE behaving as a PCC initiates a PCE session it SHOULD also indicate its path computation capabilities.
機能TLVはPCEに対してのみ意味があるため、通常、PCEセッションの確立中に2つのOpenメッセージの1つにのみ表示されます。ただし、PCE連携（ドメイン間など）の場合、PCCとして動作するPCEがPCEセッションを開始するときに、そのパス計算機能も示す必要があります（SHOULD）。
When specifying additional leaves or when optimizing existing P2MP TE LSPs as specified in [RFC5862], it may be necessary to pass existing P2MP LSP route information between the PCC and PCE in the request and reply messages. In each of these scenarios, we need path objects for efficiently passing the existing P2MP LSP between the PCE and PCC.
追加のリーフを指定する場合、または[RFC5862]で指定されているように既存のP2MP TE LSPを最適化する場合、要求および応答メッセージでPCCとPCEの間で既存のP2MP LSPルート情報を渡す必要がある場合があります。これらの各シナリオでは、PCEとPCCの間で既存のP2MP LSPを効率的に渡すためのパスオブジェクトが必要です。
We specify the use of the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions Explicit Route Object (ERO) to encode the explicit route of a TE LSP through the network. PCEP ERO sub-object types correspond to RSVP-TE ERO sub-object types. The format and content of the ERO are defined in [RFC3209] and [RFC3473].
ネットワークを介したTE LSPの明示的なルートをエンコードするために、リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張の明示的ルートオブジェクト（ERO）の使用を指定します。 PCEP EROサブオブジェクトタイプは、RSVP-TE EROサブオブジェクトタイプに対応しています。 EROのフォーマットと内容は、[RFC3209]と[RFC3473]で定義されています。
The Secondary Explicit Route Object (SERO) is used to specify the explicit route of an S2L sub-LSP. The path of each subsequent S2L sub-LSP is encoded in a P2MP_SECONDARY_EXPLICIT_ROUTE object SERO. The format of the SERO is the same as the format of an ERO as defined in [RFC3209] and [RFC3473].
セカンダリ明示ルートオブジェクト（SERO）は、S2LサブLSPの明示ルートを指定するために使用されます。後続の各S2LサブLSPのパスは、P2MP_SECONDARY_EXPLICIT_ROUTEオブジェクトSEROにエンコードされます。 SEROの形式は、[RFC3209]および[RFC3473]で定義されているEROの形式と同じです。
The Secondary Record Route Object (SRRO) is used to record the explicit route of the S2L sub-LSP. The class of the P2MP SRRO is the same as the class of the SRRO as defined in [RFC4873].
セカンダリレコードルートオブジェクト（SRRO）は、S2LサブLSPの明示的なルートを記録するために使用されます。 P2MP SRROのクラスは、[RFC4873]で定義されているSRROのクラスと同じです。
The SERO and SRRO are used to report the route of an existing TE LSP for which a reoptimization is desired. The format and content of the SERO and SRRO are defined in [RFC4875].
SEROおよびSRROは、再最適化が必要な既存のTE LSPのルートを報告するために使用されます。 SEROとSRROのフォーマットと内容は[RFC4875]で定義されています。
PCEP Object-Class and Object-Type values for the SERO and SRRO have been assigned:
SEROおよびSRROのPCEPオブジェクトクラスおよびオブジェクトタイプの値が割り当てられています。
Object-Class Value 29 Name SERO Object-Type 0: Reserved 1: SERO 2-15: Unassigned Reference RFC 8306
オブジェクトクラス値29名前SEROオブジェクトタイプ0：予約済み1：SERO 2-15：未割り当ての参照RFC 8306
Object-Class Value 30 Name SRRO Object-Type 0: Reserved 1: SRRO 2-15: Unassigned Reference RFC 8306
オブジェクトクラス値30名前SRROオブジェクトタイプ0：予約済み1：SRRO 2-15：未割り当ての参照RFC 8306
The IANA assignments are documented in Section 6.5 ("PCEP Objects").
IANAの割り当てについては、セクション6.5（「PCEPオブジェクト」）に記載されています。
Since the explicit path is available for immediate signaling by the MPLS or GMPLS control plane, the meanings of all of the sub-objects and fields in this object are identical to those defined for the ERO.
明示的なパスはMPLSまたはGMPLSコントロールプレーンによる即時シグナリングに使用できるため、このオブジェクトのすべてのサブオブジェクトとフィールドの意味は、EROに定義されたものと同じです。
This document extends the existing P2P RP (Request Parameters) object so that a PCC can signal a P2MP path computation request to the PCE receiving the PCEP request. The END-POINTS object is also extended to improve the efficiency of the message exchange between the PCC and PCE in the case of P2MP path computation.
このドキュメントは、PCCがPCEP要求を受信するPCEにP2MPパス計算要求を通知できるように、既存のP2P RP（要求パラメーター）オブジェクトを拡張します。 END-POINTSオブジェクトも拡張され、P2MPパス計算の場合のPCCとPCE間のメッセージ交換の効率が向上します。
The PCE path computation request and reply messages will need the following additional parameters to indicate to the receiving PCE (1) that the request and reply messages have been fragmented across multiple messages, (2) that they have been requested for a P2MP path, and (3) whether the route is represented in the compressed or uncompressed format.
PCEパス計算要求および応答メッセージには、受信PCEに（1）要求および応答メッセージが複数のメッセージにわたってフラグメント化されていること、（2）P2MPパスに対して要求されていること、および（3）ルートが圧縮形式で表されているか、非圧縮形式で表されているか。
This document adds the following flags to the RP object:
このドキュメントでは、RPオブジェクトに次のフラグを追加します。
The F-bit is added to the flag bits of the RP object to indicate to the receiver that the request is part of a fragmented request or is not a fragmented request.
FビットはRPオブジェクトのフラグビットに追加され、要求がフラグメント化された要求の一部であるか、フラグメント化された要求ではないことを受信者に示します。
o F (RP fragmentation bit - 1 bit):
o F（RPフラグメンテーションビット-1ビット）：
0: This indicates that the RP is not fragmented or it is the last piece of the fragmented RP.
0：これは、RPが断片化されていないか、断片化されたRPの最後のピースであることを示します。
1: This indicates that the RP is fragmented and this is not the last piece of the fragmented RP. The receiver needs to wait for additional fragments until it receives an RP with the same RP-ID and with the F-bit set to 0.
1：これは、RPがフラグメント化されており、フラグメント化されたRPの最後のピースではないことを示しています。受信者は、同じRP-IDとFビットが0に設定されたRPを受信するまで、追加のフラグメントを待つ必要があります。
The N-bit is added in the flag bits field of the RP object to signal the receiver of the message that the request/reply is for P2MP or is not for P2MP.
RPオブジェクトのフラグビットフィールドにNビットが追加され、要求/応答がP2MP用かP2MP用ではないことをメッセージの受信者に通知します。
o N (P2MP bit - 1 bit):
o N（P2MPビット-1ビット）：
0: This indicates that this is not a Path Computation Request (PCReq) or Path Computation Reply (PCRep) message for P2MP.
0：これは、P2MPのパス計算要求（PCReq）またはパス計算応答（PCRep）メッセージではないことを示します。
1: This indicates that this is a PCReq or PCRep message for P2MP.
1：これは、これがP2MPのPCReqまたはPCRepメッセージであることを示します。
The E-bit is added in the flag bits field of the RP object to signal the receiver of the message that the route is in the compressed format or is not in the compressed format. By default, the path returned by the PCE SHOULD use the compressed format.
Eビットは、RPオブジェクトのフラグビットフィールドに追加され、ルートが圧縮形式であるか、または圧縮形式でないことをメッセージの受信者に通知します。デフォルトでは、PCEによって返されるパスは圧縮形式を使用する必要があります（SHOULD）。
o E (ERO-compression bit - 1 bit):
o E（ERO圧縮ビット-1ビット）：
0: This indicates that the route is not in the compressed format.
0：ルートが圧縮形式ではないことを示します。
1: This indicates that the route is in the compressed format.
1：これは、ルートが圧縮形式であることを示します。
The IANA assignments are documented in Section 6.2 ("Request Parameter Bit Flags") of this document.
IANAの割り当ては、このドキュメントのセクション6.2（「リクエストパラメータビットフラグ」）に記載されています。
The END-POINTS object is used in a PCReq message to specify the source IP address and the destination IP address of the path for which a path computation is requested. To represent the end points for a P2MP path efficiently, we define two types of END-POINTS objects for the P2MP path:
END-POINTSオブジェクトはPCReqメッセージで使用され、パス計算が要求されたパスのソースIPアドレスと宛先IPアドレスを指定します。 P2MPパスのエンドポイントを効率的に表すために、P2MPパスの2種類のEND-POINTSオブジェクトを定義します。
o Old leaves whose path can be modified/reoptimized.
o パスを変更/再最適化できる古い葉。
o Old leaves whose path must be left unchanged.
o パスを変更しないでおく必要がある古い葉。
With the P2MP END-POINTS object, the PCE Path Computation Request message is expanded in a way that allows a single request message to list multiple destinations.
P2MP END-POINTSオブジェクトを使用すると、PCEパス計算要求メッセージは、単一の要求メッセージで複数の宛先をリストできるように拡張されます。
In total, there are now four possible types of leaves in a P2MP request:
合計すると、P2MPリクエストには、次の4種類の可能なリーフがあります。
o New leaves to add (leaf type = 1)
o 追加する新しい葉（葉の種類= 1）
o Old leaves to remove (leaf type = 2)
o 削除する古い葉（葉の種類= 2）
o Old leaves whose path can be modified/reoptimized (leaf type = 3)
o パスを変更/再最適化できる古い葉（葉のタイプ= 3）
o Old leaves whose path must be left unchanged (leaf type = 4)
o パスを変更しないでおく必要がある古い葉（葉のタイプ= 4）
A given END-POINTS object gathers the leaves of a given type. The type of leaf in a given END-POINTS object is identified by the END-POINTS object leaf type field.
特定のEND-POINTSオブジェクトは、特定のタイプの葉を収集します。特定のEND-POINTSオブジェクトのリーフのタイプは、END-POINTSオブジェクトのリーフタイプフィールドで識別されます。
Using the P2MP END-POINTS object, the END-POINTS portion of a request message for the multiple destinations can be reduced by up to 50% for a P2MP path where a single source address has a very large number of destinations.
P2MP END-POINTSオブジェクトを使用すると、単一の送信元アドレスに非常に多数の宛先があるP2MPパスの場合、複数の宛先に対する要求メッセージのEND-POINTS部分を最大50％削減できます。
Note that a P2MP path computation request can mix the different types of leaves by including several END-POINTS objects per RP object as shown in the PCReq Routing Backus-Naur Form (RBNF) [RFC5511] format in Section 3.4 ("Request Message Format").
セクション2のPCReq Routing Backus-Naur Form（RBNF）[RFC5511]形式（「リクエストメッセージ形式」）に示すように、P2MPパス計算リクエストは、RPオブジェクトごとにいくつかのEND-POINTSオブジェクトを含めることで、さまざまなタイプのリーフを混在させることができます。 ）。
The format of the P2MP END-POINTS object body for IPv4 (Object-Type 3) is as follows:
IPv4（Object-Type 3）のP2MP END-POINTSオブジェクト本体の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The P2MP END-POINTS Object Body Format for IPv4
図1：IPv4のP2MP END-POINTSオブジェクト本体の形式
The format of the END-POINTS object body for IPv6 (Object-Type 4) is as follows:
IPv6（Object-Type 4）のEND-POINTSオブジェクト本体の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The P2MP END-POINTS Object Body Format for IPv6
図2：IPv6のP2MP END-POINTSオブジェクト本体の形式
The END-POINTS object body has a variable length. These are
END-POINTSオブジェクトの本体は可変長です。これらは
o multiples of 4 bytes for IPv4
o IPv4の4バイトの倍数
o multiples of 16 bytes, plus 4 bytes, for IPv6
o IPv6の場合、16バイトの倍数と4バイト
As per [RFC5440], a Path Computation Request message (also referred to as a PCReq message) is a PCEP message sent by a PCC to a PCE to request a path computation. A PCReq message may carry more than one path computation request.
[RFC5440]のとおり、パス計算要求メッセージ（PCReqメッセージとも呼ばれる）は、パス計算を要求するためにPCCからPCEに送信されるPCEPメッセージです。 PCReqメッセージは、複数のパス計算要求を運ぶ場合があります。
As per [RFC5541], the OF object MAY be carried within a PCReq message. If an objective function is to be applied to a set of synchronized path computation requests, the OF object MUST be carried just after the corresponding SVEC (Synchronization Vector) object and MUST NOT be repeated for each elementary request.
[RFC5541]に従って、OFオブジェクトはPCReqメッセージ内で運ばれるかもしれません。目的関数が同期パス計算要求のセットに適用される場合、OFオブジェクトは対応するSVEC（同期ベクトル）オブジェクトの直後に運ばれなければならず（MUST）、基本要求ごとに繰り返されてはいけません（MUST NOT）。
The PCReq message is encoded as follows using RBNF as defined in [RFC5511].
PCReqメッセージは、[RFC5511]で定義されているRBNFを使用して次のようにエンコードされます。
Below is the message format for the request message:
以下は、要求メッセージのメッセージ形式です。
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
where:
ただし：
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<request-list> ::= <request>[<request-list>]
<request> ::= <RP>
<end-point-rro-pair-list>
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>|<BNC>]
[<LOAD-BALANCING>]
where:
ただし：
<end-point-rro-pair-list> ::=
<END-POINTS>[<RRO-List>[<BANDWIDTH>]]
[<end-point-rro-pair-list>]
<RRO-List> ::= (<RRO>|<SRRO>)[<RRO-List>]
<metric-list> ::= <METRIC>[<metric-list>]
Figure 3: The Message Format for the Request Message
図3：リクエストメッセージのメッセージフォーマット
Note that we preserve compatibility with the definition of <request> provided in [RFC5440]. At least one instance of <END-POINTS> MUST be present in this message.
[RFC5440]で提供されている<request>の定義との互換性を維持していることに注意してください。 <END-POINTS>の少なくとも1つのインスタンスがこのメッセージに存在している必要があります。
We have documented the IANA assignment of additional END-POINTS Object-Type values in Section 6.5 ("PCEP Objects") of this document.
このドキュメントのセクション6.5（「PCEPオブジェクト」）に、追加のEND-POINTSオブジェクトタイプ値のIANA割り当てを文書化しました。
The PCEP Path Computation Reply message (also referred to as a PCRep message) is a PCEP message sent by a PCE to a requesting PCC in response to a previously received PCReq message. PCEP supports the bundling of multiple replies to a set of path computation requests within a single PCRep message.
PCEPパス計算応答メッセージ（PCRepメッセージとも呼ばれます）は、以前に受信したPCReqメッセージに応答して、PCEが要求元のPCCに送信するPCEPメッセージです。 PCEPは、単一のPCRepメッセージ内の一連のパス計算要求に対する複数の応答のバンドルをサポートしています。
The PCRep message is encoded as follows using RBNF as defined in [RFC5511].
PCRepメッセージは、[RFC5511]で定義されているRBNFを使用して次のようにエンコードされます。
Below is the message format for the reply message:
以下は、返信メッセージのメッセージ形式です。
<PCRep Message> ::= <Common Header>
<response-list>
where:
ただし：
<response-list> ::= <response>[<response-list>]
<response> ::= <RP>
[<end-point-path-pair-list>]
[<NO-PATH>]
[<UNREACH-DESTINATION>]
[<attribute-list>]
<end-point-path-pair-list> ::=
[<END-POINTS>]<path>
[<end-point-path-pair-list>]
<path> ::= (<ERO>|<SERO>) [<path>]
where:
ただし：
<attribute-list> ::= [<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
Figure 4: The Message Format for the Reply Message
図4：返信メッセージのメッセージ形式
The optional END-POINTS object in the reply message is used to specify which paths are removed, changed, not changed, or added for the request. The path is only needed for the end points that are added or changed.
応答メッセージ内のオプションのEND-POINTSオブジェクトは、要求に対して削除、変更、変更なし、または追加するパスを指定するために使用されます。パスは、追加または変更されたエンドポイントにのみ必要です。
If the E-bit (ERO-Compress bit) was set to 1 in the request, then the path will be formed by an ERO followed by a list of SEROs.
Eビット（ERO圧縮ビット）が要求で1に設定されている場合、パスはEROとその後に続くSEROのリストによって形成されます。
Note that we preserve compatibility with the definition of <response> provided in [RFC5440] and with the optional <end-point-path-pair-list> and <path>.
[RFC5440]で提供される<response>の定義と、オプションの<end-point-path-pair-list>と<path>との互換性を維持していることに注意してください。
Six objective functions have been defined in [RFC5541] for P2P path computation.
[RFC5541]では、P2Pパス計算用に6つの目的関数が定義されています。
This document defines two additional objective functions -- namely, SPT (Shortest-Path Tree) and MCT (Minimum-Cost Tree) -- that apply to P2MP path computation. Hence, two objective function codes are defined as follows:
このドキュメントでは、P2MPパスの計算に適用されるSPT（最短パスツリー）とMCT（最小コストツリー）の2つの追加目的関数を定義します。したがって、2つの目的関数コードは次のように定義されます。
Objective Function Code: 7
目的関数コード：7
Name: Shortest-Path Tree (SPT)
名前：最短経路ツリー（SPT）
Description: Minimize the maximum source-to-leaf cost with respect to a specific metric or to the TE metric used as the default metric when the metric is not specified (e.g., TE or IGP metric).
説明：特定のメトリック、またはメトリックが指定されていない場合にデフォルトのメトリックとして使用されるTEメトリック（例：TEまたはIGPメトリック）に関して、ソースからリーフまでの最大コストを最小化します。
Objective Function Code: 8
目的関数コード：8
Name: Minimum-Cost Tree (MCT)
名前：最小コストツリー（MCT）
Description: Minimize the total cost of the tree (i.e., the sum of the costs of tree links) with respect to a specific metric or to the TE metric used as the default metric when the metric is not specified.
説明：特定のメトリック、またはメトリックが指定されていない場合にデフォルトメトリックとして使用されるTEメトリックに関して、ツリーの総コスト（つまり、ツリーリンクのコストの合計）を最小化します。
Processing these two objective functions is subject to the rules defined in [RFC5541].
これら2つの目的関数の処理は、[RFC5541]で定義された規則に従います。
There are three types defined for the METRIC object in [RFC5440] -- namely, the IGP metric, the TE metric, and Hop Counts. This document defines three additional types for the METRIC object: the P2MP IGP metric, the P2MP TE metric, and the P2MP hop count metric. They encode the sum of the metrics of all links of the tree. The following values for these metric types have been assigned; see Section 6.4.
[RFC5440]のMETRICオブジェクトには3つのタイプが定義されています。つまり、IGPメトリック、TEメトリック、およびホップカウントです。このドキュメントでは、METRICオブジェクトの3つの追加タイプを定義します。P2MPIGPメトリック、P2MP TEメトリック、およびP2MPホップカウントメトリックです。それらは、ツリーのすべてのリンクのメトリックの合計をエンコードします。これらのメトリックタイプには次の値が割り当てられています。セクション6.4を参照してください。
o P2MP IGP metric: T=8
o P2MP IGPメトリック：T = 8
o P2MP TE metric: T=9
o P2MP TEメトリック：T = 9
o P2MP hop count metric: T=10
o P2MPホップカウントメトリック：T = 10
o If a PCE receives a P2MP path computation request and it understands the P2MP flag in the RP object, but the PCE is not capable of P2MP computation, the PCE MUST send a PCErr message with a PCEP-ERROR object and corresponding Error-value. The request MUST then be cancelled at the PCC. The Error-Types and Error-values have been assigned; see Section 6 ("IANA Considerations") of this document.
o PCEがP2MPパス計算要求を受信し、RPオブジェクトのP2MPフラグを理解しているが、PCEがP2MP計算に対応していない場合、PCEはPCEP-ERRORオブジェクトと対応するエラー値を含むPCErrメッセージを送信する必要があります。その後、PCCで要求をキャンセルする必要があります。エラータイプとエラー値が割り当てられています。このドキュメントのセクション6（「IANAに関する考慮事項」）を参照してください。
o If the PCE does not understand the P2MP flag in the RP object, then the PCE would send a PCErr message with Error-Type=2 (Capability not supported) as per [RFC5440].
o PCEがRPオブジェクトのP2MPフラグを理解しない場合、PCEは[RFC5440]のとおり、Error-Type = 2（サポートされていない機能）のPCErrメッセージを送信します。
If a PCE receives a P2MP request and the PCE does not understand the P2MP flag in the RP object, and therefore the PCEP P2MP extensions, then the PCE SHOULD reject the request.
PCEがP2MP要求を受信し、PCEがRPオブジェクトのP2MPフラグを理解できない場合、したがってPCEP P2MP拡張機能を理解しない場合、PCEは要求を拒否する必要があります（SHOULD）。
A reoptimization request for a P2MP TE path is specified by the use of the R-bit within the RP object as defined in [RFC5440] and is similar to the reoptimization request for a P2P TE path. The only difference is that the PCC MUST insert the list of Record Route Objects (RROs) and SRROs after each instance of the END-POINTS object in the PCReq message, as described in Section 3.4 ("Request Message Format") of this document.
P2MP TEパスの再最適化要求は、[RFC5440]で定義されているように、RPオブジェクト内のRビットを使用して指定され、P2P TEパスの再最適化要求に似ています。唯一の違いは、このドキュメントのセクション3.4（「リクエストメッセージフォーマット」）で説明されているように、PCCがPCReqメッセージのEND-POINTSオブジェクトの各インスタンスの後にレコードルートオブジェクト（RRO）とSRROのリストを挿入する必要があることです。
An example of a reoptimization request and subsequent PCReq message is described below:
再最適化要求とそれに続くPCReqメッセージの例を以下に示します。
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 3 RRO list OF (optional)
リーフタイプ3 RROリストOFのP2MPフラグ/ RビットセットEND-POINTSを持つ共通ヘッダーRP（オプション）
Figure 5: PCReq Message Example 1 for Optimization
図5：最適化のためのPCReqメッセージの例1
In this example, we request reoptimization of the path to all leaves without adding or pruning leaves. The reoptimization request would use an END-POINTS object with leaf type 3. The RRO list would represent the P2MP LSP before the optimization, and the modifiable path leaves would be indicated in the END-POINTS object.
この例では、葉を追加または剪定することなく、すべての葉へのパスの再最適化を要求します。再最適化リクエストでは、リーフタイプ3のEND-POINTSオブジェクトを使用します。RROリストは、最適化前のP2MP LSPを表し、変更可能なパスリーフはEND-POINTSオブジェクトで示されます。
It is also possible to specify distinct leaves whose path cannot be modified. An example of the PCReq message in this scenario would be:
パスを変更できない個別の葉を指定することもできます。このシナリオでのPCReqメッセージの例は次のとおりです。
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 3 RRO list END-POINTS for leaf type 4 RRO list OF (optional)
P2MPフラグ付きの共通ヘッダーRP / Rビットセットリーフタイプ3のEND-POINTS RROリストリーフタイプ4のEND-POINTS RROリストOF（オプション）
Figure 6: PCReq Message Example 2 for Optimization
図6：最適化のためのPCReqメッセージの例2
When adding new leaves to or removing old leaves from the existing P2MP tree, by supplying a list of existing leaves, it is possible to optimize the existing P2MP tree. This section explains the methods for adding new leaves to or removing old leaves from the existing P2MP tree.
新しいリーフを既存のP2MPツリーに追加したり、既存のリーフを削除したりする場合、既存のリーフのリストを提供することにより、既存のP2MPツリーを最適化することができます。このセクションでは、既存のP2MPツリーに新しい葉を追加したり、古い葉を削除したりする方法について説明します。
To add new leaves, the PCC MUST build a P2MP request using END-POINTS with leaf type 1.
新しいリーフを追加するには、PCCはリーフタイプ1のEND-POINTSを使用してP2MPリクエストを作成する必要があります。
To remove old leaves, the PCC MUST build a P2MP request using END-POINTS with leaf type 2. If no type-2 END-POINTS exist, then the PCE MUST send Error-Type 17, Error-value 1: the PCE cannot satisfy the request due to no END-POINTS with leaf type 2.
古いリーフを削除するには、PCCはリーフタイプ2のEND-POINTSを使用してP2MPリクエストを作成する必要があります。タイプ2 END-POINTSが存在しない場合、PCEはエラータイプ17、エラー値1を送信する必要があります。PCEは満足できません。リーフタイプ2のEND-POINTSがないためのリクエスト
When adding new leaves to or removing old leaves from the existing P2MP tree, the PCC MUST also provide the list of old leaves, if any, including END-POINTS with leaf type 3, leaf type 4, or both. Specific PCEP-ERROR objects and types are used when certain conditions are not satisfied (i.e., when there are no END-POINTS with leaf type 3 or 4, or in the presence of END-POINTS with leaf type 1 or 2). A generic "Inconsistent END-POINTS" error will be used if a PCC receives a request that has an inconsistent END-POINTS setting (i.e., if a leaf specified as type 1 already exists). These IANA assignments are documented in Section 6.6 ("PCEP-ERROR Objects and Types") of this document.
既存のP2MPツリーに新しい葉を追加したり、古い葉を削除したりする場合、PCCは、リーフタイプ3、リーフタイプ4、またはその両方を含むEND-POINTSを含めて、古いリーフのリストも提供する必要があります。特定のPCEP-ERRORオブジェクトとタイプは、特定の条件が満たされない場合（つまり、リーフタイプ3または4のEND-POINTSがない場合、またはリーフタイプ1または2のEND-POINTSが存在する場合）に使用されます。 PCCが一貫性のないEND-POINTS設定を持つリクエストを受け取った場合（つまり、タイプ1として指定されたリーフがすでに存在する場合）、一般的な「一貫性のないEND-POINTS」エラーが使用されます。これらのIANA割り当ては、このドキュメントのセクション6.6（「PCEP-ERRORオブジェクトとタイプ」）に記載されています。
For old leaves, the PCC MUST provide the old path as a list of RROs that immediately follows each END-POINTS object. This document specifies Error-values when specific conditions are not satisfied.
古い葉の場合、PCCは、各END-POINTSオブジェクトの直後に続くRROのリストとして古いパスを提供する必要があります。このドキュメントでは、特定の条件が満たされない場合のエラー値を指定します。
The following examples demonstrate full and partial reoptimization of existing P2MP LSPs:
次の例は、既存のP2MP LSPの完全および部分的な再最適化を示しています。
Case 1: Adding leaves with full reoptimization of existing paths
ケース1：既存のパスを完全に再最適化してリーフを追加する
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 1 RRO list END-POINTS for leaf type 3 RRO list OF (optional)
P2MPフラグ付きの共通ヘッダーRP / Rビットセットリーフタイプ1のRROリストのEND-POINTSリーフタイプ3のEND-POINTS RROリストOF（オプション）
Case 2: Adding leaves with partial reoptimization of existing paths
ケース2：既存のパスを部分的に再最適化してリーフを追加する
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 1 END-POINTS for leaf type 3 RRO list END-POINTS for leaf type 4 RRO list OF (optional)
P2MPフラグ付きの共通ヘッダーRP / Rビットセットリーフタイプ1のEND-POINTSリーフタイプ3のEND-POINTS RROリストリーフタイプ4のEND-POINTS 4 RROリストOF（オプション）
Case 3: Adding leaves without reoptimization of existing paths
ケース3：既存のパスを再最適化せずに葉を追加する
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 1 RRO list END-POINTS for leaf type 4 RRO list OF (optional)
P2MPフラグ付きの共通ヘッダーRP / Rビットセットリーフタイプ1のRROリストのEND-POINTSリーフタイプ4のEND-POINTS RROリストOF（オプション）
Case 4: Pruning leaves with full reoptimization of existing paths
ケース4：既存のパスを完全に再最適化して葉を剪定する
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 2 RRO list END-POINTS for leaf type 3 RRO list OF (optional)
P2MPフラグ付きの共通ヘッダーRP / Rビットセットリーフタイプ2のEND-POINTS RROリストリーフタイプ3のEND-POINTS RROリストOF（オプション）
Case 5: Pruning leaves with partial reoptimization of existing paths
ケース5：既存のパスを部分的に再最適化して葉を剪定する
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 2 RRO list END-POINTS for leaf type 3 RRO list END-POINTS for leaf type 4 RRO list OF (optional)
P2MPフラグ付きの共通ヘッダーRP / Rビットセットリーフタイプ2のエンドポイントRROリストリーフタイプ3のエンドポイントRROリストリーフタイプ4のエンドポイントRROリストOF（オプション）
Case 6: Pruning leaves without reoptimization of existing paths
ケース6：既存のパスを再最適化せずに葉を剪定する
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 2 RRO list END-POINTS for leaf type 4 RRO list OF (optional)
P2MPフラグ付きの共通ヘッダーRP / Rビットセットリーフタイプ2 RROリストのEND-POINTSリーフタイプ4 RROリストのEND-POINT OF（オプション）
Case 7: Adding and pruning leaves with full reoptimization of existing paths
ケース7：既存のパスを完全に再最適化して葉を追加および枝刈りする
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 1 END-POINTS for leaf type 2 RRO list END-POINTS for leaf type 3 RRO list OF (optional)
P2MPフラグ付きの共通ヘッダーRP / Rビットセットリーフタイプ1のEND-POINTSリーフタイプ2のEND-POINTS RROリストリーフタイプ3のEND-POINTS RROリストOF（オプション）
Case 8: Adding and pruning leaves with partial reoptimization of existing paths
ケース8：既存のパスを部分的に再最適化してリーフを追加および枝刈りする
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 1 END-POINTS for leaf type 2 RRO list END-POINTS for leaf type 3 RRO list END-POINTS for leaf type 4 RRO list OF (optional)
P2MPフラグ付きの共通ヘッダーRP / Rビットセットリーフタイプ1のEND-POINTSリーフタイプ2のEND-POINTS RROリストリーフタイプ3のEND-POINTSリーフタイプ4のRROリストEND-POINTS（オプション）
Case 9: Adding and pruning leaves without reoptimization of existing paths
ケース9：既存のパスを再最適化せずに葉を追加および枝刈りする
Common Header RP with P2MP flag/R-bit set END-POINTS for leaf type 1 END-POINTS for leaf type 2 RRO list END-POINTS for leaf type 4 RRO list OF (optional)
P2MPフラグ付きの共通ヘッダーRP / Rビットセットリーフタイプ1のEND-POINTSリーフタイプ2のEND-POINTS RROリストリーフタイプ4のEND-POINTS RROリストOF（オプション）
Before computing the P2MP path, a PCE may need to be provided means to know which nodes in the network are capable of acting as branch LSRs. A PCE can discover such capabilities by using the mechanisms defined in [RFC5073].
P2MPパスを計算する前に、ネットワーク内のどのノードがブランチLSRとして機能できるかを知る手段をPCEに提供する必要がある場合があります。 PCEは、[RFC5073]で定義されたメカニズムを使用して、このような機能を発見できます。
The PCC can specify a list of nodes that can be used as branch nodes or a list of nodes that cannot be used as branch nodes by using the Branch Node Capability (BNC) object. The BNC object has the same format as the Include Route Object (IRO) as defined in [RFC5440], except that it only supports IPv4 and IPv6 prefix sub-objects. Two Object-Type parameters are also defined:
PCCは、Branch Node Capability（BNC）オブジェクトを使用して、ブランチノードとして使用できるノードのリストまたはブランチノードとして使用できないノードのリストを指定できます。 BNCオブジェクトは、[RFC5440]で定義されているルートオブジェクトを含む（IRO）と同じ形式ですが、IPv4およびIPv6プレフィックスサブオブジェクトのみをサポートします。 2つのObject-Typeパラメータも定義されています。
o Branch node list: List of nodes that can be used as branch nodes.
o ブランチノードリスト：ブランチノードとして使用できるノードのリスト。
o Non-branch node list: List of nodes that cannot be used as branch nodes.
o 非分岐ノードリスト：分岐ノードとして使用できないノードのリスト。
The object can only be carried in a PCReq message. A path computation request may carry at most one Branch Node object.
オブジェクトはPCReqメッセージでのみ運ぶことができます。パス計算要求は、最大で1つのブランチノードオブジェクトを運ぶことができます。
The Object-Class and Object-Type values have been allocated by IANA. The IANA assignments are documented in Section 6.5 ("PCEP Objects").
Object-ClassとObject-Typeの値は、IANAによって割り当てられています。 IANAの割り当てについては、セクション6.5（「PCEPオブジェクト」）に記載されています。
There are cases when multiple P2MP LSPs' computations need to be synchronized. For example, one P2MP LSP is the designated backup of another P2MP LSP. In this case, path diversity for these dependent LSPs may need to be considered during the path computation.
複数のP2MP LSPの計算を同期する必要がある場合があります。たとえば、1つのP2MP LSPが別のP2MP LSPの指定されたバックアップです。この場合、これらの依存LSPのパスダイバーシティをパス計算中に考慮する必要があります。
The synchronization can be done by using the existing SVEC functionality as defined in [RFC5440].
同期は、[RFC5440]で定義されている既存のSVEC機能を使用して行うことができます。
An example of synchronizing two P2MP LSPs, each having two leaves for Path Computation Request messages, is illustrated below:
それぞれがパス計算要求メッセージ用の2つのリーフを持つ2つのP2MP LSPを同期する例を以下に示します。
Common Header SVEC for sync of LSP1 and LSP2 OF (optional) RP for LSP1 END-POINTS1 for LSP1 RRO1 list RP for LSP2 END-POINTS2 for LSP2 RRO2 list
LSP1およびLSP2 OFの同期用の共通ヘッダーSVEC（オプション）LSP1のRP LSP1 RRO1リストのEND-POINTS1 LSP2のRP-LSP2 RRO2リストのEND-POINTS2
Figure 7: PCReq Message Example for Synchronization
図7：同期のPCReqメッセージの例
This specification also defines two flags for the SVEC Object Flag Field for P2MP path-dependent computation requests. The first flag allows the PCC to request that the PCE should compute a secondary P2MP path tree with partial path diversity for specific leaves or a specific S2L sub-path to the primary P2MP path tree. The second flag allows the PCC to request that partial paths should be link direction diverse.
この仕様では、P2MPパスに依存する計算要求のSVECオブジェクトフラグフィールドの2つのフラグも定義しています。最初のフラグにより、PCCは、PCEがプライマリP2MPパスツリーへの特定のリーフまたは特定のS2Lサブパスの部分的なパスダイバーシティを使用してセカンダリP2MPパスツリーを計算することを要求できます。 2番目のフラグにより、PCCは部分パスがリンク方向の多様性であることを要求できます。
The following flags are added to the SVEC object body in this document:
このドキュメントでは、次のフラグがSVECオブジェクト本体に追加されています。
o P (Partial Path Diverse bit - 1 bit):
o P（部分パス多様ビット-1ビット）：
When set, this would indicate a request for path diversity for a specific leaf, a set of leaves, or all leaves.
設定されている場合、これは特定のリーフ、リーフのセット、またはすべての葉のパスダイバーシティの要求を示します。
o D (Link Direction Diverse bit - 1 bit):
o D（リンク方向多様ビット-1ビット）：
When set, this would indicate a request that a partial path or paths should be link direction diverse.
設定されている場合、これは、部分的なパス（複数の場合もある）のリンク方向を多様にする必要があるという要求を示します。
The IANA assignments are referenced in Section 6.8 of this document.
IANAの割り当ては、このドキュメントのセクション6.8で参照されています。
The total PCEP message length, including the common header, is 16 bytes. In certain scenarios, the P2MP computation request may not fit into a single request or response message. For example, if a tree has many hundreds or thousands of leaves, then the request or response may need to be fragmented into multiple messages.
共通ヘッダーを含むPCEPメッセージの全長は16バイトです。特定のシナリオでは、P2MP計算要求が単一の要求または応答メッセージに収まらない場合があります。たとえば、ツリーに数百または数千の葉がある場合、要求または応答を複数のメッセージにフラグメント化する必要がある場合があります。
The F-bit is outlined in Section 3.3.1 ("The Extension of the RP Object") of this document. The F-bit is used in the RP object to signal that the initial request or response was too large to fit into a single message and will be fragmented into multiple messages. In order to identify the single request or response, each message will use the same request ID.
Fビットの概要は、このドキュメントのセクション3.3.1（「RPオブジェクトの拡張」）にあります。 FビットはRPオブジェクトで使用され、最初の要求または応答が大きすぎて単一のメッセージに収まらず、複数のメッセージにフラグメント化されることを通知します。単一の要求または応答を識別するために、各メッセージは同じ要求IDを使用します。
If the initial request is too large to fit into a single request message, the PCC will split the request over multiple messages. Each message sent to the PCE, except the last one, will have the F-bit set in the RP object to signify that the request has been fragmented into multiple messages. In order to identify that a series of request messages represents a single request, each message will use the same request ID.
最初の要求が大きすぎて1つの要求メッセージに収まらない場合、PCCは要求を複数のメッセージに分割します。最後のメッセージを除いて、PCEに送信される各メッセージには、RPオブジェクトにFビットが設定され、要求が複数のメッセージにフラグメント化されていることを示します。一連の要求メッセージが単一の要求を表すことを識別するために、各メッセージは同じ要求IDを使用します。
The assumption is that request messages are reliably delivered and in sequence, since PCEP relies on TCP.
PCEPはTCPに依存しているため、要求メッセージは確実に順番に配信されることが前提です。
Once the PCE computes a path based on the initial request, a response is sent back to the PCC. If the response is too large to fit into a single response message, the PCE will split the response over multiple messages. Each message sent by the PCE, except the last one, will have the F-bit set in the RP object to signify that the response has been fragmented into multiple messages. In order to identify that a series of response messages represents a single response, each message will use the same response ID.
PCEが最初の要求に基づいてパスを計算すると、PCCに応答が送信されます。応答が大きすぎて1つの応答メッセージに収まらない場合、PCEは応答を複数のメッセージに分割します。 PCEによって送信された各メッセージ（最後のメッセージを除く）には、RPオブジェクトにFビットが設定され、応答が複数のメッセージにフラグメント化されたことを示します。一連の応答メッセージが単一の応答を表すことを識別するために、各メッセージは同じ応答IDを使用します。
Again, the assumption is that response messages are reliably delivered and in sequence, since PCEP relies on TCP.
繰り返しになりますが、PCEPはTCPに依存しているため、応答メッセージは確実に順番に配信されることが前提となっています。
The following example illustrates the PCC sending a request message with Req-ID1 to the PCE, in order to add one leaf to an existing tree with 1200 leaves. The assumption used for this example is that one request message can hold up to 800 leaves. In this scenario, the original single message needs to be fragmented and sent using two smaller messages, which have Req-ID1 specified in the RP object, and with the F-bit set on the first message and the F-bit cleared on the second message.
次の例は、1200個の葉を持つ既存のツリーに1つの葉を追加するために、PCCがReq-ID1を含む要求メッセージをPCEに送信することを示しています。この例で使用されている前提は、1つの要求メッセージが最大800のリーフを保持できることです。このシナリオでは、元の単一メッセージをフラグメント化して、RPオブジェクトでReq-ID1が指定された2つの小さなメッセージを使用して送信し、最初のメッセージでFビットを設定し、2番目のメッセージでFビットをクリアする必要があります。メッセージ。
Common Header RP1 with Req-ID1 and P2MP=1 and F-bit=1 OF (optional) END-POINTS1 for P2MP RRO1 list
Req-ID1およびP2MP = 1およびF-bit = 1 OFを持つ共通ヘッダーRP1（オプション）P2MP RRO1リストのEND-POINTS1
Common Header RP2 with Req-ID1 and P2MP=1 and F-bit=0 OF (optional) END-POINTS1 for P2MP RRO1 list
Req-ID1およびP2MP = 1およびF-bit = 0 OFを持つ共通ヘッダーRP2（オプション）P2MP RRO1リストのEND-POINTS1
Figure 8: PCReq Message Fragmentation Example
図8：PCReqメッセージの断片化の例
To handle a scenario where the last fragmented message piece is lost, the receiver side of the fragmented message may start a timer once it receives the first piece of the fragmented message. If the timer expires and it still has not received the last piece of the fragmented message, it should send an error message to the sender to signal that it has received an incomplete message. The relevant error message is documented in Section 3.15 ("P2MP PCEP-ERROR Objects and Types").
最後の断片化されたメッセージの一部が失われるシナリオを処理するために、断片化されたメッセージの受信側は、断片化されたメッセージの最初の断片を受信すると、タイマーを開始します。タイマーの期限が切れても、断片化されたメッセージの最後の部分をまだ受信していない場合、不完全なメッセージを受信したことを知らせるエラーメッセージを送信者に送信する必要があります。関連するエラーメッセージは、セクション3.15（「P2MP PCEP-ERRORのオブジェクトとタイプ」）に記載されています。
The PCE path computation request may fail because all or a subset of the destinations are unreachable.
宛先のすべてまたはサブセットに到達できないため、PCEパス計算要求が失敗する可能性があります。
In such a case, the UNREACH-DESTINATION object allows the PCE to optionally specify the list of unreachable destinations.
そのような場合、UNREACH-DESTINATIONオブジェクトを使用すると、PCEはオプションで到達できない宛先のリストを指定できます。
This object can be present in PCRep messages. There can be up to one such object per RP.
このオブジェクトはPCRepメッセージに存在できます。 RPごとに最大1つのそのようなオブジェクトが存在できます。
The following UNREACH-DESTINATION objects (for IPv4 and IPv6) are defined:
次のUNREACH-DESTINATIONオブジェクト（IPv4およびIPv6用）が定義されています。
UNREACH-DESTINATION Object-Class is 28. UNREACH-DESTINATION Object-Type for IPv4 is 1. UNREACH-DESTINATION Object-Type for IPv6 is 2.
UNREACH-DESTINATIONオブジェクトクラスは28です。IPv4のUNREACH-DESTINATIONオブジェクトタイプは1です。IPv6のUNREACH-DESTINATIONオブジェクトタイプは2です。
The format of the UNREACH-DESTINATION object body for IPv4 (Object-Type=1) is as follows:
IPv4のUNREACH-DESTINATIONオブジェクト本体（Object-Type = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: UNREACH-DESTINATION Object Body for IPv4
図9：IPv4のUNREACH-DESTINATIONオブジェクト本体
The format of the UNREACH-DESTINATION object body for IPv6 (Object-Type=2) is as follows:
IPv6のUNREACH-DESTINATIONオブジェクト本体（Object-Type = 2）の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: UNREACH-DESTINATION Object Body for IPv6
図10：IPv6のUNREACH-DESTINATIONオブジェクト本体
To indicate an error associated with a policy violation, the Error-value "P2MP Path computation is not allowed" has been added to the existing error code for Error-Type 5 ("Policy violation") as defined in [RFC5440] (see also Section 6.6 of this document):
ポリシー違反に関連するエラーを示すために、[RFC5440]で定義されているように、エラー値「P2MPパス計算は許可されていません」がエラータイプ5の既存のエラーコード（「ポリシー違反」）に追加されました（以下も参照）このドキュメントのセクション6.6）：
Error-Type=5; Error-value=7: if a PCE receives a P2MP path computation request that is not compliant with administrative privileges (i.e., "The PCE policy does not support P2MP path computation"), the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=5) and an Error-value of 7. The corresponding P2MP path computation request MUST also be cancelled.
Error-Type = 5;エラー値= 7：PCEが管理者特権に準拠していないP2MPパス計算要求を受信した場合（つまり、「PCEポリシーはP2MPパス計算をサポートしていない」）、PCEはPCEP-ERRORを含むPCErrメッセージを送信する必要がありますオブジェクト（Error-Type = 5）およびエラー値7。対応するP2MPパス計算リクエストもキャンセルする必要があります。
To indicate capability errors associated with the P2MP path computation request, Error-Type (16) and subsequent Error-values are defined as follows for inclusion in the PCEP-ERROR object:
P2MPパス計算リクエストに関連する機能エラーを示すために、Error-Type（16）および後続のError-valuesは、PCEP-ERRORオブジェクトに含めるために次のように定義されています。
Error-Type=16; Error-value=1: if a PCE receives a P2MP path computation request and the PCE is not capable of satisfying the request due to insufficient memory, the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=16) and an Error-value of 1. The corresponding P2MP path computation request MUST also be cancelled.
Error-Type = 16; Error-value = 1：PCEがP2MPパス計算要求を受信し、メモリ不足のためにPCEが要求を満たすことができない場合、PCEはPCEP-ERRORオブジェクトを含むPCErrメッセージを送信する必要があります（Error-Type = 16）エラー値は1です。対応するP2MPパス計算リクエストもキャンセルする必要があります。
Error-Type=16; Error-value=2: if a PCE receives a P2MP path computation request and the PCE is not capable of P2MP computation, the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=16) and an Error-value of 2. The corresponding P2MP path computation request MUST also be cancelled.
Error-Type = 16; Error-value = 2：PCEがP2MPパス計算リクエストを受信し、PCEがP2MP計算に対応していない場合、PCEはPCEP-ERRORオブジェクト（Error-Type = 16）とError-valueを含むPCErrメッセージを送信する必要がありますof2。対応するP2MPパス計算リクエストもキャンセルする必要があります。
To indicate P2MP message fragmentation errors associated with a P2MP path computation request, Error-Type (18) and subsequent Error-values are defined as follows for inclusion in the PCEP-ERROR object:
P2MPパス計算リクエストに関連付けられたP2MPメッセージフラグメンテーションエラーを示すために、PCEP-ERRORオブジェクトに含めるために、Error-Type（18）および後続のエラー値が次のように定義されています。
Error-Type=18; Error-value=1: if a PCE has not received the last piece of the fragmented message, it should send an error message to the sender to signal that it has received an incomplete message (i.e., "Fragmented request failure"). The PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=18) and an Error-value of 1.
Error-Type = 18; Error-value = 1：PCEが断片化されたメッセージの最後の部分を受信していない場合、不完全なメッセージ（つまり、「フラグメント化された要求の失敗」）を受信したことを通知するエラーメッセージを送信者に送信する必要があります。 PCEは、PCEP-ERRORオブジェクト（Error-Type = 18）およびError-valueが1のPCErrメッセージを送信する必要があります。
To communicate the reasons for not being able to find a P2MP path computation, the NO-PATH object can be used in the PCRep message.
P2MPパス計算を見つけることができない理由を伝えるために、PCRepメッセージでNO-PATHオブジェクトを使用できます。
One bit is defined in the NO-PATH-VECTOR TLV carried in the NO-PATH object:
NO-PATHオブジェクトに含まれるNO-PATH-VECTOR TLVで1ビットが定義されています。
bit 24: when set, the PCE indicates that there is a reachability problem with all or a subset of the P2MP destinations. Optionally, the PCE can specify the destination or list of destinations that are not reachable using the UNREACH-DESTINATION object defined in Section 3.14.
ビット24：セットされている場合、PCEは、P2MP宛先のすべてまたはサブセットに到達可能性の問題があることを示します。オプションで、PCEは、セクション3.14で定義されているUNREACH-DESTINATIONオブジェクトを使用して到達できない宛先または宛先のリストを指定できます。
[RFC5862] describes various manageability requirements in support of P2MP path computation when applying PCEP. This section describes how manageability requirements mentioned in [RFC5862] are supported in the context of PCEP extensions specified in this document.
[RFC5862]は、PCEPを適用する際のP2MPパス計算をサポートするためのさまざまな管理要件を説明しています。このセクションでは、[RFC5862]で言及されている管理要件が、このドキュメントで指定されているPCEP拡張のコンテキストでどのようにサポートされるかについて説明します。
Note that [RFC5440] describes various manageability considerations for PCEP, and most of the manageability requirements mentioned in [RFC5862] are already covered there.
[RFC5440]はPCEPの管理性に関するさまざまな考慮事項を説明しており、[RFC5862]で言及されている管理性要件のほとんどはすでにそこでカバーされています。
In addition to PCE configuration parameters listed in [RFC5440], the following additional parameters might be required:
[RFC5440]にリストされているPCE構成パラメーターに加えて、以下の追加パラメーターが必要になる場合があります。
o The PCE may be configured to enable or disable P2MP path computations.
o PCEは、P2MPパス計算を有効または無効にするように構成できます。
o The PCE may be configured to enable or disable the advertisement of its P2MP path computation capability. A PCE can advertise its P2MP capability via the IGP discovery mechanism discussed in Section 3.1.1 ("IGP Extensions for P2MP Capability Advertisement") or during the Open Message Exchange discussed in Section 3.1.2 ("Open Message Extension").
o PCEは、P2MPパス計算機能のアドバタイズを有効または無効にするように設定できます。 PCEは、セクション3.1.1（「P2MP機能アドバタイズメントのIGP拡張機能」）で説明されているIGPディスカバリメカニズムを介して、またはセクション3.1.2（「オープンメッセージ拡張機能」）で説明されているオープンメッセージ交換中に、P2MP機能をアドバタイズできます。
A number of MIB objects have been defined in [RFC7420] for general PCEP control and monitoring of P2P computations. [RFC5862] specifies that MIB objects will be required to support the control and monitoring of the protocol extensions defined in this document. A new document will be required to define MIB objects for PCEP control and monitoring of P2MP computations.
[RFC7420]では、一般的なPCEP制御とP2P計算の監視のために、いくつかのMIBオブジェクトが定義されています。 [RFC5862]は、このドキュメントで定義されているプロトコル拡張の制御と監視をサポートするためにMIBオブジェクトが必要になることを指定しています。 PCEP制御とP2MP計算の監視のためのMIBオブジェクトを定義するには、新しいドキュメントが必要です。
The "ietf-pcep" PCEP YANG module is specified in [PCEP-YANG]. The P2MP capability of a PCEP entity or a configured peer can be set using this YANG module. Also, support for P2MP path computation can be learned using this module. The statistics are maintained in the "ietf-pcep-stats" YANG module as specified in [PCEP-YANG]. This YANG module will be required to be augmented to also include the P2MP-related statistics.
"ietf-pcep" PCEP YANGモジュールは[PCEP-YANG]で指定されています。 PCEPエンティティまたは構成済みピアのP2MP機能は、このYANGモジュールを使用して設定できます。また、このモジュールを使用して、P2MPパス計算のサポートを学習できます。 [PCEP-YANG]で指定されているように、統計は「ietf-pcep-stats」YANGモジュールで維持されます。このYANGモジュールは、P2MP関連の統計も含めるように拡張する必要があります。
There are no additional considerations beyond those expressed in [RFC5440], since [RFC5862] does not address any additional requirements.
[RFC5862]は追加の要件に対応していないため、[RFC5440]で表現されているものを超える追加の考慮事項はありません。
There are no additional requirements beyond those expressed in [RFC4657] for verifying the correct operation of the PCEP sessions. It is expected that future MIB objects will facilitate verification of correct operation and reporting of P2MP PCEP requests, responses, and errors.
PCEPセッションの正しい動作を検証するために、[RFC4657]で表現されているもの以外の追加の要件はありません。将来のMIBオブジェクトは、正しい動作の検証とP2MP PCEP要求、応答、およびエラーの報告を容易にすることが期待されます。
The method for the PCE to obtain information about a PCE capable of P2MP path computations via OSPF and IS-IS is discussed in Section 3.1.1 ("IGP Extensions for P2MP Capability Advertisement") of this document.
PCEがOSPFおよびIS-ISを介してP2MPパス計算が可能なPCEに関する情報を取得する方法については、このドキュメントのセクション3.1.1（「IGP Extensions for P2MP Capability Advertisement」）で説明しています。
The relevant IANA assignment is documented in Section 6.9 ("OSPF PCE Capability Flag") of this document.
関連するIANA割り当ては、このドキュメントのセクション6.9（「OSPF PCE機能フラグ」）に記載されています。
It is expected that the use of PCEP extensions specified in this document will not significantly increase the level of operational traffic. However, computing a P2MP tree may require more PCE state compared to a P2P computation. In the event of a major network failure and multiple recovery P2MP tree computation requests being sent to the PCE, the load on the PCE may also be significantly increased.
このドキュメントで指定されているPCEP拡張機能を使用しても、運用トラフィックのレベルが大幅に増加することはありません。ただし、P2MPツリーの計算には、P2P計算と比較してより多くのPCE状態が必要になる場合があります。大きなネットワーク障害が発生し、PCEに複数のリカバリP2MPツリー計算リクエストが送信された場合、PCEの負荷も大幅に増加する可能性があります。
As described in [RFC5862], P2MP path computation requests are more CPU-intensive and also utilize more link bandwidth. In the event of an unauthorized P2MP path computation request or a denial-of-service attack, the subsequent PCEP requests and processing may be disruptive to the network. Consequently, it is important that implementations conform to the relevant security requirements that specifically help to minimize or negate unauthorized P2MP path computation requests and denial-of-service attacks. These mechanisms include the following:
[RFC5862]で説明されているように、P2MPパス計算リクエストはより多くのCPUを必要とし、より多くのリンク帯域幅を利用します。不正なP2MPパス計算要求またはサービス拒否攻撃が発生した場合、後続のPCEP要求と処理はネットワークに混乱をもたらす可能性があります。したがって、実装は関連するセキュリティ要件に準拠することが重要です。これは、未承認のP2MPパス計算要求とサービス拒否攻撃を最小限に抑えるか、無効にするのに特に役立ちます。これらのメカニズムには、次のものがあります。
o Securing the PCEP session requests and responses is RECOMMENDED using TCP security techniques such as the TCP Authentication Option (TCP-AO) [RFC5925] or using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in [RFC7525].
o PCEPセッションの要求と応答の保護は、TCP認証オプション（TCP-AO）[RFC5925]などのTCPセキュリティ手法を使用するか、トランスポート層セキュリティ（TLS）[RFC8253]を使用することをお勧めします。 ]。
o Authenticating the PCEP requests and responses to ensure that the message is intact and sent from an authorized node using the TCP-AO or TLS is RECOMMENDED.
o PCEP要求と応答を認証して、メッセージが損なわれておらず、TCP-AOまたはTLSを使用して承認済みノードから送信されることを確認することをお勧めします。
o Policy control could be provided by explicitly defining which PCCs are allowed to send P2MP path computation requests to the PCE via IP access lists.
o ポリシー制御は、IPアクセスリストを介してP2MPパス計算要求をPCEに送信できるPCCを明示的に定義することで提供できます。
PCEP operates over TCP, so it is also important to secure the PCE and PCC against TCP denial-of-service attacks.
PCEPはTCPを介して動作するため、TCPサービス拒否攻撃からPCEおよびPCCを保護することも重要です。
As stated in [RFC6952], PCEP implementations SHOULD support the TCP-AO [RFC5925] and not use TCP MD5 because of TCP MD5's known vulnerabilities and weakness.
[RFC6952]で述べられているように、PCEP実装はTCP-AO [RFC5925]をサポートする必要があり（SHOULD）、TCP MD5の既知の脆弱性と弱点のため、TCP MD5を使用しないでください。
IANA maintains a registry of PCEP parameters. A number of IANA considerations have been highlighted in previous sections of this document. IANA made the allocations as per [RFC6006].
IANAはPCEPパラメータのレジストリを維持しています。このドキュメントの前のセクションでは、IANAに関するいくつかの考慮事項が強調されています。 IANAは、[RFC6006]に従って割り当てを行いました。
As described in Section 3.1.2, the P2MP capability TLV allows the PCE to advertise its P2MP path computation capability.
セクション3.1.2で説明したように、P2MP機能TLVを使用すると、PCEはP2MPパス計算機能をアドバタイズできます。
IANA had previously made an allocation from the "PCEP TLV Type Indicators" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document.
IANAは、以前は「PCEP TLV Type Indicators」サブレジストリから割り当てを行っていましたが、RFC 6006が参照されていました。 IANAは、このドキュメントを指すようにリファレンスを次のように更新しました。
Value Description Reference
値説明リファレンス
6 P2MP capable RFC 8306
6 P2MP対応RFC 8306
As described in Section 3.3.1, three RP Object Flags have been defined.
セクション3.3.1で説明したように、3つのRPオブジェクトフラグが定義されています。
IANA had previously made allocations from the PCEP "RP Object Flag Field" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document.
IANAは以前に、RFC 6006が参照であるPCEP "RP Object Flag Field"サブレジストリから割り当てを行っていました。 IANAは、このドキュメントを指すようにリファレンスを次のように更新しました。
Bit Description Reference
ビット説明リファレンス
18 Fragmentation (F-bit) RFC 8306 19 P2MP (N-bit) RFC 8306 20 ERO-compression (E-bit) RFC 8306
18フラグメンテーション（Fビット）RFC 8306 19 P2MP（Nビット）RFC 8306 20 ERO圧縮（Eビット）RFC 8306
As described in Section 3.6.1, this document defines two objective functions.
セクション3.6.1で説明したように、このドキュメントでは2つの目的関数を定義しています。
IANA had previously made allocations from the PCEP "Objective Function" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document.
IANAは以前に、RFC 6006が参照であるPCEPの「目的関数」サブレジストリから割り当てを行っていました。 IANAは、このドキュメントを指すようにリファレンスを次のように更新しました。
Code Point Name Reference
コードポイント名リファレンス
7 SPT RFC 8306 8 MCT RFC 8306
7 SPT RFC 8306 8 MCT RFC 8306
As described in Section 3.6.2, three METRIC object T fields have been defined.
セクション3.6.2で説明したように、3つのMETRICオブジェクトTフィールドが定義されています。
IANA had previously made allocations from the PCEP "METRIC Object T Field" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document.
IANAは以前に、RFC 6006が参照であるPCEP "METRIC Object T Field"サブレジストリから割り当てを行っていました。 IANAは、このドキュメントを指すようにリファレンスを次のように更新しました。
Value Description Reference
値説明リファレンス
8 P2MP IGP metric RFC 8306 9 P2MP TE metric RFC 8306 10 P2MP hop count metric RFC 8306
8 P2MP IGPメトリックRFC 8306 9 P2MP TEメトリックRFC 8306 10 P2MPホップカウントメトリックRFC 8306
As discussed in Section 3.3.2, two END-POINTS Object-Type values are defined.
セクション3.3.2で説明したように、2つのEND-POINTS Object-Type値が定義されています。
IANA had previously made the Object-Type allocations from the "PCEP Objects" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document.
IANAは、以前は「PCEPオブジェクト」サブレジストリからオブジェクトタイプの割り当てを行っていましたが、RFC 6006が参照されていました。 IANAは、このドキュメントを指すようにリファレンスを次のように更新しました。
Object-Class Value 4 Name END-POINTS Object-Type 3: IPv4 4: IPv6 5-15: Unassigned Reference RFC 8306
オブジェクトクラス値4名前END-POINTSオブジェクトタイプ3：IPv4 4：IPv6 5-15：未割り当ての参照RFC 8306
As described in Sections 3.2, 3.11.1, and 3.14, four PCEP Object-Class values and six PCEP Object-Type values have been defined.
セクション3.2、3.11.1、および3.14で説明されているように、4つのPCEPオブジェクトクラス値と6つのPCEPオブジェクトタイプ値が定義されています。
IANA had previously made allocations from the "PCEP Objects" subregistry, where RFC 6006 was the reference. IANA has updated the reference to point to this document.
IANAは、以前は「PCEPオブジェクト」サブレジストリから割り当てを行っていましたが、RFC 6006が参照されていました。 IANAは、このドキュメントを指すように参照を更新しました。
Also, for the following four PCEP objects, codepoint 0 for the Object-Type field is marked "Reserved", as per Erratum ID 4956 for RFC 5440. IANA has updated the reference to point to this document.
また、次の4つのPCEPオブジェクトでは、RFC 5440のエラータID 4956に従って、Object-Typeフィールドのコードポイント0が「予約済み」とマークされています。IANAはこのドキュメントを指すように参照を更新しました。
Object-Class Value 28 Name UNREACH-DESTINATION Object-Type 0: Reserved 1: IPv4 2: IPv6 3-15: Unassigned Reference RFC 8306
オブジェクトクラス値28名前UNREACH-DESTINATIONオブジェクトタイプ0：予約済み1：IPv4 2：IPv6 3-15：未割り当てのリファレンスRFC 8306
Object-Class Value 29 Name SERO Object-Type 0: Reserved 1: SERO 2-15: Unassigned Reference RFC 8306
オブジェクトクラス値29名前SEROオブジェクトタイプ0：予約済み1：SERO 2-15：未割り当ての参照RFC 8306
Object-Class Value 30 Name SRRO Object-Type 0: Reserved 1: SRRO 2-15: Unassigned Reference RFC 8306
オブジェクトクラス値30名前SRROオブジェクトタイプ0：予約済み1：SRRO 2-15：未割り当ての参照RFC 8306
Object-Class Value 31 Name BNC Object-Type 0: Reserved 1: Branch node list 2: Non-branch node list 3-15: Unassigned Reference RFC 8306
オブジェクトクラス値31名前BNCオブジェクトタイプ0：予約済み1：ブランチノードリスト2：非ブランチノードリスト3-15：未割り当てのリファレンスRFC 8306
As described in Section 3.15, a number of PCEP-ERROR Object Error-Types and Error-values have been defined.
セクション3.15で説明したように、多数のPCEP-ERRORオブジェクトのエラータイプとエラー値が定義されています。
IANA had previously made allocations from the PCEP "PCEP-ERROR Object Error Types and Values" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document.
IANAは以前に、RFC 6006が参照であるPCEP "PCEP-ERROR Object Error Types and Values"サブレジストリから割り当てを行っていました。 IANAは、このドキュメントを指すようにリファレンスを次のように更新しました。
Error Type Meaning Reference
エラータイプ意味リファレンス
5 Policy violation Error-value=7: RFC 8306 P2MP Path computation is not allowed
5ポリシー違反エラー値= 7：RFC 8306 P2MPパス計算は許可されていません
16 P2MP Capability Error Error-value=0: Unassigned RFC 8306 Error-value=1: RFC 8306 The PCE cannot satisfy the request due to insufficient memory Error-value=2: RFC 8306 The PCE is not capable of P2MP computation
16 P2MP機能エラーエラー値= 0：未割り当てRFC 8306エラー値= 1：RFC 8306メモリ不足のため、PCEは要求を満たすことができませんエラー値= 2：RFC 8306 PCEはP2MP計算に対応していません
17 P2MP END-POINTS Error Error-value=0: Unassigned RFC 8306 Error-value=1: RFC 8306 The PCE cannot satisfy the request due to no END-POINTS with leaf type 2 Error-value=2: RFC 8306 The PCE cannot satisfy the request due to no END-POINTS with leaf type 3 Error-value=3: RFC 8306 The PCE cannot satisfy the request due to no END-POINTS with leaf type 4 Error-value=4: RFC 8306 The PCE cannot satisfy the request due to inconsistent END-POINTS
17 P2MP END-POINTSエラーError-value = 0：未割り当てRFC 8306 Error-value = 1：RFC 8306リーフタイプ2のEND-POINTSがないため、PCEは要求を満たすことができません。Error-value= 2：RFC 8306 PCEはリーフタイプ3のEND-POINTSがないため、要求を満たします。エラー値= 3：RFC 8306 PCEは、リーフタイプ4のEND-POINTSがないため、要求を満たすことができません。エラー値= 4：RFC 8306 PCEは、一貫性のないEND-POINTSによる要求
18 P2MP Fragmentation Error Error-value=0: Unassigned RFC 8306 Error-value=1: RFC 8306 Fragmented request failure
18 P2MPフラグメンテーションエラーError-value = 0：Unassigned RFC 8306 Error-value = 1：RFC 8306 Fragmented request failure
As discussed in Section 3.16, the NO-PATH-VECTOR TLV Flag Field has been defined.
セクション3.16で説明したように、NO-PATH-VECTOR TLVフラグフィールドが定義されています。
IANA had previously made an allocation from the PCEP "NO-PATH-VECTOR TLV Flag Field" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document.
IANAは以前に、RFC 6006が参照であるPCEP "NO-PATH-VECTOR TLV Flag Field"サブレジストリから割り当てを行っていました。 IANAは、このドキュメントを指すようにリファレンスを次のように更新しました。
Bit Description Reference
ビット説明リファレンス
24 P2MP Reachability Problem RFC 8306
24 P2MP到達可能性問題RFC 8306
As discussed in Section 3.12, two SVEC Object Flags are defined.
セクション3.12で説明したように、2つのSVECオブジェクトフラグが定義されています。
IANA had previously made allocations from the PCEP "SVEC Object Flag Field" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document.
IANAは以前に、RFC 6006が参照であるPCEP "SVEC Object Flag Field"サブレジストリから割り当てを行っていました。 IANAは、このドキュメントを指すようにリファレンスを次のように更新しました。
Bit Description Reference
ビット説明リファレンス
19 Partial Path Diverse RFC 8306 20 Link Direction Diverse RFC 8306
19パーシャルパスダイバースRFC 8306 20リンク方向ダイバースRFC 8306
As discussed in Section 3.1.1, the OSPF Capability Flag is defined to indicate P2MP path computation capability.
セクション3.1.1で説明したように、OSPF機能フラグはP2MPパス計算機能を示すために定義されています。
IANA had previously made an assignment from the OSPF Parameters "Path Computation Element (PCE) Capability Flags" registry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document.
IANAは、以前にOSPFパラメータの「パス計算要素（PCE）機能フラグ」レジストリから割り当てを行っていました。RFC6006が参照されていました。 IANAは、このドキュメントを指すようにリファレンスを次のように更新しました。
Bit Description Reference
ビット説明リファレンス
10 P2MP path computation RFC 8306
10 P2MPパス計算RFC 8306
[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>。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <https://www.rfc-editor.org/info/rfc3473>.
[RFC3473] Berger、L。、編、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、DOI 10.17487 / RFC3473、2003年1月、<https： //www.rfc-editor.org/info/rfc3473>。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, May 2007, <https://www.rfc-editor.org/info/rfc4873>.
[RFC4873] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「GMPLS Segment Recovery」、RFC 4873、DOI 10.17487 / RFC4873、2007年5月、<https：//www.rfc-editor .org / info / rfc4873>。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, <https://www.rfc-editor.org/info/rfc4875>.
[RFC4875] Aggarwal、R.、Ed。、Papadimitriou、D.、Ed。、and S. Yasukawa、Ed。、 "Extensions to Resource Reservation Protocol-Traffic Engineering（RSVP-TE）for Point-to-Multipoint TE Label Switchedパス（LSP）」、RFC 4875、DOI 10.17487 / RFC4875、2007年5月、<https://www.rfc-editor.org/info/rfc4875>。
[RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", RFC 5073, DOI 10.17487/RFC5073, December 2007, <https://www.rfc-editor.org/info/rfc5073>.
[RFC5073] Vasseur、J.、Ed。およびJ. Le Roux、Ed。、 "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities"、RFC 5073、DOI 10.17487 / RFC5073、December 2007、<https：// www.rfc-editor.org/info/rfc5073>。
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, January 2008, <https://www.rfc-editor.org/info/rfc5088>.
[RFC5088] Le Roux、JL。、Ed。、Vasseur、JP。、Ed。、Ikejiri、Y.、and R. Zhang、 "OSPF Protocol Extensions for Path Computation Element（PCE）Discovery"、RFC 5088、DOI 10.17487 / RFC5088、2008年1月、<https://www.rfc-editor.org/info/rfc5088>。
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, January 2008, <https://www.rfc-editor.org/info/rfc5089>.
[RFC5089] Le Roux、JL。、Ed。、Vasseur、JP。、Ed。、Ikejiri、Y.、and R. Zhang、 "IS-IS Protocol Extensions for Path Computation Element（PCE）Discovery"、RFC 5089、DOI 10.17487 / RFC5089、2008年1月、<https://www.rfc-editor.org/info/rfc5089>。
[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。、and JL。 Le Roux編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<https://www.rfc-editor.org/info/rfc5440>。
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC5511] Farrel、A。、「Routing Backus-Naur Form（RBNF）：A Syntax Using Forming Encoding Rules in Various Routing Protocol Specifications」、RFC 5511、DOI 10.17487 / RFC5511、2009年4月、<https：// www。 rfc-editor.org/info/rfc5511>。
[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。、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>。
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, <https://www.rfc-editor.org/info/rfc7770>.
[RFC7770] Lindem、A.、Ed。、Shen、N.、Vasseur、JP。、Aggarwal、R.、and S. Shaffer、 "Extensions to OSPF for Advertising Optional Router Capabilities"、RFC 7770、DOI 10.17487 / RFC7770、 2016年2月、<https://www.rfc-editor.org/info/rfc7770>。
[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>。
[PCEP-YANG] Dhody, D., Ed., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, draft-ietf-pce-pcep-yang-05, July 2017.
[PCEP-YANG] Dhody、D.、Ed。、Hardwick、J.、Beeram、V。、およびJ. Tantsura、「パス計算要素通信プロトコル（PCEP）のYANGデータモデル」、作業中、ドラフト- ietf-pce-pcep-yang-05、2017年7月。
[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. 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。、編、およびJ.Le Roux、編、「Path Computation Element（PCE）Communication Protocol Generic Requirements」、RFC 4657、DOI 10.17487 / RFC4657、2006年9月、<https：// www .rfc-editor.org / info / rfc4657>。
[RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, DOI 10.17487/RFC5671, October 2009, <https://www.rfc-editor.org/info/rfc5671>.
[RFC5671]安川S.およびA.ファレル編、「ポイントツーマルチポイント（P2MP）MPLSおよびGMPLSトラフィックエンジニアリング（TE）へのパス計算要素（PCE）の適用性」、RFC 5671、DOI 10.17487 / RFC5671、2009年10月、<https://www.rfc-editor.org/info/rfc5671>。
[RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE", RFC 5862, DOI 10.17487/RFC5862, June 2010, <https://www.rfc-editor.org/info/rfc5862>.
[RFC5862]安川S.およびA. Farrel、「ポイントツーマルチポイントMPLS-TEのパス計算クライアント（PCC）-パス計算要素（PCE）要件」、RFC 5862、DOI 10.17487 / RFC5862、2010年6月、< https://www.rfc-editor.org/info/rfc5862>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、DOI 10.17487 / RFC5925、2010年6月、<https://www.rfc-editor.org/info / rfc5925>。
[RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., Ali, Z., and J. Meuric, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, <https://www.rfc-editor.org/info/rfc6006>.
[RFC6006] Zhao、Q.、Ed。、King、D.、Ed。、Verhaeghe、F.、Takeda、T.、Ali、Z.、J. Meuric、 "Extensions to the Path Computation Element Communication Protocol（PCEP ）ポイントツーマルチポイントトラフィックエンジニアリングラベルスイッチドパス」、RFC 6006、DOI 10.17487 / RFC6006、2010年9月、<https://www.rfc-editor.org/info/rfc6006>。
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, <https://www.rfc-editor.org/info/rfc6952>.
[RFC6952] Jethanandani、M.、Patel、K。、およびL. Zheng、「BGP、LDP、PCEP、およびMSDPの問題の分析（ルーティングプロトコルのキーイングおよび認証（KARP）設計ガイドによる」、RFC 6952、DOI 10.17487 / RFC6952、2013年5月、<https://www.rfc-editor.org/info/rfc6952>。
[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>。
[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>。
[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>。
o Updated the text to use the term "PCC" instead of "user" while describing the encoding rules in Section 3.10.
o セクション3.10でエンコーディングルールを説明しながら、「ユーザー」ではなく「PCC」という用語を使用するようにテキストを更新しました。
o Updated the example in Figure 7 to explicitly include the RP object.
o 図7の例を更新して、RPオブジェクトを明示的に含めるようにしました。
o Corrected the description of the F-bit in the RP object in Section 3.13, as per Erratum ID 3836.
o Erratum ID 3836に従って、セクション3.13のRPオブジェクトのFビットの説明を修正しました。
o Corrected the description of the fragmentation procedure for the response in Section 3.13.2, as per Erratum ID 3819.
o Erratum ID 3819に従って、セクション3.13.2の応答の断片化手順の説明を修正しました。
o Corrected the Error-Type for fragmentation in Section 3.15, as per Erratum ID 3830.
o エラータID 3830に従って、セクション3.15のフラグメンテーションのエラータイプを修正しました。
o Updated the references for the OSPF Router Information Link State Advertisement (LSA) [RFC7770] and the PCEP MIB [RFC7420].
o OSPFルーター情報リンク状態アドバタイズ（LSA）[RFC7770]およびPCEP MIB [RFC7420]の参照を更新しました。
o Added current information and references for PCEP YANG [PCEP-YANG] and PCEPS [RFC8253].
o PCEP YANG [PCEP-YANG]およびPCEPS [RFC8253]の現在の情報と参照を追加しました。
o Updated the Security Considerations section to include the TCP-AO and TLS.
o TCP-AOとTLSが含まれるように「セキュリティの考慮事項」セクションを更新しました。
o Updated the IANA Considerations section (Section 6.5) to mark codepoint 0 as "Reserved" for the Object-Type defined in this document, as per Erratum ID 4956 for [RFC5440]. IANA references have also been updated to point to this document.
o [RFC5440]のエラータID 4956に従って、このドキュメントで定義されているオブジェクトタイプのコードポイント0を「予約済み」としてマークするように、IANAの考慮事項セクション（セクション6.5）を更新しました。 IANAリファレンスもこのドキュメントを指すように更新されました。
Appendix A.1. RBNF Changes from RFC 6006
付録A.1。 RFC 6006からのRBNFの変更
o Updates to the RBNF for the request message format, per Erratum ID 4867:
o エラータID 4867に基づく、要求メッセージ形式のRBNFの更新：
* Updated the request message to allow for the bundling of multiple path computation requests within a single PCReq message.
* 単一のPCReqメッセージ内で複数のパス計算要求をバンドルできるように要求メッセージを更新しました。
* Added <svec-list> in PCReq messages. This object was missed in [RFC6006].
* PCReqメッセージに<svec-list>を追加しました。このオブジェクトは[RFC6006]で見逃されました。
* Added the BNC object in PCReq messages. This object is required to support P2MP. The BNC object shares the same format as the IRO, but it only supports IPv4 and IPv6 prefix sub-objects.
* PCReqメッセージにBNCオブジェクトを追加しました。このオブジェクトは、P2MPをサポートするために必要です。 BNCオブジェクトはIROと同じ形式を共有しますが、IPv4およびIPv6プレフィックスサブオブジェクトのみをサポートします。
* Updated the <RRO-List> format to also allow the SRRO. This object was missed in [RFC6006].
* SRROも許可するように<RRO-List>形式を更新しました。このオブジェクトは[RFC6006]で見逃されました。
* Removed the BANDWIDTH object followed by the RRO from <RRO-List>. The BANDWIDTH object was included twice in RFC 6006 -- once as part of <end-point-path-pair-list> and also as part of <RRO-List>. The latter has been removed, and the RBNF is backward compatible with [RFC5440].
* BANDWIDTHオブジェクトとそれに続くRROを<RRO-List>から削除しました。 BANDWIDTHオブジェクトは、RFC 6006に2回含まれています。1回は<end-point-path-pair-list>の一部として、また<RRO-List>の一部として含まれています。後者は削除され、RBNFは[RFC5440]と下位互換性があります。
* Updated the <end-point-rro-pair-list> to allow an optional BANDWIDTH object only if <RRO-List> is included.
* <RRO-List>が含まれている場合にのみオプションのBANDWIDTHオブジェクトを許可するように<end-point-rro-pair-list>を更新しました。
o Updates to the RBNF for the reply message format, per Erratum ID 4868:
o エラータID 4868に基づく、返信メッセージ形式のRBNFの更新：
* Updated the reply message to allow for bundling of multiple path computation replies within a single PCRep message.
* 単一のPCRepメッセージ内に複数のパス計算応答をバンドルできるように、応答メッセージを更新しました。
* Added the UNREACH-DESTINATION object in PCRep messages. This object was missed in [RFC6006].
* PCRepメッセージにUNREACH-DESTINATIONオブジェクトを追加しました。このオブジェクトは[RFC6006]で見逃されました。
Acknowledgements
謝辞
The authors would like to thank Adrian Farrel, Young Lee, Dan Tappan, Autumn Liu, Huaimo Chen, Eiji Oki, Nic Neate, Suresh Babu K, Gaurav Agrawal, Vishwas Manral, Dan Romascanu, Tim Polk, Stewart Bryant, David Harrington, and Sean Turner for their valuable comments and input on this document.
著者は、Adrian Farrel、Young Lee、Dan Tappan、Autumn Liu、Huaimo Chen、Eiko Oki、Nic Neate、Suresh Babu K、Gaurav Agrawal、Vishwas Manral、Dan Romascanu、Tim Polk、Stewart Bryant、David Harrington、およびSean Turner氏の貴重なコメントとこのドキュメントへの入力。
Thanks to Deborah Brungard for handling related errata for RFC 6006.
RFC 6006の関連エラッタを処理してくれたDeborah Brungardに感謝します。
The authors would like to thank Jonathan Hardwick and Adrian Farrel for providing review comments with suggested text for this document.
著者は、このドキュメントの推奨テキストを含むレビューコメントを提供してくれたJonathan HardwickとAdrian Farrelに感謝します。
Thanks to Jonathan Hardwick for being the document shepherd and for providing comments and guidance.
ドキュメントシェパードであり、コメントとガイダンスを提供してくれたJonathan Hardwickに感謝します。
Thanks to Ben Niven-Jenkins for RTGDIR reviews.
RTGDIRレビューを提供してくれたBen Niven-Jenkinsに感謝します。
Thanks to Roni Even for GENART reviews.
GENARTレビューをしてくれたRoni Evenに感謝します。
Thanks to Fred Baker for the OPSDIR review.
OPSDIRのレビューをしてくれたFred Bakerに感謝します。
Thanks to Deborah Brungard for being the responsible AD and guiding the authors.
責任あるADであり、著者を指導してくれたDeborah Brungardに感謝します。
Thanks to Mirja Kuehlewind, Alvaro Retana, Ben Campbell, Adam Roach, Benoit Claise, Suresh Krishnan, and Eric Rescorla for their IESG review and comments.
IESGのレビューとコメントを提供してくれたMirja Kuehlewind、Alvaro Retana、Ben Campbell、Adam Roach、Benoit Claise、Suresh Krishnan、Eric Rescorlaに感謝します。
Contributors
貢献者
Fabien Verhaeghe Thales Communication France 160 boulevard Valmy 92700 Colombes France Email: fabien.verhaeghe@gmail.com
Fabien Verhaeghe Thales Communication France 160 boulevard Valmy 92700 Colombes Franceメール：fabien.verhaeghe@gmail.com
Tomonori Takeda NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Email: tomonori.takeda@ntt.com
とものり たけだ んっｔ こｒぽらちおん ３ー９ー１１、 みどりーちょ むさしのーし、 ときょ １８０ー８５８５ じゃぱん えまいｌ： とものり。たけだ＠んっｔ。こｍ
Zafar Ali Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada Email: zali@cisco.com
Zafar Ali Cisco Systems、Inc. 2000イノベーションドライブカナタ、オンタリオK2K 3E8カナダメール：zali@cisco.com
Julien Meuric Orange 2, Avenue Pierre Marzin 22307 Lannion Cedex France Email: julien.meuric@orange.com
Julien Meuric Orange 2、Avenue Pierre Marzin 22307 Lannion Cedex Franceメール：julien.meuric@orange.com
Jean-Louis Le Roux Orange 2, Avenue Pierre Marzin 22307 Lannion Cedex France Email: jeanlouis.leroux@orange.com
Jean-Louis Le Roux Orange 2、Avenue Pierre Marzin 22307 Lannion Cedex Franceメール：jeanlouis.leroux@orange.com
Mohamad Chaitou France Email: mohamad.chaitou@gmail.com
Mohamad Chaitou Franceメール：mohamad.chaitou@gmail.com
Udayasree Palle Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: udayasreereddy@gmail.com
Udayasri Palle Huawei Technologies Divyashree Techno Park、Whitfield Bangalore、Karnataka 560066 India Email：udayasrireddy@gmail.com
Authors' Addresses
著者のアドレス
Quintin Zhao Huawei Technologies 125 Nagog Technology Park Acton, MA 01719 United States of America
Quintin Zhao Huawei Technologies 125 Nagog Technology Park Acton、MA 01719アメリカ合衆国
Email: quintin.zhao@huawei.com
Dhruv Dhody (editor) Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India
Dhruv Dhodoi（編集者）Huawei Technologies Divyashari Techno Park、Wheatfished Bangalore、Karnataka 2008インド
Email: dhruv.ietf@gmail.com
Ramanjaneya Reddy Palleti Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India
Ramanjaneya Reddy Palladti Hooverly Technologies Divyashree Techno Park、Wittefield Bangalore、Karnataka ೫೬೦೦೬೬インド
Email: ramanjaneya.palleti@huawei.com
Daniel King Old Dog Consulting United Kingdom
Daniel King Old Dog Consultingイギリス
Email: daniel@olddog.co.uk