Network Working Group JL. Le Roux
Request for Comments: 5541 France Telecom
Category: Standards Track JP. Vasseur
Cisco System Inc.
Y. Lee
Huawei
June 2009
Encoding of Objective Functions in the
Path Computation Element Communication Protocol (PCEP)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Abstract
抽象
The computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is subject to a set of one or more specific optimization criteria, referred to as objective functions (e.g., minimum cost path, widest path, etc.).
一方の演算またはトラフィックエンジニアリングラベルのセットは、（（MPLS）は一般化MPLS（GMPLS）ネットワーク一つ以上の特定の最適化基準のセットを受けるマルチプロトコルラベルスイッチングのパス（TE LSPを）スイッチとして目的関数と呼ば例えば、最小コストパス、最も広いパスなど）。
In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) may want a path to be computed for one or more TE LSPs according to a specific objective function. Thus, the PCC needs to instruct the PCE to use the correct objective function. Furthermore, it is possible that not all PCEs support the same set of objective functions; therefore, it is useful for the PCC to be able to automatically discover the set of objective functions supported by each PCE.
経路計算エレメント（PCE）アーキテクチャでは、パス計算クライアント（PCC）は、パスは、特定の目的関数に応じて一の以上のTE LSPのために計算されるようにすることができます。このように、PCCは、正しい目的関数を使用するためのPCEを指示する必要があります。また、全てのPCEは、目的関数の同じセットをサポートすることが可能です。したがって、PCCが自動的に各PCEによってサポートされる目的関数のセットを発見できるようにするために有用です。
This document defines extensions to the PCE communication Protocol (PCEP) to allow a PCE to indicate the set of objective functions it supports. Extensions are also defined so that a PCC can indicate in a path computation request the required objective function, and a PCE can report in a path computation reply the objective function that was used for path computation.
この文書では、PCEが、それがサポートする目的関数のセットを示すことができるようにPCE通信プロトコル（PCEP）への拡張を定義します。経路計算のために使用された目的関数を返信PCCは、経路計算要求に必要な目的関数を示すことができ、及びPCEは、経路計算に報告できるように拡張も定義されています。
This document defines objective function code types for six objective functions previously listed in the PCE requirements work, and provides the definition of four new metric types that apply to a set of synchronized requests.
この文書は、以前PCE要件の仕事に記載されている6つの目的関数のための目的関数のコードタイプを定義し、同期要求のセットに適用される4つの新しいメトリックタイプの定義を提供します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................5
1.2. Terminology ................................................5
1.3. Message Formats ............................................6
2. Discovery of PCE Objective Functions ............................6
2.1. OF-List TLV ................................................6
2.2. Elements of Procedure ......................................7
3. Objective Function in PCEP Path Computation Request and Reply
Messages ........................................................7
3.1. OF Object ..................................................7
3.1.1. Elements of Procedure ...............................8
3.2. Carrying The OF Object In a PCEP Message ...................9
3.3. New RP Object Flag ........................................12
3.3.1. Elements Of Procedure ..............................12
4. Objective Functions Definition .................................13
5. New Metric Types ...............................................14
6. IANA Considerations ............................................15
6.1. PCE Objective Function Sub-Registry .......................15
6.2. PCEP Code Points ..........................................16
6.2.1. OF Object ..........................................16
6.2.2. OF-List TLV ........................................16
6.2.3. PCEP Error Values ..................................16
6.2.4. RP Object Flag .....................................17
6.2.5. Metric Types .......................................17
7. Security Considerations ........................................17
8. Manageability Considerations ...................................18
8.1. Control of Function and Policy ............................18
8.2. Information and Data Models ...............................18
8.3. Liveness Detection and Monitoring .........................18
8.4. Verify Correct Operations .................................18
8.5. Requirements On Other Protocols ...........................19
8.6. Impact On Network Operations ..............................19
9. Acknowledgments ................................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
Appendix A. RBNF Code Fragments ...................................21
The Path Computation Element-based network architecture [RFC4655] defines a Path Computation Element (PCE) as an entity capable of computing the paths of Traffic Engineered Label Switched Paths (TE LSPs) based on a network graph and of applying computational constraints. A PCE services path computation requests that are sent by Path Computation Clients (PCC).
パス計算要素ベースのネットワークアーキテクチャ[RFC4655]はラベルネットワークグラフ上及び計算上の制約を適用するベースパス（TE LSPを）交換トラヒックエンジニアリングの経路を計算することが可能なエンティティとして経路計算エレメント（PCE）を定義します。 PCEサービスパス計算クライアント（PCC）によって送信された経路計算を要求。
The PCE communication Protocol (PCEP), defined in [RFC5440], allows for communication between a PCC and a PCE or between two PCEs, in compliance with requirements and guidelines set forth in [RFC4657]. Such interactions include path computation requests and path computation replies.
[RFC5440]で定義されたPCE通信プロトコル（PCEP）は、PCCとPCEとの間、または[RFC4657]に記載された要件およびガイドラインに準拠における2つのPCE間の通信を可能にします。そのような相互作用は、経路計算要求と経路計算応答を含みます。
The computation of one or a set of TE LSPs is subject to a set of one or more optimization criteria, called an objective function. An objective function is used by the PCE when it computes a path or a set of paths in order to select the "best" candidate paths. There is a variety of objective functions: an objective function could apply either to a set of non-synchronized path computation requests, or to a set of synchronized path computation requests. In the former case, the objective function refers to an individual path computation request (e.g., computation of the shortest constrained path where the metric is the IGP metric, computation of the least loaded constrained path, etc.). Conversely, in the latter case, the objective function refers to a set of path computation requests the computation of which is synchronized (e.g., minimize the aggregate bandwidth consumption of all LSPs, minimize the sum of the delays for two diverse paths or of the delta between those delays, etc.). Moreover, some objective functions relate to the optimization of a single metric and others to the optimization of a set of metrics (organized in a hierarchical manner, using a weighted function, etc.).
一方の演算又はTE LSPのセットは、目的関数と呼ばれる1つ以上の最適化基準のセットを受けます。目的関数は、それが「最良の」候補経路を選択するために、経路または経路のセットを計算するPCEによって使用されます。目的関数には様々なものがある：目的関数は、非同期経路計算要求のセットに、または同期経路計算要求のセットのいずれかに適用することもできます。前者の場合、目的関数は、個々の経路計算要求（例えば、メトリックがIGPメトリックである最短拘束経路の計算は、最小の計算は制約パス、等をロード）をいいます。逆に、後者の場合には、目的関数が経路計算のセットを指す（例えば、2つの多様な経路またはデルタの遅延の和を最小化する、すべてのLSPの集約帯域幅の消費を最小限に同期された計算を要求しますこれらの遅延など）の間。また、いくつかの目的関数は（重み関数等を使用して、階層的に編成）メトリックのセットの最適化に単一のメトリックなどの最適化に関する。
As spelled out in [RFC4674], it may be useful for a PCC to discover the set of objective functions supported by a PCE. Furthermore, [RFC4657] requires the ability for a PCC to indicate in a path computation request a required/desired objective function, as well as optional function parameters.
[RFC4674]に綴られるようPCCは、PCEによってサポートされる目的関数のセットを発見することが有用であり得ます。さらに、[RFC4657]はPCCは、経路計算要求に必要な/所望の目的関数、ならびにオプション機能パラメータを指示するための能力を必要とします。
For these purposes, this document extends the PCE communication Protocol (PCEP). It defines PCEP extensions that allow a PCE to advertise a list of supported objective functions, as well as extensions to carry the objective function in PCEP request and reply messages. It complements the PCEP base specification [RFC5440].
これらの目的のために、この文書は、PCE通信プロトコル（PCEP）に延びています。これは、PCEがPCEP要求で目的関数を実行し、メッセージを返信するサポート目的関数と同様に、拡張機能の一覧を宣伝することができPCEP拡張を定義します。これは、PCEP基本仕様[RFC5440]を補完します。
Note that OSPF- and IS-IS-based PCE discovery mechanisms are defined in [RFC5088] and [RFC5089]. These mechanisms are dedicated to the discovery of a few generic parameters, while more detailed PCE parameters should be discovered using the PCE communication Protocol. Objective functions are in this second category; thus, the objective function discovery procedure is handled by PCEP.
OSPF-およびIS-ISベースPCE発見メカニズムは[RFC5088]及び[RFC5089]で定義されることに留意されたいです。より詳細なPCEパラメータは、PCE通信プロトコルを使用して発見されるべきであるこれらのメカニズムは、いくつかの一般的なパラメータの発見に専念しています。目的関数は、この第二の範疇にあります。このように、目的関数の発見手順は、PCEPによって処理されます。
A new PCEP TLV, named the OF-List TLV, is defined in Section 2. The OF-List TLV is carried in the PCEP OPEN object and allows a PCE to list, during PCEP session-setup phase, the objective functions that it supports.
OF-リストTLVの-リストTLV第2節で定義されているという名前の新しいPCEP TLVは、PCEP OPENオブジェクトで運ばと、PCEPセッション・セットアップの段階で、PCEを一覧表示するには、それがサポートする目的関数を可能にされます。
A new PCEP object, the OF object, is defined in Section 3. The OF object is carried within a PCReq (Path Computation Request) message to indicate the required/desired objective function to be applied by a PCE, or in a PCRep (Path Computation Reply) message to indicate the objective function that was used for path computation.
新しいPCEPオブジェクトのオブジェクトは、第3のオブジェクトのPCEによって適用することが必要/所望の目的関数を示すメッセージPCReq（経路計算要求）内で実施されるで定義されている、またはPCRep（パスで経路計算のために使用された目的関数を示すために計算返信）メッセージ。
Six mandatory objective functions that must be supported by PCEP are listed in [RFC4657]. This document provides a definition of these six mandatory objective functions. Additional objective functions may be defined in other documents. Note that additional objective functions are defined for the PCE Global Concurrent Optimization (GCO) application, in [PCE-GCO].
PCEPによってサポートされなければならない六の必須の目的関数は、[RFC4657]に記載されています。この文書では、これらの6つの必須の目的関数の定義を提供します。追加の目的関数は、他のドキュメントで定義されてもよいです。追加の目的関数は、[PCE-GCO]で、PCEグローバル同時最適化（GCO）アプリケーションのために定義されていることに留意されたいです。
This document also provides the definition of four new metric types that apply to a set of synchronized requests.
また、このドキュメントでは、同期要求のセットに適用されます4つの新しいメトリックタイプの定義を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
LSR: Label Switching Router.
LSR：ラベルスイッチングルータ。
OF: Objective Function. A set of one or more optimization criteria used for the computation of a single path (e.g., path cost minimization) or for the synchronized computation of a set of paths (e.g., aggregate bandwidth consumption minimization, etc.).
OF：目的関数。単一パスの計算（例えば、パスコストの最小化）またはパスのセット（例えば、総帯域幅消費の最小化、等）の同期計算に使用される1つまたは複数の最適化基準のセット。
PCC: Path Computation Client. Any client application requesting a path computation to be performed by a Path Computation Element.
PCC：パス計算クライアント。経路計算要素によって実行される経路計算を要求する任意のクライアントアプリケーション。
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 of applying computational constraints.
PCE：パス計算要素。エンティティ（コンポーネント、アプリケーション、またはネットワークノード）が、ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用することが可能です。
PCEP: Path Computation Element communication Protocol.
PCEP：パス計算要素通信プロトコル。
TE LSP: Traffic Engineered Label Switched Path.
TE LSP：交通工学的ラベルスイッチパス。
Message formats in this document are expressed using Reduced BNF as used in [RFC5440] and defined in [RFC5511].
[RFC5440]で使用して、[RFC5511]で定義されるように、この文書に記載されているメッセージ形式は減少BNF用いて表現されています。
This section defines PCEP extensions (see [RFC5440]) so as to support the advertisement of the objective functions supported by a PCE.
PCEによってサポートされる目的関数の広告を支持するように、このセクションでは、（[RFC5440]を参照）PCEP拡張を定義します。
A new PCEP OF-List (Objective Function list) TLV is defined. The PCEP OF-List TLV is carried within an OPEN object. This way, during PCEP session-setup phase, a PCE can advertise to a PCEP peer the list of objective functions it supports.
OF-一覧新PCEP（目的関数リスト）TLVが定義されています。 PCEP OF-一覧TLVはOPENオブジェクト内で行われます。この方法では、PCEPセッション・セットアップの段階で、PCEは、それがサポートする目的関数のリストをピアPCEPに広告を掲載することができます。
The PCEP OF-List TLV is optional. It MAY be carried within an OPEN object sent by a PCE in an Open message to a PCEP peer so as to indicate the list of supported objective functions.
PCEP OF-一覧TLVはオプションです。これは、サポートされている目的関数のリストを示すようにPCEPピアにオープンメッセージにPCEによって送信されたOPENオブジェクト内で実施することができます。
The OF-List TLV format is compliant with the PCEP TLV format defined in [RFC5440]. That is, the TLV is composed of 2 octets for the type, 2 octets specifying the TLV length, and a Value field. The Length field defines the length of the value portion in octets. The TLV is padded to 4-octet alignment, and padding is not included in the Length field (e.g., a 3-octet value would have a length of three, but the total size of the TLV would be eight octets).
OF-リストTLVフォーマットは、[RFC5440]で定義さPCEP TLVフォーマットに準拠しています。つまり、TLVは、タイプ2つのオクテット、TLVの長さを指定する2つのオクテット、及び値フィールドから構成されています。 Lengthフィールドは、オクテットの値部分の長さを規定します。 TLVは4オクテット整列に埋め込まれ、パディングは、長さフィールド（例えば、3オクテットの値が3の長さを有するであろうが、TLVの合計サイズは8つのオクテットであろう）には含まれません。
The PCEP OF-List TLV has the following format:
PCEP OF-一覧TLVの形式は次のとおりです。
TYPE: 4 LENGTH: N * 2 (where N is the number of objective functions) VALUE: list of 2-byte objective function code points, identifying the objective functions supported by the sender of the Open message.
TYPE：4 LENGTH：N * 2（Nは、目的関数の数である）VALUE：2バイトの目的関数のコードポイントのリスト、オープンメッセージの送信者がサポートされている目的関数を識別する。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code #1 | OF Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code #N | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OF Code (2 bytes): Objective Function code point identifier. IANA manages the "PCE Objective Function" code point registry (see Section 6).
コード（2バイト）：目的関数のコードポイント識別子。 IANA（セクション6を参照してください）「PCE目的関数」コードポイントレジストリを管理します。
A PCE MAY include an OF-List TLV within an OPEN object in an Open message sent to a PCEP peer in order to advertise a set of one or more objective functions. The OF-List TLV MUST NOT appear more than once in an OPEN object. If it appears more than once, the PCEP session MUST be rejected with error type 1 and error value 1 (PCEP session establishment failure / Reception of an invalid Open message). The absence of the OF-List TLV in an OPEN object MUST be interpreted as an absence of information on the list of supported objective functions by the PCE.
PCEは、一つ以上の目的関数のセットを広告するためにPCEPピアに送信されたオープンメッセージに開いているオブジェクト内OF-リストTLVを含むかもしれません。 OF-リストTLVは一度OPENオブジェクトでより多く見えてはいけません。それが複数回表示された場合は、PCEPセッションは、エラータイプ1とエラー値1（PCEPのセッション確立の失敗/無効を開き、メッセージの受信）を拒絶しなければなりません。 OPENオブジェクト内OF-リストTLVが存在しないことは、PCEによってサポートされている目的関数のリストの情報が存在しないと解釈されなければなりません。
As specified in [RFC5440], a PCEP peer that does not recognize the OF-List TLV will silently ignore it.
[RFC5440]で指定されているように、認識されないPCEPピアは、OF-リストTLVは黙ってそれを無視します。
3. Objective Function in PCEP Path Computation Request and Reply Messages
PCEP経路計算要求3.目的関数とメッセージを返信
This section defines PCEP extensions [RFC5440] so as to support the communication of objective functions in PCEP path computation request and reply messages. A new PCEP OF (Objective Function) object is defined, to be carried within a PCReq message in order for the PCC to indicate the required/desired objective function.
PCEP経路計算要求に目的関数の通信をサポートし、メッセージを返信するようにこのセクションでは、PCEP拡張[RFC5440]を定義します。 （目的関数）オブジェクトが定義され、新しいPCEPは、必要な/所望の目的関数を示すPCCためにPCReqメッセージの中で運ばれます。
The PCEP OF object may also be carried within a PCRep message in order for the PCE to indicate the objective function that was used by the PCE.
オブジェクトのPCEPもPCEによって使用された目的関数を示すPCEためにPCRepメッセージ内で実施することができます。
A new flag is defined in the RP (Request Parameters) object. The flag is used in a PCReq message to indicate that the PCE MUST include an OF object in the PCRep message to indicate the objective function that was used during path computation.
新しいフラグは、RP（リクエストパラメータ）オブジェクトで定義されています。フラグは、PCEは、経路計算中に使用された目的関数を示すためにPCRepメッセージ内のオブジェクトの含まなければならないことを示すためにPCReqメッセージに使用されています。
Also, new PCEP error types and values are defined.
また、新しいPCEPエラーの種類と値が定義されています。
The PCEP OF (Objective Function) object is optional. It MAY be carried within a PCReq message so as to indicate the desired/required objective function to be applied by the PCE during path computation or within a PCRep message so as to indicate the objective function that was used by the PCE during path computation.
（目的関数）オブジェクトのPCEPは任意です。経路計算の間PCEによって使用された目的関数を示すように、経路計算中またはPCRepメッセージ内のPCEによって適用される所望の/必要な目的関数を示すように、それはPCReqメッセージ内で実施することができます。
The OF object format is compliant with the PCEP object format defined in [RFC5440].
オブジェクトフォーマットの[RFC5440]で定義されPCEPオブジェクトフォーマットに準拠しています。
The OF Object-Class is 21. The OF Object-Type is 1.
オブジェクト・クラスのオブジェクト型1で21です。
The format of the OF object body is:
オブジェクトの本体の形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OF Code (2 bytes): The identifier of the objective function. IANA manages the "PCE Objective Function" code point registry (see Section 6).
コード（2バイト）：目的関数の識別子。 IANA（セクション6を参照してください）「PCE目的関数」コードポイントレジストリを管理します。
Reserved (2 bytes): This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約済み（2バイト）：このフィールドは、送信にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
Optional TLVs may be defined in the future so as to encode objective function parameters.
目的関数のパラメータを符号化するように任意のTLVは、将来的に定義されてもよいです。
To request the use of a specific objective function by the PCE, a PCC includes an OF object in the PCReq message.
PCEによって特定の目的関数の使用を要求するために、PCCはPCReqメッセージ内のオブジェクトの含まれています。
[RFC5440] specifies a bit flag, referred to as the P bit, carried in the common PCEP object header. The P bit is set by a PCC to mandate that a PCE must take the information carried in the object into account during the path computation.
[RFC5440]はビットフラグを指定し、共通PCEPオブジェクトヘッダで運ばれ、Pビットと呼びます。 PビットはPCEが経路計算中に考慮対象で運ばれた情報を取らなければならないことを強制するためにPCCによって設定されています。
If the P bit is set in the OF object, the objective function is mandatory (required objective function) and the PCE MUST use the objective function during path computation. If the P bit is clear in the OF object, the objective function is optional (desired objective function) and the PCE SHOULD apply the function if it is supported but MAY choose to apply a different objective function, according to local capabilities and policies.
Pビットがオブジェクトの中に設定されている場合、目的関数は（必要な目的関数）必須であり、PCEは、経路計算中に目的関数を使用しなければなりません。 Pビットはオブジェクトの中にクリアされている場合、目的関数は、オプションの（所望の目的関数）であり、PCEは、それがサポートされている場合、関数を適用すべきであるが、ローカル機能およびポリシーに従って、異なる目的関数を適用することを選ぶかもしれ。
On receipt of a PCReq message with an OF object, a PCE MUST proceed as follows:
次のようにオブジェクトの有するPCReqメッセージの受信時に、PCEが進行しなければなりません。
- If the OF object is unknown/unsupported, the PCE MUST follow procedures defined in [RFC5440]. That is, if the P bit is set, the PCE sends a PCErr message with error type 3 or 4 (Unknown / Not supported object) and error value 1 or 2 (unknown / unsupported object class / object type), and the related path computation request MUST be discarded. If the P bit is cleared, the PCE is free to ignore the object.
- オブジェクトのサポートされていない/未知である場合、PCEは、[RFC5440]で定義された手順に従わなければなりません。すなわち、Pビットがセットされている場合、PCEは、エラータイプ3または4（不明/サポートされないオブジェクト）とエラー値1または2（不明/サポートされていないオブジェクト・クラス/オブジェクトタイプ）、および関連する経路とPCErrメッセージを送信し、あります計算要求を捨てなければなりません。 Pビットがクリアされている場合は、PCEは、オブジェクトを無視して自由です。
- If the objective function is unknown/unsupported and the P bit is set, the PCE MUST send a PCErr message with error type 3 or 4 (Unknown / Not supported object) and error value 4 (Unrecognized/Unsupported parameter), and the related path computation request MUST be discarded.
- 目的関数がサポートされていない/未知であり、Pビットがセットされ、PCEは、エラータイプ3または4（不明/オブジェクトをサポートせず）及び誤差値4（認識されていない/サポートされていないパラメータ）とPCErrメッセージを送信し、関連する必要がある場合経路計算要求を捨てなければなりません。
- If the objective function is unknown/unsupported and the P bit is cleared, the PCE SHOULD apply another (default) objective function.
- 目的関数がサポートされていない/未知であり、Pビットがクリアされている場合は、PCEは、別の（デフォルト）目的関数を適用する必要があります。
- If the objective function is supported but policy does not permit applying it and if the P bit is set, the PCE MUST send a PCErr message with the PCEP error type "policy-violation" (type 5) and a new error value, "objective function not allowed", which is defined in this document.
- 目的関数がサポートされているが、政策がそれを適用する許可されていないとPビットがセットされていれば、PCEはPCEPエラータイプ「ポリシー違反」（タイプ5）と新しいエラー値を持つPCErrメッセージを送信する必要がある場合」この文書で定義されて許可されていない目的関数」、。
- If the objective function is supported but policy does not allow applying it and if the P bit is cleared, the PCE SHOULD apply another (default) objective function.
- 場合は、目的関数がサポートされていますが、ポリシーは、それを適用することはできません。また、Pビットがクリアされている場合は、PCEは別の（デフォルト）目的関数を適用する必要があります。
- If the objective function is supported and policy allows applying it and if the P bit is set, the PCE MUST apply the requested objective function. Otherwise, if the P bit is cleared, the PCE is free to apply any other objective function.
- 場合は、目的関数がサポートされ、ポリシーは、それを適用することができますし、Pビットがセットされていれば、PCEは要求された目的関数を適用しなければなりません。 Pビットがクリアされている場合はそれ以外の場合は、PCEは、他の目的関数を適用することは自由です。
The default objective function may be locally configured.
デフォルト目的関数は、ローカルに構成することができます。
The OF object MAY be carried within a PCReq message. If an objective function is to be applied to a set of synchronized path computation requests, the OF object MUST be carried just after the corresponding SVEC (Synchronization VECtor) object and MUST NOT be repeated for each elementary request.
オブジェクトのPCReqメッセージ内で実施することができます。目的関数が同期経路計算リクエストのセットに適用される場合、オブジェクトのちょうど対応SVEC（同期ベクトル）オブジェクトの後に実行されなければならないと各基本要求に対して繰り返してはいけません。
Similarly, if a metric is to be applied to a set of synchronized requests, the METRIC object MUST follow the SVEC object and MUST NOT be repeated for each elementary request. Note that metrics applied to a set of synchronized requests are defined in Section 5.
メトリックが同期要求のセットに適用される場合同様、メトリックオブジェクトはSVECオブジェクトに従わなければならなくて、各基本要求に対して繰り返してはいけません。同期要求のセットに適用されるメトリックは、第5節で定義されていることに注意してください。
An OF object specifying an objective function that applies to an individual path computation request (non-synchronized case) MUST follow the RP object for which it applies.
オブジェクトのそれが適用されるRPオブジェクトに従わなければならない（非同期の場合）は、個々の経路計算要求に適用される目的関数を指定します。
The format of the PCReq message is updated as follows. Please see Appendix A for a full set of RBNF fragments defined in this document and the necessary code license.
次のようにPCReqメッセージのフォーマットが更新されます。このドキュメントおよび必要なコードのライセンスに定義されてRBNF断片のフルセットについては、付録Aを参照してください。
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
where:
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<request-list> ::= <request> [<request-list>]
<request> ::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<OF>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
and where:
そしてどこに：
<metric-list> ::= <METRIC>[<metric-list>]
The OF object MAY be carried within a PCRep message to indicate the objective function used by the PCE during path computation.
オブジェクトのパス計算中PCEによって使用される目的関数を示すためにPCRepメッセージ内で実施することができます。
When the PCE wants to indicate to the PCC the objective function that was used for the synchronized computation of a set of paths, the PCRep message MUST include the corresponding SVEC object directly followed by the OF object, which MUST NOT be repeated for each elementary request. If a metric is applicable to the set of paths, the METRIC object MUST directly follow the SVEC object and MUST NOT be repeated for each elementary request.
PCEは、PCCへのパスのセットの同期化計算のために使用された目的関数を示したい場合、PCRepメッセージは、各基本要求に対して繰り返されてはいけません直接オブジェクトの続く対応SVECオブジェクトを含まなければなりません。メトリックは、パスのセットに適用可能である場合、メトリックオブジェクトを直接SVECオブジェクトに従わなければならなくて、各基本要求に対して繰り返してはいけません。
An OF object specifying an objective function used for an individual path computation (non-synchronized case) MUST follow the RP object for which it applies.
個々の経路計算に使用される目的関数を指定するオブジェクトの（非同期の場合）は、それが適用されるRPオブジェクトに従わなければなりません。
The format of the PCRep message is updated as follows. Please see Appendix A for a full set of RBNF fragments defined in this document and the necessary code license.
次のようにPCRepメッセージのフォーマットが更新されます。このドキュメントおよび必要なコードのライセンスに定義されてRBNF断片のフルセットについては、付録Aを参照してください。
<PCRep Message> ::= <Common Header>
[<svec-list>]
<response-list>
where:
どこ：
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<response-list> ::= <response> [<response-list>]
<response> ::= <RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list> ::= <path> [<path-list>]
<path> ::= <ERO>
<attribute-list>
and where:
そしてどこに：
<attribute-list> ::= [<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<metric-list> ::= <METRIC> [<metric-list>]
Note: The OF object MAY be associated to a negative reply, i.e., a reply with a NO-PATH object.
注：オブジェクトの、負の応答に関連していてもよい、すなわち、NO-PATHオブジェクトと返信。
In some cases, where no objective function is specified in the request or an optional objective function is desired (P flag cleared in the OF object common header) but the PCE does not follow the request, the PCC may desire to know the objective function that was used by the PCE during path computation. To that end, a new flag is defined in the RP object, named the OF flag, allowing a PCC to request for the inclusion in the path computation reply of the objective function that was used by the PCE during path computation.
客観関数が要求または任意の目的関数に指定されていないいくつかのケースでは、所望される（Pフラグは、オブジェクトの共通ヘッダのクリア）が、PCEは、要求に従わない、PCCは、その目的関数を知ることを望むかもしれません経路計算の間PCEによって使用されました。そのために、新しいフラグがPCCは、経路計算中PCEによって使用された目的関数の経路計算応答に含めることを要求することができ、フラグの名前付きRPオブジェクトに定義されています。
The following new bit flag of the RP object is defined:
RPオブジェクトの次の新しいビットフラグが定義されています。
The Supply OF on response flag (bit number 24). When set in a PCReq message, this indicates that the PCE MUST provide the applied objective function (should a path satisfying the constraints be found) in the PCRep message. When set in a PCRep message, this indicates that the objective function that was used during path computation is included.
応答フラグに供給（ビット番号24）。 PCReqメッセージに設定されている場合、これは、PCEがPCRepメッセージ内（制約条件を満たすパスが見つからなければならない）を適用目的関数を提供しなければならないことを示しています。 PCRepメッセージに設定されている場合、これは、経路計算中に使用された目的関数が含まれていることを示しています。
If the PCC wants to know the objective function used by the PCE during path computation for a given request, it sets the OF flag in the RP object.
PCCは、与えられたリクエストのパス計算中PCEによって使用される目的関数を知りたい場合は、RPオブジェクトにフラグのセット。
On receipt of a PCReq message with the OF flag in the RP object set, the PCE proceeds as follows:
RPオブジェクトセット内のフラグOFとPCReqメッセージの受信時に、PCEは以下のように進行します：
- If policy permits, it MUST include in the PCRep message an OF object indicating the objective function it used during path computation.
- ポリシーが許す場合、それは経路計算の間に使用される目的関数を表すオブジェクトのPCRepメッセージに含まなければなりません。
- If policy does not permit, it MUST send a PCErr message with the PCEP error code "policy-violation" (type 5) and a new error value, "objective function indication not allowed", which is defined in this document.
- ポリシーが許可されていない場合は、PCEPエラーコード「ポリシー違反」（タイプ5）と、この文書で定義され、「目的関数表示が許可されていない」新しいエラー値とPCErrメッセージを送らなければなりません。
Note that a legacy PCE might not recognize the OF flag in the RP object. According to the definition of the Flags field for the RP object (Section 7.4.1 of [RFC5440]), the legacy PCE will ignore the unknown flag, resulting in it sending a PCRep that does not contain an OF object. In this case, the PCC's behavior is an implementation choice. The PCC might:
レガシーPCEは、RPオブジェクトにフラグOF認識しない場合がありますので注意してください。 RPオブジェクト（[RFC5440]のセクション7.4.1）のフラグ・フィールドの定義によれば、従来のPCEは、オブジェクトの含まれていないPCRepを送信することで得られ、未知のフラグを無視します。この場合は、PCCの動作は実装の選択です。 PCC可能性があります：
- Discard the PCRep because it really wanted the OF object returned.
- それは本当にオブジェクトの戻りたかったのでPCRepを捨てます。
- Accept the PCRep without the knowledge of the OF that was applied.
- その適用されたの知識がなくてもPCRepを受け入れます。
Note also that these procedures can give rise to the situation where a PCC receives a PCRep that contains an OF object with an objective function identifier that the PCC does not recognize. In this situation, the PCC behavior is dependent on implementation and configuration. The PCC could choose any of the following (or some other action):
これらの手順は、PCCが認識しない目的関数識別子と対象物の含有PCCはPCRepを受信する状況を生じさせることができることにも留意されたいです。このような状況では、PCCの動作は実装と設定に依存しています。 PCCは、以下の（または他のアクション）のいずれかを選択できます。
- Ignore the OF object and use the computed path.
- オブジェクトの無視して計算された経路を使用しています。
- Add the objective function to its view of the PCE's repertoire for inclusion in future computation requests.
- 今後の計算要求に含めるためPCEのレパートリーのビューに目的関数を追加します。
- Discard the PCRep (i.e., the computed path) and send a PCReq to another PCE.
- PCRep（すなわち、計算されたパス）を破棄し、別のPCEにPCReqを送ります。
- Discard the PCRep (i.e., the computed path) and send another PCReq to the same PCE explicitly requiring the use of some other objective function (i.e., by setting the P bit in the OF object).
- PCRep（すなわち、計算されたパス）を破棄し（すなわち、オブジェクトの中のPビットをセットすることにより）明示的に他のいくつかの目的関数の使用を必要と同じPCEに別のPCReqを送ります。
Six objective functions that must be supported by PCEP are listed in [RFC4657]. Objective function codes have been assigned by IANA and are described below.
PCEPによってサポートされている必要がありシックス・目的関数は、[RFC4657]に記載されています。目的関数のコードは、IANAによって割り当てられており、以下に説明します。
Objective functions are formulated using the following terminology:
目的関数は、以下の用語を使用して処方されます。
- A network comprises a set of N links {Li, (i=1...N)}.
- ネットワークは、N個のリンク{リチウム、（i = 1 ... N）}のセットを含みます。
- A path P is a list of K links {Lpi,(i=1...K)}.
- 経路PはKリンク{のLpi、（i = 1 ... K）}のリストです。
- Metric of link L is denoted M(L). This can be the IGP metric, the TE metric, or any other metric.
- リンクLのメトリックは、M（L）で示されます。これはIGPメトリック、TEメトリック、または任意の他のメトリックをすることができます。
- The cost of a path P is denoted C(P), where C(P) = sum {M(Lpi), (i=1...K)}.
- 経路Pのコストは、C（P）、C（P）=和{M（LPI）、（i = 1 ... K）}で示されます。
- Residual bandwidth on link L is denoted r(L).
- リンクL上の残余帯域をr（L）で示されます。
- Maximum reservable bandwidth on link L is denoted R(L).
- リンクL上の最大予約可能帯域幅はR（L）で示されます。
There are three objective functions that apply to the computation of a single path:
単一パスの計算に適用される3つの目的の機能があります。
Objective Function Code: 1 Name: Minimum Cost Path (MCP) Description: Find a path P such that C(P) is minimized.
目的関数コード：1名：最小コストパス（MCP）説明：C（P）が最小になるようにパスPを検索します。
Objective Function Code: 2 Name: Minimum Load Path (MLP) Description: Find a path P such that ( Max {(R(Lpi) - r(Lpi)) / R(Lpi), i=1...K } ) is minimized.
目的関数コード：2名：最小負荷経路（MLP）説明：パスPを探すように（最大{（R（LPI） - R（LPI））/ R（LPI）、I = 1 ... K}）最小化されます。
Objective Function Code: 3 Name: Maximum residual Bandwidth Path (MBP) Description: Find a path P such that ( Min { r(Lpi), i=1...K } ) is maximized.
目的関数コード：3名：最大残余帯域パス（MBP）説明：（最小{R（LPI）、I = 1 ... K}が）最大となるPがこのような経路を探します。
There are three objective functions that apply to a set of path computation requests the computation of which is synchronized:
同期されているの計算を要求した経路計算のセットに適用3つの目的の機能があります。
Objective Function Code: 4 Name: Minimize aggregate Bandwidth Consumption (MBC) Description: Find a set of paths such that ( Sum {R(Li) - r(Li), i=1...N} ) is minimized.
目的関数コード：4名：総帯域幅消費（MBC）説明を最小化：パスのセットを探すように（SUM {R（Li）と - R（Li）と、I = 1 ... N}）が最小化されます。
Objective Function Code: 5 Name: Minimize the Load of the most loaded Link (MLL) Description: Find a set of paths such that ( Max { (R(Li) - r(Li)) / R(Li), i=1...N}) is minimized.
目的関数コード：5名前：ほとんどロードされたリンク（MLL）説明の負荷を最小化：パスのセットを探すように（最大{（Rリチウム（Li） - R（リー））/ R（Li）と、I = 1 ... N}は）最小化されます。
Objective Function Code: 6 Name: Minimize the Cumulative Cost of a set of paths (MCC) Description: Find a set of paths {P1...Pm} such that (Sum { C(Pi), i=1...m}) is minimized.
目的関数コード：6名：パス（MCC）説明のセットの累積コストを最小化：パスのセットを探す{P1 ... Pmを}ように（SUM {C（PI）、I = 1 ... M }）が最小化されます。
Other objective functions may be defined in separate documents.
その他の目的関数は、別の文書で定義されていてもよいです。
Three metric types are defined in PCEP for the METRIC object: TE metric, IGP metric, and hop count. These metric types apply to an individual request. Here, we define four new metric types that apply to a set of synchronized requests:
TEメトリック、IGPメトリック、およびホップ数：三つのメトリックタイプがMETRICオブジェクトに対してPCEPで定義されています。これらのメトリックのタイプは、個々の要求に適用されます。ここでは、同期化要求のセットに適用されます4つの新しいメトリックタイプを定義します。
Type 4: Aggregate bandwidth consumption.
タイプ4：集約帯域幅の消費。
Type 5: Load of the most loaded link.
タイプ5：ほとんどのロードされたリンクのロード。
Type 6: Cumulative IGP cost.
タイプ6：累積IGPコスト。
Type 7: Cumulative TE cost.
タイプ7：累積TEコスト。
These metrics may be used in a PCReq to indicate a bound (B bit set in the METRIC object) or to request the computation of a metric (C bit set in the METRIC object), or in a PCRep to indicate a computed metric.
これらのメトリックは、計算されたメトリックを示すため（Cは、ビットメトリックオブジェクトに設定）バウンドを示すために（Bはビットメトリックオブジェクトに設定）またはメトリックの計算を要求するPCReqに用いてもよいし、PCRepに。
A METRIC object with one of these four types follows the SVEC object for which it applies.
これら4種類のいずれかでMETRICオブジェクトは、それが適用されるSVECオブジェクトに従います。
This document defines a 16-bit PCE objective function identifier to be carried within the PCEP OF object, and also defines the PCEP OF-List TLV.
この文書は、オブジェクトのPCEP内で実施される16ビットのPCE目的関数の識別子を定義し、また、OF-リストTLV PCEPを定義します。
IANA created and now manages the 16-bit "PCE Objective Function" code point registry, starting from 1 and continuing through 32767, as follows:
IANAが作成され、次のように今、1から始まり、32767まで継続、16ビットの「PCE目的関数」コードポイントレジストリを管理します。
- Objective Function code point value - Objective Function name - Defining RFC
- 目的関数のコードポイント値 - 目的関数名 - RFCの定義
The same registry is applicable to the OF object and the OF-List TLV that are defined in this document.
同じレジストリは、オブジェクトと、この文書で定義されているOF-リストTLV OFに適用されます。
The guidelines (using terms defined in [RFC5226]) for the assignment of objective function code point values are as follows:
次のように目的関数のコードポイント値の割り当てのためのガイドライン（[RFC5226]で定義された用語を使用して）です。
- Function code value 0 is reserved.
- 機能コード値0は予約されています。
- Function code values in the range 1-32767 are assigned as follows:
- 次のように範囲1〜32767で機能コード値が割り当てられています。
o Function code values 1 through 1023 are assigned by IANA using the "IETF Review" policy.
O機能コードは、1〜1023が「IETFレビュー」ポリシーを使用してIANAによって割り当てられた値。
o Function code values 1024 through 32767 are assigned by IANA, using the "First Come First Served" policy.
O機能コードは、1024から32767がポリシー「をまず第一に役立っ来」を使用して、IANAによって割り当てられている値。
o Function code values in the range 32768-65535 are for "Private Use".
範囲32768から65535でO機能コードの値が「私用」のためのものです。
Six objective functions are defined in Section 4 of this document and have been assigned by IANA:
シックス・目的関数は、このドキュメントのセクション4で定義され、IANAによって割り当てられています：
Code Point Name Reference
-------------------------------------------------------
1 MCP RFC 5541
2 MLP RFC 5541
3 MBP RFC 5541
4 MBC RFC 5541
5 MLL RFC 5541
6 MCC RFC 5541
IANA manages the PCEP Objects code point registry (see [RFC5440]). This is maintained as the "PCEP Objects" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
IANAは、（[RFC5440]を参照）PCEPオブジェクトコードポイントレジストリを管理します。これは、「経路計算要素プロトコル（PCEP）番号」レジストリの「PCEPオブジェクト」サブレジストリとして維持されます。
This document defines a new PCEP object, the OF object, to be carried in PCReq and PCRep messages. IANA has made the following allocation:
この文書は、新しいPCEPオブジェクト、オブジェクトの、PCReqとPCRepメッセージで搬送されることを定義します。 IANAは、次の割り当てを行っています。
Object Name Object Name Reference
Class Type
------------------------------------------------------------
21 OF 1 Objective Function RFC 5541
IANA manages the PCEP TLV code point registry (see [RFC5440]). This is maintained as the "PCEP TLV Type Indicators" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
IANAは、（[RFC5440]を参照）PCEP TLVコードポイントレジストリを管理します。これは、「経路計算要素プロトコル（PCEP）番号」レジストリの「PCEP TLVタイプインジケータ」サブレジストリとして維持されます。
This document defines a new PCEP TLV, the OF-List TLV, to be carried in the OPEN object. IANA has made the following allocation:
この文書では、OPEN対象に実施される新しいPCEP TLV、OF-リストTLVを定義します。 IANAは、次の割り当てを行っています。
Type TLV name References
-----------------------------------------------
4 OF-List RFC 5541
IANA maintains a registry of Error-types and Error-values for use in PCEP messages. This is maintained as the "PCEP-ERROR Object Error Types and Values" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
IANAは、PCEPメッセージで使用するためのエラー・タイプとエラー値のレジストリを維持します。これは、「経路計算要素プロトコル（PCEP）番号」レジストリの「PCEP-ERRORオブジェクトエラーの種類と値」サブレジストリとして維持されます。
Two new Error-values are defined for the Error-type "policy violation" (type 5):
二つの新しいエラー値がエラータイプ「ポリシー違反」（タイプ5）のために定義されています。
Error-type Meaning and error values Reference
------------------------------------------------------------------
5 Policy violation
Error-value=3: objective function not RFC 5541
allowed (request rejected)
Error-value=4: OF bit of the RP object RFC 5541 set (request rejected)
エラー値= 4：RPオブジェクトRFC 5541セットのビット（要求が拒否）
A new flag of the RP object (specified in [RFC5440]) is defined in this document. IANA maintains a registry of RP object flags in the "RP Object Flag Field" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
RPオブジェクトの新しいフラグ（[RFC5440]で指定）は、この文書で定義されています。 IANAは、「パス計算エレメントプロトコル（PCEP）番号」レジストリの「RPオブジェクトフラグ・フィールド」サブレジストリにRPオブジェクトフラグのレジストリを維持します。
IANA has made the following allocation:
IANAは、次の割り当てを行っています。
Bit Description Reference
-------------------------------------------
24 Supply OF on response RFC 5541
Four new metric types are defined in this document for the METRIC object (specified in [RFC5440]). IANA maintains a registry of metric types in the "METRIC Object T Field" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
四つの新しいメトリックタイプメトリックのオブジェクトについては、この文書で定義されている（[RFC5440]で指定されます）。 IANAは、「パス計算エレメントプロトコル（PCEP）番号」レジストリの「METRICオブジェクトTフィールド」サブレジストリにメトリックタイプのレジストリを維持します。
IANA has made the following allocations:
IANAは、次の割り当てを行っています。
- Type 4: Aggregate bandwidth consumption - Type 5: Load of the most loaded link - Type 6: Cumulative IGP cost - Type 7: Cumulative TE cost
- タイプ4：集約帯域幅の消費 - タイプ5：ほとんどのロードされたリンクの荷重 - タイプ6：累積IGPコスト - タイプ7：累積TEコスト
PCEP security mechanisms are described in [RFC5440] and are used to secure entire PCEP messages. Nothing in this document changes the message flows or introduces any new messages, so the security mechanisms set out in [RFC5440] continue to be applicable.
PCEPセキュリティメカニズムは、[RFC5440]に記載されており、全体PCEPメッセージを保護するために使用されます。本書の内容は、メッセージが流れたり紹介する新しいメッセージを、ので、[RFC5440]に記載されたセキュリティメカニズムを適用できるように引き続き変化しません。
This document introduces a single new object that may optionally be carried on PCEP messages and will be automatically secured using the mechanisms described in [RFC5440].
この文書は、必要に応じてPCEPメッセージに担持されてもよいし、自動的に[RFC5440]で説明されたメカニズムを用いて固定される単一の新しいオブジェクトを導入します。
If a PCEP message is vulnerable to attack (for example, because the security mechanisms are not used), then the OF object could be used as part of an attack; however, it is likely that other objects will provide far more significant ways of attacking a PCE or PCC in this case.
PCEPメッセージは、（セキュリティ・メカニズムが使用されないので、例えば）攻撃に対して脆弱である場合、物体の攻撃の一部として使用することができます。しかし、他のオブジェクトが、この場合、PCEかPCCを攻撃するはるかに重要な方法を提供する可能性があります。
It MUST be possible to configure the activation/deactivation of objective function discovery in PCEP.
PCEPにおける目的関数発見の有効化/無効化を設定することは可能でなければなりません。
In addition to the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD allow configuring a list of authorized objective functions on a PCE. This may apply to any session the PCEP speaker participates in, to a specific session with a given PCEP peer, or to a specific group of sessions with a specific group of PCEP peers.
すでに[RFC5440]のセクション8.1に記載されているパラメータに加えて、PCEP実装はPCEに認可目的関数のリストを設定可能にすべきです。これは、PCEPスピーカが所定PCEPピアと特定のセッションへ、またはPCEPピアの特定のグループとのセッションの特定のグループに、ことに関与する任意のセッションに適用することができます。
Note that it is not mandatory for an implementation to support all objective functions defined in Section 4.
それは第4節で定義されたすべての目的関数をサポートする実装のために必須ではないことに注意してください。
It MUST be possible to configure a default objective function used for path computation when a path request is received that requests to use an optional objective function.
パス要求は要求は、オプションの目的関数を使用することを受信したときに経路計算のために使用されるデフォルト目的関数を設定することは可能でなければなりません。
The PCEP MIB Module defined in [PCEP-MIB] could be extended to include objective functions.
[PCEP-MIB]で定義PCEP MIBモジュールは、目的関数を含むように拡張することができます。
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].
この文書で定義されたメカニズムは、すでに[RFC5440]に記載されているものに加えて、新たな生存性の検出と監視の要件を意味するものではありません。
Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440].
この文書で定義されたメカニズムは、すでに[RFC5440]に記載されているものに加えて、新たな動作確認の要件を意味するものではありません。
Mechanisms defined in this document do not imply any requirements on other protocols in addition to those already listed in [RFC5440].
この文書で定義されたメカニズムは、すでに[RFC5440]に記載されているものに加えて他のプロトコル上の任意の要件を意味するものではありません。
Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440].
この文書で定義されたメカニズムは、すでに[RFC5440]に記載されているものに加えて、ネットワーク運用への影響はありません。
The authors would like to thank Jerry Ash, Fabien Verhaeghe, Robert Sparks, and Adrian Farrel for their useful comments.
作者は彼らの役に立つコメントをジェリー・アッシュ、ファビアンVerhaeghe、ロバートスパークス、およびエードリアンファレルに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（PCE）ベースのアーキテクチャ"、RFC 4655、2006年8月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、JP。、編、およびJL。ル・ルー、エド。、 "パス計算要素（PCE）通信プロトコル（PCEP）"、RFC 5440、2009年3月。
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657]アッシュ、J.、エド。、およびJ.ル・ルー、エド。、 "パス計算要素（PCE）通信プロトコルジェネリック要件"、RFC 4657、2006年9月。
[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
[RFC4674]ル・ルー、J.、エド。、RFC 4674、2006年10月 "経路計算エレメント（PCE）の発見のための要件"。
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008.
[RFC5088]ル・ルー、JL。、エド。、Vasseur、JP。、エド。、池尻、Y.、およびR.張、 "OSPFプロトコル拡張パスの計算要素（PCE）ディスカバリー"、RFC 5088、2008年1月。
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5089]ル・ルー、JL。、エド。、Vasseur、JP。、エド。、池尻、Y.、およびR.張は、 "IS-ISプロトコル拡張経路計算エレメント（PCE）の発見について"、RFC 5089、1月2008。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[PCE-GCO] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", Work in Progress, March 2009.
[PCE-GCO]リー、Y.、ル・ルー、JL。、キング、D.、およびE.沖、「パス計算要素通信プロトコル（PCEP）の要件とプロトコルの拡張機能のグローバル同時最適化のサポートで」が進行中で働いています、2009年3月。
[PCEP-MIB] Koushik, K., and E. Stephan, "PCE Communication Protocol (PCEP) Management Information Base", Work in Progress, January 2009.
[PCEP-MIB]コウシク、K.、およびE.ステファン、 "PCE通信プロトコル（PCEP）管理情報ベース"、進歩、2009年1月の作業。
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF) - A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009.
[RFC5511]ファレル、A.、「ルーティングバッカス記法（RBNF） - さまざまなルーティングプロトコル仕様に符号化規則を形成するのに使用される構文」を2009年4月、RFC 5511を。
Appendix A. RBNF Code Fragments
付録A. RBNFコードフラグメント
This appendix contains the full set of code fragments defined in this document.
この付録では、本書で定義されたコードフラグメントのフルセットが含まれています。
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
著作権（C）2009 IETF信託コードの作者として特定の人物。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
再配布および、改変してまたは改変せずに、ソースおよびバイナリ形式で使用し、以下の条件が満たされていることを許可されます。
o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Oソースコードの再配布は、上記の著作権表示、条件のリストおよび以下の免責事項を保持しなければなりません。
o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Oバイナリ形式で再配布は、上記の著作権表示、条件のリストおよび文書および/または分布を備えた他の材料で次の免責事項を再現しなければなりません。
o Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
Oインターネット協会、IETFやIETFトラストの名称、また具体的な貢献者の名前はどちらも、特定の書面による事前の許可なしに、本ソフトウェアから派生した製品を推薦または促進するために使用することができます。
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
「現状のまま」、いかなる明示または黙示の保証、含むがこれらに限定されないが、特定目的に対する適合性の黙示の保証は放棄さ本ソフトウェアは著作権所有者によって提供されます。 NO EVENTの著作権所有者または貢献者は、以下を含むいかなる直接的、間接的、偶発的、特別、懲罰的、または間接的損害（についても責任を負いあってもよいが、代替商品またはサービスの調達、これらに限定されないものとし、使用、データ、または利益の損失; OR事業の中断）原因で生じた（そのような損害の可能性について知らされていた場合でも、一切このソフトウェアの使用の損失、データの損失）過失またはその他を含む責任、それが契約、厳格な責任、不法行為のどのような理論の上で。
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
<PCRep Message> ::= <Common Header>
[<svec-list>]
<response-list>
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<request-list> ::= <request> [<request-list>]
<request> ::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<OF>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
<metric-list> ::= <METRIC>[<metric-list>]
<response-list> ::= <response> [<response-list>]
<response> ::= <RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list> ::= <path> [<path-list>]
<path> ::= <ERO>
<attribute-list>
<attribute-list> ::= [<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
Authors' Addresses
著者のアドレス
JL Le Roux France Telecom 2, Avenue Pierre-Marzin Lannion 22307 France
JLルルーフランステレコム2、アベニューピエールMarzin 22307ラニオンフランス
EMail: jeanlouis.leroux@orange-ftgroup.com
メールアドレス：jeanlouis.leroux@orange-ftgroup.com
Jean-Philippe Vasseur Cisco Systems, Inc 11, Rue Camille Desmoulins L'Atlantis 92782 Issy Les Moulineaux France
ジャン=フィリップVasseurシスコシステムズ社11、ルーカミーユ・デムーランアトランティス92782のイシレムリノーフランス
EMail: jpv@cisco.com
メールアドレス：jpv@cisco.com
Young Lee Huawei Technologies, LTD. 1700 Alma Drive, Suite 100 Plano, TX 75075 USA
ヤング・リー華為技術、LTD。 1700アルマドライブ、スイート100プラノ、TX 75075 USA
EMail: ylee@huawei.com
メールアドレス：ylee@huawei.com