JP2023505720A - ネットワークトラフィック識別デバイス - Google Patents

Abstract

【解決手段】ネットワークデータパケットを受信するように適合された少なくとも１つのネットワークデバイスを備えるネットワークトラフィックデバイスであって、前記少なくとも１つのネットワークデバイスは、少なくとも１つの識別パケットの場所を特定するためにネットワークデータパケットをフィルタリングし、少なくとも１つのサンプルパケットを選択するために前記ネットワークデータパケットをサンプリングする、ネットワークトラフィックデバイスが開示される。前記少なくとも１つのネットワークデバイスは、前記少なくとも１つの識別パケットと、前記少なくとも１つのサンプルパケットとを分析器へ転送する。所定のサンリングルレートは、前記少なくとも１つのネットワークデバイスによって選択されたサンプルパケットの数を決定する。【選択図】図８

Description

本発明は、ネットワーク上におけるトラフィックの識別に関し、より詳しくはラインレートの速度でのデータの処理に関する。

様々なネットワーキングプロトコルは、メッセージ又はデータを小さいパケットに分割し、小さいパケットは、それぞれ宛先アドレスに送信される。各パケットが通る宛先アドレスへの経路は同一でない場合があり、それにもかかわらず、パケットが到着すると、元のメッセージを再作成するために再度組み立てられる。

各パケットは、ヘッダと、任意でペイロードとを有し得る。ペイロードは、送信されている特定用途向けのデータを含むことが可能である。ヘッダは、パケットの送信元アドレス、パケットが向かっている宛先アドレス、プロトコル、及びポートなど、いくつかの識別詳細を含む。ヘッダは、他の詳細の中でも、パケット長及びプロトコルメタデータなどの他の属性を更に含むことが可能である。

ある用途のために送信されるデータの複数のパケットは、パケットのストリームと考えられ、フローを形成する。フローのペイロードは、全パケットの結合ペイロードであり、この結合ペイロードは、再構成されると、送信された元のデータを反映する。フロー中のパケットのそれぞれは、同一の送信元アドレス、宛先アドレス、及びプロトコルを有し得る。例えばポートなどの他の属性も利用可能な場合がある。

送信元アドレスと宛先アドレスがわかっている場合、その間でフローが流れているネットワークが識別されることが可能である。同様に、フローのサービスのタイプは、プロトコル及びポートによって判断されることができる。特定のポート番号は、共通のサービス及び用途に対して通常割り当てられる。例えば、伝送制御プロトコル（ＴＣＰ）のポート２５は、Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）を指し、サーバ間での電子メールのルーティングのために使用される。同様に、ＴＣＰのポート８０は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を指し、ウェブサービスのために使用される。

パケットは、パケットの宛先アドレスに注目するアドレスルーティングスイッチ及び送信元アドレス／宛先アドレス並びに／若しくはプロトコル及びポートに注目するフロールーティングスイッチを含む異なるデバイスによって、ネットワークをわたってルーティングされる。

これらのルータ及びスイッチは、非常に高性能で特定のタスク（ルーティング及びスイッチング）を実行することに特化している。例えば、小さい（１ラックユニット）データセンタスイッチは、それぞれが１００Ｇｂｐｓラインレートワイヤースピード対応の３２個のポートを有する場合があり、双方向帯域幅及び６．４Ｔｂｐｓのスループットを与え、ポート間レイテンシが固定されている。これは、スイッチのハードウェアが、スイッチングタスクの専用及び特化の特定用途向け集積回路（ＡＳＩＣ）を使用するために実現可能である。

これらの速度は、スループット性能を犠牲にしない限り、ｘ８６プロセッサなどの汎用プロセッサでは実現可能ではない。

更に、通常、ファイアウォール、ＷＡＮ最適化、ディープパケットインスペクション（ＤＰＩ）、又は他のネットワーク機能などの他の特化機能を実行するコンピュータネットワーク内には他のアプライアンスが存在し得る。これらの特化した機能のより複雑な性質のため、これらのアプライアンスは、ＡＳＩＣベースのスイッチと同一の帯域幅及びスループットを達成できない。例えば、最上位のＦｏｒｔｉｎｅｔモデル３９８０Ｅ次世代ファイアウォールは、５ラックユニットを占有し、１００Ｇｂｐｓの速度が可能であるがｅｎｔｅｒｐｒｉｓｅ ｔｒａｆｆｉｃ ｍｉｘを用いて２８ＧｂｐｓのＮＧＦＷ（次世代ファイアウォール）スループットのみが可能である１０個のポートを有する。

データセンタコアスイッチのスループットとネットワークアプライアンスとの不一致は、コストと規模という経済的及び物流上の理由により、大規模なネットワークの全体にわたっていくつかのネットワークアプライアンス又は機能を配備することは非現実的であることを意味する。ネットワークのサイズが拡大すると、ネットワークのコアは、スイッチ及びルータのみから構成される傾向にあり、ネットワークアプライアンスは、ネットワークの境界上、又はＤＭＺ若しくは境界ネットワークなどのネットワーク間に存在する。これは、特に、電気通信及びデータセンタネットワークが該当する。

コアスイッチのスループットが、ネットワークアプライアンスよりも大幅に大きいというこの特定の問題は、よく知られている。

ディープパケットインスペクション（ＤＰＩ）の特定のシナリオの場合、その問題に対して知られている解決策は、トラフィックをバイパスすることである。この解決策のネットワークスイッチによって、ＤＰＩアプライアンスのいずれかの側のみがそのアプライアンスを通して特定のトラフィックをルーティングし、残りをその周りにバイパスする。この発想は、スループットが限定されたＤＰＩシステムを通って流れるネットワークトラフィック量を減らすことである。ただし、このアプローチの問題は、ネットワークスイッチがパケットのヘッダに含まれた情報に基づいてのみトラフィックをルーティングする場合があり、このレベルの情報の精度は十分ではない。

この点を補足説明するために、その大部分が、ＨＴＴＰ及びＱＵＩＣ（Ｑｕｉｃｋ Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ Ｉｎｔｅｒｎｅｔ Ｃｏｎｎｅｃｔｉｏｎｓ）に続くＨＴＴＰＳ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ）であるインターネットトラフィックの典型的な混合を考える。オーストラリアのインターネットトラフィックの考えられる内訳は、５５％がストリーミングビデオ、２０％が一般的なウェブ閲覧、１５％がダウンロード、及び１０％がその他である。ストリーミングビデオは、ＨＴＴＰＳ及びＱＵＩＣ上、一般的な閲覧はＨＴＴＰＳ及びＨＴＴＰ上、ダウンロードはＨＴＴＰＳ及びＨＴＴＰ上で配信され、その他はその混合である。ネットワークスイッチは、プロトコルポート（ＨＴＴＰＳ／ＨＴＴＰ／ＱＵＩＣ）及び送信元／宛先のＩＰアドレス領域によってのみトラフィックを区別できる。ＤＰＩソリューションの利点を最も活かすためには、ストリーミングビデオはバイパスされるが、パケットのペイロードのインスペクション、すなわち従来のネットワークスイッチではできないことをせずに、ストリーミングビデオを他のＨＴＴＰＳ及びＱＵＩＣトラフィックから確実に分離することは可能ではない。

