[要約] RFC 4674は、Path Computation Element (PCE)の発見に関する要件を定義しています。その目的は、ネットワーク内のPCEを自動的に検出し、経路計算を効率化することです。
Network Working Group J.L. Le Roux, Ed.
Request for Comments: 4674 France Telecom
Category: Informational October 2006
Requirements for Path Computation Element (PCE) Discovery
パス計算要素（PCE）発見の要件
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection. It is intended that solutions that specify procedures and protocols or extensions to existing protocols for such PCE discovery satisfy these requirements.
このドキュメントでは、PATH計算クライアント（PCC）がPCE選択に関連する特定の情報とともに、PATH計算クライアント（PCC）が動的かつ自動的にPCEを発見できるようにするパス計算要素（PCE）発見メカニズムの一連の要件を提示します。このようなPCE発見のために既存のプロトコルに手順とプロトコルまたは拡張を指定するソリューションがこれらの要件を満たすことを意図しています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
1.2. Terminology ................................................3
2. Problem Statement and Requirements Overview .....................4
2.1. Problem Statement ..........................................4
2.2. Requirements Overview ......................................5
3. Example of Application Scenario .................................6
4. Detailed Requirements ...........................................7
4.1. PCE Information to Be Disclosed ............................7
4.1.1. General PCE Information (Mandatory Support) .........8
4.1.1.1. Discovery of PCE Location ..................8
4.1.1.2. Discovery of PCE Domains and
Inter-domain Functions .....................8
4.1.2. Detailed PCE Information (Optional Support) .........9
4.1.2.1. Discovery of PCE Capabilities ..............9
4.1.2.2. Discovery of Alternate PCEs ...............10
4.2. Scope of PCE Discovery ....................................10
4.2.1. Inter-AS Specific Requirements .....................10
4.3. PCE Information Synchronization ...........................11
4.4. Discovery of PCE Deactivation .............................11
4.5. Policy Support ............................................12
4.6. Security Requirements .....................................12
4.7. Extensibility .............................................13
4.8. Scalability ...............................................13
4.9. Operational Orders of Magnitudes ..........................13
4.10. Manageability Considerations .............................14
4.10.1. Configuration of PCE Discovery Parameters .........14
4.10.2. PCE Discovery MIB Modules .........................14
4.10.2.1. PCC MIB Module ...........................14
4.10.2.2. PCE MIB module ...........................15
4.10.3. Monitoring Protocol Operations ....................15
4.10.4. Impact on Network Operations ......................16
5. Security Considerations ........................................16
6. Acknowledgements ...............................................16
7. Contributors ...................................................17
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................17
The PCE-based network architecture [RFC4655] defines a Path Computation Element (PCE) as an entity capable of computing TE-LSP paths based on a network graph, and applying computational constraints. A PCE serves path computation requests sent by Path Computation Clients (PCC).
PCEベースのネットワークアーキテクチャ[RFC4655]は、パス計算要素（PCE）を、ネットワークグラフに基づいてTE-LSPパスを計算し、計算制約を適用できるエンティティとして定義します。PCEは、Path Computation Clients（PCC）から送信されたPATH計算要求を提供します。
A PCC is a client application requesting a path computation to be performed by a PCE. This can be, for instance, an LSR requesting a path for a TE-LSP for which it is the head-end, or a PCE requesting a path computation of another PCE (inter-PCE communication). The communication between a PCC and a PCE requires a client-server protocol whose generic requirements are listed in [RFC4657].
PCCは、PCEによって実行されるパス計算を要求するクライアントアプリケーションです。これは、たとえば、ヘッドエンドであるTE-LSPのパスを要求するLSR、または別のPCE（PCE間通信）のパス計算を要求するPCEです。PCCとPCE間の通信には、[RFC4657]に一般的な要件がリストされているクライアントサーバープロトコルが必要です。
The PCE based architecture requires that a PCC be aware of the location of one or more PCEs in its domain, and also potentially of some PCEs in other domains, e.g., in case of inter-domain path computation.
PCEベースのアーキテクチャでは、PCCがドメイン内の1つ以上のPCEの位置を認識し、潜在的に他のドメインの一部のPCEを認識する必要があります。
In that context, it would be highly desirable to define a mechanism for automatic and dynamic PCE discovery, which would allow PCCs to automatically discover a set of PCEs, to determine additional information required for PCE selection, and to dynamically detect new PCEs or any modification of the PCEs' information. This includes the discovery by a PCC of a set of one or more PCEs in its domain, and potentially in some other domains. The latter is a desirable function in the case of inter-domain path computation, for example.
その文脈では、PCCSがPCEのセットを自動的に発見し、PCE選択に必要な追加情報を決定し、新しいPCESまたは変更を動的に検出できるようにする自動および動的なPCE発見のメカニズムを定義することが非常に望ましいでしょう。PCESの情報の。これには、そのドメイン内の1つ以上のPCESのセットのPCCによる発見、および潜在的に他のドメインでの発見が含まれます。後者は、たとえば、ドメイン間パス計算の場合、望ましい関数です。
This document lists a set of functional requirements for such an automatic and dynamic PCE discovery mechanism. Section 2 points out the problem statement. Section 3 illustrates an application scenario. Finally, Section 4 addresses detailed requirements.
このドキュメントには、このような自動および動的なPCE発見メカニズムの一連の機能要件がリストされています。セクション2では、問題の声明を示しています。セクション3では、アプリケーションシナリオを示しています。最後に、セクション4では詳細な要件について説明します。
It is intended that solutions that specify procedures and protocols or protocol extensions for PCE discovery satisfy these requirements. There is no intent either to specify solution-specific requirements or to make any assumption on the protocols that could be used for the discovery.
PCE発見のための手順とプロトコルまたはプロトコル拡張を指定するソリューションがこれらの要件を満たすことを意図しています。ソリューション固有の要件を指定したり、発見に使用できるプロトコルで仮定を立てる意図はありません。
Note that requirements listed in this document apply equally to PCEs that are capable of computing paths in MPLS-TE-enabled networks and PCEs that are capable of computing paths in GMPLS-enabled networks (and PCEs capable of both).
このドキュメントにリストされている要件は、GMPLS対応ネットワーク（および両方が可能なPCE）でパスを計算できるMPLS-TE対応ネットワークとPCESのパスを計算できるPCEに等しく適用されることに注意してください。
It is also important to note that the notion of a PCC encompasses a PCE acting as PCC when requesting a path computation of another PCE (inter-PCE communication). Hence, this document does not make the distinction between PCE discovery by PCCs and PCE discovery by PCEs.
また、PCCの概念は、別のPCE（PCE間通信）のパス計算を要求する際にPCCとして機能するPCCを含むことに注意することも重要です。したがって、この文書は、PCCSによるPCE発見とPCESによるPCE発見を区別しません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119に記載されているとおりに解釈されます。
Terminology used in this document:
このドキュメントで使用される用語：
LSR: Label Switch Router.
LSR：ラベルスイッチルーター。
TE-LSP: Traffic Engineered Label Switched Path.
TE-LSP：トラフィックエンジニアリングラベルの切り替えパス。
PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph, and applying computational constraints.
PCE：パス計算要素。ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用できるエンティティ（コンポーネント、アプリケーション、またはネットワークノード）。
PCC: Path Computation Client. Any client application requesting a path computation to be performed by a Path Computation Element.
PCC：パス計算クライアント。パス計算要素によって実行されるパス計算を要求するクライアントアプリケーション。
Interior Gateway Protocol (IGP) Area: OSPF Area or ISIS level/area.
インテリアゲートウェイプロトコル（IGP）エリア：OSPFエリアまたはISISレベル/エリア。
ABR: IGP Area Border Router (OSPF ABR or ISIS L1L2 router).
ABR：IGPエリアボーダールーター（OSPF ABRまたはISIS L1L2ルーター）。
AS: Autonomous System.
AS：自律システム。
ASBR: AS Border Router.
ASBR：ボーダールーターとして。
Intra-area TE LSP: A TE LSP whose path does not cross IGP area boundaries.
Intra-Area ele lsp：IGPエリアの境界を通過しないTE LSP。
Inter-area TE LSP: A TE LSP whose path transits through two or more IGP areas.
Inter-Areae LSP：2つ以上のIGP領域を通過するTE LSP。
Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or more ASs or sub-ASs (BGP confederations).
MPLS Inter-AS MPLS TE LSP：2つ以上のASSまたはサブアス（BGPコンフェデレーション）を通過するTE LSP。
Domain: Any collection of network elements within a common sphere of address management or path computational responsibility. Examples of domains include IGP areas and Autonomous Systems.
ドメイン：アドレス管理またはパス計算責任の共通の範囲内のネットワーク要素のコレクション。ドメインの例には、IGP領域と自律システムが含まれます。
A routing domain may, in practice, contain multiple PCEs:
ルーティングドメインには、実際には複数のPCEが含まれる場合があります。
- The path computation load may be balanced among a set of PCEs to improve scalability. - For the purpose of redundancy, primary and backup PCEs may be used. - PCEs may have distinct path computation capabilities (multi-constrained path computation, backup path computation, etc.). - In an inter-domain context, there can be several PCEs with distinct inter-domain functions (inter-area, inter-AS, inter-layer), each PCE being responsible for path computation in one or more domains.
- パス計算負荷は、スケーラビリティを向上させるために、PCESのセット間でバランスが取れている場合があります。 - 冗長性を目的として、プライマリおよびバックアップPCEを使用することができます。-PCESには、個別のパス計算機能（マルチクローン型パス計算、バックアップパス計算など）がある場合があります。 - ドメイン間のコンテキストでは、異なるドメイン間関数（エリア間、AS間、層間）を持ついくつかのPCEがあり、各PCEは1つ以上のドメインでのパス計算の原因です。
In order to allow for effective PCE selection by PCCs, that is, to select the appropriate PCE based on its capabilities and perform efficient load balancing of requests, a PCC needs to know the location of PCEs in its domain, along with some information relevant to PCE selection, and also potentially needs to know the location of some PCEs in other domains, for inter-domain path computation purpose.
PCCによる効果的なPCE選択を可能にするため、つまり、その機能に基づいて適切なPCEを選択し、リクエストの効率的な負荷分散を実行するために、PCCは、そのドメイン内のPCEの位置を知る必要があります。PCEの選択、およびドメイン間パス計算目的のために、他のドメインの一部のPCEの位置を知る必要がある可能性があります。
Such PCE information could be learned through manual configuration, on each PCC, of the set of PCEs along with their capabilities. Such a manual configuration approach may be sufficient, and even desired in some particular situations (e.g., inter-AS PCE discovery, where manual configuration of neighbor PCEs may be preferred for security reasons), but it obviously faces several limitations:
このようなPCE情報は、各PCCで、PCEのセットとその機能とともに、手動構成を通じて学習できます。このような手動構成アプローチは十分であり、特定の状況でも必要な場合があります（たとえば、PCE Inter-AS PCE発見、セキュリティ上の理由で隣接PCEの手動構成が好まれる場合があります）が、明らかにいくつかの制限に直面しています。
- This may imply a substantial configuration overhead. - This would not allow a PCC to dynamically detect that a new PCE is available, that an existing PCE is no longer available, or that there is a change in the PCE's information.
- これは、かなりの構成オーバーヘッドを意味する場合があります。 - これにより、PCCが新しいPCEが利用可能であること、既存のPCEが利用できなくなったこと、またはPCEの情報に変更があることを動的に検出することはできません。
Furthermore, as with any manual configuration approach, there is a risk of configuration errors.
さらに、他の手動構成アプローチと同様に、構成エラーのリスクがあります。
As an example, in a multi-area network made up of one backbone area and N peripheral areas, and where inter-area MPLS-TE path computation relies on multiple-PCE path computation with ABRs acting as PCEs, the backbone area would comprise at least N PCEs, and the configuration of PCC would be too cumbersome (e.g., in existing multi-area networks, N can be beyond fifty).
例として、1つのバックボーン領域とN周辺領域で構成されたマルチエリアネットワークで、およびエリア間MPLS-TEパス計算がPCESとして機能するABRを使用した多重PCEパス計算に依存している場合、バックボーン領域は最小のPCE、およびPCCの構成は面倒すぎます（たとえば、既存のマルチエリアネットワークでは、Nは50を超えています）。
Hence, an automated PCE discovery mechanism allowing a PCC to dynamically discover a set of PCEs is highly desirable.
したがって、PCCが一連のPCEを動的に発見できるようにする自動化されたPCE発見メカニズムは非常に望ましいです。
A PCE discovery mechanism that satisfies the requirements set forth in this document MUST allow a PCC to automatically discover the location of one or more of the PCEs in its domain.
このドキュメントに記載されている要件を満たすPCE発見メカニズムは、PCCがドメイン内の1つ以上のPCEの位置を自動的に発見できるようにする必要があります。
Where inter-domain path computation is required and policy permits, the PCE discovery method MUST allow a PCC to automatically discover the location of PCEs in other domains that can assist with inter-domain path computation.
ドメイン間パス計算が必要であり、ポリシー許可がある場合、PCC発見方法により、PCCは、ドメイン間パス計算を支援できる他のドメインのPCEの位置を自動的に発見できるようにする必要があります。
A PCE discovery mechanism MUST allow a PCC to discover the set of one or more domains where a PCE has TE topology visibility and can compute paths. It MUST also allow the discovery of the potential inter-domain path computation functions of a PCE (inter-area, inter-AS, inter-layer, etc.).
PCE発見メカニズムにより、PCCは、PCEにTEトポロジの可視性があり、パスを計算できる1つ以上のドメインのセットを発見できるようにする必要があります。また、PCEの潜在的なドメイン間パス計算関数（エリア間、AS間、層間など）の潜在的な発見を可能にする必要があります。
A PCE discovery mechanism MUST allow the control of the discovery scope, that is the set of one or more domains (areas, ASs) where information related to a given PCE has to be disclosed.
PCE発見メカニズムは、特定のPCEに関連する情報を開示する必要がある1つ以上のドメイン（エリア、ASS）のセットである発見範囲の制御を可能にする必要があります。
A PCE discovery mechanism MUST allow PCCs in a given discovery scope to dynamically discover that a new PCE has appeared or that there is a change in a PCE's information.
PCE発見メカニズムにより、特定の発見範囲内のPCCが新しいPCEが表示されていること、またはPCEの情報に変更があることを動的に発見する必要があります。
A PCE discovery mechanism MUST allow PCCs to dynamically discover that a PCE is no longer available.
PCE発見メカニズムにより、PCCはPCEが使用できなくなったことを動的に発見する必要があります。
A PCE discovery mechanism MUST support security procedures. In particular, key consideration MUST be given in terms of how to establish a trust model for PCE discovery.
PCE発見メカニズムは、セキュリティ手順をサポートする必要があります。特に、PCE発見のための信頼モデルを確立する方法に関して、重要な考慮事項を示す必要があります。
OPTIONALLY, a PCE discovery mechanism MAY be used so as to disclose a set of detailed PCE capabilities so that the PCC may make advanced and informed choices about which PCE to use.
オプションでは、PCCが使用するPCEについて高度かつ情報に基づいた選択を行うように、一連の詳細なPCE機能を開示するためにPCE発見メカニズムを使用する場合があります。
<----------------AS1--------------------> <----AS2---
Area 1 Area 0 Area 2
R1---------R3-----R5-------R6-----------R9----------R11----R13
| | | |
| | | |
R2---------R4-----R7-------R8-----------R10---------R12----R14
|
|
--
|S1|
--
Figure 1
図1
Figure 1 illustrates a multi-area/AS network with several PCEs:
図1は、複数のPCESを含むマルチエリア/ASネットワークを示しています。
- The ABR R3 is a PCE that can take part in inter-area path computation. It can compute paths in area 1 and area 0. - The ABR R6 is a PCE that can take part in inter-area path computation. It can compute paths in area 0 and area 2. - The ASBR R9 is a PCE that can take part in inter-AS path computation. It is responsible for path computation in AS1 towards AS2. - The ASBR R12 is a PCE that can take part in inter-AS path computation. It is responsible for path computation in AS2 towards AS1. - The server S1 is a PCE that can be used to compute diverse paths and backup paths in area 1.
- ABR R3は、エリア間パス計算に参加できるPCEです。エリア1とエリア0のパスを計算できます。 -ABR R6は、エリア間パス計算に参加できるPCEです。エリア0とエリア2のパスを計算できます。 -ASBR R9は、PATH間計算に参加できるPCEです。AS1に対するAS1のパス計算を担当します。-ASBR R12は、AS Inter-AS Path計算に参加できるPCEです。AS2に対するAS2のパス計算を担当します。 - サーバーS1は、エリア1の多様なパスとバックアップパスを計算するために使用できるPCEです。
By meeting the requirements set out in this document, the PCE discovery mechanism will allow:
このドキュメントに記載されている要件を満たすことにより、PCE発見メカニズムは以下を許可します。
- each PCC in areas 1 and 0 to dynamically discover R3, as a PCE for inter-area path computation, and that R3 can compute paths in area 0 and area 1. - each PCC in areas 0 and 2 to dynamically discover R6, as a PCE for inter-area path computation, and that R6 can compute paths in area 2 and area 0. - each PCC in AS1 and one or more PCCs in AS2 to dynamically discover R9 as a PCE for inter-AS path computation in AS1 towards AS2. - each PCC in AS2 and one or more PCCs in AS1 to dynamically discover R12 as a PCE for inter-AS path computation in AS2 towards AS1. - each PCC in area 1 to dynamically discover S1, as a PCE for intra-area path computation in area1, and optionally to discover its path computation capabilities (diverse path computation and backup path computation).
- エリア1および0の各PCCは、R3をエリア間パス計算のPCEとして動的に発見し、R3はエリア0およびエリア1のパスを計算できます。エリア間パス計算のPCE、およびそのR6はエリア2およびエリア0のパスを計算できます。。-AS2の各PCCおよびAS1の1つ以上のPCCは、AS2に向かってAS2のAS PATH計算のPCEとしてR12を動的に発見します。 - エリア1の各PCCがS1を動的に発見し、AREA1のエリア内パス計算のPCEとして、およびオプションでそのパス計算機能（多様なパス計算とバックアップパス計算）を発見します。
We distinguish two levels of PCE information to be disclosed by a PCE discovery mechanism:
PCE発見メカニズムによって開示される2つのレベルのPCE情報を区別します。
- General information. Disclosure MUST be supported by the PCE discovery mechanism. - Detailed information. Disclosure MAY be supported by the PCE discovery mechanism.
- 一般情報。開示は、PCE発見メカニズムによってサポートされなければなりません。- 詳細な情報。開示は、PCE発見メカニズムによってサポートされる場合があります。
The PCE discovery mechanism MUST allow disclosure of general PCE information that will allow PCCs to select appropriate PCEs. This comprises discovery of PCE location, PCE domains supported by the PCEs, and PCE inter-domain functions.
PCE発見メカニズムは、PCCが適切なPCEを選択できるようにする一般的なPCE情報の開示を許可する必要があります。これは、PCEの位置の発見、PCESでサポートされているPCEドメイン、およびPCE領域間関数で構成されています。
The PCE discovery mechanism MAY also allow disclosure of detailed PCE information. This comprises any or all information about PCE path computation capabilities and alternate PCEs. This information is not part of PCE discovery; this is additional information that can facilitate the selection of a PCE by a PCC. Support of the exchange of this information is optional in the context of the PCE discovery mechanism itself. This does not mean that the availability of this information is optional in the PCE-based architecture, but such information could also be obtained by other mechanisms, such as the PCC-PCE communication protocol.
PCE発見メカニズムは、詳細なPCE情報の開示を可能にする場合があります。これは、PCEパス計算機能と代替PCEに関するいずれかまたはすべての情報を含む。この情報はPCE発見の一部ではありません。これは、PCCによるPCEの選択を促進できる追加情報です。この情報の交換のサポートは、PCE発見メカニズム自体のコンテキストでオプションです。これは、この情報の可用性がPCEベースのアーキテクチャでオプションであることを意味するものではありませんが、そのような情報は、PCC-PCE通信プロトコルなどの他のメカニズムによっても取得できます。
The PCE discovery mechanism MUST allow the discovery, for a given PCE, of the IPv4 and/or IPv6 address to be used to reach the PCE. This address will typically be an address that is always reachable, if there is any connectivity to the PCE.
PCE発見メカニズムは、IPv4および/またはIPv6アドレスの特定のPCEの発見を使用してPCEに到達することを可能にする必要があります。このアドレスは、通常、PCEへの接続性がある場合、常に到達可能なアドレスになります。
This address will be used by PCCs to communicate with a PCE, through a PCC-PCE communication protocol.
このアドレスは、PCCS通信プロトコルを介してPCCSと通信するためにPCCSによって使用されます。
Inter-domain path computation is a key application of the PCE-based architecture. This can rely on a multiple-PCE path computation, where PCEs in each domain compute a part of the end-to-end path and collaborate with each other to find the end-to-end-path. Inter-domain path computation can also rely on a single-PCE path computation where a PCE has visibility inside multiple domains and can compute an entire end-to-end inter-domain path (that is, a path from the inter-domain TE-LSP head-end to the inter-domain TE-LSP tail end).
ドメイン間パス計算は、PCEベースのアーキテクチャの重要なアプリケーションです。これは、各ドメインのPCEがエンドツーエンドパスの一部を計算し、互いにコラボレーションしてエンドツーエンドパスを見つけることができる複数のPCEパス計算に依存できます。ドメイン間パス計算は、PCEが複数のドメイン内で可視性を持ち、エンドツーエンドのドメイン間パス全体（つまり、ドメイン間TE-からのパス全体を計算できる単一PCEパス計算に依存することもできます。ドメイン間TE-LSPテールエンドへのLSPヘッドエンド）。
Hence, the PCE discovery mechanism MUST allow the discovery of the set of one or more domains where a PCE has visibility and can compute paths. These domains could be identified using a domain identifier: For instance, an IGP area can be identified by the Area ID (OSPF or ISIS), and an AS can be identified by the AS number.
したがって、PCE発見メカニズムは、PCEに視界があり、パスを計算できる1つ以上のドメインのセットの発見を可能にする必要があります。これらのドメインは、ドメイン識別子を使用して識別できます。たとえば、IGP領域は領域ID（OSPFまたはISIS）で識別でき、ASはAS数で識別できます。
Also the PCE discovery mechanism MUST allow discovery of the inter-domain functions of a PCE, i.e., whether a PCE can be used to compute or to take part in the computation of end-to-end paths across domain borders. The inter-domain functions include nonexhaustively: inter-area, inter-AS and inter-layer path computation. Note that these functions are not mutually exclusive.
また、PCE発見メカニズムは、PCEのドメイン間関数の発見を可能にする必要があります。つまり、PCEを使用して、ドメインの境界を越えたエンドツーエンドパスの計算に参加できるかどうかです。ドメイン間関数には、網羅的には、エリア間、AS間、および層間パス計算が含まれます。これらの機能は相互に排他的ではないことに注意してください。
Note that the inter-domain functions are not necessarily inferred from the set of domains where a PCE has visibility. For instance, a PCE may have visibility limited to a single domain, but may be able to take part in the computation of inter-domain paths by collaborating with PCEs in other domains. Conversely, a PCE may have visibility in multiple domains, but the operator may not want the PCE to be used for inter-domain path computations.
ドメイン間関数は、PCEに視界があるドメインのセットから必ずしも推測されるわけではないことに注意してください。たとえば、PCEは単一のドメインに制限されている可能性がありますが、他のドメインのPCEと共同で協力することにより、ドメイン間パスの計算に参加できる場合があります。逆に、PCEは複数のドメインで可視性を持っている可能性がありますが、演算子はPCEをドメイン間パス計算に使用したくない場合があります。
The PCE discovery mechanisms MUST also allow discovery of the set of one or more domains toward which a PCE can compute paths. For instance, in an inter-AS path computation context, there may be several PCEs in an AS, each one responsible for taking part in the computation of inter-AS paths toward a set of one or more destination ASs, and a PCC may have to discover the destination ASs each PCE is responsible for.
PCE発見メカニズムは、PCEがパスを計算できる1つ以上のドメインのセットを発見することもできなければなりません。たとえば、PATH INTER PATH計算コンテキストでは、ASにはいくつかのPCEがある可能性があります。各PCEが責任を負う目的地のお尻を発見する。
In the case where there are several PCEs with distinct capabilities available, a PCC has to select one or more appropriate PCEs.
利用可能な異なる機能を備えたいくつかのPCEがある場合、PCCは1つ以上の適切なPCEを選択する必要があります。
For that purpose, the PCE discovery mechanism MAY support the disclosure of some detailed PCE capabilities.
その目的のために、PCE発見メカニズムは、いくつかの詳細なPCE機能の開示をサポートする場合があります。
For the sake of illustration, this could include the following path-computation-related PCE capabilities:
説明のために、これには、次のパスコンピューション関連のPCE機能が含まれます。
- The link constraints supported: e.g., bandwidth, affinities. - The path constraints supported: maximum IGP/TE cost, maximum hop count. - The objective functions supported: e.g., shortest path, widest path. - The capability to compute multiple correlated paths: e.g., diverse paths, load balanced paths. - The capability to compute bidirectional paths. - The GMPLS-technology-specific constraints supported: e.g., the supported interface switching capabilities, encoding types.
- サポートされているリンクの制約：例えば、帯域幅、親和性。 - サポートされるパスの制約：最大IGP/TEコスト、最大ホップカウント。 - サポートされている目的関数：たとえば、最短パス、最も広いパス。 - 複数の相関パスを計算する機能：たとえば、多様なパス、ロードバランスパス。 - 双方向経路を計算する能力。 - サポートされているGMPLSテクノロジー固有の制約：サポートされているインターフェイススイッチング機能、エンコードタイプ。
And this could also include some specific PCE capabilities:
また、これにはいくつかの特定のPCE機能も含まれます。
- The capability to handle request prioritization. - The maximum size of a request message. - The maximum number of path requests in a request message. - The PCE computation power (static parameters to be used for weighted load balancing of requests).
- リクエストの優先順位付けを処理する機能。 - リクエストメッセージの最大サイズ。 - リクエストメッセージ内のパス要求の最大数。-PCE計算能力（リクエストの加重負荷分散に使用される静的パラメーター）。
Such information regarding PCE capabilities could then be used by a PCC to select an appropriate PCE from a list of candidate PCEs.
そのようなPCE機能に関する情報は、PCCによって使用され、候補PCEのリストから適切なPCEを選択できます。
Note that the exact definition and description of PCE capabilities are out of the scope of this document. It is expected that this will be described in one or more separate documents which may be application specific.
PCE機能の正確な定義と説明は、このドキュメントの範囲外であることに注意してください。これは、アプリケーション固有の1つ以上の個別のドキュメントで説明されることが予想されます。
In the case of a PCE failure, a PCC has to select another PCE, if one is available. It could be useful in various situations for a PCE to indicate a set of one or more alternate PCEs that can be selected in case the given PCE fails.
PCE障害の場合、PCCが利用可能な場合は別のPCEを選択する必要があります。PCEのさまざまな状況では、与えられたPCEが失敗した場合に選択できる1つまたは複数の代替PCEのセットを示すことが役立ちます。
Hence, the PCE discovery mechanism MAY allow the discovery, for a given PCE, of the location of one or more assigned alternate PCEs.
したがって、PCE発見メカニズムにより、特定のPCEの発見が、1つ以上の割り当てられた代替PCEの位置の発見を可能にする場合があります。
The PCE discovery mechanism MAY also allow the discovery, for a given PCE, of the set of one or more PCEs for which it acts as alternate PCE.
PCE発見メカニズムにより、特定のPCEの発見が、代替PCEとして機能する1つ以上のPCEのセットの発見を可能にする場合があります。
The PCE discovery mechanism MUST allow control of the scope of the PCE information disclosure on a per-PCE basis. In other words, it MUST allow control of to which PCC or group of PCCs the information related to a PCE may be disclosed.
PCE発見メカニズムは、PCEごとにPCE情報開示の範囲を制御できるようにする必要があります。言い換えれば、PCCまたはPCCのグループがPCEに関連する情報が開示される可能性があるかを制御できるようにする必要があります。
The choice for the discovery scope of a given PCE MUST include at least the followings settings:
特定のPCEの発見範囲の選択には、少なくとも次の設定を含める必要があります。
- All PCCs in a single IGP area.
- 単一のIGP領域にあるすべてのPCC。
- All PCCs in a set of adjacent IGP areas.
- 隣接するIGP領域のセットのすべてのPCC。
- All PCCs in a single AS.
- すべてのPCCが1つのASになります。
- All PCCs in a set of ASs.
- お尻のセット内のすべてのPCC。
- A set of one or more PCCs in a set of one or more ASs.
- 1つ以上のお尻のセットにある1つ以上のPCCのセット。
In particular, this also implies that the PCE discovery mechanism MUST allow for the discovery of PCE information across IGP areas and across AS boundaries.
特に、これは、PCE発見メカニズムがIGP領域と境界を越えてPCE情報の発見を可能にしなければならないことを意味します。
The discovery scope MUST be configurable on a per PCE basis.
ディスカバリースコープは、PCEごとに構成可能でなければなりません。
It MUST be possible to deactivate PCE discovery on a per PCE basis.
PCEごとにPCE発見を無効にすることが可能である必要があります。
When using a PCE-based approach for inter-AS path computation, a PCC in one AS may need to learn information related to inter-AS capable PCEs located in other ASs. For that purpose, and as pointed out in the previous section, the PCE discovery mechanism MUST allow disclosure of information related to inter-AS-capable PCEs across AS boundaries.
Inter-AS PATH計算にPCEベースのアプローチを使用する場合、PCCは、他のASSにある可能性のあるPCESに関連する情報を学習する必要がある場合があります。その目的のために、そして前のセクションで指摘されているように、PCE発見メカニズムは、境界としての対象となるPCEに関連する情報の開示を許可する必要があります。
Such inter-AS PCE discovery must be carefully controlled. For security and confidentiality reasons, particularly in an inter-provider context, the discovery mechanism MUST allow the discovery scope to be limited to a set of ASs and MUST also provide control of the PCE information to be disclosed across ASs. This is achieved by applying policies (see also Section 4.4). This implies the capability to contain a PCE advertisement to a restricted set of one or more ASs, and to filter and translate any PCE parameter (PCE domains, PCE inter-domain functions, PCE capabilities, etc.) in disclosures that cross AS borders. For the sake of illustration, it may be useful to disclose detailed PCE information (such as detailed capabilities) locally in the PCE's AS but only general information (such as location and supported domains) in other ASs.
このようなPCEの発見間発見は慎重に制御する必要があります。セキュリティおよび機密性の理由、特にプロバイダー間の文脈では、発見メカニズムは、発見範囲を一連のお尻に制限することを可能にし、また、お尻を越えて開示するPCE情報の制御を提供する必要があります。これは、ポリシーを適用することによって達成されます（セクション4.4も参照）。これは、1つ以上のASSの制限されたセットにPCE広告を封じ込める機能を意味し、PCEパラメーター（PCEドメイン、PCEドメイン関数、PCE機能など）を境界と交差する開示に翻訳します。図のために、PCEのASでは、他のASSの一般的な情報（場所やサポートされたドメインなど）のみで詳細なPCE情報（詳細な機能など）を開示すると便利かもしれません。
The PCE discovery mechanism MUST allow a PCC to discover any change in the information related to a PCE that it has previously discovered. This includes changes to both general information (e.g., a change in the PCE domains supported) and detailed information if supported (e.g., a modification of the PCE's capabilities).
PCE発見メカニズムは、PCCが以前に発見したPCEに関連する情報の変更を発見できるようにする必要があります。これには、一般情報（サポートされているPCEドメインの変更など）とサポートされている場合の詳細情報（PCEの機能の変更など）の両方の変更が含まれます。
In addition, the PCE discovery mechanism MUST allow dynamic discovery of new PCEs in a given discovery scope.
さらに、PCE発見メカニズムは、特定の発見範囲で新しいPCEの動的発見を可能にする必要があります。
Note that there is no requirement for real-time detection of these changes; the PCE discovery mechanism SHOULD rather allow discovery of these changes in a range of 60 seconds, and the operator should have the ability to configure the discovery delay.
これらの変更をリアルタイムで検出するための要件はないことに注意してください。PCE発見メカニズムは、むしろ60秒の範囲でこれらの変化の発見を可能にするはずであり、オペレーターは発見遅延を構成する機能を持つ必要があります。
Note that PCE information is relatively static and is expected to be fairly stable and not to change frequently.
PCE情報は比較的静的であり、かなり安定しており、頻繁に変化しないことが期待されていることに注意してください。
The PCE discovery mechanism MUST allow a PCC to discover when a PCE that it has previously discovered is no longer alive or is deactivated. This may help in reducing or avoiding path computation service disruption.
PCE発見メカニズムは、以前に発見したPCEがもはや生きていないか、非アクティブ化されているときにPCCが発見できるようにする必要があります。これは、パス計算サービスの中断を減らすか回避するのに役立ちます。
Note that there is no requirement for real-time detection of PCE failure/deactivation; the PCE discovery mechanism SHOULD rather allow such discovery in a range of 60 seconds, and the operator should have the ability to configure the discovery delay.
PCE障害/非アクティブ化のリアルタイム検出の要件はないことに注意してください。PCE発見メカニズムは、むしろ60秒の範囲でそのような発見を許可するはずであり、オペレーターは発見遅延を構成する機能を持つ必要があります。
The PCE discovery mechanism MUST allow for policies to restrict the discovery scope to a set of authorized domains, to control and restrict the type and nature of the information to be disclosed, and also to filter and translate some information at domains borders. It MUST be possible to apply these policies on a per-PCE basis.
PCE発見メカニズムは、発見範囲を許可されたドメインのセットに制限し、開示される情報の種類と性質を制御および制限し、ドメインの境界で情報をフィルタリングおよび翻訳するためのポリシーを許可する必要があります。これらのポリシーをPCEごとに適用することは可能でなければなりません。
Note that the discovery mechanisms MUST allow disclosing policy information so as to control the disclosure policies at domain boundaries.
発見メカニズムは、ドメイン境界で開示ポリシーを制御するために、ポリシー情報の開示を許可する必要があることに注意してください。
Also, it MUST be possible to apply different policies when disclosing PCE information to different domains.
また、PCE情報を異なるドメインに開示するときに、異なるポリシーを適用することが可能である必要があります。
The five major threats related to PCE discovery mechanisms are
PCE発見メカニズムに関連する5つの主要な脅威は
- impersonation of PCE; - interception of PCE discovery information (sniffing); - falsification of PCE discovery information; - information disclosure to non-authorized PCCs (PCC spoofing); - Denial of Service (DoS) Attacks.
- PCEのなりすまし; - PCE発見情報の傍受（スニッフィング）; - PCE発見情報の改ざん。 - 不正なPCC（PCCスプーフィング）への情報開示; - サービス拒否（DOS）攻撃。
Note that security of the PCE discovery procedures is of particular importance in an inter-AS context, where PCE discovery may increase the vulnerability to attacks and the consequences of these attacks.
PCE発見のセキュリティは、PCEの発見が攻撃に対する脆弱性とこれらの攻撃の結果を高める可能性がある場合において、特に重要であることに注意してください。
Hence, mechanisms MUST be defined to ensure authenticity, integrity, confidentiality, and containment of PCE discovery information:
したがって、真正性、完全性、機密性、およびPCE発見情報の封じ込めを確保するために、メカニズムを定義する必要があります。
- There MUST be a mechanism to authenticate discovery information. - There MUST be a mechanism to verify discovery information integrity. - There MUST be a mechanism to encrypt discovery information. - There MUST be a mechanism to restrict the scope of discovery to a set of authorized PCCs and to filter PCE information disclosed at domain boundaries (as per defined in Section 4.5).
- 発見情報を認証するメカニズムが必要です。 - 発見情報の完全性を検証するメカニズムが必要です。 - 発見情報を暗号化するメカニズムが必要です。 - 発見の範囲を許可されたPCCSのセットに制限し、ドメイン境界で開示されたPCE情報をフィルタリングするメカニズムが必要です（セクション4.5で定義されているように）。
A PCE and PCC MUST be identified by a globally unique ID, which may be, for instance, a combination of AS number and IP address.
PCEとPCCは、たとえば、AS番号とIPアドレスの組み合わせであるグローバルに一意のIDによって識別する必要があります。
Mechanisms MUST be defined in order to limit the impact of a DoS attack on the PCE discovery procedure (e.g., filter out excessive PCE information change and flapping PCEs). Note also that DoS attacks may be either accidental (caused by a misbehaving PCE system) or intentional. As discussed in [RFC4657], such mechanisms may include packet filtering, rate limiting, no promiscuous listening, and where applicable use of private addresses spaces.
PCE発見手順に対するDOS攻撃の影響を制限するために、メカニズムを定義する必要があります（たとえば、過剰なPCE情報の変更と羽ばたきPCESを除外）。また、DOS攻撃は偶発的（不正行為のPCEシステムによって引き起こされる）または意図的なもののいずれかである可能性があることに注意してください。[RFC4657]で説明したように、このようなメカニズムには、パケットフィルタリング、レートの制限、無差別なリスニング、およびプライベートアドレススペースの適用可能な使用が含まれる場合があります。
Also, key consideration MUST be given in terms of how to establish a trust model for PCE discovery. The PCE discovery mechanism MUST explicitly support a specific set of one or more trust models.
また、PCE発見のための信頼モデルを確立する方法に関しては、重要な考慮事項を提供する必要があります。PCE発見メカニズムは、1つ以上の信頼モデルの特定のセットを明示的にサポートする必要があります。
The PCE discovery mechanism MUST be flexible and extensible so as to easily allow for the inclusion of additional PCE information that could be defined in the future.
PCE発見メカニズムは、将来定義できる追加のPCE情報を簡単に含めることができるように、柔軟で拡張可能でなければなりません。
The PCE discovery mechanism MUST be designed to scale well with an increase of any of the following parameters:
PCE発見メカニズムは、次のパラメーターのいずれかを増やすことで十分にスケーリングするように設計する必要があります。
- Number of PCCs discovering a given PCE. - Number of PCEs to be discovered by a given PCC. - Number of domains in the discovery scope.
- 特定のPCEを発見するPCCの数。 - 特定のPCCによって発見されるPCEの数。 - 発見範囲内のドメインの数。
The PCE discovery mechanism MUST NOT have an adverse effect in the performance of other protocols (especially routing and signaling) already operating in the network.
PCE発見メカニズムは、ネットワークで既に動作している他のプロトコル（特にルーティングとシグナル伝達）のパフォーマンスに悪影響を及ぼしてはなりません。
Note that there is no scalability requirement with regards to the amount of information to be exchanged.
交換する情報の量に関して、スケーラビリティ要件はないことに注意してください。
Information disclosed in the PCE discovery mechanism is relatively static. Changes in PCE information may occur as a result of PCE configuration updates, PCE deployment/activation, or PCE deactivation/suppression, and should not occur as a result of the PCE activity itself. Hence, this information is quite stable and will not change frequently.
PCE発見メカニズムで開示されている情報は比較的静的です。PCE情報の変更は、PCE構成の更新、PCE展開/アクティベーション、またはPCEの非アクティブ化/抑制の結果として発生する可能性があり、PCEアクティビティ自体の結果として発生しないでください。したがって、この情報は非常に安定しており、頻繁に変化しません。
This section gives minimum order of magnitude estimates of what the PCE discovery mechanism should support.
このセクションでは、PCE発見メカニズムがサポートすべきものの最小桁の推定値を示します。
- Number of PCCs discovering a given PCE: 1000 - Number of PCEs to be discovered by a given PCC: 100
- 特定のPCEを発見するPCCの数：1000-特定のPCCによって発見されるPCEの数：100
Mechanisms are REQUIRED to manage PCE discovery operations. This includes the configuration of PCE discovery functions and policies, as well as the monitoring of the discovery protocol activity.
PCE発見操作を管理するには、メカニズムが必要です。これには、PCE発見機能とポリシーの構成、および発見プロトコルアクティビティの監視が含まれます。
It MUST be possible to enable and disable the PCE discovery function at a PCC and at a PCE.
PCCおよびPCEでPCE発見機能を有効にして無効にすることができなければなりません。
On the PCC, it MUST be possible for an operator to activate/deactivate automatic PCE discovery. The activation of automatic discovery MUST not prevent static configuration of PCE information that may supplement discovered information.
PCCでは、オペレーターが自動PCE発見をアクティブ化/非アクティブ化することが可能である必要があります。自動発見のアクティブ化は、発見された情報を補足する可能性のあるPCE情報の静的構成を防止してはなりません。
On the PCE, it MUST be possible for an operator to control the application of discovery policies by which the specific PCE is discovered. As described in Section 4.5, this control MUST include the ability to
PCEでは、オペレーターが特定のPCEが発見された発見ポリシーの適用を制御できる必要があります。セクション4.5で説明したように、この制御には
- restrict the discovery scope to a set of authorized domains; - define the type and nature of the information disclosed; - specify the filtering and translation to be applied to the PCE information disclosed at domain borders.
- 発見スコープを認定ドメインのセットに制限します。 - 開示された情報の種類と性質を定義します。 - ドメイン境界で開示されたPCE情報に適用されるフィルタリングと翻訳を指定します。
These configuration options MAY be supported through an implementation-specific local configuration interface, or MAY be supported via a standardised interface (such as a MIB module, as below).
これらの構成オプションは、実装固有のローカル構成インターフェイスを介してサポートされる場合があります。また、標準化されたインターフェイス（以下のようにMIBモジュールなど）を介してサポートされる場合があります。
PCE discovery MIB modules MUST be specified for the control of the function on PCCs and PCEs.
PCCSおよびPCES上の関数を制御するために、PCE Discovery MIBモジュールを指定する必要があります。
The MIB module that will run on PCCs MUST include at least the following:
PCCで実行されるMIBモジュールには、少なくとも以下を含める必要があります。
- A control to disable automatic discovery by the PCC, - The set of known PCEs, - The number of known PCEs, and the number of discovered PCEs.
- PCCによる自動発見を無効にするためのコントロール - 既知のPCEのセット、既知のPCEの数、および発見されたPCEの数。
For each PCE reported in the MIB module, the following information MUST be available:
MIBモジュールで報告されている各PCEについて、次の情報を利用できる必要があります。
- Information advertised by the PCE (i.e., discovered information), - Information locally configured about the PCE, - The time since the PCE was discovered, - The time since any change to the discovered information for the PCE.
- PCE（つまり、発見された情報）によって宣伝されている情報 - PCEについてローカルに構成された情報 - PCEが発見されてから、PCEの発見された情報の変更からの時間。
Note that when a PCE is no longer alive (see Section 4.4), it SHOULD no longer be reported in the PCC MIB module.
PCEが生存していない場合（セクション4.4を参照）、PCC MIBモジュールでは報告されなくなることに注意してください。
The MIB module SHOULD also provide the average and maximum rates of arrival, departure, and modification of PCE discovery to enable effective analysis of the operation of the protocols. Furthermore, the MIB module SHOULD report on the operation of the discovery protocol by counting the number of unacceptable and incomprehensible information exchanges.
MIBモジュールは、プロトコルの動作の効果的な分析を可能にするために、PCE発見の平均および最大の到着率、出発、および変更率も提供する必要があります。さらに、MIBモジュールは、受け入れられない、理解できない情報交換の数をカウントすることにより、ディスカバリープロトコルの操作について報告する必要があります。
The PCC MIB module SHOULD also be used to provide notifications when thresholds (e.g., on the maximum rate of change, on the number of unacceptable messages) are crossed, or when important events occur (e.g., the number of discovered PCEs decreases to zero).
PCC MIBモジュールは、しきい値（例：容認できないメッセージの数）が交差する場合、または重要なイベントが発生した場合（たとえば、発見されたPCEの数がゼロに減少する）場合に通知を提供するために使用する必要があります。。
The MIB module that will run on PCEs MUST include at least
PCESで実行されるMIBモジュールには、少なくとも含まれる必要があります
- a control to disable automatic discovery announcements by the PCE; - information to be advertised by the PCE, although this information MAY be present as read-only; - the discovery policies active on the PCE, although this information MAY be present as read-only.
- PCEによる自動発見の発表を無効にするためのコントロール。 - PCEによって宣伝される情報。ただし、この情報は読み取り専用として存在する場合があります。-PCEでアクティブな発見ポリシー。ただし、この情報は読み取り専用として存在する場合があります。
The MIB module SHOULD also include
MIBモジュールにも含める必要があります
- the time since the last change to the advertised PCE information; - the time since the last change to the advertisement policies; - control of on which interfaces the PCE issues advertisements where this is applicable to the protocol solution selected.
- 宣伝されているPCE情報の最後の変更からの時間。 - 広告ポリシーの最後の変更からの時間。 - 選択したプロトコルソリューションに適用できる場合、PCEが広告を発行するインターフェイスの制御。
Note that a PCE MAY also be configured to discover other PCEs. In this case, it SHOULD operate the MIB module described in Section 4.10.2.1 as well as the module described here.
PCEも他のPCEを発見するように構成されている場合があることに注意してください。この場合、セクション4.10.2.1で説明したMIBモジュールと、ここで説明するモジュールを操作する必要があります。
It MUST be possible to monitor the operation of any PCE discovery protocol. Where an existing protocol is used to support the PCE discovery function, this monitoring SHOULD be achieved using the techniques already defined for that protocol, enhanced by the MIB modules described above. Where those techniques are inadequate, new techniques MUST be developed.
PCEディスカバリープロトコルの動作を監視することは可能である必要があります。既存のプロトコルがPCE発見機能をサポートするために使用される場合、このモニタリングは、上記のMIBモジュールによって強化されたそのプロトコルに対して既に定義されている手法を使用して達成する必要があります。これらのテクニックが不十分な場合、新しいテクニックを開発する必要があります。
Monitoring of the protocol operation demands support for at least the following functions:
プロトコル操作の監視には、少なくとも次の機能のサポートが必要です。
- Correlation of information advertised against information received. - Counts of dropped, corrupt, and rejected information elements. - Detection of 'segmented' networks, that is, the ability to detect and diagnose the failure of a PCE advertisement to reach a PCC.
- 受け取った情報に対して宣伝された情報の相関。 - ドロップ、破損、拒否された情報要素の数。 - 「セグメント化された」ネットワークの検出、つまり、PCC広告がPCCに到達するための失敗を検出および診断する機能。
Frequent changes in PCE information may have a significant impact on PCCs that receive the advertisements, might destabilize the operation of the network by causing the PCCs to swap between PCEs, and might harm the network through excessive advertisement traffic. Hence, it MUST be possible to apply at least the following controls:
PCE情報の頻繁な変更は、広告を受け取るPCCSに大きな影響を与える可能性があり、PCCがPCE間を交換することによりネットワークの動作を不安定にし、過度の広告トラフィックを通じてネットワークに害を及ぼす可能性があります。したがって、少なくとも次のコントロールを適用することが可能である必要があります。
- Configurable limit on the rate of announcement of changed parameters at a PCE. - Control of the impact on PCCs such as through discovery messages rate-limiting. - Configurable control of triggers that cause a PCC to swap to another PCE.
- PCEでの変更されたパラメーターの発表率の構成可能な制限。 - ディスカバリーメッセージレート制限など、PCCへの影響の制御。-PCCを別のPCEに交換するトリガーの構成可能な制御。
This document is a requirement document and hence does not raise by itself any particular security issue.
このドキュメントは要件文書であるため、特定のセキュリティの問題自体を提起しません。
A set of security requirements that MUST be addressed when considering the design and deployment of a PCE discovery mechanism has been identified in Section 4.6.
PCE発見メカニズムの設計と展開を検討する際に対処する必要がある一連のセキュリティ要件が、セクション4.6で特定されています。
We would like to thank, in chronological order, Benoit Fondeviole, Thomas Morin, Emile Stephan, Jean-Philippe Vasseur, Dean Cheng, Adrian Farrel, Renhai Zhang, Mohamed Boucadair, Eric Gray, Igor Bryskin, Dimitri Papadimitriou, Arthi Ayyangar, Andrew Dolganow, Lou Berger, Nabil Bitar, and Kenji Kumaki.
年代順に、Benoit Fondeviole、Thomas Morin、Emile Stephan、Jean-Philippe Vasseur、Dean Cheng、Adrian Farrel、Renhai Zhang、Mohamed Boucadair、Eric Gray、Igor Bryskin、Dimitri Papadimitriou、Arthi Ayyangir、Arthi ayyangir、、ルー・バーガー、ナビル・ビター、ケンジ・クマキ。
Thanks also to Ross Callon, Ted Hardie, Dan Romascanu, Russ Housley and Sam Hartman for their review and constructive discussions during the final stages of publication.
また、出版物の最終段階でのレビューと建設的な議論をしてくれたロス・カロン、テッド・ハーディ、ダン・ロマスカヌ、ラス・ハウズリー、サム・ハートマンにも感謝します。
The following are the authors who contributed to the present document:
以下は、現在の文書に貢献した著者です。
Jean-Louis Le Roux (France Telecom) Paul Mabey (Qwest Communications) Eiji Oki (NTT) Richard Rabbat (Fujitsu) Ting Wo Chung (Bell Canada) Raymond Zhang (BT Infonet)
Jean-Louis Le Roux（France Telecom）Paul Mabey（QWest Communications）Eiji Oki（NTT）Richard Rabbat（Fujitsu）Ting Wo Chung（Bell Canada）Raymond Zhang（BT Infonet）
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
[RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657] Ash、J.、ed。and J.L. Le Roux、ed。、「Path Computation Element（PCE）通信プロトコルジェネリック要件」、RFC 4657、2006年9月。
Contributors' Addresses
貢献者の住所
Paul Mabey Qwest Communications 950 17th Street Denver, CO 80202 USA
Paul Mabey Qwest Communications 950 17th Street Denver、Co 80202 USA
EMail: pmabey@qwest.com
Eiji Oki NTT Midori-cho 3-9-11 Musashino-shi, Tokyo 180-8585 JAPAN
eiji oki ntt midori-cho 3-9-11 Musashino-shi、東京180-8585日本
EMail: oki.eiji@lab.ntt.co.jp
Richard Rabbat
Fujitsu Laboratories of America
1240 East Arques Ave, MS 345
Sunnyvale, CA 94085
USA
EMail: richard@us.fujitsu.com
Ting Wo Chung Bell Canada 181 Bay Street, Suite 350 Toronto, Ontario, M5J 2T3 CANADA
Ting Wo Chung Bell Canada 181 Bay Street、Suite 350 Toronto、Ontario、M5J 2T3 Canada
EMail: ting_wo.chung@bell.ca
Raymond Zhang BT Infonet 2160 E. Grand Ave. El Segundo, CA 90025 USA
Raymond Zhang Bt Infonet 2160 E. Grand Ave. El Segundo、CA 90025 USA
EMail: raymond_zhang@infonet.com
Editor's Address
編集者のアドレス
Jean-Louis Le Roux (Editor) France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE
Jean-Louis Le Roux（編集者）フランスTelecom 2、Avenue Pierre-Marzin 22307 Lannion Cedex France
EMail: jeanlouis.leroux@orange-ft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。