JP2014112835A - 電気通信網における方法及び装置 - Google Patents

電気通信網における方法及び装置 Download PDF

Info

Publication number
JP2014112835A
JP2014112835A JP2013246653A JP2013246653A JP2014112835A JP 2014112835 A JP2014112835 A JP 2014112835A JP 2013246653 A JP2013246653 A JP 2013246653A JP 2013246653 A JP2013246653 A JP 2013246653A JP 2014112835 A JP2014112835 A JP 2014112835A
Authority
JP
Japan
Prior art keywords
label
frame
node
gal
mpls
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2013246653A
Other languages
English (en)
Other versions
JP5788954B2 (ja
Inventor
Jocha David
デイヴィッド ヨカ,
Kern Andras
アンドラーシュ ケルン,
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Priority to JP2013246653A priority Critical patent/JP5788954B2/ja
Publication of JP2014112835A publication Critical patent/JP2014112835A/ja
Application granted granted Critical
Publication of JP5788954B2 publication Critical patent/JP5788954B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】マルチ・プロトコル・ラベル・スイッチング(MPLS)ノードを提供する。
【解決手段】コンテクスト記述子がそのノードで終端される接続上で受信される各フレームに対して定義され、このコンテクスト記述子は、必要であれば、対応する機能(例えば、運用、管理及び保守、OAM)に、フレームと共に提供される。コンテクスト記述子は、フレームが受信される、終端された接続を特徴づける主要な属性に基づいて構成され、対応する機能(OAM、保護など)の特定の機能エンドポイント(メンテナンス・エンドポイント(MEP)、保護インスタンスのセレクタブリッジなど)をアドレス指定する。実施形態では、MPLSノードは、第1のラベルだけでなく第2のラベルをもチェックし、第2のラベルがジェネリック・アソシエーション・チャネル・ラベル(GAL)である場合は第1のラベル(及び関連する場合はラベル空間)を削除しないように指示される。
【選択図】図5

Description

本発明は、電気通信網に関し、特に、しかしながら専らではなく、パケット交換方式の転送網のノードにおけるメンテナンス・ポイントをアドレス指定するための方法及び装置に関する。
マルチ・プロトコル・ラベル・スイッチング(MPLS)は、あるノードから他のノードへデータパケットを導き、運ぶ、電気通信網における機構である。各データパケットはラベルスタックを含み、それにより、そのパケットの残りの部分を調べる必要なく、転送の決定がなされる。
既存のMPLSのフォワーディングプレーンに基づいて、マルチ・プロトコル・ラベル・スイッチング転送プレーン(Multi-Protocol Label Switching Transport Plane、MPLS−TP)は、転送網の要求を満足するフレームワークを提供することを目標としている。1つの重要な分野は、明確な操作、管理及び保守(Operation, Administration and Maintenance、OAM)機能セットを有することである。このOAM機能セットは、インターネット技術タスクフォース(IETF)で標準化中である。OAMのフレームワーク及び要求は、発展したOAMソリューションによりサポートされるべき、いくつかの機能(連続性チェック(CC)、接続性検証(CV)、管理信号など)を定義する。
MPLS−TPのためのOAMの操作は、必要なOAMの属性(識別子、タイマ、カウンタなど)を、データフロー中に多重化されるいわゆるOAMフレームに符号化するものである。この方法では、OAMフレーム及びデータフローのフェイトシェアリングが保証され、すなわち、OAMフレームとデータフローは1つのノードからもう1つへ転送されるときに同一のプロセスを経る。OAMフレームは、接続の端点に存在するメンテナンス・エンドポイント(MEP)により生成され、受信される。
現在、MPLS−TPアーキテクチャは、3つのレイヤ、疑似ワイヤ(PW)層、ラベル・スイッチド・パス(LSP)トンネル(接続)層、及びセクション(データリンク)層からなる。MPLS−TP OAMは、3つの層の全てをサポートするように、サポートされる。
現在、OAMパラメータを符号化する、いくつかの競合するソリューションが提案されている。しかしながら、これらのソリューションは、OAMフレームをデータフロー中に多重化する同一の方法に基づいている。その方法は、OAMフレームと他の制御/管理フレームを運ぶために関連するチャネルを定めている。PWの場合、これらのチャネルは、ジェネリック・アソシエイテッド・チャネル・ヘッダ(G−ACH)のみを用いて、識別され、逆多重化される。LSPトンネル及びセクションの場合、関連チャネルを表すために付加的なラベルが定義される。そのラベルは、ジェネリック・アソシエーション・チャネル・ラベル(GAL)と呼ばれる。退出側(すなわち、あて先側)は、これらのラベルに基づいてOAMフレームを検出し、逆多重化する。
しかしながら、OAMフレームをG−ACHの中で送信することに依存するこれらのソリューションは、MPLS及びMPLS−TPにおいて、以下の問題を有する。LSPトンネル層及びセクション層の場合、標準のMPLSデータ転送機構は、データプレーン転送にも使用される識別子を用いて、データプレーンからMEPをアドレス指定するための十分な方法を提供しない。
特定のノードでの標準のMPLS転送の挙動は、以下のようになる。スタック中の第1のラベル(トンネルラベル)に基づいて、ノードはネクスト・ホップ・ラベル・フォワーディング・エントリ(NHLFE)を調べる。このエントリは、そのラベルスタックの処置方法(第1のラベルをポップする、第1のラベルの値を変更する、スタックのトップに新しいラベルをプッシュする、など)を命令する。
ノードが接続の終端処理をする退出ノードである場合、ノードに、スタックからトンネルラベルを除去、すなわちポップするように、そして残りのパケットの検索を実行するように、命令するためにNHLFEは符号化される。もし、それ以上のラベルがスタックに存在する場合は、そのスタックの次のラベルに対する第2の独立の探索が実行される。この第2のラベルは、例えば、パケットをローカルノードの制御機能へ渡すべきことを意味する、GALである可能性があり、GALはフレームから取り除かれる。そして、そのノードの制御機能はフレームを処理し、OAMパケットを適切なMEPへ送信することができる。
図1は、上述の転送機構で使われてもよいMPLSパケット構造を示している。ラベルスタックは、例えば、LSPトンネルラベルである最外部ラベルを含んでもよい。これは、明示的に退出ノードを識別するラベルの形式か、ホップ数に基づいて退出ノードを判定するタイム・トゥ・ライブ(TTL)ラベルの形式をとる。G−ACHメッセージペイロードは、パケットのペイロード、例えば、MEPに送信されるべきOEMペイロードを含むのに対し、アソシエイテッド・チャネル・ヘッダは、G−ACH逆多重化プロセスにより処理される情報を含む。
したがって、MPLSデータプレーンは、データプレーンの属性(例えばデータプレーンの中のラベル)を用いて、特定のMEPをアドレス指定することは許していないことが十分に理解されるであろう。代わりに、OAMペイロードを逆多重化し、適切なMEPをアドレス指定するためのOAMペイロードの中の識別子(すなわち、ルーティング情報)を用いることにより、MEPをアドレス指定するだけかもしれない。
対応するMEPへの逆多重化の後、OAMペイロードに含まれる識別子を用いて、正しい接続を検証するべきである。これらの識別子はノード又はネットワークレベルにおいて一意的であるが、進入及び退出ノード間に複数の平行する接続が存在する場合は、パケットが受信された接続を識別できず、すなわち、入ってくる接続を識別することができない。さらに、上述のように、トンネルラベル(第1のラベル)も、着信するインタフェースも、OAMペイロードが逆多重化された後には利用できない。これは、正しい接続性を検証することが可能ではないこと、すなわち、完全な接続性検証(CV)処理を実行することが可能ではないことを意味する。
MPLS−TP OAMの接続性検証に対して提案された既知のソリューションは、リンクトレースに基づく方法である。しかしながら、その方法は、異なる機能に対して独創的に設計されたため、このソリューションは、接続の端点においてだけでなく、接続を転送する全ての中間ノードにおいてもまた、複雑な処理を含む。これは、望ましくない量の処理リソースの消費という不利点を有する。リンクトレースに基づく方法もまた、容易に拡張可能でないという不利点を有する。
本発明は、MPLSノードにおける既存のマルチ・プロトコル・ラベル・スイッチング(MPLS)フレーム転送手順への拡張を提案し、そこでは、そのノードにおいて終端される接続上で受信される各フレームに対して、コンテクスト記述子が定義され、このコンテクスト記述子は、必要に応じて、対応する機能(例えば、運用、管理及び保守、OAM)へ、フレームと共に提供される。コンテクスト記述子は、フレームが受信される終端された接続と、対応する機能(OAM、保護など)の特定の機能端点(メンテナンス・エンドポイント(MEP)、保護インスタンスのセレクタブリッジなど)とを特徴づける、主要な属性に基づいて構成される。そのようなものとして、コンテクスト記述子は、終端された接続、例えばフレームが受信される接続を特徴づける(識別する)いくつかの主要な属性を含むであろう。
1つの実施形態において、マルチ・プロトコル・ラベル・スイッチング(MPLS)ノードは、第1のラベルだけでなく第2のラベルをもチェックするように、そして、第2のラベルがジェネリック・アソシエーション・チャネル・ラベル(GAL)である場合、第1のラベル(及び関連する場合はラベル空間)を削除(drop)しないように指示される。このように、パケットの元のコンテクスト(すなわち、パケットが受信された接続に関連する情報)は保たれ、対応するMEPへの逆多重化に用いられることができる。その後、OAMペイロードの中の識別子を、接続性の検証に用いることができる。
例えば、1つの実施形態では、本発明は、マルチ・プロトコル・ラベル・スイッチング(MPLS)電気通信網における方法を提供する。方法は、1つ以上のラベルを含むラベルスタックを有するMPLSフレームを受信するステップと、そのフレームがその終端ノードに届いたかを判定するステップとを含む。フレームがその終端ノードに届いた場合、ラベルスタックの中の第2のラベルがチェックされ、第2のラベルがジェネリック・アソシエイテッド・チャネル・ラベル(GAL)であるかが判定される。そうであった場合、そのフレームのさらなる処理の間に用いるコンテクスト記述子が取得され、フレームはジェネリック・アソシエイテッド・チャネル・ヘッダ(G−ACH)処理のためにルーティングされる。
もう1つの実施形態では、タイム・トゥ・ライブ(TTL)値の満了が用いられる。ここで、あて先MEPのホップ距離は、設定によって又は測定によって、ソースMEPにより知られている。OAMメッセージを含む結果として生じるフレームのTTL値は、それに応じて設定される。したがって、これらのフレームは、OAMパケットを含むフレーム全体のあて先ノードの制御機能への転送の結果として、あて先ノードにおいて、TTL満了を受けるであろう。したがって、複数のラベルを含むフレームの全てのコンテクストが存在し、対応するMEPをアドレス指定するのに用いることができる。
さらにもう1つの実施形態では、監視される接続ごとに専用のラベル空間が特定され、MEPをアドレス指定するのにそのラベル空間を用いる。
本発明のもう1つの実施形態によれば、マルチ・プロトコル・ラベル・スイッチング(MPLS)電気通信網のノードが提供される。そのノードは、1つ以上のラベルを含むラベルスタックを有するMPLSフレームを受信するための受信手段を備える。そのノードは、フレームがその終端ノードに届いたかを判定し、もしそうであった場合、第2のラベルがジェネリック・アソシエイテッド・チャネル・ラベル(GAL)に関連するかを判定するために、ラベルスタックに含まれる第2のラベルをチェックするように構成される。もしそうであった場合、ノードは、フレームのさらなる処理の間に用いるコンテクスト記述子を取得し、ジェネリック・アソシエイテッド・チャネル・ヘッダ(G−ACH)処理のために、フレームをルーティングするように構成される。
本発明のより良い理解のため、そしてどのように実行に移されてもよいかをより明確に示すため、ここで、一例として、以下の図を参照とする。
MPLSパケット構造を示す図。 パケット交換型ネットワークの部分を示す図。 本発明の実施形態による方法のステップを説明するフローチャート。 本発明のもう1つの実施形態による方法のステップを説明するフローチャート。 本発明のもう1つの実施形態による方法のステップを説明するフローチャート。 本発明のもう1つの実施形態による方法のステップを説明するフローチャート。 本発明のもう1つの実施形態による方法のステップを説明するフローチャート。 本発明の実施形態によるノードの概略図。
以下の実施形態について、ノードにおいて運用、管理及び保守(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」は複数であることを排除せず、単一のプロセッサ、または他のユニットは、請求項で列挙されるいくつかのユニットの機能を満足してもよい。請求項におけるあらゆる参照符号は、その範囲を制限するために解釈されてはならない。

Claims (18)

  1. マルチ・プロトコル・ラベル・スイッチング(MPLS)電気通信網のノードにおける方法であって、
    1以上のラベルを含むラベルスタックを有するMPLSフレームを受信するステップと、
    前記フレームがその終端ノードに届いたかを判定するステップと、
    前記フレームがその終端ノードに届いた場合、前記ラベルスタックの中の第2のラベルがジェネリック・アソシエイテッド・チャネル・ラベル(GAL)に関連するかを判定するために、前記第2のラベルをチェックするステップと、
    前記第2のラベルがGALに関連する場合、前記フレームのさらなる処理の間の使用のために、コンテクスト記述子を取得するステップと、
    ジェネリック・アソシエイテッド・チャネル・ヘッダ(G−ACH)の処理のために、前記フレームをルーティングするステップと、
    を有することを特徴とする方法。
  2. 前記フレームがその端点に届いたかを判定する前記ステップは、前記ラベルスタックの第1のラベルをチェックするステップを含む、
    ことを特徴とする請求項1に記載の方法。
  3. 前記ラベルスタックの前記第1のラベルをチェックする前記ステップは、前記第1のラベルがポップ操作に関連するかをチェックするステップを含む、
    ことを特徴とする請求項2に記載の方法。
  4. 前記フレームがその端点に届いたかを判定する前記ステップは、フレームと共に受信されたタイム・トゥ・ライブ(TTL)情報をチェックするステップを含む、
    ことを特徴とする請求項1に記載の方法。
  5. コンテクスト記述子を取得する前記ステップは、将来の処理のために、前記第1のラベルを記憶するステップを含む、
    ことを特徴とする請求項2から4のいずれか1項に記載の方法。
  6. コンテクスト記述子を取得する前記ステップは、ラベル空間情報を記憶するステップを含む、
    ことを特徴とする請求項5に記載の方法。
  7. 前記記憶するステップは、前記第2のラベルがチェックされるのに先立って、前記第1のラベルとラベル空間情報とを記憶するステップを含み、
    前記第2のラベルがGALである場合に前記第1のラベルとラベル空間情報とを保持し、
    前記第2のラベルがGALでない場合に前記第1のラベルとラベル空間情報とを削除する、
    ことを特徴とする請求項6に記載の方法。
  8. 前記記憶するステップは、チェックする前記ステップが前記第2のラベルがGALであると判定した後に、前記第1のラベルと前記ラベル空間情報を記憶するステップを含む、
    ことを特徴とする請求項6に記載の方法。
  9. 前記記憶するステップは、ラベルスタックヒストリを記憶するために、最後に処理されたラベルをメモリに記憶するステップを含む、
    ことを特徴とする請求項5から7のいずれか1項に記載の方法。
  10. 前記第2のラベルをチェックする前記ステップは、受信した前記フレームにおいて設定されている、接続が監視された接続であることを指示する状態ビットに応答して実行される、
    ことを特徴とする請求項1から9のいずれか1項に記載の方法。
  11. 前記コンテクスト記述子は専用のラベル空間を用いて取得され、専用ラベル空間は監視された接続のそれぞれに割り当てられる、
    ことを特徴とする請求項1に記載の方法。
  12. 個々のインカミング・ラベル・マップ(ILM)テーブルが、専用のラベル空間のそれぞれに対して提供される、
    ことを特徴とする請求項11に記載の方法。
  13. 1つの監視された接続に対する専用のラベル空間は、メンテナンス・エンドポイント(MEP)をアドレス指定するのに用いられる、
    ことを特徴とする請求項11または12に記載の方法。
  14. 前記コンテクスト記述子は、ネクスト・ホップ・ラベル・フォワーディング・エントリ(NHLFE)キーを用いて取得される、
    ことを特徴とする請求項1から13のいずれか1項に記載の方法。
  15. 運用、管理及び保守(OAM)機能に関連するデータを取得するために、受信した前記フレームを逆多重化するステップと、
    前記逆多重化されたデータに含まれるルーティング情報に基づいて、前記フレームをメンテナンス・エンドポイントへルーティングするステップと、
    取得した前記コンテクスト記述子を用いて接続性チェックを実行するステップと、
    をさらに有する、
    ことを特徴とする請求項1から14のいずれか1項に記載の方法。
  16. 前記コンテクスト記述子は、接続性検証(CV)または連続性チェック(CC)の1つを含む接続性チェックを実行するために用いられる、
    ことを特徴とする請求項1から15のいずれか1項に記載の方法。
  17. マルチ・プロトコル・ラベル・スイッチング(MPLS)電気通信網のノードであって、
    1以上のラベルを含むラベルスタックを有するMPLSフレームを受信するための受信手段を備え、
    前記フレームがその終端ノードに届いたかを判定し、
    前記フレームがその終端ノードに届いた場合、前記ラベルスタックの中の第2のラベルがジェネリック・アソシエイテッド・チャネル・ラベル(GAL)に関連するかを判定するために、前記第2のラベルをチェックし、
    前記第2のラベルがGALに関連する場合、前記フレームのさらなる処理の間の使用のために、コンテクスト記述子を取得し、
    ジェネリック・アソシエイテッド・チャネル・ヘッダ(G−ACH)処理のために前記フレームをルーティングする、
    ように構成されることを特徴とするノード。
  18. 前記ノードは、請求項2から16のいずれか1項による方法を実行するように構成される、
    ことを特徴とする、請求項17に記載のノード。
JP2013246653A 2013-11-28 2013-11-28 電気通信網における方法及び装置 Expired - Fee Related JP5788954B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2013246653A JP5788954B2 (ja) 2013-11-28 2013-11-28 電気通信網における方法及び装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013246653A JP5788954B2 (ja) 2013-11-28 2013-11-28 電気通信網における方法及び装置

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2012520912A Division JP5426770B2 (ja) 2009-07-24 2009-07-24 電気通信網における方法及び装置

Publications (2)

Publication Number Publication Date
JP2014112835A true JP2014112835A (ja) 2014-06-19
JP5788954B2 JP5788954B2 (ja) 2015-10-07

Family

ID=51169671

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013246653A Expired - Fee Related JP5788954B2 (ja) 2013-11-28 2013-11-28 電気通信網における方法及び装置

Country Status (1)

Country Link
JP (1) JP5788954B2 (ja)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009112059A (ja) * 2009-02-17 2009-05-21 Hitachi Communication Technologies Ltd 通信装置

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009112059A (ja) * 2009-02-17 2009-05-21 Hitachi Communication Technologies Ltd 通信装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JPN6015003802; M. Bocci,他: 'MPLS Generic Associated Channel' RFC 5586 , 200906 *

Also Published As

Publication number Publication date
JP5788954B2 (ja) 2015-10-07

Similar Documents

Publication Publication Date Title
JP5426770B2 (ja) 電気通信網における方法及び装置
US11533258B2 (en) In-situ passive performance measurement in a network environment
JP7479490B2 (ja) パケット処理方法及び装置、ネットワークデバイス並びに記憶媒体
EP2595350B1 (en) GMPLS based OAM provisioning
US10432514B2 (en) Multiprotocol label switching traffic engineering tunnel establishing method and device
US8837300B2 (en) Managing trace requests over tunneled links
US11032193B2 (en) In-situ operation, administration, and maintenance in segment routing with multiprotocol label switching networks
US8804736B1 (en) Network tunneling using a label stack delimiter
US20160373317A1 (en) Bandwidth on-demand services in multiple layer networks
US9893986B2 (en) Label distribution method and device
US10374935B2 (en) Link discovery method, system, and device
US10020984B1 (en) RSVP local protection signaling reduction
US20140293798A1 (en) Mpls-tp network and link trace method thereof
WO2014079205A1 (zh) 环网保护中标签自动分配的方法及设备
US8681637B2 (en) Methods for establishing a traffic connection and an associated monitoring connection
US20070195709A1 (en) Methods and Systems for Notifying and Negotiating Capabilities of Monitoring the Performance of Label Switching Path
JP2009089387A (ja) 疑似ワイヤのラベルスイッチド経路の相関付けの方法、システム及びロジック
US20130259057A1 (en) Pseudowire groups in a packet switched network
JP5788954B2 (ja) 電気通信網における方法及び装置
WO2018040614A1 (zh) 建立虚拟专用网标签交换路径方法、相关设备和系统

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20150128

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150206

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150427

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20150727

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150730

R150 Certificate of patent or registration of utility model

Ref document number: 5788954

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees