JP7313480B2 - スライスベースネットワークにおける輻輳回避 - Google Patents

Description

今日の３Ｇ、４Ｇ、およびＬＴＥネットワークは、クラウド全体に分散可能な複数のデータセンタ（「ＤＣ」）を用いて動作する。これらのネットワークは、わずか数台の運用支援システム（「ＯＳＳ：Ｏｐｅｒａｔｉｎｇ Ｓｕｐｐｏｒｔ Ｓｙｓｔｅｍ」）およびネットワークオペレーションセンタ（「ＮＯＣ：Ｎｅｔｗｏｒｋ Ｏｐｅｒａｔｉｏｎｓ Ｃｅｎｔｅｒ」）によって中央管理される。５Ｇ技術は、Ｔｅｌｃｏネットワークへの接続および物理ネットワークリソースの共有が必要となるあらゆる種類のデバイスに対するネットワーク接続性を大幅に増大させることになる。現行のネットワークアーキテクチャは、これらの需要を満たすようにはスケーリングし得ない。

ネットワークスライシングは、共有物理ネットワークインフラ上での複数の論理ネットワークの動作を可能にする仮想化の一形態である。分散クラウドネットワークがさまざまなスライスによってネットワークリソースを共有して、テナントと称する異なるユーザの単一の物理インフラ上での多重化を可能にし得る。たとえば、インターネット・オブ・シングス（「ＩｏＴ」）デバイス、モバイルブロードバンドデバイス、および低レイテンシ車載デバイスはすべて、５Ｇネットワークの共有が必要となる。これらの異なる使用事例は、異なる伝送特性および要件を有することになる。たとえば、ＩｏＴは通常、多数のデバイスを有するものの、スループットは非常に低い。モバイルブロードバンドはその反対に、各デバイスが高帯域コンテンツを送受信する。ネットワークスライシングは、物理ネットワークのエンドツーエンドレベルでの分割によって、トラフィックのグループ化、テナントトラフィックの隔離、およびマクロレベルでのネットワークリソースの設定を可能にし得る。

しかしながら、サービス品質（「ＱｏＳ」）および輻輳回避に関する従来の手法は、スライスベースネットワークにより可能となるネットワーク使用の大幅な増大に対応するようには容易にスケーリングしない。たとえば、ネットワークに輻輳が生じている場合、既存のソリューションは、輻輳源を抑制し、データ伝送を効果的に遅らせて帯域幅を解放する。たとえば、プライオリティフロー制御（「ＰＦＣ：Ｐｒｉｏｒｉｔｙ Ｆｌｏｗ Ｃｏｎｔｒｏｌ」）のような既存のフロー制御メカニズムは、上流のスイッチ（たとえば、ルータ）に輻輳を通知して、スイッチを通じてトラフィックを送っているホスト等の輻輳源においてトラフィックを抑制することにより輻輳を抑える。しかし、スライスベースネットワークは、抑制が他のスライスに悪影響を及ぼして、ソフトウェアライセンス契約（「ＳＬＡ：Ｓｏｆｔｗａｒｅ Ｌｉｃｅｎｓｅ Ａｇｒｅｅｍｅｎｔ」）の下で可能なスライスの性能を下回る可能性があるため、効率が悪い。ＳＬＡ要件に違反しない新たなスライスベースソリューションが求められている。

スライスベースネットワークにおいては、レイテンシおよびスループット等の重要な性能基準を正確にモニタリングすることが特に課題である。従来のネットワークにおいては、任意の２つのエンドポイント間でｐｉｎｇ等のプローブパケットを送ることにより、ソフトウェアでレイテンシを計算可能である。ただし、ソフトウェアベースのモニタリングプローブは、数千万のユーザを抱える大規模なＴｅｌｃｏネットワークにおいてはスケーリングしない。一般的に、スライスの仮想ネットワーク機能（「ＶＮＦ：Ｖｉｒｔｕａｌ Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ」）等を用いて仮想レイヤで輻輳を検出することは、スケーラブルでないため、下層の物理ハードウェアを急速に圧迫することになる。

輻輳を緩和する別の方法がなければ、ネットワークインフラが過負荷となった場合に、重要なスライスが悪影響を受ける可能性がある。ＳＬＡでは、とりわけ９１１番通報および自動運転車との通信等の重要なトラフィックの確実な伝送が求められることが多い。

結果として、スライスベースネットワークにおける輻輳を緩和するシステムが求められている。

本明細書に記載の例は、スライスベースネットワークにおいて輻輳を緩和するシステムおよび方法を含む。このシステムは、ルータまたはサーバ等の物理デバイス上のエージェントと通信するモニタリングモジュールを具備し得る。ネットワークは、スライスへの分割によって、１つまたは複数のテナントに対する異なる使用事例に対応可能である。各スライスは、レイテンシ、帯域幅、ラウンドトリップタイム、およびその他の閾値レベル等の所要ＳＬＡ性能属性を有し得る。

仮想サービスネットワーク（「ＶＳＮ：Ｖｉｒｔｕａｌ Ｓｅｒｖｉｃｅ Ｎｅｔｗｏｒｋ」）における各ネットワークスライスは、電話、車両、およびＩｏＴデバイス等の複数の端末デバイスからデータを搬送可能である。たとえば、９１１スライスは、数千のモバイルデバイスからの通報を一度に搬送可能である。ＹＯＵＴＵＢＥ（登録商標）スライスでも同じ事例が存在し得るが、ここでは数十万のモバイルユーザがＹＯＵＴＵＢＥビデオを同時に視聴可能である。各スライスは、当該スライス内の異なる特殊機能に対して異なるＶＮＦを有し得る。ただし、ＶＮＦによって一部の性能基準をモニタリングすることは、スケーラブルでない。

一例においては、下層のスイッチ上でエージェントを動作させることにより、一部のモニタリングタスクが物理レイヤにオフロードされる。エージェントは、トラフィックを解析して、テレマティクスデータを報告としてモニタリングモジュールに返すことができる。一例において、モニタリングモジュールは、エージェントをスイッチに供給可能であり、これはプログラム可能となり得る。一例において、スイッチは、Ｐ４言語またはその他何らかのプロトコルを用いてプログラム可能なＴＯＦＩＮＯチップ等のプログラム可能ネットワーキング特定用途向け集積回路（「ＡＳＩＣ」）を含む。

スイッチは、プログラムされると、仮想レイヤではなく物理レイヤにおいてエージェントを実行可能である。スイッチ上のエージェントは、テレマティクスデータをモニタリングモジュールに報告することができる。テレマティクスデータは、スライス固有とすることにより、スライスの何らかの性能特性を示すことができる。各スイッチは、それが取り扱うスライスのテレマティクスデータを報告可能である。テレマティクスデータは、レイテンシ、帯域幅、およびラウンドトリップタイム等のスライスの任意の性能基準と関連し得る。

モニタリングモジュールは、ネットワーク接続性グラフの保持または読み出しによって、スライスベースネットワーク全体でスイッチに対するコンパイル済みテレマティクスデータを追跡可能である。また、モニタリングモジュールは、ネットワーク接続性グラフ中の１つまたは複数のスイッチに基づいて、スライスがＳＬＡ要件を満たしていないものと判定することができる。この判定は、当該スライスのスライス経路全体でのテレマティクスデータに基づき得る。一例において、性能データとも称するテレマティクスデータは、平均化等の経時的なコンパイルが可能であるとともに、ＳＬＡ閾値と比較可能である。

ＳＬＡが満たされていないことに基づいて、モニタリングモジュールは、代替スライス経路を選択することにより、輻輳を抑えることができる。たとえば、ネットワーク接続性グラフは、性能基準に優れた別の考え得るルートを示し得る。代替スライス経路は、当該スライスの既存のスライス経路にない少なくとも１つのスイッチを含み得る。モニタリングモジュールは、選択した代替スライス経路を実装することにより、第１のスイッチが元のスライス経路における第２のスイッチの代わりに第３のスイッチに対してトラフィックを送るように、ルーティングを変更可能である。これにより、単にすべてのスライスを同じ経路でルーティングするのではなく、ネットワーク全体にスライストラフィックを分散させることによって、輻輳を抑えることができる。

一例において、代替スライス経路は、ＳＬＡ要件を下回るレイテンシ値に基づいて選択可能である。たとえば、モニタリングモジュールは、複数のスライスの複数の物理スイッチから、パケットタイミング情報を受信可能である。スイッチの物理領域で動作するエージェントは、パケットタイミング情報を送ることができる。モニタリングモジュールは、パケットタイミング情報に基づき、スイッチから受信したパケットタイミング情報の複数の異なるインスタンスの平均化等により、レイテンシ値を決定することができる。レイテンシ値と閾値との比較に基づいて、モニタリングモジュールは、スライスの代替スライス経路を選択可能であって、この代替スライス経路は、当該スライスの現在のスライス経路にないスイッチを含む。その後、モニタリングモジュールは、代替スライス経路を実装可能であって、これは、次のホップが正しくなるように新たなスライス経路でスイッチを更新することを含み得る。

一例において、代替スライス経路は、ＳＬＡ要件を下回るスループットに基づいて選択可能である。モニタリングモジュールは、第１のスライスのスライス経路におけるスイッチから、データレート情報を受信可能である。データレート情報は、モニタリングモジュールによるデータレートと特定のスライスとの相関を可能にするスライス識別子に対応し得る。モニタリングモジュールは、受信したデータレート情報に基づいて、第１のスライスのアグリゲートスループットを決定することができる。アグリゲートスループットと閾値との比較に基づいて、モニタリングモジュールは、第１のスライスの代替スライス経路を実装可能である。

これらのステージは、いくつかの例において、オーケストレーションシステムの一部として実行されるモニタリングモジュールにより実行可能である。あるいは、命令を含む非一過性コンピュータ可読媒体によって、プロセッサが命令を実行した場合に、当該プロセッサに上記ステージを実行させることができる。用語「スイッチ（ｓｗｉｔｃｈ）」は、サーバまたはルータ等、ネットワーク機能を実行する任意のデバイスを広義に表し得る。

以上の概要および以下の詳細な説明は、いずれも例示かつ説明を目的としているに過ぎず、上記例に限定されるものではなく、特許請求の範囲に記載の通りである。

ＶＳＮにおいてスライスの輻輳を抑える例示的な方法のフローチャートである。 ＶＳＮにおけるスライスレイテンシに基づいて輻輳を抑える例示的な方法のフローチャートである。 ＶＳＮにおけるスライススループットに基づいて輻輳を抑える例示的な方法のフローチャートである。 ＶＳＮにおいてスライスの輻輳を抑える例示的なシーケンス図である。 レイテンシに基づいて、ＶＳＮにおいてスライスの輻輳を抑える例示的なシーケンス図である。 スループットに基づいて、ＶＳＮにおいてスライスの輻輳を抑える例示的なシーケンス図である。 スライスベースネットワークにおける輻輳抑制の例示的なフローチャートである。 ＶＳＮにおける複数のスライスを示した例示的なシステム図である。 ＶＳＮにおける複数のスライスを示した例示的なシステム図である。 スライススループットを計算する例示的なフローチャートである。 ＶＳＮのトポロジの例示的なシステム図である。

以下、添付の図面に示す例を含めて、本例を詳しく参照する。図面全体を通して、同一または同様の部分を表すのに、可能な限り同じ参照番号を使用する。
一例において、システムは、スライスベースネットワークにおける複数のスイッチから、レイテンシまたはスループットと関連する性能データ等のテレマティクスデータを受信するモニタリングモジュールを具備する。スイッチ上の物理レイヤにおいて実行されるエージェントは、テレマティクスデータを報告可能である。モニタリングモジュールは、ネットワーク接続性グラフ上で性能を追跡し、１つまたは複数のスライスに対してＳＬＡ要件が満たされないタイミングを決定することができる。

ネットワーク接続性グラフにおけるスイッチに対するスライス性能に基づいて、モニタリングモジュールは、スライスの新たなスライス経路を選択して、スライスを再びＳＬＡ準拠とすることができる。スライスは、ネットワークの仮想オーバーレイおよび物理オーバーレイの両者にエレメントを含むことができ、潜在的には複数のクラウドに及ぶ可能性がある。スライシングによれば、プロバイダは、Ｔｅｌｃｏネットワークをセグメント化して複数のテナントにより使用可能とすることができ、各テナントは、それぞれＳＬＡ要件によって管理される自身のスライスを有し得る。

スライスは、ＶＳＮにおける１つまたは複数のクラスタまたはクラウドに及ぶ可能性がある。オーケストレータは、特定の目的での使用またはテナントへの貸与が可能なネットワーク内の複数のスライスを管理することができる。たとえば、スライスは、特定のアプリケーション、ＩｏＴデバイス、または顧客に対して予約可能である。各スライスとしては、１つまたは複数のＴｅｌｃｏクラウドにわたって分散した共有物理ネットワークインフラ上で動作する仮想ネットワークが挙げられる。スライスは、特定のネットワークタスクを実行するＶＮＦのサービスチェーンを含み得る。ＶＮＦの所要の組み合わせは、ビデオストリーミングまたはＩｏＴデバイス管理等、スライスの使用目的に基づいて異なり得る。スライスは、特定の種類のトラフィックに対して予約可能であるとともに、ＱｏＳ目的等で優先可能である。ＳＬＡは、スライスに必要な性能基準を規定するとともに、異なるスライスの所要性能基準を特定することができる。性能基準は、所与のスライスの使用目的に応じて異なり得る。また、ＳＬＡまたは別個のスライスレコードによって、サービスチェーンを構成するＶＮＦを特定可能である。

スライスをインスタンス化するため、ＶＮＦは、スライス経路全体に配置可能である。スライス経路は、プロバイダの分散ネットワークの部分集合を表し得るとともに、１つまたは複数のスイッチに及ぶ可能性がある。トラフィックが同じ宛先に向かっている場合であっても、異なるスライスが当該トラフィックを別々にルーティングすることができる。物理スイッチおよびＶＮＦは、ネットワーク中の異なる区域に及ぶ可能性があるため、スライスが宛先までの異なる経路をたどり得るとともに、作業負荷をネットワーク全体に対して効果的に分散可能である。

物理スイッチは、テレマティクスデータをモニタリングモジュールに送ることができる。モニタリングモジュールとしては、オーケストレータまたは別個のプロセスの一部が挙げられる。一例において、オーケストレータおよびモニタリングモジュールは、サーバの管理クラスタ上でホスティング可能である。一例において、物理スイッチは、ハードウェアレベルでパケットをモニタリングするエージェントを実行するようにプログラムされている。たとえば、エージェントは、ＶＮＦが実行される仮想レイヤではなく、スイッチのコアにおいて動作し得る。エージェントは、スライスに基づいてスイッチにトラフィックをルーティングさせることができる。また、エージェントは、テレマティクスデータをモニタリングモジュールに報告することができる。一例において、スイッチは、Ｐ４言語またはその他何らかのプロトコルを用いてプログラム可能なＴｏｆｉｎｏチップ等のプログラム可能ネットワーキングＡＳＩＣを使用可能である。一例において、モニタリングモジュールは、エージェントを使用するようにスイッチをプログラム可能である。

モニタリングモジュールは、さまざまなスライスに対して期待されるようにネットワークが機能していることを確実にし得る。また、モニタリングモジュールは、スイッチがスライスに基づいてパケットを異なる次ホップに送れるようにするスライス経路をスイッチに与え得る。次ホップとしては、スライス経路の別のスイッチが挙げられる。これにより、ネットワークにおける低輻輳のルート全体で優先スライスを設定可能となる。スイッチ内およびネットワーク全体でのスライス経路選択におけるパケット優先度に基づいて、輻輳を抑えることができる。

図１は、モニタリングモジュールにより実行されるステージを含む例示的な方法である。ステージ１０５において、モニタリングモジュールは、複数の物理スイッチから、スライス固有のテレマティクスデータを受信可能である。テレマティクスデータとしては、スイッチへとルーティングされるスライスに関する任意の性能データが挙げられる。一例において、スイッチは、モニタリングモジュールと通信するエージェントを実行するようにプログラム可能である。エージェントは、スライス固有のテレマティクスデータを定期的に報告することも可能であるし、モニタリングモジュールによって定期的にポーリングすることも可能である。テレマティクスデータは、スイッチレイテンシ、スライスレイテンシ、総ラウンドトリップタイム、スライス帯域幅、およびスイッチ帯域幅等の性能属性を含み得る。

