通信装置及びネットワーク管理方法及びプログラム
【課題】 リクエスト数が増加した場合でも輻輳の発生を抑えることができ、ネットワーク全体の最適化を可能にする。
【解決手段】 本発明は、ネットワーク内の各通信装置において、自装置に接続されている上層側の通信装置からリクエストを受信し、該リクエストの特徴を学習アルゴリズムを用いて解析し、解析された解析結果に基づいて、リクエストを自装置に接続されている複数の下層側の通信装置のうちのいずれに転送するかを決定し、リクエストによるTCPフローを確立すると共に、該TCPフローにおける応答時間の情報を当該リクエストの送信元の上層側の通信装置に送信する。
【解決手段】 本発明は、ネットワーク内の各通信装置において、自装置に接続されている上層側の通信装置からリクエストを受信し、該リクエストの特徴を学習アルゴリズムを用いて解析し、解析された解析結果に基づいて、リクエストを自装置に接続されている複数の下層側の通信装置のうちのいずれに転送するかを決定し、リクエストによるTCPフローを確立すると共に、該TCPフローにおける応答時間の情報を当該リクエストの送信元の上層側の通信装置に送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置及びネットワーク管理方法及びプログラムに係り、特に、単一のデータセンタやエンタープライズネットワークにて、それを構成するTCP(Transmission Control Protocol)を管理できる機器間の配線が階層構造を持つとき、各TCPを管理できる機器間において、TCPのフローを自立的に管理するための通信装置及びネットワーク管理方法及びプログラムに関する。
【背景技術】
【０００２】
データセンタは階層化構造になっており、上層ではスイッチやルータ、下層ではサーバなどのネットワークコンポーネントが動作している。階層化構造のデータセンタのマネジメントに関する研究は、帯域使用率の向上や消費電力の削減に力点を置いている。中でも、帯域使用率の向上のためにデータセンタ内におけるTCPフローの制御技術が注目されている。TCPのフローを制御することにより、データセンタ内のネットワークで発生する輻輳を回避し、提供しているサービスの可用性を向上させることが可能になる。しかし、TCPフローは、バッチ処理を用いて複数のフローをまとめて制御される場合やアプリケーション層で制御されるため、フロー制御の粒度が粗く、ネットワークのスループット（帯域利用率・RTT: Round Trip Time）が悪化する問題がある。
【０００３】
しかし、近年、データセンタ特有の閉路なトポロジを考慮したTCPフロー制御技術の発展やネットワーク機器の高機能化により、TCPフローのスループットを向上させるフロー制御方式が提案されるようになった。例えば、リクエストに対して、TCPフローを確立する際、複数のTCPフローに分割して、コンテンツを配信することにより、帯域利用率を向上させる手法が提案されている。
【０００４】
また、B-cubeやDCellなどのデータセンタ構造では、アプリケーション層でフロー制御を行うことで、コンテンツのトレーサビリティの向上を目指している。
【０００５】
一般に、データセンタのトラフィックの99%以上はTCPトラヒックであることが知られている（例えば、非特許文献１参照）。多くのTCPフローが接続されることにより、輻輳が発生し、データセンタのスループットが低下し、帯域利用率を向上させることができなくなる。ここでは、データセンタネットワークにて、輻輳を回避する既存技術を２種類に分類して説明する。
【０００６】
第１に、TCPフローの転送レートを変えることによって、輻輳を回避する方法がある。DC(Data Center)TCPはデータセンタ特有のTCPフローの転送レート制御方式を提案している。DCTCPは、TCPフローを中継するネットワークコンポーネント間で転送レートを制御することで、帯域利用率の向上を目指している（例えば、非特許文献１参照）。中継するネットワークコンポーネントが、自身の転送待ちパケット数を計測し、転送待ちパケット数が一定数を超えた場合、輻輳と判断する。このとき、転送する各パケットに対してExplicit Congestion Notification(ECN)を付加し、輻輳が発生したことを転送先に通知する。ECNが付加されたパケットを中継したネットワークコンポーネントは、図１（B）に示すように、送信元に対して、転送レートを下げる要求を出す。これらの手順をデータセンタ内のネットワークコンポーネント同士が行うことにより、TCPの転送レートを輻輳が起きないように調整することができるため、輻輳の発生を抑制することができる。
【０００７】
一方で、ECNを利用せず、TCPフローの転送レートを制御するために、FAST-TCPやTCP-Vegasなどの、輻輳制御アルゴリズムを利用する方法がある（例えば、非特許文献２，３参照）。各ネットワークコンポーネントがこれらのアルゴリズムを利用する場合、TCPフローによる転送速度を監視し、最短となるTCPフローのRTT(応答時間)との比が、一定以上になった場合、輻輳を検知するという手法を用いている。
【０００８】
次に、TCPのフローのパス設定を行うことによる輻輳を回避する方法がある。VL2では、各ネットワークコンポーネントがIPアドレス以外に特別なアドレスを保持する（例えば、非特許文献４参照）。特別なアドレスはLocation Specific IP address(LAs)と呼ばれ、各ネットワークコポーネントは、LAsを用いたルーティングとIPを用いたルーティングを用いることで、データセンタネットワーク内のネットワークコンポーネント内のTCPのフローのルーティングを制御する。但し、LAsを用いる場合は、各ネットワークコンポーネントがデータセンタ全体の構造（ネットワークコンポーネントの位置）を知る必要がある。VLBは、図１（A）に示すように、階層構造の上層から下層のネットワークコンポーネントに対して、ランダムにリクエストを転送することで、TCPフローが一定のネットワークコンポーネントに集中しないようにすることで、輻輳を回避する（例えば、非特許文献５参照）。
【０００９】
これらの２つの手法では、各ネットワークコンポーネントが協調して、互いのスループットを考慮したTCPフローの制御を行っていない。第１のTCPフローの転送レートの制御では、各ネットワークコンポーネント間の輻輳の制御を行うことができるが、どのネットワークコンポーネントでTCPフローを確立したらよいかの選択を行っているわけではないので、データセンタ全体のスループットを考慮したTCPフロー制御を行っていない。また、第２のTCPフローのパス設定手法では、各ネットワークコンポーネントの状態を考慮した、TCPフローの制御を行っていない。VLBでは、ランダムに転送先を決定し、VL2では、各ネットワークコンポーネントのスループットの状態を保持することで、スループットの状態を考慮したTCPフロー制御を行うことができるかもしれないが、各ネットワークコンポーネントが、データセンタ全体のLAsを知っていることが前提となっているため、規模が大きいデータセンタでは、全てのネットワークコンポーネントのスループットの状態を把握することが困難になる。
【先行技術文献】
【非特許文献】
【００１０】
【非特許文献１】M. Alizadeh, A. Greenberg, D. A. Maltz, J. Padhye, P. Patel, B. Prabhakar, S. Sengupta, and M. Stridharan, "Data Center TCP(DCTCP)". in Proc. ACM SIGCOMM, Aug. 2010.
【非特許文献２】L. S. Brakmo, and L. L. Peterson, "TCP Vegas: End to End Congestion Avoidance on a Global Internet." IEEE Journal on Selected Areas in Communication, Vol. 13, No.8, pp. 1465-1480, Oct. 1995.
【非特許文献３】C. Jin, et.al "FAST TCP: from theory to experiments." IEEE Network, vol. 19, Issue. 1, Jan. 2005.
【非特許文献４】A. Greenberg, N. Jain, S. Kandula, C. Kim, P. Lahiri, D. Maltz, P. Patel, and S Sengupta, "VL2: A scalable and flexible data center network," in Proc. ACM SIGCOMM. Aug. 2009.
【非特許文献５】A. Greenberg, P. Lahiri, D. A. Maltz, P. Patel, and S. Sengupta, "Towards a next generation data center architecture: scalability and commercialization." in Proc. Workshop on Programmable Routers for Extensible Services of Tomorrow, Aug. 2008.
【発明の概要】
【発明が解決しようとする課題】
【００１１】
TCPフローはデータセンタの帯域利用率とスループットを考慮して制御されるべきである。つまり、TCPフローを確立するために、各ネットワークコンポーネントの負荷を考慮して、リクエストの受信先を決定しなければならない。例えば、オンデマンドサービスで代表されるような、ネットワークゲームやビデオストリーミングなどのサービスでは、TCPの制御が、サービスのユーザビリティに大きく影響を与えてしまう。しかし、これらのサービスでは、ユーザの接続時間や接続タイミングなどに特性があり、これらの接続特性を見極めなければ、適切なTCPフロー制御を行うことが難しい。
【００１２】
本発明は、上記の点に鑑みなされたもので、リクエスト数が増加した場合でも輻輳の発生を抑えることができ、ネットワーク全体の最適化が可能な通信装置及びネットワーク管理方法及びプログラム提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記の課題を解決するため、本発明（請求項１）は、TCPを管理できる複数の通信装置が階層的に接続されたネットワークにおいて、各TCPを管理できる該通信装置間において、TCPのフローを自立的に管理するための通信装置であって、
自装置に接続されている上層側の通信装置からリクエストを受信し、該リクエストの特徴を学習アルゴリズムにより解析するリクエスト解析手段と、
前記リクエスト解析手段で解析された解析結果に基づいて、前記リクエストを自装置に接続されている複数の下層側の通信装置のうちのいずれに転送するかを決定する転送先決定手段と、
TCPフローを確立すると共に、該TCPフローにおける応答時間の情報を前記リクエストの送信元の上層側の通信装置に送信する応答時間通知手段と、を有する。
【００１４】
また、本発明（請求項２）は、前記TCPフローが確立した際に、自装置の下層の通信装置のフロー数を管理し、該フロー数が変化した際に、上層の通信装置に通知するフロー数変化通知手段と、
自装置と直接接続されている下層の通信装置のフロー数を保持するフロー数保持手段と、
前記リクエスト解析手段は、
前記フロー数保持手段よりフロー数を取得して、TCPのスループットを学習する手段を含む。
【００１５】
本発明（請求項３）は、TCPを管理できる複数の通信装置が階層的に接続されたネットワークにおいて、各TCPを管理できる該通信装置間において、TCPのフローを自立的に管理するためのネットワーク管理方法であって、
ネットワーク内の各通信装置において、
リクエスト解析手段が、自装置に接続されている上層側の通信装置からリクエストを受信し、該リクエストの特徴を学習アルゴリズムにより解析するリクエスト解析ステップと、
転送先決定手段が、前記リクエスト解析ステップで解析された解析結果に基づいて、前記リクエストを自装置に接続されている複数の下層側の通信装置のうちのいずれに転送するかを決定する転送先決定ステップと、
応答時間通知手段が、TCPフローを確立すると共に、該TCPフローにおける応答時間の情報を前記リクエストの送信元の上層側の通信装置に送信する応答時間通知ステップと、
を行う。
【００１６】
また、本発明（請求項４）は、フロー数変化通知手段が、前記TCPフローが確立した際に、自装置の下層の通信装置のフロー数を管理し、該フロー数が変化した際に、上層の通信装置に通知するフロー数変化通知ステップと、
フロー数保持手段が、自装置と直接接続されている下層の通信装置のフロー数が変化したことの通知を取得すると、該フロー数を記憶手段に格納するフロー数保持ステップと、
を更に行い、
前記リクエスト解析ステップにおいて、
前記フロー数保持手段よりフロー数を取得して、TCPのスループットを学習する。
【００１７】
本発明（請求項５）は、コンピュータを、請求項１または２に記載の通信装置の各手段として機能させるためのネットワーク管理プログラムである。
【発明の効果】
【００１８】
本発明の、階層型協調フロー制御では、TCPフローが確立したときに、下層から上層に対して再帰的にスループットの情報を伝達することにより、上層のネットワークコンポーネントは下層のネットワークコンポーネントのスループットを考慮し、TCPフロー制御を行うことができる。さらに、各ネットワークコンポーネントはリクエストの接続特性とスループットを学習することにより、輻輳を回避しつつ、データセンタ全体の帯域利用率を向上させることができる。
【図面の簡単な説明】
【００１９】
【図１】従来の技術を説明するための図である。
【図２】本発明の一実施の形態におけるネットワークコンポーネントの構成図である。
【図３】本発明の一実施の形態におけるネットワークコンポーネントの動作を示す図である。
【図４】本発明の一実施の形態におけるネットワークコンポーネント間のシーケンスである。
【図５】本発明の一実施の形態におけるデータセンタのモデルの概要である。
【図６】本発明と既存手法（VLB）との比較結果である。
【発明を実施するための形態】
【００２０】
以下図面と共に、本発明の実施の形態を説明する。
【００２１】
図２は、本発明の一実施の形態におけるネットワークコンポーネントの構成を示す。
【００２２】
階層型協調フローを達成するために、本発明では、ネットワークコンポーネント（通信装置）の公知の基本的な機能を備えるNetwork Component Module (NCM)１０に加え、新たに３つのモジュールとして、Resource Control Module (RCM)２０、Feedback Module（FM）３０、Learning Module (LM)４０を有する。
【００２３】
NCM１０は、ネットワークコンポーネントの公知の基本的な機能を備えているモジュールである。LM４０は、接続されているネットワークコンポーネントのスループットの予測情報や計測情報をメモリ等の記憶手段に保持している。RCM２０は、LM４０の情報を用いて、リクエストの転送先を決定する機能を持つ。FM３０は、RCM２０によってリクエストが転送された結果、転送先からのスループットのフィードバックを受ける機能をもつ。
【００２４】
図３を用いて、これらの機能の動作例を説明する。
【００２５】
ステップ１） 時間ｔにおいて、ネットワークコンポーネントAがユーザからのリクエストを受信する。このとき、ネットワークコンポーネントAは、RCM２０を用いて直接接続されている下層のネットワークコンポーネントの中からリクエストの転送先をネットワークコンポーネントBに決定する。当該リクエストを受信したネットワークコンポーネントBは、リクエストを下層へと転送していき、TCPフローを確立したとする。
【００２６】
ステップ２）このとき、ネットワークコンポーネントBは、当該TCPフローを確立した際に変化したRTTの情報をリクエストの転送元のネットワークコンポーネントAに対して通知する。通知したRTTの情報は、ネットワークコンポーネントAのFM３０を用いて、LM４０内のメモリ等の記憶手段に格納され、学習が行われる（図４参照）。
【００２７】
ステップ３） 次に、時間tと同一の状態遷移が時間t+aにて発生するとする。このとき、ネットワークコンポーネントAのRCM２０は、LM３０から時間tにおいてネットワークコンポーネントBにリクエストを転送し、フローを確立したときのRTTが急激に上昇し、輻輳が発生したことを知る。その結果、RCM２０は、ネットワークコンポーネントBに転送するのではなく、ネットワークコンポーネントCに転送する。
【００２８】
全てのネットワークコンポーネントは、TCPフロー制御を行った際に、自身のLM４０のメモリ等の記憶手段にスループット情報を格納し、スループット情報を利用し、LM４０に従って学習を行う。これらの学習を通して、全てのネットワークコンポーネントが協調して、輻輳の発生を防ぎ、帯域の利用率を向上させることができる。
【００２９】
各機能を説明する前に、データセンタのモデルを示し、データセンタのモデルに従って各機能を説明することとする。
【００３０】
＜データセンタのモデル＞
全てのネットワークコンポーネントは、ユーザのリクエストによって確立されるTCPフローの制御を行う。本発明のデータセンタのモデルを以下に示す。
【００３１】
図５は、本発明の一実施の形態におけるデータセンタのモデルの概要を示す。
【００３２】
・データセンタはネットワークコンポーネントの集合体である。ネットワークコンポーネント同士の接続関係は、階層構造になっており、階層はM階層となっている。下層からi階層（１≦i≦M）にあるネットワークコンポーネントの数はNiで表す。
【００３３】
・i階層目にある、j(1≦j≦Ni)の識別子を持つネットワークコンポーネントをNCi,jで現す。
【００３４】
・ネットワークコンポーネントNCi,jは下層ネットワークコンポーネントと接続されている。接続されている下層のネットワークコンポーネントの数をCi,jで表す。なお、
【００３５】
【数１】
は、ネットワークコンポーネントNCi,jの下層のネットワークコンポーネントを示す。
【００３６】
・iが大きければ大きいほど、上層を示す。
【００３７】
・時間tにおける、ネットワークコンポーネントNCi,jが保持しているTCPフローの数をF i,j (t)で表す。さらに、時間tにおける、ネットワークコンポーネントNCi,jとネットワークコンポーネント
【００３８】
【数２】
の間のTCPフロー数を
【００３９】
【数３】
で表す。
【００４０】
なお、セッション要求の到着過程・到着率とサービス時間分布・平均時間には特定の仮定をおかずに未知とする。
【００４１】
＜Learning Module(LM)４０＞
LM４０では、TCPフローのスループットの状態をメモリ等の記憶手段に記録し、RCM２０に対して、直接接続されている下層のスループットの状態を提供する機能を持つ。LM４０は強化学習の一種であるQ-learningを用いて、TCPフローのスループットを学習する。Q-learningでは、学習エージェントが現在の状態を観測し、行動を通して得られる報酬が最大になるように、各状態における最適行動を学習する。
【００４２】
今、時刻tでエージェントがいる状態をｓtとし、ｓtでエージェントがとる行動をａtとする。さらに、行動ａtにより得られる報酬を
【００４３】
【数４】
とする。状態ｓtから状態ｓｔ＋１に行動ａtを通して遷移したとき、ｓtとａtに対するQ値Q(ｓt，ａt)は以下のように更新される。
【００４４】
【数５】
α（０＜α≦１）は学習率を示し、γ（０＜γ≦１）は割引率を示している。αが大きい場合には最新の報酬を重視し、αが１の場合には、過去の報酬を全く考慮しない。γは遷移先の状態に対するQ値が現在のQ値に与える影響をし、γが０の時は遷移先の状態st+1に対するQ値が現在の状態ｓ tのQ値に依存しない。
【００４５】
Q-learningをRCM２０に適用するため、本発明では、状態ｓt，行動ａt、そして報酬
【００４６】
【数６】
を定義する。上記のパラメータを階層構造に適したｓi,j (t)，ai,j (t)
【００４７】
【数７】
に置き換える。si,j (t)は、時間ｔにおけるネットワークコンポーネントNCi,jのフロー数を表す。具体的にsi,j (ｔ)は以下のように定義する。
【００４８】
【数８】
式（２）の通り、LM４０は、直接接続されている下層のネットワークコンポーネントとのTCPフロー数をメモリなどの記憶手段に格納する。このような管理構造にすることで、RCM２０は、LM４０から下層のネットワークコンポーネントの状態を把握し、TCPフローを確立することができる。
【００４９】
＜Resource Control Module (RCM)２０＞
RCM２０では、リクエストの転送先の決定、リクエストの転送及びTCPフローの確立を行う機能を有している。つまり、ネットワークコンポーネントNCi,jのRCM２０が、リクエストの転送先のネットワークコンポーネント
【００５０】
【数９】
を決定する。なお、転送先の決定は、LM４０から下層のスループットの予測情報を取得することによって行われる。
【００５１】
転送先の決定は、転送先として
【００５２】
【数１０】
が選択される確率
【００５３】
【数１１】
に従うものとする。
【００５４】
【数１２】
はボルツマン分布を用いたソフトマックス法によって以下のように決定される（文献「K. Pawelzik, J. Kohlmorgen, and K. R. Muller, "Annealed competition of experts for a segmentation and classification of switching dynamics," Neural Computation, vol. 8(2), pp. 240-356, 1996」参照）。
【００５５】
【数１３】
式（３）から、NCi,jのRCMは、行動の価値Qi,j (k)の大きさに応じて、
【００５６】
【数１４】
へ転送する確率を決定する。
【００５７】
【数１５】
への転送が決定し、TCPフローが確立された際に、
【００５８】
【数１６】
からスループットのフィードバックをもらい、
【００５９】
【数１７】
に転送するという行動に対しての報酬値
【００６０】
【数１８】
を計算する。報酬値
【００６１】
【数１９】
は報酬関数
【００６２】
【数２０】
によって、決定され、以下の式で表される。
【００６３】
【数２１】
式（４）はTCPスループットの式を改変したものである（文献「M. Mathis, J. Semke, J. Mahdavi, and T. Ott, "The macroscopic behavior of the TCP congestion avoidance algorithm," Computer Communication Review, vol. 27, no. 3, July. 1997.」参照）。式（４）を用いることで、TCPフローの輻輳状態を推定することができる（非特許文献２，３参照）。式（４）における
【００６４】
【数２２】
は、確立した
【００６５】
【数２３】
に対するフローのRTTを示し、
【００６６】
【数２４】
は、計測した
【００６７】
【数２５】
の中で最も短いRTTを示す。つまり、
【００６８】
【数２６】
を計測した際に、
【００６９】
【数２７】
が
【００７０】
【数２８】
を下回っていた場合、
【００７１】
【数２９】
を、
【００７２】
【数３０】
に置き換える。また、このとき、計測されたパケットロス率をLOSSとする。式（４）では、確立したフローのRTTが最も短いRTTに近く、パケットロス率LOSSが低い場合において、学習エージェントは高い報酬値を得ることができ、当該フローの受け入れ確率が向上する。もし、新たなフローを確立した際に輻輳が発生し、パケットロス率LOSSが高くなったり、RTTが急激に遅くなった場合、エージェントが獲得できる報酬値が小さくなり、新たなフローを受け入れる確率が減少する。
【００７３】
最終的にエージェントは輻輳が発生しないように、リクエストの転送先を決定することができる。結果的に、３つのモジュールを持つネットワークコンポーネント同士は、輻輳が発生しないようにリクエストの転送先を決定し、フローを確立するため、データセンタ全体において帯域の利用率を考慮したTCPフローの制御が可能になる。
【００７４】
＜Feedback Module (FM３０)＞
RCM２０では、直接接続している下層のネットワークコンポーネントのフロー数を記録している。もし、フロー数が正確に観測できない場合、RCM２０の学習の精度が低下し、正確な学習を行うことができない。
【００７５】
FM２０は、ネットワークコンポーネントNCi,jが、直接接続している下層のネットワークコンポーネント
【００７６】
【数３１】
が保持しているフローの数を正確に判断するためのモジュールになっている。例えば、ネットワークコンポーネント
【００７７】
【数３２】
はネットワークコンポーネントNl,n(１≦n≦Nn)、（１≦l≦M）と直接接続されている場合がある。このとき、ネットワークコンポーネントNCi,jは直接接続されているネットワークコンポーネント
【００７８】
【数３３】
が保持しているフロー数を正確に判断できない。直接接続している下層のネットワークコンポーネントが保持しているフロー数を正確に判断するためには、以下の式を満たさなければならない。
【００７９】
【数３４】
式（５）は、
【００８０】
【数３５】
と
【００８１】
【数３６】
のフロー数が一致していることを意味する。直接接続されている複数の上層のネットワークコンポーネントが存在しているときは、上層に対して、自身が保持しているフロー数を正確に伝えなければならない。FM３０では、新たにフローが確立した際、自身と直接接続している上層のネットワークコンポーネントに対して、フロー数が変化したことを通知することで、上層のネットワークコンポーネントは、その下層のネットワークコンポーネントのフロー数を正確に把握できる。
【００８２】
＜シミュレーション＞
以下に、既存方法と本発明の効果の比較をシミュレーションによって評価する。
【００８３】
想定環境として、単一のデータセンタに対するリクエスト数が膨大になり、確立されるフロー数が増加し、輻輳が多発する環境を考える。本シミュレーションでは、データセンタの階層数を３とし、各階層におけるネットワークコンポーネントの数を上層から、5，15，45と設定し、各階層の各ネットワークコンポーネントは、上層の３つのネットワークコンポーネントに対して接続されているとする。データセンタに到着するリクエストはポアソン過程に従うものとし、各リクエストによって確立されたフローの接続時間（サービス時間）は指数分布に従うものとする。各ネットワークコンポーネント間の最大同時接続フロー数は、上層から1000，100とし、最大同時接続数フロー数を上回るフローが確立されたおきは、輻輳が発生し、RTTとパケットロス率を指数的に増加させるものとする。
【００８４】
なお、最大同時接続フロー数を下回るフロー数の場合は、フロー数の数に応じてRTTが線形増加するものとする。
【００８５】
図６は、本発明と既存手法（VLB）との比較を示す。同図において、最下層の各ネットワークコンポーネントにおける、リクエスト数に対して確立されたフローの平均を示す。図６から既存手法であるVLBを用いた場合は、最大同時接続フロー数をはるかに超えてしまうフローを確立し、輻輳が頻繁に発生していることが分かる。これに対し、本発明を用いた場合では、リクエスト数が増えれば増えるほど、リクエストの特徴量を自律的に学習することで、輻輳の発生を抑えていることがわかる。
【００８６】
上記のように、本発明は、自律的にユーザの接続特性に応じて、TCPフローを制御する。本発明では、階層化構造になっている各ネットワークコンポーネント（ルータ、スイッチ、サーバ）に学習モジュールを組み込み、階層の上層に対して、TCPフローを確立した際に、当該TCPフローのスループットを伝達する。これにより、各ネットワークコンポーネントは、集約した下層のネットワークコンポーネントの情報を利用してフロー制御を行うことができるため、輻輳によるTCPの転送レートの低下を防ぎ、データセンタ全体の帯域利用率を考慮したフロー制御をデータセンタ全体で達成することができる。
【００８７】
上記の実施の形態におけるネットワークコンポーネント（通信装置）の動作をプログラムとして構築し、通信装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。
【００８８】
なお、本発明は上記の実施の形態に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。
【符号の説明】
【００８９】
１０ NCM（Network Component Module）
２０ RCM（Resource Control Module）
３０ FM（Feedback Module）
４０ LM（Learning Module）
【技術分野】
【０００１】
本発明は、通信装置及びネットワーク管理方法及びプログラムに係り、特に、単一のデータセンタやエンタープライズネットワークにて、それを構成するTCP(Transmission Control Protocol)を管理できる機器間の配線が階層構造を持つとき、各TCPを管理できる機器間において、TCPのフローを自立的に管理するための通信装置及びネットワーク管理方法及びプログラムに関する。
【背景技術】
【０００２】
データセンタは階層化構造になっており、上層ではスイッチやルータ、下層ではサーバなどのネットワークコンポーネントが動作している。階層化構造のデータセンタのマネジメントに関する研究は、帯域使用率の向上や消費電力の削減に力点を置いている。中でも、帯域使用率の向上のためにデータセンタ内におけるTCPフローの制御技術が注目されている。TCPのフローを制御することにより、データセンタ内のネットワークで発生する輻輳を回避し、提供しているサービスの可用性を向上させることが可能になる。しかし、TCPフローは、バッチ処理を用いて複数のフローをまとめて制御される場合やアプリケーション層で制御されるため、フロー制御の粒度が粗く、ネットワークのスループット（帯域利用率・RTT: Round Trip Time）が悪化する問題がある。
【０００３】
しかし、近年、データセンタ特有の閉路なトポロジを考慮したTCPフロー制御技術の発展やネットワーク機器の高機能化により、TCPフローのスループットを向上させるフロー制御方式が提案されるようになった。例えば、リクエストに対して、TCPフローを確立する際、複数のTCPフローに分割して、コンテンツを配信することにより、帯域利用率を向上させる手法が提案されている。
【０００４】
また、B-cubeやDCellなどのデータセンタ構造では、アプリケーション層でフロー制御を行うことで、コンテンツのトレーサビリティの向上を目指している。
【０００５】
一般に、データセンタのトラフィックの99%以上はTCPトラヒックであることが知られている（例えば、非特許文献１参照）。多くのTCPフローが接続されることにより、輻輳が発生し、データセンタのスループットが低下し、帯域利用率を向上させることができなくなる。ここでは、データセンタネットワークにて、輻輳を回避する既存技術を２種類に分類して説明する。
【０００６】
第１に、TCPフローの転送レートを変えることによって、輻輳を回避する方法がある。DC(Data Center)TCPはデータセンタ特有のTCPフローの転送レート制御方式を提案している。DCTCPは、TCPフローを中継するネットワークコンポーネント間で転送レートを制御することで、帯域利用率の向上を目指している（例えば、非特許文献１参照）。中継するネットワークコンポーネントが、自身の転送待ちパケット数を計測し、転送待ちパケット数が一定数を超えた場合、輻輳と判断する。このとき、転送する各パケットに対してExplicit Congestion Notification(ECN)を付加し、輻輳が発生したことを転送先に通知する。ECNが付加されたパケットを中継したネットワークコンポーネントは、図１（B）に示すように、送信元に対して、転送レートを下げる要求を出す。これらの手順をデータセンタ内のネットワークコンポーネント同士が行うことにより、TCPの転送レートを輻輳が起きないように調整することができるため、輻輳の発生を抑制することができる。
【０００７】
一方で、ECNを利用せず、TCPフローの転送レートを制御するために、FAST-TCPやTCP-Vegasなどの、輻輳制御アルゴリズムを利用する方法がある（例えば、非特許文献２，３参照）。各ネットワークコンポーネントがこれらのアルゴリズムを利用する場合、TCPフローによる転送速度を監視し、最短となるTCPフローのRTT(応答時間)との比が、一定以上になった場合、輻輳を検知するという手法を用いている。
【０００８】
次に、TCPのフローのパス設定を行うことによる輻輳を回避する方法がある。VL2では、各ネットワークコンポーネントがIPアドレス以外に特別なアドレスを保持する（例えば、非特許文献４参照）。特別なアドレスはLocation Specific IP address(LAs)と呼ばれ、各ネットワークコポーネントは、LAsを用いたルーティングとIPを用いたルーティングを用いることで、データセンタネットワーク内のネットワークコンポーネント内のTCPのフローのルーティングを制御する。但し、LAsを用いる場合は、各ネットワークコンポーネントがデータセンタ全体の構造（ネットワークコンポーネントの位置）を知る必要がある。VLBは、図１（A）に示すように、階層構造の上層から下層のネットワークコンポーネントに対して、ランダムにリクエストを転送することで、TCPフローが一定のネットワークコンポーネントに集中しないようにすることで、輻輳を回避する（例えば、非特許文献５参照）。
【０００９】
これらの２つの手法では、各ネットワークコンポーネントが協調して、互いのスループットを考慮したTCPフローの制御を行っていない。第１のTCPフローの転送レートの制御では、各ネットワークコンポーネント間の輻輳の制御を行うことができるが、どのネットワークコンポーネントでTCPフローを確立したらよいかの選択を行っているわけではないので、データセンタ全体のスループットを考慮したTCPフロー制御を行っていない。また、第２のTCPフローのパス設定手法では、各ネットワークコンポーネントの状態を考慮した、TCPフローの制御を行っていない。VLBでは、ランダムに転送先を決定し、VL2では、各ネットワークコンポーネントのスループットの状態を保持することで、スループットの状態を考慮したTCPフロー制御を行うことができるかもしれないが、各ネットワークコンポーネントが、データセンタ全体のLAsを知っていることが前提となっているため、規模が大きいデータセンタでは、全てのネットワークコンポーネントのスループットの状態を把握することが困難になる。
【先行技術文献】
【非特許文献】
【００１０】
【非特許文献１】M. Alizadeh, A. Greenberg, D. A. Maltz, J. Padhye, P. Patel, B. Prabhakar, S. Sengupta, and M. Stridharan, "Data Center TCP(DCTCP)". in Proc. ACM SIGCOMM, Aug. 2010.
【非特許文献２】L. S. Brakmo, and L. L. Peterson, "TCP Vegas: End to End Congestion Avoidance on a Global Internet." IEEE Journal on Selected Areas in Communication, Vol. 13, No.8, pp. 1465-1480, Oct. 1995.
【非特許文献３】C. Jin, et.al "FAST TCP: from theory to experiments." IEEE Network, vol. 19, Issue. 1, Jan. 2005.
【非特許文献４】A. Greenberg, N. Jain, S. Kandula, C. Kim, P. Lahiri, D. Maltz, P. Patel, and S Sengupta, "VL2: A scalable and flexible data center network," in Proc. ACM SIGCOMM. Aug. 2009.
【非特許文献５】A. Greenberg, P. Lahiri, D. A. Maltz, P. Patel, and S. Sengupta, "Towards a next generation data center architecture: scalability and commercialization." in Proc. Workshop on Programmable Routers for Extensible Services of Tomorrow, Aug. 2008.
【発明の概要】
【発明が解決しようとする課題】
【００１１】
TCPフローはデータセンタの帯域利用率とスループットを考慮して制御されるべきである。つまり、TCPフローを確立するために、各ネットワークコンポーネントの負荷を考慮して、リクエストの受信先を決定しなければならない。例えば、オンデマンドサービスで代表されるような、ネットワークゲームやビデオストリーミングなどのサービスでは、TCPの制御が、サービスのユーザビリティに大きく影響を与えてしまう。しかし、これらのサービスでは、ユーザの接続時間や接続タイミングなどに特性があり、これらの接続特性を見極めなければ、適切なTCPフロー制御を行うことが難しい。
【００１２】
本発明は、上記の点に鑑みなされたもので、リクエスト数が増加した場合でも輻輳の発生を抑えることができ、ネットワーク全体の最適化が可能な通信装置及びネットワーク管理方法及びプログラム提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記の課題を解決するため、本発明（請求項１）は、TCPを管理できる複数の通信装置が階層的に接続されたネットワークにおいて、各TCPを管理できる該通信装置間において、TCPのフローを自立的に管理するための通信装置であって、
自装置に接続されている上層側の通信装置からリクエストを受信し、該リクエストの特徴を学習アルゴリズムにより解析するリクエスト解析手段と、
前記リクエスト解析手段で解析された解析結果に基づいて、前記リクエストを自装置に接続されている複数の下層側の通信装置のうちのいずれに転送するかを決定する転送先決定手段と、
TCPフローを確立すると共に、該TCPフローにおける応答時間の情報を前記リクエストの送信元の上層側の通信装置に送信する応答時間通知手段と、を有する。
【００１４】
また、本発明（請求項２）は、前記TCPフローが確立した際に、自装置の下層の通信装置のフロー数を管理し、該フロー数が変化した際に、上層の通信装置に通知するフロー数変化通知手段と、
自装置と直接接続されている下層の通信装置のフロー数を保持するフロー数保持手段と、
前記リクエスト解析手段は、
前記フロー数保持手段よりフロー数を取得して、TCPのスループットを学習する手段を含む。
【００１５】
本発明（請求項３）は、TCPを管理できる複数の通信装置が階層的に接続されたネットワークにおいて、各TCPを管理できる該通信装置間において、TCPのフローを自立的に管理するためのネットワーク管理方法であって、
ネットワーク内の各通信装置において、
リクエスト解析手段が、自装置に接続されている上層側の通信装置からリクエストを受信し、該リクエストの特徴を学習アルゴリズムにより解析するリクエスト解析ステップと、
転送先決定手段が、前記リクエスト解析ステップで解析された解析結果に基づいて、前記リクエストを自装置に接続されている複数の下層側の通信装置のうちのいずれに転送するかを決定する転送先決定ステップと、
応答時間通知手段が、TCPフローを確立すると共に、該TCPフローにおける応答時間の情報を前記リクエストの送信元の上層側の通信装置に送信する応答時間通知ステップと、
を行う。
【００１６】
また、本発明（請求項４）は、フロー数変化通知手段が、前記TCPフローが確立した際に、自装置の下層の通信装置のフロー数を管理し、該フロー数が変化した際に、上層の通信装置に通知するフロー数変化通知ステップと、
フロー数保持手段が、自装置と直接接続されている下層の通信装置のフロー数が変化したことの通知を取得すると、該フロー数を記憶手段に格納するフロー数保持ステップと、
を更に行い、
前記リクエスト解析ステップにおいて、
前記フロー数保持手段よりフロー数を取得して、TCPのスループットを学習する。
【００１７】
本発明（請求項５）は、コンピュータを、請求項１または２に記載の通信装置の各手段として機能させるためのネットワーク管理プログラムである。
【発明の効果】
【００１８】
本発明の、階層型協調フロー制御では、TCPフローが確立したときに、下層から上層に対して再帰的にスループットの情報を伝達することにより、上層のネットワークコンポーネントは下層のネットワークコンポーネントのスループットを考慮し、TCPフロー制御を行うことができる。さらに、各ネットワークコンポーネントはリクエストの接続特性とスループットを学習することにより、輻輳を回避しつつ、データセンタ全体の帯域利用率を向上させることができる。
【図面の簡単な説明】
【００１９】
【図１】従来の技術を説明するための図である。
【図２】本発明の一実施の形態におけるネットワークコンポーネントの構成図である。
【図３】本発明の一実施の形態におけるネットワークコンポーネントの動作を示す図である。
【図４】本発明の一実施の形態におけるネットワークコンポーネント間のシーケンスである。
【図５】本発明の一実施の形態におけるデータセンタのモデルの概要である。
【図６】本発明と既存手法（VLB）との比較結果である。
【発明を実施するための形態】
【００２０】
以下図面と共に、本発明の実施の形態を説明する。
【００２１】
図２は、本発明の一実施の形態におけるネットワークコンポーネントの構成を示す。
【００２２】
階層型協調フローを達成するために、本発明では、ネットワークコンポーネント（通信装置）の公知の基本的な機能を備えるNetwork Component Module (NCM)１０に加え、新たに３つのモジュールとして、Resource Control Module (RCM)２０、Feedback Module（FM）３０、Learning Module (LM)４０を有する。
【００２３】
NCM１０は、ネットワークコンポーネントの公知の基本的な機能を備えているモジュールである。LM４０は、接続されているネットワークコンポーネントのスループットの予測情報や計測情報をメモリ等の記憶手段に保持している。RCM２０は、LM４０の情報を用いて、リクエストの転送先を決定する機能を持つ。FM３０は、RCM２０によってリクエストが転送された結果、転送先からのスループットのフィードバックを受ける機能をもつ。
【００２４】
図３を用いて、これらの機能の動作例を説明する。
【００２５】
ステップ１） 時間ｔにおいて、ネットワークコンポーネントAがユーザからのリクエストを受信する。このとき、ネットワークコンポーネントAは、RCM２０を用いて直接接続されている下層のネットワークコンポーネントの中からリクエストの転送先をネットワークコンポーネントBに決定する。当該リクエストを受信したネットワークコンポーネントBは、リクエストを下層へと転送していき、TCPフローを確立したとする。
【００２６】
ステップ２）このとき、ネットワークコンポーネントBは、当該TCPフローを確立した際に変化したRTTの情報をリクエストの転送元のネットワークコンポーネントAに対して通知する。通知したRTTの情報は、ネットワークコンポーネントAのFM３０を用いて、LM４０内のメモリ等の記憶手段に格納され、学習が行われる（図４参照）。
【００２７】
ステップ３） 次に、時間tと同一の状態遷移が時間t+aにて発生するとする。このとき、ネットワークコンポーネントAのRCM２０は、LM３０から時間tにおいてネットワークコンポーネントBにリクエストを転送し、フローを確立したときのRTTが急激に上昇し、輻輳が発生したことを知る。その結果、RCM２０は、ネットワークコンポーネントBに転送するのではなく、ネットワークコンポーネントCに転送する。
【００２８】
全てのネットワークコンポーネントは、TCPフロー制御を行った際に、自身のLM４０のメモリ等の記憶手段にスループット情報を格納し、スループット情報を利用し、LM４０に従って学習を行う。これらの学習を通して、全てのネットワークコンポーネントが協調して、輻輳の発生を防ぎ、帯域の利用率を向上させることができる。
【００２９】
各機能を説明する前に、データセンタのモデルを示し、データセンタのモデルに従って各機能を説明することとする。
【００３０】
＜データセンタのモデル＞
全てのネットワークコンポーネントは、ユーザのリクエストによって確立されるTCPフローの制御を行う。本発明のデータセンタのモデルを以下に示す。
【００３１】
図５は、本発明の一実施の形態におけるデータセンタのモデルの概要を示す。
【００３２】
・データセンタはネットワークコンポーネントの集合体である。ネットワークコンポーネント同士の接続関係は、階層構造になっており、階層はM階層となっている。下層からi階層（１≦i≦M）にあるネットワークコンポーネントの数はNiで表す。
【００３３】
・i階層目にある、j(1≦j≦Ni)の識別子を持つネットワークコンポーネントをNCi,jで現す。
【００３４】
・ネットワークコンポーネントNCi,jは下層ネットワークコンポーネントと接続されている。接続されている下層のネットワークコンポーネントの数をCi,jで表す。なお、
【００３５】
【数１】
は、ネットワークコンポーネントNCi,jの下層のネットワークコンポーネントを示す。
【００３６】
・iが大きければ大きいほど、上層を示す。
【００３７】
・時間tにおける、ネットワークコンポーネントNCi,jが保持しているTCPフローの数をF i,j (t)で表す。さらに、時間tにおける、ネットワークコンポーネントNCi,jとネットワークコンポーネント
【００３８】
【数２】
の間のTCPフロー数を
【００３９】
【数３】
で表す。
【００４０】
なお、セッション要求の到着過程・到着率とサービス時間分布・平均時間には特定の仮定をおかずに未知とする。
【００４１】
＜Learning Module(LM)４０＞
LM４０では、TCPフローのスループットの状態をメモリ等の記憶手段に記録し、RCM２０に対して、直接接続されている下層のスループットの状態を提供する機能を持つ。LM４０は強化学習の一種であるQ-learningを用いて、TCPフローのスループットを学習する。Q-learningでは、学習エージェントが現在の状態を観測し、行動を通して得られる報酬が最大になるように、各状態における最適行動を学習する。
【００４２】
今、時刻tでエージェントがいる状態をｓtとし、ｓtでエージェントがとる行動をａtとする。さらに、行動ａtにより得られる報酬を
【００４３】
【数４】
とする。状態ｓtから状態ｓｔ＋１に行動ａtを通して遷移したとき、ｓtとａtに対するQ値Q(ｓt，ａt)は以下のように更新される。
【００４４】
【数５】
α（０＜α≦１）は学習率を示し、γ（０＜γ≦１）は割引率を示している。αが大きい場合には最新の報酬を重視し、αが１の場合には、過去の報酬を全く考慮しない。γは遷移先の状態に対するQ値が現在のQ値に与える影響をし、γが０の時は遷移先の状態st+1に対するQ値が現在の状態ｓ tのQ値に依存しない。
【００４５】
Q-learningをRCM２０に適用するため、本発明では、状態ｓt，行動ａt、そして報酬
【００４６】
【数６】
を定義する。上記のパラメータを階層構造に適したｓi,j (t)，ai,j (t)
【００４７】
【数７】
に置き換える。si,j (t)は、時間ｔにおけるネットワークコンポーネントNCi,jのフロー数を表す。具体的にsi,j (ｔ)は以下のように定義する。
【００４８】
【数８】
式（２）の通り、LM４０は、直接接続されている下層のネットワークコンポーネントとのTCPフロー数をメモリなどの記憶手段に格納する。このような管理構造にすることで、RCM２０は、LM４０から下層のネットワークコンポーネントの状態を把握し、TCPフローを確立することができる。
【００４９】
＜Resource Control Module (RCM)２０＞
RCM２０では、リクエストの転送先の決定、リクエストの転送及びTCPフローの確立を行う機能を有している。つまり、ネットワークコンポーネントNCi,jのRCM２０が、リクエストの転送先のネットワークコンポーネント
【００５０】
【数９】
を決定する。なお、転送先の決定は、LM４０から下層のスループットの予測情報を取得することによって行われる。
【００５１】
転送先の決定は、転送先として
【００５２】
【数１０】
が選択される確率
【００５３】
【数１１】
に従うものとする。
【００５４】
【数１２】
はボルツマン分布を用いたソフトマックス法によって以下のように決定される（文献「K. Pawelzik, J. Kohlmorgen, and K. R. Muller, "Annealed competition of experts for a segmentation and classification of switching dynamics," Neural Computation, vol. 8(2), pp. 240-356, 1996」参照）。
【００５５】
【数１３】
式（３）から、NCi,jのRCMは、行動の価値Qi,j (k)の大きさに応じて、
【００５６】
【数１４】
へ転送する確率を決定する。
【００５７】
【数１５】
への転送が決定し、TCPフローが確立された際に、
【００５８】
【数１６】
からスループットのフィードバックをもらい、
【００５９】
【数１７】
に転送するという行動に対しての報酬値
【００６０】
【数１８】
を計算する。報酬値
【００６１】
【数１９】
は報酬関数
【００６２】
【数２０】
によって、決定され、以下の式で表される。
【００６３】
【数２１】
式（４）はTCPスループットの式を改変したものである（文献「M. Mathis, J. Semke, J. Mahdavi, and T. Ott, "The macroscopic behavior of the TCP congestion avoidance algorithm," Computer Communication Review, vol. 27, no. 3, July. 1997.」参照）。式（４）を用いることで、TCPフローの輻輳状態を推定することができる（非特許文献２，３参照）。式（４）における
【００６４】
【数２２】
は、確立した
【００６５】
【数２３】
に対するフローのRTTを示し、
【００６６】
【数２４】
は、計測した
【００６７】
【数２５】
の中で最も短いRTTを示す。つまり、
【００６８】
【数２６】
を計測した際に、
【００６９】
【数２７】
が
【００７０】
【数２８】
を下回っていた場合、
【００７１】
【数２９】
を、
【００７２】
【数３０】
に置き換える。また、このとき、計測されたパケットロス率をLOSSとする。式（４）では、確立したフローのRTTが最も短いRTTに近く、パケットロス率LOSSが低い場合において、学習エージェントは高い報酬値を得ることができ、当該フローの受け入れ確率が向上する。もし、新たなフローを確立した際に輻輳が発生し、パケットロス率LOSSが高くなったり、RTTが急激に遅くなった場合、エージェントが獲得できる報酬値が小さくなり、新たなフローを受け入れる確率が減少する。
【００７３】
最終的にエージェントは輻輳が発生しないように、リクエストの転送先を決定することができる。結果的に、３つのモジュールを持つネットワークコンポーネント同士は、輻輳が発生しないようにリクエストの転送先を決定し、フローを確立するため、データセンタ全体において帯域の利用率を考慮したTCPフローの制御が可能になる。
【００７４】
＜Feedback Module (FM３０)＞
RCM２０では、直接接続している下層のネットワークコンポーネントのフロー数を記録している。もし、フロー数が正確に観測できない場合、RCM２０の学習の精度が低下し、正確な学習を行うことができない。
【００７５】
FM２０は、ネットワークコンポーネントNCi,jが、直接接続している下層のネットワークコンポーネント
【００７６】
【数３１】
が保持しているフローの数を正確に判断するためのモジュールになっている。例えば、ネットワークコンポーネント
【００７７】
【数３２】
はネットワークコンポーネントNl,n(１≦n≦Nn)、（１≦l≦M）と直接接続されている場合がある。このとき、ネットワークコンポーネントNCi,jは直接接続されているネットワークコンポーネント
【００７８】
【数３３】
が保持しているフロー数を正確に判断できない。直接接続している下層のネットワークコンポーネントが保持しているフロー数を正確に判断するためには、以下の式を満たさなければならない。
【００７９】
【数３４】
式（５）は、
【００８０】
【数３５】
と
【００８１】
【数３６】
のフロー数が一致していることを意味する。直接接続されている複数の上層のネットワークコンポーネントが存在しているときは、上層に対して、自身が保持しているフロー数を正確に伝えなければならない。FM３０では、新たにフローが確立した際、自身と直接接続している上層のネットワークコンポーネントに対して、フロー数が変化したことを通知することで、上層のネットワークコンポーネントは、その下層のネットワークコンポーネントのフロー数を正確に把握できる。
【００８２】
＜シミュレーション＞
以下に、既存方法と本発明の効果の比較をシミュレーションによって評価する。
【００８３】
想定環境として、単一のデータセンタに対するリクエスト数が膨大になり、確立されるフロー数が増加し、輻輳が多発する環境を考える。本シミュレーションでは、データセンタの階層数を３とし、各階層におけるネットワークコンポーネントの数を上層から、5，15，45と設定し、各階層の各ネットワークコンポーネントは、上層の３つのネットワークコンポーネントに対して接続されているとする。データセンタに到着するリクエストはポアソン過程に従うものとし、各リクエストによって確立されたフローの接続時間（サービス時間）は指数分布に従うものとする。各ネットワークコンポーネント間の最大同時接続フロー数は、上層から1000，100とし、最大同時接続数フロー数を上回るフローが確立されたおきは、輻輳が発生し、RTTとパケットロス率を指数的に増加させるものとする。
【００８４】
なお、最大同時接続フロー数を下回るフロー数の場合は、フロー数の数に応じてRTTが線形増加するものとする。
【００８５】
図６は、本発明と既存手法（VLB）との比較を示す。同図において、最下層の各ネットワークコンポーネントにおける、リクエスト数に対して確立されたフローの平均を示す。図６から既存手法であるVLBを用いた場合は、最大同時接続フロー数をはるかに超えてしまうフローを確立し、輻輳が頻繁に発生していることが分かる。これに対し、本発明を用いた場合では、リクエスト数が増えれば増えるほど、リクエストの特徴量を自律的に学習することで、輻輳の発生を抑えていることがわかる。
【００８６】
上記のように、本発明は、自律的にユーザの接続特性に応じて、TCPフローを制御する。本発明では、階層化構造になっている各ネットワークコンポーネント（ルータ、スイッチ、サーバ）に学習モジュールを組み込み、階層の上層に対して、TCPフローを確立した際に、当該TCPフローのスループットを伝達する。これにより、各ネットワークコンポーネントは、集約した下層のネットワークコンポーネントの情報を利用してフロー制御を行うことができるため、輻輳によるTCPの転送レートの低下を防ぎ、データセンタ全体の帯域利用率を考慮したフロー制御をデータセンタ全体で達成することができる。
【００８７】
上記の実施の形態におけるネットワークコンポーネント（通信装置）の動作をプログラムとして構築し、通信装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。
【００８８】
なお、本発明は上記の実施の形態に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。
【符号の説明】
【００８９】
１０ NCM（Network Component Module）
２０ RCM（Resource Control Module）
３０ FM（Feedback Module）
４０ LM（Learning Module）
【特許請求の範囲】
【請求項１】
TCP(Transmission Control Protocol)を管理できる複数の通信装置が階層的に接続されたネットワークにおいて、各TCPを管理できる該通信装置間において、TCPのフローを自立的に管理するための通信装置であって、
自装置に接続されている上層側の通信装置からリクエストを受信し、該リクエストの特徴を学習アルゴリズムにより解析するリクエスト解析手段と、
前記リクエスト解析手段で解析された解析結果に基づいて、前記リクエストを自装置に接続されている複数の下層側の通信装置のうちのいずれに転送するかを決定する転送先決定手段と、
TCPフローを確立すると共に、該TCPフローにおける応答時間の情報を前記リクエストの送信元の上層側の通信装置に送信する応答時間通知手段と、
を有することを特徴とする通信装置。
【請求項２】
前記TCPフローが確立した際に、自装置の下層の通信装置のフロー数を管理し、該フロー数が変化した際に、上層の通信装置に通知するフロー数変化通知手段と、
自装置と直接接続されている下層の通信装置のフロー数を保持するフロー数保持手段と、
前記リクエスト解析手段は、
前記フロー数保持手段よりフロー数を取得して、TCPのスループットを学習する手段を含む
請求項１記載の通信装置。
【請求項３】
TCP(Transmission Control Protocol)を管理できる複数の通信装置が階層的に接続されたネットワークにおいて、各TCPを管理できる該通信装置間において、TCPのフローを自立的に管理するためのネットワーク管理方法であって、
ネットワーク内の各通信装置において、
リクエスト解析手段が、自装置に接続されている上層側の通信装置からリクエストを受信し、該リクエストの特徴を学習アルゴリズムにより解析するリクエスト解析ステップと、
転送先決定手段が、前記リクエスト解析ステップで解析された解析結果に基づいて、前記リクエストを自装置に接続されている複数の下層側の通信装置のうちのいずれに転送するかを決定する転送先決定ステップと、
応答時間通知手段が、TCPフローを確立すると共に、該TCPフローにおける応答時間の情報を前記リクエストの送信元の上層側の通信装置に送信する応答時間通知ステップと、
を行うことを特徴とするネットワーク管理方法。
【請求項４】
フロー数変化通知手段が、前記TCPフローが確立した際に、自装置の下層の通信装置のフロー数を管理し、該フロー数が変化した際に、上層の通信装置に通知するフロー数変化通知ステップと、
フロー数保持手段が、自装置と直接接続されている下層の通信装置のフロー数が変化したことの通知を取得すると、該フロー数を記憶手段に格納するフロー数保持ステップと、
を更に行い、
前記リクエスト解析ステップにおいて、
前記フロー数保持手段よりフロー数を取得して、TCPのスループットを学習する請求項３記載のネットワーク管理方法。
【請求項５】
コンピュータを、
請求項１または２に記載の通信装置の各手段として機能させるためのネットワーク管理プログラム。
【請求項１】
TCP(Transmission Control Protocol)を管理できる複数の通信装置が階層的に接続されたネットワークにおいて、各TCPを管理できる該通信装置間において、TCPのフローを自立的に管理するための通信装置であって、
自装置に接続されている上層側の通信装置からリクエストを受信し、該リクエストの特徴を学習アルゴリズムにより解析するリクエスト解析手段と、
前記リクエスト解析手段で解析された解析結果に基づいて、前記リクエストを自装置に接続されている複数の下層側の通信装置のうちのいずれに転送するかを決定する転送先決定手段と、
TCPフローを確立すると共に、該TCPフローにおける応答時間の情報を前記リクエストの送信元の上層側の通信装置に送信する応答時間通知手段と、
を有することを特徴とする通信装置。
【請求項２】
前記TCPフローが確立した際に、自装置の下層の通信装置のフロー数を管理し、該フロー数が変化した際に、上層の通信装置に通知するフロー数変化通知手段と、
自装置と直接接続されている下層の通信装置のフロー数を保持するフロー数保持手段と、
前記リクエスト解析手段は、
前記フロー数保持手段よりフロー数を取得して、TCPのスループットを学習する手段を含む
請求項１記載の通信装置。
【請求項３】
TCP(Transmission Control Protocol)を管理できる複数の通信装置が階層的に接続されたネットワークにおいて、各TCPを管理できる該通信装置間において、TCPのフローを自立的に管理するためのネットワーク管理方法であって、
ネットワーク内の各通信装置において、
リクエスト解析手段が、自装置に接続されている上層側の通信装置からリクエストを受信し、該リクエストの特徴を学習アルゴリズムにより解析するリクエスト解析ステップと、
転送先決定手段が、前記リクエスト解析ステップで解析された解析結果に基づいて、前記リクエストを自装置に接続されている複数の下層側の通信装置のうちのいずれに転送するかを決定する転送先決定ステップと、
応答時間通知手段が、TCPフローを確立すると共に、該TCPフローにおける応答時間の情報を前記リクエストの送信元の上層側の通信装置に送信する応答時間通知ステップと、
を行うことを特徴とするネットワーク管理方法。
【請求項４】
フロー数変化通知手段が、前記TCPフローが確立した際に、自装置の下層の通信装置のフロー数を管理し、該フロー数が変化した際に、上層の通信装置に通知するフロー数変化通知ステップと、
フロー数保持手段が、自装置と直接接続されている下層の通信装置のフロー数が変化したことの通知を取得すると、該フロー数を記憶手段に格納するフロー数保持ステップと、
を更に行い、
前記リクエスト解析ステップにおいて、
前記フロー数保持手段よりフロー数を取得して、TCPのスループットを学習する請求項３記載のネットワーク管理方法。
【請求項５】
コンピュータを、
請求項１または２に記載の通信装置の各手段として機能させるためのネットワーク管理プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１３−２６７４９（Ｐ２０１３−２６７４９Ａ）
【公開日】平成２５年２月４日（２０１３．２．４）
【国際特許分類】
【出願番号】特願２０１１−１５８４０９（Ｐ２０１１−１５８４０９）
【出願日】平成２３年７月１９日（２０１１．７．１９）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２５年２月４日（２０１３．２．４）
【国際特許分類】
【出願日】平成２３年７月１９日（２０１１．７．１９）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]