[要約] RFC 8231は、状態を持つPCE（Path Computation Element）のためのPCEP（Path Computation Element Communication Protocol）拡張に関するものです。このRFCの目的は、状態を持つPCEの機能を拡張し、ネットワークの経路計算と制御を改善することです。
Internet Engineering Task Force (IETF) E. Crabbe
Request for Comments: 8231 Oracle
Category: Standards Track I. Minei
ISSN: 2070-1721 Google, Inc.
J. Medved
Cisco Systems, Inc.
R. Varga
Pantheon Technologies SRO
September 2017
Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE
ステートフルPCEのパス計算要素通信プロトコル（PCEP）拡張
Abstract
概要
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.
パス計算要素通信プロトコル（PCEP）は、パス計算要素（PCE）がパス計算クライアント（PCC）要求に応答してパス計算を実行するためのメカニズムを提供します。
Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP.
PCEPは、PCEが利用できる情報に関して明示的に想定していませんが、PCEPセッション内およびPCEPセッション間でのパス計算のタイミングとシーケンスのPCE制御についても規定していません。このドキュメントでは、PCEPを介したMPLS-TEおよびGMPLSラベルスイッチドパス（LSP）のステートフル制御を可能にするPCEPの一連の拡張機能について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8231.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8231で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................5
1.1. Requirements Language ......................................5
2. Terminology .....................................................5
3. Motivation and Objectives for Stateful PCE ......................6
3.1. Motivation .................................................6
3.1.1. Background ..........................................6
3.1.2. Why a Stateful PCE? .................................7
3.1.3. Protocol vs. Configuration ..........................8
3.2. Objectives .................................................9
4. New Functions to Support Stateful PCEs ..........................9
5. Overview of Protocol Extensions ................................10
5.1. LSP State Ownership .......................................10
5.2. New Messages ..............................................11
5.3. Error Reporting ...........................................11
5.4. Capability Advertisement ..................................11
5.5. IGP Extensions for Stateful PCE Capabilities
Advertisement .............................................12
5.6. State Synchronization .....................................13
5.7. LSP Delegation ............................................16
5.7.1. Delegating an LSP ..................................16
5.7.2. Revoking a Delegation ..............................17
5.7.3. Returning a Delegation .............................19
5.7.4. Redundant Stateful PCEs ............................19
5.7.5. Redelegation on PCE Failure ........................20
5.8. LSP Operations ............................................21
5.8.1. Passive Stateful PCE Path Computation
Request/Response ...................................21
5.8.2. Switching from Passive Stateful to Active
Stateful ...........................................22
5.8.3. Active Stateful PCE LSP Update .....................23
5.9. LSP Protection ............................................24
5.10. PCEP Sessions ............................................24
6. PCEP Messages ..................................................25
6.1. The PCRpt Message .........................................25
6.2. The PCUpd Message .........................................27
6.3. The PCErr Message .........................................30
6.4. The PCReq Message .........................................31
6.5. The PCRep Message .........................................31
7. Object Formats .................................................32
7.1. OPEN Object ...............................................32
7.1.1. STATEFUL-PCE-CAPABILITY TLV ........................32
7.2. SRP Object ................................................33
7.3. LSP Object ................................................34
7.3.1. LSP-IDENTIFIERS TLVs ...............................36
7.3.2. Symbolic Path Name TLV .............................39
7.3.3. LSP Error Code TLV .................................40
7.3.4. RSVP Error Spec TLV ................................41
8. IANA Considerations ............................................42
8.1. PCE Capabilities in IGP Advertisements ....................42
8.2. PCEP Messages .............................................43
8.3. PCEP Objects ..............................................43
8.4. LSP Object ................................................44
8.5. PCEP-Error Object .........................................45
8.6. Notification Object .......................................46
8.7. PCEP TLV Type Indicators ..................................46
8.8. STATEFUL-PCE-CAPABILITY TLV ...............................47
8.9. LSP-ERROR-CODE TLV ........................................47
9. Manageability Considerations ...................................48
9.1. Control Function and Policy ...............................48
9.2. Information and Data Models ...............................49
9.3. Liveness Detection and Monitoring .........................49
9.4. Verifying Correct Operation ...............................49
9.5. Requirements on Other Protocols and Functional
Components ................................................50
9.6. Impact on Network Operation ...............................50
10. Security Considerations .......................................50
10.1. Vulnerability ............................................50
10.2. LSP State Snooping .......................................51
10.3. Malicious PCE ............................................51
10.4. Malicious PCC ............................................52
11. References ....................................................52
11.1. Normative References .....................................52
11.2. Informative References ...................................53
Acknowledgements ..................................................55
Contributors ......................................................56
Authors' Addresses ................................................57
[RFC5440] describes the Path Computation Element Communication Protocol (PCEP). PCEP defines the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between PCEs, enabling computation of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP) characteristics. Extensions for support of Generalized MPLS (GMPLS) in PCEP are defined in [PCEP-GMPLS].
[RFC5440]は、Path Computation Element Communication Protocol（PCEP）について説明しています。 PCEPは、パス計算クライアント（PCC）とパス計算要素（PCE）の間、またはPCE間の通信を定義し、トラフィックエンジニアリングラベルスイッチドパス（TE LSP）特性のマルチプロトコルラベルスイッチング（MPLS）の計算を可能にします。 PCEPでのGeneralized MPLS（GMPLS）のサポートの拡張は、[PCEP-GMPLS]で定義されています。
This document specifies a set of extensions to PCEP to enable stateful control of LSPs within and across PCEP sessions in compliance with [RFC4657]. It includes mechanisms to effect Label Switched Path (LSP) State Synchronization between PCCs and PCEs, delegation of control over LSPs to PCEs, and PCE control of timing and sequence of path computations within and across PCEP sessions.
このドキュメントでは、[RFC4657]に準拠してPCEPセッション内およびPCEPセッション全体でLSPのステートフル制御を可能にするPCEPの拡張セットを指定します。これには、PCCとPCE間のラベルスイッチドパス（LSP）状態の同期、LSPからPCEへの制御の委任、PCEPセッション内およびPCEPセッション間でのパス計算のタイミングとシーケンスのPCE制御を行うメカニズムが含まれます。
Extensions to permit the PCE to drive creation of an LSP are defined in [PCE-Init-LSP], which specifies PCE-initiated LSP creation.
PCEがLSPの作成を駆動できるようにする拡張機能は、PCEが開始するLSP作成を指定する[PCE-Init-LSP]で定義されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document uses the following terms defined in [RFC5440]: PCC, PCE, PCEP Peer, and PCEP speaker.
このドキュメントでは、[RFC5440]で定義されている次の用語を使用します。PCC、PCE、PCEPピア、PCEPスピーカー。
This document uses the following terms defined in [RFC4655]: Traffic Engineering Database (TED).
このドキュメントでは、[RFC4655]で定義されている次の用語を使用しています。TrafficEngineering Database（TED）。
This document uses the following terms defined in [RFC3031]: LSP.
このドキュメントでは、[RFC3031]で定義されている次の用語を使用します：LSP。
This document uses the following terms defined in [RFC8051]: Stateful PCE, Passive Stateful PCE, Active Stateful PCE, Delegation, and LSP State Database.
このドキュメントでは、[RFC8051]で定義されている次の用語を使用します。ステートフルPCE、パッシブステートフルPCE、アクティブステートフルPCE、委任、およびLSP状態データベース。
The following terms are defined in this document:
このドキュメントでは、次の用語が定義されています。
Revocation: an operation performed by a PCC on a previously delegated LSP. Revocation revokes the rights granted to the PCE in the delegation operation.
失効：以前に委任されたLSPでPCCによって実行される操作。取り消しは、委任操作でPCEに付与された権利を取り消します。
Redelegation Timeout Interval: the period of time a PCC waits for, when a PCEP session is terminated, before revoking LSP delegation to a PCE and attempting to redelegate LSPs associated with the terminated PCEP session to an alternate PCE. The Redelegation Timeout Interval is a PCC-local value that can be either operator configured or dynamically computed by the PCC based on local policy.
再委任タイムアウト間隔：PCEPセッションが終了したときに、PCEへのLSP委任を取り消して、終了したPCEPセッションに関連付けられたLSPを代替PCEに再委任する前に、PCCが待機する時間。 Redelegation Timeout IntervalはPCCローカル値であり、オペレーターが構成するか、ローカルポリシーに基づいてPCCが動的に計算できます。
State Timeout Interval: the period of time a PCC waits for, when a PCEP session is terminated, before flushing LSP state associated with that PCEP session and reverting to operator-defined default parameters or behaviors. The State Timeout Interval is a PCC-local value that can be either operator configured or dynamically computed by the PCC based on local policy.
状態タイムアウト間隔：PCEPセッションに関連付けられたLSP状態をフラッシュし、オペレーターが定義したデフォルトのパラメーターまたは動作に戻る前に、PCCがPCEPセッションが終了したときに待機する時間。状態タイムアウト間隔はPCCローカル値であり、オペレーターが構成するか、ローカルポリシーに基づいてPCCが動的に計算できます。
LSP State Report: an operation to send LSP state (operational/ administrative status, LSP attributes configured at the PCC and set by a PCE, etc.) from a PCC to a PCE.
LSP状態レポート：LSP状態（操作/管理ステータス、PCCで構成され、PCEによって設定されたLSP属性など）をPCCからPCEに送信する操作。
LSP Update Request: an operation where an Active Stateful PCE requests a PCC to update one or more attributes of an LSP and to re-signal the LSP with updated attributes.
LSP更新要求：アクティブステートフルPCEがPCCにLSPの1つ以上の属性を更新し、更新された属性でLSPを再シグナリングするように要求する操作。
SRP-ID-number: a number used to correlate errors and LSP State Reports to LSP Update Requests. It is carried in the Stateful PCE Request Parameter (SRP) object described in Section 7.2.
SRP-ID-number：エラーとLSP状態レポートをLSP更新要求に関連付けるために使用される番号。これは、セクション7.2で説明されているステートフルPCE要求パラメーター（SRP）オブジェクトで伝達されます。
Within this document, PCEP communications are described through PCC-PCE relationships. The PCE architecture also supports PCE-PCE communication, by having the requesting PCE fill the role of a PCC, as usual.
このドキュメントでは、PCEP通信はPCCとPCEの関係を通じて説明されています。 PCEアーキテクチャは、通常どおり、要求するPCEがPCCの役割を果たすようにすることで、PCE-PCE通信もサポートします。
The message formats in this document are specified using Routing Backus-Naur Format (RBNF) encoding as specified in [RFC5511].
このドキュメントのメッセージ形式は、[RFC5511]で指定されているRouting Backus-Naur Format（RBNF）エンコーディングを使用して指定されています。
[RFC8051] presents several use cases, demonstrating scenarios that benefit from the deployment of a stateful PCE. The scenarios apply equally to MPLS-TE and GMPLS deployments.
[RFC8051]はいくつかの使用例を示し、ステートフルPCEの展開から利益を得るシナリオを示しています。シナリオは、MPLS-TEおよびGMPLSの展開に等しく適用されます。
Traffic engineering has been a goal of the MPLS architecture since its inception [RFC2702] [RFC3031] [RFC3346]. In the traffic engineering system provided by [RFC3209], [RFC3630], and [RFC5305], information about network resources utilization is only available as total reserved capacity by the traffic class on a per-interface basis; individual LSP state is available only locally on each Label Edge Router (LER) for its own LSPs. In most cases, this makes good sense, as distribution and retention of total LSP state for all LERs within in the network would be prohibitively costly.
トラフィックエンジニアリングは、MPLSアーキテクチャの当初からの目標でした[RFC2702] [RFC3031] [RFC3346]。 [RFC3209]、[RFC3630]、および[RFC5305]によって提供されるトラフィックエンジニアリングシステムでは、ネットワークリソースの使用率に関する情報は、トラフィッククラスによる総予約容量としてのみ、インターフェイスごとに利用できます。個々のLSP状態は、独自のLSPの各ラベルエッジルーター（LER）でローカルにのみ使用できます。ネットワーク内のすべてのLERの合計LSP状態の配布と保持には法外なコストがかかるため、ほとんどの場合、これは理にかなっています。
Unfortunately, this visibility in terms of global LSP state may result in a number of issues for some demand patterns, particularly within a common setup and hold priority. This issue affects online traffic engineering systems.
残念ながら、グローバルなLSP状態に関するこの可視性は、一部の需要パターン、特に一般的なセットアップとホールドプライオリティ内で多くの問題を引き起こす可能性があります。この問題は、オンライントラフィックエンジニアリングシステムに影響します。
A sufficiently over-provisioned system will by definition have no issues routing its demand on the shortest path. However, lowering the degree to which network over-provisioning is required in order to run a healthy, functioning network is a clear and explicit promise of MPLS architecture. In particular, it has been a goal of MPLS to provide mechanisms to alleviate congestion scenarios in which "traffic streams are inefficiently mapped onto available resources; causing subsets of network resources to become over-utilized while others remain underutilized" [RFC2702].
十分に過剰にプロビジョニングされたシステムは、定義上、最短経路でその要求をルーティングする問題はありません。ただし、正常に機能しているネットワークを実行するために必要なネットワークのオーバープロビジョニングの度合いを下げることは、MPLSアーキテクチャの明確かつ明確な約束です。特に、MPLSの目標は、「トラフィックストリームが利用可能なリソースに非効率的にマッピングされ、ネットワークリソースのサブセットが過剰に利用され、他のリソースは十分に利用されない」[RFC2702]といった輻輳シナリオを緩和するメカニズムを提供することでした。
[RFC4655] defines a stateful PCE to be one in which the PCE maintains "strict synchronization between the PCE and not only the network states (in term of topology and resource information), but also the set of computed paths and reserved resources in use in the network." [RFC4655] also expressed a number of concerns with regard to a stateful PCE, specifically:
[RFC4655]は、ステートフルPCEを、PCEが「PCEとネットワーク状態（トポロジーおよびリソース情報の観点から）だけでなく、計算パスと予約済みリソースのセットで使用される厳密な同期も維持する」と定義しています。ネットワーク。」 [RFC4655]はまた、ステートフルPCEに関して多くの懸念を表明しました、特に：
o Any reliable synchronization mechanism would result in significant control-plane overhead
o 信頼できる同期メカニズムにより、コントロールプレーンのオーバーヘッドが大幅に増加する
o Out-of-band TED synchronization would be complex and prone to race conditions
o 帯域外のTED同期は複雑で、競合状態になりやすい
o Path calculations incorporating total network state would be highly complex
o 総ネットワーク状態を組み込んだパス計算は非常に複雑になります
In general, stress on the control plane will be directly proportional to the size of the system being controlled and the tightness of the control loop and indirectly proportional to the amount of over-provisioning in terms of both network capacity and reservation overhead.
一般に、コントロールプレーンへのストレスは、制御対象のシステムのサイズと制御ループの緊密さに直接比例し、ネットワーク容量と予約オーバーヘッドの両方に関して、過剰プロビジョニングの量に間接的に比例します。
Despite these concerns in terms of implementation complexity and scalability, several TE algorithms exist today that have been demonstrated to be extremely effective in large TE systems, providing both rapid convergence and significant benefits in terms of optimality of resource usage [MXMN-TE]. All of these systems share at least two common characteristics: the requirement for both global visibility of a flow (or in this case, a TE LSP) state and for ordered control of path reservations across devices within the system being controlled. While some approaches have been suggested in order to remove the requirements for ordered control (see [MPLS-PC]), these approaches are highly dependent on traffic distribution and do not allow for multiple simultaneous LSP priorities representing Diffserv classes.
実装の複雑さとスケーラビリティに関するこれらの懸念にもかかわらず、大規模なTEシステムで非常に効果的であることが実証されているいくつかのTEアルゴリズムが今日存在し、リソースの使用の最適化に関して高速収束と大きな利点の両方を提供しています[MXMN-TE]。これらのシステムはすべて、少なくとも2つの共通の特性を共有しています。フロー（またはこの場合はTE LSP）状態のグローバルな可視性と、制御対象のシステム内のデバイス間でのパス予約の順序制御の両方に対する要件です。順序制御の要件を削除するためにいくつかのアプローチが提案されていますが（[MPLS-PC]を参照）、これらのアプローチはトラフィック分散に大きく依存しており、Diffservクラスを表す複数の同時LSP優先順位を許可していません。
The use cases described in [RFC8051] demonstrate a need for visibility into global inter-PCC LSP state in PCE path computations and for PCE control of sequence and timing in altering LSP path characteristics within and across PCEP sessions.
[RFC8051]で説明されているユースケースは、PCEパス計算でのグローバルなPCC間LSP状態の可視性と、PCEPセッション内およびPCEPセッション間でのLSPパス特性の変更におけるシーケンスとタイミングのPCE制御の必要性を示しています。
Note that existing configuration tools and protocols can be used to set LSP state, such as a Command Line Interface (CLI) tool. However, this solution has several shortcomings:
コマンドラインインターフェイス（CLI）ツールなど、既存の構成ツールとプロトコルを使用してLSP状態を設定できることに注意してください。ただし、このソリューションにはいくつかの欠点があります。
o Scale & Performance: configuration operations often have transactional semantics that are typically heavyweight and often require processing of additional configuration portions beyond the state being directly acted upon, with corresponding cost in CPU cycles, negatively impacting both PCC stability LSP Update rate capacity.
o スケールとパフォーマンス：多くの場合、構成操作にはトランザクションセマンティクスがあり、直接の影響を受ける状態を超えて追加の構成部分を処理する必要があり、CPUサイクルに対応するコストがかかり、PCC安定性LSP更新レート容量の両方に悪影響を及ぼします。
o Security: when a PCC opens a configuration channel allowing a PCE to send configuration, a malicious PCE may take advantage of this ability to take over the PCC. In contrast, the PCEP extensions described in this document only allow a PCE control over a very limited set of LSP attributes.
o セキュリティ：PCCが構成チャネルを開いてPCEが構成を送信できるようにすると、悪意のあるPCEがこの機能を利用してPCCを乗っ取る可能性があります。対照的に、このドキュメントで説明されているPCEP拡張機能は、非常に限られたLSP属性のセットに対するPCE制御のみを許可します。
o Interoperability: each vendor has a proprietary information model for configuring LSP state, which limits interoperability of a stateful PCE with PCCs from different vendors. The PCEP extensions described in this document allow for a common information model for LSP state for all vendors.
o 相互運用性：各ベンダーには、LSP状態を構成するための独自の情報モデルがあり、ステートフルPCEと異なるベンダーのPCCとの相互運用性を制限します。このドキュメントで説明されているPCEP拡張機能により、すべてのベンダーのLSP状態の共通情報モデルが可能になります。
o Efficient State Synchronization: configuration channels may be heavyweight and unidirectional; therefore, efficient State Synchronization between a PCC and a PCE may be a problem.
o 効率的な状態同期：構成チャネルは重量級で単方向の場合があります。したがって、PCCとPCE間の効率的な状態同期が問題になる場合があります。
The objectives for the protocol extensions to support stateful PCE described in this document are as follows:
このドキュメントで説明されているステートフルPCEをサポートするためのプロトコル拡張の目的は次のとおりです。
o Allow a single PCC to interact with a mix of stateless and stateful PCEs simultaneously using the same protocol, i.e., PCEP.
o 単一のPCCが、同じプロトコル（PCEP）を使用して、ステートレスPCEとステートフルPCEの混在と同時に対話できるようにします。
o Support efficient LSP State Synchronization between the PCC and one or more active or passive stateful PCEs.
o PCCと1つ以上のアクティブまたはパッシブステートフルPCE間の効率的なLSP状態同期をサポートします。
o Allow a PCC to delegate control of its LSPs to an active stateful PCE such that a given LSP is under the control of a single PCE at any given time.
o PCCがLSPの制御をアクティブなステートフルPCEに委任できるようにして、特定のLSPが常に単一のPCEの制御下に置かれるようにします。
* A PCC may revoke this delegation at any time during the lifetime of the LSP. If LSP delegation is revoked while the PCEP session is up, the PCC MUST notify the PCE about the revocation.
* PCCは、LSPの有効期間中いつでもこの委任を取り消すことができます。 PCEPセッションのアップ中にLSP委任が取り消された場合、PCCは取り消しについてPCEに通知する必要があります。
* A PCE may return an LSP delegation at any point during the lifetime of the PCEP session. If LSP delegation is returned by the PCE while the PCEP session is up, the PCE MUST notify the PCC about the returned delegation.
* PCEは、PCEPセッションの存続期間中いつでもLSP委任を返すことができます。 PCEPセッションのアップ中にLSP委任がPCEによって返された場合、PCEは返された委任についてPCCに通知する必要があります。
o Allow a PCE to control computation timing and update timing across all LSPs that have been delegated to it.
o PCEが委任されたすべてのLSP全体で計算タイミングと更新タイミングを制御できるようにします。
o Enable uninterrupted operation of a PCC's LSPs in the event of a PCE failure or while control of LSPs is being transferred between PCEs.
o PCE障害が発生した場合、またはLSPの制御がPCE間で転送されている間に、PCCのLSPの中断のない動作を有効にします。
Several new functions are required in PCEP to support stateful PCEs. A function can be initiated either from a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C). The new functions are:
ステートフルPCEをサポートするには、PCEPにいくつかの新機能が必要です。機能は、PCCからPCEへ（C-E）、またはPCEからPCCへ（E-C）のいずれかで開始できます。新しい機能は次のとおりです。
Capability advertisement (E-C,C-E): both the PCC and the PCE must announce during PCEP session establishment that they support PCEP Stateful PCE extensions defined in this document.
機能アドバタイズメント（E-C、C-E）：PCCとPCEの両方が、PCEPセッションの確立中に、このドキュメントで定義されているPCEPステートフルPCE拡張をサポートしていることを通知する必要があります。
LSP State Synchronization (C-E): after the session between the PCC and a stateful PCE is initialized, the PCE must learn the state of a PCC's LSPs before it can perform path computations or update LSP attributes in a PCC.
LSP状態同期（C-E）：PCCとステートフルPCE間のセッションが初期化された後、PCEは、PCCでパス計算を実行したり、LSP属性を更新したりする前に、PCCのLSPの状態を学習する必要があります。
LSP Update Request (E-C): a PCE requests modification of attributes on a PCC's LSP.
LSP更新要求（E-C）：PCEは、PCCのLSPの属性の変更を要求します。
LSP State Report (C-E): a PCC sends an LSP State Report to a PCE whenever the state of an LSP changes.
LSP状態レポート（C-E）：PCCは、LSPの状態が変化するたびにLSP状態レポートをPCEに送信します。
LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to update LSP attributes on one or more LSPs; the PCE becomes the authoritative source of the LSP's attributes as long as the delegation is in effect (see Section 5.7); the PCC may withdraw the delegation or the PCE may give up the delegation at any time.
LSP制御委任（C-E、E-C）：PCCは、1つ以上のLSPのLSP属性を更新する権利をPCEに付与します。 PCEは、委任が有効である限り（セクション5.7を参照）、LSPの属性の信頼できるソースになります。 PCCは委任を撤回する場合があり、PCEはいつでも委任を放棄する場合があります。
Similarly to [RFC5440], 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.
[RFC5440]と同様に、PCCがPCEのセットを検出するために使用する検出方法（たとえば、静的構成または動的検出を介して）およびPCEを選択するために使用されるアルゴリズムは想定されていません。
In PCEP (defined in [RFC5440]), LSP state and operation are under the control of a PCC (a PCC may be a Label Switching Router (LSR) or a management station). Attributes received from a PCE are subject to PCC's local policy. The PCEP extensions described in this document do not change this behavior.
PCEP（[RFC5440]で定義）では、LSPの状態と操作はPCCの制御下にあります（PCCはラベルスイッチングルーター（LSR）または管理ステーションの場合があります）。 PCEから受け取った属性には、PCCのローカルポリシーが適用されます。このドキュメントで説明されているPCEP拡張機能は、この動作を変更しません。
An active stateful PCE may have control of a PCC's LSPs that were delegated to it, but the LSP state ownership is retained by the PCC. In particular, in addition to specifying values for LSP's attributes, an active stateful PCE also decides when to make LSP modifications.
アクティブなステートフルPCEは、委任されたPCCのLSPを制御できますが、LSP状態の所有権はPCCによって保持されます。特に、LSPの属性の値を指定することに加えて、アクティブなステートフルPCEは、いつLSPを変更するかを決定します。
Retaining LSP state ownership on the PCC allows for:
PCCでLSP状態の所有権を保持すると、次のことが可能になります。
o a PCC to interact with both stateless and stateful PCEs at the same time
o ステートレスPCEとステートフルPCEの両方を同時に操作するPCC
o a stateful PCE to only modify a small subset of LSP parameters, i.e., to set only a small subset of the overall LSP state; other parameters may be set by the operator, for example, through CLI commands
o LSPパラメータの小さなサブセットのみを変更する、つまりLSP状態全体の小さなサブセットのみを設定するステートフルPCE;他のパラメーターは、例えばCLIコマンドを介して、オペレーターが設定できます。
o a PCC to revert delegated LSP to an operator-defined default or to delegate the LSPs to a different PCE, if the PCC gets disconnected from a PCE with currently delegated LSPs
o 現在委任されているLSPを持つPCEからPCCが切断された場合に、委任されたLSPをオペレーター定義のデフォルトに戻す、またはLSPを別のPCEに委任するPCC
In this document, we define the following new PCEP messages:
このドキュメントでは、次の新しいPCEPメッセージを定義します。
Path Computation State Report (PCRpt): a PCEP message sent by a PCC to a PCE to report the status of one or more LSPs. Each LSP State Report in a PCRpt message MAY contain the actual LSP's path, bandwidth, operational and administrative status, etc. An LSP Status Report carried on a PCRpt message is also used in delegation or revocation of control of an LSP to/from a PCE. The PCRpt message is described in Section 6.1.
パス計算状態レポート（PCRpt）：1つ以上のLSPのステータスを報告するためにPCCからPCEに送信されるPCEPメッセージ。 PCRptメッセージ内の各LSP状態レポートには、実際のLSPのパス、帯域幅、運用および管理ステータスなどが含まれる場合があります。PCRptメッセージで伝送されるLSPステータスレポートは、PCEとの間のLSPの制御の委任または取り消しにも使用されます。 PCRptメッセージについては、セクション6.1で説明します。
Path Computation Update Request (PCUpd): a PCEP message sent by a PCE to a PCC to update LSP parameters, on one or more LSPs. Each LSP Update Request on a PCUpd message MUST contain all LSP parameters that a PCE wishes to be set for a given LSP. An LSP Update Request carried on a PCUpd message is also used to return LSP delegations if at any point PCE no longer desires control of an LSP. The PCUpd message is described in Section 6.2.
パス計算更新要求（PCUpd）：1つ以上のLSPでLSPパラメーターを更新するためにPCEからPCCに送信されるPCEPメッセージ。 PCUpdメッセージの各LSP更新要求には、PCEが特定のLSPに設定したいすべてのLSPパラメータが含まれている必要があります。 PCUpdメッセージで伝送されるLSP更新要求は、PCEがLSPの制御を必要としなくなった場合に、LSP委任を返すためにも使用されます。 PCUpdメッセージについては、セクション6.2で説明します。
The new functions defined in Section 4 are mapped onto the new messages as shown in the following table.
セクション4で定義された新しい関数は、次の表に示すように新しいメッセージにマップされます。
+----------------------------------------+--------------+
| Function | Message |
+----------------------------------------+--------------+
| Capability Advertisement (E-C,C-E) | Open |
| State Synchronization (C-E) | PCRpt |
| LSP State Report (C-E) | PCRpt |
| LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd |
| LSP Update Request (E-C) | PCUpd |
+----------------------------------------+--------------+
Table 1: New Function to Message Mapping
表1：新しい関数からメッセージへのマッピング
Error reporting is done using the procedures defined in [RFC5440] and reusing the applicable error types and error values of [RFC5440] wherever appropriate. The current document defines new error values for several error types to cover failures specific to stateful PCE.
エラー報告は、[RFC5440]で定義された手順を使用して行われ、[RFC5440]の該当するエラータイプとエラー値が適切な場合は再利用されます。現在のドキュメントでは、ステートフルPCEに固有の障害に対応するために、いくつかのエラータイプの新しいエラー値を定義しています。
During the PCEP initialization phase, PCEP speakers (PCE or PCC) advertise their support of PCEP Stateful PCE extensions. A PCEP speaker includes the "STATEFUL-PCE-CAPABILITY TLV", described in Section 7.1.1, in the OPEN object to advertise its support for PCEP
PCEP初期化フェーズ中に、PCEPスピーカー（PCEまたはPCC）は、PCEPステートフルPCE拡張機能のサポートを通知します。 PCEPスピーカーは、OPENオブジェクトにセクション7.1.1で説明されている「STATEFUL-PCE-CAPABILITY TLV」を含めて、PCEPのサポートを宣伝します。
Stateful PCE extensions. The STATEFUL-PCE-CAPABILITY TLV includes the 'LSP Update' flag that indicates whether the PCEP speaker supports LSP parameter updates.
ステートフルPCE拡張。 STATEFUL-PCE-CAPABILITY TLVには、PCEPスピーカーがLSPパラメータの更新をサポートしているかどうかを示す「LSP Update」フラグが含まれています。
The presence of the STATEFUL-PCE-CAPABILITY TLV in PCC's OPEN object indicates that the PCC is willing to send LSP State Reports whenever LSP parameters or operational status changes.
PCCのOPENオブジェクトにSTATEFUL-PCE-CAPABILITY TLVが存在することは、LSCパラメータまたは動作ステータスが変化するたびに、PCCがLSP状態レポートを送信する用意があることを示しています。
The presence of the STATEFUL-PCE-CAPABILITY TLV in PCE's OPEN message indicates that the PCE is interested in receiving LSP State Reports whenever LSP parameters or operational status changes.
PCEのOPENメッセージにSTATEFUL-PCE-CAPABILITY TLVが存在することは、PCEがLSPパラメータまたは動作ステータスが変化するたびにLSP状態レポートを受信することに関心があることを示しています。
The PCEP extensions for stateful PCEs MUST NOT be used if one or both PCEP speakers have not included the STATEFUL-PCE-CAPABILITY TLV in their respective OPEN message. If the PCEP speaker on the PCC supports the extensions of this specification but did not advertise this capability, then upon receipt of a PCUpd message from the PCE, it MUST generate a PCEP Error (PCErr) with Error-type=19 (Invalid Operation) and error-value 2 (Attempted LSP Update Request if the stateful PCE capability was not advertised)(see Section 8.5), and it SHOULD terminate the PCEP session. If the PCEP Speaker on the PCE supports the extensions of this specification but did not advertise this capability, then upon receipt of a PCRpt message from the PCC, it MUST generate a PCErr with Error-type=19 (Invalid Operation) and error-value 5 (Attempted LSP State Report if stateful PCE capability was not advertised) (see Section 8.5), and it SHOULD terminate the PCEP session.
ステートフルPCEのPCEP拡張機能は、一方または両方のPCEPスピーカーがそれぞれのOPENメッセージにSTATEFUL-PCE-CAPABILITY TLVを含めていない場合は使用しないでください。 PCCのPCEPスピーカーがこの仕様の拡張をサポートしているが、この機能をアドバタイズしなかった場合、PCEからPCUpdメッセージを受信すると、Error-type = 19（無効な操作）のPCEPエラー（PCErr）を生成する必要があります。およびエラー値2（ステートフルPCE機能がアドバタイズされなかった場合に試行されたLSP更新要求）（セクション8.5を参照）。PCEPセッションを終了する必要があります（SHOULD）。 PCEのPCEPスピーカーがこの仕様の拡張をサポートしているが、この機能をアドバタイズしなかった場合、PCCからPCRptメッセージを受信すると、Error-type = 19（無効な操作）およびerror-valueのPCErrを生成する必要があります。 5（ステートフルPCE機能がアドバタイズされなかった場合のLSP状態レポートの試行）（セクション8.5を参照）、PCEPセッションを終了する必要があります（SHOULD）。
LSP delegation and LSP Update operations defined in this document may only be used if both PCEP speakers set the LSP-UPDATE-CAPABILITY flag in the STATEFUL-PCE-CAPABILITY TLV to 'Updates Allowed (U flag = 1)'. If this is not the case and LSP delegation or LSP Update operations are attempted, then a PCErr with Error-type=19 (Invalid Operation) and error-value 1 (Attempted LSP Update Request for a non-delegated LSP) (see Section 8.5) MUST be generated. Note that, even if one of the PCEP speakers does not set the LSP-UPDATE-CAPABILITY flag in its STATEFUL-PCE-CAPABILITY TLV, a PCE can still operate as a passive stateful PCE by accepting LSP State Reports from the PCC in order to build and maintain an up-to-date view of the state of the PCC's LSPs.
このドキュメントで定義されているLSP委任とLSP更新操作は、両方のPCEPスピーカーがSTATEFUL-PCE-CAPABILITY TLVのLSP-UPDATE-CAPABILITYフラグを「更新を許可（Uフラグ= 1）」に設定した場合にのみ使用できます。これが当てはまらず、LSP委任またはLSP更新操作が試行された場合、Error-type = 19（無効な操作）およびerror-value 1（委任されていないLSPに対して試行されたLSP更新要求）を持つPCErr（セクション8.5を参照） ）生成する必要があります。 PCEPスピーカーの1つがSTATEFUL-PCE-CAPABILITY TLVでLSP-UPDATE-CAPABILITYフラグを設定しない場合でも、PCEは、PCCからのLSP状態レポートを受け入れることにより、パッシブステートフルPCEとして動作できます。 PCCのLSPの状態の最新のビューを構築および維持します。
When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs are either LSRs or servers also participating in the IGP, an effective mechanism for PCE discovery within an IGP routing domain consists of utilizing IGP advertisements. Extensions for the advertisement of PCE Discovery Information are defined for OSPF and for IS-IS in [RFC5088] and [RFC5089], respectively.
PCCがIGP（OSPFまたはIS-IS）に参加しているLSRであり、PCEがISRに参加しているLSRまたはサーバーのいずれかである場合、IGPルーティングドメイン内のPCE検出の効果的なメカニズムは、IGPアドバタイズメントの利用で構成されます。 PCE Discovery Informationのアドバタイズメントの拡張は、OSPFとIS-ISに対してそれぞれ[RFC5088]と[RFC5089]で定義されています。
The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub-TLV used to advertise PCE capabilities. It MAY be present within the PCE Discovery (PCED) sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] provide the description and processing rules for this sub-TLV when carried within OSPF and IS-IS, respectively.
[RFC5089]で定義されているPCE-CAP-FLAGSサブTLVは、PCE機能をアドバタイズするために使用されるオプションのサブTLVです。これは、OSPFまたはIS-ISによって伝送されるPCE Discovery（PCED）サブTLV内に存在する場合があります。 [RFC5088]と[RFC5089]は、それぞれOSPFとIS-IS内で伝送される場合のこのサブTLVの説明と処理ルールを提供します。
The format of the PCE-CAP-FLAGS sub-TLV is included below for easy reference:
PCE-CAP-FLAGSサブTLVのフォーマットは、簡単に参照できるように以下に含まれています。
Type: 5
タイプ：5
Length: Multiple of 4.
長さ：4の倍数。
Value: This contains an array of units of 32-bit flags with the most significant bit as 0. Each bit represents one PCE capability.
値：これには、最上位ビットが0である32ビットフラグのユニットの配列が含まれます。各ビットは1つのPCE機能を表します。
PCE capability bits are defined in [RFC5088]. This document defines new capability bits for the stateful PCE as follows:
PCE機能ビットは[RFC5088]で定義されています。このドキュメントでは、ステートフルPCEの新しい機能ビットを次のように定義しています。
Bit Capability
--- -------------------------------
11 Active stateful PCE capability
12 Passive stateful PCE capability
Note that while active and passive stateful PCE capabilities may be advertised during discovery, PCEP speakers that wish to use stateful PCEP MUST negotiate stateful PCEP capabilities during PCEP session setup, as specified in the current document. A PCC MAY initiate stateful PCEP capability negotiation at PCEP session setup even if it did not receive any IGP PCE capability advertisements.
アクティブおよびパッシブステートフルPCE機能はディスカバリー中にアドバタイズされる可能性がありますが、ステートフルPCEPを使用したいPCEPスピーカーは、現在のドキュメントで指定されているように、PCEPセッションのセットアップ中にステートフルPCEP機能をネゴシエートする必要があります。 PCCは、IGP PCE機能アドバタイズを受信していなくても、PCEPセッションのセットアップでステートフルPCEP機能ネゴシエーションを開始する場合があります。
The purpose of State Synchronization is to provide a checkpoint-in-time state replica of a PCC's LSP state in a PCE. State Synchronization is performed immediately after the initialization phase [RFC5440].
状態同期の目的は、PCE内のPCCのLSP状態のチェックポイントインタイム状態レプリカを提供することです。状態同期は、初期化フェーズの直後に実行されます[RFC5440]。
During State Synchronization, a PCC first takes a snapshot of the state of its LSPs, then it sends the snapshot to a PCE in a sequence of LSP State Reports. Each LSP State Report sent during State Synchronization has the SYNC flag in the LSP object set to 1. The set of LSPs for which state is synchronized with a PCE is determined by the PCC's local configuration (see more details in Section 9.1) and MAY also be determined by stateful PCEP capabilities defined in other documents, such as [RFC8232].
状態の同期中、PCCはまずLSPの状態のスナップショットを取得し、次に一連のLSP状態レポートでそのスナップショットをPCEに送信します。状態同期中に送信される各LSP状態レポートでは、LSPオブジェクトのSYNCフラグが1に設定されています。状態がPCEと同期されるLSPのセットは、PCCのローカル構成によって決定されます（9.1項で詳細を参照）。 [RFC8232]などの他のドキュメントで定義されているステートフルPCEP機能によって決定されます。
The end of the synchronization marker is a PCRpt message with the SYNC flag set to 0 for an LSP object with PLSP-ID equal to the reserved value 0 (see Section 7.3). In this case, the LSP object SHOULD NOT include the SYMBOLIC-PATH-NAME TLV and SHOULD include the LSP-IDENTIFIERS TLV with the special value of all zeroes. The PCRpt message MUST include an empty Explicit Route Object (ERO) as its intended path and SHOULD NOT include the optional Record Route Object (RRO) for its actual path. If the PCC has no state to synchronize, it SHOULD only send the end of the synchronization marker.
同期マーカーの終わりは、PLSP-IDが予約値0に等しいLSPオブジェクトのSYNCフラグが0に設定されたPCRptメッセージです（7.3節を参照）。この場合、LSPオブジェクトにはSYMBOLIC-PATH-NAME TLVを含めるべきではなく（SHOULD NOT）、特殊な値がすべてゼロのLSP-IDENTIFIERS TLVを含めるべきです（SHOULD）。 PCRptメッセージには、意図したパスとして空の明示的ルートオブジェクト（ERO）を含める必要があり、実際のパスのオプションのレコードルートオブジェクト（RRO）を含めないでください。 PCCに同期する状態がない場合、同期マーカーの終わりのみを送信する必要があります（SHOULD）。
A PCE SHOULD NOT send PCUpd messages to a PCC before State Synchronization is complete. A PCC SHOULD NOT send PCReq messages to a PCE before State Synchronization is complete. This is to allow the PCE to get the best possible view of the network before it starts computing new paths.
PCEは、状態同期が完了する前にPCUpdメッセージをPCCに送信しないでください。 PCCは、状態同期が完了する前にPCReqメッセージをPCEに送信してはなりません（SHOULD NOT）。これは、PCEが新しいパスの計算を開始する前に、ネットワークの可能な限り最適なビューを取得できるようにするためです。
Either the PCE or the PCC MAY terminate the session using the PCEP session termination procedures during the synchronization phase. If the session is terminated, the PCE MUST clean up the state it received from this PCC. The session re-establishment MUST be re-attempted per the procedures defined in [RFC5440], including use of a backoff timer.
PCEまたはPCCは、同期フェーズ中にPCEPセッション終了手順を使用してセッションを終了する場合があります。セッションが終了した場合、PCEはこのPCCから受信した状態をクリーンアップする必要があります。セッションの再確立は、バックオフタイマーの使用を含め、[RFC5440]で定義された手順に従って再試行する必要があります。
If the PCC encounters a problem that prevents it from completing the LSP State Synchronization, it MUST send a PCErr message with error-type 20 (LSP State Synchronization Error) and error-value 5 (indicating an internal PCC error) to the PCE and terminate the session.
PCCがLSP状態同期の完了を妨げる問題に遭遇した場合、PCCはエラータイプ20（LSP状態同期エラー）およびエラー値5（内部PCCエラーを示す）を含むPCErrメッセージをPCEに送信して終了する必要があります。セッション。
The PCE does not send positive acknowledgments for properly received synchronization messages. It MUST respond with a PCErr message with Error-type=20 (LSP State Synchronization Error) and error-value 1 (indicating an error in processing the PCRpt) (see Section 8.5) if it encounters a problem with the LSP State Report it received from the PCC, and it MUST terminate the session.
PCEは、適切に受信された同期メッセージに対して肯定応答を送信しません。受信したLSP状態レポートで問題が発生した場合、Error-type = 20（LSP状態同期エラー）とエラー値1（PCRptの処理中のエラーを示す）（セクション8.5を参照）のPCErrメッセージで応答する必要があります。 PCCから、それはセッションを終了しなければなりません。
A PCE implementing a limit on the resources a single PCC can occupy MUST send a PCEP Notify (PCNtf) message with Notification Type 4 (Stateful PCE resource limit exceeded) and Notification Value 1 (Entering resource limit exceeded state) in response to the PCRpt message triggering this condition in the synchronization phase and MUST terminate the session.
1つのPCCが占有できるリソースに制限を実装するPCEは、PCRptメッセージに応答して、通知タイプ4（ステートフルPCEリソース制限を超過）および通知値1（リソース制限超過状態を入力）を含むPCEP通知（PCNtf）メッセージを送信する同期フェーズでこの条件をトリガーし、セッションを終了する必要があります。
The successful State Synchronization sequence is shown in Figure 1.
成功した状態同期シーケンスを図1に示します。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|-----PCRpt, SYNC=1----->| (Sync start)
| |
|-----PCRpt, SYNC=1----->|
| . |
| . |
| . |
|-----PCRpt, SYNC=1----->|
| . |
| . |
| . |
| |
|-----PCRpt, SYNC=0----->| (End of sync marker
| | LSP State Report
| | for PLSP-ID=0)
| | (Sync done)
Figure 1: Successful State Synchronization
図1：成功した状態同期
The sequence where the PCE fails during the State Synchronization phase is shown in Figure 2.
PCEが状態同期フェーズ中に失敗するシーケンスを図2に示します。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|-----PCRpt, SYNC=1----->|
| |
|-----PCRpt, SYNC=1----->|
| . |
| . |
| . |
|-----PCRpt, SYNC=1----->|
| |
|-PCRpt, SYNC=1 |
| \ ,-PCErr |
| \ / |
| \/ |
| /\ |
| / `-------->| (Ignored)
|<--------` |
Figure 2: Failed State Synchronization (PCE Failure)
図2：状態同期の失敗（PCE失敗）
The sequence where the PCC fails during the State Synchronization phase is shown in Figure 3.
状態同期フェーズ中にPCCが失敗するシーケンスを図3に示します。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|-----PCRpt, SYNC=1----->|
| |
|-----PCRpt, SYNC=1----->|
| . |
| . |
| . |
|-------- PCErr=? ------>|
| |
Figure 3: Failed State Synchronization (PCC Failure)
図3：状態同期の失敗（PCC失敗）
Optimizations to the synchronization procedures and alternate mechanisms of providing the synchronization function are outside the scope of this document and are discussed elsewhere (see [RFC8232]).
同期手順の最適化と同期機能を提供する代替メカニズムは、このドキュメントの範囲外であり、他の場所で説明されています（[RFC8232]を参照）。
If during capability advertisement both the PCE and the PCC have indicated that they support LSP Update, then the PCC may choose to grant the PCE a temporary right to update (a subset of) LSP attributes on one or more LSPs. This is called "LSP delegation", and it MAY be performed at any time after the initialization phase, including during the State Synchronization phase.
機能のアドバタイズ中に、PCEとPCCの両方がLSP更新をサポートすることを示している場合、PCCは、1つ以上のLSPのLSP属性（のサブセット）を更新する一時的な権利をPCEに付与することを選択できます。これは「LSP委任」と呼ばれ、初期化フェーズの後（状態同期フェーズを含む）のいつでも実行できます（MAY）。
A PCE MAY return an LSP delegation at any time if it no longer wishes to update the LSP's state. A PCC MAY revoke an LSP delegation at any time. Delegation, Revocation, and Return are done individually for each LSP.
PCEは、LSPの状態を更新する必要がなくなった場合、いつでもLSP委任を返すことができます。 PCCはいつでもLSP委任を取り消す場合があります。委任、取り消し、および返却は、LSPごとに個別に行われます。
In the event of a delegation being rejected or returned by a PCE, the PCC SHOULD react based on local policy. It can, for example, either retry delegating to the same PCE using an exponentially increasing timer or delegate to an alternate PCE.
PCEによって委任が拒否または返却された場合、PCCはローカルポリシーに基づいて対応する必要があります（SHOULD）。たとえば、指数関数的に増加するタイマーを使用して同じPCEへの委任を再試行するか、代替のPCEに委任することができます。
A PCC delegates an LSP to a PCE by setting the Delegate flag in the LSP State Report to 1. If the PCE does not accept the LSP delegation, it MUST immediately respond with an empty LSP Update Request that has the Delegate flag set to 0. If the PCE accepts the LSP delegation, it MUST set the Delegate flag to 1 when it sends an LSP Update Request for the delegated LSP (note that this may occur at a later time). The PCE MAY also immediately acknowledge a delegation by sending an empty LSP Update Request that has the Delegate flag set to 1.
PCCは、LSP状態レポートのデリゲートフラグを1に設定して、LSPをPCEに委任します。PCEがLSP委任を受け入れない場合、PCEは、デリゲートフラグが0に設定されている空のLSP更新要求でただちに応答する必要があります。 PCEがLSP委任を受け入れる場合、委任されたLSPのLSP更新要求を送信するときに、委任フラグを1に設定する必要があります（これは後で発生する可能性があることに注意してください）。 PCEは、委任フラグが1に設定されている空のLSP更新要求を送信することによって、委任をすぐに確認することもできます（MAY）。
The delegation sequence is shown in Figure 4.
委任シーケンスを図4に示します。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---PCRpt, Delegate=1--->| LSP delegated
| |
|---PCRpt, Delegate=1--->|
| . |
| . |
| . |
|<--(PCUpd,Delegate=1)---| Delegation confirmed
| |
|---PCRpt, Delegate=1--->|
| |
Figure 4: Delegating an LSP
図4：LSPの委任
Note that for an LSP to remain delegated to a PCE, the PCC MUST set the Delegate flag to 1 on each LSP State Report sent to the PCE.
LSPがPCEに委任されたままであるには、PCCがPCEに送信される各LSP状態レポートで委任フラグを1に設定する必要があることに注意してください。
When a PCC decides that a PCE is no longer permitted to modify an LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke an LSP delegation at any time during the LSP's lifetime. A PCC revoking an LSP delegation MAY immediately remove the updated parameters provided by the PCE and revert to the operator-defined parameters, but to avoid traffic loss, it SHOULD do so in a make-before-break fashion. If the PCC has received but not yet acted on PCUpd messages from the PCE for the LSP whose delegation is being revoked, then it SHOULD ignore these PCUpd messages when processing the message queue. All effects of all messages for which processing started before the revocation took place MUST be allowed to complete, and the result MUST be given the same treatment as any LSP that had been previously delegated to the PCE (e.g., the state MAY immediately revert to the operator-defined parameters).
PCEがLSPの変更を許可されなくなったとPCCが判断した場合、PCCはそのLSPのPCEへの委任を取り消します。 PCCは、LSPの有効期間中いつでもLSP委任を取り消すことができます。 LSP委任を取り消すPCCは、PCEによって提供される更新されたパラメーターをすぐに削除し、オペレーター定義のパラメーターに戻すことができますが、トラフィック損失を回避するために、make-before-breakの方法で行う必要があります。 PCCは、委任が取り消されているLSPのPCEからPCUpdメッセージを受信したがまだ処理していない場合、メッセージキューの処理時にこれらのPCUpdメッセージを無視する必要があります。失効が発生する前に処理が開始されたすべてのメッセージのすべての影響は、完了を許可する必要があり、その結果は、以前にPCEに委任されたすべてのLSPと同じ処理を与えなければなりません（たとえば、状態はすぐにオペレーター定義のパラメーター）。
If a PCEP session with the PCE to which the LSP is delegated exists in the UP state during the revocation, the PCC MUST notify that PCE by sending an LSP State Report with the Delegate flag set to 0, as shown in Figure 5.
LSPが委任されたPCEとのPCEPセッションが失効中にUP状態で存在する場合、PCCは、図5に示すように、デリゲートフラグを0に設定したLSP状態レポートを送信して、PCEに通知する必要があります。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---PCRpt, Delegate=1--->|
| |
|<--(PCUpd,Delegate=1)---| Delegation confirmed
| . |
| . |
| . |
|---PCRpt, Delegate=0--->| PCC revokes delegation
| |
Figure 5: Revoking a Delegation
図5：委任の取り消し
After an LSP delegation has been revoked, a PCE can no longer update an LSP's parameters; an attempt to update parameters of a non-delegated LSP will result in the PCC sending a PCErr message with Error-type=19 (Invalid Operation) and error-value 1 (Attempted LSP Update Request for a non-delegated LSP) (see Section 8.5).
LSP委任が取り消された後、PCEはLSPのパラメーターを更新できなくなります。委任されていないLSPのパラメーターを更新しようとすると、PCCがError-type = 19（無効な操作）およびエラー値1（委任されていないLSPに対してLSP更新要求を試みた）のPCErrメッセージを送信します（セクションを参照） 8.5）。
When a PCC's PCEP session with a PCE terminates unexpectedly, the PCC MUST wait the time interval specified in the Redelegation Timeout Interval before revoking LSP delegations to that PCE and attempting to redelegate LSPs to an alternate PCE. If a PCEP session with the original PCE can be re-established before the Redelegation Timeout Interval timer expires, LSP delegations to the PCE remain intact.
PCEとのPCCのPCEPセッションが予期せず終了した場合、PCCは、そのPCEへのLSP委任を取り消して、LSPを代替PCEに再委任する前に、再委任タイムアウト間隔で指定された時間待機する必要があります。元のPCEとのPCEPセッションが、再委任タイムアウト間隔タイマーの期限が切れる前に再確立できる場合、PCEへのLSP委任はそのまま残ります。
Likewise, when a PCC's PCEP session with a PCE terminates unexpectedly, and the PCC does not succeed in redelegating its LSPs, the PCC MUST wait for the State Timeout Interval before flushing any LSP state associated with that PCE. Note that the State Timeout Interval timer may expire before the PCC has redelegated the LSPs to another PCE, for example, if a PCC is not connected to any active stateful PCE or if no connected active stateful PCE accepts the delegation. In this case, the PCC MUST flush any LSP state set by the PCE upon expiration of the State Timeout Interval and revert to operator-defined default parameters or behaviors. This operation SHOULD be done in a make-before-break fashion.
同様に、PCEとのPCCのPCEPセッションが予期せず終了し、PCCがLSPの再委任に成功しない場合、PCCは、そのPCEに関連付けられたLSP状態をフラッシュする前に、状態タイムアウト間隔を待機する必要があります。たとえば、PCCがアクティブなステートフルPCEに接続されていない場合、または接続されているアクティブなステートフルPCEが委任を受け入れない場合など、PCCがLSPを別のPCEに再委任する前に、状態タイムアウト間隔タイマーが期限切れになる場合があります。この場合、PCCは、状態タイムアウト間隔の満了時にPCEによって設定されたすべてのLSP状態をフラッシュし、オペレーターが定義したデフォルトのパラメーターまたは動作に戻す必要があります。この操作は、make-before-breakの方法で行う必要があります（SHOULD）。
The State Timeout Interval MUST be greater than or equal to the Redelegation Timeout Interval and MAY be set to infinity (meaning that until the PCC specifically takes action to change the parameters set by the PCE, they will remain intact).
状態タイムアウト間隔は、再制限タイムアウト間隔以上でなければならず、無限に設定する必要があります（つまり、PCCがPCEによって設定されたパラメータを変更するためのアクションを実行するまで、それらはそのまま残ります）。
In order to keep a delegation, a PCE MUST set the Delegate flag to 1 on each LSP Update Request sent to the PCC. A PCE that no longer wishes to update an LSP's parameters SHOULD return the LSP delegation back to the PCC by sending an empty LSP Update Request that has the Delegate flag set to 0. If a PCC receives an LSP Update Request with the Delegate flag set to 0 (whether the LSP Update Request is empty or not), it MUST treat this as a delegation return.
委任を維持するために、PCEは、PCCに送信される各LSP更新要求で委任フラグを1に設定する必要があります。 LSPのパラメーターを更新する必要がなくなったPCEは、デリゲートフラグが0に設定されている空のLSP更新要求を送信して、LSC委任をPCCに返す必要があります。PCCがデリゲートフラグが設定されたLSP更新要求を受信した場合0（LSP更新要求が空かどうかに関係なく）、これは委任の戻りとして扱わなければなりません（MUST）。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---PCRpt, Delegate=1--->| LSP delegated
| . |
| . |
| . |
|<--PCUpd, Delegate=0----| Delegation returned
| |
|---PCRpt, Delegate=0--->| No delegation for LSP
| |
Figure 6: Returning a Delegation
図6：委任を返す
If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is not connected to any active stateful PCE or if no connected active stateful PCE accepts the delegation), the LSP delegation on the PCC will timeout within a configurable Redelegation Timeout Interval, and the PCC MUST flush any LSP state set by a PCE at the expiration of the State Timeout Interval and revert to operator-defined default parameters or behaviors.
PCCがLSPをPCEに委任できない場合（たとえば、PCCがアクティブなステートフルPCEに接続されていない場合、または接続されたアクティブなステートフルPCEが委任を受け入れない場合）、PCC上のLSP委任は構成可能な再委任タイムアウト内でタイムアウトします間隔、およびPCCは、状態タイムアウト間隔の満了時にPCEによって設定されたLSP状態をフラッシュし、オペレーターが定義したデフォルトのパラメーターまたは動作に戻す必要があります。
In a redundant configuration where one PCE is backing up another PCE, the backup PCE may have only a subset of the LSPs in the network delegated to it. The backup PCE does not update any LSPs that are not delegated to it. In order to allow the backup to operate in a hot-standby mode and avoid the need for State Synchronization in case the primary fails, the backup receives all LSP State Reports from a PCC. When the primary PCE for a given LSP set fails, after expiry of the Redelegation Timeout Interval, the PCC SHOULD delegate to the redundant PCE all LSPs that had been previously delegated to the failed PCE. Assuming that the State Timeout Interval had been configured to be greater than the Redelegation Timeout Interval (as MANDATORY), and assuming that the primary and redundant PCEs take similar decisions, this delegation change will not cause any changes to the LSP parameters.
1つのPCEが別のPCEをバックアップしている冗長構成では、バックアップPCEに委任されたネットワーク内のLSPのサブセットのみがある場合があります。バックアップPCEは、委任されていないLSPを更新しません。バックアップがホットスタンバイモードで動作できるようにして、プライマリに障害が発生した場合の状態同期の必要性を回避するために、バックアップはPCCからすべてのLSP状態レポートを受け取ります。特定のLSPセットのプライマリPCEが失敗した場合、再委任タイムアウト間隔の満了後、PCCは、以前に失敗したPCEに委任されていたすべてのLSPを冗長PCEに委任する必要があります（SHOULD）。状態タイムアウト間隔が再構成タイムアウト間隔より大きくなるように（必須として）構成されていると想定し、プライマリPCEと冗長PCEが同様の決定を行うと想定すると、この委任の変更によってLSPパラメーターが変更されることはありません。
On failure, the goal is to: 1) avoid any traffic loss on the LSPs that were updated by the PCE that crashed, 2) minimize the churn in the network in terms of ownership of the LSPs, 3) not leave any "orphan" (undelegated) LSPs, and 4) be able to control when the state that was set by the PCE can be changed or purged. The values chosen for the Redelegation Timeout and State Timeout values affect the ability to accomplish these goals.
失敗した場合の目標は、1）クラッシュしたPCEによって更新されたLSPでのトラフィック損失を回避する、2）LSPの所有権に関してネットワークのチャーンを最小限に抑える、3）「孤立」を残さないことです。 （非連結）LSP、および4）PCEによって設定された状態をいつ変更またはパージできるかを制御できます。 Redelegation TimeoutおよびState Timeoutの値として選択された値は、これらの目標を達成する機能に影響を与えます。
This section summarizes the behavior with regards to LSP delegation and LSP state on a PCE failure.
このセクションでは、PCE障害時のLSP委任とLSP状態に関する動作をまとめています。
If the PCE crashes but recovers within the Redelegation Timeout, both the delegation state and the LSP state are kept intact.
PCEがクラッシュしたが、再委任タイムアウト内に回復した場合、委任状態とLSP状態の両方がそのまま維持されます。
If the PCE crashes but does not recover within the Redelegation Timeout, the delegation state is returned to the PCC. If the PCC can redelegate the LSPs to another PCE, and that PCE accepts the delegations, there will be no change in LSP state. If the PCC cannot redelegate the LSPs to another PCE, then upon expiration of the State Timeout Interval, the state set by the PCE is removed and the LSP reverts to operator-defined parameters, which may cause a change in the LSP state. Note that an operator may choose to use an infinite State Timeout Interval if he wishes to maintain the PCE state indefinitely. Note also that flushing the state should be implemented using make-before-break to avoid traffic loss.
PCEがクラッシュしても、再委任タイムアウト内に回復しない場合、委任状態はPCCに返されます。 PCCがLSPを別のPCEに再委任でき、そのPCEが委任を受け入れる場合、LSP状態に変化はありません。 PCCがLSPを別のPCEに再委任できない場合、状態タイムアウト間隔の満了時に、PCEによって設定された状態が削除され、LSPがオペレーター定義のパラメーターに戻るため、LSP状態が変化する可能性があります。オペレーターは、PCE状態を無期限に維持したい場合は、無限状態タイムアウト間隔を使用することを選択できます。状態のフラッシュは、トラフィックの損失を避けるためにmake-before-breakを使用して実装する必要があることにも注意してください。
If there is a standby PCE, the Redelegation Timeout may be set to 0 through policy on the PCC, causing the LSPs to be redelegated immediately to the PCC, which can delegate them immediately to the standby PCE. Assuming that the PCC can redelegate the LSP to the standby PCE within the State Timeout Interval, and assuming the standby PCE takes similar decisions as the failed PCE, the LSP state will be kept intact.
スタンバイPCEが存在する場合、PCCのポリシーを使用してRedelegation Timeoutを0に設定すると、LSPがすぐにPCCに再委任され、すぐにスタンバイPCEに委任できます。 PCCがLSPを状態タイムアウト間隔内にスタンバイPCEに再委任できると想定し、スタンバイPCEが障害のあるPCEと同様の決定を行うと想定すると、LSP状態はそのまま維持されます。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
1) Path computation |----- PCReq message --->|
request sent to | |2) Path computation
PCE | | request received,
| | path computed
| |
|<---- PCRep message ----|3) Computed paths
| (Positive reply) | sent to the PCC
| (Negative reply) |
4) LSP state change | |
event | |
| |
5) LSP State Report |----- PCRpt message --->|
sent to all | . |
stateful PCEs | . |
| . |
6) Repeat for each |----- PCRpt message --->|
LSP state change | |
| |
Figure 7: Passive Stateful PCE Path Computation Request/Response
図7：パッシブステートフルPCEパス計算要求/応答
Once a PCC has successfully established a PCEP session with a passive stateful PCE and the PCC's LSP state is synchronized with the PCE (i.e., the PCE knows about all of the PCC's existing LSPs), if an event is triggered that requires the computation of a set of paths, the PCC sends a path computation request to the PCE ([RFC5440], Section 4.2.3). The PCReq message MAY contain the LSP object to identify the LSP for which the path computation is requested.
PCCがパッシブステートフルPCEとのPCEPセッションを正常に確立し、PCCのLSP状態がPCEと同期されると（つまり、PCEはPCCのすべての既存のLSPを知っている場合）、パスのセットの場合、PCCはパス計算リクエストをPCEに送信します（[RFC5440]、セクション4.2.3）。 PCReqメッセージには、パス計算が要求されているLSPを識別するためのLSPオブジェクトが含まれる場合があります。
Upon receiving a path computation request from a PCC, the PCE triggers a path computation and returns either a positive or a negative reply to the PCC ([RFC5440], Section 4.2.4).
PCCからパス計算リクエストを受信すると、PCEはパス計算をトリガーし、PCCに正または負の応答を返します（[RFC5440]、セクション4.2.4）。
Upon receiving a positive path computation reply, the PCC receives a set of computed paths and starts to set up the LSPs. For each LSP, it MAY send an LSP State Report carried on a PCRpt message to the PCE, indicating that the LSP's status is "Going-up".
肯定的なパス計算応答を受信すると、PCCは計算されたパスのセットを受信し、LSPのセットアップを開始します。 LSPごとに、PCRptメッセージで運ばれるLSP状態レポートをPCEに送信して、LSPのステータスが「Going-up」であることを示す場合があります。
Once an LSP is up or active, the PCC MUST send an LSP State Report carried on a PCRpt message to the PCE, indicating that the LSP's status is 'Up' or 'Active', respectively. If the LSP could not be set up, the PCC MUST send an LSP State Report indicating that the LSP is 'Down' and stating the cause of the failure. Note that due to timing constraints, the LSP status may change from 'Going-up' to 'Up' (or 'Down') before the PCC has had a chance to send an LSP State Report indicating that the status is 'Going-up'. In such cases, the PCC MAY choose to only send the PCRpt indicating the latest status ('Active', 'Up', or 'Down').
LSPが起動またはアクティブになると、PCCはPCRptメッセージで伝送されるLSP状態レポートをPCEに送信して、LSPのステータスがそれぞれ「アップ」または「アクティブ」であることを示す必要があります。 LSPをセットアップできなかった場合、PCCはLSPが「ダウン」であることを示し、失敗の原因を示すLSP状態レポートを送信する必要があります。タイミングの制約により、PCCがステータスが「Going-up」であることを示すLSP状態レポートを送信する機会が得られる前に、LSPステータスが「Going-up」から「Up」（または「Down」）に変わる場合があります。 '。そのような場合、PCCは、最新のステータス（「アクティブ」、「アップ」、または「ダウン」）を示すPCRptのみを送信することを選択できます（MAY）。
Upon receiving a negative reply from a PCE, a PCC MAY resend a modified request or take any other appropriate action. For each requested LSP, it SHOULD also send an LSP State Report carried on a PCRpt message to the PCE, indicating that the LSP's status is 'Down'.
PCEから否定応答を受信すると、PCCは変更された要求を再送信するか、他の適切なアクションを実行できます（MAY）。要求されたLSPごとに、PCRptメッセージで伝えられるLSP状態レポートをPCEに送信して、LSPのステータスが「ダウン」であることを示す必要があります（SHOULD）。
There is no direct correlation between PCRep and PCRpt messages. For a given LSP, multiple LSP State Reports will follow a single PCRep message, as a PCC notifies a PCE of the LSP's state changes.
PCRepメッセージとPCRptメッセージの間には直接的な相関関係はありません。 PCCがPCEにLSPの状態変化を通知するため、特定のLSPに対して、複数のLSP状態レポートが単一のPCRepメッセージに続きます。
A PCC MUST send each LSP State Report to each stateful PCE that is connected to the PCC.
PCCは、各LSP状態レポートを、PCCに接続されている各ステートフルPCEに送信する必要があります。
Note that a single PCRpt message MAY contain multiple LSP State Reports.
1つのPCRptメッセージに複数のLSP状態レポートが含まれる場合があることに注意してください。
The passive stateful model for stateful PCEs is described in [RFC4655], Section 6.8.
ステートフルPCEのパッシブステートフルモデルについては、[RFC4655]のセクション6.8で説明されています。
This section deals with the scenario of an LSP transitioning from a passive stateful to an active stateful mode of operation. When the LSP has no working path, prior to delegating the LSP, the PCC MUST first use the procedure defined in Section 5.8.1 to request the initial path from the PCE. This is required because the action of delegating the LSP to a PCE using a PCRpt message is not an explicit request to the PCE to compute a path for the LSP. The only explicit way for a PCC to request a path from the PCE is to send a PCReq message. The PCRpt message MUST NOT be used by the PCC to attempt to request a path from the PCE.
このセクションでは、LSPがパッシブステートフルモードからアクティブステートフルモードに移行するシナリオを扱います。 LSPに作業パスがない場合、LSCを委任する前に、PCCは最初にセクション5.8.1で定義された手順を使用して、PCEから初期パスを要求する必要があります。 PCRptメッセージを使用してLSPをPCEに委任するアクションは、LSPのパスを計算するためのPCEへの明示的な要求ではないため、これが必要です。 PCCがPCEからのパスを要求するための唯一の明示的な方法は、PCReqメッセージを送信することです。 PCEからのパスを要求するために、PCCがPCRptメッセージを使用してはなりません（MUST NOT）。
When the LSP is delegated after its setup, it may be useful for the PCC to communicate to the PCE the locally configured intended configuration parameters, so that the PCE may reuse them in its computations. Such parameters MAY be acquired through an out-of-band channel, or MAY be communicated in the PCRpt message delegating the LSPs, by including them as part of the intended-attribute-list as explained in Section 6.1. An implementation MAY allow policies on the PCC to determine the configuration parameters to be sent to the PCE.
LSPがセットアップ後に委任されると、PCCがローカルに構成された意図された構成パラメーターをPCEと通信して、PCEが計算でそれらを再利用できるようになると便利です。セクション6.1で説明されているように、そのようなパラメータは、アウトオブバンドチャネルを介して取得するか、LSPを委任するPCRptメッセージで、意図した属性リストの一部として含めることで通信できます。実装は、PCC上のポリシーがPCEに送信される構成パラメーターを決定することを許可する場合があります。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
1) LSP State |-- PCRpt, Delegate=1 -->|
Synchronization | . |
| . |2) PCE decides to
| . | update the LSP
| |
|<---- PCUpd message ----|3) PCUpd message sent
| | to the PCC
| |
| |
4) LSP State Report |---- PCRpt message ---->|
sent(->Going-up) | . |
| . |
| . |
5) LSP State Report |---- PCRpt message ---->|
sent (->Up|Down) | |
| |
Figure 8: Active Stateful PCE
図8：アクティブなステートフルPCE
Once a PCC has successfully established a PCEP session with an active stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e., the PCE knows about all of the PCC's existing LSPs). After LSPs have been delegated to the PCE, the PCE can modify LSP parameters of delegated LSPs.
PCCがアクティブなステートフルPCEとのPCEPセッションを正常に確立すると、PCCのLSP状態がPCEと同期されます（つまり、PCEはPCCのすべての既存のLSPを認識します）。 LSPがPCEに委任された後、PCEは委任されたLSPのLSPパラメータを変更できます。
To update an LSP, a PCE MUST send the PCC an LSP Update Request using a PCUpd message. The LSP Update Request contains a variety of objects that specify the set of constraints and attributes for the LSP's path. Each LSP Update Request MUST have a unique identifier, the SRP-ID-number, carried in the SRP object described in Section 7.2. The SRP-ID-number is used to correlate errors and state reports to LSP Update Requests. A single PCUpd message MAY contain multiple LSP Update Requests.
LSPを更新するには、PCEはPCUpdメッセージを使用してPCCにLSP更新要求を送信する必要があります。 LSP更新要求には、LSPのパスの制約と属性のセットを指定するさまざまなオブジェクトが含まれています。各LSP更新要求には、7.2で説明されているSRPオブジェクトで伝送される一意の識別子、SRP-ID-numberが必要です。 SRP-ID-numberは、エラーと状態レポートをLSP更新要求に関連付けるために使用されます。 1つのPCUpdメッセージに複数のLSP更新要求が含まれる場合があります。
Upon receiving a PCUpd message, the PCC starts to set up LSPs specified in LSP Update Requests carried in the message. For each LSP, it MAY send an LSP State Report carried on a PCRpt message to the PCE, indicating that the LSP's status is 'Going-up'. If the PCC decides that the LSP parameters proposed in the PCUpd message are unacceptable, it MUST report this error by including the LSP-ERROR-CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable parameters" in the LSP object in the PCRpt message to the PCE. Based on local policy, it MAY react further to this error by revoking the delegation. If the PCC receives a PCUpd message for an LSP object identified with a PLSP-ID that does not exist on the PCC, it MUST generate a PCErr with Error-type=19 (Invalid Operation), error-value 3, (Attempted LSP Update Request for an LSP identified by an unknown PSP-ID) (see Section 8.5).
PCUpdメッセージを受信すると、PCCはメッセージに含まれるLSP更新要求で指定されたLSPのセットアップを開始します。 LSPごとに、PCRptメッセージで運ばれるLSP状態レポートをPCEに送信して、LSPのステータスが「Going-up」であることを示す場合があります。 PCUpdメッセージで提案されたLSPパラメータが受け入れられないとPCCが判断した場合、LSPオブジェクトにLSP error-value = "Unacceptable parameters"を含むLSP-ERROR-CODE TLV（セクション7.3.3）を含めることにより、このエラーを報告する必要がありますPCEへのPCRptメッセージ内。ローカルポリシーに基づいて、委任を取り消すことにより、このエラーにさらに反応する場合があります。 PCCが、PCCに存在しないPLSP-IDで識別されたLSPオブジェクトのPCUpdメッセージを受信した場合、Error-type = 19（無効な操作）、エラー値3、（試みられたLSP更新でPCErrを生成する必要があります。不明なPSP-IDで識別されるLSPの要求）（セクション8.5を参照）。
Once an LSP is up, the PCC MUST send an LSP State Report (PCRpt message) to the PCE, indicating that the LSP's status is 'Up'. If the LSP could not be set up, the PCC MUST send an LSP State Report indicating that the LSP is 'Down' and stating the cause of the failure. A PCC MAY compress LSP State Reports to only reflect the most up to date state, as discussed in the previous section.
LSPが起動すると、PCCはLSPステータスレポート（PCRptメッセージ）をPCEに送信して、LSPのステータスが「Up」であることを示す必要があります。 LSPをセットアップできなかった場合、PCCはLSPが「ダウン」であることを示し、失敗の原因を示すLSP状態レポートを送信する必要があります。前のセクションで説明したように、PCCはLSP状態レポートを圧縮して、最新の状態のみを反映できます。
A PCC MUST send each LSP State Report to each stateful PCE that is connected to the PCC.
PCCは、各LSP状態レポートを、PCCに接続されている各ステートフルPCEに送信する必要があります。
PCErr and PCRpt messages triggered as a result of a PCUpd message MUST include the SRP-ID-number from the PCUpd. This provides correlation of requests and errors and acknowledgement of state processing. The PCC MAY compress the state when processing PCUpd. In this case, receipt of a higher SRP-ID-number implicitly acknowledges processing all the updates with a lower SRP-ID-number for the specific LSP (as per Section 7.2).
PCUpdメッセージの結果としてトリガーされるPCErrおよびPCRptメッセージには、PCUpdからのSRP-ID-numberを含める必要があります。これにより、要求とエラーの相関、および状態処理の確認が提供されます。 PCCは、PCUpdを処理するときに状態を圧縮する場合があります。この場合、大きいSRP-ID番号を受信すると、特定のLSPの小さいSRP-ID番号を持つすべての更新の処理が暗黙的に確認されます（セクション7.2による）。
A PCC MUST NOT send to any PCE a path computation request for a delegated LSP. Should the PCC decide it wants to issue a Path Computation Request on a delegated LSP, it MUST perform the Delegation Revocation procedure first.
PCCは、委任されたLSPのパス計算要求をPCEに送信してはなりません（MUST NOT）。 PCCが委任されたLSPでパス計算要求を発行することを決定した場合、PCCは最初に委任取り消し手順を実行する必要があります。
LSP protection and interaction with stateful PCE, as well as the extensions necessary to implement this functionality, will be discussed in a separate document.
LSP保護とステートフルPCEとの相互作用、およびこの機能を実装するために必要な拡張機能については、別のドキュメントで説明します。
A permanent PCEP session MUST be established between a stateful PCE and the PCC. In the case of session failure, session re-establishment MUST be re-attempted per the procedures defined in [RFC5440].
永続的なPCEPセッションは、ステートフルPCEとPCCの間に確立する必要があります。セッションが失敗した場合、[RFC5440]で定義されている手順に従って、セッションの再確立を再試行する必要があります。
As defined in [RFC5440], a PCEP message consists of a common header followed by a variable-length body made of a set of objects. For each PCEP message type, a set of rules is defined that specifies the set of objects that the message can carry.
[RFC5440]で定義されているように、PCEPメッセージは、一連のオブジェクトで構成される可変長の本体が後に続く共通ヘッダーで構成されています。 PCEPメッセージタイプごとに、メッセージが伝送できるオブジェクトのセットを指定する一連のルールが定義されます。
A Path Computation LSP State Report message (also referred to as a PCRpt message) is a PCEP message sent by a PCC to a PCE to report the current state of an LSP. A PCRpt message can carry more than one LSP State Reports. A PCC can send an LSP State Report either in response to an LSP Update Request from a PCE or asynchronously when the state of an LSP changes. The Message-Type field of the PCEP common header for the PCRpt message is 10.
パス計算LSP状態レポートメッセージ（PCRptメッセージとも呼ばれる）は、PCCからPCEに送信されてLSPの現在の状態を報告するPCEPメッセージです。 PCRptメッセージには、複数のLSP状態レポートを含めることができます。 PCCは、PCEからのLSP更新要求に応答して、またはLSPの状態が変化したときに非同期で、LSP状態レポートを送信できます。 PCRptメッセージのPCEP共通ヘッダーのMessage-Typeフィールドは10です。
The format of the PCRpt message is as follows:
PCRptメッセージの形式は次のとおりです。
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
<path>
Where:
<path>::= <intended-path>
[<actual-attribute-list><actual-path>]
<intended-attribute-list>
<actual-attribute-list>::=[<BANDWIDTH>]
[<metric-list>]
Where: <intended-path> is represented by the ERO object defined in Section 7.9 of [RFC5440].
ここで、<intended-path>は、[RFC5440]のセクション7.9で定義されているEROオブジェクトによって表されます。
<actual-attribute-list> consists of the actual computed and signaled values of the <BANDWIDTH> and <metric-lists> objects defined in [RFC5440].
<actual-attribute-list>は、[RFC5440]で定義されている<BANDWIDTH>オブジェクトと<metric-lists>オブジェクトの実際の計算値と信号値で構成されます。
<actual-path> is represented by the RRO object defined in Section 7.10 of [RFC5440].
<actual-path>は、[RFC5440]のセクション7.10で定義されたRROオブジェクトによって表されます。
<intended-attribute-list> is the attribute-list defined in Section 6.5 of [RFC5440] and extended by PCEP extensions.
<intended-attribute-list>は、[RFC5440]のセクション6.5で定義され、PCEP拡張機能によって拡張された属性リストです。
The SRP object (see Section 7.2) is OPTIONAL. If the PCRpt message is not in response to a PCupd message, the SRP object MAY be omitted.
SRPオブジェクト（セクション7.2を参照）はオプションです。 PCRptメッセージがPCupdメッセージに応答していない場合、SRPオブジェクトは省略できます。
When the PCC does not include the SRP object, the PCE MUST treat this as an SRP object with an SRP-ID-number equal to the reserved value 0x00000000. The reserved value 0x00000000 indicates that the state reported is not a result of processing a PCUpd message.
PCCにSRPオブジェクトが含まれていない場合、PCEはこれを予約済みの値0x00000000に等しいSRP-ID-numberを持つSRPオブジェクトとして処理する必要があります。予約値0x00000000は、報告された状態がPCUpdメッセージの処理の結果ではないことを示します。
If the PCRpt message is in response to a PCUpd message, the SRP object MUST be included and the value of the SRP-ID-number in the SRP object MUST be the same as that sent in the PCUpd message that triggered the state that is reported. If the PCC compressed several PCUpd messages for the same LSP by only processing the one with the highest number, then it should use the SRP-ID-number of that request. No state compression is allowed for state reporting, e.g., PCRpt messages MUST NOT be pruned from the PCC's egress queue even if subsequent operations on the same LSP have been completed before the PCRpt message has been sent to the TCP stack. The PCC MUST explicitly report state changes (including removal) for paths it manages.
PCRptメッセージがPCUpdメッセージに応答する場合、SRPオブジェクトが含まれている必要があり、SRPオブジェクトのSRP-ID-numberの値は、報告された状態をトリガーしたPCUpdメッセージで送信された値と同じである必要があります。 。 PCCが同じLSPの複数のPCUpdメッセージを圧縮する場合、最も大きい番号のメッセージのみを処理するため、その要求のSRP-ID-numberを使用する必要があります。 PCRptメッセージがTCPスタックに送信される前に同じLSPで後続の操作が完了した場合でも、状態の報告では状態圧縮は許可されません。たとえば、PCRptメッセージはPCCの出力キューからプルーニングしてはなりません（MUST NOT）。 PCCは、管理するパスの状態変更（削除を含む）を明示的に報告する必要があります。
The LSP object (see Section 7.3) is REQUIRED, and it MUST be included in each LSP State Report on the PCRpt message. If the LSP object is missing, the receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value 8 (LSP object missing).
LSPオブジェクト（セクション7.3を参照）は必須であり、PCRptメッセージの各LSP状態レポートに含める必要があります。 LSPオブジェクトが欠落している場合、受信側のPCEは、Error-type = 6（必須オブジェクトが欠落）およびエラー値8（LSPオブジェクトが欠落）のPCErrメッセージを送信する必要があります。
If the LSP transitioned to non-operational state, the PCC SHOULD include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error Code to report the error to the PCE.
LSPが非稼働状態に移行した場合、PCCはLSP-ERROR-TLV（セクション7.3.3）と関連するLSPエラーコードを含めて、PCEにエラーを報告する必要があります（SHOULD）。
The intended path, represented by the ERO object, is REQUIRED. If the ERO object is missing, the receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value 9 (ERO object missing). The ERO may be empty if the PCE does not have a path for a delegated LSP.
EROオブジェクトによって表される、意図されたパスは必須です。 EROオブジェクトが欠落している場合、受信側のPCEは、Error-type = 6（必須オブジェクトが欠落）およびエラー値9（EROオブジェクトが欠落）のPCErrメッセージを送信する必要があります。 PCEに委任されたLSPのパスがない場合、EROは空になることがあります。
The actual path, represented by the RRO object, SHOULD be included in a PCRpt by the PCC when the path is up or active, but it MAY be omitted if the path is down due to a signaling error or another failure.
RROオブジェクトによって表される実際のパスは、パスがアップまたはアクティブのときにPCCによってPCRptに含まれる必要があります（SHOULD）が、シグナリングエラーまたは別の障害のためにパスがダウンしている場合は省略できます。
The intended-attribute-list maps to the attribute-list in Section 6.5 of [RFC5440] and is used to convey the requested parameters of the LSP path. This is needed in order to support the switch from passive to active stateful PCE as described in Section 5.8.2. When included as part of the intended-attribute-list, the meaning of the BANDWIDTH object is the requested bandwidth as intended by the operator. In this case, the BANDWIDTH Object-Type of 1 SHOULD be used. Similarly, to indicate a limiting constraint, the METRIC object SHOULD be included as part of the intended-attribute-list with the B flag set and with a specific metric value. To indicate the optimization metric, the METRIC object SHOULD be included as part of the intended-attribute-list with the B flag unset and the metric value set to zero. Note that the intended-attribute-list is optional and thus may be omitted. In this case, the PCE MAY use the values in the actual-attribute-list as the requested parameters for the path.
意図した属性リストは、[RFC5440]のセクション6.5の属性リストにマッピングされ、LSPパスの要求されたパラメーターを伝達するために使用されます。これは、セクション5.8.2で説明されているように、パッシブからアクティブステートフルPCEへの切り替えをサポートするために必要です。意図した属性リストの一部として含まれている場合、BANDWIDTHオブジェクトの意味は、オペレーターが意図した要求帯域幅です。この場合、BANDWIDTHオブジェクトタイプ1を使用する必要があります（SHOULD）。同様に、制限の制約を示すために、METRICオブジェクトは、Bフラグが設定され、特定のメトリック値を持つ意図された属性リストの一部として含まれる必要があります（SHOULD）。最適化メトリックを示すために、METRICオブジェクトは、Bフラグを設定せず、メトリック値をゼロに設定して、意図した属性リストの一部として含める必要があります（SHOULD）。 desired-attribute-listはオプションであるため、省略できることに注意してください。この場合、PCEは、パスの要求パラメーターとしてactual-attribute-listの値を使用できます（MAY）。
The actual-attribute-list consists of the actual computed and signaled values of the BANDWIDTH and METRIC objects defined in [RFC5440]. When included as part of the actual-attribute-list, Object-Type 2 [RFC5440] SHOULD be used for the BANDWIDTH object, and the C flag SHOULD be set in the METRIC object [RFC5440].
actual-attribute-listは、[RFC5440]で定義されているBANDWIDTHオブジェクトとMETRICオブジェクトの実際に計算されて通知された値で構成されます。 actual-attribute-listの一部として含まれる場合、BANDWIDTHオブジェクトにはObject-Type 2 [RFC5440]を使用する必要があり（SHOULD）、METRICオブジェクト[RFC5440]にCフラグを設定する必要があります（SHOULD）。
Note that the ordering of intended-path, actual-attribute-list, actual-path, and intended-attribute-list is chosen to retain compatibility with implementations of an earlier version of this standard.
意図されたパス、実際の属性リスト、実際のパス、意図された属性リストの順序は、この標準の以前のバージョンの実装との互換性を維持するために選択されていることに注意してください。
A PCE may choose to implement a limit on the resources a single PCC can occupy. If a PCRpt is received that causes the PCE to exceed this limit, the PCE MUST notify the PCC using a PCNtf message with Notification Type 4 (Stateful PCE resource limit exceeded) and Notification Value 1 (Entering resource limit exceeded state), and it MUST terminate the session.
PCEは、単一のPCCが占有できるリソースに制限を実装することを選択できます。 PCEがこの制限を超える原因となるPCRptを受信した場合、PCEは通知タイプ4（ステートフルPCEリソース制限を超えた）および通知値1（リソース制限を超えた状態に入った）を含むPCNtfメッセージを使用してPCCに通知する必要があり、セッションを終了します。
A Path Computation LSP Update Request message (also referred to as PCUpd message) is a PCEP message sent by a PCE to a PCC to update attributes of an LSP. A PCUpd message can carry more than one LSP Update Request. The Message-Type field of the PCEP common header for the PCUpd message is 11.
パス計算LSP更新要求メッセージ（PCUpdメッセージとも呼ばれる）は、PCEからPCCに送信されてLSPの属性を更新するPCEPメッセージです。 PCUpdメッセージは、複数のLSP更新要求を運ぶことができます。 PCUpdメッセージのPCEP共通ヘッダーのMessage-Typeフィールドは11です。
The format of a PCUpd message is as follows:
PCUpdメッセージの形式は次のとおりです。
<PCUpd Message> ::= <Common Header>
<update-request-list>
Where:
<update-request-list> ::= <update-request>[<update-request-list>]
<update-request> ::= <SRP>
<LSP>
<path>
Where:
<path>::= <intended-path><intended-attribute-list>
Where: <intended-path> is represented by the ERO object defined in Section 7.9 of [RFC5440].
ここで、<intended-path>は、[RFC5440]のセクション7.9で定義されているEROオブジェクトによって表されます。
<intended-attribute-list> is the attribute-list defined in [RFC5440] and extended by PCEP extensions.
<intended-attribute-list>は、[RFC5440]で定義され、PCEP拡張機能によって拡張された属性リストです。
There are three mandatory objects that MUST be included within each LSP Update Request in the PCUpd message: the SRP object (see Section 7.2), the LSP object (see Section 7.3) and the ERO object (as defined in [RFC5440], which represents the intended path. If the SRP object is missing, the receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=10 (SRP object missing). If the LSP object is missing, the receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=8 (LSP object missing). If the ERO object is missing, the receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=9 (ERO object missing).
PCUpdメッセージの各LSP更新要求に含める必要がある3つの必須オブジェクトがあります。SRPオブジェクト（セクション7.2を参照）、LSPオブジェクト（セクション7.3を参照）、およびEROオブジェクト（[RFC5440]で定義）は、目的のパス。SRPオブジェクトが見つからない場合、受信側のPCCは、Error-type = 6（必須オブジェクトが見つからない）およびError-value = 10（SRPオブジェクトが見つからない）のPCErrメッセージを送信する必要があります。LSPオブジェクトが見つからない場合、受信PCCは、Error-type = 6（Mandatory Object missing）およびError-value = 8（LSP object missing）のPCErrメッセージを送信する必要があります。EROオブジェクトがない場合、受信PCCはError-type =のPCErrメッセージを送信する必要があります。 6（必須オブジェクトがありません）およびError-value = 9（EROオブジェクトがありません）。
The ERO in the PCUpd may be empty if the PCE cannot find a valid path for a delegated LSP. One typical situation resulting in this empty ERO carried in the PCUpd message is that a PCE can no longer find a strict SRLG-disjoint path for a delegated LSP after a link failure. The PCC SHOULD implement a local policy to decide the appropriate action to be taken: either tear down the LSP or revoke the delegation and use a locally computed path, or keep the existing LSP.
PCEが委任されたLSPの有効なパスを見つけられない場合、PCUpdのEROは空になることがあります。 PCUpdメッセージでこの空のEROが運ばれる典型的な状況の1つは、リンク障害が発生した後、PCEが委任されたLSPの厳密なSRLGディスジョイントパスを見つけられなくなったことです。 PCCは、LSPを破棄するか、委任を取り消してローカルで計算されたパスを使用するか、既存のLSPを維持するか、適切なアクションを決定するローカルポリシーを実装する必要があります（SHOULD）。
A PCC only acts on an LSP Update Request if permitted by the local policy configured by the network manager. Each LSP Update Request that the PCC acts on results in an LSP setup operation. An LSP Update Request MUST contain all LSP parameters that a PCE wishes to be set for the LSP. A PCC MAY set missing parameters from locally configured defaults. If the LSP specified in the Update Request is already up, it will be re-signaled.
PCCは、ネットワークマネージャーによって構成されたローカルポリシーで許可されている場合にのみ、LSP更新要求に作用します。 PCCが作用する各LSP更新要求は、LSPセットアップ操作になります。 LSP更新要求には、PCEがLSPに設定したいすべてのLSPパラメータが含まれている必要があります。 PCCは、ローカルに構成されたデフォルトから欠落しているパラメーターを設定する場合があります。更新リクエストで指定されたLSPがすでに起動している場合は、再シグナリングされます。
The PCC SHOULD minimize the traffic interruption and MAY use the make-before-break procedures described in [RFC3209] in order to achieve this goal. If the make-before-break procedures are used, two paths will briefly coexist. The PCC MUST send separate PCRpt messages for each, identified by the LSP-IDENTIFIERS TLV. When the old path is torn down after the head end switches over the traffic, this event MUST be reported by sending a PCRpt message with the LSP-IDENTIFIERS-TLV of the old path and the R bit set. The SRP-ID-number that the PCC associates with this PCRpt MUST be 0x00000000. Thus, a make-before-break operation will typically result in at least two PCRpt messages, one for the new path and one for the removal of the old path (more messages may be possible if intermediate states are reported).
PCCはトラフィックの中断を最小限に抑え、この目標を達成するために[RFC3209]で説明されているmake-before-break手順を使用する必要があります（SHOULD）。 make-before-break手順を使用すると、2つのパスが一時的に共存します。 PCCは、LSP-IDENTIFIERS TLVによって識別されるそれぞれに対して個別のPCRptメッセージを送信する必要があります。ヘッドエンドがトラフィックを切り替えた後に古いパスが切断された場合、このイベントは、古いパスのLSP-IDENTIFIERS-TLVとRビットが設定されたPCRptメッセージを送信することによって報告する必要があります。 PCCがこのPCRptに関連付けるSRP-ID-numberは0x00000000でなければなりません。したがって、make-before-break操作では、通常、少なくとも2つのPCRptメッセージが生成されます。1つは新しいパス用で、もう1つは古いパスの削除用です（中間状態が報告されている場合は、さらにメッセージが表示される可能性があります）。
If the path setup fails due to an RSVP signaling error, the error is reported to the PCE. The PCC will not attempt to re-signal the path until it is prompted again by the PCE with a subsequent PCUpd message.
RSVPシグナリングエラーが原因でパスのセットアップが失敗した場合、エラーはPCEに報告されます。 PCCは、後続のPCUpdメッセージでPCEによって再度プロンプトが出されるまで、パスの再シグナリングを試みません。
A PCC MUST respond with an LSP State Report to each LSP Update Request it processed to indicate the resulting state of the LSP in the network (even if this processing did not result in changing the state of the LSP). The SRP-ID-number included in the PCRpt MUST match that in the PCUpd. A PCC MAY respond with multiple LSP State Reports to report LSP setup progress of a single LSP. In that case, the SRP-ID-number MUST be included for the first message; for subsequent messages, the reserved value 0x00000000 SHOULD be used.
PCCは、ネットワーク内のLSPの結果の状態を示すために処理した各LSP更新要求にLSP状態レポートで応答する必要があります（この処理の結果、LSPの状態が変化しなかった場合でも）。 PCRptに含まれるSRP-ID-numberは、PCUpdのSRP-ID-numberと一致する必要があります。 PCCは、複数のLSP状態レポートで応答して、単一のLSPのLSPセットアップの進行状況を報告できます。その場合、最初のメッセージにはSRP-ID-numberを含める必要があります。後続のメッセージでは、予約値0x00000000を使用する必要があります（SHOULD）。
Note that a PCC MUST process all LSP Update Requests -- for example, an LSP Update Request is sent when a PCE returns delegation or puts an LSP into non-operational state. The protocol relies on TCP for message-level flow control.
PCCはすべてのLSP更新要求を処理する必要があることに注意してください。たとえば、PCEが委任を返すか、LSPを非動作状態にすると、LSP更新要求が送信されます。プロトコルは、メッセージレベルのフロー制御をTCPに依存しています。
If the rate of PCUpd messages sent to a PCC for the same target LSP exceeds the rate at which the PCC can signal LSPs into the network, the PCC MAY perform state compression on its ingress queue. The compression algorithm is based on the fact that each PCUpd request contains the complete LSP state the PCE wishes to be set and works as follows: when the PCC starts processing a PCUpd message at the head of its ingress queue, it may search the queue forward for more recent PCUpd messages pertaining to that particular LSP, prune all but the latest one from the queue, and process only the last one as that request contains the most up-to-date desired state for the LSP. The PCC MUST NOT send PCRpt nor PCErr messages for requests that were pruned from the queue in this way. This compression step may be performed only while the LSP is not being signaled, e.g., if two PCUpd arrive for the same LSP in quick succession and the PCC started the signaling of the changes relevant to the first PCUpd, then it MUST wait until the signaling finishes (and report the new state via a PCRpt) before attempting to apply the changes indicated in the second PCUpd.
同じターゲットLSPのPCCに送信されるPCUpdメッセージのレートが、PCCがLSPをネットワークにシグナリングできるレートを超える場合、PCCはその入力キューで状態圧縮を実行できます（MAY）。圧縮アルゴリズムは、各PCUpd要求にPCEの設定を希望する完全なLSP状態が含まれ、次のように機能するという事実に基づいています。PCCが入力キューの先頭でPCUpdメッセージの処理を開始すると、順方向にキューを検索します。その特定のLSPに関連するより最近のPCUpdメッセージの場合、最新のものを除くすべてをキューからプルーニングし、その要求にLSPの最新の望ましい状態が含まれているため、最後のメッセージのみを処理します。 PCCは、このようにキューからプルーニングされた要求に対してPCRptまたはPCErrメッセージを送信してはなりません（MUST NOT）。この圧縮ステップは、LSPがシグナリングされていないときにのみ実行できます。たとえば、2つのPCUpdが同じLSPにすばやく連続して到着し、PCCが最初のPCUpdに関連する変更のシグナリングを開始した場合、シグナリングまで待機する必要があります。 2番目のPCUpdで示された変更を適用しようとする前に終了します（そしてPCRptを介して新しい状態を報告します）。
Note also that it is up to the PCE to handle inter-LSP dependencies; for example, if ordering of LSP setups is required, the PCE has to wait for an LSP State Report for a previous LSP before starting the update of the next LSP.
LSP間の依存関係を処理するのはPCE次第であることにも注意してください。たとえば、LSPセットアップの注文が必要な場合、PCEは次のLSPの更新を開始する前に、前のLSPのLSP状態レポートを待機する必要があります。
If the PCUpd cannot be satisfied (for example, due to an unsupported object or a TLV), the PCC MUST respond with a PCErr message indicating the failure (see Section 7.3.3).
PCUpdが満足できない場合（たとえば、サポートされていないオブジェクトまたはTLVが原因で）、PCCは失敗を示すPCErrメッセージで応答する必要があります（セクション7.3.3を参照）。
If the stateful PCE capability has been advertised on the PCEP session, the PCErr message MAY include the SRP object. If the error reported is the result of an LSP Update Request, then the SRP-ID-number MUST be the one from the PCUpd that triggered the error. If the error is unsolicited, the SRP object MAY be omitted. This is equivalent to including an SRP object with the SRP-ID-number equal to the reserved value 0x00000000.
ステートフルPCE機能がPCEPセッションでアドバタイズされている場合、PCErrメッセージにはSRPオブジェクトが含まれる場合があります。報告されたエラーがLSP更新要求の結果である場合、SRP-ID-numberは、エラーをトリガーしたPCUpdからのものである必要があります。エラーが未承諾の場合、SRPオブジェクトは省略できます。これは、予約済みの値0x00000000に等しいSRP-ID-numberを持つSRPオブジェクトを含めることと同じです。
The format of a PCErr message from [RFC5440] is extended as follows:
[RFC5440]からのPCErrメッセージのフォーマットは、次のように拡張されています。
<PCErr Message> ::= <Common Header>
( <error-obj-list> [<Open>] ) | <error>
[<error-list>]
<error-obj-list>::=<PCEP-ERROR>[<error-obj-list>]
<error>::=[<request-id-list> | <stateful-request-id-list>]
<error-obj-list>
<request-id-list>::=<RP>[<request-id-list>]
<stateful-request-id-list>::=<SRP>[<stateful-request-id-list>]
<error-list>::=<error>[<error-list>]
A PCC MAY include the LSP object in the PCReq message (see Section 7.3) if the stateful PCE capability has been negotiated on a PCEP session between the PCC and a PCE.
PCCとPCE間のPCEPセッションでステートフルPCE機能がネゴシエートされている場合、PCCはPCReqメッセージ（セクション7.3を参照）にLSPオブジェクトを含めることができます（MAY）。
The definition of the PCReq message from [RFC5440] is extended to optionally include the LSP object after the END-POINTS object. The encoding from [RFC5440] will become:
[RFC5440]からのPCReqメッセージの定義は、オプションでEND-POINTSオブジェクトの後にLSPオブジェクトを含めるように拡張されています。 [RFC5440]からのエンコーディングは次のようになります。
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
Where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSP>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
A PCE MAY include the LSP object in the PCRep message (see Section 7.3) if the stateful PCE capability has been negotiated on a PCEP session between the PCC, and the PCE and the LSP object were included in the corresponding PCReq message from the PCC.
PCC間のPCEPセッションでステートフルPCE機能がネゴシエートされ、PCEとLSPオブジェクトがPCCからの対応するPCReqメッセージに含まれていた場合、PCEはPCRepメッセージ（セクション7.3を参照）にLSPオブジェクトを含めることができます。
The definition of the PCRep message from [RFC5440] is extended to optionally include the LSP object after the Request Parameter (RP) object. The encoding from [RFC5440] will become:
[RFC5440]からのPCRepメッセージの定義は、リクエストパラメータ（RP）オブジェクトの後にLSPオブジェクトをオプションで含めるように拡張されています。 [RFC5440]からのエンコーディングは次のようになります。
<PCRep Message> ::= <Common Header>
<response-list>
Where:
ただし：
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<LSP>]
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
The PCEP objects defined in this document are compliant with the PCEP object format defined in [RFC5440]. The P and I flags of the PCEP objects defined in the current document MUST be set to 0 on transmission and SHOULD be ignored on receipt since they are exclusively related to path computation requests.
このドキュメントで定義されているPCEPオブジェクトは、[RFC5440]で定義されているPCEPオブジェクト形式に準拠しています。現在のドキュメントで定義されているPCEPオブジェクトのPフラグとIフラグは、送信時に0に設定する必要があり、パス計算要求にのみ関連しているため、受信時に無視する必要があります。
This document defines one new optional TLV for use in the OPEN object.
このドキュメントでは、OPENオブジェクトで使用する1つの新しいオプションのTLVを定義します。
The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the OPEN object for stateful PCE capability advertisement. Its format is shown in the following figure:
STATEFUL-PCE-CAPABILITY TLVは、ステートフルPCE機能アドバタイズのOPENオブジェクトで使用するオプションのTLVです。そのフォーマットを次の図に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=16 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: STATEFUL-PCE-CAPABILITY TLV Format
図9：STATEFUL-PCE-CAPABILITY TLV形式
The type (16 bits) of the TLV is 16. The length field is 16 bits long and has a fixed value of 4.
TLVのタイプ（16ビット）は16です。長さフィールドは16ビット長で、固定値は4です。
The value comprises a single field -- Flags (32 bits):
値は単一のフィールドで構成されています-フラグ（32ビット）：
U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U flag indicates that the PCC allows modification of LSP parameters; if set to 1 by a PCE, the U flag indicates that the PCE is capable of updating LSP parameters. The LSP-UPDATE-CAPABILITY flag must be advertised by both a PCC and a PCE for PCUpd messages to be allowed on a PCEP session.
U（LSP-UPDATE-CAPABILITY-1ビット）：PCCによって1に設定されている場合、UフラグはPCCがLSPパラメーターの変更を許可することを示します。 PCEによって1に設定されている場合、Uフラグは、PCEがLSPパラメータを更新できることを示します。 PCEPセッションでPCUpdメッセージを許可するには、LSC-UPDATE-CAPABILITYフラグをPCCとPCEの両方で通知する必要があります。
Unassigned bits are considered reserved. They MUST be set to 0 on transmission and MUST be ignored on receipt.
割り当てられていないビットは予約済みと見なされます。送信時には0に設定し、受信時には無視する必要があります。
A PCEP speaker operating in passive stateful PCE mode advertises the stateful PCE capability with the U flag set to 0. A PCEP speaker operating in active stateful PCE mode advertises the stateful PCE capability with the U flag set to 1.
パッシブステートフルPCEモードで動作するPCEPスピーカーは、Uフラグを0に設定してステートフルPCE機能をアドバタイズします。アクティブステートフルPCEモードで動作するPCEPスピーカーは、Uフラグを1に設定してステートフルPCE機能をアドバタイズします。
Advertisement of the stateful PCE capability implies support of LSPs that are signaled via RSVP, as well as the objects, TLVs, and procedures defined in this document.
ステートフルPCE機能のアドバタイズは、このドキュメントで定義されているオブジェクト、TLV、およびプロシージャだけでなく、RSVPを介して通知されるLSPのサポートを意味します。
The SRP (Stateful PCE Request Parameters) object MUST be carried within PCUpd messages and MAY be carried within PCRpt and PCErr messages. The SRP object is used to correlate between update requests sent by the PCE and the error reports and state reports sent by the PCC.
SRP（ステートフルPCE要求パラメーター）オブジェクトはPCUpdメッセージ内で運ばれなければならず（MUST）、PCRptおよびPCErrメッセージ内で運ばれてもよい（MAY）。 SRPオブジェクトは、PCEによって送信された更新要求と、PCCによって送信されたエラーレポートおよび状態レポートを関連付けるために使用されます。
SRP Object-Class is 33.
SRPオブジェクトクラスは33です。
SRP Object-Type is 1.
SRP Object-Typeは1です。
The format of the SRP object body is shown in Figure 10:
SRPオブジェクト本体のフォーマットを図10に示します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: The SRP Object Format
図10：SRPオブジェクト形式
The SRP object body has a variable length and may contain additional TLVs.
SRPオブジェクト本体は可変長であり、追加のTLVが含まれる場合があります。
Flags (32 bits): None defined yet.
フラグ（32ビット）：まだ定義されていません。
SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the current PCEP session uniquely identifies the operation that the PCE has requested the PCC to perform on a given LSP. The SRP-ID-number is incremented each time a new request is sent to the PCC, and it may wrap around.
SRP-ID-number（32ビット）：現在のPCEPセッションのスコープ内のSRP-ID-number値は、PCEが特定のLSPでPCCに実行するように要求した操作を一意に識別します。 SRP-ID-numberは、新しい要求がPCCに送信されるたびに増分され、ラップアラウンドする場合があります。
The values 0x00000000 and 0xFFFFFFFF are reserved.
値0x00000000および0xFFFFFFFFは予約されています。
Optional TLVs MAY be included within the SRP object body. The specification of such TLVs is outside the scope of this document.
オプションのTLVがSRPオブジェクト本体に含まれる場合があります。そのようなTLVの仕様は、このドキュメントの範囲外です。
Every request to update an LSP receives a new SRP-ID-number. This number is unique per PCEP session and is incremented each time an operation is requested from the PCE. Thus, for a given LSP, there may be more than one SRP-ID-number unacknowledged at a given time. The value of the SRP-ID-number is echoed back by the PCC in PCErr and PCRpt messages to allow for correlation between requests made by the PCE and errors or state reports generated by the PCC. If the error or report was not a result of a PCE operation (for example, in the case of a link down event), the reserved value of 0x00000000 is used for the SRP-ID-number. The absence of the SRP object is equivalent to an SRP object with the reserved value of 0x00000000. An SRP-ID-number is considered unacknowledged and cannot be reused until a PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the same LSP. In case of SRP-ID-number wrapping, the last SRP-ID-number before the wrapping MUST be explicitly acknowledged, to avoid a situation where SRP-ID-numbers remain unacknowledged after the wrap. This means that the PCC may need to issue two PCUpd messages on detecting a wrap.
LSPを更新するすべての要求は、新しいSRP-ID-numberを受け取ります。この番号はPCEPセッションごとに一意であり、PCEから操作が要求されるたびに増分されます。したがって、特定のLSPの場合、特定の時点で未確認のSRP-ID番号が複数存在する場合があります。 SRP-ID-numberの値は、PCEによってPCErrおよびPCRptメッセージでエコーバックされ、PCEによって行われた要求とPCCによって生成されたエラーまたは状態レポートとの相関を可能にします。エラーまたはレポートがPCE操作の結果ではなかった場合（たとえば、リンクダウンイベントの場合）、予約された値0x00000000がSRP-ID-numberに使用されます。 SRPオブジェクトがないことは、予約値が0x00000000のSRPオブジェクトと同等です。 SRP-ID番号は未確認と見なされ、PCErrまたはPCRptが同じLSPのSRP-ID番号以上で到着するまで再利用できません。 SRP-ID番号のラップの場合、ラップ後にSRP-ID番号が未確認のままになる状況を回避するために、ラッピング前の最後のSRP-ID番号を明示的に確認する必要があります。これは、PCCがラップの検出時に2つのPCUpdメッセージを発行する必要があることを意味します。
The LSP object MUST be present within PCRpt and PCUpd messages. The LSP object MAY be carried within PCReq and PCRep messages if the stateful PCE capability has been negotiated on the session. The LSP object contains a set of fields used to specify the target LSP, the operation to be performed on the LSP, and LSP delegation. It also contains a flag indicating to a PCE that the LSP State Synchronization is in progress. This document focuses on LSPs that are signaled with RSVP; many of the TLVs used with the LSP object mirror RSVP state.
LSPオブジェクトはPCRptおよびPCUpdメッセージ内に存在する必要があります。セッションでステートフルPCE機能がネゴシエートされている場合、LSPオブジェクトはPCReqおよびPCRepメッセージ内で運ばれる場合があります。 LSPオブジェクトには、ターゲットLSP、LSPで実行される操作、およびLSP委任を指定するために使用される一連のフィールドが含まれています。また、LSP状態同期が進行中であることをPCEに示すフラグも含まれています。このドキュメントでは、RSVPで通知されるLSPに焦点を当てています。 LSPオブジェクトで使用されるTLVの多くは、RSVP状態をミラーリングします。
LSP Object-Class is 32.
LSPオブジェクトクラスは32です。
LSP Object-Type is 1.
LSPオブジェクトタイプは1です。
The format of the LSP object body is shown in Figure 11:
LSPオブジェクト本体のフォーマットを図11に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLSP-ID | Flag | O |A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: The LSP Object Format
図11：LSPオブジェクト形式
PLSP-ID (20 bits): A PCEP-specific identifier for the LSP. A PCC creates a unique PLSP-ID for each LSP that is constant for the lifetime of a PCEP session. The PCC will advertise the same PLSP-ID on all PCEP sessions it maintains at a given time. The mapping of the symbolic path name to PLSP-ID is communicated to the PCE by sending a PCRpt message containing the SYMBOLIC-PATH-NAME TLV. All subsequent PCEP messages then address the LSP by the PLSP-ID. The values of 0 and 0xFFFFF are reserved. Note that the PLSP-ID is a value that is constant for the lifetime of the PCEP session, during which time for an RSVP-signaled LSP there might be different RSVP identifiers (LSP-id, tunnel-id) allocated to it.
PLSP-ID（20ビット）：LSPのPCEP固有の識別子。 PCCは、PCEPセッションの存続期間中一定である各LSPに対して一意のPLSP-IDを作成します。 PCCは、所定の時間に維持するすべてのPCEPセッションで同じPLSP-IDを通知します。 PLSP-IDへのシンボリックパス名のマッピングは、SYMBOLIC-PATH-NAME TLVを含むPCRptメッセージを送信することにより、PCEに伝達されます。その後のすべてのPCEPメッセージは、PLSP-IDによってLSPをアドレス指定します。 0および0xFFFFFの値は予約されています。 PLSP-IDは、PCEPセッションの存続期間中一定である値であることに注意してください。その間、RSVPシグナルのLSPには、異なるRSVP識別子（LSP-id、tunnel-id）が割り当てられる可能性があります。
Flags (12 bits), starting from the least significant bit:
最下位ビットから始まるフラグ（12ビット）：
D (Delegate - 1 bit): On a PCRpt message, the D flag set to 1 indicates that the PCC is delegating the LSP to the PCE. On a PCUpd message, the D flag set to 1 indicates that the PCE is confirming the LSP delegation. To keep an LSP delegated to the PCE, the PCC must set the D flag to 1 on each PCRpt message for the duration of the delegation -- the first PCRpt with the D flag set to 0 revokes the delegation. To keep the delegation, the PCE must set the D flag to 1 on each PCUpd message for the duration of the delegation -- the first PCUpd with the D flag set to 0 returns the delegation.
D（デリゲート-1ビット）：PCRptメッセージで、1に設定されたDフラグは、PCCがLSPをPCEに委任していることを示します。 PCUpdメッセージで、1に設定されたDフラグは、PCEがLSP委任を確認していることを示します。 LSPをPCEに委任したままにするために、PCCは委任の期間中、各PCRptメッセージのDフラグを1に設定する必要があります。Dフラグが0に設定された最初のPCRptは委任を取り消します。委任を維持するには、PCEは委任の期間中、各PCUpdメッセージのDフラグを1に設定する必要があります。Dフラグが0に設定された最初のPCUpdは委任を返します。
S (SYNC - 1 bit): The S flag MUST be set to 1 on each PCRpt sent from a PCC during State Synchronization. The S flag MUST be set to 0 in other messages sent from the PCC. When sending a PCUpd message, the PCE MUST set the S flag to 0.
S（SYNC-1ビット）：状態同期中にPCCから送信される各PCRptでSフラグを1に設定する必要があります。 PCCから送信される他のメッセージでは、Sフラグを0に設定する必要があります。 PCUpdメッセージを送信する場合、PCEはSフラグを0に設定する必要があります。
R (Remove - 1 bit): On PCRpt messages, the R flag indicates that the LSP has been removed from the PCC and the PCE SHOULD remove all state from its database. Upon receiving an LSP State Report with the R flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD remove all state for the path identified by the LSP-IDENTIFIERS TLV from its database. When the all-zeros LSP-IDENTIFIERS TLV is used, the PCE SHOULD remove all state for the PLSP-ID from its database. When sending a PCUpd message, the PCE MUST set the R flag to 0.
R（削除-1ビット）：PCRptメッセージでは、RフラグはLSPがPCCから削除されたことを示し、PCEはデータベースからすべての状態を削除する必要があります（SHOULD）。 RSVP信号のLSPのRフラグが1に設定されたLSP状態レポートを受信すると、PCEはLSP-IDENTIFIERS TLVによって識別されたパスのすべての状態をデータベースから削除する必要があります（SHOULD）。すべてゼロのLSP-IDENTIFIERS TLVを使用する場合、PCEはPLSP-IDのすべての状態をデータベースから削除する必要があります（SHOULD）。 PCUpdメッセージを送信する場合、PCEはRフラグを0に設定する必要があります。
A (Administrative - 1 bit): On PCRpt messages, the A flag indicates the PCC's target operational status for this LSP. On PCUpd messages, the A flag indicates the LSP status that the PCE desires for this LSP. In both cases, a value of '1' means that the desired operational state is active, and a value of '0' means that the desired operational state is inactive. A PCC ignores the A flag on a PCUpd message unless the operator's policy allows the PCE to control the corresponding LSP's administrative state.
A（管理-1ビット）：PCRptメッセージでは、AフラグはこのLSPに対するPCCのターゲット動作ステータスを示します。 PCUpdメッセージでは、Aフラグは、PCEがこのLSPに要求するLSPステータスを示します。どちらの場合も、値「1」は目的の動作状態がアクティブであることを意味し、値「0」は目的の動作状態が非アクティブであることを意味します。 PCCは、オペレーターのポリシーでPCEが対応するLSPの管理状態を制御することを許可しない限り、PCUpdメッセージのAフラグを無視します。
O (Operational - 3 bits): On PCRpt messages, the O field represents the operational status of the LSP.
O（運用-3ビット）：PCRptメッセージでは、OフィールドはLSPの運用ステータスを表します。
The following values are defined:
以下の値が定義されています。
0 - DOWN: not active.
0-DOWN：非アクティブ。
1 - UP: signaled.
1-UP：通知されました。
2 - ACTIVE: up and carrying traffic.
2-アクティブ：稼働中のトラフィック。
3 - GOING-DOWN: LSP is being torn down, and resources are being released.
3-GOING-DOWN：LSPが破棄され、リソースが解放されています。
4 - GOING-UP: LSP is being signaled.
4-GOING-UP：LSPが通知されています。
5-7 - Reserved: these values are reserved for future use.
5-7-予約済み：これらの値は将来の使用のために予約されています。
Unassigned bits are reserved for future uses. They MUST be set to 0 on transmission and MUST be ignored on receipt. When sending a PCUpd message, the PCE MUST set the O field to 0.
割り当てられていないビットは、将来の使用のために予約されています。送信時には0に設定し、受信時には無視する必要があります。 PCUpdメッセージを送信する場合、PCEはOフィールドを0に設定する必要があります。
TLVs that may be included in the LSP object are described in the following sections. Other optional TLVs, that are not defined in this document, MAY also be included within the LSP object body.
LSPオブジェクトに含めることができるTLVについては、次のセクションで説明します。このドキュメントで定義されていないその他のオプションのTLVも、LSPオブジェクト本体に含めることができます。
The LSP-IDENTIFIERS TLV MUST be included in the LSP object in PCRpt messages for RSVP-signaled LSPs. If the TLV is missing, the PCE will generate an error with Error-type=6 (Mandatory Object missing) and error-value 11 (LSP-IDENTIFIERS TLV missing) and close the session. The LSP-IDENTIFIERS TLV MAY be included in the LSP object in PCUpd messages for RSVP-signaled LSPs. The special value of all zeros for this TLV is used to refer to all paths pertaining to a particular PLSP-ID. There are two LSP-IDENTIFIERS TLVs, one for IPv4 and one for IPv6.
LSP-IDENTIFIERS TLVは、RSVPシグナリングLSPのPCRptメッセージのLSPオブジェクトに含める必要があります。 TLVが欠落している場合、PCEはError-type = 6（必須オブジェクト欠落）およびエラー値11（LSP-IDENTIFIERS TLV欠落）のエラーを生成し、セッションを閉じます。 LSP-IDENTIFIERS TLVは、RSVPシグナリングLSPのPCUpdメッセージのLSPオブジェクトに含めることができます。このTLVのすべてゼロの特別な値は、特定のPLSP-IDに関連するすべてのパスを参照するために使用されます。 LSP-IDENTIFIERS TLVは2つあり、1つはIPv4用、もう1つはIPv6用です。
It is the responsibility of the PCC to send to the PCE the identifiers for each RSVP incarnation of the tunnel. For example, in a make-before-break scenario, the PCC MUST send a separate PCRpt for the old and reoptimized paths and explicitly report removal of any of these paths using the R bit in the LSP object.
トンネルの各RSVPインカネーションの識別子をPCEに送信するのは、PCCの責任です。たとえば、make-before-breakシナリオでは、PCCは古い再最適化されたパスに対して個別のPCRptを送信し、LSPオブジェクトのRビットを使用してこれらのパスの削除を明示的に報告する必要があります。
The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following figure:
IPV4-LSP-IDENTIFIERS TLVのフォーマットを次の図に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=18 | Length=16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Endpoint Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: IPV4-LSP-IDENTIFIERS TLV Format
図12：IPV4-LSP-IDENTIFIERS TLV形式
The type (16 bits) of the TLV is 18. The length field is 16 bits long and has a fixed value of 16. The value contains the following fields:
TLVのタイプ（16ビット）は18です。長さフィールドは16ビット長で、固定値は16です。値には次のフィールドが含まれます。
IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, as defined in [RFC3209], Section 4.6.2.1, for the LSP_TUNNEL_IPv4 Sender Template Object.
IPv4トンネル送信者アドレス：[RFC3209]のセクション4.6.2.1で定義されているLSP_TUNNEL_IPv4送信者テンプレートオブジェクトの送信者ノードのIPv4アドレスが含まれます。
LSP ID: contains the 16-bit 'LSP ID' identifier defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template Object. A value of 0 MUST be used if the LSP is not yet signaled.
LSP ID：[RFC3209]で定義されている16ビットの「LSP ID」識別子が含まれています。LSP_TUNNEL_IPv4送信者テンプレートオブジェクトのセクション4.6.2.1です。 LSPがまだ通知されていない場合は、値0を使用する必要があります。
Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object.
トンネルID：[RFC3209]で定義された16ビットの「トンネルID」識別子が含まれています。LSP_TUNNEL_IPv4セッションオブジェクトのセクション4.6.1.1です。
Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' identifier defined in [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object.
Extended Tunnel ID：[RFC3209]で定義された32ビットの「Extended Tunnel ID」識別子、LSP_TUNNEL_IPv4セッションオブジェクトのセクション4.6.1.1が含まれます。
IPv4 Tunnel Endpoint Address: contains the egress node's IPv4 address, as defined in [RFC3209], Section 4.6.1.1, for the LSP_TUNNEL_IPv4 Sender Template Object.
IPv4トンネルエンドポイントアドレス：[RFC3209]のセクション4.6.1.1で定義されているように、LSP_TUNNEL_IPv4送信者テンプレートオブジェクトの出力ノードのIPv4アドレスが含まれています。
The format of the IPV6-LSP-IDENTIFIERS TLV is shown in the following figure:
IPV6-LSP-IDENTIFIERS TLVの形式を次の図に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=19 | Length=52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 Tunnel Sender Address |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Extended Tunnel ID |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 Tunnel Endpoint Address |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: IPV6-LSP-IDENTIFIERS TLV Format
図13：IPV6-LSP-IDENTIFIERS TLV形式
The type (16 bits) of the TLV is 19. The length field is 16 bits long and has a fixed value of 52. The value contains the following fields:
TLVのタイプ（16ビット）は19です。長さフィールドは16ビット長で、固定値は52です。値には次のフィールドが含まれます。
IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, as defined in [RFC3209], Section 4.6.2.2, for the LSP_TUNNEL_IPv6 Sender Template Object.
IPv6トンネル送信者アドレス：[RFC3209]のセクション4.6.2.2で定義されている、LSP_TUNNEL_IPv6送信者テンプレートオブジェクトの送信者ノードのIPv6アドレスが含まれています。
LSP ID: contains the 16-bit 'LSP ID' identifier defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template Object. A value of 0 MUST be used if the LSP is not yet signaled.
LSP ID：[RFC3209]で定義されている16ビットの「LSP ID」識別子が含まれています。LSP_TUNNEL_IPv6送信者テンプレートオブジェクトのセクション4.6.2.2です。 LSPがまだ通知されていない場合は、値0を使用する必要があります。
Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object.
トンネルID：[RFC3209]で定義された16ビットの「トンネルID」識別子、LSP_TUNNEL_IPv6セッションオブジェクトのセクション4.6.1.2が含まれています。
Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' identifier defined in [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object.
拡張トンネルID：[RFC3209]で定義された128ビットの「拡張トンネルID」識別子が含まれています。LSP_TUNNEL_IPv6セッションオブジェクトのセクション4.6.1.2です。
IPv6 Tunnel Endpoint Address: contains the egress node's IPv6 address, as defined in [RFC3209], Section 4.6.1.2, for the LSP_TUNNEL_IPv6 Session Object.
IPv6トンネルエンドポイントアドレス：[RFC3209]、セクション4.6.1.2で定義されている、LSP_TUNNEL_IPv6セッションオブジェクトの出口ノードのIPv6アドレスが含まれます。
The Tunnel ID remains constant over the lifetime of a tunnel.
トンネルIDは、トンネルの存続期間を通じて一定です。
Each LSP MUST have a symbolic path name that is unique in the PCC. The symbolic path name is a human-readable string that identifies an LSP in the network. The symbolic path name MUST remain constant throughout an LSP's lifetime, which may span across multiple consecutive PCEP sessions and/or PCC restarts. The symbolic path name MAY be specified by an operator in a PCC's configuration. If the operator does not specify a unique symbolic name for an LSP, then the PCC MUST auto-generate one.
各LSPには、PCCで一意のシンボリックパス名が必要です。シンボリックパス名は、ネットワーク内のLSPを識別する、人間が読み取れる文字列です。シンボリックパス名は、LSPのライフタイムを通じて一定である必要があります。これは、連続する複数のPCEPセッションやPCC再起動にまたがることがあります。シンボリックパス名は、PCCの構成でオペレーターが指定できます。オペレーターがLSPに一意のシンボリック名を指定しない場合、PCCはLSPを自動生成する必要があります。
The PCE uses the symbolic path name as a stable identifier for the LSP. If the PCEP session restarts, or the PCC restarts, or the PCC re-delegates the LSP to a different PCE, the symbolic path name for the LSP remains constant and can be used to correlate across the PCEP session instances.
PCEは、LSPの安定した識別子としてシンボリックパス名を使用します。 PCEPセッションが再起動するか、PCCが再起動するか、PCCがLSPを別のPCEに再委任する場合、LSPのシンボリックパス名は一定のままであり、PCEPセッションインスタンス間での相関に使用できます。
The other protocol identifiers for the LSP cannot reliably be used to identify the LSP across multiple PCEP sessions, for the following reasons.
次の理由により、LSPの他のプロトコル識別子を使用して、複数のPCEPセッションにわたってLSPを確実に識別することはできません。
o The PLSP-ID is unique only within the scope of a single PCEP session.
o PLSP-IDは、単一のPCEPセッションのスコープ内でのみ一意です。
o The LSP-IDENTIFIERS TLV is only guaranteed to be present for LSPs that are signaled with RSVP-TE, and it may change during the lifetime of the LSP.
o LSP-IDENTIFIERS TLVは、RSVP-TEでシグナリングされるLSPに対してのみ存在することが保証されており、LSPのライフタイム中に変更される可能性があります。
The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the LSP State Report (PCRpt) message when during a given PCEP session an LSP is first reported to a PCE. A PCC sends to a PCE the first LSP State Report either during State Synchronization or when a new LSP is configured at the PCC.
SYMBOLIC-PATH-NAME TLVは、特定のPCEPセッション中にLSPが最初にPCEに報告されるときに、LSP状態レポート（PCRpt）メッセージのLSPオブジェクトに含まれている必要があります。 PCCは、状態の同期中、またはPCCで新しいLSPが構成されているときに、最初のLSP状態レポートをPCEに送信します。
The initial PCRpt creates a binding between the symbolic path name and the PLSP-ID for the LSP that lasts for the duration of the PCEP session. The PCC MAY omit the symbolic path name from subsequent LSP State Reports for that LSP on that PCEP session, and just use the PLSP-ID.
最初のPCRptは、シンボリックパス名と、LSPのPLSP-ID間のバインディングを作成します。これは、PCEPセッションの期間中持続します。 PCCは、そのPCEPセッションでそのLSPの後続のLSP状態レポートからシンボリックパス名を省略し、PLSP-IDのみを使用する場合があります。
The format of the SYMBOLIC-PATH-NAME TLV is shown in the following figure:
SYMBOLIC-PATH-NAME TLVのフォーマットを次の図に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=17 | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Symbolic Path Name //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: SYMBOLIC-PATH-NAME TLV Format
図14：SYMBOLIC-PATH-NAME TLV形式
Type (16 bits): the type is 17.
タイプ（16ビット）：タイプは17です。
Length (16 bits): indicates the total length of the TLV in octets and MUST be greater than 0. The TLV MUST be zero-padded so that the TLV is 4-octet aligned.
長さ（16ビット）：TLVの合計の長さをオクテットで示し、0より大きくなければならない（MUST）。TLVは、0パディングして、TLVを4オクテットに揃える必要がある。
Symbolic Path Name (variable): symbolic name for the LSP, unique in the PCC. It SHOULD be a string of printable ASCII characters, without a NULL terminator.
シンボリックパス名（変数）：LSPのシンボリック名。PCCで一意です。 NULLターミネータのない、印刷可能なASCII文字列である必要があります。
The LSP Error Code TLV is an optional TLV for use in the LSP object to convey error information. When an LSP Update Request fails, an LSP State Report MUST be sent to report the current state of the LSP, and it SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for the failure. Similarly, when a PCRpt is sent as a result of an LSP transitioning to non-operational state, the LSP-ERROR-CODE TLV SHOULD be included to indicate the reason for the transition.
LSPエラーコードTLVは、LSPオブジェクトでエラー情報を伝えるために使用するオプションのTLVです。 LSP更新要求が失敗した場合、LSPの現在の状態を報告するためにLSP状態レポートを送信する必要があり、失敗の理由を示すLSP-ERROR-CODE TLVを含める必要があります。同様に、LSPが非動作状態に移行した結果としてPCRptが送信される場合、移行の理由を示すためにLSP-ERROR-CODE TLVを含める必要があります（SHOULD）。
The format of the LSP-ERROR-CODE TLV is shown in the following figure:
LSP-ERROR-CODE TLVのフォーマットを次の図に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=20 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: LSP-ERROR-CODE TLV Format
図15：LSP-ERROR-CODE TLVフォーマット
The type (16 bits) of the TLV is 20. The length field is 16 bits long and has a fixed value of 4. The value contains an error code that indicates the cause of the failure.
TLVのタイプ（16ビット）は20です。長さフィールドは16ビット長で、固定値は4です。値には、失敗の原因を示すエラーコードが含まれています。
The following LSP Error Codes are currently defined:
現在、次のLSPエラーコードが定義されています。
Value Description
----- -------------------------------------
1 Unknown reason
2 Limit reached for PCE-controlled LSPs
3 Too many pending LSP Update Requests
4 Unacceptable parameters
5 Internal error
6 LSP administratively brought down
7 LSP preempted
8 RSVP signaling error
The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object to carry RSVP error information. It includes the RSVP ERROR_SPEC or USER_ERROR_SPEC object ([RFC2205] and [RFC5284]), which were returned to the PCC from a downstream node. If the setup of an LSP fails at a downstream node that returned an ERROR_SPEC to the PCC, the PCC SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV with the relevant RSVP ERROR-SPEC or USER_ERROR_SPEC object.
RSVP-ERROR-SPEC TLVは、RSVPエラー情報を伝えるためにLSPオブジェクトで使用するオプションのTLVです。これには、ダウンストリームノードからPCCに返されたRSVP ERROR_SPECまたはUSER_ERROR_SPECオブジェクト（[RFC2205]および[RFC5284]）が含まれます。 PCCにERROR_SPECを返したダウンストリームノードでLSPのセットアップが失敗した場合、PCCは、このLSPのPCRptにLSPエラーコード= "RSVPシグナリングエラー"のRSP-ERROR-CODE TLVとRSVP-を含める必要があります（SHOULD）。関連するRSVP ERROR-SPECまたはUSER_ERROR_SPECオブジェクトを含むERROR-SPEC TLV。
The format of the RSVP-ERROR-SPEC TLV is shown in the following figure:
RSVP-ERROR-SPEC TLVのフォーマットを次の図に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=21 | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ RSVP ERROR_SPEC or USER_ERROR_SPEC Object +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: RSVP-ERROR-SPEC TLV Format
図16：RSVP-ERROR-SPEC TLVフォーマット
Type (16 bits): the type is 21.
タイプ（16ビット）：タイプは21です。
Length (16 bits): indicates the total length of the TLV in octets. The TLV MUST be zero-padded so that the TLV is 4-octet aligned.
長さ（16ビット）：TLVの全長をオクテットで示します。 TLVはゼロパディングして、TLVが4オクテットに整列するようにする必要があります。
Value (variable): contains the RSVP ERROR_SPEC or USER_ERROR_SPEC object, as specified in [RFC2205] and [RFC5284], including the object header.
値（変数）：[RFC2205]と[RFC5284]で指定されているRSVP ERROR_SPECまたはUSER_ERROR_SPECオブジェクトを含みます（オブジェクトヘッダーを含む）。
The code points described below have been allocated for the protocol elements defined in this document.
以下で説明するコードポイントは、このドキュメントで定義されているプロトコル要素に割り当てられています。
The following bits have been registered in the "Path Computation Element (PCE) Capability Flags" subregistry of the "Open Shortest Path First (OSPF) Parameters" registry:
次のビットは、「Open Shortest Path First（OSPF）Parameters」レジストリの「Path Computation Element（PCE）Capability Flags」サブレジストリに登録されています。
Bit Description Reference
--- ------------------------------- -------------
11 Active stateful PCE capability This document
12 Passive stateful PCE capability This document
The following message types have been allocated within the "PCEP Messages" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry:
次のメッセージタイプは、「パス計算エレメントプロトコル（PCEP）番号」レジストリの「PCEPメッセージ」サブレジストリ内に割り当てられています。
Value Description Reference
----- ------------ -------------
10 Report This document
11 Update This document
The following object-class values and object types have been allocated within the "PCEP Objects" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry:
次のオブジェクトクラス値とオブジェクトタイプは、「パス計算要素プロトコル（PCEP）番号」レジストリの「PCEPオブジェクト」サブレジストリ内に割り当てられています。
Object-Class Value Name Reference
------------------ ---------------- -------------
32 LSP This document
Object-Type
0: Reserved
1: LSP
33 SRP This document Object-Type 0: Reserved 1: SRP
33 SRPこのドキュメントObject-Type 0：予約済み1：SRP
A new subregistry, named "LSP Object Flag Field", has been created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field of the LSP object. New values are assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
LSPオブジェクトのフラグフィールドを管理するために、「パス計算要素プロトコル（PCEP）番号」レジストリ内に「LSPオブジェクトフラグフィールド」という名前の新しいサブレジストリが作成されました。新しい値は、標準アクション[RFC8126]によって割り当てられます。各ビットは、次の品質で追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit)
o ビット番号（ビット0を最上位ビットとして数えます）
o Capability description
o 機能の説明
o Defining RFC
o RFCの定義
The following values are defined in this document:
このドキュメントでは、次の値が定義されています。
Bit Description Reference
--- -------------------- -------------
0-4 Unassigned This document
5-7 Operational (3 bits) This document
8 Administrative This document
9 Remove This document
10 SYNC This document
11 Delegate This document
The following error types and error values have been registered within the "PCEP-ERROR Object Error Types and Values" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry:
次のエラータイプとエラー値は、「パス計算要素プロトコル（PCEP）番号」レジストリの「PCEP-ERRORオブジェクトエラータイプと値」サブレジストリに登録されています。
Error-Type Meaning
---------- -------------------------------------------------------
6 Mandatory Object missing
Error-value 8: LSP object missing 9: ERO object missing 10: SRP object missing 11: LSP-IDENTIFIERS TLV missing
エラー値8：LSPオブジェクトがありません9：EROオブジェクトがありません10：SRPオブジェクトがありません11：LSP-IDENTIFIERS TLVがありません
19 Invalid Operation
19無効な操作
Error-value 1: Attempted LSP Update Request for a non-delegated LSP. The PCEP-ERROR object is followed by the LSP object that identifies the LSP. 2: Attempted LSP Update Request if the stateful PCE capability was not advertised. 3: Attempted LSP Update Request for an LSP identified by an unknown PLSP-ID. 5: Attempted LSP State Report if stateful PCE capability was not advertised.
エラー値1：委任されていないLSPに対して試行されたLSP更新要求。 PCEP-ERRORオブジェクトの後には、LSPを識別するLSPオブジェクトが続きます。 2：ステートフルPCE機能がアドバタイズされなかった場合、LSP更新要求を試みました。 3：不明なPLSP-IDで識別されるLSPに対してLSP更新要求を試みました。 5：ステートフルPCE機能がアドバタイズされなかった場合、LSP状態レポートを試みました。
20 LSP State Synchronization Error
20 LSP状態同期エラー
Error-value 1: A PCE indicates to a PCC that it cannot process (an otherwise valid) LSP State Report. The PCEP-ERROR object is followed by the LSP object that identifies the LSP. 5: A PCC indicates to a PCE that it cannot complete the State Synchronization.
エラー値1：PCEは、PCCに対して、（それ以外の場合は有効な）LSP状態レポートを処理できないことを示します。 PCEP-ERRORオブジェクトの後には、LSPを識別するLSPオブジェクトが続きます。 5：PCCは、PCEに状態同期を完了できないことを示します。
The following Notification Types and Notification Values have been allocated within the "Notification Object" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry:
次の通知タイプと通知値は、「パス計算要素プロトコル（PCEP）番号」レジストリの「通知オブジェクト」サブレジストリ内に割り当てられています。
Notification-Type Name 4 Stateful PCE resource limit exceeded
通知タイプ名4ステートフルPCEリソース制限を超えました
Notification-value 1: Entering resource limit exceeded state 2: Deprecated
通知値1：リソース制限の入力が状態を超えました2：非推奨
Note that the early allocation included an additional Notification Value 2 for "Exiting resource limit exceeded state". This Notification Value is no longer required and has been marked as "Deprecated".
初期の割り当てには、「終了するリソース制限を超えた状態」に対する追加の通知値2が含まれていたことに注意してください。この通知値は不要になり、「非推奨」とマークされています。
The following TLV Type Indicator values have been registered within the "PCEP TLV Type Indicators" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry:
次のTLVタイプインジケーターの値は、「パス計算要素プロトコル（PCEP）番号」レジストリの「PCEP TLVタイプインジケーター」サブレジストリに登録されています。
Value Description Reference
----- ----------------------- -------------
16 STATEFUL-PCE-CAPABILITY This document
17 SYMBOLIC-PATH-NAME This document
18 IPV4-LSP-IDENTIFIERS This document
19 IPV6-LSP-IDENTIFIERS This document
20 LSP-ERROR-CODE This document
21 RSVP-ERROR-SPEC This document
A new subregistry, named "STATEFUL-PCE-CAPABILITY TLV Flag Field", has been created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field in the STATEFUL-PCE-CAPABILITY TLV of the PCEP OPEN object (class = 1). New values are assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
PCEP OPENオブジェクトのSTATEFUL-PCE-CAPABILITY TLVのフラグフィールドを管理するために、「パス計算要素プロトコル（PCEP）番号」レジストリ内に「STATEFUL-PCE-CAPABILITY TLVフラグフィールド」という名前の新しいサブレジストリが作成されました（クラス= 1）。新しい値は、標準アクション[RFC8126]によって割り当てられます。各ビットは、次の品質で追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit)
o ビット番号（ビット0を最上位ビットとして数えます）
o Capability description
o 機能の説明
o Defining RFC
o RFCの定義
The following values are defined in this document:
このドキュメントでは、次の値が定義されています。
Value Description Reference
----- --------------------- -------------
31 LSP-UPDATE-CAPABILITY This document
A new subregistry, named "LSP-ERROR-CODE TLV Error Code Field", has been created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the LSP Error Code field of the LSP-ERROR-CODE TLV. This field specifies the reason for failure to update the LSP.
LSP-ERROR-CODE TLVのLSPエラーコードフィールドを管理するために、「パス計算要素プロトコル（PCEP）番号」レジストリ内に「LSP-ERROR-CODE TLVエラーコードフィールド」という名前の新しいサブレジストリが作成されました。このフィールドは、LSPの更新に失敗した理由を指定します。
New values are assigned by Standards Action [RFC8126]. Each value should be tracked with the following qualities: value, meaning, and defining RFC. The following values are defined in this document:
新しい値は、標準アクション[RFC8126]によって割り当てられます。各値は、値、意味、RFCの定義という品質で追跡する必要があります。このドキュメントでは、次の値が定義されています。
Value Meaning
--- -------------------------------------
0 Reserved
1 Unknown reason
2 Limit reached for PCE-controlled LSPs
3 Too many pending LSP Update Requests
4 Unacceptable parameters
5 Internal error
6 LSP administratively brought down
7 LSP preempted
8 RSVP signaling error
All manageability requirements and considerations listed in [RFC5440] apply to the PCEP extensions defined in this document. In addition, requirements and considerations listed in this section apply.
[RFC5440]にリストされているすべての管理要件と考慮事項は、このドキュメントで定義されているPCEP拡張機能に適用されます。さらに、このセクションにリストされている要件と考慮事項が適用されます。
In addition to configuring specific PCEP session parameters, as specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST allow configuring the stateful PCEP capability and the LSP Update capability. A PCC implementation SHOULD allow the operator to specify multiple candidate PCEs for and a delegation preference for each candidate PCE. A PCC SHOULD allow the operator to specify an LSP delegation policy where LSPs are delegated to the most-preferred online PCE. A PCC MAY allow the operator to specify different LSP delegation policies.
[RFC5440]のセクション8.1で指定されている特定のPCEPセッションパラメータの構成に加えて、PCEまたはPCCの実装では、ステートフルPCEP機能とLSP更新機能を構成できる必要があります。 PCC実装は、オペレーターが候補となる各PCEに対して複数のPCE候補と委任設定を指定できるようにする必要があります（SHOULD）。 PCCは、LSPが最も優先されるオンラインPCEに委任されるLSP委任ポリシーをオペレーターが指定できるようにする必要があります（SHOULD）。 PCCにより、オペレーターは異なるLSP委任ポリシーを指定できます。
A PCC implementation that allows concurrent connections to multiple PCEs SHOULD allow the operator to group the PCEs by administrative domains, and it MUST NOT advertise LSP existence and state to a PCE if the LSP is delegated to a PCE in a different group.
複数のPCEへの同時接続を許可するPCC実装は、オペレーターが管理ドメインによってPCEをグループ化できるようにする必要があり（SHOULD）、LSPが別のグループのPCEに委任されている場合は、LSPの存在と状態をPCEに通知してはなりません。
A PCC implementation SHOULD allow the operator to specify whether the PCC will advertise LSP existence and state for LSPs that are not controlled by any PCE (for example, LSPs that are statically configured at the PCC).
PCC実装は、PCCが、PCEによって制御されていないLSP（たとえば、PCCで静的に構成されているLSP）のLSPの存在と状態を通知するかどうかをオペレーターが指定できるようにする必要があります（SHOULD）。
A PCC implementation SHOULD allow the operator to specify both the Redelegation Timeout Interval and the State Timeout Interval. The default value of the Redelegation Timeout Interval SHOULD be set to 30 seconds. An operator MAY also configure a policy that will dynamically adjust the Redelegation Timeout Interval, for example setting it to zero when the PCC has an established session to a backup PCE. The default value for the State Timeout Interval SHOULD be set to 60 seconds.
PCC実装では、オペレーターが再委任タイムアウト間隔と状態タイムアウト間隔の両方を指定できるようにする必要があります（SHOULD）。 Redelegation Timeout Intervalのデフォルト値は30秒に設定する必要があります（SHOULD）。オペレーターは、PCCがバックアップPCEへの確立されたセッションを持っているときにゼロに設定するなど、再委任タイムアウト間隔を動的に調整するポリシーを構成することもできます（MAY）。状態タイムアウト間隔のデフォルト値は60秒に設定する必要があります（SHOULD）。
After the expiration of the State Timeout Interval, the LSP reverts to operator-defined default parameters. A PCC implementation MUST allow the operator to specify the default LSP parameters. To achieve a behavior where the LSP retains the parameters set by the PCE until such time that the PCC makes a change to them, a State Timeout Interval of infinity SHOULD be used. Any changes to LSP parameters SHOULD be done in a make-before-break fashion.
状態タイムアウト間隔が満了すると、LSPはオペレーターが定義したデフォルトのパラメーターに戻ります。 PCC実装では、オペレーターがデフォルトのLSPパラメーターを指定できるようにする必要があります。 PCCがパラメータを変更するまでLSPがPCEによって設定されたパラメータを保持する動作を実現するには、無限の状態タイムアウト間隔を使用する必要があります（SHOULD）。 LSPパラメータへの変更は、make-before-breakの方法で行う必要があります。
LSP delegation is controlled by operator-defined policies on a PCC. LSPs are delegated individually -- different LSPs may be delegated to different PCEs. An LSP is delegated to at most one PCE at any given point in time. A PCC implementation SHOULD support the delegation policy, when all PCC's LSPs are delegated to a single PCE at any given time. Conversely, the policy revoking the delegation for all PCC's LSPs SHOULD also be supported.
LSP委任は、PCCのオペレーター定義のポリシーによって制御されます。 LSPは個別に委任されます。異なるLSPは異なるPCEに委任される場合があります。 LSPは任意の時点で最大1つのPCEに委任されます。 PCC実装は、すべてのPCCのLSPがいつでも単一のPCEに委任される場合に、委任ポリシーをサポートする必要があります（SHOULD）。逆に、すべてのPCCのLSPの委任を取り消すポリシーもサポートする必要があります（SHOULD）。
A PCC implementation SHOULD allow the operator to specify delegation priority for PCEs. This effectively defines the primary PCE and one or more backup PCEs to which a primary PCE's LSPs can be delegated when the primary PCE fails.
PCC実装では、オペレーターがPCEの委任優先度を指定できるようにする必要があります（SHOULD）。これにより、プライマリPCEと、プライマリPCEに障害が発生したときにプライマリPCEのLSPを委任できる1つ以上のバックアップPCEが効果的に定義されます。
Policies defined for stateful PCEs and PCCs should eventually fit in the policy-enabled path computation framework defined in [RFC5394], and the framework should be extended to support stateful PCEs.
ステートフルPCEおよびPCCに対して定義されたポリシーは、最終的には[RFC5394]で定義されたポリシー対応パス計算フレームワークに適合し、フレームワークはステートフルPCEをサポートするように拡張される必要があります。
The PCEP YANG module [PCEP-YANG] should include:
PCEP YANGモジュール[PCEP-YANG]には以下が含まれている必要があります。
o advertised stateful capabilities and synchronization status per PCEP session.
o PCEPセッションごとのアドバタイズされたステートフル機能と同期ステータス。
o the delegation status of each configured LSP.
o 構成された各LSPの委任ステータス。
The PCEP MIB [RFC7420] could also be updated to include this information.
PCEP MIB [RFC7420]もこの情報を含むように更新できます。
PCEP extensions defined in this document do not require any new mechanisms beyond those already defined in [RFC5440], Section 8.3.
このドキュメントで定義されているPCEP拡張機能は、[RFC5440]、セクション8.3ですでに定義されているものを超える新しいメカニズムを必要としません。
Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP extensions defined in this document. In addition to monitoring parameters defined in [RFC5440], a stateful PCC-side PCEP implementation SHOULD provide the following parameters:
[RFC5440]のセクション8.4で定義されているメカニズムは、このドキュメントで定義されているPCEP拡張機能にも適用されます。 [RFC5440]で定義されている監視パラメータに加えて、ステートフルPCC側のPCEP実装は次のパラメータを提供する必要があります（SHOULD）。
o Total number of LSP Updates
o LSP更新の総数
o Number of successful LSP Updates
o 成功したLSP更新の数
o Number of dropped LSP Updates
o ドロップされたLSPアップデートの数
o Number of LSP Updates where LSP setup failed
o LSPセットアップが失敗したLSP更新の数
A PCC implementation SHOULD provide a command to show for each LSP whether it is delegated, and if so, to which PCE.
PCC実装は、各LSPが委任されているかどうか、委任されている場合はどのPCEに委任するかを示すコマンドを提供する必要があります（SHOULD）。
A PCC implementation SHOULD allow the operator to manually revoke LSP delegation.
PCC実装は、オペレーターが手動でLSP委任を取り消すことを許可する必要があります（SHOULD）。
PCEP extensions defined in this document do not put new requirements on other protocols.
このドキュメントで定義されているPCEP拡張機能は、他のプロトコルに新しい要件を課しません。
Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP extensions defined in this document.
[RFC5440]のセクション8.6で定義されているメカニズムは、このドキュメントで定義されているPCEP拡張機能にも適用されます。
Additionally, a PCEP implementation SHOULD allow a limit to be placed on the number of LSPs delegated to the PCE and on the rate of PCUpd and PCRpt messages sent by a PCEP speaker and processed from a peer. It SHOULD also allow sending a notification when a rate threshold is reached.
さらに、PCEP実装では、PCEに委任されるLSPの数、およびPCEPスピーカーによって送信され、ピアから処理されるPCUpdおよびPCRptメッセージのレートに制限を設定できるようにする必要があります（SHOULD）。また、レートしきい値に達したときに通知を送信できるようにする必要があります（SHOULD）。
A PCC implementation SHOULD allow a limit to be placed on the rate of LSP Updates to the same LSP to avoid signaling overload discussed in Section 10.3.
PCC実装では、セクション10.3で説明されているシグナリングの過負荷を回避するために、同じLSPへのLSP更新のレートに制限を設定できるようにする必要があります（SHOULD）。
This document defines extensions to PCEP to enable stateful PCEs. The nature of these extensions and the delegation of path control to PCEs results in more information being available for a hypothetical adversary and a number of additional attack surfaces that must be protected.
このドキュメントでは、ステートフルPCEを有効にするPCEPの拡張機能を定義します。これらの拡張の性質とPCEへのパス制御の委任により、仮想の敵と保護する必要のある多くの追加の攻撃面についてより多くの情報を利用できるようになります。
The security provisions described in [RFC5440] remain applicable to these extensions. However, because the protocol modifications outlined in this document allow the PCE to control path computation timing and sequence, the PCE defense mechanisms described in [RFC5440], Section 7.2 are also now applicable to PCC security.
[RFC5440]で説明されているセキュリティ規定は、これらの拡張機能に引き続き適用されます。ただし、このドキュメントで説明されているプロトコルの変更により、PCEはパス計算のタイミングとシーケンスを制御できるため、[RFC5440]のセクション7.2で説明されているPCE防御メカニズムがPCCセキュリティにも適用されるようになりました。
As a general precaution, it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [PCEPS], as per the recommendations and best current practices in [RFC7525].
一般的な予防策として、これらのPCEP拡張機能は、推奨事項と現在のベストプラクティスに従って、トランスポート層セキュリティ（TLS）[PCEPS]を使用して、同じ管理機関に属するPCEとPCC間で認証および暗号化されたセッションでのみアクティブ化することをお勧めします[RFC7525]。
The following sections identify specific security concerns that may result from the PCEP extensions outlined in this document along with recommended mechanisms to protect PCEP infrastructure against related attacks.
次のセクションでは、関連する攻撃からPCEPインフラストラクチャを保護するための推奨メカニズムとともに、このドキュメントで概説されているPCEP拡張から生じる可能性のある特定のセキュリティ上の懸念を特定します。
The stateful nature of this extension explicitly requires LSP status updates to be sent from PCC to PCE. While this gives the PCE the ability to provide more optimal computations to the PCC, it also provides an adversary with the opportunity to eavesdrop on decisions made by network systems external to PCE. This is especially true if the PCC delegates LSPs to multiple PCEs simultaneously.
この拡張のステートフルな性質により、LSCステータスの更新をPCCからPCEに送信する必要があります。これにより、PCEはより最適な計算をPCCに提供できるようになりますが、PCE外部のネットワークシステムによって行われた決定を傍受する機会も敵に提供します。これは、PCCがLSPを複数のPCEに同時に委任する場合に特に当てはまります。
Adversaries may gain access to this information by eavesdropping on unsecured PCEP sessions and might then use this information in various ways to target or optimize attacks on network infrastructure, for example, by flexibly countering anti-DDoS measures being taken to protect the network or by determining choke points in the network where the greatest harm might be caused.
攻撃者は、セキュリティで保護されていないPCEPセッションを盗聴してこの情報にアクセスし、さまざまな方法でこの情報を使用して、ネットワークを保護するために行われるDDoS対策を柔軟に対抗したり、ネットワークインフラストラクチャへの攻撃を最適化したりすることができます。最大の被害が発生する可能性があるネットワーク内のチョークポイント。
PCC implementations that allow concurrent connections to multiple PCEs SHOULD allow the operator to group the PCEs by administrative domains, and they MUST NOT advertise LSP existence and state to a PCE if the LSP is delegated to a PCE in a different group.
複数のPCEへの同時接続を許可するPCC実装は、オペレーターが管理ドメインでPCEをグループ化できるようにする必要があり（SHOULD）、LSPが別のグループのPCEに委任されている場合、それらはLSPの存在と状態をPCEに通知してはなりません（MUST NOT）。
The LSP delegation mechanism described in this document allows a PCC to grant effective control of an LSP to the PCE for the duration of a PCEP session. While this enables PCE control of the timing and sequence of path computations within and across PCEP sessions, it also introduces a new attack vector: an attacker may flood the PCC with PCUpd messages at a rate that exceeds either the PCC's ability to process them or the network's ability to signal the changes, by either spoofing messages or compromising the PCE itself.
このドキュメントで説明するLSP委任メカニズムにより、PCCは、PCEPセッションの期間中、PCEにLSPの効果的な制御を付与できます。これにより、PCEPセッション内およびPCEPセッション全体のパス計算のタイミングとシーケンスのPCE制御が可能になりますが、新しい攻撃ベクトルも導入されます。攻撃者は、PCCの処理能力またはそれらの処理能力を超えるレートでPCUpdメッセージでPCCをフラッディングする可能性があります。メッセージを偽装するか、PCE自体を危険にさらすことによって、変更を通知するネットワークの機能。
A PCC is free to revoke an LSP delegation at any time without needing any justification. A defending PCC can do this by enqueueing the appropriate PCRpt message. As soon as that message is enqueued in the session, the PCC is free to drop any incoming PCUpd messages without additional processing.
PCCは、正当な理由を必要とせずに、いつでもLSP委任を自由に取り消すことができます。防御側のPCCは、適切なPCRptメッセージをエンキューすることでこれを行うことができます。そのメッセージがセッションのキューに入れられるとすぐに、PCCは追加の処理なしで着信PCUpdメッセージを自由にドロップできます。
A stateful session also results in an increased attack surface by placing a requirement for the PCE to keep an LSP state replica for each PCC. It is RECOMMENDED that PCE implementations provide a limit on resources a single PCC can occupy. A PCE implementing such a limit MUST send a PCNtf message with notification-type 4 (Stateful PCE resource limit exceeded) and notification-value 1 (Entering resource limit exceeded state) upon receiving an LSP State Report causing it to exceed this threshold.
ステートフルセッションでは、PCEが各PCCのLSP状態のレプリカを保持する必要があるため、攻撃対象領域が増加します。 PCE実装は、単一のPCCが占有できるリソースに制限を設けることをお勧めします。このような制限を実装するPCEは、LSP状態レポートを受け取ってこのしきい値を超えると、通知タイプ4（ステートフルPCEリソース制限を超えた）および通知値1（リソース制限を超えた状態に入った）を含むPCNtfメッセージを送信する必要があります。
Delegation of LSPs can create further strain on PCE resources and a PCE implementation MAY preemptively give back delegations if it finds itself lacking the resources needed to effectively manage the delegation. Since the delegation state is ultimately controlled by the PCC, PCE implementations SHOULD provide throttling mechanisms to prevent strain created by flaps of either a PCEP session or an LSP delegation.
LSPの委任は、PCEリソースにさらに負担をかける可能性があり、PCE実装は、委任を効果的に管理するために必要なリソースが不足していることがわかった場合、事前に委任を返すことができます。委任状態は最終的にPCCによって制御されるため、PCE実装は、PCEPセッションまたはLSP委任のいずれかのフラップによって生じるひずみを防ぐためのスロットルメカニズムを提供する必要があります（SHOULD）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification」、RFC 2205、DOI 10.17487 / RFC2205、1997年9月、<https://www.rfc-editor.org/info/rfc2205>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, January 2008, <https://www.rfc-editor.org/info/rfc5088>.
[RFC5088] Le Roux、JL。、Ed。、Vasseur、JP。、Ed。、Ikejiri、Y.、and R. Zhang、 "OSPF Protocol Extensions for Path Computation Element（PCE）Discovery"、RFC 5088、DOI 10.17487 / RFC5088、2008年1月、<https://www.rfc-editor.org/info/rfc5088>。
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, January 2008, <https://www.rfc-editor.org/info/rfc5089>.
[RFC5089] Le Roux、JL。、Ed。、Vasseur、JP。、Ed。、Ikejiri、Y.、and R. Zhang、 "IS-IS Protocol Extensions for Path Computation Element（PCE）Discovery"、RFC 5089、DOI 10.17487 / RFC5089、2008年1月、<https://www.rfc-editor.org/info/rfc5089>。
[RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP", RFC 5284, DOI 10.17487/RFC5284, August 2008, <https://www.rfc-editor.org/info/rfc5284>.
[RFC5284] Swallow、G。およびA. Farrel、「RSVPのユーザー定義エラー」、RFC 5284、DOI 10.17487 / RFC5284、2008年8月、<https://www.rfc-editor.org/info/rfc5284>。
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5440] Vasseur、JP。、Ed。とJL。 Le Roux、編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<https://www.rfc-editor.org/info/rfc5440>。
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC5511] Farrel、A。、「Routing Backus-Naur Form（RBNF）：A Syntax Using Forming Encoding Rules in Various Routing Protocol Specifications」、RFC 5511、DOI 10.17487 / RFC5511、2009年4月、<https：// www。 rfc-editor.org/info/rfc5511>。
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, <https://www.rfc-editor.org/info/rfc8051>.
[RFC8051]張、X。、エド。 I. Minei、編、「Stateful Path Computation Element（PCE）の適用性」、RFC 8051、DOI 10.17487 / RFC8051、2017年1月、<https://www.rfc-editor.org/info/rfc8051>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE LSP Path Computation using Preemption", Global Information Infrastructure Symposium, DOI 10.1109/GIIS.2007.4404195, July 2007.
[MPLS-PC] Chaieb、I.、Le Roux、JL。、およびB. Cousin、「Improved MPLS-TE LSP Path Computation using Preemption」、Global Information Infrastructure Symposium、DOI 10.1109 / GIIS.2007.4404195、July 2007。
[MXMN-TE] Danna, E., Mandal, S., and A. Singh, "A practical algorithm for balancing the max-min fairness and throughput objectives in traffic engineering", INFOCOM, 2012 Proceedings IEEE, pp. 846-854, DOI 10.1109/INFCOM.2012.6195833, March 2012.
[MXMN-TE] Danna、E.、Mandal、S。、およびA. Singh、「トラフィックエンジニアリングにおける最大最小の公平性とスループット目標のバランスをとるための実用的なアルゴリズム」、INFOCOM、2012 Proceedings IEEE、pp。846-854 、DOI 10.1109 / INFCOM.2012.6195833、2012年3月。
[PCE-Init-LSP] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", Work in Progress, draft-ietf-pce-pce-initiated-lsp-10, June 2017.
[PCE-Init-LSP] Crabbe、E.、Minei、I.、Sivabalan、S。、およびR. Varga、「ステートフルPCEモデルでのPCEによって開始されるLSPセットアップのPCEP拡張機能」、作業中、draft-ietf -pce-pce-initiated-lsp-10、2017年6月。
[PCEP-GMPLS] Margaria, C., de Dios, O., and F. Zhang, "PCEP extensions for GMPLS", Work in Progress, draft-ietf-pce-gmpls-pcep-extensions-11, October 2015.
[PCEP-GMPLS] Margaria、C.、de Dios、O。、およびF. Zhang、「GMPLSのPCEP拡張機能」、作業中、draft-ietf-pce-gmpls-pcep-extensions-11、2015年10月。
[PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and j. jefftant@gmail.com, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, draft-ietf-pce-pcep-yang-05, June 2017.
[PCEP-YANG] Dhody、D.、Hardwick、J.、Beeram、V.、j。 jefftant@gmail.com、「パス計算要素通信プロトコル（PCEP）のYANGデータモデル」、作業中、draft-ietf-pce-pcep-yang-05、2017年6月。
[PCEPS] Lopez, D., de Dios, O., Wu, Q., and D. Dhody, "Secure Transport for PCEP", Work in Progress, draft-ietf-pce-pceps-18, September 2017.
[PCEPS] Lopez、D.、de Dios、O.、Wu、Q。、およびD. Dhody、「Secure Transport for PCEP」、Work in Progress、draft-ietf-pce-pceps-18、2017年9月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, DOI 10.17487/RFC2702, September 1999, <https://www.rfc-editor.org/info/rfc2702>.
[RFC2702] Awduche、D.、Malcolm、J.、Agogbua、J.、O'Dell、M。、およびJ. McManus、「MPLSを介したトラフィックエンジニアリングの要件」、RFC 2702、DOI 10.17487 / RFC2702、1999年9月、 <https://www.rfc-editor.org/info/rfc2702>。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<https://www.rfc-editor.org/info / rfc3031>。
[RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., Christian, B., and W. Lai, "Applicability Statement for Traffic Engineering with MPLS", RFC 3346, DOI 10.17487/RFC3346, August 2002, <https://www.rfc-editor.org/info/rfc3346>.
[RFC3346] Boyle、J.、Gill、V.、Hannan、A.、Cooper、D.、Awduche、D.、Christian、B。、およびW. Lai、「MPLSによるトラフィックエンジニアリングの適用性に関する声明」、RFC 3346 、DOI 10.17487 / RFC3346、2002年8月、<https://www.rfc-editor.org/info/rfc3346>。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.
[RFC3630] Katz、D.、Kompella、K.、D。Yeung、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、DOI 10.17487 / RFC3630、2003年9月、<https：//www.rfc -editor.org/info/rfc3630>。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<https：//www.rfc -editor.org/info/rfc4655>。
[RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC4657] Ash、J.、Ed。およびJ. Le Roux編、「Path Computation Element（PCE）Communication Protocol Generic Requirements」、RFC 4657、DOI 10.17487 / RFC4657、2006年9月、<https://www.rfc-editor.org/info/rfc4657> 。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、DOI 10.17487 / RFC5305、2008年10月、<https://www.rfc-editor.org/info/rfc5305> 。
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, DOI 10.17487/RFC5394, December 2008, <https://www.rfc-editor.org/info/rfc5394>.
[RFC5394] Bryskin、I.、Papadimitriou、D.、Berger、L。、およびJ. Ash、「Policy-Enabled Path Computation Framework」、RFC 5394、DOI 10.17487 / RFC5394、2008年12月、<https：// www。 rfc-editor.org/info/rfc5394>。
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014, <https://www.rfc-editor.org/info/rfc7420>.
[RFC7420] Koushik、A.、Stephan、E.、Zhao、Q.、King、D。、およびJ. Hardwick、「Path Computation Element Communication Protocol（PCEP）Management Information Base（MIB）Module」、RFC 7420、DOI 10.17487 / RFC7420、2014年12月、<https://www.rfc-editor.org/info/rfc7420>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<https://www.rfc-editor.org/info/rfc7525>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., and D. Dhody, "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", RFC 8232, DOI 10.17487/RFC8232, September 2017, <http://www.rfc-editor.org/info/rfc8232>.
[RFC8232] Crabbe、E.、Minei、I.、Medved、J.、Varga、R.、Zhang、X。、およびD. Dhody、「最適化されたステートフルPCEのためのラベルスイッチドパス状態同期手順」、RFC 8232 、DOI 10.17487 / RFC8232、2017年9月、<http://www.rfc-editor.org/info/rfc8232>。
Acknowledgements
謝辞
We would like to thank Adrian Farrel, Cyril Margaria, and Ramon Casellas for their contributions to this document.
このドキュメントへの貢献に対して、Adrian Farrel、Cyril Margaria、およびRamon Casellasに感謝します。
We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto, Paul Schultz, and Raveendra Torvi for their comments and suggestions. Thanks also to Jon Hardwick, Oscar Gonzales de Dios, Tomas Janciga, Stefan Kobza, Kexin Tang, Matej Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin Sampath, Calvin Ying, Mustapha Aissaoui, Stephane Litkowski, and Olivier Dugeon for helpful comments and discussions.
シェーンアマンテ、ジュリアンムーリック、塩本浩平、ポールシュルツ、ラベンドラトルビのコメントと提案に感謝します。 Jon Hardwick、Oscar Gonzales de Dios、Tomas Janciga、Stefan Kobza、Kexin Tang、Matej Spanik、Jon Parker、Marek Zavodsky、Ambrose Kwong、Ashwin Sampath、Calvin Ying、Mustapha Aissaoui、Stephane Litkowski、Olivier Dugeonにも感謝します。そして議論。
Contributors
貢献者
The following people contributed substantially to the content of this document and should be considered coauthors:
次の人々はこのドキュメントの内容に実質的に貢献し、共著者と見なされるべきです：
Xian Zhang Huawei Technology F3-5-B R&D Center Huawei Industrial Base, Bantian, Longgang District Shenzhen, Guangdong 518129 China Email: zhang.xian@huawei.com
X Ian Zhang hu AはテクノロジーF3-5-br＆Dセンターhu Aは工業基地であり、禁止日であり、長いギャング地区は非常に現実的です。GUケースGビルディング518129中国Eメール：Zhang。Xian @ Huawei.com
Dhruv Dhody Huawei Technology Leela Palace Bangalore, Karnataka 560008 INDIA Email: dhruv.dhody@huawei.com
Dhruv Dhody Huawei Technology Leela Palace Bangalore、Karnataka 560008 INDIA Eメール：dhruv.dhody@huawei.com
Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada Email: msiva@cisco.com
Shiva Sivabalan Cisco Systems、Inc. ವೆ革新的なドライブコンテ、オンタリオクイック೩カナダメール：masiva@scisco.com
Authors' Addresses
著者のアドレス
Edward Crabbe Oracle 1501 4th Ave, suite 1800 Seattle, WA 98101 United States of America
Edward Crabbe Oracle 1501 4th Ave、suite 1800 Seattle、WA 98101アメリカ合衆国
Email: edward.crabbe@oracle.com
Ina Minei Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Ina Minei Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Email: inaminei@google.com
Jan Medved Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 United States of America
Jan Medved Cisco Systems、Inc. 170 West Tasman Dr. San Jose、CA 95134アメリカ合衆国
Email: jmedved@cisco.com
Robert Varga Pantheon Technologies SRO Mlynske Nivy 56 Bratislava 821 05 Slovakia
Robert Varga Pantheon Technologies SRO Mlynske Nivy 56ブラチスラバ821 05スロバキア
Email: robert.varga@pantheon.tech