ステージ１１０において、モニタリングモジュールは、性能がスライスのＳＬＡ要件を満たせないかを判定可能である。サービスプロバイダのテナントは、ネゴシエーションを行って、ＳＬＡに概要が記載されている特定の性能要件を取り換えることができる。サービスプロバイダは、これらのＳＬＡ要件が満たされていることを確実にする必要がある。これは特に、ＳＬＡ要件がテナントとの契約関係の基礎となり得るためである。

一例においては、ＳＬＡ要件が満たされるように、モニタリングモジュールは、スライスごとにテレマティクスデータを集約した後、データとスライス固有のＳＬＡ要件とを比較することができる。一例において、テレマティクスデータは、スライス識別子を含み、モニタリングモジュールがスライスごとの解析を実行できるようにし得る。また、一例において、モニタリングモジュールは、スライスに対応する物理レイヤ中のスイッチのグラフを保持し得る。これにより、モニタリングモジュールは、スライスの性能の決定に使用するテレマティクスデータを決定することが可能となり得る。

一例としては、第１のスライスがレイテンシおよび帯域幅のＳＬＡ要件を有し得る。モニタリングモジュールは、第１のスライスに関連するスイッチから性能基準を収集可能であり、これらの基準は、レイテンシ、帯域幅、または両者に関連し得る。モニタリングモジュールは、これらの性能基準がある期間にわたってＳＬＡ要件を下回る場合に、ＳＬＡが満たされていないものと判定することができる。

その結果、ステージ１１５において、モニタリングモジュールは、スライスの代替スライス経路を選択可能である。代替スライス経路は、既存のスライス経路の一部ではない新たなスイッチ等、物理レイヤを通る新たな経路を含み得る。モニタリングモジュールは、ネットワーク接続性グラフに基づいて、代替スライス経路を選択可能である。このグラフは、スライスが現時点で満たしていないＳＬＡ要件に関してより有利な性能を示す他のスイッチのテレマティクスデータを含み得る。たとえば、新たなスイッチからのテレマティクスデータは、スライス経路中の既存のスイッチではなく、新たなスイッチへとスライスがルーティングされる場合にレイテンシおよび帯域幅が改善されることを示し得る。

ステージ１２０において、モニタリングモジュールは、代替スライス経路を実装可能である。これは、メッセージを第１のスイッチに送って、第１のスイッチにおけるスライス経路情報を更新することを含み得る。元のスライス経路情報がスライスの次ホップの第２のスイッチを示し得る一方、更新スライス経路情報は、次ホップとして第３のスイッチを示すことができる。また、モニタリングモジュールまたはその他何らかのオーケストレーションプロセスは、必要に応じて、第３のスイッチで１つまたは複数のＶＮＦをインスタンス化することができる。スライスが物理レイヤおよび仮想レイヤの両者で動作し得ることから、モニタリングモジュールは、仮想レイヤにおけるＶＮＦ可用性によって、物理レイヤにおけるスライス経路の切り替えを調整することができる。

スライス経路の変更によって、ネットワークの輻輳を低減可能である。モニタリングモジュールは、物理ネットワークの利用可能な部分にわたってスライスを分散させるのに役立ち得る。使用されるスイッチは、１つまたは複数のクラスタまたはクラウドに及ぶことで、過負荷のスイッチの負荷を低減可能である。

図１Ｂは、レイテンシ要件に基づいて輻輳を抑える例示的な方法を示している。レイテンシは、多様な顧客にとって、重要なＳＬＡ要件となり得る。たとえば、９１１番通報のスライスは、レイテンシを可能な限り低くする必要がある。モニタリングモジュールがそのスライスについて大きなレイテンシタイムを検出した場合、一例において、モニタリングモジュールはＶＳＮトポロジを解析して、代替となる低レイテンシ経路を計算することができる。

ステージ１２５において、モニタリングモジュールは、複数のスイッチから、パケットタイミング情報を受信可能である。パケットタイミング情報としては、スライス固有のものが挙げられる。一例において、タイミング情報は、パケットがホップを構成した時点でエージェントにより収集されたタイムスタンプである。一例において、スイッチは、ワイヤスピードでパケットのリクエスト‐応答時間を追跡することができる。複数のスイッチにわたってパケットを追跡可能であり、それぞれによって、タイミング情報が報告されてレイテンシの決定に用いられる。

以下の表１は、さまざまなパケットタイプについて、リクエストおよび応答の例示的な種類を示している。

インターネット制御メッセージプロトコル（「ＩＣＭＰ：Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ」）およびアドレス解決プロトコル（「ＡＲＰ：Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ」）パケットは、プロトコルヘッダに基づいて追跡可能である。一例においては、伝送制御プロトコル（「ＴＣＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ」）パケットを追跡するため、スイッチは、緊急フラグ等のフラグをパケットに設定するとともに、当該パケットからの確認応答を追跡することができる。

各スイッチは、異なるスライスに対応するさまざまな一意のフローについて、タイミング情報を決定可能である。たとえば、スライスは、異なるフローに対して、複数の異なる入力点を有し得る。ＹＯＵＴＵＢＥトラフィックは、たとえばサンフランシスコおよびマイアミの両者においてスライスに合流可能であり、２つの異なるフローとなる。これらのフローは、パケットヘッダに基づいて決定可能である。たとえば、パケットヘッダは、送信元インターネットプロトコル（「ＩＰ」）アドレス、宛先ＩＰアドレス、送信元ポート、および宛先ポートを含み得る。スイッチは、これらの情報を用いて、スライスに対応する一意のフローを識別することができる。フローのパケットが追跡されている場合は、各スイッチから報告されたタイミング情報をモニタリングモジュールが使用することにより、レイテンシを決定することができる。

以下の表２の疑似コードは、スイッチ上のエージェントがパケットのタイミング情報を決定し得る様子の一例である。

表２に示すように、ＩＣＭＰまたはＡＲＰパケットについて、リクエストは、スイッチ上のエージェントにパケットの現在時間を記憶させ得る。応答が戻ってきたら、スイッチは、その時間を同様に取り込み可能である。その後、スイッチは、リクエストと応答との時間差を計算し、結果をスライスＩＤのＲＴＴとして返すことができる。

スイッチがＲＴＴを計算する方法は、さまざまなパケットタイプについて異なり得る。より詳細には、各パケットＰについて、プロトコルタイプ（「ｐｒｏｔｏＴｙｐｅ」）が確認される。ＩＣＭＰについて、パケットがリクエストの一部である場合（たとえば、「ｉｓＲｅｑｕｅｓｔ」が真の場合）、スイッチは、スライスＩＤ、送信元ＩＰアドレス（「ｓｉｐ」）、宛先ＩＰアドレス（「ｄｉｐ」）、および現在時間を格納することができる。ＩＣＭＰパケットが返送である場合、スイッチは、現在時間と過去に格納した時間との差を決定することができる。この値は、ＲＴＴを表し得るものであり、スライスＩＤ、ｓｉｐ、およびｄｉｐについて更新可能である。一例においては、ＲＴＴ値をモニタリングモジュールに送ることができる。

ＡＲＰパケットについて、リクエストが認識される場合（たとえば、「ｉｓＲｅｑｕｅｓｔ」が真の場合）は、スライスＩＤおよび送信元ＭＡＣアドレス（「ｓｍａｃ」）に関連して、パケットの現在時間が格納される。ＡＲＰパケットがリクエストでない場合、これは、ＡＲＰパケットが応答であることを意味し得る。この場合、応答は、エージェントにラウンドトリップタイム（「ＲＴＴ」）で格納情報を更新させ得る。これをスライスのタイミング情報としてモニタリングモジュールに報告可能である。

ＴＣＰパケットについて、エージェントは、転送フローパケットと返送パケットとの時間差に基づいて、ＲＴＴを計算することができる。たとえばユーザがビデオを開き、ビデオがアクセスされた宛先に向かってフローが延びる場合に、転送フローが生成され得る。その後、ビデオは宛先から戻り得るが、これは返送パケットを含む。

