JP2012516602A - メッシュおよびハブアンドスポークネットワークのためのスケーリングされたイーサネット（登録商標）ｏａｍ - Google Patents

Abstract

様々な実施形態例は、第１のネットワークノードにおいてメンテナンスドメインを構成することと、第１のネットワークノードにおいてメンテナンスドメイン内にメンテナンスアソシエーションを構成することと、第１のネットワークノードにおいて、メンテナンスアソシエーション内に、ローカルメンテナンスエンドポイント（ＭＥＰ）を構成することと、メンテナンスアソシエーション内に複数のポイントツーポイント接続を確立することであって、それぞれのリモートＭＥＰの識別子およびそれぞれのリモートＭＥＰのメディアアクセス制御（ＭＡＣ）アドレスを使用して、複数のネットワークノードのそれぞれのネットワークノードにおいてローカルＭＥＰとそれぞれのリモートＭＥＰとの間に各ポイントツーポイント接続が確立されることとのうちの１つまたは複数を含む方法および関連のネットワークノードに関連し、各ポイントツーポイント接続が、ローカルＭＥＰからそれぞれのリモートＭＥＰへのユニキャストＣＦＭメッセージの送信を可能にし、複数のポイントツーポイント接続が単一のメンテナンスアソシエーション内に確立される。

Description

本明細書に開示の実施形態は、一般にイーサネットＯＡＭ（運用、管理、保守：Ｏｐｅｒａｔｉｏｎｓ，Ａｄｍｉｎｉｓｔｒａｔｉｏｎ，ａｎｄ Ｍａｉｎｔｅｎａｎｃｅ）実装に関し、より詳細には、接続障害管理（Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｆａｕｌｔ Ｍａｎａｇｅｍｅｎｔ：ＣＦＭ）機能の構成に関する。

従来のローカルエリアネットワーク（ＬＡＮ）は、物理的な線を介してデータを高速送信することができるフレームベースの標準であるイーサネットを使用してデータを交換する。その最初の実装以来、イーサネット標準は、急速に発展しており、現在、１０ギガバイト／秒以上に対応する。さらに、イーサネットは広範に使用されているため、イーサネットデータ転送の実施に必要なハードウェアは、価格を大幅に下げており、イーサネットがエンタープライズレベルのネットワークの実装として好適な標準になっている。

これらの利点から、通信サービスプロバイダは、しばしばメトロポリタンエリアネットワーク（ＭＡＮ）または広域ネットワーク（ＷＡＮ）と呼ばれる大規模なネットワークにイーサネットの使用を拡大しようと努めてきた。いわゆるキャリアイーサネットを実装することによって、サービスプロバイダは、最低限のコストでそのネットワークの容量を大幅に増やすことができる。次いでこの容量の増加によって、プロバイダのネットワークは、Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＶｏＩＰ）、ＩＰ Ｔｅｌｅｖｉｓｉｏｎ（ＩＰＴＶ）、およびＶｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ（ＶｏＤ）など、次世代アプリケーションに必要な大量のトラフィックに対応することができる。

しかし、イーサネットは、ローカルエリアネットワークの関連で発展したため、本来のイーサネットは、より大規模なネットワークに適用されたとき、いくつかの制限がある。１つの重要な欠点は、運用および保守（ＯＡＭ）機能の本来のサポートの欠如である。より詳細には、ネットワーク事業者は、通常、現場でＬＡＮの問題を診断することができるため、イーサネット標準は、接続および性能のリモートの監視のサポートに欠ける。こうしたリモートの監視のサポート無しに、大規模なネットワークのネットワーク事業者は、そのネットワークを確実に維持することは、不可能ではないにしても、難しいことがわかる。

イーサネット標準における本来の接続障害管理の欠如に対処するために、いくつかの組織がこの機能を記述する追加の標準を開発している。特に、国際電気通信連合（ＩＴＵ）は、参照によりその全体を本明細書に組み込む、Ｙ．１７３１、タイトル「ＯＡＭ Ｆｕｎｃｔｉｏｎｓ ａｎｄ Ｍｅｃｈａｎｉｓｍｓ Ｆｏｒ Ｅｔｈｅｒｎｅｔ−Ｂａｓｅｄ Ｎｅｔｗｏｒｋｓ」を発行した。同様に、電気電子技術者協会（ＩＥＥＥ）は、参照によりその全体を本明細書に組み込む、８０２．１ａｇ、タイトル「Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｆａｕｌｔ Ｍａｎａｇｅｍｅｎｔ」を発行した。

Ｙ．１７３１および８０２．１ａｇは、イーサネットネットワークにおける欠点を検出し、分離し、修正するために使用されるいくつかの機構を記載する。例えば、これらの標準は、ネットワークにわたってネットワークノードによって定期的に送信することができ、それによってその状況を他のノードに通知する連続性チェックメッセージ（Ｃｏｎｔｉｎｕｉｔｙ Ｃｈｅｃｋ Ｍｅｓｓａｇｅ：ＣＣＭ）の使用を記載する。標準は、ネットワークの障害の位置を検証するための類似の機構を記載する。

ネットワーク事業者は、通常、ノードがマルチキャストメッセージを交換するように、これらの標準に記載されたＣＦＭ機構を構成する。したがって、ノードがＣＦＭメッセージを送信したとき、それは通常、複数のノードによって受信される。しかし、いくつかの状況において、ノード群ではなく単一のノードに固有の情報を含むメッセージを送信することが望ましい場合がある。これらの場合、マルチキャストメッセージングは、不十分であり、ポイントツーポイントユニキャスト機能が必要である。

