JP5815891B2

JP5815891B2 - ネットワーク自己保護

Info

Publication number: JP5815891B2
Application number: JP2014549007A
Authority: JP
Inventors: クリスティアンルメザヌ、; グオフェイジアング、; ユエピングジャング、; シング、ヴィシャル; イエワン、
Original assignee: NEC Laboratories America Inc
Current assignee: NEC Laboratories America Inc
Priority date: 2012-01-11
Filing date: 2013-01-09
Publication date: 2015-11-17
Anticipated expiration: 2033-01-09
Also published as: EP2772021B1; WO2013106386A3; IN2014CN02822A; US8976661B2; WO2013106386A2; EP2772021A2; US20130176852A1; JP2015501119A; EP2772021A4

Description

この出願は、２０１２年１月１１日に出願された米国仮出願番号６１／５８５３３７、名称「ＮｅｔＦｕｓｅ:クラウドにおけるファイティング・フレア（Fighting Flares in the Cloud）」に基づく優先権を主張し、当該米国仮出願に記載された内容を援用するものである。

本発明は、ネットワークに関し、特には、自己保護型（self-protected）ネットワークに関する。

現代のデータセンタネットワークは、高度なインフラ設備と優れたプロトコルによって構成されており、細心の注意を払って運用されている。しかしながら、ネットワーク障害による深刻な問題は、特にクラウドの時代に入り、アプリケーションやサービスの数がますます増加している昨今でも、より大きくなったと言えないまでも、まだ変わってはいない。例えば、アマゾンＥＣ２では、低容量の内部ネットワークに対して大容量の外部トラフィックが誤って再送されるというルーティングの誤設定のために、２０１１年４月２１日に大規模なダウンが発生した（非特許文献３）。結果として、何千もの企業やウェブサイトがサービスを受けられなくなり、７千５００万人のプレイステーションゲーマーたちに影響が生じた（非特許文献５）。最近の別の例では、コアスイッチの故障の結果として発生した２０１１年１０月のブラックベリーでの３日間の停電がある。

これらの問題を軽減するための最近の試みは、現在進行中であるが、有望な結果を示している。ある一群は、ネットワークの２分割帯域幅を改善でき、ネットワークルーティングトポロジにおける展性を提供できる次世代のネットワークインフラ設備を設計することによって、この問題に取り組んでいる(非特許文献５、６、８)。別の研究者グループは、データセンタネットワーク用に特別に調整されているネットワークトランスポートプロトコルの設計に焦点を当てている（非特許文献１、９）。最後の集団は、ネットワークリソース配分を最適化できる、改善された資源配置計画を提供することを目指している（非特許文献２、７）。しかしながら、連鎖的に発生する壊滅的なネットワーク障害は、データセンタでは適用されていない２つの基本的な仮定を適切に考慮しなければ、防止できないと思われる。

M. Alizadeh, A. Greenberg, D. A. Maltz, J. Padhye, P. Patel, B. Prabhakar, S. Sengupta, and M. Sridharan, "Data Center TCP (DCTCP)," in Proc. ACM SIGCOMM, Aug. 2010. H. Ballani, P. Costa, T. Karagiannis, and A. Rowstron, "Towards Predictable Datacenter Networks," in Proc. ACM SIGCOMM, Aug. 2011. Why Amazon's cloud Titanic went down. [Online]. Available: http ://money. cnn.com/2011 / 04/22/technology/ amazon_ec2_cloud_outage/index .htm. G. Cormode, S. Muthukrishnan, and D. Srivastava, "Finding hierarchical heavy hitters in data streams," in Proc. In Proc. of VLDB, 2003, pp. 464-475. A. Greenberg, J. R. Hamilton, N. Jain, S. Kandula, C. Kim, P. Lahiri, D. A. Maltz, P. Patel, and S. Sengupta, "VL2: a Scalable and Flexible Data Center Network," in Proc. ACM SIGCOMM, Aug. 2009. C. Guo, G. Lu, D. Li, H.Wu, X. Zhang, Y. Shi, C. Tian, Y. Zhang, and S. Lu, "BCube: a High Performance, Server-Centric Network Architecture for Modular Data Centers," in Proc. ACM SIGCOMM, Aug. 2009. C. Guo, G. Lu, H. J. Wang, S. Yang, C. Kong, P. Sun, W. Wu, and Y. Zhang, "SecondNet: A Data Center Network Virtualization Architecture with Bandwidth Guarantees," in Proc. ACM CoNEXT, Nov. 2010. R. N. Mysore, A. Pamboris, N. Farrington, N. Huang, P. Miri, S. Radhakrishnan, V. Subramanya, and A. Vahdat, "PortLand: a Scalable Fault-Tolerant Layer 2 Data Center Network Fabric," in Proc. ACM SIGCOMM, Aug. 2009. V. Vasudevan, A. Phanishayee, H. Shah, E. Krevat, D. G. Anderson, G. R. Ganger, G. A. Gibson, and B. Mueller, "Safe and Effective Fine -Grained TCP Retransmissions for Datacenter Communication," in Proc. ACM SIGCOMM, Aug. 2009. C. Wilson, H. Ballani, T. Karagiannis, and A. Rowstron, "Better Never than Late: Meeting Deadlines in Datacenter Networks," in Proc. ACM SIGCOMM, Aug. 2011. A. Wundsam, D. Levin, S. Seetharaman, and A. Feldmann, "OFRewind: Enabling Record and Replay Troubleshooting for Networks," in Proc. USENIX Annual Technical Conference, Jun. 2011. Y. Zhang, S. Singh, S. Sen, N. Duffield, and C. Lund, "Online identification of hierarchical heavy hitters: algorithms, evaluation, and applications," in Proc. Proceedings of the 4th ACM SIGCOMM conference on Internet measurement, ser. IMC '04.