より詳細に、エージェントはまず、直近フローのテーブルを確認して、パケットが転送フロー（「ｆｏｒＦｌｏｗ」）に対応するかを判定するよう試み得る。このテーブルは、送信元ＩＰアドレス（「ｓｉｐ」）、宛先ＩＰアドレス（「ｄｉｐ」）、送信元ポート（「ｓｉｐ」）、および宛先ポート（「ｄｐｏｒｔ」）に基づいて、直近フローを格納可能である。この情報に基づいて、エージェントは、フローテーブルを確認して、フローが既に識別され、転送フローからのタイムスタンプとともに格納されていることを確かめることができる。転送フローが認識される場合（たとえば、「ｆｏｒＦＬｏｗが有効」）は、現在のパケットは、エージェントが当該転送フローのタイムスタンプを取得可能である（「ｆｏｒＦＬｏｗ－＞ｔｉｍｅＳｔａｍｐ」）。また、エージェントは、現在時間を取得し（「ｇｅｔＴｉｍｅ（）」）、タイムスタンプを差し引いてＲＴＴを決定することができる。エージェントは、この値を用いて、スライスのＲＴＴを更新することができる（たとえば、「ｕｐｄａｔｅＳｌｉｃｅＲｔｔ（ｓｌｉｃｅＩＤ，ｒｔｔ）」）。

その後、エージェントは、将来的にＲＴＴを決定するための新たなタイムスタンプが得られるように、転送フローを一掃することができる。一例において、これは、フローテーブルからの転送フロー（「ｆｏｒＦｌｏｗ」）の削除を含み得る。別の例においては、転送フローに対してＲＴＴが既に計算されたことを示す値がフローテーブルに設定される。これにより、当該フローの将来的な探索において「ｆｏｒＦｌｏｗ」を無効化することができ、ＲＴＴが将来的に測定される場合、フローテーブルにおいて当該フローの別のタイムスタンプを生成することが可能となる。

モニタリングモジュールは、ＴＣＰパケットを用いてＲＴＴを測定したい場合、スイッチ上のエージェントにより認識されるフラグをパケットヘッダに設定することができる。エージェントは、たとえばＴＣＰパケットに設定されたこれらのフラグに基づいて、転送フローを記録することができる。一例においては、これにより定期的なＲＴＴテストが可能となり得る。表１の疑似コードに示すように、転送フローが有効でない場合は、パケットＰの確認によって、特定のフラグがゼロに等しくないことを確かめる。たとえば、アプリケーションによって、緊急フラグ（「ＵＲＧ」）、ＳＹＮフラグ、またはＰＳＨフラグを設定可能である。これらのフラグの使用によって新たなフローを識別可能であり、ＲＴＴの計算を目的として、このフローをフローテーブルに追加可能である。

ＴＣＰヘッダ中のＵＲＧフラグは、パケットが遅延なく配信される必要があることを示し得る。ＳＹＮフラグは、クライアントとサーバとの間でＴＣＰ接続が開始となった場合に設定され得る。ＰＳＨフラグは、バッファリングデータのアプリケーションに対するプッシュをクライアントおよびサーバに命じ得る。

スイッチは、ＲＴＴの計算を目的として、これらのフラグを追跡可能である。たとえば、受信側は、これらのフラグのいずれかが設定された場合、直ちに応答を送ることができる。これらのフラグのいずれもがＴＣＰパケットに存在しない場合、受信側は、到着データをバッファリングし、あとで応答するようにしてもよいが、このようなパケットはＲＴＴの計算に不適となる。たとえば、送信側が一度に１バイトのＴＣＰパケットを送る場合、この１バイトを直ちにアプリケーションへ送る代わりに、受信側のＴＣＰスタックは、データをバッファに格納するようにしてもよい。受信側は、さらに数個のパケットの到着を待って、アプリケーションに、より大きなデータ集合を通知するようにしてもよい。このように、データがバッファリングされる場合は、応答の遅延の可能性がある。その結果、一例においては、バッファリングによって結果が歪むため、レイテンシの正確な計算にバッファリングパケットを使用することができない。このシステムは、ＵＲＧ、ＳＹＮ、およびＰＳＨフラグを確認することによって、レイテンシの計算にバッファリング関連の遅延が入らないようにすることができる。

表１において、「ｃｒｅａｔｅＦｌｏｗ」は、パケットのｄｉｐ、ｓｉｐ、ｄｐｏｒｔ、およびｓｐｏｒｔに基づく新たなフローの格納を可能にする。この新たなフロー（「ｒｅｖＦｌｏｗ」）には、現在時間を読み出すｇｅｔＴｉｍｅ（）等の呼び出しに基づきタイムスタンプが与えられ得る。その後、返信パケットがスイッチで受信された場合は、同じパケット情報（ｓｉｐ、ｄｉｐ、ｓｐｏｒｔ、ｄｐｏｒｔ）の使用により、フロー（「ｆｏｒＦｌｏｗ」）を取得可能である。このフローは有効なものとして検出可能であり、現在時間からタイムスタンプが差し引かれてＲＴＴが決定される。

一例において、各ホップでは、各スイッチがこのタイミング情報を記録し、それをモニタリングモジュールに報告してレイテンシの決定に使用することができる。
ステージ１３０において、モニタリングモジュールは、レイテンシ値を決定可能である。一例において、これは、スライス上の各ホップからのパケットのタイミング情報を合算してスライスＲＴＴを決定することを含み得る。別の例において、モニタリングモジュールは、ある期間にわたるスライスのＲＴＴ情報を平均化あるいは集約する。一例においては、この集約値をスライスレイテンシ値として使用可能である。

ステージ１３５において、モニタリングモジュールは、レイテンシ値とＳＬＡ閾値とを比較可能である。モニタリングモジュールは、ＳＬＡのスライス固有の閾値に対してレイテンシ値を比較することにより、スライス固有のレイテンシに関する比較を行うことができる。一例において、レイテンシが閾値を下回った場合、モニタリングモジュールはまず、レイテンシ値がある期間にわたって閾値を下回り続けていることを確認し得る。これは、スライス経路が真に変化を必要としていることを確認して、スライス経路が絶えず変化するのを防止するのに役立ち得る。ただし、閾値期間中にＳＬＡ閾値が満たされない状態が続く場合、モニタリングモジュールは、スライス経路を変更するように作用する。

ＳＬＡレイテンシ要件が満たされない場合、モニタリングモジュールは、スライスの代替スライス経路を選択可能である。これは、ネットワーク接続性グラフを参照して、性能特性がより好適な別のルートを決定することを含み得る。一例において、ネットワーク接続性グラフには、ネットワークの物理または仮想レイヤから報告され、他のスイッチに対応する情報を格納可能である。モニタリングモジュールによって選択された代替経路は、元のスライス経路の一部ではないスイッチを含み得るため、スライスベースネットワークを通る異なる物理・仮想経路が必要となる。

ステージ１４０において、モニタリングモジュールは、新たなスイッチを介する代替スライス経路を実装可能である。これは、既存のスイッチでスライス経路情報を更新して、第２のスイッチの代わりに第３のスイッチへとスライストラフィックをルーティングすることを含み得る。また、一例においては、第３のスイッチに対応する仮想レイヤにおいて、適当なＶＮＦをインスタンス化することができる。

図１Ｃは、多様な顧客にとって重要なＳＬＡ要件となり得るスループット要件に基づいて輻輳を抑える例示的な方法を示している。スループットを計算する従来の手法は、ネットワークを通じて大量のデータを定期的に送ることを含む。ただし、このソフトウェアベースの手法は、Ｔｅｌｃｏプロバイダが国全体に分散可能な大規模ＶＳＮにおいてはスケーリングしない。その代わりに、物理ネットワークのスイッチがテレマティクスデータを収集可能であるとともに、モニタリングモジュールがこのデータを集約して、全体のスライススループットを計算可能である。