更に補足説明するために、ＨＴＴＰＳ又はＱＵＩＣストリームなどの暗号化トラフィックの場合を考える。企業以外の環境（トラフィックの復号が可能でない）に配備されたＤＰＩソリューションは、ＨＴＴＰＳ及びＱＵＩＣストリームの非暗号化ヘッダからのみ情報を抽出できる。特に、Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ（ＴＬＳ）証明書情報及びＳｅｒｖｅｒ Ｎａｍｅ Ｉｎｄｉｃａｔｉｏｎ（ＳＮＩ）のフィールドは、どのアプリケーション／ドメインにそのストリームが関連付けられているかを判断するのに有用である。この情報は、ストリーム内の特定の１つのパケット、すなわち識別パケットにおいて通常入手可能である。このストリームのパケットの残りは、暗号化されて理解できないようになっており、パケットの数及びストリームのサイズを測定するためにのみ有用である。

ダウンロード又はストリーミングビデオなどの存続時間の長いストリーム（「エレファントフロー」）は、長時間にわたって数百又は数千のパケットから構成され、一般的なウェブ閲覧などの存続時間の短いストリーム（「マイスフロー」）よりも不均衡に広い帯域幅を使用する。

これは、コアスイッチ技術の能力がネットワークアプライアンスの制限に起因して実現されることができないという基本的な問題に主に起因して、ＤＰＩアプライアンスに対して多大な負荷をかける。

ネットワーク管理の他の問題は、特定の使用の識別を試みることである。例えば、図１にて図示されるデータフローを考える。図示されているのは、ネットワークリンク８２にわたって伝送されるＮｅｔｆｌｉｘ８０、Ｆａｃｅｂｏｏｋ７９、ＹｏｕＴｕｂｅ（登録商標）７７、及び一般的な電子メール７８からのトラフィックに関係した４つのデータフローである。例示的な目的のため現実的ではないが、各データフローは５つのパケットのみを有すると仮定する。各アプリケーションは、その識別パケット３２及び３５とともに、非識別パケット３１を有する。目的がＦａｃｅｂｏｏｋ３５の使用を識別することである場合、明らかなオプションは、図２のソリューションを採用し、分析８３のために各パケットを送信することであり、すなわちＤＰＩを適用し、送信元１０と宛先１４との間で伝送された各パケットの全パケットペイロードに注目する。これは、高価なオプションとなる場合があり、膨大なサイズのネットワークに対しては非現実的である。

図２のブルートフォースオプションの代替案は、図３に示すようなアドレスルーティングを使用することであり、パケットがネットワークによってフィルタリングされる。図示する例において、１０．０．０．０／８ネットワークからの全トラフィックは分析１１のために送信される。これは、分析対象であるデータの量を大幅に減らすが、異なるネットワーク上に存在することが認識されることが望ましい使用の明らかなリスクがある。

更なる代替案は、図４に示すようなフロールーティングであり、パケットがサービスによってフィルタリングされる。この場合、ウェブサービスパケットのみが分析１１のために送信される。実践において、これは、全インターネットトラフィックのうちの大部分、おそらく９０％がウェブサービス関連である場合、図２のオプションからのわずかな改善にとどまる。

したがって、送信されるデータの量によって、何の用途に用いられているかが識別できなくなるという問題が存在する。

ネットワーク管理が直面する他の問題は、大規模なトラフィック分析である。データセンタ及び企業ネットワークにおいて、輻輳及びレイテンシを減少させるために、ネットワーク上でデータトラフィックを管理することが望まれる。すなわち、データが自由に流れて、ユーザエクスペリエンスが悪影響を受けないことを確実にすることが望まれる。これは、例えば、少数のエレファントフローが利用可能な帯域幅を消費する場合、多数のマイスフローに悪影響を与えるという問題であり得る。困難な点は、ネットワークトラフィックを管理するために、ネットワークトラフィックを分析して、ボトルネック及びネットワーク輻輳を判断する必要があることである。

大規模なネットワーク及びデータセンタは、数千のネットワークリンクを有する場合がある。それらのリンクのそれぞれは、１０Ｇから１００Ｇ＋の高速で動作可能である。通常、診断プローブ又はテストアクセスポイント（ＴＡＰ）のハードウェアデバイスは、データを監視するためにネットワークの特定のポイントに挿入される。これらのプローブは高価であり、単一のポートのみに取り付け可能で、およそ１００Ｇの限定されたスループットを有する。

プローブデバイス４１は、図５に示すようなデータセンタネットワークの特定のポート８４に手動で取り付けられ得る。そのポート上のトラフィック全体は、その後分析されることが可能である。問題は、単一のポートのみが注目可能であり、プローブを異なるポート４０に変更するには時間がかかり得ることである。図６は、ＴＡＰスイッチ８６の代替のアプローチを示す図であり、各ポートが、専用ＴＡＰスイッチ８６に取り付けられ、プローブデバイス４１もスイッチ８６に取り付けられる。リンク及び分析対象のポートの変更は迅速となり得るが、一度に単一のポートのみが調査され得る８５という同じ問題が存在する。図７は、ＴＡＰスイッチ８６をＴＡＰネットワーク８９と置き換え、トラフィック全体をポート又はリンクから送信するのではなく、選択されたフローを複数のポート８７、８８からプローブデバイスに送信する。図４に関連して上述した制限と同様に、ＴＡＰネットワークも、いずれのフローを送信するかの識別と、データの量を分析できる実用性とに制限がある。

したがって、ネットワークアドミニストレータがトラフィックフローを事前に監視して管理できないという問題がある。むしろ、問題が発生すると、受身的にしか問題に対処できない。

したがって、ネットワーク上でトラフィックを識別し、好ましくは、コアスイッチを使用した場合に利用可能なスループットを利用する代替的な手法が必要である。

一般化して表現すると、ネットワークトラフィックから識別パケットをフィルタリングし、更にネットワークトラフィックからパケットの所定の割合をサンプリングできるネットワークデバイスが提供される。

第１の態様において、
ネットワークデータパケットを受信するように適合された少なくとも１つのネットワークデバイスを備えるネットワークトラフィックデバイスであって、
少なくとも１つのネットワークデバイスは、少なくとも１つの識別パケットの場所を特定するためにネットワークデータパケットをフィルタリングし、少なくとも１つのサンプルパケットを選択するためにネットワークデータパケットをサンプリングする、ネットワークトラフィックデバイスが提供される。

識別パケット及びサンプルパケットは、その後、分析器へ送信されることが可能であり、分析器は、受信パケットにディープパケットインスペクション（ＤＰＩ）を実行し得る。

ネットワークデバイスは、プログラマブルな特定用途向け集積回路（ＡＳＩＣ）を含み、データプレーンでのみ動作することが期待される。

ネットワークデバイスによって選択されたサンプルパケットの数は、所定サンプリングレートに基づくことが可能である。サンプルパケットは、無作為に選択されてもよく、或いは、各Ｎ番目のネットワークデータパケットを選択することによって選択されてもよく、ここで、Ｎは所定数である。Ｎは、所望のサンプリングレートを考慮して選択され得る。

好ましくは、分析器は、受信パケットと、およそ４％又は５％であり得る所定サンプリングレートとからネットワークデータパケットのフロー情報を推定する（又は実質的に再構築する）。このデバイスは、いずれの分析器が各受信パケットの転送先であるかを決定する負荷分散装置を更に備えてもよい。