我々は、電気回路のヒューズボックスと同様に、様々なネットワーク問題を検出して対応し、必要なネットワークサービスを保護することを目的とする自己保護機構であるＮｅｔＦｕｓｅ（ネットヒューズ）を設計する。ＮｅｔＦｕｓｅは、具体的には、クラスタリング基準の最適な集合を自動的に決定し、それらの基準の下で、ネットワーク問題を引き起こす恐れがある疑わしいフローを特定する多次元フロー集約アルゴリズムを使用する。そして、ＮｅｔＦｕｓｅは、ネットワークフィードバック(network feedback)に従って、特定されたフローを適応的に調整する。オープンフロー技術に元から備わっている軽量検知機能（light-weight sensing capabilities）を使用するために、ＮｅｔＦｕｓｅは、今のところ、スイッチと制御装置との間のプロキシデバイスとしてオープンフローネットワークに実装される。このように、ＮｅｔＦｕｓｅは、制御メッセージを傍受してネットワーク状態を推定するだけでなく、制御装置の過度な処理オーバーヘッドをオフロードすることによって、システム全体の拡張性（scalability）を向上させることもできる。

ＮｅｔＦｕｓｅは、オープンフローに独自のメッセージ機構の強力なネットワーク検知機能を利用する。スタンドアローンな製品として、ＮｅｔＦｕｓｅは、見つけにくい問題からネットワークインフラ設備を積極的に保護し、障害の伝搬を防ぐことができる。これは、クラウドサービスプロバイダまたはデータセンタ事業者にとって非常に重要であり、損害の大きいネットワークダウンタイムやサービスの中断からネットワークを救出することができる。また、ＮｅｔＦｕｓｅは、オープンフロースイッチ上に構築することができる付加価値サービスであるため、オープンフローデバイスの販売とマーケティングを後押しすることが期待される。

本発明の目的は、ネットワークの過負荷のようなネットワーク問題について検知または対応することである。

本発明の一態様は、ネットワークで使用されるデバイスであって、ネットワーク状態を監視して、そのネットワークを通過するフローの統計量を収集するネットワーク監視部と、フローをクラスタに集約して、ネットワーク問題を引き起こす恐れのあるフローを特定するフロー集約部と、ネットワークフィードバックに従って、その特定されたフローを適応的に調整する適応制御部と、を有するデバイスを含む。

本発明の別の態様は、ネットワークで使用される方法であって、ネットワーク状態を監視して、そのネットワークを通過するフローの統計を収集することと、フローをクラスタに集約して、ネットワーク問題を引き起こす恐れのあるフローを特定することと、ネットワークフィードバックに従って、その特定されたフローを適応的に調整することとを有する方法を含む。

システムの構成を示す。そのシステムの構成に関連するフローチャートを示す。妥当なフロー集約の一例を示す手続き１．２を説明する流れ図を示す。別のフロー集約の例を示す。アルゴリズム１を示す。予備実験の結果を示すＦａｔＴｒｅｅネットワークのトポロジ―を示す。

図１に示すように、ＮｅｔＦｕｓｅは、３つの主要な構成要素、つまり、ネットワーク監視部、フロー集約部および適応制御部を有する。先ず、ＮｅｔＦｕｓｅは、ネットワーク状態を連続的に監視して、そのネットワークを通過するフローの統計量を収集する。そして、フロー集約において、ＮｅｔＦｕｓｅは、ネットワーク問題を引き起こす恐れのある疑わしいフローを特定する。最後に、ＮｅｔＦｕｓｅは、ネットワークフィードバックに従って、特定されたフローを適応的に調整する。

オープンフロー技術に元から備わっている軽量検知機能を使用するために、ＮｅｔＦｕｓｅは、今のところ、スイッチと制御装置との間のプロキシデバイスとしてオープンフローネットワークに実装される。しかし、ＮｅｔＦｕｓｅは、オープンフローに限定されるものではなく、データを監視することができる一般的なネットワークシステムに適用することができる。

上記のシステム構成は、図２のフローチャートと対応付けることができる。

手続き１：フロー集約

この手続きは、フローをクラスタに集約し、特定のネットワーク問題の原因である恐れが最も高いクラスタを見つけることを目的としている。この手続きの入力は、フローの統計量であり、出力は、疑わしいフローのクラスタである。手続き１．１および１．２は、この目的を達成するための具体的な解決法である。

手続き１．１：１次元集約

先ず、過負荷フローの有意性を評価するためのスコアＳ（Ｐ）を、Ｓ（Ｐ）＝（ｍａｘ（Ｆ）−ｍ⁻（Ｆ））／ｍ⁻（Ｆ）と定義する。ここで、ｍ⁻は、下中央値演算子（low median operator）である。また、目的は、過負荷の挙動を最も露に示す集約、すなわち、Ｐ^＊＝ｍａｘ_ｐＳ（Ｐ）を見つけることである。続いて、集約規則についての最良慣行（best practice）または作業規定（operator specification）に基づいて、過負荷の挙動を露に示す集約を選択または定義する。図３は、集約規則の一例である。

閾値を必要とする集約規則については、様々な用途に応じてその閾値を定義する。この閾値を決定するには、多くの方法がある。

上記の全ての情報が利用可能になった後、アルゴリズムは、集約規則を単に選択し、この規則に基づいてフローをクラスタ化し、そして、最も大きいスコアまたは予め定められた閾値より大きいスコアを有するフローの集合を出力する。

手続き１．２：多次元集約

実際には、過負荷（オーバーロード：overloading）は、様々なフロー特性のそれぞれに対する複数の集約条件の組み合わせに対応して、特定のネットワーク領域における特定のアプリケーションによって引き起こされる。この手続きは、複数の集約規則を相関させ、ネットワーク問題を最も明確にする規則の組み合わせを特定する。図４に示したように、この手続きは、本質的には、多次元フローを列挙するための枝の刈り込み（branch pruning）を有する幅優先探索アルゴリズムである。

手続き２：適応制御

この手続きは、手続き１にて生成された複数のフローに対して適応制御を適用する。手続き２．１は、この適応制御を実現する１つの手法である。

手続き２．１：毒素‐抗毒素制御