ステージ１４５において、オーケストレータまたはモニタリングモジュールは、エージェントをＶＳＮ中のプログラム可能なスイッチに供給可能である。これは、スイッチのコア内等のスイッチハードウェアにおいて、スイッチにエージェントを実行させることを含み得る。そして、エージェントを実行するスイッチは、複数のスライスについて、データレート情報を計算することができる。一例において、スイッチは、スライスＩＤ、Ｓｍａｃ、Ｄｍａｃ、ＳＩＰ、ＤＩＰ、ＳＰｏｒｔ、ＤＰｏｒｔ、Ｐｋｔレートといったフォーマットでデータレート情報を保持可能である。スライスＩＤは、スライスを示し得る。Ｓｍａｃが送信元ＭＡＣアドレスを示し得る一方、Ｄｍａｃは、宛先ＭＡＣアドレスを示す。ＳＩＰおよびＤＩＰはそれぞれ、送信元ＩＰアドレスおよび宛先ＩＰアドレスに対応し得る。ＳＰｏｒｔおよびＤＰｏｒｔは、送信元および宛先ポートに対応し、Ｐｋｔレートは、パケットレートを示し得る。

ステージ１５０において、モニタリングモジュールは、第１のスライスの現在のスライス経路におけるスイッチを含む複数のスイッチから、データレート情報を受信可能である。データレート情報は、スライスおよびパケットレートを識別可能である。一例において、モニタリングモジュールは、メッセージをスイッチに送ることにより、この情報を定期的に収集する。別の例において、スイッチは、モニタリングモジュールからリクエストを受信する必要なく、モニタリングモジュールに定期的な問い合わせを行う。

ステージ１５５において、モニタリングモジュールは、上記スライスおよびＶＳＮ中の他のスライスのアグリゲートスループットを決定可能である。これは、ネットワークトポロジおよびスライス経路を使用して、重複情報を除外することを含み得る。たとえば、スイッチがフローの開始ノードでない場合は、重複情報を含む可能性がある。モニタリングモジュールは、フローのループ処理により、各フローの第１のスイッチからのレート情報に基づいてスライススループットを更新することができる。これについては、図５に関して以下により詳しく説明する。一例においては、その他のレート情報を無視することができる。

ステージ１６０においては、アグリゲートスループットと閾値との比較に基づいて、モニタリングモジュールは、スライスの新たなスライス経路を実装可能である。閾値としては、ＳＬＡにおけるスライスのスループット閾値が挙げられる。レイテンシと同様に、モニタリングモジュールは、一例において、スライス経路の変更前のある期間にわたって、スループットがＳＬＡに準拠しないことを確認し得る。オーケストレータまたはモニタリングモジュールは、上述の通り、代替スライス経路を選択および実装可能である。モニタリングモジュールは、低スループットとなっていないスイッチを含む経路を取得可能である。これにより、ＶＳＮ全体にスライスを分散させて、ＳＬＡ準拠を維持することが可能となり得る。

図２Ａは、テレマティクスデータに基づいて輻輳を抑える例示的なシーケンス図である。ステージ２０５において、モニタリングモジュールは、スライスベースネットワークの複数のスイッチＳ１、Ｓ２、Ｓ３をプログラム可能である。これは、スイッチ上のインターフェースへのリモート問い合わせと、スイッチで実行するパッケージの送信とを含み得る。パッケージは、エージェントを含み得る。一例においては、Ｐ４言語スクリプトを使用して、スイッチ上でエージェントを起動する。また、スライス経路等の情報をスイッチに送って、ルーティングに使用可能である。

ステージ２１０において、エージェントは、スイッチ上で実行可能である。エージェントを使用して、レイテンシ情報またはデータレート情報等のテレマティクスデータをスライスごとに収集可能である。エージェント２１０は、スライス経路を調べ、スライスＩＤに基づいてパケットの次ホップを決定するロジックをさらに含み得る。本例において、スライスは、スイッチＳ１およびＳ２を含む現在のスライス経路を有し得る。当該スライスに関し、Ｓ１からの次ホップとしては、Ｓ２が挙げられる。

ステージ２２０において、スイッチは、テレマティクスデータをモニタリングモジュールに定期的に送信可能である。一例において、スイッチは、エージェントに基づいて、テレマティクスデータを送るタイミングを決定する。別の例において、モニタリングモジュールは、個々のスイッチへの問い合わせによって、必要ごとにテレマティクスデータを要求する。

ステージ２２５において、モニタリングモジュールは、スライスごとにテレマティクスデータを集約し、スライスがＳＬＡの１つまたは複数の性能要件を満たしていないものと判定可能である。これは、任意の性能基準に基づいて行うことができ、レイテンシおよびスループットは、そのうちの２つの例に過ぎない。その後、モニタリングモジュールは、代替スライス経路を決定可能である。これは、他の低負荷スイッチを明らかにするネットワークトポロジグラフの解析を含み得る。本例においては、第３のスイッチＳ３が第２のスイッチＳ２よりも低輻輳となり得る。

これに応答して、ステージ２３０および２３５において、モニタリングモジュールは、第３のスイッチＳ３を含み、第２のスイッチＳ２を除くように経路を変更することによって、スライスの新たなスライス経路を実装可能である。ステージ２３０において、モニタリングモジュールは、第３のスイッチＳ３に対応する仮想レイヤにおいてスライスの適当なＶＮＦが動作していることを確認し得る。スライス経路が変更されると、第２のスイッチＳ２に対応する仮想レイヤ中のＶＮＦは、当該スライスによって使用されなくなる。一例において、ＶＮＦの配置は、オーケストレータまたはモニタリングモジュール以外の何らかのオーケストレータプロセスにより取り扱われる。

ステージ２３５において、モニタリングモジュールは、第１のスイッチＳ１に新たなスライス経路を通知可能である。一例において、これは、ステージ２３０のＶＮＦの準備が整った後に実行可能である。この通知により、スイッチＳ１は、当該特定のスライスに対して次ホップをＳ３に変更可能であり、ステージ２４０において新たなスライス経路が得られる。これにより、スライスベースネットワーク全体での輻輳を抑えることができる。

図２Ｂは、スライスレイテンシに基づいて輻輳を抑える例示的なシーケンス図である。ステージ２４２において、モニタリングモジュールは、スライスベースネットワークのスイッチから、タイミング情報を受信可能である。上述の通り、スイッチ上のエージェントは、この情報をモニタリングモジュールに伝達可能である。ステージ２４４において、第１のスライス経路は、スイッチＳ１およびＳ２を含み得る。これらのスイッチはいずれも、ステージ２４２においてタイミング情報を報告可能である。

ステージ２４６において、モニタリングモジュールは、スイッチＳ１およびＳ２から受信したタイミング情報に基づいて、第１のスライスのレイテンシ値を決定可能である。ステージ２４８において、モニタリングモジュールは、スイッチＳ３からのタイミング情報に基づいて、スイッチＳ３を利用する異なるスライスのレイテンシ値を決定可能である。

ステージ２５０においては、ＳＬＡ閾値との比較により、第１のスライスにおいてレイテンシが高すぎることを明らかにし得る。これに応答して、ステージ２５６において、モニタリングモジュールは、第１のスライスのスライス経路を第２のスライス経路に変更可能である。ステージ２５２においては、これを実行するため、スイッチＳ３の仮想レイヤにおいて１つまたは複数の必要なＶＮＦをインスタンス化することができる。また、設定情報をスイッチＳ１に送ることにより、第１のスライスの次ホップをスイッチＳ３に変更することができる。これにより、第１のスライスは、スイッチＳ２を使用しなくなるため、当該スイッチにおいて輻輳を緩和することができる。

図２Ｃは、スライススループットに基づいて輻輳を抑える例示的なシーケンス図である。ステージ２６５において、第１のスライスは、スイッチＳ１およびＳ２を含む現在のスライス経路を有し得る。スイッチ上のエージェントは、スライスごとにデータレート情報を収集可能である。ステージ２６０において、スイッチは、スライス固有のデータレート情報をモニタリングモジュールに報告可能である。

ステージ２７０において、モニタリングモジュールは、スライススループットを計算可能である。モニタリングモジュールは、第１のスライスおよびネットワーク中の他のスライスについてこれを実行可能である。これは、ステージ２７５において、重複するデータレート情報を無視することを含み得る。本例において、スイッチＳ２は、スイッチＳ２ではなくスイッチＳ１で開始となるフローを有する第１のスライスについて、重複するデータレート情報を報告する。いくつかの例においては、スイッチＳ２がＳ１を含む複数のスイッチからデータを受信した場合等、スイッチＳ１から受信したデータレート情報に対して、スイッチＳ２が提供するデータレート情報の一部しか重複しない。これらの例において、ステージ２７５は、スイッチＳ１と関連付けられたデータレート情報に基づいて考慮済みの重複するデータレート情報のみを無視することを含み得る。図５において、詳細な説明および関連する議論を与える。

