[要約] RFC 8735は、ネイティブIPネットワークでのPCE（Path Computation Element）のシナリオとシミュレーション結果についての要約です。このRFCの目的は、PCEの機能とパフォーマンスを評価し、ネットワーク設計や運用に役立つ情報を提供することです。
Internet Engineering Task Force (IETF) A. Wang
Request for Comments: 8735 China Telecom
Category: Informational X. Huang
ISSN: 2070-1721 C. Kou
BUPT
Z. Li
China Mobile
P. Mi
Huawei Technologies
February 2020
Scenarios and Simulation Results of PCE in a Native IP Network
ネイティブIPネットワークにおけるPCEのシナリオとシミュレーション結果
Abstract
概要
Requirements for providing the End-to-End (E2E) performance assurance are emerging within the service provider networks. While there are various technology solutions, there is no single solution that can fulfill these requirements for a native IP network. In particular, there is a need for a universal E2E solution that can cover both intra- and inter-domain scenarios.
エンドツーエンド（E2E）のパフォーマンス保証を提供するための要件は、サービスプロバイダーネットワーク内で出現しています。さまざまなテクノロジーソリューションがありますが、ネイティブIPネットワークのこれらの要件を満たす単一のソリューションはありません。特に、ドメイン内シナリオとドメイン間シナリオの両方をカバーできるユニバーサルE2Eソリューションが必要です。
One feasible E2E traffic-engineering solution is the addition of central control in a native IP network. This document describes various complex scenarios and simulation results when applying the Path Computation Element (PCE) in a native IP network. This solution, referred to as Centralized Control Dynamic Routing (CCDR), integrates the advantage of using distributed protocols and the power of a centralized control technology, providing traffic engineering for native IP networks in a manner that applies equally to intra- and inter-domain scenarios.
実現可能なE2Eトラフィックエンジニアリングソリューションの1つは、ネイティブIPネットワークに中央制御を追加することです。このドキュメントでは、ネイティブIPネットワークでパス計算要素（PCE）を適用した場合のさまざまな複雑なシナリオとシミュレーション結果について説明します。集中制御動的ルーティング（CCDR）と呼ばれるこのソリューションは、分散プロトコルを使用する利点と集中制御技術の能力を統合し、ドメイン内およびドメイン間に等しく適用される方法でネイティブIPネットワークにトラフィックエンジニアリングを提供します。シナリオ。
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/rfc8735.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8735で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. CCDR Scenarios
3.1. QoS Assurance for Hybrid Cloud-Based Application
3.2. Link Utilization Maximization
3.3. Traffic Engineering for Multi-domain
3.4. Network Temporal Congestion Elimination
4. CCDR Simulation
4.1. Case Study for CCDR Algorithm
4.2. Topology Simulation
4.3. Traffic Matrix Simulation
4.4. CCDR End-to-End Path Optimization
4.5. Network Temporal Congestion Elimination
5. CCDR Deployment Consideration
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
A service provider network is composed of thousands of routers that run distributed protocols to exchange reachability information. The path for the destination network is mainly calculated, and controlled, by the distributed protocols. These distributed protocols are robust enough to support most applications; however, they have some difficulties supporting the complexities needed for traffic-engineering applications, e.g., E2E performance assurance, or maximizing the link utilization within an IP network.
サービスプロバイダーネットワークは、分散プロトコルを実行して到達可能性情報を交換する数千のルーターで構成されています。宛先ネットワークのパスは、主に分散プロトコルによって計算および制御されます。これらの分散プロトコルは、ほとんどのアプリケーションをサポートできるほど堅牢です。ただし、E2Eパフォーマンスの保証やIPネットワーク内のリンク利用率の最大化など、トラフィックエンジニアリングアプリケーションに必要な複雑さをサポートするのにいくつかの問題があります。
Multiprotocol Label Switching (MPLS) using Traffic-Engineering (TE) technology (MPLS-TE) [RFC3209] is one solution for TE networks, but it introduces an MPLS network along with related technology, which would be an overlay of the IP network. MPLS-TE technology is often used for Label Switched Path (LSP) protection and setting up complex paths within a domain. It has not been widely deployed for meeting E2E (especially in inter-domain) dynamic performance assurance requirements for an IP network.
トラフィックエンジニアリング（TE）テクノロジー（MPLS-TE）[RFC3209]を使用したマルチプロトコルラベルスイッチング（MPLS）は、TEネットワークのソリューションの1つですが、IPネットワークのオーバーレイとなる関連テクノロジーと共にMPLSネットワークを導入しています。 MPLS-TEテクノロジーは、ラベルスイッチドパス（LSP）保護とドメイン内の複雑なパスの設定によく使用されます。これは、IPネットワークのE2E（特にドメイン間）動的パフォーマンス保証要件を満たすために広く展開されていません。
Segment Routing [RFC8402] is another solution that integrates some advantages of using a distributed protocol and central control technology, but it requires the underlying network, especially the provider edge router, to do an in-depth label push and pop action while adding complexity when coexisting with the non-segment routing network. Additionally, it can only maneuver the E2E paths for MPLS and IPv6 traffic via different mechanisms.
セグメントルーティング[RFC8402]は、分散プロトコルと中央制御テクノロジーを使用することのいくつかの利点を統合するもう1つのソリューションですが、基盤となるネットワーク、特にプロバイダーエッジルーターは、複雑な状況を追加しながら詳細なラベルプッシュおよびポップアクションを実行する必要があります。非セグメントルーティングネットワークと共存します。さらに、MPLSおよびIPv6トラフィックのE2Eパスを操作できるのは、さまざまなメカニズムのみです。
Deterministic Networking (DetNet) [RFC8578] is another possible solution. It is primarily focused on providing bounded latency for a flow and introduces additional requirements on the domain edge router. The current DetNet scope is within one domain. The use cases defined in this document do not require the additional complexity of deterministic properties and so differ from the DetNet use cases.
確定的ネットワーキング（DetNet）[RFC8578]は、考えられる別のソリューションです。これは主にフローに制限付きレイテンシを提供することに焦点を当てており、ドメインエッジルーターに追加の要件を導入します。現在のDetNetスコープは1つのドメイン内にあります。このドキュメントで定義されているユースケースは、決定論的なプロパティの追加の複雑さを必要としないため、DetNetのユースケースとは異なります。
This document describes several scenarios for a native IP network where a Centralized Control Dynamic Routing (CCDR) framework can produce qualitative improvement in efficiency without requiring a change to the data-plane behavior on the router. Using knowledge of the Border Gateway Protocol (BGP) session-specific prefixes advertised by a router, the network topology and the near-real-time link-utilization information from network management systems, a central PCE is able to compute an optimal path and give the underlying routers the destination address to use to reach the BGP nexthop, such that the distributed routing protocol will use the computed path via traditional recursive lookup procedure. Some results from simulations of path optimization are also presented to concretely illustrate a variety of scenarios where CCDR shows significant improvement over traditional distributed routing protocols.
このドキュメントでは、集中制御動的ルーティング（CCDR）フレームワークがルーターのデータプレーンの動作を変更せずに、効率を定性的に向上できるネイティブIPネットワークのいくつかのシナリオについて説明します。ルーターによってアドバタイズされたボーダーゲートウェイプロトコル（BGP）セッション固有のプレフィックス、ネットワークトポロジ、およびネットワーク管理システムからのほぼリアルタイムのリンク利用情報の知識を使用して、中央PCEは最適なパスを計算し、基になるルーターは、BGPネクストホップに到達するために使用する宛先アドレスをルーティングします。これにより、分散ルーティングプロトコルは、従来の再帰的なルックアップ手順を介して計算されたパスを使用します。パス最適化のシミュレーションからの結果の一部は、CCDRが従来の分散ルーティングプロトコルよりも大幅に改善されているさまざまなシナリオを具体的に示しています。
This document is the base document of the following two documents: the universal solution document, which is suitable for intra-domain and inter-domain TE scenario, is described in [PCE-NATIVE-IP]; and the related protocol extension contents is described in [PCEP-NATIVE-IP-EXT].
このドキュメントは、次の2つのドキュメントのベースドキュメントです。ドメイン内およびドメイン間のTEシナリオに適したユニバーサルソリューションドキュメントは、[PCE-NATIVE-IP]で説明されています。関連するプロトコル拡張コンテンツは、[PCEP-NATIVE-IP-EXT]で説明されています。
In this document, PCE is used as defined in [RFC5440]. The following terms are used as described here:
このドキュメントでは、[RFC5440]で定義されているPCEが使用されています。ここで説明するように、次の用語が使用されます。
BRAS: Broadband Remote Access Server
BRAS：ブロードバンドリモートアクセスサーバー
CD: Congestion Degree
CD：混雑度
CR: Core Router
CR：コアルーター
CCDR: Centralized Control Dynamic Routing
CCDR：集中制御動的ルーティング
E2E: End to End
E2E：エンドツーエンド
IDC: Internet Data Center
IDC：Internet Data Center
MAN: Metro Area Network
MAN：メトロエリアネットワーク
QoS: Quality of Service
QoS：サービスの品質
SR: Service Router
SR：サービスルーター
TE: Traffic Engineering
TE：トラフィックエンジニアリング
UID: Utilization Increment Degree
UID：使用率の増分の程度
WAN: Wide Area Network
WAN：広域ネットワーク
The following sections describe various deployment scenarios where applying the CCDR framework is intuitively expected to produce improvements based on the macro-scale properties of the framework and the scenario.
次のセクションでは、CCDRフレームワークを適用すると、フレームワークとシナリオのマクロスケールプロパティに基づいて直感的に改善が見込まれるさまざまな展開シナリオについて説明します。
With the emergence of cloud computing technologies, enterprises are putting more and more services on a public-oriented cloud environment while keeping core business within their private cloud. The communication between the private and public cloud sites spans the WAN. The bandwidth requirements between them are variable, and the background traffic between these two sites varies over time. Enterprise applications require assurance of the E2E QoS performance on demand for variable bandwidth services.
クラウドコンピューティングテクノロジーの出現により、企業は、コアビジネスをプライベートクラウド内に維持しながら、パブリック指向のクラウド環境にますます多くのサービスを配置しています。プライベートクラウドサイトとパブリッククラウドサイト間の通信は、WAN全体に及びます。それらの間の帯域幅要件は可変であり、これら2つのサイト間のバックグラウンドトラフィックは時間とともに変化します。エンタープライズアプリケーションでは、可変帯域幅サービスのオンデマンドでのE2E QoSパフォーマンスの保証が必要です。
CCDR, which integrates the merits of distributed protocols and the power of centralized control, is suitable for this scenario. The possible solution framework is illustrated below:
分散プロトコルのメリットと集中制御の能力を統合したCCDRは、このシナリオに適しています。可能なソリューションフレームワークを以下に示します。
+------------------------+
| Cloud-Based Application|
+------------------------+
|
+-----------+
| PCE |
+-----------+
|
|
//--------------\\
///// \\\\\
Private Cloud Site || Distributed |Public Cloud Site
| Control Network |
\\\\\ /////
\\--------------//
Figure 1: Hybrid Cloud Communication Scenario
図1：ハイブリッドクラウド通信のシナリオ
As illustrated in Figure 1, the source and destination of the "Cloud-Based Application" traffic are located at "Private Cloud Site" and "Public Cloud Site", respectively.
図1に示すように、「クラウドベースのアプリケーション」トラフィックの送信元と宛先は、それぞれ「プライベートクラウドサイト」と「パブリッククラウドサイト」にあります。
By default, the traffic path between the private and public cloud site is determined by the distributed control network. When an application requires E2E QoS assurance, it can send these requirements to the PCE and let the PCE compute one E2E path, which is based on the underlying network topology and real traffic information, in order to accommodate the application's QoS requirements. Section 4.4 of this document describes the simulation results for this use case.
デフォルトでは、プライベートクラウドサイトとパブリッククラウドサイト間のトラフィックパスは、分散制御ネットワークによって決定されます。アプリケーションがE2E QoS保証を必要とする場合、アプリケーションはこれらの要件をPCEに送信し、アプリケーションのQoS要件に対応するために、基盤となるネットワークトポロジと実際のトラフィック情報に基づいてPCEが1つのE2Eパスを計算できるようにします。このドキュメントのセクション4.4では、このユースケースのシミュレーション結果について説明します。
Network topology within a Metro Area Network (MAN) is generally in a star mode as illustrated in Figure 2, with different devices connected to different customer types. The traffic from these customers is often in a tidal pattern with the links between the Core Router (CR) / Broadband Remote Access Server (BRAS) and CR/Service Router (SR) experiencing congestion in different periods due to subscribers under BRAS often using the network at night and the leased line users under SR often using the network during the daytime. The link between BRAS/SR and CR must satisfy the maximum traffic volume between them, respectively, which causes these links to often be underutilized.
メトロエリアネットワーク（MAN）内のネットワークトポロジは、通常、図2に示すようにスターモードであり、さまざまなデバイスがさまざまな種類の顧客に接続されています。これらの顧客からのトラフィックは、コアルーター（CR）/ブロードバンドリモートアクセスサーバー（BRAS）とCR /サービスルーター（SR）の間のリンクが潮汐パターンになっていることが多く、BRASのサブスクライバーが頻繁に夜間のネットワークとSRの専用回線ユーザーは、昼間にネットワークを使用することがよくあります。 BRAS / SRとCRの間のリンクは、それぞれの間の最大トラフィック量を満たす必要があるため、これらのリンクが十分に活用されないことがよくあります。
+--------+
| CR |
+----|---+
|
|-------|--------|-------|
| | | |
+--|-+ +-|+ +--|-+ +-|+
|BRAS| |SR| |BRAS| |SR|
+----+ +--+ +----+ +--+
Figure 2: Star-Mode Network Topology within MAN
図2：MAN内のスターモードネットワークトポロジ
If we consider connecting the BRAS/SR with a local link loop (which is usually lower cost) and control the overall MAN topology with the CCDR framework, we can exploit the tidal phenomena between the BRAS/ CR and SR/CR links, maximizing the utilization of these central trunk links (which are usually higher cost than the local loops).
BRAS / SRをローカルリンクループ（通常は低コスト）に接続し、CCDRフレームワークでMANトポロジ全体を制御することを検討する場合、BRAS / CRリンクとSR / CRリンク間の潮汐現象を利用して、これらの中央トランクリンクの使用率（通常、ローカルループよりもコストが高くなります）。
+-------+
----- PCE |
| +-------+
+----|---+
| CR |
+----|---+
|
|-------|--------|-------|
| | | |
+--|-+ +-|+ +--|-+ +-|+
|BRAS-----SR| |BRAS-----SR|
+----+ +--+ +----+ +--+
Figure 3: Link Utilization Maximization via CCDR
図3：CCDRによるリンク使用率の最大化
Service provider networks are often comprised of different domains, interconnected with each other, forming a very complex topology as illustrated in Figure 4. Due to the traffic pattern to/from the MAN and IDC, the utilization of the links between them are often asymmetric. It is almost impossible to balance the utilization of these links via a distributed protocol, but this unbalance can be overcome utilizing the CCDR framework.
サービスプロバイダーネットワークは、多くの場合、相互に相互接続された異なるドメインで構成され、図4に示すように非常に複雑なトポロジを形成します。MANとIDCとの間のトラフィックパターンにより、それらの間のリンクの利用は非対称になることがよくあります。分散プロトコルを介してこれらのリンクの使用率のバランスを取ることはほとんど不可能ですが、この不均衡はCCDRフレームワークを使用して克服できます。
+---+ +---+
|MAN|----------------|IDC|
+---+ | +---+
| ---------- |
|-----|Backbone|-----|
| ----|----- |
| | |
+---+ | +---+
|IDC|----------------|MAN|
+---+ +---+
Figure 4: Traffic Engineering for Complex Multi-domain Topology
図4：複雑なマルチドメイントポロジのトラフィックエンジニアリング
A solution for this scenario requires the gathering of NetFlow information, analysis of the source/destination autonomous system (AS), and determining what the main cause of the congested link(s) is. After this, the operator can use the external Border Gateway Protocol (eBGP) sessions to schedule the traffic among the different domains according to the solution described in the CCDR framework.
このシナリオのソリューションには、NetFlow情報の収集、送信元/宛先の自律システム（AS）の分析、および輻輳したリンクの主な原因の特定が必要です。この後、オペレーターは外部ボーダーゲートウェイプロトコル（eBGP）セッションを使用して、CCDRフレームワークで説明されているソリューションに従って、異なるドメイン間のトラフィックをスケジュールできます。
In more general situations, there is often temporal congestion within the service provider's network, for example, due to daily or weekly periodic bursts or large events that are scheduled well in advance. Such congestion phenomena often appear regularly, and if the service provider has methods to mitigate it, it will certainly improve their network operation capabilities and increase satisfaction for customers. CCDR is also suitable for such scenarios, as the controller can schedule traffic out of the congested links, lowering their utilization during these times. Section 4.5 describes the simulation results of this scenario.
より一般的な状況では、サービスプロバイダーのネットワーク内に一時的な輻輳が発生することがよくあります。たとえば、毎日または毎週の定期的なバーストや、かなり前もってスケジュールされた大きなイベントが原因です。このような輻輳現象は定期的に発生することが多く、サービスプロバイダーがそれを緩和する方法を持っている場合は、ネットワークの運用能力が確実に向上し、顧客の満足度が高まります。 CCDRはこのようなシナリオにも適しています。コントローラーは輻輳したリンクからのトラフィックをスケジュールし、これらの時間中の使用率を下げることができるためです。セクション4.5では、このシナリオのシミュレーション結果について説明します。
The following sections describe a specific case study to illustrate the workings of the CCDR algorithm with concrete paths/metrics, as well as a procedure for generating topology and traffic matrices and the results from simulations applying CCDR for E2E QoS (assured path and congestion elimination) over the generated topologies and traffic matrices. In all cases examined, the CCDR algorithm produces qualitatively significant improvement over the reference (OSPF) algorithm, suggesting that CCDR will have broad applicability.
次のセクションでは、具体的なパス/メトリックを使用したCCDRアルゴリズムの動作を説明する特定のケーススタディ、トポロジーとトラフィックマトリックスを生成する手順、およびE2E QoS（パスの保証と輻輳の解消）にCCDRを適用したシミュレーションの結果について説明します。生成されたトポロジーとトラフィックマトリックス。検討したすべてのケースで、CCDRアルゴリズムは、リファレンス（OSPF）アルゴリズムよりも質的に大幅に改善されており、CCDRは幅広い適用性を持っていることを示唆しています。
The structure and scale of the simulated topology is similar to that of the real networks. Multiple different traffic matrices were generated to simulate different congestion conditions in the network. Only one of them is illustrated since the others produce similar results.
シミュレートされたトポロジの構造とスケールは、実際のネットワークのものと似ています。ネットワーク内のさまざまな輻輳状態をシミュレートするために、複数の異なるトラフィックマトリックスが生成されました。他は同様の結果を生成するので、そのうちの1つだけが示されています。
In this section, we consider a specific network topology for case study: examining the path selected by OSPF and CCDR and evaluating how and why the paths differ. Figure 5 depicts the topology of the network in this case. There are eight forwarding devices in the network. The original cost and utilization are marked on it as shown in the figure. For example, the original cost and utilization for the link (1, 2) are 3 and 50%, respectively. There are two flows: f1 and f2. Both of these two flows are from node 1 to node 8. For simplicity, it is assumed that the bandwidth of the link in the network is 10 Mb/s. The flow rate of f1 is 1 Mb/s and the flow rate of f2 is 2 Mb/s. The threshold of the link in congestion is 90%.
このセクションでは、ケーススタディのために特定のネットワークトポロジについて検討します。OSPFとCCDRによって選択されたパスを調べ、パスがどのように、なぜ異なるかを評価します。図5は、この場合のネットワークのトポロジーを示しています。ネットワークには8つの転送デバイスがあります。図に示すように、元のコストと使用率がマークされています。たとえば、リンク（1、2）の元のコストと使用率はそれぞれ3％と50％です。 f1とf2の2つのフローがあります。これら2つのフローはどちらもノード1からノード8へのものです。簡単にするために、ネットワーク内のリンクの帯域幅は10 Mb / sであると想定しています。 f1の流量は1 Mb / sで、f2の流量は2 Mb / sです。輻輳状態のリンクのしきい値は90％です。
If the OSPF protocol, which adopts Dijkstra's algorithm (IS-IS is similar because it also uses Dijkstra's algorithm), is applied in the network, the two flows from node 1 to node 8 can only use the OSPF path (p1: 1->2->3->8). This is because Dijkstra's algorithm mainly considers the original cost of the link. Since CCDR considers cost and utilization simultaneously, the same path as OSPF will not be selected due to the severe congestion of the link (2, 3). In this case, f1 will select the path (p2: 1->5->6->7->8) since the new cost of this path is better than that of the OSPF path. Moreover, the path p2 is also better than the path (p3: 1->2->4->7->8) for flow f1. However, f2 will not select the same path since it will cause new congestion in the link (6, 7). As a result, f2 will select the path (p3: 1->2->4->7->8).
ダイクストラのアルゴリズム（IS-ISはダイクストラのアルゴリズムも使用するため、IS-ISも同様）を採用するOSPFプロトコルがネットワークで適用されている場合、ノード1からノード8への2つのフローはOSPFパスのみを使用できます（p1：1-> 2-> 3-> 8）。これは、ダイクストラのアルゴリズムが主にリンクの元のコストを考慮するためです。 CCDRはコストと使用率を同時に考慮するため、リンクの深刻な輻輳のため、OSPFと同じパスは選択されません（2、3）。この場合、このパスの新しいコストはOSPFパスのコストよりも優れているため、f1はパス（p2：1-> 5-> 6-> 7-> 8）を選択します。さらに、パスp2は、フローf1のパス（p3：1-> 2-> 4-> 7-> 8）よりも優れています。ただし、f2はリンクで新しい輻輳を引き起こすため、同じパスを選択しません（6、7）。その結果、f2はパスを選択します（p3：1-> 2-> 4-> 7-> 8）。
+----+ f1 +-------> +-----+ ----> +-----+
|Edge|-----------+ |+--------| 3 |-------| 8 |
|Node|---------+ | ||+-----> +-----+ ----> +-----+
+----+ | | 4/95%||| 6/50% |
| | ||| 5/60%|
| v ||| |
+----+ +-----+ -----> +-----+ +-----+ +-----+
|Edge|-------| 1 |--------| 2 |------| 4 |------| 7 |
|Node|-----> +-----+ -----> +-----+7/60% +-----+5/45% +-----+
+----+ f2 | 3/50% |
| |
| 3/60% +-----+ 5/55%+-----+ 3/75% |
+-----------| 5 |------| 6 |---------+
+-----+ +-----+
(a) Dijkstra's Algorithm (OSPF/IS-IS)
+----+ f1 +-----+ ----> +-----+
|Edge|-----------+ +--------| 3 |-------| 8 |
|Node|---------+ | | +-----+ ----> +-----+
+----+ | | 4/95% | 6/50% ^|^
| | | 5/60%|||
| v | |||
+----+ +-----+ -----> +-----+ ---> +-----+ ---> +-----+
|Edge|-------| 1 |--------| 2 |------| 4 |------| 7 |
|Node|-----> +-----+ +-----+7/60% +-----+5/45% +-----+
+----+ f2 || 3/50% |^
|| ||
|| 3/60% +-----+5/55% +-----+ 3/75% ||
|+-----------| 5 |------| 6 |---------+|
+----------> +-----+ ---> +-----+ ---------+
(b) CCDR Algorithm
Figure 5: Case Study for CCDR's Algorithm
図5：CCDRのアルゴリズムのケーススタディ
Moving on from the specific case study, we now consider a class of networks more representative of real deployments, with a fully linked core network that serves to connect edge nodes, which themselves connect to only a subset of the core. An example of such a topology is shown in Figure 6 for the case of 4 core nodes and 5 edge nodes. The CCDR simulations presented in this work use topologies involving 100 core nodes and 400 edge nodes. While the resulting graph does not fit on this page, this scale of network is similar to what is deployed in production environments.
特定のケーススタディからさらに進んで、実際の展開をより代表するネットワークのクラスを検討します。完全にリンクされたコアネットワークは、コアのサブセットのみに接続するエッジノードを接続するのに役立ちます。 4つのコアノードと5つのエッジノードの場合のこのようなトポロジの例を図6に示します。この作業で示されるCCDRシミュレーションは、100コアノードと400エッジノードを含むトポロジを使用します。結果のグラフはこのページに収まりませんが、このネットワークの規模は、実稼働環境に配置されているものと似ています。
+----+
/|Edge|\
| +----+ |
| |
| |
+----+ +----+ +----+
|Edge|----|Core|-----|Core|---------+
+----+ +----+ +----+ |
/ | \ / | |
+----+ | \ / | |
|Edge| | X | |
+----+ | / \ | |
\ | / \ | |
+----+ +----+ +----+ |
|Edge|----|Core|-----|Core| |
+----+ +----+ +----+ |
| | |
| +------\ +----+
| ---|Edge|
+-----------------/ +----+
Figure 6: Topology of Simulation
図6：シミュレーションのトポロジ
For the simulations, the number of links connecting one edge node to the set of core nodes is randomly chosen between two and thirty, and the total number of links is more than 20,000. Each link has a congestion threshold, which can be arbitrarily set, for example, to 90% of the nominal link capacity without affecting the simulation results.
シミュレーションの場合、1つのエッジノードをコアノードのセットに接続するリンクの数は2〜30の間でランダムに選択され、リンクの総数は20,000を超えます。各リンクには輻輳しきい値があり、シミュレーション結果に影響を与えることなく、たとえば、公称リンク容量の90％に任意に設定できます。
For each topology, a traffic matrix is generated based on the link capacity of the topology. It can result in many kinds of situations such as congestion, mild congestion, and non-congestion.
トポロジごとに、トポロジのリンク容量に基づいてトラフィックマトリックスが生成されます。混雑、穏やかな混雑、非混雑など、さまざまな状況が発生する可能性があります。
In the CCDR simulation, the dimension of the traffic matrix is 500*500 (100 core nodes plus 400 edge nodes). About 20% of links are overloaded when the Open Shortest Path First (OSPF) protocol is used in the network.
CCDRシミュレーションでは、トラフィックマトリックスの次元は500 * 500（100コアノードと400エッジノード）です。ネットワークでOpen Shortest Path First（OSPF）プロトコルを使用すると、リンクの約20％が過負荷になります。
The CCDR E2E path optimization entails finding the best path, which is the lowest in metric value, as well as having utilization far below the congestion threshold for each link of the path. Based on the current state of the network, the PCE within CCDR framework combines the shortest path algorithm with a penalty theory of classical optimization and graph theory.
CCDR E2Eパスの最適化では、メトリック値が最も低い最適なパスを見つけることと、パスの各リンクの輻輳しきい値をはるかに下回る使用率を得ることが必要になります。 CCDRフレームワーク内のPCEは、ネットワークの現在の状態に基づいて、最短経路アルゴリズムと古典的な最適化のペナルティ理論およびグラフ理論を組み合わせます。
Given a background traffic matrix, which is unscheduled, when a set of new flows comes into the network, the E2E path optimization finds the optimal paths for them. The selected paths bring the least congestion degree to the network.
スケジュールされていないバックグラウンドトラフィックマトリックスが与えられている場合、新しいフローのセットがネットワークに入ると、E2Eパス最適化はそれらの最適パスを見つけます。選択されたパスにより、ネットワークの混雑度が最小になります。
The link Utilization Increment Degree (UID), when the new flows are added into the network, is shown in Figure 7. The first graph in Figure 7 is the UID with OSPF, and the second graph is the UID with CCDR E2E path optimization. The average UID of the first graph is more than 30%. After path optimization, the average UID is less than 5%. The results show that the CCDR E2E path optimization has an eye-catching decrease in UID relative to the path chosen based on OSPF.
図7は、新しいフローがネットワークに追加されたときのUtilization Increment Degree（UID）リンクを示しています。図7の最初のグラフはOSPFを使用したUIDで、2番目のグラフはCCDR E2Eパス最適化を使用したUIDです。最初のグラフの平均UIDは30％を超えています。パスの最適化後、平均UIDは5％未満です。結果は、CCDR E2Eパスの最適化により、OSPFに基づいて選択されたパスに比べてUIDが目立って減少することを示しています。
While real-world results invariably differ from simulations (for example, real-world topologies are likely to exhibit correlation in the attachment patterns for edge nodes to the core, which are not reflected in these results), the dramatic nature of the improvement in UID and the choice of simulated topology to resemble real-world conditions suggest that real-world deployments will also experience significant improvement in UID results.
実際の結果は常にシミュレーションとは異なります（たとえば、実際のトポロジはエッジノードのコアへの接続パターンに相関があり、これらの結果には反映されません）、UIDの改善の劇的な性質また、シミュレーションされたトポロジを実際の条件に似せるように選択すると、実際のデプロイメントでもUIDの結果が大幅に改善されることがわかります。
+-----------------------------------------------------------+
| * * * *|
60| * * * * * *|
|* * ** * * * * * ** * * * * **|
|* * ** * * ** *** ** * * ** * * * ** * * *** **|
|* * * ** * ** ** *** *** ** **** ** *** **** ** *** **|
40|* * * ***** ** *** *** *** ** **** ** *** ***** ****** **|
UID(%)|* * ******* ** *** *** ******* **** ** *** ***** *********|
|*** ******* ** **** *********** *********** ***************|
|******************* *********** *********** ***************|
20|******************* ***************************************|
|******************* ***************************************|
|***********************************************************|
|***********************************************************|
0+-----------------------------------------------------------+
0 100 200 300 400 500 600 700 800 900 1000
+-----------------------------------------------------------+
| |
60| |
| |
| |
| |
40| |
UID(%)| |
| |
| |
20| |
| *|
| * *|
| * * * * * ** * *|
0+-----------------------------------------------------------+
0 100 200 300 400 500 600 700 800 900 1000
Flow Number
Figure 7: Simulation Results with Congestion Elimination
図7：輻輳除去のシミュレーション結果
During the simulations, different degrees of network congestion were considered. To examine the effect of CCDR on link congestion, we consider the Congestion Degree (CD) of a link, defined as the link utilization beyond its threshold.
シミュレーション中、さまざまな程度のネットワークの輻輳が考慮されました。リンクの輻輳に対するCCDRの影響を調べるために、リンクの輻輳度（CD）を考慮します。これは、しきい値を超えるリンク使用率として定義されます。
The CCDR congestion elimination performance is shown in Figure 8. The first graph is the CD distribution before the process of congestion elimination. The average CD of all congested links is about 20%. The second graph shown in Figure 8 is the CD distribution after using the congestion elimination process. It shows that only twelve links among the total 20,000 exceed the threshold, and all the CD values are less than 3%. Thus, after scheduling the traffic away from the congested paths, the degree of network congestion is greatly eliminated and the network utilization is in balance.
CCDR輻輳除去パフォーマンスを図8に示します。最初のグラフは、輻輳除去プロセス前のCD分布です。すべての混雑したリンクの平均CDは約20％です。図8に示す2番目のグラフは、輻輳解消プロセスを使用した後のCD分布です。合計20,000のうち12のリンクのみがしきい値を超え、すべてのCD値が3％未満であることを示しています。したがって、トラフィックを輻輳したパスから遠ざけるようにスケジュールした後、ネットワークの輻輳の程度が大幅に解消され、ネットワークの使用率がバランスします。
Before congestion elimination
+-----------------------------------------------------------+
| * ** * ** ** *|
20| * * **** * ** ** *|
|* * ** * ** ** **** * ***** *********|
|* * * * * **** ****** * ** *** **********************|
15|* * * ** * ** **** ********* *****************************|
|* * ****** ******* ********* *****************************|
CD(%) |* ********* ******* ***************************************|
10|* ********* ***********************************************|
|*********** ***********************************************|
|***********************************************************|
5|***********************************************************|
|***********************************************************|
|***********************************************************|
0+-----------------------------------------------------------+
0 0.5 1 1.5 2
After congestion elimination
+-----------------------------------------------------------+
| |
20| |
| |
| |
15| |
| |
CD(%) | |
10| |
| |
| |
5 | |
| |
| * ** * * * ** * ** * |
0 +-----------------------------------------------------------+
0 0.5 1 1.5 2
Link Number(*10000)
Figure 8: Simulation Results with Congestion Elimination
図8：輻輳除去のシミュレーション結果
It is clear that by using an active path-computation mechanism that is able to take into account observed link traffic/congestion, the occurrence of congestion events can be greatly reduced. Only when a preponderance of links in the network are near their congestion threshold will the central controller be unable to find a clear path as opposed to when a static metric-based procedure is used, which will produce congested paths once a single bottleneck approaches its capacity. More detailed information about the algorithm can be found in [PTCS].
観測されたリンクトラフィック/輻輳を考慮することができるアクティブなパス計算メカニズムを使用することにより、輻輳イベントの発生を大幅に削減できることは明らかです。ネットワーク内の多数のリンクが輻輳しきい値に近い場合にのみ、単一のボトルネックが容量に近づくと輻輳したパスを生成する静的メトリックベースの手順が使用される場合とは対照的に、中央コントローラーは明確なパスを見つけることができません。 。アルゴリズムの詳細については、[PTCS]を参照してください。
The above CCDR scenarios and simulation results demonstrate that a single general solution can be found that copes with multiple complex situations. The specific situations considered are not known to have any special properties, so it is expected that the benefits demonstrated will have general applicability. Accordingly, the integrated use of a centralized controller for the more complex optimal path computations in a native IP network should result in significant improvements without impacting the underlying network infrastructure.
上記のCCDRシナリオとシミュレーション結果は、複数の複雑な状況に対処する単一の一般的なソリューションが見つかることを示しています。検討されている特定の状況には特別な特性があることは知られていないため、実証された利点は一般的な適用性があると予想されます。したがって、ネイティブIPネットワークでのより複雑な最適パス計算のための集中型コントローラーの統合使用は、基盤となるネットワークインフラストラクチャに影響を与えることなく、大幅な改善をもたらすはずです。
For intra-domain or inter-domain native IP TE scenarios, the deployment of a CCDR solution is similar with the centralized controller being able to compute paths along with no changes being required to the underlying network infrastructure. This universal deployment characteristic can facilitate a generic traffic-engineering solution where operators do not need to differentiate between intra-domain and inter-domain TE cases.
ドメイン内またはドメイン間のネイティブIP TEシナリオの場合、CCDRソリューションの配置は同様であり、集中型コントローラーがパスを計算でき、基盤となるネットワークインフラストラクチャに変更を加える必要はありません。この普遍的な展開特性は、オペレーターがドメイン内とドメイン間のTEのケースを区別する必要がない一般的なトラフィックエンジニアリングソリューションを促進します。
To deploy the CCDR solution, the PCE should collect the underlying network topology dynamically, for example, via Border Gateway Protocol - Link State (BGP-LS) [RFC7752]. It also needs to gather the network traffic information periodically from the network management platform. The simulation results show that the PCE can compute the E2E optimal path within seconds; thus, it can cope with a change to the underlying network in a matter of minutes. More agile requirements would need to increase the sample rate of the underlying network and decrease the detection and notification interval of the underlying network. The methods of gathering this information as well as decreasing its latency are out of the scope of this document.
CCDRソリューションを展開するには、PCEが、たとえば、ボーダーゲートウェイプロトコル-リンク状態（BGP-LS）[RFC7752]を介して、基になるネットワークトポロジを動的に収集する必要があります。また、ネットワーク管理プラットフォームからネットワークトラフィック情報を定期的に収集する必要もあります。シミュレーション結果は、PCEが数秒以内にE2E最適パスを計算できることを示しています。したがって、基盤となるネットワークの変更に数分で対処できます。より機敏な要件では、基盤となるネットワークのサンプルレートを上げ、基盤となるネットワークの検出と通知の間隔を短くする必要があります。この情報を収集し、その待ち時間を短縮する方法は、このドキュメントの範囲外です。
This document considers mainly the integration of distributed protocols and the central control capability of a PCE. While it can certainly simplify the management of a network in various traffic-engineering scenarios as described in this document, the centralized control also brings a new point that may be easily attacked. Solutions for CCDR scenarios need to consider protection of the PCE and communication with the underlying devices.
このドキュメントでは、主に分散プロトコルの統合とPCEの中央制御機能について検討します。このドキュメントで説明されているように、さまざまなトラフィックエンジニアリングシナリオでネットワークの管理を確実に簡素化できますが、集中制御は、簡単に攻撃される可能性のある新しい点ももたらします。 CCDRシナリオのソリューションでは、PCEの保護と、基盤となるデバイスとの通信を考慮する必要があります。
[RFC5440] and [RFC8253] provide additional information.
[RFC5440]と[RFC8253]は追加情報を提供します。
The control priority and interaction process should also be carefully designed for the combination of the distributed protocol and central control. Generally, the central control instructions should have higher priority than the forwarding actions determined by the distributed protocol. When communication between PCE and the underlying devices is disrupted, the distributed protocol should take control of the underlying network. [PCE-NATIVE-IP] provides more considerations corresponding to the solution.
制御の優先順位と相互作用のプロセスも、分散プロトコルと中央制御の組み合わせのために注意深く設計する必要があります。一般に、中央制御命令は、分散プロトコルによって決定される転送アクションよりも高い優先度を持つ必要があります。 PCEと基盤となるデバイス間の通信が中断された場合、分散プロトコルが基盤となるネットワークを制御する必要があります。 [PCE-NATIVE-IP]は、ソリューションに対応するより多くの考慮事項を提供します。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[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>。
[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>。
[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>。
[PCE-NATIVE-IP] Wang, A., Zhao, Q., Khasanov, B., and H. Chen, "PCE in Native IP Network", Work in Progress, Internet-Draft, draft-ietf-teas-pce-native-ip-05, 9 January 2020, <https://tools.ietf.org/html/draft-ietf-teas-pce-native-ip-05>.
[PCE-NATIVE-IP] Wang、A.、Zhao、Q.、Khasanov、B。、およびH. Chen、「ネイティブIPネットワークのPCE」、作業中、インターネットドラフト、draft-ietf-teas-pce -native-ip-05、2020年1月9日、<https://tools.ietf.org/html/draft-ietf-teas-pce-native-ip-05>。
[PCEP-NATIVE-IP-EXT] Wang, A., Khasanov, B., Fang, S., and C. Zhu, "PCEP Extension for Native IP Network", Work in Progress, Internet-Draft, draft-ietf-pce-pcep-extension-native-ip-05, 17 February 2020, <https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-native-ip-05>.
[PCEP-NATIVE-IP-EXT] Wang、A.、Khasanov、B.、Fang、S。、およびC. Zhu、「ネイティブIPネットワークのPCEP拡張機能」、作業中、インターネットドラフト、draft-ietf- pce-pcep-extension-native-ip-05、2020年2月17日、<https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-native-ip-05>。
[PTCS] Zhang, P., Xie, K., Kou, C., Huang, X., Wang, A., and Q. Sun, "A Practical Traffic Control Scheme With Load Balancing Based on PCE Architecture", DOI 10.1109/ACCESS.2019.2902610, IEEE Access 18526773, March 2019, <https://ieeexplore.ieee.org/document/8657733>.
[PTCS] Zhang、P.、Xie、K.、Kou、C.、Huang、X.、Wang、A。、およびQ. Sun、「PCEアーキテクチャに基づくロードバランシングを使用した実用的なトラフィック制御方式」、DOI 10.1109 /ACCESS.2019.2902610、IEEE Access 18526773、2019年3月、<https://ieeexplore.ieee.org/document/8657733>。
[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>。
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8402] Filsfils、C。、編、Previdi、S。、編、Ginsberg、L.、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、RFC 8402、DOI 10.17487 / RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", RFC 8578, DOI 10.17487/RFC8578, May 2019, <https://www.rfc-editor.org/info/rfc8578>.
[RFC8578] Grossman、E.、Ed。、「Deterministic Networking Use Cases」、RFC 8578、DOI 10.17487 / RFC8578、2019年5月、<https://www.rfc-editor.org/info/rfc8578>。
Acknowledgements
謝辞
The authors would like to thank Deborah Brungard, Adrian Farrel, Huaimo Chen, Vishnu Beeram, and Lou Berger for their support and comments on this document.
このドキュメントに対するサポートとコメントを提供してくれたDeborah Brungard、Adrian Farrel、Huaimo Chen、Vishnu Beeram、Lou Bergerに感謝します。
Thanks to Benjamin Kaduk for his careful review and valuable suggestions on this document. Also, thanks to Roman Danyliw, Alvaro Retana, and Éric Vyncke for their reviews and comments.
このドキュメントに関する慎重なレビューと貴重な提案を提供してくれたBenjamin Kadukに感謝します。また、レビューとコメントを提供してくれたRoman Danyliw、Alvaro Retana、ÉricVynckeにも感謝します。
Contributors
貢献者
Lu Huang contributed to the content of this document.
Lu Huangがこのドキュメントの内容に貢献しました。
Authors' Addresses
著者のアドレス
Aijun Wang China Telecom Beiqijia Town, Changping District Beijing Beijing, 102209 China
AI Jun Wang中国テレコムB EI将来価格の町、チャンスクリーン地区北京北京、102209中国
Email: wangaj3@chinatelecom.cn
Xiaohong Huang Beijing University of Posts and Telecommunications No.10 Xitucheng Road, Haidian District Beijing China
Xiaohong Huang北京郵電大学第10号Xidcheng Road、海淀区北京中国
Email: huangxh@bupt.edu.cn
Caixia Kou Beijing University of Posts and Telecommunications No.10 Xitucheng Road, Haidian District Beijing China
Caixia Kou北京郵電大学第10号Xitucheng Road、海淀区北京中国
Email: koucx@lsec.cc.ac.cn
Zhenqiang Li China Mobile 32 Xuanwumen West Ave, Xicheng District Beijing 100053 China
Zは非常に強力ですl i China Mobile 32 X u Press No Door West Av、ξはDistrict Beijing 100053 Chinaになります
Email: li_zhenqiang@hotmail.com
Penghui Mi Huawei Technologies Tower C of Bldg.2, Cloud Park, No.2013 of Xuegang Road Shenzhen Bantian,Longgang District, 518129 China
Penghui Mi Huawei Technologies Tower C of Bldg.2、Cloud Park、No.2013 of Xuegang Road Shenzhen Bantian、Longgang District、518129 China
Email: mipenghui@huawei.com