JP2006311048A - 帯域制御装置 - Google Patents

Abstract

【課題】 処理負荷を増大させることなく所定のトラフィックを検知することが可能であり、該トラヒックを規制することが可能な帯域制御装置を提供する。
【解決手段】 Ｌａｙｅｒ４による規制処理を規制対象のアプリケーションによるトラヒックであると判定された規制対象トラヒックに実施するＬ４処理部と、アプリケーションレイヤーによる規制処理を規制対象トラヒックに実施するアプリケーション処理部と、流入したトラヒックから規制対象トラヒックの可能性が高い規制候補トラヒックを選出し、規制候補トラヒックのデータとシグニチャパターンとを比較することで該規制候補トラヒックが規制対象トラヒックであるか否かを判定し、規制対象トラヒック対する規制処理の実施をＬ４処理部またはアプリケーション処理部の少なくとも一方に指示する規制判定処理部とを有する構成とする。
【選択図】 図３

Description

本発明はネットワークを介して送受信されるトラヒックに対して帯域制御や規制を行うための帯域制御装置に関する。

近年、インターネット等のネットワークを介して様々なサービスが提供されているため、インターネットのトラヒックが増大し続けている。サービスには大量のデータを高速に伝送する形態もあるため、他ユーザの利用帯域を圧迫してしまう問題が生じる。特に、トラヒックの増大を招くネットワークの利用形態としてピアツーピア（Peer-to-Peer、以下Ｐ２Ｐと称す）が知られている。そのため、このＰ２Ｐアプリケーションによるトラヒックを検知し、該トラヒックが専有する伝送帯域を制限する等の規制を行う必要がある。

しかしながら、Ｐ２Ｐアプリケーションでは、ポート番号を動的に選択してデータの送受信に利用するため、Ｐ２Ｐアプリケーションによるトラヒックであることを検知するのが困難な問題がある。そこで、Ｐ２Ｐアプリケーションによるトラヒックを検知するための手法が、例えば非特許文献１で提案されている。

非特許文献１では、Ｐ２Ｐアプリケーションによってランダムに利用されるポート番号を管理するためのポート番号テーブルを用意しておき、該ポート番号テーブル内の情報に基づきＰ２Ｐアプリケーションによるトラヒックであるか否かを判断する技術が開示されている。非特許文献１に記載の技術では、ポート番号テーブルに、Ｐ２Ｐアプリケーション毎にランダムに使用しているポート番号を列挙しておき、キャプチャしたトラヒックのデータがどのポート番号を使用しているかを検索することでＰ２Ｐアプリケーションによるトラヒックであるか否かを判定している。
Myung-Sup Kim, Hun-Jeong Kang, and James W. Hong, "Towards Peer-to-Peer Traffic Analysis Using Flows", Self-Managing Distributed Systems: 14th IFIP/IEEE International Workshop On Distributed Systems: Operations and Management, DSOM 2003.

上述した非特許文献１に記載された技術では、Ｐ２Ｐアプリケーションにしたがって通信装置が所定の範囲内のポート番号をランダムに利用することを前提としている。すなわち、Ｐ２Ｐアプリケーションで利用するポート番号は既知の範囲内であり、利用するポートが数十程度に限られることを前提にポート番号テーブルを作成し、該ポート番号テーブルを用いてＰ２Ｐアプリケーションによるトラヒックであるか否かを判断している。したがって、採りうる全ての範囲内でランダムにポート番号を選択するアプリケーションのトラヒックを検知するために非特許文献１で提案された方法を採用すると、ポート番号テーブルが巨大なものとなるため特定のトラヒックを検知するための処理負荷が増大してしまう。

そのため、ポート番号を手がかりとすることなく、トラヒックデータをそれぞれ解析して規制対象のアプリケーションによるトラヒックであるか否かを判定することが望ましい。規制対象のアプリケーションによるトラヒック、すなわち所定のトラヒックであるか否かを判定するには、一般にトラヒックデータがシグニチャパターン（signature pattern）と一致するか否かを確認すればよい。シグニチャパターンは、例えばトラヒックの特定パケットの所定位置に含まれる既知の固定文字列等のように、トラヒックデータの特徴を示した情報である。

しかしながら、アプリケーションによっては取得したトラヒックデータのままではシグニチャパターンと比較できないものがある。例えば、トラヒックデータがアプリケーションのプロトコルにしたがって暗号化されている場合や正規化処理を必要とする場合、シグニチャパターンと比較するためには、暗号化されたデータを復号する処理や正規化処理が必要になる。

したがって、トラヒックデータを解析して特定のトラヒックを検知する方法でも、各トラヒックデータをシグニチャパターンと比較可能なデータに変換するための処理（以下、このような処理を「前処理」と称す）が必要となるため、処理負荷が増大してしまう問題がある。

なお、ポート番号をランダムに使用するためにトラヒックの検知が困難な問題は、Ｐ２Ｐアプリケーションに限らず、他のアプリケーションにも当てはまる問題である。例えば、マルチメディアサービスのプロトコルとして知られたRealMedia、QuickTime、SIP等もデータ転送時にランダムにポート番号を使用する。

本発明は上記したような従来の技術が有する問題点を解決するためになされたものであり、処理負荷を増大させることなく特定のトラヒックを検知することが可能であり、当該トラヒックを規制することが可能な帯域制御装置を提供することを目的とする。

上記目的を達成するため本発明の帯域制御装置は、ネットワークを介して送受信されるトラヒックに対して帯域制御や規制を行うための帯域制御装置であって、
Ｌａｙｅｒ４による規制処理を、予め決められた規制対象のアプリケーションによるトラヒックであると判定された規制対象トラヒックに実施するＬ４処理部と、
アプリケーションレイヤーによる規制処理を、前記規制対象トラヒックに実施するアプリケーション処理部と、
流入した前記トラヒックから前記規制対象トラヒックの可能性が高い規制候補トラヒックを選出し、前記規制候補トラヒックのデータと前記規制対象トラヒックのデータの特徴を示すシグニチャパターンとを比較することで該規制候補トラヒックが前記規制対象トラヒックであるか否かを判定し、前記規制対象トラヒック対する規制処理の実施を前記Ｌ４処理部または前記アプリケーション処理部の少なくとも一方に指示する規制判定処理部と、
を有する構成である。

上記のように構成された帯域制御装置では、規制判定処理部が、流入したトラヒックから規制対象トラヒックの可能性が高い規制候補トラヒックを選出し、規制候補トラヒックのデータとシグニチャパターンとを比較することで該規制候補トラヒックが規制対象トラヒックであるか否かを判定する。したがって、規制候補トラヒックのデータに対してのみ前処理を実施すれば済む。

本発明によれば、流入したトラヒックから規制対象トラヒックの可能性が高い規制候補トラヒックを選出し、規制候補トラヒックのデータとシグニチャパターンとを比較することで該規制候補トラヒックが規制対象トラヒックであるか否かを判定するため、規制候補トラヒックのデータに対してのみ前処理を実施すれば済む。

したがって、トラヒックのデータに対する前処理が大幅に低減するため、処理負荷を抑制しつつ規制対象のアプリケーションによるトラヒック（規制対象トラヒック）を検知することが可能になる。

よって、採りうる全ての範囲内でランダムにポート番号を選択するアプリケーションのトラヒックであっても、処理負荷を増大させることなく検知することが可能であり、該アプリケーションによるトラヒックを規制することが可能になる。

次に本発明について図面を参照して説明する。

図１は本発明の帯域制御装置を有する通信システムの一構成例を示すブロック図であり、図２は本発明の帯域制御装置を有する通信システムの他の構成例を示すブロック図である。

図１及び図２に示すように、本発明の通信システムは、通信装置５４、帯域制御装置５６及び通信装置５５を有し、通信装置５４、帯域制御装置５６及び通信装置５５が管理系ネットワーク５８を形成する構成である。また、端末装置５１、５２及び５３が通信装置５４、帯域制御装置５６及び通信装置５５を介してインターネット５７に接続される構成、または端末装置５１、５２及び５３がインターネット５７を介して通信装置５４、帯域制御装置５６及び通信装置５５に接続される構成である。

