JPH11136249A - ホスト間トラフィック情報の編集方法 - Google Patents

Abstract

(57)【要約】 【課題】 これから書き込もうとする新規ホストが既に
記憶領域に存在するかどうかを高速に検索可能であると
ともに、無駄な記憶領域の確保を省くことにより記憶領
域の使用効率を向上するホスト間トラフィック情報の編
集方法を提供する。 【解決手段】 ネットワーク接続装置が接続するセグメ
ント上で検出したパケットを基に収集したトラフィック
情報を、送信元ホストと送信先ホストと併せて、送信元
ホストまたは送信先ホスト毎に連続して確保された記憶
領域に格納するホスト間トラフィック情報の編集方法に
おいて、予め通信相手の多いホストを記憶しておき、登
録しようとする新規ホストが通信相手の多いホストとし
て記憶されたホストである場合、通常確保される連続し
た記憶領域より多くの連続する記憶領域を確保し、そこ
に新規ホストに関するトラフィック情報を格納するよう
にした。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワーク接続
装置が接続するセグメント上で検出したパケットを基に
収集するホスト間トラフィック情報の編集方法に関する
ものである。

【０００２】

【従来の技術】インターネットプロトコルの標準化に取
り組むIETF（Internet Engineering Task Force、イン
ターネット技術標準化委員会）は、ＭＡＣレイヤーレベ
ルでモニタすべき情報についてRFC1757と呼ばれるドキ
ュメントとして公告している。このRFC1757によると、
ネットワーク接続装置は、ホスト−ホスト間のＭＡＣレ
イヤーレベルのトラフィック情報として、Matrix Group
を実行することになっている。

【０００３】このMatrix Groupは、送信元ホスト−送信
先ホストの組み合わせ毎の「全通信パケット数」、「全
通信オクテット数」、「通信エラーパケット数」を、イ
ンターフェースポート毎に収集することを定義してい
る。

【０００４】送信元ホスト−送信先ホストの組み合わせ
毎の「全通信パケット数」、「全通信オクテット数」、
「通信エラーパケット数」をトラフィックテーブルと呼
ばれる記憶領域に、送信元ホスト−送信先ホストの組み
合わせ毎にエントリとして書き込みを行う場合、これか
ら書き込もうとする送信元ホスト−送信先ホストの組み
合わせが既にトラフィックテーブルに存在するかどうか
を検索するエントリ検索を行う必要がある。その際、エ
ントリ検索は、トラフィックテーブルに既に格納されて
いる全てのエントリを対象に行われることになるが、ホ
ストの数が増加すればするほど検索対象となるエントリ
数が増加するため、できるだけ高速に検索できることが
望ましい。そこで、同じ送信元ホスト（若しくは同じ送
信先ホスト）についてのエントリを連続的にトラフィッ
クテーブルに保持するようにしておき、まず送信元ホス
ト（若しくは送信先ホスト）が書き込まれている領域を
確定した後に、その確定した領域の中から送信先ホスト
（若しくは送信元ホスト）を検索するという手続を行う
ことで少しでも検索に要する時間を低減することが可能
となる。

【０００５】

【発明が解決しようとする課題】ところが、従来のホス
ト間トラフィック情報の編集方法では、送信元ホスト
（若しくは送信先ホスト）毎にエントリを連続して保持
できるように、単に全ての送信元ホスト（若しくは送信
先ホスト）に対して予め決められた数のエントリ数分の
記憶領域を確保している。すなわち、従来のホスト間ト
ラフィック情報の編集方法では、通信相手の多いサーバ
等のホストや通信相手が極めて少ないホストといった違
いによらず、一律に同数のエントリ数を有する記憶領域
を各ホストに割り当てている。

【０００６】従って、例えば、サーバ等の通信相手の多
いホストに鑑みて各ホストに多くの記憶領域を割り当て
た場合、通信相手の少ないホストにとっては使用されな
いエントリが発生することになり、記憶領域の資源に無
駄が生じ利用効率が悪化するという問題点を有してい
る。逆に、通信相手が極めて少ないホストに鑑みて各ホ
ストに少ない記憶領域を割り当てた場合、通信相手の多
いホストのトラフィック情報を書き込めなくなるという
問題点を有していた。

