JPH08328983A - Network managing information retrieving system - Google Patents

Abstract

PURPOSE: To provide the retrieving system with which request processing to an MIB(management information bawl) table is accelerated. CONSTITUTION: At an MIB table processing part 20, an MIB table storage part 21 stores an MIB table 21a for which the instances of objects to be indexes are sorted in order like a dictionary, and an index/entry correspondent relation holding part 22 stores index/entry correspondent relation information composed of the indexes designated in a request reported from an SNMP(simple network magngement protocol) message processing part 10, the order entries used for a response to the SNMP message processing part 10 after search, and the indexes of those entries. At the time after the second request to a table containing the plural objects in the same entry, by referring to the correspondent relation information, the search of that entry can be omitted.

Description

【発明の詳細な説明】Detailed Description of the Invention

【０００１】[0001]

【産業上の利用分野】本発明はネットワーク管理情報検
索方式に関し、特にネットワーク管理プロトコルＳＮＭ
Ｐ（Simple Network Management Protocol）を用いて管
理情報ベース（ＭＩＢ：Management Information Base
）テーブルの検索処理を行うネットワーク管理情報検
索方式に関する。BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a network management information retrieval system, and more particularly to a network management protocol SNM.
Management Information Base (MIB) using P (Simple Network Management Protocol)
) It relates to a network management information search method for performing table search processing.

【０００２】[0002]

【従来の技術】ネットワーク管理のための仮想的な管理
情報であるＭＩＢは、被管理オブジェクトのツリー状の
集合体である。これらのオブジェクトは、それ自体は単
なる属性（“形”，template）の規定のみであり、実際
にネットワーク管理プロトコルによって操作される実体
は、オブジェクトの持つそれぞれのインスタンスであ
る。2. Description of the Related Art MIB, which is virtual management information for network management, is a tree-shaped collection of managed objects. These objects are merely definitions of attributes (“shapes”, templates) themselves, and the entities actually operated by the network management protocol are the respective instances of the objects.

【０００３】テーブル中のオブジェクトは、１つのオブ
ジェクトがそのテーブルのエントリ数と同じ数の複数の
インスタンスを持つ。例として、文献「K. McCloghrie,
M.Rose, Management Information Base for Network M
anagement of TCP/IP-basedinternets: MIB-II, Networ
k Working Group Request for Comments: 1213, March
1991」において、インターネット標準ＭＩＢであるＭＩ
Ｂ−ＩＩにおいて定義されているテーブルの内、「ｉｐ
ＲｏｕｔｉｎｇＴａｂｌｅ」を考える。Objects in a table have a plurality of instances, each object having the same number as the number of entries in the table. As an example, the document “K. McCloghrie,
M.Rose, Management Information Base for Network M
anagement of TCP / IP-based internets: MIB-II, Networ
k Working Group Request for Comments: 1213, March
1991 ”, MI, which is an Internet standard MIB
Of the tables defined in B-II, "ip
"RoutingTable".

【０００４】図１６はＭＩＢ−ＩＩに定義されているテ
ーブルの一例を示す図である。テーブル「ｉｐＲｏｕｔ
ｉｎｇＴａｂｌｅ」は図示のような内容を有していると
する。なお、「ｉｐＲｏｕｔｅＤｅｓｔ」、「ｉｐＲｏ
ｕｔｅＩｆＩｎｄｅｘ」および「ｉｐＲｏｕｔｅＮｅｘ
ｔＨｏｐ」以外のオブジェクトは省略してある。このと
き、たとえばオブジェクト「ｉｐＲｏｕｔｅＤｅｓｔ」
は、インスタンスとして各エントリに「１９２．３３．
４．０」、「０．０．０．０」および「１９２．３３．
５．０」の３つの値を持っている。同様に、オブジェク
ト「ｉｐＲｏｕｔｅＩｆＩｎｄｅｘ」は、インスタンス
として「１」、「１」、「２」の値を持っている。FIG. 16 is a diagram showing an example of a table defined in MIB-II. Table "ipRout
The “ingTable” has the contents shown in the figure. In addition, "ipRouteDest", "ipRo
uteIfIndex ”and“ ipRouteNex
Objects other than "tHop" are omitted. At this time, for example, the object "ipRouteDest"
For each entry as an instance of "192.33.
4.0 "," 0.0.0.0 "and" 192.33.
It has three values of "5.0". Similarly, the object “ipRouteIfIndex” has values of “1”, “1”, and “2” as instances.

【０００５】また、テーブルでは、そのテーブルの中で
インデックスとなるオブジェクトが必ず規定され、テー
ブル内を検索するときのエントリの順番は、そのテーブ
ルの中でインデックスとなるオブジェクトの辞書的順番
の大小により決定される。図示のテーブル「ｉｐＲｏｕ
ｔｉｎｇＴａｂｌｅ」では、「ｉｐＲｏｕｔｅＤｅｓ
ｔ」がインデックスとなるオブジェクトである。したが
って、このテーブルの検索の順番は「ｉｐＲｏｕｔｅＤ
ｅｓｔ」のインスタンスの辞書的順番の大小により決定
される。In addition, in a table, an object that serves as an index in the table is always defined, and the order of entries when searching the table depends on the size of the dictionary order of the objects that serve as the index in the table. It is determined. The illustrated table "ipRou
In "tingTable", "ipRouteDes"
"t" is an object that serves as an index. Therefore, the search order for this table is "ipRouteD
It is determined by the size of the lexical order of the instance of "est".

【０００６】ネットワーク管理プロトコルＳＮＭＰにお
いては、すべての管理操作はオブジェクトの個々のイン
スタンスに対してしか行うことができない。すなわち、
テーブル全体やテーブルの中のあるエントリといった単
位での管理操作は行うことができない。したがって、テ
ーブルを検索する際には、テーブル中のすべてのインス
タンスを指定して値を取得する必要がある。In the network management protocol SNMP, all management operations can only be performed on individual instances of an object. That is,
Management operations cannot be performed in units of the entire table or certain entries in the table. Therefore, when searching the table, it is necessary to specify all the instances in the table to obtain the values.

【０００７】ＳＮＭＰによるテーブル検索として一般的
に行われている方法は、「ＧｅｔＮｅｘｔ−Ｒｅｑｕｅ
ｓｔ」中において１エントリ中のオブジェクトインスタ
ンスをすべて指定して、指定したエントリの次のエント
リ中にあるオブジェクトインスタンスを取得し、これを
テーブル中の全エントリに対して検索が終了するまで繰
り返す、というものである。The method generally used as the table search by SNMP is "GetNext-Request".
In "st", all the object instances in one entry are specified, the object instance in the entry next to the specified entry is acquired, and this is repeated until the search is completed for all the entries in the table. It is a thing.

【０００８】テーブル検索の具体例として、「ｉｐＲｏ
ｕｔｉｎｇＴａｂｌｅ」の検索例が文献「THE SIMPLE B
OOK, An Introduction to Management of TCP/IP-based
Internets, Marshall T. Rose, Prentice-Hall Intern
ational Editions」の５．３．１節“Ｔｈｅ Ｐｏｗｅ
ｒｆｕｌ Ｇｅｔ−Ｎｅｘｔ Ｏｐｅｒａｔｏｒ”に挙
げられている。As a concrete example of the table search, "ipRo
"The SIMPLE B"
OOK, An Introduction to Management of TCP / IP-based
Internets, Marshall T. Rose, Prentice-Hall Intern
Section 5.3.1 of "ational editions""The Powe
rful Get-Next Operator ”.

【０００９】この例によれば、「ＧｅｔＮｅｘｔ−Ｒｅ
ｑｕｅｓｔ」によりテーブル全体のオブジェクトインス
タンスを取得する際には、リクエスト中に指定されたイ
ンスタンスの次に辞書的順番の大きいインスタンスをイ
ンデックスとして持つエントリの検索を、テーブルに含
まれているインスタンスの数と同じ回数だけ行ってい
る。According to this example, "GetNext-Re
When acquiring the object instance of the entire table by "quest", the search for the entry having the instance with the next largest lexicographical order as the index of the instance specified in the request is performed as the number of instances included in the table. Do the same number of times.

【００１０】また、被管理機器の管理情報を高速に読み
書きすることを目的とした従来技術として、特開平６−
９７９３４号公報がある。この公報によれば、目的とす
るオブジェクトを検索する処理を高速化するため、目的
とするオブジェクトをＭＩＢツリーのルートから順次た
どっていくのではなく、連想記憶装置を用いて一気に探
し出すことにより、検索に要する時間を短縮するもので
ある。Further, as a conventional technique for reading and writing management information of a managed device at high speed, Japanese Patent Laid-Open No. 6-
There is a 97934 publication. According to this publication, in order to speed up the process of searching for an object of interest, the object of interest is searched for all at once by using an associative storage device, instead of sequentially following the root of the MIB tree. It shortens the time required for.

【００１１】[0011]

【発明が解決しようとする課題】上述のように、「Ｇｅ
ｔＮｅｘｔ−Ｒｅｑｕｅｓｔ」によりテーブル全体のオ
ブジェクトインスタンスを取得する際には、リクエスト
中に指定されたインスタンスの次に辞書的順番の大きい
インスタンスをインデックスとして持つエントリの検索
が、テーブルに含まれているインスタンスの数と同じ回
数だけ行わなければならない。このため、「ＧｅｔＮｅ
ｘｔ−Ｒｅｑｕｅｓｔ」中に複数のインスタンスが指定
され、それらが同一のインデックスを持つような場合に
も、その同じエントリを探すためのサーチ処理を何度も
繰り返す必要がある。また、このようなエントリ検索の
ためには、テーブルのすべてのエントリを参照しなけれ
ばならない可能性があるため、複数オブジェクトに対し
ては、同じテーブル全体を何度も検索することになる。SUMMARY OF THE INVENTION As described above, the "Ge
When acquiring the object instance of the entire table by “tNext-Request”, the search for the entry having the instance with the next largest lexicographic order as the index of the instance specified in the request is performed for the instances included in the table. Must be done as many times as there are numbers. Therefore, "GetNe
Even when a plurality of instances are specified in “xt-Request” and they have the same index, it is necessary to repeat the search process for searching the same entry many times. Further, in order to search for such an entry, it may be necessary to refer to all the entries in the table, so that the same entire table is searched many times for a plurality of objects.

【００１２】また、上記公報に記載の技術では、高速化
の工夫が及ぶ範囲はテーブルに含まれるオブジェクトの
検索までであり、オブジェクトが持つインデックスの検
索を高速化する手段は含まれていない。したがって、テ
ーブル検索を行う場合に、エントリの検索に要する時間
は短縮されない、という問題点があった。Further, in the technique described in the above publication, the device for speeding up is limited to the search of the object contained in the table, and the means for speeding up the search of the index of the object is not included. Therefore, there is a problem that the time required to search the entry is not shortened when the table is searched.

【００１３】本発明はこのような点に鑑みてなされたも
のであり、テーブルオブジェクトに対する「ＧｅｔＮｅ
ｘｔ−Ｒｅｑｕｅｓｔ」の処理を高速化し、ひいてはテ
ーブル全体の検索処理を高速化するネットワーク管理情
報検索方式を提供することを目的とする。The present invention has been made in view of such a point, and "GetNe" for a table object is performed.
It is an object of the present invention to provide a network management information search method that speeds up the process of “xt-Request”, and thus speeds up the process of searching the entire table.

