(57)【要約】【課題】  高速な通信回線上を流れるＩＰトラフィックを解析し、ＲＴＰパケットの推定および抽出をオンラインで実現できるトラフィック解析装置を提供することを課題とする。【解決手段】  トラフィック制御装置１Ａは、ＩＰパケットを受信するＩＰトラフィック受信手段１１と、ＩＰパケットのヘッダおよびペイロードを解析するパケットヘッダ・ペイロード解析手段１２と、解析を行うトラフィックのフローの情報を格納するフロー解析エントリテーブル１３と、を備え、パケットヘッダ・ペイロード解析手段１２が、フロー解析エントリテーブル１３上の受信したＩＰパケットのエントリを更新する処理と、フロー解析エントリテーブル１３に前記受信したＩＰパケットのエントリを登録する処理と、を行う構成とした。【選択図】      図１
2006246116.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰパケットを受信するＩＰトラフィック受信手段と、
ＩＰパケットのヘッダおよびペイロードを解析するパケットヘッダ・ペイロード解析手段と、
解析を行うトラフィックのフローの情報を格納するフロー解析エントリテーブルと、
を備えたトラフィック解析装置であって、
前記パケットヘッダ・ペイロード解析手段は、
受信したＩＰパケットのエントリが前記フロー解析エントリテーブルに存在する場合に、当該受信したＩＰパケットのエントリを参照して、前記受信したＩＰパケットがＲＴＰフローの特徴をもつかを判定し、
前記受信したＩＰパケットがＲＴＰフローの特徴をもつと判定された場合に、前記フロー解析エントリテーブル上の受信したＩＰパケットのエントリを更新する処理と、
前記受信したＩＰパケットのエントリが前記フロー解析エントリテーブルに存在しない場合であり、前記受信したＩＰパケットがＲＴＰパケットの特徴をもつ場合に、前記フロー解析エントリテーブルに前記受信したＩＰパケットのエントリを登録する処理と、を行うこと
を特徴とするトラフィック解析装置。
【請求項２】
前記トラフィック解析装置は、
更新された前記フロー解析エントリテーブル上のエントリのフローがリアルタイムなトラフィックであることを推定するＲＴＰトラフィック解析・推定手段をさらに備え、
前記パケットヘッダ・ペイロード解析手段は、
前記受信したＩＰパケットがＲＴＰフローの特徴をもつと判定された場合に、前記フロー解析エントリテーブル上の前記受信したＩＰパケットのエントリ内にあるＲＴＰフローであるかを評価する評価カウンタを増加させる処理を行い、
前記ＲＴＰトラフィック解析・推定手段は、
前記評価カウンタの増加率が所定の値に達しなかった場合に、前記フロー解析エントリテーブル上の前記受信したＩＰパケットのエントリを削除する処理を行うこと
を特徴とする請求項１に記載のトラフィック解析装置。
【請求項３】
請求項２に記載のトラフィック解析装置は、
前記パケットヘッダ・ペイロード解析手段または前記ＲＴＰトラフィック解析・推定手段で得られた解析結果を、他のネットワーク装置に通知する解析結果通知手段
をさらに備えることを特徴とするトラフィック解析装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信回線上を流れるＩＰトラフィックのフローをオンラインで解析し、ＲＴＰによるトラフィックのフローを抽出するトラフィック解析装置に関する。
【背景技術】
【０００２】
近年、インターネットの普及によりＶｏＩＰ（Voice over Internet Protocol）技術を用いたＩＰ電話や映像ストリーミング技術を用いたテレビ会議システムなどの通信サービスが広く利用されている。このような通信サービスは、ＩＰパケットによりリアルタイムデータを伝送するが、その通信プロトコルにはＲＴＰ（Real-time Transport Protocol）が用いられている（例えば、非特許文献１参照）。このようなリアルタイム系の通信サービスのトラフィックは、データ転送系通信サービスのトラフィックに比べ、パケット損失率、遅延、ゆらぎなどの通信品質に対する要求がきびしい。
このため、これらの通信サービスを同一のＩＰネットワーク上で利用する場合、リアルタイム系通信サービスのＩＰトラフィックとデータ転送系通信サービスのＩＰトラフィックとは異なるトラフィックとして扱われる必要がある。
【０００３】
従来、通信サービスのトラフィックをパケットレベルで監視するトラフィック監視装置として、ＩＰ、ＵＤＰ／ＴＣＰ、ＨＴＴＰ／ＦＴＰ／ＳＭＴＰなどのプロトコルレベルの統計情報を、一定時間毎に収集するものが実現されている。この際、ＨＴＴＰ／ＦＴＰ／ＳＭＴＰなどのアプリケーションの識別は、ＵＤＰ／ＴＣＰのポート番号の情報に基づいて行う（例えば、非特許文献２参照）。
【０００４】
また、ＲＴＰで用いるＩＰパケット（ＲＴＰパケット）を解析するためのコンピュータ用ソフトウェアとして、ＲＴＰパケットを一旦ファイルに蓄積してから、それらのパケットのヘッダを解析するものが実現されている（ソフトウェア名：Ethereal（登録商標）、またはSniffer Voice（登録商標））。
【０００５】
【非特許文献１】ＭＣＲ（Multimedia Communication Research）編，「要点チェック式H.323/MPEG-4教科書」，第1版，ＩＥインスティテュート，２００３年２月１日，ｐ．１３８−１４３
【非特許文献２】Ｗ・リチャード・スティーヴンス著，「詳解ＴＣＰ／ＩＰ  Ｖｏｌ．１」，新装版，株式会社ピアソン・エデュケーション，２０００年１２月２０日，Ｐ．１３
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、前記のトラフィック監視装置は、ＴＣＰ／ＵＤＰのポート番号に基づいたアプリケーションの識別を行っており、ＵＤＰ上位プロトコルであるＲＴＰの解析を行わないため、リアルタイム系通信サービス（ＩＰ電話、テレビ会議システム等）の識別や監視には適用することができないという問題がある。
【０００７】
また、前記のＲＴＰパケット解析用ソフトウェアは、ＲＴＰおよびＲＴＣＰの解析をオフライン（非リアルタイム）で行うことを前提としているため、リアルタイム系通信サービスの通信品質の監視や優先度制御など、解析結果をオンタイムで利用したい場合には適用することができない。また、収集したトラフィックを一旦ファイルに蓄積してから解析するため、高速な回線上でトラフィックを解析する場合には、短期間のデータを収集する際にも大容量の記憶装置が必要となり、設備コストが大きく、実現が困難であるという問題がある。
【０００８】
そこで本発明は、以上のような問題点に鑑みてなされたものであり、高速な通信回線上を流れるＩＰトラフィックを解析し、ＲＴＰパケットの推定および抽出をオンラインで実現できるトラフィック解析装置を提供することを課題とする。
【課題を解決するための手段】
【０００９】
本発明は、前記課題を解決するために創案されたものであり、まず、請求項１に記載のトラフィック制御装置は、ＩＰパケットを受信するＩＰトラフィック受信手段と、ＩＰパケットのヘッダおよびペイロードを解析するパケットヘッダ・ペイロード解析手段と、解析を行うトラフィックのフローの情報を格納するフロー解析エントリテーブルと、を備えたトラフィック解析装置であって、前記パケットヘッダ・ペイロード解析手段が、受信したＩＰパケットのエントリが前記フロー解析エントリテーブルに存在する場合に、当該受信したＩＰパケットのエントリを参照して、前記受信したＩＰパケットがＲＴＰフローの特徴をもつかを判定し、前記受信したＩＰパケットがＲＴＰフローの特徴をもつと判定された場合に、前記フロー解析エントリテーブル上の受信したＩＰパケットのエントリを更新する処理と、前記受信したＩＰパケットのエントリが前記フロー解析エントリテーブルに存在しない場合であり、前記受信したＩＰパケットがＲＴＰパケットの特徴をもつ場合に、前記フロー解析エントリテーブルに前記受信したＩＰパケットのエントリを登録する処理と、を行う構成とした。
【００１０】
かかる構成によれば、トラフィック制御装置は、受信したＩＰパケットをフロー解析エントリテーブルに登録し、登録したエントリをリアルタイムに更新することが可能となるので、エントリを参照することで、受信パケットがＲＴＰフローの特徴をもつかを判定することが可能である。
【００１１】
さらに、請求項２に記載のトラフィック制御装置は、請求項１に記載のトラフィック制御装置において、更新された前記フロー解析エントリテーブル上のエントリのフローがリアルタイムなトラフィックであることを推定するＲＴＰトラフィック解析・推定手段をさらに備え、前記パケットヘッダ・ペイロード解析手段が、前記受信したＩＰパケットがＲＴＰフローの特徴をもつと判定された場合に、前記フロー解析エントリテーブル上の前記受信したＩＰパケットのエントリ内にあるＲＴＰフローであるかを評価する評価カウンタを増加させる処理を行い、前記ＲＴＰトラフィック解析・推定手段が、前記評価カウンタの増加率が所定の値に達しなかった場合に、前記フロー解析エントリテーブル上の前記受信したＩＰパケットのエントリを削除する処理を行う構成とした。
【００１２】
かかる構成によれば、トラフィック制御装置は、フロー解析エントリテーブルのエントリの評価カウンタにＲＴＰフローであるかを評価する値を設定でき、それを参照することで、受信パケットがＲＴＰフローであることを推定することが可能である。また、評価カウンタの増加率が低いエントリをフロー解析エントリテーブルから削除することによって、フロー解析エントリテーブルの資源を有効に使用することが可能である。
【００１３】
また、請求項３に記載のトラフィック制御装置は、請求項２に記載のトラフィック制御装置において、前記パケットヘッダ・ペイロード解析手段または前記ＲＴＰトラフィック解析・推定手段で得られた解析結果を、他のネットワーク装置に通知する解析結果通知手段をさらに備える構成とした。
【００１４】
かかる構成によれば、他のネットワーク装置は、トラフィック制御装置が解析した結果を通知されるので、通知された解析結果に基づいて、リアルタイムにトラフィックの制御を行うことが可能である。
【発明の効果】
【００１５】
本発明によれば、高速な通信回線上を流れるＩＰトラフィックを解析し、ＲＴＰパケットの推定および抽出をオンラインで実現することが可能となる。
【発明を実施するための最良の形態】
【００１６】
次に、本発明を実施するための最良の形態（以下、「実施形態」という）について図面を参照して説明する。
［第１実施形態］
図１は、本発明の第１実施形態に係るトラフィック解析装置のブロック図である。図１に示すように、トラフィック解析装置１Ａは、ＩＰトラフィック受信手段１１と、パケットヘッダ・ペイロード解析手段１２と、フロー解析エントリテーブル１３と、ＲＴＰトラフィック解析・推定手段１４とを備えている。以下、各構成について詳細に説明する。
【００１７】
まず、図２を参照して、フロー解析エントリテーブル１３について説明する。図２は第１実施形態に係るフロー解析エントリテーブルのデータ構造を示す図である。
図２に示すように、フロー解析エントリテーブル１３は、エントリ毎にエントリキー１３ａ、旧シーケンス番号１３ｂ、旧タイムスタンプ値１３ｃ、旧タイムスタンプ値の増加幅１３ｄ、および評価カウンタ１３ｅを持つ。旧タイムスタンプ値の増加幅１３ｄには、エントリ作成後にキーに一致するパケットが得られた際に、そのパケットのタイムスタンプ値２３ｈ（図３参照）からエントリの旧タイムスタンプ値１３ｃを引いた値が保持される。また、評価カウンタ１３ｅには、エントリされたフローがリアルタイムなトラフィックであるかどうかを判別するための評価値が保持される。
【００１８】
図１に戻って、トラフィック解析装置１Ａの各構成について説明を続ける。
ＩＰトラフィック受信手段１１は、通信回線上のＩＰパケットを受信し、パケットヘッダ・ペイロード解析手段１２に渡す機能を有する。
【００１９】
パケットヘッダ・ペイロード解析手段１２は、次の（１）〜（６）に示す項目をキーとしてフロー解析エントリテーブル１３を検索する。
（１）送信元ＩＰアドレス
（２）宛先ＩＰアドレス
（３）送信元ポート番号
（４）宛先ポート番号
（５）Payload Type（ＰＴ）フィールドの値
（６）Synchronization Source identifier（ＳＳＲＣ識別子）フィールドの値
また、パケットヘッダ・ペイロード解析手段１２は、検索の結果、受信したＩＰパケットに関する情報（以下、「エントリ」という）が登録されていない場合には、エントリを登録する処理を行う機能を有する。また、エントリが登録されている場合には、エントリを更新する処理を行う機能を有する。以下、それぞれの処理について詳細に説明する。
【００２０】
図３を参照（適宜図１または図２参照）して、エントリを登録する処理について説明する。図３は第１実施形態に係るＲＴＰパケットのデータ構造を示す図である。
パケットヘッダ・ペイロード解析手段１２は、受信したＩＰパケットが図３に示すようなＲＴＰパケット２であると仮定し、以下の条件（ａ−１）〜（ａ−３）を満たすかを判定する。
（ａ−１）ＩＰヘッダ２１に含まれるプロトコルＩＤが１７である。
（ａ−２）ＵＤＰヘッダ２２内の宛先ポート番号が偶数で、かつ１０２４以上である。
（ａ−３）仮定したＲＴＰヘッダ２３のＶｅｒｓｉｏｎ（Ｖ）が２である。
ここで、プロトコルＩＤが１７のときは、受信パケットがＵＤＰ（User Datagram Protocol）であることを表す。また、ＲＴＰのポート番号は偶数であり、それに続いた奇数の番号がＲＴＣＰのポート番号である。受信したＩＰパケットは、前記（ａ−１）〜（ａ−３）を満たす場合、ＲＴＰパケット２の可能性があると判定される。
【００２１】
パケットヘッダ・ペイロード解析手段１２は、ＲＴＰパケットの可能性があると判定されたＩＰパケットに関する情報を、前記キー項目をエントリキーとしてフロー解析エントリテーブル１３に登録する。
このとき、受信パケットのシーケンス番号２３ｇおよびタイムスタンプ値２３ｈをそれぞれ旧シーケンス番号１３ｂおよび旧タイムスタンプ値１３ｃとして登録する。
【００２２】
図３を参照（適宜図１または図２参照）して、エントリを更新する処理について説明する。
パケットヘッダ・ペイロード解析手段１２は、受信したＩＰパケットからシーケンス番号２３ｇおよびタイムスタンプ値２３ｈを取得し、以下の条件（ｂ−１）〜（ｂ−２）を満たすかを判定する。
（ｂ−１）受信したＩＰパケットのシーケンス番号２３ｇが、エントリの旧シーケンス番号１３ｂから１だけ増加している。
（ｂ−２）｜新タイムスタンプ値の増加幅−旧タイムスタンプ値の増加幅１３ｄ｜＜αを満たす。
ここで、新タイムスタンプ値の増加幅とは、受信したＩＰパケットのタイムスタンプ値２３ｈからエントリの旧タイムスタンプ値１３ｃを減算した値を意味する。αは許容ゆらぎ幅を意味する。
受信したＩＰパケットは、前記（ｂ−１）〜（ｂ−２）を満たす場合、ＲＴＰフローの特徴をもつと判定される。ただし、旧タイムスタンプ値の増加幅１３ｄに値が設定されていない場合には、前記（ｂ−２）の条件を満たすかどうかの判定を行わない。
【００２３】
受信したＩＰパケットがＲＴＰフローの特徴をもたないと判定された場合、パケットヘッダ・ペイロード解析処理手段１２は、エントリの更新は行わない。
【００２４】
また、受信したＩＰパケットがＲＴＰフローの特徴をもつと判定された場合、パケットヘッダ・ペイロード解析処理手段１２は、フロー解析エントリテーブル１３のエントリの、受信パケットのシーケンス番号２３ｇ、タイムスタンプ値２３ｈおよび前記（ｂ−２）で算出した新タイムスタンプ値の増加幅を用いて、エントリテーブルの旧シーケンス番号１３ｂ、旧タイムスタンプ値１３ｃおよび旧タイムスタンプ値の増加幅１３ｄをそれぞれ更新する。
【００２５】
図４を参照（適宜図１、図２、および図３参照）して、受信したＩＰパケットがＲＴＰフローの特徴をもつかどうかを判定する処理について、具体例を用いて詳細に説明する。図４は、第１実施形態に係るフロー解析エントリテーブルの更新パターンを示す図である。
図４では、同一エントリのＲＴＰパケットが順次到着する場合を想定する。また、許容ゆらぎ幅αの値を８００に設定したとする。まず、シーケンス番号２３ｇがＸ＋０、タイムスタンプ値２３ｈが３０００であるＲＴＰパケット１がトラフィック解析装置１Ａに到着する。それぞれの値が旧シーケンス番号１３ｂおよび旧タイムスタンプ値１３ｃに登録される。
【００２６】
続いて、シーケンス番号２３ｇがＸ＋１、タイムスタンプ値２３ｈが６１００であるＲＴＰ１と同一エントリのＲＴＰパケット２がトラフィック解析装置１Ａに到着する。シーケンス番号２３ｇがＸ＋１であり、旧シーケンス番号１３ｂがＸ＋０であるので、前記（ｂ−１）の条件を満たす。また、旧タイムスタンプ値の増加幅１３ｄには値が設定されていないので、前記（ｂ−２）の条件を満たすかどうかの判定は行わないが、受信したＩＰパケットのタイムスタンプ値２３ｈが６１００であり、フロー解析エントリテーブル１３上のエントリの旧タイムスタンプ値１３ｃが３０００であるので、新タイムスタンプ値の増加幅は３１００（６１００−３０００）となり、その値を旧タイムスタンプ値の増加幅１３ｄに登録する。ＲＴＰパケット２のシーケンス番号２３ｇはＸ＋１、タイムスタンプ値２３ｈは６１００であるので、それぞれの値を用いて、旧シーケンス番号１３ｂおよび旧タイムスタンプ値１３ｃを更新する。
【００２７】
続いて、シーケンス番号２３ｇがＸ＋２、タイムスタンプ値２３ｈが８９００であるＲＴＰ１と同一エントリのＲＴＰパケット３がトラフィック解析装置１Ａに到着する。シーケンス番号２３ｇがＸ＋２であり、旧シーケンス番号１３ｂがＸ＋１であるので、前記（ｂ−１）の条件を満たす。また、旧タイムスタンプ値の増加幅１３ｄには３１００が設定されており、新タイムスタンプ値の増加幅は、受信したＩＰパケットのタイムスタンプ値２３ｈである８９００からエントリの旧タイムスタンプ値１３ｃである６１００を減算した２８００となる。したがって、｜２８００−３１００｜＝３００となり、αの値８００より小さいので、前記（ｂ−２）の条件を満たす。新タイムスタンプ値の増加幅は２８００となり、その値を用いて旧タイムスタンプ値の増加幅１３ｄを更新する。ＲＴＰパケット３のシーケンス番号２３ｇはＸ＋２、タイムスタンプ値２３ｈは８９００であるので、それぞれの値を用いて、旧シーケンス番号１３ｂおよび旧タイムスタンプ値１３ｃを更新する。
【００２８】
以下、ＲＴＰパケット３、ＲＴＰパケット４を受信したときも同様に、受信したＩＰパケットがＲＴＰフローの特徴をもつかどうかを判定する。
【００２９】
図３に戻って、エントリを更新する処理の続きを説明する。受信したＩＰパケットがＲＴＰフローの特徴をもつと判定された場合、パケットヘッダ・ペイロード解析手段１２は、受信したＩＰパケットの評価値をカウントし、エントリの評価カウンタ１３ｆを加算する。エントリの評価カウンタ１３ｆに加算する評価値としては、以下に示す（ｃ−１）〜（ｃ−４）などが考えられる。
（ｃ−１）エントリに一致するパケットが受信された回数。
（ｃ−２）前記シーケンス番号の条件（ｂ−１）を満たした回数。
（ｃ−３）前記タイムスタンプ値の増加幅の条件（ｂ−２）を満たした回数。
（ｃ−４）前記シーケンス番号の条件（ｂ−１）およびタイムスタンプ値の条件（ｂ−２）を満たした回数。
【００３０】
ＲＴＰトラフィック解析・推定手段１４は、フロー解析エントリテーブル１３のエントリの評価カウンタが更新されると、エントリがＲＴＰフローであるかを判定する。以下、エントリがＲＴＰフローであるかを判定する処理について詳細に説明する。
【００３１】
図２を参照（適宜図１参照）して、エントリがＲＴＰフローであるかを判定する処理について説明する。
更新されたエントリがリアルタイムなトラフィックである場合は、エントリの評価カウンタ１３ｅの増加率が高い。このことを利用し、ＲＴＰトラフィック解析・推定手段１４は、エントリの評価カウンタが更新されると、更新されたエントリの評価カウンタ１３ｅの増加率を評価し、エントリのフローがリアルタイムなトラフィックであると推定することができる。
また、エントリの評価カウンタ１３ｅの増加率が低い場合は、リアルタイムなトラフィックである可能性が低いと判断し、更新されたエントリの削除を行う。
【００３２】
このようにトラフィック解析装置１Ａを構成することで、高速な通信回線上を流れるＩＰトラフィックを解析し、ＲＴＰパケットの推定および抽出をオンラインで実現することが可能となる。
【００３３】
次に、図５を参照（適宜図１参照）して、パケットヘッダ・ペイロード解析手段１２の動作について説明する。図５は、第１実施形態に係るパケットヘッダ・ペイロード解析手段の動作を示すフローチャートである。
【００３４】
まず、パケットヘッダ・ペイロード解析手段１２は、ＩＰトラフィック受信手段１１からＩＰパケットを受信する（Ｓ１１）。
受信したＩＰパケットを受け取ったパケットヘッダ・ペイロード解析手段１２は、前記した（１）〜（６）をキーとして、フロー解析エントリテーブル１３を検索し、受信したＩＰパケットと一致するエントリがフロー解析エントリテーブル１３に存在するかを判定する（Ｓ１２）。
【００３５】
受信したＩＰパケットと一致するエントリが解析エントリテーブル１３に存在しない場合（Ｓ１２でＮｏ）、パケットヘッダ・ペイロード解析手段１２は、受信パケット内のデータがＲＴＰパケットの特徴をもつかを、判定する（Ｓ１３）。すなわち、前記した（ａ−１）〜（ａ−３）の条件を満たすかどうかを判定する。ＲＴＰパケットの特徴をもつと判定された場合（Ｓ１３でＹｅｓ）、パケットヘッダ・ペイロード解析手段１２は、フロー解析エントリテーブル１３に受信したＩＰパケットのエントリを登録し（Ｓ１４）、パケット受信ステップ（Ｓ１１）に戻る。ＲＴＰパケットの特徴をもつと判定されなかった場合（Ｓ１３でＮｏ）、エントリの登録を行わずにＩＰパケット受信ステップ（Ｓ１１）に戻る。
【００３６】
受信したＩＰパケットと一致するエントリが解析エントリテーブル１３に存在した場合（Ｓ１２でＹｅｓ）、パケットヘッダ・ペイロード解析手段１２は、受信パケット内のデータがＲＴＰフローの特徴をもつかを判定する（Ｓ１５）。すなわち、前記した（ｂ−１）〜（ｂ−２）の条件を満たすかどうかを判定する。
【００３７】
受信パケット内のデータがＲＴＰフローの特徴をもたないと判定された場合（Ｓ１５でＮｏ）、パケットヘッダ・ペイロード解析手段１２は、ＩＰパケット受信ステップ（Ｓ１１）に戻る。
【００３８】
受信パケット内のデータがＲＴＰフローの特徴をもつと判定された場合（Ｓ１５でＹｅｓ）、パケットヘッダ・ペイロード解析手段１２は、フロー解析エントリテーブル１３上の受信したＩＰパケットのエントリを更新する（Ｓ１６）。そして、パケットヘッダ・ペイロード解析手段１２は、受信したＩＰパケットの評価値を前記した条件（ｃ−１）〜（ｃ−４）等を利用してカウントし、フロー解析エントリテーブル１３にある受信したＩＰパケットのエントリの評価カウンタに加算する（Ｓ１７）。続いて、パケットヘッダ・ペイロード解析手段１２は、ＩＰパケット受信ステップ（Ｓ１１）に戻る。
【００３９】
次に、図６を参照（適宜図１参照）して、ＲＴＰトラフィック解析・推定手段１４の動作について説明する。図６は、第１実施形態に係るＲＴＰトラフィック解析・推定手段の動作を示すフローチャートである。
【００４０】
ＲＴＰトラフィック解析・推定手段１４は、エントリの評価カウンタの増加率を評価し、エントリがＲＴＰフローであるかを判定する（Ｓ２１）。エントリの評価カウンタの増加率が低い場合（Ｓ２１でＹｅｓ）、エントリの削除を行い（Ｓ２２）、エントリの評価カウンタの増加率を評価する処理（Ｓ２１）に戻る。エントリの評価カウンタの増加率が低くない場合（Ｓ２２でＮｏ）、エントリの削除を行わずにエントリの評価カウンタの増加率を評価する処理（Ｓ２１）に戻る。ＲＴＰトラフィック解析・推定手段１４は、定期的にエントリの評価カウンタの増加率を評価する処理（Ｓ２１）を行うようにするのが好ましい。また、パケットヘッダ・ペイロード解析手段１２が、受信したＩＰパケットと一致するエントリが解析エントリテーブル１３に存在すると判定した場合（図５のＳ１２でＹｅｓ）に、エントリの評価カウンタの増加率を評価する処理（Ｓ２１）をＲＴＰトラフィック解析・推定手段１４が行うようにしてもよい。
【００４１】
以上、図５および図６に示した各ステップによって、本発明の第１実施形態に係るトラフィック解析装置１Ａは、高速な通信回線上を流れるＩＰトラフィックを解析し、ＲＴＰパケットの推定および抽出をオンラインで実現することが可能となる。
【００４２】
次に、図７を参照して、トラフィック解析装置１Ａを含むネットワークの構成について説明する。図７は、第１実施形態に係るトラフィック解析装置を含むネットワークの構成を示す図である。図７に示すように、トラフィック解析装置１Ａは、通信回線上に存在している。トラフィック解析装置１Ａは、データ転送装置ＤＴからスイッチ（またはルータ）ＳＲ１を経由してスイッチ（またはルータ）ＳＲ２に流れるデータ転送系ＩＰトラフィックを解析する。また、リアルタイムデータ転送装置ＲＴからスイッチ（またはルータ）ＳＲ１を経由してスイッチ（またはルータ）ＳＲ２に流れるリアルタイム系ＩＰトラフィックを解析する。トラフィック解析装置１Ａは、パケットヘッダ・ペイロード解析手段１２またはＲＴＰトラフィック解析・推定手段１４で解析した結果（以下、「解析結果」という）に基づいて、トラフィック解析装置１Ａを通過するＩＰトラフィックを制御する機能を備えてもよい。
【００４３】
［第２実施形態］
次に、図８を参照して、トラフィック解析装置１Ｂを含むネットワークの構成について説明する。
【００４４】
図８は、第２実施形態に係るトラフィック解析装置を含むネットワークの構成を示す図である。図８に示すように、トラフィック解析装置１Ｂは、通信回線上に存在している。トラフィック解析装置１Ｂは、トラフィック解析結果をトラフィック制御装置ＴＣに通知する機能を備える。トラフィック制御装置ＴＣは、通知された解析結果を利用して、ＩＰトラフィックを制御することが可能となる。
【００４５】
［第３実施形態］
次に、図９を参照して、トラフィック解析装置１Ｃを含むネットワークの構成について説明する。
【００４６】
図９は、第３実施形態に係るトラフィック解析装置を含むネットワークの構成を示す図である。図９に示すように、トラフィック解析装置１Ｃは、通信回線上に存在している。トラフィック解析装置１Ｃは、トラフィック解析結果をスイッチ（またはルータ）ＳＲ２に通知する機能を備える。スイッチ（またはルータ）ＳＲ２は、通知された解析結果を利用して、ＩＰトラフィックを制御することが可能となる。
【００４７】
［第４実施形態］
次に、図１０を参照して、トラフィック解析装置１Ｄを含むネットワークの構成について説明する。
【００４８】
図１０は、第４実施形態に係るトラフィック解析装置を含むネットワークの構成を示す図である。図１０に示すように、トラフィック解析装置１Ｄは、通信回線上に存在せず、ミラーリングされたＩＰパケットを受信し、トラフィックを解析する。トラフィック解析装置１Ｄは、トラフィック解析結果をトラフィック制御装置ＴＣまたはスイッチ（またはルータ）ＳＲ２に通知する機能を備える。トラフィック制御装置ＴＣまたはスイッチ（またはルータ）ＳＲ２は、通知された解析結果を利用して、ＩＰトラフィックを制御することが可能となる。
【００４９】
以上、本発明の実施形態に係るトラフィック解析装置の構成について説明したが、トラフィック解析装置１Ａ、１Ｂ、１Ｃおよび１Ｄは、コンピュータに通信回線上のトラフィックを解析するためのプログラムを実行させ、コンピュータ内の演算装置や記憶装置を動作させることにより実現される。
【図面の簡単な説明】
【００５０】
【図１】第１実施形態に係るトラフィック解析装置のブロック図である。
【図２】第１実施形態に係るフロー解析エントリテーブルのデータ構造を示す図である。
【図３】第１実施形態に係るＲＴＰパケットのデータ構造を示す図である。
【図４】第１実施形態に係るフロー解析エントリテーブルの更新パターンを示す図である。
【図５】第１実施形態に係るパケットヘッダ・ペイロード解析手段の動作を示すフローチャートである。
【図６】第１実施形態に係るＲＴＰトラフィック解析・推定手段の動作を示すフローチャートである。
【図７】第１実施形態に係るトラフィック解析装置を含むネットワークの構成を示す図である。
【図８】第２実施形態に係るトラフィック解析装置を含むネットワークの構成を示す図である。
【図９】第３実施形態に係るトラフィック解析装置を含むネットワークの構成を示す図である。
【図１０】第４実施形態に係るトラフィック解析装置を含むネットワークの構成を示す図である。
【符号の説明】
【００５１】
１Ａ，１Ｂ，１Ｃ，１Ｄ  トラフィック解析装置
１１    ＩＰトラフィック受信手段
１２    パケットヘッダ・ペイロード解析手段
１３    フロー解析エントリテーブル
１４    ＲＴＰトラフィック解析・推定手段
１３ｅ  評価カウンタ
１３ｉ  エントリ
【図１】
2006246116.tif 000003
【図２】
2006246116.tif 000004
【図３】
2006246116.tif 000005
【図４】
2006246116.tif 000006
【図５】
2006246116.tif 000007
【図６】
2006246116.tif 000008
【図７】
2006246116.tif 000009
【図８】
2006246116.tif 000010
【図９】
2006246116.tif 000011
【図１０】
2006246116.tif 000012