(57)【要約】【課題】  従来技術に基づく問題点を解消し、従来から用いられているＳＮＭＰｖ１のインターフェースを改造することなく、増加するトラヒックに対応可能とする技術を提供すること。【解決手段】  トラヒックを観測したいネットワーク中継装置に３２ビットを超えるカウンタを内蔵し、例えば、内部カウンタの値をあらかじめネットワーク管理サーバとネットワーク中継装置（例えば、ルータ）が合意した数だけ下位へビットシフトした３２ビット値を転送し、ネットワーク管理サーバにおいて合意した数だけ上位へビットシフトすることによって、カウンタラップが発生する問題を解決しようとするものである。【選択図】      図４
2005151243.tif 000002
【特許請求の範囲】
【請求項１】
３２ビットを超えるトラヒックカウンタにより内部的にトラヒックデータを計測する機能を持つＩＰネットワーク中継機器と、当該中継機器のトラヒックデータをＳＮＭＰプロトコルによって取得可能なネットワーク管理サーバとが、通信回線によって接続されたネットワークにおいて、トラヒックデータ取得時に前記ネットワーク管理サーバが前記中継機器に対してトラヒックデータ取得操作を行う際に、前記トラヒックカウンタのオーバーフローを防ぐことによって正しくトラヒックデータを収集する方法であって、
前記ネットワーク管理サーバからのトラヒックカウンタ値取得要求時に、前記中継機器は内部の３２ビットを超えるトラヒックカウンタをｎビット下位へビットシフトし、下位３２ビットをカウンタ値として前記ネットワーク管理サーバに通知し、この通知を受けた前記ネットワーク管理サーバは、前記中継機器から受信した３２ビットカウンタを上位へｎビットシフトし、下位ｎビットを０とした３２＋ｎビットのカウンタ値とする
ことを特徴とするトラヒックデータの収集方法。
【請求項２】
３２ビットを超えるトラヒックカウンタにより内部的にトラヒックデータを計測する機能を持つＩＰネットワーク中継機器と、当該中継機器のトラヒックデータをＳＮＭＰプロトコルによって取得可能なネットワーク管理サーバとが、通信回線によって接続されたネットワークにおいて、トラヒックデータ取得時に前記ネットワーク管理サーバが前記中継機器に対してトラヒックデータ取得操作を行う際に、前記トラヒックカウンタのオーバーフローを防ぐことによって正しくトラヒックデータを収集するシステムであって、
前記中継機器は、前記ネットワーク管理サーバからのトラヒックカウンタ値取得要求時に、内部の３２ビットを超えるトラヒックカウンタをｎビット下位へビットシフトし、下位３２ビットをカウンタ値に変換して前記ネットワーク管理サーバに通知する変換処理手段を有し、
前記ネットワーク管理サーバは、前記カウンタ値の通知を受けた際に、前記中継機器から受信した３２ビットカウンタを上位へｎビットシフトし、下位ｎビットを０とした３２＋ｎビットのカウンタ値に変換する変換処理手段を有する
ことを特徴とするトラヒックデータの収集システム。
【請求項３】
３２ビットを超えるトラヒックカウンタにより内部的にトラヒックデータを計測する機能を持つＩＰネットワーク中継機器と、当該中継機器のトラヒックデータをＳＮＭＰプロトコルによって取得できるネットワーク管理サーバとが、通信回線によって接続されたネットワークにおいて、トラヒックデータ取得時に前記ネットワーク管理サーバが前記中継機器に対してトラヒックデータ取得操作を行う際に、前記トラヒックカウンタのオーバーフローを防ぐことによって正しくトラヒックデータを収集する方法であって、
前記ネットワーク管理サーバからのトラヒックカウンタ値取得要求時に、前記中継機器は、内部の３２ビットを超えるトラヒックカウンタをｍで除算し、除算した値をカウンタ値として前記ネットワーク管理サーバに通知し、この通知を受けた前記ネットワーク管理サーバは、前記中継機器から受信したカウンタをｍ倍し、下位ｍの２進数値分のビットを０としたカウンタ値とする
ことを特徴とするトラヒックデータの収集方法。
【請求項４】
３２ビットを超えるトラヒックカウンタにより内部的にトラヒックデータを計測する機能を持つＩＰネットワーク中継機器と、当該中継機器のトラヒックデータをＳＮＭＰプロトコルによって取得可能なネットワーク管理サーバとが、通信回線によって接続されたネットワークにおいて、トラヒックデータ取得時に前記ネットワーク管理サーバが前記中継機器に対してトラヒックデータ取得操作を行う際に、前記トラヒックカウンタのオーバーフローを防ぐことによって正しくトラヒックデータを収集するシステムであって、
前記中継機器は、前記ネットワーク管理サーバからのトラヒックカウンタ値取得要求時に、内部の３２ビットを超えるトラヒックカウンタをｍ（ｍ：定数）で除算し、除算した値をカウンタ値として前記ネットワーク管理サーバに通知する変換処理手段を有し、
前記ネットワーク管理サーバは、前記カウンタ値の通知を受けた際に、前記中継機器から受信したカウンタをｍ倍し、下位ｍの２進数値分のビットを０としたカウンタ値に変換する変換処理手段を有する
ことを特徴とするトラヒックデータの収集システム。
【請求項５】
３２ビットを超えるトラヒックカウンタにより内部的にトラヒックデータを計測する機能を持つＩＰネットワーク中継機器と、当該中継機器のトラヒックデータをＳＮＭＰプロトコルによって取得可能なネットワーク管理サーバとが、通信回線によって接続されたネットワークにおいて、トラヒックデータ取得時に前記ネットワーク管理サーバが前記中継機器に対してトラヒックデータ取得操作を行う際に、前記トラヒックカウンタのオーバーフローを防ぐことによって正しくトラヒックデータを収集する方法であって、
前記ネットワーク管理サーバからのトラヒックカウンタ値取得要求時に、前記中継機器は内部の３２ビットを超えるトラヒックカウンタの下位３２ビットをまず前記ネットワーク管理サーバに通知し、次に残りの上位ビットを前記ネットワーク管理サーバへ通知し、この通知を受けた前記ネットワーク管理サーバは、前記中継機器から受信した最初の３２ビットのカウンタを下位３２ビットの値とし、次に受信した残りの上位ビットのカウンタ値を上位に連結することにより３２ビットを超えるトラヒックカウンタ値とする
ことを特徴とするトラヒックデータの収集方法。
【請求項６】
３２ビットを超えるトラヒックカウンタにより内部的にトラヒックデータを計測する機能を持つＩＰネットワーク中継機器と、当該中継機器のトラヒックデータをＳＮＭＰプロトコルによって取得可能なネットワーク管理サーバとが、通信回線によって接続されたネットワークにおいて、トラヒックデータ取得時に前記ネットワーク管理サーバが前記中継機器に対してトラヒックデータ取得操作を行う際に、前記トラヒックカウンタのオーバーフローを防ぐことによって正しくトラヒックデータを収集するシステムであって、
前記中継機器は、前記ネットワーク管理サーバからのトラヒックカウンタ値取得要求時に、内部の３２ビットを超えるトラヒックカウンタの下位３２ビットをまず前記ネットワーク管理サーバに通知し、次に残りの上位ビットを前記ネットワーク管理サーバへ通知する変換処理手段を有し、
前記ネットワーク管理サーバは、前記２つの部分からなる通知を受けた際に、前記中継機器から受信した最初の３２ビットのカウンタを下位３２ビットの値とし、次に受信した残りの上位ビットのカウンタ値を上位に連結することにより３２ビットを超えるトラヒックカウンタ値とする変換処理手段を有する
ことを特徴とするトラヒックデータの収集システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、トラヒックデータの収集方法およびそのシステムに関し、より具体的には、図７に示すようなルータ，スイッチ等（中継機器：以下、ルータで代表させる）２０が伝送路（伝送システム）で互いに接続されたネットワークで、各中継点のルータ２０を通過するパケット数やデータ量（バイト数）をネットワーク管理サーバ１０が定期的に収集する際に、従来から用いられているＳＮＭＰｖ１のインターフェースを改造することなく、増加するトラヒックに対応可能とする技術に関するものである。
【背景技術】
【０００２】
上述のネットワーク管理サーバ（以下、単にサーバともいう）１０は、その一例を図８に示すように、定期的にルータ２０のＳＮＭＰｖ１の３２ビットトラヒックカウンタを取得し、そのカウンタデータ値の前回取得値と今回取得値の差分を、２回の取得操作を行った時間のトラヒックと見なす。例として、ルータは速度150Mbpsの回線を有しており、サーバ１０は１時間おきにルータ２０の当該回線のトラヒック量（オクテットカウンタ値）をＳＮＭＰにより収集するものとする。
【０００３】
ここで、ある時刻Ｔに手順（４）で取得した値が10,000であり、その一時間後に手順（８）で取得した値が410,075,408であったとする。このとき、サーバ１０は、時刻Ｔ時〜Ｔ＋１時の１時間に流れたトラヒック量は
＜オクテット数＞で、410,075,408−10,000＝410,065,408オクテット
＜平均トラヒック量＞は、＜410065408／3600＞×8＝911,256[bps]
と判断する。
【０００４】
従来の３２ビットのオクテットカウンタでは、最近の高速インターフェースにおける通信においては観測周期の間に２３２オクテット以上の通過トラヒックがあり得るため、サーバ１０が正確なトラヒック量を把握することができなかった（これに関しては、例えば、非特許文献１を参照のこと）。
【０００５】
例えば、図９に示すように、実際の期間Ｔ時〜Ｔ＋１時の平均トラヒック量が20Mbpsであった場合、この1時間に通過したトラヒック量は9,000,000,000オクテットであり、時刻Ｔ＋１において、手順（７）によりトラヒック量観測サーバ（１０）に通知すべき値は9,000,010,000であるが、ＳＮＭＰｖ１において通知可能な最大カウンタ値は２３２オクテット（4,294,967,296ビット）であるため、サーバに通知される値は、9,000,010,000を２３２で除した剰余である410,075,408オクテットが通知され、時刻Ｔのときのトラヒック量が10,000オクテットであったとすると、計算されるトラヒック量は410,065,408オクテットとなり、上記の平均トラヒック量900kbpsの場合との区別がつかない。
【０００６】
【非特許文献１】ＳＮＭＰインターネットワーク管理（66P）、Mark．A．Miller著トップスタジオ訳原パンメディアテック・宇野俊夫監修、1998/10/30、翔泳社
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は上記事情に鑑みてなされたものであり、その目的とするところは、前記従来技術に基づく問題点を解消し、従来から用いられているＳＮＭＰｖ１のインターフェースを改造することなく、増加するトラヒックに対応可能とする技術を提供することにある。
【課題を解決するための手段】
【０００８】
上記目的を達成するために、第１の発明においては、図１にあるように、トラヒックを観測したいネットワーク中継装置に３２ビットを超えるカウンタを内蔵し、一つは内部カウンタの値をあらかじめネットワーク管理サーバとネットワーク中継装置が合意した数だけ下位へビットシフトした３２ビット値を転送し、ネットワーク管理サーバにおいて合意した数だけ上位へビットシフトすることによって、カウンタラップが発生する問題を解決しようとするものである。
【０００９】
また、第２の発明においては、図２にあるように、内部カウンタの値に対してあらかじめネットワーク管理サーバとネットワーク中継装置が合意した数で除算を行い、カウンタの桁数を３２ビット以下へ減らし、ネットワーク管理サーバにおいて合意した数で乗算を行うことによってカウンタラップが発生する問題を解決しようとするものである。
【００１０】
また、第３の発明においては、図３にあるように、ネットワーク中継装置からネットワーク管理サーバへ下位３２ビットを転送した後、残りの上位ビットを転送し、ネットワーク管理サーバにおいてデータを連結し、カウンタラップが発生する問題を解決しようとするものである。
【００１１】
より具体的には、第１の発明に係るトラヒックデータ収集方法は、３２ビットを超えるトラヒックカウンタにより内部的にトラヒックデータを計測する機能を持つＩＰネットワーク中継機器と、当該中継機器のトラヒックデータをＳＮＭＰプロトコルによって取得可能なネットワーク管理サーバとが、通信回線によって接続されたネットワークにおいて、トラヒックデータ取得時に前記ネットワーク管理サーバが前記中継機器に対してトラヒックデータ取得操作を行う際に、前記トラヒックカウンタのオーバーフローを防ぐことによって正しくトラヒックデータを収集する方法であって、前記ネットワーク管理サーバからのトラヒックカウンタ値取得要求時に、前記中継機器は内部の３２ビットを超えるトラヒックカウンタをｎビット下位へビットシフトし、下位３２ビットをカウンタ値として前記ネットワーク管理サーバに通知し、この通知を受けた前記ネットワーク管理サーバは、前記中継機器から受信した３２ビットカウンタを上位へｎビットシフトし、下位ｎビットを０とした３２＋ｎビットのカウンタ値とすることを特徴とする。
【００１２】
この第１の発明に係るトラヒックデータ収集方法は、３２ビットを超えるトラヒックカウンタにより内部的にトラヒックデータを計測する機能を持つＩＰネットワーク中継機器と、当該中継機器のトラヒックデータをＳＮＭＰプロトコルによって取得可能なネットワーク管理サーバとが、通信回線によって接続されたネットワークにおいて、トラヒックデータ取得時に前記ネットワーク管理サーバが前記中継機器に対してトラヒックデータ取得操作を行う際に、前記トラヒックカウンタのオーバーフローを防ぐことによって正しくトラヒックデータを収集するシステムであって、前記中継機器は、前記ネットワーク管理サーバからのトラヒックカウンタ値取得要求時に、内部の３２ビットを超えるトラヒックカウンタをｎビット下位へビットシフトし、下位３２ビットをカウンタ値に変換して前記ネットワーク管理サーバに通知する変換処理手段を有し、前記ネットワーク管理サーバは、前記カウンタ値の通知を受けた際に、前記中継機器から受信した３２ビットカウンタを上位へｎビットシフトし、下位ｎビットを０とした３２＋ｎビットのカウンタ値に変換する変換処理手段を有することを特徴とするトラヒックデータ収集システムとして具体化することが可能である。
【００１３】
また、第２の発明に係るトラヒックデータ収集方法は、３２ビットを超えるトラヒックカウンタにより内部的にトラヒックデータを計測する機能を持つＩＰネットワーク中継機器と、当該中継機器のトラヒックデータをＳＮＭＰプロトコルによって取得できるネットワーク管理サーバとが、通信回線によって接続されたネットワークにおいて、トラヒックデータ取得時に前記ネットワーク管理サーバが前記中継機器に対してトラヒックデータ取得操作を行う際に、前記トラヒックカウンタのオーバーフローを防ぐことによって正しくトラヒックデータを収集する方法であって、前記ネットワーク管理サーバからのトラヒックカウンタ値取得要求時に、前記中継機器は、内部の３２ビットを超えるトラヒックカウンタをｍで除算し（ｍの２進数値ビット分、下位へビットシフトすることと同意）、除算した値をカウンタ値として前記ネットワーク管理サーバに通知し、この通知を受けた前記ネットワーク管理サーバは、前記中継機器から受信したカウンタをｍ倍し（ｍの２進数値ビット分、上位へビットシフトすることと同意）、下位ｍの２進数値分のビットを０としたカウンタ値とすることを特徴とする。
【００１４】
この第２の発明に係るトラヒックデータ収集方法は、３２ビットを超えるトラヒックカウンタにより内部的にトラヒックデータを計測する機能を持つＩＰネットワーク中継機器と、当該中継機器のトラヒックデータをＳＮＭＰプロトコルによって取得可能なネットワーク管理サーバとが、通信回線によって接続されたネットワークにおいて、トラヒックデータ取得時に前記ネットワーク管理サーバが前記中継機器に対してトラヒックデータ取得操作を行う際に、前記トラヒックカウンタのオーバーフローを防ぐことによって正しくトラヒックデータを収集するシステムであって、前記中継機器は、前記ネットワーク管理サーバからのトラヒックカウンタ値取得要求時に、内部の３２ビットを超えるトラヒックカウンタをｍ（ｍ：定数）で除算し、除算した値をカウンタ値として前記ネットワーク管理サーバに通知する変換処理手段を有し、前記ネットワーク管理サーバは、前記カウンタ値の通知を受けた際に、前記中継機器から受信したカウンタをｍ倍し、下位ｍの２進数値分のビットを０としたカウンタ値に変換する変換処理手段を有することを特徴とするトラヒックデータ収集システムとして具体化することが可能である。
【００１５】
また、第３の発明に係るトラヒックデータ収集方法は、３２ビットを超えるトラヒックカウンタにより内部的にトラヒックデータを計測する機能を持つＩＰネットワーク中継機器と、当該中継機器のトラヒックデータをＳＮＭＰプロトコルによって取得可能なネットワーク管理サーバとが、通信回線によって接続されたネットワークにおいて、トラヒックデータ取得時に前記ネットワーク管理サーバが前記中継機器に対してトラヒックデータ取得操作を行う際に、前記トラヒックカウンタのオーバーフローを防ぐことによって正しくトラヒックデータを収集する方法であって、前記ネットワーク管理サーバからのトラヒックカウンタ値取得要求時に、前記中継機器は内部の３２ビットを超えるトラヒックカウンタの下位３２ビットをまず前記ネットワーク管理サーバに通知し、次に残りの上位ビットを前記ネットワーク管理サーバへ通知し、この通知を受けた前記ネットワーク管理サーバは、前記中継機器から受信した最初の３２ビットのカウンタを下位３２ビットの値とし、次に受信した残りの上位ビットのカウンタ値を上位に連結するか、または上位３２ビットをまず前記ネットワーク管理サーバに通知し、次に残りの下位ビットを前記ネットワーク管理サーバに通知し、この通知を受けた前記ネットワーク管理サーバは、前記中継機器から受信した最初の３２ビットのカウンタを上位３２ビットの値とし、次に受信した残りの上位ビットのカウンタ値を下位へ連結することにより３２ビットを超えるトラヒックカウンタ値とすることを特徴とする。
【００１６】
この第３の発明に係るトラヒックデータ収集方法は、３２ビットを超えるトラヒックカウンタにより内部的にトラヒックデータを計測する機能を持つＩＰネットワーク中継機器と、当該中継機器のトラヒックデータをＳＮＭＰプロトコルによって取得可能なネットワーク管理サーバとが、通信回線によって接続されたネットワークにおいて、トラヒックデータ取得時に前記ネットワーク管理サーバが前記中継機器に対してトラヒックデータ取得操作を行う際に、前記トラヒックカウンタのオーバーフローを防ぐことによって正しくトラヒックデータを収集するシステムであって、前記中継機器は、前記ネットワーク管理サーバからのトラヒックカウンタ値取得要求時に、内部の３２ビットを超えるトラヒックカウンタの下位３２ビットをまず前記ネットワーク管理サーバに通知し、次に残りの上位ビットを前記ネットワーク管理サーバへ通知する変換処理手段を有し、前記ネットワーク管理サーバは、前記２つの部分からなる通知を受けた際に、前記中継機器から受信した最初の３２ビットのカウンタを下位３２ビットの値とし、次に受信した残りの上位ビットのカウンタ値を上位に連結することにより３２ビットを超えるトラヒックカウンタ値とする変換処理手段を有することを特徴とするトラヒックデータ収集システムとして具体化することが可能である。
【発明の効果】
【００１７】
本発明によれば、３２ビット分しかトラヒックカウンタを読み出せないＳＮＭＰｖ１用ネットワーク監視（管理）サーバにおいても、少ない変更、若干の測定誤差のみで将来増加するトラヒックに対応したトラヒック管理を行うことが可能となる。
換言すれば、本発明のトラヒック情報収集方法によれば、３２ビットずつカウンタの取得操作を行うことで、ＳＮＭＰｖ１のインターフェースを超えない範囲でカウンタの取得が可能になるため、新しいプロトコルにネットワーク中継装置とネットワーク管理サーバを対応させる必要がなく、増加するトラヒック量を管理することが可能となる。
【発明を実施するための最良の形態】
【００１８】
以下、添付の図面に示す好適実施形態に基づいて、本発明のトラヒック情報収集方法を詳細に説明する。なお、以下の説明中、数字列の後の(Bin)は２進数、(Dec)は１０進数であることを示している。
【００１９】
〔実施例１〕
監視対象機器（例えば、ルータ２０）が６４ビットカウンタを持ち、１０ビットシフトを行う場合：
（ａ）平均トラヒック長が900kbpsであった場合
ルータ２０は、時刻Ｔにおいて内部カウンタ（６４ビット）から値
10011100010000(Bin)=10、000(Dec)
を読み取り、これを１０ビット下位へビットシフトした値である
1001(Bin)=9(Dec)
をサーバ１０へ通知し、１０ビット上位へビットシフトして記録する。
【００２０】
時刻Ｔ＋１においては、同様に、
410、075、408（Dec）=11000011100010100000100010000(Bin)
を１０ビット下位へビットシフトした値、
1100001110001010000(Bin)=400,464(Dec)
を通知する。
サーバ１０は、この二つの値に基づいて、この期間に送られたトラヒック量を、次のように判断する。
【００２１】
＜オクテット数＞は、
1100001110001010000-1001＝1100001110001000111
ここで、
1100001110001000111
↓
１０ビット上位へビットシフト
↓
11000011100010001110000000000(Bin)＝410,065,920(Dec)
これから＜平均トラヒック量＞は、
(410,065,920／3600[sec.])×8＝911,257,6[bps]
となる。
【００２２】
（ｂ）平均トラヒック量が20Mbpsであった場合
図４にあるように、手順（１）にて、ルータ２０は時刻Ｔにおいて内部カウンタ（６４ビット）から値
10011100010000(Bin)=10,000(Dec)
を読み取り、これを１０ビット下位へビットシフトした値である
1001(Bin)＝9(Dec)
を手順（４）にてサーバ１０へ通知し、上位へ１０ビットシフトして記録する。
【００２３】
時刻T＋1においては、同様に、
9000010000(Dec)=1000011000011100010100000100010000(Bin)
を手順（６）にて１０ビット下位へビットシフトした値,
100001100001110001010000(Bin)=8,789,072(Dec)
を通知する。
サーバ１０は、この二つの値に基づいて、この期間に送られたトラヒック量を手順（８）にて１０ビット上位へビットシフトして、次のように判断する。
【００２４】
＜オクテット数＞（手順９）は、
100001100001110001010000-1001=100001100001110001000111
ここで、
100001100001110001000111
↓
１０ビット上位へビットシフト
↓
1000011000011100010001110000000000（Bin）=9,000,000,512(Dec)
これから＜平均トラヒック量＞は、
(9,000,000,512／3600[sec.])×8＝20,000,001.2[bps]
となる。
【００２５】
この結果には、わずかな誤差が含まれるが、実用的には全く問題ない。
本実施例によれば、わずかな変更、若干の測定誤差のみで、将来増加するトラヒックに対応したトラヒック管理を行うことが可能となる。
【００２６】
〔実施例２〕
監視対象機器（例えば、ルータ２０）が６４ビットカウンタを持ち、1,000で除する場合：
（ａ）平均トラヒック量が900kbpsであった場合
ルータ２０は、時刻Ｔにおいて内部カウンタ（６４ビット）から値10,000を読み取り、これを1,000で除した値である10をサーバ１０へ通知する。
時刻Ｔ＋１においては、同様に、410,075,408を1,000で除した値、410,075を通知する。
サーバ１０は、この二つの値に基づいて、この期間に送られたトラヒック量に1,000を乗じて次のように判断する。
【００２７】
これから、＜オクテット数＞は、
(410,075−10)×1,000＝410,065,000
＜平均トラヒック量＞は、
(410,065,000/3600[sec.])×8＝911,255[bps]
となる。
【００２８】
（ｂ）平均トラヒック量が20Mbpsであった場合
図５にあるように、手順（１）にてルータ２０は、時刻Ｔにおいて内部カウンタ（６４ビット）から値10,000を読み取り、これを1,000で除した値である10を手順（４）にてサーバ１０へ通知する。
時刻Ｔ＋１においては、同様に、手順（６）にて9,000,010,000を1,000で除した値、9,000,010を通知する。サーバ１０は、この二つの値に基づいて、この期間に送られたトラヒック量を、手順（８）にて1,000を乗じて、次のように判断する。
【００２９】
＜オクテット数＞（手順９）
(9,000,010−10)×1,000＝9,000,000,000
これから、＜平均トラヒック量＞は、
(9,000,000,000/3600[sec.])×8＝20,000,000[bps]
となる。
【００３０】
この結果にも、一部にわずかな誤差が含まれるが、実用的には全く問題ない。
本実施例によれば、わずかな変更、若干の測定誤差のみで、将来増加するトラヒックに対応したトラヒック管理を行うことが可能となる。
【００３１】
〔実施例３〕
監視対象機器（例えば、ルータ２０）が６４ビットカウンタを持ち、３２ビットずつ分割して送信する場合：
（ａ）平均トラヒック量が900kbpsであった場合
ルータ２０は、値
0000000000000000000000000000000000000000000000000010011100010000(Bin)
＝10,000(Dec)
を
00000000000000000000000000000000
と
00000000000000000010011100010000
との３２ビットずつに分割して、サーバ１０へ通知する。
【００３２】
時刻Ｔ＋１においては，同様に，410,075,408を
00000000000000000000000000000000
と
00011000011100010100000100010000
とに分割して通知する。
サーバ１０は，この二つの値を連結して，この期間に送られたトラヒック量を，次のように判断する。
【００３３】
＜オクテット数＞
00000000000000000000000000000000 00011000011100010100000100010000
-00000000000000000000000000000000 00000000000000000010011100010000
=11000011100010001101000000000(Bin)=410,065,408(Dec)
これから、＜平均トラヒック量＞は、
(410,065,408/3600[sec.])×8=911278.4[bps]
となる。
【００３４】
（ｂ）平均トラヒック量が20Mbpsであった場合
図６にあるように，手順（１）にて，ルータは時刻Ｔにおいて内部カウンタ（６４ビット）から値
0,000000000000000000000000000000000000000000000000010011100010000(Bin)
=10,000(Dec)
を読み取り，これを
00000000000000000000000000000000
と
00000000000000000010011100010000
との３２ビットずつに分割して、手順（４）にてサーバ１０へ通知する。
【００３５】
時刻Ｔ＋1においては、同様に、9,000,010,000(Dec)を
00000000000000000000000000000010
と
00011000011100010100000100000000
とに分割して手順（６）にて通知する。
サーバ１０は、この二つの値を手順（８）にて連結して、この期間に送られたトラヒック量を次のように判断する。
【００３６】
＜オクテット数＞（手順９）
00000000000000000000000000000010 00011000011100010100000100000000
-00000000000000000000000000000000 00000000000000000010011100010000
=00000000000000000000000000000010 00011000011100010001101000000000
(Bin)
=9,000,000,000(Dec)
これから、＜平均トラヒック量＞は、
(9,000,000,000/3600[sec.])×8=20,000,000[bps]
となる。
【００３７】
この結果にも、わずかな誤差が含まれるが、実用的には全く問題ない。
本実施例によれば、わずかな変更、若干の測定誤差のみで、将来増加するトラヒックに対応したトラヒック管理を行うことが可能となる。
【００３８】
なお、上記各実施例は、いずれも一例を示したものであり、本発明はこれらに限定されるべきものではなく、また、本発明の趣旨を逸脱しない範囲内で、適宜の変更・改良を行ってもよいこともいうまでもないことである。
【図面の簡単な説明】
【００３９】
【図１】本発明に係るトラヒックデータの収集方法およびそのシステムの第１の形態を説明する図である。
【図２】本発明に係るトラヒックデータの収集方法およびそのシステムの第２の形態を説明する図である。
【図３】本発明に係るトラヒックデータの収集方法およびそのシステムの第３の形態を説明する図である。
【図４】本発明の第１の実施例に係るトラヒックデータの収集方法の動作を説明する図である。
【図５】本発明の第２の実施例に係るトラヒックデータの収集方法の動作を説明する図である。
【図６】本発明の第３の実施例に係るトラヒックデータの収集方法の動作を説明する図である。
【図７】従来技術の一構成例を示す図である。
【図８】従来技術における動作説明図である。
【図９】従来技術における動作時の問題点について説明する図である。
【符号の説明】
【００４０】
１０  （ネットワーク管理）サーバ
２０  ルータ（中継機器）
【図１】
2005151243.tif 000003
【図２】
2005151243.tif 000004
【図３】
2005151243.tif 000005
【図４】
2005151243.tif 000006
【図５】
2005151243.tif 000007
【図６】
2005151243.tif 000008
【図７】
2005151243.tif 000009
【図８】
2005151243.tif 000010
【図９】
2005151243.tif 000011