JP2007531356A - モバイルネットワークノードにおける経路最適化マルチキャストトラフィック - Google Patents

Abstract

１つ以上のマルチキャストプロトコルを用いるネットワークにおいてソースからネットワークノードＭＮＮを含むノードのグループＧへとトラフィックを通信する方法に関する。このネットワークはネットワークとインターネットとの間でトラフィックを転送するためのルータＭＲと、ルータＭＲと同じ位置にありインタフェースにてマルチキャストルーティングプロトコルＭＲＰのシグナリングメッセージをグループメンバシッププロトコルＧＭＰのメッセージへ翻訳するマルチキャストシグナリングゲートウェイＭＳＧとを含む。モバイルネットワークの場合、好適にはインタフェースはモバイルルータＭＲの出口インタフェースである。好適にはマルチキャストシグナリングゲートウェイＭＳＧはマルチキャストパケットに加えＩＰｖ４とＩＰｖ６プロトコルとの間のマルチキャストパケットのユニキャストソースアドレス及びマルチキャスト宛先アドレスを翻訳する。

Description

本発明は、モバイルネットワークノードにおいて経路最適化されるマルチキャストトラフィックに関する。

従来のモビリティサポートでは、モバイルホストに対し連続的なインターネット接続性を提供することが目的とされているため、ホストモビリティサポートが提供されている。これに対して、ネットワーク全体がインターネットトポロジへの接続点を変化させる、したがってトポロジにおける到達性を変化させる状況では、ネットワークモビリティサポートが考慮される。そうした移動性のネットワークは、モバイルネットワーク（Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）と呼ばれることがある。

そうしたモバイルネットワークが存在する多くのシナリオがある。多数の例のうちの２つを次に示す：
・パーソナルエリアネットワーク（Ｐｅｒｓｏｎａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）（ＰＡＮ、即ち、個人に装着された幾つかのパーソナルデバイスからなるネットワーク）。ＰＡＮでは、ユーザがショッピングモール内を歩行中、インターネットトポロジへの接続点が変化する。
・バス、電車又は飛行機などの乗物に埋め込まれているネットワーク。このネットワークは、搭乗中、乗員にインターネット接続を提供する。乗員が単一のデバイス（ラップトップコンピュータなど）を用いる場合や、モバイルネットワーク（ＰＡＮなど）を所有する場合（モバイルネットワークを訪問するモバイルネットワーク（即ち、ネストされたモビリティ）の場合）がある。

モバイルネットワークは、モバイルルータ（ＭＲ；Ｍｏｂｉｌｅ Ｒｏｕｔｅｒ）に接続されている１つ以上のＩＰサブネットを形成するノード（いわゆる、モバイルネットワークノード（ＭＮＮ；Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ Ｎｏｄｅ）の組として定義され得る。モバイルネットワーク（ＭＲ及びそのＭＲに接続されている全てのＭＮＮ）は、インターネットの残りの部分に対するユニットとして移動性である。以下で用いるモバイルネットワークの用語は、インターネットドラフト（Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ）の「ｄｒａｆｔ−ｅｒｎｓｔ−ｍｏｎｅｔ−ｔｅｒｍｉｎｏｌｏｇｙ−００．ｔｘｔ」［ティエリ・エルンスト（Ｔｈｉｅｒｒｙ Ｅｒｎｓｔ）、ホン−ヨン・ラッハ（Ｈｏｎｇ−Ｙｏｎ Ｌａｃｈ）、「ネットワークモビリティサポート用語（Ｎｅｔｗｏｒｋ Ｍｏｂｉｌｉｔｙ Ｓｕｐｐｏｒｔ Ｔｅｒｍｉｎｏｌｏｇｙ）」、２００２年２月、作成中］において定義されている。特に、次の用語が定義されている：
・ローカル固定ノード（ＬＦＮ；Ｌｏｃａｌ Ｆｉｘｅｄ Ｎｏｄｅ）：モバイルネットワーク内に常に位置し、接続点を変更しないノード。ＬＦＮはＬＦＨ（ローカル固定ホスト；Ｌｏｃａｌ Ｆｉｘｅｄ Ｈｏｓｔ）又はＬＦＲ（ローカル固定ルータ；Ｌｏｃａｌ Ｆｉｘｅｄ Ｒｏｕｔｅｒ）である。
・ローカルモバイルノード（ＬＭＮ；Ｌｏｃａｌ Ｍｏｂｉｌｅ Ｎｏｄｅ）：モバイルネットワークに属しており、モバイルネットワーク内のリンクから、モバイルネットワーク内又はモバイルネットワーク外の別のリンクへ接続点を変更するモバイルノード（ＬＭＮのホームリンクはモバイルネットワーク内のリンクである）。ＬＭＮはＬＭＨ（ローカルモバイルホスト；Ｌｏｃａｌ Ｍｏｂｉｌｅ Ｈｏｓｔ）又はＬＭＲ（ローカルモバイルルータ；Ｌｏｃａｌ Ｍｏｂｉｌｅ Ｒｏｕｔｅｒ）である。
・訪問モバイルノード（ＶＭＮ；Ｖｉｓｉｔｉｎｇ Ｍｏｂｉｌｅ Ｎｏｄｅ）：モバイルネットワークに属しておらず、モバイルネットワーク外のリンクからモバイルネットワーク内のリンクへ接続点を変更するモバイルノード（ＶＭＮのホームリンクはモバイルネットワーク内のリンクではない）。モバイルネットワーク内のリンクに接続しているＶＭＮはそのリンクに対するアドレスを取得する。ＶＭＮはＶＭＨ（訪問モバイルホスト；Ｖｉｓｉｔｉｎｇ Ｍｏｂｉｌｅ Ｈｏｓｔ）又はＶＭＲ（訪問モバイルルータ；Ｖｉｓｉｔｉｎｇ Ｍｏｂｉｌｅ Ｒｏｕｔｅｒ）である。
・モバイルネットワークプレフィックス（Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ Ｐｒｅｆｉｘ）：インターネットトポロジ内のモバイルネットワークを識別するＩＰアドレスの最初の数ビットからなるビット文字列。モバイルネットワークに属しているノード（即ち、少なくともＭＲ、ＬＦＮ及びＬＭＮ）は、同じＩＰｖ６「ネットワーク識別子」を共有する。単一のモバイルＩＰサブネットでは、モバイルネットワークプレフィックスは、そのサブネットの「ネットワーク識別子」である。
・ＭＲの出口インタフェース（Ｅｇｒｅｓｓ Ｉｎｔｅｒｆａｃｅ）：モバイルネットワークがホームにある場合には、ホームリンクに接続されているインタフェース。モバイルネットワークが余所のネットワークにある場合には、余所のリンクに接続されているインタフェース。
・ＭＲの入口インタフェース（Ｉｎｇｒｅｓｓ Ｉｎｔｅｒｆａｃｅ）：モバイルネットワーク内のリンクに接続されているインタフェース。

