JPH0779246A - ネットワーク管理システム - Google Patents

Abstract

(57)【要約】 （修正有） 【目的】 管理ステーション１がゲートウエイ２ａ、２
ｂを介してプロトコルの異なる異質ノード３を管理する
ネットワークシステムにおいて、異質ノードに対するリ
クエスト送信時に必要な異質ノード構成情報の定義を自
動的に行い、オペレータによる異質ノード構成情報の管
理を不要にした管理システムを提供する。 【構成】 ゲートウエイ２ｂ、２ｄで、リクエスト送信
時に、異質ノード３を特定するための識別子を各異質ノ
ード毎に自動的に生成し、識別子と異質ノードのアドレ
スを対応付けた異質ノード構成情報として記憶する。ま
た、管理ステーションで、各ゲートウエイにて定義され
た異質ノード構成情報をゲートウエイから収集し記憶す
る。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、子とワーク管理システ
ムに関し、更に詳しくは、相異なる通信プロトコルに従
う複数のネットワークがゲートウエイで接続されたネッ
トワークシステムにおいて、特にＴＣＰ／ＩＰに従うネ
ットワークとＴＣＰ／ＩＰ以外のプロトコルに従うネッ
トワークが接続された場合に好適な管理システムに関す
る。

【０００２】

【従来の技術】まず、ＴＣＰ／ＩＰに従うネットワーク
の標準的管理プロトコルであるＳＮＭＰと、ＳＮＭＰの
管理ステーションからＴＣＰ／ＩＰ以外のプロトコルに
従うネットワークの従来のノード管理に付いて説明す
る。

【０００３】ＳＮＭＰについては、例えば、Ｍ．Ｔ．ロ
ーズ著／西田竹志訳「ＴＣＰ／ＩＰネットワーク管理入
門」（株式会社トッパン発行）に記載されているよう
に、ネットワーク内のノードから管理情報の収集や設定
処理を行うために規定されネットワーク管理プロトコル
であり、管理ステーション内のマネージャプログラムと
被管理ノード内のエージェントプログラムが互いにメッ
セージを送受することにより実現される。

【０００４】即ち、管理ステーション内のマネージャプ
ログラムは、ＵＤＰ／ＩＰパケットを用いて管理情報
（メッセージ経路情報や、送信／受信メッセージ数など
のトラフィック情報、障害情報など）の収集／設定を被
管理ノード（ホスト、ルータ、ブリッジなど）内のエー
ジェントプログラムに依頼するリクエストメッセージを
送信する。エージェントプログラムは依頼された情報の
収集／設定処理を行い、その結果をレスポンスメッセー
ジに設定してマネージャプログラムに送信する。

【０００５】さて、管理対象ノードがＴＣＰ／ＩＰ以外
のプロトコルに従う場合、上記ＳＮＭＰもサポートでき
ない。このような異質ノードについて、従来のシステム
では以下に示す方法で管理している。

【０００６】管理ステーションは、先ず、ゲートウエイ
にリクエストを送信する。ゲートウエイは、上記リクエ
ストを異質ノードが従っているプロトコルに変換した
後、これを異質ノードに送信する。異質ノードは、上記
エージェントに相当するプログラム（独自エージェント
と呼ぶ）を有し、上記リクエストに従って管理情報の収
集／設定を行い、その結果をゲートウエイに返す。ゲー
トウエイは、これをＴＣＰ／ＩＰプロトコル変換し、マ
ネージャプログラムに送信する。

【０００７】以上のような異質ノードの管理において、
ゲートウエイのことを「管理代行ノード」と呼び、管理
代行ノードにおいて管理ステーションと異質ノード間の
中継処理を行なうプログラムを「ｐｒｏｘｙエージェン
ト」と呼ぶ。

【０００８】さて、管理ステーションから管理代行ノー
ドを介して異質ノードにリクエストを送信する場合、管
理代行ノードの先に接続されているネットワーク内のど
の異質ノード宛のリクエストかを識別する為の識別子が
必要となる。この識別子としては、コミュニティ名称が
一般的に用いられている。

【０００９】「コミュニティ名称」とは、エージェント
側でマネージャの認証を行なうためのアスキー文字列で
あり、ＳＮＭＰメッセージのヘッダ部に標準的にセット
される情報である。各異質ノードに相異なるコミュニテ
ィ名称を割り当てておき、管理ステーション内のマネー
ジャプログラムが、異質ノードにリクエストメッセージ
を送信するとき、その異質ノードに割り当てられている
コミュニティ名称をリクエストメッセージにセットして
管理代行ノードに送信する。管理代行ノード内のｐｒｏ
ｘｙエージェントでは、受信したリクエストのコミュニ
ティ名称をチェックしどの異質ノードへのリクエストか
を識別する。