【００１４】[0014]

【課題を解決するための手段】本発明では上記課題を解
決するために、被管理機器毎に管理情報ベーステーブル
に登録されているネットワーク管理情報を検索するネッ
トワーク管理情報検索方式において、マネージャとの通
信時にネットワーク管理プロトコルのプロトコル処理を
行うメッセージ処理手段（１０）と、被管理オブジェク
トのインスタンスが登録され、インデックスとなるオブ
ジェクトのインスタンスをキーとしてエントリが辞書的
順番にソートされている管理情報ベーステーブル記憶部
（２１）、および前記メッセージ処理手段から通知され
たリクエスト中に指定されているインデックスと前記メ
ッセージ処理手段への応答に用いたエントリの順番と前
記メッセージ処理手段への応答に用いたエントリのイン
デックスとを検索毎に保持しておくインデックス・エン
トリ対応関係保持部（２２）を有する管理情報ベーステ
ーブル処理手段（２０）と、を備えていることを特徴と
するネットワーク管理情報検索方式が提供される。According to the present invention, in order to solve the above problems, in a network management information search method for searching network management information registered in a management information base table for each managed device, A message processing means (10) for performing protocol processing of a network management protocol at the time of communication and an instance of a managed object are registered, and a management information base table in which entries are sorted in a lexicographical order using the instance of the object serving as an index as a key The storage unit (21), the index specified in the request notified from the message processing unit, the order of the entries used for the response to the message processing unit, and the entry used for the response to the message processing unit. Search with index A management information base table processing means having a index entry correspondence holding unit to hold (22) (20), the network management information retrieval system, characterized in that it comprises a are provided.

【００１５】[0015]

【作用】上述の手段によれば、管理情報ベーステーブル
記憶部（２１）のテーブルオブジェクトに対する最初の
リクエストの処理の際に、管理情報ベーステーブル全体
をインデックスでソートして作成し、記憶しておく。そ
の上で、作成した管理情報ベーステーブルに対してエン
トリをサーチ後、管理情報ベーステーブル処理手段（２
０）のインデックス・エントリ対応関係保持部（２２）
に、リクエスト中のインデックスとリクエストに対する
応答に用いたエントリの順番とリクエストに対する応答
に用いたエントリのインデックスとを記憶しておく。According to the above means, when the first request for the table object in the management information base table storage unit (21) is processed, the entire management information base table is created by sorting by index and stored. . Then, after searching the created management information base table for an entry, the management information base table processing means (2
0) Index / entry correspondence holding unit (22)
The index in the request, the order of the entries used for the response to the request, and the index of the entry used for the response to the request are stored.

【００１６】次のリクエストの処理のときには、メッセ
ージ処理手段（１０）から渡されたインデックスとイン
デックス・エントリ対応関係保持部（２２）にあるリク
エスト中のインデックスとを比較し、一致した場合に
は、インデックス・エントリ対応関係保持部（２２）に
あるリクエストに対する応答に用いたエントリの順番と
リクエストに対する応答に用いたエントリのインデック
スとを使用して、その順番のエントリのオブジェクトイ
ンスタンスを取得し、再び、インデックス・エントリ対
応関係保持部（２２）を更新して応答に用いるオブジェ
クトインスタンスとその値とをメッセージ処理手段（１
０）へ通知する。At the time of processing the next request, the index passed from the message processing means (10) is compared with the index in the request stored in the index / entry correspondence holding unit (22). Using the order of the entries used for the response to the request and the index of the entry used for the response to the request in the index / entry correspondence holding unit (22), the object instance of the entry of the order is acquired, and again, The message processing means (1) updates the index / entry correspondence holding unit (22) to obtain the object instance used for the response and its value.
Notify 0).

【００１７】メッセージ処理手段（１０）から渡された
インデックスとインデックス・エントリ対応関係保持部
（２２）にあるリクエスト中のインデックスとが一致し
ない場合には、メッセージ処理手段（１０）から渡され
たインデックスとインデックス・エントリ対応関係保持
部（２２）にあるリクエストに対する応答に用いたエン
トリのインデックスとを比較し、一致した場合には、リ
クエストに対する応答に用いたエントリの順番の次のエ
ントリをサーチする。If the index passed from the message processing means (10) and the index in the request stored in the index / entry correspondence holding unit (22) do not match, the index passed from the message processing means (10). And the index of the entry used in the response to the request in the index / entry correspondence holding unit (22) are compared, and if they match, the next entry in the order of the entries used in the response to the request is searched.

【００１８】メッセージ処理手段（１０）から渡された
インデックスとインデックス・エントリ対応関係保持部
（２２）にあるリクエストに対する応答に用いたエント
リのインデックスとが一致しない場合には、これらのイ
ンデックスの辞書的順番を比較し、その大小に応じて、
インデックス・エントリ対応関係保持部（２２）にある
リクエストに対する応答に用いたエントリを、サーチ範
囲の上限または下限エントリとする。When the indexes passed from the message processing means (10) and the indexes of the entries used in the response to the request in the index / entry correspondence holding unit (22) do not match, these indexes are dictionary-like. Compare the order, and according to the size,
The entry used in the response to the request in the index / entry correspondence holding unit (22) is the upper or lower limit entry of the search range.

【００１９】これにより、同一のインデックスを持つ複
数のオブジェクトインスタンスへのリクエスト処理で
は、エントリをサーチするのは最初だけであるので、同
一エントリ中のオブジェクトの個数が多いほど、エント
リ全体のオブジェクトインスタンスを取得するのに要す
る時間を短縮することができる。As a result, in the request processing for a plurality of object instances having the same index, the entry is searched only at the beginning, so that the larger the number of objects in the same entry, the more the object instances of the entire entry are searched. The time required to acquire can be shortened.

【００２０】また、管理情報ベーステーブル記憶部（２
１）の管理情報ベーステーブルはインデックスとなるオ
ブジェクトのインスタンスをキーとしてエントリがソー
トされて記憶されているので、リクエスト中で指定され
たインデックスがインデックス・エントリ対応関係保持
部（２２）に記憶されているエントリのインデックスと
同じである場合には、目的のエントリは記憶されている
エントリの次のエントリであることをサーチすることな
く判断することができる。The management information base table storage unit (2
In the management information base table of 1), the entries are sorted and stored using the instance of the object to be the index as a key, so the index specified in the request is stored in the index / entry correspondence holding unit (22). If it is the same as the index of the existing entry, it can be determined without searching that the target entry is the next entry of the stored entry.

【００２１】さらに、管理情報ベーステーブルはソート
して記憶されているので、リクエスト中で指定されたイ
ンデックスがインデックス・エントリ対応関係保持部
（２２）に記憶されているリクエスト中のインデックス
や記憶されているエントリのインデックスのいずれにも
一致しない場合には、エントリを決めるためのサーチ範
囲をテーブル全体の内、リクエスト中で指定されたイン
デックスまたは記憶されているエントリのインデックス
より辞書的順番が大きいまたは小さい方向のみとするこ
とができ、サーチ効率を上げることができる。Further, since the management information base table is sorted and stored, the index specified in the request is stored in the index / entry correspondence holding unit (22) or stored in the request. If it does not match any of the index of the existing entry, the search range for determining the entry is in a dictionary order higher or lower than the index specified in the request or the index of the stored entry in the entire table. Only the direction can be used, and the search efficiency can be improved.

【００２２】[0022]

【実施例】以下、本発明の一実施例を図面に基づいて説
明する。図１は本発明のネットワーク管理情報検索方式
の構成例を示す図である。An embodiment of the present invention will be described below with reference to the drawings. FIG. 1 is a diagram showing a configuration example of a network management information search method of the present invention.

【００２３】図に例示したネットワーク管理情報検索方
式は、図示しない管理システムのマネージャとの間でＳ
ＮＭＰのプロトコル処理を行うＳＮＭＰメッセージ処理
部１０と、ネットワーク管理情報を処理するＭＩＢテー
ブル処理部２０とから構成され、ＭＩＢテーブル処理部
２０はＭＩＢテーブル２１ａを記憶するＭＩＢテーブル
記憶部２１と、リクエスト中のインデックスを保持する
領域２２ａ、「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」に用いたエ
ントリの順番を保持する領域２２ｂ、および「Ｇｅｔ−
Ｒｅｓｐｏｎｓｅ」に用いたエントリのインデックスを
保持する領域２２ｃを有するインデックス・エントリ対
応関係保持部２２とを備えている。また、ＭＩＢテーブ
ル処理部２０には、リソース情報記憶部３０のリソース
情報を元にオブジェクトインスタンスからなるＭＩＢテ
ーブル２１ａを作成し、このときエントリをインデック
スによりソートする機能を持ったＭＩＢテーブル作成部
４０が接続されている。さらに、ＭＩＢテーブル処理部
２０には、リソース情報記憶部３０のリソース情報に変
化が発生したかどうかを監視して変化が発生した場合に
は、ＭＩＢテーブル記憶部２１およびインデックス・エ
ントリ対応関係保持部２２の内容をクリアするリソース
状態監視部５０が接続されている。The network management information retrieval method illustrated in the figure is executed by the S of the management system manager (not shown).
It is composed of an SNMP message processing unit 10 for performing NMP protocol processing and an MIB table processing unit 20 for processing network management information. The MIB table processing unit 20 has a MIB table storage unit 21 for storing an MIB table 21a and a requesting request. Area 22a for holding the index of “Get-Response”, area 22b for holding the order of the entries used for “Get-Response”, and “Get-Response”.
An index / entry correspondence holding unit 22 having an area 22c for holding the index of the entry used for "Response". Further, in the MIB table processing unit 20, a MIB table creating unit 40 having a function of creating an MIB table 21a composed of object instances based on the resource information of the resource information storage unit 30 and sorting the entries by an index at this time is provided. It is connected. Further, the MIB table processing unit 20 monitors whether or not a change has occurred in the resource information of the resource information storage unit 30 and, if a change occurs, the MIB table storage unit 21 and the index / entry correspondence holding unit. A resource status monitoring unit 50 that clears the contents of 22 is connected.

【００２４】ＳＮＭＰメッセージ処理部１０は、メッセ
ージの送受信、エンコード／デコード、リクエストメッ
セージの解析、レスポンスメッセージの構築、ＭＩＢツ
リー上でのオブジェクトの検索、オブジェクト間の辞書
的順番の大小関係の検索などの処理を行っている。The SNMP message processing unit 10 performs message transmission / reception, encoding / decoding, request message analysis, response message construction, object search on the MIB tree, search of lexicographical order relation between objects, and the like. It is processing.

【００２５】リソース情報記憶部３０のリソース情報
は、被管理機器が持っている状態や構成といった情報で
ある。ＭＩＢは仮想情報であるため、そのインスタンス
の値を決定する際には、必ず被管理機器が持っている情
報との対応を取らなければならない。つまり、リソース
情報は、被管理機器が持っているＭＩＢの元情報のこと
であり、図示のリソーステーブル３０ａのように、ＭＩ
Ｂテーブル２１ａの元になるテーブル形式のデータも含
まれる。The resource information in the resource information storage section 30 is information such as the status and configuration of the managed device. Since the MIB is virtual information, when determining the value of the instance, it is necessary to take a correspondence with the information held by the managed device. That is, the resource information is the original information of the MIB held by the managed device, and is the MI as shown in the resource table 30a in the figure.
The data in the table format that is the basis of the B table 21a is also included.

【００２６】リソース状態監視部５０では、リソース情
報記憶部３０のリソース情報の状態変化を監視する方法
として常時監視またはポーリングによる監視の方法があ
る。また、リソース情報記憶部３０に状態変化をイベン
トとして通知する機能があれば、そのイベントを用いた
イベントドリブンによる状態変化の監視方法もある。こ
こでは、リソース情報の変化を判断することができれ
ば、いずれの方法でもよい。In the resource status monitoring unit 50, there are a continuous monitoring method or a polling monitoring method as a method for monitoring the status change of the resource information in the resource information storage unit 30. Further, if the resource information storage unit 30 has a function of notifying a state change as an event, there is also an event driven method of monitoring the state change using the event. Here, any method may be used as long as the change in resource information can be determined.

【００２７】ＭＩＢテーブル処理部２０のＭＩＢテーブ
ル記憶部２１はＭＩＢテーブル作成部４０にて作成され
たＭＩＢテーブル２１ａを記憶するが、このＭＩＢテー
ブル２１ａには、最後に処理した「ＧｅｔＮｅｘｔ−Ｒ
ｅｑｕｅｓｔ」に対する「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」
で使用されたオブジェクトインスタンスを含むテーブル
がインデックスによりソートされた形で記憶されてい
る。The MIB table storage unit 21 of the MIB table processing unit 20 stores the MIB table 21a created by the MIB table creating unit 40. This MIB table 21a contains the last processed "GetNext-R".
"Get-Response" for "request"
The table containing the object instances used in is stored sorted by index.

【００２８】インデックス・エントリ対応関係保持部２
２は、領域２２ａに最も新しく処理した「ＧｅｔＮｅｘ
ｔ−Ｒｅｑｕｅｓｔ」に指定されていたオブジェクトイ
ンスタンスの中のインデックスの値を、領域２２ｂには
その「ＧｅｔＮｅｘｔ−Ｒｅｑｕｅｓｔ」に対する「Ｇ
ｅｔ−Ｒｅｓｐｏｎｓｅ」中に用いたテーブルのエント
リの位置を、さらに領域２２ｃにはそのエントリのイン
デックスの値の対応関係をそれぞれ記憶している。した
がって、ここに記憶される対応関係は、ＭＩＢテーブル
記憶部２１に記憶されているＭＩＢテーブル２１ａに対
するものとなる。Index / entry correspondence holding unit 2
2 is the latest processed "GetNex" in the area 22a.
The value of the index in the object instance specified in "t-Request" is displayed in the area 22b as "G" for the "GetNext-Request".
The position of the entry of the table used in "et-Response" is stored, and the area 22c stores the correspondence between the index values of the entry. Therefore, the correspondence relationship stored here is for the MIB table 21 a stored in the MIB table storage unit 21.

【００２９】次に、上記構成のネットワーク管理情報検
索方式の作用について説明する。図２はＭＩＢテーブル
処理部の処理の流れを示すフローチャート（その１）で
あり、図３はＭＩＢテーブル処理部の処理の流れを示す
フローチャート（その２）であり、図４はＭＩＢテーブ
ル処理部の処理の流れを示すフローチャート（その３）
であり、図５はＭＩＢテーブル処理部の処理の流れを示
すフローチャート（その４）である。Next, the operation of the network management information retrieval system having the above configuration will be described. 2 is a flow chart (No. 1) showing the flow of processing of the MIB table processing unit, FIG. 3 is a flow chart (No. 2) showing the flow of processing of the MIB table processing unit, and FIG. 4 is that of the MIB table processing unit. Flowchart showing the flow of processing (Part 3)
5 is a flowchart (No. 4) showing the flow of processing of the MIB table processing unit.

【００３０】まず、ＳＮＭＰメッセージ処理部１０にお
いて、マネージャより受信したＳＮＭＰメッセージがテ
ーブルに対する「ＧｅｔＮｅｘｔ−Ｒｅｑｕｅｓｔ」で
あると認識されると、ＭＩＢテーブル処理部２０の処理
が開始される。First, when the SNMP message processing unit 10 recognizes that the SNMP message received from the manager is "GetNext-Request" for the table, the processing of the MIB table processing unit 20 is started.

【００３１】ＭＩＢテーブル処理部２０は、まず、ＳＮ
ＭＰメッセージ処理部１０より通知されたテーブルはＭ
ＩＢテーブル記憶部２１に存在するかどうかを判定する
（ステップＳ１）。ＭＩＢテーブル記憶部２１にテーブ
ルが存在すれば、そのテーブルはＳＮＭＰメッセージ処
理部１０より通知されたテーブルと同一かどうかが判断
される（ステップＳ２）。The MIB table processing section 20 firstly detects the SN.
The table notified by the MP message processing unit 10 is M
It is determined whether or not it exists in the IB table storage unit 21 (step S1). If the MIB table storage unit 21 has a table, it is determined whether the table is the same as the table notified by the SNMP message processing unit 10 (step S2).

【００３２】ここで、同一と判断されると、次に、イン
デックス・エントリ対応関係保持部２２に対応関係デー
タがあるかどうかが判定され（ステップＳ１１）、対応
関係データがあると、ＳＮＭＰメッセージ処理部１０か
ら渡されたインデックスとインデックス・エントリ対応
関係保持部２２の領域２２ａにあるリクエスト中のイン
デックスとが比較され（ステップＳ１２）、対応関係デ
ータがなければ、ＭＩＢテーブル２１ａ全体をサーチ範
囲とする（ステップＳ１３）。If it is judged that they are the same, it is then judged whether or not there is correspondence data in the index / entry correspondence holding unit 22 (step S11). If there is correspondence data, the SNMP message processing is performed. The index passed from the unit 10 is compared with the index in the request in the area 22a of the index / entry correspondence holding unit 22 (step S12). If there is no correspondence data, the entire MIB table 21a is set as the search range. (Step S13).

【００３３】ステップＳ１２において、比較の結果、両
インデックスが一致した場合には（ステップＳ１４）、
目的のエントリは「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」に用い
たエントリの順番が記憶されているインデックス・エン
トリ対応関係保持部２２の領域２２ｂの値のエントリと
し、インデックスは領域２２ｃの「Ｇｅｔ−Ｒｅｓｐｏ
ｎｓｅ」に用いたエントリのインデックスとする（ステ
ップＳ１５）。In step S12, if both indexes match as a result of the comparison (step S14),
The target entry is the entry of the value of the area 22b of the index / entry correspondence holding unit 22 in which the order of the entries used for "Get-Response" is stored, and the index is the "Get-Response" of the area 22c.
nse ”is used as the index of the entry used (step S15).

【００３４】また、両インデックスが一致しない場合に
は、インデックス・エントリ対応関係保持部２２にある
領域２２ｃの「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」に用いたエ
ントリのインデックスとＳＮＭＰメッセージ処理部１０
から渡されたインデックスとを比較する（ステップＳ１
６）。ここで、一致した場合には（ステップＳ１７）、
インデックス・エントリ対応関係保持部２２にある領域
２２ｂの「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」に用いたエント
リの順番の次のエントリがあるかどうかを判断する（ス
テップＳ１８）。If the two indexes do not match, the index of the entry used for "Get-Response" in the area 22c in the index / entry correspondence holding section 22 and the SNMP message processing section 10
It is compared with the index passed from (step S1
6). If they match (step S17),
It is determined whether or not there is the next entry in the order of the entries used for "Get-Response" in the area 22b in the index / entry correspondence holding unit 22 (step S18).

【００３５】ステップＳ１７で一致しなかった場合に
は、インデックス・エントリ対応関係保持部２２にある
領域２２ｃの「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」に用いたエ
ントリのインデックスと、ＳＮＭＰメッセージ処理部１
０から渡されたインデックスとの辞書的順番を比較する
（ステップＳ１９）。ここで、「Ｇｅｔ−Ｒｅｓｐｏｎ
ｓｅ」に用いたエントリのインデックスの方がＳＮＭＰ
メッセージ処理部１０から渡されたインデックスより辞
書的順番が大きい場合には（ステップＳ２０）、サーチ
範囲の下限エントリをインデックス・エントリ対応関係
保持部２２にある領域２２ｂの「Ｇｅｔ−Ｒｅｓｐｏｎ
ｓｅ」に用いたエントリの順番のエントリとし（ステッ
プＳ２１）、「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」に用いたエ
ントリのインデックスの方がＳＮＭＰメッセージ処理部
１０から渡されたインデックスより辞書的順番が小さい
場合には、サーチ範囲の上限エントリをインデックス・
エントリ対応関係保持部２２にある領域２２ｂの「Ｇｅ
ｔ−Ｒｅｓｐｏｎｓｅ」に用いたエントリの順番のエン
トリとする（ステップＳ２２）。そして、サーチ範囲で
のエントリをサーチする（ステップＳ２３）。If they do not match in step S17, the index of the entry used for "Get-Response" in the area 22c in the index / entry correspondence holding unit 22 and the SNMP message processing unit 1
The dictionary order with the index passed from 0 is compared (step S19). Here, "Get-Response
The index of the entry used for “se” is SNMP
If the lexicographical order is larger than the index passed from the message processing unit 10 (step S20), the lower limit entry of the search range is set to “Get-Response” in the region 22b in the index / entry correspondence holding unit 22.
If the index of the entry used for “Get-Response” has a smaller lexical order than the index passed from the SNMP message processing unit 10, Index the highest entry in the search range
In the area 22b in the entry correspondence holding unit 22, "Ge
The entries are in the order of the entries used for “t-Response” (step S22). Then, the entry within the search range is searched (step S23).

【００３６】ここで、ステップＳ１およびステップＳ２
において、ＭＩＢテーブルが存在しなかったり、ＭＩＢ
テーブルが同一でなかった場合には、ＭＩＢテーブル作
成部４０にてインデックスとなるオブジェクトインスタ
ンスをキーとしてエントリが辞書的順番でソートされた
ＭＩＢテーブルを作成し（ステップＳ３１）、ＭＩＢテ
ーブル記憶部２１に作成されたＭＩＢテーブルを記憶す
る（ステップＳ３２）。次に、ＳＮＭＰメッセージ処理
部１０より通知されたインデックスの次に辞書的順番の
大きいエントリをサーチする（ステップＳ３３）。Here, step S1 and step S2
In the, the MIB table does not exist,
If the tables are not the same, the MIB table creation unit 40 creates a MIB table in which the entries are sorted in a lexicographical order using the object instance serving as an index as a key (step S31), and the MIB table storage unit 21 is created. The created MIB table is stored (step S32). Next, the entry having the next largest lexicographical order after the index notified by the SNMP message processing unit 10 is searched (step S33).

