JPH01503110A - 分散型ローカル・エリア・ネットワークのモニターシステム - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるため要約のデータは記録されません。

Description

【発明の詳細な説明】 技術分野 本発明は、ローカル・エリア・ネットワークのモニターに関する。

背景技術 ローカル・エリア・ネットワークは、データ処理装置が互いに通信できるように するための通信システムであ、る。ローカルエリアネットワーク上の多くのステ ーションは比較的に自律的でありがちであり、時折り他のステーションとの通信 が必要になるに過ぎない。他のステーションにはもっと頻繁に通信を必要とする ものがあり、勿論、特定のステーションが必要とする通信の量は時とともに変動 する。さらに、大掛かりな中央制御が行われることなしに、ローカル・エリア・ ネットワークに対してステーションが追加されたり、取り除かれたり、移動させ られたりすることがしばしばある。このような理由から、ローカル・エリア・ネ ットワークの管理者は、該ローカル・エリア・ネットワークをモニターして各ソ ースで使用されているトラフィックの量や種々のソースが使用している通信プロ トコールのような情報を集積するための、何らかの形式の装置を必要としている 。これらの情報および他の形式の情報は、さし迫った問題や現実のシステムの故 障を検出するのに助けとなる。

典型的なローカル・エリア・ネットワークにおいては、通信の基本ユニットはパ ケットであり、一つのステーションから他のステーションへのいずれのメツセー ジも、所定のプロトコールに基づいた種々の分野の情報を含む少なくとも一つの パケットを含んでいる。この情報の典型的なものはソースステーションのアイデ ンティティ、宛先のステーションのアイデンティティおよびパケットの特性に関 する他の種々の情報を含んでいる。モニターの典型的なものは、ローカル・エリ ア・ネットワークの通信バスをモニターして、各パケットを調べ所定の情報を得 る。

得られるべき情報は、典型的には使用者により特定され、典型的な例では、各パ ケットに応じて必要とされる処理の量は使用者が特定する情報の量によって定ま る。使用者により特定されるある与えられた量の情報に対しては、パケットごと に必要とされる処理の長さは定まったものとなる。しかし、パケットの長さは変 化する。あるパケットは極めて長いが、イーサネット（ＢＴＨＢＲＮＥＴ）ふよ びＩＥＥ　８０２．３パケツトは６７．２マイクロ秒程度まで短くなることがあ り、この長さはこの種のプロトコールにとっては最少長さである。したがって、 使用者には、要求される情報の量が処理に６７．２マイクロ秒以上を必要とする ほど大きくならないことを確認する負担が課せられる。もしそうしなければ、パ ケットのレートが高くなり過ぎたときモニターが幾つかのパケットをミスするこ とになり、該モニターが発生する統計が信頼できないものとなる。

モニターに際しての他の様相の問題は、とくに二つのローカル・エリア・ネット ワークが結合されたときに現れる。一つのローカル・エリア・ネットワークレッ グは、たとえば一つの同軸ケーブルを有し、このケーブルにすべてのステーショ ンが接続される。

典型的な例では、別の同軸ケーブルに信号を伝えるための他のレッグが先に述べ たレッグにブリッジを介して接続され、該ブリッジは、宛先がソースと同一のレ ッグである、と認識しないときに、一つのレッグから他のレッグに信号を送る。

ブリッジにより得られた情報において宛先のステーションがソースステーション と同じレッグ上にあることが明らかであれば、ブリッジはメツセージを第二のレ ッグに送らない。これは全体のローカル・エリア・ネットワークバンド幅を保存 するものであるが、このことはまた、一つのレッグ上で送られるメツセージが必 ず他のレッグ上で見られるとは限らない、ということを意味する。したがって、 理解できる統計を集めるには、一つ以上のモニターを必要とする。

本発明の一目的は、パケットレートに係わりなく、また使用者が可能な統計の所 定のグループを幾つ特定するかに係わりなく、完全な統計を保証できるような方 法でローカル・エリア・ネットワークをモニターすることにある。他の目的は、 そうするに当たってローカル・エリア・ネットワークが幾つかのレッグに分かれ ていても完全な統計が得られるようにすることである。さらに他の目的は効率良 くかつ信頼性あるようにローカル・エリア・ネットワークをモニターすることで ある。他の目的は説明が進むにつれて明らかになるであろう。

発明の開示 上述の目的およびそれに関連する目的の幾つかは、リソースがモニター管理ユニ ットおよび−またはそれ以上の基本モニターユニットの間に分布させられたモニ ターによって達成される。モニターユニットは、該モニターユニットが結合され ているローカル・エリア・ネットワークのそれぞれのレッグをモニターすること により統計を集積し、これらの統計を定期的にモニター管理ユニットに送り、該 モニター管理ユニットは、モニターにより送られたデータを処理して使用者のた めの表示を発生する。

リソースをこのように分布させることにより、すべてのローカル・エリア・ネッ トワークレッグから情報を得ることができる。

本発明の他の側面は、カウンターの配置方法に関する。モニターユニットは複数 のカウンターを有し、該モニターユニットが受け取るパケットの新しい指標（た とえば新しいソースアドレス、新しいプロトコール形式）の各々にカウンターを 組合わせる。モニターユニー／　）は、特定のフィールド値を受けたときどのカ ウンターを進めるかを決定するために、ルック・アップ・テーブルを採用する。

