[要約] RFC 6007は、依存するパスの同期化におけるSynchronization VECtor（SVEC）リストの使用に関するものです。このRFCの目的は、ネットワークのパス計算において、依存するパスの同期化を実現するためのSVECリストの使用方法を提案することです。
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
同期された従属パス計算のための同期ベクトル（SVEC）リストの使用
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
1.1. 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は、PATH計算クライアント（PCC）とPATH計算要素（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がPATH計算要求をPCEに送信すると、PCEP PATH計算要求（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の依存関係フラグ（つまり、ノード、リンク、または共有リスクリンクグループ（SRLG）多様なフラグ）によって指定された依存または独立したパス計算要求の2つの同期パス計算モードを定義します。
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-Numberによって一意に識別されます。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:
PSEのパス計算を実行するときに、PCHが依存関係でパス計算リクエストを同期することが重要です。たとえば、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 動作およびばらばらの保護されたパスを計算するには、2つの多様なパス計算要求が必要になります。
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.
多様なパス要求が連続的に計算されている場合、2番目の多様なパス計算と分離の制約を考慮せずに初期の多様なパス計算を履行すると、PCEが保護されたパスの下位最適なパスの結果を提供するか、終わりを満たすことができない場合があります。 - 完全に逆行する分離要件。
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段階のアプローチの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.
同期された従属パス計算の複数のセットの複数のSVEC間の関連については、このドキュメントと、ドメイン間のエンドツーエンドの多様なパス計算のためのルールをエンコードすることを否定する仮想最短パスツリー（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）または一連のOFSを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.
このドキュメントに記載されているSVEC協会と、複数またはエンドツーエンドの多様なパスに対してGCOを計算する場合、PCEPメッセージとオブジェクト形式への拡張機能は必要ありません。さらに、複数のSVECの使用は、SVECオブジェクト[RFC5440]で現在定義されているSRLG、ノード、およびリンクの多様性のみに制限されていませんが、他の従属パス計算要求にも使用できます。
The SVEC association and disjoint VSPT are available to both single-PCE path computation and multi-PCE path computation.
SVEC AssociationとDisjoint VSPTは、単一PCEパス計算とマルチPCEパス計算の両方で利用できます。
This document uses PCE terminology defined in [RFC4655], [RFC4875], and [RFC5440].
この文書は、[RFC4655]、[RFC4875]、および[RFC5440]で定義されたPCE用語を使用します。
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.
Disjoint 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（グローバルな同時最適化）：[RFC5557]で定義された同時パス計算アプリケーション。ネットワークリソースを効率的に利用するために、トラフィックエンジニアリング（TE）パスのセットが同時に計算されます。
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 Associationを適用できるいくつかのパス計算シナリオを明確にします。また、このセクションで説明されているシナリオの任意の組み合わせが適用される可能性があります。
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は、プライマリおよびセカンダリパスの多様性（またはばらば）の目標とネットワークリソースの最適化目標を満たす確率を高めるために、2つ以上のポイントツーポイントの多様なパスを同時に計算する場合があります。
Two scenarios can be considered for the SVEC association of point-to-point diverse paths.
ポイントツーポイントの多様なパスのSVEC関連の2つのシナリオを考慮することができます。
o Two or more end-to-end diverse paths
o 2つ以上のエンドツーエンドの多様なパス
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.
2つ以上のエンドツーエンドの多様なパスの同時パス計算が要求される場合、SVEC Associationが多様なパス要求の間で必要です。ここでは、各多様なパス要求は、プライマリ、セカンダリ、および三次（およびそれ以降の）パス要求で構成されており、すべてのパス要求が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 Associationがプライマリパスといくつかのセグメント化された二次パスの間で必要です。
<------------ primary ----------->
A------B------C---D------E------F
\ / \ /
P---Q---R X---Y---Z
p --- q --- r x --- y --- z
<--secondary1--> <--secondary2-->
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.
Point-to-MultiPoint Path Requestsの場合、SVEC Associationを適用できます。
o Two or more point-to-multipoint paths
o 2つ以上のポイントツーマルチポイントパス
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]として表されている場合、ネットワークを最適化するために、2つ以上のポイントツーマルチポイントパス計算要求を同時パス計算に関連付けることができます資力。
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 Associationが必要です。これらのリクエスト。このシナリオでは、セクション3.1の「エンドツーエンドプライマリパスとそのセグメント化された二次パス」シナリオと同じ仮定を使用します。
This section describes the associations among SVECs in a SVEC list.
このセクションでは、SVECリストのSVEC間の関連について説明します。
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オブジェクトには、パス計算要求の個別のグループが含まれています。このような異なるグループ間の関連性を要求する場合、このドキュメントで説明されている関連SVECが使用されます。
"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.
「関連するSVEC」とは、SVECリストに複数のSVECに関係があることを意味します。[RFC5440]には、1つのSVECのメンバーと同じSVECリストに別のSVECのメンバーとの間に自動関連がないことに注意してください。関連するSVECは、これらのSVECを関連付けるために導入され、特にSVEC間の依存フラグと相関するために。
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オブジェクト間の関連性を示すために使用されます。SVECオブジェクトに同じリクエストIDが存在する場合、これはこれらのSVECオブジェクトが関連付けられていることを示します。SVECオブジェクトに関連する場合、関連するSVEC間で少なくとも1つの要求識別子を共有する必要があります。SVECオブジェクトは、各SVECオブジェクトの依存関係フラグに関係なく関連付けることができますが、依存関係フラグがすべてのSVECオブジェクトで設定されていない場合は、単一のSVECを使用することをお勧めします。同様に、SVECオブジェクトに依存関係フラグと関連する場合、関連するSVECの最小セットを使用してそれらを構築することをお勧めします。
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.
以下は、関連するSVECの例です。この例では、最初のSVECは他のSVECに関連付けられており、関連するSVECに含まれるすべてのパス計算要求（つまり、リクエストID＃1、＃2、＃3、＃4、＃x、＃y、および#Z）は同期する必要があります。
<SVEC-list>
<sveclist>
<SVEC> without dependency flags
依存関係フラグなし<SVEC>
Request-ID #1, Request-ID #3, Request-ID #X
<SVEC> with one or more dependency flags
<SVEC> 1つ以上の依存関係フラグを備えています
Request-ID #1, Request-ID #2
request-id＃1、request-id＃2
<SVEC> with one or more dependency flags
<SVEC> 1つ以上の依存関係フラグを備えています
Request-ID #3, Request-ID #4
Request-ID＃3、Request-ID＃4
<SVEC> without dependency flag
<SVEC>依存関係フラグなし
Request-ID #X, Request-ID #Y, Request-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.
「非関連SVEC」とは、SVECの間に関係がないことを意味します。PCREQメッセージのSVECリストのSVECオブジェクトに共通のリクエストIDが含まれていない場合、SVECの間に関連性がないため、あるSVECのリクエストと別のSVECのリクエストとの間に関連性はありません。
Below is an example of non-associated SVECs that do not contain any common request-IDs.
以下は、一般的なリクエストIDを含まない非関連SVECの例です。
<SVEC-list>
<sveclist>
<SVEC> with one or more dependency flags
<SVEC> 1つ以上の依存関係フラグを備えています
Request-ID #1, Request-ID #2
request-id＃1、request-id＃2
<SVEC> with one or more dependency flags
<SVEC> 1つ以上の依存関係フラグを備えています
Request-ID #3, Request-ID #4
Request-ID＃3、Request-ID＃4
<SVEC> without dependency flags
依存関係フラグなし<SVEC>
Request-ID #X, Request-ID #Y, Request-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はPATH計算要求をキャンセルし、PCERRメッセージエラー-Type = "機能をサポートしていない"で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.
M PATH計算要求が複数のPCREQメッセージで送信される場合、PCEは[RFC5440]のセクション7.13.3（「SVECオブジェクトの取り扱い」）で推奨されるようにシンシマーを起動する場合があります。この場合、関連するSVECも[RFC5440]で説明されているように処理する必要があります。つまり、SVECSに関連付けられたMパス計算要求のセット全体を受信した後、計算は1から始まる必要があります。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.
ドメインには複数のPCEがあり、PCCSは直接通信でき、PCCSは負荷分散パス計算要求に適した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がPATH計算要求をPCEに送信し、SVECリストを使用して別のPATH計算リクエストを別のPCEに送信して、さらなる要求が最初の要求に依存していることを示す場合、PCEの方法はありません。異なるPCESに送信された従属要求を相関させます。PCES間のSVECオブジェクト相関関数は[RFC5440]で指定されていません。この問題を解決するメカニズムは存在しません。この問題は、将来の研究のために開かれています。したがって、PCCは、SVECSに関連付けられた異なるPCESに関連付けられた従属パス計算要求を送信してはなりません。
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を使用して計算されます。PCESのチェーンが事前に決定されており、後方再転着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.
SVECは、複数のドメインを横断するエンドツーエンドの多様なパス計算に適用できます。[RFC5441]は、ドメインのチェーン全体でエンドツーエンドの多様なパス計算のために、同期（つまり、同時）と2段階のアプローチの2つのアプローチを説明しています。[RFC5521]で説明されている2段階のアプローチでは、SVECオブジェクトの依存関係フラグのいずれかが設定されていない場合、関連するSVECを使用する必要はありません。一方、同時アプローチでは、関連するSVECが必要になる場合があります。これは、依存関係フラグの少なくとも1つを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.
このドキュメントのセクション6で説明されているように、別々のドメインにあるPCEのチェーンが同時パス計算に使用される場合、追加のパス計算処理が必要です。
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.
PCESのチェーンがPCREQメッセージ内のすべてのパス計算要求の一意のシーケンスである場合、SVECオブジェクト間の関連付けを再構築する必要はありません。したがって、PCREQメッセージはテールエンドPCEに渡されます。PCREQメッセージに依存関係フラグセットを備えた複数のSVECオブジェクトが含まれている場合、含まれるSVECが関連付けられる場合があります。関連するSVECを受信するPCESは、関連性を維持する必要があり、対応する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.
PCESのチェーンが異なる場合、そのようなPCREQメッセージを受信する中間PCESがSVECオブジェクト間の関連付けを再構築し、隣接するドメインにある対応するPCESにPCREQメッセージを送信することが必要です。関連するSVECが中間PCEで再構築された場合、PCEはすべての隣接PCEからすべてのPCREPメッセージが受信されるまでパス計算を開始してはなりません。ただし、SVEC再構成には複雑なPCE実装が必要であり、待機メカニズムを実装する必要があります。したがって、パス計算要求を異なるPCEチェーンと関連付けることはお勧めしません。これはオープンな問題であり、現在[H-PCE]で議論されており、階層的な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プロシージャは、VSPTを構築して、宛先ノードへの潜在的なパスの調査PCEを通知します。
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.
Dijoint VSPTの定義はVSPTのコレクションであり、各VSPTにはプライマリパスとセカンダリパスの潜在的なセットが含まれています。
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は境界ノードに配置される場合があります。このネットワークには、S1からD1までの一次パスとセカンダリパスが要求される場合、図3に示す多様なパスの潜在的なセットに3つのVSPTがあります。これらのVSPTは、PCE1のPCREPで示されているばらばらVSPTで構成されています。Disjoint VSPTを受信するとき、PCE1は否認要求と副「VSPT情報を認識します。その後、PCE1はリクエストの処理を継続し、BRPC手順[RFC5441]を使用して多様なパスを計算します。Disjoint VSPTのエンコードについては、セクション6.2で説明します。
Domain1 Domain2
domain1 domain2
+----------+ +----------+
| PCE1 | | PCE2 | S1: Source node
| BN1---BN4 | D1: Destination node
|BN1 --- BN4 |D1：宛先ノード
| S1 BN2---BN5 D1 | BN1-BN6: Border nodes
|S1 BN2 --- BN5 D1 |BN1-BN6：境界ノード
| BN3---BN6 |
|BN3 --- BN6 |
+----------+ +----------+
Figure 2. Example Network for Diverse Path Computation
図2.多様なパス計算のためのネットワークの例
VSPT1: VSPT2: VSPT3:
VSPT1：VSPT2：VSPT3：
D1 D1 D1
/ \ / \ / \
BN4 BN5 BN4 BN6 BN5 BN6
BN4 BN5 BN4 BN6 BN5 BN6
Figure 3. Disjoint VSPTs from PCE2 to PCE1
図3. PCE2からPCE1へのdijoint vspts
Encoding for the disjoint VSPT follows the definition of PCEP message encoding in [RFC5440].
Disjoint 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オブジェクト（リクエストパラメーターオブジェクト）に対して<パスリスト> as <path list> as <path list>を返します。<Pathリスト>の<Path>の順序は、<応答>の間で、一連の明示的なルートオブジェクト（EROS）とセカンダリEROSのセットを意味します。
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.
副「PATH> in <PATHリスト>の順序の順序を正しく調整する必要がある。
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.
以下は、S1からD1までの一次パスとセカンダリパスが要求される場合（図3）、nisjoint 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プロシージャの動作モードと同じ動作モードを適用できます（つまり、[RFC5441]のセクション4.2のステップ1からステップn）。考慮しなければならない質問は、馬鹿げたVSPTをどのように認識するかです。
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.
Disjoint VSPTSの認識は、PATH計算要求（PCREQ）情報を維持するPCREQを隣接PCEに送信する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は、Disjoint 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を識別および関連付けるためにSVECを構築する必要があります。
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モジュールに追加のパラメーターはありません。MIBモジュールには、SVECアソシエーションを詳述する価値があります。この作業は現在、このドキュメントの範囲外です。
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を使用すると、PCESは多様なパスの最適なセットを計算できます。このタイプのパス計算は、結果を得るためにより多くの時間が必要になる場合があります。したがって、PCEPが[RFC5886]で指定されたPCEモニタリングメカニズムをサポートすることをお勧めします。
[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]は、このドキュメントで説明されているメカニズムの説明を提供します。関連する大規模なSVECは、関連していないSVECと比較して、より大きなPCEリソースが必要になることを考慮すると価値があります。さらに、複数のPCREQメッセージ内で大規模な関連するSVECを送信するには、より多くのネットワークリソースが必要になります。これらの特定の問題を解決することは、このドキュメントの範囲外です。
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]に依存します。ただし、関連するSVECをサポートするPCEは、不正なPCCからのサービス拒否（DOS）攻撃に対して開かれている場合があります。PCEは、到着しない他のリクエストを待っている多数のリクエストをキューに入れることができます。さらに、非常に複雑な関連するSVEC計算を計算するためにPCEが作成される場合があります。これらのDOS攻撃は、実用的なSVECリスト制限を使用して緩和される場合があります。
o Applying provisioning to PCEs, e.g., for a given number of simultaneous services (recommended).
o 特定の数の同時サービス（推奨）に対して、PCESへのプロビジョニングを適用します。
o Using a priority-based multi-queuing mechanism in which path computation requests with a smaller SVEC list are prioritized for path computation processing.
o より小さなSVECリストを持つパス計算要求がパス計算処理に優先順位を付ける優先ベースのマルチキューイングメカニズムを使用します。
o Specifying which PCCs may request large SVEC associations through PCE access policy control.
o どのPCCがPCEアクセスポリシーコントロールを通じて大規模なSVEC関連を要求する可能性があるかを指定します。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657] Ash、J.、ed。、およびJ. Le Roux、ed。、「Path Computation Element（PCE）通信プロトコルジェネリック要件」、RFC 4657、2006年9月。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875] Aggarwal、R.、ed。、ed。、Papadimitriou、D.、ed。、およびS. Yasukawa、ed。、「リソース予約プロトコルへの拡張 - ポイントツーマルチポイントTEラベルの交通工学（RSVP-TE）スイッチPaths（LSP） "、RFC 4875、2007年5月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、Jp。、ed。、およびJl。Le Roux、ed。、「パス計算要素（PCE）通信プロトコル（PCEP）」、RFC 5440、2009年3月。
[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。、ed。、Zhang、R.、Bitar、N。、およびJl。Le Roux、「最短制約されたドメイン間トラフィックエンジニアリングラベルの切り替えパスを計算するための後方再帰PCEベースの計算（BRPC）手順」、RFC 5441、2009年4月。
[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] Bradford、R.、ed。、Vasseur、JP。、およびA. Farrel、「パスキーベースのメカニズムを使用したドメイン間パス計算のトポロジの機密性を保存」、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] Oki、E.、Takeda、T。、およびA. Farrel、「ルート除外のパス計算要素通信プロトコル（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] Lee、Y.、Le Roux、Jl。、King、D。、およびE. oki、「パス計算要素通信プロトコル（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] King、D.、ed。、およびA. Farrel、ed。、「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] Farrel、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。、ed。、Le Roux、Jl。、およびY. Ikejiri、「パス計算要素（PCE）ベースのアーキテクチャの監視ツールのセット」、RFC 5886、2010年6月。
[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] Zhao、Q.、Ed。、King、D.、Ed。、Verhaeghe、F.、Takeda、T.、Ali、Z.、およびJ. Meuric、「Path Computation Element Communication Protocolへの拡張）ポイントツーマルチポイントトラフィックエンジニアリングラベルの切り替えパス」、RFC 6006、2010年9月。
The authors would like to thank Adrian Farrel, Julien Meuric, and Filippo Cugini for their valuable comments.
著者は、貴重なコメントをしてくれたAdrian Farrel、Julien Meuric、Filippo Cuginiに感謝したいと思います。
Authors' Addresses
著者のアドレス
Itaru Nishioka NEC Corp. 1753 Shimonumabe, Kawasaki, 211-8666, Japan
Itaru Nishioka Nec Corp. 1753 Shimonumabe、Kawasaki、211-8666、日本
Phone: +81 44 396 3287
EMail: i-nishioka@cb.jp.nec.com
Daniel King Old Dog Consulting United Kingdom
ダニエルキングオールドドッグコンサルティングイギリス
Phone: +44 7790 775187
EMail: daniel@olddog.co.uk