[要約] 要約：RFC 8051は、状態を持つパス計算要素（PCE）の適用可能性について説明しています。PCEは、ネットワーク内の経路計算を行うための機能です。目的：このRFCの目的は、状態を持つPCEの利点と制約を明確にし、ネットワークの経路計算におけるPCEの役割を理解することです。
Internet Engineering Task Force (IETF) X. Zhang, Ed.
Request for Comments: 8051 Huawei Technologies
Category: Informational I. Minei, Ed.
ISSN: 2070-1721 Google, Inc.
January 2017
Applicability of a Stateful Path Computation Element (PCE)
ステートフルパス計算要素（PCE）の適用性
Abstract
概要
A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic-engineering calculations for its associated Path Computation Clients (PCCs). This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCE Communication Protocol (PCEP) extensions required for stateful PCE usage are covered in separate documents.
ステートフルパス計算要素（PCE）は、関連するパス計算クライアント（PCC）のトラフィックエンジニアリング計算を提供するために、ネットワーク内のラベルスイッチドパス（LSP）特性とリソース使用状況に関する情報を維持します。このドキュメントでは、ステートフルPCE展開の一般的な考慮事項について説明し、その適用性と利点、およびその課題と制限について、さまざまなユースケースを通じて検討します。ステートフルPCEの使用に必要なPCE通信プロトコル（PCEP）拡張は、個別のドキュメントで説明されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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 http://www.rfc-editor.org/info/rfc8051.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8051で入手できます。
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 (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Application Scenarios . . . . . . . . . . . . . . . . . . . . 5
3.1. Optimization of LSP Placement . . . . . . . . . . . . . . 5
3.1.1. Throughput Maximization and Bin Packing . . . . . . . 6
3.1.2. Deadlock . . . . . . . . . . . . . . . . . . . . . . 7
3.1.3. Minimum Perturbation . . . . . . . . . . . . . . . . 9
3.1.4. Predictability . . . . . . . . . . . . . . . . . . . 10
3.2. Auto-Bandwidth Adjustment . . . . . . . . . . . . . . . . 11
3.3. Bandwidth Scheduling . . . . . . . . . . . . . . . . . . 12
3.4. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.1. Protection . . . . . . . . . . . . . . . . . . . . . 13
3.4.2. Restoration . . . . . . . . . . . . . . . . . . . . . 14
3.4.3. SRLG Diversity . . . . . . . . . . . . . . . . . . . 15
3.5. Maintenance of Virtual Network Topology (VNT) . . . . . . 15
3.6. LSP Reoptimization . . . . . . . . . . . . . . . . . . . 16
3.7. Resource Defragmentation . . . . . . . . . . . . . . . . 17
3.8. Point-to-Multipoint Applications . . . . . . . . . . . . 17
3.9. Impairment-Aware Routing and Wavelength Assignment
(IA-RWA) . . . . . . . . . . . . . . . . . . . . . . . . 18
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 19
4.1. Multi-PCE Deployments . . . . . . . . . . . . . . . . . . 19
4.2. LSP State Synchronization . . . . . . . . . . . . . . . . 19
4.3. PCE Survivability . . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Normative References . . . . . . . . . . . . . . . . . . 20
6.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
[RFC4655] defines the architecture for a model based on the Path Computation Element (PCE) for the computation of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs). To perform such a constrained computation, a PCE stores the network topology (i.e., TE links and nodes) and resource information (i.e., TE attributes) in its TE Database (TED). [RFC5440] describes the Path Computation Element Protocol (PCEP) for interaction between a Path Computation Client (PCC) and a PCE, or between two PCEs, enabling computation of TE LSPs.
[RFC4655]は、マルチプロトコルラベルスイッチング（MPLS）および一般化MPLS（GMPLS）トラフィックエンジニアリングラベルスイッチドパス（TE LSP）の計算のためのパス計算要素（PCE）に基づくモデルのアーキテクチャを定義します。そのような制約された計算を実行するために、PCEはネットワークトポロジ（つまり、TEリンクとノード）とリソース情報（つまり、TE属性）をTEデータベース（TED）に格納します。 [RFC5440]は、パス計算クライアント（PCC）とPCEの間、または2つのPCE間の相互作用のためのパス計算要素プロトコル（PCEP）を説明し、TE LSPの計算を可能にします。
As per [RFC4655], a PCE can be either stateful or stateless. A stateful PCE maintains two sets of information for use in path computation. The first is the Traffic Engineering Database (TED), which includes the topology and resource state in the network. This information can be obtained by a stateful PCE using the same mechanisms as a stateless PCE (see [RFC4655]). The second is the LSP State Database (LSP-DB), in which a PCE stores attributes of all active LSPs in the network, such as their paths through the network, bandwidth/resource usage, switching types, and LSP constraints. This state information allows the PCE to compute constrained paths while considering individual LSPs and their inter-dependency. However, this requires reliable state synchronization mechanisms between the PCE and the network, between the PCE and the PCCs, and between cooperating PCEs, with potentially significant control-plane overhead and maintenance of a large amount of state data, as explained in [RFC4655].
[RFC4655]に従って、PCEはステートフルまたはステートレスのいずれかになります。ステートフルPCEは、パス計算で使用するために2セットの情報を保持します。 1つ目は、ネットワークのトポロジーとリソースの状態を含むトラフィックエンジニアリングデータベース（TED）です。この情報は、ステートレスPCEと同じメカニズムを使用して、ステートフルPCEによって取得できます（[RFC4655]を参照）。 2つ目はLSP状態データベース（LSP-DB）で、PCEはネットワーク内のすべてのアクティブなLSPの属性（ネットワーク経由のパス、帯域幅/リソースの使用、スイッチングの種類、LSP制約など）を格納します。この状態情報により、PCEは個別のLSPとその相互依存性を考慮しながら、制約されたパスを計算できます。ただし、これには、PCEとネットワーク間、PCEとPCC間、および協力するPCE間で信頼できる状態同期メカニズムが必要であり、[RFC4655]で説明されているように、潜在的に重要なコントロールプレーンオーバーヘッドと大量の状態データのメンテナンスが伴います。 。
This document describes how a stateful PCE can be used to solve various problems for MPLS-TE and GMPLS networks and the benefits it brings to such deployments. Note that alternative solutions relying on stateless PCEs may also be possible for some of these use cases and will be mentioned for completeness where appropriate.
このドキュメントでは、ステートフルPCEを使用してMPLS-TEおよびGMPLSネットワークのさまざまな問題を解決する方法と、そのような展開にもたらす利点について説明します。ステートレスPCEに依存する代替ソリューションも、これらのユースケースの一部で可能である可能性があることに注意してください。
This document uses the following terms defined in [RFC5440]: PCC, PCE, and PCEP peer.
このドキュメントでは、[RFC5440]で定義されているPCC、PCE、PCEPピアという用語を使用しています。
This document defines the following terms:
このドキュメントでは、次の用語を定義しています。
Stateful PCE: a PCE that has access to not only the network state, but also to the set of active paths and their reserved resources for its computations. A stateful PCE might also retain information regarding LSPs under construction in order to reduce churn and resource contention. The additional state allows the PCE to compute constrained paths while considering individual LSPs and their interactions. Note that this requires reliable state synchronization mechanisms between the PCE and the network, PCE and PCC, and between cooperating PCEs.
ステートフルPCE：ネットワーク状態だけでなく、アクティブパスのセットとその計算用に予約されているリソースにもアクセスできるPCE。ステートフルPCEは、チャーンとリソースの競合を減らすために、建設中のLSPに関する情報も保持する場合があります。追加の状態により、PCEは個別のLSPとその相互作用を考慮しながら、制約されたパスを計算できます。これには、PCEとネットワーク間、PCEとPCC間、および連携するPCE間で信頼できる状態同期メカニズムが必要であることに注意してください。
Passive Stateful PCE: a PCE that uses LSP state information learned from PCCs to optimize path computations. It does not actively update LSP state. A PCC maintains synchronization with the PCE.
パッシブステートフルPCE：PCCから学習したLSP状態情報を使用してパス計算を最適化するPCE。 LSPの状態は積極的に更新されません。 PCCはPCEとの同期を維持します。
Active Stateful PCE: a PCE that may issue recommendations to the network. For example, an Active Stateful PCE may use the Delegation mechanism to update LSP parameters in those PCCs that delegate control over their LSPs to the PCE.
アクティブステートフルPCE：ネットワークに推奨を発行する可能性があるPCE。たとえば、アクティブステートフルPCEは、委任メカニズムを使用して、LSPの制御をPCEに委任するPCCのLSPパラメータを更新します。
Delegation: an operation to grant a PCE temporary rights to modify a subset of LSP parameters on one or more LSPs of a PCC. LSPs are delegated from a PCC to a PCE and are referred to as "delegated" LSPs. The PCC that owns the PCE state for the LSP has the right to delegate it. An LSP is owned by a single PCC at any given point in time. For intra-domain LSPs, this PCC should be the LSP head end.
委任：PCCの1つ以上のLSP上のLSPパラメーターのサブセットを変更するための一時的なPCE権限を付与する操作。 LSPはPCCからPCEに委任され、「委任」LSPと呼ばれます。 LSPのPCE状態を所有するPCCは、それを委任する権利を持っています。 LSPは任意の時点で単一のPCCによって所有されます。ドメイン内LSPの場合、このPCCはLSPヘッドエンドでなければなりません。
LSP State Database: information about all LSPs and their attributes.
LSP状態データベース：すべてのLSPとその属性に関する情報。
PCE Initiation: assuming LSP delegation granted by default, a PCE can issue recommendations to the network.
PCE開始：デフォルトでLSP委任が許可されていると仮定すると、PCEはネットワークに推奨を発行できます。
Minimum Cut Set: the minimum set of links for a specific source destination pair that, when removed from the network, results in a specific source being completely isolated from a specific destination. The summed capacity of these links is equivalent to the maximum capacity from the source to the destination by the max-flow min-cut theorem.
最小カットセット：ネットワークから削除されたときに、特定のソースが特定の宛先から完全に分離される特定のソースと宛先のペアのリンクの最小セット。これらのリンクの合計容量は、max-flow min-cut定理によるソースから宛先への最大容量に相当します。
In the following sections, several use cases are described, showcasing scenarios that benefit from the deployment of a stateful PCE.
次のセクションでは、いくつかの使用例について説明し、ステートフルPCEの展開からメリットを得るシナリオを紹介します。
The following use cases demonstrate a need for visibility into global LSP states in PCE path computations, and for a PCE control of sequence and timing in altering LSP path characteristics within and across PCEP sessions. Reference topologies for the use cases described later in this section are shown in Figures 1 and 2.
次の使用例は、PCEパス計算でグローバルLSP状態を可視化する必要性と、PCEPセッション内およびPCEPセッション間でLSPパス特性を変更する際のシーケンスとタイミングのPCE制御の必要性を示しています。このセクションで後述するユースケースの参照トポロジを図1および2に示します。
Some of the use cases below are focused on MPLS-TE deployments but may also apply to GMPLS. Unless otherwise cited, use cases assume that all LSPs listed exist at the same LSP priority.
以下のユースケースの一部はMPLS-TEの導入に焦点を当てていますが、GMPLSにも適用される場合があります。特に明記されていない限り、使用例では、リストされているすべてのLSPが同じLSP優先順位で存在すると想定しています。
The main benefit in the cases below comes from moving away from an asynchronous PCC-driven mode of operation to a model that allows for central control over LSP computations and maintenance, and focuses specifically on the active stateful PCE model of operation.
以下の場合の主な利点は、非同期のPCC駆動モードの操作から、LSPの計算と保守を集中的に制御できるモデルに移行することであり、アクティブなステートフルPCE操作モデルに特に焦点を当てています。
+-----+
| A |
+-----+
\
+-----+ +-----+
| C |----------------------| E |
+-----+ +-----+
/ \ +-----+ /
+-----+ +-----| D |-----+
| B | +-----+
+-----+
Figure 1: Reference Topology 1
図1：参照トポロジ1
+-----+ +-----+ +-----+
| A | | B | | C |
+--+--+ +--+--+ +--+--+
| | |
| | |
+--+--+ +--+--+ +--+--+
| E +--------+ F +--------+ G |
+-----+ +-----+ +-----+
Figure 2: Reference Topology 2
図2：参照トポロジ2
Because LSP attribute changes in [RFC5440] are driven by Path Computation Request (PCReq) messages under control of a PCC's local timers, the sequence of resource reservation arrivals occurring in the network will be randomized. This, coupled with a lack of global LSP state visibility on the part of a stateless PCE, may result in suboptimal throughput in a given network topology, as will be shown in the example below.
[RFC5440]のLSP属性の変更は、PCCのローカルタイマーの制御下にあるパス計算要求（PCReq）メッセージによって駆動されるため、ネットワークで発生するリソース予約到着のシーケンスはランダム化されます。これと、ステートレスPCEの部分でのグローバルLSP状態の可視性の欠如と相まって、以下の例に示すように、特定のネットワークトポロジでスループットが最適ではなくなる可能性があります。
Reference Topology 2 in Figure 2 and Tables 1 and 2 show an example in which throughput is at 50% of optimal as a result of the lack of visibility and synchronized control across PCCs. In this scenario, the decision must be made as to whether to route any portion of the E-G demand, as any demand routed for this source and destination will decrease system throughput.
図2の参照トポロジ2と表1および2は、PCC間の可視性と同期制御の欠如の結果としてスループットが最適の50％である例を示しています。この送信元と宛先にルーティングされるデマンドはシステムのスループットを低下させるため、このシナリオでは、E-Gデマンドの一部をルーティングするかどうかを決定する必要があります。
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-E | 1 | 10 |
| B-F | 1 | 10 |
| C-G | 1 | 10 |
| E-F | 1 | 10 |
| F-G | 1 | 10 |
+------+--------+----------+
Table 1: Link Parameters for Throughput Use Case
表1：スループットの使用例のリンクパラメーター
+------+-----+-----+-----+--------+----------+-------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+-------+
| 1 | 1 | E | G | 10 | Yes | E-F-G |
| 2 | 2 | A | B | 10 | No | --- |
| 3 | 1 | F | C | 10 | No | --- |
+------+-----+-----+-----+--------+----------+-------+
Table 2: Throughput Use Case Demand Time Series
表2：スループットの使用例の需要時系列
In many cases, throughput maximization becomes a bin-packing problem. While bin packing itself is an NP-hard problem, a number of common heuristics that run in polynomial time can provide significant improvements in throughput over random reservation event distribution, especially when traversing links that are members of the minimum cut set for a large subset of source destination pairs.
多くの場合、スループットの最大化はビンパッキングの問題になります。ビンパッキング自体はNP困難な問題ですが、多項式時間で実行される多くの一般的なヒューリスティックにより、ランダム予約イベントの分散よりもスループットが大幅に向上します。特に、大規模なサブセットの最小カットセットのメンバーであるリンクをトラバースする場合ソースと宛先のペア。
Tables 3 and 4 show a simple use case using Reference Topology 1 in Figure 1, where LSP state visibility and control of reservation order across PCCs would result in significant improvement in total throughput.
表3および4は、図1の参照トポロジ1を使用した簡単な使用例を示しています。LSC状態の可視性とPCC全体での予約順序の制御により、総スループットが大幅に向上します。
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 10 | 5 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
Table 3: Link Parameters for Bin-Packing Use Case
表3：Bin-Packingユースケースのリンクパラメーター
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 5 | Yes | A-C-D-E |
| 2 | 2 | B | E | 10 | No | --- |
+------+-----+-----+-----+--------+----------+---------+
Table 4: Bin-Packing Use Case Demand Time Series
表4：ビンパッキングの使用例の需要時系列
This section discusses the use case of cross-LSP impact under degraded operation. Most existing RSVP-TE implementations will not tear down established LSPs in the event of the failure of the bandwidth increase procedure detailed in [RFC3209]. This behavior is directly implied to be correct in [RFC3209] and is often desirable from an operator's perspective, because either a) the destination prefixes are not reachable via any means other than MPLS or b) this would result in significant packet loss as demand is shifted to other LSPs in the overlay mesh.
このセクションでは、動作が低下した場合のクロスLSP影響の使用例について説明します。既存のほとんどのRSVP-TE実装は、[RFC3209]で詳述されている帯域幅増加手順が失敗した場合、確立されたLSPを破棄しません。この動作は[RFC3209]で直接正しいことを暗示しており、a）MPLS以外の方法で宛先プレフィックスに到達できない、またはb）要求があるため、パケット損失が大幅に増えるため、オペレーターの観点からは望ましいことがよくあります。オーバーレイメッシュ内の他のLSPにシフトしました。
In addition, there are currently few implementations offering dynamic ingress admission control (policing of the traffic volume mapped onto an LSP) at the Label Edge Router (LER). Having ingress admission control on a per-LSP basis is not necessarily desirable from an operational perspective, as a) one must over-provision tunnels significantly in order to avoid deleterious effects resulting from stacked transport and flow control systems (for example, for tunnels that are dynamically resized based on current traffic) and b) there is currently no efficient commonly available northbound interface for dynamic configuration of per-LSP ingress admission control.
さらに、現在、ラベルエッジルーター（LER）で動的なイングレスアドミッション制御（LSPにマップされたトラフィックボリュームのポリシング）を提供する実装はほとんどありません。 a）スタックされたトランスポートおよびフロー制御システムから生じる有害な影響を回避するために、トンネルを大幅にプロビジョニングしなければならないため（たとえば、トンネルの場合）、LSPごとに入口アドミッション制御を行うことは必ずしも望ましいことではありません。現在のトラフィックに基づいて動的にサイズ変更されます）、およびb）LSPごとの入口アドミッション制御の動的な構成のための、一般的に利用可能な効率的なノースバウンドインターフェイスはありません。
Lack of ingress admission control coupled with the behavior in [RFC3209] may result in LSPs operating out of profile for significant periods of time. It is reasonable to expect that these out-of-profile LSPs will be operating in a degraded state and experience traffic loss. Moreover, because those LSPs end up sharing common network interfaces with other LPSs operating within their bandwidth reservations, they will impact the operation of the in-profile LSPs, even when there is unused network capacity elsewhere in the network. Furthermore, this behavior will cause information loss in the TED with regards to the actual available bandwidth on the links used by the out-of-profile LSPs, as the reservations on the links no longer reflect the capacity used.
[RFC3209]の動作に加えて、イングレスアドミッションコントロールの欠如により、LSPがかなりの期間プロファイル外で動作する可能性があります。これらの不適合なLSPが機能低下状態で動作し、トラフィック損失が発生することを期待することは妥当です。さらに、これらのLSPは、帯域幅予約内で動作している他のLPSと共通のネットワークインターフェイスを共有するため、ネットワークの他の場所に未使用のネットワーク容量がある場合でも、プロファイル内LSPの動作に影響します。さらに、リンク上の予約には使用された容量が反映されなくなるため、この動作により、プロファイル外のLSPによって使用されるリンクで実際に使用可能な帯域幅に関して、TEDで情報が失われます。
Reference Topology 1 in Figure 1 and Tables 5 and 6 show a use case that demonstrates this behavior. Two LSPs, LSP 1 and LSP 2, are signaled with demand 2 and routed along paths A-C-D-E and B-C-D-E, respectively. At a later time, the demand of LSP 1 increases to 20. Under such a demand, the LSP cannot be resignaled. However, the existing LSP will not be torn down. In the absence of ingress policing, traffic on LSP 1 will cause degradation for traffic of LSP 2 (due to oversubscription on the links C-D and D-E), as well as information loss in the TED with regard to the actual network state.
図1の参照トポロジ1と表5および6は、この動作を示す使用例を示しています。 2つのLSP、LSP 1とLSP 2はデマンド2で通知され、それぞれパスA-C-D-EとB-C-D-Eに沿ってルーティングされます。後で、LSP 1の要求は20に増加します。このような要求の下では、LSPは再シグナリングできません。ただし、既存のLSPは破棄されません。入力ポリシングがない場合、LSP 1のトラフィックは、LSP 2のトラフィックの劣化（リンクC-DおよびD-Eのオーバーサブスクリプションによる）と、実際のネットワーク状態に関するTEDの情報損失を引き起こします。
The problem could be easily ameliorated by global visibility of the LSP state coupled with PCC-external demand measurements and placement of two LSPs on disjoint links. Note that while the demand of 20 for LSP 1 could never be satisfied in the given topology, isolation from the ill-effects of the (unsatisfiable) increased demand could be achieved.
この問題は、LSC状態のグローバルな可視性とPCC外部需要測定、および2つのLSPを互いに素なリンクに配置することで、グローバルな可視性によって簡単に改善できます。 LSP 1の20の要求は特定のトポロジーでは決して満たすことはできませんが、（満たされない）増加した要求の悪影響からの分離を実現できることに注意してください。
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 10 | 5 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
Table 5: Link Parameters for the 'Degraded Operation' Example
表5：「縮退操作」の例のリンクパラメーター
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 2 | Yes | A-C-D-E |
| 2 | 2 | B | E | 2 | Yes | B-C-D-E |
| 3 | 1 | A | E | 20 | No | --- |
+------+-----+-----+-----+--------+----------+---------+
Table 6: 'Degraded Operation' Demand Time Series
表6：「縮退運転」需要時系列
As a result of both the lack of visibility into the global LSP state and the lack of control over event ordering across PCE sessions, unnecessary perturbations may be introduced into the network by a stateless PCE. Tables 7 and 8 show an example of an unnecessary network perturbation using Reference Topology 1 in Figure 1. In this case, an unimportant (high LSP priority value) LSP (LSP1) is first set up along the shortest path. At time 2, which is assumed to be relatively close to time 1, a second more important (lower LSP-priority value) LSP (LSP2) is established, preempting LSP1 potentially causing traffic loss. LSP1 is then reestablished on the longer A-C-E path.
グローバルなLSP状態の可視性の欠如と、PCEセッション全体でのイベントの順序付けの制御の欠如の両方の結果として、ステートレスPCEによって不必要な摂動がネットワークに導入される可能性があります。表7および8は、図1の参照トポロジ1を使用した不要なネットワーク摂動の例を示しています。この場合、重要でない（LSP優先度の値が高い）LSP（LSP1）が最短パスに沿って最初にセットアップされます。時間1に比較的近いと想定される時間2では、2番目に重要な（LSP優先度の値が低い）LSP（LSP2）が確立され、LSP1をプリエンプトしてトラフィック損失を引き起こす可能性があります。その後、LSP1がより長いA-C-Eパスで再確立されます。
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 10 | 10 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
Table 7: Link Parameters for the 'Minimum-Perturbation' Example
表7： 'Minimum-Perturbation'の例のリンクパラメーター
+------+-----+-----+-----+--------+----------+----------+---------+
| Time | LSP | Src | Dst | Demand | LSP Prio | Routable | Path |
+------+-----+-----+-----+--------+----------+----------+---------+
| 1 | 1 | A | E | 7 | 7 | Yes | A-C-D-E |
| 2 | 2 | B | E | 7 | 0 | Yes | B-C-D-E |
| 3 | 1 | A | E | 7 | 7 | Yes | A-C-E |
+------+-----+-----+-----+--------+----------+----------+---------+
Table 8: 'Minimum-Perturbation' LSP and Demand Time Series
表8：「最小摂動」LSPおよび需要時系列
A stateful PCE can help in this scenario by computing both routes at the same time. The advantages of using a stateful PCE over exploiting a stateless PCE via Global Concurrent Optimization (GCO) are threefold. First is the ability to accommodate concurrent path computation from different PCCs. Second is the reduction of control-plane overhead since the stateful PCE has the route information of the affected LSPs. Thirdly, the stateful PCE can use the LSP-DB to further optimize the placement of LSPs. This will ensure placement of the more important LSP along the shortest path, avoiding the setup and subsequent preemption of the lower priority LSP. Similarly, when a new higher priority LSP that requires preemption of an existing lower priority LSP(s), a stateful PCE can determine the minimum number of lower priority LSPs to reroute using the Make-Before-Break (MBB) mechanism without disrupting any service and then set up the higher priority LSP.
ステートフルPCEは、両方のルートを同時に計算することにより、このシナリオで役立ちます。グローバル同時最適化（GCO）を介してステートレスPCEを利用するよりも、ステートフルPCEを使用することの利点は3つあります。 1つは、さまざまなPCCからの同時パス計算に対応する機能です。 2つ目は、ステートフルPCEが影響を受けるLSPのルート情報を持っているため、コントロールプレーンオーバーヘッドの削減です。 3番目に、ステートフルPCEはLSP-DBを使用して、LSPの配置をさらに最適化できます。これにより、最も重要なLSPが最短経路に沿って配置され、優先順位の低いLSPのセットアップとその後のプリエンプションが回避されます。同様に、既存の優先度の低いLSPのプリエンプションを必要とする新しい優先度の高いLSPの場合、ステートフルPCEは、サービスを中断することなくMake-Before-Break（MBB）メカニズムを使用して再ルーティングする優先度の低いLSPの最小数を決定できます。次に、優先度の高いLSPを設定します。
Randomization of reservation events caused by lack of control over event ordering across PCE sessions results in poor predictability in LSP routing. An offline system applying a consistent optimization method will produce predictable results to within either the boundary of forecast error (when reservations are over-provisioned by reasonable margins) or to the variability of the signal and the forecast error (when applying some hysteresis in order to minimize churn). Predictable results are valuable for being able to simulate the network and reliably test it under various scenarios, especially under various failure modes and planned maintenances when predictable path characteristics are desired under contention for network resources.
PCEセッション全体でイベントの順序を制御できないために発生した予約イベントのランダム化は、LSPルーティングの予測可能性を低下させます。一貫した最適化方法を適用するオフラインシステムは、予測エラーの境界内（予約が妥当なマージンによって過剰にプロビジョニングされている場合）または信号と予測エラーの変動性（いくつかのヒステリシスを適用する場合）のいずれかに予測可能な結果を生成します。チャーンを最小化します）。予測可能な結果は、ネットワークをシミュレートし、さまざまなシナリオで、特にネットワークリソースの競合下で予測可能なパス特性が必要な場合に、さまざまな障害モードや計画的なメンテナンスでネットワークを確実にテストできるために役立ちます。
Reference Topology 1 and Tables 9, 10, and 11 show the impact of event ordering and predictability of LSP routing.
参照トポロジ1と表9、10、および11は、LSPルーティングのイベントの順序付けと予測可能性の影響を示しています。
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 1 | 10 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
Table 9: Link Parameters for the 'Predictability' Example
表9：「予測可能性」の例のリンクパラメーター
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 7 | Yes | A-C-E |
| 2 | 2 | B | E | 7 | Yes | B-C-D-E |
+------+-----+-----+-----+--------+----------+---------+
Table 10: 'Predictability' LSP and Demand Time Series 1
表10：「予測可能性」LSPおよび需要時系列1
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 2 | B | E | 7 | Yes | B-C-E |
| 2 | 1 | A | E | 7 | Yes | A-C-D-E |
+------+-----+-----+-----+--------+----------+---------+
Table 11: 'Predictability' LSP and Demand Time Series 2
表11：「予測可能性」LSPおよび需要時系列2
As can be shown in the example, both LSPs are routed in both cases, but along very different paths. This would be a challenge if reliable simulation of the network is attempted. An active stateful PCE can solve this through control over LSP ordering. Based on triggers such as a failure or an optimization trigger, the PCE can order the computations and path setup in a deterministic way.
例に示されているように、両方のLSPはどちらの場合もルーティングされますが、非常に異なるパスに沿っています。これは、ネットワークの信頼性の高いシミュレーションが試行される場合の課題です。アクティブなステートフルPCEは、LSPの順序を制御することでこれを解決できます。障害や最適化トリガーなどのトリガーに基づいて、PCEは計算とパス設定を決定論的な方法で順序付けることができます。
The bandwidth requirements of LSPs often change over time, requiring LSP resizing. In most implementations available today, the head-end node performs this function by monitoring the actual bandwidth usage, triggering a recomputation and resignaling when a threshold is reached. This operation is referred to as "auto-bandwidth adjustment". The head-end node either recomputes the path locally, or it requests a recomputation from a PCE by sending a PCReq message. In the latter case, the PCE computes a new path and provides the new route suggestion. Upon receiving the reply from the PCE, the PCC resignals the LSP in Shared-Explicit (SE) mode along the newly computed path. With a stateless PCE, the head-end node needs to provide the currently used bandwidth and the route information via path computation request messages. Note that in this scenario, the head-end node is the one that drives the LSP resizing based on local information, and that the difference between using a stateless and a passive stateful PCE is in the level of optimization of the LSP placement as discussed in the previous section.
LSPの帯域幅要件は、時間とともに変化することが多く、LSPのサイズ変更が必要です。今日利用できるほとんどの実装では、ヘッドエンドノードは実際の帯域幅の使用状況を監視し、しきい値に達したときに再計算と再シグナリングをトリガーすることによってこの機能を実行します。この操作を「自動帯域調整」といいます。ヘッドエンドノードは、パスをローカルで再計算するか、PCReqメッセージを送信してPCEに再計算を要求します。後者の場合、PCEは新しいパスを計算し、新しいルート候補を提供します。 PCEからの応答を受信すると、PCCは新しく計算されたパスに沿ってShared-Explicit（SE）モードでLSPに再シグナリングします。ステートレスPCEを使用する場合、ヘッドエンドノードは、パス計算要求メッセージを介して、現在使用されている帯域幅とルート情報を提供する必要があります。このシナリオでは、ヘッドエンドノードはローカル情報に基づいてLSPのサイズ変更を実行するノードであり、ステートレスPCEとパッシブステートフルPCEの使用の違いは、LSP配置の最適化レベルにあります。前のセクション。
A more interesting smart bandwidth adjustment case is one where the LSP resizing decision is done by an external entity with access to additional information such as historical trending data, application- specific information about expected demands or policy information, as well as knowledge of the actual desired flow volumes. In this case, an active stateful PCE provides an advantage in both the computation with knowledge of all LSPs in the domain and in the ability to trigger bandwidth modification of the LSP.
より興味深いスマート帯域幅調整のケースは、LSPのサイズ変更の決定が、履歴トレンドデータ、予想される需要に関するアプリケーション固有の情報、またはポリシー情報、および実際に必要な知識などの追加情報にアクセスできる外部エンティティによって行われるケースです。流量。この場合、アクティブなステートフルPCEは、ドメイン内のすべてのLSPの知識を持つ計算と、LSPの帯域幅変更をトリガーする機能の両方で利点を提供します。
Bandwidth scheduling allows network operators to reserve resources in advance according to the agreements with their customers and allows them to transmit data with a specified starting time and duration, for example, for a scheduled bulk data replication between data centers.
帯域幅スケジューリングにより、ネットワークオペレーターは顧客との合意に従ってリソースを事前に予約でき、データセンター間のスケジュールされたバルクデータレプリケーションなど、指定された開始時間と期間でデータを送信できます。
Traditionally, this can be supported by Network Management System (NMS) operation through path pre-establishment and activation on the agreed starting time. However, this does not provide efficient network usage since the established paths exclude the possibility of being used by other services even when they are not used for undertaking any service. It can also be accomplished through GMPLS protocol extensions by carrying the related request information (e.g., starting time and duration) across the network. Nevertheless, this method inevitably increases the complexity of the signaling and routing process.
従来、これは、パスの事前確立および合意された開始時刻のアクティブ化を通じて、ネットワーク管理システム（NMS）の操作でサポートできます。ただし、確立されたパスは、サービスを提供するために使用されていない場合でも、確立されたパスが他のサービスによって使用される可能性を排除するため、これは効率的なネットワーク使用を提供しません。また、関連する要求情報（たとえば、開始時間と継続時間）をネットワーク全体に伝達することにより、GMPLSプロトコル拡張を介して実現することもできます。それにもかかわらず、この方法は必然的にシグナリングおよびルーティングプロセスの複雑さを増加させます。
A passive stateful PCE can support this application with better efficiency since it can alleviate the burden of processing on network elements. This requires the PCE to maintain the scheduled LSPs and their associated resource usage, as well as the ability of head-ends to trigger signaling for LSP setup/deletion at the correct time. This approach requires coarse time synchronization between PCEs and PCCs. With PCE initiation capability, a PCE can trigger the setup and deletion of scheduled requests in a centralized manner, without modification of existing head-end behaviors, by notifying the PCCs to set up or tear down the paths.
パッシブステートフルPCEは、ネットワーク要素の処理の負担を軽減できるため、このアプリケーションをより効率的にサポートできます。これには、PCEがスケジュールされたLSPとそれに関連するリソース使用量を維持すること、およびLSPセットアップ/削除のシグナリングを正しい時間にトリガーするヘッドエンドの機能が必要です。このアプローチでは、PCEとPCCの間の粗い時間同期が必要です。 PCE開始機能を使用すると、PCEは、パスをセットアップまたは破棄するようにPCCに通知することにより、既存のヘッドエンド動作を変更することなく、スケジュールされた要求のセットアップと削除を一元的にトリガーできます。
The recovery use cases discussed in the following sections show how leveraging a stateful PCE can simplify the computation of recovery path(s). In particular, two characteristics of a stateful PCE are used: 1) using information stored in the LSP-DB for determining shared protection resources and 2) performing computations with knowledge of all LSPs in a domain.
次のセクションで説明するリカバリのユースケースでは、ステートフルPCEを利用してリカバリパスの計算を簡略化する方法を示します。特に、ステートフルPCEの2つの特性が使用されます。1）LSP-DBに格納された情報を使用して共有保護リソースを決定すること、および2）ドメイン内のすべてのLSPを認識して計算を実行すること。
If a PCC can specify in a request whether the computation is for a working path or for protection and a PCC can report the resource as a working or protection path, then the following text applies. A PCC can send multiple requests to the PCE, asking for two LSPs, and use them as working and backup paths separately. Either way, the resources bound to backup paths can be shared by different LSPs to improve the overall network efficiency, such as m:n protection or pre-configured shared mesh recovery techniques as specified in [RFC4427]. If resource sharing is supported for LSP protection, the information relating to existing LSPs is required to avoid allocation of shared protection resources to two LSPs that might fail together and cause protection contention issues. A stateless PCE can accommodate this use case by having the PCC pass this information as a constraint in the path computation request. A passive stateful PCE can more easily accommodate this need using the information stored in its LSP-DB. Furthermore, an active stateful PCE can help with (re)optimization of protection resource sharing as well as LSP maintenance operation with less impact on protection resources.
PCCが要求で計算が現用パス用か保護用かを指定でき、PCCがリソースを現用パスまたは保護パスとして報告できる場合、次のテキストが適用されます。 PCCは、2つのLSPを要求してPCEに複数の要求を送信し、それらを別々に作業パスおよびバックアップパスとして使用できます。どちらの方法でも、バックアップパスにバインドされたリソースをさまざまなLSPで共有して、[RFC4427]で指定されているm：n保護や事前構成された共有メッシュ回復技術など、ネットワーク全体の効率を向上させることができます。 LSP保護でリソース共有がサポートされている場合、2つのLSPに共有保護リソースが割り当てられて、一緒に失敗して保護競合の問題が発生するのを防ぐために、既存のLSPに関する情報が必要です。ステートレスPCEは、PCCがパス計算要求の制約としてこの情報を渡すようにすることで、このユースケースに対応できます。パッシブステートフルPCEは、LSP-DBに格納されている情報を使用して、このニーズに簡単に対応できます。さらに、アクティブなステートフルPCEは、保護リソースへの影響が少ないLSPメンテナンス操作だけでなく、保護リソース共有の（再）最適化にも役立ちます。
+----+
|PCE |
+----+
+------+ +------+ +------+
| A +----------+ B +----------+ C |
+--+---+ +---+--+ +---+--+
| | |
| +---------+ |
| | |
| +--+---+ +------+ |
+-----+ E +----------+ D +-----+
+------+ +------+
Figure 3: Reference Topology 3
図3：参照トポロジ3
For example, in the network depicted in Figure 3, suppose there exists LSP1 with working path LSP1_working following A->E and with backup path LSP1_backup following A->B->E. A request arrives asking for a working and backup path pair to be computed for LSP2 from B to E. If the PCE decides LSP2_working follows B->A->E, then the backup path LSP2_backup should not share the same protection resource with LSP1 since LSP2 shares part of its resource (specifically A->E) with LSP1 (i.e., these two LSPs are in the same shared risk group). There is no such constraint if B->C->D->E is chosen for LSP2_working.
たとえば、図3に示されているネットワークで、A-> Eの後にワーキングパスLSP1_workingがあり、A-> B-> Eの後にバックアップパスLSP1_backupがあるLSP1が存在するとします。 BからEへのLSP2の計算とバックアップパスのペアを要求する要求が到着します。PCEがLSP2_workingがB-> A-> Eに従っていると判断した場合、バックアップパスLSP2_backupはLSP1と同じ保護リソースを共有しないでください。 LSP2はそのリソースの一部（特にA-> E）をLSP1と共有します（つまり、これら2つのLSPは同じ共有リスクグループにあります）。 LSP2_workingにB-> C-> D-> Eが選択されている場合、そのような制約はありません。
If a stateless PCE is used, the head node B needs to be aware of the existence of LSPs that share the route of LSP2_working and of the details of their protection resources. B must pass this information to the PCE as a constraint so as to request a path with diversity. Alternatively, a stateless PCE may be able to compute paths diversified by SRLG (Shared Risk Link Group) if TED is extended so that it includes the SRLG information that is protected by a given backup resource, but at the expense of a high complexity in routing. On the other hand, a stateful PCE can get the LSPs information by itself given the LSP identifier(s) and can then find SRLG-diversified protection paths for both LSPs. This is made possible by comparing the LSP resource usage exploiting the LSP-DB accessible by the stateful PCE.
ステートレスPCEを使用する場合、ヘッドノードBは、LSP2_workingのルートを共有するLSPの存在と、それらの保護リソースの詳細を認識する必要があります。 Bは、ダイバーシティのあるパスを要求するために、この情報を制約としてPCEに渡す必要があります。あるいは、TEDが拡張されて所定のバックアップリソースによって保護されているSRLG情報が含まれている場合、SRLG（共有リスクリンクグループ）によって多様化されたパスをステートレスPCEが計算できる可能性がありますが、ルーティングが非常に複雑になります。 。一方、ステートフルPCEは、LSP識別子を指定してLSP情報を取得し、両方のLSPのSRLG多様化保護パスを見つけることができます。これは、ステートフルPCEからアクセス可能なLSP-DBを利用するLSPリソースの使用状況を比較することで可能になります。
In case of a link failure, such as a fiber cut, multiple LSPs may fail at the same time. Thus, the source nodes of the affected LSPs will be informed of the failure by the nodes detecting the failure. These source nodes will send requests to a PCE for rerouting. In order to reuse the resource taken by an existing LSP, the source node can send a PCReq message that includes the Exclude Route Object (XRO) with Fail (F) bit set together with the Record Route Object (RRO) that contains the current route information, as specified in [RFC5521].
ファイバー切断などのリンク障害が発生した場合、複数のLSPが同時に障害を起こすことがあります。したがって、影響を受けるLSPのソースノードは、障害を検出したノードによって障害が通知されます。これらのソースノードは、再ルーティングのためにPCEに要求を送信します。既存のLSPが使用するリソースを再利用するために、ソースノードは、現在のルートを含むレコードルートオブジェクト（RRO）と一緒に失敗（F）ビットが設定された除外ルートオブジェクト（XRO）を含むPCReqメッセージを送信できます。 [RFC5521]で指定されている情報。
If a stateless PCE is used, it might respond to the rerouting requests separately if the requests arrive at different times. Thus, it might result in suboptimal resource usage. Even worse, it might unnecessarily block some of the rerouting requests due to insufficient resources for rerouting messages that arrive later. If a passive stateful PCE is used to fulfill this task, the procedure can be simplified. The PCCs reporting the failures can include LSP identifiers instead of detailed information, and the PCE can find relevant LSP information by inspecting the LSP-DB. Moreover, the PCE can recompute the affected LSPs concurrently while reusing part of the existing LSP's resources when it is informed of the failed link identifier provided by the first request. This is made possible because the passive stateful PCE can check what other LSPs are affected by the failed link and their route information by inspecting its LSP-DB. As a result, a better performance can be achieved, such as better resource usage or minimal probability of blocking upcoming new rerouting requests sent as a result of the link failure.
ステートレスPCEが使用されている場合、要求が異なる時間に到着すると、再ルーティング要求に個別に応答する可能性があります。したがって、リソースの使用が最適化されない可能性があります。さらに悪いことに、後で到着するメッセージを再ルーティングするためのリソースが不十分なため、再ルーティング要求の一部を不必要にブロックする可能性があります。このタスクを実行するためにパッシブステートフルPCEを使用すると、手順を簡略化できます。障害を報告するPCCには詳細情報の代わりにLSP識別子を含めることができ、PCEはLSP-DBを検査することで関連するLSP情報を見つけることができます。さらに、PCEは、最初の要求によって提供された失敗したリンク識別子が通知されたときに、既存のLSPのリソースの一部を再利用しながら、影響を受けるLSPを同時に再計算できます。これは、パッシブステートフルPCEが、LSP-DBを検査することにより、障害のあるリンクによって影響を受ける他のLSPとそのルート情報を確認できるために可能になります。その結果、リソースの使用率が向上したり、リンク障害の結果として送信される次の新しい再ルーティング要求をブロックする可能性が最小限になるなど、パフォーマンスが向上します。
If the target is to avoid resource contention within the time window of a high number of LSP rerouting requests, a stateful PCE can retain the under-construction LSP resource usage information for a given time and exclude it from being used for a forthcoming LSP's request.
多数のLSP再ルーティング要求の時間枠内でリソースの競合を回避することがターゲットである場合、ステートフルPCEは、建設中のLSPリソース使用状況情報を一定時間保持し、それを今後のLSP要求に使用されないようにすることができます。
In this way, it can ensure that the resource will not be double-booked; thus, the issue of resource contention and computation crank-backs can be alleviated.
このようにして、リソースが二重予約されないようにすることができます。したがって、リソースの競合と計算のクランクバックの問題を軽減できます。
An alternative way to achieve efficient resilience is to maintain SRLG disjointness between LSPs, irrespective of whether or not these LSPs share the source and destination nodes. This can be achieved at provisioning time, if the routes of all the LSPs are requested together, using a synchronized computation of the different LSPs with SRLG disjointness constraint. If the LSPs need to be provisioned at different times, the PCC can specify, as constraints to the path computation, a set of SRLGs using the Exclude Route Object [RFC5521]. However, for the latter to be effective, the entity that requests the route to the PCE needs to maintain updated SRLG information regarding all of the LSPs to which it must maintain the disjointness. A stateless PCE can compute an SRLG-disjoint path by inspecting the TED and precluding the links with the same SRLG values specified in the PCReq message sent by a PCC.
効率的な回復力を実現する別の方法は、LSPが送信元ノードと宛先ノードを共有しているかどうかに関係なく、LSP間のSRLGの素性を維持することです。これはプロビジョニング時に、すべてのLSPのルートが一緒に要求された場合、SRLGの互いに素な制約を持つさまざまなLSPの同期計算を使用して実現できます。 LSPを異なるタイミングでプロビジョニングする必要がある場合、PCCはパス計算の制約として、Exclude Route Object [RFC5521]を使用してSRLGのセットを指定できます。ただし、後者が効果的であるためには、PCEへのルートを要求するエンティティは、不整合を維持する必要があるすべてのLSPに関する更新されたSRLG情報を維持する必要があります。ステートレスPCEは、TEDを検査し、PCCによって送信されたPCReqメッセージで指定されたものと同じSRLG値を持つリンクを除外することにより、SRLGディスジョイントパスを計算できます。
A passive stateful PCE maintains the updated SRLG information of the established LSPs in a centralized manner. Therefore, the PCC can specify, as constraints to the path computation, the SRLG disjointness of a set of already established LSPs by only providing the LSP identifiers. Similarly, a passive stateful PCE can also accommodate disjointness using other constraints, such as link, node, or path segment.
パッシブステートフルPCEは、確立されたLSPの更新されたSRLG情報を集中管理します。したがって、PCCは、パス計算の制約として、LSP識別子を指定するだけで、すでに確立されている一連のLSPのSRLG素性を指定できます。同様に、パッシブステートフルPCEは、リンク、ノード、パスセグメントなどの他の制約を使用して、ばらばらさに対応することもできます。
In Multi-Layer Networks (MLN), a Virtual Network Topology (VNT) [RFC5212] consists of a set of one or more TE LSPs in the lower layer, which provides TE links to the upper layer. In [RFC5623], the PCE-based architecture is proposed to support path computation in MLN networks in order to achieve inter-layer TE.
多層ネットワーク（MLN）では、仮想ネットワークトポロジ（VNT）[RFC5212]は、下位層の1つ以上のTE LSPのセットで構成され、上位層へのTEリンクを提供します。 [RFC5623]では、層間TEを実現するために、MLNネットワークでパス計算をサポートするPCEベースのアーキテクチャが提案されています。
The establishment/teardown of a TE link in VNT needs to take into consideration the state of existing LSPs and/or new LSP request(s) in the higher layer. Hence, when a stateless PCE cannot find the route for a request based on the upper-layer topology information, it does not have enough information to decide whether or not to set up or remove a TE link, which then can result in non-optimal usage of a resource. On the other hand, a passive stateful PCE can make a better decision of when and how to modify the VNT either to accommodate new LSP requests or to reoptimize resource usage across layers irrespective of the PCE models as described in [RFC5623]. Furthermore, given the active capability, the stateful PCE can issue VNT modification suggestions in order to accommodate path setup requests or reoptimize resource usage across layers.
VNTでのTEリンクの確立/ティアダウンでは、上位層の既存のLSPや新しいLSP要求の状態を考慮する必要があります。したがって、ステートレスPCEが上位層トポロジー情報に基づいて要求のルートを見つけることができない場合、TEリンクを設定または削除するかどうかを決定するための十分な情報がないため、最適でない結果になる可能性があります。リソースの使用。一方、パッシブステートフルPCEは、[RFC5623]で説明されているように、PCEモデルに関係なく、新しいLSP要求に対応するか、レイヤー全体のリソース使用量を再最適化するために、VNTをいつどのように変更するかをより適切に決定できます。さらに、アクティブな機能がある場合、ステートフルPCEはVNT変更提案を発行して、パスのセットアップ要求に対応したり、レイヤー間でリソースの使用を再最適化したりできます。
In order to make efficient usage of network resources, it is sometimes desirable to reoptimize one or more LSPs dynamically. In the case of a stateless PCE, in order to optimize network resource usage dynamically through online planning, a PCC must send a request to the PCE together with detailed path/bandwidth information of the LSPs that need to be concurrently optimized. This means that the PCC must be able to determine when and which LSPs should be optimized. In the case of a passive stateful PCE, given the LSP state information in the LSP database, the process of dynamic optimization of network resources can be simplified without requiring the PCC to supply detailed LSP state information. Moreover, an active stateful PCE can even make the process automated by triggering the request. Because a stateful PCE can maintain information for all LSPs that are in the process of being set up and it may have the ability to control timing and sequence of LSP setup/deletion, the optimization procedures can be performed more intelligently and effectively. A stateful PCE can also determine which LSP should be reoptimized based on network events. For example, when an LSP is torn down, its resources are freed. This can trigger the stateful PCE to automatically determine which LSP should be reoptimized so that the recently freed resources may be allocated to it.
ネットワークリソースを効率的に使用するために、1つ以上のLSPを動的に再最適化することが望ましい場合があります。ステートレスPCEの場合、オンライン計画を通じてネットワークリソースの使用を動的に最適化するために、PCCは、同時に最適化する必要があるLSPの詳細なパス/帯域幅情報と共に、PCEに要求を送信する必要があります。つまり、PCCは、いつどのLSPを最適化する必要があるかを判断できる必要があります。パッシブステートフルPCEの場合、LSPデータベース内のLSP状態情報が与えられると、PCCが詳細なLSP状態情報を提供する必要なく、ネットワークリソースの動的最適化のプロセスを簡略化できます。さらに、アクティブなステートフルPCEは、要求をトリガーすることでプロセスを自動化することもできます。ステートフルPCEは、セットアップ中のすべてのLSPの情報を維持でき、LSPセットアップ/削除のタイミングとシーケンスを制御できるため、最適化手順をよりインテリジェントかつ効果的に実行できます。ステートフルPCEは、ネットワークイベントに基づいて再最適化する必要があるLSPを決定することもできます。たとえば、LSPが破棄されると、そのリソースが解放されます。これにより、ステートフルPCEがトリガーされ、最近解放されたリソースが割り当てられるように、再最適化する必要があるLSPが自動的に決定されます。
A special case of LSP reoptimization is GCO [RFC5557]. Global control of the LSP operation sequence in [RFC5557] is predicated on the use of what is effectively a stateful (or semi-stateful) NMS. The NMS can be either not local to the network nodes, in which case another northbound interface is required for LSP attribute changes, or local/collocated, in which case there are significant issues with efficiency in resource usage. A stateful PCE adds a few features that:
LSP再最適化の特殊なケースはGCO [RFC5557]です。 [RFC5557]のLSP操作シーケンスのグローバル制御は、実質的にステートフル（またはセミステートフル）NMSの使用に基づいています。 NMSは、ネットワークノードに対してローカルではない場合があります。この場合、LSP属性の変更に別のノースバウンドインターフェイスが必要です。または、ローカル/併置されている場合、リソースの使用効率に大きな問題があります。ステートフルPCEは、次のようないくつかの機能を追加します。
o Roll the NMS visibility into the PCE and remove the requirement for an additional northbound interface.
o NMSの可視性をPCEにロールし、追加のノースバウンドインターフェイスの要件を削除します。
o Allow the PCE to determine when reoptimization is needed, with which level (GCO or a more incremental optimization).
o PCEがいつ再最適化が必要かを、どのレベル（GCOまたはより段階的な最適化）で判断できるようにします。
o Allow the PCE to determine which LSPs should be reoptimized.
o PCEが再最適化する必要があるLSPを決定できるようにします。
o Allow a PCE to control the sequence of events across multiple PCCs, allowing for bulk (and truly global) optimization, LSP shuffling, etc.
o PCEが複数のPCC間でイベントのシーケンスを制御できるようにし、バルク（そして真にグローバルな）最適化、LSPシャッフルなどを可能にします。
If LSPs are dynamically allocated and released over time, the resource becomes fragmented. In networks with link bundle, the overall available resource on a (bundle) link might be sufficient for a new LSP request, but if the available resource is not continuous, the request is rejected. Stateful PCEs can be used to perform the defragmentation procedure, because global visibility of LSPs in the network is required to accurately assess resources on the LSPs and to perform defragmentation while ensuring a minimal disruption of the network. This use case cannot be accommodated by a stateless PCE because it does not possess the detailed information of existing LSPs in the network.
LSPが動的に割り当てられ、時間の経過とともに解放されると、リソースは断片化されます。リンクバンドルのあるネットワークでは、（バンドル）リンクで利用可能なリソース全体で新しいLSP要求を十分に処理できる可能性がありますが、利用可能なリソースが継続的でない場合、要求は拒否されます。 LSP上のリソースを正確に評価し、ネットワークの中断を最小限に抑えながらデフラグを実行するには、ネットワーク内のLSPのグローバルな可視性が必要であるため、ステートフルPCEを使用してデフラグ手順を実行できます。このユースケースは、ネットワーク内の既存のLSPの詳細情報を保持していないため、ステートレスPCEでは対応できません。
Another case of particular interest is the optical spectrum defragmentation in flexible-grid networks. In flexible-grid networks [RFC7698], LSPs with different optical spectrum sizes (such as 12.5GHz, 25GHz, etc.) can coexist so as to accommodate the services with different bandwidth requests. Therefore, even if the overall spectrum size can meet the service request, it may not be usable if the available spectrum resource is not contiguous, but rather fragmented into smaller pieces. Thus, with the help of existing LSP state information, a stateful PCE can make the resource grouped together to be usable. Moreover, a stateful PCE can proactively choose routes for upcoming path requests to reduce the chance of spectrum fragmentation.
特に興味深いもう1つのケースは、フレキシブルグリッドネットワークにおける光スペクトルの最適化です。フレキシブルグリッドネットワーク[RFC7698]では、異なる光スペクトルサイズ（12.5GHz、25GHzなど）のLSPを共存させて、異なる帯域幅要求のサービスに対応できます。したがって、全体的なスペクトルサイズがサービス要求を満たすことができたとしても、利用可能なスペクトルリソースが隣接しておらず、むしろ小さな断片に断片化されている場合は、使用できない場合があります。したがって、既存のLSP状態情報を利用して、ステートフルPCEはリソースをグループ化して使用可能にすることができます。さらに、ステートフルPCEは、今後のパス要求のルートをプロアクティブに選択して、スペクトルの断片化の可能性を減らすことができます。
PCE has been identified as an appropriate technology for the determination of the paths of Point-to-Multipoint (P2MP) TE LSPs [RFC5671]. The application scenarios and use cases described in Sections 3.1, 3.4, and 3.6 are also applicable to P2MP TE LSPs.
PCEは、ポイントツーマルチポイント（P2MP）TE LSP [RFC5671]のパスを決定するための適切なテクノロジーとして識別されています。セクション3.1、3.4、および3.6で説明されているアプリケーションシナリオと使用例は、P2MP TE LSPにも適用できます。
In addition to these, the stateful nature of a PCE simplifies the information conveyed in PCEP messages since it is possible to refer to the LSPs via an identifier. For P2MP, this is an added advantage where the size of the PCEP message is much larger. In case of stateless PCEs, modification of a P2MP tree requires encoding of all leaves along with the paths in a PCReq message. But by using a stateful PCE with P2MP capability, the PCEP message can be used to convey only the modifications (the other information can be retrieved from the identifier via the LSP-DB).
これらに加えて、PCEのステートフルな性質により、識別子を介してLSPを参照できるため、PCEPメッセージで伝達される情報が簡素化されます。 P2MPの場合、これはPCEPメッセージのサイズがはるかに大きい場合の追加の利点です。ステートレスPCEの場合、P2MPツリーの変更には、PCReqメッセージ内のパスとともにすべての葉をエンコードする必要があります。ただし、P2MP機能を備えたステートフルPCEを使用することで、PCEPメッセージを使用して変更のみを伝達できます（その他の情報は、LSP-DBを介して識別子から取得できます）。
In Wavelength Switched Optical Networks (WSONs) [RFC6163], a wavelength-switched LSP traverses one or more fiber links. The bit rates of the client signals carried by the wavelength LSPs may be the same or different. Hence, a fiber link may transmit a number of wavelength LSPs with equal or mixed bit-rate signals. For example, a fiber link may multiplex the wavelengths with only 10 Gbit/s signals, mixed 10 Gbit/s and 40 Gbit/s signals, or mixed 40 Gbit/s and 100 Gbit/s signals.
波長スイッチ光ネットワーク（WSON）[RFC6163]では、波長スイッチLSPは1つ以上のファイバーリンクを通過します。波長LSPによって伝送されるクライアント信号のビットレートは、同じでも異なっていてもかまいません。したがって、ファイバリンクは、ビットレート信号が等しいまたは混合された多数の波長LSPを送信できます。たとえば、ファイバリンクは、10 Gbit / s信号のみ、10 Gbit / sと40 Gbit / s信号の混合、または40 Gbit / s信号と100 Gbit / s信号の混合で波長を多重化できます。
IA-RWA in WSONs refers to the process (i.e., lightpath computation) that takes into account the optical layer/transmission imperfections as additional (i.e., physical layer) constraints. To be more specific, linear and non-linear effects associated with the optical network elements should be incorporated into the route and wavelength assignment procedure. For example, the physical imperfection can result in the interference of two adjacent lightpaths. Thus, a guard band should be reserved between them to alleviate these effects. The width of the guard band between two adjacent wavelengths depends on their characteristics, such as modulation formats and bit rates. Two adjacent wavelengths with different characteristics (e.g., different bit rates) may need a wider guard band and those with the same characteristics may need a narrower guard band. For example, 50 GHz spacing may be acceptable for two adjacent wavelengths with 40 G signals. But for two adjacent wavelengths with different bit rates (e.g., 10 G and 40 G), a larger spacing such as 300 GHz may be needed. Hence, the characteristics (states) of the existing wavelength LSPs should be considered for a new RWA request in WSON.
WSONのIA-RWAは、追加の（つまり、物理層）制約として光学層/伝送の欠陥を考慮したプロセス（つまり、光路計算）を指します。より具体的には、光ネットワーク要素に関連する線形効果と非線形効果をルートと波長の割り当て手順に組み込む必要があります。たとえば、物理的な欠陥により、2つの隣接する光路が干渉する可能性があります。したがって、これらの影響を緩和するために、ガードバンドを予約しておく必要があります。 2つの隣接する波長間のガードバンドの幅は、変調形式やビットレートなどの特性に依存します。異なる特性（たとえば、異なるビットレート）を持つ2つの隣接する波長には広いガードバンドが必要で、同じ特性を持つ波長には狭いガードバンドが必要な場合があります。たとえば、50 GHz間隔は、40 G信号の2つの隣接する波長に対して許容可能です。しかし、ビットレートが異なる2つの隣接する波長（10 Gと40 Gなど）の場合、300 GHzなどのより大きな間隔が必要になることがあります。したがって、WSONの新しいRWA要求では、既存の波長LSPの特性（状態）を考慮する必要があります。
In summary, when stateful PCEs are used to perform the IA-RWA procedure, they need to know the characteristics of the existing wavelength LSPs. The impairment information relating to existing and to-be-established LSPs can be obtained by nodes in WSON networks via external configuration or other means such as monitoring or estimation based on a vendor-specific impair model. However, WSON-related routing protocols, i.e., [RFC7688] and [RFC7580], only advertise limited information (i.e., availability) of the existing wavelengths, without defining the supported client bit rates. It will incur a substantial amount of control-plane overhead if routing protocols are extended to support dissemination of the new information relevant for the IA-RWA process. In this scenario, stateful PCE(s) would be a more appropriate mechanism to solve this problem. Stateful PCE(s) can exploit impairment information of LSPs stored in LSP-DB to provide accurate RWA calculation.
要約すると、IA-RWA手順を実行するためにステートフルPCEが使用される場合、それらは既存の波長LSPの特性を知る必要があります。既存および確立予定のLSPに関連する障害情報は、外部構成を介して、またはベンダー固有の障害モデルに基づく監視や推定などの他の手段を介してWSONネットワークのノードによって取得できます。ただし、WSON関連のルーティングプロトコル、つまり[RFC7688]と[RFC7580]は、サポートされているクライアントのビットレートを定義せずに、既存の波長の限られた情報（つまり、可用性）のみをアドバタイズします。ルーティングプロトコルがIA-RWAプロセスに関連する新しい情報の配布をサポートするように拡張されている場合、かなりの量のコントロールプレーンオーバーヘッドが発生します。このシナリオでは、ステートフルPCEがこの問題を解決するためのより適切なメカニズムになります。ステートフルPCEは、LSP-DBに保存されているLSPの障害情報を利用して、正確なRWA計算を提供できます。
This section discusses general issues with stateful PCE deployments and identifies areas where additional protocol extensions and procedures are needed to address them. Definitions of protocol mechanisms are beyond the scope of this document.
このセクションでは、ステートフルPCE展開の一般的な問題について説明し、それらに対処するために追加のプロトコル拡張と手順が必要な領域を識別します。プロトコルメカニズムの定義は、このドキュメントの範囲外です。
Stateless and stateful PCEs can coexist in the same network and be in charge of path computation of different types. To solve the problem of distinguishing between the two types of PCEs, either discovery or configuration may be used.
ステートレスおよびステートフルPCEは、同じネットワーク内で共存でき、異なるタイプのパス計算を担当できます。 2つのタイプのPCEを区別する問題を解決するには、ディスカバリーまたは構成のいずれかを使用できます。
Multiple stateful PCEs can coexist in the same network. These PCEs may provide redundancy for load sharing, resilience, or partitioning of computation features. Regardless of the reason for multiple PCEs, an LSP is only delegated to one of the PCEs at any given point in time. However, an LSP can be redelegated between PCEs, for example, when a PCE fails. [RFC7399] discusses various approaches for synchronizing state among the PCEs when multiple PCEs are used for load sharing or backup and compute LSPs for the same network.
複数のステートフルPCEが同じネットワークに共存できます。これらのPCEは、負荷分散、回復力、または計算機能の分割に冗長性を提供します。複数のPCEの理由に関係なく、LSPは任意の時点でPCEの1つにのみ委任されます。ただし、PCEが失敗した場合など、LSEはPCE間で再委任できます。 [RFC7399]は、複数のPCEが負荷分散またはバックアップに使用され、同じネットワークのLSPを計算する場合に、PCE間で状態を同期するためのさまざまなアプローチについて説明します。
The LSP-DB is populated using information received from the PCC. Because the accuracy of the computations depends on the accuracy of the databases used and because the updates must reach the PCE from the network, it is worth noting that the PCE view lags behind the true state of the network. Thus, the use of stateful PCE reduces but cannot eliminate the possibility of crankbacks, nor can it guarantee optimal computations all the time. [RFC7399] discusses these limitations and potential ways to alleviate them.
LSP-DBは、PCCから受信した情報を使用して入力されます。計算の精度は、使用するデータベースの精度に依存し、更新はネットワークからPCEに到達する必要があるため、PCEビューはネットワークの実際の状態より遅れていることに注意してください。したがって、ステートフルPCEを使用すると、クランクバックの可能性が減りますが、排除することはできず、常に最適な計算を保証することもできません。 [RFC7399]は、これらの制限とそれらを緩和するための潜在的な方法について説明します。
In case of multiple PCEs with different capabilities coexisting in the same network, such as a passive stateful PCE and an active stateful PCE, it is useful to refer to an LSP, be it delegated or not, by a unique identifier instead of providing detailed information (e.g., route, bandwidth) associated with it, when these PCEs cooperate on path computation, such as for load sharing.
パッシブステートフルPCEとアクティブステートフルPCEなど、同じネットワークに異なる機能が共存する複数のPCEの場合、詳細情報を提供する代わりに、一意の識別子によって、委任されているかどうかに関係なく、LSPを参照すると便利です。これらに関連付けられている（ルート、帯域幅など）。これらのPCEがロードシェアリングなどのパス計算に協力する場合。
For a stateful PCE, an important issue is to get the LSP state information resynchronized after a restart. LSP state synchronization procedures can be applied equally to a network node or another PCE, allowing multiple ways to reacquire the LSP database on a restart. Because synchronization may also be skipped, if a PCE implementation has the means to retrieve its database in a different way (for example, from a backup copy stored locally), the state can be restored without further overhead in the network. A hybrid approach where the bulk of the state is recovered locally, and a small amount of state is reacquired from the network, is also possible. Note that locally recovering the state would still require some degree of resynchronization to ensure that the recovered state is indeed up-to-date. Depending on the resynchronization mechanism used, there may be an additional load on the PCE, and there may be a delay in reaching the synchronized state, which may negatively affect survivability. Different resynchronization methods are suited for different deployments and objectives.
ステートフルPCEの場合、重要な問題は、再起動後にLSP状態情報を再同期することです。 LSP状態同期手順は、ネットワークノードまたは別のPCEに等しく適用でき、再起動時にLSPデータベースを再取得する複数の方法を可能にします。同期もスキップされる可能性があるため、PCE実装にデータベースを別の方法で（たとえば、ローカルに保存されたバックアップコピーから）取得する手段がある場合、ネットワークでオーバーヘッドを追加することなく状態を復元できます。状態の大部分がローカルで回復され、ネットワークから少量の状態が再取得されるハイブリッドアプローチも可能です。ローカルで状態を回復する場合でも、回復された状態が実際に最新であることを確認するには、ある程度の再同期が必要です。使用する再同期メカニズムによっては、PCEに追加の負荷がかかる可能性があり、同期状態に到達するまでに遅延が生じる可能性があり、生存性に悪影響を及ぼす可能性があります。さまざまな再同期方法が、さまざまな展開と目的に適しています。
This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations through a number of use cases. No new protocol extensions to PCEP are defined in this document.
このドキュメントでは、ステートフルPCEの展開に関する一般的な考慮事項について説明し、その適用性と利点、および多数の使用例を通しての課題と制限を調べます。このドキュメントでは、PCEPの新しいプロトコル拡張は定義されていません。
The PCEP extensions in support of the stateful PCE and the delegation of path control ability can result in more information and control being available for a hypothetical adversary and a number of additional attack surfaces that must be protected. This includes, but is not limited to, the authentication and encryption of PCEP sessions, snooping of the state of the LSPs active in the network, etc. Therefore, documents in which the PCEP protocol extensions are defined need to consider the issues and risks associated with a stateful PCE.
ステートフルPCEとパス制御機能の委任をサポートするPCEP拡張機能により、仮想の敵対者と、保護する必要のある多くの追加の攻撃対象に対してより多くの情報と制御を利用できるようになります。これには、PCEPセッションの認証と暗号化、ネットワークでアクティブなLSPの状態のスヌーピングなどが含まれますが、これらに限定されません。したがって、PCEPプロトコル拡張が定義されているドキュメントでは、関連する問題とリスクを考慮する必要があります。ステートフルPCEを使用します。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<http：//www.rfc -editor.org/info/rfc4655>。
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>.
[RFC5440] Vasseur、JP。、Ed。とJL。 Le Roux、編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<http://www.rfc-editor.org/info/rfc5440>。
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path Computation Element Architecture", RFC 7399, DOI 10.17487/RFC7399, October 2014, <http://www.rfc-editor.org/info/rfc7399>.
[RFC7399] Farrel、A。およびD. King、「Path Computation Element Architectureにおける未回答の質問」、RFC 7399、DOI 10.17487 / RFC7399、2014年10月、<http://www.rfc-editor.org/info/rfc7399 >。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<http://www.rfc-editor.org/info/rfc3209>。
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, DOI 10.17487/RFC4427, March 2006, <http://www.rfc-editor.org/info/rfc4427>.
[RFC4427]マニー、E、エド。およびD. Papadimitriou、Ed。、「Recovery（Protection and Restoration）Terminology for Generalized Multi-Protocol Label Switching（GMPLS）」、RFC 4427、DOI 10.17487 / RFC4427、2006年3月、<http：//www.rfc-editor。 org / info / rfc4427>。
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, DOI 10.17487/RFC5212, July 2008, <http://www.rfc-editor.org/info/rfc5212>.
[RFC5212]塩本K.、パパディミトリウ、D。、ルルー、JL。、ヴィグールー、M。、およびD.ブルガード、「GMPLSベースのマルチリージョンおよびマルチレイヤーネットワーク（MRN / MLN）の要件」、 RFC 5212、DOI 10.17487 / RFC5212、2008年7月、<http://www.rfc-editor.org/info/rfc5212>。
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April 2009, <http://www.rfc-editor.org/info/rfc5521>.
[RFC5521] Oki、E.、Takeda、T。、およびA. Farrel、「Extensions to the Path Computation Element Communication Protocol（PCEP）for Route Exclusions」、RFC 5521、DOI 10.17487 / RFC5521、2009年4月、<http：/ /www.rfc-editor.org/info/rfc5521>。
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557, July 2009, <http://www.rfc-editor.org/info/rfc5557>.
[RFC5557] Lee、Y.、Le Roux、JL。、King、D。、およびE. Oki、「Path Computation Element Communication Protocol（PCEP）Requirements and Protocol Extensions Supporting for Global Concurrent Optimization」、RFC 5557、DOI 10.17487 / RFC5557、2009年7月、<http://www.rfc-editor.org/info/rfc5557>。
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, September 2009, <http://www.rfc-editor.org/info/rfc5623>.
[RFC5623]沖E.、武田T.、ルルーJL、およびA.ファレル、「PCEベースの層間MPLSおよびGMPLSトラフィックエンジニアリングのフレームワーク」、RFC 5623、DOI 10.17487 / RFC5623、2009年9月、<http://www.rfc-editor.org/info/rfc5623>。
[RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, DOI 10.17487/RFC5671, October 2009, <http://www.rfc-editor.org/info/rfc5671>.
[RFC5671]安川S.およびA.ファレル編、「ポイントツーマルチポイント（P2MP）MPLSおよびGMPLSトラフィックエンジニアリング（TE）へのパス計算要素（PCE）の適用性」、RFC 5671、DOI 10.17487 / RFC5671、2009年10月、<http://www.rfc-editor.org/info/rfc5671>。
[RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, "Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)", RFC 6163, DOI 10.17487/RFC6163, April 2011, <http://www.rfc-editor.org/info/rfc6163>.
[RFC6163] Lee、Y.、Ed。、Bernstein、G.、Ed。、およびW. Imajuku、「GMPLSおよびPath Computation Element（PCE）Control for Wavelength Switched Optical Networks（WSONs）」、RFC 6163、DOI 10.17487 / RFC6163、2011年4月、<http://www.rfc-editor.org/info/rfc6163>。
[RFC7580] Zhang, F., Lee, Y., Han, J., Bernstein, G., and Y. Xu, "OSPF-TE Extensions for General Network Element Constraints", RFC 7580, DOI 10.17487/RFC7580, June 2015, <http://www.rfc-editor.org/info/rfc7580>.
[RFC7580] Zhang、F.、Lee、Y.、Han、J.、Bernstein、G。、およびY. Xu、「OSPF-TE Extensions for General Network Element Constraints」、RFC 7580、DOI 10.17487 / RFC7580、June 2015 、<http://www.rfc-editor.org/info/rfc7580>。
[RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks", RFC 7688, DOI 10.17487/RFC7688, November 2015, <http://www.rfc-editor.org/info/rfc7688>.
[RFC7688]リー、Y、エド。およびG.バーンスタイン編、「波長切り替え光ネットワークの信号およびネットワーク要素互換性のためのGMPLS OSPF拡張機能」、RFC 7688、DOI 10.17487 / RFC7688、2015年11月、<http://www.rfc-editor.org/info / rfc7688>。
[RFC7698] Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F., Fu, X., Ceccarelli, D., and I. Hussain, "Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks", RFC 7698, DOI 10.17487/RFC7698, November 2015, <http://www.rfc-editor.org/info/rfc7698>.
[RFC7698] Gonzalez de Dios、O。、編、Casellas、R。、編、Zhang、F.、Fu、X.、Ceccarelli、D。、およびI. Hussain、「GMPLSベースの制御のフレームワークと要件of Flexi-Grid Dense Wavelength Division Multiplexing（DWDM）Networks」、RFC 7698、DOI 10.17487 / RFC7698、2015年11月、<http://www.rfc-editor.org/info/rfc7698>。
Acknowledgements
謝辞
We would like to thank Cyril Margaria, Adrian Farrel, JP Vasseur, and Ravi Torvi for the useful comments and discussions.
有益なコメントと議論をしてくれたCyril Margaria、Adrian Farrel、JP Vasseur、Ravi Torviに感謝します。
Contributors
貢献者
The following people all contributed significantly to this document and are listed below in alphabetical order:
以下の人々はすべてこの文書に大きく貢献し、以下にアルファベット順にリストされています。
Ramon Casellas CTTC - Centre Tecnologic de Telecomunicacions de Catalunya Av. Carl Friedrich Gauss n7 Castelldefels, Barcelona 08860 Spain Email: ramon.casellas@cttc.es
Ramon Casellas CTTC-カタロニアの通信技術センターカールフリードリヒガウスn7カステルデフェルス、バルセロナ08860スペインメール：ramon.casellas@cttc.es
Edward Crabbe Email: edward.crabbe@gmail.com
Edward Crabbeメール：edward.crabbe@gmail.com
Dhruv Dhody Huawei Technology Leela Palace Bangalore, Karnataka 560008 India Email: dhruv.dhody@huawei.com Oscar Gonzalez de Dios Telefonica Investigacion y Desarrollo Emilio Vargas 6 Madrid, 28045 Spain Phone: +34 913374013 Email: ogondio@tid.es
Dhruv Dhody Huawei Technology Leela Palace Bangalore、Karnataka 560008 Indiaメール：dhruv.dhody@huawei.com Oscar Gonzalez de Dios Telefonica Research and Development Emilio Vargas 6 Madrid、28045 Spain電話：+34 913374013メール：ogondio@tid.es
Young Lee Huawei 1700 Alma Drive, Suite 100 Plano, TX 75075 United States of America Phone: +1 972 509 5599 x2240 Fax: +1 469 229 5397 Email: leeyoung@huawei.com
Young Lee Huawei 1700 Alma Drive、Suite 100 Plano、TX 75075 United States電話：+1 972 509 5599 x2240 Fax：+1 469 229 5397 Eメール：leeyoung@huawei.com
Jan Medved Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 United States of America Email: jmedved@cisco.com
Jan Medved Cisco Systems、Inc. 170 West Tasman Dr. San Jose、CA 95134アメリカ合衆国メール：jmedved@cisco.com
Robert Varga Pantheon Technologies LLC Mlynske Nivy 56 Bratislava 821 05 Slovakia Email: robert.varga@pantheon.sk
Robert Varga Pantheon Technologies LLC Mlynske Nivy 56ブラチスラバ821 05スロバキアメール：robert.varga@pantheon.sk
Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 China Phone: +86-755-28972912 Email: zhangfatai@huawei.com
Fatai Zhang Huawei Technologies F3-5-B R＆D Center、Huawei Base Bantian、Longgang District Shenzhen 518129 China電話：+ 86-755-28972912メール：zhangfatai@huawei.com
Xiaobing Zi
ξオーストリアの氷Z i
Authors' Addresses
著者のアドレス
Xian Zhang (editor) Huawei Technologies F3-5-B R&D Center Huawei Industrial Base Bantian, Longgang District Shenzhen, Guangdong 518129 China
X Ian Zhang（編集者）hu AはテクノロジーF3-5-br＆Dセンターhu Aは産業基地禁止日、Long Gang地区は非常に現実的、GU Case Gビルディング518129中国
Email: zhang.xian@huawei.com
Ina Minei (editor) Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
イナミネイ（編集者）Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043 United States of America
Email: inaminei@google.com