ステージ２８０において、モニタリングモジュールは、第１のスライスのスループットがＳＬＡ要件を下回るものと判定可能である。これに応答して、ステージ２８５においては、第１のスライスの新たなスライス経路を実装可能である。これにより、スイッチＳ２の代わりにスイッチＳ３を使用することによって、スループットを向上可能である。

図３は、スライスベースネットワークにおける輻輳抑制の例示的なフローチャートである。一例においては、モニタリングモジュールによって、各ステージを実行可能である。ステージ３１０において、ＶＳＮモニタは、ネットワーク要素からテレマティクスデータを受信する。これは、ルータ、サーバ、およびホスト等、ネットワークの任意のスイッチから任意の性能データを受信することを含み得る。ＶＳＮモニタとしては、物理サーバ上で実行される１つまたは複数のプロセスが挙げられる。サーバとしては、スライスベースネットワーク上でさまざまな動作を管理する管理クラスタの一部が挙げられる。一例において、ＶＳＮモニタは、ＶＭｗａｒｅ（登録商標）のｖＲｅａｌｉｚｅ（登録商標）等、ＶＳＮにおけるＶＮＦ（たとえば、仮想マシン）の動作の様子をモニタリングする仮想解析エンジンを含む。ＶＮＦは、仮想コントローラ、仮想ルータ、仮想インターフェース、仮想ローカルエリアネットワーク（「ＶＬＡＮ」）、ホスト仮想マシン（「ＶＭ」）、またはスイッチにより接続されたサーバ等、物理ハードウェア上で動作する他の仮想化ネットワーク機能を表し得る。また、一例において、ＶＳＮモニタは、ネットワークにおけるスイッチ等のハードウェアの性能を解析する物理アンダーレイとして作用し得る物理解析エンジンを含み得る。モニタリングモジュールが物理解析エンジンを含むことも可能である。別の例においては、モニタリングモジュールが解析エンジン全体を含むことも可能である。

物理解析エンジンは、物理レイヤからの性能情報（たとえば、テレマティクスデータ）を利用する輻輳確認プロセスを含み得る。ステージ３２０において、輻輳確認プロセスは、テレマティクスデータのいずれかが輻輳を示しているかを判定可能である。輻輳は、性能データが閾値を満たさないことに基づき得る。たとえば、特定のスライスの帯域幅、ＲＴＴ、レイテンシ、またはスループットがＳＬＡ閾値を下回る可能性がある。

ステージ３３０においては、輻輳除去プロセスがスライスベースネットワークのファブリックトポロジにアクセスして、代替スライス経路を決定可能である。ファブリックトポロジは、他の利用可能なスイッチおよび関連する性能基準のグラフを含み得る。ＶＳＮのハードウェアは、どのＶＮＦがどのデバイス上で動作しているかと、どのスイッチが相互に連通しているかと、を報告可能である。ハードウェアおよび仮想の両コンポーネントの発見により、このシステムは、これらを一体的にマッピングして、ファブリックトポロジを生成することができる。

輻輳除去では、ファブリックトポロジのその他の部分およびその現在の性能に基づいて、１つまたは複数の代替スライス経路を決定することができる。物理レイヤにおいては、エージェントを実行するプログラム可能なスイッチによって性能を報告可能である。スイッチは、データレート、スループット、レイテンシ、および帯域幅等の性能情報を報告可能である。この性能情報は、輻輳の検出に使用可能である。

物理レイヤからの性能データに基づく輻輳回避がスライス経路の変更の１つの理由となり得る。仮想レイヤにおける問題もこの決定に寄与し得る。仮想コンポーネントは、性能を仮想解析エンジンに対して別個に報告可能である。一例においては、仮想および物理の両レイヤの解析によって、スライス経路を変更するタイミングを決定する。

一例においては、オーケストレーションプロセスがコントローラ階層を管理可能である。コントローラ階層は、１つまたは複数のデータセンタ内のさまざまなエンティティを設定して、仮想サービスネットワークを実現する。高レベルＶＳＮコントローラは、ＶＳＮが実装されたデータセンタにおいてエンティティを設定する複数組の他のコントローラを調整可能である。いくつかの実施形態において、各データセンタは、それ自体の一連の低レベルコントローラを有する。これらのコントローラは、（たとえば、ＶＮＦを実装するＶＭを設定する）演算コントローラ、（たとえば、スライスセレクタとネットワークサービスとの間でデータメッセージを伝送するように転送スイッチを設定する）ネットワークコントローラ、ストレージコントローラ、および（たとえば、データセンタ間でデータメッセージを伝送するスライスセレクタおよびゲートウェイまたはそのいずれかを設定する）ソフトウェア定義のネットワーク（「ＳＤＮ」）コントローラを含み得る。

ステージ３４０においては、プロセスによって、ネットワーク中の代替スライス経路を設定可能である。ＶＳＮコントローラ階層は、新たなスライス経路を実装するように一体的に機能し得る。これは、仮想レイヤにおけるＶＮＦのインスタンス化と、物理または仮想スイッチの再設定による仮想または物理レイヤの新たなスイッチへの問い合わせとを含み得る。オーケストレータプロセスは、ネットワークトポロジに基づいて、ＶＮＦインスタンス化を管理可能である。モニタリングモジュールは、メッセージを１つまたは複数のスイッチに送って、スライス経路を変更することができる。その後、将来のテレマティクスデータによって、新たなスライス経路をモニタリング可能である。

図４Ａは、ＶＳＮにおける複数のスライスを示した例示的なシステム図である。サンフランシスコ４２０のセルタワーにおけるネットワークデータの送受信によって、複数の端末デバイス４１０（本例では電話）がＶＳＮ４０５と通信可能である。

セルタワーは、端末デバイス４１０からのパケットに対する正しいスライスを決定するスライスセレクタ４２５に通信結合可能である。これは、パケットタイプ、送信元および宛先ＩＰアドレス、送信元および宛先ポート、ならびに送信元および宛先ＭＡＣアドレス等のパケット情報に基づいて実行可能である。一例において、スライスセレクタ４２５は最初、パケットを処理して、ＶＳＮのネットワークスライスのうちの１つに割り当てる。また、スライスセレクタ４２５は、割り当てスライスに対する正しい一組のネットワークサービスによってパケットが処理されるように、サービスチェーン動作を取り扱うことができる。種々例において、スライスセレクタ４２５は、とりわけ、ＶＭ、ＶＭ内もしくはホストコンピュータの仮想化ソフトウェア内で動作するソフトウェア転送要素（たとえば、フローベースの転送要素）、またはホストコンピュータの仮想化ソフトウェア内の転送要素の外側（たとえば、ＶＭと転送要素のポートとの間）で実行される一組のモジュールによって実装可能である。

場合により、ＶＳＮに対して、多数のスライスセレクタ４２５を設定する。通信サービスプロバイダの例においては、アクセスネットワークの各セルタワー、基地局、または他の態様に対してネットワークスライスセレクタを設定可能である。通信サービスプロバイダのアクセスネットワークは、各セルタワーのエッジクラウドを含み得るとともに、このような各エッジクラウドにおいて少なくとも１つのスライスセレクタ４２５を設定可能である。他の例（たとえば、一組の接続データセンタ内に完全に含まれるＳＤ－ＷＡＮトラフィックの場合）においては、ＶＭから送られたデータメッセージに対するネットワークスライス選択が（送信元ＶＭの外側ではあるものの）データメッセージの送信元と同じホストコンピュータで発生するように、分散ネットワークスライスセレクタが設定される。

本例においては、ＹＯＵＴＵＢＥストリーミング用の第１のスライス４３０および９１１番通報用の第２のスライス４３５がＶＳＮ４０５に存在する。これらのスライス４３０、４３５はそれぞれ、異なるＳＬＡ要件を有し得るため、ＶＳＮの１つまたは複数のスイッチに広がり得る。一例において、これらのスイッチは、インターネット全体で複数のクラウドに及ぶ可能性がある。また、これらの同じスライス４３０、４３５がニューヨーク市４５０において終端し得る。当該点における異なるスライスセレクタ４４０がスライスベースネットワークに対してネットワークトラフィックをルーティング可能である。

