[要約] RFC 4655は、PCEベースのアーキテクチャに関する標準化文書であり、ネットワークの経路計算を効率化するための仕組みを提案しています。目的は、ネットワークのトラフィックエンジニアリングや経路最適化を支援し、ネットワークのパフォーマンスを向上させることです。
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
パス計算要素（PCE）ベースのアーキテクチャ
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).
Copyright（c）The Internet Society（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]ネットワークのトラフィックエンジニアリングの基本的な構成要素です。[RFC2702]は、MPLSネットワークのトラフィックエンジニアリングの要件を記述し、[RFC4105]および[RFC4216]は、それぞれエリア間およびAS間の環境におけるトラフィックエンジニアリング要件を説明しています。
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のliveningの検出、パス計算クライアント（PCCS）とPCE（PCC-PCE通信）およびPCE-PCE通信、トラフィック、トラフィックの間の通信などの建築上の考慮事項について説明します。エンジニアリングデータベース（TED）同期、ステートフルおよびステートレスPCES、監視、ポリシーと機密性、および評価メトリック。
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およびTEDおよび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領域、自律システム（ASE）、およびサービスプロバイダーネットワーク内の複数のASが含まれます。パス計算責任のドメインは、地域またはASEのサブドメインとして存在する場合があります。
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.
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)
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.
複数のドメインにまたがるパスは、各ドメインに関与する1つ以上の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)
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)
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は、ルーター、LSR、専用のネットワークサーバーなどに実装できます。さらに、PCE関数は、実装されているノードの転送機能に直交します。
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.
PCEベースのアーキテクチャ（セクション5で説明）のいくつかの動機を以下に示します。このリストは網羅的であることを意図したものではなく、説明のために提供されます。
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.
これらの状況では、一部のルーターがCPUの制約のためにパス計算を実行することは不可能または望ましくない場合があります。その場合、パス計算は他のPCEにオフロードされる可能性があります。ルーターまたは専用の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 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.
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.
一部のネットワーク内で実行されるIGPSは、完全なTEDを構築するのに十分ではありません。たとえば、ネットワークはOSPF/ISIS-TE拡張機能なしでOSPF/IS-I-ISを実行したり、ネットワーク内の一部のルーターが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).
MPLS VPN [RFC4364]のコンテキストで、管理上の理由（たとえば、プロバイダーエッジ（PE）ルーターに接続されたカスタマーエッジ（CE）ルーターに接続されているルーティングドメインの一部ではない場合があります。ce to ce lspパスを提供するため）。
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 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.
PCEを使用して、LSPの速いルート保護のコンテキストでバックアップパスを計算できます。このモデルでは、特定の施設を保護するすべてのバックアップTE LSPは、PCEによって調整された方法で計算されます。これにより、TE 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アーキテクチャは、サーバー層ネットワーク全体の1つのクライアント層ネットワーク領域から別のクライアントまでのパス計算を可能にするのに役立ちます。ネットワーク領域をレイヤーします。
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.
この場合、PCESは、アドレス空間の問題を解決し、ポリシーパラメーターと制御パラメーターの違いを処理し、ネットワーク間のリソースの調整を担当します。帯域幅の粒度の違いがあるため、サーバーレイヤーネットワーク全体の接続性は仮想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.
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 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 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は、集中テッドが電流（リアルタイム）ネットワーク状態を完全に反映できない場合、ネットワーク障害またはリソースの競合の可能性がまだ存在するため、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 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.
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
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.
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
図4. PCE間通信による複数の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パス計算には、1つの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は、InterPCE通信を使用した集中計算と複数の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.
- 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が1つしかないことに注意してください。
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を含む可能性のあるドメインまたはネットワークを指し、パスの計算がPCES間で共有される場合です。特定のパスは、単一の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によって実行されます。たとえば、これは通常、Ingress LSR/Composite PCEノードがパスの計算または外部PCEの接触を担当する単一のIGP領域内のMPLS TEの場合です。逆に、複数のPCEパス計算は、1つのパスの計算に複数のPCEが関与していることを意味します。この例は、MPLS TE LSPでのトランジットLSRS/複合PCEノードによってルースホップ拡張が実行される場所です。別の例は、複数の協力PCEを使用して、複数のドメインにまたがる単一のTE LSPのパスを計算することです。
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に単一のリクエストを送信して、一連のパスを計算することを要求しますが、非同期パス計算が許容できることを指定することができます。PCCが複数のリクエストを行った場合、PCEは各パスを順番に順番に計算する場合があり、PCEが選択した場合、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.
PCC-PCEプロトコルにパラメーターを追加して、PCCがPCCが使用するための一連の代替パスを提供することを要求することが望ましいです。一方、最初のパスが失敗した場合、PCCの応答の代替パスを含む場合、代替パスが常に成功するとは限りませんが、必要に応じてPCCに後続のパス計算を個別にリクエストするよりもオーバーヘッドが少なくなる可能性があります。この手法は、既存の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.
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.
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機能を学習するか、情報を動的に発見する場合があります。PCCでPCEの位置が構成されている場合でも、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を選択する必要があります。このような選択の詳細（たとえば、複数のPCEで計算負荷を効率的に共有したり、部分的または故障した計算後に二次計算を要求するため）は、PCCにローカルであり、ポリシーに基づいており、この範囲外である可能性があります。書類。
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.)
- 説明できる一連の制約（多様性、共有リスクリンクグループ（SRLG）、光学障害、波長の連続性など）
- 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.
この情報は、PCCが使用するPCEを決定するのに役立ちます。
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の活性を検出する能力は、全体的なアーキテクチャの必須部分であり、いくつかの手段で達成できます。PCEの発見に何らかの形の定期的な広告（IGP拡張など）が使用される場合、PCEのliveningはステータス広告（たとえば、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の活性を決定するために、プロトコルタイマーなどの他のメカニズムを使用する必要があります。これは、PCCのドメインで実行されるIGPによってPCEのlivensionが検出されない場合があるドメイン間パス計算の場合に特に重要です。
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がPCCを選択し、PCCがPCCのローカルではないことを提供すると、PCCがPATH計算要求をPCEに通信し、PCEがPATH計算応答を返すためにリクエスト/応答プロトコルが必要です。このプロトコルのセキュリティ要件と意味の議論は、このドキュメントのセクション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
- 使用/回避するためのリソース、リソースの親和性、および共有リスクリンクグループ（SRLG）
- 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つ以上のパスが要求ノードに返されます。目的のパスを計算できなかった場合、エラーは、障害の理由について可能な限り多くの情報と一緒にエラーが返され、潜在的にどの制約が緩和される可能性があるため、肯定的なものが緩和される可能性があります。結果は、将来のリクエストで可能性が高くなります。
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がパス計算要求を通信するには、要求/応答プロトコルも必要です。パス計算要求には、上記の要件を含む重要な一連の要件が含まれる場合があります。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で動作します。テッドを構築するためのネットワークステータスに関する情報は、さまざまな手段でドメインで提供される場合があります。
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.
1) TE情報のIGP分布への参加。IGP領域内のTE情報の分布の標準的な方法は、IGP [RFC3630、RFC3748]への拡張機能を使用することです。このメカニズムにより、参加ノードはTEDを構築できます。これは、たとえば、単一のMPLSまたはGMPLSネットワーク内で標準的な手法です。PCE関数をホストするノードは、ドメイン内のルーターを使用して少なくとも1つのルーティング隣接を維持することにより、この方法で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) バンド外のテッド同期。PCEが1つ以上のドメインのIGPに参加するのは便利でも不可能かもしれません（たとえば、非常に多くのドメインがある場合、IGPの参加が望ましくない場合、または一部のドメインがTE認識IGPSを実行していない場合）。この場合、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（RE）最適化を強化して「完全なネットワーク」（再）最適化を提供し、トラフィックの変動を考慮に入れることができます。詳細なTE LSP情報は、仮想ネットワークトポロジ（VNT）[MLN]の再構成を促進する可能性があります。この場合、光学パスなどの低層TE LSPは、この再構成も高層で使用するためのTEリンクを提供します。フルネットワーク」の問題。
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.
同期技術は、ドメイン内および領域間TEDの両方に適用される場合があることに注意してください。さらに、技術は異なるドメインで使用するために混合できます。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）に関する情報を利用します。これにより、最適なパス計算とパス計算の成功が増加する可能性がありますが、ステートフルなPCESには、潜在的に有意なコントロールプレーンオーバーヘッドと大量のデータ/状態の維持がある信頼できる状態同期メカニズムが必要であることに注意してください（たとえば、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が1つしかない場合、すべてのTE LSP計算はこのPCEによって行われ、既存のすべてのTE LSPを追跡して同期したままです（各TE LSP状態の変更はPCEによって追跡する必要があります）。ただし、このモデルでは、かなりの制御プレーンリソースが必要になる場合があります。ネットワークに複数のPCEがある場合、TE LSPの計算と情報がPCES間に分散されるため、計算の実行に必要なリソースも分散されます。ただし、セクション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が計算したすべてのteLSPを記憶すること、TE LSPが実際にセットアップされたこと（これがわかっている場合）、およびそれらが取り壊されたときにほぼ単純な問題です。。バンド外のTED同期も複雑であり、分散型PCE計算モデルに複数のPCEセットアップがあり、人種条件、スケーラビリティの懸念などになりやすい可能性があります。そのような情報を考慮に入れてパス計算を考慮に入れて、レイヤーは非常に複雑になる可能性があります。PCESは互いに通信することで状態を同期する可能性がありますが、いくつかのPCESで実行された分散計算を使用してTE LSPをセットアップすると、同期と人種状態の回避の問題がより大きく複雑になります。
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の最小数が破壊されない可能性があることに注意してください。別のアプリケーションは、仮想ネットワークトポロジ[MLN]の構築とメンテナンスに関するものです。また、存在する、またはセットアップする必要があるフォワード隣接を管理する方法を決定するために、ネットワークに他のどのTE LSPが存在するかを理解することも役立ちます。Stateful 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は計算されたパスを覚えておく必要がなく、各リクエストセットは互いに独立して処理されます。たとえば、ステートレスPCESは、現在のTED情報に基づいてパスを計算する場合があります。これは、他の最近のPCE計算パスの変更を考慮して、実際のネットワーク状態と同期しない可能性があります。たとえば、二重帯域幅の会計を避けたり、変化を最小限に抑えたりするために、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は、ネットワーク状態に関する情報で動作していることに注意してください。TEDには、IGPSによって分散された、または他の手段で収集されたリンク状態および帯域幅の可用性情報が含まれています。この情報をさらに強化するために、粒度の向上と、たとえば、リソースの親和性または転送等価クラスに従って特定のリンクでの現在の帯域幅使用量をカバーする詳細を提供することができます。ただし、そのような情報は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]に記載されているように、Provider間のTE LSP計算の場合には、複数のサービスプロバイダーコアで機密性を維持しながらパスを計算する機能が必要です。つまり、プロバイダー間のTE LSPパス計算をサポートするために、1つのサービスプロバイダーがリソースまたはトポロジに関する情報を明かす必要はありません。したがって、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:
- 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
-
- rejection of a request by the PCE based on the identity of the requesting PCC
- 要求するPCCの身元に基づいてPCEによる要求の拒否
- 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.
------------------------------
| --------- | 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
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は、PCE間通信の例を備えた複数のPCEの例を介して、異なるPCE関数のケースを示しています（図4と比較）。各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
図7.複数のPCEのポリシーコンポーネント
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.
- PCESに相談する前に、PCCSによって政策決定が下される場合があります。このタイプの決定には、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.
-
- 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.
-
Within the context of PCE, we identify several types of policies:
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が含まれます。パス計算要求の構築中にPCCによってユーザー固有のポリシーを適用することができます。または、PCCからPCCに十分な情報が提供されている場合、リクエストの処理中にPCEによって適用できます。
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
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が他のドメインに可視性がある場合、計算にポリシーの考慮事項を適用できるはずであり、ドメイン間のポリシー契約に注意する必要があります。PATH計算がPCES間の協力の結果である場合、それぞれが特定のドメインに責任がある場合、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.
PCC-PCE通信（セクション6.6を参照）は、単純なリクエスト/応答の相互作用を超えて有用に拡張できる可能性があります。たとえば、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.
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を呼び出していたドメイン境界である可能性が最も高くなります。したがって、ドメイン内の障害は、イングレスドメイン境界に報告され、ドメイン全体のパスを計算しようとします。これに失敗すると、問題は前のドメインに報告され、そのドメインのイングレス境界に通信する場合があります。このドメインは、次のドメインへの別のエントリポイントを選択するか、またはAを通るルートを選択することにより、より成功したパスを選択しようとする場合があります。異なるドメインのセット。
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がPCSがその要求に答えるために協力する方法についての知識が限られているが、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.
-
- 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はパスのギャップを埋めるために他のPCESを参照する必要がありますか？
- How many other path computations will need to be issued from within the network in order to establish the 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つのサブケースを区別します。1つ目は、図3に示すように、TE LSPの経路に沿って他のPCCが作成した後続の計算要求です。2番目では、ヘッドエンドLSRによって複数の計算要求が発行されます。一方、PCCは、PCE間通信を使用した複数のPCEパス計算を認識しません（セクション5.4）。これは、単純な外部PCEノードケース（セクション5.2）と違いはありません。
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）には、ヘッドエンドまたはその後のPCCが中央PCEへのさらなる要求を発行するために必要な複数のPCEパス計算が必要になる可能性があることを鋭く認識します。逆に、PCCは分散型PCEモデル（セクション6.2）から保護される場合があります。これは、最初のPCEがPCE間通信を使用して完全な計算結果を達成し、それ以上の計算リクエストが不要になるためです。
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.
-
- 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).
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自体を管理する必要があります。PCESと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).
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.
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.
PCESおよびPCCSの操作は、適切な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.
Statistics for the PCE architecture can be made available through appropriate tables in the new MIB modules.
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].
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では、PCCがPCEの活性を検出できることの重要性について説明します。PCE-PCC通信手法では、PCCがリクエストを送信する前とリクエストを送信して応答を受信するまでの期間の両方の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
PCCが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アーキテクチャの正しい操作は、PCCSとPCES間の正しいポイントツーポイント接続の決定、および計算されたパスの妥当性を評価することとして分類できます。前者は、セクション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.
PCE発見の要件とソリューションの動作を損なうことなく（セクション6.4を参照）、この機能を促進するために既存のプロトコルで使用される可能性があります。この場合、前のセクションで説明した管理可能性の考慮事項の一部は、それらのプロトコルに委ねられる場合があります。
- Impact on LSRs and TE LSP signaling
- LSRSおよび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です。したがって、LSRの管理可能性と、TE LSPシグナル伝達プロトコルに適用される追加の管理可能性の制約を考慮する必要があります。
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のセットアップ時間が増加し、少数の期間でかなりの数の計算要求が発行された場合、ネットワーク内で混雑を引き起こす可能性があります。これらの問題は、忙しいネットワークやネットワークの障害後に最も深刻ですが、保護パスが事前に計算された場合、またはPSEのセット間でパス計算負荷が分布している場合、効果が軽減される場合があります。
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.
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
- TE情報、ポリシー情報、またはPCE機能の改ざん。と
- 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 Ali、Lou Berger、Mohamed Boucadair、Igor Bryskin、Dean Cheng、Vivek Dubey、Kireeti Kompella、Jean-Louis le Roux、Stephen Morris、eiji kiji kiji oki、Dimitri Papadimitriou、Richard Rabbat、Payam Torab、Takao Shimizu、およびRaymond Zhangのレビューと提案。Lou Bergerは、この文書のポリシーの議論に貴重かつ詳細な貢献を提供しました。
Thanks also to Pekka Savola, Russ Housley and Dave Kessens for review and constructive discussions during the final stages of publication.
出版の最終段階でのレビューと建設的な議論をしてくれたPekka Savola、Russ 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.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想プライベートネットワーク（VPNS）」、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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「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] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to 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] Levi、D.、Meyer、P。、およびB. Stewart、「Simple Network Management Protocol（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] Berger、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.
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「マルチプロトコルラベルスイッチング（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.
[RFC4216] Zhang, R. and J.-P. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216] Zhang、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.、Le Roux、J.-L.、Vigoureux、M。、およびD. Brungard、「GMPLSベースのマルチリージョンおよびマルチレイヤーネットワークの要件（MRN/MLN））」、2006年6月、進行中の作業。
Authors' Addresses
Adrian Farrel Old Dog Consulting
エイドリアンファレルオールドドッグコンサルティング
EMail: adrian@olddog.co.uk
Jean-Philippe Vasseur 1414 Massachussetts Avenue Boxborough, MA 01719 USA
Jean-Philippe Vasseur 1414 Massachussetts Avenue Boxborough、MA 01719 USA
EMail: jpv@cisco.com
Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA
ジェリーアッシュAT＆TルームMT D5-2A01 200ローレルアベニューミドルタウン、ニュージャージー州07748、米国
Phone: (732)-420-4578 Fax: (732)-368-8659 EMail: gash@att.com
電話：（732）-420-4578ファックス：（732）-368-8659メール：gash@att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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).