JP4755066B2 - 帯域制御装置および帯域制御方法 - Google Patents

Description

本発明は、双方向通信に係るフレームを受信し、該フレームを送信することで通信を中継する帯域制御装置および帯域制御方法に関する。

中継対象のトラフィックを装置内のバッファ（Ｑｕｅｕｅ）に一旦格納し、当該バッファからのフレームを読み出して送信する際に最低帯域保証や優先制御等の帯域制御（Ｂａｎｄｗｉｄｔｈ Ｃｏｎｔｒｏｌ）を行い、重要度の高いトラフィックの遅延または廃棄を防ぐ帯域制御装置がある。

帯域制御装置では、サーバからのフレーム受信時にフロー（Ｆｌｏｗ）の識別を行い、予め設定した中継優先度に基づいてフローごとにバッファを割り当てる。ここで、トラフィックがバースト的に到着した場合に、送信レートを平均化するための機能としてシェーピング機能がある。シェーピング機能は設定した出力レートを超えるフレームを装置内バッファにバッファリングする機能である。また、バッファからの出力ルールには最低帯域保証や優先制御などの方法が用いられる。

このような従来技術として、例えば可変長パケットに対する帯域制御機能に関する技術（特許文献１を参照）がある。また、多重アクセスシステムにおいて、測定された通信量に基づいて新しいコネクションを許可する技術がある（特許文献２を参照）。
特開２００３−１９８６１１号公報 特開平１１−２９８５３２号公報

一般的な企業ネットワークではＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）の帯域が広く、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）の帯域が狭い構成となっている。このようなネットワーク上で通信が行われる場合、ＬＡＮからＷＡＮに入る入り口において帯域の差を原因とする輻輳が発生し、重要度の高い業務に係る通信やＶｏＩＰ等の通信に遅延または廃棄が発生するという問題がある。

この問題への対策として、従来、帯域制御機能を持つネットワーク機器（以下、「帯域制御装置」と称する。）が利用されている（図１、図２を参照）。システム設計に沿って帯域制御装置を導入する場合、まず見込みユーザ数、コンテンツのサイズからピーク時のトラフィック量を推定する。その推定結果に基づいて、ピーク時のトラフィック量に耐えられるだけのネットワーク帯域を用意し、それに見合ったバッファサイズをもつ帯域制御装置を導入することとなる。

しかし、サーバおよび帯域制御装置を含めたシステム導入後、そのシステムを利用するユーザ数が増加し、帯域制御装置の持つバッファが溢れるレートでトラフィックがサーバから送信されると、フレーム廃棄によりクライアントとサーバ間の通信が途切れる、タイムアウトが発生する、などの問題が生じる（図３、図４を参照）。

ここで、増加したユーザ分のトラフィックを含めた容量までバッファのサイズを大きくすればフレーム廃棄を回避できるが、帯域制御装置のバッファサイズは通常固定であり、バッファサイズを増やすためのメモリ増設は出来ないことが一般的である。また、メモリを増設出来たとしても、メモリの部品コストが高いという問題がある。

本発明は、上記した問題に鑑み、帯域制御装置内のバッファサイズを増加することなく、フレーム廃棄の発生を回避し、処理可能なユーザ数およびトラフィック量を増やすことを課題とする。

本発明は、上記した課題を解決するために、リクエストに対して発生すると予測されるレスポンスのトラフィック量の見積結果に基づいてリクエストの転送制御を行うことにより、間接的にレスポンストラフィックの流量制御を行うこととした（図５を参照）。

詳細には、本発明は、受信フレームのうち、他の処理装置に対するデータ送信要求であるリクエストフレームを保持するフレーム保持手段と、受信フレームのうち、前記データ送信要求を受けて他の処理装置から送信されたデータを含むレスポンスフレームのサイズを計測し、該計測されたサイズに基づいて、前記リクエストフレームに対する応答として受信されると予測されるレスポンスフレームによるトラフィックの量である予測トラフィック量を算出するレスポンス計測手段と、前記フレーム保持手段からフレームを読み出すタイミングを変化させることでフレームの流量を制御する帯域制御手段であって、前記レスポンス計測手段によって算出された予測トラフィック量に基づいて、前記フレーム保持手段によって保持されるリクエストフレームを送信するタイミングを調整し、該リクエストフレームの流量を制御することで該リクエストフレームに対応するレスポンスフレームの流量を間接的に制御する流量制御を行う帯域制御手段と、を備える帯域制御装置である。

本発明は、予測トラフィック量を算出することで、リクエストフレームの流量制御によって間接的にレスポンスフレームの流量を制御することを可能としている。リクエストフレームに比べ、リクエストされたデータを含むレスポンスフレームの方がサイズが大きいことが通常であるため、より小さなバッファ消費量で、より大きなトラフィックを制御することが可能となる。

即ち、本発明に拠れば、従来の帯域制御装置と同等のバッファサイズで、従来の帯域制御装置よりも格段に多くのユーザ数およびトラフィック量を扱い、輻輳による遅延又は廃棄を防止することが可能となる。

なお、予測トラフィック量の算出手段としては、計測対象のレスポンスフレームのサイズを収集して、１のリクエストフレームに対して発生するトラフィック量の平均値や中央値を算出する方法がある。更に予測トラフィック量の精度を高めたい場合には、リクエストされるＵＲＬ単位のレスポンストラフィック量の平均値や、サーバに置かれているコンテンツの個別サイズを算出することとしてもよい。

また、本発明は、前記レスポンスフレームによるトラフィック量を計測する流量計測手段を更に備え、前記帯域制御手段は、前記流量計測手段によって所定の値を超える前記トラフィック量が計測されたときに、前記流量制御を開始することとしてもよい。

トラフィック量が所定の値を超えたときに流量制御を開始することで、通常は従来の流量制御を行い、必要となったときに適切なタイミングで本発明の流量制御を開始することが可能となる。

また、前記フレーム保持手段は、該フレーム保持手段によって保持されているフレームの量に関連する情報であるバッファ情報を前記帯域制御手段に通知し、前記帯域制御手段は、前記フレーム保持手段によって通知された前記バッファ情報が示す前記フレーム保持
手段によって保持されているフレームの量が所定の閾値以下である場合に、前記流量制御を終了することとしてもよい。

このような構成とすることで、フレーム保持手段の状況に応じて、動的に流量制御を終了することが可能となる。ここで、通知されるバッファ情報は、リクエストトラフィックに係るフレーム保持手段のバッファ情報のみでもよいが、リクエストトラフィックに係るバッファ情報と、レスポンストラフィックに係るバッファ情報との双方が通知されることとしてもよい。

リクエストトラフィックに係るバッファに余裕があると判断し、流量制御を終了した場合、送信済みのリクエストフレームに対するレスポンスフレームで、レスポンストラフィックに係るバッファが溢れてしまう可能性がある。リクエストトラフィックに係るバッファ情報とレスポンストラフィックに係るバッファ情報との双方の示すフレーム量に基づいて流量制御の終了タイミングを判断することで、このような状況が発生することを防止出来る。

また、本発明は、受信フレームのうち、リクエストフレームと該リクエストフレームに対応するレスポンスフレームとの組み合わせであるフロー毎に、前記流量制御の有効又は無効を示す情報を、前記フローを識別する情報と共に保持する制御対象フロー保持手段を更に備え、前記帯域制御手段は、受信したフレームに係るフローについて、前記制御対象フロー保持手段によって保持される前記流量制御の有効又は無効を示す情報を、前記フローを識別する情報を基に検索し、前記流量制御が無効である場合は、前記流量制御を開始しないこととしてもよい。

本発明は、上記したような流量制御を行うことを特徴としているため、リクエストに対するレスポンスのサイズが大きい通信ほど、少量のバッファで大量のトラフィックを間接的に制御できることとなり、本発明を適用することによって得られる効果が大きい。

即ち、上記構成を備えることで、特定のフローごとに流量制御の有効／無効を判断し、本発明を適用することによって得られる効果が大きい特定のフローのみに流量制御を適用することが可能となる。

また、前記フレーム保持手段は、受信フレームのうち、前記レスポンスフレームを保持し、前記フレーム保持手段によって保持されているフレームの量に関連する情報であるバッファ情報を定期的に取得することで、前記フレーム保持手段の利用状況を監視し、前記バッファ情報の示すフレームの量が所定の閾値を超えた場合に、前記帯域制御手段に前記流量制御を開始させるバッファ監視手段を更に備えてもよい。

本発明に拠れば、フレーム保持手段によって保持されているフレームの量が所定の閾値を超えるまでは従来の方法で流量制御を行い、フレームの量が所定の閾値を超えた場合に前記流量制御を開始することで、フレーム保持手段のバッファを有効に使うことが可能となる。

また、本発明は、受信フレームがリクエストフレームであるか否かを識別し、受信フレームがリクエストフレームである場合、該受信フレームを前記フレーム保持手段に保持させ、受信フレームがリクエストフレームでない場合、該受信フレームを前記フレーム保持手段に保持させずに送信するリクエスト識別手段を更に備えてもよい。

本発明に拠れば、リクエストフレームのみを流量制御の対象とすることで、フレーム保持手段のバッファに利用するメモリ量および流量制御のためのＣＰＵ使用量を削減するこ
とが可能となる。

また、本発明は、受信したリクエストフレームに対応するレスポンスフレームのうち、未受信であるレスポンスフレームの総予測トラフィック量を保持する未応答サイズ保持手段と、受信したリクエストフレームに対応する前記予測トラフィック量を前記未応答サイズ保持手段に加算する予測トラフィック量加算手段と、前記リクエストフレームに対応するレスポンスフレームを送信する際に、該レスポンスフレームのトラフィック量を前記未応答サイズ保持手段から減算するレスポンストラフィック量減算手段と、を更に備え、前記フレーム保持手段は、受信フレームのうち、前記レスポンスフレームを保持し、前記帯域制御手段は、前記総予測トラフィック量と前記フレーム保持手段の空き容量とを比較した結果に基づいて、前記フレーム保持手段によって保持されるリクエストフレームを送信するタイミングを調整し、前記流量制御を行うこととしてもよい。

総予測トラフィック量は、ある時点における、今後受信されると予測されたレスポンスフレームに係るトラフィックの総量である。この総予測トラフィック量が、その時点におけるフレーム保持手段の空き容量を上回ることは、フレーム保持手段におけるバッファ溢れが発生する可能性が高いということを意味する。

即ち、上記構成を備えることで、前記総予測トラフィック量と前記フレーム保持手段の空き容量とを比較し、予測トラフィック量がフレーム保持手段の空き容量を上回った場合に、リクエストフレームの転送を止める、又はリクエストフレームの転送レートを下げる、等の対処を行うことが可能となる。

但し、上記構成によれば、未応答サイズ保持手段に加算されるトラフィック量は予測トラフィック量であり、減算されるトラフィック量は実際のレスポンストラフィック量である。この場合、未応答サイズ保持手段に記録された総予測トラフィック量に誤差が発生する。このため、本発明に係る帯域制御装置の構成を以下に示す構成としてもよい。

即ち、受信したリクエストフレームに対応するレスポンスフレームのうち、未受信であるレスポンスフレームの総予測トラフィック量を保持する未応答サイズ保持手段と、受信したリクエストフレームに対応する前記予測トラフィック量を前記未応答サイズ保持手段に加算する予測トラフィック量加算手段と、受信したリクエストフレームに対応する前記予測トラフィック量を、リクエストフレームと該リクエストフレームに対応するレスポンスフレームとの組み合わせであるフロー毎に保持する予測トラフィック量保持手段と、前記リクエストフレームに対応するレスポンスフレームを送信する際に、前記予測トラフィック量保持手段によって保持されるフロー毎の前記予測トラフィック量から、送信するレスポンスフレームに対応する予測トラフィック量を取得し、取得した予測トラフィック量を前記未応答サイズ保持手段から減算する予測トラフィック量減算手段と、を更に備え、前記フレーム保持手段は、受信フレームのうち、前記レスポンスフレームを保持し、前記帯域制御手段は、前記総予測トラフィック量と前記フレーム保持手段の空き容量とを比較した結果に基づいて、前記フレーム保持手段によって保持されるリクエストフレームを送信するタイミングを調整し、前記流量制御を行うこととする。

上記構成を備えることで、未応答サイズ保持手段に加算された予測トラフィック量は、対応するレスポンスフレームが受信されることで加算された分だけ減算されることとなる。即ち、先述した誤差の発生を防止することが可能となる。

更に、本発明は、コンピュータが実行する方法、又はコンピュータを上記各手段として機能させるためのプログラムとしても把握することが可能である。また、本発明は、そのようなプログラムをコンピュータその他の装置、機械等が読み取り可能な記録媒体に記録
したものでもよい。ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。

本発明によって、帯域制御装置内のバッファサイズを増加することなく、フレーム廃棄の発生を回避し、処理可能なユーザ数およびトラフィック量を増やすことが可能となる。

本発明に係る帯域制御装置および帯域制御方法の実施の形態について、図面に基づいて説明する。本実施形態では、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）通信を対象に、ＱｏＳ（Ｑｕａｌｉｔｙ Ｏｆ Ｓｅｒｖｉｃｅ）制御を行う場合の例を示す。ＨＴＴＰ通信は、一般的にリクエストメッセージのサイズに対してレスポンスメッセージのサイズが非常に大きくなるため、リクエストメッセージを止めることで大量のレスポンストラフィックを止めることが可能である（図６を参照）。

但し、本発明の対象はＨＴＴＰに限定するものではなく、上記の特徴を持つリクエスト／レスポンス型の通信を行うトラフィックであれば、本発明を適用することが出来る。

＜第一の実施形態＞
図７は、本実施形態におけるネットワーク構成の概略を示す図である。クライアント４０およびサーバ５０は夫々異なるＬＡＮ３０ａ、３０ｂに接続され、クライアント４０が所属するＬＡＮ（以下、拠点ＬＡＮと称する。）３０ａと、サーバ５０が所属するＬＡＮ（以下、データセンタＬＡＮと称する。）３０ｂは、ＷＡＮ２０を介して接続されている。ＬＡＮ３０ａ、３０ｂとＷＡＮ２０の間には、ゲートウェイ１０ａ、１０ｂが配置されており、ゲートウェイ１０ａ、１０ｂは通信方法や通信速度等が異なるＬＡＮ３０ａ、３０ｂとＷＡＮ２０間における通信を仲介する。ここで、ＷＡＮ２０とデータセンタＬＡＮ３０ｂとの間に配置されたゲートウェイ１０ｂは、本発明における帯域制御装置１０ｂとして機能する。なお、本実施形態で帯域制御装置１０ｂによって仲介される通信のうち、データセンタＬＡＮ３０ｂ内の端末（主にサーバ５０）宛のトラフィックを上り（ｕｐｌｉｎｋ）トラフィック、拠点ＬＡＮ３０ａ内の端末（主にクライアント４０）宛のトラフィックを下り（ｄｏｗｎｌｉｎｋ）トラフィックと称する。

ＬＡＮ３０ｂとＷＡＮ２０においては、ＬＡＮ３０ｂの方が帯域幅が広いことが通常である。このため、ＬＡＮ３０ｂからＷＡＮ２０に向けて大量のフレームが送信されると、ゲートウェイ１０ｂにおいて輻輳が発生し、フレームの破棄などが発生する。本実施形態では、ＬＡＮ３０ｂの帯域幅を１Ｇｂｐｓ（Ｇｉｇａ ｂｉｔｓ ｐｅｒ ｓｅｃｏｎｄ）、ＷＡＮ２０の帯域幅を１００Ｍｂｐｓ（Ｍｅｇａ ｂｉｔｓ ｐｅｒ ｓｅｃｏｎｄ）とする。

図８は、本実施形態における帯域制御装置１０ｂのハードウェア構成の概略を示す図である。帯域制御装置１０ｂは、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０２、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ
Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０３、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０４、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）１０５等を有し、これらはバスを介して接続されている。

ＣＰＵ１０１は、中央処理装置であり、ＲＡＭ１０２等に展開された命令およびデータを処理することで、ＲＡＭ１０２、ＥＥＰＲＯＭ１０３、ＮＩＣ１０５等を制御する。Ｒ
ＡＭ１０２は、主記憶装置であり、ＣＰＵ１０１によって制御され、各種命令やデータが書き込まれ、読み出される。ＥＥＰＲＯＭ１０３は、補助記憶装置であり、主に帯域制御装置１０ｂの電源を落としても保持したい情報が書き込まれ、読み出される。ＮＩＣ１０５は、ネットワークインターフェースであり、ＬＡＮ３０ｂ又はＷＡＮ２０より信号を受信し、ＬＡＮ３０ｂ又はＷＡＮ２０へ信号を送信する。

図９は、本実施形態における帯域制御装置１０ｂが備える各機能による受信フレームの処理の流れの概要を示す図である。ＣＰＵ１０１がＲＡＭ１０２又はＲＯＭ１０４に展開されたプログラムを実行することで、帯域制御装置１０ｂは、フロー識別部１１ｕ、１１ｄ、廃棄制御部１２ｕ、１２ｄ、上り／下りフレーム保持部１３ｕ、１３ｄ、帯域制御部１４ｕ、１４ｄ、レスポンス計測部１５、および流量計測部１６を備える装置として機能する。

フロー識別部１１ｕ、１１ｄは、受信フレームのヘッダ情報（例えば、送信元ＩＰアドレスと宛先ＩＰアドレス等。）からフローの特定を行い、フロー番号を決定する。ここで、ヘッダ情報とフロー番号との対応関係は予め管理者により設定されているものとする。本実施形態では、送信元または送信先アドレスがサーバ５０であるフレームには全てフロー番号１が付与される。

廃棄制御部１２ｕ、１２ｄは、フロー識別部１１ｕ、１１ｄからフレームおよびフロー番号を取得し、フレーム保持部１３ｕ、１３ｄ内の該当するフロー番号のＱｕｅｕｅの状態を確認し、空きがあればフレーム保持部１３ｕ、１３ｄに受信フレームを渡す。空きがない場合、受信フレームは廃棄される。

フレーム保持部１３ｕ、１３ｄは、内部に複数のＱｕｅｕｅを有し、廃棄制御部１２ｕ、１２ｄより渡されたフレームをフロー番号が該当するＱｕｅｕｅに格納する。図１０は、本実施形態におけるフレーム保持部１３ｕ、１３ｄの内部構成を示す図である。本実施形態において、フレーム保持部１３ｕ、１３ｄは上りトラフィック用Ｑｕｅｕｅと下りトラフィック用Ｑｕｅｕｅを夫々１０個ずつ有し、各Ｑｕｅｕｅは夫々２ＭＢの容量を持つ。また、帯域制御部１４ｕ、１４ｄからのフレーム取得依頼を受けて、該当するＱｕｅｕｅのフレームを帯域制御部１４ｕ、１４ｄに渡す。更に、上りフレーム保持部１３ｕは、フレームと同時にＱｕｅｕｅの空き状況を帯域制御部１４ｕに渡す。

帯域制御部１４ｕ、１４ｄは、予め設定された帯域制御ルールに基づいてフレーム保持部１３ｕ、１３ｄに対してフレーム取得依頼を発行し、その後フレーム保持部１３ｕ、１３ｄから渡されたフレームをＬＡＮ３０ｂ又はＷＡＮ２０に転送する。通常、接続されているＬＡＮ３０ｂ又はＷＡＮ２０の帯域を超えないようにフレーム保持部１３ｕ、１３ｄよりフレームを取得し、ＮＩＣ１０５を介して送信するものとする。本実施形態における下りトラフィックの制御において、帯域制御部１４ｄは、上記した通常の帯域制御ルールに従って、優先制御および最低帯域保障等を含む帯域制御を行う。

これに対し、本実施形態における上りトラフィックの制御において、帯域制御部１４ｕは、通常は上記した通常の帯域制御ルールに従って帯域制御を行うが、流量計測部１６から後述する流量調整指示を受け取ると、レスポンス計測部１５からの予測トラフィック量算出結果とＷＡＮ２０の送信帯域を基にリクエストの転送間隔を決定する。また、この転送間隔ごとに、フレーム保持部１３ｕに対してフレーム取得依頼を発行し、フレーム保持部１３ｕから渡されたフレームをデータセンタＬＡＮ３０ｂに転送する（流量制御）。また、帯域制御部１４ｕは、Ｑｕｅｕｅ空き状況を上りフレーム保持部１３ｕより受信し、Ｑｕｅｕｅが空または所定の空き容量が確認できた時点で流量制御を終了する。なお、ここで監視されるＱｕｅｕｅは、上りトラフィック用Ｑｕｅｕｅのみでもよいが、上りトラ
フィック用Ｑｕｅｕｅと下りトラフィック用Ｑｕｅｕｅとの双方を監視し、共に十分な空き容量が確認された時点で流量制御を終了することとするのが好ましい。上りトラフィック用Ｑｕｅｕｅのみで終了判断を行い、流量制御を終了した場合、送信済みのリクエストフレームに対するレスポンスフレームで、下りトラフィック用Ｑｕｅｕｅが溢れてしまう可能性があるからである。

レスポンス計測部１５は、受信フレームのうち、レスポンスメッセージに関連するフレームのフレームサイズを計測し、１リクエストメッセージに対するレスポンスのトラフィック量を計測する。そして、計測された各リクエストメッセージに対するレスポンスのトラフィック量から、１リクエストメッセージに対するレスポンストラフィックの平均サイズを算出する。算出結果は予測トラフィック量として帯域制御部１４ｕに渡される。なお、複数フレームでレスポンスメッセージが形成されている場合は、受信フレームのヘッダ情報から同一のリクエストメッセージに対するレスポンスフレームであるか否かを判別し、同一のリクエストメッセージに対するレスポンスフレームのサイズを総計することで、１リクエストメッセージに対するレスポンスのトラフィック量を計測する。

流量計測部１６は、サーバ５０からのフレーム流量を１．０ｍｓｅｃ単位で計測し、ＷＡＮ２０の物理帯域以上のフレーム受信レート（本実施例では１００Ｋｂｐｓ（Ｋｉｌｏ
ｂｉｔｓ ｐｅｒ ｓｅｃｏｎｄ）＝１２．５ＫＢ（Ｋｉｌｏ Ｂｙｔｅｓ）／ｍｓｅｃ（ミリ秒）以上）になった時点で流量調整指示を帯域制御部１４ｕに発行する。流量計測部１６は、流量計測のために例えば図１１に示すような、１．０ｍｓｅｃ毎の受信バイト数を計測するカウンタを保持している。

図１２は、本実施形態における上りトラフィックに対する１フレーム受信毎の帯域制御の流れを示すフローチャートである。本フローチャートに示された処理は、ＮＩＣ１０５によってデータセンタＬＡＮ３０ｂ宛のフレームが受信されたことを契機として開始され、ＣＰＵ１０１によって制御される。

ステップＳ１０１では、フローの識別が行われる。フロー識別部１１ｕは、受信したフレームのヘッダ情報を参照し、フローの識別を行う。本実施形態では、フレームのヘッダ情報からサーバ５０宛のフレームであることが識別できた場合、フロー識別部１１ｕは、受信したフレームのフロー番号を１とする。また、それ以外のフレームについても、フレームのヘッダ情報からフローが識別され、適切なフロー番号が付される。フロー識別部１１ｕは、識別結果および受信フレームを廃棄制御部１２ｕに渡す。その後、処理はステップＳ１０２へ進む。

ステップＳ１０２では、Ｑｕｅｕｅの空き状況が判定される。廃棄制御部１２ｕは、該当するフロー番号のＱｕｅｕｅに、受信フレームを記録することが可能なだけの空きがあるか否かを判定する。該当するＱｕｅｕｅに空きがないと判定された場合、処理はステップＳ１０３へ進む。該当するＱｕｅｕｅに空きがあると判定された場合、処理はステップＳ１０４へ進む。

ステップＳ１０３では、フレームが廃棄される。廃棄制御部１２ｕは、Ｑｕｅｕｅに空きがないため、受信フレームを廃棄する。その後、本フローチャートに示された処理は終了する。

ステップＳ１０４では、Ｑｕｅｕｅにフレームが格納される。廃棄制御部１２ｕは、上りフレーム保持部１３ｕに受信フレームを渡す。受信フレームを受けた上りフレーム保持部１３ｕは、受信フレームを該当するフロー番号の上りトラフィック用Ｑｕｅｕｅに記録する。その後、処理はステップＳ１０５へ進む。

ステップＳ１０５では、流量調整指示の有無が判定される。帯域制御部１４ｕは、後述する流量計測部１６より流量調整指示が発行されているか否かを判定する。流量調整指示が発行されている場合、処理はステップＳ１０６へ進む。流量調整指示が発行されていない場合、処理はステップＳ１０７へ進む。

ステップＳ１０６では、フレーム送信後、転送間隔が経過したか否かが判定される。帯域制御部１４ｕは、流量調整指示が発行されていた場合に、適切な流量でリクエストフレームを転送するために、前回のフレーム送信後から転送間隔が経過したか否かを判定する。ここで、転送間隔とは、ＷＡＮ２０からデータセンタＬＡＮ３０ｂへのフレームを転送すべき間隔を示す時間（単位はｍｓｅｃ）である。転送間隔の算出方法については後述する（ステップＳ２０８を参照）。帯域制御部１４ｕは、転送間隔が経過したと判定されるまで、ステップＳ１０６の処理を繰り返す。転送間隔が経過したと判定された場合、処理はステップＳ１０７へ進む。

ステップＳ１０７では、Ｑｕｅｕｅから受信フレームの読み出しが行われる。帯域制御部１４ｕは、上りフレーム保持部１３ｕにフレーム取得依頼を発行し、これを受けた上りフレーム保持部１３ｕは、該当するＱｕｅｕｅから、最も以前にＱｕｅｕｅに入れられた受信フレームを読み出し、帯域制御部１４ｕへ渡す。その後、処理はステップＳ１０８へ進む。

ステップＳ１０８では、受信フレームがデータセンタＬＡＮ３０ｂへ送信される。帯域制御部１４ｕは、ステップＳ１０７で上りフレーム保持部１３ｕより渡されたフレームを、データセンタＬＡＮ３０ｂに接続されているＮＩＣ１０５へ渡す。その後、ＮＩＣ１０５によって受信フレームがＬＡＮ３０ｂへ送出されることで、受信フレームの転送が完了し、本フローチャートに示された処理は終了する。

図１３は、本実施形態における下りトラフィックに対する１フレーム受信毎の帯域制御の流れを示すフローチャートである。本フローチャートに示された処理は、ＮＩＣ１０５によってＷＡＮ２０宛のフレームが受信されたことを契機として開始され、ＣＰＵ１０１によって制御される。

ステップＳ２０１では、フローの識別が行われる。フロー識別部１１ｄは、受信したフレームのヘッダ情報を参照し、フローの識別を行う。例えば、フレームのヘッダ情報から該フレームの送信元がサーバ５０であることが識別できた場合、フロー識別部１１ｄは、受信したフレームのフロー番号を１とする。フロー識別部１１ｄは、識別結果および受信フレームを廃棄制御部１２ｄに渡す。その後、処理はステップＳ２０２へ進む。

ステップＳ２０２では、受信フレームがレスポンスフレームであるか否かが判定される。ここで、レスポンスフレームとは、サーバ５０が、クライアント４０から受信したリクエストフレームに対する応答としてクライアント４０宛に送信したフレームである。レスポンス計測部１５は、受信したフレームが前記レスポンスフレームであるか否かを判定する。受信フレームがレスポンスフレームであると判定された場合、処理はステップＳ２０３へ進む。受信フレームがレスポンスフレームではないと判定された場合、処理はステップＳ２０５へ進む。

ステップＳ２０３では、レスポンスメッセージが完成したか否かが判定される。レスポンス計測部１５は、受信したフレームが、これまでに受信したフレームとの組み合わせで、複数フレームに分割されたレスポンスメッセージを完成させるフレームであるか否かを判定する。即ち、ステップＳ２０３では、サーバ５０が１リクエストメッセージに対して
送信するレスポンスのトラフィック量を算出するために、フレームに分割された全てのレスポンスフレームが受信されたか否かが判定される。レスポンスメッセージが完成したと判定された場合、処理はステップＳ２０４へ進む。レスポンスメッセージが完成していないと判定された場合、処理はステップＳ２０５へ進む。

ステップＳ２０４では、予測トラフィック量の算出が行われる。レスポンス計測部１５は、サーバ５０が１リクエストメッセージに対して送信した全てのレスポンスフレームのサイズを計測し、合計することで、１リクエストメッセージに対するレスポンスのトラフィック量を算出する。そして、算出された各リクエストメッセージに対するレスポンスのトラフィック量から、１リクエストメッセージに対するレスポンストラフィックの平均サイズを算出する。レスポンス計測部１５は、この算出結果を予測トラフィック量として帯域制御部１４ｕへ渡す。その後、処理はステップＳ２０５へ進む。

ステップＳ２０５では、流量カウンタ加算が行われる。流量計測部１６は、受信フレームのサイズを、流量カウンタに加算する。この流量カウンタは、データセンタＬＡＮ３０ｂからＷＡＮ２０への１．０ｍｓｅｃあたりの流量を算出するためのカウンタである。その後、処理はステップＳ２０６へ進む。

ステップＳ２０６では、前回の流量判定（ステップＳ２０７）から１．０ｍｓｅｃが経過したか否かが判定される。流量計測部１６によって、前回の流量判定から１．０ｍｓｅｃが経過したと判定された場合、処理はステップＳ２０７へ進む。即ち、ステップＳ２０７の処理は、約１．０ｍｓｅｃに一度実行される。前回の流量判定から１．０ｍｓｅｃが経過していないと判定された場合、処理はステップＳ２０９へ進む。