【００１０】従来は、上述した異質ノードの管理を実現
するためのコミュニティ名称の生成や、異質ノードとそ
の識別子であるコミュニティ名称を対応付けた異質ノー
ド構成情報をｐｒｏｘｙエージェント及びマネージャに
定義するための手続きが、オペレータにまかせられてい
た。

【００１１】

【発明が解決しようとする課題】然るに、一般にネット
ワークでは、ノードの追加や新たなネットワークへの接
続により構成変更が頻繁に発生する。この場合、従来の
方式では、ネットワーク構成の変更が生じるたびに、コ
ミュニティ名称の生成や、生成されたコミュニティ名称
と異質ノードとの対応付けをオペレータが行わなければ
ならず、その負担が非常に大きかった。又、異質ノード
へリクエストを送信する場合、異質ノードに割り当てら
れているコミュニティ名称をセットし、管理代行ノード
のＩＰアドレスを指定して送信しなければならず、本
来、異質ノードに割り当てられているアドレスを使用で
きなかった。その為、管理ステーションでの操作性が悪
いという問題もあった。

【００１２】

【課題を解決するための手段】上記課題を解決するた
め、本発明のネットワーク管理システムでは、上記ゲー
トウエイに、管理ステーションがゲートウエイを介して
異質ノードにリクエストを送信する場合にどの異質ノー
ドへのリクエストかを識別するための識別子を各異質ノ
ード毎に自動的に生成する手段と、上記生成した識別子
と上記異質ノードのアドレスを対応づけた異質ノード構
成情報を記憶する手段とを設け、上記管理ステーション
に、ネットワーク内のゲートウエイから上記異質ノード
構成情報を収集し、収集した異質ノード構成情報に対し
てゲートウエイのアドレスを対応付けて記憶する手段
と、上記収集した異質ノード構成情報に基づいて、オペ
レータが指定した異質ノードアドレスから識別子とゲー
トウエイアドレスを検索する手段と、検索した識別子を
リクエストメッセージに付加し、上記検索したアドレス
に基づいてゲートウエイに送信する手段を設けたことを
特徴とする。

【００１３】

【作用】上記構成により、本発明によれば、管理代行ノ
ードにおいて自動的に異質ノード構成情報が作成され、
その異質ノード構成情報が管理ステーションにも記憶さ
れる。また、オペレータは、コミュニティ名称を意識す
ることなく異質ノードのアドレスのみ指定するだけで、
リクエストメッセージを管理代行ノードを経由して指定
異質ノードに送信することができる。

【００１４】

【実施例】以下、本発明の実施例として、ＳＮＭＰを適
用したネットワークの管理システムを例として説明す
る。

【００１５】図２は、本発明が適用されるシステムの全
体構成を示す。ここで、ＬＡＮ４に接続された管理ステ
ーション１とノード２間では、標準プロトコルであるＴ
ＣＰ／ＩＰを用いて通信が行われており、本明細書で
は、これを「情報系ネットワーク」と呼ぶ。一方、ＬＡ
Ｎ５に接続されたコントローラ３では、非標準の独自プ
ロトコルを用いて通信が行われており、これを「制御系
ネットワーク」と呼ぶ。

【００１６】ノード２ｂ、２ｄは、情報系ネットワーク
と制御系ネットワークの両方に接続されており、これが
管理代行ノードとなる。又、管理ステーションから見て
制御系ネットワークに接続されたコントローラが、異質
ノードとして扱われる。

【００１７】図３は、管理ステーションのソフト構成を
示す。図３に示すように、ＳＮＭＰを実現する為のプラ
ットフォーム３１と、コントローラを管理する為のアプ
リケーションプログラム：ＡＰ（制御系ネットワーク発
見表示ＡＰ３２と、制御系ネットワーク構成図表示ＡＰ
３３、コントローラ管理情報収集／設定ＡＰ３４）と、
ＩＰノード構成テーブルと、コントローラ構成テーブル
とから構成されている。管理ＡＰ３２、３３、３４の詳
細については後述するとして、先ず、テーブル構成につ
いて説明する。

