[要約] RFC 6006は、PCEPを拡張して、ポイントツーマルチポイントトラフィックエンジニアリングのラベルスイッチパスをサポートするためのものです。目的は、PCEPを使用してポイントツーマルチポイントLSPの計算と制御を可能にすることです。
Internet Engineering Task Force (IETF) Q. Zhao, Ed.
Request for Comments: 6006 Huawei Technology
Category: Standards Track D. King, Ed.
ISSN: 2070-1721 Old Dog Consulting
F. Verhaeghe
Thales Communication France
T. Takeda
NTT Corporation
Z. Ali
Cisco Systems, Inc.
J. Meuric
France Telecom
September 2010
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）への拡張について説明します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6006.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6006で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Requirements Language ......................................5
2. PCC-PCE Communication Requirements ..............................5
3. Protocol Procedures and Extensions ..............................6
3.1. P2MP Capability Advertisement ..............................6
3.1.1. P2MP Computation TLV in the Existing PCE
Discovery Protocol ..................................6
3.1.2. Open Message Extension ..............................7
3.2. Efficient Presentation of P2MP LSPs ........................7
3.3. P2MP Path Computation Request/Reply Message Extensions .....8
3.3.1. The Extension of the RP Object ......................8
3.3.2. The New P2MP END-POINTS Object ......................9
3.4. Request Message Format ....................................12
3.5. Reply Message Format ......................................12
3.6. P2MP Objective Functions and Metric Types .................13
3.6.1. New Objective Functions ............................13
3.6.2. New Metric Object Types ............................14
3.7. Non-Support of P2MP Path Computation ......................14
3.8. Non-Support by Back-Level PCE Implementations .............15
3.9. P2MP TE Path Reoptimization Request .......................15
3.10. Adding and Pruning Leaves to/from the P2MP Tree ..........16
3.11. Discovering Branch Nodes .................................19
3.11.1. Branch Node Object ................................19
3.12. Synchronization of P2MP TE Path Computation Requests .....19
3.13. Request and Response Fragmentation .......................20
3.13.1. Request Fragmentation Procedure ...................21
3.13.2. Response Fragmentation Procedure ..................21
3.13.3. Fragmentation Examples ............................21
3.14. UNREACH-DESTINATION Object ...............................22
3.15. P2MP PCEP-ERROR Objects and Types ........................23
3.16. PCEP NO-PATH Indicator ...................................24
4. Manageability Considerations ...................................25
4.1. Control of Function and Policy ............................25
4.2. Information and Data Models ...............................25
4.3. Liveness Detection and Monitoring .........................25
4.4. Verifying Correct Operation ...............................25
4.5. Requirements for Other Protocols and Functional
Components ................................................26
4.6. Impact on Network Operation ...............................26
5. Security Considerations ........................................26
6. IANA Considerations ............................................27
6.1. PCEP TLV Type Indicators ..................................27
6.2. Request Parameter Bit Flags ...............................27
6.3. Objective Functions .......................................27
6.4. Metric Object Types .......................................27
6.5. PCEP Objects ..............................................28
6.6. PCEP-ERROR Objects and Types ..............................29
6.7. PCEP NO-PATH Indicator ....................................30
6.8. SVEC Object Flag ..........................................30
6.9. OSPF PCE Capability Flag ..................................30
7. Acknowledgements ...............................................30
8. References .....................................................30
8.1. Normative References ......................................30
8.2. Informative References ....................................32
The Path Computation Element (PCE) 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とPCES間の通信プロトコルとして設計され、[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のセットとして決定できます。計算。
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 sub-set of the S2L sub-LSPs. In the extreme case, the PCC may request the S2L sub-LSPs to be computed individually with it being the PCC's responsibility to decide 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.
このドキュメントは、PCCEPのメカニズムに依存して、P2MP TE LSPのパス計算を要求します。PCCからの1つのパス計算要求メッセージは、P2MP TE LSP全体の計算を要求する場合があります。または、リクエストがS2LサブLSPのサブセットに制限される場合があります。極端な場合、PCCは、個々のS2L Sub-LSPをシグナルと組み合わせてP2MP TE LSP全体を信号するかどうかを決定するPCCの責任であるため、S2L Sub-LSPを個別に計算するよう要求する場合があります。したがって、PCCは1つのパス計算要求メッセージを使用するか、複数のパス計算メッセージにリクエストを分割する場合があります。
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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
This section summarizes the PCC-PCE communication requirements for P2MP MPLS-TE LSPs described in [RFC5862]. The numbering system corresponds to the requirement numbers used in [RFC5862].
このセクションでは、[RFC5862]に記載されているP2MP MPLS-TE LSPのPCC-PCE通信要件をまとめたものです。番号付けシステムは、[RFC5862]で使用される要件数に対応しています。
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パス計算要求に適用することを指定できる必要があります。
3. The PCE MUST have the capability to reject a P2MP path 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によって返されるパスは圧縮形式を使用する必要があります。
8. It MUST be possible for a single P2MP path computation request or response to be conveyed by a sequence of messages.
8. 単一のP2MPパス計算リクエストまたは応答が一連のメッセージによって伝達される可能性がある必要があります。
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) defined in [RFC4970] to facilitate PCE discovery using OSPF. [RFC5088] specifies that no new sub-TLVs may be added to the PCED TLV. This document defines a new flag in the OSPF PCE Capability Flags to indicate the capability of P2MP computation.
[RFC5088]は、OSPFを使用したPCE発見を促進するために、[RFC4970]で定義されているOSPFルーター情報リンク状態広告（LSA）で運ばれるPCE発見（PCED）TLVを定義します。[RFC5088]は、PCED TLVに新しいサブTLVを追加できないことを指定しています。このドキュメントでは、P2MP計算の機能を示すために、OSPF PCE機能フラグの新しいフラグを定義します。
Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE Discovery using IS-IS. This document will use the same flag requested for the OSPF PCE Capability Flags sub-TLV to allow IS-IS to indicate the capability of P2MP computation.
同様に、[RFC5089]は、IS-ISを使用したPCE発見で使用するPCED SUB-TLVを定義します。このドキュメントは、IS-ISがP2MP計算の能力を示すことを可能にするために、OSPF PCE機能フラグSub-TLVに対して要求された同じフラグを使用します。
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パス計算をサポートすることを宣伝したいPCESは、それに応じてビット（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 New P2MP END-POINTS Object") to further qualify the level of support.
P2MPパス計算のサポートを示すためにビットを設定するPCES 3.3.2（「新しいP2MPエンドポイントオブジェクト」）の手順に従って、サポートレベルをさらに修飾する必要があります。
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機能を宣伝していない場合、PCCがPCCがP2MPパス計算をサポートできるオープンメッセージ交換中にPCCを発見できるようにするために使用する必要があります。。
To satisfy this requirement, we extend the PCEP OPEN object by defining a new optional TLV to indicate the PCE's capability to perform P2MP path computations.
この要件を満たすために、新しいオプションのTLVを定義してP2MPパス計算を実行するPCEの機能を示すことにより、PCEPオープンオブジェクトを拡張します。
IANA has allocated value 6 from the "PCEP TLV Type Indicators" sub-registry, 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.
IANAは、セクション6.1（「PCEP TLVタイプインジケーター」）で文書化されているように、「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を開いたオブジェクトに含めることは、送信者が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 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つのオープンメッセージのいずれかにのみ表示されます。ただし、PCE協力（例：ドメインなど）の場合、PCCとして動作するPCCがPCEセッションを開始する場合、パス計算機能も示す必要があります。
When specifying additional leaves, or 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 new path objects for efficiently passing the existing P2MP LSP between the PCE and PCC.
追加の葉を指定したり、[RFC5862]で指定されている既存のP2MP TE LSPを最適化する場合、リクエストメッセージと返信メッセージでPCCとPCE間の既存のP2MP LSPルート情報を渡す必要がある場合があります。これらの各シナリオでは、PCCと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 object 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 a 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 an ERO 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 SRRO 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]で定義されています。
A new PCEP object class and type are requested for SERO and SRRO.
SEROとSRROの新しいPCEPオブジェクトクラスとタイプが要求されます。
Object-Class Value 29
Name SERO
Object-Type 1: SERO
2-15: Unassigned
Reference RFC 6006
Object-Class Value 30
Name SRRO
Object-Type 1: SRRO
2-15: Unassigned
Reference RFC 6006
The IANA assignment is 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 PCC and PCE in the case of P2MP path computation.
このドキュメントは、既存のP2P RP（要求パラメーター）オブジェクトを拡張して、PCCがPCEP要求を受信するPCEにP2MPパス計算要求を信号することができるようにします。エンドポイントオブジェクトは、P2MPパス計算の場合にPCCとPCE間のメッセージ交換の効率を改善するために拡張されています。
The PCE path computation request and reply messages will need the following additional parameters to indicate to the receiving PCE that the request and reply messages have been fragmented across multiple messages, that they have been requested for a P2MP path, and whether the route is represented in the compressed or uncompressed format.
PCEパス計算要求と返信メッセージは、RequestおよびReplyメッセージが複数のメッセージで断片化されていること、P2MPパスに対してリクエストされていること、およびルートが表されるかどうかを受信PCEに示すために、次の追加パラメーターが必要です。圧縮または非圧縮形式。
This document adds the following flags to the RP Object: 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.
このドキュメントでは、次のフラグをRPオブジェクトに追加します。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.
nビットは、RPオブジェクトのフラグビットフィールドに追加されて、リクエスト/返信がP2MP用であるか、P2MP用ではないというメッセージの受信機に通知されます。
o N (P2MP bit - 1 bit):
o n（p2mpビット-1ビット）：
0: This indicates that this is not a PCReq or 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によって返されるパスは圧縮形式を使用する必要があります。
o E (ERO-compression bit - 1 bit):
o e（ero -compressionビット-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 assignment is 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 new types of END-POINTS objects for the P2MP path: o Old leaves whose path can be modified/reoptimized;
エンドポイントオブジェクトは、PCREQメッセージで使用され、ソースIPアドレスとパス計算が要求されるパスの宛先IPアドレスを指定します。P2MPパスのエンドポイントを効率的に表すために、P2MPパスの2つの新しいタイプのエンドポイントオブジェクトを定義します。
o Old leaves whose path must be left unchanged.
o その道は変わらないままにしなければならない古い葉。
With the new END-POINTS object, the PCE path computation request message is expanded in a way that allows a single request message to list multiple destinations.
新しいエンドポイントオブジェクトを使用すると、PCE Path Computation Requestメッセージは、複数の宛先をリストするための単一の要求メッセージを許可する方法で展開されます。
In total, there are now 4 possible types of leaves in a P2MP request:
合計で、P2MPリクエストには4種類の葉が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.
与えられたエンドポイントオブジェクトは、特定のタイプの葉を収集します。特定のエンドポイントオブジェクトの葉のタイプは、エンドポイントオブジェクトリーフタイプフィールドによって識別されます。
Using the new 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パスで最大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").
P2MPパス計算要求は、セクション3.4（「リクエストメッセージフォーマット」にあるPCREQルーティングバックナウルフォーム（RBNF）[RFC5511]形式に示すように、RPごとにいくつかのエンドポイントオブジェクトを含めることにより、さまざまなタイプの葉を混合できることに注意してください。）。
The format of the new END-POINTS object body for IPv4 (Object-Type 3) is as follows:
IPv4（Object-Type 3）の新しいエンドポイントオブジェクト本体の形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. The New P2MP END-POINTS Object Body Format for IPv4
図1. IPv4の新しいP2MPエンドポイントオブジェクトボディフォーマット
The format of the END-POINTS object body for IPv6 (Object-Type 4) is as follows:
IPv6（Object-Type 4）のエンドポイントオブジェクト本体の形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. The New P2MP END-POINTS Object Body Format for IPv6
図2. IPv6の新しいP2MPエンドポイントオブジェクトボディフォーマット
The END-POINTS object body has a variable length. These are multiples of 4 bytes for IPv4, and multiples of 16 bytes, plus 4 bytes, for IPv6.
エンドポイントオブジェクト本体の長さはさまざまです。これらは、IPv4の4バイトの倍数であり、16バイトの倍数に加えて、IPv6で4バイトです。
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>
<request>
where:
<request>::= <RP>
<end-point-rro-pair-list>
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<LOAD-BALANCING>]
where:
ただし：
<end-point-rro-pair-list>::=
<END-POINTS>[<RRO-List>][<BANDWIDTH>]
[<end-point-rro-pair-list>]
<RRO-List>::=<RRO>[<BANDWIDTH>][<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>]
Figure 3. The Message Format for the Request Message
図3.リクエストメッセージのメッセージ形式
Note that we preserve compatibility with the [RFC5440] definition of <request>. At least one instance of <endpoints> MUST be present in this message.
[RFC5440] <question>の定義との互換性を保持していることに注意してください。このメッセージには、<EndPoints>の少なくとも1つのインスタンスが存在する必要があります。
We have documented the IANA assignment of additional END-POINTS Object-Types in Section 6.5 ("PCEP Objects") of this document.
このドキュメントのセクション6.5（「PCEPオブジェクト」）に追加のエンドポイントオブジェクトタイプのIANA割り当てを文書化しました。
The PCRep message is encoded as follows using RBNF as defined in [RFC5511].
[RFC5511]で定義されているRBNFを使用して、PCREPメッセージは次のようにエンコードされます。
Below is the message format for the reply message:
以下は、返信メッセージのメッセージ形式です。
<PCRep Message>::= <Common Header>
<response>
<response>::=<RP>
[<end-point-path-pair-list>]
[<NO-PATH>]
[<attribute-list>]
where:
ただし：
<end-point-path-pair-list>::=
[<END-POINTS>]<path>[<end-point-path-pair-list>]
<path> ::= (<ERO>|<SERO>) [<path>]
<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.
返信メッセージのオプションのエンドポイントオブジェクトは、リクエストのためにどのパスが削除、変更され、変更されていないか、変更されていないかを指定するために使用されます。パスは、追加または変更されたエンドポイントにのみ必要です。
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-bit（ero-compressビット）がリクエストで1に設定されている場合、パスはEROによって形成され、その後にSEROのリストが作成されます。
Note that we preserve compatibility with the [RFC5440] definition of <response> and the optional <end-point-path-pair-list> and <path>.
[RFC5440] <応答>およびオプションの<end-point-path-pair-list>および<path>の定義との互換性を保持することに注意してください。
Six objective functions have been defined in [RFC5541] for P2P path computation.
P2Pパス計算のために、6つの目的関数が[RFC5541]で定義されています。
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 new objective function codes have to be defined.
このドキュメントは、P2MPパス計算に適用される2つの追加の目的関数、つまりSPT（最短パスツリー）とMCT（最小コストツリー）を定義します。したがって、2つの新しい目的関数コードを定義する必要があります。
The description of the two new objective functions is as follows.
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またはIGPメトリックなど）、デフォルトメトリックとして使用されるTEメトリックに関する最大ソース間コストを最小化します。
Objective Function Code: 8
目的関数コード：8
Name: Minimum Cost Tree (MCT)
名前：最小コストツリー（MCT）
Description: Minimize the total cost of the tree, that is 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 new 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 the hop count metric. 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. We propose the following values for these new metric types:
[RFC5440]の<メトリック>オブジェクトに対して定義された3つのタイプがあります。つまり、IGPメトリック、TEメトリック、およびホップカウントメトリックです。このドキュメントでは、<Metric>オブジェクトの3つの追加タイプを定義します。P2MPIGPメトリック、P2MP TEメトリック、およびP2MPホップカウントメトリックです。それらは、ツリーのすべてのリンクのメトリックの合計をエンコードします。これらの新しいメトリックタイプの次の値を提案します。
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 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. New Error-Types and Error-Values are requested in Section 6 ("IANA Considerations") of this document.
o PCEがP2MPパスリクエストを受信し、RPオブジェクトのP2MPフラグを理解しているが、PCEはP2MP計算ができない場合、PCEはPCEPエラーオブジェクトと対応するエラー値でPCERRメッセージを送信する必要があります。その後、リクエストはPCCでキャンセルする必要があります。このドキュメントのセクション6（「IANA考慮事項」）では、新しいエラータイプとエラー価値が要求されます。
o If the PCE does not understand the P2MP flag in the RP object, then the PCE MUST send a PCErr message with Error-value=2 (capability not supported).
o PCEがRPオブジェクトのP2MPフラグを理解していない場合、PCEはError-Value = 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はリクエストを拒否する必要があります。
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 user MUST insert the list of RROs and SRROs after each type of END-POINTS in the PCReq message, as described in the "Request Message Format" section (Section 3.4) of this document.
P2MP TEパスの再最適化要求は、[RFC5440]で定義されているRPオブジェクト内のRビットを使用することによって指定され、P2P TEパスの再オプチミー化要求に類似しています。唯一の違いは、このドキュメントの「リクエストメッセージ形式」セクション（セクション3.4）で説明されているように、PCREQメッセージの各タイプのエンドポイントの後に、ユーザーが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)
P2MPフラグ/rビットセットリーフタイプ3 RROリスト（オプション）のコモンヘッダー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-POINT 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を使用します。RROリストは、最適化の前にP2MP LSPを表し、修正可能なパスの葉はエンドポイントオブジェクトで示されます。
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フラグ/rビットセットリーフタイプ3 RROリストのエンドポイントを備えた一般的なヘッダーRP葉タイプ4 RROリストのエンドポイント（オプション）
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 SHOULD be 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 user MUST build a P2MP request using END-POINTS with leaf type 1.
新しい葉を追加するには、ユーザーはリーフタイプ1のエンドポイントを使用してP2MP要求を作成する必要があります。
To remove old leaves, the user must build a P2MP request using END-POINTS with leaf type 2. If no type-2 END-POINTS exist, then the PCE MUST send an error type 17, value=1: The PCE is not capable of satisfying the request due to no END-POINTS with leaf type 2.
古い葉を削除するには、ユーザーは葉のタイプ2を使用してエンドポイントを使用してP2MP要求を作成する必要があります。タイプ2エンドポイントが存在しない場合、PCEはエラータイプ17、値= 1：PCEは能力がありません。リーフタイプ2のエンドポイントがないため、リクエストを満たしています。
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. New PCEP-ERROR objects and types are necessary for reporting 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-POINT" error will be used if a PCC receives a request that has an inconsistent END-POINT (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、またはその両方を備えたエンドポイントを含む古い葉のリストも提供する必要があります。特定の条件が満たされていない場合（つまり、リーフタイプ3または4のエンドポイントがない場合、または葉のタイプ1または2のエンドポイントが存在する場合）、新しいPCEP-ERRORオブジェクトとタイプがレポートに必要です。PCCが一貫性のないエンドポイントを持つリクエストを受信した場合（つまり、タイプ1として指定された葉がすでに存在する場合）、一般的な「一貫性のないエンドポイント」エラーが使用されます。これらのIANAの割り当ては、このドキュメントのセクション6.6（「PCEP-Errorオブジェクトとタイプ」）に文書化されています。
For old leaves, the user 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.
古い葉の場合、ユーザーは、各エンドポイントオブジェクトをすぐに実行するRROSのリストとして古いパスを提供する必要があります。このドキュメントは、特定の条件が満たされていない場合にエラー値を指定します。
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フラグ/rビットの一般的なヘッダーRP葉タイプ1のエンドポイントのエンドポイント葉タイプ3 RROリストのエンドポイント（オプション）
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フラグ/Rビット付き共通ヘッダーRP葉のエンドポイント葉タイプ1エンドポイント葉タイプ3 RROリストのエンドポイント葉タイプ4 RROリスト（オプション）のエンドポイント
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フラグ/rビットの一般的なヘッダーRP葉タイプ1のエンドポイントのエンドポイント葉タイプ4 RROリストのエンドポイント（オプション）
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フラグ/rビットの一般的なヘッダーRP葉タイプ2のエンドポイント葉タイプ2のエンドポイント葉タイプ3 RROリストのエンドポイント（オプション）
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フラグ/rビット付き共通ヘッダーRP葉タイプ2 RROリストのエンドポイント葉タイプ3 RROリストのエンドポイントリーフタイプ4 RROリストのエンドポイント（オプション）
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フラグ/rビットの一般的なヘッダーRP葉タイプ2のエンドポイント葉タイプ2のエンドポイント葉タイプ4 RROリスト（オプション）のエンドポイント
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フラグ/rビット付き共通ヘッダーRP葉のエンドポイント葉タイプ1エンドポイントのエンドポイント葉タイプ2のエンドポイントリーフタイプ3 RROリストのエンドポイント（オプション）
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フラグ/rビット付き共通ヘッダーRP葉のエンドポイント葉タイプ1エンドポイント葉タイプ2のエンドポイントタイプ2 RROリスト葉タイプ3 RROリストのエンドポイント葉タイプ4 RROリストのエンドポイント（オプション）
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フラグ/rビット付き共通ヘッダーRP葉の葉タイプ1エンドポイントのエンドポイント葉タイプ2 RROリストのエンドポイント葉タイプ4 RROリストのエンドポイント（オプション）
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パスを計算する前に、PCEを提供する必要がある場合があります。ネットワーク内のどのノードがブランチLSRとして機能するかを知ることができます。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) defined in [RFC5440], except that it only supports IPv4 and IPv6 prefix sub-objects. Two Object-types are also defined:
PCCは、ブランチノードとして使用できるノードのリストまたはブランチノード機能（BNC）オブジェクトを使用して分岐ノードとして使用できないノードのリストを指定できます。BNCオブジェクトは、[RFC5440]で定義されているincludeルートオブジェクト（IRO）と同じ形式を持っていますが、IPv4およびIPv6プレフィックスサブオブジェクトのみをサポートすることを除きます。2つのオブジェクトタイプも定義されています。
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 Request may carry at most one Branch Node Object.
オブジェクトは、PCREQメッセージでのみ運ぶことができます。パス要求は、最大で1つのブランチノードオブジェクトを運ぶ場合があります。
The Object-Class and Object-types have been allocated by IANA. The IANA assignment is documented in Section 6.5 ("PCEP Objects").
オブジェクトクラスとオブジェクトタイプは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 Synchronization VECtor (SVEC) functionality 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つのP2MP LSPを同期する例は、それぞれがパス計算要求メッセージのために2つの葉を持っていることを以下に示します。
Common Header SVEC for sync of LSP1 and LSP2 OF (optional) END-POINTS1 for P2MP RRO1 list END-POINTS2 for P2MP RRO2 list
P2MP RRO1リストの（オプション）エンドポイント1のLSP1とLSP2の同期の共通ヘッダーSVEC P2MP RRO2リストのエンドポイント2
Figure 7. PCReq Message Example for Synchronization
図7.同期のPCREQメッセージ例
This specification also defines two new flags to the SVEC Object Flag Field for P2MP path dependent computation requests. The first new flag is to allow 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, would allow 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 assignment is 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 has been outlined in "The Extension of the RP Object" (Section 3.3.1) of this document. The F-bit is used in the RP object header 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ビットは、このドキュメントの「RPオブジェクトの拡張」（セクション3.3.1）で概説されています。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.
最初の要求が大きすぎて単一の要求メッセージに収まると、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 to 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に送信されます。応答が大きすぎて単一の応答メッセージに適合できない場合、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 the Req-ID1 specified in the RP object, and with the F-bit set on the first message, and cleared on the second message.
次の例は、PCCがPCEにREQ-ID1を使用して要求メッセージを送信し、1200の葉のある既存のツリーに1つの葉を追加することを示しています。この例で使用される仮定は、1つの要求メッセージが最大800枚の葉を保持できることです。このシナリオでは、元の単一のメッセージを断片化し、2つの小さなメッセージを使用して送信する必要があります。これらの2つの小さなメッセージは、RPオブジェクトで指定され、最初のメッセージにfビットが設定され、2番目のメッセージでクリアされます。
Common Header RP1 with Req-ID1 and P2MP=1 and F-bit=1 OF (optional) END-POINTS1 for P2MP RRO1 list
p2mp rro1リストの（オプション）エンドポイントのReq-id1およびp2mp = 1およびf-bit = 1の共通ヘッダーRP1
Common Header RP2 with Req-ID1 and P2MP=1 and F-bit=0 OF (optional) END-POINTS1 for P2MP RRO1 list
p2mp rro1リストの（オプション）エンドポイントのReq-id1およびp2mp = 1およびf-bit = 0の共通ヘッダーRP2
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. When the timer expires and it 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.
そのような場合、到達しない捨てオブジェクトにより、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 will be required:
以下の到達しないオブジェクトが必要になります。
UNREACH-DESTINATION Object-Class is 28. UNREACH-DESTINATION Object-Type for IPv4 is 1. UNREACH-DESTINATION Object-Type for IPv6 is 2.
到達しないdestinationオブジェクトクラスは28です。IPv4の非到達境界オブジェクトタイプは1です。
The format of the UNREACH-DESTINATION object body for IPv4 (Object-Type=1) is as follows:
IPv4（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の到達除去オブジェクト本文
The format of the UNREACH-DESTINATION object body for IPv6 (Object-Type=2) is as follows:
IPv6（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用の到達除去オブジェクト本体
To indicate an error associated with policy violation, a new error value "P2MP Path computation not allowed" should be added to the existing error code for policy violation (Error-Type=5) as defined in [RFC5440]: 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 (Error-Value=7). The corresponding P2MP path computation request MUST also be cancelled.
ポリシー違反に関連するエラーを示すために、[RFC5440]で定義されているように、ポリシー違反のために既存のエラーコード（エラータイプ= 5）のために既存のエラーコードに追加される必要があります。;エラーValue = 7：PCEが管理権に準拠していないP2MPパス計算要求を受信した場合（つまり、「PCEポリシーはP2MPパス計算をサポートしない」）、PCEはPCEP-ErrorでPCERRメッセージを送信する必要があります。オブジェクト（エラータイプ= 5）およびエラー値（エラー値= 7）。対応するP2MPパス計算要求もキャンセルする必要があります。
To indicate capability errors associated with the P2MP path request, a new Error-Type (16) and subsequent error-values are defined as follows for inclusion in the PCEP-ERROR object:
P2MPパス要求に関連付けられた機能エラーを示すために、新しいエラータイプ（16）とその後のエラー値は、PCEP-Errorオブジェクトに含めるための次のように定義されます。
Error-Type=16; Error-Value=1: if a PCE receives a P2MP path 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 (Error-Value=1). The corresponding P2MP path computation request MUST also be cancelled.
エラータイプ= 16;エラー値= 1：PCEがP2MPパス要求を受信し、PCEがメモリが不十分であるためにリクエストを満たすことができない場合、PCEはPCEP-Errorオブジェクト（エラータイプ= 16）でPCERRメッセージを送信する必要があります。エラー値（エラー値= 1）。対応するP2MPパス計算要求もキャンセルする必要があります。
Error-Type=16; Error-Value=2: if a PCE receives a P2MP path 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 (Error-Value=2). The corresponding P2MP path computation request MUST also be cancelled.
エラータイプ= 16;エラー-Value = 2：PCEがP2MPパス要求を受信し、PCEがP2MP計算を行うことができない場合、PCEはPCEP-Errorオブジェクト（エラータイプ= 16）とエラー値（エラー値）でPCERRメッセージを送信する必要があります。エラー値= 2）。対応するP2MPパス計算要求もキャンセルする必要があります。
To indicate P2MP message fragmentation errors associated with a P2MP path request, a new Error-Type (17) and subsequent error-values are defined as follows for inclusion in the PCEP-ERROR object:
P2MPパスリクエストに関連付けられたP2MPメッセージフラグメンテーションエラーを示すために、新しいエラータイプ（17）とその後のエラー値は、PCEP-Errorオブジェクトに含めるための次のように定義されます。
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 (Error-Value=1).
エラータイプ= 18;error-value = 1：PCEが断片化されたメッセージの最後の部分を受信していない場合、エラーメッセージを送信者に送信して、不完全なメッセージ（つまり、「断片化された要求障害」）を受信したことを信号します。PCEは、PCEP-ERRORオブジェクト（エラータイプ= 18）とエラー値（エラー値= 1）を使用してPCERRメッセージを送信する必要があります。
To communicate the reasons for not being able to find P2MP path computation, the NO-PATH object can be used in the PCRep message.
P2MPパス計算を見つけることができない理由を通信するには、PCREPメッセージでNO-PATHオブジェクトを使用できます。
One new bit is defined in the NO-PATH-VECTOR TLV carried in the NO-PATH Object:
1つの新しいビットは、No-Pathオブジェクトで運ばれたNo-Path-Vector TLVで定義されています。
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 new UNREACH-DESTINATION object defined in Section 3.14.
ビット24：設定すると、PCEは、P2MP宛先のすべてまたはサブセットに到達可能性の問題があることを示します。オプションで、PCEは、セクション3.14で定義されている新しい未到達のオブジェクトを使用して到達できない宛先の宛先またはリストを指定できます。
[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 in 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 ability to enable or disable P2MP path computations on the PCE.
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 ("P2MP Computation TLV in the Existing PCE Discovery Protocol"), or during the Open Message Exchange discussed in Section 3.1.2 ("Open Message Extension").
o PCEは、P2MPパス計算機能の広告を有効または無効にするように構成されている場合があります。PCEは、セクション3.1.1（「既存のPCEディスカバリープロトコルでのP2MP計算TLV」）で説明されているIGP発見メカニズムを介して、またはセクション3.1.2（「オープンメッセージ拡張子」で説明したオープンメッセージ交換中に、P2MP機能を宣伝できます。）。
A number of MIB objects have been defined for general PCEP control and monitoring of P2P computations in [PCEP-MIB]. [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.
[PCEP-MIB]のP2P計算の一般的なPCEP制御と監視のために、多くのMIBオブジェクトが定義されています。[RFC5862]は、このドキュメントで定義されているプロトコル拡張の制御と監視をサポートするためにMIBオブジェクトが必要であることを指定します。PCEP制御とP2MP計算の監視のためのMIBオブジェクトを定義するには、新しいドキュメントが必要です。
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 ("P2MP Computation TLV in the Existing PCE Discovery Protocol") of this document.
PCEがOSPFおよびIS-ISを介してP2MPパス計算が可能なPCEに関する情報を取得する方法については、このドキュメントのセクション3.1.1（既存のPCE発見プロトコルのP2MP計算TLV」）で説明します。
The subsequent IANA assignments are 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状態が必要になる場合があります。主要なネットワーク障害と複数の回復P2MPツリー計算要求がPCEに送信される場合、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 of [RFC5440] that specifically help to minimize or negate unauthorized P2MP path computation requests and denial of service attacks. These mechanisms include:
[RFC5862]で説明されているように、P2MPパス計算要求はよりCPU集約型であり、より多くのリンク帯域幅を利用します。許可されていないP2MPパス計算要求、またはサービス攻撃の拒否が発生した場合、その後のPCEP要求と処理はネットワークを破壊する可能性があります。その結果、実装が[RFC5440]の関連するセキュリティ要件に準拠することが重要です。これは、不正なP2MPパス計算リクエストとサービス攻撃の拒否を最小限に抑えるか否定するのに役立ちます。これらのメカニズムには次のものが含まれます。
o Securing the PCEP session requests and responses using TCP security techniques (Section 10.2 of [RFC5440]).
o TCPセキュリティ手法を使用したPCEPセッション要求と応答を保護する（[RFC5440]のセクション10.2）。
o Authenticating the PCEP requests and responses to ensure the message is intact and sent from an authorized node (Section 10.3 of [RFC5440]).
o PCEPリクエストと応答を認証して、メッセージが無傷であることを確認し、認定ノード（[RFC5440]のセクション10.3）から送信されます。
o Providing policy control by explicitly defining which PCCs, via IP access-lists, are allowed to send P2MP path requests to the PCE (Section 10.6 of [RFC5440]).
o IP Access-Listsを介してどのPCCを定義するかを明示的に定義することにより、ポリシー管理を提供することは、P2MPパス要求をPCEに送信することができます（[RFC5440]のセクション10.6）。
PCEP operates over TCP, so it is also important to secure the PCE and PCC against TCP denial of service attacks. Section 10.7.1 of [RFC5440] outlines a number of mechanisms for minimizing the risk of TCP based denial of service attacks against PCEs and PCCs.
PCEPはTCPを超えて動作するため、TCPサービス攻撃に対してPCEとPCCを保護することも重要です。[RFC5440]のセクション10.7.1は、PCESおよびPCCに対するTCPベースのサービス攻撃のリスクを最小限に抑えるための多くのメカニズムの概要を示しています。
PCEP implementations SHOULD consider the additional security provided by the TCP Authentication Option (TCP-AO) [RFC5925].
PCEP実装では、TCP認証オプション（TCP-AO）[RFC5925]によって提供される追加のセキュリティを考慮する必要があります。
IANA maintains a registry of PCEP parameters. A number of IANA considerations have been highlighted in previous sections of this document. IANA has made the following allocations.
IANAは、PCEPパラメーターのレジストリを維持しています。この文書の以前のセクションでは、多くのIANAの考慮事項が強調されています。Ianaは次の割り当てを行いました。
As described in Section 3.1.2., the newly defined P2MP capability TLV allows the PCE to advertise its P2MP path computation capability. IANA has made the following allocation from the "PCEP TLV Type Indicators" sub-registry.
セクション3.1.2で説明したように、新しく定義されたP2MP機能TLVにより、PCEはP2MPパス計算機能を宣伝できます。IANAは、「PCEP TLVタイプインジケーター」サブレジストリから次の割り当てを行いました。
Value Description Reference
6 P2MP capable RFC 6006
As described in Section 3.3.1, three new RP Object Flags have been defined. IANA has made the following allocations from the PCEP "RP Object Flag Field" sub-registry:
セクション3.3.1で説明したように、3つの新しいRPオブジェクトフラグが定義されています。IANAは、PCEP「RPオブジェクトフラグフィールド」サブレジストリから次の割り当てを行いました。
Bit Description Reference
ビット説明リファレンス
18 Fragmentation (F-bit) RFC 6006 19 P2MP (N-bit) RFC 6006 20 ERO-compression (E-bit) RFC 6006
18断片化（F-BIT）RFC 6006 19 P2MP（N-BIT）RFC 6006 20 ERO-Compression（EBIT）RFC 6006
As described in Section 3.6.1, two new Objective Functions have been defined. IANA has made the following allocations from the PCEP "Objective Function" sub-registry:
セクション3.6.1で説明されているように、2つの新しい目的関数が定義されています。IANAは、PCEP「目的関数」サブレジストリから次の割り当てを行いました。
Code Point Name Reference
コードポイント名の参照
7 SPT RFC 6006
8 MCT RFC 6006
As described in Section 3.6.2, three new metric object T fields have been defined. IANA has made the following allocations from the PCEP "METRIC Object T Field" sub-registry:
セクション3.6.2で説明したように、3つの新しいメトリックオブジェクトTフィールドが定義されています。IANAは、PCEP「メトリックオブジェクトTフィールド」サブレジストリから次の割り当てを行いました。
Value Description Reference
8 P2MP IGP metric RFC 6006
9 P2MP TE metric RFC 6006
10 P2MP hop count metric RFC 6006
As discussed in Section 3.3.2, two new END-POINTS Object-Types are defined. IANA has made the following Object-Type allocations from the "PCEP Objects" sub-registry:
セクション3.3.2で説明したように、2つの新しいエンドポイントオブジェクトタイプが定義されています。IANAは、「PCEPオブジェクト」サブレジストリから次のオブジェクトタイプの割り当てを作成しました。
Object-Class Value 4
Name END-POINTS
Object-Type 3: IPv4
4: IPv6
5-15: Unassigned
Reference RFC 6006
As described in Section 3.2, Section 3.11.1, and Section 3.14, four PCEP Object-Classes and six PCEP Object-Types have been defined. IANA has made the following allocations from the "PCEP Objects" sub-registry:
セクション3.2、セクション3.11.1、およびセクション3.14で説明されているように、4つのPCEPオブジェクトクラスと6つのPCEPオブジェクトタイプが定義されています。IANAは、「PCEPオブジェクト」サブレジストリから次の割り当てを行いました。
Object-Class Value 28
Name UNREACH-DESTINATION
Object-Type 1: IPv4
2: IPv6
3-15: Unassigned
Reference RFC 6006
Object-Class Value 29
Name SERO
Object-Type 1: SERO
2-15: Unassigned
Reference RFC 6006
Object-Class Value 30
Name SRRO
Object-Type 1: SRRO
2-15: Unassigned
Reference RFC 6006
Object-Class Value 31
Name Branch Node Capability Object
Object-Type 1: Branch node list
2: Non-branch node list
3-15: Unassigned
Reference RFC 6006
As described in Section 3.15, a number of new PCEP-ERROR Object Error Types and Values have been defined. IANA has made the following allocations from the PCEP "PCEP-ERROR Object Error Types and Values" sub-registry:
セクション3.15で説明したように、多くの新しいPCEP-ERRORオブジェクトエラータイプと値が定義されています。IANAは、PCEPから「PCEP-ERRORオブジェクトエラータイプと値」から次の割り当てを行いました。
Error Type Meaning Reference
エラータイプの意味参照
5 Policy violation Error-value=7: RFC 6006 P2MP Path computation is not allowed
5ポリシー違反エラー値= 7：RFC 6006 P2MPパス計算は許可されていません
16 P2MP Capability Error Error-Value=0: Unassigned RFC 6006 Error-Value=1: RFC 6006 The PCE is not capable to satisfy the request due to insufficient memory Error-Value=2: RFC 6006 The PCE is not capable of P2MP computation
16 P2MP機能エラーエラー値= 0：割り当てられていないRFC 6006エラー値= 1：RFC 6006 PCEは、メモリエラー値が不十分なため、リクエストを満たすことができません= 2：RFC 6006 PCEはP2MP計算ができません
17 P2MP END-POINTS Error Error-Value=0: Unassigned RFC 6006 Error-Value=1: RFC 6006 The PCE is not capable to satisfy the request due to no END-POINTS with leaf type 2 Error-Value=2: RFC 6006 The PCE is not capable to satisfy the request due to no END-POINTS with leaf type 3 Error-Value=3: RFC 6006 The PCE is not capable to satisfy the request due to no END-POINTS with leaf type 4 Error-Value=4: RFC 6006 The PCE is not capable to satisfy the request due to inconsistent END-POINTS
17 P2MPエンドポイントエラーエラー値= 0：割り当てられていないRFC 6006エラー値= 1：RFC 6006 PCEは、リーフタイプ2エラーと価値のあるエンドポイントがないため、リクエストを満たすことができません= 2：RFC 6006PCEは、リーフタイプ3のエンドポイントがないため、リクエストを満たすことができません。4：RFC 6006 PCEは、一貫性のないエンドポイントのためにリクエストを満たすことができません
18 P2MP Fragmentation Error Error-Value=0: Unassigned RFC 6006 Error-Value=1: RFC 6006 Fragmented request failure
18 P2MPフラグメンテーションエラーエラー値= 0：未割り当てRFC 6006エラー値= 1：RFC 6006断片化要求障害
As discussed in Section 3.16, a new NO-PATH-VECTOR TLV Flag Field has been defined. IANA has made the following allocation from the PCEP "NO-PATH-VECTOR TLV Flag Field" sub-registry:
セクション3.16で説明したように、新しいNo-Path-Vector TLVフラグフィールドが定義されています。IANAは、PCEP「No-Path-Vector TLV Flagフィールド」から次の割り当てを行いました。
Bit Description Reference
ビット説明リファレンス
24 P2MP Reachability Problem RFC 6006
24 P2MPリーチビリティ問題RFC 6006
As discussed in Section 3.12, two new SVEC Object Flags are defined. IANA has made the following allocation from the PCEP "SVEC Object Flag Field" sub-registry:
セクション3.12で説明したように、2つの新しいSVECオブジェクトフラグが定義されています。IANAは、PCEP「SVECオブジェクトフラグフィールド」から次の割り当てを行いました。
Bit Description Reference
ビット説明リファレンス
19 Partial Path Diverse RFC 6006
20 Link Direction Diverse RFC 6006
As discussed in Section 3.1.1, a new OSPF Capability Flag is defined to indicate P2MP path computation capability. IANA has made the following assignment from the OSPF Parameters "Path Computation Element (PCE) Capability Flags" registry:
セクション3.1.1で説明したように、P2MPパス計算機能を示すために新しいOSPF機能フラグが定義されています。IANAは、OSPFパラメーター「パス計算要素（PCE）機能フラグ」レジストリから次の割り当てを行いました。
Bit Description Reference
ビット説明リファレンス
10 P2MP path computation RFC 6006
10 P2MPパス計算RFC 6006
The authors would like to thank Adrian Farrel, Young Lee, Dan Tappan, Autumn Liu, Huaimo Chen, Eiji Okim, Nick Neate, Suresh Babu K, Dhruv Dhody, Udayasree Palle, Gaurav Agrawal, Vishwas Manral, Dan Romascanu, Tim Polk, Stewart Bryant, David Harrington, and Sean Turner for their valuable comments and input on this document.
著者は、エイドリアン・ファレル、ヤング・リー、ダン・タッパン、オータム・リュー、フアイモ・チェン、エイジ・オキム、ニック・ニーテ、スレシュ・バブ・K、ドゥーヤブ・ドディ、ウダイアスリー・パール、ガウラフ・アグラワル、ヴィシュワス・マンラル、ダン・ロマスカヌ、ティム・ポーク、スチュワート・ポークに感謝したいと思います。ブライアント、デビッドハリントン、およびショーンターナーは、この文書に関する貴重なコメントと情報について。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「Gmplsセグメントリカバリー」、RFC 4873、2007年5月。
[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, May 2007.
[RFC4875] Aggarwal、R.、ed。、ed。、Papadimitriou、D.、ed。、およびS. Yasukawa、ed。、「リソース予約プロトコルへの拡張 - ポイントツーマルチポイントTEラベルの交通工学（RSVP-TE）スイッチPaths（LSP） "、RFC 4875、2007年5月。
[RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, July 2007.
[RFC4970] Lindem、A.、Ed。、Shen、N.、Vasseur、Jp。、Aggarwal、R。、およびS. Shaffer、「オプションのルーター機能の広告のためのOSPFへの拡張」、RFC 4970、2007年7月。
[RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", RFC 5073, December 2007.
[RFC5073] Vasseur、J.、ed。、およびJ. Le Roux、ed。、「トラフィックエンジニアリング機能の発見のためのIGPルーティングプロトコル拡張」、RFC 5073、2007年12月。
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008.
[RFC5088] Le Roux、Jl。、ed。、vasseur、Jp。、ed。、Ikejiri、Y.、およびR. Zhang、「Path Computation Element（PCE）DiscoveryのOSPFプロトコル拡張」、RFC 5088、2008年1月。
[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, January 2008.
[RFC5089] Le Roux、Jl。、ed。、Vasseur、JP。、Ed。、Ikejiri、Y.、およびR. Zhang、「IS-IS Path Computation Element（PCE）DiscoveryのIS-ISプロトコル拡張」、RFC 5089、1月2008年。
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009.
[RFC5511] Farrel、A。、「ルーティングバックスノーフォーム（RBNF）：さまざまなルーティングプロトコル仕様でエンコードルールを形成するために使用される構文」、RFC 5511、2009年4月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、Jp。、ed。、およびJl。Le Roux、ed。、「パス計算要素（PCE）通信プロトコル（PCEP）」、RFC 5440、2009年3月。
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, June 2009.
[RFC5541] Le Roux、Jl。、Vasseur、Jp。、およびY. Lee、「パス計算要素通信プロトコル（PCEP）における目的関数のエンコード」、RFC 5541、2009年6月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657] Ash、J.、ed。、およびJ. Le Roux、ed。、「Path Computation Element（PCE）通信プロトコルジェネリック要件」、RFC 4657、2006年9月。
[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, October 2009.
[RFC5671] Yasukawa、S。and A. Farrel、ed。、「Path-to-Multipoint（P2MP）MPLSおよびGMPLSトラフィックエンジニアリング（TE）へのパス計算要素（PCE）の適用可能性」、RFC 5671、2009年10月。
[RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE", RFC 5862, June 2010.
[RFC5862] Yasukawa、S。およびA. Farrel、「Path-To-MultiPoint MPLS-TEのパス計算要素（PCC）要件」、RFC 5862、2010年6月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「TCP認証オプション」、RFC 5925、2010年6月。
[PCEP-MIB] Koushik, K., Stephan, E., Zhao, Q., and D. King, "PCE communication protocol (PCEP) Management Information Base", Work in Progress, July 2010.
[PCEP-MIB] Koushik、K.、Stephan、E.、Zhao、Q.、およびD. King、「PCE Communication Protocol（PCEP）管理情報ベース」、2010年7月の作業。
Contributors
貢献者
Jean-Louis Le Roux France Telecom 2, Avenue Pierre-Marzin 22307 Lannion Cedex France EMail: jeanlouis.leroux@orange-ftgroup.com
Jean-Louis Le Roux France Telecom 2、Avenue Pierre-Marzin 22307 Lannion Cedex Franceメール：jeanlouis.leroux@orange-ftgroup.com
Mohamad Chaitou France EMail: mohamad.chaitou@gmail.com
Mohamad Chaitou Franceメール：mohamad.chaitou@gmail.com
Authors' Addresses
著者のアドレス
Quintin Zhao (editor) Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US EMail: qzhao@huawei.com
Quintin Zhao（編集者）Huawei Technology 125 Nagog Technology Park Acton、MA 01719 US Email：Qzhao@huawei.com
Daniel King (editor) Old Dog Consulting UK EMail: daniel@olddog.co.uk
ダニエル・キング（編集者）老犬コンサルティング英国メール：daniel@olddog.co.uk
Fabien Verhaeghe Thales Communication France 160 Bd Valmy 92700 Colombes France EMail: fabien.verhaeghe@gmail.com
Fabien Verhaeghe Thales Communication France 160 BD Valmy 92700 Colombes France Email：Fabien.verhaeghe@gmail.com
Tomonori Takeda NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan EMail: takeda.tomonori@lab.ntt.co.jp
Tomonori Takeda NTT Corporation 3-9-11、Midori-Cho Musashino-Shi、Tokyo 180-8585日本メール：takeda.tomonori@lab.ntt.co.jp
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 France Telecom 2, Avenue Pierre-Marzin 22307 Lannion Cedex France EMail: julien.meuric@orange-ftgroup.com
Julien Meuric France Telecom 2、Avenue Pierre-Marzin 22307 Lannion Cedex Franceメール：julien.meuric@orange-ftgroup.com