(57)【要約】【課題】　パケットの拡張ヘッダを利用して、測定動作をネットワークの通常の処理の中で実行すること。【解決手段】　ネットワークの第１監視地点を通過するパケットを、追加情報を前記パケットに組み込むための、該パケットのデータ構造定義の特性に従って選択するステップと、少なくとも１つのネットワーク動作パラメータを測定するための所定の情報を、前記選択されたパケットに、該パケットのデータ構造定義に従って組み込むステップと、前記パケットのアドレス情報に従って前記パケットを宛先に転送するステップと、前記ネットワークの第２監視地点を通過する前記パケットを、前記所定の情報の有無に従って選択し、前記所定の情報を観測するステップと、前記ネットワーク動作パラメータの測定を、前記観測した情報に従って実施するステップと、により行う。　 【選択図】図１
2004112791.tif 000002
【特許請求の範囲】
【請求項１】
　ネットワークで稼動するトラフィックの状態を示すネットワーク動作パラメータを測定する方法であって、
　ネットワークの第１監視地点を通過するパケットを、追加情報を前記パケットに組み込むための、該パケットのデータ構造定義の特性に従って選択するステップと、
　少なくとも１つのネットワーク動作パラメータを測定するための所定の情報を、前記選択されたパケットに、該パケットのデータ構造定義に従って組み込むステップと、
　前記パケットのアドレス情報に従って前記パケットを宛先に転送するステップと、
　前記ネットワークの第２監視地点を通過する前記パケットを、前記所定の情報の有無に従って選択し、前記所定の情報を観測するステップと、
　前記ネットワーク動作パラメータの測定を、前記観測した情報に従って実施するステップと、を含む方法。
【請求項２】
　前記第１および第２監視地点は、前記ネットワーク内で物理的に同一の場所に位置する請求項１記載の方法。
【請求項３】
　前記第１および第２監視地点の少なくともいずれかは、前記選択されたパケットの送信元または宛先の終点に位置する請求項１または２記載の方法。
【請求項４】
　前記終点へのパケット経路には無線接続を含む請求項３記載の方法。
【請求項５】
　前記ネットワーク動作パラメータは、片道の場合の終端間の遅延、往復遅延、累積遅延、２地点間ロス、およびネットワークにおけるパケット伝播の中のいずれかである請求項１から４のいずれか１つに記載の方法。
【請求項６】
　前記所定の情報は、前記第１監視地点からの前記パケットの送信タイムスタンプである請求項５記載の方法。
【請求項７】
　前記ネットワークはインターネットプロトコルバージョン６（ＩＰｖ６）を使用し、前記所定の情報はＩＰｖ６拡張ヘッダに組み込まれている、請求項１から６のいずれか１つに記載の方法。
【請求項８】
　前記ＩＰｖ６拡張ヘッダは、「Destination　Options」拡張ヘッダである請求項７記載の方法。
【請求項９】
　ネットワークで稼動するトラフィックの状態を示すネットワーク動作パラメータを測定するシステムであって、
　ネットワークの第１監視地点を通過するパケットを、追加情報を前記パケットに組み込むための、該パケットのデータ構造定義の特性に従って選択する選択部と、
　少なくとも１つのネットワーク動作パラメータを測定するための所定の情報を、前記選択されたパケットに、該パケットのデータ構造定義に従って組み込むパケット修正部と、
　前記パケットのアドレス情報に従って前記パケットを宛先に転送するパケット転送部と、
　前記ネットワークの第２監視地点を通過する前記パケットを、前記所定の情報の有無に従って選択し、前記所定の情報を観測する選択部と、
　前記ネットワーク動作パラメータの測定を、前記観測した情報に従って実施するパラメータ測定部と、を備えるシステム。
【請求項１０】
　前記ネットワーク動作パラメータは、片道の場合の終端間の遅延、往復遅延、累積遅延、２地点間ロス、およびネットワークにおけるパケット伝播の中のいずれかである請求項９に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は、ネットワーク動作パラメータを測定する方法およびシステムに関する。ネットワーク動作パラメータは、ネットワークで稼動するトラフィック（ＴＣＰ／ＩＰｖ６（Transmission　Control　Protocol　over　Internet　Protocol　version　６）を使用するネットワークにおけるデータパケットなど）で発生する、例えば、片道の場合の終端間の遅延などである。
【背景技術】
【０００２】
　インターネットの成長とビジネスおよび個人の活動への普及に伴い、その運用を監視し最適化するニーズも拡大している。その一例が、片道の場合の終端間の遅延の測定である。アプリケーションの中には、この遅延値が大きいと性能に影響を受けるものが存在する。たとえば、遅延変動（ジッタ）が過度な場合には、リアルタイムで動くアプリケーションは中断することになり、終端間の遅延が大き過ぎると、トランスポート層のプロトコルでは大きな帯域幅を維持できなくなる。終端間の遅延の最小値は、伝播および伝送遅延の推定値（即ち、負荷の軽い経路条件下での遅延）を示す。値がこの最小値を上回ると、パケットが通過する経路の輻輳の程度を示す優れた指標になる。往復遅延を確認するのは容易であるが、上流と下流のデータ経路がかなり異なる場合があり、仮にそれらが対称であったとしても、非常に異なる性能特性を示すことがあるため、往復遅延は、片道の場合の遅延を推定する優れた手段を必ずしも提供するものではない。
【０００３】
　２１世紀初頭の段階で最も広範に使用されているインターネット技術は、インターネットプロトコルのバージョン４（ＩＰｖ４）であり、このインターネット技術で使用される測定および監視技法の大部分は、受動型および能動型という２つの主要カテゴリのいずれかに分類される。
【０００４】
　受動型の測定技術では、パケットによって送られるサービスを中断することなしに、リンク上の実際のトラフィック（データパケット）が観測される。通常、これらの技術では状態機械（state machine）を使用する。状態機械では、初期レベルのフィルタリングを実行する。また、対象のトラフィックを選択した後にパターンマッチング技法を使用して特定のイベントを検索する。これらのイベントの検出により、様々なカウンタを適切に更新できる。この例には、ＮＥＰ（Network　Element　Provider）およびＲＭＯＮ（Remote　Monitoring）プローブによって実装された性能測定ＭＩＢ（Management　Information　Base）が含まれる。その他の受動型監視プローブ解決策では、これを更にもう一歩進め、指定したパターンにマッチするパケットからペイロードデータを抽出している。フルパケットのキャプチャも可能である。そして、収集したデータは、要求に応じて（プルモード）、または所定のトリガイベントの発生時に（プッシュモード）、ユーザーに提供される。
【０００５】
　後述する能動型の測定と同様に問題は、ユーザーが、測定に関連があるＩＰリンク上で送ることが必要な膨大な量の測定データを生成する場合があることである。この場合、リソース要件の競合に起因して被検サービスの性能が下がる。また、異なる受動型監視法で得られる測定値から推測できる内容は大きく異なる。ＲＭＯＮおよびＭＩＢベースの解決策は、主にネットワーク上のすべてのトラフィックの活動の総合的な状況を表すカウンタで構成される傾向がある。取得した情報を個別のサービスに関連付けたり、契約で合意した項目の遵守状況を監視するのに利用可能な知識を推測したりすることは困難である。これら様々なカウンタの実装は、産業または公的な規格によって規定されていることが多く、従って、新しいタイプの測定について認可を取得し採用に至るまでには、かなりの時間を所要することになる。特定のトラフィックストリームから生成されるイベントに依存した技法は、ＱｏＳ（quality　of　Service）性能関連の問題の解決に適しているであろう。
【０００６】
　受動型の監視技法は、ネットワーク上の１つの観測地点で実際のユーザートラフィックの１地点測定値を収集するのに特に有用である。しかしながら、別個の２つの観測地点で検出されたパケットの創刊をとるのは複雑なので、受動型の技法は、単一方向遅延などの実際のユーザートラフィックの２地点測定を実行するのにはあまり適していない。既存の解決策によれば、通常、適切に配置した監視地点でパケット内の識別可能なデータパターンを観測する。そして、タイムスタンプとデータパターンの適切なダイジェストを生成し、保存する。その後、特定の経路に沿う片道の場合の終端間の遅延は、経路のいずれかの端部から監視地点において同一のデータパターンを観測した時点の間における時間として算出可能である。しかしながら、この方法には、いくつかの欠点が存在する。往復遅延を測定する場合と異なり、関連付けのために少なくとも１つの監視地点からもう一方の監視地点に測定データを転送する必要がある。もしくは、更に望ましくないことであるが、関連付けのために測定データを両方の監視地点から第３の場所に転送する必要がある。これらの追加的な測定データは、監視対象のものと同一のネットワークリンクで送られる必要があり、得られる結果が影響を受ける可能性が高い。また、監視地点におけるスケジューリング遅延、関連付け地点への測定データの転送に伴う伝播および伝送遅延、および関連付け自体に要する時間が原因で、測定の実行時点と終端間の遅延の値を算出する時点の間で大きな遅延が発生することになる。関連付けプロセスを実行する場所とその機能は、この観点から見た測定性能に影響を及ぼす更なる要因である。
【０００７】
　遅延測定のためのクロックの同期化以外に、測定データの収集にあたり、同一のパケットを両方の測定地点でトリガする技術が必要である。また、消失またはミスマッチサンプルをエラー処理することも必要である。さらに、受動型測定プローブは、トラフィック量とデータレートが増加しても追随できない。
【０００８】
　能動的な技法は、測定用に特別につくられた統合的トラフィックネットワークへの注入に基づく。この統合的トラフィックは、サービスの特定の属性を試験するべく設計された既知の特性を有している。このタイプの測定技法は、特に、応答時間、パケットロス、帯域幅、およびサービスの可用性に関連する２地点測定の実行にあたり採用されることが多い。能動的技法は、インサービスおよびアウトオブサービス試験にも同様に適している。この種の技法はいくつかのグローバルプロジェクトで使用されている。特に、ＩＥＴＦ（Internet　Engineering　Task　Force）のＩＰ性能測定ワーキンググループ（IP　Performance　Metrics　Working　Group）においては、統合的トラフィックの使用に基づく測定の標準化を推進中である。
【０００９】
　単一方向遅延の場合には、注入されたパケットに送出前にタイムスタンプを付加するか、あるいは時刻およびパケット識別子の記録を取得して保存するかしなければならない。向こう側では、この注入パケット（それらのすべてあるいはサンプルのいずれか）を識別し、ストリームから除去する。そして、別のタイムスタンプを取得し、送出時のタイムスタンプと照らし合わせて必要な遅延の測定値を導出する。
【００１０】
　能動的な測定技法の主な欠点は、測定対象のパケットの転送およびルーティング動作が、統合的トラフィックにより発生するという点である。（必ずしも）実際のユーザートラフィックにより発生するのではない。その結果得られる測定値は、実際のユーザートラフィックで発生することを、仮定し予測するのに使用される。従って、優れた結果を得るには、統合的トラフィックが、実際のユーザーデータと同一の取り扱いを受け、同一の伝送経路を辿るよう、統合的トラフィックを適切に形成してそれらに実際のユーザーデータと同様の伝送特性を付与することが非常に重要である。その一方で、被検サービスについて付加価値の高い判定を実行する場合の、能動的測定の精度に対する信頼は依然として厚い。
【００１１】
　インターネット技術の拡張バージョンであるバージョン６（ＩＰｖ６）の策定は既に完了しており、現在、実システムに実装されつつある。ＩＰｖ６では、ＩＰｖ４と比べると、次のような様々な拡張機能が提供されている。
【００１２】
　・１２８ビットのＩＰアドレッシング
　・「集約」のために設計されたスケーラブルで階層的なアドレッシング
　・処理を単純化し、冗長性を排除すると共に、拡張された機能を提供する「拡張」ヘッダを包含する規定を有する優れた構造のパケット
　・ＱｏＳ（Quality　of　Service）／ＣｏＳ（Class　of　Service）のサポート
　・プロトコルに固有のセキュリティ
　・ホストの「プラグ＆プレイ」自動構成
　・モビリティのサポート
【発明の開示】
【発明が解決しようとする課題】
【００１３】
　これらの機能拡張は、効率的で信頼性が高く安定したデータ伝送を行うにあたり、インターネットの基本機能を改良および拡張するべく設計されたものである。これに対し、本発明では、１つまたは複数のこれらの機能拡張を用いて、ＩＰｖ６を使用するインターネット機器の動作の監視および測定を容易に改良する更なる機会を提供する。
【課題を解決するための手段】
【００１４】
　本発明の一態様によれば、ネットワークで稼動するトラフィックの状態を示すネットワーク動作パラメータを測定する方法が提供され、この方法は、
　ネットワークの第１監視地点を通過するパケットを、追加情報を前記パケットに組み込むための、該パケットのデータ構造定義の特性に従って選択するステップと、
　少なくとも１つのネットワーク動作パラメータを測定するための所定の情報を、前記選択されたパケットに、該パケットのデータ構造定義に従って組み込むステップと、
　前記パケットのアドレス情報に従って前記パケットを宛先に転送するステップと、
　前記ネットワークの第２監視地点を通過する前記パケットを、前記所定の情報の有無に従って選択し、前記所定の情報を観測するステップと、
　前記ネットワーク動作パラメータの測定を、前記観測した情報に従って実施するステップと、を有している。
【００１５】
　本発明は、ＩＰｖ６パケットの拡張ヘッダによって提供される機会を認知し発展させ、「インライン測定」を実行するものである。本明細書において使用するこの「インライン」という用語は、測定活動を起動する測定トリガおよび／または測定データ自体が、実際のユーザーパケット内に組み込まれ、この結果、測定動作をパケットの通常の処理の中で（あるいは、ネットワーク内の適切な地点に配置された特殊なソフトウェアまたは特殊なハードウェアモジュールによって）実行できることを意味している。ここでは、測定の実行に使用するパケットに、大部分のユーザーパケットと同一の取り扱いおよび遅延が発生する確率が大きい。これに要する機能は、ＩＰｖ６拡張ヘッダを使用することにより簡単に実装可能であって、それにより正確で、柔軟で、侵害性の少ない測定を実行できる。従って、このインライン技法は、革新的で正確且つ柔軟な測定、管理、会計、および請求処理サポートシステムの開発に活用できる。
【００１６】
　本発明の別の態様によれば、ネットワークで稼動するトラフィックの状態を示すネットワーク動作パラメータを測定するシステムが提供され、このシステムは、
　ネットワークの第１監視地点を通過するパケットを、追加情報を前記パケットに組み込むための、該パケットのデータ構造定義の特性に従って選択する選択部と、
　少なくとも１つのネットワーク動作パラメータを測定するための所定の情報を、選択されたパケットに、該パケットのデータ構造定義に従って組み込むパケット修正部と、
　パケットのアドレス情報に従って前記パケットを宛先に転送するパケット転送部と、
　ネットワークの第２監視地点を通過する前記パケットを、前記所定の情報の有無に従って選択し、前記所定の情報を観測する選択部と、
　前記ネットワーク動作パラメータの測定を、前記観測した情報に従って実施するパラメータ測定部と、を有している。
【発明を実施するための最良の形態】
【００１７】
　本発明については、便宜上、伝送用にデータをパケットに分割するＩＰｖ６を実装するネットワークを参照して説明する。しかしながら、本発明は、ＩＰｖ６拡張ヘッダに類似の機能を提供するその他のネットワーク技術についても同様に適用可能であることを理解されたい。従って、本明細書において使用する「パケット」という用語には、その他のネットワーク技術でセルやフレームなどの別の用語で呼ばれるデータ分割単位も包含されているものと理解されたい。
【００１８】
　図１を参照すれば、リンクによって相互接続されたルータ１０〜２２を有するインターネットの概略ブロック図が示されている。例えば、ルータ１０に到来するパケット２４は、ルータ間で交換される情報からルータが構築するルーティングテーブルに従い、パケットの一部を形成するヘッダで識別されるその宛先に対してルータ１２、１４、および１６を介して送付される。インターネットソサエティ（Internet　Society）のＲＦＣ（Request　for　Comments）２４６０にＩＰｖ６用として規定されているパケットヘッダのフォーマットが図２に示されている。
【００１９】
　この図２を参照すれば、パケットヘッダが、従来の表示法により、それぞれが連続した３２個の２値の数値（４オクテット）を表す複数行のシーケンスとして示されている。機能的なエンティティを形成する隣接ビットをグループ化した単位を四角形で示している。ＩＰｖ６ヘッダには、次のように、このようなグループが８つ含まれている。
【００２０】
・Version（バージョン）
　４ビットからなるインターネットプロトコルのバージョン番号（＝６）である。
【００２１】
・Traffic　Class（トラフィッククラス）
　８ビットからなるトラフィッククラスフィールドである。
【００２２】
・Flow　Label（フローラベル）
　２０ビットからなるフローラベルである。
【００２３】
・Payload　Length（ペイロード長）
　１６ビットからなる符号なし整数である。ＩＰｖ６のペイロード（即ち、ＩＰｖ６ヘッダに続く、すべての拡張ヘッダを含むパケットの残りの部分）の長さである（単位：オクテット）。
【００２４】
・Next Header（次のヘッダ）
　８ビットからなるセレクタである。http://www.iana.org/assignments/protocol-numbersにおいてＩＡＮＡ（Internet　Assined　Numbers　Authority）が（現在）指定しているプロトコル番号を使用し、このＩＰｖ６ヘッダの直後のヘッダのタイプを識別する。
【００２５】
・Hop　Limit（ホップリミット）
　８ビットからなる符号なし整数である。このパケットを転送する各ノードによって１ずつ減分される。この「Hop　Limit」がゼロになると、そのパケットは破棄される。
【００２６】
・Source　Address（送信元アドレス）
　ＲＦＣ２３７３の指定に従ってフォーマットされたパケットの送信元の１２８ビットからなるアドレスである。
【００２７】
・Destination　Address（宛先アドレス）
　パケットの送信先である受信者の１２８ビットからなるアドレスである（「Routing」ヘッダが存在する場合には、最終受信者ではない可能性が高い）。
【００２８】
　ＩＰｖ６の場合には、図２に示されているＩＰｖ６ヘッダとパケット内の上位層（例：ＴＣＰ）のヘッダとの間に配置可能な別個のヘッダ内に、任意選択のインターネット層情報をエンコードすることができる。このような拡張ヘッダには様々なものが存在し、それぞれが別個の「Next Header」の値で識別される。図３は、このような拡張ヘッダの１つである「Destination　Options（宛先オプション）」ヘッダのフォーマットを示している。このヘッダは、パケットの宛先ノードのみがチェックすることを要する任意選択の情報を送るのに使用する。「Destination　Options」ヘッダは、直前のヘッダの「Next Header」の値６０によって識別され、次のフィールドを含んでいる。
【００２９】
・Next Header（次のヘッダ）
　８ビットからなるセレクタである。前述のＩＰｖ６ヘッダの「Next Header」フィールドと同様に「Destination　Options」ヘッダの直後のヘッダのタイプを識別する。
【００３０】
・Hdr　Ext　Len（拡張ヘッダ長）
　８ビットからなる符号なし整数である。最初の８オクテットを除く「Destination　Options」ヘッダの長さである（単位：８オクテット（６４ビット））。
【００３１】
・Options（オプション）
　完成した「Destination　Options」ヘッダの長さが８オクテットの整数倍になるようにする可変長フィールドである。後述するように、１つまたは複数のＴＬＶ（Type−length−value）エンコードされたオプションを含んでいる。
【００３２】
　図４に示されているように、ＴＬＶエンコードされたオプションは、次のようなフォーマットを有している。
【００３３】
・Option　Type（オプションタイプ）
　８ビットからなるオプションタイプの識別子である（後述する）。
【００３４】
・Opt　Data　Len（オプションデータ長）
　８ビットからなる符号なし整数である。このオプションの「Option　Data」フィールドの長さである（単位：オクテット）。
【００３５】
・Option　Data（オプションデータ）
　可変長フィールドである。「Option−Type」の固有データである。
【００３６】
　オプションタイプ識別子の最上位の２ビットは、ＩＰｖ６ノードの処理によって「Option　Type」が認識されない場合に実行を要する動作を次のように指定している。
【００３７】
　００−このオプションをスキップし、ヘッダの処理を継続する。
【００３８】
　０１−このパケットを破棄する。
【００３９】
　１０−このパケットを破棄し、パケットの「Destination　Address」がマルチキャストアドレスであるかどうかに関係なく、ＩＣＭＰ（Internet　Control　Message　Protocol）Parameter　Problem（Code　２）メッセージを当該パケットの「Source　Address」に送信し、認識されなかった「Option　Type」を指摘する。
【００４０】
　１１−このパケットを破棄し、パケットの「Destination　Address」がマルチキャストアドレスでない場合にのみ、ICMP　Parameter　Problem（Code　２）メッセージを当該パケットの「Source　Address」に送信し、認識されなかった「Option　Type」を指摘する。
【００４１】
　「Option　Type」の最上位から３番目のビットは、そのオプションの「Option　Data」がパケットの最終的な宛先へ向かう途中で変化可能かどうかを示しており、これにより、この変化の影響を受けることなく、認証値の算出または検証を実行できるようになっている。このビットの意味は次のとおりである。
【００４２】
　０−「Option　Data」は途中で変化しない。
【００４３】
　１−「Option　Data」は途中で変化可能である。
【００４４】
　別の種類の拡張ヘッダである「Routing（ルーティング）」ヘッダのフォーマットが図５に示されている。このヘッダは、パケットが宛先に向かう途中で「訪問」する１つまたは複数の中間ノードをＩＰｖ６の送信元が一覧表示するのに使用する。「Routing」ヘッダは、直前のヘッダの「Next Header」の値４３によって識別され、次のフォーマットを有している。
【００４５】
・Next Header（次のヘッダ）
　８ビットからなるセレクタである。前述のＩＰｖ６ヘッダの「Next Header」フィールドと同様に、この「Routing」ヘッダの直後のヘッダのタイプを識別する。
【００４６】
・Hdr　Ext　Len（拡張ヘッダ長）
　８ビットからなる符号なし整数である。最初の８オクテットを除く「Routing」ヘッダの長さである（単位：８オクテット）。
【００４７】
・Routing　Type（ルーティングタイプ）
　８ビットからなる「Routing」ヘッダのタイプ識別子である。
【００４８】
・Segments Left（残存セグメント）
　８ビットからなる符号なし整数である。残っているルートセグメント数である（即ち、最終的な宛先に到達するまでに訪問を要する明示的に一覧表示されている中間ノードの数である）。
【００４９】
・Type−Specific　Data（タイプ固有データ）
　「Routing　Type」によって決定されるフォーマットの可変長フィールドであり、この長さは、完成した「Routing」ヘッダが８オクテットの整数倍になるようになっている。
【００５０】
　すべての拡張ヘッダは、その全体の長さが８オクテットの整数倍になるようにフォーマットしなければならず、ヘッダ内の幅がｎオクテット（ｎ＝１、２、３、または８）のフィールドは、ヘッダの頭からｎオクテットの整数倍のところに配置することを要する。これを実現するために、値がゼロの１オクテットからなるＰａｄ１オプション（長さまたは値フィールドは存在しない）と、値がゼロのＮ−２個のオクテットと値１を格納するタイプフィールドおよび値Ｎ−２を格納する長さフィールドを有するＰａｄＮオプション（合計でＮオクテットを挿入するためのものであって、Ｎ＞１である）という２つの特別なＴＬＶエンコードしたオプションが定義されている。
【００５１】
　特別な「Hop−by−Hop　options」ヘッダ（本明細書では説明していないが、ＲＦＣ２４６０には記載されている）を除き、ＲＦＣでは、メインＩＰｖ６ヘッダに格納されている宛先アドレスを有するノード（あるいは、マルチキャストサービスの場合には、ノードのグループ）においてのみ、これらの様々なＩＰｖ６拡張ヘッダのそれぞれをチェックすることを要求している。即ち、パケット転送ルートに沿ってＩＰｖ６に従ってルーティングを実装するだけの中間ノードは、パケット拡張ヘッダをチェックしたり処理したりしないのである。
【００５２】
　各拡張ヘッダは、「Next Header」フィールドによって次のヘッダの開始点を示し、それにより単一方向のチェーンの一種を形成している。このチェーン内の各ヘッダは、厳格にその順番どおりに処理され、そしてそれぞれの拡張ヘッダの内容と意味に従い、受信ノードが次のヘッダに進むかどうかが決定される。図６は、「Destination　Options」ヘッダをパケットのＩＰｖ６ヘッダとペイロード間に挿入した場合のこの種のヘッダチェーンの例を示している。この場合には、ＩＰｖ６ヘッダの「Next Header」フィールドは値６０を格納しており、これに対応する「Destination　Options」ヘッダのフィールドは値６を格納して、この拡張ヘッダの後にＴＣＰ上位プロトコル層のヘッダとデータが続くことが示される。
【００５３】
　本発明は、例えば、「Destination　Options」および「Routing」ヘッダなどの拡張ヘッダを利用して、動作パラメータの「インライン」測定を円滑に実行する。動作パラメータには、片道の場合の終端間の遅延、双方向（往復）遅延、累積遅延（パケットがリンクの様々なセグメントを通過する際に付加されたタイムスタンプを使用するもの）、および２地点間ロス（２地点間の伝送におけるパケットの消失）などがある。また、本発明は、追跡対象のパケットを識別する拡張ヘッダ内のタグによってネットワーク上のパケットの伝播を追跡するなど、ルータの動作の監視にも使用することができる。この測定と監視は、通常動作の一部としてネットワークを伝播するパケットに、以下の例において説明するようにフォーマットした拡張ヘッダを追加することによって実現される。
【００５４】
　例えば、「Destination　Options」ヘッダの場合は、この拡張ヘッダのオプションタイプ識別子の最上位の２ビットを００に設定することにより、このヘッダが付加されたパケットを処理するというルータの正常な動作を中断させることなく、これらの目的に便利に使用することができる。この「Destination　Options」ヘッダは、必要に応じて、そのパケットの送信先である宛先（例えばクライアント／サーバー）に配信される前に除去することができる。しかしながら、これを実行しなくても（意図的に実行しなかったり、あるいは、誤ってヘッダが除去されなかった場合にも）、受信時には、宛先ノードは、００オプションタイプ識別子に従って、このオプションを単にスキップする。
【００５５】
　原則的には、RFC2460によれば、将来的に、更なる拡張ヘッダタイプを定義することが許容されており、測定用の固有の拡張ヘッダを定義することも可能であろう。そして、定義された場合には、それらの固有の拡張ヘッダにおいて本発明を使用可能である。しかしこの方式の場合、測定拡張ヘッダと一意に関連付けられ、ネットワーク内のあらゆる場所において識別可能な、固有の「Next Header」値が提供される。この結果、ネットワーク機器の製造者およびネットワーク事業者は、この「Next Header」値を格納するヘッダを有するパケットが測定および管理データの収集に使用されていることを判定することができる。このようなパケットを、好ましいとはいえ異質な方法で処理するように機器を設計することは容易だが、測定の目的とは逆効果になる可能性がある。ヘッダの測定目的を識別することはできないので、「Destination　Options」拡張ヘッダ（または、「Routing」ヘッダ）を使用することにより、このリスクを排除することができる。さらにこれらヘッダの適用対象ノードのみが、正常なネットワークの動作において「Destination　Options」または「Routing」ヘッダの処理を行い、その結果それらの動作の障害になるリスクが減る。
【００５６】
　しかしながら、測定プロセスに関係するノード（例えば、後述する例におけるルータ１０およびルータ１６）で、関連する拡張ヘッダを検出して処理することは、正常なネットワークの動作では無視するものであっても当然必要である。このことは、後述するように、これらのノード内の通常のオペレーティングファームウェアに、必要に応じてノードのパケット処理機能を拡張するモジュールを増設することで実現できる。
【００５７】
　遅延測定の際に測定に必要な情報を送るには、「Destination　Options」拡張ヘッダを使用するのが便利である。図７は、単一方向遅延を測定するのに使用するこのヘッダのフォーマットを示しており、これには、次のような適切なオプションデータフィールドが含まれている。
【００５８】
・Pointer（ポインタ）
　８ビットからなる符号なし整数である。オプションデータ内の次の未使用スロットの位置を示すのに使用する（即ち、タイムススタンプを保存するためのものである）。
【００５９】
・Overflow（オーバーフロー）
　８ビットからなる符号なし整数である。タイムスタンプを収容するために存在するスロット数を上回る数のタイムスタンプの保存を試みるかどうかを示すのに使用する。
【００６０】
・Flags（フラグ）
　例えば、オプションデータフィールド内の別の場所に保存されているデータの特性を示すものなど、８つの２値フラグから構成されるオクテットである。
【００６１】
・Reserved（予約済み）
　アライメントのために含まれる値がゼロのオクテットである（即ち、完成した拡張ヘッダのサイズが８オクテットの整数倍になるようにするものである）。
【００６２】
・Source　timestamp（送信元タイムスタンプ）
　２つの３２ビットからなる符号なし整数である。拡張ヘッダを挿入したノードのインターフェイスから当該パケットが転送された時間を示すタイムスタンプである。２つの整数は、ＵＴＣ（Universal　Coordinated　Time）１９７０年１月１日の００：００時からの経過時間の秒およびマイクロ秒の部分をそれぞれ表している。
【００６３】
・Destination　timestamp（宛先タイムスタンプ）
　２つの３２ビットからなる符号なし整数である。送信元タイムスタンプと同一のフォーマットであり、拡張ヘッダを検出するノードのインターフェイスにおけるパケットの受信時間を示すタイムスタンプである。
【００６４】
　ヘッダ内の「Option　Type」識別子は、「片道の場合の終端間遅延の測定」を識別するべく割り当てられた値に設定される。
【００６５】
　図１に示されている本発明の例は、単一のネットワーク事業者の制御下にある区間の境界を横断するパケットフローの入口地点と出口地点間など、ネットワークの一区間における遅延を測定するケースを示している。しかしながら、本発明は、サーバー（例：ウェブサイトをサービスするもの）からクライアント（例えばウェブブラウザアプリケーションが稼動する無線接続された携帯情報端末（ＰＤＡ））などの「終端間の」の測定にも同様に適用することができる。
【００６６】
　再度図１を参照すると、ルータ１０は、適切な所定の基準に従って１つまたは複数のパケットを選択するように構成されている。例えばパケットを、指定した宛先に対してアドレス指定されているものからランダムに選択するか、または宛先には関係なく特定の送信元のパケットから選択してもよい。他には、ＴＣＰ、ＵＤＰ（User　Datagram　Protocol）、ＩＣＭＰ、またはＩＧＭＰ（Internet　Group　Management　Protocol）などの特定の上位層プロトコルによって送られるすべてのパケットを選ぶことが可能である。またはＳＩＰ（Session　Initiation　Protocol）、ＲＴＰ（Real−Time　Transport　Protocol）、またはＨＴＴＰ（Hypertext　Transfer　Protocol）などの特定のアプリケーションタイプのすべてのパケットを選択することも可能である。即ち、同一特性に準拠する所望のパケットフローまたはストリームにある（例えば、ネットワークの入口地点における）パケットを、（オプションフィールドを有する）拡張ヘッダを挿入するにあたり識別する場合、任意の複雑なルールによって行うことができる。このルールには例えば、送信元および宛先ＩＰアドレスおよびプレフィックス、トランスポートプロトコル、ＴＣＰやＵＤＰなどのトランスポートプロトコルに含まれている送信元および宛先ポート番号、トラフィッククラス、およびフローラベルの組み合わせがある。ネットワーク上でＩＰｖ４とＩＰｖ６パケットの両方が送られている場合には、ＩＰｖ６パケットから選択する。
【００６７】
　測定を反復実行する必要があり、インライン測定用に選択するパケットの間隔を均一にしなければならない場合には、同一経路を使用し同一周期で通信を行うその他のアプリケーションの動作が遅延測定の結果に影響を及ぼす可能性がある。この問題を緩和するには、パケットの間隔をポアソン分布や切れたパレート分布などのランダムな分布から選択することが望ましい。
【００６８】
　適切なパケットの選択が完了すると、「Destination　Options」拡張ヘッダを追加し（あるいは、パケットが既にこのヘッダを格納している場合には、それを変更し）、図７に示されているようにフォーマットされたＴＬＶオプションを追加する。タイプフィールドは、「片道の場合の終端間の遅延」とタイムスタンプ値を示す。測定対象の遅延は、送信ノードのリンクインターフェイスからの送出時点と宛先ノードのリンクインターフェイスにおける到着時点間のリンクをパケットが通過する際の合計時間（「ワイヤ時間」と呼ばれるもの）である。従って、タイムスタンプをパケットのヘッダに挿入する前に、タイムスタンプ値の取得時点とインターフェイスからのパケットの送出時点との間の、ノードにおける既知または推定最終処理時間を、タイムスタンプに加算するべきである。必要に応じて、別のＴＬＶエンコードされたオプションを含めて、受信ノードにおける算出の後に遅延の測定結果を転送するべきアドレス（例：ネットワーク管理ノードのアドレス）を提供することも可能である。
【００６９】
　図８は、遅延測定用の「Destination　Options」拡張ヘッダを挿入する前のＩＰｖ６パケットの例を示している。そして図９は、同じパケットに、タイムスタンプと転送アドレスのＴＬＶオプションを格納するヘッダ（点線で強調表示されている）が追加された後を示している。これら２つの図を比較すれば、図９のＩＰｖ６の「Payload　length（ペイロード長）」フィールドが４８だけ増加しており、拡張ヘッダのオクテット数を示している。そして、ＩＰｖ６ヘッダの「Next Header（次のヘッダ）」フィールドが６０に変化しており（「Destination　Options」拡張ヘッダが続くことを示している）、「Hop　limit（ホップリミット）」が減分されている。拡張ヘッダの「Next Header（次のヘッダ）」フィールドは、前にはＩＰｖ６ヘッダに存在していた値６を格納している（後続するＴＣＰヘッダを示している）。拡張ヘッダの長さは、最初の８オクテットを除き、８オクテット単位で５であると示されている。最初のＴＬＶオプションは、３３（００１０　０００１）のオプションタイプ値を有している。このオプションタイプ値は、この例においては、「片道の場合の終端間の遅延」であることを示す。また、これを処理するべく装備されていないノードで、このオプションがスキップされることがあることを示し、かつこのオプションデータ（即ち、宛先タイムスタンプ）が変化可能であることも示している。このオプションの長さは２０オクテットである。ポインタ値は１３（００００　１１０１）であって、１３番目のオクテット（宛先タイムスタンプの開始点）がこのオプションにおける次の未使用スロットであることを示しており、「Overflow（オーバーフロー）」および「Flags（フラグ）」オクテットはゼロに設定されている。送信元タイムスタンプは、３Ｄ１０　ＦＣ００Ｈ秒（２００２年６月の日付に対応している）と０００Ｂ　８６Ａ０Ｈマイクロ秒である（１８００の直後の時刻に対応している）。次のＴＬＶオプションは、全部で６オクテットのパディングを有しており、転送アドレスを指定する最後のオプションが続いている。このオプションは、３４（００１０　００１０）のタイプを有しており、この例においては、「遅延測定値の転送アドレス」を示すと共に、これを処理するように装備されていないすべてのノードはこのオプションをスキップ可能であり、且つこのオプションデータの変化は不可であることをも示している。このオプションの長さは１６オクテットであり、１２８ビットの転送アドレスから構成されている。
【００７０】
　遅延測定の対象になる経路のもう一方の端部におけるノード（図１の例では、ノード１６）は、後述するように、「Destination　Options」ヘッダを処理するように構成されており、特に、特殊な「片道の場合の終端間の遅延」および「遅延測定値の転送アドレス」ＴＬＶオプションを解釈することができる。ノード１６は、これらのヘッダの１つを有するパケットを受信したとき、そのヘッダの内容を読み出して保存する。そして、パケットを再度組み立てた後に（その他のオプションフィールドが存在しない場合には、「Destination　Options」ヘッダなしで組み立てられる可能性が高い）、そのパケットの最終的な宛先に転送する。
【００７１】
　そして、「Destination　Options」ヘッダ内に格納されている送信元タイムスタンプの値を読み出し、片道の場合の終端間のリンク伝送時間遅延を算出するべく、これを宛先ノードの現在の時間から減算する。この算出においては、このノードのインターフェイスにパケットが到着してからノードが自身の現在時刻の値を取得するまでの初期パケット処理時間をも考慮するべきである。算出した値は、その測定の緊急度に応じて、転送用に新たに生成したパケットに含まれる「Destination　Options」ヘッダのＴＬＶエンコードされたオプションを使用するか、あるいは、同一のアドレスに向かうユーザーパケットに付加することによって、「Destination　Options」ヘッダに指定されているアドレスに転送する。あるいは、この代わりに、後で送信あるいは収集するべく、別のＴＬＶオプションにより、遅延測定結果をノード１６内のキャッシュに保存するように指定することも可能である。
【００７２】
　送信元および宛先ノード内のクロックを所望の精度で同期化させるか、あるいはそれらの間の時間差を確認し安定させることが必要である。遅延の測定に（従って、タイムスタンプ処理に）必要な精度と正確性は、クロックの同期化法を選択する際の重要な要素である。これらおよび関連する課題については、RFC2679に詳しく記述されている。
【００７３】
　ＩＰｖ６の仕様では、ＩＰｖ６が稼動可能なように、すべてのリンクで１２８０オクテット以上のＭＴＵ（maximum　transmission　unit）サイズを有することを要求している。推奨ＭＴＵは１５００オクテットである。選択されたパケットに「Destination　Options」を追加することで、ノード１０がパケットの転送に使用するリンクのＭＴＵ限度を超過する危険性がある場合、次の適当なパケットを代わりに選択すべきである。理由は、遅延の測定はタイミングの影響を受け易いこと、従って、当該リンクでのパケットの転送に要する下位層のパケット分割と再組み立てに関わる時間ペナルティを被ることは適当ではないことである。パケットの選択プロセスが望ましくランダム化されていれば、選択プロセスにこの変更を加えても不都合な統計的影響は発生しないはずである。
【００７４】
　前述のように１０や１６などのルータが、この遅延測定を行うために、パケットへの「Destination　Options」ヘッダの追加と、別の場所でのそれらの検出および除去のプロセスとを実行する。これらのルータは、専用のデータプロセッサであり、ソフトウェアプログラムの制御下で動作する１つまたは複数のプロセッサユニットと、プログラムと関連データを保存する関連メモリと、処理中のパケットを保持するバッファメモリと、パケットを送受信する入力および出力インターフェイスを含んでいる。
【００７５】
　このシステムレベルで遅延やその他の測定を実行するのに必要な機能は、例えば、パケットヘッダの拡張を操作する追加処理ロジックと測定関連データの保存、検索、関連付け、および転送などのその他のサポート機能を提供する動的にロード可能なモジュールを使用することによって実装可能である。監視および測定タスクの組をモジュール化することにより、特定の時点で必要なモジュールのみを動的にロードすること、そして使用しなくなった時点でロードされたモジュールの領域を解放することが可能になる。これらのロード可能モジュールは、遠隔地からノードに配信し、ロードし、構成することが可能であり、使用する際には、ノードのオペレーティングソフトウェアの一部として効果的に組み込まれる。
【００７６】
　このように頻繁に使用する処理ロジックを最小化することにより、メモリの使用量を削減し、処理時間を短縮し、回路基板のスペース要件を緩和し、設計を単純化すると共に、サブシステム全体を簡素化することができる。携帯電話やハンドヘルド携帯情報端末（ＰＤＡ）などの無線ローカルエリアネットワーク（ＬＡＮ）の移動体装置を有するノードの場合には（この場合、処理能力とメモリの観点で限られたリソースしか有していない）、このモジュラー型の方式が特に有利である。シグナリング（または、場合によっては、データトラフィック自体）に応答して自動的にモジュールのロード／アンロードを実行するべく、必要な機能をネットワーク基地局ノードから簡単に提供可能であり、効率のよい測定と監視を行うための自動化された応答性のよい戦略が容易になる。特に、この場合には、トラフィック自体で測定／監視機能が起動されるため、測定を実行するためにネットワークのトラフィックを追跡することが不要になる。移動体端末は自由にローミング可能であり、単一セッションでデータがネットワーク内の複数の経路を経由することがあるため、この方式は、特に移動体セルラー無線アクセスネットワークにおいて有用であろう。
【００７７】
　モジュールはネットワーク内で必要に応じて自由に挿入および除去可能であるため、このモジュラー型の方式は、遠隔地に分散した実装にも適しており、動的に構成可能であって局所化された処理サイトおよび関連付けエンティティを実現することができる。組み込みモジュール型方式の更なる重要な利点は、通過するデータを監視するために、ルータ間のリンクを構成している電気的または光学的なケーブルに物理的に接続する必要がないという点である。この代わりに、組み込みモジュール型の方式では、ルータまたはその他のネットワーク装置内の予備のプログラム可能ロジックまたは処理能力を利用しており、統合され本質的に強力な解決策が提供される。アップグレードするには、新しいモジュールを（例えば、ネットワーク自体を介して）ノードに配信することが必要であり、配信の際に直接ロードしたり、あるいは、後で使用するべく、何らかの形態のローカル媒体（例：ハードディスクストレージ）上に一時的に保存することもできる。
【００７８】
　図１０は、複数のラインインターフェイス３２と、プロセッサ、メモリ、およびプログラムソフトウェアまたはファームウェアを備えたコントローラ３４を有する単一のネットワーク要素３０のアーキテクチャを図示したものである。この図では、次の３つの異なる統合ポイントの例が示されており、ここではネットワーク要素３０の設計に応じて、動的にロード可能なモジュールを収容可能である。
【００７９】
　・（Ａ）モジュールをラインインターフェイス３２上にロードできる。そのことにより、ハードウェア（例えばフィールドプログラム可能ゲートアレイ（ＦＰＧＡ））を動的に再構成するように制御するか、またはソフトウェア／ファームウェアでラインインターフェイスの処理ロジックを制御するか、あるいはこれら両方を複合して組み合わせる。
【００８０】
　・（Ｂ）モジュールを、コントローラ３４のソフトウェアオペレーティングシステムの「カーネル」またはこれと同等のものに、ロード可能ソフトウェアとして配置できる。
【００８１】
　・（Ｃ）モジュールを、コントローラのオペレーティングシステムが提供する「ユーザー」スペースに、ロード可能アプリケーションとして配置できる。
【００８２】
　オプションＢに従った統合は、オペレーティングシステムにより、モジュールをシステムカーネル（例えばＬＫＭ（Loadable　Kernel　Module））に追加することが可能になることを前提にしている。これらは、通常、ユーザースペースで稼動するアプリケーションに比べて処理性能が優れており、外部ユーザースペースの処理によってパケット全体を明示的に構築する必要がない。そしてネットワークプロトコルスタックのカーネル実装の一部として拡張ヘッダを追加、削除、および変更するべく簡単に構成できる。
【００８３】
　オプションＣは、ユーザースペースにあるＩＰｖ６拡張ヘッダの処理を含むが、オペレーティングシステムのプロトコルスタックとして実施するものではない。この場合、カーネルモジュールの使用ほどには洗練された解決策ではなく、性能も劣っているかもしれないが、オペレーティングシステムのカーネルプログラミング法に関する知識が不要であり、従って容易に実装できる。さらに、オペレーティングシステムのセキュリティおよび完全性に関連する問題が、対象のルータまたはその他のノードを運用する組織のセキュリティポリシーと抵触する可能性があるが、この場合これを回避することができる。
【００８４】
　この測定および監視を行うためのユーザートラフィックへの拡張ヘッダの挿入は、管理アプリケーションの要件に応じて動的に制御することができる。従って、すべてのユーザーパケットに拡張ヘッダを組み込む必要はない。この選択は、アプリケーションに基づいて実行可能であり、サンプリングも適用可能である。
【００８５】
　上述のインライン監視および測定を実行する技法では、従来の方式と比べ、次のようないくつかの利点が得られる。
【００８６】
　・ＩＰｖ６プロトコルを実装するルータの機能は、どのパケットが処理を要するかを検出するときの作業を実行するにあたり用いられる。対象のパケットが標準的な拡張ヘッダを介して識別されるからだ。従って、インターフェイスに到来するすべてのパケットをチェックする複雑なフィルタリング技法を避けて、パケットが監視／測定処理の対象となる所定の基準を満たしているかどうかをチェックすることができる。
【００８７】
　・測定およびトリガ情報を送るのはユーザートラフィック自体であり、従って、２つの監視地点のそれぞれでパケットを観測する際に、両方に同一のパケットが含まれることが保証されている。
【００８８】
　・同様に、経路の終点からのデータの関連付けが不要である。従って、測定システムが簡素化され、ネットワーク上で転送を要する測定データ量が潜在的に減少し、測定結果のスピーディな提供が促進される。
【００８９】
　・すべての追加されたデータは、実際のユーザートラフィックに組み込まれる。パケットヘッダ長がわずかに増えても、ネットワーク上のパケット伝播におけるパケットの取り扱われ方が変化しない場合、追加されたデータは、実際のユーザートラフィックと同様に取り扱われ、同一のルーティング経路を辿る公算が高い。
【００９０】
　・ネットワークで測定のために転送される追加トラフィックの合計量には制限がある。
【００９１】
　・パケットを注入する能動型の測定とは異なり、２地点インライン測定の場合には、ネットワークの稼動時にユーザーが経験するパケットの動作をより正確に反映することになる。この場合、変更を加えないパケットと比べ、付加されるシステム処理遅延も小さく、全体のパケット長もわずかに大きいだけでとなる。
【００９２】
　・ＩＰｖ６プロトコルの特性を活用することにより、ネットワーク動作の測定および監視の動的な実施が単純化される。この結果、同一機能を提供する特殊なプローブに伴うコスト、複雑さ、および要件が軽減される。
【００９３】
　・ＩＰｖ６拡張ヘッダを使用するインライン測定は、通常、使用される上位層トランスポートプロトコル（例：ＵＤＰまたはＴＣＰ）に影響されない。従って、選択された全トランスポートプロトコルについて（逆にいえば、所与のトランスポートプロトコルに関係なく）類似の測定を実施することができる。
【００９４】
　メインＩＰｖ６ヘッダの２０ビットからなる「Flow　Label」フィールド（図２）は、元来、実験的なものである。このフィールドが本来の意図した目的には実際に使用されない限りにおいて、また他の目的に使用してもネットワークの動作が損なわれないとの仮定では、「Destination　Options」、「Routing」ヘッダ、および「Flow　Label」フィールドの組み合わせにより、データを実際のユーザートラフィックに選択的に追加することが可能になる。実際のユーザートラフィックは、検出および処理対象となり、必要な機能がノードのＩＰｖ６プロトコル層によって実装される。
【００９５】
　この処理のレベルと特性は、拡張ヘッダに格納するオプションによって決定可能である。そして、カウンタの増分、タイムスタンプの注釈の追加、パケットデータの抽出とそのキャッシュへの吐き出し（タイムスタンプの注釈および様々なカウントと共に）、あるいはパケットのフルコピーキャプチャのトリガを必要とする。「Destination　Options」を単独で用いることにより、（ＩＰｖ６ネットワークにおける）終端間のインラインサービス測定を実行することができる。そして、「Routing」ヘッダの追加により、ユーザートラフィックがネットワーククラウドの重要な地点を通過するので、より詳細なサービスの測定を実現すべく、途中の特定のノードをターゲットにすることが可能になる。また、インラインデータを格納するユーザートラフィックは途中のノードを介してその宛先に転送されるので、動作の測定および監視を容易に識別してトリガするために、「Flow　Label」フィールド内のいくつかのビットを使用することが可能になる。
【００９６】
　概略的にいうと本発明は、図１１に示すように、次に説明する処理ステップを含んでいる。これらは、様々な異なる装置アイテム（例えばルータ）に分散して実行できる。
【００９７】
（ａ）パケットをネットワーク内の第１「論理」地点で選択する（４０）。
【００９８】
（ｂ）少なくとも１つの拡張ヘッダを用いて、パケットにデータを追加する（４２）。
【００９９】
（ｃ）任意選択で、既存の拡張ヘッダ内のデータを修正することができる。
【０１００】
（ｄ）例えば、ネットワーク内の第２「論理」地点において、パケットの拡張ヘッダのデータを観測する（４４、４６）。
【０１０１】
（ｅ）拡張ヘッダのデータを除去し（４８）、必要な測定値を取得する（５０）。
【０１０２】
　これらのネットワーク内の「論理」地点は、物理的に別個のポイントとすることができる。一方で、その測定または監視活動の特性に応じて、２つの「論理」地点は、同一の物理地点に物理的に同じく位置することも可能である。例えば１つの観測地点を使用して、ＴＣＰ接続、またはその観測地点を通過するトランザクションの「会話」（状態の確立および維持のためのシグナリングプロトコルなど）を追跡またはトラッキングすることができる。従って、応答ベースの測定では、この観測地点で、ある方向へと流れるパケットに拡張ヘッダを挿入し、一方で逆方向へのパケットの拡張ヘッダにある返送された値を受信することができる。
【０１０３】
　このようにして、ＴＣＰまたはその他の接続関連あるいはトランザクション的なプロトコルのための、接続セットアップ時間を推定することができる。更には、VoIP（voice−over−IP）のようなリアルタイムサービスを提供できるよう、ＳＩＰの関連性のセットアップに所用する時間を測定することも可能である。他の例では、論理的な測定点を共存させるにあたり、リングネットワーク上でパラメータを測定することができる。
【０１０４】
　以上便宜的に、ＩＰｖ６に準拠するネットワークを参照して本発明を説明したが、本発明は、ネットワーク上でパケットが通過する際に追加情報をパケットに組み込むことができるその他のネットワークシステムおよびプロトコルについても同様に適用可能である。
【図面の簡単な説明】
【０１０５】
【図１】インターネットの概略ブロック図。
【図２】ＩＰｖ６パケットヘッダの一般的なフォーマット。
【図３】ＩＰｖ６の「Destination　options（宛先オプション）」拡張ヘッダの一般的なフォーマット。
【図４】「Destination　options」拡張ヘッダの一部を形成するＴＬＶ（Type−length−value）タプルの一般的なフォーマット。
【図５】ＩＰｖ６の「Routing（ルーティング）」拡張ヘッダの一般的なフォーマット。
【図６】ＩＰｖ６拡張ヘッダをＩＰｖ６パケット内に組み込む方法。
【図７】本発明に従って測定を円滑に実行するべく構成された「Destination　options」拡張ヘッダの一例のフォーマット。
【図８】ＩＰｖ６パケットの一例。
【図９】単一方向遅延の測定を円滑に実行するべく、拡張ヘッダを包含することにより、本発明に従って変更された図８に示す例のＩＰｖ６パケット。
【図１０】本発明のソフトウェアをネットワーク要素において実装可能な地点を示すブロック概略図。
【図１１】本発明の一実施例における処理ステップの概要。
【符号の説明】
【０１０６】
　２４　パケット
【図１】
2004112791.tif 000003
【図２】
2004112791.tif 000004
【図３】
2004112791.tif 000005
【図４】
2004112791.tif 000006
【図５】
2004112791.tif 000007
【図６】
2004112791.tif 000008
【図７】
2004112791.tif 000009
【図８】
2004112791.tif 000010
【図９】
2004112791.tif 000011
【図１０】
2004112791.tif 000012
【図１１】
2004112791.tif 000013