ステップＳ２０７では、流量判定が行われる。流量計測部１６は、流量カウンタの示す流量が、ＷＡＮ２０へ送信可能な帯域幅を超えているか否かを判定する。即ち、流量計測部１６は、流量カウンタの示す１．０ｍｓｅｃあたりのデータセンタＬＡＮ３０ｂからＷＡＮ２０へ送信されるフレームのサイズの合計と、ＷＡＮ２０の１．０ｍｓｅｃあたりの帯域幅を比較する。この比較判定が行われた後、流量カウンタはリセットされる。流量が帯域幅を超えていると判定された場合、処理はステップＳ２０８へ進む。流量が帯域幅を超えていないと判定された場合、処理はステップＳ２０９へ進む。

ステップＳ２０８では、流量調整指示が発行される。流量計測部１６は、データセンタＬＡＮ３０ｂからＷＡＮ２０への流量がＷＡＮ２０の帯域幅を超えているため、流量調整指示を帯域制御部１４ｕへ発行する。ここで、ＷＡＮ２０からデータセンタＬＡＮ３０ｂへのフレームを転送する転送間隔が算出される。帯域制御部１４ｕは、後述するレスポンス計測部１５によって算出された予測トラフィック量、およびＷＡＮ２０の帯域を基に、ＷＡＮ２０からデータセンタＬＡＮ３０ｂへのフレームを転送すべき転送間隔を算出する。本実施形態では、転送間隔は、予測トラフィック量をＷＡＮ２０の帯域で割ることで算出される（単位はｍｓｅｃ）。この算出結果が、単位時間当たりにデータセンタＬＡＮ３０ｂへ転送してよいリクエストフレームの数である。その後、処理はステップＳ２０９へ進む。

ステップＳ２０９では、Ｑｕｅｕｅの空き状況が判定される。廃棄制御部１２ｄは、該当するフロー番号のＱｕｅｕｅに、受信フレームを記録することが可能なだけの空きがあるか否かを判定する。該当するＱｕｅｕｅに空きがないと判定された場合、処理はステップＳ２１０へ進む。該当するＱｕｅｕｅに空きがあると判定された場合、処理はステップＳ２１１へ進む。

ステップＳ２１０では、フレームが廃棄される。廃棄制御部１２ｄは、Ｑｕｅｕｅに空
きがないため、受信フレームを廃棄する。その後、本フローチャートに示された処理は終了する。

ステップＳ２１１では、Ｑｕｅｕｅにフレームが格納される。廃棄制御部１２ｄは、受信フレームを下りフレーム保持部１３ｄの該当するＱｕｅｕｅに記録する。その後、処理はステップＳ２１２へ進む。

ステップＳ２１２では、Ｑｕｅｕｅから受信フレームの読み出しが行われる。帯域制御部１４ｄは、下りフレーム保持部１３ｄにフレーム取得依頼を発行し、これを受けた下りフレーム保持部１３ｄは、該当するＱｕｅｕｅから、最も以前にＱｕｅｕｅに入れられた受信フレームを読み出し、帯域制御部１４ｄへ渡す。その後、処理はステップＳ２１３へ進む。

ステップＳ２１３では、受信フレームがＷＡＮ２０へ送信される。帯域制御部１４ｄは、ステップＳ２１２で下りフレーム保持部１３ｄより読み出されたフレームを、ＷＡＮ２０に接続されているＮＩＣ１０５へ渡す。その後、ＮＩＣ１０５によって受信フレームがＷＡＮ２０へ送出されることで、受信フレームの転送が完了し、本フローチャートに示された処理は終了する。

ここで、１００台のクライアント４０端末から送信されたＨＴＴＰリクエストメッセージが０．５ｍｓｅｃ間隔で帯域制御装置１０ｂに到着した場合の処理の流れを、図１２および図１３のフローチャートを用いて説明する。なお、ＨＴＴＰリクエストメッセージのサイズは４００バイトとし、サーバ５０および各クライアント４０端末は１フレームで１ＫＢまでのコンテンツを送信できるものとする。即ち、ＨＴＴＰリクエストメッセージは１フレームで送信される。また、帯域制御装置１０ｂがサーバ５０にＨＴＴＰリクエストメッセージを転送した後、サーバ５０からのレスポンスフレームが帯域制御装置１０ｂに到着するまでにかかる時間を２．０ｍｓｅｃとする。

帯域制御装置１０ｂがサーバ５０に最初のリクエストメッセージを転送すると（ステップＳ１０８）、これを受けたサーバ５０は、リクエストされたコンテンツ（サイズを１００ＫＢとする）を１００分割し、レスポンスフレームとして１ＫＢ分ずつクライアント４０宛に送信する。ここで、計算の簡略化のため１レスポンスフレームのサイズは１ＫＢとし、フレームの有する各種ヘッダのサイズは無視することとする。即ち、リクエストメッセージに対するレスポンスのトラフィックは０．５ｍｓｅｃ単位で１００ＫＢ、即ちＬＡＮ３０ｂの帯域である１Ｇｂｐｓに達するため、レスポンスのトラフィック量がＷＡＮ２０の帯域（１００Ｍｂｐｓ）を上回り、従来の帯域制御装置１０ｂでは、すぐに下りフレーム保持部１３ｄのＱｕｅｕｅが溢れてしまう。

本実施形態に係る帯域制御装置１０ｂがサーバ５０から送信されたレスポンスフレームを受信すると、レスポンス計測部１５は、分割送信されたレスポンスフレームを全て受信した時点でこれらのレスポンスフレームのサイズを合計し、１リクエストメッセージに対するレスポンスのトラフィック量を算出する（ステップＳ２０４）。ここでは、１リクエストメッセージに対するレスポンスのトラフィック量は１００ＫＢとなる。レスポンス計測部１５は、このサイズ（１００ＫＢ）を予測トラフィック量として帯域制御部１４ｕに渡す。

また、流量計測部１６は１．０ｍｓｅｃ単位でデータセンタＬＡＮ３０ｂからのトラフィックを計測する。本実施形態では、１リクエストメッセージに対するレスポンスメッセージのフレームをＬＡＮ３０ｂの帯域の上限である１Ｇｂｐｓ（０．８ｍｓｅｃ単位で１００ＫＢ）受信しており、ＷＡＮ２０の帯域（１Ｍｂｐｓ）を超えているため、流量計測
部１６は、帯域制御部１４ｕに対して流量調整指示を発行する（ステップＳ２０８）。

流量調整指示を受けた帯域制御部１４ｕは、レスポンス計測部１５による予測トラフィック量（１００ＫＢ）と、ＷＡＮ２０の帯域（１００Ｍｂｐｓ＝１２．５ＫＢ／ｍｓｅｃ）より、データセンタＬＡＮ３０ｂへのフレーム送信速度を８．０ｍｓｅｃ単位で１フレームに変更する（ステップＳ１０６）。このため、流量調整指示後にサーバ５０から受信されるレスポンスメッセージの流量は、８．０ｍｓｅｃ単位で１００ＫＢ、即ち１２．５ＫＢ／ｍｓｅｃとなるため、下りフレーム保持部１３ｄからＷＡＮ２０に送信可能な帯域と同等となり、下りフレーム保持部１３ｄがレスポンスフレームで溢れることはない。

即ち、本実施形態に拠れば、上りフレーム保持部を用いた帯域制御として、リクエストフレームの送信タイミング（間隔）を下りトラフィックのトラフィック量に応じて調整することで、下りトラフィックの送信レートを調整し、下りフレーム保持部のオーバーフローが抑制される。これによって、下りフレーム保持部に格納される各ユーザのレスポンスフレームに対する帯域制御（例えば、優先制御、最低帯域保障）が実施可能な状態を保つことが可能となる。以上から、従来の帯域制御装置１０ｂと同等のバッファサイズで、下りトラフィックについて帯域制御を実施可能なユーザ数、帯域制御が施されるトラフィック量を増やすことが可能となる。

＜第二の実施形態＞
以下に、第二の実施形態を説明する。第二の実施形態におけるネットワーク構成および帯域制御装置１０ｂのハードウェア構成は、第一の実施形態と同様であるため、説明を省略する。図１４は、本実施形態における帯域制御装置１０ｂが備える各機能による受信フレームの処理の流れの概要を示す図である。ＣＰＵ１０１は、ＲＡＭ１０２又はＲＯＭ１０４に展開されたプログラムを実行することで、フロー識別部１１ｕ、１１ｄ、廃棄制御部１２ｕ、１２ｄ、上り／下りフレーム保持部１３ｕ、１３ｄ、帯域制御部１４ｕ、１４ｄ、レスポンス計測部１５、流量計測部１６、又は制御対象フロー保持部１７として機能する。

制御対象フロー保持部１７は、フロー識別部１１ｕ、１１ｄで識別を行うフローごとに流量制御の有効／無効の設定を保持する。本実施形態ではフロー番号と、該フロー番号に対応するフローについての流量制御の有効（１）／無効（０）を示すフラグを保持する。この内容は予め管理者等により設定されているものとする。本エントリの構成例を図１５に示す。

流量計測部１６は、受信フレームのフロー番号で制御対象フロー保持部１７を検索し、フラグが有効を示す場合、サーバ５０からのフレーム流量を１．０ｍｓｅｃ単位で計測し、ＷＡＮ２０の物理帯域以上のフレーム受信レートになった時点で当該フロー番号に対する流量調整指示を帯域制御部１４ｕに渡す。

また、本実施形態における上りトラフィックの制御において、帯域制御部１４ｕは、通常は第一の実施形態において説明した通常の帯域制御ルールに従って帯域制御を行うが、流量計測部１６から流量調整指示を受け取ると、指定されたフロー番号に該当するＱｕｅｕｅに対して、レスポンス計測部１５からの予測トラフィック量とＷＡＮ２０の送信帯域を基にリクエストフレームの転送間隔を決定し、流量制御を行う。

フロー識別部１１ｕ、１１ｄ、廃棄制御部１２ｕ、１２ｄ、上り／下りフレーム保持部１３ｕ、１３ｄ、およびレスポンス計測部１５の機能は、第一の実施形態と同様であるため、これらについての説明は省略する。

図１６は、本実施形態における下りトラフィックに対する１フレーム受信毎の帯域制御の流れを示すフローチャートである。本フローチャートに示された処理は、ＮＩＣ１０５によってＷＡＮ２０宛のフレームが受信されたことを契機として開始され、ＣＰＵ１０１によって制御される。

