以下の実施形態について、ノードにおいて運用、管理及び保守(OAM)機能を実行し、接続検証を実行することを可能とするために、OAMペイロードの中の識別子を用いる、という背景において説明する。しかしながら、本発明は、単にOAM機能を実行することより一般的に、また、フレームが受信される接続を単に検証するより一般的に、適用可能であることに留意すべきである。
図2は、パケット交換網10の部分を図示している。
ラベル・エッジ・ルータ(「LER」)の機能を果たすMPLS能力のある進入ノード12は、パケットトラフィック、例えばインターネットプロトコル(IP)トラフィックのラベル・スイッチド・フローを、ラベル・スイッチング・ルータ(「LSR」)の機能をそれぞれが果たす中間ノード14、16を介して、退出ノード18へ送信する。
連続するノード12、14、16、18間のトラフィックの各フローは、特定の、連続する、又は「下流の」LSRへ向けられる、特定の「転送等価クラス」(「FEC」)の要素として、2つの隣接ノード間のフローのそれぞれを識別するユニークなラベルでタグ付け、又はラベル付けされる。ラベルは、1つ以上のラベルを有してよい「ラベルスタック」に含まれる。各下流のLSRは、トラフィックを受信し、ラベルスタックの中の第1のラベルを読み出す。そして、そのラベルと、いずれのNHLFEが適用されるべきかを示す、その個別のインカミング・ラベル・マップ(ILM)テーブルの中のエントリとを対応させ、そしてネクスト・ホップ・ラベル・フォワーディング・エンティティ(NHLFE)テーブルから参照されたエントリを読み出し、そして、テーブルにおいてそのエントリに関連する転送命令に従う。したがって、NHLFEテーブルは、フレームをどのように取り扱うか(例えば、転送する、外側のラベルを除去する、ノードYへ送信する、など)を記述し、中間LSRノード14、16に対しては、少なくとも、パケットの次ホップ、及びラベルスタック上で実行されるべき処理が含まれるであろう。
ノード12、14、16、18は、ラベル・スイッチド・パス(LSP)トンネルを定義することができる。そのようなシナリオでは、進入ノード12と退出ノード18との間で転送される各パケット上の第1のラベルは、トンネルパス12→14→16→18を識別するトンネルラベルである。退出ノード18において、従来技術によれば、トンネルラベルはラベルスタックからポップされ(すなわち、ラベルスタックから除去され)、第2のラベルに基づいて、又は、もしそのような第2のラベルがラベルスタックの中に存在しない場合はパケットの内容に基づいて、パケットはその次のあて先ノードへ転送される。第2のラベルがジェネリック・アソシエイテッド・チャネル・ラベル(GAL)である場合、パケットは、ノード18のジェネリック・アソシエイテッド・チャネル・ヘッダ(G−ACH)処理機能へ、そして、OAM機能の例では、そこからメンテナンス・エンドポイント(MEP)へ、転送されてもよい。しかしながら、トンネルラベルは失われる。
本発明によれば、既存のマルチ・プロトコル・ラベル・スイッチング(MPLS)フレーム転送手順がMPLSノードへ拡張され、それにより、そのノードにおいて終端される接続で受信される各フレームに対してコンテクストが定義され、このコンテクストは、必要に応じて、フレームと共に対応する機能(例えばOAM)へ供給される。コンテクストは、フレームが受信される、その終端される接続を特徴づける主要な属性に基づいて構成され、対応する機能(OAM、保護、など)の、特定の機能エンドポイント(例えば、メンテナンス・エンドポイント(MEP)、保護インスタンスのセレクタブリッジなど)をアドレス指定する。
第1の実施形態においては、MPLSノードは、第1のラベルのみならず第2のラベルもまたチェックするように、そして、第2のラベルがジェネリック・アソシエイテッド・チャネル・ラベル(GAL)であるときに、第1のラベル(及び関連する場合はラベル空間)を削除しないように命令される。このように、パケットの元のコンテクスト(すなわち、パケットが受信された接続に関する情報)は保たれ、対応するMEPへ逆多重化のために用いることができる。したがって、OAMペイロードの中の識別子を接続性の検証のために用いることができる。コンテクストに特有のラベル空間又はインタフェースごとのラベル空間が用いられ、ラベル単体では接続を完全には識別できない場合、ラベル空間は関連すると考えられることに留意されたい。
図3は、本発明の実施形態による発明により実行されるステップを示している。ステップ201において、ノードはMPLSフレームを受信する。その後、ステップ203において、そのノードがLSPトンネルのエンドポイント、すなわち、退出ノードであるかを判定するために、フレームがチェックされる。例えば、(以下の図4でさらに詳細に説明する)1つの実施形態では、ノードがLSPトンネルのエンドポイントであることを示す第1のラベルを伴って、ステップ203でMPLSフレームの第1のラベルがチェックされる。(以下の図5でさらに詳細に説明する)もう1つの実施形態によれば、ノードがLSPトンネルのエンドポイントであるかを判定するのに、MPLSフレーム中で受信されるタイム・トゥ・ライブ(TTL)情報を用いる。
ステップ203において、ノードがLSPトンネルのエンドポイントでないと判定された場合、フレームの処理は、ステップ211において、例えば、次のホップをチェックし、それに応じてフレームを転送する、通常のやり方で継続する。
ステップ203において、ノードがLSPトンネルのエンドポイントであると判定された場合、ステップ205において、MPLSフレームの第2のラベルもまたチェックされる。ステップ207において、第2のラベルがGALであるかが判定される。
ステップ207において、第2のラベルがGALでないと判定された場合、MPLSフレームは従来のやり方で処理され、それにより、ステップ209において第1のラベルがポップされ、その後、ステップ211において、例えば、次のホップをチェックし、それに応じてフレームを転送する、通常のやり方でフレーム処理は継続する。
しかしながら、ステップ207で、第2のラベルがGALであると判定された場合、ステップ213において、転送手順の属性に基づいて、コンテクスト記述子が取得される。例えば、このコンテクスト記述子を、トンネルラベル(すなわち、第1のラベル)とラベル空間を用いて、又は、NHLFEキーの値を用いて、形成することができる。コンテクスト記述子が取得されると、その後、ステップ215で、フレームを上位層に送信することにより、例えば、ステップ213で取得されたコンテクスト記述子と共にフレームをG−ACH逆多重工程へ送信することによって、従来のやり方でMPLSフレームを処理してもよい。ステップ213で取得されたコンテクスト記述子は保持され、接続検証(CV)、連続性チェック(CC)、又はフレームの出所の識別が要求されるかもしれない他の機能のような、将来の処理のために用いられてもよい。
上述のように、コンテクスト記述子を取得する1つの方法は、第1のラベル上で実行されるポップ処理の間に、そうでなければ失われるであろう第1のラベルを記憶しておくことである。図4は、本発明のそのような実施形態で実行されるステップを示している。ステップ301では、ノードはMPLSフレームを受信する。その後、ステップ303で、そのMPLSフレームの第1のラベルがチェックされる。ステップ304では、例えば、ポップ工程が実行されるべきであるかを判定することにより、そのノードがエンドポイントであることを第1のラベルが示すかを判定する。ステップ304において、ノードがLSPトンネルのエンドポイントでないと判定されると、MPLSフレームの処理は、ステップ313において、例えば、次のホップをチェックしてそれに応じてフレームを転送する、従来のやり方で継続する。
ステップ304において、ノードがLSPトンネルのエンドポイントであると判定されると、この実施形態によれば、その後、ステップ305において、第1のラベルが記憶される。その後、ステップ307においてMPLSフレームの第2のラベルがチェックされ、ステップ309において第2のラベルがGALであるかが判定される。
ステップ309において第2のラベルがGALでないと判定されると、ステップ311において第1のラベルがポップされ、それにより、結果として第1のラベルが削除される。その後、ステップ313において、例えば、次のホップをチェックしそれに応じてフレームを転送する、従来のやり方でMPLSフレームの処理が継続する。
しかしながら、ステップ309において、第2のラベルがGALであると判定される場合、例えばステップ317においてGAL及びG−ACHを逆多重化し、そして、その後、ステップ317においてMPLSフレームを上位層に送信することにより、けれどもステップ305において先に記憶された第1のラベルを削除せずに、従来のやり方で、MPLSフレームを処理してもよい。したがって、接続の検証又は連続性チェックのような将来の処理のために、入ってくるフレームのコンテクストを取得して保持することを、ステップ305における第1のラベルを記憶することが可能としていることが理解されるであろう。ラベルスタックと異なる特定のメモリにラベル値のコピーを記憶することによって、第1のラベルを記憶してもよい。もう1つの方法として、ラベルスタックヒストリを記憶するために提供されるメモリに、したがって、そのヒストリが所望のコンテクストを供給するように、第1のラベルを記憶してもよい。この目的のためには、最後に処理されたラベルのみを記憶すれば十分であることに留意されたい。
図4の実施形態は、第2のラベルがチェックされるのに先立って第1のラベルが記憶されるが、第1のラベルがポップされる前に記憶されるという条件で、そして、第1のラベルがポップされた後に保持されることができるという条件で、第1のラベルは他のインスタンスにおいて、又は他の方法で記憶されてもよい。
アプリケーションの一例では、図3及び4で説明された実施形態は、OAMペイロードを逆多重化すること、そして、その後、そのフレームを所望のMEPへ導くことを含んでもよい。しかしながら、本発明は、フレームが受信される終端された接続を特徴づける主要な属性に基づく、着信するフレームのコンテクストを要求する他のアプリケーションにも、適用可能であることが理解されるであろう。
図5は、本発明の実施形態による退出ノード18における、本発明のより詳細なアプリケーションを示すフローチャートである。本実施形態は、どのようにジェネリックMPLSデータプレーンの操作(例えば、インターネット技術タスクフォース(IETF)RFC3031)を拡張できるか、を示している。
ステップ401では、MPLSフレームが受信される。本発明と併せて、タイム・トゥ・ライブ(TTL)機構を有するものとして、本実施形態を示す。TTL機構は、MPLSシステムにおいて、フレームがその所望のあて先に届く前に何回のホップが実行されなければならないかを示すために提供される。例えば、誤設定されたループ(例えばリング状のLSP)が、永遠に転送されるフレームを引き起こさないことを確実にするために、使用することができる。そのようなものとして、ステップ403では、最初に、タイム・トゥ・ライブ(TTL)値が、フレームが期限切れとなっていることを示す所定値、例えば1、に到達したかが判定される。もしそうであった場合、ステップ405においてフレームはTTL満了モジュールへ送信され、そのような期限切れのフレームに対する従来の方法で処理される。TTL機構の利用は、図5の実施形態に必須ではないことに留意されたい。
受信フレームが期限切れでないとすると、ステップ407でラベル空間が識別される。このステップは、その特定のフレームを処理するために、適切なインカミング・ラベル・マップ(ILM)テーブルを識別することを含んでもよい。ILMテーブルは、ラベルスペースごとに定義される。ノード設定に基づいて、ラベル空間値がそれぞれの受信フレームに割り当てられ、ILMテーブルの選択を可能にする。例えば、特定のインタフェース及び他のインタフェースのセットに対する第2のラベル空間に対して、特定のラベル空間を定義することができ、それにより、2つのILMテーブルが与えられる。
次に、ステップ409において、ラベルスタックにおける第1のラベルのラベル値がチェックされる。(例えば、GALはラベルスタックの第2のラベルであるために)第1のラベルがGALでない場合、処理はステップ411へ移る。ステップ411では、第1のラベル、すなわち最外部のラベルを用いてNHLFEキーが見つけられる。NHLFEキーは、NHLFEテーブルの特定のNHLFEを識別する。NHLFEキーは、例えば、行番号であることができる。ステップ413では、NHLFEオペコード(すなわち、ステップ411においてNHLFEキーにより取り出されたもの)がNHLFEオペコードの性質を判定するためにチェックされる。
ステップ413で、NHLFEオペコードがPOPオペコードではないいずれか(例えば、スワップ、新しいラベルのプッシュなど)であると判定された場合、処理はステップ415へ移る。そして、ステップ417で、次のホップがチェックされる。次のホップが同一ノードへ向かうように指示される場合、処理は、手順を再度開始するステップ403へ戻る。ステップ417で、次のホップが他のノードへ向かうように指示される場合は、フレームはステップ419においてRFC3031パケット転送操作に従って処理され、そして、それに応じて、ステップ421においてフレームが送信される。
ステップ413で、NHLFEオペコードがPOPオペコードであると判定された場合、ステップ423において、MONITORED_CONNECTION(MON_CON)状態ビットが設定されているかと共にラベルスタックにおける第2のラベルがGALであるかが判定される。(MON_CON)ビットは、コンテクスト(例えば第1のラベル)が記憶される必要があるようなフレームの連続する処理の間に、ある点で接続性チェックが要求されてもよいことを指示するために供給されてもよい、オプションの特徴であることに留意されたい。したがって、MON_CONビットは、第2のラベルがGALであるかを判定するために第2のラベルを「のぞき見る」ための表示の機能を果たす。MON_CON状態ビットはNHLFEに格納されている(そして、NHLFEテーブルにおけるエントリの属性と見なしてもよい)。
ステップ423において、MON_CONビットが設定されていない、又は、第2のラベルがGALでない場合、処理は、第1のラベルが(例えばRFC3031により)ポップされるステップ425に移動し、その後、処理は次のホップがチェックされるステップ417へ移る。従来のシステムでは、ステップ413でNHLFEがPOPオペコードであると判定された場合、処理は単にステップ413からステップ425へ移動するであろうことに留意されたい。
処理は、ステップ425からその後、上述のように進む。すなわち、ステップ417において次のホップが同一ノードへ向かうように指示されていると判定されると、処理が再び開始するステップ403へ処理は戻る。ステップ417で次のホップが他のいずれかのノードへ向かうように指示されていると判定されると、ステップ419においてフレームはRFC3031パケット転送操作に従って処理され、その後、ステップ421においてそれによってフレームが送信される。
ステップ423に戻り、MON_CONビットが設定されており、かつ第2のラベルがGALであると判定された場合、処理はGAL及びG−ACHが(例えば、RFC5586に従って)逆多重化されるステップ427へ移動し、その後、ステップ429においてフレームは上位層へ送信される。そのようなものとして、第1のラベルはポップされず、これは、将来の使用、例えば、接続の検証、連続性チェックなどのために、第1のラベルがシステムにとってまだ利用可能であろうことを意味する。第1のラベルは、ステップ425でポップされるのを待つ間記憶されたメモリに保持されてもよく、また、将来の処理のために他の場所に記憶されてもよい。上述の実施形態は、別の方法では通常要求されるであろう、GALをスタックの先頭ラベルと識別するためのさらなる検索を避けていることに留意すべきである。
OAMペイロードに関連するアプリケーションで用いられるとき、逆多重化ステップ427と送信ステップ429は、OAMペイロードの逆多重化とMEPへのフレームの送信とを含んでもよい。
したがって、上記のことから、第1のラベルとラベル空間がステップ423において利用可能である場合、第1のラベルとラベル空間は、コンテクスト記述子の一部として、ステップ427のG−ACH処理機能へ渡されることが理解されるであろう。処理がステップ423に到達する時までに、第1のラベル又はラベル空間が失われうる状況があるかもしれない。しかしながら、第1のラベル又はラベル空間がすでに失われている場合、NHLFEはまだコンテクストを供給できるが、後者の場合、複数のNHLFEをその接続の専用としなければならず、すなわち、1つのNHLFEは1つ以上の接続のエンドポイントの転送の挙動を符号化してはならない。そのような制限はMPLS−TPにおいて、他の目的に対しても有効である。
図5では明示的に説明していないが、本方法は、また、ラベルスタックの最後に第1のラベルがあるかを判定するために、インカミングラベルをチェックするステップを含んでもよい。これは、不必要な処理を省く、初期チェックとして提供されることができる。
図4で説明した実施形態は、「二重ラベルチェック」の形式で実施すること、すなわち、第1のラベルをチェックし、その後、第2のラベルをチェックすることが理解されるであろう。実装に特有の具現化オプションによれば、二重ラベルチェックに代えて、本方法は、オリジナルのMPLSの挙動を維持し、除去される第1のラベル及びラベル空間を記憶し、このようにして、図4のそれと同様の方法を組み込むステップを含んでもよい。言い換えれば、第2のラベルがチェックされているような時間まで、第1のラベルが記憶され、その後、それが必要とされなければ第1のラベルを削除するが、それが将来の処理に必要とされる場合は第1のラベルを維持する。例えば、第2の(GAL)ラベルの第2の探査及び除去の後に、OAM CV G−ACHが検出されない限り、この記憶されたコンテクストを削除することができる。この削除することの代替案は、第1及び第2のラベルのみならず、考えられるOAM G−ACHをもチェックし、検出された場合、第1のラベルとコンテクストとを保持することである。
このように、パケットの元のコンテクストは、ACH処理機能に利用可能であり、対応するMEPをアドレス指定するのに使用されうる。そして、接続性の検証又は連続性のチェックに、OAMペイロードの中の識別子を用いることができる。
上記のことから見られるように、図5の実施形態は、追加的なオプションの特徴を有していてもよく、それにより、「MONITORED_CONNECTION」フラグの形式で、対応するNHLFEにおいて、第2のラベルのチェックが必要とされることを示す追加的なフラグが提供される。明確な指示は、毎インスタンスに対してより、必要な場合にのみ第2のラベルのチェックが実行されるように、システムの性能を高める利点を有する。
セットアップの間、このフラグは、ソースからあて先ノードへ明示的に通信されることができるし(例えば、LSPを設定するとき、オプションのTLV又は新しいビットをRSVPパスメッセージにおいて用いることができる)、その他の受信パラメータ(例えば、OAMの設定)からの推論に基づいて設定されることもできることに留意されたい。
図5の実施形態において説明されたように、本発明は、将来の処理に、例えば接続検証又は連続性チェックを実行するのに利用可能な、第1のラベル、すなわちコンテクスト記述子を保持する利点を有する。
図6は、本発明のさらなる実施形態による退出ノード18における方法を示すフローチャートである。図5と同様に、この実施形態は、ジェネリックMPLSデータプレーン操作(例えば、インターネット技術タスクフォース(IETF)RFC3031)をどのように拡張できるかを示す。図6の実施形態は、MPLSに対して定義されたTTL満了の機構を再利用することにより、関連チャネルの識別のための新しい機構を提供する。
ステップ501において、MPLSフレームが受信される。図5と同様に、図6の実施形態は、タイム・トゥ・ライブ(TTL)の機構の動作を有するように示される。TTL機構は、MPLSシステムにおいて、フレームが所望のあて先に届く前に実行されなければならないホップの回数を示すために供給される。ソースMEPは、あて先MEPへのホップ距離を知っていると仮定して、ソースノードは、ラベルを識別するLSPにおけるTTLフィールドを、G−ACHメッセージを運ぶあらゆるフレームに対するそのホップカウントに設定する。あて先ノードでは、TTL満了が発生し、コンテクスト全体が処理機能で使用可能である。これについて、以下、さらに詳細に説明する。
ステップ503では、最初に、タイム・トゥ・ライブ(TTL)値が、フレームが期限切れとなったことを示す所定値、例えば1に到達したかが判定される。もしそうであった場合、処理はステップ525へ移され、GALが次の(第2の)ラベルであるかが判定される。GALが次の(第2の)ラベルでない場合、処理はステップ527へ移り、それにより、その後、フレームは、TTL満了モジュールへ送信され、そのような期限切れのフレームに対する従来のやり方で処理される。
ステップ525で、GALが次の(第2の)ラベルであると判定された場合、処理はステップ521へ移り、それにより、GAL及びG−ACHは(例えばRFC5586に従って)逆多重化され、その後、ステップ523でフレームが上位層へ送信される。あて先ノードのACH処理機能では、複数のラベルを含むパケットの全てのコンテクストが存在し、対応するMEPをアドレス指定するのに用いられることができる。これは、コンテクストが失われる結果となるであろう最外部のラベル上でのポップ(POP)操作が実行されることなく、GAL及びG−ACHが逆多重化されるからである。そして、OAMペイロードの中に含まれる識別子が、例えば、接続性の検証又は連続性チェックのために用いられることができる。
ステップ503で、受信フレームが、そのノードが退出ノードでないことを示す、期限切れでなかったと判定された場合、MPLS機構は従来のやり方で動作し、それにより、ステップ505でラベル空間が識別される。このステップは、その特定のフレームを処理するために、適切なインカミング・ラベル・マップ(ILM)テーブルを識別することを含んでもよい。
次に、ステップ507において、第1のラベル値がチェックされる。(例えば、GALはラベルスタックの次の(第2の)ラベルであるため、)第1のラベルがGALでない場合、処理はステップ509へ移る。ステップ509では、NHLFEキーが最外部のラベルを用いて発見される。ステップ509では、NHLFEキーは、NHLFEテーブルの特定のNHLFEを識別する。NHLFEキーは、例えば、列数であることができる。ステップ511では、NHLFEオペコードの性質を判定するために、(すなわち、ステップ509でNHLFEキーにより取得された)NHLFEオペコードがチェックされる。
ステップ511において、NHLFEオペコードが、POPオペコードではないいずれか、(例えば、スワップ、新しいラベルのプッシュなどの)オペコードであると判定された場合、処理はステップ513へ移動する。そして、ステップ515で次のホップがチェックされる。次のホップが同一ノードへ向かうように指示される場合、処理は本手順を再度開始するステップ503へ移動する。ステップ515で、次のホップが別のノードへ向かうように指示される場合は、ステップ517において、フレームは、例えば、RFC3031パケット転送操作に従って処理され、そして、それに応じて、ステップ519でフレームが送信される。
ステップ511において、NHLFEオペコードがPOPオペコードであると判定された場合、処理は、(例えばRFC3031により)第1のラベルがポップされるステップ522へ移動し、その後、処理は、次のホップがチェックされるステップ515へ移る。ステップ522はステップ513の部分として組み込まれてもよいことに留意されたい。
その後、ステップ515からの処理は上述のように進行する。すなわち、ステップ515で次のホップが同一ノードへ向かうように指示されていると判定された場合、処理は、本手順を再度開始するステップ503へ戻る。ステップ515で次のホップが別のノードへ向かうように指示されていると判定された場合は、ステップ517において、フレームはRFC3031パケット転送操作に従って処理され、そして、それに応じて、ステップ519でフレームが送信される。
このように、上記のことから、追加的な機能を提供することにより、TTL満了処理機能が拡張されることが理解されるであろう。まず、存在する場合はスタックの第2のラベルをチェックし、この第2のラベルがGALである場合、フレームは、コンテクストの全体と共に、ACH処理へ渡される。
図6から、TTl満了がない場合、第1のラベルが除去され、第2のラベルに基づいて転送が継続されることも分かる。この第2のラベルは、例えば、ローカルノードがパケットを処理すべきことを意味するGALであることができる。そして、第2のラベルの除去後、G−ACHが、OAMペイロードと共に発見される。しかしながら、このステップにおいては、第1のラベル、そして元のコンテクストはすでに失われ、接続検証に用いることができない。しかしながら、連続性チェックに対しては、このレガシーの操作をまだ利用可能である。
ソースとあて先のMEP間のホップカウントを判定するために用いられてもよい様々な選択肢がある。
1つの実施形態によれば、接続のセットアップ手順は、ホップカウントを判定し、この情報をソース及びあて先ノードへ提供することができる。この実装は、接続のセットアップが、(管理プレーンを通じて)集中型の方法でなされているか、(制御プレーンを通じて)分散型の方法でなされているかに依存する。
集中型の接続のセットアップでは、そのセットアップ手順を制御するエンティティは、確立されるべき接続に対する全体の展望を有する。したがって、ローカルな知識に基づいてホップ距離を計算し、他の設定パラメータと共に、それをエンドポイントMEPへ送信することができる。
分散型の接続のセットアップでは、制御プレーンプロトコルが、ホップカウントを決定する方法を提供しなければならない。MPLS−TPに対する制御プレーンとしてGMPLSが使用される場合、GMPLS接続提供プロトコル(RSVP−TE)がホップ距離を計算しなければならない。1つのオプションは、RSVP−TEのルート記録能力を適用することである。第2のオプションは、MPLS−TP接続の物理的なホップの数を計算する、RSVP−TEシグナリングメッセージに新しいホップカウンタを付加することである。
接続確立後(しかし接続性検証前)に、ソースMEPは、このメッセージのTTLが周知の値、例えば250である測定フレームを送信する。あて先ノードは、OMAメッセージの実際のTTl値をその周知の値から引き出すことにより、ソースノードからのそのホップ距離を計算することができる。そして、あて先MEPは、ソースMEPへその結果を通知することができる。
すでに存在するCCフレームをこの目的に用いてもよい。これらのフレームを用いて、あて先MEPは、ソースMEPからのその距離を知る。しかしながら、新しい距離測定メッセージも使われてもよく、この場合、このメッセージは測定を指示し、あて先MEPからそれに応じて応答メッセージが生成される。
この値をソースMEPへ送り返すために、代わりの方法が用いられてもよい。1つのオプションは、この値を運ぶオプションのフィールドを伴い、ソースMEPへあて先MEPによって返信されるCCメッセージを拡張することである。もう1つのオプションによれば、その値は、新しい距離測定応答メッセージを経て送り返される。
距離測定メッセージに代えてCCメッセージを用いる場合、あて先MEPは、測定されたデータをソースへいつ返信するかについて、通知されるべきであることに留意されたい。これは、以下のオプションのうちの1つを用いて達成されてもよい。1つのオプションは、第1のCCメッセージを受信した後、1度だけ返信することである。第2のオプションは、ソースから停止するように通知されない限り、測定した距離を連続的に返信することである。この通知は第1のCVメッセージであってもよく、CCメッセージにおける追加的なビットであってもよい。ホップ距離を測定する上述のオプションは、パスが正しい、又は測定が完了するような時間まで静的であることを仮定していることが理解されるであろう。
図7は、本発明のもう1つの実施形態による、退出ノード18の方法を示すフローチャートである。図5及び6と同様に、この実施形態は、ジェネリックMPLSデータプレーン操作(例えば、インターネット技術タスクフォース(IETF)RFC3031)をどのように拡張できるかを示す。図7の実施形態は、監視される接続ごとに専用のラベル空間を特定し、ラベル空間はMEPをアドレス指定するのに用いられる。このように、この実施形態によれば、入ってくる接続が属するラベル空間は、MEPのアドレス指定をするためのコンテクストを特定する。RFC5331が「コンテクスト固有ラベル空間」を付加するために用いられるところ、RFC3031手順は、例えば、プラットフォームごと、及びインタフェースごとにラベル空間を定義する。
ラベル空間は、ノードの中でのみ意味を有する数値の識別子として仮定できる。特定のラベル空間識別子は特定のインタフェースで受信されたラベル値に割り当てられる。これは、そのインタフェースで受信されるとともに定められた第1のラベルを運ぶ、それぞれのフレームが、そのコンテクスト固有ラベル空間に属することを意味する。したがって、第1のラベルを取り除くことができ、第2のラベル、例えばGAL上で探索が実行される。このステップにおいて、ラベル空間識別子はまだ利用可能であり、そして、フレームと共にG−ACH逆多重化レイヤに供給されることができる。ラベル空間識別子が利用可能でない場合、NHLFEキーがある制約を伴って利用されてもよい。
したがって、この実施形態は特定のインカミングラベルに対して専用のラベル空間を定め、そのラベルのために、専用のラベル・マッピング・テーブル(ILM)を特定する。より詳細な説明を以下に与える。
ステップ601において、MPLSフレームが受信される。図5及び6と同様に、図7の実施形態はタイム・トゥ・ライブ(TTL)の機構の動作を有するように示される。ステップ603において、最初に、タイム・トゥ・ライブ(TTL)値が、フレームが期限切れとなったことを示す所定値、例えば1に到達したかが判定される。もしそうであった場合、処理はステップ627へ移され、それにより、その後、フレームはTTL満了モジュールへ送信され、そのような期限切れのフレームに対する従来のやり方で処理される。
ステップ603で、受信フレームが期限切れでなかったと判定された場合、ステップ605でラベル空間が識別される。このステップは、その特定のフレームを処理するために、適切なインカミング・ラベル・マップ(ILM)テーブルを識別することを含んでもよい。ラベル空間はラベル値の範囲を定め、すなわち、ラベル空間においてのみ、ラベル値の一意性が保証される。理論的には、ラベル空間とラベル値は共に受信フレーム上で実施されるべき処理を定義する。ラベル空間は、ノード、ノードのインタフェース、又は(すなわち、そのトンネルを識別するラベル値を伴う)トンネルのエンドポイントと結合されてもよい。
スタックにおける第1のラベルがラベル空間を定めると、次に、ステップ607では、次の(第2の)ラベルの値がチェックされる。言い換えると、MPLS操作のこのステージにおいて通常行われるであろう第1のラベルをチェックするよりも、かわりに、次のラベル(すなわち、第2のラベル)のラベル値がチェックされる。次の(第2の)ラベルがGALでない場合、処理はステップ609へ移動する。ステップ609では、次の(第2の)ラベルを用いて、NHLFEキーを発見する。NHLFEキーは、NHLFEテーブルにおける特定のNHLFEを識別する。NHLFEキーは、例えば、列数であることができる。ステップ611では、NHLFEオペコードの性質を判定するために、(すなわちステップ609でNHLFEキーにより取得された)NHLFEオペコードがチェックされる。
ステップ611で、NHLFEオペコードがPOPオペコードではないいずれか(例えばスワップ、新しいラベルのプッシュなどの)オペコードであると判定されると、処理はステップ613へ移る。そして、ステップ615において次のホップがチェックされる。次のホップが同一のノード、すなわち、現在のノードへ向かうように指示される場合、処理は本手順を再度開始するステップ603へ移動する。ステップ615で、次のホップが別のノードへ向かうように指示される場合は、ステップ617において、フレームはRFC3031パケット転送操作に従って処理され、そして、それに応じて、ステップ619でフレームが送信される。
ステップ611において、NHLFEオペコードがPOPオペコードであると判定されると、処理は、(例えばRFC3031により)第1のラベルがポップされるステップ621へ移動し、その後、処理は、次のホップがチェックされるステップ615へ移る。ステップ621はステップ613の部分として組み込まれてもよいことに留意されたい。
その後、ステップ615からの処理は上述のように進行する。すなわち、ステップ615で次のホップが同一ノードへ向かうように指示されていると判定されると、処理は、本手順を再度開始するステップ603へ戻る。ステップ615で次のホップが別のノードへ向かうように指示されていると判定されると、ステップ617において、フレームはRFC3031パケット転送操作に従って処理され、そして、それに応じて、ステップ519でフレームが送信される。
図7の実施形態では、第1のラベルの正確な値が失われるが、第1のラベルはラベル空間を定義し、ラベル空間は、接続そのものをあいまいさなく特定する。そのようなものとして、ラベル空間は、コンテクスト記述子を定義するために用いられることができる。言い換えれば、第1のラベルはコンテクストを記述し、このコンテクストはMEPをアドレス指定するために使用される。したがって、第1のラベルはMEPをアドレス指定し、第2のラベルはGALのみであり、第2のラベルは、フレームがGAL及びG−ACH逆多重化へ送信されるべきことを指示する。
上記のことから、図7の実施形態は、例えば、監視される接続の各々に対して割り当てられるべき専用のラベル空間(及び個々のILMテーブル)を提供するために、(RFC3031から導出され)、手順RFC5331を再利用する。退出ノードは、以下に記載されている基準に基づき、いずれのラベル空間を用いるかを判定することができる。ラベル空間インスタンスがノードと結合されている場合、この「デフォルトの」ラベル空間は、あらゆる受信フレームに割り当てられるであろう。ラベル空間インスタンスがインタフェース(ポート)と結合されている場合、ノードは、そのインタフェース/ポートで受信されるあらゆるフレームに対して、このラベル空間を割り当てるであろう。ラベル空間インスタンスがトンネル・エンドポイントと結合されている場合、ノードは、そのトンネルで受信されるあらゆるフレームに対してこのラベル空間を割り当てるであろう。3つのラベル空間のクラスは、ノードごと、インタフェースごと、コンテクスト固有ラベル空間として、割り当てられてもよい。
接続専用ILMテーブルは、以下のものを含んでもよい。
・ 監視された接続を通じてトンネリングされ、ノードにおいて逆多重化されるクライアント接続を参照するラベルエントリ。
・ カプセル化された疑似ワイヤフローを参照するラベルエントリ。
・ 監視された接続に対して関連チャネルが定められる場合、GAL(ラベル値13)を参照するラベルエントリ。
・ カプセル化されていないクライアントのフローに対する処理を定めるために、明示的ヌルラベル(値0)を参照するラベルエントリ。
ILMにおける各エントリは、NHLFEを参照できることに留意されたい。そして、そのようなコンテクストラベル空間のGALに対するラベルエントリによりアドレス指定されるNHLFEは、コンテクストの情報を符号化できる。このようにして、フレームが受信される接続を識別することができ、MEPをアドレス指定するのに用いることができる。接続情報はまた、接続検証を実行することのような、続く動作を実行するために用いられることができる。
図8は、本発明の実施形態による、パケット交換型ネットワークのノード100を示している。ノード100は、図2に関して説明された退出ノード18としての動作に適している。
ノード100は、接続されたノードからデータトラフィックのパケットを受信するための受信回路102を備える。受信パケットは、例えば、図3から7に関して説明した方法のいずれかに従ってそのパケットを処理する処理回路104へ渡される。受信パケットがGALラベルを有すると判定されると、パケットは、そのパケット上で実行する適切な処理を決定するGAL逆多重化回路108へ渡される。例えば、パケットがOAMパケットであると識別した場合、GAL逆多重化回路108は、インタフェース110を介してそのパケットをMEPへ転送してもよい。受信パケットがGALラベルを有していない場合、処理回路104は、接続されている別のノードへ、インタフェース回路106を介して、パケットを転送してもよい。このように、インタフェース回路110を介して、LSP及びセクション層に対するさらなる機能性を提供するOAM、保護機能などを接続してもよい。インタフェース回路106を介して、例えば、他のMPLS−TPノード又はクライアント装置に接続してもよい。
上述の様々な実施形態は、IETF BFDに基づく機能、ITU−T Y.1731に基づく機能、又は同様の接続検証機能が、LSPトンネル及びセクション層については、MPLS−TP接続性検証(CV)に対する要求を満足させることを可能とすることが理解されるであろう。例えば、上の実施形態で説明された提案の1つを用いるとき、複数のMEのそれぞれからのMEPが同一のノードに位置する、予期しない2つのME間の接続性(例えば、不正結合又は不正接続)が検出可能となる。これらの拡張なくして、言及された機能はそのエラーを検出することはできない。
LSPトンネルレイヤについては、問題を解決するために、上述の実施形態の全てが適用可能であることに留意されたい。セクション層については、問題の解決のために図6及び7の実施形態が適用可能である。
上述の実施形態は、本発明を制限するよりは説明し、当業者は、添付の請求項の範囲から離れることなく、多くの別の実施形態を設計することができるであろうことに留意すべきである。用語「備え(comprising)」は、請求項に記載されたものではない要素又はステップの存在を排除せず、「a」又は「an」は複数であることを排除せず、単一のプロセッサ、または他のユニットは、請求項で列挙されるいくつかのユニットの機能を満足してもよい。請求項におけるあらゆる参照符号は、その範囲を制限するために解釈されてはならない。