[要約] RFC 8413は、リソースのスケジュールされた使用のためのフレームワークを提供するものであり、リソースの効率的な管理と予約を可能にすることを目的としています。
Internet Engineering Task Force (IETF) Y. Zhuang
Request for Comments: 8413 Q. Wu
Category: Informational H. Chen
ISSN: 2070-1721 Huawei
A. Farrel
Juniper Networks
July 2018
Framework for Scheduled Use of Resources
リソースのスケジュールされた使用のためのフレームワーク
Abstract
概要
Time-Scheduled (TS) reservation of Traffic Engineering (TE) resources can be used to provide resource booking for TE Label Switched Paths so as to better guarantee services for customers and to improve the efficiency of network resource usage at any moment in time, including network usage that is planned for the future. This document provides a framework that describes and discusses the architecture for supporting scheduled reservation of TE resources. This document does not describe specific protocols or protocol extensions needed to realize this service.
トラフィックエンジニアリング（TE）リソースのタイムスケジュール（TS）予約を使用して、TEラベルスイッチドパスのリソース予約を提供し、顧客へのサービスをより適切に保証し、ネットワークリソースの使用効率をいつでも向上させることができます。将来的に予定されているネットワーク使用量。このドキュメントは、TEリソースのスケジュールされた予約をサポートするためのアーキテクチャを説明および説明するフレームワークを提供します。このドキュメントでは、このサービスを実現するために必要な特定のプロトコルまたはプロトコル拡張については説明していません。
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 candidates 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 https://www.rfc-editor.org/info/rfc8413.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8413で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Provisioning TE-LSPs and TE Resources . . . . . . . . . . 4
2.2. Selecting the Path of an LSP . . . . . . . . . . . . . . 4
2.3. Planning Future LSPs . . . . . . . . . . . . . . . . . . 5
2.4. Looking at Future Demands on TE Resources . . . . . . . . 6
2.4.1. Interaction between Time-Scheduled and Ad Hoc
Reservations . . . . . . . . . . . . . . . . . . . . 6
2.5. Requisite State Information . . . . . . . . . . . . . . . 7
3. Architectural Concepts . . . . . . . . . . . . . . . . . . . 8
3.1. Where is Scheduling State Held? . . . . . . . . . . . . . 8
3.2. What State is Held? . . . . . . . . . . . . . . . . . . . 10
3.3. Enforcement of Operator Policy . . . . . . . . . . . . . 12
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 13
4.1. Service Request . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Reoptimization After TED Updates . . . . . . . . . . 14
4.2. Initialization and Recovery . . . . . . . . . . . . . . . 15
4.3. Synchronization Between PCEs . . . . . . . . . . . . . . 15
5. Multi-domain Considerations . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Informative References . . . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Traffic Engineering Label Switched Paths (TE-LSPs) are connection-oriented tunnels in packet and non-packet networks [RFC3209] [RFC3945]. TE-LSPs may reserve network resources for use by the traffic they carry, thus providing some guarantees of service delivery and allowing a network operator to plan the use of the resources across the whole network.
トラフィックエンジニアリングラベルスイッチドパス（TE-LSP）は、パケットおよび非パケットネットワークにおける接続指向のトンネルです[RFC3209] [RFC3945]。 TE-LSPは、それらが運ぶトラフィックが使用するためにネットワークリソースを予約する場合があります。これにより、サービス配信の保証が提供され、ネットワークオペレーターがネットワーク全体でのリソースの使用を計画できるようになります。
In some technologies (such as wavelength switched optical networks) the resource is synonymous with the label that is switched on the path of the LSP so that it is not possible to establish an LSP that can carry traffic without assigning a physical resource to the LSP. In other technologies (such as packet switched networks), the resources assigned to an LSP are a measure of the capacity of a link that is dedicated for use by the traffic on the LSP.
一部のテクノロジー（波長切り替え光ネットワークなど）では、リソースはLSPのパスで切り替えられるラベルと同義であるため、物理リソースをLSPに割り当てずにトラフィックを伝送できるLSPを確立することはできません。他のテクノロジー（パケット交換ネットワークなど）では、LSPに割り当てられたリソースは、LSP上のトラフィック専用のリンクの容量の測定値です。
In all cases, network planning consists of selecting paths for LSPs through the network so that there will be no contention for resources. LSP establishment is the act of setting up an LSP and reserving resources within the network. Network optimization or reoptimization is the process of repositioning LSPs in the network to make the unreserved network resources more useful for potential future LSPs while ensuring that the established LSPs continue to fulfill their objectives.
すべての場合において、ネットワークの計画は、リソースを介した競合がないように、ネットワークを介したLSPのパスの選択で構成されます。 LSPの確立は、LSPをセットアップし、ネットワーク内のリソースを予約する行為です。ネットワークの最適化または再最適化は、ネットワーク内のLSPを再配置するプロセスであり、予約されていないLSPが将来のLSPに対してより有用になるようにすると同時に、確立されたLSPが引き続き目的を達成できるようにします。
It is often the case that it is known that an LSP will be needed at some specific time in the future. While a path for that LSP could be computed using knowledge of the currently established LSPs and the currently available resources, this does not give any degree of certainty that the necessary resources will be available when it is time to set up the new LSP. Yet, setting up the LSP ahead of the time when it is needed (which would guarantee the availability of the resources) is wasteful since the network resources could be used for some other purpose in the meantime.
LSPが将来の特定の時点で必要になることがわかっている場合がよくあります。そのLSPのパスは、現在確立されているLSPと現在利用可能なリソースの知識を使用して計算できますが、新しいLSPをセットアップするときに必要なリソースが利用可能であるという確証はありません。それでも、必要なときに（リソースの可用性を保証する）事前にLSPを設定することは無駄です。当面はネットワークリソースを他の目的に使用できるためです。
Similarly, it may be known that an LSP will no longer be needed after some future time and that it will be torn down, which will release the network resources that were assigned to it. This information can be helpful in planning how a future LSP is placed in the network.
同様に、将来的にLSPが不要になり、LSPが破棄されて、それに割り当てられていたネットワークリソースが解放されることがわかっている場合があります。この情報は、将来のLSPがネットワークにどのように配置されるかを計画するのに役立ちます。
Time-Scheduled (TS) reservation of TE resources can be used to provide resource booking for TE-LSPs so as to better guarantee services for customers and to improve the efficiency of network resource usage into the future. This document provides a framework that describes the problem and discusses the architecture for the scheduled reservation of TE resources. This document does not describe specific protocols or protocol extensions needed to realize this service.
TEリソースのタイムスケジュール（TS）予約を使用して、TE-LSPにリソース予約を提供し、顧客へのサービスをより適切に保証し、将来のネットワークリソース使用の効率を向上させることができます。このドキュメントでは、問題を説明し、TEリソースのスケジュールされた予約のアーキテクチャについて説明するフレームワークを提供します。このドキュメントでは、このサービスを実現するために必要な特定のプロトコルまたはプロトコル拡張については説明していません。
TE-LSPs in existing networks are provisioned using a variety of techniques. They may be set up using RSVP-TE as a signaling protocol [RFC3209] [RFC3473]. Alternatively, they could be established by direct control of network elements such as in the Software-Defined Networking (SDN) paradigm. They could also be provisioned using the PCE Communication Protocol (PCEP) [RFC5440] as a control protocol to communicate with the network elements.
既存のネットワークのTE-LSPは、さまざまな手法を使用してプロビジョニングされます。これらは、RSVP-TEをシグナリングプロトコルとして使用してセットアップできます[RFC3209] [RFC3473]。あるいは、ソフトウェア定義ネットワーキング（SDN）パラダイムなどのネットワーク要素を直接制御することによって確立することもできます。また、ネットワーク要素と通信するための制御プロトコルとしてPCE通信プロトコル（PCEP）[RFC5440]を使用してプロビジョニングすることもできます。
TE resources are reserved at the point of use. That is, the resources (wavelengths, timeslots, bandwidth, etc.) are reserved for use on a specific link and are tracked by the Label Switching Routers (LSRs) at the end points of the link. Those LSRs learn which resources to reserve during the LSP setup process.
TEリソースは使用時に予約されます。つまり、リソース（波長、タイムスロット、帯域幅など）は特定のリンクで使用するために予約されており、リンクのエンドポイントのラベルスイッチングルーター（LSR）によって追跡されます。これらのLSRは、LSPセットアッププロセス中に予約するリソースを学習します。
The use of TE resources can be varied by changing the parameters of the LSP that uses them, and the resources can be released by tearing down the LSP.
TEリソースの使用は、それらを使用するLSPのパラメーターを変更することで変更でき、LSPを破棄することでリソースを解放できます。
Resources that have been reserved in the network for use by one LSP may be preempted for use by another LSP. If RSVP-TE signaling is in use, a holding priority and a preemption priority are used to determine which LSPs may preempt the resources that are in use for which other LSPs. If direct (central) control is in use, the controller is able to make preemption decisions. In either case, operator policy forms a key part of preemption since there is a trade between disrupting existing LSPs and enabling new LSPs.
1つのLSPで使用するためにネットワークで予約されているリソースは、別のLSPで使用するためにプリエンプトされる場合があります。 RSVP-TEシグナリングが使用されている場合、保持優先順位とプリエンプション優先順位を使用して、どのLSPが他のどのLSPに使用されているリソースをプリエンプトできるかを決定します。直接（中央）制御が使用されている場合、コントローラーはプリエンプションの決定を行うことができます。どちらの場合でも、既存のLSPを中断することと新しいLSPを有効にすることの間にトレードがあるため、オペレーターポリシーはプリエンプションの重要な部分を形成します。
Although TE-LSPs can determine their paths hop by hop using the shortest path toward the destination to route the signaling protocol messages [RFC3209], in practice this option is not applied because it does not look far enough ahead into the network to verify that the desired resources are available. Instead, the full length of the path of an LSP is usually computed ahead of time either by the head-end LSR of a signaled LSP or by Path Computation Element (PCE) functionality that is in a dedicated server or built into network management software [RFC4655].
TE-LSPは、宛先への最短パスを使用してホップごとにパスを決定し、シグナリングプロトコルメッセージをルーティングすることができますが[RFC3209]、実際にはこのオプションは適用されません。必要なリソースが利用可能です。代わりに、LSPのパスの全長は通常、事前に信号で通知されたLSPのヘッドエンドLSRによって、または専用サーバーにあるかネットワーク管理ソフトウェアに組み込まれているパス計算要素（PCE）機能によって計算されます[ RFC4655]。
Such full-path computation is applied in order that an end-to-end view of the available resources in the network can be used to determine the best likelihood of establishing a viable LSP that meets the service requirements. Even in this situation, however, it is possible that two LSPs being set up at the same time will compete for scarce network resources, which means that one or both of them will fail to be established. This situation is avoided by using a centralized PCE that is aware of the LSP setup requests that are in progress.
このようなフルパス計算は、ネットワークで使用可能なリソースのエンドツーエンドのビューを使用して、サービス要件を満たす実行可能なLSPを確立する可能性が最も高いと判断するために適用されます。ただし、この状況でも、同時にセットアップされている2つのLSPが不足しているネットワークリソースをめぐって競合する可能性があります。つまり、一方または両方のLSPを確立できません。この状況は、進行中のLSPセットアップ要求を認識する集中型PCEを使用することで回避できます。
Path selection may make allowance for preemption as described in Section 2.1. That is, when selecting a path, the decision may be made to choose a path that will result in the preemption of an existing LSP. The trade-off between selecting a less optimal path, failing to select any path at all, and preempting an existing LSP must be subject to operator policy.
セクション2.1で説明されているように、パスの選択によりプリエンプションが考慮される場合があります。つまり、パスを選択するときに、既存のLSPのプリエンプションが発生するパスを選択するように決定できます。最適ではないパスを選択すること、パスをまったく選択しないこと、および既存のLSPをプリエンプトすることの間のトレードオフは、オペレーターのポリシーに従う必要があります。
Path computation is subject to "objective functions" that define what criteria are to be met when the LSP is placed [RFC4655]. These can be criteria that apply to the LSP itself (such as the shortest path to the destination) or to the network state after the LSP is set up (such as the maximized residual link bandwidth). The objective functions may be requested by the application requesting the LSP and may be filtered and enhanced by the computation engine according to operator policy.
パス計算は、LSPが配置されたときに満たされる基準を定義する「目的関数」の対象となります[RFC4655]。これらは、LSP自体（宛先への最短パスなど）またはLSPがセットアップされた後のネットワーク状態（最大化された残余リンク帯域幅など）に適用される基準になります。目的関数は、LSPを要求するアプリケーションによって要求される場合があり、オペレーターのポリシーに従って計算エンジンによってフィルター処理および拡張される場合があります。
LSPs may be established "on demand" when the requester determines that a new LSP is needed. In this case, the path of the LSP is computed as described in Section 2.2.
LSPは、リクエスタが新しいLSPが必要であると判断したときに「オンデマンド」で確立できます。この場合、LSPのパスはセクション2.2で説明されているように計算されます。
However, in many situations, the requester knows in advance that an LSP will be needed at a particular time in the future. For example, the requester may be aware of a large traffic flow that will start at a well-known time, perhaps for a database synchronization or for the exchange of content between streaming sites. Furthermore, the requester may also know for how long the LSP is required before it can be torn down.
ただし、多くの場合、リクエスタは、将来の特定の時点でLSPが必要になることを事前に知っています。たとえば、リクエスタは、おそらくデータベースの同期またはストリーミングサイト間のコンテンツの交換のために、既知の時間に開始される大きなトラフィックフローを認識している場合があります。さらに、リクエスタは、LSPが分解されるまでに必要な時間を知ることもできます。
The set of requests for future LSPs could be collected and held in a central database (such as at a Network Management System (NMS)): when the time comes for each LSP to be set up, the NMS can ask the PCE to compute a path and can then request the LSP to be provisioned. This approach has a number of drawbacks because it is not possible to determine in advance whether it will be possible to deliver the LSP since the resources it needs might be used by other LSPs in the network. Thus, at the time the requester asks for the future LSP, the NMS can only make a best-effort guarantee that the LSP will be set up at the desired time.
将来のLSPに対する一連の要求を収集して、中央データベース（ネットワーク管理システム（NMS）など）に保持できます。各LSPを設定する時期になると、NMSはPCEにパスを取得し、プロビジョニングするLSPを要求できます。必要なリソースがネットワーク内の他のLSPによって使用される可能性があるため、LSPの配信が可能かどうかを事前に判断できないため、このアプローチには多くの欠点があります。したがって、リクエスタが将来のLSPを要求するときに、NMSは、LSPが目的の時間にセットアップされることを保証するベストエフォート型の保証しかできません。
A better solution, therefore, is for the requests for future LSPs to be serviced at once. The paths of the LSPs can be computed ahead of time and converted into reservations of network resources during specific windows in the future. That is, while the path of the LSP is computed and the network resources are reserved, the LSP is not established in the network until the time for which it is scheduled.
したがって、より良い解決策は、将来のLSPの要求を一度に処理することです。 LSPのパスを事前に計算し、将来の特定の時間帯にネットワークリソースの予約に変換できます。つまり、LSPのパスが計算され、ネットワークリソースが予約されている間、LSPはスケジュールされた時間までネットワークで確立されません。
There is a need to take into account items that need to be subject to operator policy, such as 1) the amount of capacity available for scheduling future reservations, 2) the operator preference for the measures that are used with respect to the use of scheduled resources during rapid changes in traffic demand events, or 3) a complex (multiple nodes/links) failure event so as to protect against network destabilization. Operator policy is discussed further in Section 3.3.
1）将来の予約をスケジュールするために利用可能な容量の量、2）スケジュールされた使用に関して使用される測定値に対するオペレーターの好みなど、オペレーターのポリシーに従う必要がある項目を考慮する必要があります。トラフィック需要イベントの急激な変化時のリソース、または3）ネットワークの不安定化から保護するための複雑な（複数のノード/リンク）障害イベント。オペレーターのポリシーについては、セクション3.3で詳しく説明します。
While path computation, as described in Section 2.2, takes account of the currently available network resources and can act to place LSPs in the network so that there is the best possibility of future LSPs being accommodated, it cannot handle all eventualities. It is simple to construct scenarios where LSPs that are placed one at a time lead to future LSPs being blocked, but where foreknowledge of all of the LSPs would have made it possible for them all to be set up.
セクション2.2で説明されているように、パスの計算は現在利用可能なネットワークリソースを考慮し、LSPをネットワークに配置するように機能できるため、将来のLSPに対応できる可能性が最も高くなりますが、すべての不測の事態に対応できません。一度に1つずつ配置されたLSPが将来のLSPのブロックにつながるシナリオを構築するのは簡単ですが、すべてのLSPを事前に知っていれば、すべてのLSPをセットアップできるようになります。
If, therefore, we were able to know in advance what LSPs were going to be requested, we could plan for them and ensure resources were available. Furthermore, such an approach enables a commitment to be made to a service user that an LSP will be set up and available at a specific time.
したがって、どのLSPが要求されるかを事前に知ることができれば、それらを計画し、リソースが利用可能であることを確認できます。さらに、そのようなアプローチにより、LSPがセットアップされ、特定の時間に利用可能になるというサービスユーザーへのコミットメントが可能になります。
A reservation service can be achieved by tracking the current use of network resources and also having a future view of the resource usage. We call this Time-Scheduled TE (TS-TE) resource reservation.
予約サービスは、ネットワークリソースの現在の使用状況を追跡し、リソースの使用状況を将来的に把握することで実現できます。これをタイムスケジュールTE（TS-TE）リソース予約と呼びます。
There will, of course, be a mixture of resource uses in a network. For example, normal unplanned LSPs may be requested alongside TS-TE LSPs. When an unplanned LSP is requested, no prior accommodation can be made to arrange resource availability, so the LSP can be placed no better than would be the case without TS-TE. However, the new LSP can be placed considering the future demands of TS-TE LSPs that have already been requested. Of course, the unplanned LSP has no known end time and so any network planning must assume that it will consume resources forever.
もちろん、ネットワークではリソースの使用が混合されます。たとえば、通常の計画外のLSPがTS-TE LSPとともに要求される場合があります。計画外のLSPが要求された場合、リソースの可用性を調整するための事前調整を行うことができないため、TS-TEがない場合よりもLSPを配置することができます。ただし、新しいLSPは、すでに要求されているTS-TE LSPの将来の要求を考慮して配置できます。もちろん、計画外のLSPには既知の終了時間がないため、ネットワーク計画では、リソースを永久に消費すると想定する必要があります。
In order to achieve the TS-TE resource reservation, the use of resources on the path needs to be scheduled. The scheduling state is used to indicate when resources are reserved and when they are available for use.
TS-TEリソース予約を実現するには、パス上のリソースの使用をスケジュールする必要があります。スケジューリング状態は、リソースがいつ予約され、いつ使用できるようになるかを示すために使用されます。
A simple information model for one piece of the scheduling state is as follows:
1つのスケジューリング状態の簡単な情報モデルは次のとおりです。
{
link id;
resource id or reserved capacity;
reservation start time;
reservation end time
}
The resource that is scheduled could be link capacity, physical resources on a link, buffers on an interface, etc., and could include advanced considerations such as CPU utilization and the availability of memory at nodes within the network. The resource-related information might also include the maximal unreserved bandwidth of the link over a time interval. That is, the intention is to book (reserve) a percentage of the residual (unreserved) bandwidth of the link. This could be used, for example, to reserve bandwidth for a particular class of traffic (such as IP) that doesn't have a provisioned LSP.
スケジュールされるリソースは、リンク容量、リンク上の物理リソース、インターフェイス上のバッファなどであり、CPU使用率やネットワーク内のノードでのメモリの可用性などの高度な考慮事項を含めることができます。リソース関連の情報には、時間間隔におけるリンクの予約されていない最大帯域幅も含まれる場合があります。つまり、リンクの残りの（予約されていない）帯域幅の割合を予約（予約）することを目的としています。これは、たとえば、プロビジョニングされたLSPを持たない特定のクラスのトラフィック（IPなど）の帯域幅を予約するために使用できます。
For any one resource, there could be multiple pieces of the scheduling state, and for any one link, the timing windows might overlap.
1つのリソースでは、スケジューリング状態の複数の部分が存在する可能性があり、1つのリンクでは、タイミングウィンドウが重複する可能性があります。
There are multiple ways to realize this information model and different ways to store the data. The resource state could be expressed as a start time and an end time (as shown above), or it could be expressed as a start time and a duration. Multiple reservation periods, possibly of different lengths, may need to be recorded for each resource. Furthermore, the current state of network reservation could be kept separate from the scheduled usage, or everything could be merged into a single TS database.
この情報モデルを実現する方法はいくつかあり、データを保存する方法もいくつかあります。リソースの状態は、（上記のように）開始時刻と終了時刻として表すことも、開始時刻と期間として表すこともできます。リソースごとに、長さが異なる可能性のある複数の予約期間を記録する必要がある場合があります。さらに、ネットワーク予約の現在の状態をスケジュールされた使用とは別に保持することも、すべてを単一のTSデータベースにマージすることもできます。
An application may make a reservation request for immediate resource usage or to book resources for future use so as to maximize the chance of services being delivered and to avoid contention for resources in the future. A single reservation request may book resources for multiple periods and might request a reservation that repeats on a regular cycle.
サービスが提供される可能性を最大化し、将来のリソースの競合を回避するために、アプリケーションは、即時のリソース使用の予約要求、または将来の使用のためにリソースを予約する場合があります。 1つの予約リクエストで複数の期間のリソースを予約し、定期的に繰り返される予約をリクエストする場合があります。
A computation engine (that is, a PCE) may use the scheduling state information to help optimize the use of resources into the future and reduce contention or blocking when the resources are actually needed.
計算エンジン（つまり、PCE）は、スケジューリング状態情報を使用して、将来のリソースの使用を最適化し、リソースが実際に必要な場合の競合またはブロックを減らすことができます。
Note that it is also necessary to store the information about future LSPs as distinct from the specific resource scheduling. This information is held to allow the LSPs to be instantiated when they are due, and use the paths/resources that have been computed for them, and also to provide correlation with the TS-TE resource reservations so that it is clear why resources were reserved, thus allowing preemption and handling the release of reserved resources in the event of cancellation of future LSPs. See Section 3.2 for further discussion of the distinction between scheduled resource state and scheduled LSP state.
特定のリソーススケジューリングとは別に、将来のLSPに関する情報を保存することも必要です。この情報は、LSPが期限切れになったときにインスタンス化できるようにし、計算されたパス/リソースを使用できるようにし、またリソースが予約された理由を明確にするためにTS-TEリソース予約との相関を提供するために保持されますしたがって、将来のLSPがキャンセルされた場合に、予約されたリソースの解放を優先して処理することができます。スケジュールされたリソース状態とスケジュールされたLSP状態の違いの詳細については、セクション3.2を参照してください。
Network performance factors (such as maximum link utilization and the residual capacity of the network), with respect to supporting scheduled reservations, need to be supported and are subject to operator policy.
スケジュールされた予約のサポートに関するネットワークパフォーマンス要因（最大リンク使用率やネットワークの残りの容量など）はサポートする必要があり、オペレーターのポリシーの対象となります。
This section examines several important architectural concepts to understand the design decisions reached in this document to achieve TS-TE in a scalable and robust manner.
このセクションでは、いくつかの重要なアーキテクチャの概念を検討して、このドキュメントで達成された設計上の決定を理解し、スケーラブルで堅牢な方法でTS-TEを実現します。
The scheduling state information described in Section 2.5 has to be held somewhere. There are two places where this makes sense:
セクション2.5で説明されているスケジューリング状態情報は、どこかに保持する必要があります。これが意味のある場所が2つあります。
o in the network nodes where the resources exist; or,
o リソースが存在するネットワークノード。または、
o in a central scheduling controller where decisions about resource allocation are made.
o リソースの割り当てに関する決定が行われる中央のスケジューリングコントローラで。
The first of these makes policing of resource allocation easier. It means that many points in the network can request immediate or scheduled LSPs with the associated resource reservation, and that all such requests can be correlated at the point where the resources are allocated. However, this approach has some scaling and technical problems:
これらの最初のものは、リソース割り当てのポリシングを容易にします。これは、ネットワーク内の多くのポイントが、関連するリソース予約で即時またはスケジュールされたLSPを要求できること、およびそのようなすべての要求を、リソースが割り当てられたポイントで関連付けることができることを意味します。ただし、このアプローチにはスケーリングと技術的な問題がいくつかあります。
o The most obvious issue is that each network node must retain the full time-based state for all of its resources. In a busy network with a high arrival rate of new LSPs and a low hold time for each LSP, this could be a lot of state. Network nodes are normally implemented with minimal spare memory.
o 最も明白な問題は、各ネットワークノードがすべてのリソースについて完全な時間ベースの状態を保持する必要があることです。新しいLSPの到着率が高く、各LSPの保持時間が短い、ビジーなネットワークでは、これは多くの状態になる可能性があります。ネットワークノードは通常、最小限のスペアメモリで実装されます。
o In order that path computation can be performed, the computing entity normally known as a Path Computation Element (PCE) [RFC4655] needs access to a database of available links and nodes in the network (as well as the TE properties of said links). This database is known as the Traffic Engineering Database (TED) and is usually populated from information advertised in the IGP by each of the network nodes or exported using BGP Link State (BGP-LS) [RFC7752]. To be able to compute a path for a future LSP, the PCE needs to populate the TED with all of the future resource availability: if this information is held on the network nodes, it must also be advertised in the IGP. This could be a significant scaling issue for the IGP and the network nodes, as all of the advertised information is held at every network node and must be periodically refreshed by the IGP.
o パス計算を実行できるようにするために、パス計算要素（PCE）[RFC4655]として通常知られている計算エンティティは、ネットワークで利用可能なリンクとノードのデータベース（および上記リンクのTEプロパティ）にアクセスする必要があります。このデータベースは、トラフィックエンジニアリングデータベース（TED）と呼ばれ、通常、各ネットワークノードによってIGPでアドバタイズされた情報、またはBGPリンク状態（BGP-LS）[RFC7752]を使用してエクスポートされた情報から読み込まれます。将来のLSPのパスを計算できるようにするには、PCEがTEDに将来のすべてのリソースの可用性を設定する必要があります。この情報がネットワークノードで保持されている場合は、IGPでもアドバタイズする必要があります。アドバタイズされたすべての情報はすべてのネットワークノードで保持され、IGPによって定期的に更新する必要があるため、これはIGPおよびネットワークノードにとって大きなスケーリングの問題になる可能性があります。
o When a normal node restarts, it can recover the resource reservation state from the forwarding hardware, from Non-Volatile Random-Access Memory (NVRAM), or from adjacent nodes through the signaling protocol [RFC5063]. If the scheduling state is held at the network nodes, it must also be recovered after the restart of a network node. This cannot be achieved from the forwarding hardware because the reservation will not have been made, could require additional expensive NVRAM, or might require that all adjacent nodes also have the scheduling state in order to reinstall it on the restarting node. This is potentially complex processing with scaling and cost implications.
o 通常のノードが再起動すると、フォワーディングハードウェア、不揮発性ランダムアクセスメモリ（NVRAM）、またはシグナリングプロトコル[RFC5063]を介して隣接ノードからリソース予約状態を回復できます。スケジューリング状態がネットワークノードで保持されている場合は、ネットワークノードの再起動後にもその状態を回復する必要があります。これは、予約が行われなかったり、追加の高価なNVRAMが必要になったり、再起動するノードに再インストールするためにすべての隣接ノードにもスケジューリング状態が必要になるため、転送ハードウェアからは実現できません。これは、スケーリングとコストの影響を伴う潜在的に複雑な処理です。
Conversely, if the scheduling state is held centrally, it is easily available at the point of use. That is, the PCE can utilize the state to plan future LSPs and can update that stored information with the scheduled reservation of resources for those future LSPs. This approach also has several issues:
逆に、スケジューリング状態が一元的に保持されている場合は、使用時に簡単に使用できます。つまり、PCEは状態を利用して将来のLSPを計画し、その保存された情報を、将来のLSPのリソースのスケジュールされた予約で更新できます。このアプローチには、いくつかの問題もあります。
o If there are multiple controllers, then they must synchronize their stored scheduling state as they each plan future LSPs and they must have a mechanism to resolve resource contention. This is relatively simple and is mitigated by the fact that there is ample processing time to replan future LSPs in the case of resource contention.
o 複数のコントローラーが存在する場合、それぞれが将来のLSPを計画し、リソースの競合を解決するメカニズムを備えているため、保存されているスケジューリング状態を同期する必要があります。これは比較的単純で、リソースの競合が発生した場合に将来のLSPを再計画するための十分な処理時間があるという事実によって緩和されます。
o If other sources of immediate LSPs are allowed (for example, other controllers or autonomous action by head-end LSRs), then the changes in resource availability caused by the setup or tear down of these LSPs must be reflected in the TED (by use of the IGP as is already normally done) and may have an impact on planned future LSPs. This impact can be mitigated by replanning future LSPs or through LSP preemption.
o 即時LSPの他のソースが許可されている場合（たとえば、他のコントローラーまたはヘッドエンドLSRによる自律アクション）、これらのLSPのセットアップまたはティアダウンによって引き起こされるリソース可用性の変更は、TEDに反映される必要があります（ IGPはすでに通常どおり行われています）、将来の計画LSPに影響を与える可能性があります。この影響は、将来のLSPを再計画するか、LSPプリエンプションを使用することで軽減できます。
o If the scheduling state is held centrally at a PCE, the state must be held and restored after a system restart. This is relatively easy to achieve on a central server that can have access to non-volatile storage. The PCE could also synchronize the scheduling state with other PCEs after restart. See Section 4.2 for details.
o スケジューリング状態がPCEで集中的に保持されている場合、システムの再起動後に状態を保持して復元する必要があります。これは、不揮発性ストレージにアクセスできる中央サーバーで比較的簡単に実現できます。 PCEは、再起動後にスケジューリング状態を他のPCEと同期させることもできます。詳細については、セクション4.2を参照してください。
o Of course, a centralized system must store information about all of the resources in the network. In a busy network with a high arrival rate of new LSPs and a low hold time for each LSP, this could be a lot of state. This is multiplied by the size of the network measured both by the number of links and nodes and by the number of trackable resources on each link or at each node. This challenge may be mitigated by the centralized server being dedicated hardware, but there remains the problem of collecting the information from the network in a timely way when there is potentially a very large amount of information to be collected and when the rate of change of that information is high. This latter challenge is only solved if the central server has full control of the booking of resources and the establishment of new LSPs so that the information from the network only serves to confirm what the central server expected.
o もちろん、集中システムは、ネットワーク内のすべてのリソースに関する情報を保存する必要があります。新しいLSPの到着率が高く、各LSPの保持時間が短い、ビジーなネットワークでは、これは多くの状態になる可能性があります。これには、リンクとノードの数、および各リンクまたは各ノードの追跡可能なリソースの数の両方で測定されたネットワークのサイズが掛けられます。この課題は、集中型サーバーが専用ハードウェアであることによって軽減される可能性がありますが、収集される可能性のある非常に大量の情報が潜在的にあり、その変化率が変化する場合に、ネットワークからタイムリーに情報を収集するという問題が残っています。情報は高いです。この後者の課題は、中央サーバーがリソースの予約と新しいLSPの確立を完全に制御できる場合にのみ解決され、ネットワークからの情報は中央サーバーが予期したものを確認するためだけに機能します。
Thus, considering these trade-offs, the architectural conclusion is that the scheduling state should be held centrally at the point of use and not in the network devices.
したがって、これらのトレードオフを考慮すると、アーキテクチャ上の結論は、スケジューリング状態はネットワークデバイスではなく使用ポイントで集中的に保持されるべきであるということです。
As already described, the PCE needs access to an enhanced, time-based
TED. It stores the Traffic Engineering (TE) information, such as
bandwidth, for every link for a series of time intervals. There are
a few ways to store the TE information in the TED. For example,
suppose that the amount of the unreserved bandwidth at a priority
level for a link is Bj in a time interval from time Tj to Tk (k =
j+1), where j = 0, 1, 2, ....
Bandwidth
^
| B3
| B1 ___________
| __________
|B0 B4
|__________ B2 _________
| ________________
|
-+-------------------------------------------------------> Time
|T0 T1 T2 T3 T4
Figure 1: A Plot of Bandwidth Usage against Time
図1：時間に対する帯域幅使用量のプロット
The unreserved bandwidth for the link can be represented and stored in the TED as [T0, B0], [T1, B1], [T2, B2], [T3, B3], ... as shown in Figure 1.
図1に示すように、リンクの予約されていない帯域幅は、[T0、B0]、[T1、B1]、[T2、B2]、[T3、B3]、...として表され、TEDに保存されます。
But it must be noted that service requests for future LSPs are known in terms of the LSPs whose paths are computed and for which resources are scheduled. For example, if the requester of a future LSP decides to cancel the request or to modify the request, the PCE must be able to map this to the resources that were reserved. When the LSP (or the request for the LSP with a number of time intervals) is canceled, the PCE must release the resources that were reserved on each of the links along the path of the LSP in every time interval from the TED. If the bandwidth that had been reserved for the LSP on a link was B from time T2 to T3 and the unreserved bandwidth on the link was B2 from T2 to T3, then B is added back to the link for the time interval from T2 to T3 and the unreserved bandwidth on the link from T2 to T3 will be seen to be B2 + B.
ただし、将来のLSPに対するサービス要求は、パスが計算され、リソースがスケジュールされるLSPに関して既知であることに注意する必要があります。たとえば、将来のLSPの要求者が要求をキャンセルするか、要求を変更することを決定した場合、PCEはこれを予約されたリソースにマップできる必要があります。 LSP（またはいくつかの時間間隔でのLSPの要求）がキャンセルされると、PCEは、TEDからのすべての時間間隔でLSPのパスに沿った各リンクで予約されたリソースを解放する必要があります。リンク上のLSP用に予約された帯域幅が時間T2からT3までBであり、リンク上の予約されていない帯域幅がT2からT3までB2だった場合、BはT2からT3までの時間間隔でリンクに追加されます。 T2からT3へのリンクの予約されていない帯域幅は、B2 + Bであることがわかります。
This suggests that the PCE needs an LSP Database (LSP-DB) [RFC8231] that contains information not only about LSPs that are active in the network but also those that are planned. For each time interval that applies to the LSP, the information for an LSP stored in the LSP-DB includes: the time interval, the paths computed for the LSP satisfying the constraints in the time interval, and the resources (such as bandwidth) reserved for the LSP in the time interval. See also Section 2.3
これは、PCEがLSPデータベース（LSP-DB）[RFC8231]を必要としていることを示唆しています。これには、ネットワークでアクティブなLSPだけでなく、計画されているLSPに関する情報も含まれています。 LSPに適用される時間間隔ごとに、LSP-DBに保存されているLSPの情報には、時間間隔、時間間隔の制約を満たすLSPについて計算されたパス、および予約されているリソース（帯域幅など）が含まれます。時間間隔内のLSPの場合。セクション2.3も参照
It is an implementation choice how the TED and LSP-DB are stored both for dynamic use and for recovery after failure or restart, but it may be noted that all of the information in the scheduled TED can be recovered from the active network state and from the scheduled LSP-DB.
TEDとLSP-DBを動的に使用する場合と、障害または再起動後の回復用に格納する方法は実装の選択ですが、スケジュールされたTEDのすべての情報は、アクティブなネットワーク状態とスケジュールされたLSP-DB。
Computation requests for LSPs are serviced according to operator policy. For example, a PCE may refuse a computation request because the application making the request does not have sufficient permissions or because servicing the request might take specific resource usage over a given threshold.
LSPの計算要求は、オペレーターのポリシーに従って処理されます。たとえば、要求を行うアプリケーションに十分なアクセス許可がないか、要求の処理に特定のリソース使用率が指定されたしきい値を超える可能性があるため、PCEが計算要求を拒否することがあります。
Furthermore, the preemption and holding priorities of any particular computation request may be subject to the operator's policies. The request could be rejected if it does not conform to the operator's policies, or (possibly more likely) the priorities could be set/ overwritten according to the operator's policies.
さらに、特定の計算要求の優先権および保持優先度は、オペレーターのポリシーの対象となる場合があります。オペレーターのポリシーに準拠していない場合、要求は拒否される可能性があります。または、オペレーターのポリシーに従って優先順位が設定/上書きされる可能性があります。
Additionally, the Objective Functions (OFs) of computation request (such as maximizing residual bandwidth) are also subject to operator policies. It is highly likely that the choice of OFs is not available to an application and is selected by the PCE or management system subject to operator policies and knowledge of the application.
さらに、計算リクエストの目的関数（OF）（残余帯域幅の最大化など）もオペレーターのポリシーの対象となります。 OFの選択はアプリケーションで利用できない可能性が高く、オペレーターのポリシーとアプリケーションの知識に従って、PCEまたは管理システムによって選択されます。
None of these statements is new to scheduled resources. They apply to stateless, stateful, passive, and active PCEs, and they continue to apply to scheduling of resources.
これらのステートメントはどれも、スケジュールされたリソースにとって新しいものではありません。これらは、ステートレス、ステートフル、パッシブ、およびアクティブPCEに適用され、リソースのスケジューリングにも引き続き適用されます。
An operator may choose to configure special behavior for a PCE that handles resource scheduling. For example, an operator might want only a certain percentage of any resource to be bookable. And an operator might want the preemption of booked resources to be an inverse function of how far in the future the resources are needed for the first time.
オペレーターは、リソースのスケジューリングを処理するPCEの特別な動作を構成することを選択できます。たとえば、オペレーターは予約可能なリソースの特定のパーセンテージのみを必要とする場合があります。また、オペレーターは、予約されたリソースのプリエンプションを、将来リソースが初めて必要になるまでの距離の逆関数にすることもできます。
It is a general assumption about the architecture described in Section 4 that a PCE is under the operational control of the operator that owns the resources that the PCE manipulates. Thus, the operator may configure any amount of (potentially complex) policy at the PCE. This configuration would also include policy points surrounding reoptimization of existing and planned LSPs in the event of changes in the current and future (planned) resource availability.
PCEは、PCEが操作するリソースを所有するオペレーターの操作制御下にあるというセクション4で説明されているアーキテクチャーに関する一般的な前提です。したがって、オペレーターは、任意の量の（潜在的に複雑な）ポリシーをPCEで構成できます。この構成には、現在および将来の（計画された）リソースの可用性が変更された場合に、既存および計画されたLSPの再最適化に関するポリシーポイントも含まれます。
The granularity of the timing window offered to an application will depend on an operator's policy as well as the implementation in the PCE and goes to define the operator' service offerings. Different granularities and different lengths of prebooking may be offered to different applications.
アプリケーションに提供されるタイミングウィンドウの細かさは、PCEでの実装と同様にオペレーターのポリシーに依存し、オペレーターのサービス提供を定義します。さまざまな粒度とさまざまな長さの事前予約がさまざまなアプリケーションに提供される場合があります。
The architectural considerations and conclusions described in the previous section lead to the architecture described in this section and illustrated in Figure 2. The interfaces and interactions shown in the figure and labeled (a) through (f) are described in Section 4.1.
前のセクションで説明したアーキテクチャの考慮事項と結論は、このセクションで説明し、図2に示すアーキテクチャにつながります。図に示され、（a）〜（f）とラベル付けされたインターフェースと相互作用については、セクション4.1で説明します。
-------------------
| Service Requester |
-------------------
^
a|
v
------- b --------
| |<--->| LSP-DB |
| | --------
| PCE |
| | c -----
| |<---->| TED |
------- -----
^ ^
| |
d| |e
| |
------+-----+--------------------
| | Network
| --------
| | Router |
v --------
----- -----
| LSR |<------>| LSR |
----- f -----
Figure 2: Reference Architecture for Scheduled Use of Resources
図2：スケジュールされたリソースの使用のためのリファレンスアーキテクチャ
As shown in Figure 2, some component in the network requests a service. This may be an application, an NMS, an LSR, or any component that qualifies as a Path Computation Client (PCC). We show this on the figure as the "Service Requester", and it sends a request to the PCE for an LSP to be set up at some time (either now or in the future). The request, indicated on Figure 2 by the arrow (a), includes all of the parameters of the LSP that the requester wishes to supply, such as priority, bandwidth, start time, and end time. Note that the requester in this case may be the LSR shown in the figure or may be a distinct system.
図2に示すように、ネットワーク内の一部のコンポーネントがサービスを要求します。これは、アプリケーション、NMS、LSR、またはパス計算クライアント（PCC）として適格なコンポーネントです。これを「サービスリクエスタ」として図に示し、いつか（現在または将来）LSPを設定するようにPCEに要求を送信します。図2の矢印（a）で示されている要求には、優先度、帯域幅、開始時刻、終了時刻など、要求者が提供したいLSPのすべてのパラメーターが含まれています。この場合のリクエスターは、図に示されているLSRでも、別個のシステムでもかまいません。
The PCE enters the LSP request in its LSP-DB (b) and uses information from its TED (c) to compute a path that satisfies the constraints (such as bandwidth) for the LSP in the time interval from the start time to the end time. It updates the future resource availability in the TED so that further path computations can take account of the scheduled resource usage. It stores the path for the LSP into the LSP-DB (b).
PCEはLSP要求をLSP-DBに入力し（b）、TEDからの情報を使用して（c）開始時刻から終了時刻までの時間間隔でLSPの制約（帯域幅など）を満たすパスを計算します時間。 TEDの将来のリソースの可用性を更新するため、以降のパス計算では、スケジュールされたリソースの使用量を考慮できます。 LSPのパスをLSP-DBに保存します（b）。
When it is time (i.e., at the start time) for the LSP to be set up, the PCE sends a PCEP Initiate request to the head-end LSR (d), which provides the path to be signaled as well as other parameters, such as the bandwidth of the LSP.
LSPをセットアップする時間（つまり、開始時間）になると、PCEはPCEP開始要求をヘッドエンドLSR（d）に送信します。これにより、シグナリングされるパスとその他のパラメーターが提供されます。 LSPの帯域幅など。
As the LSP is signaled between LSRs (f), the use of resources in the network is updated and distributed using the IGP. This information is shared with the PCE either through the IGP or using BGP-LS (e), and the PCE updates the information stored in its TED (c).
LSPはLSR間で通知されるため（f）、ネットワーク内のリソースの使用はIGPを使用して更新および分散されます。この情報は、IGPまたはBGP-LSを使用してPCEと共有され（e）、PCEはそのTEDに格納された情報を更新します（c）。
After the LSP is set up, the head-end LSR sends a PCEP LSP State Report (PCRpt) message to the PCE (d). The report contains the resources, such as bandwidth usage, for the LSP. The PCE updates the status of the LSP in the LSP-DB according to the report.
LSPがセットアップされた後、ヘッドエンドLSRはPCEP LSP状態レポート（PCRpt）メッセージをPCEに送信します（d）。レポートには、LSPの帯域幅使用量などのリソースが含まれています。 PCEは、レポートに従ってLSP-DBのLSPのステータスを更新します。
When an LSP is no longer required (either because the Service Requester has canceled the request or because the LSP's scheduled lifetime has expired), the PCE can remove it. If the LSP is currently active, the PCE instructs the head-end LSR to tear it down (d), and the network resource usage will be updated by the IGP and advertised back to the PCE through the IGP or BGP-LS (e). Once the LSP is no longer active, the PCE can remove it from the LSP-DB (b).
LSPが不要になった場合（サービスリクエスターが要求をキャンセルしたか、LSPのスケジュールされた有効期限が切れたため）、PCEはそれを削除できます。 LSPが現在アクティブな場合、PCEはヘッドエンドLSRにそれを破棄するように指示し（d）、ネットワークリソースの使用量はIGPによって更新され、IGPまたはBGP-LSを介してPCEにアドバタイズされます（e） 。 LSPがアクティブでなくなると、PCEはLSP-DBから削除できます（b）。
When the TED is updated as indicated in Section 4.1, depending on operator policy (so as to minimize network perturbations), the PCE may perform reoptimization of the LSPs for which it has computed paths. These LSPs may be already provisioned, in which case the PCE issues PCEP Update request messages for the LSPs that should be adjusted. Additionally, the LSPs being reoptimized may be scheduled LSPs that have not yet been provisioned, in which case reoptimization involves updating the store of scheduled LSPs and resources.
4.1に示すようにTEDが更新されると、オペレーターのポリシーに応じて（ネットワークの混乱を最小限に抑えるため）、PCEはパスを計算したLSPの再最適化を実行できます。これらのLSPはすでにプロビジョニングされている場合があります。その場合、PCEは調整する必要があるLSPに対してPCEP更新要求メッセージを発行します。さらに、再最適化されるLSPは、まだプロビジョニングされていないスケジュール済みLSPである可能性があります。この場合、再最適化には、スケジュール済みLSPとリソースのストアの更新が含まれます。
In all cases, the purpose of reoptimization is to take account of the resource usage and availability in the network and to compute paths for the current and future LSPs that best satisfy the objectives of those LSPs while keeping the network as clear as possible to support further LSPs. Since reoptimization may perturb established LSPs, it is subject to operator oversight and policy. As the stability of the network will be impacted by frequent changes, the extent and impact of any reoptimization needs to be subject to operator policy.
すべての場合において、再最適化の目的は、ネットワークでのリソースの使用状況と可用性を考慮し、ネットワークをさらに明確に保ちながら、これらのLSPの目的を最もよく満たす現在および将来のLSPのパスを計算することです。 LSP。再最適化は確立されたLSPを混乱させる可能性があるため、オペレーターの監視とポリシーの影響を受けます。ネットワークの安定性は頻繁な変更によって影響を受けるため、再最適化の範囲と影響は、オペレーターのポリシーに従う必要があります。
Additionally, the status of the reserved resources (alarms) can enhance the computation and planning for future LSPs and may influence repair and reoptimization. Control of recalculations based on failures and notifications to the operator is also subject to policy.
さらに、予約されたリソース（アラーム）のステータスは、将来のLSPの計算と計画を強化し、修復と再最適化に影響を与える可能性があります。失敗に基づく再計算の制御とオペレーターへの通知もポリシーの対象となります。
See Section 3.3 for further discussion of operator policy.
オペレーターポリシーの詳細については、セクション3.3を参照してください。
When a PCE in the architecture shown in Figure 2 is initialized, it must learn the state from the network, from its stored databases, and potentially from other PCEs in the network.
図2に示すアーキテクチャのPCEが初期化されるとき、PCEはネットワークから、その格納されたデータベースから、そして場合によってはネットワーク内の他のPCEから状態を学習する必要があります。
The first step is to get an accurate view of the topology and resource availability in the network. This would normally involve reading the state directly from the network via the IGP or BGP-LS (e), but it might include receiving a copy of the TED from another PCE. Note that a TED stored from a previous instantiation of the PCE is unlikely to be valid.
最初のステップは、トポロジとネットワーク内のリソースの可用性を正確に把握することです。これには通常、IGPまたはBGP-LS（e）を介してネットワークから直接状態を読み取ることが含まれますが、別のPCEからTEDのコピーを受信することも含まれます。 PCEの以前のインスタンス化から保存されたTEDが有効である可能性は低いことに注意してください。
Next, the PCE must construct a time-based TED to show scheduled resource usage. How it does this is implementation specific, and this document does not dictate any particular mechanism: it may recover a time-based TED previously saved to non-volatile storage, or it may reconstruct the time-based TED from information retrieved from the LSP-DB previously saved to non-volatile storage. If there is more than one PCE active in the network, the recovering PCE will need to synchronize the LSP-DB and time-based TED with other PCEs (see Section 4.3).
次に、PCEは時間ベースのTEDを作成して、スケジュールされたリソースの使用状況を表示する必要があります。これがどのように行われるかは実装固有であり、このドキュメントは特定のメカニズムを規定していません。以前に不揮発性ストレージに保存された時間ベースのTEDを回復する場合や、LSPから取得した情報から時間ベースのTEDを再構築する場合があります。以前に不揮発性ストレージに保存されたDB。ネットワーク内にアクティブなPCEが複数ある場合、回復するPCEは、LSP-DBおよび時間ベースのTEDを他のPCEと同期させる必要があります（セクション4.3を参照）。
Note that the stored LSP-DB needs to include the intended state and actual state of the LSPs so that when a PCE recovers, it is able to determine what actions are necessary.
保存されたLSP-DBには、PCEが回復したときに必要なアクションを判別できるように、LSPの意図した状態と実際の状態を含める必要があることに注意してください。
If there is active in the network more than one PCE that supports scheduling, it is important to achieve some consistency between the scheduled TED and scheduled LSP-DB held by the PCEs.
スケジューリングをサポートする複数のPCEがネットワークでアクティブになっている場合、PCEが保持するスケジュール済みTEDとスケジュール済みLSP-DBの間に一定の整合性を達成することが重要です。
[RFC7399] answers various questions around synchronization between the PCEs. It should be noted that the time-based "scheduled" information adds another dimension to the issue of synchronization between PCEs. It should also be noted that a deployment may use a primary PCE and then have other PCEs as backup, where a backup PCE can take over only in the event of a failure of the primary PCE. Alternatively, the PCEs may share the load at all times. The choice of the synchronization technique is largely dependent on the deployment of PCEs in the network.
[RFC7399]は、PCE間の同期に関するさまざまな質問に答えます。時間ベースの「スケジュールされた」情報は、PCE間の同期の問題に別の側面を追加することに注意してください。また、展開ではプライマリPCEを使用し、他のPCEをバックアップとして使用できます。バックアップPCEは、プライマリPCEに障害が発生した場合にのみ引き継ぐことができます。あるいは、PCEは常に負荷を共有する場合があります。同期手法の選択は、ネットワーク内のPCEの展開に大きく依存します。
One option for ensuring that multiple PCEs use the same scheduled information is simply to have the PCEs driven from the same shared database, but it is likely to be inefficient, and interoperation between multiple implementations will be harder.
複数のPCEが同じスケジュールされた情報を使用することを保証する1つのオプションは、PCEを同じ共有データベースから駆動することですが、非効率的である可能性が高く、複数の実装間の相互運用が難しくなります。
Another option is for each PCE to be responsible for its own scheduled database and to utilize some distributed database synchronization mechanism to have consistent information. Depending on the implementation, this could be efficient, but interoperation between heterogeneous implementations is still hard.
別のオプションは、各PCEが独自のスケジュールされたデータベースを担当し、いくつかの分散データベース同期メカニズムを利用して一貫した情報を持つことです。実装によっては、これは効率的かもしれませんが、異種の実装間の相互運用は依然として困難です。
A further approach is to utilize PCEP messages to synchronize the scheduled state between PCEs. This approach would work well if the number of PCEs that support scheduling is small, but as the number increases, considerable message exchange needs to happen to keep the scheduled databases synchronized. Future solutions could also utilize some synchronization optimization techniques for efficiency. Another variation would be to request information from other PCEs for a particular time slice, but this might have an impact on the optimization algorithm.
さらなるアプローチは、PCEPメッセージを利用して、PCE間でスケジュールされた状態を同期させることです。このアプローチは、スケジューリングをサポートするPCEの数が少ない場合にうまく機能しますが、数が増えると、スケジュールされたデータベースの同期を維持するためにかなりのメッセージ交換が必要になります。将来のソリューションでは、効率を高めるためにいくつかの同期最適化手法を利用することもできます。別のバリエーションは、特定のタイムスライスについて他のPCEから情報を要求することですが、これは最適化アルゴリズムに影響を与える可能性があります。
Multi-domain path computation usually requires some form of cooperation between PCEs, each of which has responsibility for determining a segment of the end-to-end path in the domain for which it has computational responsibility. When computing a scheduled path, resources need to be booked in all of the domains that the path will cross so that they are available when the LSP is finally signaled.
通常、マルチドメインパスの計算には、PCE間の何らかの形式の協調が必要です。各PCEは、計算の責任があるドメイン内のエンドツーエンドパスのセグメントを決定する責任があります。スケジュールされたパスを計算する場合、LSPが最終的に通知されたときに使用できるように、パスが交差するすべてのドメインでリソースを予約する必要があります。
Per-domain path computation [RFC5152] is not an appropriate mechanism when a scheduled LSP is being computed because the computation requests at downstream PCEs are only triggered by signaling. However, a similar mechanism could be used where cooperating PCEs exchange Path Computation Request (PCReq) messages for a scheduled LSP, as shown in Figure 3. In this case, the service requester asks for a scheduled LSP that will span two domains (a). PCE1 computes a path across Domain 1 and reserves the resources and also asks PCE2 to compute and reserve in Domain 2 (b). PCE2 may return a full path or could return a path key [RFC5520]. When it is time for LSP setup, PCE1 triggers the head-end LSR (c), and the LSP is signaled (d). If a path key is used, the entry LSR in Domain 2 will consult PCE2 for the path expansion (e) before completing signaling (f).
ドメインごとのパス計算[RFC5152]は、ダウンストリームPCEでの計算要求がシグナリングによってのみトリガーされるため、スケジュールされたLSPが計算されている場合は適切なメカニズムではありません。ただし、図3に示すように、協調するPCEがスケジュールされたLSPのPath Computation Request（PCReq）メッセージを交換する場合も同様のメカニズムを使用できます。この場合、サービスリクエスターは2つのドメインにまたがるスケジュールされたLSPを要求します（a） 。 PCE1はドメイン1全体のパスを計算してリソースを予約し、ドメイン2で計算して予約するようにPCE2に要求します（b）。 PCE2は完全なパスを返すか、パスキー[RFC5520]を返す可能性があります。 LSPセットアップの時間になると、PCE1がヘッドエンドLSRをトリガーし（c）、LSPが通知されます（d）。パスキーが使用されている場合、ドメイン2のエントリLSRは、シグナリング（f）を完了する前に、パス拡張（e）についてPCE2に問い合わせます。
-------------------
| Service Requester |
-------------------
^
a|
v
------ b ------
| |<---------------->| |
| PCE1 | | PCE2 |
| | | |
------ ------
^ ^
| |
c| e|
| |
----+----------------- ----+-----------------
| | Domain 1 | | | Domain 2 |
| v | | v |
| ----- d ----- | | ----- f ----- |
| | LSR |<--->| LSR |<-+--+->| LSR |<--->| LSR | |
| ----- ----- | | ----- ----- |
---------------------- ----------------------
Figure 3: Per-Domain Path Computation for Scheduled LSPs
図3：スケジュールされたLSPのドメインごとのパス計算
Another mechanism for PCE cooperation in multi-domain LSP setup is Backward Recursive PCE-Based Computation (BRPC) [RFC5441]. This approach relies on the downstream domain to supply a variety of potential paths to the upstream domain. Although BRPC can arrive at a more optimal end-to-end path than per-domain path computation, it is not well suited to LSP scheduling because the downstream PCE would need to reserve resources on all of the potential paths and then release those that the upstream PCE announced it did not plan to use.
マルチドメインLSPセットアップでのPCE連携のもう1つのメカニズムは、逆方向再帰PCEベースの計算（BRPC）[RFC5441]です。このアプローチは、ダウンストリームドメインに依存して、アップストリームドメインへのさまざまな潜在的なパスを提供します。 BRPCはドメインごとのパス計算よりも最適なエンドツーエンドパスに到達できますが、ダウンストリームPCEはすべての潜在的なパスでリソースを予約してから、それらを解放する必要があるため、LSPスケジューリングにはあまり適していません。アップストリームPCEは、使用する予定はないと発表しました。
Finally, we should consider hierarchical PCE (H-PCE) [RFC6805]. This mode of operation is similar to that shown in Figure 3, but a parent PCE is used to coordinate the requests to the child PCEs, which then results in better visibility of the end-to-end path and better coordination of the resource booking. The sequenced flow of control is shown in Figure 4.
最後に、階層PCE（H-PCE）[RFC6805]を検討する必要があります。この操作モードは図3に示すものと似ていますが、親PCEを使用して子PCEへの要求を調整します。これにより、エンドツーエンドパスの可視性が向上し、リソース予約の調整が向上します。シーケンスされた制御フローを図4に示します。
-------------------
| Service Requester |
-------------------
^
a|
v
--------
| |
| Parent |
| PCE |
| |
--------
^ ^ b
b| |_______________________
| |
v v
------ ------
| | | |
| PCE1 | | PCE2 |
| | | |
------ ------
^ ^
| |
c| e|
| |
----+----------------- ----+-----------------
| | Domain 1 | | | Domain 2 |
| v | | v |
| ----- d ----- | | ----- f ----- |
| | LSR |<--->| LSR |<-+--+->| LSR |<--->| LSR | |
| ----- ----- | | ----- ----- |
---------------------- ----------------------
Figure 4: Hierarchical PCE for Path Computation for Scheduled LSPs
図4：スケジュールされたLSPのパス計算のための階層PCE
The protocol implications of scheduled resources are unchanged from "on demand" LSP computation and setup. A discussion of securing PCEP is found in [RFC5440], and work to extend that security is provided in [RFC8253]. Furthermore, the path key mechanism described in [RFC5520] can be used to enhance privacy and security.
スケジュールされたリソースのプロトコルへの影響は、「オンデマンド」LSP計算およびセットアップから変更されていません。 PCEPの保護についての議論は[RFC5440]にあり、そのセキュリティを拡張するための作業は[RFC8253]で提供されています。さらに、[RFC5520]で説明されているパスキーメカニズムを使用して、プライバシーとセキュリティを強化できます。
Similarly, there is no change to the security implications for the signaling of scheduled LSPs. A discussion of the security of the signaling protocols that would be used is found in [RFC5920].
同様に、スケジュールされたLSPのシグナリングのセキュリティへの影響に変更はありません。使用されるであろうシグナリングプロトコルのセキュリティの議論は[RFC5920]にあります。
However, the use of scheduled LSPs extends the attack surface for a PCE-enabled TE system by providing a larger (logically infinite) window during which an attack can be initiated or planned. That is, if bogus scheduled LSPs can be requested and entered into the LSP-DB, then a large number of LSPs could be launched and significant network resources could be blocked. Control of scheduling requests needs to be subject to operator policy, and additional authorization needs to be applied for access to LSP scheduling. Diagnostic tools need to be provided to inspect the LSP-DB to spot attacks.
ただし、スケジュールされたLSPを使用すると、攻撃を開始または計画できる大きな（論理的に無限の）ウィンドウを提供することにより、PCE対応TEシステムの攻撃面が広がります。つまり、偽のスケジュールされたLSPを要求してLSP-DBに入力できる場合、多数のLSPが起動され、重要なネットワークリソースがブロックされる可能性があります。スケジューリング要求の制御はオペレーターのポリシーに従う必要があり、追加の許可をLSPスケジューリングへのアクセスに適用する必要があります。 LSP-DBを検査して攻撃を特定するには、診断ツールを提供する必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[AUTOBW] Yong, L. and Y. Lee, "ASON/GMPLS Extension for Reservation and Time Based Automatic Bandwidth Service", Work in Progress, draft-yong-ccamp-ason-gmpls-autobw-service-00, October 2006.
[AUTOBW] Yong、L。、およびY. Lee、「予約および時間ベースの自動帯域幅サービスのためのASON / GMPLS拡張」、作業中、draft-yong-ccamp-ason-gmpls-autobw-service-00、2006年10月。
[DRAGON] National Science Foundation, "The DRAGON Project: Dynamic Resource Allocation via GMPLS Optical Networks", Overview and Status Presentation at ONT3, September 2006, <http://www.maxgigapop.net/wp-content/uploads/ The-DRAGON-Project.pdf>.
[DRAGON] National Science Foundation、「DRAGON Project：Dynamic Resource Allocation via GMPLS Optical Networks」、概要およびステータスプレゼンテーション、ONT3、2006年9月、<http://www.maxgigapop.net/wp-content/uploads/ The- DRAGON-Project.pdf>。
[FRAMEWORK-TTS] Chen, H., Toy, M., Liu, L., and K. Pithewan, "Framework for Temporal Tunnel Services", Work In Progress, draft-chen-teas-frmwk-tts-01, March 2016.
[FRAMEWORK-TTS] Chen、H.、Toy、M.、Liu、L。、およびK. Pithewan、「Temporal Tunnel Servicesのフレームワーク」、作業中、draft-chen-teas-frmwk-tts-01、3月2016。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <https://www.rfc-editor.org/info/rfc3473>.
[RFC3473] Berger、L。、編、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、DOI 10.17487 / RFC3473、2003年1月、<https： //www.rfc-editor.org/info/rfc3473>。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, DOI 10.17487/RFC3945, October 2004, <https://www.rfc-editor.org/info/rfc3945>.
[RFC3945] Mannie、E。、編、「Generalized Multi-Protocol Label Switching（GMPLS）Architecture」、RFC 3945、DOI 10.17487 / RFC3945、2004年10月、<https://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, <https://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<https：//www.rfc -editor.org/info/rfc4655>。
[RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007, <https://www.rfc-editor.org/info/rfc5063>.
[RFC5063] Satyanarayana、A.、Ed。およびR.ラーマン編、「Extensions to GMPLS Resource Reservation Protocol（RSVP）Graceful Restart」、RFC 5063、DOI 10.17487 / RFC5063、2007年10月、<https://www.rfc-editor.org/info/rfc5063> 。
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, <https://www.rfc-editor.org/info/rfc5152>.
[RFC5152] Vasseur、JP。、編、Ayyangar、A。、編、およびR. Zhang、「ドメイン間トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）を確立するためのドメインごとのパス計算方法」、 RFC 5152、DOI 10.17487 / RFC5152、2008年2月、<https://www.rfc-editor.org/info/rfc5152>。
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5440] Vasseur、JP。、Ed。とJL。 Le Roux編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<https://www.rfc-editor.org/info/rfc5440>。
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, DOI 10.17487/RFC5441, April 2009, <https://www.rfc-editor.org/info/rfc5441>.
[RFC5441] Vasseur、JP。、Ed。、Zhang、R.、Bitar、N.、and JL。 Le Roux、「最短の制約付きドメイン間トラフィックエンジニアリングラベルスイッチドパスを計算するための後方再帰PCEベースの計算（BRPC）手順」、RFC 5441、DOI 10.17487 / RFC5441、2009年4月、<https：//www.rfc- editor.org/info/rfc5441>。
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, DOI 10.17487/RFC5520, April 2009, <https://www.rfc-editor.org/info/rfc5520>.
[RFC5520] Bradford、R。、編、Vasseur、JP、およびA. Farrel、「パスキーベースのメカニズムを使用したドメイン間パス計算におけるトポロジー機密性の保持」、RFC 5520、DOI 10.17487 / RFC5520、4月2009、<https://www.rfc-editor.org/info/rfc5520>。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<https://www.rfc-editor.org/info/rfc5920>。
[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 10.17487/RFC6805, November 2012, <https://www.rfc-editor.org/info/rfc6805>.
[RFC6805]キング、D。、エド。およびA.ファレル編、「MPLSおよびGMPLSにおける一連のドメインの決定へのパス計算要素アーキテクチャの適用」、RFC 6805、DOI 10.17487 / RFC6805、2012年11月、<https：//www.rfc -editor.org/info/rfc6805>。
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path Computation Element Architecture", RFC 7399, DOI 10.17487/RFC7399, October 2014, <https://www.rfc-editor.org/info/rfc7399>.
[RFC7399]ファレル、A。およびD.キング、「パス計算要素アーキテクチャにおける未回答の質問」、RFC 7399、DOI 10.17487 / RFC7399、2014年10月、<https://www.rfc-editor.org/info/rfc7399 >。
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.
[RFC7752] Gredler、H.、Ed。、Medved、J.、Previdi、S.、Farrel、A.、and S. Ray、 "North-bound Distribution of Link-State and Traffic Engineering（TE）Information using BGP" 、RFC 7752、DOI 10.17487 / RFC7752、2016年3月、<https://www.rfc-editor.org/info/rfc7752>。
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/info/rfc8231>.
[RFC8231] Crabbe、E.、Minei、I.、Medved、J。、およびR. Varga、「Pathful Computation Element Communication Protocol（PCEP）Extensions for Stateful PCE」、RFC 8231、DOI 10.17487 / RFC8231、2017年9月、< https://www.rfc-editor.org/info/rfc8231>。
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, <https://www.rfc-editor.org/info/rfc8253>.
[RFC8253] Lopez、D.、Gonzalez de Dios、O.、Wu、Q。、およびD. Dhody、「PCEPS：TLSの使用によるパス計算要素通信プロトコル（PCEP）の安全なトランスポートの提供」、RFC 8253 、DOI 10.17487 / RFC8253、2017年10月、<https://www.rfc-editor.org/info/rfc8253>。
Acknowledgements
謝辞
This work has benefited from the discussions of resource scheduling over the years. In particular, the DRAGON project [DRAGON] and [AUTOBW], both of which provide approaches to auto-bandwidth services in GMPLS networks.
この作業は、何年にもわたってリソーススケジューリングの議論から恩恵を受けてきました。特に、DRAGONプロジェクト[DRAGON]と[AUTOBW]はどちらもGMPLSネットワークの自動帯域幅サービスへのアプローチを提供します。
Mehmet Toy, Lei Liu, and Khuzema Pithewan contributed to an earlier version of [FRAMEWORK-TTS]. We would like to thank the authors of that document on Temporal Tunnel Services for material that assisted in thinking about this document.
Mehmet Toy、Lei Liu、Khuzema Pithewanは、[FRAMEWORK-TTS]の以前のバージョンに貢献しました。 Temporal Tunnel Servicesに関するこのドキュメントの作成者に、このドキュメントの検討に役立つ資料を提供してくれたことに感謝します。
Thanks to Michael Scharf and Daniele Ceccarelli for useful comments on this work.
この作業に関する有益なコメントを提供してくれたMichael ScharfとDaniele Ceccarelliに感謝します。
Jonathan Hardwick provided a helpful Routing Directorate review.
ジョナサンハードウィックは、有用なルーティング総局のレビューを提供しました。
Deborah Brungard, Mirja Kuehlewind, and Benjamin Kaduk suggested many changes during their Area Director reviews.
Deborah Brungard、Mirja Kuehlewind、Benjamin Kadukは、エリアディレクターのレビュー中に多くの変更を提案しました。
Contributors
貢献者
The following person contributed to discussions that led to the development of this document:
次の人物は、このドキュメントの開発につながる議論に貢献しました：
Dhruv Dhody Email: dhruv.dhody@huawei.com
Dhruv Dhodyメール：dhruv.dhody@huawei.com
Authors' Addresses
著者のアドレス
Yan Zhuang Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
yプレスZ黄色H UAを101ソフトウェアアベニュー、Y U描画地区南京、江蘇省210012中国
Email: zhuangyan.zhuang@huawei.com
Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
Wuhu AのQは101ソフトウェアアベニューで、Y Uは地区210012中国江蘇省NaN京を描画します
Email: bill.wu@huawei.com
Huaimo Chen Huawei Boston, MA United States of America
ふあいも ちぇん ふあうぇい ぼｓとん、 ま うにてｄ Ｓたてｓ おｆ あめりか
Email: huaimo.chen@huawei.com
Adrian Farrel Juniper Networks
エイドリアンファレルジュニパーネットワークス
Email: afarrel@juniper.net