【００３７】ステップＳ１８、ステップＳ２３およびス
テップＳ３３の処理の次は、辞書的順番の大きいエント
リは存在したかどうかが判断される（ステップＳ４
１）。ここで、辞書的順番の大きいエントリが存在した
場合と、ステップＳ１５の処理の後は、インデックス・
エントリ対応関係保持部２２に、ＳＮＭＰメッセージ処
理部１０より通知されたインデックスの値と、サーチ結
果のエントリの順番と、そのエントリのインデックスの
値との対応関係を記憶し（ステップＳ４２）、「Ｇｅｔ
−Ｒｅｓｐｏｎｓｅ」に用いるオブジェクトインスタン
スの名前およびその値をＳＮＭＰメッセージ処理部１０
に通知する（ステップＳ４３）。一方、ステップＳ４１
の判断において、辞書的順番の大きいエントリが存在し
ない場合には、「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」に用いる
オブジェクトインスタンスは存在しない旨をＳＮＭＰメ
ッセージ処理部１０に通知する（ステップＳ４４）。After the processing of steps S18, S23 and S33, it is determined whether or not there is an entry having a large lexicographical order (step S4).
1). Here, if there is an entry having a large lexicographical order, and if there is an index
The entry correspondence holding unit 22 stores the correspondence between the index value notified by the SNMP message processing unit 10, the order of the search result entries, and the index value of the entry (step S42).
-The name of the object instance used for "Response" and the value thereof
(Step S43). On the other hand, step S41
If there is no entry having a large lexicographical order in the determination of No., the SNMP message processing unit 10 is notified that there is no object instance used for “Get-Response” (step S44).

【００３８】図６はリソース状態監視部の処理の流れを
示すフローチャートである。リソース状態監視部５０は
リソース情報記憶部３０のリソース情報の状態変化を監
視しており、そのため、まず、ＭＩＢテーブル記憶部２
１に記憶されているＭＩＢテーブル２１ａに対応したリ
ソース情報を取得する（ステップＳ５１）。リソース情
報に変化があると判断されると（ステップＳ５２）、Ｍ
ＩＢテーブル記憶部２１に記憶されているＭＩＢテーブ
ル２１ａを抹消し（ステップＳ５３）、インデックス・
エントリ対応関係保持部２２に記憶されている対応関係
を抹消する（ステップＳ５４）。FIG. 6 is a flow chart showing the flow of processing of the resource status monitoring unit. The resource status monitoring unit 50 monitors the status change of the resource information in the resource information storage unit 30. Therefore, first, the MIB table storage unit 2
The resource information corresponding to the MIB table 21a stored in No. 1 is acquired (step S51). If it is determined that the resource information has changed (step S52), M
The MIB table 21a stored in the IB table storage unit 21 is deleted (step S53), and the index
The correspondence relationship stored in the entry correspondence relationship holding unit 22 is deleted (step S54).

【００３９】ここで、ＭＩＢ−ＩＩで定義されているテ
ーブル「ｉｐＡｄｄｒＴａｂｌｅ」の検索処理の具体的
な例を示す。なお、ＭＩＢテーブル記憶部２１およびイ
ンデックス・エントリ対応関係保持部２２の記憶内容
は、リソース状態監視部５０により、リソース情報の状
態が変化した際に抹消されているとする。Here, a specific example of the search processing of the table "ipAddrTable" defined in MIB-II will be shown. It is assumed that the storage contents of the MIB table storage unit 21 and the index / entry correspondence holding unit 22 are deleted by the resource status monitoring unit 50 when the status of the resource information changes.

【００４０】ＳＮＭＰによりテーブルの検索を行う際、
マネージャは最初、インスタンスを指定せず、オブジェ
クト名のみを指定した「ＧｅｔＮｅｘｔ−Ｒｅｑｕｅｓ
ｔ」を発行する。ここで、ＳＮＭＰメッセージ処理部１
０は、最初のテーブルに対する「ＧｅｔＮｅｘｔ−Ｒｅ
ｑｕｅｓｔ」として、以下のようなリクエストを受けた
ものとする。When searching a table by SNMP,
Initially, the manager does not specify the instance, but only the object name, "GetNext-Requests".
t "is issued. Here, the SNMP message processing unit 1
0 means "GetNext-Re" for the first table.
It is assumed that the following request is received as "quest".

【００４１】 ＳＮＭＰメッセージ処理部１０では、「ＧｅｔＮｅｘｔ
−Ｒｅｑｕｅｓｔ」に指定されているオブジェクトイン
スタンスを順番に処理する。まず、最初の「ｉｐＡｄＥ
ｎｔＡｄｄｒ」についての処理を開始し、受信したメッ
セージが「ｉｐＡｄｄｒＴａｂｌｅ」に対する「Ｇｅｔ
Ｎｅｘｔ−Ｒｅｑｕｅｓｔ」であると認識されると、Ｍ
ＩＢテーブル処理部２０が起動される。この際、ＳＮＭ
Ｐメッセージ処理部１０はＭＩＢテーブル処理部２０に
対して、以下のようなデータを渡す。[0041] In the SNMP message processing unit 10, “GetNext” is displayed.
-Process the object instances specified in "Request" in order. First, the first "ipAdE
ntAddr ”is started and the received message is“ GetAdd ”to“ ipAddrTable ”.
Next-Request "is recognized, M
The IB table processing unit 20 is activated. At this time, SNM
The P message processing unit 10 passes the following data to the MIB table processing unit 20.

【００４２】図７はＳＮＭＰメッセージ処理部からＭＩ
Ｂテーブル処理部へ渡されるデータ例を示す図である。
図示のデータ６１の例によれば、テーブル名は「ｉｐＡ
ｄｄｒＴａｂｌｅ」、リクエスト中に指定されていたイ
ンデックスは、オブジェクト名しか指定されていないの
で、「なし」となっている。FIG. 7 shows MI from the SNMP message processing unit.
It is a figure which shows the example of data passed to a B table processing part.
According to the example of the illustrated data 61, the table name is “ipA
"ddrTable", the index specified in the request is "none" because only the object name is specified.

【００４３】ＭＩＢテーブル処理部２０は、ＭＩＢテー
ブル記憶部２１にテーブル「ｉｐＡｄＥｎｔＡｄｄｒ」
が存在するかどうかの判断を行う（図２中のＳ１）。今
は、起動されて最初のテーブルに対する「ＧｅｔＮｅｘ
ｔ−Ｒｅｑｕｅｓｔ」の処理中であるので、ＭＩＢテー
ブル記憶部２１にはデータは存在しない。したがって、
ＭＩＢテーブル作成部４０によりＭＩＢテーブルを作成
することになる。ＭＩＢテーブル作成部４０では、リソ
ース情報記憶部３０からリソース情報を取得してＭＩＢ
のオブジェクトインスタンスからなるテーブルを作成
し、さらにインデックスによる辞書的順番にソートが行
われる（図４中のＳ３１）。ここで、リソース情報の取
得方法には、たとえばＵＮＩＸマシンであれば、ＵＮＩ
Ｘのシステムコールなどを使用する。この結果、次のよ
うな内容のＭＩＢテーブルが作成されたとする。The MIB table processing unit 20 stores the table “ipAdEntAddr” in the MIB table storage unit 21.
Is determined (S1 in FIG. 2). Now for the first table that has been launched, "GetNex
Since the “t-Request” is being processed, no data exists in the MIB table storage unit 21. Therefore,
The MIB table is created by the MIB table creating unit 40. The MIB table creation unit 40 acquires the resource information from the resource information storage unit 30 to obtain the MIB.
A table including the object instances of is created, and sorting is further performed in the dictionary order by the index (S31 in FIG. 4). Here, as a method of acquiring resource information, for example, if it is a UNIX machine, UNI
X system call is used. As a result, assume that the MIB table having the following contents is created.

【００４４】図８は作成されたＭＩＢテーブルの内容例
を示す図である。図示の内容例によれば、テーブル６２
の「ｉｐＡｄｄｒＴａｂｌｅ」では、インデックスとな
るオブジェクトは「ｉｐＡｄＥｎｔＡｄｄｒ」である。
したがって、このテーブル６２は、「ｉｐＡｄＥｎｔＡ
ｄｄｒ」のオブジェクトインスタンスの辞書的順番の大
小によってソートされていることになる。FIG. 8 is a diagram showing an example of the contents of the created MIB table. According to the illustrated content example, the table 62
In “ipAddrTable”, the object serving as an index is “ipAdEntAddr”.
Therefore, this table 62 shows “ipAdEntA
They are sorted according to the size of the lexicographical order of the object instances of "ddr".

【００４５】次に、作成されたテーブル６２はＭＩＢテ
ーブル記憶部２１にＭＩＢテーブル２１ａとして記憶す
る（図４中のＳ３２）。そして、図７に示されたインデ
ックスの次に辞書的順番の大きいインデックスを持った
エントリをサーチする（図４中のＳ３３）。サーチの方
法としては、たとえば二分検索法などがある。なお、図
７のデータ６１では、インデックスの指定がないので、
サーチ結果のエントリは図８のテーブル６２中で辞書的
順番が最少のインデックスを持つエントリ、すなわち、
１番目のエントリとなる。Next, the created table 62 is stored in the MIB table storage section 21 as the MIB table 21a (S32 in FIG. 4). Then, the entry having the index having the next largest lexicographic order after the index shown in FIG. 7 is searched (S33 in FIG. 4). As a search method, there is a binary search method, for example. In the data 61 of FIG. 7, since no index is specified,
The entry of the search result is the entry having the index with the smallest lexicographical order in the table 62 of FIG.
This is the first entry.

【００４６】サーチが終了し、エントリが見つかると、
インデックス・エントリ対応関係保持部２２の領域２２
ａには、ＳＮＭＰメッセージ処理部１０より通知された
インデックスの値が記憶され、領域２２ｂには、サーチ
結果のエントリの順番が記憶され、領域２２ｃには、そ
のエントリのインデックスの値が記憶されて、インデッ
クス・エントリの対応関係が記憶される（図５中のＳ４
２）。When the search is completed and an entry is found,
Area 22 of index / entry correspondence holding unit 22
The value of the index notified from the SNMP message processing unit 10 is stored in a, the order of the entry of the search result is stored in the area 22b, and the index value of the entry is stored in the area 22c. , The correspondence between index entries is stored (S4 in FIG. 5).
2).

【００４７】図９はインデックス・エントリ対応関係保
持部の内容例を示す図である。図示の例によれば、イン
デックス・エントリ対応関係保持部２２のデータ６３
は、図８のテーブル６２に対して図７のデータ６１がＳ
ＮＭＰメッセージ処理部１０より通知された際には、領
域２２ａに相当するリクエスト中のインデックスとし
て、「なし」が記憶され、領域２２ｂに相当する「Ｇｅ
ｔ−Ｒｅｓｐｏｎｓｅ」に用いたエントリの順番とし
て、「１」が記憶され、領域２２ｃに相当する「Ｇｅｔ
−Ｒｅｓｐｏｎｓｅ」に用いたエントリのインデックス
として、「１２９．２４９．１．１」が記憶されてい
る。FIG. 9 is a diagram showing an example of the contents of the index / entry correspondence holding unit. According to the illustrated example, the data 63 of the index / entry correspondence holding unit 22
Of the data 61 of FIG. 7 to the table 62 of FIG.
When notified by the NMP message processing unit 10, "none" is stored as the index in the request corresponding to the area 22a, and "Ge" corresponding to the area 22b is stored.
"1" is stored as the order of the entries used for "t-Response", and "Get" corresponding to the area 22c is stored.
“129.249.1.1” is stored as the index of the entry used for “Response”.