図４Ｂは、ＶＳＮにおける複数のスライスを示した例示的なシステム図である。第１のスライス４６０は、スイッチＲ１、Ｒ３、Ｒ５、およびＲ６に及ぶ可能性がある。第２のスライス４６５は、スイッチＲ１、Ｒ２、Ｒ４、およびＲ６に及ぶ可能性がある。両スライス４６０、４６５は、サンフランシスコ４２０からニューヨーク市４５０まで及ぶ。本例のスイッチとしては、ルータが挙げられる。これらのスイッチはそれぞれ、各スライス４６０、４６５のパケットレートおよびタイミング情報を計算する。

一例において、第２のスライスは当初、サンフランシスコ４２０からニューヨーク市４５０までのスライス経路を有する。このスライス経路は、輻輳に基づいて、スイッチＲ３、Ｒ５の代わりにスイッチＲ２、Ｒ４を使用するように変更され得る。このため、モニタリングモジュールは、スイッチＲ１におけるルーティングテーブルを更新して、スイッチＲ３の代わりにスイッチＲ２へと次ホップを変更可能である。また、スイッチＲ２、Ｒ３、Ｒ４、およびＲ５におけるルーティングテーブルは、新たなスライス経路を反映するように更新可能である。

モニタリングモジュールは、輻輳を検出するため、前述のさまざまなスイッチからのパケットレートおよびタイミング情報等のテレマティクスデータを使用可能である。モニタリングモジュールは、このデータを使用して、各スライス４６０、４６５のスループットの集約を試行可能である。一例においては、スライススループットにのみ、総スライススループットを計算するための重複しないデータレート情報を必要とする。たとえば、スイッチＲ３およびＲ５は、サンフランシスコ４２０からニューヨーク４５０に向かう第１のスライス４６０の重複するパケットレートデータを有し得るが、スイッチＲ５は、マイアミ４７０からニューヨーク４５０に向かう第１のスライス４６０の重複しない関連するパケットレートデータを有することになる。このため、一例においては、スイッチＲ３からのデータレート情報が無視される一方、スイッチＲ５におけるマイアミ４７０のデータは、第１のスライス４６０のスループットの計算に含まれるものとする。これは、第１のスライス４６０が同一スライス内に、それぞれサンフランシスコ４２０およびマイアミ４７０からのフローである第１および第２の２つの異なるスループット源を有するためである。一方、スイッチＲ３は、Ｒ１からの重複するフロー情報のみを含む。

図５は、スライススループットを計算するとともに、重複フローからデータを除去する方法を決定する例示的なフローチャートである。スループットを計算する他の方法も考えられるため、図５は、１つの例示的な手法に過ぎない。ステージ５０５において、モニタリングモジュールは、上記説明の通り、スライスのスループットの集約を開始する。一例において、スライススループットの計算には、スライス内の各フローに関する第１のスイッチからのデータレート情報のみが必要となる。このため、一例において、モニタリングモジュールは、スライス経路内のどのスイッチでどのフローが開始となっているかを解析し、これらのスイッチからのデータレート情報に基づいてスループットを計算可能である。

ステージ５１０において、モニタリングモジュールは、当該スライスのスライス経路における次スイッチＳからテレマティクスデータを収集する。これは、パケットレートデータの収集を含み得る。ステージ５１５において、モニタリングモジュールは、次フローＦのパケットレートデータを取得する。

ステージ５２０において、このスイッチが当該フローの経路中の最初のスイッチである場合は、データレート情報がスライススループットの決定に関連する。その結果、ステージ５２５において、モニタリングモジュールは、当該フローのデータレート情報を含むようにスライススループットを更新可能である。

スイッチが当該フローの最初の経路でない場合は、スライススループットの決定に関して、データレート情報が無視され得る。代わりに、このアルゴリズムは、ステージ５１５において次フローＦを再び取得し、スイッチで確認すべきフローがなくなるまで、このプロセスを繰り返すことができる。図４Ｂに関しては、この理由から、スイッチＲ５が第１のスライスのスループットと関連していたが、Ｒ３は関連していなかった。スイッチＲ３においては、サンフランシスコからのフローが存在するものの、当該フローはスイッチＲ１を起点とする。これに対して、スイッチＲ５では、第１のフローがスイッチＲ１を起点とする一方、第２のフローはスイッチＲ５を起点とする。

ステージ５３０において、モニタリングモジュールは、未処理のフローが存在するかを判定する。モニタリングモジュールは、ファブリックトポロジへのアクセスに基づいてこれを実行可能である。ファブリックトポロジとしてはグラフが挙げられるが、これは、一例において、フロー経路および物理スイッチに基づいて、さまざまなフローを示し得る。未処理のフローが存在する場合、このアルゴリズムは、ステージ５１５に戻って、次フローのレート統計値を取得可能である。

そうでない場合、ステージ５３５において、モニタリングモジュールは、別のスイッチが存在するかを判定可能である。存在する場合、このアルゴリズムは、ステージ５１０から再び開始可能である。次スイッチは、必要により、任意のフロー経路で最初のスイッチとして確認するとともに、スライススループットに含めることができる。ただし、それ以上のスイッチが存在しない場合は、ステージ５４０において、スライススループットの計算が完了となる。

図６は、ＶＳＮ６００におけるシステム構成要素の例示的な図である。ＶＳＮ６００としては、１つまたは複数のクラウド６２０、６４０を含む分散Ｔｅｌｃｏクラウドネットワークが挙げられる。スライス６７２、６７８、６８２は、これらのクラウド６２０、６４０全体に分散可能である。

各クラウド６２０、６４０は、ネットワーク機能仮想化（「ＮＦＶ」）６４２のための物理および仮想インフラを有し得る。たとえば、ルータおよびサーバ等の物理スイッチ６４４は、ＶＮＦ機能を提供するＶＭ６４６またはマイクロサービスを動作させ得る。スライスは、エッジクラウド６２０上で実行される第１のＶＮＦを含み得る。ＶＮＦは、１つまたは複数のｖＣＰＵを利用可能であり、一例においては、１つまたは複数のＶＭ６２４が挙げられる。ただし、エッジクラウド６２０は、多数のＶＮＦを実行可能であり、これは多くの場合、ＶＮＦがさまざまなスライスの一部である場合の複数のテナントを対象とする。スライスは、異なるスライスからのＶＮＦが、共有物理ハードウェア６２２上で動作するＶＭ６２４に依拠する場合であっても、互いの存在を認識しない状態で、機能的観点からの分離を保ち得る。

スライス経路中の第１のＶＮＦは、異なるクラウド６４０に配置可能な第２のＶＮＦと通信可能である。たとえば、第２のＶＮＦは、コアクラウド６４０の物理ハードウェア６４４上で動作する１つまたは複数のＶＭ６４６を含み得る。また、第２のＶＮＦは、スライス経路中のさらに別のＶＮＦと通信可能である。一例において、これらのＶＮＦのうちの１つまたは複数は、インターネット６６０への出力として作用し得る。

１つまたは複数のユーザデバイス６０２は、たとえば５Ｇデータ接続を用いて、ＶＳＮ６００のスライスに接続可能である。ユーザデバイス６０２としては、Ｔｅｌｃｏネットワークに接続可能な任意の物理プロセッサ対応デバイスが挙げられる。例として、車両、電話、ラップトップ、タブレット、ＩｏＴデバイス、仮想現実デバイス等が挙げられる。セルタワー６０５等の送受信機がこれらのユーザデバイス６０２と送受信可能である。エッジクラウド６２０への入力では、スライスセレクタ６０８がユーザデバイス６０２から送られたデータを受信して、適用するスライスを決定可能である。スライスセレクタ６０８は、エッジクラウド中のＶＭ６２４として動作することも可能であるし、またはエッジクラウド６２０に接続された異なるハードウェア上で動作することも可能である。一例において、スライスセレクタは、パケットヘッダ中の情報を用いて、パケットが属するスライスを決定することができる。

