Network Working Group JP. Vasseur, Ed.
Request for Comments: 5440 Cisco Systems
Category: Standards Track JL. Le Roux, Ed.
France Telecom
March 2009
Path Computation Element (PCE) 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
抽象
This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future.
この文書では、パス計算クライアント（PCC）とPCEの間、または2つのPCE間の通信のための経路計算エレメント（PCE）通信プロトコル（PCEP）を指定します。このような相互作用は、経路計算要求を含めると、経路計算の回答だけでなく、マルチプロトコルラベルスイッチング（MPLS）と一般化MPLS（GMPLS）交通工学文脈におけるPCEの使用に関連する特定の状態の通知。将来的に発現させることが必要条件をさらにべきPCEPは、容易にさらにメッセージやオブジェクトの追加を可能にするように柔軟で拡張可能であるように設計されています。
Table of Contents
目次
1. Introduction ....................................................5
1.1. Requirements Language ......................................5
2. Terminology .....................................................5
3. Assumptions .....................................................6
4. Architectural Protocol Overview (Model) .........................7
4.1. Problem ....................................................7
4.2. Architectural Protocol Overview ............................7
4.2.1. Initialization Phase ................................8
4.2.2. Session Keepalive ...................................9
4.2.3. Path Computation Request Sent by a PCC to a PCE ....10
4.2.4. Path Computation Reply Sent by The PCE to a PCC ....11
4.2.5. Notification .......................................12
4.2.6. Error ..............................................14
4.2.7. Termination of the PCEP Session ....................14
4.2.8. Intermittent versus Permanent PCEP Session .........15
5. Transport Protocol .............................................15
6. PCEP Messages ..................................................15
6.1. Common Header .............................................16
6.2. Open Message ..............................................16
6.3. Keepalive Message .........................................18
6.4. Path Computation Request (PCReq) Message ..................19
6.5. Path Computation Reply (PCRep) Message ....................20
6.6. Notification (PCNtf) Message ..............................21
6.7. Error (PCErr) Message .....................................22
6.8. Close Message .............................................23
6.9. Reception of Unknown Messages .............................23
7. Object Formats .................................................23
7.1. PCEP TLV Format ...........................................24
7.2. Common Object Header ......................................24
7.3. OPEN Object ...............................................25
7.4. RP Object .................................................27
7.4.1. Object Definition ..................................27
7.4.2. Handling of the RP Object ..........................30
7.5. NO-PATH Object ............................................31
7.6. END-POINTS Object .........................................34
7.7. BANDWIDTH Object ..........................................35
7.8. METRIC Object .............................................36
7.9. Explicit Route Object .....................................39
7.10. Reported Route Object ....................................39
7.11. LSPA Object ..............................................40
7.12. Include Route Object .....................................42
7.13. SVEC Object ..............................................42
7.13.1. Notion of Dependent and Synchronized Path
Computation Requests ..............................42
7.13.2. SVEC Object .......................................44
7.13.3. Handling of the SVEC Object .......................45
7.14. NOTIFICATION Object ......................................46
7.15. PCEP-ERROR Object ........................................49
7.16. LOAD-BALANCING Object ....................................54
7.17. CLOSE Object .............................................55
8. Manageability Considerations ...................................56
8.1. Control of Function and Policy ............................56
8.2. Information and Data Models ...............................57
8.3. Liveness Detection and Monitoring .........................57
8.4. Verifying Correct Operation ...............................58
8.5. Requirements on Other Protocols and Functional
Components ................................................58
8.6. Impact on Network Operation ...............................58
9. IANA Considerations ............................................59
9.1. TCP Port ..................................................59
9.2. PCEP Messages .............................................59
9.3. PCEP Object ...............................................59
9.4. PCEP Message Common Header ................................61
9.5. Open Object Flag Field ....................................61
9.6. RP Object .................................................61
9.7. NO-PATH Object Flag Field .................................62
9.8. METRIC Object .............................................63
9.9. LSPA Object Flag Field ....................................63
9.10. SVEC Object Flag Field ...................................64
9.11. NOTIFICATION Object ......................................64
9.12. PCEP-ERROR Object ........................................65
9.13. LOAD-BALANCING Object Flag Field .........................67
9.14. CLOSE Object .............................................67
9.15. PCEP TLV Type Indicators .................................68
9.16. NO-PATH-VECTOR TLV .......................................68
10. Security Considerations .......................................69
10.1. Vulnerability ............................................69
10.2. TCP Security Techniques ..................................70
10.3. PCEP Authentication and Integrity ........................70
10.4. PCEP Privacy .............................................71
10.5. Key Configuration and Exchange ...........................71
10.6. Access Policy ............................................73
10.7. Protection against Denial-of-Service Attacks .............73
10.7.1. Protection against TCP DoS Attacks ................73
10.7.2. Request Input Shaping/Policing ....................74
11. Acknowledgments ...............................................75
12. References ....................................................75
12.1. Normative References .....................................75
12.2. Informative References ...................................76
Appendix A. PCEP Finite State Machine (FSM) ......................79
Appendix B. PCEP Variables .......................................85
Appendix C. Contributors .........................................86
[RFC4655] describes the motivations and architecture for a Path Computation Element (PCE) based model for the computation of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs). The model allows for the separation of PCE from Path Computation Client (PCC), and allows for the cooperation between PCEs. This necessitates a communication protocol between PCC and PCE, and between PCEs. [RFC4657] states the generic requirements for such a protocol including that the same protocol be used between PCC and PCE, and between PCEs. Additional application-specific requirements (for scenarios such as inter-area, inter-AS, etc.) are not included in [RFC4657], but there is a requirement that any solution protocol must be easily extensible to handle other requirements as they are introduced in application-specific requirements documents. Examples of such application-specific requirements are [RFC4927], [RFC5376], and [INTER-LAYER].
[RFC4655]はパス計算要素（PCE）ベース（MPLS）をマルチプロトコルラベルスイッチングの計算のためのモデルと汎用MPLS（GMPLS）のための動機とアーキテクチャは、トラフィックエンジニアリングラベルパス（TE LSPを）スイッチが記載されています。モデルは、経路計算クライアント（PCC）からPCEの分離を可能にし、のPCE間の協力を可能にします。これはPCCとPCEとの間、及びのPCE間の通信プロトコルを必要とします。 [RFC4657]は同じプロトコルはPCCとPCEとのPCEの間に使用することを含む、そのようなプロトコルのための一般的な要件を述べています。 （等間領域、インターASなどシナリオの）追加のアプリケーション固有の要件は、[RFC4657]に含まれていないが、それらが導入される任意の溶液プロトコルは、他の要件を処理するために容易に拡張可能でなければならないという要件がありますアプリケーション固有の要件文書インチそのようなアプリケーション固有の要件の例は、[RFC4927]、[RFC5376]、および[INTER-LAYER]です。
This document specifies the Path Computation Element Protocol (PCEP) for communications between a PCC and a PCE, or between two PCEs, in compliance with [RFC4657]. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of MPLS and GMPLS Traffic Engineering.
このドキュメントは[RFC4657]に準拠して、PCC及びPCE、又は二のPCE間の間の通信のためのパス計算エレメントプロトコル（PCEP）を指定します。そのような相互作用は、経路計算リクエストを含み、経路計算は同様にMPLSとGMPLSトラヒックエンジニアリングの文脈におけるPCEの使用に関連する特定の状態の通知を返信します。
PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future.
将来的に発現させることが必要条件をさらにべきPCEPは、容易にさらにメッセージやオブジェクトの追加を可能にするように柔軟で拡張可能であるように設計されています。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The following terminology is used in this document.
以下の用語は、この文書で使用されています。
AS: Autonomous System.
AS：自律システム。
Explicit path: Full explicit path from start to destination; made of a list of strict hops where a hop may be an abstract node such as an AS.
明示的なパス：開始から目的地までのフル明示的なパス。ホップがASのような抽象ノードであってもよい厳密ホップのリストからなります。
IGP area: OSPF area or IS-IS level.
IGPエリア：OSPFエリアまたはIS-ISレベル。
Inter-domain TE LSP: A TE LSP whose path transits at least two different domains where a domain can be an IGP area, an Autonomous System, or a sub-AS (BGP confederation).
ドメイン間TE LSP：その経路ドメインはIGP領域、自律システム、またはサブAS（BGP連合）とすることができる少なくとも2つの異なるドメインを通過するTE LSP。
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 applying computational constraints.
PCE：パス計算要素。ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用することが可能なエンティティ（コンポーネント、アプリケーション、またはネットワークノード）。
PCEP Peer: An element involved in a PCEP session (i.e., a PCC or a PCE).
PCEPピア：PCEPセッションに関与する要素（すなわち、PCC又はPCE）。
TED: Traffic Engineering Database that contains the topology and resource information of the domain. The TED may be fed by IGP extensions or potentially by other means.
TED：ドメインのトポロジーおよびリソース情報が含まれているトラフィックエンジニアリングデータベース。 TEDは、IGPの拡張によって、または潜在的に他の手段によって供給されてもよいです。
TE LSP: Traffic Engineering Label Switched Path.
TE LSP：トラフィックエンジニアリングラベルスイッチパス。
Strict/loose path: A mix of strict and loose hops comprising at least one loose hop representing the destination where a hop may be an abstract node such as an AS.
厳密/緩いパス：ホップはASなどの抽象ノードとすることができる宛先を表す少なくとも一つのルーズホップを含む厳格な緩いホップミックス。
Within this document, when describing PCE-PCE communications, the requesting PCE fills the role of a PCC. This provides a saving in documentation without loss of function.
PCE-PCE通信を記述する場合、この文書内で、要求PCEは、PCCの役割を満たします。これは、機能を失うことなくドキュメントの節約を提供します。
The message formats in this document are specified using Backus-Naur Format (BNF) encoding as specified in [RBNF].
【RBNF]で指定されるように、この文書に記載されているメッセージ形式は、バッカス正規形式（BNF）エンコーディングを使用して指定されます。
[RFC4655] describes various types of PCE. PCEP does not make any assumption about, and thus does not impose any constraint on, the nature of the PCE.
[RFC4655]はPCEの様々な種類を記載しています。 PCEPは、およそあらゆる仮定をしないので、PCEの性質上、上の任意の制約を課しません。
Moreover, it is assumed that the PCE has the required information (usually including network topology and resource information) so as to perform the computation of a path for a TE LSP. Such information can be gathered by routing protocols or by some other means. The way in which the information is gathered is out of the scope of this document.
また、TE LSPのためのパスの計算を実行するように、PCEは、（通常、ネットワークトポロジーおよびリソース情報を含む）必要な情報を有しているものとします。このような情報は、ルーティングプロトコルによってまたは他の手段によって収集することができます。情報が収集される方法は、この文書の範囲外です。
Similarly, no assumption is made about the discovery method used by a PCC to discover a set of PCEs (e.g., via static configuration or dynamic discovery) and on the algorithm used to select a PCE. For reference, [RFC4674] defines a list of requirements for dynamic PCE discovery and IGP-based solutions for such PCE discovery are specified in [RFC5088] and [RFC5089].
同様に、何の仮定は（静的構成または動的な発見を介して、例えば、）のPCEのセットを発見するPCCによって使用される検出方法については、PCEを選択するために使用されるアルゴリズムになされていません。参考のために、[RFC4674]は動的PCE発見のための要件のリストを定義し、そのようなPCE発見のためのIGPベースのソリューションは、[RFC5088]及び[RFC5089]で指定されています。
The aim of this section is to describe the PCEP model in the spirit of [RFC4101]. An architectural protocol overview (the big picture of the protocol) is provided in this section. Protocol details can be found in further sections.
このセクションの目的は、[RFC4101]の精神にPCEPモデルを記述することです。アーキテクチャプロトコルの概要（プロトコルの全体像）をこのセクションで提供されています。プロトコルの詳細は、さらにセクションに記載されています。
The PCE-based architecture used for the computation of paths for MPLS and GMPLS TE LSPs is described in [RFC4655]. When the PCC and the PCE are not collocated, a communication protocol between the PCC and the PCE is needed. PCEP is such a protocol designed specifically for communications between a PCC and a PCE or between two PCEs in compliance with [RFC4657]: a PCC may use PCEP to send a path computation request for one or more TE LSPs to a PCE, and the PCE may reply with a set of computed paths if one or more paths can be found that satisfies the set of constraints.
MPLSとGMPLS TE LSPのためのパスの計算に用いPCEベースのアーキテクチャは、[RFC4655]に記載されています。 PCCとPCEが並置されていない場合、PCCとPCEとの間の通信プロトコルが必要です。 PCCは、PCEへの1つ以上のTE LSPのためのパス計算要求を送信するPCEPを使用することができ、及びPCE：PCEPはPCCとPCEとの間、または[RFC4657]に準拠における2つのPCE間の通信のために特別に設計されたそのようなプロトコルであります1つ以上のパスが制約のセットを満足することがわかる場合に計算パスのセットで応答することができます。
PCEP operates over TCP, which fulfills the requirements for reliable messaging and flow control without further protocol work.
PCEPは、さらに、プロトコル作業をせずに信頼性の高いメッセージングおよびフロー制御のための要件を満たしてTCP上で動作します。
Several PCEP messages are defined:
いくつかのPCEPのメッセージが定義されています。
o Open and Keepalive messages are used to initiate and maintain a PCEP session, respectively.
O開いてキープアライブメッセージは、それぞれ、PCEPセッションを開始し、維持するために使用されます。
o PCReq: a PCEP message sent by a PCC to a PCE to request a path computation.
O PCReq：PCEにPCCによって送らPCEPメッセージは、経路計算を要求します。
o PCRep: a PCEP message sent by a PCE to a PCC in reply to a path computation request. A PCRep message can contain either a set of computed paths if the request can be satisfied, or a negative reply if not. The negative reply may indicate the reason why no path could be found.
O PCRep：経路計算要求に対する応答でPCCへPCEによって送信されたPCEPメッセージ。 PCRepメッセージは、要求を満たすことができる場合に計算されたパスのセット、又は負応答ない場合のいずれかを含むことができます。負の回答にはパスが見つかりませんでした理由を示すことがあります。
o PCNtf: a PCEP notification message either sent by a PCC to a PCE or sent by a PCE to a PCC to notify of a specific event.
O PCNtf：PCEP通知メッセージPCEにPCCによって送信されるか、または特定のイベントを通知するPCCとPCEによって送信されたいずれか。
o PCErr: a PCEP message sent upon the occurrence of a protocol error condition.
O PCErr：プロトコル・エラー条件の発生時に送信されたメッセージPCEP。
o Close message: a message used to close a PCEP session.
O閉じるメッセージ：PCEPセッションを閉じるために使用されるメッセージ。
The set of available PCEs may be either statically configured on a PCC or dynamically discovered. The mechanisms used to discover one or more PCEs and to select a PCE are out of the scope of this document.
利用可能なのPCEのセットは、静的PCC上で設定または動的に発見することができます。一の以上のPCEを発見し、PCEを選択するために使用されるメカニズムはこの文書の範囲外です。
A PCC may have PCEP sessions with more than one PCE, and similarly a PCE may have PCEP sessions with multiple PCCs.
PCCは、複数のPCEとPCEPセッションを有していてもよく、同様PCEは、複数のPCCとPCEPセッションを有していてもよいです。
Each PCEP message is regarded as a single transmission unit and parts of messages MUST NOT be interleaved. So, for example, a PCC sending a PCReq and wishing to close the session, must complete sending the request message before starting to send a Close message.
各PCEPメッセージは、単一の送信単位とみなされ、メッセージの部分は、インターリーブされてはいけません。したがって、たとえば、PCC PCReqを送信してセッションを終了したいが、閉じるメッセージを送信するために開始する前に要求メッセージを送信完了する必要があります。
The initialization phase consists of two successive steps (described in a schematic form in Figure 1):
初期化段階は、2つの連続工程（図1に概略的に記載されている）から構成されています。
1) Establishment of a TCP connection (3-way handshake) between the PCC and the PCE.
PCCとPCEとの間のTCP接続（3ウェイハンドシェイク）の1）設立。
2) Establishment of a PCEP session over the TCP connection.
TCP接続を介してPCEPセッションの2）設立。
Once the TCP connection is established, the PCC and the PCE (also referred to as "PCEP peers") initiate PCEP session establishment during which various session parameters are negotiated. These parameters are carried within Open messages and include the Keepalive timer, the DeadTimer, and potentially other detailed capabilities and policy rules that specify the conditions under which path computation requests may be sent to the PCE. If the PCEP session establishment phase fails because the PCEP peers disagree on the session parameters or one of the PCEP peers does not answer after the expiration of the establishment timer, the TCP connection is immediately closed. Successive retries are permitted but an implementation should make use of an exponential back-off session establishment retry procedure.
TCP接続が確立されると、PCC及びPCEは、（また、「PCEPピア」と呼ぶ）は、様々なセッションパラメータをネゴシエートされる間PCEPセッションの確立を開始します。これらのパラメータは、オープンメッセージ内で運ばれ、潜在的にキープアライブタイマー、DeadTimer、および経路計算リクエストがPCEに送信することができる条件を指定する他の詳細な機能とポリシールールが含まれます。 PCEPピアが確立タイマの満了後に応答しないセッション・パラメータまたはPCEPピアの1つに一致しないので、PCEPセッション確立フェーズが失敗した場合、TCP接続はすぐに閉じられています。歴代の再試行が許可されているが、実装は、指数バックオフセッション確立再試行手続きを利用する必要があります。
Keepalive messages are used to acknowledge Open messages, and are used once the PCEP session has been successfully established.
キープアライブメッセージはオープンメッセージを確認するために使用され、PCEPセッションが正常に確立された後に使用されています。
Only one PCEP session can exist between a pair of PCEP peers at any one time. Only one TCP connection on the PCEP port can exist between a pair of PCEP peers at any one time.
唯一PCEPセッションは、一度にPCEPピアの対の間に存在することができます。 PCEPポート上の1つのTCP接続だけは、一度にPCEPピアのペアの間に存在することができます。
Details about the Open message and the Keepalive message can be found in Sections 6.2 and 6.3, respectively.
オープンメッセージおよびキープアライブメッセージの詳細については、それぞれ、セクション6.2および6.3に見出すことができます。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| Open msg |
|-------- |
| \ Open msg |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ Keepalive|
| --------|
|Keepalive / |
|-------- / |
| \/ |
| /\ |
|<------ ---------->|
| |
Figure 1: PCEP Initialization Phase (Initiated by a PCC)
図1：PCEP初期化フェーズ（PCCによって開始されます）
(Note that once the PCEP session is established, the exchange of Keepalive messages is optional.)
（PCEPセッションが確立されると、キープアライブメッセージの交換が任意であることに注意してください。）
Once a session has been established, a PCE or PCC may want to know that its PCEP peer is still available for use.
セッションが確立されると、PCEかPCCは、そのPCEPピアがまだ使用可能であることを知ってほしいことがあります。
It can rely on TCP for this information, but it is possible that the remote PCEP function has failed without disturbing the TCP connection. It is also possible to rely on the mechanisms built into the TCP implementations, but these might not provide failure notifications that are sufficiently timely. Lastly, a PCC could wait until it has a path computation request to send and could use its failed transmission or the failure to receive a response as evidence that the session has failed, but this is clearly inefficient.
それは、この情報については、TCPに頼ることができますが、リモートPCEP機能は、TCP接続を妨害することなく失敗している可能性があります。 TCPの実装に組み込まれたメカニズムに依存することも可能であるが、これらは十分にタイムリーにある障害通知を提供しない場合があります。それが送信する経路計算要求を有し、その送信失敗またはセッションが失敗したことを証拠として応答を受信するために失敗を使用することができますが、これは明らかに非効率的になるまで最後に、PCCは待つことができます。
In order to handle this situation, PCEP includes a keepalive mechanism based on a Keepalive timer, a DeadTimer, and a Keepalive message.
この状況に対処するためには、PCEPはキープアライブタイマー、DeadTimer、およびキープアライブメッセージに基づいて、キープアライブ機構を備えています。
Each end of a PCEP session runs a Keepalive timer. It restarts the timer every time it sends a message on the session. When the timer expires, it sends a Keepalive message. Other traffic may serve as Keepalive (see Section 6.3).
PCEPセッションの各端部は、キープアライブタイマーが実行されます。これは、タイマーがセッションにメッセージを送信するたびに再起動します。タイマーの期限が切れると、それはキープアライブメッセージを送信します。他のトラフィックは、キープアライブ（6.3節を参照）として機能することができます。
The ends of the PCEP session also run DeadTimers, and they restart the timers whenever a message is received on the session. If one end of the session receives no message before the DeadTimer expires, it declares the session dead.
PCEPセッションの終了もDeadTimersを実行し、メッセージがセッション上で受信されるたびに、彼らはタイマーを再起動してください。 DeadTimerの有効期限が切れる前に、セッションの一端は何のメッセージを受信しない場合、それは死んでセッションを宣言します。
Note that this means that the Keepalive message is unresponded and does not form part of a two-way keepalive handshake as used in some protocols. Also note that the mechanism is designed to reduce to a minimum the amount of keepalive traffic on the session.
これは、キープアライブメッセージがunrespondedされていることを意味し、いくつかのプロトコルで使用される双方向キープアライブハンドシェークの一部を形成しないことに留意されたいです。また、メカニズムを最小限にセッションのキープアライブトラフィックの量を減らすように設計されていることに注意してください。
The keepalive traffic on the session may be unbalanced according to the requirements of the session ends. Each end of the session can specify (on an Open message) the Keepalive timer that it will use (i.e., how often it will transmit a Keepalive message if there is no other traffic) and a DeadTimer that it recommends its peer to use (i.e., how long the peer should wait before declaring the session dead if it receives no traffic). The session ends may use different Keepalive timer values.
セッションのキープアライブトラフィックは、セッション終了の要件に応じてアンバランスになることがあります。セッションの各端部は、（オープンメッセージに）それが使用するキープアライブタイマーを指定することができます（つまり、それは他のトラフィックがない場合はキープアライブメッセージを送信する頻度）とDeadTimerそれはそのピアが使用することを推奨していること（つまり、それは、トラフィックを受信しない場合、どのくらいピア）は、セッションが死んで宣言する前に待機しなければなりません。セッションが終了するには、さまざまなキープアライブタイマー値を使用することができます。
The minimum value of the Keepalive timer is 1 second, and it is specified in units of 1 second. The recommended default value is 30 seconds. The timer may be disabled by setting it to zero.
キープアライブタイマーの最小値は1秒であり、それは1秒単位で指定されています。推奨されるデフォルト値は30秒です。タイマーがゼロに設定することで無効にすることができます。
The recommended default for the DeadTimer is 4 times the value of the Keepalive timer used by the remote peer. This means that there is never any risk of congesting TCP with excessive Keepalive messages.
DeadTimerのための推奨されるデフォルトでは、リモートピアで使用されるキープアライブタイマーの4倍の値です。これは、過度のキープアライブメッセージをTCPの輻輳のいずれかのリスクが決してないことを意味します。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request sent to | |
the selected PCE | |
Figure 2: Path Computation Request
図2：経路計算要求
Once a PCC has successfully established a PCEP session with one or more PCEs, if an event is triggered that requires the computation of a set of paths, the PCC first selects one or more PCEs. Note that the PCE selection decision process may have taken place prior to the PCEP session establishment.
イベントは、パスのセットの計算を必要とするトリガされた場合PCCが正常に、一の以上のPCEとPCEPセッションを確立した後、PCCは、第一又は複数のPCEを選択します。 PCE選択決定プロセスの前PCEPセッション確立に行われた可能性があることに注意してください。
Once the PCC has selected a PCE, it sends a path computation request to the PCE (PCReq message) that contains a variety of objects that specify the set of constraints and attributes for the path to be computed. For example, "Compute a TE LSP path with source IP address=x.y.z.t, destination IP address=x'.y'.z'.t', bandwidth=B Mbit/s, Setup/Holding priority=P, ...". Additionally, the PCC may desire to specify the urgency of such request by assigning a request priority. Each request is uniquely identified by a request-id number and the PCC-PCE address pair. The process is shown in a schematic form in Figure 2.
PCCは、PCEを選択すると、それは、制約のセットを指定するさまざまなオブジェクトを含み、経路が計算される属性PCE（PCReqメッセージ）への経路計算要求を送信します。例えば、 "送信元IPアドレスでTE LSPの経路を計算= xyzt、宛先IPアドレス= x'.y'.z'.t」、帯域幅= Bメガビット/秒、設定/保持優先度= P、..." 。また、PCCは、要求の優先順位を割り当てることによって、そのような要求の緊急度を指定することを望むかもしれません。各要求は、一意のリクエストID番号とPCC-PCEアドレスのペアによって識別されます。プロセスは、図2に概略的に示されています。
Note that multiple path computation requests may be outstanding from a PCC to a PCE at any time.
複数の経路計算要求はいつでもPCEにPCCから未処理であってもよいことに留意されたいです。
Details about the PCReq message can be found in Section 6.4.
PCReqメッセージの詳細については、セクション6.4に記載されています。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---- PCReq message--->|
| |1) Path computation
| | request received
| |
| |2) Path successfully
| | computed
| |
| |3) Computed paths
| | sent to the PCC
| |
|<--- PCRep message ---|
| (Positive reply) |
Figure 3a: Path Computation Request With Successful Path Computation
図3a：成功した経路計算と経路計算要求
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| |
|---- PCReq message--->|
| |1) Path computation
| | request received
| |
| |2) No Path found that
| | satisfies the request
| |
| |3) Negative reply sent to
| | the PCC (optionally with
| | various additional
| | information)
|<--- PCRep message ---|
| (Negative reply) |
Figure 3b: Path Computation Request With Unsuccessful Path Computation
図3b：失敗した経路計算で経路計算要求
Upon receiving a path computation request from a PCC, the PCE triggers a path computation, the result of which can be either:
PCCからパス計算要求を受信すると、PCEは、経路計算をトリガし、その結果、それらのいずれかとすることができます。
o Positive (Figure 3a): the PCE manages to compute a path that satisfies the set of required constraints. In this case, the PCE returns the set of computed paths to the requesting PCC. Note that PCEP supports the capability to send a single request that requires the computation of more than one path (e.g., computation of a set of link-diverse paths).
O正（図3A）：PCEは、必要な制約条件のセットを満たす経路を計算するために管理します。この場合、PCEは、要求PCCを計算パスのセットを返します。 PCEPは、複数のパス（リンク多様な経路の組の例えば、計算）の計算を必要とする単一の要求を送信する機能をサポートしていることに注意してください。
o Negative (Figure 3b): no path could be found that satisfies the set of constraints. In this case, a PCE may provide the set of constraints that led to the path computation failure. Upon receiving a negative reply, a PCC may decide to resend a modified request or take any other appropriate action.
O負（図3B）：なしパスは、制約のセットを満足する見つかりませんでした。この場合、PCEは、経路計算故障につながった制約のセットを提供することができます。負の応答を受信すると、PCCは、変更要求を再送信または任意の他の適切な行動を取ることを決定することができます。
Details about the PCRep message can be found in Section 6.5.
PCRepメッセージの詳細については、セクション6.5に記載されています。
There are several circumstances in which a PCE may want to notify a PCC of a specific event. For example, suppose that the PCE suddenly gets overloaded, potentially leading to unacceptable response times. The PCE may want to notify one or more PCCs that some of their requests (listed in the notification) will not be satisfied or may experience unacceptable delays. Upon receiving such notification, the PCC may decide to redirect its path computation requests to another PCE should an alternate PCE be available. Similarly, a PCC may desire to notify a PCE of a particular event such as the cancellation of pending requests.
PCEは、特定のイベントのPCCを通知したい場合がある、いくつかの状況があります。例えば、潜在的に容認できない応答時間につながる、PCEが突然過負荷にされることを仮定します。 PCEは満足できなくなります（通知に記載されている）彼らの要求のいくつかの1つのまたは複数のPCCに通知することもできますまたは容認できない遅延が発生することがあります。そのような通知を受信すると、PCCは、代替PCEが利用可能でなければならない別のPCEへの経路計算要求をリダイレクトすることを決定することができます。同様に、PCCは、保留中の要求の取り消しなどの特定のイベントのPCEに通知することを望むかもしれません。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request X sent to | |4) Path computation
the selected PCE | | request queued
| |
| |
5) Path computation | |
request X cancelled| |
|---- PCNtf message -->|
| |6) Path computation
| | request X cancelled
Figure 4: Example of PCC Notification (Cancellation Notification) Sent to a PCE
図4：PCEに送信PCC通知（解除通知）の例
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request X sent to | |4) Path computation
the selected PCE | | request queued
| |
| |
| |5) PCE gets overloaded
| |
| |
| |6) Path computation
| | request X cancelled
| |
|<--- PCNtf message----|
Figure 5: Example of PCE Notification (Cancellation Notification) Sent to a PCC
図5：PCCに送信PCE通知（解除通知）の例
Details about the PCNtf message can be found in Section 6.6.
PCNtfメッセージの詳細については、セクション6.6に記載されています。
The PCEP Error message (also referred to as a PCErr message) is sent in several situations: when a protocol error condition is met or when the request is not compliant with the PCEP specification (e.g., capability not supported, reception of a message with a mandatory missing object, policy violation, unexpected message, unknown request reference).
（またPCErrメッセージと呼ぶ）PCEPエラーメッセージがいくつかの状況で送信される：プロトコルエラー条件が満たされたとき、または要求がPCEP仕様（例えば、能力はサポートされていません、とのメッセージの受信に準拠していない場合必須不足しているオブジェクト、ポリシー違反、予期しないメッセージ、未知の要求参照）。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request X sent to | |4) Reception of a
the selected PCE | | malformed object
| |
| |5) Request discarded
| |
|<-- PCErr message ---|
| |
Figure 6: Example of Error Message Sent by a PCE to a PCC in Reply to the Reception of a Malformed Object
図6：不正なオブジェクトの受信に応答内のPCCにPCEによって送信されるエラーメッセージの例
Details about the PCErr message can be found in Section 6.7.
PCErrメッセージの詳細については、6.7節に記載されています。
When one of the PCEP peers desires to terminate a PCEP session it first sends a PCEP Close message and then closes the TCP connection. If the PCEP session is terminated by the PCE, the PCC clears all the states related to pending requests previously sent to the PCE. Similarly, if the PCC terminates a PCEP session, the PCE clears all pending path computation requests sent by the PCC in question as well as the related states. A Close message can only be sent to terminate a PCEP session if the PCEP session has previously been established.
PCEPピアの1つは、PCEPセッションを終了したい場合は、まずPCEP閉じるメッセージを送信し、TCP接続を閉じます。 PCEPセッションがPCEで終了した場合、PCCは、以前PCEに送信された保留中の要求に関連するすべての状態をクリアします。 PCCは、PCEPセッションを終了した場合も同様に、PCEは、問題のPCCだけでなく、関連する状態で送信されたすべての保留中の経路計算要求をクリアします。クローズメッセージは、PCEPセッションが以前に確立された場合PCEPセッションを終了するために送信することができます。
In case of TCP connection failure, the PCEP session is immediately terminated.
TCP接続に失敗した場合には、PCEPセッションはすぐに終了します。
Details about the Close message can be found in Section 6.8.
閉じるメッセージについての詳細は、6.8節に記載されています。
An implementation may decide to keep the PCEP session alive (and thus the corresponding TCP connection) for an unlimited time. (For instance, this may be appropriate when path computation requests are sent on a frequent basis so as to avoid opening a TCP connection each time a path computation request is needed, which would incur additional processing delays.) Conversely, in some other circumstances, it may be desirable to systematically open and close a PCEP session for each PCEP request (for instance, when sending a path computation request is a rare event).
実装は、無制限の時間のために生きている（したがって、対応するTCPコネクション）PCEPセッションを維持するように決定することができます。 （TCPコネクションの追加の処理遅延を招くことになる経路計算要求が必要とされるたびに、開く回避するように経路計算要求が頻繁に送信された場合例えば、これは適切であるかもしれない。）逆に、いくつかの他の状況において、それは系統的オープンすることが望ましいことが、各PCEP要求のPCEPセッションを閉じることができる（例えば、経路計算リクエストを送信するときにはまれな事象です）。
PCEP operates over TCP using a registered TCP port (4189). This allows the requirements of reliable messaging and flow control to be met without further protocol work. All PCEP messages MUST be sent using the registered TCP port for the source and destination TCP port.
PCEPは、登録されたTCPポート（4189）を使用して、TCP上で動作します。これは、信頼性の高いメッセージングおよびフロー制御の要件はさらにプロトコル作業をせずに満たすことができるようになります。すべてのPCEPメッセージは、送信元と宛先TCPポートの登録TCPポートを使用させなければなりません。
A PCEP message consists of a common header followed by a variable-length body made of a set of objects that can either be mandatory or optional. In the context of this document, an object is said to be mandatory in a PCEP message when the object MUST be included for the message to be considered valid. A PCEP message with a missing mandatory object MUST trigger an Error message (see Section 7.15). Conversely, if an object is optional, the object may or may not be present.
PCEPメッセージは、必須またはオプションのいずれかであることができるオブジェクトのセットからなる可変長体続い共通ヘッダから成ります。この文書の文脈では、オブジェクトは、オブジェクトが有効と見なされるべきメッセージのために含まなければならない場合PCEPメッセージに必須であると言われています。不足している必須オブジェクトとPCEPメッセージは、エラーメッセージをトリガしなければならない（セクション7.15を参照してください）。オブジェクトがオプションである場合は逆に、オブジェクトがあってもなくてもよいです。
A flag referred to as the P flag is defined in the common header of each PCEP object (see Section 7.2). When this flag is set in an object in a PCReq, the PCE MUST take the information carried in the object into account during the path computation. For example, the METRIC object defined in Section 7.8 allows a PCC to specify a bounded acceptable path cost. The METRIC object is optional, but a PCC may set a flag to ensure that the constraint is taken into account. In this case, if the constraint cannot be taken into account by the PCE, the PCE MUST trigger an Error message.
Pフラグは各PCEPオブジェクトの共通ヘッダに定義されていると呼ばれるフラグ（セクション7.2を参照します）。このフラグがPCReq内のオブジェクトに設定されているとき、PCEは、経路計算時に考慮対象で運ばれた情報を取らなければなりません。例えば、セクション7.8で定義メトリックの目的は、PCCは、境界に許容されるパスコストを指定することを可能にします。 METRICオブジェクトは任意であるが、PCCは制約が考慮されることを確実にするためにフラグを設定することができます。制約はPCEによって考慮することができない場合は、この場合には、PCEは、エラーメッセージをトリガしなければなりません。
For each PCEP message type, rules are defined that specify the set of objects that the message can carry. We use the Backus-Naur Form (BNF) (see [RBNF]) to specify such rules. Square brackets refer to optional sub-sequences. An implementation MUST form the PCEP messages using the object ordering specified in this document.
各PCEPメッセージタイプのために、ルールがそのメッセージを運ぶことができるオブジェクトのセットを指定する定義されています。私たちは、このようなルールを指定するには、バッカス記法（BNF）（[RBNF]を参照）を使用します。角括弧は、オプションのサブ配列を指します。実装はこの文書で指定されたオブジェクトの順序を使用してPCEPメッセージを形成しなければなりません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Flags | Message-Type | Message-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: PCEP Message Common Header
図7：PCEPメッセージ共通ヘッダ
Ver (Version - 3 bits): PCEP version number. Current version is version 1.
版（バージョン - 3ビット）：PCEPバージョン番号。現在のバージョンはバージョン1です。
Flags (5 bits): No flags are currently defined. Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt.
フラグ（5ビット）：なしフラグが現在定義されています。予約済みとして割り当てられていないビットが考慮されます。彼らは、送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
Message-Type (8 bits): The following message types are currently defined:
メッセージタイプ（8ビット）：次のメッセージタイプは、現在定義されています。
Value Meaning
1 Open
2 Keepalive
3 Path Computation Request
4 Path Computation Reply
5 Notification
6 Error
7 Close
Message-Length (16 bits): total length of the PCEP message including the common header, expressed in bytes.
メッセージ長（16ビット）：共通ヘッダを含むPCEPメッセージの総バイト数。
The Open message is a PCEP message sent by a PCC to a PCE and by a PCE to a PCC in order to establish a PCEP session. The Message-Type field of the PCEP common header for the Open message is set to 1.
オープンメッセージは、PCEPセッションを確立するために、PCCにPCEにし、PCEによってPCCによって送られPCEPメッセージです。オープンメッセージのPCEP共通ヘッダのメッセージタイプフィールドが1に設定されています。
Once the TCP connection has been successfully established, the first message sent by the PCC to the PCE or by the PCE to the PCC MUST be an Open message as specified in Appendix A.
TCP接続が正常に確立された後、付録Aで指定されるように、PCEまたはPCCのPCEによってPCCによって送信された最初のメッセージはオープンメッセージでなければなりません
Any message received prior to an Open message MUST trigger a protocol error condition causing a PCErr message to be sent with Error-Type "PCEP session establishment failure" and Error-value "reception of an invalid Open message or a non Open message" and the PCEP session establishment attempt MUST be terminated by closing the TCP connection.
オープンメッセージの前に受信されたすべてのメッセージは、エラータイプ「PCEPセッション確立失敗」とエラー値「無効オープンメッセージまたは非オープンメッセージの受信」とで送信するPCErrメッセージの原因プロトコルエラー状態をトリガしなければなりませんPCEPセッション確立の試行はTCP接続を閉じるで終了する必要があります。
The Open message is used to establish a PCEP session between the PCEP peers. During the establishment phase, the PCEP peers exchange several session characteristics. If both parties agree on such characteristics, the PCEP session is successfully established.
オープンメッセージは、PCEPピア間PCEPセッションを確立するために使用されます。確立フェーズでは、PCEPピアは、いくつかのセッション特性を交換します。両当事者は、このような特性に同意する場合は、PCEPセッションが正常に確立されます。
The format of an Open message is as follows:
次のようにオープンメッセージの形式は次のとおりです。
<Open Message>::= <Common Header>
<OPEN>
The Open message MUST contain exactly one OPEN object (see Section 7.3).
オープンメッセージは、1つのOPENオブジェクト（セクション7.3を参照）を含まなければなりません。
Various session characteristics are specified within the OPEN object. Once the TCP connection has been successfully established, the sender MUST start an initialization timer called OpenWait after the expiration of which, if no Open message has been received, it sends a PCErr message and releases the TCP connection (see Appendix A for details).
様々なセッション特性がOPENオブジェクト内で指定されています。 TCP接続が正常に確立されたら何のオープンメッセージを受信していない場合、送信者は、満了後OpenWaitという初期化タイマーを起動する必要があり、それは、TCP接続（詳細については、付録Aを参照してください）PCErrメッセージやリリースを送信します。
Once an Open message has been sent to a PCEP peer, the sender MUST start an initialization timer called KeepWait after the expiration of which, if neither a Keepalive message has been received nor a PCErr message in case of disagreement of the session characteristics, a PCErr message MUST be sent and the TCP connection MUST be released (see Appendix A for details).
オープンメッセージがPCEPピアに送信された後、送信者は、有効期限の、キープアライブメッセージのいずれも受信もPCErrメッセージセッション特性の不一致の場合されている場合は、PCErr後KeepWaitという初期化タイマーを起動する必要があります（詳細については、付録Aを参照してください）メッセージを送らなければなりませんし、TCP接続が解放されなければなりません。
The OpenWait and KeepWait timers have a fixed value of 1 minute.
OpenWaitとKeepWaitタイマーは1分の固定値を持っています。
Upon the receipt of an Open message, the receiving PCEP peer MUST determine whether the suggested PCEP session characteristics are acceptable. If at least one of the characteristics is not acceptable to the receiving peer, it MUST send an Error message. The Error message SHOULD also contain the related OPEN object and, for each unacceptable session parameter, an acceptable parameter value SHOULD be proposed in the appropriate field of the OPEN object in place of the originally proposed value. The PCEP peer MAY decide to resend an Open message with different session characteristics. If a second Open message is received with the same set of parameters or with parameters that are still unacceptable, the receiving peer MUST send an Error message and it MUST immediately close the TCP connection. Details about error messages can be found in Section 7.15. Successive retries are permitted, but an implementation SHOULD make use of an exponential back-off session establishment retry procedure.
オープンメッセージを受信すると、受信PCEPピアが提案PCEPセッション特性が許容可能であるかどうかを決定しなければなりません。特性の少なくとも一つが受信ピアに許容されない場合は、エラーメッセージを送らなければなりません。エラーメッセージは、各受け入れられないセッション・パラメータに、許容されるパラメータ値は、当初提案された値の代わりに、開いているオブジェクトの適切なフィールドに提案されるべきであり、関連するOPENオブジェクトを含むとすべきです。 PCEPピアは、別のセッションの特性を持つオープンメッセージを再送信することもできます。第二のオープンメッセージは、パラメータの同じセットまたは依然として許容できないパラメータで受信された場合、受信ピアはエラーメッセージを送信しなければならず、すぐにTCP接続を閉じる必要があります。エラーメッセージについての詳細は、7.15項に記載されています。連続した再試行は許可されているが、実装は、指数バックオフセッション確立再試行手順の使用をしなければなりません。
If the PCEP session characteristics are acceptable, the receiving PCEP peer MUST send a Keepalive message (defined in Section 6.3) that serves as an acknowledgment.
PCEPセッション特性が許容可能である場合、受信PCEPピアは、肯定応答として機能する（セクション6.3で定義される）キープアライブメッセージを送信しなければなりません。
The PCEP session is considered as established once both PCEP peers have received a Keepalive message from their peer.
両方PCEPピアがそのピアからのキープアライブメッセージを受信したら確立さPCEPセッションがあると考えられます。
A Keepalive message is a PCEP message sent by a PCC or a PCE in order to keep the session in active state. The Keepalive message is also used in response to an Open message to acknowledge that an Open message has been received and that the PCEP session characteristics are acceptable. The Message-Type field of the PCEP common header for the Keepalive message is set to 2. The Keepalive message does not contain any object.
キープアライブメッセージは、アクティブな状態でセッションを維持するために、PCC又はPCEによって送信されたPCEPメッセージです。キープアライブメッセージはまた、オープンメッセージが受信されたこととPCEPセッション特性が許容可能であることを確認するためにオープンメッセージに応答して使用されます。キープアライブメッセージのPCEP共通ヘッダのメッセージタイプフィールドは、キープアライブメッセージは、任意のオブジェクトが含まれていない2に設定されています。
PCEP has its own keepalive mechanism used to ensure the liveness of the PCEP session. This requires the determination of the frequency at which each PCEP peer sends Keepalive messages. Asymmetric values may be chosen; thus, there is no constraint mandating the use of identical keepalive frequencies by both PCEP peers. The DeadTimer is defined as the period of time after the expiration of which a PCEP peer declares the session down if no PCEP message has been received (Keepalive or any other PCEP message); thus, any PCEP message acts as a Keepalive message. Similarly, there are no constraints mandating the use of identical DeadTimers by both PCEP peers. The minimum Keepalive timer value is 1 second. Deployments SHOULD consider carefully the impact of using low values for the Keepalive timer as these might not give rise to the expected results in periods of temporary network instability.
PCEPは、PCEPセッションの生存性を確保するために使用、独自のキープアライブメカニズムを持っています。これは、各PCEPピアがキープアライブメッセージを送信する頻度の決意を必要とします。非対称の値を選択することができます。このように、両方のPCEPピアによって同一キープアライブ周波数の使用を義務付ける何ら制約はありません。 DeadTimerはないPCEPメッセージが（キープアライブまたは他PCEPメッセージ）を受信していない場合PCEPピアがダウンセッションを宣言したの終了後の期間として定義されます。従って、任意のPCEPメッセージは、キープアライブメッセージとして働きます。同様に、両方のPCEPピアによって同じDeadTimersの使用を義務付ける何ら制約は存在しません。最小のキープアライブタイマー値は1秒です。配備は慎重に一時的なネットワークの不安定性の期間中に予想される結果を生じさせない可能性がありますこれらのようなキープアライブタイマーのために低い値を使用しての影響を考慮すべきです。
Keepalive messages are sent at the frequency specified in the OPEN object carried within an Open message according to the rules specified in Section 7.3. Because any PCEP message may serve as Keepalive, an implementation may either decide to send Keepalive messages at fixed intervals regardless of whether other PCEP messages might have been sent since the last sent Keepalive message, or may decide to differ the sending of the next Keepalive message based on the time at which the last PCEP message (other than Keepalive) was sent.
キープアライブメッセージはセクション7.3で指定された規則に従ってオープンメッセージ内で運ばOPENオブジェクトに指定された周波数で送信されます。任意のPCEPメッセージがキープアライブとして働くことができるので、実装にかかわらず、最後は、キープアライブメッセージを送信し、または次のキープアライブメッセージの送信を異なることを決定することができるので、他のPCEPメッセージが送信された可能性があるかどうかの一定間隔でキープアライブメッセージを送信するように決定することができるいずれか（キープアライブ以外の）最後PCEPメッセージが送信された時刻に基づい。
Note that sending Keepalive messages to keep the session alive is optional, and PCEP peers may decide not to send Keepalive messages once the PCEP session is established; in which case, the peer that does not receive Keepalive messages does not expect to receive them and MUST NOT declare the session as inactive.
セッションを存続するためにキープアライブメッセージを送信することはオプションであることに注意してください、とPCEPピアはPCEPセッションが確立されると、キープアライブメッセージを送信しないことを決定することができます。その場合には、キープアライブメッセージを受信しないピアはそれらを受け取ることを期待していないと、非アクティブとしてセッションを宣言してはなりません。
The format of a Keepalive message is as follows:
次のようにキープアライブメッセージの形式は次のとおりです。
<Keepalive Message>::= <Common Header>
A Path Computation Request message (also referred to as a PCReq message) is a PCEP message sent by a PCC to a PCE to request a path computation. A PCReq message may carry more than one path computation request. The Message-Type field of the PCEP common header for the PCReq message is set to 3.
経路計算要求メッセージ（またPCReqメッセージと呼ぶ）は経路計算を要求するPCEにPCCによって送らPCEPメッセージです。 PCReqメッセージは、複数の経路計算要求を搬送することができます。 PCReqメッセージのPCEP共通ヘッダのメッセージタイプフィールドが3に設定されています。
There are two mandatory objects that MUST be included within a PCReq message: the RP and the END-POINTS objects (see Section 7). If one or both of these objects is missing, the receiving PCE MUST send an error message to the requesting PCC. Other objects are optional.
RPおよびエンドポイントのオブジェクト（セクション7を参照してください）：PCReqメッセージ内に含まれなければならない2つの必須のオブジェクトがあります。これらのオブジェクトの一方または両方が欠落している場合、受信PCEは要求してPCCにエラーメッセージを送らなければなりません。他の目的はオプションです。
The format of a PCReq message is as follows:
次のようにPCReqメッセージのフォーマットは次のとおりです。
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
where:
どこ：
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
where:
どこ：
<metric-list>::=<METRIC>[<metric-list>]
The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO, and LOAD-BALANCING objects are defined in Section 7. The special case of two BANDWIDTH objects is discussed in detail in Section 7.7.
SVEC、RP、エンドポイント、LSPA帯域幅メトリック、RRO、IRO、及び負荷分散オブジェクトは、二つの帯域幅オブジェクトの特殊なケースは、セクション7.7で詳細に説明されているセクション7で定義されています。
A PCEP implementation is free to process received requests in any order. For example, the requests may be processed in the order they are received, reordered and assigned priority according to local policy, reordered according to the priority encoded in the RP object (Section 7.4.1), or processed in parallel.
PCEPの実装は、任意の順序で受信した要求を処理して自由です。例えば、要求は、RPオブジェクト（7.4.1項）で符号化された優先順位に従って並べ替え、または並列処理、ローカルポリシーに従って優先順位を、それらが受信された順序で処理並べ替えと割り当てることができます。
The PCEP Path Computation Reply message (also referred to as a PCRep message) is a PCEP message sent by a PCE to a requesting PCC in response to a previously received PCReq message. The Message-Type field of the PCEP common header for the PCRep message is set to 4.
（また、PCRepメッセージと呼ぶ）PCEP経路計算応答メッセージは、以前に受信したPCReqメッセージに応答して、要求PCCとPCEによって送信されたPCEPメッセージです。 PCRepメッセージのPCEP共通ヘッダのメッセージタイプフィールドが4に設定されています。
The bundling of multiple replies to a set of path computation requests within a single PCRep message is supported by PCEP. If a PCE receives non-synchronized path computation requests by means of one or more PCReq messages from a requesting PCC, it MAY decide to bundle the computed paths within a single PCRep message so as to reduce the control plane load. Note that the counter side of such an approach is the introduction of additional delays for some path computation requests of the set. Conversely, a PCE that receives multiple requests within the same PCReq message MAY decide to provide each computed path in separate PCRep messages or within the same PCRep message. A PCRep message may contain positive and negative replies.
単一PCRepメッセージ内の経路計算要求のセットに対する複数の応答のバンドルは、PCEPによって支持されています。 PCEは要求PCCから1つ以上のPCReqメッセージによって非同期経路計算リクエストを受信した場合、それは、制御プレーンの負荷を低減するように単一PCRepメッセージ内で計算された経路をバンドルすることを決定することができます。そのようなアプローチの対向側はセットの一部経路計算要求に対する追加の遅延を導入することであることに留意されたいです。逆に、同じPCReqメッセージ内の複数のリクエストを受信したPCEは、別個PCRepメッセージまたは同じPCRepメッセージ内の各計算された経路を提供することを決定することができます。 PCRepメッセージは、正および負の応答を含んでいてもよいです。
A PCRep message may contain a set of computed paths corresponding to either a single path computation request with load-balancing (see Section 7.16) or multiple path computation requests originated by a requesting PCC. The PCRep message may also contain multiple acceptable paths corresponding to the same request.
PCRepメッセージは、要求PCCによって発信ロードバランシング（セクション7.16を参照）、または複数の経路計算要求に単一の経路計算要求のどちらかに対応する計算されたパスのセットを含んでいてもよいです。 PCRepメッセージは、同じ要求に対応する複数の許容される経路を含んでもよいです。
The PCRep message MUST contain at least one RP object. For each reply that is bundled into a single PCReq message, an RP object MUST be included that contains a Request-ID-number identical to the one specified in the RP object carried in the corresponding PCReq message (see Section 7.4 for the definition of the RP object).
PCRepメッセージは、少なくとも一つのRPオブジェクトを含まなければなりません。単一PCReqメッセージにバンドルされた各応答を、RPオブジェクトは、対応するPCReqメッセージで運ばRPオブジェクトで指定されたものと同一のRequest-ID番号が含まれていることを含まなければなりません（の定義についてはセクション7.4を参照してくださいRPオブジェクト）。
If the path computation request can be satisfied (i.e., the PCE finds a set of paths that satisfy the set of constraints), the set of computed paths specified by means of Explicit Route Objects (EROs) is inserted in the PCRep message. The ERO is defined in Section 7.9. The situation where multiple computed paths are provided in a PCRep message is discussed in detail in Section 7.13. Furthermore, when a PCC requests the computation of a set of paths for a total amount of bandwidth by means of a LOAD-BALANCING object carried within a PCReq message, the ERO of each computed path may be followed by a BANDWIDTH object as discussed in section Section 7.16.
経路計算要求を満たすことができる場合、PCRepメッセージに挿入された明示的経路オブジェクト（エロス）によって指定された計算されたパスのセット（すなわち、PCEは、制約のセットを満足する経路の集合を見つけます）。 EROは、7.9節で定義されています。複数の計算されたパスがPCRepメッセージで提供される状況は、セクション7.13で詳しく説明されています。 PCCはPCReqメッセージの中で運ば負荷分散オブジェクトによる帯域幅の合計のパスの組の計算を要求する場合セクションで説明したようにまた、各計算パスのEROは、帯域幅オブジェクトが続いてもよいですセクション7.16。
If the path computation request cannot be satisfied, the PCRep message MUST include a NO-PATH object. The NO-PATH object (described in Section 7.5) may also contain other information (e.g, reasons for the path computation failure).
経路計算要求を満たすことができない場合、PCRepメッセージは、NO-Pathオブジェクトを含まなければなりません。 NO-PATHオブジェクト（セクション7.5に記載）も、他の情報を含んでいてもよい（例えば、経路計算失敗の理由）。
The format of a PCRep message is as follows:
次のようにPCRepメッセージの形式は次のとおりです。
<PCRep Message> ::= <Common Header>
<response-list>
where:
どこ：
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO><attribute-list>
where:
どこ：
<attribute-list>::=[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<metric-list>::=<METRIC>[<metric-list>]
The PCEP Notification message (also referred to as the PCNtf message) can be sent either by a PCE to a PCC, or by a PCC to a PCE, to notify of a specific event. The Message-Type field of the PCEP common header for the PCNtf message is set to 5.
（またPCNtfメッセージと呼ぶ）PCEP通知メッセージは、特定のイベントを通知するために、PCEとPCCのPCEによって、またはPCCのいずれかによって送信することができます。 PCNtfメッセージのPCEP共通ヘッダのメッセージタイプフィールドが5に設定されています。
The PCNtf message MUST carry at least one NOTIFICATION object and MAY contain several NOTIFICATION objects should the PCE or the PCC intend to notify of multiple events. The NOTIFICATION object is defined in Section 7.14. The PCNtf message MAY also contain RP objects (see Section 7.4) when the notification refers to particular path computation requests.
PCNtfメッセージは、少なくとも1つの通知オブジェクトを運ばなければなりませんし、PCEまたはPCCは、複数のイベントを通知しようとするべきであるいくつかのNOTIFICATIONオブジェクトを含むかもしれません。通知オブジェクトは、セクション7.14で定義されています。通知は、特定の経路計算リクエストを指す場合PCNtfメッセージは、RPオブジェクト（セクション7.4を参照）を含んでいてもよいです。
The PCNtf message may be sent by a PCC or a PCE in response to a request or in an unsolicited manner.
PCNtfメッセージは、PCC又は要求に応じて、または未承諾の方法でPCEによって送信されてもよいです。
The format of a PCNtf message is as follows:
次のようにPCNtfメッセージの形式は次のとおりです。
<PCNtf Message>::=<Common Header>
<notify-list>
<notify-list>::=<notify> [<notify-list>]
<notify>::= [<request-id-list>]
<notification-list>
<request-id-list>::=<RP>[<request-id-list>]
<notification-list>::=<NOTIFICATION>[<notification-list>]
The PCEP Error message (also referred to as a PCErr message) is sent in several situations: when a protocol error condition is met or when the request is not compliant with the PCEP specification (e.g., reception of a malformed message, reception of a message with a mandatory missing object, policy violation, unexpected message, unknown request reference). The Message-Type field of the PCEP common header for the PCErr message is set to 6.
プロトコルエラー条件が満たされたとき、またはメッセージの要求がPCEP仕様に準拠していない（例えば、不正な形式のメッセージの受信、受信：PCEPエラーメッセージ（またPCErrメッセージと呼ぶ）は、いくつかの状況で送信されます必須不足しているオブジェクト、ポリシー違反、予期しないメッセージ、未知の要求参照）で。 PCErrメッセージのPCEP共通ヘッダのメッセージタイプフィールドが6に設定されています。
The PCErr message is sent by a PCC or a PCE in response to a request or in an unsolicited manner. If the PCErr message is sent in response to a request, the PCErr message MUST include the set of RP objects related to the pending path computation requests that triggered the error condition. In the latter case (unsolicited), no RP object is inserted in the PCErr message. For example, no RP object is inserted in a PCErr when the error condition occurred during the initialization phase. A PCErr message MUST contain a PCEP-ERROR object specifying the PCEP error condition. The PCEP-ERROR object is defined in Section 7.15.
PCErrメッセージは、PCC又は要求に応じて、または未承諾の方法でPCEによって送信されます。 PCErrメッセージが要求に応答して送信される場合、PCErrメッセージは、エラー状態をトリガし、保留中の経路計算要求に関連するRPオブジェクトのセットを含まなければなりません。 （迷惑）、後者の場合には、何のRPオブジェクトはPCErrメッセージに挿入されていません。エラー条件が初期化フェーズ中に発生した場合、例えば、何RPオブジェクトはPCErrに挿入されていません。 PCErrメッセージは、PCEPエラー条件を指定PCEP-ERRORオブジェクトを含まなければなりません。 PCEP-ERRORオブジェクトは、7.15項で定義されています。
The format of a PCErr message is as follows:
次のようにPCErrメッセージの形式は次のとおりです。
<PCErr Message> ::= <Common Header>
( <error-obj-list> [<Open>] ) | <error>
[<error-list>]
<error-obj-list>::=<PCEP-ERROR>[<error-obj-list>]
<error>::=[<request-id-list>]
<error-obj-list>
<request-id-list>::=<RP>[<request-id-list>]
<error-list>::=<error>[<error-list>]
The procedure upon the receipt of a PCErr message is defined in Section 7.15.
PCErrメッセージを受信する手順はセクション7.15に定義されています。
The Close message is a PCEP message that is either sent by a PCC to a PCE or by a PCE to a PCC in order to close an established PCEP session. The Message-Type field of the PCEP common header for the Close message is set to 7.
クローズメッセージは、確立PCEPセッションを閉じるために、PCEまたはPCCのPCEによってPCCによって送られるかPCEPメッセージです。クローズメッセージのPCEP共通ヘッダのメッセージタイプフィールドは7に設定されています。
The format of a Close message is as follows:
次のように閉じるのメッセージの形式は次のとおりです。
<Close Message>::= <Common Header>
<CLOSE>
The Close message MUST contain exactly one CLOSE object (see Section 6.8). If more than one CLOSE object is present, the first MUST be processed and subsequent objects ignored.
クローズメッセージは、1つのCLOSEのオブジェクトを（セクション6.8を参照）を含まなければなりません。複数の近距離物体が存在する場合、最初に処理されなければならないと後続のオブジェクトが無視します。
Upon the receipt of a valid Close message, the receiving PCEP peer MUST cancel all pending requests, it MUST close the TCP connection and MUST NOT send any further PCEP messages on the PCEP session.
有効閉じるメッセージを受信すると、受信PCEPピアは、すべての保留中の要求をキャンセルする必要があり、それはTCPコネクションを閉じる必要がありますし、PCEPセッションについて、さらにPCEPメッセージを送ってはいけません。
A PCEP implementation that receives an unrecognized PCEP message MUST send a PCErr message with Error-value=2 (capability not supported).
未認識のPCEPメッセージを受信PCEP実装がエラー値= 2でPCErrメッセージを送信しなければならない（機能がサポートされていません）。
If a PCC/PCE receives unrecognized messages at a rate equal or greater than MAX-UNKNOWN-MESSAGES unknown message requests per minute, the PCC/PCE MUST send a PCEP CLOSE message with close value="Reception of an unacceptable number of unknown PCEP message". A RECOMMENDED value for MAX-UNKNOWN-MESSAGES is 5. The PCC/PCE MUST close the TCP session and MUST NOT send any further PCEP messages on the PCEP session.
PCC / PCEは、MAX-UNKNOWN-MESSAGESと同等以上の速度毎分未知のメッセージ要求で認識されていないメッセージを受信した場合、PCC / PCEは、未知のPCEPメッセージの許容できない数の= "受信近い値PCEP CLOSEメッセージを送らなければなりません」。 MAX-UNKNOWN-MESSAGESの推奨値はPCC / PCEは、TCPセッションを閉じる必要がありますし、PCEPセッションについて、さらにPCEPメッセージを送ってはいけません5です。
PCEP objects have a common format. They begin with a common object header (see Section 7.2). This is followed by object-specific fields defined for each different object. The object may also include one or more type-length-value (TLV) encoded data sets. Each TLV has the same structure as described in Section 7.1.
PCEPオブジェクトは、共通のフォーマットを持っています。彼らは（セクション7.2を参照）、共通オブジェクトヘッダで始まります。これは、各異なるオブジェクトに対して定義されたオブジェクト固有のフィールドが続きます。オブジェクトはまた、1つ以上のタイプレングス値（TLV）エンコードされたデータセットを含むことができます。各TLVは、セクション7.1に記載されたものと同じ構造を有しています。
A PCEP object may include a set of one or more optional TLVs.
PCEPオブジェクトは、1つの以上の任意のTLVのセットを含むことができます。
All PCEP TLVs have the following format:
すべてのPCEPのTLVの形式は次のとおりです。
Type: 2 bytes Length: 2 bytes Value: variable
タイプ：2バイトの長さ：2バイト値：変数
A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes specifying the TLV length, and a value field.
PCEPオブジェクトTLVは、タイプのための2バイト、TLVの長さを指定する2バイト、及び値フィールドから構成されています。
The Length field defines the length of the value portion in bytes. The TLV is padded to 4-bytes alignment; padding is not included in the Length field (so a 3-byte value would have a length of 3, but the total size of the TLV would be 8 bytes).
Lengthフィールドは、バイト単位の値部分の長さを規定します。 TLVは4バイトアライメントにパディングされます。パディングは、長さフィールド（SO 3バイトの値が3の長さを有するであろうが、TLVの合計サイズが8つのバイトであろう）には含まれません。
Unrecognized TLVs MUST be ignored.
認識されないのTLVを無視しなければなりません。
IANA management of the PCEP Object TLV type identifier codespace is described in Section 9.
PCEPオブジェクトTLVタイプ識別子コードスペースのIANA管理は、セクション9に記載されています。
A PCEP object carried within a PCEP message consists of one or more 32-bit words with a common header that has the following format:
PCEPメッセージ内で運ばPCEPオブジェクトは、次のフォーマットを有する共通ヘッダを有する1つまたは複数の32ビットワードで構成されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Object body) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: PCEP Common Object Header
図8：PCEP共通オブジェクトヘッダー
Object-Class (8 bits): identifies the PCEP object class.
オブジェクトクラス（8ビット）：PCEPオブジェクトクラスを識別する。
OT (Object-Type - 4 bits): identifies the PCEP object type.
OT（オブジェクトタイプ - 4ビット）：PCEPオブジェクトタイプを識別する。
The Object-Class and Object-Type fields are managed by IANA.
オブジェクトクラスとオブジェクト型のフィールドは、IANAによって管理されています。
The Object-Class and Object-Type fields uniquely identify each PCEP object.
オブジェクトクラスおよびオブジェクトタイプのフィールドは、一意PCEPオブジェクトを識別する。
Res flags (2 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt.
RESフラグ（2ビット）：Reservedフィールド。このフィールドは、送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
P flag (Processing-Rule - 1-bit): the P flag allows a PCC to specify in a PCReq message sent to a PCE whether the object must be taken into account by the PCE during path computation or is just optional. When the P flag is set, the object MUST be taken into account by the PCE. Conversely, when the P flag is cleared, the object is optional and the PCE is free to ignore it.
Pフラグ（処理ルール - 1ビット）：Pフラグは、PCCは、オブジェクトがパス計算中PCEによって考慮または単に任意であるしなければならないかどうかをPCEに送信PCReqメッセージに指定することを可能にします。 Pフラグが設定されている場合、オブジェクトは、PCEによって考慮されなければなりません。 Pフラグがクリアされると逆に、オブジェクトはオプションであり、PCEは、それを無視して自由です。
I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep message to indicate to a PCC whether or not an optional object was processed. The PCE MAY include the ignored optional object in its reply and set the I flag to indicate that the optional object was ignored during path computation. When the I flag is cleared, the PCE indicates that the optional object was processed during the path computation. The setting of the I flag for optional objects is purely indicative and optional. The I flag has no meaning in a PCRep message when the P flag has been set in the corresponding PCReq message.
Iは、（無視 - 1ビット）フラグ：Iフラグは、任意のオブジェクトが処理されたか否かをPCCに示すためにPCRepメッセージにPCEによって使用されます。 PCEは、その応答で無視任意のオブジェクトを含み、任意の目的は、経路計算中に無視されたことを示すために、Iフラグを設定してもよいです。 Iフラグがクリアされると、PCEは、任意の目的は、経路計算中に処理されたことを示しています。任意のオブジェクトのIフラグの設定は、純粋に指標及びオプションです。 Iフラグは、Pフラグは、対応するPCReqメッセージに設定されているPCRepメッセージに意味を持ちません。
If the PCE does not understand an object with the P flag set or understands the object but decides to ignore the object, the entire PCEP message MUST be rejected and the PCE MUST send a PCErr message with Error-Type="Unknown Object" or "Not supported Object" along with the corresponding RP object. Note that if a PCReq includes multiple requests, only requests for which an object with the P flag set is unknown/unrecognized MUST be rejected.
PCEは、Pフラグが設定されたオブジェクトを理解したり、オブジェクトを理解しますが、オブジェクトを無視することを決定しない場合は、全体PCEPメッセージを拒絶しなければなりませんし、PCEは、エラー・タイプ=「未知のオブジェクト」または「とPCErrメッセージを送らなければなりません対応するRPのオブジェクトと一緒に「オブジェクトをサポートしていません。 PCReqが複数の要求、Pフラグが設定されたオブジェクトが未知の/未認識が拒否されなければならないためにのみ要求を含む場合ことに留意されたいです。
Object Length (16 bits): Specifies the total object length including the header, in bytes. The Object Length field MUST always be a multiple of 4, and at least 4. The maximum object content length is 65528 bytes.
物体長（16ビット）：バイトで、ヘッダを含む全オブジェクトの長さを指定します。物体長フィールドは常に4の倍数でなければならない、少なくとも4、最大対象コンテンツの長さが65528バイトです。
The OPEN object MUST be present in each Open message and MAY be present in a PCErr message. There MUST be only one OPEN object per Open or PCErr message.
OPENオブジェクトは、各オープンメッセージ内に存在していなければなりませんとPCErrメッセージ中に存在してもよいです。開くかPCErrメッセージごとに1つだけ開いているオブジェクトが存在しなければなりません。
The OPEN object contains a set of fields used to specify the PCEP version, Keepalive frequency, DeadTimer, and PCEP session ID, along with various flags. The OPEN object may also contain a set of TLVs used to convey various session characteristics such as the detailed PCE capabilities, policy rules, and so on. No TLVs are currently defined.
OPENオブジェクトは、各種のフラグと一緒に、PCEPバージョン、キープアライブ周波数、DeadTimer、及びPCEPセッションIDを指定するために使用するフィールドのセットを含みます。 OPENオブジェクトものTLVのセットを含むことができるようなので、上の詳細なPCE機能、ポリシールール、およびなどの様々なセッション特性を伝えるために使用されます。何のTLVは、現在定義されていません。
OPEN Object-Class is 1.
OPENオブジェクトクラスは1です。
OPEN Object-Type is 1.
OPENオブジェクト型は1です。
The format of the OPEN object body is as follows:
次のようにOPENオブジェクト本体の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Flags | Keepalive | DeadTimer | SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: OPEN Object Format
図9：OPENオブジェクトフォーマット
Ver (3 bits): PCEP version. Current version is 1.
版（3ビット）：PCEPバージョン。現在のバージョンは1です。
Flags (5 bits): No flags are currently defined. Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt.
フラグ（5ビット）：なしフラグが現在定義されています。予約済みとして割り当てられていないビットが考慮されます。彼らは、送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
Keepalive (8 bits): maximum period of time (in seconds) between two consecutive PCEP messages sent by the sender of this message. The minimum value for the Keepalive is 1 second. When set to 0, once the session is established, no further Keepalive messages are sent to the remote peer. A RECOMMENDED value for the keepalive frequency is 30 seconds.
キープアライブ（8ビット）：このメッセージの送信者によって送信された二つの連続PCEPメッセージ間の時間（秒）の最大期間。キープアライブの最小値は1秒です。 0に設定すると、セッションが確立されると、それ以上のキープアライブメッセージがリモートピアに送信されません。キープアライブ周波数の推奨値は30秒です。
DeadTimer (8 bits): specifies the amount of time after the expiration of which the PCEP peer can declare the session with the sender of the Open message to be down if no PCEP message has been received. The DeadTimer SHOULD be set to 0 and MUST be ignored if the Keepalive is set to 0. A RECOMMENDED value for the DeadTimer is 4 times the value of the Keepalive.
DeadTimer（8ビット）：PCEPピアがないPCEPメッセージが受信されていない場合にダウンしてオープンメッセージの送信者とのセッションを宣言することができるの終了後の時間を指定します。 DeadTimerは0に設定されるべきであり、キープアライブが0に設定されている場合、AはDeadTimerの値がキープアライブの4倍の値であり、推奨無視しなければなりません。
Example:
例：
A sends an Open message to B with Keepalive=10 seconds and DeadTimer=40 seconds. This means that A sends Keepalive messages (or any other PCEP message) to B every 10 seconds and B can declare the PCEP session with A down if no PCEP message has been received from A within any 40-second period.
Aは、キープアライブ= 10秒とDeadTimer = 40秒とBに開くメッセージを送信します。これは、Aは、キープアライブメッセージを送信することを意味する（または任意の他のPCEPメッセージ）が10秒ごとにBにおよびNO PCEPメッセージは、任意の40秒の期間内にAから受信されていない場合、Bは、ダウンとPCEPセッションを宣言することができます。
SID (PCEP session ID - 8 bits): unsigned PCEP session number that identifies the current session. The SID MUST be incremented each time a new PCEP session is established. It is used for logging and troubleshooting purposes. Each increment SHOULD have a value of 1 and may cause a wrap back to zero.
SID（PCEPセッションID - 8ビット）：現在のセッションを識別する符号なしPCEPセッション番号。 SIDは、新しいPCEPセッションが確立されるたびに増加しなければなりません。これは、ロギングおよびトラブルシューティングの目的のために使用されます。各増分は1の値を持つ必要がありますし、ゼロに戻ってラップを引き起こす可能性があります。
The SID is used to disambiguate instances of sessions to the same peer. A PCEP implementation could use a single source of SIDs across all peers, or one source for each peer. The former might constrain the implementation to only 256 concurrent sessions. The latter potentially requires more states. There is one SID number in each direction.
SIDは、同じピアにセッションのインスタンスを明確にするために使用されます。 PCEP実装は、単一のすべてのピアを横断SIDのソース、または各ピアに対して1つのソースを使用することができます。前者は唯一の256の同時セッションへの実装を制約する可能性があります。後者は、潜在的により多くの状態を必要とします。各方向に1つのずつSID番号があります。
Optional TLVs may be included within the OPEN object body to specify PCC or PCE characteristics. The specification of such TLVs is outside the scope of this document.
任意のTLVは、PCC又はPCE特性を指定するために開いているオブジェクトの本体内に含めることができます。このようなのTLVの仕様は、この文書の範囲外です。
When present in an Open message, the OPEN object specifies the proposed PCEP session characteristics. Upon receiving unacceptable PCEP session characteristics during the PCEP session initialization phase, the receiving PCEP peer (PCE) MAY include an OPEN object within the PCErr message so as to propose alternative acceptable session characteristic values.
存在する場合オープンメッセージで、開いているオブジェクトが提案PCEPセッション特性を指定します。代替的に許容されるセッション特性値を提案するように、PCEPセッション初期化フェーズ中に許容できないPCEPセッション特性を受信すると、受信PCEPピア（PCE）はPCErrメッセージ内で開いているオブジェクトを含むかもしれません。
The RP (Request Parameters) object MUST be carried within each PCReq and PCRep messages and MAY be carried within PCNtf and PCErr messages. The RP object is used to specify various characteristics of the path computation request.
RP（リクエストパラメータ）オブジェクトは、各PCReqとPCRepメッセージ内で運ばなければならないとPCNtfとPCErrメッセージの中に行うことができます。 RPオブジェクトは、経路計算要求の様々な特性を指定するために使用されます。
The P flag of the RP object MUST be set in PCReq and PCRep messages and MUST be cleared in PCNtf and PCErr messages. If the RP object is received with the P flag set incorrectly according to the rules stated above, the receiving peer MUST send a PCErr message with Error-Type=10 and Error-value=1. The corresponding path computation request MUST be cancelled by the PCE without further notification.
RPオブジェクトのPフラグはPCReqとPCRepメッセージに設定されなければならないとPCNtfとPCErrメッセージでクリアする必要があります。 RPオブジェクトは、上述した規則に従って正しく設定Pフラグが受信された場合、受信ピアは、エラータイプ= 10、エラー値= 1とPCErrメッセージを送らなければなりません。対応する経路計算要求は、さらに、通知なしPCEによって相殺されなければなりません。
RP Object-Class is 2.
RPオブジェクトクラスは2です。
RP Object-Type is 1.
RPオブジェクト・タイプは1です。
The format of the RP object body is as follows:
次のようにRPオブジェクト本体の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: RP Object Body Format
図10：RPオブジェクト本体のフォーマット
The RP object body has a variable length and may contain additional TLVs. No TLVs are currently defined.
RPオブジェクト本体は、可変の長さを有し、追加のTLVを含んでいてもよいです。何のTLVは、現在定義されていません。
Flags (32 bits)
フラグ（32ビット）
The following flags are currently defined:
以下のフラグは、現在定義されています。
o Pri (Priority - 3 bits): the Priority field may be used by the requesting PCC to specify to the PCE the request's priority from 1 to 7. The decision of which priority should be used for a specific request is a local matter; it MUST be set to 0 when unused. Furthermore, the use of the path computation request priority by the PCE's scheduler is implementation specific and out of the scope of this document. Note that it is not required for a PCE to support the priority field: in this case, it is RECOMMENDED that the PCC set the priority field to 0 in the RP object. If the PCE does not take into account the request priority, it is RECOMMENDED to set the priority field to 0 in the RP object carried within the corresponding PCRep message, regardless of the priority value contained in the RP object carried within the corresponding PCReq message. A higher numerical value of the priority field reflects a higher priority. Note that it is the responsibility of the network administrator to make use of the priority values in a consistent manner across the various PCCs. The ability of a PCE to support request prioritization MAY be dynamically discovered by the PCCs by means of PCE capability discovery. If not advertised by the PCE, a PCC may decide to set the request priority and will learn the ability of the PCE to support request prioritization by observing the Priority field of the RP object received in the PCRep message. If the value of the Pri field is set to 0, this means that the PCE does not support the handling of request priorities: in other words, the path computation request has been honored but without taking the request priority into account.
ぷり（プライオリティ - 3ビット）O：Priorityフィールドは1から7の優先順位は、ローカルの問題である特定の要求のために使用すべきかの決定にPCEに要求の優先順位を指定することを要求PCCによって使用されてもよいです。それが0未使用時に設定しなければなりません。さらに、PCEのスケジューラによる経路計算要求の優先順位を使用することは、特定し、この文書の範囲の外に実装したものです。それは優先順位フィールドをサポートするPCEのために必要とされないことに注意してください。この場合、PCCは、RPオブジェクトに優先順位フィールドを0に設定することをお勧めします。 PCEは、アカウントに要求の優先順位を取らない場合、関係なく、対応するPCReqメッセージ内で運ばRPオブジェクトに含まれるプライオリティ値の、対応PCRepメッセージ内で運ばRPオブジェクトに優先順位フィールドを0に設定することが推奨されます。優先順位フィールドのより高い数値は、より高い優先度を反映します。様々なのPCC全体で一貫した方法で優先順位の値を使用するために、ネットワーク管理者の責任であることに注意してください。要求の優先順位付けをサポートするPCEの能力は、動的PCE機能の発見によってのPCCによって発見されるかもしれません。 PCEによってアドバタイズされない場合は、PCCは、要求の優先順位を設定することを決定してもよいとPCRepメッセージで受信したRPオブジェクトの優先度フィールドを観察することによって、要求の優先順位付けをサポートするPCEの能力を学びます。ぷりフィールドの値が0に設定されている場合、これは、PCEが、要求の優先順位の取り扱いをサポートしていないことを意味します。つまり、経路計算要求はなく、口座に要求の優先順位を取らずに表彰されました。
o R (Reoptimization - 1 bit): when set, the requesting PCC specifies that the PCReq message relates to the reoptimization of an existing TE LSP. For all TE LSPs except zero-bandwidth LSPs, when the R bit is set, an RRO (see Section 7.10) MUST be included in the PCReq message to show the path of the existing TE LSP. Also, for all TE LSPs except zero-bandwidth LSPs, when the R bit is set, the existing bandwidth of the TE LSP to be reoptimized MUST be supplied in a BANDWIDTH object (see Section 7.7). This BANDWIDTH object is in addition to the instance of that object used to describe the desired bandwidth of the reoptimized LSP. For zero-bandwidth LSPs, the RRO and BANDWIDTH objects that report the characteristics of the existing TE LSP are optional.
O R（再最適化 - 1ビット）：セット、要求PCCはPCReqメッセージが既存のTE LSPの再最適化に関連することを指定します。 Rビットがセットされたときにゼロ帯域のLSPを除くすべてのTE LSPのために、RRO（セクション7.10を参照）、既存のTE LSPの経路を示すためPCReqメッセージに含まれなければなりません。また、ゼロ帯域のLSPを除くすべてのTE LSPを、Rビットが設定されている場合に、再最適化されるTE LSPの既存の帯域幅が帯域オブジェクトで供給されなければならない（セクション7.7を参照）。この帯域幅オブジェクトは再最適化LSPの所望の帯域幅を記述するために使用したオブジェクトのインスタンスに追加されます。ゼロ帯域のLSPのために、既存のTE LSPの特性を報告RROとBANDWIDTHオブジェクトはオプションです。
o B (Bi-directional - 1 bit): when set, the PCC specifies that the path computation request relates to a bi-directional TE LSP that has the same traffic engineering requirements including fate sharing, protection and restoration, LSRs, TE links, and resource requirements (e.g., latency and jitter) in each direction. When cleared, the TE LSP is unidirectional.
O B（双方向 - 1ビット）：セット、PCCは、経路計算要求が運命共有、保護及び修復、のLSR、TEリンクを含む同じトラフィックエンジニアリング要件を有する双方向TE LSPに関連することを指定し各方向およびリソース要件（例えば、レイテンシーおよびジッタ）。クリアすると、TE LSPは一方向です。
o O (strict/loose - 1 bit): when set, in a PCReq message, this indicates that a loose path is acceptable. Otherwise, when cleared, this indicates to the PCE that a path exclusively made of strict hops is required. In a PCRep message, when the O bit is set this indicates that the returned path is a loose path; otherwise (when the O bit is cleared), the returned path is made of strict hops.
O O（ルーズ/厳密 - 1ビット）：セットは、PCReqメッセージには、これは、緩いパスが許容可能であることを示しています。クリア時にそれ以外の場合は、これは独占的に厳しいホップで作られたパスが必要とされるPCEに示します。 Oビットが設定されている場合にPCRepメッセージでは、これは、返されたパスが緩んパスであることを示しています。そうでなければ（Oビットがクリアされている場合）、返された経路は、厳密ホップで構成されています。
Unassigned bits are considered reserved. They MUST be set to zero on transmission and MUST be ignored on receipt.
割り当てられていないビットはリザーブと考えられます。彼らは、送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
Request-ID-number (32 bits): The Request-ID-number value combined with the source IP address of the PCC and the PCE address uniquely identify the path computation request context. The Request-ID-number is used for disambiguation between pending requests, and thus it MUST be changed (such as by incrementing it) each time a new request is sent to the PCE, and may wrap.
要求ID番号（32ビット）：PCCの送信元IPアドレスと経路計算リクエストコンテキストを識別する一意PCEアドレスと組み合わさ要求ID番号値。リクエスト-ID番号は、保留中の要求の間に曖昧さ回避のために使用され、したがって、それは新しい要求をPCEに送信されるたびに（それを増分することによってなど）変更されなければならない、とラップしてもよいです。
The value 0x00000000 is considered invalid.
値0x00000000には、無効とみなされます。
If no path computation reply is received from the PCE (e.g., the request is dropped by the PCE because of memory overflow), and the PCC wishes to resend its request, the same Request-ID-number MUST be used. Upon receiving a path computation request from a PCC with the same Request-ID-number, the PCE SHOULD treat the request as a new request. An implementation MAY choose to cache path computation replies in order to quickly handle retransmission without having to process a path computation request twice (in the case that the first request was dropped or lost). Upon receiving a path computation reply from a PCE with the same Request-ID-number, the PCC SHOULD silently discard the path computation reply.
いかなる経路計算応答がPCEから受信されない場合（例えば、要求があるため、メモリのオーバーフローのPCEによってドロップされ）、及びPCCはその要求を再送信することを望む、同じ要求-ID番号を使用しなければなりません。同じ要求-ID番号を有するPCCからパス計算要求を受信すると、PCEは、新しい要求としての要求を扱うべきです。実装は、すぐに（最初の要求が削除または失われた場合には）二回経路計算要求を処理することなく、再送を処理するために、キャッシュ経路計算返信することもできます。同じ要求-ID番号とPCEの経路計算応答を受信すると、PCCは、サイレントパス計算応答を破棄すべきです。
Conversely, different Request-ID-numbers MUST be used for different requests sent to a PCE.
逆に、異なる要求-IDナンバーは、PCEに送信された異なる要求のために使用されなければなりません。
The same Request-ID-number MAY be used for path computation requests sent to different PCEs. The path computation reply is unambiguously identified by the IP source address of the replying PCE.
同じ要求-ID番号は、別のPCEに送信された経路計算要求のために使用されるかもしれません。経路計算応答が明確に返信するのPCEのIP送信元アドレスによって識別されます。
If a PCReq message is received that does not contain an RP object, the PCE MUST send a PCErr message to the requesting PCC with Error-Type="Required Object missing" and Error-value="RP Object missing".
PCReqメッセージはRPオブジェクトが含まれていませんが受信される場合は、PCEは、エラー・タイプ=「欠けている必要なオブジェクト」とエラー値は=「RPオブジェクト欠落している」と要求してPCCにPCErrメッセージを送らなければなりません。
If the O bit of the RP message carried within a PCReq message is cleared and local policy has been configured on the PCE to not provide explicit paths (for instance, for confidentiality reasons), a PCErr message MUST be sent by the PCE to the requesting PCC and the pending path computation request MUST be discarded. The Error-Type is "Policy Violation" and Error-value is "O bit cleared".
PCReqメッセージの中で運ばRPメッセージのOビットがクリアされ、ローカルポリシーは、（例えば、機密性の理由のために）明示的なパスを提供しないようにPCEに構成されている場合、PCErrメッセージが要求するPCEによって送信されなければなりませんPCCとペンディング経路計算要求は破棄されなければなりません。エラー・タイプは、「ポリシー違反」であるとエラー値は、「Oビットがクリア」です。
When the R bit of the RP object is set in a PCReq message, this indicates that the path computation request relates to the reoptimization of an existing TE LSP. In this case, the PCC MUST also provide the strict/loose path by including an RRO object in the PCReq message so as to avoid/limit double-bandwidth counting if and only if the TE LSP is a non-zero-bandwidth TE LSP. If the PCC has not requested a strict path (O bit set), a reoptimization can still be requested by the PCC, but this requires that the PCE either be stateful (keep track of the previously computed path with the associated list of strict hops), or have the ability to retrieve the complete required path segment. Alternatively, the PCC MUST inform the PCE about the working path and the associated list of strict hops in PCReq. The absence of an RRO in the PCReq message for a non-zero-bandwidth TE LSP (when the R bit of the RP object is set) MUST trigger the sending of a PCErr message with Error-Type="Required Object Missing" and Error-value="RRO Object missing for reoptimization".
RPオブジェクトのRビットがPCReqメッセージに設定されている場合、これは、経路計算要求は、既存のTE LSPの再最適化に関連することを示しています。この場合ならば/リミット二重帯域幅カウントを回避するように、PCCはまたPCReqメッセージにRROオブジェクトを含むによって厳密/緩いパスを提供しなければなりませんし、TE LSPは、非ゼロ帯域幅TE LSPである場合にのみ。 PCCは、厳密な経路（Oビットセット）を要求していない場合、再最適化は依然としてPCCによって要求することができるが、これはPCEのいずれかが、ステートフルである（厳密ホップの関連するリストと以前に計算された経路を追跡する）ことが必要、または完全な必要なパスセグメントを取得する機能を持っています。代替的に、PCCは、現用パスとPCReqにおける厳密ホップの関連リストについてPCEに通知しなければなりません。 （RPオブジェクトのRビットがセットされている）は、非ゼロ帯域幅TE LSPのためPCReqメッセージにRROが存在しないことは、エラータイプ=「必要なオブジェクトの欠落」とエラーとPCErrメッセージの送信をトリガしなければなりません - 値=「RROオブジェクト再最適化のために不足しています」。
If a PCC/PCE receives a PCRep/PCReq message that contains an RP object referring to an unknown Request-ID-number, the PCC/PCE MUST send a PCErr message with Error-Type="Unknown request reference". This is used for debugging purposes. If a PCC/PCE receives PCRep/ PCReq messages with unknown requests at a rate equal or greater than MAX-UNKNOWN-REQUESTS unknown requests per minute, the PCC/PCE MUST send a PCEP CLOSE message with close value="Reception of an unacceptable number of unknown requests/replies". A RECOMMENDED value for MAX-UNKNOWN-REQUESTS is 5. The PCC/PCE MUST close the TCP session and MUST NOT send any further PCEP messages on the PCEP session.
PCC / PCEが未知のリクエスト-ID番号を参照するRPオブジェクトを含むPCRep / PCReqメッセージを受信した場合、PCC / PCEは、エラー・タイプ=「不明な要求の参照」でPCErrメッセージを送らなければなりません。これは、デバッグの目的のために使用されています。 PCC / PCEが毎分MAX-UNKNOWN-REQUESTS未知の要求よりも同等以上の速度で、未知の要求にPCRep / PCReqメッセージを受信した場合、PCC / PCEは、許容できない数の= "受信近い値PCEP CLOSEメッセージを送らなければなりません不明な要求の/」応答します。 MAX-UNKNOWN-REQUESTSの推奨値はPCC / PCEは、TCPセッションを閉じる必要がありますし、PCEPセッションについて、さらにPCEPメッセージを送ってはいけません5です。
The reception of a PCEP message that contains an RP object referring to a Request-ID-number=0x00000000 MUST be treated in similar manner as an unknown request.
= 0x00000000のが未知の要求と同様に処理しなければならない要求-ID番号を参照RPオブジェクトを含むPCEPメッセージの受信。
The NO-PATH object is used in PCRep messages in response to an unsuccessful path computation request (the PCE could not find a path satisfying the set of constraints). When a PCE cannot find a path satisfying a set of constraints, it MUST include a NO-PATH object in the PCRep message.
NO-PATHオブジェクトが失敗した経路計算要求に応じてPCRepメッセージで使用されている（PCEは、制約のセットを満足するパスを見つけることができませんでした）。 PCEは、制約のセットを満足するパスを見つけることができない場合、それはPCRepメッセージにNO-Pathオブジェクトを含まなければなりません。
There are several categories of issue that can lead to a negative reply. For example, the PCE chain might be broken (should there be more than one PCE involved in the path computation) or no path obeying the set constraints could be found. The "NI (Nature of Issue)" field in the NO-PATH object is used to report the error category.
負の応答につながる可能性の問題のいくつかのカテゴリがあります。例えば、PCEチェーンが破損する可能性がある（経路計算に関与する複数のPCEがなければならない）、またはセットの制約に従うないパスが見つかりませんでした。 「NI（問題の性質）、」NO-PATHオブジェクト内のフィールドは、エラーのカテゴリを報告するために使用されます。
Optionally, if the PCE supports such capability, the NO-PATH object MAY contain an optional NO-PATH-VECTOR TLV defined below and used to provide more information on the reasons that led to a negative reply. The PCRep message MAY also contain a list of objects that specify the set of constraints that could not be satisfied. The PCE MAY just replicate the set of objects that was received that was the cause of the unsuccessful computation or MAY optionally report a suggested value for which a path could have been found (in which case, the value differs from the value in the original request).
PCEは、このような機能をサポートしている場合、必要に応じて、NO-PATHオブジェクトは、以下のように定義し、負の応答につながっの理由に関する詳細な情報を提供するために使用されるオプションNO-PATH-VECTOR TLVを含むかもしれません。 PCRepメッセージも満たすことができませんでした制約のセットを指定したオブジェクトのリストを含むことができます。 PCEはちょうどそれが失敗した計算の原因となったか、必要に応じて、その場合には、値が元の要求で値とは異なる（パスが発見されている可能性があるため推奨値を報告することが受信されたオブジェクトのセットを複製し得ます）。
NO-PATH Object-Class is 3.
NO-PATHオブジェクトクラスは3です。
NO-PATH Object-Type is 1.
NO-PATHオブジェクト・タイプは1です。
The format of the NO-PATH object body is as follows:
次のようにNO-PATH対象体の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Nature of Issue|C| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: NO-PATH Object Format
図11：NO-PATHオブジェクトフォーマット
NI - Nature of Issue (8 bits): The NI field is used to report the nature of the issue that led to a negative reply. Two values are currently defined:
NI - 問題の性質（8ビット）：NIフィールドが負の応答につながった問題の性質を報告するために使用されます。 2つの値が現在定義されています：
0: No path satisfying the set of constraints could be found
0：制約のセットを満たすませパスが見つかりませんでした
1: PCE chain broken
1：PCE鎖破断
The Nature of Issue field value can be used by the PCC for various purposes:
問題のフィールド値の自然は様々な目的のためにPCCで使用することができます。
* Constraint adjustment before reissuing a new path computation request,
*新しい経路計算要求を再発行する前に、制約の調整、
* Explicit selection of a new PCE chain,
*新しいPCEチェーンを明示的に選択、
* Logging of the error type for further action by the network administrator.
*ネットワーク管理者による更なる行動のためのエラータイプのロギング。
IANA management of the NI field codespace is described in Section 9.
NIフィールドコードスペースのIANA管理は、セクション9に記載されています。
Flags (16 bits).
フラグ（16ビット）。
The following flag is currently defined:
以下のフラグは、現在定義されています。
o C flag (1 bit): when set, the PCE indicates the set of unsatisfied constraints (reasons why a path could not be found) in the PCRep message by including the relevant PCEP objects. When cleared, no failing constraints are specified. The C flag has no meaning and is ignored unless the NI field is set to 0x00.
O Cフラグ（1ビット）：設定した場合、PCEは、関連PCEPオブジェクトを含めることによって、PCRepメッセージに不満制約（パスが見つからなかった理由）の集合を示します。クリアすると、何ができない制約が指定されていません。 Cフラグは意味を持ちませんし、NIフィールドが0x00に設定されていない限り無視されます。
Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt.
予約済みとして割り当てられていないビットが考慮されます。彼らは、送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
Reserved (8 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約（8ビット）：このフィールドは、送信にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
The NO-PATH object body has a variable length and may contain additional TLVs. The only TLV currently defined is the NO-PATH-VECTOR TLV defined below.
NO-PATHオブジェクト本体は、可変の長さを有し、追加のTLVを含んでいてもよいです。現在定義されている唯一のTLVは、以下のように定義さNO-PATH-VECTOR TLVです。
Example: consider the case of a PCC that sends a path computation request to a PCE for a TE LSP of X Mbit/s. Suppose that PCE cannot find a path for X Mbit/s. In this case, the PCE must include in the PCRep message a NO-PATH object. Optionally, the PCE may also include the original BANDWIDTH object so as to indicate that the reason for the unsuccessful computation is the bandwidth constraint (in this case, the NI field value is 0x00 and C flag is set). If the PCE supports such capability, it may alternatively include the BANDWIDTH object and report a value of Y in the bandwidth field of the BANDWIDTH object (in this case, the C flag is set) where Y refers to the bandwidth for which a TE LSP with the same other characteristics (such as Setup/Holding priorities, TE LSP attribute, local protection, etc.) could have been computed.
例：Xメガビット/秒のTE LSPのためのPCEに経路計算要求を送信PCCの場合を考えます。 PCEは、Xメガビット/秒のパスを見つけることができないと仮定する。この場合、PCEはPCRepメッセージにNO-Pathオブジェクトを含まなければなりません。失敗した計算のための理由は、帯域幅の制約（この場合には、NIフィールドの値が0x00であり、Cフラグがセットされている）であることを示すように、任意に、PCEはまた、元の帯域幅のオブジェクトを含むことができます。 PCEは、そのような機能をサポートしている場合、それは、代わりに帯域幅オブジェクトを含み、帯域幅オブジェクトの帯域幅フィールドのYの値を報告してもよい（この場合には、Cフラグがセットされている）、Yは用TE LSP帯域幅を指し（等セットアップ/ホールディング優先順位、TE LSP属性、ローカル保護など）同一の他の特性は、計算された可能性を有します。
When the NO-PATH object is absent from a PCRep message, the path computation request has been fully satisfied and the corresponding paths are provided in the PCRep message.
NO-PATHオブジェクトはPCRepメッセージに存在しない場合、経路計算リクエストが完全に満たされており、対応するパスがPCRepメッセージで提供されます。
An optional TLV named NO-PATH-VECTOR MAY be included in the NO-PATH object in order to provide more information on the reasons that led to a negative reply.
NO-PATH-VECTORという名前のないオプションのTLVは、負の応答につながっの理由に関する詳細な情報を提供するために、NO-PATHの対象に含まれるかもしれません。
The NO-PATH-VECTOR TLV is compliant with the PCEP TLV format defined in Section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying the TLV length (length of the value portion in bytes) followed by a fixed-length 32-bit flags field.
NO-PATHベクターTLVは、セクション7.1で定義されたPCEP TLVフォーマットに準拠しており、固定長32に続くタイプの2バイト、TLVの長さ（バイト単位の値部分の長さ）を指定する2バイトで構成されていますビットのフラグフィールド。
Type: 1 Length: 4 bytes Value: 32-bit flags field
タイプ：1本の長さ：4バイト値：32ビットのフラグフィールド
IANA manages the space of flags carried in the NO-PATH-VECTOR TLV (see Section 9).
IANA（セクション9を参照）NO-PATH-VECTOR TLVで運ばれた旗のスペースを管理します。
The following flags are currently defined:
以下のフラグは、現在定義されています。
o Bit number: 31 - PCE currently unavailable
Oビット数：31 - PCE現在使用できません
o Bit number: 30 - Unknown destination
Oビット数：30 - 未知の宛先
o Bit number: 29 - Unknown source
Oビット数：29 - 不明なソース
The END-POINTS object is used in a PCReq message to specify the source IP address and the destination IP address of the path for which a path computation is requested. The P flag of the END-POINTS object MUST be set. If the END-POINTS object is received with the P flag cleared, the receiving peer MUST send a PCErr message with Error-Type=10 and Error-value=1. The corresponding path computation request MUST be cancelled by the PCE without further notification.
エンドポイントオブジェクトは、送信元IPアドレスと経路計算が要求されているパスの宛先IPアドレスを指定するPCReqメッセージで使用されています。エンドポイントオブジェクトのPフラグを設定しなければなりません。エンドポイントオブジェクトは、Pフラグをクリアして受信された場合、受信ピアは、エラータイプ= 10、エラー値= 1とPCErrメッセージを送らなければなりません。対応する経路計算要求は、さらに、通知なしPCEによって相殺されなければなりません。
Note that the source and destination addresses specified in the END-POINTS object may correspond to the source and destination IP address of the TE LSP or to those of a path segment. Two END-POINTS objects (for IPv4 and IPv6) are defined.
エンドポイント・オブジェクトに指定された送信元アドレスと宛先アドレスは、TE LSPの送信元および宛先IPアドレスまたはパスセグメントのものに対応してもよいことに留意されたいです。 （IPv4とIPv6のための）二エンドポイントオブジェクトが定義されています。
END-POINTS Object-Class is 4.
エンドポイントのオブジェクトクラスは4です。
END-POINTS Object-Type is 1 for IPv4 and 2 for IPv6.
エンドポイントオブジェクトタイプは、IPv6のためのIPv4の1と2です。
The format of the END-POINTS object body for IPv4 (Object-Type=1) is as follows:
エンドポイントの形式は、IPv4（オブジェクトタイプ= 1）のための身体オブジェクト以下の通りであります：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: END-POINTS Object Body Format for IPv4
図12：エンドポイントは、IPv4のためのボディフォーマットオブジェクト
The format of the END-POINTS object for IPv6 (Object-Type=2) is as follows:
エンドポイントの形式は、IPv6（オブジェクトタイプ= 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: END-POINTS Object Body Format for IPv6
図13：エンドポイントは、IPv6のためのボディフォーマットオブジェクト
The END-POINTS object body has a fixed length of 8 bytes for IPv4 and 32 bytes for IPv6.
エンドポイントオブジェクト本体は、IPv4用の8バイト、IPv6のための32バイトの固定長を有します。
If more than one END-POINTS object is present, the first MUST be processed and subsequent objects ignored.
複数のエンドポイント・オブジェクトが存在する場合、最初に処理されなければならないと後続のオブジェクトが無視します。
The BANDWIDTH object is used to specify the requested bandwidth for a TE LSP. The notion of bandwidth is similar to the one used for RSVP signaling in [RFC2205], [RFC3209], and [RFC3473].
帯域幅のオブジェクトは、TE LSPのために要求された帯域幅を指定するために使用されます。帯域幅の概念は、[RFC2205]、[RFC3209]及び[RFC3473]をにRSVPシグナリングのために使用されるものと同様です。
If the requested bandwidth is equal to 0, the BANDWIDTH object is optional. Conversely, if the requested bandwidth is not equal to 0, the PCReq message MUST contain a BANDWIDTH object.
要求された帯域幅が0に等しい場合、帯域幅のオブジェクトはオプションです。要求帯域が0に等しくない場合は逆に、PCReqメッセージは、帯域幅オブジェクトを含まなければなりません。
In the case of the reoptimization of a TE LSP, the bandwidth of the existing TE LSP MUST also be included in addition to the requested bandwidth if and only if the two values differ. Consequently, two Object-Type values are defined that refer to the requested bandwidth and the bandwidth of the TE LSP for which a reoptimization is being performed.
2つの値が異なる場合だけTE LSPの再最適化の場合には、既存のTE LSPの帯域幅はまた、要求された帯域幅に加えて含まなければなりません。その結果、2つのObject型の値は、要求された帯域幅および再最適化が行われているTE LSPの帯域幅を指すように定義されています。
The BANDWIDTH object may be carried within PCReq and PCRep messages.
帯域幅のオブジェクトは、PCReqとPCRepメッセージの中に行うことができます。
BANDWIDTH Object-Class is 5.
帯域幅のオブジェクトクラスは5です。
Two Object-Type values are defined for the BANDWIDTH object:
2つのオブジェクト型の値は、帯域幅のオブジェクトのために定義されています。
o Requested bandwidth: BANDWIDTH Object-Type is 1.
O要求帯域幅：帯域幅のオブジェクトタイプが1です。
o Bandwidth of an existing TE LSP for which a reoptimization is requested. BANDWIDTH Object-Type is 2.
再最適化が要求されている既存のTE LSPのO帯域幅。帯域幅のオブジェクトタイプは2です。
The format of the BANDWIDTH object body is as follows:
次のように帯域幅対象体の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: BANDWIDTH Object Body Format
図14：帯域幅オブジェクト本体のフォーマット
Bandwidth (32 bits): The requested bandwidth is encoded in 32 bits in IEEE floating point format (see [IEEE.754.1985]), expressed in bytes per second. Refer to Section 3.1.2 of [RFC3471] for a table of commonly used values.
帯域幅（32ビット）：要求された帯域幅は、IEEE浮動小数点フォーマットで32ビットで符号化される（[IEEE.754.1985]参照）は、秒あたりのバイト数で表しました。一般的に使用される値の表については[RFC3471]のセクション3.1.2を参照。
The BANDWIDTH object body has a fixed length of 4 bytes.
BANDWIDTH対象体は、4バイトの固定長を有します。
The METRIC object is optional and can be used for several purposes.
METRICオブジェクトはオプションであり、いくつかの目的のために使用することができます。
In a PCReq message, a PCC MAY insert one or more METRIC objects:
PCReqメッセージでは、PCCは、一つ以上のMETRICのオブジェクトを挿入することができます。
o To indicate the metric that MUST be optimized by the path computation algorithm (IGP metric, TE metric, hop counts). Currently, three metrics are defined: the IGP cost, the TE metric (see [RFC3785]), and the number of hops traversed by a TE LSP.
経路計算アルゴリズム（IGPメトリック、TEメトリック、ホップ数）によって最適化されなければならない基準を示すために、O。 IGPコスト、TEメトリック（[RFC3785]を参照）、およびTE LSPによって横断ホップ数：現在、3つのメトリックが定義されます。
o To indicate a bound on the path cost that MUST NOT be exceeded for the path to be considered as acceptable by the PCC.
パスはPCCで許容できると見なされるために超えてはならないパスコスト上の結合を示すために、O。
In a PCRep message, the METRIC object MAY be inserted so as to provide the cost for the computed path. It MAY also be inserted within a PCRep with the NO-PATH object to indicate that the metric constraint could not be satisfied.
計算された経路のコストを提供するようにPCRepメッセージにメトリックオブジェクトが挿入されてもよいです。また、メトリック制約が満足できなかったことを示すために、NO-PATHオブジェクトとPCRep内に挿入することができます。
The path computation algorithmic aspects used by the PCE to optimize a path with respect to a specific metric are outside the scope of this document.
特定のメトリックに対するパスを最適化するPCEによって使用される経路計算アルゴリズムの態様は、この文書の範囲外です。
It must be understood that such path metrics are only meaningful if used consistently: for instance, if the delay of a computed path segment is exchanged between two PCEs residing in different domains, consistent ways of defining the delay must be used.
計算された経路セグメントの遅延が異なるドメインに存在する2つのPCEの間で交換された場合、例えば、遅延を定義する一貫した方法が使用されなければならない：一貫して使用する場合には、このようなパスメトリックのみ意味があることを理解しなければなりません。
The absence of the METRIC object MUST be interpreted by the PCE as a path computation request for which no constraints need be applied to any of the metrics.
METRICオブジェクトが存在しないことには制約がメトリックのいずれにも適用する必要がないそのため、経路計算要求としてPCEによって解釈されなければなりません。
METRIC Object-Class is 6.
METRICオブジェクトクラスは6です。
METRIC Object-Type is 1.
METRICオブジェクト型は1です。
The format of the METRIC object body is as follows:
次のようにMETRIC対象体の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |C|B| T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metric-value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: METRIC Object Body Format
図15：METRICオブジェクト本体のフォーマット
The METRIC object body has a fixed length of 8 bytes.
METRICオブジェクト本体は8バイトの固定長を有します。
Reserved (16 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
（16ビット）予約：このフィールドは、送信にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
T (Type - 8 bits): Specifies the metric type.
T（タイプ - 8ビット）：メトリックのタイプを指定します。
Three values are currently defined: * T=1: IGP metric * T=2: TE metric * T=3: Hop Counts
3つの値が現在定義されている：* T = 1：IGPメトリックは、* T = 2：TEメトリック* T = 3：ホップカウント
Flags (8 bits): Two flags are currently defined:
フラグ（8ビット）：2つのフラグは、現在定義されています。
* B (Bound - 1 bit): When set in a PCReq message, the metric-value indicates a bound (a maximum) for the path metric that must not be exceeded for the PCC to consider the computed path as acceptable. The path metric must be less than or equal to the value specified in the metric-value field. When the B flag is cleared, the metric-value field is not used to reflect a bound constraint.
* B（バウンド - 1ビット）：PCReqメッセージに設定されている場合、メトリック値は、PCCが許容されるように計算経路を検討するために超えてはならないパスメトリックのバウンド（最大値）を示しています。パスメトリックは、メトリック値フィールドで指定された値以下でなければなりません。 Bフラグがクリアされると、メトリック値フィールドは、バインドされた制約を反映するために使用されません。
* C (Computed Metric - 1 bit): When set in a PCReq message, this indicates that the PCE MUST provide the computed path metric value (should a path satisfying the constraints be found) in the PCRep message for the corresponding metric.
* C（計算されたメトリック - 1ビット）：PCReqメッセージに設定されている場合、これは、PCEは、対応するメトリックのPCRepメッセージ内（制約条件を満たすパスが見つからなければならない）計算された経路メトリック値を提供しなければならないことを示しています。
Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt.
未割り当てのフラグは送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
Metric-value (32 bits): metric value encoded in 32 bits in IEEE floating point format (see [IEEE.754.1985]).
メトリック値（32ビット）IEEE浮動小数点フォーマットで32ビットで符号化されたメトリック値（[IEEE.754.1985]参照）。
Multiple METRIC objects MAY be inserted in a PCRep or a PCReq message for a given request (i.e., for a given RP). For a given request, there MUST be at most one instance of the METRIC object for each metric type with the same B flag value. If, for a given request, two or more instances of a METRIC object with the same B flag value are present for a metric type, only the first instance MUST be considered and other instances MUST be ignored.
複数METRICオブジェクトはPCRep又は（即ち、所与のRP用）指定された要求のPCReqメッセージに挿入することができます。特定の要求のために、同じBのフラグ値と各メトリックタイプのメトリックオブジェクトの最大1つのインスタンスが存在しなければなりません。特定の要求のために、同一のBフラグ値METRIC物体の2つの以上のインスタンスがメトリックタイプのために存在している、場合、最初のインスタンスだけが考慮されなければならないし、他のインスタンスは無視しなければなりません。
For a given request, the presence of two METRIC objects of the same type with a different value of the B flag is allowed. Furthermore, it is also allowed to insert, for a given request, two METRIC objects with different types that have both their B flag cleared: in this case, an objective function must be used by the PCE to solve a multi-parameter optimization problem.
特定の要求のために、Bフラグの異なる値を持つ同じタイプの2つのメトリックオブジェクトの存在が許容されます。さらに、また、挿入させ、特定の要求のために、彼らのBフラグをクリアしている両方の異なるタイプを持つ2つのメトリックのオブジェクトがこの場合に、目的関数は、マルチパラメータ最適化問題を解決するPCEによって使用されなければなりません。
A METRIC object used to indicate the metric to optimize during the path computation MUST have the B flag cleared and the C flag set to the appropriate value. When the path computation relates to the reoptimization of an exiting TE LSP (in which case, the R flag of the RP object is set), an implementation MAY decide to set the metric-value field to the computed value of the metric of the TE LSP to be reoptimized with regards to a specific metric type.
経路計算の間に最適化するメトリックを示すために使用されるメトリックの目的は、適切な値に設定クリアBフラグとCフラグを持たなければなりません。経路計算が出るTE LSP（この場合には、RPオブジェクトのRフラグがセットされている）の再最適化に関連する場合、実装は、TEのメトリックの計算値にメトリック値フィールドを設定することを決定することができますLSPは、特定のメトリックタイプに関して再最適化することができます。
A METRIC object used to reflect a bound MUST have the B flag set, and the C flag and metric-value field set to the appropriate values.
バウンドを反映するために使用されるメトリックの目的は、Bフラグを設定する必要があり、およびCフラグとメトリック値フィールドが適切な値に設定します。
In a PCRep message, unless not allowed by PCE policy, at least one METRIC object MUST be present that reports the computed path metric if the C flag of the METRIC object was set in the corresponding path computation request (the B flag MUST be cleared). The C flag has no meaning in a PCRep message. Optionally, the PCRep message MAY contain additional METRIC objects that correspond to bound constraints; in which case, the metric-value MUST be equal to the corresponding computed path metric (the B flag MUST be set). If no path satisfying the constraints could be found by the PCE, the METRIC objects MAY also be present in the PCRep message with the NO-PATH object to indicate the constraint metric that could be satisfied.
PCEポリシーによって許可されていない場合を除きPCRepメッセージに、少なくとも1つのメトリックの目的は、メトリックオブジェクトのCフラグ（Bフラグをクリアしなければならない）対応するパス計算要求に設定された場合、計算パスメトリックを報告すること存在していなければなりません。 CフラグはPCRepメッセージには意味を持ちません。必要に応じて、PCRepメッセージは、バインドされた制約に対応する追加METRICオブジェクトを含む可能性があります。その場合、メトリック値は、対応する計算されたパスメトリック（Bフラグが設定されなければならない）に等しくなければなりません。制約条件を満たすパスがPCEによって発見できなかった場合、METRICオブジェクトも満足することができ、制約メトリックを示すNO-PATHオブジェクトとPCRepメッセージ中に存在してもよいです。
Example: if a PCC sends a path computation request to a PCE where the metric to optimize is the IGP metric and the TE metric must not exceed the value of M, two METRIC objects are inserted in the PCReq message:
例：PCCを最適化するメトリックをIGPメトリックとTEメトリックは、2メートルのオブジェクトがPCReqメッセージに挿入され、Mの値を超えてはならないでPCEへの経路計算リクエストを送信した場合。
o First METRIC object with B=0, T=1, C=1, metric-value=0x0000
B = 0、T = 1、C = 1とO最初のメトリックオブジェクト、メトリック値= 0000
o Second METRIC object with B=1, T=2, metric-value=M
B = 1、T = 2、メトリック値とO第メトリックオブジェクトM =
If a path satisfying the set of constraints can be found by the PCE and there is no policy that prevents the return of the computed metric, the PCE inserts one METRIC object with B=0, T=1, metric-value= computed IGP path cost. Additionally, the PCE may insert a second METRIC object with B=1, T=2, metric-value= computed TE path cost.
制約のセットを満足する経路がPCEによって発見することができ、計算されたメトリックの戻りを防止するポリシーが存在しない場合、PCEは、B = 0、T = 1、メトリック値=計算IGPパスと1つのメトリックオブジェクトを挿入しますコスト。また、PCEは、B = 1、T = 2、メトリック値=計算TEパスコストを有する第二メトリックオブジェクトを挿入することができます。
The ERO is used to encode the path of a TE LSP through the network. The ERO is carried within a PCRep message to provide the computed TE LSP if the path computation was successful.
EROは、ネットワークを介してTE LSPの経路を符号化するために使用されます。 EROは、経路計算が成功した場合、計算TE LSPを提供するためにPCRepメッセージの中で運ばれます。
The contents of this object are identical in encoding to the contents of the Resource Reservation Protocol Traffic Engineering Extensions (RSVP-TE) Explicit Route Object (ERO) defined in [RFC3209], [RFC3473], and [RFC3477]. That is, the object is constructed from a series of sub-objects. Any RSVP-TE ERO sub-object already defined or that could be defined in the future for use in the RSVP-TE ERO is acceptable in this object.
このオブジェクトの内容は、リソース予約プロトコル・トラフィックエンジニアリングの拡張（RSVP-TE）を、[RFC3209]、[RFC3473]及び[RFC3477]で定義された明示的経路オブジェクト（ERO）の内容に符号化において同一です。つまり、オブジェクトは、サブオブジェクトのシリーズから構成されています。任意RSVP-TE EROサブオブジェクト既に定義された、またはそれがRSVP-TE EROにおける使用のために将来的に定義することができるが、この目的に許容可能です。
PCEP ERO sub-object types correspond to RSVP-TE ERO sub-object types.
PCEP EROサブオブジェクトタイプはEROサブオブジェクトタイプ-TEをRSVPに対応します。
Since the explicit path is available for immediate signaling by the MPLS or GMPLS control plane, the meanings of all of the sub-objects and fields in this object are identical to those defined for the ERO.
明示的なパスは、MPLS又はGMPLS制御プレーンによる即時シグナリングのために利用可能であるため、このオブジェクトのサブオブジェクトおよびフィールドのすべての意味はEROに対して定義されたものと同一です。
ERO Object-Class is 7.
EROオブジェクトクラスは7です。
ERO Object-Type is 1.
EROオブジェクト・タイプは1です。
The RRO is exclusively carried within a PCReq message so as to report the route followed by a TE LSP for which a reoptimization is desired.
再最適化が望まれるTE LSPに続く経路を報告するようにRROは、もっぱらPCReqメッセージの中で運ばれます。
The contents of this object are identical in encoding to the contents of the Route Record Object defined in [RFC3209], [RFC3473], and [RFC3477]. That is, the object is constructed from a series of sub-
このオブジェクトの内容は、[RFC3209]、[RFC3473]及び[RFC3477]で定義されたルートレコードオブジェクトの内容に符号化において同一です。これは、オブジェクトがサブのシリーズから構成されています
objects. Any RSVP-TE RRO sub-object already defined or that could be defined in the future for use in the RSVP-TE RRO is acceptable in this object.
オブジェクト。任意RSVP-TE RROサブオブジェクト既に定義された、またはそれがRSVP-TE RROで使用するために、将来的に定義することができるが、この目的に許容可能です。
The meanings of all of the sub-objects and fields in this object are identical to those defined for the RSVP-TE RRO.
このオブジェクトのサブオブジェクトおよびフィールドのすべての意味はRSVP-TE RROに対して定義されたものと同一です。
PCEP RRO sub-object types correspond to RSVP-TE RRO sub-object types.
PCEP RROサブオブジェクトタイプはRROサブオブジェクトタイプ-TEをRSVPに対応します。
RRO Object-Class is 8.
RROオブジェクトクラスは8です。
RRO Object-Type is 1.
RROオブジェクト・タイプは1です。
The LSPA (LSP Attributes) object is optional and specifies various TE LSP attributes to be taken into account by the PCE during path computation. The LSPA object can be carried within a PCReq message, or a PCRep message in case of unsuccessful path computation (in this case, the PCRep message also contains a NO-PATH object, and the LSPA object is used to indicate the set of constraints that could not be satisfied). Most of the fields of the LSPA object are identical to the fields of the SESSION-ATTRIBUTE object (C-Type = 7) defined in [RFC3209] and [RFC4090]. When absent from the PCReq message, this means that the Setup and Holding priorities are equal to 0, and there are no affinity constraints. See Section 4.7.4 of [RFC3209] for a detailed description of the use of resource affinities.
LSPA（LSP属性）オブジェクトは任意であり、種々のTE LSPは、経路計算中PCEによって考慮されるべき属性を指定します。 LSPAオブジェクトがPCReqメッセージ、またはこの場合に失敗経路計算の場合にPCRepメッセージ（内で実施することができ、PCRepメッセージはまた、NO-PATHオブジェクトを含み、LSPAオブジェクトは、制約のセットを示すために使用されます）を満足することができませんでした。 LSPAオブジェクトのフィールドの大部分は、[RFC3209]及び[RFC4090]で定義されたセッション属性オブジェクト（Cタイプ= 7）のフィールドと同じです。場合不在PCReqメッセージから、このセットアップ及び保持優先度が0に等しく、非親和性の制約が存在しないことを意味します。リソースの親和性の使用の詳細については、[RFC3209]のセクション4.7.4を参照してください。
LSPA Object-Class is 9.
LSPAオブジェクトクラスは9です。
LSPA Object-Types is 1.
LSPAオブジェクト・タイプ1です。
The format of the LSPA object body is:
LSPAオブジェクト本体の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags |L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: LSPA Object Body Format
図16：LSPAオブジェクト本体のフォーマット
Setup Prio (Setup Priority - 8 bits): The priority of the TE LSP with respect to taking resources, in the range of 0 to 7. The value 0 is the highest priority. The Setup Priority is used in deciding whether this session can preempt another session.
セットアッププリオ（セットアッププライオリティ - 8ビット）：0〜7の値0の範囲内のリソースを取るに対するTE LSPの優先順位は、最高の優先順位です。セットアップの優先順位は、このセッションは別のセッションを先取りできるかどうかを決定する際に使用されています。
Holding Prio (Holding Priority - 8 bits): The priority of the TE LSP with respect to holding resources, in the range of 0 to 7. The value 0 is the highest priority. Holding Priority is used in deciding whether this session can be preempted by another session.
保持プリオ（保持優先度 - 8ビット）：0値7までの範囲で、リソースを保持に対するTE LSPの優先順位が最優先です。保持優先順位は、このセッションが別のセッションによってプリエンプトできるかどうかを決定するのに使用されています。
Flags (8 bits)
フラグ（8ビット）
L flag: Corresponds to the "Local Protection Desired" bit ([RFC3209]) of the SESSION-ATTRIBUTE Object. When set, this means that the computed path must include links protected with Fast Reroute as defined in [RFC4090].
Lフラグは：セッション属性オブジェクトの「所望の局所保護」ビット（[RFC3209]）に対応します。設定されている場合、これは[RFC4090]で定義されるように計算された経路は、高速リルートで保護リンクを含まなければならないことを意味します。
Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt.
未割り当てのフラグは送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
Reserved (8 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約（8ビット）：このフィールドは、送信にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
Note that optional TLVs may be defined in the future to carry additional TE LSP attributes such as those defined in [RFC5420].
任意のTLVは、[RFC5420]で定義されるような属性の追加のTE LSPを運ぶために、将来的に定義されてもよいことに留意されたいです。
The IRO (Include Route Object) is optional and can be used to specify that the computed path MUST traverse a set of specified network elements. The IRO MAY be carried within PCReq and PCRep messages. When carried within a PCRep message with the NO-PATH object, the IRO indicates the set of elements that cause the PCE to fail to find a path.
IROは、（ルートオブジェクトを含む）オプションで、計算された経路が指定されたネットワーク要素のセットを横断しなければならないことを指定するために使用することができます。 IROはPCReqとPCRepメッセージの中に行うことができます。 NO-PATHオブジェクトにPCRepメッセージ内で搬送すると、IROは、パスを見つけるために失敗するPCEを引き起こす要素の集合を表します。
IRO Object-Class is 10.
IROオブジェクトクラスは10です。
IRO Object-Type is 1.
IROオブジェクト・タイプは1です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Sub-objects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: IRO Body Format
図17：IROボディフォーマット
Sub-objects: The IRO is made of sub-objects identical to the ones defined in [RFC3209], [RFC3473], and [RFC3477], where the IRO sub-object type is identical to the sub-object type defined in the related documents.
サブオブジェクト：IROは、[RFC3209]で定義されたものと同一のサブオブジェクト[RFC3473]で作られ、そして、[RFC3477]、IROサブオブジェクトタイプは、関連で定義されたサブオブジェクトのタイプと同じですドキュメント。
The following sub-object types are supported.
以下のサブオブジェクトタイプがサポートされています。
Type Sub-object
1 IPv4 prefix
2 IPv6 prefix
4 Unnumbered Interface ID
32 Autonomous system number
The L bit of such sub-object has no meaning within an IRO.
そのようなサブオブジェクトのLビットは、IRO内意味を持ちません。
Independent versus dependent path computation requests: path computation requests are said to be independent if they are not related to each other. Conversely, a set of dependent path computation requests is such that their computations cannot be performed independently of each other (a typical example of dependent requests is the computation of a set of diverse paths).
依存経路計算要求に対して独立：経路計算要求は、それらが相互に関連していない場合は独立していると言われています。逆に、依存経路計算要求のセットは、それらの計算が（依存要求の典型的な例は、多様な経路のセットの計算で）互いに独立して行うことができないようなものです。
Synchronized versus non-synchronized path computation requests: a set of path computation requests is said to be non-synchronized if their respective treatment (path computations) can be performed by a PCE in a serialized and independent fashion.
非同期経路計算要求に対する同期：経路計算要求のセットは、それぞれの処理（パス計算）をシリアライズおよび独立様式でPCEによって行うことができる場合、非同期であると言われます。
There are various circumstances where the synchronization of a set of path computations may be beneficial or required.
経路計算のセットの同期化が有益または必要であり得る様々な状況があります。
Consider the case of a set of N TE LSPs for which a PCC needs to send path computation requests to a PCE. The first solution consists of sending N separate PCReq messages to the selected PCE. In this case, the path computation requests are non-synchronized. Note that the PCC may chose to distribute the set of N requests across K PCEs for load balancing purposes. Considering that M (with M<N) requests are sent to a particular PCEi, as described above, such M requests can be sent in the form of successive PCReq messages destined to PCEi or bundled within a single PCReq message (since PCEP allows for the bundling of multiple path computation requests within a single PCReq message). That said, even in the case of independent requests, it can be desirable to request from the PCE the computation of their paths in a synchronized fashion that is likely to lead to more optimal path computations and/or reduced blocking probability if the PCE is a stateless PCE. In other words, the PCE should not compute the corresponding paths in a serialized and independent manner, but it should rather "simultaneously" compute their paths. For example, trying to "simultaneously" compute the paths of M TE LSPs may allow the PCE to improve the likelihood to meet multiple constraints.
PCCは、PCEへの経路計算リクエストを送信する必要があるためN TE LSPのセットの場合を考えます。第一の溶液は、選択されたPCEにN別個PCReqメッセージの送信から成ります。この場合、経路計算要求は非同期です。 PCCは、負荷分散の目的のためにK個のPCEを横切るN要求のセットを配布することを選択してもよいことに留意されたいです。上記のようにM（M <Nで）要求がPCEPのを可能にするため、このようなM要求が連続PCReqメッセージPCEi宛又は単一PCReqメッセージの中にバンドル（の形式で送信することができ、特定のPCEiに送信されることを考慮単一PCReqメッセージ内の複数の経路計算要求のバンドル）。すなわち、前記偶数独立要求の場合には、PCEからより最適経路の計算につながる可能性がある及び/又はPCEである場合の確率を遮断低減同期様式でそれらの経路の計算を要求することが望ましいですステートレスPCE。換言すれば、PCEは、シリアル化に依存しない方法で対応するパスを計算してはならないが、それはむしろ「同時に」は、それらの経路を計算すべきです。たとえば、「同時に」PCEは、複数の制約を満たすために可能性を改善することを可能にするM TE LSPの経路を計算しようとしています。
Consider the case of two TE LSPs requesting N1 Mbit/s and N2 Mbit/s, respectively, and a maximum tolerable end-to-end delay for each TE LSP of X ms. There may be circumstances where the computation of the first TE LSP, irrespectively of the second TE LSP, may lead to the impossibility to meet the delay constraint for the second TE LSP.
それぞれN1メガビット/秒を要求しN2 Mbit / sの2つのTE LSPの場合、及びX MSの各TE LSPのための最大許容エンドツーエンド遅延を考慮する。第1のTE LSPの計算は、無関係に第2のTE LSPの、第2のTE LSPのための遅延制約を満たすために不能につながり得る状況が存在してもよいです。
A second example is related to the bandwidth constraint. It is quite straightforward to provide examples where a serialized independent path computation approach would lead to the impossibility to satisfy both requests (due to bandwidth fragmentation), while a synchronized path computation would successfully satisfy both requests.
第二の例では、帯域幅の制約に関連しています。シリアル化された独立した経路計算アプローチが同期経路計算が正常に両方の要求を満足させるだろうが、（帯域幅断片化に起因）の両方の要求を満たすために不可能につながる例を提供することは極めて簡単です。
A last example relates to the ability to avoid the allocation of the same resource to multiple requests, thus helping to reduce the call setup failure probability compared to the serialized computation of independent requests.
最後の例は、このように独立した要求のシリアル化された計算と比較してコールセットアップ失敗確率を低減するのに役立つ、複数の要求に同じリソースの割り当てを回避する能力にも関します。
Dependent path computations are usually synchronized. For example, in the case of the computation of M diverse paths, if such paths are computed in a non-synchronized fashion, this seriously increases the probability of not being able to satisfy all requests (sometimes also referred to as the well-known "trapping problem").
依存パスの計算は、通常は同期されています。そのような経路が非同期方式で計算される場合、例えば、M多様な経路の計算の場合には、これは深刻なすべてのリクエスト（時々も周知と呼ぶ」を満たすことができない確率を増加させます）「問題をトラップします。
Furthermore, this would not allow a PCE to implement objective functions such as trying to minimize the sum of the TE LSP costs. In such a case, the path computation requests must be synchronized: they cannot be computed independently of each other.
さらに、これは、PCEが、そのようなTE LSPコストの合計を最小化しようとしているとして、目的関数を実装することができません。このような場合に、経路計算要求は同期されなければならない：それらは互いに独立して計算することができません。
Conversely, a set of independent path computation requests may or may not be synchronized.
逆に、独立した経路計算要求のセットは、または同期してもしなくてもよいです。
The synchronization of a set of path computation requests is achieved by using the SVEC object that specifies the list of synchronized requests that can either be dependent or independent.
経路計算要求のセットの同期は、依存性または非依存性のいずれかであることができる同期要求のリストを指定SVECオブジェクトを使用することによって達成されます。
PCEP supports the following three modes:
PCEPは、次の3つのモードをサポートしています。
o Bundle of a set of independent and non-synchronized path computation requests,
O独立した非同期経路計算要求のセットのバンドル、
o Bundle of a set of independent and synchronized path computation requests (requires the SVEC object defined below),
独立した同期経路計算リクエストの組のOバンドル（以下に定義SVECオブジェクトを必要とします）、
o Bundle of a set of dependent and synchronized path computation requests (requires the SVEC object defined below).
O依存と同期経路計算要求のセットのバンドルは、（以下に定義SVECオブジェクトが必要）。
Section 7.13.1 details the circumstances under which it may be desirable and/or required to synchronize a set of path computation requests. The SVEC (Synchronization VECtor) object allows a PCC to request the synchronization of a set of dependent or independent path computation requests. The SVEC object is optional and may be carried within a PCReq message.
セクション7.13.1は、それが望ましい及び/又は経路計算要求のセットを同期させるために必要であってもよいれる状況を詳述します。 SVEC（同期ベクトル）オブジェクトは、依存性または非依存性経路計算要求のセットの同期を要求するPCCを可能にします。 SVECオブジェクトはオプションであり、PCReqメッセージの中で運ばれてもよいです。
The aim of the SVEC object carried within a PCReq message is to request the synchronization of M path computation requests. The SVEC object is a variable-length object that lists the set of M path computation requests that must be synchronized. Each path computation request is uniquely identified by the Request-ID-number carried within the respective RP object. The SVEC object also contains a set of flags that specify the synchronization type.
PCReqメッセージ内で運ばSVECオブジェクトの目的は、M経路計算要求の同期を要求することです。 SVECオブジェクトは同期されなければならないM経路計算要求のセットを一覧表示し可変長オブジェクトです。各経路計算要求を一意各RPオブジェクト内に担持要求-ID番号によって識別されます。 SVECオブジェクトは、同期タイプを指定するフラグのセットを含みます。
SVEC Object-Class is 11.
SVECオブジェクトクラスは11です。
SVEC Object-Type is 1.
SVECオブジェクト・タイプは1です。
The format of the SVEC object body is as follows:
次のようにSVEC対象体の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |S|N|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number #1 |
// //
| Request-ID-number #M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: SVEC Body Object Format
図18：SVECボディオブジェクトフォーマット
Reserved (8 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約（8ビット）：このフィールドは、送信にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
Flags (24 bits): Defines the potential dependency between the set of path computation requests.
フラグ（24ビット）：経路計算要求のセットとの間の潜在的な依存関係を定義します。
* L (Link diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST NOT have any link in common.
* L（リンク多様な）ビット：セットが、これは次のRPオブジェクトによって指定された要求に対応する計算されたパスが共通のリンクを有してはならないことを示しています。
* N (Node diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST NOT have any node in common.
* N（ノード多様）ビット：設定すると、これは次のRPオブジェクトによって指定された要求に対応する計算されたパスが共通の任意のノードを有してはならないことを示しています。
* S (SRLG diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST NOT share any SRLG (Shared Risk Link Group).
* S（SRLG多様な）ビット：セットには、これは以下のRPオブジェクトによって指定された要求に対応する計算されたパスが任意のSRLG（共有リスクリンクグループ）を共有してはならないことを示します。
In case of a set of M synchronized independent path computation requests, the bits L, N, and S are cleared.
M同期独立経路計算リクエストの組の場合には、ビットL、N、及びSがクリアされます。
Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt.
未割り当てのフラグは送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
The flags defined above are not exclusive.
上記で定義されたフラグは排他的ではありません。
The SVEC object allows a PCC to specify a list of M path computation requests that MUST be synchronized along with a potential dependency. The set of M path computation requests may be sent within a single PCReq message or multiple PCReq messages. In the latter case, it is RECOMMENDED for the PCE to implement a local timer (called the
SVECオブジェクトは、PCCは、電位依存性と一緒に同期されなければならないM経路計算リクエストのリストを指定することを可能にします。 M経路計算要求のセットは、単一PCReqメッセージまたは複数PCReqメッセージ内で送信されてもよいです。後者の場合、それはローカルタイマを実装するPCEに推奨される（呼び出さ
SyncTimer) activated upon the receipt of the first PCReq message that contains the SVEC object after the expiration of which, if all the M path computation requests have not been received, a protocol error is triggered. When a PCE receives a path computation request that cannot be satisfied (for example, because the PCReq message contains an object with the P bit set that is not supported), the PCE sends a PCErr message for this request (see Section 7.2), the PCE MUST cancel the whole set of related path computation requests and MUST send a PCErr message with Error-Type="Synchronized path computation request missing".
SyncTimer）全てのM経路計算リクエストを受信していない場合、満了後SVECオブジェクトを含む第一PCReqメッセージ、プロトコルエラーがトリガされたの受信の際に活性化されました。 PCEは、（PCReqメッセージがサポートされていないPビットが設定されたオブジェクトが含まれているため、たとえば）を満足することができない経路計算リクエストを受信したとき、PCEは、この要求のPCErrメッセージを送信する（セクション7.2を参照）、 PCEは、関連する経路計算要求のセット全体をキャンセルする必要がありますし、エラー・タイプ=「不足している同期経路計算要求」とPCErrメッセージを送らなければなりません。
Note that such PCReq messages may also contain non-synchronized path computation requests. For example, the PCReq message may comprise N synchronized path computation requests that are related to RP 1, ..., RP N and are listed in the SVEC object along with any other path computation requests that are processed as normal.
このようPCReqメッセージはまた、非同期経路計算要求を含んでいてもよいことに注意してください。例えば、PCReqメッセージはRP 1、...、RP Nに関連しており、通常のように処理される任意の他の経路計算要求とともにSVECオブジェクトに記載されているN同期経路計算リクエストを含んでもよいです。
The NOTIFICATION object is exclusively carried within a PCNtf message and can either be used in a message sent by a PCC to a PCE or by a PCE to a PCC so as to notify of an event.
NOTIFICATIONオブジェクトは専らPCNtfメッセージ内に担持され、イベントを通知するようにいずれかのPCCにPCEまたはPCEによってPCCによって送信されたメッセージで使用することができます。
NOTIFICATION Object-Class is 12.
通知オブジェクトクラスは12です。
NOTIFICATION Object-Type is 1.
通知オブジェクト型は1です。
The format of the NOTIFICATION body object is as follows:
次のようにNOTIFICATION本体オブジェクトの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | NT | NV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: NOTIFICATION Body Object Format
図19：通知ボディオブジェクトフォーマット
Reserved (8 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約（8ビット）：このフィールドは、送信にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
Flags (8 bits): No flags are currently defined. Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt.
フラグ（8ビット）：いいえフラグが現在定義されています。未割り当てのフラグは送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
NT (Notification Type - 8 bits): The Notification-type specifies the class of notification.
NT（通知タイプ - 8ビット）：通知型通知のクラスを特定します。
NV (Notification Value - 8 bits): The Notification-value provides addition information related to the nature of the notification.
NV（通知値 - 8ビット）：通知の値は、通知の性質に関連する追加情報を提供します。
Both the Notification-type and Notification-value are managed by IANA.
どちらの通知タイプと通知-値はIANAによって管理されています。
The following Notification-type and Notification-value values are currently defined:
次の通知タイプと通知値の値が現在定義されています。
o Notification-type=1: Pending Request cancelled
O通知型= 1：保留中の要求が取り消さ
* Notification-value=1: PCC cancels a set of pending requests. A Notification-type=1, Notification-value=1 indicates that the PCC wants to inform a PCE of the cancellation of a set of pending requests. Such an event could be triggered because of external conditions such as the receipt of a positive reply from another PCE (should the PCC have sent multiple requests to a set of PCEs for the same path computation request), a network event such as a network failure rendering the request obsolete, or any other events local to the PCC. A NOTIFICATION object with Notification-type=1, Notification-value=1 is carried within a PCNtf message sent by the PCC to the PCE. The RP object corresponding to the cancelled request MUST also be present in the PCNtf message. Multiple RP objects may be carried within the PCNtf message; in which case, the notification applies to all of them. If such a notification is received by a PCC from a PCE, the PCC MUST silently ignore the notification and no errors should be generated.
*通知-値= 1：PCCは、保留中の要求のセットを取り消します。通知タイプ= 1、通知値= 1は、PCCは、保留中の要求のセットの解除のPCEに通知したいことを示しています。そのようなイベントがあるため、ネットワーク障害など、ネットワークイベント（PCCは、同じ経路計算要求のためのPCEのセットに複数の要求を送信しているはず）、このような別のPCEからの肯定応答の受信などの外部条件によってトリガすることができます廃止された要求、またはPCCへのローカル任意の他のイベントをレンダリングします。通知タイプ= 1、通知値= 1 NOTIFICATIONオブジェクトがPCEにPCCによって送らPCNtfメッセージ内で運ばれます。キャンセル要求に対応するRPオブジェクトは、PCNtfメッセージ内に存在していなければなりません。複数のRPオブジェクトはPCNtfメッセージ内で実施することができます。その場合には、通知はそれらのすべてに適用されます。そのような通知は、PCEからPCCによって受信される場合、PCCは、サイレント通知を無視しなければなりませんし、エラーが発生してはなりません。
* Notification-value=2: PCE cancels a set of pending requests. A Notification-type=1, Notification-value=2 indicates that the PCE wants to inform a PCC of the cancellation of a set of pending requests. A NOTIFICATION object with Notification-type=1, Notification-value=2 is carried within a PCNtf message sent by a PCE to a PCC. The RP object corresponding to the cancelled request MUST also be present in the PCNtf message. Multiple RP objects may be carried within the PCNtf message; in which case, the notification applies to all of them. If such notification is received by a PCE from a PCC, the PCE MUST silently ignore the notification and no errors should be generated.
*通知-値= 2：PCEは、保留中の要求のセットを取り消します。通知タイプ= 1、通知値= 2は、PCEが保留中の要求のセットの解除のPCCを知らせたいことを示しています。通知タイプ= 1、通知値= 2の通知オブジェクトは、PCCへPCEによって送信されたPCNtfメッセージ内で運ばれます。キャンセル要求に対応するRPオブジェクトは、PCNtfメッセージ内に存在していなければなりません。複数のRPオブジェクトはPCNtfメッセージ内で実施することができます。その場合には、通知はそれらのすべてに適用されます。そのような通知は、PCCからPCEにより受信された場合、PCEは、サイレント通知を無視しなければなりませんし、エラーが発生してはなりません。
o Notification-type=2: Overloaded PCE
O通知型= 2：オーバーロードPCE
* Notification-value=1: A Notification-type=2, Notification-
*通知値= 1：通知型= 2、はnotification-
value=1 indicates to the PCC that the PCE is currently in an overloaded state. If no RP objects are included in the PCNtf message, this indicates that no other requests SHOULD be sent to that PCE until the overloaded state is cleared: the pending requests are not affected and will be served. If some pending requests cannot be served due to the overloaded state, the PCE MUST also include a set of RP objects that identifies the set of pending requests that are cancelled by the PCE and will not be honored. In this case, the PCE does not have to send an additional PCNtf message with Notification-type=1 and Notification-value=2 since the list of cancelled requests is specified by including the corresponding set of RP objects. If such notification is received by a PCE from a PCC, the PCE MUST silently ignore the notification and no errors should be generated.
値= 1は、PCEが過負荷状態に現在あることをPCCに示します。保留中の要求が影響を受けず、提供されます：何のRPオブジェクトはPCNtfメッセージに含まれていない場合、これは他の要求が過負荷状態がクリアされるまで、そのPCEに送信すべきではないことを示しています。いくつかの保留中の要求が原因過負荷状態に提供することができない場合は、PCEはまた、PCEによってキャンセルされ、表彰されることはありません保留中の要求のセットを識別するRPオブジェクトのセットを含まなければなりません。この場合、PCEは、RPオブジェクトの対応するセットを含むによって指定されたキャンセル要求のリストので通知型= 1、通知値= 2を有する追加PCNtfメッセージを送信する必要がありません。そのような通知は、PCCからPCEにより受信された場合、PCEは、サイレント通知を無視しなければなりませんし、エラーが発生してはなりません。
* A PCE implementation SHOULD use a dual-threshold mechanism used to determine whether it is in a congestion state with regards to specific resource monitoring (e.g. CPU, memory). The use of such thresholds is to avoid oscillations between overloaded/ non-overloaded state that may result in oscillations of request targets by the PCCs.
* PCEの実装は、それが特定のリソース監視（例えばCPU、メモリ）に関して輻輳状態にあるかどうかを決定するために使用されるデュアル閾値メカニズムを使用すべきです。そのようなしきい値の使用は、のPCCによって要求対象の振動を生じ得る過負荷/無過負荷状態の間の振動を回避することです。
* Optionally, a TLV named OVERLOADED-DURATION may be included in the NOTIFICATION object that specifies the period of time during which no further request should be sent to the PCE. Once this period of time has elapsed, the PCE should no longer be considered in a congested state.
*任意には、TLV名前過負荷継続時間は、さらなる要求がPCEに送信されるべきではないれる期間を指定する通知オブジェクトに含まれていてもよいです。この時間が経過すると、PCEはもはや輻輳状態で考慮されるべきではありません。
The OVERLOADED-DURATION TLV is compliant with the PCEP TLV format defined in Section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying the TLV length (length of the value portion in bytes), followed by a fixed-length value field of a 32-bit flags field.
過負荷継続時間TLVは、セクション7.1で定義されたPCEP TLVフォーマットに準拠し、タイプに2バイトで構成され、TLVの長さ（バイト単位の値部分の長さ）を指定する2バイト固定長の値フィールドが続きます32ビットのフラグフィールドの。
Type: 2 Length: 4 bytes Value: 32-bit flags field indicates the estimated PCE congestion duration in seconds.
タイプ：2長さ：4バイト値：32ビットのフラグフィールドは、秒単位で推定PCE輻輳期間を示します。
* Notification-value=2: A Notification-type=2, Notification-value=2 indicates that the PCE is no longer in an overloaded state and is available to process new path computation requests. An implementation SHOULD make sure that a PCE sends such notification to every PCC to which a Notification message (with Notification-type=2, Notification-value=1) has been sent unless an OVERLOADED-DURATION TLV has been included in the corresponding message and the PCE wishes to wait for the expiration of that period of time before receiving new requests. If such notification is received by a PCE from a PCC, the PCE MUST silently ignore the notification and no errors should be generated. It is RECOMMENDED to support some dampening notification procedure on the PCE so as to avoid too frequent congestion state and congestion state release notifications. For example, an implementation could make use of an hysteresis approach using a dual-threshold mechanism that triggers the sending of congestion state notifications. Furthermore, in case of high instabilities of the PCE resources, an additional dampening mechanism SHOULD be used (linear or exponential) to pace the notification frequency and avoid oscillation of path computation requests.
*通知値= 2：通知型= 2、通知値= 2 PCEが過負荷状態でなくなると、新しい経路計算要求を処理するために利用可能であることを示していません。実装が確認PCEが過負荷継続時間TLVは、対応するメッセージに含まれていない限り、通知メッセージ（通知型= 2と、通知値= 1）が送信されてきたためにあらゆるPCCにそのような通知を送信していることを確認する必要がありPCEは、新しい要求を受信する前にその期間の満了を待つことを望みます。そのような通知は、PCCからPCEにより受信された場合、PCEは、サイレント通知を無視しなければなりませんし、エラーが発生してはなりません。あまりにも頻繁に輻輳状態と輻輳状態解除の通知を回避するために、PCEにいくつかの減衰通知手順をサポートすることをお勧めします。例えば、実装が輻輳状態の通知の送信をトリガーするデュアルしきい値のメカニズムを使用して、ヒステリシスアプローチを利用することができます。また、PCEリソースの高い不安定性の場合には、追加の減衰機構は、通知頻度をペースと経路計算要求の発振を回避するために、（線形または指数関数的）に使用されるべきです。
When a PCC receives an overload indication from a PCE, it should consider the impact on the entire network. It must be remembered that other PCCs may also receive the notification, and so many path computation requests could be redirected to other PCEs. This may, in turn, cause further overloading at PCEs in the network. Therefore, an application at a PCC receiving an overload notification should consider applying some form of back-off (e.g., exponential) to the rate at which it generates path computation requests into the network. This is especially the case as the number of PCEs reporting overload grows.
PCCは、PCEから過負荷指示を受信すると、ネットワーク全体への影響を考慮すべきです。他のPCCにも通知を受け取ることができるということを忘れてはならない、と非常に多くの経路計算要求は、他のPCEにリダイレクトすることができます。これは、順番に、さらにネットワーク内のPCEで過負荷を引き起こす可能性があります。従って、過負荷通知を受信PCCにおけるアプリケーションは、ネットワークへの経路計算リクエストを生成する速度に（例えば、指数関数的な）バックオフのいくつかのフォームを適用することを検討すべきです。これは成長の過負荷を報告するPCEの数としては特にそうです。
The PCEP-ERROR object is exclusively carried within a PCErr message to notify of a PCEP error.
PCEP-ERRORオブジェクトは専らPCEPエラーを通知するPCErrメッセージ内で運ばれます。
PCEP-ERROR Object-Class is 13.
PCEP-ERRORオブジェクトクラスは13です。
PCEP-ERROR Object-Type is 1.
PCEP-ERRORオブジェクト・タイプは1です。
The format of the PCEP-ERROR object body is as follows:
次のようにPCEP-ERRORオブジェクト本体の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | Error-Type | Error-value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: PCEP-ERROR Object Body Format
図20：PCEP-ERRORオブジェクト本体のフォーマット
A PCEP-ERROR object is used to report a PCEP error and is characterized by an Error-Type that specifies the type of error and an Error-value that provides additional information about the error type. Both the Error-Type and the Error-value are managed by IANA (see the IANA section).
PCEP-ERRORオブジェクトは、PCEPエラーを報告するために使用され、エラーの種類およびエラーのタイプに関する追加情報を提供するエラー値を指定するエラータイプによって特徴付けられます。エラー・タイプとエラー値の両方がIANA（IANAの項を参照）によって管理されています。
Reserved (8 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約（8ビット）：このフィールドは、送信にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
Flags (8 bits): no flag is currently defined. This flag MUST be set to zero on transmission and MUST be ignored on receipt.
フラグ（8ビット）：なしフラグは、現在定義されていません。このフラグは、送信にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
Error-Type (8 bits): defines the class of error.
エラータイプ（8ビット）：エラーのクラスを定義します。
Error-value (8 bits): provides additional details about the error.
エラー値（8ビット）：エラーに関する追加の詳細を提供します。
Optionally, the PCEP-ERROR object may contain additional TLVs so as to provide further information about the encountered error.
発生したエラーに関する詳細情報を提供するように、必要に応じて、PCEP-ERRORオブジェクトは、追加のTLVが含まれていてもよいです。
A single PCErr message may contain multiple PCEP-ERROR objects.
単一PCErrメッセージは、複数のPCEP-ERRORオブジェクトを含んでいてもよいです。
For each PCEP error, an Error-Type and an Error-value are defined.
各PCEPエラーのため、エラー・タイプとエラー値が定義されています。
Error-Type Meaning 1 PCEP session establishment failure Error-value=1: reception of an invalid Open message or a non Open message. Error-value=2: no Open message received before the expiration of the OpenWait timer Error-value=3: unacceptable and non-negotiable session characteristics Error-value=4: unacceptable but negotiable session characteristics Error-value=5: reception of a second Open message with still unacceptable session characteristics Error-value=6: reception of a PCErr message proposing unacceptable session characteristics Error-value=7: No Keepalive or PCErr message received before the expiration of the KeepWait timer 2 Capability not supported 3 Unknown Object Error-value=1: Unrecognized object class Error-value=2: Unrecognized object Type 4 Not supported object Error-value=1: Not supported object class Error-value=2: Not supported object Type 5 Policy violation Error-value=1: C bit of the METRIC object set (request rejected) Error-value=2: O bit of the RP object set (request rejected) 6 Mandatory Object missing Error-value=1: RP object missing Error-value=2: RRO object missing for a reoptimization request (R bit of the RP object set) when bandwidth is not equal to 0. Error-value=3: END-POINTS object missing 7 Synchronized path computation request missing 8 Unknown request reference 9 Attempt to establish a second PCEP session 10 Reception of an invalid object Error-value=1: reception of an object with P flag not set although the P flag must be set according to this specification.
エラー・タイプ意味1 PCEPセッション確立の失敗エラー値= 1：無効オープンメッセージの受信または非オープンメッセージ。エラー値= 2：OpenWaitタイマ誤差値の満了前に受信しないオープンメッセージ= 3：許容できない非交渉セッション特性誤差値= 4：許容できないが、交渉セッション特性誤差値= 5：の受信容認できないセッション特性エラー値= 7を提案PCErrメッセージの受信：いいえキープアライブまたはKeepWaitタイマ2機能の満了前に受信PCErrメッセージがサポートされていない3未知のオブジェクトエラー依然として許容できないセッション特性エラー値= 6を持つ第二のオープンメッセージ - 値= 1：認識されないオブジェクトクラスError-値= 2：サポートされていません認識されていないオブジェクトタイプ4オブジェクトエラー値= 1：オブジェクトクラスError-値= 2をサポートしていません：オブジェクトタイプ5ポリシー違反のエラー値= 1をサポートしていません。 RPオブジェクト欠落エラー値= 2：RROオブジェクトが欠落しているRPオブジェクトセット（要求が拒否）6必須オブジェクト欠落エラー値= 1のOビット：メトリックオブジェクトセット（要求拒否）エラー値= 2のCビット再最適化のための要求（RPオブジェクトセットのRビット）帯域幅は、0エラー値= 3と等しくない場合：エンドポイントは、第PCEPセッション10の受信を確立する8不明な要求基準9試みが欠落7同期経路計算要求を欠落オブジェクト無効なオブジェクトエラー値= 1：Pフラグとオブジェクトの受信Pフラグはこの仕様に応じて設定されなければならないが設定されていません。
The error types listed above are described below.
上記のエラーの種類は、以下に記載されています。
Error-Type=1: PCEP session establishment failure.
エラー-タイプ= 1：PCEPセッション確立に失敗しました。
If a malformed message is received, the receiving PCEP peer MUST send a PCErr message with Error-Type=1, Error-value=1.
不正なメッセージを受信した場合、受信PCEPピアはエラータイプ= 1、エラー値= 1 PCErrメッセージを送らなければなりません。
If no Open message is received before the expiration of the OpenWait timer, the receiving PCEP peer MUST send a PCErr message with Error-Type=1, Error-value=2 (see Appendix A for details).
いかなるオープンメッセージはOpenWaitタイマの満了前に受信されない場合、受信PCEPピアはエラータイプ= 1、エラー値= 2（詳細については、付録Aを参照）PCErrメッセージを送らなければなりません。
If one or more PCEP session characteristics are unacceptable by the receiving peer and are not negotiable, it MUST send a PCErr message with Error-Type=1, Error-value=3.
一つ以上のPCEPセッション特性は受信ピアによって受け入れられないと交渉可能でない場合は、エラータイプ= 1、エラー値= 3でPCErrメッセージを送らなければなりません。
If an Open message is received with unacceptable session characteristics but these characteristics are negotiable, the receiving PCEP peer MUST send a PCErr message with Error-Type-1, Error-value=4 (see Section 6.2 for details).
オープンメッセージは受け入れられないセッション特性で受信されるが、これらの特性が交渉されている場合、受信PCEPピアは、エラータイプ1、エラー値= 4（詳細はセクション6.2を参照）PCErrメッセージを送らなければなりません。
If a second Open message is received during the PCEP session establishment phase and the session characteristics are still unacceptable, the receiving PCEP peer MUST send a PCErr message with Error-Type-1, Error-value=5 (see Section 6.2 for details).
第二のオープンメッセージは、PCEPセッション確立フェーズ中に受信され、セッション特性が依然として許容できない場合、受信PCEPピアは、エラータイプ1、エラー値= 5（詳細はセクション6.2を参照）PCErrメッセージを送らなければなりません。
If a PCErr message is received during the PCEP session establishment phase that contains an Open message proposing unacceptable session characteristics, the receiving PCEP peer MUST send a PCErr message with Error-Type=1, Error-value=6.
PCErrメッセージが受け入れられないセッション特性を提案オープンメッセージを含むPCEPセッション確立フェーズ中に受信した場合、受信PCEPピアはエラータイプ= 1、エラー値= 6を有するPCErrメッセージを送らなければなりません。
If neither a Keepalive message nor a PCErr message is received before the expiration of the KeepWait timer during the PCEP session establishment phase, the receiving PCEP peer MUST send a PCErr message with Error-Type=1, Error-value=7.
キープアライブメッセージもPCErrメッセージいずれもPCEPセッション確立フェーズ中KeepWaitタイマーの満了前に受信された場合、受信PCEPピアはエラータイプ= 1、エラー値= 7とPCErrメッセージを送らなければなりません。
Error-Type=2: the PCE indicates that the path computation request cannot be honored because it does not support one or more required capability. The corresponding path computation request MUST be cancelled.
エラー・タイプ= 2：PCEは、それが1つのまたは複数の必要な機能をサポートしていないため、経路計算要求が受け入れられないことを示します。対応する経路計算要求は取り消されなければなりません。
Error-Type=3 or Error-Type=4: if a PCEP message is received that carries a PCEP object (with the P flag set) not recognized by the PCE or recognized but not supported, then the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=3 and 4, respectively). In addition, the PCE MAY include in the PCErr message the unknown or not supported object. The corresponding path computation request MUST be cancelled by the PCE without further notification.
エラータイプ= 3またはエラータイプ= 4：PCEPメッセージは、PCEによって認識または認識が、サポートされていないではない（Pフラグが設定されている）PCEPオブジェクトを搬送する受信された場合、その後、PCEはでPCErrメッセージを送らなければなりませんPCEP-ERRORオブジェクト（それぞれエラータイプ= 3及び4）。また、PCEはPCErrメッセージに不明またはサポートされていないオブジェクトを含むかもしれません。対応する経路計算要求は、さらに、通知なしPCEによって相殺されなければなりません。
Error-Type=5: if a path computation request is received that is not compliant with an agreed policy between the PCC and the PCE, the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=5). The corresponding path computation MUST be cancelled. Policy-specific TLVs carried within the PCEP-ERROR object may be defined in other documents to specify the nature of the policy violation.
エラータイプ= 5：経路計算要求はそれがPCCとPCEとの間の合意されたポリシーに準拠していない受信された場合、PCEは、PCEP-ERRORオブジェクト（エラータイプ= 5）でPCErrメッセージを送らなければなりません。対応する経路計算をキャンセルしなければなりません。 PCEP-ERRORオブジェクト内に運ばポリシー固有のTLVは、ポリシー違反の性質を指定するには、他のドキュメントで定義されてもよいです。
Error-Type=6: if a path computation request is received that does not contain a mandatory object, the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=6). If there are multiple mandatory objects missing, the PCErr message MUST contain one PCEP-ERROR object per missing object. The corresponding path computation MUST be cancelled.
エラータイプ= 6：経路計算要求は必須オブジェクトを含まない受信された場合、PCEは、PCEP-ERRORオブジェクト（エラータイプ= 6）でPCErrメッセージを送らなければなりません。不足している複数の必須オブジェクトがある場合は、PCErrメッセージが欠落しているオブジェクトごとに1 PCEP-ERRORオブジェクトを含まなければなりません。対応する経路計算をキャンセルしなければなりません。
Error-Type=7: if a PCC sends a synchronized path computation request to a PCE and the PCE does not receive all the synchronized path computation requests listed within the corresponding SVEC object after the expiration of the timer SyncTimer defined in Section 7.13.3, the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=7). The corresponding synchronized path computation MUST be cancelled. It is RECOMMENDED for the PCE to include the REQ-MISSING TLVs (defined below) that identify the missing requests.
エラー・タイプ= 7：PCCはPCEに同期経路計算要求を送信し、PCEは、セクション7.13.3で定義されたタイマーSyncTimerが満了した後、対応するSVECオブジェクト内にリストされているすべての同期経路計算要求を受信しない場合、 PCEは、PCEP-ERRORオブジェクト（エラータイプ= 7）でPCErrメッセージを送らなければなりません。対応する同期経路計算をキャンセルしなければなりません。不足している要求を識別（以下に定義）REQ-MISSING TLVを含めるようにPCEをお勧めします。
The REQ-MISSING TLV is compliant with the PCEP TLV format defined in section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying the TLV length (length of the value portion in bytes), followed by a fixed-length value field of 4 bytes.
REQ欠損TLVは、セクション7.1で定義されたPCEP TLVフォーマットに準拠し、タイプに2バイトで構成され、TLVの長さ（バイト単位の値部分の長さ）を指定する2バイト固定長の値フィールドが続きます4バイトの。
Type: 3 Length: 4 bytes Value: 4 bytes that indicate the Request-ID-number that corresponds to the missing request.
タイプ：3長さ：4バイト値：欠落要求に対応する要求-ID番号を示す4バイト。
Error-Type=8: if a PCC receives a PCRep message related to an unknown path computation request, the PCC MUST send a PCErr message with a PCEP-ERROR object (Error-Type=8). In addition, the PCC MUST include in the PCErr message the unknown RP object.
エラータイプ= 8：PCCが未知の経路計算要求に関連PCRepメッセージを受信した場合、PCCは、PCEP-ERRORオブジェクト（エラータイプ= 8）でPCErrメッセージを送らなければなりません。また、PCCはPCErrメッセージに未知のRPオブジェクトを含まなければなりません。
Error-Type=9: if a PCEP peer detects an attempt from another PCEP peer to establish a second PCEP session, it MUST send a PCErr message with Error-Type=9, Error-value=1. The existing PCEP session MUST be preserved and all subsequent messages related to the tentative establishment of the second PCEP session MUST be silently ignored.
エラータイプ= 9：PCEPピアが第PCEPセッションを確立する別のPCEPピアからの試みを検出した場合、それはエラータイプ= 9、誤差値= 1とPCErrメッセージを送らなければなりません。既存のPCEPセッションが保存されなければならないと第二PCEPセッションの暫定的な確立に関連するすべての後続のメッセージは静かに無視しなければなりません。
Error-Type=10: if a PCEP peers receives an object with the P flag not set although the P flag must be set according to this specification, it MUST send a PCErr message with Error-Type=10, Error-value=1.
エラータイプ= 10：PCEPピアは、Pフラグがセットされなければならないが、この仕様に従って設定されていないPフラグ付きオブジェクトを受信した場合、それはエラータイプ= 10、エラー値= 1とPCErrメッセージを送らなければなりません。
There are situations where no TE LSP with a bandwidth of X could be found by a PCE although such a bandwidth requirement could be satisfied by a set of TE LSPs such that the sum of their bandwidths is equal to X. Thus, it might be useful for a PCC to request a set of TE LSPs so that the sum of their bandwidth is equal to X Mbit/s, with potentially some constraints on the number of TE LSPs and the minimum bandwidth of each of these TE LSPs. Such a request is made by inserting a LOAD-BALANCING object in a PCReq message sent to a PCE.
そのような帯域幅の要件は、それらの帯域幅の合計がこのようにXに等しくなるようにTEのLSPのセットによって満たすことができるがXの帯域幅とはTE LSPは、PCEによって発見することができなかった、それは有用であるかもしれない状況がありますそれらの帯域幅の合計がTE LSPの数及びこれらTE LSPのそれぞれの最小帯域幅に潜在的にいくつかの制約を、Xメガビット/秒となるようにTE LSPのセットを要求するためのPCC。そのような要求は、PCEに送信PCReqメッセージにおける負荷分散オブジェクトを挿入することによって行われます。
The LOAD-BALANCING object is optional.
ロードバランシングオブジェクトはオプションです。
LOAD-BALANCING Object-Class is 14.
ロードバランシングオブジェクトクラスは14です。
LOAD-BALANCING Object-Type is 1.
ロードバランシングオブジェクトタイプは1です。
The format of the LOAD-BALANCING object body is as follows:
次のようにロードバランシング対象体の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | Max-LSP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min-Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: LOAD-BALANCING Object Body Format
図21：ロード・バランシング・オブジェクト本体のフォーマット
Reserved (16 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
（16ビット）予約：このフィールドは、送信にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
Flags (8 bits): No flag is currently defined. The Flags field MUST be set to zero on transmission and MUST be ignored on receipt.
フラグ（8ビット）：なしフラグは、現在定義されていません。 Flagsフィールドは、送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
Max-LSP (8 bits): maximum number of TE LSPs in the set.
MAX-LSP（8ビット）：セットにおけるTE LSPの最大数。
Min-Bandwidth (32 bits): Specifies the minimum bandwidth of each element of the set of TE LSPs. The bandwidth is encoded in 32 bits in IEEE floating point format (see [IEEE.754.1985]), expressed in bytes per second.
最小帯域幅（32ビット）：TE LSPの組の各要素の最小帯域幅を指定します。帯域幅は、IEEE浮動小数点形式の32ビットで符号化される（[IEEE.754.1985]参照）、秒あたりのバイト数で表しました。
The LOAD-BALANCING object body has a fixed length of 8 bytes.
負荷分散の対象体は、8バイトの固定長を有します。
If a PCC requests the computation of a set of TE LSPs so that the sum of their bandwidth is X, the maximum number of TE LSPs is N, and each TE LSP must at least have a bandwidth of B, it inserts a BANDWIDTH object specifying X as the required bandwidth and a LOAD-BALANCING object with the Max-LSP and Min-Bandwidth fields set to N and B, respectively.
PCCは、TE LSPのセットの計算を要求する場合、それらの帯域幅の合計がXとなるように、TE LSPの最大数はNであり、そして各TE LSPは、少なくともBの帯域幅を持っている必要があり、それは、特定の帯域幅オブジェクトを挿入します必要な帯域幅は、それぞれ、N及びBに設定最大LSPと最小帯域幅のフィールドを持つ負荷分散オブジェクトとしてX。
The CLOSE object MUST be present in each Close message. There MUST be only one CLOSE object per Close message. If a Close message is received that contains more than one CLOSE object, the first CLOSE object is the one that must be processed. Other CLOSE objects MUST be silently ignored.
CLOSE目的は、各閉じるメッセージ中に存在しなければなりません。閉じるメッセージごとに1つだけCLOSEオブジェクトが存在しなければなりません。クローズメッセージが複数のCLOSEのオブジェクトが含まれている受信された場合、最初のCLOSEオブジェクトが処理されなければならないものです。その他CLOSEオブジェクトは黙って無視しなければなりません。
CLOSE Object-Class is 15.
CLOSEオブジェクトクラスは15です。
CLOSE Object-Type is 1.
CLOSEオブジェクト型は1です。
The format of the CLOSE object body is as follows:
次のようにCLOSE対象体の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: CLOSE Object Format
図22：CLOSEオブジェクトフォーマット
Reserved (16 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
（16ビット）予約：このフィールドは、送信にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
Flags (8 bits): No flags are currently defined. The Flag field MUST be set to zero on transmission and MUST be ignored on receipt.
フラグ（8ビット）：いいえフラグが現在定義されています。フラグフィールドは、送信にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
Reason (8 bits): specifies the reason for closing the PCEP session. The setting of this field is optional. IANA manages the codespace of the Reason field. The following values are currently defined:
理由（8ビット）：PCEPセッションを閉じるための理由を指定します。このフィールドの設定はオプションです。 IANAは、理由フィールドのコードスペースを管理します。次の値が現在定義されています：
Reasons
Value Meaning
1 No explanation provided
2 DeadTimer expired
3 Reception of a malformed PCEP message
4 Reception of an unacceptable number of unknown
requests/replies
5 Reception of an unacceptable number of unrecognized
PCEP messages
Optional TLVs may be included within the CLOSE object body. The specification of such TLVs is outside the scope of this document.
オプションのTLVはCLOSEオブジェクト本体内に含めることができます。このようなのTLVの仕様は、この文書の範囲外です。
This section follows the guidance of [PCE-MANAGE].
このセクションでは、[PCE-管理]の指導に従います。
A PCEP implementation SHOULD allow configuring the following PCEP session parameters on the implementation:
PCEPの実装は、実装上の次のPCEPセッションパラメータを設定できるようにする必要があります。
o The local Keepalive and DeadTimer (i.e., parameters sent by the PCEP peer in an Open message),
ローカルキープアライブとDeadTimer O（すなわち、オープンメッセージにPCEPピアによって送信されたパラメータ）
o The maximum acceptable remote Keepalive and DeadTimer (i.e., parameters received from a peer in an Open message),
O最大許容遠隔キープアライブとDeadTimer（すなわち、オープンメッセージ内のピアから受信されたパラメータ）
o Whether negotiation is enabled or disabled,
ネゴシエーションが有効か無効か、O、
o If negotiation is allowed, the minimum acceptable Keepalive and DeadTimer timers received from a PCEP peer,
ネゴシエーションが許可されている場合は、O、最小許容キープアライブとDeadTimerタイマーは、PCEPピアから受信しました
o The SyncTimer,
、SyncTimer O
o The maximum number of sessions that can be set up,
設定可能な最大セッション数O、
o The request timer, the amount of time a PCC waits for a reply before resending its path computation requests (potentially to an alternate PCE),
要求タイマO、時間の量は、PCCは、（潜在的代替PCEに）、その経路計算リクエストを再送信する前に応答を待ちます
o The MAX-UNKNOWN-REQUESTS,
MAX-UNKNOWN-REQUESTS O、
o The MAX-UNKNOWN-MESSAGES.
MAX-UNKNOWN-MESSAGES O。
These parameters may be configured as default parameters for any PCEP session the PCEP speaker participates in, or may apply to a specific session with a given PCEP peer or to a specific group of sessions with a specific group of PCEP peers. A PCEP implementation SHOULD allow configuring the initiation of a PCEP session with a selected subset of discovered PCEs. Note that PCE selection is a local implementation issue. A PCEP implementation SHOULD allow configuring a specific PCEP session with a given PCEP peer. This includes the configuration of the following parameters:
これらのパラメータは、PCEPスピーカーが参加する、または所与PCEPピアまたはピアPCEPの特定のグループとのセッションの特定のグループに特定のセッションに適用することができる任意のPCEPセッションのデフォルトパラメータとして構成されてもよいです。 PCEPの実装では、発見されたのPCEの選択されたサブセットでPCEPセッションの開始を設定可能にするべきです。 PCEの選択はローカルの導入問題であることに注意してください。 PCEPの実装では、与えられたPCEPピアと特定のPCEPセッションを設定可能にするべきです。これは、次のパラメータの設定が含まれています。
o The IP address of the PCEP peer,
O PCEPピアのIPアドレス、
o The PCEP speaker role: PCC, PCE, or both,
PCEPスピーカーの役割O：PCC、PCE、またはその両方、
o Whether the PCEP speaker should initiate the PCEP session or wait for initiation by the peer,
PCEPスピーカーがPCEPセッションを開始するか、またはピアによって開始を待つべきかどうか、O、
o The PCEP session parameters, as listed above, if they differ from the default parameters,
PCEPセッションパラメータO、彼らはデフォルトパラメータと異なる場合、上記のように、
o A set of PCEP policies including the type of operations allowed for the PCEP peer (e.g., diverse path computation, synchronization, etc.).
O PCEPピア（例えば、多様な経路計算、同期など）のために許可された操作の種類を含むPCEPポリシーのセット。
A PCEP implementation MUST allow restricting the set of PCEP peers that can initiate a PCEP session with the PCEP speaker (e.g., list of authorized PCEP peers, all PCEP peers in the area, all PCEP peers in the AS).
PCEP実装がPCEPスピーカーとPCEPセッションを開始することができるPCEPピアのセットを制限できるようにしなければならない（例えば、許可さPCEPピアのリスト、エリア内のすべてのピアPCEP、AS内のすべてのピアPCEP）。
A PCEP MIB module is defined in [PCEP-MIB] that describes managed objects for modeling of PCEP communication including:
PCEP MIBモジュールは、PCEP通信などのモデリングのための管理オブジェクトを記述する[PCEP-MIB]で定義されています。
o PCEP client configuration and status,
O PCEPクライアントの設定とステータス、
o PCEP peer configuration and information,
O PCEPピア設定情報
o PCEP session configuration and information,
O PCEPのセッション構成情報、
o Notifications to indicate PCEP session changes.
O通知はPCEPセッションの変更を指示します。
PCEP includes a keepalive mechanism to check the liveliness of a PCEP peer and a notification procedure allowing a PCE to advertise its overloaded state to a PCC. Also, procedures in order to monitor the liveliness and performances of a given PCE chain (in case of multiple-PCE path computation) are defined in [PCE-MONITOR].
PCEPは、PCEPピアの活気とPCEは、PCCへの過負荷状態をアドバタイズすることを可能にする通知手順をチェックするキープアライブ機構を含みます。また、活気と（複数PCEの経路計算の場合）指定されたPCEチェーンの性能を監視するための手順は、[PCE-MONITOR]で定義されています。
Verifying the correct operation of a PCEP communication can be performed by monitoring various parameters. A PCEP implementation SHOULD provide the following parameters:
PCEP通信の正しい動作を検証する様々なパラメータを監視することによって行うことができます。 PCEPの実装は、次のパラメータを提供する必要があります。
o Response time (minimum, average, and maximum), on a per-PCE-peer basis,
O応答時間（最小値、平均値、および最大値）、単位のPCEピア基づいて、
o PCEP session failures,
O PCEPセッションの失敗、
o Amount of time the session has been in active state,
セッションがアクティブな状態にあった時間のO量、
o Number of corrupted messages,
破損したメッセージのO数、
o Number of failed computations,
失敗した計算のO数、
o Number of requests for which no reply has been received after the expiration of a configurable timer and by verifying that at least one path exists that satisfies the set of constraints.
返事が設定タイマーの満了後に少なくとも一つの経路が制約を満たす組が存在することを確認することによって受信された要求のO数。
A PCEP implementation SHOULD log error events (e.g., corrupted messages, unrecognized objects).
PCEP実装は、エラーイベント（例えば、破損メッセージ、認識されていないオブジェクト）ログインする必要があります。
PCEP does not put any new requirements on other protocols. As PCEP relies on the TCP transport protocol, PCEP management can make use of TCP management mechanisms (such as the TCP MIB defined in [RFC4022]).
PCEPは、他のプロトコル上の任意の新しい要件を入れていません。 PCEPは、TCPトランスポートプロトコルに依存しているように、PCEP管理は、（例えば、[RFC4022]で定義されたTCP MIBなど）TCP管理メカニズムを利用することができます。
The PCE Discovery mechanisms ([RFC5088], [RFC5089]) may have an impact on PCEP. To avoid that a high frequency of PCE Discoveries/ Disappearances triggers a high frequency of PCEP session setups/ deletions, it is RECOMMENDED to introduce some dampening for establishment of PCEP sessions.
PCEディスカバリメカニズム（[RFC5088]、[RFC5089]）はPCEPに影響を与えることができます。 PCEの発見の高周波/失踪がPCEPセッションのセットアップ/削除の高周波をトリガーすることを回避するために、いくつかのPCEPセッションの確立のための減衰を導入することをお勧めします。
In order to avoid any unacceptable impact on network operations, an implementation SHOULD allow a limit to be placed on the number of sessions that can be set up on a PCEP speaker, and MAY allow a limit to be placed on the rate of messages sent by a PCEP speaker and received from a peer. It MAY also allow sending a notification when a rate threshold is reached.
ネットワーク運用上の任意の許容できない影響を回避するために、実装は限界がPCEPスピーカに設定することができるセッションの数に配置されることを可能にするべきであり、制限により送信されたメッセージの速度に配置することを可能にすることができますPCEPスピーカーとピアから受信しました。また、レートしきい値に達したときに通知を送信することが可能になります。
IANA assigns values to the PCEP protocol parameters (messages, objects, TLVs).
IANAは、PCEPプロトコルパラメータ（メッセージ、オブジェクト、のTLV）に値を割り当てます。
IANA established a new top-level registry to contain all PCEP codepoints and sub-registries.
IANAは、すべてのPCEPコードポイントとサブレジストリを含むように新しいトップレベルのレジストリを設立しました。
The allocation policy for each new registry is by IETF Consensus: new values are assigned through the IETF consensus process (see [RFC5226]). Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists).
各新しいレジストリの割り当てポリシーは、IETFコンセンサスによるものである：新しい値はIETFコンセンサスプロセスを経て割り当てられている（[RFC5226]を参照します）。具体的には、新しい割り当てがIESGによって承認されたRFCを介して行われています。典型的には、IESGは、適切な人（例えば、関連するワーキンググループが存在する場合）から、将来の割り当ての入力を求めます。
PCEP has been registered as TCP port 4189.
PCEPは、TCPポート4189として登録されています。
IANA created a registry for PCEP messages. Each PCEP message has a message type value.
IANAは、PCEPメッセージのレジストリを作成しました。各PCEPメッセージは、メッセージタイプ値を有します。
Value Meaning Reference 1 Open This document 2 Keepalive This document 3 Path Computation Request This document 4 Path Computation Reply This document 5 Notification This document 6 Error This document 7 Close This document
この文書3経路計算要求この文書2キープアライブこの文書で4パスの計算を参照開き意味値がこの文書6エラーこの文書5通知を返信この文献7を閉じるこの文書
IANA created a registry for PCEP objects. Each PCEP object has an Object-Class and an Object-Type.
IANAは、PCEPオブジェクトのレジストリを作成しました。各PCEPオブジェクトは、Objectクラスとオブジェクト型を持っています。
Object-Class Value Name Reference
オブジェクトクラス値の名前リファレンス
1 OPEN This document
Object-Type
1
2 RP This document Object-Type 1
2 RPこの文書オブジェクト・タイプ1
3 NO-PATH This document Object-Type 1
3 NO-PATHこの文書オブジェクト・タイプ1
4 END-POINTS This document Object-Type 1: IPv4 addresses 2: IPv6 addresses
4エンドポイントこの文書オブジェクト・タイプ1：IPv4のアドレスは2：IPv6アドレス
5 BANDWIDTH This document Object-Type 1: Requested bandwidth 2: Bandwidth of an existing TE LSP for which a reoptimization is performed.
5 BANDWIDTHこの文書オブジェクト・タイプ1：要求された帯域幅2：再最適化が実行されている既存のTE LSPの帯域幅。
6 METRIC This document Object-Type 1
6 METRICこの文書オブジェクト・タイプ1
7 ERO This document Object-Type 1
7 EROこの文書オブジェクト・タイプ1
8 RRO This document Object-Type 1
8 RROこの文書オブジェクト・タイプ1
9 LSPA This document Object-Type 1
9 LSPAこの文書オブジェクト・タイプ1
10 IRO This document Object-Type 1
10 IROこの文書オブジェクト・タイプ1
11 SVEC This document Object-Type 1
11 SVECこの文書オブジェクト・タイプ1
12 NOTIFICATION This document Object-Type 1
12通知この文書オブジェクト・タイプ1
13 PCEP-ERROR This document Object-Type 1
13 PCEP-ERRORこの文書オブジェクト・タイプ1
14 LOAD-BALANCING This document Object-Type 1
14この文書オブジェクト・タイプ1をロードバランシング
15 CLOSE This document Object-Type 1
15 CLOSEこの文書オブジェクト・タイプ1
IANA created a registry to manage the Flag field of the PCEP Message Common Header.
IANAは、PCEPメッセージ共通ヘッダのフラグフィールドを管理するために、レジストリを作成しました。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新しいビット数はIETF Consensus動作によって割り当てることができます。各ビットは以下の品質を追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description
O機能の説明
o Defining RFC
Oの定義RFC
No bits are currently defined for the PCEP message common header.
何ビットが現在PCEPメッセージ共通ヘッダのために定義されていません。
IANA created a registry to manage the Flag field of the OPEN object.
IANAは、OPENオブジェクトのフラグフィールドを管理するために、レジストリを作成しました。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新しいビット数はIETF Consensus動作によって割り当てることができます。各ビットは以下の品質を追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description
O機能の説明
o Defining RFC
Oの定義RFC
No bits are currently for the OPEN Object flag field.
何ビットがOPENオブジェクトフラグフィールドに現在ありません。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新しいビット数はIETF Consensus動作によって割り当てることができます。各ビットは以下の品質を追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description o Defining RFC
定義RFC O O機能の説明
Several bits are defined for the RP Object flag field in this document. The following values have been assigned:
いくつかのビットは、この文書のRPオブジェクトフラグフィールドのために定義されています。以下の値が割り当てられています：
Codespace of the Flag field (RP Object)
フラグフィールドのコードスペース（RPオブジェクト）
Bit Description Reference
ビット説明リファレンス
26 Strict/Loose This document 27 Bi-directional This document 28 Reoptimization This document 29-31 Priority This document
26厳正/ 27双方向この文書を失うこの文書28再最適化このドキュメント29-31優先順位このドキュメント
IANA created a registry to manage the codespace of the NI field and the Flag field of the NO-PATH object.
IANAは、NIフィールドのコードスペースとNO-PATHオブジェクトのフラグフィールドを管理するために、レジストリを作成しました。
Value Meaning Reference
参考値意味
0 No path satisfying the set This document of constraints could be found 1 PCE chain broken This document
制約のこのドキュメントは、このドキュメントを破壊1つのPCE鎖を見出すことができたセットを満たす0ませんパス
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新しいビット数はIETF Consensus動作によって割り当てることができます。各ビットは以下の品質を追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description
O機能の説明
o Defining RFC
Oの定義RFC
One bit is defined for the NO-PATH Object flag field in this document:
1ビットは、この文書に記載されているNO-Pathオブジェクトフラグフィールドのために定義されています。
Codespace of the Flag field (NO-PATH Object)
フラグフィールドのコードスペース（NO-PATHオブジェクト）
Bit Description Reference
ビット説明リファレンス
0 Unsatisfied constraint indicated This document
0不満制約は、この文書を示しました
IANA created a registry to manage the codespace of the T field and the Flag field of the METRIC Object.
IANAは、TフィールドのコードスペースとMETRICオブジェクトのフラグフィールドを管理するために、レジストリを作成しました。
Codespace of the T field (Metric Object)
Tフィールド（メトリックオブジェクト）のコードスペース
Value Meaning Reference
参考値意味
1 IGP metric This document 2 TE metric This document 3 Hop Counts This document
1つのIGPメトリックこの文書2 TEメトリックこの文書3ホップカウントこの文書
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新しいビット数はIETF Consensus動作によって割り当てることができます。各ビットは以下の品質を追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description
O機能の説明
o Defining RFC
Oの定義RFC
Several bits are defined in this document. The following values have been assigned:
いくつかのビットは、この文書で定義されています。以下の値が割り当てられています：
Codespace of the Flag field (Metric Object)
フラグフィールドのコードスペース（メトリックオブジェクト）
Bit Description Reference
ビット説明リファレンス
6 Computed metric This document 7 Bound This document
6計算さメトリックこの文書では、7この文書をバウンド
IANA created a registry to manage the Flag field of the LSPA object.
IANAはLSPAオブジェクトのフラグフィールドを管理するために、レジストリを作成しました。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新しいビット数はIETF Consensus動作によって割り当てることができます。各ビットは以下の品質を追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description
O機能の説明
o Defining RFC
Oの定義RFC
One bit is defined for the LSPA Object flag field in this document:
1ビットは、この文書のLSPAオブジェクトフラグフィールドのために定義されています。
Codespace of the Flag field (LSPA Object)
フラグフィールドのコードスペース（LSPAオブジェクト）
Bit Description Reference
ビット説明リファレンス
7 Local Protection Desired This document
7ローカル保護は、この文書を希望しました
IANA created a registry to manage the Flag field of the SVEC object.
IANAはSVECオブジェクトのフラグフィールドを管理するために、レジストリを作成しました。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新しいビット数はIETF Consensus動作によって割り当てることができます。各ビットは以下の品質を追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description
O機能の説明
o Defining RFC
Oの定義RFC
Three bits are defined for the SVEC Object flag field in this document:
3つのビットは、この文書のSVECオブジェクトフラグフィールドのために定義されています。
Codespace of the Flag field (SVEC Object)
フラグフィールドのコードスペース（SVECオブジェクト）
Bit Description Reference
ビット説明リファレンス
21 SRLG Diverse This document 22 Node Diverse This document 23 Link Diverse This document
多様なこのドキュメント22ノードはこの文書23のリンク多様多彩な21 SRLGこのドキュメント
IANA created a registry for the Notification-type and Notification-value of the NOTIFICATION object and manages the code space.
IANAは、通知オブジェクトの通知タイプと通知 - 値のレジストリを作成し、コードスペースを管理します。
Notification-type Name Reference 1 Pending Request cancelled This document Notification-value 1: PCC cancels a set of pending requests 2: PCE cancels a set of pending requests
通知型名リファレンス1保留中の要求は、この文書で通知-値1をキャンセル：PCCは、保留中の要求2のセットを取り消し：PCEは、保留中の要求のセットを取り消し
2 Overloaded PCE This document
Notification-value
1: PCE in congested state
2: PCE no longer in congested state
IANA created a registry to manage the Flag field of the NOTIFICATION object.
IANAは、通知オブジェクトのフラグフィールドを管理するために、レジストリを作成しました。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新しいビット数はIETF Consensus動作によって割り当てることができます。各ビットは以下の品質を追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description
O機能の説明
o Defining RFC
Oの定義RFC
No bits are currently for the Flag Field of the NOTIFICATION object.
何ビットがNOTIFICATIONオブジェクトのフラグ・フィールドのために現在ありません。
IANA created a registry for the Error-Type and Error-value of the PCEP Error Object and manages the code space.
IANAは、PCEP・エラー・オブジェクトのエラー・タイプとエラー値のレジストリを作成し、コードスペースを管理します。
For each PCEP error, an Error-Type and an Error-value are defined.
各PCEPエラーのため、エラー・タイプとエラー値が定義されています。
Error- Meaning Reference Type 1 PCEP session establishment failure This document Error-value=1: reception of an invalid Open message or a non Open message. Error-value=2: no Open message received before the expiration of the OpenWait timer Error-value=3: unacceptable and non-negotiable session characteristics Error-value=4: unacceptable but negotiable session characteristics Error-value=5: reception of a second Open message with still unacceptable session characteristics Error-value=6: reception of a PCErr message proposing unacceptable session characteristics Error-value=7: No Keepalive or PCErr message received before the expiration of the KeepWait timer Error-value=8: PCEP version not supported 2 Capability not supported This document 3 Unknown Object This document Error-value=1: Unrecognized object class Error-value=2: Unrecognized object Type 4 Not supported object This document Error-value=1: Not supported object class Error-value=2: Not supported object Type 5 Policy violation This document Error-value=1: C bit of the METRIC object set (request rejected) Error-value=2: O bit of the RP object cleared (request rejected) 6 Mandatory Object missing This document Error-value=1: RP object missing Error-value=2: RRO missing for a reoptimization request (R bit of the RP object set) Error-value=3: END-POINTS object missing 7 Synchronized path computation request missing This document 8 Unknown request reference This document 9 Attempt to establish a second PCEP session This document 10 Reception of an invalid object This document Error-value=1: reception of an object with P flag not set although the P flag must be set according to this specification.
エラー - 意味リファレンスタイプ1 PCEPセッション確立の失敗このドキュメントのエラー値= 1：無効開きメッセージまたは非オープンメッセージの受信。エラー値= 2：OpenWaitタイマ誤差値の満了前に受信しないオープンメッセージ= 3：許容できない非交渉セッション特性誤差値= 4：許容できないが、交渉セッション特性誤差値= 5：の受信KeepWaitタイマエラー値= 8の満了前に受信したキープアライブまたはPCErrメッセージ：許容できないセッション特性エラー値= 7を提案PCErrメッセージの受信：PCEPバージョン依然として許容できないセッション特性エラー値= 6を持つ第二のオープンメッセージサポート2能力このドキュメント3未知のオブジェクトをサポートしていないではない。このドキュメントのエラー値= 1：認識されないオブジェクトクラスError-値= 2：認識されないオブジェクトタイプ4サポートされていませんオブジェクトこのドキュメントのエラー値= 1：オブジェクトクラスエラー値をサポートしていません= 2：サポートされないオブジェクトタイプ5ポリシー違反このドキュメントエラー値= 1：メトリックオブジェクトセット（要求拒否）エラー値のCビット= 2：クリアRPオブジェクトのOビット（要求が拒否）6必須O bject欠落この文書エラー値= 1：RPオブジェクト欠落エラー値= 2：RROは再最適化の要求に対して不足している（RPオブジェクトセットのRビット）のエラー値= 3：エンドポイントは、7同期経路計算要求を欠落オブジェクト無効なオブジェクトのこのドキュメント10フロントこのドキュメントエラー値= 1この文書8不明な要求基準を第二PCEPセッションを確立するために、このドキュメント9試みが欠落：Pフラグに従って設定されなければならないがPフラグとオブジェクトの受信が設定されていませんこの仕様に。
IANA created a registry to manage the Flag field of the PCEP-ERROR object.
IANAは、PCEP-ERRORオブジェクトのフラグフィールドを管理するために、レジストリを作成しました。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新しいビット数はIETF Consensus動作によって割り当てることができます。各ビットは以下の品質を追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description
O機能の説明
o Defining RFC
Oの定義RFC
No bits are currently for the Flag Field of the PCEP-ERROR Object.
何ビットがPCEP-ERRORオブジェクトのフラグ・フィールドのために現在ありません。
IANA created a registry to manage the Flag field of the LOAD-BALANCING object.
IANAは、ロード・バランシング対象のフラグフィールドを管理するために、レジストリを作成しました。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新しいビット数はIETF Consensus動作によって割り当てることができます。各ビットは以下の品質を追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description
O機能の説明
o Defining RFC
Oの定義RFC
No bits are currently for the Flag Field of the LOAD-BALANCING Object.
何ビットがロードバランシングオブジェクトのフラグ・フィールドのために現在ありません。
The CLOSE object MUST be present in each Close message in order to close a PCEP session. The reason field of the CLOSE object specifies the reason for closing the PCEP session. The reason field of the CLOSE object is managed by IANA.
CLOSEオブジェクトは、PCEPセッションを閉じるために、各閉じるメッセージ中に存在しなければなりません。 CLOSEオブジェクトのreasonフィールドには、PCEPセッションを閉じるための理由を指定します。 CLOSEオブジェクトの理由フィールドは、IANAによって管理されています。
Reasons
理由
Value Meaning 1 No explanation provided 2 DeadTimer expired 3 Reception of a malformed PCEP message 4 Reception of an unacceptable number of unknown requests/replies 5 Reception of an unacceptable number of unrecognized PCEP messages
いいえ説明は2 DeadTimerが未知の要求の容認できない数の不正なPCEPメッセージ4フロントの3レセプション/未認識PCEPメッセージの許容できない数の5受信を返信期限が切れません1値意味
IANA created a registry to manage the flag field of the CLOSE object.
IANAはCLOSEオブジェクトのフラグフィールドを管理するために、レジストリを作成しました。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新しいビット数はIETF Consensus動作によって割り当てることができます。各ビットは以下の品質を追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description
O機能の説明
o Defining RFC
Oの定義RFC
No bits are currently for the Flag Field of the CLOSE Object.
何ビットがCLOSEオブジェクトのフラグ・フィールドのために現在ありません。
IANA created a registry for the PCEP TLVs.
IANAは、PCEPのTLVのレジストリを作成しました。
Value Meaning Reference
参考値意味
1 NO-PATH-VECTOR TLV This document 2 OVERLOAD-DURATION TLV This document 3 REQ-MISSING TLV This document
1 NO-PATHベクターTLVこの文書2過負荷DURATION TLV本書3 REQ欠損TLVこの文書
IANA manages the space of flags carried in the NO-PATH-VECTOR TLV defined in this document, numbering them from 0 as the least significant bit.
IANAは、この文書で定義されたNO-PATH-VECTOR TLVで運ばれた旗のスペース、最下位ビットとして0からそれらの番号を管理します。
New bit numbers may be allocated only by an IETF Consensus action.
新しいビット数はIETF Consensus動作によって割り当てることができます。
Each bit should be tracked with the following qualities:
各ビットは以下の品質を追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Name flag
名前フラグO
o Reference
Oリファレンス
Bit Number Name Reference 31 PCE currently unavailable This document 30 Unknown destination This document 29 Unknown source This document
ビット数名リファレンス31 PCE現在使用できません。この文書30未知の宛先この文書29未知のソースこの文書
Attacks on PCEP may result in damage to active networks. If path computation responses are changed, the PCC may be encouraged to set up inappropriate LSPs. Such LSPs might deviate to parts of the network susceptible to snooping, or might transit congested or reserved links. Path computation responses may be attacked by modification of the PCRep message, by impersonation of the PCE, or by modification of the PCReq to cause the PCE to perform a different computation from that which was originally requested.
PCEPに対する攻撃は、アクティブなネットワークへの損傷をもたらすことができます。経路計算応答が変更された場合、PCCは、不適切なLSPを設定することが推奨されてもよいです。このようなLSPはスヌーピングの影響を受けやすいネットワーク、またはかもしれないトランジット混雑または予約のリンクの部分に外れるかもしれません。経路計算応答は、PCEが最初に要求されたものとは異なる計算を実行させるためにPCEのなりすましによって、またはPCReqの修飾によって、PCRepメッセージの変更によって攻撃することができます。
It is also possible to damage the operation of a PCE through a variety of denial-of-service attacks. Such attacks can cause the PCE to become congested with the result that path computations are supplied too slowly to be of value for PCCs. This could lead to slower-than-acceptable recovery times or delayed LSP establishment. In extreme cases, it may be that service requests are not satisfied.
サービス拒否攻撃の様々なを通じてPCEの操作を損傷することも可能です。このような攻撃は、PCEは、経路計算がのPCCのために価値があることがあまりにもゆっくりと供給され、その結果、混雑になることがあります。これは、遅いよりも、許容回復時間または遅延LSPの確立につながる可能性があります。極端な例では、サービス要求が満たされていないということかもしれません。
PCEP could be the target of the following attacks:
PCEPは、次の攻撃の標的となりうる。
o Spoofing (PCC or PCE impersonation)
スプーフィング（PCC又はPCE偽装）O
o Snooping (message interception)
Oスヌーピング（メッセージインターセプト）
o Falsification
改ざんO
o Denial of Service
サービス拒否O
In inter-AS scenarios when PCE-to-PCE communication is required, attacks may be particularly significant with commercial as well as service-level implications.
PCEツーPCE通信が必要な場合AS間のシナリオでは、攻撃は、商業およびサービス・レベルの影響に特に重要であり得ます。
Additionally, snooping of PCEP requests and responses may give an attacker information about the operation of the network. Simply by viewing the PCEP messages someone can determine the pattern of service establishment in the network and can know where traffic is being routed, thereby making the network susceptible to targeted attacks and the data within specific LSPs vulnerable.
また、PCEP要求と応答のスヌーピングは、ネットワークの動作について、攻撃者の情報を与えることができます。単に誰かがネットワーク内のサービスの確立のパターンを決定することができ、トラフィックが、それによって標的型攻撃や脆弱特定のLSP内のデータへのネットワークが影響を受けやすく、ルーティングされている場所を知ることができPCEPメッセージを表示することもできます。
The following sections identify mechanisms to protect PCEP against security attacks.
次のセクションでは、セキュリティ攻撃からPCEPを保護するためのメカニズムを識別します。
At the time of writing, TCP-MD5 [RFC2385] is the only available security mechanism for securing the TCP connections that underly PCEP sessions.
執筆の時点では、TCP-MD5 [RFC2385]はPCEPセッションを基礎となるTCP接続を保護するためにのみ利用可能なセキュリティ・メカニズムです。
As explained in [RFC2385], the use of MD5 faces some limitations and does not provide as high a level of security as was once believed. A PCEP implementation supporting TCP-MD5 SHOULD be designed so that stronger security keying techniques or algorithms that may be specified for TCP can be easily integrated in future releases.
[RFC2385]で説明したように、MD5の使用は、いくつかの制限に直面していると一度考えられていたようにセキュリティのような高レベルを提供しません。 TCPに指定することができる技術又はアルゴリズムをキーイング強力なセキュリティを容易に将来のリリースに統合することができるように、TCP-MD5をサポートPCEP実装は、設計されなければなりません。
The TCP Authentication Option [TCP-AUTH] (TCP-AO) specifies new security procedures for TCP, but is not yet complete. Since it is believed that [TCP-AUTH] will offer significantly improved security for applications using TCP, implementers should expect to update their implementation as soon as the TCP Authentication Option is published as an RFC.
TCP認証オプション[TCP-AUTH]（TCP-AO）は、TCPのための新しいセキュリティ手続きを指定しますが、まだ完全ではありません。 [TCP-AUTH]はTCPを使用してアプリケーションのため大幅に改善されたセキュリティを提供すると考えられているので、実装者は、すぐにTCP認証オプションは、RFCとして公開されているとして、その実装を更新することを期待すべきです。
Implementations MUST support TCP-MD5 and should make the security function available as a configuration option.
実装は、TCP-MD5をサポートしなければならないし、設定オプションなどのセキュリティ機能を利用できるようにすべきです。
Operators will need to observe that some deployed PCEP implementations may pre-date the completion of [TCP-AUTH], and it will be necessary to configure policy for secure communication between PCEP speakers that support the TCP Authentication Option, and those that don't.
オペレータは、いくつかの展開PCEPの実装は、[TCP-AUTH]の完了を最新に事前ことを観察する必要があるでしょう、そして、TCP認証オプションをサポートPCEPスピーカー間の安全な通信のためのポリシーを設定する必要がありますし、そうでないもの。
An alternative approach for security over TCP transport is to use the Transport Layer Security (TLS) protocol [RFC5246]. This provides protection against eavesdropping, tampering, and message forgery. But TLS doesn't protect the TCP connection itself, because it does not authenticate the TCP header. Thus, it is vulnerable to attacks such as TCP reset attacks (something against which TCP-MD5 does protect). The use of TLS would, however, require the specification of how PCEP initiates TLS handshaking and how it interprets the certificates exchanged in TLS. That specification is out of the scope of this document, but could be the subject of future work.
TCPトランスポート上のセキュリティのための別のアプローチは、トランスポート層セキュリティ（TLS）プロトコル[RFC5246]を使用することです。これは、盗聴、改ざん、およびメッセージ偽造に対する保護を提供します。それはTCPヘッダを認証していないので、しかし、TLSは、TCP接続自体を保護することはできません。したがって、そのようなTCPリセット攻撃（TCP-MD5を守るんそれに対して何か）などの攻撃に対して脆弱です。 TLSの使用は、しかし、PCEPは、TLSハンドシェイクを開始する方法の仕様を必要とし、それがTLSで交換証明書をどのように解釈しますか。その仕様は、このドキュメントの範囲外であるが、今後の作業の対象となりうる。
Authentication and integrity checks allow the receiver of a PCEP message to know that the message genuinely comes from the node that purports to have sent it and to know whether the message has been modified.
認証および完全性チェックは、PCEPメッセージの受信機は、メッセージが本当にそれを送っていると、メッセージが変更されたかどうか知っていると主張するノードから来ていることを知ることを可能にします。
The TCP-MD5 mechanism [RFC2385] described in the previous section provides such a mechanism subject to the concerns listed in [RFC2385] and [RFC4278]. These issues will be addressed and resolved by [TCP-AUTH].
前のセクションで説明したTCP-MD5メカニズム[RFC2385]は[RFC2385]及び[RFC4278]に記載されている問題に、このような機構の主題を提供します。これらの問題に対処し、[TCP-AUTH]で解決されます。
Ensuring PCEP communication privacy is of key importance, especially in an inter-AS context, where PCEP communication end-points do not reside in the same AS, as an attacker that intercepts a PCE message could obtain sensitive information related to computed paths and resources.
PCEP通信のプライバシーを確保することは、特にPCEP通信エンドポイントが計算パスとリソースに関連する機密情報を得ることができPCEメッセージを傍受攻撃者として、同じASに存在していない間AS文脈において、極めて重要です。
PCEP privacy can be ensured by encryption. TCP MAY be run over IPsec [RFC4303] tunnels to provide the required encryption. Note that IPsec can also ensure authentication and integrity; in which case, TCP-MD5 or TCP-AO would not be required. However, there is some concern that IPsec on this scale would be hard to configure and operate. Use of IPSec with PCEP is out of the scope of this document and may be addressed in a separate document.
PCEPプライバシーは暗号化によって確保することができます。 TCPは、必要な暗号化を提供するためにIPsec [RFC4303]トンネルで実行できます。 IPsecは、認証と整合性を確保できることに注意してください。その場合には、TCP-MD5またはTCP-AOが必要とされないであろう。しかし、この規模のIPsecが設定・運用するのは難しいだろうと、いくつかの懸念があります。 PCEPとのIPSecの使用は、この文書の範囲外であると、別の文書に対処することができます。
Authentication, tamper protection, and encryption all require the use of keys by sender and receiver.
認証、改ざん保護、および暗号化は、すべての送信者と受信者によってキーを使用する必要があります。
Although key configuration per session is possible, it may be particularly onerous to operators (in the same way as for the Border Gateway Protocol (BGP) as discussed in [BGP-SEC]). If there is a relatively small number of PCCs and PCEs in the network, manual key configuration MAY be considered a valid choice by the operator, although it is important to be aware of the vulnerabilities introduced by such mechanisms (i.e., configuration errors, social engineering, and carelessness could all give rise to security breaches). Furthermore, manually configured keys are less likely to be regularly updated which also increases the security risk. Where there is a large number of PCCs and PCEs, the operator could find that key configuration and maintenance is a significant burden as each PCC needs to be configured to the PCE.
セッションあたりのキー設定が可能であるが（[BGP-SEC]で議論するようにボーダーゲートウェイプロトコル（BGP）の場合と同様に）、それはオペレータに特に厄介であり得ます。ネットワーク内のPCCとのPCEの比較的少数があれば、そのようなメカニズム（すなわち、構成エラー、ソーシャルエンジニアリングによって導入された脆弱性を認識することが重要であるが、手動鍵設定は、オペレータによる有効な選択肢と考えることができます、および不注意は、すべての）セキュリティ侵害を引き起こす可能性があります。さらに、手動で設定したキーは、定期的にも、セキュリティ上のリスクを増加させる更新されにくいです。 PCCとのPCEの数が多い場合には、オペレータは各PCCはPCEに設定する必要がありますように、キーの設定やメンテナンスは大きな負担であることを見つけることができます。
An alternative to individual keys is the use of a group key. A group key is common knowledge among all members of a trust domain. Thus, since the routers in an IGP area or an AS are part of a common trust domain [MPLS-SEC], a PCEP group key MAY be shared among all PCCs and PCEs in an IGP area or AS. The use of a group key will considerably simplify the operator's configuration task while continuing to secure
個々のキーの代わりに、グループキーを使用することです。グループキーは、信頼ドメインのすべてのメンバーの間で共通の知識です。 IGP領域またはAS内のルータは、一般的信頼ドメイン[MPLS-SEC]の一部であるので、従って、PCEPグループキーは、IGP領域またはAS内のすべてのPCCとのPCE間で共有することができます。確保し続けながら、グループキーの使用が大幅にオペレータの設定作業を簡素化します
PCEP against attack from outside the network. However, it must be noted that the more entities that have access to a key, the greater the risk of that key becoming public.
ネットワークの外部からの攻撃に対してPCEP。しかし、キーへのアクセス権を持っているより多くのエンティティが、より大きなそのキーのリスクが公共になってきていることに留意しなければなりません。
With the use of a group key, separate keys would need to be configured for the PCE-to-PCE communications that cross trust domain (e.g., AS) boundaries, but the number of these relationships is likely to be very small.
グループキーを使用すると、別のキーが信託（例えば、AS）ドメイン境界を越えるPCEツーPCE通信用に設定する必要がありますが、これらの関係の数が非常に少ない可能性が高いです。
PCE discovery ([RFC5088] and [RFC5089]) is a significant feature for the successful deployment of PCEP in large networks. This mechanism allows a PCC to discover the existence of suitable PCEs within the network without the necessity of configuration. It should be obvious that, where PCEs are discovered and not configured, the PCC cannot know the correct key to use. There are three possible approaches to this problem that retain some aspect of security:
PCEの発見（[RFC5088]と[RFC5089]）は、大規模ネットワークでのPCEPの展開を成功のための重要な特徴です。このメカニズムは、PCCは、構成を必要とせずにネットワーク内の適切なのPCEの存在を発見することを可能にします。 PCCが使用する正しい鍵を知ることができない、のPCEが発見され、構成されていない場合は、ことは言うまでもないです。セキュリティのいくつかの側面を保持して、この問題には3つの可能なアプローチがあります。
o The PCCs may use a group key as previously discussed.
前述したように、OのPCCは、グループ鍵を使用してもよいです。
o The PCCs may use some form of secure key exchange protocol with the PCE (such as the Internet Key Exchange protocol v2 (IKE) [RFC4306]). The drawback to this is that IKE implementations on routers are not common and this may be a barrier to the deployment of PCEP. Details are out of the scope of this document and may be addressed in a separate document.
OのPCCは、PCEとのセキュアな鍵交換プロトコルのいくつかのフォームを使用することができる（例えば、インターネット鍵交換プロトコルV2と（IKE）[RFC4306]）。これの欠点は、ルータ上のIKE実装が一般的ではないということであり、これは、PCEPの展開に対する障壁であってもよいです。詳細は、この文書の範囲外であり、別の文書に対処することができます。
o The PCCs may make use of a key server to determine the key to use when talking to the PCE. To some extent, this is just moving the problem, since the PCC's communications with the key server must also be secure (for example, using Kerberos [RFC4120]), but there may some (minor) benefit in scaling if the PCC is to learn about several PCEs and only needs to know one key server. Note that key servers currently have very limited implementation. Details are out of the scope of this document and may be addressed in a separate document.
OのPCCは、PCEと話をするときに使用するキーを決定するために鍵サーバを利用することができます。ある程度までは、キーサーバとPCCの通信はまた、（ケルベロス[RFC4120]を使用して、例えば）安全でなければならないので、これは単に、問題を移動されますが、PCCを学ぶのであればスケーリングにおけるいくつかの（マイナー）の利益があるかもしれませんいくつかのPCEと1台のキーだけのサーバーを知っている必要があります。キーサーバは現在、非常に限られた実装を持っていることに注意してください。詳細は、この文書の範囲外であり、別の文書に対処することができます。
PCEP relationships are likely to be long-lived even if the PCEP sessions are repeatedly closed and re-established. Where protocol relationships persist for a large number of protocol interactions or over a long period of time, changes in the keys used by the protocol peers is RECOMMENDED [RFC4107]. Note that TCP-MD5 does not allow the key to be changed without closing and reopening the TCP connection which would result in the PCEP session being terminated and needing to be restarted. That might not be a significant issue for PCEP. Note also that the plans for the TCP Authentication Option [TCP-AUTH] will allow dynamic key change (roll-over) for an active TCP connection.
PCEP関係がPCEPのセッションを繰り返し閉じて再確立されていても長寿命である可能性が高いです。プロトコル関係はプロトコル相互作用の数が多いために、または長期間にわたって持続する場合、プロトコルのピアによって使用されるキーの変更は、[RFC4107]を推奨されています。そのTCP-MD5キーがPCEPセッションが終了して再起動する必要がされていることになるTCP接続を閉じて再オープンすることなく変更することはできません。それはPCEPのための重要な問題ではないかもしれません。 TCP認証オプション[TCP-AUTH]のための計画はアクティブなTCP接続のための動的なキー変更（ロールオーバー）を可能にするもことに留意されたいです。
If key exchange is used (for example, through IKE), then it is relatively simple to support dynamic key updates and apply these to PCEP.
鍵交換は、（例えば、IKEを介して）使用される場合、ダイナミックキー更新をサポートし、PCEPにこれらを適用することは比較的簡単です。
Note that in-band key management for the TCP Authentication Option [TCP-AUTH] is currently unresolved.
TCP認証オプション[TCP-AUTH]のためのインバンドの鍵管理は、現在未解決であることに留意されたいです。
[RFC3562] sets out some of the issues for the key management of secure TCP connections.
[RFC3562]はセキュアTCP接続の鍵管理のための問題のいくつかを設定します。
Unauthorized access to PCE function represents a variety of potential attacks. Not only may this be a simple denial-of-service attack (see Section 10.7), but it would be a mechanism for an intruder to determine important information about the network and operational network policies simply by inserting bogus computation requests. Furthermore, false computation requests could be used to predict where traffic will be placed in the network when real requests are made, allowing the attacker to target specific network resources.
PCE機能への不正アクセスは、潜在的な攻撃の多様性を表しています。これは（10.7節を参照）、単純なDoS攻撃かもしれないが、それは単に偽の計算要求を挿入することで、ネットワークと運用ネットワークポリシーに関する重要な情報を決定するために、侵入者のためのメカニズムだろうだけではなく。さらに、偽の計算要求は、実際の要求は、攻撃者が特定のネットワークリソースをターゲットにすることができ、行われたときにトラフィックがネットワーク内に配置される場所を予測するために使用することができます。
PCEs SHOULD be configurable for access policy. Where authentication is used, access policy can be achieved through the exchange or configuration of keys as described in Section 10.5. More simple policies MAY be configured on PCEs in the form of access lists where the IP addresses of the legitimate PCCs are listed. Policies SHOULD also be configurable to limit the type of computation requests that are supported from different PCCs.
PCEは、アクセスポリシーのために設定可能であるべきです。認証が使用される場合、セクション10.5に記載されているように、アクセスポリシーは、キーの交換または構成によって達成することができます。もっとシンプルなポリシーが正当なのPCCのIPアドレスがリストされているアクセスリストの形でのPCEに構成されるかもしれません。ポリシーはまた、異なるのPCCから支持されている計算要求の種類を制限するように構成可能であるべきです。
It is RECOMMENDED that access policy violations are logged by the PCE and are available for inspection by the operator to determine whether attempts have been made to attack the PCE. Such mechanisms MUST be lightweight to prevent them from being used to support denial-of-service attacks (see Section 10.7).
試みがPCEを攻撃するためになされたかどうかを判断するために、オペレータによりPCEによってログに記録されているポリシー違反にアクセスし、検査のために利用できることをお勧めします。このようなメカニズムは、サービス拒否攻撃（10.7節を参照）をサポートするために使用されているからそれらを防ぐために、軽量でなければなりません。
Denial-of-service (DoS) attacks could be mounted at the TCP level or at the PCEP level. That is, the PCE could be attacked through attacks on TCP or through attacks within established PCEP sessions.
サービス拒否（DoS）攻撃は、TCPレベルまたはPCEPレベルで取り付けることができます。これは、PCEは、TCP上または確立PCEPセッション内の攻撃による攻撃によって攻撃される可能性があります。
PCEP can be the target of TCP DoS attacks, such as for instance SYN attacks, as is the case for all protocols that run over TCP. Other protocol specifications have investigated this problem and PCEP can share their experience. The reader is referred to the specification of the Label Distribution Protocol (LDP) [RFC5036] for example. In order to protect against TCP DoS attacks, PCEP implementations can support the following techniques.
TCP上で実行されるすべてのプロトコルの場合のようにPCEPは、そのような場合SYN攻撃用としてTCP DoS攻撃のターゲットになることができます。他のプロトコル仕様は、この問題を調査しているとPCEPは、彼らの経験を共有することができます。読者は、例えば、ラベル配布プロトコル（LDP）[RFC5036]の仕様と呼ばれます。 TCP DoS攻撃から保護するためには、PCEP実装は、以下の技術をサポートすることができます。
o PCEP uses a single registered port for all communications. The PCE SHOULD listen for TCP connections only on ports where communication is expected.
O PCEPは、すべての通信のための単一の登録されているポートを使用しています。 PCEは唯一の通信が期待されているポート上のTCP接続をリッスンすべきです。
o The PCE MAY implement an access list to immediately reject (or discard) TCP connection attempts from unauthorized PCCs.
O PCEはすぐに不正のPCCからのTCP接続試行を拒否（または破棄）するアクセスリストを実装してもよいです。
o The PCE SHOULD NOT allow parallel TCP connections from the same PCC on the PCEP-registered port.
O PCEはPCEP登録ポートで同じPCCからの並列TCP接続を許可しません。
o The PCE MAY require the use of the MD5 option on all TCP connections, and MAY reject (or discard) any connection setup attempt that does not use MD5. A PCE MUST NOT accept any SYN packet for which the MD5 segment checksum is invalid. Note, however, that the use of MD5 requires that the receiver use CPU resources to compute the checksum before it can decide to discard an otherwise acceptable SYN segment.
O PCEは、すべてのTCP接続上のMD5オプションを使用する必要があり、MD5を使用していない任意の接続設定の試みを拒否（または破棄）するかもしれません。 PCEは、MD5セグメントチェックサムが無効であるため、任意のSYNパケットを受け入れてはいけません。 MD5の使用は、それがそうでなければ許容されるSYNセグメントを廃棄することを決定する前に、受信機用CPUリソースがチェックサムを計算することが必要であること、しかし、注意してください。
A PCEP implementation may be subject to DoS attacks within a legitimate PCEP session. For example, a PCC might send a very large number of PCReq messages causing the PCE to become congested or causing requests from other PCCs to be queued.
PCEPの実装は、正当なPCEPセッション内でDoS攻撃を受ける可能性があります。例えば、PCCは、PCEが混雑になることを引き起こすか、またはキューに登録されるように、他ののPCCからの要求を引き起こしPCReqメッセージの非常に大きな数を送信することがあります。
Note that the direct use of the Priority field on the RP object to prioritize received requests does not provide any protection since the attacker could set all requests to be of the highest priority.
攻撃者が最優先であることがすべての要求を設定する可能性があるため、受信した要求を優先するRPオブジェクトのPriorityフィールドの直接使用は任意の保護を提供しないことに注意してください。
Therefore, it is RECOMMENDED that PCE implementations include input shaping/policing mechanisms that either throttle the requests received from any one PCC, or apply queuing or priority-degradation techniques to over-communicative PCCs.
したがって、PCE実装がいずれかPCCから受信した要求を絞る、または過剰コミュニケーションのPCCにキューイングまたは優先分解技術を適用するいずれかの入力シェーピング/ポリシング機構を含むことが推奨されます。
Such mechanisms MAY be set by default, but SHOULD be available for configuration. Such techniques may be considered particularly important in multi-service-provider environments to protect the resources of one service provider from unwarranted, over-zealous, or malicious use by PCEs in another service provider.
このようなメカニズムは、デフォルトで設定されてもよいが、コンフィギュレーションのために利用可能であるべきです。このような技術は、他のサービスプロバイダでのPCEによってオーバー熱心な、不当な、または悪意のある使用からのサービス・プロバイダのリソースを保護するために、マルチサービス・プロバイダー環境では特に重要と考えることができます。
The authors would like to thank Dave Oran, Dean Cheng, Jerry Ash, Igor Bryskin, Carol Iturrade, Siva Sivabalan, Rich Bradford, Richard Douville, Jon Parker, Martin German, and Dennis Aristow for their very valuable input. The authors would also like to thank Fabien Verhaeghe for the very fruitful discussions and useful suggestions. David McGrew and Brian Weis provided valuable input to the Security Considerations section.
作者は彼らの非常に貴重な入力のためにデーブオラン、ディーン・チェン、ジェリー・アッシュ、イゴールBryskin、キャロルIturrade、シヴァシババラン、リッチブラッドフォード、リチャード・Douville、ジョン・パーカー、マーティンドイツ語、およびデニスAristowに感謝したいと思います。著者はまた、非常に実りある議論と有益な提案をファビアンVerhaegheに感謝したいと思います。デビッドマグリューとブライアン・ワイスは、Security Considerations部に貴重な入力を提供します。
Ross Callon, Magnus Westerlund, Lars Eggert, Pasi Eronen, Tim Polk, Chris Newman, and Russ Housley provided important input during IESG review.
ロスCallon、マグヌスウェスター、ラースEggertの、パシEronen、ティムポーク、クリス・ニューマン、とラスHousleyはIESGレビューの間に重要な入力を提供しました。
[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月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K.とY. Rekhter、 "資源予約プロトコルでアンナンバードリンクシグナリング - トラフィックエンジニアリング（RSVP-TE）"、RFC 3477、2003年1月。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]パン、P.、ツバメ、G.、およびA.アトラスは、RFC 4090、2005年5月 "高速リルート機能拡張は、LSPトンネルの-TEをRSVPに"。
[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月。
[BGP-SEC] Christian, B. and T. Tauber, "BGP Security Requirements", Work in Progress, November 2008.
[BGP-SEC]クリスチャン、B.およびT.タウバー、 "BGPセキュリティ要件"、進歩、2008年11月の作業。
[IEEE.754.1985] IEEE Standard 754, "Standard for Binary Floating-Point Arithmetic", August 1985.
[IEEE.754.1985] IEEE規格754、「標準バイナリ浮動小数点演算のために」、1985年8月。
[INTER-LAYER] Oki, E., Roux, J., Kumaki, K., Farrel, A., and T. Takeda, "PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering", Work in Progress, January 2009.
[INTER-LAYER]沖、E.、ルー、J.、熊木、K.、ファレル、A.、およびT.武田、 "レイヤ間トラヒックエンジニアリングのためのPCC-PCEコミュニケーションとPCEディスカバリー要件"、進行中で働い、2009年1月。
[MPLS-SEC] Fang, L. and M. Behringer, "Security Framework for MPLS and GMPLS Networks", Work in Progress, November 2008.
[MPLS-SEC]牙、L.およびM.ベリンガー、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク"、進歩、2008年11月の作業。
[PCE-MANAGE] Farrel, A., "Inclusion of Manageability Sections in PCE Working Group Drafts", Work in Progress, January 2009.
[PCE-管理]ファレル、A.、「PCEワーキンググループドラフトでの管理性のセクションを含める」、進歩、2009年1月に作業。
[PCE-MONITOR] Vasseur, J., Roux, J., and Y. Ikejiri, "A set of monitoring tools for Path Computation Element based Architecture", Work in Progress, November 2008.
[PCE-MONITOR] Vasseur、J.、ルー、J.、およびY.池尻、「パス計算要素ベースのアーキテクチャのための監視ツールのセット」、進歩、2008年11月の作業。
[PCEP-MIB] Stephan, E. and K. Koushik, "PCE communication protocol (PCEP) Management Information Base", Work in Progress, November 2008.
[PCEP-MIB]ステファン、E.およびK.コウシク、 "PCE通信プロトコル（PCEP）管理情報ベース"、進歩、2008年11月ワーク。
[RBNF] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications", Work in Progress, November 2008.
[RBNF]ファレル、A.は、進歩、2008年11月の作業「バッカス記法（RBNF）各種プロトコル仕様書で使用される構文を削減します」。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562]リーチ、M.、 "TCP MD5署名オプションのためのキー管理の考慮事項"、RFC 3562、2003年7月。
[RFC3785] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP 87, RFC 3785, May 2004.
[RFC3785]ルFaucheur、F.、Uppili、R.、Vedrenne、A.、メルクス、P.、およびT. Telkamp、 "第二のMPLSトラフィックエンジニアリング（TE）メトリックとしてインテリアゲートウェイプロトコル（IGP）メトリックの使用" 、BCP 87、RFC 3785、2004年5月。
[RFC4022] Raghunarayan, R., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, March 2005.
[RFC4022] Raghunarayan、R.、 "伝送制御プロトコルのための管理情報ベース（TCP）"、RFC 4022、2005年3月。
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005.
[RFC4101]レスコラ、E.およびIAB、 "ライティング・プロトコル・モデル"、RFC 4101、2005年6月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107] Bellovin氏、S.とR. Housley氏、 "暗号鍵管理のためのガイドライン"、BCP 107、RFC 4107、2005年6月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120]ノイマン、C.、ゆう、T.、ハルトマン、S.、およびK.レイバーン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 4120、2005年7月。
[RFC4278] Bellovin, S. and A. Zinin, "Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification", RFC 4278, January 2006.
[RFC4278] Bellovin氏、S.およびA.ジニン、 "TCP MD5署名オプション（RFC 2385）およびBGP-4仕様に関して標準成熟差異"、RFC 4278、2006年1月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009.
[RFC5420]ファレル、A.編、Papadimitriou、D.、Vasseur、JP。、およびA. Ayyangarps、 "リソース予約プロトコル・トラフィック・エンジニアリング（RSVP-TE）を使用してMPLS LSPの確立のための属性のエンコーディング"、RFC 5420、 2009年2月。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]ファレル、A.、Vasseur、J.、およびJ.アッシュ、 "パス計算要素（PCE）ベースのアーキテクチャ"、RFC 4655、2006年8月。
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657]アッシュ、J.とJ.ル・ルー、 "パス計算要素（PCE）通信プロトコルジェネリック要件"、RFC 4657、2006年9月。
[RFC4674] Le Roux, J., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
[RFC4674]ル・ルー、J.、RFC 4674、2006年10月 "経路計算エレメント（PCE）の発見のための要件"。
[RFC4927] Le Roux, J., "Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering", RFC 4927, June 2007.
[RFC4927]ル・ルー、J.、「パス計算要素通信プロトコル（PCECP）エリア間MPLSおよびGMPLSトラフィックエンジニアリングのための特定の要件」、RFC 4927、2007年6月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036]アンデション、L.、Minei、I.、およびB.トーマス、 "LDP仕様"、RFC 5036、2007年10月。
[RFC5088] Le Roux, JL., Vasseur, JP., 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., Vasseur, JP., 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、2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", RFC 5376, November 2008.
[RFC5376]ビタール、N.、張、R.、およびK.熊木、RFC 5376、 "パス計算要素通信プロトコル（PCECP）のためのInter-ASの要件" 2008年11月。
[TCP-AUTH] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", Work in Progress, November 2008.
[TCP-AUTH]タッチ、J.、マンキン、A.、およびR. Bonica、 "TCP認証オプション"、進歩、2008年11月の作業。
Appendix A. PCEP Finite State Machine (FSM)
付録A. PCEP有限状態機械（FSM）
The section describes the PCEP finite state machine (FSM). PCEP Finite State Machine
セクションでは、PCEP有限状態機械（FSM）を記述する。 PCEP有限ステートマシン
+-+-+-+-+-+-+<------+
+------| SessionUP |<---+ |
| +-+-+-+-+-+-+ | |
| | |
| +->+-+-+-+-+-+-+ | |
| | | KeepWait |----+ |
| +--| |<---+ |
|+-----+-+-+-+-+-+-+ | |
|| | | |
|| | | |
|| V | |
|| +->+-+-+-+-+-+-+----+ |
|| | | OpenWait |-------+
|| +--| |<------+
||+----+-+-+-+-+-+-+<---+ |
||| | | |
||| | | |
||| V | |
||| +->+-+-+-+-+-+-+ | |
||| | |TCPPending |----+ |
||| +--| | |
|||+---+-+-+-+-+-+-+<---+ |
|||| | | |
|||| | | |
|||| V | |
|||+--->+-+-+-+-+ | |
||+---->| Idle |-------+ |
|+----->| |----------+
+------>+-+-+-+-+
Figure 23: PCEP Finite State Machine for the PCC
図23：PCCのためのPCEP有限状態マシン
PCEP defines the following set of variables:
PCEPは、次の変数のセットを定義します。
Connect: the timer (in seconds) started after having initialized a TCP connection using the PCEP-registered TCP port. The value of the Connect timer is 60 seconds.
接続：（秒）タイマーがPCEP登録TCPポートを使用してTCP接続を初期化した後に開始しました。接続タイマーの値は60秒です。
ConnectRetry: the number of times the system has tried to establish a TCP connection with a PCEP peer without success.
ConnectRetry：システムは成功せずPCEPピアとのTCP接続を確立しようとした回数。
ConnectMaxRetry: the maximum number of times the system tries to establish a TCP connection using the PCEP-registered TCP port before going back to the Idle state. The value of the ConnectMaxRetry is 5.
ConnectMaxRetry：最大回数は、システムがアイドル状態に戻る前に、PCEP登録TCPポートを使用してTCP接続を確立しようとします。 ConnectMaxRetryの値は5です。
OpenWait: the timer that corresponds to the amount of time a PCEP peer will wait to receive an Open message from the PCEP peer after the expiration of which the system releases the PCEP resource and goes back to the Idle state. The OpenWait timer has a fixed value of 60 seconds.
OpenWait：PCEPピアは、システムがPCEPリソースを解放し、バックアイドル状態になっているの満了後PCEPピアからのオープンメッセージを受信するために待機する時間の量に対応するタイマー。 OpenWaitタイマーは、60秒の固定値を持っています。
KeepWait: the timer that corresponds to the amount of time a PCEP peer will wait to receive a Keepalive or a PCErr message from the PCEP peer after the expiration of which the system releases the PCEP resource and goes back to the Idle state. The KeepWait timer has a fixed value of 60 seconds.
KeepWait：PCEPピアは、システムがPCEPリソースを解放し、バックアイドル状態になっているの満了後PCEPピアからのキープアライブやPCErrメッセージを受信するために待機する時間の量に対応するタイマー。 KeepWaitタイマーは、60秒の固定値を持っています。
OpenRetry: the number of times the system has received an Open message with unacceptable PCEP session characteristics.
OpenRetry：システムが許容できないPCEPセッション特性を持つオープンメッセージを受信した回数。
The following two state variables are defined:
以下の2つの状態変数が定義されています。
RemoteOK: a boolean that is set to 1 if the system has received an acceptable Open message.
RemoteOK：システムが許容可能なオープンメッセージを受信した場合に1に設定されているブール。
LocalOK: a boolean that is set to 1 if the system has received a Keepalive message acknowledging that the Open message sent to the peer was valid.
LocalOK：システムがピアに送信オープンメッセージが有効であったことを認めるキープアライブメッセージを受信した場合に1に設定されているブール。
Idle State:
アイドル状態：
The idle state is the initial PCEP state where the PCEP (also referred to as "the system") waits for an initialization event that can either be manually triggered by the user (configuration) or automatically triggered by various events. In Idle state, PCEP resources are allocated (memory, potential process, etc.) but no PCEP messages are accepted from any PCEP peer. The system listens to the PCEP-registered TCP port.
アイドル状態では（また、「システム」と呼ぶ）PCEPは、手動ユーザ（コンフィギュレーション）によってトリガまたは自動様々なイベントによってトリガすることができる初期化イベントを待つ初期PCEP状態です。アイドル状態では、PCEPリソースは、（メモリ、潜在的なプロセス、等）を割り当てられるが、何らPCEPメッセージは任意PCEPピアから受け付けていません。システムは、PCEP登録TCPポートにリッスンします。
The following set of variables are initialized:
次の変数のセットが初期化されます：
TCPRetry=0,
TCPRetry = 0、
LocalOK=0,
LocalOK = 0、
RemoteOK=0,
RemoteOK = 0、
OpenRetry=0.
OpenRetry = 0。
Upon detection of a local initialization event (e.g., user configuration to establish a PCEP session with a particular PCEP peer, local event triggering the establishment of a PCEP session with a PCEP peer such as the automatic detection of a PCEP peer), the system:
ローカル初期化イベントを検出すると（例えば、ユーザ設定は、特定のPCEPピアとPCEPセッションを確立するために、そのようなPCEPピアの自動検出としてPCEPピアとPCEPセッションの確立をトリガするローカルイベント）システム：
o Initiates a TCP connection with the PCEP peer,
oは、PCEPピアとのTCP接続を開始します
o Starts the Connect timer,
oは、接続タイマーを開始します
o Moves to the TCPPending state.
O TCPPending状態に移動します。
Upon receiving a TCP connection on the PCEP-registered TCP port, if the TCP connection establishment succeeds, the system:
TCP接続の確立に成功した場合、PCEP登録TCPポートにTCP接続を受信すると、システム。
o Sends an Open message,
oはオープンメッセージを送信し、
o Starts the OpenWait timer,
oは、OpenWaitタイマーを開始します
o Moves to the OpenWait state.
oはOpenWait状態に移動します。
If the connection establishment fails, the system remains in the Idle state. Any other event received in the Idle state is ignored.
接続の確立に失敗した場合は、システムがアイドル状態のまま。アイドル状態で受信された他のイベントは無視されます。
It is expected that an implementation will use an exponentially increasing timer between automatically generated Initialization events and between retries of TCP connection establishment.
実装が自動的に生成された初期化イベント間のTCPコネクション確立の再試行の間に指数関数的に増加するタイマーを使用することが期待されます。
TCPPending State:
TCPPending状態：
If the TCP connection establishment succeeds, the system:
TCPコネクションの確立が成功した場合、システム：
o Sends an Open message,
oはオープンメッセージを送信し、
o Starts the OpenWait timer,
oは、OpenWaitタイマーを開始します
o Moves to the OpenWait state.
oはOpenWait状態に移動します。
If the TCP connection establishment fails (an error is detected during the TCP connection establishment) or the Connect timer expires:
TCPコネクションの確立に失敗した場合（エラーがTCP接続の確立中に検出された）または接続タイマーが満了します：
o If ConnectRetry = ConnectMaxRetry, the system moves to the Idle State.
O ConnectRetry = ConnectMaxRetry場合は、システムがアイドル状態に移動します。
o If ConnectRetry < ConnectMaxRetry, the system:
O ConnectRetry <ConnectMaxRetry、システムの場合：
In response to any other event, the system releases the PCEP resources for that peer and moves back to the Idle state.
他のイベントに応答して、システムがそのピアのPCEPリソースを解放し、アイドル状態に戻ります。
OpenWait State:
OpenWait状態：
In the OpenWait state, the system waits for an Open message from its PCEP peer.
OpenWait状態では、システムは、PCEPピアからオープンメッセージを待ちます。
If the system receives an Open message from the PCEP peer before the expiration of the OpenWait timer, the system first examines all of its sessions that are in the OpenWait or KeepWait state. If another session with the same PCEP peer already exists (same IP address), then the system performs the following collision-resolution procedure:
システムはOpenWaitタイマーの満了前に、PCEPピアからオープンメッセージを受信した場合、システムは、最初OpenWait又はKeepWait状態にあるそのセッションの全てを検査します。同じPCEPピアと別のセッションが既に（同じIPアドレス）が存在する場合、システムは、次の衝突解決手順を実行します。
o If the system has initiated the current session and it has a lower IP address than the PCEP peer, the system closes the TCP connection, releases the PCEP resources for the pending session, and moves back to the Idle state.
システムは、現在のセッションを開始しており、それがPCEPピアより低いIPアドレスを持っている場合は、O、システムは、TCPコネクションを閉じ、保留中のセッションのためのPCEPリソースを解放し、アイドル状態に戻ります。
o If the session was initiated by the PCEP peer and the system has a higher IP address that the PCEP peer, the system closes the TCP connection, releases the PCEP resources for the pending session, and moves back to the Idle state.
OセッションはPCEPピアによって開始され、システムは、PCEPピアは、システムがTCP接続をクローズ高いIPアドレスを持つ保留中のセッションのためPCEPリソースを解放し、アイドル状態に戻りました場合。
o Otherwise, the system checks the PCEP session attributes (Keepalive frequency, DeadTimer, etc.).
Oそうでない場合、システムは、PCEPセッション属性（キープアライブ周波数、DeadTimer、等）をチェックします。
If an error is detected (e.g., malformed Open message, reception of a message that is not an Open message, presence of two OPEN objects), PCEP generates an error notification, the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=1. The system releases the PCEP resources for the PCEP peer, closes the TCP connection, and moves to the Idle state.
エラー（例えば、不正な形式のメッセージを開き、オープンメッセージではないメッセージの受信、二つの開放物体の存在）が検出された場合、PCEPは、エラー通知を生成し、PCEPピアはエラータイプ= 1でPCErrメッセージを送信しエラー値= 1。このシステムは、PCEPピアのためのPCEPリソースを解放TCP接続を閉じ、そしてアイドル状態に移行します。
If no errors are detected, OpenRetry=1, and the session characteristics are unacceptable, the PCEP peer sends a PCErr with Error-Type=1 and Error-value=5, and the system releases the PCEP resources for that peer and moves back to the Idle state.
エラーが検出されない場合、OpenRetry = 1、およびセッション特性が許容できない、PCEPピアはエラータイプ= 1とエラー値= 5のPCErrを送信し、システムがそのピアのPCEPリソースを解放しに戻りアイドル状態。
If no errors are detected, and the session characteristics are acceptable to the local system, the system:
エラーが検出されず、セッション特性がローカルシステムに許容される場合、システム
o Sends a Keepalive message to the PCEP peer,
oは、PCEPピアにキープアライブメッセージを送信します
o Starts the Keepalive timer,
oは、キープアライブタイマーを開始します
o Sets the RemoteOK variable to 1.
oは1にRemoteOK変数を設定します。
If LocalOK=1, the system clears the OpenWait timer and moves to the UP state.
LocalOK = 1の場合、システムはOpenWaitタイマをクリアし、UP状態に移行します。
If LocalOK=0, the system clears the OpenWait timer, starts the KeepWait timer, and moves to the KeepWait state.
LocalOK = 0は、システムがOpenWaitタイマーをクリアした場合は、KeepWaitタイマーを開始し、KeepWait状態に移行します。
If no errors are detected, but the session characteristics are unacceptable and non-negotiable, the PCEP peer sends a PCErr with Error-Type=1 and Error-value=3, and the system releases the PCEP resources for that peer and moves back to the Idle state.
エラーが検出されないが、セッション特性が許容できない非交渉されている場合、PCEPピアはエラータイプ= 1とエラー値= 3とPCErrを送信し、システムがそのピアのPCEPリソースを解放しに戻りアイドル状態。
If no errors are detected, and OpenRetry is 0, and the session characteristics are unacceptable but negotiable (such as, the Keepalive period or the DeadTimer), then the system:
エラーが検出されない、とOpenRetryは0であり、セッションの特性は、システム（例えば、キープアライブ期間又はDeadTimerように）許容できないが、交渉している場合：
o Increments the OpenRetry variable,
oは、OpenRetry変数をインクリメントします
o Sends a PCErr message with Error-Type=1 and Error-value=4 that contains proposed acceptable session characteristics,
Oは、提案に許容されるセッション特性が含まエラータイプ= 1 PCErrメッセージとエラー値= 4を送信し、
o If LocalOK=1, the system restarts the OpenWait timer and stays in the OpenWait state.
O LocalOK = 1の場合、システムはOpenWaitタイマーを再起動し、OpenWait状態のままです。
o If LocalOK=0, the system clears the OpenWait timer, starts the KeepWait timer, and moves to the KeepWait state.
LocalOK = 0は、システムがOpenWaitタイマーをクリアした場合は、O、KeepWaitタイマーを開始し、KeepWait状態に移行します。
If no Open message is received before the expiration of the OpenWait timer, the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=2, the system releases the PCEP resources for the PCEP peer, closes the TCP connection, and moves to the Idle state.
何を開き、メッセージがOpenWaitタイマの満了前に受信されない場合は、PCEPピアは、システムがPCEPピアのためのPCEPリソースを解放エラー-タイプ= 1とエラー値= 2でPCErrメッセージを送信TCP接続を閉じ、そしてアイドル状態に移行します。
In response to any other event, the system releases the PCEP resources for that peer and moves back to the Idle state.
他のイベントに応答して、システムがそのピアのPCEPリソースを解放し、アイドル状態に戻ります。
KeepWait State:
KeepWait状態：
In the Keepwait state, the system waits for the receipt of a Keepalive from its PCEP peer acknowledging its Open message or a PCErr message in response to unacceptable PCEP session characteristics proposed in the Open message.
Keepwait状態では、システムは、そのオープンメッセージまたはオープンメッセージで提案されている許容できないPCEPセッション特性に応じてPCErrメッセージを承認そのPCEPピアからのキープアライブの受信を待ちます。
If an error is detected (e.g., malformed Keepalive message), PCEP generates an error notification, the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=1. The system releases the PCEP resources for the PCEP peer, closes the TCP connection, and moves to the Idle state.
エラー（例えば、不正なキープアライブメッセージ）が検出された場合、PCEPは、エラー通知を生成し、PCEPピアはエラータイプ= 1とエラー値= 1 PCErrメッセージを送信します。このシステムは、PCEPピアのためのPCEPリソースを解放TCP接続を閉じ、そしてアイドル状態に移行します。
If a Keepalive message is received before the expiration of the KeepWait timer, then the system sets LocalOK=1 and:
キープアライブメッセージはKeepWaitタイマの満了前に受信された場合、システムはLocalOK = 1を設定します。
o If RemoteOK=1, the system clears the KeepWait timer and moves to the UP state.
O RemoteOK = 1の場合、システムはKeepWaitタイマをクリアし、UP状態に移行します。
o If RemoteOK=0, the system clears the KeepWait timer, starts the OpenWait timer, and moves to the OpenWait State.
RemoteOK = 0は、システムがKeepWaitタイマーをクリアした場合は、O、OpenWaitタイマーを開始し、OpenWait州に移動します。
If a PCErr message is received before the expiration of the KeepWait timer:
PCErrメッセージはKeepWaitタイマーの満了前に受信されている場合：
1. If the proposed values are unacceptable, the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=6, and the system releases the PCEP resources for that PCEP peer, closes the TCP connection, and moves to the Idle state.
提案された値が受け入れられない場合1は、PCEPピアはエラータイプ= 1とエラー値= 6を有するPCErrメッセージを送信し、システムは、PCEPピアのPCEPリソースを解放し、TCP接続を閉じ、そしてへ移動アイドル状態。
2. If the proposed values are acceptable, the system adjusts its PCEP session characteristics according to the proposed values received in the PCErr message, restarts the KeepWait timer, and sends a new Open message. If RemoteOK=1, the system restarts the KeepWait timer and stays in the KeepWait state. If RemoteOK=0, the system clears the KeepWait timer, starts the OpenWait timer, and moves to the OpenWait state.
2.提案された値が許容可能である場合、システムは、PCErrメッセージで受信した提案値に応じてPCEPセッション特性を調整KeepWaitタイマーを再起動し、新しいオープンメッセージを送信します。 RemoteOK = 1の場合、システムはKeepWaitタイマーを再起動し、KeepWait状態のままです。 RemoteOK = 0は、システムがKeepWaitタイマーをクリアした場合は、OpenWaitタイマーを開始し、OpenWait状態に移行します。
If neither a Keepalive nor a PCErr is received after the expiration of the KeepWait timer, the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=7, and the system releases the PCEP resources for that PCEP peer, closes the TCP connection, and moves to the Idle State.
キープアライブもPCErrどちらもKeepWaitタイマーの満了後に受信されている場合は、PCEPピアはエラー-タイプ= 1とPCErrメッセージとエラー値= 7を送信し、システムは、そのPCEPピアのためのPCEPリソースを解放閉じTCP接続、およびアイドル状態に移行します。
In response to any other event, the system releases the PCEP resources for that peer and moves back to the Idle state.
他のイベントに応答して、システムがそのピアのPCEPリソースを解放し、アイドル状態に戻ります。
UP State:
UP州：
In the UP state, the PCEP peer starts exchanging PCEP messages according to the session characteristics.
UP状態では、PCEPピアがセッション特性に応じPCEPメッセージ交換を開始します。
If the Keepalive timer expires, the system restarts the Keepalive timer and sends a Keepalive message.
キープアライブタイマーが満了した場合、システムは、キープアライブタイマーを再起動し、キープアライブメッセージを送信します。
If no PCEP message (Keepalive, PCReq, PCRep, PCNtf) is received from the PCEP peer before the expiration of the DeadTimer, the system terminates the PCEP session according to the procedure defined in Section 6.8, releases the PCEP resources for that PCEP peer, closes the TCP connection, and moves to the Idle State.
何PCEPメッセージ（キープアライブ、PCReq、PCRep、PCNtf）はDeadTimerの満了前PCEPピアから受信されない場合、システムは、セクション6.8で定義された手順に従ってPCEPセッションを終了し、そのPCEPピアのPCEPリソースを解放TCP接続を閉じ、そしてアイドル状態に移動します。
If a malformed message is received, the system terminates the PCEP session according to the procedure defined in Section 6.8, releases the PCEP resources for that PCEP peer, closes the TCP connection and moves to the Idle State.
不正な形式のメッセージを受信した場合、システムは、6.8節で定義された手順に従って、PCEPセッションを終了し、そのPCEPピアのためのPCEPリソースを解放し、TCP接続とアイドル状態への移行が終了します。
If the system detects that the PCEP peer tries to set up a second TCP connection, it stops the TCP connection establishment and sends a PCErr with Error-Type=9.
システムはPCEPピアが第二のTCP接続をセットアップしようとしたことを検出した場合は、TCPコネクションの確立を停止し、エラー・タイプ= 9でPCErrを送信します。
If the TCP connection fails, the system releases the PCEP resources for that PCEP peer, closes the TCP connection, and moves to the Idle State.
TCP接続が失敗した場合、システムはそのPCEPピアにPCEPリソースを解放し、TCP接続を閉じ、そしてアイドル状態に移動します。
Appendix B. PCEP Variables
付録B.のPCEP変数
PCEP defines the following configurable variables:
PCEPは、以下の設定可能な変数を定義します。
Keepalive timer: minimum period of time between the sending of PCEP messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer. A suggested value for the Keepalive timer is 30 seconds.
キープアライブタイマー：PCEPピアにPCEPメッセージ（キープアライブ、PCReq、PCRep、PCNtf）の送信の間の時間の最小期間。キープアライブタイマーの推奨値は30秒です。
DeadTimer: period of timer after the expiration of which a PCEP peer declares the session down if no PCEP message has been received.
DeadTimer：なしPCEPメッセージを受信していない場合PCEPピアがダウンしてセッションを宣言したが満了した後、タイマーの時間。
SyncTimer: timer used in the case of synchronized path computation request using the SVEC object defined in Section 7.13.3. Consider the case where a PCReq message is received by a PCE that contains the SVEC object referring to M synchronized path computation requests. If after the expiration of the SyncTimer all the M path computation requests have not been received, a protocol error is triggered and the PCE MUST cancel the whole set of path computation requests. The aim of the SyncTimer is to avoid the storage of unused synchronized requests should one of them get lost for some reason (e.g., a misbehaving PCC). Thus, the value of the SyncTimer must be large enough to avoid the expiration of the timer under normal circumstances. A RECOMMENDED value for the SyncTimer is 60 seconds.
SyncTimer：セクション7.13.3に規定されSVECオブジェクトを使用して同期経路計算リクエストの場合に使用されるタイマー。 PCReqメッセージはM同期経路計算リクエストを参照SVECオブジェクトを含むPCEによって受信される場合を考えます。 SyncTimerの満了後、すべてのM経路計算要求を受信していない場合は、プロトコルエラーがトリガされ、PCEは、経路計算要求のセット全体をキャンセルする必要があります。 SyncTimerの目的は、そのうちの一つが何らかの理由（例えば、不正な動作PCC）のために迷子にする必要があり、未使用の同期要求の保存を避けるためです。このように、SyncTimerの値は、通常の状況下では、タイマーの満了を回避するのに十分な大きさでなければなりません。 SyncTimerの推奨値は60秒です。
MAX-UNKNOWN-REQUESTS: A RECOMMENDED value is 5.
MAX-UNKNOWN-REQUESTS：推奨値は5です。
MAX-UNKNOWN-MESSAGES: A RECOMMENDED value is 5.
MAX-UNKNOWN-MESSAGES：推奨値は5です。
Appendix C. Contributors
付録C.協力者
The content of this document was contributed by those listed below and the editors listed at the end of the document.
この文書の内容は、以下に列挙されたものと文書の最後に記載されている編集者によって寄与されました。
Arthi Ayyangar Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA
Arthi Ayyangarジュニパーネットワークスの1194 N.マチルダアベニューサニーベール、CA 94089 USA
EMail: arthi@juniper.net
メールアドレス：arthi@juniper.net
Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944
エードリアンファレル老犬のコンサルティング電話：+44（0）1978 860944
EMail: adrian@olddog.co.uk
メールアドレス：adrian@olddog.co.uk
Eiji Oki NTT Midori 3-9-11 Musashino, Tokyo, 180-8585 JAPAN
えいじ おき んっｔ みどり ３ー９ー１１ むさしの、 ときょ、 １８０ー８５８５ じゃぱん
EMail: oki.eiji@lab.ntt.co.jp
メールアドレス：oki.eiji@lab.ntt.co.jp
Alia Atlas British Telecom
アリアアトラスブリティッシュテレコム
EMail: akatlas@alum.mit.edu
メールアドレス：akatlas@alum.mit.edu
Andrew Dolganow Alcatel 600 March Road Ottawa, ON K2K 2E6 CANADA
アンドリューDolganowアルカテルK2K 2E6 CANADA ON 600月の道オタワ、
EMail: andrew.dolganow@alcatel.com
メールアドレス：andrew.dolganow@alcatel.com
Yuichi Ikejiri NTT Communications Corporation 1-1-6 Uchisaiwai-cho, Chiyoda-ku Tokyo, 100-819 JAPAN
ゆいち いけじり んっｔ こっむにかちおんｓ こｒぽらちおん １ー１ー６ うちさいわいーちょ、 ちよだーく ときょ、 １００ー８１９ じゃぱん
EMail: y.ikejiri@ntt.com
メールアドレス：y.ikejiri@ntt.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo, 102-8460 JAPAN
けんじ くまき Ｋっぢ こｒぽらちおん がｒでん あいｒ とうぇｒ いいだばし、 ちよだーく、 ときょ、 １０２ー８４６０ じゃぱん
EMail: ke-kumaki@kddi.com
メールアドレス：ke-kumaki@kddi.com
Authors' Addresses
著者のアドレス
JP Vasseur (editor) Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA
JP Vasseur（編集者）、シスコシステムズ1414年マサチューセッツアベニューボックスボロー、MA 01719 USA
EMail: jpv@cisco.com
メールアドレス：jpv@cisco.com
JL Le Roux (editor) France Telecom 2, Avenue Pierre-Marzin Lannion 22307 FRANCE
JLル・ルー（編集者）フランステレコム2、アベニューピエールMarzin 22307ラニオンFRANCE
EMail: jeanlouis.leroux@orange-ftgroup.com
メールアドレス：jeanlouis.leroux@orange-ftgroup.com