【００４８】このような手順で、「ｉｐＡｄＥｎｔＡｄ
ｄｒ」に対応した、「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」に用
いるオブジェクトインスタンス「ｉｐＡｄＥｎｔＡｄｄ
ｒ．１２９．２４９．１．１」とその値「１２９．２４
９．１．１」とが、ＳＮＭＰメッセージ処理部１０へと
渡される（図５中のＳ４３）。In this way, "ipAdEntAd
object instance “ipAdEntAdd” used for “Get-Response” corresponding to “dr”
r. 129.249.1.1 ”and its value“ 129.24
9.1.1 ”is passed to the SNMP message processing unit 10 (S43 in FIG. 5).

【００４９】「ｉｐＡｄＥｎｔＡｄｄｒ」の処理が終了
すると、ＳＮＭＰメッセージ処理部１０では、「ｉｐＡ
ｄＥｎｔＩｆＩｎｄｅｘ」に対する処理を開始する。こ
のときも、ＳＮＭＰメッセージ処理部１０からＭＩＢテ
ーブル処理部２０へ図７に示したデータ６１と同じ内容
のデータが渡される。When the processing of "ipAdEntAddr" is completed, the SNMP message processing unit 10 sets "ipA
The process for “dEntIfIndex” is started. Also at this time, the data having the same content as the data 61 shown in FIG. 7 is passed from the SNMP message processing unit 10 to the MIB table processing unit 20.

【００５０】今度は、ＭＩＢテーブル記憶部２１には図
８に示したテーブル６２の内容が記憶され、インデック
ス・エントリ対応関係保持部２２には図９に示したデー
タ６３が記憶されている。したがって、ＳＮＭＰメッセ
ージ処理部１０より通知されたテーブルがＭＩＢテーブ
ル記憶部２１に存在することになる（図２中のＳ１、Ｓ
２がともに肯定）。ＳＮＭＰメッセージ処理部１０から
渡されたインデックスとインデックス・エントリ対応関
係保持部２２にあるリクエスト中のインデックスとはと
もに「なし」で一致するため、インデックス・エントリ
対応関係保持部２２にある「Ｇｅｔ−Ｒｅｓｐｏｎｓ
ｅ」に用いたエントリの順番「１」と「Ｇｅｔ−Ｒｅｓ
ｐｏｎｓｅ」に用いたエントリのインデックス「１２
９．２４９．１．１」とを使用し（図３中のＳ１１、Ｓ
１２、Ｓ１４、Ｓ１５）、ＳＮＭＰメッセージ処理部１
０へ渡されるオブジェクトインスタンスおよびその値
は、それぞれ「ｉｐＡｄＥｎｔＩｆＩｎｄｅｘ．１２
９．２４９．１．１」および「３」となる。This time, the contents of the table 62 shown in FIG. 8 are stored in the MIB table storage unit 21, and the data 63 shown in FIG. 9 is stored in the index / entry correspondence holding unit 22. Therefore, the table notified by the SNMP message processing unit 10 exists in the MIB table storage unit 21 (S1, S in FIG. 2).
2 is both positive). Since both the index passed from the SNMP message processing unit 10 and the index in the request stored in the index / entry correspondence holding unit 22 match with “none”, “Get-Responses” in the index / entry correspondence holding unit 22 is matched.
The order of the entries used for “e” is “1” and “Get-Res
The index of the entry used for "response""12
9.249.1.1 ”(S11, S in FIG. 3
12, S14, S15), the SNMP message processing unit 1
The object instance passed to 0 and its value are "ipAdEntIfIndex.12".
9.249.1.1 ”and“ 3 ”.

【００５１】「ｉｐＡｄＥｎｔＩｆＩｎｄｅｘ」に対す
る処理と同様の処理を、「ＧｅｔＮｅｘｔ−Ｒｅｑｕｅ
ｓｔ」に指定された他のオブジェクトについても繰り返
すと、上記リクエスト（１）に対する「Ｇｅｔ−Ｒｅｓ
ｐｏｎｓｅ」の内容は以下のようになる。A process similar to the process for "ipAdEntIfIndex" is performed by "GetNext-Request".
Repeating for other objects designated as “st”, “Get-Res” for the above request (1)
The contents of "ponse" are as follows.

【００５２】 ipAdEntAddr.129.249.1.1=129.249.1.1, ipAdEntIfIndex.129.249.1.1=3, ipAdEntNetMask.129.249.1.1=255.255.255.0, ipAdEntBcastAddr.129.249.1.1=129.249.1.0, ipAdEntReasmMaxSize.129.249.1.1=1500 …（２） このように、「ＧｅｔＮｅｘｔ−Ｒｅｑｕｅｓｔ」に指
定されたオブジェクトの数は５つであり、これらのエン
トリのサーチはそれぞれ５回必要なところが１回で済ん
でいる。したがって、４回のサーチの時間分、処理に要
する時間を短縮することができる。IpAdEntAddr.129.249.1.1 = 129.249.1.1, 129.249.1.1 = 3, ipAdEntNetMask.129.249.1.1 = 255.255.255.0, ipAdEntBcastAddr.129.249.1.1 = 129.249.1.0, ipAdEntReasmMaxSize.129.249.1.1 = 1500… ( 2) As described above, the number of objects specified in “GetNext-Request” is five, and each of these entries needs to be searched five times, but only once. Therefore, the time required for processing can be shortened by the time required for four searches.

【００５３】上記（２）の内容の「Ｇｅｔ−Ｒｅｓｐｏ
ｎｓｅ」を受けて、次に予想される「ＧｅｔＮｅｘｔ−
Ｒｅｑｕｅｓｔ」の内容は以下のようになる。 get-next ( ipAdEntAddr.129.249.1.1, ipAdEntIfIndex.129.249.1.1, ipAdEntNetMask.129.249.1.1, ipAdEntBcastAddr.129.249.1.1, ipAdEntReasmMaxSize.129.249.1.1 ) …（３） 前記（１）の「ＧｅｔＮｅｘｔ−Ｒｅｑｕｅｓｔ」を受
けたときと同様に、ＳＮＭＰメッセージ処理部１０は、
「ｉｐＡｄＥｎｔＡｄｄｒ」から順に処理を行う。オブ
ジェクトインスタンス「ｉｐＡｄＥｎｔＡｄｄｒ．１２
９．２４９．１．１」に対して、ＳＮＭＰメッセージ処
理部１０からＭＩＢテーブル処理部２０へ渡されるデー
タは以下のようになる。[Get-Respo] of the contents of the above (2)
"GetNext-" expected next time
The contents of "Request" are as follows. get-next (ipAdEntAddr.129.249.1.1, ipAdEntIfIndex.129.249.1.1, ipAdEntNetMask.129.249.1.1, ipAdEntBcastAddr.129.249.1.1, ipAdEntReasmMaxSize.129.249.1.1) (3) Receives "GetNext-Request" in (1) above. The SNMP message processing unit 10
Processing is performed in order from "ipAdEntAddr". The object instance “ipAdEntAddr.12
9.249.1.1 ”, the data passed from the SNMP message processing unit 10 to the MIB table processing unit 20 is as follows.

【００５４】図１０はＳＮＭＰメッセージ処理部からＭ
ＩＢテーブル処理部へ渡されるデータ例を示す図であ
る。図示のデータ６４の例によれば、テーブル名は「ｉ
ｐＡｄｄｒＴａｂｌｅ」、リクエスト中に指定されてい
たインデックスは「１２９．２４９．１．１」となって
いる。FIG. 10 shows M from the SNMP message processing unit.
It is a figure which shows the example of data passed to an IB table processing part. According to the example of the illustrated data 64, the table name is “i
pAddrTable ”, and the index specified in the request is“ 129.249.1.1 ”.

【００５５】このデータ６４を受けたＭＩＢテーブル処
理部２０では、渡されたテーブルがＭＩＢテーブル記憶
部２１にあるものと同一なので、インデックス・エント
リ対応関係保持部２２の対応関係を参照する。インデッ
クス・エントリ対応関係保持部２２の内容は、図９のと
おりなので、ＳＮＭＰメッセージ処理部１０から渡され
たインデックス「１２９．２４９．１．１」と、インデ
ックス・エントリ対応関係保持部２２にあるリクエスト
中のインデックス「なし」は一致しない（図３中のＳ１
４が否定）。これを受けて、次に、「Ｇｅｔ−Ｒｅｓｐ
ｏｎｓｅ」に用いたエントリのインデックス「１２９．
２４９．１．１」と、ＳＮＭＰメッセージ処理部１０か
ら渡されたインデックス「１２９．２４９．１．１」と
を比較する。ここでは、これらインデックスは一致する
ので、「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」に用いるエントリ
の順番は、インデックス・エントリ対応関係保持部２２
にある「１」の次、すなわち、「２」となる。ここで、
２番目のエントリが存在するかどうかをＭＩＢテーブル
記憶部２１にあるＭＩＢテーブル２１ａを参照して判断
する（図３中のＳ１７、Ｓ１８）。In the MIB table processing unit 20 that has received this data 64, the passed table is the same as that in the MIB table storage unit 21, so the correspondence relation of the index / entry correspondence relation holding unit 22 is referred to. Since the content of the index / entry correspondence holding unit 22 is as shown in FIG. 9, the index “129.249.1.1” passed from the SNMP message processing unit 10 and the request in the index / entry correspondence holding unit 22 are stored. The index "none" in the table does not match (S1 in FIG. 3).
4 is denied). In response to this, next, "Get-Resp
index of the entry used for “onse” is “129.
249.1.1 ”is compared with the index“ 129.249.1.1 ”passed from the SNMP message processing unit 10. Here, since these indexes match, the order of the entries used for “Get-Response” is the index / entry correspondence holding unit 22.
It becomes the next of "1" in "2", that is, "2". here,
It is determined whether or not the second entry exists by referring to the MIB table 21a in the MIB table storage unit 21 (S17 and S18 in FIG. 3).

【００５６】今、ＭＩＢテーブル記憶部２１にあるＭＩ
Ｂテーブル２１ａには、図９に示したように、２番目の
エントリが存在する。したがって、インデックス・エン
トリ対応関係保持部２２の内容は、以下のように更新さ
れる。The MI currently stored in the MIB table storage unit 21
As shown in FIG. 9, the B table 21a has a second entry. Therefore, the contents of the index / entry correspondence holding unit 22 are updated as follows.

【００５７】図１１はインデックス・エントリ対応関係
保持部の更新内容例を示す図である。図示の例によれ
ば、インデックス・エントリ対応関係保持部２２のデー
タ６５は、ＳＮＭＰメッセージ処理部１０より通知され
た際のインデックスは「１２９．２４９．１．１」なの
で、リクエスト中のインデックスとして、「１２９．２
４９．１．１」が記憶され、「Ｇｅｔ−Ｒｅｓｐｏｎｓ
ｅ」に用いたエントリの順番としては、「２」が記憶さ
れ、「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」に用いたエントリの
インデックスとしては、「１２９．２４９．１．１１」
が記憶されている。FIG. 11 is a diagram showing an example of updated contents of the index / entry correspondence holding unit. According to the example shown in the figure, the data 65 of the index / entry correspondence holding unit 22 has the index “129.249.1.1” when notified by the SNMP message processing unit 10. "129.2
49.1.1 ”is stored, and“ Get-Responses ”is stored.
“2” is stored as the order of the entries used for “e”, and “129.249.1.11” is stored as the index of the entry used for “Get-Response”.
Is remembered.

