JP5719449B2 - Ｉｐパスの利用可能な容量及び狭リンク容量を単一のエンドポイントから測定するためのシステム及び方法 - Google Patents

Description

本発明は、インターネットプロトコル（ＩＰ）ネットワーク及び関連付けられる方法に関し、特に、そのようなネットワークにおいてＩＰパスの利用可能な容量及び／又は狭リンク（tight link）容量を測定するための技法に関する。

過去数年の間に、日々の通信においてモバイルコンピューティング装置及び地上線／有線コンピューティング装置を用いることへの関心は高まってきた。デスクトップコンピュータ、ワークステーション、及び他の有線コンピュータは、今や、例えば電子メール、ビデオ会議、及びインスタントメッセージ（ＩＭ）を介してユーザが通信することを可能にする。モバイル装置、例えば、携帯電話、ハンドヘルドコンピュータ、ＰＤＡ（personal digital assistants）等も、電子メール、ビデオ会議、ＩＭ等を介してユーザが通信することを可能にする。携帯電話は、従来、音声通信装置としての役割を果たしてきたが、技術的な進歩を通じて、近年はデータ、画像等を通信するための効果的な装置であることを証明している。異なるプラットフォームにわたるシームレスな通信へのユーザ需要が増加するにつれて、無線技術及び地上線技術は、より統合された通信システムへと融合し続けている。

種々のサービスを提供するためにインターネットプロトコル（ＩＰ）ネットワークが用いられている新たな及び様々な手法に適合するために、新たなアクティブ計測技法が、サービス性能を検証するために開発され及び標準化されつつある。１つ以上のＩＰネットワークにわたるパス上で（輻輳しているか否かを問わず）どのくらいの容量が利用可能であるかをリアルタイムで知得することは、ネットワーク事業者又はアプリケーションユーザに有益な情報である。利用可能なパス容量の測定値は、ネットワークの特性化及びアプリケーション性能の推定のために用いられることができる。例えば、利用可能なパス容量メトリックは、ネットワークのモニタリング、トラブルシューティング、サーバ若しくはゲートウェイの選択、アドミッションコントロールのために、又はネットワークプロバイダにわたって提供される保証された若しくはビジネスクラスのサービスのサービスレベルアグリーメント（ＳＬＡ）を単に検証するために用いられることができる。

ネットワークパス（又はパスセグメント）のアクティブプローブベースのサンプリングは、当該パス（及びパスセグメント）上の利用可能なＩＰレイヤの帯域幅容量の状態についての推測を行うための実行可能な方法論として確立されてきた。利用可能なパス容量及び狭リンク（tight link）容量といったＩＰレイヤ性能メトリックは、ＩＥＴＦ及びＩＴＵ−Ｔを含む多くの標準化団体において定義されてきた。ＩＰレイヤの利用可能なパス容量（ＡＰＣ：available path capacity）は、トランスポートプロトコル、ポート番号、パケットサイズ及びＤｉｆｆｓｅｒｖコードポイント（ＤＳＣＰ）に対応するタイプＰパケットとして知られる所与のパケットタイプについての、ソースホストと宛先ホストとの間の利用可能なＩＰレイヤの帯域幅容量として定義される。ＩＰレイヤの狭リンク容量は、トランスポートプロトコル、ポート番号、パケットサイズ、及びＤｉｆｆｓｅｒｖコードポイント（ＤＳＣＰ）に対応するタイプＰパケットとして知られる所与のパケットタイプについての、ソースホストと宛先ホストとの間のパスでＩＰレイヤの利用可能なリンク容量が最も小さいリンクのＩＰレイヤ容量と定義される。ＩＰレイヤの狭リンクのＩＰレイヤの利用可能なリンク容量はＩＰレイヤの利用可能なパス容量と等しいことに留意されたい。

ＩＥＴＦのＩＰＰＭ（IP Performance Metrics）ワーキンググループは、２つのＩＰアクティブ測定プロトコル定義している：ＯＷＡＭＰ（One-Way Active Measurement Protocol）及びＴＷＡＭＰ（Two-Way Active Measurement Protocol）である。ＯＷＡＭＰは、２つのホスト間における一方向のパケット遅延及び一方向のパケットロスについて設計されている。ＴＷＡＭＰは、ＯＷＡＭＰに基づいており、２つのホスト間における一方向及び双方向（往復）のパケット遅延及びパケットロスについて設計されている。

ＴＷＡＭＰプロトコルは、２つのプロトコルを含む：ＴＷＡＭＰ制御プロトコル及びＴＷＡＭＰテストプロトコルである。ＴＷＡＭＰ制御プロトコルは、ＴＷＡＭＰテストセッションを初期化し、開始し及び終了するために用いられる。ＴＷＡＭＰテストプロトコルは、２つのＴＷＡＭＰホスト又はエンドポイント間においてＴＷＡＭＰテストパケットを交換するために用いられる。テストセッションは、ＴＷＡＭＰ制御プロトコル無しに構成されることもでき、これはＴＷＡＭＰ ｌｉｇｈｔとして知られる。

ＴＷＡＭＰ測定アーキテクチャは、通常、特定の役割を有する２つのホストのみから成る。これは、ツーホスト実装（two-host implementation）として知られる。一方のホストは、制御クライアント及びセッション送信部（session-sender）の役割を担い、他方のホストは、サーバ及びセッション返送部（session-reflector）の役割を担う。ＴＷＡＭＰ制御のＴＣＰ接続を開始するホストは、制御クライアント及びセッション送信部の役割を果たす。ＴＷＡＭＰ制御のＴＣＰ接続の確認応答を行うホストは、サーバ及びセッション返送部の役割を受け入れる。実際のネットワークの配置において、各ホストは、制御クライアント／セッション送信部及びサーバ／セッション返送部の双方として、幾つかのアクティブなセッションに同時に参加し得る。

