(57)【要約】  インターネットプロトコルバージョン６（ＩＰｖ６）の統合機能、特に、拡張ヘッダに基づいて、ノード間データ転送、即ち、ネットワークホップのパフォーマンス情報を取得および報告する方法を提供する。（リアルタイム）データフローのパフォーマンスは、そのデータフロー内の選択データパケットの拡張ヘッダに特定の情報を挿入することによって、送信元−送信先の対の間で監視される。送信元クライアントで拡張ヘッダを開始することおよび送信元−送信先の経路に沿った任意の中間ノードで拡張ヘッダを更新することによって、拡張ヘッダの報告データに基づいて、ネットワークの選択ノードのその時点でのパフォーマンスレベルに関する統計情報の詳細なセットを送信先ノードが作成し得る。データフローパフォーマンスは、任意の所望するネットワーク経路またはセグメント上で、それらの経路上の特定のフローとは無関係に監視され得る。
2010515366.tif 000002
【特許請求の範囲】
【請求項１】
データネットワークのパフォーマンスレベルを監視および記録する方法であって、
（１）送信元ノードでデータフローを開始するステップと、
（２）前記ネットワークを介して前記データフローを前記送信元ノードから前記送信先ノードに転送するステップと、
（３）前記ネットワークのその時点でのパフォーマンスレベルに関する統計情報を前記送信先ノードで記録するステップとを含む、方法。
【請求項２】
前記ステップ（１）が、前記データフローのパケットに拡張ヘッダを含むことをさらに含み、前記拡張ヘッダが前記ネットワークの各ノードで集められるべきパフォーマンス情報の仕様を定める、請求項１に記載の方法。
【請求項３】
ステップ（２）が、前記送信元ノードと前記送信先ノードとの間の経路に沿った任意の中間ノードで前記拡張ヘッダを更新することをさらに含み、前記更新することが、前記拡張ヘッダによって仕様が定められる前記パフォーマンス情報を付加することを含む、請求項２に記載の方法。
【請求項４】
前記ステップ（３）が、各中間ノードに関する前記パフォーマンス情報を前記送信先ノードで記録することを含む、請求項３に記載の方法。
【請求項５】
前記パフォーマンス情報が、終端間パケット遅延、ホップ毎パケット遅延、受信されるパケット、連続パケット損失、総合パケット損失、およびパケットジッタが導出され得るデータを含む、請求項４に記載の方法。
【請求項６】
データネットワークの送信元−送信先の経路上の個々のノードのパフォーマンスレベルを監視する方法であって、
（１）送信先ノードに送信されるデータフローを送信元ノードで開始するステップであって、前記データフローがパフォーマンス情報を報告するための拡張ヘッダを備えるパケットを周期的に含む、開始するステップと、
（２）前記データネットワークを介して前記データフローに関連するパケットを前記送信先ノードに転送するステップと、
（３）前記ネットワークのその時点でのパフォーマンスレベルに関する統計情報を前記送信先ノードで決定するステップとを含む、方法。
【請求項７】
前記拡張ヘッダが前記ネットワークの各ノードで集められるべきパフォーマンス情報の仕様を定める、請求項６に記載の方法。
【請求項８】
ステップ（２）が、前記送信元ノードと前記送信先ノードとの間の経路に沿った任意の中間ノードで前記拡張ヘッダを更新することをさらに含み、前記更新することが、前記拡張ヘッダによって仕様が定められる、前記中間ノードに対応する前記パフォーマンス情報を付加することを含む、請求項７に記載の方法。
【請求項９】
ステップ（３）が、各中間ノードに関する前記パフォーマンス情報を前記送信先ノードで記録することを含む、請求項８に記載の方法。
【請求項１０】
前記記録されるパフォーマンス情報が、前記データネットワークの少なくとも１つの他のノードに配信される、請求項９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケットベースネットワーク、特に、ＩＰベースのパケットネットワークでのパフォーマンス監視に関する。
【背景技術】
【０００２】
ここ１０年間、コンピュータネットワークはサイズおよびパフォーマンス性能の両方で大きく成長した。これらのネットワークをサポートするネットワーク構成要素、例えば、ルータ、スイッチ、その他は、能力面で同様にスケールアップしたが、それらは未だに、ネットワーク構成要素への負荷がその能力を著しく超過する場合の一時的な過負荷によって生じる不定期の輻輳およびその結果生じるパフォーマンス低下に脆弱である。
【０００３】
ネットワーク構成要素のパフォーマンス低下に対する１つの回答は、サービスの品質（ＱｏＳ）監視アプリケーションの開発であった。これらのアプリケーションは、ネットワークパフォーマンスを監視し、ノード輻輳、パケット遅延、またはネットワークのリンク切れ等の問題を診断するために使用される。この種類の監視アプリケーションは、より大きな一連の運用、管理およびメンテナンス（ＯＡＭ）アプリケーションのうちのほんの一部であるとみなされ得る。ＯＡＭは、運用を簡易化して運用費用を低減するためにネットワークで使用される機構に言及している。それは、ネットワークパフォーマンスの検証および障害回避のためにも使用され得る。
【０００４】
ネットワークのパフォーマンスを監視するために、様々なＯＡＭアプリケーションまたはユーテリィティが現在利用可能である。広く使用されているＯＡＭユーテリィティの１つは、ＩＰベースのパケットネットワークのためのＰＩＮＧ機構である。ＰＩＮＧは、一連のパケットを送信先に送信し、パケットの戻りに基づいて、パケットの送信元と送信先との間の総合遅延および総合パケット損失数等の統計値を報告する。よく知られている別のＯＡＭユーテリィティはＴＲＡＣＥＲＯＵＴＥである。ＴＲＡＣＥＲＯＵＴＥは、送信元と送信先との間にある各ノードまたはルータのリスティングを提供し、さらに、送信元と各中間ノードとの間にある遅延サンプルを提供する。ＰＩＮＧおよびＴＲＡＣＥＲＯＵＴＥによって用いられる、インターネット制御通知プロトコル（ＩＣＭＰ）に基づく遅延測定技術は、経路に沿ったルータでの処理遅延にばらつきが非常に出やすいため、絶対的パフォーマンスの信頼できないインジケータとして知られている。ＰＩＮＧおよびＴＲＡＣＥＲＯＵＴＥは、正確なパフォーマンス検証ツールとしてではなく、むしろ接続性検査および粗い遅延見積もりのために設計された。
【０００５】
別のパフォーマンス監視ツールは、特定のネットワーク上の各ルータに関する管理情報ベース（ＭＩＢ）を利用する。各ルータが、入パケット数、出パケット数、およびインターフェース当たりまたはトラフィッククラス当たりでの総合遅延等の総統計値を集める。この統計情報は、その特定のルータに関するＭＩＢに保存される。この情報は、通常、ＳＮＭＰ等のプロトコルを介してネットワークパフォーマンス管理プラットフォームによって集められる。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述されたメンテナンスツールは、総合的なネットワークパフォーマンスまたはネットワーク内の個々のルータの総合的なパフォーマンスを監視するために有用であるが、単一のデータフローに関するネットワークパフォーマンスの監視に対する手段は提供しない。それらは、一定時間、例えば、一日に渡るネットワーク構成要素のパフォーマンスのスナップショットを単に提供するだけであり、全期間の間で種々の統計値を示す。必要とされているのは、ネットワークのノードを介して、単一のデータフローを一度に１つのネットワークホップずつ追跡し、個々のデータフローに特有のパフォーマンス情報を記録することによって、ネットワークのパフォーマンスを監視するために使用され得るメンテナンスツールである。
【課題を解決するための手段】
【０００７】
本発明は、インターネットプロトコルバージョン６（ＩＰｖ６）の統合機能、特に、拡張ヘッダに基づいて、ノード間データ転送、即ち、ネットワークホップのパフォーマンス情報を取得および報告する方法を提供する。（リアルタイム）データフローのパフォーマンスは、そのデータフロー内の選択データパケットの拡張ヘッダに特定の情報を挿入することによって、送信元−送信先の対の間で監視される。さらに、データフローパフォーマンスは、任意の所望するネットワーク経路またはセグメント上で、それらの経路上の特定のフローとは無関係に監視され得る。
【０００８】
第１の実施形態では、データフローの送信元ノードがそのフローに属するパケットの中にホップ毎の拡張ヘッダを周期的に挿入し、このフローの送信元−送信先の経路上の各ノードがこの拡張ヘッダを更新する。この拡張ヘッダは、データフローの経路上の各ノードによって報告されるべきシーケンス番号およびＱｏＳメトリクスの識別子を含む「サービスの品質（ＱｏＳ）報告」オプションを含む。シーケンス番号およびＱｏＳメトリクスの識別子は、データフローの送信元ノードで動作する監視機能によって挿入される。拡張ヘッダのＱｏＳ報告オプションは、送信元−送信先経路上の全ての経路ノードで更新される。データフローの経路上の各ノードは、タイムスタンプ、受信されるパケット、連続パケット損失数、その他の情報を（拡張ヘッダに）記録する。ひとたび拡張ヘッダを搬送するパケットが送信先ノードに到達すると、上記のホップ毎の情報の全てが送信先側の監視機能によって受信される。この情報を受信すると、送信先側の監視機能は、経路に沿ったホップの各々に関する詳細なパフォーマンスプロファイルを集める。タイムスタンプは、経路に沿って遭遇した総合遅延と、個々のホップ毎の遅延との両方を決定するために使用される。連続するルータで受信されるパケットの差異は、ホップ毎のパケット損失を決定する。連続パケット損失等の他の任意の所望するパフォーマンス特性を決定するために、付加的な記録情報が同様に使用される。
【０００９】
第２の実施形態では、上述と同様のプロセスを使用することによって、ネットワークの任意のノードが、独立したネットワーク経路監視フローを生成可能である。しかしながら、既存のデータフローの監視とは対照的に、経路のパフォーマンスを試験するためだけにノードがデータフローを開始する。この試験プロセスは、データフローが存在するか否かに関わらず、ネットワークで特定経路のパフォーマンスを監視するために散発的に使用され得る。上述と同様に、送信先ノードが拡張ヘッダに含まれている情報を収集し、ネットワークパフォーマンスの概要を作成するためにその情報を編集することが可能である。
【図面の簡単な説明】
【００１０】
【図１】本発明の原理による、ローカルエリアネットワークを示すブロック図である。
【図２ａ】ＩＰｖ６標準によるデータパケットを示す図である。
【図２ｂ】ＩＰｖ６標準による拡張ヘッダのオプション部分を示す図である。
【図３】本発明の特定の実施形態を示すフローチャートである。
【図４ａ】本発明による、送信元クライアントによって生成されるホップ毎の拡張ヘッダを示す図である。
【図４ｂ】本発明による、送信先に向かう経路上のルータによって修正された後のホップ毎の拡張ヘッダを示す図である。
【図４ｃ】本発明による、空のＱｏＳ報告オプションを備えたホップ毎の拡張ヘッダを示す図である。
【発明を実施するための形態】
【００１１】
本発明は、ＩＰｖ６ネットワークの監視およびメンテナンスを改善するために、ホップ毎の拡張ヘッダのＩＰｖ６特性を利用するプロセスを提供する。図１は、単純なデータネットワーク１００を示す。送信元クライアント１０５が、ルータ１１０ａ−ｄを利用することにより送信先クライアント１１５にパケットを送信する。送信元クライアント１０５は、送信先クライアント１１５のネットワークアドレスである送信先アドレスをデータパケットにアドレス指定する。ルータ１１０ａがパケットを受信して、送信先アドレスを検査する。データパケットの最終的な送信先でないことを判定した後、ルータ１１０ａがこのパケットをルータ１１０ｂに転送する。このプロセスは、パケットが送信先クライアント１１５に到達するまでルータ１１０ｃおよび１１０ｄを通じて続く。
【００１２】
クライアント１２０ａ−ｄが、同様にネットワーク１００に動作可能に接続されており、同様にネットワーク通じてデータパケットを送信可能である。これらの追加のデータフローは、任意の個々のルータ１１０ａ−ｄが、送信元クライアント１０５から送信されているパケットを受信する際の混雑状態をもたらし得る。これは、輻輳ルータでのパケット遅延および起こり得るパケット損失を生じさせる。
【００１３】
ネットワークパフォーマンスを監視するために既存の技術を使用することによって、送信元クライアント１０５は、送信先クライアント１１５から単一のデータフローに関する総合遅延および総パケット損失を取得し得るが、クライアント１０５と１１５との間の単一のデータフローに関する個々のルータのパフォーマンスは利用不可能である。
【００１４】
本発明では、送信先クライアント１１５に送信されるデータフローに属する送信パケット中に、送信元クライアント１０５がホップ毎の拡張ヘッダを周期的に挿入する。これ以降、拡張ヘッダと呼ぶ、このホップ毎の拡張ヘッダは、ＱｏＳ報告オプションを含み、ＱｏＳ報告オプションは、ネットワークのデータフローを追跡するために使用される送信元クライアント１０５によって指定されるシーケンス番号を含む。拡張ヘッダは、集められるべき、そのフローに関する種々の統計データの識別子を同様に含む。そのデータフローの経路上のノードによって報告されるべき統計データの識別子に加えて、送信元クライアントは、拡張ヘッダ内の対応するフィールドにこれらのデータの初期値を同様に含む。拡張ヘッタは、送信元クライアントが要求するデータフローに関する局所的に集められた統計データを含むように、ルータ１１０ａで更新される。これは、送信元クライアント１０５と送信先クライアント１１５との間の残りのルータの各々を通して続く。ひとたび送信先クライアント１１５がパケットを受信すると、それは、パケットの拡張ヘッダに含まれる蓄積データに基づいて一連のパフォーマンス統計値を構成し得る。データフローの監視のプロセスは、以下の図３の説明中でより詳細に説明される。
【００１５】
図２ａは、ＩＰｖ６によって標準化されたデータパケットを示し、以下のフィールドを含む：バージョンフィールド２０１、トラフィッククラスフィールド２０２、フローラベルフィールド２０３、ペイロード長フィールド２０４、次ヘッダフィールド２０５、ホップ限界フィールド２０６、送信元アドレスフィールド２０７、送信先アドレスフィールド２０８、次ヘッダフィールド２０９、ヘッダ拡張長フィールド２１０、次ヘッダフィールド２１１、ヘッダ拡張長フィールド２１２、およびデータフィールド２１３。本発明は、ＩＰｖ６で導入されている拡張ヘッダを特に活用する。ＩＰｖ６仕様は、６種類の拡張ヘッダ：ホップ毎、経路、フラグメント、送信先オプション、認証、カプセル化セキュリティペイロードを可能にする。ホップ毎および経路拡張ヘッダを除き、他の拡張ヘッダは全て、ＩＰｖ６ヘッダの送信先アドレスによって指定されるノードによってのみ処理される。経路拡張ヘッダは、送信元経路指定のために、即ち、訪問すべき中間ノードをリストするために、使用される。同様に、ホップ毎拡張ヘッダは、各中間ルータによって処理される。しかしながら、ＩＰｖ６標準は、フォーマット／構成の仕様を定めるだけであり、これらの拡張ヘッダのいかなる特定の使用を提案するものでないことに留意されたい。
【００１６】
拡張ヘッダは、図２ａに示されるように次ヘッダフィールドを使用して１つにまとめられ得る。データパケットが複数の拡張ヘッダを含む場合、１つの拡張ヘッダの次ヘッダフィールドは、次の拡張ヘッダを指し示す。最終的に、この配列中の最後の拡張ヘッダの次ヘッダフィールドは、ＴＣＰまたはＵＤＰ等のトランスポート層プロトコルのヘッダおよびＩＰパケットの実際のペイロードを指し示す。次ヘッダフィールドが利用される場合、パケットの受信者は、次の拡張ヘッダが関連情報を有することを推測する。そのようなシステムを採用する理由は、付加的なサービスを基本サービスから分離し、それらを拡張ヘッダに入れ、さらにそれらの機能によって拡張ヘッダを分類するためである。そのようにすることによって、個々のルータにかけられる負荷が減少され、諸機能の柔軟な付加を可能にするシステムが確立される。
【００１７】
図２ｂは、以下のフィールド：オプション型フィールド２２０、オプション長フィールド２２１、およびデータフィールド２２２を含むホップ毎拡張ヘッダのオプション部分を示す。これ、即ち、オプション、特性を活用することによってホップ毎拡張ヘッダに様々な種類の情報が報告され得る。本発明は、タイムスタンプ、受信されるパケット、連続パケット損失、および監視プログラムがネットワークパフォーマンスを監視するために要求し得るその他の統計データ等の情報を報告するためにこの特性を利用する。ヘッダおよびオプション生成および更新の具体的な詳細は、以下で図３の説明中で説明される。
【００１８】
図３は、本発明の特定の実施形態による、クライアントおよびルータ等のネットワークエンティティの動作を概略的に表すフローチャートを示す。ステップ３００で、図１のクライアント１０５等の送信元クライアントがデータフローを開始する。データフローの最初のパケットでは、送信元クライアントがそのパケットを、図１のクライアント１１５のアドレス等の送信先アドレスにアドレス設定する。この例では、送信元クライアント１０５は、経路上のルータの識別ならびにそれ自身と送信先クライアント１１５との間のホップ毎のパケット遅延およびパケット損失の監視に関心を持っている。
【００１９】
図４ａ、図４ｂおよび図４ｃは、以下のフィールド：ＩＰｖ６固定ヘッダ４０１、ホップ毎拡張ヘッダ４０２、次ヘッダフィールド４０３、ヘッダ拡張長フィールド４３０、オプション型フィールド４０４、オプション長フィールド４０６、シーケンス番号フィールド４０８、ノード報告の数フィールド４１０、メトリクスの数フィールド４１２、ノード位置フィールド４１４、識別子１フィールド４１６ａ、識別子２フィールド４１６ｂ、識別子３フィールド４１６ｃ、アドレスフィールド４１８、タイムスタンプフィールド４２０およびパケットカウントフィールド４２２を含むＩＰｖ６データパケット４００を示す。
【００２０】
このパフォーマンス監視を容易化するために、図４ａに示されるように、送信元クライアントがデータパケット４００内にホップ毎拡張ヘッダ４０２を生成する。本発明によれば、ＱｏＳ報告ヘッダとして使用される拡張ヘッダを示すために、特別なオプション型（１バイト）が使用される。従って、送信元クライアント１０５がＱｏＳ報告ヘッダを示すためにオプション型フィールド４０４を埋める。オプション長フィールド４０６がオプション型フィールド４０４に続く。オプション長フィールド４０６は、拡張ヘッダのＱｏＳ報告部分の長さを示すためにクライアントによって使用される。このＱｏＳ報告部分は、図４ａの影付部分によって示されている。オプション長フィールド４０６の後に最初に現れるフィールドはシーケンス番号フィールド４０８である。
【００２１】
送信元クライアント１０５が所与のデータフローに対してＱｏＳ報告を開始する場合、そのデータフローに関連する第１のパケットのＱｏＳ報告拡張ヘッダのシーケンス番号フィールド４０８が０に設定される。その後、ＱｏＳ報告拡張ヘッダを備える、そのデータフローに関連するパケットが、送信元クライアント１０５によって送信される際には常に、「シーケンス番号」フィールドが１ずつ増加される。
【００２２】
「ノード報告の数」フィールド４１０は、送信元クライアントによって１に設定され、そのＱｏＳ報告データを拡張ヘッダに含む、送信先への経路上の全てのノード毎に１ずつ増加される。送信元クライアント１０５は、次のフィールド「メトリクスの数」フィールド４１２を、それがネットワークノードに報告を望むＱｏＳ関連データの数で埋める。本例では、送信元クライアント１０５が（１）送信先クライアントへの経路上に出現するノードの識別またはアドレス、（２）パケットが各ホップを横断するのに要する時間、および（３）ホップ毎のパケット損失に関心を持っているので、このフィールドが送信元クライアント１０５によって３に設定される。
【００２３】
「メトリクスの数」フィールド４１２の後に出現するフィールドは「ノード位置」フィールド４１４とみなされる。送信元クライアント１０５は、このフィールドを１つの「０」で埋め、それは、送信元クライアントと送信先クライアントとの間のデータ経路上での自分の位置である。ネットワークノードに所望のパフォーマンスデータを収集および報告させるように指示するために、送信元クライアントは、報告されるべきデータを識別するためにコードを使用する。このコード、図４ａで識別子とラベルされているフィールド４１６ａ、４１６ｂおよび４１６ｃは、ＱｏＳ報告オプションの対応するデータの常に前に位置する。識別子１フィールド４１６ａは、第１の報告されるデータがノードアドレスになることを示すために使用される。フィールド４１６ａに続き、フィールド４１８が報告ノード全アドレスを報告するために使用される。実際のパケットでは、フィールド４１８が、１６個の連続バイトのデータを含むことに留意されたい。図４ａの描写方法だけが理由で、一般的慣習に従って、行毎に４バイトが示されており、それによりフィールド４１８が４行に渡って広がっているように見えている。アドレスフィールド４１８に続くのは識別子２フィールド４１６ｂである。ここで、識別子２は、報告する第２のデータがタイムスタンプであることを示すために使用される。フィールド４２０は、タイムスタンプを報告するために使用される。再度、フィールド４２０が２行に渡って広がっているように見えるが、それは実際のパケットの４個の連続バイトを含む。タイムスタンプフィールドに続くのが識別子３フィールド４１６ｃである。このフィールドは、報告する第３のデータがパケットカウントであることを示すためにラベル付けされている。続くフィールド４１６ｃは、パケットカウントフィールド４２２である。パケットカウントフィールド４２２は、同様に、図４ａでそれが２行に渡って広がっているように見えるが、４個の連続バイトを含む。図４ａでは、１バイトコードが識別子に対して使用されている。しかしながら、報告する必要のあるデータを識別するために、任意の適切な長さが使用され得ることは明白であろう。同様に、任意の適切な長さがタイムスタンプおよびパケットカウントのフィールドに割り当てられてよい。
【００２４】
送信元クライアントが各識別子フィールドを適切に埋めた後、この送信元クライアントは、ＱｏＳ報告拡張ヘッダを備える第１のパケットを送信する前にアドレスフィールド４１８を自分のネットワークアドレスで埋め、自分の時刻によってタイムスタンプフィールド４２０を埋め、「パケットカウント」フィールド４２２を１に初期化する。この時点から、送信元クライアントは、フローに関して送信さるパケットの総数を追跡記録し、そのフローに属するパケットにＱｏＳ報告拡張ヘッダを挿入する際は常に、「パケットカウント」フィールドをそのような最新のパケットカウントで埋める。タイムスタンプフィールド４２０は、その時点でのクロック時刻で埋められる。
【００２５】
ＱｏＳ報告オプション内の所望のフィールドの全てが作成されて埋められた後、送信元クライアント１０５は、拡張ヘッダの全長を示すために使用されるヘッダ拡張長フィールド４３０等のパケットヘッダの残りを埋め、次にパケットをその経路上の次のノード、例えば、ルータ１１０ａに向けて送信する。
【００２６】
図３のステップ３０５で、図４ａの影付部分で示されるようなＱｏＳ報告オプションを搬送する拡張ヘッダ４０２を備えるデータパケット４００を図１のルータ１１０ａが受信する。経路ノードは、データフローの最初のパケットを試験し、最初に送信先アドレスを検査する。データフローの送信先を判定した後、経路ノードは、拡張ヘッダ、具体的にはホップ毎拡張ヘッダ４０２を検査する。拡張ヘッダに含まれるオプション型フィールド４０４を検査することによって、経路ノードは、拡張ヘッダが、統計的パフォーマンスデータを集めるために使用されるホップ毎拡張ヘッダであると決定する。ルータ１１０ａは、メトリクスの数フィールド４１２ならびに識別子フィールド４１６ａ、４１６ｂおよび４１６ｃに基づいて、対応するデータフローに関して何の特定のパフォーマンスデータが監視および報告される必要があるかを決定する。
【００２７】
識別子フィールドで示されるように、監視されるべきデータは、ノードアドレス、送信前の時点でのパケットのタイムスタンプ、データフローに関するパケット総数である。それゆえに、ルータ１１０ａは、このデータフローに関して受信されるパケットの数を追跡記録するためにカウンタを設定し、そのデータフローに属する第１のパケットが受信されたばかりであるため、それを１に初期化する。このカウンタは、そのデータフローに属するパケットがルータ１１０ａによって受信される際、常に更新される。
【００２８】
図４ｂは、ルータ１１０ａがＱｏＳ報告オプションを更新した後に、ホップ毎拡張ヘッダ４０２がどのように見えるかを示す。第１に、ルータ１１０ａが「ノード報告の数」フィールド４１０を１だけ増加し、それにより今それが２に等しい。ルータ１１０ａは、次に、要求されるデータを報告するのに必要な適切なフィールドおよび対応する識別子をＱｏＳ報告オプションに追加する。最初に、それは新規の「ノード位置に関する識別子」フィールド４３４を追加し、ルータ１１０ａの経路での位置を示す１でそのフィールドを埋める。次に、ルータ１１０ａは、報告データに関して送信元クライアント１０５と同様なステップを続ける。第１に、ルータ１１０ａはノードアドレスに関する識別子を含み、自分のネットワークアドレスを提供する。次に、ルータ１１０ａは、タイムスタンプに関する識別子を含み、その時点でのクロック時刻を含む。最後に、この例では、ルータ１１０ａは、パケットカウントに関する識別子を含み、その時点でのパケットカウントを含む。要求されているデータの報告後、ルータ１１０ａは、今では送信元クライアント１０５およびルータ１１０ａによって埋められたデータを示す、ＱｏＳ報告オプションフィールドの新しい長さを反映するためにオプション長フィールド４０６を設定する。
【００２９】
ルータ１１０ａは、次に、拡張ヘッダに付加される情報を反映するために「ヘッダ拡張長」フィールド４３０を適切に設定し、図３のステップ３１０に示されるように、送信先に向けて次のホップにパケットを転送する。上述と同様に、ステップ３１５で、次の受信ノードが送信先アドレスを検査し、それがデータフローの最終的な送信先であるか否かを判定する。次の受信ノードが最終的な送信先でない場合、プロセスがステップ３０５に戻り、その後すぐにルータ１１０ａに関連して説明されたのと同様の動作が実行される。一方、受信ノードが意図する受信者である場合、プロセスがステップ３２０に進む。
【００３０】
ステップ３２０で、データフローに関する送信先ノード、本例の送信先クライアント１１５がＱｏＳ報告拡張ヘッダを備えるデータパケットを受信する。このデータパケットがＱｏＳ報告拡張ヘッダを備える第１のパケットである場合、送信先クライアントは、送信元クライアント１０５が望むパフォーマンスデータを集めて編集するために、テーブル、カウンタ、その他を設定する。その後、ＱｏＳ報告拡張ヘッダを有する、データフローに属する各パケット毎に、データ経路の種々のノードによって拡張ヘッダに報告されるパフォーマンスデータを送信先クライアント１１５が集め、所望のパフォーマンス測定値を取得するためにこのデータを処理する。本例では、この処理は、ヘッダに報告されているデータ経路上のノードアドレス、現在時刻と送信元クライアント１０５によって報告されるタイムスタンプとの差異に等しい終端間パケット遅延、ノードとデータ経路上でその前にあるノードとによって報告されるタイムスタンプの差異に等しいホップ毎パケット遅延、送信元クライアントによって報告されるパケットカウントと送信先クライアントによって測定されるパケットカウントとの間の差異に等しい総合パケット損失、およびノードとデータ経路上でその後にあるノードとによって報告されるパケットカウントとの間の差異に等しいホップ毎パケット損失を記録することを含む。ひとたび送信先ノードが所望のパフォーマンスデータを有すると、それはネットワーク構造に応じて種々のことを実行可能である。種々の可能性は、送信元ノードに送信先ノードがデータを送信し返すこと、ネットワーク上のあらゆるノードが情報にアクセス可能である中央記憶サーバに送信先ノードがデータを送信すること、またはネットワークの全ノードに送信先ノードが情報をブロードキャストすることを含む。
【００３１】
この第１のパケットを送信した後、送信元クライアントは、周期的に、例えば、１００パケット毎に一度、データフローに属する送信パケットにＱｏＳ報告拡張ヘッダを挿入する。データ経路上のノードが、ＱｏＳ報告オプションを搬送するホップ毎拡張ヘッダを備えるパケットに遭遇する際に常に、それは、上述したやり方で、その送信元によってパケットの中に含まれるパフォーマンスメトリクスに対応するその局所的なパフォーマンスデータを報告する。
【００３２】
送信元クライアントがＱｏＳ報告オプションを備えるパケットを送信する際に、毎回、第１のパケットのＱｏＳ報告拡張ヘッダに含まれていたパフォーマンスメトリクスの全てを含む必要はない。例えば、送信元クライアントが２００パケット毎にパケット損失に関して、且つ１００パケット毎にパケット遅延に関して報告を望む場合には、それは以下のステップを実行し得る。第１に、それが毎回１００番目の送信パケットにＱｏＳ報告拡張ヘッダを含み得る。しかしながら、そのような全ての拡張ヘッダに、パケット遅延が推測されるタイムスタンプメトリクスが含まれ、一方、そのような拡張ヘッダに１つおきにパケットカウントメトリクスが含まれる。ノードアドレスフィールドは、同様に、全てのＱｏＳ報告拡張ヘッダに含まれる必要はない。この特性は、ネットワークエンティティが、任意の所望する頻度で種々のパフォーマンスメトリクスを報告および編集することを可能にし、従って、パフォーマンスデータ収集プロセスに柔軟性および効率性を提供する。
【００３３】
ＱｏＳ報告拡張ヘッダが「空」のＱｏＳ報告オプションを備えるようにすることも同様に可能であり、それは「シーケンス番号」フィールド以外に何も含まず、それは前述したように送信元クライアントによってオプションフィールドに入れられる。図４ｃは、空のＱｏＳ報告オプションを備えるホップ毎拡張ヘッダの概略を示す。空のＱｏＳ報告オプションがパフォーマンス報告に関するいかなるフィールドも含まないため、それは送信元と送信先との間の経路上のいかなるノードによっても変更されない。しかしながら、空のＱｏＳ報告オプションに含まれるシーケンス番号フィールドは、所定の有用なパフォーマンスメトリクスを取得するために活用される。例えば、送信元クライアントがデータフローに関する「連続パケット損失」に関心がある場合、それは、そのフローに属する全てのパケットに、空のＱｏＳ報告オプションを備えるホップ毎拡張ヘッダを含み得る。このオプションに含まれる「シーケンス番号」フィールドは、経路上のノードおよび送信先クライアントが、そのフローに関する連続パケット損失を判定するのに役立つ。「連続パケット損失」識別子および連続パケット損失を報告するためのフィールドを、その送信パケットのＱｏＳ報告オプションに周期的に含めることによって、送信元クライアントは、データ経路上のノードに対して、それらが記憶している連続パケット損失値を送信先クライアントに報告するように促すことが可能である。従って、例えば、１００パケット毎に連続パケット損失が報告されることを送信元クライアントが希望する場合、以下のようになされ得る：最初に、送信元クライアントは、データフローに属する第１のパケットと１００番目のパケット毎とに、連続パケット損失フィールドを備えるＱｏＳ報告オプションを含み、その後、そのデータフローに属する他の全てのパケットに空のＱｏＳ報告オプションを含む。これは、定義済みのペイロードを備えるデータフローを実際に送信することなしに、送信元クライアントがネットワークの所与のノードのパフォーマンスを監視することを可能にする。所与の一連のパケットに渡って、ノードは、複数のバラバラの連続パケット損失のインスタンスを経験し得る。例えば、あるデータフローの１００個のパケットシーケンスに渡って連続パケット損失の２つのインスタンスを経験し得て、５個の連続パケットが第１のインスタンスで損失し、１０個が第２のインスタンスで損失している。残りの８５個のパケットは適切に受信されている。そのような場合、ノードが所与のデータフローに関する連続パケット損失フィールドを埋める際に、連続パケット損失カウントのより大きい方を報告する。従って、本例では、それは連続パケット損失フィールドを値１０で埋める。
【００３４】
図３、図４ａ、図４ｂおよび図４ｃで示される実施形態は、単に例示を目的として示されている。当業者は、さらなる実施形態および利点が上記で完全に示されていないことを認識するであろう。例えば、本発明の別の実施形態は、特定のネットワークセグメント上のノードから試験データフローを散発的に送信することを含む。この試験データフローは、フローが単にパフォーマンスを監視するために使用されるため、実際のデータがフローに含まれないこと以外は、図３、図４ａ、図４ｂおよび図４ｃで説明される上述の実施形態と同様である。
【００３５】
本発明の特定の好適な実施形態が説明されてきたが、これらの実施形態は、例示のみを目的として示されており、本発明の範疇を限定することを意図しない。従って、本発明の広さおよび範疇は、以下の特許請求の範囲およびそれらの同等物によってのみ規定されるべきである。
【図１】
2010515366.tif 000003
【図２ａ】
2010515366.tif 000004
【図２ｂ】
2010515366.tif 000005
【図３】
2010515366.tif 000006
【図４ａ】
2010515366.tif 000007
【図４ｂ】
2010515366.tif 000008
【図４ｃ】
2010515366.tif 000009
【国際調査報告】
2010515366.tif 000010
2010515366.tif 000011
2010515366.tif 000012