【００５８】その後、「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」に
用いられるオブジェクトインスタンス「ｉｐＡｄＥｎｔ
Ａｄｄｒ．１２９．２４９．１．１１」とその値「１２
９．２４９．１．１１」とがＳＮＭＰメッセージ処理部
１０へ渡される。After that, the object instance "ipAdEnt" used for "Get-Response"
Addr. 129.249.1.11 ”and its value“ 12
9.249.1.11 ”is passed to the SNMP message processing unit 10.

【００５９】上記リクエスト（３）に対する「Ｇｅｔ−
Ｒｅｓｐｏｎｓｅ」の内容は以下のようになる。 ipAdEntAddr.129.249.1.11=129.249.1.11, ipAdEntIfIndex.129.249.1.11=1, ipAdEntNetMask.129.249.1.11=255.255.255.0, ipAdEntBcastAddr.129.249.1.11=129.249.1.0, ipAdEntReasmMaxSize.129.249.1.11=1500 …（４） 他のオブジェクトインスタンスの処理は、更新されたイ
ンデックス・エントリ対応関係保持部２２の内容を使用
し、同様にして繰り返し実行される。"Get-" for the above request (3)
The contents of "Response" are as follows. ipAdEntAddr.129.249.1.11 = 129.249.1.11, = ipAdEntIfIndex.129.249.1.11 = 1, ipAdEntNetMask.129.249.1.11 = 255.255.255.0, ipAdEntBcastAddr.129.249.1.11 = 129.249.1.0, ipAdEntReasmMaxSize.129.249.1.11 = 1500 ... (4) Other The processing of the object instance of is used repeatedly by using the updated contents of the index / entry correspondence holding unit 22.

【００６０】このようにしてテーブルの検索が続行され
ると、このテーブルに対する最後の「ＧｅｔＮｅｘｔ−
Ｒｅｑｕｅｓｔ」の内容は、以下のようになる。 get-next ( ipAdEntAddr.129.249.1.61, ipAdEntIfIndex.129.249.1.61, ipAdEntNetMask.129.249.1.61, ipAdEntBcastAddr.129.249.1.61, ipAdEntReasmMaxSize.129.249.1.61 ) …（５） テーブル検索の「ＧｅｔＮｅｘｔ−Ｒｅｑｕｅｓｔ」を
順次処理してきたとすると、このときのインデックス・
エントリ対応関係保持部２２の内容は以下のようになっ
ている。When the search of the table is continued in this way, the last "GetNext-" for this table is
The contents of "Request" are as follows. get-next (ipAdEntAddr.129.249.1.61, ipAdEntIfIndex.129.249.1.61, ipAdEntNetMask.129.249.1.61, ipAdEntBcastAddr.129.249.1.61, ipAdEntReasmMaxSize.129.249.1.61) ... (5) “GetNext-Request is processed sequentially” for table search. If so, the index at this time
The contents of the entry correspondence holding unit 22 are as follows.

【００６１】図１２はインデックス・エントリ対応関係
保持部の内容例を示す図である。図示の例によれば、イ
ンデックス・エントリ対応関係保持部２２のデータ６６
は、リクエスト中のインデックスが「１２９．２４９．
１．５１」、「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」に用いたエ
ントリの順番が「７」、「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」
に用いたエントリのインデックスが「１２９．２４９．
１．６１」になっている。FIG. 12 is a diagram showing an example of the contents of the index / entry correspondence holding unit. According to the illustrated example, the data 66 of the index / entry correspondence holding unit 22
Indicates that the index in the request is "129.249.
The order of the entries used for "1.51", "Get-Response" is "7", "Get-Response"
The index of the entry used for is "129.249.
It is 1.61 ".

【００６２】上記（５）の「ＧｅｔＮｅｘｔ−Ｒｅｑｕ
ｅｓｔ」中のオブジェクトインスタンス「ｉｐＡｄＥｎ
ｔＡｄｄｒ．１２９．２４９．１．６１」に対して、Ｓ
ＮＭＰメッセージ処理部１０からＭＩＢテーブル記憶部
２１へ渡されるデータは以下のようになる。In the above (5), "GetNext-Request"
object instance "ipAdEn in est"
tAddr. 129.249.1.61 ”for S
The data passed from the NMP message processing unit 10 to the MIB table storage unit 21 are as follows.

【００６３】図１３はＳＮＭＰメッセージ処理部からＭ
ＩＢテーブル処理部へ渡されるデータ例を示す図であ
る。図示のデータ６７の例によれば、テーブル名は「ｉ
ｐＡｄｄｒＴａｂｌｅ」、リクエスト中に指定されてい
たインデックスは「１２９．２４９．１．６１」となっ
ている。FIG. 13 shows an M from the SNMP message processing unit.
It is a figure which shows the example of data passed to an IB table processing part. According to the example of the illustrated data 67, the table name is “i
pAddrTable ”, and the index specified in the request is“ 129.249.1.61 ”.

【００６４】前記（３）の「ＧｅｔＮｅｘｔ−Ｒｅｑｕ
ｅｓｔ」を受けたときと同様、まず、ＳＮＭＰメッセー
ジ処理部１０から渡されたインデックス「１２９．２４
９．１．６１」と、インデックス・エントリ対応関係保
持部２２にあるリクエスト中のインデックス「１２９．
２４９．１．５１」とを比較する。これらインデックス
は一致しないので、、次に、「Ｇｅｔ−Ｒｅｓｐｏｎｓ
ｅ」に用いたエントリのインデックス「１２９．２４
９．１．６１」と、ＳＮＭＰメッセージ処理部１０から
渡されたインデックス「１２９．２４９．１．６１」と
を比較する。これらインデックスは一致するので、「Ｇ
ｅｔ−Ｒｅｓｐｏｎｓｅ」に用いたエントリの順番は、
インデックス・エントリ対応関係保持部２２にある
「７」の次、すなわち、「８」となる。しかし、図８に
例示のテーブル６２には、８番目のエントリは存在しな
い。したがって、ＭＩＢテーブル処理部２０は、「Ｇｅ
ｔ−Ｒｅｓｐｏｎｓｅ」に用いるオブジェクトインスタ
ンスは存在しない旨を、ＳＮＭＰメッセージ処理部１０
へ通知する（図５中のＳ４１、Ｓ４４）。このとき、イ
ンデックス・エントリ対応関係保持部２２の内容は更新
されない。In the above (3), "GetNext-Request"
Similarly to the case of receiving the “est”, first, the index “129.24” passed from the SNMP message processing unit 10 is received.
9.1.61 ”and the index“ 129.
249.1.51 ". Since these indexes do not match, the next step is "Get-Responses".
The index “129.24” of the entry used for “e”
The “9.1.61” is compared with the index “129.249.1.61” passed from the SNMP message processing unit 10. Since these indexes match, "G
The order of the entries used for "et-Response" is
It is next to "7" in the index / entry correspondence holding unit 22, that is, "8". However, the table 62 illustrated in FIG. 8 does not have the eighth entry. Therefore, the MIB table processing unit 20 determines that “Ge
The SNMP message processing unit 10 indicates that the object instance used for “t-Response” does not exist.
To (S41, S44 in FIG. 5). At this time, the contents of the index / entry correspondence holding unit 22 are not updated.

【００６５】ＳＮＭＰメッセージ処理部１０では、ＭＩ
Ｂツリー上で「ｉｐＡｄＥｎｔＡｄｄｒ」の次に辞書的
順番の大きいオブジェクトである「ｉｐＡｄＥｎｔＩｆ
Ｉｎｄｅｘ」を検索し、「ｉｐＡｄＥｎｔＩｆＩｎｄｅ
ｘ」に対してインデックス「なし」の状態、すなわち、
図７に示したデータと同じ内容のデータを渡して、再度
ＭＩＢテーブル処理部２０を起動する。インデックスは
「なし」なので、ＭＩＢテーブル処理部２０はテーブル
中最少のエントリの順番とインデックスとを用いてオブ
ジェクトインスタンス「ｉｐＡｄＥｎｔＩｆＩｎｄｅ
ｘ．１２９．２４９．１．１」とその値「３」とをＳＮ
ＭＰメッセージ処理部１０へ渡し、インデックス・エン
トリ対応関係保持部２２の内容を更新する。更新された
結果は、図９に示したデータと同じ内容になる。In the SNMP message processing unit 10, the MI
"IpAdEntIf", which is the object with the next largest lexicographical order after "ipAdEntAddr" on the B-tree
Search for "Index" and search for "ipAdEntIfInde
The state of the index “none” for x ”, that is,
The data having the same content as the data shown in FIG. 7 is passed, and the MIB table processing unit 20 is activated again. Since the index is “none”, the MIB table processing unit 20 uses the order of the smallest entry in the table and the index to determine the object instance “ipAdEntIfInde.
x. 129.249.1.1 ”and its value“ 3 ”are SN
It is passed to the MP message processing unit 10 and the contents of the index / entry correspondence holding unit 22 are updated. The updated result has the same contents as the data shown in FIG.

【００６６】このように、インデックス・エントリ対応
関係保持部２２の内容を利用することにより、エントリ
を決めるためのサーチが不要になるので、最初のエント
リを除くエントリ数６×オブジェクト数５＝３０回のサ
ーチ時間分、処理に要する時間を短くすることができ
る。As described above, by using the contents of the index / entry correspondence holding unit 22, a search for determining an entry is not required, so the number of entries excluding the first entry 6 × the number of objects 5 = 30 times. It is possible to shorten the time required for processing by the search time.

【００６７】次に、ＳＮＭＰメッセージ処理部１０から
のリクエストに、インデックス・エントリ対応関係保持
部２２にあるリクエスト中のインデックスと「Ｇｅｔ−
Ｒｅｓｐｏｎｓｅ」に用いたエントリのインデックスと
のいずれにも該当しないインデックスが指定されていた
場合について考える。Next, in the request from the SNMP message processing unit 10, the index in the request stored in the index / entry correspondence holding unit 22 and "Get-
Consider a case where an index that does not correspond to any of the indexes of the entries used for “Response” is specified.

【００６８】今、ＭＩＢテーブル記憶部２１に図８のテ
ーブル６２と同じ内容が記憶され、また、インデックス
・エントリ対応関係保持部２２には、以下のような内容
が記憶されていたとする。Now, it is assumed that the same contents as the table 62 of FIG. 8 are stored in the MIB table storage unit 21, and the following contents are stored in the index / entry correspondence holding unit 22.

【００６９】図１４はインデックス・エントリ対応関係
保持部の内容例を示す図である。図示の例によれば、イ
ンデックス・エントリ対応関係保持部２２のデータ６８
は、リクエスト中のインデックスが「１２９．２４９．
１．３１」、「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」に用いたエ
ントリの順番が「５」、「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」
に用いたエントリのインデックスが「１２９．２４９．
１．４１」になっているものとする。FIG. 14 is a diagram showing an example of contents of the index / entry correspondence holding unit. According to the illustrated example, the data 68 of the index / entry correspondence holding unit 22 is
Indicates that the index in the request is "129.249.
The order of entries used for "1.31", "Get-Response" is "5", "Get-Response"
The index of the entry used for is "129.249.
1.41 ”.

【００７０】これらの状態で、ＳＮＭＰメッセージ処理
部１０がたとえば以下の「ＧｅｔＮｅｘｔ−Ｒｅｑｕｅ
ｓｔ」を受けたとする。 get-next ( ipAdEntAddr.129.249.1.25 ) …（７） このとき、ＳＮＭＰメッセージ処理部１０からＭＩＢテ
ーブル処理部２０へ渡されるデータは以下のようにな
る。In these states, the SNMP message processing unit 10 may use, for example, the following "GetNext-Request".
st ”is received. get-next (ipAdEntAddr.129.249.1.25) (7) At this time, the data passed from the SNMP message processing unit 10 to the MIB table processing unit 20 is as follows.

【００７１】図１５はＳＮＭＰメッセージ処理部からＭ
ＩＢテーブル処理部へ渡されるデータ例を示す図であ
る。図示のデータ６９の例によれば、テーブル名は「ｉ
ｐＡｄｄｒＴａｂｌｅ」、リクエスト中に指定されてい
たインデックスは「１２９．２４９．１．２５」となっ
ている。FIG. 15 shows an M message from the SNMP message processing unit.
It is a figure which shows the example of data passed to an IB table processing part. According to the example of the illustrated data 69, the table name is “i
pAddrTable ”, and the index specified in the request is“ 129.249.1.25 ”.

【００７２】ＭＩＢテーブル処理部２０では、ＭＩＢテ
ーブル記憶部２１に「ｉｐＡｄＥｎｔＡｄｄｒ」が記憶
されているので、インデックス・エントリ対応関係保持
部２２のデータを参照する。しかし、このとき、ＳＮＭ
Ｐメッセージ処理部１０から渡されたインデックス「１
２９．２４９．１．２５」は、インデックス・エントリ
対応関係保持部２２にあるリクエスト中のインデックス
「１２９．２４９．１．３１」、「Ｇｅｔ−Ｒｅｓｐｏ
ｎｓｅ」に用いたエントリのインデックス「１２９．２
４９．１．４１」のいずれとも一致しない。In the MIB table processing unit 20, since “ipAdEntAddr” is stored in the MIB table storage unit 21, the data in the index / entry correspondence holding unit 22 is referred to. However, at this time, SNM
The index “1” passed from the P message processing unit 10
“29.249.1.25” is the index “129.24.91.31” and “Get-Respo” in the request stored in the index / entry correspondence holding unit 22.
The index of the entry used for “nse” is “129.2.
49.1.41 ”.

【００７３】よって、「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」に
用いるエントリをテーブル全体からサーチすることが必
要となる。ここで、ＭＩＢテーブル記憶部２１にあるテ
ーブルはインデックスの辞書的順番によってソートされ
ているので、インデックス・エントリ対応関係保持部２
２にあるリクエスト中のインデックスと、ＳＮＭＰメッ
セージ処理部１０から渡されたインデックスとの辞書的
順番の大小により、サーチ範囲を決めることができる。Therefore, it is necessary to search the entire table for the entry used for "Get-Response". Here, since the table in the MIB table storage unit 21 is sorted according to the lexical order of the indexes, the index / entry correspondence holding unit 2
The search range can be determined based on the size of the lexicographical order of the index in the request in 2 and the index passed from the SNMP message processing unit 10.

【００７４】ＳＮＭＰメッセージ処理部１０から渡され
たインデックス「１２９．２４９．１．２５」は、イン
デックス・エントリ対応関係保持部２２にあるリクエス
ト中のインデックス「１２９．２４９．１．３１」より
も辞書的順番が小さい。したがって、「Ｇｅｔ−Ｒｅｓ
ｐｏｎｓｅ」に用いるエントリは、テーブル中、順番が
最小のエントリ、すなわち、１番目のエントリと、イン
デックス・エントリ対応関係保持部２２にある「Ｇｅｔ
−Ｒｅｓｐｏｎｓｅ」に用いたエントリ、すなわち、５
番目のエントリとの間でサーチすればよい（図３中のＳ
２２、Ｓ２３）。The index “129.249.1.25” passed from the SNMP message processing unit 10 is a dictionary rather than the index “129.249.1.31” in the request in the index / entry correspondence holding unit 22. The target order is small. Therefore, "Get-Res
The entry used for “response” is the entry with the smallest order in the table, that is, the first entry and “Get” in the index / entry correspondence holding unit 22.
-The entry used for "Response", that is, 5
Search with the th entry (S in FIG. 3)
22, S23).

【００７５】その結果、「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」
に用いるエントリは、インデックスが「１２９．２４
９．１．３１」、すなわち、４番目のエントリとなる。
後は、すでに述べた場合と同様に、インデックス・エン
トリ対応関係保持部２２の内容が更新され、「Ｇｅｔ−
Ｒｅｓｐｏｎｓｅ」に用いられるオブジェクトインスタ
ンスとその値が、ＳＮＭＰメッセージ処理部１０へと渡
される。As a result, "Get-Response"
The entry used for the index is "129.24.
9.1.31 ”, that is, the fourth entry.
After that, as in the case already described, the content of the index / entry correspondence holding unit 22 is updated to "Get-
The object instance used for “Response” and its value are passed to the SNMP message processing unit 10.

【００７６】このように、インデックス・エントリ対応
関係保持部２２の内容を利用することにより、サーチ範
囲を狭めることができ、インデックスの辞書的順番の大
小を比較する処理時間を、５〜７番目のエントリ、すな
わち、３エントリ分短くすることができるようになる。As described above, by using the contents of the index / entry correspondence holding unit 22, the search range can be narrowed, and the processing time for comparing the lexicographical order of the indexes is the fifth to the seventh. It becomes possible to shorten the number of entries, that is, three entries.

【００７７】なお、上述の実施例では、ＭＩＢテーブル
記憶部およびインデックス・エントリ対応関係保持部に
１つのテーブル分の内容だけを記憶している場合を示し
たが、これらを複数記憶しておくようにすることもでき
る。これにより、複数のテーブルに対する「ＧｅｔＮｅ
ｘｔ−Ｒｅｑｕｅｓｔ」を非連続的に受けた場合の全体
的な処理時間を短縮することが可能である。これは、複
数のＳＮＭＰマネージャから同時にアクセスされる可能
性の高いＳＮＭＰエージェントにおいて、特に有効であ
る。In the above embodiment, the MIB table storage unit and the index / entry correspondence holding unit store only the contents of one table, but a plurality of these may be stored. You can also This allows "GetNe for multiple tables.
It is possible to reduce the overall processing time when the "xt-Request" is received discontinuously. This is particularly effective for an SNMP agent that is likely to be simultaneously accessed by multiple SNMP managers.

【００７８】[0078]

【発明の効果】以上説明したように本発明では、テーブ
ル全体をインデックスでソートして記憶し、さらに、
「ＧｅｔＮｅｘｔ−Ｒｅｑｕｅｓｔ」中のインデックス
と、サーチしたエントリの順番と、そのエントリのイン
デックスとの組み合わせによるインデックス・エントリ
対応関係を記憶しておくように構成したことにより、以
下のような効果がある。As described above, according to the present invention, the entire table is sorted by index and stored.
The following effects can be obtained by storing the index-entry correspondence relationship based on the combination of the index in "GetNext-Request", the order of the searched entry, and the index of the entry.

【００７９】（ａ）同一のインデックスを持つ複数のオ
ブジェクトインスタンスへの「ＧｅｔＮｅｘｔ−Ｒｅｑ
ｕｅｓｔ」の処理で、エントリのサーチは最初の１回の
みでよく、次回からはインデックス・エントリ対応関係
を参照するだけでよいので、エントリ中のオブジェクト
の個数が多いほど、エントリ全体のオブジェクトインス
タンスを取得するのに要する時間は短くなる。(A) "GetNext-Req" for a plurality of object instances having the same index
In the process of “uest”, the entry search only needs to be performed once at the beginning, and from the next time, it is only necessary to refer to the index / entry correspondence. It takes less time to get.

【００８０】（ｂ）テーブルはソートされているため、
「ＧｅｔＮｅｘｔ−Ｒｅｑｕｅｓｔ」中のオブジェクト
インスタンスを持つインデックスが、記憶されているエ
ントリのそれと同じであった場合には、テーブル全体で
はなく、記憶されているエントリの次のエントリをサー
チすればよいので、エントリのサーチ時間を短縮するこ
とができる。(B) Since the table is sorted,
If the index having the object instance in "GetNext-Request" is the same as that of the stored entry, the next entry of the stored entry may be searched instead of the entire table. The entry search time can be shortened.

【００８１】（ｃ）テーブルはソートされているため、
「ＧｅｔＮｅｘｔ−Ｒｅｑｕｅｓｔ」中に指定されたイ
ンデックスが、記憶されている「ＧｅｔＮｅｘｔ−Ｒｅ
ｑｕｅｓｔ」中のインデックスやサーチしたエントリの
インデックスのいずれにも一致しない場合には、テーブ
ル全体のうち、エントリのサーチは、記憶されているイ
ンデックスおよびサーチしたエントリのインデックスよ
り辞書的順番の大きい方向または小さい方向のどちらか
のみのでサーチを行えばよく、サーチ効果を向上させる
ことができる。(C) Since the table is sorted,
The index specified in "GetNext-Request" is stored in "GetNext-Re".
If it does not match any of the index in “quest” or the index of the searched entry, the search of the entry in the entire table is performed in a direction having a larger lexicographical order than the stored index and the index of the searched entry, or It suffices to perform the search only in one of the smaller directions, and the search effect can be improved.

【００８２】実際に上記効果が現れる状況例としては、
以下のような場合が考えられる。通常、テーブルの検索
は、１エントリを単位として「ＧｅｔＮｅｘｔ−Ｒｅｑ
ｕｅｓｔ」の発行と「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」の受
信の繰り返しにより行われる。このとき、テーブルは複
数のオブジェクトによって構成されるのが一般的であ
る。よって、１つの「ＧｅｔＮｅｘｔ−Ｒｅｑｕｅｓ
ｔ」は、同一エントリ中の複数のオブジェクトインスタ
ンスが含まれた形で発行される。これが、上記（ａ）の
効果が現れる状況になる。As an example of a situation in which the above effect actually appears,
The following cases are possible. Normally, the table is searched by "GetNext-Req" in units of one entry.
It is performed by repeatedly issuing the "uest" and receiving the "Get-Response". At this time, the table is generally composed of a plurality of objects. Therefore, one "GetNext-Requests"
The “t” is issued in a form in which a plurality of object instances in the same entry are included. This is the situation in which the effect of (a) above appears.

