(57)【特許請求の範囲】
【請求項１】
透過クロックを含むトンネルノード（１−４）によって少なくとも１つのカプセル化された同期メッセージ（６）を扱う方法であって、
−  前記カプセル化された同期メッセージ（６）から署名（７）を生成するステップと、
−  前記カプセル化された同期メッセージ署名（７）を含むトンネルフォローアップメッセージ（８）を生成する、または既に生成されている場合は更新するステップと、
−  前記トンネルノード（１−４）を横断する前記カプセル化された同期メッセージの滞留時間を測定するステップと、
−  前述の測定された滞留時間を用いて前記トンネルフォローアップメッセージの補正フィールドを更新するステップと
を含み、
前記トンネルフォローアップメッセージが、変更されたＯＡＭ  ＬＳＰ  ｔｒａｃｅｒｏｕｔｅメッセージ内に含まれる、方法。
【請求項２】
前記署名（７）が、前記カプセル化された同期メッセージ（６）全体のハッシュ関数を使用して生成される、請求項１に記載の方法。
【請求項３】
前記署名（７）が、前記同期メッセージ（６）の少なくとも顕著な特徴の全単射関数を使用して生成される、請求項１に記載の方法。
【請求項４】
前記同期メッセージ（６）の顕著な特徴が、その同期シーケンス番号である、請求項３に記載の方法。
【請求項５】
前記生成されたフォローアップメッセージ（８）が、イベントメッセージタイプＴＬＶをさらに含む、請求項１から４のいずれか一項に記載の方法。
【請求項６】
前記生成されたフォローアップメッセージ（８）が、トンネルレベルＴＬＶをさらに含む、請求項１から５のいずれか一項に記載の方法。
【請求項７】
前記生成されたフォローアップメッセージ（８）が、トンネルルーティング情報ＴＬＶをさらに含む、請求項１から６のいずれか一項に記載の方法。
【請求項８】
前記カプセル化された同期メッセージが暗号化される、請求項１から７のいずれか一項に記載の方法。
【請求項９】
前記トンネルノードが、事前定義された期間、前記トンネルフォローアップメッセージ（８）に関連する前記カプセル化された同期メッセージ（６）の受信を待つ間に、前記トンネルフォローアップメッセージ（８）をバッファリングする、請求項１から８のいずれか一項に記載の方法。
【請求項１０】
前記トンネルノード（１−４）がトンネルテールエンドノード（４）である場合、
前記トンネルフォローアップメッセージ（８）のファイルされた更新された補正を含む標準的なフォローアップメッセージ（１０）への前記トンネルフォローアップメッセージ（８）の変換ステップをさらに含む、請求項１から９のいずれか一項に記載の方法。
【請求項１１】
前記同期メッセージが、高精度時間プロトコルのイベントメッセージである、請求項１から１０のいずれか一項に記載の方法。
【請求項１２】
透過クロックを含み、着信したカプセル化された同期メッセージ（６）から署名（７）を生成するための手段と、前記カプセル化された同期メッセージ署名（７）を含むトンネルフォローアップメッセージ（８）を生成する、または既に生成されている場合は更新する手段とを備え、
前記トンネルフォローアップメッセージが、変更されたＯＡＭ  ＬＳＰ  ｔｒａｃｅｒｏｕｔｅメッセージ内に含まれる、トンネルノード（１−４）。
【請求項１３】
署名（６）を生成するための前記手段が、ハッシュ関数を含む、請求項１２に記載のトンネルノード（１−４）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に、高精度時間プロトコル（ＰＴＰ）とも呼ばれるＩＥＥＥ標準１５８８ＴＭ−２００８プロトコルを使用する同期転送の技術分野に関する。
【背景技術】
【０００２】
電気通信によるデータ伝送は、パケットベースのネットワーク（たとえば、イーサネット、ＭＰＬＳ／ＩＰ）にますます依存しているため、これらのネットワーク内において時間および周波数同期のために堅牢な方法がますます求められている。同期によって、時間および周波数スケールを合わせるために、ネットワークノード内に組み込まれた、ネットワーククロックに共通の時間および周波数基準を配布する方法を意味する。
【０００３】
ＩＥＥＥ（電気電子技術者協会）によって標準化された、高精度時間プロトコル（ＰＴＰ）は、パケットベースのネットワーク内の同期問題に取り組む最新の標準の１つである。実際に、ＰＴＰは、ネットワークタイムプロトコル（ＮＴＰ）など現在の時間同期技術の改善として設計された。
【０００４】
ＰＴＰは、タイムソース（マスタークロックとして指定）と受信機（スレーブクロックとして指定）との間の通信路遅延の測定に依存するパケットベースのプロトコルである。
【０００５】
ＰＴＰは、最初に境界クロック（ＢＣ）の概念を導入したが、すぐに、パケットベースのネットワークの開発によって、特に同期の連鎖においてカスケードされるＢＣの可能な数について、ＢＣの複数の制限が指摘された。実際、ＢＣの長い連鎖を通じた同期転送の結果、大きなフェーズエラーを蓄積する可能性があることが示されている。そのようなエラーは、主に以下によるものである。
−  必ずしも同調が必要ない場合がある（周波数で同期される）連鎖内の異なる対の連続するＢＣ間のＰＴＰメッセージ交換、および
−  連続するＢＣの位相ロックループサーボの利得最大化およびノイズ生成。
【０００６】
したがって、ＢＣの代わりとして、透過クロック（ＴＣ）と呼ばれる最近の概念が、主にカスケードによる拡張性の問題を回避する目的で第２のリリース（ＰＴＰＶ２）で指定された。
【０００７】
原則として、ＴＣは、単にネットワークノード（つまり、ブリッジ、ルータ、スイッチ、中継器など）を横断するＰＴＰパケット滞留時間の補正を提供するだけである。ここで、滞留時間は、ネットワークノードの入口ポートから出口ポートに伝播するためにＰＴＰイベントメッセージによって必要な時間に対応している。このために、ＴＣは、次を用いて続行する：
−  ＰＴＰイベントメッセージ（たとえば、Ｓｙｎｃ、Ｄｅｌａｙ＿ｒｅｑ、Ｄｅｌａｙ＿Ｒｅｓ）の識別、
−  それらの滞留時間の計算（入口および出口のタイムスタンプの両方が、滞留時間を計算するために記録され保存される）、
−  ＰＴＰイベントメッセージ内で新しく導入された時間間隔フィールドの更新（ＣＦ（補正フィールド）と呼ぶ）、そして次に
−  ただ単に通常のスイッチとして、これらの変更されたＰＴＰイベントメッセージの転送。
【０００８】
したがって、ＴＣがＰＴＰイベントメッセージを転送するのを維持できるが、それを変更した後、ＣＦ変更によって何が引き起こされる可能性があるかを覚えておくこと。
【０００９】
よって、トンネリングおよびカプセル化が引き起こされるとすぐに、ＰＴＰイベントメッセージ変更に関して複数の問題が生じる。実際、トンネル内にカプセル化されたＰＴＰパケット（または、より一般的にはＰＴＰイベントメッセージ）を変更する能力は、複数の問題および課題を引き起こす。それらの問題の中で、以下について述べることができる：
−  カプセル化されたＰＴＰイベントメッセージの変更は、レイヤ違反の問題を引き起こす。その理由は、トンネルの中間ノードによって変更されることからカプセル化されたデータを保護することを目的とするカプセル化自体の原理に矛盾するためである。文書「Ｉｓｓｕｅｓ  ｗｉｔｈ  ｔｈｅ  Ｔｒａｎｓｐａｒｅｎｔ  Ｃｌｏｃｋ  ｃｏｎｃｅｐｔ  ｏｆ  ＰＴＰｖ２」、フランステレコム、ＩＴＵ−Ｔ  ＳＧ１５／Ｑ１３中間会議、２００９年３月１６日−３月２０日、サンホセに、そのような問題が明らかにされている。この問題に関して、そのアドレスがパケットの宛先アドレスである場合のみ、所与のネットワークノードは、パケットペイロードを変更することが許される。そうでない場合、ノードは、レイヤ分離の原理に違反する。
−  変更自体が不可能な場合がある：いずれかのＰＴＰパケットコンテンツを変更するには、最初のカプセル化ヘッダおよび再計算されたチェックサムをすべて備えた新しいパケットを作成する必要がある。しかし、トンネルの中間ノードは、多くの場合、この目的のために実装されたすべてのプロトコルスタックを含んでいない。たとえば、ＥｏＳ（Ｅｔｈｅｒｎｅｔ（登録商標）−ｏｖｅｒ−ＳＤＨ）トンネル中央のＳＤＨ装置は、（たとえば、ＩＴＵＴ  Ｇ．７０４１によって規定されているようなフレームマップトジェネリックフレーミングプロシージャ（ＧＦＰ：Ｆｒａｍｅ−ｍａｐｐｅｄ  Ｇｅｎｅｒｉｃ  Ｆｒａｍｉｎｇ  Ｐｒｏｃｅｄｕｒｅ）で）イーサネット（登録商標）ヘッダを再生成し、特にイーサネットフレームチェックシーケンス（ＦＣＳ）を再計算するために、イーサネットプロトコルスタックを実装していない可能性がある。実際は、カプセル化対象のフレーム全体が受信時に破棄されることを回避するために、カプセル化されたＰＴＰメッセージ内の補正フィールドの変更は、すべてのＦＣＳの再計算を必要とする（たとえばＥｏＳカプセル化の状況におけるイーサネットＦＣＳおよびＧＦＰ  ＦＣＳの両方）。
−  ＩＰＳｅｃトンネリング、またはより一般的に暗号化使用の場合には、中間ノードによる、カプセル化されたＰＴＰパケットコンテンツの変更は、単に不可能なタスクとして示される（セキュリティの理由から、暗号鍵は中間ノードに配布されないため）。
【先行技術文献】
【非特許文献】
【００１０】
【非特許文献１】ＩＥＥＥ標準１５８８ＴＭ−２００８
【非特許文献２】「Ｉｓｓｕｅｓ  ｗｉｔｈ  ｔｈｅ  Ｔｒａｎｓｐａｒｅｎｔ  Ｃｌｏｃｋ  ｃｏｎｃｅｐｔ  ｏｆ  ＰＴＰｖ２」、フランステレコム、ＩＴＵ−Ｔ  ＳＧ１５／Ｑ１３中間会議、２００９年３月１６日−３月２０日、サンホセ
【非特許文献３】ＩＴＵ−Ｔ  Ｇ．７０４１
【非特許文献４】ＩＥＴＦ  ＲＦＣ  ３０３２
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本発明の目的の１つは、前述の問題の少なくとも１つを克服し、従来技術を超える長所を提供することである。
【００１２】
本発明の他の目的は、従来のＴＣに比較的複雑な回路を追加することなく、前述の問題の少なくとも１つを克服することである。
【００１３】
本発明の他の目的は、タイミングメッセージがＴＣによって扱われている間に、レイヤ違反を回避することである。
【００１４】
本発明の他の目的は、カプセル化／トンネリングの実施形態内で、または、より一般的にはタイミングメッセージを変更できないときに、ＴＣ展開を可能にすることである。
【００１５】
本発明の他の目的は、ＰＴＰイベントメッセージコンテンツにアクセスするその能力が何であろうと、トンネル内の中間ノードでＴＣ展開を許可することである。
【００１６】
本発明の他の目的は、ＰＴＰネットワーク内の暗号化されたトンネルを横断してＴＣ展開を許可することである。
【００１７】
本発明の他の目的は、ＩＰＳｅｃトンネルを横断するＴＣ展開のための方法を提供することである。
【課題を解決するための手段】
【００１８】
本発明は、上記の問題の１つまたは複数による影響に対処することを対象とする。以下は、本発明の一部の態様について基本的な理解を提供するために、簡素化した発明の概要を示すものである。この概要は、本発明の網羅的な概要ではない。これは、本発明の重要な要素の手がかりを特定したり、または本発明の範囲を描写したりすることを意図するものではない。その唯一の目的は、後で記述するより詳細な記述の準備として、単純化した形で一部の概念を示すことである。
【００１９】
本発明は、透過クロックを含むトンネルノードによってカプセル化された同期メッセージの少なくとも１つを扱うための方法に関し、方法は：
−  カプセル化された同期メッセージから署名を生成するステップと、
−  カプセル化された同期メッセージの署名を含むトンネルフォローアップメッセージを生成する、または既に生成されている場合は更新するステップと、
−  トンネルノードを横断してカプセル化された同期メッセージ滞留時間を測定するステップと
−  前述の測定された滞留時間を用いてトンネルフォローアップメッセージの補正フィールドを更新するステップと
を含む。
【００２０】
広い態様によると、同期メッセージは、クラスオブサービス（ｃｌａｓｓ  ｏｆ  ｓｅｒｖｉｃｅ）値のタグが付けられる。
他の広い態様によると、トンネルフォローアップメッセージは保守メッセージ内に含まれる。
他の広い態様によると、同期メッセージは暗号化される。
他の広い態様によると、同期メッセージは入れ子のトンネル内で伝えられる。
【００２１】
本発明は、透過クロックを含むトンネルノードにさらに関し、着信したカプセル化された同期メッセージから署名を生成するための手段を含む。
【００２２】
広い態様によると、着信したカプセル化された同期メッセージから署名を生成するための手段として、ハッシュ関数が提供される。
【００２３】
有利なことに、生成された署名は、トンネルフォローアップメッセージをその関連する同期メッセージ（たとえばＰＴＰイベントメッセージ）に一義的かつ一意に結合する。
【００２４】
有利なことに、トンネルフォローアップメッセージは、レイヤ分離の原理を破ることなく、トンネル中間ノードによって変更することができる。
【００２５】
本発明は、様々な変更および代替形式の余地があるが、その特定の実施形態を例示を目的として図面に示している。しかし、本明細書に記述した特定の実施形態の記述は、開示された特定の形式に本発明を限定することを意図するものではないことを理解すべきである。
【００２６】
もちろん、そのような実際の実施形態の開発のいずれにおいても、開発者の特定の目的を達成するために、システム関連およびビジネス関連の制約への遵守など、実装に固有の決定を行うべきであることを理解されるだろう。そのような開発努力は時間がかかる場合があるが、本開示の利益を受ける人または当業者にとっては日常的な認識の可能性があることを理解されるであろう。
【００２７】
本発明の目的、利点、および他の機能は、以下の開示および特許請求の範囲からより一義的になるだろう。添付図面に関して、以下に示す好ましい実施形態の限定しない記述は、例示のみを目的として提供するものであり、同様の参照文字は、同様の要素を指している。
【００２８】
本明細書において参照符号は、任意の特定の順序または階層を暗示するものではなく、参照目的のみに使用されることに注意されたい。
【図面の簡単な説明】
【００２９】
【図１】レイヤ違反の回避に関係する例示的実施形態を示すブロック図である。
【図２】暗号化されたトンネルに関係する例示的実施形態を示すブロック図である。
【図３】入れ子のトンネルに関係する例示的実施形態を示すブロック図である。
【発明を実施するための形態】
【００３０】
図１を参照すると、パケットベースのネットワーク内で複数のノード１−４を通じてＭＰＬＳ  ＬＳＰ（マルチプロトコルラベルスイッチング−ラベルスイッチパス）によって実現されたトンネル５が示されている。
【００３１】
トンネル５のエンドノードは、トンネルヘッドエンドノード１およびトンネルテールエンドノード４である。ノード１および４の両方は、ＬＥＲ（ラベルエッジルータ）タイプである。
【００３２】
トンネルの中間ノード２−３は、ＬＳＲ（ラベルスイッチングルータ）タイプである。トンネル５は、中間ノードを１つも含まなくても、中間ノードを１つ含んでも、または複数の中間ノードを含んでもよい。
【００３３】
トンネル５のノード１−４はすべて、従来のＴＣ機能を含む。
【００３４】
一実施形態により、かつＴＣ展開の状況において、ＰＴＰイベントメッセージ６の処理は、以下を含む：
−  変更なく、かつそのオリジナルデータ経路１１内でＰＴＰイベントメッセージ６を転送する（つまり、データトラフィックに続いて、オリジナルデータ経路１１内に同期信号を維持する）、が、特殊なマークをタグとして付ける。
−  中間ノード（ＴＣ）２−３によって読み取り変更できる方法で新しいメッセージ８を生成する。かつ
−  全単射に、転送されたＰＴＰイベントメッセージ６に、生成されたメッセージ８を関連させる。
【００３５】
一実施形態では、ＰＴＰイベントメッセージ６は、専用のＣｏＳ（クラスオブサービス）値のタグが付けられる。したがって、トンネル中間ノード２−３は、そこにタグが付けられた専用のＣｏＳ値に基づいてＰＴＰイベントメッセージ６を認識する。ＣｏＳ値は、ＭＰＬＳラベルの３ビットのＥＸＰフィールド内で伝えることができる（ＩＥＴＦ  ＲＦＣ３０３２を参照）。
【００３６】
あるいは、ＰＴＰイベントメッセージ６には、メッセージタイプフラグ、またはメッセージ識別子、もしく特定の専用ＭＰＬＳラベルのタグを付けることができる。
【００３７】
一実施形態では、生成されたメッセージは、トンネル５の境界内でのみ有効なトンネルフォローアップメッセージ（ＴＦＭ）８である。ＴＦＭ８は、ＰＴＰＶ２標準のフォローアップメッセージにいくぶん類似しているが、ＴＦＭ８は、その関連するＰＴＰイベントメッセージ６（同期メッセージとも呼ばれる）と同じデータ経路１１に従わないという点が異なる。言い換えると、ＴＦＭ８は、その対応するＰＴＰイベントメッセージ６と同じトンネル５で伝達されない。ＴＦＭ８は、トンネル５ノードを含む経路９でルーティングされる。
【００３８】
ＴＦＭ８の他の態様によると、レイヤ分離の原理を破ることなくトンネル５の中間ノード２−３が、そのＣＦ（補正フィールド）を変更できるように、それは伝えられるか、またはカプセル化される。そのため、たとえば、ＴＦＭ８は、「変更された」ＯＡＭ（運用、管理、および保守）ＬＳＰ  ｔｒａｃｅｒｏｕｔｅメッセージ内で伝えられるため、ＴＦＭ８のＣＦは、各中間ノード２−３で、すなわち横断された各ＬＳＲによって各ホップで変更することができる（あるいは、標準的なｔｒａｃｅｒｏｕｔｅ手順で、それ自身のＩＰシステムアドレスを通信するのと同じ方法で、横断された各ＬＳＲは、関連するイベントメッセージ滞留時間を通信することができる）。ここで、ｔｒａｃｅｒｏｕｔｅ手順は、中間ノードを処理するために存続時間（ＴＴＬ）の期限を使用するためレイヤ違反はないことを言及する価値がある（たとえば、ＩＰ  ｔｒａｃｅｒｏｕｔｅ、およびＯＡＭ  ＬＳＰ  ｔｒａｃｅｒｏｕｔｅなど）。
【００３９】
ＴＦＭ８は、複数の追加的なＴＬＶ（タイプ−長さ−値の構造）を含む。以下に例を挙げる。
−  関連するイベントメッセージ６の署名を含むイベントメッセージ署名７  ＴＬＶ（ＥＭＳ−ＴＬＶ）。ＥＭＳ−ＴＬＶは、ＴＦＭ８をその関連するイベントメッセージ６に一義的かつ一意に結合することに可能にする。
−  関連するイベントメッセージ６のタイプを示すイベントメッセージタイプＴＬＶ（ＥＭＴ−ＴＬＶ）（たとえば、Ｓｙｎｃ、Ｄｅｌａｙ＿Ｒｅｑ、Ｄｅｌａｙ＿Ｒｅｓ）。
−  中間ノード（つまりＴＣ）２−３がトンネル５によって取られたのと同じ経路に従ってＴＦＭ８をルーティングすることを可能にするトンネルルーティング情報ＴＬＶ（ＴＲＩ−ＴＬＶ）。限定を目的としない例として、ＴＲＩ−ＴＬＶは、ＧＲＥトンネルの場合はトンネル５  ＩＰ宛先アドレス、またはＭＰＬＳトンネルの場合は明示ルートオブジェクト（ＥＲＯ：Ｅｘｐｌｉｃｉｔ  Ｒｏｕｔｅ  Ｏｂｊｅｃｔ）を含むことができる。
−  多重レベルのカプセル化／トンネルへのＴＦＭ概念の展開を可能にするトンネルレベルＴＬＶ（ＴＬ−ＴＬＶ）。ＴＬ−ＴＬＶは、イベントメッセージ６を伝達するトンネルに関連するカプセル化のレベルを示す。このトンネルレベルは、各トンネルエンドノードでオペレータによって提供できる構成パラメータである。
【００４０】
イベントメッセージ署名７は、たとえば以下を使用して、複数の方法によりイベントメッセージ６から取得することができる。
−  カプセル化されたイベントメッセージ６のハッシュ関数（たとえば、ＭＤ５またはＳＨＡ−２）、
−  中間のＬＳＲ２−３に機能詮索（ｆｅａｔｕｒｅ  ｓｎｏｏｐｉｎｇ）のための手段が提供されている、またはＰＴＰイベントメッセージ６のコンテンツが暗号化されていない場合、イベントメッセージ６シーケンス番号、またはより一般的には、ＰＴＰイベントメッセージ６の少なくとも顕著な特徴の全単射関数（たとえば、同期シーケンス番号、および同期シーケンス番号＋タイプ）。
【００４１】
好ましい実施形態では、イベントメッセージ署名７は、カプセル化されたＰＴＰイベントメッセージ６全体のハッシュ関数である。
【００４２】
図１関して、および開示された実施形態によると、トンネル５内のＴＣ展開は、以下のステップを含む：
−  トンネルヘッドエンドノード１で、入力ＰＴＰイベントメッセージ６からイベントメッセージ署名７を生成するステップ（図１の矢印６７）、
−  変更なく、入力ＰＴＰイベントメッセージ６を転送するステップ、
−  ＥＭＳ−ＴＬＶ内でイベントメッセージ署名７を含むＴＦＭ８を生成するステップ（図１の矢印７８）、
−  付加的な方法で、トンネルノードを横断するＰＴＰイベントメッセージの滞留時間を用いてＴＦＭ８の補正フィールド（ＣＦ）を更新するステップ、
−  ｔｒａｃｅｒｏｕｔｅ  ９、好ましくは「変更された」ＯＡＭ  ＬＳＰ  ｔｒａｃｅｒｏｕｔｅ  ９で、生成されたＴＦＭ８を伝えるステップ。
−  トンネルテールエンドノード４で、ＴＦＭ８メッセージは、横断したネットワークノードに組み込まれている異なる透過クロックにわたる累積滞留時間を含む標準的なフォローアップメッセージ１０に変換される。これは、ここで関連するイベントメッセージと同じデータ経路に後に従う。あるいは、ＴＦＭ８  ＣＦ内での累積滞留時間は、関連するイベントメッセージのＣＦにコピーすることができる。
【００４３】
図２に示された一実施形態では、特に、暗号化する状況におけるＴＣ展開を目標として、暗号化されたトンネル２５（たとえばＩＰＳｅｃトンネル２５）は、トンネルヘッドエンドノード２１の出力ポートと、トンネルテールエンドノード２４の入力ポートとの間で作成される。暗号化されたトンネル２５は、中間ノード２２−２３を通る、ＰＴＰイベントメッセージ２６を含む、すべてのデータフローをカプセル化する。
【００４４】
トンネル中間ノード２２−２３は、そこにタグが付けられた弁別的なマークに基づいて、カプセル化されたＰＴＰイベントメッセージ２６を認識する。一実施形態では、ＰＴＰイベントメッセージ２６は、ＩＰＳｅｃヘッダ内のＤＳＣＰ（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ  Ｓｅｒｖｉｃｅｓ  ＣｏｄｅＰｏｉｎｔ）フィールド内で伝えられる専用のＣｏＳ値のタグを付けられる。
【００４５】
図２を参照すると、暗号化されたトンネル２５内のＴＣ展開は以下のステップを含む：
−  その入力ポートのレベルでトンネルヘッドエンドノード２１によって、ＩＰＳｅｃトンネル２５へと入力のＰＴＰイベントメッセージ２６をカプセル化するステップ、
−  たとえば、ハッシュ関数を使用して、カプセル化／暗号化されたＰＴＰイベントメッセージ２６から、イベントメッセージ署名２７を生成し（図２の矢印２６７）、トンネルヘッドエンドノード２１の出力ポートへとカプセル化／暗号化されたＰＴＰイベントメッセージ２６を転送するステップ、
−  トンネルヘッドエンドノード２１によって、カプセル化／暗号化されたＰＴＴイベントメッセージ２６に基づいてＴＦＭ２８を生成し、そこから生成されたイベントメッセージ署名２７を含むステップ（図２の矢印２７８）、
−  トンネル中間ノード２２−２３に向けて生成されたＴＦＭ２８を伝送するステップ（カプセル化されたＰＴＰイベントメッセージ２６およびＴＦＭ２８の両方は、ここでは、ネットワークの安全でない部分を横断する）、
−  カプセル化されたＰＴＰイベントメッセージ２６、次にＴＦＭ２８の受信時に（受信順序は反対でもよい）、トンネル中間ノード２２で、このノード２２によって以下のアクションが実行される：
・ＩＰＳｅｃヘッダで専用のＣｏＳ値に基づいてカプセル化されたＰＴＰイベントメッセージ２６を検出する、
・関連するイベントメッセージ署名２７を生成する、
・イベントメッセージ２６滞留時間を測定する、
・専用メモリエントリに、そのように生成されたイベントメッセージ署名２７およびそのように測定された滞留時間を格納する（事前に、妥当性タイマーの開始を扱い、タイマーの期限切れによって、メモリエントリの消去がトリガーされる）、
・ＴＦＭ８  ＥＭＳ−ＴＬＶのコンテンツのおかげで、イベントメッセージ署名２７に基づいて、上記のカプセル化されたＰＴＰイベントメッセージ２６に関連するＴＦＭ２８を受信および識別する、
・そのように測定された滞留時間を用いて、識別されたＴＦＭ２８補正フィールドを更新する、
・ＩＰＳｅｃトンネル２５と同じ経路に従って次のノードに向けてＴＦＭ２８を転送するためにＴＲＩ−ＴＬＶを読み取る、
−  トンネル中間ノード２２によって実行されるのと同じ方法で、横断された各トンネル中間ノード２３で上記のステップを実行するステップ、
−  トンネルテールエンドノード２４でカプセル化されたＰＴＰイベントメッセージ２６およびその関連するＴＦＭ２８の両方の受信時に、以下のアクションがこの後のノード２４によって実行される：
・トンネルテールエンドノード２４入力ポートで、ＩＰＳｅｃトンネル２５からＰＴＰイベントメッセージ２６をカプセル化解除する、
・ＰＴＰイベントメッセージ２６滞留時間を記録する、
・トンネルテールエンドノード２４の出力ポートにカプセル化解除されたＰＴＰイベントメッセージ２６を送信する、
・ＴＦＭ２８のコンテンツを使用して、標準的なフォローアップメッセージ２０（従来のＴＣ規格によるツーステップモード）を生成し、特に、後のメッセージの補正フィールド（ＣＦ）に、そのように記録された累積滞留時間を追加し、かつ新しいフォローアップメッセージ２０補正フィールドに合計値を書き込み、
・ここで、関連するイベントメッセージ２６の１つと同じデータ経路に従って、トンネルテールエンドノード２４の出力ポートにフォローアップメッセージ２０を送信する。
【００４６】
上記の実施形態のように、ＩＰＳｅｃトンネル２５内の生成されたＴＦＭ２８は、以下に例を挙げるように、２つ以上のＴＬＶを含むことができる：
−  カプセル化されたＰＴＰイベントメッセージ２６から生成された署名２７を含むＥＭＳ−ＴＬＶ。これは、トンネル中間ノード２２−２３が、ＰＴＰイベントメッセージ２６にＴＦＭ２８を一義的に関連させることを可能にする。後のメッセージは、ＩＰＳｅｃトンネル２５内で暗号化されるため、そのコンテンツ（たとえばシーケンス番号）は、トンネル中間ノード２２−２３によって読み取ることができないことに注意されたい。
−  関連するＰＴＰイベントメッセージ２６のタイプを示すＥＭＴ−ＴＬＶ（たとえば、Ｓｙｎｃ、Ｄｅｌａｙ＿Ｒｅｑ、Ｄｅｌａｙ＿Ｒｅｓｐ）。これにより、Ｓｙｎｃメッセージ以外のイベントメッセージに概念を生成することが可能になる。
−  安全な方法でＴＦＭ２８を伝達することを目的としたＴＲＩ−ＴＬＶ（データは、ネットワークの安全でない部分を横断するかもしれないことが強調されるべきである）。リンクバイリンク基準で利用可能かつ専用のトランスポートチャネル（たとえば、イーサネットの場合、スロープロトコルチャネル）を利用することを決定することができる。この場合、ＴＲＩ−ＴＬＶは、たとえば、ＩＰＳｅｃトンネル宛先アドレスを含むことができるため、ＴＦＭ２８は、各トンネル中間ノード２３−２４でルーティングすることができ、ＩＰＳｅｃトンネル２５と同じ経路に従うことができる。
−  トンネルレベルを示すＴＬ−ＴＬＶ。図２に示すケースでは、この例では単一のレベルのカプセル化しかないため、トンネルレベルは１に設定される。
【００４７】
トンネル中間ノード２２−２３またはトンネルテールエンドノード２４は、関連するＰＴＰイベントメッセージ２６の前にＴＦＭ２８を受信することができる。この場合、このトンネルノード２２−２４は、その関連するＰＴＰイベントメッセージ２６の受信を待機している間にＴＦＭ２８をバッファリングする。妥当性タイマーが開始され、このタイマーの期限切れによって、ＴＦＭ２８のバッファからの消去がトリガーされる。
【００４８】
図３に示す他の実施形態では、ＴＦＭメカニズムは、多重レベルのトンネル／カプセル化の場合に使用される。このケースは、ＴＬ−ＴＬＶの有用性を概説している。
【００４９】
実際に、ＴＬ−ＴＬＶは、ＴＦＭに関連するレベルを示すために使用される。トンネルレベルは、オペレータが手作業で構成できるが、自動的に管理することもできる（たとえば、トンネル入口エンドノードで自動的に上昇し、トンネル出口エンドノードで低下する）。
【００５０】
たとえば、レベル１トンネルは、ＧＲＥトンネルでもよく、レベル２トンネルは、ＩＰＳｅｃトンネルでもよい（中央セグメント（ノード３２−ノード３３）は、安全でないと考えられる）。この場合、カプセル化されたＰＴＰイベントメッセージのレベル１署名（つまりノード１）は、メッセージのシーケンス番号でもよく、（ノード３２の）レベル２署名は、暗号化されたＰＴＰイベントメッセージ３６のハッシュ関数でもよい。
【００５１】
図３を参照すると、ＴＦＭ３８は、
−  カプセル化されたＰＴＰイベントメッセージ３６から取得した第１のイベントメッセージ署名３７をそこに含むトンネル３５（レベル１）のトンネルヘッドエンドノード３１によって生成される。
−  次に、暗号化された（つまりＩＰＳｅｃ暗号化）ＰＴＰイベントメッセージ３６に基づいてトンネル４５（レベル２）の（トンネル３５内のトンネル中間ノードでもある）トンネルヘッドエンドノード３２によって生成された第２のイベントメッセージ署名４０を含むように変更される。
−  レベル２イベントメッセージ署名４０を取り除き、レベル１トンネル３５に関するレベル１イベントメッセージ署名３７を保持しながらレベル２トンネル４５を終了する。
−  トンネル４５のトンネルテールエンドノードの出力ポートから、イベントメッセージ署名３７だけを用いてトンネル３５の残りのノードを横断する。
【００５２】
図３に示すように、レベル２イベントメッセージ署名４０は、レベル１イベントメッセージ署名３７に連結される。あるいは、以前のイベントメッセージ署名４０は、ＴＦＭサイズを減らすために、後のイベントメッセージ署名３７を置き換えることができる。
【００５３】
これらの教示は、２つを超える入れ子のトンネルに拡張することができ、ＰＴＰ偶数メッセージ（ｅｖｅｎ  ｍｅｓｓａｇｅ）は、連続するカプセル化／カプセル化解除を経ることができることを当業者なら理解すべきである。
【００５４】
上記のトンネルノード内に組み込まれたＴＣには、ＴＦＭの生成および扱いのために必要な手段が提供される。そのような手段は、以下を含むことができる。
−  ＴＦＭを生成するための手段、
−  たとえば、ハッシュ関数を使用してイベントメッセージ署名を生成するための手段。
【００５５】
本明細書に記述した方法およびシステムは、エンドツーエンドでも、ピアツーピアでも、ＴＣのタイプに依存しないことに注意されたい。
【００５６】
ここで、本明細書に記述された実施形態は、ＰＴＰｖ２に限定されないことを言及することに注目すべきである。これらの教示は、任意の他の同期プロトコル、またはＴＣを使用するＰＴＰの任意の他のバージョンにも関係することを当業者は理解されるだろう。よって、上記の「ＰＴＰイベントメッセージ」という表現は、「同期イベントメッセージ」、「タイミングメッセージ」、またはより一般的に「同期メッセージ」によって代用することができる。
【図１】
0005717868.tif 000002
【図２】
0005717868.tif 000003
【図３】
0005717868.tif 000004