ルック・アップ・テーブルの各ロケーションはタグセグメントとポインターセグ メントを有する。タグセグメント特定のパケット指標を表すコードを含み、ポイ ンターセグメントは、その特定指標の発生度数を含むべきカウンターのアドレス を含む。

モニターが特定の指標を有するパケットを受けると、該モニターはルック・アッ プ・テーブルをサーチし、該指標のコードを含むタグセグメントの位置を検出す る。その位置が発見されると、モニターユニットはその位置のポインターセグメ ントの内容より示されるカウンターの内容を進める。

本発明のこの側面によれば、ルック・アップ・テーブルの構成がサーチを大幅に やり易くする。これは、タグフィールドの内容がルック・アップ・テーブル位置 のアドレスとともに単調に進むように、パケットフィールドの新しい値の各々が ルックアップテーブルにおいて位置させられるからである。したがって、サーチ は二進サーチとして達成でき、このサーチの長さはルック・アップ・テーブルの サイズの対数としてのみ増加する。これは、最も短いパケットに対してさえも十 分な統計を可能にするもので、処理は使用者が要求する特定の情報とは本質的に 独立したものとなる。

図面の簡単な説明 本発明のこれらのおよび他の特徴および利点は、添付図面に関連して説明する。

図において、 第１図は、本発明のモニターシステムが接続されるローカル・エリア・ネットワ ークのブロック図、 第２図は、第１図のローカル・エリア・ネットワークの通信バスにより接続され た信号パケットの代表的なフォーマットの図、第３図は、モニターシステムの他 の実施例のブロック図、第４図は、第１図に示すモニターユニットの一つのハー ドウェア配置のブロック図、 第５図は、モニターユニットがモニターしている通信バスが単一宛先パケットを 送っているときに該モニターユニットが達成する処理を示す図、 第６図は、モニターユニットがモニターしている通信バスがマルチキャスト宛先 パケットを送っているときに該モニターユニットが達成する処理を示す図である 。

発明を実施するための形態 第１図は、二つの同軸ケーブル通信バス１２．１４に通信を生じる二つのレッグ を含むローカル・エリア・ネットワーク１０を示すものである。図示されたネッ トワークはビット・シリアル・ネットワークであるが、本発明の教示がパラレル ・バス・ネットワークにも適用できることは明らかであろう。

第１図はさらにバス１２により相互に接続された三つのステーションユニット１ ６．１８．２０と、バス１４により相互に接続された四つのステーションユニッ ト２４．２６．２８を示す。各ステーションはたとえばプロセッサまたはディス クドライブでよく、ローカル・エリア・ネットワーク・プロトコールに応じてバ ス信号を送ったり受けたりするインターフェイス回路を含む。一つのステーショ ンたとえばステーション１６は、他のステーションと通信するために、該ステー ションが接続されたバス１２の制御を受け、制御を得たとき、周知の技術により 信号を所定のパケットフォーマットの上に置く。フォーマットは、たとえば第２ 図に示す形式のものでよい。第２図に示すように、パケットの最初の６バイトが 宛先アドレスフィールドを構成する。各ステーションは独特のアドレスを有し、 最初の６バイトはパケットを受けるべきステーションのアドレスである。

バス１２上の各ステーションは宛先アドレスフィールドを調べて、これがパケッ トを受けるべきステーションのものであるかどうかを決定する。例として、最初 の６バイトがステーション１８のアドレスを含むものと仮定する。ステーション １８の場合には、最初の６バイトとステーション１８の独特のアドレスとの比較 が一致を示すとき、ステーション１８がパケットの残りを処理する。

他の装置のすべては、そのアドレスと宛先アドレスとの比較結果が否定的である ことを認識したとき、パケットの処理を行わず、その代わりに次のパケットの始 まりを示すバス１２上のヘッダ信号（第２図には図示せず）のみについてモニタ ーする。

パケットの残りは、第２図に示すようにソースアドレスを含んでおり、宛先のス テーションは受け取ったパケットに適当に応答するためにこのアドレスを必要と する。ソースフィールドに続く２バイトフイールドは、所定のプロトコールにし たがってパケットの形式を示し、このフィールドは、後続するデータに対して宛 先ステーションが与えるべき解釈に関する別の情報を与える。このフィールドの 値が１０進法の１５０１より小さければこのパケットはＩＥＥＥ　８０２．３パ ケツトであり、このフィールドの値は後続するデータフィールドの長さを示す。

これ以外のばあいには、該値ハエターネットプロトコールによるパケット形式を 表す。

