(57)【要約】  イーサネットマルチキャストの接続性チェックのための方法およびシステムが提供される。ルートＭＥＰが、マルチキャストＤＡを使用して、マルチキャストグループの中のすべてのリーフＭＥＰへ接続性チェック機能情報を有するフレームをマルチキャストする。故障状態であるリーフＭＥＰは、故障表示情報を有するフレームをルートＭＥＰに送信する。故障表示情報を有するフレームを受信することに応答して、ルートＭＥＰは、故障状態であるリーフＭＥＰのユニキャストアドレスを使用して、故障状態であるリーフＭＥＰにのみ接続性損失情報を有するフレームを送信する。
2011512059.tif 000002
【特許請求の範囲】
【請求項１】
イーサネットマルチキャストの接続性チェックのための方法であって、
マルチキャストＤＡを使用して、ルートＭＥＰからマルチキャストグループの中のすべてのリーフＭＥＰへ接続性チェック機能情報を有するフレームをマルチキャストすることと、
故障状態であるリーフＭＥＰからルートＭＥＰへ、故障表示情報を有するフレームを送信することと、
故障表示情報を有するフレームを受信することに応答して、ルートＭＥＰが、故障状態であるリーフＭＥＰのユニキャストアドレスを使用して、故障状態であるリーフＭＥＰにのみ接続性損失情報を有するフレームを送信することと
を含む、方法。
【請求項２】
故障表示情報を有するフレームを受信すると、ルートＭＥＰがマルチキャストＤＡから故障状態であるリーフＭＥＰのユニキャストアドレスを削除すること
をさらに含む、請求項１に記載の方法。
【請求項３】
前記マルチキャストＤＡからユニキャストアドレスを削除することが、故障状態であるリーフＭＥＰがマルチキャストグループから抜けるようにすることによって実現される、請求項２に記載の方法。
【請求項４】
ユニキャストアドレスをマルチキャストＤＡから削除した後に、以前のように、マルチキャストＤＡを使用してルートＭＥＰから故障状態であるリーフＭＥＰを除くマルチキャストグループの中のすべてのリーフＭＥＰに、接続性チェック機能情報を有するフレームをマルチキャストすること
をさらに含む、請求項２または３に記載の方法。
【請求項５】
前記マルチキャストすることが、定期的に行われる、請求項１に記載の方法。
【請求項６】
イーサネットマルチキャストの接続性チェックのためのシステムであって、ルートＭＥＰおよびマルチキャストグループの中の複数のリーフＭＥＰを含み、ルートＭＥＰが、
マルチキャストＤＡを使用して、マルチキャストグループの中の複数のリーフＭＥＰのすべてに接続性チェック機能情報を有するフレームをマルチキャストするように構成され、マルチキャストグループの中のリーフＭＥＰから故障表示情報を有するフレームを受信することに応答して、このリーフＭＥＰのユニキャストアドレスを使用して、このリーフＭＥＰにのみ接続性損失情報を有するフレームを送信するように構成された送信機と、
故障状態であるリーフＭＥＰから故障表示情報を有するフレームを受信するように構成された受信機とを含み、リーフＭＥＰが、
故障状態を検出すると、ルートＭＥＰへ故障表示情報を有するフレームを送信するように構成された送信機と、
マルチキャストＤＡを使用して接続性チェック機能情報を有するフレームを、自己のユニキャストアドレスを使用してルートＭＥＰの送信機から接続性損失情報を有するフレームを受信するように構成された受信機と
を含む、システム。
【請求項７】
ルートＭＥＰがさらに、
リーフＭＥＰから故障表示情報を有するフレームを受信すると、マルチキャストＤＡからリーフＭＥＰのユニキャストアドレスを削除するための手段
を含む、請求項６に記載のシステム。
【請求項８】
マルチキャストＤＡからユニキャストアドレスを削除するための手段が、
リーフＭＥＰがマルチキャストグループから抜けるようにすることによってユニキャストアドレスをマルチキャストＤＡから削除する
ように構成された、請求項７に記載のシステム。
【請求項９】
ルートＭＥＰの送信機がさらに、
ユニキャストアドレスをマルチキャストＤＡから削除した後に、以前のように、マルチキャストＤＡを使用することによって、故障表示情報を有するフレームの送信元であるリーフＭＥＰを除くマルチキャストグループの中のすべてのリーフＭＥＰに接続性チェック機能情報を有するフレームをマルチキャストする
ように構成された、請求項６または７に記載のシステム。
【請求項１０】
ルートＭＥＰの送信機が、接続性チェック機能情報を有するフレームを定期的にマルチキャストするように構成された、請求項６に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概してマルチキャストイーサネットＯＡＭ（Ｏｐｅｒａｔｉｎｇ  Ａｄｍｉｎｉｓｔｒａｔｉｏｎ  ａｎｄ  Ｍａｉｎｔｅｎａｎｃｅ、運用、管理、および保守）メカニズムに関し、より詳細にはイーサネットマルチキャストの接続性チェックのための方法およびシステムに関する。
【背景技術】
【０００２】
イーサネットの配備が急速に拡大するにつれて、イーサネットＯＡＭ機能の需要が増大している。高度なＯＡＭ機能（Ｅｔｈｅｒｎｅｔ  Ｃｏｎｎｅｃｔｉｖｉｔｙ  ａｎｄ  Ｆａｕｌｔ  Ｍａｎａｇｅｍｅｎｔ（イーサネットの接続性および障害管理）、またはイーサネットＣＦＭとも呼ばれる）を提供することを目的とする様々な標準が開発されている。詳細には、本明細書に参照により組み込まれる２つの標準、ＩＥＥＥ  ８０２．１ａｇおよびＩＴＵ−Ｔ  Ｙ．１７３１が、イーサネット網におけるＯＡＭ機能、特にポイントツーポイント（すなわちユニキャスト）のイーサネットＯＡＭのためのメカニズムを定義している。ＩＴＵ−Ｔ  Ｙ．１７３１との関連では、イーサネットＭＥＧ（Ｍａｉｎｔｅｎａｎｃｅ  Ｅｎｔｉｔｙ  Ｇｒｏｕｐ）のエンドポイントは、「ＭＥＧエンドポイント」すなわちＭＥＰと呼ばれる。ＭＥＰは、（適切なＯＡＭフレームを発行することによって）ＯＡＭ活動を開始する、および監視するために、システム管理者によって使用される。
【０００３】
事前対応型のＯＡＭには、イーサネットの接続性チェック機能が使用される。これは、ＭＥＧの中のＭＥＰの任意のペア間の接続性の損失（ＬＯＣ）、ミスマージ、予期しないＭＥＰ、予期しないＭＥＧレベル、予期しない周期など、他の故障状態を検出するために使用される。ポイントツーポイント接続のための接続性チェックのプロセスが、図１に示されている。このプロセスでは、ＲＤＩ（Ｒｅｍｏｔｅ  ｄｅｆｅｃｔ  ｉｎｄｉｃａｔｉｏｎ、遠隔故障表示）ビットが０であるＣＣＭ（Ｃｏｎｔｉｎｕｉｔｙ  Ｃｈｅｃｋ  Ｍｅｓｓａｇｅ、接続性チェックメッセージ）が、一方のＭＥＰ（例えば、図１の中のＭＥＰ１０１）からもう一方のＭＥＰ（例えば図１の中のＭＥＰ１０２）へ定期的に送信される、ステップ１１０。２つのＭＥＰ間のリンクが、例えばＳＦ（信号損失）またはＳＤ（信号劣化）により、損害を受ける場合、ＭＥＰ１０２は、ＭＥＰ１０１にＲＤＩを送り返し、ＣＣＭを受信することの障害を示す、ステップ１２０。ＭＥＰ１０１がＲＤＩを受信したとき、ＭＥＰ１０１はＲＤＩ故障状態に入り、ＲＤＩビットが１であるＣＣＭをＭＥＰ１０２に送信して、これらの間のリンクに何らかの故障があることを示す、ステップ１３０。
【０００４】
ＣＣＭおよびＲＤＩは、接続性を調べて監視するために最も重要な要素である。ＭＥＰによって使用されるＣＣＭメッセージのフォーマットは、図２に示されている。「ＭＥＬ」（ＭＥＧ  Ｌｅｖｅｌ）は、ＯＡＭ  ＰＤＵのＭＥＧレベルを識別するために使用される。「Ｖｅｒｓｉｏｎ（バージョン）」は、常に０であるＯＡＭプロトコルのバージョンを識別するために使用される。「ＯｐＣｏｄｅ」は、残りのコンテンツのタイプを識別するために使用され、ＣＣＭのＯｐＣｏｄｅの値は１である。「Ｆｌａｇ（フラグ）」は、ＲＤＩ、および接続性チェックにおいてＣＣＭによって必要とされる他の情報に使用される。「ＴＬＶ  Ｏｆｆｓｅｔ（ＴＬＶオフセット）」は、ＴＬＶオフセットフィールドに対してＯＡＭ  ＰＤＵの中の第１のＴＬＶへのオフセットを含んでおり、ＣＣＭについては７０に設定される。「Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ（シーケンス番号）」は、この勧告ではすべてゼロに設定される。「ＭＥＰ  ＩＤ」は、ＣＣＭフレームを送信しているＭＥＰを識別するために使用され、ＭＥＧ内で一意である。「ＭＥＧ  ＩＤ」は、ＣＣＭフレームを送信しているＭＥＰが所属するＭＥＧを識別するために使用される。「ＴｘＦＣｆ」、「ＴｘＦＣｂ」、「ＲｘＦＣｂ」のそれぞれは、ラップアラウンドのフレームカウンタのサンプルを用いて４オクテットの整数値である。「Ｒｅｓｅｒｖｅｄ（予備）」フィールドは、すべてゼロに設定される。「Ｅｎｄ  ＴＬＶ」は、すべてゼロオクテット値である。
【０００５】
図３に示すフィールド「Ｆｌａｇ」のフォーマットとして、ＲＤＩは、フィールド「Ｆｌａｇ」の第１のビットで示されている。このビットが１である場合、これはリンクに何らかの故障があることを示し、そうでない場合、このビットは０である。「Ｐｅｒｉｏｄ（周期）」は、ＣＣＭフレームを送信しているＭＥＰ１０１で設定されたＣＣＭ送信周期の値を含んでいる。このフィールド「Ｐｅｒｉｏｄ」の値は、「０００」とすることができ、これはＣＣＭメッセージが定期的に送信されないことを意味する。
【０００６】
ユニキャストのシナリオでは、接続性チェックは、上記のポイントツーポイント接続用の接続性チェックプロセスを通じて比較的わかりやすい方法で実行されることが可能である。しかしながら、マルチキャスト、すなわちポイントツーマルチポイントのシナリオでは問題が発生する。マルチキャストのシナリオでは、ルートＭＥＰが、マルチキャストグループに属する故障状態である１つのＭＥＰからＲＤＩを受信すると、ルートＭＥＰはマルチキャストグループの中のリーフＭＥＰのすべてにＲＤＩビットが１であるＣＣＭメッセージを送信する。これによりシステム管理者は、ルートＭＥＰからリーフＭＥＰへの接続のすべてがダウンしているとみなし、その結果リーフＭＥＰのすべてがリーフＭＥＰとルートＭＥＰとの接続がダウンしているとみなし、次いでリーフＭＥＰのすべてがその接続によるデータの伝送ができなくなる。言い換えれば、故障状態ではないルートＭＥＰとリーフＭＥＰの間の接続が、故障状態であるリーフＭＥＰによって遮断されることが問題である。
【０００７】
現在、マルチキャストのシナリオにおける接続性チェックに一般的に使用される解決法は、ポイントツーポイントの接続性チェックのグループを使用し、ルートＭＥＰとそれぞれのリーフＭＥＰの間の各接続の接続性を確認することである。この接続性チェックプロセスでは、ＣＣＭは、リーフＭＥＰのユニキャストＤＡ（宛先ＭＡＣアドレス）を用いて対応するリーフＭＥＰに宛てられる。マルチキャストグループの中でＭＥＰを一意に識別するユニキャストＤＡのユニキャストアドレスは、分岐機構に依存しない。したがって、接続性チェック機構は、すべてのリーフＭＥＰ間で独立している。これは、接続性をチェックするために良い方法である。しかしながら、ポイントツーポイントの接続性チェックを各接続に使用することは非効率的であり、そもそもマルチキャストの目的、すなわち使用できる帯域幅をより大きくし、関連して処理効率をより高くするという目標を覆すものである。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】ＩＥＴＦ  ＲＦＣ４６０４−ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ  Ｇｒｏｕｐ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）、「Ｕｓｉｎｇ  Ｉｎｔｅｒｎｅｔ  Ｇｒｏｕｐ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎ  ３（ＩＧＭＰｖ３）ａｎｄ  Ｍｕｌｔｉｃａｓｔ  Ｌｉｓｔｅｎｅｒ  Ｄｉｓｃｏｖｅｒｙ  Ｐｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎ  ２（ＭＬＤｖ２）ｆｏｒ  Ｓｏｕｒｃｅ−Ｓｐｅｃｉｆｉｃ  Ｍｕｌｔｉｃａｓｔ」
【非特許文献２】ＩＥＥＥ８０２．１ｄ−２００４−Ｃｈａｐｔｅｒ  １０−ＧＭＲＰ（ＧＡＲＰマルチキャストレジスタプロトコル）、「Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ（Ｍａｃ）ｂｒｉｄｇｅ」
【発明の概要】
【発明が解決しようとする課題】
【０００９】
イーサネットマルチキャストのより簡単かつより効率の良い接続性チェックを可能にし、上記の制約および欠点を克服する方法およびシステムを提供することは、当技術分野における前進となる。
【課題を解決するための手段】
【００１０】
以下は、本発明のいくつかの態様の基本的な理解を得られるように、本発明の平易な概要を示すものである。この概要は、本発明の包括的な概要ではない。本発明の主要な要素もしくは決定的な要素を断定すること、または本発明の範囲を明確に示すことを目的とするものではない。次の概要は、以下に提供するさらに詳細な説明への前置きとして簡単な形で本発明の一部の概念を単に表している。
【００１１】
上記の従来の技術における制約を克服するために、また本明細書を読んで理解すると明らかになる他の制約を克服するために、本発明は、イーサネットマルチキャストの接続性チェックのための方法およびシステムに関するものである。
【００１２】
本発明の一実施形態では、イーサネットマルチキャストの接続性チェックのための方法は、マルチキャストＤＡを使用して、ルートＭＥＰからマルチキャストグループの中のすべてのリーフＭＥＰへ接続性チェック機能情報を有するフレームをマルチキャストすること、故障状態であるリーフＭＥＰからルートＭＥＰへ、故障表示情報を有するフレームを送信することと、故障表示情報を有するフレームを受信することに応答して、ルートＭＥＰが、故障状態であるリーフＭＥＰのユニキャストアドレスを使用して、故障状態であるリーフＭＥＰにのみ接続性損失情報を有するフレームを送信することとを含む。
【００１３】
本発明の別の実施形態では、この方法は、故障表示情報を有するフレームを受信すると、ルートＭＥＰがマルチキャストＤＡから故障状態であるリーフＭＥＰのユニキャストアドレスを削除することをさらに含む。
【００１４】
本発明の別の実施形態では、この方法は、ユニキャストアドレスをマルチキャストＤＡから削除した後に、以前のように、マルチキャストＤＡを使用してルートＭＥＰから故障状態であるリーフＭＥＰを除くマルチキャストグループの中のすべてのリーフＭＥＰに、接続性チェック機能情報を有するフレームをマルチキャストすることをさらに含む。
【００１５】
本発明の一実施形態では、イーサネットマルチキャストの接続性チェックのためのシステムは、ルートＭＥＰおよびマルチキャストグループの中の複数のリーフＭＥＰを含む。ルートＭＥＰは、マルチキャストＤＡを使用して、マルチキャストグループの中の複数のリーフＭＥＰのすべてに接続性チェック機能情報を有するフレームをマルチキャストするように構成され、マルチキャストグループの中のリーフＭＥＰから故障表示情報を有するフレームを受信することに応答して、このリーフＭＥＰのユニキャストアドレスを使用して、このリーフＭＥＰにのみ接続性損失情報を有するフレームを送信するように構成された送信機と、故障状態であるリーフＭＥＰから故障表示情報を有するフレームを受信するように構成された受信機とを含む。リーフＭＥＰは、故障状態を検出すると、ルートＭＥＰへ故障表示情報を有するフレームを送信するように構成された送信機と、マルチキャストＤＡを使用して接続性チェック機能情報を有するフレームを、自己のユニキャストアドレスを使用してルートＭＥＰの送信機から接続性損失情報を有するフレームを受信するように構成された受信機とを含む。
【００１６】
本発明の解決法を用いると、マルチキャストによって接続性チェックを行うことが効率的である。さらに、ポイントツーポイントの接続性チェックのグループが利用される従来の技術よりも簡単である。同時に、本発明により、ルートＭＥＰと故障状態であるリーフＭＥＰとの接続は、故障状態ではない他のリーフＭＥＰとルートＭＥＰとの他の接続を遮断しない。さらに、既存のＯＡＭ規格との互換性は、維持されることが可能である。
【００１７】
上記は、以下にさらに詳細に説明する主題への単なる導入であることを当業者は理解するであろう。
【００１８】
添付の図面を参照することによって、本発明はより良く理解され、その多くの目的、特徴、および利点が当業者に明らかにされるであろう。
【図面の簡単な説明】
【００１９】
【図１】従来の技術におけるポイントツーポイント接続用の接続性チェックのプロセスを概略的に示す図である。
【図２】ＣＣＭメッセージの標準化されたフォーマットを示す図である。
【図３】ＲＤＩの標準化されたフォーマットを示す図である。
【図４】本発明の一実施形態によるイーサネットマルチキャストの接続性チェックのためのシステムの概略的な機能ブロックを示す図である。
【図５】本発明の一実施形態によるイーサネットマルチキャストの接続性チェックのための方法を示すシーケンス図である。
【図６】本発明の別の実施形態によるイーサネットマルチキャストの接続性チェックのためのさらなる方法を示す流れ図である。
【発明を実施するための形態】
【００２０】
様々な例示的実施形態の次の説明では、本明細書の一部を形成し、本発明が実行可能である様々な例示的実施形態が実例として示される添付の図面を参照する。他の実施形態が利用されることが可能であり、本発明の範囲を逸脱することなく構造上および機能上の変更が行われることが可能であることを理解されたい。
【００２１】
図４は、本発明が実行可能であるイーサネットマルチキャストシステムの概略的な機能ブロックを示している。このようなイーサネットマルチキャストシステムの構造および機能、ならびに関連するネットワーク要素の構造および機能は、単に本発明に関連して説明される。
【００２２】
システム４００は、例示的実施形態により、複数のリーフＭＥＰ４２０、４３０、および４４０と、ルートＭＥＰ４１０とを含む。ルートＭＥＰ４１０は、ＭＥＰグループに属するリーフＭＥＰのすべてにデータをマルチキャストすることができ、それによって好都合にも、３つ以上のリーフＭＥＰが送信されることになる場合、ルートからリーフまでの帯域幅のリソースを節約する。
【００２３】
ルートＭＥＰ４１０は、送信機４１１および受信機４１２を含み、これらはそれぞれリーフＭＥＰ４２０、４３０、および４４０への接続性チェックプロセスまたはこれらのリーフＭＥＰからの接続性チェックプロセスのために、フレームを送受信するために使用される。送信機４１１および受信機４１２の基本構造および動作は当業者には知られており、本解決法に関連する詳細のみを詳しく説明する。ルートＭＥＰ４１０は、さらに手段４１３を含み、これは送信機４１１および受信機４１２に結合されて、イーサネットマルチキャストの接続性チェックを管理するために使用される。手段４１３の機能は、デジタル信号プロセッサ、メモリ、およびコンピュータプロセスを実行するためのコンピュータプログラムを用いて実行されることが可能である。
【００２４】
リーフＭＥＰ４２０、４３０、４４０の各々は、それぞれ送信機４２１、４３１、４４１と受信機４２２、４３２、４４２とを含み、これらは接続性チェックプロセス用のフレームを、ルートＭＥＰ４１０へ送信するために、またはルートＭＥＰ４１０から受信するために使用される。送信機４２２、４３２、４４２および受信機４２２、４３２、４４２の基本構造および動作は、当業者には知られており、本解決法に関連する詳細のみを詳しく説明する。
【００２５】
次に、図５を参照して、本発明の一実施形態によるイーサネットマルチキャストの接続性チェックプロセスの説明を行う。このプロセスは、システム管理者によって手動でまたは自動的に、開始されることが可能である。ルートＭＥＰ５０１、およびリーフＭＥＰ５０２、５０３、５０４の構造および機能は、図４に示されるシステム４００の中の対応する要素（ルートＭＥＰ４１０、およびリーフＭＥＰ４２０、４３０、４４０）と同じものである。
【００２６】
ステップ５１０では、ルートＭＥＰ５０１が、接続性チェック情報を有するフレーム、すなわちＣＣＭフレームと呼ばれる、ＣＣＭメッセージを搬送するフレームを、マルチキャストグループの中のリーフＭＥＰ５０２、５０３、５０４のすべてにマルチキャストする。好ましくは、ＣＣＭフレームは、定期的に送信されることが可能であり、その周期は、図３を参照して説明するように関連するビットの中で設定されることが可能である。マルチキャスト機構は、イーサネット網の標準的なマルチキャストと同様である。ＣＣＭフレームの簡易化されたフォーマットは、ステップ５１０を示す矢印の上のブロック５１１として示されており、この中でＲＤＩビットは０である。ＣＣＭフレーム５１１は、マルチキャストグループのマルチキャストＤＡを用いてリーフＭＥＰのすべてに宛てられる。
【００２７】
マルチキャストグループの中のリーフＭＥＰ５０２が、故障状態に遭遇したとき、例えばリーフＭＥＰ５０２が３．５周期でＣＣＭフレーム５１１を受信しなかったとき、ステップ５２０に示すように、リーフＭＥＰ５０２はルートＭＥＰ５０１に故障表示情報を有するフレームを送信する。フレームは、好ましくはＣＣＭフレームであり、ＲＤＩビットはリーフＭＥＰ５０２によって１に設定され、リーフＭＥＰ５０２とルートＭＥＰ５０１の間の接続が故障状態であることを示す。ＣＣＭフレームの簡略化されたフォーマットは、ステップ５２０を示す矢印の上のブロック５２１として示されており、この中でリーフＭＥＰ５０２のユニキャストアドレスは、フィールド「Ｓｏｕｒｃｅ」の中に提供されている。
【００２８】
ステップ５３０では、リーフＭＥＰ５０２からＲＤＩ＝１とするＣＣＭフレームを受信することに応答して、ルートＭＥＰ５０１は、接続性損失情報を有するフレームをリーフＭＥＰ５０２へ送信し、ルートＭＥＰ５０１とリーフＭＥＰ５０２の間の接続性が失われたことを確認する。フレームは、好ましくはＣＣＭフレームであり、ＲＤＩビットは１である。ＣＣＭフレームの簡略化されたフォーマットが、ステップ５３０を示す矢印の上のブロック５３１として示されている。ＣＣＭフレーム５３１は、リーフＭＥＰ５０２のユニキャストアドレスを用いてリーフＭＥＰ５０２にのみ宛てられ、他のリーフＭＥＰ５０３、５０４はＣＣＭフレーム５３１を受信しない。
【００２９】
リーフＭＥＰ５０２がＣＣＭフレーム５３１を受信すると、リーフＭＥＰ５０２はルートＭＥＰ５０３からの受信および／またはルートＭＥＰ５０３への送信を停止する。場合によっては、リーフＭＥＰ５０２は、あらかじめ定められた指定により、またはＣＣＭフレーム５３１の中で搬送された追加の指示情報により、保護機構を開始する。
【００３０】
当業者には理解されるように、ルートＭＥＰ５０１およびリーフＭＥＰ５０２、５０３、および５０４は例示的であり、故障状態であるリーフＭＥＰは、マルチキャストグループの中のリーフＭＥＰのいずれでもありうる。故障状態であるリーフＭＥＰの数は、１つに限定されず、考えられるいかなる数でもある。
【００３１】
図６は、本発明の一実施形態によるイーサネットマルチキャストの接続性チェックのためのさらなる方法を示す流れ図である。図６に示すプロセスでは、ステップ６１０、６２０、および６４０は、図５に示す対応するステップ５１０−５３０と同様である。違いは、ルートＭＥＰ５０１が、故障表示情報を有するフレームを受信すると、マルチキャストＤＡから故障状態であるリーフＭＥＰ５０２のユニキャストアドレスを削除することができるという点にある。例えば、ルートＭＥＰの中の手段４１３が、ユニキャストアドレスを抜き出して、これをマルチキャストグループの中のリーフＭＥＰのユニキャストアドレスとマルチキャストＤＡとの間のマッピングに関するリストから削除することができる。好ましくは、この削除は、故障状態であるリーフＭＥＰがマルチキャストグループから抜けるようにすることによって達成されることが可能である。この削除のさらに詳細な説明は、「Ｕｓｉｎｇ  Ｉｎｔｅｒｎｅｔ  Ｇｒｏｕｐ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎ  ３（ＩＧＭＰｖ３）ａｎｄ  Ｍｕｌｔｉｃａｓｔ  Ｌｉｓｔｅｎｅｒ  Ｄｉｓｃｏｖｅｒｙ  Ｐｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎ  ２（ＭＬＤｖ２）ｆｏｒ  Ｓｏｕｒｃｅ−Ｓｐｅｃｉｆｉｃ  Ｍｕｌｔｉｃａｓｔ」というタイトルの、ＩＥＴＦ  ＲＦＣ４６０４−ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ  Ｇｒｏｕｐ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）、および「Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ（Ｍａｃ）ｂｒｉｄｇｅ」というタイトルの、ＩＥＥＥ８０２．１ｄ−２００４−Ｃｈａｐｔｅｒ  １０−ＧＭＲＰ（ＧＡＲＰマルチキャストレジスタプロトコル）の中で提供されており、これらはその全体を参照により本明細書に組み込まれる。
【００３２】
このプロセスはさらに、ステップ６３０の後に実行されるステップ６５０を含むことができる。ステップ６５０では、マルチキャストＤＡからこのユニキャストアドレスを削除した後に、ルートＭＥＰ５０１が、以前のように、すなわちステップ６１０のように、マルチキャストＤＡを使用して、リーフＭＥＰ５０２を除くマルチキャストグループの中のすべてのリーフＭＥＰ５０３、５０４に、接続性チェック機能情報を有するフレームをマルチキャストすることを継続する。このユニキャストアドレスは、マルチキャストＤＡから削除されたので、ＭＥＰ５０２はマルチキャストＤＡを使用してマルチキャストされるフレームを受信しない。ステップ６５０は、ステップ６４０と同時に行われることがあり、行われないこともある。ステップ６５０は、ルートＭＥＰ５０１の中の設定に応じて、ステップ６４０の前に、または後に行われることがある。
【００３３】
本発明の１つまたは複数の態様は、１つまたは複数のプログラムモジュールの中のようなコンピュータで実行可能な命令の中で具体化され、１つまたは複数のコンピュータまたは他の装置によって実行されることが可能である。一般に、プログラムモジュールは、コンピュータまたは他の装置の中でプロセッサによって実行されるとき、本発明の方法ステップを行うルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。コンピュータで実行可能な命令は、ハードディスク、光ディスク、リムーバブル記憶媒体、ソリッドステートメモリ、ＲＡＭなどのコンピュータ可読媒体に格納されることが可能である。当業者には理解されるように、プログラムモジュールの機能は、様々な実施形態で要望通りに結合される、または分散されることが可能である。さらに、機能は、集積回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、および同様のものなど、ファームウェアまたはハードウェア同等物の中の全部にまたは一部に組み入れられることが可能である。
【００３４】
本発明を特定の実施形態を参照して説明したが、この説明は、限定される意味で解釈されることを意図しない。本発明の説明を参照すると、開示した実施形態の様々な変更、ならびに本発明の代替的実施形態が、当業者には明らかになるであろう。したがって、添付の特許請求の範囲は、本発明の範囲内である変更形態、またはその均等物を含むものとする。
【図１】
2011512059.tif 000003
【図２】
2011512059.tif 000004
【図３】
2011512059.tif 000005
【図４】
2011512059.tif 000006
【図５】
2011512059.tif 000007
【図６】
2011512059.tif 000008
【国際調査報告】
2011512059.tif 000009
2011512059.tif 000010