ＴＷＡＭＰテストセッションにおいて、パケットは、タイムスタンプを付与され、シーケンス番号によりタグ付けされ、及びセッション送信部からセッション返送部へ送信される。セッション返送部は、インカミングパケットにタイムスタンプを付与し、新たなテストパケットを生成し（セッション返送部によって受信されるテストパケットごとに１つのパケットが生成され）、及びそれらをできる限り速やかにセッション送信部に送信する。これらのタイプスタンプ及びシーケンス番号を用いて、セッション送信部は、順方向（forward）パス及び逆方向（reverse）パスの双方におけるセッションについて、一方向の遅延、ジッタ、及びパケットロスを算出することができる。しかしながら、利用可能なパス容量及び狭リンク容量といった他のＩＰパスパラメータを測定することが可能な方法、装置、システム及びソフトウェアを提供することは、望ましいであろう。

大抵の利用可能な容量の推定方法（例えば、ＢＡＲＴ、ＰａｔｈＣｈｉｒｐ、Ｓｐｒｕｃｅ、Ｐａｔｈｌｏａｄ）は、パケットトレイン又は単にトレインと呼ばれるグループでパケットを送信し及び受信する必要がある。各トレインは、単一の所与の方向において特定の送信レートで送信される。これらのトレインは、各双方向テストセッションストリーム内で識別されなければならない。

第１の測定原理は、順方向におけるＩＰレイヤの利用可能なパス容量及びＩＰレイヤの狭リンク容量を推定するために、１つのＩＰノードから別のＩＰノードへのテストセッションストリーム内で複数のトレインを送信することである。各トレインは、パケット間隔によって互いに分離される複数のテストパケットのグループから成る。

第２の測定原理は、自己導入型輻輳（self-induced congestion）と呼ばれる。この原理によれば、ＩＰレイヤの利用可能なパス容量及び狭リンク容量を測定するために、幾つかのトレインは、ネットワークパス上で瞬間的な輻輳を引き起こさなければならない。実質的に、これは、幾つかのトレインがネットワークパス上で利用可能なものよりも高いレートで送信されなければならないことを意味する。輻輳は、トレインの持続期間についての一時的なものにすぎず、これは典型的に短い。

本技術領域においては、利用可能なＩＰパス容量及び狭リンク容量の測定のための包括的でロバストなメカニズムを提供することへのニーズが引き続き存在する。

以下の例示的な実施形態は、単一のエンドポイントからの双方向の送信における、ネットワークにおけるＩＰパスの利用可能な容量の測定又はテストに関連する利点及び利益を提供する。例えば、ＴＷＡＭＰベースである実施形態の場合、例えば、例示的な実施形態はパディングオクテットを利用して、利用可能なＩＰパス容量の算出のために用いられることができる付加的な情報を伝達するため、ＴＷＡＭＰ制御プロトコルに変更は必要とされない。

１つの例示的な実施形態によれば、単一のエンドポイントからのＩＰパスの順方向及び逆方向の利用可能な容量又は狭リンク容量を判定するための方法は、ソースＩＰエンドポイントノードから宛先ＩＰエンドポイントノードに向けて、第１の複数のＩＰテストパケットを含む順方向パケットトレインをＩＰパス上で送信するステップと、ソースＩＰエンドポイントノードにおいて、対応する逆方向パケットトレインを宛先ＩＰエンドポイントノードから受信するステップと、当該逆方向パケットトレインは、第２の複数のＩＰテストパケットを含むことと、当該第２の複数のＩＰテストパケットの各々は、第１の複数のＩＰテストパケットのそれぞれに対応することと、を含む。

別の例示的な実施形態によれば、単一のエンドポイントからの双方向の送信におけるＩＰパスの利用可能な容量を判定するためのシステムは、第１の複数のＩＰテストパケットを含む順方向パケットトレインを宛先ＩＰエンドポイントノードに向けて順方向ＩＰパス上で送信するセッション送信部機能を実装するように構成されるプロセッサを有する、ソースＩＰエンドポイントノードを備え、当該プロセッサは、宛先ＩＰエンドポイントノードから対応する逆方向パケットトレインを受信するようにさらに構成され、当該逆方向パケットトレインは、逆方向ＩＰパス上の第２の複数のＩＰテストパケットを含み、当該第２の複数のＩＰテストパケットの各々は、第１の複数のＩＰテストパケットのそれぞれに対応する。

本明細書に包含され及び本明細書の一部を構成する添付の図面は、１つ以上の実施形態を例示し、及び以下の説明と共にこれらの実施形態を説明する。図面において：

例示的な実施形態に係る、利用可能なＩＰパス容量及び狭ＩＰリンク容量の測定技法が実装されることができる例示的なＩＰネットワークの一部の回路図である。 例示的な実施形態に係る、順方向ＩＰテストパケットのフォーマットを示す。 従来の順方向ＩＰテストパケットのフォーマットを示す。 例示的な実施形態に係る、逆方向ＩＰテストパケットのフォーマットを示す。 従来の逆方向ＩＰテストパケットのフォーマットを示す。 別の例示的な実施形態に係る、順方向ＩＰテストパケットのフォーマットを示す。 別の従来の順方向ＩＰテストパケットのフォーマットを示す。 別の例示的な実施形態に係る、逆方向ＩＰテストパケットのフォーマットを示す。 別の従来の逆方向ＩＰテストパケットのフォーマットを示す。 例示的な実施形態に係る、ＩＰパスの容量を判定する方法を例示するフローチャートである。 例示的な実施形態に係る、例示的なＩＰエンドポイントノードを示す。

以下の例示的な実施形態の説明は、添付の図面を参照する。異なる図面における同じ参照番号は、同じ又は同様の要素を識別する。以下の詳細な説明は、本発明を限定しない。代わりに、本発明の範囲は、添付の特許請求の範囲によって定義される。

本発明の全体にわたる「１つの実施形態」又は「ある実施形態」への言及は、ある実施形態に関連して説明される特定の特徴、構造、又は特性が本発明の少なくとも１つの実施形態に含まれることを意味する。従って、本明細書全体にわたる種々の箇所における「１つの実施形態において」又は「ある実施形態において」という表現の出現は、必ずしも全て同じ実施形態に言及するわけではない。さらに、特定の特徴、構造、又は特性は、１つ以上の実施形態において適切な手法で組み合わせられ得る。