後続するフィールドは、パケットの伝達の目的となる実際のデータを含む。この フィールドの長さはフィールドに与えられた内容に応じてパケットごとに異なる 。最後の４バイトはエラー修正バイトであり、これをローカルエリアネットワー クインターフェイスが調べて伝達中にエラーが発生したかどうかを決定する。ス テーション１６がステーション１８にパケットを送るときにはバス１４は関与し ない。しかし、宛先がたとえばステーション２２であれば、バス１２上の信号に 含まれる情報をバス１４に送る必要がある。これは、ブリッジユニット３００機 能である。ブリッジユニット３０は両バス１２．１４上のトラフィックをモニタ ーし、バス１２から受けるソースアドレスのリストおよびバス１４から受けるソ ースアドレスのリストに従う。もし、バス１２から伝達されるパケットを調べて 当該バスのソースアドレスリストに含まれる宛先アドレスを発見すると、ブリッ ジ３０はパケット内容をバス１４に送らない、したがって、バス１４は不要なト ラフィックを受けることはない。他方、ブリッジ３０がバス１２上のパケットに 発見する宛先アドレスがバス１２のソースアドレスのリストにないときには、該 ブリッジはこのパケットをストアし、バス１４の制御を受けてこのパケットに含 まれる情報をバス１４上に移す。バス１４上にあるプロトコールがバス１２上に あるプロトコールとは異なるときは、ブリッジ３０はさらにプロトコール間の翻 訳を行う。

本発明によれば、基本モニターユニット３２と以下にモニター管理装置と呼ぶホ ストユニット３４とを少なくとも有するモニターシステムが提供される。モニタ ーユニット３２は一つのポート３６によりバス１２に接続され、バス１２をモニ ターして種々の指標を持つパケットのカウントを保持することができる。次いで このモニターユニットは最終的な統計をバスからモニター管理装置に送る。モニ ター管理装置は高レベルの処理を行って使用者のために表示装置３５に表示され る情報を発生する。

基本ユニット３２とモニター管理装置のみでは、バス１２上に現れるトラフィッ クのみをモニターすることが可能である。典型的な例を挙げれば、たとえばステ ーション２２．２４間のトラフィックはバス１２上には示されず、一つのネット ワークだけに接続できるモニターシステムは、幾つかのトラフィックをミスする ことがある。本発明による分布された配置の強味は、モニターのアーキテクチャ を拡張できることである。たとえば一つのローカル・エリア・ネットワークのレ ッグを増やすことができ、一つのモニターシステムのモニターユニットを増加し て追加したレッグのトラフィックの軌道を確保するこ♂ができる。モニターユニ ットを増加したばあいでも、使用する人に対する出力は以前として一つの装置す なわちモニター管理装置に集中化させる。

第１図に示すシステムでは、追加されるモニターユニット４０はポート４２によ りバス１４をモニターし、該モニターユニットは、その統計をバス１４からブリ ッジ３０および他の通信バス１２を介してモニター管理装置３４に伝達する。モ ニターユニット３２．４０とモニター管理装置３４との間の通信はローカルエリ アネットワークバス１２．１４により行われるので、モニターシステムの二つの 部分の間の通信があるバスバンド幅を使用することになる。これは通常は受け入 れることができる。しかし、モニターシステムが障害にならないようにするため に、第３図に示すようにモニターシステム内の通信のために別の特別に設けたバ スを採用することができる。さらに詳細に述べると、モニター管理装置３４は、 第３図においてはローカル・エリア・ネットワーク自体に接続されておらず、別 のモニターシステムバス４３に接続されている。この配置では、基本モニターユ ニット３２．４０はそれぞれ第２のポート４４．４５によりモニターシステムバ ス４３に接続され、ローカル・エリア・ネットワークバス１２には接続されてい ない。

モニター管理装置３４は、単に適当にプログラムされた汎用プロセッサであり、 通信バス１２により通信を行うためのインターフェイス回路と使用する人に出力 を与えるための出力装置とを備えている。モニター管理装置がモニターユニット から得る統計に対して該モニター管理装置が行う処理は通常のものであり、モニ ターユニット３２．４０が大量のモニター機能を遂行するのでモニター管理装置 の処理の負荷は最低である。したがって、モニター管理装置については、これ以 上説明しない。

基本モニターユニット３２．４０はとくに拘束処理のために配置されている。モ ニター３２．４０は同一のものであり、基本モニターユニット３２について第４ ．５．６図に基づき説明する。

第４図はモニター３２のハードウェア配置を示す。このハードウェアはケンブに 与えられた米国特許！　４．５９７．０７８号に説明された形式のインターネッ トワークブリッジと本質的に同一のものであり、該特許をここに参照する。しか し、プログラミングは相違しており、ブリッジとしてよりは、モニターの機能を 果たす。モニターユニット３２は二つの通常のローカルエリアネットワークイン ター７エイスユニツト４６．４８を含み、これらは通常の態様で２ポートメモリ ５０内に接続されている。ローカルエリアネットワークインターフェイス４６． ４８はバスからビットシリアル情報を受け、これをバイトに組んでチェックサム を調べてエラーが生じなかったことを確認し、次いでパケットの内容を連続する パケットメモリ位置に移す。インターフェイス４６．４８はさらにハウスキープ 用情報たとえばパケットサイズやパケット内容をストアした位置等をパケットメ モリに移す。インターフェイス４６．４８の一つがこの作業を完了したとき、該 インターフェイスはプログラムメモリ５３にストアしたプログラムにより作動す るマイクロプロセッサ５２をインターラブドし、アップデートなカウンター（実 際にはパケットメモリ位置）の作動を始めてモニターユニットが達成すべき目的 である統計を維持させる。