他の態様において、本発明は、
データプレーンでのみ動作する少なくとも１つのネットワークデバイスであり、少なくとも１つのネットワークデバイスは、ネットワークトラフィックを形成するデータストリームからデータパケットを受信するように適合され、少なくとも１つのネットワークデバイスは、各識別パケットの場所を特定するためにデータパケットをフィルタリングし、所定の数のサンプルパケットを選択するためにデータパケットをサンプリングするように適合される、ネットワークデバイスと、
受信パケットに対してディープパケットインスペクションを実行するように適合され、受信パケットは、少なくとも１つの識別パケット及び少なくとも１つのサンプルパケットを含む、少なくとも１つの分析器と
を備えるネットワークトラフィックデバイスを提供する。

本発明の例示的な実施形態が、添付図面を参照して以下で説明される。本発明の更なる特徴及び利点も、付随する明細書から明らかとなるであろう。

例示的なシナリオを示す図である。 ブルートフォース手法を用いた図１のシナリオに対する１つの可能な解決策を示す図である。 アドレスルーティングを使用した図１のシナリオに対する他の可能な解決策を示す図である。 フロールーティングを使用した図１のシナリオに対する他の可能な解決策を示す図である。 手動プローブを使用したネットワーク診断アプローチを示す図である。 ＴＡＰスイッチを使用した図５に対する代替的なアプローチを示す図である。 ＴＡＰネットワークを使用した図５に対する他の代替的なアプローチを示す図である。 本発明を使用した、可能なハードウェアセットアップを説明する図である。 図８の代替図であり、垂直に拡大する本発明の機能を例示する。 水平に拡大する本発明の機能を例示する図である。 本発明を使用した、可能なシステムセットアップを説明する図である。 ＨＴＴＰパケットのスクリーンショットを示す図である。 ＨＴＴＰＳパケットのスクリーンショットを示す図である。 本発明による、プログラマブルネットワークスイッチを構成する１つのアプローチのフロー図である。 本発明のアプローチを例示する図である。 本発明を使用した、図１のシナリオに対する可能な解決策を示す図である。 本発明を使用した、図５に対する代替アプローチを示す図である。 本発明を使用した、可能なトラフィック管理アプローチを示す図である。

以下の説明は、当業者が本発明を作成及び使用可能なように提示され、特定の用途及びその要件の文脈において提供される。開示の実施形態に対する様々な修正は、当業者にとっては非常に明らかであり、本明細書で定義される全般的な原理は、本発明の趣旨及び範囲から逸脱せずに他の実施形態及び用途に適用され得る。したがって、本発明は、示された実施形態に限定されることが意図されておらず、本明細書で開示された原理及び特徴と一致する最も広い範囲を有することが意図される。

本発明は、ネットワーク上のトラフィックの識別に対する新規のアプローチを説明する。本システムは、ラインレートの速度で動作可能であり、それによって、既知のネットワークアプライアンスに依存した現在の技法が直面するボトルネックを回避できる。好適な実施形態において、本発明は、ネットワークトラフィックのコピーを、識別パケットをフィルタリングしてそれらの識別パケットのみをＤＰＩアプライアンスに送信するデバイスを通して送信する。好適な構成において、そのデバイスは、更に、非識別パケットをサンプリングし、計数又は分析のために、１０００個毎に１つなど、所定の割合をＤＰＩまで送信する。このデバイスは、ネットワークスイッチの速度で動作し、処理のためにＤＰＩまで有用なパケットのみを送信することができ、有益である。

本発明は、Ｂａｒｅｆｏｏｔ Ｎｅｔｗｏｒｋｓから入手可能なＴｏｆｉｎｏなどのプログラマブルＡＳＩＣチップを利用可能である。ＡＳＩＣチップは、Ｐ４プログラミング言語によるソフトウェア開発キット（ＳＤＫ）を使用してプログラム可能であり、ラインレートの速度で動作し得る。このチップは、受電ネットワークスイッチとして機能可能であり、特定のパケットヘッダ条件及び／又は特定のパケットペイロード条件に一致するパケットのコピーを、処理／インスペクションのために他のデバイスに送信するように構成され得る。

本発明の他の実施形態は、チップによって抽出されたパケットの処理及びインスペクションを行うサーバ（ｘ８６又は同様のもの）である。この分析プロセスの出力は、他のデバイス／システムに供給され、オペレータが閲覧できるようにし、及び／又は後の使用のために収集されることが可能である。

基本的な構成において、図８に示すように、一実施形態は、複数の高速ポート（例えば、３２ｘ１００Ｇｂｐｓポート）を用いてラインレートで動作する、完全にプログラム可能なスイッチングＡＳＩＣチップを含む、ハードウェアネットワークデバイス１１を備える。ネットワークデバイス１１は、送信元のネットワーク１０から、例えばＳｗｉｔｃｈ Ｐｏｒｔ Ａｎａｌｙｓｅｒ（ＳＰＡＮ）ポート又は光学ＴＡＰのいずれかを介して、入力を受信する。一実施形態では、ネットワークデバイス１１の出力は、識別パケットを処理するために分析デバイス１２に渡され、好ましくは、所望の分析出力１３を生成するためにサンプリングされたパケットストリームに渡される。

この構成において、送信元ネットワーク１０は、ネットワークトラフィックのコピーをネットワークデバイス１１に提供する。これは必須ではないが、ネットワークデバイス１１がインラインで動作している時にトラフィックを通過するため、帯域外で動作しているときに適用可能である。ネットワークデバイス１１は、送信元ネットワーク１０自体の内部にも配置されることも可能であり、本発明の特定の機能に加えて従来のネットワークスイッチング機能を実行できる。いずれにしても、プログラマブルネットワークデバイス１１は、送信元ネットワーク１０から入力を受信する。

分析デバイス１２は、フィルタリング後、及びパケットカプセル化後の出力を受信するために、ネットワークデバイス１１に接続される。

一実施形態によれば、送信元ネットワーク１０からネットワークデバイス１１を介して分析デバイス１２の手前までの全ては、ラインレートでデータプレーンにおいて動作する。コントロールプレーンが関与する必要はなく、レイテンシの原因と、可能性のあるボトルネックとを取り除く。すなわち、スループットは利用可能な帯域幅と等しく、スループット制限はなく、ネットワークデバイス１１はラインレートで動作する。このため、分析デバイス１２はフィルタリング後にネットワークデバイス１１によって出力された構成量のネットワークトラフィックを扱うのに十分に拡大されるはずである。この点に関して、この構成は、必要に応じてオペレータによって変更されることが可能であり、全てのパケットから、皆無のパケット、ある割合のパケットへの何かが分析デバイス１２に渡されることが可能となり得る。出願人は、現実的なシナリオとして、およそ４％から５％のサンプリングレートが、ネットワークフローの用途を識別して、ネットワークフローの統計情報を正確に推定できるために十分であると考える。

ネットワークデバイス１１は、フィルタとして動作するように構成され得る。例えば、ネットワークデバイス１１は、送信元ネットワーク１０中を流れる各パケットのコピーを受信し、フィルタ基準に適合するパケットのみを分析デバイス１２に送信するように構成され得る。

