RFC4657 日本語訳
4657 Path Computation Element (PCE) Communication Protocol GenericRequirements. J. Ash, Ed., J.L. Le Roux, Ed.. September 2006. (Format: TXT=45284 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Ash, Ed.
Request for Comments: 4657 AT&T
Category: Informational J.L. Le Roux, Ed.
France Telecom
September 2006
エド、ワーキンググループJ.灰をネットワークでつないでください。コメントのために以下を要求してください。 4657年のAT&Tカテゴリ: エド情報のJ.L.ル・ルー、フランステレコム2006年9月
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)インターネット協会(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の間の協力が望ましいPCEsの間でも通信プロトコルのための一般的な要件を指定します。 その後のドキュメントは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
1. 序論…2 2. このドキュメントで中古のコンベンション…3 3. 用語…3 4. PCE通信プロトコル(PCECP)の概観…4 5. PCE通信プロトコルジェネリック要件…5 5.1. 基本プロトコル要件…5 5.1.1. PCC-PCEとPCE-PCEコミュニケーションの共通点…5 5.1.2. クライアント/サーバコミュニケーション…5 5.1.3. 輸送…5 5.1.4. 経路計算要求…5 5.1.5. 経路計算応答…7 5.1.6. 未定の要求のキャンセル…7 5.1.7. 複数の要求と応答…8 5.1.8. 信頼できる交換処理…8 5.1.9. 交換処理を保証してください…9
Ash & Le Roux Informational [Page 1] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[1ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年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
5.1.10. 優先順位づけを要求してください…10 5.1.11. 求められていない通知…10 5.1.12. 非同期通信…10 5.1.13. コミュニケーションオーバーヘッド最小化…10 5.1.14. 伸展性…11 5.1.15. スケーラビリティ…11 5.1.16. 規制…12 5.1.17. 目的は支持されていた状態で機能します…13 5.2. 展開サポート要件…13 5.2.1. 異なったサービスプロバイダーには、環境を支持してください…13 5.2.2. 方針サポート…14 5.3. Aliveness検出と回復要件…14 5.3.1. Aliveness検出…14 5.3.2. 回復について議定書の中で述べてください…14 5.3.3. LSPコースを変更するのとReoptimization…14 6. セキュリティ問題…15 7. 管理可能性問題…16 8. 貢献者…17 9. 承認…18 10. 参照…19 10.1. 標準の参照…19 10.2. 有益な参照…19
1. Introduction
1. 序論
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]は'合成(共同見つけられている)である'かPCEから'外部であるかもしれない'(リモート)Path Computation Client(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)によって出された経路計算要求に基づく経路を計算するためにネットワークグラフを作動させます。 経路計算要求は計算されるために経路のソースと目的地を含むでしょう、そして、また、計算、およびそれの間に適用されるという1セットの規制は目的関数を含むかもしれません。 PCE応答は計算された経路か失敗した計算の理由を含んでいます。
Ash & Le Roux Informational [Page 2] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[2ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年9月の情報の灰とル・ルー
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 Communicationプロトコル(PCECP)のための1セットの一般的な要件をリストアップします。 アプリケーション決められた一定の要求は、このドキュメントの範囲を超えていて、別々のドキュメントに記述されるでしょう。 例えば、相互領域と相互層のPCEアプリケーションのために[PCECP-INTER-AREA]と[PCECP-INTER-LAYER]でそれぞれアプリケーション特有の通信プロトコル要件を与えます。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「」 これが記録する「5月」、「推薦され」て、「5月のNOT」、および「任意」のコネはRFC2119[RFC2119]で説明されるように解釈しないべきであることですか?
3. Terminology
3. 用語
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.
ドメイン: アドレス管理か経路のコンピュータの責任の一般的な球の中のネットワーク要素のどんな収集。 ドメインに関する例はInteriorゲートウェイプロトコル(IGP)部門、Autonomous Systems(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: 経路計算クライアント: 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.
テッド: 交通Engineering Database。(そのEngineering Databaseはネットワークかネットワークセグメントの情報がPCEで使用したトポロジーとリソースを含みます)。
TE LSP: Traffic Engineering (G)MPLS Label Switched Path.
Te LSP: MPLSがラベルする交通工学(G)は経路を切り換えました。
See [RFC4655] for further definitions of terms.
用語のさらなる定義に関して[RFC4655]を見てください。
Ash & Le Roux Informational [Page 3] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[3ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年9月の情報の灰とル・ルー
4. Overview of PCE Communication Protocol (PCECP)
4. PCE通信プロトコルの概観(PCECP)
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から築き上げられたネットワークグラフを作動させます。 PCECPのための範囲の外にTEDが居住されるメカニズムがあります。
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で説明されるようにさらなる要件(規制として、知られている)の1セットを含むかもしれません。
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]で説明されたすべてのモデルに適切です。
Ash & Le Roux Informational [Page 4] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[4ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年9月の情報の灰とル・ルー
5. PCE Communication Protocol Generic Requirements
5. PCE通信プロトコルジェネリック要件
5.1. Basic Protocol Requirements
5.1. 基本プロトコル要件
5.1.1. Commonality of PCC-PCE and PCE-PCE Communication
5.1.1. PCC-PCEとPCE-PCEコミュニケーションの共通点
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コミュニケーションのためにただ一つのプロトコルを定義しなければなりません。 PCCであると別のPCEから経路を要求するPCEを考えることができます、そして、このドキュメントの残りでは、それらがPCC-PCEかPCE-PCEであることにかかわらず私たちはすべてのコミュニケーションをPCC-PCEと呼びます。
5.1.2. Client-Server Communication
5.1.2. クライアント/サーバコミュニケーション
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 MUSTは、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).
この要求応答モードに加えて、ケースがPCEからPCCまで求められていないコミュニケーションがある(セクション5.1.11を見てください)ところにあります。
5.1.3. Transport
5.1.3. 輸送
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 SHOULDは輻輳制御を支える既存のトランスポート・プロトコルを利用します。 また、このトランスポート・プロトコルは、信頼性などのこのドキュメントの他のセクションのいくつかの要件を満たすのに使用されるかもしれません。 PCECP SHOULD、1つのトランスポート・プロトコルだけには、相互運用性を確実にして、定義されてください。 トランスポート・プロトコルはPCECPによって使用されたメッセージのサイズを制限してはいけません。
5.1.4. Path Computation Requests
5.1.4. 経路計算要求
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セグメントのためのものであり、始めと終わりであることに注意してください。
Ash & Le Roux Informational [Page 5] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[5ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年9月の情報の灰とル・ルー
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つ以上の経路規制の1セットの包含を支持しなければならなくて、含んでいる他は、含んでいるか、または除く要求された帯域幅かリソース(ホップ、親近感など)です。 例えば、LSPセットアップが失敗するなら、PCCは、新しい経路の計算におけるポイントの失敗を除くようPCEに要求するかもしれません。 規制の実際の包含は要求を出すPCCのための選択です。 セクション5.1.16でPCECPが支持しなければならないコア規制のリストを提供します。 規制の仕様はセクション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つの経路の計算、または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.
セクション5.1.17でPCECPが支持しなければならないコア目的関数のリストを提供します。 目的関数の仕様はセクション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.
リクエスタSHOULD、また、業者特有の、または、実験している目的関数か機能的なオプションを選択できてください。 その上、リクエスタに使用中の機能/オプションをカスタマイズさせなければなりません。 すなわち、個々の目的関数に、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.
最短パス選択はメートル法の、または、IGPのメートル法のTE[METRIC]を当てにするかもしれません。 したがって、PCECP要求メッセージで、PCCは、最短パス選択に使用されるために、メートル法のタイプ(IGPかTE)を示すことができなければなりません。 他のメートル法のタイプが将来指定されるかもしれないことに注意してください。
Ash & Le Roux Informational [Page 6] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[6ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年9月の情報の灰とル・ルー
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.
ケースがただ一つの経路が与えられた帯域幅要求に合うことができないところにあるかもしれません、要求に合うように1セットの経路を結合できましたが。 与えられた要求に役立つそのような経路組み合わせは負荷バランスをとることと呼ばれます。 要求メッセージで、PCCは、負荷分散が許容されているかどうかを示すことができなければなりません。 また、それは負荷分散経路グループにおける、経路の最大数、および負荷分散経路グループの最小の経路帯域幅を含まなければなりません。 要求メッセージはばらばらになることの負荷分散グループのメンバーについて度の仕様を許容しなければなりません。
5.1.5. Path Computation Responses
5.1.5. 経路計算応答
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 LSPsはRSVP-TEシグナリングにおける使用のために一度Explicit Route Objectに変えました。 さらに、Explicit Route Objectで言い表すことができることは計算された経路で返すことができなければなりません。 結果の経路が1セットの厳しいかゆるいホップ、または厳しくてゆるいホップのどんな組み合わせでも作られるかもしれないことに注意してください。 そのうえ、ホップには、非単純の抽象的なノードのフォームがあるかもしれません。 厳しいホップ、ゆるいホップ、および抽象的なノードの定義に関して[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 MUSTからの積極的な応答は計算された経路を含んでいます。 積極的なPCECP計算応答は計算された経路の属性の1セットの包含を支持しなければなりません、経路コスト(例えば、累積しているリンク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応答メッセージは負荷分散経路グループの計算された経路のセットの包含を支持しなければなりません、それらのそれぞれの帯域幅と同様に。
5.1.6. Cancellation of Pending Requests
5.1.6. 未定の要求のキャンセル
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
PCC MUST、適切なメッセージを使用することで未定の要求を中止できてください。 例えば、aを送ったA PCCが、もうセットアップしたがっていないので、PCEともう必要性に応答を要求します。
Ash & Le Roux Informational [Page 7] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[7ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年9月の情報の灰とル・ルー
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.
関連サービスは、要求をクリアすることができるように(すなわち、既に始められるなら、計算を止めてください、そして、文脈をクリアしてください)PCEに通知できなければなりません。 また、PCEは何らかの混雑している状態で未定の要求を中止したがっているかもしれません。
5.1.7. Multiple Requests and Responses
5.1.7. 複数の要求と応答
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とPCEsの両方の構成でただ一つのメッセージの中で運ぶことができる要求の数を制限するのは可能であるに違いありません。
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 MUSTは能力についてPCCに知らせます。 最大の許容できるメッセージサイズと1メッセージあたりの要求の最大数をPCE能力広告[PCE-DISC-REQ]のPCE MAYフォーム部分で支持するか、またはここで説明されたプロトコルの一部として情報メッセージを通して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が指定するのは、可能であるに違いありません、1それが支持できる応答メッセージあたりの計算された経路の要求メッセージ、最大の許容できる応答メッセージサイズ、および最大数で。
It MUST be possible to limit the message size by configuration on PCCs and PCEs.
PCCsとPCEsで構成でメッセージサイズを制限するのは可能であるに違いありません。
5.1.8. Reliable Message Exchange
5.1.8. 信頼できる交換処理
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 MUSTは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
いくつかの場合(例えば、リンクの故障の後に)、多くのPCCsが同時に要求をPCEに送るかもしれません、可能性に通じて
Ash & Le Roux Informational [Page 8] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[8ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年9月の情報の灰とル・ルー
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.
PCEsの飽和。 PCECP MUSTは混雑州とレート制限状態のしるしを支持します。 要求率が高過ぎるなら、これは、例えば、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に機能を加えるのが必要であるなら、SHOULDは、選ばれた移送機構、これらの機能における短所に打ち勝つのに、同じ短所をに拠点を置いていて、技術が打ち勝つために他のプロトコルで見いだされたのが可能であるところで再使用します。 選ばれたトランスポート・プロトコルが既にそれを提供するPCECPに機能性を加えてはいけません。
5.1.9. Secure Message Exchange
5.1.9. 安全な交換処理
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がいったん特定されて、認証されると、それには、他のすべてのPCCsと同じ特権があります。
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 SHOULDは、ローカルの方針が明白な経路を提供しないようにPCEで構成されるのを許容します。 これが許容されていないとき、PCCが明白な経路を要求するなら、PCE MUSTは要求しているPCCにエラーメッセージを返します、そして、未定の経路計算要求を捨てなければなりません。
Authorization requirements [RFC3127] include reject capability, reauthorization on demand, support for access rules and filters, and unsolicited disconnect.
[RFC3127]が含む認可要件は能力、オンデマンドの再認可、アクセス規則とフィルタのサポート、および求められていない分離を拒絶します。
Ash & Le Roux Informational [Page 9] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[9ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年9月の情報の灰とル・ルー
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アドレスは、PCCsとPCEsを特定するのに使用されます。 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を見てください。
5.1.10. Request Prioritization
5.1.10. 優先順位づけを要求してください。
The PCECP MUST allow a PCC to specify the priority of a computation request.
PCECP MUSTは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の範囲の外にこの手続きの経緯はあります。
5.1.11. Unsolicited Notifications
5.1.11. 求められていない通知
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 MUSTは求められていないPCEからPCCか、PCCからPCEまでの通知を支持します。 この要件はPCCsとPCEsの間の情報と警戒の求められていないコミュニケーションを容易にします。 セクション5.1.8で指定されるように、信頼できるトランスミッションプロトコルでこれらの通知メッセージを支持しなければなりません。 また、PCECP MAYは求められていない通知メッセージに応答メッセージを支持します。
5.1.12. Asynchronous Communication
5.1.12. 非同期通信
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 MUST NOTは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.
また、応答の注文に対応する要求の注文と異ならせるのも、可能であるに違いありません。 例えば、経路要求メッセージに異なったプライオリティがあるとき(Requirement5.1.10を見てください)、これは起こるかもしれません。 結果の要件は経路計算応答が関連要求にダイレクト相関関係を含まなければならないということです。
5.1.13. Communication Overhead Minimization
5.1.13. コミュニケーションオーバーヘッド最小化
The request and response messages SHOULD be designed so that the communication overhead is minimized. In particular, the overhead per
要求と応答メッセージSHOULD、コミュニケーションオーバーヘッドが最小にされるように、設計されてください。 特にオーバーヘッド
Ash & Le Roux Informational [Page 10] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[10ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年9月の情報の灰とル・ルー
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:
最小にされて計算答えSHOULDに到着するように交換されたバイト数になってください。メッセージSHOULD、最小にされます。 頭上の最小化における他の問題は以下を含んでいます:
- 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)の加工費(計算要求自体を処理するのと異なる)です。
5.1.14. Extensibility
5.1.14. 伸展性
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 MUSTは新しい経路計算規制、多様性タイプ、目的関数、最適化方法、パラメタなどの導入のための方法を提供します、プロトコルにおける主要な変更を必要としないで。
For example, the PCECP MUST be extensible to support various PCE- based applications, such as the following:
例えば、PCECP MUST、以下などの様々な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相互層]
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 MUSTはアプリケーション決められた一定の要求ドキュメントで指定された要件を支持します。 また、より多くのPCEアプリケーションが将来紹介されるとき、PCECP MUSTは拡大を許します。
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 SHOULD、また、現在、PCEワーキンググループのいずれの範囲でも将来のアプリケーションを支持しないのにおいて広げることができてください、例えば、ポイントツーマルチポイント経路計算、マルチホップpseudowire経路計算などのように
Note that application specific requirements are out of the scope of this document and will be addressed in separate requirements documents.
アプリケーション決められた一定の要求がこのドキュメントの範囲の外にあって、別々の要件ドキュメントに記述されることに注意してください。
5.1.15. Scalability
5.1.15. スケーラビリティ
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 MUSTは以下のパラメタのどれかの増加で直線的と少なくとも同じくらい良い井戸をスケーリングします。 挿入句でPCECPが支持するはずであることに関する大きさ見積りに関する最低発注量を与えます(注意: これらはPCEではなく、PCECPに関する要件です):
Ash & Le Roux Informational [Page 11] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[11ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年9月の情報の灰とル・ルー
- 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)とコミュニケートするPCCsの数--PCEsの数は独身のPCC(100)--ドメイン(20)の数--経路の数に従ってメッセージ(10/第2/PCEの平均)を要求するために交信しました--要求(10の2番目の間隔以内の100/第2/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.
経路要求メッセージに経路要求を束ねることができるというメモ、例えば、10PCECPはメッセージ/秒が100の経路要求/2番目に対応するかもしれないよう要求します。
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 MUSTが優雅な方法で混雑を扱うので、ネットワークの残りに過度に影響を与えないで、またそれはPCEが計算を実行する能力をどんなゲートにもしません。
5.1.16. Constraints
5.1.16. 規制
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の一般的な規制: - 帯域幅--親近感包含/除外--リンク、Node、Shared Risk Link Group(SRLG)包含/除外--最大の終わりによるIGPのメートル法(最大のホップカウント)の最大が終わりにTEメートル法で終わる--経路ばらばらになることの度(リンク、ノード、SRLG)
o MPLS-TE specific constraints
- Class-type
- Local protection
- Node protection
- Bandwidth protection
o MPLS-TEの特定の規制--クラスタイプ--地方の保護--ノード保護--帯域幅保護
Ash & Le Roux Informational [Page 12] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[12ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年9月の情報の灰とル・ルー
o GMPLS specific constraints
- Switching type, encoding type
- Link protection type
o GMPLSの特定の規制--タイプをコード化して、タイプを切り換えます--リンク保護タイプ
5.1.17. Objective Functions Supported
5.1.17. 支持された目的関数
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 MUSTは少なくとも以下の"非連動"の機能をサポートします:
- 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 MUSTは少なくとも以下の「連動している」目的関数を支持します:
- 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
- すべてのリンクで集合帯域幅消費を最小にしてください--最も積み込まれたリンクにおける残りの帯域幅を最大にしてください--1セットのさまざまの経路の累積している費用を最小にしてください。
5.2. Deployment Support Requirements
5.2. 展開サポート要件
5.2.1. Support for Different Service Provider Environments
5.2.1. 異なったサービスプロバイダー環境のサポート
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コントロール飛行機環境に適切です。 [RFC4655]で集結され、分配され、単一で、および複数のPCE経路計算の定義を見つけることができます。
Ash & Le Roux Informational [Page 13] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[13ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年9月の情報の灰とル・ルー
5.2.2. Policy Support
5.2.2. 方針サポート
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 MUSTは、方針の使用が要求を受け入れるか、または拒絶するのを許容します。 それは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メッセージは見え透いた方針情報を運ぶことができなければなりません。
5.3. Aliveness Detection & Recovery Requirements
5.3. Aliveness検出と回復要件
5.3.1. Aliveness Detection
5.3.1. Aliveness検出
The PCECP MUST allow a PCC/PCE to
PCECP MUSTは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活性に関する相互的な知識を確実にしなければなりません。
5.3.2. Protocol Recovery
5.3.2. プロトコル回復
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混雑状態)と要求の再同期を支持しなければなりません。 このSHOULD、反復データ転送を最小にするには、アレンジされてください。
5.3.3. LSP Rerouting & Reoptimization
5.3.3. LSPのコースを変更するのとReoptimization
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をアップデートしたのを知ることができないので、新しい経路計算要求にこの情報を含んでいるのは役に立ちます。
Ash & Le Roux Informational [Page 14] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[14ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年9月の情報の灰とル・ルー
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 MAYは、その後の要求を扱うとき与えられた要求でアカウントまで運ばれた失敗指示情報を取るのを選びます。 これはローカルの政策決定で運転されるべきです。
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.
ネットワーク失敗が多くのLSPsに影響を与えるかもしれないことに注意してください。 この場合、多くのPCCsが同時に、要求をPCEに送るでしょう。 PCECP MUSTは適切にそのようなオーバーロード状況を扱います、例えば、突き抜けるように。要求はセクション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を二重帯域幅会計を避けて、問題を妨げながら減少するのを助けるので。
6. Security Considerations
6. セキュリティ問題
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 MUSTとネットワークの中で使用中のテクニックの使用の影響。 ネットワークには新しいインタフェース、プロトコル、および要素があるので、イントラドメインセキュリティは影響を与えられます。 ネットワークのどんなホストも、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
特定の関連性において、マルチドメインネットワークに、PCECPに固有の秘密性のための含意はそうですか? それは必ずそうであるというわけではありません。
Ash & Le Roux Informational [Page 15] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[15ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年9月の情報の灰とル・ルー
the case that a multi-domain PCE solution will compromise security, but solutions MUST examine their impacts in this area.
マルチドメイン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
- PCEsかPCCsにおけるPCE要求か応答--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 MUSTは、詳細に認証、暗号化、および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 MUSTは例えば、PCCの危険を緩和するのを故意にリソース疲労困憊にPCEを追い込むのに複雑な目的を使用することで許容します。
7. Manageability Considerations
7. 管理可能性問題
Manageability of the PCECP MUST address the following considerations:
PCECP MUSTの管理可能性は以下の問題を記述します:
- 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モジュールの必要性--プロトコル(例えば、パートナー失敗検出とOperations政権とMaintenance(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.
適切なMIBモジュールでPCECP操作をモデル化されて、制御しなければなりません。 PCCsとPCEsの間には、種差が別々のMIBモジュールを定義する必要性に通じるほどあります。 統計集会はPCECPの操作の重要な部分を形成するでしょう。 MIBモジュールはオペレータがPCECPの歴史的な相互作用と要求の成功率を測定できる情報を提供しなければなりません。 同様に、PCECPを決定できるオペレータとPCEがロードして、個々のPCCは負荷の不釣り合いな額に責任があるか否かに関係なく、それが重要です。 それはPCECPコミュニケーションに関する統計を記録して、点検するためにMIBモジュールの使用で可能でなければなりません、奇形のメッセージや、権限のないメッセージや、混雑のために捨てられたメッセージなどの問題を含んでいて。
Ash & Le Roux Informational [Page 16] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[16ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年9月の情報の灰とル・ルー
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が要求を送る前と時代にPCEの活性を決定するのを可能にしなければなりません。
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が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 MUSTは混雑州とレート制限状態のしるしを支持します、そして、オペレータがそのような機能を制御するのを許容するかもしれません。
8. Contributors
8. 貢献者
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:
このドキュメントはPCECP要件デザインが共同努力を組にするというPCE作業部会の結果です。 「作者のアドレス」セクションで記載された作者/エディタに加えて、↓これはドキュメントに貢献したデザインチームメンバーです:
Alia K. Atlas Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA EMail: akatlas@alum.mit.edu
アリアK.Atlas Google株式会社1600円形劇場Parkwayカリフォルニア94043マウンテンビュー(米国)はメールされます: akatlas@alum.mit.edu
Arthi Ayyangar Nuova Systems, 2600 San Tomas Expressway Santa Clara, CA 95051 EMail: arthi@nuovasystems.com
サントマス・Expresswayサンタクララ、2600カリフォルニア Arthi Ayyangarヌオーヴァシステム、95051はメールされます: arthi@nuovasystems.com
Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 USA EMail: nabil.bitar@verizon.com
Nabil Bitarベライゾン40の森のRoad MA02145ウォルサム(米国)はメールされます: nabil.bitar@verizon.com
Igor Bryskin Independent Consultant EMail: i_bryskin@yahoo.com
イーゴリのBryskinの独立しているコンサルタントメール: i_bryskin@yahoo.com
Ash & Le Roux Informational [Page 17] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[17ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年9月の情報の灰とル・ルー
Dean Cheng Cisco Systems, Inc. 3700 Cisco Way San Jose CA 95134 USA Phone: 408 527 0677 EMail: dcheng@cisco.com
サンノゼカリフォルニア95134米国が電話をするディーンチェンシスコシステムズInc.3700コクチマス道: 0677年の408 527メール: 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社の庭の空気Tower飯田橋、千代田区、東京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
美土里町の3 9-11テロのEiji Oki NTT武蔵野市、東京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
レイモンドチャンBT INFONETは社2160のE.の壮大なAveを調整します。 カリフォルニア90245エルセガンド(米国)はメールされます: Raymond_zhang@bt.infonet.com
9. Acknowledgements
9. 承認
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のおかげで彼らのレビューと提案における彼らの最も暖かさを広げたがっています。
Ash & Le Roux Informational [Page 18] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[18ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年9月の情報の灰とル・ルー
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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)ベースの構造」、RFC4655、2006年8月。
10.2. Informative References
10.2. 有益な参照
[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.、ベドレン、A.、メルクス、P.、およびT.Telkamp、「a第2MPLS Traffic Engineering(TE)メートル法としてのメートル法のInteriorゲートウェイプロトコル(IGP)の使用」、BCP87、RFC3785(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.、他、「(G) Inter-領域MPLS Traffic EngineeringのためのPCE Communicationプロトコル(PCECP)決められた一定の要求」、ProgressのWork。
[PCECP-INTER-LAYER] Oki, E., et al., "PCC-PCE Communication
Requirements for Inter-Layer Traffic
Engineering", Work in Progress.
[PCECP-INTER-LAYER] Oki、E.、他、「相互層の交通工学のためのPCC-PCEコミュニケーション要件」、ProgressのWork。
[PCECP-INTER-AS] Bitar, N., Zhang, R., Kumaki, K., "Inter-AS
Requirements for the Path Computation Element
Communication Protocol (PCECP)", Work in
Progress.
[PCECP、相互、]、Bitar、N.、チャン、R.、Kumaki、K.、「相互、経路計算要素通信プロトコル(PCECP)のための要件、」 仕事進行中です。
[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.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[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.、セントジョンズ、M.、バークリー、S.、ネルソン、D.、パティル、B.、スティーブンス、M.、B.ヴォルフ、「認証、認可、以下を説明すること」。 「プロトコル評価」、RFC3127、2001年6月。
Ash & Le Roux Informational [Page 19] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[19ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年9月の情報の灰とル・ルー
Authors' Addresses
作者のアドレス
Jerry Ash (Editor) AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA
ジェリー灰の(エディタ)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
Lannion Cedex、大通りピアー-Marzin22307フランスのジャン・ルイル・ルー(エディタ)フランステレコム2
EMail: jeanlouis.leroux@orange-ft.com
メール: jeanlouis.leroux@orange-ft.com
Ash & Le Roux Informational [Page 20] RFC 4657 PCE Communication Protocol Generic Reqmnts September 2006
[20ページ]RFC4657PCE通信プロトコルジェネリックReqmnts2006年9月の情報の灰とル・ルー
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Ash & Le Roux Informational [Page 21]
灰とル・ルーInformationalです。[21ページ]
一覧
スポンサーリンク
