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

Abstract

(57)【要約】 【課題】 複数のマネージャ２０１にTrap-ＰＤＵを送
信したときに、どのマネージャ２０１がTrap-ＰＤＵを
受信したかを確認できるようにする。 【解決手段】 ＭＩＢ１４０に受信トラップテーブル１
４１を備え、Trap-ＰＤＵを受信したマネージャ２０１
は、この受信トラップテーブル１４１の値を変更するse
t-requestオペレーションを送信元のエージェント１０
１に送信する。このオペレーションによってTrap-ＰＤ
Ｕ１３１の送信元エージェント１０１の受信トラップテ
ーブル１４１にトラップ受信者とタイムスタンプ値とが
記録され、エージェント１０１はこの受信トラップテー
ブル１４１を検査することにより、どのマネージャ２０
１がTrap-ＰＤＵを受信したかを確認する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、簡単なプロトコル
を利用して複数の管理ステーンョンが複数のネットワー
ク・エレメント（network element；以下「ＮＥ」と記
す）を管理するネットワーク管理システムに関する。

【０００２】

【従来の技術】ネットワーク管理は、ネットワークを介
してコンピュータ間で通信を行う際に、マルチベンダ化
が進む中で主にネットワークの安定な運用、セキュリテ
ィ確保、運用コストの削減を目的として行う管理であ
る。

【０００３】図２は、ネットワーク管理システムのシス
テム構成を示すブロック図である。ネットワーク１に
は、それぞれＮＥに搭載され、管理対象ノードの管理機
能である例えば３つのエージェント１１〜１３と、各エ
ージェント１１〜１３を管理する４つのマネージャ２１
〜２４と、が接続されている。

【０００４】このエージェント１１〜１３とマネージャ
２１〜２４との間で種々のオペレーションを行うことに
よりネットワークが管理される。このようなネットワー
ク管理の世界では、ＳＮＭＰ（Simple Network Managem
ent Protocol）と呼ばれるプロトコルが広く利用されつ
つある。

【０００５】ＳＮＭＰによれば、このエージェント１１
〜１３とマネージャ２１〜２４との間で、ポーリング
（マネージャからエージェントの管理情報へのアクセ
ス）又はＴＲＡＰ（異常状態のマネージャへの通知）が
行われる。

【０００６】このＳＮＭＰは、「大鏡久生著．『ＴＣＰ
／ＩＰとＯＳＩネットワーク管理』ソフト・リサーチ・
センター発行」の第４章や「W.Richard Stevens著．井
上尚司 監訳．橘康雄 訳．『詳解ＴＣＰ／ＩＰ』ソフ
トバンク発行」の第２５章にも解説されているように、
ＴＣＰ／ＩＰプロトコル群の第４層（アプリケーション
層）プロトコルであり、一般的に第３層（トランスポー
ト層）プロトコルとしてＵＤＰ（User Datagram Protoc
ol）を利用している。

【０００７】このＵＤＰは、データグラム指向のプロト
コルと呼ばれるものであり、信頼性は提供されていな
い。即ち、ＵＤＰは、コネクションレス型プロトコルで
あるが、このコネクションレス型プロトコルはＴＣＰ／
ＩＰのようなコネクション型プロトコルとは異なり、デ
ータ送信の前にコネクションを設定しない。このため、
送信したデータが相手に必ず届くという保証はなく、ま
た、送信中にＵＤＰのＰＤＵ（Protocol Data Unit）に
エラーが生じた場合、受信者はそのＰＤＵを破棄するだ
けで、再送要求などは行われない。

【０００８】このようなＵＤＰを利用しているＳＮＭＰ
においても、信頼性は同様に提供されていない。即ち、
このようなＳＮＭＰを利用したネットワーク管理では、
障害等の管理対象となる事象（イベント）が発生したと
き等に事象内容を報告するためのオペレーションとして
trapオペレーションが用意されているが、このtrapオペ
レーションは、エージェントがマネージャに対して自発
的に行うオペレーションであり、信頼性のないプロトコ
ルによって行われ、マネージャがエージェントに対して
このtrapオペレーションの反応を示すことはない。従っ
て、trapオペレーションによって送信されたTrap-ＰＤ
Ｕがマネージャによって正しく受信されたかどうかを、
エージェントもマネージャも確認できないという問題点
があった。

【０００９】このような問題点を解決するため、ＮＥに
trapオペレーションの結果を確認するための管理オブジ
ェクトを用意し、Trap-ＰＤＵを受信したマネージャがT
rap-ＰＤＵを送信したエージェントに対し、その管理オ
ブジェクトの値を変更するset-requestオペレーション
を行うことでtrapオペレーションの結果を確認するよう
にしたものがある（特開平８−３３１２０６号公報等参
照）。

【００１０】

【発明が解決しようとする課題】しかし、かかる従来の
ネットワーク管理システムでは、エージェントが確認で
きるのはTrap-ＰＤＵを受信したたった一つのマネージ
ャの応答だけである。

【００１１】一般に、エージェントは複数かつ不特定の
Trap-ＰＤＵの送信先を設定できるが、Trap-ＰＤＵが複
数のマネージャによって受信される可能性がある場合、
エージェントは、それらがどのマネージャによって受信
されたのかを判断することはできないし、trapオペレー
ションが正常に行われたかどうかも確認できない。従っ
て、Trap-ＰＤＵが複数のマネージャによって受信され
る可能性がある場合にTrap-ＰＤＵを送信したとき、こ
のTrap-ＰＤＵがどのマネージャによって受信されたか
を判断できるようになれば、trapオペレーションの信頼
性も向上する。

【００１２】

【課題を解決するための手段】本発明は以上の点を解決
するため次の構成を採用する。 〈構成１〉請求項１の発明に係るネットワーク管理シス
テムは、被管理装置が、ＰＤＵを送信すべきＰＤＵ送信
先及びＰＤＵを受信したトラップ受信先を記録するため
のトラップ送受信データベースと、前記ＰＤＵを一意に
識別可能なＰＤＵ識別データ及びＰＤＵ送信先を記録す
るためのトラップ送信データベースと、前記ＰＤＵ識別
データ及びトラップ受信先の管理装置を記録するための
受信トラップテーブルと、発生したイベントに応じてＰ
ＤＵ送信先を設定するトラップ送信先設定手段と、設定
されたＰＤＵ送信先及びＰＤＵ識別データをトラップ送
信データベースに記録し、ＰＤＵ識別データをＰＤＵ内
に記録し、トラップ送信先設定手段により設定されたＰ
ＤＵ送信先に当該ＰＤＵを送信するＰＤＵ送信手段と、
前記管理装置から受信トラップテーブルの値の変更を要
求する変更要求を受信したとき、受信トラップテーブル
にトラップ受信先及びＰＤＵ識別データを記録するセッ
ト受信処理手段と、前記受信トラップテーブルの値が変
更されたとき、トラップ受信先をＰＤＵ送信先と関連付
けてトラップ送受信データベースに記録するトラップ受
信確認手段と、を備え、管理装置が、送信されたＰＤＵ
に記録されたＰＤＵ識別データに基づいて受信すべきＰ
ＤＵを受信するトラップ受信処理手段と、該トラップ受
信処理手段がＰＤＵを受信したとき、当該装置をトラッ
プ受信先としてＰＤＵに記録されているＰＤＵ識別デー
タを用いてＰＤＵ送信元に前記変更要求を送信するセッ
ト送信処理手段と、を備えて構成されたものである。

【００１３】〈構成２〉請求項２の発明に係るネットワ
ーク管理システムは、被管理装置は、送信すべきＰＤＵ
のＰＤＵ送信先及び送信するＰＤＵを一意に識別可能な
送信トラップインデックスを記録するための送信トラッ
プテーブルと、ＰＤＵを送信すべきＰＤＵ送信先を設定
し、送信トラップインデックス及びＰＤＵ送信先を送信
トラップテーブルに記録するトラップ送信先設定手段
と、前記送信トラップテーブルに記録された送信トラッ
プインデックスをＰＤＵに記録し、ＰＤＵ送信先に当該
ＰＤＵを送信するＰＤＵ送信手段と、を備え、管理装置
が、受信したＰＤＵ及びＰＤＵを送信したＰＤＵ送信元
を記録するための受信トラップデータベースと、前記Ｐ
ＤＵを受信し、受信したＰＤＵ及びＰＤＵを送信したＰ
ＤＵ送信元を受信トラップデータベースに記録するトラ
ップ受信処理手段と、前記被管理装置の送信トラップテ
ーブルを検索し、当該管理装置が受信可能なＰＤＵの送
信トラップインデックスを取得するゲット送信処理手段
と、該ゲット送信処理手段が取得した送信トラップイン
デックスを、受信トラップデータベースに記録されてい
るＰＤＵの送信トラップインデックスと比較し、受信で
きなかったＰＤＵの有無を確認するトラップ確認処理手
段と、を備えて構成されたものである。

【００１４】〈構成３〉請求項３の発明に係るネットワ
ーク管理システムは、被管理装置が、ＰＤＵを送信すべ
きＰＤＵ送信先及びＰＤＵを受信したトラップ受信先を
記録するためのトラップ送受信データベースと、送信す
るＰＤＵを一意に識別可能な送信トラップインデック
ス、トラップ送信先及びトラップ再送信先を記録するた
めの送信トラップテーブルと、前記受信トラップインデ
ックス及びトラップ受信先を記録するための受信トラッ
プテーブルと、送信したＰＤＵを保存するためのＰＤＵ
保存データベースと、前記ＰＤＵを送信すべきＰＤＵ送
信先を設定し、送信トラップインデックス及びＰＤＵ送
信先を送信トラップテーブルに記録するトラップ送信先
設定手段と、送信するＰＤＵをＰＤＵ保存データベース
に保存し、送信トラップテーブルに記録された送信トラ
ップインデックスをＰＤＵに記録し、ＰＤＵ送信先に当
該ＰＤＵを送信するＰＤＵ送信手段と、管理装置から受
信トラップテーブルの値の変更を要求する第１の変更要
求を受信したときは、該受信トラップテーブルにトラッ
プ受信先及びトラップ受信先を識別するための受信先ト
ラップインデックスを記録し、送信トラップテーブルの
値の変更を要求する第２の変更要求を受信したときは、
送信トラップテーブルに当該ＰＤＵの送信トラップイン
デックス及びトラップ再送信先を記録するセット受信処
理手段と、前記受信トラップテーブルの値が変更された
とき、受信トラップテーブルに記録された受信先トラッ
プインデックスと同じ値を有する送信トラップインデッ
クスを送信トラップテーブルから検索し、トラップ受信
先をトラップ送信先と関連付けてトラップ送受信データ
ベースに記録するトラップ受信確認手段と、前記送信ト
ラップテーブルの値が変更されたとき、該送信トラップ
テーブルに記録されたトラップ再送信先の送信トラップ
インデックスに基づいてＰＤＵ保存データベースを検索
し、管理装置が受信できなかったＰＤＵをトラップ再送
信先に再送信するトラップ再送処理手段と、を備え、管
理装置が、受信したＰＤＵ及びＰＤＵを送信したＰＤＵ
送信元を記録するための受信トラップデータベースと、
前記第１の変更要求、第２の変更要求の送信依頼を受け
たとき、ＰＤＵ送信元に当該変更要求を送信するセット
送信処理手段と、ＰＤＵを受信し、受信トラップデータ
ベースに受信したＰＤＵ及びＰＤＵを送信したＰＤＵ送
信元を記録して第１の変更要求の送信を依頼するトラッ
プ受信処理手段と、前記被管理装置の送信トラップテー
ブルを検索し、当該管理装置が受信可能なＰＤＵの送信
トラップインデックスを取得するゲット送信処理手段
と、該ゲット送信処理手段が取得した送信トラップイン
デックスを、受信トラップデータベースに記録されてい
る送信トラップインデックスと比較し、受信できなかっ
たＰＤＵの有無を確認するトラップ確認処理手段と、該
トラップ確認処理手段により、受信できなかったＰＤＵ
があると判定されたときは、ＰＤＵの送信元に前記第２
の変更要求の送信を依頼するトラップ再送要求処理手段
と、前記トラップ受信処理手段からの第１の変更要求の
送信依頼を受けてＰＤＵ送信元に第１の変更要求を送信
し、トラップ再送要求処理手段からの第２の変更要求の
送信依頼を受けて、ゲット送信処理手段が送信トラップ
インデックスを取得したＰＤＵ送信元に第２の変更要求
を送信するセット送信処理手段と、を備えたものであ
る。

【００１５】〈構成４〉請求項４の発明に係るネットワ
ーク管理システムでは、被管理装置は、ＰＤＵを受信す
ることが予想される管理装置の受信者を記録するための
トラップ受信予定者を記録するためのトラップ受信予定
リストを備える一方、前記トラップ受信確認手段は、受
信トラップテーブルにデータが記録されたとき、トラッ
プ受信予定リストに記録されたトラップ受信予定者を削
除し、前記ＰＤＵ送信手段は、トラップ送受信データベ
ースに記録されているトラップ受信先をトラップ受信予
定リストに記録し、ＰＤＵ送信後にトラップ受信予定リ
ストにトラップ受信先が残っているときは、ＰＤＵを再
送するように構成されている。

【００１６】〈構成５〉請求項５の発明に係るネットワ
ーク管理システムでは、各被管理装置、各管理装置が、
それぞれ各手段及びデータベースを備えたエージェン
ト、マネージャを備えて構成されている。

【００１７】

【発明の実施の形態】以下、本発明の実施の形態を具体
例を用いて説明する。 〈具体例１〉具体例１は、被管理装置に実装されたエー
ジェント内に受信トラップテーブルを備え、エージェン
トが管理装置に実装された複数のマネージャにTrap-Ｐ
ＤＵを送信したときに、Trap-ＰＤＵを受信したマネー
ジャがこの受信トラップテーブルの値を変更するオペレ
ーションを行うようにして、受信できなかったマネージ
ャが存在するかどうかを送信元のエージェント側で確認
できるようにしたものである。

【００１８】図１は、具体例１の構成を示すブロック図
である。図１において、ネットワーク１には、ｐ台の被
管理装置としてのＮＥ１００−１〜ｐと、ｑ台の管理装
置としての管理ステーション２００−１〜ｑとが接続さ
れている。各ＮＥ１００−１〜ｐには、エージェント１
０１及びトラップ送信先アドレス設定部１１０が実装さ
れ、各管理ステーション２００−１〜ｑにはマネージャ
２０１が実装されている。尚、ネットワーク１に、その
他の機器を接続することはできるが、ここでは、言及し
ない。

【００１９】各ＮＥ１００−１〜ｐのエージェント１０
１は、トラップ送信処理部１２０と、トラップ送信プロ
セス１３０−１〜ｎと、ＭＩＢ（Management Informati
on Base）１４０と、セット受信処理部１５０と、トラ
ップ受信確認プロセス１６０と、トラップ送受信アドレ
スデータベース１７０と、を備えて構成され、トラップ
送信先アドレス設定部１１０はエージェント１０１外に
配置されている。

【００２０】トラップ送信先アドレス設定部１１０は、
エージェント１０１が送信するTrap-ＰＤＵ１３１の送
信先アドレスを設定するものである。尚、イベントの種
類の違い等、所定の条件に応じて異なるトラップ送信先
アドレスを設定することも可能である。

【００２１】トラップ送信処理部１２０は、trapオペレ
ーションを行うべきイベントが発生したときTrap-ＰＤ
Ｕ１３１を作成し、作成されたTrap-ＰＤＵ１３１に従
ってトラップ送信プロセス１３０−１〜ｎを起動するも
のである。尚、トラップ送信先アドレス設定部１１０と
トラップ送信処理部１２０とがトラップ送信先設定手段
に相当する。

【００２２】トラップ送信プロセス１３０−１〜１３０
−ｎは、Trap-ＰＤＵ１３１を受信すると予測されるト
ラップ受信予定者のアドレスをトラップ受信予定リスト
１３２に記録するとともに、Trap-ＰＤＵ１３１を送信
先に送信するＰＤＵ送信手段であり、トラップ送受信ア
ドレスデータベース１７０の内容の更新も行う。

【００２３】Trap-ＰＤＵ１３１はＳＮＭＰ標準のTrap-
ＰＤＵであり、time-stampフィールドを有している。Ｓ
ＮＭＰの規則では、このtime-stampフィールドに、エー
ジェント１０１が初期化されてからの経過時間を示すTi
meTicks型のタイムスタンプ値を記録することになって
いる。

【００２４】従って、複数のイベントが同時に発生しな
い限り、このtime-stampフィールドに記録されたタイム
スタンプ値によってTrap-ＰＤＵ１３１がどのイベント
に対応しているか一意に識別できる。このタイムスタン
プ値がTrap-ＰＤＵ１３１を一意に識別するためのＰＤ
Ｕ識別データに相当する。各管理ステーション２００−
１〜ｑのマネージャ２０１は自分のアドレスと受信した
Trap-ＰＤＵ１３１のタイムスタンプ値を用いて受信ト
ラップテーブル１４１の値を変更する変更要求としての
set-requestオペレーションを実行することになってい
るので、各エージェント１０１は受信トラップテーブル
１４１に対するset-requestオペレーションを検査する
ことにより、送ったTrap-ＰＤＵ１３１をどのマネージ
ャ２０１が受信したかをエージェント１０１自身が確認
できる。

【００２５】ＭＩＢ１４０は、ネットワーク管理モデル
の中で管理情報の集まりを仮想的なデータベースとして
扱ったものであり、ＳＮＭＰエージェントが標準的に備
えているデータベースに加え、受信トラップテーブル
（trapReceiveTable）１４１も備えている。

【００２６】受信トラップテーブル１４１は、Trap-Ｐ
ＤＵ１３１を受信したマネージャのアドレスを表すオブ
ジェクト（trapReceivedAddress）とTrap-ＰＤＵ１３１
のtime-stampを表すオブジェクト（trapReceiveTimeSta
mp）の少なくとも２つのオブジェクトを有するエントリ
（trapReceivedEntry）を備えたテーブルオブジェクト
である。図３は、具体例１の受信トラップテーブル１４
１に記録されたデータの一例を示す説明図である。図
中、トラップ受信者がTrap-ＰＤＵ１３１を受信したマ
ネージャのアドレスを表すオブジェクトであり、タイム
スタンプがTrap-ＰＤＵ１３１のtime-stampが表すオブ
ジェクトである。

【００２７】図４は、具体例１の受信トラップテーブル
１４１の定義例を示す説明図である。ただし、この定義
例では、受信トラップテーブル１４１のオブジェクト名
が未定義になっている。セット受信処理部１５０は、セ
ット受信処理手段に相当するものであり、マネージャ２
０１からのSetRequest-ＰＤＵを受信してそれに応じたG
etResponse-ＰＤＵを送信するというＳＮＭＰエージェ
ント標準のものであり、受信したSetRequest-ＰＤＵが
ＭＩＢ１４０の受信トラップテーブル１４１に対するオ
ペレーションであるときは、その受信トラップテーブル
１４１の内容を変更すると共に、トラップ受信確認プロ
セス１６０にSetRequest-ＰＤＵの内容を通知する。

【００２８】トラップ受信確認プロセス１６０は、セッ
ト受信処理部１５０からの通知を受けてトラップ受信予
定リスト１３２とトラップ送受信アドレスデータべース
１７０を更新するトラップ受信確認手段であり、Trap-
ＰＤＵ１３１の送信先アドレスを保存するトラップ送信
アドレスデータベース１６１を備えている。

【００２９】図５は、具体例１のトラップ送信アドレス
データベース１６１に記録されたデータの一例を示す説
明図である。このトラップ送信アドレスデータベース１
６１がトラップ送信データベースに相当する。

【００３０】トラップ送受信アドレスデータベース１７
０は、トラップ送受信データベースに相当するものであ
り、Trap-ＰＤＵ１３１の送信先アドレスと受信者アド
レスとを関連付けて記録するデータベースである。図６
は、具体例１のトラップ送受信アドレスデータベース１
７０に記録されたデータの一例を示す説明図である。

【００３１】管理ステーション２００−１〜ｑの各マネ
ージャ２０１は、トラップ受信処理部２１１とセット送
信処理部２１２とを備えている。トラップ受信処理部２
１１は、トラップ受信処理手段に相当するものであり、
ＮＥ１００−１〜ｐのエージェント１０１から送信され
たTrap-ＰＤＵ１３１を受信し、そのTrap-ＰＤＵ１３１
を利用してＭＩＢ１４０の受信トラップテーブル１４１
の変更を指示するset-requestオペレーションの実行を
セット送信処理部２１２に依頼する。

【００３２】セット送信処理部２１２は、トラップ受信
処理部２１１からの依頼を受けてSetRequest-ＰＤＵを
作成し、このSetRequest-ＰＤＵをエージェント１０１
へ送信してエージェント１０１からGetResponse-ＰＤＵ
を受信するセット送信処理手段である。

【００３３】〈動作〉まず、ＳＮＭＰのオペレーション
について説明する。ＳＮＭＰでは、各ＮＥ１００−１〜
ｐを管理するのに４つのオペレーションが定められてい
る。それは、GetRequest，GetNextRequest，SetReques
t，Trapである。

【００３４】Getオペレーションは、オブジェクト識別
子で指定した管理オブジェクトそのものの値を取得する
ときに用いるオペレーションであり、GetNextオペレー
ションは、指定したオブジェクト識別子から見てオブジ
ェクト登録ツリー上のすぐ次にあるオブジェクトの値を
取得するときに用いるオペレーションであり、Setオペ
レーションは、オブジェクト識別子で指定した管理オブ
ジェクトの値を変更するときに用いるオペレーションで
あり、Trapオペレーションは、障害等の管理対象となる
事象（イベント）が発生したとき等にこの事象内容を報
告するときに用いるオペレーションである。

【００３５】このうち、GetNextRequest，GetNextReque
st，SetRequestは、マネージャがエージェントに対して
行うオペレーションであり、Trapオペレーションは、エ
ージェントが自律的に報告するオペレーションである。
GetNextRequest，GetNextRequest，SetRequestについて
は、その応答としてエージェントからGetResponseが返
送されるが、Trapオペレーションについては、マネージ
ャからの応答はない。具体例１では、エージェント１０
１がTrap-ＰＤＵ１３１を送信してTrapオペレーション
を行い、マネージャ２０１はSetRequestを用いて送信元
エージェント１０１の受信トラップテーブル１４１の値
を変更する。

【００３６】次に各ブロックの動作を順次説明する。ま
ず、トラップ送信処理部１２０の動作について説明す
る。図７は、具体例１のトラップ送信処理部１２０の動
作を示すフローチャートである。尚、図１１は、具体例
１の全体動作を示す説明図であり、図中、該当ステップ
は、各ブロックのステップに対応している。ステップ
（図中、ステップを「Ｓ」と記す。）１では、エージェ
ント１０１の初期化後、Trap-オペレーション起動イベ
ントが発生するまで待機する。そして、例えば、障害等
の管理対象となる事象（イベント）が発生したときは、
ステップ２に進む。

【００３７】ステップ２では、Trap-ＰＤＵ１３１を作
成する。ステップ３では、このTrap-ＰＤＵ１３１に基
づいてトラップ送信プロセス１３０−１〜ｎを起動す
る。

【００３８】トラップ送信プロセス１３０−１〜ｎを起
動した後は、再びTrap-オペレーション起動イベントが
発生するまで待機する。

【００３９】次にトラップ送信プロセス１３０−１〜ｎ
の動作について説明する。尚、ここでは、トラップ送信
プロセス１３０−１〜ｎのうちのトラップ送信プロセス
１３０−１が起動されたものとして説明する。図８は、
起動したトラップ送信プロセス１３０−１の動作を示す
フローチャートである。ステップ１１では、初めにトラ
ップ送信先アドレス設定部１１０からTrap-ＰＤＵ１３
１に応じたトラップ送信先アドレスを取得する。

【００４０】ステップ１２では、トラップ送受信アドレ
スデータベース１７０から、Trap-ＰＤＵ１３１を受信
することが予測されるトラップ受信予定者のアドレスを
検索し、そのアドレスをトラップ受信予定リスト１３２
に記録する。

【００４１】ステップ１３では、送信するTrap-ＰＤＵ
１３１のタイムスタンプ値と送信先のアドレスをトラッ
プ送信アドレスデータベース１６１に追加する。図５に
示すように、トラップ送信アドレスデータベース１６１
には、トラップ送信先として送信先アドレスAddress1〜
Address4が、それぞれTrap-ＰＤＵ１３１と関連付けら
れて記録される。

【００４２】ステップ１４では、トラップ送信アドレス
データベース１６１に記録されている送信先のアドレス
を指定してマネージャ２０１へTrap-ＰＤＵ１３１を送
信する。トラップ送信先アドレスが複数記録されている
ときは、Trap-ＰＤＵ１３１も複数送信される。

【００４３】トラップ送信プロセス１３０−１は、Trap
-ＰＤＵ１３１のトラップ受信確認のため、ステップ１
５において所定時間待機する。この間にTrap-ＰＤＵ１
３１を受信したマネージャ２０１では、トラップ受信処
理部２１１がマネージャ２０１自身のアドレスとそのTr
ap-ＰＤＵ２３１のタイムスタンプ値を用いて受信トラ
ップテーブル１４１の値の変更を要求するset-request
オペレーションの実行を同じマネージャ２０１内のセッ
ト送信処理部２１２へ依頼する。

【００４４】依頼されたセット送信処理部２１２は、Se
tRequest-ＰＤＵを作成してこれをTrap-ＰＤＵ１３１の
送信元のエージェント１０１へ送信する。そして、セッ
ト受信処理部１５０がこのSetRequest-ＰＤＵを受信し
たとき、トラップ受信確認プロセス１６０にSetRequest
-ＰＤＵの内容が通知され、トラップ受信予定リスト１
３２からトラップ受信予定者のアドレスを削除される。
従って、所定時間待機した後にトラップ受信予定リスト
１３２にトラップ受信予定者のアドレスが残っているか
否かを調べることによりTrap-ＰＤＵ１３１を受信した
かどうかを確認できる。尚、セット受信処理部１５０及
びトラップ受信確認プロセス１６０の動作については後
述する。