典型的なネットワークデバイス１１は、１００Ｇｂｐｓの速度でそれぞれ動作する３２個のポートを有し得る。それらのポートのうちの１つ又は２つは出力として使用可能であり、３０個までのポートが入力のために提供される。４％のサンプリングレートを３０ｘ１００Ｇｂｐｓの入力に適用すると、３，０００Ｇｂｐｓ＊４％＝１２０Ｇｂｐｓの出力が得られる。ネットワークリンクがピークで平均して常に８０％のみが使用されている場合、これは１２０Ｇｂｐｓ＊８０％＝９６Ｇｂｐｓの出力となる。これは、単一の１００Ｇｂｐｓ出力ポートによって対応可能であり、分析デバイスのサイズに応じて、１つ又は複数の分析デバイス１２によって対応可能である。

入力ポートの数が増加すると、本発明の解決策は、より多くのハードウェアを配備して中間層を追加することによっても拡大可能である。これは、従来のシステムにはないオプションである。図１０に示すように、複数のネットワークデバイス１１及び１６は、送信元ネットワーク１０からのデータを受信及びフィルタリングするために相互接続し、フィルタリングされた出力を複数の分析デバイス１２にわたって分散する。これは、集約ネットワークデバイス１６が容量を超えて動作するまで、必要に応じて水平方向に拡大できる。一実施形態によれば、現段階において、解決策全体は、再現されて、無制限に拡大することができ、フローデータ１３のレコードは、重複除去され、必要に応じて統合される。

これを例証するために、図１１では、２１Ｔｂｐｓのトラフィック９０がユーザ１５とインターネット１７との間を流れるネットワークが存在すると仮定する。これは、２０１９年９月現在のＡｕｓｔｒａｌｉａｎ Ｎａｔｉｏｎａｌ Ｂｒｏａｄｂａｎｄ Ｎｅｔｗｏｒｋの住宅インターネット接続容量のほぼ２倍を表す。演習の目的で、上記のネットワークは、８０％という非現実的に高い使用率を有し、システムは４％のレートでサンプリングしている。この構成によって、本発明において、ユーザとインターネットとの間を流れる２１Ｔｂｐｓのトラフィックのコピー９１は、エッジで動作している１８ｘネットワークデバイス１１に供給される。各１００Ｇｂｐｓ双方向リンク９３は、一対の１００Ｇｂｐｓ単方向リンク入力９２に変換される。エッジのプログラマブルネットワークスイッチのそれぞれは、データ９７をおよそ９６Ｇｂｐｓの出力９６へフィルタリング及びサンプリングする。これは、集約機能を実行する中間ネットワークデバイス１６を介して分析デバイス１２に供給される。４５ｘ分析デバイスの要件は、通常は非常に大容量を有することとされるが、それぞれが４０Ｇｂｐｓのネットワークトラフィックのみを処理できると仮定する。

これは、ネットワークパケットのサンプリングを実行できない現在利用可能なネットワークパケットブローカーのソリューションと比較して好ましい場合がある。本発明の再現を試みるために、ネットワークパケットブローカー構成は、１，３５０ｘサーバ（それぞれが４０Ｇの入力を処理）又は専用「サービスアプライアンス」の追加を必要とする場合がある。したがって、現在利用可能なネットワークパケットブローカーのソリューションは、全トラフィックを４％でサンプリングするために、ネットワークパケットブローカースイッチ自体に加えて、ネットワーク中を流れるネットワークトラフィックのすべてを処理するために十分なサーバ／サービスアプライアンスを必要とするというボトルネックにつながり得る。

本発明は、依然としてカットスルー処理を実行しながら、ラインレートの速度でデータプレーンにおいてのみ、識別パケットを、無作為及び選抜の両方を行って、パケットをサンプリングできる。有益なことに、本明細書で提示した場合のように、他のデバイスへのルーティング、ラインレートの速度の犠牲、パケットの遅延、又はコントロールプレーンの関与を必要としない場合がある。更に、フローベースのソリューションではないため、処理されるフローの数に制限はない。

既存の分析ツール／プローブデバイスは、サンプリングされたデータではなく、ネットワークトラフィックの完全なフィードを受信することを想定しているため、本発明の実施形態の分析デバイス１２は、異なるデータ構成を受信する。分析デバイス１２は、識別パケットとともに、無作為にサンプリングされた他のパケットも受信し、それらのカプセル化を解除して、分析を実行する。これは、フローデータとともに、他の出力も生成できるため、有益である。

分析デバイス１２は、汎用コンピュータ（ｘ８６）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）、又は専用ハードウェアに実装され得る。

スイッチ構成
一実施形態では、ネットワークデバイス１１は、関心パケットの識別を可能とし、識別されたパケットがどのように扱われるかを決定するように（例えば、「テーブル」によって）構成可能である。

好ましくは、パケットを特定の関心ヘッダと、理想的には、ペイロードの少なくとも最初の６バイトと照合するマッチングテーブルが構成される。完全一致も効果があるが、効率性のために、この照合は、３値／ワイルドカードをベースとしたものである方がよい。３値による照合は、オペレータが、全ての可能性のある一致値を徹底的に列挙する必要があるよりも、「ｄｏｎ’ｔ ｃａｒｅ」値を容易に構成できる。

上記のマッチングテーブルを採用すると、ＨＴＴＰ及びＨＴＴＰＳの識別パケットの検出とともに、ＨＴＴＰ及びＨＴＴＰＳトラフィックの４％でのサンプリング（他の全トラフィックを無視）の一致ルールが以下のように作成される。
１．ＨＴＴＰ
ａ．「ＧＥＴ／」（ＨＴＴＰ ＧＥＴ）で始まるペイロードを有する８０（ＨＴＴＰ）の送信元ポート又は宛先ポートのいずれかを有するＴＣＰパケットを選択し、ルール優先度１によって１００％でサンプリングする
ｂ．８０（ＨＴＴＰ）の送信元ポート又は宛先ポートのいずれかを有するＴＣＰパケットを選択し、ルール優先度２によって４％でサンプリングする
２．ＨＴＴＰＳ
ａ．０ｘ１６（１６進数）のペイロードの第１バイト及び０ｘ０１（１６進数）のペイロードの第６バイト（ＨＴＴＰＳ ＣｌｉｅｎｔＨｅｌｌｏ）を有する４４３（ＨＴＴＰＳ）の送信元ポート又は宛先ポートのいずれかを有するＴＣＰパケットを選択し、ルール優先度１によって１００％でサンプリングする
ｂ．４４３（ＨＴＴＰＳ）の送信元ポート又は宛先ポートのいずれかを有するＴＣＰパケットを選択し、ルール優先度２によって４％でサンプリングする
各セットにおける第１のルールは、識別パケットの全てを抽出し、各セットの第２のルールは、非識別パケットの４％をサンプリングする。

ＨＴＴＰ識別パケット
一実施形態では、ＨＴＴＰ接続のために、本発明はＨｏｓｔヘッダを含むパケットに関心を示す。一般に、ＨＴＴＰリクエストは、ＧＥＴ、ＰＯＳＴ、ＰＵＴ、ＤＥＬＥＴＥ、ＨＥＡＤ、ＯＰＴＩＯＮＳ、ＴＲＡＣＥ又はＰＡＴＣＨリクエストメソッドのいずれかを含むパケットをクライアントからサーバへ発行することによって開始する。これらはパケットペイロードの先頭に現れ、そのため、それらの語で始まるパケットが選択されるように、システムは、ワイルドカードを用いて照合を行うことができる。他のパケットがそれらの文字で無作為に始まり得ることは可能であるが、非常に低頻度であり、ランダムサンプルとして分析サーバによって扱われる場合がある。

