(57)【要約】【解決手段】本発明は、ネットワークにおいてパケットフロー群を転送する方法であって、前記パケットフロー群は前記ネットワークにおける複数のエンドホスト（６）から発信され、前記パケットフロー群は所定のルーティング経路群を介して前記複数のエンドホスト（６）のそれぞれからシンクノード（８）へ送信される。エンドホスト（６）のパケットフロー群のルーティング経路はＳＤＮコントローラー（４）の制御下にある１つ又は複数のＳＤＮスイッチを含み、前記１つ又は複数のスイッチ（２）は前記エンドホスト（６）に接続された少なくとも１つのポートを有するエッジスイッチ（７）を含む。前記各エッジスイッチ（７）による前記複数のエンドホスト（６）のうちの特定のエンドホストからのパケットフローの転送は、ドアオープナーパケットと呼ばれる専用パケットにより可能にされ、前記ドアオープナーパケットは前記各スイッチ（２、７）により処理されると、前記パケットフローをそのルーティング経路に沿って次のスイッチ（２）へ転送するために前記各スイッチ（２、７）内での転送ルールの稼働又は設定を実現する、方法に関する。【選択図】図３
2019510424.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークにおいてパケットフロー群を転送する方法であって、
前記パケットフロー群は前記ネットワークにおける複数のエンドホスト（６）から発信され、前記パケットフロー群は所定のルーティング経路群を介して前記複数のエンドホスト（６）のそれぞれからシンクノード（８）へ送信され、
エンドホスト（６）のパケットフロー群のルーティング経路はＳＤＮコントローラー（４）の制御下にある１つ又は複数のＳＤＮスイッチを含み、前記１つ又は複数のスイッチ（２）は前記エンドホスト（６）に接続された少なくとも１つのポートを有するエッジスイッチ（７）を含み、
前記各エッジスイッチ（７）による前記複数のエンドホスト（６）のうちの特定のエンドホストからのパケットフローの転送は、ドアオープナーパケットと呼ばれる専用パケットにより可能にされ、前記ドアオープナーパケットは前記各スイッチ（２、７）により処理されると、前記パケットフローをそのルーティング経路に沿って次のスイッチ（２）へ転送するために前記各スイッチ（２、７）内での転送ルールの稼働又は設定を実現する、方法。
【請求項２】
前記各スイッチ（２、７）での前記ドアオープナーパケットの処理は前記各スイッチ（２、７）のデータプレーンにおいてのみ実行される、請求項１に記載の方法。
【請求項３】
スイッチ（２、７）の状態テーブル（１０）及びフローテーブル（９）は、前記スイッチ（２、７）での前記ドアオープナーパケットの処理が前記各パケットフローについての新しい又は変更されたエントリーで前記状態テーブル（１０）の更新を引き起こすように設定される、請求項１に記載の方法。
【請求項４】
前記新しい又は変更された状態エントリーは、その設定以来特定の時間が経過後その削除を起動するタイムアウトを用いて構成される、請求項３に記載の方法。
【請求項５】
前記ＳＤＮコントローラー（４）は、ドアオープナーパケットをコントロールプレーンメッセージとしてスイッチ（２、７）へ送ることにより前記ドアオープナーパケットの前記スイッチ（２、７）への供給を起動する、請求項１〜４のいずれかに記載の方法。
【請求項６】
前記ＳＤＮコントローラー（４）は、スイッチ（２、７）に時間により起動されるパケット生成を設定することによりドアオープナーパケットの前記スイッチ（２、７）への供給を起動する、請求項１〜５のいずれかに記載の方法。
【請求項７】
エッジスイッチ（７）は、前記ＳＤＮコントローラー（４）にオンデマンドでドアオープナーパケットの供給を求める、請求項１〜６のいずれかに記載の方法。
【請求項８】
前記ドアオープナーパケット群は、それらが関連付けられた前記各パケットフローと同じルーティング経路を介して前記シンクノード（８）へ送られる、請求項１〜７のいずれかに記載の方法。
【請求項９】
前記ドアオープナーパケット群のヘッダーは前記パケット群を専用ドアオープナーパケット群として特定するタグを含み、及び／又は前記ドアオープナーパケット群のヘッダーはそれらが関連付けられている前記各パケットフローの識別を含む、請求項１〜８のいずれかに記載の方法。
【請求項１０】
エッジスイッチ（７）は、前記エッジスイッチ（７）のエッジポートを介して受信されるいずれのドアオープナーパケットもドロップする、請求項の１〜９のいずれかに記載の方法。
【請求項１１】
好ましくは請求項１〜１０のいずれかに記載の方法を実行するためのネットワークシステムであって、
ＳＤＮコントローラー（４）と、
前記ＳＤＮコントローラー（４）の制御下にあるいくつかのＳＤＮスイッチ（２）と、
複数のエンドホスト（６）と、
シンクノード（８）と、
前記エンドホスト群（６）から発信されるパケットフロー群の前記シンクノード（８）への送信を可能にする所定のルーティング経路群とを含み、
エンドホスト（６）のパケットフロー群のためのルーティング経路は、前記ＳＤＮスイッチ群（２）の１つ又は複数を含み、前記１つ又は複数のＳＤＮスイッチ群（２）は前記エンドホスト（６）に接続された少なくとも１つのポート（５）を有するエッジスイッチ（７）を含み、
前記スイッチ群（２、７）は、ドアオープナーパケットと呼ばれる専用パケットにより前記複数のエンドホスト（６）のうちの特定のエンドホストからのパケットフローの転送を可能にし、前記ドアオープナーパケットは前記各スイッチ（２、７）により処理されると、前記パケットフローをそのルーティング経路に沿って次のスイッチ（２）へ転送するために前記各スイッチ（２、７）内での転送ルールの稼働又は設定を実現する、ネットワークシステム。
【請求項１２】
前記エンドホスト群（６）は、そこから前記ＳＤＮコントローラー（４）が前記データ送信装置（６）のパケットフロー送信の時間及び間隔を照会できるＡＰＩを含む、請求項１１に記載のシステム。
【請求項１３】
前記エンドホスト群（６）はセンサー群及び／又はスマートグリッドのスマートメーター群を含む、請求項１１又は１２に記載のシステム。
【請求項１４】
請求項１〜１３にいずれかに記載の方法及び／又はシステムにおいて採用されるように構成されたフローベースのプログラマブルネットワーク装置、特にＳＤＮスイッチ（２）。
【請求項１５】
請求項１〜１３にいずれかに記載の方法及び／又はシステムにおいて採用されるように構成されたコントローラー実体、特にＳＤＮコントローラー（４）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、ネットワークにおいてパケットフロー群を転送する方法に関わる。本発明は更に、対応するネットワークシステムに関わる。
【背景技術】
【０００２】
本発明の実施形態の用途の技術分野は、例えば、非常に多数のスマートメーターなどのセンサーがネットワークインフラストラクチャーに接続された、いわゆる「スマートシティ」及びそれと同等のシナリオである。このようなセンサーの多くは、非常に少ない頻度で、例えば、１時間に１回、又は１日に１回、データをＩｏＴ（物のインターネット）データベース又はサーバに送信する場合がある。センサーは事前にこのデータを中央のＩｏＴサーバに送り込む、又は後者が一定の間隔で又はオンデマンドでセンサーをポーリングする。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
恒常的なフロールールをネットワークの各センサーに設定した場合、ネットワークのスイッチ、特にＩｏＴサーバにより近いスイッチのフローテーブルが直ぐにオーバーロードしてしまう。アップリンク方向では、（すなわち、センサーからサーバへの方向）送信先ＩＰアドレスに基づくアグリゲート転送によってこの問題の多くは軽減されるが、より粒状のフロールールを必要とするダウンリンク方向ではこの問題は避けられない。
【０００４】
現在、センサーからＩｏＴサーバ又は他のシンクへパケットを伝送するネットワークインフラストラクチャーのフローベースのプログラマブルネットワーク装置（例えば、ＳＤＮスイッチ）に事後的にフロールールを設定することは可能である。この場合、センサー（又はそのＩｏＴゲートウェイ）はそのデータパケットをイングレススイッチに送信する。ここで、イングレススイッチは、ＳＤＮネットワークを想定しかつマッチングルールがないと想定した場合、ＳＤＮコントローラーに照会してオンデマンドでフロールールを取得する。このルールは関連するタイムアウト値を有していてもよく、それによりしばらくして消滅する。この方法は（“スマートシティ”ネットワークなどの異種システムにおける合理的な前提と思われる、各センサーは全てのデータパケットを同時に送信しないという前提で）時間とともにフロールールのエントリーを分散するので、フロールールのオーバーロード問題が軽減される。しかしながら、そのためにスイッチとＳＤＮコントローラー間のシグナリング負荷が増大する。数百万のセンサーが一定間隔で転送経路に沿って数百万のメッセージ交換を行うことになる。これは本質的に問題とみなされてもよい。
【０００５】
代替的な方法として、フローテーブルの「拡張」の実装があげられる（例えば、Roberto Bifulco and Anton Matsiuk: “Towards Scalable SDN Switches: Enabling Faster Flow Table Entries Installation”, in Proceedings of the 2015 ACM Conference on Special Interest Group on Data Communication (SIGCOMM’15). ACM, New York, NY, USA, 343-344, DOI=http://dx.doi.org/10.1145/2785956.2790008又はNaga Katta, Omid Alipourfard, Jennifer Rexford, and David Walker: “Infinite CacheFlow in software-defined networks”, in Proceedings of the third workshop on Hot topics in software defined networking (HotSDN ’14). ACM, New York, NY, USA, 175-180, DOI=http://dx.doi.org/10.1145/2620728.2620734）に記載されるもの）。例えば、スイッチのＣＰＵを用いて多数のエントリーを保持することが可能なソフトウェアフローテーブルを実装してもよい。しかしその場合、データプレーントラフィックの処理に関する転送処理量及びスケーラビリティが限定されてしまう。
【０００６】
従って、本発明の目的は、関係するフローテーブルやコントロールプレーンをオーバーロードすることなく、転送ソリューションが多数の（例えば、数百万の範囲の）ＩｏＴセンサーなどのエンドホスト送信データにスケールされるようにネットワークにおいてパケットフローを転送する方法及びネットワークシステムを改良及び発展させることである。
【課題を解決するための手段】
【０００７】
本発明によれば、上記の目的は、ネットワークにおいてパケットフロー群を転送する方法であって、前記パケットフロー群は前記ネットワークにおける複数のエンドホストから発信され、前記パケットフロー群は所定のルーティング経路群を介して前記複数のエンドホストのそれぞれからシンクノードへ送信され、エンドホストのパケットフロー群のルーティング経路はＳＤＮコントローラーの制御下にある１つ又は複数のＳＤＮスイッチを含み、前記１つ又は複数のスイッチは前記エンドホストに接続された少なくとも１つのポートを有するエッジスイッチを含み、前記各エッジスイッチによる前記複数のエンドホストのうちの特定のエンドホストからのパケットフローの転送は、ドアオープナーパケットと呼ばれる専用パケットにより可能にされ、前記ドアオープナーパケットは前記各スイッチにより処理されると、前記パケットフローをそのルーティング経路に沿って次のスイッチへ転送するために前記各スイッチ内での転送ルールの稼働又は設定を実現する、方法により達成される。
【０００８】
更に、上記の目的は、ネットワークシステムであって、ＳＤＮコントローラーと、前記ＳＤＮコントローラーの制御下にあるいくつかのＳＤＮスイッチと、複数のエンドホストと、シンクノードと、前記エンドホスト群から発信されるパケットフロー群の前記シンクノードへの送信を可能にする所定のルーティング経路群とを含み、エンドホストのパケットフロー群のためのルーティング経路は前記ＳＤＮスイッチ群の１つ又は複数を含み、前記１つ又は複数のＳＤＮスイッチ群は前記エンドホストに接続された少なくとも１つのポートを有するエッジスイッチを含み、前記スイッチ群はドアオープナーパケットと呼ばれる専用パケットにより前記複数のエンドホストのうちの特定のエンドホストからのパケットフローの転送を可能にし、前記ドアオープナーパケットは前記各スイッチにより処理されると、前記パケットフローをそのルーティング経路に沿って次のスイッチへ転送するために前記各スイッチ内での転送ルールの稼働又は設定を実現する、ネットワークシステムにより達成される。
【０００９】
本発明によれば、上記の目的はイベントベースのやり方で、すなわち、（エンドホストからのパケットフローの送信である）イベントが発生する前にジャストインタイムでフロールールの設定を実現することにより達成可能であることが認識された。本発明の実施形態は、ステートフルなパケット処理を可能にしＳＤＮコントローラーなどのコントロール実体によりプログラマブルだが毎回コントローラーを参照する必要のないＳＤＮスイッチなどのフローベースのプログラマブルネットワーク装置の定義に基づいて構築される。特に、このようなスイッチはネットワークイベントの観察に基づいてその内部状態を更新できる（またそれにより内部アクションを起動することができる）。本発明の実施形態の背後にある概念は、各スイッチが、センサーなどの許可されたエンドホストのニーズについての知識を取得し、通信フローを開始し、この情報を用いてこのセンサーのトラフィックシンク（例えば、ＩｏＴサーバ）への転送動作を統治するフロールールを自立的に「設定する」又は「稼働させる」ことである。
【００１０】
コントロールプレーンに負荷を与える事後的なルール設定の代わりに、本発明の実施形態はジャストインタイムでのフロールール設定を実現する。事後的な場合と同様、この方法は（例えば、Dusi, M.; Bifulco, R.; Gringoli, F.; Schneider, F.: “Reactive logic in software-defined networking: Measuring flow-table requirements”, in Wireless Communications and Mobile Computing Conference (IWCMC), 2014 International, vol., no., pp.340-345, 4-8 Aug. 2014に記載されるように）経時的にフローテーブルのエントリーの分散を可能にし、その一方でコントローラーとの対話の回避を可能にする。
【００１１】
より詳細には、本発明の実施形態によれば、ドアオープナーパケットと呼ぶ専用パケットが、エンドホストからのパケットフローのためのイングレススイッチであるエッジスイッチに設定される。そのようなパケットがエッジスイッチで処理されると、各パケットフローを次のスイッチへそのルーティング経路に沿って転送する又は最終的な宛先へ転送するための転送ルールが当該エッジスイッチ内で稼働又は設定される。そのような設定が一度なされると、各スイッチは、エンドホストによる実際のデータパケット送信（又はセンサーからデータをポーリングするためのサーバからの各要求）の前にジャストインタイムで、コントローラーとの対話なしに自立的に該当するフロールールを稼働させる（及び非稼働にする）ことができる。ここで「ジャストインタイムで」とは、センサーからのデータの転送が実際の送信に近い設定可能な長さの時間窓の間可能になることを意味する。それぞれのコントローラーとの対話なしに各スイッチへの転送フロールールの時間決めされた又はジャストインタイムの生成又は設定を起動するそのような方法又はシステムを提供することにより、各スイッチにおける高粒度のトラフィック転送ルールの数がスケールされる、すなわち、フロールールのスケーラビリティが達成される。上記のフローテーブルの「拡張」と比べ、本ソリューションはデータプレーントラフィックの処理に関してよりスケーラブルである。これは、本ソリューションが高速スイッチのＡＳＩＣ（Application Specific Integrated Circuit：特定用途向け集積回路）だけを必要とするからである。また、各スイッチのＣＰＵが既にオーバーロードしているシナリオでは、ソフトウェアフローテーブル実装を用いることができない。更に、ジャストインタイムのルール設定のセキュリティ関連の利点はソフトウェアフローテーブルを用いる方法により無効化されてしまう。これは、この場合、フロールールが常に利用可能になってしまうからである。
【００１２】
要約すると、本発明の実施形態は、経時的にフローエントリーを配信するジャストインタイムでのステートフルＳＤＮ装置への高粒度の転送ルールの設定を可能し、それにより低頻度でのみ通信を行う多数の装置のスケーラビリティの向上を可能にする。これは、ＳＤＮコントローラーとの対話なしに、すなわち、スイッチにより自立的に、又は経路上シグナリングを介して行うことができる。
【００１３】
本発明の一実施形態によれば、各スイッチでのドアオープナーパケットの処理をスイッチのデータプレーンでのみ実行してもよい。
【００１４】
本発明の一実施形態によれば、スイッチの状態テーブル及びフローテーブルを、前記スイッチでの前記ドアオープナーパケットの処理が前記各パケットフローについての新しい又は変更されたエントリーで前記状態テーブルの更新を引き起こすように設定してもよい。これにより、特定のパケットフロー、すなわち、ネットワーク内の特定のエンドホストからのパケットフローのための転送ルールの稼働は、前記特定のパケットフローについての新しい又は変更された状態エントリーを用いて適時に行われた前記状態テーブルの更新により起動される。一実施形態によれば、状態テーブルの更新は、前記フローテーブルの転送ルールに含まれる状態遷移アクションにより実行してもよい。具体的に、前記ドアーオープナーは、パケットを送信する際そのフローが可能にされなくてはならない情報を保持してもよい。フローテーブルのエントリーは、前記ドアーオープナーにマッチした場合、それに応じて状態テーブルのエントリーを設定してドアーオープナーに含まれるフローについての状態エントリーを構成してもよい。
【００１５】
一実施形態によれば、前記新しい又は変更された状態エントリーは、その設定以来特定の時間が経過後その削除を起動するタイムアウトを用いて構成されてもよい。これにより、パケットフローの実際の送信時に近い（実装されたタイムアウト値によって設定可能な長さの）短い時間のみエンドホストのために可能な「送信窓」を開けることができる。これにより潜在的なアタッカーによるエンドホストのデータ、例えば、センサーデータの遮断又は操作が困難になるため、ネットワークの安全が大幅に向上する。タイムアウトを用いる代わりに、最後のパケットの転送後にルールの除去が可能である場合に多くのアプリケーションシナリオ（例えば、スマートグリッド）において所定の（及び公知の）数の連続するパケット（多くの場合、１つのみ）が個々のセンサーにより送信されるという事実を活用してフロールールの設定を自動的に解除してもよい。
【００１６】
一実施形態によれば、前記ＳＤＮコントローラーはドアオープナーパケットをコントロールプレーンメッセージとしてスイッチへ送ることにより前記ドアオープナーパケットの前記スイッチへの供給を起動してもよい。その代わりに、前記ＳＤＮコントローラーが各スイッチにサポートされる場合、前記ＳＤＮコントローラーは時間により起動されるパケット生成をスイッチ自体に設定することによりドアオープナーパケットの当該スイッチへの供給を起動してもよい。そのために、両ケースの前提条件として、前記コントローラーは特定のエンドホストとの通信を有効にする必要性についての知識を取得してもよい。これは、ひとたび新しいエンドホストがネットワークシステムに接続されたときに静的及び／又は手動の構成を介して、又はエンドホストがこのために備える場合があるＡＰＩ（Application Programming Interface：アプリケーションプログラミングインタフェース）を検索することを通じて、又は機械学習手法を介して行ってもよい。いずれの場合でも、コントローラーはこの知識を用いてドアオープナーパケットの生成を設定することになる。
【００１７】
一実施形態によれば、エンドホストから前記シンクノードへのデータの転送は、固定された時点でのみデータ送信を有効にする代わりにオンデマンドで実行してもよい。この場合、前記エッジスイッチは前記ＳＤＮコントローラーにオンデマンドでドアーオープナーパケットの供給を要求してもよい。
【００１８】
一実施形態によれば、前記ドアオープナーパケット群は、それらが関連付けられた前記各パケットフローと同じルーティング経路を介して前記シンクノード（８）へ送られてもよい。これにより、特定のエンドホストからのパケットフローのルーティング経路上の他の全てのスイッチは、前記エンドホストの実際のパケットフローが各スイッチに到着する前にジャストインタイムで自動的に、すなわち、コントローラーとの対話なしに必要な転送ルールを設定する。各パケットフローと同じルーティング経路に沿った前記ドアーオープナーパケットの転送は、ドアーオープナーパケットのヘッダーへ組み込まれる場合があるパケットフローのＩＰ宛先アドレスに基づいて転送を実行することにより行ってもよい。
【００１９】
一実施形態によれば、ドアーオープナーパケット群は、それらのヘッダーが当該パケット群を専用ドアオープナーパケット群として特定するタグを含むように生成されてもよい。このようなタグを用いることにより、前記エッジスイッチだけでなく下流側スイッチも、適切な状態テーブルエントリーを設定する又は稼働する必要性について知らされることになる。
【００２０】
ドアーオープナーはパケットフロー毎に生成される、すなわち、各パケットフローはそれ自体のドアーオープナーパケットを有する。一実施形態によれば、特定のドアーオープナーパケットが関連付けられている各パケットフローの識別が各ドアーオープナーパケットのヘッダーに組み込まれてもよい。これらのフロー識別データは、各スイッチにドアーオープナーに含まれるパケットフローのためにまさに適切な状態エントリーを構成できるようにする。
【００２１】
一実施形態によれば、前記ネットワークシステムはドアーオープナーが信用されるソースによってのみ生成可能であることを保証してもよい。これは、前記エッジスイッチのエッジポート、すなわち、制御された前記ネットワークの一部ではない装置に接続されたポートから受信されたいずれのドアーオープナーパケットもドロップする構成により実現されてもよい。
【００２２】
本発明の実施形態によれば、前記コントローラーがエンドホスト毎のパケット生成の時間及び間隔に関する知識を取得できるように、これらのエンドホストはそこから前記コントローラーが必要な情報を照会することが可能なＡＰＩ（Application Programming Interface：アプリケーションプログラミングインターフェース）を含んでもよい。本発明の主要な用途シナリオによれば、前記エンドホスト群はセンサー群及び／又はスマートグリッドのスマートメーター群を含んでもよい。一般に、これらのホストのパケット送信の時間及び間隔についての知識は、一度新しいホスト／センサーが接続されると静的又は手動の構成を介して、又は機械学習方法を介して取得できる。
【００２３】
本発明の内容を有利なやり方で設計し発展させる方法がいくつもある。このため、従属する請求項、及び図示された、例としての本発明の好適な実施形態についての以下の説明を参照されたい。図に補助された本発明の好適な実施形態の説明と関連して、本発明の内容の一般的に好適な実施形態及び更なる進展が説明されよう。
【図面の簡単な説明】
【００２４】
【図１】図１は、本発明の実施形態が適用可能なネットワークの一般的概念を代表的に示す概略図である。
【図２】図２は、本発明の実施形態による状態テーブルとフローテーブルを備えたネットワークスイッチを示す概略図である。
【図３】図３は、本発明の実施形態によるドアオープナーソリューションを示す概略図である。
【図４】図４は、本発明の実施形態によるドアオープナーが実装されたステートフルＳＤＮネットワークスイッチを示す概略図である。
【発明を実施するための形態】
【００２５】
以下に詳細に説明するように、本発明の実施形態は、コントロールインターフェース３を露出するいくつかのフローベースのプログラマブルネットワーク装置（例えば、ＳＤＮスイッチ２）を含むネットワークシステム１を想定しており、コントロールインターフェース３はフローベースのプログラマブルネットワーク装置を構成又は設定するために用いることができる。また、一般性を失うことなく、簡素化のために、各装置は論理的に中央のコントローラー実体４（例えば、ＳＤＮコントローラー４）により制御されるものとする。しかし、当業者には理解されるように、本発明は、フローベースの各ネットワーク装置が異なるコントローラーにより制御される場合にも、それらのコントローラーが互いにメッセージを交換できるのであれば適用可能である。コントローラー４は、コントロールチャネルによってネットワークシステム１における装置（以後、相互交換可能に「フローベースのプログラマブルネットワーク装置」若しくは短く「スイッチ」又は「ＳＤＮスイッチ２」と呼ぶ）のそれぞれに接続されている。各スイッチ２は、本発明の実施形態が適用可能なネットワークシステム１の一般的概念を示す図１に典型的に示されるように、他のスイッチ２又はエンドホストに接続可能な一組のポート５（インプットポート５ａ及びアウトプットポート５ｂ）を有する。エンドホストに接続されたポート５は「エッジポート」と呼ばれる。１つ又は複数のポートを有するスイッチ２は「エッジスイッチ７」と呼ばれる。
【００２６】
また、図１に示されるように、各スイッチ２は更にフローテーブル（ＦＴ）１０を備える。フローテーブル１０にはフローテーブルエントリー（ＦＴＥ）が含まれる。ＦＴＥは、ＦＴＥが適用されるネットワークパケットをパケットのヘッダーフィールドの値を指定することにより特定するマッチ部と、マッチされたパケットに適用されるアクションを指定するアクション部と、当該ＦＴＥがどのパケットにもマッチしない場合その時間の経過後に当該ＦＴＥを削除しなければならない時間を指定するアイドルタイムアウトとからなる。各スイッチ２のＦＴ１０内のＦＴＥの組は、そのスイッチ２がどのようにネットワークパケットを転送するかを規定する。ＦＴＥのアクションにコントロールチャネルを介したコントローラー４へのパケットの送信が含まれていてもよい。本発明の文脈において、スイッチ２からコントローラー４へのネットワークパケットの移転を「packet_in」と呼ぶ。packet_inには以下の情報が含まれる：それを生成したネットワークパケット、そこからそれが送信されるスイッチの識別子、及びパケットが受信されたスイッチ２のインプットポート５ａの識別子。スイッチ２はＦＴＥが削除されるたびにコントローラー４に通知するように構成されてもよい。
【００２７】
加えて、図２に示されるように、各スイッチ２は状態テーブル９を備えてもよい。状態テーブルのエントリーは所定のネットワークフローの状態を示す。例えば、（センサーやスマートメーターなどの）ネットワーク内のエンドホスト６により生成されたパケットがスイッチ２に入り、状態テーブル９内のエントリーの１つにマッチした場合、スイッチ２内でそのような状態情報を保持するメタデータにより当該パケットの質が改善される。また、各ＦＴＥがこの状態情報にマッチしてもよい。更に、ＦＴＥのアクションに所定のフローのアクションset_stateが含まれていてもよい。そのようなアクションset_stateは、所定の状態テーブルのエントリーについて、状態テーブル９に含まれる状態情報を修正する。これにより、ネットワークパケットを受信次第、フローテーブル８を用いて所定のフローの状態遷移を実行することができる。状態テーブルのエントリーもＦＴＥもアイドルとハードのタイムアウトの両方に関連付けられている。この種のスイッチのそれ以外の又は類似した特性／能力に関する詳細は、Giuseppe Bianchi et al.: “OpenState: Programming Platform-independent Stateful OpenFlow Applications inside the Switch”, SIGCOMM Comput.Commun.Rev.44, 2 (April 2014), 44-51から得ることができる。
【００２８】
本発明の実施形態の以下の記述との関連において、ＳＤＮネットワーク、例えば、OpenFlow技術に基づくＳＤＮネットワークがそれらの実施形態が適用されるネットワークシステムとして想定される。実際、ＳＤＮネットワークは上記の全ての特性を示す。ただし、当業者には理解されるように、本発明はそのような特性を示す他のいずれのネットワークにも適用可能である。以下、「フロールール」、「転送ルール」、及び「ＦＴＥ」という用語は折々に交換可能に用いられる。
【００２９】
図３は、イベントベースのフロールール設定を専用パケット（以後「ドアオープナーパケット」と呼ぶ）を用いることにより実行する本発明の一実施形態を示す。本実施形態は、概して、フロー識別データを運搬し実際のフローのパケットが転送される前にフローの経路を横切るデータプレーンパケットを用いてネットワークスイッチへの転送ルールの設定を起動するシステムに関する。
【００３０】
具体的に、図３は図示しないＳＤＮコントローラーの制御下にあるいくつかのＳＤＮスイッチ２を有するネットワークシステム１のセグメントを示す。スイッチ２の１つ（図３の中で左手のもの）は、複数のエンドホスト６に接続されたエッジスイッチ７として機能する。これらのエンドホスト６は、随時（少量の）データを所定のルーティング経路を介してＩｏＴサーバなどのシンクノード８に送信するセンサーなどの装置であってもよい。図示された実施形態の以後の説明の文脈において、エンドホスト６からシンクノード８までのルーティング経路には（送信データのためのイングレススイッチとしての）エッジスイッチ７に加えて（図３においてコアスイッチとして示される）更に３つのスイッチ２が含まれると仮定する。
【００３１】
図示された実施形態において、コントローラー４はエンドホスト６との通信を可能にする必要性についての知識を保有すると仮定する。例えば、コントローラー４は特定のエンドホスト６がデータを定期的に、例えば、毎日９：００に、又は毎月最初の日の１２：００に送信することを知っている。いずれの場合でも、以下に詳細に説明されるように、コントローラー４はこの知識を用いてドアオープナーパケットの生成を設定することになる。
【００３２】
ドアオープナーパケットの生成が、所定ネットワークフローの経路上の第１のスイッチで、すなわち、図３の実施形態におけるエッジスイッチ７で起動される。ドアオープナーの生成は様々なやり方で起動できる。例えば、コントローラー４は、図４に示すように、コントロールプレーンメッセージをエッジスイッチ７に送ることによりドアオープナーの生成を起動してもよい。或いは、エッジスイッチ７がそのような機能をサポートするという条件で、コントローラー４が時間で起動されるパケット生成をエッジスイッチ７自体に設定してもよい。
【００３３】
ドアオープナーパケットがステートフルＳＤＮスイッチであるエッジスイッチ７の入力ポート５ａで受信されたとき起きることが図４に示されている。ドアオープナーパケットのヘッダーには、パケットを専用ドアオープナーパケットとして特定する一個の情報が含まれる。また、ドアオープナーパケットはフローに固有のドアオープナーパケットである、すなわち、各フローはそれ自身のドアオープナーパケットを有することに留意することが重要である。これは、その受信トラフィックがドアオープナーを起動したエンドホスト６を特定する情報を含むドアオープナーパケットにより達成されてもよい。図４に示される実施形態では、ドアオープナーパケットは「フローＡ」として示される特定のフローと関連付けられている。
【００３４】
図示の実施形態において、（センサーなどのエンドホスト６からのデータ送信の期限を過ぎたことによる）イベントの起動はＦＴＥにより実行される。当初、すなわち、エンドホストからのデータ送信の発生が予定されていない期間、エッジスイッチ７の状態テーブル１０はフローＡに状態「DEFAULT」を割り当てる（ID 1を持つ）エントリーを含んでいる。これにより、フローＡはその後エッジスイッチ７のフローテーブル９により処理されると、ID 3を持つＦＴＥにマッチする、すなわち、フローＡはドロップされる。（以後「D」で示す）ドアオープナーパケットがエッジスイッチ７に到着すると、このパケットはID Dを持つ状態テーブル１０のエントリーにマッチし、それにより状態「DEFAULT」を割り当てられる。そのため、ドアオープナーパケットＤがエッジスイッチ７のフローテーブル９により処理されると、このパケットはID 1を持つＦＴＥにマッチする。
【００３５】
このID 1を持つＦＴＥは、状態テーブル１０の一部のエントリー（例えば、その通信を有効にする必要のあるエンドホスト６に関係するエントリー）の状態を設定するset_action stateを用いて構成される。具体的に、図示の実施形態によれば、（エンドホスト６のうちの特定の１つからの特定のフローＡに関連するスイッチ２においてフロールールを有効にするためにスイッチ２に提供される）ドアオープナーパケットＤは、スイッチ２のフローテーブル９のＦＴＥ ID 1とのマッチングにより、このドアオープナーパケットに示されたフロー、すなわち、フローＡに対して状態エントリー「OK」の設定を実行する、すなわち、ドアオープナーパケットＤは、図４に示すように、フローＡを状態「OK」へ状態遷移させる。その結果、フローＡはスイッチ２に到着すると、状態テーブル９のＦＴＥ ID 2にマッチして転送される。この状態エントリーは１０秒のタイムアウトが満了した後消滅する。換言すれば、１０秒のタイムアウトの後、状態エントリーは削除され「転送窓」は閉められる。すなわち、このエンドホスト６から送信されたデータはもはや転送されない。
【００３６】
イングレス、すなわち、エッジスイッチ７は、例えば、コントローラーにより生成された起動メッセージに応答して、又は時間で起動されるパケット生成により、上記のように所定のエンドホスト６のためのドアオープナーを生成する。その後、エッジスイッチ７はドアオープナーパケットを生成し、それをエンドホスト６により送信されるパケットフローによっても使われる同じアウトポート５ｂ、すなわち、当該フローのシンクノード８への経路上の次の下流側スイッチ２へ送る。当該フローの経路に沿った各スイッチ２において、ドアオープナーはエッジスイッチ７で行ったのと同じやり方でフロー固有の転送ルールの設定を起動する。エンドホスト６の実際のデータパケットは、ドアオープナーが伝達された後に初めて転送される。その結果、ジャストインタイムのフロールール設定がフロー経路全体に沿って実現される。
【００３７】
特定の実施形態によれば、ドアオープナーパケットは、その受信トラフィックがドアオープナーを起動したエンドホスト６（例えば、センサー）を特定する情報を含む。下流側スイッチ２は、ドアオープナーパケットを受信次第、エンドホスト６のIDを抽出し、当該フローのために新しい状態テーブルエントリーを生成する。この方法の利点は、イングレススイッチだけがドアオープナーの生成に関わる必要があり、一方、ネットワーク１の他の全てのスイッチ２はドアオープナーが受信されたときパケットの転送のために自動的に構成されることである。実際、経路上の他のすべてのスイッチ２が、装置データが到着する直前にオンデマンドで必要なルールを設定する。これらは全てコントローラー４との対話なしに行われる。
【００３８】
再度、ドアオープナーパケットがエッジスイッチ７により生成されること、及びドアオープナーはフロー固有のドアオープナーである、すなわち、各フローはそれ自体のドアオープナーパケットを有することに留意されたい。そのため、ドアオープナー実装の一実施形態によれば、単にエンドホスト６のパケットにタグを付けて下流側スイッチ２に対して状態テーブル１０に新しいエントリーを設定する必要性について知らせてもよい。
【００３９】
スケーラビリティと低いオーバーヘッドという利点に加えて、上記の実施形態はセキュリティ関連の利点も有する。第１に、実際のデータ送信に近い非常に短い時間だけ「有効な」フロールールを有することにより、ネットワーク内のアタッカーがセンサー６に侵入する又はホストのデータを取得することが困難になる。上記時間以外ではエンドホスト６に向けられたパケットは転送できず、またエンドホスト６は基本的に不可視である。第２に、イベントで起動されるフロールール設定により、接続されたエンドホスト６のためのトラフィック生成及び転送の機会は基本的に制限される。“スマートシティ”などの文脈では、非常に異種のソースからの（センサーという形態の）エンドホスト６が多数存在することになる。その場合でも、（データシート又は任意の情報源によって）１期間に１回のみデータを生成すると期待されるエンドホスト６はそれ以上の頻度でネットワークにデータを送り込むことはできないだろう。これは、イングレススイッチ７は事前に設定された時間の外で該当するフロールールを持つことがないからである。
【００４０】
シンクノード８（例えば、ＩｏＴサーバ）からのエンドホスト６データへの（定期アクセスではなく）オンデマンドアクセスもまたこの方法により可能であることに留意されたい。ただし、この場合、イングレススイッチ７は事後モードを用いてコントローラー４に対して対応するドアオープナーを要求する必要がある。コントローラー４はその後、予め構成されたフロールールを検索して各エンドホスト６に設定し場合によってはドアオープナーを各フローの転送経路に沿って次の下流側スイッチ２に送るとイングレススイッチ７によって解釈されるメッセージを送り返すことになる。この場合、イングレススイッチ７にとってはコントローラーとの１往復の通信が必要であるが、転送経路上の他の全てのスイッチ２はオンデマンドで再度必要なフロールールを稼働及び設定することができる。
【００４１】
最後に、本発明の意味においてドアオープナーを用いるネットワークは当該ネットワークの外で生成されたいずれのドアオープナーパケットもドロップされるようにすべきであることに留意されたい。これは、事実上、ネットワーク１の全てのイングレススイッチ７に、スイッチ７のエッジポート、すなわち、制御されたネットワーク１の一部ではない装置に接続されたエッジポートから来るどのマッチするドアオープナーパケットもドロップするドロップルールを設定することに相当する。
【００４２】
ここで説明した本発明の変形例や他の実施形態が、本発明が関係し上記の説明や添付の図面に示された内容の恩恵を受ける当業者により想到されよう。従って、本発明は開示された特定の実施形態に限定されるべきではなく、変形例や他の実施形態が添付の特許請求の範囲に含まれることが意図されていると理解すべきである。ここでは特定の用語が使われているが、それらは限定する目的ではなく一般的及び説明的意味で使われている。
【符号の説明】
【００４３】
１  ネットワークシステム
２  ＳＤＮスイッチ
３  コントロールインターフェース
４  ＳＤＮコントローラー
５  ポート
６  エンドホスト
７  エッジスイッチ
８  シンクノード
９  フローテーブル
１０  状態テーブル
１１  データ送信装置／センサー
【図１】
2019510424.tif 000003
【図２】
2019510424.tif 000004
【図３】
2019510424.tif 000005
【図４】
2019510424.tif 000006
【国際調査報告】
2019510424.tif 000007
2019510424.tif 000008