[要約] 要約： RFC 4657は、Path Computation Element (PCE) Communication Protocolの一般的な要件を定義しています。このプロトコルは、ネットワーク内の経路計算エンティティ（PCE）間の通信を可能にするために使用されます。目的： 1. PCE間の通信を効率的かつ信頼性の高い方法で実現するための要件を定義する。 2. 経路計算エンティティ（PCE）の相互運用性を向上させるための共通のプロトコルを提供する。 3. ネットワークの経路計算に関連する情報の交換を容易にするための標準化を促進する。
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
パス計算要素（PCE）通信プロトコルジェネリック要件
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
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アーキテクチャ」ドキュメントで説明されており、Path Computation Clients（PCCS）からPath Computation Elements（PCES）へのパス計算要求を促進します。このドキュメントは、PCCSとPCES間の通信プロトコルの一般的な要件、およびPCES間の協力が望ましい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].
Path Computation Element（PCE）[RFC4655]は、PCHから「複合」（Composite」（COLOCATED）または「外部」（リモート）であるPATH計算クライアント（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.
PCCが発行したパス計算要求に基づいてパスを計算するために、PCEはネットワークグラフで動作します。パス計算要求には、計算するパスのソースと宛先と、計算中に適用する一連の制約が含まれ、目的関数も含まれる場合があります。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].
キーワード「必須」、「必要」、「必須」、「「shall」、「shall」、「obs "of"、 "nove"、 "becommended"、 "may"、 "optional」「この文書では、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）領域、自律システム（ASS）、サービスプロバイダーネットワーク内の複数のASS、または複数のサービスプロバイダーネットワークの複数のASSが含まれます。
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：Path Computationクライアント：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モデルでは、パス計算要求は、PCCによって、複合（共同住宅）または外部（リモート）であるPCEに発行されます。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によって発行されたパス計算要求には、必要なパスの仕様が含まれます。提供される情報には、少なくともパスのソースと宛先が含まれますが、セクション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]で説明されているように、2つの異なるプロトコルが必要であると仮定する理由はありません。このドキュメントでは、単一のプロトコルが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].
[RFC4655]は、PCEの4つのモデル、複合、外部、複数のPCEパス計算、およびPCE間通信を伴う複数のPCEパス計算を説明しています。複合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通信は、Natureによるクライアントサーバーベースです。PCECPは、PCCがパス計算を要求するためにRequestメッセージをPCEに送信することを許可する必要があります。PCCは、パスが計算されたら、PCCを要求するPCCへの応答メッセージで返信する必要があります。
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からPCCへの未承諾通信がある場合があります（セクション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).
Path Computation Requestメッセージには、少なくともソースと宛先を含める必要があります。パス計算要求は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.
パス計算要求メッセージは、要求された帯域幅またはリソース（ホップ、アフィニティなど）を含むがこれらに限定されない、1つ以上のパス制約のセットを含めることをサポートする必要があります。たとえば、PCCは、LSPのセットアップが失敗した場合、新しいパスの計算の障害点を除外するようにPCCを要求する場合があります。制約の実際の包含は、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がパスを計算するときにパス計算要求に制約を処理するために制約を処理するために使用され、「最適な」候補パス（例：最小ホップパス）を選択し、の計算に使用される最適化基準に対応します。1つのパス、または一連のパスの同期計算。非同性化パス計算の場合、これは、たとえば、最も負荷のあるパスリンクのパスコストまたは残留帯域幅になる可能性があります。同期されたパス計算の場合、これは、たとえば、グローバルな帯域幅の消費または最もロードされたネットワークリンクの残留帯域幅になる可能性があります。
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からPCCへの要求に設定するパラメーターがあります。セクション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.
プロトコルは、RSVP-TEシグナル伝達で使用するために明示的なルートオブジェクトに変換されると、MPLSおよびGMPLS LSPに使用するために許容できる明示的なパスを返すことができなければなりません。さらに、明示的なルートオブジェクトで表現できるものはすべて、計算されたパスで返される必要があります。結果のパスは、厳格なホップまたはルーズホップのセット、または厳格なホップとルーズホップの任意の組み合わせで構成されている可能性があることに注意してください。さらに、ホップには、非シンプルな抽象ノードの形式があります。厳密なホップ、ルーズホップ、抽象ノードの定義については、[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は、適切なメッセージを使用して保留中のリクエストをキャンセルできる必要があります。PCCがPCEにリクエストを送信し、たとえば応答を必要としなくなったPCCは、関連するサービスを設定したくないため、リクエストをクリアできることをPCEに通知できる必要があります（つまり、停止します。既に開始されている場合は計算、コンテキストをクリアします）。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.
同じ要求メッセージ内で複数のパス計算要求を送信することが可能である必要があります。そのような要求は、相関している（例えば、ばらばらのパスを要求する）または相関していない（無関係なサービスのパスを要求する）。PCCSの両方の構成によって制限され、単一のメッセージ内で実行できるリクエストの数を制限することができなければなりません。
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.
関連するすべての要求または計算されたパスが1つのメッセージ内に適合できず、一連の相関メッセージに掲載される「継続的な相関」を提供することが可能でなければなりません。
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.
PCCSおよびPCESの構成によってメッセージサイズを制限することが可能である必要があります。
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にリクエストを送信し、PCESの潜在的な飽和につながる場合があります。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は、別のリクエストを行う前に、あるリクエストへの応答を待つ必要はありません。
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] - Inter-AS Intra ProviderおよびAS Inter-Provider Path Computation [PCECP-INTER-AS] - レイヤー間パス計算[PCECP-INTER-層]
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は、Point-to-Multipoint Path Computations、Multi-hop Pseudowire Path Computationなど、PCEワーキンググループの範囲内で現在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).
- PCCSの数（1000/ドメイン） - PCESの数（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が拒絶または障害の理由を決定できるようにするために、PCCが政策上の理由の要求を拒否する場合、PCEが十分な詳細を提供する能力を含める必要があります。たとえば、1つのドメイン（おそらくAS）を提供する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.
Alivension検出メカニズムは、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が更新されたことを知ることができないため、この情報を新しいPATH計算リクエストに含めると便利です。
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.
したがって、PATH計算要求メッセージは、計算がLSPの復元用であるかどうかを示すことを許可する必要があり、以前に計算されたパスの包含と故障した要素のIDをサポートする必要があります。古いパスは、古い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発見プロセスのセキュリティに依存します（[PCE-Disc-Req]を参照）。ドメイン間情報フローの増加は、セキュリティ攻撃に対する脆弱性を高める可能性があり、ドメイン間パスの促進により、これらのセキュリティ攻撃の影響が増加する可能性があります。
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を使用してPCCを意図的にリソースの排出に駆り立てるリスクを軽減する必要があります。
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モジュールを介してモデル化および制御する必要があります。PCCSとPCESの間には、個別のMIBモジュールを定義する必要性につながるのに十分な違いがあります。統計収集は、PCECPの動作の重要な部分を形成します。MIBモジュールは、オペレーターがPCECPの履歴相互作用とリクエストの成功率を決定できるようにする情報を提供する必要があります。同様に、オペレーターがPCECPとPCE負荷を決定できること、および個々のPCCが不均衡な量の負荷の原因であるかどうかを判断できることが重要です。MIBモジュールを使用して、不正なメッセージ、不正なメッセージ、輻輳のために破棄されたメッセージなどの問題など、PCECP通信に関する統計を記録および検査することが可能でなければなりません。
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テクニックは、PCCがリクエストを送信する前とリクエストを送信して応答を受信するまでの期間の両方の両方の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.
また、PCCがPCCSの活性について知ることは、将来のPCEの可能性のある負荷の予測ビューを獲得し、PCEが受信リクエストの処理を放棄できるようにすることも重要です。
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
Alia K. Atlas Google Inc. 1600 Amphitheater Parkway Mountain View、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 Nuova Systems、2600 San Tomas Expressway Santa Clara、CA 95051メール：arthi@nuovasystems.com
Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 USA EMail: nabil.bitar@verizon.com
Nabil Bitar Verizon 40 Sylvan Road Waltham、MA 02145 USAメール：nabil.bitar@verizon.com
Igor Bryskin Independent Consultant EMail: 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
Igor Bryskin Independent Consultant Email：i_bryskin@yahoo.com Dean Cheng Cisco Systems、Inc。3700 Cisco Way San Jose CA 95134 USA電話：408 527 0677電子メール：dcheng@cisco.com
Durga Gangisetti MCI EMail: durga.gangisetti@mci.com
Durga 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
Kenji Kumaki Kddi Corporation Garden Air Tower Iidabashi、Chiyoda-Ku、Tokyo 102-8460、日本電話：3-6678-3103メール：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
eiji oki ntt midori-cho 3-9-11 Musashino-shi、東京180-8585、日本メール：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
Raymond Zhang Bt Infonet Services Corporation 2160 E. Grand Ave. El Segundo、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.
著者は、（アルファベット順の順序で）ルーバーガー、ロスコロン、エイドリアンファレル、トーマスモリン、ディミトリパパディミトリウ、ロバートスパークス、およびJ.P.ヴァスセルのレビューと提案のおかげで、最も暖かく拡張したいと考えています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
[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.
[Metric] Le Faucheur、F.、Uppili、R.、Vedrenne、A.、Merckx、P。、およびT. Telkamp、「2番目の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] Le Roux、J.L.、et al。、「Path Computation Element（PCE）Discoveryの要件」、進行中の作業。
[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] Le Roux、J.L.、et al。、「PCE通信プロトコル（PCECP）A-A-AREA（G）MPLS Traffic Engineeringの特定の要件」、進行中の作業。
[PCECP-INTER-LAYER] Oki, E., et al., "PCC-PCE Communication Requirements for Inter-Layer Traffic Engineering", Work in Progress.
[PCECP-Inter-Layer] Oki、E.、et al。、「層間交通工学の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] Bitar、N.、Zhang、R.、Kumaki、K。、「パス計算要素通信プロトコル（PCECP）の要件間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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「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] Mitton、D.、St.Johns、M.、Barkley、S.、Nelson、D.、Patil、B.、Stevens、M。、およびB. Wolff、「認証、承認、および会計：プロトコル評価"、RFC 3127、2001年6月。
Authors' Addresses
著者のアドレス
Jerry Ash (Editor) AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA
Jerry Ash（編集者）AT＆TルームMT D5-2A01 200ローレルアベニューミドルタウン、ニュージャージー州07748、米国
Phone: (732)-420-4578 EMail: gash@att.com
電話：（732）-420-4578メール：gash@att.com
Jean-Louis Le Roux (Editor) France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex, FRANCE
Jean-Louis Le Roux（編集者）フランスTelecom 2、Avenue Pierre-Marzin 22307 Lannion Cedex、フランス
EMail: jeanlouis.leroux@orange-ft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。