[要約] RFC 8281は、状態保持型PCEモデルでのPCEによるLSPセットアップのためのPCEP拡張に関するものです。このRFCの目的は、PCEがLSPのセットアップを開始し、状態情報を保持するためのプロトコル拡張を提供することです。
Internet Engineering Task Force (IETF) E. Crabbe
Request for Comments: 8281 Individual Contributor
Category: Standards Track I. Minei
ISSN: 2070-1721 Google, Inc.
S. Sivabalan
Cisco Systems, Inc.
R. Varga
Pantheon Technologies SRO
December 2017
Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model
ステートフルPCEモデルでのPCEによって開始されるLSPセットアップのパス計算要素通信プロトコル（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）要求に応答してパス計算を実行するためのメカニズムを提供します。
The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model.
ステートフルPCEの拡張により、PCCが1つ以上のローカルに構成されたLSPの制御をPCEに委任するモデルに対して、PCEPを介したマルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリングラベルスイッチドパス（TE LSP）のアクティブ制御を提供します。このドキュメントでは、ステートフルPCEモデルでのPCEによって開始されるLSPの作成と削除について説明します。
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/rfc8281.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8281で入手できます。
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
このドキュメントは、BCP 78およびIETFドキュメントに関連するIETFトラストの法的規定の対象です。
(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.
（https://trustee.ietf.org/license-info）このドキュメントの発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 5
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Operation Overview . . . . . . . . . . . . . . . . . . . 6
4. Support of PCE-Initiated LSPs . . . . . . . . . . . . . . . . 7
4.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 8
5. PCE-Initiated LSP Instantiation and Deletion . . . . . . . . 8
5.1. The LSP Initiate Request . . . . . . . . . . . . . . . . 8
5.2. The R Flag in the SRP Object . . . . . . . . . . . . . . 10
5.3. LSP Instantiation . . . . . . . . . . . . . . . . . . . . 10
5.3.1. The Create Flag . . . . . . . . . . . . . . . . . . . 12
5.3.2. The SPEAKER-ENTITY-ID TLV . . . . . . . . . . . . . . 13
5.4. LSP Deletion . . . . . . . . . . . . . . . . . . . . . . 13
6. LSP Delegation and Cleanup . . . . . . . . . . . . . . . . . 14
7. LSP State Synchronization . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 15
8.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 15
8.3. SRP object . . . . . . . . . . . . . . . . . . . . . . . 16
8.4. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 16
8.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
[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 PCE and PCE, enabling computation of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP) characteristics.
[RFC5440]は、Path Computation Element Communication Protocol（PCEP）について説明しています。 PCEPは、パス計算クライアント（PCC）とパス計算エレメント（PCE）の間、またはPCEとPCEの間の通信を定義し、トラフィックエンジニアリングラベルスイッチドパス（TE LSP）特性のマルチプロトコルラベルスイッチング（MPLS）の計算を可能にします。
[RFC8231] specifies a set of extensions to PCEP to enable stateful control of TE LSPs between and across PCEP sessions in compliance with [RFC4657]. It includes:
[RFC8231]は、PCEPの拡張セットを指定して、[RFC4657]に準拠してPCEPセッション間およびPCEPセッション全体でTE LSPのステートフル制御を有効にします。以下が含まれます：
o mechanisms to effect LSP State Synchronization between PCCs and PCEs
o PCCとPCE間のLSP状態同期を実行するメカニズム
o delegation of control of LSPs to PCEs
o PCEへのLSPの制御の委任
o PCE control of timing and sequence of path computations within and across PCEP sessions
o PCEPセッション内およびPCEPセッション全体のパス計算のタイミングとシーケンスのPCE制御
It focuses on a model where LSPs are configured on the PCC, and control over them is delegated to the PCE.
LSPがPCCで構成されているモデルに焦点を当て、それらの制御はPCEに委任されます。
This document describes the setup, maintenance, and teardown of PCE-initiated LSPs under the stateful PCE model, without the need for local configuration on the PCC, thus allowing for a dynamic network that is centrally controlled and deployed.
このドキュメントでは、PCCでのローカル構成を必要とせず、ステートフルPCEモデルでのPCEによって開始されたLSPのセットアップ、メンテナンス、およびティアダウンについて説明します。
This document uses the following terms defined in [RFC5440]: PCC, PCE, and PCEP Peer.
このドキュメントでは、[RFC5440]で定義されているPCC、PCE、PCEPピアという用語を使用しています。
This document uses the following terms defined in [RFC8051]: Stateful PCE and Delegation.
このドキュメントでは、[RFC8051]で定義されている次の用語を使用します：ステートフルPCEおよび委任。
This document uses the following terms defined in [RFC8231]: Redelegation Timeout Interval, State Timeout Interval, LSP State Report, and LSP Update Request.
このドキュメントでは、[RFC8231]で定義されている次の用語を使用します。再委任タイムアウト間隔、状態タイムアウト間隔、LSP状態レポート、およびLSP更新要求。
The following terms are defined in this document:
このドキュメントでは、次の用語が定義されています。
PCE-initiated LSP: LSP that is instantiated as a result of a request from the PCE.
PCEによって開始されたLSP：PCEからの要求の結果としてインスタンス化されたLSP。
The message formats in this document are specified using Routing Backus-Naur Form (RBNF) encoding as specified in [RFC5511].
このドキュメントのメッセージ形式は、[RFC5511]で指定されているルーティングBackus-Naur Form（RBNF）エンコーディングを使用して指定されています。
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]で説明されているように解釈されます。
[RFC8231] provides active control over LSPs that are locally configured on the PCC. This model relies on the Label Edge Router (LER) taking an active role in delegating locally configured LSPs to the PCE and is well suited in environments where the LSP placement is fairly static. However, in environments where the LSP placement needs to change in response to application demands, it is useful to support dynamic creation and teardown of LSPs. The ability for a PCE to trigger the creation of LSPs on demand can be seamlessly integrated into a controller-based network architecture, where intelligence in the controller can determine when and where to set up paths.
[RFC8231]は、PCCでローカルに構成されているLSPをアクティブに制御します。このモデルは、ローカルに構成されたLSPをPCEに委任する際にアクティブな役割を果たすラベルエッジルーター（LER）に依存しており、LSP配置がかなり静的な環境に適しています。ただし、アプリケーションの要求に応じてLSPの配置を変更する必要がある環境では、LSPの動的な作成と破棄をサポートすると便利です。 PCEがオンデマンドでLSPの作成をトリガーする機能は、コントローラーベースのネットワークアーキテクチャにシームレスに統合できます。コントローラーのインテリジェンスは、パスをセットアップするタイミングと場所を決定できます。
A possible use case is a software-defined network, where applications request network resources and paths from the network infrastructure. For example, an application can request a path with certain constraints between two Label Switching Routers (LSRs) by contacting the PCE. The PCE can compute a path satisfying the constraints, and instruct the head end LSR to instantiate and signal it. When the path is no longer required by the application, the PCE can request its teardown.
考えられる使用例は、アプリケーションがネットワークインフラストラクチャからネットワークリソースとパスを要求するソフトウェア定義ネットワークです。たとえば、アプリケーションは、PCEに接続することにより、2つのラベルスイッチングルーター（LSR）間の特定の制約付きのパスを要求できます。 PCEは、制約を満たすパスを計算し、インスタンス化してシグナリングするようにヘッドエンドLSRに指示できます。パスがアプリケーションで不要になった場合、PCEはその破棄を要求できます。
Another use case is dynamically adjusting aggregate bandwidth between two points in the network using multiple LSPs. This functionality is very similar to auto-bandwidth, but it allows for providing the desired capacity through multiple LSPs. This approach overcomes two of the limitations auto-bandwidth can experience: 1) growing the capacity between the endpoints beyond the capacity of individual links in the path and 2) achieving good bin packing through use of several small LSPs instead of a single large one. The number of LSPs varies based on the demand, and LSPs are created and deleted dynamically to satisfy the bandwidth requirements.
別の使用例は、複数のLSPを使用してネットワーク内の2つのポイント間の集約帯域幅を動的に調整することです。この機能は自動帯域幅とよく似ていますが、複数のLSPを通じて必要な容量を提供できます。このアプローチは、自動帯域幅で発生する可能性のある2つの制限を克服します。1）エンドポイント間の容量をパス内の個々のリンクの容量を超えて拡大する、2）単一の大きなLSPの代わりに複数の小さなLSPを使用して適切なビンパッキングを実現する。 LSPの数は需要に応じて異なり、LSPは帯域幅要件を満たすために動的に作成および削除されます。
Another use case is demand engineering, where a PCE with visibility into both the network state and the demand matrix can anticipate and optimize how traffic is distributed across the infrastructure. Such optimizations may require creating new paths across the infrastructure.
もう1つのユースケースはデマンドエンジニアリングです。ネットワークの状態とデマンドマトリックスの両方を可視化するPCEは、インフラストラクチャ全体にトラフィックが分散される方法を予測して最適化できます。このような最適化では、インフラストラクチャ全体に新しいパスを作成する必要がある場合があります。
This document defines the new I flag in the STATEFUL-PCE-CAPABILITY TLV to indicate that the sender supports PCE-initiated LSPs (see details in Section 4.1). A PCC or PCE sets this flag in the Open message during the PCEP initialization phase to indicate that it supports the procedures of this document.
このドキュメントでは、送信者がPCEで開始されたLSPをサポートすることを示すために、STATEFUL-PCE-CAPABILITY TLVの新しいIフラグを定義しています（詳細はセクション4.1を参照）。 PCCまたはPCEは、PCEPの初期化フェーズ中にOpenメッセージにこのフラグを設定して、このドキュメントの手順をサポートしていることを示します。
This document defines a new PCEP message, the LSP Initiate Request (PCInitiate) message, which a PCE can send to a PCC to request the initiation or deletion of an LSP. The decision when to instantiate or delete a PCE-initiated LSP is out of the scope of this document.
このドキュメントでは、新しいPCEPメッセージであるLSP Initiate Request（PCInitiate）メッセージを定義します。これは、PCEがPCCに送信して、LSPの開始または削除を要求できます。 PCEによって開始されたLSPをいつインスタンス化または削除するかは、このドキュメントの範囲外です。
The PCE sends a PCInitiate message to the PCC to request the initiation of an LSP. The PCC creates the LSP using the attributes communicated by the PCE and local values for any unspecified parameters. The PCC generates a Path Computation State Report (PCRpt) for the LSP, carrying a newly assigned PLSP-ID for the LSP and delegating the LSP to the PCE via the Delegate flag in the LSP object.
PCEはPCInitiateメッセージをPCCに送信して、LSPの開始を要求します。 PCCは、PCEによって通信された属性と、指定されていないパラメーターのローカル値を使用してLSPを作成します。 PCCはLSPのパス計算状態レポート（PCRpt）を生成し、LSPに新しく割り当てられたPLSP-IDを伝達し、LSPオブジェクトのデリゲートフラグを介してLSPをPCEに委任します。
The PCE can update the attributes of the LSP by sending subsequent Path Computation Update Request (PCUpd) messages. Subsequent PCRpt and PCUpd messages that the PCC and PCE, respectively, send for the LSP will carry the PCC-assigned PLSP-ID, which uniquely identifies the LSP. See details in Section 5.3.
PCEは、後続のパス計算更新要求（PCUpd）メッセージを送信することにより、LSPの属性を更新できます。 PCCおよびPCEがそれぞれLSPに対して送信する後続のPCRptおよびPCUpdメッセージは、LSCを一意に識別するPCC割り当てのPLSP-IDを伝達します。セクション5.3の詳細を参照してください。
The PCE sends a PCInitiate message to the PCC to request the deletion of an LSP. To indicate a delete operation, this document defines the new R flag in the Stateful PCE Request Parameter (SRP) object in the PCInitiate message, as described in Section 5.2. As a result of the deletion request, the PCC removes the LSP and sends a PCRpt for the removed state. See details in Section 5.4.
PCEはPCInitiateメッセージをPCCに送信して、LSPの削除を要求します。削除操作を示すために、このドキュメントでは、セクション5.2で説明されているように、PCInitiateメッセージのステートフルPCEリクエストパラメータ（SRP）オブジェクトに新しいRフラグを定義します。削除要求の結果として、PCCはLSPを削除し、削除された状態のPCRptを送信します。詳細はセクション5.4をご覧ください。
Figure 1 illustrates these message exchanges.
図1は、これらのメッセージ交換を示しています。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|<--PCInitiate-------------------| (Initiate LSP)
| |
|---PCRpt, PLSP_ID=1, D=1------->| (Confirm initiation)
| . |
| . |
| |
|<--PCUpd, PLSP_ID=1-------------| (Update LSP)
| |
|---PCRpt, PLSP_ID=1, D=1------->| (Confirm update)
| . |
| . |
| |
|<--PCInitiate, PLSP_ID=1, R=1---| (Delete LSP)
| |
|---PCRpt, PLSP_ID=1, R=1------->| (Confirm delete)
Figure 1: PCE-Initiated LSP Life Cycle
図1：PCEによって開始されるLSPライフサイクル
A PCEP speaker indicates its ability to support PCE-initiated LSPs during the PCEP initialization phase, as follows. When the PCEP session is created, it sends an Open message with an OPEN object that contains the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A new flag, the I (LSP-INSTANTIATION-CAPABILITY) flag, is introduced to this TLV to indicate support for instantiation of PCE-initiated LSPs. A PCE can initiate LSPs only for PCCs that advertised this capability. A PCC will follow the procedures described in this document only on sessions where the PCE advertised the I flag.
PCEPスピーカーは、次のように、PCEP初期化フェーズ中にPCEによって開始されたLSPをサポートする機能を示します。 PCEPセッションが作成されると、[RFC8231]で定義されているように、STATEFUL-PCE-CAPABILITY TLVを含むOPENオブジェクトを含むOpenメッセージを送信します。 PCEによって開始されたLSPのインスタンス化のサポートを示すために、このTLVに新しいフラグI（LSP-INSTANTIATION-CAPABILITY）フラグが導入されました。 PCEは、この機能をアドバタイズしたPCCに対してのみLSPを開始できます。 PCCは、PCEがIフラグをアドバタイズしたセッションでのみ、このドキュメントで説明されている手順に従います。
The format of the STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231] and included here for easy reference with the addition of the new I flag.
STATEFUL-PCE-CAPABILITY TLVのフォーマットは[RFC8231]で定義されており、新しいIフラグを追加して簡単に参照できるようにここに含まれています。
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 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |I|S|U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+
Figure 2: STATEFUL-PCE-CAPABILITY TLV Format
図2：STATEFUL-PCE-CAPABILITY TLV形式
A new flag is defined to indicate the sender's support for LSP instantiation by a PCE:
PCEによるLSPインスタンス化に対する送信者のサポートを示すために、新しいフラグが定義されています。
I (LSP-INSTANTIATION-CAPABILITY -- 1 bit): If set to 1 by a PCC, the I flag indicates that the PCC allows instantiation of an LSP by a PCE. If set to 1 by a PCE, the I flag indicates that the PCE supports instantiating LSPs. The LSP-INSTANTIATION-CAPABILITY flag must be set by both the PCC and PCE in order to enable PCE-initiated LSP instantiation.
I（LSP-INSTANTIATION-CAPABILITY-1ビット）：PCCによって1に設定された場合、IフラグはPCCがPCEによるLSPのインスタンス化を許可することを示します。 PCEによって1に設定されている場合、Iフラグは、PCEがLSPのインスタンス化をサポートしていることを示します。 PCEによって開始されるLSPインスタンス化を有効にするには、PCCとPCEの両方でLSP-INSTANTIATION-CAPABILITYフラグを設定する必要があります。
To initiate an LSP, a PCE sends a PCInitiate message to a PCC. The message format, objects, and TLVs are discussed separately below for the creation and the deletion cases.
LSPを開始するために、PCEはPCInitiateメッセージをPCCに送信します。メッセージの形式、オブジェクト、およびTLVについては、作成と削除の場合について以下で個別に説明します。
An LSP Initiate Request (PCInitiate) message is a PCEP message sent by a PCE to a PCC to trigger LSP instantiation or deletion. The Message-Type field of the PCEP common header for the PCInitiate message is set to 12. The PCInitiate message MUST include the SRP and the LSP objects and MAY contain other objects, as discussed later in this section.
LSP Initiate Request（PCInitiate）メッセージは、PCEがPCCに送信してLSPのインスタンス化または削除をトリガーするPCEPメッセージです。このセクションで後述するように、PCInitiateメッセージのPCEP共通ヘッダーのMessage-Typeフィールドは12に設定されています。PCInitiateメッセージにはSRPおよびLSPオブジェクトを含める必要があり、他のオブジェクトを含めることができます（MAY）。
The format of a PCInitiate message is as follows:
PCInitiateメッセージの形式は次のとおりです。
<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list>
Where:
<Common Header> is defined in RFC 5440
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|
<PCE-initiated-lsp-deletion>)
<PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP>
[<END-POINTS>]
<ERO>
[<attribute-list>]
<PCE-initiated-lsp-deletion> ::= <SRP>
<LSP>
Where: <attribute-list> is defined in RFC 5440 and extended by PCEP extensions.
<attribute-list>はRFC 5440で定義され、PCEP拡張によって拡張されています。
The LSP object is defined in [RFC8231]. The END-POINTS and Explicit Route Objects (EROs) are defined in [RFC5440].
LSPオブジェクトは[RFC8231]で定義されています。 END-POINTSとExplicit Route Object（ERO）は[RFC5440]で定義されています。
The SRP object is defined in [RFC8231]. The SRP object contains an SRP-ID-number that is unique within a PCEP session. The PCE increments the last-used SRP-ID-number before it sends each PCInitiate message. The PCC MUST echo the value of the SRP-ID-number in PCEP Error (PCErr) and PCRpt messages that it sends as a result of the PCInitiate; this allows the PCE to correlate them with the corresponding PCInitiate message.
SRPオブジェクトは[RFC8231]で定義されています。 SRPオブジェクトには、PCEPセッション内で一意のSRP-ID-numberが含まれています。 PCEは、各PCInitiateメッセージを送信する前に、最後に使用されたSRP-ID番号を増分します。 PCCは、PCInitiateの結果として送信するPCEPエラー（PCErr）およびPCRptメッセージのSRP-ID-numberの値をエコーする必要があります。これにより、PCEはそれらを対応するPCInitiateメッセージと関連付けることができます。
The format of the SRP object is defined in [RFC8231] and included here for easy reference with the addition of the new R flag.
SRPオブジェクトのフォーマットは[RFC8231]で定義されており、新しいRフラグを追加して簡単に参照できるようにここに含まれています。
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 |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The SRP Object Format
図3：SRPオブジェクト形式
A new flag is defined to indicate a delete operation initiated by the PCE:
PCEによって開始された削除操作を示すために、新しいフラグが定義されています。
R (LSP-REMOVE -- 1 bit): If set to 0, it indicates a request to create an LSP. If set to 1, it indicates a request to remove an LSP.
R（LSP-REMOVE-1ビット）：0に設定されている場合、LSPを作成する要求を示します。 1に設定されている場合、LSPを削除する要求を示します。
The LSP is instantiated by sending a PCInitiate message. The LSP is set up using RSVP-TE. Extensions for other setup methods are outside the scope of this document.
LSPは、PCInitiateメッセージを送信することによってインスタンス化されます。 LSPはRSVP-TEを使用して設定されます。他のセットアップ方法の拡張は、このドキュメントの範囲外です。
The PCInitiate message, when used to instantiate an LSP, MUST contain an LSP object with the reserved PLSP-ID 0. The LSP object MUST include the SYMBOLIC-PATH-NAME TLV, which is used to correlate between the PCC-assigned PLSP-ID and the LSP.
LSPのインスタンス化に使用する場合、PCInitiateメッセージには、予約済みのPLSP-ID 0のLSPオブジェクトを含める必要があります。LSPオブジェクトには、PCCが割り当てたPLSP-ID間の相関に使用されるSYMBOLIC-PATH-NAME TLVを含める必要がありますそしてLSP。
The PCInitiate message, when used to instantiate an LSP, MUST contain an ERO for the LSP.
PCInitiateメッセージは、LSPのインスタンス化に使用される場合、LSPのEROを含んでいる必要があります。
For an instantiation request of an RSVP-signaled LSP, the destination address may be needed. The PCC MAY determine it from a provided object (e.g., ERO) or a local decision. Alternatively, the END-POINTS object MAY be included to explicitly convey the destination addresses to be used in the RSVP-TE signaling. The source address MUST be either specified or left for the PCC to choose by setting it to "0.0.0.0" (if the destination is an IPv4 address) or "::" (if the destination is an IPv6 address).
RSVPシグナルのLSPのインスタンス化要求の場合、宛先アドレスが必要になることがあります。 PCCは、提供されたオブジェクト（EROなど）またはローカルの決定からそれを決定できます（MAY）。代わりに、END-POINTSオブジェクトを含めて、RSVP-TEシグナリングで使用される宛先アドレスを明示的に伝えてもよい（MAY）。送信元アドレスは、PCCが「0.0.0.0」（宛先がIPv4アドレスの場合）または「::」（宛先がIPv6アドレスの場合）に設定して選択するか、そのままにする必要があります。
The PCE MAY include various attributes as per [RFC5440]. The PCC MUST use these values in the LSP instantiation and local values for unspecified parameters. After the LSP setup, the PCC MUST send a PCRpt to the PCE, reflecting these values. The SRP object in the PCRpt message MUST echo the value of the PCInitiate message that triggered the setup. LSPs that were instantiated as a result of a PCInitiate message MUST have the Create flag (Section 5.3.1) set in the LSP object.
PCEには、[RFC5440]のようにさまざまな属性が含まれる場合があります。 PCCは、LSPのインスタンス化でこれらの値を使用する必要があり、指定されていないパラメーターのローカル値を使用する必要があります。 LSPセットアップ後、PCCはこれらの値を反映してPCRptをPCEに送信する必要があります。 PCRptメッセージのSRPオブジェクトは、セットアップをトリガーしたPCInitiateメッセージの値をエコーする必要があります。 PCInitiateメッセージの結果としてインスタンス化されたLSPには、LSPオブジェクトで作成フラグ（セクション5.3.1）が設定されている必要があります。
If the PCC receives a PCInitiate message with a non-zero PLSP-ID and the R flag in the SRP object set to zero, then it MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=8 (Non-zero PLSP-ID in the LSP Initiate Request).
PCCが、ゼロ以外のPLSP-IDと、SRPオブジェクトのRフラグがゼロに設定されたPCInitiateメッセージを受信した場合、Error-type = 19（無効な操作）およびError-value = 8のPCErrメッセージを送信する必要があります。 （LSP開始要求のゼロ以外のPLSP-ID）。
If the PCC receives a PCInitiate message without an ERO and the R flag in the SRP object set to zero, then it MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=9 (ERO object missing).
PCCがEROなしでPCInitiateメッセージを受信し、SRPオブジェクトのRフラグがゼロに設定されている場合、PCCはError-type = 6（Mandatory Object missing）およびError-value = 9（ERO object missing）を含むPCErrメッセージを送信する必要があります。 ）。
If the PCC receives a PCInitiate message without a SYMBOLIC-PATH-NAME TLV, then it MUST send a PCErr message with Error-type=10 (Reception of an invalid object) and Error-value=8 (SYMBOLIC-PATH-NAME TLV missing).
PCCがSYMBOLIC-PATH-NAME TLVのないPCInitiateメッセージを受信した場合、PCErrメッセージをError-type = 10（無効なオブジェクトの受信）およびError-value = 8（SYMBOLIC-PATH-NAME TLVなし）で送信する必要があります。 ）。
The PCE MUST NOT provide a symbolic path name that conflicts with the symbolic path name of any existing LSP in the PCC. (Existing LSPs may be either statically configured or initiated by another PCE.) If there is a conflict with the symbolic path name of an existing LSP, the PCC MUST send a PCErr message with Error-type=23 (Bad Parameter value) and Error-value=1 (SYMBOLIC-PATH-NAME in use). The only exception to this rule is for LSPs for which the State Timeout Interval timer is running (see Section 6).
PCEは、PCC内の既存のLSPのシンボリックパス名と競合するシンボリックパス名を提供してはなりません（MUST NOT）。 （既存のLSPは、静的に構成されているか、別のPCEによって開始されている可能性があります。）既存のLSPのシンボリックパス名と競合する場合、PCCは、Error-type = 23（不正なパラメーター値）およびErrorのPCErrメッセージを送信する必要があります。 -value = 1（SYMBOLIC-PATH-NAMEが使用中）。このルールの唯一の例外は、State Timeout Intervalタイマーが実行されているLSPの場合です（セクション6を参照）。
If the PCC determines that the LSP parameters proposed in the PCInitiate message are unacceptable, it MUST send a PCErr message with Error-type=24 (PCE instantiation error) and Error-value=1 (Unacceptable instantiation parameters). If the PCC encounters an internal error during the processing of the PCInitiate message, it MUST send a PCErr message with Error-type=24 (PCE instantiation error) and Error-value=2 (Internal error).
PCInitiateメッセージで提案されたLSPパラメータが受け入れられないとPCCが判断した場合、PCCはError-type = 24（PCEインスタンス化エラー）およびError-value = 1（受け入れられないインスタンス化パラメータ）のPCErrメッセージを送信しなければなりません（MUST）。 PCCは、PCInitiateメッセージの処理中に内部エラーを検出した場合、Error-type = 24（PCEインスタンス化エラー）およびError-value = 2（内部エラー）のPCErrメッセージを送信する必要があります。
A PCC MUST relay errors it encounters in the setup of a PCE-initiated LSP to the PCE by sending a PCErr message with Error-type=24 (PCE instantiation error) and Error-value=3 (Signaling error). The PCErr message MUST echo the SRP-ID-number of the PCInitiate message. The PCEP-ERROR object SHOULD include the RSVP_ERROR_SPEC TLV (if an RSVP ERROR_SPEC object was returned to the PCC by a downstream node).
PCCは、PCEによって開始されたLSPのセットアップで発生したエラーを、Error-type = 24（PCEインスタンス化エラー）およびError-value = 3（信号エラー）のPCErrメッセージを送信してPCEに中継する必要があります。 PCErrメッセージは、PCInitiateメッセージのSRP-ID-numberをエコーする必要があります。 PCEP-ERRORオブジェクトには、RSVP_ERROR_SPEC TLVを含める必要があります（ダウンストリームノードによってRSVP ERROR_SPECオブジェクトがPCCに返された場合）。
After the LSP is set up, errors in RSVP signaling are reported in PCRpt messages, as described in [RFC8231].
[RFC8231]で説明されているように、LSPがセットアップされた後、RSVPシグナリングのエラーがPCRptメッセージで報告されます。
On successful completion of the LSP instantiation, the PCC MUST send a PCRpt message. The LSP object message MUST contain a non-zero PLSP-ID that uniquely identifies the LSP within this PCC and MUST have the Create flag (Section 5.3.1) and Delegate flag set. The SRP object MUST contain an SRP-ID-number that echoes the value from the PCInitiate message that triggered the setup. The PCRpt MUST include the attributes that the PCC used to instantiate the LSP.
LSPのインスタンス化が正常に完了すると、PCCはPCRptメッセージを送信する必要があります。 LSPオブジェクトメッセージには、このPCC内のLSPを一意に識別するゼロ以外のPLSP-IDが含まれている必要があり、作成フラグ（セクション5.3.1）とデリゲートフラグが設定されている必要があります。 SRPオブジェクトには、セットアップをトリガーしたPCInitiateメッセージからの値をエコーするSRP-ID-numberが含まれている必要があります。 PCRptには、PCCがLSPのインスタンス化に使用した属性を含める必要があります。
A PCC SHOULD be able to place a limit on either the number of LSPs or the percentage of resources that are allocated to honor PCE-initiated LSP requests. As soon as that limit is reached, the PCC MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=6 (PCE-initiated LSP limit reached) and is free to drop any incoming PCInitiate messages without additional processing.
PCCは、PCEが開始したLSP要求を受け入れるために割り当てられるLSPの数またはリソースのパーセンテージのいずれかに制限を設定できる必要があります（SHOULD）。その制限に達するとすぐに、PCCはError-type = 19（無効な操作）およびError-value = 6（PCEによって開始されたLSP制限に達した）のPCErrメッセージを送信する必要があり、追加のPCなしで着信PCInitiateメッセージを自由にドロップできます。処理。
Similarly, the PCE SHOULD be able to place a limit on either the number of PCInitiate messages pending for a particular PCC or the time it waits for a response (positive or negative) to a PCInitiate message from a PCC, and it MAY take further action (such as closing the session or removing all its LSPs) if this limit is reached.
同様に、PCEは、特定のPCCに対して保留中のPCInitiateメッセージの数、またはPCCからのPCInitiateメッセージへの応答（肯定または否定）を待機する時間のいずれかに制限を設定できる必要があり（SHOULD）、さらにアクションを実行できます（MAY） （セッションを閉じる、またはそのすべてのLSPを削除するなど）この制限に達した場合。
The LSP object is defined in [RFC8231] and included here for easy reference with the addition of the new Create (C) flag.
LSPオブジェクトは[RFC8231]で定義されており、新しいCreate（C）フラグを追加して簡単に参照できるようにここに含まれています。
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 |Flags |C| O |A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The LSP Object Format
図4：LSPオブジェクト形式
A new flag, the C flag, is introduced. On a PCRpt message, the C flag set to 1 indicates that this LSP was created via a PCInitiate message. The C flag MUST be set to 1 on each PCRpt message for the LSP's duration of existence. The C flag allows PCEs to be aware of which LSPs were PCE initiated (a state that would otherwise only be known by the PCC and the PCE that initiated them).
新しいフラグであるCフラグが導入されました。 PCRptメッセージでは、1に設定されたCフラグは、このLSPがPCInitiateメッセージを介して作成されたことを示します。 LSPの存続期間中、各PCRptメッセージでCフラグを1に設定する必要があります。 Cフラグを使用すると、PCEは、どのLSPがPCEで開始されたか（そうでなければPCCとPCEが開始したPCEだけが知る状態）を認識できます。
The optional SPEAKER-ENTITY-ID TLV defined in [RFC8232] MAY be included in the LSP object in a PCRpt message as an optional TLV for LSPs for which the C flag is 1. The SPEAKER-ENTITY-ID TLV identifies the PCE that initiated the creation of the LSP on all PCEP sessions, a state that would otherwise only be known by the PCC and the PCE that initiated the LSP. If the TLV appears in a PCRpt for an LSP for which the C flag is 0, the LSP MUST be ignored, and the PCE MUST send a PCErr message with Error-type=23 (Bad parameter value) and Error-value=2 (Speaker identity included for an LSP that is not PCE initiated).
[RFC8232]で定義されているオプションのSPEAKER-ENTITY-ID TLVは、Cフラグが1であるLSPのオプションのTLVとしてPCRptメッセージのLSPオブジェクトに含めることができます（SPEAKER-ENTITY-ID TLVは、開始したPCEを識別します）すべてのPCEPセッションでのLSPの作成。それ以外の場合は、LSCを開始したPCCとPCEだけが知っている状態。 TLVがCフラグが0のLSPのPCRptに表示される場合、LSPは無視されなければならず、PCEはError-type = 23（Bad parameter value）およびError-value = 2（ PCEで開始されていないLSPに含まれるスピーカーID）。
A PCE can initiate the removal of a PCE-initiated LSP by sending a PCInitiate message with an LSP object carrying the PLSP-ID of the LSP to be removed and an SRP object with the R flag set (see Section 5.2). A PLSP-ID of zero removes all LSPs with the C flag set to 1 (in their LSP object) that are delegated to the PCE.
PCEは、削除するLSPのPLSP-IDを運ぶLSPオブジェクトとRフラグが設定されたSRPオブジェクトを含むPCInitiateメッセージを送信することにより、PCEによって開始されたLSPの削除を開始できます（セクション5.2を参照） PLSP-IDが0の場合、PCEに委任された（LSPオブジェクトで）Cフラグが1に設定されているすべてのLSPが削除されます。
If the PLSP-ID is unknown, the PCC MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=3 (Unknown PLSP-ID) [RFC8231].
PLSP-IDが不明な場合、PCCはPCErrメッセージをError-type = 19（無効な操作）およびError-value = 3（不明なPLSP-ID）[RFC8231]で送信する必要があります。
If the PLSP-ID specified in the PCInitiate message is not delegated to the PCE, the PCC MUST send a PCErr message with Error-type=19 (Invalid operation) and Error-value=1 (LSP is not delegated) [RFC8231].
PCInitiateメッセージで指定されたPLSP-IDがPCEに委任されていない場合、PCCはError-type = 19（無効な操作）およびError-value = 1（LSPが委任されていない）[RFC8231]のPCErrメッセージを送信する必要があります。
If the PLSP-ID specified in the PCInitiate message was not created by a PCE, the PCC MUST send a PCErr message with Error-type=19 (Invalid operation) and Error-value=9 (LSP is not PCE initiated).
PCInitiateメッセージで指定されたPLSP-IDがPCEによって作成されなかった場合、PCCはError-type = 19（無効な操作）およびError-value = 9（LSPがPCEで開始されない）のPCErrメッセージを送信する必要があります。
Following the removal of the LSP, the PCC MUST send a PCRpt as described in [RFC8231]. The SRP object in the PCRpt MUST include the SRP-ID-number from the PCInitiate message that triggered the removal. The R flag in the SRP object MUST be set.
LSPの削除後、PCCは[RFC8231]で説明されているようにPCRptを送信する必要があります。 PCRptのSRPオブジェクトには、削除をトリガーしたPCInitiateメッセージからのSRP-ID-numberを含める必要があります。 SRPオブジェクトのRフラグを設定する必要があります。
The PCC MUST delegate PCE-initiated LSPs to the PCE upon instantiation. The PCC MUST set the delegation bit to 1 in the PCRpt that includes the assigned PLSP-ID.
PCCは、インスタンス化時にPCEによって開始されたLSPをPCEに委任する必要があります。 PCCは、割り当てられたPLSP-IDを含むPCRptの委任ビットを1に設定する必要があります。
The PCC MUST NOT revoke the delegation for a PCE-initiated LSP on an active PCEP session. Therefore, all PCRpt messages from the PCC to the PCE that owns the delegation MUST have the delegation bit set to 1. If the PCE that owns the delegation receives a PCRpt message with the delegation bit set to 0, then it MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=7 (Delegation for PCE-initiated LSP cannot be revoked). The PCE MAY further react by closing the session.
PCCは、アクティブなPCEPセッションでPCEによって開始されたLSPの委任を取り消すことはできません。したがって、PCCから委任を所有するPCEへのすべてのPCRptメッセージでは、委任ビットが1に設定されている必要があります。委任を所有するPCEが委任ビットが0に設定されたPCRptメッセージを受信する場合は、PCErrメッセージを送信する必要があります。 Error-type = 19（無効な操作）およびError-value = 7（PCEによって開始されたLSPの委任を取り消すことはできません）。 PCEは、セッションを閉じることによってさらに反応する場合があります。
Control over a PCE-initiated LSP can revert to the PCC in two ways. A PCE MAY return a delegation to the PCC to allow for LSP transfer between PCEs. Alternatively, the PCC gains control of an LSP if the PCEP session that it was delegated on fails and the Redelegation Timeout Interval timer expires. In both cases, the LSP becomes an orphan until the expiration of the State Timeout Interval timer [RFC8231].
PCEによって開始されたLSPの制御は、2つの方法でPCCに戻ることができます。 PCEは、PCE間のLSP転送を可能にするために委任をPCCに返す場合があります。または、委任されたPCEPセッションが失敗し、再委任タイムアウト間隔タイマーが期限切れになると、PCCはLSPの制御を取得します。どちらの場合も、状態タイムアウト間隔タイマー[RFC8231]の期限が切れるまで、LSPは孤立になります。
The PCC MAY attempt to redelegate an orphaned LSP by following the procedures of [RFC8231]. Alternatively, if the orphaned LSP was PCE-initiated, then a PCE MAY obtain control over it, as follows.
PCCは、[RFC8231]の手順に従って、孤立したLSPを再委任しようとする場合があります。あるいは、孤立したLSPがPCEによって開始された場合、PCEはそれを次のように制御できます（MAY）。
A PCE (either the original or one of its backups) sends a PCInitiate message that includes just the SRP and LSP objects and carries the PLSP-ID of the LSP it wants to take control of. If the PCC receives a PCInitiate message with a PLSP-ID pointing to an orphaned PCE-initiated LSP, then it MUST redelegate that LSP to the PCE. Any other non-zero PLSP-ID MUST result in the generation of a PCErr message using the rules described in Section 5.4. The State Timeout Interval timer for the LSP is stopped upon the redelegation. After obtaining control of the LSP, the PCE may remove it using the procedures described in this document.
PCE（元のバックアップまたはそのバックアップの1つ）は、SRPオブジェクトとLSPオブジェクトのみを含み、制御したいLSPのPLSP-IDを含むPCInitiateメッセージを送信します。 PCCが、孤立したPCEで開始されたLSPを指すPLSP-IDを含むPCInitiateメッセージを受信した場合、そのLSPをPCEに再委任する必要があります。他のゼロ以外のPLSP-IDは、セクション5.4で説明されているルールを使用してPCErrメッセージを生成する必要があります。 LSPの状態タイムアウト間隔タイマーは、再委任時に停止します。 LSPの制御権を取得した後、PCEは、このドキュメントで説明されている手順を使用してLSPを削除できます。
The State Timeout Interval timer ensures that a PCE crash does not result in automatic and immediate disruption for the services using PCE-initiated LSPs. PCE-initiated LSPs are not removed immediately upon PCE failure. Instead, they are cleaned up on the expiration of this timer. This allows for network cleanup without manual intervention. The PCC MUST support removal of PCE-initiated LSPs as one of the behaviors applied on expiration of the State Timeout Interval timer. The behavior MUST be picked based on local policy and can result in either LSP removal or reverting to operator-defined default parameters.
状態タイムアウト間隔タイマーは、PCEクラッシュが原因で、PCEによって開始されたLSPを使用するサービスが自動的かつ即時に中断されないようにします。 PCEによって開始されたLSPは、PCEの障害が発生してもすぐには削除されません。代わりに、これらはこのタイマーの満了時にクリーンアップされます。これにより、手動操作なしでネットワークのクリーンアップが可能になります。 PCCは、状態タイムアウト間隔タイマーの満了時に適用される動作の1つとして、PCEによって開始されたLSPの削除をサポートする必要があります。動作はローカルポリシーに基づいて選択する必要があり、LSPを削除するか、オペレーターが定義したデフォルトのパラメーターに戻す可能性があります。
LSP State Synchronization procedures are described in Section 5.6 of [RFC8231]. During State Synchronization, a PCC reports the state of its LSPs to the PCE using PCRpt messages, setting the SYNC flag in the LSP object. For PCE-initiated LSPs, the PCC MUST also set the Create flag in the LSP object and MAY include the SPEAKER-ENTITY-ID TLV identifying the PCE that requested the LSP creation. At the end of State Synchronization, the PCE SHOULD send a PCInitiate message to initiate any missing LSPs and/or remove any LSPs that are not wanted. Under some circumstances, depending on the deployment, it might be preferable for a PCE not to send this PCInitiate immediately, or at all. For example, the PCC may be a slow device, or the operator might prefer not to disrupt active flows.
LSP状態同期手順は、[RFC8231]のセクション5.6で説明されています。状態の同期中に、PCCはPCRptメッセージを使用してLSPの状態をPCEに報告し、LSPオブジェクトにSYNCフラグを設定します。 PCEで開始されたLSPの場合、PCCはLSPオブジェクトに作成フラグも設定する必要があり、LSPの作成を要求したPCEを識別するSPEAKER-ENTITY-ID TLVを含めることができます（MAY）。状態同期の最後に、PCEはPCInitiateメッセージを送信して、欠落しているLSPを開始したり、不要なLSPを削除したりする必要があります（SHOULD）。状況によっては、展開によっては、PCEがこのPCInitiateをすぐに送信しないか、まったく送信しない方が望ましい場合があります。たとえば、PCCが遅いデバイスである場合や、オペレーターがアクティブなフローを中断しないことを選択している場合があります。
As detailed below, IANA has allocated code points for the protocol elements defined in this document.
以下に詳述するように、IANAはこのドキュメントで定義されたプロトコル要素にコードポイントを割り当てました。
IANA has registered the following message type within the "PCEP Messages" subregistry of the PCEP Numbers registry. (Note that the early allocation for this message type was called "Initiate"; it has been changed as follows.)
IANAは、PCEP番号レジストリの「PCEPメッセージ」サブレジストリ内に次のメッセージタイプを登録しました。 （このメッセージタイプの初期割り当ては「開始」と呼ばれていました。次のように変更されています。）
Value Meaning Reference
----- -------------------- -------------
12 LSP Initiate Request RFC 8281
[RFC8231] defines the LSP object; per that RFC, IANA created a registry to manage the value of the LSP object's Flag field. IANA has allocated a new bit in the "LSP Object Flag Field" subregistry, as follows:
[RFC8231]はLSPオブジェクトを定義します。そのRFCに従って、IANAはLSPオブジェクトのフラグフィールドの値を管理するためのレジストリを作成しました。 IANAは、次のように、「LSPオブジェクトフラグフィールド」サブレジストリに新しいビットを割り当てました。
Bit Description Reference
--- ----------- -------------
4 Create RFC 8281
4 RFC 8281を作成する
IANA has created a new subregistry, named "SRP Object Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry, to manage the Flag field of the SRP object. New values are to be assigned by Standards Action [RFC8126]. Each bit is tracked with the following qualities: bit number (counting from bit 0 as the most significant bit), description, and defining RFC.
IANAは、「Path Computation Element Protocol（PCEP）Numbers」レジストリ内に「SRP Object Flag Field」という名前の新しいサブレジストリを作成し、SRPオブジェクトのFlagフィールドを管理します。新しい値は、標準アクション[RFC8126]によって割り当てられます。各ビットは、ビット番号（ビット0から最上位ビットとして数える）、説明、およびRFCの定義によって追跡されます。
The following values are defined in this document:
このドキュメントでは、次の値が定義されています。
Bit Description Reference
--- ----------- -------------
31 LSP-Remove RFC 8281
31 LSP-Remove RFC 8281
[RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV; per that RFC, IANA created a registry to manage the value of the STATEFUL-PCE-CAPABILITY TLV's Flag field. IANA has allocated a new bit in the STATEFUL-PCE-CAPABILITY TLV Flag Field registry, as follows:
[RFC8231]は、STATEFUL-PCE-CAPABILITY TLVを定義しています。そのRFCに従って、IANAはSTATEFUL-PCE-CAPABILITY TLVのフラグフィールドの値を管理するレジストリを作成しました。 IANAは、次のように、STATEFUL-PCE-CAPABILITY TLVフラグフィールドレジストリに新しいビットを割り当てました。
Bit Description Reference
--- -------------------------------- -------------
29 LSP-INSTANTIATION-CAPABILITY (I) RFC 8281
29 LSP-INSTANTIATION-CAPABILITY（I）RFC 8281
IANA has registered the following error types and error values within the "PCEP-ERROR Object Error Types and Values" subregistry of the PCEP Numbers registry.
IANAは、PCEP番号レジストリの「PCEP-ERRORオブジェクトエラータイプと値」サブレジストリ内に次のエラータイプとエラー値を登録しました。
Error-Type Meaning
---------- --------------
10 Reception of an invalid object
Error-value=8: SYMBOLIC-PATH-NAME TLV missing
エラー値= 8：SYMBOLIC-PATH-NAME TLVがありません
19 Invalid Operation
19無効な操作
Error-value=6: PCE-initiated LSP limit reached
Error-value=7: Delegation for PCE-initiated LSP cannot
be revoked
Error-value=8: Non-zero PLSP-ID in LSP Initiate Request
Error-value=9: LSP is not PCE initiated
Error-value=10: PCE-initiated operation-frequency limit
reached
23 Bad parameter value
23不正なパラメーター値
Error-value=1: SYMBOLIC-PATH-NAME in use Error-value=2: Speaker identity included for an LSP that is not PCE initiated
エラー値= 1：SYMBOLIC-PATH-NAMEが使用中エラー値= 2：PCEで開始されていないLSPにスピーカーIDが含まれています
24 LSP instantiation error
24 LSPインスタンス化エラー
Error-value=1: Unacceptable instantiation parameters
Error-value=2: Internal error
Error-value=3: Signaling error
The security considerations described in [RFC8231] apply to the extensions described in this document. Additional considerations related to a malicious PCE are introduced.
[RFC8231]で説明されているセキュリティの考慮事項は、このドキュメントで説明されている拡張機能に適用されます。悪意のあるPCEに関連する追加の考慮事項が導入されました。
The LSP instantiation mechanism described in this document allows a PCE to generate state on the PCC and throughout the network. As a result, it introduces a new attack vector: an attacker may flood the PCC with LSP instantiation requests and consume network and LSR resources by either spoofing messages or compromising the PCE itself.
このドキュメントで説明するLSPインスタンス化メカニズムにより、PCEはPCC上およびネットワーク全体で状態を生成できます。その結果、新しい攻撃ベクトルが導入されます。攻撃者は、PCCにLSPインスタンス化要求をフラッディングし、メッセージを偽装するか、PCE自体を危険にさらすことにより、ネットワークおよびLSRリソースを消費する可能性があります。
A PCC can protect itself from such an attack by imposing a limit on either the number of LSPs or the percentage of resources that are allocated to honor PCE-initiated LSP requests. As soon as that limit is reached, the PCC MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=6 (PCE-initiated LSP limit reached) and is free to drop any incoming PCInitiate messages for LSP initiation without additional processing.
PCCは、LSEの数またはPCEが開始したLSP要求を受け入れるために割り当てられるリソースのパーセンテージに制限を課すことにより、このような攻撃から身を守ることができます。その制限に達するとすぐに、PCCはError-type = 19（無効な操作）およびError-value = 6（PCEによって開始されたLSP制限に達した）のPCErrメッセージを送信する必要があり、LSPの着信PCInitiateメッセージを自由にドロップできます。追加処理なしの開始。
Rapid flaps triggered by the PCE can also be an attack vector. A PCC can protect itself from such an attack by imposing a limit on the number of flaps per unit of time that it allows a PCE to generate. As soon as that limit is reached, a PCC MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=10 (PCE-initiated operation-frequency limit reached) and is free to treat the session as having reached the limit in terms of resources allocated to honor PCE-initiated LSP requests, either permanently or for a locally-defined cool-off period.
PCEによってトリガーされる急速なフラップも、攻撃ベクトルになる可能性があります。 PCCは、PCEが生成できる単位時間あたりのフラップ数に制限を課すことにより、このような攻撃から身を守ることができます。その制限に達するとすぐに、PCCはError-type = 19（無効な操作）およびError-value = 10（PCEによって開始された操作の頻度の制限に達した）のPCErrメッセージを送信する必要があり、セッションをPCEが開始したLSPリクエストを永続的にまたはローカルで定義されたクールオフ期間に応じて割り当てるために割り当てられたリソースの制限に達しました。
The LSP instantiation mechanism described in this document requires the PCE to keep state for LSPs that it instantiates and relies on the PCC responding (with either a state report or an error message) to requests for LSP instantiation. A malicious PCC or one that reached the limit of the number of PCE-initiated LSPs can ignore PCE requests and consume PCE resources. A PCE can protect itself by imposing a limit on the number of requests pending or by setting a timeout, and it MAY take further action such as closing the session or removing all the LSPs it initiated.
このドキュメントで説明するLSPのインスタンス化メカニズムでは、PCEがインスタンス化するLSPの状態を保持し、PCCが（状態レポートまたはエラーメッセージのいずれかで）LSPのインスタンス化の要求に応答することを前提としています。悪意のあるPCCまたはPCEによって開始されたLSPの数の制限に達したPCCは、PCE要求を無視してPCEリソースを消費する可能性があります。 PCEは、保留中の要求の数に制限を課したり、タイムアウトを設定したりして、自分自身を保護できます。また、PCEは、セッションを閉じたり、開始したすべてのLSPを削除したりするなど、さらにアクションを実行できます。
[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>。
[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、Ed。、 "Path Computation Element（PCE）Communication Protocol（PCEP）"、RFC 5440、DOI 10.17487 / RFC5440、March 2009、<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>。
[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>。
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/info/rfc8231>.
[RFC8231] Crabbe、E.、Minei、I.、Medved、J。、およびR. Varga、「Pathful Computation Element Communication Protocol（PCEP）Extensions for Stateful PCE」、RFC 8231、DOI 10.17487 / RFC8231、2017年9月、< https://www.rfc-editor.org/info/rfc8231>。
[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, <https://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月、<https://www.rfc-editor.org/info/rfc8232>。
[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> 。
[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>。
[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>。
Acknowledgments
謝辞
We would like to thank Jan Medved, Ambrose Kwong, Ramon Casellas, Cyril Margaria, Dhruv Dhody, Raveendra Trovi, and Jon Hardwick for their contributions to this document.
このドキュメントへの貢献に対して、Jan Medved、Ambrose Kwong、Ramon Casellas、Cyril Margaria、Dhruv Dhody、Raveendra Trovi、およびJon Hardwickに感謝します。
Authors' Addresses
著者のアドレス
Edward Crabbe Individual Contributor
Edward Crabbe個人貢献者
Email: edward.crabbe@gmail.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
Siva Sivabalan Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 United States of America
Siva Sivabalan Cisco Systems、Inc. 170 West Tasman Dr. San Jose、CA 95134アメリカ合衆国
Email: msiva@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