ステップＳ３０１からステップＳ３０５までに示された処理は、図１３のステップＳ２０１からステップＳ２０５までに示された処理と同様であるため、説明を省略する。

ステップＳ３０６では、フロー番号に対応するフラグの検索要求が行われる。流量計測部１６は、制御対象フロー保持部１７にフロー番号を示して検索要求を行う。その後、処理はステップＳ３０７へ進む。

ステップＳ３０７では、該当するフロー番号について流量制御が有効であるか又は無効であるかが判定される。制御対象フロー部は、ステップＳ３０６での検索要求を受けて、該当するフロー番号に対応するフラグを読み出し、フラグの内容から有効（１）又は無効（０）を判定する。該当するフロー番号について流量制御が有効であると判定された場合、処理はステップＳ３０８へ進む。該当するフロー番号について流量制御が無効であると判定された場合、処理はステップＳ３１１へ進む。

ステップＳ３１１からステップＳ３１５までに示された処理は、図１３のステップＳ２０９からステップＳ２１３までに示された処理と同様であるため、説明を省略する。

即ち、該当するフロー番号について流量制御が有効である場合は、ステップＳ３０８以降の流量調整指示の発行処理が行われ、該当するフローに係る下りトラフィックの流量が一定以上である場合に流量調整指示が発行される。これに対し、該当するフロー番号について流量制御が無効である場合は、ステップＳ３０８からステップＳ３１０に示された処理がスキップされ、該当するフローに係る下りトラフィックの流量が一定以上である場合にも、流量調整指示は発行されない。

即ち、本実施形態に拠れば、特定フローごとに流量制御の有無を判断することで、特定のフローのみに流量制御を適用することが可能となる。

＜第三の実施形態＞
以下に、第三の実施形態を説明する。第三の実施形態におけるネットワーク構成および帯域制御装置１０ｂのハードウェア構成は、第一の実施形態と同様であるため、説明を省略する。図１７は、本実施形態における帯域制御装置１０ｂが備える各機能による受信フレームの処理の流れの概要を示す図である。ＣＰＵ１０１は、ＲＡＭ１０２又はＲＯＭ１０４に展開されたプログラムを実行することで、フロー識別部１１ｕ、１１ｄ、廃棄制御部１２ｕ、１２ｄ、上り／下りフレーム保持部１３ｕ、１３ｄ、帯域制御部１４ｕ、１４ｄ、レスポンス計測部１５、又はバッファ監視部１８として機能する。

フレーム保持部１３ｕ、１３ｄは、第一の実施形態において説明した機能を果たすＣＰＵ１０１であり、本実施形態では更に、各Ｑｕｅｕｅの空き状況をバッファ監視部１８に随時通知する。

バッファ監視部１８は、下りフレーム保持部１３ｄの各Ｑｕｅｕｅの空き状況を監視し、４０％以上のＱｕｅｕｅの利用率になった時点で流量調整指示を帯域制御部１４ｕに発行する。これを受けた帯域制御部１４ｕは、第一の実施形態において流量計測部１６より流量調整指示を受けた場合と同様に、上記バッファ監視部１８より発行された流量調整指示に従って、前述の流量制御（図１２のステップＳ１０６およびステップＳ１０７を参照
）を行う。

フロー識別部１１ｕ、１１ｄ、廃棄制御部１２ｕ、１２ｄ、帯域制御部１４ｕ、１４ｄ、およびレスポンス計測部１５の機能は、第一の実施形態と同様であるため、これらについての説明は省略する。

図１８は、本実施形態におけるバッファ監視処理の流れを示すフローチャートである。本フローチャートに示された処理は、所定の間隔で定期的に実行され、ＣＰＵ１０１によって制御される。

ステップＳ４０１では、Ｑｕｅｕｅ利用率が所定の比率を超えているか否かが判定される。バッファ監視部１８は、下りフレーム保持部１３ｄよりＱｕｅｕｅの空き状況を取得し、Ｑｕｅｕｅ利用率が所定の比率を超えているか否かを判定する。本実施形態では、所定の比率を４０％とする。Ｑｕｅｕｅ利用率が４０％を超えていると判定された場合、処理はステップＳ４０２へ進む。Ｑｕｅｕｅ利用率が４０％を超えていないと判定された場合、本フローチャートに示された処理は終了する。

ステップＳ４０２では、流量調整指示が発行される。バッファ監視部１８は、データセンタＬＡＮ３０ｂからＷＡＮ２０へのトラフィック用Ｑｕｅｕｅ利用率が所定の比率（４０％）を超えているため、流量調整指示を帯域制御部１４ｕへ発行する。ここで、ＷＡＮ２０からデータセンタＬＡＮ３０ｂへのフレームを転送する転送間隔が算出される。帯域制御部１４ｕは、レスポンス計測部１５によって算出された予測トラフィック量、およびＷＡＮ２０の帯域を基に、ＷＡＮ２０からデータセンタＬＡＮ３０ｂへのフレームを転送すべき転送間隔を算出する。その後、本フローチャートに示された処理は終了する。

即ち、本実施形態に拠れば、下りトラフィック用のＱｕｅｕｅにフレームが所定の量溜まるまでは従来の方法でＱｕｅｕｅ制御を行い、下りトラフィック用のＱｕｅｕｅに所定の量フレームが溜まった後に流量制御を開始することで、下りのフレームＱｕｅｕｅを有効に使うことが可能となる。

＜第四の実施形態＞
以下に、第四の実施形態を説明する。第四の実施形態におけるネットワーク構成および帯域制御装置１０ｂのハードウェア構成は、第一の実施形態と同様であるため、説明を省略する。図１９は、本実施形態における帯域制御装置１０ｂが備える各機能による受信フレームの処理の流れの概要を示す図である。ＣＰＵ１０１は、ＲＡＭ１０２又はＲＯＭ１０４に展開されたプログラムを実行することで、リクエスト識別部１９、フロー識別部１１ｕ、１１ｄ、廃棄制御部１２ｕ、１２ｄ、上り／下りフレーム保持部１３ｕ、１３ｄ、帯域制御部１４ｕ、１４ｄ、レスポンス計測部１５、又は流量計測部１６として機能する。

リクエスト識別部１９は、ＷＡＮ２０からの受信フレームの識別を行い、該フレームがＨＴＴＰリクエストメッセージの場合、フロー識別部１１ｕにフレームを渡し、該フレームがＨＴＴＰリクエストメッセージに係るフレームでない場合、そのフレームをデータセンタＬＡＮ３０ｂに転送する。

フロー識別部１１ｕ、１１ｄ、廃棄制御部１２ｕ、１２ｄ、上り／下りフレーム保持部１３ｕ、１３ｄ、帯域制御部１４ｕ、１４ｄ、レスポンス計測部１５、および流量計測部１６の機能は、第一の実施形態と同様であるため、これらについての説明は省略する。

図２０は、本実施形態における上りトラフィックに対する１フレーム受信毎の帯域制御
の流れを示すフローチャートである。本フローチャートに示された処理は、ＮＩＣ１０５によってデータセンタＬＡＮ３０ｂ宛のフレームが受信されたことを契機として開始され、ＣＰＵ１０１によって制御される。

ステップＳ５０１では、受信したフレームがＨＴＴＰリクエストメッセージに係るフレームであるか否かが判定される。リクエスト制御部は、受信フレームのヘッダ情報等（フレームサイズ、プロトコル番号、ポート番号、メッセージ内容等）から、該フレームがＨＴＴＰリクエストメッセージに係るフレームであるか否かを判定する。受信フレームがＨＴＴＰリクエストメッセージに係るフレームであると判定された場合、処理はステップＳ５０２へ進む。受信フレームがＨＴＴＰリクエストメッセージに係るフレームではないと判定された場合、処理はステップＳ５０９へ進む。

ステップＳ５０２以降の処理は、図１２に示されたステップＳ１０１からステップＳ１０８の処理と同様であるため、説明を省略する。

即ち、帯域制御装置１０ｂがＷＡＮ２０から受信したフレームがＨＴＴＰリクエストメッセージに係るフレームではなく、例えば、ＩＣＭＰのＥｃｈｏリクエストフレーム等であった場合、該フレームは、流量調整指示に基づく流量制御を受けることなく、データセンタＬＡＮ３０ｂへ転送される。

即ち、本実施形態に拠れば、ＨＴＴＰリクエストメッセージのみを流量制御の対象とすることで、上りトラフィックのＱｕｅｕｅに利用するメモリ量および流量制御のためのＣＰＵ使用量を削減することが可能となる。

＜第五の実施形態＞
以下に、第五の実施形態を説明する。第五の実施形態におけるネットワーク構成および帯域制御装置１０ｂのハードウェア構成は、第一の実施形態と同様であるため、説明を省略する。図２１は、本実施形態における帯域制御装置１０ｂが備える各機能による受信フレームの処理の流れの概要を示す図である。ＣＰＵ１０１は、ＲＡＭ１０２又はＲＯＭ１０４に展開されたプログラムを実行することで、フロー識別部１１ｕ、１１ｄ、廃棄制御部１２ｕ、１２ｄ、上り／下りフレーム保持部１３ｕ、１３ｄ、帯域制御部１４ｕ、１４ｄ、レスポンス計測部１５、未応答サイズカウント部２３、予測トラフィック量保持部２１、又はクライアント送信部２２として機能する。

未応答サイズカウント部２３は、データセンタＬＡＮ３０ｂにリクエストメッセージを送信したが、ＷＡＮ２０にレスポンスメッセージを送信していないレスポンスメッセージの予測トラフィック量をフローごとにカウントし、保持する未応答サイズカウンタを有する。図２２は、本実施形態における未応答サイズカウンタの構成例を示す図である。

予測トラフィック量保持部２１は、ＨＴＴＰリクエストメッセージごとに、リクエストメッセージの送信対象のＵＲＬ、サーバ５０ＩＰアドレス、クライアント４０ＩＰアドレス、フロー番号および予測トラフィック量等のリクエスト識別情報を保持する。この構成例を図２３に示す。

クライアント送信部２２は、レスポンスメッセージの送信時に、メッセージに付与されているＵＲＬ、サーバ５０ＩＰアドレス、クライアント４０ＩＰアドレス等のリクエスト識別情報から予測トラフィック量保持部２１のエントリを検索し、該当するフロー番号および予測トラフィック量を取得する。未応答サイズカウント部２３のカウンタ値から前記予測トラフィック量だけ減算する。