【００１８】図４はＩＰノード構成テーブルの構成を示
す。このテーブルは、情報系ネットワークの構成を管理
する為のものであり、ノード番号をセットするエリア４
１と、ノードのＩＰアドレスをセットするエリア４２
と、そのノードが管理代行ノードか否かを表すタイプ
（管理代行ノードの場合はｐｒｏｘｙ、そうでない場合
はＡＧＴとセットする）をセットするエリア４３と、管
理代行ノードの場合に各管理代行ノードから収集したコ
ントローラ構成テーブルの先頭アドレスをセットするエ
リア４４とから構成されている。

【００１９】図５はコントローラ構成テーブルの構成を
示す。このテーブルは、制御系ネットワークの構成を管
理するためのものであり、制御系ネットワーク５ａ、５
ｂに対応して設けられ、それぞれ、コントローラ番号を
セットするエリア５１と、各コントローラに割り当てら
れたコミュニティ名称をセットするエリア５２と、制御
系ネットワークのアドレスをセットするエリア５３とか
ら構成されている。

【００２０】図６は管理代行ノードとコントローラのソ
フト構成と、リクエスト／レスポンスメッセージのフロ
ーを示す。

【００２１】管理代行ノード２は、ＳＮＭＰプラットフ
ォーム６１と、エージェント６２と、ｐｒｏｘｙエージ
ェント６３と、制御系通信プロトコル６４と、コントロ
ーラ構成テーブル６４と、コンフィギュレーションファ
イル６６とから構成されている。ここで、コンフィギュ
レーションファイルには、制御系ネットワークに接続さ
れたコントローラの番号とアドレスとが前もって登録さ
れており、コントローラ構成テーブルを作成する際に参
照される。

【００２２】さて、エージェントでは、管理ステーショ
ンからのリクエストを受信すると、コミュニティ名称を
参照し、当該ノードへのリクエストかコントローラへの
リクエストかをチェックする。本実施例では、情報系ネ
ットワークに接続されたノードに対して、ＩＰＣＯＭと
いうコミュニティ名称を定義し、この名称によって識別
を行うものとする。また、当該ノードに対するリクエス
トならば、リクエスト内容に応じて管理情報の収集／設
定を行い、レスポンスを返す。コントローラへのリクエ
ストならば、ｐｒｏｘｙエージェントに渡す。

【００２３】ｐｒｏｘｙエージェントでは、エージェン
トから渡されたリクエストを受信すると、コミュニティ
名称を用いてリクエスト先コントローラを識別し、制御
系通信プロトコルに変換した後、指定コントローラへリ
クエストを送信する。又、コントローラから受信したレ
スポンスは、ＳＮＭＰに変換した後、管理ステーション
に送信する。

【００２４】コントローラ３は、制御系通信プロトコル
６５と、独自エージェント６６とから構成されており、
独自エージェントでは、ｐｒｏｘｙエージェントからの
リクエストを受け付け、管理情報の収集／設定を行い、
レスポンスを返す。

【００２５】次に、エージェント６２およびｐｒｏｘｙ
エージェント６３と、独自エージェント６８の処理フロ
ーについて説明する。

【００２６】図７は、エージェントの処理フローを示
す。エージェントでは、先ず管理ステーションからＳＮ
ＭＰリクエスト待ちとなる（処理７１）。ここで、リク
エストメッセージとスポンスメッセージは、同一フォー
マットを有もつ。

【００２７】これらのメッセージは、例えば図８に示す
ように、ＳＮＭＰのバージョン番号をセットするエリア
８１と、コミュニティ名をセットするエリア８２と、メ
ッセージのリクエスト種別（管理情報の収集あるいは設
定かを識別する為のコード）をセットするエリア８３
と、エラーステータス、エラーＩＮＤＥＸをセットする
エリア８４、８５と、変数リストをセットするエリア８
６とから構成される。

【００２８】エラーステータスとエラーＩＮＤＥＸは、
レスポンスメッセージの時に有効となるエリアであり、
リクエストに対するエラー情報（正常終了か否か、異常
ならばエラーの詳細）がセットされる。変数リストは、
ｎａｍｅ（エリア８ａ、８ｃ、８ｅ）とｖａｌｕｅ（エ
リア８ｂ、８ｄ、８ｆ）から構成されている。ｎａｍｅ
には要求する管理情報を識別するためのＩＤがセットさ
れ、ｖａｌｕｅにはそのＩＤが示す値がセットされる。
このｎａｍｅとｖａｌｕｅの数は、リクエストする際の
管理情報の数に一致しており、ｎ個の管理情報収集を要
求した場合、ｎ個のｎａｍｅとｖａｌｕｅから構成され
る。

