(57)【要約】【課題】トラヒック計測システムにおいて、無駄なフロー計測情報を転送せず、したがって計測用ネットワークのトラヒック量を不必要に増加させない。【解決手段】トラヒック情報送信機器１は、自機器の計測および処理可能な項目または対応する仕様に関する情報をトラヒック情報受信機器２に送信する。トラヒック情報受信機器２は、自機器のフロー処理機能に関して、トラヒック情報送信機器１のパケット処理機能との照合を行い、両機器に利用できる機能を抽出し、トラヒック情報送信機器に送信する。トラヒック情報送信機器１は、受信した、両機器に利用可能な機能情報に基づいた項目のみを利用したトラヒック情報をトラヒック情報受信機器２に送信する。【選択図】図１
2008211597.tif 000002
【特許請求の範囲】
【請求項１】
複数の端末を相互に接続するネットワーク上に配置され、該当ネットワークにおけるトラヒックを計測するために管理用ネットワークを介して接続されるトラヒック情報送信機器とトラヒック情報受信機器を有する通信システムにおけるトラヒック計測方法において、
前記トラヒック情報送信機器が、自機器の計測および処理可能な項目または対応する仕様に関する情報を前記トラヒック情報受信機器に送信するステップと、
前記トラヒック情報受信機器が、自機器のフロー処理機能に関して、前記トラヒック情報送信機器から送信された情報との照合を行い、両機器に利用できる機能を抽出し、前記トラヒック情報送信機器に送信するステップと、
前記トラヒック情報送信機器が、受信した、両機器に利用可能な機能情報に基づいた項目のみを利用したトラヒック情報を前記トラヒック情報受信機器に送信するステップと
を有すること特徴とするトラヒック計測方法。
【請求項２】
前記トラヒック情報受信機器が、両機器に利用できる機能を抽出するステップが、前記トラヒック情報送信機器から送信された情報に関して、該当する仕様情報から、予め登録された仕様情報に対応する項目を参照し、複数の仕様情報から同一の項目が重複参照された場合に、該当項目に対しては予め登録された仕様情報の分類において、同一分類の仕様情報から重複参照されている場合には論理和を用い、異なる分類の仕様情報から重複参照されている場合には論理積を用い、出力された処理項目の一覧に対して、自己の処理可能もしくは処理対象とするパケット属性情報に関連する項目に関しては論理積を用い、それ以外の項目に関しては論理和を用いて、前記トラヒック情報受信機器と前記トラヒック情報送信機器の両方に利用できる機能を抽出することを含む、請求項１に記載のトラヒック計測方法。
【請求項３】
複数の端末を相互に接続するネットワーク上に配置され、該ネットワークにおけるトラヒックを計測するために管理用ネットワークを介して接続されたトラヒック情報送信機器とトラヒック情報受信機器を有するトラヒック計測システムにおいて、
前記トラヒック情報送信機器は、自機器の計測および処理可能な項目に関する情報を前記トラヒック情報受信機器に送信する手段を有し、
前記トラヒック情報受信機器は自機器のフロー処理機能に関して、前記トラヒック情報送信機器から送信された情報との照合を行い、両機器に利用できる機能を抽出し、前記送信機器に送信する手段を有し、
前記トラヒック情報送信機器は、受信した、両機器に利用可能な機能に基づいた項目のみを利用したトラヒック情報を前記トラヒック情報受信機器に送信する手段を有する
ことを特徴とするトラヒック計測システム。
【請求項４】
複数の端末を相互に接続するネットワーク上に配置され、該ネットワークにおけるトラヒックを計測するために管理用ネットワークを介して接続されたトラヒック情報送信機器とトラヒック情報受信機器を有するトラヒック計測システムにおけるトラヒック情報送信機器において、
自機器の計測および処理可能な項目に関する情報を前記トラヒック情報受信機器に送信する手段と、
自機器と前記トラヒック情報受信機器の両機器に利用可能な機能に基づいた項目のみを前記トラヒック情報受信機器から受信し、該項目のみを利用したトラヒック情報を前記トラヒック情報受信機器に送信する手段と、
を有することを特徴とするトラヒック情報送信機器。
【請求項５】
自機器の計測および処理可能な項目に関する情報を前記トラヒック情報受信機器に送信する手段は、フローとして計測可能な項目の情報そのものか、または前記トラヒック情報送信機器内のパケット収集処理およびフロー情報化処理に関連する仕様・規格の情報として送信する、請求項４記載のトラヒック情報送信機器。
【請求項６】
自機器と前記トラヒック情報受信機器の両機器に利用可能な機能に基づいた項目のみを前記トラヒック情報受信機器から受信し、該項目のみを利用したトラヒック情報を前記トラヒック情報受信機器に送信する手段は、前記トラヒック情報受信機器から受信した、抽出された計測項目の中でパケット属性以外の計測項目に対して自機器の処理可能なパケット属性以外の計測項目との論理積計算を行い、該当する計測項目が存在しない場合に、通信を切断し、該当する計測項目が存在しない旨を画面またはネットワーク上の他の端末に対して出力する、請求項４または５に記載のトラヒック情報送信機器。
【請求項７】
複数の端末を相互に接続するネットワーク上に配置され、該ネットワークにおけるトラヒックを計測するために管理用ネットワークを介して接続されたトラヒック情報送信機器とトラヒック情報受信機器を有するトラヒック計測システムにおけるトラヒック情報受信機器において、
前記トラヒック情報送信機器から送信された、該トラヒック情報送信機器の計測および処理可能な項目に関する情報を受信し、自機器のフロー処理機能に関して、前記トラヒック情報送信機器からの情報との照合を行い、両機器に利用できる機能を抽出し、前記トラヒック情報送信機器に送信する手段を有することを特徴とするトラヒック情報受信機器。
【請求項８】
前記手段は、前記トラヒック情報送信機器から送信された計測および利用可能な項目と、自機器の処理可能な項目の論理積を計算して両機器に利用できる機能を抽出する、請求項７のトラヒック情報受信機器。
【請求項９】
前記手段は、前記送信機器から送信された、該送信機器のパケット処理可能な機能に関して、該当する仕様情報から、予め登録された仕様情報に対応する項目を参照し、複数の仕様情報から同一の項目が重複参照された場合に、該当項目に対しては予め登録された仕様情報の分類において、同一分類の仕様情報から重複参照されている場合には論理和を用い、異なる分類の仕様情報から重複参照されている場合には論理積を用い、出力された処理項目の一覧に対して、自己の処理可能もしくは処理対象とするパケット属性情報に関連する項目に関しては論理積を用い、それ以外の項目に関しては論理和を用いて、両機に利用できる機能を抽出する、請求項７または８に記載のトラヒック情報受信機器。
【請求項１０】
該当する計測項目がない場合に、通信を切断し、該当する計測項目が存在しない旨を画面またはネットワーク上の他の端末に対して出力する手段をさらに有する、請求項７から９のいずれかに記載のトラヒック情報受信機器。
【請求項１１】
複数のフロー情報のデータ構造を示した定義情報の共通部分と独立部分を分離し、個別に管理を行う手段を有する、請求項７から１０のいずれかに記載のトラヒック情報受信機器。
【請求項１２】
コンピュータを、請求項４から６のいずれかに記載のトラヒック情報送信機器の各手段として機能させるためのプログラム。
【請求項１３】
コンピュータを、請求項７から１１のいずれかに記載のトラヒック情報受信機器の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はインターネット、ＩＰネットワークなどの複数の端末を相互に接続するネットワーク上における複数の地点間の複数の通信サービスを計測する方法に関する。
【背景技術】
【０００２】
インターネットで使われるＩＰには、プロトコル、ソースＩＰアドレス、宛先ＩＰアドレスの情報が含まれ、また一部のトランスポートプロトコルにはソースポート、宛先ポートの情報が含まれる。トラヒック計測技術の中でこれらのパケットが持つ情報を元に通信の種別を分類する方法がフロー計測である。フロー計測では、同一のプロトコル、ソースＩＰアドレス、宛先ＩＰアドレス、ソースポート、宛先ポートなどの情報を持つパケットを同一の通信に属するパケットと見なす。同一の通信に属するパケットの集合をフローと呼ぶ。フローのデータ量やパケット量を計測することで、複数の地点間で複数の通信サービスを監視することができる。
【０００３】
インターネットではルータにより経路制御が行われ、送信元から送出されたパケットが複数のルータを経由することで送信先に到達する。ルータはパケットのＩＰヘッダや場合によってはトランスポートレイヤーのヘッダを参照するため、上述のフローの分類をする機器としては適している。ルータを通過したパケットのフロー情報を他の機器に通知する方法の例がＮｅｔＦｌｏｗ（非特許文献１参照）やＩＰＦＩＸ（ＩＰ  Ｆｌｏｗ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｅｘｐｏｒｔ）である。
【０００４】
これらの方法では、ルータなどのフロー情報送信機器は通過したパケットをフロー化した後、そのフローが持つ情報から、受信機器に対して送信する要素情報を任意に選択し、その要素情報の集合をパケット化して送信する。要素情報の一例は、ソースＩＰアドレスや宛先ポート等と言った、フロー情報を構成するために必要な一部の情報である。これらの情報には上述のプロトコルなどでは識別のための固有の番号が付与されており、本発明では以下この番号を要素情報番号と呼ぶ。
【０００５】
フロー情報送信機器が利用する要素情報の選択方式は２方式あり、要素情報の選択項目と並び方が常に一定である送信情報固定方式と、送信機器の利用者からの入力された設定などによって変更できる送信情報自由選択方式がある。既存のプロトコルで送信情報自由選択方式を採用しているのはＮｅｔＦｌｏｗのＶｅｒｓｉｏｎ９以降、ＩＰＦＩＸである。
【０００６】
送信情報自由選択方式の場合、計測されたフロー情報とそのフロー情報のデータ構造を定義する（ＩＰＦＩＸプロトコル用語でテンプレートと呼ばれる）データ構造定義情報を送信機器は送信する。データ構造定義情報は（ＩＰＦＩＸプロトコル用語で要素情報と呼ばれる）要素情報の集合である。
【０００７】
同一の要素情報の集合を利用しても、その順序が異なる場合異なるデータ構造定義情報となる。また、同一のフロー情報の送信においても、異なるデータ構造定義情報を利用すると、異なるデータ列になる。
【０００８】
受信機器は、異なったデータ構造定義情報を利用した同一のフロー情報から生成された異なったデータ列に対して、それぞれ異なったデコード処理を要求される。また、異なるデータ構造定義情報はそれぞれ個別に保持しなければならないため、送信情報固定方式と比較して、処理効率の面、計算機資源量利用効率の面において劣る場合が発生する。
【０００９】
また、非特許文献２によると一例としてＩＰＦＩＸにおける要素情報は１６７種類にわたり、この中では表す情報の意味が同じだが、単位や表し方が異なる情報などが存在する。例えば時間を示す情報は、秒、ミリ秒、マイクロ秒、ナノ秒の要素情報が存在する。
【００１０】
したがって、単一のフロー情報の伝達のために生成されるデータ構造定義情報は単位の選択も含めると、多数の組合せの可能性が存在する。また、一部の要素情報では、サイズを状況に応じて変更することができる。したがって、データ構造定義情報次第では同一の要素情報でもサイズが異なる場合がある。
【００１１】
一方、非特許文献３によると、送信情報自由選択方式において、要素情報の順序を何らかの方法で一定化した場合、生成される可能性のあるテンプレート数を抑制し、処理対象とする要素情報の数を減らすことができることが述べられている。また、非特許文献４では、その一定化されたデータアライメントを意識している順序の一例が示されている。この例では、固定長の要素情報、サイズ変更可能な要素情報、可変長の要素情報に分類しており、同一の要素情報の組を利用した場合に、どのテンプレートでも固定長の要素情報の集合の部分が一意に決まり同一になる。
【非特許文献１】［平成１８年１２月２６日閲覧  インターネット］http://www.ietf.org/rfc/rfc3954.txt
【非特許文献２】［平成１８年１２月２６日閲覧  インターネット］Quittek, J., Bryant, S., Claise, B., and J. Meyer, "Information Model for IP Flow Information Export"（特に５，９章）http://www.ietf.org/internet-drafts/draft-ietf-ipfix-info-14.txt
【非特許文献３】入野  仁志，片山  勝，“フロー情報コレクタ省資源化のためのフロー情報送信方法の提案”，電子情報通信学会  ソサイエティ大会（２００６）ＢＳ−４−３
【非特許文献４】［平成１８年１２月２６日閲覧  インターネット］H. Irino, "Order of Information Elements"http://tools.ietf.org/wg/ipfix/draft-irino-ipfix-ie-order-00.txt
【発明の開示】
【発明が解決しようとする課題】
【００１２】
送信情報自由選択方式を採用しているプロトコルでは、どの要素情報を利用するかの選択は送信機器に依存している。しかし、受信機器はそれら全ての要素情報を解釈できない可能性がある。したがって、送信機器が送信しても解釈できない場合が存在する。この場合、無駄なフロー計測情報を生成し転送していることになり、計測用ネットワークのトラヒック量を不必要に増加させ、送信機器、受信機器の不必要な処理を発生させる。
【００１３】
一方、要素情報の順序の決定において、従来技術の順序の一定化によって生成の可能性のあるデータ構造定義情報の数が抑制される。しかし、同一の要素情報の組を利用しない場合はその限りでなく、同一の要素情報を利用するかは送信機器のみに依存している。
【００１４】
本発明の目的は、無駄なフロー計測情報を転送せず、したがって計測用ネットワークのトラヒック量を不必要に増加させ、送信機器、受信機器の不必要な処理を発生させることがないトラヒック計測方法、システム、トラヒック情報受信機器、トラヒック情報送信機器、およびプログラムを提供することにある。
【課題を解決するための手段】
【００１５】
本発明のトラヒック計測システムは、トラヒック情報送信機器は、自機器の計測および処理可能な項目に関する情報を前記トラヒック情報受信機器に送信する手段を有し、トラヒック情報受信機器は自機器のフロー処理機能に関して、トラヒック情報送信機器から送信された情報との照合を行い、両機器に利用できる機能を抽出し、前記送信機器に送信する手段を有し、トラヒック情報送信機器は、受信した、両機器に利用可能な機能に基づいた項目のみを利用したトラヒック情報をトラヒック情報受信機器に送信する手段を有する。
【００１６】
フロー計測情報の送信では、要素情報は、大きく分類すると、フロー計測情報の送信機器を通過したパケットから取得できる要素情報（ＩＰＦＩＸプロトコル用語でフローキーにあたるインフォメーションエレメントとパケットから取得した値の最小値最大値などの統計情報を表すインフォメーションエレメント）と、パケット量、バイト量といったカウンタ型の要素情報、計測されたフローの開始時間と終了時間を表す要素情報、それ以外の雑多な要素情報に分かれる。
【００１７】
これらの分類のうち、パケットから取得できる要素情報は送信機器が該当する仕様に準拠していなければ、利用できない。例えばＲＦＣ２４６０“Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ，  Ｖｅｒｓｉｏｎ  ６  （ＩＰｖ６）  Ｓｐｅｃｉｆｉｃａｔｉｏｎ”に準拠していないフロー情報送信機器はＩＰｖ６のパケットを取り扱えないためＩＰｖ６に関する要素情報は送信できない。また、例えば、ＲＦＣ７９１“ＩＮＴＥＲＮＥＴ  ＰＲＯＴＯＣＯＬ”、ＲＦＣ２４６０に準拠、対応していてＲＦＣ２６７５“ＩＰｖ６  Ｊｕｍｂｏｒａｍｓ”に準拠および対応していないフロー情報送信機器においてはＩＰペイロードのサイズは必ず１６ビットとなる。フロー計測情報送信機器はパケットを扱う必要がありその際に、準拠している規格、仕様によって取り扱うことのできる要素情報や場合によってはそのサイズが決定される。
【００１８】
以上の特徴から、フロー情報の送信機器から、準拠している仕様（ＲＦＣや、ＩＥＥＥ等の標準規格）と送信機器の実装に関する情報を受信機器に通知する。これによって、送信機器が送信可能とする要素情報を受信機器で判断できる。その情報を受け取った受信機器は、その通知と自分の解析可能な要素情報と照合し、送信機器が通知可能な要素情報の中で解析可能な要素情報を判別する。判別した要素情報の番号を再度、送信機器に送信する。通知を受信した送信機器は、受信された要素情報の中から、送信情報に用いる要素情報を選択し、一定の順序に基づいて、データ構造定義情報を生成および送信し、その後、対応した形式で観測されたフロー計測情報を送信する。
【００１９】
さらに、準拠している仕様の通知を行うことで、サイズが一意に決定することのできるサイズ変更可能な要素情報が存在するため、それらの要素情報を固定長の要素情報として利用することで、サイズ変更可能な要素情報の数が減少する。その結果複数のデータ構造定義情報における共通部分が増加する。共通部分を共通の記憶領域に配置し、共通の処理過程で処理することで、記憶領域の節約と高速化が可能になる。特に共通部分をＣＰＵのキャッシュなど、高速なメモリ空間に配置すると、より高速化できる。
【発明の効果】
【００２０】
利用可能な要素情報の交換が送受信機器間で自律的に行われる。
【００２１】
フロー情報の送信機器が送出可能、受信機器が解釈可能な要素情報から成るフロー情報しか生成されないため、転送するデータに無駄が発生しない。また、送信機器、受信機器の処理にも無駄が発生しない。よって、計測用ネットワークにおいてより多いフロー情報を転送と処理が可能になる。もしくは各送信機器が出力するフロー情報量が一定の場合は、単一の受信機器で従来より多くの送信機器を監視することができる。
【００２２】
また、一定の順序と組み合わすことで、フロー情報の一部分は受信機器において記録時や受信パケットの検索時にデータ位置の調整のためのメモリ上のコピーが不要になる。
【００２３】
本方式でサイズ変更可能な要素情報の数が減少する。その結果複数のデータ構造定義情報における共通部分が増加する。受信機器において共通部分を共通の記憶領域に配置し、共通の処理過程で処理することで、記憶領域の節約と高速化が可能になる。特に、共通部分をＣＰＵのキャッシュなど、高速なメモリ空間に配置すると、より高速化できる。
【発明を実施するための最良の形態】
【００２４】
次に、本発明の実施の形態について図面を参照して説明する。
【００２５】
図１は本発明の一実施形態によるトラヒック計測システムの構成図である。
【００２６】
本実施形態によるトラヒック計測システムは、ネットワーク１上に配置されたトラヒック情報送信機器（以下、単に送信機器と称す）１と、管理用ネットワーク４を介して送信機機器１に接続されるトラヒック情報受信機器（以下、単に受信機器と称す）２とを有している。
【００２７】
本実施形態では、フロー情報が、ネットワーク１上のルータなどのパケット転送装置である送信機器１から、ＩＰＦＩＸをはじめとした送信情報自由選択方式のプロトコルを用いて管理用の受信機器２に送信される。
【００２８】
図２は送信機１と受信機器２のブロック図である。
【００２９】
送信機器１は、ＳＮＭＰのＳＥＴリクエスト等に代表される設定情報要求を受け付ける設定情報受信部１１と、設定情報受信部１１で受信された情報の中で後述する受信機器２が処理可能な情報を蓄積する受信機器処理可能情報蓄積部１２と、パケット収集部１６で収集されたパケットのうちフローとして集計処理することが可能な情報要素の情報を予め蓄積する送信機器処理可能情報蓄積部１３と、受信機器処理可能情報蓄積部１２に蓄積されている情報と送信機器処理可能情報蓄積部１３に格納されている情報を比較し、トラヒック情報を送信する際に、後述する算出方法によって算出された利用可能な情報要素を参照するための情報を格納する利用可能情報蓄積部１５の情報を更新する比較・情報更新部１４と、計測対象となるネットワークからパケットを収集するパケット収集部１６と、トラヒック情報そのもの以外の付加的な情報であるオプション情報を蓄積するオプション情報蓄積部１７と、トラヒック情報作成・送信部１８を有し、トラヒック情報作成・送信部１８は、トラヒック情報を作成するトラヒック情報作成部１８Ａと、オプション情報を作成するオプション情報作成部１８Ｂと、トラヒック情報およびオプション情報を送信する送信部１８Ｃを有している。
【００３０】
受信機器２は、送信機器１から送信されたトラヒック情報およびオプション情報を受信し、処理するトラヒック情報受信・処理部２１と、その処理した情報の中で送信機器１が計測可能な情報を蓄積する送信機器計測可能情報蓄積部２２と、受信機器２が処理できる情報要素の情報を予め蓄積する受信機器計測可能情報蓄積部２３と、送信機器計測可能情報蓄積部２２と受信機器計測可能情報蓄積部２３の情報を元に、送信機器１と受信機器２の間で利用することのできる情報要素を算出する比較部２４と、比較部２４で算出された情報をＳＮＭＰのＳＥＴリクエスト等に代表される設定情報要求として送信する設定情報送信部２５を有し、トラヒック情報受信・処理部２１は、情報を受信する受信部２１Ａと、受信部２１Ａで受信した情報の中で付加的な情報であるオプション情報を処理するオプション情報処理部２１Ｂと、送信機器１が計測可能な送信機器計測可能情報以外の付加情報であるオプション情報を蓄積するオプション情報蓄積部２１Ｃと、受信部２１Ａで受信した情報の中でトラヒック情報を処理するトラヒック情報処理部２１Ｄと、処理されたトラヒック情報を蓄積するトラヒック情報蓄積部２１Ｅとを有している。
【００３１】
以下、フロー計測情報通知プロトコルにＩＰＦＩＸを用いた場合を例として、本実施形態の動作を説明する。
【００３２】
本実施形態では（ＩＰＦＩＸプロトコルではエクスポータと呼ばれる）送信機器１からオプションテンプレートによって、対応している規格／仕様を示し、（ＩＰＦＩＸプロトコルではコレクタと呼ばれる）受信機器２から送信機器１に対してＳＮＭＰのＳＥＴリクエストを用いて受信可能な要素情報を通知する。
【００３３】
ＩＰＦＩＸではオプションテンプレートおよびオプションデータレコードと呼ばれる付加的な情報を転送するためのデータ構造定義情報とその構造情報に基づいたデータの送信が可能である。
【００３４】
フロー情報の送信機器１は、このオプションテンプレートおよびオプションデータレコードの仕組みを用いて、最初に受信機器２に対して、計測パケット処理機能情報蓄積部１３に格納されている情報をオプション情報作成部１８Ｂでパケット化し、送信部１８Ｃを介して、送信機器１が準拠している仕様を通知する。
【００３５】
図３に送信機器１が準拠している仕様を受信機器２に通知するためのＩＰＦＩＸオプションプレートのパケットの一例を示す。ここでは、独自定義のｃａｐａｂｉｌｉｔｙＮｏｔｉｆｉｃａｔｉｏｎという情報要素を用いている。図４に送信機器１が準拠している仕様を受信機器２に通知するためのオプション情報の一例を示す。図４で示したオプション情報は図３のｃａｐａｂｉｌｉｔｙＮｏｔｉｆｉｃａｔｉｏｎのデータ構造である。
【００３６】
図４の例では、この要素情報はビット列として構成されており、１ビットごとに異なった意味を持ち、値が１の場合にその仕様に準拠していることを指す。この例は３２ビットの情報である。図中の数字は、仕様を示す番号である（値を示しているわけではない。値は０か１である）。この例において先頭から２４ビットの情報は値が０の場合無効、値が１の場合有効として受信機器２側で解釈される。２５ビットのＯＲＤはある特定の順序を用いるか用いないかを示す順序のポリシー、２６，２７ビット目のＩＭＰは要素情報のサイズ決定に関する実装ポリシーを示している。例えば要素情報番号３１番のｆｌｏｗＬａｂｅｌＩＰｖ６は２０ビットで表現できる情報だが、ＩＰＦＩＸの定義では４バイトで定義されており、プロトコルの定義に基づいて３バイトに変更可能である。ＩＭＰが１の場合は常に最小値をとることとし、例としてｆｌｏｗＬａｂｅｌＩＰｖ６のサイズは常に３バイトとなり常に最大値をとることとし、例として、ＩＭＰが２の場合ｆｌｏｗＬａｂｅｌＩＰｖ６のサイズは常に４バイトとなり、０の場合はデータ構造定義情報毎に個別に設定する（通常のＩＰＦＩＸ処理）こととする。ＩＭＰが１の場合、有効範囲は適用されるのはパケットから取得できる要素情報のみで、その他の要素情報（カウンタ型、時間型）には適用されない。
【００３７】
なお、送信機器１は受信機器２に対して図４の代わりに図５のように、利用可能な要素情報ビット列を送っても構わない。ただし、同じ目的の情報を送信するのに図５では２５６ビット分必要とするのに対し、図４では３２ビットで済むため、図４の方式のほうが少ないデータ量で同等の情報を送信できる。
【００３８】
受信機器２は、オプション情報処理部２１Ｂで処理され、送信機器計測可能情報蓄積部２２に蓄積された利用可能な情報要素の情報と、受信機器処理可能情報蓄積部２３に予め蓄積されている利用可能な情報要素の情報とを比較部２４で後述する比較方法で比較し、最終的に生成された利用可能な要素情報ビット列を、設定情報送信部２５を介してＳＮＭＰのＳＥＴリクエスト等を用いて設定する。一般に、送信機器１となるルータは機器の情報を取得したり、設定したりするためにＳＮＭＰを用いることが多く、ＳＮＭＰの機能を具備しているため、この例ではＳＮＭＰを用いて情報の設定を行う。しかし他の設定方法があればその方法を利用してよい。
【００３９】
図５に設定情報送信部２５から送信され、設定情報受信部１１で受信される設定情報要求のビット列の例を示す。図５に示した設定情報要求のビット列をＳＮＭＰのＳＥＴリクエストとして送信した場合、３２バイトのＳＭＩｖ２  ＯＣＴＥＴ  ＳＴＲＩＮＧを用いる。２５６ビット中に１〜２５４番までの要素情報を埋め込む。この値が１の場合はその要素情報が利用できることを示す。また、最終２ビットにはサイズに関係する仕様として、（ＲＦＣ）２６７５と（Ｉ-Ｄ）４Ｂ-ＡＳの情報を示す。この値が１の場合は関係する要素情報はその仕様に準じたサイズを利用可能であることを示す。なお、図５の代わりに図４で示した形式で送信しても構わない。しかし、図４で示したデータ構造で送信した場合は、受信機器２で、図４で示したデータ構造へのデータ変換が発生し、また送信機器１で、利用可能な要素情報を算出する再計算が必要となる。
【００４０】
オプション情報処理部２１Ｂで行う、受信部２１Ａから受け取った、図４で示したデータ構造を用いるデータから利用可能な要素情報番号を算出する判断処理を図６に示す。二重線は有効であることを示す。「Ｌ３」は第３層、すなわちネットワーク層、「Ｌ４」は第４層、すなわちトランスポート層、「ＴＯＳ」はＴｙｐｅ  ｏｆ  Ｓｅｒｖｉｃｅの略、「ＢＧＰ」は経路制御プロトコルのＢＧＰ（Ｂｏｒｄｅｒ  Ｇａｔｅｗａｙ  Ｐｒｏｔｏｃｏｌ）である。「Ｓｉｚｅ」はＩＰＦＩＸに要素情報のデータサイズに関係・影響する可能性があることを示している。受信機器２は内部的に仕様を分類して、その情報をオプション情報処理部２１Ｂに保持している（図６上段）。また、各仕様と関係のある要素情報番号の数字配列を持ち、同様にその情報をオプション情報処理部２１Ｂに保持している（図６中段）。複数の数字配列で同じ要素情報番号を持つ場合、それが図６上段の分類で同一分類に属する場合は、論理和（ＯＲ）で計算され、異なる分類に属する場合は論理積（ＡＮＤ）で計算される。
【００４１】
受信機器２は送信機器１から図４の形式で仕様（ＲＦＣ等）の番号の情報を受け取った後、図６の中段に記載されている、仕様の番号と対応するＩＰＦＩＸの要素情報番号の数字配列を参照する。図６では、ＲＦＣ７９１（ＩＰｖ４）と関係する要素情報番号として、４，５，８，９，１２，１３，１８，４７，（途中略），２２４としている。一方で、ＲＦＣ２４６０（ＩＰｖ６）と関係する要素情報番号は、４,５,２７,２８,２９,３０，３１，５４，５５，６３，（途中略），２２４としている。これらは内部的には最終的に図５のようなビットマップにマッピングされることになる。ＲＦＣ７９１（ＩＰｖ４）が有効な場合、４，５，８，９，１２，１３，１８，４７，（途中略），２２４ビット目は１（有効）になっており、それ以外のビットは０（無効）になっている。この最終結果のビットマップに対して次々に各仕様の数字配列の番号と一致するビット位置において１ビットずつ論理和または論理積を行なう。基本的に論理和を行い、論理積の対象となるのは、同一の要素が異なる分類に跨っている場合である。
【００４２】
０ビット目の７９１が１で、１ビット目の２４６０が０だった場合、ＩＰｖ４に関係する全ての要素情報が利用できるが、ＩＰｖ６に関係する全ての要素情報が利用できないと解釈される。この場合、ＲＦＣ７９１（ＩＰｖ４）と関係する要素情報番号である、４，５，８，９，１２，１３，１８，４７，（途中略），２２４が有効になる（ただし、他の分類に属している仕様（図４において、３〜２４ビット目）が全て１（有効）の状態の場合）。ＩＰｖ４，ＩＰｖ６共通に関係する要素情報、例えばＩＰＦＩＸ要素情報４番：ｐｒｏｔｏｃｏｌｉｄｅｎｔｉｆｉｅｒ、５番：ｉｐＴＴＬ、はこの場合論理和で１となり、有効として解釈される（図６下段）。そして、論理積は、異なる分類に同一の要素情報番号が存在した場合にその要素情報番号にのみ適用される。例えば、図４の０ビット目の（ＲＦＣ）７９１が１で、１ビット目の（ＲＦＣ）２４６０が０で、１８ビット目の（ＲＦＣ）１７７１が１だった場合、（ＲＦＣ）７９１と（ＲＦＣ）１７７１の両方に属するＩＰＩＦＩＸ要素情報１８番：ｂｇｐＮｅｘｔＨｏｐＩＰｖ４Ａｄｄｒｅｓｓは論理積で１となり、有効として解釈されるが、（ＲＦＣ）２４６０と（ＲＦＣ）１７７１の両方に属する６３番：ｂｇｐＮｅｘｔＨｏｐＩＰｖ６Ａｄｄｒｅｓｓは論理積で０となり、有効でないとして解釈される（図６下段左）。
【００４３】
ただし、図６上段のＳＩＺＥは例外となる。該当する要素情報のサイズを変更する。例として４Ｂ−ＡＳは４バイトＡＳ番号の利用可否を示している。現在使われているＡＳ番号は２バイトで表現できる番号が枯渇する懸念があり、４バイトに拡張する提案（ＢＧＰ  Ｓｕｐｐｏｒｔ  ｆｏｒ  Ｆｏｕｒ−ｏｃｔｅｔ  ＡＳ  Ｎｕｍｂｅｒ  Ｓｐａｃｅ）がなされている。ＩＰＦＩＸの要素情報も４バイトとして定義されている。しかし、送信機器１において４バイトＡＳ番号に対応していなければ、ＡＳ番号の表現は２バイトとして考えてよいことになる。したがって、図６で４バイトＡＳ番号に対応しているか否かを示している４Ｂ−ＡＳが１（有効）の場合は、ＡＳ番号に関係する１６，１７，１２８，１２９番の要素情報は４バイトとして解釈され、４Ｂ−ＡＳが０（無効）の場合は、ＡＳ番号に関係する１６，１７，１２８，１２９番の要素情報は２バイトとして解釈される。
【００４４】
要素情報はパケットのヘッダ情報から導出できる情報と、データ量や時間などのそれ以外の情報の２種類に分類することができる。送信機器１が計測可能な要素情報ビット列は前者のパケットのヘッダ情報から導出される情報である。
【００４５】
受信機機器２が処理可能な要素情報に関しては受信機器処理可能情報蓄積部２３で予め図５のデータ構造でヘッダ情報から導出した情報とそれ以外の情報との２種類のデータを保持する。受信機器２が処理可能な要素情報は明示的に利用者が受信機器２の制限内で限定しても構わない。
【００４６】
一方、オプション情報処理部２１Ｂで算出された送信機器計測可能情報処理部２２に蓄積される要素情報ビット列は、パケットのヘッダ情報から導出される情報のみとなる。したがって、比較部２４では、送信機器計測可能情報処理部２２内の要素情報ビット列と受信機器処理可能情報蓄積部２３内のヘッダ情報から導出した情報の要素情報ビット列とで論理積を行い、次にその結果と受信機器処理可能情報蓄積部２３内のそれ以外の情報の要素情報ビット列とで論理和を行う。そして最終的な結果を、設定情報送信部２５を介して送信する。この情報は送信機器１の設定情報受信部１１で受信され、受信機器処理可能情報蓄積部１２で保持される。
【００４７】
送信機器処理可能情報蓄積部１３は、先に送信した図４のデータ構造で持つ仕様に関する情報以外に、図５のデータ構造でヘッダ情報から導出されないそれ以外の情報の要素情報ビット列を予め別途保持しており、設定情報受信部１１を介して受信機器処理可能情報蓄積部１２で保持した要素情報ビット列と送信機器処理可能情報蓄積部１３で予め保持していた要素情報ビット列の論理積を比較・情報更新部１４で計算する。この結果を利用可能情報蓄積部１５に保持して、それ以後のトラヒック情報作成部１８Ａは利用可能情報蓄積部１５に保持された情報を参照してフロー情報を作成する。
【００４８】
この方法により受信機器２内の比較部２４で論理積を求めた際に、該当する要素情報が無く計測不可になった場合は、フロー情報通知のための通信を受信機器２内の受信部２１Ａで切断して、エラーメッセージなどの障害を示す出力を行えばよい。送信機器１の場合も同様であり、比較・情報更新部１４で論理積を求めた際に該当する要素情報が無く、計測不可になった場合は送信部１８Ｃで同様の処理を行えばよい。
【００４９】
本方法により、送信機器１と受信機器２の利用する要素情報が自動的に選択される。受信機器１での利用可能な要素情報のみを利用するため、無駄な情報転送が発生しない。
【００５０】
さらに、受信機器２において計測対象とする要素情報に対して、あらかじめ一定の順序に基づいてデータ構造を作成することで、処理の簡略化が可能になる。一例を図７に示す。図７は、受信機器２においてトラヒック情報処理部２１Ｅからトラヒック情報蓄積部２１Ｄに対して情報を蓄積する処理を示している。要素情報の選択方式がない従来の方法だと受信機器２で処理できない要素情報が含まれる可能性があるため、図７左に示すとおり、受信バッファから必要な部分を抽出してから記憶装置に書き込む必要がある。分割された部分の数だけメモリ上のコピーが発生する一方、本発明は受信機器２が処理できる要素情報のみが送信されるため、図７右に示すとおり必要となる部分が分割されることがない。
【００５１】
また、パケットから取得できる情報は検索条件にも利用できる。例えば、ソースアドレス、宛先アドレス、ソースポート、宛先ポート、プロトコルの条件でフローが計測され、送信機器から送信された情報のうち特定のソースアドレスと宛先アドレスのみを処理対象としたい場合（ホワイトリスト、ブラックリスト形式）、図７左の従来方法では必ず一時バッファが必要となるが、図７右の本発明では一時バッファが必要なくなり、メモリ使用量の低減化と、処理過程の省略による高速化が図れる。
【００５２】
図１に示すとおり、管理用受信機器１台に対して２台以上のパケット転送装置からフロー情報は送信されることが一般的であり、その場合に、本発明の方法と順序の一定化により、複数台において、共通のデータ構造定義情報が生成されるか、完全に共通のデータ構造定義情報が生成されないとしても、パケットから取得できる要素情報の部分は完全に同一になる。
【００５３】
データ構造定義情報の一部または完全に同一の場合、同一性を意識した方法で定義情報を管理することによりメモリ節約が可能になる。従来（図８左）は、定義情報は個別に管理していた。データ構造の定義情報において、送信機器の識別子と定義情報の識別子の組に対して、単一の定義情報のデータ列（要素情報の番号とそのサイズの配列）を保持する。一方、本発明（図８右）は、送信機器から与えられた送信機器の識別子と定義情報の識別子の組に対して内部的な定義情報の識別子を付与し、その内部定義情報の識別子に対して定義情報のデータ列を保持する。この例ではＡとＢの２種類の定義情報が単一のものとして管理できる。定義情報の管理において、識別子情報よりも定義情報のデータ列の方がデータ量が大きいので、管理する全体のデータ量は削減できる。一部のみが同一の場合は共通部分を分離して共通部分を内部定義情報と関連付けて管理し、個別部分は送信機器識別子と関連付けて管理すればよい。この共通部分の分離は、使用する一定の順序において、パケットから取得できる情報を特定の位置に配置する（例えばパケットの先頭から配置する）ことを決めておくことで、容易に分離できる。
【００５４】
なお、送信機器１、受信機器２の機能は、その機能を実現するためのプログラムを、コンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませ、実行するものであってもよい。コンピュータ読み取り可能な記録媒体とは、フレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ等の記録媒体、コンピュータシステムに内蔵されるハードディスク装置等の記憶装置を指す。さらに、コンピュータ読み取り可能な記録媒体は、インターネットを介してプログラムを送信する場合のように、短時間、動的にプログラムを保持するもの（伝送媒体もしくは伝送波）、その場合のサーバとなるコンピュータ内の揮発性メモリのように、一定時間プログラムを保持しているものを含む。
【図面の簡単な説明】
【００５５】
【図１】本発明の一実施形態によるトラヒック計測システムの構成図である。
【図２】図１中の送信機１と受信機器２のブロック図である。
【図３】送信機器１が準拠している仕様を受信機器２に通知するためのパケットの一例を示す図である。
【図４】送信機器１が準拠している仕様を受信機器２に通知するためのオプション情報の一例を示す図である。
【図５】ＳＮＭＰを用いて利用可能な要素情報ビット列を示す図である。
【図６】利用可能な要素情報番号の判断処理の一例を示す図である。
【図７】本発明の効果を従来技術の効果と比較して示す図である。
【図８】本発明の効果を従来技術の効果と比較して示す図である。
【符号の説明】
【００５６】
１      送信機器
２      受信機器
３      ネットワーク
４      管理ネットワーク
１１    設定情報受信部
１２    受信機器処理可能情報蓄積部
１３    送信機器処理可能情報蓄積部
１４      比較情報更新部
１５      利用可能情報蓄積部
１６      パケット収集部
１７      オプション情報蓄積部
１８      トラヒック情報作成・送信部
１８Ａ    トラヒック情報作成部
１８Ｂ    オプション情報作成部
１８Ｃ    送信部
２１      トラヒック情報受信・処理部
２１Ａ    受信部
２１Ｂ    オプション情報処理部
２１Ｃ    オプション情報蓄積部
２１Ｄ    トラヒック情報処理部
２１Ｅ    トラヒック情報蓄積部
２２      送信機器計測可能情報蓄積部
２３      受信機器計測可能情報蓄積部
２４      比較部
２５      設定情報送信部
【図１】
2008211597.tif 000003
【図２】
2008211597.tif 000004
【図３】
2008211597.tif 000005
【図４】
2008211597.tif 000006
【図５】
2008211597.tif 000007
【図６】
2008211597.tif 000008
【図７】
2008211597.tif 000009
【図８】
2008211597.tif 000010