また、帯域制御部１４ｕ、１４ｄは、通常は第一の実施形態において説明した通常の帯域制御ルールに従って帯域制御を行う。ここで、本実施形態における上りトラフィックに係る制御において、帯域制御部１４ｕは、データセンタＬＡＮ３０ｂに対してＨＴＴＰリクエストメッセージを送信する前に、上記未応答サイズカウント部２３のカウンタ値をレスポンス計測部１５から得た予測トラフィック量分だけ加算する。また、この際に対象のＵＲＬ、サーバ５０ＩＰアドレス、クライアント４０ＩＰアドレス、フロー番号および予測トラフィック量を予測トラフィック量保持部２１に渡す。

更に、帯域制御部１４ｕは、未応答サイズカウント部２３のカウンタ値がＱｕｅｕｅの空きサイズを超えた時点でフレーム保持部１３ｕからのフレーム読み出しを停止する。未応答サイズカウント部２３の値が下りトラフィック用のＱｕｅｕｅの空きサイズを超えていない場合、フレーム保持部１３ｕに対してフレーム取得依頼を渡し、フレーム保持部１３ｕから渡されたフレームをデータセンタＬＡＮ３０ｂに転送する。

フロー識別部１１ｕ、１１ｄ、廃棄制御部１２ｕ、１２ｄ、上り／下りフレーム保持部１３ｕ、１３ｄ、帯域制御部１４ｕ、１４ｄ、およびレスポンス計測部１５の機能は、第一の実施形態と同様であるため、これらについての説明は省略する。

図２４は、本実施形態における上りトラフィックに対する１フレーム受信毎の帯域制御の流れを示すフローチャートである。本フローチャートに示された処理は、ＮＩＣ１０５によってデータセンタＬＡＮ３０ｂ宛のフレームが受信されたことを契機として開始され、ＣＰＵ１０１によって制御される。

ステップＳ６０１からステップＳ６０４の処理は、図１２に示されたステップＳ１０１からステップＳ１０４の処理と同様であるため、説明を省略する。

ステップＳ６０５では、未応答サイズカウンタが下りトラフィック用Ｑｕｅｕｅの空きサイズを超えているか否かが判定される。帯域制御部１４ｕは、未応答サイズカウント部２３から未応答サイズカウンタの値を取得し、該カウンタが下りトラフィック用Ｑｕｅｕｅの空きサイズを超えているか否かを判定する。本実施形態において、Ｑｕｅｕｅのサイズは２ＭＢであるため、下りトラフィック用Ｑｕｅｕｅの空きサイズは「２ＭＢ−現時点での下りトラフィック用Ｑｕｅｕｅの使用容量」である。未応答サイズカウンタの値は、以降サーバ５０からレスポンスフレームとして受信されると予測されるトラフィックのサイズを示しており、これが下りトラフィック用Ｑｕｅｕｅの空きサイズを超えるということは、Ｑｕｅｕｅが溢れる可能性があるということを意味するからである。未応答サイズカウンタが下りトラフィック用Ｑｕｅｕｅの空きサイズを超えていない場合、Ｑｕｅｕｅ溢れは予測されないため、処理はステップＳ６０６へ進む。未応答サイズカウンタが下りトラフィック用Ｑｕｅｕｅの空きサイズを超えている場合、Ｑｕｅｕｅ溢れが予測されるため、未応答サイズカウンタが２ＭＢ以下となるまで、ステップＳ６０５の判定処理が繰り返される。

ステップＳ６０６では、Ｑｕｅｕｅから受信フレームの読み出しが行われる。帯域制御部１４ｕは、上りフレーム保持部１３ｕにフレーム取得依頼を発行し、これを受けた上りフレーム保持部１３ｕは、該当するＱｕｅｕｅから、最も以前にＱｕｅｕｅに入れられた受信フレームを読み出し、帯域制御部１４ｕへ渡す。その後、処理はステップＳ６０７へ進む。

ステップＳ６０７では、予測トラフィック量が記録される。予測トラフィック量保持部２１は、リクエストメッセージの送信対象のＵＲＬ、サーバ５０ＩＰアドレス、クライアント４０ＩＰアドレス、フロー番号および該リクエストメッセージに対して発生すると予
測されるレスポンスの予測トラフィック量をＲＡＭ１０２に記録する。ここで記録される予測トラフィック量は、本処理以前にレスポンス計測部１５によって算出された予測トラフィック量である。その後、処理はステップＳ６０８へ進む。

ステップＳ６０８では、未応答サイズカウンタに予測トラフィック量が加算される。未応答サイズカウント部２３は、ステップＳ６０７で予測トラフィック量保持部２１によって保持された予測トラフィック量を、未応答サイズカウンタに加算する。その後、処理はステップＳ６０９へ進む。

ステップＳ６０９では、受信フレームがデータセンタＬＡＮ３０ｂへ送信される。帯域制御部１４ｕは、ステップＳ６０６で上りフレーム保持部１３ｕより渡されたフレームを、データセンタＬＡＮ３０ｂに接続されているＮＩＣ１０５へ渡す。その後、ＮＩＣ１０５によって受信フレームがＬＡＮ３０ｂへ送出されることで、受信フレームの転送が完了し、本フローチャートに示された処理は終了する。

図２５は、本実施形態における下りトラフィックに対する１フレーム受信毎の帯域制御の流れを示すフローチャートである。本フローチャートに示された処理は、ＮＩＣ１０５によってＷＡＮ２０宛のフレームが受信されたことを契機として開始され、ＣＰＵ１０１によって制御される。

ステップＳ７０１からステップＳ７０８の処理は、図１３に示されたステップＳ２０１からステップＳ２０４、およびステップＳ２０９からステップＳ２１２の処理と同様であるため、説明を省略する。即ち、本実施形態では、第一の実施形態に係る図１３に示された、流量計測部１６によるステップＳ２０５からステップＳ２０８の処理は行われない。流量計測部１６に代わって、帯域制御部１４ｕが、未応答サイズカウント部２３より取得したカウンタ値に基づいて、流量制御の開始／終了を判定するためである。

ステップＳ７０９では、レスポンスメッセージが完成したか否かが判定される。クライアント送信部２２は、受信したフレームが、これまでに受信したフレームとの組み合わせで、複数フレームに分割されたレスポンスメッセージを完成させるフレームであるか否かを判定する。レスポンスメッセージが完成したと判定された場合、処理はステップＳ７１０へ進む。レスポンスメッセージが完成していないと判定された場合、処理はステップＳ７１２へ進む。

ステップＳ７１０では、受信フレームに係るレスポンスメッセージの予測トラフィック量が読み出される。クライアント送信部２２は、レスポンスメッセージの送信元のＵＲＬ、サーバ５０ＩＰアドレス、クライアント４０ＩＰアドレス、フロー番号を基に、予測トラフィック量保持部２１から該当する予測トラフィック量を読み出す。その後、処理はステップＳ７１１へ進む。

ステップＳ７１１では、未応答サイズカウンタから予測トラフィック量が減算される。未応答サイズカウント部２３は、ステップＳ７１０で読み出された、レスポンスメッセージに係る予測トラフィック量を未応答サイズカウンタから減算する。即ち、リクエストメッセージに対するレスポンスメッセージが全て受信されたため、該リクエストメッセージをサーバ５０に転送した時にステップＳ６０８で加算された、該リクエストメッセージに対する予測トラフィック量を減算する。リクエストメッセージの転送時にカウンタを加算し（ステップＳ６０８を参照）、これに対するレスポンスメッセージの転送時にカウンタを減算することで、未応答サイズカウンタには、データセンタＬＡＮ３０ｂにリクエストメッセージを送信したが、ＷＡＮ２０にレスポンスメッセージを送信していないレスポンスメッセージの予測トラフィック量、即ち、下りトラフィック用Ｑｕｅｕｅに確保してお
くべき空き容量の値が保持される。この未応答サイズカウンタの値が図２４に示すステップＳ６０５の処理で取得され、Ｑｕｅｕｅ溢れの予測を行うための判定指標となる。その後、処理はステップＳ７１２へ進む。

ステップＳ７１２では、受信フレームがＷＡＮ２０へ送信される。クライアント送信部２２は、ステップＳ７０８で下りフレーム保持部１３ｄより読み出されたフレームを、ＷＡＮ２０に接続されているＮＩＣ１０５へ渡す。その後、ＮＩＣ１０５によって受信フレームがＷＡＮ２０へ送出されることで、受信フレームの転送が完了し、本フローチャートに示された処理は終了する。

本実施形態に拠れば、下りトラフィック用のＱｕｅｕｅの空きサイズ以上のＨＴＴＰリクエストがサーバ５０に集中することがなくなり、サーバ５０の処理遅延によるフレーム廃棄の確率を低減することが可能となる。

また、本発明は、以下のような付記的事項を含むものである。

＜その他＞
本発明は、以下のように特定することが出来る。
（付記１）
双方向通信に係るフレームを受信し、該フレームを送信することで通信を中継する帯域制御装置であって、
受信フレームのうち、他の処理装置に対するデータ送信要求であるリクエストフレームを保持するフレーム保持手段と、
受信フレームのうち、前記データ送信要求を受けて他の処理装置から送信されたデータを含むレスポンスフレームのサイズを計測し、該計測されたサイズに基づいて、前記リクエストフレームに対する応答として受信されると予測されるレスポンスフレームによるトラフィックの量である予測トラフィック量を算出するレスポンス計測手段と、
前記レスポンス計測手段によって算出された予測トラフィック量に基づいて、前記フレーム保持手段によって保持されるリクエストフレームを送信するタイミングを調整し、該リクエストフレームの流量制御を行う帯域制御手段と、
を備える帯域制御装置。
（付記２）
前記レスポンスフレームによるトラフィック量を計測し、該トラフィック量が所定の値を超えたときに、前記帯域制御手段に対して前記流量制御の開始を指示する流量計測手段を更に備え、
前記帯域制御手段は、前記流量制御の開始の指示を受けて、前記流量制御を開始する、
付記１に記載の帯域制御装置。
（付記３）
前記フレーム保持手段は、該フレーム保持手段によって保持されているフレームの量に関連する情報であるバッファ情報を前記帯域制御手段に通知し、
前記帯域制御手段は、前記フレーム保持手段によって通知された前記バッファ情報が示す前記フレーム保持手段によって保持されているフレームの量が所定の閾値以下である場合に、前記流量制御を終了する、
付記２に記載の帯域制御装置。
（付記４）
受信フレームのうち、リクエストフレームと該リクエストフレームに対応するレスポンスフレームとの組み合わせであるフロー毎に、前記流量制御の有効又は無効を示す情報を、前記フローを識別する情報と共に保持する制御対象フロー保持手段を更に備え、
前記流量計測手段は、受信したフレームに係るフローについて、前記制御対象フロー保持手段によって保持される前記流量制御の有効又は無効を示す情報を、前記フローを識別
する情報を基に検索し、前記流量制御が無効である場合は、前記帯域制御手段に対して前記流量制御の開始を指示しない、
付記２又は付記３に記載の帯域制御装置。
（付記５）
前記フレーム保持手段によって保持されているフレームの量に関連する情報であるバッファ情報を定期的に取得することで、前記フレーム保持手段の利用状況を監視し、前記バッファ情報の示すフレームの量が所定の閾値を超えた場合に、前記帯域制御手段に対して前記流量制御の開始を指示するバッファ監視手段を更に備える、付記１に記載の帯域制御装置。
（付記６）
受信フレームがリクエストフレームであるか否かを識別し、受信フレームがリクエストフレームである場合、該受信フレームを前記フレーム保持手段に保持させ、受信フレームがリクエストフレームでない場合、該受信フレームを前記フレーム保持手段に保持させずに送信するリクエスト識別手段を更に備える、付記２又は付記３に記載の帯域制御装置。（付記７）
受信したリクエストフレームに対応するレスポンスフレームのうち、未受信であるレスポンスフレームの総予測トラフィック量を保持する未応答サイズ保持手段と、
受信したリクエストフレームに対応する前記予測トラフィック量を前記未応答サイズ保持手段に加算する予測トラフィック量加算手段と、
前記リクエストフレームに対応するレスポンスフレームを送信する際に、該レスポンスフレームのトラフィック量を前記未応答サイズ保持手段から減算するレスポンストラフィック量減算手段と、
を更に備え、
前記帯域制御手段は、前記総予測トラフィック量と前記フレーム保持手段の空き容量とを比較した結果に基づいて、前記フレーム保持手段によって保持されるリクエストフレームを送信するタイミングを調整し、前記流量制御を行う、
付記１に記載の帯域制御装置。
（付記８）
受信したリクエストフレームに対応するレスポンスフレームのうち、未受信であるレスポンスフレームの総予測トラフィック量を保持する未応答サイズ保持手段と、
受信したリクエストフレームに対応する前記予測トラフィック量を前記未応答サイズ保持手段に加算する予測トラフィック量加算手段と、
受信したリクエストフレームに対応する前記予測トラフィック量を、リクエストフレームと該リクエストフレームに対応するレスポンスフレームとの組み合わせであるフロー毎に保持する予測トラフィック量保持手段と、
前記リクエストフレームに対応するレスポンスフレームを送信する際に、前記予測トラフィック量保持手段によって保持されるフロー毎の前記予測トラフィック量から、送信するレスポンスフレームに対応する予測トラフィック量を取得し、取得した予測トラフィック量を前記未応答サイズ保持手段から減算する予測トラフィック量減算手段と、
を更に備え、
前記帯域制御手段は、前記総予測トラフィック量と前記フレーム保持手段の空き容量とを比較した結果に基づいて、前記フレーム保持手段によって保持されるリクエストフレームを送信するタイミングを調整し、前記流量制御を行う、
付記１に記載の帯域制御装置。
（付記９）
受信フレームのうち、他の処理装置に対するデータ送信要求であるリクエストフレームを保持するフレーム保持ステップと、
受信フレームのうち、前記データ送信要求を受けて他の処理装置から送信されたデータを含むレスポンスフレームのサイズを計測し、該計測されたサイズに基づいて、前記リクエストフレームに対する応答として受信されると予測されるレスポンスフレームによるト
ラフィックの量である予測トラフィック量を算出するレスポンス計測ステップと、
前記レスポンス計測ステップで算出された予測トラフィック量に基づいて、前記フレーム保持ステップで保持されるリクエストフレームを送信するタイミングを調整し、該リクエストフレームの流量制御を行う帯域制御ステップと、
を備える帯域制御方法。
（付記１０）
前記レスポンスフレームによるトラフィック量を計測し、該トラフィック量が所定の値を超えたときに、前記帯域制御ステップに対して前記流量制御の開始を指示する流量計測ステップを更に備え、
前記帯域制御ステップでは、前記流量制御の開始の指示を受けて、前記流量制御が開始される、
付記９に記載の帯域制御方法。
（付記１１）
受信したリクエストフレームに対応するレスポンスフレームのうち、未受信であるレスポンスフレームの総予測トラフィック量を保持する未応答サイズ保持ステップと、
受信したリクエストフレームに対応する前記予測トラフィック量を前記未応答サイズ保持ステップに加算する予測トラフィック量加算ステップと、
前記リクエストフレームに対応するレスポンスフレームを送信する際に、該レスポンスフレームのトラフィック量を前記未応答サイズ保持ステップから減算するレスポンストラフィック量減算ステップと、
を更に備え、
前記帯域制御ステップでは、前記総予測トラフィック量と前記フレーム保持ステップの空き容量とを比較した結果に基づいて、前記フレーム保持ステップで保持されるリクエストフレームを送信するタイミングが調整され、前記流量制御を行う、
付記９に記載の帯域制御方法。
（付記１２）
受信したリクエストフレームに対応するレスポンスフレームのうち、未受信であるレスポンスフレームの総予測トラフィック量を保持する未応答サイズ保持ステップと、
受信したリクエストフレームに対応する前記予測トラフィック量を前記未応答サイズ保持ステップに加算する予測トラフィック量加算ステップと、
受信したリクエストフレームに対応する前記予測トラフィック量を、リクエストフレームと該リクエストフレームに対応するレスポンスフレームとの組み合わせであるフロー毎に保持する予測トラフィック量保持ステップと、
前記リクエストフレームに対応するレスポンスフレームを送信する際に、前記予測トラフィック量保持ステップで保持されるフロー毎の前記予測トラフィック量から、送信するレスポンスフレームに対応する予測トラフィック量を取得し、取得した予測トラフィック量を前記未応答サイズ保持ステップから減算する予測トラフィック量減算ステップと、
を更に備え、
前記帯域制御ステップでは、前記総予測トラフィック量と前記フレーム保持ステップの空き容量とを比較した結果に基づいて、前記フレーム保持ステップで保持されるリクエストフレームを送信するタイミングが調整され、前記流量制御を行う、
付記９に記載の帯域制御方法。
（付記１３）
双方向通信に係るフレームを受信し、該フレームを送信することで通信を中継する処理装置を、
受信フレームのうち、他の処理装置に対するデータ送信要求であるリクエストフレームを保持するフレーム保持手段と、
受信フレームのうち、前記データ送信要求を受けて他の処理装置から送信されたデータを含むレスポンスフレームのサイズを計測し、該計測されたサイズに基づいて、前記リクエストフレームに対する応答として受信されると予測されるレスポンスフレームによるト
ラフィックの量である予測トラフィック量を算出するレスポンス計測手段と、
前記レスポンス計測手段によって算出された予測トラフィック量に基づいて、前記フレーム保持手段によって保持されるリクエストフレームを送信するタイミングを調整し、該リクエストフレームの流量制御を行う帯域制御手段と、
として機能させる帯域制御プログラム。
（付記１４）
前記処理装置を、前記レスポンスフレームによるトラフィック量を計測し、該トラフィック量が所定の値を超えたときに、前記帯域制御手段に対して前記流量制御の開始を指示する流量計測手段として更に機能させ、
前記帯域制御手段は、前記流量制御の開始の指示を受けて、前記流量制御を開始する、
付記１３に記載の帯域制御プログラム。
（付記１５）
前記フレーム保持手段は、該フレーム保持手段によって保持されているフレームの量に関連する情報であるバッファ情報を前記帯域制御手段に通知し、
前記帯域制御手段は、前記フレーム保持手段によって通知された前記バッファ情報が示す前記フレーム保持手段によって保持されているフレームの量が所定の閾値以下である場合に、前記流量制御を終了する、
付記１４に記載の帯域制御プログラム。
（付記１６）
前記処理装置を、受信フレームのうち、リクエストフレームと該リクエストフレームに対応するレスポンスフレームとの組み合わせであるフロー毎に、前記流量制御の有効又は無効を示す情報を、前記フローを識別する情報と共に保持する制御対象フロー保持手段として更に機能させ、
前記流量計測手段は、受信したフレームに係るフローについて、前記制御対象フロー保持手段によって保持される前記流量制御の有効又は無効を示す情報を、前記フローを識別する情報を基に検索し、前記流量制御が無効である場合は、前記帯域制御手段に対して前記流量制御の開始を指示しない、
付記１４又は付記１５に記載の帯域制御プログラム。
（付記１７）
前記処理装置を、前記フレーム保持手段によって保持されているフレームの量に関連する情報であるバッファ情報を定期的に取得することで、前記フレーム保持手段の利用状況を監視し、前記バッファ情報の示すフレームの量が所定の閾値を超えた場合に、前記帯域制御手段に対して前記流量制御の開始を指示するバッファ監視手段として更に機能させる、付記１３に記載の帯域制御プログラム。
（付記１８）
前記処理装置を、受信フレームがリクエストフレームであるか否かを識別し、受信フレームがリクエストフレームである場合、該受信フレームを前記フレーム保持手段に保持させ、受信フレームがリクエストフレームでない場合、該受信フレームを前記フレーム保持手段に保持させずに送信するリクエスト識別手段として更に機能させる、付記１４又は付記１５に記載の帯域制御プログラム。
（付記１９）
前記処理装置を、
受信したリクエストフレームに対応するレスポンスフレームのうち、未受信であるレスポンスフレームの総予測トラフィック量を保持する未応答サイズ保持手段と、
受信したリクエストフレームに対応する前記予測トラフィック量を前記未応答サイズ保持手段に加算する予測トラフィック量加算手段と、
前記リクエストフレームに対応するレスポンスフレームを送信する際に、該レスポンスフレームのトラフィック量を前記未応答サイズ保持手段から減算するレスポンストラフィック量減算手段と、
として更に機能させ、
前記帯域制御手段は、前記総予測トラフィック量と前記フレーム保持手段の空き容量とを比較した結果に基づいて、前記フレーム保持手段によって保持されるリクエストフレームを送信するタイミングを調整し、前記流量制御を行う、
付記１３に記載の帯域制御プログラム。
（付記２０）
前記処理装置を、
受信したリクエストフレームに対応するレスポンスフレームのうち、未受信であるレスポンスフレームの総予測トラフィック量を保持する未応答サイズ保持手段と、
受信したリクエストフレームに対応する前記予測トラフィック量を前記未応答サイズ保持手段に加算する予測トラフィック量加算手段と、
受信したリクエストフレームに対応する前記予測トラフィック量を、リクエストフレームと該リクエストフレームに対応するレスポンスフレームとの組み合わせであるフロー毎に保持する予測トラフィック量保持手段と、
前記リクエストフレームに対応するレスポンスフレームを送信する際に、前記予測トラフィック量保持手段によって保持されるフロー毎の前記予測トラフィック量から、送信するレスポンスフレームに対応する予測トラフィック量を取得し、取得した予測トラフィック量を前記未応答サイズ保持手段から減算する予測トラフィック量減算手段と、
として更に機能させ、
前記帯域制御手段は、前記総予測トラフィック量と前記フレーム保持手段の空き容量とを比較した結果に基づいて、前記フレーム保持手段によって保持されるリクエストフレームを送信するタイミングを調整し、前記流量制御を行う、
付記１３に記載の帯域制御プログラム。

帯域制御装置の利用例を示す図 従来技術における帯域制御装置の構成例を示す図 従来技術におけるフレーム廃棄発生時の状況を示す図である。 従来技術においてフレーム廃棄が発生する状況を示すグラフである。 本発明の原理構成を示す図 実施形態におけるトラフィックの特徴を示す図である。 実施形態におけるネットワーク構成の概略を示す図である。 実施形態における帯域制御装置のハードウェア構成の概略を示す図である。 実施形態における帯域制御装置が備える各機能による受信フレームの処理の流れの概要を示す図である。 実施形態におけるフレーム保持部の内部構成を示す図である。 実施形態における流量計測カウンタの構成の概略を示す図である。 実施形態における上りトラフィックに対する１フレーム受信毎の帯域制御の流れを示すフローチャートである。 実施形態における下りトラフィックに対する１フレーム受信毎の帯域制御の流れを示すフローチャートである。 実施形態における帯域制御装置が備える各機能による受信フレームの処理の流れの概要を示す図である。 実施形態におけるフロー毎の流量制御の有効／無効フラグを保持するエントリの構成の概略を示す図である。 実施形態における下りトラフィックに対する１フレーム受信毎の帯域制御の流れを示すフローチャートである。 実施形態における帯域制御装置が備える各機能による受信フレームの処理の流れの概要を示す図である。 実施形態におけるバッファ監視処理の流れを示すフローチャートである。 実施形態における帯域制御装置が備える各機能による受信フレームの処理の流れの概要を示す図である。 実施形態における上りトラフィックに対する１フレーム受信毎の帯域制御の流れを示すフローチャートである。 実施形態における帯域制御装置が備える各機能による受信フレームの処理の流れの概要を示す図である。 実施形態における未応答サイズカウンタの構成例を示す図である。 実施形態において予測トラフィック量保持部が保持するリクエスト識別情報の構成例を示す図である。 実施形態における上りトラフィックに対する１フレーム受信毎の帯域制御の流れを示すフローチャートである。 実施形態における下りトラフィックに対する１フレーム受信毎の帯域制御の流れを示すフローチャートである。

符号の説明

１０ａ ゲートウェイ
１０ｂ 帯域制御装置
２０ ＷＡＮ
３０ａ 拠点ＬＡＮ
３０ｂ データセンタＬＡＮ
４０ クライアント
５０ サーバ

Claims (9)

1. 受信フレームのうち、他の処理装置に対するデータ送信要求であるリクエストフレームを保持するフレーム保持手段と、
   受信フレームのうち、前記データ送信要求を受けて他の処理装置から送信されたデータを含むレスポンスフレームのサイズを計測し、該計測されたサイズに基づいて、前記リクエストフレームに対する応答として受信されると予測されるレスポンスフレームによるトラフィックの量である予測トラフィック量を算出するレスポンス計測手段と、
   前記レスポンス計測手段によって算出された予測トラフィック量に基づいて、前記フレーム保持手段によって保持されるリクエストフレームを送信するタイミングを調整し、該リクエストフレームの流量制御を行う帯域制御手段と、
   を備える帯域制御装置。
2. 前記レスポンスフレームによるトラフィック量を計測する流量計測手段を更に備え、
   前記帯域制御手段は、前記流量計測手段によって所定の値を超える前記トラフィック量が計測されたときに、前記流量制御を開始する、
   請求項１に記載の帯域制御装置。
3. 前記フレーム保持手段は、該フレーム保持手段によって保持されているフレームの量に関連する情報であるバッファ情報を前記帯域制御手段に通知し、
   前記帯域制御手段は、前記フレーム保持手段によって通知された前記バッファ情報が示す前記フレーム保持手段によって保持されているフレームの量が所定の閾値以下である場合に、前記流量制御を終了する、
   請求項２に記載の帯域制御装置。
4. 受信フレームのうち、リクエストフレームと該リクエストフレームに対応するレスポンスフレームとの組み合わせであるフロー毎に、前記流量制御の有効又は無効を示す情報を、前記フローを識別する情報と共に保持する制御対象フロー保持手段を更に備え、
   前記帯域制御手段は、受信したフレームに係るフローについて、前記制御対象フロー保持手段によって保持される前記流量制御の有効又は無効を示す情報を、前記フローを識別する情報を基に検索し、前記流量制御が無効である場合は、前記流量制御を開始しない、
   請求項２又は請求項３に記載の帯域制御装置。
5. 前記フレーム保持手段は、受信フレームのうち、前記レスポンスフレームを保持し、
   前記フレーム保持手段によって保持されているフレームの量に関連する情報であるバッファ情報を定期的に取得することで、前記フレーム保持手段の利用状況を監視し、前記バッファ情報の示すフレームの量が所定の閾値を超えた場合に、前記帯域制御手段に前記流量制御を開始させるバッファ監視手段を更に備える、
   請求項１に記載の帯域制御装置。
6. 受信フレームがリクエストフレームであるか否かを識別し、受信フレームがリクエストフレームである場合、該受信フレームを前記フレーム保持手段に保持させ、受信フレームがリクエストフレームでない場合、該受信フレームを前記フレーム保持手段に保持させずに送信するリクエスト識別手段を更に備える、請求項２又は請求項３に記載の帯域制御装置。
7. 受信したリクエストフレームに対応するレスポンスフレームのうち、未受信であるレスポンスフレームの総予測トラフィック量を保持する未応答サイズ保持手段と、
   受信したリクエストフレームに対応する前記予測トラフィック量を前記未応答サイズ保持手段に加算する予測トラフィック量加算手段と、
   前記リクエストフレームに対応するレスポンスフレームを送信する際に、該レスポンスフレームのトラフィック量を前記未応答サイズ保持手段から減算するレスポンストラフィック量減算手段と、
   を更に備え、
   前記フレーム保持手段は、受信フレームのうち、前記レスポンスフレームを保持し、
   前記帯域制御手段は、前記総予測トラフィック量と前記フレーム保持手段の空き容量とを比較した結果に基づいて、前記フレーム保持手段によって保持されるリクエストフレームを送信するタイミングを調整し、前記流量制御を行う、
   請求項１に記載の帯域制御装置。
8. 受信したリクエストフレームに対応するレスポンスフレームのうち、未受信であるレスポンスフレームの総予測トラフィック量を保持する未応答サイズ保持手段と、
   受信したリクエストフレームに対応する前記予測トラフィック量を前記未応答サイズ保持手段に加算する予測トラフィック量加算手段と、
   受信したリクエストフレームに対応する前記予測トラフィック量を、リクエストフレームと該リクエストフレームに対応するレスポンスフレームとの組み合わせであるフロー毎に保持する予測トラフィック量保持手段と、
   前記リクエストフレームに対応するレスポンスフレームを送信する際に、前記予測トラフィック量保持手段によって保持されるフロー毎の前記予測トラフィック量から、送信するレスポンスフレームに対応する予測トラフィック量を取得し、取得した予測トラフィック量を前記未応答サイズ保持手段から減算する予測トラフィック量減算手段と、
   を更に備え、
   前記フレーム保持手段は、受信フレームのうち、前記レスポンスフレームを保持し、
   前記帯域制御手段は、前記総予測トラフィック量と前記フレーム保持手段の空き容量とを比較した結果に基づいて、前記フレーム保持手段によって保持されるリクエストフレームを送信するタイミングを調整し、前記流量制御を行う、
   請求項１に記載の帯域制御装置。
9. 受信フレームのうち、他の処理装置に対するデータ送信要求であるリクエストフレームを保持するフレーム保持ステップと、
   受信フレームのうち、前記データ送信要求を受けて他の処理装置から送信されたデータ
   を含むレスポンスフレームのサイズを計測し、該計測されたサイズに基づいて、前記リクエストフレームに対する応答として受信されると予測されるレスポンスフレームによるトラフィックの量である予測トラフィック量を算出するレスポンス計測ステップと、
   前記レスポンス計測ステップで算出された予測トラフィック量に基づいて、前記フレーム保持ステップで保持されるリクエストフレームを送信するタイミングを調整し、該リクエストフレームの流量制御を行う帯域制御ステップと、
   を備える帯域制御方法。

Images