[要約] RFC 8934は、状態を持つPCE（Path Computation Element）を用いてラベルスイッチパス（LSP）のスケジューリングを行うためのPCEP（PCE Communication Protocol）の拡張に関するものです。この文書の目的は、ネットワークリソースの予約とスケジューリングを効率的に行うためのプロトコル拡張を定義することにあります。利用場面としては、帯域幅が限られた時間帯に特定の通信を優先させる、あるいは将来のイベントに向けてネットワークリソースを事前に確保する場合などが挙げられます。
Internet Engineering Task Force (IETF) H. Chen, Ed.
Request for Comments: 8934 Futurewei
Category: Standards Track Y. Zhuang, Ed.
ISSN: 2070-1721 Q. Wu
Huawei
D. Ceccarelli
Ericsson
October 2020
PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE
ステートフルPCEによるラベルスイッチパス（LSP）スケジューリングのためのPCE通信プロトコル（PCE）拡張
Abstract
概要
This document defines a set of extensions to the stateful PCE Communication Protocol (PCEP) to enable Label Switched Path (LSP) path computation, activation, setup, and deletion based on scheduled time intervals for the LSP and the actual network resource usage in a centralized network environment, as stated in RFC 8413.
このドキュメントは、LSPのスケジュールされた時間間隔と、集中化されたネットワークリソースの使用量に基づいて、ラベルスイッチングパス（LSP）のパスの計算、アクティベーション、セットアップ、および削除を有効にするためのステートフルPCE通信プロトコル（PCE）の一連の拡張子を定義します。RFC 8413に記載されているネットワーク環境。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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）の製品です。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/rfc8934.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8934で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
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 LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Conventions Used in This Document
2.1. Terminology
3. Motivation and Objectives
4. Procedures and Mechanisms
4.1. LSP Scheduling Overview
4.2. Support of LSP Scheduling
4.2.1. LSP Scheduling
4.2.2. Periodical LSP Scheduling
4.3. Scheduled LSP Creation
4.4. Scheduled LSP Modifications
4.5. Scheduled LSP Activation and Deletion
5. PCEP Objects and TLVs
5.1. Stateful PCE Capability TLV
5.2. LSP Object
5.2.1. SCHED-LSP-ATTRIBUTE TLV
5.2.2. SCHED-PD-LSP-ATTRIBUTE TLV
6. The PCEP Messages
6.1. The PCRpt Message
6.2. The PCUpd Message
6.3. The PCInitiate Message
6.4. The PCReq message
6.5. The PCRep Message
6.6. The PCErr Message
7. Security Considerations
8. Manageability Consideration
8.1. Control of Function and Policy
8.2. Information and Data Models
8.3. Liveness Detection and Monitoring
8.4. Verify Correct Operations
8.5. Requirements on Other Protocols
8.6. Impact on Network Operations
9. IANA Considerations
9.1. PCEP TLV Type Indicators
9.1.1. SCHED-PD-LSP-ATTRIBUTE TLV Opt Field
9.1.2. Schedule TLVs Flag Field
9.2. STATEFUL-PCE-CAPABILITY TLV Flag Field
9.3. PCEP-ERROR Object Error Types and Values
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
The PCE Communication Protocol (PCEP) defined in [RFC5440] is used between a Path Computation Element (PCE) and a Path Computation Client (PCC) (or other PCE) to enable path computation of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs).
[RFC5440]で定義されているPCE通信プロトコル（PCE）は、PATH計算要素（PCE）とパス計算クライアント（PCC）（またはPCC）（または他のPCE）の間で使用され、マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリングラベルのパスが切り替わります。パス（TE LSP）
[RFC8231] describes a set of extensions to PCEP to provide stateful control. A stateful PCE has access to not only the information carried by the network's Interior Gateway Protocol (IGP) but also the set of active paths and their reserved resources for its computations. The additional state allows the PCE to compute constrained paths while considering individual LSPs and their interactions.
[RFC8231]は、ステートフル制御を提供するためのPCEPへの一連の拡張子を説明しています。ステートフルPCEは、ネットワークのインテリアゲートウェイプロトコル（IGP）によって実行されている情報だけでなく、その計算のためのアクティブなパスとそれらの予約されたリソースにもアクセスできます。追加の状態は、PCEが個々のLSPとそれらの相互作用を考慮しながら制約されたパスを計算することを可能にします。
Traditionally, the usage and allocation of network resources, especially bandwidth, can be supported by a Network Management System (NMS) operation such as path pre-establishment. However, this does not provide efficient usage of network resources. The established paths reserve the resources forever, so they cannot be used by other services even when they are not used for transporting any service. [RFC8413] then provides a framework that describes and discusses the problem and defines an appropriate architecture for the scheduled reservation of TE resources.
伝統的に、ネットワークリソース、特に帯域幅の使用および割り当ては、パス前確立などのネットワーク管理システム（NMS）操作によってサポートされ得る。ただし、これはネットワークリソースの効率的な使用を提供しません。確立されたパスは永久にリソースを常に予約します。[RFC8413]は、問題を説明し説明し、テストリソースの予約のための適切なアーキテクチャを定義するフレームワークを提供します。
The scheduled reservation of TE resources allows network operators to reserve resources in advance according to the agreements with their customers and allows them to transmit data about scheduling, such as a specified start time and duration (for example, for a scheduled bulk data replication between data centers). It enables the activation of bandwidth usage at the time the service is really being used while letting other services use the bandwidth when it is not being used by this service. The requirement of scheduled LSP provisioning is mentioned in [RFC8231] and [RFC7399]. Also, for deterministic networks [RFC8655], the scheduled LSP or temporal LSP can provide better network resource usage for guaranteed links. This idea can also be applied in segment routing [RFC8402] to schedule the network resources over the whole network in a centralized manner.
TEリソースの予約予約は、ネットワーク事業者が顧客との契約に従って事前にリソースを予約し、指定された開始時刻と期間（たとえば、データ間のスケジュールされたバルクデータ複製のために）スケジューリングに関するデータを送信することができます。中心部）。他のサービスが使用されていないときに、サービスが本当に使用されているときに帯域幅の使用を活性化することができます。スケジュールされたLSPプロビジョニングの要件は[RFC8231]と[RFC7399]に記載されています。また、決定論的ネットワーク[RFC8655]では、スケジュールされたLSPまたはTemporal LSPは保証リンクのためのより良いネットワークリソース使用量を提供することができます。このアイデアは、ネットワーク全体を介してネットワークリソースを集中的にスケジュールするために、セグメントルーティング[RFC8402]にも適用できます。
With this in mind, this document defines a set of needed extensions to PCEP used for stateful PCEs so as to enable LSP scheduling for path computation and LSP setup/deletion based on the actual network resource usage duration of a traffic service. A scheduled LSP is characterized by a start time and a duration. When the end of the LSP life is reached, it is deleted to free up the resources for other LSPs (scheduled or not).
これを念頭に置いて、このドキュメントは、トラフィックサービスの実際のネットワークリソース使用期間に基づいて、パス計算およびLSPセットアップ/削除のLSPスケジューリングを可能にするために、ステートフルPCEに必要な拡張機能のセットを定義します。スケジュールされたLSPは開始時間と期間によって特徴付けられます。LSP寿命の終わりに達すると、他の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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The following terminology is reused from existing PCE documents.
次の用語は既存のPCE文書から再利用されます。
* Active Stateful PCE [RFC8051]
* アクティブステートフルPCE [RFC8051]
* Delegation [RFC8051]
* 代表団[RFC8051]
* PCE-initiated LSP [RFC8281]
* PCE開始LSP [RFC8281]
* PCC [RFC5440]
* PCC [RFC5440]
* PCE [RFC5440]
* PCE [RFC5440]
* TE LSP [RFC5440]
* TE LSP [RFC5440]
* TED (Traffic Engineering Database) [RFC5440]
* TED（トラフィックエンジニアリングデータベース）[RFC5440]
* LSP-DB (LSP State Database) [RFC8051]
* LSP-DB（LSP状態データベース）[RFC8051]
In addition, this document defines the following terminologies.
さらに、この文書は次の用語を定義しています。
Scheduled TE LSP (or Scheduled LSP for short): An LSP with scheduling attributes that carries traffic flow demand at a start time and lasts for a certain duration (or from a start time to an end time, where the end time is the start time plus the duration). A scheduled LSP is also called a "temporal LSP". The PCE operates path computation per LSP availability for the required time and duration.
スケジュールされたTE LSP（またはShortのスケジュールされたLSP）：開始時にトラフィックフローの需要を担うスケジューリング属性を持つLSPと、一定期間（または終了時刻から終了時刻まで、終了時刻が開始時刻）プラス期間）。スケジュールされたLSPは「一時的なLSP」とも呼ばれます。PCEは、必要な時間と期間のLSPの可用性ごとのパス計算を操作します。
Scheduled LSP-DB (SLSP-DB): A database of scheduled LSPs.
スケジュールされたLSP-DB（SLSP-DB）：スケジュールされたLSPのデータベース。
Scheduled TED: Traffic engineering database with the awareness of scheduled resources for TE. This database is generated by the PCE from the information in the TED and scheduled LSP-DB; it allows knowing, at any time, the expected amount of available resources (discounting the possibility of failures in the future).
スケジュールされたTED：TEのためのスケジュールされたリソースを認識したトラフィックエンジニアリングデータベース。このデータベースは、TEDおよびスケジュールされたLSP-DB内の情報からPCEによって生成されます。それはいつでも、利用可能な資源の予想される額（将来の失敗の可能性を引き受ける）を知ることができます。
Start time (Start-Time): This value indicates when the scheduled LSP is used and the corresponding LSP must be set up and active. At other times (i.e., before the start time or after the start time plus duration), the LSP can be inactive to include the possibility of the resources being used by other services.
開始時刻（開始時刻）：この値は、スケジュールされたLSPがいつ使用され、対応するLSPを設定してアクティブにする必要があります。他の時点で（開始時刻以前または開始時間と期間の後に）は、LSPは他のサービスによって使用されている可能性を含むようにLSPを非アクティブにすることができる。
Duration: This value indicates the length of time that the LSP carries a traffic flow and the corresponding LSP must be set up and active. At the end of the duration, the LSP is torn down and removed from the database.
期間：この値は、LSPがトラフィックフローを搬送し、対応するLSPを設定してアクティブにする必要があります。期間の最後に、LSPは破棄されてデータベースから削除されます。
A stateful PCE [RFC8231] can support better efficiency by using LSP scheduling described in the use case of [RFC8051]. This requires the PCE to maintain the scheduled LSPs and their associated resource usage (e.g., bandwidth for packet-switched network) as well as have the ability to trigger signaling for the LSP setup/tear-down at the correct time.
ステートフルPCE [RFC8231]は、[RFC8051]のユースケースに記載されているLSPスケジューリングを使用することで、より良い効率をサポートできます。これには、スケジュールされたLSPとそれらの関連リソース使用量（例えば、パケット交換ネットワークのための帯域幅）を維持することと、正しい時点でLSPセットアップ/ティームダウンのシグナリングをトリガすることができます。
Note that existing configuration tools can be used for LSP scheduling, but as highlighted in Section 3.1.3 of [RFC8231] as well as discussions in [RFC8413], doing this as a part of PCEP in a centralized manner has obvious advantages.
既存の設定ツールはLSPスケジューリングに使用できますが、[RFC8231]のセクション3.1.3で強調表示されているとおり、[RFC8413]では、PCEPの一部としての議論は明らかな利点を持っています。
This document provides a set of extensions to PCEP to enable LSP scheduling for LSP creation/deletion under the stateful control of a PCE and according to traffic service requests from customers, so as to improve the usage of network resources.
このドキュメントでは、PCEのステートフルコントロールの下でLSPのスケジューリングを可能にし、ネットワークリソースの使用状況を改善するために、LSPの作成/削除のLSPスケジューリングを可能にします。
LSP scheduling allows PCEs and PCCs to provide scheduled LSP for customers' traffic services at its actual usage time, so as to improve the network resource utilization efficiency.
LSPスケジューリングにより、ネットワークリソースの利用効率を向上させるために、PCEとPCCは実際の使用時間で顧客のトラフィックサービスのスケジュールされたLSPを提供することができます。
For stateful PCE supporting LSP scheduling, there are two types of LSP databases used in this document. One is the LSP-DB defined in PCEP [RFC8231], while the other is the scheduled LSP database (SLSP-DB). The SLSP-DB records scheduled LSPs and is used in conjunction with the TED and LSP-DB. Note that the two types of LSP databases can be implemented in one physical database or two different databases. This is an implementation matter, and this document does not state any preference.
LSPスケジューリングをサポートするステートフルPCEの場合、このドキュメントでは2種類のLSPデータベースが使用されています。1つはPCEP [RFC8231]で定義されているLSP-DBですが、もう1つはスケジュールされたLSPデータベース（SLSP-DB）です。SLSP-DBはスケジュールされたLSPを記録し、TEDとLSP-DBと組み合わせて使用されます。2種類のLSPデータベースは、1つの物理データベースまたは2つの異なるデータベースに実装できます。これは実装の問題であり、この文書は好みを述べていません。
Furthermore, a scheduled TED can be generated from the scheduled LSP-DB, LSP-DB, and TED to indicate the network links and nodes with resource availability information for now and the future. The scheduled TED MUST be maintained by all PCEs within the network environment.
さらに、スケジュールされたTEDは、スケジュールされたLSP-DB、LSP-DB、およびTEDから、現在および未来のためのリソースの可用性情報を持つネットワークリンクとノードを示すようにします。スケジュールされたTEDは、ネットワーク環境内のすべてのPCEによって維持されなければなりません。
In the case of implementing PCC-initiated scheduled LSPs, when delegating a scheduled LSP, a PCC MUST include that LSP's scheduling parameters (see Section 5.2.1), including the start time and duration, using a Path Computation State Report (PCRpt) message. Since the LSP is not yet signaled, at the time of delegation, the LSP would be in down state. Upon receiving the delegation of the scheduled LSP, a stateful PCE MUST check whether the parameters are valid. If they are valid, it SHALL check the scheduled TED for the network resource availability on network nodes, compute a path for the LSP with the scheduling information, and update to the PCC as per the active stateful PCE techniques [RFC8231].
PCC開始スケジュールされたLSPの実装の場合、スケジュールされたLSPを委任するときには、PCCは、PATH計算状態レポート（PCRPT）メッセージを使用した、開始時間と期間を含むLSPのスケジューリングパラメータ（セクション5.2.1を参照）を含める必要があります。。LSPはまだシグナリングされていないので、委任時にLSPはダウン状態になります。スケジュールされたLSPの委任を受け取ると、ステートフルPCEは、パラメータが有効かどうかを確認する必要があります。有効であれば、ネットワークノード上のネットワークリソースの可用性のためにスケジュールされたTEDをチェックし、スケジューリング情報を使用してLSPのパスを計算し、ActiveステートフルPCEテクニック[RFC8231]に従ってPCCに更新されます。
Note that the active stateful PCE can update to the PCC with the path for the scheduled LSP at any time. However, the PCC should not signal the LSP over the path after receiving these messages since the path is not active yet; the PCC signals the LSP at the start time.
アクティブなステートフルPCEは、いつでもスケジュールされたLSPのパスを持つPCCに更新できます。ただし、パスがまだアクティブではないため、PCCはこれらのメッセージを受信した後にパスを介してLSPをシグナリングしないでください。PCCは開始時にLSPを信号にします。
In the case of multiple PCEs within a single domain, the PCE would need to synchronize their scheduling information with other PCEs within the domain. This could be achieved by proprietary database-synchronization techniques or via a possible PCEP extension (see [PCE-STATE-SYNC]). The technique used to synchronize an SLSP-DB is out of scope for this document. When the scheduling information is out of synchronization among some PCEs, some scheduled LSPs may not be set up successfully.
単一のドメイン内の複数のPCESの場合、PCEはそれらのスケジューリング情報をドメイン内の他のPCEと同期させる必要があるであろう。これは、独自のデータベース同期技術によって、または可能なPCEP拡張を介して達成することができます（[PCE-STATE-SYNC]を参照）。SLSP-DBを同期させるために使用される技術はこの文書の範囲外です。スケジューリング情報が一部のPCE間の同期不足の場合、一部のスケジュールされたLSPは正常に設定されていない可能性があります。
The scheduled LSP can also be initiated by a PCE itself. In the case of implementing a PCE-initiated scheduled LSP, the stateful PCE SHALL check the network resource availability for the traffic, compute a path for the scheduled LSP, and initiate a scheduled LSP at the PCC and synchronize the scheduled LSP to other PCEs. Note that the PCC could be notified immediately or at the start time of the scheduled LSP, based on the local policy. In the former case, the SCHED-LSP-ATTRIBUTE TLV (see Section 5.2.1) MUST be included in the message, whereas for the latter, the SCHED-LSP-ATTRIBUTE TLV SHOULD NOT be included. Either way, the synchronization to other PCEs MUST be done when the scheduled LSP is created.
スケジュールされたLSPはPCE自体によっても開始され得る。PCE開始されたスケジュールされたLSPを実装する場合、ステートフルPCEはトラフィックのネットワークリソースの可用性をチェックし、スケジュールされたLSPのパスを計算し、PCCでスケジュールされたLSPを開始し、スケジュールされたLSPを他のPCSに同期させるものとします。ローカルポリシーに基づいて、PCCにスケジュールされたLSPのすぐにまたは開始時に通知することができます。前者の場合、sched-lsp-attribute tlv（セクション5.2.1を参照）をメッセージに含める必要がありますが、後者の場合、sched-lsp-属性TLVを含めるべきではありません。いずれにせよ、スケジュールされたLSPが作成されたときに他のPCSへの同期を実行する必要があります。
In both modes, for activation of scheduled LSPs, the PCC MUST initiate the setup of the scheduled LSP at the start time. Similarly, on the scheduled usage expiry, the PCC MUST initiate the removal of the LSP based on the flag set in the SCHED-LSP-ATTRIBUTE TLV.
両方のモードでは、スケジュールされたLSPの起動のために、PCCは開始時にスケジュールされたLSPの設定を開始する必要があります。同様に、スケジュールされた使用状況期限切れでは、PCCはSCHED-LSP-属性TLVに設定されているフラグに基づいてLSPの削除を開始する必要があります。
For a scheduled LSP, a user configures it with an arbitrary scheduling period from time Ta to time Tb, which may be represented as [Ta, Tb].
スケジュールされたLSPの場合、ユーザは、時刻Taから時刻tbまで任意のスケジューリング期間で構成され、これは[Ta、Tb]として表すことができる。
When an LSP is configured with arbitrary scheduling period [Ta, Tb], a path satisfying the constraints for the LSP in the scheduling period is computed, and the LSP along the path is set up to carry traffic from time Ta to time Tb.
LSPが任意のスケジューリング期間[Ta、Tb]で構成されている場合、スケジューリング期間内のLSPの制約を満たす経路が計算され、経路に沿ったLSPは時刻Taから時刻tbへのトラフィックを搬送するように設定される。
In addition to LSP scheduling at an arbitrary time period, there is also periodical LSP scheduling.
任意の期間でLSPスケジューリングに加えて、周期的なLSPスケジューリングもあります。
Periodical LSP scheduling means an LSP has multiple time intervals and the LSP is set up to carry traffic in every time interval. It has a scheduling period such as [Ta, Tb], a number of repeats such as 10 (repeats 10 times), and a repeat cycle/time interval such as a week (repeats every week). The scheduling interval "[Ta, Tb] repeats n times with repeat cycle C" represents n+1 scheduling intervals as follows:
定期的なLSPスケジューリングは、LSPが複数の時間間隔を持ち、LSPは時間間隔ごとにトラフィックを伝送するように設定されます。それは[Ta、Tb]のようなスケジューリング期間、10（10回繰り返す）、週の繰り返しサイクル/時間間隔（毎週繰り返す）などのスケジューリング期間を有する。スケジューリング間隔 "[Ta、Tb]は、繰り返しサイクルCでN回繰り返すと、次のようにN 1スケジューリング間隔を表します。
[Ta, Tb], [Ta+C, Tb+C], [Ta+2C, Tb+2C], ..., [Ta+nC, Tb+nC]
When an LSP is configured with a scheduling interval such as "[Ta, Tb] repeats 10 times with a repeat cycle of a week" (representing 11 scheduling intervals), a path satisfying the constraints for the LSP in every interval represented by the periodical scheduling interval is computed once. Note that the path computed for one recurrence may be different from the path for another recurrence. And then the LSP along the path is set up to carry traffic in each of the scheduling intervals. If there is no path satisfying the constraints for some of the intervals, the LSP MUST NOT be set up at all. It MUST generate a PCEP Error (PCErr) with Error-Type = 29 (Path computation failure) and Error-value = 5 (Constraints could not be met for some intervals).
LSPが「[Ta、Tb]）のようなスケジューリング間隔で構成されている場合、（11週間のスケジューリング間隔を表す）（11回のスケジューリング間隔を表す）、周期的に表されるすべての間隔でLSPの制約を満たす経路スケジューリング間隔は一度計算されます。1つの再発に対して計算された経路は、他の再発のための経路とは異なる場合がある。そして、パスに沿ったLSPは、各スケジューリング間隔でトラフィックを搬送するように設定されます。一部の間隔に対して制約を満たすパスがない場合は、LSPをまったく設定してはいけません。ERROR-TYPE = 29（パス計算失敗）を備えたPCEPエラー（PCERR）を生成し、エラー値= 5（制約はある間隔で満たすことができませんでした）。
In addition to the basic LSP scheduling at an arbitrary time period, another option is elastic time intervals, which is represented as within -P and Q, where P and Q are amounts of time such as 300 seconds. P is called the elastic range lower bound, and Q is called the elastic range upper bound.
任意の期間での基本的なLSPスケジューリングに加えて、別の選択肢は弾性時間間隔であり、これは-pおよびq内で表される。ここで、pおよびqは300秒の時間の量である。Pは弾性範囲の下限と呼ばれ、Qは弾性範囲の上限と呼ばれます。
For a simple time interval such as [Ta, Tb] with an elastic range, elastic time interval "[Ta, Tb] within -P and Q" means a time period from (Ta+X) to (Tb+X), where -P <= X <= Q. Note that both Ta and Tb are shifted by the same X. This elastic time interval is suitable for the case where a user wants to have a scheduled LSP up to carry the traffic in time interval [Ta, Tb] and has some flexibility on shifting the time interval a little bit, such as up to P seconds earlier/left or some time such as up to Q seconds later/right.
弾性範囲の[Ta、Tb]のような単純な時間間隔の場合、弾性時間間隔は、-pとq内の弾性時間間隔は、（Ta x）から（Tb x）への期間を意味します。<= X≦Q. TaとTbの両方が同じxだけシフトされている。この弾性時間間隔は、ユーザが時間間隔でトラフィックを伝送するためにスケジュールされたLSPを持ちたい場合に適している[Ta、Tb）]そして、最大P秒、または最大Q秒後/右など、時間間隔を少しずっとずらすことである程度の柔軟性があります。
When an LSP is configured with elastic time interval "[Ta, Tb] within -P and Q", a path is computed such that the path satisfies the constraints for the LSP in the time period from (Ta+Xv) to (Tb+Xv), and an optimization is performed on Xv from -P to Q. The optimization makes [Ta+Xv, Tb+Xv] the time interval closest to time interval [Ta, Tb] within the elastic range. The LSP along the path is set up to carry traffic in the time period from (Ta+Xv) to (Tb+Xv).
LSPが弾性時間間隔 "[-pおよびq内の" "で構成されている場合、パスが（Ta xv）から（Tb xv）への期間中のLSPの制約を満たすように経路が計算される。最適化は、最適化により、弾性範囲内の時間間隔[Ta、Tb]に最も近い時間間隔を最適化します。経路に沿ったLSPは、（TA XV）から（TB XV）までの期間のトラフィックを搬送するように設定されています。
Similarly, for a recurrent time interval with an elastic range, elastic time interval "[Ta, Tb] repeats n times with repeat cycle C within -P and Q" represents n+1 simple elastic time intervals as follows:
同様に、弾性範囲の再発時間間隔では、弾性時間間隔が-P、reの繰り返しサイクルcでn回繰り返すと、次のようにN 1単純な弾性時間間隔を表す。
[Ta+X0, Tb+X0], [Ta+C+X1, Tb+C+X1], ..., [Ta+nC+Xn, Tb+nC+Xn], where -P <= Xi <= Q, i = 0, 1, 2, ..., n.
[Ta x 0、Tb x 0]、[Ta C x 1、Tb C x 1]、...、<n c x n、tb n c x n]、ここで-p≦x i≦q、i = 0,1,2、...、n。
If a user wants to keep the same repeat cycle between any two adjacent time intervals, elastic time interval "[Ta, Tb] repeats n times with repeat cycle C within -P and Q SYNC" may be used, which represents n+1 simple elastic time intervals as follows:
任意の2つの隣接する時間間隔の間に同じ繰り返しサイクルを維持したい場合は、弾性時間間隔「[Ta、Tb]が-Pおよびq同期の繰り返しサイクルCで繰り返すことができ、これはN 1単純伸縮性を表すことができる。以下の時間間隔：
[Ta+X, Tb+X], [Ta+C+X, Tb+C+X], ..., [Ta+nC+X, Tb+nC+X], where -P <= X <= Q.
[Ta x、tb x]、[Ta C x、Tb C x]、...、[Ta Nc x、Tb Nc x]。ここで、-p≦x≦q。
Besides the stated time scheduling, a user may want to have some grace periods (short for "graceful time periods") for each or some of the time intervals for the LSP. Two grace periods may be configured for a time interval. One is the grace period before the time interval, called "Grace-Before", which extends the lifetime of the LSP by an amount of time (such as 30 seconds) before the time interval. The other grace period is after the time interval and is called "Grace-After"; it extends the lifetime of the LSP by an amount of time (such as 60 seconds) after the time interval. Note that no network resources such as link bandwidth will be reserved for the LSP during the grace periods.
述べられた時間スケジューリングの他に、LSPの各またはいくつかの時間間隔に対して、いくつかの猶予期間（「優雅な期間」の場合）を持つことをお勧めします。2つの猶予期間を時間間隔で構成することができる。1つは時間間隔の前の猶予期間の前の猶予期間です。これは、時間間隔の前にLSPの寿命（30秒など）だけ長さを延長します。他の猶予期間は時間間隔の後であり、「猶予後」と呼ばれます。時間間隔の後にLSPの寿命（60秒など）だけ延長されます。リンク帯域幅などのネットワークリソースは、猶予期間中にLSP用に予約されないことに注意してください。
When an LSP is configured with a simple time interval such as [Ta, Tb] with grace periods such as Grace-Before GrB and Grace-After GrA, a path is computed such that the path satisfies the constraints for the LSP in the time period from Ta to Tb. The LSP along the path is set up to carry traffic in the time period from (Ta-GrB) to (Tb+GrA). During grace periods from (Ta-GrB) to Ta and from Tb to (Tb+GrA), the LSP is up to carry traffic in best effort.
LSPがGRBの前にGRBおよびGRACE - AFTER GRAのような猶予期間を有する[TA、TB]のような単純な時間間隔で構成されている場合、経路が期間内のLSPの制約を満たすように経路が計算される。TAからTBへ。経路に沿ったLSPは、（TA - GRB）から（TB GRA）までの期間のトラフィックを搬送するように設定されている。（TA-GRB）からTAへの猶予期間およびTBから（TB GRA）まで、LSPは最良の努力でトラフィックを搬送することです。
In order to realize PCC-initiated scheduled LSPs in a centralized network environment, a PCC MUST separate the setup of an LSP into two steps. The first step is to request/delegate and get an LSP but not signal it over the network. The second step is to signal the scheduled LSP over the Label Switching Routers (LSRs) at its start time.
集中型ネットワーク環境でPCC開始スケジュールされたLSPを実現するために、PCCはLSPの設定を2つのステップに分離する必要があります。最初のステップは、LSPを要求/委任して取得することですが、ネットワーク経由で信号を送りません。2番目のステップは、開始時にラベルスイッチングルータ（LSRS）を介してスケジュールされたLSPをシグナリングすることです。
For PCC-initiated scheduled LSPs, a PCC MUST delegate the scheduled LSP by sending a PCRpt message by including its demanded resources with the scheduling information to a stateful PCE. Note that the PCC MAY use Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages with scheduling information before delegating.
PCC開始されたスケジュールされたLSPの場合、PCCはスケジューリング情報をスケジューリング情報と共にステートフルPCEに含めることによってPCRPTメッセージを送信することによってスケジュールされたLSPを委任しなければなりません。PCCは、委任前のスケジューリング情報を備えたパス計算要求（PCREQ）およびパス計算応答（PCREP）メッセージを使用することができることに留意されたい。
Upon receiving the delegation via PCRpt message, the stateful PCE MUST compute a path for the scheduled LSP per its start time and duration based on the network resource availability stored in the scheduled TED (see Section 4.1).
PCRPTメッセージを介して委任を受け取ると、ステートフルPCEは、スケジュールされたTEDに格納されているネットワークリソースの可用性に基づいて、開始時刻および期間ごとにスケジュールされたLSPのパスを計算する必要があります（セクション4.1を参照）。
The stateful PCE will send a Path Computation Update Request (PCUpd) message with the scheduled path information and the scheduled resource information for the scheduled LSP to the PCC. The stateful PCE MUST update its local scheduled LSP-DB and scheduled TED with the scheduled LSP and would need to synchronize the scheduling information with other PCEs in the domain.
ステートフルPCEは、スケジュールされたパス情報とスケジュールされたLSPのスケジュールされたリソース情報を、スケジュールされたLSPのスケジュールされたリソース情報をPCCに送信します。ステートフルPCEは、そのローカルスケジュールされたLSP-DBを更新し、スケジュールされたLSPとスケジュールされており、スケジューリング情報をドメイン内の他のPCEと同期させる必要があります。
For a PCE-initiated scheduled LSP, the stateful PCE MUST automatically compute a path for the scheduled LSP per requests from network management systems, based on the network resource availability in the scheduled TED, and send an LSP Initiate Request (PCInitiate) message with the path information to the PCC. Based on the local policy, the PCInitiate message could be sent immediately to ask the PCC to create a scheduled LSP (as per this document), or the PCInitiate message could be sent at the start time to the PCC to create a normal LSP (as per [RFC8281]).
PCE開始されたスケジュールされたLSPの場合、ステートフルPCEは、スケジュールされたテッド内のネットワークリソースの可用性に基づいて、ネットワーク管理システムからの要求ごとにスケジュールされたLSPのパスを自動的に計算し、LSP開始要求（PCINITIATE）メッセージを送信する必要があります。PCCへのパス情報。ローカルポリシーに基づいて、pcinitiateメッセージはすぐに送信され、PCCに（このドキュメントに従って）スケジュールされたLSPを作成するか、またはPCInitiateメッセージをPCCに送信して、通常のLSPを作成することができます（[RFC8281]（RFC8281]）。
For both PCC-initiated and PCE-initiated Scheduled LSPs:
PCC開始とPCE開始されたスケジュールされたLSPの両方について：
* The stateful PCE MUST update its local scheduled LSP-DB and scheduled TED with the scheduled LSP.
* ステートフルPCEは、そのローカルスケジュールされたLSP-DBを更新し、スケジュールされたLSPとスケジュールされています。
* Upon receiving the PCUpd message or PCInitiate message for the scheduled LSP from PCEs with a found path, the PCC determines that it is a scheduled path for the LSP by the SCHED-LSP-ATTRIBUTE TLV (see Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2) in the message and does not trigger signaling for the LSP setup on LSRs immediately.
* 見つかったパスを持つPCESからのスケジュールされたLSPのPCUPDメッセージまたはPCINITIATEメッセージを受信すると、PCCはSCHED-LSP-属性TLVによってLSPのスケジュールパスであると判断します（セクション5.2.1を参照）。メッセージ内の-lsp-属性TLV（5.2.2項を参照）、すぐにLSRSのLSPセットアップのシグナリングをトリガーしません。
* The stateful PCE MUST update the scheduled LSP parameters on any network events using the PCUpd message to the PCC. These changes are also synchronized to other PCEs.
* ステートフルPCEは、PCUPDメッセージを使用してPCCにPCCを使用して任意のネットワークイベントでスケジュールされたLSPパラメータを更新する必要があります。これらの変化も他のPCEと同期されています。
* When it is time for the LSP to be set up (i.e., at the start time), based on the value of the C flag for the scheduled TLV, either the PCC MUST trigger the LSP to be signaled or the delegated PCE MUST send a PCUpd message to the head-end LSR providing the updated path to be signaled (with the A flag set to indicate LSP activation).
* スケジュールされたTLVのCフラグの値に基づいて、LSPを設定する時間（すなわち、開始時刻に）が、シグナリングされるLSPをトリガする必要があるか、または委任されたPCEが送信する必要がある場合シグナリングされるべき更新されたパスを提供するヘッドエンドLSRへのPCUPDメッセージ（LSPアクティベーションを示すために設定されたフラグに設定されている）。
After a scheduled LSP is configured, a user may change its parameters, including the requested time and the bandwidth. For a periodic-scheduled LSP, its unused recurrences can be modified or canceled. For a scheduled LSP that is currently active, its duration (the lifetime) can be reduced.
スケジュールされたLSPが設定された後、要求された時間と帯域幅を含む、ユーザーはそのパラメータを変更することができます。定期的にスケジュールされたLSPの場合、未使用の再発は変更またはキャンセルされます。現在アクティブなスケジュールされたLSPの場合、その期間（寿命）を短縮することができます。
In the PCC-initiated case, the PCC MUST send the PCE a PCRpt message for the scheduled LSP with updated parameters, as well as scheduled information included in the SCHED-LSP-ATTRIBUTE TLV (see Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2) carried in the LSP object. The PCE SHOULD take the updated resources and schedule into consideration, and update the new path for the scheduled LSP to the PCC, and synchronize to other PCEs in the network. If the path cannot be set based on new requirements, the previous LSP will not be impacted, and this MUST be conveyed by the use of an empty Explicit Route Object (ERO) in the PCEP messages.
PCC開始されたケースでは、PCCは、スケジュールされたLSPにPCE A PCRPTメッセージを更新されたパラメータとSched-LSP-attribute TLV（セクション5.2.1）またはSCHED-PD-に送信する必要があります。LSPオブジェクトで搭載されているLSP-属性TLV（5.2.2項を参照）。PCEは、更新されたリソースとスケジュールを考慮して、スケジュールされたLSPの新しいパスをPCCに更新し、ネットワーク内の他のPCEと同期してください。新しい要件に基づいてパスを設定できない場合、前のLSPは影響を受けません。これは、PCEPメッセージ内の空の明示的なルートオブジェクト（ERO）を使用することによって伝えられなければなりません。
In the PCE-initiated case, the stateful PCE would recompute the path based on updated parameters and scheduled information. If it has already conveyed this information to the PCC by sending a PCInitiate message, it SHOULD update the path and other scheduling and resource information by sending a PCUpd message.
PCE開始されたケースでは、ステートフルPCEは、更新されたパラメータとスケジュールされた情報に基づいてパスを再計算します。PCINITIATEメッセージを送信してこの情報をすでにPCCに伝えている場合は、PCUPDメッセージを送信してパスやその他のスケジューリング情報とリソース情報を更新する必要があります。
In the PCC-initiated case, when it is time for the LSP to be set up (i.e., at the start time), based on the value of the C flag for the scheduled TLV, either the PCC MUST trigger the LSP to be signaled, or the delegated PCE MUST send a PCUpd message to the head-end LSR providing the updated path to be signaled (with the A flag set to indicate LSP activation). The PCC MUST report the status of the active LSP as per the procedures in [RFC8231], and at this time, the LSP MUST be considered part of the LSP-DB. The A flag MUST be set in the scheduled TLV to indicate that the LSP is active now. After the scheduled duration expires, based on the C flag, the PCC MUST trigger the LSP deletion on itself, or the delegated PCE MUST send a PCUpd message to the PCC to delete the LSP as per the procedures in [RFC8231].
PCC開始された場合では、スケジュールされたTLVのCフラグの値に基づいてLSPが設定される時期（開始時刻）が、シグナリングされるLSPをトリガする必要があります。または、委任されたPCEは、シグナリングされるべき更新されたパスを提供する（LSPアクティベーションを示すために設定されたフラグに設定されている）ヘッドエンドLSRにPCUPDメッセージを送信する必要があります。PCCは、[RFC8231]の手順に従ってアクティブLSPのステータスを報告し、現時点ではLSPはLSP-DBの一部と見なされなければなりません。LSPが現在アクティブであることを示すために、AフラグをスケジュールされたTLVに設定する必要があります。スケジュールされた期間が経過した後、Cフラグに基づいて、PCCはそれ自体のLSPの削除をトリガする必要があります。または、委任されたPCEは[RFC8231]の手順に従ってLSPを削除するためにPCCにPCCDメッセージを送信する必要があります。
In the PCE-initiated case, based on the local policy, if the scheduled LSP is already conveyed to the PCC at the time of creation, the handling of LSP activation and deletion is handled in the same way as the PCC-initiated case, as per the setting of the C flag. Otherwise, the PCE MUST send the PCInitiate message to the PCC at the start time to create a normal LSP without the scheduled TLV and remove the LSP after the duration expires, as per [RFC8281].
PCE開始された場合、ローカルポリシーに基づいて、スケジュールされたLSPが作成時にすでにPCCに伝達されている場合、LSPの起動と削除の処理は、PCCが開始されたケースと同じ方法で処理されます。Cフラグの設定ごとに。それ以外の場合、PCEは開始時にPCCにPCCにPCCを送信して、スケジュールされたTLVなしで通常のLSPを作成し、[RFC8281]と同様に、期間が期限切れになった後にLSPを削除する必要があります。
A PCC and a PCE indicate their ability to support LSP scheduling during their PCEP session establishment phase. For an environment with multiple PCEs, the PCEs SHOULD also establish a PCEP session and indicate its ability to support LSP scheduling among PCEP peers. The OPEN object in the Open message contains the STATEFUL-PCE-CAPABILITY TLV. Note that the STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231] and updated in [RFC8281] and [RFC8232]. In this document, we define a new flag bit B (LSP-SCHEDULING-CAPABILITY) in the Flags field of the STATEFUL-PCE-CAPABILITY TLV to indicate the support of LSP scheduling. We also define another flag bit PD (PD-LSP-CAPABILITY) to indicate the support of LSP periodical scheduling.
PCCとPCEは、PCEPセッション確立段階の間にLSPスケジューリングをサポートする能力を示しています。複数のPCEを使用した環境の場合、PCEはPCEPセッションも確立されるべきであり、PCEPピア間のLSPスケジューリングをサポートする能力を示します。Openメッセージの開いているオブジェクトには、ステートフルPCE機能TLVが含まれています。なお、ステートフルPCE機能TLVは[RFC8231]で定義され、[RFC8281]と[RFC8232]で更新されています。この文書では、LSPスケジューリングのサポートを示すために、ステートフルPCE機能TLVのFlagsフィールドに新しいフラグビットB（LSPスケジューリング機能）を定義します。また、LSP周期的スケジューリングのサポートを示すために別のフラグビットPD（PD-LSP機能）を定義します。
B (LSP-SCHEDULING-CAPABILITY) - 1 bit (Bit Position 22): If set to 1 by a PCC, the B flag indicates that the PCC allows LSP scheduling; if set to 1 by a PCE, the B flag indicates that the PCE is capable of LSP scheduling. The B bit MUST be set by both PCEP peers in order to support LSP scheduling for path computation.
B（LSP-Scheduling-Capability） - 1ビット（ビット位置22）：PCCによって1に設定されている場合、BフラグはPCCがLSPスケジューリングを許可することを示します。PCEで1に設定すると、BフラグはPCEがLSPスケジューリングが可能であることを示します。PATH計算のLSPスケジューリングをサポートするには、Bビットは両方のPCEPピアによって設定する必要があります。
PD (PD-LSP-CAPABILITY) - 1 bit (Bit Position - 21): If set to 1 by a PCC, the PD flag indicates that the PCC allows LSP scheduling periodically; if set to 1 by a PCE, the PD flag indicates that the PCE is capable of periodical LSP scheduling. Both the PD bit and the B bit MUST be set to 1 by both PCEP peers in order to support periodical LSP scheduling for path computation. If the PD bit or B bit is 0, then the periodical LSP scheduling capability MUST be ignored.
PD（PD-LSP-Capability） - 1ビット（ビット位置 - 21）：PCCによって1に設定されている場合、PDフラグはPCCが定期的にLSPスケジューリングを許可することを示します。PCEで1に設定すると、PDフラグはPCEが定期的なLSPスケジューリングが可能であることを示します。パス計算のための定期的なLSPスケジューリングをサポートするために、PDビットとBビットは両方のPCEPピアによって1に設定する必要があります。PDビットまたはBビットが0の場合、定期LSPスケジューリング機能は無視されなければなりません。
The LSP object is defined in [RFC8231]. This document adds an optional SCHED-LSP-ATTRIBUTE TLV for normal LSP scheduling and an optional SCHED-PD-LSP-ATTRIBUTE TLV for periodical LSP scheduling. The LSP object for a scheduled LSP MUST NOT include these two TLVs. Only one scheduling, either normal or periodical, is allowed for a scheduled LSP.
LSPオブジェクトは[RFC8231]で定義されています。この文書は、通常のLSPスケジューリング用のオプションのSCHED-LSP-属性TLVと、定期的なLSPスケジューリング用のオプションのSCHED-PD-LSP-属性TLVを追加します。スケジュールされたLSPのLSPオブジェクトは、これら2つのTLVを含めてはいけません。スケジュールされたLSPには、通常または定期的なスケジューリングのみが1つだけです。
The presence of the SCHED-LSP-ATTRIBUTE TLV in the LSP object indicates that this LSP is normal scheduling while the SCHED-PD-LSP-ATTRIBUTE TLV indicates that this scheduled LSP is periodical. The SCHED-LSP-ATTRIBUTE TLV MUST be present in the LSP object for each normal-scheduled LSP carried in the PCEP messages. The SCHED-PD-LSP-ATTRIBUTE TLV MUST be used in the LSP object for each periodic-scheduled LSP carried in the PCEP messages.
LSPオブジェクト内のSCHED-LSP-属性TLVの存在は、このLSPが通常のスケジューリングであることを示し、SCHED-PD-LSP-属性TLVは、このスケジュールされたLSPが定期的であることを示します。SCHED-LSP-属性TLVは、PCEPメッセージで運ばれる通常スケジュールされた各LSPごとにLSPオブジェクトに存在する必要があります。SCHED-PD-LSP-属性TLVは、PCEPメッセージで運ばれる各定期スケジュールされたLSPごとにLSPオブジェクトで使用する必要があります。
Only one SCHED-LSP-ATTRIBUTE TLV SHOULD be present in the LSP object. If more than one SCHED-LSP-ATTRIBUTE TLV is found, the first instance is processed and others ignored. The SCHED-PD-LSP-ATTRIBUTE TLV is the same as the SCHED-LSP-ATTRIBUTE TLV with regard to its presence in the LSP object.
LSPオブジェクトには、1つのSCHED-LSP-属性TLVのみが存在する必要があります。複数のSCHED-LSP-属性TLVが見つかった場合、最初のインスタンスは処理され、他のものは無視されます。SCHED-PD-LSP-属性TLVは、LSPオブジェクト内の存在に関してSCHED-LSP-属性TLVと同じです。
The SCHED-LSP-ATTRIBUTE TLV MAY be included as an optional TLV within the LSP object for LSP scheduling for the requesting traffic service.
SCHED-LSP-属性TLVは、要求側のトラフィックサービスのLSPスケジューリング用のLSPオブジェクト内のオプションのTLVとして含まれている可能性があります。
This TLV MUST NOT be included unless both PCEP peers have set the B (LSP-SCHEDULING-CAPABILITY) bit in the STATEFUL-PCE-CAPABILITY TLV carried in the Open message to one. If the TLV is received by a peer when both peers didn't set the B bit to one, the peer MUST generate a PCEP Error (PCErr) with a PCEP-ERROR object having Error-Type = 19 (Invalid Operation) and Error-value = 15 (Attempted LSP scheduling while the scheduling capability was not advertised).
両方のPCEPピアがSTATEFUL-PCE-CAPABILY TLVでB（LSP-Scheduling-Capability）ビットを設定しない限り、このTLVは含まれていなければならない。両方のピアがBビットを1に設定していないときにTLVがTLVが受信された場合、ピアはERROR-TYPE = 19（無効な操作）とエラーを持つPCEPエラーオブジェクトを使用してPCEPエラー（PCerr）を生成しなければなりません。値= 15（スケジューリング機能が広告されていない間は、LSPスケジューリングの試みました）。
The format of the SCHED-LSP-ATTRIBUTE TLV is shown in Figure 1.
SCHED-LSP-属性TLVの形式を図1に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (49) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |R|C|A|G| Reserved (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GrB / Elastic-Lower-Bound | GrA / Elastic-Upper-Bound |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SCHED-LSP-ATTRIBUTE TLV
図1：Sched-LSP-属性TLV
The type of the TLV is 49, and the TLV has a fixed length of 16 octets.
TLVの種類は49であり、TLVは16オクテットの固定長を有する。
The fields in the format are:
フォーマットのフィールドは次のとおりです。
Flags (8 bits): The following flags are defined in this document.
フラグ（8ビット）：この文書では、次のフラグが定義されています。
R (1 bit): Set to 1 to indicate that the Start-Time is a relative time, which is the number of seconds from the current time. The PCEs and PCCs MUST synchronize their clocks when relative time is used. It is RECOMMENDED that the Network Time Protocol [RFC5905] be used to synchronize clocks among them. When the transmission delay from a PCE or PCC to another PCE or PCC is too big (such as greater than 1 second), the scheduling interval represented is not accurate if the delay is not considered. Set to 0 to indicate that the 32-bit Start-Time is an absolute time, which is the number of seconds since the epoch. The epoch is 1 January 1970 at 00:00 UTC. It wraps around every 2^32 seconds, which is roughly 136 years. The next wraparound will occur in the year 2106. The received Start-Time is considered after the wraparound if the resulting value is less than the current time. In that case, the value of the 32-bit Start-Time is considered to be the number of seconds from the time of wraparound (because the Start-Time is always a future time).
R（1ビット）：開始時間が相対時間であることを示すために1に設定します。これは現在時刻からの秒数です。相対時間を使用すると、PCEとPCCはクロックを同期させる必要があります。ネットワークタイムプロトコル[RFC5905]を使用してクロックを同期させることをお勧めします。 PCEまたはPCCから別のPCEへの伝送遅延が大きすぎる（1秒を超えるなど）、遅延が考慮されていない場合、表されるスケジューリング間隔は正確ではない。 32ビットの開始時刻が絶対時間であることを示し、これはエポック以降の秒数です。エポックは1970年1月1日00:00 UTCです。それは222秒ごとにラップします。これはおよそ136歳です。次のラップアラウンドは2106年に発生します。結果の値が現在の時刻より小さい場合、受信した開始時刻はラップアラウンドの後に考慮されます。その場合、32ビットの開始時刻の値は、ラップアラウンド時の秒数と見なされます（スタートタイムは常に将来の時間であるため）。
C (1 bit): Set to 1 to indicate that the PCC is responsible to set up and remove the scheduled LSP based on the Start-Time and Duration. The PCE holds these responsibilities when the bit is set to zero.
C（1ビット）：PCCが開始時間と期間に基づいてスケジュールされたLSPを設定して削除する責任があることを示すために、1に設定します。ビットがゼロに設定されている場合、PCEはこれらの責任を保持しています。
A (1 bit): Set to 1 to indicate that the scheduled LSP has been activated.
A（1ビット）：スケジュールされたLSPが有効になっていることを示すために1に設定します。
G (1 bit): Set to 1 to indicate that the grace period is included in the fields GrB/Elastic-Lower-Bound and GrA/Elastic-Upper-Bound; set to 0 to indicate that the elastic range is included in the fields.
g（1ビット）：猶予期間がフィールドGRB /弾性下限およびGRA / ELASTIP-UPER-BANDに含まれることを示すために1に設定します。弾性範囲がフィールドに含まれていることを示すには、0に設定します。
Reserved (24 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約済み（24ビット）：このフィールドは送信時にゼロに設定する必要があり、受信時に無視する必要があります。
Start-Time (32 bits): This value, in seconds, indicates when the scheduled LSP is used to carry traffic and the corresponding LSP MUST be set up and activated. Note that the transmission delay SHOULD be considered when R=1 and the value of Start-Time is small.
起動時刻（32ビット）：この値は、スケジュールされたLSPを使用してトラフィックを搬送し、対応するLSPを設定してアクティブにする必要がある場合は、秒単位で表示します。なお、R = 1のときは送信遅延を考慮する必要があり、起動時刻の値は小さい。
Duration (32 bits): This value, in seconds, indicates the duration that the LSP carries a traffic flow and the corresponding LSP MUST be up to carry traffic. At the expiry of this duration, the LSP MUST be torn down and deleted. A value of 0 MUST NOT be used in Duration since it does not make any sense. The value of Duration SHOULD be greater than a constant MINIMUM-DURATION seconds, where MINIMUM-DURATION is 5.
期間（32ビット）：この値は、LSPがトラフィックフローを搬送する期間を示し、対応するLSPはトラフィックを搬送する必要があります。この期間の有効期限で、LSPは引き下げられて削除されなければなりません。0の値は意味がないので、0の値を持続時間に使用しないでください。期間の値は、最小期間が5の一定の最小期間秒より大きくなければなりません。
Start-Time indicates a time at or before which the scheduled LSP MUST be set up. When the R bit is set to 0, the value of Start-Time represents the number of seconds since the epoch. When the R bit is set to 1, the value of Start-Time represents the number of seconds from the current time.
開始時間は、スケジュールされたLSPを設定する必要がある時または前の時間を示します。Rビットが0に設定されている場合、開始時刻の値はエポック以降の秒数を表します。Rビットが1に設定されている場合、開始時刻の値は現在時刻の秒数を表します。
In addition, the SCHED-LSP-ATTRIBUTE TLV contains the G flag set to 1 and a nonzero Grace-Before and Grace-After in the fields GrB/Elastic-Lower-Bound and GrA/Elastic-Upper-Bound if grace periods are configured. It includes the G flag set to 0 and a nonzero elastic range lower bound and upper bound in the fields if there is an elastic range configured. A TLV can configure a nonzero grace period or elastic range, but it MUST NOT provide both for an LSP.
さらに、SCHED-LSP-属性TLVには、GRB / Elastic-Lower-BoundおよびGRA / Elastic-Upperバインドが設定されている場合、GRB / Elastic-Lower-BoundおよびGRA / Elastic-Upper-Boundが設定されている場合のGフラグが1に設定され、猶予後のgrace-pargyが含まれています。。弾性範囲が構成されている場合、0に設定されたGフラグと、ゼロ以外の弾性範囲の下限および上限が含まれます。TLVはゼロ以外の猶予期間または弾性範囲を設定できますが、LSPの両方を提供してはなりません。
GrB (Grace-Before, 16 bits): The grace period time length, in seconds, before the start time.
GRB（猶予前、16ビット）：開始時刻の前の猶予期間の時間長。
GrA (Grace-After, 16 bits): The grace period time length, in seconds, after time interval [start time, start time + duration].
GRA（Grace-After、16ビット）：猶予期間時間の長さは、時間間隔の後、[開始時間、開始期間]。
Elastic-Lower-Bound (16 bits): The maximum amount of time, in seconds, that the time interval can shift lower/left.
弾性下限（16ビット）：時間間隔が左下にシフトできる最大時間（秒単位）。
Elastic-Upper-Bound (16 bits): The maximum amount of time, in seconds, that the time interval can shift higher/right.
弾性上限（16ビット）：時間間隔が高/右にシフトできる最大時間（秒単位）。
The periodical LSP is a special case of LSP scheduling. The traffic service happens in a series of repeated time intervals. The SCHED-PD-LSP-ATTRIBUTE TLV can be included as an optional TLV within the LSP object for this periodical LSP scheduling.
定期LSPはLSPスケジューリングの特別な場合です。交通サービスは一連の繰り返しの時間間隔で行われます。SCHED-PD-LSP-属性TLVは、この定期的なLSPスケジューリングのためにLSPオブジェクト内のオプションのTLVとして含めることができます。
This TLV MUST NOT be included unless both PCEP peers have set the B (LSP-SCHEDULING-CAPABILITY) bit and PD (PD-LSP-CAPABILITY) bit in STATEFUL-PCE-CAPABILITY TLV carried in Open message to one. If the TLV is received by a peer when either bit is zero (or both bits are zero), the peer MUST generate a PCEP Error (PCErr) with a PCEP-ERROR object having Error-Type = 19 (Invalid Operation) and Error-value = 15 (Attempted LSP scheduling while the scheduling capability was not advertised).
両方のPCEPピアがB（LSP-Scheduling-Capability）ビットとPD（PD-LSP-Capability）ビットを設定していない限り、Openメッセージで1つに搭載されている場合は含まれていない場合があります。いずれかのビットがゼロ（または両方のビットがゼロの場合）にTLVがピアによって受信された場合、ピアはERROR-TYPE = 19（無効な操作）とエラーを持つPCEPエラーオブジェクトを持つPCEPエラー（PCerr）を生成しなければなりません。値= 15（スケジューリング機能が広告されていない間は、LSPスケジューリングの試みました）。
The format of the SCHED-PD-LSP-ATTRIBUTE TLV is shown in Figure 2.
SCHED-PD-LSP-属性TLVの形式を図2に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (50) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags|R|C|A|G| Opt | NR | Reserved (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Repeat-time-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GrB / Elastic-Lower-Bound | GrA / Elastic-Upper-Bound |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SCHED-PD-LSP-ATTRIBUTE TLV
図2：SCHED-PD-LSP-属性TLV
The type of the TLV is 50, and the TLV has a fixed length of 20 octets. The description, format, and meaning of the flags (R, C, A, and G bits), Start-Time, Duration, GrB, GrA, Elastic-Lower-Bound, and Elastic-Upper-Bound fields remain the same as in the SCHED-LSP-ATTRIBUTE TLV.
TLVの種類は50であり、TLVは20オクテットの固定長を有する。フラグ（R、C、A、およびGビット）の説明、フォーマット、および意味、始動時間、期間、GRB、GRA、弾性下限フィールド、および弾性上の上限フィールドは、SCHED-LSP属性TLV
The following fields are new:
次のフィールドは新しいフィールドです。
Opt (4 bits): Indicates options to repeat. When a PCE receives a TLV with an unknown Opt value, it does not compute any path for the LSP. It MUST generate a PCEP Error (PCErr) with a PCEP-ERROR object having Error-Type = 4 (Not supported object) and Error-value = 4 (Unsupported parameter).
opt（4ビット）：繰り返すオプションを示します。PCEが未知のOPT値を持つTLVを受信すると、LSPのパスを計算しません。ERROR-TYPE = 4（サポートされていないオブジェクト）とエラー値= 4（サポートされていないパラメータ）を持つPCEPエラーオブジェクトを持つPCEPエラー（PCERR）を生成する必要があります。
Opt = 1: repeat every month
opt = 1：毎月繰り返します
Opt = 2: repeat every year
opt = 2：毎年繰り返します
Opt = 3: repeat every Repeat-time-length
opt = 3：繰り返し時間長を繰り返す
A user may configure a Repeat-time-length in time units weeks, days, hours, minutes, and/or seconds. The value represented by these units is converted to the number of seconds in the TLV. For example, repeat every 2 weeks is equivalent to repeat every Repeat-time-length = 2*7*86,400 (seconds), where 86,400 is the number of seconds per day.
ユーザは、時間単位、日数、数時間、分、および/または秒で繰り返し時間長を設定することができる。これらの単位で表される値は、TLVの秒数に変換されます。たとえば、2週間ごとに繰り返すことは、繰り返し時間-1 * 7 * 86,400（秒）を繰り返すのと同じです。ここで、86,400は1日あたりの秒数です。
NR (12 bits): The number of repeats. During each repetition, LSP carries traffic.
NR（12ビット）：繰り返し数。各繰り返し中、LSPはトラフィックを搬送します。
Reserved (8 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約済み（8ビット）：このフィールドは送信時にゼロに設定されており、受信時に無視される必要があります。
Repeat-time-length (32 bits): The time in seconds between the Start-Time of one repetition and the Start-Time of the next repetition.
繰り返し時間長（32ビット）：1回の繰り返しの開始時刻と次の繰り返しの開始時刻の間の時間。
The Path Computation State Report (PCRpt) message is a PCEP message sent by a PCC to a PCE to report the status of one or more LSPs, as per [RFC8231]. Each LSP State Report in a PCRpt message contains the actual LSP's path, bandwidth, operational and administrative status, etc. An LSP Status Report carried in a PCRpt message is also used in delegation or revocation of control of an LSP to/from a PCE. In the case of a scheduled LSP, a scheduled TLV MUST be carried in the LSP object, and the ERO conveys the intended path for the scheduled LSP. The scheduled LSP MUST be delegated to a PCE.
パス計算状態レポート（PCRPT）メッセージは、PCCからPCEに送信され、1つ以上のLSPのステータスを[RFC8231]に通知します。PCRPTメッセージ内の各LSP状態レポートには、実際のLSPのパス、帯域幅、運用ステータスなどが含まれています.PCRPTメッセージで運ばれるLSPステータスレポートは、PCEへの/ /からのLSPの制御の委任または失効にも使用されます。スケジュールされたLSPの場合、スケジュールされたTLVをLSPオブジェクトに持ち運ぶ必要があり、EROはスケジュールされたLSPの意図された経路を伝えます。スケジュールされたLSPはPCEに委任されなければなりません。
The Path Computation Update Request (PCUpd) message is a PCEP message sent by a PCE to a PCC to update LSP parameters on one or more LSPs, as per [RFC8231]. Each LSP Update Request in a PCUpd message contains all LSP parameters that a PCE wishes to be set for a given LSP. In the case of a scheduled LSP, a scheduled TLV MUST be carried in the LSP object, and the ERO conveys the intended path for the scheduled LSP. If no path can be found, an empty ERO is used. The A bit is used in the PCUpd message to indicate the activation of the scheduled LSP if the PCE is responsible for the activation (as per the C bit).
PATH計算更新要求（PCUPD）メッセージは、PCCからPCCに送信され、[RFC8231]に従って、1つまたは複数のLSPでLSPパラメータを更新することができます。PCUPDメッセージ内の各LSP更新要求には、PCEが特定のLSPに対して設定されたいすべてのLSPパラメータが含まれています。スケジュールされたLSPの場合、スケジュールされたTLVをLSPオブジェクトに持ち運ぶ必要があり、EROはスケジュールされたLSPの意図された経路を伝えます。パスが見つからない場合は、空のEROが使用されます。PCEが起動を担当している場合は、PCUPDメッセージで使用されている（Cビットに従って）PCEがスケジュールされたLSPの起動を示します。
The LSP Initiate Request (PCInitiate) message is a PCEP message sent by a PCE to a PCC to trigger LSP instantiation or deletion, as per [RFC8281]. In the case of a scheduled LSP, based on the local policy, the PCE MAY convey the scheduled LSP to the PCC by including a scheduled TLV in the LSP object. Alternatively, the PCE would initiate the LSP only at the start time of the scheduled LSP, as per [RFC8281], without the use of scheduled TLVs.
LSP開始要求（PCINITIATE）メッセージは、PCCからPCCが送信して、LSPのインスタンス化または削除をトリガーするようにPCCによって送信され、[RFC8281]になります。スケジュールされたLSPの場合、ローカルポリシーに基づいて、PCEは、LSPオブジェクト内のスケジュールされたTLVを含むことによって、スケジュールされたLSPをPCCに伝達することができる。あるいは、PCEは、スケジュールされたTLVを使用せずに、[RFC8281]と同様に、スケジュールされたLSPの開始時点でのみLSPを開始するであろう。
The Path Computation Request (PCReq) message is a PCEP message sent by a PCC to a PCE to request a path computation [RFC5440], and it may contain the LSP object [RFC8231] to identify the LSP for which the path computation is requested. In the case of a scheduled LSP, a scheduled TLV MUST be carried in the LSP object in the PCReq message to request the path computation based on the scheduled TED and LSP-DB. A PCC MAY use the PCReq message to obtain the scheduled path before delegating the LSP. The parameters of the LSP may be changed (refer to Section 4.4).
パス計算要求（PCREQ）メッセージは、PCCからPCEに送信されたPCEからPCEへの送信メッセージであり、パス計算が要求されるLSPオブジェクト[RFC8231]を含めることができ、パス計算が要求されるLSPを識別することができる。スケジュールされたLSPの場合、スケジュールされたTEDおよびLSP-DBに基づいてパス計算を要求するために、PCREQメッセージ内のLSPオブジェクトでスケジュールされたTLVを搬入する必要があります。PCCは、LSPを委任する前にスケジュールされたパスを取得するためにPCREQメッセージを使用することができる。LSPのパラメータを変更することができます（4.4項参照）。
The Path Computation Reply (PCRep) message is a PCEP message sent by a PCE to a PCC in reply to a path computation request [RFC5440], and it may contain the LSP object [RFC8231] to identify the LSP for which the path is computed. A PCRep message can contain either a set of computed paths if the request can be satisfied or a negative reply if not. A negative reply may indicate the reason why no path could be found. In the case of a scheduled LSP, a scheduled TLV MUST be carried in the LSP object in PCRep message to indicate the path computation based on the scheduled TED and LSP-DB. A PCC and PCE MAY use PCReq and PCRep messages to obtain the scheduled path before delegating the LSP.
パス計算応答（PCREP）メッセージは、パス計算要求[RFC5440]に返信したPCCからPCEに送信されたPCEPメッセージであり、パスが計算されているLSPを識別するためのLSPオブジェクト[RFC8231]を含めることができます。。PCREPメッセージは、要求が満たされ得るかどうか、またはそうでない場合は否定的な応答のうちの一組の計算パスを含めることができます。否定的な回答は、パスが見つからなかった理由を示すかもしれません。スケジュールされたLSPの場合、スケジュールされたTEDおよびLSP-DBに基づくパスの計算を示すために、スケジュールされたTLVをPCREPメッセージのLSPオブジェクトで持ち運ぶ必要があります。PCCとPCEは、LSPを委任する前に、PCREQおよびPCREPメッセージを使用してスケジュールされたパスを取得することができます。
The PCEP Error (PCErr) message is a PCEP message, as described in [RFC5440], for error reporting. This document defines new error values for several error types to cover failures specific to scheduling and reuses the applicable error types and error values of [RFC5440] and [RFC8231] wherever appropriate.
ERROR Reportingの[RFC5440]で説明されているPCEPエラー（PCERR）メッセージはPCEPメッセージです。このドキュメントでは、スケジューリングに固有の障害をカバーするための新しいエラー値の新しいエラー値を定義し、適切な場合はRFC5440]と[RFC8231]の該当するエラータイプとエラー値を再利用します。
The PCEP extensions for scheduling MUST NOT be used if one or both of the PCEP speakers have not set the corresponding bits in the STATEFUL-PCE-CAPABILITY TLV in their respective Open messages to one. If the PCEP speaker supports the extensions of this specification but did not advertise this capability, then upon receipt of LSP object with the scheduled TLV, it MUST generate a PCEP Error (PCErr) with Error-Type = 19 (Invalid Operation) and Error-value = 15 (Attempted LSP scheduling while the scheduling capability was not advertised), and it SHOULD ignore the TLV. As per Section 7.1 of [RFC5440], a legacy PCEP implementation that does not understand this specification would consider a scheduled TLV unknown and ignore it.
PCEPスピーカーの一方または両方のPCEPスピーカーが、それぞれの開いているメッセージ内のステートフルPCE機能TLVの対応するビットを設定していない場合、スケジューリングのためのPCEP拡張を使用しないでください。PCEPスピーカーがこの仕様の拡張機能をサポートしているがこの機能をアドバタイズしなかった場合は、スケジュールされたTLVを使用してLSPオブジェクトを受信した場合、ERROR-TYPE = 19（無効な操作）およびエラーを持つPCEPエラー（PCERR）を生成する必要があります。値= 15（スケジューリング機能が広告されていない間は、LSPスケジューリングの試行が試行されました）、TLVを無視してください。[RFC5440]のセクション7.1によると、この仕様を理解していないレガシーPCEP実装では、スケジュールされたTLVが不明でそれを無視します。
If the PCC decides that the scheduling parameters proposed in the PCUpd/PCInitiate message are unacceptable, it MUST report this error by including the LSP-ERROR-CODE TLV (Section 7.3.3 of [RFC8231]) with LSP Error-value = 4 (Unacceptable parameters) in the LSP object (with the scheduled TLV) in the PCRpt message to the PCE.
PCCがPCUPD / pcinitiateメッセージで提案されているスケジューリングパラメータが受け入れられないことを決定した場合は、LSP-Error-Code TLV（RFC8231のセクション7.3.3）をLSPエラー値= 4に含めることで、このエラーを報告する必要があります。PCRPTメッセージ内のLSPオブジェクト（スケジュールされているTLVを持つ）内の許容できないパラメータ。
The scheduled TLV MUST be included in the LSP object for the scheduled LSPs. If the TLV is missing, the receiving PCEP speaker MUST send a PCErr message with Error-Type = 6 (Mandatory Object missing) and Error-value = 16 (Scheduled TLV missing).
スケジュールされたLSPのLSPオブジェクトにスケジュールされたTLVを含める必要があります。TLVが見つからない場合、受信側PCEPスピーカーはError-Type = 6（必須オブジェクトが見つからない）とERROR-VALUE = 16（スケジュールされているTLVが見つからない）でPCERRメッセージを送信する必要があります。
This document defines the LSP-SCHEDULING-CAPABILITY TLV and SCHED-LSP-ATTRIBUTE TLV; the security considerations discussed in [RFC5440], [RFC8231], and [RFC8281] continue to apply. In some deployments, the scheduling information could provide details about the network operations that could be deemed extra sensitive. Additionally, snooping of PCEP messages with such data or using PCEP messages for network reconnaissance may give an attacker sensitive information about the operations of the network. A single PCEP message can now instruct a PCC to set up and tear down an LSP every second for a number of times. That single message could have a significant effect on the network. Thus, such deployments SHOULD employ suitable PCEP security mechanisms like TCP Authentication Option (TCP-AO), which is discussed in [RFC5925] and [RFC8253]. Note that [RFC8253] is considered a security enhancement and thus is much better suited for sensitive information. PCCs may also need to apply some form of rate limit to the processing of scheduled LSPs.
このドキュメントでは、LSPスケジューリング機能TLVとSCHED-LSP-属性TLVを定義します。 [RFC5440]、[RFC8231]、[RFC8281]で説明しているセキュリティ上の考慮事項は適用され続けます。いくつかの展開では、スケジューリング情報は、余分な敏感と見なすことができるネットワーク操作に関する詳細を提供することができます。さらに、そのようなデータを含むPCEPメッセージのスヌーピングまたはネットワーク偵察のためのPCEPメッセージを使用することは、ネットワークの動作に関する攻撃者に敏感な情報を与える可能性がある。単一のPCEPメッセージは、PCCにPCCにLSPをセットアップし、LSPを毎秒切り取ることができます。その単一のメッセージはネットワークに大きな影響を与える可能性があります。したがって、そのような展開は、[RFC5925]および[RFC8253]で説明されているTCP認証オプション（TCP-AO）のような適切なPCEPセキュリティメカニズムを使用する必要があります。 [RFC8253]はセキュリティの強化と見なされ、したがって機密情報にはるかに適しています。 PCCは、スケジュールされたLSPの処理に何らかの形式のレート制限を適用する必要があるかもしれません。
The LSP scheduling feature MUST be controlled per tunnel by the active stateful PCE. The values for parameters like start time and duration SHOULD be configurable by customer applications and based on the local policy at PCE. The suggested default values for start time and duration are one day (in seconds) from the current time and one year (in seconds), respectively. One day has 86,400 seconds. One year has 31,536,000 seconds.
LSPスケジューリング機能は、アクティブなステートフルPCEによってトンネルごとに制御する必要があります。開始時刻と期間などのパラメータの値は、PCEのローカルポリシーに基づいて、カスタマーアプリケーションによって設定可能である必要があります。開始時刻と期間の推奨されるデフォルト値は、現在時刻と1年（秒）の1日（秒単位）です。ある日は86,400秒です。1年は31,536,000秒です。
When configuring the parameters for time, a user SHOULD consider leap years and leap seconds. If a scheduled LSP has a time interval containing a leap year, the duration of the LSP is 366 days plus the rest of the interval.
時間の間パラメータを設定するとき、ユーザーはうるう年度と閏秒を検討する必要があります。スケジュールされたLSPがうるう年を含む時間間隔を持つ場合、LSPの期間は366日と残りの間隔である。
An implementation SHOULD allow the operator to view the information about each scheduled LSP defined in this document. To serve this purpose, the PCEP YANG module [PCE-PCEP-YANG] could be extended.
実装により、オペレータはこのドキュメントで定義されている各スケジュールされた各LSPに関する情報を表示できるようにします。この目的を果たすために、PCEPヤンモジュール[PCE-PCEP-YANG]を拡張することができます。
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].
この文書で定義されているメカニズムは、[RFC5440]にすでにリストされているものに加えて、新しい活性検出および監視要件を意味しません。
Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440]. An implementation SHOULD allow a user to view information, including the status of a scheduled LSP, through a Command Line Interface (CLI) tool. In addition, it SHOULD check and handle the cases where there is a significant time correction or a clock skew between PCC and PCE.
この文書で定義されているメカニズム[RFC5440]に記載されているものに加えて、新しい操作検証要件を暗示していません。実装は、コマンドラインインターフェイス（CLI）ツールを介して、スケジュールされたLSPのステータスを含む情報を表示することを可能にする必要があります。さらに、PCCとPCEの間にかなりの時間訂正や時計の傾斜がある場合を確認して処理する必要があります。
Mechanisms defined in this document do not imply any new requirements on other protocols.
この文書で定義されているメカニズムは、他のプロトコルに関する新しい要件を暗示しません。
Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440].
この文書で定義されているメカニズムは、[RFC5440]に記載されているものに加えて、ネットワーク操作にも影響を与えません。
IANA maintains the "PCEP TLV Type Indicators" subregistry within the "Path Computation Element Protocol (PCEP) Numbers" registry. IANA has made the following allocations in this subregistry for the new PCEP TLVs defined in this document.
IANAは、「PATH計算要素プロトコル（PCEP）番号」レジストリ内で「PCEP TLVタイプインジケータ」サブリュージストリを維持しています。IANAは、この文書で定義されている新しいPCEP TLVのこのサブレジストに次の割り当てを行った。
+=======+========================+===============+
| Value | Description | Reference |
+=======+========================+===============+
| 49 | SCHED-LSP-ATTRIBUTE | This document |
+-------+------------------------+---------------+
| 50 | SCHED-PD-LSP-ATTRIBUTE | This document |
+-------+------------------------+---------------+
Table 1: Additions to PCEP TLV Type Indicators Subregistry
表1：PCEP TLVタイプ指標サブレジストの追加
IANA has created and will maintain a new subregistry named "SCHED-PD-LSP-ATTRIBUTE TLV Opt Field" within the "Path Computation Element Protocol (PCEP) Numbers" registry. Initial values for the subregistry are given below. New values are assigned by Standards Action [RFC8126].
IANAは、「PATH計算要素プロトコル（PCEP）番号」レジストリ内の「SCHED-PD-LSP-属性TLV OPTフィールド」という名前の新しいサブレジストを維持します。サブレジストの初期値を以下に示します。新しい値は標準アクション[RFC8126]によって割り当てられます。
+=======+=================================+===============+
| Value | Description | Reference |
+=======+=================================+===============+
| 0 | Reserved | |
+-------+---------------------------------+---------------+
| 1 | REPEAT-EVERY-MONTH | This document |
+-------+---------------------------------+---------------+
| 2 | REPEAT-EVERY-YEAR | This document |
+-------+---------------------------------+---------------+
| 3 | REPEAT-EVERY-REPEAT-TIME-LENGTH | This document |
+-------+---------------------------------+---------------+
| 4-14 | Unassigned | |
+-------+---------------------------------+---------------+
| 15 | Reserved | |
+-------+---------------------------------+---------------+
Table 2: New SCHED-PD-LSP-ATTRIBUTE TLV Opt Field Subregistry
表2：新しいSCHED-PD-LSP-属性TLV OPTフィールドサブレジスト
IANA has created a new subregistry named "Schedule TLVs Flag Field" within the "Path Computation Element Protocol (PCEP) Numbers" registry. New values are assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
IANAは、「PATH計算要素プロトコル（PCEP）番号」レジストリ内に「Schedule TLVS Flagフィールド」という名前の新しいサブレジストを作成しました。新しい値は標準アクション[RFC8126]によって割り当てられます。各ビットは次の資質で追跡されるべきです。
* Bit number (counting from bit 0 as the most significant bit)
* ビット数（最上位ビットとしてのビット0からのカウント）
* Capability description
* 機能の説明
* Defining RFC
* RFCを定義する
The following values are defined in this document:
この文書では、次の値が定義されています。
+=====+===============================+===============+
| Bit | Description | Reference |
+=====+===============================+===============+
| 0-3 | Unassigned | |
+-----+-------------------------------+---------------+
| 4 | Relative Time (R-bit) | This document |
+-----+-------------------------------+---------------+
| 5 | PCC Responsible (C-bit) | This document |
+-----+-------------------------------+---------------+
| 6 | LSP Activated (A-bit) | This document |
+-----+-------------------------------+---------------+
| 7 | Grace Period Included (G-bit) | This document |
+-----+-------------------------------+---------------+
Table 3: New Schedule TLVs Flag Field Subregistry
表3：新しいスケジュールTLVS FLAGフィールドサブレジスト
This document defines new bits in the Flags field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. IANA maintains the "STATEFUL-PCE-CAPABILITY TLV Flag Field" subregistry within the "Path Computation Element Protocol (PCEP) Numbers" registry. IANA has made the following allocations in this subregistry.
このドキュメントでは、Openオブジェクト内のステートフルPCE機能TLVのFlagsフィールドに新しいビットを定義します。IANAは、「PATH計算要素プロトコル（PCEP）番号」レジストリ内の「ステートフルPCE機能TLVフラグフィールド」サブリュージストを維持しています。IANAはこのサブレジストに以下の割り当てをしました。
+=====+===================================+===============+
| Bit | Description | Reference |
+=====+===================================+===============+
| 22 | LSP-SCHEDULING-CAPABILITY (B-bit) | This document |
+-----+-----------------------------------+---------------+
| 21 | PD-LSP-CAPABILITY (PD-bit) | This document |
+-----+-----------------------------------+---------------+
Table 4: Additions to STATEFUL-PCE-CAPABILITY TLV Flag Field Subregistry
表4：ステートフルPCE機能への追加TLV FLAGフィールドサブレジスト
IANA has allocated the following new error types to the existing error values within the "PCEP-ERROR Object Error Types and Values" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry:
IANAは、「PCEP-Errorオブジェクトエラー型と値」の「PATH計算要素プロトコル（PCEP）番号」レジストリ内の既存のエラー値に次のエラー値を割り当てました。
+============+================+===============================+
| Error-Type | Meaning | Error-value |
+============+================+===============================+
| 6 | Mandatory | 16: Scheduled TLV missing |
| | Object missing | |
+------------+----------------+-------------------------------+
| 19 | Invalid | 15: Attempted LSP scheduling |
| | Operation | while the scheduling |
| | | capability was not advertised |
+------------+----------------+-------------------------------+
| 29 | Path | 5: Constraints could not be |
| | computation | met for some intervals |
| | failure | |
+------------+----------------+-------------------------------+
Table 5: Additions to PCEP-ERROR Object Error Types and Values Subregistry
表5：PCEPエラーオブジェクトエラータイプと値サブレイストの追加
[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、「RFCSで使用するためのキーワード」、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計算要素（PCE）通信プロトコル（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<https：//www.rfc-editor.org/info/rfc5440>。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5905]ミルズ、D.、Martin、J.、Ed。、Burbank、J.、およびW. Kasch、「ネットワークタイムプロトコルバージョン4：プロトコルおよびアルゴリズム仕様」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月<https://www.rfc-editor.org/info/rfc5905>。
[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.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[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、ステートフルPCEの「パス計算要素通信プロトコル（PCEP）拡張機能」、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。、Medived、J.、Varga、R.、Zhang、X.、およびD.D.Dhody、「ラベルスイッチパス状態の最適化：ステートフルPCEのための最適化」、RFC 8232、DOI 10.17487 / RFC8232、2017年9月、<https：//www.rfc-editor.org/info/rfc8232>。
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, <https://www.rfc-editor.org/info/rfc8281>.
[RFC8281] Crabbe、E.、Minei、I.、Sivabalan、S.、およびR. Varga、ステートフルPCEモデルにおけるPCE開始LSPセットアップのための「PCEP演算要素通信プロトコル（PCE）拡張」、RFC 8281、DOI2017487 / RFC8281、2017年12月、<https：//www.rfc-editor.org/info/rfc8281>。
[RFC8413] Zhuang, Y., Wu, Q., Chen, H., and A. Farrel, "Framework for Scheduled Use of Resources", RFC 8413, DOI 10.17487/RFC8413, July 2018, <https://www.rfc-editor.org/info/rfc8413>.
[RFC8413] Zhuang、Y.、Wu、Q.、Chen、H.、およびA. Farrel、RFC 8413、DOI 10.17487 / RFC8413、2018年7月、<https：// www。rfc-editor.org/info/rfc8413>。
[PCE-PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, Internet-Draft, draft-ietf-pce-pcep-yang-15, 31 October 2020, <https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-15>.
[PCE-PCEP-YANG] Dhody、D.、Hardwick、J.、Bearam、VP、J.Tantura、「パス計算要素通信プロトコル（PCEP）のYangデータモデル」、進行中の作業、インターネットドラフト、DRAFT-IETF-PCE-PCEP-YANG-15,2020、<https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-15>。
[PCE-STATE-SYNC] Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter Stateful Path Computation Element (PCE) Communication Procedures.", Work in Progress, Internet-Draft, draft-litkowski-pce-state-sync-08, 12 July 2020, <https://tools.ietf.org/html/draft-litkowski-pce-state-sync-08>.
[PCE-STATE-SYNC] Litkowski、S.、Sivabalan、S.、Li、C、およびH.Zheng、「インターステートフルパス計算要素（PCE）通信手順」、進行中の作業、インターネットドラフト、ドラフト-litkowski-pce-state-sync-08,2020、<https://tools.ietf.org/html/draft-litkowski-pce-state-sync-08>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A.、R.ボニカ、「TCP認証オプション」、RFC 5925、DOI 10.17487 / RFC5925、2010年6月、<https://www.rfc-editor.org/info/ RFC5925>。
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path Computation Element Architecture", RFC 7399, DOI 10.17487/RFC7399, October 2014, <https://www.rfc-editor.org/info/rfc7399>.
[RFC7399] Farrel、A.およびD. King、「パス計算要素のアーキテクチャにおける未回答の質問」、RFC 7399、DOI 10.17487 / RFC7399、2014年10月、<https://www.rfc-editor.org/info/rfc7399>。
[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] Zhang、X.、ED。そして、「ステートフルパス計算要素（PCE）」、RFC 8051、DOI 10.17487 / RFC8051、2017年1月、<https://www.rfc-editor.org/info/rfc8051>。
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, <https://www.rfc-editor.org/info/rfc8253>.
[RFC8253] Lopez、D.、Gonzalez De Deos、O.、Wu、Q.、およびD.Dhody、 "PCEP：パス計算要素通信プロトコル（PCEP）のための安全な輸送（PCEP）"、RFC 8253、DOI 10.17487 / RFC8253、2017年10月、<https://www.rfc-editor.org/info/rfc8253>。
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8402] Filsfils、C、Ed。、Previdi、S.、Ed。、Ginsberg、L.、Decraene、B.、Litkowski、S.、およびR. Shakir、「セグメントルーティングアーキテクチャ」、RFC 8402、DOI 10.17487/ RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, <https://www.rfc-editor.org/info/rfc8655>.
[RFC8655] Finn、N.、Thubert、P.、Varga、B.、およびJ. Farkas、「決定論的ネットワーキングアーキテクチャ」、RFC 8655、DOI 10.17487 / RFC8655、2019年10月、<https：//www.rfc-編集者.org / info / rfc8655>。
Acknowledgments
謝辞
The authors of this document would also like to thank Rafal Szarecki, Adrian Farrel, and Cyril Margaria for the review and comments.
この文書の著者らは、レビューとコメントのためにRafal Szarecki、Adrian Farrel、およびCyril Margariaに感謝します。
Contributors
貢献者
Dhruv Dhody Huawei Divyashree Techno Park, Whitefield Bangalore 560066 Karnataka India
Dhruv Dhody Huawei Divyasrea Technopark、Whitefield Bangalore 560066カルナータカインド
Email: dhruv.ietf@gmail.com
Xufeng Liu Ericsson United States of America
Xufeng Liu Ericssonアメリカ合衆国
Email: xliu@kuatrotech.com
Mehmet Toy Verizon United States of America
Mehmet Toy Verizonアメリカ合衆国
Email: mehmet.toy@verizon.com
Vic Liu China Mobile No.32 Xuanwumen West Street, Xicheng District Beijing 100053 China
Vic Liu China Mobile No.32 Xuanwumen West Street、Xicheng District Beijing 100053中国
Email: liu.cmri@gmail.com
Lei Liu Fujitsu United States of America
レイリウ富士通アメリカ合衆国
Email: lliu@us.fujitsu.com
Khuzema Pithewan Infinera
Khuzema Pithewan Infinera.
Email: kpithewan@infinera.com
Zitao Wang Huawei 101 Software Avenue, Yuhua District Nanjing Jiangsu, 210012 China
Zitao Wang Huawei 101 Software Avenue、Yuhua District Nanjing Jiangsu、210012中国
Email: wangzitao@huawei.com
Xian Zhang Huawei Technologies Research Area F3-1B Huawei Industrial Base Shenzhen 518129 China
Xian Zhang Huawei Technologies Research Area F3-1B Huawei Industrial Base Shenzhen 518129中国
Email: zhang.xian@huawei.com
Authors' Addresses
著者の住所
Huaimo Chen (editor) Futurewei Boston, MA United States of America
Huaimo Chen（編集）Futurewei Boston、MAアメリカ合衆国
Email: huaimo.chen@futurewei.com
Yan Zhuang (editor) Huawei Yuhua District 101 Software Avenue Nanjing Jiangsu, 210012 China
Yan Zhuang（編集）Huawei Yuhua District 101ソフトウェアアベニュー南京江蘇省、210012中国
Email: zhuangyan.zhuang@huawei.com
Qin Wu Huawei Yuhua District 101 Software Avenue Nanjing Jiangsu, 210012 China
Qin Wu Huawei Yuhua District 101ソフトウェアアベニュー南京江蘇省、210012中国
Email: bill.wu@huawei.com
Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy
Daniele Ceccarelli Ericsson経由A. Negrone 1 / A Genova - Sestri Ponenteイタリア
Email: daniele.ceccarelli@ericsson.com