残念ながら、Ｙ．１７３１および８０２．１ａｇのＣＦＭ機構をポイントツーポイント機能用に構成することは複雑であり、時間がかかり、非効率である。特に、ポイントツーポイント機能が必要であるとき、ネットワーク事業者は、接続ごとに個別のメンテナンスアソシエーション（ｍａｉｎｔｅｎａｎｃｅ ａｓｓｏｃｉａｔｉｏｎ）を確立する必要がある。さらに、ネットワーク事業者は、すべてのメンテナンスアソシエーション内にローカルのメンテナンスエンドポイント（ｍａｉｎｔｅｎａｎｃｅ ｅｎｄｐｏｉｎｔ）を確立する必要もある。構成が時間がかかる煩わしいタスクになることに加えて、ネットワークノードが各メンテナンスアソシエーションおよびエンドポイントに関するデータを維持しなければならないため、この構成は、大量の記憶領域も必要とする。

Ｙ．１７３１、タイトル「ＯＡＭ Ｆｕｎｃｔｉｏｎｓ ａｎｄ Ｍｅｃｈａｎｉｓｍｓ Ｆｏｒ Ｅｔｈｅｒｎｅｔ−Ｂａｓｅｄ Ｎｅｔｗｏｒｋｓ」 ８０２．１ａｇ、タイトル「Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｆａｕｌｔ Ｍａｎａｇｅｍｅｎｔ」

上記の理由、および本明細書を読み、理解することにより当業者にとって明らかになる別の理由のために、イーサネットネットワークにおけるポイントツーポイント接続障害管理の簡略化された構成が必要である。

イーサネットネットワークにおけるポイントツーポイント接続障害管理の簡略化された構成のこの必要性に照らして、様々な実施形態例の簡単な概要を提示する。本発明の範囲を限定するためではなく、様々な実施形態例のいくつかの態様を強調し、紹介するための以下の概要では、いくつかの簡略化および省略を行うこともある。当業者が発明の概念を作成し、使用するのに適した好ましい実施形態例の詳細な説明は、後のセクションで述べる。

様々な実施形態例は、第１のネットワークノードにおいてメンテナンスドメインを構成することと；第１のネットワークノードにおいてメンテナンスドメイン内にメンテナンスアソシエーションを構成することと；第１のネットワークノードにおいて、メンテナンスアソシエーション内に、ローカルメンテナンスエンドポイント（ＭＥＰ）を構成することと；メンテナンスアソシエーション内に複数のポイントツーポイント接続を確立することであって、それぞれのリモートＭＥＰの識別子およびそれぞれのリモートＭＥＰのメディアアクセス制御（ＭＡＣ）アドレスを使用して、複数のネットワークノードのそれぞれのネットワークノードにおいてローカルＭＥＰとそれぞれのリモートＭＥＰとの間に各ポイントツーポイント接続が確立されることとのうちの１つまたは複数を含む方法および関連のネットワークノードに関連する。各ポイントツーポイント接続は、ローカルＭＥＰからそれぞれのリモートＭＥＰへのユニキャストＣＦＭメッセージの送信を可能にし、したがって複数のポイントツーポイント接続が単一のメンテナンスアソシエーション内に確立され得る。

この方法で、様々な実施形態例が、メンテナンスエンドポイント間のポイントツーポイントの接続障害管理のメッセージングを実施するのに必要な構成を簡略化することを理解されたい。特に、リモートＭＥＰのユニキャストＭＡＣアドレスを使用してポイントツーポイント接続の構成を可能にすることによって、様々な実施形態例は、ポイントツーポイント接続に関連付けられた機能の向上を可能にしながら、これらのポイントツーポイント接続を確立し、維持するのに必要な時間およびメモリの量を減らす。

様々な実施形態例をよりよく理解するために、添付の図面を参照する。

１つまたは複数のメンテナンスエンドポイントをそれぞれ含む３つのネットワークノードを含むネットワーク例の概要図である。 図１のネットワークにおけるＣＦＭの構成に使用するためのノード例の概要図である。 図２のノードによってＣＦＭメッセージを送信するために使用されるイーサネットフレーム例の概要図である。 イーサネットＣＦＭを構成する方法例のフロー図である。 ２つのメンテナンスエンドポイント間の接続を構成する方法例のフロー図である。 ＣＦＭメッセージを送信する際にメンテナンスエンドポイントによって実行される方法例のフロー図である。 ＣＦＭメッセージを受信する際にメンテナンスエンドポイントによって実行される方法例のフロー図である。

次に、類似の番号は類似の構成要素またはステップを示す図面を参照すると、様々な実施形態例の広範な態様が開示されている。

図１は、３つのネットワークノード１１０、１２０、１３０を含むネットワーク１００の例の概要図である。ネットワーク１００は、ノードＡ１１０、ノードＢ１２０、およびノードＣ１３０を含み、そのそれぞれは、ルータ、スイッチ、またはイーサネットＯＡＭをサポートする他のネットワーク機器とすることができる。各ノード１１０、１２０、１３０は、イーサネット接続障害管理を実施するように構成され得る。より詳細には、各ノード１１０、１２０、１３０は、ＣＦＭメッセージをネットワーク１００における他のノードと交換することによって障害検出、障害検証、障害分離、および障害通知を実施することができる。

ノード１１０、１２０、１３０を使用してＣＦＭメッセージを交換するために、一連の構成ステップがノード１１０、１２０、１３０のそれぞれにおいて実行されなければならない。特に、各ノード１１０、１２０、１３０において、事業者または他のエンティティは、メンテナンスドメイン、メンテナンスアソシエーション、ローカルメンテナンスエンドポイント、およびリモートメンテナンスエンドポイントを構成しなければならない。