【００４５】ステップ１６では、トラップ受信予定リス
ト１３２にトラップ受信予定者のアドレスが残っている
かどうかを調べる。このアドレスが残っているときは、
ステップ１７に進み、このTrap-ＰＤＵ１３１を再送す
るかどうかを判断する。

【００４６】Trap-ＰＤＵ１３１を再送しないときは、
ステップ１８に進む。ステップ１８では、トラップ受信
者をトラップ送受信アドレスデータベース１７０から削
除してトラップ送受信アドレスデータベース１７０を更
新する。

【００４７】ステップ１７において、再送すると判断し
たときは、ステップ１９に進む。ステップ１９では、ト
ラップ送信先アドレス設定部１１０によって設定された
送信先へこのTrap-ＰＤＵ１３１を送信する。このとき
送信するTrap-ＰＤＵ１３１の数は、トラップ受信予定
リスト１３２に記録されているトラップ受信予定者のア
ドレス数となる。

【００４８】Trap-ＰＤＵ１３１の再送後、ステップ１
５に戻り、再びトラップ受信確認待ちが行われる。この
ようにして、Trap-ＰＤＵ１３１を順次送信し、ステッ
プ１６において、送信すべきTrap-ＰＤＵ１３１が残っ
ていないと判定したときは、動作を終了させる。

【００４９】次に、セット受信処理部１５０の動作につ
いて説明する。図９は、具体例１のセット受信処理部１
５０の動作を示すフローチャートである。ステップ２１
では、エージェント１０１の初期化後、セット受信処理
部１５０はSetRequest-ＰＤＵを受信するまで待機す
る。セット受信処理部１５０がSetRequest-ＰＤＵを受
信したとき、ステップ２２に進む。

【００５０】ステップ２２では、管理オブジェクトの値
を変更してGetResponse-ＰＤＵを送信する。これはset-
requestオペレーションに対する通常の処理である。

【００５１】ステップ２３では、受信したset-request
オペレーションが受信トラップテーブル１４１に対する
オペレーションかどうかを調べる。受信したSetRequest
-ＰＤＵが、テーブルオブジェクトである受信トラップ
テーブル１４１に対するオペレーションであると判定し
たとき、そのインデックスのエントリが存在しない場合
は新たにエントリを追加する。図３に示すように、受信
トラップテーブル１４１に新たなエントリが追加されて
Trap-ＰＤＵ１３１を受信したトラップ受信者とそのタ
イプスタンプ値とが記録される。

【００５２】ステップ２４では、通知待ちのトラップ受
信確認プロセス１６０に、受信したSetRequest-ＰＤＵ
の内容を通知する。通知後、再びステップ２１に戻る。

【００５３】次に、トラップ受信確認プロセス１６０の
動作について説明する。図１０は、具体例１のトラップ
受信確認プロセス１６０の動作を示すフローチャートで
ある。ステップ３１は、エージェント１０１の初期化後
に前述した通知をセット受信処理部１５０から受けるま
で待機するステップである。セット受信処理部１５０か
ら通知を受けてステップ３２に進む。

【００５４】ステップ３２では、トラップ送信プロセス
１３０−１のトラップ受信予定リスト１３２から、送信
済みのトラップ受信予定者のアドレスを削除する。前述
のように、これによってTrap-ＰＤＵ１３１の受信確認
が行われる。

【００５５】ステップ３３では、time-stampフィールド
に、変更されたタイムスタンプ６１２の値を有するTrap
-ＰＤＵ１３１の送信先アドレスを、トラップ送信アド
レスデータべース１６１から検索し、検索された送信先
アドレスと変更されたトラップ受信者のアドレスを用い
てトラップ送受信アドレスデータベース１７０を更新す
る。この後、トラップ受信確認プロセス１６０は、ステ
ップ３１に戻り、再びセット受信処理部１５０からの通
知を受けるまで待機する。尚、トラップ送信アドレスデ
ータべース１６１の古いデータは、トラップ受信確認プ
ロセス１６０によって削除されるか、あるいはデータ追
加時に新しいデータによって上書きされる。

【００５６】次に、Trap-ＰＤＵ１３１の送受信を行っ
たときの各データの遷移について説明する。図１２〜図
１４は、Trap-ＰＤＵ１３１の送受信を行ったときの具
体例１のトラップ送受信アドレスデータベース１７０と
受信トラップテーブル１４１に記録されたデータの変化
を示す説明図である。図１２の（１）はエージェントの
初期状態を示す。エージェントの初期状態では、トラッ
プ送受信アドレスデータベース１７０と受信トラップテ
ーブル１４１とは空になっている。

【００５７】図１２の（２）は、例えばタイムスタンプ
値２０を有するTrap-ＰＤＵ１３１を、トラップ送信先
としてAddress１とAddress２を指定して送信したとき、
Manager１〜Manager４が受信トラップテーブル１４１に
対するset-requestオペレーションを行ったときの結果
を示す。ここで、Manager１〜Manager４は、管理ステー
ション２００−１〜ｑのうちのいずれかのマネージャ２
０１を示す。

【００５８】図１３の（３）は、次にタイムスタンプ値
１００を有するTrap-ＰＤＵ１３１をAddress１に送信し
たとき、Manager１，Manager２が受信トラップテーブル
１４１に対するset-requestオペレーションを行った結
果を示す。

【００５９】図１３の（４）は、次にタイムスタンプ値
５００を有するTrap-ＰＤＵ１３１をAddress３に送信し
たときに、Manager１が受信トラップテーブル１４１に
対するset-requestオペレーションを行った結果を示
す。

【００６０】図１４の（５）は、次にタイムスタンプ値
１０００を有するTrap-ＰＤＵ１３１をAddress４に送信
したときに、Manager３が受信トラップテーブル１４１
に対するset-requestオペレーションを行った結果を示
す。このようにトラップ送受信アドレスデータベース１
７０に送信先アドレスと受信者アドレスとが関連付けら
れて記録され、両アドレスの関係が明確になる。

【００６１】図１４の（６）は、この後の動作結果を示
す。即ち、タイムスタンプ値３０００を有するTrap-Ｐ
ＤＵ１３１を再びAddress１とAddress２に送信したと
き、Manager１，Manager２，Manager３，Manager４によ
って受信トラップテーブル１４１に対するset-request
オペレーションが行われることが予想されるので、これ
らのマネージャ２０１のアドレスをトラップ受信予定リ
スト１３２に登録する。

【００６２】Trap-ＰＤＵ１３１をAddress１とAddress
２に送信後、もしManager１から受信トラップテーブル
１４１へのset-requestオペレーションが行われなかっ
たときは、トラップ受信予定リスト１３２にそのアドレ
スが残っているので、エージェント１０１はManager１
へそのTrap-ＰＤＵ１３１を再送する。それでも受信ト
ラップテーブル１４１に対するset-requestオペレーシ
ョンが行われなかったときは、Manager１のアドレスを
トラップ送受信アドレスデータベース１７０から削除す
る。これにより、トラップ送受信アドレスデータべース
１７０は動的に更新される。

【００６３】〈具体例１の効果〉以上、説明したように
具体例１によれば、ＭＩＢ１４０に受信トラップテーブ
ル１４１を備え、Trap-ＰＤＵ１３１を受信したマネー
ジャ２０１が受信トラップテーブル１４１の値を変更す
るset-requestオペレーションを送信し、受信トラップ
テーブル１４１の値を変更してトラップ受信者とTrap-
ＰＤＵ１３１のタイムスタンプ値とを記録するようにし
たので、複数の送信先にTrap-ＰＤＵ１３１を送信した
ときでも、エージェント１０１が受信トラップテーブル
１４１に対するset-requestオペレーションの有無を検
査することにより、送信したTrap-ＰＤＵ１３１がどの
マネージャ２０１によって受信されたかを送信元のエー
ジェント１０１側で確認することができる。

【００６４】従って、その送信先アドレスとは必ずしも
一致しない複数のマネージャ２０１がこのTrap-ＰＤＵ
を受信したときでも、エージェント１０１自身が、送信
したTrap-ＰＤＵ１３１を受信できなかったマネージャ
２０１がいないかどうかを判断することができる。

【００６５】そして、受信できなかったマネージャ２０
１があると判断したとき、エージェント１０１がそのマ
ネージャ２０１にTrap-ＰＤＵ１３１を再送するように
したので、ＳＮＭＰを利用したネットワーク管理システ
ムにおいても、trapオペレーションの信頼性を向上させ
ることができる。

