JP3741573B2 - ネットワーク管理エージェント - Google Patents
ネットワーク管理エージェント Download PDFInfo
- Publication number
- JP3741573B2 JP3741573B2 JP24096799A JP24096799A JP3741573B2 JP 3741573 B2 JP3741573 B2 JP 3741573B2 JP 24096799 A JP24096799 A JP 24096799A JP 24096799 A JP24096799 A JP 24096799A JP 3741573 B2 JP3741573 B2 JP 3741573B2
- Authority
- JP
- Japan
- Prior art keywords
- unit
- entry
- processing unit
- request
- access
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Multi Processors (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク管理技術における管理対象ノードの管理機能であるネットワーク管理エージェントに関し、特に、管理情報ベース（ＭＩＢ；Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）の一形態であるテーブル型オブジェクトをアクセスするエージェントに関する。
【０００２】
【従来の技術】
図２に、従来のネットワーク管理に係るシステム構成を示す。
【０００３】
図２において、管理ステーション２は、ネットワーク１を通じて、管理対象ノード３にアクセスする。管理する側である管理ステーション２には、管理対象ノード３に対する収集設定要求や収集した情報を加工・蓄積・解析を行うための機能を集約したマネージャ２Ａが存在している。一方、管理される側である管理対象ノード３には、管理項目である管理オブジェクト群３Ｂと、管理オブジェクト群３Ｂを直接アクセスするための管理機能としてのエージェント３Ａとが存在している。
【０００４】
マネージャ２Ａは、管理オブジェクトの情報を収集するために、収集要求として、「ＧＥＴ ＲＥＱＵＥＳＴ」を発信する。この「ＧＥＴ ＲＥＱＵＥＳＴ」に対して、エージェント３Ａは、要求されている情報を、「ＧＥＴ ＲＥＳＰＯＮＳＥ」としてマネージャ２Ａに返信する。また、マネージャ２Ａは、管理オブジェクトに対して何らかの設定変更を行う設定要求として、その設定値を格納した「ＳＥＴ ＲＥＱＵＥＳＴ」を発信する。エージェント３Ａは、この設定変更の結果を「ＧＥＴ ＲＥＳＰＯＮＳＥ」としてマネージャ２Ａに返信する。エージェント３Ａは、マネージャ２Ａに対して、管理対象ノード３で発生している異常などを、「ＴＲＡＰ」を発信して一方的に通知する。
【０００５】
図３に、管理オブジェクト群３Ｂの内の一つの形態であるテーブル型オブジェクト（テーブル型ＭＩＢオブジェクト）の構成例を示す。
【０００６】
図３に示す構成例では、テーブルの行にあたる各エントリに５個のオブジェクトが存在している。これらのオブジェクトには、３種類があり、インデックスオブジェクト（Ｉｎｄｅｘオブジェクト）Ａ，Ｂ、状態オブジェクト（Ｓｔａｔｕｓオブジェクト）Ｅ、その他のオブジェクト（ｏｔｈｅｒオブジェクト）Ｃ，Ｄに分けられる。ＩｎｄｅｘオブジェクトＡ，Ｂは、その値がそのまま各エントリを区別する識別子として用いられるものであり、対象管理機能に関係する。ＳｔａｔｕｓオブジェクトＥの値は、各エントリの状態を表しており、状態管理機能に関係する。ＳｔａｔｕｓオブジェクトＥの値には、ｖａｌｉｄ（有効）、ｃｒｅａｔｅＲｅｑｕｅｓｔ（生成要求）、ｕｎｄｅｒＣｒｅａｔｉｏｎ（生成中）、ｉｎｖａｌｉｄ（無効）の４種類ががある。ｏｔｈｅｒオブジェクトＣ，Ｄについての説明は省略する。
【０００７】
次に、テーブル型オブジェクトヘのエントリの従来の生成方法及び削除方法について、上述した図３を参照しながら簡単に説明する。
【０００８】
図３に示すテーブル型オブジェクトの例において、マネージャ２Ａが、管理対象ノード３に対して４個目のエントリ４を生成する場合、マネージャ２Ａは、「ＳＥＴ ＲＥＱＵＥＳＴ」を発信して、エージェント３Ａを介して、エントリ４のＳｔａｔｕｓオブジェクトの値をｃｒｅａｔｅＲｅｑｕｅｓｔに設定する。エージェント３Ａがこの要求を受け入れ、メモリ確保などの初期化処理を終えると、エージェント３Ａ自身がこの値をｕｎｄｅｒＣｒｅａｔｉｏｎに設定する。そして次に、マネージャ２Ａがエントリ４中の他の各オブジェクトの値を設定し、Ｓｔａｔｕｓオブジェクトの値をｖａｌｉｄに設定すると、このエントリ４が機能し始める。
【０００９】
また、エントリを削除する場合、マネージャ２Ａは、削除対象のエントリに対して、「ＳＥＴ ＲＥＱＵＥＳＴ」を発信して、エージェント３Ａを介して、そのエントリのＳｔａｔｕｓオブジェクトの値をｉｎｖａｌｉｄに設定する。これにより、エージェント３Ａはそのエントリを削除する。
【００１０】
図４に、エントリ生成時のシーケンス図を示す。以下、この図４を参照しながら、エントリ生成処理を、上述した以上に詳述する。
【００１１】
マネージャ２Ａが、管理対象ノード３に対してエントリ１を生成する場合、マネージャ２Ａは、「ＳＥＴ ＲＥＱＵＥＳＴ」を発信する。この「ＳＥＴ ＲＥＱＵＥＳＴ」には、ＳｔａｔｕｓオブジェクトＥに関し、ＩｎｄｅｘとｃｒｅａｔｅＲｅｑｕｅｓｔとの情報を含み、また、ｏｔｈｅｒオブジェクトＣ及びＤに関し、Ｉｎｄｅｘと設定する情報とを含み、さらに、再び、ＳｔａｔｕｓオブジェクトＥに関し、Ｉｎｄｅｘとｖａｌｉｄとの情報を含む。
【００１２】
エージェント３Ａは、このような「ＳＥＴ ＲＥＱＵＥＳＴ」に応じ、エントリ１に対し、ＩｎｄｅｘとｃｒｅａｔｅＲｅｑｕｅｓｔを含むＳｔａｔｕｓオブジェクトＥについての情報に応じ、ＩｎｄｅｘオブジェクトＡ及びＢにそのＩｎｄｅｘを設定すると共に、ＳｔａｔｕｓオブジェクトＥにｃｒｅａｔｅＲｅｑｕｅｓに設定する。その後、ｏｔｈｅｒオブジェクトＣ及びＤに到来した情報を設定し、最後に、ＳｔａｔｕｓオブジェクトＥの値をｖａｌｉｄに設定して、エントリ内の５個のオブジェクトＡ〜Ｅの生成を終了する。そして、エージェント３Ａは、エントリが正常に生成されたとして、「ＧＥＴ ＲＥＳＰＯＮＳＥ」をｎｏＥｒｒｏｒ（正常）で返信する。
【００１３】
【発明が解決しようとする課題】
しかしながら、マネージャ２Ａが発信した「ＳＥＴ ＲＥＱＵＥＳＴ」内のエントリ生成要求に不備がある場合がある。これは、マネージャ２Ａから送出された時点で不備なこともあれば、ネットワーク１を介することにより、不備になることもある。
【００１４】
図４のエントリ２の設定は、不備な設定の場合を示している。すなわち、オブジェクトＣの値が不明のままエントリ２が生成され、「ＧＥＴ ＲＥＳＰＯＮＳＥ」もｎｏＥｒｒｏｒでマネージャ２Ａに返信されている場合である。
【００１５】
このような場合、マネージャ２Ａは、このエントリ２の生成の不備を発見するために、エントリ２に対して「ＧＥＴ ＲＥＱＵＥＳＴ」を発信して５個のオブジェクトＡ〜Ｅの値を取得して、その正常性を確認することになる。
【００１６】
すなわち、従来では、「ＧＥＴ ＲＥＳＰＯＮＳＥ」がｎｏＥｒｒｏｒであっても、エントリ生成に対してその正常性を確認するために、マネージャ２Ａは、「ＳＥＴ ＲＥＱＵＥＳＴ」が終了した後に、「ＧＥＴ ＲＥＱＵＥＳＴ」で収集要求を発信していた。
【００１７】
以上のように、従来では、マネージャの負荷が高く、また、マネージャとエージェント間のネットワークヘの負荷が高くなるという課題があった。
【００１８】
そのため、マネージャの負荷を軽減でき、また、マネージャとエージェント間のネットワークヘの負荷を軽減できるネットワーク管理エージェントが求められている。
【００１９】
【課題を解決するための手段】
かかる課題を解決するため、本発明は、マネージャとの通信処理を行う通信処理手段と、この通信処理手段からのオブジェクト毎の要求に対してテーブル型オブジェクトにアクセスするアクセス手段とを有するネットワーク管理エージェントにおいて、（１）上記アクセス手段は、（１−１）要求を受付けたインデックスオブジェクトの値を保管するインデックス保管部と、当該仮エントリ部がエントリ生成中であるか否かの状態を保管する状態保管部と、インデックスオブジェクトと状態オブジェクト以外のオブジェクトの値を保管する他オブジェクト保管部とを少なくとも含み、エントリ生成時に仮エントリが生成される仮エントリ部と、（１−２）エントリ生成時にまず、上記仮エントリ部に仮エントリを生成させると共に、上記仮エントリ部に仮エントリが正常に生成されたときに、対応するテーブル型オブジェクトにアクセスしてエントリを設定するアクセス処理部と、（１−３）エントリ生成時に要求を受付けたオブジェクトの数をカウントするオブジェクトカウント部と、（１−４）要求を受付けたオブジェクトの種別と上記仮エントリ部の状態保管部の値から状態及び状態遷移を管理する状態管理部とを備え、（２）上記アクセス処理部は、オブジェクト毎の要求時に、上記仮エントリ部の仮エントリ、及び、上記オブジェクトカウント部がカウントした要求を受け付けたオブジェクトの数とをもって上記状態管理部に問い合わせて、エントリ設定の正常、異常を判定することを特徴とする。
【００２０】
【発明の実施の形態】
（Ａ）第１の実施形態
以下、本発明によるネットワーク管理エージェントの第１の実施形態を図面を参照しながら、詳述する。
【００２１】
（Ａ−１）第１の実施形態の構成
図１は、第１の実施形態の管理対象ノードにおけるエージェントの構成を示している。なお、上述した図２との同一、対応部分には、同一符号を付して示している。
【００２２】
図１において、第１の実施形態の管理対象ノード３におけるエージェント３Ａは、送受信処理部１０１、ＴＲＡＰ送信処理部１０４、及び、複数のオブジェクトアクセス部１０５−１〜１０５−Ｎを有する。送受信処理部１０１は、ＲＥＱＵＥＳＴ受信処理部１０２及びＲＥＳＰＯＮＳＥ送信処理部１０３でなる。
【００２３】
ネットワーク１より受信した「ＧＥＴ ＲＥＱＵＥＳＴ」、「ＳＥＴ ＲＥＱＵＥＳＴ」等の複数のオブジェクトについての収集及び設定要求からなるメッセージは、ＲＥＱＵＥＳＴ受信処理部１０２でオブジェクト毎の要求に分解される。分解されたオブジェクト毎の要求は、それぞれに対応するオブジェクトアクセス部１０５−１、…、１０５−Ｎに送られる。オブジェクトアクセス部１０５−１、…、１０５−Ｎは、それぞれ担当するテーブル型オブジェクト１０６−１、…、１０６−Ｎにアクセスを行う。
【００２４】
オブジェクトアクセス部１０５−１、…、１０５−Ｎは、アクセスの結果を、ＲＥＳＰＯＮＳＥ送信処理部１０３に与える。ＲＥＳＰＯＮＳＥ送信処理部１０３は、オブジェクト毎に返ってきたアクセスの結果をメッセージとして組み立て、「ＧＥＴ ＲＥＳＰＯＮＳＥ」としてネットワーク１に送信する。
【００２５】
ＴＲＡＰ送信処理部１０４は、オブジェクトアクセス部１０５−１、…、１０５−Ｎから受けた異常検出などをメッセージとして組み立て「ＴＲＡＰ」をネットワーク１に送信する。
【００２６】
図５は、エージェント３Ａ内のオブジェクトアクセス部１０５−ｎ（ｎは１〜Ｎ）の詳細構成を示している。
【００２７】
オブジェクトアクセス部１０５−ｎは、仮エントリ部１１１、オブジェクトカウンタ部１１２、アクセス処理部１１３及び状態管理部１１４からなる。
【００２８】
アクセス処理部１１３は、送受信処理部１０１又はＴＲＡＰ送信部１０４と、自己が担当するテーブル型オブジェクト１０６−ｎとのデータの仲介処理を行う。アクセス処理部１１３は、仲介処理を実行するときに、適宜、仮エントリ部１１１に保管されている情報を利用したり、仮エントリ部１１１に所定情報を保管したり、また、オブジェクトカウンタ部１１２のカウント値を利用したり、カウント値を更新したり、さらに、状態管理部１１４を利用したりする。
【００２９】
仮エントリ部１１１は、Ｉｎｄｅｘ保管部１１５、Ｓｔａｔｕｓ保管部１１６及びｏｔｈｅｒオブジェクト保管部１１７からなり、それぞれ、Ｉｎｄｅｘ、Ｓｔａｔｕｓ及びｏｔｈｅｒオブジェクトを保管するものである。
【００３０】
エージェント３Ａの構成要素の詳細機能については、後述する動作説明で明らかにする。
【００３１】
（Ａ−２）第１の実施形態の動作
次に、第１の実施形態に係るシステムの動作シーケンスを、正常時の動作、異常時の動作、ＲＥＳＥＴ時の動作の順に説明する。
【００３２】
［正常時の動作］
図６に、正常時の動作シーケンス図を示す。
【００３３】
マネージャ２Ａは、エントリ生成要求として、「ＳＥＴ ＲＥＱＵＥＳＴ」のメッセージをエージェント３Ａに送信する。メッセージの内容は、従来と同様である。
【００３４】
メッセージを受信したエージェント３Ａにおいては、送受信処理部１０１から対応するオブジェクトアクセス部１０５−ｎヘオブジェクト毎の要求を行う。
【００３５】
オブジェクトアクセス部１０５−ｎにおいて、仮エントリ部１１１の各保管部１１５、１１６、１１７は、「Ｅ．Ｉｎｄｅｘ：ｃｒｅａｔｅＲｅｑｕｅｓｔ」の要求前の初期状態では全て初期値になっており、Ｓｔａｔｕｓ保管部１１６は状態値として「Ｓｔａｔｕｓ：ｎｏｎＥｘｉｓｔ」を保管し、他の保管部１１５、１１７は「ＮＵＬＬ」を保管している。また、この初期状態では、オブジェクトカウンタ部１１２のカウント値は「０」である。
【００３６】
アクセス処理部１１３は、送受信処理部１０１から、「Ｅ．Ｉｎｄｅｘ：ｃｒｅａｔｅＲｅｑｕｅｓｔ」の要求が与えられると、状態管理部１１４に状態問合せを行い、その結果、Ｓｔａｔｕｓ保管部１１６の状態を「Ｓｔａｔｕｓ：ｕｎｄｅｒＣｒｅａｔｉｏｎ」に変更し、オブジェクトカウンタ部１１２を「１」にカウントアップし、Ｉｎｄｅｘ保管部１１５にオブジェクトＡ、Ｂを格納する。なお、このときには、ｏｔｈｅｒオブジェクト保管部１１７に保管するオブジェクトは存在しない。
【００３７】
アクセス処理部１１３は、次に、送受信処理部１０１から、「Ｃ．Ｉｎｄｅｘ：ＸＸＸ」の要求が与えられると、状態管理部１１４に状態問合せを行い、その結果、Ｓｔａｔｕｓ保管部１１６の状態を維持し（同一情報ではあるが再格納するようにしても良い）、オブジェクトカウンタ部１１２を「２」にカウントアップし、ｏｔｈｅｒオブジェクト保管部１１７にオブジェクトＣを保管する。このときに、Ｉｎｄｅｘ保管部１１５の格納状態を維持するようにしても良く、又、オブジェクトＡ、Ｂを再格納するようにしても良い。
【００３８】
アクセス処理部１１３は、送受信処理部１０１から、「Ｄ．Ｉｎｄｅｘ：ＸＸＸ」の要求が与えられるときも、送受信処理部１０１から、「Ｃ．Ｉｎｄｅｘ：ＸＸＸ」の要求が与えられるときと同様に処理する。なお、「Ｄ．Ｉｎｄｅｘ：ＸＸＸ」の要求に対する処理を実行したときには、仮エントリ部１１１には必要な情報が全て保管されている。
【００３９】
そして、アクセス処理部１１３は、送受信処理部１０１から、「Ｅ．Ｉｎｄｅｘ：ｖａｌｉｄ」という最後の要求を受け付けた時点で、仮エントリ部１１１に保管されている１組の仮エントリ内容をテーブル型オブジェクト３Ｂにエントリ設定する。その後、アクセス処理部１１３は、仮エントリ部１１１とオブジェクトカウンタ部１１２の初期化を行う。この初期化により、Ｓｔａｔｕｓ保管部１１６の状態は「Ｓｔａｔｕｓ：ｎｏｎＥｘｉｓｔ」となり、オブジェクトカウンタ部１１２のカウント値は「０」になり、Ｉｎｄｅｘ保管部１１５及びｏｔｈｅｒオブジェクト保管部１１７の保管内容は、「ＮＵＬＬ」となる。
【００４０】
オブジェクトアクセス部１０５−ｎは、エントリの生成が正常に終了したことを送受信処理部１０１に「ｎｏＥｒｒｏｒ」として伝える。送受信処理部１０１のＲＥＳＰＯＮＳＥ送信処理部１０３は、「ｎｏＥｒｒｏｒ」を「ＧＥＴ ＲＥＳＰＯＮＳＥ」のメッセージとして組み立てマネージャ２Ａに送信する。
【００４１】
［異常時の動作］
図７に、異常時の動作シーケンス図を示す。
【００４２】
図７の例では、マネージャ２Ａから送信された「ＳＥＴ ＲＥＱＵＥＳＴ」のメッセージに不備があり、図６の場合に比較して、最終要求の「Ｅ．Ｉｎｄｅｘ：ｖａｌｉｄ」が抜け落ちている。
【００４３】
そのため、オブジェクトアクセス部１０５−ｎは、「Ｄ．Ｉｎｄｅｘ：ＸＸＸ」の要求に対する処理を実行した段階で動作が停止している。すなわち、仮エントリ部１１１とオブジェエクトカウンタ部１１２は、「Ｄ．Ｉｎｄｅｘ：ＸＸＸ」の要求に対する処理を実行した段階での値を継続して保持し、テーブル型オブジェクト３Ｂヘのエントリ設定は行われない。
【００４４】
このような状態で、次の「ＳＥＴ ＲＥＱＵＥＳＴ」のメッセージが与えられると、アクセス処理部１１３による状態管理部１１４への問合せにより、異常が検出される。異常検出時には、オブジェクトアクセス部１０５−ｎは、Ｉｎｄｅｘ保管部１１５のＩｎｄｅｘオブジェクトＡ、ＢをＴＲＡＰのメッセージとしてＴＲＡＰ送信処理部１０４にＴＲＡＰ要求を出す。
【００４５】
ＴＲＡＰ送信処理部１０４は、メッセージを組立てマネージャ２Ａに「ＴＲＡＰ」を送信する。その後、仮エントリ部１１１とオブジェクトカウンタ部１１２は、今回の「ＳＥＴ ＲＥＱＵＥＳＴ」に関わる状態に新規設定され、次のオブジェクトの要求を待つ。
【００４６】
［ＲＥＳＥＴ時の動作］
図８に、ＲＥＳＥＴ時の動作シーケンス図を示す。
【００４７】
マネージャ２Ａは、仮エントリ部１１１の状態を初期化するために、「Ｅ．Ｉｎｄｅｘ：Ｒｅｓｅｔ」のメッセ一ジを持った「ＳＥＴ ＲＥＱＵＥＳＴ」を送信する。
【００４８】
この要求を受けたオブジェクトアクセス部１０５−ｎでは、仮エントリ部１１１とオブジェクトカウンタ部１１２の初期化を行い、Ｓｔａｔｕｓ保管部１１６の状態は「Ｓｔａｔｕｓ：ｎｏｎＥｘｉｓｔ」となる。
【００４９】
「Ｅ．Ｉｎｄｅｘ：Ｒｅｓｅｔ」を含むメッセージは、あるテーブル型オブジェクトの最後のエントリ生成要求の後、若しくは、異なるテーブル型オブジェクトのエントリ生成要求に移るときに送信することにより、オブジェクトアクセス部１０５−ｎの状態を初期化したり、その直前の要求での異常検出を行なったりすることができる。
【００５０】
［状態遷移］
図９に、以上のような正常時、異常時、ＲＥＳＥＴ時の動作を実行させるための状態遷移図を示す。
【００５１】
この状態遷移図は、アクセス処理部１１３で受け付けたオブジェクトの種別とＳｔａｔｕｓ保管部１１７の状態から、次にアクセス処理部１１３が実行する処理を表している。なお、各処理については、図９での記載に委ね、その説明は省略する。
【００５２】
状態管理部１１４では、この状態遷移図を基にアクセス処理部１１３からの状態問合せに応答する。
【００５３】
（Ａ−３）第１の実施形態の効果
上述した第１の実施形態によれば、以下の効果を奏することができる。
【００５４】
（１）送受信処理部の構成が全くブラックボックスであり、エージェント内部においてはオブジェクトアクセス部とのインタフェースのみ明確になっているときでも、エントリ生成の異常を検出することができる。これにより、送受信処理部に汎用モジュールを用いることが可能で、エージェントの開発時のコストを削減できる。
【００５５】
（２）エージェントが自律的にエントリ生成での異常を検出するので、マネージャにおいて「ＧＥＴ ＲＥＱＵＥＳＴ」によるエントリ生成の正常性の再確認のためのスケジューリングの負荷を削減できる。
【００５６】
（３）エージェントが自律的にエントリ生成での異常を検出するので、管理ステーションと管理対象ノード間のネットワークヘの負荷を軽減できる。
【００５７】
（４）状態管理のみでエントリ生成の異常検出を行なうので、管理対象ノードヘの負荷を軽減できる。
【００５８】
（５）テーブル型オブジェクト毎に状態を管理することにより異なるテーブル型オブジェクトヘのエントリ生成を並列に処理し、エントリ全体の生成にかかる時間を短縮できる。
【００５９】
（Ｂ）第２の実施形態
次に、本発明によるネットワーク管理エージェントの第２の実施形態を図面を参照しながら、詳述する。
【００６０】
（Ｂ−１）第２の実施形態の構成
図１０は、第２の実施形態の管理対象ノードにおけるエージェントの構成を示している。なお、上述した図１、図２との同一、対応部分には、同一、対応符号を付して示している。ここで、対応符号は、第１の実施形態で１００番台であったものを２００番台にしたものである。
【００６１】
図１０において、第２の実施形態の管理対象ノード３におけるエージェント３Ａも、第１の実施形態と同様に、送受信処理部２０１、ＴＲＡＰ送信処理部２０４、及び、複数のオブジェクトアクセス部２０５−１〜２０５−Ｎを有する。第２の実施形態のエージェント３Ａは、以上の構成要素に加えて、全てのオブジェクトアクセス部２０５−１〜２０５−Ｎに接続されている共通状態保管部２０７を有する。
【００６２】
第２の実施形態のオブジェクトアクセス部２０５−ｎ（ｎは１〜Ｎ）は、共通状態保管部２０７が設けられていることと関連し、第１の実施形態とは異なる内部構成となっている。図１１は、このオブジェクトアクセス部２０５−ｎの詳細構成を示している。
【００６３】
第２の実施形態のオブジェクトアクセス部２０５−ｎは、アクセス処理部２１３及び状態管理部２１４を備え、仮エントリ部とオブジェクトカウンタ部は備えていない。アクセス処理部２１３及び状態管理部２１４の機能は、第１の実施形態のものとほぼ同様である。
【００６４】
図１２は、第２の実施形態で新たに設けられた共通状態保管部２０７の詳細構成を示している。
【００６５】
共通状態保管部２０７は、オブジェクトアクセス部２０５−ｎ内のアクセス処理部２１３に接続している、仮エントリ部２１１とオブジェクトカウンタ部２１２とからなる。仮エントリ部２１１は、第１の実施形態と同様に、Ｉｎｄｅｘ保管部２１５と、Ｓｔａｔｕｓ保管部２１６と、ｏｔｈｅｒオブジェクト保管部２１７から構成されている。
【００６６】
（Ｂ−２）第２の実施形態の動作
第２の実施形態においても、［正常時の動作］、［異常時の動作］及び［ＲＥＳＥＴ時の動作］は、第１の実施形態とほぼ同様に行われる（図６〜図８参照）。また、その際のエージェント３Ａでの状態遷移も、第１の実施形態のものとほぼ同様である（図９参照）。
【００６７】
第１の実施形態と異なるのは、以下の点である。各オブジェクトアクセス部２０５−ｎが、仮エントリ部とオブジェクトカウンタ部を持たないため、アクセス処理部２１３は、オブジェクト毎の要求に対して、共通状態保管部２０７の仮エントリ部２１１とオブジェクトカウンタ部２１２の値を参照した後、状態管理部２１４に状態問合せを行ない処理を進める点である。これは、［正常時の動作］、［異常時の動作］、［ＲＥＳＥＴ時の動作］の全てに同様である。
【００６８】
（Ｂ−３）第２の実施形態の効果
第２の実施形態によっても、第１の実施形態の効果（１）〜（４）と同様な効果を奏することができる。
【００６９】
これに加えて、第２の実施形態によれば、以下の効果（６）及び（７）をも奏する。
【００７０】
（６）共通状態保管部のみで状態を保管することによりエージェント構成時のメモリ量を削減できる。
【００７１】
（７）異なるテーブル型オブジェクトヘのエントリ生成要求に移るとき（例えば図１０の２０６−１から２０６−２へ）、「Ｅ．Ｉｎｄｅｘ：Ｒｅｓｅｔ」のメッセージを持った「ＳＥＴ ＲＥＱＵＥＳＴ」を送信せずにエントリ生成を連続して実行しても異常検出ができる。これにより、異常検出時のタイムラグを減少でき、マネージャとネットワークの負荷も軽減できる。
【００７２】
（Ｃ）第３の実施形態
次に、本発明によるネットワーク管理エージェントの第３の実施形態を図面を参照しながら、詳述する。
【００７３】
（Ｃ−１）第３の実施形態の構成
図１３は、第３の実施形態の管理対象ノードにおけるエージェントの構成を示している。なお、上述した図２、図１０との同一、対応部分には、同一、対応符号を付して示している。ここで、対応符号は、第２の実施形態で２００番台であったものを３００番台にしたものである。
【００７４】
図１３において、第３の実施形態の管理対象ノード３におけるエージェント３Ａも、第２の実施形態と同様に、送受信処理部３０１、ＴＲＡＰ送信処理部３０４、複数のオブジェクトアクセス部３０５−１〜３０５−Ｎ、及び、共通状態保管部３０７を有する。
【００７５】
第３の実施形態のエージェント３Ａは、以上の構成要素に加えて、シングルタイマ処理部３０８と、タイムアウト処理部３０９とを有する。タイムアウト処理部３０９は、シングルタイマ処理部３０５と共通状態保管部３０８とＴＲＡＰ送信処理部３０４に接続されている。シングルタイマ処理部３０５は、各オブジェクトアクセス部３０５−ｎから一方向で接続されている。
【００７６】
図１４は、第３の実施形態のオブジェクトアクセス部３０５−ｎの詳細構成を示している。これは、第２の実施形態のものとほぼ同様であるが、アクセス処理部３１３がシングルタイマ処理部３０８にも接続されている点は、第２の実施形態のものと異なっている。
【００７７】
図１５は、第３の実施形態の共通状態保管部３０８の詳細構成を示している。これは、第２の実施形態のものとほぼ同様であるが、仮エントリ部３１１とオブジェクトカウンタ部３１２とがタイムアウト処理部３０９にも接続されている点は、第２の実施形態のものと異なっている。
【００７８】
この第３の実施形態のエージェント３Ａの各部の機能は、後述する動作説明で明らかにする。
【００７９】
（Ｃ−２）第３の実施形態の動作
次に、第３の実施形態に係るシステムの動作シーケンスを、正常時の動作、異常時の動作の順に説明する。
【００８０】
［正常時の動作］
図１６に、正常時の動作シーケンス図を示す。
【００８１】
第３の実施形態の正常時の動作において、第２の実施形態の動作と異なるのは、以下の点である。
【００８２】
送受信処理部３０１において、シングルタイマ処理部３０８は、オブジェクト毎の要求がない場合（図１６では後半のシーケンスが該当する）、一定のタイムアウト間隔でタイムアウト処理部３０９へ「ＴｉｍｅＯｕｔ」を要求する。「ＴｉｍｅＯｕｔ」の要求を受付けたタイムアウト処理部３０９は、共通状態保管部３０８の仮エントリ部３１１内にあるＳｔａｔｕｓ保管部３１６を参照し、「Ｓｔａｔｕｓ：ｎｏｎＥｘｉｓｔ」であれば異常なしと判定する。
【００８３】
また、各オブジェクトアクセス部３０５−ｎは、オブジェクト毎の要求を受けたときに（図１６では前半のシーケンスが該当する）、シングルタイマ処理部３０８に「ＴｉｍｅｒＲｅｓｅｔ」を送り、タイマをリセットする。すなわち、オブジェクトアクセス部３０５−ｎにおけるオブジェクト毎の要求の受付間隔がリセット間隔となる。
【００８４】
リセット間隔は必ずしも一定間隔とは限らないが、ある範囲内の時間であり、リセット間隔＜タイムアウト間隔である。
【００８５】
なお、オブジェクトのエントリ設定動作自体は、第２の実施形態のものと同様である。
【００８６】
［異常時の動作］
図１７に、異常時の動作シーケンス図を示す。
【００８７】
第３の実施形態の異常時の動作において、第２の実施形態の動作と異なるのは、以下の点である。
【００８８】
「ＳＥＴ ＲＥＱＵＥＳＴ」のメッセージに不備があり、最終要求の「Ｅ．Ｉｎｄｅｘ：ｖａｌｉｄ」が抜け落ちている。そのため、オブジェクトアクセス部３０５−ｎは、「Ｄ．Ｉｎｄｅｘ：ＸＸＸ」の要求に対する処理を実行した段階で動作が停止している。すなわち、仮エントリ部３１１とオブジェエクトカウンタ部３１２は、「Ｄ．Ｉｎｄｅｘ：ＸＸＸ」の要求に対する処理を実行した段階での値を継続して保持し、テーブル型オブジェクト３Ｂヘのエントリ設定は行われない。このとき、仮エントリ部３１１のＳｔａｔｕｓ保管部３１６は、「Ｓｔａｔｕｓ：ｕｎｄｅｒＣｒｅａｔｉｏｎ」の状態であり、また、「Ｄ．Ｉｎｄｅｘ：ＸＸＸ」の要求に対する処理に応じた以降、オブジェクトアクセス部３０５−ｎからシングルタイマ処理部３０８に「ＴｉｍｅｒＲｅｓｅｔ」が与えられない。
【００８９】
この状態で、シングルタイマ処理部３０８から「ＴｉｍｅＯｕｔ」を要求されると、タイムアウト処理部３０９は、Ｓｔａｔｕｓ保管部３１６を参照し、異常を検出する。異常を検出したタイムアウト処理部３０９は、Ｉｎｄｅｘ保管部３１５のＩｎｄｅｘオブジェクトＡ、ＢをＴＲＡＰのメッセージとして、ＴＲＡＰ送信処理部３０４にＴＲＡＰ要求を出す。
【００９０】
［状態遷移］
図１８に、以上のような正常時、異常時などの動作を実行させるための状態遷移図を示す。
【００９１】
この状態遷移図は、アクセス処理部３１３で受け付けたオブジェクトの種別とＳｔａｔｕｓ保管部３１７の状態から、次にアクセス処理部３１３が実行する処理を表している。第１や第２の実施形態と異なるのは、次の点である。受付オブジェクトの種別に「Ｒｅｓｅｔ」は存在しない。その代わりに、「ＴｉｍｅＯｕｔ」が存在する。
【００９２】
（Ｃ−３）第３の実施形態の効果
第３の実施形態によっても、第１の実施形態の効果（１）〜（４）と同様な効果を奏することができ、また、第２の実施形態の効果（６）と同様な効果を奏することができる。
【００９３】
これに加えて、第３の実施形態によれば、以下の効果（８）をも奏する。
【００９４】
（８）「ＴｉｍｅＯｕｔ」を用いたエントリ生成の異常検出により、ランダムなエントリ生成を行なっても異常検出が可能である。これは管理ステーションにおいてエントリ生成のスケジューリングの自由度を大きくする。
【００９５】
（Ｄ）第４の実施形態
次に、本発明によるネットワーク管理エージェントの第４の実施形態を図面を参照しながら、詳述する。
【００９６】
（Ｄ−１）第４の実施形態の構成
図１９は、第４の実施形態の管理対象ノードにおけるエージェントの構成を示している。なお、上述した図１、図２との同一、対応部分には、同一、対応符号を付して示している。ここで、対応符号は、第１の実施形態で１００番台であったものを４００番台にしたものである。
【００９７】
図１９において、第４の実施形態の管理対象ノード３におけるエージェント３Ａも、第１の実施形態と同様に、送受信処理部４０１、ＴＲＡＰ送信処理部４０４及び複数のオブジェクトアクセス部４０５−１〜４０５−Ｎを有する。
【００９８】
第４の実施形態のエージェント３Ａは、さらに、マルチタイマ処理部４０８及びタイムアウト処理部４０９を備える。マルチタイマ処理部４０８は、オブジェクトアクセス部４０５−１〜４０５−Ｎとタイムアウト処理部４０９とに接続されいる。また、タイムアウト処理部４０９は、オブジェクトアクセス部４０５−１〜４０５−ＮとＴＲＡＰ送信処理部４０４とに接続されている。
【００９９】
図２０は、第４の実施形態のオブジェクトアクセス部４０５−ｎの詳細構成を示している。
【０１００】
第４の実施形態のオブジェクトアクセス部４０５−ｎは、第１の実施形態のものとほぼ同様であるが、仮エントリ部４１１にシーケンスナンバ保管部４１８が設けられている点、並びに、アクセス処理部４１３がマルチタイマ処理部４０８及びタイムアウト処理部４０９に接続している点が、第１の実施形態のものとは異なっている。
【０１０１】
（Ｄ−２）第４の実施形態の動作
次に、第４の実施形態に係るシステムの動作シーケンスを、正常時の動作、異常時の動作の順に説明する。
【０１０２】
［正常時の動作］
図２１に、正常時の動作シーケンス図を示す。
【０１０３】
第４の実施形態の正常時の動作において、第１の実施形態の動作と異なるのは、以下のような計時処理に係る点である。なお、基本的なエントリ設定動作は、第１の実施形態と同様である。
【０１０４】
送受信処理部４０１からオブジェクトアクセス部４０５−ｎへ「Ｅ．Ｉｎｄｅｘ：ｃｒｅａｔｅＲｅｑｕｅｓｔ」の要求時に、オブジェクトアクセス部４０５−ｎはマルチタイマ処理部４０８へ「ＴｉｍｅｒＳｅｔ」の要求を行う。このとき、オブジェクトアクセス部４０５−ｎでは、シーケンスナンバ保管部４１８の値をカウントアップし、そのカウント値（シーケンスナンバ）と各オブジェクトアクセス部４０５−ｎ毎にユニークな仮エントリＩＤをマルチタイマ処理部４０８に送る。
【０１０５】
マルチタイマ処理部４０８は、仮エントリＩＤとシーケンスナンバを保持し、これを担当する１つのタイマを起動する。このタイマが起動してから、タイムアウトするまでのタイムアウト間隔は、「ＳＥＴ ＲＥＱＵＥＳＴ」が当該エージェント３Ａに到達してから、正常なエントリ設定がなされて当該エージェント３Ａが「ＧＥＴ ＲＥＳＰＯＮＳＥ」を送信するまでのエントリ生成間隔より長くなされている。
【０１０６】
マルチタイマ処理部４０８における担当タイマがタイムアウトすると、マルチタイマ処理部４０８は、タイムアウト処理部４０９へ「ＴｉｍｅＯｕｔ」を要求する。このとき、マルチタイマ処理部４０８は、保持していた仮エントリＩＤとシーケンスナンバをタイムアウト処理部４０９に送る。
【０１０７】
タイムアウト処理部４０９は仮エントリＩＤから対応するオブジェクトアクセス部４０５−ｎを識別し、その仮エントリ部４１１内にあるＳｔａｔｕｓ保管部４１６を参照し、「Ｓｔａｔｕｓ：ｎｏｎＥｘｉｓｔ」であれば異常なしと判定する。
【０１０８】
［異常時の動作］
図２２に、異常時の動作シーケンス図を示す。
【０１０９】
第４の実施形態の異常時の動作において、第１の実施形態の動作と異なるのは、以下の点である。
【０１１０】
「ＳＥＴ ＲＥＱＵＥＳＴ」のメッセージに不備があり、最終要求の「Ｅ．Ｉｎｄｅｘ：ｖａｌｉｄ」が抜け落ちている。そのため、オブジェクトアクセス部４０５−ｎは、「Ｄ．Ｉｎｄｅｘ：ＸＸＸ」の要求に対する処理を実行した段階で動作が停止している。すなわち、仮エントリ部４１１とオブジェエクトカウンタ部４１２は、「Ｄ．Ｉｎｄｅｘ：ＸＸＸ」の要求に対する処理を実行した段階での値を継続して保持し、テーブル型オブジェクト３Ｂヘのエントリ設定は行われない。このとき、仮エントリ部４１１のＳｔａｔｕｓ保管部３１６は、「Ｓｔａｔｕｓ：ｕｎｄｅｒＣｒｅａｔｉｏｎ」の状態である。
【０１１１】
このような状況において、マルチタイマ処理部４０８から「ＴｉｍｅＯｕｔ」を要求されると、タイムアウト処理部４０９は、仮エントリＩＤから対応するオブジェクトアクセス部４０５−ｎを識別し、仮エントリ部４１１内にあるＳｔａｔｕｓ保管部４１６を参照し「Ｓｔａｔｕｓ：ｍｄｅｒＣｒｅａｔｉｏｎ」であれば、仮エントリ部４１１内にあるシーケンスナンバ保管部４１８の値とマルチタイマ処理部４０８から受け取ったシーケンスナンバのマッチングを行う。ここで値が一致すれば、異常を検出する。
【０１１２】
異常を検出したタイムアウト処理部４０９は、Ｉｎｄｅｘ保管部４１５のＩｎｄｅｘオブジェクトＡ、ＢをＴＲＡＰのメッセージとしてＴＲＡＰ送信処理部４０４にＴＲＡＰ要求を出す。
【０１１３】
［状態遷移］
図２３に、以上のような正常時、異常時などの動作を実行させるための状態遷移図を示す。
【０１１４】
この状態遷移図は、アクセス処理部４１３で受け付けたオブジェクトの種別とＳｔａｔｕｓ保管部４１７の状態から、次にアクセス処理部４１３が実行する処理を表している。第１の実施形態と異なるのは、次の点である。受付オブジェクトの種別に「Ｒｅｓｅｔ」は存在しない。その代わりに、「ＴｉｍｅＯｕｔ」が存在する。また、受付オブジェクトの種別がＳｔａｔｕｓオブジェクト「ｃｒｅａｔｅＲｅｑｕｅｓｔ」で、Ｓｔａｔｕｓ保管部４１７が「ｎｏｎＥｘｉｓｔ」のときの処理が異なる。
【０１１５】
（Ｄ−３）第４の実施形態の効果
第４の実施形態によっても、第１の実施形態の効果（１）〜（５）と同様な効果を奏することができる。
【０１１６】
これに加えて、第４の実施形態によれば、以下の効果（９）をも奏する。
【０１１７】
（９）エントリ生成を並列に処理している場合でも、オブジェクトアクセス部毎の「ＴｉｍｅＯｕｔ」を用いたエントリ生成の異常検出により、ランダムなエントリ生成を行なっても異常検出が可能である。これは管理ステーションにおいてエントリ生成のスケジューリングの自由度を大きくする。
【０１１８】
（Ｅ）他の実施形態
１エントリでのオブジェクト数などは、上記実施形態のものに限定されるものではない。本発明のネットワーク管理エージェントが適用できるネットワーク管理システムの用途は限定されるものではない。
【０１１９】
【発明の効果】
以上のように、本発明によれば、仮エントリ機能を備え、仮エントリが正常になされたときにテーブル型オブジェクトにエントリ設定すると共に、仮エントリが生成中を条件として、異常通知をマネージャに行うようにしたので、マネージャの負荷を軽減でき、また、マネージャとエージェント間のネットワークヘの負荷を軽減できるネットワーク管理エージェントを実現できる。
【図面の簡単な説明】
【図１】第１の実施形態の管理対象ノード内のエージェント構成を示すブロック図である。
【図２】従来のネットワーク管理に係るシステム構成等を示す説明図である。
【図３】テーブル型ＭＩＢオブジェクトの構成例を示す説明図である。
【図４】従来のネットワーク管理動作を示す動作シーケンス図である。
【図５】第１の実施形態のオブジェクトアクセス部の詳細構成を示すブロック図である。
【図６】第１の実施形態の正常時の動作シーケンス図である。
【図７】第１の実施形態の異常時の動作シーケンス図である。
【図８】第１の実施形態のＲＥＳＥＴ時の動作シーケンス図である。
【図９】第１の実施形態のエージェントでの状態遷移を示す図面である。
【図１０】第２の実施形態の管理対象ノード内のエージェント構成を示すブロック図である。
【図１１】第２の実施形態のオブジェクトアクセス部の詳細構成を示すブロック図である。
【図１２】第２の実施形態の共通状態保管部の詳細構成を示すブロック図である。
【図１３】第３の実施形態の管理対象ノード内のエージェント構成を示すブロック図である。
【図１４】第３の実施形態のオブジェクトアクセス部の詳細構成を示すブロック図である。
【図１５】第３の実施形態の共通状態保管部の詳細構成を示すブロック図である。
【図１６】第３の実施形態の正常時の動作シーケンス図である。
【図１７】第３の実施形態の異常時の動作シーケンス図である。
【図１８】第３の実施形態のエージェントでの状態遷移を示す図面である。
【図１９】第４の実施形態の管理対象ノード内のエージェント構成を示すブロック図である。
【図２０】第４の実施形態のオブジェクトアクセス部の詳細構成を示すブロック図である。
【図２１】第４の実施形態の正常時の動作シーケンス図である。
【図２２】第４の実施形態の異常時の動作シーケンス図である。
【図２３】第４の実施形態のエージェントでの状態遷移を示す図面である。
【符号の説明】
２…管理ステーション、
２Ａ…マネージャ、
３…管理対象ノード、
３Ａ…エージェント、
３Ｂ…テーブル型オブジェクト（群）、
１０１、２０１、３０１、４０１…送受信処理部、
１０４、２０４、３０４、４０４…ＴＲＡＰ送信処理部、
１０５−１〜１０５−Ｎ、２０５−１〜２０５−Ｎ、３０５−１〜３０５−Ｎ
、４０５−１〜４０５−Ｎ…オブジェクトアクセス部、
１１１、２１１、３１１、４１１…仮エントリ部、
１１２、２１２、３１２、４１２…オブジェクトカウンタ部、
１１３、２１３、３１３、４１３…アクセス処理部、
１１４、２１４、３１４、４１４…状態管理部、
１１５、２１５、３１５、４１５…Ｉｎｄｅｘ保管部、
１１６、２１６、３１６、４１６…Ｓｔａｔｕｓ保管部、
１１７、２１７、３１７、４１７…ｏｔｈｅｒオブジェクト保管部、
２０７、３０７…共通状態保管部、
３０８…シングルタイマ処理部、
３０９、４０９…タイムアウト処理部、
４０８…マルチタイマ処理部、
４１８…シーケンスナンバ保管部。
【発明の属する技術分野】
本発明は、ネットワーク管理技術における管理対象ノードの管理機能であるネットワーク管理エージェントに関し、特に、管理情報ベース（ＭＩＢ；Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）の一形態であるテーブル型オブジェクトをアクセスするエージェントに関する。
【０００２】
【従来の技術】
図２に、従来のネットワーク管理に係るシステム構成を示す。
【０００３】
図２において、管理ステーション２は、ネットワーク１を通じて、管理対象ノード３にアクセスする。管理する側である管理ステーション２には、管理対象ノード３に対する収集設定要求や収集した情報を加工・蓄積・解析を行うための機能を集約したマネージャ２Ａが存在している。一方、管理される側である管理対象ノード３には、管理項目である管理オブジェクト群３Ｂと、管理オブジェクト群３Ｂを直接アクセスするための管理機能としてのエージェント３Ａとが存在している。
【０００４】
マネージャ２Ａは、管理オブジェクトの情報を収集するために、収集要求として、「ＧＥＴ ＲＥＱＵＥＳＴ」を発信する。この「ＧＥＴ ＲＥＱＵＥＳＴ」に対して、エージェント３Ａは、要求されている情報を、「ＧＥＴ ＲＥＳＰＯＮＳＥ」としてマネージャ２Ａに返信する。また、マネージャ２Ａは、管理オブジェクトに対して何らかの設定変更を行う設定要求として、その設定値を格納した「ＳＥＴ ＲＥＱＵＥＳＴ」を発信する。エージェント３Ａは、この設定変更の結果を「ＧＥＴ ＲＥＳＰＯＮＳＥ」としてマネージャ２Ａに返信する。エージェント３Ａは、マネージャ２Ａに対して、管理対象ノード３で発生している異常などを、「ＴＲＡＰ」を発信して一方的に通知する。
【０００５】
図３に、管理オブジェクト群３Ｂの内の一つの形態であるテーブル型オブジェクト（テーブル型ＭＩＢオブジェクト）の構成例を示す。
【０００６】
図３に示す構成例では、テーブルの行にあたる各エントリに５個のオブジェクトが存在している。これらのオブジェクトには、３種類があり、インデックスオブジェクト（Ｉｎｄｅｘオブジェクト）Ａ，Ｂ、状態オブジェクト（Ｓｔａｔｕｓオブジェクト）Ｅ、その他のオブジェクト（ｏｔｈｅｒオブジェクト）Ｃ，Ｄに分けられる。ＩｎｄｅｘオブジェクトＡ，Ｂは、その値がそのまま各エントリを区別する識別子として用いられるものであり、対象管理機能に関係する。ＳｔａｔｕｓオブジェクトＥの値は、各エントリの状態を表しており、状態管理機能に関係する。ＳｔａｔｕｓオブジェクトＥの値には、ｖａｌｉｄ（有効）、ｃｒｅａｔｅＲｅｑｕｅｓｔ（生成要求）、ｕｎｄｅｒＣｒｅａｔｉｏｎ（生成中）、ｉｎｖａｌｉｄ（無効）の４種類ががある。ｏｔｈｅｒオブジェクトＣ，Ｄについての説明は省略する。
【０００７】
次に、テーブル型オブジェクトヘのエントリの従来の生成方法及び削除方法について、上述した図３を参照しながら簡単に説明する。
【０００８】
図３に示すテーブル型オブジェクトの例において、マネージャ２Ａが、管理対象ノード３に対して４個目のエントリ４を生成する場合、マネージャ２Ａは、「ＳＥＴ ＲＥＱＵＥＳＴ」を発信して、エージェント３Ａを介して、エントリ４のＳｔａｔｕｓオブジェクトの値をｃｒｅａｔｅＲｅｑｕｅｓｔに設定する。エージェント３Ａがこの要求を受け入れ、メモリ確保などの初期化処理を終えると、エージェント３Ａ自身がこの値をｕｎｄｅｒＣｒｅａｔｉｏｎに設定する。そして次に、マネージャ２Ａがエントリ４中の他の各オブジェクトの値を設定し、Ｓｔａｔｕｓオブジェクトの値をｖａｌｉｄに設定すると、このエントリ４が機能し始める。
【０００９】
また、エントリを削除する場合、マネージャ２Ａは、削除対象のエントリに対して、「ＳＥＴ ＲＥＱＵＥＳＴ」を発信して、エージェント３Ａを介して、そのエントリのＳｔａｔｕｓオブジェクトの値をｉｎｖａｌｉｄに設定する。これにより、エージェント３Ａはそのエントリを削除する。
【００１０】
図４に、エントリ生成時のシーケンス図を示す。以下、この図４を参照しながら、エントリ生成処理を、上述した以上に詳述する。
【００１１】
マネージャ２Ａが、管理対象ノード３に対してエントリ１を生成する場合、マネージャ２Ａは、「ＳＥＴ ＲＥＱＵＥＳＴ」を発信する。この「ＳＥＴ ＲＥＱＵＥＳＴ」には、ＳｔａｔｕｓオブジェクトＥに関し、ＩｎｄｅｘとｃｒｅａｔｅＲｅｑｕｅｓｔとの情報を含み、また、ｏｔｈｅｒオブジェクトＣ及びＤに関し、Ｉｎｄｅｘと設定する情報とを含み、さらに、再び、ＳｔａｔｕｓオブジェクトＥに関し、Ｉｎｄｅｘとｖａｌｉｄとの情報を含む。
【００１２】
エージェント３Ａは、このような「ＳＥＴ ＲＥＱＵＥＳＴ」に応じ、エントリ１に対し、ＩｎｄｅｘとｃｒｅａｔｅＲｅｑｕｅｓｔを含むＳｔａｔｕｓオブジェクトＥについての情報に応じ、ＩｎｄｅｘオブジェクトＡ及びＢにそのＩｎｄｅｘを設定すると共に、ＳｔａｔｕｓオブジェクトＥにｃｒｅａｔｅＲｅｑｕｅｓに設定する。その後、ｏｔｈｅｒオブジェクトＣ及びＤに到来した情報を設定し、最後に、ＳｔａｔｕｓオブジェクトＥの値をｖａｌｉｄに設定して、エントリ内の５個のオブジェクトＡ〜Ｅの生成を終了する。そして、エージェント３Ａは、エントリが正常に生成されたとして、「ＧＥＴ ＲＥＳＰＯＮＳＥ」をｎｏＥｒｒｏｒ（正常）で返信する。
【００１３】
【発明が解決しようとする課題】
しかしながら、マネージャ２Ａが発信した「ＳＥＴ ＲＥＱＵＥＳＴ」内のエントリ生成要求に不備がある場合がある。これは、マネージャ２Ａから送出された時点で不備なこともあれば、ネットワーク１を介することにより、不備になることもある。
【００１４】
図４のエントリ２の設定は、不備な設定の場合を示している。すなわち、オブジェクトＣの値が不明のままエントリ２が生成され、「ＧＥＴ ＲＥＳＰＯＮＳＥ」もｎｏＥｒｒｏｒでマネージャ２Ａに返信されている場合である。
【００１５】
このような場合、マネージャ２Ａは、このエントリ２の生成の不備を発見するために、エントリ２に対して「ＧＥＴ ＲＥＱＵＥＳＴ」を発信して５個のオブジェクトＡ〜Ｅの値を取得して、その正常性を確認することになる。
【００１６】
すなわち、従来では、「ＧＥＴ ＲＥＳＰＯＮＳＥ」がｎｏＥｒｒｏｒであっても、エントリ生成に対してその正常性を確認するために、マネージャ２Ａは、「ＳＥＴ ＲＥＱＵＥＳＴ」が終了した後に、「ＧＥＴ ＲＥＱＵＥＳＴ」で収集要求を発信していた。
【００１７】
以上のように、従来では、マネージャの負荷が高く、また、マネージャとエージェント間のネットワークヘの負荷が高くなるという課題があった。
【００１８】
そのため、マネージャの負荷を軽減でき、また、マネージャとエージェント間のネットワークヘの負荷を軽減できるネットワーク管理エージェントが求められている。
【００１９】
【課題を解決するための手段】
かかる課題を解決するため、本発明は、マネージャとの通信処理を行う通信処理手段と、この通信処理手段からのオブジェクト毎の要求に対してテーブル型オブジェクトにアクセスするアクセス手段とを有するネットワーク管理エージェントにおいて、（１）上記アクセス手段は、（１−１）要求を受付けたインデックスオブジェクトの値を保管するインデックス保管部と、当該仮エントリ部がエントリ生成中であるか否かの状態を保管する状態保管部と、インデックスオブジェクトと状態オブジェクト以外のオブジェクトの値を保管する他オブジェクト保管部とを少なくとも含み、エントリ生成時に仮エントリが生成される仮エントリ部と、（１−２）エントリ生成時にまず、上記仮エントリ部に仮エントリを生成させると共に、上記仮エントリ部に仮エントリが正常に生成されたときに、対応するテーブル型オブジェクトにアクセスしてエントリを設定するアクセス処理部と、（１−３）エントリ生成時に要求を受付けたオブジェクトの数をカウントするオブジェクトカウント部と、（１−４）要求を受付けたオブジェクトの種別と上記仮エントリ部の状態保管部の値から状態及び状態遷移を管理する状態管理部とを備え、（２）上記アクセス処理部は、オブジェクト毎の要求時に、上記仮エントリ部の仮エントリ、及び、上記オブジェクトカウント部がカウントした要求を受け付けたオブジェクトの数とをもって上記状態管理部に問い合わせて、エントリ設定の正常、異常を判定することを特徴とする。
【００２０】
【発明の実施の形態】
（Ａ）第１の実施形態
以下、本発明によるネットワーク管理エージェントの第１の実施形態を図面を参照しながら、詳述する。
【００２１】
（Ａ−１）第１の実施形態の構成
図１は、第１の実施形態の管理対象ノードにおけるエージェントの構成を示している。なお、上述した図２との同一、対応部分には、同一符号を付して示している。
【００２２】
図１において、第１の実施形態の管理対象ノード３におけるエージェント３Ａは、送受信処理部１０１、ＴＲＡＰ送信処理部１０４、及び、複数のオブジェクトアクセス部１０５−１〜１０５−Ｎを有する。送受信処理部１０１は、ＲＥＱＵＥＳＴ受信処理部１０２及びＲＥＳＰＯＮＳＥ送信処理部１０３でなる。
【００２３】
ネットワーク１より受信した「ＧＥＴ ＲＥＱＵＥＳＴ」、「ＳＥＴ ＲＥＱＵＥＳＴ」等の複数のオブジェクトについての収集及び設定要求からなるメッセージは、ＲＥＱＵＥＳＴ受信処理部１０２でオブジェクト毎の要求に分解される。分解されたオブジェクト毎の要求は、それぞれに対応するオブジェクトアクセス部１０５−１、…、１０５−Ｎに送られる。オブジェクトアクセス部１０５−１、…、１０５−Ｎは、それぞれ担当するテーブル型オブジェクト１０６−１、…、１０６−Ｎにアクセスを行う。
【００２４】
オブジェクトアクセス部１０５−１、…、１０５−Ｎは、アクセスの結果を、ＲＥＳＰＯＮＳＥ送信処理部１０３に与える。ＲＥＳＰＯＮＳＥ送信処理部１０３は、オブジェクト毎に返ってきたアクセスの結果をメッセージとして組み立て、「ＧＥＴ ＲＥＳＰＯＮＳＥ」としてネットワーク１に送信する。
【００２５】
ＴＲＡＰ送信処理部１０４は、オブジェクトアクセス部１０５−１、…、１０５−Ｎから受けた異常検出などをメッセージとして組み立て「ＴＲＡＰ」をネットワーク１に送信する。
【００２６】
図５は、エージェント３Ａ内のオブジェクトアクセス部１０５−ｎ（ｎは１〜Ｎ）の詳細構成を示している。
【００２７】
オブジェクトアクセス部１０５−ｎは、仮エントリ部１１１、オブジェクトカウンタ部１１２、アクセス処理部１１３及び状態管理部１１４からなる。
【００２８】
アクセス処理部１１３は、送受信処理部１０１又はＴＲＡＰ送信部１０４と、自己が担当するテーブル型オブジェクト１０６−ｎとのデータの仲介処理を行う。アクセス処理部１１３は、仲介処理を実行するときに、適宜、仮エントリ部１１１に保管されている情報を利用したり、仮エントリ部１１１に所定情報を保管したり、また、オブジェクトカウンタ部１１２のカウント値を利用したり、カウント値を更新したり、さらに、状態管理部１１４を利用したりする。
【００２９】
仮エントリ部１１１は、Ｉｎｄｅｘ保管部１１５、Ｓｔａｔｕｓ保管部１１６及びｏｔｈｅｒオブジェクト保管部１１７からなり、それぞれ、Ｉｎｄｅｘ、Ｓｔａｔｕｓ及びｏｔｈｅｒオブジェクトを保管するものである。
【００３０】
エージェント３Ａの構成要素の詳細機能については、後述する動作説明で明らかにする。
【００３１】
（Ａ−２）第１の実施形態の動作
次に、第１の実施形態に係るシステムの動作シーケンスを、正常時の動作、異常時の動作、ＲＥＳＥＴ時の動作の順に説明する。
【００３２】
［正常時の動作］
図６に、正常時の動作シーケンス図を示す。
【００３３】
マネージャ２Ａは、エントリ生成要求として、「ＳＥＴ ＲＥＱＵＥＳＴ」のメッセージをエージェント３Ａに送信する。メッセージの内容は、従来と同様である。
【００３４】
メッセージを受信したエージェント３Ａにおいては、送受信処理部１０１から対応するオブジェクトアクセス部１０５−ｎヘオブジェクト毎の要求を行う。
【００３５】
オブジェクトアクセス部１０５−ｎにおいて、仮エントリ部１１１の各保管部１１５、１１６、１１７は、「Ｅ．Ｉｎｄｅｘ：ｃｒｅａｔｅＲｅｑｕｅｓｔ」の要求前の初期状態では全て初期値になっており、Ｓｔａｔｕｓ保管部１１６は状態値として「Ｓｔａｔｕｓ：ｎｏｎＥｘｉｓｔ」を保管し、他の保管部１１５、１１７は「ＮＵＬＬ」を保管している。また、この初期状態では、オブジェクトカウンタ部１１２のカウント値は「０」である。
【００３６】
アクセス処理部１１３は、送受信処理部１０１から、「Ｅ．Ｉｎｄｅｘ：ｃｒｅａｔｅＲｅｑｕｅｓｔ」の要求が与えられると、状態管理部１１４に状態問合せを行い、その結果、Ｓｔａｔｕｓ保管部１１６の状態を「Ｓｔａｔｕｓ：ｕｎｄｅｒＣｒｅａｔｉｏｎ」に変更し、オブジェクトカウンタ部１１２を「１」にカウントアップし、Ｉｎｄｅｘ保管部１１５にオブジェクトＡ、Ｂを格納する。なお、このときには、ｏｔｈｅｒオブジェクト保管部１１７に保管するオブジェクトは存在しない。
【００３７】
アクセス処理部１１３は、次に、送受信処理部１０１から、「Ｃ．Ｉｎｄｅｘ：ＸＸＸ」の要求が与えられると、状態管理部１１４に状態問合せを行い、その結果、Ｓｔａｔｕｓ保管部１１６の状態を維持し（同一情報ではあるが再格納するようにしても良い）、オブジェクトカウンタ部１１２を「２」にカウントアップし、ｏｔｈｅｒオブジェクト保管部１１７にオブジェクトＣを保管する。このときに、Ｉｎｄｅｘ保管部１１５の格納状態を維持するようにしても良く、又、オブジェクトＡ、Ｂを再格納するようにしても良い。
【００３８】
アクセス処理部１１３は、送受信処理部１０１から、「Ｄ．Ｉｎｄｅｘ：ＸＸＸ」の要求が与えられるときも、送受信処理部１０１から、「Ｃ．Ｉｎｄｅｘ：ＸＸＸ」の要求が与えられるときと同様に処理する。なお、「Ｄ．Ｉｎｄｅｘ：ＸＸＸ」の要求に対する処理を実行したときには、仮エントリ部１１１には必要な情報が全て保管されている。
【００３９】
そして、アクセス処理部１１３は、送受信処理部１０１から、「Ｅ．Ｉｎｄｅｘ：ｖａｌｉｄ」という最後の要求を受け付けた時点で、仮エントリ部１１１に保管されている１組の仮エントリ内容をテーブル型オブジェクト３Ｂにエントリ設定する。その後、アクセス処理部１１３は、仮エントリ部１１１とオブジェクトカウンタ部１１２の初期化を行う。この初期化により、Ｓｔａｔｕｓ保管部１１６の状態は「Ｓｔａｔｕｓ：ｎｏｎＥｘｉｓｔ」となり、オブジェクトカウンタ部１１２のカウント値は「０」になり、Ｉｎｄｅｘ保管部１１５及びｏｔｈｅｒオブジェクト保管部１１７の保管内容は、「ＮＵＬＬ」となる。
【００４０】
オブジェクトアクセス部１０５−ｎは、エントリの生成が正常に終了したことを送受信処理部１０１に「ｎｏＥｒｒｏｒ」として伝える。送受信処理部１０１のＲＥＳＰＯＮＳＥ送信処理部１０３は、「ｎｏＥｒｒｏｒ」を「ＧＥＴ ＲＥＳＰＯＮＳＥ」のメッセージとして組み立てマネージャ２Ａに送信する。
【００４１】
［異常時の動作］
図７に、異常時の動作シーケンス図を示す。
【００４２】
図７の例では、マネージャ２Ａから送信された「ＳＥＴ ＲＥＱＵＥＳＴ」のメッセージに不備があり、図６の場合に比較して、最終要求の「Ｅ．Ｉｎｄｅｘ：ｖａｌｉｄ」が抜け落ちている。
【００４３】
そのため、オブジェクトアクセス部１０５−ｎは、「Ｄ．Ｉｎｄｅｘ：ＸＸＸ」の要求に対する処理を実行した段階で動作が停止している。すなわち、仮エントリ部１１１とオブジェエクトカウンタ部１１２は、「Ｄ．Ｉｎｄｅｘ：ＸＸＸ」の要求に対する処理を実行した段階での値を継続して保持し、テーブル型オブジェクト３Ｂヘのエントリ設定は行われない。
【００４４】
このような状態で、次の「ＳＥＴ ＲＥＱＵＥＳＴ」のメッセージが与えられると、アクセス処理部１１３による状態管理部１１４への問合せにより、異常が検出される。異常検出時には、オブジェクトアクセス部１０５−ｎは、Ｉｎｄｅｘ保管部１１５のＩｎｄｅｘオブジェクトＡ、ＢをＴＲＡＰのメッセージとしてＴＲＡＰ送信処理部１０４にＴＲＡＰ要求を出す。
【００４５】
ＴＲＡＰ送信処理部１０４は、メッセージを組立てマネージャ２Ａに「ＴＲＡＰ」を送信する。その後、仮エントリ部１１１とオブジェクトカウンタ部１１２は、今回の「ＳＥＴ ＲＥＱＵＥＳＴ」に関わる状態に新規設定され、次のオブジェクトの要求を待つ。
【００４６】
［ＲＥＳＥＴ時の動作］
図８に、ＲＥＳＥＴ時の動作シーケンス図を示す。
【００４７】
マネージャ２Ａは、仮エントリ部１１１の状態を初期化するために、「Ｅ．Ｉｎｄｅｘ：Ｒｅｓｅｔ」のメッセ一ジを持った「ＳＥＴ ＲＥＱＵＥＳＴ」を送信する。
【００４８】
この要求を受けたオブジェクトアクセス部１０５−ｎでは、仮エントリ部１１１とオブジェクトカウンタ部１１２の初期化を行い、Ｓｔａｔｕｓ保管部１１６の状態は「Ｓｔａｔｕｓ：ｎｏｎＥｘｉｓｔ」となる。
【００４９】
「Ｅ．Ｉｎｄｅｘ：Ｒｅｓｅｔ」を含むメッセージは、あるテーブル型オブジェクトの最後のエントリ生成要求の後、若しくは、異なるテーブル型オブジェクトのエントリ生成要求に移るときに送信することにより、オブジェクトアクセス部１０５−ｎの状態を初期化したり、その直前の要求での異常検出を行なったりすることができる。
【００５０】
［状態遷移］
図９に、以上のような正常時、異常時、ＲＥＳＥＴ時の動作を実行させるための状態遷移図を示す。
【００５１】
この状態遷移図は、アクセス処理部１１３で受け付けたオブジェクトの種別とＳｔａｔｕｓ保管部１１７の状態から、次にアクセス処理部１１３が実行する処理を表している。なお、各処理については、図９での記載に委ね、その説明は省略する。
【００５２】
状態管理部１１４では、この状態遷移図を基にアクセス処理部１１３からの状態問合せに応答する。
【００５３】
（Ａ−３）第１の実施形態の効果
上述した第１の実施形態によれば、以下の効果を奏することができる。
【００５４】
（１）送受信処理部の構成が全くブラックボックスであり、エージェント内部においてはオブジェクトアクセス部とのインタフェースのみ明確になっているときでも、エントリ生成の異常を検出することができる。これにより、送受信処理部に汎用モジュールを用いることが可能で、エージェントの開発時のコストを削減できる。
【００５５】
（２）エージェントが自律的にエントリ生成での異常を検出するので、マネージャにおいて「ＧＥＴ ＲＥＱＵＥＳＴ」によるエントリ生成の正常性の再確認のためのスケジューリングの負荷を削減できる。
【００５６】
（３）エージェントが自律的にエントリ生成での異常を検出するので、管理ステーションと管理対象ノード間のネットワークヘの負荷を軽減できる。
【００５７】
（４）状態管理のみでエントリ生成の異常検出を行なうので、管理対象ノードヘの負荷を軽減できる。
【００５８】
（５）テーブル型オブジェクト毎に状態を管理することにより異なるテーブル型オブジェクトヘのエントリ生成を並列に処理し、エントリ全体の生成にかかる時間を短縮できる。
【００５９】
（Ｂ）第２の実施形態
次に、本発明によるネットワーク管理エージェントの第２の実施形態を図面を参照しながら、詳述する。
【００６０】
（Ｂ−１）第２の実施形態の構成
図１０は、第２の実施形態の管理対象ノードにおけるエージェントの構成を示している。なお、上述した図１、図２との同一、対応部分には、同一、対応符号を付して示している。ここで、対応符号は、第１の実施形態で１００番台であったものを２００番台にしたものである。
【００６１】
図１０において、第２の実施形態の管理対象ノード３におけるエージェント３Ａも、第１の実施形態と同様に、送受信処理部２０１、ＴＲＡＰ送信処理部２０４、及び、複数のオブジェクトアクセス部２０５−１〜２０５−Ｎを有する。第２の実施形態のエージェント３Ａは、以上の構成要素に加えて、全てのオブジェクトアクセス部２０５−１〜２０５−Ｎに接続されている共通状態保管部２０７を有する。
【００６２】
第２の実施形態のオブジェクトアクセス部２０５−ｎ（ｎは１〜Ｎ）は、共通状態保管部２０７が設けられていることと関連し、第１の実施形態とは異なる内部構成となっている。図１１は、このオブジェクトアクセス部２０５−ｎの詳細構成を示している。
【００６３】
第２の実施形態のオブジェクトアクセス部２０５−ｎは、アクセス処理部２１３及び状態管理部２１４を備え、仮エントリ部とオブジェクトカウンタ部は備えていない。アクセス処理部２１３及び状態管理部２１４の機能は、第１の実施形態のものとほぼ同様である。
【００６４】
図１２は、第２の実施形態で新たに設けられた共通状態保管部２０７の詳細構成を示している。
【００６５】
共通状態保管部２０７は、オブジェクトアクセス部２０５−ｎ内のアクセス処理部２１３に接続している、仮エントリ部２１１とオブジェクトカウンタ部２１２とからなる。仮エントリ部２１１は、第１の実施形態と同様に、Ｉｎｄｅｘ保管部２１５と、Ｓｔａｔｕｓ保管部２１６と、ｏｔｈｅｒオブジェクト保管部２１７から構成されている。
【００６６】
（Ｂ−２）第２の実施形態の動作
第２の実施形態においても、［正常時の動作］、［異常時の動作］及び［ＲＥＳＥＴ時の動作］は、第１の実施形態とほぼ同様に行われる（図６〜図８参照）。また、その際のエージェント３Ａでの状態遷移も、第１の実施形態のものとほぼ同様である（図９参照）。
【００６７】
第１の実施形態と異なるのは、以下の点である。各オブジェクトアクセス部２０５−ｎが、仮エントリ部とオブジェクトカウンタ部を持たないため、アクセス処理部２１３は、オブジェクト毎の要求に対して、共通状態保管部２０７の仮エントリ部２１１とオブジェクトカウンタ部２１２の値を参照した後、状態管理部２１４に状態問合せを行ない処理を進める点である。これは、［正常時の動作］、［異常時の動作］、［ＲＥＳＥＴ時の動作］の全てに同様である。
【００６８】
（Ｂ−３）第２の実施形態の効果
第２の実施形態によっても、第１の実施形態の効果（１）〜（４）と同様な効果を奏することができる。
【００６９】
これに加えて、第２の実施形態によれば、以下の効果（６）及び（７）をも奏する。
【００７０】
（６）共通状態保管部のみで状態を保管することによりエージェント構成時のメモリ量を削減できる。
【００７１】
（７）異なるテーブル型オブジェクトヘのエントリ生成要求に移るとき（例えば図１０の２０６−１から２０６−２へ）、「Ｅ．Ｉｎｄｅｘ：Ｒｅｓｅｔ」のメッセージを持った「ＳＥＴ ＲＥＱＵＥＳＴ」を送信せずにエントリ生成を連続して実行しても異常検出ができる。これにより、異常検出時のタイムラグを減少でき、マネージャとネットワークの負荷も軽減できる。
【００７２】
（Ｃ）第３の実施形態
次に、本発明によるネットワーク管理エージェントの第３の実施形態を図面を参照しながら、詳述する。
【００７３】
（Ｃ−１）第３の実施形態の構成
図１３は、第３の実施形態の管理対象ノードにおけるエージェントの構成を示している。なお、上述した図２、図１０との同一、対応部分には、同一、対応符号を付して示している。ここで、対応符号は、第２の実施形態で２００番台であったものを３００番台にしたものである。
【００７４】
図１３において、第３の実施形態の管理対象ノード３におけるエージェント３Ａも、第２の実施形態と同様に、送受信処理部３０１、ＴＲＡＰ送信処理部３０４、複数のオブジェクトアクセス部３０５−１〜３０５−Ｎ、及び、共通状態保管部３０７を有する。
【００７５】
第３の実施形態のエージェント３Ａは、以上の構成要素に加えて、シングルタイマ処理部３０８と、タイムアウト処理部３０９とを有する。タイムアウト処理部３０９は、シングルタイマ処理部３０５と共通状態保管部３０８とＴＲＡＰ送信処理部３０４に接続されている。シングルタイマ処理部３０５は、各オブジェクトアクセス部３０５−ｎから一方向で接続されている。
【００７６】
図１４は、第３の実施形態のオブジェクトアクセス部３０５−ｎの詳細構成を示している。これは、第２の実施形態のものとほぼ同様であるが、アクセス処理部３１３がシングルタイマ処理部３０８にも接続されている点は、第２の実施形態のものと異なっている。
【００７７】
図１５は、第３の実施形態の共通状態保管部３０８の詳細構成を示している。これは、第２の実施形態のものとほぼ同様であるが、仮エントリ部３１１とオブジェクトカウンタ部３１２とがタイムアウト処理部３０９にも接続されている点は、第２の実施形態のものと異なっている。
【００７８】
この第３の実施形態のエージェント３Ａの各部の機能は、後述する動作説明で明らかにする。
【００７９】
（Ｃ−２）第３の実施形態の動作
次に、第３の実施形態に係るシステムの動作シーケンスを、正常時の動作、異常時の動作の順に説明する。
【００８０】
［正常時の動作］
図１６に、正常時の動作シーケンス図を示す。
【００８１】
第３の実施形態の正常時の動作において、第２の実施形態の動作と異なるのは、以下の点である。
【００８２】
送受信処理部３０１において、シングルタイマ処理部３０８は、オブジェクト毎の要求がない場合（図１６では後半のシーケンスが該当する）、一定のタイムアウト間隔でタイムアウト処理部３０９へ「ＴｉｍｅＯｕｔ」を要求する。「ＴｉｍｅＯｕｔ」の要求を受付けたタイムアウト処理部３０９は、共通状態保管部３０８の仮エントリ部３１１内にあるＳｔａｔｕｓ保管部３１６を参照し、「Ｓｔａｔｕｓ：ｎｏｎＥｘｉｓｔ」であれば異常なしと判定する。
【００８３】
また、各オブジェクトアクセス部３０５−ｎは、オブジェクト毎の要求を受けたときに（図１６では前半のシーケンスが該当する）、シングルタイマ処理部３０８に「ＴｉｍｅｒＲｅｓｅｔ」を送り、タイマをリセットする。すなわち、オブジェクトアクセス部３０５−ｎにおけるオブジェクト毎の要求の受付間隔がリセット間隔となる。
【００８４】
リセット間隔は必ずしも一定間隔とは限らないが、ある範囲内の時間であり、リセット間隔＜タイムアウト間隔である。
【００８５】
なお、オブジェクトのエントリ設定動作自体は、第２の実施形態のものと同様である。
【００８６】
［異常時の動作］
図１７に、異常時の動作シーケンス図を示す。
【００８７】
第３の実施形態の異常時の動作において、第２の実施形態の動作と異なるのは、以下の点である。
【００８８】
「ＳＥＴ ＲＥＱＵＥＳＴ」のメッセージに不備があり、最終要求の「Ｅ．Ｉｎｄｅｘ：ｖａｌｉｄ」が抜け落ちている。そのため、オブジェクトアクセス部３０５−ｎは、「Ｄ．Ｉｎｄｅｘ：ＸＸＸ」の要求に対する処理を実行した段階で動作が停止している。すなわち、仮エントリ部３１１とオブジェエクトカウンタ部３１２は、「Ｄ．Ｉｎｄｅｘ：ＸＸＸ」の要求に対する処理を実行した段階での値を継続して保持し、テーブル型オブジェクト３Ｂヘのエントリ設定は行われない。このとき、仮エントリ部３１１のＳｔａｔｕｓ保管部３１６は、「Ｓｔａｔｕｓ：ｕｎｄｅｒＣｒｅａｔｉｏｎ」の状態であり、また、「Ｄ．Ｉｎｄｅｘ：ＸＸＸ」の要求に対する処理に応じた以降、オブジェクトアクセス部３０５−ｎからシングルタイマ処理部３０８に「ＴｉｍｅｒＲｅｓｅｔ」が与えられない。
【００８９】
この状態で、シングルタイマ処理部３０８から「ＴｉｍｅＯｕｔ」を要求されると、タイムアウト処理部３０９は、Ｓｔａｔｕｓ保管部３１６を参照し、異常を検出する。異常を検出したタイムアウト処理部３０９は、Ｉｎｄｅｘ保管部３１５のＩｎｄｅｘオブジェクトＡ、ＢをＴＲＡＰのメッセージとして、ＴＲＡＰ送信処理部３０４にＴＲＡＰ要求を出す。
【００９０】
［状態遷移］
図１８に、以上のような正常時、異常時などの動作を実行させるための状態遷移図を示す。
【００９１】
この状態遷移図は、アクセス処理部３１３で受け付けたオブジェクトの種別とＳｔａｔｕｓ保管部３１７の状態から、次にアクセス処理部３１３が実行する処理を表している。第１や第２の実施形態と異なるのは、次の点である。受付オブジェクトの種別に「Ｒｅｓｅｔ」は存在しない。その代わりに、「ＴｉｍｅＯｕｔ」が存在する。
【００９２】
（Ｃ−３）第３の実施形態の効果
第３の実施形態によっても、第１の実施形態の効果（１）〜（４）と同様な効果を奏することができ、また、第２の実施形態の効果（６）と同様な効果を奏することができる。
【００９３】
これに加えて、第３の実施形態によれば、以下の効果（８）をも奏する。
【００９４】
（８）「ＴｉｍｅＯｕｔ」を用いたエントリ生成の異常検出により、ランダムなエントリ生成を行なっても異常検出が可能である。これは管理ステーションにおいてエントリ生成のスケジューリングの自由度を大きくする。
【００９５】
（Ｄ）第４の実施形態
次に、本発明によるネットワーク管理エージェントの第４の実施形態を図面を参照しながら、詳述する。
【００９６】
（Ｄ−１）第４の実施形態の構成
図１９は、第４の実施形態の管理対象ノードにおけるエージェントの構成を示している。なお、上述した図１、図２との同一、対応部分には、同一、対応符号を付して示している。ここで、対応符号は、第１の実施形態で１００番台であったものを４００番台にしたものである。
【００９７】
図１９において、第４の実施形態の管理対象ノード３におけるエージェント３Ａも、第１の実施形態と同様に、送受信処理部４０１、ＴＲＡＰ送信処理部４０４及び複数のオブジェクトアクセス部４０５−１〜４０５−Ｎを有する。
【００９８】
第４の実施形態のエージェント３Ａは、さらに、マルチタイマ処理部４０８及びタイムアウト処理部４０９を備える。マルチタイマ処理部４０８は、オブジェクトアクセス部４０５−１〜４０５−Ｎとタイムアウト処理部４０９とに接続されいる。また、タイムアウト処理部４０９は、オブジェクトアクセス部４０５−１〜４０５−ＮとＴＲＡＰ送信処理部４０４とに接続されている。
【００９９】
図２０は、第４の実施形態のオブジェクトアクセス部４０５−ｎの詳細構成を示している。
【０１００】
第４の実施形態のオブジェクトアクセス部４０５−ｎは、第１の実施形態のものとほぼ同様であるが、仮エントリ部４１１にシーケンスナンバ保管部４１８が設けられている点、並びに、アクセス処理部４１３がマルチタイマ処理部４０８及びタイムアウト処理部４０９に接続している点が、第１の実施形態のものとは異なっている。
【０１０１】
（Ｄ−２）第４の実施形態の動作
次に、第４の実施形態に係るシステムの動作シーケンスを、正常時の動作、異常時の動作の順に説明する。
【０１０２】
［正常時の動作］
図２１に、正常時の動作シーケンス図を示す。
【０１０３】
第４の実施形態の正常時の動作において、第１の実施形態の動作と異なるのは、以下のような計時処理に係る点である。なお、基本的なエントリ設定動作は、第１の実施形態と同様である。
【０１０４】
送受信処理部４０１からオブジェクトアクセス部４０５−ｎへ「Ｅ．Ｉｎｄｅｘ：ｃｒｅａｔｅＲｅｑｕｅｓｔ」の要求時に、オブジェクトアクセス部４０５−ｎはマルチタイマ処理部４０８へ「ＴｉｍｅｒＳｅｔ」の要求を行う。このとき、オブジェクトアクセス部４０５−ｎでは、シーケンスナンバ保管部４１８の値をカウントアップし、そのカウント値（シーケンスナンバ）と各オブジェクトアクセス部４０５−ｎ毎にユニークな仮エントリＩＤをマルチタイマ処理部４０８に送る。
【０１０５】
マルチタイマ処理部４０８は、仮エントリＩＤとシーケンスナンバを保持し、これを担当する１つのタイマを起動する。このタイマが起動してから、タイムアウトするまでのタイムアウト間隔は、「ＳＥＴ ＲＥＱＵＥＳＴ」が当該エージェント３Ａに到達してから、正常なエントリ設定がなされて当該エージェント３Ａが「ＧＥＴ ＲＥＳＰＯＮＳＥ」を送信するまでのエントリ生成間隔より長くなされている。
【０１０６】
マルチタイマ処理部４０８における担当タイマがタイムアウトすると、マルチタイマ処理部４０８は、タイムアウト処理部４０９へ「ＴｉｍｅＯｕｔ」を要求する。このとき、マルチタイマ処理部４０８は、保持していた仮エントリＩＤとシーケンスナンバをタイムアウト処理部４０９に送る。
【０１０７】
タイムアウト処理部４０９は仮エントリＩＤから対応するオブジェクトアクセス部４０５−ｎを識別し、その仮エントリ部４１１内にあるＳｔａｔｕｓ保管部４１６を参照し、「Ｓｔａｔｕｓ：ｎｏｎＥｘｉｓｔ」であれば異常なしと判定する。
【０１０８】
［異常時の動作］
図２２に、異常時の動作シーケンス図を示す。
【０１０９】
第４の実施形態の異常時の動作において、第１の実施形態の動作と異なるのは、以下の点である。
【０１１０】
「ＳＥＴ ＲＥＱＵＥＳＴ」のメッセージに不備があり、最終要求の「Ｅ．Ｉｎｄｅｘ：ｖａｌｉｄ」が抜け落ちている。そのため、オブジェクトアクセス部４０５−ｎは、「Ｄ．Ｉｎｄｅｘ：ＸＸＸ」の要求に対する処理を実行した段階で動作が停止している。すなわち、仮エントリ部４１１とオブジェエクトカウンタ部４１２は、「Ｄ．Ｉｎｄｅｘ：ＸＸＸ」の要求に対する処理を実行した段階での値を継続して保持し、テーブル型オブジェクト３Ｂヘのエントリ設定は行われない。このとき、仮エントリ部４１１のＳｔａｔｕｓ保管部３１６は、「Ｓｔａｔｕｓ：ｕｎｄｅｒＣｒｅａｔｉｏｎ」の状態である。
【０１１１】
このような状況において、マルチタイマ処理部４０８から「ＴｉｍｅＯｕｔ」を要求されると、タイムアウト処理部４０９は、仮エントリＩＤから対応するオブジェクトアクセス部４０５−ｎを識別し、仮エントリ部４１１内にあるＳｔａｔｕｓ保管部４１６を参照し「Ｓｔａｔｕｓ：ｍｄｅｒＣｒｅａｔｉｏｎ」であれば、仮エントリ部４１１内にあるシーケンスナンバ保管部４１８の値とマルチタイマ処理部４０８から受け取ったシーケンスナンバのマッチングを行う。ここで値が一致すれば、異常を検出する。
【０１１２】
異常を検出したタイムアウト処理部４０９は、Ｉｎｄｅｘ保管部４１５のＩｎｄｅｘオブジェクトＡ、ＢをＴＲＡＰのメッセージとしてＴＲＡＰ送信処理部４０４にＴＲＡＰ要求を出す。
【０１１３】
［状態遷移］
図２３に、以上のような正常時、異常時などの動作を実行させるための状態遷移図を示す。
【０１１４】
この状態遷移図は、アクセス処理部４１３で受け付けたオブジェクトの種別とＳｔａｔｕｓ保管部４１７の状態から、次にアクセス処理部４１３が実行する処理を表している。第１の実施形態と異なるのは、次の点である。受付オブジェクトの種別に「Ｒｅｓｅｔ」は存在しない。その代わりに、「ＴｉｍｅＯｕｔ」が存在する。また、受付オブジェクトの種別がＳｔａｔｕｓオブジェクト「ｃｒｅａｔｅＲｅｑｕｅｓｔ」で、Ｓｔａｔｕｓ保管部４１７が「ｎｏｎＥｘｉｓｔ」のときの処理が異なる。
【０１１５】
（Ｄ−３）第４の実施形態の効果
第４の実施形態によっても、第１の実施形態の効果（１）〜（５）と同様な効果を奏することができる。
【０１１６】
これに加えて、第４の実施形態によれば、以下の効果（９）をも奏する。
【０１１７】
（９）エントリ生成を並列に処理している場合でも、オブジェクトアクセス部毎の「ＴｉｍｅＯｕｔ」を用いたエントリ生成の異常検出により、ランダムなエントリ生成を行なっても異常検出が可能である。これは管理ステーションにおいてエントリ生成のスケジューリングの自由度を大きくする。
【０１１８】
（Ｅ）他の実施形態
１エントリでのオブジェクト数などは、上記実施形態のものに限定されるものではない。本発明のネットワーク管理エージェントが適用できるネットワーク管理システムの用途は限定されるものではない。
【０１１９】
【発明の効果】
以上のように、本発明によれば、仮エントリ機能を備え、仮エントリが正常になされたときにテーブル型オブジェクトにエントリ設定すると共に、仮エントリが生成中を条件として、異常通知をマネージャに行うようにしたので、マネージャの負荷を軽減でき、また、マネージャとエージェント間のネットワークヘの負荷を軽減できるネットワーク管理エージェントを実現できる。
【図面の簡単な説明】
【図１】第１の実施形態の管理対象ノード内のエージェント構成を示すブロック図である。
【図２】従来のネットワーク管理に係るシステム構成等を示す説明図である。
【図３】テーブル型ＭＩＢオブジェクトの構成例を示す説明図である。
【図４】従来のネットワーク管理動作を示す動作シーケンス図である。
【図５】第１の実施形態のオブジェクトアクセス部の詳細構成を示すブロック図である。
【図６】第１の実施形態の正常時の動作シーケンス図である。
【図７】第１の実施形態の異常時の動作シーケンス図である。
【図８】第１の実施形態のＲＥＳＥＴ時の動作シーケンス図である。
【図９】第１の実施形態のエージェントでの状態遷移を示す図面である。
【図１０】第２の実施形態の管理対象ノード内のエージェント構成を示すブロック図である。
【図１１】第２の実施形態のオブジェクトアクセス部の詳細構成を示すブロック図である。
【図１２】第２の実施形態の共通状態保管部の詳細構成を示すブロック図である。
【図１３】第３の実施形態の管理対象ノード内のエージェント構成を示すブロック図である。
【図１４】第３の実施形態のオブジェクトアクセス部の詳細構成を示すブロック図である。
【図１５】第３の実施形態の共通状態保管部の詳細構成を示すブロック図である。
【図１６】第３の実施形態の正常時の動作シーケンス図である。
【図１７】第３の実施形態の異常時の動作シーケンス図である。
【図１８】第３の実施形態のエージェントでの状態遷移を示す図面である。
【図１９】第４の実施形態の管理対象ノード内のエージェント構成を示すブロック図である。
【図２０】第４の実施形態のオブジェクトアクセス部の詳細構成を示すブロック図である。
【図２１】第４の実施形態の正常時の動作シーケンス図である。
【図２２】第４の実施形態の異常時の動作シーケンス図である。
【図２３】第４の実施形態のエージェントでの状態遷移を示す図面である。
【符号の説明】
２…管理ステーション、
２Ａ…マネージャ、
３…管理対象ノード、
３Ａ…エージェント、
３Ｂ…テーブル型オブジェクト（群）、
１０１、２０１、３０１、４０１…送受信処理部、
１０４、２０４、３０４、４０４…ＴＲＡＰ送信処理部、
１０５−１〜１０５−Ｎ、２０５−１〜２０５−Ｎ、３０５−１〜３０５−Ｎ
、４０５−１〜４０５−Ｎ…オブジェクトアクセス部、
１１１、２１１、３１１、４１１…仮エントリ部、
１１２、２１２、３１２、４１２…オブジェクトカウンタ部、
１１３、２１３、３１３、４１３…アクセス処理部、
１１４、２１４、３１４、４１４…状態管理部、
１１５、２１５、３１５、４１５…Ｉｎｄｅｘ保管部、
１１６、２１６、３１６、４１６…Ｓｔａｔｕｓ保管部、
１１７、２１７、３１７、４１７…ｏｔｈｅｒオブジェクト保管部、
２０７、３０７…共通状態保管部、
３０８…シングルタイマ処理部、
３０９、４０９…タイムアウト処理部、
４０８…マルチタイマ処理部、
４１８…シーケンスナンバ保管部。
Claims (5)
- マネージャとの通信処理を行う通信処理手段と、この通信処理手段からのオブジェクト毎の要求に対してテーブル型オブジェクトにアクセスするアクセス手段とを有するネットワーク管理エージェントにおいて、
上記アクセス手段は、
要求を受付けたインデックスオブジェクトの値を保管するインデックス保管部と、当該仮エントリ部がエントリ生成中であるか否かの状態を保管する状態保管部と、インデックスオブジェクトと状態オブジェクト以外のオブジェクトの値を保管する他オブジェクト保管部とを少なくとも含み、エントリ生成時に仮エントリが生成される仮エントリ部と、
エントリ生成時にまず、上記仮エントリ部に仮エントリを生成させると共に、上記仮エントリ部に仮エントリが正常に生成されたときに、対応するテーブル型オブジェクトにアクセスしてエントリを設定するアクセス処理部と、
エントリ生成時に要求を受付けたオブジェクトの数をカウントするオブジェクトカウント部と、
要求を受付けたオブジェクトの種別と上記仮エントリ部の状態保管部の値から状態及び状態遷移を管理する状態管理部とを備え、
上記アクセス処理部は、オブジェクト毎の要求時に、上記仮エントリ部の仮エントリ、及び、上記オブジェクトカウント部がカウントした要求を受け付けたオブジェクトの数とをもって上記状態管理部に問い合わせて、エントリ設定の正常、異常を判定する
ことを特徴とするネットワーク管理エージェント。 - 上記仮エントリ部、上記アクセス処理部、上記オブジェクトカウント部及び上記状態管理部が、複数のテーブル型オブジェクトのそれぞれに対応して個別に設けられていることを特徴とする請求項１に記載のネットワーク管理エージェント。
- 上記アクセス手段は、
計時時間がエントリ生成要求の受信時から、正常なエントリ設定がなされる時間より長い、上記アクセス処理部毎に対応した複数のタイマを設定するマルチタイマ処理部と、
上記アクセス処理部毎のタイムアウトをトリガに、その上記アクセス処理部に対応した上記仮エントリ部内の上記状態保管部の値から、エントリ生成における異常を検出し、異常通知を行うタイムアウト処理部とをさらに有する
ことを特徴とする請求項２に記載のネットワーク管理エージェント。 - 上記アクセス処理部及び上記状態管理部が、複数のテーブル型オブジェクトのそれぞれに対応して個別に設けられていると共に、上記仮エントリ部及び上記オブジェクトカウント部が、複数のテーブル型オブジェクトに共通して設けられていることを特徴とする請求項１に記載のネットワーク管理エージェント。
- 上記アクセス手段は、
一定の間隔でタイマを設定し、上記仮エントリ部がオブジェクトを仮エントリする毎に送出するリセット要求でタイマを設定し直すシングルタイマ処理部と、
上記シングルタイマ処理部のタイムアウトをトリガに、上記仮エントリ部の上記状態保管部の値からエントリ生成における異常を検出し、異常通知を行うタイムアウト処理部とをさらに有する
ことを特徴とする請求項４に記載のネットワーク管理エージェント。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP24096799A JP3741573B2 (ja) | 1999-08-27 | 1999-08-27 | ネットワーク管理エージェント |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP24096799A JP3741573B2 (ja) | 1999-08-27 | 1999-08-27 | ネットワーク管理エージェント |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001067326A JP2001067326A (ja) | 2001-03-16 |
| JP3741573B2 true JP3741573B2 (ja) | 2006-02-01 |
Family
ID=17067327
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP24096799A Expired - Fee Related JP3741573B2 (ja) | 1999-08-27 | 1999-08-27 | ネットワーク管理エージェント |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3741573B2 (ja) |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3483364B2 (ja) * | 1995-09-07 | 2004-01-06 | Ｋｄｄｉ株式会社 | Ｓｎｍｐ／ｏｓｉ管理ゲートウェイ装置 |
-
1999
- 1999-08-27 JP JP24096799A patent/JP3741573B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001067326A (ja) | 2001-03-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2021203623A1 (zh) | 一种物联网资源接入系统及资源接入方法 | |
| US6076100A (en) | Server-side chat monitor | |
| US6205122B1 (en) | Automatic network topology analysis | |
| US6925079B2 (en) | IP address duplication detection method using address resolution protocol | |
| US5568605A (en) | Resolving conflicting topology information | |
| JP3315404B2 (ja) | ネットワークのトポロジ的特徴を探知する方法 | |
| EP3734913A1 (en) | Communication method and communication apparatus | |
| US6175874B1 (en) | Packet relay control method packet relay device and program memory medium | |
| US7308597B2 (en) | Analysis of pipelined networks | |
| US7330889B2 (en) | Network interaction analysis arrangement | |
| CN106302434A (zh) | 服务器适配方法、装置和系统 | |
| US20050132154A1 (en) | Reliable leader election in storage area network | |
| US6219705B1 (en) | System and method of collecting and maintaining historical top communicator information on a communication device | |
| CN1886935B (zh) | 用于收集有关通信网络的信息和用于收集有关在通信网络节点上运行的操作系统的信息的方法和系统 | |
| CN103581276A (zh) | 集群管理装置、系统、业务客户端及相应方法 | |
| US8335843B2 (en) | Communication system having multiple communication lines between a transmitter and a receiver | |
| CN113596176A (zh) | 物联网中心节点的自选方法、装置、物联网设备和系统 | |
| CN109921925A (zh) | 一种拨测方法及装置 | |
| US20170302533A1 (en) | Method for the exchange of data between nodes of a server cluster, and server cluster implementing said method | |
| CN109981795A (zh) | 资源请求调度方法和装置 | |
| JP3741573B2 (ja) | ネットワーク管理エージェント | |
| CN103973827A (zh) | 一种域名解析方法及装置 | |
| CN111130936B (zh) | 一种负载均衡算法的测试方法及装置 | |
| US6351769B1 (en) | Dynamic burn rack monitor listener server | |
| CN115378841B (zh) | 设备接入云平台状态的检测方法及装置、存储介质、终端 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050510 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050701 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20051108 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051108 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081118 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091118 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091118 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101118 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101118 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111118 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111118 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121118 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121118 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131118 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |