JP2014506069A - Ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ診断コマンド - Google Patents

Abstract

少なくとも、ネットワーク経路内に含まれるネットワークノード内におけるプローブメッセージの滞留時間を測定する方法であり、前記プローブメッセージが生存時間値を備える、方法であって、− プローブメッセージの受信タイムスタンプを記録するステップと、− 受信タイムスタンプを、受信されたプローブメッセージ内の専用フィールド内に書き込むステップと、− プローブメッセージの生存時間値を検査するステップと、− 生存時間値がヌルでない場合、生存時間値を１、デクリメントするステップと、− 生存時間値が１に等しい場合には、− プローブメッセージの伝送タイムスタンプを記録するステップと、− 記録された伝送タイムスタンプに対して、記録された受信タイムスタンプを減算することによってネットワークノード内におけるプローブメッセージ滞留時間を計算するステップと、− 計算された滞留時間をプローブメッセージ内のフィールド内に書き込むステップと、− 滞留時間をプローブメッセージに対する後続の動作によって上書きされないように保護するために、受信されたプローブメッセージ内のフラグの値を変更するステップと、を含む、方法。

Description

本発明は一般にネットワーク遅延／レイテンシ管理の技術分野に関する。

ネットワーク導入遅延は、ＶｏＩＰ、双方向性ネットワークゲーム等のリアルタイムアプリケーションからタイムクリティカルな金融アプリケーションおよびローカライゼーションシステムに及ぶいくつかのワイドエリアネットワークアプリケーションに直接影響を与えるため、最も重要なネットワーク性能メトリクスの１つである。

従って、ネットワーク内のデータ伝送遅延の性能の監視は、これらの遅延がどのようにしてどこで導入されるかを詳細に理解することを必要とせざるをえない。

従来のＴＤＭ技術の範囲内では、ネットワーク遅延はＴＤＭスイッチ間の決定論的な遷移時間により（例えばシステムクロック遷移数の観点から）予測可能である。しかし、帯域幅需要の著しい増加のために、ＴＤＭは次第にパケット交換網（Ｐａｃｋｅｔ Ｓｗｉｔｃｈ Ｎｅｔｗｏｒｋ、ＰＳＮ）に置き換えられている。パケット交換網では、パケットジッタ、パケット遅延変動とも呼ばれる（基本的にパケットキューイングによって生じるランダムプロセス）のために、ネットワークノード内におけるパケット滞留時間（以後、ネットワークノード滞留時間と呼ばれる）が予測不可能になる。

従って、ＰＳＮネットワークオペレータは、サービス品質保証契約（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ、ＳＬＡ）の順守およびネットワーク遅延／レイテンシに関するＳＬＡ違反の是正を目指して適切な対策（例えばネットワーク再設計／再構成）を講じることができるようにするために、ネットワーク遅延またはネットワークレイテンシを監視するツールをこれまで以上に必要としている。

これらの問題に対処するために、ネットワークオペレータは、一般的に、以下のもの等の種々のエンドツーエンド時間遅延測定ツールに依拠している。

− ＩＰネットワーク内における送信元から宛先ホストまでのエンドツーエンド往復遅延の測定を可能とする、インターネット制御メッセージプロトコル（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ、ＩＣＭＰｖ４−ＲＦＣ７９２およびＩＣＭＰｖ６−ＲＦＣ４４４３）上で定義されるＰＩＮＧコマンド。

− ＲＦＣ２６７９によって記述されている片方向遅延測定方法。この方法は、ネットワーク遅延／レイテンシ値、測定の要求精度および両エンドにおけるクロック正確度に依存する時刻同期を必要とすることがある。

− 送信元から宛先ホストまでのネットワーク経路に沿った各ネットワークノード（すなわち各ネットワーク層デバイス）のアドレスを判定することを可能とするｔｒａｃｅｒｏｕｔｅ（またはｔｒａｃｅｒｔ）コマンド。Ｔｒａｃｅｒｏｕｔｅは、それぞれ、送信元からネットワーク経路内の各経由ノードまでのエンドツーエンド遅延も返す。

ＩＥＴＦ文書「Ｏｐｅｒａｔｉｎｇ ＭＰＬＳ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｆｉｌｅ ＬＳＰ ｉｎ Ｌｏｏｐｂａｃｋ Ｍｏｄｅ」、２０１０年３月

しかし、これらのツールは、ネットワークノード滞留時間（またはレイテンシ）に関する精度は全く有しない全体的なエンドツーエンド遅延を返す。換言すると、これらのツールによって返される遅延値は、ネットワークノード滞留時間を、それに関する精度を全く有さずにすでに含む、単一のまとまった成分と考えられる。

ネットワーク導入遅延は以下のものに大別することができる：
− ネットワークノード滞留時間。とりわけ、以下のものを含む。

− パケットを処理し、（再）伝送のためにそれを準備するためにネットワークノードによって必要とされる時間（処理遅延）。処理遅延は、主に、プロトコルスタックの複雑度、各ノードにおける利用可能な計算能力（すなわち利用可能なハードウェア）およびカードドライバ（もしくはインタフェースカードロジック）の関数である。ならびに
− キューイング遅延、すなわち処理および／または伝送前のネットワークノードのバッファ内におけるパケットの総待ち時間。これは、ネットワークノードのスイッチング（または下位層スイッチ）の詳細に依存することがある。

