[要約] RFC 7399は、Path Computation Element（PCE）アーキテクチャにおける未解決の問題についての要約です。その目的は、PCEアーキテクチャの改善と進化に向けた課題の特定と解決策の提案です。
Internet Engineering Task Force (IETF) A. Farrel
Request for Comments: 7399 Juniper Networks
Category: Informational D. King
ISSN: 2070-1721 Old Dog Consulting
October 2014
Unanswered Questions in the Path Computation Element Architecture
パス計算要素アーキテクチャにおける未回答の質問
Abstract
概要
The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) in RFC 5623 and generalized to Hierarchical PCE (H-PCE) in RFC 6805.
Path Computation Element（PCE）アーキテクチャはRFC 4655で規定されています。このアーキテクチャは、RFC 5623で仮想ネットワークトポロジマネージャー（VNTM）を導入することでマルチレイヤーネットワーキングに拡張され、Hierarchical PCE（H-PCE）に一般化されています。 RFC 6805。
These three architectural views of PCE deliberately leave some key questions unanswered, especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF efforts.
これら3つのPCEのアーキテクチャビューは、特にアーキテクチャコンポーネント間の相互作用に関して、いくつかの重要な質問に意図的に回答していません。このドキュメントはそれらの質問を引き出し、他のアーキテクチャコンポーネント、既存のプロトコル、および最近のIETFの取り組みを参照しながら、アーキテクチャのコンテキストでそれらについて説明します。
This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function.
このドキュメントは、アーキテクチャドキュメントを更新せず、プロトコルまたはコンポーネントの使用方法を定義しません。ただし、アーキテクチャコンポーネントを組み合わせて高度なPCE機能を提供する方法を提案しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7399.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7399で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. What Is Topology Information? ...................................4
3. How Is Topology Information Gathered? ...........................5
4. How Do I Find My PCE? ...........................................6
5. How Do I Select between PCEs? ...................................7
6. How Do Redundant PCEs Synchronize TEDs? .........................8
7. Where Is the Destination? .......................................9
8. Who Runs or Owns a Parent PCE? .................................10
9. How Do I Find My Parent PCE? ...................................11
10. How Do I Find My Child PCEs? ..................................11
11. How Is the Parent PCE Domain Topology Built? ..................12
12. Does H-PCE Solve the Internet? ................................12
13. What are Sticky Resources? ....................................13
14. What Is a Stateful PCE for? ...................................14
15. How Is the LSP-DB Built? ......................................14
16. How Do Redundant Stateful PCEs Synchronize State? .............15
17. What Is an Active PCE? What Is a Passive PCE? .................16
18. What is LSP Delegation? .......................................17
19. Is an Active PCE with LSP Delegation Just a Fancy NMS? ........18
20. Comparison of Stateless and Stateful PCE ......................18
21. How Does a PCE Work with a Virtual Network Topology? ..........19
22. How Does PCE Communicate with VNTM ............................21
23. How Does Service Scheduling and Calendering Work? .............21
24. Where Does Policy Fit In? .....................................22
25. Does PCE Play a Role in SDN? ..................................23
26. Security Considerations .......................................23
27. References ....................................................25
27.1. Normative References .....................................25
27.2. Informative References ...................................25
Acknowledgements ..................................................29
Authors' Addresses ................................................29
Over the years since the architecture for the Path Computation Element (PCE) was documented in [RFC4655], many new people have become involved in the work of the PCE working group and wish to use or understand the PCE architecture. These people often missed out on early discussions within the working group and are unfamiliar with questions that were raised during the development of the documentation.
パス計算要素（PCE）のアーキテクチャが[RFC4655]で文書化されてから長年、多くの新しい人々がPCEワーキンググループの作業に参加し、PCEアーキテクチャの使用または理解を望んでいます。これらの人々は、ワーキンググループ内での初期の議論を見落としがちで、ドキュメントの作成中に出された質問に慣れていません。
Furthermore, the base architecture has been extended to handle other situations and requirements: the architecture was extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) [RFC5623] and was generalized to include Hierarchical PCE (H-PCE) [RFC6805].
さらに、他の状況や要件を処理するように基本アーキテクチャが拡張されました。仮想ネットワークトポロジマネージャー（VNTM）[RFC5623]の導入により、マルチレイヤーネットワーキング用にアーキテクチャが拡張され、階層PCE（H-PCEを含むように一般化されました。 ）[RFC6805]。
These three architectural views of PCE deliberately leave some key questions unanswered, especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF efforts.
これら3つのPCEのアーキテクチャビューは、特にアーキテクチャコンポーネント間の相互作用に関して、いくつかの重要な質問に意図的に回答していません。このドキュメントはそれらの質問を引き出し、他のアーキテクチャコンポーネント、既存のプロトコル、および最近のIETFの取り組みを参照しながら、アーキテクチャのコンテキストでそれらについて説明します。
This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function.
このドキュメントは、アーキテクチャドキュメントを更新せず、プロトコルまたはコンポーネントの使用方法を定義しません。ただし、アーキテクチャコンポーネントを組み合わせて高度なPCE機能を提供する方法を提案しています。
Readers are assumed to be thoroughly familiar with terminology defined in [RFC4655], [RFC4726], [RFC5440], [RFC5623], and [RFC6805]. More information about terms related to stateful PCE can be found in [STATEFUL-PCE].
読者は、[RFC4655]、[RFC4726]、[RFC5440]、[RFC5623]、および[RFC6805]で定義されている用語に精通していることを前提としています。ステートフルPCEに関連する用語の詳細については、[STATEFUL-PCE]を参照してください。
Throughout this document, the term "area" is used to refer equally to an OSPF area and an IS-IS level. It is assumed that the reader is able to map the small differences between these two use cases.
このドキュメント全体を通して、「エリア」という用語は、OSPFエリアとIS-ISレベルを同等に指すために使用されます。読者は、これら2つの使用例の小さな違いをマッピングできると想定されています。
[RFC4655] specifies that a PCE performs path computations based on a view of the available network resources and network topology. This information is collected into a Traffic Engineering Database (TED).
[RFC4655]は、PCEが使用可能なネットワークリソースとネットワークトポロジのビューに基づいてパス計算を実行することを指定します。この情報は、トラフィックエンジニアリングデータベース（TED）に収集されます。
However, [RFC4655] does not provide a detailed description of what information is present in the TED. It simply says that the TED "contains the topology and resource information of the domain." The precise information that needs to be held in a TED depends on the type of network and nature of the computation that has to be performed. As a basic minimum, the TED must contain the nodes and links that form the domain, and it must identify the connectivity in the domain.
ただし、[RFC4655]には、TEDに存在する情報の詳細は記載されていません。それは単に、TEDが「ドメインのトポロジーとリソース情報を含んでいる」と言います。 TEDに保持する必要がある正確な情報は、ネットワークのタイプと実行する必要がある計算の性質によって異なります。基本的に、TEDにはドメインを形成するノードとリンクが含まれている必要があり、ドメイン内の接続を識別する必要があります。
For most traffic-engineering needs (for example, MPLS Traffic Engineering - MPLS-TE), the TED would additionally contain a basic metric for each link and knowledge of the available (unallocated) resources on each link.
ほとんどのトラフィックエンジニアリングのニーズ（たとえば、MPLSトラフィックエンジニアリング-MPLS-TE）の場合、TEDには、各リンクの基本的なメトリックと、各リンクで利用可能な（割り当てられていない）リソースの情報が含まれます。
More advanced use cases might require that the TED contain additional data that represents qualitative information such as:
より高度なユースケースでは、TEDに次のような定性的な情報を表す追加のデータを含める必要がある場合があります。
- link delay - link jitter - node throughput capabilities - optical impairments - switching capabilities - limited node cross-connect capabilities
- リンク遅延-リンクジッタ-ノードスループット機能-光障害-スイッチング機能-制限されたノードクロスコネクト機能
Additionally, an important information element for computing paths, especially for protected services, is the Shared Risk Group (SRG). This is an indication of resources in the TED that have a common risk of failure. That is, they have a shared risk of failure from a single event.
さらに、パスの計算、特に保護されたサービスの重要な情報要素は、Shared Risk Group（SRG）です。これは、障害の一般的なリスクがあるTED内のリソースを示しています。つまり、1つのイベントで障害が発生するという共通のリスクがあります。
In short, the TED needs to contain as much information as is needed to satisfy the path computation requests subject to the objective functions (OFs). This, in itself, may not be a trivial issue in some network technologies. For example, in some optical networks, the path computation for a new Label Switched Path (LSP) may need to consider the impact that turning up a new laser would have on the optical signals already being carried by fibers. It may be possible to abstract this information as parameters of the optical links and nodes in the TED, but it may be easier to capture this information through a database of existing LSPs (see Sections 14 and 15).
つまり、TEDには、目的関数（OF）の対象となるパス計算要求を満たすために必要なだけの情報を含める必要があります。これ自体は、一部のネットワークテクノロジーではささいな問題ではない場合があります。たとえば、一部の光ネットワークでは、新しいラベルスイッチドパス（LSP）のパス計算で、新しいレーザーを立ち上げることが、ファイバーによって既に伝送されている光信号に与える影響を考慮する必要がある場合があります。この情報をTEDの光リンクとノードのパラメータとして抽象化することは可能ですが、既存のLSPのデータベースを介してこの情報を取得する方が簡単な場合があります（セクション14および15を参照）。
Clearly, the information in the TED discussed in Section 2 needs to be gathered and maintained somehow. [RFC4655] simply says "The TED may be fed by Interior Gateway Protocol (IGP) extensions or potentially by other means." In this context, "fed" means built and maintained.
明らかに、セクション2で説明したTEDの情報は、何らかの方法で収集および維持する必要があります。 [RFC4655]は単に「TEDはInterior Gateway Protocol（IGP）拡張によって、または他の手段によって供給される可能性がある」と述べています。この文脈では、「供給」は構築され、維持されることを意味します。
Thus, one way that the PCE may construct its TED is by participating in the IGP running in the network. In an MPLS-TE network, this would depend on OSPF TE [RFC3630] and IS-IS TE [RFC5305]. In a GMPLS network, it would utilize the GMPLS extensions to OSPF and IS-IS, [RFC4203] and [RFC5307].
したがって、PCEがTEDを構築する方法の1つは、ネットワークで実行されているIGPに参加することです。 MPLS-TEネットワークでは、これはOSPF TE [RFC3630]とIS-IS TE [RFC5305]に依存します。 GMPLSネットワークでは、OSPFおよびIS-IS、[RFC4203]および[RFC5307]へのGMPLS拡張を利用します。
However, participating in an IGP, even as a passive receiver of IGP information, can place a significant load on the PCE. The IGP can be quite "chatty" when there are frequent updates to the use of the network, meaning that the PCE must dedicate significant processing to parsing protocol messages and updating the TED. Furthermore, to be truly useful, a PCE implementation would need to support OSPF and IS-IS.
ただし、IGP情報のパッシブレシーバーとしてもIGPに参加すると、PCEに大きな負荷がかかる可能性があります。 IGPは、ネットワークの使用が頻繁に更新される場合、かなり「おしゃべり」になる可能性があります。つまり、PCEはプロトコルメッセージの解析とTEDの更新に重要な処理を費やす必要があります。さらに、PCE実装が本当に役立つためには、OSPFとIS-ISをサポートする必要があります。
An alternative feed from the network to the PCE's TED is offered by BGP-LS [LS-DISTRIB]. This approach offers the alternative of leveraging an in-network BGP speaker (such as an Autonomous System Border Router or a Route Reflector) that already has to participate in the IGP and that is specifically designed to apply filters to IGP advertisements. In this usage, the BGP speaker filters and aggregates topology information according to configured policy before advertising it "north-bound" to the PCE to update the TED. The PCE implementation has to support just a simplified subset of BGP rather than two full IGPs.
ネットワークからPCEのTEDへの代替フィードは、BGP-LS [LS-DISTRIB]によって提供されます。このアプローチは、すでにIGPに参加する必要があり、IGPアドバタイズメントにフィルターを適用するように特別に設計された、ネットワーク内のBGPスピーカー（自律システムボーダールーターやルートリフレクターなど）を利用する代替手段を提供します。この使用法では、BGPスピーカーは、構成されたポリシーに従ってトポロジ情報をフィルタリングおよび集約してから、それをPCEに「ノースバウンド」でアドバタイズして、TEDを更新します。 PCE実装は、2つの完全なIGPではなく、単純化されたBGPのサブセットのみをサポートする必要があります。
But BGP might not be convenient in all networks (for example, where BGP is not run, such as in an optical network or a BGP-free core). Furthermore, not all relevant information is made available through standard TE extensions to the IGPs. In these cases, the TED must be built or supplemented from other sources such as the Network Management System (NMS), inventory management systems, and directly configured data.
ただし、BGPはすべてのネットワークで便利ではない場合があります（たとえば、光ネットワークやBGPフリーコアなど、BGPが実行されていない場合）。さらに、IGPへの標準TE拡張機能を介してすべての関連情報を利用できるわけではありません。これらの場合、TEDは、ネットワーク管理システム（NMS）、在庫管理システム、直接構成されたデータなどの他のソースから構築または補足する必要があります。
It has also been proposed that the PCE Communication Protocol (PCEP) [RFC5440] could be extended to serve as an information collection protocol to supply information from network devices to a PCE. The logic is that the network devices may already speak PCEP; so, the protocol could easily be used to report details about the resources and state in the network, including the LSP state discussed in Sections 14 and 15.
PCE通信プロトコル（PCEP）[RFC5440]を拡張して、ネットワークデバイスからPCEに情報を提供する情報収集プロトコルとして機能させることも提案されています。論理は、ネットワークデバイスがすでにPCEPを話している可能性があるということです。そのため、このプロトコルは、セクション14および15で説明したLSP状態を含む、ネットワーク内のリソースと状態に関する詳細を報告するために簡単に使用できます。
Note that a PCE that is responsible for more than one domain must, of course, collect TE information from each domain to build its TED or TEDs.
もちろん、複数のドメインを担当するPCEは、TEDを構築するために各ドメインからTE情報を収集する必要があります。
A Path Computation Client (PCC) needs to know the identity/location of a PCE in order to be able to make computation requests. This is because PCEP is a transaction-based protocol carried over TCP, and the architectural decision made in Section 6.4 of RFC 4655 required targeted PCC-PCE communications.
パス計算クライアント（PCC）は、計算要求を行うことができるようにするために、PCEのID /場所を知っている必要があります。これは、PCEPがTCPを介して実行されるトランザクションベースのプロトコルであり、RFC 4655のセクション6.4で行われたアーキテクチャ上の決定により、対象を絞ったPCC-PCE通信が必要になったためです。
As described in [RFC4655], a PCC could be configured with the knowledge of the IP address of its PCE. This is a relatively lightweight option considering all of the other configuration that a router may require, but it is open to configuration errors, and does not meet the need for minimal-configuration operation. Furthermore, configuration communication with multiple PCEs could become onerous, while handling changes in PCE identities and coping with failure events would be an issue for a configured system.
[RFC4655]で説明されているように、PCCはそのPCEのIPアドレスの知識で構成できます。これは、ルーターが必要とする可能性のある他のすべての構成を考慮すると比較的軽量なオプションですが、構成エラーが発生する可能性があり、最小限の構成操作の必要性を満たしていません。さらに、複数のPCEとの構成通信は面倒になる可能性がありますが、PCE IDの変更の処理と障害イベントへの対処は、構成されたシステムの問題になります。
[RFC4655] offers the possibility for PCEs to advertise themselves in the IGP, and this requirement is developed in [RFC4674] and made possible in OSPF and IS-IS through [RFC5088] and [RFC5089]. In general, these mechanisms should be sufficient for PCCs in a network where an IGP is used and where the PCE participates in the IGP.
[RFC4655]は、PCEがIGPで自身をアドバタイズする可能性を提供します。この要件は[RFC4674]で開発され、OSPFおよびIS-ISで[RFC5088]および[RFC5089]を介して可能になります。一般に、これらのメカニズムは、IGPが使用され、PCEがIGPに参加するネットワーク内のPCCには十分なはずです。
Note, however, that not all PCEs will participate in the IGP (see Section 3). In these cases, assuming configuration is not appropriate as a discovery mechanism, some other server announcement/discovery function may be needed, such as DNS [RFC4848] as used for discovery of the Local Location Information Server (LIS) [RFC5986] and in the Application-Layer Traffic Optimization (ALTO) discovery function [ALTO-SERVER-DISC].
ただし、すべてのPCEがIGPに参加するわけではないことに注意してください（セクション3を参照）。これらの場合、構成が検出メカニズムとして適切ではないと想定すると、ローカルロケーション情報サーバー（LIS）[RFC5986]の検出に使用されるDNS [RFC4848]やその他のサーバーのアナウンス/検出機能が必要になる場合があります。アプリケーション層トラフィック最適化（ALTO）検出機能[ALTO-SERVER-DISC]。
When more than one PCE is discovered or configured, a PCC will need to select which PCE to use. It may make this decision on any arbitrary algorithm (for example, first-listed, or round robin), but it may also be the case that different PCEs have different capabilities and path computation scope; in which case, the PCC will want to select the PCE most likely to be able to satisfy any one request. The first requirement, of course, is that the PCE can compute paths for the relevant domain.
複数のPCEが検出または構成される場合、PCCは使用するPCEを選択する必要があります。任意のアルゴリズム（たとえば、最初にリストされた、またはラウンドロビン）でこの決定を行う可能性がありますが、異なるPCEが異なる機能とパス計算スコープを持つ場合もあります。その場合、PCCは、1つの要求を満たすことができる可能性が最も高いPCEを選択する必要があります。もちろん、最初の要件は、PCEが関連ドメインのパスを計算できることです。
PCE advertisement in OSPF or IS-IS per [RFC5088] and [RFC5089] allows a PCE to announce its capabilities as required in [RFC4657]. A PCC can select between PCEs based on the capabilities that they have announced. However, these capabilities are expressed as flags in the PCE advertisement so only the core capabilities are presented, and there is not scope for including detailed information (such as support for specific objective functions) in the advertisement.
[RFC5088]および[RFC5089]に準拠したOSPFまたはIS-ISでのPCEアドバタイズメントにより、PCEは[RFC4657]で必要とされる機能を発表できます。 PCCは、発表した機能に基づいてPCEを選択できます。ただし、これらの機能はPCEアドバタイズメントではフラグとして表現されるため、コア機能のみが示され、アドバタイズメントに詳細情報（特定の目的関数のサポートなど）を含める余地はありません。
Additional and more complex PCE capabilities, including the capability to perform point-to-multipoint (P2MP) path computations [RFC6006], may be announced by the PCE as optional PCEP type-length-value (TLV) Type Indicators in the Open message described in [RFC5440]. This mechanism is not limited to just a set of flags, and detailed capability information may be presented in sub-TLVs.
ポイントツーマルチポイント（P2MP）パス計算を実行する機能[RFC6006]を含む、追加のより複雑なPCE機能は、説明されているOpenメッセージ内のオプションのPCEP type-length-value（TLV）タイプインジケーターとしてPCEによって発表される場合があります。 [RFC5440]。このメカニズムはフラグのセットだけに限定されず、詳細な機能情報がサブTLVで提示される場合があります。
Note that this exchange of PCE capabilities is in the form of an announcement, not a negotiation. That is, a PCC that wants specific function from a PCE must examine the advertised capabilities and select which PCE to use for a specific request. There is no scope for a PCC to request a PCE to support features or functions that it does not offer or announce.
このPCE機能の交換は、交渉ではなく、アナウンスの形式であることに注意してください。つまり、PCEから特定の機能を必要とするPCCは、アドバタイズされた機能を調べて、特定の要求に使用するPCEを選択する必要があります。 PCCが提供または発表していない機能をサポートするようにPCCに要求する範囲はありません。
A PCC may also vary which PCE it uses according to congestion information reported by the PCEs using the Notification Object and Notification Type [RFC5440]. In a heavily overloaded PCE system, note that reports from one PCE that it is overloaded may simply result in all PCCs switching to another PCE, which will, itself, immediately become overloaded. Thus, PCCs should exercise a certain amount of discretion and queueing theory before selecting a PCE purely based on reported load.
PCCは、通知オブジェクトと通知タイプ[RFC5440]を使用してPCEによって報告された輻輳情報に応じて、使用するPCEを変えることもできます。非常に過負荷のPCEシステムでは、1つのPCEからの過負荷のレポートは、すべてのPCCが別のPCEに切り替わるだけで、すぐに過負荷になることに注意してください。したがって、PCCは、報告された負荷に純粋に基づいてPCEを選択する前に、ある程度の裁量権と待ち行列理論を実行する必要があります。
Note that a PCC could send all requests to all PCEs that it knows about. It can then select between the results, perhaps choosing the first result it receives, but this approach is very likely to overload all the PCEs in the network considering that one of the reasons for multiple PCEs is to share the load.
PCCは、認識しているすべてのPCEにすべての要求を送信できることに注意してください。その後、結果の中から選択し、おそらく最初に受け取った結果を選択しますが、このアプローチは、複数のPCEの理由の1つが負荷を共有することであることを考えると、ネットワーク内のすべてのPCEに過負荷をかける可能性が非常に高くなります。
A network may have more than one PCE, as discussed in the previous sections. These PCEs may provide redundancy for load-sharing, resilience, or partitioning of computation features.
前のセクションで説明したように、ネットワークには複数のPCEがある場合があります。これらのPCEは、負荷分散、回復力、または計算機能の分割に冗長性を提供します。
In order to achieve some consistency between the results of different PCEs, it is desirable that they operate on the same TE information.
異なるPCEの結果間の一貫性を実現するために、それらは同じTE情報で動作することが望ましいです。
The TED reflects the actual state of the network and is not a resource reservation or booking scheme. Therefore, a PCE-based system does not prevent competition for network resources during the provisioning phase, although a process of "sticky resources" that are temporarily reduced in the TED after a computation may be applied purely as a local implementation feature.
TEDはネットワークの実際の状態を反映しており、リソースの予約または予約スキームではありません。したがって、PCEベースのシステムは、プロビジョニングフェーズ中にネットワークリソースの競合を防止しませんが、計算後にTEDで一時的に削減される「スティッキーリソース」のプロセスは、純粋にローカル実装機能として適用できます。
One option for ensuring that multiple PCEs use the same TE information is simply to have the PCEs driven from the same TED. This could be achieved in implementations by utilizing a shared database, but it is unlikely to be efficient.
複数のPCEが同じTE情報を確実に使用するための1つのオプションは、PCEを同じTEDから駆動させることです。これは、実装で共有データベースを利用することで実現できますが、効率的ではありません。
More likely is that each PCE is responsible for building its own TED independently, using the techniques described in Section 3. If the PCEs participate in the IGP, it is likely that they will attach at different points in the network; so, there may be minor and temporary inconsistencies between their TEDs caused by IGP convergence issues. If the PCEs gather TE information via BGP-LS [LS-DISTRIB] from different sources, the same inconsistencies may arise. However, if the PCEs attach to the same BGP speaker, it may be possible to achieve consistency between TEDs modulo the BGP-LS process itself.
より可能性が高いのは、セクション3で説明されている手法を使用して、各PCEが独自のTEDを個別に構築することです。PCEがIGPに参加している場合、ネットワークの異なるポイントに接続する可能性があります。そのため、IGPのコンバージェンスの問題が原因で、TED間でマイナーな一時的な不整合が発生する可能性があります。 PCEが異なるソースからBGP-LS [LS-DISTRIB]を介してTE情報を収集する場合、同じ不整合が発生する可能性があります。ただし、PCEが同じBGPスピーカーに接続している場合、BGP-LSプロセス自体を法とするTED間の一貫性を実現できる可能性があります。
A final option is to provide an explicit synchronization process between the TED of a "master" PCE and the TEDs of other PCEs. Such a process could be achieved using BGP-LS or a database synchronization protocol (which would allow check-pointing and sequential updates). This approach is fraught with issues around selection of the master PCE and handling failures. It is, in fact, a mirrored database scenario: a problem that is well known and the subject of plenty of work.
最後のオプションは、「マスター」PCEのTEDと他のPCEのTEDとの間に明示的な同期プロセスを提供することです。このようなプロセスは、BGP-LSまたはデータベース同期プロトコル（チェックポイントと順次更新を可能にする）を使用して実現できます。このアプローチには、マスターPCEの選択と障害の処理に関する問題がたくさんあります。実際、これはミラーリングされたデータベースのシナリオです。よく知られている問題であり、多くの作業の対象となっています。
Noting that the provisioning protocols such as RSVP-TE [RFC3209] already handle contention for resources, that the differences between TEDs are likely to be relatively small with moderate arrival rates for new services, and that contention in all but the most busy networks is relatively unlikely, there may be no value in any attempt to synchronize TEDs between PCEs.
RSVP-TE [RFC3209]などのプロビジョニングプロトコルはリソースの競合をすでに処理していることに注意してください。TED間の差は比較的小さく、新しいサービスの到着率は中程度であり、最もビジーなネットワーク以外のすべての競合は比較的ありそうもないことですが、PCE間でTEDを同期する試みに価値がない場合があります。
However, see Section 16 for a discussion of synchronizing other state between redundant PCEs.
ただし、冗長PCE間の他の状態の同期については、セクション16を参照してください。
Path computation provides an end-to-end path between a source and a destination. If the destination lies in the source domain, then its location will be known to the PCE and there are no issues to be solved. However, in a multi-domain system a path must be found to a remote domain that contains the destination, and that can only be achieved by knowledge of the location of the destination or at least knowing the next domain in the path toward the domain that contains the destination.
パス計算は、送信元と宛先の間のエンドツーエンドのパスを提供します。宛先がソースドメインにある場合、その場所はPCEに認識され、解決すべき問題はありません。ただし、マルチドメインシステムでは、宛先を含むリモートドメインへのパスを見つける必要があります。これは、宛先の場所を知っているか、少なくとも、ドメインへのパス内の次のドメインを知っていることによってのみ達成できます。宛先が含まれています。
The simplest solution here is achieved when a PCE has visibility into multiple domains. Such may be the case in a multi-area network where the PCE is aware of the contents of all of the IGP areas. This approach is only likely to be appropriate where the number of nodes is manageable, and it is unlikely to extend over administrative boundaries.
ここで最も簡単なソリューションは、PCEが複数のドメインを表示できる場合に実現されます。これは、PCEがすべてのIGPエリアのコンテンツを認識しているマルチエリアネットワークの場合です。このアプローチは、ノードの数が管理可能な場合にのみ適切である可能性が高く、管理の境界を越えて拡張することはほとんどありません。
The per-domain path computation method for establishing inter-domain traffic engineering LSPs [RFC5152] simply requires a PCE to compute a path to the next domain toward the destination. As the LSP setup (through signaling) progresses domain by domain, the Label Switching Router (LSR) at the entry point to each domain requests its local PCE to compute the next segment of the path, that is from that LSR to the next domain in the sequence toward the destination. Thus, it is not necessary for any PCE (except the last) to know in which domain the destination exists. But, in this approach, each PCE must somehow determine the next domain toward the destination, and it is not obvious how this is achieved.
ドメイン間トラフィックエンジニアリングLSP [RFC5152]を確立するためのドメインごとのパス計算方法は、PCEが宛先に向かう次のドメインへのパスを計算することを要求するだけです。 LSPセットアップ（シグナリングを介して）がドメインごとに進行すると、各ドメインへのエントリポイントにあるラベルスイッチングルーター（LSR）は、ローカルPCEにパスの次のセグメント、つまりそのLSRから次のドメインへの計算を要求します。目的地へのシーケンス。したがって、PCE（最後を除く）が宛先がどのドメインに存在するかを知る必要はありません。しかし、このアプローチでは、各PCEが何らかの方法で宛先に向かう次のドメインを決定する必要があり、これがどのように達成されるかは明らかではありません。
[RFC5152] suggests that, in an IP/MPLS network, it is good enough to leverage the IP reachability information distributed by BGP and assume that TE reachability can follow the same Autonomous System (AS) path. This approach might not guarantee the optimal TE path and, of course, might result in no path being found in degenerate cases. Furthermore, in many network technologies (such as optical networks operated by GMPLS) there may be limited or no end-to-end IP connectivity.
[RFC5152]は、IP / MPLSネットワークでは、BGPによって配布されたIP到達可能性情報を活用し、TE到達可能性が同じ自律システム（AS）パスをたどることができると想定することで十分であることを示唆しています。このアプローチでは、最適なTEパスが保証されない場合があります。もちろん、縮退した場合にパスが見つからない場合があります。さらに、多くのネットワーク技術（GMPLSで運用される光ネットワークなど）では、エンドツーエンドのIP接続が制限されているか、まったくない場合があります。
The Backward Recursive PCE-based Computation (BRPC) procedure [RFC5441] is able to achieve a more optimal end-to-end path than the per-domain method, but depends on the knowledge of both the domain in which the destination is located and the sequence of domains toward the destination. This information is described in [RFC5441] as being known a priori. Clearly, however, information is not always known a priori, and it may be hard for the PCE that serves the source PCC to discover the necessary details. While there are several approaches to solving the question of establishing the domain sequence (for example, BRPC trial and error or H-PCE [RFC6805]), none of them addresses the issue of determining where the destination lies.
後方再帰PCEベースの計算（BRPC）プロシージャ[RFC5441]は、ドメイン単位の方法よりも最適なエンドツーエンドパスを実現できますが、宛先が配置されているドメインと、宛先に向かうドメインのシーケンス。この情報は[RFC5441]でアプリオリに知られていると説明されています。ただし、明らかに、情報が常にアプリオリに知られているわけではなく、ソースPCCを提供するPCEが必要な詳細を発見するのが難しい場合があります。ドメインシーケンスの確立に関する問題を解決する方法はいくつかありますが（たとえば、BRPCの試行錯誤やH-PCE [RFC6805]）、宛先がどこにあるかを特定するという問題には対処していません。
One argument that is often made is that an end-to-end connection expressed as an LSP is a feature of a service agreement between source and destination. If that is the case, it is argued, it stands to reason that the location of the destination must be known to the source node in the same way that the source has determined the IP address of the destination. Presumably, this would be through a commercial process or an administrative protocol.
LSPとして表されるエンドツーエンド接続は、送信元と宛先の間のサービス契約の機能であるとよく言われます。それが事実である場合、それは議論されます、それは、送信元が送信先のIPアドレスを決定したのと同じ方法で送信先ノードの場所が送信元ノードに知られている必要があることを正当化します。おそらく、これは商用プロセスまたは管理プロトコルによるものでしょう。
[RFC4974] introduced the concept of Calls and Connections for LSPs. A Call does not provide the actual connectivity for transmitting user traffic, but builds a relationship that will allow subsequent Connections to be made. A Call might be considered an agreement to support an end-to-end LSP that is made between the endpoint nodes. Call messages are sent and routed as normal IP messages, so the sender does not need to know the location of the destination.
[RFC4974]は、LSPの呼び出しと接続の概念を導入しました。呼び出しは、ユーザートラフィックを送信するための実際の接続を提供しませんが、その後の接続を確立できるようにする関係を構築します。コールは、エンドポイントノード間で行われるエンドツーエンドLSPをサポートするための合意と見なされる場合があります。呼び出しメッセージは通常のIPメッセージとして送信およびルーティングされるため、送信者は宛先の場所を知る必要がありません。
Furthermore, Call requests are responded, and the Call Response can carry information (such as the identity of the domain containing the destination) for use by Call initiator. Thus, the use of GMPLS Calls might provide a mechanism to discover destination's location.
さらに、呼び出し要求が応答され、呼び出し応答は、呼び出しの開始者が使用する情報（宛先を含むドメインのIDなど）を運ぶことができます。したがって、GMPLS呼び出しを使用すると、宛先の場所を検出するメカニズムが提供される場合があります。
A parent PCE [RFC6805] is responsible for selecting inter-domain path by coordinating with child PCEs and maintaining a domain topology map.
親PCE [RFC6805]は、子PCEと調整してドメイントポロジマップを維持することにより、ドメイン間パスを選択します。
In the case of multi-domains (e.g., IGP areas or multiple ASes) within a single service provider network, the management responsibility for the parent PCE would most likely be handled by the service provider.
単一のサービスプロバイダーネットワーク内のマルチドメイン（IGPエリアや複数のASなど）の場合、親PCEの管理責任は、ほとんどの場合サービスプロバイダーによって処理されます。
In the case of multiple ASes within different service provider networks, it may be necessary for a third party to manage the parent PCEs according to commercial and policy agreements from each of the participating service providers. Note that the H-PCE architecture does not require disclosure of internals of a child domain to the parent PCE. Thus, there is ample scope for a parent PCE to be run by one of the connected service providers or by a third party without compromising commercial issues. In fact, each service provider could run its own parent PCE while allowing its child PCEs to be contacted by outsider parent PCEs according to configured policy and security.
異なるサービスプロバイダーネットワーク内の複数のASの場合、サードパーティが、参加している各サービスプロバイダーからの商業契約およびポリシー契約に従って親PCEを管理する必要がある場合があります。 H-PCEアーキテクチャでは、子ドメインの内部を親PCEに開示する必要がないことに注意してください。したがって、商業上の問題を犠牲にすることなく、接続されたサービスプロバイダーの1つまたはサードパーティが親PCEを実行できる十分な範囲があります。実際、各サービスプロバイダーは、独自の親PCEを実行しながら、構成されたポリシーとセキュリティに従って、その子PCEが外部の親PCEからアクセスできるようにすることができます。
[RFC6805] specifies that a child PCE must be configured with the address of its parent PCE in order for it to interact with its parent PCE. There is no scope for parent PCEs to advertise their presence; however, there is potential for directory systems (such as DNS [RFC4848] as used in the ALTO discovery function [ALTO-SERVER-DISC]) to be used as described in Section 4.
[RFC6805]は、子PCEがその親PCEと対話するために、その親PCEのアドレスを使用して構成する必要があることを指定しています。親PCEがその存在をアドバタイズするための範囲はありません。ただし、セクション4で説明されているように、ディレクトリシステム（ALTO検出機能[ALTO-SERVER-DISC]で使用されるDNS [RFC4848]など）が使用される可能性があります。
According to [RFC6805], note that the child PCE must also be authorized to peer with the parent PCE. This is discussed from the viewpoint of the parent PCE in Section 10. The child PCE may need to participate in a key distribution protocol in order to properly authenticate its identity to the parent PCE.
[RFC6805]によれば、子PCEは親PCEとのピアリングも許可されている必要があることに注意してください。これについては、セクション10で親PCEの観点から説明します。子PCEは、親PCEに対してIDを適切に認証するために、鍵配布プロトコルに参加する必要がある場合があります。
Within the hierarchical PCE framework [RFC6805], the parent PCE must only accept path computation requests from authorized child PCEs. If a parent PCE receives a request from an unauthorized child PCE, the request should be dropped.
階層PCEフレームワーク[RFC6805]内では、親PCEは、承認された子PCEからのパス計算要求のみを受け入れる必要があります。親PCEが無許可の子PCEから要求を受け取った場合、その要求はドロップする必要があります。
This requires a parent PCE to be configured with the identities and security credentials of all of its child PCEs, or there must be some form of shared secret that allows an unknown child PCE to be authorized by the parent PCE.
これには、親PCEがそのすべての子PCEのIDとセキュリティ資格情報で構成されている必要があります。または、不明な子PCEが親PCEによって承認されるようにする何らかの形式の共有シークレットが必要です。
The parent PCE maintains a domain topology map of the child domains and their interconnectivity. This map does not include any visibility into the child domains. Where inter-domain connectivity is provided by TE links, the capabilities of those links may also be known to the parent PCE.
親PCEは、子ドメインとその相互接続のドメイントポロジマップを保持します。このマップには、子ドメインへの可視性は含まれていません。ドメイン間接続がTEリンクによって提供される場合、それらのリンクの機能は親PCEにも認識される場合があります。
The parent PCE maintains a TED for the parent domain in the same way that any PCE does. The nodes in the parent domain will be abstractions of the child domains (connected by real or virtual TE links), but the parent domain may also include real nodes and links.
親PCEは、PCEと同じ方法で親ドメインのTEDを維持します。親ドメイン内のノードは、子ドメインの抽象化（実際のまたは仮想TEリンクによって接続される）になりますが、親ドメインには実際のノードとリンクが含まれる場合もあります。
The mechanism for building the parent TED is likely to rely heavily on administrative configuration and commercial issues because the network was probably partitioned into domains specifically to address these issues. However, note that in some configurations (for example, collections of small optical domains) a separate instance of a routing protocol (probably an IGP) may be run within the parent domain to advertise the domain interconnectivity. Additionally, since inter-domain TE links can be advertised by the IGPs operating in the child domains, this information could be exported to the parent PCE either by the child PCEs or using a north-bound export mechanism such as BGP-LS [LS-DISTRIB].
親のTEDを構築するメカニズムは、ネットワークがおそらくこれらの問題に対処するためにドメインに分割されている可能性があるため、管理構成と商業上の問題に大きく依存する可能性があります。ただし、一部の構成（たとえば、小さな光ドメインのコレクション）では、親ドメイン内でルーティングプロトコル（おそらくIGP）の個別のインスタンスを実行して、ドメインの相互接続をアドバタイズする場合があることに注意してください。さらに、ドメイン間TEリンクは子ドメインで動作しているIGPによってアドバタイズできるため、この情報は、子PCEによって、またはBGP-LS [LS-LSなどのノースバウンドエクスポートメカニズムを使用して、親PCEにエクスポートできます。 DISTRIB]。
The model described in [RFC6805] introduced a hierarchical relationship between domains. It is applicable to environments with small groups of domains where visibility from the ingress LSRs is limited. Applying the hierarchical PCE model to large groups of domains such as the Internet is not considered feasible or desirable.
[RFC6805]で説明されているモデルは、ドメイン間の階層関係を導入しました。これは、入力LSRからの可視性が制限されているドメインの小さなグループを持つ環境に適用できます。階層型PCEモデルをインターネットなどのドメインの大きなグループに適用することは、実現可能または望ましいとは見なされていません。
This does open up a harder question: how many domains can be handled by an H-PCE system? In other words: what is a small group of domains? The answer is not clear and might be "I know it when I see it." At the moment, a rough guide might be around 20 domains as a maximum.
これはより難しい質問を開きます：H-PCEシステムで処理できるドメインの数は？言い換えると、ドメインの小さなグループとは何ですか？答えは明確ではなく、「見ればわかる」のかもしれません。現在のところ、おおよその目安は最大20ドメイン程度です。
An associated question would be: how many hierarchy levels can be handled by H-PCE? Architecturally, the answer is that there is no limit, but it is hard to construct practical examples where more than two or possibly three levels are needed.
関連する質問は次のとおりです。H-PCEで処理できる階層レベルはいくつですか。構造的には、制限はないという答えがありますが、2つ以上、場合によっては3つ以上のレベルが必要な実際的な例を構築することは困難です。
When a PCE computes a path, it has a reasonable idea that an LSP will be set up and that resources will be allocated within the network. If the arrival rate of computation requests is faster than the LSP setup rate combined with the IGP convergence time, it is quite possible that the PCE will perform its next computation before the TED has been updated to reflect the setup of the previous LSP. This can result in LSP setup failures if there is contention for resources. The likelihood of this problem is particularly high during recovery from network failures when a large number of LSPs might need new paths.
PCEがパスを計算するとき、LSPがセットアップされ、リソースがネットワーク内で割り当てられるというのは合理的な考えです。計算要求の到着率がISPコンバージェンス時間と組み合わせたLSPセットアップレートよりも速い場合、TEDが更新されて前のLSPのセットアップが反映される前に、PCEが次の計算を実行する可能性があります。これにより、リソースの競合がある場合、LSPセットアップが失敗する可能性があります。この問題の可能性は、多数のLSPが新しいパスを必要とする可能性があるネットワーク障害からの回復時に特に高くなります。
A PCE may choose to make a provisional assignment of the resources that would be needed for an LSP and to reduce the available resources in its TED so that the problem is mitigated. Such resources are informally known as "sticky resources".
PCEは、LSPに必要なリソースを暫定的に割り当て、問題の緩和のためにTEDで使用可能なリソースを減らすことを選択できます。このようなリソースは、非公式に「スティッキーリソース」と呼ばれます。
Note that using sticky resources introduces a number of other problems that can make managing the TED difficult. For example:
スティッキーリソースを使用すると、TEDの管理を困難にする可能性のある他の多くの問題が発生することに注意してください。例えば：
- When the TED is updated as a result of new information from the IGP, how does the PCE know whether the reduction in available resources is due to the successful setup of the LSP for which it is holding sticky resources or due to some other network event (such as the setup of another LSP)? This problem may be particularly evident if there are multiple PCEs that do not synchronize their sticky resources or if not all LSPs utilize PCE computation.
- IGPからの新しい情報の結果としてTEDが更新されると、PCEは、利用可能なリソースの減少が、スティッキリソースを保持しているLSPのセットアップが成功したためか、その他のネットワークイベント（別のLSPのセットアップなど）？この問題は、スティッキーリソースを同期しないPCEが複数ある場合、またはすべてのLSPがPCE計算を利用するわけではない場合に特に顕著になります。
- When LSP setup fails, how are the sticky resources released? Since the PCE doesn't know about the failure of the LSP setup, it needs some other mechanism to release them.
- LSPセットアップが失敗した場合、スティッキーリソースはどのようにリリースされますか？ PCEはLSPセットアップの失敗を認識しないため、それらを解放するために他のメカニズムが必要です。
- What happens if a path computation was made only to investigate the potential for an LSP but not to actually set one up?
- パス計算がLSPの可能性を調査するためだけに行われ、実際に設定するために行われなかった場合はどうなりますか？
- What if the path used by the LSP does not match that provided by the PCE (for example, because the control plane routes around some problem)?
- LSPが使用するパスがPCEが提供するパスと一致しない場合（たとえば、コントロールプレーンが何らかの問題を迂回するため）
Some of these issues can be mitigated by using a Stateful PCE (see Section 14) or by timers.
これらの問題の一部は、ステートフルPCE（セクション14を参照）またはタイマーを使用することで軽減できます。
A Stateless PCE can perform path computations that take into account the existence of other LSPs if the paths of those LSPs are supplied on the computation request. This function can be particularly useful when arranging protection paths so that a working and protection LSP do not share any links or nodes. It can also be used when a group of LSPs are to be reoptimized at the same time in the process known as Global Concurrent Optimization (GCO) [RFC5557].
ステートレスPCEは、他のLSPのパスが計算要求で提供されている場合、他のLSPの存在を考慮したパス計算を実行できます。この機能は、現用および保護LSPがリンクまたはノードを共有しないように保護パスを配置する場合に特に役立ちます。また、LSPのグループがグローバル同時最適化（GCO）[RFC5557]と呼ばれるプロセスで同時に再最適化される場合にも使用できます。
However, this mechanism can be quite a burden on the protocol messages, especially when large numbers of LSP paths need to be reported.
ただし、このメカニズムは、特に大量のLSPパスを報告する必要がある場合、プロトコルメッセージにかなりの負担になる可能性があります。
A Stateful PCE [STATEFUL-PCE] maintains a database of LSPs (the LSP-DB) that are active in the network, i.e., have been provisioned such that they use network resources although they might or might not be carrying traffic. This database allows a PCC to refer to an LSP using only its identifier -- all other details can be retrieved by the PCE from the LSP-DB.
ステートフルPCE [STATEFUL-PCE]は、ネットワークでアクティブなLSPのデータベース（LSP-DB）を維持します。つまり、トラフィックを伝送する場合としない場合でもネットワークリソースを使用するようにプロビジョニングされています。このデータベースにより、PCCはその識別子のみを使用してLSPを参照できます。他のすべての詳細は、PCEがLSP-DBから取得できます。
A Stateful PCE can use the LSP-DB for many other functions, such as balancing the distribution of LSPs in the network. Furthermore, the PCE can correlate LSPs with network resource availability placing new LSPs more cleverly.
ステートフルPCEは、LSP-DBを使用して、ネットワーク内のLSPの分散バランスなど、他の多くの機能を実行できます。さらに、PCEはLSPをネットワークリソースの可用性と関連付けて、新しいLSPをより巧妙に配置できます。
A Stateful PCE that is also an Active PCE (see Section 17) can respond to changes in network resource availability and predicted demands to reroute LSPs that it knows about.
アクティブPCE（セクション17を参照）でもあるステートフルPCEは、ネットワークリソースの可用性の変化と、それが知っているLSPを再ルーティングするための予測された要求に応答できます。
Section 20 offers a brief comparison of the different modes of PCE with reference to stateful and stateless PCE.
セクション20では、ステートフルPCEとステートレスPCEを参照して、PCEのさまざまなモードを簡単に比較します。
The LSP-DB contains information about the LSPs that are active in the network, as mentioned in Section 14. This state information can be constructed by the PCE from information it receives from a number of sources including from provisioning tools and from the network, but no matter how the information is gleaned, a Stateful PCE needs to synchronize its LSP-DB with the state in the network. Just as described in Section 13, the PCE cannot rely on knowledge about previous computations it has made, but it must find out the actual LSPs in the network.
セクション14で説明したように、LSP-DBには、ネットワークでアクティブなLSPに関する情報が含まれています。この状態情報は、PCEがプロビジョニングツールやネットワークからなど、いくつかのソースから受け取った情報から構築できますが、情報をどのように収集しても、ステートフルPCEはLSP-DBをネットワークの状態と同期させる必要があります。セクション13で説明したように、PCEは以前に行った計算に関する知識に依存できませんが、ネットワーク内の実際のLSPを見つける必要があります。
A simple solution is for all ingress LSRs to report all LSPs to the PCE as they are set up, modified, or torn down. Since PCEP already has the facility to fully describe LSP routes and resources in the protocol messages, this is not a difficult problem, and the LSP State Report (PCRpt) message has been defined for this purpose [STATEFUL-PCE].
簡単な解決策は、すべての入力LSRが、セットアップ、変更、または破棄されたときに、すべてのLSPをPCEに報告することです。 PCEPにはすでにプロトコルメッセージでLSPルートとリソースを完全に記述する機能があるため、これは難しい問題ではなく、LSP状態レポート（PCRpt）メッセージがこの目的で定義されています[STATEFUL-PCE]。
The situation can be more complex, however, if there are ingress LSRs that do not support PCEP, support PCEP but not the PCRpt, or that are unaware of the requirement to report LSPs to the PCE. This might happen if the LSRs are able to compute paths themselves or if they receive LSP setup instructions with pre-computed paths from an NMS.
ただし、PCEPをサポートしていない、PCEPをサポートしているがPCRptをサポートしていない、またはLSPをPCEに報告する要件を認識していない入力LSRがある場合、状況はさらに複雑になる可能性があります。これは、LSRがパス自体を計算できる場合、またはNMSから事前に計算されたパスを含むLSPセットアップ命令を受け取った場合に発生する可能性があります。
An alternative approach is to note that any LSR on the path of an LSP can probably see the whole path (through the Record Route object in RSVP-TE signaling [RFC3209]) and knows the bandwidth reserved for the LSP. Thus, any LSR could report the LSP to the PCE, noting that it will not hurt (beyond additional message processing and potential overload of the PCE or the network) for the LSP to be reported multiple times because it is clearly identified. In fact, this would also provide a cross-check mechanism.
代替アプローチは、LSPのパス上のどのLSRもおそらく（RSVP-TEシグナリング[RFC3209]のレコードルートオブジェクトを通じて）パス全体を見ることができ、LSP用に予約された帯域幅を知っていることに注意することです。したがって、どのLSRもLSPをPCEに報告し、LSPが明確に識別されるため、LSPが複数回報告されることで、（追加のメッセージ処理とPCEまたはネットワークの潜在的な過負荷を超えて）害を及ぼさないことに注意できます。実際、これはクロスチェックメカニズムも提供します。
Nevertheless, it is possible that some LSPs will traverse only LSRs that are not aware of the PCE's need to learn LSP state and build an LSP-DB. In these cases, the stateful PCE must either only have limited knowledge of the LSPs in the network or must learn about LSPs through some other mechanism (such as reading the MPLS and GMPLS MIB modules [RFC3812] [RFC4802]).
それにもかかわらず、一部のLSPは、PCEがLSP状態を学習してLSP-DBを構築する必要性を認識していないLSRのみを通過する可能性があります。これらの場合、ステートフルPCEは、ネットワーク内のLSPについて限られた知識しか持っていないか、他のメカニズム（MPLSおよびGMPLS MIBモジュール[RFC3812] [RFC4802]の読み取りなど）を通じてLSPについて学習する必要があります。
Ultimately, there may be no substitute for all LSRs being aware of Stateful PCEs and able to respond to requests for reports on all LSPs that they know about. This will allow a Stateful PCE to build its LSP-DB from scratch (which it may need to do at start of day) and to verify its LSP-DB against the network (which may be important if the PCE has suffered some form of outage).
最終的に、すべてのLSRがステートフルPCEを認識し、それらが知っているすべてのLSPに関するレポートの要求に応答できる代わりになるものはありません。これにより、ステートフルPCEはLSP-DBを最初から構築し（1日の初めに実行する必要がある場合があります）、ネットワークに対してLSP-DBを検証できます（PCEが何らかの形で停止した場合に重要になる場合があります） ）。
It is important that two PCEs operating in a network have similar views of the available resources. That is, they should have the same or substantially similar TEDs. This is easy to achieve either by building the TEDs from the network in the same way or by one PCE synchronizing its TED to the other PCE using a TED export protocol such as BGP-LS [LS-DISTRIB] or the Network Configuration Protocol (NETCONF) [RFC6241] (see Section 6).
ネットワークで動作している2つのPCEが、使用可能なリソースについて同様の見解を持つことが重要です。つまり、それらのTEDは同じまたは実質的に類似している必要があります。これは、同じ方法でネットワークからTEDを構築するか、BGP-LS [LS-DISTRIB]やネットワーク構成プロトコル（NETCONF）などのTEDエクスポートプロトコルを使用して、1つのPCEがそのTEDを他のPCEに同期させることで簡単に達成できます。 ）[RFC6241]（セクション6を参照）。
Synchronizing the LSP-DB can be a more complicated issue. As described in Section 15, building the LSP-DB can be an involved process, so it would be best to not have multiple PCEs each trying to build an LSP-DB from the network. However, it is still important that where multiple PCEs operate in the network (either as distributed PCEs or with one acting as a backup for the other), their LSP-DBs are kept synchronized.
LSP-DBの同期は、より複雑な問題になる可能性があります。セクション15で説明したように、LSP-DBの構築は複雑なプロセスになる可能性があるため、複数のPCEがそれぞれネットワークからLSP-DBを構築しようとしないことが最善です。ただし、複数のPCEがネットワークで動作している場合（分散PCEとして、または一方が他方のバックアップとして機能する場合）は、それらのLSP-DBが常に同期していることが重要です。
Thus, there is likely to be a need for a protocol mechanism for one PCE to update its LSP-DB with that of another PCE. This is no different from any other database-synchronization problem and could use existing mechanisms or a new protocol. Note, however, that in the case of distributed PCEs that are also Active PCEs (see Section 17), each PCE will be creating entries in its own LSP-DB; so, the synchronization of databases must be incremental and bidirectional, not just simply a database dump.
したがって、あるPCEが別のPCEのLSP-DBでLSP-DBを更新するためのプロトコルメカニズムが必要になる可能性があります。これは他のデータベース同期の問題と何ら変わりはなく、既存のメカニズムまたは新しいプロトコルを使用できます。ただし、アクティブPCEでもある分散PCE（セクション17を参照）の場合、各PCEは独自のLSP-DBにエントリを作成することに注意してください。したがって、データベースの同期は、単なるデータベースダンプだけでなく、インクリメンタルかつ双方向でなければなりません。
It may be helpful to clarify the word "redundant" in the context of this question. One interpretation is that a redundant PCE exists solely as a backup such that it only performs a function in the network in the event of a failure of the primary PCE. This seems like a waste of expensive resources, and it would make more sense for the redundant PCE to take its share of computation load all the time. However, that scenario of two (or more) active PCEs creates exactly the state synchronization issue described above.
この質問の文脈で「冗長」という言葉を明確にすることは役立つかもしれません。 1つの解釈は、冗長PCEはバックアップとしてのみ存在し、プライマリPCEに障害が発生した場合にのみネットワークで機能を実行するというものです。これは高価なリソースの無駄遣いのようであり、冗長PCEが常に計算負荷のシェアをとる方が理にかなっています。ただし、2つ（またはそれ以上）のアクティブなPCEのシナリオでは、上記の状態同期の問題が正確に発生します。
Various deployment options have been suggested where one PCE serves a set of PCCs as the primary computation server, and only addresses requests from other PCCs in the event of the failure of some other PCE; however, this mode of operation still raises questions about the need for synchronized state even in non-failure scenarios if the LSPs that will be computed by the different PCEs may traverse the same network resources.
1つのPCEが一連のPCCをプライマリ計算サーバーとして提供し、他のPCEに障害が発生した場合にのみ他のPCCからの要求に対応するさまざまな展開オプションが提案されています。ただし、この操作モードでは、異なるPCEによって計算されるLSPが同じネットワークリソースをトラバースする可能性がある場合、障害のないシナリオでも同期状態の必要性について疑問が残ります。
A Passive PCE is one that only responds to path computation requests. It takes no autonomous actions. A Passive PCE may be stateless or stateful.
パッシブPCEは、パス計算要求にのみ応答するものです。自律的な動作は行いません。パッシブPCEは、ステートレスまたはステートフルの場合があります。
An Active PCE is one that issues provisioning "recommendations" to the network. These recommendations may be new routes for existing LSPs or routes for new LSPs (that is, an Active PCE may recommend the instantiation of new LSPs). An Active PCE may be stateless or stateful, but in order for it to reroute existing LSPs effectively, it is likely to hold state for at least those LSPs that it will reroute.
アクティブPCEは、ネットワークへのプロビジョニングの「推奨事項」を発行するものです。これらの推奨事項は、既存のLSPの新しいルートまたは新しいLSPのルートである場合があります（つまり、アクティブPCEが新しいLSPのインスタンス化を推奨する場合があります）。アクティブPCEはステートレスまたはステートフルの場合がありますが、既存のLSPを効果的に再ルーティングするために、少なくとも再ルーティングするLSPの状態を保持する可能性があります。
Many people consider that the PCE, itself, cannot be Active. That is, they hold that the PCE's function is purely to compute paths. In that worldview, the "Active PCE" is actually the combination of a normal, passive PCE and an additional architectural component responsible for issuing commands or recommendations to the network.
PCE自体をアクティブにすることはできないと多くの人が考えています。つまり、PCEの機能は純粋にパスを計算することであると彼らは考えています。その世界観では、「アクティブPCE」は実際には、通常のパッシブPCEと、ネットワークへのコマンドまたは推奨の発行を担当する追加のアーキテクチャコンポーネントの組み合わせです。
In some configurations, the VNTM discussed in Sections 21 and 22 provides this additional component.
一部の構成では、セクション21および22で説明するVNTMがこの追加コンポーネントを提供します。
Section 20 offers a brief comparison of the different modes of PCE with reference to passive and active PCE.
セクション20では、パッシブPCEとアクティブPCEを参照して、PCEのさまざまなモードを簡単に比較します。
LSP delegation [STATEFUL-PCE] is the process where a PCC (usually an ingress LSR) passes responsibility for triggering updates to the attributes of an LSP (such as bandwidth or path) to the PCE. In this case, the PCE would need to be both Stateful and Active.
LSP委任[STATEFUL-PCE]は、PCC（通常は入力LSR）がLSPの属性（帯域幅やパスなど）の更新をトリガーする責任をPCEに渡すプロセスです。この場合、PCEはステートフルとアクティブの両方である必要があります。
LSP delegation allows an LSP to be set up under the control of the ingress LSR potentially using the services of a PCE. Once the LSP has been set up, the LSR (a PCC) tells the PCE about the LSP by providing details of the path and resources used. It delegates responsibility for the LSP to the PCE so that the PCE can make adjustments to the LSP as dictated by changes to the TED and the policies in force at the PCE. The PCE makes the adjustments by sending a new path to the LSR with the instruction/recommendation that the LSP be re-signaled.
LSP委任により、PCEのサービスを潜在的に使用して、入力LSRの制御下でLSPをセットアップできます。 LSPがセットアップされると、LSR（PCC）は、使用されたパスとリソースの詳細を提供することにより、LSPについてPCEに通知します。 PCEがLSPに調整を加えることができるように、LSEに対する責任をPCEに委任します。PCEは、TEDへの変更とPCEで有効なポリシーに応じてLSPを調整できるようにします。 PCEは、LSPが再シグナリングされるという指示/推奨を含む新しいパスをLSRに送信することにより、調整を行います。
There may be some debate over whether the PCE "owns" the LSP after delegation. That is, if the PCE supplies a new path, is the ingress LSR required to act or can it take the information "under advisement"? It may be too soon to answer this question definitively; however, there is certainly an expectation that the LSR will act on the advice it receives. A comparison may be drawn with a visit to the doctor: the doctor has an expectation that the patient will take the medicine, but the patient has free will.
PCEが委任後にLSPを「所有」するかどうかについては、いくつかの議論があるかもしれません。つまり、PCEが新しいパスを提供する場合、入力LSRは動作する必要がありますか、それとも「アドバイスの下」の情報を取得できますか？この質問に決定的に答えるのは時期尚早かもしれません。ただし、LSRが受け取ったアドバイスに基づいて行動することが確実に期待されています。比較は、医者への訪問と引き出されるかもしれません：医者は患者が薬を服用することを期待していますが、患者は自由意志を持っています。
It is important, however, to distinguish between an LSP established within the network and subsequently delegated to a PCE and an LSP that was established as the result of an Active PCE's recommendation for LSP instantiation.
ただし、ネットワーク内で確立され、その後PCEに委任されたLSPと、アクティブなPCEがLSPのインスタンス化を推奨した結果として確立されたLSPを区別することが重要です。
Section 20 offers a brief comparison of the different modes of PCE with reference to LSP delegation.
セクション20では、LSP委任に関してPCEのさまざまなモードを簡単に比較します。
In many ways the answer here is "yes". But the PCE architecture forms part of a new way of looking at network operation and management. In this new view, the network operation is more dynamic and under the control of software applications without direct intervention from operators. This is not to say that the operator has no say in how their network runs, but it does mean that the operator sets policies (see Section 24) and that new components (such as an Active PCE) are responsible for acting on those policies to dynamically control the network.
多くの点で、ここでの答えは「はい」です。しかし、PCEアーキテクチャは、ネットワークの運用と管理を検討する新しい方法の一部を形成しています。この新しいビューでは、ネットワーク操作はより動的であり、オペレーターの直接介入なしにソフトウェアアプリケーションの制御下にあります。これは、事業者がネットワークの運用方法について何も言わないというわけではありませんが、事業者がポリシーを設定し（セクション24を参照）、新しいコンポーネント（アクティブPCEなど）がこれらのポリシーに基づいて行動する責任があることを意味しますネットワークを動的に制御します。
There is a subtle distinction between an NMS and an Active PCE with LSP delegation. An NMS is in control of the LSPs in the network and can command that they are set up, modified, or torn down. An Active PCE can only make suggestions about LSPs that have been delegated to the PCE by a PCC, or make recommendations for the instantiation of new LSPs.
NMSとLSP委任によるアクティブPCEの間には微妙な違いがあります。 NMSはネットワーク内のLSPを制御しており、LSPのセットアップ、変更、または破棄を指示できます。アクティブPCEは、PCCによってPCEに委任されたLSPについてのみ提案を行うか、新しいLSPのインスタンス化についての提案を行うことができます。
For more details, see the discussion of an architecture for Application-Based Network Operation (ABNO) in [NET-OPS]
詳細については、[NET-OPS]のアプリケーションベースのネットワーク操作（ABNO）のアーキテクチャに関する説明を参照してください。
Table 1 shows a comparison of stateless and stateful PCEs to show how they how might be instantiated as passive or active PCEs with or without control of LSPs. The terms used relate to the concepts introduced in the previous sections. The entries in the table refer to the notes that follow.
表1は、ステートレスPCEとステートフルPCEの比較を示し、LSPの制御の有無にかかわらず、どのようにパッシブまたはアクティブPCEとしてインスタンス化されるかを示しています。使用されている用語は、前のセクションで紹介した概念に関連しています。表のエントリは、以下の注記を参照しています。
| Stateless | Stateful |
------------------------+-----------+-----------+
Passive | 1 | 2 |
Active delegated LSPs | 3 | 4 |
Active suggest new LSPs | 5 | 6 |
Active instantiate LSPs | 7 | 7 |
Notes: 1. Passive is the normal mode for a stateless PCE. 2. A passive mode stateful PCE may have value for more complex environments and for computing protected services. 3. Delegation of LSPs to a stateless PCE is relatively pointless, but could add value at moment of delegation. 4. This is the normal mode for a stateful PCE. 5. There is only marginal potential for a stateless PCE to recommend new LSPs because without a view of existing LSPs, the PCE cannot determine when new ones might be needed. 6. This mode has potential for recommending the instantiation of new LSPs. 7. These modes are out of scope for PCE as currently described. That is, the PCE can recommend instantiation, but cannot actually instantiate the LSPs.
注：1.パッシブは、ステートレスPCEの通常モードです。 2.パッシブモードのステートフルPCEは、より複雑な環境やコンピューティング保護サービスに価値がある場合があります。 3.ステートレスPCEへのLSPの委任は比較的無意味ですが、委任の瞬間に価値を追加できます。 4.これは、ステートフルPCEの通常モードです。 5.ステートレスPCEが新しいLSPを推奨する可能性はわずかですが、PCEは既存のLSPを確認しないと、新しいLSPが必要になる時期を判断できないためです。 6.このモードは、新しいLSPのインスタンス化を推奨する可能性があります。 7.これらのモードは、現在説明されているPCEの範囲外です。つまり、PCEはインスタンス化を推奨できますが、実際にLSPをインスタンス化することはできません。
Table 1 : Comparing Stateless and Stateful PCE
表1：ステートレスPCEとステートフルPCEの比較
A Virtual Network Topology (VNT) is described in [RFC4397] as a set of Hierarchical LSPs that is created (or could be created) in a particular network layer to provide network flexibility (data links) in other layers. Thus, the TE topology of a network can be constructed from TE links that are simply data links, from TE links that are supported by LSPs in another layer of the network, or from TE links that could be supported by LSPs ("potential LSPs") that would be set up on demand in another network layer. This third type of TE link is known as a Virtual TE Link in [RFC5212].
仮想ネットワークトポロジ（VNT）は、[RFC4397]で、特定のネットワークレイヤーで作成された（または作成できる）階層型LSPのセットとして記述され、他のレイヤーでネットワークの柔軟性（データリンク）を提供します。したがって、ネットワークのTEトポロジは、単なるデータリンクであるTEリンク、ネットワークの別のレイヤのLSPでサポートされるTEリンク、またはLSPでサポートされる可能性のあるTEリンク（「潜在的なLSP」）から構築できます。 ）別のネットワーク層でオンデマンドで設定されます。この3番目のタイプのTEリンクは、[RFC5212]では仮想TEリンクとして知られています。
[RFC5212] also gives a more detailed explanation of a VNT, and it should be noted that the network topology in a packet network could be supported by LSPs in a number of different lower-layer networks. For example, the TE links in the packet network could be achieved by connections (LSPs) in underlying Synchronous Optical Network or Synchronous Digital Hierarchy (SONET/SDH) and photonic networks. Furthermore, because of the hierarchical nature of MPLS, the TE links in a packet network may be achieved by setting up packet LSPs in the same packet network.
[RFC5212]は、VNTの詳細な説明も提供します。また、パケットネットワークのネットワークトポロジは、多くの異なる下位層ネットワークのLSPでサポートできることに注意してください。たとえば、パケットネットワークのTEリンクは、基礎となる同期光ネットワークまたは同期デジタル階層（SONET / SDH）およびフォトニックネットワークの接続（LSP）によって実現できます。さらに、MPLSの階層的な性質により、パケットネットワーク内のTEリンクは、同じパケットネットワーク内にパケットLSPを設定することで実現できます。
A PCE obviously works with the TED that contains information about the TE links in the network. Those links may be already established or may be virtual TE links. In a simple TED, there is no distinction between the types of TE link; however, there may be advantages to selecting TE links that are based on real data links over those based on dynamic LSPs in lower layers because the data links may be more stable. Conversely, the TE links based on dynamic LSPs may be able to be repaired dynamically giving better resilience. Similarly, a PCE may prefer to select a TE link that is supported by a data link or existing LSP in preference to using a virtual TE link because the latter may need to be set up (taking time) and the setup could potentially fail. Thus, a PCE might want to employ additional metrics or indicators to help it view the TED and select the right path for LSPs.
PCEは、ネットワーク内のTEリンクに関する情報を含むTEDと明らかに連携します。これらのリンクは、すでに確立されている場合と、仮想TEリンクの場合があります。単純なTEDでは、TEリンクのタイプに違いはありません。ただし、データリンクの方が安定している可能性があるため、下位層の動的LSPに基づくものよりも実際のデータリンクに基づくTEリンクを選択する方が有利な場合があります。逆に、動的LSPに基づくTEリンクは、動的に修復できるため、回復力が向上します。同様に、PCEは仮想TEリンクを使用するよりも、データリンクまたは既存のLSPによってサポートされるTEリンクを選択することを好む場合があります。仮想TEリンクをセットアップする必要があり（時間がかかる）、セットアップが失敗する可能性があるためです。したがって、PCEは、TEDを表示してLSPの適切なパスを選択するのに役立つ追加のメトリックまたはインジケーターを使用する場合があります。
If a PCE uses a virtual TE link, then some action will be needed to establish the LSP that supports that link. Some models (such as that in [RFC5212]) trigger the setup of the lower-layer LSPs on-demand during the signaling of the upper-layer LSP (i.e., when the upper layer comes to use the virtual TE link, the upper-layer signaling is paused and the lower-layer LSP is established). Another view, described in [RFC5623], is that when the PCE computes a path that will use a virtual TE link, it should trigger the setup of the lower-layer LSP to properly create the TE link so that the path it returns will be sure to be viable. This latter mode of operation can be extended to allow the PCE to spot the need for additional TE links and to trigger LSPs in lower layers in order to create those links.
PCEが仮想TEリンクを使用する場合、そのリンクをサポートするLSPを確立するためにいくつかのアクションが必要になります。一部のモデル（[RFC5212]のモデルなど）は、上位層LSPのシグナリング中にオンデマンドで下位層LSPのセットアップをトリガーします（つまり、上位層が仮想TEリンクを使用するようになると、上位層LSP層のシグナリングが一時停止され、下位層のLSPが確立されます）。 [RFC5623]で説明されている別のビューは、PCEが仮想TEリンクを使用するパスを計算するときに、下位層LSPのセットアップをトリガーしてTEリンクを適切に作成し、それが返すパスが実行可能であることを確認してください。この後者の動作モードを拡張して、PCEが追加のTEリンクの必要性を特定し、それらのリンクを作成するために下位層でLSPをトリガーできるようにすることができます。
Of course, such "interference" in a lower-layer network by a PCE responsible for a higher-layer network depends heavily on policy. In order to make a clean architectural separation and to facilitate proper policy control, [RFC5623] introduces the Virtual Network Topology Manager (VNTM) as a functional element that manages and controls the VNT. [RFC5623] notes that the PCE and VNT Manager are distinct functional elements that may or may not be collocated. indeed, it should be noted that there will be a PCE for the upper layer, and a PCE for each lower layer, and a VNTM responsible for coordinating between the PCEs and for triggering LSP setup in the lower layers. Therefore, the combination of all of the PCEs and the VNTM produces functionally similar to an Active, multi-layer PCE.
もちろん、上位層ネットワークを担当するPCEによる下位層ネットワークでのこのような「干渉」は、ポリシーに大きく依存します。アーキテクチャを明確に分離し、適切なポリシー制御を容易にするために、[RFC5623]はVNTを管理および制御する機能要素としてVirtual Network Topology Manager（VNTM）を導入しています。 [RFC5623]は、PCEとVNTマネージャーは、併置されている場合とされていない場合がある別個の機能要素であることを指摘しています。実際、上位層にはPCE、各下位層にはPCE、PCE間の調整および下位層でのLSPセットアップのトリガーを担当するVNTMがあることに注意してください。したがって、すべてのPCEとVNTMの組み合わせにより、アクティブな多層PCEと機能的に類似したものが生成されます。
See [TE-INFO] for additional discussion of the construction of networks using virtual and potential links.
仮想および潜在的なリンクを使用したネットワークの構築の詳細については、[TE-INFO]を参照してください。
The VNTM described in Section 21 and [RFC5623] has several interfaces (see also [NET-OPS]).
セクション21および[RFC5623]で説明されているVNTMには、いくつかのインターフェイスがあります（[NET-OPS]も参照）。
- In order to make decisions on whether to create new TE links, the VNTM needs to learn from the upper-layer PCE about resource shortages and the need for additional TE links. It can then make policy-based decisions to determine whether to create new TE links and how to support them through existing or new LSPs.
- 新しいTEリンクを作成するかどうかを決定するために、VNTMはリソース不足と追加のTEリンクの必要性について上位層PCEから学習する必要があります。次に、ポリシーベースの決定を行って、新しいTEリンクを作成するかどうか、および既存または新しいLSPを通じてそれらをサポートする方法を決定できます。
- The VNTM will need to coordinate with the PCEs in the lower layers, but this is simply a normal use of PCEP.
- VNTMは下位層のPCEと調整する必要がありますが、これは単にPCEPの通常の使用方法です。
- The VNTM will need to issue provisioning requests/commands (via the Provisioning Manager described in [NET-OPS]) to the lower-layer networks to cause LSPs to be set up to act as TE links in the higher layer network. A number of potential protocols exist for this function as described in [NET-OPS], but it should be noted that it makes a lot of sense for this interface to be the same as that used by an Active PCE when providing paths to the network.
- VNTMは、下位層ネットワークにプロビジョニング要求/コマンド（[NET-OPS]で説明されているプロビジョニングマネージャーを介して）を発行して、LSPが上位層ネットワークでTEリンクとして機能するように設定する必要があります。 [NET-OPS]で説明されているように、この機能にはいくつかの潜在的なプロトコルが存在しますが、ネットワークへのパスを提供するときに、このインターフェイスがアクティブPCEによって使用されるものと同じであることは非常に理にかなっています。 。
LSP scheduling or calendaring is a process where LSPs are planned ahead of time, and they are only set up when needed. The challenge here is to ensure that the resources needed by an LSP and that were available when the LSP's path was computed are still available when the LSP needs to be set up. This needs to be achieved using a mechanism that allows those resources to be used in the meantime.
LSPスケジューリングまたはカレンダーは、LSPが事前に計画され、必要な場合にのみ設定されるプロセスです。ここでの課題は、LSPが必要であり、LSPのパスが計算されたときに利用可能であったリソースが、LSPを設定する必要がある場合でも利用可能であることを確認することです。その間、これらのリソースを使用できるメカニズムを使用してこれを実現する必要があります。
Previous discussion of this topic has suggested that LSPs should be pre-signaled so that each LSR along the path could make a "temporal reservation" of resources. But this approach can become very complicated requiring each network node to store multi-dimensional state.
このトピックの以前の説明では、パスに沿った各LSRがリソースの「一時予約」を行えるように、LSPに事前に信号を送る必要があることを示唆しています。ただし、このアプローチは非常に複雑になり、各ネットワークノードに多次元の状態を格納する必要があります。
Conversely, a centralized database of resources and LSPs (such as the database maintained by a Stateful PCE) can be enhanced with a time-based booking system. If the PCE is also Active, then when the time comes for the LSP to be set up (or later, when it is to be torn down), the PCE can issue recommendations to the network.
逆に、リソースとLSPの集中データベース（ステートフルPCEによって維持されるデータベースなど）は、時間ベースの予約システムで拡張できます。 PCEもアクティブである場合、LSPがセットアップされるとき（または後で取り壊されるとき）に、PCEはネットワークに推奨を発行できます。
In a busy network (and why would one bother with a scheduling service in a network that is not busy?), it should be noted that the computation algorithm can be quite complex. It may also be necessary to reposition existing or planned LSPs as new bookings arrive.
ビジー状態のネットワークでは（そして、ビジー状態でないネットワークでスケジューリングサービスに煩わされるのはなぜですか？）、計算アルゴリズムは非常に複雑になる可能性があることに注意してください。新しい予約が到着したときに、既存または計画中のLSPを再配置する必要がある場合もあります。
Furthermore, the booking database that contains both the scheduled LSPs and their impact on the network resources can become quite large. A very important factor in the size of the active database (depending on implementation) may be the timeslices that are available in the calendering process.
さらに、スケジュールされたLSPとネットワークリソースへの影響の両方を含む予約データベースは、非常に大きくなる可能性があります。アクティブなデータベースのサイズ（実装によって異なります）の非常に重要な要素は、カレンダー処理で使用できるタイムスライスです。
Policy is critical to the operation of a network. In a PCE context, it provides control and management of how a PCE selects network resources for use by different PCEs.
ポリシーはネットワークの運用に不可欠です。 PCEのコンテキストでは、PCEがさまざまなPCEで使用するネットワークリソースを選択する方法を制御および管理します。
[RFC5394] introduced the concept of PCE-based policy-enabled path computation. It is based on the Policy Core Information Model (PCIM) [RFC3060] as extended by [RFC3460], and provides a framework for supporting path computation policy.
[RFC5394]は、PCEベースのポリシー対応パス計算の概念を導入しました。 [RFC3460]によって拡張されたポリシーコア情報モデル（PCIM）[RFC3060]に基づいており、パス計算ポリシーをサポートするためのフレームワークを提供します。
Policy enters into all aspects of the use of a PCE starting from the very decision to use a PCE to off-load computation function from the LSRs.
PCEを使用してLSRから計算機能をオフロードするというまさにその決定から始めて、ポリシーはPCEの使用のすべての側面に入ります。
- Each PCC must select which computations will be delegated to a PCE.
- 各PCCは、PCEに委任される計算を選択する必要があります。
- Each PCC must select which PCEs it will use.
- 各PCCは、使用するPCEを選択する必要があります。
- Each PCE must determine which PCCs are allowed to use its services and for what computations.
- 各PCEは、どのPCCがそのサービスの使用を許可され、どの計算が許可されるかを決定する必要があります。
- The PCE must determine how to collect the information in its TED, who to trust for that information, and how to refresh/update the information.
- PCEは、TEDで情報を収集する方法、その情報を信頼する人、および情報を更新/更新する方法を決定する必要があります。
- Each PCE must determine which objective functions and which algorithms to apply.
- 各PCEは、適用する目的関数とアルゴリズムを決定する必要があります。
- Inter-domain (and particularly H-PCE) computations will need to be sensitive to commercial and reliability information about domains and their interactions.
- ドメイン間（特にH-PCE）の計算は、ドメインとその相互作用に関する商用情報および信頼性情報に敏感である必要があります。
- Stateful PCEs must determine what state to hold, when to refresh it, and which network elements to trust for the supply of the state information.
- ステートフルPCEは、保持する状態、それを更新するタイミング、および状態情報の提供を信頼するネットワーク要素を決定する必要があります。
- An Active PCE must have a policy relationship with its LSRs to determine which LSPs can be modified or triggered, and what LSP delegation is supported.
- アクティブPCEは、変更またはトリガーできるLSPと、サポートされるLSP委任を決定するために、LSRとのポリシー関係を持っている必要があります。
- Multi-layer interactions (especially those using virtual or dynamic TE links) must provide policy control to stop server layer LSPs (which are fat and expensive by definition) from being set up on a whim to address micro-flows or speculative computations in higher layers.
- マルチレイヤーインタラクション（特に仮想またはダイナミックTEリンクを使用するもの）は、上位レイヤーでのマイクロフローまたは投機的計算に対処するために、サーバーレイヤーLSP（定義上、脂肪で高価）が気まぐれにセットアップされないようにするポリシー制御を提供する必要があります。
- A PCE may supply, along with a computed path, policy information that should be signaled during LSP setup for use by the LSRs along the path.
- PCEは、計算されたパスとともに、パスに沿ったLSRが使用するためにLSPセットアップ中に通知される必要があるポリシー情報を提供する場合があります。
It may be seen, therefore, that a PCE is substantially a policy engine that computes paths. It should also be noted that the work of the PCE can be substantially controlled by configured policy in a way that will reduce the options available to the PCC, but also significantly reduce the need for the use of optional parameters in the PCEP messages.
したがって、PCEは実質的にパスを計算するポリシーエンジンであることがわかります。また、PCEの作業は、PCCで使用できるオプションを減らすだけでなく、PCEPメッセージでオプションのパラメーターを使用する必要性を大幅に減らす方法で、構成されたポリシーによって実質的に制御できることにも注意してください。
Software-Defined Networking (SDN) is the latest shiny thing in networking. It refers to a separation between the control elements and the forwarding components so that software running in a centralized system called a controller, can act to program the devices in the network to behave in specific ways.
ソフトウェア定義ネットワーキング（SDN）は、ネットワーキングにおける最新の光沢のあるものです。これは、コントローラーと呼ばれる集中型システムで実行されるソフトウェアが特定の方法で動作するようにネットワーク内のデバイスをプログラムするように機能できるように、制御要素と転送コンポーネント間の分離を指します。
A required element in an SDN architecture is a component that plans how the network resources will be used and how the devices will be programmed. It is possible to view this component as performing specific computations to place flows within the network given knowledge of the availability of network resources, how other forwarding devices are programmed, and the way that other flows are routed. This, it may be concluded, is the same function that a PCE might offer in a network operated using a dynamic control plane. Thus, a PCE could form part of the infrastructure for an SDN.
SDNアーキテクチャで必要な要素は、ネットワークリソースの使用方法とデバイスのプログラミング方法を計画するコンポーネントです。このコンポーネントは、ネットワークリソースの可用性、他の転送デバイスのプログラム方法、および他のフローのルーティング方法に関する知識があれば、特定の計算を実行してネットワーク内にフローを配置するものと見なすことができます。これは、結論として、動的制御プレーンを使用して操作されるネットワークでPCEが提供する可能性のある機能と同じです。したがって、PCEはSDNのインフラストラクチャの一部を形成できます。
A view of how PCE integrates into a wider network control system including SDN is presented in [NET-OPS].
PCEがSDNを含むより広範なネットワーク制御システムにどのように統合されるかについての図は、[NET-OPS]に示されています。
The use of a PCE-based architecture and subsequent impact on network security must, itself, be considered in the context of existing routing and signaling protocols and techniques. The nature of multi-domain network scenarios and establishment of relationships between PCCs and PCEs may increase the vulnerability of the network to security attacks. However, this informational document does not define any new protocol elements or mechanism. As such, it does not introduce any new security issues and security is deemed to be a
PCEベースのアーキテクチャの使用とその後のネットワークセキュリティへの影響は、それ自体、既存のルーティングとシグナリングのプロトコルと技術のコンテキストで検討する必要があります。マルチドメインネットワークシナリオの性質およびPCCとPCE間の関係の確立により、ネットワークのセキュリティ攻撃に対する脆弱性が高まる可能性があります。ただし、この情報ドキュメントでは、新しいプロトコル要素やメカニズムを定義していません。そのため、新しいセキュリティ問題は発生せず、セキュリティは
"previously answered question" even if the answers previously supplied are not perfect. Previous PCE RFCs have given some attention to security concerns in the use of PCE (RFC 4655), PCE discovery (RFC 4674, RFC 5088, and RFC 5089), and PCEP (RFC 4657 and RFC 5440).
以前に提供された回答が完全ではない場合でも、「以前に回答された質問」。以前のPCE RFCは、PCE（RFC 4655）、PCEディスカバリー（RFC 4674、RFC 5088、およびRFC 5089）、およびPCEP（RFC 4657およびRFC 5440）の使用におけるセキュリティ上の懸念に注意を払っていました。
It is worth noting that PCEP operates over TCP. An analysis of the security issues for routing protocols that use TCP (including PCEP) is provided in [RFC6952], while [PCE-PCEPS] discusses an experimental approach to provide secure transport for PCEP.
PCEPがTCP上で動作することは注目に値します。 TCP（PCEPを含む）を使用するルーティングプロトコルのセキュリティ問題の分析は[RFC6952]で提供され、[PCE-PCEPS]はPCEPに安全なトランスポートを提供する実験的アプローチについて説明します。
A number of the questions raised and answered in this document should be given consideration in the light of security requirements. Some of these are called out explicitly (Sections 8 and 10), but attention should also be paid to security in all aspects of the use of PCE. For example:
このドキュメントで取り上げて回答した多くの質問は、セキュリティ要件に照らして検討する必要があります。これらの一部は明示的に呼び出されますが（セクション8および10）、PCEの使用のすべての側面でセキュリティにも注意を払う必要があります。例えば：
- Topology and other information about the network needs to be kept private and protected from modification or forgery. That means that access to the TED, LSP-DB, etc., needs to be secured and that mechanisms used to gather topology and other information (Sections 2, 11, 14, and 15) need to include security.
- ネットワークに関するトポロジーやその他の情報は、プライベートに保ち、変更や偽造から保護する必要があります。つまり、TEDやLSP-DBなどへのアクセスを保護する必要があり、トポロジやその他の情報（セクション2、11、14、15）を収集するために使用するメカニズムにセキュリティを含める必要があります。
- PCE discovery (Sections 4, 5, 9, and 10) needs to protect against impersonation or misconfiguration so that PCCs know that they are getting correct paths and so that PCEs know that they are only serving legitimate computation requests.
- PCE検出（セクション4、5、9、および10）は、なりすましや設定ミスから保護し、PCCが正しいパスを取得していることを認識し、PCEが正当な計算リクエストのみを処理していることを認識できるようにする必要があります。
- Synchronization of information and state between PCEs (Sections 6 and 16) is subject to the same security requirements in that the information exchanged is sensitive and needs to be protected against interception and modification.
- PCE間の情報と状態の同期（セクション6および16）は、交換される情報が機密であり、傍受や変更から保護される必要があるという点で、同じセキュリティ要件の影響を受けます。
- PCE computes paths for components that may provision the network. Those component are responsible for the security of the provisioning mechanisms, however, if PCE operates as a provisioning protocol (Sections 17, 18, 19, and 25).
- PCEは、ネットワークをプロビジョニングするコンポーネントのパスを計算します。ただし、PCEがプロビジョニングプロトコルとして動作する場合（セクション17、18、19、および25）、これらのコンポーネントはプロビジョニングメカニズムのセキュリティを担当します。
- A PCE may also need to interface with other network components (Sections 19, 21, 22, and 25). Those communications, if external to an implementation, also need to be secure.
- PCEは、他のネットワークコンポーネントとインターフェイスする必要がある場合もあります（セクション19、21、22、および25）。これらの通信は、実装の外部にある場合も、安全である必要があります。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、2006年8月、<http：//www.rfc-editor .org / info / rfc4655>。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>.
[RFC5440] Vasseur、JP。、Ed。、and JL。 Le Roux、Ed。、 "Path Computation Element（PCE）Communication Protocol（PCEP）"、RFC 5440、March 2009、<http://www.rfc-editor.org/info/rfc5440>。
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, September 2009, <http://www.rfc-editor.org/info/rfc5623>.
[RFC5623]沖、E、武田、T。、ルルー、J.、A。ファレル、「PCEベースの層間MPLSおよびGMPLSトラフィックエンジニアリングのフレームワーク」、RFC 5623、2009年9月、<http：/ /www.rfc-editor.org/info/rfc5623>。
[RFC6805] King, D., Ed., and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, November 2012, <http://www.rfc-editor.org/info/rfc6805>.
[RFC6805]キング、D。、エド、およびA.ファレル、エド、「MPLSおよびGMPLSにおけるドメインのシーケンスの決定へのパス計算要素アーキテクチャの適用」、RFC 6805、2012年11月、<http ：//www.rfc-editor.org/info/rfc6805>。
[ALTO-SERVER-DISC] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and H. Song, "ALTO Server Discovery", Work in Progress, draft-ietf-alto-server-discovery-10, September 2013.
[ALTO-SERVER-DISC]キーゼル、S。、スティーマーリング、M。、シュワン、N。、シャーフ、M。、およびH.ソング、「ALTOサーバーの検出」、作業中、draft-ietf-alto-server-発見-10、2013年9月。
[LS-DISTRIB] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and TE Information using BGP", Work in Progress, draft-ietf-idr-ls-distribution-06, September 2014.
[LS-DISTRIB] Gredler、H.、Medved、J.、Previdi、S.、Farrel、A。、およびS. Ray、「BGPを使用したリンク状態およびTE情報の北限定分布」、作業中、 draft-ietf-idr-ls-distribution-06、2014年9月。
[NET-OPS] King, D., and A. Farrel, "A PCE-based Architecture for Application-based Network Operations", Work in Progress, draft-farrkingel-pce-abno-architecture-13, October 2014.
[NET-OPS]キング、D。、およびA.ファレル、「アプリケーションベースのネットワーク運用のためのPCEベースのアーキテクチャ」、進行中の作業、draft-farrkingel-pce-abno-architecture-13、2014年10月。
[PCE-PCEPS] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "Secure Transport for PCEP", Work in Progress, draft-ietf-pce-pceps-02, October 2014.
[PCE-PCEPS] Lopez、D.、Gonzalez de Dios、O.、Wu、Q。、およびD. Dhody、「Secure Transport for PCEP」、Work in Progress、draft-ietf-pce-pceps-02、2014年10月。
[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001, <http://www.rfc-editor.org/info/rfc3060>.
[RFC3060] Moore、B.、Ellesson、E.、Strassner、J。、およびA. Westerinen、「Policy Core Information Model-Version 1 Specification」、RFC 3060、2001年2月、<http：//www.rfc- editor.org/info/rfc3060>。
[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, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、12月2001、<http://www.rfc-editor.org/info/rfc3209>。
[RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003 <http://www.rfc-editor.org/info/rfc3460>.
[RFC3460] Moore、B。、編、「Policy Core Information Model（PCIM）Extensions」、RFC 3460、2003年1月<http://www.rfc-editor.org/info/rfc3460>。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003, <http://www.rfc-editor.org/info/rfc3630>.
[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、2003年9月、<http://www.rfc-editor.org/ info / rfc3630>。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004, <http://www.rfc-editor.org/info/rfc3812>.
[RFC3812] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「Multiprotocol Label Switching（MPLS）Traffic Engineering（TE）Management Information Base（MIB）」、RFC 3812、2004年6月、<http：// www .rfc-editor.org / info / rfc3812>。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005, <http://www.rfc-editor.org/info/rfc4203>.
[RFC4203] Kompella、K.、Ed。、and Y. Rekhter、Ed。、 "OSPF Extensions Support of Supported Generalized Multi-Protocol Label Switching（GMPLS）"、RFC 4203、October 2005、<http：//www.rfc -editor.org/info/rfc4203>。
[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture", RFC 4397, February 2006, <http://www.rfc-editor.org/info/rfc4397>.
[RFC4397] Bryskin、I。およびA. Farrel、「ITU-Tの自動スイッチ光ネットワーク（ASON）アーキテクチャーのコンテキスト内での一般化マルチプロトコルラベルスイッチング（GMPLS）用語の解釈のための辞書編集」、RFC 4397、2006年2月、<http://www.rfc-editor.org/info/rfc4397>。
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006, <http://www.rfc-editor.org/info/rfc4657>.
[RFC4657] Ash、J。、編、およびJ.Le Roux、編、「Path Computation Element（PCE）Communication Protocol Generic Requirements」、RFC 4657、2006年9月、<http：//www.rfc-editor。 org / info / rfc4657>。
[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006, <http://www.rfc-editor.org/info/rfc4674>.
[RFC4674] Le Roux、J.、Ed。、 "Requirements for Path Computation Element（PCE）Discovery"、RFC 4674、October 2006、<http://www.rfc-editor.org/info/rfc4674>
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006, <http://www.rfc-editor.org/info/rfc4726>.
[RFC4726] Farrel、A.、Vasseur、J.-P。、およびA. Ayyangar、「フレームワーク間のマルチプロトコルラベルスイッチングトラフィックエンジニアリングのフレームワーク」、RFC 4726、2006年11月、<http：//www.rfc- editor.org/info/rfc4726>。
[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007, <http://www.rfc-editor.org/info/rfc4802>.
[RFC4802] Nadeau、T。、編、およびA. Farrel、編、「Generalized Multiprotocol Label Switching（GMPLS）Traffic Engineering Management Information Base」、RFC 4802、2007年2月、<http：//www.rfc-editor .org / info / rfc4802>。
[RFC4848] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007, <http://www.rfc-editor.org/info/rfc4848>.
[RFC4848] Daigle、L。、「URIと動的委任発見サービス（DDDS）を使用したドメインベースのアプリケーションサービスの場所」、RFC 4848、2007年4月、<http://www.rfc-editor.org/info/rfc4848 >。
[RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 4974, August 2007, <http://www.rfc-editor.org/info/rfc4974>.
[RFC4974] Papadimitriou、D。およびA. Farrel、「Generalized MPLS（GMPLS）RSVP-TE Signaling Extensions in Support of Calls」、RFC 4974、2007年8月、<http://www.rfc-editor.org/info/ rfc4974>。
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008, <http://www.rfc-editor.org/info/rfc5088>.
[RFC5088] Le Roux、JL。、Ed。、Vasseur、JP。、Ed。、Ikejiri、Y.、and R. Zhang、 "OSPF Protocol Extensions for Path Computation Element（PCE）Discovery"、RFC 5088、January 2008、 <http://www.rfc-editor.org/info/rfc5088>。
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008, <http://www.rfc-editor.org/info/rfc5089>.
[RFC5089] Le Roux、JL。、Ed。、Vasseur、JP。、Ed。、Ikejiri、Y.、and R. Zhang、 "IS-IS Protocol Extensions for Path Computation Element（PCE）Discovery"、RFC 5089、January 2008、<http://www.rfc-editor.org/info/rfc5089>。
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008, <http://www.rfc-editor.org/info/rfc5152>.
[RFC5152] Vasseur、JP。、編、Ayyangar、A。、編、およびR. Zhang、「ドメイン間トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）を確立するためのドメインごとのパス計算方法」、 RFC 5152、2008年2月、<http://www.rfc-editor.org/info/rfc5152>。
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 2008, <http://www.rfc-editor.org/info/rfc5212>.
[RFC5212]塩本K.、パパディミトリウD.、ルルーJL。、ビグールーM.、D。ブルガード、「GMPLSベースのマルチリージョンおよびマルチレイヤーネットワーク（MRN / MLN）の要件」、 RFC 5212、2008年7月、<http://www.rfc-editor.org/info/rfc5212>。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、2008年10月、<http://www.rfc-editor.org/info/rfc5305>。
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008, <http://www.rfc-editor.org/info/rfc5307>.
[RFC5307] Kompella、K.、Ed。およびY. Rekhter、Ed。、 "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching（GMPLS）"、RFC 5307、October 2008、<http：// www .rfc-editor.org / info / rfc5307>。
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008, <http://www.rfc-editor.org/info/rfc5394>.
[RFC5394] Bryskin、I.、Papadimitriou、D.、Berger、L。、およびJ. Ash、「Policy-Enabled Path Computation Framework」、RFC 5394、2008年12月、<http://www.rfc-editor.org / info / rfc5394>。
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009, <http://www.rfc-editor.org/info/rfc5441>.
[RFC5441] Vasseur、JP。、Ed。、Zhang、R.、Bitar、N.、and JL。 Le Roux、「最短の制約付きドメイン間トラフィックエンジニアリングラベルスイッチドパスを計算するための後方再帰PCEベースの計算（BRPC）手順」、RFC 5441、2009年4月、<http://www.rfc-editor.org/info / rfc5441>。
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", RFC 5557, July 2009, <http://www.rfc-editor.org/info/rfc5557>.
[RFC5557] Lee、Y.、Le Roux、JL。、King、D。、およびE. Oki、「Path Computation Element Communication Protocol（PCEP）Requirements and Protocol Extensions Supporting Support for Global Concurrent Optimization」、RFC 5557、2009年7月、<http://www.rfc-editor.org/info/rfc5557>。
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010, <http://www.rfc-editor.org/info/rfc5986>.
[RFC5986] Thomson、M.およびJ. Winterbottom、「Discovering the Local Location Information Server（LIS）」、RFC 5986、2010年9月、<http://www.rfc-editor.org/info/rfc5986>。
[RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., Ali, Z., and J. Meuric, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 6006, September 2010, <http://www.rfc-editor.org/info/rfc6006>.
[RFC6006] Zhao、Q.、Ed。、King、D.、Ed。、Verhaeghe、F.、Takeda、T.、Ali、Z. and J. Meuric、 "Extensions to the Path Computation Element Communication Protocol（PCEP ）ポイントツーマルチポイントトラフィックエンジニアリングラベルスイッチドパス」、RFC 6006、2010年9月、<http://www.rfc-editor.org/info/rfc6006>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R.、Ed。、Bjorklund、M.、Ed。、Schoenwaelder、J.、Ed。、and A. Bierman、Ed。、 "Network Configuration Protocol（NETCONF）"、RFC 6241、June 2011、 <http://www.rfc-editor.org/info/rfc6241>。
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013, <http://www.rfc-editor.org/info/rfc6952>.
[RFC6952] Jethanandani、M.、Patel、K。、およびL. Zheng、「BGP、LDP、PCEP、およびMSDPの分析とルーティングプロトコルのキーイングおよび認証（KARP）設計ガイドによる問題」、RFC 6952、5月2013、<http://www.rfc-editor.org/info/rfc6952>。
[STATEFUL-PCE] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", Work in Progress, draft-ietf-pce-stateful-pce-10, October 2014.
[STATEFUL-PCE] Crabbe、E.、Minei、I.、Medved、J。、およびR. Varga、「ステートフルPCEのPCEP拡張機能」、作業中、draft-ietf-pce-stateful-pce-10、10月2014。
[TE-INFO] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D, and X. Zhang, "Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks", Work in Progress, draft-farrel-interconnected-te-info-exchange-07, September 2014.
[TE-INFO] Farrel、A.、Ed。、Drake、J.、Bitar、N.、Swallow、G.、Ceccarelli、D、およびX. Zhang、「相互接続されたトラフィックエンジニアリングネットワーク間の情報交換のための問題ステートメントとアーキテクチャ"、作業中、draft-farrel-interconnected-te-info-exchange-07、2014年9月。
Acknowledgements
謝辞
Thanks for constructive comments go to Fatai Zhang, Oscar Gonzalez de Dios, Xian Zhang, Cyril Margaria, Denis Ovsienko, Ina Minei, Dhruv Dhody, and Qin Wu.
建設的なコメントをお寄せいただきありがとうございます。FataiZhang、Oscar Gonzalez de Dios、Xian Zhang、Cyril Margaria、Denis Ovsienko、Ina Minei、Dhruv Dhody、Qin Wu。
This work was supported in part by the FP-7 IDEALIST project under grant agreement number 317999.
この作品の一部は、FP-7 IDEALISTプロジェクトの助成金契約番号317999でサポートされていました。
This work received funding from the European Union's Seventh Framework Programme for research, technological development and demonstration through the PACE project under grant agreement no. 619712.
この作品は、研究、技術開発、およびデモのための欧州連合の第7次フレームワークプログラムから、助成金契約No. 619712。
Authors' Addresses
著者のアドレス
Adrian Farrel Juniper Networks EMail: adrian@olddog.co.uk
エイドリアン・ファレル・ジュニパーネットワークスEメール：adrian@olddog.co.uk
Daniel King Old Dog Consulting EMail: daniel@olddog.co.uk
Daniel King Old Dog Consulting Eメール：daniel@olddog.co.uk