モバイルＩＰｖ６仕様のドラフト［ディ．ジョンソン（Ｄ．Ｊｏｈｎｓｏｎ）、シー．パーキンス（Ｃ．Ｐｅｒｋｉｎｓ）、ジェイ．アルコ（Ｊ．Ａｒｋｋｏ）、「ＩＰｖ６におけるモビリティサポート（Ｍｏｂｉｌｉｔｙ Ｓｕｐｐｏｒｔ ｉｎ ＩＰｖ６）」、ｄｒａｆｔ−ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｉｐｖ６−２０．ｔｘｔ、２００３年１月、作成中］では、モバイルノードが移動中にマルチキャストトラフィックを受信する２つの手段、即ち、双方向トンネリング及びリモートサブスクリプションが定義されているが、モバイルネットワークの場合、現在、双方向トンネリングのアプローチのみが予示されている。実際、最も高度な提案ではモバイルルータとそのホームエージェント（Ｈｏｍｅ Ａｇｅｎｔ）との間の双方向トンネリングが用いられており、それによってモバイルネットワークノードのユニキャストトラフィック及びマルチキャストトラフィックが両方向に転送される。特にマルチキャストトラフィックの場合には：
・添付の図面の図１に示すように、ＭＮＮのインバウンドマルチキャストパケット（即ち、ＭＮＮがサブスクライブしたマルチキャストグループＧ宛のマルチキャストパケット−ＭＮＮはマルチキャストレシーバ）は、バックボーンのマルチキャストツリー（ｔｒｅｅ）に沿ってモバイルルータのホームリンクに向けてルーティングされ、それらのマルチキャストパケットをＭＲへのユニキャストトンネルを通じてトンネルさせるＭＲのホームエージェントＨＡによりインターセプトされ、ＭＲにより脱トンネル（ｄｅｔｕｎｎｅｌ）され、モバイルネットワーク内のマルチキャストツリーに沿って転送され、最終的にＭＮＮにより受信される。
・図２に示すように、アウトバウンドパケット（即ち、ＭＮＮによりマルチキャストグループＧへ送信されるマルチキャストパケット−ＭＮＮはマルチキャストソース）はモバイルルータに向けてルーティングされ、ＭＲによりホームエージェントＨＡへ逆トンネル（ｒｅｖｅｒｓｅ−ｔｕｎｎｅｌ）され、そこからマルチキャスト配信ツリーに向けてルーティングされる。

マルチキャスト配信ツリー（バックボーンの）とＭＮＮとの間のマルチキャストパケットはＭＲとＨＡとの間の双方向トンネルを通じる必要があるが、このことは非常に長いパス（ｐａｔｈ）を導入する可能性がある（例として、米国の上空を飛行する飛行機にＭＲが配備されており、そのＨＡがフランス国に位置する場合）ため、この機構ではＭＮＮに対し経路最適化が提供されない。

したがって、ＭＮＮが最適化パスに沿ってマルチキャストトラフィックを受信すること、即ち、ＭＲのホームエージェントＨＡを通じて遷移させる必要なく、モバイルルータの現在位置から又は現在位置へマルチキャストツリーを通じてパケットを配信させることを可能とする手段が必要である。

特許文献１では、「階層レベル型ＩＰマルチキャスト（ＨＬＩＭ；Ｈｉｅｒａｒｃｈｉｃａｌ Ｌｅｖｅｌ−ｂａｓｅｄ ＩＰ Ｍｕｌｔｉｃａｓｔｉｎｇ）」と呼ばれる新規なＩＰマルチキャストルーティングプロトコルが提案されている。ＨＬＩＭは、ホストモビリティ（ＩＰホストの移動）をサポートするのみならず、ネットワークモビリティ（ホストに接続されている又は接続されていないＩＰルータの移動）もサポートすると言われている。特に、ＨＬＩＭは、ネットワークがトポロジにおいて接続点を変更しても、モバイルネットワーク内に位置するソースからレシーバへの最短パスによるマルチキャストトラフィックの配信を維持すると記載されている。しかしながら、ＨＬＩＭは計画的な（ｔａｃｔｉｃａｌ）なネットワーク用に設計されており、極めて特定のネットワークトポロジ（階層ネットワーク）においてのみ動作可能である。インターネットはこれには当てはまらないため、商業用途における適用性は制限される。これに加えて、ＨＬＩＭではトポロジの全ルータがこの新規なプロトコルを用いることが要求されるが、インターネットのマルチキャストモデルは多くのマルチキャストドメイン（異なるパーティが所有する）に基づいており、おそらくは異なるマルチキャストプロトコル（例えば、ＤＶＭＲＰ，ＭＯＳＰＦ，ＰＩＭ−ＳＭ，ＰＩＭ−ＤＭ，ＣＢＴ）を用いているため、インターネットに対しては現実的でない。したがって、ＨＬＩＭでは、モバイルネットワークの内外において用いられるマルチキャストルーティングプロトコルにかかわらず、インターネットにおいてローミングしているモバイルネットワークへのマルチキャストトラフィックの経路最適化配信をサポートする手段は提供されない。

マルチキャスト可能なモバイルルータの現在位置に向かうマルチキャストツリーのブランチ（ｂｒａｎｃｈ）を再構築するために、モバイルルータがモバイルネットワークと訪問ネットワークとのノードの間（ホームネットワークとそのホームエージェントＨＡとを通じるのではなく）でマルチキャストルーティングシグナリングメッセージ（マルチキャストツリーを管理するために用いられる）の交換を用いることは望ましくない。このアプローチは、モバイルネットワーク及び訪問ネットワークの両方の内部で同じマルチキャストルーティングプロトコルが用いられるときかつそのときに限り、適用可能である。上述のように、非常に多数のマルチキャストプロトコルが存在するため、この要求が実際に満たされることはまれである。結果として、このアプローチでは、インターネットにおけるモバイルネットワークの位置にかかわらず、マルチキャストトラフィックの経路最適化配信は不可能である。これに加えて、実際には、訪問ネットワークのセキュリティポリシーにより、一般的に訪問モバイルルータ（異なる機関がモバイルルータを所有する場合がある）など非認可ノードからのルーティングシグナリング（ユニキャスト及びマルチキャスト）の注入は禁止される。

