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
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).
著作権（C）インターネット協会（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.
この文書では、パス計算クライアント（PCC）はPCEの選択に関連する特定の情報とともに、動的かつ自動的の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]は、ネットワークグラフに基づいて、TE-LSPの経路を計算し、計算上の制約を適用することが可能なエンティティとして経路計算エレメント（PCE）を定義します。 PCEは、経路計算クライアント（PCC）によって送信された経路計算リクエストを提供しています。
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によって実行される経路計算を要求しているクライアント・アプリケーションです。これは、例えば、LSRは、それがヘッドエンドであるため、TE-LSP、または別の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は、ドメイン間経路計算の場合には、例えば、そのドメイン、また潜在的に他のドメイン内のいくつかの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.
その文脈では、のPCCを自動的PCE選択のために必要な追加情報を決定し、動的に新規のPCEまたは任意の改変を検出するために、のPCEのセットを発見することを可能にする自動および動的PCE発見のための機構を定義することが非常に望ましいであろうPCEの情報の。これは、そのドメイン、および潜在的にいくつかの他のドメイン内の1つのまたは複数のPCEの組の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対応ネットワークとのPCEに経路を計算することが可能であるの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として作用するPCEを包含することに留意することも重要です。したがって、この文書はのPCEによってのPCCとPCEの発見によって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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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エリア境界ルータ（ABR OSPFまたはISIS L1L2ルータ）。
AS: Autonomous System.
AS：自律システム。
ASBR: AS Border Router.
ASBR：境界ルータAS。
Intra-area TE LSP: A TE LSP whose path does not cross IGP area boundaries.
イントラ領域TE LSP：そのパスIGP領域の境界と交差しないTE LSP。
Inter-area TE LSP: A TE LSP whose path transits through two or more IGP areas.
相互領域TE LSP：そのパス複数のIGP領域を介して遷移TE LSP。
Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or more ASs or sub-ASs (BGP confederations).
インターAS MPLS TE LSP：そのパス二つ以上のASまたはサブのAS（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.
- 経路計算負荷は、スケーラビリティを向上させるためのPCEのセットの中バランスをとることができます。 - 冗長性のために、プライマリとバックアップのPCEを使用することができます。 - のPCEは、別個の経路計算機能（マルチ制約経路計算、バックアップ経路計算、等）を有していてもよいです。 - ドメイン間のコンテキストでは、異なるドメイン間の機能（エリア間、インターAS、レイヤ間）、1つ以上のドメインに経路計算を担当する各PCEを持ついくつかのPCEが存在し得ます。
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.
その能力に基づいて適切なPCEを選択して、要求の効率的な負荷分散を行うために、つまり、のPCCによる効果的な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情報は、その機能と一緒のPCEのセットで、各PCCに、手動設定を通じて学習することができます。そのような手動設定のアプローチが十分で、さらにいくつかの特定の状況では、所望の（例えば、インター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.
- これは、実質的なコンフィギュレーションオーバーヘッドを意味してもよいです。 - これは、既存のPCEが使用できなくなったことを、PCCは動的に新しい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パス計算はのPCEとして作用するのABRと、複数のPCEの経路計算に依存している場合、バックボーンエリアはで含むであろう少なくともN個の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が自動的にそのドメインのPCEのうちの1つまたは複数の場所を発見することを可能にしなければなりません。
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.
ドメイン間経路計算が必要とポリシーで許可されている場合、PCE発見方法は、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つまたは複数のドメイン（領域、尻）の集合で発見スコープの制御を可能にしなければなりません。
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は、いくつかのPCEを持つネットワークとして/マルチエリアを示します。
- 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は、AS間の経路計算に参加することができPCEです。それはAS2へのAS1における経路計算を担当しています。 - ASBR R12は、AS間の経路計算に参加することができPCEです。これは、AS1への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).
- として、動的R6を発見するエリア0及び2の各PCC - 領域1,0動的エリア間経路計算用のPCEとして、R3を発見するため、及びR3は、領域0と領域1の経路を計算することができることで各PCCエリア間経路計算用のPCE、およびR6は領域2に経路を計算し、エリア0ことができる - 各AS1におけるPCC及びAS2内の1つの以上のPCCを動的に向かっAS1内のAS間経路計算のためのPCEとしてR9を発見しますAS2。 - AS2とAS1内の1つの以上のPCCにおける各PCC動的AS1向かっAS2におけるAS間の経路計算のためのPCEとしてR12を発見します。 - 領域1の各PCCを動的AREA1でエリア内の経路計算のためのPCEとして、S1を発見するために、そして必要に応じてその経路計算機能（多様な経路計算およびバックアップ経路計算）を発見します。
We distinguish two levels of PCE information to be disclosed by a PCE discovery mechanism:
私たちは、PCE発見メカニズムにより開示される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の位置、のPCEによってサポート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発見メカニズムがPCEに到達するために使用されるIPv4および/またはIPv6アドレスを、所定のPCEのための発見を可能にしなければなりません。 PCEへの接続が存在する場合、このアドレスは、通常、常に到達可能なアドレスになります。
This address will be used by PCCs to communicate with a PCE, through a PCC-PCE communication protocol.
このアドレスはPCC-PCE通信プロトコルを介して、PCEと通信するためのPCCによって使用されるであろう。
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が複数のドメイン内部の視認性を有する単PCEの経路計算に頼ることができると（すなわち、ドメイン間の経路である全体のエンドツーエンドインター - ドメイン経路を計算することができますTE-ドメイン間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またはIS-IS）によって識別することができ、そして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のドメイン間の機能の発見を可能にしなければなりません。ドメイン間の機能はnonexhaustively含む：インターエリア、インター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つまたは複数のドメインのセットの発見を可能にしなければなりません。例えば、インターAS経路計算コンテキストに存在するように、1つ以上の宛先のASの組に向かってAS間の経路の計算に参加する責任それぞれにおけるいくつかのPCEであってもよく、PCCが有していてもよいです各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の機能に関するそのような情報は、次に、候補のPCEのリストから適切なPCEを選択するために、PCCによって使用することができます。
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は1つが利用可能である場合、別の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の位置の所与の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として機能するための1つのまたは複数のPCEのセットの所定の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情報開示の範囲の制御を可能にしなければなりません。換言すれば、PCEに関連する情報が開示されていることができるPCC又はのPCCのグループの制御を可能にしなければなりません。
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.
- 単一AS内のすべてのPCC。
- All PCCs in a set of ASs.
- のASのセットのすべてのPCC。
- A set of one or more PCCs in a set of one or more ASs.
- 一の以上のASのセット内の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情報の発見とASの境界を越えて許可しなければならないことを意味します。
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.
AS間の経路計算のためのPCEベースのアプローチを使用する場合、あるASにおけるPCCは、他のASに位置するインターASできるのPCEに関連する情報を学習する必要があるかもしれません。その目的のために、前節で指摘したように、PCE発見メカニズムは、ASの境界を越えインターAS対応の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.
このようなAS間PCEの発見は、慎重に制御しなければなりません。セキュリティおよび機密性の理由から、特にインタープロバイダ文脈において、発見メカニズムは、検出スコープお尻のセットに限定されることは、またのASを横断開示がPCE情報の制御を提供しなければならない可能にしなければなりません。これは、ポリシーを適用することによって達成される（セクション4.4を参照してください）。これは、1つのまたは複数のASの制限されたセットにPCE広告を含むようにし、フィルタリングし、国境AS交差開示における任意のPCEパラメータ（PCEドメイン、PCEドメイン間機能、PCE機能など）を変換する機能を意味します。説明のために、ローカルPCEのASにのみ一般的な情報の他のお尻の（例えば、位置およびサポートされているドメインとして）（例えば、詳細な機能など）詳細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発見メカニズムに関連した五つの主要な脅威があります
- 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.
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の発見は攻撃とこれらの攻撃の影響に対する脆弱性を増大させることができるAS間のコンテキストで特に重要であることに注意してください。
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).
- 発見の情報を認証するための機構が存在しなければなりません。 - 発見情報の完全性を検証するための機構が存在しなければなりません。 - 発見の情報を暗号化するための機構が存在しなければなりません。 - 認可のPCCのセットに発見の範囲を制限すると（セクション4.5で定義された通り）ドメイン境界において開示PCE情報をフィルタリングする機構が存在しなければなりません。
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は、例えば、とすることができる、グローバルに一意のIDによってAS番号とIPアドレスの組み合わせを特定しなければなりません。
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
メカニズムはPCE発見手順にDoS攻撃の影響を制限するために定義されなければならない（例えば、過度のPCE情報変更と羽ばたきのPCEを除外する）。 DoS攻撃は、偶発（誤動作のPCEシステムによって引き起こされる）、または意図的のいずれであってもよいことにも注意してください。 [RFC4657]で説明したように、そのようなメカニズムは含んでいてもよいです
packet filtering, rate limiting, no promiscuous listening, and where applicable use of private addresses spaces.
パケットフィルタリング、レート制限、無無差別リスニング、どこでプライベートアドレス空間の該当する使用。
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発見メカニズムは、明示的に一つ以上の信頼モデルの特定のセットをサポートしなければなりません。
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.
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.
PCEの発見MIBモジュールはのPCCとのPCEの機能の制御を指定しなければなりません。
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).
（例えば、発見のPCEの数がゼロに減少する）（変化の最大レートで、許容できないメッセージの数の例えば、）閾値が交差している場合、または重要なイベントが発生したときPCC MIBモジュールはまた、通知を提供するために使用されるべき。
The MIB module that will run on PCEs MUST include at least
PCEの上で実行されます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.
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.
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に到達するPCE広告の障害を検出し、診断する能力です。
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の情報が頻繁に変化が広告を受け取るのPCCに重大な影響を有していてもよい、の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への影響をコントロール。 - 他のPCEにスワップするPCCを引き起こすトリガーの設定可能な制御。
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.
私たちは、年代順に、ブノワFondeviole、トーマス・モラン、エミール・ステファン、ジャン=フィリップVasseur、ディーン・チェン、エードリアンファレル、Renhai張、モハメドBoucadair、エリックグレー、イゴールBryskin、ディミトリPapadimitriou、Arthi Ayyangar、アンドリューDolganowに感謝したいと思います、ルー・バーガー、ナビル・ビタール、および健二熊木。
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.
また、ロスCallon、テッドハーディー、ダンRomascanu、ラスHousleyとサム・ハートマンのおかげで彼らのレビューと出版物の最終段階で建設的な議論のために。
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)
ジャン=ルイ・ルー（フランステレコム）ポール・Mabey（クエスト・コミュニケーションズ）大木英司（NTT）リチャード・Rabbat（富士通）チョン臥ティン（ベル・カナダ）レイモンド・チャン（BTインフォネット）
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（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]アッシュ、J.、エド。そしてJ.L.ル・ルー、エド。、 "パス計算要素（PCE）通信プロトコルジェネリック要件"、RFC 4657、2006年9月。
Contributors' Addresses
貢献者のアドレス
Paul Mabey Qwest Communications 950 17th Street Denver, CO 80202 USA
ポールMabeyクエスト・コミュニケーションズ950 17thストリートデンバー、CO 80202 USA
EMail: pmabey@qwest.com
メールアドレス：pmabey@qwest.com
Eiji Oki NTT Midori-cho 3-9-11 Musashino-shi, Tokyo 180-8585 JAPAN
えいじ おき んっｔ みどりーちょ ３ー９ー１１ むさしのーし、 ときょ １８０ー８５８５ じゃぱん
EMail: oki.eiji@lab.ntt.co.jp
メールアドレス：oki.eiji@lab.ntt.co.jp
Richard Rabbat Fujitsu Laboratories of America 1240 East Arques Ave, MS 345 Sunnyvale, CA 94085 USA
アメリカのリチャード・Rabbat富士通研究所1240東アルクアベニュー、MS 345サニーベール、CA 94085 USA
EMail: richard@us.fujitsu.com
メールアドレス：richard@us.fujitsu.com
Ting Wo Chung Bell Canada 181 Bay Street, Suite 350 Toronto, Ontario, M5J 2T3 CANADA
チョンベル・カナダ181ベイストリート臥ティン、スイート350トロント、オンタリオ、M5J 2T3 CANADA
EMail: ting_wo.chung@bell.ca
メールアドレス：ting_wo.chung@bell.ca
Raymond Zhang BT Infonet 2160 E. Grand Ave. El Segundo, CA 90025 USA
レイモンド・チャンBTインフォネット2160 E.グランドアベニューエル・セグンド、CA 90025 USA
EMail: raymond_zhang@infonet.com
メールアドレス：raymond_zhang@infonet.com
Editor's Address
編集者の住所
Jean-Louis Le Roux (Editor) France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE
ジャン=ルイ・ルー（編集）フランステレコム2、大通りピエールMarzin 22307ラニオンセデックスFRANCE
EMail: jeanlouis.leroux@orange-ft.com
メールアドレス：jeanlouis.leroux@orange-ft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。