[要約] RFC 5440は、PCE間の通信を可能にするPCEPの仕様を定義しています。PCEPは、ネットワーク内の経路計算エンティティ（PCE）間の情報交換を行うために使用されます。このRFCの目的は、PCEPの機能とメッセージフォーマットを明確にし、ネットワークの経路計算を効率化することです。
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)
パス計算要素（PCE）通信プロトコル（PCEP）
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
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.
このドキュメントは、PATH計算クライアント（PCC）とPCE間の通信、または2つのPCE間のパス計算要素（PCE）通信プロトコル（PCEP）を指定します。このような相互作用には、パス計算要求とパス計算応答、およびマルチプロトコルラベルスイッチング（MPLS）および一般化されたMPLS（GMPL）トラフィックエンジニアリングのコンテキストでの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]は、マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPLS（GMPLS）トラフィックエンジニアリングラベルスイッチドパス（TE LSP）の計算のためのパス計算要素（PCE）ベースのモデルの動機とアーキテクチャを説明しています。このモデルにより、PATH計算クライアント（PCC）からPCEを分離することができ、PCE間の協力が可能になります。これには、PCCとPCEの間、およびPCE間の通信プロトコルが必要です。[RFC4657]は、PCCとPCCの間、およびPCE間で同じプロトコルを使用することを含む、このようなプロトコルの一般的な要件を述べています。追加のアプリケーション固有の要件（エリア間、ASなどのシナリオ）は[RFC4657]には含まれていませんが、導入されている他の要件を処理するためにソリューションプロトコルを簡単に拡張できる必要があるという要件があります。アプリケーション固有の要件文書で。このようなアプリケーション固有の要件の例は、[RFC4927]、[RFC5376]、および[層間]です。
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とPCC間、または2つの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のような抽象的なノードである可能性のある宛先を表す少なくとも1つのルーズホップを含む、厳格なホップとルーズホップのミックス。
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]で指定されているように、Backus-Naur形式（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].
同様に、PCCのセットを発見するために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の間の通信プロトコルが必要です。PCEPは、[RFC4657]に準拠して、PCCとPCC間、または2つのPCE間の通信専用に設計されたプロトコルです[RFC4657]：PCCはPCEPを使用して、1つ以上のTE LSPのパス計算要求を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：PCCからPCEに送信された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：PATH計算リクエストに応答して、PCCからPCCに送信された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：PCCからPCCからPCEに送信されたPCEP通知メッセージか、PCCからPCCに送信されて特定のイベントが通知されます。
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.
利用可能なPCESのセットは、PCCで静的に構成されているか、動的に発見されたものです。1つ以上の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メッセージは単一の送信ユニットと見なされ、メッセージの一部をインターリーブしてはなりません。したがって、たとえば、PCREQを送信してセッションを閉じることを希望するPCCは、緊密なメッセージの送信を開始する前にリクエストメッセージを完了する必要があります。
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.
1) PCCとPCEの間にTCP接続（3ウェイハンドシェイク）の確立。
2) Establishment of a PCEP session over the TCP connection.
2) TCP接続を介したPCEPセッションの確立。
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セッションの確立を開始します。これらのパラメーターは、オープンメッセージ内で携帯されており、KeepAliveタイマー、Deadtimer、およびPath計算要求がPCEに送信される可能性のある条件を指定する潜在的に他の詳細な機能とポリシールールが含まれます。PCEPセッションの確立フェーズが失敗した場合、PCEPピアがセッションパラメーターまたはPCEPピアのいずれかが確立タイマーの有効期限が切れた後に回答しないため、TCP接続はすぐに閉じられます。連続したレトリーは許可されていますが、実装は指数関数的なバックオフセッションの確立手順を使用する必要があります。
Keepalive messages are used to acknowledge Open messages, and are used once the PCEP session has been successfully established.
KeepAliveメッセージは、オープンメッセージを確認するために使用され、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セッションは1つだけです。PCEPポートの1つのTCP接続のみが、一度にPCEPピアのペア間に存在することができます。
Details about the Open message and the Keepalive message can be found in Sections 6.2 and 6.3, respectively.
開いたメッセージとKeepAliveメッセージの詳細は、それぞれセクション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セッションが確立されると、KeepAliveメッセージの交換はオプションであることに注意してください。）
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に依存する可能性がありますが、TCP接続を乱すことなくリモートPCEP関数が失敗した可能性があります。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には、キープライブタイマー、デッドティマー、キープライブメッセージに基づくキープライブメカニズムが含まれています。
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セッションの各端は、KeepAliveタイマーを実行します。セッションでメッセージを送信するたびにタイマーを再起動します。タイマーの有効期限が切れると、キープライブメッセージが送信されます。他のトラフィックはキープライブとして機能する場合があります（セクション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.
これは、キープライブメッセージが反応しておらず、一部のプロトコルで使用されている双方向のキープライブハンドシェイクの一部を形成しないことを意味することに注意してください。また、このメカニズムは、セッションのキープライブトラフィックの量を最小限に抑えるように設計されていることに注意してください。
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.
KeepAliveタイマーの最小値は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の推奨デフォルトは、リモートピアが使用するKeepAliveタイマーの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が1つ以上のPCESでPCEPセッションを正常に確立すると、パスのセットの計算を必要とするイベントがトリガーされた場合、PCCは最初に1つ以上のPCEを選択します。PCEPセッションの確立の前にPCE選択決定プロセスが行われた可能性があることに注意してください。
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を選択すると、PCHE（PCREQメッセージ）にパス計算要求を送信します。これには、計算するパスの制約と属性のセットを指定するさまざまなオブジェクトが含まれます。たとえば、「ソースIPアドレスでTE LSPパスを計算します= x.y.z.t、宛先IPアドレス= x'.y'.z'.t '、bandwidth = b mbit/s、setup/holding priority = p、...」。さらに、PCCは、リクエストの優先順位を割り当てることにより、そのような要求の緊急性を指定することを望んでいる場合があります。各リクエストは、リクエストID番号とPCC-PCEアドレスペアで一意に識別されます。このプロセスは、図2の概略形式で示されています。
Note that multiple path computation requests may be outstanding from a PCC to a PCE at any time.
複数のパス計算リクエストは、いつでもPCCからPCEまで発行される可能性があることに注意してください。
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つまたは複数のPCCSに、リクエストの一部（通知にリストされている）が満たされないか、容認できない遅延が発生する可能性があることを通知したい場合があります。そのような通知を受信すると、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：PCCに送信された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).
PCEPエラーメッセージ（PCERRメッセージとも呼ばれる）は、いくつかの状況で送信されます。プロトコルエラー条件が満たされている場合、またはリクエストが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からPCCに送信されたエラーメッセージの例
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).
実装は、無制限の時間の間、PCEPセッション（したがって対応するTCP接続）を維持することを決定する場合があります。（たとえば、これは、パス計算リクエストが必要になるたびに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は境界のある許容パスコストを指定できます。メトリックオブジェクトはオプションですが、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メッセージタイプについて、メッセージが伝えることができるオブジェクトのセットを指定するルールが定義されています。そのようなルールを指定するには、Backus-Naurフォーム（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.
Ver（バージョン-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
値意味1オープン2キープライブ3パス計算要求4パス計算応答5通知6エラー7閉じる
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.
Openメッセージは、PCCからPCCに送信され、PCEPセッションを確立するためにPCCからPCCに送信されるPCEPメッセージです。Openメッセージの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接続が正常に確立されたら、PCCからPCCに送信された最初のメッセージまたはPCCにPCCから送信されたメッセージは、付録Aで指定されているように開かれたメッセージでなければなりません。
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.
オープンメッセージの前に受信したメッセージは、プロトコルエラー条件をトリガーする必要があります。PCERRメッセージをエラータイプの「PCEPセッションの確立障害」およびエラーと価値の「無効なオープンメッセージまたは非開いたメッセージの受信」と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つの開いたオブジェクトが含まれている必要があります（セクション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).
オープンオブジェクト内でさまざまなセッション特性が指定されています。TCP接続が正常に確立されたら、送信者は有効期限が切れた後、OpenWaitと呼ばれる初期化タイマーを開始する必要があります。開いたメッセージが受信されていない場合、PCERRメッセージを送信してTCP接続をリリースします（詳細については付録Aを参照）。
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ピアに送信されたら、送信者は、セッション特性の意見の相違の場合、KeepAliveメッセージが受信されていない場合、PCERRのPCERR、PCERRメッセージを受け取った後、keepwaitと呼ばれる初期化タイマーを開始する必要があります。メッセージを送信する必要があり、TCP接続をリリースする必要があります（詳細については、付録Aを参照してください）。
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セッションの特性が許容できるかどうかを判断する必要があります。少なくとも1つの特性が受信ピアに受け入れられない場合、エラーメッセージを送信する必要があります。エラーメッセージには、関連するオープンオブジェクトも含まれている必要があり、容認できないセッションパラメーターごとに、当初提案された値の代わりにオープンオブジェクトの適切なフィールドで許容可能なパラメーター値を提案する必要があります。PCEPピアは、異なるセッション特性を持つオープンメッセージを再送信することを決定する場合があります。同じパラメーターのセットまたはまだ受け入れられないパラメーターで2番目の開いたメッセージが受信された場合、受信ピアはエラーメッセージを送信する必要があり、すぐに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ピアは、承認として機能するKeepAliveメッセージ（セクション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.
Keepaliveメッセージは、セッションをアクティブ状態に保つために、PCCまたはPCEから送信されたPCEPメッセージです。KeepAliveメッセージは、開かれたメッセージが受信され、PCEPセッションの特性が受け入れられることを認めるために、開かれたメッセージに応じて使用されます。KeepAliveメッセージの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ピアがKeepAliveメッセージを送信する周波数の決定が必要です。非対称値が選択される場合があります。したがって、両方のPCEPピアによる同一のキープライブ周波数の使用を義務付ける制約はありません。Deadtimerは、PCEPピアがPCEPメッセージを受信していない場合、PCEPピアがセッションを宣言する期間として定義されます（KeepAliveまたはその他のPCEPメッセージ）。したがって、PCEPメッセージはキープライブメッセージとして機能します。同様に、両方のPCEPピアによる同一のデッドティマーの使用を義務付ける制約はありません。最小キープライブタイマー値は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.
KeepAliveメッセージは、セクション7.3で指定されたルールに従って、開いたメッセージ内で運ばれる開いたオブジェクトで指定された頻度で送信されます。PCEPメッセージはKeepaliveとして機能する可能性があるため、実装は、最後の送信されたKeepAliveメッセージ以降に他のPCEPメッセージが送信された可能性があるかどうかに関係なく、固定間隔でKeepAliveメッセージを送信することを決定するか、次のKeepAliveメッセージの送信を異なることを決定する場合があります。最後のPCEPメッセージ（Keepalive以外）が送信された時間に基づいています。
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セッションが確立されたらKeepaliveメッセージを送信しないことを決定する場合があります。その場合、Keepaliveメッセージを受け取らないピアは、それらを受信することを期待せず、セッションを非アクティブであると宣言してはなりません。
The format of a Keepalive message is as follows:
KeepAliveメッセージの形式は次のとおりです。
<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メッセージとも呼ばれる）は、PCCからPCEに送信された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.
PCREQメッセージに含める必要がある2つの必須オブジェクトがあります：RPとエンドポイントオブジェクト（セクション7を参照）。これらのオブジェクトの1つまたは両方が欠落している場合、受信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で定義されています。2つの帯域幅オブジェクトの特殊なケースについては、セクション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.
PCEPパス計算応答メッセージ（PCREPメッセージとも呼ばれます）は、以前に受信したPCREQメッセージに応じてPCCからPCCに送信された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メッセージには、ロードバランスを備えた単一のパス計算要求（セクション7.16を参照）に対応する計算パスのセット、またはPCCの要求によって発信される複数のパス計算要求のいずれかを含めることができます。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メッセージには、少なくとも1つのRPオブジェクトを含める必要があります。単一のPCREQメッセージにバンドルされた各返信について、対応するPCREQメッセージに掲載されたRPオブジェクトで指定されたものと同一のリクエスト-ID-Numberを含むRPオブジェクトを含める必要があります（セクション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.
パス計算要求を満たすことができる場合（つまり、PCEは、制約のセットを満たす一連のパスを見つけます）、明示的なルートオブジェクト（ERO）によって指定された計算パスのセットがPCREPメッセージに挿入されます。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オブジェクト（セクション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.
PCEP通知メッセージ（PCNTFメッセージとも呼ばれます）は、PCCにPCCに、またはPCCが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つの通知オブジェクトを携帯する必要があり、PCCまたはPCCが複数のイベントに通知する予定の場合、いくつかの通知オブジェクトを含めることができます。通知オブジェクトは、セクション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エラーメッセージ（PCERRメッセージとも呼ばれます）は、いくつかの状況で送信されます。プロトコルエラー条件が満たされている場合、またはリクエストがPCEP仕様に準拠していない場合（例：不正なメッセージの受信、メッセージの受信、必須の欠落オブジェクト、ポリシー違反、予期しないメッセージ、不明なリクエストリファレンス）。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オブジェクトのセットを含める必要があります。後者の場合（未承諾）、PCERRメッセージにRPオブジェクトは挿入されていません。たとえば、初期化フェーズ中にエラー条件が発生した場合、RPオブジェクトはPCERRに挿入されません。PCERRメッセージには、PCEPエラー条件を指定するPCEPエラーオブジェクトを含める必要があります。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.
Closeメッセージは、PCCがPCCにPCEに送信されるか、PCCがPCCにPCCに送信されるPCEPメッセージです。Closeメッセージの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つの近接オブジェクトを含める必要があります（セクション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実装では、エラーValue = 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が1分あたり最大既知のメッセージの不明なメッセージ要求よりも等しいか大きいレートで認識されていないメッセージを受信する場合、PCC/PCEは近くの値でPCEPクローズメッセージを送信する必要があります= "許容できない数の不明なPCEPメッセージの受信「。Max-Unnound-Messagesの推奨値は5です。PCC/PCEはTCPセッションを閉じる必要があり、PCEPセッションでさらにPCEPメッセージを送信してはなりません。
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).
長さフィールドは、バイト内の値部分の長さを定義します。TLVは、4バイトのアライメントにパッドで埋められています。パディングは長さフィールドに含まれていません（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（Object -Type -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ビット）：予約済みフィールド。このフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
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はPCREQメッセージでPCEに送信されたPCREQメッセージで、PATH計算中にPCEがPCEによって考慮する必要があるかどうかを指定できます。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のPCCがPCCにPCCに処理されたかどうかを示すために使用されます。PCEには、その返信に無視されたオプションオブジェクトを含めることができ、Iフラグを設定して、パス計算中にオプションのオブジェクトが無視されたことを示します。Iフラグがクリアされると、PCEは、パス計算中にオプションのオブジェクトが処理されたことを示します。オプションのオブジェクトのIフラグの設定は、純粋に指標であり、オプションです。Iフラグは、対応するPCREQメッセージにPフラグが設定されている場合、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はerror-type = "不明オブジェクト"または "を使用して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.
開いたオブジェクトは、各オープンメッセージに存在する必要があり、PCERRメッセージに存在する場合があります。Openまたは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バージョン、KeepAlive頻度、DeadTimer、およびPCEPセッションIDを指定するために使用される一連のフィールドが含まれています。オープンオブジェクトには、詳細なPCE機能、ポリシールールなどのさまざまなセッション特性を伝えるために使用されるTLVのセットも含まれている場合があります。現在、TLVは定義されていません。
OPEN Object-Class is 1.
Open Object-Classは1です。
OPEN Object-Type is 1.
Open Object-Typeは1です。
The format of the OPEN 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Flags | Keepalive | DeadTimer | SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: OPEN Object Format
図9：オブジェクト形式を開く
Ver (3 bits): PCEP version. Current version is 1.
Ver（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.
KeepAlive（8ビット）：このメッセージの送信者によって送信された2つの連続したPCEPメッセージの間の最大期間（秒単位）。KeepAliveの最小値は1秒です。セッションが確立されると、0に設定すると、リモートピアにそれ以上のキープライブメッセージが送信されません。KeepAlive周波数の推奨値は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メッセージの送信者とセッションを宣言して、PCEPメッセージが受信されていない場合は、Openメッセージの送信者とのセッションを宣言できるようにします。deadtimerは0に設定する必要があり、Keepaliveが0に設定されている場合は無視する必要があります。Deadtimerの推奨値は、KeepAliveの値の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は、KeepAlive = 10秒、DeadTimer = 40秒でBに開いたメッセージを送信します。これは、Aが10秒ごとにKepealiveメッセージ（またはその他のPCEPメッセージ）をBに送信し、Bが40秒以内にPCEPメッセージが受信されていない場合、PCEPセッションをダウンでAで宣言できることを意味します。
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.
o PRI（優先度-3ビット）：優先フィールドは、PCCに1から7までのPCEを指定するためにPCCを要求することで使用できます。未使用の場合は0に設定する必要があります。さらに、PCEのスケジューラによるパス計算要求の優先順位の使用は、実装固有であり、このドキュメントの範囲外です。PCEが優先度フィールドをサポートする必要はないことに注意してください。この場合、PCCはRPオブジェクトの優先フィールドを0に設定することをお勧めします。PCEがリクエストの優先順位を考慮していない場合、対応するPCREQメッセージ内にあるRPオブジェクトに含まれる優先順位値に関係なく、対応するPCREPメッセージ内にあるRPオブジェクトの優先フィールドを0に設定することをお勧めします。優先度フィールドの数値が高いと、優先度が高いことが反映されます。さまざまなPCCで一貫した方法で優先度の値を利用することは、ネットワーク管理者の責任であることに注意してください。リクエストの優先順位付けをサポートするPCEの能力は、PCE機能の発見によってPCCによって動的に発見される場合があります。PCCによって宣伝されていない場合、PCCはリクエストの優先順位を設定することを決定し、PCREPメッセージで受信したRPオブジェクトの優先フィールドを観察することにより、リクエストの優先順位付けをサポートするPCEの能力を学習します。PRIフィールドの値が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は、既存のTE LSPの再最適化に関連するPCREQメッセージが関連することを指定します。ゼロバンド幅LSPを除くすべてのTE LSPについて、Rビットが設定されている場合、RRO（セクション7.10を参照）をPCREQメッセージに含めて、既存のTE LSPのパスを表示する必要があります。また、ゼロ帯域幅LSPを除くすべてのTE LSPについて、Rビットが設定されている場合、再現するTE LSPの既存の帯域幅は帯域幅オブジェクトに供給する必要があります（セクション7.7を参照）。この帯域幅オブジェクトは、再オプチミー化されたLSPの望ましい帯域幅を記述するために使用されるそのオブジェクトのインスタンスに追加されます。ゼロ帯域幅LSPの場合、既存のTE LSPの特性を報告するRROおよび帯域幅オブジェクトはオプションです。
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（Strict/Loose -1ビット）：PCREQメッセージで設定すると、これはルーズパスが許容できることを示します。それ以外の場合、クリアされた場合、これはPCEに、厳格なホップでのみ作られたパスが必要であることを示します。PCREPメッセージでは、O BITが設定されている場合、これは返されたパスがゆるいパスであることを示します。それ以外の場合は（O BITがクリアされている場合）、返されたパスは厳格なホップでできています。
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.
Request-ID-Number（32ビット）：PCCおよびPCEアドレスのソースIPアドレスと組み合わせたリクエスト-ID-Number値は、パス計算要求コンテキストを一意に識別します。リクエストID-Numberは、保留中のリクエスト間の曖昧性を除去するために使用されるため、新しいリクエストが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-Numberを使用する必要があります。PCCから同じリクエストID-Numberのパス計算要求を受信すると、PCEはリクエストを新しいリクエストとして扱う必要があります。実装は、パス計算要求を2回処理することなく再送信をすばやく処理するために、パス計算応答をキャッシュすることを選択できます（最初の要求がドロップまたは紛失した場合）。同じリクエストID-NumberでPCEからパス計算応答を受信すると、PCCはパス計算応答を静かに破棄する必要があります。
Conversely, different Request-ID-numbers MUST be used for different requests sent to a PCE.
逆に、PCEに送信されたさまざまなリクエストには、異なるリクエストID番号を使用する必要があります。
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-Numberは、異なるPCESに送信されたパス計算要求に使用できます。PATH計算応答は、応答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".
RPオブジェクトが含まれていないPCREQメッセージが受信された場合、PCEはERROR-Type = "必要なオブジェクトの欠落"およびError-Value = "RPオブジェクトの欠落"を使用してPCERRメッセージを要求PCCに送信する必要があります。
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は、TE LSPが非ゼロバンド幅TE LSPである場合にのみ、二重帯域幅カウントを回避/制限するために、PCREQメッセージにRROオブジェクトを含めることにより、厳格/ルーズパスを提供する必要があります。PCCが厳密なパス（Oビットセット）を要求していない場合、PCCは再最適化を要求できますが、これにはPCEがステートフルである必要があります（以前に計算されたパスを、関連する厳格なホップのリストで追跡します）、または、必要な完全なパスセグメントを取得する機能を持っています。あるいは、PCCは、PCREQの厳密なホップの作業パスと関連するリストについてPCEに通知する必要があります。ゼロ帯域幅te lspのpcreqメッセージにrroが存在しないため（RPオブジェクトのrビットが設定されている場合）、error-type = "必要なオブジェクトの欠落"およびエラーを使用してpcerrメッセージの送信をトリガーする必要があります。-value = "再オプチミー化のために欠落している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-Numberを参照するRPオブジェクトを含むPCREP/PCREQメッセージを受信した場合、PCC/PCEはERROR-Type = "不明要求リファレンス"を使用してPCERRメッセージを送信する必要があります。これは、デバッグ目的に使用されます。PCC/PCEが1分あたりの最大既知の要求よりも等しいまたは大きいレートで不明な要求を持つPCREP/PCREQメッセージを受信した場合、PCC/PCEは、近くの値でPCEPクローズメッセージを送信する必要があります= "受容不可能な数の受信不明なリクエスト/返信の」。Max-Unknown-Requestsの推奨値は5です。PCC/PCEはTCPセッションを閉じる必要があり、PCEPセッションでさらにPCEPメッセージを送信してはなりません。
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.
Request-ID-Number = 0x00000000を参照する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メッセージにパスなしオブジェクトを含める必要があります。
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が関与した場合）、設定の制約に従うパスが見つからない場合があります。No-Pathオブジェクトの「Ni（Issue of Issueの性質）」フィールドは、エラーカテゴリを報告するために使用されます。
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.
ノーパスオブジェクトクラスは3です。
NO-PATH Object-Type is 1.
No-Path Object-Typeは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：パスなしオブジェクト形式
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は、以下に定義されているパスベクトルなし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 Mbit/sのTe LSPのPCEにパス計算要求を送信するPCCの場合を検討してください。PCEがx Mbit/sのパスを見つけることができないと仮定します。この場合、PCEはPCREPメッセージにパスなしオブジェクトを含める必要があります。オプションでは、PCEには、失敗した計算の理由が帯域幅の制約であることを示すために、元の帯域幅オブジェクトも含めることができます（この場合、Niフィールド値は0x00、Cフラグが設定されています）。PCEがそのような機能をサポートしている場合、帯域幅オブジェクトを含めて、帯域幅オブジェクトの帯域幅フィールド（この場合はCフラグが設定されています）にyの値を報告することができます。同じ他の特性（セットアップ/保持優先順位、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-VECTOR TLVは、セクション7.1で定義されているPCEP TLV形式に準拠しており、タイプの2バイト、2バイト（バイト内の値部分の長さ）を指定する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は、No-Path-Vector TLVで運ばれるフラグのスペースを管理しています（セクション9を参照）。
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.
エンドポイントオブジェクトは、PCREQメッセージで使用され、ソースIPアドレスとパス計算が要求されるパスの宛先IPアドレスを指定します。エンドポイントオブジェクトの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アドレスまたはパスセグメントのアドレスに対応する場合があることに注意してください。2つのエンドポイントオブジェクト（IPv4およびIPv6用）が定義されています。
END-POINTS Object-Class is 4.
エンドポイントオブジェクトクラスは4です。
END-POINTS Object-Type is 1 for IPv4 and 2 for IPv6.
エンドポイントオブジェクトタイプは、IPv4の場合は1、IPv6の場合は2です。
The format of the END-POINTS object body for IPv4 (Object-Type=1) is as follows:
IPv4（Object-Type = 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（Object-Type = 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.
TE LSPの再最適化の場合、2つの値が異なる場合にのみ、要求された帯域幅に加えて、既存のTE LSPの帯域幅も含める必要があります。したがって、要求された帯域幅と、再最適化が実行されているTE LSPの帯域幅を参照する2つのオブジェクトタイプの値が定義されています。
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.
o 再最適化が要求される既存のTE LSPの帯域幅。帯域幅オブジェクトタイプは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フローティングポイント形式（[IEEE.754.1985]を参照）で32ビットでエンコードされ、1秒あたりのバイトで表されます。一般的に使用される値の表については、[RFC3471]のセクション3.1.2を参照してください。
The BANDWIDTH object body has a fixed length of 4 bytes.
帯域幅オブジェクト本体の固定長は4バイトです。
The METRIC object is optional and can be used for several purposes.
メトリックオブジェクトはオプションであり、いくつかの目的に使用できます。
In a PCReq message, a PCC MAY insert one or more METRIC objects:
PCREQメッセージでは、PCCが1つ以上のメトリックオブジェクトを挿入する場合があります。
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.
o パス計算アルゴリズム（IGPメトリック、TEメトリック、ホップカウント）によって最適化する必要があるメトリックを示すため。現在、3つのメトリックが定義されています：IGPコスト、TEメトリック（[RFC3785]を参照）、およびTE LSPによって横断されるホップ数。
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.
o PCCが受け入れられると見なされるためにパスを超えてはならないパスコストのバウンドを示すため。
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.
メトリックオブジェクトの欠如は、PCEによって、メトリックのいずれにも制約を適用する必要がないパス計算要求として解釈する必要があります。
METRIC Object-Class is 6.
メトリックオブジェクトクラスは6です。
METRIC Object-Type is 1.
メトリックオブジェクトタイプは1です。
The format of the METRIC 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 |C|B| T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metric-value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: METRIC Object Body Format
図15：メトリックオブジェクトボディ形式
The METRIC object body has a fixed length of 8 bytes.
メトリックオブジェクト本体の固定長は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
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.
特定の要求に対して（つまり、特定のRPに対して）、複数のメトリックオブジェクトをPCREPまたはPCREQメッセージに挿入できます。特定の要求に対して、同じBフラグ値を持つ各メトリックタイプのメトリックオブジェクトのせいぜい1つのインスタンスが必要です。特定の要求に対して、同じbフラグ値を持つメトリックオブジェクトの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つのメトリックオブジェクトを挿入することも許可されています。この場合、Multi-Parameterの最適化問題を解決するために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.
PCREPメッセージでは、PCEポリシーで許可されていない限り、メトリックオブジェクトのCフラグが対応するパス計算要求に設定されている場合、計算されたパスメトリックを報告する少なくとも1つのメトリックオブジェクトが存在する必要があります（Bフラグをクリアする必要があります）。Cフラグには、PCREPメッセージには意味がありません。オプションで、PCREPメッセージには、バインドされた制約に対応する追加のメトリックオブジェクトが含まれる場合があります。その場合、メートルコ値は、対応する計算パスメトリックに等しくなければなりません（Bフラグを設定する必要があります）。PCEによって制約を満たすパスがない場合、メトリックオブジェクトは、満たすことができる制約メトリックを示すために、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メトリックがMの値を超えてはならないPCEにパス計算要求を送信した場合、PCREQメッセージに2つのメトリックオブジェクトが挿入されます。
o First METRIC object with B=0, T=1, C=1, metric-value=0x0000
o b = 0、t = 1、c = 1、metric-value = 0x0000の最初のメトリックオブジェクト
o Second METRIC object with B=1, T=2, metric-value=M
o b = 1、t = 2、metric-value = mの2番目のメトリックオブジェクト
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、metric-value =計算Igpパスで1つのメトリックオブジェクトを挿入します料金。さらに、PCEは、b = 1、t = 2、metric-value =計算されたteパスコストで2番目のメトリックオブジェクトを挿入する場合があります。
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は、PATH計算が成功した場合に計算された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.
このオブジェクトの内容は、[RFC3209]、[RFC3473]、および[RFC3477]で定義されたリソース予約プロトコルトラフィックエンジニアリング拡張機能（RSVP-TE）明示的ルートオブジェクト（ERO）の内容にエンコードする際に同一です。つまり、オブジェクトは一連のサブオブジェクトから構成されています。既に定義されているRSVP-TE EROサブオブジェクトまたはRSVP-TE EROで使用するために将来定義される可能性のあるものは、このオブジェクトで受け入れられます。
PCEP ERO sub-object types correspond to RSVP-TE ERO sub-object types.
PCEP EROサブオブジェクトタイプは、RSVP-TE EROサブオブジェクトタイプに対応しています。
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.
RROは、Routeを報告するためにPCREQメッセージ内にのみ搭載されています。その後、再最適化が必要なTE LSPが続きます。
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- 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.
このオブジェクトの内容は、[RFC3209]、[RFC3473]、および[RFC3477]で定義されたルートレコードオブジェクトの内容とエンコードする際に同一です。つまり、オブジェクトは一連のサブオブジェクトから構成されています。既に定義されているRSVP-TERROサブオブジェクトまたはRSVP-TERROで使用するために将来定義できるものは、このオブジェクトで受け入れられます。
The meanings of all of the sub-objects and fields in this object are identical to those defined for the RSVP-TE RRO.
このオブジェクトのすべてのサブオブジェクトとフィールドの意味は、RSVP-TERROで定義されたものと同じです。
PCEP RRO sub-object types correspond to RSVP-TE RRO sub-object types.
PCEP RROサブオブジェクトタイプは、RSVP-TERROサブオブジェクトタイプに対応しています。
RRO Object-Class is 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属性）オブジェクトはオプションであり、PATH計算中にPCEによって考慮されるさまざまなTE LSP属性を指定します。LSPAオブジェクトは、パス計算が失敗した場合のPCREQメッセージ、またはPCREPメッセージ内で携帯できます（この場合、PCREPメッセージにはパスなしオブジェクトも含まれ、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.
セットアップPRIO（セットアップ優先度-8ビット）：0〜7の範囲で、リソースの取得に関するTE LSPの優先度は、値0が最優先事項です。セットアップの優先順位は、このセッションが別のセッションを先取りできるかどうかを決定する際に使用されます。
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.
PRIOを保持する（優先度 - 8ビット）：0〜7の範囲で、リソースを保持することに関してTE LSPの優先度。値0が最優先事項です。保持優先度は、このセッションを別のセッションで先取りできるかどうかを決定する際に使用されます。
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].
[RFC5420]で定義されているものなどの追加のTE LSP属性を運ぶために、オプションのTLVが将来定義される可能性があることに注意してください。
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（include routeオブジェクト）はオプションであり、計算されたパスが指定されたネットワーク要素のセットを通過する必要があることを指定するために使用できます。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]で定義されているものと同一のサブオブジェクトでできています。ドキュメント。
The following sub-object types are supported.
次のサブオブジェクトタイプがサポートされています。
Type Sub-object 1 IPv4 prefix 2 IPv6 prefix 4 Unnumbered Interface ID 32 Autonomous system number
タイプSub-Object 1 IPv4プレフィックス2 IPv6プレフィックス4アンサム付きインターフェイスID 32自律システム番号
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がPCHにPATH計算リクエストをPCEに送信する必要がある一連のN TE LSPのケースを考えてください。最初のソリューションは、選択したPCEにN個の個別のPCREQメッセージを送信することで構成されています。この場合、パス計算リクエストは同期されていません。PCCは、負荷分散の目的でK PCES全体でN要求のセットを配布することを選択する場合があることに注意してください。上記のように、m（m <n）リクエストが特定のPCEIに送信されることを考慮すると、そのようなMリクエストは、PCEIを運営する連続したPCREQメッセージの形で送信できます。単一のPCREQメッセージ内の複数のパス計算要求のバンドル）。とはいえ、独立した要求の場合でも、PCEがより最適なパス計算やブロッキング確率の低下につながる可能性が高い同期された方法で、PCEからパスの計算を要求することが望ましい場合があります。ステートレスPCE。言い換えれば、PCEは、シリアル化された独立した方法で対応するパスを計算すべきではありませんが、パスを「同時に」計算する必要があります。たとえば、M TE LSPのパスを「同時に」計算しようとすると、PCEが複数の制約を満たす可能性を改善できるようになります。
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 MBIT/SとN2 MBIT/Sを要求する2つのTE LSPの場合、およびX MSの各TE LSPの最大許容エンドツーエンド遅延を考慮してください。2番目のTE LSPの逆に、最初の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.
2番目の例は、帯域幅の制約に関連しています。シリアル化された独立したパス計算アプローチが両方のリクエストを満たすことが不可能になる（帯域幅の断片化のため）、同期されたパス計算が両方のリクエストを正常に満たすことを実現する例を提供することは非常に簡単です。
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 Diberse Pathsの計算の場合、そのようなパスが非同期に計算されている場合、これによりすべての要求を満たすことができない確率が大幅に増加します（よく知られているものとも呼ばれることもあります」トラップの問題」）。
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-Numberによって一意に識別されます。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 Diberse）BIT：設定すると、これは、次の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 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".
SVECオブジェクトにより、PCCは潜在的な依存関係とともに同期する必要があるMパス計算要求のリストを指定できます。M PATH計算要求のセットは、単一のPCREQメッセージまたは複数のPCREQメッセージ内で送信される場合があります。後者の場合、PCEは、有効期限後にSVECオブジェクトを含む最初のPCREQメッセージの受信時にアクティブ化されたローカルタイマー（Synctimerと呼ばれる）を実装することをお勧めします。受信され、プロトコルエラーがトリガーされます。PCEが満たさないパス計算要求を受信すると（たとえば、PCREQメッセージにはサポートされていないPビットセットがあるオブジェクトが含まれているため）、PCEはこのリクエストのPCERRメッセージを送信します（セクション7.2を参照）、PCEは、関連するパス計算リクエストのセット全体をキャンセルする必要があり、error-type = "同期パス計算リクエストの欠落"を使用して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に関連する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.
通知オブジェクトは、PCNTFメッセージ内でのみ運ばれ、PCCからPCCに送信されたメッセージで、またはPCCにPCCに送信されてイベントを通知するために使用できます。
NOTIFICATION Object-Class is 12.
通知オブジェクトクラスは12です。
NOTIFICATION Object-Type is 1.
通知オブジェクトタイプは1です。
The format of the NOTIFICATION body object 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 | 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.
* 通知Value = 1：PCCは、保留中のリクエストのセットをキャンセルします。通知タイプ= 1、通知値= 1は、PCCがPCEに保留中のリクエストのセットのキャンセルを通知したいことを示しています。このようなイベントは、別のPCEからの肯定的な応答の受領などの外部条件のためにトリガーされる可能性があります（PCCが同じパス計算要求のために複数のリクエストをPCESに送信した場合）、ネットワーク障害などのネットワークイベントなどリクエストを時代遅れ、またはPCCの地元のイベントをレンダリングします。通知タイプ= 1の通知オブジェクト、通知値= 1は、PCCからPCCに送信されたPCNTFメッセージ内でPCNTFメッセージ内に配置されます。キャンセルされた要求に対応するRPオブジェクトも、PCNTFメッセージに存在する必要があります。複数のRPオブジェクトは、PCNTFメッセージ内で運ばれる場合があります。その場合、通知はそれらすべてに適用されます。そのような通知がPCCから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.
* 通知Value = 2：PCEは、保留中のリクエストのセットをキャンセルします。通知タイプ= 1、通知値= 2は、PCCが保留中のリクエストのセットのキャンセルをPCCに通知したいことを示しています。通知タイプ= 1の通知オブジェクトは、PCCからPCCに送信された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-
* Notification-Value = 1：A Notification-Type = 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は、PCCが現在過負荷状態にあることをPCCに示します。RPオブジェクトがPCNTFメッセージに含まれていない場合、これは、過負荷状態がクリアされるまで他のリクエストをそのPCEに送信する必要がないことを示しています。保留中の要求が影響を受けず、提供されます。過負荷状態のために保留中のリクエストを提供できない場合、PCEには、PCEによってキャンセルされ、表彰されない保留中のリクエストのセットを識別するRPオブジェクトのセットも含める必要があります。この場合、PCEは、キャンセルされたリクエストのリストは、対応するRPオブジェクトのセットを含めることによって指定されるため、通知-Type = 1およびNotification-Value = 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、メモリなど）に関して混雑状態にあるかどうかを判断するために使用されるデュアルスレッショナルメカニズムを使用する必要があります。このようなしきい値の使用は、PCCSによる要求ターゲットの振動をもたらす可能性のある過負荷/非オーバーロード状態間の振動を回避するためです。
* 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.
* Notification-Value = 2：通知-Type = 2、通知値= 2は、PCEが過負荷状態ではなくなり、新しいパス計算要求を処理できることを示します。実装では、PCEがそのような通知をすべてのPCCに送信する必要があります。このPCCは、通知メッセージ（通知-Type = 2、通知-Value = 1）が送信されています。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にリダイレクトできることを覚えておく必要があります。これにより、ネットワーク内のPCESでさらに過負荷が発生する可能性があります。したがって、過負荷通知を受信するPCCでのアプリケーションは、ネットワークへのパス計算要求を生成するレートに何らかの形のバックオフ（例えば、指数）を適用することを検討する必要があります。これは、過負荷を報告するPCESの数が増加するため、特にそうです。
The PCEP-ERROR object is exclusively carried within a PCErr message to notify of a PCEP error.
PCEP-ERRORオブジェクトは、PCERRメッセージ内でのみ運ばれ、PCEPエラーを通知します。
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エラーオブジェクトが含まれる場合があります。
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.
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でPCERRメッセージを送信する必要があります（詳細については、付録Aを参照）。
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.
1つ以上のPCEPセッションの特性が受信ピアによって受け入れられず、交渉不可能な場合は、Error-Type = 1、Error-Value = 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でPCERRメッセージを送信する必要があります（詳細についてはセクション6.2を参照）。
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セッションの確立フェーズ中に2番目のオープンメッセージが受信され、セッションの特性がまだ受け入れられない場合、受信PCEPピアはエラータイプ-1、エラー値= 5でPCERRメッセージを送信する必要があります（詳細についてはセクション6.2を参照）。
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.
許容できないセッション特性を提案する開いたメッセージを含むPCEPセッションの確立フェーズでPCERRメッセージが受信される場合、受信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.
PCEPセッションの確立フェーズ中にKeepAliveメッセージもPCERRメッセージもKeepwaitタイマーの有効期限がかかる前に受信されない場合、受信PCEPピアはエラータイプ= 1、エラー-Value = 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.
error-type = 3またはerror-type = 4：pcepオブジェクト（p flagセットを備えた）を持つpcepメッセージが受信された場合、pceによって認識されないか認識されていないがサポートされていない場合、pceはpcerrメッセージを送信する必要があります。PCEP-ERRORオブジェクト（それぞれERROR-Type = 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.
ERROR-Type = 5：PCCとPCEの間の合意されたポリシーに準拠していないパス計算要求を受信した場合、PCEはPCEP-Errorオブジェクトを使用してPCERRメッセージを送信する必要があります（Error-Type = 5）。対応するパス計算をキャンセルする必要があります。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.
ERROR-Type = 6：必須オブジェクトが含まれていないパス計算要求を受信した場合、PCEはPCEP-Errorオブジェクトを使用してPCERRメッセージを送信する必要があります（エラータイプ= 6）。欠落している複数の必須オブジェクトがある場合、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、セクション7.13.3で定義されたタイマーシンクリマーの有効期限の終了後に、対応するSVECオブジェクト内にリストされているすべての同期パス計算要求を受信しません。PCEは、PCEP-ERRORオブジェクトを使用してPCERRメッセージを送信する必要があります（Error-Type = 7）。対応する同期パス計算をキャンセルする必要があります。PCEが、欠落しているリクエストを識別するREQミッシングTLV（以下に定義）を含めることをお勧めします。
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バイト、2バイト（バイト内の値部分の長さ）を指定する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-Numberを示す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.
ERROR-Type = 8：PCCが不明なパス計算要求に関連するPCREPメッセージを受信した場合、PCCはPCEP-ERRORオブジェクトを使用してPCERRメッセージを送信する必要があります（ERROR-Type = 8）。さらに、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ピアからの試行を検出して2番目のPCEPセッションを確立する場合、Error-Type = 9、Error-Value = 1でPCERRメッセージを送信する必要があります。既存のPCEPセッションは保存する必要があり、2回目の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、エラー-Value = 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がPCEによって見つかりない状況がありますが、そのような帯域幅要件は、帯域幅の合計がXに等しくなるように、TE LSPのセットによって満たすことができます。したがって、それは有用かもしれません。PCCがTE LSPのセットを要求して、帯域幅の合計がX Mbit/sに等しく、TE LSPの数とこれらの各TE LSPの最小帯域幅に潜在的に制約があるようにするために。このようなリクエストは、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ビット）：現在、フラグは定義されていません。フラグフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
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.
MIN-BANDWIDTH（32ビット）：TE LSPのセットの各要素の最小帯域幅を指定します。帯域幅は、IEEEフローティングポイント形式で32ビットでエンコードされています（[IEEE.754.1985]を参照）、1秒あたりのバイトで表されます。
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は、帯域幅の合計がxになるようにTe LSPのセットの計算を要求し、Te LSPの最大数はn、各TE LSPには少なくともBの帯域幅が必要な場合、指定する帯域幅オブジェクトを挿入します。x必要な帯域幅として、およびそれぞれnとbに設定されたmax-lspおよびmin帯域幅フィールドを備えた負荷バランスオブジェクトとして。
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.
クローズオブジェクトは、各密接なメッセージに存在する必要があります。緊密なメッセージごとに1つのクローズオブジェクトしかない必要があります。複数のクローズオブジェクトを含む緊密なメッセージが受信された場合、最初のクローズオブジェクトは処理する必要があるものです。他の密接なオブジェクトは静かに無視する必要があります。
CLOSE Object-Class is 15.
クローズオブジェクトクラスは15です。
CLOSE Object-Type is 1.
Close Object-Typeは1です。
The format of the CLOSE 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 | Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: CLOSE Object Format
図22：オブジェクト形式を閉じます
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は、Reasonフィールドのコードスペースを管理します。現在、次の値が定義されています。
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は、クローズオブジェクト本体に含まれる場合があります。このようなTLVの仕様は、このドキュメントの範囲外です。
This section follows the guidance of [PCE-MANAGE].
このセクションは、[PCE-Manage]のガイダンスに従います。
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),
o 地元のKeepaliveとDeadtimer（すなわち、PCEPピアが開いたメッセージで送信したパラメーター）、
o The maximum acceptable remote Keepalive and DeadTimer (i.e., parameters received from a peer in an Open message),
o 最大の許容可能なリモートキープライブとデッドティマー（つまり、開いたメッセージでピアから受け取ったパラメーター）、
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 交渉が許可されている場合、PCEPピアから受け取った最低許容可能なKeepaliveおよびDeadtimerタイマー、
o The 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,
o Max-Unknown-Requests、
o The MAX-UNKNOWN-MESSAGES.
o Max-Connund-Messages。
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実装により、発見されたPCESの選択されたサブセットで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,
o PCEPスピーカーの役割：PCC、PCE、またはその両方
o Whether the PCEP speaker should initiate the PCEP session or wait for initiation by the peer,
o PCEPスピーカーがPCEPセッションを開始するか、ピアによる開始を待つかどうか、
o The PCEP session parameters, as listed above, if they differ from the default parameters,
o 上記のPCEPセッションパラメーターは、デフォルトのパラメーターと異なる場合、
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-MIB]で定義されています。これは、次のようなPCEP通信のモデリングのための管理されたオブジェクトを説明しています。
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 構成可能なタイマーの有効期限後、および制約のセットを満たす少なくとも1つのパスが存在することを確認することにより、返信がないリクエストの数。
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管理はTCP管理メカニズム（[RFC4022]で定義されているTCP MIBなど）を使用できます。
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
IANA created a registry for PCEP objects. Each PCEP object has an Object-Class and an Object-Type.
IANAは、PCEPオブジェクトのレジストリを作成しました。各PCEPオブジェクトには、オブジェクトクラスとオブジェクトタイプがあります。
Object-Class Value Name Reference
オブジェクトクラスの値名の参照
1 OPEN This document
Object-Type
1
2 RP This document
Object-Type
1
3 NO-PATH This document
Object-Type
1
4 END-POINTS This document
Object-Type
1: IPv4 addresses
2: IPv6 addresses
5 BANDWIDTH This document
Object-Type
1: Requested bandwidth
2: Bandwidth of an existing TE LSP
for which a reoptimization is performed.
6 METRIC This document
Object-Type
1
7 ERO This document
Object-Type
1
8 RRO This document
Object-Type
1
9 LSPA This document
Object-Type
1
10 IRO This document
Object-Type
1
11 SVEC This document
Object-Type
1
12 NOTIFICATION This document
Object-Type
1
13 PCEP-ERROR This document
Object-Type
1
14 LOAD-BALANCING This document
Object-Type
1
15 CLOSE This document
Object-Type
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コンセンサスアクションによってのみ割り当てられる場合があります。各ビットは、次の品質で追跡する必要があります。
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は、オープンオブジェクトのフラグフィールドを管理するレジストリを作成しました。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新しいビット番号は、IETFコンセンサスアクションによってのみ割り当てられる場合があります。各ビットは、次の品質で追跡する必要があります。
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.
現在、オープンオブジェクトフラグフィールド用のビットはありません。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新しいビット番号は、IETFコンセンサスアクションによってのみ割り当てられる場合があります。各ビットは、次の品質で追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit)
o ビット番号（最も重要なビットとしてビット0からカウント）
o Capability description o Defining RFC
o 機能説明o RFCを定義します
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
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
0セットを満足させるパスはありません
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新しいビット番号は、IETFコンセンサスアクションによってのみ割り当てられる場合があります。各ビットは、次の品質で追跡する必要があります。
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:
このドキュメントのNo-Pathオブジェクトフラグフィールドでは、1つのビットが定義されています。
Codespace of the Flag field (NO-PATH Object)
フラグフィールドのコードスペース（パスなしオブジェクト）
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フィールドのコーデススペースとメトリックオブジェクトのフラグフィールドを管理するレジストリを作成しました。
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コンセンサスアクションによってのみ割り当てられる場合があります。各ビットは、次の品質で追跡する必要があります。
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コンセンサスアクションによってのみ割り当てられる場合があります。各ビットは、次の品質で追跡する必要があります。
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: Codespace of the Flag field (LSPA Object)
このドキュメントのLSPAオブジェクトフラグフィールドには、1つのビットが定義されています。
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コンセンサスアクションによってのみ割り当てられる場合があります。各ビットは、次の品質で追跡する必要があります。
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:
このドキュメントのSVECオブジェクトフラグフィールドの3つのビットが定義されています。
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
21 srlg Diverseこのドキュメント22ノード多様なこのドキュメント23リンク多様なこのドキュメント
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
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コンセンサスアクションによってのみ割り当てられる場合があります。各ビットは、次の品質で追跡する必要があります。
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.
現在、通知オブジェクトのフラグフィールド用のビットはありません。
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.
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コンセンサスアクションによってのみ割り当てられる場合があります。各ビットは、次の品質で追跡する必要があります。
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コンセンサスアクションによってのみ割り当てられる場合があります。各ビットは、次の品質で追跡する必要があります。
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.
PCEPセッションを閉じるために、閉じるオブジェクトは、各閉鎖メッセージに存在する必要があります。Closeオブジェクトの理由は、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
IANA created a registry to manage the flag field of the CLOSE object.
IANAは、クローズオブジェクトのフラグフィールドを管理するレジストリを作成しました。
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
新しいビット番号は、IETFコンセンサスアクションによってのみ割り当てられる場合があります。各ビットは、次の品質で追跡する必要があります。
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.
現在、クローズオブジェクトのフラグフィールド用のビットはありません。
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
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コンセンサスアクションによってのみ割り当てられる場合があります。
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
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への攻撃は、アクティブネットワークに損傷を与える可能性があります。PATH計算応答が変更された場合、PCCは不適切なLSPをセットアップすることをお勧めします。このようなLSPは、ネットワークの一部がスヌーピングの影響を受けやすい場合、または混雑または予約されたリンクを通過する可能性があります。PATH計算応答は、PCREPメッセージの変更、PCEのなりすまし、またはPCREQの変更により、PCEが最初に要求されたものとは異なる計算を実行することにより攻撃される場合があります。
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の操作を損傷することもできます。このような攻撃により、PCCがゆっくりと供給されるとPCCSにとって価値があるため、PCEが混雑する可能性があります。これにより、容認できる回復時間が遅くなったり、LSPの施設が遅れたりする可能性があります。極端な場合、サービスリクエストが満たされていない可能性があります。
PCEP could be the target of the following attacks:
PCEPは、次の攻撃のターゲットになる可能性があります。
o Spoofing (PCC or PCE impersonation)
o スプーフィング（PCCまたはPCEのなりすまし）
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 Inter-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リクエストと応答のスヌーピングは、ネットワークの操作に関する攻撃者の情報を提供する場合があります。PCEPメッセージを表示するだけで、誰かがネットワーク内のサービス確立のパターンを決定し、トラフィックがルーティングされている場所を知ることができ、それによりネットワークがターゲットを絞った攻撃と特定のLSP内のデータを脆弱にしやすくします。
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セッションを保護するための唯一の利用可能なセキュリティメカニズムです。
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-MD5をサポートするPCEP実装は、TCP用に指定される可能性のあるより強力なセキュリティキーイングテクニックまたはアルゴリズムを将来のリリースに簡単に統合できるように設計する必要があります。
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]を使用することです。これは、盗聴、改ざん、メッセージの偽造に対する保護を提供します。ただし、TLSはTCP接続自体を保護しません。これは、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に関連する攻撃者が計算されたパスとリソースに関連する機密情報を取得できるため、同じ重要性が非常に重要です。
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]で説明されているように、Border Gateway Protocol（BGP）と同じように）。ネットワークに比較的少数のPCCとPCEがある場合、手動のキー構成はオペレーターによる有効な選択と見なされる場合がありますが、そのようなメカニズムによって導入される脆弱性（つまり、構成エラー、ソーシャルエンジニアリングによって導入される脆弱性に注意することが重要です、そして不注意はすべてセキュリティ侵害を引き起こす可能性があります）。さらに、手動で構成されたキーが定期的に更新される可能性が低く、セキュリティリスクも増加します。多数のPCCとPCESがある場合、オペレーターは、各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 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.
個々のキーに代わるものは、グループキーの使用です。グループキーは、信頼ドメインのすべてのメンバーの間で一般的な知識です。したがって、IGP領域のルーターまたは共通の信頼ドメイン[MPLS-SEC]の一部であるため、PCEPグループキーは、IGP領域またはASのすべてのPCCとPCEの間で共有される場合があります。グループキーを使用すると、ネットワークの外部からの攻撃に対して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.
グループキーを使用すると、Trustドメイン（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 Discovery（[RFC5088]および[RFC5089]）は、大規模なネットワークでのPCEPの展開を成功させるための重要な機能です。このメカニズムにより、PCCは構成を必要とせずにネットワーク内に適切なPCEの存在を発見できます。PCEが発見され、構成されていない場合、PCCが使用する正しいキーを知ることができないことは明らかです。この問題には、セキュリティの一部の側面を保持する3つのアプローチがあります。
o The PCCs may use a group key as previously discussed.
o PCCSは、前述のようにグループキーを使用する場合があります。
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 PCCSは、PCEと話すときに使用するキーを決定するためにキーサーバーを使用する場合があります。キーサーバーとのPCCの通信も安全である必要があるため、ある程度は問題を移動しています（たとえば、Kerberos [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では、TCP接続を閉じて再開せずにキーを変更しないことに注意してください。これにより、PCEPセッションが終了し、再起動する必要があります。それは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を参照）、侵入者にとって、単に偽の計算要求を挿入することにより、ネットワークおよび運用ネットワークポリシーに関する重要な情報を決定するメカニズムになります。さらに、実際の要求が行われたときにネットワーク内のトラフィックがどこに配置されるかを予測するために、誤った計算要求を使用して、攻撃者が特定のネットワークリソースをターゲットにすることができます。
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.
PCESは、アクセスポリシーのために設定可能である必要があります。認証が使用される場合、セクション10.5で説明されているように、キーの交換または構成を通じてアクセスポリシーを達成できます。正当なPCCのIPアドレスがリストされている場合、アクセスリストの形式でPCESでより簡単なポリシーを構成することができます。また、ポリシーは、異なる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.
PCEPは、TCPを超えるすべてのプロトコルの場合のように、たとえば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は、許可されていないPCCSから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を使用するには、受信者が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は非常に多数のPCREQメッセージを送信して、PCEが混雑したり、他のPCCからのリクエストをキューにしたりする可能性があります。
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オブジェクトの優先フィールドを直接使用しても保護は提供されないことに注意してください。
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の実装には、1つの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.
このようなメカニズムはデフォルトで設定される場合がありますが、構成に使用できるはずです。このような手法は、あるサービスプロバイダーのリソースを、別のサービスプロバイダーのPCESによる不当な、熱心な、または悪意のある使用から保護するために、マルチサービスプロバイダー環境で特に重要であると考えられる場合があります。
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.
著者は、Dave Oran、Dean Cheng、Jerry Ash、Igor Bryskin、Carol Iturrade、Siva Sivabalan、Rich Bradford、Richard Douville、Jon Parker、Martin German、Dennis Aristowに非常に貴重な入力に感謝します。著者はまた、非常に実り多い議論と有用な提案について、Fabien Verhaegheに感謝したいと思います。David McGrewとBrian Weisは、セキュリティ上の考慮事項セクションへの貴重な入力を提供しました。
Ross Callon, Magnus Westerlund, Lars Eggert, Pasi Eronen, Tim Polk, Chris Newman, and Russ Housley provided important input during IESG review.
ロスコロン、マグナスウェスターランド、ラースエガート、パシーエロネン、ティムポーク、クリスニューマン、およびラスハウリーは、IESGレビュー中に重要なインプットを提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「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] Berger、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] Pan、P.、Swallow、G。、およびA. Atlas、「LSPトンネルのRSVP-TEへの高速拡張式」、RFC 4090、2005年5月。
[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 Standard 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.
[層間] oki、E.、Roux、J.、Kumaki、K.、Farrel、A。、およびT. Takeda、「層間交通工学の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] Fang、L。およびM. Behringer、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、2008年11月、進行中の作業。
[PCE-MANAGE] Farrel, A., "Inclusion of Manageability Sections in PCE Working Group Drafts", Work in Progress, January 2009.
[PCE-Manage] Farrel、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.、Roux、J。、およびY. Ikejiri、「パス計算要素ベースのアーキテクチャ用の一連の監視ツール」、2008年11月の作業。
[PCEP-MIB] Stephan, E. and K. Koushik, "PCE communication protocol (PCEP) Management Information Base", Work in Progress, November 2008.
[PCEP-MIB] Stephan、E。およびK. Koushik、「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] Farrel、A。、「さまざまなプロトコル仕様で使用される構文（RBNF）の縮小バックナウル形式（RBNF）、2008年11月、進行中の作業。
[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] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562] Leech、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] Le Faucheur、F.、Uppili、R.、Vedrenne、A.、Merckx、P。、およびT. Telkamp、「インテリアゲートウェイプロトコル（IGP）メトリックの使用としての2番目のMPLSトラフィックエンジニアリング（TE）メトリック」、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] Rescorla、E。and 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] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network認証サービス（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. Zinin、「TCP MD5署名オプション（RFC 2385）およびBGP-4仕様に関する標準成熟度の差異」、RFC 4278、2006年1月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（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] Farrel、A.、ed。、ed。、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] Farrel、A.、Vasseur、J。、およびJ. Ash、「パス計算要素（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] Ash、J。およびJ. Le Roux、「パス計算要素（PCE）通信プロトコルジェネリック要件」、RFC 4657、2006年9月。
[RFC4674] Le Roux, J., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
[RFC4674] Le Roux、J。、「パス計算要素（PCE）発見の要件」、RFC 4674、2006年10月。
[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] Le Roux、J。、「パス計算要素通信プロトコル（PCECP）エリア間MPLSおよびGMPLSトラフィックエンジニアリングの特定の要件」、RFC 4927、2007年6月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Minei、I。、およびB. Thomas、「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] Le Roux、Jl。、Vasseur、JP。、Ikejiri、Y.、およびR. Zhang、「Path Computation Element（PCE）DiscoveryのOSPFプロトコル拡張」、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] Le Roux、Jl。、Vasseur、JP。、Ikejiri、Y。、およびR. Zhang、「IS-IS Path Computation Element（PCE）DiscoveryのISプロトコル拡張」、RFC 5089、2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン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] Bitar、N.、Zhang、R。、およびK. Kumaki、「Path Computation Element Communication Protocol（PCECP）の要件」、RFC 5376、2008年11月。
[TCP-AUTH] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", Work in Progress, November 2008.
[TCP-Auth] Touch、J.、Mankin、A。、およびR. Bonica、「TCP認証オプション」、2008年11月、Work in Progress。
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.
Connect：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：システムがIDLE状態に戻る前に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ピアから開かれたメッセージを受信する時間に対応するタイマーは、システムが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ピアからKeepALiveまたはPCERRメッセージを受信するのを待つ時間に対応するタイマーは、システムがPCEPリソースを解放し、アイドル状態に戻ります。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:
PCEPに登録されたTCPポートで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、システム：
1. Initiates of a TCP connection with the PCEP peer,
1. PCEPピアとのTCP接続の開始、
2. Increments the ConnectRetry variable,
2. ConnectRetry変数を増やし、
3. Restarts the Connect timer,
3. 接続タイマーを再起動し、
4. Stays in the TCPPending state.
4. tcppending状態にとどまります。
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 State：
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.
o システムが現在のセッションを開始し、PCEPピアよりもIPアドレスが低い場合、システムは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ピアが高いIPアドレスがある場合、システムはTCP接続を閉じ、保留中のセッションのPCEPリソースを解放し、アイドル状態に戻ります。
o Otherwise, the system checks the PCEP session attributes (Keepalive frequency, DeadTimer, etc.).
o それ以外の場合、システムはPCEPセッションの属性（Keepalive頻度、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.
エラーが検出された場合（例えば、奇形のオープンメッセージ、オープンメッセージではないメッセージの受信、2つのオープンオブジェクトの存在）、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 KeepAlive Timerを開始し、
o Sets the RemoteOK variable to 1.
o remoteok変数を1に設定します。
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およびエラー値= 4でPCERRメッセージを送信します。
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.
o localok = 0の場合、システムはOpenWaitタイマーをクリアし、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ピアはエラータイプ= 1およびエラー値= 2でPCERRメッセージを送信します。システムは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リソースをリリースし、アイドル状態に戻ります。
KeepWait State:
Keepwait State：
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状態では、システムは、Openメッセージで提案されている容認できないPCEPセッション特性に応じて、OpenメッセージまたはPCERRメッセージを認めるPCEPピアからKeepAliveの受領を待ちます。
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およびエラー-Value = 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タイマーの有効期限の前にKeepALIVEメッセージが受信された場合、システムは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.
o remoteok = 0の場合、システムはKeepwaitタイマーをクリアし、OpenWaitタイマーを開始し、OpenWait状態に移動します。
If a PCErr message is received before the expiration of the KeepWait timer:
Keepwaitタイマーの有効期限の前にPCERRメッセージが受信された場合：
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.
KeepAliveまたはPCERRがKeepwaitタイマーの有効期限の後に受信されない場合、PCEPピアはエラータイプ= 1およびエラーValue = 7でPCERRメッセージを送信し、システムはその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 State：
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.
Keepalive Timerが期限切れになった場合、システムはKeepAliveタイマーを再起動し、KeepAliveメッセージを送信します。
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メッセージ（KeepAlive、PCREQ、PCREP、PCNTF）がPCEPピアからDeadtimerの有効期限が切れない場合、システムはセクション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ピアが2番目のTCP接続のセットアップを試みることを検出すると、TCP接続の確立を停止し、Error-Type = 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接続を閉じ、アイドル状態に移動します。
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.
Keepalive Timer：PCEPメッセージ（KeepAlive、PCREQ、PCREP、PCNTF）の送信の間の最小期間PCEPピアへ。KeepAliveタイマーの推奨値は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メッセージが受信されていない場合、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オブジェクトを使用して、同期されたパス計算要求の場合に使用されるタイマー。M同期されたパス計算要求を参照するSVECオブジェクトを含むPCEによってPCREQメッセージが受信される場合を考えてください。Synctimerの有効期限が切れた後、すべてのMパス計算要求が受信されていない場合、プロトコルエラーがトリガーされ、PCEはパス計算要求のセット全体をキャンセルする必要があります。Synctimerの目的は、何らかの理由で使用されていない同期リクエストの保存を回避することです（たとえば、PCCの不正行為）。したがって、シンシマーの値は、通常の状況下でタイマーの有効期限を回避するのに十分な大きさでなければなりません。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です。
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 Juniper Networks 1194 N. Mathilda Ave Sunnyvale、CA 94089 USA
EMail: arthi@juniper.net
Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944
エイドリアンファレルオールドドッグコンサルティング電話：44（0）1978 860944
EMail: adrian@olddog.co.uk
Eiji Oki NTT Midori 3-9-11 Musashino, Tokyo, 180-8585 JAPAN
eiji oki ntt midori 3-9-11 Musashino、東京、180-8585日本
EMail: oki.eiji@lab.ntt.co.jp
Alia Atlas British Telecom
Alia Atlas British Telecom
EMail: akatlas@alum.mit.edu
Andrew Dolganow
Alcatel
600 March Road
Ottawa, ON K2K 2E6
CANADA
EMail: andrew.dolganow@alcatel.com
Yuichi Ikejiri NTT Communications Corporation 1-1-6 Uchisaiwai-cho, Chiyoda-ku Tokyo, 100-819 JAPAN
Yuichi Ikejiri ntt Communications Corporation 1-1-6 Uchisaiwai-Cho、Chiyoda-Ku Tokyo、100-819 Japan
EMail: y.ikejiri@ntt.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo, 102-8460 JAPAN
Kenji Kumaki Kddi Corporation Garden Air Tower Iidabashi、Chiyoda-Ku、Tokyo、102-8460 Japan
EMail: ke-kumaki@kddi.com
Authors' Addresses
著者の住所
JP Vasseur (editor) Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA
JP Vasseur（編集者）Cisco Systems 1414 Massachusetts Avenue Boxborough、MA 01719 USA
EMail: jpv@cisco.com
JL Le Roux (editor) France Telecom 2, Avenue Pierre-Marzin Lannion 22307 FRANCE
Jl Le Roux（編集者）フランステレコム2、アベニューピエールマルジンラニオン22307フランス
EMail: jeanlouis.leroux@orange-ftgroup.com