分散仮想インフラを管理するため、モニタリングモジュールを有するオーケストレータ６６８を含めて、プロバイダは管理プロセスのトポロジ６６５を動作させ得る。オーケストレータ６６８は、異なるサーバ上または異なる仮想環境中で別個に動作するモニタリングモジュールと交互に通信可能である。本例において、モニタリングモジュールとしては、オーケストレータ６６８とともに機能するトポロジ６６５の一部が挙げられる。これらのプロセスの一例となるフレームワークがＶＭＷＡＲＥによるＶＣＬＯＵＤ ＮＦＶであって、これは、ネットワーク仮想化にＶＳＰＨＥＲＥを、仮想解析にＶＲＥＡＬＩＺＥを使用可能である。例示的なオーケストレータは、ＣＬＯＵＤＩＦＹである。

一例において、オーケストレータは、スライスおよびＶＮＦの管理を担当し得る。これは、性能基準およびネットワーク負荷に基づく新たなスライスのプロビジョニングまたは既存のスライスの再プロビジョニングを含み得る。オーケストレータは、１つまたは複数のコアクラウド６２０、６４０中またはクラウドとは別個に配置された１つまたは複数の物理サーバ上で動作し得る。オーケストレータ６６８は、各スライスにどのクラウドおよびＶＮＦが含まれるかについての経過を追うツールを提供可能である。オーケストレータはさらに、個々のテナント６７０、６８０のスライス性能を追跡して、管理コンソールを提供可能である。また、オーケストレータ６６８は、性能基準および負荷情報を受信して、モニタリングモジュールが新たなスライス経路を見出すべきタイミングを決定可能である。

本例においては、第１のテナント６７０が複数のスライス６７２、６７４を有する。各スライス６７２、６７８は、当該スライスのＶＮＦ要件を示すスライス記録により規定可能である。ＶＮＦ６７４、６７６はそれぞれ、サービスチェーンにおける異なる機能を提供可能である。

また、ＳＬＡはスライスのさまざまな閾値性能要件を規定し得る。これらの性能要件は、レイテンシ、ラウンドトリップタイム、帯域幅等を含み得る。一例において、これらは、スライスごとのＱｏＳ要件として機能し得る。

オーケストレータ６６８は、モニタリングモジュールに依拠して、スイッチ６２２、６４４からテレマティクスデータを受信するとともに、ＳＬＡが満たされているかを判定することができる。一例において、モニタリングモジュールは、スイッチ６２２、６４４にエージェント６０１を提供する。スイッチ６２２、６４４は、エージェント６０１を実行するようにプログラム可能である。また、モニタリングモジュールは、入力ポート６０３から出力ポート６０６まで、および、出力ポート６０６からネットワーク６００中の次ホップまでパケットを移動させるのにスイッチが使用するポリシングアルゴリズムを供給可能である。また、モニタリングモジュールは、次ホップおよびこれらの次ホップに対して使用する出力インターフェース（たとえば、ポート）を決定するのにスイッチ６２２、６４４が使用するスライス経路情報も供給可能である。

また、オーケストレータ６６８は、スライスセレクタ６０８およびスイッチ６２２、６４４の設定を変更して、スライス経路を通るトラフィックのルートが正しくなるようにし得る。これは、上記デバイスがパケット情報を比較するテーブルの変更を含み得る。たとえば、スライス選択は、パケットのパケットヘッダ中の情報に基づき得る。たとえば、スイッチまたはスライスセレクタは、レイヤ２～レイヤ４（Ｌ２～Ｌ４）ヘッダの組み合わせを使用することも可能であるし、（たとえば、レイヤ７（Ｌ７）ヘッダ中のデータに基づいてトラフィックを分類するために）深層パケット検査を実行することも可能である。たとえば、スライス選択は単に、送信元ネットワークレイヤ（たとえば、ＩＰ）アドレスを用いることにより、送信元デバイスに基づくことも可能であるし、Ｌ７ヘッダを確認することにより、トラフィックタイプまたは宛先ネットワーク領域に基づくことも可能である。いくつかの実施形態において、ネットワークスライスセレクタは、接続の各データメッセージ上で深層パケット検査を実行する必要がないように、接続をネットワークスライスにマッピングする状態を維持する。また、一部の接続については、スライス選択の実行に必要なＬ７ヘッダ情報を特定のデータメッセージのみが含む。

深層パケット検査を用いてスライス選択を実行する場合、接続の最初のデータメッセージには、スライスセレクタがスライスを正しく識別するために必要とするＬ７ヘッダ情報が含まれていなくてもよい。たとえば、端末デバイス（たとえば、スマートフォンまたはタブレット等のモバイルデバイス、ラップトップまたはデスクトップコンピュータ、ＩｏＴデバイス、自動運転車、セキュリティシステムに属するスマートカメラ）とネットワーク領域との間の接続は、ＴＣＰハンドシェイク等の一組の接続開始メッセージによって開始となることが多い。ハンドシェイクの完了後、デバイスは、たとえばネットワーク領域を含むｈｔｔｐ取得メッセージを送る。デバイスとネットワーク領域との間で送信される後続のデータメッセージは、このような情報を含んでいなくてもよい。

以上、物理スイッチに関して複数の例を説明したが、これらの例は、仮想スイッチにおいても代替実行可能である。また、オーケストレータ、仮想管理トポロジ、およびモニタリングモジュールに別々に言及したが、これらのプロセスはすべて、一体的に動作し得る。これらの例は、どのプロセスがどのステップを実行するかを制限するものではない。その代わりに、モニタリングモジュールは、上記ステージを実行する仮想管理トポロジの任意の部分と考えられる。

本明細書に開示の例の規定および実施を考慮することにより、当業者には、本開示の他の例が明らかとなるであろう。上記方法の一部を一連のステップとして提示したが、当然のことながら、１つまたは複数のステップが同時に起こることもあり得るし、重なって起こることもあり得るし、異なる順序で起こることもあり得る。提示のステップの順序は、可能性を示したに過ぎず、これらのステップは、任意の好適な様態で実行または実施可能である。さらに、本明細書に記載の例のさまざまな特徴は、相互に排他的ではない。むしろ、本明細書に記載の如何なる例の如何なる特徴も、その他任意の好適な例に組み込み可能である。上記規定および例は、ほんの一例に過ぎないと考えられ、本開示の真の範囲および思想は、以下の特許請求の範囲により示されるものとする。

Claims (9)

1. スライスベースネットワークにおいて輻輳を回避する方法であって、
   複数のスライスの複数のスイッチからデータを受信するステップと、
   少なくとも第１および第２のスイッチからの前記データに基づいて、前記第１および第２のスイッチを使用するスライスのサービスレベル契約（以下、「ＳＬＡ」とする）が満たされていないものと判定するステップと、
   前記スライスに対して、前記スライスの既存の経路にない第３のスイッチを含む代替スライス経路を選択するステップと、
   前記代替スライス経路を選択した後、前記第３のスイッチ上で仮想ネットワーク機能をインスタンス化して前記スライスとともに使用すること、および
   前記第１のスイッチに、前記第２のスイッチの代わりに前記第３のスイッチに対して、前記スライスのトラフィックを送らせることを含んで、
   前記代替スライス経路を動的に実装するステップと、
   を含む方法。
2. 前記データが、前記スイッチにインストールされたエージェントから、前記代替スライス経路を選択するリモートモニタリングモジュールに送られる、請求項１に記載の方法。
3. 前記データが、レイテンシを含み、前記代替スライス経路が、前記ＳＬＡのレイテンシ要件が満たされていないものとモニタリングモジュールが判定することに基づいて選択される、請求項１に記載の方法。
4. 前記データが、スループットを含み、前記代替スライス経路が、前記ＳＬＡのスループット要件が満たされていないものとモニタリングモジュールが判定することに基づいて選択される、請求項１に記載の方法。
5. 前記複数のスイッチにエージェントを送るステップをさらに含み、前記エージェントは、前記スイッチの物理レイヤにおいてパケットを解析することにより前記データを決定するように前記複数のスイッチによって実行される、請求項１に記載の方法。
6. 元のスライス経路における前記スイッチの一部からのスループット情報を利用してスライススループットを決定するステップをさらに含む、請求項１に記載の方法。
7. 前記データは、テレマティクスデータを含む、請求項１に記載の方法。
8. 命令を含むコンピュータ可読媒体であって、前記命令は、コンピュータシステムによる実行時に請求項１乃至７のいずれか一項に記載の方法を実行する、コンピュータ可読媒体。
9. 請求項１乃至７のいずれか一項に記載の方法を実行するように構成されたコンピュータシステム。