図１２のスクリーンショットは、ＧＥＴリクエストからのＨＴＴＰパケットを示す。パケットプロトコル２０はＴＣＰであり、宛先ポート２１は８０であり、パケットペイロード２２の最初の数バイトはＧＥＴ／である。このパケットのコピーを分析デバイス１２へ送信するために、フィルタがネットワークデバイス１１において適用され得る。その後、分析デバイス１２は、ＨＴＴＰ ＧＥＴリクエストが送信されるサーバの名称を判断するように、Ｈｏｓｔ：２３を発見するためにパケットペイロードをより詳しく注目することができる。

ＨＴＴＰが暗号化されていないため、コンテンツは関心のものであり得る。ただし、一般的に、大部分のインターネットトラフィックは暗号化されている。ランダムサンプリングをＨＴＴＰパケットに適用することによって、ネットワークデバイス１１は、ＨＴＴＰパケットの小さい代表的部分を分析デバイスへ送信できる。これによって、分析デバイスは、フロー中のパケットの数、フローのサイズ、フローがいつ始まったか、フローがいつ終了したかを推定できる。所与のパケットを選択するために適用されたサンプリングレートを認識することによって、分析デバイスは、単純な外挿によってフロー中のパケットの数及びフローのサイズを推定できる。例えば、２０分の１の確率でサンプリングされたパケットが受信された場合、システムは２０を、フロー中のパケットの数に追加でき、パケットのサイズをフローのサイズへ２０倍する。

ＨＴＴＰＳ識別パケット
一実施形態では、ＨＴＴＰＳパケットに対して、システムは、Ｃｌｉｅｎｔ Ｈｅｌｌｏ２５のハンドシェイクパケット内に存在するＳｅｒｖｅｒ Ｎａｍｅ表示フィールド２４及び／又はＳｅｒｖｅｒ Ｈｅｌｌｏハンドシェイクパケット後の証明書内に存在するＣｏｍｍｏｎ Ｎａｍｅフィールドに注目する。

ＨＴＴＰＳパケットは、ＴＣＰプロトコル２０と、４４３であるポート２１によって識別可能である。Ｃｌｉｅｎｔ Ｈｅｌｌｏハンドシェイクパケットは、クライアントからサーバへ送信され、それによって宛先ポートは４４３となる。Ｓｅｒｖｅｒ Ｈｅｌｌｏハンドシェイクパケットはサーバからクライアントへ送信され、それによって送信元ポートは４４３となる。ＴＬＳハンドシェイクパケットは、０ｘ１６（１６進数）バイトの第１のペイロード（ハンドシェイク）と、０ｘ０１（１６進数）バイト（Ｃｌｉｅｎｔ Ｈｅｌｌｏ）又は０ｘ０２（１６進数）（Ｓｅｒｖｅｒ Ｈｅｌｌｏ）の第６のペイロードとを有する。

図１３は、Ｃｌｉｅｎｔ Ｈｅｌｌｏを含むＨＴＴＰＳネットワークパケットを示すスクリーンショットを示す図である。パケットのペイロード内のより深い部分では、Ｓｅｒｖｅｒ Ｎａｍｅ表示２４の拡張部は、リクエストが送信されたサーバの名称を示す。

ＱＵＩＣなどの他のプロトコルに対して識別パケットを識別するために、同様のアプローチが使用され得る。ただし、機械学習モデルによって発見されたパケットシグニチャなど、他の一致基準が使用され得ることも理解されるであろう。

フローハッシュ
マッチングテーブルによってパケットが選択され、ルールが１００％未満のサンプリングレートを有する場合に送信されない可能性があると認識すると、そのパケットを分析デバイス１２に送信するかに関する決定がなされる。単一の分析デバイス１２は小規模ネットワークに対して十分である一方、本発明を水平方向に拡大するために、システムは、複数の分析デバイスにわたって負荷を分散することが理想的であり、その場合、システムはいずれの分析デバイス１２にパケットを送信するかを決定できる。

それを行う際に、単一フローのパケットが異なる分析デバイスに送信される場合の相関問題を避けるために、単一フローの全パケットが同一の分析デバイス１２に送信されることが望ましい場合がある。このプロセスを支援するために、本発明の好適な構成は、パケットのフローハッシュを計算する。

各フローは、プロトコル並びに送信元アドレス／宛先アドレス及び送信元ポート／宛先ポートによって一意に識別され得る。ネットワークによるが、ＶＬＡＮ又はＭＰＬＳタグなどの追加パケットヘッダも必要であり得る。フローは、アップロード方向とダウンロード方向との両方で動作する（クライアントからサーバへ、及びサーバからクライアントへ）。厳密には、それぞれが個別のフローである。ただし、システムは、アップロード方向とダウンロード方向との両方からのパケットが同一の分析デバイス１２に送信されることを優先し得る。これは、アップロードパケットとダウンロードパケットとをより容易に相関するためであり、識別パケットが例えばアップロードフロー上で検出された時、システムは、同時に、その情報を対応ダウンロードフローへ適用できる。

フローハッシュは、以下のようなフローの一方向ハッシュを使用することによって計算され得る。
１．プロトコルがＴＣＰ又はＵＤＰでない場合（比較的珍しい）、システムは、ＥｔｈｅｒＴｙｐｅ及びペイロードバイト１から６からのパケットのフローハッシュを計算する。この結果、パケットは、分析デバイス間で無作為に分散される。
２．その後、システムは、フローが「アップロード」フローか、又は「ダウンロード」フローかを決定する。これは、決定論的に行われ得る。ＴＣＰフロー及びＵＤＰフローに対して、１つのオプションは、送信元ポート及び宛先ポートを使用し、送信元ポートが宛先ポートよりも高い、又は等しい場合に、フローが「アップロード」であると考え、それ以外は「ダウンロード」フローであると考えることである。
３．「アップロード」フローの場合、システムは、プロトコル、送信元アドレス、宛先アドレス、送信元ポート、及び宛先ポートからフローハッシュを計算する。
４．「ダウンロード」フローの場合、システムは、プロトコル、宛先アドレス、送信元アドレス、宛先ポート、及び送信元ポートからフローハッシュを計算する。

フローハッシュの順序は、ダウンロードフローのためのフローハッシュが対応アップロードフローと同一となることを確実にするために、アップロードフロー及びダウンロードフローのそれぞれに対して反転される。実際のフローハッシュ値は、決定的なものではなく、必要に応じて代替のフローハッシュが使用され得る。重要なことは、いずれの方向にパケットが移動しているかに関わらず、所与のフローに対して同一のハッシュ値が出力されることを確実にすることである。

フローハッシュが決定されると、システムは、出力テーブルを参照して、そのパケットの負荷分散を行う。

出力テーブル
複数の分析デバイス１２が存在する場合、処理のために、いずれの分析デバイス１２に所与のパケットが送信されるべきかを決定するために、出力テーブルが使用できる。

上記のテーブルによれば、可能なフローハッシュ値の範囲（例えば、０から６５５３５）が入力されてもよく、この範囲の一部はそれぞれの利用可能な分析デバイス１２と関連付けられている。範囲の重複も許容可能であり、タイは、ルール優先度を使用して解除されることが可能であり、連続した動作を確実にするために代替デバイス又はデフォルトへのフォールバックによって、１つの分析デバイス１２を取り除くことができる。

