Network Working Group A. Farrel
Request for Comments: 4655 Old Dog Consulting
Category: Informational J.-P. Vasseur
Cisco Systems, Inc.
J. Ash
AT&T
August 2006
A Path Computation Element (PCE)-Based Architecture
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.
制約ベースの経路計算は、マルチプロトコルラベルスイッチング（MPLS）と一般化マルチプロトコルラベルスイッチング（GMPLS）ネットワークなどのトラフィックエンジニアリングシステムの基本的なビルディング・ブロックです。大きな、マルチドメイン、マルチリージョン、またはマルチレイヤネットワークにおける経路計算は複雑であり、特別な計算構成要素と異なるネットワークドメイン間の協力を必要とするかもしれません。
This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed.
この文書では、この問題空間に対処するための経路計算エレメント（PCE）ベースモデルのアーキテクチャを指定します。この文書は、すべてのアーキテクチャコンポーネントの詳細な説明を提供しようとしない、むしろそれはソリューションを構築することができるから、PCEアーキテクチャのビルディングブロックのセットを記述する。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Definitions .....................................................4
4. Motivation for a PCE-Based Architecture .........................6
4.1. CPU-Intensive Path Computation .............................6
4.2. Partial Visibility .........................................7
4.3. Absence of the TED or Use of Non-TE-Enabled IGP ............7
4.4. Node Outside the Routing Domain ............................8
4.5. Network Element Lacks Control Plane or Routing Capability ..8
4.6. Backup Path Computation for Bandwidth Protection ...........8
4.7. Multi-layer Networks .......................................9
4.8. Path Selection Policy ......................................9
4.9. Non-Motivations ...........................................10
4.9.1. The Whole Internet .................................10
4.9.2. Guaranteed TE LSP Establishment ....................10
5. Overview of the PCE-Based Architecture .........................11
5.1. Composite PCE Node ........................................11
5.2. External PCE ..............................................12
5.3. Multiple PCE Path Computation .............................13
5.4. Multiple PCE Path Computation with Inter-PCE
Communication .............................................14
5.5. Management-Based PCE Usage ................................15
5.6. Areas for Standardization .................................16
6. PCE Architectural Considerations ...............................16
6.1. Centralized Computation Model .............................16
6.2. Distributed Computation Model .............................17
6.3. Synchronization ...........................................17
6.4. PCE Discovery and Load Balancing ..........................18
6.5. Detecting PCE Liveness ....................................20
6.6. PCC-PCE and PCE-PCE Communication .........................20
6.7. PCE TED Synchronization ...................................22
6.8. Stateful versus Stateless PCEs ............................23
6.9. Monitoring ................................................25
6.10. Confidentiality ..........................................25
6.11. Policy ...................................................26
6.11.1. PCE Policy Architecture ...........................26
6.11.2. Policy Realization ................................28
6.11.3. Type of Policies ..................................28
6.11.4. Relationship to Signaling .........................29
6.12. Unsolicited Interactions .................................30
6.13. Relationship with Crankback ..............................30
7. The View from the Path Computation Client ......................31
8. Evaluation Metrics .............................................32
9. Manageability Considerations ...................................33
9.1. Control of Function and Policy ............................33
9.2. Information and Data Models ...............................34
9.3. Liveness Detection and Monitoring .........................34
9.4. Verifying Correct Operation ...............................35
9.5. Requirements on Other Protocols and Functional
Components ................................................35
9.6. Impact on Network Operation ...............................36
9.7. Other Considerations ......................................36
10. Security Considerations .......................................37
11. Acknowledgements ..............................................37
12. Informative References ........................................38
Constraint-based path computation is a fundamental building block for traffic engineering in MPLS [RFC3209] and GMPLS [RFC3473] networks. [RFC2702] describes requirements for traffic engineering in MPLS networks, while [RFC4105] and [RFC4216] describe traffic engineering requirements in inter-area and inter-AS environments, respectively.
制約ベースの経路計算は、MPLS [RFC3209]とGMPLS [RFC3473]ネットワークにおけるトラフィックエンジニアリングの基本的なビルディングブロックです。 [RFC4105]及び[RFC4216]は、それぞれ、相互領域と相互AS環境におけるトラフィックエンジニアリング要件を記載しているが[RFC2702]は、MPLSネットワークでのトラヒックエンジニアリングのための要件を記述する。
Path computation in large, multi-domain networks is complex and may require special computational components and cooperation between the elements in different domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space.
大型マルチドメインネットワークにおける経路計算は複雑であり、特別な計算構成要素と異なるドメイン内の要素間の協力を必要とするかもしれません。この文書では、この問題空間に対処するための経路計算エレメント（PCE）ベースモデルのアーキテクチャを指定します。
This document describes a set of building blocks for the PCE architecture from which solutions may be constructed. For example, it discusses PCE-based implementations including composite, external, and multiple PCE path computation. Furthermore, it discusses architectural considerations including centralized computation, distributed computation, synchronization, PCE discovery and load balancing, detection of PCE liveness, communication between Path Computation Clients (PCCs) and the PCE (PCC-PCE communication) and PCE-PCE communication, Traffic Engineering Database (TED) synchronization, stateful and stateless PCEs, monitoring, policy and confidentiality, and evaluation metrics.
この文書では、ソリューションを構築することができるから、PCEアーキテクチャのビルディングブロックのセットを記述する。例えば、それは、複合外部、および複数のPCEの経路計算を含むPCEベースの実装について説明します。また、集中計算、分散計算、同期、PCE発見とロードバランシング、PCEの生存性の検出、経路計算クライアント（のPCC）とPCE（PCC-PCE通信）とPCE-PCEの通信との間の通信トラフィックを含むアーキテクチャの考慮事項について説明しますエンジニアリングデータベース（TED）の同期、ステートフルとステートレスのPCE、監視、ポリシーおよび機密性、および評価指標。
The model of the Internet is to distribute network functionality (e.g., routing) within the network. PCE functionality is not intended to contradict this model and can be used to match the model exactly, for example, when the PCE functionality coexists with each Label Switching Router (LSR) in the network. PCE is also able to augment functionality in the network where the Internet model cannot supply adequate solutions, for example, where traffic engineering information is not exchanged between network domains.
インターネットのモデルは、ネットワーク内のネットワーク機能（例えば、ルーティング）を分配することです。 PCEの機能は、このモデルと矛盾することを意図していないとPCEの機能は、ネットワーク内の各ラベルスイッチングルータ（LSR）と共存する場合、例えば、正確にモデルに適合するように使用することができます。 PCEはまた、トラフィックエンジニアリング情報はネットワークドメインとの間で交換されていないインターネットモデルは、例えば、適切なソリューションを提供することができないネットワークに機能を増強することができます。
CSPF: Constraint-based Shortest Path First.
CSPF：制約ベースの最短パスファースト。
LER: Label Edge Router.
LER：エッジルータにラベルを付けます。
LSDB: Link State Database.
LSDB：リンクステートデータベース。
LSP: Label Switched Path.
LSP：ラベルスイッチパス。
LSR: Label Switching Router.
LSR：ラベルスイッチングルータ。
PCC: Path Computation Client. Any client application requesting a path computation to be performed by the Path Computation Element.
PCC：パス計算クライアント。経路計算要素によって実行される経路計算を要求する任意のクライアントアプリケーション。
PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints (see further description in Section 3).
PCE：パス計算要素。エンティティネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用することが可能である（コンポーネント、アプリケーション、またはネットワークノード）（第3節でさらに説明を参照）。
TED: Traffic Engineering Database, which contains the topology and resource information of the domain. The TED may be fed by Interior Gateway Protocol (IGP) extensions or potentially by other means.
TED：ドメインのトポロジーおよびリソース情報が含まれているトラフィックエンジニアリングデータベース、。 TEDはインテリアゲートウェイプロトコル（IGP）の拡張によって、または潜在的に他の手段によって供給されてもよいです。
TE LSP: Traffic Engineering MPLS Label Switched Path.
TE LSP：トラフィックエンジニアリングMPLSラベルスイッチパス。
A Path Computation Element (PCE) is an entity that is capable of computing a network path or route based on a network graph, and of applying computational constraints during the computation. The PCE entity is an application that can be located within a network node or component, on an out-of-network server, etc. For example, a PCE would be able to compute the path of a TE LSP by operating on the TED and considering bandwidth and other constraints applicable to the TE LSP service request.
パス計算要素（PCE）ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算中に計算上の制約を適用することが可能なエンティティです。 PCEエンティティは、例えば、PCEは、TEDに操作することにより、TE LSPの経路を計算することができるであろう等、外のネットワークサーバ上で、ネットワーク・ノードまたはコンポーネント内に配置することができるアプリケーションであり、そしてTE LSPサービス要求に適用される帯域幅およびその他の制約を考慮。
A domain is any collection of network elements within a common sphere of address management or path computation responsibility. Examples of domains include IGP areas, Autonomous Systems (ASes), and multiple ASes within a Service Provider network. Domains of path computation responsibility may also exist as sub-domains of areas or ASes.
ドメインは、アドレス管理や経路計算責任の共通の球内のネットワーク要素の任意の集合です。ドメインの例としては、IGP領域、自律システム（のAS）、およびサービスプロバイダネットワーク内の複数のASを含みます。経路計算責任のドメインはまた、領域またはのASのサブドメインとして存在してもよいです。
In order to fully characterize a PCE and clarify these definitions, the following important considerations must also be examined:
完全にPCEを特徴付け、これらの定義を明確にするために、次の重要な考慮事項についても検討する必要があります。
1) Path computation is applicable in intra-domain, inter-domain, and inter-layer contexts.
1）パス計算は、イントラドメイン、ドメイン間、および層間コンテキストに適用可能です。
a. Inter-domain path computation may involve the association of topology, routing, and policy information from multiple domains from which relationships may be deduced in order to help in performing path computation.
A。ドメイン間経路計算は関係が経路計算を実行する際に支援するために推定することができるから、複数のドメインからのトポロジー、ルーティング、およびポリシー情報の関連付けを含むことができます。
b. Inter-layer path computation refers to the use of PCE where multiple layers are involved and when the objective is to perform path computation at one or multiple layers while taking into account topology and resource information at these layers.
B。層間経路計算は、複数の層が含まれるPCEの使用を指し、目的は、これらの層のアカウントトポロジーおよびリソース情報を考慮しながら、一つまたは複数の層で経路計算を実行するとき。
Overlapping domains are not within the scope of this document. In the inter-domain case, the domains may belong to a single or to multiple Service Providers.
重複ドメインは、この文書の範囲内ではありません。ドメイン間の場合、ドメインは、単一または複数のサービスプロバイダに属していてもよいです。
2) a. In "single PCE path computation", a single PCE is used to compute a given path in a domain. There may be multiple PCEs in a domain, but only one PCE per domain is involved in any single path computation.
2）A。 「単一PCEの経路計算」は、単一のPCEは、ドメイン内の所定の経路を計算するために使用されます。そこドメイン内の複数のPCEであってもよいが、ドメインごとに1つだけのPCEは、任意の単一の経路計算に関与していることがあります。
b. In "multiple PCE path computation", multiple PCEs are used to compute a given path in a domain.
B。 「複数のPCEの経路計算」において、複数のPCEは、ドメイン内の指定されたパスを計算するために使用されます。
3) a. "Centralized computation model" refers to a model whereby all paths in a domain are computed by a single, centralized PCE.
3）A。 「集中型計算モデル」は、ドメイン内のすべてのパスは、単一、集中PCEによって計算されるモデルを指します。
b. Conversely, "distributed computation model" refers to the computation of paths in a domain being shared among multiple PCEs.
B。逆に、「分散型計算モデル」は、複数のPCEの間で共有されるドメイン内経路の計算を指します。
Paths that span multiple domains may be computed using the distributed model with one or more PCEs responsible for each domain, or the centralized model by defining a domain that encompasses all the other domains.
複数のドメインにまたがるパスが他のすべてのドメインを含むドメインを定義することによって、各ドメインの責任一の以上のPCEを持つ分散モデル、または集中型モデルを用いて計算することができます。
From these definitions, a centralized computation model inherently uses single PCE path computation. However, a distributed computation model could use either single PCE path computation or multiple PCE path computations. There would be no such thing as a centralized model that uses multiple PCEs.
これらの定義から、集中型の計算モデルは、本質的に、単一のPCEの経路計算を使用しています。しかし、分散型計算モデルは、単一のPCEの経路計算又は複数のPCEの経路計算のいずれかを使用することができます。複数のPCEを使用する集中型モデルのようなものはないだろう。
4) The PCE may or may not be located at the head-end of the path. For example, a conventional intra-domain solution is to have path computation performed by the head-end LSR of an MPLS TE LSP; in this case, the head-end LSR contains a PCE. But solutions also exist where other nodes on the path must contribute to the path computation (for example, loose hops), making them PCEs in their own right. At the same time, the path computation may be made by some other PCE physically distinct from the computed path.
4）PCEは、またはパスのヘッドエンドに位置してもしなくてもよいです。例えば、従来のドメイン内溶液は、MPLS TE LSPのヘッドエンドLSRによって実行される経路計算を持つことです。この場合には、ヘッドエンドLSRは、PCEが含まれています。パス上の他のノードが経路計算（例えば、ゆるいホップ）に貢献しなければならない場合でも、ソリューションは、独自の右にそれらをのPCEを作り、存在します。同時に、経路計算は、計算された経路とは物理的に別個のいくつかの他のPCEによって製造することができます。
5) The path computed by the PCE may be an "explicit path" (that is, the full explicit path from start to destination, made of a list of strict hops) or a "strict/loose path" (that is, a mix of strict and loose hops comprising at least one loose hop representing the destination), where a hop may be an abstract node such as an AS.
5）PCEによって計算された経路は、それが、ミックスされ（「明示的なパス」（すなわち、厳密ホップのリストからなる開始から宛先への完全な明示的なパスである）、または「厳密/ルーズパス」であってもよいですホップがASのような抽象ノードとすることができる宛先を表す少なくとも一つのルーズホップを含む厳格な緩いホップ）の。
6) A PCE-based path computation model does not mean to be exclusive and can be used in conjunction with other path computation models. For instance, the path of an inter-AS TE LSP may be computed using a PCE-based path computation model in some ASes, whereas the set of traversed ASes may be specified by other means (not determined by a PCE). Furthermore, different path computation models may be used for different TE LSPs.
6）PCEベースの経路計算モデルは排他的であることを意味せず、他の経路計算モデルと組み合わせて使用することができます。横断のASのセットは、他の手段（PCEによって決定されていない）によって指定することができるのに対し、例えば、インターAS TE LSPの経路は、いくつかのAS内のPCEベースの経路計算モデルを用いて計算することができます。また、異なる経路計算モデルは、別のTE LSPのために使用することができます。
7) This document does not make any assumptions about the nature or implementation of a PCE. A PCE could be implemented on a router, an LSR, a dedicated network server, etc. Moreover, the PCE function is orthogonal to the forwarding capability of the node on which it is implemented.
7）この文書では、PCEの性質や実装についての仮定をしていません。 PCEはまた、PCEの機能は、それが実装されているノードの転送能力に直交するなど、LSR、専用ネットワーク・サーバ、ルータに実装することができます。
Several motivations for a PCE-based architecture (described in Section 5) are listed below. This list is not meant to be exhaustive and is provided for the sake of illustration.
（セクション5を参照）PCEベースのアーキテクチャのためのいくつかの動機を以下に列挙する。このリストは、網羅的であることを意味するものではなく、説明のために提供されます。
It should be highlighted that the aim of this section is to provide some application examples for which a PCE-based path may be suitable: this also clearly states that such a model does not aim to replace existing path computation models but would apply to specific existing or future situations.
このセクションの目的は、PCEベースのパスが適切であるそのためのいくつかの応用例を提供することであることを強調されるべきである。これはまた、明らかに、このようなモデルは、既存の経路計算モデルを置き換えることを目的としていないと述べているが、既存の特定に適用されますまたは将来の状況。
As can be seen from these examples, PCE does not replace the existing Internet model where intelligence is distributed within the network. Instead, it builds on this model and makes use of distributed centers of information or computational ability. PCE should not, therefore, necessarily be seen as a centralized, "all-seeing oracle in the sky", but as the cooperative operation of distributed functionality used to address specific challenges such as the computation of a shortest inter-domain constrained path.
これらの例からわかるように、PCEは知性がネットワーク内で配布され、既存のインターネットのモデルに代わるものではありません。代わりに、このモデルに基づいて構築された情報や計算能力の分散センターを利用します。 PCEは、従って、必ずしも「空に全シーイングオラクル」集中、と見られ、そのような最短ドメイン間制約経路の計算のような特定の課題に対処するために使用される分散された機能の協調動作とすべきではありません。
There are many situations where the computation of a path may be highly CPU-intensive; examples of CPU-intensive path computations include the resolution of problems such as:
経路の計算は非常にCPU集約型であり得る多くの状況があります。 CPU集中型経路計算の例は、以下のような問題の解決を含みます。
- Placing a set of TE LSPs within a domain so as to optimize an objective function (for example, minimization of the maximum link utilization)
- ドメイン内のTE LSPのセットを配置すること（例えば、最大リンク利用率の最小化）目的関数を最適化するように
- Multi-criteria path computation (for example, delay and link utilization, inclusion of switching capabilities, adaptation features, encoding types and optical constraints within a GMPLS optical network)
- 多基準経路計算（例えば、遅延、リンクの利用率、GMPLS光ネットワーク内のスイッチング機能、適応機能、符号化タイプと光学制約の包含のために）
- Computation of minimal cost Point to Multipoint trees (Steiner trees)
- 木対多最小限のコストポイントの計算（シュタイナー木）
In these situations, it may not be possible or desirable for some routers to perform path computation because of the constraints on their CPUs, in which case the path computations may be off-loaded to some other PCE(s) that may, themselves, be routers or may be dedicated PCE servers.
いくつかのルータがあるため、パス計算は、それ自体が、とすることができるいくつかの他のPCE（単数または複数）にオフロードすることができる場合には、そのCPU上の制約の経路計算を実行するために、これらの状況では、可能又は望ましくないかもしれませんルータまたはPCEサーバを専用にすることができます。
There are several scenarios where the node responsible for path computation has limited visibility of the network topology to the destination. This limitation may occur, for instance, when an ingress router attempts to establish a TE LSP to a destination that lies in a separate domain, since TE information is not exchanged across the domain boundaries. In such cases, it is possible to use loose routes to establish the TE LSP, relying on routers at the domain borders to establish the next piece of the path. However, it is not possible to guarantee that the optimal (shortest) path will be used, or even that a viable path will be discovered except, possibly, through repeated trial and error using crankback or other signaling extensions.
経路計算を担当するノードが宛先へのネットワークトポロジーの可視性を制限しているいくつかのシナリオがあります。この制限は、入口ルータがTE情報はドメインの境界を越えて交換されていないので、別のドメインにある宛先にTE LSPを確立しようとしたとき、例えば、起こり得ます。このような場合には、経路の次の部分を確立するために、ドメイン境界のルータに依存する、TE LSPを確立するために緩いルートを使用することが可能です。しかし、最適（最短）パスが使用されること、または実行可能なパスがクランクバックまたは他のシグナリングの拡張機能を使って試行錯誤を繰り返して、おそらく、を除いて発見されるも、ことを保証することはできません。
This problem of inter-domain path computation may most probably be addressed through distributed computation with cooperation among PCEs within each of the domains, and potentially using crankback between the domains to dynamically resolve provisioning issues. Alternatively, a central "all-seeing" PCE that has access to the complete set of topology information may be used, but in this case there are challenges of scalability (both the size of the TED and the responsiveness of a single PCE handling requests for many domains) and of preservation of confidentiality when the domains belong to different Service Providers.
ドメイン間経路計算の問題は、おそらくドメインのそれぞれの中のPCE間の協力と分散計算によって対処することが、潜在的に動的にプロビジョニング問題を解決するためにドメイン間のクランクバックを使用してもよいです。また、トポロジ情報の完全なセットへのアクセス権を持つ中央の「すべてを見通す」PCEを使用することができるが、この場合には、スケーラビリティの課題（TEDの大きさとするための単一のPCE処理要求の応答性の両方があります多くのドメイン）と機密保持のドメインが異なるサービスプロバイダに属しています。
Note that the issues described here can be further highlighted in the context of TE LSP reoptimization, or the establishment of multiple diverse TE LSPs for protection or load sharing.
ここで説明する問題はさらにTE LSPの再最適化の文脈、または保護や負荷分散のために複数の多様なTEのLSPの確立を強調表示することができることに注意してください。
The traffic engineering database (TED) may be a large drain on the resources of a network node (such as an edge router or LER). Maintaining the TED may require a lot of memory and may require non-negligible CPU activity. The use of a distinct PCE may be appropriate in such circumstances, and a separate node can be used to establish and maintain the TED, and to make it available for path computation.
トラフィックエンジニアリングデータベース（TED）は、（例えば、エッジルータ又はLERのような）ネットワーク・ノードのリソースに大きなドレインであってもよいです。 TEDを維持することは、多くのメモリを必要とするかもしれないし、無視できないCPUの活動が必要な場合があります。異なるPCEの使用は、このような状況において適切であるかもしれない、と別のノードは、TEDを確立し、維持するために使用することができ、経路計算のためにそれを利用できるようにします。
The IGPs run within some networks are not sufficient to build a full TED. For example, a network may run OSPF/IS-IS without the OSPF-TE/ISIS-TE extensions, or some routers in the network may not support the TE extensions. In these cases, in order to successfully compute paths through the network, the TED must be constructed or supplemented through configuration action and updated as network resources are reserved or released. Such a TED could be distributed to the routers that need to perform path computation or held centrally (on a distinct node that supports PCE) for centralized computation.
いくつかのネットワーク内で実行するのIGPは、フルTEDを構築するのに十分ではありません。例えば、ネットワークは、OSPF-TE / ISIS-TEの拡張なしでOSPF / ISISを実行することができる、またはネットワーク上のいくつかのルータはTE拡張をサポートしていないかもしれません。これらのケースでは、成功したネットワーク経由の経路を計算するために、TEDは、構築や補足構成アクションを通って、ネットワークリソースが予約または解放されているように更新する必要があります。そのようなTEDは、経路計算を実行し、または集中化計算のため（PCEをサポートする別個のノードで）中央に保持する必要がルータに分配することができます。
An LER might not be part of the routing domain for administrative reasons (for example, a customer-edge (CE) router connected to the provider-edge (PE) router in the context of MPLS VPN [RFC4364] and for which it is desired to provide a CE to CE TE LSP path).
LERは、管理上の理由MPLS VPNの文脈において、プロバイダエッジ（PE）ルータ[RFC4364]に、それが望まれる接続（例えば、顧客エッジ（CE）ルータのルーティングドメインの一部ではないかもしれませんCE TE LSPパスにCEを提供します）。
This scenario suggests a solution that does not involve doing computation on the ingress (TE LSP head-end, CE) router, and that does not rely on the configuration of static loose hops. In this case, optimal shortest paths cannot be guaranteed. A solution that a distinct PCE can help here. Note that the PCE in this case may, itself, provide a path that includes loose hops.
このシナリオでは、入口（TE LSPのヘッドエンド、CE）ルータ上で計算を行って関与しない解決策を提案し、それは静的なゆるいホップの設定に依存しません。この場合、最適な最短経路を保証することはできません。個別のPCEはここに助けることができるソリューション。この場合のPCEは、それ自体、ルーズホップを含む経路を提供してもよいことに留意されたいです。
It is common in legacy optical networks for the network elements not to have a control plane or routing capability. Such network elements only have a data plane and a management plane, and all cross-connections are made from the management plane. It is desirable in this case to run the path computation on the PCE, and to send the cross-connection commands to each node on the computed path. That is, the PCC would be an element of the management plane, perhaps residing in the Network Management System (NMS) or Operations Support System (OSS).
なお、制御プレーンまたはルーティング機能を持たないネットワーク要素のための従来の光ネットワークでは一般的です。そのようなネットワーク要素は、データプレーンおよび管理プレーンを有し、すべての相互接続を管理プレーンから作られます。それはPCEに経路計算を実行し、計算された経路上の各ノードに相互接続コマンドを送信するために、この場合には望ましいです。つまり、PCCは、おそらくネットワーク管理システム（NMS）またはオペレーションサポートシステム（OSS）に存在する、管理面の要素になります。
This scenario is important for Automatically Switched Optical Network (ASON)-capable networks and may also be used for interworking between GMPLS-capable and GMPLS-incapable networks.
このシナリオは、自動交換光ネットワーク（ASON）対応ネットワークのために重要であり、また可能なGMPLS-とGMPLS非対応ネットワーク間のインターワーキングのために使用することができます。
A PCE can be used to compute backup paths in the context of fast reroute protection of TE LSPs. In this model, all backup TE LSPs protecting a given facility are computed in a coordinated manner by a PCE. This allows complete bandwidth sharing between backup tunnels protecting independent elements, while avoiding any extensions to TE
PCEは、TE LSPの高速リルート保護の文脈でのバックアップのパスを計算するために使用することができます。このモデルでは、所定の機能を保護するすべてのバックアップのTE LSPは、PCEによって協調して計算されます。 TEへの拡張を回避しながらこれは、独立した要素を保護するバックアップトンネルの間の完全な帯域幅の共有を可能に
LSP signaling. Both centralized and distributed computation models are applicable. In the distributed case each LSR can be a PCE to compute the paths of backup tunnels to protect against the failure of adjacent network links or nodes.
LSPシグナリング。集中型と分散型の両方の計算モデルが適用可能です。分散場合、各LSRは、隣接するネットワークリンクまたはノードの障害から保護するためにバックアップトンネルの経路を計算するPCEであることができます。
A server-layer network of one switching capability may support multiple networks of another (more granular) switching capability. For example, a Time-Division Multiplexing (TDM) network may provide connectivity for client-layer networks such as IP, MPLS, or Layer 2 [MLN].
一つのスイッチング能力のサーバレイヤネットワークは、別の（より細かい）の複数のネットワークスイッチング機能をサポートすることができます。例えば、時分割多重（TDM）ネットワークは、IP、MPLS、またはレイヤ2 [MLN]としてクライアントレイヤネットワークの接続性を提供することができます。
The server-layer network is unlikely to provide the same connectivity paradigm as the client networks, so bandwidth granularity in the server-layer network may be much coarser than in the client-layer network. Similarly, there is likely to be a management separation between the two networks providing independent address spaces. Furthermore, where multiple client-layer networks make use of the same server-layer network, those client-layer networks may have independent policies, control parameters, address spaces, and routing preferences.
サーバレイヤネットワークは、クライアントネットワークと同じ接続性パラダイムを提供することはほとんどありませんので、サーバレイヤネットワークにおける帯域幅の粒度は、クライアントレイヤネットワークにおけるよりもはるかに粗くなることがあります。同様に、独立したアドレス空間を提供する2つのネットワーク間の管理分離である可能性があります。複数のクライアント層ネットワークが同じサーバー層のネットワークを利用してどこさらに、それらのクライアントレイヤネットワークは独立した政策、制御パラメータ、アドレス空間、およびルーティングの好みを有することができます。
The different client- and server-layer networks may be considered distinct path computation regions within a PCE domain, so the PCE architecture is useful to allow path computation from one client-layer network region, across the server-layer network, to another client-layer network region.
異なるクライアント側およびサーバレイヤネットワークはPCEドメイン内の別個の経路計算領域と考えることができるので、PCEアーキテクチャは、一つのクライアント層ネットワーク領域から、サーバレイヤネットワークを介し、別のクライアント - に経路計算を可能にするのに有用ですレイヤネットワーク領域。
In this case, the PCEs are responsible for resolving address space issues, handling differences in policy and control parameters, and coordinating resources between the networks. Note that, because of the differences in bandwidth granularity, connectivity across the server-layer network may be provided through virtual TE links or Forwarding Adjacencies: the PCE may offer a point of control responsible for the decision to provision new TE links or Forwarding Adjacencies across the server-layer network.
この場合、のPCEは、アドレス空間の問題を解決する政策や制御パラメータの違いを取り扱い、およびネットワーク間でのリソースの調整を担当しています。なぜなら、帯域幅粒度の違いにより、サーバ層のネットワークを介して接続が仮想のTEリンクやフォワーディング隣接関係を介して提供することができる、ということに注意してください：PCEは全体で提供新しいTEリンクまたはフォワーディング隣接関係を決定するコントロールのポイントを提供することがありますサーバレイヤネットワーク。
A PCE may have a local policy that impacts path computation and selection in response to a path computation request. Such policy may act on information provided by the requesting PCC. The result of applying such policy includes, for example, rejection of the path computation request, or provision of a path that does not meet all of the requested constraints. Further, the policy may support administratively configured paths, or selection among transit providers. Inclusion of policy within PCE may simplify the application of policy within the path computation/selection process.
PCEは、経路計算要求に応じて、ローカルポリシーに影響を与える経路計算および選択を有することができます。このような方針は、要求PCCによって提供される情報に作用することができます。そのようなポリシーを適用した結果は、例えば、要求された制約条件の全てを満たしていないパスの経路計算要求、または規定の拒絶。さらに、ポリシーは、トランジット・プロバイダ間で管理構成パス、または選択をサポートすることができます。 PCE内のポリシーを含めることは、経路計算/選択プロセス内のポリシーの適用を単純化することができます。
Similarly, a PCC may apply local policy to the selection of a PCE to compute a specific path, and to the constraints that are requested.
同様に、PCCは、特定の経路を計算するPCEの選択に、及び要求された制約のために、ローカルポリシーを適用することができます。
In a PCE context, the policy may be sensitive to the type of path that is being computed. For example, a different set of policies may be applied for an intra-area or single-layer path than would be provided for an inter-area or multi-layer path.
PCEの文脈において、ポリシーが計算されるパスのタイプに敏感であってもよいです。例えば、ポリシーの異なるセットは、相互領域又は多層パスのために提供されるよりもエリア内または単一層のパスに適用することができます。
Note that synchronization of policy between PCEs or between PCCs and PCEs may be necessary. Such issues are outside the scope of the PCE architecture, but within scope for the PCE policy framework and application which is described in a separate document.
PCE間またはのPCCとPCEとの間のポリシーの同期注意が必要であってもよいです。そのような問題は、PCEアーキテクチャの範囲外であるが、別の文書に記載されているPCEポリシーフレームワークとアプリケーションの範囲内です。
PCE is not considered to be a solution that is applicable to the entire Internet. That is, the applicability of PCE is limited to a set of domains with known relationships. The scale of this limitation is similar to the peering relationships between Service Providers.
PCEは、インターネット全体にも適用することが解決策ではないと考えられます。それはPCEの適用性は、既知の関係を持つドメインのセットに限定されている、です。この制限の規模は、サービスプロバイダ間のピアリング関係と同様です。
When two or more paths for TE LSPs are computed on the same set of TE link state information, it is possible that the resultant paths will compete for limited resources within the network. This may result in success for only the first TE LSP to be signaled, or it might even mean that no TE LSP can be established.
TE LSPのために2つの以上のパスがTEリンク状態情報の同じセットで計算されている場合、結果として得られるパスは、ネットワーク内の限られたリソースの競合する可能性があります。これが合図するだけで最初のTE LSPのための成功をもたらすことができるか、それも何のTE LSPを確立できないことを意味するかもしれません。
Batch processing of computation requests, back-off times, computation of alternate paths, and crankback can help to mitigate this sort of problem, and PCE may also improve the chances of successful TE LSP setup. However, a single, centralized PCE is not viewed as a solution that can guarantee TE LSP establishment since the potential for network failures or contention for resources still exists where the centralized TED cannot fully reflect current (i.e., real-time) network state.
バッチ計算要求の処理、バックオフ時間、代替パスの計算、およびクランクバックは、この種の問題を軽減するのに役立つことができ、及びPCEにも成功したTE LSP設定の可能性を向上させることができます。しかし、単一、集中PCEは、集中TEDが完全電流（即ち、リアルタイム）ネットワークの状態を反映することができない場合にリソースのネットワーク障害または競合の可能性が依然として存在するためTE LSPの確立を保証することができる解決策として見なされません。
This section gives an overview of the architecture of the PCE model. It needs to be read in conjunction with the details provided in the next section to provide a full view of the flexibility of the model.
このセクションでは、PCEモデルのアーキテクチャの概要を説明します。これは、モデルの柔軟性の完全なビューを提供するために、次のセクションで提供詳細と併せて読まれる必要があります。
Figure 1 below shows the components of a typical composite PCE node (that is, a router that also implements the PCE functionality) that utilizes path computation. The routing protocol is used to exchange TE information from which the TED is constructed. Service requests to provision TE LSPs are received by the node and converted into signaling requests, but this conversion may require path computation that is requested from a PCE. The PCE operates on the TED subject to local policy in order to respond with the requested path.
図1は、以下の一般的な合成PCEノードの構成要素を示している（つまり、また、PCEの機能を実装するルータ）経路計算を利用します。ルーティングプロトコルは、TEDが構築されたTE情報を交換するために使用されます。規定TEのLSPへのサービス要求は、ノードによって受信され、シグナリング要求に変換し、この変換は、PCEから要求された経路計算を必要とするかもしれないれています。 PCEは要求されたパスに対応するために、ローカルポリシーにTEDの被写体に動作します。
---------------
| --------- | Routing ----------
| | | | Protocol | |
| | TED |<-+----------+-> |
| | | | | |
| --------- | | |
| | | | |
| | Input | | |
| v | | |
| --------- | | |
| | | | | Adjacent |
| | PCE | | | Node |
| | | | | |
| --------- | | |
| ^ | | |
| |Request | | |
| |Response| | |
| v | | |
| --------- | | |
Service | | | | Signaling| |
Request | |Signaling| | Protocol | |
------+->| Engine |<-+----------+-> |
| | | | | |
| --------- | ----------
---------------
Figure 1. Composite PCE Node
図1複合PCEノード
Note that the routing adjacency between the composite PCE node and any other router may be performed by means of direct connectivity or any tunneling mechanism.
複合PCEノードと他のルータとの間のルーティング隣接関係が直接接続またはトンネル機構によって行われてもよいことに留意されたいです。
Figure 2 shows a PCE that is external to the requesting network element. A service request is received by the head-end node, and before it can initiate signaling to establish the service, it makes a path computation request to the external PCE. The PCE uses the TED subject to local policy as input to the computation and returns a response.
図2は、要求元ネットワーク要素の外部にあるPCEを示しています。サービス要求は、ヘッドエンドノードによって受信され、それがサービスを確立するためのシグナリングを開始することができる前に、それは外部のPCEに経路計算要求を行います。 PCEは、計算への入力としてローカルポリシーにTEDの件名を使用して応答を返します。
----------
| ----- |
| | TED |<-+----------->
| ----- | TED synchronization
| | | mechanism (for example, routing protocol)
| | |
| v |
| ----- |
| | PCE | |
| ----- |
----------
^
| Request/
| Response
v
Service ---------- Signaling ----------
Request | Head-End | Protocol | Adjacent |
---->| Node |<---------->| Node |
---------- ----------
Figure 2. External PCE Node
図2.外部PCEノード
Note that in this case, the node that supports the PCE function may also be an LSR or router performing forwarding in its own right (i.e., it may be a composite PCE node), but those functions are purely orthogonal to the operation of the function in the instance being considered here.
なお、この場合、PCEの機能をサポートしているノードは、LSRまたは（すなわち、それは複合PCEノードであってもよい）、それ自体に転送を行うルータが、これらの機能は、機能の操作に純粋に直交していることができます例えば、ここで検討されています。
Figure 3 illustrates how multiple PCE path computations may be performed along the path of a signaled service. As in the previous example, the head-end PCC makes a request to an external PCE, but the path that is returned is such that the next network element finds it necessary to perform further computation. This may be the case when the path returned is a partial path that does not reach the intended destination or when the computed path is loose. The downstream network element consults another PCE to establish the next hop(s) in the path. In this case, all policy decisions are made independently at each PCE based on information passed from the PCC.
図3は、複数のPCEの経路計算は、シグナリングサービスの経路に沿って行うことができる方法を示します。前の例のように、ヘッドエンドPCCは、外部のPCEに要求を行うが、返されたパスは、次のネットワーク要素がさらに計算を実行する必要があると認めるようなものです。返された経路が計算された経路が緩んでいるときに意図された宛先に到達しないか、または部分的なパスである場合、これは場合であってもよいです。下流ネットワーク要素はパスの次のホップ（複数可）を確立するための別のPCEを参照します。この場合、すべてのポリシーの決定は、PCCから渡された情報に基づいて、各PCEに独立に行われます。
Note that either or both PCEs in this case could be composite PCE nodes, as in Section 5.1.
この場合のいずれかまたは両方のPCEは、第5.1節と同様に、複合PCEノードであってもよいことに留意されたいです。
---------- ----------
| | | |
| PCE | | PCE |
| | | |
| ----- | | ----- |
| | TED | | | | TED | |
| ----- | | ----- |
---------- ----------
^ ^
| Request/ | Request/
| Response | Response
v v
Service -------- Signaling ------------ Signaling ------------
Request |Head-End| Protocol |Intermediate| Protocol |Intermediate|
---->| Node |<--------->| Node |<--------->| Node |
-------- ------------ ------------
Figure 3. Multiple PCE Path Computation
図3.複数のPCEの経路計算
The PCE in Section 5.3 was not able to supply a full path for the requested service, and as a result the adjacent node needs to make its own computation request. As illustrated in Figure 4, the same problem may be solved by introducing inter-PCE communication, and cooperation between PCEs so that the PCE consulted by the head-end network node makes a request of another PCE to help with the computation.
セクション5.3でPCEは、要求されたサービスのための完全なパスを供給することができなかった、結果として隣接ノードは、独自の計算要求を行う必要があります。図4に示すように、同様の問題は、ヘッドエンドネットワークノードによって相談PCEは、計算を支援する別のPCEの要求を行うように相互PCE通信、及びのPCE間の協力を導入することによって解決することができます。
---------- ----------
| | Inter-PCE Request/Response | |
| PCE |<--------------------------------->| PCE |
| | | |
| ----- | | ----- |
| | TED | | | | TED | |
| ----- | | ----- |
---------- ----------
^
| Request/
| Response
v
Service ---------- Signaling ---------- Signaling ----------
Request | Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ----------
Figure 4. Multiple PCE Path Computation with Inter-PCE Communication
インターPCE通信図4.複数のPCEの経路計算
Multiple PCE path computation with inter-PCE communication involves coordination between distinct PCEs such that the result of the computation performed by one PCE depends on path fragment information supplied by other PCEs. This model does not provide a distributed computation algorithm, but it allows distinct PCEs to be responsible for computation of parts (segments) of the path.
PCE間の通信で複数のPCEの経路計算は、一のPCEによって実行される計算の結果は、他のPCEによって供給されたパス断片情報に依存するように、別個のPCE間の調整を必要とします。このモデルは、分散型計算アルゴリズムを提供していないが、それは別個のPCEは、経路の部分（セグメント）の計算を担当することを可能にします。
PCE-PCE communication is discussed further in Section 6.6.
PCE-PCE通信は、セクション6.6で詳しく説明されています。
Note that a PCC might not see the difference between centralized computation and multiple PCE path computation with inter-PCE communication. That is, the PCC network node or component that requests the computation makes a single request and receives a full or partial path in response, but the response is actually achieved through the coordinated, cooperative efforts of more than one PCE.
PCCは、PCE間の通信に集中計算と複数のPCEの経路計算の間の差が表示されない可能性があることに注意してください。すなわち、計算を要求するPCCネットワークノードまたはコンポーネントが単一の要求を行い、応答して完全または部分的なパスを受信しているが、応答は実際に複数のPCEの協調、協調努力によって達成されます。
In this model, all policy decisions may be made independently at each PCE based on computation information passed from the previous PCE. Alternatively, there may be explicit communication of policy information between PCEs.
このモデルでは、すべてのポリシーの決定は、以前のPCEから渡された演算情報に基づいて、各PCEに独立に行うことができます。代替的に、のPCE間のポリシー情報の明示的な通信があってもよいです。
It must be observed that the PCC is not necessarily an LSR. For example, in Figure 5 the NMS supplies the head-end LSR with a fully computed explicit path for the TE LSP that it is to establish through signaling. The NMS uses a management plane mechanism to send this request and encodes the data using a representation such as the TE MIB module [RFC3812].
PCCは必ずしもLSRではないことが観察されなければなりません。例えば、図5にNMSは、シグナリングを通じて確立することであることTE LSPの完全計算明示的経路とヘッドエンドLSRを供給する。 NMSは、この要求を送信する管理プレーン機構を使用し、そのようなTE MIBモジュール[RFC3812]として表現を使用してデータを符号化します。
The NMS constructs the explicit path that it supplies to the head-end LSR using information provided by the operator. It consults the PCE, which returns a path for the NMS to use.
NMSは、オペレータによって提供される情報を使用してヘッドエンドLSRに供給する明示的なパスを構築します。これは、NMSが使用するパスを返すPCEを、参照します。
Although Figure 5 shows the PCE as remote from the NMS, it could, of course, be collocated with the NMS.
図5は、NMSからリモートとしてPCEを示しているが、それは、もちろん、NMSと連結することができます。
-----------
| ----- |
Service | | TED |<-+----------->
Request | ----- | TED synchronization
| | | | mechanism (for example,
v | | | routing protocol)
------------- Request/ | v |
| | Response| ----- |
| NMS |<--------+> | PCE | |
| | | ----- |
------------- -----------
Service |
Request |
v
---------- Signaling ----------
| Head-End | Protocol | Adjacent |
| Node |<---------->| Node |
---------- ----------
Figure 5. Management-Based PCE Usage
図5.管理ベースPCEの使い方
The following areas require standardization within the PCE architecture.
以下の分野ではPCEアーキテクチャ内の標準化が必要です。
- communication between PCCs and PCEs, and between cooperating PCEs, including the communication of policy-related information
- のPCCとPCEとの間、及びポリシー関連情報の通信を含む協働のPCE間の通信
- requirements for extending existing routing and signaling protocols in support of PCE discovery and signaling of inter-domain paths
- ドメイン間経路のPCE発見及びシグナリングをサポートするために既存のルーティングおよびシグナリングプロトコルを拡張するための要件
- definition of metrics to evaluate path quality, scalability, responsiveness, robustness, and policy support of path computation models.
- パスの品質、拡張性、応答性、堅牢性、および経路計算モデルの政策支援を評価するためのメトリクスの定義。
- MIB modules related to communication protocols, routing and signaling extensions, metrics, and PCE monitoring information
- 通信プロトコル、ルーティングおよびシグナリング拡張、メトリクス、及びPCE監視情報に関連するMIBモジュール
This section provides a list of the PCE architectural components. Specific realizations and implementation details (state machines or algorithms, etc.) of PCE-based solutions are out of the scope of this document.
このセクションでは、PCEアーキテクチャコンポーネントのリストを提供します。特定の実現とPCEベースのソリューションの実装の詳細（状態機械またはアルゴリズムなど）は、この文書の範囲外です。
Note also that PCE-based path computation does not affect in any way the use of the computed paths. For example, the use of PCE does not change the way in which Traffic Engineering LSPs are signaled, maintained, and torn down, but it strictly relates to the path computation aspects of such TE LSPs.
メモはまた、PCEベースの経路計算は、どのような方法で計算パスの使用に影響を及ぼしません。例えば、PCEの使用は、トラフィックエンジニアリングのLSPは、シグナリング維持され、切断された方法を変更しないが、それは厳密にそのようなTEのLSPの経路計算の側面に関する。
This section presents an architectural view of PCE. That is, it describes the components that exist and how they interact. Note that the architectural model, and in particular the functional model, may be perceived differently by different components of the PCE system. For example, the PCC will not be aware of whether a PCE consults other PCEs. The PCC view of the PCE architecture is discussed in Section 7.
このセクションでは、PCEの建築図を示します。それはそれは存在し、それらがどのように相互作用するかのコンポーネントを説明し、です。建築モデル、特に、機能モデルは、PCEシステムの異なる構成要素によって異なって知覚されてもよいことに留意されたいです。例えば、PCCは、PCEは、他のPCEを参照するかどうかを認識できません。 PCEアーキテクチャのPCC図は第7章で議論されています。
A "centralized computation model" considers that all path computations for a given domain will be performed by a single, centralized PCE. This may be a dedicated server (for example, an external PCE node), or a designated router (for example, a composite PCE node) in the network. In this model, all PCCs in the domain would send their path computation requests to the central PCE. While a domain in this context might be an IGP area or AS, it might also be a sub-group of network nodes that is defined by its dependence on the PCE.
「集中型計算モデル」は、所与のドメインのすべてのパスの計算は、単一、集中PCEによって実行されるであろうと考えています。これは、ネットワーク内の（例えば、外部のPCEノード）は、専用サーバ、または指定ルータ（例えば、複合PCEノード）であってもよいです。このモデルでは、ドメイン内のすべてのPCCは、中央PCEへの経路計算要求を送信します。この文脈におけるドメインはIGP領域またはASかもしれないが、それはまたPCEへの依存によって定義されるネットワークノードのサブグループであるかもしれません。
This model has a single point of failure: the PCE. In order to avoid this issue, the centralized computation model may designate a backup PCE that can take over the computation responsibility in a controlled manner in the event of a failure of the primary PCE. Any policies present on the primary PCE should also be present on the backup, although the primary policies may themselves be subject to policy governing how they are implemented on the backup. Note that at any moment in time there is only one active PCE in any domain.
PCE：このモデルは、単一障害点があります。この問題を回避するためには、集中型の計算モデルは、プライマリPCEの障害が発生した場合に制御された方法で計算責任を引き継ぐことができるバックアップPCEを指定することができます。主要政策自体はそれらがバックアップに実装されている方法を管理するポリシーの対象となるかもしれないが、プライマリPCE上に存在する任意のポリシーはまた、バックアップ上に存在する必要があります。時間の任意の時点で任意のドメインで唯一のアクティブなPCEがあることに注意してください。
A "distributed computation model" refers to a domain or network that may include multiple PCEs, and where computation of paths is shared among the PCEs. A given path may in turn be computed by a single PCE ("single PCE path computation") or multiple PCEs ("multiple PCE path computation"). A PCC may be linked to a particular PCE or may be able to choose freely among several PCEs; the method of choice between PCEs is out of scope of this document, but see Section 6.4 for a discussion of PCE discovery that affects this choice. Implementation of policy should be consistent across the set of available PCEs.
「分散計算モデル」は、複数のPCEを含むことができるドメインまたはネットワークを参照し、経路の計算は、のPCEの間で共有されます。指定されたパスは、順番に、単一のPCE（「単一PCEの経路計算」）または複数のPCE（「複数のPCEの経路計算」）によって計算することができます。 PCCは、特定のPCEに連結され得るか、またはいくつかのPCE間で自由に選択することができるかもしれません。 PCEの間の選択の方法は、この文書の範囲外であるが、この選択に影響を与えPCE発見の議論については、セクション6.4を参照してください。政策の実施は可能なのPCEのセット全体で一貫している必要があります。
Often, the computation of an individual path is performed entirely by a single PCE. For example, this is usually the case in MPLS TE within a single IGP area where the ingress LSR/composite PCE node is responsible for computing the path or for contacting an external PCE. Conversely, multiple PCE path computation implies that more than one PCE is involved in the computation of a single path. An example of this is where loose hop expansion is performed by transit LSRs/composite PCE nodes on an MPLS TE LSP. Another example is the use of multiple cooperating PCEs to compute the path of a single TE LSP across multiple domains.
多くの場合、個々の経路の計算は、単一のPCEによって完全に実行されます。例えば、これは、通常、入口LSR /複合PCEノードが経路を計算するための、または外部PCEに接触する責任がある単一のIGP領域内のMPLS TEの場合です。逆に、複数のPCEの経路計算は、複数のPCEが単一経路の計算に関与していることを意味します。ルーズホップ拡張をMPLS TE LSP上のトランジットのLSR /複合PCEノードによって実行されるこの例です。別の例では、複数のドメインにわたる単一TE LSPの経路を計算するために、複数の協働のPCEの使用です。
Often, multiple paths need to be computed to support a single service (for example, for protection or load sharing). A PCC that determines that it requires more than one path to be computed may send a series of individual requests to the PCE. In this case of non-synchronized path computation requests, the PCE may make multiple individual path computations to generate the paths, and the PCC may send its individual requests to different PCEs.
しばしば、複数のパス（たとえば、保護または負荷分散のために）単一のサービスをサポートするために計算される必要があります。それは計算される複数のパスが必要と判断したPCCは、PCEに個々の要求の系列を送信することができます。非同期経路計算リクエストこの場合、PCEは、経路を生成するために、複数の個々の経路計算を行うことができ、及びPCCは別のPCEへの個々の要求を送信することができます。
Alternatively, the PCC may send a single request to a PCE asking for a set of paths to be computed, but specifying that non-synchronized path computation is acceptable. The PCE may compute each path in turn exactly as it would have done had the PCC made multiple requests, and the PCE may devolve some computations to other PCEs if it chooses. On the other hand, the PCE is not prohibited from performing all computations together in a synchronized manner as described below.
代替的に、PCCを計算するための経路のセットを求めるPCEへの単一の要求を送信するが、非同期経路計算が許容可能であることを指定してもよいです。 PCEは、PCCが複数の要求を作って、それが選択した場合PCEが他のPCEにいくつかの計算を委譲ていた行った場合とまったく同じように順番に各パスを計算することができます。一方、PCEは、以下に記載されるように同期して一緒にすべての計算を実行することが禁止されていません。
The PCC may also issue a single request to the PCE asking for all the paths to be computed in a synchronized manner. The PCE will then perform simultaneous computation of the set of requested paths. Such synchronized computation can often provide better results.
PCCはまた、すべてのパスが同期して計算することを求めてPCEに単一の要求を発行することができます。 PCEは、要求されたパスのセットの同時計算を実行します。このような同期の計算は、多くの場合、より良い結果を提供することができます。
The involvement of more than one PCE in the computation of a series of paths is by its nature non-synchronized. However, a set of cooperating PCEs may be synchronized under the control of a single PCE. For example, a PCC may send a request to a PCE that invokes domain-specific computations by other PCEs before supplying a result to the PCC.
パスの一連の計算には、複数のPCEの関与は、その性質上、非同期です。しかし、協働のPCEの組は、単一のPCEの制御下で同期させることができます。例えば、PCCは、PCCに結果を供給する前に、他のPCEによってドメイン固有の計算を呼び出すPCEに要求を送信することができます。
It is desirable to add a parameter to the PCC-PCE protocol to request that the PCE supply a set of alternate paths for use by the PCC, should the establishment of the TE LSP using the principal path fail to complete. While alternate paths may not always be successful if the first path fails, including alternate paths in a PCE response could have less overhead than having the PCC make separate requests for subsequent path computations as the need arises. This technique is used in some existing CSPF implementations.
PCE供給PCCによる使用のために代替パスのセットは、主要経路を使用してTE LSPの確立が完了するのに失敗することを要求するPCC-PCEプロトコルにパラメータを追加することが望ましいです。最初のパスが必要に応じてPCCは、後続のパス計算のための別個の要求を行う有するよりも少ないオーバーヘッドを有することができるPCE応答の代替パスを含めて、失敗した場合に代替パスが常に成功しないかもしれないが。この手法は、いくつかの既存のCSPFの実装に使用されています。
In order that a PCC can communicate efficiently with a PCE, it must know the location of the PCE. That is, it is an architectural decision made here that PCC requests be targeted to a specific PCE, and not broadcast to the network for any PCE to respond. This decision means that only the selected PCE will operate on any single request, and it saves network resources during request propagation and processing resources at the PCEs that are not required to respond.
PCCは、PCEと効率的に通信できるようにするためには、PCEの位置を知らなければなりません。つまり、PCC要求が特定のPCEを対象とし、対応するすべてのPCEのためのネットワークにブロードキャストしないことが、ここで作られた建築の決定である、です。この決定は、選択PCEが、任意の単一の要求に応じて動作することを意味し、それが応答する必要はありませんのPCEでリクエストの伝播と処理リソースの間にネットワークリソースを節約できます。
The knowledge of the location of a PCE may be achieved through local configuration at the PCC or may rely on a protocol-based discovery mechanism that may be governed by policy.
PCEの位置の知識は、PCCでローカル設定を介して達成され得るか、またはポリシーによって管理することができるプロトコルベースの発見メカニズムに依存してもよいです。
Where more than one PCE is known to a PCC, the PCC must have sufficient information to select an appropriate PCE for its purposes, under the control of policy. Such a selection procedure allows for load sharing between PCEs and supports PCEs with different computation capabilities including different visibility scopes. Thus, the information available to the PCC must include details of the PCE capabilities, which may be fixed or may vary dynamically in time.
複数のPCEがPCCに知られている場合は、PCCは、ポリシーの制御下で、その目的のために適切なPCEを選択するのに十分な情報を持っている必要があります。そのような選択手順は、のPCEの間で負荷分散を可能にし、異なる視認スコープを含む異なる計算機能を持つのPCEをサポートします。したがって、PCCに利用可能な情報は、固定されてもよいし、時間的に動的に変化してもよいPCEの機能の詳細を含まなければなりません。
The PCC may learn PCE capabilities through static configuration, or it may discover the information dynamically. Note that even when the location of the PCE is configured at the PCC, the PCC may still discover the PCE capabilities dynamically. Dynamic PCE capabilities cannot be configured and can only be discovered.
PCCは、静的な構成を通してPCE機能を学習すること、またはそれは情報を動的に発見することがあります。 PCEの位置はPCCで構成されている場合でも、PCCは依然として動的PCE能力を発見することができることに留意されたいです。ダイナミックなPCE機能を設定することはできませんとだけ発見することができます。
Proxy PCE advertisement whereby the existence of a PCE is advertised via a proxy PCE is a viable alternative, should the PCE be incapable of such advertisement itself. In this case, it is a requirement that the proxy adequately advertise the PCE status and capability in a timely and synchronized fashion.
PCEの存在は、プロキシを経由してPCE公示させるプロキシPCE広告は、PCEが、そのような広告自体が不可能である必要があり、現実的な選択肢です。この場合、プロキシが適切にタイムリーと同期してPCEの状態と機能をアドバタイズ要件です。
In the event that multiple PCEs are available to serve a particular path computation request, the PCC must select a PCE to satisfy the request. The details of such a selection (for instance, to efficiently share the computation load across multiple PCEs or to request secondary computations after partial or failed computations) are local to the PCC, may be based on policy, and are out of the scope of this document.
複数のPCEが、特定の経路計算要求にサービスを提供するために利用可能である場合には、PCCは、要求を満たすためにPCEを選択しなければなりません。このような選択の詳細は、PCCにローカルなポリシーに基づいてもよく、この範囲外である（例えば、効率的に複数のPCEを横切って計算負荷を共有する、または部分的または失敗した演算後の二次計算を要求します）資料。
PCE capabilities that may be advertised or configured could include (and are not be limited to):
アドバタイズまたは構成することができるPCE機能は含むことができる（とに限定されません）。
- a set of constraints that it can account for (diversity, shared risk link groups (SRLGs), optical impairments, wavelength continuity, etc.)
- それは（等多様性、共有リスク・リンク・グループ（SRLGs）、光障害、波長連続性）を考慮することができる制約のセット
- computational capacity (for example, the number of computations it can perform per second)
- 計算能力（例えば、それは毎秒実行できる演算の数）
- the number of switching capability layers (and which ones)
- 機能層を切り替える（およびもの）の数
- the number of path selection criteria (and which ones)
- 経路選択基準（およびもの）の数
- whether it is a stateless PCE or it can send updates about better paths that might be available in the future
- それはステートレスPCEであるか、それが将来的に利用可能であるかもしれない、より良いパスに関する更新情報を送信できるかどうか
- whether it can compute P2MP trees (and which types)
- それはP2MPツリーを計算することができるかどうか（およびどのタイプ）
- whether it can ensure resource sharing between backup tunnels
- それは、バックアップトンネル間のリソース共有を確保することができるかどうか
This information would help a PCC to decide which PCE to use.
この情報は、使用するPCEを決定するPCCが役立つだろう。
Requirements for PCE advertisement will be documented separately. Note that there is no restriction within the architecture about how location and capabilities are advertised, and the two elements should be considered functionally distinct.
PCE広告のための要件は、別途記載されます。位置及び機能がアドバタイズされ、2つの要素が機能的に異なるとみなされるべきである方法に関するアーキテクチャ内の制限がないことに留意されたいです。
A PCC might also ask a PCE to perform a particular type of service without knowledge of the PCE's capabilities and receive a response that says that the PCE is unable to perform the service. The response could specify the capabilities of the PCE and might also suggest another PCE that has the requested capabilities.
PCCはまた、PCEの能力の知識がなくても特定のタイプのサービスを実行し、PCEがサービスを行うことができないと言うの応答を受け取るためにPCEを頼むかもしれません。応答は、PCEの機能を指定でき、また、要求された機能を持つ別のPCEを示唆するかもしれません。
The ability to detect a PCE's liveness is a mandatory piece of the overall architecture and could be achieved by several means. If some form of regular advertisement (such as through IGP extensions) is used for PCE discovery, it is expected that the PCE liveness will be determined by means of status advertisement (for example, IGP LSA/LSPs).
PCEの生存性を検出する能力は、全体的なアーキテクチャの必須部分であり、いくつかの手段によって達成することができました。定期的な広告（例えばIGP拡張を介してなど）のいくつかのフォームは、PCE発見のために使用されている場合には、PCEのライブネスステータス広告の手段によって決定されることが期待される（例えば、IGP LSA /のLSP）。
The inability of a PCE to service a request (perhaps due to excessive load) may be reported to the PCC through a failure message, but the failure of a PCE or the communications mechanism while processing a request cannot be reported in this way. Furthermore, in the case of excessive load, the PCE may not have sufficient resources to send a failure message. Thus, the PCC should employ other mechanisms, such as protocol timers, to determine the liveness of the PCE. This is particularly important in the case of inter-domain path computation where the PCE liveness may not be detected by means of the IGP that runs in the PCC's domain.
（おそらく過負荷に）要求をサービスするPCEのできないことは、障害メッセージを介してPCCに報告することができるが、PCEの故障または通信機構要求を処理している間は、この方法で報告することができません。また、過負荷の場合には、PCEは、障害メッセージを送信するために十分なリソースを有していてもよいです。したがって、PCCは、PCEの生存性を決定するために、そのようなプロトコルタイマーのような他のメカニズムを採用すべきです。これは、PCEのライブネスはPCCのドメインで実行さIGPによって検出されない場合があり、ドメイン間経路計算の場合に特に重要です。
Once the PCC has selected a PCE, and provided that the PCE is not local to the PCC, a request/response protocol is required for the PCC to communicate the path computation requests to the PCE and for the PCE to return the path computation response. Discussion of the security requirements and implications for this protocol is provided in Section 10 of this document.
PCCは、PCEを選択し、PCEは、PCCに対してローカルではないことを提供した後、要求/応答プロトコルは、PCEおよびPCEは、経路計算応答を返すための経路計算リクエストを通信するPCCのために必要とされます。このプロトコルのためのセキュリティ要件と意味についての議論は、このドキュメントのセクション10に設けられています。
The path computation request may include a significant set of requirements, including the following:
経路計算要求は、次のような要件の有意なセットを含むことができます。
- the source and destination of the path
- パスのソースとデスティネーション
- the bandwidth and other Quality of Service (QoS) parameters desired
- 帯域幅やサービスの他の品質（QoS）パラメータを希望
- resources, resource affinities, and shared risk link groups (SRLGs) to use/avoid
- /回避を使用するには、リソース、リソースの親和性、および共有リスクリンクグループ（SRLGs）
- the number of disjoint paths required and whether near-disjoint paths are acceptable
- ばらばらパスの数必要と近互いに素なパスかどうかが許容されます
- the levels of resiliency, reliability, and robustness of the path resources
- パス・リソースの弾力性、信頼性、及び堅牢性のレベル
- policy-related information
- ポリシー関連情報
The level of robustness of the path resources covers a qualitative assessment of the vulnerability of the resources that may be used. For example, one might grade resources based on empirical evidence (mean time between failures), on known risks (there is major building work going on near this conduit), or on prejudice (vendor X's software is always crashing). A PCC could request that only robust resources be used, or it could allow any resource.
パスリソースのロバスト性のレベルを使用することができるリソースの脆弱性の定性的評価をカバーします。例えば、経験的証拠（平均故障間隔）に基づくものかもしれないグレードのリソース、既知のリスクに、または偏見に（ベンダーがXのソフトウェアは常にクラッシュした）（主要な建物、この管路の近くで起こって仕事があります）。 PCCは、唯一の強力なリソースを使用することを要求することができる、またはそれは、任意のリソースを可能性があります。
In case of a positive response from the PCE, one or more paths would be returned to the requesting node. In the event of a failure to compute the desired path(s), an error is returned together with as much information as possible about the reasons for the failure(s), and potentially with advice about which constraints might be relaxed so that a positive result is more likely in a future request.
PCEからの肯定応答の場合には、1つ以上のパスが要求ノードに戻されることになります。所望の経路（単数または複数）を計算するために障害が発生した場合に、エラーが故障（S）理由についてできるだけ多くの情報と一緒に戻され、潜在的に正のような制約が緩和される可能性があるかについてのアドバイスされます結果は、将来の要求に可能性が高いです。
Note that the resultant path(s) may be made up of a set of strict or loose hops, or any combination of strict and loose hops. Moreover, a hop may have the form of a non-explicit abstract node.
得られたパス（複数可）は、厳密な又はゆるいホップのセット、または厳密とゆるいホップの任意の組み合わせで構成されてもよいことに留意されたいです。また、ホップは、非明示的な抽象ノードの形態を有していてもよいです。
A request/response protocol is also required for a PCE to communicate path computation requests to another PCE and for the PCE to return the path computation response. The path computation request may include a significant set of requirements including those defined above. In case of a positive response from the PCE, one or more paths would be returned to the requesting PCE. In the event of a failure to compute the desired path(s), an error is returned together with as much information as possible about the reasons for the failure, and potentially advice about which constraints might be relaxed so that a positive result is more likely. Note that the resultant path(s) may be made up of a set of strict or loose hops, or any combination of strict and loose hops. Moreover, a hop may have the form of a non-explicit abstract node.
要求/応答プロトコルは、他のPCEおよびPCEは、経路計算応答を返すための経路計算リクエストを通信するPCEのために必要とされます。経路計算要求は、上記で定義されたものを含む要件の有意な組を含むことができます。 PCEからの肯定応答の場合には、1つ以上のパスは、要求PCEに返されます。所望の経路（複数可）を計算する障害が発生した場合、エラーが失敗の理由についてできるだけ多くの情報と一緒に返され、陽性の結果がより可能性があるように、潜在的なアドバイス制約が緩和されるかもしれませんかについて。得られたパス（複数可）は、厳密な又はゆるいホップのセット、または厳密とゆるいホップの任意の組み合わせで構成されてもよいことに留意されたいです。また、ホップは、非明示的な抽象ノードの形態を有していてもよいです。
An important feature of PCEs that are cooperating to compute a path is that they apply compatible or identical computation algorithms and coordinated policies. This may require coordination through the communication between the PCEs.
パスを計算するために協力しているのPCEの重要な特徴は、彼らが互換性または同一の計算アルゴリズムと協調政策を適用することです。これは、のPCE間の通信を介して調整を必要とするかもしれません。
Note that when multiple PCEs cooperate to compute a path, it is important that they have a coordinated view of the meaning of constraints such as costs, resource affinities, and class of service. This is particularly significant where the PCEs are responsible for different domains. It is assumed that this is a matter of policy between domains and between PCEs.
複数のPCEは、パスを計算するために協力したときに、彼らが、そのようなコスト、リソースの親和性、およびサービスのクラスなどの制約の意味の協調ビューを持つことが重要であることに注意してください。 PCEは異なるドメインに責任がある場合に特に重要です。ドメイン間でのPCE間の政策の問題であると仮定されます。
No assumption is made in this architecture about whether the PCC-PCE and PCE-PCE communication protocols are identical.
何の仮定はPCC-PCEとPCE-PCE通信プロトコルが同一であるかどうかについては、このアーキテクチャでは行われません。
As previously described, the PCE operates on a TED. Information on network status to build the TED may be provided in the domain by various means:
前述のように、PCEはTEDで動作します。 TEDを構築するためのネットワークの状態に関する情報は、様々な手段によってドメインで提供することができます。
1) Participation in IGP distribution of TE information. The standard method of distribution of TE information within an IGP area is through the use of extensions to the IGP [RFC3630, RFC3748]. This mechanism allows participating nodes to build a TED, and this is the standard technique, for example, within a single area MPLS or GMPLS network. A node that hosts the PCE function may collect TE information in this way by maintaining at least one routing adjacency with a router in the domain. The PCE node may be adjacent or non-adjacent (via some tunneling techniques) to the router. Such a technique provides a mechanism for ensuring that the TED is efficiently synchronized with the network state and is the normal case, for example, when the PCE is co-resident with the LSRs in an MPLS or GMPLS network.
TE情報のIGP分布1）参加。 IGP領域内のTE情報の分布の標準的な方法は、IGP [RFC3630、RFC3748]の拡張機能を使用することです。このメカニズムは、TEDを構築するためにノードを参加でき、これは、単一の領域MPLS又はGMPLSネットワーク内の例えば標準技術です。 PCEの機能をホストするノードは、ドメイン内のルータと少なくとも一つのルーティング隣接関係を維持することによって、このようにTEの情報を収集することができます。 PCEノードは、ルータに（いくつかのトンネリング技術を介して）隣接または非隣接であってもよいです。そのような技術は、TEDを効率的にネットワークの状態と同期してPCEは、MPLS又はGMPLSネットワーク内のLSRとの共存である場合、例えば、通常のケースであることを保証するためのメカニズムを提供します。
2) Out-of-band TED synchronization. It may not be convenient or possible for a PCE to participate in the IGPs of one or more domains (for example, when there are very many domains, when IGP participation is not desired, or when some domains are not running TE-aware IGPs). In this case, some mechanism may need to be defined to allow the PCE node to retrieve the TED from each domain. Such a mechanism could be incremental (like the IGP in the previous case), or it could involve a bulk transfer of the complete TED. The latter might significantly limit the capability to ensure TED synchronization, which might result in an increase in the failure rate of computed paths, or the computation of sub-optimal paths. Consideration should also be given to the impact of the TED distribution on the network and on the network node within the domain that is asked to distribute the database. This is particularly relevant in the case of frequent network state changes.
2）アウトオブバンドTED同期。 PCEは、1つ以上のドメインのIGPに参加することが好都合であるかまたは可能でないかもしれない（例えば、IGPの参加が望まれていない、またはいくつかのドメインはTE対応のIGPを実行していないときに、非常に多くのドメインが存在する場合） 。この場合には、いくつかのメカニズムがPCEノードが各ドメインのTEDを取得できるように定義される必要があるかもしれません。そのような機構は、（前のケースでIGPように）増分することができ、またはそれは完全なTEDのバルク転送を伴う可能性があります。後者は、大幅に計算パスの故障率、またはサブ最適経路の計算の増加をもたらす可能性がTEDの同期を確実にする能力を制限するかもしれません。考慮すべきことは、ネットワーク上で、データベースを配布するように依頼されたドメイン内のネットワークノード上のTED分布の影響を考慮すべきです。これは、頻繁にネットワークの状態が変化した場合に特に関連します。
3) Information in the TED can include information obtained from sources other than the IGP. For example, information about link usage policies can be configured by the operator. Path computation can also act on a far wider set of information that includes data about the TE LSPs provisioned within the network. This information can include TE LSP routes, reserved bandwidth, and measured traffic volume passing through the TE LSP.
3）TEDの情報は、IGP以外のソースから得られた情報を含むことができます。例えば、リンクの使用ポリシーについての情報は、オペレータによって設定することができます。経路計算は、ネットワーク内でプロビジョニングTEのLSPのに関するデータを含む情報のはるかに広いセットに作用することができます。この情報は、TE LSPの経路、予約帯域を含み、TE LSPを通過するトラフィック量を測定することができます。
Such TE LSP information can enhance TE LSP (re)optimization to provide "full network" (re)optimization and can allow traffic fluctuations to be taken into account. Detailed TE LSP information may also facilitate reconfiguration of the Virtual Network Topology (VNT) [MLN], in which lower-layer TE LSPs, such as optical paths, provide TE links for use by the higher layer, since this reconfiguration is also a "full network" problem.
このようなTE LSP情報は、「完全なネットワーク」（再）最適化を提供するために、TE LSP（再）最適化を向上させることができ、トラフィックの変動を考慮に入れることができるようにすることができます。この再構成」もあるので、詳細なTE LSP情報はまた、下層TEのLSPは、そのような光路として、上位層によって使用するためのTEリンクを提供する仮想ネットワークトポロジ（VNT）[MLN]の再構成を容易にすることができます完全なネットワーク」の問題。
Note that synchronization techniques may apply to both intra- and inter-domain TEDs. Furthermore, the techniques can be mixed for use in different domains. The degree of synchronization between the PCE and the network is subject to implementation and/or policy. However, better synchronization generally leads to paths that are more likely to succeed.
その同期技術は、細胞内およびドメイン間TEDSの両方に適用される場合があります注意してください。さらに、技術は、異なるドメインで使用するために混合することができます。 PCEとネットワーク間の同期の程度は、実装及び/又はポリシーの対象となります。しかし、より良い同期は、一般的に成功する可能性が高いパスにつながります。
Note also that the PCE may have access to only a partial TED: for instance, in the case of inter-domain path computation where each such domain may be managed by different entities. In such cases, each PCE may have access to a partial TED, and cooperative techniques between PCEs may be used to achieve end-to-end path computation without any requirement that any PCE handle the complete TED related to the set of traversed domains by the TE LSP in question.
例えば、ドメイン間経路計算の場合には、このような各ドメインが異なるエンティティによって管理することができる場合：PCEは部分的にしかTEDへのアクセスを有していてもよいことにも留意されたいです。このような場合には、各PCEは、部分TEDへのアクセスを有していてもよい、とのPCEの間の協調的な技術は、任意のPCEにより横断ドメインのセットに関連する完全なTEDを扱う任意の必要なしに、エンドツーエンド経路計算を達成するために使用することができます問題のTE LSP。
A PCE can be either stateful or stateless. In the former case, there is a strict synchronization between the PCE and not only the network states (in term of topology and resource information), but also the set of computed paths and reserved resources in use in the network. In other words, the PCE utilizes information from the TED as well as information about existing paths (for example, TE LSPs) in the network when processing new requests. Note that although this allows for optimal path computation and increased path computation success, stateful PCEs require reliable state synchronization mechanisms, with potentially significant control plane overhead and the maintenance of a large amount of data/states (for example, full mesh of TE LSPs).
PCEは、ステートフルまたはステートレスのいずれかになります。前者の場合、ネットワークで使用されているPCEだけでなく、ネットワークの状態（トポロジーおよびリソース情報の用語で）だけでなく、計算されたパスのセットと予約されたリソースとの間の厳密な同期があります。新しい要求を処理するとき換言すれば、PCEは、ネットワーク内でTEDからの情報だけでなく、既存のパスに関する情報（例えば、TE LSPを）を利用します。これは、最適経路計算と増加経路計算の成功を可能にするが、ステートフルのPCEは、潜在的に重要な制御オーバヘッドプレーン及びデータ/状態の大量の維持と、信頼性の高い状態の同期メカニズムを必要とすることに注意してください（例えば、TE LSPのフルメッシュ） 。
For example, if there is only one PCE in the domain, all TE LSP computation is done by this PCE, which can then track all the existing TE LSPs and stay synchronized (each TE LSP state change must be tracked by the PCE). However, this model could require substantial control plane resources. If there are multiple PCEs in the network, TE LSP computation and information are distributed among PCEs and so the resources required to perform the computations are also distributed. However, synchronization issues discussed in Section 6.7 also come into play.
唯一のPCEは、ドメイン内に存在する場合、例えば、全てのTE LSP計算は、すべての既存のTE LSPを追跡し（各TE LSPの状態の変化は、PCEによって追跡されなければならない）同期を維持することができ、このPCEによって行われます。しかし、このモデルはかなりのコントロールプレーンのリソースを必要とする可能性があります。ネットワーク内の複数のPCEが存在する場合、TE LSP計算情報は、のPCE間で分散され、計算を実行するために必要なので、リソースは、分散されています。しかし、6.7節で説明した同期の問題も遊びに来ます。
The maintenance of a stateful database can be non-trivial. However, in a single centralized PCE environment, a stateful PCE is almost a simple matter of remembering all the TE LSPs the PCE has computed, that the TE LSPs were actually set up (if this can be known), and when they were torn down. Out-of-band TED synchronization can also be complex, with multiple PCE setup in a distributed PCE computation model, and could be prone to race conditions, scalability concerns, etc. Even if the PCE has detailed information on all paths, priorities, and layers, taking such information into account for path computation could be highly complex. PCEs might synchronize state by communicating with each other, but when TE LSPs are set up using distributed computation performed among several PCEs, the problems of synchronization and race condition avoidance become larger and more complex.
ステートフルデータベースのメンテナンスは非自明なことができます。しかし、単一の集中PCE環境では、ステートフルPCEはほとんどPCE（これは知ることができる場合）のTEのLSPが実際に設定されたことを、計算した、と彼らは取り壊されたときにすべてのTE LSPを覚えるのは簡単なことです。アウトオブバンドTED同期はまた、分散型PCEの計算モデルで複数のPCEのセットアップで、複雑になる可能性があり、PCEは上の詳細な情報を持っている場合でも条件等、拡張性の懸念を、レースになりやすいかもしれないすべてのパス、優先順位、および層は、経路計算のための口座にそのような情報を取ることは非常に複雑である可能性があります。 PCEは、互いに通信することにより、状態を同期させるかもしれないが、TEのLSPは、いくつかのPCEの間で行わ分散計算を使用して設定されている場合、同期と競合状態回避の問題はより大きく、より複雑になります。
There is benefit in knowing which TE LSPs exist, and their routing, to support such applications as placing a high-priority TE LSP in a crowded network such that it preempts as few other TE LSPs as possible (also known as the "minimal perturbation" problem). Note that preempting based on the minimum number of links might not result in the smallest number of TE LSPs being disrupted. Another application concerns the construction and maintenance of a Virtual Network Topology [MLN]. It is also helpful to understand which other TE LSPs exist in the network in order to decide how to manage the forward adjacencies that exist or need to be set up. The cost-benefit of stateful PCE computation would be helpful to determine if the benefit in path computation is sufficient to offset the additional drain on the network and computational resources.
TEのLSPが存在知ることで利益、およびそれらのルーティングは、「最小の摂動」として知られ、それは可能な限り少ない他のTEのLSPとして先取りするような混雑したネットワーク（高優先度TE LSPを配置するようなアプリケーションをサポートするために、あります問題）。 TEのLSPが中断されるの最小数にはならないかもしれないリンクの最小数に基づいて、プリエンプトことに注意してください。別のアプリケーションが仮想ネットワークトポロジ[MLN]の建設と維持管理に関するものです。存在しないか設定する必要があり、前方の隣接関係をどのように管理するかを決定するために、ネットワーク内に存在する他のどのTE LSPを理解することも有用です。経路計算における利点は、ネットワークおよび計算リソースの追加ドレインを相殺するのに十分である場合、ステートフルPCEの計算の費用対効果を判断するために役立つであろう。
Conversely, stateless PCEs do not have to remember any computed path and each set of request(s) is processed independently of each other. For example, stateless PCEs may compute paths based on current TED information, which could be out of sync with actual network state given other recent PCE-computed paths changes. Note that a PCC may include a set of previously computed paths in its request, in order to take them into account, for instance, to avoid double bandwidth accounting or to try to minimize changes (minimum perturbation problem).
逆に、ステートレスのPCEは、任意の計算された経路を覚えておく必要はなく、要求（単数または複数）の各セットは、互いに独立して処理されます。例えば、ステートレスのPCEは、実際のネットワーク状態所定の他の最近のPCE計算経路の変更に同期してかもしれない現在のTED情報に基づいて経路を計算することができます。 PCCはそのリクエストで以前に計算経路の集合を含むことができ、それらを考慮するためには、例えば、二重の帯域幅課金を避けるために、または変更（最小摂動問題）を最小化しようとすることに注意してください。
Note that the stateless PCE does operate on information about network state. The TED contains link state and bandwidth availability information as distributed by the IGPs or collected through some other means. This information could be further enhanced to provide increased granularity and more detail to cover, for example, the current bandwidth usage on certain links according to resource affinities or forwarding equivalence classes. Such information is, however, not PCE state information and so a model that uses it is still described as stateless in the PCE context.
ステートレスPCEは、ネットワークの状態に関する情報を操作ありません。 IGPによって配布またはいくつかの他の手段を介して収集するようにTEDは、リンク状態と帯域幅の可用性情報を含みます。この情報はさらに増加粒度と、例えば、特定のリンクのリソース親和性に応じて、または等価クラスの転送に現在の帯域幅使用量をカバーするために詳細を提供するように拡張することができます。そのような情報には、しかし、ないPCE状態情報及びそれを使用するモデルが依然としてPCEコンテキストでステートレスとして記載されています。
A limited form of statefulness might be applied within an otherwise stateless PCE. The PCE may retain some context from paths it has recently computed so that it avoids suggesting the use of the same resources for other TE LSPs.
ステートフルの限定された形は、そうでなければ、ステートレスPCE内で適用されるかもしれません。 PCEは、他のTEのLSPのために同じリソースを使用することを示唆している避けるように、それは最近計算した経路からのいくつかのコンテキストを保持することができます。
PCE monitoring is undoubtedly of the utmost importance in any PCE architecture. This must include the collection of variables related to the PCE status and operation. For example, it will be necessary to understand the way in which the TED is being kept synchronized, the rate of arrival of new requests and the computation times, the range of PCCs that are using the PCE, and the operation of any PCC-PCE protocol.
PCEの監視は間違いなくすべてのPCEアーキテクチャの最も重要です。これは、PCEの状態と操作に関連する変数のコレクションを含める必要があります。例えば、TEDが同期保持されているようにして、新たな要求と計算時間の到着の速度、PCEを使用しているのPCCの範囲、および任意のPCC-PCEの動作を理解するのに必要であろうプロトコル。
As stated in [RFC4216], the case of inter-provider TE LSP computation requires the ability to compute a path while preserving confidentiality across multiple Service Providers cores. That is, one Service Provider must not be required to divulge any information about its resources or topology in order to support inter-provider TE LSP path computation. Thus, any PCE architecture solution must support the ability to return partial paths by means of loose hops (for example, where each loose hop would, for instance, identify a boundary LSR).
[RFC4216]に記載されているように、インタープロバイダTE LSP計算の場合は、複数のサービスプロバイダのコア間機密性を維持しながら、経路を計算する能力を必要とします。これは、1つのサービスプロバイダは、インタープロバイダTE LSPの経路計算をサポートするために、そのリソースまたはトポロジに関する情報を漏らすする必要はない必要があります。したがって、任意のPCEアーキテクチャ溶液（例えば、ここで、各ルースホップは、例えば、境界LSRを識別することになる）ルーズホップによって部分的パスを返す機能をサポートしなければなりません。
This requirement is not a security issue, but relates to Service Provider policy. Confidentiality, integrity, and authentication of PCC-PCE and PCE-PCE messages must also be ensured and are described in Section 10.
この要件は、セキュリティ上の問題ではなく、サービスプロバイダーのポリシーに関するものです。 PCC-PCEとPCE-PCEメッセージの機密性、完全性、および認証も保証されなければならないと、セクション10に記載されています。
The ability to compute a path at the request of the head-end PCC, but to supply the path in segments to the domain boundary PCCs, may also be desirable.
、ヘッドエンドPCCの要求に応じてパスを計算するが、ドメイン境界のPCCへのセグメントのパスを供給する能力も望ましいかもしれません。
Policy impacts multiple aspects of the PCE architecture. There are two applications of policy for consideration:
PCEアーキテクチャの政策に影響を与える複数の側面。検討のための政策の2つのアプリケーションがあります。
- application of policy within an architectural entity (PCC or PCE)
- 建築エンティティ（PCC又はPCE）内のポリシーの適用
- application of policy to PCE-related communications
- PCE関連の通信にポリシーを適用します
As directly applicable to TE LSPs, policy forms part of the signaling mechanism for the establishment of the TE LSPs and is not described here.
TE LSPを、TE LSPの確立のためのシグナリング機構のポリシー一部を形成するまでとして直接適用し、ここでは説明しません。
It is envisioned that policy will be largely applied as a local matter within each PCC and PCE. However, this document needs to define policy models that can be supported within the PCE architecture and by PCE-related communication.
政策が大きく、各PCCとPCE内のローカル問題として適用されることが想定されます。しかし、この文書は、PCEアーキテクチャ内及びPCE関連の通信がサポートできるポリシーモデルを定義する必要があります。
Some example policies include:
いくつかの例ポリシーは、次のとおりです。
- selection of a PCE by a PCC
- PCCによるPCEの選択
- rejection of a request by the PCE based on the identity of the requesting PCC
- PCEによって要求の拒否要求するPCCのアイデンティティに基づいて
- selection by the PCE of a path or application of additional constraints to a computation based on the PCC, the computation target, the time of day, etc.
- 等PCC、演算対象、一日の時間に基づいて計算する追加の制約のパスまたはアプリケーションのPCEによる選択
Two examples of the use of policy components within the PCE architecture are illustrated in Figures 6 and 7. Policy components could equally be applied to the other PCE configurations shown in Section 5. In each configuration, policy may be consulted before a response is provided by a PCE and may also be consulted by the PCC/PCE that receives the response.
応答は、によって提供される前に、PCEアーキテクチャ内のポリシーコンポーネントの使用の2つの例が図6に示されており、7ポリシーコンポーネントが等しく、各構成ではセクション5に示す他のPCEの構成に適用することができ、ポリシーを参照することができますPCEとも応答を受信したPCC / PCEによって参照することができます。
A PCE may have a local policy that impacts the paths selected to satisfy a particular PCE request. A policy may be applied based on any information provided from a PCC.
PCEは、経路が特定のPCE要求を満たすように選択影響ローカルポリシーを有していてもよいです。ポリシーは、PCCから提供された情報に基づいて適用されてもよいです。
In Figure 6, the policy component is shown providing input to the PCE component. This policy component may consult an external policy database, but this is outside the scope of this document.
図6に、ポリシーコンポーネントは、PCEコンポーネントに入力を提供示されています。このポリシーコンポーネントは、外部ポリシーデータベースを調べることができるが、これはこの文書の範囲外です。
------------------------------
| --------- | Routing ----------
| | | | Protocol | |
| | TED |<-+----------+-> |
| | | | | |
| --------- | | |
| | | | |
| | Input | | |
| v | | |
| --------- --------- | | |
| | Policy | | | | | Adjacent |
| |Component|--->| PCE | | | Node |
| | | | | | | |
| --------- --------- | | |
| ^ | | |
| |Request | | |
| |Response| | |
| v | | |
| --------- | | |
Service | | | | Signaling| |
Request | |Signaling| | Protocol | |
------+---------------->| Engine |<-+----------+-> |
| | | | | |
| --------- | ----------
------------------------------
Figure 6. Policy Component in the Composite PCE Node
コンポジットPCEノード図6.ポリシーコンポーネント
Note that policy information may be conveyed on the internal interfaces, and on the external protocol interfaces.
ポリシー情報は、内部インターフェイス上で、外部プロトコルインターフェイス上を搬送されてもよいことに留意されたいです。
Figure 7 displays the case of a distinct PCE function through the example of the multiple PCE with inter-PCE communication example (compare with Figure 4). Each PCE takes input from local policy as part of the router computation/determination process. The local policy components may consult external policy components or databases, but that is out of the scope of this document.
図7は、（図4と比較）間PCE通信例を有する複数のPCEの例を通して異なるPCE関数の場合を表示します。各PCEは、ルータ演算/決意プロセスの一部として、ローカルポリシーから入力をとります。ローカルポリシーコンポーネントは、外部ポリシーコンポーネントやデータベースを協議することができるが、それはこの文書の範囲外です。
Note that policy information may be conveyed on the external protocol interfaces, including the inter-PCE interface.
ポリシー情報がインターPCEインターフェースを含む外部プロトコルインタフェース、上を搬送されてもよいことに留意されたいです。
------------------ ------------------
| | Inter-PCE Request/Response| |
| PCE |<------------------------->| PCE |
| | | |
| ------ ----- | | ------ ----- |
| |Policy| | TED | | | |Policy| | TED | |
| ------ ----- | | ------ ----- |
------------------ ------------------
^
| Request/
| Response
v
Service ---------- Signaling ---------- Signaling ----------
Request| Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ----------
Figure 7. Policy Components in Multiple PCEs
複数のPCE図7.ポリシーコンポーネント
There are multiple options for how policy information is coordinated.
ポリシー情報が配位している方法のための複数のオプションがあります。
- Policy decisions may be made by PCCs before consulting PCEs. This type of decision includes selection of PCE, application of constraints, and interpretation of service requests.
- 政策決定はのPCEに相談する前のPCCによって行うことができます。意思決定のこのタイプは、PCEの選択、制約のアプリケーション、およびサービス要求の解釈が含まれています。
- Policy decisions may be made independently at a PCE, or at each cooperating PCE. That is, the PCE(s) may make policy decisions independent of other policy decisions made at PCCs or other PCEs.
- 政策決定はPCEで、または各協力PCEで独立して行うことができます。つまり、PCE（複数可）のPCCまたは他のPCEで行われた他の政策決定の方針の決定が独立して行うことができます。
- There may also be explicit communication of policy information between PCC and PCE, or between PCEs to achieve some level of coordination of policy between entities. The type of information conveyed to support policy has important implications on what policies may be applied at each PCE, and the requirements for the exchange of policy information inform the choice or implementation of communication protocols including PCC-PCE, PCE-PCE, and discovery protocols.
- また、PCCとPCEの間、またはエンティティ間の政策の調整のいくつかのレベルを達成するためのPCE間のポリシー情報の明示的な通信があるかもしれません。情報の種類は、ポリシーをサポートするために搬送されるPCEに適用され、ポリシー情報を交換するための要件はPCC-PCE、PCE-PCE、および発見プロトコルを含む通信プロトコルの選択や実施を知らせることができるものを政策上重要な意味を持っています。
Within the context of PCE, we identify several types of policies:
PCEの文脈の中で、我々は政策のいくつかのタイプを識別します。
o User-specific policies operate on information that is specific to the user of a service or the service itself, that is, the service for which the path is being computed, not the computation service. Examples of such information includes the contents of objects of a signaling or provisioning message, the port ID over which the message was received, a VPN ID, a reference point type, or the identity of the user initiating the request. User-specific policies could be applied by a PCC while building a path computation request, or by a PCE while processing the request provided that sufficient information is supplied by the PCC to the PCE.
Oユーザー固有のポリシーは、それは、経路が計算されているサービスではなく、計算サービスであり、サービスまたはサービス自体のユーザに固有の情報で動作します。そのような情報の例には、シグナリングまたはプロビジョニングメッセージのオブジェクトの内容を含む、メッセージを受信した上ポートID、VPN ID、基準点タイプ、または要求を開始するユーザのID。要求の処理中にユーザー固有のポリシーは、経路計算要求を構築しながら、又はPCEによってPCCによって適用することができる十分な情報をPCEにPCCによって供給されることを条件とします。
o Request-specific policies operate on information that is specific to a path computation request and is carried in the request. Examples of such information include constraints, diversities, constraint and diversity relaxation strategies, and optimization functions. Request-specific policies directly affect the path selection process because they specify which links, nodes, path segments, and/or paths are not acceptable or, on the contrary, may be desirable in the resulting paths.
O要求固有のポリシーは、経路計算要求に固有のリクエストで搬送される情報で動作します。そのような情報の例としては、制約、多様性、制約および多様性緩和戦略、および最適化機能が含まれています。それらは許容されない、または、逆に、得られた経路に望ましい場合があるリンク、ノード、パスセグメント、および/または経路指定するため、要求固有のポリシーは、直接経路選択プロセスに影響を与えます。
o Domain-specific policies operate on the identify of the domain in which the requesting PCC exists, and upon the identities of the domains through which the resulting paths are routed. These policies have the same effect as user-specific policies, with the difference that they can be applied to a group of users rather than an individual user. One example of domain-specific policy is a restriction on what information a PCE publishes within a given domain. In such a case, PCEs in some domains may advertise just their presence, while others may advertise details regarding their capabilities, client authentication process, and computation resource availability.
Oドメイン固有のポリシーは、要求PCCが存在するドメインの識別に、得られたパスを送信する際に経由するドメインの識別時に動作します。これらのポリシーは、彼らは、ユーザーのグループではなく、個々のユーザーに適用することができ差異のあるユーザー固有のポリシーと同じ効果を持ちます。ドメイン固有のポリシーの一例は、PCEが与えられたドメイン内で発行してどのような情報に制限です。他の人がその機能に関する詳細は、クライアントの認証プロセス、および計算リソースの可用性を宣伝するかもしれないが、このような場合には、いくつかのドメインでのPCEは、ちょうど彼らの存在を通知します。
When a path for an inter-domain TE LSP is being computed, it is not required to consider signaling plane policy. However, failure to do so may result in the TE LSP failing to be established, or being assigned fewer resources than intended resulting in a substandard service. Thus, where a PCE invoked by a head-end LSR has visibility into other domains, it should be capable of applying policy considerations to the computation and should be aware of the inter-domain policy agreements. Where path computation is the result of cooperation between PCEs, each of which is responsible for a particular domain, the policy issues should, where possible, be resolved at the time of computation so that the TE LSP is more likely to be signaled successfully. In this context, policy violation during inter-domain TE LSP computation may lead to path computation interruption, about which the requester should be notified along with the cause.
ドメイン間TE LSPのためのパスが計算されているとき、平面ポリシーシグナリングを検討する必要はありません。しかし、そうしないと、TE LSPを確立することに失敗し、又はサブスタンダードサービスをもたらすことを意図よりも少ないリソースを割り当てられるもたらし得ます。従って、LSRが他のドメインに可視性を有するヘッドエンドによって呼び出さPCEは、それが計算にポリシーの考慮事項を適用することが可能であるべきであり、ドメイン間ポリシー契約を認識するべきです。経路計算は、PCEの間の協力の結果である場合、そのそれぞれが特定のドメインに責任があるTE LSPが正常に通知されやすくなるよう、政策課題は、可能な場合、計算の時に解決されなければなりません。この文脈では、ドメイン間TE LSPの計算中のポリシー違反は、要求者が原因と一緒に通知されるべきかについての経路計算の中断につながる可能性があります。
It may be that the PCC-PCE communications (see Section 6.6) can be usefully extended beyond a simple request/response interaction. For example, the PCE and PCC could exchange capabilities using this protocol. Additionally, the protocol could be used to collect and report information in support of a stateful PCE.
これは有用単純な要求/応答相互作用を超えて拡張することができる（6.6節を参照）PCC-PCE通信ということもできます。例えば、PCEとPCCは、このプロトコルを使用して機能を交換することができました。さらに、プロトコルは、ステートフルPCEの支援で情報を収集し、報告するために使用することができます。
Furthermore, it may be the case that a PCE is able to update a path that it computed earlier (perhaps in reaction to a change in the network or a change in policy), and in this case the PCE-PCC communication could support an "unsolicited" path computation message to supply this new path to the PCC. Note, however, that this function would require that the PCE retained a record of previous computations and had a clear trigger for performing recomputations. The PCC would also need to be able to identify the new path with the old path and determine whether it should act on the new path. Further, the PCC should be able to report the outcome of such path changes to the requesting PCE. Note that the PCE-PCC interaction is not a management interaction and the PCC is not obliged to utilize any additional path supplied by the PCE.
また、PCEは、それが（ネットワークの変更またはポリシーの変更におそらく反応において）以前計算された経路を更新することができる場合であってもよく、この場合、PCE-PCC通信をサポートすることができます " PCCにこの新しいパスを供給するために迷惑」経路計算メッセージ。この機能は、PCEが前の計算の記録を保持し、再計算を実行するための明確なトリガーを持っていたことを必要とするであろうということ、しかし、注意してください。 PCCはまた、古いパスと新しいパスを識別し、それが新しいパスに基づいて行動する必要があるかどうかを判断できるようにする必要があります。さらに、PCCは、要求PCEにそのような経路変更の結果を報告することができなければなりません。 PCE-PCC対話管理相互作用ではなく、PCCは、PCEによって供給される追加のパスを利用する義務がないことに留意されたいです。
These functions fit easily within the architecture described here but are left for further discussion within separate requirements documents.
これらの機能は、ここで説明するアーキテクチャ内で簡単に収まるが、個別の要件文書内のさらなる議論のために残されています。
Crankback routing is a mechanism whereby a failure to establish a path or a failure of an existing path may be corrected by a new path computation and fresh signaling. Crankback routing relies on the distribution of crankback information along with the failure notification so that the new computation can be performed avoiding the failure or blockage point.
クランクバックルーティングパスを確立するために失敗するか、または既存のパスの障害が新しい経路計算及び新鮮なシグナリングによって補正することができる機構です。新しい計算が故障または閉塞箇所を避けて行うことができるようにクランクバックルーティングが失敗通知と共にクランクバック情報の分布に依存しています。
In the context of PCE, crankback information may be passed back to the head-end where the process of computation and signaling can be repeated using the failed resource as an exclusion in the computation process. But crankback may be used to attempt to correct the problem at intermediate points along the path. Such crankback recomputation nodes are most likely to be domain boundaries where the PCC had already invoked a PCE. Thus, a failure within a domain is reported to the ingress domain boundary, which will attempt to compute an alternate path across the domain. Failing this, the problem may be reported to the previous domain and communicated to the ingress boundary for that domain, which may attempt to select a more successful path either by choosing a different entry point into the next domain, or by selecting a route through a different set of domains.
PCEの文脈では、クランクバック情報は、バック計算およびシグナリングの処理は演算処理において除外として失敗したリソースを使用して繰り返すことができるヘッドエンドへ渡すことができます。しかし、クランクバックは、経路に沿った中間点で問題を解決しようとするために使用することができます。このようなクランクバック再計算ノードは、PCCはすでにPCEを起動していたドメイン境界である可能性が最も高いです。したがって、ドメイン内の故障がドメイン全体代替パスを計算しようと進入ドメイン境界に報告されています。 、またはを通じて経路を選択することによって、この失敗、問題は、前のドメインに報告されてもよいし、いずれかの次のドメインに異なるエントリポイントを選択することによって、より多くの成功した経路を選択することを試みることができるそのドメインの入口境界に伝達しますドメインの異なるセット。
The view of the PCE architecture, and particularly the functional model, is subtly different from the PCC's perspective. This is partly because the PCC has limited knowledge of the way in which the PCEs cooperate to answer its requests, but depends more on the fact that the PCC is concerned with different questions.
PCEアーキテクチャの観点から、特に、機能モデルは、PCCの観点からは微妙に異なっています。これは、PCCはのPCEは、その要求に答えるために協力する方法の知識が限られている一因であるが、より多くのPCCが別の質問に関係しているという事実に依存します。
The PCC is interested in the following:
PCCは、以下に興味を持っています：
- Selecting a PCE that is able to promptly provide a computed path that meets the supplied constraints.
- 迅速供給制約を満たす計算された経路を提供することができるPCEを選択します。
- How many computation requests will the PCC have to send? Will the desired path be computed by the first PCE contacted (possibly in cooperation with other PCEs), or will the PCC have to consult other PCEs to fill in gaps in the path?
- どのように多くの計算を要求PCCは、送信する必要がありますか？所望の経路は、（おそらく他のPCEと連携して）接触最初PCEによって計算される、またはPCCは、経路内のギャップを埋めるために、他のPCEに相談する必要がありますか？
- How many other path computations will need to be issued from within the network in order to establish the TE LSP?
- どのように多くの他の経路計算TE LSPを確立するために、ネットワーク内から発行する必要があるでしょうか？
This last question might be considered out of scope for the head-end LSR, but an important constraint that the PCC may wish to apply is that the path should be computed in its entirety and supplied without loose hops or non-simple abstract nodes.
この最後の質問は、ヘッドエンドLSRの範囲外と見なされるかもしれませんが、PCCは、適用したいことが重要な制約は、パスが全体的に計算され、ゆるいホップまたは非シンプルな抽象ノードなしで供給されなければならないということです。
Thus, with its limited perspective, the PCC will see Multiple PCE Path Computation (Section 5.3) as important and will distinguish two subcases. The first is as shown in Figure 3 with subsequent computation requests made by other PCCs along the path of the TE LSP. In the second, multiple computation requests are issued by the head-end LSR. On the other hand, the PCC will not be aware of Multiple PCE Path Computation with Inter-PCE Communication (Section 5.4), which it will perceive as no different from the simple External PCE Node case (Section 5.2).
したがって、その制限された視点で、PCCは重要のような複数のPCEの経路計算（セクション5.3）を参照し、2つのサブケースを区別します。 TE LSPの経路に沿った他のPCC製後続の計算要求とともに、図3に示すように、第1です。第二に、複数の計算要求は、ヘッドエンドLSRによって発行されています。一方、PCCは、それが簡単な外部PCEノードの場合（5.2節）から変わらないとして知覚するのInter-PCEコミュニケーション（5.4節）、と複数のPCEの経路計算を認識しません。
The PCC, therefore, will be acutely aware that a Centralized PCE Model (Section 6.1) might still require Multiple PCE Path Computations with the head-end or subsequent PCCs required to issue further requests to the central PCE. Conversely, the PCC may be protected from the Distributed PCE Model (Section 6.2) because the first PCE it consults uses inter-PCE communication to achieve a complete computation result so that no further computation requests are required.
PCCは、それゆえ、中央集中型PCEモデル（6.1節）は、まだ中央PCEへのさらなる要求を発行するために必要なヘッドエンドまたはそれ以降のPCCを持つ複数のPCE経路計算を必要とするかもしれないことを痛感されます。それは相談最初のPCEは、さらなる計算要求が必要とされないように、完全な計算結果を達成するために、インターPCE通信を使用するので、逆に、PCCは、PCE分散モデル（セクション6.2）から保護することができます。
These distinctions can be completely classified by determining whether the computation response includes all necessary paths, and whether those paths are fully explicit (that is, containing only strict hops between simple abstract nodes).
これらの区別は、完全に計算応答に必要なすべてのパスを含むかどうかを決定することによって分類することができ、それらのパス（つまり、単純な抽象ノード間の唯一の厳密なホップを含むされる）完全に明示されているかどうか。
Evaluation metrics that may be used to evaluate the efficiency and applicability of any PCE-based solution are listed below. Note that these metrics are not being used to determine paths, but are used to evaluate potential solutions to the PCE architecture.
任意PCEベースのソリューションの効率および適用性を評価するために使用することができる評価指標を以下に列挙する。これらの指標は、経路を決定するために使用されていないが、PCEアーキテクチャへの潜在的な解決策を評価するために使用されることに留意されたいです。
- Optimality: The ability to maximize network utilization and minimize cost, considering QoS objectives, multiple regions, and network layers. Note that models that require the sequential involvement of multiple PCEs (for example, the multiple PCE model described in Section 5.3) might create path loops unless careful policy is applied.
- 最適：QoSの目標、複数の領域、およびネットワーク層を考慮すると、ネットワークの利用率を最大化し、コストを最小限にする能力。慎重なポリシーが適用されない限り、複数のPCEのシーケンシャルな関与を必要としたモデルは、（例えば、5.3節で説明した複数のPCEモデル）のパスを作成することがありますがループすることに注意してください。
- Scalability: The implications of routing, TE LSP signaling, and PCE communication overhead, such as the number of messages and the size of messages (including LSAs, crankback information, queries, distribution mechanisms, etc.).
- スケーラビリティ：そのようなメッセージの数とメント（LSA、クランクバック情報、クエリ、分配機構、等を含む）メッセージのサイズとしてルーティング、TE LSPシグナリング、及びPCE通信オーバーヘッドの影響、。
- Load sharing: The ability to allow multiple PCEs to spread the path computation load by allowing multiple PCEs each to take responsibility for a subset of the total path computation requests.
- 負荷分散：複数のPCEが複数のPCEそれぞれが全経路計算リクエストのサブセットのための責任を取るようにすることによって経路計算負荷を分散することを可能にする能力。
- Multi-path computation: The ability to compute multiple and potentially diverse paths to satisfy load-sharing of traffic and protection/restoration needs including end-to-end diversity and protection within individual domains.
- マルチパス計算：個々のドメイン内のエンドツーエンドの多様性と保護を含むトラフィックおよび保護/修復ニーズの負荷分散を満たすために、複数の潜在的に多様な経路を計算する能力。
- Reoptimization: The ability to perform TE LSP path reoptimization. This also includes the ability to perform inter-layer correlation when considering the reoptimization at any specific layer.
- 再最適化：TE LSPパスの再最適化を実行する機能。これはまた、任意の特定の層に再最適化を考慮した場合、層間の相関を実行する能力を含みます。
- Path computation time: The time to compute individual paths and multiple diverse paths and to satisfy bulk path computation requests. (Note that such a metric can only be applied to problems that are not NP-complete.)
- 経路計算時間：個々のパスと複数の多様な経路を計算すると、バルク経路計算要求を満たすために時間。 （そのようなメトリックのみNP完全でない問題に適用することができることに留意されたいです。）
- Network stability: The ability to minimize any perturbation on existing TE state resulting from the computation and establishment of new TE paths.
- ネットワークの安定性：新しいTEパスの計算と確立に起因する既存のTE状態の任意の摂動を最小にする能力。
- Ability to maintain accurate synchronization between TED and network topology and resource states.
- TEDとネットワークトポロジとリソースの状態の間の正確な同期を維持する能力。
- Speed with which TED synchronization is achieved.
- TED同期が達成される速度。
- Impact of the synchronization process on the data flows in the network.
- データに同期処理の影響は、ネットワークを流れます。
- Ability to deal with situations where paths satisfying a required set of constraints cannot be found by the PCE.
- 制約の必要なセットを満たす経路をPCEによって見つけることができない状況に対処する能力。
- Policy: Application of policy to the PCC-PCE and PCE-PCE communications as well as to the computation of paths that respect inter-domain TE LSP establishment policies.
- ポリシー：PCC-PCEとPCE-PCE通信に同様にドメイン間TE LSP確立ポリシーを尊重経路の計算に対するポリシーの適用。
Note that other metrics may also be considered. Such metrics should be used when evaluating a particular PCE-based architecture. The potential tradeoffs of the optimization of such metrics should be evaluated (for instance, increasing the path optimality is likely to have consequences on the computation time).
他のメトリックも考慮することができることに注意してください。特定のPCEベースのアーキテクチャを評価する場合、そのようなメトリックが使用されるべきです。そのようなメトリックの最適化の潜在的なトレードオフを評価すべきである（例えば、パスの最適性を増加させると、計算時間に影響を持っている可能性があります）。
The PCE architecture introduces several elements that are subject to manageability. The PCE itself must be managed, as must its communications with PCCs and other PCEs. The mechanism by which PCEs and PCCs discover each other are also subject to manageability.
PCEアーキテクチャは、管理の対象となるいくつかの要素を紹介します。 PCC及びその他のPCEとのコミュニケーションなければならないようPCE自体は、管理する必要があります。 PCEとのPCCが互いを発見するメカニズムはまた、管理の対象となっています。
Many of the issues of manageability are already covered in other sections of this document.
管理性の問題の多くは、すでにこの文書の他のセクションで説明されています。
It must be possible to enable and disable the PCE function at a PCE, and this will lead to the PCE accepting, rejecting, or simply not receiving requests from PCCs. Graceful shutdown of the PCE function should also be considered so that in controlled circumstances (such as software upgrade) a PCE does not just 'disappear' but warns its PCCs and gracefully handles any queued computation requests (perhaps by completing them, forwarding them to another PCE, or rejecting them).
PCEでPCE機能を有効または無効にすることが可能でなければならない、これはPCEが、受諾拒否、または単にのPCCからのリクエストを受信していないにつながります。 （ソフトウェアのアップグレードなど）制御された状況でPCEはちょうど「消える」が、そののPCCを警告し、優雅いずれかが別のに転送する、おそらくそれらを完了することにより（計算要求をキューに入れられた処理しないように、PCE機能の正常な停止をも考慮すべきですPCE、またはそれらを拒絶します）。
Similarly it must be possible to control the application of policy at the PCE through configuration. This control may include the restriction of certain functions or algorithms, the configuration of access rights and priorities for PCCs, and the relationships with other PCEs both inside and outside the domain.
同様に構成を通してPCEでポリシーの適用を制御することが可能でなければなりません。このコントロールは、特定の機能又はアルゴリズムの制限、アクセス権とのPCCの優先順位の設定、およびドメイン内外の両方他のPCEとの関係を含むことができます。
The policy configuration interface is yet to be determined. The interface may be purely a local matter, or it may be supported via a standardized interface (such as a MIB module).
ポリシー構成インタフェースは、まだ決定されるべきです。インタフェースは、純粋に局所的な問題であってもよいし、（例えば、MIBモジュールなどの）標準化されたインタフェースを介して支持されてもよいです。
It is expected that the operations of PCEs and PCCs will be modeled and controlled through appropriate MIB modules. The tables in the new MIB modules will need to reflect the relationships between entities and to control and report on configurable options.
のPCEとのPCCの動作をモデル化し、適切なMIBモジュールを介して制御されることが期待されます。新しいMIBモジュールのテーブルは、エンティティ間の関係を反映するために、制御および設定可能なオプションを報告する必要があります。
Statistics gathering will form an important part of the operation of PCEs. The operator must be able to determine the historical interactions of a PCC with its PCEs, the performance that it has seen, and the success rate of its requests. Similarly, it is important for an operator to be able to inspect a PCE and determine its load and whether an individual PCC is responsible for a disproportionate amount of the load. It will also be important to be able to record and inspect statistics about the communications between the PCC and PCE, including issues such as malformed messages, unauthorized messages, and messages discarded because of congestion. In this respect, there is clearly an overlap between manageability and security.
統計の収集はのPCEの動作の重要な部分を形成することになります。オペレータは、そののPCEとPCCの歴史的な相互作用が、それは見ている、パフォーマンス、およびその要求の成功率を決定することができる必要があります。同様に、オペレータは、PCEを検査し、その負荷を決定できるようにするために重要であり、個々のPCCは、負荷の不均衡な量の原因であるかどうか。また、このような不正なメッセージ、不正なメッセージ、およびので渋滞の破棄されたメッセージなどの問題を含むPCCとPCEとの間の通信に関する統計情報を記録し、検査できることが重要になります。この点で、明らかに管理とセキュリティの間に重複があります。
Statistics for the PCE architecture can be made available through appropriate tables in the new MIB modules.
PCEアーキテクチャの統計は、新しいMIBモジュールにおける適切なテーブルを通じて利用できるようにすることができます。
The new MIB modules should also be used to provide notifications when key thresholds are crossed or when important events occur. Great care must be exercised to ensure that the network is not flooded with Simple Network Management Protocol (SNMP) notifications. Thus, it might be inappropriate to issue a notification every time a PCE receives a request to compute a path. In any case, full control must be provided to allow notifications to be disabled using, for example, the mechanisms defined in the SNMP-NOTIFICATION-MIB module in [RFC3413].
新しいMIBモジュールはまた、主要なしきい値を超えた場合、または重要なイベントが発生したときに通知を提供するために使用する必要があります。細心の注意は、ネットワークが簡易ネットワーク管理プロトコル（SNMP）通知が殺到していないことを保証するために払わなければなりません。したがって、通知にPCEがパスを計算するための要求を受信するたびに発行することは不適切かもしれません。いずれの場合においても、フルコントロールを通知は、例えば、使用して無効にすることを可能にするために提供されなければならない、[RFC3413]にSNMP-NOTIFICATION-MIBモジュールで定義されたメカニズム。
Section 6.5 discusses the importance of a PCC being able to detect the liveness of a PCE. PCE-PCC communications techniques must enable a PCC to determine the liveness of a PCE both before it sends a request and in the period between sending a request and receiving a response.
セクション6.5は、PCEの生存性を検出することができるPCCの重要性を論じています。それが要求を送信し、要求を送信し、応答を受信するまでの期間に前PCE-PCC通信技術は、両方のPCEの生存性を決定するために、PCCを有効にする必要があります。
It is less important for a PCE to know about the liveness of PCCs, and within the simple request/response model, this is only helpful
PCEはのPCCの生存性について知っていることはそれほど重要であり、単純な要求/応答モデルの中に、これが唯一の役に立ちます
- to gain a predictive view of the likely loading of a PCE in the future, or
- 将来PCEの可能性ローディングの予測ビューを得る、またはし
- to allow a PCE to abandon processing of a received request.
- PCEは、受信した要求の処理を放棄することを可能にします。
Correct operation for the PCE architecture can be classified as determining the correct point-to-point connectivity between PCCs and PCEs, and as assessing the validity of the computed paths. The former is a security issue that may be enhanced by authentication and monitored through event logging and records as described in Section 9.1. It may also be a routing issue to ensure that PCC-PCE connectivity is possible.
PCEアーキテクチャの正しい動作のPCCとPCEとの間の正確なポイント・ツー・ポイント接続を決定するよう、及び計算された経路の有効性を評価するように分類することができます。前者は9.1節で説明したように、認証によって強化し、イベントログとレコードを監視することができるセキュリティの問題です。また、PCC-PCE接続が可能であることを保証するために、ルーティングの問題であってもよいです。
Verifying computed paths is more complex. The information to perform this function can, however, be made available to the operator through MIB tables, provided that full records are kept of the constraints passed on the request, the path computed and provided on the response, and any additional information supplied by the PCE such as the constraint relaxation policies applied.
計算されたパスを検証することは、より複雑です。この機能を実行するための情報は、しかしながら、完全なレコードが、要求に渡される制約の維持経路が応答に計算され、提供され、任意の追加情報により供給されていれば、MIBテーブルを介してオペレータに利用可能にすることができますPCE適用される制約緩和政策など。
At the architectural stage, it is impossible to make definitive statements about the impact on other protocols and functional components since the solution's work has not been completed. However, it is possible to make some observations.
建築段階では、ソリューションの作業が完了していないので、他のプロトコルおよび機能部品への影響についての明確な発言をすることは不可能です。しかし、いくつかの観測を行うことが可能です。
- Dependence on underlying transport protocols
- 基本的なトランスポートプロトコルへの依存
PCE-PCC communications may choose to utilize underlying protocols to provide transport mechanisms. In this case, some of the manageability considerations described in the previous sections may be devolved to those protocols.
PCE-PCC通信は、トランスポートメカニズムを提供するために、基礎となるプロトコルを利用することを選択することができます。この場合、前のセクションで説明した管理の考慮事項のいくつかは、それらのプロトコルに委譲してもよいです。
- Re-use of existing protocols for discovery
- 発見のための既存のプロトコルの再利用
Without prejudicing the requirements and solutions work for PCE discovery (see Section 6.4), it is possible that use will be made of existing protocols to facilitate this function. In this case some of the manageability considerations described in the previous sections may be devolved to those protocols.
（セクション6.4を参照）PCE発見のために働くの要件とソリューションを害するなければ、この機能を容易にするための使用は、既存のプロトコルを説明することは可能です。この場合、前のセクションで説明した管理の考慮事項のいくつかは、それらのプロトコルに委譲してもよいです。
- Impact on LSRs and TE LSP signaling
- のLSRとTE LSPシグナリングへの影響
The primary example of a PCC identified in this architecture is an MPLS or a GMPLS LSR. Consideration must therefore be given to the manageability of the LSRs and the additional manageability constraints applicable to the TE LSP signaling protocols.
このアーキテクチャで同定されたPCCの主な例は、MPLS又はGMPLSのLSRです。考察は、したがって、TE LSPのシグナリングプロトコルにも適用可能でのLSRと追加の管理の制約の管理に与えられなければなりません。
In addition to allowing the PCC management described in the previous sections, an LSR must be configurable to determine whether it will use a remote PCE at all, the options being to use hop-by-hop routing or to supply the PCE function itself. It is likely to be important to be able to distinguish within an LSR whether the route used for a TE LSP was supplied in a signaling message from another LSR, by an operator, or by a PCE, and, in the case where it was supplied in a signaling message, whether it was enhanced or expanded by a PCE.
前のセクションで説明したPCCの管理を可能にすることに加えて、LSRは、それがすべてのリモートPCEを使用するかどうかを決定するために構成可能である必要があり、あるオプションは、ホップバイホップルーティングを使用するか、PCEの機能自体を供給します。供給された場合には、TE LSPのために使用される経路は、オペレータによって、別のLSRからのシグナリングメッセージで供給される、又はPCEによってれたかどうかLSR内で区別できることが重要であると思われる、とシグナリングメッセージに、それが強化されたかどうかPCEによって拡大しました。
- Reuse of existing policy models and mechanisms
- 既存のポリシーモデルとメカニズムの再利用
As policy support mechanisms can be quite extensive, it is worthwhile to explore to what extent this prior work can be leveraged and applied to PCE. This desire to leverage prior work should not be interpreted as a requirement to use any particular solution or protocol.
政策支援の仕組みは非常に広範なように、この前の仕事が活用してPCEに適用することができますどの程度まで探索する価値があります。前ワークを活用するために、この願望は、任意の特定の溶液又はプロトコルを使用するための要件として解釈されるべきではありません。
This architecture may have two impacts on the operation of a network. It increases TE LSP setup times while requests are sent to and processed by a remote PCE, and it may cause congestion within the network if a significant number of computation requests are issued in a small period of time. These issues are most severe in busy networks and after network failures, although the effect may be mitigated if the protection paths are precomputed or if the path computation load is distributed among a set of PCEs.
このアーキテクチャは、ネットワークの運用上の2つの影響を有することができます。リクエストが送られ、リモートPCEによって処理されている間、それは、TE LSP設定時間を増加させ、計算要求のかなりの数は、時間の小さな期間内に発行された場合には、ネットワーク内の輻輳を引き起こす可能性があります。予備パスが予め計算された場合、または経路計算負荷のPCEのセット間に分散された場合に効果を緩和することができるが、これらの問題は、忙しいネットワークおよびネットワーク障害後に最も深刻です。
Issues of potential congestion during recovery from failures may be mitigated through the use of pre-established protection schemes such as fast reroute.
障害からの回復時の潜在的な輻輳の問題は、このような高速リルートとして事前に確立された保護スキームを使用することによって緩和することができます。
It is important that network congestion be managed proactively because it may be impossible to manage it reactively once the network is congested. It should be possible for an operator to rate limit the requests that a PCC sends to a PCE, and a PCE should be able to report impending congestion (according to a configured threshold) both to the operator and to its PCCs.
ネットワークが混雑しているいったん反応的に管理することは不可能かもしれないので、ネットワークの輻輳を積極的に管理することが重要です。オペレータは、PCCはPCEに送信し、PCEは、オペレータに、その型PCCの両方（設定されたしきい値に応じて）切迫輻輳を報告することができなければならない要求をレート制限することが可能であるべきです。
No other management considerations have been identified.
他の管理に関する考慮事項が確認されていません。
The impact of the use of a PCE-based architecture must be considered in the light of the impact that it has on the security of the existing routing and signaling protocols and techniques in use within the network. The impact may be less likely to be an issue in the case of intra-domain use of PCE, but an increase in inter-domain information flows and the facilitation of inter-domain path establishment may increase the vulnerability to security attacks.
PCEベースのアーキテクチャを使用することの影響は、それがネットワーク内で使用中のルーティングを既存のシグナリングプロトコルおよび技術のセキュリティに対して有する影響に照らして考慮しなければなりません。影響はPCEのドメイン内での使用の場合は問題になりにくいかもしれないが、ドメイン間の情報の流れの増加とドメイン間のパスの確立の促進は、セキュリティ攻撃に対する脆弱性を増大させることができます。
Of particular relevance are the implications for confidentiality inherent in a PCE-based architecture for multi-domain networks. It is not necessarily the case that a multi-domain PCE solution will compromise security, but solutions MUST examine their effects in this area.
特に関連のマルチドメインネットワークのPCEベースのアーキテクチャに固有の機密性への影響です。これは、マルチドメインPCEソリューションは、セキュリティを侵害することを必ずしもそうではありませんが、解決策は、この分野での効果を検討しなければなりません。
Applicability statements for particular combinations of signaling, routing and path computation techniques are expected to contain detailed security sections.
シグナリング、ルーティング、および経路計算技術の特定の組み合わせのための適用性ステートメントは詳細なセキュリティセクションを含むことが期待されます。
Note that the use of a non-local PCE (that is, one not co-resident with the PCC) does introduce additional security issues. Most notable among these are:
非ローカルPCEの使用は（PCCとつまり、人はいない共存）追加のセキュリティ問題を導入しないことに注意してください。これらの中で最も注目すべきは、以下のとおりです。
- interception of PCE requests or responses;
- PCE要求や応答の傍受。
- impersonation of PCE or PCC;
- PCEまたはPCCの偽装。
- falsification of TE information, policy information, or PCE capabilities; and
- 情報、ポリシー情報、またはPCIE機能の改ざん。そして
- denial-of-service attacks on PCE or PCE communication mechanisms.
- PCEやPCE通信メカニズム上のサービス拒否攻撃。
It is expected that PCE solutions will address these issues in detail using authentication and security techniques.
PCEのソリューションは、認証やセキュリティ技術を用いて詳細にこれらの問題に対処することが期待されます。
The authors would like to extend their warmest thanks to (in alphabetical order) Arthi Ayyangar, Zafar Ali, Lou Berger, Mohamed Boucadair, Igor Bryskin, Dean Cheng, Vivek Dubey, Kireeti Kompella, Jean-Louis Le Roux, Stephen Morris, Eiji Oki, Dimitri Papadimitriou, Richard Rabbat, Payam Torab, Takao Shimizu, and Raymond Zhang for their review and suggestions. Lou Berger provided valuable and detailed contributions to the discussion of policy in this document.
著者は、（アルファベット順）Arthi Ayyangar、Zafarアリ、ルー・バーガー、モハメドBoucadair、イゴールBryskin、ディーン・チェン、のVivek Dubeyさん、Kireeti Kompella、ジャン=ルイ・ル・ルー、スティーブン・モリス、大木英司への暖かい感謝を拡張したいと思います、彼らのレビューと提案のためのディミトリPapadimitriou、リチャードRabbat、Payam Torab、高尾清水、そしてレイモンドチャン。ルー・バーガーは、この文書に記載されている政策の議論に貴重かつ詳細な貢献を提供します。
Thanks also to Pekka Savola, Russ Housley and Dave Kessens for review and constructive discussions during the final stages of publication.
出版物の最終段階でのレビューと建設的な議論のためにも、ペッカSavola、ラスHousleyとDave Kessensに感謝します。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702] Awduche、D.、マルコム、J.、Agogbua、J.、オデル、M.、およびJ.マクマナス、 "トラフィックエンジニアリングオーバーMPLSのための要件"、RFC 2702、1999年9月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、RFC 4364、2006年2月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）OSPFバージョン2への拡張"、RFC 3630、2003年9月。
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[RFC3413]レビ、D.、マイヤー、P.、およびB.スチュワート、 "簡易ネットワーク管理プロトコル（SNMP）アプリケーション"、STD 62、RFC 3413、2002年12月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3748] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3748]スミット、H.、およびT.李、 "中間システムトラフィックエンジニアリング（TE）のための中間システム（IS-IS）への拡張"、RFC 3784、2004年6月。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812]スリニバサン、C.、Viswanathanの、A.、およびT.ナドー、 "マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）管理情報ベース（MIB）"、RFC 3812、2004年6月。
[RFC4105] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105]ル・ルー、J.-L.、Vasseur、J.-P.、およびJ.ボイル、 "エリア間MPLSトラフィックエンジニアリングのための要件"、RFC 4105、2005年6月。
[RFC4216] Zhang, R. and J.-P. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216]張、R.及びJ.-P. Vasseur、 "MPLSインター自律システム（AS）トラフィックエンジニアリング（TE）の要件"、RFC 4216、2005年11月。
[MLN] Shiomoto, K., Papdimitriou, D., Le Roux, J.-L., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-based multi-region and multi-layer networks (MRN/MLN)", Work in Progress, June 2006.
【MLN] Shiomoto、K.、Papdimitriou、D.、ルルー、J.-L.、Vigoureux、M.、およびD. Brungard、「要件GMPLSベースのマルチ領域多層ネットワーク（MRN / MLN ）」、進歩、2006年6月に作業。
Authors' Addresses
著者のアドレス
Adrian Farrel Old Dog Consulting
エードリアンファレル古い犬のコンサルティング
EMail: adrian@olddog.co.uk
メールアドレス：adrian@olddog.co.uk
Jean-Philippe Vasseur 1414 Massachussetts Avenue Boxborough, MA 01719 USA
ジャン=フィリップVasseur 1414マサチューセッツアベニューボックスボロー、MA 01719 USA
EMail: jpv@cisco.com
メールアドレス：jpv@cisco.com
Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA
ジェリー・アッシュAT＆TルームMT D5-2A01 200ローレルアベニューミドルタウン、NJ 07748、USA
Phone: (732)-420-4578 Fax: (732)-368-8659 EMail: gash@att.com
電話：（732）-420-4578ファックス：（732）-368-8659 Eメール：gash@att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。