− 伝送遅延：パケット全体（最初のビットから最後のビットまで）またはより基本的には単一ビットを第１のネットワークノードの出力ポートから第２のネットワークノードの入力ポートまで伝送するために必要とされる時間。

従って、全体的なエンドツーエンド遅延を、その成分に関する詳細を全く与えず単一の値で返すことによって、現在のエンドツーエンド遅延測定ツールは、許容レイテンシ超過問題を解決するために是正策が適用されるべきネットワークセグメントまたはネットワークノードを見つけ出すことをオペレータに許さない。

従来技術のさらに別の問題は、既存のネットワーク診断ツールでは、総転送レイテンシの何割がネットワークノード滞留時間によるのかを判定することができないことである。

本発明の１つの目的は、関連技術分野に関する上述の問題およびその他の問題に対処することである。

本発明の別の目的は、ネットワーク経路内においてどこで支配的遅延が導入されるのかを突き止めることである。

本発明の別の目的は、ネットワーク導入遅延のきめの細かい組成を提供することである。

本発明の別の目的は、ノード毎レイテンシを判定することを可能にする方法を提案することである。

本発明の別の目的は、プローブメッセージの内容を制御することによって、このパケットが被るエンドツーエンド遅延のきめの細かい描像を提供するコマンドを提供することである。

本発明の別の目的は、エンドツーエンド遅延を、ＩＰネットワーク内の送信元から宛先までの経路に沿ったノード滞留時間を区別する成分に分割することである。

本発明の別の目的は、ネットワークレイテンシに関するＳＬＡ違反問題（委ねられたサービスの品質の不順守）の迅速且つ精密な診断をオペレータが行うことを可能にすることである。

本発明の別の目的は、インターネットアプリケーション内における重大な遅延の発生源を正確に突き止めることを可能にする診断コマンドを提供することである。

本発明の別の目的は、最も多くのレイテンシを導入し、遅延劣化の原因となっている支配的ネットワークホップを発見することである。

本発明は、前述の問題のうちの１つまたは複数の影響に対処することを対象とする。以下の事項は、本発明のいくつかの態様の基本的理解をもたらすために、本発明の簡略化された概要を提示する。この概要は本発明の網羅的な要約ではない。それは、本発明の重要な要素を特定することも、本発明の範囲を明確に描出することも意図していない。その唯一の目的は、後で述べられるより詳細な説明への前置きとして、簡略化された形でいくつかのコンセプトを提示することである。

本発明は、少なくとも、ネットワーク経路内に含まれるネットワークノード内におけるプローブメッセージの滞留時間を測定する方法であり、前記プローブメッセージが生存時間（Ｔｉｍｅ−Ｔｏ−Ｌｉｖｅ）値を備える、方法であって、
− プローブメッセージの受信タイムスタンプを記録するステップと、
− 受信タイムスタンプを、受信されたプローブメッセージ内の専用フィールド内に書き込むステップと、
− プローブメッセージの生存時間値を検査するステップと、
− 生存時間値がヌルでない場合、生存時間値を１、デクリメントするステップと、
− 生存時間値が１に等しい場合には、
− プローブメッセージの伝送タイムスタンプを記録するステップと、
− 記録された伝送タイムスタンプに対して、記録された受信タイムスタンプを減算することによってネットワークノード内におけるプローブメッセージ滞留時間を計算するステップと、
− 計算された滞留時間をプローブメッセージ内のフィールド内に書き込むステップと、
− 滞留時間をプローブメッセージに対する後続の動作によって上書きされないように保護するために、受信されたプローブメッセージ内のフラグの値を変更するステップと、
を含む、方法に関する。

広い態様によれば、上述の方法は、
− 生存時間値が、デクリメントされた後、ヌルである場合には
− 計算された滞留時間、その関連フラグ値およびプローブメッセージ識別子をプローブメッセージからプローブ応答メッセージ内にコピーしてプローブ応答メッセージを作成するステップと、
− 作成されたプローブ応答メッセージをプローブメッセージの発信元へ向けて送るステップと、
をさらに含む。

広い態様によれば、プローブメッセージが、変更されたインターネット制御メッセージプロトコル（ＩＣＭＰ）メッセージである。

別の広い態様によれば、プローブメッセージが、ＭＰＬＳ−ＴＰ／ＭＰＬＳ ＯＡＭメッセージまたはイーサネット（登録商標）ＯＡＭメッセージ等の、変更された運用管理保守（Ｏｐｅｒａｔｉｏｎ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ Ｍａｉｎｔｅｎａｎｃｅ、ＯＡＭ）メッセージである。

有利には、ネットワークノード内におけるプローブメッセージの計算された滞留時間は、プローブメッセージ処理（すなわち符号化／復号化）を担う主要プロトコル層／スタック内におけるその滞留時間に等しい。従って、異なるプロトコル層におけるプローブメッセージの利用により、各ノードの許容遅延に対する異なるプロトコル層の影響を分析することが可能となる。

本発明は、
− プローブメッセージの受信タイムスタンプを記録する手段と、
− 受信タイムスタンプを、受信されたプローブメッセージ内の専用フィールド内に書き込む手段と、
− プローブメッセージの生存時間の値を検査する手段と、
− プローブメッセージの伝送タイムスタンプを記録する手段と、
− 記録された伝送タイムスタンプと書き込まれた受信タイムスタンプとの差であるプローブメッセージ滞留時間を計算し、次にそれをプローブメッセージ内のフィールド内に書き込む手段と、
− 計算された滞留時間値を、プローブメッセージに対する他のノードまたは現在のノード自体の後続の動作によって上書きされないように保護するために、プローブメッセージ内のフラグの値を変更する手段と、
− プローブメッセージの生存時間の値をデクリメントし、比較する手段と、
− プローブメッセージから異なる情報、特に、計算された滞留時間、がプローブ応答メッセージ内にコピーされるプローブ応答メッセージを作成する手段と、
を含む、ネットワークノードにさらに関する。

本発明は、上述の方法を実施するように構成されたコンピュータプログラム製品にさらに関する。

本発明は種々の変更および代替形態を受け入れる余地があるが、図面においてはその特定の実施形態が実施例として示されている。しかし、本願明細書における特定の実施形態の説明は、本発明を、開示されている特定の形態に限定するように意図されるものではないことを理解されたい。

もちろん、このような実際の実施形態の開発においては、システム関連および業務関連の制約条件の順守等の、開発者の特定の目的を達成するために、実装固有の決定がなされるべきであることを理解されたい。このような開発努力は時間のかかるものとなり得ようが、それにもかかわらず、本開示の利益を得る当業者にとっては通常の了解事項であってよいことは理解されよう。

本発明の目的、利点およびその他の特徴は以下の開示および特許請求の範囲からより明らかになる。以下の好ましい実施形態の非限定的説明は、添付の図面を参照して例示の目的でのみ与えられている。

従来技術によるプローブヘッダのフォーマットを示すブロック図である。 第１の実施形態によるプローブヘッダのフォーマットを示すブロック図である。 従来技術の診断コマンドｔｒａｃｅｒｏｕｔｅ（）の実施形態を示すブロック図である。 診断コマンドの機能的実施形態を示すブロック図である。 第２の実施形態によるプローブヘッダのフォーマットを示すブロック図である。

診断コマンド、以下、ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ（）として示されるものが提供される。この呼称は命名の目的で与えられているにすぎず、従来のｔｒａｃｅｒｏｕｔｅ（）コマンド（例えばＲＦＣ１３９３）および遅延測定問題の両方にある程度言及している。言うまでもなく、任意の他の名称がそのために与えられてよい。

プローブメッセージヘッダを制御することによって、ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ（）コマンドは、経由ノードアドレスに加えて、経由ノード滞留時間および最終的に経由リンク伝播遅延を収集する。

一実施形態では、プローブは、変更されたＩＣＭＰメッセージである。実際には、ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ（）コマンドは、ＩＣＭＰタイムスタンプ、およびＩＣＭＰタイムスタンプリプレイメッセージ（ＲＦＣ９７２）のいくつかのフィールドを、想定されているものとは異なるように使用する（これらの既存のフィールドに新しい意味を与える）。

図１および２を参照すると、従来のＩＣＭＰタイムスタンプまたはタイムスタンプリプレイメッセージ（ＲＦＣ９７２）のフィールド「発信タイムスタンプ」、「受信タイムスタンプ」、および「伝送タイムスタンプ」（図１）が、それぞれ、ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ（）コマンドに従って、（図２）「アウトバウンド滞留時間」、「受信タイムスタンプ」、および「戻り滞留時間」フィールドと置き換えられている。さらに、「アウトバウンド滞留時間」および「戻り滞留時間」フィールドの各々には、フラグ「Ｌ」が関連付けられている。

従って、ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ（）コマンドによるプローブヘッダは以下のものを含む。

− フィールド「タイプ」、「コード」、「チェックサム」、「識別子」、および「シーケンス番号」等のＩＣＭＰタイムスタンプおよびタイムスタンプ応答メッセージに共通のフィールド（図１および２）。これらのフィールドは、それらのそれぞれの従来技術で認識されている機能（すなわち、データチャンクの破損を判定するための「チェックサム」フィールド、またはメッセージの識別を可能にする「識別子」フィールド等のそれらの標準的解釈）の通りに用いられる。

− 「アウトバウンド滞留時間」フィールド：このフィールドはネットワークノード内における、アウトバウンド方向のパケット滞留時間である（マイクロ秒単位）。

− 「受信タイムスタンプ」フィールド：このフィールドは、各経由ノードにおけるパケット受信タイムスタンプのログを取るためのプレースホルダである。これは、ノードが、このタイムスタンプを伝送タイムスタンプに対して減算することによって伝送時のパケット滞留時間を計算することを可能とする。

− 「戻り滞留時間」：このフィールドは、ルータ内における、戻り方向のパケット滞留時間である（マイクロ秒単位）。

− 「Ｌ」ビット：それぞれのフィールド（アウトバウンド／戻り滞留時間）をロックし、それが他のノードまたは現在のノード自体によるパケットの後続の処理によって上書きされるのを防ぐためのフラグ。

変更されたＩＣＭＰタイムスタンプまたはタイムスタンプ応答メッセージを利用することは、すでに標準化されているがどちらかと言えば未利用であったこれらのメッセージを活用することのみを目的としており、迅速な実装および展開をもたらすことに注目されたい。