ネットワークデバイス
好適な構成において、代替の構成が採用可能であると理解され得るが、ネットワークデバイスは、図１４のフローチャートにしたがって構成され得る。ネットワークデバイス１１は、入力パケットを受信し２０、その後、パケットヘッダ及びパケットペイロード、又は、好ましくは、少なくともペイロードの最初の６バイトを解析する２１。理想的には、少なくとも、ヘッダＥｔｈｅｒｎｅｔ、ＩＰｖ４／ＩＰｖ６、ＴＣＰ／ＵＤＰ、及びペイロードが解析される。

図１４のフローチャートの次のステップは、負荷分散を支援するためにフローハッシュを計算することである２２。ただし、このステップは任意であり、その代わりに、好ましい場合、後で実行されてもよい。フローハッシュを計算するために、いずれのフィールドがフローを一意に識別するために識別されるべきかに関する決定がなされる。（例えば、上述したように、プロトコル、送信元アドレス、宛先アドレス、送信元ポート、及び宛先ポートであり得る。

パケットが反対方向に流れている場合に入れ替えられるそれらのフィールドが識別される必要があり、例えば、送信元ポート及び宛先ポートと同様に、送信元アドレス及び宛先アドレスは、スワップされ得る。「アップロード」方向又は「ダウンロード」方向に対して入れ替え可能なフィールドをスワップするかについて任意の決定を行うことができ、その後、フローハッシュは、一方向ハッシュ関数を、フローを一意に識別するフィールドに適用することによって計算されることが可能であり、パケットの入れ替え可能なフィールドを一方向でスワップする。その結果は、いずれかの方法に進むフローにおいていずれのパケットに対しても同一となるはずである。

例えば、ホストＡアドレス１０．０．０．１，ポート１１１１とホストＢアドレス１０．０．０．２，ポート２２２２との間にＴＣＰ接続がある場合、フローハッシュは以下のように計算され得る。

サンプリングレートと関連して使用可能な乱数が任意で生成される２３。この乱数は、好ましい場合に異なるステップで生成され得る。

ネットワークデバイス１１は、パケットヘッダからの解析済みデータと、パケットペイロードとを、マッチングテーブルに対して照合する２４。このマッチングテーブルは、関心パケットを照合するように定義される必要があり、少なくとも識別パケットを含む必要がある。サンプリングレートもマッチングテーブルに構成されてもよく、又は他において構成されてもよい。マッチングテーブルは、いくつかの異なるテーブルに分割されてもよく、場合によって、可変フィールドが照合対象となる。それぞれのシナリオにおいて、マッチングテーブルは、パケットが関心のものかを決定する。フィールドは、正確な３値の範囲又は他の一致方法を使用した照合のために試験され得る。

データが一致した場合、パケットがサンプリングされ２５、分析されるかを決定するために、乱数は、サンプリングレートとともに使用され得る。これは、多くの手法で行われ得る。例えば、乱数が０と１０２４との間の数字として与えられ、サンプリングレートが５０％の場合、したがって乱数が５１２を下回る場合、パケットはサンプリングされ、乱数が５１２を上回っている場合、サンプリングされない。

その後、いずれの分析デバイス１２にパケットが行くかを決定するために、フローハッシュは、出力テーブルに対して任意で照合され２６、その後、パケットは宛先の分析サーバ１２に転送される。この特定の負荷分散方法は任意である。代替案として、単一の分析デバイス１２が使用され、又は個別の負荷分散機構が使用される。

このプロセスの変形も、その実装に依存し得る。例えば、負荷分散が異なる方法で行われた場合、フローハッシュ及び出力の計算並びに使用が必要ない場合がある。同様に、小規模なネットワークに対してサンプリングレートが１００％だった場合、乱数を生成する必要がない場合がある。加えて、乱数を使用するのではなく、Ｎ個のパケット毎に１つ（例えば、Ｎ＞１）が代わりに選択されてもよい。

分析デバイス
分析デバイス１２は、ある範囲のタスクを実行するように構成され得る。一実施形態によれば、上述した基本的な使用は、識別パケットを扱って、サンプリング済みデータからフロー情報を再構築することである。

上述したマッチングテーブルの構成を分析デバイス１２が使用可能であると仮定すると、分析デバイス１２は必要なデータを構築するのに十分な情報を有する必要がある。マッチングテーブルが使用可能でない場合、パケットは、適用されたサンプリングレート情報を用いてカプセル化される。分析デバイス１２は、そのパケットにいずれのサンプリングレートが適用されたかを判断でき、それを使用して、フローにおけるパケットの数及び／又はフローのサイズを外挿できる。分析デバイス１２は、更に、フローに関するより多くの情報を識別するために任意の識別パケットのコンテンツを読み込もうとすることもできる。フロー自体に関するメタデータはキャッシュに保持されることが可能であり、それによってより多くのフローパケットが到着した時に更新されることが可能で、キャッシュ上の有効期限機構は、フロー終端を検出するために使用され得る。

多くの代替案が利用可能である。例えば、要望に応じて、分析デバイスの機能は、分割されて、個別のコンポーネントによって実行され得る。フロー情報がキャッシュに格納されなくてもよく、他のプロセスによる相関のために、データストアに送信され得る。また、フロー終端は、例えばＴＣＰ ＦＩＮパケットなどのパケットのコンテンツをより詳しく見ることによっても検出され得る。

一実施形態によれば、分析デバイス１２は、それが提供されたサンプリング済みパケットからフローのサイズ（パケット数及びバイト単位の全体のサイズ）を推定するように構成される。この推定は、いくつかの異なる手法で実行され得る。好ましくは、分析デバイス１２は、少なくとも、配信されたサンプリング済みパケットを有し、更に、各パケットが抽出された確率／サンプリングレートの知識を有する。

分析デバイス１２（又は何らかのコンポーネント）は、その情報を引き出してフローのメタデータに追加するために識別パケットを更に調べてもよい。

それに応じて、一実施形態では、分析デバイス１２は、サンプリング済みパケットを受信し、それが抽出されたサンプリングレート／確率を決定する。このデータを取得すると、分析デバイス１２は、パケットのコンテンツ（例えば、識別パケット）に基づいてパケットフローメタデータと、フローパケット数及びフロー全体のサイズの推定値とを更新する。例えば、単純なアプローチでは、２０％のサンプリングレートが適用された場合、分析デバイス１２は、５をパケット数に加算し、全体のサイズとしてパケットのサイズを５倍する。すなわち、分析デバイス１２によって分析されたデータは、サンプリングレートが１００％の場合に、その結果を推定するために外挿される。

パケットのコンテンツに注目する際、分析デバイス１２は、抽出可能な更なる有用な情報があるかを決定し得る。例えば、ＨＴＴＰパケットの場合、分析デバイス１２は、それがＧＥＴ、ＰＯＳＴ、ＰＵＴ、ＰＡＴＣＨ、ＤＥＬＥＴＥ、ＯＰＴＩＯＮＳ、ＨＥＡＤ、又はＴＲＡＣＥのリクエストであるかをチェックして、それに応じてホストを抽出できる。同様に、ＨＴＴＰＳパケットの場合、分析デバイス１２は、それがＣｌｉｅｎｔ Ｈｅｌｌｏ又はＳｅｒｖｅｒ Ｈｅｌｌｏを有するハンドシェイクパケットであるかをチェックし、Ｓｅｒｖｅｒ Ｎａｍｅ Ｉｎｄｉｃａｔｉｏｎ又はＣｅｒｔｉｆｉｃａｔｅ Ｃｏｍｍｏｎ Ｎａｍｅを抽出してもよい。

サンプリングアプローチ
一実施形態によれば、低サンプリングレート（例えば４％など）が全パケットに適用され、更に、全識別パケットがサンプリングされる。サンプリングレートがネットワークトラフィックプロファイル（通常４％から５％）に対して十分な場合、総パケット数からのサンプルのサイズから、正しいパケット数と各フローのサイズとの良好な推定値が得られる。より簡略化した、より小さいフローは、存続時間の長い、より大きなフローよりも正確性が低い。ただし、存続時間の長い大きいフローはネットワークに最も大きい影響を与えるため、ネットワークオペレータは、存続時間の長い大きいフローに一般的により大きな関心を持つ。より小さいフローのエビデンスは、その識別パケットの抽出によって依然として見られる。

全識別パケットを抽出することによって、システムオペレータによって構成されるように、本発明はフロー全体を処理する必要なく、フローから関心パケットを抽出できる。

この説明は図１５に示されており、送信元１０がパケットを宛先１４に送信している。本発明のネットワークデバイス１１は中央に存在し、パケットを選択的に抽出する。

この例において、それぞれが５つのパケット３１を有する４つのフローが存在し（ただし、より一般的には、各フローが任意の数のパケットを有してもよい）、各フローは１、２、３、及び４という番号が付されている。フロー１、２及び４は、識別パケット３２を含む。なお、１つのパケットのみ（又はフローにおける他のパケットの数と比較して非常に少ないパケット）が識別パケットであり、フローの残りは、この用途では関心がもたれていないことに留意されたい。

データを分析するために、従来のソリューションは、全４×５＝２０個のパケットのインスペクション及び処理を行う必要がある場合がある。しかしながら、いくつかのパケットを無作為にサンプリングし、全識別パケットをサンプリングすることによって、本発明は、全２０個のパケットのパケットを処理する必要がなく同様の結果が達成できる。この場合、ネットワークデバイス１１は、依然として全２０個のパケットのインスペクションを行うが、この例では、５個のパケットのみが識別パケット９８及びいくつかの無作為にサンプリングされたパケット９９となって分析デバイス１２で終端すると仮定する。

図１の例と、Ｆａｃｅｂｏｏｋ使用を識別するという目的に戻ると、本発明は理想的なツールを提供する。図１６に示すように、本発明は、送信元１０のデータを受信し、分析のために識別パケット３２のそれぞれを検出し、それによってＦａｃｅｂｏｏｋ識別パケット３５の場所を特定できる。この例では、３つのパケットが分析のために送信され、分析では、図２の例で分析が必要な２０個のパケットと比較されるため、非常に有益である。

同様に、本発明は、トラフィックフローを分析する上で大幅な改善を提供し得る。図５から図７の例は、ネットワークオペレータが直面する限界、或いは少なくともネットワークの内部トラフィックの全てを監視できない点を示す。識別パケット９８及びランダムパケット９９を選択する図１５で例証されたアプローチを採用して、ネットワーク監視の改善されたアプローチが図１７に示される。このシナリオにおいて、全ポート４０は、本発明のネットワークデバイス１１に取り付けられ、ネットワークデバイス１１は更に診断プローブデバイス４１に接続され得る。このアプローチによって、ネットワークオペレータは、ネットワーク上の内部トラフィックの全てを識別できる。識別パケットを分析することによって、システムは、ネットワーク上で実行されているアプリケーションを識別できる。システムは、更に、侵入検出、アプリケーション監視、トラフィック分析、及びネットワーク診断のためのデータフィードを提供できる。

このデータは、トラフィック管理において特に役立つ場合がある。トラフィック管理の一般的な目標は、顧客満足体験、特にピーク時間での顧客満足体験を改善することである。一般的に重要ではない、ソフトウェア更新などの大きなエレファントフローは、延長時間のために使用可能な帯域幅の大部分を消費し得る。これは、ウェブ閲覧のトラフィックなどのマイスフローをブロックするという影響を与え得る。最終消費者のために、これは、ウェブページのロードにおける遅延を意味する場合があり、通常、責任はサービスプロバイダにある。

本発明を採用することによって、帯域幅を大量に消費する望ましくないエレファントフローが識別可能であり、それらの影響を制限するように、サービス品質（ＱｏＳ）ポリシーが適用され得る。例えば、人気のあるゲームのゲームプレイとゲームダウンロードとの区別が成され得る。区別がなされると、ゲームのプレイではなく、ゲームのダウンロードは、帯域幅の節約を実現するためにレートが制限され、他のデータがネットワーク上でより自由に移動できるようにする。同様に、マイスフローが悪影響を確実に受けないように、他のソフトウェア及びオペレーティングシステムの更新は限定され得る。

これは、図１８に示す構成によって実現され得る。光学ＴＡＰ４５は、アップロード及びダウンロードのトラフィック４６の全てのアウトオブラインコピーを使用でき、これを、本発明のネットワークデバイス１１に供給できる。ネットワークデバイス１１は、識別パケットの全てを検出し、パケットインスペクションのために、それらを分析デバイス１２に転送する。ある比率の残りのパケットのサンプルは、送信されることが可能である。

分析デバイスは、ｘ８６でもよく、指紋アプリケーションへの受信パケットに対してパケットインスペクションを実行する。また、フローカウンターを追跡して、エレファントフローの開始イベント及び終了イベントを検出できる。エレファントフローは、望ましくないアプリケーションのテーブルと照合されることが可能で、一致が検出された場合、望ましくないアプリケーションフロー通知４９がネットワークポリシー施行５０に送信され得る。ネットワークポリシー施行５０は、その後、違反アプリケーションのフロー量を制限でき、又は選択され得る任意の他の是正措置を取り得る。例えば、エレファントフローは、低優先度キューに配置されるとしてマーキングが成され得る。

本発明は、拡大問題に対処しており、有益である。すなわち、ネットワークの全データを閲覧できず、又はネットワークの全体を包含するように拡大できない、現在の技術の技術的な限界を克服し得る。本発明は、ラインレートで、比較的低コスト及び大規模で、ネットワークパケットをフィルタリングできる。既存のシステムが実現できなかったものである。

ネットワークパケットブローカーと比較すると、本発明は、基準と一致するフローからのパケットのランダムサンプリングと、基準一致するフローからのパケットの抽出と含む、特徴の一意の組み合わせを提供し、この場合の基準は、パケットヘッダとともに、パケットペイロードの一部を含む。既存のネットワークパケットブローカーは、いずれかの他のデバイスに接続されない限り上記の両方の機能を実行できない。そのような接続に依存することは、データセンタのネットワークスイッチの速度で動作できないことを意味する。本発明は、それらの特徴の両方をラインレートの速度で動作させることができる。

加えて、市販のネットワークパケットブローカーにおけるパケットペイロードに対する照合は、パケットの最初の１２８バイトに通常限定されている一方、本発明は、３００バイトを上回る非常に詳細な一致を可能とする。

本発明は、ネットワークトラフィックの分析を大規模に実現するという追加の利点とともに、ネットワークパケットブローカーとしてネットワーク全体にわたって大規模に配備され得る。したがって、ネットワーク問題を事前に識別し、分析と、セキュリティシステムへの供給のためにフローメタデータレコードを収集し、リアルタイムのプロトコル（ＤＨＣＰ、ＤＮＳ）データ抽出を提供し、新しい詳細度のネットワーク可視性を提供するために使用可能である。