一般に、マイクロプロセッサ５２はインターラブドと応答してインターフェイス ４６がポインターで満たしている位置の内容のパケットメモリ５０を取り出、し 、該ポインターが丁度置かれたパケットの位置に移す。次いでマイクロプロセッ サは、その位置でスタートするパケットのソースアドレスフィールドの内容を取 す出し、その特定のソースが伝達したパケットの数を表すカウンターを進めなけ ればならないと決定する。そのカウンターを発見するために、マイクロプロセッ サ５２は、このソースアドレスを前述したケンプの特許に説明しであるような形 式のルック・アップ・エンジン５４に送る。この種のルック・アップ・エンジン ５４はケンプ特許に見出すことができ、ここでは繰り返さない。しかし、その一 般的な目的を述べると、それはルック・アップ・テーブル５６を採用しており、 マイクロプロセッサ５２がルック・アップ・エンジン５４に与えたアドレスを有 するソースにより送られたパケットの数のカウンターとして作用するパケットメ モリ５０内におけるメモリ位置のアドレスを見出す。

ルック・アップ・エンジン５４の作動の結果として、マイクロプロセッサ５２は 進められるべきカウンターのアドレスを得る。

このマイクロプロセッサはカウンターの内容を読み、それらの内容を進め、結果 をカウンターに戻してストアする。典型的には、マイクロプロセッサ５２、ルッ ク−アップ・エンジン５４およびルック・アップ・テーブル５６は、特定のソー スにより送られたパケットの数を表すカウンターのためだけではなく、他の特定 の記号を有するパケットの数をカウントするカウンターのためにも、この動作を 行う。この統計の集積は、第５．６図について説明する。

第５図は第４図の回路が単一の宛先パケットについて達成する処理の図である。

前述したように、パケットの第一のフィールドは、パケットがアドレスされる宛 先を表す。通常は、これは単一の宛先である。しかし、幾つかのアドレスには、 単一のステーションでなく複数のステーションを指定するものもある。そのよう なアドレスを「マルチキャスト」アドレスと呼ぶ。幾つかのステーションは、そ れ自身の独特の宛先アドレスに応答する外に、さらに加えて他のステーションが 応答する−またはそれ以上のマルチキャストアドレスにも応答する。第５図に示 す処理は、宛先アドレスがマルチキャストアドレスでない宛先アドレスを有する パケットに応答して達成される。宛先アドレスフィールドがマルチキャストアド レスを含むばあいには、モニターユニットは第６図について説明するような処理 を行う。

第５図に示される処理は模範的である。プログラムメモリ５４は他の形態の処理 を達成するためのインストラクションを含むことができる。本願明細書に記載さ れるオーガナイゼイション（編成）の威力の一つはそれ自体が基本ユニットの標 準プログラミングを導くことにある。即ち、モニターユニットは最小パケット時 間内にこのような多くの情報を修正するのに充分に高速に動作し、ユーザーが後 でモニター管理装置から要求する最大の情報に対する生データを収集することが できる。最小パケットタイムよりも少ない時間で走る標準プログラムを用いると 、データ修正プログラムの保全性はユーザーが要求した情報に依存しない。

ユーザーは、基本ユニットがコンパイルする統計を決める必要がないので、基本 的なプログラミングが、最小パケット時間よりも少ない時間で起こるように容易 に構成することができる。従って、全てのパケットが処理される。ユーザーが望 む特定の情報は、モニター管理装置３４に与えられる。このモニター管理装置３ ４は、基本モニターユニット３２および４ｏが与える統計の中から選択して採り 上げる。

第５図を理解するためには、パケットメモ！Ｊ−４０が二つのセクションに編成 されていることが理解されるべきである。第１のセクションはパケットバッファ ーとして作動する。これは、ローカル・エリア・ネットワーク・インターフェー ス４６および４８が受け取るパケットの内容を一時的に記憶する。第２のセクシ ョンはカウンタとして機能する記憶位置を含む。このカウンタが一度更新される と、マイクロプロセッサはローカル・エリア・ネットワーク・インターフェース ４Ｇおよび４８にこれを通知する。

これらインターフェースは次に最早必要でない記憶を有するパケットの内容を含 む第１のセクション内の記憶位置を自由に使用する。

第５図において、この図の左手側のブロックは入力情報を第１のパケットバッフ ァーセクションから得ていることを表している。

図面の右手側のブロックは第２のセクション内のカウンタの結果として生じる更 新を表している。

第５図の第ルベル５８はマイクロプロセッサの第１の処理を表している。このマ イクロプロセッサは、パケット力ウタとして機能するパケットメモリー５０内の 所定の記憶位置の内容をフェッチし、これらの内容を増加（インクリメント）し 、そして前記記憶位置に戻すことによりローカル・エリア・ネットワーク４６あ るいは４８からの割込に応答する。レベル５８は図面の右側において、ブロック ６０のみを含み、パケットカウンタ上の操作を表しており、左側にはブロックを 有さない。このことは、マイクロプロセッサは、この機能を達成するためにパケ ットについてはは何も知る必要がないということを意味している。パケットが受 け取られたことのみを知る必要があり、ローカル・エリア・ネットワーク・イン ターフェース４６あるいは４８による割り込みはこの事実を表している。

第５図の第２のレベル６２は左側にブロック６４を有しており、マイクロプロセ ッサが、パケットメモリから記憶位置の内容をフェッチすることを示している。

