(57)【要約】パケット・スイッチ・ネットワークにおいて多セグメント擬似回線の接続性を検証する方法であって、（ａ）第１プロバイダ端デバイスから第２プロバイダ端デバイスへ、第１プロバイダ端デバイスと第２プロバイダ端デバイスとの間にある、多セグメント擬似回線の第１セグメントに対してエコー要求メッセージを送信するステップと、（ｂ）当該エコー要求メッセージに応答して第２プロバイダ端デバイスからエコー応答メッセージを受信するステップとを含み、当該エコー応答メッセージは、第１セグメントの接続性を確認し、多セグメント擬似回線において第２プロバイダ端デバイスと第３プロバイダ端デバイスとの間に第２セグメントが存在するか否かを示し、第２セグメントが存在する場合、第２セグメントに関する情報を含む、接続性検証方法。
2010507312.tif 000002
【特許請求の範囲】
【請求項１】
パケット・スイッチ・ネットワークにおいて多セグメント擬似回線の接続性を検証する接続性検証方法であって、
（ａ）第１プロバイダ端デバイスから第２プロバイダ端デバイスへ、当該第１プロバイダ端デバイスと当該第２プロバイダ端デバイスとの間にある、当該多セグメント擬似回線の第１セグメントに対してエコー要求メッセージを送信するステップと、
（ｂ）当該エコー要求メッセージに応答して当該第２プロバイダ端デバイスからエコー応答メッセージを受信するステップと、を含み、当該エコー応答メッセージは、当該第１セグメントの接続性を確認し、当該多セグメント擬似回線において当該第２プロバイダ端デバイスと第３プロバイダ端デバイスとの間に第２セグメントが存在するか否かを示し、第２セグメントが存在する場合、当該第２セグメントに関する情報を含む、接続性検証方法。
【請求項２】
第２セグメントが存在する場合、（ｃ）当該第１プロバイダ端デバイスから当該第３プロバイダ端デバイスへ第２エコー要求メッセージを送信するステップと、（ｄ）当該第２エコー要求メッセージに応答して当該第３プロバイダ端デバイスから第２エコー応答メッセージを受信するステップとを更に含み、当該第２エコー要求メッセージは、当該第２セグメントの接続性を確認し、当該多セグメント擬似回線において当該第３プロバイダ端デバイスと第４プロバイダ端デバイスとの間に第３セグメントが存在するか否かを示し、第３セグメントが存在する場合、第３セグメントに関する情報を含む、請求項１に記載の接続性検証方法。
【請求項３】
当該第１プロバイダ端デバイスが当該第１セグメントに関する情報を有している、請求項２に記載の接続性検証方法。
【請求項４】
当該エコー要求メッセージが当該第１セグメントに関する情報を有している、請求項３に記載の接続性検証方法。
【請求項５】
当該第２エコー要求メッセージが当該第２セグメントに関する情報を有している、請求項４に記載の接続性検証方法。
【請求項６】
当該パケット・スイッチ・ネットワークがマルチプロトコル・ラベル・スイッチング（「ＭＰＬＳ」）ネットワークである、請求項５に記載の接続性検証方法。
【請求項７】
当該第１および第２セグメントに関する情報が擬似回線転送等価クラス（「ＦＥＣ」）用のタイプ長値（「ＴＬＶ」）を含んでいる、請求項６に記載の接続性検証方法。
【請求項８】
当該多セグメント擬似回線において当該第２プロバイダ端デバイスと当該第３プロバイダ端デバイスとの間に第２セグメントが存在するか否かを示すステップが、当該第２セグメントに関する情報を含んでいる当該エコー応答メッセージと、第１および第２のリターンコードとの少なくとも一つにより実行可能であって、当該第１リターンコードは第２セグメントが存在することを示し、当該第２リターンコードは第２セグメントが存在しないことを示す、請求項６に記載の接続性検証方法。
【請求項９】
当該パケット・スイッチ・ネットワークが第１および第２のパケット・スイッチ・ネットワークを含んでいて、当該第１および第２セグメントが各々当該第１および第２のパケット・スイッチ・ネットワークに存在し、当該第１および第２のパケット・スイッチ・ネットワークが第１および第２のサービス・プロバイダにより制御される、請求項２に記載の接続性検証方法。
【請求項１０】
当該第２プロバイダ端デバイスが第ｋプロバイダ端デバイスであり、当該第３プロバイダ端デバイスが第（ｋ＋１）プロバイダ端デバイスであり、当該第１セグメントが当該第１プロバイダ端デバイスと当該第ｋプロバイダ端デバイスとの間にある、当該多セグメント擬似回線のｎ個のセグメントの第（ｋ−１）セグメントであり、当該第２セグメントが当該第ｋプロバイダ端デバイスと当該第（ｋ＋１）プロバイダ端デバイスとの間にある、当該多セグメント擬似回線のｎ個のセグメントの第ｋセグメントであって、ｋおよびｎは整数、ｋはｎ以下であり、更にｋ＝３からｎまでステップ（ａ）および（ｂ）を繰り返す、請求項１に記載の接続性検証方法。
【請求項１１】
パケット・スイッチ・ネットワークにおいて多セグメント擬似回線の接続性を検証するシステムであって、
メモリおよび当該ネットワークへのインターフェースに接続されたプロセッサと、
当該メモリ内にあって当該プロセッサにより実行されるモジュールと、を含み、当該モジュールは、
（ａ）第１プロバイダ端デバイスから第２プロバイダ端デバイスへ、当該第１プロバイダ端デバイスと当該第２プロバイダ端デバイスとの間にある、当該多セグメント擬似回線の第１セグメントに対してエコー要求メッセージを送信するモジュールと、
（ｂ）当該エコー要求メッセージに応答して当該第２プロバイダ端デバイスからエコー応答メッセージを受信するモジュールとを含み、当該エコー応答メッセージは、当該第１セグメントの接続性を確認し、当該多セグメント擬似回線において当該第２プロバイダ端デバイスと第３プロバイダ端デバイスとの間に第２セグメントが存在するか否かを示し、第２セグメントが存在する場合、当該第２セグメントに関する情報を含む、接続性検証システム。
【請求項１２】
第２セグメントが存在する場合、（ｃ）当該第１プロバイダ端デバイスから当該第３プロバイダ端デバイスへ第２エコー要求メッセージを送信し、（ｄ）当該第２エコー要求メッセージに応答して当該第３プロバイダ端デバイスから第２エコー応答メッセージを受信するための１個以上のモジュールを更に含み、当該第２エコー要求メッセージが、当該第２セグメントの接続性を確認し、当該多セグメント擬似回線において当該第３プロバイダ端デバイスと第４プロバイダ端デバイスとの間に第３セグメントが存在するか否かを示し、第３セグメントが存在する場合、第３セグメントに関する情報を含む、請求項１１に記載の接続性検証システム。
【請求項１３】
当該第１プロバイダ端デバイスが当該第１セグメントに関する情報を有している、請求項１２に記載の接続性検証システム。
【請求項１４】
当該エコー要求メッセージが当該第１セグメントに関する情報を有している、請求項１３に記載の接続性検証システム。
【請求項１５】
当該第２エコー要求メッセージが当該第２セグメントに関する情報を有している、請求項１４に記載の接続性検証システム。
【請求項１６】
当該パケット・スイッチ・ネットワークがマルチプロトコル・ラベル・スイッチング（「ＭＰＬＳ」）ネットワークである、請求項１５に記載の接続性検証システム。
【請求項１７】
当該第１および第２セグメントに関する情報が擬似回線転送等価クラス（「ＦＥＣ」）用のタイプ長値（「ＴＬＶ」）を含んでいる、請求項１６に記載の接続性検証システム。
【請求項１８】
当該多セグメント擬似回線において当該第２プロバイダ端デバイスと当該第３プロバイダ端デバイスとの間に第２セグメントが存在するか否かを示すステップが、当該第２セグメントに関する情報を含んでいる当該エコー応答メッセージと、第１および第２のリターンコードとの少なくとも一つにより実行可能であって、当該第１リターンコードは第２セグメントが存在することを示し、当該第２リターンコードは第２セグメントが存在しないことを示す、請求項１６に記載の接続性検証システム。
【請求項１９】
当該パケット・スイッチ・ネットワークが第１および第２のパケット・スイッチ・ネットワークを含んでいて、当該第１および第２セグメントが各々当該第１および第２のパケット・スイッチ・ネットワークに存在し、当該第１および第２のパケット・スイッチ・ネットワークが第１および第２のサービス・プロバイダにより制御される、請求項１２に記載の接続性検証システム。
【請求項２０】
当該第２プロバイダ端デバイスが第ｋプロバイダ端デバイスであり、当該第３プロバイダ端デバイスが第（ｋ＋１）プロバイダ端デバイスであり、当該第１セグメントが当該第１プロバイダ端デバイスと当該第ｋプロバイダ端デバイスとの間にある、当該多セグメント擬似回線のｎ個のセグメントの第（ｋ−１）セグメントであり、当該第２セグメントが当該第ｋプロバイダ端デバイスと当該第（ｋ＋１）プロバイダ端デバイスとの間にある、当該多セグメント擬似回線のｎ個のセグメントの第ｋセグメントであって、ｋおよびｎは整数、ｋはｎ以下であり、更にｋ＝３からｎまでステップ（ａ）および（ｂ）を繰り返す、請求項１１に記載の接続性検証システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク管理及びサービス・プロバイディングの分野に関する。より詳細には、パケット・スイッチ・ネットワークにおける多セグメント擬似回線用の、接続性検証方法及び接続性検証システムに関する。
【背景技術】
【０００２】
マルチプロトコル・ラベル・スイッチング（ＭＰＬＳ）は、ネットワーク（たとえば、パケット・スイッチ・ネットワーク）を通してネットワーク・パケットをどのように転送するかを記述する、ショート・ラベルをネットワーク・パケットに割り当てる、ネットワーク・トラフィック・パターンを処理するメカニズムを提供する。ＭＰＬＳネットワークにおいて、ノード、スイッチ又はルータは、一般的にラベル・スイッチング・ルータ（ＬＳＲ）として知られており、ＭＰＬＳネットワーク端部（入り口又は出口）におけるＬＳＲは、一般的にラベル・エッジ・ルータ（ＬＥＲ）として知られている。
【０００３】
一般的に、無接続ネットワーク層プロトコル（たとえば、インターネット・プロトコル「ＩＰ」）のデータ・フレームは、送信元ノードから目的ノードまで、ネットワークを通して隣接ノードに移動しながら移動する。各ノードは、そのパケットに対して、独立した転送決定を行う。すなわち、各ノードは、パケットを次にどこに転送するかを定めるように、データ・フレームのヘッダーを分析する。転送決定は、各ノードに存在し、該ノードで実行されるネットワーク層ルーチング・アルゴリズムによって生成される転送テーブルによって行われる。したがって、各ルータは、パケットのヘッダー及びルーチング・アルゴリズムの実行の結果の分析に基づいて、データ・フレーム用の次のホップを独立に選択する。
【０００４】
フレーム・ヘッダーは、単に、経路に沿った次のホップを選択することのみに必要な情報よりもかなり多くの情報を含む。したがって、次のホップを選択することは、二つの機能の組み合わせと考えることができる。第１の機能は、ありうるパケットの全体を、転送等価クラス（ＦＥＣ）のセットへ分割する。従来のＩＰ転送において、ＦＥＣは、サブネットＩＰアドレス・プリフィックスである。したがって、ルータのルーチング・テーブルに何らかのアドレス・プリフィックス「Ｘ」が存在し、２個のパケットのうちの各パケットの目的アドレスに対して、「Ｘ」が「最長の一致」である場合には、特定のノードは、２個のパケットが、同一のＦＥＣ内にあると考える。第２の機能は、各ＦＥＣを次のホップにマップすることである。転送決定に関する限り、同じＦＥＣにマップされた異なるパケットは、区別が付かない。特定のＦＥＣに属し、特定のノードから異動するする全てのデータ・フレームは、同じ経路を経て進む（あるいは、ある種の多パスのルーチングが使用される場合は、全てのデータ・フレームは、ＦＥＣに関連した経路のセットのうちの一つを経て進む）。データ・フレームがネットワークを移動するにしたがって、各ホップは、順番にパケットを再調査し、次のホップを定めるように、該パケットをＦＥＣに対応付ける。
【０００５】
ＭＰＬＳにおいて、特定のデータ・フレームの特定のＦＥＣへの割り当ては、データ・フレームがネットワークに入るときに一回だけ行われる。パケットが割り当てられるＦＥＣは、「ラベル」として知られる、短い固定長の値としてコード化される。パケットが次のホップへ転送されるとき、ラベルはパケットとともに送られる。すなわち、パケットは転送される前に、「ラベル付け」される。後続のホップにおいて、データ・フレームのネットワーク層ヘッダーのさらなる分析は行われない。フレーム・ヘッダーのラベルは、ノードにおけるテーブルへのインデクスとして使用される。テーブルエントリは、次のホップ及び新たなラベルを指定する。フレーム・ヘッダーにおける古いラベルは、新たなラベルと置き換えられ、データ・フレームは、次のホップへ転送される。このように、ＭＰＬＳの転送方法において、一旦パケットがＦＥＣに割り当てられると、後続のルータによって、さらなるネットワーク層ヘッダー分析は行われない。全ての転送は、ラベルによって駆動される。
【０００６】
参考として、ＭＰＬＳヘッダーは、３２ビット・ラベルのスタックから構成される。ＭＰＬＳ「ラベル」は、２０ビット長であり、ＬＳＲに対してローカルに重要な識別子である。「実験的ビット」フィールドは、３ビット長であり、データ・フレームに適用されるサービスの質（ＱｏＳ）を定めるのに使用される。「スタック」フィールドは、１ビットを占め、ヘッダー内に他のラベル・スタック・エントリがあるかどうか定めるのに使用される。生存時間（「ＴＴＬ」）フィールドは、８ビット長であり、ＩＰヘッダーで実行されるＴＴＬヘッダーと同様であり、フレームが何回のホップを経ることができるかを定めるのに使用される。ＩＰフレームは、ＭＰＬＳネットワークの入口端において、ＭＰＬＳヘッダーに規格化（encapsulate）される。出口端において、ＩＰフレームは、ＭＰＬＳヘッダーを取り除くことによって回復される。
【０００７】
ラベル分配プロトコル（「ＬＤＰ」）は、ＭＰＬＳネットワークを通してトラフィックを転送するのに使用されるＭＰＬＳデータベースを構築し、維持するのに使用される。ＬＤＰは、本明細書に参考用に組み入れるInternet Engineering Task Force(“IETF”) documents request for comment(“RFC”) 3036, “LDP Specification”, January 2001 及び RFC 3037, “LDP Applicability”, January 2001に規定されている。上述のように、ＭＰＬＳは、パケットを転送するための方法であり、パケットの次のホップを定めるのに、ラベルと呼ばれる、パケットに運ばれ、短く、固定長の値を使用する。ＭＰＬＳの基本的な考えは、２個のＬＳＲは、その間またはそこを通してトラフィックを転送するのに使用されるラベルの意味について一致している必要があることである。この共通の理解は、１個のＬＳＲが、それが作成したラベルの拘束を、他方に知らせる一連の手順（たとえば、ＬＤＰ）を使用して達成される。このように、ＬＤＰは、一方のＬＳＲが、ＬＳＲ間またはＬＳＲを通して、トラフィックを転送するのに使用されるラベルの意味を他方のＬＳＲに知らせる、一連の手順である。
【０００８】
さて、擬似回線（pseudowire又は「ＰＷ」）は、パケット・スイッチ・ネットワーク（「ＰＳＷ」）上の特定のシステム用のサービスのエミュレーションである。特定のシステム用のサービスは、非同期転送モード（ＡＴＭ）、フレーム・リレー、イーサネット、低速時分割多重（「ＴＤＭ」）または同期光ネットワーク／同期デジタル階層（「ＳＯＮＥＴ／ＳＤＨ」）であり、ＰＳＮは、ＭＰＬＳ、ＩＰ又はネットワークに基づくレイヤー２トンネル・プロトコル（「Ｌ２ＴＰ」）であってもよい。ＰＷは、特定のシステム用のサービスを実行する「透明な回線」の動作をエミュレーションする。換言すれば、ＰＷは、ポイント・ツー・ポイント・リンクをエミュレーションし、選択されたサービスの共有されていないリンクまたは回線として、そのユーザによって知覚される単一のサービスを提供する。
【０００９】
一般的に、ＰＷは、二つの付属回線（「ＡＣ」）を接続する、二つのプロバイダ端（「ＰＥ」）の間の接続である。ＡＣは、フレーム・リレー・データリンク接続識別子（「ＤＬＣＩ」）、ＡＴＭ仮想経路識別子／仮想チャネル識別子（「ＶＰＩ／ＶＣＩ」）、イーサネット・ポート、仮想ＬＡＮ（「ＶＬＡＮ」）、高レベルデータリンク制御（「ＨＤＬＣ」）リンク、物理インターフェースにおけるポイント・ツー・ポイント・プロトコル（「ＰＰＰ」）、Ｌ２ＴＰトンネルからのＰＰＰセッション、ＭＰＬＳラベル・スイッチ経路（ＬＳＰ）などでありうる。ＰＷを設定する間に、二つのＰＥは、後で他方端から来るパケットをどのように処理するかを知ることができるように、構成され、またはエミュレーションされるサービスについての情報を自動的に交換する。二つのＰＥ間においてＰＷが設定された後に、ＡＣから一方のＰＥによって受けたられたフレームは、規格化（encapsulate）され、ＰＷを経由して遠隔のＰＥへ送られ、そこで特定のシステム用のフレームが再構築され、他方のＡＣを経由して転送される。ＰＥデバイスは、たとえば、ＭＰＬＳスイッチ、ＬＥＲまたはＬＳＲであってもよい。
【００１０】
ＬＤＰへのＰＷの拡張は、参考として組み入れられる、ＩＥＴＦドキュメント、RFC 4447, “Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP), April 2006  に記載されている。RFC 4447によれば、（フレーム・リレー、ＡＴＭ及びイーサネットなどの）レイヤー２サービスは、レイヤー２プロトコル・データ・ユニット（ＰＤＵ）を規格化（encapsulate）し、ＰＷを経由して伝送することによってＭＰＬＳバックボーン上でエミュレーションすることができる。換言すれば、ＰＷは、ＭＰＬＳネットワークを横断して異なったタイプのトラフィックを搬送するように生成され、ＰＷは、それが輸送するレイヤー２サービスの透明性を提供するＭＰＬＳ上のポイント・ツー・ポイント・ネットワーク接続である。
【００１１】
RFC 4447は、ＬＤＰへの拡張を利用して、ＰＷを確立し維持するためのプロトコルを規定している。RFC 4447は、新しいタイプ長値（「ＴＬＶ」）、ＦＥＣエレメント、パラメータ及び、ＬＤＰがＰＷを識別し、ＰＷの属性を信号で伝えることができるようにする、ＬＤＰ用のコードを定める。RFC 4447は、どのようにＰＷ端点が、ＬＤＰにおけるこれらのＴＬＶを使用して、ＰＷに対するデマルチプレクサ・フィールド値（たとえば、上述のＭＰＬＳラベル）を取り決めるか、及び、どのようにＰＷ端点が、遠隔の端点にその取り決めを知らせるかを規定する。RFC 4447は、また、ＰＷ状態の変化を報告する方法、必要な場合にＰＷについての追加情報を伝える方法及びその取り決めを解除する方法を規定する。
【００１２】
以下のRFC 4447シナリオを考察する。入口ＬＳＲ  ＰＥ1出口ＬＳＲ  ＰＥ２へ、介在するＭＰＬＳ動作可能ネットワークを横断して、レイヤー２ＰＤＵを伝達することが所望されていると仮定する。ＰＥ1からＰＥ２へのＭＰＬＳトンネルがあると想定する。すなわち、ＰＥ1は、パケットを「ＭＰＬＳトンネル・ヘッダー」内に規格化しその結果を隣接端の一つに送ることによって、パケットがＰＥ２へ配送されるようにすることができる。ＭＰＬＳトンネルは、ＭＰＬＳラベル・スイッチ経路（「ＬＳＲ」）である。このように、ＭＰＬＳトンネル規格化を行うことは、ＭＰＬＳラベルを付けることである。また、単一のＭＰＬＳトンネルを通して多数のＰＷを搬送することができると仮定する。このように、個々のＰＷに対してネットワークの状態を維持することは全く必要ではない。ＭＰＬＳトンネルがポイント・ツー・ポイントであることは前提とされていない。ＰＷは、ポイント・ツー・ポイントであるが、ＭＰＬＳトンネルは、マルチポイント・ツー・ポイントであってよい。ＰＥ２が、受け取られるパケットがそこを通して伝送されるＭＰＬＳトンネルを定めることができることも前提とされていない。（たとえば、ＭＰＬＳトンネルがＬＳＰであり、最後から２番目のホップ・ポッピングが使用される場合に、パケットがＰＥ２に到着したときに、パケットはそのトンネルを識別する情報を含まない。）ＰＥ２がＰＷ上でパケットを受け取ったときに、ＰＷ上で実際にそのパケットが受け取られたことを判断することができる必要があり、そのパケットを特定のＰＷと関連付けることができる必要がある。ＰＥ２は、ＰＷデマルチプレクサ・フィールドとして機能するＭＰＬＳラベルを調べることによりこれを行うことができる。このラベルは、「ＰＷラベル」と呼んでもよい。ＰＥ1がレイヤー２ＰＤＵをＰＥ２へ送るときに、パケットにＰＷラベルを加えることによってＭＰＬSパケットを生成し、このようにしてラベル・スタックの第１のエントリを生成する。ＰＳＮトンネルがＭＰＬＳＬＳＰである場合には、ＰＥ1は、ラベル・スタックの第２のエントリとして他のラベル（すなわち、トンネル・ラベル）をそのパケットに付ける。ＰＷラベルは、ＭＰＬＳパケットがＰＥ２へ到達するまで、見ることはできない。そのパケットのＰＥ２の処置は、ＰＷラベルに基づいている。
【００１３】
このように、ＰＷは、二つのラベルのスタックによって識別される、ＭＰＬＳネットワークを横断するポイント・ツー・ポイント接続である。第１のラベルは、「外側」ラベルと呼ばれる。「外側」ラベルは、外側トンネル又は「外側」ラベル外側ＬＳＰを表す。この外トンネル内において、「内側」接続（すなわち、ＰＷ）は、マルチプレクス化されてもよい。これらの内側接続の各々は、通常「内側」ラベルと呼ばれる、第２のラベルによって識別される。外側トンネルは、通常、ＬＤＰ又はリソース保存プロトコル・トラフィック拡張（「ＲＳＶＰ−ＴＥ」）などのプロトコルを使用して、信号を送られる。内側接続は、下流非要求モード（「ＤＵ」）におけるＬＤＰ（すなわち、「ＬＤＰ−ＤＵ」）を使用して、信号を送られる。ＬＤＰ−ＤＵモードが機能しているときに、ＬＳＲ(たとえば、ＭＰＬＳスイッチ)は、明示的に要求していない他のＬＳＲに、ＭＰＬＳラベルの取り決めを分配することができる。このラベル管理動作は、RFC 3036に記載されている。このように、ＰＷ拡張を伴う、ＭＰＬＳＬＤＰ−ＤＵ信号化プロトコルは、ＭＰＬＳネットワークを横断する双方向のＰＷを確立するのにこのように使用される。
【００１４】
上述のＰＷは、単一セグメント疑似回線（「ＳＳ−ＰＷ」）が二つの終端ＰＥ（「Ｔ−ＰＥ」）の間で直接に設定された際には、信号セグメント疑似回線と呼称してもよい。このように、Ｔ−ＰＥは、顧客対応付属回路（「ＡＣ」）がＰＷ転送装置に接続されるＰＥである。ＰＷは、多数のセグメントを有してもよい。そのようなＰＷは、多セグメント擬似回線（「ＭＳ−ＰＷ」）と呼称してもよい。このように、ＭＳ−ＰＷは、単一のポイント・ツー・ポイントＰＷとして動作し機能する二つ以上の接続しているＰＷセグメントの、静的なまたは動的に構成されたセットである。定義によるＭＳ−ＰＷの各端は、Ｔ−ＰＥにおいて終端する。すなわち、Ｔ−ＰＥは、ＭＳ−ＰＷの最初および最後のセグメントに存在する。ＭＳ−ＰＷのＴＰＥ間に位置するＰＥは、スイッチＰＥ（「Ｓ−ＰＥ」）と呼称される。Ｓ−ＰＥは、ＭＳ−ＰＷにおける先行するＰＷセグメント及び後続するＰＷセグメントの制御プレーンおよびデータプレーンをスイッチングすることができるＰＥである。Ｓ−ＰＥは、ＭＳ−ＰＷの先行するＰＷセグメント及び後続するＰＷセグメントを輸送するＰＳＮトンネルを終端する。Ｓ−ＰＥは、ＭＳ−ＰＷ用のＰＷスイッチング・ポイントである。ＰＷスイッチング・ポイントは、同一のＭＳ−ＰＷに対して、Ｓ−ＰＥ及びＴ−ＰＥではありえない。ＰＷスイッチング・ポイントは、他のＰＷスイッチング・ポイント及びＴ−ＰＥと、ＰＷセグメントを設定し管理するのに必要なプロトコルを実行する。
【００１５】
さて、サービス・プロバイダー（「ＳＰ」）がＰＷサービスを展開する際に、特に、ネットワークのＰＳＮ部分に対する故障検出及び診断機構が重要である。具体的に、エミュレーションされるサービスに対して、ポイント・ツー・ポイントに故障検出および診断を供給する能力が、ＳＰに対する重要な考察である。仮想回路接続確認（「ＶＣＣＶ」）という用語は、ＳＳ−ＰＷと関連する制御チャネルを呼称し、その制御チャネル上で使用される接続性確認などの、対応する動作および管理機能を呼称するのに使用されている。一般的に、ＶＣＣＶは、ＳＳ−ＰＷの接続性を確認するように、ＰＥの間で交換されるメッセージのセットを定める。ＶＣＣＶパケットが、ＳＳ−ＰＷデータ・フローと同じ経路に従うのを確実にするように、ＶＣＣＶパケットは、通常、同じＳＳ−ＰＷデマルチプレクサで規格化され、同じＰＳＮトンネルで輸送される。たとえば、ＭＰＬＳが使用中のＰＳＮであれば、同じラベル・シム・ヘッダー（及びラベル・スタック）が通常組み込まれる。ＶＣＣＶは、ＳＳ−ＰＷに対する故障検出及び／又は診断ツールとして使用することができる。オペレータは、事前の接続性確認用に、周期的にＶＣＣＶを呼び出すことができ、あるいは、特にそのために又は必要に応じて、マニュアルの接続性確認の手段として呼び出すことができる。ＶＣＣＶを呼び出すときに、オペレータは、種々の接続性チェック（ＣＣ）タイプの一つと種々の接続性確認（ＣＶ）タイプの一つとの組み合わせを駆動させる。これらは、ラベル・スイッチ経路（「ＬＳＰ」）、ＬＳＴＰ又はインターネット制御メッセージ・プロトコル（「ＩＣＰＭ」）ｐｉｎｇモードを含み、基礎をなすＰＳＮに応じて適用される。参考として、「ｐｉｎｇ」という用語は、ネットワークにおける接続性をテストするのに使用される動作をさす。ｐｉｎｇ動作は、あるアドレスへエコー要求パケットを送り、その後応答を待つ。ｐｉｎｇ動作の結果は、ＳＰが、経路・ホストの信頼性、経路上の遅れ、及びホストに到達することが可能であるかどうか、ホストが機能しているかを評価するのに役立つ。たとえば、ｐｉｎｇ動作は、要求された宛先（もし、存在すれば）に到達するのに、ＩＣＭＰトラフィックに基づいてもよいし、公共のルーチング・テーブルを使用してもよい。参考として、参考用に組み入れられる、IETF  RFC 4379,”Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failure”, February 2006は、ＭＰＬＳラベル・スイッチ経路（ＬＳＰ」）に対する故障検出および隔離のための、ＭＰＬＳ「エコー要求」及び「エコー応答」を記載している。
【００１６】
しかし、新しいＭＳ−ＰＷサービスに対して、簡単に故障のポイントの正確な位置を示し、ＭＳ−ＰＷの端間接続性を確認する効果的な方法は現在のところ存在しない。特に、現在のＭＳ−ＰＷネットワークの一つの問題は、ＭＳ−ＰＷの入口ノード（すなわち、Ｔ−ＰＥ）の制御プレーンは、ＶＣＣＶエコー要求（又はｐｉｎｇ）をフォーマットし、ＭＳ−ＰＷの次のセグメントにおけるエコー要求を首尾よく確認できるように備えるために、ＭＳ−ＰＷの次のセグメントに関する必要な情報にアクセスできない。ネットワークのオペレータは、ＭＳ−ＰＷの各々個別のセグメントに対するＶＣＣＶｐｉｎｇを、一度に一つずつマニュアルで実行することができるが、このことは時間がかかり、ユーザ・フレンドリーではなく、オペレータが、ＭＳ−ＰＷ全体の各々のセグメントの詳細な知識を有することを要求する。さらに、そのようなマニュアル手法は、オペレータがＭＳ−ＰＷの全てのセグメントにアクセスできなければ（たとえば、ＭＳ−ＰＷが異なるＳＰのＰＳＮに及ばなければ）、可能ではないかもしれない。
【発明の概要】
【発明が解決しようとする課題】
【００１７】
故に、パケット・スイッチ・ネットワークにおける多セグメント擬似回線接続の接続性を確認する、改良された方法及びシステムに対するニーズがある。したがって、上記及び他の欠点に、少なくとも部分的に対処する解決策が所望されている。
【課題を解決するための手段】
【００１８】
本発明の一態様によれば、パケット・スイッチ・ネットワークにおいて多セグメント擬似回線の接続性を検証する方法を提供し、本方法は、（ａ）第１プロバイダ端デバイスから第２プロバイダ端デバイスへ、第１プロバイダ端デバイスと第２プロバイダ端デバイスとの間にある、多セグメント擬似回線の第１セグメントに対してエコー要求メッセージを送信するステップと、（ｂ）当該エコー要求メッセージに応答して第２プロバイダ端デバイスからエコー応答メッセージを受信するステップとを含んでいて、当該エコー応答メッセージは、第１セグメントの接続性を確認し、多セグメント擬似回線において第２プロバイダ端デバイスと第３プロバイダ端デバイスとの間に第２セグメントが存在するか否かを示し、第２セグメントが存在する場合、第２セグメントに関する情報を含んでいる。
【００１９】
本方法は更に、第２セグメントが存在する場合、（ｃ）第１プロバイダ端デバイスから第３プロバイダ端デバイスへ第２エコー要求メッセージを送信するステップと、（ｄ）第２エコー要求メッセージに応答して第３プロバイダ端デバイスから第２エコー応答メッセージを受信するステップとを含んでいて、第２エコー要求メッセージは、第２セグメントの接続性を確認し、多セグメント擬似回線において第３プロバイダ端デバイスと第４プロバイダ端デバイスとの間に第３セグメントが存在するか否かを示し、第３セグメントが存在する場合、第３セグメントに関する情報を含んでいる。第１プロバイダ端デバイスが第１セグメントに関する情報を含んでいてよい。エコー要求メッセージが第１セグメントに関する情報を含んでいてよい。第２エコー要求メッセージが第２セグメントに関する情報を含んでいてよい。パケット・スイッチ・ネットワークがマルチプロトコル・ラベル・スイッチング（「ＭＰＬＳ」）ネットワークであってよい。第１および第２セグメントに関する情報が擬似回線転送等価クラス（「ＦＥＣ」）用のタイプ長値（「ＴＬＶ」）を含んでいてよい。多セグメント擬似回線において第２プロバイダ端デバイスと第３プロバイダ端デバイスとの間に第２セグメントが存在するか否かを示すステップは、第２セグメントに関する情報を含んでいるエコー応答メッセージと、第１および第２のリターンコードとの少なくとも一つにより実行可能であって、第１リターンコードは第２セグメントが存在することを示し、第２リターンコードは第２セグメントが存在しないことを示す。パケット・スイッチ・ネットワークは第１および第２のパケット・スイッチ・ネットワークを含んでいてよく、第１および第２セグメントは各々第１および第２のパケット・スイッチ・ネットワークに存在してよく、その場合第１および第２のパケット・スイッチ・ネットワークは第１および第２のサービス・プロバイダにより制御される。また、第２プロバイダ端デバイスは第ｋプロバイダ端デバイスであり、第３プロバイダ端デバイスは第（ｋ＋１）プロバイダ端デバイスであり、第１セグメントは第１プロバイダ端デバイスと第ｋプロバイダ端デバイスとの間にある、多セグメント擬似回線のｎ個のセグメントの第（ｋ−１）セグメントであり、第２セグメントは第ｋプロバイダ端デバイスと第（ｋ＋１）プロバイダ端デバイスとの間にある、多セグメント擬似回線のｎ個のセグメントの第ｋセグメントであってよく、ｋおよびｎは整数、ｋはｎ以下であり、更にｋ＝３からｎまでステップ（ａ）および（ｂ）を繰り返す。
【００２０】
本発明の更なる態様によれば、データ処理システム（たとえば、ＭＰＬＳルータまたはスイッチ、ネットワーク要素、ネットワーク管理システムその他）等の装置、本システムを適合させる方法、並びに本発明の方法を実施すべくプログラムされた命令が記録されたコンピュータ可読媒体等の製品が提供される。
【００２１】
本発明の実施形態の更なる特徴および利点が添付の図面と合せて以下の詳細説明から明らかになる。
【図面の簡単な説明】
【００２２】
【図１】本発明の実施形態による多セグメント擬似回線を用いる通信ネットワークを示すブロック図である
【図２】本発明の実施形態を実装すべく適合されたデータ処理システムを示すブロック図である。
【図３】本発明の実施形態に従い、パケット・スイッチ・ネットワークにおいて多セグメント擬似回線の接続性を検証するデータ処理システムのメモリ内のモジュールの動作を示す流れ図である。
【発明を実施するための形態】
【００２３】
添付の図面全体を通じて、同一の特徴には同一の参照番号が付与されている点に注意されたい。
【００２４】
以下の説明において、詳細は、発明を理解させるように述べられている。発明をわかりにくくしないように、所定のソフトウェア、回路、構造及び技術は、詳細に記述されず、示されていない場合もある。「データ処理システム」という用語は、本明細書では、本明細書に記載されるネットワーク・エレメント及びネットワーク管理システムを含む、データを処理するためのどのようなマシンをも指す。本発明は、データ処理システムのオペレーティング・システムが、本発明の要請をサポートする機能を供給する限り、どのようなコンピュータ・プログラム言語によっても実現されてもよい。どのような制約も、特定のタイプのオペレーティング・システム又はコンピュータ・プログラム言語の結果であり、本発明の制約ではない。本発明は、ハードウェアによって実現されてもよい。
【００２５】
図１は、本発明の実施形態による、多セグメント擬似回線による通信ネットワーク１００を説明するブロック図である。通信ネットワーク（すなわち、システム）１００は、第１の擬似回線（「ＰＷ」）セグメントＰＷ１を経由して、第１のパケット・スイッチ・ネットワーク（［ＰＳＮ」）ＰＳＮ１上で第２のＰＥデバイスＰＥ２に結合されている第１プロバイダ端（「ＰＥ」）デバイスＰＥ１を含む。さらに、第２のＰＥデバイスＰＥ２は、第３のＰＷセグメントＰＷ３を経由して、第２のＰＳＮネットワークＰＳＮ２上で第３のＰＥデバイスＰＥ３に結合されている。顧客端末（「ＣＥ」）デバイスＣＥ１、ＣＥ２は、それぞれの付属回路（「ＡＣ」）ＡＣ１、ＡＣ２によってそれぞれのＰＥデバイスＰＥ１、ＰＥに結合されている。ＰＳＮネットワークＰＳＮ１、ＰＳＮ２は、ＭＰＬＳネットワーク、ＩＰネットワークなどであってもよい。ＰＥデバイスＰＥ１、ＰＥ２、ＰＥ３は、ＭＰＬＳスイッチ、ノード、エレメント、スイッチ、ルータなどであってもよい。ＰＥデバイスＰＥ１、ＰＥ２、ＰＥ３は、ＣＥデバイスＣＥ１、ＣＥ２を経由してサブスクライバ又はユーザへレイヤー２サービスを供給するように、少なくとも一つのサービス・プロバイダ（「ＳＰ」）によって維持されてもよい。一実施形態によれば、ＰＥデバイスＰＥ１、ＰＥ２、ＰＥ３は、制御または監視目的のためにネットワーク管理システム（「ＮＭＳ」）（図示せず）に結合されてもよい。ＮＭＳは、ＳＰの中央オフィス（「ＣＯ」）又は他の場所に配置してもよい。
【００２６】
このように、ＰＥ１及びＰＥ３は、ＣＥ１及びＣＥ２にＰＷサービスを供給し、終端ＰＥ（「Ｔ−ＰＥ」）Ｔ−ＰＥ１、Ｔ−ＰＥ２と呼称してもよい。これらのＰＥは、異なるＰＳＮドメイン、それぞれ、ＰＳＮ１及びＰＳＮ２に存在する。ＰＳＮトンネルは、ＰＳＮ１を横断してＰＥ１からＰＥ２へ伸びており、第２のＰＳＮトンネルは、ＰＳＮ２を横断してＰＳ２からＰＳ３へ伸びる。ＰＷは、ＰＥ１へ付属したＡＣ  ＡＣ１をＰＥ３へ付属した対応するＡＣ  ＡＣ２へ接続するのに使用される。ＰＳＮ１を横断するトンネル上の各々のＰＷ（すなわち、ＰＷ１、ＰＷ２）は、ＰＥ１及びＰＥ３の間で多セグメント擬似回線（「ＭＳ−ＰＷ」）１１０、１２０を完成するように、ＰＥ２においてＰＳ２を横断するトンネルにおけるＰＷ（すなわち、ＰＷ３、ＰＷ４）へ組み合わされる。ＰＥ２は、ＰＷスイッチ・ポイントであり、ＰＷスイッチ・プロバイダー端（「Ｓ−ＰＥ」）Ｓ−ＰＥと呼称してもよい。ＰＷ１及びＰＷ３は、同じＭＳ−ＰＷ１１０セグメントであり、ＰＷ２及びＰＷ４は、他のＭＳ−ＰＷ１２０セグメントである。同じＭＳ−ＰＷ（たとえば、１１０）のセグメント（たとえば、ＰＷ１及びＰＷ３）は、同じＰＷタイプ又は異なるタイプであってよく、ＰＳＮトンネル（たとえば、ＰＳＮ１及びＰＳＮ２）は、同じ技術又は異なる技術であってもよい。Ｓ−ＰＥは、ＰＷ識別子（たとえば、ＭＰＬＳＰＷの場合のＰＷラベル）に基づいて、ＭＳ−ＰＷ（たとえば、１１０）を一つのセグメントから他のセグメントへ切り替える。このように、図１は、スイッチ・ポイントＰＥ２（Ｓ−ＰＥ）を通してＰＥ１からＰＥ３（ともにＴ−ＰＥ）への接続性を供給するＭＳ−ＰＷ１１０を示す。
【００２７】
図２は、本発明の実施形態を実現するように構成されたデータ処理システム３００を説明するブロック図である。データ処理システム３００は、ＰＥデバイスＰＥ１、ＰＥ２、ＰＥ３、ＣＥデバイスＣＥ１、ＣＥ２、又はＮＭＳとしての動作に適している。データ処理システム３００は、中央処理システム（「ＣＰＵ」）３２０、メモリ３３０及びインターフェース・デバイス３５０を含み、オプションとして入力デバイス３１０及びディスプレイ３４０を含んでもよい。ＣＰＵ３２０は、専用の共同プロセッサ及びメモリ・デバイスを含んでもよい。ＣＰＵ３２０は、システム３００の一般的な管理のための（図示しない）オペレーティング・システムを格納するメモリ３３０に機能的に結合される。メモリ３３０は、ＲＡＭ、ＲＯＭ、ディスク・デバイスおよびデータベースを含んでもよい。メモリ３３０は、当業者に理解されるように、典型的には階層構造に構成された外部大容量記憶及び内部メモリを含む。インターフェース・デバイス３５０は、一つまたは複数のネットワーク接続を含んでもよい。データ処理システム３００は、ネットワーク１００、インターフェース・デバイス３５０を経由したＰＳＮ１、ＰＳＮ２上の他のデータ処理システム（ＰＥ２に対するＰＥ１及びＰＥ２）と通信するように構成されている。入力デバイス３１０は、キーボード、マウス、トラックボールまたは同様のデバイスを含んでもよい。さらに、ディスプレイ３４０は、コンピュータ・スクリーン、端末デバイス、又はプリンタ又はプロッタなどのハードコピー生成出力デバイスを含んでもよい。システム３００のＣＰＵ３２０は、ユーザの指令または問い合わせを受け取り、これらの指令または問い合わせの結果をディスプレイ３４０上でユーザに表示するための、一つまたは複数の入力デバイス３１０に通常結合される。指令及び問い合わせを、ネットワーク接続を経由して受け取り、結果を、ネットワーク接続を経由して伝達してもよい。データ処理システム３００は、ネットワーク・トポロジー及びプログラム情報を格納し、アクセスするためのデータベース・システム３３２を含んでもよい。データベース・システム３３２は、データベース管理システム（「ＤＢＭＳ」）及びデータベースを含み、データ処理システム３００のメモリ３３０に格納されてもよい。データ処理システム３００は、その中に、実行されたときに本明細書に記載された方法を実施させる命令シーケンスを表すデータを格納している。もちろん、データ処理システム３００は、その説明が本発明の理解に必要ではない、その他のソフトウェアおよびハードウェアを含んでもよい。
【００２８】
オプションとして、ユーザは、オプションのグラフィカル・ユーザ・インターフェース（「ＧＵＩ」）３８０を使用してデータ処理システム３００及びそのハードウェアおよびソフトウェアモジュールと情報を交換してもよい。ＧＵＩ３８０は、データ処理システム３００の監視、管理及びアクセス用に使用してもよい。ＧＵＩは、一般的なオペレーティング・システムによってサポートされ、マウス３１０などの入力又はユーザ指示デバイスを使用して、アイコンとして知られる絵のような表現を選択し、又はメニューからアイテムを選択することによって、ユーザが、命令を選択し、アプリケーション・プログラムを実行し、コンピュータ・ファイルを管理し、他の機能を実施することができるようにする、ディスプレイ・フォーマットを供給する。一般的に、ＧＵＩは、ユーザへ情報を運びユーザから命令を受け取るのに使用され、アイコン、ツールバー、ドロップ・ダウン・メニュー、テキスト、ダイアログ・ボックス、ボタンなどの、種々のＧＵＩオブジェクトまたはコントロールを含む。ユーザは、通常、ポインタ又はカーソル３９０をオブジェクト３９１上に位置させ、そのオブジェクト３９１を「クリックする」ために入力又は指示デバイス（たとえば、マウス）３１０を使用することによって、ディスプレイ３４０に示されたＧＵＩ３８０と情報を交換する。
【００２９】
通常、ＧＵＩベースのシステムは、ディスプレイ３４０に現れる「ウィンドウ」内で、アプリケーション、システム状態及び他の情報をユーザへ提供する。ウィンドウ３９２は、ディスプレイ３４０においてほほ矩形の領域であり、ユーザは、その中でアプリケーション又はドキュメントを眺める。そのようなウィンドウ３９２は、開き、閉じ、全画面に表示し、アイコンへ縮小し、サイズを増加または減少し、ディスプレイ３４０の異なる領域へ移動させることができる。他のウィンドウ内のウィンドウ、他のウィンドウに重なるウィンドウ，表示領域に重ならないように配置されたウィンドウなど多くのウィンドウを同時に表示することができる。
【００３０】
このように、データ処理システム３００は、データ処理システム３００に本発明の実施形態を実装させるべくコンピュータ実行可能なようにプログラムされた命令を含んでいる。プログラムされた命令は、データ処理システム３００のメモリ３３０に常駐可能な１個以上のハードウェアモジュールまたはソフトウェアモジュール３３１に実装することができる。あるいは、プログラムされた命令は、プログラムされた命令をデータ処理システム３００のメモリ３３０へ移送すべく使用可能なコンピュータ可読媒体（ＣＤディスクまたはフロッピーディスク等）に実装することができる。あるいは、プログラムされた命令は、プログラムされた命令の販売元または供給元によりネットワーク１００へアップロードされたコンピュータ可読信号または信号を搭載した媒体に埋め込むことができ、エンドユーザまたは潜在的な買い手によりこの信号または信号搭載媒体をネットワーク１００からデータ処理システム３００へインターフェース（たとえば、３５０）を介してダウンロードすることができる。
【００３１】
上述のように、新規ＭＳ−ＰＷサービスについて、故障箇所を容易に指摘して、ＭＳ−ＰＷ（たとえば、ＰＷ１およびＰＷ３からなる１１０）のエンド・ツー・エンドの接続性を検証する効果的な方法は今のところ無い。特に、現行ＭＳ−ＰＷネットワーク（たとえば、１００）に関する問題の一つは、ＶＣＣＶエコー要求（またはｐｉｎｇ）をフォーマット化して、ＭＳ−ＰＷ１１０の次のセグメントＰＷ３でエコー要求を首尾よく検証できるようにするために、ＭＳ−ＰＷ１１０の入り口ノード（たとえば、ＰＷ１の場合Ｔ−ＰＥ１）の制御プレーンからＭＳ−ＰＷ１１０の次のセグメント（たとえば、ＰＷ３）に関する必要情報にアクセスできないことである。ネットワーク１００のオペレータはＭＳ−ＰＷ１１０の個々のセグメントＰＷ１、ＰＷ３に対してＶＣＣＶｐｉｎｇを手操作で一度に１回ずつ実行できるものの、これには時間を要し、使い勝手が悪く、ＭＳ−ＰＷ１１０全体の各セグメントＰＷ１、ＰＷ３に関する詳細な知識をオペレータが有している必要がある。また、このような手操作によるアプローチは、オペレータがＭＳ−ＰＷ１１０の全てのセグメントＰＷ１、ＰＷ３へアクセスできない限り可能ですらない（たとえば、ＭＳ−ＰＷ１１０が異なる複数のＳＰの複数のＰＳＮであるＰＳＮ１、ＰＳＮ２にまたがる場合）。
【００３２】
本発明の一実施形態によれば、ＭＳ−ＰＷ１１０のエンド・ツー・エンド接続性およびデータ経路をユーザ（たとえば、ＳＰオペレータ）が検証できるようにする自動化されたＶＣＣＶトレース方法が提供される。故障があった場合、ＭＳ−ＰＷ１１０内のどのセグメントＰＷ１、ＰＷ３が故障の原因であるかをユーザが単一の動作コマンドを介して容易に特定できる。
【００３３】
一実施形態によれば、ＭＳ−ＰＷ（たとえば、１１０）の各セグメント（たとえば、ＰＷ１）の各対象ノードまたは遠端（たとえば、Ｓ−ＰＥ）が、ＶＣＣＶエコー要求（たとえば、Ｔ−ＰＥ１からの）に対してリターンコード８（すなわちスタックの深さでラベル・スイッチされた）、ＦＥＣ１２８サブＴＬＶ、および次のセグメント（たとえば、ＰＷ３）に関する他の任意の必要な情報を含んでいるエコー応答を返す。最初エコー要求の発信元ノード（たとえば、Ｔ−ＰＥ１）は、ＦＥＣ１２８サブＴＬＶ（たとえば、Ｓ−ＰＥからの）と共にエコーを受信したならば、受信したＦＥＣ１２８サブＴＬＶと共に次のＶＣＣＶエコー要求を構成して、これをＭＳ−ＰＷ１１０の次のセグメント（たとえば、ＰＷ３）に送信する。これらのステップを、ＭＳ−ＰＷ１１０の他のセグメント（図示せず）について繰り返す。ＭＳ−ＰＷ１１０の宛先ノード（たとえば、Ｔ−ＰＥ２）または最後のセグメントＰＷ３の遠端は、ＶＣＣＶエコー要求に対しリターンコード３（すなわち、スタックの深さにおける出口ルータ）を示すエコー応答を返すが、ＦＥＣ１２８サブＴＬＶは返さない。これは、ＭＳ−ＰＷ１１０の終端であって、本方法が終了したことを発信元ノード（たとえば、Ｔ−ＰＥ１）に知らせる。好都合なことに、本方法はRFC 4379に記載されているＬＳＰｐｉｎｇ環境に準拠している。また、本方法はＭＳ−ＰＷを介してＶＣＣＶエコーパケットを転送するために採用されたデータ経路方式にかかわらず機能する。
【００３４】
このように、一実施形態によれば、ＶＣＣＶトレースは、以下の方法ステップによる単一動作コマンドにより、ＰＥｌ（またはＴ−ＰＥｌ）から生じたＭＳ−ＰＷ１１０に対して実行することができる。
【００３５】
第１に、ＰＥ１は検証のため、第１ＰＷセグメントＰＷ１（すなわち、ＰＥ１とＰＥ２の間にある）に関するＰＷ情報を含んでいるＦＥＣ１２８サブＴＬＶと共にＶＣＣＶエコー要求をＰＥ２（またはＳ−ＰＥ）に送信する。ＴＬＶがRFC 4379のセクション７．２において定義されている点に注意されたい。用語「ＦＥＣ１２８サブＴＬＶ」は、RFC 4379のセクション７．２に記載の通り「ＴＬＶタイプ１、サブタイプ９、数値フィールド「ＦＥＣ１２８」擬似回線（廃止予定）」または「ＴＬＶタイプ１、サブタイプ１０、数値フィールド「ＦＥＣ１２８」擬似回線」を指す。（RFC 4379のセクション７．２に記載の通り、「ＴＬＶタイプ１、サブタイプ１１、数値フィールド「ＦＥＣ１２９」擬似回線」もまた使用できる点に注意されたい。）参考までに、データ通信プロトコル内では、オプションの情報をプロトコル内部のタイプ長値（「ＴＬＶ」）要素として符号化することができる。タイプおよび長さフィールドは固定サイズ（たとえば、１−４バイト）であり、数値フィールドは可変サイズである。これらのフィールドは以下のように用いられる。すなわち、タイプはメッセージの当該部分が表わす種類のフィールドを示す数値コード、長さは数値フィールドのサイズ（通常はバイト）、および値はメッセージの当該部分のデータを含むバイトの可変サイズの集合である。また参考までに、転送等価クラス（「ＦＥＣ」）は、同一の方法で転送することができる、すなわち同一のＭＰＬＳラベルに紐付けることができる類似または同一の特徴を有するパケットの組を記述するためにＭＰＬＳにおいて用いられる用語である。一実施形態によれば、内部ラベルのＴＴＬは、エコー要求対象Ｓ−ＰＥを制御する。一実施形態によれば、データ経路を介したＶＣＣＶエコーパケットの配信は、本明細書に引用している２００６年６月発行のＩＥＴＦドラフト文書  ”VCCV Extensions for Segmented Pseudo-Wire”（draft-hart-pwe３-segmented-pw-vccv-00.txt）に記載された内側ＶｃラベルＴＴＬの利用、あるいは、本明細書に引用している２００６年３月発行のＩＥＴＦドラフト文書”SegmentedPseudo-Wire”（draft-ietf-pwe3-segmented-pw-02.txt）に記載されたマルチホップＴＴＬ（「ＭＨ−ＴＴＬ」）の利用等の方法を採用してもよい。
【００３６】
第２に、ＰＥ２はＦＥＣ１２８サブＴＬＶを有するエコー要求を検証する。これは第１および第２セグメントＰＷ１、ＰＷ３間のスイッチ位置（すなわちＳ−ＰＥ）であるため、第２セグメントＰＷ３（すなわち、ＰＥ２とＰＥ３との間）向けにリターンコード８を有するエコー応答およびＦＥＣ１２８サブＴＬＶを生成してＰＥ１へ返信する。リターンコードはRFC 4379のセクション３．１において定義されている点に注意されたい。値８のリターンコードは「スタックの深さ＜ＲＳＣ＞でラベル・スイッチされた」ことを意味する一方、値３のリターンコードはRFC 4379のセクション３．１に記載の通り「応答ルータはスタックの深さ＜ＲＳＣ＞におけるＦＥＣの出口である」ことを意味する。上記の「ＲＳＣ」が、処理が終了したラベル・スタック内の位置を含む戻りサブコードを表わす点に注意されたい。ＲＳＣがゼロの場合、ラベルは処理されなかった。さもなければ、パケットは深さＲＳＣでラベル・スイッチされているであろう。
【００３７】
第３に、ＰＥ１はＰＥ２から応答のＦＥＣ１２８サブＴＬＶに基づいて、第２のＶＣＣＶエコー要求を生成する。ＰＥ１は次いで、この第２のＶＣＣＶエコー要求をＰＥ３へ送信する。
【００３８】
第４に、ＰＥ３はＰＥ１からのＦＥＣ１２８サブＴＬＶを有するエコー要求を検証する。ＰＥ３はＭＳ−ＰＷ１１０の宛先ノードまたは出口ノード（すなわちＴ−ＰＥ２）であるため、ＦＥＣ１２８サブＴＬＶは含んでいないがリターンコード３（すなわち出口ルータ）を有するエコー応答をＰＥ１へ返す。
【００３９】
第５に、ＰＥ１はＰＥ３からエコー応答を受信する。ＰＥ１は、エコー応答が次のＦＥＣ１２８サブＴＬＶを含んでおらず、且つそのリターンコードが３であるため、ＰＥ３がＭＳ−ＰＷ１１０の宛先であることを認識している。次いで本方法は終了する。
【００４０】
上記においてＦＥＣ１２８サブＴＬＶだけがスイッチされるものと仮定されている点に注意されたい。しかし、ＶＣＣＶトレース方法はまた、他のＴＬＶまたは対象ＦＥＣサブＴＬＶ（たとえば、ＦＥＣ１２９、ＬＤＰプレフィックス、ＲＳＶＰＬＳＰ等）も使用できる。
【００４１】
一実施形態によれば、本方法はデータ処理システム３００のＧＵＩ３８０を介して（たとえば、対応するコマンドを入力、対応するアイコン３９１をクリック、メニューから対応する部材を選択する等により）ユーザにより起動することができ、ユーザに対して本方法の結果をデータ処理システムのディスプレイ画面３４０上に表示することができる。別の実施形態によれば、本方法を自動的に起動することができる。
【００４２】
一実施形態によれば、本発明はＭＳ−ＰＷにおけるＶＣＣＶエコーメッセージの制御プレーン処理に対応している。制御プレーンにおける課題は、パケットの宛先である下流ＰＷセグメントの対象ＦＥＣ１２８ＰＷサブＴＬＶ（ＦＥＣ１２８）等の必要な情報を有するＶＣＣＶエコー要求パケットを生成できることである。上述のように、これはＭＳ−ＰＷが異なる複数のＳＰおよび自律システムにまたがっている場合がある点でより困難な場合がある。たとえば、図１を参照するに、Ｔ−ＰＥ１はＰＷ１のＦＥＣ１２８を構成するために必要な情報を有しているが、ＶＣＣＶエコー要求がＴ−ＰＥ２を宛先としている場合はＰＷ３のＦＥＣ１２８を構成するために必要な情報を有していない。この問題は以下に記述する方法により解決することができる。
【００４３】
ＶＣＣＶエコー要求の受信に関して、ＶＣＣＶエコー要求を受信したならば、Ｓ−ＰＥ（またはＭＳ−ＰＷ１１０の各セグメントＰＷ１、ＰＷ３の対象ノード）が要求を検証して、当該要求に対して、次の下流のセグメントＰＷ３のＦＥＣ１２８およびＳ−ＰＥであってＭＳ−ＰＷ１１０出口ルータではないことを示すリターンコード８（すなわち、スタックの深さでラベル・スイッチされた）で構成されるエコー応答を返す。当該ノードがＭＳ−ＰＷ１１０のＴ−ＰＥ２または出口ノードである場合、エコー要求に対して、リターンコード３（すなわち出口ルータ）を有し、且つＦＥＣ１２８を含んでいないエコー応答を返す。
【００４４】
ＶＣＣＶエコー応答の受信に関して、エコー応答を受信するノード（たとえば、Ｔ−ＰＥ１）が当該エコー要求に応答して実行する動作は、「ｐｉｎｇ」または「トレース」等の現行動作モードに依存する。「ｐｉｎｇ」モードにおいて、ノードＴ−ＰＥ１は、エコー応答における対象ＦＥＣ１２８を無視して、ユーザ（たとえば、オペレータ）に対しリターンコードだけを報告すること選択することができる。しかし、「トレース」モードでは、ノードＴ−ＰＥ１は、後続するＶＣＣＶエコー要求を生成してエコー応答において受信した情報（下流ＦＥＣ１２８等）と共に次の下流セグメントＰＷ３に送信する。
【００４５】
ＶＣＣＶトレース動作に関して、たとえば、図１において、ＶＣＣＶトレースは、１個の動作コマンドによりＴ−ＰＥ１から発せられたＭＳ−ＰＷ（たとえば、１１０）上で実行することができる。これは以下の方法ステップにより実現することができる。第１に、Ｔ−ＰＥ１は検証のため、第１セグメント（すなわちＴ−ＰＥ１とＳ−ＰＥとの間のＰＷ１）の擬似回線情報を含むＦＥＣ１２８を有するＶＣＣＶエコー要求をＳ−ＰＥに送信する。第２に、Ｓ−ＰＥはＦＥＣ１２８を有するエコー要求を検証する。これは第１および第２セグメントＰＷ１、ＰＷ３間のスイッチ位置であるため、リターンコード８を有するエコー応答を生成して、これに第２セグメント（すなわちＳ−ＰＥとＴ−ＰＥ２との間のＰＷ３）のＦＥＣ１２８を含め、当該エコー応答をＴ−ＰＥ１に送信する。第３に、Ｔ−ＰＥ１は、Ｓ−ＰＥからエコー応答内のＦＥＣ１２８に基づいて第２のＶＣＣＶエコー要求を生成する。Ｔ−ＰＥ１は、次エコー要求をＴ−ＰＥ２に送信する。一実施形態によれば、ＶＣＣＶエコー要求パケットは、Ｓ−ＰＥデータ経路でスイッチされて、制御プレーンが一切関与することなく次の下流セグメントＰＷ３へ転送される。第４に、Ｔ−ＰＥ２は、ＰＷ３のＦＥＣ１２８を有するエコー要求をＴ−ＰＥ１から受信してこれを検証する。Ｔ−ＰＥ２はＭＳ−ＰＷ１１０の宛先ノードまたは出口ノードであるため、リターンコード３（すなわち出口ルータ）を有するがＦＥＣ１２８は含んでいないエコー応答をＴ−ＰＥ１に返す。第５に、Ｔ−ＰＥ１はＴ−ＰＥ２からエコー応答を受信する。エコー応答がＦＥＣ１２８を一切含んでおらず、且つリターンコードが３であるため、Ｔ−ＰＥ１はＴ−ＰＥ２がＭＳ−ＰＷ１１０の宛先であることを知らされる。次いでトレース方法は終了する。先の例ではＦＥＣ１２８サブＴＬＶだけがスイッチされるが、スイッチされた情報もまた他のＴＬＶまたは対象ＦＥＣサブＴＬＶ（たとえば、ＦＥＣ１２９、ＬＤＰプレフィクスまたはＲＳＶＰ  ＬＳＰ）を含み得ることに注意されたい。ＶＣＣＶエコーパケットのフォーマットに関する更なる詳細についてはRFC 4379を参照されたい。
【００４６】
一般に、ＶＣＣＶトレースがエンド・ツー・エンドであるためには、ネットワーク１００内の各Ｓ−ＰＥが上述の方法に準拠している必要がある点に注意されたい。
【００４７】
本発明にはいくつかの利点がある。第１に、ユーザ（たとえば、ＳＰオペレータ）は各ＳＳ−ＰＷ（すなわち各ＰＷセグメント）に関する予備知識が無くても、ＭＳ−ＰＷの制御およびデータ経路を動的に学習および検証することができる。第２に、ＭＳ−ＰＷにおける問題を診断する際に、個々のセグメントを手動でｐｉｎｇするよりも効率的である。第３に、異なる複数のＳＰネットワークにまたがるＭＳ−ＰＷを扱う際の潜在的な困難さを克服する。第４に、ユーザ・フレンドリー且つ使い勝手がよい。第５に、ＭＳ−ＰＷをセグメント毎に辿って、単一の動作コマンドで故障箇所を識別する自動化され方法を提供する。
【００４８】
上述の方法は、流れ図を用いて要約することができる。図３は、本発明の実施形態に従い、パケット・スイッチ・ネットワーク１００内の多セグメント擬似回線１１０の接続性を検証するデータ処理システム３００のメモリ３３０内のモジュール３３１の動作２００を示す流れ図である。
【００４９】
ステップ２０１で動作２００が開始される。
【００５０】
ステップ（ａ）で、エコー要求メッセージが、多セグメント擬似回線１１０において第１プロバイダ端デバイスＰＥ１と第２プロバイダ端デバイスＰＥ２との間にある第１セグメントＰＷ１向けに第１プロバイダ端デバイスＰＥ１から第２プロバイダ端デバイスＰＥ２へ送信される。
【００５１】
ステップ（ｂ）で、エコー要求メッセージに応答してエコー応答メッセージが、第２プロバイダ端デバイスＰＥ２から受信され、当該エコー応答メッセージは、第１セグメントＰＷ１の接続性を確認し、第２プロバイダ端デバイスＰＥ２と第３プロバイダ端デバイスＰＥ３との間に多セグメント擬似回線１１０の第２セグメントＰＷ３が存在するか否かを示し、第２セグメントＰＷ３が存在する場合、第２セグメントＰＷ３に関する情報を含んでいる。
【００５２】
ステップ２０２で動作２００が終了する。
【００５３】
本方法は更に、第２セグメントＰＷ３が存在する場合、（ｃ）第１プロバイダ端デバイスＰＥ１から第３プロバイダ端デバイスＰＥ３へ第２エコー要求メッセージを送信するステップ、および（ｄ）第２エコー要求メッセージに応答して第３プロバイダ端デバイスＰＥ３から第２エコー応答メッセージを受信するステップを含んでいてよく、第２エコー応答メッセージは、第２セグメントＰＷ３の接続性を確認し、第３プロバイダ端デバイスＰＥ３と第４プロバイダ端デバイス（図示せず）との間にある多セグメント擬似回線１１０に第３セグメント（図示せず）が存在するか否かを示し、第３セグメントが存在する場合、第３セグメントに関する情報を含んでいる。第１プロバイダ端デバイスＰＥ１が第１セグメントＰＷ１に関する情報を有していてよい。エコー要求メッセージが第１セグメントＰＷ１に関する情報を含んでいてよい。第２エコー要求メッセージが第２セグメントＰＷ３に関する情報を含んでいてよい。パケット・スイッチ・ネットワーク１００がマルチプロトコル・ラベル・スイッチング（「ＭＰＬＳ」）ネットワークであってよい。第１および第２セグメントＰＷ１、ＰＷ３に関する情報が擬似回線転送等価クラス（「ＦＥＣ」）のタイプ長値（「ＴＬＶ」）を含んでいてよい。第２プロバイダ端デバイスＰＥ２と第３プロバイダ端デバイスＰＥ３との間にある多セグメント擬似回線１１０に第２セグメントＰＷ３が存在するか否かを示すステップは、第２セグメントに関する情報を含むエコー応答メッセージと、第１および第２リターンコードとの少なくとも一つにより実行可能であって、第１リターンコード（たとえば、「８」）は第２セグメントＰＷ３が存在することを示し、第２リターンコード（たとえば、「３」）は第２セグメントＰＷ３が存在しないことを示す。パケット・スイッチ・ネットワーク１００は第１および第２のパケット・スイッチ・ネットワークＰＳＮ１、ＰＳＮ２を含んでいてよく、第１および第２セグメントＰＷ１、ＰＷ３は各々第１および第２のパケット・スイッチ・ネットワークＰＳＮ１、ＰＳＮ２に存在し得ると共に、第１および第２のパケット・スイッチ・ネットワークＰＳＮ１、ＰＳＮ２は各々第１および第２のサービス・プロバイダにより制御される。また、第２プロバイダ端デバイスＰＥ２は第ｋプロバイダ端デバイスであってよく、第３プロバイダ端デバイスＰＥ３は第（ｋ＋１）プロバイダ端デバイスであってよく、第１セグメントＰＷ１は第１プロバイダ端デバイスＰＥ１と第ｋプロバイダ端デバイスとの間にある、多セグメント擬似回線１１０のｎ個のセグメントの第（ｋ−１）セグメントであってよく、第２セグメントＰＷ３は第ｋプロバイダ端デバイスと第（ｋ＋１）プロバイダ端デバイスと間の多セグメント擬似回線１１０のｎ個のセグメントの第ｋセグメントであってよく、ｋおよびｎは整数であってｋはｎ以下であり、更にステップ（ａ）および（ｂ）をｋ＝３からｎまで繰り返す。
【００５４】
本発明の一実施形態によれば、上述の方法はまた、複数のＰＥすなわち、ＰＥ１、ＰＥ２、ＰＥ３、３００に代えて、あるいはこれらと組合せて、ＮＭＳ（図示せず）により実装することができる。
【００５５】
本発明は主に方法として記述してきたが、当業者であればデータ処理システム３００に関して上で述べた装置が、本発明の方法の実行を可能にすべくプログラミング可能であることが理解されよう。更に、データ処理システム３００と合せて使用する製品、たとえば、プログラム命令が記録されている書き込み済み記憶装置その他同様のコンピュータ可読媒体により、データ処理システム３００に本発明の方法の実行を可能にするよう指示できる。そのような装置および製品も本発明の範囲に含まれることを理解されたい。
【００５６】
特に、実行された際に本明細書に記述した方法をデータ処理システム３００により実行させる命令シーケンスは、本発明の一実施形態によるデータ搬送製品に格納することができる。このデータ搬送製品は、データ処理システム３００にロードして実行することができる。また、実行された際に本明細書に記述した方法をデータ処理システム３００により実行させる命令シーケンスは、本発明の一実施形態によるコンピュータソフトウェア製品に格納することができる。このコンピュータソフトウェア製品は、データ処理システム３００にロードして実行することができる。更に、実行された際に本明細書に記述した方法をデータ処理システム３００により実行させる命令シーケンスは、本発明の一実施形態によるコプロセッサまたはメモリを含む集積回路製品（たとえば、ハードウェアモジュール）に格納することができる。この集積回路製品は、データ処理システム３００に組み込むことができる。
【００５７】
上述の本発明の実施形態は、単に例示目的のものである。当業者であればこれらの実施形態に対し各種の細かい変更をなし得るが、その全てが本発明の範囲内にあることが理解されよう。
【図１】
2010507312.tif 000003
【図２】
2010507312.tif 000004
【図３】
2010507312.tif 000005
【国際調査報告】
2010507312.tif 000006
2010507312.tif 000007
2010507312.tif 000008