Network Working Group J. Ash, Ed.
Request for Comments: 4657 AT&T
Category: Informational J.L. Le Roux, Ed.
France Telecom
September 2006
Path Computation Element (PCE) Communication Protocol
Generic Requirements
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
抽象
The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol.
PCEモデルは「PCEアーキテクチャ」文書で説明し、経路計算要素（PCEの）へのパス計算クライアント（のPCC）から経路計算要求を容易にしています。この文書は、のPCE間の協力が望ましい、とものPCEの間のPCCとPCEの間の通信プロトコルのための一般的な要件を指定します。以降の文書は、PCE通信プロトコルのアプリケーション固有の要件を指定します。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Terminology .....................................................3
4. Overview of PCE Communication Protocol (PCECP) ..................4
5. PCE Communication Protocol Generic Requirements .................5
5.1. Basic Protocol Requirements ................................5
5.1.1. Commonality of PCC-PCE and PCE-PCE Communication ....5
5.1.2. Client-Server Communication .........................5
5.1.3. Transport ...........................................5
5.1.4. Path Computation Requests ...........................5
5.1.5. Path Computation Responses ..........................7
5.1.6. Cancellation of Pending Requests ....................7
5.1.7. Multiple Requests and Responses .....................8
5.1.8. Reliable Message Exchange ...........................8
5.1.9. Secure Message Exchange .............................9
5.1.10. Request Prioritization ............................10
5.1.11. Unsolicited Notifications .........................10
5.1.12. Asynchronous Communication ........................10
5.1.13. Communication Overhead Minimization ...............10
5.1.14. Extensibility .....................................11
5.1.15. Scalability .......................................11
5.1.16. Constraints .......................................12
5.1.17. Objective Functions Supported .....................13
5.2. Deployment Support Requirements ...........................13
5.2.1. Support for Different Service Provider
Environments .......................................13
5.2.2. Policy Support .....................................14
5.3. Aliveness Detection & Recovery Requirements ...............14
5.3.1. Aliveness Detection ................................14
5.3.2. Protocol Recovery ..................................14
5.3.3. LSP Rerouting & Reoptimization .....................14
6. Security Considerations ........................................15
7. Manageability Considerations ...................................16
8. Contributors ...................................................17
9. Acknowledgements ...............................................18
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
A Path Computation Element (PCE) [RFC4655] supports requests for path computation issued by a Path Computation Client (PCC), which may be 'composite' (co-located) or 'external' (remote) from a PCE. When the PCC is external from the PCE, a request/response communication protocol is required to carry the path computation request and return the response. In order for the PCC and PCE to communicate, the PCC must know the location of the PCE; PCE discovery is described in [PCE-DISC-REQ].
経路計算エレメント（PCE）[RFC4655]はPCEから「複合」（共同設置）または「外部」（リモート）であってもよいパス計算クライアント（PCC）によって発行された経路計算のための要求をサポートします。 PCCは、PCEから外部にある場合、要求/応答通信プロトコルは、経路計算要求を携帯し、応答を返すために必要とされます。通信するPCCとPCEために、PCCは、PCEの位置を知っていなければなりません。 PCEの発見は[PCE-DISC-REQ]に記載されています。
The PCE operates on a network graph in order to compute paths based on the path computation request(s) issued by the PCC(s). The path computation request will include the source and destination of the paths to be computed and a set of constraints to be applied during the computation, and it may also include an objective function. The PCE response includes the computed paths or the reason for a failed computation.
PCEは、PCC（S）によって発行された経路計算リクエスト（単数または複数）に基づいて経路を計算するために、ネットワークグラフ上で動作します。経路計算要求は、送信元と宛先のパス計算すると、計算中に適用される制約のセットが含まれ、それはまた、目的関数を含んでいてもよいです。 PCE応答は、計算パスしたか失敗した計算のための理由を含みます。
This document lists a set of generic requirements for the PCE Communication Protocol (PCECP). Application-specific requirements are beyond the scope of this document, and will be addressed in separate documents. For example, application-specific communication protocol requirements are given in [PCECP-INTER-AREA] and [PCECP-INTER-LAYER] for inter-area and inter-layer PCE applications, respectively.
この文書では、PCE通信プロトコル（PCECP）のための一般的な要件のセットを示しています。アプリケーション固有の要件は、このドキュメントの範囲を超えていて、別の文書で対処されることになります。例えば、それぞれ、相互領域と層間PCEアプリケーション用に、アプリケーション固有の通信プロトコル要件は[PCECP-INTER-AREA]で与えられ、[PCECP-INTER-LAYER]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "MAY NOT", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "ないかもしれない"、および「オプションRFC 2119 [RFC2119]に記載されているように「この文書に解釈されるべきです。
Domain: Any collection of network elements within a common sphere of address management or path computational responsibility. Examples of domains include Interior Gateway Protocol (IGP) areas, Autonomous Systems (ASs), multiple ASs within a service provider network, or multiple ASs across multiple service provider networks.
ドメイン：アドレス管理またはパス計算責任の共通の球内のネットワーク要素の任意のコレクション。ドメインの例は、内部ゲートウェイプロトコル（IGP）領域、自律システム（ASの）、サービスプロバイダネットワーク内の複数のAS、または複数のサービスプロバイダのネットワークを介し複数のASを含みます。
GMPLS: Generalized Multi-Protocol Label Switching
GMPLS：一般マルチプロトコルラベルスイッチング
LSP: MPLS/GMPLS Label Switched Path
LSP：MPLS / GMPLSラベルスイッチパス
LSR: Label Switch Router
LSR：ラベルスイッチルータ
MPLS: Multi-Protocol Label Switching
MPLS：マルチプロトコルラベルスイッチング
PCC: Path Computation Client: Any client application requesting a path computation to be performed by the PCE.
PCC：経路計算クライアント：PCEによって実行される経路計算を要求する任意のクライアントアプリケーション。
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 (see further description in [RFC4655]).
PCE：パス計算要素：エンティティ（コンポーネント、アプリケーション、またはネットワークノード）ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用することが可能である（[RFC4655]でさらに説明を参照）。
TED: Traffic Engineering Database, which contains the topology and resource information of the network or network segment used by a PCE.
TED：PCEが使用しているネットワークやネットワークセグメントのトポロジーおよびリソース情報が含まれているトラフィックエンジニアリングデータベース、。
TE LSP: Traffic Engineering (G)MPLS Label Switched Path.
TE LSP：トラフィックエンジニアリング（G）MPLSラベルスイッチパス。
See [RFC4655] for further definitions of terms.
用語のさらなる定義については、[RFC4655]を参照してください。
In the PCE model, path computation requests are issued by a PCC to a PCE that may be composite (co-located) or external (remote). If the PCC and PCE are not co-located, a request/response communication protocol is required to carry the request and return the response. If the PCC and PCE are co-located, a communication protocol is not required, but implementations may choose to utilize a protocol for exchanges between the components.
PCEモデルでは、経路計算要求は、（リモート）複合体（共位置）でも外付けでもよいがPCEにPCCによって発行されます。 PCCとPCEが同一場所に配置されていない場合、要求/応答通信プロトコルは、要求を携帯し、応答を返すために必要とされます。 PCC及びPCEは、位置共同している場合は、通信プロトコルが必要とされないが、実装は、コンポーネント間の交換のためのプロトコルを利用することを選択することができます。
In order for a PCC and PCE to communicate, the PCC must know the location of the PCE. This can be configured or discovered. The PCE discovery mechanism is out of scope of this document, but requirements are documented in [PCE-DISC-REQ].
PCCとPCE通信するためには、PCCは、PCEの位置を知らなければなりません。これは、構成されたかを発見することができます。 PCE発見メカニズムは、この文書の範囲外であるが、要件は[PCE-DISC-REQ]に記載されています。
The PCE operates on a network graph built from the TED in order to compute paths. The mechanism by which the TED is populated is out of scope for the PCECP.
PCEは、経路を計算するために、TEDから構築されたネットワークグラフ上で動作します。 TEDが移入されるメカニズムはPCECPの範囲外です。
A path computation request issued by the PCC includes a specification of the path(s) needed. The information supplied includes, at a minimum, the source and destination for the paths, but may also include a set of further requirements (known as constraints) as described in Section 5.
PCCによって発行された経路計算要求は、必要に応じパス（S）の仕様を含みます。供給された情報は、最低でも、パスのソースとデスティネーションを含むが、セクション5に記載されているようにも（制約条件として知られている）、さらに要件のセットを含むことができます。
The response from the PCE may be positive in which case it will include the paths that have been computed. If the computation fails or cannot be performed, a negative response is required with an indication of the type of failure.
PCEからの応答は、それが計算されたパスが含まれている場合に正であってもよいです。計算が失敗した場合、または実行できない場合は、否定応答は、故障のタイプの表示で必要とされます。
A request/response protocol is also required for a PCE to communicate path computation requests to another PCE and for that PCE to return the path computation response. As described in [RFC4655], there is no reason to assume that two different protocols are needed, and this document assumes that a single protocol will satisfy all requirements for PCC-PCE and PCE-PCE communication.
要求/応答プロトコルは、他のPCEに経路計算要求を通信するためのPCEと経路計算応答を返すことPCEのために必要とされます。 [RFC4655]に記載されているように、そこに二つの異なるプロトコルが必要とされていることを前提とする理由はなく、この文書は、単一のプロトコルがPCC-PCEとPCE-PCE通信のための全ての要件を満足することを前提としています。
[RFC4655] describes four models of PCE: composite, external, multiple PCE path computation, and multiple PCE path computation with inter-PCE communication. In all cases except the composite PCE model, a PCECP is required. The requirements defined in this document are applicable to all models described in [RFC4655].
PCE間の通信との複合、外部の、複数のPCEの経路計算、および複数のPCEの経路計算：[RFC4655]はPCEの4つのモデルが記載されています。複合PCEモデルを除くすべての場合において、PCECPが必要です。この文書で定義された要件は[RFC4655]で説明したすべてのモデルに適用されます。
A single protocol MUST be defined for PCC-PCE and PCE-PCE communication. A PCE requesting a path from another PCE can be considered a PCC, and in the remainder of this document we refer to all communications as PCC-PCE regardless of whether they are PCC-PCE or PCE-PCE.
単一のプロトコルは、PCC-PCEとPCE-PCEの通信のために定義されなければなりません。別のPCEからのパスを要求するPCEはPCCと考えることができ、この文書の残りでは、我々は関係なく、PCC-PCE又はPCE-PCEであるかどうかのPCC-PCEとしてすべての通信を指します。
PCC-PCE communication is by nature client-server based. The PCECP MUST allow a PCC to send a request message to a PCE to request path computation, and for a PCE to reply with a response message to the requesting PCC once the path has been computed.
PCC-PCE通信は、ベースの自然のクライアント・サーバーです。 PCECPは、PCCは、経路計算を要求するPCEに要求メッセージを送信することができ、及び経路が計算されると、要求PCCに対する応答メッセージで応答するPCEのためにしなければなりません。
In addition to this request-response mode, there are cases where there is unsolicited communication from the PCE to the PCC (see Section 5.1.11).
この要求応答モードに加えて、PCCへのPCEから未承諾通信（セクション5.1.11を参照のこと）がある場合があります。
The PCECP SHOULD utilize an existing transport protocol that supports congestion control. This transport protocol may also be used to satisfy some requirements in other sections of this document, such as reliability. The PCECP SHOULD be defined for one transport protocol only in order to ensure interoperability. The transport protocol MUST NOT limit the size of the message used by the PCECP.
PCECPは、輻輳制御をサポートし、既存のトランスポートプロトコルを利用すべきです。このトランスポート・プロトコルはまた、信頼性など、この文書の他のセクションにいくつかの要件を満たすために使用されてもよいです。 PCECPだけの相互運用性を確保するために、1つのトランスポートプロトコルのために定義する必要があります。トランスポートプロトコルはPCECPによって使用されるメッセージのサイズを制限してはいけません。
The path computation request message MUST include at least the source and destination. Note that the path computation request is for an LSP or LSP segment, and the source and destination supplied are the start and end of the computation being requested (i.e., of the LSP segment).
経路計算要求メッセージは、少なくとも、送信元と宛先を含まなければなりません。経路計算要求がLSPまたはLSPセグメントのためのものであり、供給されたソースと宛先（すなわち、LSPセグメントの）要求される計算の開始と終了であることに留意されたいです。
The path computation request message MUST support the inclusion of a set of one or more path constraints, including but not limited to the requested bandwidth or resources (hops, affinities, etc.) to include/exclude. For example, a PCC may request the PCE to exclude points of failure in the computation of a new path if an LSP setup fails. The actual inclusion of constraints is a choice for the PCC issuing the request. A list of core constraints that must be supported by the PCECP is supplied in Section 5.1.16. Specification of constraints MUST be future-proofed as described in Section 5.1.14.
経路計算要求メッセージは、要求された帯域幅やリソース（ホップ、親和性、等）を包含/除外するために限定されるものではないが一つ以上のパス制約のセットを含めることをサポートしなければなりません。例えば、PCCは、LSPセットアップが失敗した場合、新しい経路の計算に失敗した点を除外するPCEに要求することができます。制約の実際の含有は、要求を発行PCCのための選択です。 PCECPによってサポートされなければならないコアの制約のリストは、セクション5.1.16に供給されています。セクション5.1.14で説明したように、制約の仕様は、将来防音でなければなりません。
The requester MUST be allowed to select from or prefer an advertised list or minimal subset of standard objective functions and functional options. An objective function is used by the PCE to process constraints to a path computation request when it computes a path in order to select the "best" candidate paths (e.g., minimum hop path), and corresponds to the optimization criteria used for the computation of one path, or the synchronized computation of a set of paths. In the case of unsynchronized path computation, this can be, for example, the path cost or the residual bandwidth on the most loaded path link. In the case of synchronized path computation, this can be, for example, the global bandwidth consumption or the residual bandwidth on the most loaded network link.
依頼者から選択するか、広告を出して、リストまたは標準目的関数と機能オプションの最小サブセットを好むために許可する必要があります。目的関数は、それが「最良の」候補経路（例えば、最小ホップ経路）を選択するためにパスを計算するときに経路計算要求に制約を処理するPCEによって使用される、との計算に使用される最適化基準に対応しています一方の経路、または経路のセットの同期化計算。非同期の経路計算の場合、これは、例えば、パスコストまたは最もロードされたパスのリンク上の残余帯域ことができます。同期経路計算の場合、これは、例えば、グローバルな帯域幅の消費や、ほとんどのロードされたネットワークリンク上の残余帯域ことができます。
A list of core objective functions that MUST be supported by the PCECP is supplied in Section 5.1.17. Specification of objective functions MUST be future-proofed as described in Section 5.1.14.
PCECPによってサポートしなければならないコア目的関数のリストは、セクション5.1.17に供給されます。セクション5.1.14で説明したように目的関数の仕様は、将来防音でなければなりません。
The requester SHOULD also be able to select a vendor-specific or experimental objective function or functional option. Furthermore, the requester MUST be allowed to customize the function/options in use. That is, individual objective functions will often have parameters to be set in the request from PCC to PCE. Support for the specification of objective functions and objective parameters is required in the protocol extensibility specified in Section 5.1.14.
依頼者はまた、ベンダー固有または実験の目的関数や機能のオプションを選択できるようにすべきです。さらに、依頼者は、使用中の機能/オプションをカスタマイズすることができなければなりません。それは、個々の目的関数は、多くの場合、パラメータはPCCからPCEへの要求に設定する必要があります、です。目的関数および目的のパラメータの仕様のサポートは、セクション5.1.14に指定されたプロトコルの拡張に必要とされます。
A request message MAY include TE parameters carried by the MPLS/GMPLS LSP setup signaling protocol. Also, it MUST be possible for the PCE to apply additional objective functions. This might include policy-based routing path computation for load balancing instructed by the management plane.
要求メッセージは、MPLS / GMPLS LSPセットアップシグナリングプロトコルによって運ばTEのパラメータを含むことができます。また、追加の目的関数を適用するPCEのために可能でなければなりません。これは、管理プレーンによって指示された負荷分散のためのポリシーベースのルーティング経路計算が含まれる場合があります。
Shortest path selection may rely either on the TE metric or on the IGP metric [METRIC]. Hence the PCECP request message MUST allow the PCC to indicate the metric type (IGP or TE) to be used for shortest path selection. Note that other metric types may be specified in the future.
最短経路の選択は、TEメトリックまたはIGPメトリック[尺度]のいずれかに依存してもよいです。したがってPCECP要求メッセージは、PCCは、最短経路選択に使用されるメトリックタイプ（IGPまたはTE）を示すことができなければなりません。他のメトリックタイプは、将来的に指定することができることに注意してください。
There may be cases where a single path cannot fit a given bandwidth request, while a set of paths could be combined to fit the request. Such path combination to serve a given request is called load-balancing. The request message MUST allow the PCC to indicate if load-balancing is allowed. It MUST also include the maximum number of paths in a load-balancing path group, and the minimum path bandwidth in a load-balancing path group. The request message MUST allow specification of the degree of disjointness of the members of the load-balancing group.
パスのセットを要求に適合するように組み合わせることができるが、単一のパスが指定された帯域幅要求に適合できない場合があってもよいです。指定された要求にサービスを提供するために、このようなパスの組み合わせは、ロードバランシングと呼ばれています。要求メッセージは、ロード・バランシングが許可されている場合はPCCを示すことができなければなりません。また、負荷分散パスグループ内のパスの最大数、および負荷分散パスグループ内の最小のパス帯域を含まなければなりません。要求メッセージは、負荷分散グループのメンバーの互いに素の程度の指定を可能にしなければなりません。
The path computation response message MUST allow the PCE to return various elements including, at least, the computed path(s).
経路計算応答メッセージは、PCEが、少なくとも、計算された経路（単数または複数）を含む様々な要素を返すことができなければなりません。
The protocol MUST be capable of returning any explicit path that would be acceptable for use for MPLS and GMPLS LSPs once converted to an Explicit Route Object for use in RSVP-TE signaling. In addition, anything that can be expressed in an Explicit Route Object MUST be capable of being returned in the computed path. Note that the resultant path(s) may be made up of a set of strict or loose hops, or any combination of strict and loose hops. Moreover, a hop may have the form of a non-simple abstract node. See [RFC3209] for the definition of strict hop, loose hop, and abstract node.
プロトコルは、MPLSとGMPLS LSPのための使用を一度RSVP-TEシグナリングに使用するための明示的経路オブジェクトに変換するために許容されるであろう任意の明示的なパスを返すことができなければなりません。また、明示的経路オブジェクトで表すことができるものは、計算された経路に戻されることができなければなりません。得られたパス（複数可）は、厳密な又はゆるいホップのセット、または厳密とゆるいホップの任意の組み合わせで構成されてもよいことに留意されたいです。また、ホップは、非単純な抽象ノードの形態を有していてもよいです。厳密ホップ、ルーズホップ、及び抽象ノードの定義については[RFC3209]を参照。
A positive response from the PCE MUST include the paths that have been computed. A positive PCECP computation response MUST support the inclusion of a set of attributes of the computed path, such as the path costs (e.g., cumulative link TE metrics and cumulative link IGP metrics) and the computed bandwidth. The latter is useful when a single path cannot serve the requested bandwidth and load balancing is applied.
PCEからの肯定応答が計算されたパスを含まなければなりません。正PCECP計算応答は、パスコスト（例えば、累積リンクTEメトリックおよび累積リンクIGPメトリック）と計算された帯域幅として計算された経路の属性のセットを含めることをサポートしなければなりません。単一パスが要求された帯域幅を提供することはできませんと負荷分散を適用した場合、後者が便利です。
When a path satisfying the constraints cannot be found, or if the computation fails or cannot be performed, a negative response MUST be sent. This response MAY include further details of the reason(s) for the failure and MAY include advice about which constraints might be relaxed to be more likely to achieve a positive result.
制約条件を満たすパスが見つからない場合、計算が失敗した場合、または実行できない場合、又は、否定応答が送信されなければなりません。この応答は、失敗の理由（複数可）の更なる詳細を含むことができ、制約が肯定的な結果を達成する可能性が高いために緩和されるかもしれないアドバイスを含むかもしれません。
The PCECP response message MUST support the inclusion of the set of computed paths of a load-balancing path group, as well as their respective bandwidths.
PCECP応答メッセージは、負荷分散パスグループの計算経路、ならびにそれらのそれぞれの帯域幅の組を含めることをサポートしなければなりません。
A PCC MUST be able to cancel a pending request using an appropriate message. A PCC that has sent a request to a PCE and no longer needs a response, for instance, because it no longer wants to set up the associated service, MUST be able to notify the PCE that it can clear the request (i.e., stop the computation if already started, and clear the context). The PCE may also wish to cancel a pending request because of some congested state.
PCCは、適切なメッセージを使用して、保留中の要求を取り消すことができなければなりません。 PCEに要求を送信し、もはやそれがもはや関連するサービスを設定したいと考えていないので、それは要求をクリアすることができPCEに通知することができなければならない、例えば、応答を必要としているPCCは（すなわち、停止します計算すでに開始、および）コンテキストをクリアした場合。 PCEもあるため、いくつかの輻輳状態の保留中の要求をキャンセルしたいことがあります。
It MUST be possible to send multiple path computation requests within the same request message. Such requests may be correlated (e.g., requesting disjoint paths) or uncorrelated (requesting paths for unrelated services). It MUST be possible to limit by configuration of both PCCs and PCEs the number of requests that can be carried within a single message.
同じ要求メッセージ内の複数の経路計算要求を送信することも可能でなければなりません。そのような要求は、（例えば、ばらばらのパスを要求する）または無相関（無関係なサービスのパスを要求する）相関させることができます。のPCCとのPCEの両方の構成により、単一のメッセージ内で実施することができる要求の数を制限することができなければなりません。
Similarly, it MUST be possible to return multiple computed paths within the same response message, corresponding either to the same request (e.g., multiple suited paths, paths of a load-balancing path group) or to distinct requests, correlated or not, of the same request message or distinct request messages.
同様に、同一の要求（例えば、複数適しパス、ロードバランシングパスグループのパス）または相関かの異なる要求へ、のいずれかに対応する、同じ応答メッセージ内の複数の計算されたパスを返すことが可能でなければなりません同じ要求メッセージまたは個別の要求メッセージ。
It MUST be possible to provide "continuation correlation" where all related requests or computed paths cannot fit within one message and are carried in a sequence of correlated messages.
すべての関連要求または計算されたパスが一つのメッセージ内に収まらないと相関メッセージのシーケンスで運ばれる「継続相関」を提供することができなければなりません。
The PCE MUST inform the PCC of its capabilities. Maximum acceptable message sizes and the maximum number of requests per message supported by a PCE MAY form part of PCE capabilities advertisement [PCE-DISC-REQ] or MAY be exchanged through information messages from the PCE as part of the protocol described here.
PCEは、その機能のPCCに通知しなければなりません。最大許容メッセージサイズとPCEによってサポートされるメッセージあたりの要求の最大数は、PCE機能広告の一部を形成することができる[PCE-DISC-REQ]又はここで説明されたプロトコルの一部として、PCEから情報メッセージを介して交換することができます。
It MUST be possible for a PCC to specify, in the request message, the maximum acceptable response message sizes and the maximum number of computed paths per response message it can support.
PCCは、要求メッセージ、最大許容応答メッセージのサイズと、それがサポートすることができ、応答メッセージあたりの計算されたパスの最大数は、指定することが可能でなければなりません。
It MUST be possible to limit the message size by configuration on PCCs and PCEs.
のPCCとのPCEに設定することにより、メッセージのサイズを制限することが可能でなければなりません。
The PCECP MUST support reliable transmission of PCECP packets. This may form part of the protocol itself or may be achieved by the selection of a suitable transport protocol (see Section 5.1.3).
PCECPはPCECPパケットの信頼性の高い伝送をサポートしなければなりません。これは、プロトコル自体の一部を形成してもよく、または（セクション5.1.3を参照）は、適切なトランスポートプロトコルを選択することによって達成することができます。
In particular, it MUST allow for the detection and recovery of lost messages to occur quickly and not impede the operation of the PCECP.
失われたメッセージの検出と回復が早く起こるとPCECPの操作を妨げないようにするために特に、それは許容しなければなりません。
In some cases (e.g., after link failure), a large number of PCCs may simultaneously send requests to a PCE, leading to a potential saturation of the PCEs. The PCECP MUST support indication of congestion state and rate limitation state. This should enable, for example, a PCE to limit the rate of incoming request messages if the request rate is too high.
いくつかの場合（例えば、リンク障害の後）において、のPCC多数の同時のPCEの潜在的な飽和につながる、PCEに要求を送信することができます。 PCECPは輻輳状態と速度制限状態の表示をサポートしなければなりません。これは、例えば、要求レートが高すぎる場合、着信要求メッセージのレートを制限するためにPCEを有効にする必要があります。
The PCECP or its transport protocol MUST provide the following:
PCECPまたはそのトランスポートプロトコルは、以下を提供する必要があります。
- Detection and report of lost or corrupted messages - Automatic attempts to retransmit lost messages without reference to the application - Handling of out-of-order messages - Handling of duplicate messages - Flow control and back-pressure to enable throttling of requests and responses - Rapid PCECP communication failure detection - Distinction between partner failure and communication channel failure after the PCECP communication is recovered
- 検出および紛失または破損したメッセージのレポート - アプリケーションへの参照せずに失われたメッセージを再送する自動試み - アウトオブオーダーメッセージの処理 - 重複したメッセージの処理 - フロー制御と要求と応答の調整を有効にする背圧 - 急速PCECP通信障害検出 - PCECP通信相手後障害と通信路障害の区別が回収されます
If it is necessary to add functions to PCECP to overcome shortcomings in the chosen transport mechanisms, these functions SHOULD be based on and re-use where possible techniques developed in other protocols to overcome the same shortcomings. Functionality MUST NOT be added to the PCECP where the chosen transport protocol already provides it.
それは選択された輸送機構における欠点を克服するPCECPする機能を追加する必要がある場合、これらの機能は他のプロトコルで開発可能な技術は、同じ欠点を克服し、再利用に基づくべきです。機能が選択されたトランスポートプロトコルが既にそれを提供PCECPに追加してはいけません。
The PCC-PCE communication protocol MUST include provisions to ensure the security of the exchanges between the entities. In particular, it MUST support mechanisms to prevent spoofing (e.g., authentication), snooping (e.g., preservation of confidentiality of information through techniques such as encryption), and Denial of Service (DoS) attacks (e.g., packet filtering, rate limiting, no promiscuous listening). Once a PCC is identified and authenticated, it has the same privileges as all other PCCs.
PCC-PCE通信プロトコルは、エンティティ間の交換のセキュリティを確保するための規定を含まなければなりません。特に、それはありません、なりすまし（例えば、認証）を防止するためのメカニズムをサポートしています（暗号化などの技術により、情報の機密性の例えば、保存を）スヌーピング、およびサービス拒否（DoS）攻撃（例えば、パケットフィルタリング、レート制限、しなければなりません無差別リスニング）。 PCCが識別と認証されると、それは他のすべてのPCCと同じ権限を持っています。
To ensure confidentiality, the PCECP SHOULD allow local policy to be configured on the PCE to not provide explicit path(s). If a PCC requests an explicit path when this is not allowed, the PCE MUST return an error message to the requesting PCC and the pending path computation request MUST be discarded.
機密性を確保するために、PCECPは、ローカルポリシーは、明示的なパス（複数可）を提供しないようにPCEに構成されることを可能にするべきです。 PCCは、明示的なパスを要求した場合、これは許可されていない場合、PCEは、要求PCCにエラーメッセージを返す必要があり、保留中の経路計算要求は破棄されなければなりません。
Authorization requirements [RFC3127] include reject capability, reauthorization on demand, support for access rules and filters, and unsolicited disconnect.
許可要件[RFC3127]は機能、オンデマンドで再認可、アクセスルールとフィルタのサポート、および迷惑切断を拒否しています。
IP addresses are used to identify PCCs and PCEs. Where the PCC-PCE communication takes place entirely within one limited domain, the use of a private address space that is not available to customer systems MAY be used to help protect the information exchange, but other mechanisms MUST also be available.
IPアドレスはのPCCとのPCEを識別するために使用されています。 PCC-PCE通信が1つの限られた領域内に完全に行われる場合には、顧客のシステムに使用できないプライベートアドレス空間を使用すると、情報交換を保護するために使用することができるが、他のメカニズムも利用可能でなければなりません。
These functions may be provided by the transport protocol or directly by the PCECP. See Section 6 for further discussion of security considerations.
これらの機能は、トランスポートプロトコルによって、または直接PCECPによって提供されてもよいです。セキュリティの考慮事項のさらなる議論については、セクション6を参照してください。
The PCECP MUST allow a PCC to specify the priority of a computation request.
PCECPは、PCCは、計算要求の優先順位を指定することができなければなりません。
Implementation of priority-based activity within a PCE is subject to implementation and local policy. This application processing is out of scope of the PCECP.
PCE内の優先順位に基づく活性の実装は、実装およびローカルポリシーの対象となります。このアプリケーション処理はPCECPの範囲外です。
The normal operational mode is for the PCC to make path computation requests to the PCE and for the PCE to respond.
PCCはPCEへとPCEが応答するまでの経路計算要求を行うため、通常の動作モードがあります。
The PCECP MUST support unsolicited notifications from PCE to PCC, or PCC to PCE. This requirement facilitates the unsolicited communication of information and alerts between PCCs and PCEs. As specified in Section 5.1.8, these notification messages must be supported by a reliable transmission protocol. The PCECP MAY also support response messages to the unsolicited notification messages.
PCECPはPCEからPCC、またはPCCへのPCEに任意通知をサポートしなければなりません。この要件は、のPCCとのPCE間の情報およびアラートの迷惑通信を容易にします。セクション5.1.8に規定されているように、これらの通知メッセージは、信頼性の高い伝送プロトコルによってサポートされなければなりません。 PCECPも迷惑通知メッセージに対する応答メッセージをサポートするかもしれません。
The PCC-PCE protocol MUST allow for asynchronous communication. A PCC MUST NOT have to wait for a response to one request before it can make another request.
PCC-PCEプロトコルは、非同期通信を可能にしなければなりません。 PCCは、それが別の要求を行うことができます前に、1つの要求に対する応答を待つために持ってはいけません。
It MUST also be possible to have the order of responses differ from the order of the corresponding requests. This may occur, for instance, when path request messages have different priorities (see Requirement 5.1.10). A consequent requirement is that path computation responses MUST include a direct correlation to the associated request.
また、応答が対応する要求の順序と異なる順序を持つことが可能でなければなりません。これは、経路要求メッセージは、（要件5.1.10を参照）異なる優先度を有する場合、例えば、起こり得ます。結果としての要件は、経路計算応答が関連する要求に直接的な相関関係が含まれなければならないことです。
The request and response messages SHOULD be designed so that the communication overhead is minimized. In particular, the overhead per message SHOULD be minimized, and the number of bytes exchanged to arrive at a computation answer SHOULD be minimized. Other considerations in overhead minimization include the following:
通信オーバーヘッドが最小になるように要求及び応答メッセージが設計されるべきです。具体的には、メッセージごとのオーバヘッドが最小化されるべき、およびバイト数が最小化されるべき計算解答に到達するために交換しました。オーバーヘッドの最小化の他の考慮事項は、次のものがあります。
- the number of background messages used by the protocol or its transport protocol to keep alive any session or association between the PCE and PCC - the processing cost at the PCE (or PCC) associated with request/response messages (as distinct from processing the computation requests themselves)
- 異なるとして計算を処理からの要求/応答メッセージに関連付けられたPCE（又はPCC）で処理コスト（ - プロトコルまたはPCEとPCCとの間のセッションまたは関連付けをキープアライブするためのトランスポートプロトコルによって使用されるバックグラウンドメッセージの数）自分自身を要求
The PCECP MUST provide a way for the introduction of new path computation constraints, diversity types, objective functions, optimization methods and parameters, and so on, without requiring major modifications in the protocol.
PCECPは、プロトコルの主要な変更を必要とせず、これに新しい経路計算の制約、ダイバーシティ種類、目的関数、最適化手法とパラメータの導入のための方法を提供しなければなりません。
For example, the PCECP MUST be extensible to support various PCE-based applications, such as the following:
例えば、PCECPは、次のような種々のPCEベースのアプリケーションをサポートするために拡張可能でなければなりません。
- intra-area path computation - inter-area path computation [PCECP-INTER-AREA] - inter-AS intra provider and inter-AS inter-provider path computation [PCECP-INTER-AS] - inter-layer path computation [PCECP-INTER-LAYER]
- エリア内の経路計算 - エリア間経路計算[PCECP-INTER-AREA] - インターAS内のプロバイダと相互AS間プロバイダ経路計算[PCECP-INTER-AS] - インターレイヤ経路計算[PCECP- INTER-LAYER]
The PCECP MUST support the requirements specified in the application-specific requirements documents. The PCECP MUST also allow extensions as more PCE applications will be introduced in the future.
PCECPは、アプリケーション固有の要件文書で指定された要件をサポートしなければなりません。 PCECPはまた、より多くのPCEのアプリケーションは、将来的に導入されるように拡張を許容しなければなりません。
The PCECP SHOULD also be extensible to support future applications not currently in the scope of the PCE working group, such as, for instance, point-to-multipoint path computations, multi-hop pseudowire path computation, etc.
PCECPはまた、等、例えば、ポイント・ツー・マルチポイントパス計算、マルチホップ疑似回線経路計算、等のない現在PCEワーキンググループの範囲内の将来のアプリケーションをサポートするように拡張可能であるべきです
Note that application specific requirements are out of the scope of this document and will be addressed in separate requirements documents.
アプリケーション固有の要件は、この文書の範囲外であると、個別の要件文書で対処されることに注意してください。
The PCECP MUST scale well, at least as good as linearly, with an increase of any of the following parameters. Minimum order of magnitude estimates of what the PCECP should support are given in parenthesis (note: these are requirements on the PCECP, not on the PCE):
PCECPは、次のパラメータのいずれかの増加とともに、直線と少なくとも同程度の良い、よく比例しなければなりません。 PCECPがサポートすべきかの大きさの推定値の最小次数は括弧内に与えられている（注：これらはないPCEのPCECP上の要件、です）：
- number of PCCs (1000/domain) - number of PCEs (100/domain) - number of PCCs communicating with a single PCE (1000) - number of PCEs communicated to by a single PCC (100) - number of domains (20) - number of path request messages (average of 10/second/PCE) - handling bursts of requests (burst of 100/second/PCE within a 10- second interval).
- のPCCの数（1000 /ドメイン） - のPCEの数（100 /ドメイン） - 単一PCE（1000）と通信するのPCCの数 - 単一PCC（100）によって通信さのPCEの数 - ドメインの数（20） - 経路要求メッセージの数（10 /秒/ PCEの平均） - リクエストの処理バースト（10-秒間隔以内に100 /秒/ PCEのバースト）。
Note that path requests can be bundled in path request messages, for example, 10 PCECP request messages/second may correspond to 100 path requests/second.
例えば、10件のPCECP要求メッセージ/秒、100の経路要求/秒に対応してもよく、その経路要求は経路要求メッセージにバンドルすることができます。
Bursts of requests may arise, for example, after a network outage when multiple recomputations are requested. The PCECP MUST handle the congestion in a graceful way so that it does not unduly impact the rest of the network, and so that it does not gate the ability of the PCE to perform computation.
複数の再計算が要求されたときの要求のバーストは、ネットワーク停止した後、例えば、発生する可能性があります。それが過度にネットワークの残りの部分に影響を与えないようにPCECPは優雅な方法で輻輳を処理する必要があり、それはゲート計算を実行するPCEの能力をしないように。
This section provides a list of generic constraints that MUST be supported by the PCECP. Other constraints may be added to service specific applications as identified by separate application-specific requirements documents. Note that the provisions of Section 5.1.14 mean that new constraints can be added to this list without impacting the protocol to a level that requires major protocol changes.
このセクションでは、PCECPによってサポートしなければならない一般的な制約のリストを提供します。他の制約は、個別のアプリケーション固有の要件文書によって識別される特定のアプリケーションにサービスを提供するために添加することができます。セクション5.1.14の規定は、新たな制約が主要なプロトコルの変更を必要とするレベルにプロトコルに影響を与えずに、このリストに追加することができることを意味していることに注意してください。
The set of supported generic constraints MUST include at least the following:
サポートされる一般的な制約のセットは、少なくとも以下を含める必要があります。
o MPLS-TE and GMPLS generic constraints: - Bandwidth - Affinities inclusion/exclusion - Link, Node, Shared Risk Link Group (SRLG) inclusion/exclusion - Maximum end-to-end IGP metric - Maximum hop count - Maximum end-to-end TE metric - Degree of paths disjointness (Link, Node, SRLG)
O MPLS-TEとGMPLS、一般的な制約： - 帯域幅 - 親和性/除外 - リンク、ノード、共有リスクリンクグループ（SRLG）/除外 - 最大エンドツーエンドのIGPメトリック - 最大ホップ数 - 最大エンドツーエンドTEメトリック - パスの互いに素の学位（リンク、ノード、SRLG）
o MPLS-TE specific constraints - Class-type - Local protection - Node protection - Bandwidth protection
O MPLS-TE固有の制約 - クラス型 - ローカル保護 - ノードの保護 - 帯域幅保護
o GMPLS specific constraints - Switching type, encoding type - Link protection type
O特定の制約をGMPLS - リンク保護タイプ - タイプ、エンコードのタイプを切り替えます
This section provides a list of generic objective functions that MUST be supported by the PCECP. Other objective functions MAY be added to service specific applications as identified by separate application-specific requirements documents. Note that the provisions of Section 5.1.14 mean that new objective functions MAY be added to this list without impacting the protocol.
このセクションでは、PCECPによってサポートしなければならない一般的な目的関数のリストを提供します。その他の目的関数は、個別のアプリケーション固有の要件文書によって識別される特定のアプリケーションにサービスを提供するために添加してもよいです。セクション5.1.14の規定は、新たな目的関数は、プロトコルに影響を与えずに、このリストに追加してもよいことを意味することに注意してください。
The PCECP MUST support at least the following "unsynchronized" functions:
PCECPは、少なくとも以下「非同期化」機能をサポートしなければなりません：
- Minimum cost path with respect to a specified metric (shortest path) - Least loaded path - Maximum available bandwidth path
- 指定されたメトリック（最短経路）に対する最小コスト経路 - 最小ロードされたパス - 最大利用可能な帯域幅パス
Also, the PCECP MUST support at least the following "synchronized" objective functions:
また、PCECPは、少なくとも以下の「同期」の目的関数をサポートする必要があります。
- Minimize aggregate bandwidth consumption on all links - Maximize the residual bandwidth on the most loaded link - Minimize the cumulative cost of a set of diverse paths
- すべてのリンク上の集約帯域幅の消費を最小限に抑える - ほとんどのロードされたリンク上の残留帯域幅を最大化 - 多様なパスのセットの累積コストを最小化
The PCECP must at least support the following environments:
PCECPは、少なくとも以下の環境をサポートする必要があります。
- MPLS-TE and GMPLS networks - Packet and non-packet networks - Centralized and distributed PCE path computation - Single and multiple PCE path computation
- MPLS-TEやGMPLSネットワーク - パケットと非パケットネットワーク - 集中型と分散PCEの経路計算 - 単一および複数のPCEの経路計算
For example, PCECP is possibly applicable to packet networks (e.g., IP networks), non-packet networks (e.g., time-division multiplexed (TDM) transport), and perhaps to multi-layer GMPLS control plane environments. Definitions of centralized, distributed, single, and multiple PCE path computation can be found in [RFC4655].
例えば、PCECPは、パケットネットワーク（例えば、IPネットワーク）、非パケットネットワーク（例えば、時分割多重（TDM）輸送）に、そしておそらく多層GMPLS制御プレーン環境におそらく適用可能です。 、分散、集中単一、および複数のPCEの経路計算の定義は、[RFC4655]に見出すことができます。
The PCECP MUST allow for the use of policies to accept/reject requests. It MUST include the ability for a PCE to supply sufficient detail when it rejects a request for policy reasons to allow the PCC to determine the reason for rejection or failure. For example, filtering could be required for a PCE that serves one domain (perhaps an AS) such that all requests that come from another domain (AS) are rejected. However, specific policy details are left to application-specific PCECP requirements. Actual policies, configuration of policies, and applicability of policies are out of scope.
PCECPは/要求を拒否受け入れる方針の使用を許容しなければなりません。それはPCCが拒絶または失敗の理由を決定することを可能にする政策上の理由から、要求を拒否した場合に十分な詳細を提供するPCEのための能力を含まなければなりません。例えば、フィルタリングは、別のドメイン（AS）から来るすべての要求が拒否されるように、1つのドメインを提供していPCE（おそらくAS）のために必要とされ得ます。しかし、特定のポリシーの詳細は、アプリケーション固有のPCECP要件に委ねられています。実際の政策、方針の設定、およびポリシーの適用は適用範囲外です。
Note that work on supported policy models and the corresponding requirements/implications is being undertaken as a separate work item in the PCE working group.
注サポートされているポリシー・モデルおよび対応する要件/影響についてその作業はPCEのワーキンググループで別の作業項目として行われています。
PCECP messages MUST be able to carry transparent policy information.
PCECPメッセージは透明ポリシー情報を運ぶことができなければなりません。
The PCECP MUST allow a PCC/PCE to
PCECPはへのPCC / PCEを許容しなければなりません
- check the liveliness of the PCC-PCE communication, - rapidly detect PCC-PCE communication failure (indifferently to partner failure or connectivity failure), and - distinguish PCC/PCE node failures from PCC-PCE connectivity failures, after the PCC-PCE communication is recovered.
- 、PCC-PCE通信の活気をチェック - 急速に（無関係に相手障害または接続障害に）PCC-PCE通信障害を検出し、 - PCC-PCE通信後、PCC-PCE接続障害からのPCC / PCEノード障害を区別回収されます。
The aliveness detection mechanism MUST ensure reciprocal knowledge of PCE and PCC liveness.
稼働状態検知機構はPCEとPCC生存性の逆数知識を確保しなければなりません。
In the event of the failure of a sender or of the communication channel, the PCECP, upon recovery, MUST support resynchronization of information (e.g., PCE congestion status) and requests between the sender and the receiver; this SHOULD be arranged so as to minimize repeat data transfer.
送信者または通信チャネルの障害が発生した場合に、PCECPは、回復時に、情報の再同期化（例えば、PCE輻輳状態）と送信側と受信側との間の要求をサポートしなければなりません。リピートデータ転送を最小限にするように、これは配置する必要があります。
If an LSP fails owing to the failure of a link or node that it traverses, a new computation request may be made to a PCE in order to repair the LSP. Since the PCC cannot know that the PCE's TED has been updated to reflect the failure network information, it is useful to include this information in the new path computation request.
LSPは、それが横断するリンクまたはノードの障害により失敗した場合、新しい計算要求は、LSPを修復するために、PCEに対して行うことができます。 PCCは、PCEのTEDが障害ネットワーク情報を反映するように更新されていることを知ることができないので、新しい経路計算要求にこの情報を含めることが有益です。
Also, in order to re-use the resources used by the old LSP, it may be advantageous to indicate the route of the old LSP as part of the new path computation request.
また、古いLSPによって使用されるリソースを再利用するためには、新しい経路計算要求の一部として古いLSPの経路を示すために、有利であり得ます。
Hence the path computation request message MUST allow an indication of whether the computation is for LSP restoration, and it MUST support the inclusion of the previously computed path as well as the identity of the failed element. Note that the old path might only be useful if the old LSP has not yet been torn down. The PCE MAY choose to take failure indication information carried in a given request into account when handling subsequent requests. This should be driven by local policy decision.
したがって経路計算要求メッセージは計算がLSP復元するためのものであるか否かの表示を許可する必要があり、それが以前に計算された経路の包含、並びに失敗要素の識別をサポートしなければなりません。古いLSPがまだ取り壊されていない場合、古いパスが唯一の役に立つかもしれないことに注意してください。 PCEは、後続の要求を処理する際に考慮に与えられた要求で運ば失敗指示情報を取ることを選ぶかもしれません。これは、ローカルの政策決定によって駆動されなければなりません。
Note that a network failure may impact a large number of LSPs. In this case, a potentially large number of PCCs will simultaneously send requests to the PCE. The PCECP MUST properly handle such overload situations, such as, for instance, through throttling of requests as set forth in Section 5.1.8.
ネットワーク障害がLSPの多数に影響を与えるかもしれないことに留意されたいです。この場合、のPCCの潜在的に大きな数を同時にPCEに要求を送信します。 PCECPは適切な、例えば、セクション5.1.8に記載された要求のスロットリングによるこのような過負荷状況を、処理する必要があります。
The path computation request message MUST support TE LSP path reoptimization and the inclusion of a previously computed path. This will help ensure optimal routing of a reoptimized path, since it will allow the PCE to avoid double bandwidth accounting and help reduce blocking issues.
経路計算要求メッセージは、TE LSPパス再最適化と以前に計算された経路を含めることをサポートしなければなりません。それは二重の帯域幅の会計処理を回避し、ブロッキングの問題を軽減するためにPCEをできるようになりますので、これは、再最適化パスの最適なルーティングを確保するのに役立ちます。
Key management MUST be provided by the PCECP to provide for the authenticity and integrity of PCECP messages. This will allow protecting against PCE or PCC impersonation and also against message content falsification.
鍵管理はPCECPメッセージの信憑性と整合性を提供するためにPCECPによって提供されなければなりません。これは、PCEまたはPCCなりすましに対してもメッセージ内容の改ざんから保護できるようになります。
The impact of the use of a PCECP MUST be considered in light of the impact that it has on the security of the existing routing and signaling protocols and techniques in use within the network. Intra-domain security is impacted since there is a new interface, protocol, and element in the network. Any host in the network could impersonate a PCC and receive detailed information on network paths. Any host could also impersonate a PCE, both gathering information about the network before passing the request on to a real PCE and spoofing responses. Some protection here depends on the security of the PCE discovery process (see [PCE-DISC-REQ]). An increase in inter-domain information flows may increase the vulnerability to security attacks, and the facilitation of inter-domain paths may increase the impact of these security attacks.
PCECPの使用の影響は、それがネットワーク内で使用中のルーティングを既存のシグナリングプロトコルおよび技術のセキュリティに与える影響の観点で考慮されなければなりません。新しいインタフェース、プロトコル、およびネットワーク内の要素があるので、ドメイン内のセキュリティが影響を受けています。ネットワーク内の任意のホストは、PCCを偽装し、ネットワーク経路の詳細情報を受信することができます。任意のホストは、両方が本当のPCEやなりすまし応答に上の要求を渡す前に、ネットワークに関する情報を収集し、PCEになりすますことができます。ここではいくつかの保護は（[PCE-DISC-REQ]を参照）PCEの発見プロセスのセキュリティに依存します。ドメイン間の情報の流れの増加は、セキュリティ攻撃に対する脆弱性を増大させることができる、およびドメイン間経路の促進は、これらのセキュリティ攻撃の影響を増大させることができます。
Of particular relevance are the implications for confidentiality inherent in a PCECP for multi-domain networks. It is not necessarily the case that a multi-domain PCE solution will compromise security, but solutions MUST examine their impacts in this area.
特に関連するのは、マルチドメインネットワークのためのPCECPに固有の機密保持のための含意があります。これは、マルチドメインPCEソリューションは、セキュリティを侵害することを必ずしもそうではありませんが、解決策は、この領域にその影響を調べる必要があります。
Applicability statements for particular combinations of signaling, routing, and path computation techniques are expected to contain detailed security sections.
シグナリング、ルーティング、および経路計算技術の特定の組み合わせのための適用性ステートメントは詳細なセキュリティセクションを含むことが期待されます。
It should be observed that the use of an external PCE introduces additional security issues. Most notable among these are the following:
外部のPCEの使用は、追加のセキュリティ問題を紹介することが観察されるべきです。これらの中で最も注目すべきは次のとおりです。
- Interception of PCE requests or responses - Impersonation of PCE or PCC - DoS attacks on PCEs or PCCs
- PCE要求や応答の傍受 - PCEのなりすましやPCC - PCEのかのPCCのDoS攻撃
The PCECP MUST address these issues in detail using authentication, encryption, and DoS protection techniques. See also Section 5.1.9.
PCECPは、認証、暗号化、およびDoSの保護技術を用いて詳細にこれらの問題に対処しなければなりません。また、セクション5.1.9を参照してください。
There are security implications of allowing arbitrary objective functions, as discussed in Section 5.1.17, and the PCECP MUST allow mitigating the risk of, for example, a PCC using complex objectives to intentionally drive a PCE into resource exhaustion.
そこセクション5.1.17で説明したように、任意の目的関数を可能にするセキュリティ上の影響があり、PCECPは、リスクを軽減できるようにしなければならない、例えば、複雑な目標を使用してPCCを意図的リソースの枯渇にPCEを駆動します。
Manageability of the PCECP MUST address the following considerations:
PCECPの管理性は、次の考慮事項に対処する必要があります：
- The need for a MIB module for control and monitoring of PCECP - The need for built-in diagnostic tools to test the operation of the protocol (e.g., partner failure detection, Operations Administration and Maintenance (OAM), etc.) - Configuration implications for the protocol
- PCECPの制御と監視のためのMIBモジュールの必要性 - コンフィギュレーションへの影響 - 内蔵の診断ツールプロトコル（例えば、パートナーの障害検出など運用管理および保守（OAM）、）の動作をテストするための必要性プロトコルのための
PCECP operations MUST be modeled and controlled through appropriate MIB modules. There are enough specific differences between PCCs and PCEs to lead to the need of defining separate MIB modules. Statistics gathering will form an important part of the operation of the PCECP. The MIB modules MUST provide information that will allow an operator to determine PCECP historical interactions and the success rate of requests. Similarly, it is important for an operator to be able to determine PCECP and PCE load and whether an individual PCC is responsible for a disproportionate amount of the load. It MUST be possible, through use of MIB modules, to record and inspect statistics about the PCECP communications, including issues such as malformed messages, unauthorized messages, and messages discarded owing to congestion.
PCECP操作をモデル化し、適切なMIBモジュールを介して制御されなければなりません。別のMIBモジュールを定義する必要性につながるのPCCとPCEの間に十分な具体的な違いがあります。統計の収集は、PCECPの操作の重要な部分を形成することになります。 MIBモジュールはPCECP歴史的相互作用を決定するために、オペレータとリクエストの成功率を可能にする情報を提供しなければなりません。同様に、オペレータはPCECPとPCE負荷を決定し、個々のPCCは、負荷の不均衡な量の原因であるかどうかをできるようにするために重要です。それは、このような不正なメッセージ、不正なメッセージ、および混雑のために破棄されたメッセージなどの問題を含めPCECP通信に関する統計情報を記録し、検査する、MIBモジュールを使用して、可能でなければなりません。
The new MIB modules should also be used to provide notifications (traps) when thresholds are crossed or when important events occur. For example, the MIB module may support indication of exceeding the congestion state threshold or rate limitation state.
新しいMIBモジュールはまた、しきい値を超えた場合、または重要なイベントが発生したときに通知（トラップ）を提供するために使用する必要があります。例えば、MIBモジュールは、輻輳状態閾値または速度制限状態を超える表示をサポートしてもよいです。
PCECP techniques must enable a PCC to determine the liveness of a PCE both before it sends a request and in the period between sending a request and receiving a response.
PCECP技術は、それが要求を送信する前に、要求を送信し、応答を受信するまでの期間の両方PCEの生存性を決定するために、PCCを有効にする必要があります。
It is also important for a PCE to know about the liveness of PCCs to gain a predictive view of the likely loading of a PCE in the future and to allow a PCE to abandon processing of a received request.
PCEは、将来的にPCEの可能性の高いロードの予測ビューを獲得し、PCEは、受信した要求の処理を放棄することを可能にするためのPCCの生存性について知ることも重要です。
The PCECP MUST support indication of congestion state and rate limitation state, and MAY allow the operator to control such a function.
PCECPは輻輳状態と速度制限状態の表示をサポートしなければなりません、そして、オペレータは、このような機能を制御することを可能にし得ます。
This document is the result of the PCE Working Group PCECP requirements design team joint effort. In addition to the authors/editors listed in the "Authors' Addresses" section, the following are the design team members who contributed to the document:
この文書では、PCEワーキンググループPCECP要件の設計チームの共同の努力の結果です。 「著者のアドレス」欄に記載されている著者/編集者に加えて、以下の文書に貢献し、設計チームのメンバーは以下のとおりです。
Alia K. Atlas Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA EMail: akatlas@alum.mit.edu
アリアK.アトラスグーグル株式会社1600アンフィシアターパークウェイマウンテンビュー、CA 94043 USA電子メール：akatlas@alum.mit.edu
Arthi Ayyangar Nuova Systems, 2600 San Tomas Expressway Santa Clara, CA 95051 EMail: arthi@nuovasystems.com
Arthi Ayyangarヌオーヴァシステムズ、2600年サントーマス高速道路サンタクララ、CA 95051 Eメール：arthi@nuovasystems.com
Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 USA EMail: nabil.bitar@verizon.com
ナビル・ビタールベライゾン40シルバンロードウォルサム、MA 02145 USA電子メール：nabil.bitar@verizon.com
Igor Bryskin Independent Consultant EMail: i_bryskin@yahoo.com
イゴールBryskin独立コンサルタント電子メール：i_bryskin@yahoo.com
Dean Cheng Cisco Systems, Inc. 3700 Cisco Way San Jose CA 95134 USA Phone: 408 527 0677 EMail: dcheng@cisco.com
ディーン・チェンシスコシステムズ株式会社3700シスコウェイサンノゼCA 95134 USA電話：408 527 0677 Eメール：dcheng@cisco.com
Durga Gangisetti MCI EMail: durga.gangisetti@mci.com
ドゥルガーGangisetti MCIメールアドレス：durga.gangisetti@mci.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN Phone: 3-6678-3103 EMail: ke-kumaki@kddi.com
健二熊木KDDI株式会社ガーデンエアタワー飯田橋、東京都千代田区102-8460、JAPAN電話：3-6678-3103 Eメール：ke-kumaki@kddi.com
Eiji Oki NTT Midori-cho 3-9-11 Musashino-shi, Tokyo 180-8585, JAPAN EMail: oki.eiji@lab.ntt.co.jp
えいじ おき んっｔ みどりーちょ ３ー９ー１１ むさしのーし、 ときょ １８０ー８５８５、 じゃぱん えまいｌ： おき。えいじ＠ぁｂ。んっｔ。こ。ｊｐ
Raymond Zhang BT INFONET Services Corporation 2160 E. Grand Ave. El Segundo, CA 90245 USA EMail: Raymond_zhang@bt.infonet.com
レイモンド・チャンBTインフォネット・サービス株式会社2160 E.グランドアベニューエル・セグンド、CA 90245 USA電子メール：Raymond_zhang@bt.infonet.com
The authors would like to extend their warmest thanks to (in alphabetical order) Lou Berger, Ross Callon, Adrian Farrel, Thomas Morin, Dimitri Papadimitriou, Robert Sparks, and J.P. Vasseur for their review and suggestions.
作者は彼らのレビューと提案のためのルー・バーガー、ロスCallon、エードリアンファレル、トーマス・モラン、ディミトリPapadimitriou、ロバートスパークス、およびJ.P. Vasseur（アルファベット順）への暖かい感謝を拡張したいと思います。
[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月。
[METRIC] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP 87, RFC 3785, May 2004.
[尺度]ルFaucheur、F.、Uppili、R.、Vedrenne、A.、メルクス、P.、およびT. Telkamp、 "第二のMPLSトラフィックエンジニアリング（TE）メトリックとしてインテリアゲートウェイプロトコル（IGP）メトリックの使用" 、BCP 87、RFC 3785、2004年5月。
[PCE-DISC-REQ] Le Roux, J.L., et al., "Requirements for Path Computation Element (PCE) Discovery", Work in Progress.
[PCE-DISC-REQ]ルルー、J.L.ら、 "パス計算要素（PCE）の発見のための要件"、ProgressのWork。
[PCECP-INTER-AREA] Le Roux, J.L., et al., "PCE Communication Protocol (PCECP) specific requirements for Inter-Area (G)MPLS Traffic Engineering", Work in Progress.
[PCECP-INTER-AREA]ルルー、J.L.ら、 "PCE通信プロトコル（PCECP）エリア間（G）MPLSトラフィックエンジニアリングのための特定の要件"、ProgressのWork。
[PCECP-INTER-LAYER] Oki, E., et al., "PCC-PCE Communication Requirements for Inter-Layer Traffic Engineering", Work in Progress.
[PCECP-INTER-LAYER]沖、E.、ら、 "レイヤ間トラフィックエンジニアリングのためのPCC-PCE通信の要件"、進行中の作業。
[PCECP-INTER-AS] Bitar, N., Zhang, R., Kumaki, K., "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", Work in Progress.
[PCECP-INTER-AS]が進行中で働いてビタール、N.、張、R.、熊木、K.、 "パス計算要素通信プロトコル（PCECP）のためのInter-ASの要件"。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3127] Mitton, D., St.Johns, M., Barkley, S., Nelson, D., Patil, B., Stevens, M., and B. Wolff, "Authentication, Authorization, and Accounting: Protocol Evaluation", RFC 3127, June 2001.
[RFC3127]ミットン、D.、St.Johns、M.、バークリー、S.、ネルソン、D.、パティル、B.、スティーブンス、M.、およびB.ヴォルフ、「認証、認可、およびアカウンティング：プロトコル評価」、RFC 3127、2001年6月。
Authors' Addresses
著者のアドレス
Jerry Ash (Editor) AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA
ジェリー・アッシュ（編集）AT＆TルームMT D5-2A01 200ローレルアベニューミドルタウン、NJ 07748、USA
Phone: (732)-420-4578 EMail: gash@att.com
電話：（732）-420-4578 Eメール：gash@att.com
Jean-Louis Le Roux (Editor) France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex, FRANCE
ジャン=ルイ・ルー（編集）フランステレコム2、大通りピエールMarzin 22307ラニオンセデックス、フランス
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）によって提供されます。