代替的に、上述のプローブフォーマットは、ＩＣＭＰタイムスタンプおよび／またはタイムスタンプ応答メッセージと全く関係なく定義されてもよい。この場合には、「アウトバウンド滞留時間」、「受信タイムスタンプ」、「戻り滞留時間」フィールド、ならびに「アウトバウンド滞留時間」および「戻り滞留時間」フィールドの各々に関連付けられる保護フラグ「Ｌ」を含むプローブヘッダが考えられる。これらのフィールドは上述のタスクのためにプログラムされる。

ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ（）コマンドは以下の構文を有する：
ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ（宛先アドレス、［ＱｏＳ、モード］）
ここで
− 「宛先アドレス」は宛先ネットワークノードのアドレスである。

− 「ＱｏＳ」は、ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ（）コマンドを移送する関連プロトコルプローブメッセージに、その発信点においてタグ付けするためのサービス品質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ、ＱｏＳ）またはサービスクラス（Ｃｌａｓｓ ｏｆ Ｓｅｒｖｉｃｅ、ＣｏＳ）の値を指定する。初期設定では、またはオペレータによって指定される値がない場合には、「ＱｏＳ」値は「ベストエフォート」値に設定される。

− 「モード」はコマンドの動作モードを示し、片方向（すなわち値０）または双方向（すなわち値１）モードを意味する。初期設定では、またはオペレータによって指定される値がない場合には、値は１に設定される。

「宛先アドレス」のフォーマットは、ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ（）コマンドを移送するために用いられる技術およびプロトコルに依存する。例えば、それは以下のものであり得る：
− ＩＰアドレス（またはホスト名）。このコマンドがＩＣＭＰの拡張機能（ＲＦＣ４８８４＆５８３７）を介して移送される場合。あるいは
− ＮＳＡＰ（Ｎｅｔｗｏｒｋ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ、ネットワークサービスアクセスポイント）アドレス。このコマンドが非ＩＰネットワーク内でマルチプロトコルラベルスイッチングトランスポートプロファイル（Ｍｕｌｔｉ−ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｆｉｌｅ、ＭＰＬＳ−ＴＰ）ＯＡＭプロトコル（Ｏｐｅｒａｔｉｏｎ Ａｎｄ Ｍａｉｎｔｅｎａｎｃｅ（運用および保守）、運用管理および保守としても知られる）（ＲＦＣ５８６０）、を介して移送される場合。

入力される「ＱｏＳ」は、以下のもののために設定されることになる値である：
− ＩＰヘッダ内の差別化サービスコードポイント（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｃｏｄｅ Ｐｏｉｎｔ、ＤＳＣＰ）フィールドのため。ＩＣＭＰ等のＩＰ上のプロトコルが用いられる場合。

− 汎用マルチプロトコルラベルスイッチング（Ｍｕｌｔｉ−ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ、ＭＰＬＳ）ラベル内の実験用（ＥＸＰ）の３ビット予備フィールドのため。ＭＰＬＳ ＯＡＭまたは疑似回線（Ｐｓｅｕｄｏ−ｗｉｒｅ、ＰＷ）ＯＡＭが用いられる場合。または
− ＩＥＥＥ８０２．１ｐによって言及されている通りの３ビット優先度コードポイント（Ｐｒｉｏｒｉｔｙ Ｃｏｄｅ Ｐｏｉｎｔ、ＰＣＰ）フィールドのため。異なるｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ（）メッセージを移送するためにイーサネットＯＡＭが用いられる場合。

実際、データパケット遅延は、多くの場合、各経由ノードにおいて、設定される関連スケジューリングで、適用される差別化サービス処理、およびその（発信／出発点において）割り当てられた「ＱｏＳ」に依存する。

「モード」入力に関しては、各通信方向（アウトバウンド方向および戻り方向）でパケットジッタの大きさが異なることにより、パケット滞留時間は、多くの場合、各方向で異なる。従って、２つのモード、すなわち片方向モードおよび双方向モードが提供される。「識別子」フィールドの最上位ビットが片方向（値０）と往復遅延（値１）測定モードとを分別することを可能とする。

より一般的には、以下のもの等の、ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ（）コマンドの呼び出しを定義する他の入力パラメータが考えられてもよい：
− ＵＤＰ（初期設定による）、ＩＣＭＰ、またはＴＣＰ等のプローブパケットプロトコルに言及する「プロトコル」。

− ネットワークノード毎のプローブパケット数を示す「ｐ」。

ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ（）コマンドの動作を紹介するために、従来のｔｒａｃｅｒｏｕｔｅコマンドの基本アルゴリズムを思い出してもらう簡単な図が図３に示されている。

ＩＣＭＰｖ４上において、従来のｔｒａｃｅｒｏｕｔｅ（）コマンドは、ノード（１からｎ）をリンクするネットワーク経路に沿った各ノード（２からｎ）にＩＣＭＰエラーメッセージを返させることによって機能する。プロービングはホップバイホップで行われ、一連の往復１１−１３において送信元から離れて宛先ｉ（ｉ＝２、．．．、ｎ）へと向かう。生存時間またはホップ数は１から開始し、宛先ノードｎに到達するまで、または別の停止条件が適用されるまで、各往復１１−１３の後にインクリメントされる。