【００６６】さらに、送信先として指定されなかった他
のマネージャ２０１も、このエージェント１０１の受信
トラップテーブル１４１に対してget-requestオペレー
ションやset-requestオペレーションを行うことによ
り、このエージェント１０１のtrapオペレーションを受
けている他のマネージャ２０１を確認することも可能と
なる。

【００６７】尚、具体例１では、ＳＮＭＰを利用したネ
ットワーク管理システムについて説明したが、これに限
られるものではなく、その他のプロトコルを利用したネ
ットワーク管理システムにおいてエージェントが自発的
に送信したＰＤＵの記録をオブジェクトとして表す場合
にも適用可能である。以下の具体例についても同様であ
る。

【００６８】〈具体例２〉具体例２は、エージェント内
に送信トラップテーブルを備え、エージェントがTrap-
ＰＤＵの送信先であるエントリをこの送信トラップテー
ブルに追加し、マネージャがこの送信トラップテーブル
を検索することにより、受信できなかったTrap-ＰＤＵ
の有無をマネージャ側で確認できるようにしたものであ
る。

【００６９】図１５は、具体例２の構成を示すブロック
図である。各ＮＥ１００−１〜ｐのエージェント１０１
は、トラップ送信処理部１２０と、ＭＩＢ１４０と、を
備えて構成され、ＭＩＢ１４０は、受信トラップテーブ
ル１４１と、送信トラップテーブル（trapSendTable）
１４２とを備えている。

【００７０】まず、具体例２の各ＮＥ１００−１〜ｐの
構成について説明する。送信トラップテーブル１４２
は、そのエージェント１０１が送信するTrap-ＰＤＵ１
３１を一意に識別するために付けられた番号を表すオブ
ジェクト（trapSendIndex）とTrap-ＰＤＵの送信先アド
レスを表すオブジェクト（trapSendAddress）、少なく
ともこの２つのオブジェクトを有するエントリ（trapSe
ndEntry）を備えたテーブルオブジェクトである。

【００７１】ＳＮＭＰでは、送信トラップテーブル１４
２の送信トラップインデックスがTrap-ＰＤＵ１３１の
ＶＢＬ（Variable Binding List）に必ず含まれてい
る。図１６は、具体例２の送信トラップテーブル１４２
に記録されたデータの一例を示す説明図である。この図
１６に示すように、送信トラップインデックスがTrap-
ＰＤＵ１３１を一意に識別するために付けられた番号を
表すオブジェクトであり、トラップ送信先がTrap-ＰＤ
Ｕ１３１の送信先アドレスを表すオブジェクトである。

【００７２】尚、送信トラップテーブル１４２に、さら
にTrap-ＰＤＵのgeneric-trapフィールドやtime-stamp
フィールド等のオブジェクトも有するエントリを備える
ようにすれば、より詳細なTrap-ＰＤＵ１３１の情報を
表現できる。図１７は、具体例２の送信トラップテーブ
ル１４２の定義例を示す説明図である。ただし、この定
義例では、送信トラップテーブルのオブジェクト名が未
定義になっている。

【００７３】次に、管理ステーション２００−１〜ｑの
構成について説明する。管理ステーション２００−１〜
ｑのマネージャ２０１は、トラップ受信処理部２１１
と、受信トラップデータベース２１３と、ゲット送信処
理部２１４と、トラップ確認処理部２１５と、を備えて
構成されている。

【００７４】具体例２のトラップ受信処理部２１１は、
エージェント１０１が送信したTrap-ＰＤＵを受信してT
rap-ＰＤＵ１３１を受信トラップデータベース２１３に
記録するものである。

【００７５】受信トラップデータベース２１３は、マネ
ージャ２０１が受信したTrap-ＰＤＵ１３１の全てのデ
ータを記録するデータベースである。図１８は、具体例
２の受信トラップデータベース２１３に記録されたデー
タの一例を示す説明図である。前述のようにエージェン
ト１０１が送信するTrap-ＰＤＵのＶＢＬには送信トラ
ップテーブル１４２の送信トラップインデックスが含ま
れているので、他のエージェント１０１が送信したTrap
-ＰＤＵ１３１と区別することができる。従って、受信
トラップデータベース２１３には、あらゆるエージェン
ト１０１が送信したTrap-ＰＤＵを保存しておくことが
できる。

【００７６】ゲット送信処理部２１４は、GetRequest -
ＰＤＵもしくはGetNextRequest-ＰＤＵを作成してエー
ジェント１０１へ送信し、エージェント１０１からGetR
esponse-ＰＤＵを受信し、当該マネージャ２０１が受信
可能なTrap-ＰＤＵ１３１の送信トラップインデックス
を取得するゲット送信処理手段である。

【００７７】トラップ確認処理部２１５は、送信トラッ
プテーブル１４２を検索するgetrequestオペレーション
あるいはget-next-requestオペレーションの実行をゲッ
ト送信処理部２１４に依頼し、取得した送信トラップイ
ンデックスと受信トラップデータベースに記録されたTr
ap-ＰＤＵ１３１とを比較して受信できなかったTrap-Ｐ
ＤＵ１３１の有無を確認するＰＤＵするトラップ確認処
理手段である。

【００７８】〈動作〉まず、トラップ送信処理部１２０
の動作について説明する。図１９は、具体例２のトラッ
プ送信処理部１２０の動作を示すフローチャートであ
る。ステップ４１では、エージェント１０１を初期化
し、その後、trapオペレーション起動イベントが発生す
るまで待機する。trapオペレーション起動イベントが発
生したときは、ステップ４２に進む。ステップ４２で
は、トラップ送信先アドレス設定部１１０からトラップ
送信先のアドレスを取得する。

【００７９】ステップ４３では、送信トラップテーブル
１４２に、取得したアドレスを新しいエントリとして追
加する。尚、トラップ送信先が複数のときは、送信トラ
ップテーブル１４２の送信トラップインデックスを整数
として、エントリを追加するたびに１ずつ送信トラップ
インデックスを増やしていけば、Trap-ＰＤＵ１３１の
送信順にトラップ送信先のアドレスが記録される。つま
り送信されるTrap-ＰＤＵ１３１の内容は、同じイベン
トでもトラップ送信先が異なる場合には、異なるものと
なる。

【００８０】ステップ４４では、追加したエントリの送
信トラップインデックスをＶＢＬに有するTrap-ＰＤＵ
１３１を作成する。ステップ４５では、作成したTrap-
ＰＤＵ１３１を送信する。

【００８１】ステップ４６では、トラップ送信先のアド
レスがあるかどうかを判定する。まだあるときは、ステ
ップ４３に戻り、ステップ４３〜４５を実行する。トラ
ップ送信先のアドレスがなくなったときは、ステップ４
１に戻り、再び次のtrapオペレーション起動イベントが
発生するまで待機する。

【００８２】次に、トラップ確認処理部２１５の動作に
ついて説明する。図２０は、具体例２のトラップ確認処
理部２１５の動作を示すフローチャートである。ステッ
プ５１では、指定されたエージェント１０１の送信トラ
ップテーブル１４２の全エントリを検索するためにget-
next-requestオペレーションの実行をゲット送信処理部
２１４に繰り返し依頼する。

【００８３】ゲット送信処理部２１４は、この依頼を受
けてGetRequest-ＰＤＵもしくは GetNextRequest-ＰＤ
Ｕを作成し、このオペレーションをエージェント１０１
へ送信し、エージェント１０１からGetResponse-ＰＤＵ
を受信し、エージェント１０１の送信トラップテーブル
１４２から、当該マネージャ２０１が受信可能なTrap-
ＰＤＵ１３１を抽出する。

【００８４】通常、エージェント１０１が送信するTrap
-ＰＤＵ１３１のトラップ送信先のアドレスは、マネー
ジャ２０１のアドレスを直接指定するアドレスであると
は限らず、ブロードキャストアドレスやマルチキャスト
アドレスであることもある。

【００８５】エージェント１０１にとっては、このアド
レスによってどのマネージャ２０１が受信できるかを特
定することはできないが、マネージャ２０１にとっては
このアドレスが自分を含む機器へのブロードキャストな
のか、あるいはマルチキャストなのかを判断できるの
で、マネージャ２０１は、送信トラップテーブル１４２
の全エントリの検索結果から受信可能なTrap-ＰＤＵ１
３１だけを抽出することが可能となる。そして、抽出し
た受信可能なTrap-ＰＤＵ１３１の送信トラップインデ
ックスを取得してその送信トラップインデックスをトラ
ップ確認処理部２１５に送る。

【００８６】ステップ５２では、この送信トラップイン
デックスを用いて受信トラップデータベース２１３を検
索する。ステップ５３では、取得した送信トラップイン
デックスと受信トラップデータベース２１３に記録され
ている指定されたエージェント１０１が送信したTrap-
ＰＤＵ１３１とを比較する。そして抽出の結果、受信ト
ラップデータベース２１３に含まれていないTrap-ＰＤ
Ｕ１３１のＶＢＬが有している送信トラップテーブル１
４２の送信トラップインデックスを返却してこのルーチ
ンを終了させる。

【００８７】〈具体例２の効果〉以上、説明したように
具体例２によれば、ＭＩＢ１４０に送信トラップテーブ
ル１４２を備え、エージェント１０１がこの送信トラッ
プテーブル１４２に送信トラップインデックスとトラッ
プ送信先を記録するようにしたので、マネージャ２０１
がこの送信トラップテーブル１４２を検索することによ
り、各マネージャ２０１は、エージェント１０１が送信
したTrap-ＰＤＵの送信先アドレスを確認することがで
きる。従って、本人が受信できなかったTrap-ＰＤＵ１
３１があるかどうかを確認することもできるし、他のマ
ネージャ２０１が受信すべきTrap-ＰＤＵとしてどのよ
うなTrap-ＰＤＵがあるかを確認することもできる。

【００８８】〈具体例３〉具体例３は、エージェント内
に送信トラップテーブルと受信トラップテーブルとを備
え、この２つのトラップテーブルにトラップ送信先、ト
ラップ受信者、トラップ再送信先を記録することによ
り、受信できなかったTrap-ＰＤＵがあるかどうかをマ
ネージャ及びエージェントが確認できるようにしたもの
である。

【００８９】図２１は、具体例３の構成を示すブロック
図である。まず、具体例３のエージェント１０１の構成
について説明する。具体例３のエージェント１０１は、
トラップ再送処理部１８０と、トラップデータベース１
９０と、を備えている。

【００９０】トラップデータベース１９０は、トラップ
送信プロセス１３０−１〜ｎによって送信されるTrap-
ＰＤＵ１３１を保存するためのデータベースである。ト
ラップ再送処理部１８０は、送信トラップテーブル１４
２に後述するトラップ再送信先が記録されているとき、
その送信トラップインデックスに基づいてトラップデー
タベース１９０を検索し、マネージャ２０１が受信でき
なかったTrap-ＰＤＵ１３１を再送信するトラップ再送
処理手段である。

【００９１】具体例３のセット受信処理部１５０は、マ
ネージャ２０１からSetRequest-ＰＤＵを受信し、この
オペレーションが受信トラップテーブル１４１に対する
第１の変更要求としてのオペレーションであってそのエ
ントリが存在しないときは、受信トラップテーブル１４
１にエントリを追加してトラップ受信確認プロセス１６
０にSetRequest-ＰＤＵの内容を通知し、送信トラップ
テーブル１４２のトラップ再送信先に対する第２の変更
要求としてのオペレーションであるときは、送信トラッ
プテーブル１４２のトラップ再送信先に、そのアドレス
を記録する。

【００９２】図２２は、具体例３の受信トラップテーブ
ル１４１に記録されたデータの一例を示す説明図であ
る。図２２に示すように、具体例３の受信トラップテー
ブル１４１には、受信トラップインデックスとトラップ
受信者とが記録される。受信トラップインデックスは、
受信したTrap-ＰＤＵを一意に識別するために付けられ
た番号を表すオブジェクトであり、トラップ受信者はTr
ap-ＰＤＵを受信したマネージャ２０１のアドレスを表
すオブジェクトである。

【００９３】図２３は、具体例３の受信トラップテーブ
ル１４１の定義例を示す説明図である。ただし、この定
義例では、受信トラップテーブル１４１のオブジェクト
名が未定義になっている。

【００９４】図２４は、具体例３の送信トラップテーブ
ル１４２に記録されたデータの一例を示す説明図であ
る。図２４に示すように、具体例３の送信トラップテー
ブル１４２には、少なくとも送信トラップインデックス
（trapSendedIndex）と、トラップ送信先（trapSendedA
ddress）と、トラップ再送信先（trapSendedAgainAddre
ss）と、が記録される。尚、Trap-ＰＤＵのgeneric-tra
pフィールドやtime-stampフィールドなども用いれば、
より詳細な情報を送受信することができる。

【００９５】図２５は、具体例３の送信トラップテーブ
ル１４２の定義例を示す説明図である。ただし、この定
義例では、送信トラップテーブル１４２のオブジェクト
名が未定義になっている。

【００９６】次に、具体例３の管理ステーション２００
−１〜ｑの構成について説明する。具体例３の管理ステ
ーション２００−１〜ｑは、トラップ再送要求処理部２
１６を備えている。

【００９７】トラップ再送要求処理部２１６は、エージ
ェント１０１に対して送信トラップテーブル１４２のト
ラップ再送信先にアドレスを設定するsetrequestオペレ
ーションの実行をセット送信処理部２１２に依頼するト
ラップ再送要求処理手段である。尚、具体例１及び具体
例２と同一要素については同一符号を付して説明を省略
する。

【００９８】〈動作〉トラップ送信プロセス１３０−１
〜ｎは、具体例１と同じように、Trap-オペレーション
起動イベントが発生したとき、トラップ送信処理部１２
０によって起動される。図２６は、具体例３の起動した
トラップ送信プロセス１３０−１〜ｎの動作を示すフロ
ーチャートである。

【００９９】具体例１では、図８のステップ１３におい
て、トラップ送信アドレスデータベース１６１にTrap-
ＰＤＵ１３１のタイムスタンプ値と送信先アドレスをト
ラップ送信アドレスデータベース１６１に追加するよう
にしたが、具体例３では、この図２６に示すように、ス
テップ６１において、Trap-ＰＤＵ１３１をトラップデ
ータベース１９０に保存する。

【０１００】そして、具体例１と同じように動作してTr
ap-ＰＤＵ１３１を各マネージャ２０１に送信する。
尚、具体例１と同じ動作をするステップについては同一
ステップ符号を付して説明を省略する。

【０１０１】次に、具体例３のセット受信処理部１５０
の動作について説明する。図２７は、具体例３のセット
受信処理部１５０の動作を示すフローチャートである。
ステップ７１では、エージェント１０１の初期化後、セ
ット受信処理部２１１はSetRequest-ＰＤＵを受信する
まで待機する。そしてSetRequest-ＰＤＵを受信してス
テップ７２に進む。

【０１０２】ステップ７２では、管理オブジェクトの値
を変更し、set-requestオペレーションに対する通常の
処理として、GetResponse-ＰＤＵを送信する。テーブル
オブジェクトに対するset-requestオペレーションを行
うとき、そのインデックスのエントリが存在しない場合
は、エージェント１０１は新たにエントリを追加する。

【０１０３】ステップ７３では、受信したSetRequest-
ＰＤＵが受信トラップテーブル１４１に対するオペレー
ションであるかどうかを判定する。受信トラップテーブ
ル１４１に対するオペレーションであると判定したとき
は、ステップ７４に進む。

【０１０４】ステップ７４では、トラップ受信確認プロ
セス１６０にSetRequest-ＰＤＵの内容を通知する。通
知後、ステップ７１に戻る。ステップ７３において、受
信トラップテーブル１４１に対するオペレーションでは
ないと判定したときは、ステップ７５に進む。

【０１０５】ステップ７５では、受信したSetRequest-
ＰＤＵが送信トラップテーブル１４２のトラップ再送信
先に対するオペレーションであるかどうかを判定する。
送信トラップテーブル１４２のトラップ再送信先に対す
るオペレーションであると判定したときは、ステップ７
６に進む。

【０１０６】ステップ７６では、トラップ再送信先へTr
ap-ＰＤＵ１３１を送信する。どのTrap-ＰＤＵ１３１を
送信するかは、SetRequest-ＰＤＵに基づいて判断でき
る。即ち、SetRequest-ＰＤＵには、送信トラップテー
ブル１４２のどのエントリに対するオペレーションであ
るかが指定されているので、そのエントリの送信トラッ
プインデックスをＶＢＬに有するTrap-ＰＤＵ１３１を
トラップデータべース１９０から検索する。

【０１０７】Trap-ＰＤＵ１３１を送信した後は、受信
トラップテーブル１４１のトラップ再送信先を元の値へ
戻す。トラップ再送処理部１８０は、指定された送信ト
ラップテーブル１４２の送信トラップインデックスをＶ
ＢＬに有しているTrap-ＰＤＵ１３１をトラップデータ
ベース１９０から検索し、指定されたアドレスへ送信す
る。

【０１０８】トラップ受信処理部２１１は、エージェン
ト１０１からのTrap-ＰＤＵ１３１を受信し、受信したT
rap-ＰＤＵ１３１を受信トラップデータベース２１３へ
保存する。更に受信したTrap-ＰＤＵ１３１が、エージ
ェント１０１からのTrap-ＰＤＵ１３１である場合、自
分のアドレスとそのTrap-ＰＤＵ１３１のＶＢＬが有し
ている送信トラップテーブル１４２の送信トラップイン
デックスの値を使って受信トラップテーブル１４１の値
を変更するset-requestオペレーションの実行をセット
送信処理部２１２へ依頼する。

