(57)【要約】    【課題】      ＴＣＰ／ＩＰプロトコルスィートインプリメンテーションから独立して、ＲＴＰを識別すること。    【解決手段】  ＩＰパケットサンプリング部１１２はノードに到来するＩＰパケットフローからＩＰパケットをサンプル抽出する。ＲＴＰヘッダー検出部１１４はサンプル抽出されたＩＰパケット内のＲＴＰヘッダーの存在を検出する。通知部１１６はノードに対して、ＲＴＰヘッダーの存在が検出された場合に、当該ＩＰパケットフローがＲＴＰペイロードを搬送するものであることを通知する。  【選択図】      図２
2005101743.tif 000002
【特許請求の範囲】
【請求項１】
ノードに到来するＩＰパケットフローからＩＰパケットをサンプル抽出するサンプリング手段と、前記サンプル抽出されたＩＰパケットの中にＲＴＰヘッダーの存在を検出する検出手段と、前記ＲＴＰヘッダーの存在が検出された場合に、前記ノードに対して、前記ＩＰパケットがＲＴＰペイロードを搬送するものであることを通知する通知手段と、を具備することを特徴とするＲＴＰペイロードを含むＩＰパケットフローを識別するための装置。
【請求項２】
前記検出手段は、前記サンプル抽出されたＩＰパケットの中にＵＤＰペイロードの存在を検出するＵＤＰペイロード検出手段と、第一の所定条件を用いて、前記ＵＤＰペイロード検出手段により、前記ＵＤＰペイロードの存在が検出された場合に、前記サンプル抽出されたＩＰパケットの中に前記ＲＴＰヘッダーが存在する可能性を決定する決定手段と、前記サンプル抽出されたＩＰパケットの中に前記ＲＴＰヘッダーが存在する可能性があると決定された場合に、第二の所定条件を用いて、前記サンプル抽出されたＩＰパケットのスコアを取得する取得手段と、前記取得されたスコアに基づいて、前記サンプル抽出されたＩＰパケットの中に前記ＲＴＰヘッダーが存在するかどうかを判定する判定手段と、を具備することを特徴とする請求項１に記載のＲＴＰペイロードを含むＩＰパケットフローを識別するための装置。
【請求項３】
ノードに到来するＩＰパケットフローからＩＰパケットをサンプル抽出するサンプリングステップと、前記サンプル抽出されたＩＰパケットの中にＲＴＰヘッダーの存在を検出する検出ステップと、前記ＲＴＰヘッダーの存在が検出された場合に、前記ノードに対して、前記ＩＰパケットがＲＴＰペイロードを搬送するものであることを通知する通知ステップと、を具備することを特徴とするＲＴＰペイロードを含むＩＰパケットフローを識別するための方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＴＣＰ／ＩＰ（送信制御プロトコル／インターネットプロトコル）プロトコルスィートをベースとする通信ネットワークに用いられるＲＴＰ（リアルタイムトランスポートプロトコル）ペイロードを含むＩＰ（インターネットプロトコル）パケットを検出するための装置および方法に関する。
【背景技術】
【０００２】
ＴＣＰ／ＩＰプロトコルスィートでは、最外のプロトコルヘッダーはそのバージョンナンバーにより示される（例えば、ＩＰｖ４、ＩＰｖ６など）。内側プロトコルヘッダーについては、そのプロトコルタイプが外側プロトコルヘッダーによって示されている場合が多い。例えば、往々にして、ＩＰｖ４ではプロトコルタイプがプロトコルタイプフィールドによって示され、ＩＰｖ６では、これが次ヘッダーフィールドによって示されている。一方、この範疇に収まらない幾つかのプロトコルヘッダーも存在する。それらのプロトコルヘッダーはそれらが存在することを示す、他と重複しないユニークなプロトコルナンバーを有しておらず、プロトコルヘッダーがペイロードと合わせて、外側プロトコルのためのペイロードとして搬送される。この時、外側ヘッダーには、それらが存在することを示す明示的なインジケーションがない。ＲＴＰはそうしたものの一つである。
【０００３】
ＴＣＰ／ＩＰプロトコルスィートでは、ＲＴＰは、映像または音声サービスなどのリアルタイム通信データを搬送する。ＲＴＰパケットは、一般的にＵＤＰ（ユーザデータグラムプロトコル）ペイロードとして搬送され、ＲＴＰは多重化およびチェックサム機能を提供するにあたってはＵＤＰのサポートに依存する。ある程度までにおいては、これはＲＴＰにとって好都合であり、ＲＴＰがサポートされていないネットワーク、さらにはＲＴＰの存在を認識しない古いネットワークを介してさえも、ＲＴＰパケットをより容易にトランスポートすることを可能とする。
【０００４】
一方で、下位レイヤーが、例えば、ＲＴＰヘッダー圧縮などのような追加のサービスまたはサポートを提供する必要があるネットワークも幾つか存在する。そのような場合においては、係る追加のサービスまたはサポートはＲＴＰの識別に基づいて行なわれる必要がある。
【０００５】
従来、ＴＣＰ／ＩＰインプリメンテーションにおいては、ある一つの方法が提案されていた。係る方法では、ＲＴＰの存在を示すための特別のＡＰＩ（アプリケーションプログラミングインタフェイス）または参照テーブルが使用される（例えば、非特許文献１参照）。
【非特許文献１】「ＧＮＵ  ｃｃＲＴＰ」、http://www.gnu.org/software/ccrtp/  、２００２年１０月２８日
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記説明した従来方法では、ＲＴＰおよび／またはＴＣＰ／ＩＰのインプリメンテーションに変更がある時には常に、それに従って下位レイヤーがアップデートされる必要があり、これはホストコンピュータ、ルーター、その他などのノードにとっては柔軟性に欠けるものとなる。また、この方法は、ＲＴＰフローが固定経路を使用するように制限するものであるので、ルーター上で用いることがほぼ不可能である。またさらに、ネットワークが拡張したときに、係る方法では十分なスケーリングが行なえない。また、上記説明のように参照テーブルを用いる場合には、参照テーブルをネットワーク全体にセットアップし、これを更新維持する必要があるため、係る方法はローバスト性に欠けることとなる。すなわち、ＲＴＰインプリメンテーションが明示のインジケーションを出すことに依存することなく、ＲＴＰを識別することができるようにするための方法が全く提案されていないという問題がある。
【０００７】
本発明の目的は、ＴＣＰ／ＩＰプロトコルスィートインプリメンテーションから独立してＲＴＰを識別することができるようにするための、ＲＴＰペイロードを含むＩＰパケットフローを識別するための装置および方法を提供することである。
【課題を解決するための手段】
【０００８】
本発明に係るＲＴＰペイロードを含むＩＰパケットフローを識別するための装置は、ノードに到来するＩＰパケットフローからＩＰパケットをサンプル抽出するサンプリング手段と、前記サンプル抽出されたＩＰパケットの中にＲＴＰヘッダーの存在を検出する検出手段と、前記ＲＴＰヘッダーの存在が検出された場合に、前記ノードに対して、前記ＩＰパケットがＲＴＰペイロードを搬送するものであることを通知する通知手段と、を具備する構成を採る。
【０００９】
この構成によれば、ノードに到来するＩＰパケットフローからサンプル抽出されたＩＰパケット内のＲＴＰヘッダーの存在についての検出がなされ、前記ＲＴＰヘッダーの存在が検出された場合に、前記ＩＰパケットフローがＲＴＰペイロードを搬送していることが前記ノードに対して通知されるので、ＲＴＰペイロードがＵＤＰペイロードの一部として扱われることなく、また、前記ＲＴＰペイロードの存在を明示的に示すインジケーションをＲＴＰインプリメンテーションに頼ることなく、前記ノードが前記ＲＴＰペイロードを含む前記ＩＰパケットフローを処理することができ、よって、ＴＣＰ／ＩＰのプロトコルスィートインプリメンテーションから独立して、ＲＴＰを識別することができるようになる。
【００１０】
本発明に係るＲＴＰペイロードを含むＩＰパケットフローを識別するための装置は上述の構成において、前記検出手段が、前記サンプル抽出されたＩＰパケットの中にＵＤＰペイロードの存在を検出するＵＤＰペイロード検出手段と、第一の所定条件を用いて、前記ＵＤＰペイロード検出手段により、前記ＵＤＰペイロードの存在が検出された場合に、前記サンプル抽出されたＩＰパケットの中に前記ＲＴＰヘッダーが存在する可能性を決定する決定手段と、前記サンプル抽出されたＩＰパケットの中に前記ＲＴＰヘッダーが存在する可能性があると決定された場合に、第二の所定条件を用いて、前記サンプル抽出されたＩＰパケットのスコアを取得する取得手段と、前記取得されたスコアに基づいて、前記サンプル抽出されたＩＰパケットの中に前記ＲＴＰヘッダーが存在するかどうかを判定する判定手段と、を具備する構成を採る。
【００１１】
この構成によれば、ＲＴＰヘッダーがサンプル抽出されたＩＰパケット内に存在するかどうかについての判定結果が、二つの異なる条件を用いた量的解析を含めたレイヤー毎の解析の後に得られるため、ノードに到来するＩＰパケットフローがＲＴＰペイロードを搬送しているというインジケーションがなくとも、ＲＴＰを識別することが可能である。
【００１２】
本発明に係るＲＴＰペイロードを含むＩＰパケットフローを識別するための方法は、ノードに到来するＩＰパケットフローからＩＰパケットをサンプル抽出するサンプリングステップと、前記サンプル抽出されたＩＰパケットの中にＲＴＰヘッダーの存在を検出する検出ステップと、前記ＲＴＰヘッダーの存在が検出された場合に、前記ノードに対して、前記ＩＰパケットがＲＴＰペイロードを搬送するものであることを通知する通知ステップと、を具備するようにした。
【００１３】
この方法によれば、ノードに到来するＩＰパケットフローからサンプル抽出されたＩＰパケット内のＲＴＰヘッダーの存在についての検出がなされ、前記ＲＴＰヘッダーの存在が検出された場合に、前記ＩＰパケットフローがＲＴＰペイロードを搬送していることが前記ノードに対して通知されるので、ＲＴＰペイロードがＵＤＰペイロードの一部として扱われることなく、また、前記ＲＴＰペイロードの存在を明示的に示すインジケーションをＲＴＰインプリメンテーションに頼ることなく、前記ノードが前記ＲＴＰペイロードを含む前記ＩＰパケットフローを処理することができ、よって、ＴＣＰ／ＩＰのプロトコルスィートインプリメンテーションから独立して、ＲＴＰを識別することができるようになり、スケーラビリティとローバスト性が得られる。
【発明の効果】
【００１４】
上述したように、本発明によれば、ＴＣＰ／ＩＰのプロトコルスィートインプリメンテーションから独立して、ＲＴＰを識別することが可能となる。
【発明を実施するための最良の形態】
【００１５】
本発明の骨子は、ノードに到来するＩＰパケットフローからサンプル抽出されたＩＰパケットの中にＲＴＰヘッダーの存在を検出し、前記ＲＴＰヘッダーの存在が検出された場合に、前記ノードに対して、前記ＩＰパケットがＲＴＰペイロードを搬送していることを通知することである。
【００１６】
図１は本発明の一実施の形態に係るＲＴＰ識別装置を含む通信ネットワークの構成を示す図である。
【００１７】
図１に示される通信ネットワーク１００はＲＴＰ識別装置１１０およびノード１２０、１３０、１４０、１５０、１６０、１７０を含む。この点において、説明の便宜上、通信ネットワーク１００はこのような構成を有するものとしているが、ＲＴＰ識別装置が用いられる通信ネットワークの構成は上記説明したものに限られるものではない。例えば、ＲＴＰ識別装置１１０はホストコンピュータ上、ルーター上、および／またはＲＴＰに対する特別のサポートを提供する如何なるネットワーク機器上で用いることもできる。
【００１８】
ＲＴＰ識別装置１１０の内部構成を図２に示す。図２に示すＲＴＰ識別装置１１０は、ノード１２０に到来するＩＰパケットより構成されるＩＰパケットフローからＩＰパケットをサンプル抽出するＩＰパケットサンプリング部１１２と、ＩＰパケットサンプリング部１１２によりサンプル抽出されたＩＰパケット内のＲＴＰヘッダーの存在を検出するＲＴＰヘッダー検出部１１４と、ノード１２０内のＩＰパケット処理部１２２に対して、ＲＴＰヘッダー検出部１１４によりＲＴＰヘッダーの存在が検出された場合に、着信ＩＰパケットフローがＲＴＰペイロードを搬送するものであることを通知する通知部１１６を備える。従って、ＲＴＰヘッダー検出部１１４によりＲＴＰヘッダーの存在が検出された場合には、ＩＰパケット処理部１２２はＩＰパケットフローがサンプル抽出された着信ＩＰパケットフローに含まれるＩＰパケットをＲＴＰパケットとして処理する。
【００１９】
次に、ＲＴＰ識別装置１１０におけるＲＴＰヘッダー検出部１１４の動作について説明する。図３Ａおよび図３ＢはＲＴＰ識別装置１１０におけるＲＴＰヘッダー検出部１１４の動作の例を説明するフローチャートである。
【００２０】
まず、ステップＳ１１００において、ＩＰｖ４またはＩＰｖ６仕様によるところの標準的なレイヤー毎の処理である、着信ＩＰパケット内のＵＤＰセグメントに対してのチェックが行なわれる。ここでは、着信パケットとは、ＩＰパケットサンプリング部１１２によりサンプル抽出されたＩＰパケットを意味する。そして、着信ＩＰパケットがＵＤＰペイロードを含むかどうかが判定される（Ｓ１２００）。判定の結果、係る着信ＩＰパケットがＵＤＰペイロードを含んでいない場合には（Ｓ１２００：ＮＯ）手順はステップＳ１３００に進む。
【００２１】
ステップＳ１３００では、当該着信ＩＰパケット内にはＲＴＰヘッダーが存在しないことを意味する、否定結果を示す信号が通知部１１６に対して出力される。
【００２２】
一方、判定の結果、係る着信ＩＰパケットがＵＤＰペイロードを含んでいる場合には（Ｓ１２００：ＹＥＳ）前記着信ＩＰパケットからフローＩＤが取得される（Ｓ１４００）。フローＩＤは、送信元／宛先ＩＰアドレスと送信元／宛先ポート番号から構成される、ＩＰパケットフローの識別子である。
【００２３】
そして、ステップＳ１５００においては、当該着信ＩＰパケットに対して、所定の絶対条件によるチェックがなされる。絶対条件による係るチェックの詳細については、後述することとする。そして、ステップＳ１６００においては、当該着信ＩＰパケットが絶対条件をパスするかどうかが決定される。
【００２４】
この決定結果として、当該着信ＩＰパケットが絶対条件をパスする場合には（Ｓ１６００：ＹＥＳ）、暫定的に当該着信ＩＰパケットはＲＴＰペイロードを含むものとして扱われ、同期送信元識別子（以降、「ＳＳＲＣ」と称する）に対応する値、ＲＴＰシーケンス番号（以降、「ＳＮ」と称する）に対応する値、および、ＲＴＰタイムスタンプ（以降、「ＴＳ」と称する）が、当該着信ＩＰパケットに含まれる暫定のＲＴＰヘッダーから取得される（Ｓ１７００）。一方、当該着信ＩＰパケットが絶対条件をパスしない場合には（Ｓ１６００：ＮＯ）当該着信ＩＰパケットはＲＴＰペイロードを含まないものとして扱われ、取得されたフローＩＤが事前に内部記憶された現在のフローリスト上で検索される（Ｓ１８００）。
【００２５】
そして、ステップＳ１９００において、取得されたフローＩＤが現在のフローリスト上に存在するかどうかが判断される。判断の結果、当該フローＩＤが現在のフローリスト上に存在しない場合には（Ｓ１９００：ＮＯ）手順はステップＳ１３００へと進み、一方、当該フローＩＤが現在のフローリスト上に存在する場合には（Ｓ１９００：ＹＥＳ）当該取得されたフローＩＤが現在のフローＩＤから除かれた後に（Ｓ２０００）ステップＳ１３００へと進む。
【００２６】
一方、ステップＳ２１００においては、取得されたフローＩＤが現在のフローリスト上で検索される。そして、ステップＳ２２００において、取得されたフローＩＤが現在のフローリスト上に存在するかどうかが判断される。判断の結果、当該フローＩＤが現在のフローリスト上に存在する場合には（Ｓ２２００：ＹＥＳ）取得されたＳＳＲＣが現在のフローリストにおける当該フローＩＤの（現在解析中の）パケットフローについて記録されたＳＳＲＣ情報（すなわち、ＳＳＲＣについての情報）に適合するかどうかが判断される。当該取得されたＳＳＲＣがこれに適合する場合には（Ｓ２３００：ＹＥＳ）当該着信ＩＰパケットに対する所定の相対条件を用いたチェックがなされ（Ｓ２４００）当該ＩＰパケットの最終スコアが取得される。相対条件による係るチェックの詳細については、後述することとする。一方、当該取得されたＳＳＲＣがこれに適合しない場合には、手順はステップＳ２０００へと進む。
【００２７】
ステップＳ２２００における判断の結果が否定的である場合、すなわち、当該取得されたフローＩＤが現在のフローリスト上に存在しない場合には（Ｓ２２００：ＮＯ）当該取得されたフローＩＤが現在のフローリストに追加され（Ｓ２５００）当該着信ＩＰパケットと同一のパケットフローに属する次のＩＰパケットを待つウェイト状態に入り（Ｓ２６００）Ｓ１１００に進む。
【００２８】
そして、ステップＳ２４００の後のステップＳ２７００において、調査中のＩＰパケットフローに属するＩＰパケットの総数が所定の最大数と比較され、最大数の着信ＩＰパケットが受信されたかどうかが判断される（Ｓ２７００）。ステップＳ２７００における判断により、エンドレスな動作手順を回避することができる。判断の結果、最大数の着信ＩＰパケットが受信された場合には（Ｓ２７００：ＹＥＳ）手順はステップＳ１３００へと進み、一方、最大数の着信ＩＰパケットが受信されていない場合には（Ｓ２７００：ＮＯ）手順はステップＳ２８００へと進む。
【００２９】
ステップＳ２８００では、最終スコアが有効であるかどうかが判断される。最終スコアが有効でない場合には（Ｓ２８００：ＮＯ）手順はステップＳ２６００へと進み、一方、最終スコアが有効である場合には（Ｓ２８００：ＹＥＳ）ステップＳ２９００へと進む。
【００３０】
ステップＳ２９００では、最終スコアが所定の閾値以上であるかどうかが判断される。判断の結果、最終スコアが所定の閾値以上である場合には（Ｓ２９００：ＹＥＳ）当該着信ＩＰパケット内にはＲＴＰヘッダーが存在することを意味する、肯定結果を示す信号が通知部１１６に対して出力される（Ｓ３０００）。一方、最終スコアが閾値以上でない場合には（Ｓ２９００：ＮＯ）手順はステップＳ１３００へと進む。
【００３１】
次に、上記のステップＳ１５００における絶対条件を用いたチェック手順について、詳細に説明する。図４はＲＴＰヘッダー検出部１１４における絶対条件を用いたチェック手順を説明するためのフローチャートである。
【００３２】
まず、ステップＳ１５１０において、着信ＩＰパケット内のＵＤＰ送信元ポート番号が偶数であるかどうかが判断される。送信元ポート番号が偶数である場合には（Ｓ１５１０：ＹＥＳ）ＵＤＰセグメントパケット長が２０以上であるかどうかが判断される（Ｓ１５２０）。ＵＤＰパケット長が２０以上である場合には（Ｓ１５２０：ＹＥＳ）ＵＤＰペイロードのＲＴＰバージョンナンバー（図４におけるＲＴＰ＿ＶＥＲＳＩＯＮ）が２であるかどうかが判断される（Ｓ１５３０）。ＲＴＰバージョンナンバーが２である場合には（Ｓ１５３０：ＹＥＳ）ＲＴＰ貢献ソースカウント（以降、「ＣＣ」と称する）に対応する値が取得される（Ｓ１５４０）。
【００３３】
そして、ステップＳ１５５０において、ＣＣが０であるかどうかが判断される。ＣＣが０である場合（Ｓ１５５０：ＹＥＳ）当該着信ＩＰパケットは絶対条件をパスするとの結論が下される（Ｓ１５６０）。ＣＣが０でない場合（Ｓ１５５０：ＮＯ）ＭｉｎＬｅｎｇｔｈが計算される（Ｓ１５７０）。ここでは、ＭｉｎＬｅｎｇｔｈは１１にＣＣを４倍して加算したものに等しい。
【００３４】
そして、ステップＳ１５８０において、ＣＣフィールド後のバイト数がＭｉｎＬｅｎｇｔｈ以上であるかどうかが判断される。ＣＣフィールド後のバイト数がＭｉｎＬｅｎｇｔｈ以上である場合には（Ｓ１５８０：ＹＥＳ）ステップＳ１５６０に進む。
【００３５】
ＵＤＰ送信元ポート番号が偶数でない場合（Ｓ１５１０：ＮＯ）、パケット長が２０以上でない場合（Ｓ１５２０：ＮＯ）、ＲＴＰバージョンナンバーが２でない場合（Ｓ１５３０：ＮＯ）、ＣＣフィールド後のバイト数がＭｉｎＬｅｎｇｔｈ以上でない場合には（Ｓ１５８０：ＮＯ）当該着信ＩＰパケットは絶対条件をパスできないものとの結論が下される（Ｓ１５９０）。
【００３６】
上記の説明の通り、絶対条件を用いたチェックを実行することにより、着信ＩＰパケット内のＲＴＰヘッダーの存在可能性が判断できる。具体的には、絶対条件が満たされる場合には、ＲＴＰヘッダーが着信ＩＰパケット内に存在する可能性があり、これはすなわち、着信ＩＰパケットがＲＴＰペイロードを含む可能性があるということになる。絶対条件が満たされない場合には、着信ＩＰパケットがＲＴＰペイロードを含む可能性は無いこととなる。
【００３７】
次に、上記のステップＳ２４００における相対条件を用いたチェック手順について、詳細に説明する。図５はＲＴＰヘッダー検出部１１４における相対条件を用いたチェック手順を説明するためのフローチャートである。
【００３８】
まず、ステップＳ２４１０において、着信ＩＰパケットを含めた二つの連続するＩＰパケット間のＳＮ差のスコアが取得される。このスコアをＳＳＮと呼ぶことにする。
【００３９】
暫定的にＲＴＰペイロードを含むものとして扱われるＩＰパケットフローについては、ＳＮは１からランダムな数への直線的な傾きをもって増加することが予測される。すなわち、ＳＮは各新規パケットに対して、１ずつ増加するはずのものである。従って、二つの連続するパケット間のＳＮ差は１である。このＳＳＮ取得の動作について、図６を用いて以下に説明する。
【００４０】
まず、ＳＮ差であるｎの値が取得される（Ｓ２４１１）。次に、ｎが０より大きいかどうかが判断される（Ｓ２４１２）。ｎが０より大きい場合には（Ｓ２４１２：ＹＥＳ）以下の（式１）の計算がなされ、ＳＳＮが取得される（Ｓ２４１３）。ｎが０より大きくない場合には（Ｓ２４１２：ＮＯ）ｎが０より小さいかどうかが判断される（Ｓ２４１４）。ｎが０より小さい場合には（Ｓ２４１４：ＹＥＳ）以下の（式２）の計算がなされ、ＳＳＮが取得される（Ｓ２４１５）。ｎが０より小さくない場合には（Ｓ２４１４：ＮＯ）ｎ＝０は通信エラーもしくはパケット重複の場合に起こり得る特殊なケースであり、このようなケースは処理から除外して良いので、手順は終了となる。さらに、以下の式は、例えパケット損失や順序違いが起こった場合でも連続パケット間にはあまり大きなＳＮ差が生じていることは無いということを考慮して用いられる。また、判断を行なうにあたっては少なくとも三つのパケットを解析する必要があるので、二以上のＳＮ差が取得される。マルチパケットの状況においては、全てのＳＳＮの平均値が用いられる。
【数１】
2005101743.tif 000003
【数２】
2005101743.tif 000004
【００４１】
再度、図５を参照するに、ステップＳ２４００においては、着信ＩＰパケットフローのＴＳ変動スコアが取得される。このスコアをＳＴＳと呼ぶことにする。
【００４２】
ＴＳはリニアクロックから取得され、さらに殆どのリアルタイムアプリケーションでは一様なサンプリングが用いられることを考慮するに、ＴＳ差はある値の同値または整数倍の値となる。整数倍の値はＲＴＰのＳＮ差ｎに対応するが、幾つかのアプリケーションでそうであるように、ＴＳが一様に変化しない場合、例えば、幾つかのＲＴＰパケットが同一のサンプルに対応する時にＴＳが変化しない場合などもあり得る。また、パケット損失についても考慮しつつ、ＴＳフィールドは以下の方法で処理される。
【００４３】
ＳＮ差ｎが０でない場合には、基本となるＴＳ変動を求めることができる。基本ＴＳ変動はＴＳ差をＳＮ差ｎで除算することで求められる。なお、特別の状況においては、基本ＴＳ変動は０となり得る。そして、以下の二つの特殊なケースを考慮しつつ、基本ＴＳ変動値の平均値が求められる。
【００４４】
（ａ）基本ＴＳ変動値に０の値が存在する場合、または二つの連続するＴＳに対して不連続のＳＮが存在する場合には、０でない基本ＴＳ変動値に対して、他の値の整数倍の値であるものがあるかどうかのチェックがなされる。このような値が存在する場合には、小さいほうの値が除かれる。
【００４５】
（ｂ）基本ＴＳ変動値が０である場合、この値は除く必要がある。
【００４６】
そして、「ＴＳＳＡＶＥ」と表すこととする、残り全ての基本ＴＳ変動値の平均値が求められる。ＴＳＳＡＶＥが算出された後、ＴＳＳＡＶＥを基準にして、各々の基本ＴＳ変動値に対してスコアが与えられる。
【００４７】
基本ＴＳ変動値が処理中に除かれた値に属する場合には、係る基本ＴＳ変動値には最も高いスコア、すなわち、scoreｎ＝１が与えられる。これ以外の場合には、scoreｎは以下の（式３）を用いて算出される。
【数３】
2005101743.tif 000005
【００４８】
上記の式において、scoreｎは第ｎ番目の基本ＴＳ変動値に対するスコアであり、ＴＳＳｎは第ｎ番目の基本ＴＳ変動値の値であり、ＴＳＳＡＶＥは基本ＴＳ変動値の平均値であり、さらにＤｉｆｆはＴＳＳｎとＴＳＳＡＶＥの間の差の絶対値である。このスコアリング方法は図７に示されている。
【００４９】
各々の基本ＴＳ変動値に対する全てのスコアが取得された後、これら全てのスコアの平均値を計算することにより、ＳＴＳが取得される。
【００５０】
そして、図５を再度参照するに、ステップＳ２４３０において、ＳＳＮとＳＴＳが合わせられて最終スコアＳが取得される。これらを合わせるにあたっては、ＳＳＮは予め定められた重み、例えば「０．４」で重み付けされ、ＳＴＳが予め定められた重み、例えば「０．６」で重み付けされる。そして、最終スコアが上述のように所定の閾値（例えば、「０．６」）と比較される。
【００５１】
従って、本実施の形態によれば、着信ＩＰパケット内のＲＴＰヘッダーが検出され、前記ＲＴＰヘッダーの存在が検出された場合に、前記ＩＰパケットフローがＲＴＰペイロードを搬送していることがノードに対して通知されるので、ＲＴＰペイロードがＵＤＰペイロードの一部として扱われることなく、また、前記ＲＴＰペイロードの存在を明示的に示すインジケーションをＲＴＰインプリメンテーションに頼ることなく、前記ノードが前記ＲＴＰペイロードを含む前記ＩＰパケットフローを処理することができ、よって、ＴＣＰ／ＩＰのプロトコルスィートインプリメンテーションから独立して、ＲＴＰを識別することができるようになる。
【００５２】
また、本実施の形態によれば、ＲＴＰヘッダーが着信ＩＰパケット内に存在するかどうかについての判定結果が、絶対条件および相対条件を用いた量的解析を含めたレイヤー毎の解析の後に得られるため、ノードに到来するＩＰパケットフローがＲＴＰペイロードを搬送しているというインジケーションがなくとも、ＲＴＰを識別することが可能である。
【００５３】
また、本実施の形態によれば、僅か幾つかのパケットを調べることにより、ＲＴＰヘッダーを検出することができ、さらに多くのパケットが調べられる場合には、より信頼性の高い検出結果が得られることとなる。
【００５４】
さらに加えて、現在のフローリストの各項目に対して、タイマーをセットしても良い。このタイマーは新規パケットが到来する度に元の値にリセットされる。タイマーがタイムアウトになると、当該項目が削除され、現在のフローリストが更新される。
【００５５】
また、本実施の形態に用いられた上述の方法は、ＴＳがランダム変動するＲＴＰフロー、またはＴＳがたびたび逆変化するような、換言すれば、ＳＮが増加する間にＴＳが減少するようなＲＴＰフローには適さない場合があるが、実際上このような二つの状況が生じることは稀である。
【産業上の利用可能性】
【００５６】
本発明に係るＲＴＰペイロードを含むＩＰパケットフローを識別するための装置および方法により、ＴＣＰ／ＩＰプロトコルスィートインプリメンテーションから独立して、ＲＴＰが識別されるという効果がもたらされ、当該装置および方法は、ＴＣＰ／ＩＰプロトコルスィートをベースとする通信ネットワークにおいて有益である。
【図面の簡単な説明】
【００５７】
【図１】本発明の一の実施の形態に係るＲＴＰ識別装置を含む通信ネットワークの構成を示すブロック図
【図２】本発明の一の実施の形態に係るＲＴＰ識別装置の内部構成を示すブロック図
【図３Ａ】本発明の一の実施の形態に係るＲＴＰ識別装置内の動作例を説明するフローチャート
【図３Ｂ】本発明の一の実施の形態に係るＲＴＰ識別装置内の動作例を説明する別のフローチャート
【図４】本発明の一の実施の形態に係るＲＴＰ識別装置内での絶対条件を用いたチェック処理を説明するフローチャート
【図５】本発明の一の実施の形態に係るＲＴＰ識別装置内での相対条件を用いたチェック処理を説明するフローチャート
【図６】本発明の一の実施の形態に係るＲＴＰ識別装置内でのスコア取得処理を説明するフローチャート
【図７】本発明の一の実施の形態に係るＲＴＰ識別装置内での別のスコア取得処理を説明する図
【符号の説明】
【００５８】
１００  通信ネットワーク
１１０  ＲＴＰ識別装置
１１２  ＩＰパケットサンプリング部
１１４  ＲＴＰヘッダー検出部
１１６  通知部
１２０、１３０、１４０、１５０、１６０、１７０  ノード
１２２  ＩＰパケット処理部
【図１】
2005101743.tif 000006
【図２】
2005101743.tif 000007
【図３Ａ】
2005101743.tif 000008
【図３Ｂ】
2005101743.tif 000009
【図４】
2005101743.tif 000010
【図５】
2005101743.tif 000011
【図６】
2005101743.tif 000012
【図７】
2005101743.tif 000013
【外国語明細書】
2005101743000001.pdf