【０００７】本発明は、上記の問題点に鑑みて成された
ものであり、その目的とするところは、これから書き込
もうとする新規ホストが既に記憶領域に存在するかどう
かを高速に検索可能であるとともに、無駄な記憶領域の
確保を省くことにより記憶領域の使用効率を向上するホ
スト間トラフィック情報の編集方法を提供することにあ
る。

【０００８】

【課題を解決するための手段】請求項１記載の発明は、
ネットワーク接続装置が接続するセグメント上で検出し
たパケットを基に収集したトラフィック情報を、送信元
ホストと送信先ホストと併せて、送信元ホストまたは送
信先ホスト毎に連続して確保された記憶領域に格納する
ホスト間トラフィック情報の編集方法において、予め通
信相手の多いホストを記憶しておき、登録しようとする
新規ホストが通信相手の多いホストとして記憶されたホ
ストである場合、通常確保される連続した記憶領域より
多くの連続する記憶領域を確保し、そこに新規ホストに
関するトラフィック情報を格納するようにしたことを特
徴とするものである。

【０００９】請求項２記載の発明は、ネットワーク接続
装置が接続するセグメント上で検出したパケットを基に
収集したトラフィック情報を、送信元ホストと送信先ホ
ストと併せて、送信元ホストまたは送信先ホスト毎に連
続して確保された記憶領域に格納するホスト間トラフィ
ック情報の編集方法において、登録しようとする新規ホ
ストが、既に確保されている既存の記憶領域に格納でき
ない場合、新たに連続する記憶領域に確保し、そこに新
規ホストに関するトラフィック情報を格納するととも
に、新たに記憶領域を確保した旨を記憶するようにした
ことを特徴とするものである。

【００１０】

【発明の実施の形態】以下、本発明の一実施の形態につ
いて図１乃至図６に基づき詳細に説明する。図１は第１
の実施の形態に係るホスト間トラフィックの編集方法の
フローチャートである。図２は第２の実施の形態に係る
ホスト間トラフィックの編集方法のフローチャートであ
る。図３はアドレステーブルである。図４は第１の実施
の形態に係るトラフィックテーブルである。図５は第２
の実施の形態に係るトラフィックテーブルである。図６
は第２の実施の形態に係る共通メモリプールである。

【００１１】［第１の実施の形態］送信元ホスト−送信
先ホストの組み合わせ毎の「全通信パケット数」、「全
通信オクテット数」、「通信エラーパケット数」といっ
たトラフィック情報は、ブリッジやスイッチ等の中継装
置に、送信元ホスト−送信先ホストの組み合わせ毎にエ
ントリとして格納される。

【００１２】まず、中継装置において、パケットの送信
が検出されると図３に示すアドレステーブルの更新が行
われる。アドレステーブルは、セグメント上で検出され
たパケットが持つアドレスから発生するものであり、新
たに通信が開始されたホストのホストアドレス毎に、そ
のソースポートが書き込まれるとともに、固有の識別子
であるIndexが割り当てられることになる。このアドレ
ステーブルの更新により、送信元ホストを示す送信元In
dexと送信先ホストを示す送信先Indexを取得する。

【００１３】なお、ホストアドレスとIndexは一対一の
関係にあるとともに、Indexの方がホストアドレスより
も情報量が少なくなるように設定されている。このた
め、後述するトラフィックテーブルや第２の実施の形態
における共通メモリプールには、ホストアドレスではな
くIndexを格納するようにし、送信元ホスト及び送信先
ホストをIndexにより識別するようにすることで、トラ
フィックテーブルや共通メモリプール全体に要する記憶
領域が小さくなるようにしている。

【００１４】次に、図４に示すトラフィックテーブルか
ら送信元Indexを検索する。トラフィックテーブルは、
送信元ホストの送信元Index、送信先ホストの送信先Ind
ex及びトラフィック情報を一つのエントリとして、送信
元ホスト−送信先ホストの組み合わせ毎に書き込むよう
になっている。なお、以後、トラフィックテーブルにお
いて、送信元Indexを書き込む領域を送信元ホストフィ
ールド、送信先Indexを書き込む領域を送信先ホストフ
ィールド、トラフィック情報を書き込む領域を情報フィ
ールドと記載する。

【００１５】いま、トラフィックテーブルの情報フィー
ルドを更新しようとしている送信元Indexが送信元ホス
トフィールドに未登録の送信ホストであった場合、その
送信元IndexがSNMPの通信プロトコルで設定可能なMIBに
おいてそのサーバリストに通信相手が多いホストとして
登録されているならば、その送信元Indexを登録すると
ともに、その送信元ホストにリスト登録用のエントリ数
を確保する。なお、図４では、通信相手が多い送信元ホ
スト２（ホストアドレスＢ）に対して１７エントリの記
憶領域が割り当てられているが、割り当てられるエント
リの数はこれに限られるものではない。

【００１６】トラフィックテーブルの情報フィールドを
更新しようとしている送信元Indexが、送信元ホストフ
ィールドに未登録の送信ホストであった場合、前述のサ
ーバーリストに登録されていないならば、その送信元In
dexを登録するとともに、その送信元ホストにリスト未
登録ホスト用のエントリ数を確保する。なお、図４で
は、通信相手が少ない送信元ホスト１（ホストアドレス
Ａ）に対して５エントリの記憶領域が割り当てられてい
るが、割り当てられるエントリの数はこれに限られるも
のではない。

【００１７】そして、トラフィックテーブルの該当する
送信元Indexのエントリ（図４では、送信元Indexが２の
場合の領域Ａ）の中に送信先Indexが未登録の場合、該
当エントリ中の使用されていないエントリに送信先Inde
xを登録する。

【００１８】最後に、該当する送信元Indexと送信先Ind
exを持つエントリのトラフィック情報を、検出したパケ
ットを基に更新する。

【００１９】本実施の形態によれば、サーバ等の通信相
手の多いホストとそうでないホストとで、そのホストに
連続して割り当てるエントリの数を変えることができる
ので、これから書き込もうとする新規ホストが既に記憶
領域に存在するかどうかを高速に検索可能であるととも
に、トラフィック情報の収集に利用する記憶領域の使用
効率の向上を図ることが可能となる。

【００２０】なお、本実施の形態では、送信元ホスト毎
に複数のトラフィック情報をエントリとして保持してい
るが、送信先ホスト毎に複数のトラフィック情報をエン
トリとして保持するようにしてもよい。

【００２１】また、アドレステーブルとトラフィックテ
ーブルとを分けて保持しているが、一つのテーブルとし
てまとめて保持するようにしてもよい。

【００２２】さらに、本実施の形態では、サーバーリス
トをSNMPで設定可能なMIBとして保持しているが、例え
ば、シリアル端末によって設定するようにしてもよい。

【００２３】［第２の実施の形態］まず、第１の実施の
形態と同様に、アドレステーブルの更新を行う。このア
ドレステーブルは、セグメント上で検索されたパケット
が持つアドレスから生成する。更新時に送信先ホストと
送信元ホストのアドレス検索やアドレス登録を行うこと
で、送信元ホストを示す送信元Indexと送信先ホストを
示す送信先Indexを取得する。

【００２４】次に、図５に示すトラフィックテーブルか
ら送信元Indexを検索する。図５において、送信元ホス
トフィールドと送信先ホストフィールドは、送信元ホス
トと送信先ホストを示すアドレステーブル内のホストIn
dex、トラフィック情報フィールドは該当する送信元ホ
ストと送信先ホストの組み合わせ毎のトラフィック情
報、ポインタフィールドはその送信元ホストにトラフィ
ックテーブル内で確保されたエントリでは足りない場合
に、図６に示す、共通メモリプールと呼ばれる増設した
記憶領域に確保した複数のエントリからなるブロックの
先頭アドレスをそれぞれ格納する領域である。