【００２９】リクエストが受信されると、コミュニティ
名をチェックし、自ノード宛リクエストかコントローラ
宛リクエストかを識別する（処理７２）。コミュニティ
名称がＩＰＣＯＭのとき、当該ノード宛リクエストであ
り、リクエストＩＤ（収集／設定）とｎａｍｅをチェッ
クしていき、管理情報の収集／設定処理を実行する。

【００３０】この後、レスポンスメッセージを作成し、
管理ステーションに対して送信する（処理７３、７
４）。リクエストメッセージがエージェント宛でないと
きは、ｐｒｏｘｙエージェントにリクエストを渡す（処
理７５）。

【００３１】このように、エージェントでは、当該ノー
ド宛リクエストについては、要求されたリクエストの内
容に応じて管理情報の収集／設定を実行して管理ステー
ションにレスポンスを返し、コントローラ宛リクエスト
ならば、ｐｒｏｘｙエージェントにリクエストを渡す。

【００３２】次に、図１を参照して、ｐｒｏｘｙエージ
ェントの処理について説明する。ｐｒｏｘｙエージェン
トが起動されると、先ず、コントローラ構成テーブル
（図５）の設定処理を実行する（処理１０１）。ここ
で、コントローラ番号、アドレス（エリア５１，５３）
については、コンフィギュレーションファイルから読み
込みセットしていく。又、エリア５２のコミュニティ名
称については、各ノード毎に異なる名称を生成しセット
していく（処理１０２）。本実施例では、ＣＴＬＣＯＭ
１、ＣＴＬＣＯＭ２、ＣＴＬＣＯＭ３の順に生成し、セ
ットしていくものとする。

【００３３】コントローラ構成テーブルの設定が終了し
た後（処理１０１、１０２）、エージェントからのリク
エストメッセージ受信待ちとなる（処理１０３）。

【００３４】リクエストメッセージが受信されると、コ
ミュニティ名称を読み込み、受信したコミュニティ名と
同一名称をコントローラ構成テーブルからサーチし、ど
のコントローラに対するリクエストかをチェックする
（処理１０４）。そして、コントローラのアドレスを読
み込み、制御系通信プロトコルを使ってコントローラヘ
リクエストを送信し、レスポンス受信待ちとなる（処理
１０５、１０６）。

【００３５】コントローラからレスポンスが返ってくる
と、そのメッセージをＳＮＭＰメッセージに変換して管
理ステーションに送信し（処理１０７）、次のコントロ
ーラへのリクエスト待ちとなる。

【００３６】コントローラ３では、独自エージェント６
６が起動されており、図８に示すフローを実行する。ｐ
ｒｏｘｙエージェントからのリクエスト受信待ち状態
（処理９１）で、リクエストが受信されると、リクエス
トの内容を解析し、管理情報の収集／設定処理を実行す
る（処理９２、９３）。ついで、ｐｒｏｘｙエージェン
トに対してレスポンスを送信し（処理９４）、次のリク
エスト受信待ちとなる。

【００３７】以上示したｐｒｏｘｙエージェントと独自
エージェントとにより、コントローラ宛リクエストは、
制御系プロトコルを使って指定コントローラ内の独自エ
ージェントに渡される。そして、ｐｒｏｘｙエージェン
トにて独自エージェントからのレスポンスを受け取り管
理ステーションに送信される。

【００３８】次に、管理ステーション内の制御系ネット
ワーク発見表示ＡＰ３２と、制御系ネットワーク構成図
表示ＡＰ３３と、コントローラ管理情報収集／設定ＡＰ
３４の処理について説明する。

【００３９】ここで、情報系ネットワークに接続された
ＩＰノードについては、既に発見され、ＩＰ構成テーブ
ル（図４）のノード番号と、ＩＰアドレス（エリア４
１、４２）のセットとが行なわれているものとする。
又、図１０に示す情報系ネットワークの構成図も既に表
示されているものとする。尚、ウインドウ上に表示され
たノードを表す各アイコン１０に対しては、ノード番号
との対応付けが行なわれているものとする。これは、ウ
インドウ上に表示された各アイコンを編集したり、オペ
レータにてマウスクリックされたアイコンとノード番号
との対応付けを行う為のものであり、詳細については本
実施例では省略する。