【０１０９】トラップ再送要求処理部２１６は、エージ
ェント１０１に対して送信トラップテーブル１４２のト
ラップ再送信先の値をマネージャ２０１のアドレスに設
定する再送要求としてのset-requestオペレーションの
実行をセット送信処理部２１２に依頼する。このset-re
questオペレーションにより、指定されたエージェント
１０１はマネージャ２０１に指定されたTrap-ＰＤＵ１
３１を再送する。

【０１１０】次に、具体例３の各データの遷移について
説明する。図２８〜図３２は、具体例３の各データの変
化を示す説明図である。

【０１１１】図２８の（１）に示すように、まずエージ
ェント１０１の初期状態において、トラップ送受信アド
レスデータベース１７０と受信トラップテーブル１４
１、送信トラップテーブル１４２に記録されているもの
はなにもない。

【０１１２】図２８の（２）は、トラップ送信先として
Address１とAddress２を指定してTrap-ＰＤＵ１３１を
送信し、トラップ送信先のManager１〜４が受信トラッ
プテーブル１４１に対するset-requestオペレーション
を行った結果を示す。

【０１１３】図２９の（３）は、Trap-ＰＤＵ１３１を
次にAddress３とAddress４を指定して送信したときに、
Manager１とManager３が受信トラップテーブル１４１に
対するset-requestオペレーションを行った結果を示
す。このようにして送信先アドレスと受信者アドレスの
関係が明確になる。

【０１１４】図３０の（４）は、その後、Trap-ＰＤＵ
１３１を再びAddress１を指定して送信したときのデー
タを示す。エージェント１０１は、Manager１とManager
２が受信トラップテーブル１４１に対するset-request
オペレーションを行うことを予想してこれらのマネージ
ャ２０１のアドレスをトラップ受信予定リスト１３２に
登録する。

【０１１５】Trap-ＰＤＵ１３１をAddress１の送信先に
送信後、もしManager１から受信トラップテーブル１４
１に対するset-requestオペレーションが行われなかっ
たときは、エージェント１０１はManager１へそのTrap-
ＰＤＵ１３１を再送する。それでも受信トラップテーブ
ル１４１に対するset-requestオペレーションが行われ
なかったときは、Manager１のアドレスはトラップ送受
信アドレスデータベース１７０から削除される。このよ
うにして、トラップ送受信アドレスデータベース１７０
が動的に更新される。

【０１１６】図３１の（５）は、次に、Manager１がこ
のエージェント１０１の送信トラップテーブル１４２の
トラップ再送信先に対するset-requestオペレーション
を実行したときの結果を示す。送信トラップテーブル１
４２には、トラップ再送信先としてManager１が記録さ
れ、エージェント１０１は、トラップ送信先のアドレス
を指定してTrap-ＰＤＵ１３１を再送する。

【０１１７】図３２の（６）は、そしてManager１が受
信トラップテーブル１４１に対するset-requestオペレ
ーションを行った結果を示し、Trap-ＰＤＵ１３１の再
送後、トラップ再送信先には、記録されたデータが存在
しなくなる。尚、具体例３では、マネージャ２０１自身
が再送要求を行ったTrap-ＰＤＵ１３１を受信した場合
も受信トラップテーブル１４１に対するset-requestオ
ペレーションを行い、エージェント１０１はトラップ送
受信アドレスデータベース１７０を更新する。

【０１１８】〈具体例３の効果〉以上、説明したように
具体例３によれば、ＭＩＢ１４０に受信トラップテーブ
ル１４１と送信トラップテーブル１４２とを備え、それ
ぞれトラップ受信者、トラップ送信先及びトラップ再送
信先を記録するようにしたので、送信したTrap-ＰＤＵ
１３１を受信できなかったマネージャ２０１がいるかど
うかを、エージェント１０１側、マネージャ２０１側で
判断することが可能となる。

【０１１９】従って、エージェント１０１がTrap-ＰＤ
Ｕ１３１を再送するかどうかを判断することもできる
し、マネージャ２０１自身も自分が受信していないTrap
-ＰＤＵを確認することができ、エージェント１０１に
対してTrap-ＰＤＵの再送を要求することもでき、trap
オペレーションの信頼性をさらに向上させることができ
る。

【０１２０】さらに、受信トラップテーブル１４１と送
信トラップテーブル１４２に対してget-requestオペレ
ーションやgeｔ-next-requestオペレーションを行うこ
とにより、ネットワーク管理システム全体のtrapオペレ
ーションが正常に行われているかどうかを確認すること
が可能となる。

【０１２１】従って、複数の管理ステーションが各々異
なる役割を有する複数のＮＥを管理する協調的なネット
ワーク管理システムにおいて、特に信頼性についての効
果は大きい。

【図面の簡単な説明】

【図１】具体例１の構成を示すブロック図である。

【図２】ネットワーク管理システムのシステム構成を示
すブロック図である。

【図３】具体例１の受信トラップテーブルに記録された
データ例を示す説明図である。

【図４】具体例１の受信トラップテーブルの定義例を示
す説明図である。

【図５】具体例１のトラップ送信アドレスデータベース
に記録されたデータの一例を示す説明図である。

【図６】具体例１のトラップ送受信アドレスデータベー
スに記録されたデータの一例を示す説明図である。

【図７】具体例１のトラップ送信処理部の動作を示すフ
ローチャートである。

【図８】具体例１のトラップ送信プロセスの動作を示す
フローチャートである。

【図９】具体例１のセット受信処理部の動作を示すフロ
ーチャートである。

【図１０】具体例１のトラップ受信確認プロセスの動作
を示すフローチャートである。

【図１１】具体例１の全体動作を示す説明図である。

【図１２】具体例１のトラップ送受信アドレスデータベ
ースと受信トラップテーブルに記録されたデータの変化
（その１）を示す説明図である。

【図１３】具体例１のトラップ送受信アドレスデータベ
ースと受信トラップテーブルに記録されたデータの変化
（その２）を示す説明図である。

【図１４】具体例１のトラップ送受信アドレスデータベ
ースと受信トラップテーブルに記録されたデータの変化
（その３）を示す説明図である。

【図１５】具体例２の構成を示すブロック図である。

【図１６】具体例２の送信トラップテーブルに記録され
たデータの一例を示す説明図である。

【図１７】具体例２の送信トラップテーブルの定義例を
示す説明図である。

【図１８】具体例２の受信トラップデータベースに記録
されたデータの一例を示す説明図である。

【図１９】具体例２のトラップ送信処理部の動作を示す
フローチャートである。

【図２０】具体例２のトラップ確認処理部の動作を示す
フローチャートである。

【図２１】具体例３の構成を示すブロック図である。

【図２２】具体例３の受信トラップテーブルに記録され
たデータの一例を示す説明図である。

【図２３】具体例３の受信トラップテーブルの定義例を
示す説明図である。

【図２４】具体例３の送信トラップテーブルに記録され
たデータの一例を示す説明図である。

【図２５】具体例３の送信トラップテーブルの定義例を
示す説明図である。

【図２６】具体例３のトラップ送信プロセスの動作を示
すフローチャートである。

【図２７】具体例３のセット受信処理部の動作を示すフ
ローチャートである。

【図２８】具体例３の各データの変化（その１）を示す
説明図である。

【図２９】具体例３の各データの変化（その２）を示す
説明図である。

【図３０】具体例３の各データの変化（その３）を示す
説明図である。

【図３１】具体例３の各データの変化（その４）を示す
説明図である。

【図３２】具体例３の各データの変化（その５）を示す
説明図である。

【符号の説明】

１ ネットワーク １００−１〜ｐ ネットワークエレメント（ＮＥ） １０１ エージェント １３０−１〜ｎ トラップ送信プロセス １４１ 受信トラップテーブル １４２ 送信トラップテーブル １６０ トラップ受信確認プロセス ２００−１〜ｑ 管理ステーション ２０１ マネージャ

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 15/177 ６８２ Ｈ０４Ｌ 11/00 ３１０Ｄ Ｈ０４Ｌ 12/28

Claims (5)

