JP3781663B2 - トラヒック情報収集装置およびトラヒック情報収集方法およびプログラムおよび記録媒体 - Google Patents
トラヒック情報収集装置およびトラヒック情報収集方法およびプログラムおよび記録媒体 Download PDFInfo
- Publication number
- JP3781663B2 JP3781663B2 JP2001356362A JP2001356362A JP3781663B2 JP 3781663 B2 JP3781663 B2 JP 3781663B2 JP 2001356362 A JP2001356362 A JP 2001356362A JP 2001356362 A JP2001356362 A JP 2001356362A JP 3781663 B2 JP3781663 B2 JP 3781663B2
- Authority
- JP
- Japan
- Prior art keywords
- information
- request
- packet
- traffic information
- node
- 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)
Description
【０００１】
【発明が属する技術分野】
本発明は、ＩＰパケット転送装置ならびに装置管理システムから構成されるＩＰ通信網に利用する。特にトラヒック情報の収集技術に関する。
【０００２】
【従来の技術】
ＩＰ通信網では、従来のベストエフォートサービスに加えて、Ｄｉｆｆｓｅｒｖ網(Differentiated Services:Blake, S., Black, D., Carlson, M.,Davies, E., Wang, Z. and W. Weiss,“An Architecture for Differentiated Services”, IETF RFC 2475, December 1998)のように、パケットに優先順位を設け、網内で優先制御を行うことにより、高い優先度のパケットの廃棄率等を低く抑えて品質を確保するような、優先順位に基づく複数のサービスクラスの導入が始まりつつある。このような複数のサービスクラスから構成されるマルチサービス網においては、その利用者が通信を行う時点で実際のトラヒック情報を取得し、それに基づきサービスクラスを選択する必要がある。ここでトラヒック情報とは通信経路上の各リンクのサービスクラス毎の占有帯域と定義し、占有帯域はＩＰパケット転送装置において１秒間に転送された各パケットのデータサイズの総和に相当する。
【０００３】
ＩＰ通信網のトラヒック情報を利用者が収集する手段として既に多くのソフトウェアが開発されている。例えば、ＵＮＩＸ Ｍａｇａｚｉｎｅ １９９８年５月号 ｐｐ１３−２０ “ネットワーク管理（３）”の記事で紹介されているＰａｔｈｃｈａｒというソフトウェアは、利用者が自らデータサイズの異なる複数の観測用パケットを送出し、その観測用パケットの到着間隔を測定することにより、経路情報のトラヒック状態を推定するものである。研究開発での利用を主目的とした全世界レベルの広域ＩＰ通信網であるＴｈｅ Ｉｎｔｅｒｎｅｔにおいては、全ての通信装置を監視する管理システムの導入は不可能であるという観点からは効果的な手法であるが、一般にこの種のトラヒック情報収集方式は、正確な情報を推定するために何回も観測用パケットを送出する必要があるため、計測自体がＩＰ通信網への負荷をかけてしまい正確性の限界があるとともに、商用のＩＰ通信網においてはトラヒック情報収集のための料金が余計にかかってしまうという問題点がある。
【０００４】
一方、商用のＩＰ通信網においては、通信装置を監視する管理システムが配備され、各通信装置が計測しているトラヒック情報、もしくは専用の監視装置が保持するトラヒック情報を、統合管理する方式が一般に用いられている。例えば、特開２００１−９４５７３号公報では、通信装置間の回線を通過するパケットを伝送信号レベルで分岐して取得し、専用の計測装置で分岐して取得したトラヒック情報を格納する方式が開示されており、また、特開平１０−２００５２９号公報では、複数の通信装置が計測しているトラヒック情報を通信装置毎の通信手段を用いて集中型の管理システムに集約する方式が開示されており、また、特開２００１−６９１７０号公報では、特開２００１−９４５７３号公報と同等の計測装置に加え、計測装置の情報を加工することでＩＰ通信網のトラヒック状態を予測する評価装置を導入したトラヒック情報収集の方式が開示されている。これらの方式は基本的には、SNMP(Simple Network Management System:Case, J., Fedor, M., Schoffstall, M. and J. Davin, “Simple Network Management Protocol”, IETF RFC 1157, May 1990)で規定されるシステムモデルに基づくものであり、管理対象となる各通信装置に対応する管理エージェントが、該当通信装置のトラヒック情報を含む管理情報を収集し、集中型の管理マネージャが複数の管理エージェントの情報をＳＮＭＰと呼ばれる管理プロトコルを用いて収集するものである。図１１は本動作を示す図であり、管理マネージャであるオペレーションサポートシステム(Operation Support System（ＯＳＳ）)が１９に対応し、管理エージェントは２４〜２８の通信ノードに実装されており、ユーザ端末１１もしくはネットワーク管理端末１３の要求に基づき、ＯＳＳ１９は、ＳＮＭＰを利用して２４〜２８の通信ノードに実装される管理エージェントが保持するトラヒック情報を収集する動作を示している。本方式は、特別な観測パケットを用いることなく外部からトラヒック情報を観測するため、正確な情報を収集することが可能であるが、各装置毎の情報を集中型の管理システムで集約して保持する必要があるため、ＩＰ通信網の利用者から個々にトラヒック情報の取得要求に対し管理システムの処理負荷が集中する、さらにはトラヒック情報集約のための管理プロトコル処理により管理システムの処理負荷が集中する等の問題点がある。
【０００５】
【発明が解決しようとする課題】
上述した従来のシステムでは、次のような問題点がある。第１の問題点は、トラヒック情報収集のためのオーバヘッドが大きいということである。その理由は、観測パケットを用いる手法では複数の観測パケットを用いる必要があるためであり、管理マネージャを用いる手法では通信装置から情報をアクセスするための管理プロトコルを用いる必要があるためである。
【０００６】
第２の問題点は、ＩＰ通信網の利用者がサービスクラスを選択するためのトラヒック情報収集の負荷が大きいということである。その理由は、観測パケットを用いる手法では、サービスクラス毎に複数の観測パケットを用いる必要があるためであり、管理マネージャを用いる手法では管理マネージャへの負荷が集中してしまうためである。各利用者がＩＰパケット転送装置をＳＮＭＰを用いてアクセスする手法も考えらるが、この場合は、ＩＰパケット転送装置の運用保守の観点から利用者認証およびアクセス制御等の処理を行う必要があり、各ＩＰパケット転送装置への負荷が大きくなってしまう。
【０００７】
本発明は、このような背景に行われたものであって、トラヒック情報収集のために特別な観測パケットを用いたり、トラヒック情報収集のための特別な通信プロトコルを必要とすることがなく、ＩＰ通信網の利用者に対してサービスクラス毎のトラヒック情報を容易かつ高速に提供可能とし、かつこれを実現する際に、特定のシステムに対して集中的な処理負荷を与えることがないトラヒック情報収集装置およびトラヒック情報収集方法およびプログラムおよび記録媒体を提供することを目的とする。
【０００８】
【課題を解決するための手段】
本発明は、ＩＰ通信網を構成する通信装置を、トラヒック情報の検索経路の始点となる要求受付ノード、中間点となる要求中継ノード、終点となる要求終端ノードから構成したことを特徴としている。
【０００９】
トラヒック情報収集の要求を行うユーザ端末もしくはネットワーク管理端末の要求は、要求受付ノードに送出され、要求受付ノードでは、通信装置内でのトラヒック情報収集を指示する情報要求パケットを生成し、自ノードでのトラヒック情報を収集するとともに、経路上の隣接する要求中継ノードに対して情報要求パケットを転送する。
【００１０】
要求中継ノードでは、自ノードでのトラヒック情報を収集し、収集した情報を情報回答パケットとして要求受付ノードに送出するとともに、経路上の隣接する要求中継ノードに対して情報要求パケットを転送する。情報要求パケットが、要求終端ノードに到着すると、要求終端ノードでは、自ノードでのトラヒック情報を収集し、収集した情報を情報回答パケットとして要求受付ノードに送出するとともに、受信した情報要求パケットの廃棄を行うことで、情報収集の処理が終了する。
【００１１】
したがって、トラヒック情報を推定するための観測用パケットや特別な管理プログラムを用いることなくトラヒック情報収集を可能とし、要求受付ノード、要求中継ノード、要求終端ノードでトラヒック情報収集の処理を分散化しているため、サービスクラス毎の大量な情報を集中的な負荷をかけることなく分散的に収集および加工処理することが可能となるという効果が得られる。
【００１２】
すなわち、本発明の第一の観点はトラヒック情報収集装置であって、本発明の特徴とするところは、ＩＰ通信網における特定の２点間のトラヒック情報収集の要求を行うユーザ端末もしくはネットワーク管理端末からのトラヒック情報収集の要求を受信する手段と、この受信する手段により受信した前記要求にしたがって隣接する他通信装置へ前記要求を含む情報要求パケットを送信する手段と、前記隣接する他通信装置から自装置以外の複数の通信装置のトラヒック情報が書込まれた情報回答パケットを受信する手段と、自装置内のトラヒック情報および受信した前記情報回答パケットに書込まれたトラヒック情報をとりまとめる手段と、前記トラヒック情報収集を要求した前記端末に前記とりまとめる手段がとりまとめた統括的なトラヒック情報を含む情報回答パケットを送信する手段とを備えた要求受付ノードと、前記情報要求パケットを受信する手段と、この受信する手段により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して前記要求受付ノードへこの作成した情報回答パケットを送信する手段と、前記情報要求パケットの送信元以外の隣接する他通信装置へ前記要求を含む情報要求パケットを転送する手段とを備えた要求中継ノードと、前記情報要求パケットを受信する手段と、この受信する手段により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して前記要求受付ノードへこの作成した情報回答パケットを送信する手段と、受信した情報要求パケットを廃棄する手段とを備えた要求終端ノードとを備えたところにある。前記トラヒック情報は、サービスクラス毎のリンク容量を含むことが望ましい。
【００１３】
これにより、トラヒック情報収集のために特別な観測パケットを用いたり、トラヒック情報収集のための特別な通信プロトコルを必要とすることがなく、また、ＩＰ通信網の利用者に対して、サービスクラス毎のトラヒック情報を容易かつ高速に提供可能とし、かつこれを実現する際に、特定のシステムに対して集中的な処理負荷を与えることがない。
【００１４】
前記情報要求パケットにはホップ数フィールドが設けられ、前記情報要求パケットを送信する手段は、情報要求パケット生成時に前記ホップ数フィールドに初期値を与える手段を備え、前記情報要求パケットを転送する手段は、転送する毎に前記ホップ数フィールドの値を１増加させる手段を備え、前記情報回答パケットを送信する手段は、受信した情報要求パケットの前記ホップ数フィールドのホップ数情報を当該情報要求に対する情報回答パケットに書込む手段を備えることが望ましい。
【００１５】
これにより、要求受付ノードでは、情報回答パケットに書込まれたホップ数から情報回答パケットの経路上の順番を再現することができる。したがって、欠落しているトラヒック情報を検出することができる。欠落しているトラヒック情報については再収集を行う等の対策を実施することができるため、正確なトラヒック情報を収集することができる。
【００１６】
前記情報要求パケットを送信する手段は、情報要求パケットに対して要求ごとの識別情報を付与する手段を備え、前記情報回答パケットを送信する手段は、受信した情報要求パケットの前記識別情報を当該情報要求に対する情報回答パケットに書込む手段を備えることが望ましい。
【００１７】
これにより、要求受付ノードでは、情報回答パケットに書込まれた識別情報により、受信した複数の情報回答パケットがいずれの情報要求に対する回答であるかを識別できるため、複数のユーザ端末もしくはネットワーク管理端末からのトラヒック情報収集の要求を同時に処理することができ、効率の良い運用を行うことができる。
【００１８】
前記情報回答パケットには最終ノードフラグが設けられ、前記要求終端ノードは、当該最終ノードフラグを設定する手段を備えることが望ましい。
【００１９】
これにより、要求受付ノードでは、情報要求パケットが要求終端ノードまで誤り無く到達したか否かを確認することができるため、情報収集が完了したか未完了かを識別することができる。したがって、トラヒック情報収集処理の失敗を検出することができ、もし、失敗を検出した場合には再度、情報要求パケットを送信する等の処理を行うことができるため、確実なトラヒック情報収集を行うことができる。
【００２０】
前記情報要求パケットおよび前記情報回答パケットは、ＩＣＭＰ(Internet Control Message Protocol)パケットとして転送されることが望ましい。
【００２１】
ＩＣＭＰパケットとは、ＩＰデータグラム配送時に経路上のゲートウェイで発生したＩＰデータグラム転送処理の障害を、送信ホストに対して通知するために開発されたプロトコルを用いるパケットである。情報要求パケットおよび情報回答パケットにこのＩＣＭＰパケットを用いることにより、これらのパケットは特別なプロトコルを用いることなく、実通信と同一経路にしたがって転送されるために経路変更に柔軟に追従可能であり、実通信に沿った有効なトラヒック情報収集を行うことができる。さらに、多数の観測パケットを用いる従来方式と比較して、適切なコストでトラヒック情報収集を行うことができる。
【００２２】
本発明の第二の観点はトラヒック情報収集方法であって、本発明の特徴とするところは、ＩＰ通信網における特定の２点間のトラヒック情報収集の要求を行うユーザ端末もしくはネットワーク管理端末からのトラヒック情報収集の要求を受信して隣接する他通信装置へ前記要求を含む情報要求パケットを送信するとともに前記隣接する他通信装置から自装置以外の複数の通信装置のトラヒック情報が書込まれた情報回答パケットを受信し、自装置内のトラヒック情報および受信した前記情報回答パケットに書込まれたトラヒック情報をとりまとめて前記トラヒック情報収集を要求した前記端末に統括的なトラヒック情報を含む情報回答パケットを送信する要求受付ノードを配置し、前記情報要求パケットを受信して自装置内のトラヒック情報により情報回答パケットを作成して前記要求受付ノードへこの作成した情報回答パケットを送信するとともに前記情報要求パケットの送信元以外の隣接する他通信装置へ前記要求を含む情報要求パケットを転送する要求中継ノードを配置し、前記情報要求パケットを受信して自装置内のトラヒック情報により情報回答パケットを作成して前記要求受付ノードへこの作成した情報回答パケットを送信するとともに受信した情報要求パケットを廃棄する要求終端ノードを配置し、前記要求受付ノードおよび前記要求中継ノードおよび前記要求終端ノードの連携により自律分散的にＩＰ通信網における特定の２点間のトラヒック情報の収集を行うところにある。
【００２３】
本発明の第三の観点はプログラムであって、本発明の特徴とするところは、情報処理装置にインストールすることにより、その情報処理装置に、ＩＰ通信網における特定の２点間のトラヒック情報の収集を行う機能を実現させ、この収集を行う機能として、前記トラヒック情報収集の要求を行うユーザ端末もしくはネットワーク管理端末からのトラヒック情報収集の要求を受信する機能と、この受信する機能により受信した前記要求にしたがって隣接する他通信装置へ前記要求を含む情報要求パケットを送信する機能と、前記隣接する他通信装置から自装置以外の複数の通信装置のトラヒック情報が書込まれた情報回答パケットを受信する機能と、自装置内のトラヒック情報および受信した前記情報回答パケットに書込まれたトラヒック情報をとりまとめる機能と、前記トラヒック情報収集を要求した前記端末に前記とりまとめる機能がとりまとめた統括的なトラヒック情報を含む情報回答パケットを送信する機能とを備えた要求受付ノードに相応する機能と、前記情報要求パケットを受信する機能と、この受信する機能により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して前記要求受付ノードへこの作成した情報回答パケットを送信する機能と、前記情報要求パケットの送信元以外の隣接する他通信装置へ前記要求を含む情報要求パケットを転送する機能とを備えた要求中継ノードに相応する機能と、前記情報要求パケットを受信する機能と、この受信する機能により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して前記要求受付ノードへこの作成した情報回答パケットを送信する機能と、受信した情報要求パケットを廃棄する機能とを備えた要求終端ノードに相応する機能とを実現させるところにある。
【００２４】
本発明の第四の観点は、本発明のプログラムが記録された前記情報処理装置読取可能な記録媒体である。本発明のプログラムは本発明の記録媒体に記録されることにより、前記情報処理装置は、この記録媒体を用いて本発明のプログラムをインストールすることができる。あるいは、本発明のプログラムを保持するサーバからネットワークを介して直接前記情報処理装置に本発明のプログラムをインストールすることもできる。
【００２５】
これにより、コンピュータ装置等の情報処理装置により、トラヒック情報収集のために特別な観測パケットを用いたり、トラヒック情報収集のための特別な通信プロトコルを必要とすることがなく、ＩＰ通信網の利用者に対してサービスクラス毎のトラヒック情報を容易かつ高速に提供可能とし、かつこれを実現する際に、特定のシステムに対して集中的な処理負荷を与えることがない、トラヒック情報収集を実現することができる。
【００２６】
【発明の実施の形態】
本発明実施例のトラヒック情報収集装置を図１ないし図１０を参照して説明する。図１は本発明の実施形態の構成を示すブロック図である。図２は要求受付ノードの内部構成を示すブロック図である。図３は要求中継ノードの内部構成を示すブロック図である。図４は要求終端ノードの内部構成を示すブロック図である。図５は情報要求パケットに格納される情報の例を示す図である。図６は情報回答パケットに格納される情報の例を示す図である。図７は本発明の実施形態のトラヒック情報収集手順を示すフローチャートである。図８は本発明の実施例におけるネットワーク構成例を示す図である。図９は実施例における各ルータからの情報回答パケットの内容例を示す図である。図１０は実施例における情報要求元への回答内容を示す図である。
【００２７】
本実施例はトラヒック情報収集装置であって、本実施例の特徴とするところは、図１および図２に示すように、ＩＰ通信網における特定の２点間のトラヒック情報収集の要求を行うユーザ端末１１もしくはネットワーク管理端末１３からのトラヒック情報収集の要求を受信する要求受付処理部４２と、この要求受付処理部４２により受信した前記要求にしたがって隣接する他通信装置へ前記要求を含む情報要求パケットを送信する情報要求パケット転送処理部４５と、前記隣接する他通信装置から自装置以外の複数の通信装置のトラヒック情報が書込まれた情報回答パケットを受信する情報回答パケット受付処理部４８と、自装置内のトラヒック情報および受信した前記情報回答パケットに書込まれたトラヒック情報をとりまとめて前記トラヒック情報収集を要求したユーザ端末１１もしくはネットワーク管理端末１３にとりまとめた統括的なトラヒック情報を含む情報回答パケットを送信する要求回答処理部４９とを備えた要求受付ノード１４と、図３に示すように、前記情報要求パケットを受信する情報要求パケット検出処理部５１と、この情報要求パケット検出処理部５１により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して要求受付ノード１４へこの作成した情報回答パケットを送信するトラヒック情報計測処理部５３および情報回答パケット作成処理部５４と、前記情報要求パケットの送信元以外の隣接する他通信装置へ前記要求を含む情報要求パケットを転送する情報要求パケット転送処理部５２とを備えた要求中継ノード１５、１６、１７と、図４に示すように、前記情報要求パケットを受信する情報要求パケット検出処理部６１と、この情報要求パケット検出処理部６１により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して要求受付ノード１４へこの作成した情報回答パケットを送信するトラヒック情報計測処理部６３および情報回答パケット作成処理部６４と、受信した情報要求パケットを廃棄する情報要求パケット廃棄処理部６２とを備えた要求終端ノード１８とを備えたところにある。前記トラヒック情報は、図９および図１０に示すように、サービスクラス毎のリンク容量を含む。
【００２８】
図５に示すように、前記情報要求パケットにはホップ数フィールド７４が設けられ、要求受付ノード１４の情報要求パケット作成処理部４３は、情報要求パケット生成時にホップ数フィールド７４に初期値を与え、要求中継ノード１５、１６、１７の情報要求パケット転送処理部５２は、転送する毎にホップ数フィールド７４の値を１増加させ、要求中継ノード１５、１６、１７および要求終端ノード１８の情報回答パケット作成処理部５４、６４は、受信した情報要求パケットのホップ数フィールド７４のホップ数情報を当該情報要求に対する情報回答パケットに書込む。
【００２９】
また、図５に示すように、要求受付ノード１４の情報要求パケット作成処理部４３は、情報要求パケットに対して要求ごとの識別情報である検索ＩＤ７３を付与し、要求中継ノード１５、１６、１７および要求終端ノード１８の情報回答パケット作成処理部５４、６４は、受信した情報情報パケットの検索ＩＤ７３を当該情報要求に対する情報回答パケットに書込む。
【００３０】
また、図６に示すように、前記情報回答パケットには最終ノードフラグが設けられ、要求終端ノード１８の情報回答パケット作成処理部６４は、当該最終ノードフラグを設定する。
【００３１】
前記情報要求パケットおよび前記情報回答パケットは、ＩＣＭＰ(Internet Control Message Protocol)パケットとして転送される。
【００３２】
本実施例のトラヒック情報収集装置は、情報処理装置としてのコンピュータ装置により実現することができる。すなわち、コンピュータ装置にインストールすることにより、そのコンピュータ装置に、ＩＰ通信網における特定の２点間のトラヒック情報の収集を行う機能を実現させ、この収集を行う機能として、前記トラヒック情報収集の要求を行うユーザ端末１１もしくはネットワーク管理端末１３からのトラヒック情報収集の要求を受信する要求受付処理部４２に相応する機能と、この要求受付処理部４２に相応する機能により受信した前記要求にしたがって隣接する他通信装置へ前記要求を含む情報要求パケットを送信する情報要求パケット転送処理部４５に相応する機能と、前記隣接する他通信装置から自装置以外の複数の通信装置のトラヒック情報が書込まれた情報回答パケットを受信する情報回答パケット受付処理部４８に相応する機能と、自装置内のトラヒック情報および受信した前記情報回答パケットに書込まれたトラヒック情報をとりまとめて前記トラヒック情報収集を要求したユーザ１１もしくはネットワーク管理端末１３にとりまとめた統括的なトラヒック情報を含む情報回答パケットを送信する要求回答処理部４９に相応する機能とを備えた要求受付ノード１４に相応する機能と、前記情報要求パケットを受信する情報要求パケット検出処理部５１に相応する機能と、この情報要求パケット検出処理部５１に相応する機能により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して要求受付ノード１４へこの作成した情報回答パケットを送信するトラヒック情報計測処理部５３および情報回答パケット作成処理部５４に相応する機能と、前記情報要求パケットの送信元以外の隣接する他通信装置へ前記要求を含む情報要求パケットを転送する情報要求パケット転送処理部５２に相応する機能とを備えた要求中継ノード１５、１６、１７に相応する機能と、前記情報要求パケットを受信する情報要求パケット検出処理部６１に相応する機能と、この情報要求パケット検出処理部６１に相応する機能により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して要求受付ノード１４へこの作成した情報回答パケットを送信する情報回答パケット作成処理部６４に相応する機能と、受信した情報要求パケットを廃棄する情報要求パケット廃棄処理部６２に相応する機能とを備えた要求終端ノード１８に相応する機能とを実現させるプログラムをコンピュータ装置にインストールすることにより、このコンピュータ装置を用いて実現することができる。
【００３３】
本発明のプログラムは、本発明の記録媒体に記録されることにより、コンピュータ装置は、この記録媒体を用いて本発明のプログラムをインストールすることができる。あるいは、本発明のプログラムを保持するサーバからネットワークを介して直接コンピュータ装置に本発明のプログラムをインストールすることもできる。
【００３４】
これにより、コンピュータ装置により、トラヒック情報収集のために特別な観測パケットを用いたり、トラヒック情報収集のための特別な通信プロトコルを必要とすることがなく、ＩＰ通信網の利用者に対してサービスクラス毎のトラヒック情報を容易かつ高速に提供可能とし、かつこれを実現する際に、特定のシステムに対して集中的な処理負荷を与えることがないトラヒック情報収集装置を実現することができる。
【００３５】
以下では、本発明実施例をさらに詳細に説明する。
【００３６】
本発明の実施の形態について図面を参照して詳細に説明する。図１を参照すると、本発明の実施の形態は、ＩＰ通信を行うある２点間を示すユーザ端末１１、ユーザ端末１２と、ＩＰ通信網を構成し本発明を実施する要求受付ノード１４と、要求中継ノード１５〜１７と、要求終端ノード１８と、各通信ノードの管理システムであるＯＳＳ１９と、ＯＳＳ１９を利用して管理業務を行うためのネットワーク管理端末１３とから構成される。ここで、トラヒック情報収集の要求元は、ユーザ端末１１もしくはネットワーク管理端末１３であるものとし、トラヒック情報収集の要求は、要求受付ノード１４に送出されるものとする。
【００３７】
要求受付ノード１４は、ユーザ端末１１もしくはネットワーク管理端末１３からのトラヒック情報収集の要求を受信し、ユーザ認証等のセキュリティ関連処理を行うと共に、通信装置内でのトラヒック情報収集を指示する情報要求パケットを生成し、自ノードでのトラヒック情報を収集し、トラヒック情報を格納した情報回答パケットを作成するとともに、経路上の隣接する要求中継ノード１５に対して情報要求パケットを転送する。さらに、以降の要求中継ノード１５〜１７および要求終端ノード１８から送出された情報回答パケットを自ノード分とあわせて集約し、要求元であるユーザ端末１１もしくはネットワーク管理端末１３へのトラヒック情報収集要求の回答を作成して送出する処理を行う。
【００３８】
要求中継ノード１５〜１７は、隣接する要求受付ノード１４もしくは要求中継ノード１５〜１７から情報要求パケットを受信し、自ノードでのトラヒック情報を収集し、収集した情報を情報回答パケットとして要求受付ノード１４に送出するとともに、経路上で次に隣接する要求中継ノード（例えば、要求中継ノード１５の場合は要求中継ノード１６がこれに相当し、要求中継ノード１６の場合は要求中継ノード１７がこれに相当する）に対して情報要求パケットを転送する。
【００３９】
要求終端ノード１８は、隣接する要求中継ノード１７から情報要求パケットを受信し、自ノードでのトラヒック情報を収集し、収集した情報を情報回答パケットとして要求受付ノード１４に送出するとともに、受信した情報要求パケットの廃棄を行うことで、情報収集の処理要求の終端ノードを越えた伝播を防止する。
【００４０】
次に、図１の実施の形態におけるトラヒック情報収集手順を図７を参照して詳細に説明する。（ステップ１）要求受付処理では、トラヒック情報収集の要求を受付け、ユーザ認証等のセキュリティ処理を行う。（ステップ２）情報要求パケット作成処理では、各通信ノードに対するトラヒック情報収集の指示を行う情報要求パケットの生成を行う。情報要求パケットには、ユーザ端末等から受付けた情報収集要求の指定に基づきトラヒック情報を収集したいユーザ端末のアドレス（ソースアドレス、デスティネーションアドレス）等が格納される。
【００４１】
（ステップ３）情報要求パケット検出処理では、通信ノードの出力インタフェースにおいて情報要求パケットの検出を行う。検出方法としては、例えば、特定のＩＣＭＰタイプを持つＩＣＭＰパケットを使用することで、容易に検出が可能となる。情報要求パケットが検出されると、情報要求パケット転送処理（ステップ４）ならびに、トラヒック情報計測処理（ステップ５）の実行指示を行う。
【００４２】
（ステップ４）情報要求パケット転送処理の判断では、情報要求パケットに含まれるデスティネーション端末を調べ自ノードに隣接していない場合は、デスティネーションアドレスに至る経路上で隣接する通信ノードに向けて、情報要求パケットのホップ数を１つ増加させて情報要求パケットの転送を行う。
【００４３】
（ステップ５）トラヒック情報計測処理では、各出力インタフェース毎にサービスクラス毎のトラヒック情報を計測し、最新の情報をメモリに保持しており、情報要求パケット検出処理（ステップ３）からの指示により、サービスクラス毎のトラヒック情報を検索し、次ステップに情報を引渡す。
【００４４】
（ステップ６）情報回答パケット作成処理では、検索されたトラヒック情報ならびに、検索ＩＤとホップ数のフィールド値を用い、情報回答パケットの作成を行う。さらに、作成された情報回答パケットを、情報要求パケットのソースアドレスで指定される要求受付ノードへ送信する処理を行う。
【００４５】
（ステップ７）情報回答パケット受付処理では、経路上の各ノードからの情報回答パケットを検索ＩＤ毎に集約する。このとき、最終ノードフラグの立っているパケットのホップ数フィールド値から、経路上のノード数がわかるので、経路上の全てのノードからの回答パケットを受信するまで待ち、全てを受信した時点で次ステップへ移行する。一定時間内に経路上の全てのノードからの情報回答パケットが受信できない場合には、検索失敗の通知を次ステップに行う。
【００４６】
（ステップ８）要求回答処理では、ステップ７での情報回答パケットの受信結果から、サービスクラス毎の使用可能帯域を計算して要求元へ回答する。
【００４７】
（ステップ９）ステップ３と同一の処理を行う。（ステップ１０）ステップ５と同一の処理を行う。（ステップ１１）ステップ６と同一の処理を行う。（ステップ１２）ステップ４と同一の処理を行う。
【００４８】
（ステップ１３）情報要求パケット廃棄では、情報要求パケットに含まれるデスティネーション端末が自ノードに隣接しているため、情報要求パケットの廃棄を行い、これ以上の情報要求パケットの転送を防止する。
【００４９】
ここで、上記のステップ４ならびにステップ９〜１１は（処理グループＳ１４）、トラヒック情報を収集する経路における要求中継ノードならびに要求終端ノードの数分だけ、繰り返し（処理グループＳ１５のように）処理が行われることになる。
【００５０】
次に、図２を参照すると、図１に示す要求受付ノード１４の詳細が示されている。要求受付ノード４１は、要求受付処理部４２、情報要求パケット作成処理部４３、情報要求パケット検出処理部４４、情報要求パケット転送処理部４５、トラヒック情報計測処理部４６、情報回答パケット作成処理部４７、情報回答パケット受付処理部４８、要求回答処理部４９から構成される。それぞれの処理内容を説明する。
【００５１】
要求受付処理部４２では、要求元４１からのトラヒック情報収集の要求に対し、ユーザ認証等のセキュリティ対策を行い、情報収集の要求を受理すると、情報要求パケット作成処理部４３に対して、情報要求パケットを作成するよう指示する。要求元４１からのトラヒック情報収集の要求メッセージは、通信先（デスティネーション）のアドレスを含む。
【００５２】
情報要求パケット作成処理部４３では、図５に示すフォーマットの情報要求パケットを組み立て、経路情報にしたがって情報要求パケットを送出する。ここで、図５のソースアドレス７１には自ノードのアドレス、デスティネーションアドレス７２には、要求元からのトラヒック情報収集の要求メッセージ内の通信先アドレス、検索ＩＤ７３は要求受付ノードで一意になる値（たとえば０から始まるシーケンシャルな値）、ホップ数フィールド７４には“０”を設定する。
【００５３】
情報要求パケット検出処理部４４は、自通信ノード出力インタフェースにおいて情報要求パケットの検出を行う。検出方法としては、例えば、特定のＩＣＭＰタイプを持つＩＣＭＰパケットを使用することで、容易に検出が可能となる。情報要求パケットが検出されると、トラヒック情報計測処理部４６に該当するトラヒック情報を検索するよう指示を行う。また、検索ＩＤとホップ数のフィールド値を情報回答パケット作成処理部４７に渡す。
【００５４】
情報要求パケット転送処理部４５では、情報要求パケットのホップ数を１つ増加させて、次の要求中継ノード１５〜１７または要求終端ノード１８に情報要求パケットを転送する。
【００５５】
トラヒック情報計測処理部４６では、自通信ノードのインタフェース毎にサービスクラス毎のトラヒック情報を計測し、最新の情報をメモリに保持する。情報要求パケット検出処理部４４より検索指示を受けると、サービスクラス毎のトラヒック情報を情報回答パケット作成処理部４７に渡す。
【００５６】
情報回答パケット作成処理部４７では、図６に示すフォーマットの情報回答パケットを作成する。図６において、検索ＩＤ８１とホップ数フィールド８２のフィールド値は情報要求パケット検出処理部４４から渡された値を入れ、最終ノードフラグ８３は立てない。リンク帯域８４ならびにサービスクラス毎の占有帯域８５、８６は、トラヒック情報計測処理部４６から渡された値を格納する。このように作成された情報回答パケットは、情報要求パケットのソースアドレスで指定される要求受付ノード（この場合は、自ノード）へ送出される。
【００５７】
情報回答パケット受付処理部４８では、経路上の各ノードからの情報回答パケットを検索ＩＤ毎に集約する。このとき、最終ノードフラグの立っているパケットのホップ数フィールド値から、経路上のノード数がわかるので、経路上の全てのノードからの回答パケットを受信すると、受信結果を要求回答処理部４９に渡す。一定時間内に経路上の全てのノードからの回答パケットが受信できない場合には、検索失敗通知を要求回答処理部４９に渡す。
【００５８】
要求回答処理部４９では、情報回答パケット受付処理部４８からの受信結果から、クラスごとの使用可能帯域を計算し、要求元４１へ回答する。
【００５９】
次に、図３を参照すると、図１に示す要求中継ノード１５〜１７の詳細が示されている。要求中継ノード１５〜１７は、情報要求パケット検出処理部５１、情報要求パケット転送処理部５２、トラヒック情報計測処理部５３、情報回答パケット作成処理部５４から構成される。それぞれの処理内容を説明する。
【００６０】
情報要求パケット検出処理部５１は、自通信ノードの出力インタフェースにおいて情報要求パケットの検出を行う。情報要求パケットが検出されると、トラヒック情報計測処理部５３の情報を検索するよう指示する。また、検索ＩＤとホップ数フィールドの値を情報回答パケット作成処理部５４に渡す。
【００６１】
情報要求パケット転送処理部５２では、情報要求パケットのホップ数を１つ増加させて、次の要求中継ノード１６、１７または要求終端ノード１８に情報要求パケットを転送する。
【００６２】
トラヒック情報計測処理部５３では、自通信ノードのインタフェース毎にサービスクラス毎のトラヒック情報を計測し、最新の情報をメモリに保持する。情報要求パケット検出処理部５１より検索指示を受けると、サービスクラス毎のトラヒック情報を情報回答パケット作成処理部５４へ渡す。
【００６３】
情報回答パケット作成処理部５４では、図６に示すフォーマットの情報回答パケットを作成する。検索ＩＤとホップ数フィールドの値は情報要求パケット検出処理部５１から渡された値を入れ、最終ノードフラグは立てない。作成された情報回答パケットは、情報要求パケットのソースアドレスで指定される要求受付ノードへ送出される。
【００６４】
次に、図４を参照すると、図１に示す要求終端ノード１８の詳細が示されている。要求終端ノード１８は、情報要求パケット検出処理部６１、情報要求パケット廃棄処理部６２、トラヒック情報計測処理部６３、情報回答パケット作成処理部６４から構成される。それぞれの処理内容を説明する。
【００６５】
情報要求パケット検出処理部６１は、自通信ノードの出力インタフェースにおいて情報要求パケットの検出を行う。情報要求パケットが検出されると、トラヒック情報計測処理部６２の情報を検索するよう指示する。また、検索ＩＤとホップ数フィールドの値を情報回答パケット作成処理部６４に渡す。情報要求パケット廃棄処理部６２では、情報要求パケットを廃棄する。
【００６６】
トラヒック情報計測処理部６３では、自通信ノードのインタフェース毎にサービスクラス毎のトラヒック情報を計測し、最新の情報をメモリに保持する。情報要求パケット検出処理部６１より検索指示を受けると、サービスクラス毎のトラヒック情報を情報回答パケット作成処理部６４へ渡す。
【００６７】
情報回答パケット作成処理部６４では、図６に示すフォーマットの回答パケットを作成する。検索ＩＤとホップ数フィールドの値は情報要求パケット検出処理部６１から渡された値を入れ、最終ノードフラグを立てる。作成された情報回答パケットは、情報要求パケットのソースアドレスで指定される要求受付ノードへ送出される。
【００６８】
次に、本発明の実施例について図面を参照して詳細に説明する。図８を参照すると、実施例におけるＩＰ通信網の例が示されており、ユーザ端末１１とユーザ端末１２との間には、要求受付ノード１４としての加入者収容装置Ａ、要求中継ノード１５〜１７としてのルータＡ、ルータＢ、ルータＣ、要求終端ノード１８としての加入者収容装置Ｂから構成され、各装置はＯＳＳ１９を介して、ネットワーク管理端末１３によって管理されている。
【００６９】
ＩＰ通信網は複数のサービスクラスを提供するマルチサービス網であり、提供されるサービスクラスは３種類（クラス３、クラス２、クラス１）、優先度がクラス３＞クラス２＞クラス１の順に設定され、クラス３の通信が最優先されるものとする。各サービスクラスはデータ量に対して課金される従量課金制、各クラスの料金（データ量単価）はクラス３＞クラス２＞クラス１の順に設定され、クラス３の料金が一番高く設定されているものとする。
【００７０】
ここで、ユーザ端末１１のユーザＡが、ユーザ端末１２のユーザＢと通信するために、ユーザ端末１１からユーザ端末１２までの間のトラヒック情報を得たい場合には、ユーザ端末１１から加入者収容装置Ａに対してトラヒック情報要求を送出する。トラヒック情報要求には、デスティネーションアドレス（ユーザ端末１２のアドレス）を指定して要求を行う。
【００７１】
加入者収容装置Ａは、要求受付ノード１４として動作する。加入者収容装置Ａは、ユーザ端末１１からのトラヒック情報要求に対してユーザ認証を行う。ユーザ認証の方法としては、ユーザＩＤとパスワードの利用や、ユーザＡのＩＰアドレスのチェック等を用いる。トラヒック情報要求が受理されると、情報要求パケットを作成し、設定されているルーティングテーブルにしたがって出力インタフェースに転送する。出力インタフェースでは、情報要求パケットの検出を行い、出力インタフェースのトラヒック情報の検索を行う。
【００７２】
情報要求パケットは、情報要求パケット転送処理部４５にてホップ数を１つインクリメントされる（ホップ数１）。情報要求パケットは出力インタフェースよりルータＡへ送出される。
【００７３】
経路上にあるルータＡ、ルータＢ、ルータＣはそれぞれ要求中継ノード１５〜１７として動作する。ルータＡでは、加入者収容装置Ａからの情報要求パケットを、設定されているルーティングテーブルにしたがって出力インタフェースに転送する。出力インタフェースでは、情報要求パケットの検出を行い、出力インタフェースのトラヒック情報の検索を行う。情報要求パケットは、情報要求パケット転送処理部５２にてホップ数を１つインクリメントされる（ホップ数２）。情報要求パケットは出力インタフェースよりルータＢへ送出される。情報回答パケット作成処理部５４では、トラヒック情報の検索結果と、情報要求パケット検出処理部５１で抽出された検索ＩＤ、ホップ数（ここではホップ数１）、あらかじめ設定されているリンク帯域を図６に示す情報回答パケットとして作成し、加入者収容装置Ａに回答する。ルータＢではルータＡと同様の処理を行い、情報要求パケットをルータＣへ転送する。ルータＣも同様の処理を行い、情報要求パケットを加入者収容装置Ｂに転送する。
【００７４】
ユーザ端末１２を収容している加入者収容装置Ｂは、要求終端ノード１８として動作する。加入者収容装置Ｂでは、ルータＣより転送された情報要求パケットを、設定されているルーティングテーブルにしたがって出力インタフェースに転送する。出力インタフェースでは、要求パケットの検出を行い、出力インタフェースのトラヒック情報の検索を行う。情報要求パケットは情報要求パケット廃棄処理部６２にて廃棄される。情報回答パケット作成処理部６４では、トラヒック情報の検索結果と、要求パケット検出部で抽出された検索ＩＤ、ホップ数（ここではホップ数４）、あらかじめ設定されているリンク帯域を図６に示す情報回答パケットとして作成し、加入者収容装置Ａに回答する。このとき、情報回答パケットの最終ノードフラグには“１”が立てられている。
【００７５】
各ノード（１４〜１８）からの回答は加入者収容装置Ａの情報回答パケット受付処理部４８にて集約される。ここで、最終ノードフラグの検出を行い、最終ノードフラグの検出されたパケットからホップ数を抽出する。ここではホップ数４が抽出されるので、ホップ数０、ホップ数１、ホップ数２、ホップ数３の回答パケットが受信されていることを確認する。ここで、加入者収容装置Ａではあらかじめ決められた時間内に回答パケットが受信されるものとし、時間内に最終ノードフラグが検出されない場合または経路途中のホップ数のパケットが受信されない場合は情報要求パケットまたは情報回答パケットが廃棄されたものとして、検索失敗を通知する。加入者収容装置Ａの要求回答処理部４９では、受信した情報回答パケットの回答内容から、トラヒック情報の回答をユーザ端末１１に送る。例えば、情報回答パケットの回答内容が図９のような場合（ホップ０は加入者収容装置Ａのトラヒック情報検索結果）、ユーザ端末１１に対しての回答は各クラスの使用可能帯域（その帯域でデータ通信してもパケット廃棄されることなく相手端末までデータ転送が可能な最大帯域）を通知することとすると、ユーザ端末１１からユーザ端末１２までの経路上でのリンク容量は、全ホップ中での最小の容量となり、各クラスの使用可能帯域は各ホップにおけるリンク占有可能帯域の最小のものとなるため、図１０のようになる。図９の例において、例えばクラス２についてはホップ２においてリンク占有可能帯域が最小となり、その値は、空き帯域（３０）を含むクラス２より低位クラスの占有帯域の合計（３０＋１０）となる。
【００７６】
本実施例のサービスへの適用例として、ストリーム通信サービスのように、ユーザが特定のスループットを要求するようなサービスの例について説明する。回答結果として図１０の結果を得たユーザが４０の帯域で通信したいと思うと、サービスクラスとしてクラス２を選択すれば４０の帯域が確保できることがわかる。ここで、クラス１を選択すると、４０の帯域は確保できないので要求される品質を提供できない。また、クラス３を選択すると要求帯域は確保できるが、通信コストが多くかかることとなる。
【００７７】
また、別のサービスへの適用例としてバルク通信サービスのような、ユーザが帯域を可変できるサービスの例について説明する。ユーザはクラス１の料金で通信をしたいのだが、使用可能な帯域はどれくらいか知るためにトラヒック情報を要求する。このときの回答を図９のとおりとすると、ユーザは２０の帯域であればクラス１の料金でパケット廃棄されることなく通信できることがわかる。ここで、３０の帯域でデータ送信する場合には、すべてのデータが相手に到達する保証はないため、通信コストを無駄にする可能性がある。
【００７８】
また、本実施例のサービスへの適用例として通信品質／通信料金に関する要求条件をユーザが指定し、ユーザＡＰがトラヒック情報を定期的に要求することにより、データ送出帯域や選択サービスクラスを自動制御するサービスも考えられる。
【００７９】
（実施例まとめ）
以上説明したように、本発明においては、次のような効果を奏する。
【００８０】
第１の効果は、トラヒック情報の推測のための特別な観測パケットや、トラヒック情報収集のための特別な通信プロトコルを必要とすることがない、ということにある。その理由は、各通信ノードにおいて管理格納されているトラヒック情報を、ＩＣＭＰ等を利用した情報要求パケットならびに情報回答パケットを用いて収集することを可能としたためである。
【００８１】
第２の効果は、ＩＰ通信網の利用者に対して、サービスクラス毎のトラヒック情報を容易かつ高速に提供可能とし、かつこれを実現する際に、特定のシステムに対して集中的な処理負荷を与えることがない、ということにある。その理由は、各通信ノードにおいて情報要求パケットならびに情報回答パケットを処理する形態としたことにより、情報要求パケット１個と、ホップ数分の情報回答パケットのみの少ないパケット数で情報収集を可能としていることと、トラヒック情報収集処理を経路上の複数の通信ノードで分散処理するためである。さらに要求受付ノードで収容端末のトラヒック情報要求を受付け、ユーザ認証や結果集約等の処理を行うため、複数のＩＰ通信網利用者に対して分散的な処理を可能としたためである。
【００８２】
第３の効果は、要求中継ノードから個別に送信されてきた情報回答パケットの経路上の順番を、要求受付ノードにおいて再現することができることにある。その理由は、情報要求パケットにホップ数フィールドを設け、転送毎に１増加させ、情報回答パケットにコピーする処理を行っているためである。
【００８３】
第４の効果は、要求受付ノードは複数のユーザ端末もしくはネットワーク管理端末からの要求を、同時に処理することができることにある。その理由は、情報要求パケットにＩＤフィールドを設け、情報回答パケットにコピーする処理を行っているためである。
【００８４】
第５の効果は、ＩＰ網内でのパケット廃棄によるトラヒック情報収集処理の失敗を検出することができることにある。その理由は、情報回答パケットに最終ノードフラグを設け、要求終端ノードにおいてフラグを立てる処理を行っているためである。
【００８５】
第６の効果は、トラヒック情報収集が正確であり、ユーザ端末が適切なコストで通信を行うことができることにある。その理由は、情報要求パケットが実通信と同一経路に従って転送されるため、経路変更に柔軟に追従可能であり、情報収集結果を用いることによりパケット廃棄が発生しない帯域でデータ送出を行うことを可能としているためである。
【００８６】
【発明の効果】
以上説明したように、本発明によれば、トラヒック情報収集のために特別な観測パケットを用いたり、トラヒック情報収集のための特別な通信プロトコルを必要とすることがなく、ＩＰ通信網の利用者に対してサービスクラス毎のトラヒック情報を容易かつ高速に提供可能とし、かつこれを実現する際に、特定のシステムに対して集中的な処理負荷を与えることがない。
【図面の簡単な説明】
【図１】本発明の実施形態の構成を示すブロック図。
【図２】要求受付ノードの内部構成を示すブロック図。
【図３】要求中継ノードの内部構成を示すブロック図。
【図４】要求終端ノードの内部構成を示すブロック図。
【図５】情報要求パケットに格納される情報の例を示す図。
【図６】情報回答パケットに格納される情報の例を示す図。
【図７】本発明の実施形態のトラヒック情報収集手順を示すフローチャート。
【図８】本発明の実施例におけるネットワーク構成例を示す図。
【図９】実施例における各ルータからの情報回答パケットの内容例を示す図。
【図１０】実施例における情報要求元への回答内容を示す図。
【図１１】従来のトラヒック情報収集方式を説明するための図。
【符号の説明】
１１、１２ ユーザ端末
１３ ネットワーク管理端末
１４ 要求受付ノード
１５〜１７ 要求中継ノード
１８ 要求終端ノード
１９ オペレーションサポートシステム（ＯＳＳ）
２４〜２８ 通信ノード
４１ 要求元
４２ 要求受付処理部
４３ 情報要求パケット作成処理部
４４、５１、６１ 情報要求パケット検出処理部
４５、５２ 情報要求パケット転送処理部
４６、５３、６３ トラヒック情報計測処理部
４７、５４、６４ 情報回答パケット作成処理部
４８ 情報回答パケット受付処理部
４９ 要求回答処理部
６２ 情報要求パケット廃棄処理部
７１ ソースアドレス
７２ ディスティネーションアドレス
７３、８１ 検索ＩＤ
７４、８２ ホップ数フィールド
８３ 最終ノードフラグ
８４ リンク帯域
８５ クラスｘの占有帯域
８６ クラスｙの占有帯域
【発明が属する技術分野】
本発明は、ＩＰパケット転送装置ならびに装置管理システムから構成されるＩＰ通信網に利用する。特にトラヒック情報の収集技術に関する。
【０００２】
【従来の技術】
ＩＰ通信網では、従来のベストエフォートサービスに加えて、Ｄｉｆｆｓｅｒｖ網(Differentiated Services:Blake, S., Black, D., Carlson, M.,Davies, E., Wang, Z. and W. Weiss,“An Architecture for Differentiated Services”, IETF RFC 2475, December 1998)のように、パケットに優先順位を設け、網内で優先制御を行うことにより、高い優先度のパケットの廃棄率等を低く抑えて品質を確保するような、優先順位に基づく複数のサービスクラスの導入が始まりつつある。このような複数のサービスクラスから構成されるマルチサービス網においては、その利用者が通信を行う時点で実際のトラヒック情報を取得し、それに基づきサービスクラスを選択する必要がある。ここでトラヒック情報とは通信経路上の各リンクのサービスクラス毎の占有帯域と定義し、占有帯域はＩＰパケット転送装置において１秒間に転送された各パケットのデータサイズの総和に相当する。
【０００３】
ＩＰ通信網のトラヒック情報を利用者が収集する手段として既に多くのソフトウェアが開発されている。例えば、ＵＮＩＸ Ｍａｇａｚｉｎｅ １９９８年５月号 ｐｐ１３−２０ “ネットワーク管理（３）”の記事で紹介されているＰａｔｈｃｈａｒというソフトウェアは、利用者が自らデータサイズの異なる複数の観測用パケットを送出し、その観測用パケットの到着間隔を測定することにより、経路情報のトラヒック状態を推定するものである。研究開発での利用を主目的とした全世界レベルの広域ＩＰ通信網であるＴｈｅ Ｉｎｔｅｒｎｅｔにおいては、全ての通信装置を監視する管理システムの導入は不可能であるという観点からは効果的な手法であるが、一般にこの種のトラヒック情報収集方式は、正確な情報を推定するために何回も観測用パケットを送出する必要があるため、計測自体がＩＰ通信網への負荷をかけてしまい正確性の限界があるとともに、商用のＩＰ通信網においてはトラヒック情報収集のための料金が余計にかかってしまうという問題点がある。
【０００４】
一方、商用のＩＰ通信網においては、通信装置を監視する管理システムが配備され、各通信装置が計測しているトラヒック情報、もしくは専用の監視装置が保持するトラヒック情報を、統合管理する方式が一般に用いられている。例えば、特開２００１−９４５７３号公報では、通信装置間の回線を通過するパケットを伝送信号レベルで分岐して取得し、専用の計測装置で分岐して取得したトラヒック情報を格納する方式が開示されており、また、特開平１０−２００５２９号公報では、複数の通信装置が計測しているトラヒック情報を通信装置毎の通信手段を用いて集中型の管理システムに集約する方式が開示されており、また、特開２００１−６９１７０号公報では、特開２００１−９４５７３号公報と同等の計測装置に加え、計測装置の情報を加工することでＩＰ通信網のトラヒック状態を予測する評価装置を導入したトラヒック情報収集の方式が開示されている。これらの方式は基本的には、SNMP(Simple Network Management System:Case, J., Fedor, M., Schoffstall, M. and J. Davin, “Simple Network Management Protocol”, IETF RFC 1157, May 1990)で規定されるシステムモデルに基づくものであり、管理対象となる各通信装置に対応する管理エージェントが、該当通信装置のトラヒック情報を含む管理情報を収集し、集中型の管理マネージャが複数の管理エージェントの情報をＳＮＭＰと呼ばれる管理プロトコルを用いて収集するものである。図１１は本動作を示す図であり、管理マネージャであるオペレーションサポートシステム(Operation Support System（ＯＳＳ）)が１９に対応し、管理エージェントは２４〜２８の通信ノードに実装されており、ユーザ端末１１もしくはネットワーク管理端末１３の要求に基づき、ＯＳＳ１９は、ＳＮＭＰを利用して２４〜２８の通信ノードに実装される管理エージェントが保持するトラヒック情報を収集する動作を示している。本方式は、特別な観測パケットを用いることなく外部からトラヒック情報を観測するため、正確な情報を収集することが可能であるが、各装置毎の情報を集中型の管理システムで集約して保持する必要があるため、ＩＰ通信網の利用者から個々にトラヒック情報の取得要求に対し管理システムの処理負荷が集中する、さらにはトラヒック情報集約のための管理プロトコル処理により管理システムの処理負荷が集中する等の問題点がある。
【０００５】
【発明が解決しようとする課題】
上述した従来のシステムでは、次のような問題点がある。第１の問題点は、トラヒック情報収集のためのオーバヘッドが大きいということである。その理由は、観測パケットを用いる手法では複数の観測パケットを用いる必要があるためであり、管理マネージャを用いる手法では通信装置から情報をアクセスするための管理プロトコルを用いる必要があるためである。
【０００６】
第２の問題点は、ＩＰ通信網の利用者がサービスクラスを選択するためのトラヒック情報収集の負荷が大きいということである。その理由は、観測パケットを用いる手法では、サービスクラス毎に複数の観測パケットを用いる必要があるためであり、管理マネージャを用いる手法では管理マネージャへの負荷が集中してしまうためである。各利用者がＩＰパケット転送装置をＳＮＭＰを用いてアクセスする手法も考えらるが、この場合は、ＩＰパケット転送装置の運用保守の観点から利用者認証およびアクセス制御等の処理を行う必要があり、各ＩＰパケット転送装置への負荷が大きくなってしまう。
【０００７】
本発明は、このような背景に行われたものであって、トラヒック情報収集のために特別な観測パケットを用いたり、トラヒック情報収集のための特別な通信プロトコルを必要とすることがなく、ＩＰ通信網の利用者に対してサービスクラス毎のトラヒック情報を容易かつ高速に提供可能とし、かつこれを実現する際に、特定のシステムに対して集中的な処理負荷を与えることがないトラヒック情報収集装置およびトラヒック情報収集方法およびプログラムおよび記録媒体を提供することを目的とする。
【０００８】
【課題を解決するための手段】
本発明は、ＩＰ通信網を構成する通信装置を、トラヒック情報の検索経路の始点となる要求受付ノード、中間点となる要求中継ノード、終点となる要求終端ノードから構成したことを特徴としている。
【０００９】
トラヒック情報収集の要求を行うユーザ端末もしくはネットワーク管理端末の要求は、要求受付ノードに送出され、要求受付ノードでは、通信装置内でのトラヒック情報収集を指示する情報要求パケットを生成し、自ノードでのトラヒック情報を収集するとともに、経路上の隣接する要求中継ノードに対して情報要求パケットを転送する。
【００１０】
要求中継ノードでは、自ノードでのトラヒック情報を収集し、収集した情報を情報回答パケットとして要求受付ノードに送出するとともに、経路上の隣接する要求中継ノードに対して情報要求パケットを転送する。情報要求パケットが、要求終端ノードに到着すると、要求終端ノードでは、自ノードでのトラヒック情報を収集し、収集した情報を情報回答パケットとして要求受付ノードに送出するとともに、受信した情報要求パケットの廃棄を行うことで、情報収集の処理が終了する。
【００１１】
したがって、トラヒック情報を推定するための観測用パケットや特別な管理プログラムを用いることなくトラヒック情報収集を可能とし、要求受付ノード、要求中継ノード、要求終端ノードでトラヒック情報収集の処理を分散化しているため、サービスクラス毎の大量な情報を集中的な負荷をかけることなく分散的に収集および加工処理することが可能となるという効果が得られる。
【００１２】
すなわち、本発明の第一の観点はトラヒック情報収集装置であって、本発明の特徴とするところは、ＩＰ通信網における特定の２点間のトラヒック情報収集の要求を行うユーザ端末もしくはネットワーク管理端末からのトラヒック情報収集の要求を受信する手段と、この受信する手段により受信した前記要求にしたがって隣接する他通信装置へ前記要求を含む情報要求パケットを送信する手段と、前記隣接する他通信装置から自装置以外の複数の通信装置のトラヒック情報が書込まれた情報回答パケットを受信する手段と、自装置内のトラヒック情報および受信した前記情報回答パケットに書込まれたトラヒック情報をとりまとめる手段と、前記トラヒック情報収集を要求した前記端末に前記とりまとめる手段がとりまとめた統括的なトラヒック情報を含む情報回答パケットを送信する手段とを備えた要求受付ノードと、前記情報要求パケットを受信する手段と、この受信する手段により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して前記要求受付ノードへこの作成した情報回答パケットを送信する手段と、前記情報要求パケットの送信元以外の隣接する他通信装置へ前記要求を含む情報要求パケットを転送する手段とを備えた要求中継ノードと、前記情報要求パケットを受信する手段と、この受信する手段により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して前記要求受付ノードへこの作成した情報回答パケットを送信する手段と、受信した情報要求パケットを廃棄する手段とを備えた要求終端ノードとを備えたところにある。前記トラヒック情報は、サービスクラス毎のリンク容量を含むことが望ましい。
【００１３】
これにより、トラヒック情報収集のために特別な観測パケットを用いたり、トラヒック情報収集のための特別な通信プロトコルを必要とすることがなく、また、ＩＰ通信網の利用者に対して、サービスクラス毎のトラヒック情報を容易かつ高速に提供可能とし、かつこれを実現する際に、特定のシステムに対して集中的な処理負荷を与えることがない。
【００１４】
前記情報要求パケットにはホップ数フィールドが設けられ、前記情報要求パケットを送信する手段は、情報要求パケット生成時に前記ホップ数フィールドに初期値を与える手段を備え、前記情報要求パケットを転送する手段は、転送する毎に前記ホップ数フィールドの値を１増加させる手段を備え、前記情報回答パケットを送信する手段は、受信した情報要求パケットの前記ホップ数フィールドのホップ数情報を当該情報要求に対する情報回答パケットに書込む手段を備えることが望ましい。
【００１５】
これにより、要求受付ノードでは、情報回答パケットに書込まれたホップ数から情報回答パケットの経路上の順番を再現することができる。したがって、欠落しているトラヒック情報を検出することができる。欠落しているトラヒック情報については再収集を行う等の対策を実施することができるため、正確なトラヒック情報を収集することができる。
【００１６】
前記情報要求パケットを送信する手段は、情報要求パケットに対して要求ごとの識別情報を付与する手段を備え、前記情報回答パケットを送信する手段は、受信した情報要求パケットの前記識別情報を当該情報要求に対する情報回答パケットに書込む手段を備えることが望ましい。
【００１７】
これにより、要求受付ノードでは、情報回答パケットに書込まれた識別情報により、受信した複数の情報回答パケットがいずれの情報要求に対する回答であるかを識別できるため、複数のユーザ端末もしくはネットワーク管理端末からのトラヒック情報収集の要求を同時に処理することができ、効率の良い運用を行うことができる。
【００１８】
前記情報回答パケットには最終ノードフラグが設けられ、前記要求終端ノードは、当該最終ノードフラグを設定する手段を備えることが望ましい。
【００１９】
これにより、要求受付ノードでは、情報要求パケットが要求終端ノードまで誤り無く到達したか否かを確認することができるため、情報収集が完了したか未完了かを識別することができる。したがって、トラヒック情報収集処理の失敗を検出することができ、もし、失敗を検出した場合には再度、情報要求パケットを送信する等の処理を行うことができるため、確実なトラヒック情報収集を行うことができる。
【００２０】
前記情報要求パケットおよび前記情報回答パケットは、ＩＣＭＰ(Internet Control Message Protocol)パケットとして転送されることが望ましい。
【００２１】
ＩＣＭＰパケットとは、ＩＰデータグラム配送時に経路上のゲートウェイで発生したＩＰデータグラム転送処理の障害を、送信ホストに対して通知するために開発されたプロトコルを用いるパケットである。情報要求パケットおよび情報回答パケットにこのＩＣＭＰパケットを用いることにより、これらのパケットは特別なプロトコルを用いることなく、実通信と同一経路にしたがって転送されるために経路変更に柔軟に追従可能であり、実通信に沿った有効なトラヒック情報収集を行うことができる。さらに、多数の観測パケットを用いる従来方式と比較して、適切なコストでトラヒック情報収集を行うことができる。
【００２２】
本発明の第二の観点はトラヒック情報収集方法であって、本発明の特徴とするところは、ＩＰ通信網における特定の２点間のトラヒック情報収集の要求を行うユーザ端末もしくはネットワーク管理端末からのトラヒック情報収集の要求を受信して隣接する他通信装置へ前記要求を含む情報要求パケットを送信するとともに前記隣接する他通信装置から自装置以外の複数の通信装置のトラヒック情報が書込まれた情報回答パケットを受信し、自装置内のトラヒック情報および受信した前記情報回答パケットに書込まれたトラヒック情報をとりまとめて前記トラヒック情報収集を要求した前記端末に統括的なトラヒック情報を含む情報回答パケットを送信する要求受付ノードを配置し、前記情報要求パケットを受信して自装置内のトラヒック情報により情報回答パケットを作成して前記要求受付ノードへこの作成した情報回答パケットを送信するとともに前記情報要求パケットの送信元以外の隣接する他通信装置へ前記要求を含む情報要求パケットを転送する要求中継ノードを配置し、前記情報要求パケットを受信して自装置内のトラヒック情報により情報回答パケットを作成して前記要求受付ノードへこの作成した情報回答パケットを送信するとともに受信した情報要求パケットを廃棄する要求終端ノードを配置し、前記要求受付ノードおよび前記要求中継ノードおよび前記要求終端ノードの連携により自律分散的にＩＰ通信網における特定の２点間のトラヒック情報の収集を行うところにある。
【００２３】
本発明の第三の観点はプログラムであって、本発明の特徴とするところは、情報処理装置にインストールすることにより、その情報処理装置に、ＩＰ通信網における特定の２点間のトラヒック情報の収集を行う機能を実現させ、この収集を行う機能として、前記トラヒック情報収集の要求を行うユーザ端末もしくはネットワーク管理端末からのトラヒック情報収集の要求を受信する機能と、この受信する機能により受信した前記要求にしたがって隣接する他通信装置へ前記要求を含む情報要求パケットを送信する機能と、前記隣接する他通信装置から自装置以外の複数の通信装置のトラヒック情報が書込まれた情報回答パケットを受信する機能と、自装置内のトラヒック情報および受信した前記情報回答パケットに書込まれたトラヒック情報をとりまとめる機能と、前記トラヒック情報収集を要求した前記端末に前記とりまとめる機能がとりまとめた統括的なトラヒック情報を含む情報回答パケットを送信する機能とを備えた要求受付ノードに相応する機能と、前記情報要求パケットを受信する機能と、この受信する機能により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して前記要求受付ノードへこの作成した情報回答パケットを送信する機能と、前記情報要求パケットの送信元以外の隣接する他通信装置へ前記要求を含む情報要求パケットを転送する機能とを備えた要求中継ノードに相応する機能と、前記情報要求パケットを受信する機能と、この受信する機能により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して前記要求受付ノードへこの作成した情報回答パケットを送信する機能と、受信した情報要求パケットを廃棄する機能とを備えた要求終端ノードに相応する機能とを実現させるところにある。
【００２４】
本発明の第四の観点は、本発明のプログラムが記録された前記情報処理装置読取可能な記録媒体である。本発明のプログラムは本発明の記録媒体に記録されることにより、前記情報処理装置は、この記録媒体を用いて本発明のプログラムをインストールすることができる。あるいは、本発明のプログラムを保持するサーバからネットワークを介して直接前記情報処理装置に本発明のプログラムをインストールすることもできる。
【００２５】
これにより、コンピュータ装置等の情報処理装置により、トラヒック情報収集のために特別な観測パケットを用いたり、トラヒック情報収集のための特別な通信プロトコルを必要とすることがなく、ＩＰ通信網の利用者に対してサービスクラス毎のトラヒック情報を容易かつ高速に提供可能とし、かつこれを実現する際に、特定のシステムに対して集中的な処理負荷を与えることがない、トラヒック情報収集を実現することができる。
【００２６】
【発明の実施の形態】
本発明実施例のトラヒック情報収集装置を図１ないし図１０を参照して説明する。図１は本発明の実施形態の構成を示すブロック図である。図２は要求受付ノードの内部構成を示すブロック図である。図３は要求中継ノードの内部構成を示すブロック図である。図４は要求終端ノードの内部構成を示すブロック図である。図５は情報要求パケットに格納される情報の例を示す図である。図６は情報回答パケットに格納される情報の例を示す図である。図７は本発明の実施形態のトラヒック情報収集手順を示すフローチャートである。図８は本発明の実施例におけるネットワーク構成例を示す図である。図９は実施例における各ルータからの情報回答パケットの内容例を示す図である。図１０は実施例における情報要求元への回答内容を示す図である。
【００２７】
本実施例はトラヒック情報収集装置であって、本実施例の特徴とするところは、図１および図２に示すように、ＩＰ通信網における特定の２点間のトラヒック情報収集の要求を行うユーザ端末１１もしくはネットワーク管理端末１３からのトラヒック情報収集の要求を受信する要求受付処理部４２と、この要求受付処理部４２により受信した前記要求にしたがって隣接する他通信装置へ前記要求を含む情報要求パケットを送信する情報要求パケット転送処理部４５と、前記隣接する他通信装置から自装置以外の複数の通信装置のトラヒック情報が書込まれた情報回答パケットを受信する情報回答パケット受付処理部４８と、自装置内のトラヒック情報および受信した前記情報回答パケットに書込まれたトラヒック情報をとりまとめて前記トラヒック情報収集を要求したユーザ端末１１もしくはネットワーク管理端末１３にとりまとめた統括的なトラヒック情報を含む情報回答パケットを送信する要求回答処理部４９とを備えた要求受付ノード１４と、図３に示すように、前記情報要求パケットを受信する情報要求パケット検出処理部５１と、この情報要求パケット検出処理部５１により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して要求受付ノード１４へこの作成した情報回答パケットを送信するトラヒック情報計測処理部５３および情報回答パケット作成処理部５４と、前記情報要求パケットの送信元以外の隣接する他通信装置へ前記要求を含む情報要求パケットを転送する情報要求パケット転送処理部５２とを備えた要求中継ノード１５、１６、１７と、図４に示すように、前記情報要求パケットを受信する情報要求パケット検出処理部６１と、この情報要求パケット検出処理部６１により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して要求受付ノード１４へこの作成した情報回答パケットを送信するトラヒック情報計測処理部６３および情報回答パケット作成処理部６４と、受信した情報要求パケットを廃棄する情報要求パケット廃棄処理部６２とを備えた要求終端ノード１８とを備えたところにある。前記トラヒック情報は、図９および図１０に示すように、サービスクラス毎のリンク容量を含む。
【００２８】
図５に示すように、前記情報要求パケットにはホップ数フィールド７４が設けられ、要求受付ノード１４の情報要求パケット作成処理部４３は、情報要求パケット生成時にホップ数フィールド７４に初期値を与え、要求中継ノード１５、１６、１７の情報要求パケット転送処理部５２は、転送する毎にホップ数フィールド７４の値を１増加させ、要求中継ノード１５、１６、１７および要求終端ノード１８の情報回答パケット作成処理部５４、６４は、受信した情報要求パケットのホップ数フィールド７４のホップ数情報を当該情報要求に対する情報回答パケットに書込む。
【００２９】
また、図５に示すように、要求受付ノード１４の情報要求パケット作成処理部４３は、情報要求パケットに対して要求ごとの識別情報である検索ＩＤ７３を付与し、要求中継ノード１５、１６、１７および要求終端ノード１８の情報回答パケット作成処理部５４、６４は、受信した情報情報パケットの検索ＩＤ７３を当該情報要求に対する情報回答パケットに書込む。
【００３０】
また、図６に示すように、前記情報回答パケットには最終ノードフラグが設けられ、要求終端ノード１８の情報回答パケット作成処理部６４は、当該最終ノードフラグを設定する。
【００３１】
前記情報要求パケットおよび前記情報回答パケットは、ＩＣＭＰ(Internet Control Message Protocol)パケットとして転送される。
【００３２】
本実施例のトラヒック情報収集装置は、情報処理装置としてのコンピュータ装置により実現することができる。すなわち、コンピュータ装置にインストールすることにより、そのコンピュータ装置に、ＩＰ通信網における特定の２点間のトラヒック情報の収集を行う機能を実現させ、この収集を行う機能として、前記トラヒック情報収集の要求を行うユーザ端末１１もしくはネットワーク管理端末１３からのトラヒック情報収集の要求を受信する要求受付処理部４２に相応する機能と、この要求受付処理部４２に相応する機能により受信した前記要求にしたがって隣接する他通信装置へ前記要求を含む情報要求パケットを送信する情報要求パケット転送処理部４５に相応する機能と、前記隣接する他通信装置から自装置以外の複数の通信装置のトラヒック情報が書込まれた情報回答パケットを受信する情報回答パケット受付処理部４８に相応する機能と、自装置内のトラヒック情報および受信した前記情報回答パケットに書込まれたトラヒック情報をとりまとめて前記トラヒック情報収集を要求したユーザ１１もしくはネットワーク管理端末１３にとりまとめた統括的なトラヒック情報を含む情報回答パケットを送信する要求回答処理部４９に相応する機能とを備えた要求受付ノード１４に相応する機能と、前記情報要求パケットを受信する情報要求パケット検出処理部５１に相応する機能と、この情報要求パケット検出処理部５１に相応する機能により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して要求受付ノード１４へこの作成した情報回答パケットを送信するトラヒック情報計測処理部５３および情報回答パケット作成処理部５４に相応する機能と、前記情報要求パケットの送信元以外の隣接する他通信装置へ前記要求を含む情報要求パケットを転送する情報要求パケット転送処理部５２に相応する機能とを備えた要求中継ノード１５、１６、１７に相応する機能と、前記情報要求パケットを受信する情報要求パケット検出処理部６１に相応する機能と、この情報要求パケット検出処理部６１に相応する機能により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して要求受付ノード１４へこの作成した情報回答パケットを送信する情報回答パケット作成処理部６４に相応する機能と、受信した情報要求パケットを廃棄する情報要求パケット廃棄処理部６２に相応する機能とを備えた要求終端ノード１８に相応する機能とを実現させるプログラムをコンピュータ装置にインストールすることにより、このコンピュータ装置を用いて実現することができる。
【００３３】
本発明のプログラムは、本発明の記録媒体に記録されることにより、コンピュータ装置は、この記録媒体を用いて本発明のプログラムをインストールすることができる。あるいは、本発明のプログラムを保持するサーバからネットワークを介して直接コンピュータ装置に本発明のプログラムをインストールすることもできる。
【００３４】
これにより、コンピュータ装置により、トラヒック情報収集のために特別な観測パケットを用いたり、トラヒック情報収集のための特別な通信プロトコルを必要とすることがなく、ＩＰ通信網の利用者に対してサービスクラス毎のトラヒック情報を容易かつ高速に提供可能とし、かつこれを実現する際に、特定のシステムに対して集中的な処理負荷を与えることがないトラヒック情報収集装置を実現することができる。
【００３５】
以下では、本発明実施例をさらに詳細に説明する。
【００３６】
本発明の実施の形態について図面を参照して詳細に説明する。図１を参照すると、本発明の実施の形態は、ＩＰ通信を行うある２点間を示すユーザ端末１１、ユーザ端末１２と、ＩＰ通信網を構成し本発明を実施する要求受付ノード１４と、要求中継ノード１５〜１７と、要求終端ノード１８と、各通信ノードの管理システムであるＯＳＳ１９と、ＯＳＳ１９を利用して管理業務を行うためのネットワーク管理端末１３とから構成される。ここで、トラヒック情報収集の要求元は、ユーザ端末１１もしくはネットワーク管理端末１３であるものとし、トラヒック情報収集の要求は、要求受付ノード１４に送出されるものとする。
【００３７】
要求受付ノード１４は、ユーザ端末１１もしくはネットワーク管理端末１３からのトラヒック情報収集の要求を受信し、ユーザ認証等のセキュリティ関連処理を行うと共に、通信装置内でのトラヒック情報収集を指示する情報要求パケットを生成し、自ノードでのトラヒック情報を収集し、トラヒック情報を格納した情報回答パケットを作成するとともに、経路上の隣接する要求中継ノード１５に対して情報要求パケットを転送する。さらに、以降の要求中継ノード１５〜１７および要求終端ノード１８から送出された情報回答パケットを自ノード分とあわせて集約し、要求元であるユーザ端末１１もしくはネットワーク管理端末１３へのトラヒック情報収集要求の回答を作成して送出する処理を行う。
【００３８】
要求中継ノード１５〜１７は、隣接する要求受付ノード１４もしくは要求中継ノード１５〜１７から情報要求パケットを受信し、自ノードでのトラヒック情報を収集し、収集した情報を情報回答パケットとして要求受付ノード１４に送出するとともに、経路上で次に隣接する要求中継ノード（例えば、要求中継ノード１５の場合は要求中継ノード１６がこれに相当し、要求中継ノード１６の場合は要求中継ノード１７がこれに相当する）に対して情報要求パケットを転送する。
【００３９】
要求終端ノード１８は、隣接する要求中継ノード１７から情報要求パケットを受信し、自ノードでのトラヒック情報を収集し、収集した情報を情報回答パケットとして要求受付ノード１４に送出するとともに、受信した情報要求パケットの廃棄を行うことで、情報収集の処理要求の終端ノードを越えた伝播を防止する。
【００４０】
次に、図１の実施の形態におけるトラヒック情報収集手順を図７を参照して詳細に説明する。（ステップ１）要求受付処理では、トラヒック情報収集の要求を受付け、ユーザ認証等のセキュリティ処理を行う。（ステップ２）情報要求パケット作成処理では、各通信ノードに対するトラヒック情報収集の指示を行う情報要求パケットの生成を行う。情報要求パケットには、ユーザ端末等から受付けた情報収集要求の指定に基づきトラヒック情報を収集したいユーザ端末のアドレス（ソースアドレス、デスティネーションアドレス）等が格納される。
【００４１】
（ステップ３）情報要求パケット検出処理では、通信ノードの出力インタフェースにおいて情報要求パケットの検出を行う。検出方法としては、例えば、特定のＩＣＭＰタイプを持つＩＣＭＰパケットを使用することで、容易に検出が可能となる。情報要求パケットが検出されると、情報要求パケット転送処理（ステップ４）ならびに、トラヒック情報計測処理（ステップ５）の実行指示を行う。
【００４２】
（ステップ４）情報要求パケット転送処理の判断では、情報要求パケットに含まれるデスティネーション端末を調べ自ノードに隣接していない場合は、デスティネーションアドレスに至る経路上で隣接する通信ノードに向けて、情報要求パケットのホップ数を１つ増加させて情報要求パケットの転送を行う。
【００４３】
（ステップ５）トラヒック情報計測処理では、各出力インタフェース毎にサービスクラス毎のトラヒック情報を計測し、最新の情報をメモリに保持しており、情報要求パケット検出処理（ステップ３）からの指示により、サービスクラス毎のトラヒック情報を検索し、次ステップに情報を引渡す。
【００４４】
（ステップ６）情報回答パケット作成処理では、検索されたトラヒック情報ならびに、検索ＩＤとホップ数のフィールド値を用い、情報回答パケットの作成を行う。さらに、作成された情報回答パケットを、情報要求パケットのソースアドレスで指定される要求受付ノードへ送信する処理を行う。
【００４５】
（ステップ７）情報回答パケット受付処理では、経路上の各ノードからの情報回答パケットを検索ＩＤ毎に集約する。このとき、最終ノードフラグの立っているパケットのホップ数フィールド値から、経路上のノード数がわかるので、経路上の全てのノードからの回答パケットを受信するまで待ち、全てを受信した時点で次ステップへ移行する。一定時間内に経路上の全てのノードからの情報回答パケットが受信できない場合には、検索失敗の通知を次ステップに行う。
【００４６】
（ステップ８）要求回答処理では、ステップ７での情報回答パケットの受信結果から、サービスクラス毎の使用可能帯域を計算して要求元へ回答する。
【００４７】
（ステップ９）ステップ３と同一の処理を行う。（ステップ１０）ステップ５と同一の処理を行う。（ステップ１１）ステップ６と同一の処理を行う。（ステップ１２）ステップ４と同一の処理を行う。
【００４８】
（ステップ１３）情報要求パケット廃棄では、情報要求パケットに含まれるデスティネーション端末が自ノードに隣接しているため、情報要求パケットの廃棄を行い、これ以上の情報要求パケットの転送を防止する。
【００４９】
ここで、上記のステップ４ならびにステップ９〜１１は（処理グループＳ１４）、トラヒック情報を収集する経路における要求中継ノードならびに要求終端ノードの数分だけ、繰り返し（処理グループＳ１５のように）処理が行われることになる。
【００５０】
次に、図２を参照すると、図１に示す要求受付ノード１４の詳細が示されている。要求受付ノード４１は、要求受付処理部４２、情報要求パケット作成処理部４３、情報要求パケット検出処理部４４、情報要求パケット転送処理部４５、トラヒック情報計測処理部４６、情報回答パケット作成処理部４７、情報回答パケット受付処理部４８、要求回答処理部４９から構成される。それぞれの処理内容を説明する。
【００５１】
要求受付処理部４２では、要求元４１からのトラヒック情報収集の要求に対し、ユーザ認証等のセキュリティ対策を行い、情報収集の要求を受理すると、情報要求パケット作成処理部４３に対して、情報要求パケットを作成するよう指示する。要求元４１からのトラヒック情報収集の要求メッセージは、通信先（デスティネーション）のアドレスを含む。
【００５２】
情報要求パケット作成処理部４３では、図５に示すフォーマットの情報要求パケットを組み立て、経路情報にしたがって情報要求パケットを送出する。ここで、図５のソースアドレス７１には自ノードのアドレス、デスティネーションアドレス７２には、要求元からのトラヒック情報収集の要求メッセージ内の通信先アドレス、検索ＩＤ７３は要求受付ノードで一意になる値（たとえば０から始まるシーケンシャルな値）、ホップ数フィールド７４には“０”を設定する。
【００５３】
情報要求パケット検出処理部４４は、自通信ノード出力インタフェースにおいて情報要求パケットの検出を行う。検出方法としては、例えば、特定のＩＣＭＰタイプを持つＩＣＭＰパケットを使用することで、容易に検出が可能となる。情報要求パケットが検出されると、トラヒック情報計測処理部４６に該当するトラヒック情報を検索するよう指示を行う。また、検索ＩＤとホップ数のフィールド値を情報回答パケット作成処理部４７に渡す。
【００５４】
情報要求パケット転送処理部４５では、情報要求パケットのホップ数を１つ増加させて、次の要求中継ノード１５〜１７または要求終端ノード１８に情報要求パケットを転送する。
【００５５】
トラヒック情報計測処理部４６では、自通信ノードのインタフェース毎にサービスクラス毎のトラヒック情報を計測し、最新の情報をメモリに保持する。情報要求パケット検出処理部４４より検索指示を受けると、サービスクラス毎のトラヒック情報を情報回答パケット作成処理部４７に渡す。
【００５６】
情報回答パケット作成処理部４７では、図６に示すフォーマットの情報回答パケットを作成する。図６において、検索ＩＤ８１とホップ数フィールド８２のフィールド値は情報要求パケット検出処理部４４から渡された値を入れ、最終ノードフラグ８３は立てない。リンク帯域８４ならびにサービスクラス毎の占有帯域８５、８６は、トラヒック情報計測処理部４６から渡された値を格納する。このように作成された情報回答パケットは、情報要求パケットのソースアドレスで指定される要求受付ノード（この場合は、自ノード）へ送出される。
【００５７】
情報回答パケット受付処理部４８では、経路上の各ノードからの情報回答パケットを検索ＩＤ毎に集約する。このとき、最終ノードフラグの立っているパケットのホップ数フィールド値から、経路上のノード数がわかるので、経路上の全てのノードからの回答パケットを受信すると、受信結果を要求回答処理部４９に渡す。一定時間内に経路上の全てのノードからの回答パケットが受信できない場合には、検索失敗通知を要求回答処理部４９に渡す。
【００５８】
要求回答処理部４９では、情報回答パケット受付処理部４８からの受信結果から、クラスごとの使用可能帯域を計算し、要求元４１へ回答する。
【００５９】
次に、図３を参照すると、図１に示す要求中継ノード１５〜１７の詳細が示されている。要求中継ノード１５〜１７は、情報要求パケット検出処理部５１、情報要求パケット転送処理部５２、トラヒック情報計測処理部５３、情報回答パケット作成処理部５４から構成される。それぞれの処理内容を説明する。
【００６０】
情報要求パケット検出処理部５１は、自通信ノードの出力インタフェースにおいて情報要求パケットの検出を行う。情報要求パケットが検出されると、トラヒック情報計測処理部５３の情報を検索するよう指示する。また、検索ＩＤとホップ数フィールドの値を情報回答パケット作成処理部５４に渡す。
【００６１】
情報要求パケット転送処理部５２では、情報要求パケットのホップ数を１つ増加させて、次の要求中継ノード１６、１７または要求終端ノード１８に情報要求パケットを転送する。
【００６２】
トラヒック情報計測処理部５３では、自通信ノードのインタフェース毎にサービスクラス毎のトラヒック情報を計測し、最新の情報をメモリに保持する。情報要求パケット検出処理部５１より検索指示を受けると、サービスクラス毎のトラヒック情報を情報回答パケット作成処理部５４へ渡す。
【００６３】
情報回答パケット作成処理部５４では、図６に示すフォーマットの情報回答パケットを作成する。検索ＩＤとホップ数フィールドの値は情報要求パケット検出処理部５１から渡された値を入れ、最終ノードフラグは立てない。作成された情報回答パケットは、情報要求パケットのソースアドレスで指定される要求受付ノードへ送出される。
【００６４】
次に、図４を参照すると、図１に示す要求終端ノード１８の詳細が示されている。要求終端ノード１８は、情報要求パケット検出処理部６１、情報要求パケット廃棄処理部６２、トラヒック情報計測処理部６３、情報回答パケット作成処理部６４から構成される。それぞれの処理内容を説明する。
【００６５】
情報要求パケット検出処理部６１は、自通信ノードの出力インタフェースにおいて情報要求パケットの検出を行う。情報要求パケットが検出されると、トラヒック情報計測処理部６２の情報を検索するよう指示する。また、検索ＩＤとホップ数フィールドの値を情報回答パケット作成処理部６４に渡す。情報要求パケット廃棄処理部６２では、情報要求パケットを廃棄する。
【００６６】
トラヒック情報計測処理部６３では、自通信ノードのインタフェース毎にサービスクラス毎のトラヒック情報を計測し、最新の情報をメモリに保持する。情報要求パケット検出処理部６１より検索指示を受けると、サービスクラス毎のトラヒック情報を情報回答パケット作成処理部６４へ渡す。
【００６７】
情報回答パケット作成処理部６４では、図６に示すフォーマットの回答パケットを作成する。検索ＩＤとホップ数フィールドの値は情報要求パケット検出処理部６１から渡された値を入れ、最終ノードフラグを立てる。作成された情報回答パケットは、情報要求パケットのソースアドレスで指定される要求受付ノードへ送出される。
【００６８】
次に、本発明の実施例について図面を参照して詳細に説明する。図８を参照すると、実施例におけるＩＰ通信網の例が示されており、ユーザ端末１１とユーザ端末１２との間には、要求受付ノード１４としての加入者収容装置Ａ、要求中継ノード１５〜１７としてのルータＡ、ルータＢ、ルータＣ、要求終端ノード１８としての加入者収容装置Ｂから構成され、各装置はＯＳＳ１９を介して、ネットワーク管理端末１３によって管理されている。
【００６９】
ＩＰ通信網は複数のサービスクラスを提供するマルチサービス網であり、提供されるサービスクラスは３種類（クラス３、クラス２、クラス１）、優先度がクラス３＞クラス２＞クラス１の順に設定され、クラス３の通信が最優先されるものとする。各サービスクラスはデータ量に対して課金される従量課金制、各クラスの料金（データ量単価）はクラス３＞クラス２＞クラス１の順に設定され、クラス３の料金が一番高く設定されているものとする。
【００７０】
ここで、ユーザ端末１１のユーザＡが、ユーザ端末１２のユーザＢと通信するために、ユーザ端末１１からユーザ端末１２までの間のトラヒック情報を得たい場合には、ユーザ端末１１から加入者収容装置Ａに対してトラヒック情報要求を送出する。トラヒック情報要求には、デスティネーションアドレス（ユーザ端末１２のアドレス）を指定して要求を行う。
【００７１】
加入者収容装置Ａは、要求受付ノード１４として動作する。加入者収容装置Ａは、ユーザ端末１１からのトラヒック情報要求に対してユーザ認証を行う。ユーザ認証の方法としては、ユーザＩＤとパスワードの利用や、ユーザＡのＩＰアドレスのチェック等を用いる。トラヒック情報要求が受理されると、情報要求パケットを作成し、設定されているルーティングテーブルにしたがって出力インタフェースに転送する。出力インタフェースでは、情報要求パケットの検出を行い、出力インタフェースのトラヒック情報の検索を行う。
【００７２】
情報要求パケットは、情報要求パケット転送処理部４５にてホップ数を１つインクリメントされる（ホップ数１）。情報要求パケットは出力インタフェースよりルータＡへ送出される。
【００７３】
経路上にあるルータＡ、ルータＢ、ルータＣはそれぞれ要求中継ノード１５〜１７として動作する。ルータＡでは、加入者収容装置Ａからの情報要求パケットを、設定されているルーティングテーブルにしたがって出力インタフェースに転送する。出力インタフェースでは、情報要求パケットの検出を行い、出力インタフェースのトラヒック情報の検索を行う。情報要求パケットは、情報要求パケット転送処理部５２にてホップ数を１つインクリメントされる（ホップ数２）。情報要求パケットは出力インタフェースよりルータＢへ送出される。情報回答パケット作成処理部５４では、トラヒック情報の検索結果と、情報要求パケット検出処理部５１で抽出された検索ＩＤ、ホップ数（ここではホップ数１）、あらかじめ設定されているリンク帯域を図６に示す情報回答パケットとして作成し、加入者収容装置Ａに回答する。ルータＢではルータＡと同様の処理を行い、情報要求パケットをルータＣへ転送する。ルータＣも同様の処理を行い、情報要求パケットを加入者収容装置Ｂに転送する。
【００７４】
ユーザ端末１２を収容している加入者収容装置Ｂは、要求終端ノード１８として動作する。加入者収容装置Ｂでは、ルータＣより転送された情報要求パケットを、設定されているルーティングテーブルにしたがって出力インタフェースに転送する。出力インタフェースでは、要求パケットの検出を行い、出力インタフェースのトラヒック情報の検索を行う。情報要求パケットは情報要求パケット廃棄処理部６２にて廃棄される。情報回答パケット作成処理部６４では、トラヒック情報の検索結果と、要求パケット検出部で抽出された検索ＩＤ、ホップ数（ここではホップ数４）、あらかじめ設定されているリンク帯域を図６に示す情報回答パケットとして作成し、加入者収容装置Ａに回答する。このとき、情報回答パケットの最終ノードフラグには“１”が立てられている。
【００７５】
各ノード（１４〜１８）からの回答は加入者収容装置Ａの情報回答パケット受付処理部４８にて集約される。ここで、最終ノードフラグの検出を行い、最終ノードフラグの検出されたパケットからホップ数を抽出する。ここではホップ数４が抽出されるので、ホップ数０、ホップ数１、ホップ数２、ホップ数３の回答パケットが受信されていることを確認する。ここで、加入者収容装置Ａではあらかじめ決められた時間内に回答パケットが受信されるものとし、時間内に最終ノードフラグが検出されない場合または経路途中のホップ数のパケットが受信されない場合は情報要求パケットまたは情報回答パケットが廃棄されたものとして、検索失敗を通知する。加入者収容装置Ａの要求回答処理部４９では、受信した情報回答パケットの回答内容から、トラヒック情報の回答をユーザ端末１１に送る。例えば、情報回答パケットの回答内容が図９のような場合（ホップ０は加入者収容装置Ａのトラヒック情報検索結果）、ユーザ端末１１に対しての回答は各クラスの使用可能帯域（その帯域でデータ通信してもパケット廃棄されることなく相手端末までデータ転送が可能な最大帯域）を通知することとすると、ユーザ端末１１からユーザ端末１２までの経路上でのリンク容量は、全ホップ中での最小の容量となり、各クラスの使用可能帯域は各ホップにおけるリンク占有可能帯域の最小のものとなるため、図１０のようになる。図９の例において、例えばクラス２についてはホップ２においてリンク占有可能帯域が最小となり、その値は、空き帯域（３０）を含むクラス２より低位クラスの占有帯域の合計（３０＋１０）となる。
【００７６】
本実施例のサービスへの適用例として、ストリーム通信サービスのように、ユーザが特定のスループットを要求するようなサービスの例について説明する。回答結果として図１０の結果を得たユーザが４０の帯域で通信したいと思うと、サービスクラスとしてクラス２を選択すれば４０の帯域が確保できることがわかる。ここで、クラス１を選択すると、４０の帯域は確保できないので要求される品質を提供できない。また、クラス３を選択すると要求帯域は確保できるが、通信コストが多くかかることとなる。
【００７７】
また、別のサービスへの適用例としてバルク通信サービスのような、ユーザが帯域を可変できるサービスの例について説明する。ユーザはクラス１の料金で通信をしたいのだが、使用可能な帯域はどれくらいか知るためにトラヒック情報を要求する。このときの回答を図９のとおりとすると、ユーザは２０の帯域であればクラス１の料金でパケット廃棄されることなく通信できることがわかる。ここで、３０の帯域でデータ送信する場合には、すべてのデータが相手に到達する保証はないため、通信コストを無駄にする可能性がある。
【００７８】
また、本実施例のサービスへの適用例として通信品質／通信料金に関する要求条件をユーザが指定し、ユーザＡＰがトラヒック情報を定期的に要求することにより、データ送出帯域や選択サービスクラスを自動制御するサービスも考えられる。
【００７９】
（実施例まとめ）
以上説明したように、本発明においては、次のような効果を奏する。
【００８０】
第１の効果は、トラヒック情報の推測のための特別な観測パケットや、トラヒック情報収集のための特別な通信プロトコルを必要とすることがない、ということにある。その理由は、各通信ノードにおいて管理格納されているトラヒック情報を、ＩＣＭＰ等を利用した情報要求パケットならびに情報回答パケットを用いて収集することを可能としたためである。
【００８１】
第２の効果は、ＩＰ通信網の利用者に対して、サービスクラス毎のトラヒック情報を容易かつ高速に提供可能とし、かつこれを実現する際に、特定のシステムに対して集中的な処理負荷を与えることがない、ということにある。その理由は、各通信ノードにおいて情報要求パケットならびに情報回答パケットを処理する形態としたことにより、情報要求パケット１個と、ホップ数分の情報回答パケットのみの少ないパケット数で情報収集を可能としていることと、トラヒック情報収集処理を経路上の複数の通信ノードで分散処理するためである。さらに要求受付ノードで収容端末のトラヒック情報要求を受付け、ユーザ認証や結果集約等の処理を行うため、複数のＩＰ通信網利用者に対して分散的な処理を可能としたためである。
【００８２】
第３の効果は、要求中継ノードから個別に送信されてきた情報回答パケットの経路上の順番を、要求受付ノードにおいて再現することができることにある。その理由は、情報要求パケットにホップ数フィールドを設け、転送毎に１増加させ、情報回答パケットにコピーする処理を行っているためである。
【００８３】
第４の効果は、要求受付ノードは複数のユーザ端末もしくはネットワーク管理端末からの要求を、同時に処理することができることにある。その理由は、情報要求パケットにＩＤフィールドを設け、情報回答パケットにコピーする処理を行っているためである。
【００８４】
第５の効果は、ＩＰ網内でのパケット廃棄によるトラヒック情報収集処理の失敗を検出することができることにある。その理由は、情報回答パケットに最終ノードフラグを設け、要求終端ノードにおいてフラグを立てる処理を行っているためである。
【００８５】
第６の効果は、トラヒック情報収集が正確であり、ユーザ端末が適切なコストで通信を行うことができることにある。その理由は、情報要求パケットが実通信と同一経路に従って転送されるため、経路変更に柔軟に追従可能であり、情報収集結果を用いることによりパケット廃棄が発生しない帯域でデータ送出を行うことを可能としているためである。
【００８６】
【発明の効果】
以上説明したように、本発明によれば、トラヒック情報収集のために特別な観測パケットを用いたり、トラヒック情報収集のための特別な通信プロトコルを必要とすることがなく、ＩＰ通信網の利用者に対してサービスクラス毎のトラヒック情報を容易かつ高速に提供可能とし、かつこれを実現する際に、特定のシステムに対して集中的な処理負荷を与えることがない。
【図面の簡単な説明】
【図１】本発明の実施形態の構成を示すブロック図。
【図２】要求受付ノードの内部構成を示すブロック図。
【図３】要求中継ノードの内部構成を示すブロック図。
【図４】要求終端ノードの内部構成を示すブロック図。
【図５】情報要求パケットに格納される情報の例を示す図。
【図６】情報回答パケットに格納される情報の例を示す図。
【図７】本発明の実施形態のトラヒック情報収集手順を示すフローチャート。
【図８】本発明の実施例におけるネットワーク構成例を示す図。
【図９】実施例における各ルータからの情報回答パケットの内容例を示す図。
【図１０】実施例における情報要求元への回答内容を示す図。
【図１１】従来のトラヒック情報収集方式を説明するための図。
【符号の説明】
１１、１２ ユーザ端末
１３ ネットワーク管理端末
１４ 要求受付ノード
１５〜１７ 要求中継ノード
１８ 要求終端ノード
１９ オペレーションサポートシステム（ＯＳＳ）
２４〜２８ 通信ノード
４１ 要求元
４２ 要求受付処理部
４３ 情報要求パケット作成処理部
４４、５１、６１ 情報要求パケット検出処理部
４５、５２ 情報要求パケット転送処理部
４６、５３、６３ トラヒック情報計測処理部
４７、５４、６４ 情報回答パケット作成処理部
４８ 情報回答パケット受付処理部
４９ 要求回答処理部
６２ 情報要求パケット廃棄処理部
７１ ソースアドレス
７２ ディスティネーションアドレス
７３、８１ 検索ＩＤ
７４、８２ ホップ数フィールド
８３ 最終ノードフラグ
８４ リンク帯域
８５ クラスｘの占有帯域
８６ クラスｙの占有帯域
Claims (9)
- ＩＰ通信網における特定の２点間のトラヒック情報収集の要求を行うユーザ端末もしくはネットワーク管理端末からのトラヒック情報収集の要求を受信する手段と、
この受信する手段により受信した前記要求にしたがって隣接する他通信装置へ前記要求を含む情報要求パケットを送信する手段と、
前記隣接する他通信装置から自装置以外の複数の通信装置のトラヒック情報が書込まれた情報回答パケットを受信する手段と、
自装置内のトラヒック情報および受信した前記情報回答パケットに書込まれたトラヒック情報をとりまとめる手段と、
前記トラヒック情報収集を要求した前記端末に前記とりまとめる手段がとりまとめた統括的なトラヒック情報を含む情報回答パケットを送信する手段と
を備えた要求受付ノードと、
前記情報要求パケットを受信する手段と、
この受信する手段により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して前記要求受付ノードへこの作成した情報回答パケットを送信する手段と、
前記情報要求パケットの送信元以外の隣接する他通信装置へ前記要求を含む情報要求パケットを転送する手段と
を備えた要求中継ノードと、
前記情報要求パケットを受信する手段と、
この受信する手段により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して前記要求受付ノードへこの作成した情報回答パケットを送信する手段と、
受信した情報要求パケットを廃棄する手段と
を備えた要求終端ノードと
を備えたことを特徴とするトラヒック情報収集装置。 - 前記トラヒック情報は、サービスクラス毎のリンク容量を含む請求項１記載のトラヒック情報収集装置。
- 前記情報要求パケットにはホップ数フィールドが設けられ、
前記情報要求パケットを送信する手段は、情報要求パケット生成時に前記ホップ数フィールドに初期値を与える手段を備え、
前記情報要求パケットを転送する手段は、転送する毎に前記ホップ数フィールドの値を１増加させる手段を備え、
前記情報回答パケットを送信する手段は、受信した情報要求パケットの前記ホップ数フィールドのホップ数情報を当該情報要求に対する情報回答パケットに書込む手段を備えた
請求項１記載のトラヒック情報収集装置。 - 前記情報要求パケットを送信する手段は、情報要求パケットに対して要求ごとの識別情報を付与する手段を備え、
前記情報回答パケットを送信する手段は、受信した情報情報パケットの前記識別情報を当該情報要求に対する情報回答パケットに書込む手段を備えた
請求項１記載のトラヒック情報収集装置。 - 前記情報回答パケットには最終ノードフラグが設けられ、
前記要求終端ノードは、当該最終ノードフラグを設定する手段を備えた
請求項１記載のトラヒック情報収集装置。 - 前記情報要求パケットおよび前記情報回答パケットは、ＩＣＭＰ(Internet Control Message Protocol)パケットとして転送される
請求項１記載のトラヒック情報収集装置。 - ＩＰ通信網における特定の２点間のトラヒック情報収集の要求を行うユーザ端末もしくはネットワーク管理端末からのトラヒック情報収集の要求を受信して隣接する他通信装置へ前記要求を含む情報要求パケットを送信するとともに前記隣接する他通信装置から自装置以外の複数の通信装置のトラヒック情報が書込まれた情報回答パケットを受信し、自装置内のトラヒック情報および受信した前記情報回答パケットに書込まれたトラヒック情報をとりまとめて前記トラヒック情報収集を要求した前記端末に統括的なトラヒック情報を含む情報回答パケットを送信する要求受付ノードを配置し、
前記情報要求パケットを受信して自装置内のトラヒック情報により情報回答パケットを作成して前記要求受付ノードへこの作成した情報回答パケットを送信するとともに前記情報要求パケットの送信元以外の隣接する他通信装置へ前記要求を含む情報要求パケットを転送する要求中継ノードを配置し、
前記情報要求パケットを受信して自装置内のトラヒック情報により情報回答パケットを作成して前記要求受付ノードへこの作成した情報回答パケットを送信するとともに受信した情報要求パケットを廃棄する要求終端ノードを配置し、
前記要求受付ノードおよび前記要求中継ノードおよび前記要求終端ノードの連携により自律分散的にＩＰ通信網における特定の２点間のトラヒック情報の収集を行うことを特徴とするトラヒック情報収集方法。 - 情報処理装置にインストールすることにより、その情報処理装置に、ＩＰ通信網における特定の２点間のトラヒック情報の収集を行う機能を実現させ、
この収集を行う機能として、
前記トラヒック情報収集の要求を行うユーザ端末もしくはネットワーク管理端末からのトラヒック情報収集の要求を受信する機能と、
この受信する機能により受信した前記要求にしたがって隣接する他通信装置へ前記要求を含む情報要求パケットを送信する機能と、
前記隣接する他通信装置から自装置以外の複数の通信装置のトラヒック情報が書込まれた情報回答パケットを受信する機能と、
自装置内のトラヒック情報および受信した前記情報回答パケットに書込まれたトラヒック情報をとりまとめる機能と、
前記トラヒック情報収集を要求した前記端末に前記とりまとめる機能がとりまとめた統括的なトラヒック情報を含む情報回答パケットを送信する機能と
を備えた要求受付ノードに相応する機能と、
前記情報要求パケットを受信する機能と、
この受信する機能により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して前記要求受付ノードへこの作成した情報回答パケットを送信する機能と、
前記情報要求パケットの送信元以外の隣接する他通信装置へ前記要求を含む情報要求パケットを転送する機能と
を備えた要求中継ノードに相応する機能と、
前記情報要求パケットを受信する機能と、
この受信する機能により受信した前記情報要求パケットに含まれる前記要求にしたがって自装置内のトラヒック情報により情報回答パケットを作成して前記要求受付ノードへこの作成した情報回答パケットを送信する機能と、
受信した情報要求パケットを廃棄する機能と
を備えた要求終端ノードに相応する機能と
を実現させることを特徴とするプログラム。 - 請求項８記載のプログラムが記録された前記情報処理装置読取可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001356362A JP3781663B2 (ja) | 2001-11-21 | 2001-11-21 | トラヒック情報収集装置およびトラヒック情報収集方法およびプログラムおよび記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001356362A JP3781663B2 (ja) | 2001-11-21 | 2001-11-21 | トラヒック情報収集装置およびトラヒック情報収集方法およびプログラムおよび記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003158549A JP2003158549A (ja) | 2003-05-30 |
| JP3781663B2 true JP3781663B2 (ja) | 2006-05-31 |
Family
ID=19167896
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001356362A Expired - Fee Related JP3781663B2 (ja) | 2001-11-21 | 2001-11-21 | トラヒック情報収集装置およびトラヒック情報収集方法およびプログラムおよび記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3781663B2 (ja) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007139460A1 (en) * | 2006-05-30 | 2007-12-06 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for remote monitoring of femto radio base stations |
| JP4689541B2 (ja) * | 2006-06-05 | 2011-05-25 | 日本電信電話株式会社 | 情報探索システム、装置、方法及びプログラム |
| JP4915345B2 (ja) * | 2007-12-26 | 2012-04-11 | 富士通株式会社 | 試験装置測定システム |
| WO2010095588A1 (ja) | 2009-02-18 | 2010-08-26 | 日本電気株式会社 | 分散監視システム、分散監視方法、及びプログラム |
| JP5701238B2 (ja) * | 2012-02-29 | 2015-04-15 | 日本電信電話株式会社 | 通信装置及び通信方法 |
-
2001
- 2001-11-21 JP JP2001356362A patent/JP3781663B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003158549A (ja) | 2003-05-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4798285B2 (ja) | パケットの伝送品質計測方法、およびパケット受信計測装置 | |
| US8811395B2 (en) | System and method for determination of routing information in a network | |
| US8565227B2 (en) | Mobile IP data communication system comprising a mobile router that detects a change in connection status | |
| CN110890994B (zh) | 一种报文转发路径的确定方法、设备和系统 | |
| US8023509B2 (en) | Communication terminal and retransmission request method | |
| US20030161265A1 (en) | System for end user monitoring of network service conditions across heterogeneous networks | |
| US20090086645A1 (en) | Apparatus and method for passively analyzing a data packet delivery path | |
| EP1657851A1 (en) | Apparatus and method for routing packets in a network | |
| US9634851B2 (en) | System, method, and computer readable medium for measuring network latency from flow records | |
| US20050207349A1 (en) | System and method for measuring quality of communication | |
| JP2005311863A (ja) | トラフィック分散制御方法、制御装置及びネットワークシステム | |
| WO2009071030A1 (fr) | Procédé pour rapporter des informations de dispositif, système et dispositif pour obtenir des informations de dispositif | |
| CN111771359A (zh) | 用于连接通信网络的方法和系统 | |
| JP2000312226A (ja) | 通信品質を保証する方法 | |
| JP3642301B2 (ja) | パケット監視方式 | |
| JP5233295B2 (ja) | 通信装置、通信システム及び通信方法 | |
| JP3781663B2 (ja) | トラヒック情報収集装置およびトラヒック情報収集方法およびプログラムおよび記録媒体 | |
| CN102316086A (zh) | 业务数据的中继方法及中继节点系统 | |
| JP4568846B2 (ja) | ゲートウェイ装置、送信方法、受信方法および情報記録媒体 | |
| JP2004260285A (ja) | 通信品質管理システムおよび方法 | |
| US6865182B2 (en) | Data transfer method including recognizing identical messages and communication apparatus using the method | |
| JP2004343462A (ja) | ネットワーク計測制御システム | |
| JP3704095B2 (ja) | アクセス回線帯域制御ゲートウェイ装置、アクセス回線帯域制御ルータ装置、およびアクセス回線帯域制御システム | |
| EP4425876A1 (en) | Data processing method and apparatus, and network device and storage medium | |
| JP2004178068A (ja) | 遠方監視制御装置、遠方監視制御システム、遠方監視制御方法、遠方監視制御プログラム、および該プログラムを記録した記録媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040415 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060206 |
|
| 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: 20060214 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060307 |
|
| 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: 20100317 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100317 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110317 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110317 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120317 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |