[要約] 要約：RFC 8694は、パス計算要素（PCE）がインターエリアおよびインターアリア間のMPLSおよびGMPLSトラフィックエンジニアリングに適用される方法について説明しています。 目的：このRFCの目的は、PCEの使用を通じて、異なるエリアやAS間でのトラフィックエンジニアリングを改善し、ネットワークの効率性と信頼性を向上させることです。
Internet Engineering Task Force (IETF) D. King
Request for Comments: 8694 Old Dog Consulting
Category: Informational 郑好棉 (H. Zheng)
ISSN: 2070-1721 华为技术有限公司 (Huawei Technologies)
December 2019
Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering
エリア間およびAS間MPLSおよびGMPLSトラフィックエンジニアリングへのパス計算要素の適用性
Abstract
概要
The Path Computation Element (PCE) may be used for computing services that traverse multi-area and multi-Autonomous System (multi-AS) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic-Engineered (TE) networks.
パス計算要素（PCE）は、マルチエリアおよびマルチ自律システム（マルチAS）マルチプロトコルラベルスイッチング（MPLS）および汎用MPLS（GMPLS）トラフィックエンジニアリング（TE）ネットワークを通過するコンピューティングサービスに使用できます。
This document examines the applicability of the PCE architecture, protocols, and protocol extensions for computing multi-area and multi-AS paths in MPLS and GMPLS networks.
このドキュメントでは、MPLSおよびGMPLSネットワークでマルチエリアおよびマルチASパスを計算するための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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8694.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8694で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Domains
1.2. Path Computation
1.2.1. PCE-Based Path Computation Procedure
1.3. Traffic Engineering Aggregation and Abstraction
1.4. Traffic-Engineered Label Switched Paths
1.5. Inter-area and Inter-AS-capable PCE Discovery
1.6. Objective Functions
2. Terminology
3. Issues and Considerations
3.1. Multihoming
3.2. Destination Location
3.3. Domain Confidentiality
4. Domain Topologies
4.1. Selecting Domain Paths
4.2. Domain Sizes
4.3. Domain Diversity
4.4. Synchronized Path Computations
4.5. Domain Inclusion or Exclusion
5. Applicability of the PCE to Inter-area Traffic Engineering
5.1. Inter-area Routing
5.1.1. Area Inclusion and Exclusion
5.1.2. Strict Explicit Path and Loose Path
5.1.3. Inter-Area Diverse Path Computation
6. Applicability of the PCE to Inter-AS Traffic Engineering
6.1. Inter-AS Routing
6.1.1. AS Inclusion and Exclusion
6.2. Inter-AS Bandwidth Guarantees
6.3. Inter-AS Recovery
6.4. Inter-AS PCE Peering Policies
7. Multi-domain PCE Deployment Options
7.1. Traffic Engineering Database and Synchronization
7.1.1. Applicability of BGP-LS to PCE
7.2. Pre-planning and Management-Based Solutions
8. Domain Confidentiality
8.1. Loose Hops
8.2. Confidential Path Segments and Path-Keys
9. Point to Multipoint
10. Optical Domains
10.1. Abstraction and Control of TE Networks (ACTN)
11. Policy
12. Manageability Considerations
12.1. Control of Function and Policy
12.2. Information and Data Models
12.3. Liveness Detection and Monitoring
12.4. Verifying Correct Operation
12.5. Impact on Network Operation
13. Security Considerations
13.1. Multi-domain Security
14. IANA Considerations
15. References
15.1. Normative References
15.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
Computing paths across large multi-domain environments may require special computational components and cooperation between entities in different domains capable of complex path computation.
大規模なマルチドメイン環境全体でパスを計算するには、特別な計算コンポーネントと、複雑なパス計算が可能な異なるドメイン内のエンティティ間の連携が必要になる場合があります。
Issues that may exist when routing in multi-domain networks include the following:
マルチドメインネットワークでのルーティング時に発生する可能性がある問題には、次のものがあります。
* There is often a lack of full topology and TE information across domains.
* 多くの場合、ドメイン全体で完全なトポロジとTE情報が不足しています。
* No single node has the full visibility to determine an optimal or even feasible end-to-end path across domains.
* ドメイン全体の最適な、または実現可能なエンドツーエンドパスを決定するための完全な可視性を持つ単一のノードはありません。
* Knowing how to evaluate and select the exit point and next domain boundary from a domain.
* ドメインからの出口点と次のドメイン境界を評価および選択する方法を知る。
* Understanding how the ingress node determines which domains should be used for the end-to-end path.
* 入力ノードがエンドツーエンドパスに使用するドメインを決定する方法を理解します。
An information exchange across multiple domains is often limited due to the lack of trust relationship, security issues, or scalability issues, even if there is a trust relationship between domains.
複数のドメイン間での情報交換は、ドメイン間に信頼関係がある場合でも、信頼関係の欠如、セキュリティの問題、またはスケーラビリティの問題のために制限されることがよくあります。
The Path Computation Element (PCE) [RFC4655] provides an architecture and a set of functional components to address the problem space and the issues highlighted above.
Path Computation Element（PCE）[RFC4655]は、上記で強調された問題空間と問題に対処するためのアーキテクチャと一連の機能コンポーネントを提供します。
A PCE may be used to compute end-to-end paths across multi-domain environments using a per-domain path computation technique [RFC5152]. The so-called backward recursive PCE-based computation (BRPC) mechanism [RFC5441] defines a path computation procedure to compute inter-domain constrained Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic-Engineered (TE) networks. However, both per-domain and BRPC techniques assume that the sequence of domains to be crossed from source to destination is known, either fixed by the network operator or obtained by other means.
PCEは、ドメインごとのパス計算手法[RFC5152]を使用して、マルチドメイン環境全体のエンドツーエンドパスを計算するために使用できます。いわゆる後方再帰PCEベースの計算（BRPC）メカニズム[RFC5441]は、ドメイン間制約マルチプロトコルラベルスイッチング（MPLS）および一般化MPLS（GMPLS）トラフィックエンジニアリング（TE）ネットワークを計算するパス計算手順を定義します。ただし、ドメインごとの手法とBRPC手法の両方で、送信元から宛先に渡るドメインのシーケンスが既知であり、ネットワークオペレーターによって固定されているか、他の方法で取得されていると想定しています。
In more advanced deployments (including multi-area and multi-Autonomous System (multi-AS) environments), the sequence of domains may not be known in advance, and the choice of domains in the end-to-end domain sequence might be critical to the determination of an optimal end-to-end path. In this case, the use of the hierarchical PCE [RFC6805] architecture and mechanisms may be used to discover the intra-area path and select the optimal end-to-end domain sequence.
より高度な展開（マルチエリアおよびマルチ自律システム（マルチAS）環境を含む）では、ドメインのシーケンスが事前にわかっていない場合があり、エンドツーエンドのドメインシーケンスでのドメインの選択が重要になる場合があります。エンドツーエンドの最適なパスを決定します。この場合、階層型PCE [RFC6805]アーキテクチャとメカニズムを使用して、エリア内パスを検出し、最適なエンドツーエンドドメインシーケンスを選択できます。
This document describes the processes and procedures available when using the PCE architecture and protocols for computing inter-area and inter-AS MPLS and GMPLS Traffic-Engineered paths.
このドキュメントでは、エリア間およびAS間MPLSおよびGMPLSトラフィックエンジニアリングパスを計算するためにPCEアーキテクチャとプロトコルを使用するときに利用可能なプロセスと手順について説明します。
The scope of this document does not include discussions of deployment scenarios for stateful PCE, active PCE, remotely initiated PCE, or PCE as a central controller (PCECC).
このドキュメントの範囲には、ステートフルPCE、アクティブPCE、リモートで開始されたPCE、または中央コントローラー（PCECC）としてのPCEの展開シナリオの説明は含まれていません。
Generally, 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 (as per [RFC4726] and [RFC4655]).
一般に、ドメインは、ネットワーク内の個別の管理環境、地理的環境、またはスイッチング環境として定義できます。ドメインは、ルーティングまたは計算能力のゾーンとしてさらに定義できます。これらの定義では、ドメインは自律システム（AS）または内部ゲートウェイプロトコル（IGP）エリアとして分類される場合があります（[RFC4726]および[RFC4655]に従って）。
For the purposes of this document, a domain is considered to be a collection of network elements within an area or AS that has a common sphere of address management or path computational responsibility. Wholly or partially overlapping domains are not within the scope of this document.
このドキュメントでは、ドメインは、アドレス管理またはパス計算の責任の共通の領域を持つ、エリアまたはAS内のネットワーク要素の集合と見なされます。完全にまたは部分的に重複しているドメインは、このドキュメントの範囲外です。
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, computation of an end-to-end path requires the selection of nodes and links within a parent domain where some nodes may, in fact, be subnetworks. Furthermore, a domain might be an ASON routing area [G-7715]. A PCE may perform the path computation function of an ASON Routing Controller as described in [G-7715-2].
GMPLSのコンテキストでは、ドメインの特に重要な例は、自動切り替え光ネットワーク（ASON）サブネットワーク[G-8080]です。この場合、エンドツーエンドパスの計算には、一部のノードが実際にはサブネットワークである可能性がある親ドメイン内のノードとリンクを選択する必要があります。さらに、ドメインはASONルーティングエリアである可能性があります[G-7715]。 PCEは、[G-7715-2]で説明されているように、ASONルーティングコントローラーのパス計算機能を実行できます。
It is assumed that the PCE architecture is not applied to a large group of domains, such as the Internet.
PCEアーキテクチャは、インターネットなどの大規模なドメイングループには適用されないと想定されています。
For the purpose of this document, it is assumed that path computation is the sole responsibility of the PCE as per the architecture defined in [RFC4655]. When a path is required, the Path Computation Client (PCC) will send a request to the PCE. The PCE will apply the required constraints, compute a path, and return a response to the PCC. In the context of this document, it may be necessary for the PCE to cooperate with other PCEs in adjacent domains (as per BRPC [RFC5441]) or with a parent PCE (as per [RFC6805]).
このドキュメントでは、[RFC4655]で定義されているアーキテクチャに従って、パス計算がPCEの唯一の責任であると想定しています。パスが必要な場合、パス計算クライアント（PCC）はPCEに要求を送信します。 PCEは必要な制約を適用し、パスを計算して、PCCに応答を返します。このドキュメントのコンテキストでは、PCEが隣接ドメイン内の他のPCE（BRPC [RFC5441]による）または親PCE（[RFC6805]による）と連携する必要がある場合があります。
It is entirely feasible that an operator could compute a path across multiple domains without the use of a PCE if the relevant domain information is available to the network planner or network management platform. The definition of what relevant information is required to perform this network planning operation and how that information is discovered and applied is outside the scope of this document.
関連するドメイン情報がネットワークプランナーまたはネットワーク管理プラットフォームで利用できる場合、オペレーターがPCEを使用せずに複数のドメインにまたがるパスを計算できることは完全に実現可能です。このネットワーク計画操作を実行するために必要な関連情報の定義と、その情報がどのように検出および適用されるかは、このドキュメントの範囲外です。
As highlighted, the PCE is an entity capable of computing an inter-domain TE path upon receiving a request from a PCC. There could be a single PCE per domain or a single PCE responsible for all domains. A PCE may or may not reside on the same node as the requesting PCC. A path may be computed by either a single PCE node or a set of distributed PCE nodes that collaborate during path computation.
強調表示されているように、PCEは、PCCから要求を受信するとドメイン間TEパスを計算できるエンティティです。ドメインごとに1つのPCEが存在することも、すべてのドメインを担当する1つのPCEが存在することもあります。 PCEは、要求元のPCCと同じノードに存在する場合と存在しない場合があります。パスは、単一のPCEノード、またはパスの計算中に連携する一連の分散PCEノードのいずれかによって計算できます。
According to [RFC4655], a PCC should send a path computation request to a particular PCE using [RFC5440] (PCC-to-PCE communication). This negates the need to broadcast a request to all the PCEs. Each PCC can maintain information about the computation capabilities of the PCEs it is aware of. The PCC-PCE capability awareness can be configured using static configurations or by automatic and dynamic PCE discovery procedures.
[RFC4655]によると、PCCは[RFC5440]（PCC-to-PCE通信）を使用してパス計算要求を特定のPCEに送信する必要があります。これにより、すべてのPCEに要求をブロードキャストする必要がなくなります。各PCCは、認識しているPCEの計算機能に関する情報を維持できます。 PCC-PCE機能認識は、静的構成を使用して、または自動および動的PCE検出手順によって構成できます。
If a network path is required, the PCC will send a path computation request to the PCE. A PCE may then compute the end-to-end path if it is aware of the topology and TE information required to compute the entire path. If the PCE is unable to compute the entire path, the PCE architecture provides cooperative PCE mechanisms for the resolution of path computation requests when an individual PCE does not have sufficient TE visibility.
ネットワークパスが必要な場合、PCCはパス計算要求をPCEに送信します。 PCEは、パス全体の計算に必要なトポロジーとTE情報を認識している場合、エンドツーエンドパスを計算します。 PCEがパス全体を計算できない場合、PCEアーキテクチャは、個々のPCEが十分なTE可視性を持たない場合に、パス計算要求を解決するための協調的PCEメカニズムを提供します。
End-to-end path segments may be kept confidential through the application of Path-Keys to protect partial or full path information. A Path-Key is a token that replaces a path segment in an explicit route. The Path-Key mechanism is described in [RFC5520].
エンドツーエンドのパスセグメントは、パスキーを適用することにより、部分的または完全なパス情報を保護することにより、機密情報を保持できます。パスキーは、明示的なルートのパスセグメントを置き換えるトークンです。パスキーのメカニズムは[RFC5520]で説明されています。
Networks are often constructed from multiple areas or ASes that are interconnected via multiple interconnect points. To maintain network confidentiality and scalability, the TE properties of each area and AS are not generally advertised outside each specific area or AS.
ネットワークは多くの場合、複数の相互接続ポイントを介して相互接続された複数のエリアまたはASから構築されます。ネットワークの機密性とスケーラビリティを維持するために、通常、各エリアとASのTEプロパティは、各特定のエリアまたはASの外部には通知されません。
TE aggregation or abstraction provide a mechanism to hide information but may cause failed path setups 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.
TEの集約または抽象化は、情報を隠すメカニズムを提供しますが、パスのセットアップに失敗したり、最適ではないエンドツーエンドのパスを選択したりする可能性があります[RFC4726]。集約プロセスには、多くの可能なルートと複数のTEメトリックがあるネットワークの場合、重大なスケーリングの問題がある場合もあります。 TE情報のフラッディングは機密性を破壊し、ルーティングプロトコルで拡張されません。
The PCE architecture and associated mechanisms provide a solution to avoid the use of TE aggregation and abstraction.
PCEアーキテクチャと関連するメカニズムは、TEの集約と抽象化の使用を回避するソリューションを提供します。
This document highlights the PCE techniques and mechanisms that exist for establishing TE packet and optical Label Switched Paths (LSPs) across multiple areas (inter-area TE LSP) and ASes (inter-AS TE LSP). In this context and within the remainder of this document, we consider all LSPs to be constraint based and traffic engineered.
このドキュメントでは、複数のエリア（エリア間TE LSP）とAS（インターAS TE LSP）にわたってTEパケットと光ラベルスイッチドパス（LSP）を確立するために存在するPCEテクニックとメカニズムについて説明します。このコンテキストおよびこのドキュメントの残りの部分では、すべてのLSPが制約ベースであり、トラフィックエンジニアリングされていると見なします。
Three signaling options are defined for setting up an inter-area or inter-AS LSP [RFC4726]:
エリア間またはAS間LSP [RFC4726]を設定するために、3つのシグナリングオプションが定義されています。
* Contiguous LSP
* 隣接LSP
* Stitched LSP
* ステッチLSP
* Nested LSP
* ネストされたLSP
All three signaling methods are applicable to the architectures and procedures discussed in this document.
3つのシグナリング方法はすべて、このドキュメントで説明されているアーキテクチャと手順に適用できます。
When using a PCE-based approach for inter-area and inter-AS path computation, a PCE in one area or AS may need to learn information related to inter-AS-capable PCEs located in other ASes. The PCE discovery mechanism defined in [RFC5088] and [RFC5089] facilitates the discovery of PCEs and disclosure of information related to inter-area and inter-AS-capable PCEs.
エリア間およびAS間パス計算にPCEベースのアプローチを使用する場合、1つのエリアまたはASのPCEは、他のASにあるAS間対応PCEに関連する情報を学習する必要がある場合があります。 [RFC5088]と[RFC5089]で定義されているPCE検出メカニズムは、PCEの検出と、エリア間およびAS間対応のPCEに関連する情報の開示を容易にします。
An Objective Function (OF) [RFC5541] or a set of OFs specifies the intentions of the path computation and so defines the "optimality" in the context of the computation request.
目的関数（OF）[RFC5541]またはOFのセットは、パス計算の意図を指定し、計算要求のコンテキストで「最適性」を定義します。
An OF specifies the desired outcome of a computation. It does not describe or specify the algorithm to use. Also, an implementation may apply any algorithm or set of algorithms to achieve the result indicated by the OF. A number of general OFs are specified in [RFC5541].
OFは、計算の望ましい結果を指定します。使用するアルゴリズムは記述または指定されていません。また、実装は、任意のアルゴリズムまたはアルゴリズムのセットを適用して、OFによって示される結果を達成できます。 [RFC5541]には、いくつかの一般的なOFが指定されています。
Various OFs may be included in the PCE computation request 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 whether it applies its own OFs.
PCEでエンコードまたは構成されたポリシーを満たすために、PCE計算要求にさまざまなOFを含めることができます。PCEは、計算要求に含まれるOFを満たすか、または独自のOFを適用するかを決定する際にポリシーの対象となる場合があります。
During 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 policies.
ドメイン間パスの計算中、ドメインシーケンスの選択、各（ドメインごとの）パスフラグメントの計算、およびエンドツーエンドパスの決定は、それぞれ異なるOFおよびポリシーの影響を受ける可能性があります。
This document also uses the terminology defined in [RFC4655] and [RFC5440]. Additional terminology is defined below:
このドキュメントでは、[RFC4655]と[RFC5440]で定義されている用語も使用しています。追加の用語を以下に定義します。
ABR: IGP Area Border Router -- a router that is attached to more than one IGP area.
ABR：IGPエリア境界ルーター-複数のIGPエリアに接続されているルーター。
ASBR: Autonomous System Border Router -- a router used to connect together ASes of a different or the same Service Provider via one or more inter-AS links.
ASBR：Autonomous System Border Router-1つまたは複数のAS間リンクを介して、異なるまたは同じサービスプロバイダーのASを接続するために使用されるルーター。
Inter-area TE LSP: A TE LSP whose path transits through two or more IGP areas.
エリア間TE LSP：パスが2つ以上のIGPエリアを通過するTE LSP。
Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or more ASes or sub-ASes (BGP confederations)
Inter-AS MPLS TE LSP：パスが2つ以上のASまたはサブAS（BGP連合）を通過するTE LSP
SRLG: Shared Risk Link Group.
SRLG：共有リスクリンクグループ。
TED: Traffic Engineering Database, which contains the topology and resource information of the domain. The TED may be fed by Interior Gateway Protocol (IGP) extensions or potentially by other means.
TED：ドメインのトポロジーとリソース情報を含むトラフィックエンジニアリングデータベース。 TEDは、Interior Gateway Protocol（IGP）拡張によって、または他の手段によって供給される可能性があります。
Networks constructed from multi-areas or multi-AS environments may have multiple interconnect points (multihoming). End-to-end path computations may need to use different interconnect points to avoid a single-point failure disrupting both the primary and backup services.
マルチエリアまたはマルチAS環境から構築されたネットワークには、複数の相互接続ポイント（マルチホーミング）がある場合があります。エンドツーエンドパスの計算では、プライマリサービスとバックアップサービスの両方を中断するシングルポイント障害を回避するために、異なる相互接続ポイントを使用する必要がある場合があります。
A PCC asking for an inter-domain path computation is typically aware of the identity of the destination node. If the PCC is aware of the destination domain, it may supply the destination domain information as part of the path computation request. However, if the PCC does not know the destination domain, this information must be determined by another method.
ドメイン間パスの計算を要求するPCCは、通常、宛先ノードのIDを認識しています。 PCCが宛先ドメインを認識している場合、PCCはパス計算要求の一部として宛先ドメイン情報を提供できます。ただし、PCCが宛先ドメインを認識していない場合、この情報は別の方法で決定する必要があります。
When the end-to-end path crosses multiple domains, it may be possible that each domain (AS or area) is administered by separate Service Providers. Thus, if a PCE supplies a path segment to a PCE in another domain, it may break confidentiality rules and could disclose AS-internal topology information.
エンドツーエンドパスが複数のドメインをまたぐ場合、各ドメイン（ASまたはエリア）が別々のサービスプロバイダーによって管理される可能性があります。したがって、PCEが別のドメインのPCEにパスセグメントを提供すると、機密性ルールに違反し、AS内部トポロジー情報を開示する可能性があります。
If confidentiality is required between domains (ASes and areas) belonging to different Service Providers, then cooperating PCEs cannot exchange path segments; otherwise, the receiving PCE or PCC will be able to see the individual hops through another domain.
異なるサービスプロバイダーに属するドメイン（ASおよびエリア）間で機密性が必要な場合、協力するPCEはパスセグメントを交換できません。そうでない場合、受信側のPCEまたはPCCは、別のドメインを経由する個々のホップを見ることができます。
This topic is discussed further in Section 8 of this document.
このトピックについては、このドキュメントのセクション8で詳しく説明します。
Constraint-based inter-domain path computation is a fundamental requirement for operating traffic-engineered MPLS [RFC3209] and GMPLS [RFC3473] networks in inter-area and inter-AS (multi-domain) environments. Path computation across multi-domain networks is complex and requires computational cooperational entities like the PCE.
制約ベースのドメイン間パス計算は、エリア間およびAS間（マルチドメイン）環境でトラフィックエンジニアリングMPLS [RFC3209]およびGMPLS [RFC3473]ネットワークを運用するための基本的な要件です。マルチドメインネットワーク全体のパス計算は複雑で、PCEなどの計算協力エンティティが必要です。
Where the sequence of domains is known a priori, various techniques can be employed to derive an optimal multi-domain path. If the domains are connected to a simple path with no branches and single links between all domains or if the preferred points of interconnection are also known, the per-domain path computation [RFC5152] technique may be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, BRPC [RFC5441] can be used to derive an optimal path.
ドメインのシーケンスが事前にわかっている場合、さまざまな手法を使用して、最適なマルチドメインパスを導出できます。ドメインがブランチのない単純なパスに接続され、すべてのドメイン間に単一のリンクがある場合、または相互接続の優先ポイントもわかっている場合は、ドメインごとのパス計算[RFC5152]手法を使用できます。ドメイン間に複数の接続があり、相互接続のポイントの選択に優先順位がない場合、BRPC [RFC5441]を使用して最適なパスを導出できます。
When the sequence of domains is not known in advance or the end-to-end path will have to navigate a mesh of small domains (especially typical in optical networks), the optimum path may be derived through the application of a hierarchical PCE [RFC6805].
ドメインのシーケンスが事前にわからない場合、またはエンドツーエンドのパスが小さなドメインのメッシュをナビゲートする必要がある場合（特に光ネットワークでは一般的）、階層型PCE [RFC6805 ]。
Very frequently, network domains are composed of dozens or hundreds of network elements. These network elements are usually interconnected in a partial-mesh fashion to provide survivability against dual failures and to benefit from the traffic-engineering capabilities of MPLS and GMPLS protocols. Network operator feedback in the development of the document highlighted that the node degree (the number of neighbors per node) typically ranges from 3 to 10 (4-5 is quite common).
非常に頻繁に、ネットワークドメインは数十または数百のネットワーク要素で構成されます。これらのネットワーク要素は、通常、部分メッシュ方式で相互接続され、二重障害に対する耐久性を提供し、MPLSおよびGMPLSプロトコルのトラフィックエンジニアリング機能の恩恵を受けます。ドキュメントの開発におけるネットワークオペレーターのフィードバックにより、ノードの次数（ノードあたりの隣接ノードの数）の範囲は通常3〜10であることが強調されました（4〜5は非常に一般的です）。
Domain and path diversity may also be required when computing end-to-end paths. Domain diversity should facilitate the selection of paths that share ingress and egress domains but do not share transit domains. Therefore, there must be a method allowing the inclusion or exclusion of specific domains when computing end-to-end paths.
エンドツーエンドパスを計算するときに、ドメインとパスの多様性も必要になる場合があります。ドメインの多様性により、入力ドメインと出力ドメインを共有するが、通過ドメインを共有しないパスの選択が容易になります。したがって、エンドツーエンドのパスを計算するときに、特定のドメインの包含または除外を許可する方法が必要です。
In some scenarios, it would be beneficial for the operator to rely on the capability of the PCE to perform synchronized path computation.
一部のシナリオでは、オペレーターがPCEの機能に依存して同期パス計算を実行することが有益です。
Synchronized path computations, known as Synchronization VECtors (SVECs), are used for dependent path computations. SVECs are defined in [RFC5440], and [RFC6007] provides an overview of the use of the PCE SVEC list for synchronized path computations when computing dependent requests.
依存パスの計算には、同期VECtor（SVEC）と呼ばれる同期パスの計算が使用されます。 SVECは[RFC5440]で定義されており、[RFC6007]は、依存する要求を計算するときの同期パス計算のためのPCE SVECリストの使用の概要を提供します。
In hierarchical PCE (H-PCE) deployments, a child PCE will be able to request both dependent and synchronized domain-diverse end-to-end paths from its parent PCE.
階層型PCE（H-PCE）の展開では、子PCEは、親PCEからの従属および同期ドメイン多様なエンドツーエンドパスの両方を要求できます。
A domain sequence is an ordered sequence of domains traversed to reach the destination domain. A domain sequence may be supplied during path computation to guide the PCEs or are derived via the use of hierarchical PCE (H-PCE).
ドメインシーケンスは、宛先ドメインに到達するために通過するドメインの順序付けられたシーケンスです。ドメインシーケンスは、パス計算中にPCEを導くために提供されるか、階層PCE（H-PCE）を使用して導出されます。
During multi-domain path computation, a PCC may request specific domains to be included or excluded in the domain sequence using the Include Route Object (IRO) [RFC5440] and Exclude Route Object (XRO) [RFC5521]. The use of Autonomous Number (AS) as an abstract node representing a domain is defined in [RFC3209]. [RFC7897] specifies new subobjects to include or exclude domains such as an IGP area or a 4-byte AS number.
マルチドメインパスの計算中、PCCは、Include Route Object（IRO）[RFC5440]およびExclude Route Object（XRO）[RFC5521]を使用して、特定のドメインをドメインシーケンスに含めるまたは除外するように要求できます。ドメインを表す抽象ノードとしての自律番号（AS）の使用は、[RFC3209]で定義されています。 [RFC7897]は、IGPエリアや4バイトのAS番号などのドメインを含めるか除外する新しいサブオブジェクトを指定します。
An operator may also need to avoid a path that uses specified nodes for administrative reasons. If a specific connectivity service is required to have a 1+1 protection capability, two separate disjoint paths must be established. A mechanism known as Shared Risk Link Group (SRLG) information may be used to ensure path diversity.
オペレーターは、管理上の理由から、指定されたノードを使用するパスを回避する必要がある場合もあります。 1 + 1保護機能を備えた特定の接続サービスが必要な場合は、2つの個別の分離パスを確立する必要があります。共有リスクリンクグループ（SRLG）情報と呼ばれるメカニズムを使用して、パスの多様性を確保できます。
As networks increase in size and complexity, it may be required to introduce scaling methods to reduce the amount of 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 visibility of the area to routers in a single area. If a router needs to compute the route to a destination located in another area, a method would be required to compute a path across area boundaries.
ネットワークのサイズと複雑さが増すにつれ、ネットワーク内に氾濫する情報の量を減らし、ネットワークをより管理しやすくするためのスケーリング方法の導入が必要になる場合があります。 IGP階層は、IGPドメインをエリアに分割し、トポロジー情報のフラッディングスコープをエリア境界内に制限することにより、IGPのスケーラビリティを向上させるように設計されています。これにより、エリアの可視性が単一エリア内のルーターに制限されます。ルーターが別のエリアにある宛先へのルートを計算する必要がある場合、エリア境界を越えるパスを計算する方法が必要になります。
In order to support multiple vendors in a network in cases where data or control-plane technologies cannot interoperate, it is useful to divide the network into vendor domains. Each vendor domain is an IGP area, and the flooding scope of the topology (as well as any other relevant information) is limited to the area boundaries.
データまたはコントロールプレーンテクノロジーが相互運用できない場合にネットワークで複数のベンダーをサポートするには、ネットワークをベンダードメインに分割すると便利です。各ベンダードメインはIGPエリアであり、トポロジのフラッディングスコープ（およびその他の関連情報）はエリア境界に制限されています。
Per-domain path computation [RFC5152] exists to provide a method of inter-area path computation. The per-domain solution is based on loose hop routing with an Explicit Route Object (ERO) expansion on each Area Border Router (ABR). This allows an LSP to be established using a constrained path. However, at least two issues exist:
ドメインごとのパス計算[RFC5152]は、エリア間パス計算の方法を提供するために存在します。ドメインごとのソリューションは、各エリアボーダールーター（ABR）での明示的なルートオブジェクト（ERO）の拡張によるルーズホップルーティングに基づいています。これにより、制約されたパスを使用してLSPを確立できます。ただし、少なくとも2つの問題が存在します。
* This method does not guarantee an optimal constrained path.
* この方法は、最適な制約パスを保証するものではありません。
* The method may require several crankback signaling messages, as per [RFC4920], increasing signaling traffic and delaying the LSP setup.
* この方法では、[RFC4920]のように、いくつかのクランクバックシグナリングメッセージが必要になる場合があり、シグナリングトラフィックが増加し、LSPセットアップが遅延します。
PCE-based architecture [RFC4655] is designed to solve inter-area path computation problems. The issue of limited topology visibility is resolved by introducing path computation entities that are able to cooperate in order to establish LSPs with the source and destinations located in different areas.
PCEベースのアーキテクチャ[RFC4655]は、エリア間パス計算の問題を解決するように設計されています。トポロジの可視性の制限の問題は、異なる領域にある送信元と宛先でLSPを確立するために連携できるパス計算エンティティを導入することで解決されます。
An inter-area TE-LSP is an LSP that transits through at least two IGP areas. In a multi-area network, topology visibility remains local to a given area for scaling and privacy purposes. A node in one area will not be able to compute an end-to-end path across multiple areas without the use of a PCE.
エリア間TE-LSPは、少なくとも2つのIGPエリアを通過するLSPです。マルチエリアネットワークでは、トポロジの可視性は、スケーリングとプライバシーの目的で、特定のエリアに対してローカルのままです。 1つのエリアのノードは、PCEを使用しないと、複数のエリアにまたがるエンドツーエンドパスを計算できません。
The BRPC method [RFC5441] of path computation provides a more optimal method to specify inclusion or exclusion of an ABR. Using the BRPC procedure, an end-to-end path is recursively computed in reverse from the destination domain towards the source domain. Using this method, an operator might decide if an area must be included or excluded from the inter-area path computation.
パス計算のBRPCメソッド[RFC5441]は、ABRの包含または除外を指定するためのより最適な方法を提供します。 BRPC手順を使用して、エンドツーエンドパスが宛先ドメインからソースドメインに向かって逆に再帰的に計算されます。この方法を使用すると、オペレーターは、エリアをエリア間パスの計算に含めるか除外するかを決定できます。
A strict explicit path is defined as a set of strict hops, while a loose path is defined as a set of at least one loose hop and zero or more strict hops. It may be useful to indicate whether a strict explicit path is required during the path computation request. An inter-area path may be strictly explicit or loose (e.g., a list of ABRs as loose hops).
厳密な明示パスは、厳密なホップのセットとして定義されますが、ルーズパスは、少なくとも1つのルーズホップと0個以上の厳密なホップのセットとして定義されます。パス計算要求中に厳密な明示パスが必要かどうかを示すと役立つ場合があります。エリア間パスは、厳密に明示的である場合とルーズである場合があります（ルーズホップとしてのABRのリストなど）。
A PCC request to a PCE does allow indication of whether a strict explicit path across specific areas ([RFC7897]) is required or desired or whether the path request is loose.
PCEへのPCC要求は、特定の領域（[RFC7897]）にまたがる厳密な明示的パスが必要であるか望ましいか、またはパス要求が緩んでいるかどうかを示します。
It may be necessary to compute a path that is partially or entirely diverse from a previously computed path to avoid fate sharing of a primary service with a corresponding backup service. There are various levels of diversity in the context of an inter-area network:
プライマリサービスと対応するバックアップサービスの運命的な共有を回避するために、以前に計算されたパスとは部分的または全体的に異なるパスを計算する必要がある場合があります。エリア間ネットワークのコンテキストには、さまざまなレベルの多様性があります。
* Per-area diversity (the intra-area path segments are a link, node, or SRLG disjoint).
* エリアごとのダイバーシティ（エリア内パスセグメントは、リンク、ノード、またはSRLGの素です）。
* Inter-area diversity (the end-to-end inter-area paths are a link, node, or SRLG disjoint).
* エリア間ダイバーシティ（エンドツーエンドのエリア間パスは、リンク、ノード、またはSRLGディスジョイントです）。
Note that two paths may be disjointed in the backbone area but non-disjointed in peripheral areas. Also, two paths may be node disjointed within areas but may share ABRs, in which case path segments within an area are node disjointed but end-to-end paths are not node disjointed. Per-domain [RFC5152], BRPC [RFC5441], and H-PCE [RFC6805] mechanisms all support the capability to compute diverse paths across multi-area topologies.
2つのパスは、バックボーンエリアでは分離されているが、周辺エリアでは分離されていない場合があることに注意してください。また、2つのパスは、エリア内でノードのまとまりがない場合がありますが、ABRを共有できます。この場合、エリア内のパスセグメントはノードのまとまりですが、エンドツーエンドパスはノードのまとまりではありません。ドメイン単位[RFC5152]、BRPC [RFC5441]、およびH-PCE [RFC6805]メカニズムはすべて、マルチエリアトポロジ全体の多様なパスを計算する機能をサポートしています。
As discussed in Section 5 (Applicability of the PCE to Inter-area Traffic Engineering), it is necessary to divide the network into smaller administrative domains, or ASes. If an LSR within an AS needs to compute a path across an AS boundary, it must also use an inter-AS computation technique. [RFC5152] defines mechanisms for the computation of inter-domain TE LSPs using network elements along the signaling paths to compute per-domain constrained path segments.
セクション5（エリア間トラフィックエンジニアリングへのPCEの適用性）で説明したように、ネットワークを小さな管理ドメイン（AS）に分割する必要があります。 AS内のLSRがAS境界を越えてパスを計算する必要がある場合は、AS間計算手法も使用する必要があります。 [RFC5152]は、ドメインごとの制約されたパスセグメントを計算するために、シグナリングパスに沿ったネットワーク要素を使用してドメイン間TE LSPを計算するためのメカニズムを定義します。
The PCE was designed to be capable of computing MPLS and GMPLS paths across AS boundaries. This section outlines the features of a PCE-enabled solution for computing inter-AS paths.
PCEは、AS境界を越えてMPLSおよびGMPLSパスを計算できるように設計されています。このセクションでは、AS間パスを計算するためのPCE対応ソリューションの機能について概説します。
[RFC5441] allows the specification of AS or ASBR inclusion or exclusion. Using this method, an operator might decide whether an AS must be included or excluded from the inter-AS path computation. Exclusion and/or inclusion could also be specified at any step in the LSP path computation process by a PCE (within the BRPC algorithm), but the best practice would be to specify them at the edge. In opposition to the strict and loose path, AS inclusion or exclusion doesn't impose topology disclosure as ASes and their interconnection are public entities.
[RFC5441]では、ASまたはASBRの包含または除外を指定できます。この方法を使用すると、オペレーターはASをAS間パスの計算に含めるか除外するかを決定できます。除外と包含は、PCEによって（BRPCアルゴリズム内で）LSPパス計算プロセスの任意のステップで指定することもできますが、エッジで指定することをお勧めします。 ASとその相互接続はパブリックエンティティであるため、厳密でルーズなパスとは反対に、ASの包含または除外はトポロジの開示を強制しません。
Many operators with multi-AS domains will have deployed the MPLS-TE Diffserv either across their entire network or at the domain edges on CE-PE links. In situations where strict QoS bounds are required, admission control inside the network may also be required.
マルチASドメインを持つ多くのオペレーターは、ネットワーク全体またはCE-PEリンクのドメインエッジにMPLS-TE Diffservを展開しています。厳密なQoS境界が必要な状況では、ネットワーク内部のアドミッションコントロールも必要になる場合があります。
When the propagation delay can be bounded, the performance targets, such as maximum one-way transit delay, may be guaranteed by providing bandwidth guarantees along the Diffserv-enabled path. These requirements are described in [RFC4216].
伝播遅延を制限できる場合、Diffserv対応パスに沿って帯域幅保証を提供することにより、最大一方向通過遅延などのパフォーマンス目標を保証できます。これらの要件は[RFC4216]で説明されています。
One typical example of the requirements in [RFC4216] is to provide bandwidth guarantees over an end-to-end path for VoIP traffic classified as an EF (Expedited Forwarding) class in a Diffserv-enabled network. In cases where the EF path is extended across multiple ASes, an inter-AS bandwidth guarantee would be required.
[RFC4216]の要件の1つの典型的な例は、Diffserv対応ネットワークでEF（Expedited Forwarding）クラスとして分類されたVoIPトラフィックのエンドツーエンドパスで帯域幅保証を提供することです。 EFパスが複数のASにまたがっている場合、AS間帯域幅の保証が必要になります。
Another case for an inter-AS bandwidth guarantee is the requirement to guarantee a certain amount of transit bandwidth across one or multiple ASes.
AS間帯域幅保証のもう1つのケースは、1つまたは複数のASにわたって一定量の伝送帯域幅を保証する要件です。
During a path computation process, a PCC request may contain the requirement to compute a backup LSP for protecting the primary LSP, such as 1+1 protection. A single LSP or multiple backup LSPs may also be used for a group of primary LSPs; this is typically known as m:n protection.
パス計算プロセス中、PCC要求には、1 + 1保護などのプライマリLSPを保護するためのバックアップLSPを計算する要件が含まれる場合があります。単一のLSPまたは複数のバックアップLSPをプライマリLSPのグループに使用することもできます。これは通常、m：n保護と呼ばれます。
Other inter-AS recovery mechanisms include [RFC4090], which adds Fast Reroute (FRR) protection to an LSP. So, the PCE could be used to trigger computation of backup tunnels in order to protect inter-AS connectivity.
他のAS間回復メカニズムには、[RFC4090]が含まれます。これは、LSPに高速リルート（FRR）保護を追加します。したがって、PCEを使用して、AS間接続を保護するためにバックアップトンネルの計算をトリガーできます。
Inter-AS recovery clearly requires backup LSPs for service protection, but it would also be advisable to have multiple PCEs deployed for path computation redundancy, especially for service restoration in the event of catastrophic network failure.
AS間リカバリでは、サービス保護のためにバックアップLSPが明らかに必要ですが、特に壊滅的なネットワーク障害が発生した場合のサービス復元のために、パス計算の冗長性のために複数のPCEを展開することもお勧めします。
Like BGP peering policies, inter-AS PCE peering policies are required for an operator. In an inter-AS BRPC process, the PCE must cooperate in order to compute the end-to-end LSP. Therefore, the AS path must not only follow technical constraints, e.g., bandwidth availability, but also the policies defined by the operator.
BGPピアリングポリシーと同様に、オペレーターにはAS-AS PCEピアリングポリシーが必要です。 AS間のBRPCプロセスでは、PCEはエンドツーエンドのLSPを計算するために協力する必要があります。したがって、ASパスは、帯域幅の可用性などの技術的な制約だけでなく、オペレーターが定義したポリシーにも従う必要があります。
Typically, PCE interconnections at an AS level must follow the agreed contract obligations, also known as peering agreements. The PCE peering policies are the result of the contract negotiation and govern the relation between the different PCEs.
通常、ASレベルでのPCE相互接続は、ピアリング契約とも呼ばれる、合意された契約義務に従う必要があります。 PCEピアリングポリシーは、契約交渉の結果であり、異なるPCE間の関係を管理します。
An optimal path computation requires knowledge of the available network resources, including nodes and links, constraints, link connectivity, available bandwidth, and link costs. The PCE operates on a view of the network topology as presented by a TED. As discussed in [RFC4655], the TED used by a PCE may be learned by the relevant IGP extensions.
最適パスの計算には、ノードとリンク、制約、リンク接続、利用可能な帯域幅、リンクコストなど、利用可能なネットワークリソースの知識が必要です。 PCEは、TEDによって提示されるネットワークトポロジのビューで動作します。 [RFC4655]で説明されているように、PCEによって使用されるTEDは、関連するIGP拡張機能によって学習される場合があります。
Thus, the PCE may operate its TED by participating in the IGP running
in the network. In an MPLS-TE network, this would require OSPF-TE
[RFC3630] or ISIS-TE [RFC5305]. In a GMPLS network, it would utilize
the GMPLS extensions to OSPF and IS-IS defined in [RFC4203] and
[RFC5307]. Inter-AS connectivity information may be populated via
[RFC5316] and [RFC5392].
An alternative method to providing network topology and resource information is offered by [RFC7752], which is described in the following section.
ネットワークトポロジとリソース情報を提供する別の方法は、[RFC7752]によって提供されます。これについては、次のセクションで説明します。
The concept of the exchange of TE information between Autonomous Systems (ASes) is discussed in [RFC7752]. 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情報の交換の概念は、[RFC7752]で説明されています。この方法で交換される情報は、ASからの完全なTE情報、その情報の集約、またはAS全体の潜在的な接続の表現です。さらに、その情報は頻繁に更新されるか（たとえば、AS全体でセットアップされるすべての新しいLSPに対して）、またはしきい値超過イベントでのみ更新されます。
In an H-PCE deployment, the parent PCE will require the inter-domain topology and link status between child domains. This information may be learned by a BGP-LS speaker and provided to the parent PCE. Furthermore, link-state performance, including delay, available bandwidth, and utilized bandwidth, may also be provided to the parent PCE for optimal path link selection.
H-PCE展開では、親PCEはドメイン間トポロジと子ドメイン間のリンクステータスを必要とします。この情報は、BGP-LSスピーカーによって学習され、親PCEに提供されます。さらに、最適なパスリンクを選択するために、遅延、使用可能な帯域幅、および利用された帯域幅を含むリンクステートパフォーマンスも親PCEに提供されます。
Offline path computation is performed ahead of time before the LSP setup is requested. That means that it is requested by or performed as part of an Operation Support System (OSS) management application. This model can be seen in Section 5.5 of [RFC4655].
オフラインパス計算は、LSPセットアップが要求される前に事前に実行されます。つまり、操作サポートシステム（OSS）管理アプリケーションによって要求されるか、その一部として実行されます。このモデルは、[RFC4655]のセクション5.5で確認できます。
The offline model is particularly appropriate for long-lived LSPs (such as those present in a transport network) or for planned responses to network failures. In these scenarios, more planning is normally a feature of LSP provisioning.
オフラインモデルは、長寿命のLSP（トランスポートネットワークに存在するものなど）またはネットワーク障害への計画的な応答に特に適しています。これらのシナリオでは、通常、より多くの計画がLSPプロビジョニングの機能です。
The management system may also use a PCE and BRPC to pre-plan an AS sequence, and the source domain PCE and per-domain path computation to be used when the actual end-to-end path is required. This model may also be used where the operator wishes to retain full manual control of the placement of LSPs, using the PCE only as a computation tool to assist the operator and not as part of an automated network.
管理システムは、PCEとBRPCを使用してASシーケンスを事前に計画することもできます。ソースドメインのPCEとドメインごとのパス計算は、実際のエンドツーエンドパスが必要な場合に使用されます。このモデルは、オペレーターがLSPの配置を完全に手動で制御し、PCEをオペレーターを支援する計算ツールとしてのみ使用し、自動ネットワークの一部として使用しない場合にも使用できます。
In environments where operators peer with each other to provide end-to-end paths, the operator responsible for each domain must agree on the extent to which paths must be pre-planned or manually controlled.
オペレーターが相互にピアツーエンドのパスを提供する環境では、各ドメインを担当するオペレーターは、パスを事前に計画するか手動で制御する必要がある範囲について合意する必要があります。
This section discusses the techniques that cooperating PCEs can use to compute inter-domain paths without each domain disclosing sensitive internal topology information (such as explicit nodes or links within the domain) to the other domains.
このセクションでは、協調するPCEがドメイン間パスを計算するために使用できる手法について説明します。各ドメインが他のドメインに機密の内部トポロジ情報（明示的なノードやドメイン内のリンクなど）を開示することはありません。
Confidentiality typically applies to inter-provider (inter-AS) PCE communication. Where the TE LSP crosses multiple domains (ASes or areas), the path may be computed by multiple PCEs that cooperate together, with each local PCE responsible for computing a segment of the path. With each local PCE responsible for computing a segment of the path.
機密性は通常、プロバイダー間（AS間）PCE通信に適用されます。 TE LSPが複数のドメイン（ASまたはエリア）を横断する場合、パスは、協調する複数のPCEによって計算され、各ローカルPCEがパスのセグメントの計算を担当します。パスのセグメントの計算を担当する各ローカルPCE。
In situations where ASes are administered by separate Service Providers, it would break confidentiality rules for a PCE to supply path segment details to a PCE responsible for another domain, thus disclosing AS-internal or area topology information.
ASが個別のサービスプロバイダーによって管理されている状況では、PCEが別のドメインを担当するPCEにパスセグメントの詳細を提供するための機密性ルールに違反し、AS内部またはエリアトポロジ情報が開示されます。
A method for preserving the confidentiality of the path segment is for the PCE to return a path containing a loose hop in place of the segment that must be kept confidential. The concept of loose and strict hops for the route of a TE LSP is described in [RFC3209].
パスセグメントの機密性を保持する方法は、PCEが機密性を保持する必要があるセグメントの代わりにルーズホップを含むパスを返すことです。 TE LSPのルートのルーズホップとストリクトホップの概念は、[RFC3209]で説明されています。
[RFC5440] supports the use of paths with loose hops; whether it returns a full explicit path with strict hops or uses loose hops is a local policy decision at a PCE. A path computation request may require an explicit path with strict hops or may allow loose hops, as detailed in [RFC5440].
[RFC5440]は、ルーズホップのあるパスの使用をサポートしています。厳密なホップを含む完全な明示パスを返すか、ルーズホップを使用するかは、PCEでのローカルポリシーの決定です。 [RFC5440]で詳述されているように、パス計算リクエストは、厳密なホップを含む明示的なパスを必要とする場合や、ルーズホップを許可する場合があります。
[RFC5520] defines the concept and mechanism of a Path-Key. A Path-Key is a token that replaces the path segment information in an explicit route. The Path-Key allows the explicit route information to be encoded and is contained in the Path Computation Element Communication Protocol (PCEP) ([RFC5440]) messages exchanged between the PCE and PCC.
[RFC5520]は、パスキーの概念とメカニズムを定義しています。パスキーは、明示的なルートのパスセグメント情報を置き換えるトークンです。パスキーを使用すると、明示的なルート情報をエンコードでき、PCEとPCCの間で交換されるパス計算要素通信プロトコル（PCEP）（[RFC5440]）メッセージに含まれます。
This Path-Key technique allows explicit route information to be used for end-to-end path computation without disclosing internal topology information between domains.
このパスキー技術により、ドメイン間の内部トポロジ情報を開示することなく、明示的なルート情報をエンドツーエンドのパス計算に使用できます。
For inter-domain point-to-multipoint application scenarios using MPLS-TE LSPs, the complexity of domain sequences, domain policies, and the choice and number of domain interconnects is magnified compared to point-to-point path computations. As the size of the network grows, the number of leaves and branches increases, further increasing the complexity of the overall path computation problem. A solution for managing point-to-multipoint path computations may be achieved using the PCE inter-domain point-to-multipoint path computation [RFC7334] procedure.
MPLS-TE LSPを使用するドメイン間ポイントツーマルチポイントアプリケーションシナリオの場合、ドメインシーケンス、ドメインポリシー、およびドメイン相互接続の選択と数の複雑さは、ポイントツーポイントパス計算に比べて拡大されます。ネットワークのサイズが大きくなると、リーフとブランチの数が増加し、パス計算問題全体の複雑さがさらに増大します。ポイントツーマルチポイントパス計算を管理するソリューションは、PCEドメイン間ポイントツーマルチポイントパス計算[RFC7334]手順を使用して実現できます。
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.
国際電気通信連合（ITU）は、[G-8080]でASONアーキテクチャを定義しています。 [G-7715]は、ASONのルーティングアーキテクチャを定義し、階層アーキテクチャを導入します。このアーキテクチャでは、ルーティングエリア（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, which is 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 (RC) during the operation of remote route queries. An RC is synonymous with a PCE.
ASONフレームワークでは、パス計算リクエストはルートクエリと呼ばれます。このクエリは、シグナリングを使用してLSPを確立する前に実行されます。LSPは、交換接続（SC）またはソフト永続接続（SPC）と呼ばれます。 [G-7715-2]は、リモートルートクエリの操作中にルーティングコントローラ（RC）が実行する機能の要件とアーキテクチャを定義しています。 RCはPCEと同義です。
In the ASON routing environment, an RC responsible for an RA may communicate with its neighbor RC to request the computation of an end-to-end path across several RAs. The path computation components and sequences are defined as follows:
ASONルーティング環境では、RAを担当するRCがその隣接RCと通信して、複数のRAにわたるエンドツーエンドパスの計算を要求できます。パス計算コンポーネントとシーケンスは、次のように定義されています。
* Remote route query. An operation where a Routing Controller communicates with another Routing Controller, which does not have the same set of layer resources, in order to compute a routing path in a collaborative manner.
* リモートルートクエリ。ルーティングパスを共同で計算するために、ルーティングコントローラーが同じレイヤーリソースのセットを持たない別のルーティングコントローラーと通信する操作。
* Route query requester. The connection controller or RC that sends a route query message to a Routing Controller that requests one or more routing paths satisfying a set of routing constraints.
* ルートクエリリクエスタ。一連のルーティング制約を満たす1つ以上のルーティングパスを要求するルーティングコントローラーにルートクエリメッセージを送信する接続コントローラーまたはRC。
* Route query responder. An RC that performs the path computation upon reception of a route query message from a Routing Controller or connection controller, and sends a response back at the end of the computation.
* ルートクエリレスポンダ。ルーティングコントローラーまたは接続コントローラーからルートクエリメッセージを受信するとパス計算を実行し、計算の最後に応答を返すRC。
When computing an end-to-end connection, the route may be computed by a single RC or multiple RCs in a collaborative manner, and the two scenarios can be considered a centralized remote route query model and a distributed remote route query model. RCs in an ASON environment can also use the hierarchical PCE [RFC6805] model to fully match the ASON hierarchical routing model.
エンドツーエンド接続を計算する場合、ルートは単一のRCまたは複数のRCによって協調的に計算されます。2つのシナリオは、集中リモートルートクエリモデルと分散リモートルートクエリモデルと見なすことができます。 ASON環境のRCは、階層PCE [RFC6805]モデルを使用して、ASON階層ルーティングモデルに完全に一致させることもできます。
Where a single operator operates multiple TE domains (including optical environments), an Abstraction and Control of TE Networks (ACTN) framework [RFC8453] may be used to create an abstracted (virtualized network) view of underlay-interconnected domains. This underlay connectivity is then exposed to higher-layer control entities and applications.
単一の事業者が複数のTEドメイン（光環境を含む）を運用している場合、TEネットワークの抽象化と制御（ACTN）フレームワーク[RFC8453]を使用して、アンダーレイ相互接続ドメインの抽象化（仮想化ネットワーク）ビューを作成できます。このアンダーレイ接続は、上位層の制御エンティティとアプリケーションに公開されます。
ACTN describes the method and procedure for coordinating the underlay per-domain Provisioning Network Controllers (PNCs), which may be PCEs, via a hierarchical model to facilitate setup of end-to-end connections across interconnected TE domains.
ACTNは、相互接続されたTEドメイン間でのエンドツーエンド接続のセットアップを容易にするために、階層モデルを介して、PCEである可能性があるアンダーレイのドメインごとのプロビジョニングネットワークコントローラー（PNC）を調整する方法と手順を説明します。
Policy is important in the deployment of new services and the operation of the network. [RFC5394] provides a framework for PCE-based policy-enabled path computation. This framework is based on the Policy Core Information Model (PCIM) as defined in [RFC3060] and further extended by [RFC3460].
ポリシーは、新しいサービスの展開とネットワークの運用において重要です。 [RFC5394]は、PCEベースのポリシー対応パス計算のフレームワークを提供します。このフレームワークは、[RFC3060]で定義され、[RFC3460]によってさらに拡張されたポリシーコア情報モデル（PCIM）に基づいています。
When using a PCE to compute inter-domain paths, policy may be invoked by specifying the following:
PCEを使用してドメイン間パスを計算する場合、以下を指定することでポリシーを呼び出すことができます。
* Each PCC must select which computations it will request from 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, whom to trust for that information, and how to refresh/update the information.
* PCEは、TEDで情報を収集する方法、その情報を信頼する人、および情報を更新/更新する方法を決定する必要があります。
* Each PCE must determine which objective functions and algorithms to apply.
* 各PCEは、適用する目的関数とアルゴリズムを決定する必要があります。
General PCE management considerations are discussed in [RFC4655]. In the case of multi-domains within a single service provider network, the management responsibility for each PCE would most likely be handled by the same service provider. In the case of multiple ASes within different service provider networks, it will likely be necessary for each PCE to be configured and managed separately by each participating service provider, with policy being implemented based on a previously agreed set of principles.
PCE管理の一般的な考慮事項は、[RFC4655]で説明されています。単一のサービスプロバイダーネットワーク内のマルチドメインの場合、各PCEの管理責任は、ほとんどの場合同じサービスプロバイダーによって処理されます。異なるサービスプロバイダーネットワーク内の複数のASの場合、各PCEは、参加している各サービスプロバイダーによって個別に構成および管理され、以前に合意された一連の原則に基づいてポリシーが実装される必要があります。
As per [RFC5440], PCEP implementation allows the user to configure a number of PCEP session parameters. These are detailed in Section 8.1 of [RFC5440].
[RFC5440]のとおり、PCEPの実装により、ユーザーはいくつかのPCEPセッションパラメータを構成できます。これらについては、[RFC5440]のセクション8.1で詳しく説明しています。
In H-PCE deployments, the administrative entity responsible for the management of the parent PCEs for multi-areas would typically be a single service provider. In multiple ASes (managed by different service providers), it may be necessary for a third party to manage the parent PCE.
H-PCE展開では、マルチエリアの親PCEの管理を担当する管理エンティティは通常、単一のサービスプロバイダーです。複数のAS（異なるサービスプロバイダーによって管理されている）では、サードパーティが親PCEを管理する必要がある場合があります。
A PCEP MIB module is defined in [RFC7420], which describes managed objects for modeling PCEP communication, including:
PCEP MIBモジュールは[RFC7420]で定義されており、以下を含むPCEP通信をモデリングするための管理対象オブジェクトについて説明しています。
* PCEP client configuration and status.
* PCEPクライアントの構成とステータス。
* PCEP peer configuration and information.
* PCEPピアの構成と情報。
* PCEP session configuration and information.
* PCEPセッションの構成と情報。
* Notifications to indicate PCEP session changes.
* PCEPセッションの変更を示す通知。
A YANG module for PCEP has also been proposed [PCEP-YANG].
PCEP用のYANGモジュールも提案されています[PCEP-YANG]。
An H-PCE MIB module or YANG data model will be required to report parent PCE and child PCE information, including:
H-PCE MIBモジュールまたはYANGデータモデルは、以下を含む親PCEおよび子PCE情報を報告する必要があります。
* Parent PCE configuration and status.
* 親PCEの構成とステータス。
* Child PCE configuration and information.
* 子PCEの構成と情報。
* Notifications to indicate session changes between parent PCEs and child PCEs.
* 親PCEと子PCEの間のセッション変更を示す通知。
* Notification of parent PCE TED updates and changes.
* 親PCE TEDの更新と変更の通知。
PCEP includes a keepalive mechanism to check the liveliness of a PCEP peer and a notification procedure allowing a PCE to advertise its overloaded state to a PCC. In a multi-domain environment, [RFC5886] provides the procedures necessary to monitor the liveliness and performance of a given PCE chain.
PCEPには、PCEPピアの活性をチェックするキープアライブメカニズムと、PCEがその過負荷状態をPCCに通知できるようにする通知手順が含まれています。マルチドメイン環境では、[RFC5886]は、特定のPCEチェーンの活性とパフォーマンスを監視するために必要な手順を提供します。
It is important to verify the correct operation of PCEP. [RFC5440] specifies the monitoring of key parameters. These parameters are detailed in [RFC5520].
PCEPが正しく動作することを確認することが重要です。 [RFC5440]は、主要なパラメータの監視を指定します。これらのパラメータは[RFC5520]で詳述されています。
[RFC5440] states that in order to avoid any unacceptable impact on network operations, a PCEP implementation should allow a limit to be placed on the number of sessions that can be set up on a PCEP speaker and that it may also be practical to place a limit on the rate of messages sent by a PCC and received by the PCE.
[RFC5440]は、ネットワーク操作への許容できない影響を回避するために、PCEPの実装では、PCEPスピーカーで設定できるセッション数に制限を設けることを許可する必要があり、 PCCによって送信され、PCEによって受信されるメッセージのレートの制限。
PCEP security considerations are discussed in [RFC5440] and [RFC6952]. Potential vulnerabilities include spoofing, snooping, falsification, and using PCEP as a mechanism for denial of service attacks.
PCEPのセキュリティに関する考慮事項は、[RFC5440]および[RFC6952]で説明されています。潜在的な脆弱性には、なりすまし、スヌーピング、改ざん、およびサービス拒否攻撃のメカニズムとしてのPCEPの使用が含まれます。
As PCEP operates over TCP, it may make use of TCP security encryption mechanisms, such as Transport Layer Security (TLS) and TCP Authentication Option (TCP-AO). Usage of these security mechanisms for PCEP is described in [RFC8253], and recommendations and best current practices are described in [RFC7525].
PCEPはTCPで動作するため、トランスポート層セキュリティ（TLS）やTCP認証オプション（TCP-AO）などのTCPセキュリティ暗号化メカニズムを利用する場合があります。 PCEPのこれらのセキュリティメカニズムの使用法は[RFC8253]で説明されており、推奨事項と現在のベストプラクティスは[RFC7525]で説明されています。
Any multi-domain operation necessarily involves the exchange of information across domain boundaries. This represents a significant security and confidentiality risk.
マルチドメイン操作では、ドメイン境界を越えた情報の交換が必ず必要です。これは、セキュリティと機密性に関する重大なリスクです。
It is expected that PCEP is used between PCCs and PCEs that belong to the same administrative authority while also using one of the aforementioned encryption mechanisms. Furthermore, PCEP allows individual PCEs to maintain the confidentiality of their domain path information using path-keys.
PCEPは、前述の暗号化メカニズムのいずれかを使用しながら、同じ管理権限に属するPCCとPCEの間で使用されることが期待されます。さらに、PCEPを使用すると、個々のPCEがパスキーを使用してドメインパス情報の機密性を維持できます。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://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、DOI 10.17487 / RFC3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <https://www.rfc-editor.org/info/rfc3473>.
[RFC3473] Berger、L。、編、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、DOI 10.17487 / RFC3473、2003年1月、<https： //www.rfc-editor.org/info/rfc3473>。
[RFC4216] Zhang, R., Ed. and J.-P. Vasseur, Ed., "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, DOI 10.17487/RFC4216, November 2005, <https://www.rfc-editor.org/info/rfc4216>.
[RFC4216] Zhang、R.、Ed。とJ.-P. Vasseur編、「MPLS Inter-Autonomous System（AS）Traffic Engineering（TE）Requirements」、RFC 4216、DOI 10.17487 / RFC4216、2005年11月、<https://www.rfc-editor.org/info/rfc4216> 。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<https：// www.rfc-editor.org/info/rfc4655>。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, DOI 10.17487/RFC4726, November 2006, <https://www.rfc-editor.org/info/rfc4726>.
[RFC4726] Farrel、A.、Vasseur、J.-P。、およびA. Ayyangar、「A Interframe for Inter-domain Multiprotocol Label Switching Traffic Engineering」、RFC 4726、DOI 10.17487 / RFC4726、2006年11月、<https：/ /www.rfc-editor.org/info/rfc4726>。
[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, DOI 10.17487/RFC5152, February 2008, <https://www.rfc-editor.org/info/rfc5152>.
[RFC5152] Vasseur、JP。、編、Ayyangar、A。、編、およびR. Zhang、「ドメイン間トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）を確立するためのドメインごとのパス計算方法」、 RFC 5152、DOI 10.17487 / RFC5152、2008年2月、<https://www.rfc-editor.org/info/rfc5152>。
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5440] Vasseur、JP。、Ed。とJL。 Le Roux編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<https://www.rfc-editor.org/info/rfc5440>。
[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, DOI 10.17487/RFC5441, April 2009, <https://www.rfc-editor.org/info/rfc5441>.
[RFC5441] Vasseur、JP。、Ed。、Zhang、R.、Bitar、N.、and JL。 Le Roux、「最短の制約付きドメイン間トラフィックエンジニアリングラベルスイッチドパスを計算するための後方再帰PCEベースの計算（BRPC）手順」、RFC 5441、DOI 10.17487 / RFC5441、2009年4月、<https：//www.rfc- editor.org/info/rfc5441>。
[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, DOI 10.17487/RFC5520, April 2009, <https://www.rfc-editor.org/info/rfc5520>.
[RFC5520] Bradford、R。、編、Vasseur、JP、およびA. Farrel、「パスキーベースのメカニズムを使用したドメイン間パス計算におけるトポロジー機密性の保持」、RFC 5520、DOI 10.17487 / RFC5520、4月2009、<https://www.rfc-editor.org/info/rfc5520>。
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, June 2009, <https://www.rfc-editor.org/info/rfc5541>.
[RFC5541] Le Roux、JL。、Vasseur、JP。、and Y. Lee、 "Encoding of Objective Functions in the Path Computation Element Communication Protocol（PCEP）"、RFC 5541、DOI 10.17487 / RFC5541、June 2009、<https： //www.rfc-editor.org/info/rfc5541>。
[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, DOI 10.17487/RFC6805, November 2012, <https://www.rfc-editor.org/info/rfc6805>.
[RFC6805]キング、D。、エド。およびA.ファレル編、「MPLSおよびGMPLSにおける一連のドメインの決定へのパス計算要素アーキテクチャの適用」、RFC 6805、DOI 10.17487 / RFC6805、2012年11月、<https：//www.rfc -editor.org/info/rfc6805>。
[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, DOI 10.17487/RFC3060, February 2001, <https://www.rfc-editor.org/info/rfc3060>.
[RFC3060] Moore、B.、Ellesson、E.、Strassner、J。、およびA. Westerinen、「Policy Core Information Model-Version 1 Specification」、RFC 3060、DOI 10.17487 / RFC3060、2001年2月、<https：/ /www.rfc-editor.org/info/rfc3060>。
[RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) Extensions", RFC 3460, DOI 10.17487/RFC3460, January 2003, <https://www.rfc-editor.org/info/rfc3460>.
[RFC3460] Moore、B。、編、「Policy Core Information Model（PCIM）Extensions」、RFC 3460、DOI 10.17487 / RFC3460、2003年1月、<https://www.rfc-editor.org/info/rfc3460> 。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.
[RFC3630] Katz、D.、Kompella、K.、D。Yeung、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、DOI 10.17487 / RFC3630、2003年9月、<https：//www.rfc -editor.org/info/rfc3630>。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, <https://www.rfc-editor.org/info/rfc4090>.
[RFC4090] Pan、P。、編、Swallow、G、編、A。Atlas、編、「LSPトンネル用のRSVP-TEへの高速リルート拡張」、RFC 4090、DOI 10.17487 / RFC4090、2005年5月、<https://www.rfc-editor.org/info/rfc4090>。
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, <https://www.rfc-editor.org/info/rfc4203>.
[RFC4203] Kompella、K.、Ed。およびY. Rekhter編、「汎用マルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張機能」、RFC 4203、DOI 10.17487 / RFC4203、2005年10月、<https://www.rfc-editor.org/info / rfc4203>。
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, DOI 10.17487/RFC4920, July 2007, <https://www.rfc-editor.org/info/rfc4920>.
[RFC4920] Farrel、A.、Ed。、Satyanarayana、A.、Iwata、A.、Fujita、N。、およびG. Ash、「MPLSおよびGMPLS RSVP-TEのクランクバックシグナリング拡張機能」、RFC 4920、DOI 10.17487 / RFC4920、2007年7月、<https://www.rfc-editor.org/info/rfc4920>。
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, January 2008, <https://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、DOI 10.17487 / RFC5088、2008年1月、<https://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, DOI 10.17487/RFC5089, January 2008, <https://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、DOI 10.17487 / RFC5089、2008年1月、<https://www.rfc-editor.org/info/rfc5089>。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、DOI 10.17487 / RFC5305、2008年10月、<https://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, DOI 10.17487/RFC5307, October 2008, <https://www.rfc-editor.org/info/rfc5307>.
[RFC5307] Kompella、K.、Ed。およびY. Rekhter編、「一般化マルチプロトコルラベルスイッチング（GMPLS）をサポートするIS-IS拡張機能」、RFC 5307、DOI 10.17487 / RFC5307、2008年10月、<https://www.rfc-editor.org / info / rfc5307>。
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, December 2008, <https://www.rfc-editor.org/info/rfc5316>.
[RFC5316] Chen、M.、Zhang、R。、およびX. Duan、「Inter-Autonomous System（AS）MPLSおよびGMPLSトラフィックエンジニアリングをサポートするISIS拡張機能」、RFC 5316、DOI 10.17487 / RFC5316、2008年12月、< https://www.rfc-editor.org/info/rfc5316>。
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, January 2009, <https://www.rfc-editor.org/info/rfc5392>.
[RFC5392] Chen、M.、Zhang、R。、およびX. Duan、「Inter-Autonomous System（AS）MPLSおよびGMPLSトラフィックエンジニアリングをサポートするOSPF拡張機能」、RFC 5392、DOI 10.17487 / RFC5392、2009年1月、< https://www.rfc-editor.org/info/rfc5392>。
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, DOI 10.17487/RFC5394, December 2008, <https://www.rfc-editor.org/info/rfc5394>.
[RFC5394] Bryskin、I.、Papadimitriou、D.、Berger、L。、およびJ. Ash、「ポリシー対応パス計算フレームワーク」、RFC 5394、DOI 10.17487 / RFC5394、2008年12月、<https：// www。 rfc-editor.org/info/rfc5394>。
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April 2009, <https://www.rfc-editor.org/info/rfc5521>.
[RFC5521] Oki、E.、Takeda、T。、およびA. Farrel、「Extensions to the Path Computation Element Communication Protocol（PCEP）for Route Exclusions」、RFC 5521、DOI 10.17487 / RFC5521、2009年4月、<https：/ /www.rfc-editor.org/info/rfc5521>。
[RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, <https://www.rfc-editor.org/info/rfc5886>.
[RFC5886] Vasseur、JP。、Ed。、Le Roux、JL。、and Y. Ikejiri、 "A Set Monitoring Tools for Path Computation Element（PCE）-Based Architecture"、RFC 5886、DOI 10.17487 / RFC5886、June 2010 、<https://www.rfc-editor.org/info/rfc5886>。
[RFC6007] Nishioka, I. and D. King, "Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations", RFC 6007, DOI 10.17487/RFC6007, September 2010, <https://www.rfc-editor.org/info/rfc6007>.
[RFC6007] Nishioka、I. and D. King、 "Use of the Synchronization VECtor（SVEC）List for Synchronized Dependent Path Computations"、RFC 6007、DOI 10.17487 / RFC6007、September 2010、<https：//www.rfc-editor .org / info / rfc6007>。
[G-8080] ITU-T, "Architecture for the automatically switched optical network", ITU-T Recommendation G.8080/Y.1304, February 2012.
[G-8080] ITU-T、「自動切り替え光ネットワークのアーキテクチャ」、ITU-T勧告G.8080 / Y.1304、2012年2月。
[G-7715] ITU-T, "Architecture and requirements for routing in the automatically switched optical networks", ITU-T Recommendation G.7715/Y.1706, June 2002.
[G-7715] ITU-T、「アーキテクチャと自動切り替え光ネットワークでのルーティングの要件」、ITU-T勧告G.7715 / Y.1706、2002年6月。
[G-7715-2] ITU-T, "ASON routing architecture and requirements for remote route query", ITU-T Recommendation G.7715.2/Y.1706.2, February 2007.
[G-7715-2] ITU-T、「ASONルーティングアーキテクチャとリモートルートクエリの要件」、ITU-T勧告G.7715.2 / Y.1706.2、2007年2月。
[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, DOI 10.17487/RFC6952, May 2013, <https://www.rfc-editor.org/info/rfc6952>.
[RFC6952] Jethanandani、M.、Patel、K。、およびL. Zheng、「ルーティングプロトコルのキーイングおよび認証（KARP）設計ガイドによるBGP、LDP、PCEP、およびMSDPの問題の分析」、RFC 6952、DOI 10.17487 / RFC6952、2013年5月、<https://www.rfc-editor.org/info/rfc6952>。
[RFC7334] Zhao, Q., Dhody, D., King, D., Ali, Z., and R. Casellas, "PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths", RFC 7334, DOI 10.17487/RFC7334, August 2014, <https://www.rfc-editor.org/info/rfc7334>.
[RFC7334] Zhao、Q.、Dhody、D.、King、D.、Ali、Z。、およびR. Casellas、「最短の制約付きポイントツーマルチポイント（P2MP）ドメイン間トラフィックを計算するためのPCEベースの計算手順Engineering Label Switched Paths」、RFC 7334、DOI 10.17487 / RFC7334、2014年8月、<https://www.rfc-editor.org/info/rfc7334>。
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014, <https://www.rfc-editor.org/info/rfc7420>.
[RFC7420] Koushik、A.、Stephan、E.、Zhao、Q.、King、D。、およびJ. Hardwick、「Path Computation Element Communication Protocol（PCEP）Management Information Base（MIB）Module」、RFC 7420、DOI 10.17487 / RFC7420、2014年12月、<https://www.rfc-editor.org/info/rfc7420>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<https://www.rfc-editor.org/info/rfc7525>。
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.
[RFC7752] Gredler、H.、Ed。、Medved、J.、Previdi、S.、Farrel、A.、and S. Ray、 "North-bound Distribution of Link-State and Traffic Engineering（TE）Information using BGP" 、RFC 7752、DOI 10.17487 / RFC7752、2016年3月、<https://www.rfc-editor.org/info/rfc7752>。
[RFC7897] Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects for the Path Computation Element Communication Protocol (PCEP)", RFC 7897, DOI 10.17487/RFC7897, June 2016, <https://www.rfc-editor.org/info/rfc7897>.
[RFC7897] Dhody、D.、Palle、U。、およびR. Casellas、「Path Computation Element Communication Protocol（PCEP）のドメインサブオブジェクト」、RFC 7897、DOI 10.17487 / RFC7897、2016年6月、<https：// www .rfc-editor.org / info / rfc7897>。
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, <https://www.rfc-editor.org/info/rfc8253>.
[RFC8253] Lopez、D.、Gonzalez de Dios、O.、Wu、Q。、およびD. Dhody、「PCEPS：TLSの使用によるパス計算要素通信プロトコル（PCEP）のセキュアなトランスポートの提供」、RFC 8253 、DOI 10.17487 / RFC8253、2017年10月、<https://www.rfc-editor.org/info/rfc8253>。
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/info/rfc8453>.
[RFC8453] Ceccarelli、D.、Ed。 Y.リー、編、「TEネットワークの抽象化と制御のフレームワーク（ACTN）」、RFC 8453、DOI 10.17487 / RFC8453、2018年8月、<https://www.rfc-editor.org/info/rfc8453> 。
[PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, Internet-Draft, draft-ietf-pce-pcep-yang-13, 31 October 2019, <https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13>.
[PCEP-YANG] Dhody、D.、Hardwick、J.、Beeram、V。、およびJ. Tantsura、「パス計算要素通信プロトコル（PCEP）のYANGデータモデル」、作業中、インターネットドラフト、ドラフト-ietf-pce-pcep-yang-13、2019年10月31日、<https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13>。
Acknowledgements
謝辞
The author would like to thank Adrian Farrel for his review and Meral Shirazipour and Francisco Javier Jiménez Chico for their comments.
著者は、レビューしてくれたAdrian FarrelとコメントしてくれたMeral ShirazipourとFrancisco JavierJiménezChicoに感謝します。
Contributors
貢献者
Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore 560066 Karnataka India
Dhruv Dhodoi Huawei Technologies Divyashari Techno Park、Whitfished Bangalore 2008 Karnataka India
Email: dhruv.ietf@gmail.com
Quintin Zhao Huawei Technologies 125 Nagog Technology Park Acton, MA 01719 United States of America
Quintin Zhao Huawei Technologies 125 Nagog Technology Park Acton、MA 01719アメリカ合衆国
Email: qzhao@huawei.com
Julien Meuric France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France
Julien Meuric France Telecom 2、avenue Pierre-Marzin 22307 Lannion Cedex France
Email: julien.meuric@orange.com
Olivier Dugeon France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France
Olivier Dugeon France Telecom 2、avenue Pierre-Marzin 22307 Lannion Cedex France
Email: olivier.dugeon@orange.com
Jon Hardwick Metaswitch Networks 100 Church Street Enfield EN2 6BQ United Kingdom
Jon Hardwick Metaswitch Networks 100 Church Street Enfield EN2 6BQイギリス
Email: jonathan.hardwick@metaswitch.com
Óscar González de Dios Telefonica I+D Emilio Vargas 6 Madrid Spain
オスカーゴンサレスデディオステレフォニカI + Dエミリオバルガス6マドリードスペイン
Email: oscar.gonzalezdedios@telefonica.com
Authors' Addresses
著者のアドレス
Daniel King Old Dog Consulting
Daniel King Old Dog Consulting
Email: daniel@olddog.co.uk
Haomian Zheng Huawei Technologies H1, Huawei Xiliu Beipo Village, Songshan Lake Dongguan Guangdong, 523808 China
ハオフェイスZは非常にGHです。
Email: zhenghaomian@huawei.com
Additional contact information:
追加の連絡先情報：
郑好棉 中国 523808 广东 东莞 松山湖华为溪流背坡村H1 华为技术有限公司
Zheng Haomian China 523808 Guangdong Dongguan Songshan Lake Huawei Streamback Village H1 Huawei Technologies Co.、Ltd.