これらの例示的な実施形態に係る、利用可能なパス容量及び狭リンク容量をテストすることの議論について幾つかのコンテキストを提供するために、図１は、利用可能なＩＰパス容量及び狭リンク容量がテストされることができる例示的なＩＰネットワーク１００を例示する。図１において、ＩＰネットワーク（例えば、ＩＰｖ４ネットワーク又はＩＰｖ６ネットワーク）１００は、例えば、複数のルータ１０２、１０４及び１０６を含み、これらは、有線接続又は無線接続（ＩＰホップ）によって互いに接続されて、２つのエンドポイントノード１１０と１１２との間の順方向パス１２０及び逆方向パス１３２を共同で形成する。順方向パス１２０又は逆方向パス１３２におけるリンク１０８は、イーサネットワイヤ、メトロイーサネットネットワーク上のイーサネット接続、無線接続又は任意の他のリンク層媒体のうちの１つ以上を含むことができる。

この例示的な実施形態によれば、エンドポイントノード１１０は、例えば、利用可能なパス容量を測定する方法又はアプリケーション１１４によりアクティブ測定プロトコルを実行するＩＰ／ＵＤＰノードとすることができ、当該手法又はアプリケーション１１４は、非侵入的な手法（non-intrusive manner）で順方向パス１２０及び逆方向パス１３２の利用可能な帯域幅容量及び／又は狭リンク容量を測定することが可能である。このプロトコルの具体的な詳細及び対応する測定アクティビティは、以下においてより詳細に説明される。ＩＰノード１１０、１１２は、例えば、ホスト、ルータ、テスト機器、又はＩＰスタックを実行する任意の他のプラットフォームとすることができる。

例示的な実施形態に係る利用可能なＩＰパス容量テスト又は狭ＩＰリンク容量テストを実行するために、順方向パケットトレイン１１６は、ノード１１０上で実行されるセッション送信部機能１１８によって生成され、及び順方向パスの方向１２０において送信される。図１は、２つのセッション送信側ＩＰテストパケット１２２を含む単一の順方向パケットトレイン１１６を例示する。しかしながら、例示的な実施形態によれば、２つよりも多くのＩＰテストパケットが順方向パケットトレイン中に含まれることができることが当業者によって認識されるであろう。例示的な実施形態に係る、ＩＰテストパケットのフォーマット及び中身は、図２（ａ）、図３（ａ）、図４（ａ）及び図５ａ）に関して以下に説明されるであろう。

順方向パケットトレイン１１６は、他方のエンドポイント１１２のセッション返送部機能１２４によって受信される。セッション返送部機能１２４は、受信するテストＩＰパケットをバッファ１２６にバッファリングし、それらのバッファリングされたパケットを用いて、対応するセッション返送部テストＩＰパケット１２８を生成する。セッション返送部テストＩＰパケット１２８は、点線１３２によって表される逆方向パスの方向において送信される逆方向パケットトレイン１３０の一部として、ノード１１０に向けて送信される。この場合も、上述したように、逆方向パケットトレイン１３０は、２つよりも多くのＩＰテストパケットを含むことができる。

送出タイプスタンプは、ＩＰテストパケット１２２及びＩＰテストパケット１２８に提供されて、それぞれセッション送信部機能１１８及びセッション返送部機能１２４によるそれらの送信の時刻を示す。同様に、到着タイムスタンプは、ＩＰテストパケット１２８に挿入され（又はさもなければ関連付けられ）て、順方向パケットトレイン１１６中の対応するＩＰテストパケット１２２がエンドポイントノード１１２に到着した時刻が示され、及びＩＰテストパケット１２８に挿入されて、パケット１２８がエンドポイントノード１１０に到着する時刻が示される。

この情報を用いて、順方向パスの方向１２０における種々のＩＰパス容量メトリック、例えば、利用可能なパス容量及び狭リンク容量は、セッション送信部機能１１８によってテストパケット１２２に挿入された送出タイプスタンプと、セッション返送部機能１２４においてテストパケット１２８に挿入され又は関連付けられた到着タイムスタンプと、からＡＰＣ測定機能１１４によって算出されることができる。同様に、逆方向パスの方向１３２における利用可能なパス容量及び狭リンク容量は、返送されたテストパケット１２８にセッション返送部によって挿入された送出タイムスタンプと、返送されたテストパケットにセッション送信部１１８によって挿入され又は関連付けられた到着タイムスタンプと、からＡＰＣ測定機能１１４によって算出されることができる。例示的な実施形態によって測定され又は判定されることができるＩＰパス容量の例は、特に、利用可能なパス容量（ＡＰＣ）及び狭リンク容量（ＴＬＣ：tight ink capacity）を含むが、これらに限定されない。ＡＰＣ及びＴＬＣは、標準仕様書ＩＴＵ Ｙ．１４５０ Ａｍｅｎｄｍｅｎｔ １（２００９年３月）において定義され、その開示は参照によって本明細書に包含される。具体的なＩＰパス容量パラメータを算出するためにＡＰＣ測定機能１１４によって用いられる具体的なアルゴリズムは、任意の所望の技法が採用され得る為、本議論の範囲を超えるものである。ただし、単に例示的なアルゴリズムは、Ｓｖａｎｔｅ Ｅｋｅｌｉｎらの“Real-Time Measurement of End-to-End Bandwidth using Kalman Filtering”（Network Operations and Management Symposium (NOMS), April 2006, 10^th IEEE/IFIP）と題された論文の７３〜８４頁において説明され、その開示は参照によって本明細書に包含される。

上述されたＩＰネットワーク１００の例示的な部分は単なる実例であること、及び他のＩＰノード構成、ＩＰリンク構成等が上述され及び以下でより詳細に説明されるプロトコルと共に用いられることができることが当業者によって認識されるであろう。例えば、セッション送信部機能１１８を制御するＩＰノード１１０及びセッション返送部機能１２４を制御するＩＰノード１１２は、異なるＩＰパケット特性（例えば、Ｄｉｆｆｓｅｒｖコードポイント及びパケットサイズ）を有する複数の並列的なテストセッションをサポートすることができる。さらに、ＡＰＣ測定機能１１４は、セッション送信部機能１１８と同じＩＰエンドポイントノード１１０上で、又は別個のノード若しくはサーバ上で実行することができる。