【００２５】図６に示す、共通メモリプールは、決めら
れたエントリ数からなるブロックで構成され、送信先ホ
ストとトラフィック情報フィールドには、各々送信先In
dexと該当する送信元ホストと送信先ホストの組み合わ
せのトラフィック情報を格納する。なお、図６では、１
つのブロックに対し１０エントリずつの記憶領域が割り
当てられているが、割り当てられるエントリの数はこれ
に限られるものではない。

【００２６】送信元ホストが、トラフィックテーブルの
送信元ホストフィールドに未登録である場合には、その
送信元Indexを登録するとともに、その送信元ホストに
一定のエントリ数を確保する。なお、図５では、各送信
元ホストに対して５エントリずつの記憶領域が割り当て
られているが、割り当てられるエントリの数はこれに限
られるものではない。

【００２７】該当する送信元Indexを持つエントリの中
から送信先Indexを持つエントリの検索は、送信元ホス
トに対応するポインタフィールドがNULLの場合には、ト
ラフィックテーブル内の該当エントリのみを検索し、ポ
インタフィールドが共通メモリプール内のブロックを指
す場合には、そのブロック内も検索する。すなわち、図
５において、送信元Indexが１の場合、ポインタフィー
ルドがNULLであるので、検索対象となる領域は領域Ｂと
なる。また、送信元Indexが２の場合、ポインタフィー
ルドがＡ''であるので、検索対象となる領域は領域Ｂと
領域Ｇということになる。

【００２８】この検索の結果、送信先Indexが未登録で
合った場合、トラフィックテーブル内の該当する送信元
Indexのエントリに未使用の記憶領域があれば、その未
使用エントリに送信先Indexを登録する。すなわち、図
５において、送信元Indexが１の場合、エントリＤに新
たな送信先Indexを登録することになる。

【００２９】また、トラフィックテーブル内の該当する
送信元Indexの全エントリが使用不可の場合、その送信
元ホストに対応するポインタフィールドがNULLであれ
ば、共通のメモリプールにおいて確保した未使用ブロッ
クのアドレスをポインタフィールドに格納して、その未
使用エントリに送信先Indexを登録する。すなわち、図
５において、送信元Indexが３の場合、アドレスＢ''を
ポインタフィールドに格納して、その未使用エントリを
図６のエントリＦに新たな送信先Indexを登録すること
になる。

【００３０】最後に、該当する送信元Indexと送信先Ind
exを持つエントリのトラフィック情報を、検出したパケ
ットを基に更新する。

【００３１】本実施の形態によれば、サーバ等の通信相
手の多いホストとそうでないホストとで、そのホストに
連続して割り当てるエントリの数を変えることができる
ので、これから書き込もうとする新規ホストが既に記憶
領域に存在するかどうかを高速に検索可能であるととも
に、トラフィック情報の収集に利用する記憶領域の使用
効率の向上を図ることが可能となる。また、第１の実施
の形態のように、サーバー等の通信相手の多いホストを
リストに予め登録する処理を省くことが可能となる。

【００３２】なお、本実施の形態では、送信元ホスト毎
に複数のトラフィック情報をエントリとして保持してい
るが、送信先ホスト毎に複数のトラフィック情報をエン
トリとして保持するようにしてもよい。

【００３３】また、アドレステーブルとトラフィックテ
ーブルとを別けて保持しているが、一つのテーブルとし
てまとめて保持するようにしてもよい。

【００３４】さらに、本実施の形態では、１つの送信元
ホストに対して１つのブロックを割り当てるようにして
いるが、１つの送信元ホストに対して複数のブロックを
割り当てるようにしてもよい。

【００３５】