図１に示す通信システムは、端末装置５１、５２及び５３が通信装置５４、帯域制御装置５６及び通信装置５５を介してインターネット５７に接続される構成であり、帯域制御装置５６が規制対象のアプリケーションで動作している端末装置５２のトラヒックのみを規制し、規制対象のアプリケーションで動作していない端末装置５１及び５３のトラヒックをそのまま通過させる様子を示している。図１は、端末装置５１、５２及び５３からインターネット５７へ送信されるトラヒックを規制する構成であり、企業や教育機関等が有するネットワークに本発明の帯域制御装置５６を適用する例である。

図２に示す通信システムは、端末装置５１、５２及び５３がインターネット５７を介して通信装置５４、帯域制御装置５６及び通信装置５５に接続される構成であり、帯域制御装置５６がインターネット５７を介して受信した規制対象のアプリケーションで動作している端末装置５２のトラヒックのみを規制し、規制対象のアプリケーションで動作していない端末装置５１及び５３のトラヒックをそのまま通過させる様子を示している。図２は、インターネット５７を介して端末装置５１〜５３から受信したトラヒックを規制する構成であり、インターネット５７への接続サービスを提供するサービスプロバイダ等のネットワークに本発明の帯域制御装置５６を適用する例である。

なお、通信システムを構成する端末装置５１、５２及び５３並びに通信装置５４及び５５の数は、図１及び図２に示した数に限定されるものではなく、いくつであってもよい。

以下では、通信装置５４、５５や帯域制御装置５６が備える通信用のプロトコルスタック（protocol stack）のうち、Ｌａｙｅｒ２、Ｌａｙｅｒ３、Ｌａｙｅｒ４を、それぞれＬ２、Ｌ３、Ｌ４と略す。各Ｌａｙｅｒの具体的なプロトコルとしては、Ｌａｙｅｒ２にはＥｔｈｅｒｎｅｔ（富士ゼロックス株式会社の登録商標）、Ｌａｙｅｒ３にはＩＰ（Internet Protocol：ＲＦＣ７９１）、Ｌａｙｅｒ４にはＴＣＰ（Transmission Control Protocol：ＲＦＣ７９３）やＵＤＰ（User Datagram Protocol：ＲＦＣ７６８）等がある。

図３は本発明の帯域制御装置の一構成例を示すブロック図である。

図３に示すように、本発明の帯域制御装置５６は、規制判定処理部１００、Ｌ２終端処理部１２０、Ｌ３処理部１３０、Ｌ４処理部１４０及びアプリケーション処理部１５０を有する構成である。

Ｌ２終端処理部１２０は、入力ポート及び出力ポートを少なくとも１組以上を備え、Ｌａｙｅｒ２の終端処理を行う。入力ポートからはトラヒックが流入し、出力ポートからは帯域制御装置５６による規制処理が実施されたトラヒックが送出される。

Ｌ３処理部１３０は、Ｌ３規制処理部１３１及びＬ３終端処理部１３２を備えた構成である。Ｌ３終端処理部は、Ｌ２終端処理部と接続され、Ｌａｙｅｒ３の終端処理を行う。また、Ｌ３規制処理部は、規制判定処理部１００からの指示にしたがって、Ｌａｙｅｒ３による規制処理を各トラヒックに実施する。Ｌａｙｅｒ３での規制処理には、例えば送信元のＩＰアドレス毎にトラヒックを監視し、トラヒックが多いＩＰアドレスからのデータを一定時間だけ強制的に廃棄する方法等がある。

Ｌ４処理部１４０は、Ｌ４規制処理部１４１及びＬ４終端処理部１４２を備えた構成である。Ｌ４終端処理部は、Ｌ３終端処理部と接続され、Ｌａｙｅｒ４の終端処理を行う。また、Ｌ４規制処理部は、規制判定処理部１００からの指示にしたがってＬａｙｅｒ４による規制処理を規制対象トラヒックに実施する。

Ｌａｙｅｒ４による規制処理には、コネクション型プロトコルあるいはコネクションレス型プロトコルに応じて以下に示す方法が考えられる。

例えば、Ｌａｙｅｒ４がコネクション型プロトコル場合は、規制対象のアプリケーションで動作している装置（ＩＰアドレス）とのコネクションを規制する方法、及び規制対象のアプリケーションで動作している全ての装置からのトラヒック(但し、装置に登録されたポート番号を除く)を一括して規制する方法が考えられる。例えばＬａｙｅｒ４のプロトコルがＴＣＰ（ＲＦＣ７９３）の場合、いずれの規制方法においても、Ｌ４規制処理部１４１により、ＲＳＴ（Reset Flag）を発行することでコネクションを強制的に切断したり、所定量の遅延を規制対象トラヒックに付加することで帯域を制限すればよい。いずれの処理も一定時間後に解除する。

一方、Ｌａｙｅｒ４がコネクションレス型プロトコル（ＵＤＰ）の場合は、Ｌ４規制処理部１４１により、規制対象となるトラヒックのデータを一定時間だけ強制的に廃棄する方法がある。

アプリケーション処理部１５０は、アプリケーション規制処理部１５１、通知処理部１５２、統計処理部１５３、シグニチャ比較前処理部１５４及びシグニチャ比較処理部１５５を備えた構成である。

アプリケーション規制処理部１５１は、規制判定処理部１００からの指示にしたがってアプリケーションレイヤーによる規制処理を規制対象トラヒックに実施する。本規制処理はプロトコルが既知であるアプリケーションの場合に実施する。実際にトラヒックを規制する際には、例えば規制対象のアプリケーションのプロトコルにしたがって、アプリケーション規制処理部１５１から規制対象のアプリケーションによるサービスを受けている複数の装置に対してネットワークを介して通信切断を一定時間だけ通知すればよい。

統計処理部１５３は、Ｌ４終端処理部１４２による処理後のトラヒックから該トラヒックに関連する各種統計値を算出する。算出した統計値は通知処理部１５２へ送信する。統計値としては、単位時間当たりのコネクション数、データ転送量、使用ポート数等がある。統計処理部１５３は、これらの統計値のなかから少なくともいずれか一つを算出すればよい。なお、使用ポート数については、同一ポートを使用する場合は加算の対象外とする。

シグニチャ比較前処理部１５４は、規制判定処理部１００からの指示にしたがって、規制判定処理部１００で規制対象トラヒックの可能性が高いと判定された規制候補トラヒックのうち、シグニチャパターンと比較できないトラヒックデータに対して必要な前処理を行う。例えば暗号化されたデータであれば、復号処理を行うことでシグニチャパターンとの比較を可能にする。

シグニチャ比較処理部１５５は、規制判定処理部１００からの指示にしたがって規制候補トラヒックのデータとシグニチャパターンとを比較し、該規制候補トラヒックが規制対象トラヒックであるか否かを判定し、通知処理部１５２に判定結果を送信する。

シグニチャパターンは、上述したようにトラヒックの特定パケットの所定位置に含まれる既知の固定文字列等、規制対象トラヒックのデータの特徴を示すパターンデータである。シグニチャパターンには、設計者や帯域制御装置の管理者等が設定した後述する閾値、あるいは使用ポート数やデータ転送量等の統計情報を付加してもよい。シグニチャパターンは、例えば帯域制御装置５６の起動時に、不揮発性の不図示の記憶装置からシグニチャ比較処理部１５５に読み込まれる。

通知処理部１５２は、統計処理部１５３で求めた統計値、またはシグニチャ比較処理部１５５の判定結果を規制判定部１００で解釈可能なフォーマットに変換し、規制判定処理部１００へ通知する。

規制判定処理部１００は、規制判定部１０１及び規制リスト１０２を備えた構成である。規制判定部１０１は、通知処理部１５２から受け取った情報を基にトラヒックに対する規制処理の要否を判断し、規制が必要な場合は規制リスト１０２内の情報にしたがってＬ４規制処理部１４１またはアプリケーション規制処理部１５１の少なくとも一方に規制処理の実施を指示する。なお、規制判定部１０１は、Ｌ３規制処理部１３１に対しても必要に応じて規制処理の実施を指示する。規制リスト１０２には、規制対象トラヒックに対して実施する規制処理の内容（規制指示）及び規制処理で用いる各種情報が格納される。

また、規制判定部１０１は、通知処理部１５２から受け取った情報から送信元のＩＰアドレス毎にトラヒックの統計値をそれぞれ抽出し、抽出した統計値と規制リスト１０２に格納された所定の閾値とを比較する。そして、統計値が閾値を越えている場合は対応するトラヒックが規制対象トラヒックの可能性が高い規制候補トラヒックであると判定し、シグニチャ比較前処理部１５４へ指示して該規制候補トラヒックのデータへの前処理を実行させる。

本発明では規制判定部１０１で用いる閾値を処理負荷に応じて変更可能にする。その場合、規制判定部１０１は、帯域制御装置の処理負荷を定期的に監視し、処理負荷に応じて閾値を変更する。例えば負荷が高いときは閾値を上げて前処理を行うトラヒックを減らし、負荷が低いときは閾値を下げて前処理を行うトラヒックを増やせばよい。

処理負荷の監視対象は帯域制御装置５６に限る必要はなく、例えば管理系ネットワーク５８に接続された他の通信装置から定期的に負荷情報を送信させ、該負荷情報に応じて閾値を変更してもよい。図１に示した構成では、例えばＳＮＭＰ（Simple Network Management Protocol）を利用して通信装置５４及び通信装置５５からそれぞれの負荷情報を取得し、取得した負荷情報を基に閾値を変更する。

なお、本発明の帯域制御装置５６は、図３に示した各構成要素の機能を実現するＬＳＩや論理回路等によって構成してもよく、ネットワークとの通信機能を備えた情報処理装置（コンピュータ）によって実現してもよい。その場合、情報処理装置は、ＣＰＵを含む処理装置と、ＣＰＵの処理で必要な情報を記憶する記憶装置と、ＣＰＵに本発明の帯域制御装置５６の処理を実行させるためのプログラムが記録された記録媒体とを備え、処理装置は、記録媒体に格納されたプログラムを読み込み、ＣＰＵにより該プログラムにしたがって処理することで図３に示した各構成要素の機能をそれぞれ実現する。図１及び図２に示した通信装置５４及び５５並びに端末装置５１，５２及び５３も、帯域制御装置５６と同様にネットワークとの通信機能を備えた情報処理装置（コンピュータ）によって実現可能である。

次に、本発明の帯域制御装置５６の動作について図４を用いて説明する。

図４は本発明の帯域制御装置の処理手順を示すフローチャートである。

図４に示すように、本発明の帯域制御装置５６は、ネットワークからトラヒックが流入すると、まずＬ２終端処理部１２０によりＬ２終端処理を実施する（ステップＳ１）。続いて、Ｌ３終端処理部１３２によりＬ３終端処理を実施し（ステップＳ２）、Ｌ４終端処理部１４２によりＬ４終端処理を実施する（ステップＳ３）。

次に、帯域制御装置５６は、統計処理部１５３を用いてＬ４終端処理後のデータからトラヒックに関連する各種統計値を算出し（統計算出処理）、算出結果を通知処理部１５２へ送信する（ステップＳ４）。通知処理部１５２は、受け取った統計値を規制判定部１００で解釈可能なフォーマットに変換し、規制判定部１０１へ通知する（ステップＳ５）。

規制判定部１０１は、通知処理部１５２から受け取った通知から統計値を読み取り、該統計値が規制リスト１０２に格納された所定の閾値を越えているか否かを判定する（ステップＳ６）。閾値を越えていない場合は対応するトラヒックをそのまま通過させる（ステップＳ６−２）。また、統計値が閾値を越えている場合は、対応するトラヒックを規制候補トラヒックとして選出し、シグニチャ比較前処理部１５４を用いて該規制候補トラヒックのデータに対してシグニチャパターンとの比較に必要な前処理を実施する（ステップＳ６−１）。このステップＳ６−１、Ｓ６−２の処理はステップＳ５の処理が終了後に即時に実施する。

次に、帯域制御装置５６は、シグニチャ比較処理部１５５を用いて規制候補トラヒックのデータとシグニチャパターンとの比較処理を実施する（ステップＳ７）。そして、その比較結果により規制候補トラヒックが規制対象トラヒックであるか否かを判定し（ステップＳ８）、判定結果を通知処理部１５２を介して規制判定部１０１へ通知する。