前述の議論によって、例示的な実施形態に係る、単一のエンドポイントからの順方向パス１２０及び逆方向パス１３２上の利用可能な容量の算出は、順方向パス１２０及び逆方向パス１３２の双方上でのパケットトレインの送信及び受信に関連付けられた情報を提供することによって可能となることが認識されるであろう。１つの例示的な実施形態によれば、ＴＷＡＭＰプロトコルは、順方向パス及び逆方向パスのＩＰパステストの種々の態様を可能にするための種々の付加的な情報要素を提供するように拡張され、当該付加的な情報要素は、特に、各テストパケットのパディングオクテットに何の情報が埋め込まれているのかを特定する。

さらに、例示的な実施形態は、特定のＩＰテストパケットフォーマットにおいて提供される情報をセッション送信部機能１１８及びセッション返送部機能がどのように用いるかにも対処する。例えば、例示的な実施形態は、あるセッションに属するインカミングパケット及びアウトゴーイングパケットをホストがどのように識別することが可能であるかを例示し、各セッション及びその関連付けられる状態の知識を有する。さらに、例示的な実施形態は、セッション内で種々のパケットトレインを構築し、各トレインについての所望の逆方向パケット間隔を識別し、及びトレインに属する各パケットを特定の順方向パケット間隔でセッション返送部機能１２４に送信するためのセッション送信部機能１１８についてのメカニズムを提供する。また、例示的な実施形態に係るセッション返送部機能１２４には、セッション内のトレインに属するインカミングパケットを識別し、各インカミングトレイン及び関連付けられる測定データを記憶し、及び対応する新たなトレインを所望の逆方向パケット間隔でセッション送信部に送信することが可能であるためのケイパビリティが提供される。

例示的な実施形態に係るＩＰテストプロトコルのこれらの及び他の特徴は、図２（ａ）に示される例示的な順方向ＩＰテストパケット２００及び図３（ａ）に示される逆方向ＩＰテストパケット３００に関して議論されるであろう。図２（ａ）は、非認証モードにおいて用いられる例示的な順方向ＩＰテストパケットのフォーマットを例示する。この例示的な実施形態はＴＷＡＭＰプロトコルの拡張である実装を例示するため、図２に示されるフィールドのうちの幾つかは、ＴＷＡＭＰ標準文書、例えば、ＲＦＣ４６５６、ＲＦＣ５３５７及びＲＦＣ６０３８においてより詳細に説明され、興味のある読者は、これらのフィールドに関するより多くの情報についてこれらの文書を参照されたい。例えば、図２において、最初の３つのフィールド２０２、２０４及び２０６は、ＲＦＣ４６５６における非認証モードについての順方向ＩＰテストパケットフォーマットにおいても提供され、その開示は参照によって包含される。シーケンス番号フィールド２０２は、テストセッションにおける他の順方向テスト順方向パケットに対するその送信順序に従って当該順方向パケットを一意に識別する、ＩＰテストパケット用のシーケンス番号をセッション送信部１１８が提供するフィールドである。タイムスタンプフィールド２０４は、セッション送信部１１８によって送出（送信）タイムスタンプを付与することができるフィールドである。誤り推定フィールド２０６は、送出タイムスタンプ中の誤りを訂正するために有益な情報を含むことができる。

図３（ａ）は、例示的な実施形態に係る、非認証モードにおいて用いられる例示的な逆方向ＩＰテストパケットのフォーマットを例示する。この例示的な実施形態はＴＷＡＭＰプロトコルの拡張である実装を例示するため、図３に示されるフィールドのうちの幾つかは、ＴＷＡＭＰ標準文書、例えば、ＲＦＣ５３５７及びＲＦＣ６０３８において、より詳細に説明され、興味のある読者は、これらのフィールドに関するより多くの情報についてこれらの文書を参照されたい。例えば、図３において、最初の３つのフィールド３０２、３０４及び３０６は、ＲＦＣ５３５７における非認証モードについてのＩＰテストパケットフォーマットにおいても提供され、その開示は参照によって包含される。シーケンス番号フィールド３０２は、セッション返送部１２４が例えばテストセッション中の他の逆方向テストパケットに対するその送信順序に従って当該パケットを一意に識別する、逆方向ＩＰテストパケット用のシーケンス番号を提供するフィールドである。タイムスタンプフィールド３０４は、セッション返送部１２４によって送出（送信）タイムスタンプを付与することができるフィールドである。誤り推定フィールド３０６は、送出タイムスタンプ中の誤りを訂正するために有益な情報を含むことができる。

ＲＦＣ４６５６及びＲＦＣ５３５７において説明されるＩＰテストパケットフォーマットにおいて、ＩＰテストパケット中の最後のオクテットは、随意的なパケットパディングとして単に示される。参考までに、この従来の順方向ＩＰテストパケットフォーマットは、図２（ｂ）として提供され、従来の逆方向ＩＰテストパケットフォーマットは、図３（ｂ）として提供される。例示的な実施形態は、代わりに、これらのパケットパディングオクテットのうちの幾つかを、例えば、セッション送信部機能１１８がＴＷＡＭＰテストパケットパディングフィールドにおける最初の１６オクテットに送信の各方向における一方向のＡＰＣ及び／又はＴＬＣを算出するために用いられることができる情報を設定することを可能にするために提供されるフィールドとして定義する。

例えば、順方向ＩＰテストパケット中のバージョンフィールド２０８は、最初の４ビットにおいてエンコードされ、フォーマット２００におけるテストパディングオクテットの構造、並びにパディングフラグ２１０及び２１２を含む種々のフィールドの意味を識別するために用いられることができる。送信側判別子存在（Ｓ）ビット（Sender Discriminator Present (S) bit）２１０は、例えば、送信側判別子フィールド２１６が存在することを示すために１に等しく設定されることができる最初のパディングフラグである。ＡＰＣフィールド存在（Ａ）ビット２１２は、この例示的な実施形態に係る例示的なＩＰテストパケット２００中の第２のパディングフラグであり、ＡＰＣフィールドが存在することを示すために１に等しく設定されることができる。ＡＰＣフィールドは、トレインＩＤフィールド２１８、パケットＩＤフィールド２２０、トレインサイズフィールド２２２及び所望逆方向レート間隔フィールド２２４である。フラグ２１０、２１２は、フィールドの様々な組み合わせに適応し、あるフィールドが必要とされない場合にパディングオーバーヘッドにおける低減を提供するように設計される。フラグは、フィールドの複数の組み合わせがサポートされ又は必要とされる場合にセッション送信部１１８及びセッション返送部１２４における情報のパーシング（parsing）を軽減するためにパディングオクテット中にも導入される。