【発明の効果】以上のように、請求項１記載の発明にあ
っては、ネットワーク接続装置が接続するセグメント上
で検出したパケットを基に収集したトラフィック情報
を、送信元ホストと送信先ホストと併せて、送信元ホス
トまたは送信先ホスト毎に連続して確保された記憶領域
に格納するホスト間トラフィック情報の編集方法におい
て、予め通信相手の多いホストを記憶しておき、登録し
ようとする新規ホストが通信相手の多いホストとして記
憶されたホストである場合、通常確保される連続した記
憶領域より多くの連続する記憶領域を確保し、そこに新
規ホストに関するトラフィック情報を格納するようにし
たので、連続して記憶領域が確保されているため、これ
から書き込もうとする新規ホストが既に記憶領域に存在
するかどうかを高速に検索可能であるとともに、通信相
手の少ないホストに対して使用されることのない無駄な
記憶領域を割り当てないため、記憶領域の使用効率を向
上するホスト間トラフィック情報の編集方法を提供する
ことができた。

【００３６】請求項２記載の発明にあっては、ネットワ
ーク接続装置が接続するセグメント上で検出したパケッ
トを基に収集したトラフィック情報を、送信元ホストと
送信先ホストと併せて、送信元ホストまたは送信先ホス
ト毎に連続して確保された記憶領域に格納するホスト間
トラフィック情報の編集方法において、登録しようとす
る新規ホストが、既に確保されている既存の記憶領域に
格納できない場合、新たに連続する記憶領域に確保し、
そこに新規ホストに関するトラフィック情報を格納する
とともに、新たに記憶領域を確保した旨を記憶するよう
にしたので、サーバー等の通信相手の多いホストをリス
トに予め登録することなく、サーバ等の通信相手の多い
ホストとそうでないホストとで、そのホストに連続して
割り当てるエントリの数を変えることができるので、連
続して記憶領域が確保されているため、これから書き込
もうとする新規ホストが既に記憶領域に存在するかどう
かを高速に検索可能であるとともに、通信相手の少ない
ホストに対して使用されることのない無駄な記憶領域を
割り当てないため、記憶領域の使用効率を向上すること
が可能となるという効果をそうする。

【図面の簡単な説明】

【図１】第１の実施の形態に係るホスト間トラフィック
の編集方法のフローチャートである。

【図２】第２の実施の形態に係るホスト間トラフィック
の編集方法のフローチャートである。

【図３】アドレステーブルである。

【図４】第１の実施の形態に係るトラフィックテーブル
である。

【図５】第２の実施の形態に係るトラフィックテーブル
である。

【図６】第２の実施の形態に係る共通メモリプールであ
る。

【符号の説明】

１ アドレステーブル ２ トラフィックテーブル ３ 共通メモリプール

Claims (2)

【特許請求の範囲】
1. 【請求項１】 ネットワーク接続装置が接続するセグメ
   ント上で検出したパケットを基に収集したトラフィック
   情報を、送信元ホストと送信先ホストと併せて、送信元
   ホストまたは送信先ホスト毎に連続して確保された記憶
   領域に格納するホスト間トラフィック情報の編集方法に
   おいて、予め通信相手の多いホストを記憶しておき、登
   録しようとする新規ホストが通信相手の多いホストとし
   て記憶されたホストである場合、通常確保される連続し
   た記憶領域より多くの連続する記憶領域を確保し、そこ
   に新規ホストに関するトラフィック情報を格納するよう
   にしたことを特徴とするホスト間トラフィックの編集方
   法。
2. 【請求項２】 ネットワーク接続装置が接続するセグメ
   ント上で検出したパケットを基に収集したトラフィック
   情報を、送信元ホストと送信先ホストと併せて、送信元
   ホストまたは送信先ホスト毎に連続して確保された記憶
   領域に格納するホスト間トラフィック情報の編集方法に
   おいて、登録しようとする新規ホストが、既に確保され
   ている既存の記憶領域に格納できない場合、新たに連続
   する記憶領域に確保し、そこに新規ホストに関するトラ
   フィック情報を格納するとともに、新たに記憶領域を確
   保した旨を記憶するようにしたことを特徴とするホスト
   間トラフィックの編集方法。