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



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


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 ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント(に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.


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
1. Introduction
1. はじめに

[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リストを使用する場合の手順を指定するものではありません。

1.1. SVEC Object
1.1. 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:


o A set of independent and synchronized path computation requests.


o A set of dependent and synchronized path computation requests.


See [RFC5440] for more details on dependent, independent, and synchronous path computation.


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オブジェクト")で定義されています。

1.2. Application of SVEC Lists
1.2. 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:


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 Two diverse path computation requests would be needed to compute the working and disjointed protected paths.


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.


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 Single-domain, multi-PCE, dependent and synchronized path request.


o Multi-domain, dependent and synchronized path computation request, including end-to-end diverse path computation.


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.


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.


The SVEC association and disjoint VSPT are available to both single-PCE path computation and multi-PCE path computation.


2. Terminology

This document uses PCE terminology defined in [RFC4655], [RFC4875], and [RFC5440].


Associated SVECs: A group of multiple SVECs (Synchronization VECtors), defined in this document, to indicate a set of synchronized or concurrent path computations.


Disjoint VSPT: A set of VSPTs, defined in this document, to indicate a set of virtual diverse path trees.


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.


Synchronized: Describes a set of path computation requests that the PCE associates and that the PCE does not compute independently of each other.


VSPT: Virtual Shortest Path Tree, defined in [RFC5441].


3. SVEC Association Scenarios
3. SVEC協会のシナリオ

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.


3.1. Synchronized Computation for Diverse Path Requests
3.1. 多様なパス要求の同期化計算

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.


Two scenarios can be considered for the SVEC association of point-to-point diverse paths.


o Two or more end-to-end diverse paths


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.


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.


o End-to-end primary path and its segmented secondary paths


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.


                   <------------ primary ----------->

\ / \ /

¥ / ¥ /

                        P---Q---R        X---Y---Z

<--secondary1--> <--secondary2-->

< - 二次 - > < - セカンダリー2 - >

Figure 1. Segment Recovery Paths


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.


3.2. Synchronized Computation for Point-to-Multipoint Path Requests
3.2. ポイントツーマルチパス要求の同期化計算

For point-to-multipoint path requests, SVEC association can be applied.


o Two or more point-to-multipoint paths


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.


o Point-to-multipoint paths and their secondary paths


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.


4. SVEC Association
4. SVEC協会

This section describes the associations among SVECs in a SVEC list.


4.1. SVEC List
4.1. 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オブジェクトは、経路計算リクエストの異なる基を含みます。そのような異なるグループ間の関連付けを要求するとき、この文書で説明する関連SVECsが使用されます。

4.2. Associated SVECs
4.2. 関連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.


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.




<SVEC> without dependency flags


Request-ID #1, Request-ID #3, Request-ID #X

リクエスト-ID#1、リクエスト-ID#3、リクエスト-ID #X

<SVEC> with one or more dependency flags


Request-ID #1, Request-ID #2


<SVEC> with one or more dependency flags


Request-ID #3, Request-ID #4


<SVEC> without dependency flag


Request-ID #X, Request-ID #Y, Request-ID #Z

リクエスト-ID #X、リクエスト-ID#Y、リクエスト-ID #Z

4.3. Non-Associated SVECs
4.3. 非関連SVECs

"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.




<SVEC> with one or more dependency flags


Request-ID #1, Request-ID #2


<SVEC> with one or more dependency flags


Request-ID #3, Request-ID #4


<SVEC> without dependency flags


Request-ID #X, Request-ID #Y, Request-ID #Z

リクエスト-ID #X、リクエスト-ID#Y、リクエスト-ID #Z

5. Processing of SVEC List
5.1. Single-PCE, Single-Domain Environments
5.1. シングルPCE、シングルドメイン環境

In this environment, there is a single PCE within the domain.


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.


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.


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.


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".


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に応答しなければなりません。

5.2. Multi-PCE, Single-Domain Environments
5.2. マルチPCE、シングルドメイン環境

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.


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によって関連付け依存経路計算要求を送信してはなりません。

5.3. Multi-PCE, Multi-Domain Environments
5.3. マルチPCE、マルチドメイン環境

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.


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.


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.


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.


6. End-to-End Diverse Path Computation

In this section, the synchronous approach is provided to compute primary and secondary paths simultaneously.


6.1. Disjoint VSPT
6.1. 互いに素VSPT

The BRPC procedure constructs a VSPT to inform the enquiring PCE of potential paths to the destination node.


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.


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


           +----------+     +----------+

| 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




D1 D1 D1

D1 D1 D1

/ \ / \ / \

/ ¥ / ¥ / ¥



Figure 3. Disjoint VSPTs from PCE2 to PCE1

図3.ディスジョイントVSPTs PCE2からPCE1へ

6.2. Disjoint VSPT Encoding
6.2. 互いに素VSPTエンコーディング

Encoding for the disjoint VSPT follows the definition of PCEP message encoding in [RFC5440].


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.


If confidentiality is required between domains, the path key mechanism defined in [RFC5520] is used for a disjoint 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.


o Request ID #1 (Primary)


- 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)


- 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用】

6.3. Path Computation Procedure
6.3. パス計算手順

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.


7. Manageability Considerations

This section describes manageability considerations specified in [PCE-MNG-REQS].


7.1. Control of Function and Policy
7.1. 機能とポリシーの管理

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を構築する必要があります。

7.2. Information and Data Models (MIB Modules)
7.2. 情報とデータモデル(MIBモジュール)

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モジュールに値が存在することになります。この作品は、この文書の範囲の外に現在あります。

7.3. Liveness Detection and Monitoring
7.3. 生体検知とモニタリング

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].


7.4. Verifying Correct Operation
7.4. 正しい動作を確認

[RFC5440] provides a sufficient description for this document. There are no additional considerations.


7.5. Requirements on Other Protocols and Functional Components
7.5. その他のプロトコルと機能コンポーネントの要件

This document does not require any other protocol and functional components.


7.6. Impact on Network Operation
7.6. ネットワークオペレーションへの影響

[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.


8. Security Considerations

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).


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 Specifying which PCCs may request large SVEC associations through PCE access policy control.


9. References
9.1. Normative References
9.1. 引用規格

[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月。

9.2. Informative References
9.2. 参考文献

[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.


[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月、「パスを交換。

10. Acknowledgements

The authors would like to thank Adrian Farrel, Julien Meuric, and Filippo Cugini for their valuable comments.


Authors' Addresses


Itaru Nishioka NEC Corp. 1753 Shimonumabe, Kawasaki, 211-8666, Japan

いたる にしおか ねC こrp。 1753 しもぬまべ、 かわさき、 211ー8666、 じゃぱん

Phone: +81 44 396 3287 EMail:

電話:+81 44 396 3287 Eメール

Daniel King Old Dog Consulting United Kingdom


Phone: +44 7790 775187 EMail:

電話:+44 7790 775187 Eメール