ＮｅｔＦｕｓｅが過負荷フローｆのＲＴＴ（往復遅延時間）に対して追加遅延を適用すると、ＮｅｔＦｕｓｅはｆの応答の積極性をテストする。ｆがそのレートを低減する場合、追加の遅延も低減され、最終的には、もはや追加遅延を被ることなく、元のデータパスを享受することになる。別の場合には、追加遅延は増加し、最終的には、バッファが満杯になり、ｆの全てのパケットがドロップすることになる。ｆの目標レートをｒとした場合、（ＮｅｔＦｕｓｅボックスのバッファキューで測定される）ｆの現在のレート要求がｒ_ｆであるとすると、ＮｅｔＦｕｓｅがｆに適用する追加遅延は、（ｒ_ｆ−ｒ）×ｒ_ｆ×ＲＴＴ／ｒである。このため、フローがＴＣＰ（伝送制御プロトコル）を採用し、そのフローレートがＲＴＴに反比例すると仮定すると、ｒ_ｆ〜ＲＴＴであるため、ｆの追加遅延は、フローレートをｒ_ｆからｒに低減させることを目的としている。実際には、良い挙動のフローは、レートをｒ以下に下げることによって追加遅延に応答し、その結果、ＮｅｔＦｕｓｅにおいて、いかなる追加遅延もなくなる。一方、悪い挙動のフローはレートを高くしてしまい、ＮｅｔＦｕｓｅは、それらのパケットを可能な限り強制的にドロップさせるために、それらのパケットを遅延させ続ける。

以上説明したことは、全ての点において例示的・代表的であり、これらに限定されるものではない。本発明の範囲は、発明を実施するための形態から決定されるものではなく、特許法によって認められる最大限の解釈によって請求項から決定されるものである。ここで説明された実施形態は、単に本発明の原理を説明したものであって、本発明の範囲と精神内において当業者が様々な変更を実施することができる。また、当業者は、発明のスコープと精神内において他の様々な特徴の組み合わせを実装することができる。

更なるシステムの詳細

現代のクラウドおよびデータセンタのプラットフォームは、冗長ネットワークトポロジと優れたプロトコルで構成されているが、未だに致命的な障害に苦しめられており、大きなトラフィックサージによる性能低下は、外部要因（例えば、ＤＤｏＳ攻撃）または内部要因（ワークロードの変化、オペレータのエラー、ルーティングの誤設定）の両方によって引きこされる。これが緩和されない場合、トラフィックの過負荷は、クラウド・プロバイダに対して、厳しい財政的および可用的な影響を与える恐れがある。

我々は、データセンタネットワークに基づくオープンフローをトラフィックの過負荷から保護する機構であるＮｅｔＦｕｓｅを提案する。ＮｅｔＦｕｓｅは、アクティブなネットワークフローを検出するために受動的に収集されたオープンフロー制御メッセージを使用するため、拡張性を有する。また、過負荷の挙動を引き起こすネットワークフローを組み合わせる正当な基準を決定するために多次元フロー集約を用いているため、正確である。そして、アプリケーションフィードバックに基づいてフローのレートを適応的に決定する毒素‐抗毒素のような機構を使用するため、通常のトラフィックに影響を与えずにサージによる損傷を制限するのに有効である。我々は、ＮｅｔＦｕｓｅの試作品を構築し、実際のオープンフローテストベッド上で評価した。我々の結果は、不正動作するトラフィックを低偽陽性率（＜９％）で特定し隔離するのに、この機構が有効であることを示している。

１：序説

現代のクラウドおよびデータセンタのプラットフォームは、それぞれの相互作用およびインフラ設備との相互作用が必ずしも知られているとは限らない、複雑なアプリケーションを実行している数千ものサーバを有する。それらのプラットフォームは、冗長ネットワークトポロジ（非特許文献５）と優れたプロトコル（非特許文献１）とで構成されているが、トラフィックの過負荷が発生すると、未だに致命的な障害や性能低下を被る。トラフィックの過負荷は、ＤＤｏＳ攻撃のような外部要因によっても引き起こされるが、小さなワークロードの変化、オペレータの単純な処理、または、ルーティングの誤設定のような一見無害な内部要因によっても引き起こされる。例えば、アマゾンＥＣ２は、低容量の内部ネットワークに対して大容量の外部トラフィックが誤って再送されるというルーティングの誤設定のために２０１１年４月にダウンした（非特許文献３）。

もしこれが緩和されない場合、トラフィックの過負荷は、クラウド・プロバイダに対して、厳しい財政的および可用的な影響を与える恐れがある。４１のＵＳのデータセンタに関する最近の研究では、プロバイダに対して停電１分当たり平均５６００ドルの費用がかかることを示している。事例証拠としては、ＥＣ２の停電がアマゾンに対して約２００万ドルの収益の損失がもたらされたことが示唆されている。ますます多くのサービスやアプリケーションがクラウドに移行するため、トラフィックの過負荷の影響を効果的に緩和することが重要である。

トラフィックの過剰に起因するネットワークの問題の特定および緩和に焦点を当てた多くの研究があり、それらは２つの広いカテゴリ、すなわち、積極的なものと反応的なものとに分類される。反応的な解決策は、障害の発生を制限するために、データセンタアーキテクチャ、プロトコル、リソースの配置またはアプリケーションを修正することを提案する（非特許文献１、２、７、９、１０）。しかしながら、これらは、アプリケーション間の予想できない相互作用に起因する連鎖的な障害、または、アマゾンの事件で明らかなようにインフラ設備に対しては容易に対処できない。積極的な解決策は、ネットワークを管理し、故障の発生後に迅速に故障を検出する方法に焦点を当てている。これらのアプローチは、ネットワークのトラフィックやアプリケーションの挙動を常に監視しなければならず、また、測定値を集めるための費用が高い場合には用いられない場合がある。

我々は、データセンタネットワークの過負荷問題を防止するために、オープンフローのスイッチの機能を活用する機構を探る。オープンフローは、実績ベースまたは信頼性ベースのアプリケーション要件をサポートするために、データセンタにおいてますます実装されている。オープンフローネットワークでは、スイッチは、論理的な集中制御装置と接続され、新しいフローが到着するか失効した場合に、制御メッセージを用いてそれに通知する。

我々はＮｅｔＦｕｓｅ、つまり、わずかな測定オーバーヘッドで連鎖的なネットワークの過負荷から保護する機構を提案する。ＮｅｔＦｕｓｅは、ヒューズボックスがサージから電気回路を保護する方法と同様に、オープンフローネットワークのスイッチと制御装置の間に設けられ、トラフィックの過負荷の影響からネットワークを守る。

