[要約] RFC 5541は、PCEPで使用される目的関数のエンコーディングに関する情報を提供します。このRFCの目的は、PCEPの通信プロトコルで使用される目的関数のエンコーディング方法を標準化することです。
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)
パス計算要素通信プロトコル（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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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）の1つまたはAセットの計算は、客観的機能と呼ばれる1つ以上の特定の最適化基準のセットに従います（たとえば、最小コストパス、最も広いパスなど）。
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）は、特定の目的関数に従って1つ以上の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通信プロトコル（PCEP）への拡張機能を定義して、PCEがサポートする一連の目的関数を示すことができます。拡張機能は、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).
PATH計算要素ベースのネットワークアーキテクチャ[RFC4655]は、ネットワークグラフと計算制約の適用に基づいて、トラフィックエンジニアリングラベルスイッチドパス（TE LSP）のパスを計算できるエンティティとしてパス計算要素（PCE）を定義します。Path Computation Clients（PCC）によって送信されるPCEサービスパス計算要求。
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）は、[RFC4657]に記載されている要件とガイドラインに準拠して、PCCとPCEまたは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つまたはAセットの計算は、目的関数と呼ばれる1つ以上の最適化基準のセットの対象となります。PCEがパスまたは一連のパスを計算して、「最良の」候補パスを選択するときに、PCEが目的関数を使用します。さまざまな目的関数があります。目的関数は、一連の非同期パス計算要求のセット、または同期されたパス計算要求のセットのいずれかに適用できます。前者の場合、目的関数は、個々のパス計算要求（たとえば、メトリックがIGPメトリックである場合の最短の制約パスの計算、負荷の少ない制約パスの計算など）を指します。逆に、後者の場合、目的関数は、一連のパス計算要求を指します。その計算は同期されます（たとえば、すべてのLSPの集約帯域幅消費を最小化し、2つの多様なパスまたはデルタの遅延の合計を最小化しますそれらの遅延などの間）。さらに、一部の目的関数は、単一のメトリックの最適化に関連しており、他の関数は一連のメトリックの最適化（加重関数などを使用して階層的な方法で編成されています）の最適化に関連しています。
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パラメーターを発見する必要があります。目的関数は、この2番目のカテゴリにあります。したがって、目的関数発見手順は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と名付けられた新しいPCEP TLVはセクション2で定義されています。OFリストTLVはPCEPオープンオブジェクトに運ばれ、PCEがサポートするPCEPセッションセットアップフェーズで、PCEPセッションセットアップフェーズでリストできるようにします。。
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で定義されています。オブジェクトは、PCREQ（PATH計算要求）メッセージ内で配信され、PCEまたはPCREP（PATH）で適用される必要な/目的のオブジェクト関数を示します。計算応答）パス計算に使用された目的関数を示すメッセージ。
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でサポートする必要がある6つの必須目的関数は、[RFC4657]にリストされています。このドキュメントは、これらの6つの必須の目的関数の定義を提供します。追加の目的関数は、他のドキュメントで定義される場合があります。[PCE-GCO]で、PCE Global Concurrent Opturrent Opturization（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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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がサポートする目的関数の広告をサポートするために、PCEP拡張（[RFC5440]を参照）を定義します。
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.
リストの新しいPCEP（目的関数リスト）TLVが定義されています。リストTLVのPCEPは、開いたオブジェクト内で運ばれます。このようにして、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.
リストTLVのPCEPはオプションです。PCEPピアへの開かれたメッセージでPCEによって送信された開いたオブジェクト内で、サポートされている目的関数のリストを示すことができます。
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オクテット、および値フィールドで構成されています。長さフィールドは、オクテットの値部分の長さを定義します。TLVは4-OCTETアライメントにパッドで埋められており、パディングは長さフィールドに含まれていません（たとえば、3-OCTET値の長さは3ですが、TLVの合計サイズは8オクテットです）。
The PCEP OF-List TLV has the following format:
リストTLVのPCEPには、次の形式があります。
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.
タイプ：4長さ：n * 2（nは目的関数の数）値：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は「PCE Objective Function」コードポイントレジストリを管理します（セクション6を参照）。
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には、1つ以上の目的関数のセットを宣伝するために、PCEPピアに送信された開いたメッセージにOpenオブジェクト内にOFリストTLVを含めることができます。OFリストTLVは、開いたオブジェクトに1回以上表示されてはなりません。複数回表示される場合、PCEPセッションはエラータイプ1およびエラー値1（PCEPセッションの確立の失敗 /無効なオープンメッセージの受信）で拒否されなければなりません。開いたオブジェクトにof-fist TLVが存在しないことは、PCEによるサポートされている目的関数のリストに関する情報の欠如として解釈されなければなりません。
As specified in [RFC5440], a PCEP peer that does not recognize the OF-List TLV will silently ignore it.
[RFC5440]で指定されているように、OFリストTLVを認識しないPCEPピアは静かにそれを無視します。
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.
PCEがPCEで使用された目的関数を示すために、オブジェクトのPCEPを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（リクエストパラメーター）オブジェクトで定義されています。フラグはPCREQメッセージで使用されて、PCEがPCREPメッセージにObjectを含める必要があることを示し、パス計算中に使用された目的関数を示す必要があることを示します。
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によって適用される目的の/必要な目的関数を示すために、またはPATH計算中にPCEがPCEによって使用された目的関数を示すために、目的の/必要な目的関数をPCREQメッセージ内またはPCREPメッセージ内で実施することができます。
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.
オブジェクトクラスは21です。オブジェクトタイプのものは1です。
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は「PCE Objective Function」コードポイントレジストリを管理します（セクション6を参照）。
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 BITは、PCCがパス計算中にオブジェクトに携帯されている情報を考慮しなければならないことを義務付けるために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はパス計算中に目的関数を使用する必要があります。PITがオブジェクトで明確である場合、目的関数はオプション（目的の目的関数）であり、PCEがサポートされている場合は関数を適用する必要がありますが、ローカル機能とポリシーに従って異なる目的関数を適用することを選択できます。
On receipt of a PCReq message with an OF object, a PCE MUST proceed as follows:
Objectを使用した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）と新しいエラー値「Objective」で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.
OFオブジェクトは、PATH計算中に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.
PCCが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.
注：オブジェクトは、否定的な応答、つまりパスなしオブジェクトを使用した返信に関連付けられている場合があります。
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.
場合によっては、要求に目的関数が指定されていない場合、またはオプションの目的関数が望ましい場合（PFのflagがオブジェクト共通ヘッダーでクリアされています）、pceはリクエストに従わない場合、PCCは目的関数を知りたい場合があります。PATH計算中にPCEによって使用されました。そのために、flagと名付けられたRPオブジェクトで新しいフラグが定義されているため、PCCがPATH計算中にPCEが使用した目的関数のパス計算応答を要求することができます。
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オブジェクトセットにflagを使用したpcreqメッセージを受信すると、PCEは次のように進みます。
- If policy permits, it MUST include in the PCRep message an OF object indicating the objective function it used during path computation.
- ポリシーが許可されている場合は、PATH計算中に使用した目的関数を示すオブジェクトの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オブジェクトのフラグを認識しない場合があることに注意してください。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が認識していない目的関数識別子を持つオブジェクトを含むPCREPをPCCが受信する状況を引き起こす可能性があることに注意してください。この状況では、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（つまり、計算されたパス）を破棄し、PCREQを別のPCEに送信します。
- 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（つまり、計算されたパス）を破棄し、他の目的関数を使用することを明示的に必要とする同じPCEに別のPCREQを送信します（つまり、オブジェクトにPビットを設定することにより）。
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でサポートする必要がある6つの目的関数は、[RFC4657]にリストされています。目的関数コードはIANAによって割り当てられており、以下に説明します。
Objective functions are formulated using the following terminology:
目的関数は、次の用語を使用して定式化されます。
- A network comprises a set of N links {Li, (i=1...N)}.
- ネットワークは、nリンクのセット{li、（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）= sum {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）説明：（max {（r（lpi） - r（lpi）） / r（lpi）、i = 1 ... k}）などのパスPを見つけます。最小化されます。
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）説明：（min {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）の負荷を最小化します説明：（max {（r（li） - r（li）） / 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:
メトリックオブジェクトのPCEPで3つのメトリックタイプが定義されています：TEメトリック、IGPメトリック、およびホップカウント。これらのメトリックタイプは、個々のリクエストに適用されます。ここでは、同期されたリクエストのセットに適用される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.
これらのメトリックは、PCREQで使用されて、結合（メトリックオブジェクトに設定されたbビット）またはメトリックの計算（メトリックオブジェクトで設定されたCビット）を要求するか、計算されたメトリックを示すPCREPで使用できます。
A METRIC object with one of these four types follows the SVEC object for which it applies.
これらの4つのタイプのいずれかを持つメトリックオブジェクトは、適用される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.
このドキュメントは、16ビットのPCE対物関数識別子をオブジェクトのPCEP内で携帯するように定義し、リスト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から16ビットの「PCE Objective Function」コードポイントレジストリを作成し、次のように32767まで続きます。
- 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.
同じレジストリは、このドキュメントで定義されているOFFOLおよびOF-LIST TLVに適用できます。
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".
o 範囲32768-65535の関数コード値は「プライベート使用」用です。
Six objective functions are defined in Section 4 of this document and have been assigned by IANA:
このドキュメントのセクション4で6つの目的関数が定義されており、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は、PCEPオブジェクトコードポイントレジストリを管理します（[RFC5440]を参照）。これは、「PATH計算要素プロトコル（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:
このドキュメントでは、PCREQおよびPCREPメッセージで伝達される新しいPCEPオブジェクト、OFオブジェクトを定義します。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は、PCEP TLVコードポイントレジストリを管理します（[RFC5440]を参照）。これは、「PATH計算要素プロトコル（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:
このドキュメントでは、オープンオブジェクトに運ばれる新しい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メッセージで使用するためのエラータイプとエラー値のレジストリを維持しています。これは、「PATH計算要素プロトコル（PCEP）番号」レジストリの「PCEP-ERRORオブジェクトエラータイプと値」のサブレジストリとして維持されます。
Two new Error-values are defined for the Error-type "policy violation" (type 5):
エラータイプの「ポリシー違反」（タイプ5）に対して2つの新しいエラー価値が定義されています。
Error-type Meaning and error values Reference
------------------------------------------------------------------
5 Policy violation
Error-value=3: objective function not RFC 5541 allowed (request rejected)
エラー値= 3：目的関数はRFC 5541許可されていません（リクエスト拒否）
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は、「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.
このドキュメントでは、メトリックオブジェクトの4つの新しいメトリックタイプが定義されています（[RFC5440]で指定）。IANAは、「Path Computation Element Protocol（PCEP）番号」レジストリの「メトリックオブジェクト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].
このドキュメントでは、[RFC5440]で説明されているメカニズムを使用して、オプションでPCEPメッセージに携帯する可能性のある単一の新しいオブジェクトを導入します。
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メッセージが攻撃に対して脆弱である場合（たとえば、セキュリティメカニズムが使用されていないため）、Offは攻撃の一部として使用できます。ただし、この場合、他のオブジェクトが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.
著者は、Jerry Ash、Fabien Verhaeghe、Robert Sparks、およびAdrian Farrelの有用なコメントに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、Jp。、ed。、およびJl。Le Roux、ed。、「パス計算要素（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] Ash、J.、ed。、およびJ. Le Roux、ed。、「Path Computation Element（PCE）通信プロトコルジェネリック要件」、RFC 4657、2006年9月。
[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
[RFC4674] Le Roux、J.、ed。、「Path Computation Element（PCE）Discoveryの要件」、RFC 4674、2006年10月。
[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] Le Roux、Jl。、ed。、vasseur、Jp。、ed。、Ikejiri、Y.、およびR. Zhang、「Path Computation Element（PCE）DiscoveryのOSPFプロトコル拡張」、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] Le Roux、Jl。、ed。、vasseur、Jp。、ed。、Ikejiri、Y.、およびR. Zhang、「IS-IS Path Computation Element（PCE）DiscoveryのISプロトコル拡張」、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] Lee、Y.、Le Roux、Jl。、King、D。、およびE. Oki、「パス計算要素通信プロトコル（PCEP）要件とプロトコル拡張がグローバルな同時最適化をサポートする」、進行中の作業、2009年3月。
[PCEP-MIB] Koushik, K., and E. Stephan, "PCE Communication Protocol (PCEP) Management Information Base", Work in Progress, January 2009.
[PCEP-MIB] Koushik、K。、およびE. Stephan、「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] Farrel、A。、「ルーティングバックスノーフォーム（RBNF） - さまざまなルーティングプロトコル仕様でエンコーディングルールを形成するために使用される構文」、RFC 5511、2009年4月。
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.
Copyright（c）2009 IETF TrustおよびCodeの著者として特定された人。全著作権所有。
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.
このソフトウェアは、著作権所有者と貢献者によって「現状のまま」、および商品性と特定の目的に対する適合性の暗黙の保証を含むがこれらに限定されない明示的または黙示的な保証が否認されます。いかなる場合でも、著作権所有者または貢献者は、直接的、間接的、偶発的、特別な、模範的、または結果的な損害（代替品またはサービスの調達を含むがこれらに限定されない、使用の損失、データ、または利益に対して責任を負いません。ただし、契約、厳格責任、または不法行為（過失などを含む）であろうと、このソフトウェアの使用から何らかの形で発生するかどうかにかかわらず、責任の理論に起因します。
<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 Le Roux France Telecom 2、Avenue Pierre-Marzin Lannion 22307 France
EMail: jeanlouis.leroux@orange-ftgroup.com
Jean-Philippe Vasseur Cisco Systems, Inc 11, Rue Camille Desmoulins L'Atlantis 92782 Issy Les Moulineaux France
Jean-Philippe Vasseur Cisco Systems、Inc 11、Rue Camille Desmoulins L'Atlantis 92782 Issy Les Moulineaux France
EMail: jpv@cisco.com
Young Lee Huawei Technologies, LTD. 1700 Alma Drive, Suite 100 Plano, TX 75075 USA
Young Lee Huawei Technologies、Ltd。1700 Alma Drive、Suite 100 Plano、TX 75075 USA
EMail: ylee@huawei.com