(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023126364
(43)【公開日】2023-09-07
(54)【発明の名称】スライスベースネットワークにおける輻輳回避
(51)【国際特許分類】
H04L 41/5025 20220101AFI20230831BHJP
H04L 41/40 20220101ALI20230831BHJP
H04L 41/0895 20220101ALI20230831BHJP
H04L 45/302 20220101ALI20230831BHJP
【FI】
H04L41/5025
H04L41/40
H04L41/0895
H04L45/302
【審査請求】有
【請求項の数】9
【出願形態】OL
(21)【出願番号】P 2023113802
(22)【出願日】2023-07-11
(62)【分割の表示】P 2021568099の分割
【原出願日】2020-05-14
(31)【優先権主張番号】16/411,888
(32)【優先日】2019-05-14
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】510149482
【氏名又は名称】ヴイエムウェア インコーポレイテッド
【氏名又は名称原語表記】VMware,Inc.
(74)【代理人】
【識別番号】100105957
【弁理士】
【氏名又は名称】恩田 誠
(74)【代理人】
【識別番号】100068755
【弁理士】
【氏名又は名称】恩田 博宣
(74)【代理人】
【識別番号】100142907
【弁理士】
【氏名又は名称】本田 淳
(72)【発明者】
【氏名】コムラ、ラジャ
(72)【発明者】
【氏名】タイドマン、ジェレミー
(72)【発明者】
【氏名】ポリクロノポウロス、コンスタンティン
(72)【発明者】
【氏名】ボルドロー、マルク アンドレ
(72)【発明者】
【氏名】チョー、エドワード
(72)【発明者】
【氏名】グプタ、オージャス
(72)【発明者】
【氏名】キド、ロバート
(72)【発明者】
【氏名】オイコノム、ゲオルギオス
(57)【要約】
【課題】スライスベースネットワークにおけるレイテンシを管理するための方法を提供する。
【解決手段】方法は、スライスに対応するパケットのパケットヘッダにフラグを設定するステップと、スライスベースネットワーク内の複数のスイッチからエージェントによって決定されたスライス固有のパケットタイミング情報を受信するステップと、スライスのための第1のスライス経路における複数のスイッチからのパケットタイミング情報に基づいてレイテンシ値を決定するステップと、レイテンシ値と閾値との比較に基づいて、スライスのための代替スライス経路を選択するステップと、代替スライス経路は、第1のスライス経路にない第3のスイッチを含んでおり、少なくとも第1のスイッチおよび第3のスイッチを介する前記代替スライス経路を実装するステップと、を含む。
【選択図】
図1B
【特許請求の範囲】
【請求項1】
スライスベースネットワークにおけるレイテンシを管理するための方法であって、
スライスに対応するパケットのパケットヘッダにフラグを設定するステップと、
スライスベースネットワーク内の複数のスイッチからスライス固有のパケットタイミング情報を受信するステップと、前記パケットタイミング情報は、前記スイッチ上で実行されるエージェントによって決定され、前記エージェントは、少なくとも
前記フラグが認識されるが、前記パケットが前記スイッチにおいて既に格納されているフローに関連しない場合、前記フローを現在時刻と関連付けて格納すること、
前記パケットヘッダ内のアドレス情報に基づいて、前記フローが個々のスイッチに格納されていると認識された場合、新たな現在時刻から格納されている現在時刻を差し引くこと、
前記スイッチにおける格納から前記フローを削除することによって、前記スライス固有のパケットタイミング情報を決定し、
前記スライスのための第1のスライス経路における複数のスイッチからの前記パケットタイミング情報に基づいてレイテンシ値を決定するステップと、
前記レイテンシ値と閾値との比較に基づいて、前記スライスのための代替スライス経路を選択するステップと、前記代替スライス経路は、前記第1のスライス経路にない第3のスイッチを含んでおり、
少なくとも第1のスイッチおよび第3のスイッチを介する前記代替スライス経路を実装するステップと、を含む方法。
【請求項2】
前記パケットタイミング情報は、前記エージェントが前記複数のスイッチにおけるホップのタイミングを報告することに基づくものであり、前記パケットタイミング情報は、モニタリングモジュールによって受信され、かつ前記スライスの前記レイテンシ値を決定する一部として加算される、請求項1に記載の方法。
【請求項3】
前記閾値は、前記スライスの最大レイテンシを含むサービスレベル契約(「SLA」)によって確立される、請求項1に記載の方法。
【請求項4】
前記複数のスイッチは、伝送制御プロトコル(「TCP」)パケットのヘッダ内のフラグを認識することに基づいて、前記パケットタイミング情報を報告する、請求項1に記載の方法。
【請求項5】
前記パケットタイミング情報を受信するステップは、第1および第2のエージェントから送信元アドレスおよび宛先アドレスを受信することを含み、モニタリングモジュールは、前記スライスの前記レイテンシ値を算出することの一部として前記送信元アドレスおよび前記宛先アドレスを使用する、請求項1に記載の方法。
【請求項6】
前記レイテンシ値を計算することは、一定期間にわたる前記スライスのレイテンシを平均化することを含む、請求項1に記載の方法。
【請求項7】
前記代替スライス経路を実装するステップは、スライストラフィックを前記第3のスイッチにルーティングするように前記第1のスイッチを設定する前に、前記第3のスイッチにおいて前記スライストラフィックによるアクセスのための新たな仮想ネットワーク機能(「VNF」)をインスタンス化することを含む、請求項1に記載の方法。
【請求項8】
命令を含むコンピュータ可読媒体であって、前記命令は、コンピュータシステムによる実行時に請求項1乃至7のいずれか一項に記載の方法を実行する、コンピュータ可読媒体。
【請求項9】
請求項1乃至7のいずれか一項に記載の方法を実行するように構成されたコンピュータシステム。
【発明の詳細な説明】
【背景技術】
【0001】
今日の3G、4G、およびLTEネットワークは、クラウド全体に分散可能な複数のデータセンタ(「DC」)を用いて動作する。これらのネットワークは、わずか数台の運用支援システム(「OSS:Operating Support System」)およびネットワークオペレーションセンタ(「NOC:Network Operations Center」)によって中央管理される。5G技術は、Telcoネットワークへの接続および物理ネットワークリソースの共有が必要となるあらゆる種類のデバイスに対するネットワーク接続性を大幅に増大させることになる。現行のネットワークアーキテクチャは、これらの需要を満たすようにはスケーリングし得ない。
【0002】
ネットワークスライシングは、共有物理ネットワークインフラ上での複数の論理ネットワークの動作を可能にする仮想化の一形態である。分散クラウドネットワークがさまざまなスライスによってネットワークリソースを共有して、テナントと称する異なるユーザの単一の物理インフラ上での多重化を可能にし得る。たとえば、インターネット・オブ・シングス(「IoT」)デバイス、モバイルブロードバンドデバイス、および低レイテンシ車載デバイスはすべて、5Gネットワークの共有が必要となる。これらの異なる使用事例は、異なる伝送特性および要件を有することになる。たとえば、IoTは通常、多数のデバイスを有するものの、スループットは非常に低い。モバイルブロードバンドはその反対に、各デバイスが高帯域コンテンツを送受信する。ネットワークスライシングは、物理ネットワークのエンドツーエンドレベルでの分割によって、トラフィックのグループ化、テナントトラフィックの隔離、およびマクロレベルでのネットワークリソースの設定を可能にし得る。
【0003】
しかしながら、サービス品質(「QoS」)および輻輳回避に関する従来の手法は、スライスベースネットワークにより可能となるネットワーク使用の大幅な増大に対応するようには容易にスケーリングしない。たとえば、ネットワークに輻輳が生じている場合、既存のソリューションは、輻輳源を抑制し、データ伝送を効果的に遅らせて帯域幅を解放する。たとえば、プライオリティフロー制御(「PFC:Priority Flow Control」)のような既存のフロー制御メカニズムは、上流のスイッチ(たとえば、ルータ)に輻輳を通知して、スイッチを通じてトラフィックを送っているホスト等の輻輳源においてトラフィックを抑制することにより輻輳を抑える。しかし、スライスベースネットワークは、抑制が他のスライスに悪影響を及ぼして、ソフトウェアライセンス契約(「SLA:Software License Agreement」)の下で可能なスライスの性能を下回る可能性があるため、効率が悪い。SLA要件に違反しない新たなスライスベースソリューションが求められている。
【0004】
スライスベースネットワークにおいては、レイテンシおよびスループット等の重要な性能基準を正確にモニタリングすることが特に課題である。従来のネットワークにおいては、任意の2つのエンドポイント間でping等のプローブパケットを送ることにより、ソフトウェアでレイテンシを計算可能である。ただし、ソフトウェアベースのモニタリングプローブは、数千万のユーザを抱える大規模なTelcoネットワークにおいてはスケーリングしない。一般的に、スライスの仮想ネットワーク機能(「VNF:Virtual Network Function」)等を用いて仮想レイヤで輻輳を検出することは、スケーラブルでないため、下層の物理ハードウェアを急速に圧迫することになる。
【0005】
輻輳を緩和する別の方法がなければ、ネットワークインフラが過負荷となった場合に、重要なスライスが悪影響を受ける可能性がある。SLAでは、とりわけ911番通報および自動運転車との通信等の重要なトラフィックの確実な伝送が求められることが多い。
【0006】
結果として、スライスベースネットワークにおける輻輳を緩和するシステムが求められている。
【発明の概要】
【0007】
本明細書に記載の例は、スライスベースネットワークにおいて輻輳を緩和するシステムおよび方法を含む。このシステムは、ルータまたはサーバ等の物理デバイス上のエージェントと通信するモニタリングモジュールを具備し得る。ネットワークは、スライスへの分割によって、1つまたは複数のテナントに対する異なる使用事例に対応可能である。各スライスは、レイテンシ、帯域幅、ラウンドトリップタイム、およびその他の閾値レベル等の所要SLA性能属性を有し得る。
【0008】
仮想サービスネットワーク(「VSN:Virtual Service Network」)における各ネットワークスライスは、電話、車両、およびIoTデバイス等の複数の端末デバイスからデータを搬送可能である。たとえば、911スライスは、数千のモバイルデバイスからの通報を一度に搬送可能である。YOUTUBE(登録商標)スライスでも同じ事例が存在し得るが、ここでは数十万のモバイルユーザがYOUTUBEビデオを同時に視聴可能である。各スライスは、当該スライス内の異なる特殊機能に対して異なるVNFを有し得る。ただし、VNFによって一部の性能基準をモニタリングすることは、スケーラブルでない。
【0009】
一例においては、下層のスイッチ上でエージェントを動作させることにより、一部のモニタリングタスクが物理レイヤにオフロードされる。エージェントは、トラフィックを解析して、テレマティクスデータを報告としてモニタリングモジュールに返すことができる。一例において、モニタリングモジュールは、エージェントをスイッチに供給可能であり、これはプログラム可能となり得る。一例において、スイッチは、P4言語またはその他何らかのプロトコルを用いてプログラム可能なTOFINOチップ等のプログラム可能ネットワーキング特定用途向け集積回路(「ASIC」)を含む。
【0010】
スイッチは、プログラムされると、仮想レイヤではなく物理レイヤにおいてエージェントを実行可能である。スイッチ上のエージェントは、テレマティクスデータをモニタリングモジュールに報告することができる。テレマティクスデータは、スライス固有とすることにより、スライスの何らかの性能特性を示すことができる。各スイッチは、それが取り扱うスライスのテレマティクスデータを報告可能である。テレマティクスデータは、レイテンシ、帯域幅、およびラウンドトリップタイム等のスライスの任意の性能基準と関連し得る。
【0011】
モニタリングモジュールは、ネットワーク接続性グラフの保持または読み出しによって、スライスベースネットワーク全体でスイッチに対するコンパイル済みテレマティクスデータを追跡可能である。また、モニタリングモジュールは、ネットワーク接続性グラフ中の1つまたは複数のスイッチに基づいて、スライスがSLA要件を満たしていないものと判定することができる。この判定は、当該スライスのスライス経路全体でのテレマティクスデータに基づき得る。一例において、性能データとも称するテレマティクスデータは、平均化等の経時的なコンパイルが可能であるとともに、SLA閾値と比較可能である。
【0012】
SLAが満たされていないことに基づいて、モニタリングモジュールは、代替スライス経路を選択することにより、輻輳を抑えることができる。たとえば、ネットワーク接続性グラフは、性能基準に優れた別の考え得るルートを示し得る。代替スライス経路は、当該スライスの既存のスライス経路にない少なくとも1つのスイッチを含み得る。モニタリングモジュールは、選択した代替スライス経路を実装することにより、第1のスイッチが元のスライス経路における第2のスイッチの代わりに第3のスイッチに対してトラフィックを送るように、ルーティングを変更可能である。これにより、単にすべてのスライスを同じ経路でルーティングするのではなく、ネットワーク全体にスライストラフィックを分散させることによって、輻輳を抑えることができる。
【0013】
一例において、代替スライス経路は、SLA要件を下回るレイテンシ値に基づいて選択可能である。たとえば、モニタリングモジュールは、複数のスライスの複数の物理スイッチから、パケットタイミング情報を受信可能である。スイッチの物理領域で動作するエージェントは、パケットタイミング情報を送ることができる。モニタリングモジュールは、パケットタイミング情報に基づき、スイッチから受信したパケットタイミング情報の複数の異なるインスタンスの平均化等により、レイテンシ値を決定することができる。レイテンシ値と閾値との比較に基づいて、モニタリングモジュールは、スライスの代替スライス経路を選択可能であって、この代替スライス経路は、当該スライスの現在のスライス経路にないスイッチを含む。その後、モニタリングモジュールは、代替スライス経路を実装可能であって、これは、次のホップが正しくなるように新たなスライス経路でスイッチを更新することを含み得る。
【0014】
一例において、代替スライス経路は、SLA要件を下回るスループットに基づいて選択可能である。モニタリングモジュールは、第1のスライスのスライス経路におけるスイッチから、データレート情報を受信可能である。データレート情報は、モニタリングモジュールによるデータレートと特定のスライスとの相関を可能にするスライス識別子に対応し得る。モニタリングモジュールは、受信したデータレート情報に基づいて、第1のスライスのアグリゲートスループットを決定することができる。アグリゲートスループットと閾値との比較に基づいて、モニタリングモジュールは、第1のスライスの代替スライス経路を実装可能である。
【0015】
これらのステージは、いくつかの例において、オーケストレーションシステムの一部として実行されるモニタリングモジュールにより実行可能である。あるいは、命令を含む非一過性コンピュータ可読媒体によって、プロセッサが命令を実行した場合に、当該プロセッサに上記ステージを実行させることができる。用語「スイッチ(switch)」は、サーバまたはルータ等、ネットワーク機能を実行する任意のデバイスを広義に表し得る。
【0016】
以上の概要および以下の詳細な説明は、いずれも例示かつ説明を目的としているに過ぎず、上記例に限定されるものではなく、特許請求の範囲に記載の通りである。
【図面の簡単な説明】
【0017】
【
図1A】VSNにおいてスライスの輻輳を抑える例示的な方法のフローチャートである。
【
図1B】VSNにおけるスライスレイテンシに基づいて輻輳を抑える例示的な方法のフローチャートである。
【
図1C】VSNにおけるスライススループットに基づいて輻輳を抑える例示的な方法のフローチャートである。
【
図2A】VSNにおいてスライスの輻輳を抑える例示的なシーケンス図である。
【
図2B】レイテンシに基づいて、VSNにおいてスライスの輻輳を抑える例示的なシーケンス図である。
【
図2C】スループットに基づいて、VSNにおいてスライスの輻輳を抑える例示的なシーケンス図である。
【
図3】スライスベースネットワークにおける輻輳抑制の例示的なフローチャートである。
【
図4A】VSNにおける複数のスライスを示した例示的なシステム図である。
【
図4B】VSNにおける複数のスライスを示した例示的なシステム図である。
【
図5】スライススループットを計算する例示的なフローチャートである。
【
図6】VSNのトポロジの例示的なシステム図である。
【発明を実施するための形態】
【0018】
以下、添付の図面に示す例を含めて、本例を詳しく参照する。図面全体を通して、同一または同様の部分を表すのに、可能な限り同じ参照番号を使用する。
一例において、システムは、スライスベースネットワークにおける複数のスイッチから、レイテンシまたはスループットと関連する性能データ等のテレマティクスデータを受信するモニタリングモジュールを具備する。スイッチ上の物理レイヤにおいて実行されるエージェントは、テレマティクスデータを報告可能である。モニタリングモジュールは、ネットワーク接続性グラフ上で性能を追跡し、1つまたは複数のスライスに対してSLA要件が満たされないタイミングを決定することができる。
【0019】
ネットワーク接続性グラフにおけるスイッチに対するスライス性能に基づいて、モニタリングモジュールは、スライスの新たなスライス経路を選択して、スライスを再びSLA準拠とすることができる。スライスは、ネットワークの仮想オーバーレイおよび物理オーバーレイの両者にエレメントを含むことができ、潜在的には複数のクラウドに及ぶ可能性がある。スライシングによれば、プロバイダは、Telcoネットワークをセグメント化して複数のテナントにより使用可能とすることができ、各テナントは、それぞれSLA要件によって管理される自身のスライスを有し得る。
【0020】
スライスは、VSNにおける1つまたは複数のクラスタまたはクラウドに及ぶ可能性がある。オーケストレータは、特定の目的での使用またはテナントへの貸与が可能なネットワーク内の複数のスライスを管理することができる。たとえば、スライスは、特定のアプリケーション、IoTデバイス、または顧客に対して予約可能である。各スライスとしては、1つまたは複数のTelcoクラウドにわたって分散した共有物理ネットワークインフラ上で動作する仮想ネットワークが挙げられる。スライスは、特定のネットワークタスクを実行するVNFのサービスチェーンを含み得る。VNFの所要の組み合わせは、ビデオストリーミングまたはIoTデバイス管理等、スライスの使用目的に基づいて異なり得る。スライスは、特定の種類のトラフィックに対して予約可能であるとともに、QoS目的等で優先可能である。SLAは、スライスに必要な性能基準を規定するとともに、異なるスライスの所要性能基準を特定することができる。性能基準は、所与のスライスの使用目的に応じて異なり得る。また、SLAまたは別個のスライスレコードによって、サービスチェーンを構成するVNFを特定可能である。
【0021】
スライスをインスタンス化するため、VNFは、スライス経路全体に配置可能である。スライス経路は、プロバイダの分散ネットワークの部分集合を表し得るとともに、1つまたは複数のスイッチに及ぶ可能性がある。トラフィックが同じ宛先に向かっている場合であっても、異なるスライスが当該トラフィックを別々にルーティングすることができる。物理スイッチおよびVNFは、ネットワーク中の異なる区域に及ぶ可能性があるため、スライスが宛先までの異なる経路をたどり得るとともに、作業負荷をネットワーク全体に対して効果的に分散可能である。
【0022】
物理スイッチは、テレマティクスデータをモニタリングモジュールに送ることができる。モニタリングモジュールとしては、オーケストレータまたは別個のプロセスの一部が挙げられる。一例において、オーケストレータおよびモニタリングモジュールは、サーバの管理クラスタ上でホスティング可能である。一例において、物理スイッチは、ハードウェアレベルでパケットをモニタリングするエージェントを実行するようにプログラムされている。たとえば、エージェントは、VNFが実行される仮想レイヤではなく、スイッチのコアにおいて動作し得る。エージェントは、スライスに基づいてスイッチにトラフィックをルーティングさせることができる。また、エージェントは、テレマティクスデータをモニタリングモジュールに報告することができる。一例において、スイッチは、P4言語またはその他何らかのプロトコルを用いてプログラム可能なTofinoチップ等のプログラム可能ネットワーキングASICを使用可能である。一例において、モニタリングモジュールは、エージェントを使用するようにスイッチをプログラム可能である。
【0023】
モニタリングモジュールは、さまざまなスライスに対して期待されるようにネットワークが機能していることを確実にし得る。また、モニタリングモジュールは、スイッチがスライスに基づいてパケットを異なる次ホップに送れるようにするスライス経路をスイッチに与え得る。次ホップとしては、スライス経路の別のスイッチが挙げられる。これにより、ネットワークにおける低輻輳のルート全体で優先スライスを設定可能となる。スイッチ内およびネットワーク全体でのスライス経路選択におけるパケット優先度に基づいて、輻輳を抑えることができる。
【0024】
図1は、モニタリングモジュールにより実行されるステージを含む例示的な方法である。ステージ105において、モニタリングモジュールは、複数の物理スイッチから、スライス固有のテレマティクスデータを受信可能である。テレマティクスデータとしては、スイッチへとルーティングされるスライスに関する任意の性能データが挙げられる。一例において、スイッチは、モニタリングモジュールと通信するエージェントを実行するようにプログラム可能である。エージェントは、スライス固有のテレマティクスデータを定期的に報告することも可能であるし、モニタリングモジュールによって定期的にポーリングすることも可能である。テレマティクスデータは、スイッチレイテンシ、スライスレイテンシ、総ラウンドトリップタイム、スライス帯域幅、およびスイッチ帯域幅等の性能属性を含み得る。
【0025】
ステージ110において、モニタリングモジュールは、性能がスライスのSLA要件を満たせないかを判定可能である。サービスプロバイダのテナントは、ネゴシエーションを行って、SLAに概要が記載されている特定の性能要件を取り換えることができる。サービスプロバイダは、これらのSLA要件が満たされていることを確実にする必要がある。これは特に、SLA要件がテナントとの契約関係の基礎となり得るためである。
【0026】
一例においては、SLA要件が満たされるように、モニタリングモジュールは、スライスごとにテレマティクスデータを集約した後、データとスライス固有のSLA要件とを比較することができる。一例において、テレマティクスデータは、スライス識別子を含み、モニタリングモジュールがスライスごとの解析を実行できるようにし得る。また、一例において、モニタリングモジュールは、スライスに対応する物理レイヤ中のスイッチのグラフを保持し得る。これにより、モニタリングモジュールは、スライスの性能の決定に使用するテレマティクスデータを決定することが可能となり得る。
【0027】
一例としては、第1のスライスがレイテンシおよび帯域幅のSLA要件を有し得る。モニタリングモジュールは、第1のスライスに関連するスイッチから性能基準を収集可能であり、これらの基準は、レイテンシ、帯域幅、または両者に関連し得る。モニタリングモジュールは、これらの性能基準がある期間にわたってSLA要件を下回る場合に、SLAが満たされていないものと判定することができる。
【0028】
その結果、ステージ115において、モニタリングモジュールは、スライスの代替スライス経路を選択可能である。代替スライス経路は、既存のスライス経路の一部ではない新たなスイッチ等、物理レイヤを通る新たな経路を含み得る。モニタリングモジュールは、ネットワーク接続性グラフに基づいて、代替スライス経路を選択可能である。このグラフは、スライスが現時点で満たしていないSLA要件に関してより有利な性能を示す他のスイッチのテレマティクスデータを含み得る。たとえば、新たなスイッチからのテレマティクスデータは、スライス経路中の既存のスイッチではなく、新たなスイッチへとスライスがルーティングされる場合にレイテンシおよび帯域幅が改善されることを示し得る。
【0029】
ステージ120において、モニタリングモジュールは、代替スライス経路を実装可能である。これは、メッセージを第1のスイッチに送って、第1のスイッチにおけるスライス経路情報を更新することを含み得る。元のスライス経路情報がスライスの次ホップの第2のスイッチを示し得る一方、更新スライス経路情報は、次ホップとして第3のスイッチを示すことができる。また、モニタリングモジュールまたはその他何らかのオーケストレーションプロセスは、必要に応じて、第3のスイッチで1つまたは複数のVNFをインスタンス化することができる。スライスが物理レイヤおよび仮想レイヤの両者で動作し得ることから、モニタリングモジュールは、仮想レイヤにおけるVNF可用性によって、物理レイヤにおけるスライス経路の切り替えを調整することができる。
【0030】
スライス経路の変更によって、ネットワークの輻輳を低減可能である。モニタリングモジュールは、物理ネットワークの利用可能な部分にわたってスライスを分散させるのに役立ち得る。使用されるスイッチは、1つまたは複数のクラスタまたはクラウドに及ぶことで、過負荷のスイッチの負荷を低減可能である。
【0031】
図1Bは、レイテンシ要件に基づいて輻輳を抑える例示的な方法を示している。レイテンシは、多様な顧客にとって、重要なSLA要件となり得る。たとえば、911番通報のスライスは、レイテンシを可能な限り低くする必要がある。モニタリングモジュールがそのスライスについて大きなレイテンシタイムを検出した場合、一例において、モニタリングモジュールはVSNトポロジを解析して、代替となる低レイテンシ経路を計算することができる。
【0032】
ステージ125において、モニタリングモジュールは、複数のスイッチから、パケットタイミング情報を受信可能である。パケットタイミング情報としては、スライス固有のものが挙げられる。一例において、タイミング情報は、パケットがホップを構成した時点でエージェントにより収集されたタイムスタンプである。一例において、スイッチは、ワイヤスピードでパケットのリクエスト‐応答時間を追跡することができる。複数のスイッチにわたってパケットを追跡可能であり、それぞれによって、タイミング情報が報告されてレイテンシの決定に用いられる。
【0033】
以下の表1は、さまざまなパケットタイプについて、リクエストおよび応答の例示的な種類を示している。
【0034】
【表1】
インターネット制御メッセージプロトコル(「ICMP:Internet Control Message Protocol」)およびアドレス解決プロトコル(「ARP:Address Resolution Protocol」)パケットは、プロトコルヘッダに基づいて追跡可能である。一例においては、伝送制御プロトコル(「TCP:Transmission Control Protocol」)パケットを追跡するため、スイッチは、緊急フラグ等のフラグをパケットに設定するとともに、当該パケットからの確認応答を追跡することができる。
【0035】
各スイッチは、異なるスライスに対応するさまざまな一意のフローについて、タイミング情報を決定可能である。たとえば、スライスは、異なるフローに対して、複数の異なる入力点を有し得る。YOUTUBEトラフィックは、たとえばサンフランシスコおよびマイアミの両者においてスライスに合流可能であり、2つの異なるフローとなる。これらのフローは、パケットヘッダに基づいて決定可能である。たとえば、パケットヘッダは、送信元インターネットプロトコル(「IP」)アドレス、宛先IPアドレス、送信元ポート、および宛先ポートを含み得る。スイッチは、これらの情報を用いて、スライスに対応する一意のフローを識別することができる。フローのパケットが追跡されている場合は、各スイッチから報告されたタイミング情報をモニタリングモジュールが使用することにより、レイテンシを決定することができる。
【0036】
以下の表2の疑似コードは、スイッチ上のエージェントがパケットのタイミング情報を決定し得る様子の一例である。
【0037】
【表2】
表2に示すように、ICMPまたはARPパケットについて、リクエストは、スイッチ上のエージェントにパケットの現在時間を記憶させ得る。応答が戻ってきたら、スイッチは、その時間を同様に取り込み可能である。その後、スイッチは、リクエストと応答との時間差を計算し、結果をスライスIDのRTTとして返すことができる。
【0038】
スイッチがRTTを計算する方法は、さまざまなパケットタイプについて異なり得る。より詳細には、各パケットPについて、プロトコルタイプ(「protoType」)が確認される。ICMPについて、パケットがリクエストの一部である場合(たとえば、「isRequest」が真の場合)、スイッチは、スライスID、送信元IPアドレス(「sip」)、宛先IPアドレス(「dip」)、および現在時間を格納することができる。ICMPパケットが返送である場合、スイッチは、現在時間と過去に格納した時間との差を決定することができる。この値は、RTTを表し得るものであり、スライスID、sip、およびdipについて更新可能である。一例においては、RTT値をモニタリングモジュールに送ることができる。
【0039】
ARPパケットについて、リクエストが認識される場合(たとえば、「isRequest」が真の場合)は、スライスIDおよび送信元MACアドレス(「smac」)に関連して、パケットの現在時間が格納される。ARPパケットがリクエストでない場合、これは、ARPパケットが応答であることを意味し得る。この場合、応答は、エージェントにラウンドトリップタイム(「RTT」)で格納情報を更新させ得る。これをスライスのタイミング情報としてモニタリングモジュールに報告可能である。
【0040】
TCPパケットについて、エージェントは、転送フローパケットと返送パケットとの時間差に基づいて、RTTを計算することができる。たとえばユーザがビデオを開き、ビデオがアクセスされた宛先に向かってフローが延びる場合に、転送フローが生成され得る。その後、ビデオは宛先から戻り得るが、これは返送パケットを含む。
【0041】
より詳細に、エージェントはまず、直近フローのテーブルを確認して、パケットが転送フロー(「forFlow」)に対応するかを判定するよう試み得る。このテーブルは、送信元IPアドレス(「sip」)、宛先IPアドレス(「dip」)、送信元ポート(「sip」)、および宛先ポート(「dport」)に基づいて、直近フローを格納可能である。この情報に基づいて、エージェントは、フローテーブルを確認して、フローが既に識別され、転送フローからのタイムスタンプとともに格納されていることを確かめることができる。転送フローが認識される場合(たとえば、「forFLowが有効」)は、現在のパケットは、エージェントが当該転送フローのタイムスタンプを取得可能である(「forFLow->timeStamp」)。また、エージェントは、現在時間を取得し(「getTime()」)、タイムスタンプを差し引いてRTTを決定することができる。エージェントは、この値を用いて、スライスのRTTを更新することができる(たとえば、「updateSliceRtt(sliceID,rtt)」)。
【0042】
その後、エージェントは、将来的にRTTを決定するための新たなタイムスタンプが得られるように、転送フローを一掃することができる。一例において、これは、フローテーブルからの転送フロー(「forFlow」)の削除を含み得る。別の例においては、転送フローに対してRTTが既に計算されたことを示す値がフローテーブルに設定される。これにより、当該フローの将来的な探索において「forFlow」を無効化することができ、RTTが将来的に測定される場合、フローテーブルにおいて当該フローの別のタイムスタンプを生成することが可能となる。
【0043】
モニタリングモジュールは、TCPパケットを用いてRTTを測定したい場合、スイッチ上のエージェントにより認識されるフラグをパケットヘッダに設定することができる。エージェントは、たとえばTCPパケットに設定されたこれらのフラグに基づいて、転送フローを記録することができる。一例においては、これにより定期的なRTTテストが可能となり得る。表1の疑似コードに示すように、転送フローが有効でない場合は、パケットPの確認によって、特定のフラグがゼロに等しくないことを確かめる。たとえば、アプリケーションによって、緊急フラグ(「URG」)、SYNフラグ、またはPSHフラグを設定可能である。これらのフラグの使用によって新たなフローを識別可能であり、RTTの計算を目的として、このフローをフローテーブルに追加可能である。
【0044】
TCPヘッダ中のURGフラグは、パケットが遅延なく配信される必要があることを示し得る。SYNフラグは、クライアントとサーバとの間でTCP接続が開始となった場合に設定され得る。PSHフラグは、バッファリングデータのアプリケーションに対するプッシュをクライアントおよびサーバに命じ得る。
【0045】
スイッチは、RTTの計算を目的として、これらのフラグを追跡可能である。たとえば、受信側は、これらのフラグのいずれかが設定された場合、直ちに応答を送ることができる。これらのフラグのいずれもがTCPパケットに存在しない場合、受信側は、到着データをバッファリングし、あとで応答するようにしてもよいが、このようなパケットはRTTの計算に不適となる。たとえば、送信側が一度に1バイトのTCPパケットを送る場合、この1バイトを直ちにアプリケーションへ送る代わりに、受信側のTCPスタックは、データをバッファに格納するようにしてもよい。受信側は、さらに数個のパケットの到着を待って、アプリケーションに、より大きなデータ集合を通知するようにしてもよい。このように、データがバッファリングされる場合は、応答の遅延の可能性がある。その結果、一例においては、バッファリングによって結果が歪むため、レイテンシの正確な計算にバッファリングパケットを使用することができない。このシステムは、URG、SYN、およびPSHフラグを確認することによって、レイテンシの計算にバッファリング関連の遅延が入らないようにすることができる。
【0046】
表1において、「createFlow」は、パケットのdip、sip、dport、およびsportに基づく新たなフローの格納を可能にする。この新たなフロー(「revFlow」)には、現在時間を読み出すgetTime()等の呼び出しに基づきタイムスタンプが与えられ得る。その後、返信パケットがスイッチで受信された場合は、同じパケット情報(sip、dip、sport、dport)の使用により、フロー(「forFlow」)を取得可能である。このフローは有効なものとして検出可能であり、現在時間からタイムスタンプが差し引かれてRTTが決定される。
【0047】
一例において、各ホップでは、各スイッチがこのタイミング情報を記録し、それをモニタリングモジュールに報告してレイテンシの決定に使用することができる。
ステージ130において、モニタリングモジュールは、レイテンシ値を決定可能である。一例において、これは、スライス上の各ホップからのパケットのタイミング情報を合算してスライスRTTを決定することを含み得る。別の例において、モニタリングモジュールは、ある期間にわたるスライスのRTT情報を平均化あるいは集約する。一例においては、この集約値をスライスレイテンシ値として使用可能である。
【0048】
ステージ135において、モニタリングモジュールは、レイテンシ値とSLA閾値とを比較可能である。モニタリングモジュールは、SLAのスライス固有の閾値に対してレイテンシ値を比較することにより、スライス固有のレイテンシに関する比較を行うことができる。一例において、レイテンシが閾値を下回った場合、モニタリングモジュールはまず、レイテンシ値がある期間にわたって閾値を下回り続けていることを確認し得る。これは、スライス経路が真に変化を必要としていることを確認して、スライス経路が絶えず変化するのを防止するのに役立ち得る。ただし、閾値期間中にSLA閾値が満たされない状態が続く場合、モニタリングモジュールは、スライス経路を変更するように作用する。
【0049】
SLAレイテンシ要件が満たされない場合、モニタリングモジュールは、スライスの代替スライス経路を選択可能である。これは、ネットワーク接続性グラフを参照して、性能特性がより好適な別のルートを決定することを含み得る。一例において、ネットワーク接続性グラフには、ネットワークの物理または仮想レイヤから報告され、他のスイッチに対応する情報を格納可能である。モニタリングモジュールによって選択された代替経路は、元のスライス経路の一部ではないスイッチを含み得るため、スライスベースネットワークを通る異なる物理・仮想経路が必要となる。
【0050】
ステージ140において、モニタリングモジュールは、新たなスイッチを介する代替スライス経路を実装可能である。これは、既存のスイッチでスライス経路情報を更新して、第2のスイッチの代わりに第3のスイッチへとスライストラフィックをルーティングすることを含み得る。また、一例においては、第3のスイッチに対応する仮想レイヤにおいて、適当なVNFをインスタンス化することができる。
【0051】
図1Cは、多様な顧客にとって重要なSLA要件となり得るスループット要件に基づいて輻輳を抑える例示的な方法を示している。スループットを計算する従来の手法は、ネットワークを通じて大量のデータを定期的に送ることを含む。ただし、このソフトウェアベースの手法は、Telcoプロバイダが国全体に分散可能な大規模VSNにおいてはスケーリングしない。その代わりに、物理ネットワークのスイッチがテレマティクスデータを収集可能であるとともに、モニタリングモジュールがこのデータを集約して、全体のスライススループットを計算可能である。
【0052】
ステージ145において、オーケストレータまたはモニタリングモジュールは、エージェントをVSN中のプログラム可能なスイッチに供給可能である。これは、スイッチのコア内等のスイッチハードウェアにおいて、スイッチにエージェントを実行させることを含み得る。そして、エージェントを実行するスイッチは、複数のスライスについて、データレート情報を計算することができる。一例において、スイッチは、スライスID、Smac、Dmac、SIP、DIP、SPort、DPort、Pktレートといったフォーマットでデータレート情報を保持可能である。スライスIDは、スライスを示し得る。Smacが送信元MACアドレスを示し得る一方、Dmacは、宛先MACアドレスを示す。SIPおよびDIPはそれぞれ、送信元IPアドレスおよび宛先IPアドレスに対応し得る。SPortおよびDPortは、送信元および宛先ポートに対応し、Pktレートは、パケットレートを示し得る。
【0053】
ステージ150において、モニタリングモジュールは、第1のスライスの現在のスライス経路におけるスイッチを含む複数のスイッチから、データレート情報を受信可能である。データレート情報は、スライスおよびパケットレートを識別可能である。一例において、モニタリングモジュールは、メッセージをスイッチに送ることにより、この情報を定期的に収集する。別の例において、スイッチは、モニタリングモジュールからリクエストを受信する必要なく、モニタリングモジュールに定期的な問い合わせを行う。
【0054】
ステージ155において、モニタリングモジュールは、上記スライスおよびVSN中の他のスライスのアグリゲートスループットを決定可能である。これは、ネットワークトポロジおよびスライス経路を使用して、重複情報を除外することを含み得る。たとえば、スイッチがフローの開始ノードでない場合は、重複情報を含む可能性がある。モニタリングモジュールは、フローのループ処理により、各フローの第1のスイッチからのレート情報に基づいてスライススループットを更新することができる。これについては、
図5に関して以下により詳しく説明する。一例においては、その他のレート情報を無視することができる。
【0055】
ステージ160においては、アグリゲートスループットと閾値との比較に基づいて、モニタリングモジュールは、スライスの新たなスライス経路を実装可能である。閾値としては、SLAにおけるスライスのスループット閾値が挙げられる。レイテンシと同様に、モニタリングモジュールは、一例において、スライス経路の変更前のある期間にわたって、スループットがSLAに準拠しないことを確認し得る。オーケストレータまたはモニタリングモジュールは、上述の通り、代替スライス経路を選択および実装可能である。モニタリングモジュールは、低スループットとなっていないスイッチを含む経路を取得可能である。これにより、VSN全体にスライスを分散させて、SLA準拠を維持することが可能となり得る。
【0056】
図2Aは、テレマティクスデータに基づいて輻輳を抑える例示的なシーケンス図である。ステージ205において、モニタリングモジュールは、スライスベースネットワークの複数のスイッチS1、S2、S3をプログラム可能である。これは、スイッチ上のインターフェースへのリモート問い合わせと、スイッチで実行するパッケージの送信とを含み得る。パッケージは、エージェントを含み得る。一例においては、P4言語スクリプトを使用して、スイッチ上でエージェントを起動する。また、スライス経路等の情報をスイッチに送って、ルーティングに使用可能である。
【0057】
ステージ210において、エージェントは、スイッチ上で実行可能である。エージェントを使用して、レイテンシ情報またはデータレート情報等のテレマティクスデータをスライスごとに収集可能である。エージェント210は、スライス経路を調べ、スライスIDに基づいてパケットの次ホップを決定するロジックをさらに含み得る。本例において、スライスは、スイッチS1およびS2を含む現在のスライス経路を有し得る。当該スライスに関し、S1からの次ホップとしては、S2が挙げられる。
【0058】
ステージ220において、スイッチは、テレマティクスデータをモニタリングモジュールに定期的に送信可能である。一例において、スイッチは、エージェントに基づいて、テレマティクスデータを送るタイミングを決定する。別の例において、モニタリングモジュールは、個々のスイッチへの問い合わせによって、必要ごとにテレマティクスデータを要求する。
【0059】
ステージ225において、モニタリングモジュールは、スライスごとにテレマティクスデータを集約し、スライスがSLAの1つまたは複数の性能要件を満たしていないものと判定可能である。これは、任意の性能基準に基づいて行うことができ、レイテンシおよびスループットは、そのうちの2つの例に過ぎない。その後、モニタリングモジュールは、代替スライス経路を決定可能である。これは、他の低負荷スイッチを明らかにするネットワークトポロジグラフの解析を含み得る。本例においては、第3のスイッチS3が第2のスイッチS2よりも低輻輳となり得る。
【0060】
これに応答して、ステージ230および235において、モニタリングモジュールは、第3のスイッチS3を含み、第2のスイッチS2を除くように経路を変更することによって、スライスの新たなスライス経路を実装可能である。ステージ230において、モニタリングモジュールは、第3のスイッチS3に対応する仮想レイヤにおいてスライスの適当なVNFが動作していることを確認し得る。スライス経路が変更されると、第2のスイッチS2に対応する仮想レイヤ中のVNFは、当該スライスによって使用されなくなる。一例において、VNFの配置は、オーケストレータまたはモニタリングモジュール以外の何らかのオーケストレータプロセスにより取り扱われる。
【0061】
ステージ235において、モニタリングモジュールは、第1のスイッチS1に新たなスライス経路を通知可能である。一例において、これは、ステージ230のVNFの準備が整った後に実行可能である。この通知により、スイッチS1は、当該特定のスライスに対して次ホップをS3に変更可能であり、ステージ240において新たなスライス経路が得られる。これにより、スライスベースネットワーク全体での輻輳を抑えることができる。
【0062】
図2Bは、スライスレイテンシに基づいて輻輳を抑える例示的なシーケンス図である。ステージ242において、モニタリングモジュールは、スライスベースネットワークのスイッチから、タイミング情報を受信可能である。上述の通り、スイッチ上のエージェントは、この情報をモニタリングモジュールに伝達可能である。ステージ244において、第1のスライス経路は、スイッチS1およびS2を含み得る。これらのスイッチはいずれも、ステージ242においてタイミング情報を報告可能である。
【0063】
ステージ246において、モニタリングモジュールは、スイッチS1およびS2から受信したタイミング情報に基づいて、第1のスライスのレイテンシ値を決定可能である。ステージ248において、モニタリングモジュールは、スイッチS3からのタイミング情報に基づいて、スイッチS3を利用する異なるスライスのレイテンシ値を決定可能である。
【0064】
ステージ250においては、SLA閾値との比較により、第1のスライスにおいてレイテンシが高すぎることを明らかにし得る。これに応答して、ステージ256において、モニタリングモジュールは、第1のスライスのスライス経路を第2のスライス経路に変更可能である。ステージ252においては、これを実行するため、スイッチS3の仮想レイヤにおいて1つまたは複数の必要なVNFをインスタンス化することができる。また、設定情報をスイッチS1に送ることにより、第1のスライスの次ホップをスイッチS3に変更することができる。これにより、第1のスライスは、スイッチS2を使用しなくなるため、当該スイッチにおいて輻輳を緩和することができる。
【0065】
図2Cは、スライススループットに基づいて輻輳を抑える例示的なシーケンス図である。ステージ265において、第1のスライスは、スイッチS1およびS2を含む現在のスライス経路を有し得る。スイッチ上のエージェントは、スライスごとにデータレート情報を収集可能である。ステージ260において、スイッチは、スライス固有のデータレート情報をモニタリングモジュールに報告可能である。
【0066】
ステージ270において、モニタリングモジュールは、スライススループットを計算可能である。モニタリングモジュールは、第1のスライスおよびネットワーク中の他のスライスについてこれを実行可能である。これは、ステージ275において、重複するデータレート情報を無視することを含み得る。本例において、スイッチS2は、スイッチS2ではなくスイッチS1で開始となるフローを有する第1のスライスについて、重複するデータレート情報を報告する。いくつかの例においては、スイッチS2がS1を含む複数のスイッチからデータを受信した場合等、スイッチS1から受信したデータレート情報に対して、スイッチS2が提供するデータレート情報の一部しか重複しない。これらの例において、ステージ275は、スイッチS1と関連付けられたデータレート情報に基づいて考慮済みの重複するデータレート情報のみを無視することを含み得る。
図5において、詳細な説明および関連する議論を与える。
【0067】
ステージ280において、モニタリングモジュールは、第1のスライスのスループットがSLA要件を下回るものと判定可能である。これに応答して、ステージ285においては、第1のスライスの新たなスライス経路を実装可能である。これにより、スイッチS2の代わりにスイッチS3を使用することによって、スループットを向上可能である。
【0068】
図3は、スライスベースネットワークにおける輻輳抑制の例示的なフローチャートである。一例においては、モニタリングモジュールによって、各ステージを実行可能である。ステージ310において、VSNモニタは、ネットワーク要素からテレマティクスデータを受信する。これは、ルータ、サーバ、およびホスト等、ネットワークの任意のスイッチから任意の性能データを受信することを含み得る。VSNモニタとしては、物理サーバ上で実行される1つまたは複数のプロセスが挙げられる。サーバとしては、スライスベースネットワーク上でさまざまな動作を管理する管理クラスタの一部が挙げられる。一例において、VSNモニタは、VMware(登録商標)のvRealize(登録商標)等、VSNにおけるVNF(たとえば、仮想マシン)の動作の様子をモニタリングする仮想解析エンジンを含む。VNFは、仮想コントローラ、仮想ルータ、仮想インターフェース、仮想ローカルエリアネットワーク(「VLAN」)、ホスト仮想マシン(「VM」)、またはスイッチにより接続されたサーバ等、物理ハードウェア上で動作する他の仮想化ネットワーク機能を表し得る。また、一例において、VSNモニタは、ネットワークにおけるスイッチ等のハードウェアの性能を解析する物理アンダーレイとして作用し得る物理解析エンジンを含み得る。モニタリングモジュールが物理解析エンジンを含むことも可能である。別の例においては、モニタリングモジュールが解析エンジン全体を含むことも可能である。
【0069】
物理解析エンジンは、物理レイヤからの性能情報(たとえば、テレマティクスデータ)を利用する輻輳確認プロセスを含み得る。ステージ320において、輻輳確認プロセスは、テレマティクスデータのいずれかが輻輳を示しているかを判定可能である。輻輳は、性能データが閾値を満たさないことに基づき得る。たとえば、特定のスライスの帯域幅、RTT、レイテンシ、またはスループットがSLA閾値を下回る可能性がある。
【0070】
ステージ330においては、輻輳除去プロセスがスライスベースネットワークのファブリックトポロジにアクセスして、代替スライス経路を決定可能である。ファブリックトポロジは、他の利用可能なスイッチおよび関連する性能基準のグラフを含み得る。VSNのハードウェアは、どのVNFがどのデバイス上で動作しているかと、どのスイッチが相互に連通しているかと、を報告可能である。ハードウェアおよび仮想の両コンポーネントの発見により、このシステムは、これらを一体的にマッピングして、ファブリックトポロジを生成することができる。
【0071】
輻輳除去では、ファブリックトポロジのその他の部分およびその現在の性能に基づいて、1つまたは複数の代替スライス経路を決定することができる。物理レイヤにおいては、エージェントを実行するプログラム可能なスイッチによって性能を報告可能である。スイッチは、データレート、スループット、レイテンシ、および帯域幅等の性能情報を報告可能である。この性能情報は、輻輳の検出に使用可能である。
【0072】
物理レイヤからの性能データに基づく輻輳回避がスライス経路の変更の1つの理由となり得る。仮想レイヤにおける問題もこの決定に寄与し得る。仮想コンポーネントは、性能を仮想解析エンジンに対して別個に報告可能である。一例においては、仮想および物理の両レイヤの解析によって、スライス経路を変更するタイミングを決定する。
【0073】
一例においては、オーケストレーションプロセスがコントローラ階層を管理可能である。コントローラ階層は、1つまたは複数のデータセンタ内のさまざまなエンティティを設定して、仮想サービスネットワークを実現する。高レベルVSNコントローラは、VSNが実装されたデータセンタにおいてエンティティを設定する複数組の他のコントローラを調整可能である。いくつかの実施形態において、各データセンタは、それ自体の一連の低レベルコントローラを有する。これらのコントローラは、(たとえば、VNFを実装するVMを設定する)演算コントローラ、(たとえば、スライスセレクタとネットワークサービスとの間でデータメッセージを伝送するように転送スイッチを設定する)ネットワークコントローラ、ストレージコントローラ、および(たとえば、データセンタ間でデータメッセージを伝送するスライスセレクタおよびゲートウェイまたはそのいずれかを設定する)ソフトウェア定義のネットワーク(「SDN」)コントローラを含み得る。
【0074】
ステージ340においては、プロセスによって、ネットワーク中の代替スライス経路を設定可能である。VSNコントローラ階層は、新たなスライス経路を実装するように一体的に機能し得る。これは、仮想レイヤにおけるVNFのインスタンス化と、物理または仮想スイッチの再設定による仮想または物理レイヤの新たなスイッチへの問い合わせとを含み得る。オーケストレータプロセスは、ネットワークトポロジに基づいて、VNFインスタンス化を管理可能である。モニタリングモジュールは、メッセージを1つまたは複数のスイッチに送って、スライス経路を変更することができる。その後、将来のテレマティクスデータによって、新たなスライス経路をモニタリング可能である。
【0075】
図4Aは、VSNにおける複数のスライスを示した例示的なシステム図である。サンフランシスコ420のセルタワーにおけるネットワークデータの送受信によって、複数の端末デバイス410(本例では電話)がVSN405と通信可能である。
【0076】
セルタワーは、端末デバイス410からのパケットに対する正しいスライスを決定するスライスセレクタ425に通信結合可能である。これは、パケットタイプ、送信元および宛先IPアドレス、送信元および宛先ポート、ならびに送信元および宛先MACアドレス等のパケット情報に基づいて実行可能である。一例において、スライスセレクタ425は最初、パケットを処理して、VSNのネットワークスライスのうちの1つに割り当てる。また、スライスセレクタ425は、割り当てスライスに対する正しい一組のネットワークサービスによってパケットが処理されるように、サービスチェーン動作を取り扱うことができる。種々例において、スライスセレクタ425は、とりわけ、VM、VM内もしくはホストコンピュータの仮想化ソフトウェア内で動作するソフトウェア転送要素(たとえば、フローベースの転送要素)、またはホストコンピュータの仮想化ソフトウェア内の転送要素の外側(たとえば、VMと転送要素のポートとの間)で実行される一組のモジュールによって実装可能である。
【0077】
場合により、VSNに対して、多数のスライスセレクタ425を設定する。通信サービスプロバイダの例においては、アクセスネットワークの各セルタワー、基地局、または他の態様に対してネットワークスライスセレクタを設定可能である。通信サービスプロバイダのアクセスネットワークは、各セルタワーのエッジクラウドを含み得るとともに、このような各エッジクラウドにおいて少なくとも1つのスライスセレクタ425を設定可能である。他の例(たとえば、一組の接続データセンタ内に完全に含まれるSD-WANトラフィックの場合)においては、VMから送られたデータメッセージに対するネットワークスライス選択が(送信元VMの外側ではあるものの)データメッセージの送信元と同じホストコンピュータで発生するように、分散ネットワークスライスセレクタが設定される。
【0078】
本例においては、YOUTUBEストリーミング用の第1のスライス430および911番通報用の第2のスライス435がVSN405に存在する。これらのスライス430、435はそれぞれ、異なるSLA要件を有し得るため、VSNの1つまたは複数のスイッチに広がり得る。一例において、これらのスイッチは、インターネット全体で複数のクラウドに及ぶ可能性がある。また、これらの同じスライス430、435がニューヨーク市450において終端し得る。当該点における異なるスライスセレクタ440がスライスベースネットワークに対してネットワークトラフィックをルーティング可能である。
【0079】
図4Bは、VSNにおける複数のスライスを示した例示的なシステム図である。第1のスライス460は、スイッチR1、R3、R5、およびR6に及ぶ可能性がある。第2のスライス465は、スイッチR1、R2、R4、およびR6に及ぶ可能性がある。両スライス460、465は、サンフランシスコ420からニューヨーク市450まで及ぶ。本例のスイッチとしては、ルータが挙げられる。これらのスイッチはそれぞれ、各スライス460、465のパケットレートおよびタイミング情報を計算する。
【0080】
一例において、第2のスライスは当初、サンフランシスコ420からニューヨーク市450までのスライス経路を有する。このスライス経路は、輻輳に基づいて、スイッチR3、R5の代わりにスイッチR2、R4を使用するように変更され得る。このため、モニタリングモジュールは、スイッチR1におけるルーティングテーブルを更新して、スイッチR3の代わりにスイッチR2へと次ホップを変更可能である。また、スイッチR2、R3、R4、およびR5におけるルーティングテーブルは、新たなスライス経路を反映するように更新可能である。
【0081】
モニタリングモジュールは、輻輳を検出するため、前述のさまざまなスイッチからのパケットレートおよびタイミング情報等のテレマティクスデータを使用可能である。モニタリングモジュールは、このデータを使用して、各スライス460、465のスループットの集約を試行可能である。一例においては、スライススループットにのみ、総スライススループットを計算するための重複しないデータレート情報を必要とする。たとえば、スイッチR3およびR5は、サンフランシスコ420からニューヨーク450に向かう第1のスライス460の重複するパケットレートデータを有し得るが、スイッチR5は、マイアミ470からニューヨーク450に向かう第1のスライス460の重複しない関連するパケットレートデータを有することになる。このため、一例においては、スイッチR3からのデータレート情報が無視される一方、スイッチR5におけるマイアミ470のデータは、第1のスライス460のスループットの計算に含まれるものとする。これは、第1のスライス460が同一スライス内に、それぞれサンフランシスコ420およびマイアミ470からのフローである第1および第2の2つの異なるスループット源を有するためである。一方、スイッチR3は、R1からの重複するフロー情報のみを含む。
【0082】
図5は、スライススループットを計算するとともに、重複フローからデータを除去する方法を決定する例示的なフローチャートである。スループットを計算する他の方法も考えられるため、
図5は、1つの例示的な手法に過ぎない。ステージ505において、モニタリングモジュールは、上記説明の通り、スライスのスループットの集約を開始する。一例において、スライススループットの計算には、スライス内の各フローに関する第1のスイッチからのデータレート情報のみが必要となる。このため、一例において、モニタリングモジュールは、スライス経路内のどのスイッチでどのフローが開始となっているかを解析し、これらのスイッチからのデータレート情報に基づいてスループットを計算可能である。
【0083】
ステージ510において、モニタリングモジュールは、当該スライスのスライス経路における次スイッチSからテレマティクスデータを収集する。これは、パケットレートデータの収集を含み得る。ステージ515において、モニタリングモジュールは、次フローFのパケットレートデータを取得する。
【0084】
ステージ520において、このスイッチが当該フローの経路中の最初のスイッチである場合は、データレート情報がスライススループットの決定に関連する。その結果、ステージ525において、モニタリングモジュールは、当該フローのデータレート情報を含むようにスライススループットを更新可能である。
【0085】
スイッチが当該フローの最初の経路でない場合は、スライススループットの決定に関して、データレート情報が無視され得る。代わりに、このアルゴリズムは、ステージ515において次フローFを再び取得し、スイッチで確認すべきフローがなくなるまで、このプロセスを繰り返すことができる。
図4Bに関しては、この理由から、スイッチR5が第1のスライスのスループットと関連していたが、R3は関連していなかった。スイッチR3においては、サンフランシスコからのフローが存在するものの、当該フローはスイッチR1を起点とする。これに対して、スイッチR5では、第1のフローがスイッチR1を起点とする一方、第2のフローはスイッチR5を起点とする。
【0086】
ステージ530において、モニタリングモジュールは、未処理のフローが存在するかを判定する。モニタリングモジュールは、ファブリックトポロジへのアクセスに基づいてこれを実行可能である。ファブリックトポロジとしてはグラフが挙げられるが、これは、一例において、フロー経路および物理スイッチに基づいて、さまざまなフローを示し得る。未処理のフローが存在する場合、このアルゴリズムは、ステージ515に戻って、次フローのレート統計値を取得可能である。
【0087】
そうでない場合、ステージ535において、モニタリングモジュールは、別のスイッチが存在するかを判定可能である。存在する場合、このアルゴリズムは、ステージ510から再び開始可能である。次スイッチは、必要により、任意のフロー経路で最初のスイッチとして確認するとともに、スライススループットに含めることができる。ただし、それ以上のスイッチが存在しない場合は、ステージ540において、スライススループットの計算が完了となる。
【0088】
図6は、VSN600におけるシステム構成要素の例示的な図である。VSN600としては、1つまたは複数のクラウド620、640を含む分散Telcoクラウドネットワークが挙げられる。スライス672、678、682は、これらのクラウド620、640全体に分散可能である。
【0089】
各クラウド620、640は、ネットワーク機能仮想化(「NFV」)642のための物理および仮想インフラを有し得る。たとえば、ルータおよびサーバ等の物理スイッチ644は、VNF機能を提供するVM646またはマイクロサービスを動作させ得る。スライスは、エッジクラウド620上で実行される第1のVNFを含み得る。VNFは、1つまたは複数のvCPUを利用可能であり、一例においては、1つまたは複数のVM624が挙げられる。ただし、エッジクラウド620は、多数のVNFを実行可能であり、これは多くの場合、VNFがさまざまなスライスの一部である場合の複数のテナントを対象とする。スライスは、異なるスライスからのVNFが、共有物理ハードウェア622上で動作するVM624に依拠する場合であっても、互いの存在を認識しない状態で、機能的観点からの分離を保ち得る。
【0090】
スライス経路中の第1のVNFは、異なるクラウド640に配置可能な第2のVNFと通信可能である。たとえば、第2のVNFは、コアクラウド640の物理ハードウェア644上で動作する1つまたは複数のVM646を含み得る。また、第2のVNFは、スライス経路中のさらに別のVNFと通信可能である。一例において、これらのVNFのうちの1つまたは複数は、インターネット660への出力として作用し得る。
【0091】
1つまたは複数のユーザデバイス602は、たとえば5Gデータ接続を用いて、VSN600のスライスに接続可能である。ユーザデバイス602としては、Telcoネットワークに接続可能な任意の物理プロセッサ対応デバイスが挙げられる。例として、車両、電話、ラップトップ、タブレット、IoTデバイス、仮想現実デバイス等が挙げられる。セルタワー605等の送受信機がこれらのユーザデバイス602と送受信可能である。エッジクラウド620への入力では、スライスセレクタ608がユーザデバイス602から送られたデータを受信して、適用するスライスを決定可能である。スライスセレクタ608は、エッジクラウド中のVM624として動作することも可能であるし、またはエッジクラウド620に接続された異なるハードウェア上で動作することも可能である。一例において、スライスセレクタは、パケットヘッダ中の情報を用いて、パケットが属するスライスを決定することができる。
【0092】
分散仮想インフラを管理するため、モニタリングモジュールを有するオーケストレータ668を含めて、プロバイダは管理プロセスのトポロジ665を動作させ得る。オーケストレータ668は、異なるサーバ上または異なる仮想環境中で別個に動作するモニタリングモジュールと交互に通信可能である。本例において、モニタリングモジュールとしては、オーケストレータ668とともに機能するトポロジ665の一部が挙げられる。これらのプロセスの一例となるフレームワークがVMWAREによるVCLOUD NFVであって、これは、ネットワーク仮想化にVSPHEREを、仮想解析にVREALIZEを使用可能である。例示的なオーケストレータは、CLOUDIFYである。
【0093】
一例において、オーケストレータは、スライスおよびVNFの管理を担当し得る。これは、性能基準およびネットワーク負荷に基づく新たなスライスのプロビジョニングまたは既存のスライスの再プロビジョニングを含み得る。オーケストレータは、1つまたは複数のコアクラウド620、640中またはクラウドとは別個に配置された1つまたは複数の物理サーバ上で動作し得る。オーケストレータ668は、各スライスにどのクラウドおよびVNFが含まれるかについての経過を追うツールを提供可能である。オーケストレータはさらに、個々のテナント670、680のスライス性能を追跡して、管理コンソールを提供可能である。また、オーケストレータ668は、性能基準および負荷情報を受信して、モニタリングモジュールが新たなスライス経路を見出すべきタイミングを決定可能である。
【0094】
本例においては、第1のテナント670が複数のスライス672、674を有する。各スライス672、678は、当該スライスのVNF要件を示すスライス記録により規定可能である。VNF674、676はそれぞれ、サービスチェーンにおける異なる機能を提供可能である。
【0095】
また、SLAはスライスのさまざまな閾値性能要件を規定し得る。これらの性能要件は、レイテンシ、ラウンドトリップタイム、帯域幅等を含み得る。一例において、これらは、スライスごとのQoS要件として機能し得る。
【0096】
オーケストレータ668は、モニタリングモジュールに依拠して、スイッチ622、644からテレマティクスデータを受信するとともに、SLAが満たされているかを判定することができる。一例において、モニタリングモジュールは、スイッチ622、644にエージェント601を提供する。スイッチ622、644は、エージェント601を実行するようにプログラム可能である。また、モニタリングモジュールは、入力ポート603から出力ポート606まで、および、出力ポート606からネットワーク600中の次ホップまでパケットを移動させるのにスイッチが使用するポリシングアルゴリズムを供給可能である。また、モニタリングモジュールは、次ホップおよびこれらの次ホップに対して使用する出力インターフェース(たとえば、ポート)を決定するのにスイッチ622、644が使用するスライス経路情報も供給可能である。
【0097】
また、オーケストレータ668は、スライスセレクタ608およびスイッチ622、644の設定を変更して、スライス経路を通るトラフィックのルートが正しくなるようにし得る。これは、上記デバイスがパケット情報を比較するテーブルの変更を含み得る。たとえば、スライス選択は、パケットのパケットヘッダ中の情報に基づき得る。たとえば、スイッチまたはスライスセレクタは、レイヤ2~レイヤ4(L2~L4)ヘッダの組み合わせを使用することも可能であるし、(たとえば、レイヤ7(L7)ヘッダ中のデータに基づいてトラフィックを分類するために)深層パケット検査を実行することも可能である。たとえば、スライス選択は単に、送信元ネットワークレイヤ(たとえば、IP)アドレスを用いることにより、送信元デバイスに基づくことも可能であるし、L7ヘッダを確認することにより、トラフィックタイプまたは宛先ネットワーク領域に基づくことも可能である。いくつかの実施形態において、ネットワークスライスセレクタは、接続の各データメッセージ上で深層パケット検査を実行する必要がないように、接続をネットワークスライスにマッピングする状態を維持する。また、一部の接続については、スライス選択の実行に必要なL7ヘッダ情報を特定のデータメッセージのみが含む。
【0098】
深層パケット検査を用いてスライス選択を実行する場合、接続の最初のデータメッセージには、スライスセレクタがスライスを正しく識別するために必要とするL7ヘッダ情報が含まれていなくてもよい。たとえば、端末デバイス(たとえば、スマートフォンまたはタブレット等のモバイルデバイス、ラップトップまたはデスクトップコンピュータ、IoTデバイス、自動運転車、セキュリティシステムに属するスマートカメラ)とネットワーク領域との間の接続は、TCPハンドシェイク等の一組の接続開始メッセージによって開始となることが多い。ハンドシェイクの完了後、デバイスは、たとえばネットワーク領域を含むhttp取得メッセージを送る。デバイスとネットワーク領域との間で送信される後続のデータメッセージは、このような情報を含んでいなくてもよい。
【0099】
以上、物理スイッチに関して複数の例を説明したが、これらの例は、仮想スイッチにおいても代替実行可能である。また、オーケストレータ、仮想管理トポロジ、およびモニタリングモジュールに別々に言及したが、これらのプロセスはすべて、一体的に動作し得る。これらの例は、どのプロセスがどのステップを実行するかを制限するものではない。その代わりに、モニタリングモジュールは、上記ステージを実行する仮想管理トポロジの任意の部分と考えられる。
【0100】
本明細書に開示の例の規定および実施を考慮することにより、当業者には、本開示の他の例が明らかとなるであろう。上記方法の一部を一連のステップとして提示したが、当然のことながら、1つまたは複数のステップが同時に起こることもあり得るし、重なって起こることもあり得るし、異なる順序で起こることもあり得る。提示のステップの順序は、可能性を示したに過ぎず、これらのステップは、任意の好適な様態で実行または実施可能である。さらに、本明細書に記載の例のさまざまな特徴は、相互に排他的ではない。むしろ、本明細書に記載の如何なる例の如何なる特徴も、その他任意の好適な例に組み込み可能である。上記規定および例は、ほんの一例に過ぎないと考えられ、本開示の真の範囲および思想は、以下の特許請求の範囲により示されるものとする。