ＮｅｔＦｕｓｅは、３つのステップで動作する。先ず、アクティブなネットワークフローの集合を検出するために、オープンフロー制御メッセージ（例えば、ＰａｃｋｅｔＩｎ、ＦｌｏｗＭｏｄ、ＦｌｏｗＲｅｍｏｖｅｄ）を使用する。フロー出発および到着（flow departures and arrivals）のような、ネットワークイベントの制御装置に通知する制御トラフィックに依存することは、オンデマンドによる高価な監視を不要にする。第二に、我々は、（例えば、ＶＬＡＮ、アプリケーション、パス、レートに基づいて）、アクティブなフローをクラスタリングした集合を自動的に決定する多次元集約アルゴリズムを採用し、それぞれの基準について疑わしいフローを特定する。最後に、ＮｅｔＦｕｓｅは、アプリケーションフィードバックに従って、それらのレートを適応的に変化させることによってそれらのフローの影響を制限する。

我々は、ＮｅｔＦｕｓｅを提供し、スイッチと制御装置との間のプロキシとして実際のオープンフローネットワークに配置する。予備的な実験は、ＮｅｔＦｕｓｅがルーティングの誤設定またはＤＤｏｓ攻撃に起因するネットワークの過負荷を、（９％より低い）低偽陽性率で首尾よく検出することができることを示している。

２：フロー集約

ＮｅｔＦｕｓｅの最初の目標は、疑わしい挙動のフローを特定することである。「疑わしい」の定義は、種々の文脈に応じて変化する。例えば、非常に頻繁に起こるＤＮＳクエリおよび極端に高いトラフィック量の両方が過負荷の挙動を表す。実際には、ネットワークオペレータが運用経験と領域知識に基づいて過負荷の挙動を指定する必要があるかもしれない。単一のフローは疑われない恐れがあるため、ＮｅｔＦｕｓｅは、過負荷の挙動を有するアクティブなフローのクラスタを特定するためにフロー集約を実行する。

２．１：一次元集約

［一般的な問題］一般的なフロー集約の問題を述べることから始める。入力はｎ個のフローの集合｛ｆ_１，ｆ_２，…，ｆ_ｎ｝である。有効なフロー集約は集合分割Ｐ（例えば、Ｐ＝｛Ｆ_１＝｛ｆ_１，ｆ_３，ｆ_５｝，Ｆ_２＝｛ｆ_２，ｆ_ｎ｝，…，Ｆ_ｋ｝）としてモデル化することができる。我々の目標は過負荷を示す集約を見つけることである。

集約の過負荷の挙動を補足するために、過負荷スコアＳ（Ｐ）を、Ｓ（Ｐ）＝（ｍａｘ（Ｆ）−ｍ⁻（Ｆ））／ｍ⁻（Ｆ）と定義する。ここで、ｍａｘは、集約内に集約された全てのフローのうち最大のレートを示し、ｍ⁻は、下中央値を示す。ある集約が他のものよりも明らかな過負荷の挙動を示すように、異なる集約は異なるスコアを有する。例えば、図１において、集約Ｐ１は、そのピークが鋭いために、集約Ｐ２よりもスコアが高い。最も顕著に過負荷の挙動を示す集約は、Ｐ^＊＝ｍａｘ_ｐＳ（Ｐ）で与えられる。

フロー集約は組合せ最適化問題であり、ＮＰ困難である。クラスタリング・アルゴリズムに基づく機械学習が適用されるが、重いトレーニング・データと複雑な計算が必要なため、オンライン問題の検出には適さない。実際、この一般的なフロー集約の問題は解く必要すらないかもしれない。なぜなら、任意のフロー・クラスタリングは実用的な過負荷の理由に対応しないことがあり、そのため、実用的な解決策を見つけることができないからである。さらに悪いことに、ある統計的な過負荷の挙動を全体として示すという理由だけで、完全に正当なフローのグループが問題の標的にされる恐れがある。

［妥当な集約］任意のフロー集約を詳細に考察する代わりに、妥当な集約の一覧を列挙し、観測された過負荷現象を最も良く説明するものを見つけるＮｅｔＦｕｓｅを設計する。妥当な集約は、１つまたはそれ以上の実用的な過負荷の理由に対応する。表１は、妥当なフロー集約とその対応する過負荷の理由の一覧を例示している。Ｐ４は、同じ宛先ポート番号を有するフローを集約する。過負荷がＨＴＴＰに対する攻撃に起因する場合、「ｄＰｏｒｔ＝８０」の集約フローは、他のフローよりもリソースをはるかに要する。ＮｅｔＦｕｓｅがこのフロー集約を特定する場合、（予定されていたものを含む）全てのＨＴＴＰリクエストのトラフィックが制御され、ネットワーク内の他のアプリケーションは保護される。規則の一覧は、空間的（Ｐ１からＰ６）および時間的（Ｐ７からＰ９）なフロー特性を含むことに注意すべきである。そして、オープンフローにおける必要な情報を容易に取得できる（セクション４で詳細に説明する）。しかしながら、可能な集約条件の全てをカバーすることはできず、領域知識に基づいてオペレータによってカスタマイズすることができる。

［閾値に基づく集約］いくつかの妥当な集約規則は、例えば、Ｐ７．Ｐ８およびＰ９のように予め定められた閾値に基づいている。例として表１のＰ８を挙げた場合、期間ｄ_ｆによってフローを分類する場合、閾値ｄ_ｔｈを設定し、それより短い期間（ｄ_ｆ＜ｄ_ｔｈ）を有するフローを「一時的」として集約し、他のフローを「長期的」として集約することができる。最大の距離によって集約フローを分ける値を選択することによって適切な閾値を見つける。距離の定義は、正常な（および負荷が重い）動作の間における過去の測定統計値によって決定・取得される。例えば、フロー期間がべき乗分布に従う場合、閾値ｄ_ｔｈと集約されたフローＦとの間の距離を

と定義する。そして、ｌｏｇ（ｄ_ｆ）によってＦ内のフローを分類して、

を見つけ、閾値として

を設定する。異なるフロー特性に対しては、集約条件のための閾値を決定する異なる技術（例えば、クラスタリングアルゴリズム）を使用する。

２．２：多次元集約

