[要約] 要約：RFC 7709は、GMPLSラベルスイッチドパス（LSP）の非常に高速なセットアップに関する要件を定義しています。 目的：このRFCの目的は、ネットワークの効率性と柔軟性を向上させるために、GMPLS LSPのセットアップ時間を最小限に抑えることです。
Internet Engineering Task Force (IETF) A. Malis, Ed.
Request for Comments: 7709 Huawei Technologies
Category: Informational B. Wilson
ISSN: 2070-1721 Applied Communication Sciences
G. Clapp
AT&T Labs Research
V. Shukla
Verizon Communications
November 2015
Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs)
GMPLSラベルスイッチドパス（LSP）の非常に高速なセットアップの要件
Abstract
概要
Establishment and control of Label Switch Paths (LSPs) have become mainstream tools of commercial and government network providers. One of the elements of further evolving such networks is scaling their performance in terms of LSP bandwidth and traffic loads, LSP intensity (e.g., rate of LSP creation, deletion, and modification), LSP set up delay, quality-of-service differentiation, and different levels of resilience.
ラベルスイッチパス（LSP）の確立と制御は、商業および政府のネットワークプロバイダーの主流のツールになっています。このようなネットワークをさらに進化させる要素の1つは、LSP帯域幅とトラフィック負荷、LSP強度（LSPの作成、削除、変更の速度など）、LSPセットアップ遅延、サービス品質の差別化の観点からパフォーマンスをスケーリングすることです。さまざまなレベルの回復力。
The goal of this document is to present target scaling objectives and the related protocol requirements for Generalized Multi-Protocol Label Switching (GMPLS).
このドキュメントの目的は、一般化されたマルチプロトコルラベルスイッチング（GMPLS）のターゲットスケーリング目標と関連するプロトコル要件を提示することです。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション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/rfc7709.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7709で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Driving Applications and Their Requirements . . . . . . . . . 5
4.1. Key Application Requirements . . . . . . . . . . . . . . 5
5. Requirements for Very Fast Setup of GMPLS LSPs . . . . . . . 6
5.1. Protocol and Procedure Requirements . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
Generalized Multi-Protocol Label Switching (GMPLS) [RFC3471] [RFC3945] includes an architecture and a set of control-plane protocols that can be used to operate data networks ranging from packet-switch-capable networks, through those networks that use Time Division Multiplexing, to WDM networks. The Path Computation Element (PCE) architecture [RFC4655] defines functional components that can be used to compute and suggest appropriate paths in connection-oriented traffic-engineered networks. Additional wavelength switched optical networks (WSON) considerations were defined in [RFC6163].
Generalized Multi-Protocol Label Switching（GMPLS）[RFC3471] [RFC3945]には、パケットスイッチ対応ネットワークから、時分割を使用するネットワークに至るまで、データネットワークの運用に使用できるアーキテクチャと一連のコントロールプレーンプロトコルが含まれていますWDMネットワークへの多重化。 Path Computation Element（PCE）アーキテクチャ[RFC4655]は、接続指向のトラフィックエンジニアリングネットワークで適切なパスを計算および提案するために使用できる機能コンポーネントを定義します。追加の波長スイッチ光ネットワーク（WSON）の考慮事項は、[RFC6163]で定義されています。
This document refers to the same general framework and technologies, but it adds requirements related to expediting LSP setup under heavy connection churn scenarios, while achieving low blocking under an overall distributed control plane. This document focuses on a specific problem space -- high-capacity and highly dynamic connection request scenarios -- that may require clarification and or extensions to current GMPLS protocols and procedures. In particular, the purpose of this document is to address the potential need for protocols and procedures that enable expediting the setup of LSPs in high-churn scenarios. Both single-domain and multi-domain network scenarios are considered.
このドキュメントは同じ一般的なフレームワークとテクノロジーに言及していますが、全体的な分散型コントロールプレーンの下で低いブロッキングを実現しながら、重い接続チャーンシナリオでのLSPセットアップの迅速化に関連する要件を追加します。このドキュメントでは、特定の問題領域（大容量で非常に動的な接続要求シナリオ）に焦点を当てています。これらのシナリオでは、現在のGMPLSプロトコルと手順の説明や拡張が必要になる場合があります。特に、このドキュメントの目的は、チャーンの多いシナリオでLSPのセットアップを迅速化できるようにするプロトコルと手順の潜在的なニーズに対処することです。単一ドメインとマルチドメインの両方のネットワークシナリオが考慮されます。
This document focuses on the following two topics: 1) the driving applications and main characteristics and requirements of this problem space, and 2) the key requirements that may be novel with respect to current GMPLS protocols.
このドキュメントでは、次の2つのトピックに焦点を当てています。1）駆動アプリケーションとこの問題空間の主な特性と要件、および2）現在のGMPLSプロトコルに関して新規である可能性がある主要な要件。
This document presents the objectives and related requirements for GMPLS to provide the control for networks operating with such performance requirements. While specific deployment scenarios are considered part of the presentation of objectives, the stated requirements are aimed at ensuring the control protocols are not the limiting factor in achieving a particular network's performance. Implementation dependencies are out of scope of this document.
このドキュメントでは、GMPLSの目的と関連要件を示し、そのようなパフォーマンス要件で動作するネットワークを制御できるようにします。特定の展開シナリオは目的の提示の一部と見なされますが、記載されている要件は、制御プロトコルが特定のネットワークのパフォーマンスを達成する際の制限要因ではないことを確認することを目的としています。実装の依存関係はこのドキュメントの範囲外です。
Other documents may be needed to define how GMPLS protocols meet the requirements laid out in this document. Such future documents may define extensions or simply clarify how existing mechanisms may be used to address the key requirements of highly dynamic networks.
GMPLSプロトコルがこのドキュメントで説明されている要件を満たす方法を定義するには、他のドキュメントが必要になる場合があります。このような将来の文書では、拡張機能を定義するか、既存のメカニズムを使用して非常に動的なネットワークの主要な要件に対処する方法を単純に明確にする可能性があります。
The Defense Advanced Research Projects Agency (DARPA) Core Optical Networks (CORONET) program [Chiu] is an example target environment that includes IP and optical commercial and government networks, with a focus on highly dynamic and resilient multi-terabit core networks.
米国国防総省高等研究計画局（DARPA）コア光ネットワーク（CORONET）プログラム[Chiu]は、非常に動的で復元力のあるマルチテラビットコアネットワークに重点を置いた、IPおよび光商用および政府ネットワークを含むターゲット環境の例です。
It anticipates the need for rapid (sub-second) setup and SONET/SDH-like restoration times for high-churn (up to tens of requests per second network wide and holding times as short as one second) on-demand wavelength, sub-wavelength, and packet services for a variety of applications (e.g., grid computing, cloud computing, data visualization, fast data transfer, etc.). This must be done while meeting stringent call-blocking requirements and while minimizing the use of resources such as time slots, switch ports, wavelength conversion, etc.
高チャーン（ネットワーク全体で1秒あたり最大数十のリクエスト、1秒という短い保持時間）のオンデマンド波長での高速（サブ秒）セットアップとSONET / SDHのような復元時間の必要性を予測しています。さまざまなアプリケーション（たとえば、グリッドコンピューティング、クラウドコンピューティング、データ視覚化、高速データ転送など）の波長、およびパケットサービス。これは、厳しいコールブロッキング要件を満たし、タイムスロット、スイッチポート、波長変換などのリソースの使用を最小限に抑えながら行う必要があります。
The motivation for this document, and envisioned related future documents, is two-fold:
このドキュメント、および想定される関連する将来のドキュメントの動機は2つあります。
1. The anticipated need for rapid setup, while maintaining low blocking, of large bandwidth and highly churned on-demand connections (in the form of sub-wavelengths, e.g., OTN ODUx, and wavelengths, e.g., OTN OCh) for a variety of applications including grid computing, cloud computing, data visualization, and intra- and inter-datacenter communications.
1. 以下を含むさまざまなアプリケーションのための低帯域幅を維持しながら、広い帯域幅と高度にチャーンされたオンデマンド接続（OTN ODUxなどのサブ波長、およびOTN OChなどの波長の形式）の迅速なセットアップに対する予想されるニーズグリッドコンピューティング、クラウドコンピューティング、データの視覚化、データセンター内およびデータセンター間の通信。
2. The ability to set up circuit-like LSPs for large bandwidth flows with low setup delays provides an alternative to packet-based solutions implemented over static circuits that may require tying up more expensive and power-consuming resources (e.g., router ports). Reducing the LSP setup delay will reduce the minimum bandwidth threshold at which a GMPLS circuit approach is preferred over a layer 3 (e.g., IP) approach. Dynamic circuit and virtual circuit switching intrinsically provide guaranteed bandwidth, guaranteed low-latency and jitter, and faster restoration, all of which are very hard to provide in packet-only networks. Again, a key element in achieving these benefits is enabling the fastest possible circuit setup times.
2. セットアップ遅延の少ない大きな帯域幅フローに対して回線のようなLSPをセットアップする機能は、より高価で電力を消費するリソース（ルーターポートなど）の拘束を必要とする可能性がある静的回線上に実装されるパケットベースのソリューションに代わるものを提供します。 LSPセットアップ遅延を減らすと、GMPLS回路アプローチがレイヤー3（IPなど）アプローチよりも優先される最小帯域幅しきい値が減少します。ダイナミックサーキットと仮想サーキットスイッチングは、本質的に帯域幅の保証、低レイテンシとジッターの保証、高速な復元を提供します。これらはすべて、パケットのみのネットワークでは非常に困難です。繰り返しますが、これらの利点を達成するための重要な要素は、可能な限り最速の回路セットアップ時間を可能にすることです。
Future applications are expected to require setup times that are as fast as 100 ms in highly dynamic, national-scale network environments while meeting stringent blocking requirements and minimizing the use of resources such as switch ports, wavelength converters/ regenerators, and other network design parameters. Of course, the benefits of low setup delay diminish for connections with long holding times. For some specific applications, a trade-off may be required, as the need for rapid setup may be more important than their requirements for other features currently provided in GMPLS (e.g., robustness against setup errors).
将来のアプリケーションでは、厳しいダイナミックブロッキング要件を満たし、スイッチポート、波長コンバーター/リジェネレーター、その他のネットワーク設計パラメーターなどのリソースの使用を最小限に抑えながら、非常に動的な全国規模のネットワーク環境で100ミリ秒の高速セットアップ時間が必要になると予想されます。 。もちろん、セットアップの遅延が少ないことの利点は、保持時間が長い接続では減少します。一部の特定のアプリケーションでは、GMPLSで現在提供されている他の機能の要件（セットアップエラーに対する堅牢性など）よりも迅速なセットアップの必要性が重要になる場合があるため、トレードオフが必要になる場合があります。
With the advent of data centers, cloud computing, video, gaming, mobile and other broadband applications, it is anticipated that connection request rates may increase, even for connections with longer holding times, either during limited time periods (such as during the restoration from a data center failure) or over the longer term, to the point where the current GMPLS procedures of path computation/selection and resource allocation may not be timely, thus leading to increased blocking or increased resource cost. Thus, extensions of GMPLS signaling and routing protocols (e.g., OSPF-TE) may also be needed to address heavy churn of connection requests (i.e., high-connection-request arrival rate) in networks with high-traffic loads, even for connections with relatively longer holding times.
データセンター、クラウドコンピューティング、ビデオ、ゲーム、モバイル、その他のブロードバンドアプリケーションの登場により、限られた期間（たとえば、からの復元中）に保持時間が長くなる接続であっても、接続要求レートが増加することが予想されます。データセンターの障害）、または長期的には、パスの計算/選択とリソース割り当ての現在のGMPLS手順がタイムリーでなくなり、ブロッキングの増加またはリソースコストの増加につながる可能性があります。したがって、GMPLSシグナリングおよびルーティングプロトコル（OSPF-TEなど）の拡張は、高負荷のネットワークでの接続要求の大量のチャーン（つまり、接続要求の到着率が高い）に対処するためにも必要になる場合があります。比較的長い保持時間。
There are several emerging applications that fall under the problem space addressed here in several service areas such as provided by telecommunication carriers, government networks, enterprise networks, content providers, and cloud providers. Such applications include research and education networks / grid computing, and cloud computing. Detailing and standardizing protocols to address these applications will expedite the transition to commercial deployment.
通信事業者、政府ネットワーク、エンタープライズネットワーク、コンテンツプロバイダー、クラウドプロバイダーなどが提供するいくつかのサービス分野で、ここで取り上げる問題領域に該当するいくつかの新しいアプリケーションがあります。このようなアプリケーションには、研究および教育ネットワーク/グリッドコンピューティング、クラウドコンピューティングが含まれます。これらのアプリケーションに対処するためのプロトコルの詳細化と標準化は、商用展開への移行を促進します。
In the target environment, there are multiple Bandwidth-on-Demand service requests per second, such as might arise as cloud services proliferate. It includes dynamic services with connection setup requirements that range from seconds to milliseconds. The aggregate traffic demand, which is composed of both packet (IP) and circuit (wavelength and sub-wavelength) services, represents a five to twenty-fold increase over today's traffic levels for the largest of any individual carrier. Thus, the aggressive requirements must be met with solutions that are scalable, cost effective, and power efficient, while providing the desired quality of service (QoS).
ターゲット環境では、クラウドサービスの急増に伴い発生する可能性のある、1秒あたりの複数のBandwidth-on-Demandサービスリクエストがあります。これには、秒からミリ秒の範囲の接続設定要件を持つ動的サービスが含まれます。パケット（IP）と回線（波長とサブ波長）の両方のサービスで構成される総トラフィック需要は、個々のキャリアの中で最大の今日のトラフィックレベルの5〜20倍の増加を表しています。そのため、アグレッシブな要件は、スケーラブルでコスト効率が高く、電力効率の高いソリューションで満たすと同時に、望ましいサービス品質（QoS）を提供する必要があります。
There are two key performance-scaling requirements in the target environment that are the main drivers behind this document:
このドキュメントの背後にある主要なドライバーであるターゲット環境には、2つの主要なパフォーマンススケーリング要件があります。
1. Connection request rates ranging from a few requests per second for high-capacity (e.g., 40 Gb/s, 100 Gb/s) wavelength-based LSPs to around 100 requests per second for sub-wavelength LSPs (e.g., OTN ODU0, ODU1, and ODU2).
1. 大容量（40 Gb / s、100 Gb / sなど）の波長ベースのLSPの1秒あたりの数リクエストから、サブ波長LSP（OTN ODU0、ODU1など）の1秒あたり約100リクエストまでの接続リクエストレートおよびODU2）。
2. Connection setup delay of around 100 ms across a national or regional network. To meet this target, assuming pipelined cross-connection and worst-case propagation delay and hop count, it is estimated that the maximum processing delay per hop is around 700 microseconds [Lehmen]. Optimal path selection and resource allocation may require somewhat longer processing (up to 5 milliseconds) in either the destination or source nodes and possibly tighter processing delays (around 500 microseconds) in intermediate nodes.
2.全国または地域のネットワーク全体で約100 msの接続セットアップ遅延。この目標を達成するために、パイプライン化されたクロスコネクトとワーストケースの伝搬遅延およびホップ数を想定すると、ホップあたりの最大処理遅延は約700マイクロ秒と推定されます[Lehmen]。最適なパスの選択とリソースの割り当てには、宛先ノードまたは送信元ノードのどちらかでやや長い処理（最大5ミリ秒）が必要で、中間ノードでの処理遅延（約500マイクロ秒）が厳しくなる可能性があります。
The model for a national network is that of the continental US with up to 100 nodes and LSPs with distances up to ~3000 km and up to 15 hops.
全国ネットワークのモデルは、最大100ノードとLSPが最大で3,000 kmまで、最大ホップ数が15である米国大陸のモデルです。
A connection setup delay is defined here as the time between the arrival of a connection request at an ingress edge switch -- or more generally a Label Switch Router (LSR) -- and the time at which information can start flowing from that ingress switch over that connection. Note that this definition is more inclusive than the LSP setup time defined in [RFC5814] and [RFC6777], which do not include PCE path computation delays.
接続セットアップ遅延は、ここでは、入力エッジスイッチ（より一般的にはラベルスイッチルータ（LSR））に接続要求が到着してから、その入力スイッチから情報が流れ始める時間として定義されています。その接続。この定義は、[RFC5814]と[RFC6777]で定義されているLSPセットアップ時間よりも包括的であり、PCEパス計算遅延は含まれていません。
This section lists the protocol requirements for very fast setup of GMPLS LSPs in order to adequately support the service characteristics described in the previous sections. These requirements may be the basis for future documents, some of which may be simply informational, while others may describe specific GMPLS protocol extensions. While some of these requirements may have implications on implementations, the intent is for the requirements to apply to GMPLS protocols and their standardized mechanisms.
このセクションでは、前のセクションで説明したサービス特性を適切にサポートするために、GMPLS LSPを非常に高速にセットアップするためのプロトコル要件を示します。これらの要件は将来のドキュメントの基礎となる可能性があり、その中には単に情報を提供するものもあれば、特定のGMPLSプロトコル拡張について説明するものもあります。これらの要件の一部は実装に影響を与える可能性がありますが、GMPLSプロトコルとそれらの標準化されたメカニズムに適用される要件を意図しています。
R1 The portion of the LSP establishment time related to protocol processing should scale linearly based on the number of traversed nodes.
R1プロトコル処理に関連するLSP確立時間の部分は、通過するノードの数に基づいて線形にスケーリングする必要があります。
R2 End-to-end LSP data path availability should be bounded by the worst-case single-node data path establishment time. In other words, pipelined cross-connect processing as discussed in [RFC6383] should be enabled.
R2エンドツーエンドLSPデータパスの可用性は、最悪の場合の単一ノードデータパス確立時間によって制限されます。言い換えると、[RFC6383]で説明されているようなパイプライン化された相互接続処理を有効にする必要があります。
R3 LSP establishment time shall depend on the number of nodes supporting an LSP and link propagation delays and not on any off (control) path transactions, e.g., PCC-PCE and PCC-PCC communications at the time of connection setup, even when PCE-based approaches are used.
R3 LSP確立時間は、LSPをサポートするノードの数とリンク伝播遅延に依存し、オフの（制御）パストランザクションには依存しません。たとえば、PCE-PCE-が接続セットアップ時のPCC-PCEとPCC-PCC通信ベースのアプローチが使用されます。
R4 LSP holding times as short as one second must be supported.
1秒という短いR4 LSP保持時間をサポートする必要があります。
R5 The protocol aspects of LSP signaling must not preclude LSP request rates of tens per second.
R5 LSPシグナリングのプロトコルの側面は、毎秒数十のLSP要求レートを妨げてはなりません。
R6 The above requirements should be met even when there are failures in connection establishment, i.e., LSPs should be established faster than when crank-back is used.
R6上記の要件は、接続の確立に失敗がある場合でも満たされる必要があります。つまり、LSPは、クランクバックが使用される場合よりも早く確立される必要があります。
R7 These requirements are applicable even when an LSP crosses one or more administrative domains/boundaries.
R7これらの要件は、LSPが1つ以上の管理ドメイン/境界をまたぐ場合にも適用されます。
R8 The above are additional requirements and do not replace existing requirements, e.g., alarm-free setup and teardown, recovery, or inter-domain confidentiality.
R8上記は追加の要件であり、既存の要件（アラームのないセットアップと破棄、回復、ドメイン間の機密性など）を置き換えるものではありません。
Being able to support very fast setup and a high-churn rate of GMPLS LSPs is not expected to adversely affect the underlying security issues associated with existing GMPLS signaling. If encryption that requires key exchange is intended to be used on the signaled LSPs, then this requirement needs to be included as a part of the protocol design process, as the usual extra round-trip time (RTT) for key exchange will have an effect on the setup and churn rate of the GMPLS LSPs. It is possible to amortize the costs of key exchange over multiple exchanges (if those occur between the same peers) so that some exchanges need not cost a full RTT and operate in so-called zero-RTT mode.
非常に高速なセットアップと高いチャーン率のGMPLS LSPをサポートできることが、既存のGMPLSシグナリングに関連する根本的なセキュリティ問題に悪影響を与えるとは考えられていません。鍵交換を必要とする暗号化がシグナリングされたLSPで使用されることを意図している場合、鍵交換のための通常の追加の往復時間（RTT）が影響するため、この要件をプロトコル設計プロセスの一部として含める必要があります。 GMPLS LSPの設定と解約率について。複数の交換（同じピア間で発生する場合）での鍵交換のコストを償却できるため、一部の交換で完全なRTTを費やす必要がなく、いわゆるゼロRTTモードで動作する必要があります。
The authors would like to thank Ann Von Lehmen, Joe Gannett, Ron Skoog, and Haim Kobrinski of Applied Communication Sciences for their comments and assistance on this document. Lou Berger provided editorial comments on this document.
このドキュメントに関するコメントと支援について、Applied Communication Sciencesのアンフォンレーメン、ジョーガネット、ロンスクーグ、およびハイムコブリンスキーに感謝します。 Lou Bergerがこのドキュメントに編集上のコメントを提供しました。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003, <http://www.rfc-editor.org/info/rfc3471>.
[RFC3471] Berger、L.、Ed。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Functional Description」、RFC 3471、DOI 10.17487 / RFC3471、2003年1月、<http://www.rfc-editor.org/ info / rfc3471>。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, DOI 10.17487/RFC3945, October 2004, <http://www.rfc-editor.org/info/rfc3945>.
[RFC3945] Mannie、E。、編、「Generalized Multi-Protocol Label Switching（GMPLS）Architecture」、RFC 3945、DOI 10.17487 / RFC3945、2004年10月、<http://www.rfc-editor.org/info/ rfc3945>。
[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>。
[RFC5814] Sun, W., Ed. and G. Zhang, Ed., "Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks", RFC 5814, DOI 10.17487/RFC5814, March 2010, <http://www.rfc-editor.org/info/rfc5814>.
[RFC5814]日、西、エド。 and G. Zhang、Ed。、 "Label Switched Path（LSP）Dynamic Provisioning Performance Metrics in Generalized MPLS Networks"、RFC 5814、DOI 10.17487 / RFC5814、March 2010、<http://www.rfc-editor.org/info / rfc5814>。
[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>。
[RFC6383] Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE", RFC 6383, DOI 10.17487/RFC6383, September 2011, <http://www.rfc-editor.org/info/rfc6383>.
[RFC6383] Shiomoto、K。およびA. Farrel、「RSVP-TEを使用して確立されたラベルスイッチドパスでデータの送信を開始しても安全な場合のアドバイス」、RFC 6383、DOI 10.17487 / RFC6383、2011年9月、<http：// www.rfc-editor.org/info/rfc6383>。
[RFC6777] Sun, W., Ed., Zhang, G., Ed., Gao, J., Xie, G., and R. Papneja, "Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks", RFC 6777, DOI 10.17487/RFC6777, November 2012, <http://www.rfc-editor.org/info/rfc6777>.
[RFC6777] Sun、W.、Ed。、Zhang、G.、Ed。、Gao、J.、Xie、G。、およびR. Papneja、「Label Switched Path（LSP）Data Path Delay Metrics in Generalized MPLS and MPLSトラフィックエンジニアリング（MPLS-TE）ネットワーク」、RFC 6777、DOI 10.17487 / RFC6777、2012年11月、<http://www.rfc-editor.org/info/rfc6777>。
[Chiu] Chiu, A., et al., "Architectures and Protocols for Capacity Efficient, Highly Dynamic and Highly Resilient Core Networks", Journal of Optical Communications and Networking vol. 4, No. 1, pp. 1-14, 2012, DOI 10.1364/JOCN.4.000001, <http://dx.doi.org/10.1364/JOCN.4.000001>.
[Chiu] Chiu、A.、et al。、 "Architectures and Protocols for Capacity Efficient、Highly Dynamic and Highly Resilient Core Networks"、Journal of Optical Communications and Networking vol。 4、No. 1、pp。1-14、2012、DOI 10.1364 / JOCN.4.000001、<http://dx.doi.org/10.1364/JOCN.4.000001>。
[Lehmen] Von Lehmen, A., et al., "CORONET: Testbeds, Demonstration, and Lessons Learned", Journal of Optical Communications and Networking Vol. 7, Issue 3, pp. A447-A458, 2015, DOI 10.1364/JOCN.7.00A447, <http://dx.doi.org/10.1364/JOCN.7.00A447>.
[Lehmen] Von Lehmen、A.、et al。、 "CORONET：Testbeds、Demonstration、and Lessons Learned"、Journal of Optical Communications and Networking Vol。 7、Issue 3、pp。A447-A458、2015、DOI 10.1364 / JOCN.7.00A447、<http://dx.doi.org/10.1364/JOCN.7.00A447>。
Authors' Addresses
著者のアドレス
Andrew G. Malis (editor) Huawei Technologies
アンドリューG.マリ（編集者）Huawei Technologies
Email: agmalis@gmail.com
Brian J. Wilson Applied Communication Sciences
ブライアンJ.ウィルソン応用コミュニケーション科学
Email: bwilson@appcomsci.com
George Clapp AT&T Labs Research
George Clapp AT＆T Labs Research
Email: clapp@research.att.com
Vishnu Shukla Verizon Communications
Vishnu Shukla Verizon Communications
Email: vishnu.shukla@verizon.com