スタンドアロンのＤＰＩアプライアンスと比較すると、本発明は、所与のパケットストリームの完全なコピーを受信することに依存しておらず、むしろ関心パケットと他の関心パケットのランダムサンプルとを抽出するだけである。本発明は、各パケットを見ることができるが、ＤＰＩアプライアンスの処理オーバーヘッド要件を有していない。

標準的なフローベースのネットワークスイッチ（例えば、ＯｐｅｎＦｌｏｗ）と同様に、本発明はパケット数及びバイトサイズに関してストリーム／フローを数えることができる。ただし、フローベースのネットワークスイッチは、扱うことができる同時フローの数が、通常は数百万のみなどに限定されている。フローベースのネットワークスイッチがその限定されたフローテーブルメモリを使い果たすと、スイッチは、他のアクティブなストリームをフローテーブルから立ち退かせて、大混雑を巻き起こし、更なる負荷をスイッチのＳＤＮ（ソフトウェア定義ネットワーキング）コントローラにかけることになる。簡単に述べると、フローベースのスイッチは、大規模には機能しない。一方、本発明は、必要に応じて拡大可能である。

本実施形態がスイッチ又はフィルタの文脈において説明されたが、本発明の中心は、データストリームからの識別パケットの抽出である。これによって、ストリームから他のパケットのサンプルの抽出とともに、分析器は、特定の実装に必要なデータを導出できる。例えば、適用例は、利用可能な帯域幅を事前に管理するために、ネットワーク中を流れるトラフィックを監視することであり得る。代替例は、送信元からのトラフィック、又は宛先へのトラフィックを監視する、又はネットワーク上での特定の適用の効果を監視することでもあり得る。更なる代替例において、例えば有名なテロリストグループなどから望ましくない情報の流布を制限するために使用され得る。これらの用途は、ほぼ形だけの努力によるものを除いて、現在のところ着手されることはできない。パケットのランダムサンプルとともに識別パケットを抽出するという本発明の機能は、バイパスされているデータの大部分に依存することなく、分析対象のデータを大幅に減らす。当業者は、基礎となる発明が上述したような多くの異なる用途のために使用可能であることを理解するであろう。

本明細書全体において「一実施形態」又は「実施形態」への言及は、その実施形態と関連して説明された特定の特徴、構造、又は特性が本発明の少なくとも１つの実施形態に含まれることを意味する。それによって、本明細書全体の様々な箇所における「一実施形態において」又は「実施形態では」という句の記載の全てが必ずしも同一の実施形態に言及していない。

更に、本開示を解釈する際には、全ての語が、文脈と一致した最も広い合理的な方法で解釈されるべきである。特に、「備える」、「備えている」という語は、非排他的に要素、構成要素、又はステップに言及するとして解釈されるべきであり、言及された要素、構成要素、又はステップが、明示的に言及されていない他の要素、構成要素、又はステップとともに存在し、又は利用され、又は組み合わされてもよいことを示す。

本明細書において、「スイッチ」、「サーバ」、「ポート」、「プロセッサ」などの語は、文脈上必要な場合を除いて、ハードウェア及びソフトウェアの組み合わせを備える、デバイス、装置、及びシステムの可能性のある実装の範囲に言及するとして理解されるべきである。

更に、特定の特徴、構造、又は特性は、１つ又は複数の組み合わせにおいて適切な方法で組み合わされてもよい。当業者が、上述された方法とは異なる方法で本発明を実装してもよく、変形は、その趣旨及び範囲から逸脱することなく生成され得ることを理解されるであろう。

本明細書における文書、デバイス、動作、又は知識のあらゆる記載は、本発明の文脈を説明するために含まれる。上記のもののいずれかが、従来技術の基礎、又は関連技術、あらゆる国、本明細書が属する本出願の出願日若しくはそれ以前における一般的な常識の一部をなすことを認めるものとして解釈されるべきではない。

１０ 送信元
１１ ネットワークデバイス
１２ 分析デバイス
１３ フローデータ
１４ 宛先

Claims (13)

1. ネットワークデータパケットを受信するように適合された少なくとも１つのネットワークデバイスを備えるネットワークトラフィックデバイスであって、
   前記少なくとも１つのネットワークデバイスは、少なくとも１つの識別パケットの場所を特定するためにネットワークデータパケットをフィルタリングし、少なくとも１つのサンプルパケットを選択するために前記ネットワークデータパケットをサンプリングする、ネットワークトラフィックデバイス。
2. 前記少なくとも１つのネットワークデバイスは、前記少なくとも１つの識別パケットと、前記少なくとも１つのサンプルパケットとを分析器へ転送する、請求項１に記載のデバイス。
3. 前記ネットワークデバイスは、プログラマブルな特定用途向け集積回路を含む、請求項１又は請求項２に記載のデバイス。
4. 前記少なくとも１つのネットワークデバイスは、データプレーンでのみ動作する、請求項１から３のいずれか一項に記載のデバイス。
5. 所定のサンリングルレートは、前記少なくとも１つのネットワークデバイスによって選択されたサンプルパケットの数を決定する、請求項１から４のいずれか一項に記載のデバイス。
6. 前記分析器は受信パケットに対してディープパケットインスペクションを実行し、前記受信パケットは、前記少なくとも１つの識別パケット及び前記少なくとも１つのサンプルパケットを含む、請求項２、又は請求項２に従属した場合の請求項３から５のいずれか一項に記載のデバイス。
7. 前記分析器は、前記受信パケット及び前記所定サンプリングレートから前記ネットワークデータパケットのフロー情報を推定する、請求項６に記載のデバイス。
8. 前記少なくとも１つの分析器のうちのいずれが各受信パケットの転送先であるかを決定する負荷分散装置を更に備える、請求項１から７のいずれか一項に記載のデバイス。
9. 前記所定サンプリングレートは約４％又は５％である、請求項１から８のいずれか一項に記載のデバイス。
10. 前記少なくとも１つのサンプルパケットは無作為に選択される、請求項１から９のいずれか一項に記載のデバイス。
11. 前記少なくとも１つのサンプルパケットは、各Ｎ番目のネットワークデータパケットを選択することによって選択され、ここで、Ｎは所定数である、請求項１から９のいずれか一項に記載のデバイス。
12. データプレーンでのみ動作する少なくとも１つのネットワークデバイスであり、前記少なくとも１つのネットワークデバイスは、ネットワークトラフィックを形成するデータストリームからデータパケットを受信するように適合され、前記少なくとも１つのネットワークデバイスは、各識別パケットの場所を特定するために前記データパケットをフィルタリングし、所定の数のサンプルパケットを選択するために前記データパケットをサンプリングするように適合される、ネットワークデバイスと、
    受信パケットに対してディープパケットインスペクションを実行するように適合された少なくとも１つの分析器であり、前記受信パケットは、前記少なくとも１つの識別パケット及び前記少なくとも１つのサンプルパケットを含む、分析器と
    を備えるネットワークトラフィックデバイス。
13. ネットワークトラフィックから識別パケットをフィルタリングし、前記ネットワークトラフィックからサンプルパケットの所定の割合をサンプリングするように適合されたネットワークデバイス。

Images