いくつかの状況において、各メンテナンスエンドポイント間でポイントツーポイント接続が必要とされる。一例として、イーサネット自動保護切り替え（Ａｕｔｏｍａｔｉｃ Ｐｒｏｔｅｃｔｉｏｎ Ｓｗｉｔｃｈｉｎｇ：ＡＰＳ）の実施に努める事業者は、特定のメンテナンスエンドポイントに合わせて調整された情報を含むメッセージを送信する機能を必要とし得る。すべてのノード１１０、１２０、１３０は、メッセージを受信し、所与のメンテナンスエンドポイントは、それに固有の情報を分離することができないため、この機能は、マルチキャストメッセージングを使用して行うことは不可能である。一例として、ＣＣＭ ＰＤＵにおけるリモート障害表示（ｒｅｍｏｔｅ ｄｅｆｅｃｔ ｉｎｄｉｃａｔｉｏｎ：ＲＤＩ）ビットがＡＰＳの切り替えを実行するための表示として使用されていた場合、そのビットセットを伴うマルチキャストメッセージによって、ＲＤＩビットが影響を及ぼすことが意図されたピアのみではなく、すべてのピアが行動を起こすことになる。

通常の実装において、メンテナンスドメイン内におけるすべての接続をポイントツーポイント接続として構成することは、かなりの数のコマンドおよびオーバーヘッドを必要とする。以下の例は、ネットワーク１００のノードにおけるメンテナンスエンドポイントの各対間のポイントツーポイントメンテナンス接続を構成するために使用することができる１組の疑似コマンドを示す。

したがって、この例において、ドメインにおけるノードの各対の間にポイントツーポイント接続を確立することは、３つのアソシエーションおよび６つのＭＥＰを必要とする。その結果、各ノード１１０、１２０、１３０は、２つのアソシエーション、２つのリモートＭＥＰ、および２つのローカルＭＥＰに関する情報を格納する必要がある。所望の数のポイントツーポイント接続が増加するにつれて、構成が次第に煩わしくなることを理解されたい。例えば、ハブアンドスポーク構成において、中央または「ハブ」ノードは、他のすべての「スポーク」ノードとのポイントツーポイント通信が可能でなければならない。各ノードは、メッシュにおけるすべての他のノードとのポイントツーポイント通信が可能でなければならないため、メッシュ構成は、なおさら複雑である。

様々な実施形態例によれば、各ノード１１０、１２０、１３０は、簡略化された構成プロセスを使用してノード１１０、１２０、１３０間にポイントツーポイント接続を確立するように構成され得る。より詳細には、各ノード１１０、１２０、１３０は、接続が確立されるべきリモートＭＥＰのメディアアクセス制御（ＭＡＣ）アドレスを使用してポイントツーポイント接続を確立することができる。以下の例は、ネットワーク１００のノードにおけるメンテナンスエンドポイントの各対間のポイントツーポイントメンテナンス接続を構成するために使用することができる１組の疑似コマンドを示す。

したがって、この例において、ドメインにおけるノードの各対の間にポイントツーポイント接続を確立することは、１つのアソシエーションおよび３つのＭＥＰだけを必要とする。その結果、各ノード１１０、１２０、１３０は、１つのアソシエーション、２つのリモートＭＥＰ、および１つのローカルＭＥＰに関する情報を格納するだけでよい。さらに、必要なコマンドの合計数が大幅に低減されるため、ＣＦＭ機能の構成は、大幅に簡略化される。構成時間およびメモリ使用率のこの低減は、ハブアンドスポークおよびメッシュ構成を確立するときに特に明白である。

上記のコマンドから明らかなように、リモートＭＥＰの構成は、最初の構成コマンドにリモートＭＥＰのＭＡＣアドレスを含めることによって容易にすることができる。あるいは、本明細書にさらに詳しく記載するように、リモートＭＥＰからＣＦＭメッセージを受信すると、リモートＭＥＰのＭＡＣアドレスを動的に決定することができる。こうした実施形態において、ポイントツーポイント接続は、リモートＭＥＰのＭＡＣアドレスを決定すると、適切に構成することができる。

上記のコマンドに従って構成すると、それぞれのノード１１０、１２０、１３０における各メンテナンスエンドポイントは、確立されたポイントツーポイント接続上でＣＦＭメッセージを交換することができる。一例として、ノード１１０におけるメンテナンスエンドポイントは、ユニキャスト連続性チェックメッセージ（ＣＣＭ）をノード１２０上のメンテナンスエンドポイントに直接送信することができる。このＣＣＭメッセージは、ローカルＭＥＰの状況に関するリモートＭＥＰを更新するために使用され、必要に応じて、リモートＭＥＰにおいてイーサネットＡＰＳを実施するために使用される情報を送信することができる。

上記の説明において、構成は、メンテナンスエンドポイントを含む３つのノード１１０、１２０、１３０に関して記載されていることを理解されたい。ネットワーク１００は、他の大量のノードを含む可能性があり、その一部はメンテナンスエンドポイントを含まない。一例として、ネットワーク１００におけるいくつかのノードは、メンテナンス中間ポイント（ｍａｉｎｔｅｎａｎｃｅ ｉｎｔｅｒｍｅｄｉａｔｅ ｐｏｉｎｔ）を含むことができ、その構成は、当業者に明らかであろう。

図２は、図１のネットワーク１００におけるＣＦＭの構成に使用するためのノード２００の例の概要図である。ノード２００は、ルータ、スイッチ、またはイーサネットＯＡＭをサポートする他のネットワーク機器とすることができる。ノード２００は、受信機２１０、構成モジュール２２０、構成ストレージ２３０、および送信機２４０を含み得る。

受信機２１０は、別のネットワークノードからデータを受信するように構成される、機械可読記憶媒体上で符号化されるソフトウェアおよび／またはハードウェアを含み得る。受信機２１０に含まれるハードウェアは、例えば、パケットおよび他のデータを受信するネットワークインターフェイスカードとすることができる。したがって、受信機２１０は、ノード２００にあるメンテナンスエンドポイント向けのＣＦＭメッセージを受信することができる。

構成モジュール２２０は、ノード２００上でＣＦＭ機能を実施するように構成される、機械可読記憶媒体上で符号化されるソフトウェアおよび／またはハードウェアを含み得る。したがって、構成モジュール２２０は、マイクロプロセッサ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または類似のハードウェアを含み得る。また、構成モジュール２２０は、機械実行可能命令を含む記憶媒体を含み得る。いずれの場合も、このハードウェアは、スタンドアロンまたはノード２００の中央プロセッサ（図示せず）の一部でもよく、あるいはラインカードまたはポート分配オブジェクトで実施されてもよい。他の適した実装は、当業者に明らかであろう。

構成モジュール２２０は、ノード２００においてＣＦＭ機能を構成するよう要求される命令を実行するように構成され得る。したがって、構成モジュール２２０は、メンテナンスドメインを構成し、メンテナンスドメイン内にメンテナンスアソシエーションを構成し、メンテナンスアソシエーション内にローカルメンテナンスエンドポイントを構成するのに必要な命令を実行することができる。

ポイントツーポイント機能が望ましいとき、構成モジュール２２０は、メンテナンスアソシエーション内にポイントツーポイント接続を確立するようさらに構成され得る。したがって、構成モジュール２２０は、リモートＭＥＰの識別子（例えばリモートメンテナンスエンドポイント識別子）およびリモートＭＥＰのＭＡＣアドレスを使用してローカルＭＥＰとリモートＭＥＰとの間のポイントツーポイント接続を確立するための命令を実行することができる。上記でさらに詳しく説明したように、この構成方法は、すべてのポイントツーポイント接続が単一のメンテナンスアソシエーション内に確立されるため、構成の複雑さおよび構成情報の格納に必要なメモリ量の大幅な低減をもたらす。

構成モジュール２２０は、コマンドラインインターフェイスから、またはグラフィカルユーザインターフェイスを介して、リモートＭＥＰ ＩＤおよびＭＡＣアドレスを含むコマンドを受信すると、ポイントツーポイント接続を確立することができる。あるいは、構成モジュール２２０は、リモートＭＥＰからＣＦＭメッセージを受信したことに基づいてリモートＭＥＰのＭＡＣアドレスを発見すると、ポイントツーポイント接続を動的に確立することができる。特に、構成モジュール２２０は、ノード２００におけるリモートＭＥＰからローカルＭＥＰへのＣＦＭメッセージの送信に使用されるＰＤＵからＭＡＣアドレスを抽出することができる。

ローカルＭＥＰとリモートＭＥＰとの間のポイントツーポイント接続を確立すると、ポイントツーポイント接続は、ローカルＭＥＰからリモートＭＥＰへのユニキャストＣＦＭメッセージの送信に使用され得る。したがって、構成モジュール２２０は、リモートＭＥＰに固有の少なくとも１つのフィールドを含むリモートＭＥＰへのユニキャスト送信のためのＣＦＭメッセージを生成することができる。一例として、構成モジュール２２０は、リモートＭＥＰによって使用されるリンクが故障したことを示すリモート障害表示（ＲＤＩ）フィールドに値「１」を含める連続性チェックメッセージを生成することができる。ＣＣＭメッセージを受信すると、リモートＭＥＰは、メッセージをリモートＭＥＰ用に合わせて調整されたという知識に基づいて適切に応答することができる。例えば、リモートＭＥＰは、ＣＦＭメッセージにおいてＲＤＩビットを認識すると、保護リンクに切り替えることができる。連続性チェックメッセージにおけるユニキャスト送信のための他の適した情報は、当業者に明らかであろう。

構成ストレージ２３０は、機械可読記憶媒体において維持されてもよく、構成モジュール２２０によって使用されるすべての構成情報を含む。したがって、構成ストレージ２３０は、データベース、連結リスト、アレイ、または構成情報の記憶に適した任意の他のデータ構造または構成を含み得る。

構成ストレージ２３０は、ノード２００によって使用されるすべてのドメイン、アソシエーション、ローカルＭＥＰ、およびリモートＭＥＰに関する情報を維持するＣＦＭオブジェクト２３２を含む。構成ストレージ２３０は、ポイントツーポイント接続が確立された各リモートＭＥＰのＭＡＣアドレスを示すＭＡＣアドレス２３４をさらに含む。各ＭＡＣアドレスは、リモートＭＥＰを識別するリモートＭＥＰ ＩＤと関連付けてＭＡＣアドレス２３４に格納することができる。ＣＦＭ機能の初期構成後、構成モジュール２２０は、リモートＭＥＰの対応するＭＡＣアドレスを示すためにＭＡＣアドレス２３４を更新しながら、ノード２００によって使用されるドメイン、アソシエーション、ローカルＭＥＰ、およびリモートＭＥＰの構成情報を反映するためにＣＦＭオブジェクト２３２を更新することができる。

送信機２４０は、別のネットワークノードにデータを送信するように構成される、機械可読記憶媒体上で符号化されるソフトウェアおよび／またはハードウェアを含み得る。送信機２４０に含まれるハードウェアは、例えば、パケットおよび他のデータを送信するネットワークインターフェイスカードとすることができる。したがって、送信機２４０は、ポイントツーポイント接続を介してリモートＭＥＰ向けのＣＦＭメッセージを送信することができる。一例として、送信機２４０は、図３を参照して以下でさらに詳しく説明するフォーマットを使用して連続性チェックメッセージを送信することができる。

図３は、図２のノード２００によってＣＦＭメッセージを送信するために使用されるイーサネットフレーム３００の例の概要図である。フレーム３００は、宛先アドレスフィールド３１０、ソースアドレスフィールド３２０、サービスタグフィールド３３０、顧客タグフィールド３４０、ＯＡＭ Ｅｔｈｅｒｔｙｐｅフィールド３５０、データペイロード３６０、およびフレームチェックシーケンスフィールド３７０を含む。

宛先アドレスフィールド３１０は、フレーム３００の宛先ＭＡＣアドレスを示すために使用される６バイトを含む。ソースアドレスフィールド３２０は、フレーム３００のソースアドレスを示すために使用される６バイトを含む。ノード２００がリモートＭＥＰの宛先ＭＡＣアドレスを動的に埋める実施形態において、ノード２００は、リモートＭＥＰからメッセージを受信すると、ソースアドレスフィールド３２０から値を抽出することによってＭＡＣアドレスを決定することができる。

サービスタグフィールド３３０は、サービスプロバイダネットワークへの入り口でフレーム３００に添付することができ、ネットワークを介してトラフィックを分離し、識別するために使用される。オプションの顧客タグフィールド３４０は、フレーム３００に関連付けられた顧客の仮想ローカルエリアネットワーク（ＶＬＡＮ）タグを含むために使用され得る。ＯＡＭ Ｅｔｈｅｒｔｙｐｅフィールド３５０は、フレームが特定のプロトコルに従って送信されることを示す予め定義された値に設定され得る。一例として、フレームがＩＥＥＥ８０２．１ａｇに準拠することを示すために、値を「０×８９０２」に設定することができる。

データペイロード３６０は、フレーム３００で送信されるＣＦＭメッセージに固有の複数のフィールドを含み得る。フィールド３６１、３６２、３６３、３６４は、すべてのＣＦＭヘッダーに含まれるが、ＣＦＭメッセージのタイプに固有の情報を含んでいてもよい。メンテナンスドメインフィールド３６１は、フレーム３００のメンテナンスドメインレベルを識別する整数を含み得る。バージョンフィールド３６２は、基礎を成すプロトコルの拡張を反映するために変更され得るプロトコルバージョン番号を含み得る。ＯｐＣｏｄｅフィールド３６３は、フレーム３００によって送信されるメッセージのタイプを識別するために使用され得る。一例として、フレーム３００が連続性チェックメッセージを含むとき、ＯｐＣｏｄｅフィールド３６３の値は、「１」に設定され得る。

フラグフィールド３６４は、ＯｐＣｏｄｅフィールド３６３によって識別されるように、ＣＦＭメッセージのタイプに固有の情報を含み得る。一例として、ＯｐＣｏｄｅフィールド３６３が、メッセージがＣＣＭであることを示す「１」であるとき、フラグフィールド３６４は、３つの構成要素に分けられ得る。第１の構成要素は、上記でさらに詳しく説明したように、リモート障害インジケータビットを含むことができる。第２の構成要素は、ＣＣＭメッセージの送信間隔を示すＣＣＭ間隔を含み得る。最後に、第３の構成要素は、フラグフィールド３６４における残りのビットから成るいくつかの予備ビットとすることができる。

ＴＬＶオフセットフィールド３６５は、ＯｐＣｏｄｅフィールド３６３によって示されるように、ＣＦＭメッセージのタイプに基づいて設定され得る。ＴＬＶオフセットフィールド３６５に格納された値は、フレームに含まれるデータのエンドポイントを決定するために使用され得る。一例として、メッセージがＣＣＭメッセージであるとき、ＴＬＶオフセットフィールド３６５は、「７０」に設定され得る。

共通フィールド３６１、３６２、３６３、３６４に加えて、フレーム３００は、メッセージのタイプに固有のいくつかの他のフィールドを含み得る。図３に示されるように、ＣＣＭメッセージは、シーケンス番号フィールド３６６、そこからＣＣＭが送信されたＭＥＰを指定するメンテナンスエンドポイント識別子フィールド３６７、および送信側ＭＥＰが属するメンテナンスアソシエーションを指定するメンテナンスアソシエーション識別子フィールド３６８も含み得る。データペイロード３６０の後、フレームチェックシーケンス３７０は、フレーム３００の送信における誤り検出および訂正に使用されるいくつかの文字を含み得る。

図４は、イーサネットＣＦＭを構成する方法４００の例のフロー図である。方法４００に記載した処理は、ノードにおいてＣＦＭ機能を実施するために、およびより詳細には、メンテナンスエンドポイント間でポイントツーポイント機能を実施するためにノード２００で実行され得る。

方法４００は、ステップ４０５で開始し、ステップ４１０に進み、メンテナンスドメインがノード２００において構成される。次いで方法４００は、ステップ４２０に進み、ノード２００において、メンテナンスドメイン内にメンテナンスアソシエーションが構成される。次に方法４００は、ステップ４３０に進み、ノード２００において、ステップ４２０で確立されたメンテナンスアソシエーション内にローカルメンテナンスエンドポイントが構成される。

ノード２００においてドメイン、アソシエーション、およびローカルＭＥＰを構成した後、方法４００は、ステップ４４０に進み、ローカルＭＥＰとリモートメンテナンスエンドポイントとの間の接続が構成される。図５を参照して以下でさらに詳しく説明されるように、構成中にリモートＭＥＰのＭＡＣアドレスを提供することによって、またはリモートＭＥＰからＣＦＭメッセージを受信するとＭＡＣアドレスを動的に決定することによって、所与の接続がポイントツーポイントとして確立され得る。

決定ステップ４５０で、ＭＥＰ間の接続が構成されなければならない追加のノードがあるかどうかが決定される。構成が必要な追加のノードがあるとき、方法４００は、ステップ４１０に戻り、新しいノードについてプロセスが繰り返される。あるいは、すべてのノードが構成されているとき、方法４００は、ステップ４５５に進み、方法４００が終了する。

図５は、２つのメンテナンスエンドポイント間の接続を構成する方法５００の例のフロー図である。方法５００は、図４のステップ４４０に関連して上述したように、ノード２００において、ローカルＭＥＰとリモートＭＥＰとの間の接続を確立する際に実行される詳細な処理に対応し得る。

