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
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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]はポイント・ツー・マルチポイント（P2MP）トラフィックエンジニアリングラベルが（MPLS）をマルチプロトコルラベルスイッチングで使用するために（TE LSPを）パスを交換し、一般化MPLS（GMPLS）ネットワークセットアップする方法について説明します。
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 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.
この文書では、P2MP TE LSPのためのパス計算を要求するPCEPのメカニズムに依存しています。 PCCから一つの経路計算要求メッセージ全体P2MP TE LSPの計算を要求することができる、または要求がS2LサブLSPのサブセットに制限されてもよいです。極端な場合には、PCCは、それが個々のS2LサブLSPを信号または全体P2MP TE LSPをシグナリングするために計算結果を結合するかどうかを決定するPCCの責任であると個別に計算されるS2LサブLSPを要求することができます。従ってPCCは、一の経路計算要求メッセージを使用してもよいし、複数の経路計算メッセージを横切って要求を分割してもよいです。
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. A P2MP経路計算要求は、複数の送信先を一覧表示することができなければなりません。
6. A P2MP path computation response MUST be able to carry the path of a P2MP LSP.
6. A 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.
単一P2MP経路計算要求が異なる制約、トラフィックパラメータ、またはP2MP LSPの異なる宛先のためのサービス品質要件のセットを指定するために9それは可能にすることはできません。
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.
PCCは、P2MP経路計算能力を発見するため14.ことが可能でなければなりません。
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]は新しいサブのTLVは、TLV PCEDに添加しなくてもよいことを指定します。この文書では、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サブTLVを定義します。この文書では、許可するように、サブTLV OSPF PCE能力フラグのために要求された同じフラグを使用しますP2MP計算の性能を示すために、IS-IS。
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.
IANAの共有OSPFの割り当てとP2MP能力フラグIS-ISは、このドキュメントのセクション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経路計算はそれに応じて（10）ビットを設定しますサポートすることをアドバタイズすることを望むのPCE。このビットを理解していないの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経路計算のサポートを示すためにビットを設定するのPCEは、さらなる支持のレベルを修飾するために、セクション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.
PCEは、ディスカバリ中にそのP2MP能力をアドバタイズしない場合は[RFC5862]に記載の機能交換の要件に基づいて、PCEP支持P2MP経路計算が可能であるのPCEオープンメッセージ交換中に、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.
この要件を満たすために、我々はP2MPパスの計算を実行するためにPCEの能力を示すために、新しいオプションのTLVを定義することによって、PCEP OPENオブジェクトを拡張します。
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.
セクション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.
OPENオブジェクトでこの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は、その経路計算能力をも示すべきPCEセッションを開始するように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の経路情報を渡し、メッセージを返信する必要があるかもしれません。これらの各シナリオでは、我々は効率的に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 object are defined in [RFC3209] and [RFC3473].
私たちは、ネットワークを介してTE LSPのルートを明示的にエンコードするためにリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張明示的なルートオブジェクト（ERO）の使用を指定します。 PCEP EROサブオブジェクトタイプはEROサブオブジェクトタイプ-TEをRSVPに対応します。 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]で定義されるEROと[RFC3473]と同じです。
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.
新しいPCEPオブジェクトクラスとタイプがSEROとSRROのために要求されています。
Object-Class Value 29 Name SERO Object-Type 1: SERO 2-15: Unassigned Reference RFC 6006
オブジェクトクラス値29名SEROオブジェクト・タイプ1：SERO 2-15：未割り当て参考RFC 6006
Object-Class Value 30 Name SRRO Object-Type 1: SRRO 2-15: Unassigned Reference RFC 6006
オブジェクトクラス値30名前SRROオブジェクト・タイプ1：SRRO 2-15：未割り当て参考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.
PCCは、PCEP要求を受信PCEにP2MP経路計算要求をシグナリングすることができるように、この文書では、既存のP2P RP（要求パラメータ）オブジェクトを拡張します。エンドポイントオブジェクトは、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の経路計算要求と、それらがP2MP経路のために要求されていることを、複数のメッセージを横切って断片化されたメッセージを、その要求受信PCEに指示し、応答するために、次の追加のパラメータを必要とするメッセージを返信し、ルートはで表現されているか否か圧縮または非圧縮フォーマット。
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で、0に設定F-ビットで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ビットは、要求/応答がP2MPのためのものであるか、P2MPのためではないメッセージの受信を知らせるためにRPオブジェクトのフラグビットフィールドに追加されます。
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圧縮ビット - 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;
エンドポイントオブジェクトは、送信元IPアドレスと経路計算が要求されているパスの宛先IPアドレスを指定するPCReqメッセージで使用されています。効率P2MP経路の終了点を表すために、我々は、エンドポイントの二つの新しいタイプを定義するには、P2MP経路のためのオブジェクト：古いは、そのパス再最適化/修飾することができる葉Oであり;
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の経路計算要求メッセージは、単一の要求メッセージが複数の宛先を一覧表示することを可能にする方法で展開されます。
In total, there are now 4 possible types of leaves in a P2MP request:
合計では、葉の4つの可能なタイプはP2MP要求で今があります。
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").
PCReqルーティングバッカスナウア記法（RBNF）に示すように、P2MP経路計算要求は、いくつかのエンドポイントを含むことにより、葉の種類を混在させることができることに注意してくださいは、RPオブジェクトごとのオブジェクト[RFC5511]セクション3.4（「要求メッセージフォーマット」でフォーマット）。
The format of the new END-POINTS object body for IPv4 (Object-Type 3) is as follows:
次のように新しいエンドポイントのフォーマット（オブジェクトタイプ3）IPv4の本体を目的とします。
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.新しいP2MPエンドポイントは、IPv4のためのボディフォーマットオブジェクト
The format of the END-POINTS object body for IPv6 (Object-Type 4) is as follows:
以下のようにエンドポイントのフォーマット（オブジェクトタイプ4）IPv6の本体を目的とします。
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
新P2MPエンドポイント2.図は、IPv6のためのボディフォーマットオブジェクト
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バイトの倍数、およびIPv6のための16バイトを加えた4バイトの倍数です。
The PCReq message is encoded as follows using RBNF as defined in [RFC5511].
[RFC5511]で定義されるようRBNFを用いて以下のようPCReqメッセージが符号化されます。
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]の定義との互換性を維持することに注意してください。 <エンドポイント>の少なくとも一つのインスタンスがこのメッセージに存在しなければなりません。
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ビット（ERO-圧縮ビット）は、要求に1に設定された場合、パスはSEROsのリストが続くEROによって形成されます。
Note that we preserve compatibility with the [RFC5440] definition of <response> and the optional <end-point-path-pair-list> and <path>.
我々は[RFC5440]の定義<応答>およびオプションの<エンドポイントパスペアリスト>および<パス>との互換性を維持することに留意されたいです。
Six objective functions have been defined in [RFC5541] for P2P path computation.
シックス・目的関数は、P2P経路計算のために[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経路計算に適用され、すなわち、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].
これら二つの新しい目的関数を処理して、[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:
すなわち、IGPメトリック、TEメトリック、およびホップ数メトリック - [RFC5440]で<METRIC>オブジェクトに定義された3つのタイプがあります。 P2MP IGPメトリック、P2MP TEメトリック、およびP2MPホップカウントメトリック：この文書では、<METRIC>オブジェクトのための3つの追加のタイプを定義します。彼らは、ツリーのすべてのリンクのメトリックの合計を符号化します。我々は、これらの新しい評価指標タイプのため、以下の値を提案します：
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.
PCEは、P2MP経路要求を受信し、RPオブジェクト内P2MPフラグを理解するが、PCEは、P2MP計算することができない場合はO、PCEは、PCEP-ERRORオブジェクトと対応するエラー値を持つ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).
PCEは、RPオブジェクト内P2MPフラグを理解していない場合はO、次いでPCEは、エラー値= 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.
[RFC5440]で定義されており、P2P TEパスの再最適化の要求に類似しているとしてP2MP TEパスの再最適化要求は、RPオブジェクト内のRビットを使用することによって特定されます。唯一の違いは、この文書の「要求メッセージのフォーマット」のセクション（セクション3.4）に記載したように、ユーザは、PCReqメッセージ内のエンドポイントの各タイプ後RROsとSRROsのリストを挿入しなければならないことです。
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)
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.
この例では、葉を追加したり、剪定せずに全ての葉へのパスの再最適化を要求します。再最適化要求は、最適化前のP2MP LSPを表すことになるEND-POINT型3 RROリストを使用して、変更パス葉はエンドポイント・オブジェクトで示されるであろう。
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)
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.
PCEは対応していない古い葉を削除するには、ユーザーには、タイプ2エンドポイントが存在しない場合は、PCEがエラータイプ17、値= 1を送らなければなりません、葉タイプ2とエンドポイントを使用してP2MP要求を構築する必要がありますリーフタイプ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、またはその両方を持つエンドポイントを含め、いかなる場合、古い葉のリストを提供しなければなりません。新しいPCEP-ERRORオブジェクトとタイプは、特定の条件が満たされていない場合、レポートのために必要である（すなわち、リーフタイプ3又は4、又は葉型1とエンドポイントの存在下で、またはとはエンドポイントが存在しない場合2）。 PCCは、一貫性のないエンドポイントを（1型として指定された葉がすでに存在している、すなわち、場合）は、要求を受信した場合、一般的な「矛盾END-POINT」エラーが使用されます。これらの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)
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)
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)
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)
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)
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)
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)
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)
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)
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オブジェクトは、それが唯一のIPv4およびIPv6プレフィックスサブオブジェクトをサポートしていることを除いて、[RFC5440]で定義された含めるルートオブジェクト（IRO）と同じフォーマットを有します。 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を計算が同期する必要がある場合があります。例えば、一つの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
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は、複数のメッセージを介して要求を分割します。最後の1を除いて、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 1200葉で既存のツリーに1つのリーフを追加するために、PCEにREQ-ID1と要求メッセージを送信示します。この例で使用仮定は、1件の要求メッセージが800葉まで保持できるということです。このシナリオでは、元の単一のメッセージは、断片化とREQ-ID1がRPオブジェクトに指定され、第1のメッセージに設定されたFビットで、そして第2のメッセージにクリアされた2つの小さなメッセージを使用して送信される必要があります。
Common Header
RP1 with Req-ID1 and P2MP=1 and F-bit=1
OF (optional)
END-POINTS1 for P2MP
RRO1 list
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とP2MP RRO1リスト（オプション）END-ポイントのFビット= 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.
このような場合に、UNREACH先オブジェクトは、PCEが到達不能な目的地のリストを指定任意することを可能にします。
This object can be present in PCRep messages. There can be up to one such object per RP.
このオブジェクトはPCRepメッセージ中に存在することができます。 RPごとにそのようなオブジェクトまでが存在する場合があります。
The following UNREACH-DESTINATION objects will be required:
次UNREACH先のオブジェクトが必要となります。
UNREACH-DESTINATION Object-Class is 28. UNREACH-DESTINATION Object-Type for IPv4 is 1. UNREACH-DESTINATION Object-Type for IPv6 is 2.
UNREACH先オブジェクト・クラスは、IPv4用の28 UNREACH先オブジェクトタイプであるIPv6の1 UNREACH先オブジェクトタイプが2です。
The format of the UNREACH-DESTINATION object body for IPv4 (Object-Type=1) is as follows:
次のようにIPv4のUNREACH先オブジェクト本体（オブジェクトタイプ= 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
IPv4の図9. UNREACH-DESTINATIONオブジェクトボディー
The format of the UNREACH-DESTINATION object body for IPv6 (Object-Type=2) is as follows:
次のようにIPv6のUNREACH先オブジェクト本体（オブジェクトタイプ= 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
IPv6の図10. UNREACH-DESTINATIONオブジェクトボディー
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]:
[RFC5440]で定義されるようにポリシー違反に関連するエラーを示すために、新しいエラー値「許可されていないP2MP経路計算は、」ポリシー違反（エラータイプ= 5）のための既存のエラーコードに追加する必要があります。
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.
エラー・タイプ= 5;エラー値= 7：PCEは、管理者権限（すなわち、「PCEポリシーはP2MPの経路計算をサポートしていません」）に準拠していない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:
PCEP-ERRORオブジェクトに含めるために、次のようにP2MP経路要求に関連する能力エラーを示すために、新しいエラータイプ（16）とそれに続くエラー値が定義されています。
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オブジェクトとPCErrメッセージを送らなければなりません（エラータイプ= 16）と誤り数値（エラー値= 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;エラー値= 2：PCEは、P2MP経路要求を受信し、PCEは、P2MP計算することが可能でない場合、PCEは、PCEP-ERRORオブジェクトとPCErrメッセージを送らなければなりません（エラータイプ= 16）とエラー値（エラー値= 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:
PCEP-ERRORオブジェクトに含めるために、次のようにP2MP経路要求に関連P2MPメッセージの断片化エラーを示すために、新しいエラータイプ（17）とそれに続くエラー値が定義されています。
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;エラー値= 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経路計算を見つけることができない理由を伝えるために、NO-PATHオブジェクトはPCRepメッセージに使用することができます。
One new bit is defined in the NO-PATH-VECTOR TLV carried in the NO-PATH Object:
一つの新しいビットは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節で定義された新しいUNREACH先オブジェクトを使用して到達できない宛先の宛先またはリストを指定することができます。
[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.
PCEにP2MP経路計算を有効または無効にする機能、O。
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ディスカバリ機構を介して、またはOpenメッセージ交換の際にそのP2MP機能を宣伝することができます3.1.2項（「オープン・メッセージの拡張」で説明）。
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.
MIBオブジェクトの数は、[PCEP-MIB]におけるP2P計算の一般的なPCEP制御および監視のために定義されています。 [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.
OSPFを介しP2MP経路計算可能なPCEについての情報を取得するPCEのための方法とは-ISは、この文書のセクション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状態を必要とするかもしれません。主要なネットワーク障害や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 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要求処理は、ネットワークへの破壊的であってもよいです。したがって、実装は、具体的最小化や不正P2MP経路計算要求とサービス拒否攻撃を否定するのに役立つ[RFC5440]の関連するセキュリティ要件に準拠していることが重要です。これらのメカニズムは、次のとおりです。
o Securing the PCEP session requests and responses using TCP security techniques (Section 10.2 of [RFC5440]).
TCPのセキュリティ技術（[RFC5440]のセクション10.2）を使用して、PCEPセッションのリクエストとレスポンスの確保、O。
o Authenticating the PCEP requests and responses to ensure the message is intact and sent from an authorized node (Section 10.3 of [RFC5440]).
メッセージを確実にするために、PCEP要求と応答を認証oを無傷で認可ノード（[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]).
明示的にこれのPCCを定義することによって、ポリシー制御を提供O、IPアクセス・リストを介して、PCE（[RFC5440]のセクション10.6）にP2MP経路要求を送信することが許可されています。
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はのPCEとの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
値説明リファレンス6 P2MPできる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
断片化（Fビット）RFC 6006 19 P2MP（Nビット）RFC 6006 20 ERO圧縮（Eビット）RFC 6006 18
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
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「METRICオブジェクトTフィールド」サブレジストリから次の割り当てを行っています。
Value Description Reference
値説明リファレンス
8 P2MP IGP metric RFC 6006 9 P2MP TE metric RFC 6006 10 P2MP hop count metric RFC 6006
8 P2MP IGPメトリックRFC 6006 9 P2MP TEメトリックRFC 6006 10 P2MPホップカウントメトリック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項で述べたように、二つの新しいエンドポイントのオブジェクト・タイプが定義されています。 IANAは「PCEPオブジェクト」サブレジストリから以下のオブジェクトタイプの割り当てを行っています。
Object-Class Value 4 Name END-POINTS Object-Type 3: IPv4 4: IPv6 5-15: Unassigned Reference RFC 6006
オブジェクトクラス値4名エンドポイントのオブジェクト・タイプ3：IPv4の4：IPv6の5-15：未割り当て参考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
オブジェクトクラス値28名前UNREACH先のオブジェクトタイプ1：IPv4の2：IPv6の3-15：未割り当て参考RFC 6006
Object-Class Value 29 Name SERO Object-Type 1: SERO 2-15: Unassigned Reference RFC 6006
オブジェクトクラス値29名SEROオブジェクト・タイプ1：SERO 2-15：未割り当て参考RFC 6006
Object-Class Value 30 Name SRRO Object-Type 1: SRRO 2-15: Unassigned Reference RFC 6006
オブジェクトクラス値30名前SRROオブジェクト・タイプ1：SRRO 2-15：未割り当て参考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
オブジェクトクラス値31名前支店ノードの能力オブジェクトのオブジェクトタイプ1：ブランチノードリスト2：非分岐ノードリスト3-15：未割り当て参考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：メモリ不足エラー値= 2にRFC PCEが要求を満たすことができない6006：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 6006 PCEが原因リーフタイプないエンドポイントへの要求を満たすことができない3エラー値= 3：PCEは要求を満たすことができない原因葉型4エラー値を持つないエンドポイントにRFC 6006 = 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フラグ・フィールド」のサブレジストリから以下の割り当てを行っています。
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節で説明したように、二つの新しいSVECオブジェクトフラグが定義されています。 IANAは、PCEP「SVECオブジェクトフラグ・フィールド」のサブレジストリから以下の割り当てを行っています。
Bit Description Reference
ビット説明リファレンス
19 Partial Path Diverse RFC 6006 20 Link Direction Diverse RFC 6006
19部分パス多様RFC 6006 20リンク方向多様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で説明したように、新しいOSPF能力フラグは、P2MP経路計算能力を示すために定義されています。 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.
著者は、エードリアンファレル、ヤング・リー、ダンタッパン、秋劉、Huaimoチェン、英二Okim、ニックNeate、スレシュバブーK、Dhruv Dhody、Udayasree Palle、のGaurav Agrawalさん、Vishwas Manral、ダンRomascanu、ティムポーク、スチュワートに感謝したいと思いますこのドキュメントの彼らの貴重なコメントや入力のためのブライアント、デヴィッドハリントン、そしてショーン・ターナー。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのための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]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（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]バーガー、L.、Bryskin、I.、Papadimitriou、D.、およびA.ファレル、 "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]アガルワルは、R.、エド、Papadimitriou、D.、エド、およびS.安川、エド、「リソース予約プロトコルへの拡張 - 。。。は、ポイント・ツー・マルチポイントTEラベルのためのトラフィックエンジニアリング（RSVP-TE）は、スイッチパス（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.編、シェン、N.、Vasseur、JP。、アガルワル、R.、およびS.シェイファー、 "広告オプションのルータの機能のための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.、エド。、およびJ.ル・ルー、エド。、 "トラフィックエンジニアリングノード能力の発見のための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]ル・ルー、JL。、エド。、Vasseur、JP。、エド。、池尻、Y.、およびR.張、 "OSPFプロトコル拡張パスの計算要素（PCE）ディスカバリー"、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]ル・ルー、JL。、エド。、Vasseur、JP。、エド。、池尻、Y.、およびR.張は、 "IS-ISプロトコル拡張経路計算エレメント（PCE）の発見について"、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]ファレル、A.、「ルーティングバッカス記法（RBNF）：さまざまなルーティングプロトコル仕様に符号化規則を形成するのに使用される構文」を2009年4月、RFC 5511を。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、JP。、編、およびJL。ル・ルー、エド。、 "パス計算要素（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]ル・ルー、JL。、Vasseur、JP。、およびY.リー、 "パス計算要素通信プロトコル（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]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（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]アッシュ、J.、エド。、およびJ.ル・ルー、エド。、 "パス計算要素（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]安川、S.およびA.ファレル、エド。、RFC 5671、2009年10月、 "ポイント・ツー・マルチポイントにする（P2MP）MPLSおよびGMPLSトラフィックエンジニアリング（TE）のパス計算要素（PCE）の適用"。
[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]安川、S.およびA.ファレル、 "パス計算クライアント（PCC） - のパス計算要素（PCE）の要件ポイントツーマルチポイントMPLS-TE"、RFC 5862、2010年6月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]をタッチし、J.、マンキン、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]コウシク、K.、ステファン、E.、趙、Q.、及びD.キング、 "PCE通信プロトコル（PCEP）管理情報ベース"、進歩、2010年7月ワーク。
Contributors
協力者
Jean-Louis Le Roux France Telecom 2, Avenue Pierre-Marzin 22307 Lannion Cedex France EMail: jeanlouis.leroux@orange-ftgroup.com
ジャン=ルイ・ルーフランステレコム2、アベニューピエールMarzin 22307ラニオンCedexのフランス電子メール：jeanlouis.leroux@orange-ftgroup.com
Mohamad Chaitou France EMail: mohamad.chaitou@gmail.com
モハマドChaitouフランスEメール：mohamad.chaitou@gmail.com
Authors' Addresses
著者のアドレス
Quintin Zhao (editor) Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US EMail: qzhao@huawei.com
Quintinの趙（エディタ）華為技術125 Nagogテクノロジーパークアクトン、MA 01719米国電子メール：qzhao@huawei.com
Daniel King (editor) Old Dog Consulting UK EMail: daniel@olddog.co.uk
ダニエル・キング（エディタ）老犬のコンサルティング英国Eメール：daniel@olddog.co.uk
Fabien Verhaeghe Thales Communication France 160 Bd Valmy 92700 Colombes France EMail: fabien.verhaeghe@gmail.com
ファビアンVerhaegheタレス・コミュニケーションズフランス160大通りヴァルミ92700コロンブフランスEメール：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
とものり たけだ んっｔ こｒぽらちおん ３ー９ー１１、 みどりーちょ むさしのーし、 ときょ １８０ー８５８５ じゃぱん えまいｌ： たけだ。とものり＠ぁｂ。んっｔ。こ。ｊｐ
Zafar Ali Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada EMail: zali@cisco.com
Zafarアリシスコシステムズ株式会社2000年イノベーションドライブカナタ、オンタリオK2K 3E8カナダEメール：zali@cisco.com
Julien Meuric France Telecom 2, Avenue Pierre-Marzin 22307 Lannion Cedex France EMail: julien.meuric@orange-ftgroup.com
ジュリアンMeuricフランステレコム2、アベニューピエールMarzin 22307ラニオンCedexのフランス電子メール：julien.meuric@orange-ftgroup.com