【００４０】さて、オペレータは先ず初めに制御系ネッ
トワーク発見ＡＰ３２を起動する。起動されると、図１
１に示すフローを実行する。

【００４１】先ず、ＩＰノード構成テーブルにセットさ
れたノードに対して、順次、コントローラ構成テーブル
の情報収集（ｇｅｔ）を要求する（処理１１１）。要求
が成功（リクエストが正常終了）したならば、そのノー
ドは管理代行ノードであり、コントローラ構成テーブル
の値を全て収集した後、ノードタイプ（エリア４３）に
ｐｒｏｘｙをセットする。そして、収集したコントロー
ラ構成テーブルの先頭アドレスをエリア４４にセットす
る（処理１１２〜１１４）。又、管理代行ノードでない
ならばノードタイプにＡＧＴをセットした後（処理１１
２、１１５）、次のノードに対してチェックを行う。以
上の処理を全ＩＰノードに対して行っていく（処理１１
６）。

【００４２】次に、処理１１４、１１５でセットされた
ノードタイプ情報に基づいて、図１２に示すように、Ｉ
Ｐノードのネットワーク構成図を編集する。発見した管
理代行ノードのアイコン１２には、ｐｒｏｘｙという文
字を追加表示し、その下に制御系ネットワークが接続さ
れていることを表すアイコン１３を表示する（処理１１
７、１１８）。尚、新しくウインドウ上に表示したアイ
コン１３に対してはどのノードに接続されているかの対
応付けを行う（処理１１９）。又、このアイコン１３が
ダブルクリックされた時、制御系ネットワーク構成図表
示ＡＰ３３が起動されるように登録しておく。以上処理
により、オペレータは、制御系ネットワークの存在を確
認することができるようになる。

【００４３】オペレータが、表示したい制御系ネットワ
ークのアイコンをダブルクリックすると、制御系ネット
ワーク構成図表示ＡＰ３３が起動され、図１３に示すフ
ローが実行される。

【００４４】先ず、クリックされたアイコンのノード番
号をチェックする（処理１３１）。次に、ＩＰノード構
成テーブルから、コントローラ構成テーブルのアドレス
を取得し、コントローラ構成テーブルの情報を参照し
て、図１４に示す制御系ネットワークの構成図と、各コ
ントローラに付けられたアドレスを表示する（処理１３
２）。ここでも、表示したアイコン１３に対してコント
ロール番号との対応付けを行う（処理１３３）。また、
コントローラを表すアイコン１３がダブルクリックされ
た時、コントローラ管理情報収集／設定ＡＰ７４が起動
されるよう登録しておく。尚、起動する際に管理代行ノ
ードのノード番号を引数として渡すようにする。

【００４５】コントローラ管理情報収集／設定ＡＰは、
図１５に示すフローを実行する。

【００４６】先ず、クリックされたアイコンのコントロ
ーラ番号をチェックする（処理１５１）。そして、引数
で渡された管理代行ノードのノード番号をキーとして、
ＩＰノード構成テーブルから管理代行ノードのＩＰアド
レス、及び、コントローラ構成テーブルのアドレスを得
る。そして、コントローラ番号から割り当てられたコミ
ュニティ名称を取得し、オペレータの指示待ちとなる
（処理１５２、１５３）。

【００４７】ここで、オペレータからのリクエスト内容
の指示が行なわれると、その指示に基づいてリクエスト
メッセージを作成し、管理代行ノードに送信し（処理１
５４）、レスポンスメッセージ受信待ちとなる（処理１
５５）。

【００４８】リクエストメッセージには、取得したコミ
ュニティ名称、指定されたリクエストのＩＤ、管理情報
のＩＤをセットする。又、管理情報の設定要求の場合に
は指定された設定値をセットする。尚、送信されたコン
トローラ宛リクエストメッセージは、上記説明したエー
ジェント、ｐｒｏｘｙエージェント、独自エージェント
の処理によって、レスポンスが返される。そして、レス
ポンスが受信されるとメッセージの内容（正常終了か否
か、収集した管理情報の値）を解析し、ウインドウに表
示する（処理１５６）。これをオペレータからの終了指
示があるまで繰り返し実行する（処理１５７）。

【００４９】以上の処理によって、オペレータはコント
ローラを識別するためのコミュニティ名称を意識する必
要なく、ウインドウ上に表示された制御系ネットワーク
の構成図を使ってコントローラの管理を行なうことがで
きる。又、オペレータは、制御系ネットワークの構成を
自動的に把握することができる。

【００５０】上記実施例では、制御系発見表示ＡＰをオ
ペレータが起動するようにしたが、これを管理ステーシ
ョンの立ち上げ時、及び、定期的に起動するようにし、
管理代行ノードからコントローラ構成テーブルを収集
し、今までに登録していたコントローラ構成テーブルの
値とチェックすることによって、ネットワーク構成の変
化を検出するようにしてもよい。

【００５１】

【発明の効果】本発明によれば、オペレータはｐｒｏｘ
ｙエージェント及び管理ステーションにおいて、異質ノ
ード構成情報の定義が不要となる。又、オペレータは、
コミュニティ名称を意識する必要なく、異質ノードのア
ドレスを使って異質ノードの管理を行うことができ、管
理ステーションでは、ネットワーク内に管理代行ノード
があるか否かの確認や、管理代行ノード下の異質ノード
の構成を把握することができる。

【図面の簡単な説明】

【図１】本発明のシステムにおけるｐｒｏｘｙエージェ
ントの概略フローチャート。

【図２】本発明を適用するネットワークシステムの１例
を示す構成図。

【図３】管理ステーションのソフトウエア構成を示す
図。

【図４】ＩＰノード構成テーブルの構成図。

【図５】コントローラ構成テーブルの構成図。

【図６】管理代行ノードとコントローラのソフトウエア
構成図。

【図７】エージェントの概略フローチャート。

【図８】ＳＮＭＰメッセージのフォーマットを示す図。

【図９】独自エージェントの概略フローチャート。

【図１０】情報系ネットワークの表示画面の１例を示す
図。

【図１１】制御系ネットワーク発見表示ＡＰの概略フロ
ーチャート。

【図１２】管理代行ノードの表示画面の１例を示す図。

【図１３】制御系ネットワーク構成図表示ＡＰの概略フ
ローチャート。

【図１４】制御系ネットワークの表示画面の１例を示す
図。

【図１５】コントローラ管理情報収集／設定ＡＰの概略
フローチャート。

【符号の説明】

ｎａｍｅ……管理情報の識別子、 ｖａｌｕｅ……管理情報の値、 ＭＧＲ……管理ステーション、 ｐｒｏｘｙ……管理代行ノード、 ＡＰ……アプリケーションプログラム、 ＣＴＬ……コントローラ。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 柳沢 恵美子 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 高田 治 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 綿谷 洋 茨城県日立市大みか町五丁目２番１号 株 式会社日立製作所大みか工場内

Claims (2)

【特許請求の範囲】
1. 【請求項１】相異なる通信プロトコルに従う複数のネッ
   トワークがゲートウエイで相互に接続され、ある１つの
   ネットワーク内の管理ステーションがゲートウエイを経
   由して他のネットワーク内のノード（異質ノードと呼
   ぶ）と管理情報収集／設定のためのリクエスト／レスポ
   ンスメッセージを送受するネットワーク管理システムに
   おいて、 上記ゲートウエイが、 管理ステーションがゲートウエイを介して異質ノードに
   リクエストを送信する場合にどの異質ノードへのリクエ
   ストかを識別するための識別子を各異質ノード毎に自動
   的に生成する手段と、 上記生成した識別子と上記異質ノードのアドレスを対応
   づけた異質ノード構成情報を記憶する手段とを有し、 上記管理ステーションが、 ネットワーク内のゲートウエイから上記異質ノード構成
   情報を収集し、収集した異質ノード構成情報に対してゲ
   ートウエイのアドレスを対応付けて記憶する手段と、 上記収集した異質ノード構成情報に基づいて、オペレー
   タが指定した異質ノードアドレスから識別子とゲートウ
   エイアドレスを検索する手段と、 検索した識別子をリクエストメッセージに付加し、上記
   検索したアドレスに基づいてゲートウエイに送信する手
   段とを有することを特徴とするネットワーク管理システ
   ム
2. 【請求項２】前記管理ステーションが、起動された時点
   および定期的に前記ゲートウエイの存在をチェックし、
   上記ゲートウエイから異質ノード構成情報を収集し、既
   に取得済みの異質ノード構成情報と比較することによ
   り、ネットワーク構成の変化を検出する手段を有するこ
   とを特徴とする請求項１に記載のネットワーク管理シス
   テム。