(57)【特許請求の範囲】
【請求項１】
マルチ・プロトコル・ラベル・スイッチング（ＭＰＬＳ）電気通信網のノードにおける、対応するジェネリック・アソシエイテッド・チャネル・ヘッダ（Ｇ−ＡＣＨ）機能の特定の機能エンドポイントをアドレス指定するための方法であって、
第１のラベルと第２のラベルとを含むラベルスタックを有するＭＰＬＳフレームを受信するステップと、
前記フレームがその終端ノードに届いたかを判定するステップと、
前記フレームがその終端ノードに届いた場合、前記ラベルスタックの中の前記第２のラベルがジェネリック・アソシエイテッド・チャネル・ラベル（ＧＡＬ）に関連するかを判定するために、前記第２のラベルをチェックするステップと、
前記第２のラベルがＧＡＬに関連する場合、接続検証（ＣＶ）、連続性チェック（ＣＣ）または前記フレームの出所の識別が要求される他の機能を実行する際に、前記フレームに対するその後の処理の間の、運用、管理及び保守（ＯＡＭ）機能による使用のために、前記フレームが受信された、終端された接続を特徴づける主要な属性に基づいて構成される前記第１のラベルを含むコンテクスト記述子であって、前記ＯＡＭ機能の特定の機能エンドポイントをアドレス指定するコンテクスト記述子を記憶するステップと、
前記ノードにおけるジェネリック・アソシエイテッド・チャネル・ヘッダ（Ｇ−ＡＣＨ）の処理のために、前記フレームを、取得された前記コンテクスト記述子と共にルーティングするステップと、
を有することを特徴とする方法。
【請求項２】
前記フレームがその端点に届いたかを判定するステップは、前記ラベルスタックの前記第１のラベルをチェックするステップを含む、
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記ラベルスタックの前記第１のラベルをチェックするステップは、前記第１のラベルがポップ操作に関連するかをチェックするステップを含む、
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記フレームがその端点に届いたかを判定するステップは、フレームと共に受信されたタイム・トゥ・ライブ（ＴＴＬ）情報をチェックするステップを含む、
ことを特徴とする請求項１に記載の方法。
【請求項５】
前記コンテクスト記述子を記憶するステップは、前記運用、管理及び保守機能による将来の処理のために、前記第１のラベルを記憶するステップを含む、
ことを特徴とする請求項１から４のいずれか１項に記載の方法。
【請求項６】
前記コンテクスト記述子を記憶するステップは、ラベル空間情報を記憶するステップを含む、
ことを特徴とする請求項５に記載の方法。
【請求項７】
前記コンテクスト記述子を記憶するステップは、前記第２のラベルがチェックされるのに先立って、前記第１のラベルとラベル空間情報とを記憶するステップを含み、
前記第２のラベルがＧＡＬである場合に前記第１のラベルとラベル空間情報とを保持し、
前記第２のラベルがＧＡＬでない場合に前記第１のラベルとラベル空間情報とを削除する、
ことを特徴とする請求項６に記載の方法。
【請求項８】
前記コンテクスト記述子を記憶するステップは、前記第２のラベルをチェックするステップが前記第２のラベルがＧＡＬであると判定した後に、前記第１のラベルと前記ラベル空間情報を記憶するステップを含む、
ことを特徴とする請求項６に記載の方法。
【請求項９】
前記コンテクスト記述子を記憶するステップは、ラベルスタックヒストリを記憶するために、最後に処理されたラベルをメモリに記憶するステップを含む、
ことを特徴とする請求項５から７のいずれか１項に記載の方法。
【請求項１０】
前記第２のラベルをチェックするステップは、受信した前記フレームにおいて設定されている、接続が監視された接続であることを指示する状態ビットに応答して実行される、
ことを特徴とする請求項１から９のいずれか１項に記載の方法。
【請求項１１】
前記コンテクスト記述子は、前記受信されたＭＰＬＳフレームのラベル空間において提供される情報から記憶され、ラベル空間は監視された接続のそれぞれに割り当てられる、
ことを特徴とする請求項１に記載の方法。
【請求項１２】
個々のインカミング・ラベル・マップ（ＩＬＭ）テーブルが、ラベル空間のそれぞれに対して提供される、
ことを特徴とする請求項１１に記載の方法。
【請求項１３】
１つの監視された接続に対するラベル空間は、メンテナンス・エンドポイント（ＭＥＰ）をアドレス指定するのに用いられる、
ことを特徴とする請求項１１または１２に記載の方法。
【請求項１４】
前記コンテクスト記述子は、ネクスト・ホップ・ラベル・フォワーディング・エントリ（ＮＨＬＦＥ）キーを用いて記憶される、
ことを特徴とする請求項１から１３のいずれか１項に記載の方法。
【請求項１５】
運用、管理及び保守（ＯＡＭ）機能に関連するデータを取得するために、受信した前記フレームを逆多重化するステップと、
前記逆多重化されたデータに含まれるルーティング情報に基づいて、前記フレームをメンテナンス・エンドポイントへルーティングするステップと、
記憶した前記コンテクスト記述子を用いて接続性チェックを実行するステップと、
をさらに有する、
ことを特徴とする請求項１から１４のいずれか１項に記載の方法。
【請求項１６】
マルチ・プロトコル・ラベル・スイッチング（ＭＰＬＳ）電気通信網のノードであって、前記ノードは、対応するジェネリック・アソシエイテッド・チャネル・ヘッダ（Ｇ−ＡＣＨ）機能の特定の機能エンドポイントをアドレス指定するように適合され、
第１のラベルと第２のラベルとを含むラベルスタックを有するＭＰＬＳフレームを受信するための受信手段を備え、
前記フレームがその終端ノードに届いたかを判定し、
前記フレームがその終端ノードに届いた場合、前記ラベルスタックの中の前記第２のラベルがジェネリック・アソシエイテッド・チャネル・ラベル（ＧＡＬ）に関連するかを判定するために、前記第２のラベルをチェックし、
前記第２のラベルがＧＡＬに関連する場合、接続検証（ＣＶ）、連続性チェック（ＣＣ）または前記フレームの出所の識別が要求される他の機能を実行する際に、前記フレームに対するその後の処理の間の、運用、管理及び保守（ＯＡＭ）機能による使用のために、前記フレームが受信された、終端された接続を特徴づける主要な属性に基づいて構成される前記第１のラベルを含むコンテクスト記述子であって、前記ＯＡＭ機能の特定の機能エンドポイントをアドレス指定するコンテクスト記述子を記憶し、
ジェネリック・アソシエイテッド・チャネル・ヘッダ（Ｇ−ＡＣＨ）処理のために前記フレームをルーティングする、
ように構成されることを特徴とするノード。
【請求項１７】
前記ノードは、請求項２から１５のいずれか１項による方法を実行するように構成される、
ことを特徴とする、請求項１６に記載のノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電気通信網に関し、特に、しかしながら専らではなく、パケット交換方式の転送網のノードにおけるメンテナンス・ポイントをアドレス指定するための方法及び装置に関する。
【背景技術】
【０００２】
マルチ・プロトコル・ラベル・スイッチング（ＭＰＬＳ）は、あるノードから他のノードへデータパケットを導き、運ぶ、電気通信網における機構である。各データパケットはラベルスタックを含み、それにより、そのパケットの残りの部分を調べる必要なく、転送の決定がなされる。
【０００３】
既存のＭＰＬＳのフォワーディングプレーンに基づいて、マルチ・プロトコル・ラベル・スイッチング転送プレーン（Multi-Protocol Label Switching Transport Plane、ＭＰＬＳ−ＴＰ）は、転送網の要求を満足するフレームワークを提供することを目標としている。１つの重要な分野は、明確な操作、管理及び保守（Operation, Administration and Maintenance、ＯＡＭ）機能セットを有することである。このＯＡＭ機能セットは、インターネット技術タスクフォース（ＩＥＴＦ）で標準化中である。ＯＡＭのフレームワーク及び要求は、発展したＯＡＭソリューションによりサポートされるべき、いくつかの機能（連続性チェック（ＣＣ）、接続性検証（ＣＶ）、管理信号など）を定義する。
【０００４】
ＭＰＬＳ−ＴＰのためのＯＡＭの操作は、必要なＯＡＭの属性（識別子、タイマ、カウンタなど）を、データフロー中に多重化されるいわゆるＯＡＭフレームに符号化するものである。この方法では、ＯＡＭフレーム及びデータフローのフェイトシェアリングが保証され、すなわち、ＯＡＭフレームとデータフローは１つのノードからもう１つへ転送されるときに同一のプロセスを経る。ＯＡＭフレームは、接続の端点に存在するメンテナンス・エンドポイント（ＭＥＰ）により生成され、受信される。
【０００５】
現在、ＭＰＬＳ−ＴＰアーキテクチャは、３つのレイヤ、疑似ワイヤ（ＰＷ）層、ラベル・スイッチド・パス（ＬＳＰ）トンネル（接続）層、及びセクション（データリンク）層からなる。ＭＰＬＳ−ＴＰ  ＯＡＭは、３つの層の全てをサポートするように、サポートされる。
【０００６】
現在、ＯＡＭパラメータを符号化する、いくつかの競合するソリューションが提案されている。しかしながら、これらのソリューションは、ＯＡＭフレームをデータフロー中に多重化する同一の方法に基づいている。その方法は、ＯＡＭフレームと他の制御／管理フレームを運ぶために関連するチャネルを定めている。ＰＷの場合、これらのチャネルは、ジェネリック・アソシエイテッド・チャネル・ヘッダ（Ｇ−ＡＣＨ）のみを用いて、識別され、逆多重化される。ＬＳＰトンネル及びセクションの場合、関連チャネルを表すために付加的なラベルが定義される。そのラベルは、ジェネリック・アソシエーション・チャネル・ラベル（ＧＡＬ）と呼ばれる。退出側（すなわち、あて先側）は、これらのラベルに基づいてＯＡＭフレームを検出し、逆多重化する。
【０００７】
しかしながら、ＯＡＭフレームをＧ−ＡＣＨの中で送信することに依存するこれらのソリューションは、ＭＰＬＳ及びＭＰＬＳ−ＴＰにおいて、以下の問題を有する。ＬＳＰトンネル層及びセクション層の場合、標準のＭＰＬＳデータ転送機構は、データプレーン転送にも使用される識別子を用いて、データプレーンからＭＥＰをアドレス指定するための十分な方法を提供しない。
【０００８】
特定のノードでの標準のＭＰＬＳ転送の挙動は、以下のようになる。スタック中の第１のラベル（トンネルラベル）に基づいて、ノードはネクスト・ホップ・ラベル・フォワーディング・エントリ（ＮＨＬＦＥ）を調べる。このエントリは、そのラベルスタックの処置方法（第１のラベルをポップする、第１のラベルの値を変更する、スタックのトップに新しいラベルをプッシュする、など）を命令する。
【０００９】
ノードが接続の終端処理をする退出ノードである場合、ノードに、スタックからトンネルラベルを除去、すなわちポップするように、そして残りのパケットの検索を実行するように、命令するためにＮＨＬＦＥは符号化される。もし、それ以上のラベルがスタックに存在する場合は、そのスタックの次のラベルに対する第２の独立の探索が実行される。この第２のラベルは、例えば、パケットをローカルノードの制御機能へ渡すべきことを意味する、ＧＡＬである可能性があり、ＧＡＬはフレームから取り除かれる。そして、そのノードの制御機能はフレームを処理し、ＯＡＭパケットを適切なＭＥＰへ送信することができる。
【００１０】
図１は、上述の転送機構で使われてもよいＭＰＬＳパケット構造を示している。ラベルスタックは、例えば、ＬＳＰトンネルラベルである最外部ラベルを含んでもよい。これは、明示的に退出ノードを識別するラベルの形式か、ホップ数に基づいて退出ノードを判定するタイム・トゥ・ライブ（ＴＴＬ）ラベルの形式をとる。Ｇ−ＡＣＨメッセージペイロードは、パケットのペイロード、例えば、ＭＥＰに送信されるべきＯＥＭペイロードを含むのに対し、アソシエイテッド・チャネル・ヘッダは、Ｇ−ＡＣＨ逆多重化プロセスにより処理される情報を含む。
【００１１】
したがって、ＭＰＬＳデータプレーンは、データプレーンの属性（例えばデータプレーンの中のラベル）を用いて、特定のＭＥＰをアドレス指定することは許していないことが十分に理解されるであろう。代わりに、ＯＡＭペイロードを逆多重化し、適切なＭＥＰをアドレス指定するためのＯＡＭペイロードの中の識別子（すなわち、ルーティング情報）を用いることにより、ＭＥＰをアドレス指定するだけかもしれない。
【００１２】
対応するＭＥＰへの逆多重化の後、ＯＡＭペイロードに含まれる識別子を用いて、正しい接続を検証するべきである。これらの識別子はノード又はネットワークレベルにおいて一意的であるが、進入及び退出ノード間に複数の平行する接続が存在する場合は、パケットが受信された接続を識別できず、すなわち、入ってくる接続を識別することができない。さらに、上述のように、トンネルラベル（第１のラベル）も、着信するインタフェースも、ＯＡＭペイロードが逆多重化された後には利用できない。これは、正しい接続性を検証することが可能ではないこと、すなわち、完全な接続性検証（ＣＶ）処理を実行することが可能ではないことを意味する。
【００１３】
ＭＰＬＳ−ＴＰ  ＯＡＭの接続性検証に対して提案された既知のソリューションは、リンクトレースに基づく方法である。しかしながら、その方法は、異なる機能に対して独創的に設計されたため、このソリューションは、接続の端点においてだけでなく、接続を転送する全ての中間ノードにおいてもまた、複雑な処理を含む。これは、望ましくない量の処理リソースの消費という不利点を有する。リンクトレースに基づく方法もまた、容易に拡張可能でないという不利点を有する。
【発明の概要】
【課題を解決するための手段】
【００１４】
本発明は、ＭＰＬＳノードにおける既存のマルチ・プロトコル・ラベル・スイッチング（ＭＰＬＳ）フレーム転送手順への拡張を提案し、そこでは、そのノードにおいて終端される接続上で受信される各フレームに対して、コンテクスト記述子が定義され、このコンテクスト記述子は、必要に応じて、対応する機能（例えば、運用、管理及び保守、ＯＡＭ）へ、フレームと共に提供される。コンテクスト記述子は、フレームが受信される終端された接続と、対応する機能（ＯＡＭ、保護など）の特定の機能端点（メンテナンス・エンドポイント（ＭＥＰ）、保護インスタンスのセレクタブリッジなど）とを特徴づける、主要な属性に基づいて構成される。そのようなものとして、コンテクスト記述子は、終端された接続、例えばフレームが受信される接続を特徴づける（識別する）いくつかの主要な属性を含むであろう。
【００１５】
１つの実施形態において、マルチ・プロトコル・ラベル・スイッチング（ＭＰＬＳ）ノードは、第１のラベルだけでなく第２のラベルをもチェックするように、そして、第２のラベルがジェネリック・アソシエーション・チャネル・ラベル（ＧＡＬ）である場合、第１のラベル（及び関連する場合はラベル空間）を削除（drop）しないように指示される。このように、パケットの元のコンテクスト（すなわち、パケットが受信された接続に関連する情報）は保たれ、対応するＭＥＰへの逆多重化に用いられることができる。その後、ＯＡＭペイロードの中の識別子を、接続性の検証に用いることができる。
【００１６】
例えば、１つの実施形態では、本発明は、マルチ・プロトコル・ラベル・スイッチング（ＭＰＬＳ）電気通信網における方法を提供する。方法は、１つ以上のラベルを含むラベルスタックを有するＭＰＬＳフレームを受信するステップと、そのフレームがその終端ノードに届いたかを判定するステップとを含む。フレームがその終端ノードに届いた場合、ラベルスタックの中の第２のラベルがチェックされ、第２のラベルがジェネリック・アソシエイテッド・チャネル・ラベル（ＧＡＬ）であるかが判定される。そうであった場合、そのフレームのさらなる処理の間に用いるコンテクスト記述子が取得され、フレームはジェネリック・アソシエイテッド・チャネル・ヘッダ（Ｇ−ＡＣＨ）処理のためにルーティングされる。
【００１７】
もう１つの実施形態では、タイム・トゥ・ライブ（ＴＴＬ）値の満了が用いられる。ここで、あて先ＭＥＰのホップ距離は、設定によって又は測定によって、情報源ＭＥＰにより知られている。ＯＡＭメッセージを含む結果として生じるフレームのＴＴＬ値は、それに応じて設定される。したがって、これらのフレームは、ＯＡＭパケットを含むフレーム全体のあて先ノードの制御機能への転送の結果として、あて先ノードにおいて、ＴＴＬ満了を受けるであろう。したがって、複数のラベルを含むフレームの全てのコンテクストが存在し、対応するＭＥＰをアドレス指定するのに用いることができる。
【００１８】
さらにもう１つの実施形態では、監視される接続ごとに専用のラベル空間が特定され、ＭＥＰをアドレス指定するのにそのラベル空間を用いる。
【００１９】
本発明のもう１つの実施形態によれば、マルチ・プロトコル・ラベル・スイッチング（ＭＰＬＳ）電気通信網のノードが提供される。そのノードは、１つ以上のラベルを含むラベルスタックを有するＭＰＬＳフレームを受信するための受信手段を備える。そのノードは、フレームがその終端ノードに届いたかを判定し、もしそうであった場合、第２のラベルがジェネリック・アソシエイテッド・チャネル・ラベル（ＧＡＬ）に関連するかを判定するために、ラベルスタックに含まれる第２のラベルをチェックするように構成される。もしそうであった場合、ノードは、フレームのさらなる処理の間に用いるコンテクスト記述子を取得し、ジェネリック・アソシエイテッド・チャネル・ヘッダ（Ｇ−ＡＣＨ）処理のために、フレームをルーティングするように構成される。
【００２０】
本発明のより良い理解のため、そしてどのように実行に移されてもよいかをより明確に示すため、ここで、一例として、以下の図を参照とする。
【図面の簡単な説明】
【００２１】
【図１】ＭＰＬＳパケット構造を示す図。
【図２】パケット交換型ネットワークの部分を示す図。
【図３】本発明の実施形態による方法のステップを説明するフローチャート。
【図４】本発明のもう１つの実施形態による方法のステップを説明するフローチャート。
【図５】本発明のもう１つの実施形態による方法のステップを説明するフローチャート。
【図６】本発明のもう１つの実施形態による方法のステップを説明するフローチャート。
【図７】本発明のもう１つの実施形態による方法のステップを説明するフローチャート。
【図８】本発明の実施形態によるノードの概略図。
【発明を実施するための形態】
【００２２】
以下の実施形態について、ノードにおいて運用、管理及び保守（ＯＡＭ）機能を実行し、接続検証を実行することを可能とするために、ＯＡＭペイロードの中の識別子を用いる、という背景において説明する。しかしながら、本発明は、単にＯＡＭ機能を実行することより一般的に、また、フレームが受信される接続を単に検証するより一般的に、適用可能であることに留意すべきである。
【００２３】
図２は、パケット交換網１０の部分を図示している。
【００２４】
ラベル・エッジ・ルータ（「ＬＥＲ」）の機能を果たすＭＰＬＳ能力のある進入ノード１２は、パケットトラフィック、例えばインターネットプロトコル（ＩＰ）トラフィックのラベル・スイッチド・フローを、ラベル・スイッチング・ルータ（「ＬＳＲ」）の機能をそれぞれが果たす中間ノード１４、１６を介して、退出ノード１８へ送信する。
【００２５】
連続するノード１２、１４、１６、１８間のトラフィックの各フローは、特定の、連続する、又は「下流の」ＬＳＲへ向けられる、特定の「転送等価クラス」（「ＦＥＣ」）の要素として、２つの隣接ノード間のフローのそれぞれを識別するユニークなラベルでタグ付け、又はラベル付けされる。ラベルは、１つ以上のラベルを有してよい「ラベルスタック」に含まれる。各下流のＬＳＲは、トラフィックを受信し、ラベルスタックの中の第１のラベルを読み出す。そして、そのラベルと、いずれのＮＨＬＦＥが適用されるべきかを示す、その個別のインカミング・ラベル・マップ（ＩＬＭ）テーブルの中のエントリとを対応させ、そしてネクスト・ホップ・ラベル・フォワーディング・エンティティ（ＮＨＬＦＥ）テーブルから参照されたエントリを読み出し、そして、テーブルにおいてそのエントリに関連する転送命令に従う。したがって、ＮＨＬＦＥテーブルは、フレームをどのように取り扱うか（例えば、転送する、外側のラベルを除去する、ノードＹへ送信する、など）を記述し、中間ＬＳＲノード１４、１６に対しては、少なくとも、パケットの次ホップ、及びラベルスタック上で実行されるべき処理が含まれるであろう。
【００２６】
ノード１２、１４、１６、１８は、ラベル・スイッチド・パス（ＬＳＰ）トンネルを定義することができる。そのようなシナリオでは、進入ノード１２と退出ノード１８との間で転送される各パケット上の第１のラベルは、トンネルパス１２→１４→１６→１８を識別するトンネルラベルである。退出ノード１８において、従来技術によれば、トンネルラベルはラベルスタックからポップされ（すなわち、ラベルスタックから除去され）、第２のラベルに基づいて、又は、もしそのような第２のラベルがラベルスタックの中に存在しない場合はパケットの内容に基づいて、パケットはその次のあて先ノードへ転送される。第２のラベルがジェネリック・アソシエイテッド・チャネル・ラベル（ＧＡＬ）である場合、パケットは、ノード１８のジェネリック・アソシエイテッド・チャネル・ヘッダ（Ｇ−ＡＣＨ）処理機能へ、そして、ＯＡＭ機能の例では、そこからメンテナンス・エンドポイント（ＭＥＰ）へ、転送されてもよい。しかしながら、トンネルラベルは失われる。
【００２７】
本発明によれば、既存のマルチ・プロトコル・ラベル・スイッチング（ＭＰＬＳ）フレーム転送手順がＭＰＬＳノードへ拡張され、それにより、そのノードにおいて終端される接続で受信される各フレームに対してコンテクストが定義され、このコンテクストは、必要に応じて、フレームと共に対応する機能（例えばＯＡＭ）へ供給される。コンテクストは、フレームが受信される、その終端される接続を特徴づける主要な属性に基づいて構成され、対応する機能（ＯＡＭ、保護、など）の、特定の機能エンドポイント（例えば、メンテナンス・エンドポイント（ＭＥＰ）、保護インスタンスのセレクタブリッジなど）をアドレス指定する。
【００２８】
第１の実施形態においては、ＭＰＬＳノードは、第１のラベルのみならず第２のラベルもまたチェックするように、そして、第２のラベルがジェネリック・アソシエイテッド・チャネル・ラベル（ＧＡＬ）であるときに、第１のラベル（及び関連する場合はラベル空間）を削除するように命令される。このように、パケットの元のコンテクスト（すなわち、パケットが受信された接続に関する情報）は保たれ、対応するＭＥＰへ逆多重化のために用いることができる。したがって、ＯＡＭペイロードの中の識別子を接続性の検証のために用いることができる。コンテクストに特有のラベル空間又はインタフェースごとのラベル空間が用いられ、ラベル単体では接続を完全には識別できない場合、ラベル空間は関連すると考えられることに留意されたい。
【００２９】
図３は、本発明の実施形態による発明により実行されるステップを示している。ステップ２０１において、ノードはＭＰＬＳフレームを受信する。その後、ステップ２０３において、そのノードがＬＳＰトンネルのエンドポイント、すなわち、退出ノードであるかを判定するために、フレームがチェックされる。例えば、（以下の図４でさらに詳細に説明する）１つの実施形態では、ノードがＬＳＰトンネルのエンドポイントであることを示す第１のラベルを伴って、ステップ２０３でＭＰＬＳフレームの第１のラベルがチェックされる。（以下の図５でさらに詳細に説明する）もう１つの実施形態によれば、ノードがＬＳＰトンネルのエンドポイントであるかを判定するのに、ＭＰＬＳフレーム中で受信されるタイム・トゥ・ライブ（ＴＴＬ）情報を用いる。
【００３０】
ステップ２０３において、ノードがＬＳＰトンネルのエンドポイントでないと判定された場合、フレームの処理は、ステップ２１１において、例えば、次のホップをチェックし、それに応じてフレームを転送する、通常のやり方で継続する。
【００３１】
ステップ２０３において、ノードがＬＳＰトンネルのエンドポイントであると判定された場合、ステップ２０５において、ＭＰＬＳフレームの第２のラベルもまたチェックされる。ステップ２０７において、第２のラベルがＧＡＬであるかが判定される。
【００３２】
ステップ２０７において、第２のラベルがＧＡＬでないと判定された場合、ＭＰＬＳフレームは従来のやり方で処理され、それにより、ステップ２０９において第１のラベルがポップされ、その後、ステップ２１１において、例えば、次のホップをチェックし、それに応じてフレームを転送する、通常のやり方でフレーム処理は継続する。
【００３３】
しかしながら、ステップ２０７で、第２のラベルがＧＡＬであると判定された場合、ステップ２１３において、転送手順の属性に基づいて、コンテクスト記述子が取得される。例えば、このコンテクスト記述子を、トンネルラベル（すなわち、第１のラベル）とラベル空間を用いて、又は、ＮＨＬＦＥキーの値を用いて、形成することができる。コンテクスト記述子が取得されると、その後、ステップ２１５で、フレームを上位層に送信することにより、例えば、ステップ２１３で取得されたコンテクスト記述子と共にフレームをＧ−ＡＣＨ逆多重工程へ送信することによって、従来のやり方でＭＰＬＳフレームを処理してもよい。ステップ２１３で取得されたコンテクスト記述子は保持され、接続検証（ＣＶ）、連続性チェック（ＣＣ）、又はフレームの出所の識別が要求されるかもしれない他の機能のような、将来の処理のために用いられてもよい。
【００３４】
上述のように、コンテクスト記述子を取得する１つの方法は、第１のラベル上で実行されるポップ処理の間に、そうでなければ失われるであろう第１のラベルを記憶しておくことである。図４は、本発明のそのような実施形態で実行されるステップを示している。ステップ３０１では、ノードはＭＰＬＳフレームを受信する。その後、ステップ３０３で、そのＭＰＬＳフレームの第１のラベルがチェックされる。ステップ３０４では、例えば、ポップ工程が実行されるべきであるかを判定することにより、そのノードがエンドポイントであることを第１のラベルが示すかを判定する。ステップ３０４において、ノードがＬＳＰトンネルのエンドポイントでないと判定されると、ＭＰＬＳフレームの処理は、ステップ３１３において、例えば、次のホップをチェックしてそれに応じてフレームを転送する、従来のやり方で継続する。
【００３５】
ステップ３０４において、ノードがＬＳＰトンネルのエンドポイントであると判定されると、この実施形態によれば、その後、ステップ３０５において、第１のラベルが記憶される。その後、ステップ３０７においてＭＰＬＳフレームの第２のラベルがチェックされ、ステップ３０９において第２のラベルがＧＡＬであるかが判定される。
【００３６】
ステップ３０９において第２のラベルがＧＡＬでないと判定されると、ステップ３１１において第１のラベルがポップされ、それにより、結果として第１のラベルが削除される。その後、ステップ３１３において、例えば、次のホップをチェックしそれに応じてフレームを転送する、従来のやり方でＭＰＬＳフレームの処理が継続する。
【００３７】
しかしながら、ステップ３０９において、第２のラベルがＧＡＬであると判定される場合、例えばステップ３１７においてＧＡＬ及びＧ−ＡＣＨを逆多重化し、そして、その後、ステップ３１７においてＭＰＬＳフレームを上位層に送信することにより、けれどもステップ３０５において先に記憶された第１のラベルを削除せずに、従来のやり方で、ＭＰＬＳフレームを処理してもよい。したがって、接続の検証又は連続性チェックのような将来の処理のために、入ってくるフレームのコンテクストを取得して保持することを、ステップ３０５における第１のラベルを記憶することが可能としていることが理解されるであろう。ラベルスタックと異なる特定のメモリにラベル値のコピーを記憶することによって、第１のラベルを記憶してもよい。もう１つの方法として、ラベルスタックヒストリを記憶するために提供されるメモリに、したがって、そのヒストリが所望のコンテクストを供給するように、第１のラベルを記憶してもよい。この目的のためには、最後に処理されたラベルのみを記憶すれば十分であることに留意されたい。
【００３８】
図４の実施形態は、第２のラベルがチェックされるのに先立って第１のラベルが記憶されるが、第１のラベルがポップされる前に記憶されるという条件で、そして、第１のラベルがポップされた後に保持されることができるという条件で、第１のラベルは他のインスタンスにおいて、又は他の方法で記憶されてもよい。
【００３９】
アプリケーションの一例では、図３及び４で説明された実施形態は、ＯＡＭペイロードを逆多重化すること、そして、その後、そのフレームを所望のＭＥＰへ導くことを含んでもよい。しかしながら、本発明は、フレームが受信される終端された接続を特徴づける主要な属性に基づく、着信するフレームのコンテクストを要求する他のアプリケーションにも、適用可能であることが理解されるであろう。
【００４０】
図５は、本発明の実施形態による退出ノード１８における、本発明のより詳細なアプリケーションを示すフローチャートである。本実施形態は、どのようにジェネリックＭＰＬＳデータプレーンの操作（例えば、インターネット技術タスクフォース（ＩＥＴＦ）ＲＦＣ３０３１）を拡張できるか、を示している。
【００４１】
ステップ４０１では、ＭＰＬＳフレームが受信される。本発明と併せて、タイム・トゥ・ライブ（ＴＴＬ）機構を有するものとして、本実施形態を示す。ＴＴＬ機構は、ＭＰＬＳシステムにおいて、フレームがその所望のあて先に届く前に何回のホップが実行されなければならないかを示すために提供される。例えば、誤設定されたループ（例えばリング状のＬＳＰ）が、永遠に転送されるフレームを引き起こさないことを確実にするために、使用することができる。そのようなものとして、ステップ４０３では、最初に、タイム・トゥ・ライブ（ＴＴＬ）値が、フレームが期限切れとなっていることを示す所定値、例えば１、に到達したかが判定される。もしそうであった場合、ステップ４０５においてフレームはＴＴＬ満了モジュールへ送信され、そのような期限切れのフレームに対する従来の方法で処理される。ＴＴＬ機構の利用は、図５の実施形態に必須ではないことに留意されたい。
【００４２】
受信フレームが期限切れでないとすると、ステップ４０７でラベル空間が識別される。このステップは、その特定のフレームを処理するために、適切なインカミング・ラベル・マップ（ＩＬＭ）テーブルを識別することを含んでもよい。ＩＬＭテーブルは、ラベルスペースごとに定義される。ノード設定に基づいて、ラベル空間値がそれぞれの受信フレームに割り当てられ、ＩＬＭテーブルの選択を可能にする。例えば、特定のインタフェース及び他のインタフェースのセットに対する第２のラベル空間に対して、特定のラベル空間を定義することができ、それにより、２つのＩＬＭテーブルが与えられる。
【００４３】
次に、ステップ４０９において、ラベルスタックにおける第１のラベルのラベル値がチェックされる。（例えば、ＧＡＬはラベルスタックの第２のラベルであるために）第１のラベルがＧＡＬでない場合、処理はステップ４１１へ移る。ステップ４１１では、第１のラベル、すなわち最外部のラベルを用いてＮＨＬＦＥキーが見つけられる。ＮＨＦＬＥキーは、ＮＨＦＬＥテーブルの特定のＮＨＦＬＥを識別する。ＮＨＦＬＥキーは、例えば、行番号であることができる。ステップ４１３では、ＮＨＦＬＥオペコード（すなわち、ステップ４１１においてＮＨＦＬＥキーにより取り出されたもの）がＮＨＦＬＥオペコードの性質を判定するためにチェックされる。
【００４４】
ステップ４１３で、ＮＨＦＬＥオペコードがＰＯＰオペコードではないいずれか（例えば、スワップ、新しいラベルのプッシュなど）であると判定された場合、処理はステップ４１５へ移る。そして、ステップ４１７で、次のホップがチェックされる。次のホップが同一ノードへ向かうように指示される場合、処理は、手順を再度開始するステップ４０３へ戻る。ステップ４１７で、次のホップが他のノードへ向かうように指示される場合は、フレームはステップ４１９においてＲＦＣ３０３１パケット転送操作に従って処理され、そして、それに応じて、ステップ４２１においてフレームが送信される。
【００４５】
ステップ４１３で、ＮＨＦＬＥオペコードがＰＯＰオペコードであると判定された場合、ステップ４２３において、ＭＯＮＩＴＯＲＥＤ＿ＣＯＮＮＥＣＴＩＯＮ（ＭＯＮ＿ＣＯＮ）状態ビットが設定されているかと共にラベルスタックにおける第２のラベルがＧＡＬであるかが判定される。（ＭＯＮ＿ＣＯＮ）ビットは、コンテクスト（例えば第１のラベル）が記憶される必要があるようなフレームの連続する処理の間に、ある点で接続性チェックが要求されてもよいことを指示するために供給されてもよい、オプションの特徴であることに留意されたい。したがって、ＭＯＮ＿ＣＯＮビットは、第２のラベルがＧＡＬであるかを判定するために第２のラベルを「のぞき見る」ための表示の機能を果たす。ＭＯＮ＿ＣＯＮ状態ビットはＮＨＬＦＥに格納されている（そして、ＮＨＬＦＥテーブルにおけるエントリの属性と見なしてもよい）。
【００４６】
ステップ４２３において、ＭＯＮ＿ＣＯＮビットが設定されていない、又は、第２のラベルがＧＡＬでない場合、処理は、第１のラベルが（例えばＲＦＣ３０３１により）ポップされるステップ４２５に移動し、その後、処理は次のホップがチェックされるステップ４１７へ移る。従来のシステムでは、ステップ４１３でＮＨＦＬＥがＰＯＰオペコードであると判定された場合、処理は単にステップ４１３からステップ４２５へ移動するであろうことに留意されたい。
【００４７】
処理は、ステップ４２５からその後、上述のように進む。すなわち、ステップ４１７において次のホップが同一ノードへ向かうように指示されていると判定されると、処理が再び開始するステップ４０３へ処理は戻る。ステップ４１７で次のホップが他のいずれかのノードへ向かうように指示されていると判定されると、ステップ４１９においてフレームはＲＦＣ３０３１パケット転送操作に従って処理され、その後、ステップ４２１においてそれによってフレームが送信される。
【００４８】
ステップ４２３に戻り、ＭＯＮ＿ＣＯＮビットが設定されており、かつ第２のラベルがＧＡＬであると判定された場合、処理はＧＡＬ及びＧ−ＡＣＨが（例えば、ＲＦＣ５５８６に従って）逆多重化されるステップ４２７へ移動し、その後、ステップ４２９においてフレームは上位層へ送信される。そのようなものとして、第１のラベルはポップされず、これは、将来の使用、例えば、接続の検証、連続性チェックなどのために、第１のラベルがシステムにとってまだ利用可能であろうことを意味する。第１のラベルは、ステップ４２５でポップされるのを待つ間記憶されたメモリに保持されてもよく、また、将来の処理のために他の場所に記憶されてもよい。上述の実施形態は、別の方法では通常要求されるであろう、ＧＡＬをスタックの先頭ラベルと識別するためのさらなる検索を避けていることに留意すべきである。
【００４９】
ＯＡＭペイロードに関連するアプリケーションで用いられるとき、逆多重化ステップ４２７と送信ステップ４２９は、ＯＡＭペイロードの逆多重化とＭＥＰへのフレームの送信とを含んでもよい。
【００５０】
したがって、上記のことから、第１のラベルとラベル空間がステップ４２３において利用可能である場合、第１のラベルとラベル空間は、コンテクスト記述子の一部として、ステップ４２７のＧ−ＡＣＨ処理機能へ渡されることが理解されるであろう。処理がステップ４２３に到達する時までに、第１のラベル又はラベル空間が失われてもよい状況があるかもしれない。しかしながら、第１のラベル又はラベル空間がすでに失われている場合、ＮＨＬＦＥはまだコンテクストを供給できるが、後者の場合、複数のＮＨＬＦＥをその接続の専用としなければならず、すなわち、１つのＮＨＬＦＥは１つ以上の接続のエンドポイントの転送の挙動を符号化してはならない。そのような制限はＭＰＬＳ−ＴＰにおいて、他の目的に対しても有効である。
【００５１】
図５では明示的に説明していないが、本方法は、また、ラベルスタックの最後に第１のラベルがあるかを判定するために、インカミングラベルをチェックするステップを含んでもよい。これは、不必要な処理を省く、初期チェックとして提供されることができる。
【００５２】
図４で説明した実施形態は、「二重ラベルチェック」の形式で実施すること、すなわち、第１のラベルをチェックし、その後、第２のラベルをチェックすることが理解されるであろう。実装に特有の具現化オプションによれば、二重ラベルチェックに代えて、本方法は、オリジナルのＭＰＬＳの挙動を維持し、除去される第１のラベル及びラベル空間を記憶し、このようにして、図４のそれと同様の方法を組み込むステップを含んでもよい。言い換えれば、第２のラベルがチェックされているような時間まで、第１のラベルが記憶され、その後、それが必要とされなければ第１のラベルを削除するが、それが将来の処理に必要とされる場合は第１のラベルを維持する。例えば、第２の（ＧＡＬ）ラベルの第２の探査及び除去の後に、ＯＡＭ  ＣＶ  Ｇ−ＡＣＨが検出されない限り、この記憶されたコンテクストを削除することができる。この削除することの代替案は、第１及び第２のラベルのみならず、考えられるＯＡＭ  Ｇ−ＡＣＨをもチェックし、検出された場合、第１のラベルとコンテクストとを保持することである。
【００５３】
このように、パケットの元のコンテクストは、ＡＣＨ処理機能に利用可能であり、対応するＭＥＰをアドレス指定するのに使用されうる。そして、接続性の検証又は連続性のチェックに、ＯＡＭペイロードの中の識別子を用いることができる。
【００５４】
上記のことから見られるように、図５の実施形態は、追加的なオプションの特徴を有していてもよく、それにより、「ＭＯＮＩＴＯＲＥＤ＿ＣＯＮＮＥＣＴＩＯＮ」フラグの形式で、対応するＮＨＬＦＥにおいて、第２のラベルのチェックが必要とされることを示す追加的なフラグが提供される。明確な指示は、毎インスタンスに対してより、必要な場合にのみ第２のラベルのチェックが実行されるように、システムの性能を高める利点を有する。
【００５５】
セットアップの間、このフラグは、情報源からあて先ノードへ明示的に通信されることができるし（例えば、ＬＳＰを設定するとき、オプションのＴＬＶ又は新しいビットをＲＳＶＰパスメッセージにおいて用いることができる）、その他の受信パラメータ（例えば、ＯＡＭの設定）からの推論に基づいて設定されることもできることに留意されたい。
【００５６】
図５の実施形態において説明されたように、本発明は、将来の処理に、例えば接続検証又は連続性チェックを実行するのに利用可能な、第１のラベル、すなわちコンテクスト記述子を保持する利点を有する。
【００５７】
図６は、本発明のさらなる実施形態による退出ノード１８における方法を示すフローチャートである。図５と同様に、この実施形態は、ジェネリックＭＰＬＳデータプレーン操作（例えば、インターネット技術タスクフォース（ＩＥＴＦ）ＲＦＣ３０３１）をどのように拡張できるかを示す。図６の実施形態は、ＭＰＬＳに対して定義されたＴＴＬ満了の機構を再利用することにより、関連チャネルの識別のための新しい機構を提供する。
【００５８】
ステップ５０１において、ＭＰＬＳフレームが受信される。図５と同様に、図６の実施形態は、タイム・トゥ・ライブ（ＴＴＬ）の機構の動作を有するように示される。ＴＴＬ機構は、ＭＰＬＳシステムにおいて、フレームが所望のあて先に届く前に実行されなければならないホップの回数を示すために供給される。情報源ＭＥＰは、あて先ＭＥＰへのホップ距離を知っていると仮定して、情報源ノードは、ラベルを識別するＬＳＰにおけるＴＴＬフィールドを、Ｇ−ＡＣＨメッセージを運ぶあらゆるフレームに対するそのホップカウントに設定する。あて先ノードでは、ＴＴＬ満了が発生し、コンテクスト全体が処理機能で使用可能である。これについて、以下、さらに詳細に説明する。
【００５９】
ステップ５０３では、最初に、タイム・トゥ・ライブ（ＴＴＬ）値が、フレームが期限切れとなったことを示す所定値、例えば１に到達したかが判定される。もしそうであった場合、処理はステップ５２５へ移され、ＧＡＬが次の（第２の）ラベルであるかが判定される。ＧＡＬが次の（第２の）ラベルでない場合、処理はステップ５２７へ移り、それにより、その後、フレームは、ＴＴＬ満了モジュールへ送信され、そのような期限切れのフレームに対する従来のやり方で処理される。
【００６０】
ステップ５２５で、ＧＡＬが次の（第２の）ラベルであると判定された場合、処理はステップ５２１へ移り、それにより、ＧＡＬ及びＧ−ＡＣＨは（例えばＲＦＣ５５８６に従って）逆多重化され、その後、ステップ５２３でフレームが上位層へ送信される。あて先ノードのＡＣＨ処理機能では、複数のラベルを含むパケットの全てのコンテクストが存在し、対応するＭＥＰをアドレス指定するのに用いられることができる。これは、コンテクストが失われる結果となるであろう、最外部のラベル上でのポップ（ＰＯＰ）操作が実行されることなく、ＧＡＬ及びＧ−ＡＣＨが逆多重化されるからである。そして、ＯＡＭペイロードの中に含まれる識別子が、例えば、接続性の検証又は連続性チェックのために用いられることができる。
【００６１】
ステップ５０３で、受信フレームが、そのノードが退出ノードでないことを示す、期限切れでなかったと判定された場合、ＭＰＬＳ機構は従来のやり方で動作し、それにより、ステップ５０５でラベル空間が識別される。このステップは、その特定のフレームを処理するために、適切なインカミング・ラベル・マップ（ＩＬＭ）テーブルを識別することを含んでもよい。
【００６２】
次に、ステップ５０７において、第１のラベル値がチェックされる。（例えば、ＧＡＬはラベルスタックの次の（第２の）ラベルであるため、）第１のラベルがＧＡＬでない場合、処理はステップ５０９へ移る。ステップ５０９では、ＮＨＬＦＥキーが最外部のラベルを用いて発見される。ステップ５０９では、ＮＨＬＦＥキーは、ＮＨＬＦＥテーブルの特定のＮＨＬＦＥを識別する。ＮＨＬＦＥキーは、例えば、列数であることができる。ステップ５１１では、ＮＨＦＬＥオペコードの性質を判定するために、（すなわち、ステップ５０９でＮＨＦＬＥキーにより取得された）ＮＨＬＦＥオペコードがチェックされる。
【００６３】
ステップ５１１において、ＮＨＦＬＥオペコードが、ＰＯＰオペコードではないいずれか、（例えば、スワップ、新しいラベルのプッシュなどの）オペコードであると判定された場合、処理はステップ５１３へ移動する。そして、ステップ５１５で次のホップがチェックされる。次のホップが同一ノードへ向かうように指示される場合、処理は本手順を再度開始するステップ５０３へ移動する。ステップ５１５で、次のホップが別のノードへ向かうように指示される場合は、ステップ５１７において、フレームは、例えば、ＲＦＣ３０３１パケット転送操作に従って処理され、そして、それに応じて、ステップ５１９でフレームが送信される。
【００６４】
ステップ５１１において、ＮＨＦＬＥオペコードがＰＯＰオペコードであると判定された場合、処理は、（例えばＲＦＣ３０３１により）第１のラベルがポップされるステップ５２２へ移動し、その後、処理は、次のホップがチェックされるステップ５１５へ移る。ステップ５２２はステップ５１３の部分として組み込まれてもよいことに留意されたい。
【００６５】
その後、ステップ５１５からの処理は上述のように進行する。すなわち、ステップ５１５で次のホップが同一ノードへ向かうように指示されていると判定された場合、処理は、本手順を再度開始するステップ５０３へ戻る。ステップ５１５で次のホップが別のノードへ向かうように指示されていると判定された場合は、ステップ５１７において、フレームはＲＦＣ３０３１パケット転送操作に従って処理され、そして、それに応じて、ステップ５１９でフレームが送信される。
【００６６】
このように、上記のことから、追加的な機能を提供することにより、ＴＴＬ満了処理機能が拡張されることが理解されるであろう。まず、存在する場合はスタックの第２のラベルをチェックし、この第２のラベルがＧＡＬである場合、フレームは、コンテクストの全体と共に、ＡＣＨ処理へ渡される。
【００６７】
図６から、ＴＴｌ満了がない場合、第１のラベルが除去され、第２のラベルに基づいて転送が継続されることも分かる。この第２のラベルは、例えば、ローカルノードがパケットを処理すべきことを意味するＧＡＬであることができる。そして、第２のラベルの除去後、Ｇ−ＡＣＨが、ＯＡＭペイロードと共に発見される。しかしながら、このステップにおいては、第１のラベル、そして元のコンテクストはすでに失われ、接続検証に用いることができない。しかしながら、連続性チェックに対しては、このレガシーの操作をまだ利用可能である。
【００６８】
情報源とあて先のＭＥＰ間のホップカウントを判定するために用いられてもよい様々な選択肢がある。
【００６９】
１つの実施形態によれば、接続のセットアップ手順は、ホップカウントを判定し、この情報を情報源及びあて先ノードへ提供することができる。この実装は、接続のセットアップが、（管理プレーンを通じて）集中型の方法でなされているか、（制御プレーンを通じて）分散型の方法でなされているかに依存する。
【００７０】
集中型の接続のセットアップでは、そのセットアップ手順を制御するエンティティは、確立されるべき接続に対する全体の展望を有する。したがって、ローカルな知識に基づいてホップ距離を計算し、他の設定パラメータと共に、それをエンドポイントＭＥＰへ送信することができる。
【００７１】
分散型の接続のセットアップでは、制御プレーンプロトコルが、ホップカウントを決定する方法を提供しなければならない。ＭＰＬＳ−ＴＰに対する制御プレーンとしてＧＭＰＬＳが使用される場合、ＧＭＰＬＳ接続提供プロトコル（ＲＳＶＰ−ＴＥ）がホップ距離を計算しなければならない。１つのオプションは、ＲＳＶＰ−ＴＥのルート記録能力を適用することである。第２のオプションは、ＭＰＬＳ−ＴＰ接続の物理的なホップの数を計算する、ＲＳＶＰ−ＴＥシグナリングメッセージに新しいホップカウンタを付加することである。
【００７２】
接続確立後（しかし接続性検証前）に、情報源ＭＥＰは、このメッセージのＴＴＬが周知の値、例えば２５０である測定フレームを送信する。あて先ノードは、ＯＭＡメッセージの実際のＴＴｌ値をその周知の値から引き出すことにより、情報源ノードからのそのホップ距離を計算することができる。そして、あて先ＭＥＰは、情報源ＭＥＰへその結果を通知することができる。
【００７３】
すでに存在するＣＣフレームをこの目的に用いてもよい。これらのフレームを用いて、あて先ＭＥＰは、情報源ＭＥＰからのその距離を知る。しかしながら、新しい距離測定メッセージも使われてもよく、この場合、このメッセージは測定を指示し、あて先ＭＥＰからそれに応じて応答メッセージが生成される。
【００７４】
この値を情報源ＭＥＰへ送り返すために、代わりの方法が用いられてもよい。１つのオプションは、この値を運ぶオプションのフィールドを伴い、情報源ＭＥＰへあて先ＭＥＰによって返信されるＣＣメッセージを拡張することである。もう１つのオプションによれば、その値は、新しい距離測定応答メッセージを経て送り返される。
【００７５】
距離測定メッセージに代えてＣＣメッセージを用いる場合、あて先ＭＥＰは、測定されたデータを情報源へいつ返信するかについて、通知されるべきであることに留意されたい。これは、以下のオプションのうちの１つを用いて達成されてもよい。１つのオプションは、第１のＣＣメッセージを受信した後、１度だけ返信することである。第２のオプションは、情報源から停止するように通知されない限り、測定した距離を連続的に返信することである。この通知は第１のＣＶメッセージであってもよく、ＣＣメッセージにおける追加的なビットであってもよい。ホップ距離を測定する上述のオプションは、パスが正しい、又は測定が完了するような時間まで静的であることを仮定していることが理解されるであろう。
【００７６】
図７は、本発明のもう１つの実施形態による、退出ノード１８の方法を示すフローチャートである。図５及び６と同様に、この実施形態は、ジェネリックＭＰＬＳデータプレーン操作（例えば、インターネット技術タスクフォース（ＩＥＴＦ）ＲＦＣ３０３１）をどのように拡張できるかを示す。図７の実施形態は、監視される接続ごとに専用のラベル空間を特定し、ラベル空間はＭＥＰをアドレス指定するのに用いられる。このように、この実施形態によれば、入ってくる接続が属するラベル空間は、ＭＥＰのアドレス指定をするためのコンテクストを特定する。ＲＦＣ５３３１が「コンテクスト固有ラベル空間」を負荷するために用いられるところ、ＲＦＣ３０３１手順は、例えば、プラットフォームごと、及びインタフェースごとにラベル空間を定義する。
【００７７】
ラベル空間は、ノードの中でのみ意味を有する数値の識別子として仮定できる。特定のラベル空間識別子は特定のインタフェースで受信されたラベル値に割り当てられる。これは、そのインタフェースで受信されるとともに定められた第１のラベルを運ぶ、それぞれのフレームが、そのコンテクスト固有ラベル空間に属することを意味する。したがって、第１のラベルを取り除くことができ、第２のラベル、例えばＧＡＬ上で探索が実行される。このステップにおいて、ラベル空間識別子はまだ利用可能であり、そして、フレームと共にＧ−ＡＣＨ逆多重化レイヤに供給されることができる。ラベル空間識別子が利用可能でない場合、ＮＨＬＦＥキーがある制約を伴って利用されてもよい。
【００７８】
したがって、この実施形態は特定のインカミングラベルに対して専用のラベル空間を定め、そのラベルのために、専用のラベル・マッピング・テーブル（ＩＬＭ）を特定する。より詳細な説明を以下に与える。
【００７９】
ステップ６０１において、ＭＰＬＳフレームが受信される。図５及び６と同様に、図７の実施形態はタイム・トゥ・ライブ（ＴＴＬ）の機構の動作を有するように示される。ステップ６０３において、最初に、タイム・トゥ・ライブ（ＴＴＬ）値が、フレームが期限切れとなったことを示す所定値、例えば１に到達したかが判定される。もしそうであった場合、処理はステップ６２７へ移され、それにより、その後、フレームはＴＴＬ満了モジュールへ送信され、そのような期限切れのフレームに対する従来のやり方で処理される。
【００８０】
ステップ６０３で、受信フレームが期限切れでなかったと判定された場合、ステップ６０５でラベル空間が識別される。このステップは、その特定のフレームを処理するために、適切なインカミング・ラベル・マップ（ＩＬＭ）テーブルを識別することを含んでもよい。ラベル空間はラベル値の範囲を定め、すなわち、ラベル空間においてのみ、ラベル値の一意性が保証される。理論的には、ラベル空間とラベル値は共に受信フレーム上で実施されるべき処理を定義する。ラベル空間は、ノード、ノードのインタフェース、又は（すなわち、そのトンネルを識別するラベル値を伴う）トンネルのエンドポイントと結合されてもよい。
【００８１】
スタックにおける第１のラベルがラベル空間を定めると、次に、ステップ６０７では、次の（第２の）ラベルの値がチェックされる。言い換えると、ＭＰＬＳ操作のこのステージにおいて通常行われるであろう第１のラベルをチェックするよりも、かわりに、次のラベル（すなわち、第２のラベル）のラベル値がチェックされる。次の（第２の）ラベルがＧＡＬでない場合、処理はステップ６０９へ移動する。ステップ６０９では、次の（第２の）ラベルを用いて、ＮＨＬＦＥキーを発見する。ＮＨＦＬＥキーは、ＮＨＦＬＥテーブルにおける特定のＮＨＦＬＥを識別する。ＮＨＦＬＥキーは、例えば、列数であることができる。ステップ６１１では、ＮＨＦＬＥオペコードの性質を判定するために、（すなわちステップ６０９でＮＨＦＬＥキーにより取得された）ＮＨＬＦＥオペコードがチェックされる。
【００８２】
ステップ６１１で、ＮＨＦＬＥオペコードがＰＯＰオペコードではないいずれか（例えばスワップ、新しいラベルのプッシュなどの）オペコードであると判定されると、処理はステップ６１３へ移る。そして、ステップ６１５において次のホップがチェックされる。次のホップが同一のノード、すなわち、現在のノードへ向かうように指示される場合、処理は本手順を再度開始するステップ６０３へ移動する。ステップ６１５で、次のホップが別のノードへ向かうように指示される場合は、ステップ６１７において、フレームはＲＦＣ３０３１パケット転送操作に従って処理され、そして、それに応じて、ステップ６１９でフレームが送信される。
【００８３】
ステップ６１１において、ＮＨＦＬＥオペコードがＰＯＰオペコードであると判定されると、処理は、（例えばＲＦＣ３０３１により）第１のラベルがポップされるステップ６２１へ移動し、その後、処理は、次のホップがチェックされるステップ６１５へ移る。ステップ６２１はステップ６１３の部分として組み込まれてもよいことに留意されたい。
【００８４】
その後、ステップ６１５からの処理は上述のように進行する。すなわち、ステップ６１５で次のホップが同一ノードへ向かうように指示されていると判定されると、処理は、本手順を再度開始するステップ６０３へ戻る。ステップ６１５で次のホップが別のノードへ向かうように指示されていると判定されると、ステップ６１７において、フレームはＲＦＣ３０３１パケット転送操作に従って処理され、そして、それに応じて、ステップ５１９でフレームが送信される。
【００８５】
図７の実施形態では、第１のラベルの正確な値が失われるが、第１のラベルはラベル空間を定義し、ラベル空間は、接続そのものをあいまいさなく特定する。そのようなものとして、ラベル空間は、コンテクスト記述子を定義するために用いられることができる。言い換えれば、第１のラベルはコンテクストを記述し、このコンテクストはＭＥＰをアドレス指定するために使用される。したがって、第１のラベルはＭＥＰをアドレス指定し、第２のラベルはＧＡＬのみであり、第２のラベルは、フレームがＧＡＬ及びＧ−ＡＣＨ逆多重化へ送信されるべきことを指示する。
【００８６】
上記のことから、図７の実施形態は、例えば、監視される接続の各々に対して割り当てられるべき専用のラベル空間（及び個々のＩＬＭテーブル）を提供するために、（ＲＦＣ３０３１から導出され）、手順ＲＦＣ５３３１を再利用する。退出ノードは、以下に記載されている基準に基づき、いずれのラベル空間を用いるかを判定することができる。ラベル空間インスタンスがノードと結合されている場合、この「デフォルトの」ラベル空間は、あらゆる受信フレームに割り当てられるであろう。ラベル空間インスタンスがインタフェース（ポート）と結合されている場合、ノードは、そのインタフェース／ポートで受信されるあらゆるフレームに対して、このラベル空間を割り当てるであろう。ラベル空間インスタンスがトンネル・エンドポイントと結合されている場合、ノードは、そのトンネルで受信されるあらゆるフレームに対してこのラベル空間を割り当てるであろう。３つのラベル空間のクラスは、ノードごと、インタフェースごと、コンテクスト固有ラベル空間として、割り当てられてもよい。
【００８７】
接続専用ＩＬＭテーブルは、以下のものを含んでもよい。
・  監視された接続を通じてトンネリングされ、ノードにおいて逆多重化されるクライアント接続を参照するラベルエントリ。
・  カプセル化された疑似ワイヤフローを参照するラベルエントリ。
・  監視された接続に対して関連チャネルが定められる場合、ＧＡＬ（ラベル値１３）を参照するラベルエントリ。
・  カプセル化されていないクライアントのフローに対する処理を定めるために、明示的ヌルラベル（値０）を参照するラベルエントリ。
【００８８】
ＩＬＭにおける各エントリは、ＮＨＬＦＥを参照できることに留意されたい。そして、そのようなコンテクストラベル空間のＧＡＬに対するラベルエントリによりアドレス指定されるＮＨＬＦＥは、コンテクストの情報を符号化できる。このようにして、フレームが受信される接続を識別することができ、ＭＥＰをアドレス指定するのに用いることができる。接続情報はまた、接続検証を実行することのような、続く動作を実行するために用いられることができる。
【００８９】
図８は、本発明の実施形態による、パケット交換型ネットワークのノード１００を示している。ノード１００は、図２に関して説明された退出ノード１８としての動作に適している。
【００９０】
ノード１００は、接続されたノードからデータトラフィックのパケットを受信するための受信回路１０２を備える。受信パケットは、例えば、図３から７に関して説明した方法のいずれかに従ってそのパケットを処理する処理回路１０４へ渡される。受信パケットがＧＡＬラベルを有すると判定されると、パケットは、そのパケット上で実行する適切な処理を決定するＧＡＬ逆多重化回路１０８へ渡される。例えば、パケットがＯＡＭパケットであると識別した場合、ＧＡＬ逆多重化回路１０８は、インタフェース１１０を介してそのパケットをＭＥＰへ転送してもよい。受信パケットがＧＡＬラベルを有していない場合、処理回路１０４は、接続されている別のノードへ、インタフェース回路１０６を介して、パケットを転送してもよい。このように、インタフェース回路１１０を介して、ＬＳＰ及びセクション層に対するさらなる機能性を提供するＯＡＭ、保護機能などを接続してもよい。インタフェース回路１０６を介して、例えば、他のＭＰＬＳ−ＴＰノード又はクライアント装置に接続してもよい。
【００９１】
上述の様々な実施形態は、ＩＥＴＦ  ＢＦＤに基づく機能、ＩＴＵ−Ｔ  Ｙ．１７３１に基づく機能、又は同様の接続検証機能が、ＬＳＰトンネル及びセクション層については、ＭＰＬＳ−ＴＰ接続性検証（ＣＶ）に対する要求を満足させることを可能とすることが理解されるであろう。例えば、上の実施形態で説明された提案の１つを用いるとき、複数のＭＥのそれぞれからのＭＥＰが同一のノードに位置する、予期しない２つのＭＥ間の接続性（例えば、不正結合又は不正接続）が検出可能となる。これらの拡張なくして、言及された機能はそのエラーを検出することはできない。
【００９２】
ＬＳＰトンネルレイヤについては、問題を解決するために、上述の実施形態の全てが適用可能であることに留意されたい。セクション層については、問題の解決のために図６及び７の実施形態が適用可能である。
【００９３】
上述の実施形態は、本発明を制限するよりは説明し、当業者は、添付の請求項の範囲から離れることなく、多くの別の実施形態を設計することができるであろうことに留意すべきである。用語「備え（comprising）」は、請求項に記載されたものではない要素又はステップの存在を排除せず、「a」又は「an」は複数であることを排除せず、単一のプロセッサ、または他のユニットは、請求項で列挙されるいくつかのユニットの機能を満足してもよい。請求項におけるあらゆる参照符号は、その範囲を制限するために解釈されてはならない。
【図１】
0005426770.tif 000002
【図２】
0005426770.tif 000003
【図３】
0005426770.tif 000004
【図４】
0005426770.tif 000005
【図５】
0005426770.tif 000006
【図６】
0005426770.tif 000007
【図７】
0005426770.tif 000008
【図８】
0005426770.tif 000009