予約フィールド２１４は、将来の使用（例えば、パディングオクテットの使用を拡張するための将来のフラグ）のために予約され、セッション送信部機能１１８によってゼロ値を有して送信されることができる。

この例示的な実施形態に係る順方向ＩＰテストパケット中の送信側判別子フィールド２１６は、例えば、セッション送信部機能１１８によって生成される、符号無しの１６ビットの整数を含む。このフィールド２１６における値は、セッション返送部機能１２４及び／又はセッション送信部機能１１８によってテストセッションに属するパケットを識別するために用いられ得る。このフィールド２１６は、ゼロに設定される場合、セッション返送部機能１２４によって無視されることができる。フィールド２１６が非ゼロ値を含むことになる場合、セッション送信部機能１１８は、そのシステム上の全てのテストセッション間において一意である判別子の値を選択する。

この例示的な実施形態に係る順方向ＩＰテストパケット中のトレイン識別子（ＴＩＤ：Train Identifier）フィールド２１８は、例えば、セッション送信部機能１１８によって生成される、符号無しの１６ビットの整数を含む。このフィールド２１８は、テストセッションストリーム内のトレインを識別し、例えば、セッション送信部機能１１８によって送信され及び後続のトレインごとに１だけインクリメントされる最初のテストトレインにおいてゼロに設定される値を有することができる。フィールド２１８の値は、その最大値に到達する場合、ゼロに巡回する（wrap back）ことができる。ＴＩＤフィールド２１８は、セッション送信部機能１１８及びセッション返送部機能１２４によってパケットがどのトレインに属するかを識別するために用いられる。セッションごとに、パケットのＴＩＤは、完全なトレインが受信されたかを確認するために、過去のパケットのＴＩＤと比較されることができる。

この例示的な実施形態に係る順方向ＩＰテストパケット中のパケット識別子（ＰＩＤ：Packet Identifier）フィールド２２０は、例えば、セッション送信部機能１１８によって生成される、符号無しの１６ビットの整数を含む。ＰＩＤフィールド２２０は、テストセッションストリームのトレイン内の各パケットを識別し、トレイン中のパケットごとに一意である。ＰＩＤフィールド２２０は、セッション送信部機能１１８によって送信されるトレインの最初のパケットにおいてゼロに設定されることができ、例えば、当該トレイン中の後続のパケットごとに１だけインクリメントされることができる。

この例示的な実施形態に係る順方向ＩＰテストパケット中のトレインサイズ（ＴＳ）フィールド２２２は、例えば、セッション送信部機能１１８によって生成される、符号無しの１６ビットの整数を含み、当該整数は、セッション送信部機能１１８によって送信されるトレイン中のテストパケットの数を特定する。

この例示的な実施形態に係る順方向ＩＰテストパケット中の所望逆方向パケット間隔（ＤＲＰＩ：Desired Reverse Packet Interval）フィールド２２４は、例えば、セッション送信部機能１１８によって生成される、符号無しの３２ビットの整数を含む。ＤＲＰＩフィールド２２４は、セッション返送部機能１２４が返送されるテストパケットをセッション送信部機能１１８に向けて送信する際に用いる所望のパケット時間間隔を示す。このフィールドのフォーマットは、例えばＯＷＡＭＰ［ＲＦＣ４６５６］においてタイムスタンピングのために用いられる１秒のうちのある割合の部分を特定するための技法と同様の手法で１秒のうちのある割合の部分を特定することができる。

同様のフィールドは、図３（ａ）に示されるように、逆方向パスの方向１３２において用いられるＩＰテストパケット３００に提供される。これらのフィールドは、図２（ａ）に関して上述されたそれらの対応する部分と同じ機能を有するであろう。当該機能は、簡潔にするためにここでは繰り返されない。

幾つかの他の実施形態によれば、ＩＰテストパケットにおいて図２（ａ）に例示される追加のフィールドの全てを含むことが必要とはされないことが、当業者によって認識されるであろう。１つ以上のフィールドが省略されることができ、他のフィールドが追加され得る。例えば、セッション送信部機能１１８は、パディングオクテットにおけるセッション判別子フィールド２１６を（ゼロを有して送信することとは対照的に）省略することを決定してもよく、その場合、ＡＰＣ／ＴＬＣは、ＡＰＣフィールドに基づいて測定されることができる。この例において、セッション送信部１１８及びセッション返送部１２４は、送信側判別子２３９を用いずに（例えば、ＩＰヘッダからの情報を用いて）、セッションに属するテストパケットを識別する手法を見つけ出さなければならないであろう。別の例として、セッション送信部機能１１８は、パディングオクテットにおけるＡＰＣフィールドを省略することを決定してもよく、セッションに属するテストパケットを識別するための手法として送信側判別子２１６を用いることによって、遅延／ロスがテストセッションについて測定されることができる。他の変形例も可能である。

図２（ａ）及び図３（ａ）の例示的な実施形態に関して上述されたＩＰテストパケットフィールドは、認証モード又は暗号化モードにおいて用いられるＩＰテストパケットに提供されることもできる。そのような順方向ＩＰテストパケット４００の例は、図４（ａ）として提供され、図２（ａ）に関して上述されたものと同じラベルを有するフィールドは、ＩＰテストパケット４００において同様の機能性を提供する。そのような逆方向ＩＰテストパケット５００の例は、図５（ａ）として提供され、図３（ａ）に関して上述されたものと同じラベルを有するフィールドは、ＩＰテストパケット５００において同様の機能性を提供する。比較の目的のため、ＲＦＣ４６５６において説明されるような、認証モード又は暗号化モードにおいて使用可能な従来の順方向ＩＰテストパケットは図４（ｂ）として提供され、ＲＦＣ５３５７において説明されるような、認証モード又は暗号化モードにおいて使用可能な従来の逆方向ＩＰテストパケットは、図５（ｂ）として提供される。

例示的な実施形態に係るＡＰＣ測定のためにテストセッションが構成される場合、セッション送信部機能１１８は、例えば図２（ａ）及び図４（ａ）に関して上述されたフォーマットのうちの１つを用いて、複数のテストパケットを生成することができる。セッション送信部機能１１８は、生成されたＩＰテストパケット１２２を１つ以上のトレイン１１６にグループ化し、及び、例えば利用可能なパス容量測定方法、ツール又はアルゴリズム１１４によって提供されるような、所望の順方向パケット間隔で当該トレイン１１６をセッション返送部機能１２４に向けて送信することができる。

この例示的な実施形態によれば、ＡＰＣ測定のために構成されるセッション返送部機能１２４は、ＩＰテストパケット１２２が受信されると、バージョンフィールド２０８、Ｓフラグ２１０及びＡフラグ２１２を読み出す。各ＩＰテストパケット１２２について、バージョンフィールド２０８、Ｓフラグ２１０及びＡフラグ２１２の全てが所定の値、例えば１に等しい場合、セッション返送部機能１２４は、当該ＩＰテストパケットにおける残りのＡＰＣパディングオクテットから情報を読み出し及び抽出することを継続する。バージョンフィールド２０８、Ｓフラグ２１０又はＡフラグ２１２が所定の値、例えば１に等しくない場合、これは、テストセッションの特性が突然変化したこと、及びセッション返送部機能１２４が通常の動作モードに戻ってローカルで現在記憶されている全てのテストパケットを送信しなければならないことを意味するため、セッション返送部機能１２４は、例えばＲＦＣ５３５７において説明される手続き及びガイドラインに従い、できる限り早くＩＰテストパケット（テストセッションのために現在記憶されている任意の他のＩＰテストパケットを含む）を送信し得る。

ＡＰＣパディングオクテットの全てを読み出し及び抽出した後、セッション返送部機能１２４は、各セッションに属するパケットをバッファ１２６にバッファリングし（又は、パケットレベルパフォーマンスデータを記憶し）、及びバッファリングされたＩＰテストパケットを（適切な処理、例えばタイムスタンプデータを付加することの後に）、例えば各順方向パケットトレイン１１６の最後に記憶されたパケットから取得される所望逆方向パケット間隔フィールド２２４において示される所与のパケット間隔で、逆方向パケットトレイン１３０において送信する。

テストセッションストリームのトレイン１２２内の各インカミングＩＰテストパケット１１６について、完全なトレインがセッション返送部機能１２４によって受け取られたかを確認するために、パケットＩＤ２２０は、トレインサイズ２２２と比較される。この例示的な実施形態によれば、逆方向パケットトレイン１３０は、対応する順方向トレインパケット１１６の最後のパケットが受信された後、できる限り速く送信される。トレイン中の最後のパケットは、例えば、トレインサイズフィールド２２２の値から１を引いた値に等しいＰＩＤフィールド２２０の値を有する。

パケットロスの場合には、セッション返送部機能１２４は、所与のセッションについての次のトレインに属するＴＩＤフィールド２１８の値を有する順方向ＩＰテストパケットを受信する際又はタイムアウト後に、不完全なトレインを送信する。タイムアウトは、例えば、［ＲＦＣ５３５７］のセクション４．２において仕様化されるＲＥＦＷＡＩＴタイマであり得る。この例示的な実施形態によれば、トレイン１１６内の順序が乱れて到来するパケットは、対応する逆方向トレイン１３０がセッション送信部機能１１８にまだ送信されていない場合にのみ、セッション返送部機能１２４においてバッファリングされる。対応する逆方向ＩＰテストパケットトレイン１３０が既に送信されている場合、当該トレイン１３０に関連付けられる、順序が乱れたパケットは破棄されることができる。

一般的に、前述の変形されたＴＷＡＭＰアプローチに従ってＩＰパス容量テストを実装する例示的な実施形態の場合、ＴＷＡＭＰセッション返送部機能１２４は、上述された変更及び付加的な機能と共に、ＲＦＣ５３５７のセクション４．２において説明される手続き及びガイドラインに従うことができる。例えば、セッション返送部テストパケット１２８及びそれらの内容は、パケット１２８がＡＰＣパディングオクテット、即ち送信部のパケットパディングにおいて提供される上述された新たなフィールド２０８〜２２４を再利用することを除き、ＴＷＡＭＰ［ＲＦＣ５３５７］及びTWAMP Reflect Octets and Symmetrical Size Features［ＲＦＣ６０３８］において定義されるものと同じ手続き及びガイドラインに従うことができる。

当業者によって認識されるであろうように、これらの例示的な実施形態に係るパス容量測定への適応のための既存のＴＷＡＭＰ標準プロトコルに関連付けられる他の検討事項も、実装され得る。例えば、ＲＦＣ５３５７における推奨される切り捨て（truncation）処理を用いる場合、（１つの例示的な実施形態によれば）セッション返送部機能１２４は、認証モードにおいてはパディングの丁度２７オクテット、認証モード及び暗号化モードにおいては丁度５６オクテットを切り捨てなければならない。

さらに、これらの例示的な実施形態に係るＡＰＣ測定は、テストセッションがＴＷＡＭＰ Ｌｉｇｈｔに従って動作する場合、幾つかの付加的な検討事項を導入してもよい。例えば、セッション返送部機能１２４がセッション状態の知識を有しない場合、逆方向パスの方向におけるＡＰＣ測定はセッション返送部機能１２４がセッション状態の知識を有し及び特定のテストセッションに属するテストパケットを識別することが可能であることを必要とする為、測定システムは、送信の順方向パスの方向における利用可能なパス容量を推定し又は算出することのみ可能であろう。従って、例示的な実施形態に係る利用可能な逆方向ＩＰパス容量及び逆方向狭ＩＰリンク容量の測定について、セッション返送部機能１２４は、セッション状態の知識を有し、及び、例えばパケットパディング中に含まれる送信側判別子フィールドを用いて、受信テストパケットを正確なテストセッションに逆多重化するためのローカルポリシーを実装する。

例示的な実施形態は、利用可能なＩＰパス容量及び狭ＩＰリンク容量のテストに関連付けられる多くの利点を提供する。例えば、ＴＷＡＭＰベースである実施形態の場合、例示的な実施形態はパディングオクテットを利用して付加的な情報を伝達するため、ＴＷＡＭＰ制御プロトコルを変更する必要が無い。利用可能なパス容量及び／又は狭リンク容量は、ＴＷＡＭＰ ｌｉｇｈｔにおいて、即ちＴＷＡＭＰ制御プロトコル無しに確立されるＴＷＡＭＰテストセッションにより、測定されることができる。従って、例示的な実施形態は、異なるベンダ間に相互運用性を提供する。提案されるＴＷＡＭＰエンハンスメントは、ＴＷＡＭＰ標準仕様との後方互換性を有する。標準ＴＷＡＭＰセッション送信部及びセッション返送部は、例示的な実施形態に係るＴＷＡＭＰエンハンスメントを用いるホストによって影響されない。標準的なＴＷＡＭＰセッション返送部は、例えば部分的な帯域幅測定のために用いられ得る。

さらに、前述の例示的な実施形態は、変形されたＴＷＡＭＰ ＩＰテストパケットフォーマットのコンテキストにおいて説明されているが、本発明はそれに限定されない。図６のフローチャートにおいて例示されるように、ＩＰパスの利用可能な容量及び／又は狭リンク容量を判定するための一般的な方法は、ソースＩＰエンドポイントノードから宛先ＩＰエンドポイントノードへ向けて、第１の複数のＩＰテストパケットを含む順方向パケットトレインを順方向パス１２０上で送信するステップ６００と、宛先ＩＰエンドポイントノードから対応する逆方向パケットトレインをソースＩＰエンドポイントノードにおいて受信するステップ６０２と、を含み、当該逆方向パケットトレインは、逆方向パス上の第２の複数のＩＰテストパケットを含み、当該第２の複数のＩＰテストパケットの各々は、第１の複数のＩＰテストパケットのうちのそれぞれに対応する。従来のＩＰパス測定技法とは違い、例示的な実施形態は、順方向ＩＰテストパケットトレインの返送又はエコーを逆方向パス１３２上の逆方向ＩＰテストパケットトレインとして提供する。図２（ａ）、図３（ａ）、図４（ａ）及び図５（ａ）に関して上述された新たなフィールドのうちの１つ、幾つか又は全ては、ＩＰテストパケット中に含まれ得る。

図１において一般的に表されるＩＰエンドポイントノード１１０及び１１２は、例えば、図７におけるＩＰエンドポイントノード７００に示される要素を備え得る。例えば、ＩＰエンドポイントノードは、一般的に、ソフトウェア、例えばセッション送信部１１８及び／又はセッション返送部１２４の上述された機能のインスタンスを初期化することが可能なアプリケーションソフトウェアを実行することが可能であるプロセッサ７０２を備えるであろう。プロセッサ７０２は、例えば図２（ａ）、図３（ａ）、図４（ａ）及び図５（ａ）に関して上述された種々のＩＰテストパケットを生成し、潜在的にインタフェース５０４を介してＩＰリンク１０８に送信し及び／又は受信することも可能である。当該インタフェースは、所望のプロトコルスタック（例えば、ＩＰ／ＵＤＰ等）を表すことができ、ハードウェア及び／又はソフトウェアを含み得る。ＩＰエンドポイントノード７００は、メモリ装置７０６によって表される１つ以上のメモリ装置を備えることができる。当該メモリ装置は、例えば、上述されたようにＩＰテストパケットをバッファリングするために用いられることができる。

実施形態の特徴及び要素は、特定の組み合わせにおいて当該実施形態において説明されているが、各特徴及び要素は、実施形態の他の特徴及び要素無しに単独で、又は本明細書において開示される他の特徴及び要素と共に若しくは無しに種々の組み合わせにおいて用いられることができる。本願において提供される方法又はフローチャートは、少なくとも部分的に、汎用コンピュータ又はプロセッサによる実行のためのコンピュータ読取可能な記憶媒体において有形に具現化されるコンピュータプログラム、ソフトウェア、又はファームウェアにおいて実装され得る。本明細書は、開示される主題の例を用いて、如何なる当業者も、装置及びシステムを製造し及び使用すること、並びに任意の包含される方法を実行することを含む、当該主題の実施をすることを可能にする。主題の特許可能な範囲は、特許請求の範囲によって定義され、及び当業者が思い付く他の例を含み得る。そのような他の例は、特許請求の範囲内であることが意図される。

Claims (22)

1. 単一のエンドポイントからのパスの順方向及び逆方向の利用可能な容量又は狭リンク容量を判定するための方法であって、
   ソースエンドポイントノードから宛先エンドポイントノードに向けて、第１の複数のテストパケットを含む順方向パケットトレインを前記パス上で順方向において第１のレートで送信することと、
   前記ソースエンドポイントノードにおいて、対応する逆方向パケットトレインを前記宛先エンドポイントノードから受信することと、当該逆方向パケットトレインは、前記パス上の逆方向における第２の複数のテストパケットを含むことと、当該第２の複数のテストパケットの各々は、前記第１の複数のテストパケットの各々に対応することと、
   前記ソースエンドポイントノードによって、前記第１の複数のテストパケットのうちの少なくとも１つにおいて逆方向パケットフィールドを提供することと、当該逆方向パケットフィールドは、前記宛先エンドポイントノードに前記第２の複数のテストパケットが送信されるべきパケット時間間隔について通知することと、当該パケット時間間隔は、前記第１のレートとは異なる第２のレートを示すことと、
   を含む、方法。
2. 前記第１の複数のテストパケットからの情報を前記第２の複数のテストパケットにコピーすることと、
   到着タイプスタンプ及び送出タイムスタンプを含むコピーされた前記情報に基づいて、前記パスの前記順方向及び逆方向の利用可能な容量又は狭リンク容量を判定することと、
   をさらに含む、請求項１に記載の方法。
3. 前記提供するステップは、
   前記ソースエンドポイントノードによって、前記逆方向パケットフィールドとして逆方向パケット間隔フィールドを提供すること、
   を含む、請求項１に記載の方法。
4. 前記第１の複数のテストパケットをそれらの対応する送出タイムスタンプ及び到着タイムスタンプを含めて前記宛先エンドポイントノードにおいてバッファリングすることと、
   前記第１の複数のテストパケットの全ての受信後、前記第２の複数のテストパケットを前記第２のレートで送信することと、
   をさらに含む、請求項１に記載の方法。
5. 前記ソースエンドポイントノードによって、前記第１の複数のテストパケットの各々においてトレイン識別フィールドを提供することと、当該トレイン識別フィールドは、前記第１の複数のテストパケットを前記順方向パケットトレインに属するものとして識別することと、
   をさらに含む、請求項１に記載の方法。
6. 前記ソースエンドポイントノードによって、前記第１の複数のテストパケットの各々においてトレインサイズフィールドを提供することと、当該トレインサイズフィールドは、前記順方向パケットトレイン中の前記第１の複数のテストパケットの数を示すことと、
   をさらに含む、請求項１に記載の方法。
7. 前記ソースエンドポイントノードによって、前記第１の複数のテストパケットの各々においてパケット識別子フィールドを提供することと、当該パケット識別子フィールドは、前記順方向パケットトレインに属する各テストパケットを一意に識別することと、
   をさらに含む、請求項１に記載の方法。
8. 前記ソースエンドポイントノードによって、前記第１の複数のテストパケットの各々において送信側判別子フィールドを提供することと、当該送信側判別子フィールドは、前記第１の複数のテストパケットを前記ソースエンドポイントノードと前記宛先エンドポイントノードとの間のテストセッションに属するものとして識別することと、
   をさらに含む、請求項１に記載の方法。
9. 前記第１の複数のテストパケット及び前記第２の複数のテストパケットは、ＴＷＡＭＰ（Two-Way Active Measurement Protocol）テストパケットである、請求項１に記載の方法。
10. パスの容量を判定するためのシステムであって、
    ソースエンドポイントノード及び宛先エンドポイントノードを含み、
    前記ソースエンドポイントノードは、
    第１の複数のテストパケットを含む順方向パケットトレインを前記宛先エンドポイントノードに向けて前記パス上で順方向において第１のレートで送信するセッション送信部機能を実装するように構成されるプロセッサ、
    を含み、
    前記プロセッサは、前記宛先エンドポイントノードから対応する逆方向パケットトレインを受信するようにさらに構成され、当該逆方向パケットトレインは、前記パス上の逆方向における第２の複数のテストパケットを含み、当該第２の複数のテストパケットの各々は、前記第１の複数のテストパケットの各々に対応し、
    さらに、前記プロセッサは、前記第１の複数のテストパケットのうちの少なくとも１つにおいて逆方向パケットフィールドを生成するようにさらに構成され、当該逆方向パケットフィールドは、前記宛先エンドポイントノードに前記第２の複数のテストパケットが送信されるべきパケット時間間隔について通知し、当該パケット時間間隔は、前記第１のレートとは異なる第２のレートを示す、
    システム。
11. 前記プロセッサは、前記第２の複数のテストパケットから情報を抽出し、並びに、抽出された当該情報に基づいて、前記パスの前記順方向及び逆方向の利用可能な容量又は狭リンク容量を判定するようにさらに構成される、請求項１０に記載のシステム。
12. 前記プロセッサは、順方向パケット間隔を生成し、及び前記第１の複数のテストパケットを前記第１のレートで送信するように構成される、請求項１０に記載のシステム。
13. 前記プロセッサは、前記逆方向パケットフィールドとして逆方向パケット間隔フィールドを生成するように構成される、請求項１０に記載のシステム。
14. 前記宛先エンドポイントノードは、
    前記第１の複数のテストパケットをそれらの対応する送出タイムスタンプ及び到着タイムスタンプを含めて前記宛先エンドポイントノードにおいて記憶するように構成されるバッファ、及び
    前記第１の複数のテストパケットの全ての受信後、前記第２の複数のテストパケットを前記第２のレートで送信するように構成される宛先プロセッサ、
    を含む、請求項１０に記載のシステム。
15. 前記プロセッサは、前記第１の複数のテストパケットの各々においてトレイン識別フィールドを生成するようにさらに構成され、当該トレイン識別フィールドは、前記第１の複数のテストパケットを前記順方向パケットトレインに属するものとして識別する、請求項１０に記載のシステム。
16. 前記プロセッサは、前記第１の複数のテストパケットの各々においてトレインサイズフィールドを生成するようにさらに構成され、当該トレインサイズフィールドは、前記順方向パケットトレイン中の前記第１の複数のテストパケットの数を示す、請求項１０に記載のシステム。
17. 前記プロセッサは、前記第１の複数のテストパケットの各々においてパケット識別子フィールドを生成するようにさらに構成され、当該パケット識別子フィールドは、前記順方向パケットトレインに属する各テストパケットを一意に識別する、請求項１０に記載のシステム。
18. 前記プロセッサは、前記第１の複数のテストパケットの各々において送信側判別子フィールドを生成するようにさらに構成され、当該送信側判別子フィールドは、前記第１の複数のテストパケットを前記ソースエンドポイントノードと前記宛先エンドポイントノードとの間のテストセッションに属するものとして識別する、請求項１０に記載のシステム。
19. 前記第１の複数のテストパケット及び前記第２の複数のテストパケットは、ＴＷＡＭＰ（Two-Way Active Measurement Protocol）テストパケットである、請求項１０に記載のシステム。
20. 前記提供するステップは、
    前記ソースエンドポイントノードによって、前記第１の複数のテストパケットの各々において逆方向パケットフィールドを提供すること、
    を含む、請求項１に記載の方法。
21. 前記プロセッサは、前記第１の複数のテストパケットの各々において逆方向パケットフィールドを生成するように構成される、請求項１０に記載のシステム。
22. 前記宛先エンドポイントノードは、
    前記順方向パケットトレインを受信し、
    前記第２のレートを取得し、
    前記第２の複数のテストパケットを生成し前記パス上で前記逆方向において前記第２のレートで送信する、
    ように構成される宛先プロセッサ、を含む、請求項１０に記載のシステム。

Images