Internet Engineering Task Force (IETF) I. Nishioka
Request for Comments: 6007 NEC Corp.
Category: Informational D. King
ISSN: 2070-1721 Old Dog Consulting
September 2010
Use of the Synchronization VECtor (SVEC) List for
Synchronized Dependent Path Computations
Abstract
抽象
A Path Computation Element (PCE) may be required to perform dependent path computations. Dependent path computations are requests that need to be synchronized in order to meet specific objectives. An example of a dependent request would be a PCE computing a set of services that are required to be diverse (disjointed) from each other. When a PCE computes sets of dependent path computation requests concurrently, use of the Synchronization VECtor (SVEC) list is required for association among the sets of dependent path computation requests. The SVEC object is optional and carried within the Path Computation Element Communication Protocol (PCEP) PCRequest (PCReq) message.
経路計算エレメント（PCE）が依存経路計算を実行するために必要とされ得ます。依存パスの計算は、特定の目標を達成するために同期させる必要が要求されています。依存要求の例は、互いに（ばらばら）多様であることが要求されるサービスのセットを計算するPCEであろう。 PCEが同時に依存経路計算要求のセットを計算するときに、同期ベクター（SVEC）リストの使用は、依存経路計算要求のセット間の関連付けのために必要とされます。 SVECオブジェクトはオプションとパス計算エレメント通信プロトコル（PCEP）PCRequest（PCReq）メッセージの中で運ばれています。
This document does not specify the PCEP SVEC object or procedure. This informational document clarifies the use of the SVEC list for synchronized path computations when computing dependent requests. The document also describes a number of usage scenarios for SVEC lists within single-domain and multi-domain environments.
この文書では、PCEP SVECオブジェクトまたはプロシージャを指定していません。依存の要求を計算するときに、この情報のドキュメントを同期パス計算のためのSVECリストの使用を明確にしています。文書はまた、単一ドメインとマルチドメイン環境内のSVECリストの使用シナリオの数を示します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc6007.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6007で取得することができます。
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. SVEC Object ................................................4
1.2. Application of SVEC Lists ..................................5
2. Terminology .....................................................6
3. SVEC Association Scenarios ......................................7
3.1. Synchronized Computation for Diverse Path Requests .........7
3.2. Synchronized Computation for Point-to-Multipoint
Path Requests ..............................................8
4. SVEC Association ................................................9
4.1. SVEC List ..................................................9
4.2. Associated SVECs ...........................................9
4.3. Non-Associated SVECs ......................................10
5. Processing of SVEC List ........................................10
5.1. Single-PCE, Single-Domain Environments ....................10
5.2. Multi-PCE, Single-Domain Environments .....................11
5.3. Multi-PCE, Multi-Domain Environments ......................11
6. End-to-End Diverse Path Computation ............................13
6.1. Disjoint VSPT .............................................13
6.2. Disjoint VSPT Encoding ....................................14
6.3. Path Computation Procedure ................................15
7. Manageability Considerations ...................................15
7.1. Control of Function and Policy ............................15
7.2. Information and Data Models (MIB Modules) .................15
7.3. Liveness Detection and Monitoring .........................15
7.4. Verifying Correct Operation ...............................15
7.5. Requirements on Other Protocols and Functional
Components ................................................16
7.6. Impact on Network Operation ...............................16
8. Security Considerations ........................................16
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................17
10. Acknowledgements ..............................................18
[RFC5440] describes the specifications for the Path Computation Element Communication Protocol (PCEP). PCEP specifies the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs based on the PCE architecture [RFC4655]. PCEP interactions include path computation requests and path computation replies.
[RFC5440]はパス計算要素通信プロトコル（PCEP）の仕様について説明しています。 PCEPは、経路計算クライアント（PCC）とパス計算要素（PCE）との間、又はPCEアーキテクチャ[RFC4655]に基づいて、2つのPCE間の通信を指定します。 PCEP相互作用は、経路計算要求と経路計算の返信が含まれています。
The PCE may be required to compute independent and dependent path requests. Path computation requests are said to be independent if they are not related to each other and therefore not required to be synchronized. Conversely, a set of dependent path computation requests is such that their computations cannot be performed independently of each other, and the requests must be synchronized. The Synchronization VECtor (SVEC) with a list of the path computation request identifiers carried within the request message allows the PCC or PCE to specify a list of multiple path computation requests that must be synchronized. Section 1.1 ("SVEC Object") describes the SVEC object. Section 1.2 ("Application of SVEC Lists") describes the application of SVEC lists in certain scenarios.
PCEは、独立および従属パス要求を計算するために必要な場合があります。経路計算要求は、それらが相互に関連していないため、同期化する必要がない場合は独立していると言われています。逆に、依存経路計算要求のセットは、それらの計算が互いに独立して行うことができず、要求は同期されなければならないようなものです。要求メッセージの中で運ば経路計算要求識別子のリストとの同期ベクトル（SVEC）は、PCC又はPCEを同期させる必要があり、複数の経路計算要求のリストを指定することを可能にします。 1.1項（ "SVECオブジェクト"）SVECオブジェクトを記述します。 1.2節（「SVECリストの適用」）は、特定のシナリオでSVECリストのアプリケーションを記述しています。
This informational document clarifies the handling of dependent and synchronized path computation requests, using the SVEC list, based on the PCE architecture [RFC4655] and PCEP [RFC5440]. The document also describes a number of usage scenarios for SVEC lists within single-domain and multi-domain environments. This document is not intended to specify the procedure when using SVEC lists for dependent and synchronized path computation requests.
この情報のドキュメントはPCEアーキテクチャ[RFC4655]とPCEP [RFC5440]に基づいて、SVECリストを使用して、依存と同期経路計算要求の取り扱いを明確にしています。文書はまた、単一ドメインとマルチドメイン環境内のSVECリストの使用シナリオの数を示します。この文書は、依存と同期経路計算要求をSVECリストを使用する場合の手順を指定するものではありません。
When a PCC or PCE sends path computation requests to a PCE, a PCEP Path Computation Request (PCReq) message may carry multiple requests, each of which has a unique path computation request identifier. The SVEC with a list of the path computation request identifiers carried within the request message allows the PCC or PCE to specify a list of multiple path computation requests that must be synchronized, and also allows the specification of any dependency relationships between the paths. The path computation requests listed in the SVEC must be handled in a specific relation to each other (i.e., synchronized).
PCC又はPCEは、PCEへの経路計算リクエストを送信すると、PCEP経路計算要求（PCReq）メッセージは、固有の経路計算要求識別子をそれぞれ有する複数の要求を、搬送することができます。要求メッセージの中で運ば経路計算要求識別子のリストとSVECは、PCC又はPCEを同期させる必要があり、複数の経路計算要求のリストを指定することができ、また、パス間の任意の依存関係の指定を可能にします。 SVECに記載されている経路計算リクエスト（すなわち、同期）は、互いに特定の関係で処理されなければなりません。
[RFC5440] defines two synchronous path computation modes for dependent or independent path computation requests specified by the dependency flags (i.e., Node, Link, or Shared Risk Link Group (SRLG) diverse flags) in the SVEC:
[RFC5440]はSVECに依存フラグで指定された依存性または非依存性経路計算要求のための2つの同期経路計算モード（すなわち、ノード、リンク、または共有リスクリンクグループ（SRLG）多様なフラグ）を定義します。
o A set of independent and synchronized path computation requests.
独立した同期経路計算要求のセットO。
o A set of dependent and synchronized path computation requests.
依存と同期経路計算要求のセットO。
See [RFC5440] for more details on dependent, independent, and synchronous path computation.
、依存独立し、同期経路計算の詳細については、[RFC5440]を参照。
These computation modes are exclusive to each other in a single SVEC. If one of the dependency flags in a SVEC is set, it indicates that a set of synchronous path computation requests has a dependency and does not allow any other path computation requests. In order to be synchronized with other path computation requests with a dependency, it is necessary to associate them.
これらの演算モードは、単一のSVECで互いに排他的です。 SVECに依存フラグの1つが設定されている場合、それは、同期経路計算要求のセットは依存性があり、他の経路計算要求を許可しないことを示しています。依存関係を持つ他の経路計算要求と同期させるためには、それらを関連付けることが必要です。
The aim of the SVEC object carried within a PCReq message is to request the synchronization of M path computation requests. Each path computation request is uniquely identified by the Request-ID-number carried within the respective Request Parameters (RP) object. The SVEC object also contains a set of flags that specify the synchronization type. The SVEC object is defined in Section 7.13 ("SVEC Object") of [RFC5440].
PCReqメッセージ内で運ばSVECオブジェクトの目的は、M経路計算要求の同期を要求することです。各経路計算要求を一意各要求パラメータ（RP）オブジェクト内に担持要求-ID番号によって識別されます。 SVECオブジェクトは、同期タイプを指定するフラグのセットを含みます。 SVECオブジェクトは[RFC5440]のセクション7.13（ "SVECオブジェクト"）で定義されています。
It is important for the PCE, when performing path computations, to synchronize any path computation requests with a dependency. For example, consider two protected end-to-end services:
パス計算を実行するときには、依存関係を持つ任意の経路計算要求を同期させるために、PCEのために重要です。例えば、2保護されたエンドツーエンドのサービスを考えてみます。
o It would be beneficial for each back-up path to be disjointed so they do not share the same links and nodes as the working path.
Oそれは彼らが働いてパスと同じリンクとノードを共有しないようにするために分解でき、各バックアップパスのために有益であろう。
o Two diverse path computation requests would be needed to compute the working and disjointed protected paths.
O二つの多様な経路計算要求は、作業ととりとめのない保護されたパスを計算するために必要とされるであろう。
If the diverse path requests are computed sequentially, fulfillment of the initial diverse path computation without consideration of the second diverse path computation and disjoint constraint may result in the PCE either providing sub-optimal path disjoint results for the protected path or failing to meet the end-to-end disjoint requirement altogether.
多様な経路要求が順次算出される場合、第二の多様な経路計算と互いに素な制約を考慮しない初期の多様な経路計算の履行は、PCEをもたらすことができるいずれかの保護されたパスの準最適な経路ばらばら結果を提供または終了を満たしません-to-エンド全くばらばらな要件。
Additionally, SVEC can be applied to end-to-end diverse path computations that traverse multiple domains. [RFC5441] describes two approaches, synchronous (i.e., simultaneous) and 2-step approaches, for end-to-end diverse path computation across a chain of domains. The path computation procedure is specified for the 2-step approaches in [RFC5521], but no guidelines are provided for the synchronous approach described in this document.
また、SVECは、エンドツーエンドのために複数のドメインを横断する多様な経路計算を適用することができます。 [RFC5441]はドメインのチェーン全体のエンドツーエンドの多様な経路計算のための二つのアプローチ、同期（すなわち、同時）及び2段階のアプローチを記載しています。経路計算手順は[RFC5521]での2段階アプローチのために指定されているが、何のガイドラインは、この文書に記載された同期アプローチのために提供されていません。
The following scenarios are specifically described within this document:
次のシナリオは、特に、この文書内に記述されています。
o Single-domain, single-PCE, dependent and synchronized path computation request.
Oシングルドメイン、シングルPCE、依存と同期した経路計算要求。
o Single-domain, multi-PCE, dependent and synchronized path request.
Oシングルドメイン、マルチPCE、依存と同期パス要求。
o Multi-domain, dependent and synchronized path computation request, including end-to-end diverse path computation.
エンドツーエンドの多様な経路計算を含むOマルチドメイン、依存及び同期経路計算要求、。
The association among multiple SVECs for multiple sets of synchronized dependent path computations is also described in this document, as well as the disjoint Virtual Shortest Path Tree (VSPT) encoding rule for end-to-end diverse path computation across domains. Path computation algorithms for these path computation scenarios are out of the scope of this document.
同期依存経路計算の複数のセットのための複数のSVECs間の関連はまた、この文書、ならびにドメイン間のエンドツーエンドの多様な経路計算のためにばらばら仮想最短経路ツリー（VSPT）符号化規則に記載されています。これらの経路計算のシナリオのための経路計算アルゴリズムは、この文書の範囲外です。
The clarifications and use cases in this document are applicable to the Global Concurrent Optimization (GCO) path computation mechanism specified in [RFC5557]. The GCO application provides the capability to optimize a set of services within the network, in order to maximize efficient use of network resources. A single objective function (OF) or a set of OFs can be applied to a GCO. To compute a set of such traffic-engineered paths for the GCO application, PCEP supports the synchronous and dependent path computation requests required in [RFC4657].
この文書で明確化とユースケースは、[RFC5557]で指定されたグローバル同時最適化（GCO）経路計算機構にも適用可能です。 GCOアプリケーションは、ネットワークリソースの効率的な利用を最大化するために、ネットワーク内の一連のサービスを最適化する機能を提供します。単一の目的関数（OF）又はのOFのセットは、GCOに適用することができます。 GCOアプリケーションのようなトラフィック・エンジニアリングされたパスのセットを計算するために、PCEPは、[RFC4657]に必要な同期および依存経路計算要求をサポートします。
The SVEC association and the disjoint VSPT described in this document do not require any extension to PCEP messages and object formats, when computing a GCO for multiple or end-to-end diverse paths. In addition, the use of multiple SVECs is not restricted to only SRLG, node, and link diversity currently defined in the SVEC object [RFC5440], but is also available for other dependent path computation requests.
複数またはエンド・ツー・エンドの多様なパスのGCOを計算するときSVEC会合し、この文書に記載さればらばらVSPTは、PCEPメッセージオブジェクトフォーマットへの拡張を必要としません。加えて、複数SVECsの使用は、現在SVECオブジェクト[RFC5440]で定義された唯一のSRLG、ノード、及びリンクの多様性に制限するだけでなく、他の従属経路計算要求のために利用可能であるれていません。
The SVEC association and disjoint VSPT are available to both single-PCE path computation and multi-PCE path computation.
SVECアソシエーションと互いに素VSPTシングルPCEの経路計算とマルチPCEの経路計算の両方に利用可能です。
This document uses PCE terminology defined in [RFC4655], [RFC4875], and [RFC5440].
この文書では、PCEの[RFC4655]で定義された用語、[RFC4875]及び[RFC5440]を使用します。
Associated SVECs: A group of multiple SVECs (Synchronization VECtors), defined in this document, to indicate a set of synchronized or concurrent path computations.
関連SVECs：同期または同時パス計算のセットを示すために、この文書で定義された複数のSVECs（同期ベクトル）の基、、。
Disjoint VSPT: A set of VSPTs, defined in this document, to indicate a set of virtual diverse path trees.
互いに素VSPT：仮想多様なパス木の集合を示すために、この文書で定義されたVSPTsのセット、、。
GCO (Global Concurrent Optimization): A concurrent path computation application, defined in [RFC5557], where a set of traffic engineered (TE) paths is computed concurrently in order to efficiently utilize network resources.
GCO（グローバル同時最適化）：トラフィック工学（TE）パスのセットを効率的にネットワーク資源を利用するために並行して計算される[RFC5557]で定義された並行経路計算アプリケーション、。
Synchronized: Describes a set of path computation requests that the PCE associates and that the PCE does not compute independently of each other.
同期：PCE関連付け経路計算要求のセットを記述し、PCEは、互いに独立して計算しません。
VSPT: Virtual Shortest Path Tree, defined in [RFC5441].
VSPT：[RFC5441]で定義された仮想最短パスツリー、。
This section clarifies several path computation scenarios in which SVEC association can be applied. Also, any combination of scenarios described in this section could be applicable.
このセクションでは、SVECアソシエーションを適用することができるいくつかの経路計算シナリオを明確にしています。また、このセクションで説明したシナリオの任意の組み合わせが適用できます。
A PCE may compute two or more point-to-point diverse paths concurrently, in order to increase the probability of meeting primary and secondary path diversity (or disjointness) objectives and network resource optimization objectives.
PCEは、プライマリおよびセカンダリパスダイバーシチ（又は互いに素）目的とネットワーク資源最適化の目標を達成する確率を高めるために、同時に二つ以上のポイントツーポイントの多様な経路を計算することができます。
Two scenarios can be considered for the SVEC association of point-to-point diverse paths.
2つのシナリオは、ポイントツーポイントの多様な経路のSVEC会合のために考慮することができます。
o Two or more end-to-end diverse paths
Oつ以上のエンド・ツー・エンドの多様な経路
When concurrent path computation of two or more end-to-end diverse paths is requested, SVEC association is needed among diverse path requests. Note here that each diverse path request consists of primary, secondary, and tertiary (and beyond) path requests, in which all path requests are grouped with one SVEC association.
二つ以上のエンド・ツー・エンドの多様な経路の同時経路計算が要求されると、SVEC会合は、多様な経路要求のうち必要とされます。各多様な経路要求は、すべてのパスの要求は、1つのSVECアソシエーションとグループ化された、第一、第二、及び第三（以降）経路要求、からなることをここで注意してください。
Consider two end-to-end services that are to be kept separate by using diverse paths. The path computation requests would need to be associated so that diversity could be assured. Consider further that each of these services requires a backup path that can protect against any failure in the primary path. These backup paths must be computed using requests that are associated with the primary paths, giving rise to a set of four associated requests.
多様な経路を使用して別々に維持される2つのエンドツーエンドのサービスを考えます。多様性を確保することができるように、経路計算要求が関連している必要があります。これらの各サービスは、プライマリパスのいずれかの障害から保護することができ、バックアップパスを必要とすることがさらに考えてみましょう。これらの予備パスは、4つの関連する要求のセットを生じさせる、プライマリパスに関連付けられた要求を使用して計算されなければなりません。
o End-to-end primary path and its segmented secondary paths
Oエンドツーエンドのプライマリパスとセカンダリパスのセグメント化
When concurrent path computation for segment recovery paths, as shown in Figure 1, is requested, SVEC association is needed between a primary path and several segmented secondary paths.
セグメント回復パスの場合並行経路計算、図1に示すように、SVECアソシエーションがプライマリパスといくつかのセグメント化された二次経路との間に必要とされる、要求されています。
<------------ primary ----------->
A------B------C---D------E------F
\ / \ /
￥ ／ ￥ ／
P---Q---R X---Y---Z
<--secondary1--> <--secondary2-->
< - 二次 - > < - セカンダリー2 - >
Figure 1. Segment Recovery Paths
図1.セグメント復旧パス
In this scenario, we assume that the primary path may be pre-computed and used for specifying the segment for secondary paths. Otherwise, the segment for secondary path requests is specified in advance, by using Exclude Route Object (XRO) and/or Include Route Object (IRO) constraints in the primary request.
このシナリオでは、プライマリパスを事前に計算し、二次パスのセグメントを指定するために使用することができると仮定する。そうでなければ、二次経路要求用セグメントは、ルートオブジェクト（XRO）を除外し、および/または一次要求にルートオブジェクト（IRO）制約を含め使用して、事前に指定されています。
For point-to-multipoint path requests, SVEC association can be applied.
ポイント・ツー・マルチポイントパス要求に対して、SVECアソシエーションを適用することができます。
o Two or more point-to-multipoint paths
Oつ以上のポイント・ツー・マルチポイントパス
If a point-to-multipoint path computation request is represented as a set of point-to-point paths [RFC6006], two or more point-to-multipoint path computation requests can be associated for concurrent path computation, in order to optimize network resources.
ポイント・ツー・マルチポイントパス計算要求は、ポイントツーポイントパス[RFC6006]の集合として表される場合、二つ以上のポイント・ツー・マルチポイントパス計算要求は、ネットワークを最適化するために、並行経路計算のために関連することができます資源。
o Point-to-multipoint paths and their secondary paths
Oポイントツーマルチパスとその二次パス
When concurrent path computation of a point-to-multipoint path and its point-to-point secondary paths [RFC4875], or a point-to-multipoint path and its point-to-multipoint secondary paths is requested, SVEC association is needed among these requests. In this scenario, we use the same assumption as the "end-to-end primary path and its segmented secondary paths" scenario in Section 3.1.
ポイント・ツー・マルチポイントパスとポイントツーポイント二次経路[RFC4875]、またはポイント・ツー・マルチポイントパスとポイントツーマルチポイントの二次経路の同時経路計算が要求されると、SVECアソシエーションを間必要とされていますこれらの要求。このシナリオでは、我々は、セクション3.1の「エンド・ツー・エンドのプライマリパスとセカンダリパスセグメント化」シナリオと同じ仮定を使用します。
This section describes the associations among SVECs in a SVEC list.
このセクションでは、SVECリストでSVECs間の関連性を説明しています。
PCEP provides the capability to carry one or more SVEC objects in a PCReq message, and this set of SVEC objects within the PCReq message is termed a SVEC list. Each SVEC object in the SVEC list contains a distinct group of path computation requests. When requesting association among such distinct groups, associated SVECs described in this document are used.
PCEPはPCReqメッセージ内の1つまたは複数のSVECオブジェクトを実行する機能を提供し、PCReqメッセージ内SVECオブジェクトのこのセットはSVECリストと呼ばれます。 SVECリスト内の各SVECオブジェクトは、経路計算リクエストの異なる基を含みます。そのような異なるグループ間の関連付けを要求するとき、この文書で説明する関連SVECsが使用されます。
"Associated SVECs" means that there are relationships among multiple SVECs in a SVEC list. Note that there is no automatic association in [RFC5440] between the members of one SVEC and the members of another SVEC in the same SVEC list. The associated SVEC is introduced to associate these SVECs, especially for correlating among SVECs with dependency flags.
「関連SVECsは」SVECリスト内の複数のSVECs間の関係があることを意味します。同じSVECリスト内の1つSVECのメンバーと別のSVECのメンバーとの間の[RFC5440]には自動的な関連がないことに留意されたいです。関連SVECは特に依存フラグとSVECs間相関のために、これらSVECsを関連付けるために導入されます。
Request identifiers in the SVEC objects are used to indicate the association among SVEC objects. If the same request-IDs exist in SVEC objects, this indicates these SVEC objects are associated. When associating among SVEC objects, at least one request identifier must be shared between associated SVECs. The SVEC objects can be associated regardless of the dependency flags in each SVEC object, but it is recommended to use a single SVEC if the dependency flags are not set in all SVEC objects. Similarly, when associating among SVEC objects with dependency flags, it is recommended to construct them using a minimum set of associated SVECs, thus avoiding complex relational associations.
SVECオブジェクト内の要求識別子は、SVECのオブジェクト間の関連を示すために使用されています。同じ要求IDがSVECオブジェクト内に存在する場合、これは、これらのSVECオブジェクトが関連付けられている示しています。 SVECオブジェクト間関連付けるとき、少なくとも一つの要求識別子は、関連付けられたSVECs間で共有されなければなりません。 SVECオブジェクトに関係なく、各SVECオブジェクトに依存フラグを関連付けることができ、依存フラグが全てSVECオブジェクトに設定されていない場合、単一のSVECを使用することが推奨されます。同様に、SVEC間関連付けるときには依存フラグを持つオブジェクト、このように複雑な関係の関連付けを回避する、関連SVECsの最小セットを使用して構築することが推奨されます。
Below is an example of associated SVECs. In this example, the first SVEC is associated with the other SVECs, and all of the path computation requests contained in the associated SVECs (i.e., Request-IDs #1, #2, #3, #4, #X, #Y, and #Z) must be synchronized.
以下関連SVECsの一例です。この例では、第一SVECは、他SVECsに関連付けられ、経路計算要求の全ては、関連SVECs（すなわち、依頼IDが＃1、＃2、＃3、＃4、#X、#Yに含まそして＃Z）が同期している必要があります。
<SVEC-list>
<SVECリスト>
<SVEC> without dependency flags
<SVEC>依存フラグなし
Request-ID #1, Request-ID #3, Request-ID #X
リクエスト-ID＃1、リクエスト-ID＃3、リクエスト-ID #X
<SVEC> with one or more dependency flags
<SVEC>一の以上の依存フラグ付き
Request-ID #1, Request-ID #2
リクエスト-ID＃1、要求-ID＃2
<SVEC> with one or more dependency flags
<SVEC>一の以上の依存フラグ付き
Request-ID #3, Request-ID #4
要求ID＃3、要求ID＃4
<SVEC> without dependency flag
<SVEC>依存フラグなし
Request-ID #X, Request-ID #Y, Request-ID #Z
リクエスト-ID #X、リクエスト-ID＃Y、リクエスト-ID #Z
"Non-associated SVECs" means that there are no relationships among SVECs. If none of the SVEC objects in the SVEC list on a PCReq message contains a common request-ID, there is no association between the SVECs and so no association between the requests in one SVEC and the requests in another SVEC.
「非関連したSVECsは」SVECs間には関係がないことを意味します。 PCReqメッセージにSVECリストのSVECオブジェクトのいずれも共通の要求IDを含まない場合、SVECs一SVECに要求し、別のSVECにおける要求との間のように無関連との間には関連がありません。
Below is an example of non-associated SVECs that do not contain any common request-IDs.
下記のいずれかの共通要求IDを含まない非会合SVECsの例があります。
<SVEC-list>
<SVECリスト>
<SVEC> with one or more dependency flags
<SVEC>一の以上の依存フラグ付き
Request-ID #1, Request-ID #2
リクエスト-ID＃1、要求-ID＃2
<SVEC> with one or more dependency flags
<SVEC>一の以上の依存フラグ付き
Request-ID #3, Request-ID #4
要求ID＃3、要求ID＃4
<SVEC> without dependency flags
<SVEC>依存フラグなし
Request-ID #X, Request-ID #Y, Request-ID #Z
リクエスト-ID #X、リクエスト-ID＃Y、リクエスト-ID #Z
In this environment, there is a single PCE within the domain.
この環境では、ドメイン内の単一のPCEがあります。
When a PCE receives PCReq messages with more than one SVEC object in the SVEC list, PCEP has to first check the request-IDs in all SVEC objects in order to identify any associations among them.
PCEはSVECのリストに複数のSVECオブジェクトとPCReqメッセージを受信すると、PCEPは、まず、それらの間の任意の関連を識別するために、すべてのSVECオブジェクトに要求IDをチェックする必要があります。
If there are no matching request-IDs in the different SVEC objects, these SVEC objects are not associated, and then each set of path computation requests in the non-associated SVEC objects has to be computed separately.
異なるSVECオブジェクトに該当する要求IDが存在しない場合、これらSVECオブジェクトが関連付けられていない、そして、非関連SVECオブジェクトに経路計算リクエストの各セットは、別々に計算されなければなりません。
If there are matching request-IDs in the different SVEC objects, these SVEC objects are associated, and then all path computation requests in the associated SVEC objects are treated in a synchronous manner for GCO application.
異なるSVECオブジェクトに要求IDを一致がある場合、これらSVECオブジェクトが関連付けられ、次いで関連SVECオブジェクト内のすべての経路計算要求は、GCOアプリケーションの同期方法で処理されます。
If a PCE that is unable to handle the associated SVEC finds the common request-IDs in multiple SVEC objects, the PCE should cancel the path computation request and respond to the PCC with the PCErr message Error-Type="Capability not supported".
関連するSVECを処理することができませんPCEが複数のSVECオブジェクトに共通要求IDを見つけた場合、PCEは、経路計算要求をキャンセルし、PCErrメッセージエラー・タイプ=「機能はサポートされていません」とPCCに応答しなければなりません。
In the case that M path computation requests are sent across multiple PCReq messages, the PCE may start a SyncTimer as recommended in Section 7.13.3 ("Handling of the SVEC Object") of [RFC5440]. In this case, the associated SVECs should also be handled as described in [RFC5440], i.e., after receiving the entire set of M path computation requests associated by SVECs, the computation should start at one. If the SyncTimer has expired or the subsequent PCReq messages are malformed, the PCE should cancel the path computation request and respond to the PCC with the relevant PCErr message.
セクション7.13.3 [RFC5440]の（「SVECオブジェクトの処理」）に推奨されるようにMパス計算要求が複数PCReqメッセージを介して送信される場合には、PCEはSyncTimerを開始してもよいです。 [RFC5440]に記載されているように、この場合、関連するSVECsも処理する必要があり、即ち、SVECsによって関連するM個の経路計算要求のセット全体を受信した後、計算は、一つに開始すべきです。 SyncTimerの有効期限が切れているか、その後のPCReqメッセージが不正な形式であれば、PCEは、経路計算要求をキャンセルして、関連するPCErrメッセージでPCCに応答しなければなりません。
There are multiple PCEs in a domain, to which PCCs can communicate directly, and PCCs can choose an appropriate PCE for load-balanced path computation requests. In this environment, it is possible that dependent path computation requests are sent to different PCEs.
そこのPCCは、直接通信することができるため、ドメイン内の複数のPCEは、であり、のPCCは、負荷バランスが経路計算要求のための適切なPCEを選択することができます。この環境では、依存経路計算要求が異なるのPCEに送信されている可能性があります。
However, if a PCC sends path computation requests to a PCE, and then sends a further path computation request to a different PCE using the SVEC list to show that the further request is dependent on the first requests, there is no method for the PCE to correlate the dependent requests sent to different PCEs. No SVEC object correlation function between the PCEs is specified in [RFC5440]. No mechanism exists to resolve this problem, and the issue is open for future study. Therefore, a PCC must not send dependent path computation requests associated by SVECs to different PCEs.
PCCは、PCEへの経路計算リクエストを送信し、さらに要求が最初の要求に依存していることを示すためにSVECリストを使用して、異なるPCEへのさらなる経路計算リクエストを送信する場合は、へPCEのための方法がありません異なるのPCEに送信された依存要求を関連付けます。 PCEの間にSVEC物体相関関数は、[RFC5440]で指定されていません。メカニズムは、この問題を解決するために存在しない、との問題は、今後の研究のために開いています。したがって、PCCは、別のPCEにSVECsによって関連付け依存経路計算要求を送信してはなりません。
In this environment, there are multiple domains in which PCEs are located in each domain, and end-to-end dependent paths (i.e., diverse paths) are computed using multiple PCEs. Note that we assume a chain of PCEs is predetermined and the Backward-Recursive PCE-Based Computation (BRPC) procedure [RFC5441] is in use.
この環境では、のPCEは、各ドメインに配置され、エンドツーエンド依存経路（すなわち、多様な経路）は複数のPCEを使用して計算された複数のドメインが存在します。我々はのPCEの鎖を所定及び後方再帰PCEベースの計算（BRPC）手順[RFC5441]使用中であると仮定されていることに留意されたいです。
The SVECs can be applied to end-to-end diverse path computations that traverse multiple domains. [RFC5441] describes two approaches, synchronous (i.e., simultaneous) and 2-step approaches, for end-to-end diverse path computation across a chain of domains. In the 2-step approaches described in [RFC5521], it is not necessary to use the associated SVECs if any of the dependency flags in a SVEC object are not set. On the other hand, the simultaneous approach may require the associated SVEC because at least one of the dependency flags is required to be set in a SVEC object. Thus, a use case of the simultaneous approach is described in this environment.
SVECsは、エンドツーエンドのために複数のドメインを横断する多様な経路計算を適用することができます。 [RFC5441]はドメインのチェーン全体のエンドツーエンドの多様な経路計算のための二つのアプローチ、同期（すなわち、同時）及び2段階のアプローチを記載しています。 [RFC5521]に記載されるアプローチ2工程では、SVECオブジェクトに依存フラグのいずれかが設定されていない場合、関連SVECsを使用する必要はありません。依存フラグの少なくとも一方がSVECオブジェクトに設定する必要があるので、一方、同時アプローチは、関連SVECを必要とするかもしれません。このように、同時アプローチの使用の場合は、この環境の中で記述されています。
When a chain of PCEs located in separate domains is used for simultaneous path computations, additional path computation processing is required, as described in Section 6 of this document.
別々のドメインに位置するのPCEの鎖が同時パス計算のために使用される場合、このドキュメントのセクション6で説明したように、追加の経路計算処理が必要となります。
If the PCReq message contains multiple associated SVEC objects and these SVEC objects contain path computation requests that will be sent to the next PCE along the path computation chain, the following procedures are applied.
PCReqメッセージは、複数の関連SVECオブジェクトが含まれており、これらSVECオブジェクトがパス計算鎖に沿って次のPCEに送信する経路計算リクエストが含まれている場合、以下の手順が適用されます。
When a chain of PCEs is a unique sequence for all of the path computation requests in a PCReq message, it is not necessary to reconstruct associations among SVEC objects. Thus, the PCReq message is passed to the tail-end PCE. When a PCReq message contains more than one SVEC object with the dependency flag set, the contained SVECs may then be associated. PCEs receiving the associated SVECs must maintain their association and must consider their relationship when performing path computations after receiving a corresponding PCReply (PCRep) message.
PCEの鎖はPCReqメッセージ内の経路計算要求の全ての一意のシーケンスである場合、SVECオブジェクト間の関連付けを再構築する必要はありません。このように、PCReqメッセージはテールエンドPCEに渡されます。 PCReqメッセージは依存フラグが設定された複数のSVECオブジェクトを含む場合、含まSVECsは次に関連していてもよいです。関連SVECsを受けるのPCEは、その関連付けを維持する必要があり、対応するPCReply（PCRep）メッセージを受信した後、パス計算を実行するときの関係を考慮しなければなりません。
When a chain of PCEs is different, it is required that intermediate PCEs receiving such PCReq messages may reconstruct associations among SVEC objects, and then send PCReq messages to corresponding PCEs located in neighboring domains. If the associated SVECs are reconstructed at the intermediate PCE, the PCE must not start its path computation until all PCRep messages have been received from all neighbor PCEs. However, a complex PCE implementation is required for SVEC reconstruction, and waiting mechanisms must be implemented. Therefore, it is not recommended to associate path computation requests with different PCE chains. This is an open issue and is currently being discussed in [H-PCE], which proposes a hierarchical PCE architecture.
PCEの鎖が異なる場合には、中間のPCEは、PCReqメッセージを受信することが要求されるSVECオブジェクト間の関連付けを再構成し、次に隣接する領域に位置する対応のPCEにPCReqメッセージを送信することができます。関連するSVECs中間PCEで再構成されている場合は、すべてのPCRepメッセージは、すべてのネイバーのPCEから受信されるまで、PCEは、その経路計算を開始してはいけません。しかし、複雑なPCEの実装はSVECの再構築のために必要である、と待っているのメカニズムを実装する必要があります。したがって、異なるPCE鎖を有する経路計算要求を関連付けることは推奨されません。これは、未解決の問題であり、現在階層PCEアーキテクチャを提案している[H-PCE]で議論されています。
In this section, the synchronous approach is provided to compute primary and secondary paths simultaneously.
このセクションでは、同期アプローチは、同時に一次および二次経路を計算するために設けられています。
The BRPC procedure constructs a VSPT to inform the enquiring PCE of potential paths to the destination node.
BRPC手順は、宛先ノードへの潜在的なパスの問い合わせPCEに通知するVSPTを構築します。
In the end-to-end diverse path computation, diversity (or disjointness) information among the potential paths must be preserved in the VSPT to ensure an end-to-end disjoint path. In order to preserve diversity (or disjointness) information, disjoint VSPTs are sent in the PCEP PCRep message. The PCReq containing a SVEC object with the appropriate diverse flag set would signal that the PCE should compute a disjoint VSPT.
エンドツーエンドの多様な経路計算において、潜在的なパスの間で多様性（又は互いに素）情報は、エンドツーエンドの独立経路を確保するために、VSPTに保存されなければなりません。多様性（又は互いに素）情報を保持するために、互いに素VSPTsは、PCEP PCRepメッセージで送信されます。適切な多様なフラグが設定されたSVECオブジェクトを含むPCReqは、PCEが互いに素VSPTを計算する必要があることを知らせることになります。
A definition of the disjoint VSPT is a collection of VSPTs, in which each VSPT contains a potential set of primary and secondary paths.
互いに素VSPTの定義は、各VSPTプライマリおよびセカンダリパスの電位組を含有する、VSPTsの集合です。
Figure 2 shows an example network. Here, transit nodes in domains are not depicted, and PCE1 and PCE2 may be located in border nodes. In this network, there are three VSPTs for the potential set of diverse paths, shown in Figure 3, when the primary path and secondary path are requested from S1 to D1. These VSPTs consist of a disjoint VSPT, which is indicated in a PCRep to PCE1. When receiving the disjoint VSPT, PCE1 recognizes the disjoint request and disjoint VSPT information. PCE1 will then continue to process the request and compute the diverse path using the BRPC procedure [RFC5441]. Encoding for the disjoint VSPT is described in Section 6.2.
図2は、例示的なネットワークを示しています。ここで、ドメイン内のトランジットノードは示されていない、とPCE1およびPCE2はボーダー・ノードに配置することができます。このネットワークでは、プライマリパスとセカンダリパスはD1にS1から要求された図3に示されている多様な経路の潜在的セットのための3つのVSPTsがあります。これらVSPTsはPCE1にPCRepに示されているばらばらVSPT、から成ります。互いに素VSPTを受信すると、PCE1は互いに素要求と互いに素VSPT情報を認識する。 PCE1は、要求を処理し、BRPC手順[RFC5441]を使用して、多様な経路を計算し続けます。互いに素VSPTのエンコードは、セクション6.2に記載されています。
Domain1 Domain2
ドメイン1ドメイン2
+----------+ +----------+
| PCE1 | | PCE2 | S1: Source node
| PCE1 | | PCE2 | S1：ソースノード
| BN1---BN4 | D1: Destination node
| S1 BN2---BN5 D1 | BN1-BN6: Border nodes
| BN3---BN6 |
+----------+ +----------+
Figure 2. Example Network for Diverse Path Computation
多様な経路計算図2.ネットワーク例
VSPT1: VSPT2: VSPT3:
VSPT1：VSPT2：VSPT3：
D1 D1 D1
D1 D1 D1
/ \ / \ / \
／ ￥ ／ ￥ ／ ￥
BN4 BN5 BN4 BN6 BN5 BN6
BN4 BN5 BN4 BN6 BN5 BN6
Figure 3. Disjoint VSPTs from PCE2 to PCE1
図3.ディスジョイントVSPTs PCE2からPCE1へ
Encoding for the disjoint VSPT follows the definition of PCEP message encoding in [RFC5440].
互いに素VSPTの符号化は[RFC5440]でPCEPメッセージエンコーディングの定義に従います。
The PCEP PCRep message returns a disjoint VSPT as <path list> for each RP object (Request Parameter object). The order of <path> in <path list> among <responses> implies a set of primary Explicit Route Objects (EROs) and secondary EROs.
PCEP PCRepメッセージは、各RPオブジェクト（要求パラメータオブジェクト）のための<パスリスト>として互いに素VSPTを返します。 <回答>うちの<path>に<パスリスト>の順序は、一次明示的経路オブジェクト（エロス）と二次エロスのセットを意味しています。
A PCE sending a PCRep with a disjoint VSPT can reply with a partial disjoint VSPT based on its network operation policy, but the order of <path> in <path list> must be aligned correctly.
そのネットワーク運用方針に基づく部分互いに素VSPTを使用して返信することができます互いに素VSPTでPCRepを送るPCEが、<パス>で<パスリスト>の順序が正しく整列されなければなりません。
If confidentiality is required between domains, the path key mechanism defined in [RFC5520] is used for a disjoint VSPT.
機密性はドメイン間で必要とされる場合は、[RFC5520]で定義されたパスキー機構は互いに素VSPTのために使用されます。
Below are the details of the disjoint VSPT encoding (in Figure 3), when a primary path and a secondary path are requested from S1 to D1.
以下プライマリパスとセカンダリパスはD1にS1から要求されている（図3の）ばらばらVSPT符号化の詳細があります。
o Request ID #1 (Primary)
OリクエストID＃1（プライマリ）
- ERO1 BN4(TE route ID)- ...-D1(TE-Router ID) [for VSPT1]
- ERO1 BN4（TEルートID） - ...- D1（TE-ルータID）[VSPT1用】
- ERO2 BN4(TE route ID)- ...-D1(TE-Router ID) [for VSPT2]
- ERO2 BN4（TEルートID） - ...- D1（TE-ルータID）[VSPT2用】
- ERO3 BN5(TE route ID)- ...-D1(TE-Router ID) [for VSPT3]
- ERO3 BN5（TEルートID） - ...- D1（TE-ルータID）[VSPT3用】
o Request ID #2 (Secondary)
OリクエストID＃2（セカンダリ）
- ERO4 BN5(TE route ID)- ...-D1(TE-Router ID) [for VSPT1]
- ERO4 BN5（TEルートID） - ...- D1（TE-ルータID）[VSPT1用】
- ERO5 BN6(TE route ID)- ...-D1(TE-Router ID) [for VSPT2]
- ERO5 BN6（TEルートID） - ...- D1（TE-ルータID）[VSPT2用】
- ERO6 BN6(TE route ID)- ...-D1(TE-Router ID) [for VSPT3]
- ERO6 BN6（TEルートID） - ...- D1（TE-ルータID）[VSPT3用】
For end-to-end diverse path computation, the same mode of operation as that of the BRPC procedure can be applied (i.e., Step 1 to Step n in Section 4.2 of [RFC5441]). A question that must be considered is how to recognize disjoint VSPTs.
エンドツーエンドの多様な経路計算のために、BRPC手順のと同じ動作モード（ステップN [RFC5441]のセクション4.2にする、すなわち、工程1）を適用することができます。考慮されなければならない質問は互いに素VSPTsを認識する方法です。
The recognition of disjoint VSPTs is achieved by the PCE sending a PCReq to its neighbor PCE, which maintains the path computation request (PCReq) information. If the PCReq has one or more SVEC object(s) with the appropriate dependency flags, the received PCRep will contain the disjoint VSPT. If not, the received VSPT is a normal VSPT based on the shortest path computation.
互いに素VSPTsの認識は、経路計算要求（PCReq）情報を保持するその隣接PCEにPCReqを送信PCEによって達成されます。 PCReqが適切依存フラグを有する1つ以上のSVECオブジェクト（複数可）を有する場合、受信PCRepは互いに素VSPTを含むであろう。そうでない場合、受信VSPT最短経路計算に基づいて、正常VSPTあります。
Note that the PCE will apply a suitable algorithm for computing requests with disjoint VSPTs. The selection and application of the appropriate algorithm is out of scope in this document.
PCEは互いに素VSPTsとの要求を計算するために適切なアルゴリズムを適用することに注意してください。適切なアルゴリズムの選択とアプリケーションは、この文書で範囲外です。
This section describes manageability considerations specified in [PCE-MNG-REQS].
このセクションでは、[PCE-MNG-REQS]で指定された管理性の考慮事項について説明します。
In addition to [RFC5440], PCEP implementations should allow the PCC to be responsible for mapping the requested paths to computation requests. The PCC should construct the SVECs to identify and associate SVEC relationships.
[RFC5440]に加えて、PCEP実装は、PCCは、計算要求に要求されたパスをマッピングする責任を負うことを可能にするべきです。 PCCはSVECの関係を識別し、関連付けるためにSVECsを構築する必要があります。
There are currently no additional parameters for MIB modules. There would be value in a MIB module that details the SVEC association. This work is currently out of scope of this document.
MIBモジュールのための追加のパラメータはありません。 SVECの関連を詳細MIBモジュールに値が存在することになります。この作品は、この文書の範囲の外に現在あります。
The associated SVEC in this document allows PCEs to compute optimal sets of diverse paths. This type of path computation may require more time to obtain its results. Therefore, it is recommended for PCEP to support the PCE monitoring mechanism specified in [RFC5886].
この文書の関連SVECはのPCEは、多様な経路の最適なセットを計算することを可能にします。経路計算のこのタイプは、その結果を得るために多くの時間を必要とするかもしれません。したがって、[RFC5886]で指定されたPCE監視機構をサポートするPCEPのために推奨されています。
[RFC5440] provides a sufficient description for this document. There are no additional considerations.
[RFC5440]は、この文書のために十分な説明を提供します。追加の考慮事項はありません。
This document does not require any other protocol and functional components.
このドキュメントは、他のプロトコルや機能部品を必要としません。
[RFC5440] provides descriptions for the mechanisms discussed in this document. There is value in considering that large associated SVECs will require greater PCE resources, compared to non-associated SVECs. Additionally, the sending of large associated SVECs within multiple PCReq messages will require more network resources. Solving these specific issues is out of scope of this document.
[RFC5440]は、本書で説明したメカニズムの説明を提供します。大きな関連するSVECsは非会合SVECsに比べて、より大きなPCEのリソースが必要になることを考慮に値があります。また、複数のPCReqメッセージ内に大きな関連するSVECsの送信はより多くのネットワークリソースが必要になります。これらの特定の問題を解決することが、この文書の範囲外です。
This document describes the usage of the SVEC list, and does not have any extensions for PCEP. The security of the procedures described in this document depends on PCEP [RFC5440]. However, a PCE that supports associated SVECs may be open to Denial-of-Service (DoS) attacks from a rogue PCC. A PCE may be made to queue large numbers of requests waiting for other requests that will never arrive. Additionally, a PCE might be made to compute exceedingly complex associated SVEC computations. These DoS attacks may be mitigated with the use of practical SVEC list limits, as well as:
この文書では、SVECリストの使用法を説明し、PCEPのための任意の拡張子を持っていません。このドキュメントで説明する手順のセキュリティは、PCEP [RFC5440]に依存します。しかし、関連するSVECsをサポートPCEは不正PCCからサービス拒否（DoS）攻撃に開放されていてもよいです。 PCEが到着することはありません他の要求を待っている多数の要求をキューに行うことができます。また、PCEは非常に複雑に関連するSVEC計算を計算するために作られている可能性があります。これらのDoS攻撃は、だけでなく、実用的なSVECリストの制限を使用して軽減することができます。
o Applying provisioning to PCEs, e.g., for a given number of simultaneous services (recommended).
同時サービスの所与の数に対して、例えば、のPCEにプロビジョニングを適用O（推奨）。
o Using a priority-based multi-queuing mechanism in which path computation requests with a smaller SVEC list are prioritized for path computation processing.
小さいSVECリストと経路計算要求は経路計算処理のために優先される優先順位ベースのマルチキューイングメカニズムを使用し、O。
o Specifying which PCCs may request large SVEC associations through PCE access policy control.
PCCは、PCEアクセスポリシー制御を通じて大SVECの関連付けを要求することができるの指定、O。
[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月。
[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月。
[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月。
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009.
[RFC5441] Vasseur、JP。、編、張、R.、ビタール、N.、およびJL。ル・ルー、RFC 5441、2009年4月「最短拘束ドメイン間トラフィックエンジニアリングラベルを計算するために下位再帰PCEベースの計算（BRPC）手順は、パスの交換しました」。
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009.
[RFC5520]ブラッドフォード、R.、エド。、Vasseur、JP。、およびA.ファレル、「パス・キー・ベースのメカニズムを使用したドメイン間の経路計算で保存トポロジ機密性」、RFC 5520、2009年4月。
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC 5521, April 2009.
[RFC5521]沖、E.、武田、T.、およびA.ファレル、 "ルートの除外のためにパス計算要素通信プロトコル（PCEP）への拡張"、RFC 5521、2009年4月。
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", RFC 5557, July 2009.
[RFC5557]リー、Y.、ル・ルー、JL。、キング、D.、およびE.沖、 "パス計算要素通信プロトコル（PCEP）の要件とプロトコルの拡張機能のグローバル同時最適化のサポートで"、RFC 5557、2009年7月。
[H-PCE] King, D., Ed., and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS & GMPLS", Work in Progress, December 2009.
[H-PCE]キング、D.、エド。、およびA.ファレル、エド。、「MPLS＆GMPLSにおけるドメインの配列の決定へのパス計算要素のアーキテクチャの応用」、進歩、2009年12月の作業。
[PCE-MNG-REQS] Farrel, A., "Inclusion of Manageability Sections in PCE Working Group Drafts", Work in Progress, July 2009.
[PCE-MNG-REQS]ファレル、A.、 "PCEワーキンググループドラフトでの管理性のセクションを含める"、進歩、2009年7月に作業。
[RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture", RFC 5886, June 2010.
[RFC5886] Vasseur、JP。、エド。、ル・ルー、JL。、およびY.池尻、RFC 5886、2010年6月 "経路計算エレメント（PCE）ベースのアーキテクチャのための監視ツールのセット"。
[RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., Ali, Z., and J. Meuric, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 6006, September 2010.
[RFC6006]趙、Q.、エド。、キング、D.、エド。、Verhaeghe、F.、武田、T.、アリ、Z.、およびJ. Meuric、「パス計算要素通信プロトコルへの拡張（PCEP ）ポイントツーマルチポイントトラフィックエンジニアリングラベルについては、RFC 6006、2010年9月、「パスを交換。
The authors would like to thank Adrian Farrel, Julien Meuric, and Filippo Cugini for their valuable comments.
作者は彼らの貴重なコメントをエードリアンファレル、ジュリアンMeuric、およびフィリッポCuginiに感謝したいと思います。
Authors' Addresses
著者のアドレス
Itaru Nishioka NEC Corp. 1753 Shimonumabe, Kawasaki, 211-8666, Japan
いたる にしおか ねＣ こｒｐ。 １７５３ しもぬまべ、 かわさき、 ２１１ー８６６６、 じゃぱん
Phone: +81 44 396 3287 EMail: i-nishioka@cb.jp.nec.com
電話：+81 44 396 3287 Eメール：i-nishioka@cb.jp.nec.com
Daniel King Old Dog Consulting United Kingdom
ダニエル・キング老犬のコンサルティングイギリス
Phone: +44 7790 775187 EMail: daniel@olddog.co.uk
電話：+44 7790 775187 Eメール：daniel@olddog.co.uk