【００８３】「ＧｅｔＮｅｘｔ−Ｒｅｑｕｅｓｔ」に対
する「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」には、「ＧｅｔＮｅ
ｘｔ−Ｒｅｑｕｅｓｔ」中に指定されていたインデック
スの次に辞書的順番の大きいエントリが格納される。
「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」を受け取ったマネージャ
では、「Ｇｅｔ−Ｒｅｓｐｏｎｓｅ」に格納されたエン
トリのインデックスを用いて、新たな「ＧｅｔＮｅｘｔ
−Ｒｅｑｕｅｓｔ」を発行し、これをテーブル全体の検
索が終了するまで繰り返す。したがって、指定されてい
るインデックスが辞書的順番として単調増加しながら、
「ＧｅｔＮｅｘｔ−Ｒｅｑｕｅｓｔ」は繰り返し発行さ
れる。これが、上記（ｂ）の効果が現れる状況になる。"Get-Response" for "GetNext-Request" contains "GetNe."
The entry having the next largest lexicographical order after the index designated in “xt-Request” is stored.
The manager receiving the "Get-Response" uses the index of the entry stored in the "Get-Response" to create a new "GetNext".
-Request "is issued and this is repeated until the search of the entire table is completed. Therefore, the specified index increases monotonically as a lexicographical order,
“GetNext-Request” is repeatedly issued. This is the situation where the effect of (b) above appears.

【００８４】さらに、エージェントは複数のマネージャ
から管理されている場合がある。このとき、複数のマネ
ージャが同時に同一のテーブルを検索開始した場合に
は、受信する「ＧｅｔＮｅｘｔ−Ｒｅｑｕｅｓｔ」に指
定されたインデックスが上記のように辞書的順番として
単調増加するとは限らず、指定されているエントリがラ
ンダムに変化する可能性がある。これが、上記（ｃ）の
効果が現れる状況になる。Further, the agent may be managed by a plurality of managers. At this time, when a plurality of managers start searching the same table at the same time, the index specified in the received "GetNext-Request" does not always increase monotonically in the lexicographical order as described above, but is specified. Entries may change randomly. This is the situation where the effect of (c) above appears.

【図面の簡単な説明】[Brief description of drawings]

【図１】本発明のネットワーク管理情報検索方式の構成
例を示す図である。FIG. 1 is a diagram showing a configuration example of a network management information search method of the present invention.

【図２】ＭＩＢテーブル処理部の処理の流れを示すフロ
ーチャート（その１）である。FIG. 2 is a flowchart (No. 1) showing the flow of processing of the MIB table processing unit.

【図３】ＭＩＢテーブル処理部の処理の流れを示すフロ
ーチャート（その２）である。FIG. 3 is a flowchart (part 2) showing the flow of processing of the MIB table processing unit.

【図４】ＭＩＢテーブル処理部の処理の流れを示すフロ
ーチャート（その３）である。FIG. 4 is a flowchart (No. 3) showing the flow of processing of the MIB table processing unit.

【図５】ＭＩＢテーブル処理部の処理の流れを示すフロ
ーチャート（その４）である。FIG. 5 is a flowchart (No. 4) showing the flow of processing of the MIB table processing unit.

【図６】リソース状態監視部の処理の流れを示すフロー
チャートである。FIG. 6 is a flowchart showing a processing flow of a resource status monitoring unit.

【図７】ＳＮＭＰメッセージ処理部からＭＩＢテーブル
処理部へ渡されるデータ例を示す図である。FIG. 7 is a diagram showing an example of data passed from an SNMP message processing unit to an MIB table processing unit.

【図８】作成されたＭＩＢテーブルの内容例を示す図で
ある。FIG. 8 is a diagram showing an example of the contents of a created MIB table.

【図９】インデックス・エントリ対応関係保持部の内容
例を示す図である。FIG. 9 is a diagram showing an example of contents of an index / entry correspondence holding unit.

【図１０】ＳＮＭＰメッセージ処理部からＭＩＢテーブ
ル処理部へ渡されるデータ例を示す図である。FIG. 10 is a diagram showing an example of data passed from the SNMP message processing unit to the MIB table processing unit.

【図１１】インデックス・エントリ対応関係保持部の更
新内容例を示す図である。FIG. 11 is a diagram showing an example of updated contents of an index / entry correspondence holding unit.

【図１２】インデックス・エントリ対応関係保持部の内
容例を示す図である。FIG. 12 is a diagram showing an example of contents of an index / entry correspondence holding unit.

【図１３】ＳＮＭＰメッセージ処理部からＭＩＢテーブ
ル処理部へ渡されるデータ例を示す図である。FIG. 13 is a diagram showing an example of data passed from the SNMP message processing unit to the MIB table processing unit.

【図１４】インデックス・エントリ対応関係保持部の内
容例を示す図である。FIG. 14 is a diagram showing an example of contents of an index / entry correspondence holding unit.

【図１５】ＳＮＭＰメッセージ処理部からＭＩＢテーブ
ル処理部へ渡されるデータ例を示す図である。FIG. 15 is a diagram showing an example of data passed from the SNMP message processing unit to the MIB table processing unit.

【図１６】ＭＩＢ−ＩＩに定義されているテーブルの一
例を示す図である。FIG. 16 is a diagram showing an example of a table defined in MIB-II.

【符号の説明】[Explanation of symbols]

１０ ＳＮＭＰメッセージ処理部 ２０ ＭＩＢテーブル処理部 ２１ ＭＩＢテーブル記憶部 ２１ａ ＭＩＢテーブル ２２ インデックス・エントリ対応関係保持部 ３０ リソース情報記憶部 ４０ ＭＩＢテーブル作成部 ５０ リソース状態監視部 10 SNMP Message Processing Section 20 MIB Table Processing Section 21 MIB Table Storage Section 21a MIB Table 22 Index / Entry Correspondence Holding Section 30 Resource Information Storage Section 40 MIB Table Creation Section 50 Resource Status Monitoring Section

Claims (6)

【特許請求の範囲】[Claims] 【請求項１】 被管理機器毎に管理情報ベーステーブル
に登録されているネットワーク管理情報を検索するネッ
トワーク管理情報検索方式において、 マネージャとの通信時にネットワーク管理プロトコルの
プロトコル処理を行うメッセージ処理手段と、 被管理オブジェクトのインスタンスが登録され、インデ
ックスとなるオブジェクトのインスタンスをキーとして
エントリが辞書的順番にソートされている管理情報ベー
ステーブル記憶部、および前記メッセージ処理手段から
通知されたリクエスト中に指定されているインデックス
と前記メッセージ処理手段への応答に用いたエントリの
順番と前記メッセージ処理手段への応答に用いたエント
リのインデックスとを検索毎に保持しておくインデック
ス・エントリ対応関係保持部を有する管理情報ベーステ
ーブル処理手段と、 を備えていることを特徴とするネットワーク管理情報検
索方式。1. In a network management information search method for searching network management information registered in a management information base table for each managed device, message processing means for performing protocol processing of a network management protocol during communication with a manager, An instance of a managed object is registered, and a management information base table storage unit in which entries are sorted in a lexicographical order using an instance of an object serving as an index, and is specified in a request notified from the message processing unit. Management information having an index / entry correspondence holding unit that holds, for each search, an index that is present, the order of the entries used to respond to the message processing unit, and the index of the entry used to respond to the message processing unit. Network management information retrieval system, characterized in that it comprises a base table processing means. 【請求項２】 前記管理情報ベーステーブル処理手段
は、前記メッセージ処理手段から通知されたリクエスト
中に指定されているインデックスと前記インデックス・
エントリ対応関係保持部に保持されているリクエスト中
のインデックスとを比較して一致した場合に、前記イン
デックス・エントリ対応関係保持部に保持されている応
答に用いたエントリの順番を検索対象のエントリの順番
とするよう構成されていることを特徴とする請求項１記
載のネットワーク管理情報検索方式。2. The management information base table processing means includes the index specified in the request notified from the message processing means and the index.
When the comparison is made with the index in the request held in the entry correspondence holding unit, the order of the entries used in the response held in the index / entry correspondence holding unit is compared with that of the entry to be searched. 2. The network management information search method according to claim 1, wherein the network management information search method is configured in order. 【請求項３】 前記管理情報ベーステーブル処理手段
は、前記メッセージ処理手段から通知されたリクエスト
中に指定されているインデックスが前記インデックス・
エントリ対応関係保持部に保持されているリクエスト中
のインデックスと一致しないが前記インデックス・エン
トリ対応関係保持部に保持されている応答に用いたエン
トリのインデックスとは一致する場合に、前記インデッ
クス・エントリ対応関係保持部に保持されている応答に
用いたエントリの順番を検索対象のエントリの順番とす
るよう構成されていることを特徴とする請求項１記載の
ネットワーク管理情報検索方式。3. The management information base table processing means is characterized in that the index specified in the request notified from the message processing means is the index.
If it does not match the index in the request held in the entry correspondence holding unit but matches the index of the entry used in the response held in the index / entry correspondence holding unit, the index / entry correspondence 2. The network management information search method according to claim 1, wherein the order of the entries used for the response held in the relationship holding unit is set as the order of the entries to be searched. 【請求項４】 前記管理情報ベーステーブル処理手段
は、前記メッセージ処理手段から通知されたリクエスト
中に指定されているインデックスが前記インデックス・
エントリ対応関係保持部に保持されているリクエスト中
のインデックスおよび応答に用いたエントリのインデッ
クスのいずれにも一致しない場合に、前記メッセージ処
理手段から通知されたリクエスト中に指定されているイ
ンデックスと前記インデックス・エントリ対応関係保持
部に保持されている応答に用いたエントリのインデック
スとの辞書的順番を比較して、前記インデックス・エン
トリ対応関係保持部に保持されている応答に用いたエン
トリを検索範囲の限界エントリとするよう構成されてい
ることを特徴とする請求項１記載のネットワーク管理情
報検索方式。4. The management information base table processing means uses the index specified in the request notified from the message processing means as the index.
The index specified in the request notified from the message processing means and the index when the index held in the entry correspondence holding unit and the index of the entry used for the response do not match -Compare the lexicographical order with the index of the entry used for the response held in the entry correspondence holding unit and compare the entries used for the response held in the index-entry correspondence holding unit with the search range. The network management information retrieval system according to claim 1, wherein the network management information retrieval system is configured to be a limit entry. 【請求項５】 前記管理情報ベーステーブル記憶部にメ
ッセージ処理手段から通知された検索対象の管理情報ベ
ーステーブルが存在しない場合に、リソース情報を元に
管理情報ベーステーブルを作成する管理情報ベーステー
ブル作成手段をさらに備えていることを特徴とする請求
項１記載のネットワーク管理情報検索方式。5. A management information base table creation for creating a management information base table based on resource information when the search target management information base table notified from the message processing means does not exist in the management information base table storage unit. The network management information retrieval system according to claim 1, further comprising means. 【請求項６】 前記管理情報ベーステーブル記憶部に記
憶されている管理情報ベーステーブルに対応したリソー
ス情報の変化を監視して前記リソース情報に変化があっ
た場合に、前記管理情報ベーステーブル記憶部に記憶さ
れている管理情報ベーステーブルおよび前記インデック
ス・エントリ対応関係保持部に保持されている対応関係
を抹消するリソース状態監視手段をさらに備えているこ
とを特徴とする請求項１記載のネットワーク管理情報検
索方式。6. The management information base table storage unit when a change in resource information corresponding to a management information base table stored in the management information base table storage unit is monitored and there is a change in the resource information. 2. The network management information according to claim 1, further comprising a resource status monitoring unit that deletes the correspondence relationship held in the management information base table and the index / entry correspondence relationship holding unit stored in. Search method.