表１において、各集約は単一のフロー特性に基づいている。実際には、過負荷は、異なるフロー特性に対する複数の集約条件の組み合わせに対応し、特定のネットワーク領域における特定のアプリケーションによって引き起こされる。例えば、過負荷がデータベースに対する同時攻撃に起因する場合、対応する集約は「開始時間＜３０秒」および「ｄＰｏｒｔ＝１４３３」とすることができる。もし開始時間またはｄＰｏｒｔによってフローを集約するならば、フローの適切な集合を特定することができない。したがって、適切な規則の組み合わせをどのように見つけるかが重要な課題となる。

我々は、多次元フロー集約を列挙するための枝の刈り込みを有する幅優先探索アルゴリズムを開発する（アルゴリズム１）。このアルゴリズムの入力は、π＝｛Ｐ_１，Ｐ_２，Ｐ_３，…｝であり、これは、試されるべき妥当な集約のリストを含む。例として、ｆ_１，ｆ_２を「古い」フロー、ｆ_３を「新しい」フローとし、Ｐ_１＝｛｛ｆ_１，ｆ_２｝，｛ｆ_３｝｝を開始時間に基づくフロー集約と仮定し、また、ｆ_１をポート２２のフロー、ｆ_２、ｆ_３をポート８０のフローとし、Ｐ_２＝｛｛ｆ_１｝，｛ｆ_２，ｆ_３｝｝をｄＰｏｒｔに基づく別のフロー集約と仮定する。アルゴリズムは、Ｐ_１およびＰ_２を組み合わせることによって、新しい集約Ｐ_３を生成する。このとき、ｆ_１はポート２２の古いフロー、ｆ_２はポート８０の古いフロー、ｆ_３はポート８０の新しいフローである、このような新しい集約Ｐ_３がＰ_１およびＰ_２よりも高いスコアＳ（Ｐ_３）を有する場合、アルゴリズムは、Ｐ_３がより良いと考えて、それをπの中にとっておく。

は、２つの集合分割間の細分関係（refinement relation）を示す。このアルゴリズムは、一方が他方の細分である場合、２つの集約を組み合わせない。

アルゴリズム１の計算的な複雑さは、Ｎをアクティブなフローの数、Ｋを予め定められた集約規則の数、ｍを最適な集約の次元とすると、Ｏ（ＮＫ^ｍ）である。実用的な設定については、このアルゴリズムは、１秒以内に終了することができる。これは、制御装置の応答時間に匹敵し、オンライン検出および反応のための十分な応答性を示す。ＮｅｔＦｕｓｅは、最も妥当なフロー集約と、それに対応する最も可能性の高い過負荷の理由を見つけるために、このアルゴリズムを適用する。集約が過負荷の問題を明らかに示していない場合、アルゴリズムの出力は、集約していない単なるフロー（これは最良の集約とみなすこともできる）である。さもなければ、アルゴリズムの出力は、１つまたは複数の１次元または多次元フロー集約規則である。ＮｅｔＦｕｓｅは、過負荷として集約に含まれる全てのフローを分類する。

３：適応制御

３．１：基本制御

ＮｅｔＦｕｓｅは、疑わしいフローを見つけると、過負荷の問題を軽減するためにそれらを制御することができる。特定された過負荷フローのそれぞれについて、ＮｅｔＦｕｓｅは、関連するスイッチに対して、フローをＮｅｔＦｕｓｅボックスへ再ルーティングするように指示する。再ルーティングは、ミラーリングとは異なり、過負荷フローによって元々占有されていたネットワークリソースを解放する。そして、ＮｅｔＦｕｓｅは、それらのフローレートが強制的に削減されるように、内部バッファキューにリダイレクトされたフローのパケットを、遅延または選択的にドロップすることができる。セクション４では、オープンフローネットワークにおいて、この機能を実現する方法について説明する。

３．２：毒素‐抗毒素機構

特定された疑わしいフローは平等には扱われないことがある。潜在的に誤報の可能性があるため、疑わしいフローが全て不正な挙動をとるわけではない。異常なフローが正しく検出された場合でも、異なるフローが、集約された過負荷の挙動に対して異なる影響を持つことがある。さらに、トラフィックの相互依存は、特定されたフローの内部、または、それらと他の正常なフローと間に存在する。したがって、ＮｅｔＦｕｓｅは、特定されたフローのそれぞれに異なる調整を行い、システムフィードバックに従った反応を適用することができる。

我々は毒素‐抗毒素の生物システムに触発された適応制御機構を導入する。細胞分裂中には、再生毒（reproducible poison）と限られた量の解毒剤の両方が放出され、悪い挙動の子細胞は（毒とともに）攻撃的な再生によって自身を殺し、良い挙動の子細胞は自身を制御して十分な解毒剤を用いて生き残る。同様なメカニズムは、インターネットにおける高帯域幅の集約フローを制御するために使用された。

ＮｅｔＦｕｓｅは、以下のように、制御動作中に毒素‐抗毒素機構を適用する。過負荷フローｆを遅延させた場合、ＮｅｔＦｕｓｅは、ｆの応答の積極性をテストする。もしｆがそのレートを低減する場合、ＮｅｔＦｕｓｅは、もはやｆが遅延しなくなるまで、遅延の積極性を低減させる。さもなければ、ＮｅｔＦｕｓｅは、遂にバッファが満杯になり、ｆの全てのパケットがドロップするまでｆをより積極的に遅延させる。実際には、ＮｅｔＦｕｓｅ制御において、ｆの目標レートがｒ（例えば、他の正常なフローのレートの平均値）であり、（ＮｅｔＦｕｓｅボックスバッファキューで測定される）ｆの現在のレート要求がｒ_ｆであるとすると、ＮｅｔＦｕｓｅがｆに適用する追加遅延は、（ｒ_ｆ−ｒ）×ｒ_ｆ×ＲＴＴ／ｒである。このため、そのフローはＴＣＰ（伝送制御プロトコル）を採用し、そのフローレートがＲＴＴに反比例すると仮定すると、ｒ_ｆ∝ＲＴＴであるため、ｆの追加遅延は、フローレートをｒｆからｒに低減させることを意図している。実際、良い挙動のフローはレートをｒ以下に下げることによって追加遅延に応答し、その結果、ＮｅｔＦｕｓｅにおいていかなる追加遅延もなくなり、悪い挙動のフローは本来よりもレートを高くし続け、ＮｅｔＦｕｓｅは、可能な限り強制的にドロップされるように、それらのパケットを遅延させ続ける。

４：ＮｅｔＦｕｓｅ設計

このセクションでは、我々は、オープンフローに基づくネットワークにおいて、フロー集約および適応制御機構を実現する。具体的には、ＯＦＲｅｗｉｎｄ（非特許文献１１）、つまり、オープンフローネットワークのネットワーク記録再生機構と同様に、オープンフローのスイッチと制御装置との間のプロキシデバイスとしてＮｅｔＦｕｓｅを実装する。しかしながら、ＯＦＲｅｗｉｎｄとは異なり、我々は、より集約的なオープンフローの軽量検知機構および柔軟なルーティング機能を利用している。これらはＮｅｔＦｕｓｅの設計と実装を容易にする。

［監視］ＮｅｔＦｕｓｅは、必要なネットワーク情報を収集するために、受動的な傍聴（passive listening）と能動的な問い合わせ（active query）の両方を用いる。途中の中継として、ＮｅｔＦｕｓｅは、オープンフローのスイッチと制御装置との間の制御メッセージの全てを傍受し、それにより、ネットワークにおける全てのフローの情報および統計量の全体像を取得する。

各スイッチは、そのフローテーブルのエントリのいずれともマッチしないデータパケットを受信するたびに、制御装置に対してＰａｃｋｅｔＩｎメッセージを送信する。制御装置は、同じフローにおける当該パケットとその次のパケットのための転送規則をインストールするために、ＦｌｏｗＭｏｄメッセージを用いて応答する。ＰａｃｋｅｔＩｎおよびＦｌｏｗＭｏｄメッセージの両方は、重要なフロー情報、つまり、識別子（例えば、発信元のＩＰおよびポート、宛先のＩＰアドレスおよびポート）、ルーティング設定情報（例えば、ＶＬＡＮタグ、入力（ingress）インターフェースおよび出力（egress）インターフェース）およびフロー開始時刻を符号化する。フローのエントリが（ＦｌｏｗＭｏｄにて符号化された設定可能なタイマーによってトリガーされ）完了すると、スイッチは、この完了したフローの継続期間およびボリュームを含むＦｌｏｗＲｅｍｏｖｅｄメッセージを制御装置に対して送信する。それらの制御メッセージの全ては、オープンフローネットワークの通常の動作に組み込まれており、そのため、小さな追加オーバーヘッドでＮｅｔＦｕｓｅによって効率的に利用することができる。

さらに制御メッセージの受動的な傍聴に加えて、ＮｅｔＦｕｓｅは、ネットワークリソースの利用率およびきめ細やかなフロー情報のためにスイッチに対して周期的に問い合わせるためのオープンフローＲｅａｄＳｔａｔｅメッセージを使用することもできる。ネットワークの利用率情報は、インターフェースの負荷およびキューのサイズを含む。ＮｅｔＦｕｓｅは、長命なエレファントフローに関するきめ細やかな情報、特に、フローの開始時刻および終了時間の間のダイナミックなフローレートを能動的に問い合わせる。必然的に、それらの能動的な問い合わせは、データパスにオーバーヘッドを引き起こす。この問題を軽減するために、ＮｅｔＦｕｓｅは、問い合わせの頻度が現在のネットワークの負荷に比例するように設定する。さらに、ＮｅｔＦｕｓｅは、は、疑わしいフローおよび疑わしいネットワーク領域においてのみより能動的な問い合わせを導入する。

［検知および行動］制御トラフィックの監視から得られたフローの集合が指定されると、ＮｅｔＦｕｓｅは、過負荷の挙動を有するフローを特定するためにフロー集約アルゴリズムを適応する。通常動作時には、スイッチから報告されたフローの全ては制御装置に中継される。過負荷状況では、特に制御ネットワークの負荷が重い場合、ＮｅｔＦｕｓｅは、制御装置に送るフローレポートをフィルタリングして優先する。制御装置からの制御コマンドもスイッチに届く前にＮｅｔＦｕｓｅを経由する。ネットワーク問題を検知し、その原因となるフローを特定すると、ＮｅｔＦｕｓｅは、スイッチに新しくフロー制御規則を修正または発行することによって、特定されたフローの適応制御を実行する。深いパケットの検査が要求される場合、または、（セクション３．１で説明したように）所定のフローに追加の遅延を注入する必要がある場合、特定されたフローは、更なる処理のためにＮｅｔＦｕｓｅボックスへ転送される。

ＮｅｔＦｕｓｅボックスは、制御装置およびスイッチの間の透過的なデバイス(transparent devices)として動作する。スイッチの観点からは、それらのデバイスは、制御装置として機能し、特定のタスクを実行するためにスイッチに実際のコマンドを発行する。制御装置の観点からは、それらはネットワークである。さらに、このＮｅｔＦｕｓｅプロキシは、フローの転送、注入遅延およびパケットブロックのような重いタスクから制御装置を和らげ、その結果、システム全体の拡張性が向上される。

５：予備実験

データセンタのテストベッドにおいてＮｅｔＦｕｓｅｎｏ試作品を構築し、いくつかの多層アプリケーションをホストしているテストベッド上で収集されたネットワークトレースによって動作するシミュレーションを使用して、我々の設計を評価した。図３で示したように、我々は、１０個のスイッチを有するＦａｔＴｒｅｅネットワークを作成し、１００タイムスロットに亘ってこのネットワーク上の５００以上のランダムフローを生成した。

ＮｅｔＦｕｓｅは、各タイムスロットで監視されたフローにフロー集約アルゴリズムを適用する。ネットワークリンクが過大に使用されている場合、ＮｅｔＦｕｓｅは、最も良いフロー集約規則に基づいて過負荷フローを特定する。以下の報告された結果では、我々は、ネットワークに注入された特定の過負荷フローを用いて複数のテストケースを生成し、ＮｅｔＦｕｓｅがそれらの過負荷フローを正確に捕捉できるかどうかを評価した。我々は、ブートストラップのために（表１のように）いくつかの妥当な集約規則を設定して、対応する規則のそれぞれについて閾値を決定する単純なアルゴリズムを適用した（セクション２参照）。

［実験１：単一の危険なフロー（single compromised flow）］１つの正常なフローをピックアップし、そのレートをあるタイムスロットで突然増加させる最も簡単なケースから始める。図２（ａ）は、疑わしいフローがその他のフローよりも多くのリソースを使用しており、集約すら必要とせずに、簡単に特定できることを示している。

［実験２：ＤＤｏｓ攻撃］異なるスイッチからスイッチ９へのフローを注入することによってＤＤｏｓ攻撃をシミュレートする。図２（ｂ）は、「頻度＜４」および「開始時間＜３０秒」という規則を組み合わせることで得られる、特定された過負荷状態の集約フローを示す。この集約フローは、ＤＤｏｓ攻撃フローの全てを含んでいるが、攻撃と同時に開始する新しい正常なフローを誤って特定してしまう。この誤った警告の割合は９％である。適応的なＮｅｔＦｕｓｅの反応は、最終的には、実際の悪い攻撃トラフィックをブロックし、正常なフローを通過させるだろう。

［実験３：ルーティングの誤設定］ルーティングの誤設定を導入し、スイッチ１からスイッチ４へ、そして最終的にはスイッチ８へ送られる約５０個の新しいフローを導入する。新しいフローはいずれも非常に高いレートを持つことはないが、再ルーティングされたトラフィックの全ての負荷の総和は、あるネットワークリンクを過負荷にする恐れがある。図２（ｃ）は、リンク１−４が過負荷になっている、標本ネットワークの利用率を示す。

各フローのレート（図２（ｄ））が与えられたとき、ＮｅｔＦｕｓｅは、過負荷を引き起こす新しいフローを特定する必要があるかもしれない。先ず、集約されていない、リンク１−４を経由するフローを想定する（（図２（ｅ））。過負荷の挙動を有するフローを特定することは困難である。集約規則として頻度およびルーティングを組み合わせることによってそれらのフローの集約を実行すると、検知は非常に容易になる。図２（ｆ）は、基準「頻度＜４」と、再ルーティングされた新しいトラフィックに対応する正確に対応する「スイッチ１からスイッチ４を経由してスイッチ８へ」とを組み合わせることによって集約されたフローのレートの増加を示す。

６：議論と関連研究

［監視］
最近の研究は、コモディティスイッチで大きなトラヒック集合体を検知するフローワークを提案している。それらのシステムは、スイッチから状態を積極的に読み出すことに依存しており、重要である可能性が高いフローを測定する監視規則を適用する。これに対してＮｅｔＦｕｓｅは、主に受動的な制御トラフィックに依存しており、制御トラフィックが不十分なときにのみ能動的に問い合わせを使用する。さらにＮｅｔＦｕｓｅは、サージの影響を制限することを試みることができる。ＮｅｔＦｕｓｅは、受動的な測定に大きく依存するだろう。

［フロー集約］我々は問題のあるフローを見つけるために多次元集約を使用する。これは、伝統的なＩＰネットワークにおける、階層的重要（ＨＨＨ：hierarchical heavy hitter）問題（非特許文献４、１２）である。しかしながら、自然なＩＰアドレス階層は、常に存在しているとは限らず、特に、ＶＬ２（非特許文献５）およびＰｏｒｔｌａｎｄ（非特許文献８）のような、分離された物理的および論理的なアドレス方式を有するトポロジであるため、データセンタネットワークに直接適用することはできない。たとえフローの空間的な特性が階層的に集約できるとしても、フローの時間的な特性は、ＨＨＨアルゴリズムには、まだ馴染まないだろう。

［拡張性］２つの機構、つまり、オープンフローの制御メッセージに基づくネットワークの統計的推定、および、ＮｅｔＦｕｓｅミドルボックスを使用する制御装置の負荷軽減がスケールＮｅｔＦｕｓｅを支援する。多数のフローが存在すると、多くの制御パケットを引き起こし、ＮｅｔＦｕｓｅを圧倒してしまうことがある。以前の測定値は、多数のフローを有することが、強力な制御装置または制御装置の集合を有する中規模のオープンフローネットワークに適していることを示す。
例えば、１０μ秒ごとに到着する新しいフローを有する、１００個のスイッチのネットワークにおける制御装置は、１秒当たり１千万のＰａｃｋｅｔＩｎメッセージを処理する。制御装置が分配される場合でも、ＮｅｔＦｕｓｅは制御トラフィックを依然として補足することができ、フローバイザー（Flow Visor）と同様の機構を使用してネットワーク情報を同期させることができる。

［発展］現在のＮｅｔＦｕｓｅの設計は、リアクティブ型のオープンフローネットワークを仮定している。実際には、ＮｅｔＦｕｓｅボックスは、レガシーおよびオープンフローのスイッチの組み合わせで構築されたハイブリッドネットワークに配備される可能性が最も高い。このような環境では、現在のＮｅｔＦｕｓｅの監視機構は、ＳＮＭＰに基づく技術およびフローサンプリング機構を結び付けることができる。さらに、このようなハイブリッド環境では、ＮｅｔＦｕｓｅボックスは、ネットワークに偏在する代わりにいくつかの有利な箇所に配置される。我々は、将来の仕事において、これらの問題について最大限の処置を行うだろう。

７：結論

我々は、オープンフローデータセンターネットワークにおけるネットワークの過負荷の問題から保護するＮｅｔＦｕｓｅを公開した。ＮｅｔＦｕｓｅは、（１）アクティブなネットワークフローを特定するために受動的に収集されたオープンフロー制御トラフィック、（２）疑わしいフロークラスタを見つけるための多次元集約、（３）偽陽性に深刻に影響を与えずに疑わしいフローのレートを適応的に制限する毒素‐抗毒素機構を使用する。我々は、我々の研究所において、オープンフローテストベッドでＮｅｔＦｕｓｅを実証し、ＤＤｏｓ攻撃とルーティングの誤設定とを検出できることを示した。

Claims