実際には、従来のｔｒａｃｅｒｏｕｔｅ（）は、ＴＴＬ＝１（生存時間）としてその最初のパケット群を送る。従って、経路に沿った１番目のルータ（ノード２）がパケットを破棄し（それらのＴＴＬはゼロにデクリメントされる）、ＩＣＭＰ「ＴＴＬ超過」エラーメッセージを返すことになる（往復１１）。こうして、ｔｒａｃｅｒｏｕｔｅ（）は１番目のルータ（ノード２）のアドレスを記録することができる。次に、パケットは、ＴＴＬ＝２（往復１２）、次にＴＴＬ＝３以下同様（往復１３）として送られることができ、経路に沿った各ルータに、それを識別するエラーをｔｒａｃｅｒｏｕｔｅ（）コマンド（送信元ルータまたはホストに配置されている）に返させる。最後には、最終宛先（ノードｎ）に到達するか、または最大ＴＴＬ値（デフォルト値は３０）に達してｔｒａｃｅｒｏｕｔｅ（）が終了するかのいずれかとなる。最終宛先においては、異なるエラーが返される。

実装によっては、何もリッスンしていないいずれかのランダムな高番号ポートにＵＤＰデータグラムを送ることによって動作し、他の実装によっては、ＩＣＭＰエコーパケットを利用する。

次に図４を参照すると、従来のｔｒａｃｅｒｏｕｔｅ（）コマンドと同様に、ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ（）は、ＴＴＬ＝１（往復１１）、次にＴＴＬ＝２（往復１２）、以下同様（往復１３）として、ＩＣＭＰタイムスタンプメッセージを宛先ゲートウェイ（ノードｎ）へ連続的に送る。ノードｎに向かうこの方向がアウトバウンド方向と呼ばれる。反対の方向が戻り方向と呼ばれる。

アウトバウンド方向の場合、各経由ノードｉ（ｉ＝２、．．．、ｎ）は以下の動作を実現する：
− （図４のステップ２１）：
− （例えば入力ポートにおいてハードウェアによるタイムスタンプ付けを用いて）担当プロトコルがパケットの存在を検出するとすぐに、タイムスタンプパケット受信時刻（このパケットがネットワークノード内の関連プロトコルスタック（例えばＩＰプロトコル、イーサネットプロトコル、等）によって受信された時刻を記す）を記録し、タイムスタンプ値をパケット「受信タイムスタンプ」フィールド内に書き込む（ステップ２１）。

− ＴＴＬを１、デクリメントする、
− （図４のステップ２２）。ＴＴＬ＝１である場合には、パケット伝送プロセスにおいて（例えば出力ポートにおいて）、
− このパケットが伝送のために関連プロトコルスタックから出た時刻を記すパケット伝送タイムスタンプを記録する（例えばＩＰスタックの場合には、これは、ＩＰスタックがイーサネット層等のトランスポート層へのＩＣＭＰパケットを伝送のために処理した時刻となる）。

− ノードｉ内におけるパケット滞留時間を、このノードにおいて測定されたパケットの伝送タイムスタンプと受信タイムスタンプとの差として計算する。

− そのように計算された滞留時間値をパケット「アウトバウンド滞留時間」フィールド内に書き込む。

− このフィールドのＬ−ビットを、それを後続の動作によって上書きされないように保護するために、１に設定する（Ｌ−ビットがすでに設定されている場合、この場合には、前のノードがＴＴＬ値をデクリメントするのを忘れたか、あるいはそれがＬ−ビットを誤って設定したかのいずれかの誤りの問題があり、この場合には、動作は、パケットを回送することではなく、「アウトバウンド滞留時間」フィールドを０に設定し、関連Ｌ−ビットを１に設定して、「タイムスタンプ応答」メッセージを送り返すことになる）。

そうでなく、宛先に到達するか、またはＴＴＬ＝０である場合（図４のステップ３１）、
− 「タイムスタンプ応答」メッセージを作成することが作成される。その「アウトバウンド滞留時間」フィールドおよび関連Ｌ−ビットは「タイムスタンプ」メッセージから複製／コピーされる。「識別子」フィールドについても同様である。「タイムスタンプ応答」メッセージは「タイムスタンプメッセージ」の発信元へ送り返される、
− ＴＴＬ＝０であり、且つ宛先に到達していない場合、ＩＣＭＰ「ＴＴＬ超過」エラーメッセージを発信元へ送り返す。

戻り方向の場合、各ノードは以下の動作を実現する：
− （図４のステップ２３）：
− （例えばその入力ポートにおいて）それがパケットを検出するとすぐに、タイムスタンプ応答パケット受信タイムスタンプを記録する。

− 受信タイムスタンプ値をパケット「受信タイムスタンプ」フィールド内に書き込む。

− （図４のステップ２４）。「識別子」フィールドの最上位ビットが設定され（双方向モード、すなわち値１）、且つ 「戻り滞留時間」の関連Ｌ−ビットが設定されていない場合、次いで、その出力ポートにおいて、
− 受信タイムスタンプに基づいてパケット滞留時間：伝送タイムスタンプと受信タイムスタンプとの差、を計算する。および
− そのように計算された値をパケット「戻り滞留時間」フィールド内に書き込む。

− 「戻り滞留時間」フィールドを後続の動作によって上書きされないように保護するために関連Ｌ−ビットを１に設定する。

