(57)【特許請求の範囲】
【請求項１】
ネットワークにおいてテスト中のノードにおけるトラフィックを測定する方法であって、
ａ）ソースノードから複数の第１のタイプのデータグラムを送信し、各第１のタイプのデータグラムが前記テスト中のノードを含み前記ネットワークを通る経路を有し、各第１のタイプのデータグラムが該テスト中のノードに対し第２のタイプのデータグラムを生成させ、各第２のタイプのデータグラムが前記ソースノードを含み前記ネットワークを通る経路を有し、
ｂ）前記第２のタイプのデータグラムのうちの少なくとも２つを処理して、該少なくとも２つのデータグラムの間で前記テスト中のノードによって処理されたデータグラムの数を決定し、
ｃ）前記少なくとも２つのデータグラムの間の時間を決定し、
ｄ）前記決定したメッセージの数と前記決定した時間との間の比率を反映するトラフィック値を計算する、
ことを含む方法。
【請求項２】
前記テスト中のノードに対して第２のタイプのデータグラムを生成させることは、前記第１のタイプのデータグラムにおいて、該データグラムがテスト中のノードに到達すると時間が切れるようにする生存時間フィールドを設定することを含む請求項１記載の方法。
【請求項３】
前記第２のタイプのデータグラムは、データグラムの時間が切れたことを示すメッセージの一部である請求項２記載の方法。
【請求項４】
前記ソースノードは、消費者コンピュータである請求項１記載の方法。
【請求項５】
前記ソースノードは、コールセンターに接続された診断ユニットである請求項１記載の方法。
【請求項６】
前記診断ユニットは、前記テスト中のノードと異なる管理ドメインにある請求項５記載の方法。
【請求項７】
前記第１のタイプのデータグラムは、問題に直面した顧客がアクセスするサーバを表す宛先アドレスを有する請求項５記載の方法。
【請求項８】
インターネットへのアクセスが遅いことに関する消費者の苦情に応答する方法において使用され、
ａ）前記消費者からＵＲＬを受取り、
ｂ）該指定されたＵＲＬに基づいて前記テスト中のノードを選択し、
ｃ）前記測定されたトラフィックの結果に基づいて前記消費者に報告する、
ことをさらに含む請求項１記載の方法。
【請求項９】
ａ）複数のノードを有し前記ネットワークを通る経路を選択し、
ｂ）請求項１の方法にしたがって前記複数のノードにおいてトラフィックを測定する、
ことをさらに含む請求項１記載の方法。
【請求項１０】
前記第１のタイプのデータグラムは、ＩＰプロトコル内にある請求項１記載の方法。
【請求項１１】
前記第２のタイプのデータグラムは、ＩＰプロトコル内にあり、該第２のタイプのデータグラムを処理することは、該データグラムにおける前記識別フィールドの値の変化を計算することを含む請求項１記載の方法。
【請求項１２】
前記第２のタイプのデータグラムは、タイムアウトメッセージの一部である請求項１記載の方法。
【請求項１３】
前記計算されたトラフィック値を反映する値は、第２のタイプのデータグラムの複数のペアを処理することから取得される値の平均である請求項１記載の方法。
【請求項１４】
ネットワークにおいてテスト中のノードにおけるトラフィックを測定する方法であって、
ａ）ソースノードから時間間隔によって隔てられた第１のタイプのデータグラム対を送信し、第１のタイプのデータグラムの各々が前記テスト中のノードを含み前記ネットワークを通る経路を有し、第１のタイプのデータグラムの各々が、データグラムをテスト中のノードにおいて時間切れさせる生存時間フィールドを含み、それによってテスト中のノードに対し各第１のタイプのデータグラムに応答してタイムアウトメッセージを生成させ、
ｂ）タイムアウトメッセージを処理して、タイムアウトメッセージ間の前記テスト中のノードによって処理されたデータグラムの数を決定し、
ｃ）前記時間間隔において前記テスト中のノードによって処理された前記データグラムの数を反映するトラフィック値を計算する、
ことを含む方法。
【請求項１５】
前記第１のタイプのデータグラムは、ＩＰプロトコル内にある請求項１４記載の方法。
【請求項１６】
前記ソースノードは、コールセンターに関連する診断ユニットである請求項１４記載の方法。
【請求項１７】
ネットワークの経路上のノードにおいてトラフィックを測定する方法であって、
該経路上の各ノードに対し、
ａ）ソースノードから時間間隔によって隔てられた第１のタイプのデータグラム対を送信し、第１のタイプのデータグラムの各々が前記テスト中のノードを含み前記ネットワークを通る経路を有し、第１のタイプのデータグラムの各々が、データグラムをテスト中のノードにおいて時間切れさせる生存時間フィールドを有し、それによってテスト中のノードに対し第１のタイプのデータグラムの各々に応答してタイムアウトメッセージを生成させ、
ｂ）タイムアウトメッセージを処理して、該タイムアウトメッセージ間で前記テスト中のノードによって処理されたデータグラムの数を決定し、
ｃ）ノード毎にトラフィックを示すグラフに前記処理の結果をグラフィカルに表示する、
ことを含む方法。
【請求項１８】
前記ネットワークのノードにアクセスすることに関する消費者の苦情に応答して、ネットワークの経路を選択することをさらに含む請求項１７記載の方法。
【請求項１９】
前記タイムアウトメッセージを処理することは、該メッセージの前記ＩＤフィールドの値の差を計算することを含む請求項１７記載の方法。
【請求項２０】
前記タイムアウトメッセージを処理することは、前記ＩＤフィールドの値の差と前記第１のタイプのデータグラム対における前記メッセージが送信された時刻の差との比率を決定することを含む請求項１９記載の方法。
【発明の詳細な説明】
【０００１】
関連出願データ
本願は、２０００年６月２日に出願された、Arsikere等による「Method and Apparatus for Measuring Internet Router Traffic」と題する仮出願第６０／２０９，０５７号に対する優先権を主張する。
背景
本発明は、包括的にはデータネットワークに関し、より詳細にはデータネットワークに対する性能（パフォーマンス）測定に関する。
【０００２】
インターネットは、大規模で広範に使用されるデータネットワークの例である。インターネットは、しばしば異なるエンティティによって所有される多くのコンピュータを相互接続し、広く行き渡った情報交換を可能にする。ネットワークによって接続されるコンピュータは、時に「ノード」と呼ばれる。ノードは、「ルータ」または「サーバ」の形態をとる場合がある。
【０００３】
サーバは、一般にアプリケーションを実行するノードである。しばしば、それは要求時に情報を提供する。しかしながら、サーバは、ユーザコマンドに応答してデータに対しプログラムを実行するかまたはデータを格納することができる。
【０００４】
対照的に、「ルータ」は、多くの他のノードに接続され意図された宛先（行先）コンピュータの方向にデータメッセージを渡すコンピュータである。インターネット上のすべてのノードが、インターネットプロトコル（ＩＰ：Internet Protocol）を使用して通信する。インターネットプロトコルの下で、メッセージはデータの「データグラム」または「パケット」に分割される。各データグラムは、所定のフォーマットに従う。所定のフィールドの１つは、宛先アドレスである。各ノードにはアドレスが割当てられており、宛先アドレスによって、コンピュータを、データの特定のデータグラムを受信するように指定することができる。ルータは、データグラムの宛先アドレスを読み取る。そのアドレスを有するコンピュータがルータに接続されると、メッセージをそのコンピュータに直接送信することができる。
【０００５】
宛先コンピュータが、データグラムを受信するルータに接続されていない場合、ルータはデータグラムを別のルータに渡すことができる。しかしながら、時に、データグラムはその宛先アドレスに決して到達しない。データグラムが誤りを含み、存在しないアドレスを指定する可能性がある。あるいは、宛先アドレスのサーバが機能していない可能性がある。あるいは、宛先アドレスへの経路がブロック（封鎖）されている場合がある。かかるデータグラムをネットワークから除去する方法がない場合、かかるデータグラムの数は時間の経過により増大する。最終的に、ネットワークのすべてのルータが、宛先に到達することができないデータグラムを送信することのみを行うことになる。
【０００６】
これを回避するために、インターネットプロトコルでは、各データグラムがソース（送信元）アドレスと「Time To Live（生存時間）」またはＴＴＬと呼ばれるフィールドとを含むことが必要である。ＴＴＬフィールドは１から２５５の間の値に初期設定されているカウンタである。１つのルータから次のルータにメッセージが送信される度に、ＴＴＬフィールドは１だけ減少させられる。ＴＴＬフィールドが１に達すると、メッセージは別のルータに渡されない。代りに、そのルータは、その宛先フィールドに古いメッセージのソースのアドレスを有する新たなメッセージを生成する。このメッセージは、第１のメッセージのソースに対し、宛先アドレスへの経路を見つけるために非常に時間がかかったためにデータグラムがメッセージを受取らなかったと通知するデータを含む。
【０００７】
さらに、各データグラムは識別番号を有する。概して、各ソースは、送信するデータグラム毎に１だけ識別番号フィールドをインクリメントする。識別番号は、オリジナルソースコンピュータがいずれのデータグラムが受信されなかったかを識別するのに役立つ。それは、トランスポート層プロトコルによって使用されることが意図されていたが、既存の実施態様のいずれによっても使用されていない。以下により詳細に説明するように、このフィールドはまた、ネットワークの応答時間を測定する新規の方法においても使用することができる。
【０００８】
インターネットプロトコルを使用して、異なるエンティティによって操作される多くのコンピュータはすべて通信することができる。しかしながら、インターネットの分散される特質により、何かが正しく動作しない場合に特別な問題ももたらされる。
【０００９】
インターネットによって特定のコンピュータと情報を交換しようと試みるユーザは、いくつかの「管理ドメイン」を通してメッセージを伝送しなければならない。管理ドメインは、特定のエンティティによって管理されるネットワークの一部を表す。通信が失敗するかまたは長くかかり過ぎる場合、ユーザが問題の存在する場所を知ることは困難である場合がある。
【００１０】
高レベルでは、従来のインターネット通信は、５つの管理ドメインを通過するものとして考えることができる。消費者は、ＰＣ等のコンピュータを有する。ＰＣは、ユーザの制御下にあるため１つの管理ドメインを表す。ＰＣは、アクセスプロバイダネットワークを通してインターネットに接続されている。アクセスプロバイダネットワークは、ローカル（地域）電話会社またはＤＳＬプロバイダ等のアクセスプロバイダによって管理される。アクセスプロバイダネットワークは、インターネットサービスプロバイダ（ＩＳＰ：Internet Service Provider）との通信を可能にする。ＩＳＰは、インターネットへの接続を提供するＩＳＰネットワークを維持する。インターネット内では、ルータはサーバとの通信を可能にするメッセージを渡す。多くのエンティティは、インターネットにおける個々のルータを制御するが、インターネットは全体として１つの管理ゾーンとして考えることができる。サーバは、概して単一会社またはエンティティの制御下にあり、それはさらに他の管理ドメインを表す。
【００１１】
消費者は、特定のサーバと通信する問題に直面する場合、しばしばその問題がどこにあるのかを知らない。しかしながら、消費者は多くの場合、サービスに対してアクセスプロバイダまたはＩＳＰに支払いをする。ユーザが問題に直面すると、消費者はアクセスプロバイダかまたはＩＳＰによって運営されるコールセンターに電話をすることが多い。
【００１２】
コールセンターオペレータが、迅速に問題の原因に関する正確な情報を提供することができれば非常に望ましい。コールセンターを運営するエンティティによって制御される管理ゾーンに問題がある場合、問題を迅速に識別しそれが修復されるように手配することが望ましい。しかしながら、問題が別の場所にある場合、問題が異なる管理ドメインに存在することを識別できることが望ましい。タイムリな情報によって、コールセンターを運営している会社に対する負担が低減され、また顧客の不満も低減される。
【００１３】
ネットワーク問題を診断するいくつかのツールが利用可能である。「ＰＩＮＧ」は、ネットワークコンピュータにしばしばインストールされるネットワークツールである。ＰＩＮＧツールは、特定のコンピュータにメッセージを送信し、応答が受信されたか否かを判断する。このツールは、コネクション（接続）が存在することを調べることができる。しかしながら、コネクションが存在しない場合、このツールは問題の原因を示すことができない。また、このツールは、ボトルネックの原因や通信を封鎖はしないが低速にする同様の問題の原因を識別することもできない。
【００１４】
トレースルート（traceroute）は別の同様のツールである。トレースルートは、ＩＰデータグラムの生存時間（time to live）フィールドを使用する。トレースルートを実行しているソースは、特定の宛先に複数のデータグラムを送信する。第１のデータグラムでは、生存時間フィールドは１に設定される。これにより、データグラムは経路の最初のルータで生存時間が切れる。そのルータは、「データグラム時間切れ（datagram expired）」メッセージを返信する。メッセージは、そのヘッダにそれを送信したルータのアドレスを含み、それは経路の最初のルータを知らせる。トレースルートを実行しているソースは、別のデータグラムを、生存時間フィールドを１だけインクリメントして送信する。このデータグラムは、経路の次のルータで生存時間が切れ、そのルータによって「データグラム時間切れ」メッセージが生成される。連続したデータグラムが、連続的に高くなる生存時間の値が付されて送信されると、経路の連続したルータは、それらのＩＰアドレスをソースに提供して応答する。生存時間値によっては、データグラムは時間切れの前に宛先コンピュータに到達する。そのコンピュータは、「宛先到達不能／ポート到達不能（Destination Unreachable/Port Unreachable）」メッセージによりトレースルートメッセージに応答する。このように、ソースは、宛先までの経路のすべてのルータのアドレスを確定することができる。しかしながら、トレースルートは、特定のコンピュータに対する経路のみを提供する。それは、経路のノードのうちの１つにおいて過度のトラフィックによってパフォーマンスが妨げられているか否かに関しては何も示さない。
【００１５】
パフォーマンス情報は、経路のルータに格納されたＳＮＭＰ情報の使用を介して取得されてよい。ルータは、一般に、それらが渡すメッセージに関する情報を格納する。トラフィックの容量に関する統計値によって、たとえば、特定のルータに過負荷がかかり、したがってそれがボトルネックであるということが明らかになる。しかしながら、ＳＮＭＰツールを採用する問題は、それらがテスト中のルータにおいて管理特権を有するユーザのみが利用可能である、ということである。ルータは通常、コールセンターを運営するエンティティ以外のエンティティによって運営される管理ゾーンにあるため、これらツールを使用するためにルータに対する適当なアクセスが利用可能となる可能性は低い。
発明の概要
上述した背景を考慮し、本発明の目的は、コンピュータネットワークにおけるパフォーマンスに影響する問題を識別するツールを提供することである。
【００１６】
上記および他の目的は、メッセージがネットワークの特定のルータでタイムアウトとなるようにする生存時間（time to live）フィールドを有する、データの複数のデータグラムを送信することを含む方法によって達成される。データグラムを送信した時刻とタイムアウトメッセージを受信した時刻とが、記録される。タイムアウトメッセージのフィールドが検査されることにより、２つのメッセージ間でルータによって送信されたデータグラムの数が求められ、そのルータに対する負荷を求めることができる。
【００１７】
好ましい実施形態では、生存時間フィールドは、経路の種々のルータにおける負荷をテストしてボトルネックを探索することができるように、連続的に増大する。
【００１８】
さらに、好ましい実施形態では、ネットワークに接続された診断装置により診断メッセージが送信される。データグラムの宛先アドレスは、ユーザが通信の問題を有することを報告した特定のサーバのアドレスに対応する。
【００１９】
本発明は、以下のより詳細な説明と添付図面とを参照することによってより良く理解されるであろう。
好適な実施形態の説明
図１は、コンピュータネットワークを例示する。好ましい実施形態では、コンピュータネットワークはインターネット１００である。しかしながら、本発明は、ＷＡＮまたはエンタプライズワイドネットワーク等の他のネットワークに採用することが可能である。
【００２０】
インターネット１００は、消費者ネットワークを含む。簡単のために、消費者ネットワークを単にＰＣ１１５として示す。しかしながら、消費者ネットワークは、複数のコンピュータ、ワークステーション、ルータ、ハブおよび他のスイッチング（交換）装置を含むことができる。また、多くの消費者がインターネットを使用し、そのため多くのコンピュータネットワークがあることも理解しなければならない。しかしながら、簡単のために１つの消費者ネットワークのみを示す。
【００２１】
ＰＣ１１５は、アクセスプロバイダネットワーク１２０に接続される。アクセスプロバイダネットワークは、多くの形態をとることができ、アクセスプロバイダネットワークの特定のタイプは本発明に重要ではない。たとえば、アクセスプロバイダネットワークは、公衆電話交換網または専用電話線とすることができる。例示する実施形態では、アクセスプロバイダネットワーク１２０はＤＳＬ電話網である。それは、デジタル加入者ループアクセスモジュール（ＤＳＬＡＭ：digital subscriber loop access module）１２２と、メッセージをデジタル形式でルーティング（経路指定）するデータネットワーク１２４とを含む。例示する実施形態では、アクセスプロバイダデータネットワーク１２４は、インターネットプロトコルを使用して通信する。ＤＳＬＡＭ１２２は、消費者ＰＣ１１５によって送信されるデータを組込んだデータグラムを生成するかまたは消費者ＰＣ１１５にデータグラムを提供する。ＤＳＬＡＭ１２２は、コンピュータネットワーク全体における第１のノードとして考えることができる。好ましくは、データネットワーク１２４は、既知のネットワークコンポーネントを採用する。それらコンポーネントは、追加のルータかまたは他のネットワークノードを含むことができる。しかしながら、簡単のために、図１には追加のノードは示していない。
【００２２】
アクセスプロバイダネットワーク１２０は、消費者ＰＣ１１５をインターネットサービスプロバイダ（Internet Service Provider）ネットワーク１３０に接続する。ＩＳＰネットワーク１３０は時にポイントオブプレゼンス（Point of Presence）またはＰＯＰと呼ばれ、本技術分野において既知の通りである。図１において、ＩＳＰネットワーク１３０は、入口（ingress）ルータ１３２と出口（egress）ルータ１３４とを含む。公衆インターネット網（Public Internet Network）１４０から来るかまたはそこへ行くデータグラムは、ルータ１３２および１３４によって適切に送られる。
【００２３】
そして、データグラムは、公衆インターネット網１４０に渡される。公衆インターネットは、複数のノードを含む。簡単のために、ルータ１４２および１４４のみを示す。しかしながら、公衆インターネットは、多くの他のルータと他のタイプのノードとを含むことは理解されるであろう。
【００２４】
最終的に、ルータの１つがサーバネットワーク１５０に接続する。サーバネットワークもまた、ルータおよび他のタイプのコンピュータを含む多くのノードを含むことができる。簡単のために、サーバネットワーク１５０を単一サーバとして示す。サーバは、当技術分野において既知である通りである。本明細書で示す好ましい実施形態の説明のために、サーバ１５０は、消費者が消費者ＰＣ１１５からアクセスするウェブページをホストするコンピュータであるが、他のアプリケーションを実行するサーバを使用することができる。
【００２５】
また、インターネット１００は診断ユニット１１０を含むようにも示されている。インターネット診断ユニット（ＩＤＵ：Internet Diagnostic Unit）１１０は、本技術分野で既知であるようにネットワークに接続されたコンピュータとすることができる。それは、ネットワーク１００に対して適切なフォーマットでメッセージを送受信することができる。
【００２６】
ＩＤＵ１１０は、顧客コールセンター１６０の一部として示されている。当技術分野において既知であるように、コールセンターの人間のオペレータは、サービスの問題に直面している顧客からの電話を受ける。例示する実施例では、ＩＤＵ１１０は、ＩＳＰネットワーク１３０に接続さているように示されており、顧客コールセンターは、可能性として、ＩＳＰネットワーク１３０を管理するインターネットサービスプロバイダによって管理される。
【００２７】
ＩＤＵ１１０が実行するようにプログラムされている機能の１つは、後により詳細に説明する方法によるインターネットトラフィックルータ負荷テストである。かかるテストは、たとえば、特定の顧客が特定のウェブサイトにアクセスすることができないという苦情に対する顧客コールセンターオペレータからのコマンドに応じて、実行することができる。好ましい実施形態では、ＩＤＵ１１０は、特定の宛先アドレスを有するインターネット１００上のサーバである。消費者は、ＩＤＵ１１０に、それが他のサーバにアクセスすることができるのと同じ方法でアクセスすることができる。
【００２８】
ユーザによってＩＤＵ１１０に送信されるメッセージは、消費者がアクセスすることが困難だったインターネット上の特定のノードを識別する。そして、ＩＤＵ１１０は、インターネットにメッセージを送信することにより、顧客が知覚したパフォーマンス問題をもたらしている、そのサーバに及んでいるボトルネックがあるか否かを判断する。ボトルネックは、短期間にルータによって処理される非常に多くのデータグラムによってもたらされる可能性がある。
【００２９】
ルータトラフィックを測定する方法をよりよく説明するために、図２は、インターネットプロトコルにおけるデータグラム２００を示す。データグラム２００は、複数のデータフィールドを含む。メッセージは、ヘッダ部とデータ部とを含む。ヘッダは、ネットワークを通してデータグラムを経路指定するために必要な情報を提供する。宛先アドレスは、フィールド２１６において識別される。メッセージを生成しているコンピュータのソース（送信元）アドレスは、フィールド２１４において識別される。
【００３０】
フィールド２１０は、データグラムに対する識別子を含む。プロトコルによれば、コンピュータは、データグラムを生成する度に、フィールド２１０に異なる識別子を提供しなければならない。各フィールドは、所定数のビットを有する。ＩＰプロトコルにおいて、識別子フィールドは１６ビットを有する。それは、ノードが識別子フィールド２１０に同じ値を有するデータグラムを送信するまで、通常２16データグラムを取る。
【００３１】
ＩＰプロトコルの公式定義によれば、識別子フィールド２１０の値は、伝送プロトコルの上位層によって設定されなければならない。たとえば、ＴＣＰ／ＩＰとＵＤＰ／ＩＰとの両方で通信するコンピュータは、同じ識別子フィールドを有するメッセージを生成することができる。しかしながら、本発明者は、ＩＰプロトコルを実現する略すべての市販のハードウェアは、識別子がＩＰ層で設定されるように設計されている、ということを発見した。また、識別子フィールド２１０の一意の値は、各データグラムが送信される度にフィールドに配置された値を１だけインクリメントすることによって保証される。
【００３２】
このため、識別子フィールド２１０の値は、特定のノードによって送信されたデータグラムの数を求める都合のよい方法を提供する。特定のルータにおけるトラフィックを測定するために、そのルータによって送信された２つのデータグラムが受信される。識別子フィールド２１０の値の差は、それら２つのデータグラム間でそのルータによって送信されたそれら２つのデータグラムの間のデータグラムの数を示すものとして計算される。その差を、時間によって除算することにより、データグラムがノードによって処理されているレート（速度）を求めることができる。
【００３３】
ノードがネットワークの終端にある場合、ＩＤ値の差は、ノードによって送信されたメッセージの数を適当に示す。ノードがルータ等の内部ノードである場合、そのノードによって操作されたメッセージトラフィックのある部分は、ノードによって受信され転送されるデータグラムからもたらされる。データグラムが転送される場合、ＩＤフィールドの値は変更されず、これらデータグラムは、２つのデータグラムにおけるＩＤ値の差を求めた結果であるカウントに影響しない。
【００３４】
しかしながら、単にメッセージを他のノードに転送するノードでさえも、ネットワーク制御メッセージを処理する。これらメッセージは、主にＩＣＭＰおよびＳＮＭＰメッセージからなる。本発明者は、送信されたかかる制御メッセージの数が、ノードによって処理されたデータグラムの総数に比例するということが分かった。このため、２つのデータグラム間のＩＤ値の差は、ノードによって処理される総メッセージトラフィックに比例しまたはそれに反映される。比例定数は、ネットワークの終端ノードの場合と異なる可能性がある。しかしながら、特定のノードによって送信されたデータグラムにおけるＩＤフィールドの値の差は、そのノードにおけるメッセージトラフィックの指標である。
【００３５】
このため、トラフィック負荷を求める１つの方法は、ノードに対し、時間が隔てられた２つのデータグラムを送信させ、その後、ＩＤフィールドの値の変化を求めるというものである。
【００３６】
フィールド２１２は、生存時間（time to live）フィールドであり、好ましい実施形態では、ノードにデータグラムを送信させるために使用される。ＩＰプロトコルでは、生存時間は８ビットフィールドである。通常の通信では、それは、データグラムを発生しているコンピュータによって１と２５５との間の値を有するように設定される。しかしながら、６４、１２８または２５５の値が、最も頻繁に使用される。ＩＰプロトコルにおいて、生存時間フィールドは、データグラムがもたらすことができる「ホップ（hop）」の数を表す。「ホップ」は、データグラムが１つのノードから他のノードに渡されることを意味する。
【００３７】
データグラムが１つのノードから他のノードに渡される度に、ノードによって渡されるデータグラムは、入来（着信）データグラムより１だけ少ない生存時間フィールドを有する。ノードは、１にデクリメントされた生存時間フィールドを有するデータグラムを受信すると、そのデータグラムを他のルータに渡さない。代りに、ノードは、ＩＰプロトコルにしたがってデータグラムを使用することにより、新たなメッセージを生成する。メッセージは、データグラムがその宛先に到達することなく時間が切れたかまたはタイムアウトしたことを示す。
【００３８】
タイムアウトメッセージは、そのソースアドレスとして、メッセージがタイムアウトしたノードのアドレスを有する。宛先アドレスは、最初にデータグラムを送信したコンピュータである。メッセージのデータは、いずれのデータグラムがタイムアウトしたかを示す。通常、タイムアウトメッセージを受信しているノードは、適当なデータグラムを再送信する。しかしながら、本明細書で説明するように、インターネットルータトラフィックを測定しているノードは、データグラムを再送信するのではなく、タイムアウトメッセージのデータを使用してネットワークの特定のルータにおけるトラフィックを求める。
【００３９】
トラフィックを測定するために、生存時間フィールド２１２を、データグラムに対してテスト中のネットワークの特定のノードにおいてタイムアウトさせる値に設定することができる。この設定により、ノードにおけるタイムアウトによって、そのノードがメッセージ、この場合は「タイムアウト」または「データグラム時間切れ」メッセージを生成するようになる。ノードによって生成されたメッセージは、そのノードのトラフィックを求めることができるようにする情報を提供する。
【００４０】
例示する実施形態では、タイムアウトメッセージは、テスト中のノードによって送信されるデータグラムを含む。ネットワーク上でＩＰプロトコルが使用されている場合、タイムアウトメッセージのデータグラムは、図２のフォーマットを有することになる。特に、それは、ＩＤフィールド２１０を含む。上述したように、ＩＤフィールドは、通常、データグラムがルータによって送信される度にインクリメントされるカウンタによって設定される。同じソースノードによって発せられた２つの異なるメッセージを検査することにより、通常、ＩＤフィールドの差を計算することによって、それら２つのデータグラム間のそのノードによって送信されたデータグラムの数を求めることができる。
【００４１】
図３は、図１に示すようなネットワークにおいて低速のサービスに関する顧客苦情に応答するために使用されるプロセスのフローチャートを示す。実施例において、ＰＣ１１５を使用している顧客は、サーバ１５０上でホスト（ホスティング）されるウェブサイトに到達しようと試みているが、低速な応答に直面している。顧客は、自身のＩＳＰのコールセンター１６０に電話をする。コールセンターでは、オペレータが、その顧客が、特定のサーバにアクセスしようとする時に低速な応答に直面している、ということを知る。コールセンターオペレータは、顧客に対し、そのサーバの名前をＩＤＵ１１０に通信する方法について指示する。
【００４２】
好ましい実施形態では、コールセンターオペレータは、顧客に対し、ＩＤＵ１１０のネットワークアドレスまたはＵＲＬを、ＩＤＵ１１０にアクセスするパスワードと共に与える。消費者は、ネットワークによってＩＤＵ１１０にアクセスする。ＩＤＵ１１０は、ユーザに対し、顧客がアクセスを試みていたサーバ１５０の宛先アドレスまたはＵＲＬの入力を要求する。
【００４３】
そして、ＩＤＵ１１０はテストプログラムを実行する。テストプログラムは、多くの場合、ＰＣ１１５とＩＳＰ１３０との間のコネクションを検査（確認）する複数のテストを含む。それは、たとえば、ＰＣ１１５に対しデータをＩＤＵ１１０にアップロードまたはダウンロードさせる命令を送信してよい。
【００４４】
コネクションが検査されると、ＩＤＵ１１０は、消費者の問題がインターネット１４０内の特定のノードにおいてトラフィックが多すぎることの結果であるか否かの判断を試みるさらなるテストプログラムを実行することができる。図３はかかるテストの１つを示す。
【００４５】
インターネット１４０内のノードにおけるトラフィック負荷を求めるテストは、ステップ３１０において開始する。ユーザは、入力として、アクセスすることができなかったウェブサイトのＵＲＬを提供する。
【００４６】
ステップ３１２において、インターネット１４０の経路が追跡される。周知のツールにより経路を追跡することができる。「トレースルート（Trace Route）」はかかるツールの１つである。ＩＤＵ１１０は、このツールを使用して経路を確定することができる。
【００４７】
送信元ノードから宛先ノードへの経路は常に同じとは限らない。場合によっては、ハードウェア問題かまたは他の要因によって、ネットワークにおけるデータグラムの経路指定が変更される。しかしながら、時間的に近接して送信される同じソースから同じ宛先へのデータグラムは、しばしば同じ経路を辿る。しかしながら、ステップ３１２には、メッセージに対して同じ経路が使用されていることを検査するためにトレースルートツールを複数回実行することを含んでよい。異なる経路が使用されることが判定された場合、各経路に対して測定値の完全なセットが取得されるまで、図３のプロセスを複数回繰返す必要のある場合がある。
【００４８】
経路が確定されると、トラフィック負荷テストは、経路の各ノード上で実行される。ステップ３１４において、テストするために経路のノードが選択される。通常、経路は、それらが経路に現れる順序でテストされるが、特定の順序は必要ではない。
【００４９】
ステップ３１６において、ＩＤＵ１１０は、選択されたノードにおいてデータグラムをタイムアウトさせる生存時間を計算する。データグラムがＩＰプロトコルに基づく場合、生存時間フィールド２１２を、ＩＤＵ１１０と選択されたノードとの間の「ホップ」の数に基づいて設定することができる。「ホップ」は、メッセージが経路に沿って１つのノードから他のノードに渡されることを意味する。テストするために経路の連続したノードが選択される度に、生存時間フィールドがインクリメントされる。
【００５０】
ステップ３１８において、データグラムが送信される。ステップ３２０において、第２のデータグラムが送信される。両方とも、宛先として、ユーザが問題のあるアクセスを報告したサーバのアドレスを含む。また、両方とも、ステップ３１６で計算された生存時間値を含む。また、両方とも、ソースフィールドにＩＤＵ１１０のＵＲＬを含む。フィールドの多くの実際の値は重要ではないが、データグラムは好ましくは、ＩＤフィールドの値が異なる以外は同じである。
【００５１】
データグラム間の主な差異は、それらが送信される時刻である。それらは、短期間で隔てられる。好ましくは、時間は、テスト中のノードが統計的に十分な数のデータグラムを送信するのに十分長くなければならない。長い時間にわたって測定するほど、より正確な平均がもたらされる。しかしながら、ネットワーク上のメッセージは、ビットの数が有限である識別フィールドを有する。結局は、フィールドが「オーバフロー」し、識別フィールドの値のシーケンスが繰返すことになる。データグラム間で経過する期間が長すぎると、値のシーケンスが何回繰返したかを知ることが可能でなくなる。したがって、フィールドの値の差は、２つのデータグラム間に送信されたデータグラムの数を正確に示さなくなる。
【００５２】
好ましい実施形態では、連続したデータグラム間の時間間隔は、５００ミリ秒オーダである。より好ましくは、最初に間隔を小さい値に設定することができる。データグラムのペアを、データグラム間の時間を連続的に長くして送信することができる。タイムアウトメッセージにおけるＩＤ値の差がＩＤフィールドに配置することができる最大値にかなりの割合で等しくなるまで、間隔を増大させることができる。たとえば、ＩＤフィールドが１６ビットを有する場合、それが保持することができる最大値は２16である。時間間隔は、何らかの最大時間に達するまで増大してよい。たとえば、間隔を１００ミリ秒から２秒まで増大してよい。あるいは、ＩＤフィールドの値の差が２15、すなわち実施例では最大値の半分に達するまで時間を増大することができる。
【００５３】
ステップ３２２において、データグラムが送信される時刻の記録が作成される。好ましくは、時刻は、ＩＤＵに関連するコンピュータメモリに格納される。
送信されたデータグラムの生存時間フィールドの値に基づき、データグラムは、テスト中のノードにおいて時間が切れなければならない。したがって、テスト中のノードは、データグラムがそのノードで時間が切れた（終了した）ことを示すメッセージを返信しなければならない。このメッセージを送信するデータグラムは、ＩＤＵ１１０において受信される。ステップ３２４において、応答は記録される。特に、応答データグラムのＩＤフィールドが記録される。
【００５４】
判断ブロック３２６において、経路にそれ以上ノードがあるか否かがチェックされる。ステップ３１４で開始するプロセスは、テストされる経路の各ノードに対して繰返される。最終的にテストするノードがそれ以上無いと判断されると、プロセスはステップ３２８に進む。プロセスがステップ３２８に達した時、ＩＤＵ１１０は、各ノードに対して２つのデータグラム間の時間間隔を格納したことになる。また、テスト中の各ノードによって送信された２つのタイムアウトメッセージからのデータグラムのＩＤフィールドからの値もあることになる。ステップ３２８において、これら値を使用して各ノードにおけるトラフィックを計算することができる。
【００５５】
好ましい実施形態では、トラフィックは、それらが送信されている間の時間間隔の長さに対する送信されたデータグラムの数の割合として計算される。時間間隔は、ステップ３１８および３２０においてデータグラムのペアの送信間の時間である。この時間間隔は、テスト中のノードによるタイムアウトメッセージの送信間の間隔の許容可能な近似値である。
【００５６】
その間隔においてテスト中のノードによって送信されたメッセージの数は、各ノードによって送信されたタイムアウトメッセージから確定される。好ましい実施形態では、この値は、データグラムのＩＤフィールドから抽出される。ＩＰプロトコルのほとんどの実装例では、ＩＤカウンタは、データグラムが送信される度に増加される。このため、新たなデータグラムが生成されると、一意の値がＩＤフィールドにロードされる。しかしながら、その値は、送信された総データグラムのカウントを表す。
【００５７】
ネットワークプロトコルにより識別フィールド２１０のバイトの解釈が指示されていても、本発明者は、コンピュータによっては、識別値をこのフィールドの最上位バイトに最初にロードすることに気が付いた。最上位バイトに最後にロードするものもある。このため、ステップ３２８は、フィールド２１０のバイトの順序が確定されることを必要とする。
【００５８】
上述したように、ステップ３１８および３２０において夫々送信された第１のデータグラムと第２のデータグラムとの間の時間間隔が好ましくは、充分小さい状態で開始されその間隔においてテスト中のノードによって送信されたデータグラムの数はＩＤフィールドの最大値の分数となるであろう。この制約により、ＩＤフィールドの最上位バイトを容易に確定することができる。下位バイトは変化する可能性があるが、最上位バイトは変化しないはずである。
【００５９】
バイト順序を確定するために、２つのタイムアウトメッセージデータグラムのＩＤフィールドが、ＸＯＲ演算を使用して結合される。この演算は、２つの数が異なるいかなるビット位置にも論理１をもたらし、２つの数が同じいかなるビット位置にも０をもたらす。このため、それは、いずれのバイト位置が変化したかを示すことになる。フィールドの最初のバイトが変化した場合、そのフィールドは最下位バイトが最初にロードされる。一方、フィールドの最後のバイトが変化した場合、そのフィールドは最上位バイトが最初にロードされる。最初と最後のバイトが共に変化するまれなケースでは、測定が繰返されるであろう。繰返し時、ステップ３１８および３２０において送信されたデータグラム間の間隔を低減することにより、ＩＤフィールドの最上位バイトの値が変化する機会を低減することができる。
【００６０】
ＩＤフィールドのバイトの順序は、テスト中の各ノードに対して確定される。バイトの順序が確定されると、２つの値の間の差は、一方のメッセージのＩＤフィールドの値を他方のメッセージの同じフィールドの値から減算することによって迅速に計算することができる。この差は、テスト中のノードによって送信されたデータグラムの数を反映する。
【００６１】
このデータグラムの数は、ステップ３１８および３２０において送信された第１のデータグラムと第２のデータグラムとの受信の間の間隔に、テスト中のノードによって送信されたものである。それらデータグラムの送信間の時間間隔を、それらの受信間の時間差を適当に示すものと見ることができる。したがって、ＩＤフィールド値の差をステップ３２２において格納された時間で除算することにより、特定のノードにおけるトラフィックを示す値を生成することができる。
【００６２】
ステップ３３０において、結果が処理される。実行される特定の処理は、情報が使用される方法によって決まる。結果が処理されてよい１つの簡単な方法は、特定のウェブサイトへの経路における各ノードのトラフィックのグラフを表示することによるものである。図４は、かかるグラフを示す。
【００６３】
水平軸は、消費者が問題に直面した特定のウェブサイトへの経路におけるノードを示す。図４において、各ノードは、ノード１、ノード２、…等、経路におけるその順序によって単純に識別される。しかしながら、各ノードのＵＲＬを、タイムアウトメッセージにおけるソースアドレスから確定することができるということは理解されるであろう。このため、追加の情報を、ノードの順序ではなくノードのＵＲＬを示すことによって表すことができる。
【００６４】
垂直軸は、テスト中の特定のノードによって処理されたデータグラムの数を示すものである。この場合、グラフは、秒当たりのデータグラムを単位にして示す。しかしながら、それは、データグラム／分かまたは他の任意の都合のよい単位とすることができる。代替的に、ステップ３２２における記録された時刻がテスト中のすべてのノードに対して同じである場合、垂直軸は単純に、メッセージの送信間の時間に発生したメッセージの数を示すことができる。この場合、グラフは、ただ時間の尺度に対して正規化されているのではなく、各ノードにおけるデータグラムの相対数を示す。
【００６５】
かかるグラフは、単に、人間が結果を分析することができるように消費者かまたはコールセンターオペレータに提示してもよい。たとえば、図４は、ノード１０が経路の他のノードよりずっと高いトラフィックを有することを示す。顧客がウェブサイトからの低速な応答に直面している場合、図４に示すようなトラフィックパターンは、可能性として問題の原因がノード１０におけるネットワーク輻輳にあることを示す。
【００６６】
かかる処理は自動化することができる。たとえば、テスト中の各ノードにおけるトラフィックが求められると、問題の原因を示すものとして、他のノードよりトラフィックが大きいノードについて結果をサーチ（探索）することができる。あるいは、特定の閾値より上のトラフィックレベルを有するノードについて探索を行うことができる。閾値は、消費者がサービス問題について苦情を訴えた時に測定されたトラフィックレベルに基づく経験によって設定することができる。あるいは、ルータまたはコンピュータテクノロジーにおける最新の知識に基づいて閾値を設定することができる。たとえば、特定のネットワークのルータが平均して８００メッセージ／秒を処理することが既知である場合がある。この割合より上のメッセージトラフィックを、問題を示すものとして使用してよい。特定のノードを実装するのに使用されるハードウェアに関してデータを取得することができる場合、そのノードのトラフィックを、ノードに過負荷がかかっているか否かをより正確に理解するために、その特定のタイプのハードウェアに対して評価されたトラフィック値と比較してよい。
【００６７】
ネットワークの特定のノードに過負荷がかかっているか否かに関する情報は、より高いレベルのサービスの提供を容易にする。一方、特定のノードにおける高いトラフィックが顧客の使用を妨害していることを知ることにより、コールセンターオペレータは調整を行うことができる。ノードにおけるハードウェア問題を探索するために、そのノードの管理者に問合せをしてもよい。消費者およびコールセンターオペレータが管理特権を有していない異なる管理ドメインに問題が存在するために、問題を解消することができない場合であっても、問題が消費者またはＩＳＰの過失でないということを知ることは、各々に対する大幅な時間の節約となり得る。コールセンターオペレータのための時間の節約は、ＩＳＰかまたはコールセンターを管理しているアクセスプロバイダのコスト節約になる。
【００６８】
一方、顧客のサービス問題がルータトラフィックに起因しないということを知ることは、問題の位置を突き止め修正しようとしてさらなる努力が費やされなければならないことを示すものであり得る。問題の位置を突き止める際、テストが実行される順序は、通常、テストが問題の原因を明らかにする可能性とテストを行うことに関連するコストとの組合せによって指示される。このため、しばしば、ＩＳＰまたはアクセスプロバイダネットワークの基礎となるハードウェアに対するテストを実行する前に、問題の原因としてインターネット輻輳を除外することが望ましい。かかるテストによっては、たとえば、コネクションをチェックするかまたはハードウェアテストを開始するために技術者を派遣する必要のある場合がある。ルータトラフィックを測定する上述したテストは、何分もかかる可能性があり、したがって、それが非常に高価な技術者の派遣かまたは他のより立ち入ったテストの必要を無くした場合、かなりの節約を提供することになる。
【００６９】
上述したシステムの重要な利点は、特定の管理ゾーン内の問題を、そのゾーンにおける管理特権またはネットワークトポロジーの特定の知識無しに検出することができることである。説明した実施例では、消費者およびＩＳＰに関わるコールセンターオペレータは、公衆インターネット内の問題を検出することができる。
【００７０】
一実施形態を説明したが、多数の代替実施形態または変形が可能である。たとえば、メッセージをＰＣ１１５からサーバ１５０に渡すことができるように、アクセスプロバイダネットワークとＩＳＰネットワークとが共にＩＰプロトコルを使用して通信するように説明した。当業者は、通信ネットワーク内に複数のプロトコル層があることを理解するであろう。プロトコル層は、かかる層の１つである。この層の下には物理層がある。同じプロトコルが使用される場合であっても、異なる物理層が存在することができる。たとえば、アクセスプロバイダネットワークはＤＳＬである必要はない。データグラムを、従来のアナログ電話線によって伝送してＩＳＰネットワーク１３０におけるモデムによってデジタル形式に変換することができる。本発明の根底にある原理はまた、通信を伝送するために使用される物理媒体に関わりなく同じである。
【００７１】
同様に、ネットワークのより高位層は本発明には重要でない。プロトコル層は、任意のタイプのアプリケーションに対してデータグラムを伝送するように意図される。
【００７２】
さらに、ＩＰプロトコルを、それが広く使用されるプロトコルであるという理由で本発明を例示するために使用したことを理解すべきである。メッセージをあらゆるノードにおいてタイムアウトさせることができる他のプロトコルを使用することができる。ＩＰプロトコルと同様に、生存時間を、データグラムの時間が切れる前にデータグラムが許容されるべきホップの数に基づいて指定してもよい。あるいは、生存時間を、メッセージの時間が切れる時刻に基づいて指定してもよい。たとえば、各ノードがマスタクロックと同期するようなローカルクロックを有するネットワークを想定することができる。生存時間フィールドを、ローカルクロックにおける時刻として指定することができる。
【００７３】
その場合、最初の生存時間設定が同じであっても、メッセージがタイムアウトしたノードは、ネットワークにおける遅延かまたは他の要因によって決まる。適切なデータが収集されたことを確実にするために、わずかに異なる生存時間値を有する複数のデータグラムを送信することにより、複数のメッセージが各ノードから受信されたことを保証することが必要な場合がある。
【００７４】
さらに一般に、前述した方法を、ノードがある時間期間で処理したメッセージの数を何らかの方法で示すメッセージでノードが応答するように作成することが可能な任意のプロトコルで使用することができる。
【００７５】
また、本発明を、データグラムのＩＤがＩＰプロトコル層によって設定されると想定して説明していることは理解される。これは、本発明に対する限定ではなく、開示した方法は、メッセージＩＤがアプリケーション層によって設定される場合であっても有効である。
【００７６】
他のあり得る変形の例として、ＩＤＵ１１０がＩＳＰネットワークに接続されると説明した。ＩＤＵ１１０はまた、アクセスプロバイダネットワーク１２０かまたはインターネット１００の他の都合のよい場所に接続することも可能である。
【００７７】
さらに、ルータ負荷を測定する方法をＩＤＵ上で実行することは必ずしも必要ではない。要求された測定を実行するコンピュータソフトウェアは、ネットワークに接続されたほとんどすべてのコンピュータ上で実行することも可能である。特に、それは、消費者ＰＣ１１５にロードすることができる。ソフトウェアは、消費者ＰＣ１１５に永久的にインストールされるか、または必要な場合にのみＰＣ１１５にダウンロードしてもよい。
【００７８】
また、本方法を、ルータにおいてトラフィックを測定する状況で説明した。本技術を、ネットワークのノードを通過する他のタイプのメッセージで使用することができることが理解されるであろう。たとえば、スイッチ、ブリッジ、または他のタイプのノードもまた、同様に応答して、メッセージトラフィックの推定を行うことも可能である。
【００７９】
また、実施例では、トラフィックを単位時間当たりのデータグラムの数として表している。トラフィックは、他の方法で記述してよい。たとえば、トラフィックを、ノードが所定時間間隔で伝送することができるメッセージの数のパーセンテージとして表してよい。結果がいかに表されるかに関らず、それらがテスト中のノードによって処理されるデータグラムの数に決定論的に関連付けられる場合、それらをトラフィックの有用な指標とすることができる。
【００８０】
また、２つのデータグラムのＩＤフィールドの値の差を取ることによって計算された数が、メッセージの実際のカウントではなくそのノードにおいて処理されたメッセージトラフィックを示すことも理解されるであろう。この数は、ユーザに対して提示される前にいかなる数の方法で処理されてもよい。それは、たとえば、ルータによって処理されたデータグラムの総数に対するルータによって生成された制御データグラムの割合を表す係数によって、スケーリングしてもよい。かかる係数は、経験的に確定することができる。特定のノードに応じて、異なる割合を適用することができることが可能である。たとえば、可能性として、ネットワークの端部のノードは、ネットワークの内部のルータと異なる係数によってスケーリングすることがあり得る。
【００８１】
さらなる変形として、経路を確定することと経路のノードを選択することとが異なるステップであることに留意しなければならない。これらステップは別々に行われる必要はない。それらステップは、経路を検出するために使用されるメッセージを、ノードにおいて送信されたメッセージの数を計算するために使用されるメッセージのうちの最初のものとして取出すこと等によって、結合することができる。
【００８２】
さらに、ＩＤフィールドのバイトの順序は未知であると想定した。したがって、上述した方法の一部は、ＩＤフィールドのバイト順序の確定を含んでいた。順序があらかじめ既知である場合、そのステップは不要である。このため、そのステップは本プロセスに必須ではない。
【００８３】
メッセージの送信および処理の場所における他の変形が可能である。たとえば、消費者コンピュータは、テスト中のノードに対してタイムアウトメッセージを生成させるメッセージを送信してもよい。しかしながら、タイムアウトメッセージは、ＩＤＵ１１０によってインタセプトされ、応答をその時点で処理することができる。さらに、ＩＤＵは、消費者コンピュータによって送信されたメッセージを監視し、タイムアウトメッセージ間の時間間隔を計算することができるようにそれらが送信された時刻を求めてもよい。
【００８４】
したがって、本発明は、特許請求の範囲の精神および範囲によってのみ限定されなければならない。
【図面の簡単な説明】
【図１】  ルータトラフィックを測定する方法を含む診断システムを有するネットワークのブロック図である。
【図２】  インターネットプロトコルにおけるデータグラムを示すスケッチである。
【図３】  本発明による方法のフローチャートである。
【図４】  ネットワーク経路に対するテストに対し出力されたサンプルデータである。
【図１】
0004065398.tif 000002
【図２】
0004065398.tif 000003
【図３】
0004065398.tif 000004
【図４】
0004065398.tif 000005