規制判定部１０１は、規制候補トラヒックが規制対象トラヒックではない場合は対応するトラヒックをそのまま通過させる（ステップＳ６−２）。また、規制候補トラヒックが規制対象トラヒックである場合は、規制リスト１０２に格納された情報を読み出し、対応するトラヒックに対してＬａｙｅｒ４で規制処理（Ｌ４規制）を実施するかアプリケーションレイヤーで規制処理（アプリケーション規制）を実施するかを判定する（ステップＳ９）。規制リスト１０２にＬ４規制の指示が格納されている場合は、Ｌ４処理部１４０によりＬａｙｅｒ４での規制処理を実施する（ステップＳ９−１）。また、規制リスト１０２にアプリケーション規制の指示が格納されている場合は、アプリケーション規制処理部１５１によりアプリケーションレイヤーでの規制処理を実施する（ステップＳ９−２）。

上記説明では、各トラヒックの統計値が予め設定された閾値を越えたときに対応するトラヒックデータに対する前処理及びシグニチャパターンとの比較処理を実施する例を示しているが、上述したように本発明の帯域制御装置５６は帯域制御装置５６や通信装置５４、５５の処理負荷に応じて閾値を変更することも可能である。以下に処理負荷に応じて閾値を変更する場合の処理手順について図面を用いて説明する。

図５は本発明の帯域制御装置で実施する第１の閾値設定方法の処理手順を示すフローチャートである。図５は帯域制御装置５６の負荷情報を収集して閾値に実施させる処理フローを示したものである。なお、以下に記載する第１の閾値設定方法の処理は規制判定処理部１００の規制判定部１０１にて所定の周期毎に実行し、図４に示した処理とは非同期に実行するものとする。

図５に示すように、規制判定部１０１は、まず帯域制御装置５６の負荷情報を取得し（ステップＳ３１）、処理負荷の統計値を算出する（ステップＳ３２）。算出する統計値としては、例えばシグニチャ比較前処理部１５４による前処理の計算時間がある。また、帯域制御装置５６を情報処理装置で実現している場合はＣＰＵの使用率やメモリの使用量等がある。以下では、ＣＰＵの使用率を例に図６を用いて第１の閾値設定方法を説明する。図６は図５に示した第１の閾値設定方法で用いる統計値と閾値の関係を示すグラフである。図６に示すグラフの縦軸は閾値を示し、横軸は帯域制御装置５６が有するＣＰＵの使用率を示している。

規制判定部１０１は、設計者や帯域制御装置の管理者等によって設定された方針にしたがって図６に示すグラフの特性５００、５０１、５０２のいずれかを用いてＣＰＵの使用率から閾値を求める。図６に示す特性５００、５０１、５０２は、例えば規制リスト１０２に予め格納しておくものとする。

図６に示す特性５００はＣＰＵの使用率の増加に比例して閾値を増加させる例である。例えばＣＰＵの使用率が上昇しても可能な限り前処理を実施する設計方針である場合は、ＣＰＵの使用率が増加しても閾値の増加が抑制される特性５０２を選択する。また、突発的に大量のトラヒックが流入しても安定した運用を重視する場合は、ＣＰＵの使用率の増加に伴って閾値をより増加させる特性５０１を選択する。

このような特性を用いて規制判定部１０１は統計値に対応する閾値を決定する（ステップＳ３３）。そして、統計値（ここではＣＰＵの使用率）の変動により前回の処理周期で設定した閾値から変更が必要か否かを判定し（ステップＳ３４）、閾値の変更が必要な場合は規制リスト１０２内の閾値をステップＳ３３の処理で求めた閾値に再設定し（ステップＳ３５）、ステップＳ３１の処理に戻ってステップＳ３４までの処理を繰り返す。閾値の変更が不要な場合は、規制リスト１０２内の閾値の再設定を行わずにステップＳ３１の処理に戻ってステップＳ３４までの処理を繰り返す。

図７は本発明の帯域制御装置で実施する第２の閾値設定方法の処理手順を示すフローチャートである。図７は図１に示した管理系ネットワークに接続された通信装置の負荷情報を収集して閾値に実施させる処理フローを示したものである。なお、以下に記載する第２の閾値設定方法も第１の閾値設定方法の処理と同様に規制判定処理部１００の規制判定部１０１にて所定の周期毎に実行し、図４に示した処理とは非同期に実行するものとする。

図７に示すように、規制判定部１０１は、まず負荷情報の収集対象となる装置(本帯域制御装置含む)のうち、任意の装置の負荷情報を取得し（ステップＳ５１）、該装置の処理負荷の統計値を算出する（ステップＳ５２）。算出する統計値としては、第１の閾値設定方法と同様に、ＣＰＵの使用率やメモリの使用量等がある。以下では、負荷情報の収集対象となる装置が有するＣＰＵの使用率を例に図８を用いて第２の閾値設定方法を説明する。図８は図７に示した第２の閾値設定方法で用いる統計値と閾値の関係を示すグラフである。図８に示すグラフの縦軸は閾値を示し、横軸は負荷情報の収集対象となる装置が有するＣＰＵの使用率を示している。

規制判定部１０１は、負荷情報の収集対象となる装置（以下、対象装置と称す）の負荷情報の取得が終了しているか否かを確認し（ステップＳ５３）、負荷情報を全て取得していない場合はステップＳ５１の処理に戻って対象装置の残りの負荷情報を取得する。取得した負荷情報を基に、例えば帯域制御装置５６の後段に接続された通信装置の負荷が高いことが判明した場合、閾値を下げてより多くのトラヒックデータに対して前処理を実施し、トラヒックデータの内容を検査して規制処理を実施する必要がある。

そのため、規制判定部１０１は、図６のグラフに示した特性５０１、５０２、５０３の傾きを修正して図８のグラフに示す特性５１０、５１１、５１２を設定する。そして、対象装置の処理負荷の取得が完了した場合は、第１の設定方法と同様に設計者や帯域制御装置の管理者等によって設定された方針にしたがって図８に示すグラフの特性５１０、５１１、５１２のいずれかを用いてＣＰＵの使用率から閾値を決定する（ステップＳ５４）。なお、図８に示す特性５１０、５１１、５１２は、例えば規制リスト１０２に格納するものとする。

そして、統計値（ここではＣＰＵの使用率）の変動により前回の処理周期で設定した閾値から変更が必要か否かを判定し（ステップＳ５５）、閾値の変更が必要な場合は規制リスト１０２内の閾値をステップＳ５４の処理で求めた閾値に再設定し（ステップＳ５６）、ステップＳ５１の処理に戻ってステップＳ５５までの処理を繰り返す。また、閾値の変更が不要な場合は、規制リスト１０２内の閾値の再設定を行わずにステップＳ５１の処理に戻ってステップＳ５５までの処理を繰り返す。

以上説明したように本発明によれば、流入したトラヒックから規制対象トラヒックの可能性が高い規制候補トラヒックを選出し、規制候補トラヒックのデータとシグニチャパターンとを比較することで該規制候補トラヒックが規制対象トラヒックであるか否かを判定するため、規制候補トラヒックのデータに対してのみ前処理を実施すれば済む。

したがって、トラヒックのデータに対する前処理が大幅に低減するため、処理負荷を抑制しつつ規制対象のアプリケーションによるトラヒック（規制対象トラヒック）を検知することが可能になる。

よって、採りうる全ての範囲内でランダムにポート番号を選択するアプリケーションのトラヒックであっても、処理負荷を増大させることなく検知することが可能であり、該アプリケーションによるトラヒックを規制することが可能になる。

本発明の帯域制御装置を有する通信システムの一構成例を示すブロック図である。 本発明の帯域制御装置を有する通信システムの他の構成例を示すブロック図である。 本発明の帯域制御装置の一構成例を示すブロック図である。 本発明の帯域制御装置の処理手順を示すフローチャートである。 本発明の帯域制御装置で実施する第１の閾値設定方法の処理手順を示すフローチャートである。 図５に示した第１の閾値設定方法で用いる統計値と閾値の関係を示すグラフである。 本発明の帯域制御装置で実施する第２の閾値設定方法の処理手順を示すフローチャートである。 図７に示した第２の閾値設定方法で用いる統計値と閾値の関係を示すグラフである。

符号の説明

５１，５２，５３ 端末装置
５４，５５ 通信装置
５６ 帯域制御装置
５７ インターネット
５８ 管理系ネットワーク
１００ 規制判定処理部
１０１ 規制判定部
１０２ 規制リスト
１２０ Ｌ２終端処理部
１３０ Ｌ３処理部
１３１ Ｌ３規制処理部
１３２ Ｌ３終端処理部
１４０ Ｌ４処理部
１４１ Ｌ４規制処理部
１４２ Ｌ４終端処理部
１５０ アプリケーション処理部
１５１ アプリケーション規制処理部
１５２ 通知処理部
１５３ 統計処理部１５３
１５４ シグニチャ比較前処理部
１５５ シグニチャ比較処理部

Claims (10)

1. ネットワークを介して送受信されるトラヒックに対して帯域制御や規制を行うための帯域制御装置であって、
   Ｌａｙｅｒ４による規制処理を、予め決められた規制対象のアプリケーションによるトラヒックであると判定された規制対象トラヒックに実施するＬ４処理部と、
   アプリケーションレイヤーによる規制処理を、前記規制対象トラヒックに実施するアプリケーション処理部と、
   流入した前記トラヒックから前記規制対象トラヒックの可能性が高い規制候補トラヒックを選出し、前記規制候補トラヒックのデータと前記規制対象トラヒックのデータの特徴を示すシグニチャパターンとを比較することで該規制候補トラヒックが前記規制対象トラヒックであるか否かを判定し、前記規制対象トラヒック対する規制処理の実施を前記Ｌ４処理部または前記アプリケーション処理部の少なくとも一方に指示する規制判定処理部と、
   を有する帯域制御装置。
2. 前記アプリケーション処理部は、
   前記トラヒックに関連する統計値をそれぞれ算出し、
   前記規制判定処理部は、
   前記統計値が所定の閾値を越えたとき、対応するトラヒックを前記規制候補トラヒックとして選出する請求項１記載の帯域制御装置。
3. 前記規制判定処理部は、
   前記シグニチャパターンとの比較に必要な、前記規制候補トラヒックのデータに対する前処理を前記アプリケーション処理部へ指示し、
   前記アプリケーション処理部は、
   前記規制判定処理部からの指示にしたがって、前記規制候補トラヒックのデータに前記前処理を実施する請求項１または２記載の帯域制御装置。
4. 前記統計値に、
   単位時間当たりのコネクション数、データ転送量、または使用ポート数の少なくともいずれか一つを含む請求項１から３のいずれか１項記載の帯域制御装置。
5. 前記規制判定処理部は、
   前記閾値を、処理負荷に応じて変更する請求項１から４のいずれか１項記載の帯域制御装置。
6. 前記規制判定処理部は、
   前記閾値を、前記ネットワークを介して接続される通信装置の処理負荷に応じて変更する請求項１から４のいずれか１項記載の帯域制御装置。
7. 前記Ｌ４処理部は、
   前記Ｌａｙｅｒ４がコネクション型プロトコルの場合、前記規制対象トラヒックに設定されたコネクションを一定時間だけ切断することで規制処理を実施する請求項１から６のいずれか１項記載の帯域制御装置。
8. 前記Ｌ４処理部は、
   前記Ｌａｙｅｒ４がコネクション型プロトコルの場合、前記規制対象トラヒックに所定量の遅延を付加することで規制処理を実施する請求項１から６のいずれか１項記載の帯域制御装置。
9. 前記Ｌ４処理部は、
   前記Ｌａｙｅｒ４がコネクションレス型プロトコルの場合、前記規制対象トラヒックのデータを一定時間だけ廃棄することで規制処理を実施する請求項１から８のいずれか１項記載の帯域制御装置。
10. 前記アプリケーション処理部は、
    前記規制対象のアプリケーションのプロトコルにしたがって、該アプリケーションによるサービスを受けている装置に対して前記ネットワークを介して通信切断を一定時間だけ通知する請求項１から９のいずれか１項記載の帯域制御装置。

Images