図４に、ＴＴＬ＝２とした、上述のアルゴリズム適用の実例が示されている（往復１２）。本例では：
− ノード２が、入力ポートからパケットを検出するとすぐに、受信タイムスタンプ値を、受信されたプローブのフィールド「受信タイムスタンプフィールド」内に書き込む（図４のステップ２１）。

− ノード２がＴＴＬを１、デクリメントする。ＴＴＬ＝１になるので、次いで、ノード２は滞留時間を計算し、それを「アウトバウンド滞留タイムスタンプ」に書き込み、このフィールドを上書きされないように保護するためにＬ−ビットを１に設定する（図４のステップ２２）。

− ノード３がＴＴＬを０にデクリメントする。「アウトバウンド滞留タイムスタンプ」を破棄する前に、ノード３は、対応するフィールドを、新たに作成されたタイムスタンプ応答メッセージ内の関連フィールドにコピーする。ノード３は後者のメッセージを送信元ルータまたは送信元ホストへ送り返す（図４のステップ３１）。

− ノード２がパケット受信タイムスタンプを記録し、先のものを「受信タイムスタンプ」フィールド内に書き込む。

− 「識別子」フィールドの最上位ビットが双方向モードに設定されている場合、ノード２はその出力ポートにおいて戻り滞留時間を計算し、タイムスタンプ応答メッセージのフィールド「戻り滞留時間」を更新する。次いで、この先のフィールドに関連するＬ−ビットが、それを上書きされないように保護するために、１に設定される（図４のステップ２４）。

より一般的には、ＴＴＬ＝ｉ（ｉ＝１、．．．、ｎ−１）である各往復１１−１３内で、ノードｉ内における、片方向および／または双方向モードの滞留時間が測定され、次いで、プローブメッセージヘッダ内に格納される。それに応じて、ノード毎の異なる単方向滞留時間（または単方向レイテンシ）がオペレータのために要約テーブル内に表示されてよい。

その目的のために、ネットワークノードｉ（ｉ＝２、…、ｎ）は以下のものを含む：
− それがプローブパケットを検出すると（すなわち関連プロトコルスタックによって検出されると）すぐに、その入力ポートからのプローブパケットの受信タイムスタンプを記録する手段。

− 受信タイムスタンプをプローブパケット内のフィールド内に書き込む手段。

− プローブパケットの生存時間の値を検査し、比較する手段。

− プローブパケットの伝送タイムスタンプ（すなわちパケットが伝送のために関連プロトコルスタックから出た時刻）を記録する手段。

− 記録された伝送タイムスタンプと受信タイムスタンプとの差であるパケット単方向滞留時間を計算し、プローブパケット内のフィールド内に書き込む手段。

− 計算された滞留時間値を、（他のネットワークノードまたはそのノード自体による）プローブメッセージに対する後続の動作によって上書きされないように保護するために、プローブパケット内のフラグの値を変更する手段。

− プローブパケットの生存時間の値をデクリメントし、比較する手段。

デクリメントされた後に１より真に大きいＴＴＬを有するプローブパケットをノードが受信した場合には、プローブパケットは滞留時間測定ステップを経ずに回送されることに留意されたい。

ＭＰＬＳ−ＴＰ ＯＡＭの別の実施形態は、上述のアルゴリズムに加えて、ＩＥＴＦ文書「Ｏｐｅｒａｔｉｎｇ ＭＰＬＳ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｆｉｌｅ ＬＳＰ ｉｎ Ｌｏｏｐｂａｃｋ Ｍｏｄｅ」、２０１０年３月、を利用する。

送信／送信元保守エンドポイント（Ｍａｉｎｔｅｎａｎｃｅ Ｅｎｄ Ｐｏｉｎｔ、ＭＥＰ）によって、リモート／宛先ＭＥＰに到達するまでＴＴＬを１から増加させながら、異なるＯＡＭループバックが実施される。

この目的のために、ＭＰＬＳ−ＴＰ ＯＡＭ組み込みのｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙメッセージが定義される。図４に、そのフォーマット（ＭＰＬＳ−ＴＰ ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ）が示されている。同図において：
− 「アウトバウンド／戻り」はメッセージ方向：アウトバウンド（値０ｘ００−以前の「タイムスタンプ」メッセージに相当）方向または戻り方向（値０ｘ０１−以前の「タイムスタンプ応答」メッセージに相当）、を指定する。

− 「Ｌ−ビット」は、ＩＣＭＰの実施形態において上述されたのと同じ意味を有する。

− 「アウトバウンド滞留時間」は、ＩＣＭＰの実施形態において上述されたのと同じ意味を有する。

− 「受信タイムスタンプ」は、ＩＣＭＰの実施形態において上述されたのと同じ目的を有する。

− 「戻り滞留時間」は、ＩＣＭＰの実施形態において上述されたのと同じ意味を有する。

− 「発信元伝送タイムスタンプ」は、パケットの、それが送信元／発信元によって伝送された時の（発信元ローカルクロックに基づく）タイムスタンプを示す。

− 「片方向受信タイムスタンプ」は、パケットの、それが宛先ノードによって受信された時の（宛先ノードローカルクロックに基づく）タイムスタンプを示す。

最後の２つのフィールドが、ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ（）コマンドがエンドツーエンド片方向遅延（すなわち「片方向受信タイムスタンプ」−「発信元伝送タイムスタンプ」）を計算することを可能とする。これは、宛先ノードクロックが、測定要件に適合された正確度で発信元クロックに同期されていることを仮定している。

「発信元伝送タイムスタンプ」は、発信元が戻りメッセージの受信時に往復遅延を計算することを可能とする。これは、「アウトバウンド」メッセージ（このメッセージは前の実施形態における「タイムスタンプ」メッセージに相当）の「発信元伝送タイムスタンプ」フィールドが、「戻り」メッセージ（このメッセージは前の実施形態における「タイムスタンプ応答」メッセージに相当）の「発信元伝送タイムスタンプ」フィールドにコピーされることを課す。

前のＩＣＭＰの実施形態では、「発信元伝送タイムスタンプ」がない場合でも、発信元は往復遅延をなお測定することができることに留意されたい。それは、例えば、メッセージ識別子（すなわち「識別子」フィールド）の値毎に、ローカルに（すなわちローカルコンテキストメモリ内に）関連伝送タイムスタンプのログを取り、同じ識別子を有する「タイムスタンプ応答」メッセージの受信タイムスタンプのログを取ることができる。

測定された連続的な往復時間により、ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ（）コマンドは、往復時間からノード滞留時間を減算することによって総リンク遅延を計算することができることに注目されたい（リンク遅延は対称的であると仮定）。

ネットワークノード滞留時間は、各プロトコル層において他の層とは独立して監視される。例えば、ＩＰ／イーサネットネットワークにおいては：
− ＩＣＭＰ／ＩＰプロトコル層は、それが着信イーサネットＭＡＣインタフェースからの着信パケットを（ＩＰプロトコルスタックの視点から）検出することができた時刻としてパケット受信時刻（受信タイムスタンプ）のログを取り、それは、それが発信イーサネットＭＡＣインタフェースへのパケット処理した時刻としてパケット伝送時刻（伝送タイムスタンプ）のログを取る。

− イーサネットＯＡＭ層は、それが着信物理インタフェースからの着信パケットのフレーム開始を検出することができた時刻としてパケット受信時刻（受信タイムスタンプ）のログを取り、それは、それが発信物理インタフェースへのパケットを処理した時刻としてパケット伝送時刻（伝送タイムスタンプ）のログを取る。

従って、所与のネットワークノードにおいて、ＩＣＭＰ／ＩＰ層において報告される通りの平均滞留時間の方が、イーサネットＯＡＭ層によって報告されるものよりも小さくなる。後者（プロトコルスタック内の最下層プロトコル）のためには、ハードウェアによるタイムスタンプ付けが実装されることができる。この方法により、所与のノード内において、ネットワークノードレイテンシに最も影響を与えるプロトコル層を分析することができる。ノード内のすべての層における滞留時間の測定方法は実装固有のものであり、本発明の範囲内ではない。

「タイムスタンプ応答」メッセージのＩＰ送信元アドレスは、ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ（）に、アウトバウンドおよび戻り滞留時間の両方が測定されるノードのＩＰアドレスを提供するのではなく、アウトバウンド経路上の次のノードのＩＰアドレスを提供することに留意されたい。ノードＩＰアドレスを得るには、コマンドは前の「タイムスタンプ応答」メッセージを参照しなければならない。

ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ（）は、プローブメッセージを送るために、以下のもの等の異なる方法を用いてもよい：
− パケットバイパケット：従来のｔｒａｃｅｒｏｕｔｅの通り、すなわち、プローブを送り、応答またはタイムアウトを待ち、次のプローブを送る、以下同様。

− ノードバイノード：所与のノードのために１つを超えるプローブを、プローブ間に設定可能な遅延（オペレータによって入力されるかまたはデフォルト値によって与えられる）を持たせて送り、応答またはタイムアウトを待ち、次いで、次のノードのために同じ手順を繰り返す。

コマンドは、診断目的のためにオンデマンドで実行されることができるが、顧客が問題を検出する前に迅速に対処するために、予防的に一定時間毎に自動実行されることもできることに注目されたい。

ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ（）コマンドはオペレーティングシステム内に含まれるか、またはネットワークツール（ＮｅｔＴｏｏｌｓ等）内にカプセル化されてもよい。

それはネットワークノード滞留時間の測定に関係しているので、滞留時間は小さい、つまり数ｍｓ未満程度であるため、ノードクロックの同期の必要は実際にはないことに留意されたい。フリーランで１００ｐｐｍ（ｐａｒｔ−ｐｅｒ−ｍｉｌｌｉｏｎ、百万分率）の正確度の従来の低コストのクロック（例えばイーサネットインタフェースクロック）は、１０ｍｓの滞留時間の間に１μｓの測定エラー（１００×１０^−６×１０×１０^−３）（およびそれぞれ、典型的な１０ノードのカスケードの場合には１０μｓ未満の最大測定エラー）を生じさせる。

有利には、ネットワーク経路内のノード滞留時間を知ることにより、許容遅延限界を提供していないノードの識別ができる。さらに、それは、ネットワークリンク、またはノードのいずれかへの導入遅延の決定的且つ正確な配分を可能にする。

有利には、上述の方法は、エンドツーエンド時間遅延を２つの成分：ネットワークセグメント（またはリンク）上の伝送遅延ならびにノード滞留時間、に分割することを可能にする。従って、ｔｒａｃｅｒｏｕｔｅ＿ｄｅｌａｙ（）コマンドは、エンドツーエンド片方向（または双方向）遅延の詳細なビュー／割り振りを提供し、エンドツーエンド片方向（または双方向）遅延がＳＬＡ閾値を超えたときに、作り直し／再設計されるべきネットワークセグメントまたはネットワークノードを指摘することを可能とする。

Claims (15)

1. 少なくとも、ネットワーク経路内に含まれるネットワークノード内におけるプローブメッセージの滞留時間を測定する方法であり、前記プローブメッセージが生存時間値を備える、方法であって、
   プローブメッセージの受信タイムスタンプを記録するステップと、
   受信タイムスタンプを、受信されたプローブメッセージ内の専用フィールド内に書き込むステップと、
   プローブメッセージの生存時間値を検査するステップと、
   生存時間値がヌルでない場合、生存時間値を１、デクリメントするステップと、
   生存時間値が１に等しい場合には、
   プローブメッセージの伝送タイムスタンプを記録するステップと、
   記録された伝送タイムスタンプに対して、記録された受信タイムスタンプを減算することによってネットワークノード内におけるプローブメッセージ滞留時間を計算するステップと、
   計算された滞留時間をプローブメッセージ内のフィールド内に書き込むステップと、
   滞留時間をプローブメッセージに対する後続の動作によって上書きされないように保護するために、受信されたプローブメッセージ内のフラグの値を変更するステップと、
   を含む、方法。
2. 生存時間値が、デクリメントされた後、ヌルである場合には
   計算された滞留時間、その関連フラグ値およびプローブメッセージ識別子をプローブメッセージからプローブ応答メッセージ内にコピーしてプローブ応答メッセージを作成するステップと、
   作成されたプローブ応答メッセージをプローブメッセージの発信元へ向けて送り返すステップと、
   をさらに含む、請求項１に記載の方法。
3. プローブメッセージが
   第１の通信方向の経由ネットワークノード内におけるプローブメッセージ滞留時間を保持するための第１のフィールド、
   ネットワークノードの入力ポートからのプローブメッセージ受信タイムスタンプのログを取るためのプレースホルダ、
   プローブメッセージに対するあらゆる後続の動作による第１のフィールドの上書きを防ぐための第１のフラグ、
   を含む、請求項１または請求項２に記載の方法。
4. プローブメッセージが
   第１の方向とは反対の第２の通信方向の経由ネットワークノード内におけるその滞留時間を保持するための第２のフィールド、
   プローブメッセージに対するあらゆる後続の動作による第２のフィールドの上書きを防ぐための第２のフラグ、
   をさらに含む、請求項３に記載の方法。
5. 経由ネットワークノードのための、通信方向に関する情報が、少なくとも、プローブメッセージ内で伝達されるフィールドによって示される、請求項３または請求項４に記載の方法。
6. プローブメッセージが、変更されたインターネット制御メッセージプロトコルメッセージである、請求項１から５のいずれか一項に記載の方法。
7. プローブメッセージが、変更された運用管理保守メッセージである、請求項１から５のいずれか一項に記載の方法。
8. プローブメッセージの受信タイムスタンプを記録する手段と、
   受信タイムスタンプを、受信されたプローブメッセージ内の専用フィールド内に書き込む手段と、
   プローブメッセージの生存時間の値を検査する手段と、
   プローブメッセージの伝送タイムスタンプを記録する手段と、
   記録された伝送タイムスタンプと書き込まれた受信タイムスタンプとの差であるプローブメッセージ滞留時間を計算し、次にそれをプローブメッセージ内のフィールド内に書き込む手段と、
   計算された滞留時間値を、プローブメッセージに対する他のノードまたは現在のノード自体の後続の動作によって上書きされないように保護するために、プローブメッセージ内のフラグの値を変更する手段と、
   プローブメッセージの生存時間の値をデクリメントし、比較する手段と、
   を含む、ネットワークノード。
9. プローブメッセージから情報がプローブ応答メッセージ内にコピーされるプローブ応答メッセージを作成する手段をさらに含む、請求項８に記載のネットワークノード。
10. コピーされる情報が、計算された滞留時間、およびプローブメッセージの識別子を含む、請求項９に記載のネットワークノード。
11. コンピュータおよび／または専用システムのメモリ上に格納される命令を含むコンピュータプログラムであって、請求項１から７のいずれか一項に記載の方法を実施するように構成される、コンピュータプログラム。
12. 入力がネットワークノードの宛先アドレスを含む、請求項１１に記載のコンピュータプログラム。
13. 入力が、プローブメッセージおよび関連プローブ応答メッセージの移送のためのサービス品質またはサービスクラス仕様を含む、請求項１１または請求項１２に記載のコンピュータプログラム。
14. 入力が、片方向モードまたは双方向モードの指示を含む、請求項１１から１３のいずれか一項に記載のコンピュータプログラム。
15. 少なくとも、請求項１から７のいずれか一項に記載のプローブメッセージおよび関連プローブ応答メッセージによって経由されるネットワーク経路内のネットワークノード内における片方向または双方向滞留時間を表示するようにプログラムされた、請求項１１から１４のいずれか一項に記載のコンピュータプログラム。

Images