内部的にマルチキャストルーティングプロトコルを用いる代わりに、モバイルネットワークがモバイルネットワーク内の全ルータに「ＩＧＭＰ／ＭＬＤ型マルチキャスト転送」［ビー．フェナー（Ｂ．Ｆｅｎｎｅｒ）、エイチ．ヘー（Ｈ．Ｈｅ）、ノーテル・ネットワークス（Ｎｏｒｔｅｌ Ｎｅｔｗｏｒｋｓ）、ビー．ハーバーマン（Ｂ．Ｈａｂｅｒｍａｎ）、エイチ．サンディック（Ｈ．Ｓａｎｄｉｃｋ）、「ＩＧＭＰ／ＭＬＤ型マルチキャスト転送；ＩＧＭＰ／ＭＬＤ−ｂａｓｅｄ Ｍｕｌｔｉｃａｓｔ Ｆｏｒｗａｒｄｉｎｇ（「ＩＧＭＰ／ＭＬＤプロクシ；ＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙｉｎｇ」）」、ｄｒａｆｔ−ｉｅｔｆ−ｍａｇｍａ−ｉｇｍｐ−ｐｒｏｘｙ−０２．ｔｘｔ、２００３年３月、作成中］と呼ばれる機構を配備することが提案されている。このアプローチでは、モバイルルータがそのモバイルネットワーク内から到達する全てのマルチキャストグループメンバシップ情報を収集し、訪問ドメイン内のマルチキャスト可能アクセスルータによるＩＧＭＰ／ＭＬＤを用いて、それらの全てのマルチキャストグループへ、そのモバイルルータ自身をサブスクライブすることを可能とすることが意図されている。グループメンバシップ情報は、その親ルータに対して受信される着信ＩＧＭＰ／ＭＬＤ報告（Ｒｅｐｏｒｔ）メッセージを代理する全ての中間固定ルータにより、意図されるマルチキャストレシーバからモバイルルータまで、モバイルネットワーク内でホップ毎に交換される。このアプローチでは、モバイルルータはモバイルネットワークの全ノードの代わりに訪問ドメインのマルチキャストサブスクリプションを処理する。移動があると、新たな接続点にＭＬＤ報告を送信することにより、新たな位置における新たなマルチキャストブランチの再構築がトリガされる。しかしながら、このアプローチでは、特に、モバイルネットワークの各ルータに対するアップストリーム及びダウンストリームのインタフェースを定義して、内部トポロジをモバイルルータにてルーティングされるツリーのようにするために、過重な手動設定が必要となる。このため、このアプローチは、安定な内部トポロジを有する比較的小さいモバイルネットワークに対してしか適用可能でない。これに加えて、各内部ルータに対して新規な転送機構（ＩＧＭＰ／ＭＬＤプロクシ）の配備を強制し、モバイルネットワークに配備される他の形式のマルチキャストルーティングにおいてはマルチキャストトラフィックの経路最適化配信がサポートされない。これは特に、通常のマルチキャストルーティングプロトコルを配備してモバイルネットワーク内のマルチキャストサポートを容易とすることが期待される大きなモバイルネットワークにおいては、制限となる。

したがって、モバイルネットワークからの又はモバイルネットワークへのマルチキャストトラフィックの経路最適化配信を可能とする機構が必要である。この機構は：
・インターネットにおけるモバイルネットワークの位置にかかわらない。
・モバイルネットワークの内外で用いられるマルチキャストルーティングプロトコルの種類にかかわらない。
・モバイルルータのみを伴う拡張による。即ち、モバイルネットワークにおいてもインターネットにおいてもノードには変化がない。
米国特許出願公開第２００２／０１５００９４号明細書

本発明により、添付の特許請求の範囲に記載のように、１つ以上のマルチキャストプロトコルを用いるモバイルネットワークにおいて、ソースから、モバイルネットワークノード（ＭＮＮ）を含むノードのグループへトラフィックを通信する方法と、そうした方法に用いるための装置とを提供する。

添付の図面の図３〜５に示す本発明の実施形態では、次の一定の主要な利点を提示する、マルチキャストトラフィックの大幅な経路最適化が提供される：
・パケットが最短パスにより送信されるため、遅延時間は極小である。多くのマルチキャストアプリケーションは遅延時間に関して厳密な要件を有するため、このことは重要である（例えば、音声／映像ストリーミング、音声／映像コンファレンシング）。
・パケットが最短パスに沿って送信されるため、輻輳によるパケット損失の確率は低下する。リアルタイムマルチキャストアプリケーションにおいても、このことによりレシーバ側でのストリーム品質が向上する。
・スケーラビリティ及びロバスト性の向上。モバイルルータのホームエージェントＨＡはマルチキャストトラフィックが集中するために過負荷となり易いが、この点をバイパスすることにより、経路最適化によって故障の確率が低下する。
・パケットがトンネルされないため、帯域幅オーバヘッドは低下する。これにより、ネットワーク資源の最適化が補助される。
・ＭＮＮ−ＣＮパスにおけるＰＭＴＵ（パス最大伝送単位）の極大化により、ペイロード断片化は極小となることが保証される。

図３に示す本発明の実施形態は、モバイルルータと同じ位置に存在し、かつ、ＭＳＧ可能ネットワークインタフェースを有し、インターネットにおけるモバイルネットワークの位置にかかわらず、またモバイルネットワークの内外で用いられるマルチキャストルーティングプロトコルにかかわらず、モバイルネットワークへのマルチキャストトラフィックの経路最適化配信を達成するためのマルチキャストシグナリングゲートウェイ（ＭＳＧ；Ｍｕｌｔｉｃａｓｔ Ｓｉｇｎａｌｌｉｎｇ Ｇａｔｅｗａｙ）を含む。

このＭＳＧの主要原理は、マルチキャストルーティングプロトコル（ＭＲＰ）のメッセージをグループメンバシッププロトコル（ＧＭＰ）のメッセージへと翻訳することである。このＭＳＧの機能が、ＧＭＰメッセージのＭＲＰメッセージへの翻訳を含め、ＭＲＰ及びＧＭＰプロトコルが相互運用される既知の方法とは全く異なることは認められるであろう。

以下に詳細に示すように、ＭＳＧがＧＭＰメッセージを生成することが可能な１つの方法は、それらのＧＭＰプロトコルにより提供される、いわゆる「サービスインタフェース」を用いることである。「サービスインタフェース」は上位レイヤプロトコル、即ち、アプリケーションプログラムにより用いられ、ＩＰレイヤに対し、特定のＩＰマルチキャストアドレスへ送信される（随意では、所与のソースの組からのみ）パケットの受信を可能また不能とするように要求することが可能である。このサービスインタフェースは機能呼出として理解することが可能であり、通常、ソケットＡＰＩレベルにて利用可能とされる。これは、ＩＰｖ４（ＩＧＭＰ）及びＩＰｖ６（ＭＬＤ）の両方で利用可能である。

マルチキャストルーティングプロトコル（ＭＲＰ）はマルチキャスト配信ツリーの構築を担うプロトコルであり、例えば、ＤＶＭＲＰ，ＭＯＳＰＦ，ＰＩＭ−ＳＭ，ＰＩＭ−ＤＭ，ＣＢＴなどである。基本的には、マルチキャストルーティングプロトコルは２つのファミリーに区別される：
・明示的シグナリングを用いてマルチキャストツリーを構築するプロトコル：これらのプロトコルでは、レシーバのマルチキャストルータが自身に向かうマルチキャスト配信ブランチの確立をトリガするために用いる、特定のメッセージが定義される。ＰＩＭ−ＳＭはそうしたプロトコルの一例である。これらのメッセージは２つの主なカテゴリに分けられる：
「グループ参加（Ｊｏｉｎ ｇｒｏｕｐ）」：マルチキャスト配信ツリーに参加するためにマルチキャストルータが用いるメッセージ。ＰＩＭ−ＳＭ参加（ＰＩＭ−ＳＭ Ｊｏｉｎ）は、こうしたメッセージの一例である。
「グループ離脱（Ｌｅａｖｅ ｇｒｏｕｐ）」：マルチキャスト配信ツリーを離脱するためにマルチキャストルータが用いるメッセージ。ＰＩＭ−ＳＭ剪定（ＰＩＭ−ＳＭ Ｐｒｕｎｅ）は、こうしたメッセージの一例である。
・フラッディングを用いるプロトコル：これらのプロトコルでは、レシーバのマルチキャストルータがマルチキャスト配信ツリーに参加するために用いる特定のメッセージが必ずしも定義されない。反対に、マルチキャストソースにより送信されるパケットはネットワーク全体にフラッディングされ、任意の対象のノードにリッスン（ｌｉｓｔｅｎ）される。しかしながら、このカテゴリの既存のプロトコルのうちのほとんどは明示的シグナリングを備えており、ブランチを「剪定（ｐｒｕｎｅ）」して、対象のレシーバが存在しないネットワークの領域を通じるマルチキャストトラフィックの配信を停止することが可能である。また、それらのプロトコルでは、新たなレシーバが登場した場合にブランチを「接木する（ｇｒａｆｔｉｎｇ）」こともサポートされている。ＰＩＭ−ＤＭはこうしたプロトコルの一例である。

グループメンバシッププロトコル（ＧＭＰ）は、マルチキャストレシーバがマルチキャストグループＧへ送信されるマルチキャストパケットを受信する際、その対象を告知することを可能とするプロトコルである。ＩＰｖ４におけるインターネットグループ管理プロトコル（ＩＧＭＰ）や、ＩＰｖ６におけるマルチキャストリスナー探索プロトコル（ＭＬＤ）はＧＭＰである。なお、ＩＧＭＰｖ３［ビー．カイン（Ｂ．Ｃａｉｎ）、エス．ディーリング（Ｓ．Ｄｅｅｒｉｎｇ）、ビー．フェナー（Ｂ．Ｆｅｎｎｅｒ）、アイ．コウベラス（Ｉ．Ｋｏｕｖｅｌａｓ）、エイ．ティヤガラジャン（Ａ．Ｔｈｙａｇａｒａｊａｎ）、ＲＦＣ３３７６、「インターネットグループ管理プロトコルバージョン３（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ，Ｖｅｒｓｉｏｎ ３）」、２００２年５月］や、ＭＬＤｖ２［アール．ヴィダ（Ｒ．Ｖｉｄａ）、エル．コスタ（Ｌ．Ｃｏｓｔａ）、「ＩＰｖ６におけるマルチキャストリスナー探索バージョン２（Ｍｕｌｔｉｃａｓｔ Ｌｉｓｔｎｅｒ Ｄｉｓｃｏｖｅｒｙ Ｖｅｒｓｉｏｎ２（ＭＬＤｖ２）ｆｏｒ ＩＰｖ６）」、ｄｒａｆｔ−ｖｉｄａ−ｍｌｄ−ｖ２−０６．ｔｘｔ、２００２年１１月、作成中］など、これらのプロトコルの最近のバージョンでは、以前のバージョンと比較して「ソースフィルタリング」のサポートが追加されている。これは、レシーバがマルチキャストアドレスへの送信パケットを、特定のソースアドレスからのみ、または、特定のソースアドレス以外の全てからリッスンすることを報告する機能を表す。

「ＭＳＧ可能ネットワークインタフェース」とは、マルチキャストルーティングプロトコルを用い、マルチキャストシグナリングゲートウェイが有効化されているノードのネットワークインタフェースを意味する。１つのノードが同時に幾つかのＭＳＧ可能ネットワークインタフェースを有する場合もある。モバイルルータの場合、グループメンバシッププロトコルにより、モバイルネットワーク内外のマルチキャストルーティングプロトコルの間の相互作用を達成するには、全ての出口インタフェースがＭＳＧ可能である必要がある。

図３には例として、単一の出口インタフェースを備えるモバイルルータ（ＭＲ）の場合のＭＳＧの使用を示す。マルチキャストルーティングプロトコルＭＲＰ＃１がモバイルネットワーク内で用いられている。ＭＲは、異なるマルチキャストルーティングプロトコルＭＲＰ＃２を用いる訪問ネットワークに接続されている。ＭＲＰ＃１、ＭＲＰ＃２の両方は「明示的シグナリング」ファミリの一部であると仮定する。また、モバイルネットワーク及び訪問ネットワークの両方において、ＩＰｖ６を仮定する。ＩＰｖ６状況のため、グループメンバシッププロトコル（ＧＭＰ）はＭＬＤである。ＭＲの出口インタフェースにおいてＭＳＧが可能である。

モバイルネットワーク内のノードＭＮＮは、マルチキャストグループＧへサブスクライブするとき、自身のローカルマルチキャストルータＬＦＲ１に向けてグループメンバシッププロトコルのＭＬＤ＿Ｒｅｐｏｒｔ（Ｇ）メッセージを送信する。まだＬＦＲ１はグループＧのマルチキャストツリーに接続されていないため（ＭＮＮはＬＦＲ１より下の、グループＧの第１のレシーバであると仮定する）、ＬＦＲ１はモバイルネットワーク内にマルチキャストルーティングプロトコル＃１の明示的なＭＲＰ＃１＿Ｊｏｉｎ（Ｇ）メッセージを送信し、ＬＦＲ１に向かう配信ブランチの確立をトリガする。このブランチ確立リクエストがモバイルネットワーク内に伝搬し、最終的にモバイルルータまで伝搬すると、そのモバイルルータのＭＲＰ＃１プロトコルのローカルインスタンスは出口インタフェースに向けてＭＲＰ＃１＿Ｊｏｉｎ（Ｇ）を発行することを決定する。このインタフェースはＭＳＧ可能であるため、ＭＲは代わりに訪問ネットワークのアクセスルータ（ＡＲ）に向けてグループメンバシッププロトコルのＭＬＤ＿Ｒｅｐｏｒｔ（Ｇ）メッセージを発行する。これにより、グループＧのマルチキャスト配信ツリーに向けて訪問ネットワーク内を伝搬するマルチキャストルーティングプロトコル＃２のＭＲＰ＃２＿Ｊｏｉｎ（Ｇ）メッセージが生じる。これらの動作から、モバイルルータにより相互接続される２つのマルチキャスト配信ブランチ（各マルチキャストドメインに１つ）の生成が可能となる。結果として、グループＧへ送信されるマルチキャストパケット（例えば、ソースＳからの）は、訪問ネットワークにおいてＭＲに向けてルーティングされるＭＲＰ＃２ネイティブなマルチキャストと、そこからＭＮＮに向けてルーティングされるＭＲＰ＃１ネイティブなマルチキャストとである。

ＭＳＧ可能モバイルルータＭＲは、モバイルネットワークの全ノードに代わり、訪問ドメインのマルチキャストサブスクリプションを処理する。ＭＳＧはモバイルネットワーク内より到達するＭＲＰメッセージから、自動的にサブスクリプション情報（即ち、対象のソースのグループ及びリスト）を探索する。ＭＲは、訪問ネットワーク（又はインターネット）への接続点を変更するとき、サブスクライブしたマルチキャストグループの新たな接続点に対しＭＬＤ報告を送信することにより、新たな位置にて１つ以上の新たなマルチキャストブランチの再構築をトリガする。このことはリモートサブスクリプション（Ｒｅｍｏｔｅ Ｓｕｂｓｃｒｉｐｔｉｏｎ）として言及されている。

図４は、ＭＳＧをホストするノードのネットワークインタフェースｉｆｃ＿ｉを通じて送信されようとしているマルチキャストルーティングプロトコルメッセージ（ＭＲＰメッセージ）を検出するとき、本発明の一実施形態のマルチキャストシグナリングゲートウェイ（ＭＳＧ）により開始される動作のフローチャートである。

インタフェースｉｆｃ＿ｉがＭＳＧ可能でない場合、ＭＳＧは単にメッセージを無視する。
インタフェースｉｆｃ＿ｉがＭＳＧ可能である場合、ＭＲＰメッセージは次のことを判定するために解析される：
・ＭＲＰメッセージのクラス：このクラスはＭＲＰメッセージの種類（又は、マルチキャスト配信ツリーに対するその影響）に応じて、次の３つの値｛ＪＯＩＮ，ＬＥＡＶＥ，ＮＯＮＥ｝のうちの１つを取る。ＭＲＰのいずれのメッセージにも、これらの３つの値のうちの１つが割り当てられる。この情報は、所与のマルチキャストルーティングプロトコルのメッセージをクラス分類する目的でＭＳＧにより用いられる、クラステーブルと呼ぶテーブルに格納される。
・ＭＲＰメッセージのターゲット：ターゲットはメッセージの参照するマルチキャストグループＧと、おそらくはソースＳのアドレスとから構成される。ソースアドレスが存在しない場合、パケットが任意のソースを表し得ることを意味している。この場合、Ｓ＝＊、のように、ワイルドカード記号「＊」を用いて全てのソースを表す。ターゲットは、カップル（Ｓ，Ｇ）や、ソース特定の情報が伝達されない場合には（＊，Ｇ）のように表現される。

ＭＲＰメッセージのクラスがＮＯＮＥの場合、このパケットのＭＳＧに特定の動作は必要ない。通常、このことは、ＭＳＧの両側のマルチキャストプロトコルの間の相互作用を実現する目的でＧＭＰプロトコルメッセージへの翻訳が必要なセマンティックを、パケットが有しないことを意味している。

ＭＲＰメッセージのクラスがＪＯＩＮの場合、インタフェースｉｆｃ＿ｉのＭＳＧにより保持されるグループＧ（ターゲットからの）のソースの既存のリスト：ＭＳＧ＿ｓｒｃｌｉｓｔ（ｉｆｃ＿ｉ，Ｇ）へ、ソースＳ（ターゲットからの）を追加する必要がある。これは、ＭＳＧがインタフェースｉｆｃ＿ｉを通じるトラフィックの受信を維持する必要があるグループＧのソースのリストである。この目的で、ＭＳＧは、各ＭＳＧ可能インタフェースに対して対象のグループのリストと共にそのそれぞれのソースのリストを含む、グループリストと呼ぶリストを維持する必要がある。グループリストは図５に示す。ターゲットからのソースＳによりＭＳＧ＿ｓｒｃｌｉｓｔ（ｉｆｃ＿ｉ，Ｇ）が更新される（又は、新たなエントリの場合には、作成される）と、このＳの追加によりＭＳＧ＿ｓｒｃｌｉｓｔ（ｉｆｃ＿ｉ，Ｇ）が変更されたか否かが検査される。ＭＳＧ＿ｓｒｃｌｉｓｔ（ｉｆｃ＿ｉ，Ｇ）が変更されていない場合、動作は必要ない。また、ＭＳＧ＿ｓｒｃｌｉｓｔ（ｉｆｃ＿ｉ，Ｇ）が変化した場合、ＭＳＧはインタフェースｉｆｃ＿ｉにおいてこのグループＧのソースの新たな組のＧＭＰサブスクリプションを更新する必要がある。任意の他のマルチキャストアプリケーションが行うように、この目的で、ＭＳＧはＧＭＰ「サービスインタフェース」（即ち、ＡＰＩ）を用いることが可能である。

ＭＲＰメッセージのクラスがＬＥＡＶＥの場合、インタフェースｉｆｃ＿ｉのＭＳＧにより保持されるグループＧ（ターゲットからの）のソースの既存のリスト：ＭＳＧ＿ｓｒｃｌｉｓｔ（ｉｆｃ＿ｉ，Ｇ）から、ソースＳ（ターゲットからの）を除去する必要がある。ＭＳＧ＿ｓｒｃｌｉｓｔ（ｉｆｃ＿ｉ，Ｇ）が更新されると、このＳの除去によりＭＳＧ＿ｓｒｃｌｉｓｔ（ｉｆｃ＿ｉ，Ｇ）が変更されたか否かが検査される。ＭＳＧ＿ｓｒｃｌｉｓｔ（ｉｆｃ＿ｉ，Ｇ）が変更されていない場合、動作は必要ない。また、ＭＳＧ＿ｓｒｃｌｉｓｔ（ｉｆｃ＿ｉ，Ｇ）が変化し、現在、空である場合、ＭＳＧはインタフェースｉｆｃ＿ｉにおいてグループＧへのＧＭＰサブスクリプションを中断する。これに加えて、ＭＳＧがｉｆｃ＿ｉのグループリストにおけるグループＧのエントリを除去してもよい。更新されたＭＳＧ＿ｓｒｃｌｉｓｔ（ｉｆｃ＿ｉ，Ｇ）が空でない場合、ＭＳＧはインタフェースｉｆｃ＿ｉにおいてこのグループＧのソースの新たな組のＧＭＰサブスクリプションを更新する必要がある。任意の他のマルチキャストアプリケーションが行うように、この目的で、ＭＳＧはＧＭＰ「サービスインタフェース」（即ち、ＡＰＩ）を用いることが可能である。

ソース（Ｓ又は＊）をソースリストＭＳＧ＿ｓｒｃｌｉｓｔ（ｉｆｃ＿ｉ，Ｇ）へ追加する（＋）又はＭＳＧ＿ｓｒｃｌｉｓｔ（ｉｆｃ＿ｉ，Ｇ）から除去する（−）場合、次の算法が用いられ得る：
・ソースはリストに一度しか登場しない：Ｓ＋Ｓ＝Ｓ，Ｓ−Ｓ＝φ
・全ソース（＊）をリストに追加すると、そのリストは全ソースを含む：ｓｒｃｌｉｓｔ＋＊＝＊（当然のことながら、＊＋＊＝＊）
・全ソース（＊）をリストから除去すると、そのリストは空（φ）になる：ｓｒｃｌｉｓｔ−＊＝φ（特に、＊−＊＝φ）
・全ソース（＊）を含むリストから既定のソースＳを除去しても、そのリストは変化しない：＊−Ｓ＝＊。

図５にはＭＳＧにより保持されるグループリストの一例を示す。次のテーブルには、ＰＩＭ−ＳＭマルチキャストルーティングプロトコルにおいてＭＳＧにより用いられ得るクラステーブルを示す。ＭＳＧにより用いられる任意のマルチキャストルーティングプロトコル（明示的シグナリングを備える）において、同様のクラステーブルが確立され得る。

ＭＳＧ可能ノードにおけるマルチキャストパケットの転送は非常に単純であり、実際、ＭＳＧに対して透明性である。マルチキャストパケットの転送は、ＭＳＧ可能ノードにより用いられるＭＲＰプロトコルに関するマルチキャスト転送テーブルに従って行われる。着信インタフェースがＭＳＧ可能であるか否かにかかわらず、このことは真である。

特に、モバイルネットワークの場合には、モバイルネットワークの外部のソース（即ち、ＭＳＧ可能インタフェースを通じてサブスクライブされている）からのマルチキャストパケットは、ＭＲのローカルマルチキャスト転送テーブルに従って、ＭＲの出口インタフェース（ＭＳＧ可能）に向けてマルチキャストルーティングされ、そこからモバイルネットワーク内にマルチキャストルーティングされる。

モバイルルータ（ＭＲ）のＭＳＧ可能インタフェースが訪問ネットワーク（又はインターネット）への接続点を変更するとき、ＭＳＧは、ＧＭＰ報告メッセージを送信してＭＳＧ可能インタフェースのグループリストに一覧されているマルチキャストグループ（及びそれぞれのソース）にサブスクライブすることにより、新たな位置において必要なマルチキャストブランチの再構築をトリガする。

所与の出口インタフェースがホームにあるモバイルルータ（ＭＲ）は、このインタフェースをＭＳＧ可能として構成する又は構成しないと決定することが可能である。選択された選択肢にかかわらず、マルチキャストトラフィックは同じようにＭＮＮへルーティングされる（ＭＲのローカルマルチキャスト転送テーブルに従って）。しかしながら、ホームにある場合にもインタフェースをＭＳＧ可能として構成することにより、インタフェースが別のトポロジ位置に接続する場合にも、進行中のマルチキャスト通信を保持することが可能となる。これは、ＭＳＧが進行中のグループＧのリスト（及び関連のソース）を学習し、新たな位置にてそれらに再サブスクライブすることが可能となるためである。

モバイルルータ（ＭＲ）のＭＳＧ可能インタフェースがホームに戻り、モバイルルータ（ＭＲ）がこのインタフェースにおいてＭＳＧを無効化すると決定する場合、マルチキャストルーティングプロトコルは、通常、このインタフェースを通じてホームネットワークに向けて動作する。そうした場合、ＭＳＧはその所与のインタフェースのグループリストにおいて、任意の状態を除去してよい。

マルチキャストシグナリングゲートウェイ（ＭＳＧ）の実装において、幾つかの手法を取ることが可能である。詳細には、例えば、１）別個のソフトウェアモジュールとして、又は、２）マルチキャストルーティングプロトコル（ＭＲＰ）実装の拡張（パッチ）として、実装される。

両方の場合において、この本発明の実施形態では、既存のＧＭＰ「サービスインタフェース」：ＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ（ソケット，インタフェース，マルチキャストアドレス，フィルタモード，ソースリスト）を用いることにより、グループメンバシッププロトコルに向けたＭＳＧインタフェース（ＭＳＧ−ＧＭＰインタフェース）が実装され得る。

このアプローチでは、任意のマルチキャストアプリケーションプログラムのするのと同じように（例えば、ＧＭＰ可能ソケットＡＰＩを通じて）、ＭＳＧはＩＰレイヤ（ＧＭＰ）に対し、特定のＩＰマルチキャストアドレスへ送信されるパケットの受信を可能また不能とするように要求する。上述のサービスインタフェースに基づく実装は、２つの異なった手法により実現され得る：
ａ）ＭＳＧソフトウェアは所与のマルチキャストグループ（ＭＳＧ＿ｓｒｃｌｉｓｔ（ｉｆｃ＿ｉ，Ｇ））のソースの集合を処理し、単一のソケット識別子（ｓｉｄ）を用いて全リストを渡す：
ＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ（ｓｉｄ，ｉｆｃ＿ｉ，Ｇ，ＩＮＣＬＵＤＥ，ＭＳＧ＿ｓｒｃｌｉｓｔ（ｉｆｃ＿ｉ，Ｇ））、又は、
ＭＳＧ＿ｓｒｃｌｉｓｔ（ｉｆｃ＿ｉ，Ｇ）＝＝＊の場合、ＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ（ｓｉｄ，ｉｆｃ＿ｉ，Ｇ，ＥＸＣＬＵＤＥ，｛｝）
ｂ）ＭＳＧソフトウェアは幾つかのソケットｉｄ（（Ｓ，Ｇ）ターゲット毎に１つ）を用い、所与のマルチキャストグループのソースの集合を担うＭＬＤモジュールへ、それぞれのターゲット（Ｓ，Ｇ）と、ＭＲＰメッセージから導出される関連するクラスとを渡す。所与のターゲット（Ｓ，Ｇ）において：
・クラスがＪＯＩＮの場合：
ＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ（ｔａｒｇｅｔ＿ｓｉｄ，ｉｆｃ＿ｉ，Ｇ，ＩＮＣＬＵＤＥ，Ｓ）、又は、
Ｓ＝＝＊の場合、ＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ（ｔａｒｇｅｔ＿ｓｉｄ，ｉｆｃ＿ｉ，Ｇ，ＥＸＣＬＵＤＥ，｛｝）
・クラスがＬＥＡＶＥの場合：
ＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ（ｔａｒｇｅｔ＿ｓｉｄ，ｉｆｃ＿ｉ，Ｇ，ＥＸＣＬＵＤＥ，Ｓ）、又は、
Ｓ＝＝＊の場合、ＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ（ｔａｒｇｅｔ＿ｓｉｄ，ｉｆｃ＿ｉ，Ｇ，ＩＮＣＬＵＤＥ，｛｝）
この第２のアプローチには、ＭＳＧソフトウェアがターゲット毎にユニークなｔａｒｇｅｔ＿ｓｉｄを生成し、それをＭＳＧグループリストに格納する必要がある。

マルチキャストルーティングプロトコル（ＭＲＰ）に向けたＭＳＧ−ＭＲＰインタフェースの実装は、アプローチ１），２）のいずれが選択されるかによる。このインタフェースの目的は、ＭＳＧが「インタフェースｉｆｃ＿ｉにおける送信準備の完了しているＭＲＰメッセージ」（図４のＭＳＧ状態機械を参照）を検出し、ＭＳＧ動作をトリガすることである。
・アプローチ１）：独立のソフトウェアモジュールであるＭＳＧは、インタフェースｉｆｃ＿ｉを通じて送信されるパケットを監視することにより、ＭＲＰメッセージを検出することが可能である。
・アプローチ２）：ＭＳＧ動作はＭＲＰプロトコル実装により直接的にトリガされることが可能である。例えば、ＭＳＧ可能インタフェースｉｆｃ＿ｉを通じてＭＲＰメッセージを送信する代わりに、ＭＳＧパッチされたＭＲＰ実装により、正しいクラス及びターゲット情報によるＭＳＧ手続が呼び出される。

アプローチ１）では、ＭＳＧはＭＲＰから完全に独立であり、結果として、対応するクラステーブルが認識されている限り任意のＭＲＰにおいて用いられてよい。このことによりソフトウェアの再利用が容易となる。

アプローチ２）では、ＭＳＧソフトウェアはＭＳＧ可能ノードのＭＲＰ実装に組み込まれている。このことにより、例えば、ＭＳＧ動作のトリガの必要があるときを検出するための、より効率的な実装が提供され得る。

マルチキャストシグナリングゲートウェイ（ＭＳＧ）はモバイルネットワークへのマルチキャストパケットの経路最適化配信を可能とする一方、他の種類の問題を解決するための非常に有用なアプローチでもある。以下は、ＭＳＧの他の用途の２つの例である：
・高速マルチキャストドメイン相互接続用ＭＳＧ：例えば、相互接続マルチキャストバックボーンの故障の場合、２つの固定リーフ（ｌｅａｆ）マルチキャストドメインの間の一時的な相互作用点としてＭＳＧが用いられる。したがってＭＳＧにより、ネットワーク管理者の配備用の高速かつ容易である、一時的な故障回復法が提供される。
・ＩＰｖ４／ＩＰｖ６遷移用ＭＳＧ：ＭＳＧにより、ＩＰｖ４及びＩＰｖ６マルチキャストクラウド（ｃｌｏｕｄ）を相互接続する非常に簡便なアプローチが提供される。ＩＰｖ６レシーバはＩＰｖ４ソースからマルチキャストトラフィックを受信することが可能であり、反対に、ＩＰｖ４レシーバはＩＰｖ６ソースからマルチキャストトラフィックを受信することが可能である。ＩＰｖ４及びＩＰｖ６プロトコルは、全ＩＰｖ４から全ＩＰｖ６への遷移段階が完了するまでの比較的長期に渡り共存すると予示されることを考慮すると、この事例は非常に重要な使用例である。この目的のため、ＭＳＧはマルチキャストパケット（マルチキャストパケットのユニキャスト送信元アドレス及びマルチキャスト宛先アドレスと共に）をＩＰｖ４からＩＰｖ６へと、また反対に、ＩＰｖ６からＩＰｖ４へと翻訳する必要がある。ＩＰｖ４／ＩＰｖ６翻訳用の既知の機構のほとんどは、ユニキャストトラフィックにしか適用されない。ＩＰｖ４及びＩＰｖ６ドメインの間のマルチキャストパケット転送（及びその反対）を実現するためのＩＰｖ４−ＩＰｖ６プロトコルトランスレータ及びアドレスマッパを特徴とする、マルチキャストトラフィック用の機構に関する提案がなされている［ケイ．ツチヤ（Ｋ．Ｔｓｕｃｈｉｙａ）ら、「ＩＧＭＰ／ＭＬＤプロクシ（ｍｔｐ）に基づくＩＰｖ６／ＩＰｖ４マルチキャストトランスレータ（Ａｎ ＩＰｖ６／ＩＰｖ４ Ｍｕｌｔｉｃａｓｔ Ｔｒａｎｓｌａｔｏｒ ｂａｓｅｄ ｏｎ ＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙｉｎｇ（ｍｔｐ））」、ｄｒａｆｔ−ｔｓｉｃｈｉｙａ−ｍｔｐ−０１．ｔｘｔ、２００３年２月、作成中］。しかしながら、この提案では、所与のＩＰｖ４（それぞれにＩＰｖ６）マルチキャストアドレスの組のトラフィックを転送するために、トランスレータが手動で予め設定される（ネットワーク管理者により）必要がある。この設定中、関連するトラフィックを受信することを可能とするために、トランスレータはそれらの予め設定されたグループの全てに参加する。この機構は、新たなマルチキャストグループの翻訳が必要となる毎に人の介入が要求されるため、明らかに効率的でない。ＭＳＧ（ＩＰｖ４−ＩＰｖ６ヘッダトランスレータ及びアドレスマッパにより拡張されている）は、ＩＰｖ６（それぞれにＩＰｖ４）ドメインにより必要とされる場合にのみＭＳＧにてＩＰｖ４（それぞれにＩＰｖ６）マルチキャストトラフィックの受信を動的にトリガすることにより、この問題を解決する。

そうしたＭＳＧ可能モバイルルータの使用により、ＩＰｖ６（それぞれにＩＰｖ４）モバイルネットワークがＩＰｖ４訪問ネットワーク（それぞれにＩＰｖ６）にローミングし、この訪問ネットワークからマルチキャストトラフィックを受信することが可能となることに留意されたい。

上述の本発明の実施形態により幾つかの有利な特徴が提供されることは認められるであろう。例えば：
・インターネットにおけるモバイルネットワークの位置にかかわらず、最適パスに沿ってＭＮＮへのマルチキャストトラフィックの配信を可能とする手段。
・ＭＮＮに対して透明性であるマルチキャストトラフィックの経路最適化：ＭＮＮにおける変更は不要であり、基本的な非モビリティ認知ＬＦＮも経路最適化から利益を得る（例えば、車中の基本的な電子デバイス）。単独のＭＲにより経路最適化が達成される。
・ネストされたモバイルネットワーク（即ち、別のモバイルネットワークを訪問するモバイルネットワーク）の集合におけるレベルの数にかかわらない、ネストされたモバイルネットワークのマルチキャストトラフィックの経路最適化配信。
・モバイルネットワークの場合に適用可能なリモートサブスクリプションアプローチに基づくモバイルマルチキャストホストのシームレスモビリティの機構。

上述の特徴は、モバイルルータと同じ位置に存在しマルチキャストパケットの経路最適化配信を可能とする場合、既存のマルチキャストルーティングプロトコルに対する変更なしで適用可能である。

これに加えて、ＭＳＧは：
・ＩＰｖ４／ＩＰｖ６トランスレータなど他のシナリオに適用可能である。
・実装が非常に簡単である。
・ネットワークの他のノードにおける既存のプロトコルに対しても拡張に対しても変更が不要である。

既知の方法によるインバウンドマルチキャストパケットのルーティングの概略図。 図１の方法によるアウトバウンドマルチキャストパケットのルーティングの概略図。 本発明の一実施形態によるインバウンドマルチキャストパケットのルーティングの例の概略図。 図３に示す方法の工程のフローチャート。 図３に示す方法において保持される一例のグループリスト。

Claims (22)

1. １つ以上のマルチキャストプロトコルを用い、かつ、ネットワークとインターネットとの間でトラフィックを転送するためのルータ（ＭＲ）を含むネットワークにおいて、ソースから、ネットワークノード（ＭＮＮ）を含むノードのグループ（Ｇ）へとトラフィックを通信する方法であって、
   マルチキャストシグナリングゲートウェイ（ＭＳＧ）はルータ（ＭＲ）と同じ位置に存在することと、インタフェースにおいてマルチキャストルーティングプロトコル（ＭＲＰ）のシグナリングメッセージをグループメンバシッププロトコル（ＧＭＰ）のメッセージへ翻訳することとを特徴とする方法。
2. １つ以上のマルチキャストプロトコルを用い、かつ、モバイルネットワークとインターネットとの間でトラフィックを転送するためのモバイルルータ（ＭＲ）を含むモバイルネットワークにおいて、ソースから、モバイルネットワークノード（ＭＮＮ）を含むノードのグループ（Ｇ）へとトラフィックを通信する方法であって、
   マルチキャストシグナリングゲートウェイ（ＭＳＧ）はモバイルルータ（ＭＲ）と同じ位置に存在することと、インタフェースにおいてマルチキャストルーティングプロトコル（ＭＲＰ）のシグナリングメッセージをグループメンバシッププロトコル（ＧＭＰ）のメッセージへ翻訳することとを特徴とする方法。
3. インタフェースはモバイルルータ（ＭＲ）の出口インタフェースである請求項２に記載の方法。
4. インタフェースにおいて動作しているマルチキャストシグナリングゲートウェイ（ＭＳＧ）はシグナリングメッセージがグループ参加クラス（｛ＪＯＩＮ｝）及びグループ離脱クラス（｛ＬＥＡＶＥ｝）のうちのいずれに関連するかを判定することと、該クラスをグループメンバシッププロトコル（ＧＭＰ）へ翻訳することとを含む請求項１乃至３のいずれか一項に記載の方法。
5. シグナリングメッセージの種類に応じてクラスを提供するクラステーブルを用いてクラスの判定が行われる請求項４に記載の方法。
6. インタフェースにおいて動作しているマルチキャストシグナリングゲートウェイ（ＭＳＧ）はシグナリングメッセージがターゲットマルチキャストグループ（Ｇ）の識別子を含むか否かを判定することと、ターゲットマルチキャストグループの識別子をグループメンバシッププロトコル（ＧＭＰ）へ翻訳することとを含む請求項１乃至５のいずれか一項に記載の方法。
7. インタフェースにおいて動作しているマルチキャストシグナリングゲートウェイ（ＭＳＧ）はシグナリングメッセージがターゲットマルチキャストグループソース（Ｓ）のアドレスを含むか否かを判定することと、該ターゲットマルチキャストグループソースのアドレスをグループメンバシッププロトコル（ＧＭＰ）へ翻訳することとを含む請求項６に記載の方法。
8. マルチキャストシグナリングゲートウェイ（ＭＳＧ）は各ＭＳＧ可能インタフェースに対してシグナリングメッセージにより識別されるそれぞれのマルチキャストグループソースアドレスに関連するグループ（Ｇ）の識別子を含むソースリストを保持することを含む請求項７に記載の方法。
9. マルチキャストシグナリングゲートウェイ（ＭＳＧ）はそれぞれのソースリストの変化に応答して前記グループ（Ｇ）のＧＭＰサブスクリプションを更新することを含む請求項８に記載の方法。
10. マルチキャストシグナリングゲートウェイ（ＭＳＧ）は、インタフェースのトポロジ接続点の変化に応答してグループのＧＭＰサブスクリプションと、インタフェースに保持されている関連するソースリストとを更新することを含む請求項１乃至９のいずれか一項に記載の方法。
11. ＭＳＧ可能インタフェースを通じてサブスクライブされるネットワークの外のソースからのマルチキャストパケットは、ルータ（ＭＲ）のローカルマルチキャスト転送テーブルに従って、ネットワーク内のＭＳＧ可能インタフェースからマルチキャストルーティングされることを含む請求項１乃至１０のいずれか一項に記載の方法。
12. マルチキャストシグナリングゲートウェイ（ＭＳＧ）はＧＭＰプロトコルにより提供される「サービスインタフェース」を用いてＧＭＰメッセージを生成することにより、特定のソースにより特定のＩＰマルチキャストアドレスへ送信されるパケットの受信を可能また不能とすることを含む請求項１乃至１１のいずれか一項に記載の方法。
13. マルチキャストシグナリングゲートウェイ（ＭＳＧ）は所与のマルチキャストグループ（Ｇ）のソースを集合させ、単一のソケット識別子（ｓｉｄ）を用いて全集合を渡すことを含む請求項１２に記載の方法。
14. マルチキャストシグナリングゲートウェイ（ＭＳＧ）はシグナリングメッセージから導出されるそれぞれのターゲット（ソースＳ，マルチキャストグループＧ）に対して異なるソケット識別子（ｔａｒｇｅｔ＿ｓｉｄ）を用いることを含む請求項１２又は１３に記載の方法。
15. マルチキャストシグナリングゲートウェイ（ＭＳＧ）はＭＳＧ可能インタフェースを通じて送信されるパケットを監視することによりマルチキャストルーティングプロトコル（ＭＲＰ）メッセージを検出することを含む請求項１乃至１４のいずれか一項に記載の方法。
16. マルチキャストシグナリングゲートウェイ（ＭＳＧ）はマルチキャストルーティングプロトコル（ＭＲＰ）実装の拡張に埋め込まれることを含む請求項１乃至１５のいずれか一項に記載の方法。
17. マルチキャストシグナリングゲートウェイ（ＭＳＧ）はマルチキャストパケットに加えて、ＩＰｖ４とＩＰｖ６との間のマルチキャストパケットのユニキャストソースアドレス及びマルチキャスト宛先アドレスを翻訳することを含む請求項１乃至１６のいずれか一項に記載の方法。
18. マルチキャストシグナリングゲートウェイ（ＭＳＧ）はＩＰｖ４ ＭＲＰメッセージをＩＰｖ４ ＧＭＰメッセージ（即ち、ＩＧＭＰメッセージ）へ翻訳することを含む請求項１乃至１７のいずれか一項に記載の方法。
19. マルチキャストシグナリングゲートウェイ（ＭＳＧ）はＩＰｖ６ ＭＲＰメッセージをＩＰｖ６ ＧＭＰメッセージ（即ち、ＭＬＤメッセージ）へ翻訳することを含む請求項１乃至１８のいずれか一項に記載の方法。
20. マルチキャストシグナリングゲートウェイ（ＭＳＧ）はＩＰｖ４ ＭＲＰメッセージをＩＰｖ６ ＧＭＰメッセージへ翻訳して、ＩＰｖ４ノードがＩＰｖ６マルチキャストグループ及びソースからマルチキャストパケットを受信することを可能とすることを含む請求項１乃至１９のいずれか一項に記載の方法。
21. マルチキャストシグナリングゲートウェイ（ＭＳＧ）はＩＰｖ６ ＭＲＰメッセージをＩＰｖ４ ＧＭＰメッセージへ翻訳して、ＩＰｖ６ノードがＩＰｖ４マルチキャストグループ及びソースからマルチキャストパケットを受信することを可能とすることを含む請求項１乃至２０のいずれか一項に記載の方法。
22. 請求項１乃至２１のいずれか一項に記載の方法を実行する際に使用するための装置であって、ルータ（ＭＲ）と同じ位置に存在し、かつ、マルチキャストルーティングプロトコル（ＭＲＰ）のシグナリングメッセージをグループメンバシッププロトコル（ＧＭＰ）のメッセージへ翻訳するマルチキャストシグナリングゲートウェイ（ＭＳＧ）からなる装置。
    

Images