方法５００の例は、ステップ５０５で開始し、ステップ５１０に進み、ノード２００は、リモートＭＥＰのＭＡＣアドレスを取得する。ＭＡＣアドレスは、ポイントツーポイント接続の構成中にユーザから取得され得る。あるいは、リモートＭＥＰのＭＡＣアドレスは、例えば、ＣＦＭメッセージを送信するために使用されるＰＤＵからソースアドレスを抽出することによって、リモートＭＥＰからＣＦＭメッセージを受信すると決定され得る。ステップ５１０においてＭＡＣアドレスを決定すると、方法５００は、ステップ５２０に進み、ＭＡＣアドレスが構成ストレージ２３０に格納され、より詳細には、ＭＡＣアドレス２３４に格納される。

次いで方法５００は、ステップ５３０に進み、接続の構成のためのコマンドが受信され、決定ステップ５４０に進み、接続がポイントツーポイントとして構成されるかどうかをノード２００が決定する。接続がポイントツーポイントとして構成されることが決定されると、ノード２００は、その接続についてのユニキャスト挙動を有効にする。図６を参照して以下でさらに詳しく説明されるように、次いでローカルＭＥＰから宛先ＭＥＰにユニキャストメッセージが送信され得る。その接続についてのユニキャスト挙動を有効にした後、方法５００は、ステップ５６５に進み、方法５００が終了する。

これに対して、決定ステップ５４０で、接続がポイントツーポイントとして構成されないことを決定すると、方法５００は、ステップ５６０に進み、マルチキャスト挙動が使用される。特に、リモートＭＥＰがメッセージを受信するマルチキャストアドレスを使用して、ローカルＭＥＰからリモートＭＥＰに送信されたＣＦＭメッセージが送信される。次いで方法５００は、ステップ５６５に進み、方法５００が終了する。

図６は、ＣＦＭメッセージを送信する際にメンテナンスエンドポイントによって実行される方法６００の例のフロー図である。方法６００に記載した処理は、ノード２００におけるローカルＭＥＰと別のノードにあるリモートＭＥＰとの間でＣＦＭメッセージを送信するために、ノード２００で実行され得る。

方法６００の例は、ステップ６０５で開始し、決定ステップ６１０に進み、特定の接続についてユニキャスト機能が有効かどうかをノード２００が決定する。ノード２００は、例えば構成ストレージ２３０におけるＭＡＣアドレス２３４がリモートＭＥＰのリモートＭＥＰ ＩＤに対応するエントリを有するかどうかを決定することによってこの決定を行うことができる。

決定ステップ６１０において、その接続についてユニキャストが有効であることをノード２００が決定すると、方法６００は、ステップ６２０に進み、ノード２００が、リモートＭＥＰに関連付けられたＭＡＣアドレスをパケットの宛先アドレスとして使用して、リモートＭＥＰ向けのユニキャストＣＦＭメッセージを構築する。一例として、ノード２００は、図３に関連して上述したフレーム３００のフォーマットを使用して、接続性チェックメッセージを構築することができる。

次いで方法６００は、決定ステップ６３０に進み、ＣＦＭメッセージに障害通知を含むかどうかをノード２００が決定する。ノード２００が障害通知を含むべきであることを決定すると、方法６００は、ステップ６４０に進み、ノード２００が障害通知をパケットに追加する。一例として、ＣＦＭメッセージがＣＣＭであるとき、ノード２００は、メッセージ内のリモート障害表示ビットを「１」にマークすることができる。次いで方法６００は、ステップ６５０に進む。あるいは、決定ステップ６３０において、障害通知がメッセージに追加されるべきではないと決定されると、方法６００はステップ６５０に直接進む。

ステップ６５０において、ノード２００は、ユニキャストＣＦＭメッセージをリモートＭＥＰに送信する。特に、ノード２００の送信機２４０は、メッセージをリモートＭＥＰのユニキャストＭＡＣアドレスに対して出力する。次いで方法６００は、ステップ６７０に進み、方法６００が終了する。

あるいは、決定ステップ６１０で、特定の接続についてユニキャスト機能が有効でないとノード２００が決定すると、方法６００はステップ６６０に進み、ノード２００は、メッセージをマルチキャストメッセージとして、リモートＭＥＰがメンバーであるメンテナンスエンドポイントのグループに送信する。次いで方法６００は、ステップ６７０に進み、方法６００が終了する。

図７は、ＣＦＭメッセージを受信する際にメンテナンスエンドポイントによって実行される方法７００の例のフロー図である。方法７００に記載した処理は、別のノードにあるリモートＭＥＰから受信したＣＦＭメッセージを処理するために、ノード２００で実行され得る。

方法７００の例は、ステップ７０５で開始し、ステップ７１０に進み、ノード２００がリモートＭＥＰからＣＦＭメッセージを受信する。次いで方法７００は、決定ステップ７１５に進み、メッセージがユニキャストであるかどうかをノード２００が決定する。ノード２００は、例えば、メッセージの決定アドレスフィールドに含まれるＭＡＣアドレスを検査することによってこの決定を行うことができる。

メッセージがユニキャストであることが決定ステップ７２０で決定されると、方法７００は、決定ステップ７２０に進む。決定ステップ７２０において、ノード２００は、メッセージのソースＭＡＣアドレスが、構成ストレージ２３０におけるリモートＭＥＰのために格納されたＭＡＣアドレスに一致するかどうかを決定する。この決定は、例えば、構成ストレージ２３０のＭＡＣアドレス２３４におけるリモートＭＥＰ ＩＤと関連付けて格納されているＭＡＣアドレスを決定することによって行うことができる。

ＭＡＣアドレスが一致することが決定ステップ７２０で決定されると、方法７００は、ステップ７２５に進み、ＣＦＭメッセージがポイントツーポイントとして処理される。特に、ノード２００は、内容をノード２００に合わせて調整されたという知識によりメッセージを処理することができる。一例として、これによってノード２００は、メッセージのリモート障害表示ビットにおける「１」の値を認識すると、自動保護切り替えを実施することができ得る。こうした場合、ノード２００は動作中のリンクが故障したと決定し、保護リンクへの切り替えを自動的に実施することができる。ポイントツーポイントの関連の他の適した使用は、当業者に明らかである。

