(57)【要約】  本発明は、データネットワーク内のマルチキャストトラフィックを管理する方法と、方法を用いる装置に関する。ホスト（２００、２２０、２２５、２３０）は、各マルチキャストグループについて包含ソースレコードおよび除外ソースレコードを格納し、ホストのネットワークインタフェースは、包含ソースレコードについての情報および／または除外ソースレコードについての情報を含むメッセージをルータ（２６０）に送付する。ルータ（２６０）はまた、各マルチキャストグループについて包含ソースレコードおよび除外ソースレコードを格納し、そのネットワークインタフェースを介して包含ソースリストについての情報および／または除外ソースリストについての情報を含むメッセージをホスト（２００、２２０、２２５、２３０）から受信すると、それらレコードを更新する。本装置は、本方法に適合したルータ、ホスト機器およびネットワーク機器である。
2010531586.tif 000002
【特許請求の範囲】
【請求項１】
データネットワーク内のマルチキャストトラフィックを管理する方法であって、ソース（２９５、２９６、２９７、２９８、２９９）が、少なくとも一つのマルチキャストグループにアドレス指定されたデータを送付し、複数のホスト（２００、２２０、２２５、２３０）が、前記マルチキャストグループ中の、送付を行う前記ソース（２９５、２９６、２９７、２９８、２９９）の一又は複数によって送付される前記データをルータ（２６０）から受信し、前記ホスト（２００、２２０、２２５、２３０）と前記ルータ（２６０）とが、ホスト−ルータ間マルチキャスト通信を可能にする通信プロトコルにより互いに通信するもので、この通信プロトコルにより、前記ホスト（２００、２２０、２２５、２３０）は、前記マルチキャストグループに対して、前記ホスト（２００、２２０、２２５、２３０）が包含ソースリスト上のソースによって送付される前記データの受信を望むことを示す前記包含ソースリストと、前記ホスト（２００、２２０、２２５、２３０）が除外ソースリスト上のソースを除く前記マルチキャストグループのソースすべてからトラフィックの受信を望むことを示す前記除外ソースリストとを定義することができ、前記通信プロトコルに従って、
・ホスト（２００、２２０、２２５、２３０）が、各マルチキャストグループおよびネットワークインタフェースについて、二つの別々のレコード、すなわち包含ソースリストを含む包含ソースレコードおよび除外ソースリストを含む除外ソースレコードを格納し、
・各ホスト（２００、２２０、２２５、２３０）のネットワークインタフェースが、単一マルチキャストグループに関する、前記ホスト（２００、２２０、２２５、２３０）の包含ソースレコードのソースリストについての情報および／または前記ホスト（２００、２２０、２２５、２３０）の除外ソースレコードのソースリストについての情報を含むメッセージをルータ（２６０）に送付し、
・ルータ（２６０）が、各マルチキャストグループについて、二つの別々のレコード、すなわち包含ソースリストについての情報を含む包含ソースレコードおよび除外ソースリストについての情報を含む除外ソースレコードを格納し、
・前記ルータ（２６０）が、ホスト（２００、２２０、２２５、２３０）からルータのネットワークインタフェースを介して、包含ソースリストについての情報および／または除外ソースリストについての情報を含むメッセージを受信したとき、各マルチキャストグループについてルータの包含ソースレコードおよび／またはルータの除外ソースレコードを更新する
ことを特徴とする方法。
【請求項２】
各ホスト（２００、２２０、２２５、２３０）のネットワークインタフェースが前記ルータ（２６０）に送付するメッセージが、前記ホスト（２００、２２０、２２５、２３０）の包含ソースレコードのソースリストおよび前記ホスト（２００、２２０、２２５、２３０）の除外ソースレコードのソースリストを含む状態メッセージであることを特徴とする、請求項１に記載の方法。
【請求項３】
各ホスト（２００、２２０、２２５、２３０）のネットワークインタフェースが前記ルータ（２６０）に送付するメッセージが、前記ホスト（２００、２２０、２２５、２３０）がホストの包含ソースレコードの変化またはホストの除外ソースレコードの変化を検出したときに送付される状態変更メッセージであり、前記状態変更メッセージが、各マルチキャストグループについて一つまたは二つのデータブロックを含み、前記データブロックの各々が、包含ソースレコードのソースリストの修正についての情報または除外ソースレコードのソースリストの修正についての情報を含み、かつ前記データブロックの各々が、データブロックが包含ソースリストの修正に関するか、それとも除外ソースリストの修正に関するかを示すフィールドを含むことを特徴とする、請求項１に記載の方法。
【請求項４】
前記ルータ（２６０）が、受信したメッセージに含まれる包含ソースリストについての情報を用いて、前記包含ソースによって送付されるデータトラフィックを要求することを特徴とする、請求項１から３のいずれか一項に記載の方法。
【請求項５】
前記通信プロトコルに従って、ホスト（２００、２２０、２２５、２３０）のネットワークインタフェース（２０３、２２２、２２３、２３２）用、前記ネットワークインタフェース（２０３、２２２、２２３、２３２）を用いる各ソケット用、および各マルチキャストグループ用に、一つの包含ソースレコードおよび一つの除外ソースレコードが保持され、ソケット用の前記包含ソースレコードの内容とソケット用の前記除外ソースレコードとに基づいてそれぞれ更新される包含ソースレコードと除外ソースレコードとが、ネットワークインタフェース（２０３、２２２、２２３、２３２）用に保持されることを特徴とする、請求項１から４のいずれか一項に記載の方法。
【請求項６】
ルータ（２６０）のネットワークインタフェースに届く前記状態メッセージが、前記ルータ（２６０）が前記包含ソースから前記ルータ（２６０）への経路指定ツリーをセットアップするために適用しなければならない方法についての命令を含むことを特徴とする、請求項１から５のいずれか一項に記載の方法。
【請求項７】
状態メッセージに前記命令を組み込むために、マルチキャストアドレス用に予約された範囲外のマルチキャストアドレスが状態メッセージ中で指示され、ルータ（２６０）が、指示されたマルチキャストアドレスが範囲外であることを検出し、前記マルチキャストアドレスが前記命令を含むと解釈し、かつ前記マルチキャストアドレスに含まれる数字コードの形で前記命令を読み出すことを特徴とする、請求項６に記載の方法。
【請求項８】
ルータ（２６０）とホスト（２００、２２０、２２５、２３０）との間の通信プロトコルが、ネットワークインタフェースまたは機器インタフェースによって送付される状態メッセージがＩＧＭＰプロトコル（インターネットグループ管理プロトコル）またはＭＬＤ（マルチキャストリスナ発見）プロトコルのバージョンであり、かつ同一メッセージ中に包含ソースリストおよび除外ソースリストを含むことができることを特徴とする、請求項１から７のいずれか一項に記載の方法。
【請求項９】
請求項１に記載の方法に適合したネットワーク機器（２０３、２０８、２２２、２２３、２３２、２０８、２２８、２２９、２４０）であって、ネットワークインタフェースを備えており、前記ホスト（２００、２２０、２２５、２３０）と前記ルータ（２６０）との間の交換線路中で動作するのに適しており、
・各マルチキャストグループ用に、包含ソースレコードおよび除外ソースレコードを保持し、
・ルータ（２６０）への近接ネットワークインタフェースに対し、マルチキャストグループに関する前記包含ソースレコードのソースリストについての情報および／または前記除外ソースレコードのソースリストについての情報を含むメッセージを送付し、かつ
・前記ネットワーク機器のネットワークインタフェースが別のネットワークインタフェースから包含ソースリストについての情報および／または除外ソースリストについての情報を含むメッセージを受信するとき、各マルチキャストグループについて包含ソースレコードおよび／または除外ソースレコードを更新する
ための実行可能な命令を格納することを特徴とする機器。
【請求項１０】
請求項５に記載の方法に適合した機器（２００、２２０、２２５、２３０）であって、ネットワークインタフェース（２０３、２２２、２２３、２３２）を備えており、ホストとして動作するのに適しており、前記ネットワークインタフェース（２０３、２２２、２２３、２３２）を用いる各ソケット用、および各マルチキャストグループ用に、包含ソースレコードおよび除外ソースレコードを保持し、前記ネットワークインタフェース（２０３、２２２、２２３、２３２）用に、前記ソケット用包含ソースレコードの内容と前記ソケット用除外ソースレコードとに基づいてそれぞれ更新される包含ソースレコードと除外ソースレコードとを保持するための実行可能な命令を格納することを特徴とする機器。
【請求項１１】
請求項１に記載の方法に適合したルータ（２６０）であって、
・各マルチキャストグループ用に、二つの別々のレコード、すなわち包含ソースレコードおよび除外ソースレコードを保持し、
・前記ルータ（２６０）が、ルータのネットワークインタフェースを介して、包含ソースリストについての情報および／または除外ソースリストについての情報を含むメッセージを受信すると、各マルチキャストグループ用に前記包含ソースレコードおよび／または前記除外ソースレコードを更新する
ための実行可能な命令を格納することを特徴とする、ルータ。
【請求項１２】
前記ルータ（２６０）が、ルータ（２６０）によって受信される前記メッセージに含まれる包含ソースリストについての情報を用いて、前記包含ソースによって送付されるデータトラフィックを他のルータから要求することを特徴とする、請求項１１に記載のルータ（２６０）。
【請求項１３】
前記包含ソースによって送付される前記データトラフィックを要求するために、前記ルータ（２６０）が、ＰＩＭ−ＳＩＭ（プロトコル非依存マルチキャスト−スパースモード）プロトコルを用いることを特徴とする、請求項１２に記載のルータ（２６０）。
【請求項１４】
特定のマルチキャストグループおよび特定の包含ソースからのトラフィックの受信をホストがそれ以上望まないことを通知するメッセージを受信すると、前記ルータがマルチキャストグループの除外ソースレコードがあるかどうかを調べ、前記レコードが存在し、かつ前記包含ソースと同じＩＰアドレスを有する除外ソースを含まない場合、前記ルータ（２６０）が、前記特定のマルチキャストグループおよび前記特定の包含ソースの前記トラフィックを伝送し続け、前記トラフィックの受信を依然として望む別のホストがあるかどうかを調べるための、ＩＧＭＰプロトコルにおける「グループおよびソース特定照会」型メッセージを送付しないことを特徴とする、請求項１１に記載のルータ（２６０）。
【請求項１５】
除外ソースレコードについての情報を更新するためのメッセージであって、特定のソースおよび前記マルチキャストグループからのトラフィックの遮断を要求するメッセージを受信すると、前記ルータ（２６０）が、前記マルチキャストグループの包含ソースレコードがあるかどうかを調べ、前記レコードが存在し、かつ前記メッセージが遮断を要求しているソースと同じＩＰアドレスを有する包含ソースを含む場合、前記ルータ（２６０）が、前記特定のマルチキャストグループおよび前記特定のソースの前記トラフィックを伝送し続け、前記トラフィックの受信を依然として望む別のホストがあるかどうかを調べるための、ＩＧＭＰプロトコルにおける「グループおよびソース特定照会」型メッセージを送付しないことを特徴とする、請求項１１に記載のルータ（２６０）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データネットワークにおけるマルチキャスト技術の分野に含まれる。具体的には、本発明は、データネットワークにおけるマルチキャストトラフィックを管理する方法に関し、このネットワークでは、ソースが、少なくとも一つのマルチキャストグループにアドレス指定されたデータを送付し、複数のホストが、前記マルチキャストグループ中の、送付を行う前記ソースの一又は複数によって送付されたデータをルータから受信するもので、前記ホストと前記ルータとは、たとえばＩＧＭＰプロトコル（インターネットグループ管理プロトコル）やＭＬＤ（マルチキャストリスナ発見）プロトコルなどの通信プロトコルを用いて互いと通信してホスト−ルータ間マルチキャスト通信を可能にし、前記ホストは、そのプロトコルにより、前記マルチキャストグループに関して、前記リストのソースによって送付されるデータの受信を望むことを示すための包含ソースリストと、前記リストのソースを除く前記マルチキャストグループのソースすべてからのトラフィックの受信を望むことを示すための除外ソースリストとを前記ホストが定義することができる。
【０００２】
本発明は、前記方法を適用する装置にも関する。
【背景技術】
【０００３】
マルチキャスト技術により、ユニキャスト通信、すなわち一対一の個別通信をソースと各受信機との間にセットアップする必要なく、データネットワークを通して単一ソースから多くの受信機にデータを送付することが可能になる。このために、ソースは、データパケットの形のデータを、前記データ送付の受信機になることを希望した機器が受信登録することができるマルチキャストグループに関連づけられた単一アドレスに送付する。このアドレスは、マルチキャストアドレスまたはマルチキャストグループアドレスとも呼ばれ、マルチキャストアプリケーション用に予約された範囲内で選ばれるＩＰ（インターネットプロトコル）アドレスである。ソースによってマルチキャストアドレスに送付されたデータパケットは、次いでマルチキャストグループに加入している受信機に届き得るように、異なるネットワークルータ内で複製される。
【０００４】
マルチキャストグループ中のデータ送付受信機は一般に、プロキシまたはルータを用いてデータネットワークに接続された機器である。これ以降、ホストという一般用語を、前記機器を指すのに使用する。ホストは、たとえば、コンピュータでも、テレビセットに接続されたセットトップボックスでもよい。
【０００５】
ホストは、マルチキャストグループの一又は複数のソースによって送付される情報を受信したいとき、前記グループに受信登録するための受信登録メッセージを、最も近いルータまたは中間プロキシに送付し、それによりルータは、データネットワークを通して到着した、マルチキャストグループのソースによって送付されたデータをホストに伝送する。同様に、ホストは、マルチキャストグループにおけるデータ送付の受信の停止を望むとき、送付の受信を停止するための登録解除メッセージをルータまたはプロキシに送付する。
【０００６】
ホストと最も近いルータとの間で交換される、マルチキャストグループへの所属を管理するためのメッセージは、ルータがＩＰプロトコル（インターネットプロトコル）のバージョン４（ＩＰｖ４）またはバージョン６（ＩＰｖ６）と連動するかどうかによって、それぞれＩＧＭＰプロトコル（インターネットグループ管理プロトコル）またはＭＬＤ（マルチキャストリスナ発見）プロトコルを用いる。
【０００７】
ホストとルータとの間にプロキシがある場合、そのプロキシは、ホスト、最も近いルータまたは他の中間プロキシと、マルチキャストグループ所属メッセージを交換するのに、ＩＧＭＰ／ＭＬＤプロトコルも用いる。これらの場合、プロキシは、マルチキャストグループに受信登録し、または登録解除するための申請を異なるホストから受信することができ、これらの申請をアセンブルすることによって、ルータに送付するＩＧＭＰ／ＭＬＤメッセージトラフィックを削減する。
【０００８】
さらに、ルータは、マルチキャストグループに受信登録したホストに、データをソースから効率的に経路指定することを可能にする経路制御を定義するために、ルータ同士でメッセージを交換する。このために、ルータは、非常によく知られているＰＩＭ−ＳＭ（プロトコル非依存マルチキャスト−スパースモード）を含む特定のプロトコルを用いる。
【０００９】
要するに、ルータは、どのマルチキャストグループからトラフィックを受信したいかを指定する情報を、ＩＧＭＰ／ＭＬＤメッセージの形でホストから受信し、ホストによって要求されたトラフィックを受け入れる経路指定をこのようなホストまでセットアップするために、たとえば、ＰＩＭ−ＳＭプロトコルを用いて他のルータと通信する。
【００１０】
言及したプロトコルはすべて、インターネット通信技術作業部会（ＩＥＴＦ）によって定義され文書化されている。
【００１１】
現在使われているＩＧＭＰプロトコルバージョンはＩＧＭＰｖ３であり、これは、ＩＥＴＦによってオンラインで公表されているＲＦＣ３３７６仕様（Ｂ．Ｃａｉｎら、Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ、Ｎｅｔｗｏｒｋ  Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ、Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ３３７６、２００２年１０月。現在、インターネットアドレスｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ３３７６から入手可能）に記載されている。
【００１２】
ＭＤＬプロトコルに関しては、現在使われているバージョンはＭＤＬｖ２であり、これは、ＩＥＴＦによってオンラインで公表されているＲＦＣ３８１０仕様（Ｒ．Ｖｉｄａら、Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ、Ｎｅｔｗｏｒｋ  Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ、Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ３８１０、２００４年６月。現在、インターネットアドレスｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ３８１０から入手可能）に記載されている。
【００１３】
ＩＧＭＰ／ＭＬＤプロトコルを用いるＩＧＭＰプロキシの動作は、ＩＥＴＦによってオンラインで公表されているＲＦＣ４６０５仕様（Ｂ．Ｆｅｎｎｅｒら、Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ、Ｎｅｔｗｏｒｋ  Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ、Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ  ４６０５、２００６年８月。現在、インターネットアドレスｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ４６０５から入手可能）に記載されている。
【００１４】
ルータ間の通信に用いられるＰＩＭ−ＳＭプロトコルは、ＩＥＴＦによってオンラインで公表されているＲＦＣ４６０１仕様（Ｂ．Ｆｅｎｎｅｒら、Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ、Ｎｅｔｗｏｒｋ  Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ、Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ  ４６０１、２００６年８月。現在、インターネットアドレスｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ４６０１から入手可能）に記載されている。
【００１５】
マルチキャスト技術は当初、主として、ＡＳＭ（全ソースマルチキャスト）として知られる多対多の通信モデルに適用されるために実装された。この通信モデルでは、多数のユーザが互いに通信し、ユーザの誰もがデータを送付し、また他の全員からデータを受信することができる。典型的なＡＳＭアプリケーションは、インターネットを介して複数通信者呼出しである。
【００１６】
マルチキャスト技術はその後、ＳＳＭ（ソース特定マルチキャスト）として知られる１対多通信モデルに適用されるために実装された。この通信モデルでは、単一ソースが多くの受信機向けにデータを送付する。インターネット経由のラジオおよびテレビは、ＳＳＭアプリケーションである。このため、ＳＳＭに対する関心は現在非常に大きい。
【００１７】
それ以前のＩＧＭＰプロトコルバージョンでは、ホストは、マルチキャストグループ中で受信登録したいデータ送付ソースを選ぶことができず、ソースすべてに関してグループに受信登録または登録解除することしかできなかった。ホストがルータに送付するメッセージは非常に単純だった。すなわち、マルチキャストグループＧからトラフィックを受信するにはＪｏｉｎ（Ｇ）、および受信を停止するにはＬｅａｖｅ（Ｇ）である。したがって、それ以前のＩＧＭＰプロトコルバージョンは、ＳＳＭを許容していなかった。
【００１８】
ホストによるマルチキャストグループ中のソース選択は、ＩＧＭＰプロトコルのＩＧＭＰｖ３バージョンにおいて可能になり、ＳＳＭが可能となった。このために、ホストは、以下の二つの型のＩＧＭＰメッセージを送付することができる。
【００１９】
・ＩＮＣＬＵＤＥメッセージ：ホストがデータの受信を望む送付元のソースＩＰアドレスの指示からなる。ＲＦＣ３３７６仕様の用語によると、包含されたこれらのソースのＩＰアドレスは、ＩＮＣＬＵＤＥソースと呼ばれる。
【００２０】
・ＥＸＣＬＵＤＥメッセージ：ホストがデータの受信を望まない送付元のソースＩＰアドレスの指示からなる。この場合、ホストは、メッセージ中で除外と示されるソースを除くソースすべてによって送付されるデータの受信を望むと解釈される。やはりＲＦＣ３３７６仕様の用語によると、これらの除外ソースのＩＰアドレスは、ＥＸＣＬＵＤＥソースと呼ばれる。
【００２１】
メモリ、データトラフィックを節約するため、または他の理由により、ＩＧＭＰｖ３バージョンにおいて、各ネットワークインタフェースおよびマルチキャストグループは以下の二つのモードの一方でのみ動作することができ、一方から他方に切り換え可能であることが決められた。前記二つのモードとは、ネットワークインタフェースがＩＮＣＬＵＤＥソースリストをその中で定義するＩＮＣＬＵＤＥモード、またはネットワークインタフェースがＥＸＣＬＵＤＥソースリストをその中で定義するＥＸＣＬＵＤＥモードである。
【００２２】
ネットワークインタフェースは、各マルチキャストグループＧ１について複数の異なる要求を受信することができる。各要求は、同一マルチキャストグループに関するＩＮＣＬＵＤＥソースリストまたはＥＸＣＬＵＤＥソースリストを含む。この状況を解消し、各ネットワークインタフェースがＩＮＣＬＵＤＥモードおよびＥＸＣＬＵＤＥモードのいずれかでのみ動作し得るという制約を保つために、ＩＧＭＰｖ３プロトコルは、ネットワークインタフェースが以下の規則を適用しなければならないとしている。
【００２３】
規則１：グループＧ１のデータソースのいずれかがＥＸＣＬＵＤＥの場合、ネットワークインタフェースは、グループＧ１についてＥＸＣＬＵＤＥモードで動作し、ネットワークインタフェースのソースリストは、ＥＸＣＬＵＤＥソースリストからＩＮＣＬＵＤＥリストのソースを引いた共通部分である。
【００２４】
規則２：ソースすべてがＩＮＣＬＵＤＥソースの場合、ネットワークインタフェースは、グループＧ１についてＩＮＣＬＵＤＥモードで動作し、ネットワークインタフェースのソースリストは、ＩＮＣＬＵＤＥソースすべての和集合である。
【００２５】
後述では、本発明の複数の実施形態の説明により、これらの規則が通信を有意に複雑にすることが理解されよう。
【００２６】
ＡＳＭマルチキャストでは、ホストが特定のマルチキャストグループＧからのトラフィックを受信したい場合、以下の技術的問題を解決することが必要である。すなわち、ホストは、マルチキャストグループＧのアドレスのみを知っており、データを送付しているそのグループＧのソースＩＰアドレスを知らない。この問題を異なる方法で解決する、ルータ間で異なるマルチキャスト通信プロトコルがある。今日では、ＰＩＭ−ＳＭプロトコルが主として適用され、ランデブーポイントと呼ばれるルータ（これ以降ＲＰルータ）を、単一マルチキャストドメイン（同じＲＰルータを使用するルータのグループ）のソースすべての認知を担うルータとして指定することによって問題を解決する。ソースＩＰアドレスを見つけ出すために、各ルータは、ＲＰルータとの第１のマルチキャスト通信をセットアップし、それにより、ＲＰルータは、要求されたマルチキャストトラフィックを各ルータに送付する。ルータは、第１のマルチキャストトラフィックデータを受信すると、ソースＩＰアドレスを発見する。次いで、最終ルータ、すなわちホストからＩＧＭＰメッセージを直接受信するルータが、ＳＰＴパスと呼ばれる、ネットワークを通る最短パスをセットアップするＳＰＴツリー（最短パスツリー）を使用して、データをソースから直接受信しようとする。ルータは、ＲＰルータを介して、およびＳＰＴパスにより直接、共に複写の形でデータの受信を始めると、ＲＰルータとの通信を切断し、ＳＰＴパスによる直接通信のみを維持する。
【００２７】
ＳＳＭでは、マルチキャストグループのソースＩＰアドレスを見つけ出すという問題は存在しない。というのは、ユーザ自身がマルチキャストトラフィックの受信を望む送付元のソースを選ぶためである。したがって、ホストは、ルータまたはプロキシにソースＩＰアドレスを示せばよい。その結果、ＳＳＭでは、ＡＳＭの特性である複数の技術的に複雑な問題をなくすことが可能である。具体的には、ソースＩＰアドレスを見つけ出すのに関連した技術的に複雑な問題をなくすことが可能である。たとえば、ＳＳＭでは、ルータは、マルチキャストグループに受信登録する際に、ホストによって指示されるソースＩＰアドレスを知ることができるので、ＲＰルータを使用する必要はない。したがって、ＳＳＭでは、今日用いられているものよりも効率的なアルゴリズムを適用することができる。
【００２８】
ＩＧＭＰｖ３プロトコルに関する前述の規則により、ＳＳＭシステムのこれらの利点が活用できなくなる。ネットワークインタフェースは、ＥＸＣＬＵＤＥモードで動作する際、ソースＩＰアドレスを知らず、したがって、ＡＳＭに関して前述したように、ＲＰルータを介して前記ＩＰアドレスを見つけ出すことを強制され、ＡＳＭ用の経路指定プロセスがより複雑になるという欠点がある。
【００２９】
ＩＥＴＦは最近、言及した欠点の解消を試みるために、ＩＧＭＰおよびＭＤＬプロトコルのＩＧＭＰｖ３およびＭＬＤｖ２バージョン仕様を修正する新たな提案を発表しており、この提案は、ＩＥＴＦによってオンラインで公表されているＲＦＣ４６０４仕様（Ｈ．Ｈｏｌｂｒｏｏｋら、Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ、Ｎｅｔｗｏｒｋ  Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ、Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ４６０４、２００６年８月。現在、インターネットアドレスｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ４６０４から入手可能）に記載されている。提案された修正は基本的に、ＳＳＭマルチキャストアドレス用の範囲を予約すること、およびＳＳＭマルチキャストシステム内のホストがＥＸＣＬＵＤＥメッセージを送付するのを禁止することからなる。この制約は、ホストが同じマルチキャストグループ中の他の新規ソースをリッスンできないようにするので、ＳＳＭの十分な開発を不要に阻んでいる。
【００３０】
マルチキャスト通信における異なる改良を提案する複数の特許または特許出願が公知である。米国特許第６４３４６２２号、米国特許第６７８５２９４号、米国特許第６９７７８９１号、米国特許出願公開第２００３／００６７９１７号、米国特許出願公開第２００５／０２０７３５４号、米国特許出願公開第２００６／０１２０３６８号、米国特許出願公開第２００６／０１８２１０９号およびＷＯ２００６／００１８０３Ａ１を挙げておく。しかし、これらのいずれもが、上述した問題を解決していない。
【発明の概要】
【００３１】
本発明の主な目的は、特にＳＳＭ通信に適用される、データネットワークにおけるマルチキャスト通信を管理する改良型システムを提供することである。
【００３２】
本発明の目的は、データ送付ソースと、前記データ送付の受信を要求したホストとの間の経路指定効率を上げることである。
【００３３】
本発明の別の目的は、既存プロトコルを基礎として用いる改良型ホスト−ルータ間マルチキャスト通信プロトコルの形で、およびこれらのプロトコルの以前のバージョンに適合した方法で上記システムを実装できるようにすることである。
【００３４】
このために、冒頭で示したタイプのデータネットワークにおけるマルチキャストトラフィックを管理する方法が開発された。この方法は、ホスト−ルータ間マルチキャスト通信を可能にする前記通信プロトコルに従って、
・ホストが、各マルチキャストグループおよびネットワークインタフェースについて、包含ソースリストを含む包含ソースレコードおよび除外ソースリストを含む除外ソースレコードという二つの別々のレコードを格納し、
・各ホストのネットワークインタフェースが、単一マルチキャストグループについての前記ホストの包含ソースレコードのソースリストの情報および／または前記ホストの除外ソースレコードのソースリストの情報を含むメッセージを前記ルータに送付し、
・ルータが、各マルチキャストグループについて、包含ソースリストの情報を含む包含ソースレコードおよび除外ソースリストの情報を含む除外ソースレコードという二つの別々のレコードを格納し、
・前記ルータが、前記ルータのネットワークインタフェースを介してホストから包含ソースリストについての情報および／または除外ソースリストについての情報を含むメッセージを受信したとき、前記ルータの包含ソースレコードおよび／または前記ルータの除外ソースレコードを、各マルチキャストグループについて更新することを特徴とする。
【００３５】
本発明は、各ホストのネットワークインタフェースが前記ルータに送付する前記メッセージが、前記ホストの包含ソースレコードのソースリストおよび前記ホストの除外ソースレコードのソースリストを含む状態メッセージであることを意図している。
【００３６】
本発明は、各ホストのネットワークインタフェースが前記ルータに送付する前記メッセージが、前記ホストが前記ホストの包含ソースレコードの変化または前記ホストの除外ソースレコードの変化を検出したときに送付される状態変更メッセージであり、前記状態変更メッセージが、各マルチキャストグループについて一つまたは二つのデータブロックを含み、前記データブロックの各々が、包含ソースレコードのソースリストの修正についての情報または除外ソースレコードのソースリストの修正についての情報を含み、前記データブロックの各々が、データブロックが包含ソースリストの修正に関するのか、それとも除外ソースリストの修正に関するのかを示すフィールドを含むことも意図している。
【００３７】
ルータは、有利には、受信した前記メッセージに含まれる包含ソースリストについての情報を用いて、前記包含ソースによって送付されるデータトラフィックを要求する。
【００３８】
ネットワークインタフェースがホストのネットワークインタフェースである場合、前記ネットワークインタフェースを用いる各ソケットおよび各マルチキャストグループ用に包含ソースレコードおよび除外ソースレコードが保持され、ソケット用の前記包含ソースレコードの内容およびソケット用の前記除外ソースレコードに基づいてそれぞれ更新される包含ソースレコードおよび除外ソースレコードが、前記ネットワークインタフェース用に保持される。
【００３９】
有利な実施形態では、ルータのネットワークインタフェースに届く前記状態メッセージが、前記ルータが前記包含ソースから前記ルータへの経路指定ツリーをセットアップするために適用しなければならない方法についての命令を含む。好ましくは、前記命令を状態メッセージに組み込むために、前記状態メッセージが、マルチキャストアドレス用に予約された範囲外のマルチキャストアドレスを指示し、ルータが、指示されたマルチキャストアドレスが範囲外であることを検出し、前記マルチキャストアドレスが前記命令を含むと解釈し、前記マルチキャストアドレスに含まれる数字コードの形で前記命令を読み出す。
【００４０】
ルータとホストとの間の通信プロトコルは、好ましくは、ＩＧＭＰプロトコル（インターネットグループ管理プロトコル）またはＭＬＤ（マルチキャストリスナ発見）プロトコルのバージョンであり、このバージョンでは、ネットワークインタフェースまたは機器インタフェースによって送付される状態メッセージが、同一メッセージ中に包含ソースリストおよび除外ソースリストを含んでよい。
【００４１】
本発明は、本発明による方法に適合したネットワーク機器にも関し、前記ネットワーク機器は、ネットワークインタフェースを備えており、前記ホストと前記ルータとの間の交換線路中で動作するのに適しており、
・各マルチキャストグループ用に、包含ソースレコードおよび除外ソースレコードを保持し、
・前記ルータへの近接ネットワークインタフェースに対し、マルチキャストグループに関する前記包含ソースレコードのソースリストの情報および／または前記除外ソースレコードのソースリストの情報を含むメッセージを送付し、
・前記ネットワーク機器のネットワークインタフェースが、別のネットワークインタフェースから、包含ソースリストについての情報および／または除外ソースリストについての情報を含むメッセージを受信すると、前記包含ソースレコードおよび／または前記除外ソースレコードを各マルチキャストグループについて更新する実行可能命令を格納することを特徴とする。
【００４２】
本発明は、本発明による方法に適合した機器にも関し、前記機器は、ネットワークインタフェースを備えており、ホストとして動作するのに適しており、前記ネットワークインタフェースを用いる各ソケット用、および各マルチキャストグループ用に、包含ソースレコードおよび除外ソースレコードを保持し、前記ネットワークインタフェース用に、ソケット用前記包含ソースレコードの内容およびソケット用前記除外ソースレコードに基づいてそれぞれ更新される包含ソースレコードおよび除外ソースレコードを保持するための実行可能命令を格納することを特徴とする。
【００４３】
本発明は、本発明による方法に適合したルータにも関し、
・各マルチキャストグループ用に、二つの別々のレコード、すなわち包含ソースレコードおよび除外ソースレコードを保持し、
・前記ルータが、前記ルータのネットワークインタフェースを介して包含ソースリストについての情報および／または除外ソースリストについての情報を含むメッセージを受信すると、各マルチキャストグループに関する前記包含ソースレコードおよび／または前記除外ソースレコードを更新する
ための実行可能命令を格納することを特徴とする。
【００４４】
前記ルータは、好ましくは、ルータによって受信される前記メッセージに含まれる包含ソースリストの情報を用いて、前記包含ソースによって送付されるデータトラフィックを他のルータに対して要求する。
【００４５】
前記包含ソースによって送付される前記データトラフィックを要求するために、前記ルータは、好ましくは、ＰＩＭ−ＳＭ（プロトコル非依存マルチキャスト−スパースモード）プロトコルを用いる。
【００４６】
好ましい実施形態では、特定のマルチキャストグループおよび特定の包含ソースからのトラフィックの受信をホストが以降望まないことを通知するメッセージを受信すると、前記ルータは、前記マルチキャストグループの除外ソースレコードがあるかどうかを調べ、前記レコードが存在し、かつ前記包含ソースと同じＩＰアドレスを有する除外ソースを含まない場合、前記ルータが、前記特定のマルチキャストグループおよび前記特定の包含ソースの前記トラフィックを伝送し続け、前記トラフィックの受信を依然として望む別のホストがあるかどうかを調べるための、ＩＧＭＰプロトコルにおける「グループおよびソース特定照会」型メッセージを送付しない。
【００４７】
好ましい実施形態ではまた、除外ソースレコードについての情報を更新するためのメッセージであって、特定のソースおよびマルチキャストグループからのトラフィックを遮断することを要求する前記メッセージを受信すると、前記ルータは、前記マルチキャストグループの包含ソースレコードがあるかどうかを調べ、前記レコードが存在し、かつ前記メッセージが遮断を要求するソースと同じＩＰアドレスを有する包含ソースを含む場合、前記ルータは、前記特定のマルチキャストグループおよび前記特定のソースの前記トラフィックを伝送し続け、前記トラフィックの受信を依然として望む別のホストがあるかどうかを調べるための、ＩＧＭＰプロトコルにおける「グループおよびソース特定照会」型メッセージを送付しない。
【００４８】
本発明の他の利点および特徴は、後述の説明に見ることができる。後述の説明では、非限定的なキャラクタを用いて、添付の図面に関する本発明の好ましい実施形態に言及する。
【図面の簡単な説明】
【００４９】
【図１】データネットワークにおけるマルチキャストシステムの基本的実施例を示す。
【図２】データネットワークにおけるマルチキャストシステムの詳細な実施例を示す。
【図３】ＩＧＭＰｖ３プロトコルで、すなわちＩＧＭＰｖ３プロトコルおよび本発明による修正ＩＧＭＰプロトコル両方で、ルータによってホストに送付される「所属照会」メッセージの形式を示す。
【図４】ＩＧＭＰｖ３プロトコルおよび本発明による修正ＩＧＭＰプロトコル両方で、ホストによってルータに送付される「所属報告」メッセージの形式を示す。
【図５】ＩＧＭＰｖ３プロトコルにおける各「所属照会」または「所属報告」メッセージに含まれる「グループレコード」データブロックの内部形式を示す。
【図６】本発明による修正ＩＧＭＰプロトコルが適用されたとき、図２のシステムにおいて、ＤＳＬＡＭ２４０によってルータ２６０に送付されるメッセージに対応する「所属報告」メッセージの形式を示す。
【発明を実施するための形態】
【００５０】
図１は、データネットワークにおけるマルチキャストシステムの基本的な実施例を示す。この実施例では、３つのホスト１０１、１０２、１０３が、ＣＰＥ１０４、１０５（ＣＰＥ：顧客構内機器）を介してデータネットワークに接続されている。ＣＰＥとは、加入者アクセス回線側に配置されたネットワークに接続する端末であり、たとえばＤＳＬ（デジタル加入者線）モデムを用いて通信を行う。ホスト１０１は、加入者線のＣＰＥ１０４に接続されており、ホスト１０２、１０３は両方とも別の加入者線の別のＣＰＥ１０５に接続されている。ＣＰＥ１０４、１０５は、異なるＣＰＥ１０４、１０５からのトラフィックを、スイッチ１０７を介してルータ１０８に向けるＤＳＬＡＭ１０６（ＤＳＬＡＭ：デジタル加入者線アクセスマルチプレクサ）に接続され、ルータ１０８は、ＩＰ（インターネットプロトコル）ネットワーク１０９に接続される。別のルータ１１０は、ＩＰネットワーク１０９の別のポイントに接続されており、このルータは、マルチキャストグループの複数のソース１１１、１１２によって送付されるデータパケットを集める。
【００５１】
分かりやすくするために、図１は、ルータ１０８に接続された複数のホスト１０１、１０２、１０３によって形成される単一グループ、およびルータ１１０に接続されたソース１１１、１１２からなる単一グループを示す。当然ながら、マルチキャストシステムは実際には、これらの多数の集まりおよびグループから成り立っている。
【００５２】
図１は、ＩＧＭＰおよびＰＩＭ−ＳＭプロトコルそれぞれの範囲も示す。すなわち、ＩＧＭＰプロトコルは、ＣＰＥおよびＤＳＬＡＭを介した受信ホストとルータとの間の通信に適用され、ＰＩＭ−ＳＭプロトコルは、ＩＰネットワークを介した、異なるルータ間の通信に適用される。
【００５３】
この実施例では、ルータはＩＰプロトコルのＩＰｖ４バージョンで動作するので、このシステムはＩＧＭＰプロトコルを用いると想定されている。ただし、記載した理由は、ＭＬＤプロトコル（ＩＰプロトコルのバージョンＩＰｖ６）を用いるシステムにも適用される。
【００５４】
ＣＰＥおよびＤＳＬＡＭは、複数のＩＧＭＰ要求を受信すること、およびこれらの要求をアセンブルして、ルータに送付されるＩＧＭＰメッセージの分量を削減することからなるＩＧＭＰプロキシ機能を実施することができる機器である。この動作は、冒頭で言及したＩＥＴＦのＲＦＣ４６０５仕様に記載されている。
【００５５】
図１に示すマルチキャストシステムの基本動作は、以下の通りである。
【００５６】
ホスト１０１、１０２、１０３は、グループのマルチキャストアドレスおよびホストが受信を希望するデータの送付元のソースアドレスを識別するための複数のＩＧＭＰメッセージをＣＰＥ１０４、１０５に送付する。図１の実施例におけるＣＰＥ１０５のケースのように、異なるホストから複数のＩＧＭＰメッセージを受信するＣＰＥは、これらのＩＧＭＰメッセージをアセンブルして、単一のＩＧＭＰメッセージをＤＳＬＡＭに送付する。一方、ＤＳＬＡＭ１０６は、異なるＣＰＥ、この場合ＣＰＥ１０４、１０５からＩＧＭＰメッセージを受信し、これらのメッセージをアセンブルして、各マルチキャストグループについてＩＮＣＬＵＤＥまたはＥＸＣＬＵＤＥソースのみが中に示されるＩＧＭＰメッセージを、スイッチ１０７を介してルータ１０８に送付する。
【００５７】
ルータ１０８は、スイッチ１０７を介してＤＳＬＡＭ１０６によって送付されたＩＧＭＰメッセージを受信し、ＰＩＭ−ＳＭプロトコルを用いて他のＩＰネットワークルータと通信することによって、ルータ１０８によって受信されたＩＧＭＰメッセージ中に指定されるソースによって送付されたデータをルータ１０８に届かせるようにする経路指定を、ＩＰネットワークを通してセットアップする。
【００５８】
さらに詳細な実施例において以下に示すように、従来技術では、ルータ１０８は、ホストによって指定されているソースＩＰアドレスを常に知っているわけではない。というのは、この情報は、元々はホストによって送付されたＩＧＭＰメッセージをネットワークインタフェースがアセンブルしたときに失われてしまっているからである。したがって、ルータ１０８は、複雑で多少非効率なプロセスを適用することによってソースＩＰアドレスを見つけ出さなければならない。
【００５９】
従来技術の方法を適用するマルチキャストシステムの動作例（ＩＧＭＰｖ３プロトコル）
図２は、マルチキャストシステムおよびこのシステムが動作するのに必要な異なる通信を詳細に示す。
【００６０】
図２に基づいて本発明の原理および利点を明らかにするために、ＩＧＭＰｖ３プロトコルを適用する従来技術による動作について最初に説明する。次いで、図２のこの同じ図表を参照して本発明による動作を説明する。
【００６１】
ホスト２００は、マルチキャストトラフィックを要求することができる二つのアプリケーション２０１、２０２が実行されるパーソナルコンピュータＰＣである。コンピュータ２００は、ＣＰＥ２０８に接続されるネットワークカード２０３を装備し、ＣＰＥ２０８は、ＤＳＬＡＭ２４０に接続される。
【００６２】
ホスト２２０、２２５は、単一のＣＰＥ２２８に接続されたネットワークカード２２２、２２３をそれぞれ装備する二つのパーソナルコンピュータＰＣであり、ＣＰＥ２２８はＤＳＬＡＭ２４０に接続される。それぞれマルチキャストトラフィックを要求することができる単一のアプリケーション２２１、２２６は、各コンピュータ２２０、２２５内で実行される。
【００６３】
ホスト２３１は、インターネットを経由したテレビチャンネルの受信を可能にするテレビセット２３０に接続されたＳＴＢ（セットトップボックス）デコーダである。デコーダ２３１は、ＣＰＥ２２９に接続されたネットワークカード２３２を装備し、ＣＰＥ２２９はＤＳＬＡＭ２４０に接続される。
【００６４】
ＤＳＬＡＭ２４０は、スイッチ２５０を介してルータ２６０に接続される。ルータ２６０は、この例ではルータ２６１、２６２、２６３、２６４、２６５、２６６、２６７、２６８である他のルータによって形成されるＩＰネットワークに接続される。
【００６５】
ルータ２６４は、ＲＰ（ランデブーポイント）ルータ、すなわち、マルチキャストグループの送付ソースと、ホストがソースのＩＰアドレスを知らないときにこれらのソースからの送付の受信を望むホストとの間の経路指定をセットアップするのに、ＰＩＭ−ＳＭプロトコルによって使用されるルータである。
【００６６】
図２の実施例では、単一マルチキャストグループＧ１に属す５つの送付ソース２９５、２９６、２９７、２９８、２９９が存在する。説明を簡単にするために、以下の説明では、図２に示すように、それぞれＳ１、Ｓ２、Ｓ３、Ｓ４、Ｓ５である各ＩＰアドレスにより、これらのソースを参照する。
【００６７】
ソースＳ１、Ｓ２、Ｓ３は、ルータ２６６を介してＩＰネットワークに接続され、ソースＳ４、Ｓ５は、ルータ２６２を介して接続される。
【００６８】
ホスト２００内で実行されるアプリケーション２０１、２０２は、マルチキャストグループＧ１中のデータ送付の受信を望むが、各アプリケーションは、以下のように異なるソースからの送付の受信を望む。
【００６９】
・アプリケーション２０１は、ソースＳ１、Ｓ２からの送付を受信することを望み、そのために、ＩＮＣＬＵＤＥ（｛Ｓ１，Ｓ２｝；Ｇ１）型要求を行う。
【００７０】
・アプリケーション２０２は、Ｓ４を除くソースすべてからの送付を受信することを望み、そのために、ＥＸＣＬＵＤＥ（｛Ｓ４｝；Ｇ１）型要求を行う。
【００７１】
ネットワークカード２０３は、ＩＧＭＰｖ３プロトコル規則を適用するアプリケーション２０１、２０２に関連づけられた異なるソケットの状態を組み合わせなければならないネットワークインタフェースである。ソケットの一つはＥＸＣＬＵＤＥモードで動作するので、ネットワークインタフェース２０３はＥＸＣＬＵＤＥモードでのみ動作することになり、ＣＰＥ２０８にＥＸＣＬＵＤＥ（｛Ｓ４｝；Ｇ１）というメッセージを送付する。
【００７２】
理論上は、ＥＸＣＬＵＤＥ（｛Ｓ４｝；Ｇ１）メッセージを送付すると、ＩＮＣＬＵＤＥ（｛Ｓ１，Ｓ２｝；Ｇ１）メッセージを送付する必要がなくなると思われる。というのは、第１のメッセージは、Ｓ４を除くソースをすべて暗黙のうちに含み、したがって、ソースＳ１、Ｓ２を含むからである。ただし、このように動作することによって、アプリケーション２０１によって送付されるＩＧＭＰメッセージに含まれていた有益な情報、すなわちソースＳ１、Ｓ２のＩＰアドレスが失われてしまっている。
【００７３】
ネットワークカード２０３によって送付されるＥＸＣＬＵＤＥ（｛Ｓ４｝；Ｇ１）メッセージは、ＣＰＥ２０８によってソースの情報が修正されずに、ＤＳＬＡＭ２４０に伝送される。というのは、ＤＳＬＡＭ２４０は、一つの起点からのＩＧＭＰメッセージしか受信しないためである。
【００７４】
コンピュータ２２０内で実行されるアプリケーション２２１は、ソースＳ５からの送付の受信を望むことを示すＩＮＣＬＵＤＥ（｛Ｓ５｝，Ｇ１）型要求を行う。ネットワークカード２２２は、アプリケーション２２１が関連づけられるソケットからの要求を受信するだけなので、複数の要求を組み合わせる必要はない。したがって、ネットワークカード２２２は、アプリケーション２２１の要求と同じ情報を含むＩＧＭＰメッセージ、すなわちＩＮＣＬＵＤＥ（｛Ｓ５｝，Ｇ１）メッセージをＣＰＥ２２８に送付する。
【００７５】
コンピュータ２２５内で実行されるアプリケーション２２６は、ソースＳ３からの送付の受信を望むことを示すＩＮＣＬＵＤＥ（｛Ｓ３｝，Ｇ１）型要求を行う。ネットワークカード２２３は、アプリケーション２２６が関連づけられるソケットからの要求を受信するだけなので、複数の要求を組み合わせる必要はない。したがって、ネットワークカード２２３は、アプリケーション２２６の要求と同じ情報を含むＩＧＭＰメッセージ、すなわちＩＮＣＬＵＤＥ（｛Ｓ３｝，Ｇ１）メッセージをＣＰＥ２２８に送付する。
【００７６】
ＣＰＥ２２８は、ＩＧＭＰプロキシとして振る舞い、ＩＧＭＰｖ３プロトコル規則を適用して、ネットワークインタフェース２２２、２２３によってそれぞれ送付されるメッセージを組み合わせる。受信されたメッセージはすべてＩＮＣＬＵＤＥ型メッセージなので、ネットワークインタフェース２２８はＩＮＣＬＵＤＥモードでのみ動作することになり、ＤＳＬＡＭ２４０にＩＮＣＬＵＤＥ（｛Ｓ３，Ｓ５｝；Ｇ１）というメッセージを伝送する。
【００７７】
ＳＴＢ２３１は、ソースＳ１からの送付の受信を望むことを示すＩＮＣＬＵＤＥ（｛Ｓ１｝，Ｇ１）メッセージを送付する。ＤＳＬＡＭ２４０は単一起点からのＩＧＭＰメッセージを受信するので、ＣＰＥ２２９は、このメッセージをそのままＤＳＬＡＭ２４０に伝送する。
【００７８】
したがって、ＤＳＬＡＭ２４０は、以下の三つのＩＧＭＰメッセージを受信する。
ＣＰＥ２０８からのＥＸＣＬＵＤＥ（｛Ｓ４｝；Ｇ１）
ＣＰＥ２２８からのＩＮＣＬＵＤＥ（｛Ｓ３，Ｓ５｝；Ｇ１）
ＣＰＥ２２９からのＩＮＣＬＵＤＥ（｛Ｓ１｝，Ｇ１）
【００７９】
ＤＳＬＡＭ２４０は、これらの異なるメッセージを、ＩＧＭＰｖ３プロトコル規則を適用して組み合わせなければならないプロキシである。マルチキャストグループＧ１に関して受信されたメッセージの一つがＥＸＣＬＵＤＥ型メッセージなので、ネットワークインタフェース２４０は、前記マルチキャストグループＧ１に対してはＥＸＣＬＵＤＥモードでのみ動作することになり、Ｓ４を除くグループＧ１のソースすべてからの送付をルータ２６０がＤＳＬＡＭ２４０に伝送しなければならないことを示すＥＸＣＬＵＤＥ（｛Ｓ４｝；Ｇ１）というメッセージを、スイッチ２５０を通してルータ２６０に伝送する。
【００８０】
次いでルータ２６０は、ＰＩＭ−ＳＭプロトコルを用いて他のＩＰネットワークルータと通信し、ソースＳ４を除くマルチキャストグループＧ１のソース全部である、ＩＧＭＰメッセージ中で要求されたソースによって送付されるデータを受信する。ＰＩＭ−ＳＭプロトコルは、二つの経路指定ツリー型、すなわちＲＰルータ（この場合、ルータ２６４）を中心とするＲＰＴ（ランデブーポイントツリー）ツリーおよび最短パスをセットアップするＳＰＴ（最短パスツリー）のセットアップを可能にする複雑なプロトコルである。ＲＰルータは、マルチキャストグループのソースすべてのＩＰアドレスの認知を担うルータとして、ＰＩＭ−ＳＭプロトコルによって指定されるルータである。ルータ２６０は最初、ＲＰルータのみがソースＩＰアドレスを知っているので、マルチキャストグループからのトラフィックを、ＲＰＴツリーを通して常に受信する。後述で説明する一定の条件が満たされると、ルータ２６０は、ＳＰＴツリーを使用し、ＲＰツリーを通した伝送を中止する。
【００８１】
図２の実施例において、最初にＲＰＴツリーを使用すると、ルータ２６０は、点線で示すパス２８１を通してソースＳ１、Ｓ２、Ｓ３からの送付を受信し、点線で示すパス２８２を通してソースＳ５からの送付を受信する。したがって、ルータ２６０は、実線で示すパス２９１、２９２であるＳＰＴツリーによる最短パスを通してではなく、最長パスを通してデータを受信している。
【００８２】
ルータ２６０は、ＤＳＬＡＭ２４０からＥＸＣＬＵＤＥ（｛Ｓ４｝；Ｇ１）メッセージを受信しただけなので、包含ソースのＩＰアドレスを知らない。したがって、ルータ２６０は、ＳＰＴツリーを直接使用して包含ソースからのトラフィックを要求することはできない。冒頭で述べたように、これは重大な欠点である。別の欠点は、ルータがＳＳＭマルチキャストにおいてのみ動作する場合、ＥＸＣＬＵＤＥメッセージを受信しないという事実である。さらに、ルータは、ソースと直接接続することしかできない簡略ルータである場合、ソースのＩＰアドレスを知らない場合は、直接接続することができない。
【００８３】
特定のチャネル（Ｓ，Ｇ）、すなわちマルチキャストグループＧ中のソースＳによって定義されるチャネルをＲＰＴツリーからＳＰＴツリーに切り換えるための、ＰＩＭ−ＳＭプロトコルによって与えられる条件は、ＲＦＣ４６０１仕様、具体的にはＣｈｅｃｋＳｗｉｔｃｈＴｏＳｐｔ（Ｓ，Ｇ）と呼ばれる関数を定義する「Ｌａｓｔ  Ｈｏｐ  Ｓｗｉｔｃｈｏｖｅｒ  ｔｏ  ｔｈｅ  ＳＰＴ」というセクション４．２．１に詳述されている。
2010531586.tif 000003
＃注：ＫＡＴをリスタートすると、ＳＰＴ切換えという結果になる。ＫｅｅｐａｌｉｖｅＴｉｍｅｒ（Ｓ，Ｇ）をＫｅｅｐａｌｉｖｅ＿Ｐｅｒｉｏｄにセットする
【００８４】
ＣｈｅｃｋＳｗｉｔｃｈＴｏＳｐｔ（Ｓ，Ｇ）関数は、設定可能な「ＳｗｉｔｃｈＴｏＳｐｔＤｅｓｉｒｅｄ（Ｓ，Ｇ）」関数によって定義される設定可能部分、および設定不可能部分を有する。ＲＰＴツリーからＳＰＴツリーへの切換えは、条件の両方の部分が満たされるときに実施される。
【００８５】
通常、前記閾値を超えていない場合はＲＰＴツリーからＳＰＴツリーへの切換えが実施されないように、設定可能な「ＳｗｉｔｃｈＴｏＳｐｔＤｅｓｉｒｅｄ（Ｓ，Ｇ）」関数が、ソースＳからのトラフィックの分量の閾値を確立するのに使用される。
【００８６】
ＰＩＭ−ＳＭプロトコルプログラミングコードの一部を形成する設定不可能部分は、以下の通りである。
2010531586.tif 000004
【００８７】
この設定不可能条件は、ＩＮＣＬＵＤＥ（Ｓ，Ｇ）というＩＧＭＰメッセージを受信済みであるルータのネットワークインタフェースがある場合、またはグループＧのソースすべてからのトラフィックの受信を望むことを示すＩＧＭＰ型メッセージを受信済みであるルータのネットワークインタフェースがあり、前記ネットワークインタフェースがＥＸＣＬＵＤＥ（Ｓ，Ｇ）というＩＧＭＰメッセージを受信していない場合に、ルータが特定のチャネル（Ｓ，Ｇ）をＲＰＴツリーからＳＰＴツリーに切り換えるだけであることを定めるものである。この設定不可能条件は、ＩＧＭＰメッセージにのみ関するので、ＳＰＴツリーへの切換えを開始してチャネル（Ｓ，Ｇ）の入力ルータとの直接接続をセットアップすることができる唯一のルータは、ＩＧＭＰメッセージを受信するルータ、すなわち図２の実施例ではルータ２６０である。ネットワークインタフェースを介してＩＧＭＰメッセージを直接受信しないルータでは、これらのルータがＳＰＴツリーへの切換えを開始することがないように、この条件が満たされることはない。
【００８８】
図２の実施例において、ルータ２６０が受信する唯一のメッセージは、前記設定不可能条件が満たされないＥＸＣＬＵＤＥ（｛Ｓ４｝，Ｇ１）である。したがって、ルータ２６０は、ＲＰＴツリーからＳＰＴツリーに切り換えることができず、トラフィックは、最短パス２９１、２９２を通るのではなく、ＲＰルータ２６４を通して最長パス２８１、２８２をいつまでも通り続けることになる。このように、トラフィックはむしろ非効率な方法で配信され、ＲＰルータに不必要に負荷がかかる。
【００８９】
要するに、この例は、ＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥ型メッセージを組み合わせるためにＩＧＭＰｖ３プロトコル規則を適用すると、経路指定システムの効率に悪影響を与えることを示す。この状況は、図２に示すものとは異なる組合せを有する他のマルチキャストシステムにおいても起こることが、当業者には容易に理解されよう。
【００９０】
本発明による修正ＩＧＭＰプロトコル
本発明は、修正ＩＧＭＰプロトコルを適用することによってこれらの問題を解決し、その結果、ネットワークインタフェースは、ホストによって送付されるメッセージを、前記メッセージに含まれる情報を失うことなく伝送することができる。
【００９１】
本発明による修正ＩＧＭＰプロトコルは、ネットワークインタフェースがデュアルモードで動作し得る点で、ＩＧＭＰｖ３プロトコルとは異なる。すなわち、インタフェースは、ＩＮＣＬＵＤＥ型ＩＧＭＰメッセージに含まれる情報およびＥＸＣＬＵＤＥ型ＩＧＭＰメッセージに含まれる情報を別々に格納および伝送する。
【００９２】
本発明による修正ＩＧＭＰプロトコルについては、後述で説明する。説明を容易にするために、冒頭で言及したＩＥＴＦのＲＦＣ３３７６仕様によるＩＧＭＰｖ３プロトコルの説明を参照し、前記ＩＧＭＰｖ３プロトコルに対する、修正ＩＧＭＰプロトコルにおける変更のみを詳しく記述する。詳しく記述しない部分は、ＩＧＭＰｖ３プロトコルに該当するので、当業者の理解の範囲内である。
【００９３】
説明は、以下のセクションにまとめられる。
１）インタフェースの説明／状態情報／ソースのアセンブル法
２）状態レコードの消去法
３）ネットワークインタフェースレコードを導出する規則
４）ＩＧＭＰメッセージの説明
５）レコードの情報が変更する際の挙動
６）ホストが「所属照会」メッセージを受信する際の挙動
７）ルータ用プロトコルの説明
８）ＩＧＭＰｖ３ホストとの互換性
９）改良型ＩＧＭＰプロキシ
【００９４】
１）インタフェースの説明／状態情報／ソースのアセンブル法
ＩＧＭＰｖ３プロトコルのＲＦＣ３３７６仕様では、システムが以下の関数によるＩＧＭＰメッセージをサポートし、ホストがマルチキャストデータソースを選択することができなければならないと記載している。
ＩＰＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ（ｓｏｃｋｅｔ，ｉｎｔｅｒｆａｃｅ，ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ｆｉｌｔｅｒ−ｍｏｄｅ，｛ｓｏｕｒｃｅ−ｌｉｓｔ｝）
上記関数で、
【００９５】
「ｓｏｃｋｅｔ」は、システム内で実行される異なるアプリケーションを区別することを可能にし、ＩＰＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ関数を呼び出すパラメータである。たとえば、データネットワークに接続された単一コンピュータ内で実行される異なるアプリケーションとすることができる。
【００９６】
「ｉｎｔｅｒｆａｃｅ」は、受信するべきマルチキャストデータソースを示すネットワークカードまたはネットワークインタフェースのローカル識別子である。
【００９７】
「ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ」は、マルチキャストグループのアドレスである。
【００９８】
「ｆｉｌｔｅｒ−ｍｏｄｅ」は、ＩＮＣＬＵＤＥでもＥＸＣＬＵＤＥでもよいネットワークインタフェースモードである。ＩＮＣＬＵＤＥモードでは、ネットワークインタフェースは、ｓｏｕｒｃｅ−ｌｉｓｔをＩＮＣＬＵＤＥとして定義し、このことは、リスト上のソースすべてによって送付されるトラフィックが送付されなければならないことを意味する。ＥＸＣＬＵＤＥモードでは、ネットワークインタフェースは、ｓｏｕｒｃｅ−ｌｉｓｔをＥＸＣＬＵＤＥと定義し、このことは、マルチキャストグループ中の送付を行うソースのうち、リスト上のソースを除くすべてからのトラフィックが送付されなければならないことを意味する。
【００９９】
「ｓｏｕｒｃｅ−ｌｉｓｔ」は、ＩＮＣＬＵＤＥまたはＥＸＣＬＵＤＥソースリストである。
【０１００】
ＲＦＣ３３７６仕様は、特定のソケット、ネットワークインタフェースおよびマルチキャストグループの組合せに対して、ＩＮＣＬＵＤＥでもＥＸＣＬＵＤＥでもよい一つのｆｉｌｔｅｒ−ｍｏｄｅしかあり得ないと明白に記述している。
【０１０１】
システムは、各アクティブソケットに対して状態レコードを保存する。このレコードは、以下の情報を含む。
（ｉｎｔｅｒｆａｃｅ，ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ｆｉｌｔｅｒ−ｍｏｄｅ，｛ｓｏｕｒｃｅ−ｌｉｓｔ｝）
【０１０２】
各ソケットに対し、レコードのｆｉｌｔｅｒ−ｍｏｄｅは、ＩＮＣＬＵＤＥまたはＥＸＣＬＵＤＥでしかあり得ない。
【０１０３】
システムは、各ネットワークインタフェースに関するレコードも保存する。このレコードは、以下の情報を含む。
（ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ｆｉｌｔｅｒ−ｍｏｄｅ，｛ｓｏｕｒｃｅ−ｌｉｓｔ｝）
【０１０４】
各ネットワークインタフェースおよびマルチキャストグループに対し、レコードのｆｉｌｔｅｒ−ｍｏｄｅは、ＩＮＣＬＵＤＥまたはＥＸＣＬＵＤＥでしかあり得ない。各ネットワークインタフェースのレコードは、ソケットレコードから導出される。ネットワークインタフェースのレコードが異なるレコードの組合せから生じなければならない場合、冒頭に記載し、下に転記する規則が適用される。
【０１０５】
規則１：グループＧ１のデータソースのいずれかがＥＸＣＬＵＤＥの場合、ネットワークインタフェースは、グループＧ１用にＥＸＣＬＵＤＥ  ｆｉｌｔｅｒ−ｍｏｄｅを有することになり、ネットワークインタフェースのソースリストは、ＥＸＣＬＵＤＥソースリストからＩＮＣＬＵＤＥリストのソースを引いた共通部分である。
【０１０６】
規則２：ソースすべてがＩＮＣＬＵＤＥ型ソースの場合、ネットワークインタフェースは、グループＧ１用にＩＮＣＬＵＤＥ  ｆｉｌｔｅｒ−ｍｏｄｅを有することになり、ソースリストは、ＩＮＣＬＵＤＥソースすべての和集合である。
【０１０７】
ここまでは、ＲＦＣ３３７６仕様によるＩＧＭＰｖ３プロトコルの特性について記述した。
【０１０８】
本発明による修正ＩＧＭＰプロトコルは、ＩＧＭＰｖ３プロトコルのＩＰＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ関数の同じ構造を維持する。
ＩＰＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ（ｓｏｃｋｅｔ，ｉｎｔｅｒｆａｃｅ，ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ｆｉｌｔｅｒ−ｍｏｄｅ，｛ｓｏｕｒｃｅ−ｌｉｓｔ｝）
しかし、各ソケットおよび各ネットワークインタフェースに対して、システムが二つのレコード、すなわちＥＸＣＬＵＤＥ  ｆｉｌｔｅｒ−ｍｏｄｅ用に一つ、ＩＮＣＬＵＤＥ  ｆｉｌｔｅｒ−ｍｏｄｅ用にもう一つを保存するという違いがある。
【０１０９】
したがって、システムは、各ソケットに対して二つのレコードを保存する。
ＩＮＣＬＵＤＥレコード：（ｉｎｔｅｒｆａｃｅ，ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ＩＮＣＬＵＤＥ，｛ｓｏｕｒｃｅ−ｌｉｓｔ｝）
ＥＸＣＬＵＤＥレコード：（ｉｎｔｅｒｆａｃｅ，ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ＥＸＣＬＵＤＥ，｛ｓｏｕｒｃｅ−ｆｉｓｔ｝）
また、各ネットワークインタフェースおよびマルチキャストグループに対して二つのレコードを保存する。
ＩＮＣＬＵＤＥレコード：（ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ＩＮＣＬＵＤＥ，｛ｓｏｕｒｃｅ−ｌｉｓｔ｝）
ＥＸＣＬＵＤＥレコード：（ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ＥＸＣＬＵＤＥ，｛ｓｏｕｒｃｅ−ｌｉｓｔ｝）
【０１１０】
ＩＮＣＬＵＤＥソースだけがある、またはＥＸＣＬＵＤＥソースだけがある場合は、システムは一つのレコードしか必要としない。ただし、ＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソース情報を有する同じマルチキャストグループに対してＩＰＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ関数への異なる呼出しがある場合、システムは、ＩＧＭＰｖ３プロトコルを用いた従来技術において行われるように情報を混合するのではなく、二つのレコードに情報を格納する。
【０１１１】
ＩＰＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ関数の各呼出しにより、特定のマルチキャストグループに対するレコードの内容が置き換えられ、レコードがない場合は、関数呼出しによって一つのレコードが作成される（これは、たとえば、前記マルチキャストグループ用に初めて関数を呼び出すときに起こる）。
【０１１２】
２）状態レコードの消去法
ＩＧＭＰｖ３プロトコルにおいて、特定のグループＧ１のレコードを消去するために、空のソースリストを有するＩＮＣＬＵＤＥ型メッセージ、すなわちＩＮＣＬＵＤＥ（｛｝，Ｇ１）が送付される。さらに、特定のグループＧ１の、ＥＸＣＬＵＤＥモードでのレコードは、一定の時間が経過した後、いかなるメッセージを送付する必要もなく、ＩＮＣＬＵＤＥモードに自動的に切り換わる。そのために、ＩＧＭＰｖ３プロトコルでのレコードは、レコード状態がＥＸＣＬＵＤＥの場合、各マルチキャストグループ用に、ゼロとは異なるタイマを有する。タイマがゼロに達すると、レコードは、ＥＸＣＬＵＤＥモードからＩＮＣＬＵＤＥモードに切り換わる。
【０１１３】
本発明による修正ＩＧＭＰプロトコルにおいて、特定のグループＧ１のＩＮＣＬＵＤＥレコードを消去するために、ＩＧＭＰｖ３プロトコルの場合と同じ仕組みが使用される。すなわち、空のソースリストを有するＩＮＣＬＵＤＥ型メッセージ、すなわちＩＮＣＬＵＤＥ（｛｝）が送付される。
【０１１４】
特定のグループＧ１のＥＸＣＬＵＤＥレコードを自動的に消去するために、修正ＩＧＭＰプロトコルでは、ＥＸＣＬＵＤＥレコードもＩＧＭＰｖ３プロトコルでのように各マルチキャストグループ用にタイマを有するが、その動作は、ＩＮＣＬＵＤＥモードからＥＸＣＬＵＤＥモードに切り換わる必要がないのでより単純である。すなわち、タイマがゼロに達すると、ＥＸＣＬＵＤＥレコードが単に消去される。
【０１１５】
修正ＩＧＭＰシステムは、以下のものに適用される、ＥＸＣＬＵＤＥ状態レコードをより素早く消去する新たな仕組みを、任意選択で追加する。
・ホストレコード：ＩＰＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ関数で更新される。
・プロキシおよびルータレコード：ＩＧＭＰメッセージを用いて更新される。
【０１１６】
Ｆｉｌｔｅｒ＿Ｄｅｌｅｔｅ＿Ｅｘｃｌｕｄｅと呼ばれる新規のｆｉｌｔｅｒ−ｍｏｄｅパラメータが、ＩＰＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ関数を用いてＥＸＣＬＵＤＥレコードを消去するために、修正ＩＧＭＰプロトコルに組み込まれている。ＩＰＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ関数は、このパラメータを有する呼出しを受信するとき、ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓに示されるマルチキャストグループからＥＸＣＬＵＤＥレコードを消去しなければならないことを知っている。
【０１１７】
ＩＧＭＰメッセージを用いてプロキシおよびルータからＥＸＣＬＵＤＥレコードを消去するために、「所属報告」メッセージの「グループレコード型」フィールド用の新規の値が、修正ＩＧＭＰプロトコルにおいて以下の簡略な記述により定義されている。
2010531586.tif 000005
【０１１８】
この新規の値は、以下の簡略記述によりＩＧＭＰｖ３プロトコルに既に存在する「グループレコード型」フィールドの値１〜６（ＲＦＣ３３７６仕様のセクション４．２．１２）に追加される。
2010531586.tif 000006
上記において、ｘは、ソースＩＰアドレスのリストである。
【０１１９】
３）ネットワークインタフェースレコードを導出する規則
セクション１）に示したように、修正ＩＧＭＰプロトコルは、各ネットワークインタフェースおよびマルチキャストグループについて二つのレコードを保存することを可能にする。
ＩＮＣＬＵＤＥレコード：（ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ＩＮＣＬＵＤＥ，｛ｓｏｕｒｃｅ−ｌｉｓｔ｝）
ＥＸＣＬＵＤＥレコード：（ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ＥＸＣＬＵＤＥ，｛ｓｏｕｒｃｅ−ｌｉｓｔ｝）
上で、ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓはマルチキャストグループのアドレスであり、ｓｏｕｒｃｅ−ｌｉｓｔはソースのリストである。
【０１２０】
ＩＧＭＰｖ３プロトコルでのように、ネットワークインタフェースレコードは、ソケットレコードから導出される。ただし、修正ＩＧＭＰプロトコルを適用すると、単一マルチキャストグループのＩＮＣＬＵＤＥソースとＥＸＣＬＵＤＥソースを混合する必要がないので、プロセスははるかに単純になる。
【０１２１】
修正ＩＧＭＰプロトコルは、各ネットワークインタフェースおよびマルチキャストグループに以下の規則を適用する。
【０１２２】
規則１：各マルチキャストグループについて、ネットワークインタフェースの各ＩＮＣＬＵＤＥレコードは、前記ネットワークインタフェースを用いるソケットのＩＮＣＬＵＤＥレコードのソースすべての和集合を含む。
【０１２３】
規則２：各マルチキャストグループについて、ネットワークインタフェースの各ＥＸＣＬＵＤＥレコードは、前記ネットワークインタフェースを用いるソケットのＥＸＣＬＵＤＥレコードのソースの共通部分を含む。
【０１２４】
４）ＩＧＭＰメッセージの説明
説明を簡単にするために、ルータとホストとの間のＩＧＭＰメッセージについて、このセクションでは、両者の間にＩＧＭＰプロキシがないと想定して記載する。ＩＧＭＰプロキシの挙動については、後でセクション９において説明する。
【０１２５】
ホストとルータとの間の通信のために、修正ＩＧＭＰプロトコルでは、ＲＦＣ３３７６仕様のセクション４に記載されているＩＧＭＰｖ３プロトコルと同じメッセージを使用するが、後述で説明するような修正を施す。
【０１２６】
図３は、ＩＧＭＰｖ３プロトコルにおいて、すなわちＩＧＭＰｖ３プロトコルおよび本発明による修正ＩＧＭＰプロトコルの両方において、ルータによってホストに送付されるメッセージの形式を示す。これらのメッセージは、「所属照会」メッセージと呼ばれる。図３に示す形式は、ＩＧＭＰｖ３プロトコルおよび修正ＩＧＭＰプロトコル両方に適用される。
【０１２７】
図４は、ＩＧＭＰｖ３プロトコルにおいて、ホストによってルータに送付されるメッセージの形式を示す。これらのメッセージは、「所属報告」メッセージと呼ばれる。図４に示す形式は、ＩＧＭＰｖ３プロトコルおよび修正ＩＧＭＰプロトコル両方に適用される。
【０１２８】
図５は、各「所属報告」メッセージに含まれる「グループレコード」と呼ばれるデータブロックの内部形式を示す。「グループアドレス」フィールドは、マルチキャストグループアドレスを含む。「ソースアドレス」フィールドは、ソースについての情報を含む。「ソース数」フィールドは、各「グループレコード」に存在する「ソースアドレス」フィールドの数を示す。図５に示す形式は、ＩＧＭＰｖ３プロトコルに適用される。
【０１２９】
修正ＩＧＭＰプロトコルにおいて、「所属報告」型メッセージが送付される際はＩＧＭＰｖ３プロトコルの場合と同じメッセージ形式が使用されるが、同じマルチキャストグループに対してＩＮＣＬＵＤＥソースとＥＸＣＬＵＤＥソースもある場合には、後で論じる図６に示すように、二つの「グループレコード」が送付される。これらのソースは混合されず、各ネットワークインタフェースおよびマルチキャストグループについて二つのレコードが存在し得るので、システムは、単一のマルチキャストアドレスまたはグループ用に２通りの「グループレコード」を有するメッセージを伝送することができる。すなわち、「グループレコード」の一つは、ＩＮＣＬＵＤＥソースについての情報を伝送し、もう一つは、ＥＸＣＬＵＤＥソースについての情報を伝送する。
【０１３０】
ＩＧＭＰｖ３プロトコルでは、ルータは、ホストにホストの状態について尋ねるために、「一般照会」型「所属照会」メッセージを送付する。このメッセージに応答して、ホストは、「現状レコード」型「所属報告」状態メッセージを送付する。この仕組みは、修正ＩＧＭＰプロトコルにおいて維持されるが、ホストによって送付される「現状レコード」メッセージは、単一マルチキャストグループ用に、一つはＩＮＣＬＵＤＥモードで、およびもう一つはＥＸＣＬＵＤＥモードで二つの「グループレコード」を含み得る。ＩＮＣＬＵＤＥまたはＥＸＣＬＵＤＥモードは、ＩＧＭＰｖ３プロトコルでのように、それぞれ、「レコード型」フィールドの内容によって識別される。
レコード型＝１＝ＭＯＤＥ＿ＩＳ＿ＩＮＣＬＵＤＥ
レコード型＝２＝ＭＯＤＥ＿ＩＳ＿ＥＸＣＬＵＤＥ
【０１３１】
したがって、二つのレコードについての情報は、単一の「現状レコード」メッセージ内で伝送される。
【０１３２】
ＩＧＭＰｖ３プロトコルでは、ホストは、ＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソースに生じた変更を報告するために、「Ｓｏｕｒｃｅ−Ｌｉｓｔ−Ｃｈａｎｇｅレコード」メッセージを送付する。「現状レコード」メッセージとは異なり、「Ｓｏｕｒｃｅ−Ｌｉｓｔ−Ｃｈａｎｇｅレコード」メッセージは、ルータによって送付される「所属照会」メッセージに応答して送付されるのではなく、そのソースレコードに変更が起きたことを示すためにホストによって送付される。
【０１３３】
ＩＧＭＰｖ３プロトコルでのように、修正ＩＧＭＰプロトコルでは、ホストは、「Ｓｏｕｒｃｅ−Ｌｉｓｔ−Ｃｈａｎｇｅレコード」メッセージも送付するが、以下の違いがある。単一マルチキャストグループ用にニ通りのレコード（ＩＮＣＬＵＤＥレコードおよびＥＸＣＬＵＤＥレコード）があり得るので、「Ｓｏｕｒｃｅ−Ｌｉｓｔ−Ｃｈａｎｇｅレコード」メッセージは、それが二つのレコードのどちらを指すのか示さなければならない。そのために、修正ＩＧＭＰプロトコルでは四つの新規「グループレコード」型が以下の簡略表現で定義される。
2010531586.tif 000007
上記において、ｘは、ソースＩＰアドレスのリストである。
【０１３４】
新規の「グループレコード型」８、９、すなわちＡＬＬＯＷＩＮ（ｘ）およびＢＬＯＣＫＩＮ（ｘ）表現が、それぞれ、ＩＮＣＬＵＤＥレコード中のソースリストに要素を追加または削除するメッセージを送付するために使用される。
【０１３５】
新規の「グループレコード型」１０、１１、すなわちＡＬＬＯＷＥＸ（ｘ）およびＢＬＯＣＫＥＸ（ｘ）表現のそれぞれが、ソースｘによって送付されるトラフィックを許容または遮断するメッセージを送付するために使用される。
【０１３６】
図６は、本発明による修正ＩＧＭＰプロトコルが適用されたとき、図２の図表において、ＤＳＬＡＭ２４０によってルータ２６０に送付されるメッセージに対応する「所属報告」メッセージの一実施例を示す。このメッセージの内容については、後で詳しく説明する。ＤＳＬＡＭ２４０は、ルータ２６０とホスト２００、２２０、２２５、２３１との間に配置されたＩＧＭＰプロキシとして振る舞う。したがって、この場合、ルータとホストとの間のＩＧＭＰメッセージについての先述の説明は、前記ホストをＤＳＬＡＭ２４０で置き換えて当てはまる。ＩＧＭＰプロキシは、ＩＧＭＰルータとの通信ではホストとして振る舞い、ホストとの通信ではＩＧＭＰルータとして振る舞う。
【０１３７】
本発明による修正ＩＧＭＰプロトコルが適用される場合に図２の各機器に格納されるレコードを、以下に示す。
【０１３８】
ＰＣ２００において、アプリケーション２０１、２０２が、それぞれソケット１およびソケット２を使用する場合、ソケット１およびソケット２の状態レコードは、それぞれ以下のようになる。
ＩＮＣＬＵＤＥレコード：（インタフェース２０３，グループＧ１，ＩＮＣＬＵＤＥ，｛Ｓ１，Ｓ２｝）
ＥＸＣＬＵＤＥレコード：（インタフェース２０３，グループＧ１，ＥＸＣＬＵＤＥ，｛Ｓ４｝）
【０１３９】
ＣＰＥ２０８のネットワークインタフェースの状態と一致するＰＣ２００のネットワークインタフェース２０３の状態レコードは、以下のようになる。
ＩＮＣＬＵＤＥレコード：（グループＧ１，ＩＮＣＬＵＤＥ，｛Ｓ１，Ｓ２｝）
ＥＸＣＬＵＤＥレコード：（グループＧ１，ＥＸＣＬＵＤＥ，｛Ｓ４｝）
【０１４０】
ＰＣ２２０において、アプリケーション２２１がソケット１を使用する場合、ソケット１の状態レコードは以下のようになる。
ＩＮＣＬＵＤＥレコード：（グループＧ１，ＩＮＣＬＵＤＥ，｛Ｓ５｝）
【０１４１】
ＰＣ２２５において、アプリケーション２２６がソケット１を使用する場合、ソケット１の状態レコードは以下のようになる。
ＩＮＣＬＵＤＥレコード：（グループＧ１，ＩＮＣＬＵＤＥ，｛Ｓ３｝）
【０１４２】
ソースをアセンブルした後、ＩＧＭＰプロキシとして動作するＣＰＥ２２８のネットワークインタフェースの状態レコードは、以下のようになる。
ＩＮＣＬＵＤＥレコード：（グループＧ１，ＩＮＣＬＵＤＥ，｛Ｓ３，Ｓ５｝）
【０１４３】
ＳＴＢ２３１において、ＣＰＥ２２９のネットワークインタフェースの状態と一致するネットワークインタフェース２３２の状態レコードは、以下のようになる。
ＩＮＣＬＵＤＥレコード：（グループＧ１，ＩＮＣＬＵＤＥ，｛Ｓ１｝）
【０１４４】
ＣＰＥ２０８、２２８、２２９の各々は、そのＩＧＭＰメッセージをＤＳＬＡＭ２４０に送付し、ＤＳＬＡＭ２４０は、これらのメッセージを再度アセンブルするが、ＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソースを混合することはない。
【０１４５】
ソースをアセンブルした後、ＩＧＭＰプロキシとして動作するＤＳＬＡＭ２４０のネットワークインタフェースの状態レコードは、以下のようになる。
ＩＮＣＬＵＤＥレコード：（グループＧ１，ＩＮＣＬＵＤＥ，｛Ｓ１，Ｓ２，Ｓ３，Ｓ５｝）
ＥＸＣＬＵＤＥレコード：（グループＧ１，ＥＸＣＬＵＤＥ，｛Ｓ４｝）
【０１４６】
ルータ２６０によって送付される「一般照会」メッセージに応答して、ＤＳＬＡＭ２４０は、以下で分析される図６に示すメッセージをルータ２６０に送付する。
【０１４７】
「型」＝＝０ｘ２２は「所属報告」であることを示し、「グループレコード数」＝２は、同じマルチキャストグループＧ１に関して二つのデータブロックまたは「グループレコード」が送付されることを示す。「グループレコード」の一つは、ＩＮＣＬＵＤＥソースについての情報を含み、もう一つは、ＥＸＣＬＵＤＥソースについての情報を含む。第１の「グループレコード」は、１に等しい「レコード型」を有する。このことは、ＭＯＤＥ＿ＩＳ＿ＩＮＣＬＵＤＥ型であること、すなわちＩＮＣＬＵＤＥソースについての情報を含むことを意味する。このデータブロックにおいて、「ソース数」は４に等しく、４つのＩＮＣＬＵＤＥソースの情報が送付される予定であることを意味する。マルチキャストグループＧ１は、「マルチキャストアドレス」フィールドに示される。「ソースアドレス［１］」〜「ソースアドレス［４］」の四つのフィールドは、四つのＩＮＣＬＵＤＥソース、すなわちＳ１、Ｓ２、Ｓ３、Ｓ５についての情報を含む。２に等しい「レコード型」を有する第２の「グループレコード」が下段に示されている。このことは、ＭＯＤＥ＿ＩＳ＿ＥＸＣＬＵＤＥ型であること、すなわちＥＸＣＬＵＤＥソースについての情報を含むことを意味する。「ソース数」は１に等しく、一つのＥＸＣＬＵＤＥソースについての情報が送付される予定であることを意味する。マルチキャストグループＧ１が、「マルチキャストアドレス」フィールドに示される。「ソースアドレス［１］」フィールドは、ＥＸＣＬＵＤＥソース、すなわちＳ４についての情報を含む。
【０１４８】
ルータ２６０は、ソースすべての完全な情報を受信している。ここで、ＲＰＴツリーをＳＰＴツリーに切り換えるための、ＰＩＭ−ＳＭプロトコルによって与えられる要件が、後述で説明するように満たされる。
【０１４９】
ＰＩＭ−ＳＭプロトコルのＳｗｉｔｃｈＴｏＳｐｔＤｅｓｉｒｅｄ（Ｓ，Ｇ）条件は、チャネル（Ｓ，Ｇ）をＲＰＴツリーからＳＰＴツリーに切り換えるための切換え条件の設定可能部分であり、第１のデータパケットがＳＰＴツリーを通してソースＳから届くときにこの条件が満たされるように、デフォルトで設定される。前記切換え条件の設定不可能条件は、修正ＩＧＭＰプロトコルが適用されるときは常に満たされる。というのは、ソースＳからの受信トラフィックに関心があるルータは、ＩＮＣＬＵＤＥ（Ｓ，Ｇ）というＩＧＭＰメッセージを常に受信していることになり、またはグループＧのソースすべてからのトラフィックの受信を望むことを示すＩＧＭＰ型メッセージを受信していることになり、ＥＸＣＬＵＤＥ（Ｓ，Ｇ）というＩＧＭＰメッセージを受信していることにならないためである。
【０１５０】
したがって、修正ＩＧＭＰプロトコルが適用される際、ソースに関するトラフィック要求を受信済みであるルータはすべてＳＰＴツリーに進み、最短パスを通して前記ソースからのトラフィックを受信することができる。
【０１５１】
したがって、図２の例において、ソースＳ１、Ｓ２、Ｓ３によって送付されるトラフィックは、最短パス２９１を通ることになり、ソースＳ５によって送付されるトラフィックは、最短パス２９２を通ることになる。
【０１５２】
ルータ２６０は、任意選択で、最初から、ソースＳ１、Ｓ２、Ｓ３、Ｓ５それぞれのＳＰＴツリーと直接接続することができる。というのは、これらのソースのＩＰアドレスを知っており、したがってＳＰＴツリーを直接使用することができるからである。そのために、ＳｗｉｔｃｈＴｏＳｐｔＤｅｓｉｒｅｄ（Ｓ，Ｇ）関数を常に真にすれば十分である。
【０１５３】
さらに、各ホストは、任意選択で、各ソースによりＲＰＴツリーからＳＰＴツリーへの切換えを開始しなければならないときを、実際のＩＧＭＰメッセージ中でルータ２６０に示すことができる。そのために、本発明によると、マルチキャストアドレスの範囲外の、マルチキャストアドレスの代わりにメッセージが配置されたマルチキャストアドレスフィールドが使用される。たとえば、マルチキャストアドレスの最初の２バイトは０にセットされ、次の２バイトはルータにメッセージを送付するのに使用される。これら次の２バイトには以下の意味が関連づけられる。
１００＝ＳＰＴツリーを使って直接接続する
２００＝ルータのデフォルト設定を使用し、ＳｗｉｔｃｈＴｏＳｐｔＤｅｓｉｒｅｄ（Ｓ，Ｇ）関数を評価して、ＳＰＴツリーに切り換えることを決める
３００＝常にＲＰＴツリーを使用し、決してＳＰＴツリーには切り換えない
【０１５４】
ルータは、アドレスがマルチキャストアドレスの範囲外であることを検出し、これらの４バイトを、同じ「グループレコード」の後に含まれるマルチキャストアドレス中で、ルータがＲＰＴツリーからＳＰＴツリーに切り換えなければならない場合の方法を示すメッセージと解釈する。
【０１５５】
５）レコードの情報が変更する際の挙動
修正ＩＧＭＰプロトコルにおいて、特定のマルチキャストグループに対するネットワークインタフェースの状態レコードが変更された場合、システムは、前セクションで示した「Ｓｏｕｒｃｅ−Ｌｉｓｔ−Ｃｈａｎｇｅレコード」メッセージを送付することによって、そのような変更を伝送しなければならないだけである。
【０１５６】
このプロセスは、システムがｆｉｌｔｅｒ−ｍｏｄｅおよびこのモードに起こり得る変更を考慮に入れなければならないので、ＩＧＭＰｖ３プロトコルではより複雑である。修正ＩＧＭＰプロトコルでは、ＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソースの情報は別々に格納および伝送されるので、このような複雑さはない。
【０１５７】
６）ホストが「所属照会」メッセージを受信する際の挙動
ＩＧＭＰｖ３プロトコルおよび修正ＩＧＭＰプロトコルでは、ルータは「所属照会」メッセージと呼ばれるメッセージをホストに送付し、それにより、ホストは、受信を望むマルチキャストグループおよびチャネルについて通知する。修正ＩＧＭＰプロトコルにおいてホストは、ＩＧＭＰｖ３プロトコルで送付するものと同様の応答メッセージをルータに送付するが、ＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソースについての情報が別々に送付されるという違いがある。
【０１５８】
ホストが同時に応答することを防止するために複数のタイマが使用され、これらのタイマは、「所属照会」メッセージ中で指定されたタイムスロットの間ホストの応答を配信するように、応答を遅らせる。これは、修正ＩＧＭＰプロトコルおよびＩＧＭＰｖ３プロトコルの場合と同じように作用する。
【０１５９】
三つのタイプの「所属照会」メッセージ、すなわち「一般照会」、「グループ特定照会」および「グループおよびソース特定照会」がある。
【０１６０】
「一般照会」型メッセージは、一定期間（デフォルトでは１２５秒）毎にルータによって送付され、それによりホストのすべては、「現状レコード」と呼ばれる「所属報告」メッセージを送付することによって、受信を望むマルチキャストグループおよびチャネルについて通知を行う。ホストが「一般照会」要求に応答するためのメッセージは、「グループレコード」と呼ばれるデータブロックを含む。このデータブロックは、以下の二つの型を採り得る。
レコード型＝１  ＭＯＤＥ＿ＩＳ＿ＩＮＣＬＵＤＥ
レコード型＝２  ＭＯＤＥ＿ＩＳ＿ＥＸＣＬＵＤＥ
【０１６１】
上に示したように、図５に示すような「グループレコード」と呼ばれる複数のデータブロックが、単一メッセージまたは図４に示すような「所属報告」に入れて送付される。図５、すなわち「グループレコード」の第１フィールドは、各データブロックの意味を示す「レコード型」フィールドである（図５の例では、「レコード型」フィールドは、「型」として示されるフィールドである）。
【０１６２】
ＩＧＭＰｖ３プロトコルでは、各マルチキャストグループはＩＮＣＬＵＤＥ状態またはＥＸＣＬＵＤＥ状態のみであり得るので、各ホストは、各マルチキャストグループについて一つの「グループレコード」を送付するだけであり、その「レコード型」は、ＩＮＣＬＵＤＥまたはＥＸＣＬＵＤＥグループの状態によってそれぞれ値１または値２を有する。
【０１６３】
修正ＩＧＭＰプロトコルでは、ＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソースの情報が別々に格納および送付されるという事実の結果、ホストは、単一マルチキャストグループに関して二つの「グループレコード」を送付する必要があり得る。すなわち、第１の「グループレコード」はレコード型＝１を有してＩＮＣＬＵＤＥソースについて通知し、第２の「グループレコード」はレコード型＝２を有してＥＸＣＬＵＤＥソースについて通知する。このことは、同一マルチキャストグループＧ１に対して二つの「グループレコード」がある図６に見ることができる。
【０１６４】
上述と同じ違いが、「グループ特定照会」および「グループおよびソース特定照会」型メッセージに対して存在する。すなわち、ホストは、これらのメッセージに返信するとき、二つの「グループレコード」を使用して、ＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソースから別々に情報を送付することができる。
【０１６５】
７）ルータ用プロトコルの説明
修正ＩＧＭＰプロトコルによる動作は、ＩＧＭＰｖ３およびＭＬＤｖ２プロトコルのものと非常に類似している。したがって、後述では、冒頭で言及したＲＦＣ３３７６仕様（ＩＧＭＰｖ３プロトコル）およびＲＦＣ３８１０仕様（ＭＬＤｖ２プロトコル）で使用されるものと同じ名称を、理解を助けるために使用する。
【０１６６】
従来技術によるＩＧＭＰｖ３およびＭＬＤｖ２プロトコルに関する主な違いは、修正ＩＧＭＰプロトコルでは、ルータが各マルチキャストグループについて二つの状態レコード、すなわちＩＮＣＬＵＤＥレコードおよびＥＸＣＬＵＤＥレコードを有することである。
【０１６７】
修正ＩＧＭＰプロトコルにより、ルータがＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソースについての詳細な情報をホストから受信する結果、ルータは、経路指定アルゴリズムをさらに利用することできる。ルータは、ルータが直接接続されるネットワークすべてにおいてＩＧＭＰプロトコルを実行する。マルチキャストルータは、同じネットワークに接続された複数のネットワークインタフェースを有する場合、そのネットワークに接続されたネットワークインタフェースの一つにおいてプロトコルを実行する必要があるだけである。ＩＧＭＰｖ３プロトコルとは異なり、修正ＩＧＭＰプロトコルでは、ルータは、各マルチキャストグループおよびネットワークインタフェースに対して、ＩＮＣＬＵＤＥまたはＥＸＣＬＵＤＥモードのみで作用することはない。したがって、ルータは、ルータをＩＮＣＬＵＤＥモードからＥＸＣＬＵＤＥモードへ、およびその逆への変更を可能にする機構すべてを必要とするわけではない。
【０１６８】
各ネットワークカードまたはネットワークインタフェース、およびマルチキャストグループに、修正ＩＧＭＰプロトコルを用いるルータは、マルチキャストＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソースからの情報を二つのレコードに別々に格納する。
ＩＮＣＬＵＤＥレコード：（ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ＩＮＣＬＵＤＥ，｛ｓｏｕｒｃｅ  ｌｉｓｔ  ａｎｄ  ｔｉｍｅｒｓ｝）
ＥＸＣＬＵＤＥレコード：（ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ｇｒｏｕｐ−ｔｉｍｅｒ，ＥＸＣＬＵＤＥ，｛ｓｏｕｒｃｅ  ｌｉｓｔ  ａｎｄ  ｔｉｍｅｒｓ｝）
上記レコード中、｛ｓｏｕｒｃｅ  ｌｉｓｔ  ａｎｄ  ｔｉｍｅｒｓ｝は、要素（ｓｏｕｒｃｅ−ａｄｄｒｅｓｓ、ｓｏｕｒｃｅ−ｔｉｍｅｒ）のリストであり、ｓｏｕｒｃｅ−ａｄｄｒｅｓｓはソースＩＰアドレスであり、ｓｏｕｒｃｅ−ｔｉｍｅｒは前記ソースに関連づけられたタイマである。
【０１６９】
ｔｉｍｅｒは、ゼロに達するまで時間とともに規則正しく減少する値を含むメモリ中の変数である。
【０１７０】
したがって、ルータに格納される二つのＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥレコードは、各ｓｏｕｒｃｅ−ａｄｄｒｅｓｓに関連づけられた一つのｓｏｕｒｃｅ−ｔｉｍｅｒを含む。
【０１７１】
レコードの消去法に関するポイント２において上で説明したように、マルチキャストグループに関連づけられた各ＥＸＣＬＵＤＥレコードは、ＥＸＣＬＵＤＥ型トラフィック要求を有する報告をルータが受信することなく特定の時間が経過したときに、ＥＸＣＬＵＤＥ状態のレコードの除去に使用されるｇｒｏｕｐ−ｔｉｍｅｒをさらに含む。
【０１７２】
上で説明したように、ルータは、図３に示すような、「所属照会」メッセージと呼ばれるメッセージをホストに定期的に送付し、それにより、ホストは、マルチキャストトラフィックの受信を望むグループおよびソースについての通知を返信する。ホストは、ホストが「所属照会」メッセージを送付するのを待たずに、マルチキャストトラフィックを要求するためのメッセージをルータに送付することもできる。
【０１７３】
ルータは、「グループ特定照会」メッセージまたは「グループおよびソース特定照会」メッセージを送付した後で、ホストすべてが前記メッセージに返信するのに十分な時間があったことを確認するためにタイマを使用する。タイマの値は、時間とともに徐々に低下し、ルータがホストから「所属報告」メッセージを受信した場合、ルータは、対応するタイマを再度リスタートする。
【０１７４】
ＩＮＣＬＵＤＥレコード中のタイマは以下のように動作する。すなわち、特定のネットワークインタフェース、特定のマルチキャストグループおよび特定の包含ソースアドレスに関して、ｓｏｕｒｃｅ−ｔｉｍｅｒがゼロより大きい限り、ルータは、チャネル（ソース、マルチキャストグループ）から前記ネットワークインタフェースを介してマルチキャストトラフィックを伝送し続け、ｓｏｕｒｃｅ−ｔｉｍｅｒがゼロに達すると、ルータは前記トラフィックの伝送を停止し、そのマルチキャストグループのＩＮＣＬＵＤＥソースリストからソースを除去する。
【０１７５】
ＥＸＣＬＵＤＥレコード中のタイマは同様に動作するが、ＥＸＣＬＵＤＥソースが二つのリストに分類されるという違いがある。すなわち、そのｓｏｕｒｃｅ−ｔｉｍｅｒがゼロより大きい値もつソースを含む「要求リスト」と呼ばれる第１のリストと、そのｓｏｕｒｃｅ−ｔｉｍｅｒがゼロの値を有するソースを含む「除外リスト」と呼ばれる第２のリストである。
【０１７６】
各グループＧｉに関して、ルータは、ＩＮＣＬＵＤＥソースによって要求されたトラフィックすべてを伝送する。さらなるグループＧｉのＥＸＣＬＵＤＥレコードが存在する場合、ルータは、「除外リスト」からＥＸＣＬＵＤＥソースを除き、グループＧｉの残りのトラフィックすべてをさらに伝送する。
【０１７７】
「要求リスト」が存在する理由は、ルータにメッセージを送付する複数のホストを有するネットワークにおいて、異なるホストの要求間に衝突があり得るためである。これは、たとえば、ホストが特定のソースからのトラフィックを要求し、別のホストが前記ソースを除くトラフィックを要求するときに起こる。たとえば、ホスト１は第１のＥＸＣＬＵＤＥ（｛Ｓ１｝，Ｇ１）メッセージを送付し、次いで、同じイーサネットネットワーク内の別のホスト２が、第２のＥＸＣＬＵＤＥ（｛Ｓ１，Ｓ２，Ｓ３｝，Ｇ１）メッセージを同じルータに送付する。第２のメッセージを受信すると、ルータが第２のメッセージのソース｛Ｓ１，Ｓ２，Ｓ３｝を「除外リスト」中に置く場合、ホスト１は、ソースＳ１からのトラフィックを除くトラフィックすべてを受信したかったのであるから、受信したかったソースＳ２、Ｓ３からのトラフィックの受信を停止することになる。この問題を回避するために、ルータは、新規メッセージのソースセットと、メッセージを受信する前に「除外リスト」中にあったソースセットとの共通部分のみを「除外リスト」中に置く。残っているＥＸＣＬＵＤＥソースは「要求リスト」に入り、ルータは、任意選択で、グループＧ１のソースＳ２、Ｓ３からのトラフィックの受信を依然として希望するホストがあるかどうかを尋ねるための「グループおよびソース特定照会」メッセージをホストに送付する。
【０１７８】
ｓｏｕｒｃｅ−ｔｉｍｅｒの値によってＥＸＣＬＵＤＥソースを二つのリスト、すなわち「要求リスト」および「除外リスト」に分類するための原理は、ＩＧＭＰｖ３およびＭＬＤｖ２プロトコルにおいて適用されるものと同様である。冒頭で言及したＲＦＣ３８１０仕様（ＭＬＤｖ２プロトコル）がこの原理の説明を含んでいる。
【０１７９】
表１（この文書の末尾にある）は、本発明による修正ＩＧＭＰプロトコルを適用する改良型ルータの動作を示す。初期状態において、ルータは特定のマルチキャストグループＧについて、ＩＮＣＬＵＤＥソースを有し、またＥＸＣＬＵＤＥソースを有するので、前記マルチキャストグループＧに関する二つの状態レコードを有する。表１において、第１列の「状態１」は、ルータのＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥレコードの初期状態を示す。第２列の「メッセージ」は、ルータによって受信される「所属報告」メッセージの内容を示す。第３列の「状態２」は、「所属報告」メッセージを受信した後のルータの前記レコードの状態を示す。第４であり最後の列の「アクション」は、ルータが前記「所属報告」メッセージを受信した後で実施するアクションを示す。表は、点線で分けられた６行を含む。表の各行は、初期状態に基づき、かつルータが受信したメッセージに依存するルータの動作例である。
【０１８０】
表１は、各マルチキャストグループＧを個々に指す。各マルチキャストグループＧは、前記Ｇグループに関してルータが受信するメッセージの影響を受ける独自のＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥ状態レコードを有する。
【０１８１】
表１では、以下の名称が使われている。
・（Ａ＋Ｂ）は、ソースセットＡ、Ｂの和集合を意味する。
・（Ａ＊Ｂ）は、ソースセットＡ、Ｂの共通部分を意味する。
・（Ａ−Ｂ）は、ソースセットＡから、Ｂにも見られるソースを引いたものを意味する。
・ＩＮＣＬＵＤＥ（Ａ）は、Ａと呼ばれるソースセットを有するＩＮＣＬＵＤＥレコードをルータがもつことを示す。
・ＥＸＣＬＵＤＥ（Ｘ，Ｙ）は、ＥＸＣＬＵＤＥソースがあるので、ルータがＥＸＣＬＵＤＥ状態レコードを有することを示す。
・Ｘは、「要求リスト」である。
・Ｙは、「除外リスト」である。
・ＧＭＩは、時間値を含む「グループ所属間隔」と呼ばれるパラメータである。２５０秒という値がデフォルトで使用される。
・ＬＭＱＴは、時間値を含む、「最終メンバ照会時間」と呼ばれるパラメータである。これは、ホストが「グループおよびソース特定照会」型メッセージに返信しなければならない時間である。この時間の後、このデータに関心があることをいずれのホストも返信しない場合、ルータはデータの伝送を停止する。
・Ｔ（Ｓ）は、ソースＳのソースタイマである。
・ＧＴは、「グループタイマ」、すなわちマルチキャストグループ全体に対するＥＸＣＬＵＤＥレコードのタイマである。
・ＳＥＮＤ  Ｑ（Ｇ，Ｓ）は、マルチキャストグループＧのソースＳに関心があるホストが依然としてあるかどうかを調べるために、ルータが「グループおよびソース特定照会」メッセージをホストに送付することを意味する。このアクションが実施されると、ルータは、ソースＳのタイマもＬＭＱＴ値まで下げる。ルータは、ソースＳのいずれかに興味を示すメッセージを応答中で受信した場合、関心を持たれたホストがある前記ソースのタイマ値を、ＧＭＩに等しい初期値に初期化する。
【０１８２】
修正ＩＧＭＰプロトコルのさらなる利点は、ソースすべてが除去される場合もメッセージを消すことができるように、ルータが「ソースおよびグループ特定照会」型メッセージを送付し、メッセージのソースリストから一部のソースを除去する前に二つのＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥレコードを照会することを可能にすることである。
【０１８３】
そのために、ルータは、表１の行４に示す実施例のようなＢＬＯＣＫＩＮ（Ｂ）型メッセージを受信すると、ＳＥＮＤ  Ｑ（Ｇ，Ａ＊Ｂ）というアクションを実施する前に、同じグループＧに対してＥＸＣＬＵＤＥレコードがあるかどうかを調べ、「除外リスト」中にないソースすべてをメッセージＱ（Ｇ，Ａ＊Ｂ）から除去することができる。というのは、「除外リスト」にないということは、ＥＸＣＬＵＤＥメッセージを用いて誰かがそれらソースを要求していることを意味するからである。
【０１８４】
同じ方法で、ルータは、表１の行６に示す実施例のようなＢＬＯＣＫＥＸ（Ｂ）型メッセージを受信すると、ルータは、ＩＮＣＬＵＤＥレコードのソースリストを照会し、その情報を用いて、ＩＮＣＬＵＤＥレコード中に見られるソースをメッセージＱ（Ｇ，Ｂ−Ｙ）から消すことができる。
【０１８５】
これら二つの調査によって、多数の「グループおよびソース特定照会」メッセージを除去することができ、その結果、ネットワーク内のトラフィック、およびホストおよびルータが処理しなければならないメッセージの数が削減される。
【０１８６】
８）ＩＧＭＰｖ３ホストとの互換性
修正ＩＧＭＰプロトコルを用いるルータは、これ以降は改良型ルータと呼ぶが、ＩＧＭＰｖ３プロトコルを用いるホストと通信することができる。たとえば、イーサネットネットワークは、ＩＧＭＰｖ３プロトコルにより動作するホスト、および自ネットワークに接続されたホストおよび本発明による修正ＩＧＭＰプロトコルにより動作するホストを有することができる。
【０１８７】
そのために、改良型ルータは、修正ＩＧＭＰプロトコルの新規メッセージに対処することができ、修正ＩＧＭＰプロトコルにおいて使用されるＩＧＭＰｖ３およびＭＬＤｖ２プロトコルによって使用されるメッセージにも対処する。
【０１８８】
改良型ルータは、ＡＬＬＯＷ（Ｂ）型メッセージを受信すると、ＩＮＣＬＵＤＥレコード中のＢ上のソースに対するＡＬＬＯＷＩＮ（Ｂ）メッセージを受信したかのように動作し、ＥＸＣＬＵＤＥ状態レコードを有する、Ｂ上のソースに対するＡＬＬＯＷＥＸ（Ｂ）メッセージを受信したかのように動作する。
【０１８９】
ＡＬＬＯＷ（Ｂ）メッセージのＢ上のソースがルータのＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥレコード両方に含まれる場合、ルータの動作は、二つのＡＬＬＯＷＩＮ（Ｂ）およびＡＬＬＯＷＥＸ（Ｂ）メッセージを受信したかのように、またはこの二つのメッセージの一方のみを受信したかのように動作するように設定することができる。ルータ設定では、これらの二つの選択肢のどちらかを選ぶことが可能である。
【０１９０】
ルータがＢＬＯＣＫ（Ｂ）型メッセージを受信するケースは、同じ方法で扱われる。すなわち、ルータの動作は、二つのＢＬＯＣＫＩＮ（Ｂ）および／またはＢＬＯＣＫＥＸ（Ｂ）メッセージを受信したかのように動作するように設定することができる。
【０１９１】
ルータは、ＴＯ＿ＩＮ（Ｂ）メッセージを受信すると、そのメッセージをＩＳ＿ＩＮ（Ｂ）メッセージであるかのように取り扱う。というのは、ルータはデュアルモードで動作することができるので、ＩＮＣＬＵＤＥモードからＥＸＣＬＵＤＥモードに、およびその逆に変わる必要がないためである。
【０１９２】
同様に、ルータは、ＴＯ＿ＥＸ（Ｂ）メッセージを受信すると、そのメッセージをＩＳ＿ＥＸ（Ｂ）メッセージであるかのように取り扱う。
【０１９３】
９）改良型ＩＧＭＰプロキシ
本発明による改良型ＩＧＭＰプロキシは、ＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソースについての情報を別々に格納および伝送するという点で、冒頭で言及したＲＦＣ４６０５仕様で定義されるＩＧＭＰプロキシとは異なる。
【０１９４】
改良型ＩＧＭＰプロキシは、各ネットワークインタフェースおよびマルチキャストグループについて二つのレコードを保存することができる。
ＩＮＣＬＵＤＥレコード：（ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ＩＮＣＬＵＤＥ，｛ｓｏｕｒｃｅ  ｌｉｓｔ｝）
ＥＸＣＬＵＤＥレコード：（ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ＥＸＣＬＵＤＥ，｛ｓｏｕｒｃｅ  ｌｉｓｔ｝）
【０１９５】
ＩＧＭＰプロキシの機能は、ホストに接続されたそのネットワークインタフェースから受信したメッセージをアセンブルして、ＩＧＭＰプロキシをＩＧＭＰルータまたは別のＩＧＭＰプロキシと接続するネットワークインタフェースによってアセンブルまたは要約されたメッセージを送付することである。ＩＧＭＰルータ用の前記ネットワークインタフェースは一般に、上流インタフェースと呼ばれる。
【０１９６】
そのために、ＩＧＭＰプロキシは、セクション３において上述したものと同様の規則を適用し、ソケットレコードに基づいてホストのネットワークインタフェースからレコードを推論するが、ＩＮＣＬＵＤＥソース用とＥＸＣＬＵＤＥソース用という二つの別々のレコードがあるのでＥＸＣＬＵＤＥソースレコードからソースリストを推論し、ＩＮＣＬＵＤＥソースについての情報はＩＮＣＬＵＤＥソースレコードに前記情報が含まれるので考慮する必要がないという違いがある。
【０１９７】
改良型ＩＧＭＰプロキシが各ネットワークインタフェースおよびマルチキャストグループに対して適用するこれらの規則は以下の通りである。
【０１９８】
規則１：各マルチキャストグループについて、各ＩＮＣＬＵＤＥレコードは、プロキシのネットワークインタフェースすべてにおいて受信される前記マルチキャストグループに関するＩＮＣＬＵＤＥメッセージの、ＩＮＣＬＵＤＥソースすべての和集合を含む。
【０１９９】
規則２：各マルチキャストグループについて、各ＥＸＣＬＵＤＥレコードは、プロキシのネットワークインタフェースすべてにおいて受信される前記マルチキャストグループに関するＥＸＣＬＵＤＥメッセージの、ＥＸＣＬＵＤＥソースすべての共通部分を含む。
【０２００】
ＩＮＣＬＵＤＥソースおよびＥＸＣＬＵＤＥソースの両方を含むマルチキャストグループについての情報をルータに別々に伝送するために、ポイント４で説明したものと同じ、二つの「グループレコード」を有するメッセージシステムが使用される。
【０２０１】
改良型ＩＧＭＰプロキシは、ＩＧＭＰｖ３プロトコルを用いるホストおよび本発明による修正ＩＧＭＰプロトコルを用いるホストと同時に働くことができる。
【０２０２】
2010531586.tif 000008
【図１】
2010531586.tif 000009
【図２】
2010531586.tif 000010
【図３】
2010531586.tif 000011
【図４】
2010531586.tif 000012
【図５】
2010531586.tif 000013
【図６】
2010531586.tif 000014
【国際調査報告】
2010531586.tif 000015
2010531586.tif 000016