[要約] RFC 6805は、MPLSおよびGMPLSにおけるドメインのシーケンスの決定にパス計算要素アーキテクチャを適用するためのガイドラインです。このRFCの目的は、異なるドメイン間の経路計算を効率的に行うための手法を提供することです。
Internet Engineering Task Force (IETF) D. King, Ed.
Request for Comments: 6805 A. Farrel, Ed.
Category: Informational Old Dog Consulting
ISSN: 2070-1721 November 2012
The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS
MPLSおよびGMPLSでのドメインのシーケンスの決定へのパス計算要素アーキテクチャーの適用
Abstract
概要
Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path Computation Element (PCE) architecture.
MPLSトラフィックエンジニアリング（MPLS-TE）およびGMPLSネットワークの複数のドメインにまたがるラベルスイッチドパス（LSP）の最適ルートを計算すると、各ドメインのすべてのリンクとリソースが単一のパス計算で認識されないため、問題が発生します。経路計算要素（PCE）アーキテクチャを使用してソリューションを実現できます。
Where the sequence of domains is known a priori, various techniques can be employed to derive an optimum path. If the domains are simply connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward-Recursive PCE-based Computation (BRPC) procedure can be used to derive an optimal path.
ドメインのシーケンスが事前にわかっている場合、さまざまな手法を使用して最適なパスを導出できます。ドメインが単純に接続されている場合、または相互接続の優先ポイントもわかっている場合は、ドメインごとのパス計算手法を使用できます。ドメイン間に複数の接続があり、相互接続のポイントの選択に優先順位がない場合、Backward-Recursive PCE-based Computation（BRPC）手順を使用して最適なパスを導出できます。
This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains.
このドキュメントでは、ドメインのシーケンスが事前にわからない場合に最適なパスを確立するための手法を検討します。このドキュメントでは、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/rfc6805.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6805で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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 ....................................................4
1.1. Problem Statement ..........................................5
1.2. Definition of a Domain .....................................5
1.3. Assumptions and Requirements ...............................6
1.3.1. Metric Objectives ...................................6
1.3.2. Diversity ...........................................7
1.3.2.1. Physical Diversity .........................7
1.3.2.2. Domain Diversity ...........................7
1.3.3. Existing Traffic Engineering Constraints ............7
1.3.4. Commercial Constraints ..............................8
1.3.5. Domain Confidentiality ..............................8
1.3.6. Limiting Information Aggregation ....................8
1.3.7. Domain Interconnection Discovery ....................8
1.4. Terminology ................................................8
2. Examination of Existing PCE Mechanisms ..........................9
2.1. Per-Domain Path Computation ................................9
2.2. Backward-Recursive PCE-Based Computation ..................10
2.2.1. Applicability of BRPC When the Domain Path
is Not Known .......................................11
3. Hierarchical PCE ...............................................12
4. Hierarchical PCE Procedures ....................................13
4.1. Objective Functions and Policy ............................13
4.2. Maintaining Domain Confidentiality ........................14
4.3. PCE Discovery .............................................14
4.4. Traffic Engineering Database for the Parent Domain ........15
4.5. Determination of Destination Domain .......................16
4.6. Hierarchical PCE Examples .................................16
4.6.1. Hierarchical PCE Initial Information Exchange ......18
4.6.2. Hierarchical PCE End-to-End Path
Computation Procedure ..............................19
4.7. Hierarchical PCE Error Handling ...........................20
4.8. Requirements for Hierarchical PCEP Protocol Extensions ....20
4.8.1. PCEP Request Qualifiers ............................21
4.8.2. Indication of Hierarchical PCE Capability ..........21
4.8.3. Intention to Utilize Parent PCE Capabilities .......21
4.8.4. Communication of Domain Connectivity Information ...22
4.8.5. Domain Identifiers .................................22
5. Hierarchical PCE Applicability .................................23
5.1. Autonomous Systems and Areas ..............................23
5.2. ASON Architecture .........................................24
5.2.1. Implicit Consistency between Hierarchical
PCE and G.7715.2 ...................................25
5.2.2. Benefits of Hierarchical PCEs in ASON ..............26
6. A Note on BGP-TE ...............................................26
6.1. Use of BGP for TED Synchronization ........................27
7. Management Considerations ......................................27
7.1. Control of Function and Policy ............................27
7.1.1. Child PCE ..........................................27
7.1.2. Parent PCE .........................................27
7.1.3. Policy Control .....................................28
7.2. Information and Data Models ...............................28
7.3. Liveness Detection and Monitoring .........................28
7.4. Verifying Correct Operation ...............................28
7.5. Impact on Network Operation ...............................29
8. Security Considerations ........................................29
9. Acknowledgements ...............................................30
10. References ....................................................30
10.1. Normative References .....................................30
10.2. Informative References ...................................31
11. Contributors ..................................................32
The capability to compute the routes of end-to-end inter-domain MPLS Traffic Engineering (MPLS-TE) and GMPLS Label Switched Paths (LSPs) is expressed as requirements in [RFC4105] and [RFC4216]. This capability may be realized by a Path Computation Element (PCE). The PCE architecture is defined in [RFC4655]. The methods for establishing and controlling inter-domain MPLS-TE and GMPLS LSPs are documented in [RFC4726].
エンドツーエンドのドメイン間MPLSトラフィックエンジニアリング（MPLS-TE）およびGMPLSラベルスイッチドパス（LSP）のルートを計算する機能は、[RFC4105]および[RFC4216]の要件として表現されています。この機能は、パス計算要素（PCE）によって実現できます。 PCEアーキテクチャは[RFC4655]で定義されています。ドメイン間MPLS-TEおよびGMPLS LSPを確立および制御する方法は、[RFC4726]で文書化されています。
In this context, a domain can be defined as a separate administrative, geographic, or switching environment within the network. A domain may be further defined as a zone of routing or computational ability. Under these definitions, a domain might be categorized as an Autonomous System (AS) or an Interior Gateway Protocol (IGP) area [RFC4726] [RFC4655]. Domains are connected through ingress and egress boundary nodes (BNs). A more detailed definition is given in Section 1.2.
このコンテキストでは、ドメインは、ネットワーク内の個別の管理環境、地理的環境、またはスイッチング環境として定義できます。ドメインは、ルーティングまたは計算能力のゾーンとしてさらに定義できます。これらの定義では、ドメインは自律システム（AS）またはインテリアゲートウェイプロトコル（IGP）エリア[RFC4726] [RFC4655]として分類される場合があります。ドメインは、入力および出力境界ノード（BN）を介して接続されます。より詳細な定義はセクション1.2に記載されています。
In a multi-domain environment, the determination of an end-to-end traffic engineered path is a problem because no single point of path computation is aware of all of the links and resources in each domain. PCEs can be used to compute end-to-end paths using a per-domain path computation technique [RFC5152]. Alternatively, the Backward-Recursive PCE-based Computation (BRPC) mechanism [RFC5441] allows multiple PCEs to collaborate in order to select an optimal end-to-end path that crosses multiple domains. Both mechanisms assume that the sequence of domains to be crossed between ingress and egress is known in advance.
マルチドメイン環境では、単一ドメインのパス計算が各ドメインのすべてのリンクとリソースを認識していないため、エンドツーエンドのトラフィックエンジニアリングされたパスの決定は問題です。 PCEは、ドメインごとのパス計算手法[RFC5152]を使用してエンドツーエンドパスを計算するために使用できます。あるいは、Backward-Recursive PCE-based Computation（BRPC）メカニズム[RFC5441]を使用すると、複数のドメインにまたがる最適なエンドツーエンドのパスを選択するために、複数のPCEが協力できます。どちらのメカニズムも、入力と出力の間で交差するドメインのシーケンスが事前にわかっていることを前提としています。
This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. It shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived.
このドキュメントでは、ドメインのシーケンスが事前にわからない場合に最適なパスを確立するための手法を検討します。これは、PCEアーキテクチャを拡張して、ドメインの最適なシーケンスを選択し、最適なエンドツーエンドパスを導出できるようにする方法を示しています。
The model described in this document introduces a hierarchical relationship between domains. It is applicable to environments with small groups of domains where visibility from the ingress Label Switching Router (LSR) is limited. Applying the hierarchical PCE model to large groups of domains such as the Internet, is not considered feasible or desirable, and is out of scope for this document.
このドキュメントで説明するモデルは、ドメイン間の階層関係を導入しています。これは、入力ラベルスイッチングルータ（LSR）からの可視性が制限されている小さなドメイングループの環境に適用できます。階層PCEモデルをインターネットなどのドメインの大きなグループに適用することは、実現可能または望ましいとは見なされず、このドキュメントの範囲外です。
This document does not specify any protocol extensions or enhancements. That work is left for future protocol specification documents. However, some assumptions are made about which protocols will be used to provide specific functions, and guidelines to future protocol developers are made in the form of requirements statements.
このドキュメントでは、プロトコルの拡張機能や拡張機能は指定していません。その作業は、将来のプロトコル仕様ドキュメントに残されます。ただし、特定の機能を提供するためにどのプロトコルが使用されるかについていくつかの仮定が行われ、将来のプロトコル開発者へのガイドラインが要件ステートメントの形式で作成されます。
Using a PCE to compute a path between nodes within a single domain is relatively straightforward. Computing an end-to-end path when the source and destination nodes are located in different domains requires co-operation between multiple PCEs, each responsible for its own domain.
PCEを使用して単一ドメイン内のノード間のパスを計算することは比較的簡単です。送信元ノードと宛先ノードが異なるドメインにある場合のエンドツーエンドパスの計算には、それぞれが独自のドメインを担当する複数のPCE間の連携が必要です。
Techniques for inter-domain path computation described so far ([RFC5152] and [RFC5441]) assume that the sequence of domains to be crossed from source to destination is well known. No explanation is given (for example, in [RFC4655]) of how this sequence is generated or what criteria may be used for the selection of paths between domains. In small clusters of domains, such as simple cooperation between adjacent ISPs, this selection process is not complex. In more advanced deployments (such as optical networks constructed from multiple sub-domains, or in multi-AS environments), the choice of domains in the end-to-end domain sequence can be critical to the determination of an optimum end-to-end path.
これまでに説明したドメイン間パス計算の手法（[RFC5152]および[RFC5441]）は、ソースから宛先に渡るドメインのシーケンスがよく知られていることを前提としています。このシーケンスがどのように生成されるか、またはドメイン間のパスの選択にどの基準が使用されるかについての説明はありません（たとえば、[RFC4655]に）。隣接するISP間の単純な連携など、ドメインの小さなクラスターでは、この選択プロセスは複雑ではありません。より高度な展開（複数のサブドメインから構築された光ネットワーク、またはマルチAS環境など）では、エンドツーエンドドメインシーケンスでのドメインの選択が、最適なエンドツーエンドドメインの決定に重要になる場合があります。終了パス。
A domain is defined in [RFC4726] as any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. Wholly or partially overlapping domains are not within the scope of this document.
ドメインは、[RFC4726]で、アドレス管理またはパス計算の責任の一般的な範囲内のネットワーク要素のコレクションとして定義されています。このようなドメインの例には、IGPエリアや自律システムなどがあります。完全にまたは部分的に重複しているドメインは、このドキュメントの範囲外です。
In the context of GMPLS, a particularly important example of a domain
is the Automatically Switched Optical Network (ASON) subnetwork
[G-8080]. In this case, a domain might be an ASON Routing Area
[G-7715]. Furthermore, computation of an end-to-end path requires
the selection of nodes and links within a routing area where some
nodes may, in fact, be subnetworks. A PCE may perform the path
computation function of an ASON Routing Controller as described in
[G-7715-2]. See Section 5.2 for a further discussion of the
applicability to the ASON architecture.
This document assumes that the selection of a sequence of domains for an end-to-end path is in some sense a hierarchical path computation problem. That is, where one mechanism is used to determine a path across a domain, a separate mechanism (or at least a separate set of paradigms) is used to determine the sequence of domains. The responsibility for the selection of domain interconnection can belong to either or both of the mechanisms.
このドキュメントでは、エンドツーエンドパスの一連のドメインの選択が、ある意味で階層パス計算の問題であると想定しています。つまり、1つのメカニズムを使用してドメイン全体のパスを決定する場合、別のメカニズム（または少なくとも別のパラダイムセット）を使用してドメインのシーケンスを決定します。ドメイン相互接続の選択の責任は、どちらかまたは両方のメカニズムに属します。
Networks are often constructed from multiple domains. These domains are often interconnected via multiple interconnect points. It's assumed that the sequence of domains for an end-to-end path is not always well known; that is, an application requesting end-to-end connectivity has no preference for, or no ability to specify, the sequence of domains to be crossed by the path.
ネットワークは多くの場合、複数のドメインから構築されます。これらのドメインは多くの場合、複数の相互接続ポイントを介して相互接続されています。エンドツーエンドパスのドメインのシーケンスは、常によく知られているとは限りません。つまり、エンドツーエンドの接続を要求するアプリケーションは、パスが通過するドメインのシーケンスを優先したり、指定したりできません。
The traffic engineering properties of a domain cannot be seen from outside the domain. Traffic engineering aggregation or abstraction, hides information and can lead to failed path setup or the selection of suboptimal end-to-end paths [RFC4726]. The aggregation process may also have significant scaling issues for networks with many possible routes and multiple TE metrics. Flooding TE information breaks confidentiality and does not scale in the routing protocol. See Section 6 for a discussion of the concept of inter-domain traffic engineering information exchange known as BGP-TE.
ドメインのトラフィックエンジニアリングプロパティは、ドメインの外から見ることはできません。トラフィックエンジニアリングの集約または抽象化により、情報が隠され、パスのセットアップが失敗したり、次善のエンドツーエンドパスが選択されたりする可能性があります[RFC4726]。集約プロセスは、多くの可能なルートと複数のTEメトリックを持つネットワークの場合、重大なスケーリングの問題がある場合もあります。 TE情報のフラッディングは機密性を破壊し、ルーティングプロトコルで拡張されません。 BGP-TEと呼ばれるドメイン間トラフィックエンジニアリング情報交換の概念については、セクション6を参照してください。
The primary goal of this document is to define how to derive optimal end-to-end, multi-domain paths when the sequence of domains is not known in advance. The solution needs to be scalable and to maintain internal domain topology confidentiality while providing the optimal end-to-end path. It cannot rely on the exchange of TE information between domains, and for the confidentiality, scaling, and aggregation reasons just cited, it cannot utilize a computation element that has universal knowledge of TE properties and topology of all domains.
このドキュメントの主な目的は、ドメインのシーケンスが事前にわからない場合に、最適なエンドツーエンドのマルチドメインパスを導出する方法を定義することです。ソリューションは、スケーラブルで、内部ドメイントポロジの機密性を維持しながら、最適なエンドツーエンドパスを提供する必要があります。ドメイン間のTE情報の交換に依存することはできません。また、引用した機密性、スケーリング、および集計の理由から、TEのプロパティとすべてのドメインのトポロジに関する普遍的な知識を持つ計算要素を利用することはできません。
The sub-sections that follow set out the primary objectives and requirements to be satisfied by a PCE solution to multi-domain path computation.
以下のサブセクションでは、マルチドメインパス計算のPCEソリューションによって満たされる主要な目的と要件を示します。
The definition of optimality is dependent on policy and is based on a single objective or a group of objectives. An objective is expressed as an objective function [RFC5541] and may be specified on a path computation request. The following objective functions are identified in this document. They define how the path metrics and TE link qualities are manipulated during inter-domain path computation. The list is not proscriptive and may be expanded in other documents.
最適性の定義はポリシーに依存し、単一の目的または目的のグループに基づいています。目的は目的関数[RFC5541]として表現され、パス計算リクエストで指定できます。このドキュメントでは、次の目的関数を特定します。それらは、ドメイン間パス計算中にパスメトリックとTEリンク品質がどのように操作されるかを定義します。このリストは指示的なものではなく、他のドキュメントで拡張される場合があります。
o Minimize the cost of the path [RFC5541]. o Select a path using links with the minimal load [RFC5541]. o Select a path that leaves the maximum residual bandwidth [RFC5541]. o Minimize aggregate bandwidth consumption [RFC5541]. o Minimize the load of the most loaded link [RFC5541]. o Minimize the cumulative cost of a set of paths [RFC5541]. o Minimize or cap the number of domains crossed. o Disallow domain re-entry.
o パスのコストを最小限に抑える[RFC5541]。 o最小負荷のリンク[RFC5541]を使用してパスを選択します。 o最大残余帯域幅を残すパスを選択します[RFC5541]。 o総帯域幅消費を最小限に抑えます[RFC5541]。 o最も負荷の高いリンク[RFC5541]の負荷を最小限に抑えます。 oパスのセットの累積コストを最小限に抑えます[RFC5541]。 o交差するドメインの数を最小限にするか、上限を設けます。 oドメインの再入力を禁止します。
See Section 4.1 for further discussion of objective functions.
目的関数の詳細については、セクション4.1を参照してください。
Within a "Carrier's Carrier" environment, MPLS services may share common underlying equipment and resources, including optical fiber and nodes. An MPLS service request may require a path for traffic that is physically disjointed from another service. Thus, if a physical link or node fails on one of the disjoint paths, not all traffic is lost.
「運送業者の運送業者」環境内では、MPLSサービスは、光ファイバーやノードなど、共通の基本的な機器とリソースを共有する場合があります。 MPLSサービス要求では、別のサービスから物理的に切り離されたトラフィックのパスが必要になる場合があります。したがって、物理リンクまたはノードが互いに素なパスの1つで障害を起こしても、すべてのトラフィックが失われるわけではありません。
A pair of paths are domain-diverse if they do not transit any of the same domains. A pair of paths that share a common ingress and egress are domain-diverse if they only share the same domains at the ingress and egress (the ingress and egress domains). Domain diversity may be maximized for a pair of paths by selecting paths that have the smallest number of shared domains. (Note that this is not the same as finding paths with the greatest number of distinct domains!)
同じドメインのいずれも通過しない場合、パスのペアはドメイン多様です。共通の入力と出力を共有するパスのペアは、入力と出力（入力ドメインと出力ドメイン）で同じドメインのみを共有する場合、ドメインの多様性があります。共有ドメインの数が最も少ないパスを選択することにより、パスのペアのドメインダイバーシティを最大化できます。 （これは、最大数の異なるドメインを持つパスを見つけることと同じではないことに注意してください！）
Path computation should facilitate the selection of paths that share ingress and egress domains but do not share any transit domains. This provides a way to reduce the risk of shared failure along any path and automatically helps to ensure path diversity for most of the route of a pair of LSPs.
パス計算により、入力ドメインと出力ドメインを共有するが、通過ドメインを共有しないパスの選択が容易になります。これにより、任意のパスに沿った共有障害のリスクを軽減する方法が提供され、LSPのペアのほとんどのルートのパスダイバーシティを確実に自動的に支援します。
Thus, domain path selection should provide the capability to include or exclude specific domains and specific boundary nodes.
したがって、ドメインパスを選択すると、特定のドメインや特定の境界ノードを含めたり除外したりできるようになります。
Any solution should take advantage of typical traffic engineering constraints (hop count, bandwidth, lambda continuity, path cost, etc.) to meet the service demands expressed in the path computation request [RFC4655].
どのようなソリューションでも、パス計算リクエスト[RFC4655]で表現されたサービス要求を満たすために、一般的なトラフィックエンジニアリングの制約（ホップカウント、帯域幅、ラムダ連続性、パスコストなど）を利用する必要があります。
The solution should provide the capability to include commercially relevant constraints such as policy, Service Level Agreements (SLAs), security, peering preferences, and monetary costs.
ソリューションは、ポリシー、サービスレベルアグリーメント（SLA）、セキュリティ、ピアリング設定、金銭的コストなどの商業的に関連する制約を含める機能を提供する必要があります。
Additionally, it may be necessary for the service provider to request that specific domains are included or excluded based on commercial relationships, security implications, and reliability.
さらに、サービスプロバイダーは、商業的関係、セキュリティへの影響、および信頼性に基づいて、特定のドメインを含めるか除外するように要求する必要がある場合があります。
A key requirement is the ability to maintain domain confidentiality when computing inter-domain end-to-end paths. It should be possible for local policy to require that a PCE not disclose to any other PCE the intra-domain paths it computes or the internal topology of the domain it serves. This requirement should have no impact in the optimality or quality of the end-to-end path that is derived.
重要な要件は、ドメイン間のエンドツーエンドパスを計算するときにドメインの機密性を維持する機能です。ローカルポリシーで、PCEが計算するドメイン内パスまたはそれがサービスを提供するドメインの内部トポロジを他のPCEに開示しないように要求できる場合があります。この要件は、導出されるエンドツーエンドパスの最適性や品質に影響を与えません。
In order to reduce processing overhead and to not sacrifice computational detail, there should be no requirement to aggregate or abstract traffic engineering link information.
処理オーバーヘッドを削減し、計算の詳細を犠牲にしないために、トラフィックエンジニアリングリンク情報を集約または抽象化する必要はありません。
To support domain mesh topologies, the solution should allow the discovery and selection of domain interconnections. Pre-configuration of preferred domain interconnections should also be supported for network operators that have bilateral agreement and have a preference for the choice of points of interconnection.
ドメインメッシュトポロジをサポートするには、ソリューションでドメインの相互接続の検出と選択を許可する必要があります。優先ドメイン相互接続の事前設定は、相互の合意があり、相互接続ポイントの選択を優先するネットワーク事業者に対してもサポートされるべきです。
This document uses PCE terminology defined in [RFC4655], [RFC4726], and [RFC5440]. Additional terms are defined below.
このドキュメントでは、[RFC4655]、[RFC4726]、および[RFC5440]で定義されているPCE用語を使用しています。追加の用語を以下に定義します。
Domain Path: The sequence of domains for a path.
ドメインパス：パスのドメインのシーケンス。
Ingress Domain: The domain that includes the ingress LSR of a path.
入力ドメイン：パスの入力LSRを含むドメイン。
Transit Domain: A domain that has an upstream and downstream neighbor domain for a specific path.
トランジットドメイン：特定のパスのアップストリームとダウンストリームの隣接ドメインを持つドメイン。
Egress Domain: The domain that includes the egress LSR of a path.
出力ドメイン：パスの出力LSRを含むドメイン。
Boundary Nodes: Each Domain has entry LSRs and exit LSRs that could be Area Border Routers (ABRs) or Autonomous System Border Routers (ASBRs) depending on the type of domain. They are defined here more generically as Boundary Nodes (BNs).
境界ノード：各ドメインには、ドメインの種類に応じてエリア境界ルーター（ABR）または自律システム境界ルーター（ASBR）になることができるエントリLSRと出口LSRがあります。これらは、ここではより一般的に境界ノード（BN）として定義されています。
Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) on a path.
domain（n）のエントリBN：domain（n-1）をパス上のdomain（n）に接続するBN。
Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) on a path.
domain（n）の終了BN：パス上のdomain（n）をdomain（n + 1）に接続するBN。
Parent Domain: A domain higher up in a domain hierarchy such that it contains other domains (child domains) and potentially other links and nodes.
親ドメイン：ドメイン階層の上位にあるドメインで、他のドメイン（子ドメイン）や、場合によっては他のリンクやノードが含まれています。
Child Domain: A domain lower in a domain hierarchy such that it has a parent domain.
子ドメイン：親ドメインを持つように、ドメイン階層の下位のドメイン。
Parent PCE: A PCE responsible for selecting a path across a parent domain and any number of child domains by coordinating with child PCEs and examining a topology map that shows domain inter-connectivity.
親PCE：子PCEと調整し、ドメインの相互接続性を示すトポロジマップを調べることにより、親ドメインと任意の数の子ドメインにわたるパスを選択するPCE。
Child PCE: A PCE responsible for computing the path across one or more specific (child) domains. A child PCE maintains a relationship with at least one parent PCE.
子PCE：1つ以上の特定の（子）ドメイン間のパスを計算するPCE。子PCEは、少なくとも1つの親PCEとの関係を維持します。
Objective Function (OF): A set of one or more optimization criteria used for the computation of a single path (e.g., path cost minimization), or the synchronized computation of a set of paths (e.g., aggregate bandwidth consumption minimization). See [RFC4655] and [RFC5541].
目的関数（OF）：単一のパスの計算（パスコストの最小化など）、またはパスのセットの同期計算（帯域幅消費の最小化など）に使用される1つ以上の最適化基準のセット。 [RFC4655]と[RFC5541]を参照してください。
This section provides a brief overview of two existing PCE cooperation mechanisms called the Per-Domain Path Computation method and the BRPC method. It describes the applicability of these methods to the multi-domain problem.
このセクションでは、ドメインごとのパス計算法とBRPC法と呼ばれる2つの既存のPCE協調メカニズムの概要を説明します。これらの方法のマルチドメイン問題への適用性について説明します。
The Per-Domain Path Computation method for establishing inter-domain TE-LSPs [RFC5152] defines a technique whereby the path is computed during the signaling process on a per-domain basis. The entry BN of each domain is responsible for performing the path computation for the section of the LSP that crosses the domain, or for requesting that a PCE for that domain computes that piece of the path.
ドメイン間TE-LSPを確立するためのドメインごとのパス計算方法[RFC5152]は、シグナリングプロセス中にドメインごとにパスを計算する手法を定義しています。各ドメインのエントリBNは、ドメインを横断するLSPのセクションのパス計算を実行するか、そのドメインのPCEがパスのその部分を計算するように要求します。
During per-domain path computation, each computation results in a path that crosses the domain to provide connectivity to the next domain in the sequence. The chosen path across the domain will be selected as best according to the optimization characteristics of the computation. The next domain in the sequence is usually indicated in signaling by an identifier of the next domain or the identity of the next entry BN.
ドメインごとのパス計算中、各計算の結果、ドメインを横切るパスが生成され、シーケンス内の次のドメインへの接続が提供されます。ドメイン全体で選択されたパスは、計算の最適化特性に従って最適なものとして選択されます。シーケンスの次のドメインは通常、次のドメインの識別子または次のエントリBNのIDによってシグナリングで示されます。
Per-domain path computation may lead to suboptimal end-to-end paths because the most optimal path in one domain may lead to the choice of an entry BN for the next domain that results in a very poor path across that next domain.
ドメインごとのパス計算は、次善のエンドツーエンドパスにつながる可能性があります。これは、あるドメインの最も最適なパスが次のドメインのエントリBNの選択につながり、その結果、次のドメイン全体のパスが非常に貧弱になるためです。
In the case that the domain path (in particular, the sequence of boundary nodes) is not known, the path computing entity must select an exit BN based on some determination of how to reach the destination that is outside the domain for which the path computing entity has computational responsibility. [RFC5152] suggest that this might be achieved using the IP shortest path as advertised by BGP. Note, however, that the existence of an IP forwarding path does not guarantee the presence of sufficient bandwidth, let alone an optimal TE path. Furthermore, in many GMPLS systems, inter-domain IP routing will not be present. Thus, per-domain path computation may require a significant number of crankback routing attempts to establish even a suboptimal path.
ドメインパス（特に境界ノードのシーケンス）が不明である場合、パス計算エンティティは、パス計算の対象であるドメイン外の宛先に到達する方法の決定に基づいて出口BNを選択する必要がありますエンティティには計算の責任があります。 [RFC5152]は、これがBGPによってアドバタイズされるIP最短パスを使用して達成される可能性があることを示唆しています。ただし、IP転送パスの存在は、最適なTEパスはもちろんのこと、十分な帯域幅の存在を保証するものではないことに注意してください。さらに、多くのGMPLSシステムでは、ドメイン間IPルーティングは存在しません。したがって、ドメインごとのパス計算では、準最適なパスを確立するためにも、かなりの数のクランクバックルーティングを試行する必要があります。
Note also that the path computing entities in each domain may have different computation capabilities, may run different path computation algorithms, and may apply different sets of constraints and optimization criteria, etc.
また、各ドメインのパスコンピューティングエンティティは、異なる計算機能を持ち、異なるパス計算アルゴリズムを実行し、異なるセットの制約や最適化基準などを適用する場合があることに注意してください。
This can result in the end-to-end path being inconsistent and suboptimal.
これにより、エンドツーエンドのパスに一貫性がなくなり、最適ではなくなります。
Per-domain path computation can suit simply connected domains where the preferred points of interconnection are known.
ドメインごとのパス計算は、相互接続の優先ポイントがわかっている単純に接続されたドメインに適しています。
The Backward-Recursive PCE-based Computation (BRPC) [RFC5441] procedure involves cooperation and communication between PCEs in order to compute an optimal end-to-end path across multiple domains. The sequence of domains to be traversed can be determined either before or during the path computation. In the case where the sequence of domains is known, the ingress Path Computation Client (PCC) sends a path computation request to a PCE responsible for the ingress domain. This request is forwarded between PCEs, domain-by-domain, to a PCE responsible for the egress domain. The PCE in the egress domain creates a set of optimal paths from all of the domain entry BNs to the egress LSR. This set is represented as a tree of potential paths called a Virtual Shortest Path Tree (VSPT), and the PCE passes it back to the previous PCE on the domain path. As the VSPT is passed back toward the ingress domain, each PCE computes the optimal paths from its entry BNs to its exit BNs that connect to the rest of the tree. It adds these paths to the VSPT and passes the VSPT on until the PCE for the ingress domain is reached and computes paths from the ingress LSR to connect to the rest of the tree. The ingress PCE then selects the optimal end-to-end path from the tree, and returns the path to the initiating PCC.
後方再帰PCEベースの計算（BRPC）[RFC5441]の手順には、複数のドメインにわたる最適なエンドツーエンドパスを計算するためのPCE間の協調と通信が含まれます。トラバースするドメインのシーケンスは、パス計算の前または最中に決定できます。ドメインのシーケンスがわかっている場合、入力パス計算クライアント（PCC）は、パス計算要求を入力ドメインを担当するPCEに送信します。この要求は、ドメインごとにPCE間で、出力ドメインを担当するPCEに転送されます。出力ドメインのPCEは、すべてのドメインエントリBNから出力LSRへの一連の最適パスを作成します。このセットは、仮想最短パスツリー（VSPT）と呼ばれる潜在的なパスのツリーとして表され、PCEはそれをドメインパス上の以前のPCEに戻します。 VSPTが入力ドメインに戻されると、各PCEは、エントリBNから、ツリーの残りの部分に接続する出口BNまでの最適パスを計算します。これらのパスをVSPTに追加し、入力ドメインのPCEに到達するまでVSPTを渡し、ツリーの残りの部分に接続するために入力LSRからのパスを計算します。次に、入力PCEはツリーから最適なエンドツーエンドパスを選択し、そのパスを開始PCCに返します。
BRPC may suit environments where multiple connections exist between domains and there is no preference for the choice of points of interconnection. It is best suited to scenarios where the domain path is known in advance, but it can also be used when the domain path is not known.
BRPCは、ドメイン間に複数の接続が存在し、相互接続のポイントの選択に優先順位がない環境に適している場合があります。ドメインパスが事前にわかっているシナリオに最適ですが、ドメインパスがわからない場合にも使用できます。
As described above, BRPC can be used to determine an optimal inter-domain path when the domain sequence is known. Even when the sequence of domains is not known, BRPC could be used as follows.
上記のように、BRPCは、ドメインシーケンスがわかっている場合に、最適なドメイン間パスを決定するために使用できます。ドメインのシーケンスが不明な場合でも、BRPCは次のように使用できます。
o The PCC sends a request to a PCE for the ingress domain (the ingress PCE).
o PCCは、入力ドメイン（入力PCE）のPCEに要求を送信します。
o The ingress PCE sends the path computation request direct to a PCE responsible for the domain containing the destination node (the egress PCE).
o 入力PCEは、パス計算要求を、宛先ノードを含むドメイン（出力PCE）を担当するPCEに直接送信します。
o The egress PCE computes an egress VSPT and passes it to a PCE responsible for each of the adjacent (potentially upstream) domains.
o 出力PCEは出力VSPTを計算し、それを隣接する（上流の可能性がある）ドメインのそれぞれに対応するPCEに渡します。
o Each PCE in turn constructs a VSPT and passes it on to all of its neighboring PCEs.
o 次に、各PCEはVSPTを作成し、それを隣接するすべてのPCEに渡します。
o When the ingress PCE has received a VSPT from each of its neighboring domains, it is able to select the optimum path.
o 入力PCEが隣接する各ドメインからVSPTを受信すると、最適なパスを選択できます。
Clearly, this mechanism (which could be called path computation flooding) has significant scaling issues. It could be improved by the application of policy and filtering, but such mechanisms are not simple and would still leave scaling concerns.
明らかに、このメカニズム（パス計算フラッディングと呼ばれることもあります）には、大きなスケーリングの問題があります。ポリシーとフィルタリングを適用することで改善できるかもしれませんが、そのようなメカニズムは単純ではなく、スケーリングの問題が残っています。
In the hierarchical PCE architecture, a parent PCE maintains a domain topology map that contains the child domains (seen as vertices in the topology) and their interconnections (links in the topology). The parent PCE has no information about the content of the child domains; that is, the parent PCE does not know about the resource availability within the child domains, nor does it know about the availability of connectivity across each domain because such knowledge would violate the confidentiality requirement and either would require flooding of full information to the parent (scaling issue) or would necessitate some form of aggregation. The parent PCE is aware of the TE capabilities of the interconnections between child domains as these interconnections are links in its own topology map.
階層PCEアーキテクチャーでは、親PCEは、（トポロジーの頂点として見られる）子ドメインとそれらの相互接続（トポロジーのリンク）を含むドメイントポロジーマップを維持します。親PCEには子ドメインの内容に関する情報はありません。つまり、親PCEは、子ドメイン内のリソースの可用性を認識していません。また、各ドメイン全体の接続の可用性についても認識していません。そのような知識は機密性要件に違反し、完全な情報を親にフラッディングする必要があるためです（スケーリングの問題）、または何らかの形の集約が必要になります。親PCEは、子ドメイン間の相互接続のTE機能を認識しています。これは、これらの相互接続が独自のトポロジマップ内のリンクであるためです。
Note that, in the case that the domains are IGP areas, there is no link between the domains (the ABRs have a presence in both neighboring areas). The parent domain may choose to represent this in its Traffic Engineering Database (TED) as a virtual link that is unconstrained and has zero cost, but this is entirely an implementation issue.
ドメインがIGPエリアである場合、ドメイン間にリンクがないことに注意してください（ABRは両方の隣接エリアに存在します）。親ドメインは、これをそのトラフィックエンジニアリングデータベース（TED）で制約なしでコストがゼロの仮想リンクとして表すことを選択できますが、これは完全に実装上の問題です。
Each child domain has at least one PCE capable of computing paths across the domain. These PCEs are known as child PCEs and have a relationship with the parent PCE. Each child PCE also knows the identity of the domains that neighbor its own domain. A child PCE only knows the topology of the domain that it serves and does not know the topology of other child domains. Child PCEs are also not aware of the general domain mesh connectivity (i.e., the domain topology map) beyond the connectivity to the immediate neighbor domains of the domain it serves.
各子ドメインには、ドメイン全体のパスを計算できるPCEが少なくとも1つあります。これらのPCEは子PCEと呼ばれ、親PCEと関係があります。各子PCEは、自分のドメインに隣接するドメインのIDも知っています。子PCEは、自身が機能するドメインのトポロジのみを認識し、他の子ドメインのトポロジを認識しません。子PCEは、サービス対象のドメインのすぐ隣のドメインへの接続を超えて、一般的なドメインメッシュ接続（つまり、ドメイントポロジマップ）を認識しません。
The parent PCE builds the domain topology map either from configuration or from information received from each child PCE. This tells it how the domains are interconnected including the TE properties of the domain interconnections. But, the parent PCE does not know the contents of the child domains. Discovery of the domain topology and domain interconnections is discussed further in Section 4.3.
親PCEは、構成または各子PCEから受信した情報からドメイントポロジマップを構築します。これは、ドメイン相互接続のTEプロパティを含め、ドメインがどのように相互接続されるかを示します。ただし、親PCEは子ドメインの内容を知りません。ドメイントポロジとドメインの相互接続の検出については、セクション4.3で詳しく説明します。
When a multi-domain path is needed, the ingress PCE sends a request to the parent PCE (using the Path Computation Element Protocol, PCEP [RFC5440]). The parent PCE selects a set of candidate domain paths based on the domain topology and the state of the inter-domain links. It then sends computation requests to the child PCEs responsible for each of the domains on the candidate domain paths. These requests may be sequential or parallel depending on implementation details.
マルチドメインパスが必要な場合、入力PCEは要求を親PCEに送信します（パス計算要素プロトコル、PCEP [RFC5440]を使用）。親PCEは、ドメイントポロジとドメイン間リンクの状態に基づいて、候補ドメインパスのセットを選択します。次に、候補ドメインパス上の各ドメインを担当する子PCEに計算要求を送信します。これらの要求は、実装の詳細に応じて、順次または並列になる場合があります。
Each child PCE computes a set of candidate path segments across its domain and sends the results to the parent PCE. The parent PCE uses this information to select path segments and concatenate them to derive the optimal end-to-end inter-domain path. The end-to-end path is then sent to the child PCE that received the initial path request, and this child PCE passes the path on to the PCC that issued the original request.
各子PCEは、そのドメイン全体で候補パスセグメントのセットを計算し、その結果を親PCEに送信します。親PCEはこの情報を使用してパスセグメントを選択し、それらを連結して最適なエンドツーエンドのドメイン間パスを導き出します。エンドツーエンドパスは、最初のパス要求を受信した子PCEに送信され、この子PCEは元の要求を発行したPCCにパスを渡します。
Specific deployment and implementation scenarios are out of scope of this document. However, the hierarchical PCE architecture described does support the function of parent PCE and child PCE being implemented as a common PCE.
特定の展開と実装のシナリオは、このドキュメントの範囲外です。ただし、説明されている階層PCEアーキテクチャは、共通PCEとして実装されている親PCEおよび子PCEの機能をサポートしています。
The definition of "optimal" in the context of deriving an optimal end-to-end path is dependent on the choices that are made during the path selection. An Objective Function (OF) [RFC5541], or set of OFs, specify the intentions of the path computation and so define the "optimality" in the context of that computation.
最適なエンドツーエンドパスを導き出すコンテキストでの「最適」の定義は、パスの選択中に行われる選択に依存します。目的関数（OF）[RFC5541]、またはOFのセットは、パス計算の意図を指定し、その計算のコンテキストで「最適性」を定義します。
An OF specifies the desired outcome of a computation: it does not describe or demand the algorithm to use, and an implementation may apply any algorithm or set of algorithms to achieve the result indicated by the OF. OFs can be included in PCEP computation requests to satisfy the policies encoded or configured at the PCC, and a PCE may be subject to policy in determining whether it meets the OFs included in the computation request, or applies its own OFs.
OFは、計算の望ましい結果を指定します。これは、使用するアルゴリズムを記述したり要求したりするものではなく、実装は、アルゴリズムまたはアルゴリズムのセットを適用して、OFによって示される結果を達成できます。 PCCでエンコードまたは構成されたポリシーを満たすために、PCEP計算要求にOFを含めることができます。PCEは、計算要求に含まれるOFを満たすか、または独自のOFを適用するかを決定する際にポリシーの対象となる場合があります。
In inter-domain path computation, the selection of a domain sequence, the computation of each (per-domain) path fragment, and the determination of the end-to-end path may each be subject to different OFs and different policy.
ドメイン間パス計算では、ドメインシーケンスの選択、各（ドメインごとの）パスフラグメントの計算、およびエンドツーエンドパスの決定は、それぞれ異なるOFと異なるポリシーの対象となる場合があります。
When computing end-to-end paths, OFs may include (see Section 1.3.1):
エンドツーエンドのパスを計算する場合、OFには次のものが含まれます（セクション1.3.1を参照）。
o Minimum cost path o Minimum load path o Maximum residual bandwidth path o Minimize aggregate bandwidth consumption o Minimize or cap the number of transit domains o Disallow domain re-entry
o 最小コストパスo最小負荷パスo最大残余帯域幅パスo総帯域幅消費量を最小化oトランジットドメインの数を最小化または制限oドメイン再入を許可しない
The objective function may be requested by the PCC, the ingress domain PCE (according to local policy), or applied by the parent PCE according to inter-domain policy.
目的関数は、PCC、入力ドメインPCE（ローカルポリシーに従って）によって要求されるか、ドメイン間ポリシーに従って親PCEによって適用されます。
More than one OF (or a composite OF) may be chosen to apply to a single computation provided they are not contradictory. Composite OFs may include weightings and preferences for the fulfillment of pieces of the desired outcome.
複数のOF（または複合OF）を選択して、それらが矛盾しない限り、単一の計算に適用することができます。複合OFには、目的の結果の一部を実現するための重み付けと優先順位を含めることができます。
Information about the content of child domains is not shared for scaling and confidentiality reasons. This means that a parent PCE is aware of the domain topology and the nature of the connections between domains but is not aware of the content of the domains. Similarly, a child PCE cannot know the internal topology of another child domain. Child PCEs also do not know the general domain mesh connectivity; this information is only known by the parent PCE.
子ドメインのコンテンツに関する情報は、スケーリングと機密保持のために共有されません。つまり、親PCEはドメイントポロジとドメイン間の接続の性質を認識していますが、ドメインの内容は認識していません。同様に、子PCEは別の子ドメインの内部トポロジーを知ることができません。子PCEも、一般的なドメインメッシュ接続を認識していません。この情報は、親PCEだけが知っています。
As described in the earlier sections of this document, PCEs can exchange path information in order to construct an end-to-end inter-domain path. Each per-domain path fragment reveals information about the topology and resource availability within a domain. Some management domains or ASes will not want to share this information outside of the domain (even with a trusted parent PCE). In order to conceal the information, a PCE may replace a path segment with a path-key [RFC5520]. This mechanism effectively hides the content of a segment of a path.
このドキュメントの前のセクションで説明したように、PCEはエンドツーエンドのドメイン間パスを構築するためにパス情報を交換できます。ドメインごとのパスフラグメントごとに、ドメイン内のトポロジとリソースの可用性に関する情報が明らかになります。一部の管理ドメインまたはASは、この情報をドメイン外で共有することを望まない場合があります（信頼できる親PCEを使用する場合でも）。情報を隠すために、PCEはパスセグメントをパスキーで置き換える場合があります[RFC5520]。このメカニズムは、パスのセグメントの内容を効果的に隠します。
It is a simple matter for each child PCE to be configured with the address of its parent PCE. Typically, there will only be one or two parents of any child.
各子PCEをその親PCEのアドレスで構成するのは簡単です。通常、子の親は1つまたは2つだけです。
The parent PCE also needs to be aware of the child PCEs for all child domains that it can see. This information is most likely to be configured (as part of the administrative definition of each domain).
親PCEは、表示できるすべての子ドメインの子PCEを認識する必要もあります。この情報は、（各ドメインの管理定義の一部として）構成される可能性が最も高いです。
Discovery of the relationships between parent PCEs and child PCEs does not form part of the hierarchical PCE architecture. Mechanisms that rely on advertising or querying PCE locations across domain or provider boundaries are undesirable for security, scaling, commercial, and confidentiality reasons.
親PCEと子PCE間の関係の発見は、階層PCEアーキテクチャの一部を形成しません。ドメインまたはプロバイダーの境界を越えてPCEロケーションのアドバタイズまたはクエリに依存するメカニズムは、セキュリティ、スケーリング、商用、および機密性の理由から望ましくありません。
The parent PCE also needs to know the inter-domain connectivity. This information could be configured with suitable policy and commercial rules, or could be learned from the child PCEs as described in Section 4.4.
親PCEは、ドメイン間の接続も知っている必要があります。この情報は、適切なポリシーと商用ルールを使用して構成するか、またはセクション4.4で説明されているように子PCEから学習できます。
In order for the parent PCE to learn about domain interconnection, the child PCE will report the identity of its neighbor domains. The IGP in each neighbor domain can advertise its inter-domain TE link capabilities [RFC5316] [RFC5392]. This information can be collected by the child PCEs and forwarded to the parent PCE, or the parent PCE could participate in the IGP in the child domains.
親PCEがドメインの相互接続について学習するために、子PCEはその隣接ドメインのIDを報告します。各ネイバードメインのIGPは、そのドメイン間TEリンク機能[RFC5316] [RFC5392]をアドバタイズできます。この情報は、子PCEによって収集され、親PCEに転送できます。または、親PCEが子ドメインのIGPに参加できます。
The parent PCE maintains a domain topology map of the child domains and their interconnectivity. Where inter-domain connectivity is provided by TE links, the capabilities of those links may also be known to the parent PCE. The parent PCE maintains a TED for the parent domain in the same way that any PCE does.
親PCEは、子ドメインとその相互接続のドメイントポロジマップを保持します。ドメイン間接続がTEリンクによって提供される場合、それらのリンクの機能は親PCEにも認識される場合があります。親PCEは、PCEと同じ方法で親ドメインのTEDを維持します。
The parent domain may just be the collection of child domains and their interconnectivity, may include details of the inter-domain TE links, and may contain nodes and links in its own right.
親ドメインは、子ドメインとそれらの相互接続の集合である場合があり、ドメイン間の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.
親のTEDを構築するためのメカニズムは、ネットワークがおそらくこれらの問題に対処するためにドメインに分割されているため、管理構成と商業上の問題に大きく依存する可能性があります。
In practice, certain information may be passed from the child domains to the parent PCE to help build the parent TED. In theory, the parent PCE could listen to the routing protocols in the child domains, but this would violate the confidentiality and scaling principles that may be responsible for the partition of the network into domains. So, it is much more likely that a suitable solution will involve specific communication from an entity in the child domain (such as the child PCE) to convey the necessary information. As already mentioned, the "necessary information" relates to how the child domains are inter-connected. The topology and available resources within the child domain do not need to be communicated to the parent PCE: doing so would violate the PCE architecture. Mechanisms for reporting this information are described in the examples in Section 4.6 in abstract terms as a child PCE "reports its neighbor domain connectivity to its parent PCE"; the specifics of a solution are out of scope of this document, but the requirements are indicated in Section 4.8. See Section 6 for a brief discussion of BGP-TE.
実際には、特定の情報が子ドメインから親PCEに渡され、親TEDの構築に役立ちます。理論的には、親PCEは子ドメインのルーティングプロトコルをリッスンできますが、これはネットワークをドメインに分割する原因となる可能性のある機密性とスケーリングの原則に違反します。したがって、適切なソリューションには、必要な情報を伝えるために子ドメインのエンティティ（子PCEなど）からの特定の通信が含まれる可能性がはるかに高くなります。すでに述べたように、「必要な情報」は、子ドメインが相互に接続される方法に関連しています。子ドメイン内のトポロジと使用可能なリソースは、親PCEに伝達する必要はありません。そうすると、PCEアーキテクチャに違反します。この情報を報告するためのメカニズムは、4.6節の例に、子PCEが「その親PCEへのその隣接ドメイン接続を報告する」と抽象的な用語で説明されています。ソリューションの詳細はこのドキュメントの範囲外ですが、要件はセクション4.8に示されています。 BGP-TEの簡単な説明については、セクション6を参照してください。
In models such as ASON (see Section 5.2), it is possible to consider a separate instance of an IGP running within the parent domain where the participating protocol speakers are the nodes directly present in that domain and the PCEs (Routing Controllers) responsible for each of the child domains.
ASON（セクション5.2を参照）などのモデルでは、親ドメイン内で実行されているIGPの個別のインスタンスを検討できます。参加しているプロトコルスピーカーは、そのドメインに直接存在するノードであり、それぞれに責任があるPCE（ルーティングコントローラー）です。子ドメインの。
The PCC asking for an inter-domain path computation is aware of the identity of the destination node by definition. If it knows the egress domain, it can supply this information as part of the path computation request. However, if it does not know the egress domain, this information must be known by the child PCE or known/determined by the parent PCE.
ドメイン間パス計算を要求するPCCは、定義により宛先ノードのIDを認識しています。出力ドメインがわかっている場合、この情報をパス計算要求の一部として提供できます。ただし、出力ドメインがわからない場合、この情報は子PCEによって認識されているか、親PCEによって認識/決定されている必要があります。
In some specialist topologies the parent PCE could determine the destination domain based on the destination address, for example, from configuration. However, this is not appropriate for many multi-domain addressing scenarios. In IP-based multi-domain networks, the parent PCE may be able to determine the destination domain by participating in inter-domain routing. Finally, the parent PCE could issue specific requests to the child PCEs to discover if they contain the destination node, but this has scaling implications.
一部のスペシャリストトポロジでは、親PCEは、構成などから、宛先アドレスに基づいて宛先ドメインを決定できます。ただし、これは多くのマルチドメインアドレス指定シナリオには適していません。 IPベースのマルチドメインネットワークでは、親PCEがドメイン間ルーティングに参加することで宛先ドメインを決定できる場合があります。最後に、親PCEは子PCEに特定の要求を発行して、宛先ノードが含まれているかどうかを検出できますが、これにはスケーリングの影響があります。
For the purposes of this document, the precise mechanism of the discovery of the destination domain is left out of scope. Suffice to say that for each multi-domain path computation some mechanism will be required to determine the location of the destination.
このドキュメントでは、宛先ドメインの検出の正確なメカニズムは範囲外です。各マルチドメインパス計算について、宛先の場所を決定するためにいくつかのメカニズムが必要になると言うだけで十分です。
The following example describes the generic hierarchical domain topology. Figure 1 demonstrates four interconnected domains within a fifth, parent domain. Each domain contains a single PCE:
次の例では、一般的な階層ドメイントポロジについて説明します。図1は、5番目の親ドメイン内の4つの相互接続ドメインを示しています。各ドメインには1つのPCEが含まれています。
o Domain 1 is the ingress domain and child PCE 1 is able to compute paths within the domain. Its neighbors are Domain 2 and Domain 4. The domain also contains the source LSR (S) and three egress boundary nodes (BN11, BN12, and BN13).
o ドメイン1は入力ドメインであり、子PCE 1はドメイン内のパスを計算できます。その隣接ノードはドメイン2とドメイン4です。このドメインには、送信元LSR（S）と3つの出力境界ノード（BN11、BN12、およびBN13）も含まれています。
o Domain 2 is served by child PCE 2. Its neighbors are Domain 1 and Domain 3. The domain also contains four boundary nodes (BN21, BN22, BN23, and BN24).
o ドメイン2は子PCE 2によって処理されます。その隣接ノードはドメイン1とドメイン3です。このドメインには4つの境界ノード（BN21、BN22、BN23、およびBN24）も含まれています。
o Domain 3 is the egress domain and is served by child PCE 3. Its neighbors are Domain 2 and Domain 4. The domain also contains the destination LSR (D) and three ingress boundary nodes (BN31, BN32, and BN33).
o ドメイン3は出力ドメインであり、子PCE 3によって処理されます。その近隣はドメイン2とドメイン4です。このドメインには、宛先LSR（D）と3つの入力境界ノード（BN31、BN32、およびBN33）も含まれています。
o Domain 4 is served by child PCE 4. Its neighbors are Domain 2 and Domain 3. The domain also contains two boundary nodes (BN41 and BN42).
o ドメイン4は子PCE 4によって処理されます。その隣接ノードはドメイン2とドメイン3です。このドメインには2つの境界ノード（BN41とBN42）も含まれています。
All of these domains are contained within Domain 5, which is served by the parent PCE (PCE 5).
これらのドメインはすべて、親PCE（PCE 5）によって処理されるドメイン5に含まれています。
-----------------------------------------------------------------
| Domain 5 |
| ----- |
| |PCE 5| |
| ----- |
| |
| ---------------- ---------------- ---------------- |
| | Domain 1 | | Domain 2 | | Domain 3 | |
| | | | | | | |
| | ----- | | ----- | | ----- | |
| | |PCE 1| | | |PCE 2| | | |PCE 3| | |
| | ----- | | ----- | | ----- | |
| | | | | | | |
| | ----| |---- ----| |---- | |
| | |BN11+---+BN21| |BN23+---+BN31| | |
| | - ----| |---- ----| |---- - | |
| | |S| | | | | |D| | |
| | - ----| |---- ----| |---- - | |
| | |BN12+---+BN22| |BN24+---+BN32| | |
| | ----| |---- ----| |---- | |
| | | | | | | |
| | ---- | | | | ---- | |
| | |BN13| | | | | |BN33| | |
| -----------+---- ---------------- ----+----------- |
| \ / |
| \ ---------------- / |
| \ | | / |
| \ |---- ----| / |
| ----+BN41| |BN42+---- |
| |---- ----| |
| | | |
| | ----- | |
| | |PCE 4| | |
| | ----- | |
| | | |
| | Domain 4 | |
| ---------------- |
| |
-----------------------------------------------------------------
Figure 1: Sample Hierarchical Domain Topology
図1：階層ドメイントポロジの例
Figure 2 shows the view of the domain topology as seen by the parent PCE (PCE 5). This view is an abstracted topology; PCE 5 is aware of domain connectivity but not of the internal topology within each domain.
図2は、親PCE（PCE 5）から見たドメイントポロジのビューを示しています。このビューは抽象化されたトポロジです。 PCE 5はドメイン接続を認識しますが、各ドメイン内の内部トポロジーを認識しません。
----------------------------
| Domain 5 |
| ---- |
| |PCE5| |
| ---- |
| |
| ---- ---- ---- |
| | |---| |---| | |
| | D1 | | D2 | | D3 | |
| | |---| |---| | |
| ---- ---- ---- |
| \ ---- / |
| \ | | / |
| ----| D4 |---- |
| | | |
| ---- |
| |
----------------------------
Figure 2: Abstract Domain Topology as Seen by the Parent PCE
図2：親PCEから見た抽象ドメイントポロジ
Based on the topology in Figure 1, the following is an illustration of the initial hierarchical PCE information exchange.
図1のトポロジに基づいて、次の図は初期の階層PCE情報交換を示しています。
1. Child PCE 1, the PCE responsible for Domain 1, is configured with the location of its parent PCE (PCE 5).
1. 子PCE 1、ドメイン1を担当するPCEは、親PCE（PCE 5）の場所で構成されます。
2. Child PCE 1 establishes contact with its parent PCE. The parent applies policy to ensure that communication with PCE 1 is allowed.
2. 子PCE 1は、親PCEとの接続を確立します。親は、PCE 1との通信が確実に許可されるようにポリシーを適用します。
3. Child PCE 1 listens to the IGP in its domain and learns its inter-domain connectivity. That is, it learns about the links BN11-BN21, BN12-BN22, and BN13-BN41.
3. 子PCE 1は、そのドメインでIGPをリッスンし、そのドメイン間接続を学習します。つまり、リンクBN11-BN21、BN12-BN22、およびBN13-BN41について学習します。
4. Child PCE 1 reports its neighbor domain connectivity to its parent PCE.
4. 子PCE 1は、ネイバードメインの接続を親PCEに報告します。
5. Child PCE 1 reports any change in the resource availability on its inter-domain links to its parent PCE.
5. 子PCE 1は、ドメイン間リンクのリソース可用性の変更を親PCEに報告します。
Each child PCE performs steps 1 through 5 so that the parent PCE can create a domain topology view as shown in Figure 2.
各子PCEはステップ1から5を実行するため、図2に示すように、親PCEはドメイントポロジビューを作成できます。
The procedure below is an example of a source PCC requesting an end-to-end path in a multi-domain environment. The topology is represented in Figure 1. It is assumed that the each child PCE has connected to its parent PCE and exchanged the initial information required for the parent PCE to create its domain topology view as described in Section 4.6.1.
以下の手順は、マルチドメイン環境でエンドツーエンドパスを要求するソースPCCの例です。トポロジを図1に示します。それぞれの子PCEがその親PCEに接続し、4.6.1で説明したように、親PCEがドメイントポロジビューを作成するために必要な初期情報を交換したと想定しています。
1. The source PCC (the ingress LSR in our example) sends a request to the PCE responsible for its domain (PCE 1) for a path to the destination LSR (D).
1. ソースPCC（この例では入力LSR）は、宛先LSR（D）へのパスを要求する、そのドメイン（PCE 1）を担当するPCEに要求を送信します。
2. PCE 1 determines the destination is not in domain 1.
2. PCE 1は、宛先がドメイン1にないと判断します。
3. PCE 1 sends a computation request to its parent PCE (PCE 5).
3. PCE 1は計算要求をその親PCE（PCE 5）に送信します。
4. The parent PCE determines that the destination is in Domain 3. (See Section 4.5.)
4. 親PCEは、宛先がドメイン3にあると判断します（セクション4.5を参照）。
5. PCE 5 determines the likely domain paths according to the domain interconnectivity and TE capabilities between the domains. For example, assuming that the link BN12-BN22 is not suitable for the requested path, three domain paths are determined:
5. PCE 5は、ドメイン間の相互接続性とドメイン間のTE機能に従って、可能性のあるドメインパスを決定します。たとえば、リンクBN12-BN22が要求されたパスに適さないと仮定すると、3つのドメインパスが決定されます。
S-BN11-BN21-D2-BN23-BN31-D S-BN11-BN21-D2-BN24-BN32-D S-BN13-BN41-D4-BN42-BN33-D
S-BN11-BN21-D2-BN23-BN31-D S-BN11-BN21-D2-BN24-BN32-D S-BN13-BN41-D4-BN42-BN33-D
6. PCE 5 sends edge-to-edge path computation requests to PCE 2, which is responsible for Domain 2 (i.e., BN21-to-BN23 and BN21-to-BN24), and to PCE 4 for Domain 4 (i.e., BN41-to-BN42).
6. PCE 5は、エッジツーエッジパス計算リクエストを、ドメイン2（つまり、BN21-to-BN23およびBN21-to-BN24）を担当するPCE 2に、ドメイン4（つまり、BN41-to-BN）を担当するPCE 4に送信します。 -BN42）。
7. PCE 5 sends source-to-edge path computation requests to PCE 1, which is responsible for Domain 1 (i.e., S-to-BN11 and S-to-BN13).
7. PCE 5は、ソースからエッジへのパス計算要求を、ドメイン1を担当するPCE 1（つまり、SからBN11およびSからBN13）に送信します。
8. PCE 5 sends edge-to-egress path computation requests to PCE 3, which is responsible for Domain 3 (i.e., BN31-to-D, BN32-to-D, and BN33-to-D).
8. PCE 5は、ドメイン3を担当するPCE 3（つまり、BN31-to-D、BN32-to-D、およびBN33-to-D）にエッジツーエグレスパス計算要求を送信します。
9. PCE 5 correlates all the computation responses from each child PCE, adds in the information about the inter-domain links, and applies any requested and locally configured policies.
9. PCE 5は、各子PCEからのすべての計算応答を相互に関連付け、ドメイン間リンクに関する情報を追加し、要求されたローカルで構成されたポリシーを適用します。
10. PCE 5 then selects the optimal end-to-end multi-domain path that meets the policies and objective functions, and supplies the resulting path to PCE 1.
10. 次に、PCE 5は、ポリシーと目的関数を満たす最適なエンドツーエンドマルチドメインパスを選択し、結果のパスをPCE 1に提供します。
11. PCE 1 forwards the path to the PCC (the ingress LSR).
11. PCE 1は、PCC（入力LSR）にパスを転送します。
Note that there is no requirement for steps 6, 7, and 8 to be carried out in parallel or in series. Indeed, they could be overlapped with step 5. This is an implementation issue.
ステップ6、7、および8を並列または直列に実行する必要がないことに注意してください。実際、これらはステップ5と重複する可能性があります。これは実装の問題です。
In the event that a child PCE in a domain cannot find a suitable path to the egress, the child PCE should return the relevant error to notify the parent PCE. Depending on the error response, the parent PCE selects one of the following actions:
ドメイン内の子PCEが出口への適切なパスを見つけられない場合、子PCEは関連するエラーを返して親PCEに通知する必要があります。エラー応答に応じて、親PCEは次のいずれかのアクションを選択します。
o Cancel the request and send the relevant response back to the initial child PCE that requested an end-to-end path;
o 要求をキャンセルし、関連する応答を、エンドツーエンドパスを要求した最初の子PCEに送り返します。
o Relax some of the constraints associated with the initial path request; or
o 最初のパス要求に関連するいくつかの制約を緩和します。または
o Select another candidate domain and send the path request to the child PCE responsible for the domain.
o 別の候補ドメインを選択し、ドメインを担当する子PCEにパス要求を送信します。
If the parent PCE does not receive a response from a child PCE within an allotted time period, the parent PCE can elect to:
親PCEが割り当てられた期間内に子PCEから応答を受信しない場合、親PCEは以下を選択できます。
o Cancel the request and send the relevant response back to the initial child PCE that requested an end-to-end path; o Send the path request to another child PCE in the same domain, if a secondary child PCE exists; o Select another candidate domain and send the path request to the child PCE responsible for that domain.
o 要求をキャンセルし、関連する応答を、エンドツーエンドパスを要求した最初の子PCEに送り返します。 o 2次子PCEが存在する場合、パス要求を同じドメイン内の別の子PCEに送信します。 o別の候補ドメインを選択し、そのドメインを担当する子PCEにパス要求を送信します。
The parent PCE may also want to prune any unresponsive child PCE domain paths from the candidate set.
親PCEは、候補セットから応答のない子PCEドメインパスを削除することもできます。
This section lists the high-level requirements for extensions to the PCEP to support the hierarchical PCE model. It is provided to offer guidance to PCEP protocol developers in designing a solution suitable for use in a hierarchical PCE framework.
このセクションでは、階層PCEモデルをサポートするためのPCEPの拡張機能の高レベルな要件を示します。階層型PCEフレームワークでの使用に適したソリューションを設計する際に、PCEPプロトコル開発者にガイダンスを提供するために提供されています。
Path Computation Request (PCReq) messages are used by a PCC or a PCE to make a computation request or enquiry to a PCE. The requests are qualified so that the PCE knows what type of action is required.
パス計算要求（PCReq）メッセージは、PCCまたはPCEが計算要求またはPCEへの問い合わせを行うために使用されます。 PCEが必要なアクションのタイプを認識するように、要求は修飾されます。
Support of the hierarchical PCE architecture will introduce two new qualifications as follows:
階層PCEアーキテクチャのサポートにより、次の2つの新しい資格が導入されます。
o It must be possible for a child PCE to indicate that the response it receives from the parent PCE should consist of a domain sequence only (i.e., not a fully specified end-to-end path). This allows the child PCE to initiate Per-Domain or BRPC.
o 子PCEは、親PCEから受信した応答がドメインシーケンスのみで構成される必要があることを示すことができる必要があります（つまり、完全に指定されたエンドツーエンドパスではありません）。これにより、子PCEはドメインごとまたはBRPCを開始できます。
o A parent PCE may need to be able to ask a child PCE whether a particular node address (the destination of an end-to-end path) is present in the domain that the child PCE serves.
o 親PCEは、特定のノードアドレス（エンドツーエンドパスの宛先）が子PCEがサービスを提供するドメインに存在するかどうかを子PCEに問い合わせることができる必要がある場合があります。
In PCEP, such request qualifications are carried as bit flags in the RP object (Request Parameter object) within the PCReq message.
PCEPでは、このような要求修飾は、PCReqメッセージ内のRPオブジェクト（要求パラメーターオブジェクト）のビットフラグとして伝達されます。
Although parent/child PCE relationships are likely configured, it will assist network operations if the parent PCE is able to indicate to the child that it really is capable of acting as a parent PCE. This will help to trap misconfigurations.
親/子PCE関係が構成されている可能性がありますが、親PCEが子に本当にそれが親PCEとして機能できることを示すことができる場合、ネットワーク操作を支援します。これは、誤った構成をトラップするのに役立ちます。
In PCEP, such capabilities are carried in the Open Object within the Open message.
PCEPでは、このような機能はOpenメッセージ内のOpenオブジェクトで伝達されます。
A PCE that is capable of acting as a parent PCE might not be configured or willing to act as the parent for a specific child PCE. This fact could be determined when the child sends a PCReq that requires parental activity (such as querying other child PCEs), and could result in a negative response in a PCEP Error (PCErr) message.
親PCEとして機能できるPCEが構成されていないか、特定の子PCEの親として機能する意思がある可能性があります。この事実は、子が親アクティビティー（他の子PCEの照会など）を必要とするPCReqを送信したときに判別でき、PCEPエラー（PCErr）メッセージで否定応答が返される可能性があります。
However, the expense of a poorly targeted PCReq can be avoided if the child PCE indicates that it might wish to use the parent-capable PCE as a parent (for example, on the Open message), and if the parent-capable PCE determines at that time whether it is willing to act as a parent to this child.
ただし、ターゲットが適切でないPCReqの費用は、子PCEが親として機能するPCEを親として（たとえば、Openメッセージで）使用する可能性があることを示し、親が機能するPCEがそのとき、この子の親として行動する用意があるかどうか。
Section 4.4 describes how the parent PCE needs a parent TED and indicates that the information might be supplied from the child PCEs in each domain. This requires a mechanism whereby information about inter-domain links can be supplied by a child PCE to a parent PCE, for example, on a PCEP Notify (PCNtf) message.
セクション4.4では、親PCEが親TEDを必要とする方法を説明し、情報が各ドメインの子PCEから提供される可能性があることを示しています。これには、ドメイン間リンクに関する情報を子PCEから親PCEに、たとえばPCEP通知（PCNtf）メッセージで提供できるメカニズムが必要です。
The information that would be exchanged includes:
交換される情報は次のとおりです。
o Identifier of advertising child PCE o Identifier of PCE's domain o Identifier of the link o TE properties of the link (metrics, bandwidth) o Other properties of the link (technology-specific) o Identifier of link endpoints o Identifier of adjacent domain
o 広告する子PCEの識別子o PCEのドメインの識別子oリンクの識別子oリンクのTEプロパティ（メトリック、帯域幅）oリンクのその他のプロパティ（技術固有）oリンクエンドポイントの識別子o隣接するドメインの識別子
It may be desirable for this information to be periodically updated, for example, when available bandwidth changes. In this case, the parent PCE might be given the ability to configure thresholds in the child PCE to prevent flapping of information.
この情報は、たとえば、利用可能な帯域幅が変化したときに定期的に更新されることが望ましい場合があります。この場合、親PCEには、情報のフラッピングを防止するために子PCEにしきい値を構成する機能が与えられる場合があります。
Domain identifiers are already present in PCEP to allow a PCE to indicate which domains it serves, and to allow the representation of domains as abstract nodes in paths. The wider use of domains in the context of this work on hierarchical PCE will require that domains can be identified in more places within objects in PCEP messages. This should pose no problems.
ドメインIDはPCEPにすでに存在しており、PCEがサービスを提供するドメインを示したり、パス内の抽象ノードとしてドメインを表現したりすることができます。階層PCEに関するこの作業のコンテキストでドメインを広く使用するには、PCEPメッセージ内のオブジェクト内のより多くの場所でドメインを識別できる必要があります。これで問題は発生しません。
However, more attention may need to be applied to the precision of domain identifier definitions to ensure that it is always possible to unambiguously identify a domain from its identifier. This work will be necessary in configuration, and also in protocol specifications (for example, an OSPF area identifier is sufficient within an Autonomous System, but becomes ambiguous in a path that crosses multiple Autonomous Systems).
ただし、ドメイン識別子の定義からドメインを常に明確に識別できるようにするには、ドメイン識別子の定義の精度にさらに注意を払う必要がある場合があります。この作業は、構成およびプロトコル仕様でも必要になります（たとえば、OSPFエリアIDは自律システム内では十分ですが、複数の自律システムを横断するパスではあいまいになります）。
As per [RFC4655], PCE can inherently support inter-domain path computation for any definition of a domain as set out in Section 1.2 of this document.
[RFC4655]に従い、PCEはこのドキュメントのセクション1.2で説明されているように、ドメインの任意の定義のドメイン間パス計算を本質的にサポートできます。
Hierarchical PCE can be applied to inter-domain environments, including autonomous Systems and IGP areas. The hierarchical PCE procedures make no distinction between, autonomous Systems and IGP area applications, although it should be noted that the TED maintained by a parent PCE must be able to support the concept of child domains connected by inter-domain links or directly connected at boundary nodes (see Section 3).
階層型PCEは、自律システムやIGPエリアを含むドメイン間環境に適用できます。階層型PCE手順は、自律システムとIGPエリアアプリケーションを区別しませんが、親PCEによって維持されるTEDは、ドメイン間リンクによって接続された、または境界で直接接続された子ドメインの概念をサポートできる必要があることに注意してください。ノード（セクション3を参照）。
This section sets out the applicability of hierarchical PCE to three environments:
このセクションでは、階層PCEの3つの環境への適用性について説明します。
o MPLS traffic engineering across multiple Autonomous Systems o MPLS traffic engineering across multiple IGP areas o GMPLS traffic engineering in the ASON architecture
o 複数の自律システムにわたるMPLSトラフィックエンジニアリングo複数のIGPエリアにわたるMPLSトラフィックエンジニアリングo ASONアーキテクチャにおけるGMPLSトラフィックエンジニアリング
Networks are comprised of domains. A domain can be considered to be a collection of network elements within an AS or area that has a common sphere of address management or path computational responsibility.
ネットワークはドメインで構成されています。ドメインは、アドレス管理またはパス計算の責任の共通の領域を持つASまたはエリア内のネットワーク要素のコレクションと見なすことができます。
As networks increase in size and complexity it may be required to introduce scaling methods to reduce the amount information flooded within the network and make the network more manageable. An IGP hierarchy is designed to improve IGP scalability by dividing the IGP domain into areas and limiting the flooding scope of topology information to within area boundaries. This restricts a router's visibility to information about links and other routers within the single area. If a router needs to compute a route to destination located in another area, a method is required to compute a path across the area boundary.
ネットワークのサイズと複雑さが増大するにつれて、ネットワーク内に氾濫する情報の量を減らし、ネットワークをより管理しやすくするためのスケーリング方法を導入することが必要になる場合があります。 IGP階層は、IGPドメインをエリアに分割し、トポロジー情報のフラッディングスコープをエリア境界内に制限することにより、IGPのスケーラビリティを向上させるように設計されています。これにより、ルーターの可視性が、単一エリア内のリンクおよび他のルーターに関する情報に制限されます。ルーターが別のエリアにある宛先へのルートを計算する必要がある場合、エリア境界を越えるパスを計算する方法が必要です。
When an LSR within an AS or area needs to compute a path across an area or AS boundary, it must also use an inter-AS computation technique. Hierarchical PCE is equally applicable to computing inter-area and inter-AS MPLS and GMPLS paths across domain boundaries.
ASまたはエリア内のLSRがエリアまたはAS境界を横切るパスを計算する必要がある場合、AS間計算手法も使用する必要があります。階層型PCEは、ドメイン境界をまたがるエリア間およびAS間MPLSおよびGMPLSパスの計算に等しく適用できます。
The International Telecommunication Union (ITU) defines the ASON architecture in [G-8080]. [G-7715] defines the routing architecture for ASON and introduces a hierarchical architecture. In this architecture, the Routing Areas (RAs) have a hierarchical relationship between different routing levels, which means a parent (or higher-level) RA can contain multiple child RAs. The interconnectivity of the lower RAs is visible to the higher-level RA. Note that the RA hierarchy can be recursive.
国際電気通信連合（ITU）は、[G-8080]でASONアーキテクチャを定義しています。 [G-7715]は、ASONのルーティングアーキテクチャを定義し、階層アーキテクチャを導入します。このアーキテクチャでは、ルーティングエリア（RA）は異なるルーティングレベル間に階層関係を持っています。つまり、親（またはより高いレベル）RAは複数の子RAを含むことができます。下位のRAの相互接続性は、上位のRAに認識されます。 RA階層は再帰的である可能性があることに注意してください。
In the ASON framework, a path computation request is termed a Route Query. This query is executed before signaling is used to establish an LSP termed a Switched Connection (SC) or a Soft Permanent Connection (SPC). [G-7715-2] defines the requirements and architecture for the functions performed by Routing Controllers (RCs) during the operation of remote route queries -- an RC is synonymous with a PCE. For an end-to-end connection, the route may be computed by a single RC or multiple RCs in a collaborative manner (i.e., RC federations). In the case of RC federations, [G-7715-2] describes three styles during remote route query operation:
ASONフレームワークでは、パス計算リクエストはルートクエリと呼ばれます。このクエリは、シグナリングを使用してスイッチド接続（SC）またはソフトパーマネント接続（SPC）と呼ばれるLSPを確立する前に実行されます。 [G-7715-2]は、リモートルートクエリの操作中にルーティングコントローラ（RC）によって実行される機能の要件とアーキテクチャを定義します。RCはPCEと同義です。エンドツーエンド接続の場合、ルートは、単一のRCまたは複数のRCによって協調的に計算されます（つまり、RCフェデレーション）。 RCフェデレーションの場合、[G-7715-2]はリモートルートクエリ操作中の3つのスタイルを説明しています。
o step-by-step remote path computation o hierarchical remote path computation o a combination of the above.
o ステップバイステップのリモートパス計算o階層型リモートパス計算o上記の組み合わせ。
In a hierarchical ASON routing environment, a child RC may communicate with its parent RC (at the next higher level of the ASON routing hierarchy) to request the computation of an end-to-end path across several RAs. It does this using a route query message (known as the abstract message RI_QUERY). The corresponding parent RC may communicate with other child RCs that belong to other child RAs at the next lower hierarchical level. Thus, a parent RC can act as either a Route Query Requester or Route Query Responder.
階層型ASONルーティング環境では、子RCはその親RCと通信して（ASONルーティング階層の1つ上のレベル）、複数のRAにわたるエンドツーエンドパスの計算を要求します。これは、ルートクエリメッセージ（抽象メッセージRI_QUERYと呼ばれる）を使用して行われます。対応する親RCは、次に下位の階層レベルにある他の子RAに属する他の子RCと通信できます。したがって、親RCは、ルートクエリリクエスターまたはルートクエリレスポンダーとして機能できます。
It can be seen that the hierarchical PCE architecture fits the hierarchical ASON routing architecture well. It can be used to provide paths across subnetworks and to determine end-to-end paths in networks constructed from multiple subnetworks or RAs.
階層PCEアーキテクチャが階層ASONルーティングアーキテクチャによく適合していることがわかります。これを使用して、サブネットワーク全体にパスを提供し、複数のサブネットワークまたはRAから構築されたネットワークのエンドツーエンドパスを決定できます。
When hierarchical PCE is applied to implement hierarchical remote path computation in [G-7715-2], it is very important for operators to understand the different terminology and implicit consistency between hierarchical PCE and [G-7715-2].
[G-7715-2]で階層型リモートパス計算を実装するために階層型PCEを適用する場合、オペレーターが階層型PCEと[G-7715-2]の間の異なる用語と暗黙の一貫性を理解することは非常に重要です。
This section highlights the correspondence between features of the hierarchical PCE architecture and the ASON routing architecture.
このセクションでは、階層型PCEアーキテクチャの機能とASONルーティングアーキテクチャの機能の対応について説明します。
(1) RC (Routing Controller) and PCE (Path Computation Element)
（1）RC（ルーティングコントローラー）とPCE（パス計算要素）
[G-8080] describes the Routing Controller component as an abstract entity, which is responsible for responding to requests for path (route) information and topology information. It can be implemented as a single entity, or as a distributed set of entities that make up a cooperative federation.
[G-8080]は、ルーティングコントローラーコンポーネントを、パス（ルート）情報とトポロジー情報の要求に応答する責任を持つ抽象エンティティとして説明しています。これは、単一のエンティティとして、または協調フェデレーションを構成するエンティティの分散セットとして実装できます。
[RFC4655] describes PCE (Path Computation Element) is 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.
[RFC4655]は、PCE（パス計算要素）が、ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算の制約を適用できるエンティティ（コンポーネント、アプリケーション、またはネットワークノード）について説明しています。
Therefore, in the ASON architecture, a PCE can be regarded as a realization of the RC.
したがって、ASONアーキテクチャでは、PCEはRCの実現と見なすことができます。
(2) Route Query Requester/Route Query Responder and PCC/PCE
（2）Route Query Requester / Route Query ResponderおよびPCC / PCE
[G-7715-2] describes the Route Query Requester as a Connection Controller or Routing Controller that sends a route query message to a Routing Controller requesting one or more paths that satisfy a set of routing constraints. The Route Query Responder is a Routing Controller that performs path computation upon receipt of a route query message from a Route Query Requester, sending a response back at the end of the path computation.
[G-7715-2]では、ルートクエリリクエスターを、ルーティングコントローラーにルーティングクエリメッセージを送信して、ルーティング制約のセットを満たす1つ以上のパスを要求するルーティングコントローラーに送信する接続コントローラーまたはルーティングコントローラーとして説明しています。 Route Query Responderは、Route Query Requesterからのルートクエリメッセージの受信時にパス計算を実行し、パス計算の最後に応答を送信するルーティングコントローラです。
In the context of ASON, a Signaling Controller initiates and processes signaling messages and is closely coupled to a Signaling Protocol Speaker. A Routing Controller makes routing decisions and is usually coupled to configuration entities and/or a Routing Protocol Speaker.
ASONのコンテキストでは、シグナリングコントローラはシグナリングメッセージを開始および処理し、シグナリングプロトコルスピーカーと密接に結合されます。ルーティングコントローラはルーティングの決定を行い、通常は構成エンティティやルーティングプロトコルスピーカーに結合されます。
It can be seen that a PCC corresponds to a Route Query Requester, and a PCE corresponds to a Route Query Responder. A PCE/RC can also act as a Route Query Requester sending requests to another Route Query Responder.
PCCはRoute Query Requesterに対応し、PCEはRoute Query Responderに対応することがわかります。 PCE / RCは、別のルートクエリレスポンダにリクエストを送信するルートクエリリクエスタとしても機能します。
The Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages between PCC and PCE correspond to the RI_QUERY and RI_UPDATE messages in [G-7715-2].
PCCとPCE間のパス計算要求（PCReq）およびパス計算応答（PCRep）メッセージは、[G-7715-2]のRI_QUERYおよびRI_UPDATEメッセージに対応します。
(3) Routing Area Hierarchy and Hierarchical Domain
（3）ルーティングエリア階層と階層ドメイン
The ASON routing hierarchy model is shown in Figure 6 of [G-7715] through an example that illustrates routing area levels. If the hierarchical remote path computation mechanism of [G-7715-2] is applied in this scenario, each routing area should have at least one RC to perform the route query function, and the child RCs within the area should have a parent RC.
ASONルーティング階層モデルは、[G-7715]の図6に、ルーティングエリアレベルを示す例を通して示されています。このシナリオで[G-7715-2]の階層型リモートパス計算メカニズムを適用する場合、各ルーティングエリアにはルートクエリ機能を実行するための少なくとも1つのRCが必要であり、エリア内の子RCには親RCが必要です。
According to [G-8080], the parent RC has visibility of the structure of the lower level, so it knows the interconnectivity of the RAs in the lower level. Each child RC can compute edge-to-edge paths across its own child RA.
[G-8080]によると、親RCは下位レベルの構造の可視性を持っているため、下位レベルのRAの相互接続性を知っています。各子RCは、自身の子RA全体のエッジ間パスを計算できます。
Thus, an RA corresponds to a domain in the PCE architecture, and the hierarchical relationship between RAs corresponds to the hierarchical relationship between domains in the hierarchical PCE architecture. Furthermore, a parent PCE in a parent domain can be regarded as parent RC in a higher routing level, and a child PCE in a child domain can be regarded as child RC in a lower routing level.
したがって、RAはPCEアーキテクチャのドメインに対応し、RA間の階層関係は階層PCEアーキテクチャのドメイン間の階層関係に対応します。さらに、親ドメインの親PCEは、上位のルーティングレベルでは親RCと見なすことができ、子ドメインの子PCEは、下位のルーティングレベルでは子RCと見なすことができます。
RCs in an ASON environment can use the hierarchical PCE model to fully match the ASON hierarchical routing model, so the hierarchical PCE mechanisms can be applied to fully satisfy the architecture and requirements of [G-7715-2] without any changes. If the hierarchical PCE mechanism is applied in ASON, it can be used to determine end-to-end optimized paths across subnetworks and RAs before initiating signaling to create the connection. It can also improve the efficiency of connection setup to avoid crankback.
ASON環境のRCは、階層PCEモデルを使用してASON階層ルーティングモデルと完全に一致させることができるため、階層PCEメカニズムを適用して、変更することなく[G-7715-2]のアーキテクチャと要件を完全に満たすことができます。階層PCEメカニズムがASONに適用されている場合、それを使用して、接続を作成するためのシグナリングを開始する前に、サブネットワークとRA間のエンドツーエンドの最適化されたパスを決定できます。また、接続設定の効率を改善して、クランクバックを回避することもできます。
The concept of exchange of TE information between Autonomous Systems (ASes) is discussed in [BGP-TE]. The information exchanged in this way could be the full TE information from the AS, an aggregation of that information, or a representation of the potential connectivity across the AS. Furthermore, that information could be updated frequently (for example, for every new LSP that is set up across the AS) or only at threshold-crossing events.
自律システム（AS）間のTE情報の交換の概念は、[BGP-TE]で説明されています。この方法で交換される情報は、ASからの完全なTE情報、その情報の集約、またはAS全体の潜在的な接続の表現です。さらに、その情報は頻繁に更新されるか（たとえば、AS全体でセットアップされるすべての新しいLSPに対して）、またはしきい値超過イベントでのみ更新されます。
There are a number of discussion points associated with the use of [BGP-TE] concerning the volume of information, the rate of churn of information, the confidentiality of information, the accuracy of aggregated or potential-connectivity information, and the processing required to generate aggregated information. The PCE architecture and the architecture enabled by [BGP-TE] make different assumptions about the operational objectives of the networks, and this document does not attempt to make one of the approaches "right" and the other "wrong". Instead, this work assumes that a decision has been made to utilize the PCE architecture.
[BGP-TE]の使用に関連して、情報量、情報のチャーン率、情報の機密性、集約された情報または潜在的な接続情報の正確性、および集約情報を生成します。 PCEアーキテクチャと[BGP-TE]によって可能になるアーキテクチャは、ネットワークの運用目標について異なる仮定を行っています。このドキュメントでは、アプローチの1つを「正しく」、もう1つを「間違って」いることを試みていません。代わりに、この作業では、PCEアーキテクチャを利用する決定が行われたと想定しています。
Indeed, [BGP-TE] may have some uses within the PCE model. For example, [BGP-TE] could be used as a "northbound" TE advertisement such that a PCE does not need to listen to an IGP in its domain, but has its TED populated by messages received (for example) from a Route Reflector. Furthermore, the inter-domain connectivity and capabilities that are required information for a parent PCE could be obtained as a filtered subset of the information available in [BGP-TE]. This scenario is discussed further in [PCE-AREA-AS].
実際、[BGP-TE]はPCEモデル内でいくつかの用途があるかもしれません。たとえば、[BGP-TE]は「ノースバウンド」TEアドバタイズメントとして使用でき、PCEはそのドメインでIGPをリッスンする必要はありませんが、ルートリフレクターから受信したメッセージなどによってTEDが入力されます。 。さらに、親PCEに必要な情報であるドメイン間接続と機能は、[BGP-TE]で利用可能な情報のフィルタリングされたサブセットとして取得できます。このシナリオについては、[PCE-AREA-AS]でさらに説明します。
General PCE management considerations are discussed in [RFC4655]. In the case of the hierarchical PCE architecture, there are additional management considerations.
PCE管理の一般的な考慮事項は、[RFC4655]で説明されています。階層PCEアーキテクチャの場合、追加の管理上の考慮事項があります。
The administrative entity responsible for the management of the parent PCEs must be determined. 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. 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.
親PCEの管理を担当する管理エンティティを決定する必要があります。単一のサービスプロバイダーネットワーク内のマルチドメイン（IGPエリアや複数のASなど）の場合、親PCEの管理責任は、ほとんどの場合サービスプロバイダーによって処理されます。異なるサービスプロバイダーネットワーク内の複数のASの場合、サードパーティが、参加している各サービスプロバイダーからの商業契約およびポリシー契約に従って親PCEを管理する必要がある場合があります。
Support of the hierarchical procedure will be controlled by the management organization responsible for each child PCE. A child PCE must be configured with the address of its parent PCE in order for it to interact with its parent PCE. The child PCE must also be authorized to peer with the parent PCE.
階層的手順のサポートは、各子PCEを担当する管理組織によって制御されます。子PCEが親PCEと対話するためには、子PCEに親PCEのアドレスを構成する必要があります。子PCEは、親PCEとピアリングすることも許可されている必要があります。
The parent PCE must only accept path computation requests from authorized child PCEs. If a parent PCE receives requests from an unauthorized child PCE, the request should be dropped.
親PCEは、許可された子PCEからのパス計算要求のみを受け入れる必要があります。親PCEが無許可の子PCEから要求を受け取った場合、その要求はドロップする必要があります。
This means that a parent PCE must 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が承認できるようにする何らかの形式の共有シークレットが必要です。
It may be necessary to maintain a policy module on the parent PCE [RFC5394]. This would allow the parent PCE to apply commercially relevant constraints such as SLAs, security, peering preferences, and monetary costs.
親PCEでポリシーモジュールを維持する必要がある場合があります[RFC5394]。これにより、親PCEはSLA、セキュリティ、ピアリング設定、金銭的コストなどの商業的に関連する制約を適用できます。
It may also be necessary for the parent PCE to limit end-to-end path selection by including or excluding specific domains based on commercial relationships, security implications, and reliability.
また、商業上の関係、セキュリティへの影響、および信頼性に基づいて特定のドメインを含めたり除外したりして、親PCEがエンドツーエンドのパス選択を制限する必要がある場合もあります。
A PCEP MIB module is defined in [PCEP-MIB] that describes managed objects for modeling of PCEP communication. An additional PCEP MIB will be required to report parent PCE and child PCE information, including:
PCEP MIBモジュールは、[PCEP-MIB]で定義され、PCEP通信のモデリング用の管理対象オブジェクトを記述します。親PCEおよび子PCE情報を報告するには、以下を含む追加のPCEP MIBが必要です。
o parent PCE configuration and status,
o 親PCEの構成とステータス
o child PCE configuration and information,
o 子PCEの構成と情報
o notifications to indicate session changes between parent PCEs and child PCEs, and
o 親PCEと子PCE間のセッションの変更を示す通知
o notification of parent PCE TED updates and changes.
o 親PCE TEDの更新と変更の通知。
The hierarchical procedure requires interaction with multiple PCEs. Once a child PCE requests an end-to-end path, a sequence of events occurs that requires interaction between the parent PCE and each child PCE. If a child PCE is not operational, and an alternate transit domain is not available, then a failure must be reported.
階層的な手順では、複数のPCEとの相互作用が必要です。子PCEがエンドツーエンドのパスを要求すると、親PCEと各子PCE間の相互作用を必要とする一連のイベントが発生します。子PCEが機能せず、代替の中継ドメインが利用できない場合は、障害を報告する必要があります。
Verifying the correct operation of a parent PCE can be performed by monitoring a set of parameters. The parent PCE implementation should provide the following parameters monitored by the parent PCE: o number of child PCE requests,
親PCEが正しく動作していることを確認するには、一連のパラメーターを監視します。親PCE実装は、親PCEによって監視される次のパラメーターを提供する必要があります。o子PCE要求の数、
o number of successful hierarchical PCE procedures completions on a per-PCE-peer basis,
o PCEピアごとの成功した階層PCEプロシージャ完了の数
o number of hierarchical PCE procedure completion failures on a per-PCE-peer basis, and
o PCEピアごとの階層的PCEプロシージャ完了失敗の数、および
o number of hierarchical PCE procedure requests from unauthorized child PCEs.
o 無許可の子PCEからの階層PCEプロシージャリクエストの数。
The hierarchical PCE procedure is a multiple-PCE path computation scheme. Subsequent requests to and from the child and parent PCEs do not differ from other path computation requests and should not have any significant impact on network operations.
階層PCE手順は、複数PCEパス計算方式です。子PCEと親PCEとの間の以降の要求は、他のパス計算要求と同じであり、ネットワーク操作に大きな影響を与えることはありません。
The hierarchical PCE procedure relies on PCEP and inherits the security requirements defined in [RFC5440]. As noted in Section 7, there is a security relationship between child and parent PCEs. This relationship, like any PCEP relationship, assumes pre-configuration of identities, authority, and keys, or can operate through any key distribution mechanism outside the scope of PCEP. As PCEP operates over TCP, it may make use of any TCP security mechanism.
階層的PCE手順はPCEPに依存し、[RFC5440]で定義されたセキュリティ要件を継承します。セクション7で述べたように、子PCEと親PCEの間にはセキュリティ関係があります。この関係は、他のPCEP関係と同様に、ID、権限、およびキーの事前構成を想定しているか、PCEPの範囲外の任意のキー配布メカニズムを通じて動作できます。 PCEPはTCPで動作するため、TCPセキュリティメカニズムを利用できます。
The hierarchical PCE architecture makes use of PCE policy [RFC5394] and the security aspects of the PCE Communication Protocol documented in [RFC5440]. It is expected that the parent PCE will require all child PCEs to use full security when communicating with the parent and that security will be maintained by not supporting the discovery by a parent of child PCEs.
階層型PCEアーキテクチャは、PCEポリシー[RFC5394]と、[RFC5440]で文書化されているPCE通信プロトコルのセキュリティの側面を利用しています。親PCEは、すべての子PCEが親と通信するときに完全なセキュリティを使用することを要求し、セキュリティは親による子PCEの検出をサポートしないことによって維持されることが期待されます。
PCE operation also relies on information used to build the TED. Attacks on a PCE system may be achieved by falsifying or impeding this flow of information. The child PCE TEDs are constructed as described in [RFC4655] and are unchanged in this document: if the PCE listens to the IGP for this information, then normal IGP security measures may be applied, and it should be noted that an IGP routing system is generally assumed to be a trusted domain such that router subversion is not a risk. The parent PCE TED is constructed as described in this document and may involve:
PCE操作は、TEDの構築に使用される情報にも依存します。 PCEシステムへの攻撃は、この情報の流れを改ざんしたり妨害したりすることによって行われる可能性があります。子PCE TEDは[RFC4655]で説明されているように構築され、このドキュメントでは変更されていません。PCEがこの情報をIGPでリッスンしている場合、通常のIGPセキュリティ対策が適用される場合があり、IGPルーティングシステムが一般に、ルーターの破壊がリスクにならないように、信頼されたドメインであると想定されます。親PCE TEDは、このドキュメントで説明されているように構成されており、以下を含む場合があります。
- multiple parent-child relationships using PCEP (as already described)
- PCEPを使用した複数の親子関係（既に説明したとおり）
- the parent PCE listening to child domain IGPs (with the same security features as a child PCE listening to its IGP)
- 子ドメインIGPをリッスンする親PCE（IGPをリッスンする子PCEと同じセキュリティ機能を備えています）
- an external mechanism (such as [BGP-TE]), which will need to be authorized and secured.
- 外部メカニズム（[BGP-TE]など）。認証およびセキュリティで保護する必要があります。
Any multi-domain operation necessarily involves the exchange of information across domain boundaries. This is bound to represent a significant security and confidentiality risk especially when the child domains are controlled by different commercial concerns. PCEP allows individual PCEs to maintain confidentiality of their domain path information using path-keys [RFC5520], and the hierarchical PCE architecture is specifically designed to enable as much isolation of domain topology and capabilities information as is possible.
マルチドメイン操作では、ドメイン境界を越えた情報の交換が必ず必要です。これは、特に子ドメインがさまざまな商業的関心事によって制御されている場合、重大なセキュリティと機密性のリスクを表すことになります。 PCEPは、個々のPCEがパスキー[RFC5520]を使用してドメインパス情報の機密性を維持できるようにします。階層PCEアーキテクチャは、ドメイントポロジと機能情報を可能な限り分離できるように特別に設計されています。
For further considerations of the security issues related to inter-AS path computation, see [RFC5376].
AS間パス計算に関連するセキュリティ問題の詳細については、[RFC5376]を参照してください。
The authors would like to thank David Amzallag, Oscar Gonzalez de Dios, Franz Rambach, Ramon Casellas, Olivier Dugeon, Filippo Cugini, Dhruv Dhody, and Julien Meuric for their comments and suggestions.
著者は、コメントと提案をしてくれたDavid Amzallag、Oscar Gonzalez de Dios、Franz Rambach、Ramon Casellas、Olivier Dugeon、Filippo Cugini、Dhruv Dhody、およびJulien Meuricに感謝します。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、2006年8月。
[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.
[RFC5152] Vasseur、JP。、編、Ayyangar、A。、編、およびR. Zhang、「ドメイン間トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）を確立するためのドメインごとのパス計算方法」、 RFC 5152、2008年2月。
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008.
[RFC5394] Bryskin、I.、Papadimitriou、D.、Berger、L。、およびJ. Ash、「Policy-Enabled Path Computation Framework」、RFC 5394、2008年12月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、JP。、Ed。、and JL。 Le Roux編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、2009年3月。
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009.
[RFC5441] Vasseur、JP。、Ed。、Zhang、R.、Bitar、N.、and JL。 Le Roux、「最短の制約付きドメイン間トラフィックエンジニアリングラベルスイッチドパスを計算するための後方再帰PCEベースの計算（BRPC）手順」、RFC 5441、2009年4月。
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009.
[RFC5520] Bradford、R。、編、Vasseur、JP、およびA. Farrel、「パスキーベースのメカニズムを使用したドメイン間パス計算でのトポロジー機密性の保持」、RFC 5520、2009年4月。
[RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle, Ed., "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105] Le Roux、J.-L.、Ed。、Vasseur、J.-P.、Ed。、and J. Boyle、Ed。、 "Requirements for Inter-Area MPLS Traffic Engineering"、RFC 4105、June 2005 。
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216] Zhang、R.、Ed。、およびJ.-P. Vasseur編、「MPLS Inter-Autonomous System（AS）Traffic Engineering（TE）Requirements」、RFC 4216、2005年11月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726] Farrel、A.、Vasseur、J.-P。、およびA. Ayyangar、「A Framework for Inter-domain Multiprotocol Label Switching Traffic Engineering」、RFC 4726、2006年11月。
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, December 2008.
[RFC5316] Chen、M.、Zhang、R。、およびX. Duan、「Inter-Autonomous System（AS）MPLSおよびGMPLSトラフィックエンジニアリングをサポートするISIS拡張」、RFC 5316、2008年12月。
[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", RFC 5376, November 2008.
[RFC5376] Bitar、N.、Zhang、R。、およびK. Kumaki、「パス計算要素通信プロトコル（PCECP）のInter-AS要件」、RFC 5376、2008年11月。
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, January 2009.
[RFC5392] Chen、M.、Zhang、R。、およびX. Duan、「Inter-Autonomous System（AS）MPLSおよびGMPLSトラフィックエンジニアリングをサポートするOSPF拡張機能」、RFC 5392、2009年1月。
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, June 2009.
[RFC5541] Le Roux、JL。、Vasseur、JP。、and Y. Lee、 "Encoding of Objective Functions in the Path Computation Element Communication Protocol（PCEP）"、RFC 5541、June 2009。
[G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for the automatically switched optical network (ASON).
[G-8080] ITU-T勧告G.8080 / Y.1304、自動切り替え光ネットワーク（ASON）のアーキテクチャ。
[G-7715] ITU-T Recommendation G.7715 (2002), Architecture and Requirements for the Automatically Switched Optical Network (ASON).
[G-7715] ITU-T勧告G.7715（2002）、自動切り替え光ネットワーク（ASON）のアーキテクチャと要件。
[G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON routing architecture and requirements for remote route query.
[G-7715-2] ITU-T勧告G.7715.2（2007）、ASONルーティングアーキテクチャおよびリモートルートクエリの要件。
[BGP-TE] 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, October 2012.
[BGP-TE] Gredler、H.、Medved、J.、Previdi、S.、Farrel、A。、およびS. Ray、「BGPを使用したリンクステートおよびTE情報の北限定分布」、作業中、 2012年10月。
[PCE-AREA-AS] King, D., Meuric, J., Dugeon, O., Zhao, Q., Gonzalez de Dios, O., and F. Chico, "Applicability of the Path Computation Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic Engineering", Work in Progress, January 2012.
[PCE-AREA-AS] King、D.、Meuric、J.、Dugeon、O.、Zhao、Q.、Gonzalez de Dios、O。、およびF. Chico、「パス計算要素のエリア間への適用性およびInter-AS MPLSおよびGMPLSトラフィックエンジニアリング」、作業中、2012年1月。
[PCEP-MIB] Koushik, A., Emile, S., Zhao, Q., King, D., and J. Hardwick, "PCE communication protocol (PCEP) Management Information Base", Work in Progress, July 2012.
[PCEP-MIB] Koushik、A.、Emile、S.、Zhao、Q.、King、D。、およびJ. Hardwick、「PCE Communication Protocol（PCEP）Management Information Base」、Work in Progress、2012年7月。
Quintin Zhao Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US
Quintin Zhao Huawei Technology 125 Nagog Technology Park Acton、MA 01719 US
EMail: qzhao@huawei.com
Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R. China
fa too Zhang hu AはテクノロジーF3-5-br＆Dセンターであり、hu Aは基本禁止日であり、地区は非常に現実的です518129 P.R. China
EMail: zhangfatai@huawei.com
Authors' Addresses
著者のアドレス
Daniel King Old Dog Consulting UK
Daniel King Old Dog Consulting UK
EMail: daniel@olddog.co.uk
Adrian Farrel Old Dog Consulting UK
エイドリアンファレルオールドドッグコンサルティングイギリス
EMail: adrian@olddog.co.uk