この記憶位置において、ローカル・エリア・ネットワーク４６あるいは４８は読 ろ取ったパケット内のバイトの数のカウント値を記憶する。レベル６２の右側に おけるブロック６６はパケットメモリ５０の第２カウンタセクシヨンにおける記 憶位置を更新することを表している。このパケットメモリ５０はローカル・エリ ア・ネットワークに転送されたバイトの全数に対するカウンタとして機能する。

マイクロプロセッサは記憶位置の内容をフェッチして、これをパケットバイトカ ウント値に加える。このパケットバイトカウント値はパケットメモリー５０のパ ケット記憶部からフェッチされたものであり、記憶位置に戻される。

レベル５８および６２によって表わされる何れのオペレイジョンにおいても、更 新されるべきカウンタの記憶位置は予め定められている。プログラムメモリ５３ は・パケットの記憶位置およびバイトカウンタを有する。従って、マイクプロセ ッサは、関心のあるカウンタを捜し出すのにルック・アップ・エンジン５４およ びルック・アップ・テーブル５６を必要としない。これに対して、レベル６８は これらの要素が必要とするプロセスを表している。

このプロセスにおいて、マイクロプロセッサはパケットバッファ記憶位置の内容 を取ってくる。ローカル・エリア・ネットワーク・インターフェース４６あるい は４８は、パケットバッファ記憶位置に、受は取ったパケットのソースアドレス フィールドの内容を記憶する。ブロック７０はこのステップを表す。次に、マイ クロプロセッサ５２は、ソースアドレスを有するソースによって送られた度数パ ケットの数を表すカウンタを増数する。どれが適正なカウンタであるかを決める ために、以下に詳細にのべる手法によりルック・アップ・エンジン５４およびル ック・アップ・テーブル５６を作動する必要がある。ブロック７２はオペレーシ ョンのこの部分を表している。結果はカウンタのアドレスとして表され、このカ ウンタは増数される必要がある。ブロック７３は、ソースアドレスに依存するパ ケットメモリスペース５００部分ヲ表している。ブロック７３が示すように、１ ０２４個の記憶位置はソースのカウンタに割り当てられている。モニターユニッ ト３２は、１０２４個のソースの各々に対するパケットを保持する能力を有して いる。

ルックアップテーブル５６は８０９６個の記憶位置Ｘ６４ビツトの記憶位置のメ モリーである。第４図に示されるように、各記憶位置７４は二つの部分、即ち４ ８ビツトタグセグメント７５および１６ビツドポイントセグメント７６に分けら れている。８０９６個の記憶位置メモリー内の１０２４の記憶位置がソースアド レスを表すルックアップカウンタに依存している。レベル６９によって表されて いるプロセスにおいて、マイクロプロセッサ５２はルック・アップ・エンジン５ ４（第４図）にソースアドレスフィールドの内容を供給する。この内容はパケッ トメモリー５０から取ってきたものであり、ルック・アップ・エンジン５４を作 動して、プロトコールタイブ・カウンタを見出すように方向づげられたルック・ アップ・テーブル５０の１０２４個の記憶位置セクションをルック・アップ・エ ンジン５４がサーチするように作動する。ルック・アップ・テーブル５６のこの セクション内の、ルック・アップ・エンジン５４は、マイクロプロセッサ５２が ルック・アップ・エンジン５４に供給したソースアドレスコードを含むタグセグ メントを有する記憶位置をサーチする。ルック・アップ・エンジンがこのような 記憶位置を見出した場合、マイクロプロセッサ５２に、その記憶位置のポインタ ーセグメントの内容を送り、マイクロプロセッサ５２はポインタが表すアドレス を有する記憶位置の内容を増大する。

本発明を、ブリッジユニットに対するＫｅｍｐｔ特許に記述されるオーガナイゼ ーションをモニターとして使用する様に適合するのが好ましい。このオーガナイ ゼーションは、第１のルック・アップ・テーブルが、第５図に記述されるプロセ ッサが最小パケット時間よりも速くサーチを達成できるようにする。

上述のＫｅｍｐｔ特許はこの作動を詳細に記述しており、ここではこの作動は詳 細に記述されない。一般に１．しかしながら、ルック・アップ・プエンジン５４ は、タグセグメントが、マイクロプロセッサ５２によってルック・アップ・プエ ンジンに供給された内容を含む記憶位置に対するルック・アップ・テーブル５６ の指定されたセクションをサーチする。ルック・アップ・エンジンが、探索値を 有するダグ内容を含む記憶位置を見出さない場合は、ルック・アップ・エンジン はこれをマイクロプロセッサ５２に知らせ、マイクロプロセッサ５２はルック・ アップ・エンジンに、ルック・アップ・テーブル・メモリー５６におけるソース アドレスルック・アップ・テーブルにおける適切な位置にソースアドレスを挿入 させる。これは、ソースアドレス・ルック・アップ・テーブルにおけるタグ入力 が、タグが記憶されている記憶位置のアドレスに従って、順番に行われる。（即 ち、ソースアトしスは、記憶位置アドレスが増大するとともに、単調増加あるい は単調減少する。）特に、ルック・アップ・エンジンは、ルック・アップ・テー ブル内の最後の入力をその記憶位置から取り除き、一つ高いアドレスの記憶位置 にこれを移動し、そして各前の入力に対してこのシーフェンスを、この新たな入 力が挿入されるべきポイントにルック・アップ・エンジンに到達するまで、繰り 返す。これは、要求された順番を保存する。

