JP2013026749A

JP2013026749A - 通信装置及びネットワーク管理方法及びプログラム

Info

Publication number: JP2013026749A
Application number: JP2011158409A
Authority: JP
Inventors: Kimihiro Mizutani; 后宏水谷; Osamu Akashi; 修明石; Atsushi Terauchi; 敦寺内; Mitsuru Maruyama; 充丸山
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2011-07-19
Filing date: 2011-07-19
Publication date: 2013-02-04
Anticipated expiration: 2031-07-19
Also published as: JP5588936B2

Abstract

【課題】リクエスト数が増加した場合でも輻輳の発生を抑えることができ、ネットワーク全体の最適化を可能にする。
【解決手段】本発明は、ネットワーク内の各通信装置において、自装置に接続されている上層側の通信装置からリクエストを受信し、該リクエストの特徴を学習アルゴリズムを用いて解析し、解析された解析結果に基づいて、リクエストを自装置に接続されている複数の下層側の通信装置のうちのいずれに転送するかを決定し、リクエストによるTCPフローを確立すると共に、該TCPフローにおける応答時間の情報を当該リクエストの送信元の上層側の通信装置に送信する。
【選択図】図３

Description

本発明は、通信装置及びネットワーク管理方法及びプログラムに係り、特に、単一のデータセンタやエンタープライズネットワークにて、それを構成する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）にあるネットワークコンポーネントの数はN_iで表す。

・i階層目にある、j(1≦j≦Ni)の識別子を持つネットワークコンポーネントをNC_i,jで現す。

・ネットワークコンポーネントNC_i,jは下層ネットワークコンポーネントと接続されている。接続されている下層のネットワークコンポーネントの数をC_i,jで表す。なお、

は、ネットワークコンポーネントNC_i,jの下層のネットワークコンポーネントを示す。

・iが大きければ大きいほど、上層を示す。

・時間tにおける、ネットワークコンポーネントNC_i,jが保持しているTCPフローの数をF_i,j (t)で表す。さらに、時間tにおける、ネットワークコンポーネントNC_i,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値に与える影響をし、γが０の時は遷移先の状態s_t+1に対するQ値が現在の状態ｓ_tのQ値に依存しない。

Q-learningをRCM２０に適用するため、本発明では、状態ｓ_t，行動ａ_t、そして報酬

を定義する。上記のパラメータを階層構造に適したｓ_i,j (t)，a_i,j (t)

に置き換える。s_i,j (t)は、時間ｔにおけるネットワークコンポーネントNC_i,jのフロー数を表す。具体的にs_i,j (ｔ)は以下のように定義する。

式（２）の通り、LM４０は、直接接続されている下層のネットワークコンポーネントとのTCPフロー数をメモリなどの記憶手段に格納する。このような管理構造にすることで、RCM２０は、LM４０から下層のネットワークコンポーネントの状態を把握し、TCPフローを確立することができる。

＜Resource Control Module (RCM)２０＞
RCM２０では、リクエストの転送先の決定、リクエストの転送及びTCPフローの確立を行う機能を有している。つまり、ネットワークコンポーネントNC_i,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」参照）。

式（３）から、NC_i,jのRCMは、行動の価値Q_i,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２０は、ネットワークコンポーネントNC_i,jが、直接接続している下層のネットワークコンポーネント

が保持しているフローの数を正確に判断するためのモジュールになっている。例えば、ネットワークコンポーネント

はネットワークコンポーネントN_l,n(１≦n≦N_n)、（１≦l≦M）と直接接続されている場合がある。このとき、ネットワークコンポーネントNC_i,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）

Claims

TCP(Transmission Control Protocol)を管理できる複数の通信装置が階層的に接続されたネットワークにおいて、各TCPを管理できる該通信装置間において、TCPのフローを自立的に管理するための通信装置であって、
自装置に接続されている上層側の通信装置からリクエストを受信し、該リクエストの特徴を学習アルゴリズムにより解析するリクエスト解析手段と、
前記リクエスト解析手段で解析された解析結果に基づいて、前記リクエストを自装置に接続されている複数の下層側の通信装置のうちのいずれに転送するかを決定する転送先決定手段と、
TCPフローを確立すると共に、該TCPフローにおける応答時間の情報を前記リクエストの送信元の上層側の通信装置に送信する応答時間通知手段と、
を有することを特徴とする通信装置。
前記TCPフローが確立した際に、自装置の下層の通信装置のフロー数を管理し、該フロー数が変化した際に、上層の通信装置に通知するフロー数変化通知手段と、
自装置と直接接続されている下層の通信装置のフロー数を保持するフロー数保持手段と、
前記リクエスト解析手段は、
前記フロー数保持手段よりフロー数を取得して、TCPのスループットを学習する手段を含む
請求項１記載の通信装置。
TCP(Transmission Control Protocol)を管理できる複数の通信装置が階層的に接続されたネットワークにおいて、各TCPを管理できる該通信装置間において、TCPのフローを自立的に管理するためのネットワーク管理方法であって、
ネットワーク内の各通信装置において、
リクエスト解析手段が、自装置に接続されている上層側の通信装置からリクエストを受信し、該リクエストの特徴を学習アルゴリズムにより解析するリクエスト解析ステップと、
転送先決定手段が、前記リクエスト解析ステップで解析された解析結果に基づいて、前記リクエストを自装置に接続されている複数の下層側の通信装置のうちのいずれに転送するかを決定する転送先決定ステップと、
応答時間通知手段が、TCPフローを確立すると共に、該TCPフローにおける応答時間の情報を前記リクエストの送信元の上層側の通信装置に送信する応答時間通知ステップと、
を行うことを特徴とするネットワーク管理方法。
フロー数変化通知手段が、前記TCPフローが確立した際に、自装置の下層の通信装置のフロー数を管理し、該フロー数が変化した際に、上層の通信装置に通知するフロー数変化通知ステップと、
フロー数保持手段が、自装置と直接接続されている下層の通信装置のフロー数が変化したことの通知を取得すると、該フロー数を記憶手段に格納するフロー数保持ステップと、
を更に行い、
前記リクエスト解析ステップにおいて、
前記フロー数保持手段よりフロー数を取得して、TCPのスループットを学習する請求項３記載のネットワーク管理方法。
コンピュータを、
請求項１または２に記載の通信装置の各手段として機能させるためのネットワーク管理プログラム。