【特許請求の範囲】
1. 【請求項１】 ネットワークに複数の管理装置と複数の
   被管理装置とを接続し、該被管理装置に所定のイベント
   が発生したとき、当該被管理装置が、イベント内容に対
   応した管理装置に、イベント内容を示すプロトコルデー
   タユニット（以後、「ＰＤＵ」と記す。）を自発的に送
   信することによって複数の管理装置により複数の被管理
   装置を管理するように構成されたネットワーク管理シス
   テムにおいて、 前記被管理装置は、ＰＤＵを送信すべきＰＤＵ送信先及
   びＰＤＵを受信したトラップ受信先を記録するためのト
   ラップ送受信データベースと、 前記ＰＤＵを一意に識別可能なＰＤＵ識別データ及びＰ
   ＤＵ送信先を記録するためのトラップ送信データベース
   と、 前記ＰＤＵ識別データ及びトラップ受信先の管理装置を
   記録するための受信トラップテーブルと、 発生したイベントに応じてＰＤＵ送信先を設定するトラ
   ップ送信先設定手段と、 設定されたＰＤＵ送信先及びＰＤＵ識別データをトラッ
   プ送信データベースに記録し、ＰＤＵ識別データをＰＤ
   Ｕ内に記録し、トラップ送信先設定手段により設定され
   たＰＤＵ送信先に当該ＰＤＵを送信するＰＤＵ送信手段
   と、 前記管理装置から受信トラップテーブルの値の変更を要
   求する変更要求を受信したとき、受信トラップテーブル
   にトラップ受信先及びＰＤＵ識別データを記録するセッ
   ト受信処理手段と、 前記受信トラップテーブルの値が変更されたとき、トラ
   ップ受信先をＰＤＵ送信先と関連付けてトラップ送受信
   データベースに記録するトラップ受信確認手段と、を備
   え、 前記管理装置は、送信されたＰＤＵに記録されたＰＤＵ
   識別データに基づいて受信すべきＰＤＵを受信するトラ
   ップ受信処理手段と、 該トラップ受信処理手段がＰＤＵを受信したとき、当該
   装置をトラップ受信先としてＰＤＵに記録されているＰ
   ＤＵ識別データを用いてＰＤＵ送信元に前記変更要求を
   送信するセット送信処理手段と、を備えて構成されたこ
   とを特徴とするネットワーク管理システム。
2. 【請求項２】 ネットワークに複数の管理装置と複数の
   被管理装置とを接続し、該被管理装置に所定のイベント
   が発生したとき、当該被管理装置が、イベント内容に対
   応した管理装置に、イベント内容を示すＰＤＵを自発的
   に送信することによって複数の管理装置により複数の被
   管理装置を管理するように構成されたネットワーク管理
   システムにおいて、 前記被管理装置は、送信すべきＰＤＵのＰＤＵ送信先及
   び送信するＰＤＵを一意に識別可能な送信トラップイン
   デックスを記録するための送信トラップテーブルと、 ＰＤＵを送信すべきＰＤＵ送信先を設定し、送信トラッ
   プインデックス及びＰＤＵ送信先を送信トラップテーブ
   ルに記録するトラップ送信先設定手段と、 前記送信トラップテーブルに記録された送信トラップイ
   ンデックスをＰＤＵに記録し、ＰＤＵ送信先に当該ＰＤ
   Ｕを送信するＰＤＵ送信手段と、を備え、 前記管理装置は、受信したＰＤＵ及びＰＤＵを送信した
   ＰＤＵ送信元を記録するための受信トラップデータベー
   スと、 前記ＰＤＵを受信し、受信したＰＤＵ及びＰＤＵを送信
   したＰＤＵ送信元を受信トラップデータベースに記録す
   るトラップ受信処理手段と、 前記被管理装置の送信トラップテーブルを検索し、当該
   管理装置が受信可能なＰＤＵの送信トラップインデック
   スを取得するゲット送信処理手段と、 該ゲット送信処理手段が取得した送信トラップインデッ
   クスを、受信トラップデータベースに記録されているＰ
   ＤＵの送信トラップインデックスと比較し、受信できな
   かったＰＤＵの有無を確認するトラップ確認処理手段
   と、を備えたことを特徴とするネットワーク管理システ
   ム。
3. 【請求項３】 ネットワークに複数の管理装置と複数の
   被管理装置とを接続し、該被管理装置に所定のイベント
   が発生したとき、当該被管理装置が、イベント内容に対
   応した管理装置に、発生したイベントに対応するＰＤＵ
   識別データを含めてイベント内容を示すＰＤＵを自発的
   に送信することによって複数の管理装置により複数の被
   管理装置を管理するように構成されたネットワーク管理
   システムにおいて、 前記被管理装置は、ＰＤＵを送信すべきＰＤＵ送信先及
   びＰＤＵを受信したトラップ受信先を記録するためのト
   ラップ送受信データベースと、 送信するＰＤＵを一意に識別可能な送信トラップインデ
   ックス、トラップ送信先及びトラップ再送信先を記録す
   るための送信トラップテーブルと、 前記受信トラップインデックス及びトラップ受信先を記
   録するための受信トラップテーブルと、 送信したＰＤＵを保存するためのＰＤＵ保存データベー
   スと、 前記ＰＤＵを送信すべきＰＤＵ送信先を設定し、送信ト
   ラップインデックス及びＰＤＵ送信先を送信トラップテ
   ーブルに記録するトラップ送信先設定手段と、 送信するＰＤＵをＰＤＵ保存データベースに保存し、送
   信トラップテーブルに記録された送信トラップインデッ
   クスをＰＤＵに記録し、ＰＤＵ送信先に当該ＰＤＵを送
   信するＰＤＵ送信手段と、 前記管理装置から受信トラップテーブルの値の変更を要
   求する第１の変更要求を受信したときは、該受信トラッ
   プテーブルにトラップ受信先及びトラップ受信先を識別
   するための受信先トラップインデックスを記録し、送信
   トラップテーブルの値の変更を要求する第２の変更要求
   を受信したときは、送信トラップテーブルに当該ＰＤＵ
   の送信トラップインデックス及びトラップ再送信先を記
   録するセット受信処理手段と、 前記受信トラップテーブルの値が変更されたとき、受信
   トラップテーブルに記録された受信先トラップインデッ
   クスと同じ値を有する送信トラップインデックスを送信
   トラップテーブルから検索し、トラップ受信先をトラッ
   プ送信先と関連付けてトラップ送受信データベースに記
   録するトラップ受信確認手段と、 前記送信トラップテーブルの値が変更されたとき、該送
   信トラップテーブルに記録されたトラップ再送信先の送
   信トラップインデックスに基づいてＰＤＵ保存データベ
   ースを検索し、管理装置が受信できなかったＰＤＵをト
   ラップ再送信先に再送信するトラップ再送処理手段と、
   を備え、 前記管理装置は、受信したＰＤＵ及びＰＤＵを送信した
   ＰＤＵ送信元を記録するための受信トラップデータベー
   スと、 前記第１の変更要求、第２の変更要求の送信依頼を受け
   たとき、ＰＤＵ送信元に当該変更要求を送信するセット
   送信処理手段と、 ＰＤＵを受信し、受信トラップデータベースに受信した
   ＰＤＵ及びＰＤＵを送信したＰＤＵ送信元を記録して第
   １の変更要求の送信を依頼するトラップ受信処理手段
   と、 前記被管理装置の送信トラップテーブルを検索し、当該
   管理装置が受信可能なＰＤＵの送信トラップインデック
   スを取得するゲット送信処理手段と、 該ゲット送信処理手段が取得した送信トラップインデッ
   クスを、受信トラップデータベースに記録されている送
   信トラップインデックスと比較し、受信できなかったＰ
   ＤＵの有無を確認するトラップ確認処理手段と、 該トラップ確認処理手段により、受信できなかったＰＤ
   Ｕがあると判定されたときは、ＰＤＵの送信元に前記第
   ２の変更要求の送信を依頼するトラップ再送要求処理手
   段と、 前記トラップ受信処理手段からの第１の変更要求の送信
   依頼を受けてＰＤＵ送信元に第１の変更要求を送信し、
   トラップ再送要求処理手段からの第２の変更要求の送信
   依頼を受けて、ゲット送信処理手段が送信トラップイン
   デックスを取得したＰＤＵ送信元に第２の変更要求を送
   信するセット送信処理手段と、を備えたことを特徴とす
   るネットワーク管理システム。
4. 【請求項４】 前記被管理装置は、ＰＤＵを受信するこ
   とが予想される管理装置の受信者を記録するためのトラ
   ップ受信予定者を記録するためのトラップ受信予定リス
   トを備える一方、 前記トラップ受信確認手段は、受信トラップテーブルに
   データが記録されたとき、トラップ受信予定リストに記
   録されたトラップ受信予定者を削除し、 前記ＰＤＵ送信手段は、トラップ送受信データベースに
   記録されているトラップ受信先をトラップ受信予定リス
   トに記録し、ＰＤＵ送信後にトラップ受信予定リストに
   トラップ受信先が残っているときは、ＰＤＵを再送する
   ように構成されたことを特徴とする請求項１又は請求項
   ３に記載のネットワーク管理システム。
5. 【請求項５】 各被管理装置、各管理装置は、それぞれ
   各手段及びデータベースを備えたエージェント、マネー
   ジャを備えて構成されたことを特徴とする請求項１〜請
   求項４のいずれか１つに記載のネットワーク管理システ
   ム。