この操作の多くはＫｅｍｐｔ特許に詳細に記述されている。これらステップに加 えて、図示されたシステムにおけるマイクロプロセッサ５２は、パケットメモリ ー５２におけるカウンタ記憶位置を新たなソースアドレスに割り付け、新たなカ ウンタ記憶位置のアドレスを、タグセグメントが新たなソースアドレスで金満た されたルックアップテーブル記憶位置のポインタセグメント内に置く。

更に、マイクロプロセッサ５２がこのカウンタ記憶位置に単位値を満たして、一 つのパケットが新たに検出されたソースに送られたことを示す。

ルックアップテーブル内の順番を保存する理由は、この順番の保存がテーブルが ２値（バイナリ−）操作をすることを可能とするからである。特に、上述された サーチにおいて、ルック・アップ・エンジンは先ず、ソースアドレス・ルック・ アップ・テーブルの半分までを通して記憶位置を検査し、このタグ内容をサーチ している記憶位置のソースアドレスと比較する。サーチされている記憶位置のソ ースアドレスがタグの内容よりも高い場合は、ルックアップテーブルの半分、即 ち現在の記憶位置よりも低いアドレスを有する半分を考慮から除外する。次に考 慮に残っているルックアップテーブルの部分を通して記憶位置においてこのプロ セスを繰り返す。この方法において、サーチの各ステップは、前に考慮されたル ックアップテーブルの半分を考慮から除外する。これは、記憶位置のタグセグメ ントがルック・アップ・エンジンがサーチしているソースアドレスを含むか、所 定回数、即ちルック・アップ・テーブルのサイズの底２の対数に等しい回数のス テップが発生するまで続く。後者の場合において、サーチは失敗しており、ルッ ク・アップ・エンジン５４はマイクロプロセッサ５２に、ルック・アップ・テー ブルが、質問されているソースアドレスを含まないことを報告する。２値サーチ 法を用いることにより、ルック・アップ・エンジン５４は４マイクロ秒よりも少 ない時間で如何なるサーチも完了することができる。

レベル７８は次の処理を示す。この処理において、マイクロブロッセサ５２は、 パケットメモリからパケットサイズを入れている場所の内容とパケットの第３の プロトコルタイプのフィールドの内容を取ってくる。ブロック８０と８２はこれ らの動作を示す。

それからマイクロブロッセサ５２は第５図のブロック８４によって示される操作 を行う。それはタイプフィールドが示すプロトコルタイプに関連している４−カ ウンタ一群の初めのアドレスを見つけるように第４図のルック・アップ・エンジ ン５４を作ａする。

それから、マイクロプロッセサ５２はそのアドレスと関連するカウンタかそのア ドレスがパケットサイズに従って１．２または３によるポインターとは異なるカ ウンターの何れかを増加する。

特に、もしマイクロプロッセサ５２の取ってくるパケットサイズが成るしき値よ り下にあれば、マイクロプロッセサはパケットはサイズ蓄積ナンバー１に属する ことを決め、そしてそれはポインタが指定する場所の内容を増加する。もし、パ ケットサイズがしき値と次のしき値の間にあれば、マイクロプロッセサ５２はパ ケットがサイズ蓄積ナンバー２に入ることを決め、そしてそれは、そのアドレス がポインターセグメントの内容より一つ大きい場所の内容を増加する。もし、パ ケットサイズが第３の範囲１こ入ると、マイクロプロッセサ５２はそのアドレス がポインターより二つ大きい場所の内容を増加する。一方、もしパケットサイズ が第４より上の範囲にあると、そのアドレスがポインターより三つ大きい場所が 増加される。

パケットメモリ５０にあるカウンタースペースはこの処理の結果に与えられる場 所の６４ｘ４のアレイを有している。ブロック８６はこのアレイを示しており、 アレイの各素子はあるサイズの範囲内にある特別のプロトコルタイプのパケット を示すカウンターである。

レベル８８はモニター３２が単一の宛先パケットの受取に応答して作動する最後 の処理を示す。この処理の目的はソースとタイプの組み合わせを示すカウンター を更新することである。これらのカウンターの各々は何回も与えられたソースが 与えられたプロトコルを用いていることを示している。ルック・アップ・テーブ ル・タグ・フィールドが４８ビツト幅であるから、タグを作るための１６ビツト プロトコル・タイプのコードをもつ４８ビツトソース・アドレスを連結すること は簡単にはできない。その代わり、マイクロ、プロッセサ５２はソース・アドレ スとプロトコル・タイプがレベル６８と７８の処理にマツプされたそれぞれ１６ ビツト・ポインターを連結することによりタグを作る。８０９６のカウンターの 一つを設けるように、ルックアップ・エンジン５４（第４図）に結果としてのタ グを与える。ブロック９４はこのルック・アップ・テーブル・サーチを示す。

レベル８８の処理はレベル７８において述べた処理と同様である。レベル８８に おいては、増加されたカウンターはルック・アップ・テーブル・サーチの結果に より指定されたカウンターか、三つの直ぐ後のアドレスに関連するカウンタの一 つかの何れかである。ブロック９６は、ルック・アップ・テーブル５６の出力に より指定されたカウンターを増加するか、パケットサイズが入る範囲に従って、 他のカウンターを指定するためにその出力に１．２または３を加えるかどうかを 決めるために、パケットメモリ５０からマイクロブロッ七すがパケットサイズを 取ってくることを示している。ブロック９８はこの機能を果たすカウンターに割 り当てるパケットメモリ５０にある位置のアレイを示している。

第５図に示されている全ての処理は最少のパケットタイム内に生ずる。そしてレ ベル８８によって示されている処理が達成されると、モニターユニット３２は次 のパケットを処理する用意をする。

第６図は第５図が単一の宛先パケットの処理を示していると同様の方法でマルチ キャスト・パケットの処理を示している。第６図において、レベル１００．１０ ２および１０４は第５図のレベル５８．６２および６８と本質的に同様の処理を することを示している。これらのブロック１０６．１０８．１１０．１１２．１ １４および１１６は第５図における同様のブロック６０．６４．６６．７０およ び７２に相当する。最初の二つの処理の結果が単一の宛先パケットの受取りを増 加させるカウンターから離れているカウンター内に保持されることを除けば、こ れらの三つの処理はそれらが単一の宛先パケット用であると同様にマルチキャス ト用テアル。単一の宛先パケット用のカウンターをマルチキャストパケット用の カウンターから分離することは時々要求される。そして合計が要求されると、モ ニター管理装置３４は容易に対応しているカウンターからカウンターを加える。

他方、ブ西ツク７２と１１４は同じルック・アップ・テーブルの使用を示し、ブ ロック７３と１１６は、同じカウンターを増加させることを示している。

レベル１１８によって示されている第４の処理は第５図に示されている処理のい ずれとも異なっている。この処理に従って、マイクロブロッセサ５２は宛先フィ ールドとタイプフィールドのカウンターをきめるパケットメモリから情報を取っ てくる。ブロック１２０と１２２はこれらのステップを示している。マイクロブ ロッセサ５２はパケットのタイプフィールドにより示されているプロトコルタイ プに割り当てられるカウンターの３２−ロケイション群の初めのアドレスを探す ためにルックアップ・エンジン５４とメモリ５６の６４−エントリーセクション を調べる。ブロック１２４はこのステップを示している。次に、マイクロブロッ セサ５２は、３２−カウンタ一群中のどのカウン、ターがパケットの目的フィー ルドに含まれているマルチジャストアドレスに関連しているかを探すためにルッ クアップ・エンジン５４とメモリ５６の３２−エントリーセクションを調べる。

ブロック１２５は第２のルック・アップ・テーブルサーチを示す。ブロック１２ ６はこの処理に関連するカウンターの６４Ｘ３２アレイを示す。

レベル１２８によって示されている次の処理は、第５図のレベル８８によって示 されている処理の同様である。それはソースとプロトコルタイプの組み合わせに 関する統計をとる。それは統計がパケットサイズによって、得られないレベル− ８８の処理とは異なっている。レベル１２８の処理は、増加するブロック１３４ によって示されている８０９６のカウンターのどれかを決めるブロック１３６に よって示されているサーチ用のタグを作るために、サーチ１１４と１２４におい て作られるポインタを連結する。

レベル１１８によって示されている処理におけるカウンター識別のように、レベ ル１２８によって示されている処理がベースとなっているパケット特性は二つの フィールドのカウンターの組み合わせである。しかし、レベル１２８によって示 されている処理において、ブロックによって示されるルックアップテーブルサー チ（第５図のブロック９４によ、て示されるサーチと同様である）はソースアド レスとプロトコルタイプの組み合わせを入力するものとして用いる。ここで、ブ ロック１２４によって示されるサーチはプロトコルタイプのみを用いる。

この違いの理由は、マイクロプロッセサ５２がそれがソースアドレスとプロトコ ルタイプの新しい組み合わせを受けると、レベル１２８の処理に対し唯一つの新 しいカウンターだけを割り当てる。何故ならば特別のプロトコルタイプと関連す るカウンターが８０９６の素子群のカウンターの周りにまかれるからである。

反対に、レベル１１８によって示されている処理は新しいプロトコルタイプが遭 遇する毎に連続したカウンターを割り当てる。

何故なら、与えられたプロトコルタイプと関連する全てのカウンターは連続した アドレスを有しているからである。明らかに、レベル１１８に用いられている方 法はレベル１２８に用いられる。

また、逆も同様である。しかし、二つの状態がレベル１２８によって与えられた メモリ割当の効率とレベル１１８の方法により与えられたサーチスピードの間の 異なった妥協を要求したことを判断するために、その選択がなされる。第５図に 示されている処理のように、第６図に示されている処理は最少の長さのパケット 伝送より時間がかからない。したがって、モニターユニット３２は各パケットを 数えるために保証されている。また、モニター３２は更に二つの機能を達成する 。第一に、マイクロプロッセサ５２はインターフェース４６と４８の一つを選択 されたカウンターの内容をモニター管理装置３４に伝送するように、周期的に動 作する。第二は、マイクロプロッセサ５２はソースがモニター管理装置３４であ り、そして宛先がモニター管理装置ｆ３４であるかどうかを決定するために、各 々のパケットのソースコードを調べる。

もしそうであれば、それは正常な方法でパケットに関する統計をとる。しかし、 マイクロプロッセサ５２はまた命令としてのデータフィールドを扱う。そして例 えば、マイクロプロッセサはマニター管理装置によって要求された特別の情報を 有するパケットを送ることによって、それを達成する。上に述べたように、情報 のこのような交換は、モニター機能に与える離れた統計関係の通信バス上に生ず るか、またはバス１２がそれ自身統計関係バスとして働く。この命令の処理は、 例えば正常なパケット処理の間の時間に起こる。

産業上の利用性 この発明に技術はローカルエリアネットワークをより信頼性のある、より柔軟な 方法で達成することを可能にする。この発明は重要な、優れた技術を構成する。

浄書（内容に変更なし） 賢表千１−５０３１１０　（８） 足 ％Ｕ〒） 手続補正書（方式） 平成　年　月　日 特許庁長官　吉　１）文　毅　殿 １、事件の表示　ＰＣＴ／ＵＳ　８８１００５２１３、補正をする者 事件との関係　出願人 ４、代理人 ５、補正命令の日付　平成１年６月２７日国際調査報告 、、、　ＰＣＴ／ＵＳ　１ｌｌｉ１１００５２１ＳＡ　２１７７２

Claims (1)

1. 【特許請求の範囲】 １．信号パケットを導くトラフィックベアリング通信バス（１２）を含むローカ ル・エリア・ネットワークのトラフィックをモニターするシステムにおいて、 Ａ．信号パケットを導く統計ベアリング通信バス（４３）と、Ｂ．トラフィック ベアリング通信バス（１２）に接続され、信号パケットの既定の特性を検出する ようにし、及び、パケットを伝達する統計ベアリング通信バス（４３）に接続さ れ、検出された特性から統計をコンパイルし、統計ベアリング通信バス（４３） にわたって、コンパイルされた統計を示すパケットを伝達するモニターユニット （３２）と、及び、Ｃ．統計ベアリング通信バス（４３）に接続され、モニター ユニット（３２）により送られたパケットを受け取り、及び、その内容の人が読 める表示を発生させるホストユニット（３４）と、 を含むシステム。 ２．前記トラフィックベアリング（１２）及び統計ベアリング通信バス（１２） は、同じである請求の範囲１項記載のシステム。 ３．Ａ．前記システムは、トラフィックベアリング通信バス（１４）に接続され 、信号パケットの既定特性を検出するようにし、及び、パケットを伝達するス統 計ベアリング通信バス（４３）に接続され、検出された特性から統計をコンパイ ルし、統計ベアリング通信バス（４３）にわたって、コンパイルされた統計を示 すパケットを伝達する第２の監視ユニット（４０）を含み、 Ｂ．ホストユニット（３４）は、第２のモニターユニット（４０）により送られ たパケットを受け取り、及び、その内容の人が読める表示を発生させる請求の範 囲１項記載のシステム。 ４．信号パケットを導く通信バス（１２）を含むローカル・エリア・ネットワー クのトラフィックをモニターするためのモニターユニット（３２、４０）におい て、 Ａ．インデックスメモリ・ロケーション（７４）の順序付けられたグループを含 み、各メモリ・ロケーションがタグセグメント（７５）及びポインターセグメン ト（７６）を含むインデックスメモリ（５６）と、 Ｂ．それぞれが異なるアドレスに関連付けられ、カウント値を有し、及び、その カウント値をインクリメントするように作動可能である複数のカウンタと、 Ｃ．信号パケット内の既定フィールドのフィールド内容を読み取るリーディング 手段と、 Ｄ．リーディング手段に応答し、インデックスメモリ（５６）のタグ内容を通し て２進サーチを行い、もしあるならば、タグセグメント（７５）が既定フィール ドの内容を含むインデックスメモリ・ロケーション（７４）を識別するサーチ手 段（５４）と、 Ｅ．サーチ手段（５４）に応答して、サーチ手段（５４）かインデックスメモリ ・ロケーション（７４）のうちの１つのタグセグメント（７５）における既定フ ィールドの内容を発見すると、タグ内容の検出された内容の内容を含むインデッ クスメモリ・ロケーション（７４）のポインタセグメント（７６）にアドレスが 含まれるカウンターの内容を増加する手段（５２）と、 Ｆ．サーチ手段（５４）に応答し、サーチ手段（５４）がインデックスメモリ・ ロケーション（７４）のうちの１つのタグセグメント（７５）における既定フィ ールドの内容を発見するのに失敗すると、インデックスメモリ・ロケーション（ ７４）のタグセグメント（７５）の内容がロケーション自身と同じ順序であり且 つこれによりタグ内容が２進サーチによりサーチされ得るように選択されたイン デックスメモリ・ロケーション（７４）のタグセグメント（７５）における既定 フィールドの内容を入れ、インデックスメモリ・ロケーションのポインタセグメ ントのいずれかにアドレスが含まれないカウンターをリーディング手段により読 み取られるフィールド内容に配置し、及び、リードフィールドロケーションがタ グロケーシヨン内に入れられるインデックスメモリロケーション（７４）のポイ ンタセグメント（７６）内に配置されたカウンタのアドレスを入れる手段（５２ ）と、を含むユニット。