ネットワークで使用されるデバイスであって、
前記ネットワーク状態を監視し、前記ネットワークを通過するフローの統計量を収集するネットワーク監視部と、
フローをクラスタに集約して、ネットワーク問題を引き起こす恐れのあるフローを特定するフロー集約部と、
ネットワークフィードバックに従って、前記特定されたフローを適応的に調整する適応制御部と、を有し、
前記フロー集約部は、集合分割ＰをＰ＝｛Ｆ _１，Ｆ _２，…，Ｆ _ｋ｝、ｍ ⁻ を下中央値としたとき、スコアＳ（Ｐ）を、Ｓ（Ｐ）＝（ｍａｘ（Ｆ）−ｍ ⁻ （Ｆ））／ｍ ⁻ （Ｆ）と定義し、
過負荷の挙動を明らかにする集約Ｐ ^＊＝ｍａｘ _ｐＳ（Ｐ）を見つけ、
妥当な集約規則の集合を定義する、デバイス。
請求項１に記載のデバイスにおいて
前記集約規則の集合は、過去の経験または動作仕様から取得される、デバイス。
請求項１または２に記載のデバイスにおいて、
前記集約規則の集合は、少なくとも
エンドツーエンドのフラッディングのための入力（ingress）または出力（egress）、
脅威に曝された仮想装置（ＶＭ）のための発信元(source)サブネット、
特定のＶＭにおけるフラッシュクラウドのための宛先(destination)サブネット
特定のサービスに対する攻撃のための宛先ポート、
ルーティングの誤設定のためのパス上のスイッチまたはルーターのリスト、
相関データの転送のための開始時間の範囲、
新しいトラフィック負荷のためのパケット到着周波数閾値、
短いまたは失敗した接続試行のための期間閾値、
バギー（buggy）にカスタマイズされた伝送制御プロトコル（ＴＣＰ）のためのバースト閾値、
を含むデバイス
請求項１ないし３のいずれか１項に記載のデバイスにおいて、
前記集約規則の少なくとも１つは、閾値を要求し、
当該デバイスは、アプリケーションのそれぞれに従って異なる閾値を定義する、デバイス。
請求項１ないし４のいずれか１項に記載のデバイスにおいて、
前記フロー集約部は、前記集約規則の一つを選択し、当該一つの集約規則に基づいてフローをクラスタ化し、そして、最も高いスコアまたは予め定められた閾値を超えるスコアを有するフローの集合を出力する、デバイス。
請求項１に記載のデバイスにおいて、
前記フロー集約部は、集約規則の集合をｐｉ^＊としたとき、ｐｉ^＊から集約規則Ｐを選択し、
ｐｉ^＊の残りのＰ’のそれぞれについて、ＰおよびＰ’が互いに他方の細分ではなく、ＰおよびＰ’の結合であるＰ”がｐｉ^＊の中になく、Ｐ”のスコアがＰおよびＰ’のスコアよりも大きい場合、Ｐ”をｐｉ^＊に追加し、
ｐｉ^＊がＰよりも大きいスコアを有する集約を含む場合、ｐｉ^＊からＰを削除する、デバイス。
請求項１ないし６のいずれか１項に記載のデバイスにおいて、
前記適応制御部は、過負荷フローの往復遅延時間（ＲＴＴ）に追加の遅延を適用する、デバイス。
請求項１に記載のデバイスにおいて、
前記ネットワークは、オープンフローネットワークである、デバイス。
請求項８に記載のデバイスにおいて、
当該デバイスは、スイッチおよび制御装置の間に配置されたプロキシデバイスに含む、デバイス。
ネットワークで使用される方法であって、
ネットワーク状態を監視して、前記ネットワークを通過するフローの統計量を収集することと、
フローをクラスタに集約して、ネットワーク問題を引き起こす恐れのあるフローを特定することと、
ネットワークフィードバックに従って、その特定されたフローを適応的に調整することと、を有し、
前記フローを集約することは、
ｍ ⁻ を下中央値としたとき、スコアＳ（Ｐ）を、Ｓ（Ｐ）＝（ｍａｘ（Ｆ）−ｍ ⁻ （Ｆ））／ｍ ⁻ （Ｆ）と定義し、
過負荷の挙動を明らかにする集約Ｐ ^＊＝ｍａｘ _ｐＳ（Ｐ）を見つけ、
集約規則の集合を定義する、方法。
請求項１０に記載の方法において
前記集約規則の集合は、過去の経験または動作仕様から取得される、方法。
請求項１０または１１に記載の方法において、
前記集約規則の集合は、少なくとも
エンドツーエンドのフラッディングのための入力（ingress）または出力（egress）、
脅威に曝された仮想装置（ＶＭ）のための発信元(source)サブネット、
特定のＶＭにおけるフラッシュクラウドのための宛先(destination)サブネット
特定のサービスに対する攻撃のための宛先ポート、
ルーティングの誤設定のためのパス上のスイッチまたはルーターのリスト、
相関データの転送のための開始時間の範囲、
新しいトラフィック負荷のためのパケット到着周波数閾値、
短いまたは失敗した接続試行のための期間閾値、
バギーにカスタマイズされた伝送制御プロトコル（ＴＣＰ）のためのバースト閾値、
を含む方法。
請求項１０ないし１２のいずれか１項に記載の方法において、
前記集約規則の少なくとも１つは、閾値を要求し、
アプリケーションのそれぞれに従って異なる閾値を定義する、方法。
請求項１０ないし１３のいずれか１項に記載の方法において、
前記フローを集約することは、
前記集約規則の一つを選択することと、
当該一つの集約規則に基づいてフローをクラスタ化することと、
最も高いスコアまたは予め定められた閾値を超えるスコアを有するフローの集合を出力することと、を含む方法。
請求項１０に記載の方法において、
前記フローを集約することは、
集約規則の集合をｐｉ^＊としたとき、ｐｉ^＊から集約規則Ｐを選択することと、
ｐｉ^＊の残りのＰ’のそれぞれについて、ＰおよびＰ’が互いに他方の細分ではなく、ＰおよびＰ’の結合であるＰ”がｐｉ^＊の中になく、Ｐ”のスコアがＰおよびＰ’のスコアよりも大きい場合、Ｐ”をｐｉ^＊に追加することと、
ｐｉ^＊がＰよりも大きいスコアを有する集約を含む場合、ｐｉ^＊からＰを削除することと、を含む方法。
請求項１０ないし１５のいずれか１項に記載の方法において、
前記適応的に調整することは、
過負荷フローの往復遅延時間（ＲＴＴ）に追加の遅延を適用することを含む、方法。
請求項１０に記載の方法において、
前記ネットワークは、オープンフローネットワークである、方法。
請求項１７に記載の方法において、
当該方法は、スイッチおよび制御装置の間に配置されたプロキシデバイスで使用される、方法。