一方、ノード２００は、決定ステップ７２０で、ＭＡＣアドレスが一致しないことを決定すると、方法７００は、ステップ７３０に進む。ステップ７３０において、ノード２００は、メッセージにおけるＭＡＣアドレスおよびリモートＭＥＰに関連付けられているＭＡＣアドレスが異なることを示す警告または他の通知をオプションで発することができる。これは、例えば送信エラーやリモートＭＥＰによるメッセージにおけるソースＭＡＣアドレスの不適切な割り当てなど、いくつかの要因の結果とすることができる。ステップ７２５でポイントツーポイントとして処理した後、またはステップ７３０で警告または他の通知を発した後、方法７００は、ステップ７６０に進み、方法７００が終了する。

あるいは、メッセージがユニキャストではないこと（すなわちマルチキャスト）が決定ステップ７１５で決定されると、方法７００は、決定ステップ７３５に進み、リモートＭＥＰのＭＡＣアドレスを知る必要があるかどうかをノード２００が決定する。この決定は、例えば、ＣＦＭメッセージに含まれるリモートＭＥＰ識別子に対応する構成ストレージ２３０のＭＡＣアドレス２３４にエントリがあるかどうかを決定することによって行われ得る。

ノード２００がリモートＭＥＰのＭＡＣアドレスを知る必要があることを決定すると、方法７００はステップ７４０に進み、ノード２００がリモートＭＥＰのＭＡＣアドレスを決定する。一例として、ノード２００は、ＣＦＭメッセージのソースアドレスフィールドからＭＡＣアドレスを抽出することができる。

次いで方法７００はステップ７４５に進み、構成ストレージ２３０が更新される。このステップにおいて、ノード２００は、リモートＭＥＰのリモートＭＥＰ ＩＤと関連付けてＭＡＣアドレス２３４にリモートＭＥＰのＭＡＣアドレスを格納することができる。さらに、ノード２００は、ノード２００のローカルＭＥＰとリモートＭＥＰとの間にポイントツーポイント接続が自動的に確立されるように、図４との関連で上述した処理を実行することができる。次いで方法７００はステップ７６０に進み、方法７００が終了する。

あるいは、決定ステップ７３５で、リモートＭＥＰのＭＡＣアドレスがすでにわかっていることをノード２００が決定すると、方法７００は、ステップ７５０に進み、ＣＦＭメッセージがマルチキャストメッセージとして処理される。次いで方法７００はステップ７６０に進み、方法７００が終了する。

上記によれば、様々な実施形態例は、メンテナンスエンドポイント間のポイントツーポイント接続障害管理メッセージングを実施するのに必要な構成を簡略化する。特に、リモートＭＥＰのユニキャストＭＡＣアドレスを使用してポイントツーポイント接続の構成を可能にすることによって、様々な実施形態例は、これらのポイントツーポイント接続の確立および維持に必要な時間およびメモリの量を低減する。その結果、事業者は、イーサネット自動保護切り替えなど、所望の機能を実施するためにポイントツーポイント機能を有利に使用することができる。

様々な実施形態例がハードウェア、ファームウェア、および／またはソフトウェアで実施され得ることは、上記の説明から明らかであろう。さらに、様々な実施形態例を、本明細書に詳しく記載した動作を実行するために、少なくとも１つのプロセッサによって読み取られ、実行され得る機械可読記憶媒体上に格納される命令として実施することができる。機械可読記憶媒体は、（例えばルータやスイッチなど）ネットワークノードなど、機械によって読み取り可能な形で情報を格納する任意の機構を含み得る。したがって、機械可読記憶媒体は、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリ装置、および類似の記憶媒体を含み得る。

様々な実施形態例を、そのいくつかの態様例を特に参照して詳しく説明したが、本発明では他の実施形態が可能であり、その詳細は明らかな様々な点について変更が可能であることを理解されたい。当業者には容易に明らかなように、本発明の意図および範囲内に留めたまま変形および変更を実施することができる。したがって、上記の開示、説明、および図面は、例示にすぎず、本発明を限定するものではなく、本発明は特許請求の範囲によってのみ定義される。

Claims (10)

1. 複数のノードを含むネットワークにおいてイーサネット接続障害管理（ＣＦＭ）を構成する方法であって、
   第１のネットワークノードにおいてメンテナンスドメインを構成することと、
   第１のネットワークノードにおいてメンテナンスドメイン内にメンテナンスアソシエーションを構成することと、
   第１のネットワークノードにおいて、メンテナンスアソシエーション内に、ローカルメンテナンスエンドポイント（ＭＥＰ）を構成することと、
   メンテナンスアソシエーション内に複数のポイントツーポイント接続を確立することであって、各ポイントツーポイント接続が、それぞれのリモートＭＥＰの識別子およびそれぞれのリモートＭＥＰのメディアアクセス制御（ＭＡＣ）アドレスを使用して、複数のネットワークノードのそれぞれのネットワークノードにおいてローカルＭＥＰとそれぞれのリモートＭＥＰとの間に確立されることとを含み、
   各ポイントツーポイント接続が、ローカルＭＥＰからそれぞれのリモートＭＥＰへのユニキャストＣＦＭメッセージの送信を可能にし、
   複数のポイントツーポイント接続が、単一のメンテナンスアソシエーション内に確立される、
   イーサネットＣＦＭを構成する方法。
2. それぞれのリモートＭＥＰのＭＡＣアドレスが、ポイントツーポイント接続の構成中にユーザによって入力される、請求項１に記載のイーサネットＣＦＭを構成する方法。
3. それぞれのリモートＭＥＰからＣＦＭメッセージを受信すると、それぞれのリモートＭＥＰのＭＡＣアドレスがローカルＭＥＰによって決定され、ＭＡＣアドレスが、それぞれのリモートＭＥＰからローカルＭＥＰにＣＦＭメッセージを送信するために使用されるプロトコルデータユニット（ＰＤＵ）から抽出される、請求項１に記載のイーサネットＣＦＭを構成する方法。
4. 各それぞれのネットワークノードにおいて、
   それぞれのネットワークノードにおいてメンテナンスドメインを構成するステップと、
   それぞれのネットワークノードにおいてメンテナンスドメイン内にメンテナンスアソシエーションを構成するステップと、
   それぞれのネットワークノードにおいて、メンテナンスアソシエーション内に、それぞれのリモートＭＥＰを構成するステップと、
   メンテナンスアソシエーション内にポイントツーポイント接続を確立するステップであって、ポイントツーポイント接続が、ローカルＭＥＰの識別子およびローカルＭＥＰのＭＡＣアドレスを使用して、それぞれのネットワークノードにおいてローカルＭＥＰとそれぞれのリモートＭＥＰとの間で確立される、ステップと
   を実行することによって、ハブアンドスポーク構成を確立することをさらに含む、請求項１に記載のイーサネットＣＦＭを構成する方法。
5. 各それぞれのネットワークノードにおいて、
   それぞれのネットワークノードにおいてメンテナンスドメインを構成するステップと、
   それぞれのネットワークノードにおいてメンテナンスドメイン内にメンテナンスアソシエーションを構成するステップと、
   それぞれのネットワークノードにおいて、メンテナンスアソシエーション内に、それぞれのリモートＭＥＰを構成するステップと、
   メンテナンスアソシエーション内に複数のポイントツーポイント接続を確立するステップであって、ポイントツーポイント接続が、複数のネットワークノードにおいてそれぞれのリモートＭＥＰとすべての他のＭＥＰとの間に確立される、ステップと
   を実行することによって、メッシュ構成を確立すること
   をさらに含む、請求項１に記載のイーサネットＣＦＭを構成する方法。
6. それぞれのリモートＭＥＰへのユニキャスト送信のためのＣＦＭメッセージを生成するステップであって、ＣＦＭメッセージがそれぞれのリモートＭＥＰ用に合わせて調整された情報を含む少なくとも１つのフィールドを含む、ステップと、
   それぞれのリモートＭＥＰに対応するポイントツーポイント接続を介してＣＦＭメッセージを送信するステップであって、それぞれのリモートＭＥＰ用に合わせて調整された情報を含む少なくとも１つのフィールドが、値「１」に設定されたリモート障害表示（ＲＤＩ）ビットを含み、値「１」に設定されたＲＤＩビットを含むＣＦＭメッセージの受信に応答して、それぞれのリモートＭＥＰが保護リンクに切り替えるための自動保護切り替え（ＡＰＳ）を実施する、ステップと
   を実行することによってそれぞれのリモートＭＥＰに固有のアクションを実施すること
   をさらに含む、請求項１に記載のイーサネットＣＦＭを構成する方法。
7. ＣＦＭ構成情報を維持する構成ストレージと、
   メンテナンスドメインを構成し、
   メンテナンスドメイン内にメンテナンスアソシエーションを構成し、
   メンテナンスアソシエーション内に、ローカルメンテナンスエンドポイント（ＭＥＰ）を構成し、
   メンテナンスアソシエーション内に複数のポイントツーポイント接続を確立し、各ポイントツーポイント接続が、それぞれのリモートＭＥＰの識別子およびそれぞれのリモートＭＥＰのメディアアクセス制御（ＭＡＣ）アドレスを使用して、複数のリモートノードのそれぞれのノードにおいてローカルＭＥＰとそれぞれのリモートＭＥＰとの間で確立され、
   メンテナンスドメイン、メンテナンスアソシエーション、ローカルメンテナンスエンドポイント、および各ポイントツーポイント接続の構成を反映するために構成ストレージを更新する
   ための命令を実行するように構成された構成モジュールと、
   を含み、各ポイントツーポイント接続が、ローカルＭＥＰからそれぞれのリモートＭＥＰへのユニキャストＣＦＭメッセージの送信を可能にし、
   複数のポイントツーポイント接続が、単一のメンテナンスアソシエーション内に確立される、
   イーサネット接続障害管理（ＣＦＭ）を実施するネットワークノード。
8. ポイントツーポイント接続の構成中、ユーザからそれぞれのリモートＭＥＰのＭＡＣアドレスを受信するように構成されたインターフェイス
   をさらに含む、請求項７に記載のネットワークノード。
9. 構成モジュールが、
   それぞれのリモートＭＥＰからＣＦＭメッセージを受信すると、それぞれのリモートＭＥＰのＭＡＣアドレスを決定し、構成モジュールが、それぞれのリモートＭＥＰからローカルＭＥＰへのＣＦＭメッセージの送信のために使用されるＰＤＵからＭＡＣアドレスを抽出する
   するようにさらに構成された、請求項７に記載のネットワークノード。
10. それぞれのリモートＭＥＰに対応するポイントツーポイント接続を介してＣＦＭメッセージを送信するように構成された送信機であって、構成モジュールが、それぞれのリモートＭＥＰへのユニキャスト送信のためにＣＦＭメッセージを生成するための命令を実行するようにさらに構成され、ＣＦＭメッセージが、それぞれのリモートＭＥＰに合わせて調整された情報を含む少なくとも１つのフィールドを含み、それぞれのリモートＭＥＰに合わせて調整された情報を含む少なくとも１つのフィールドが、値「１」に設定されたリモート障害表示（ＲＤＩ）ビットを含み、値「１」に設定されたＲＤＩビットを含むＣＦＭメッセージの受信に応答して、それぞれのリモートＭＥＰが保護リンクに切り替えるための自動保護切り替え（ＡＰＳ）を実施する、送信機
    をさらに含む、請求項７に記載のネットワークノード。

Images