(57)【要約】【課題】マルチキャストパケット配信装置において負荷分散と冗長化を実現する。【解決手段】マルチキャストパケット配信装置は、下位インタフェースからの受信状態を統合することにより、構築されるメンバシップデータベースを有すると共に、マルチキャストを受信するマルチキャストパケット配信装置である。マルチキャストパケット配信装置は、マルチキャストを受信する複数の上位インタフェースと、ルーティングテーブルであるユニキャスト・ルーティングテーブルと、上位インタフェースの優先度とユニキャスト・ルーティングテーブルとに基づいて、メンバシップデータベースから、各マルチキャストを受信し上位インタフェースを動的に管理する振り分けテーブルを生成する上位インタフェース振り分けテーブル生成手段、を備える。そして、当該上位インタフェースが受信した前記マルチキャストを、下位インタフェースを介して配信することを特徴とする。【選択図】図２
2008258962.tif 000002
【特許請求の範囲】
【請求項１】
下位インタフェースからの受信状態を統合することにより、構築されるメンバシップデータベースを有すると共に、マルチキャストを受信するマルチキャストパケット配信装置であって、
前記マルチキャストを受信する複数の上位インタフェースと、
ルーティングテーブルであるユニキャスト・ルーティングテーブルと、を備えると共に、
前記上位インタフェースの優先度と前記ユニキャスト・ルーティングテーブルとに基づいて、前記メンバシップデータベースから、前記各マルチキャストを受信し前記上位インタフェースを動的に管理する振り分けテーブルを生成する上位インタフェース振り分けテーブル生成手段、を備え、
当該上位インタフェースが受信した前記マルチキャストを、前記下位インタフェースを介して配信する
ことを特徴とするマルチキャストパケット配信装置。
【請求項２】
前記上位インタフェースは、クエリを受信すると共に、受信した時間によってリンクの状態を判定するリンク状態判定手段を備え、
前記リンク状態判定手段は、
所定時間に所定のクエリを受信しなかった場合には、リンクダウンと判定すると共に、前記上位インタフェースの優先度を解除し、
更に、前記リンクダウンと判定された後に前記所定のクエリを受信した場合には、リンクアップと判定すると共に、前記上位インタフェースの優先度を設定値に戻す
ことを特徴とする請求項１に記載のマルチキャストパケット配信装置。
【請求項３】
前記上位インタフェースは、クエリを受信すると解析し、前記クエリを受信したプロトコルのバージョンを判定するバージョン判定手段を更に備え、
前記上位インタフェースは、前記バージョン判定手段により所定のプロトコルのバージョン以外の上位ネットワークが存在すると判定される場合には、前記マルチキャストを受信する前記複数の上位インタフェースのうち、優先度が最大である上位インタフェースが前記全てのマルチキャストを受信する
ことを特徴とする請求項１又は２に記載のマルチキャストパケット配信装置。
【請求項４】
下位インタフェースからの受信状態を統合することにより、構築されるメンバシップデータベースを有すると共に、マルチキャストを受信するマルチキャストパケット配信装置における負荷分散方法であって、
前記マルチキャストを受信する複数の上位インタフェースと、
ルーティングテーブルであるユニキャスト・ルーティングテーブルと、を備えると共に、
前記上位インタフェースの優先度と前記ユニキャスト・ルーティングテーブルとに基づいて、前記メンバシップデータベースから、前記各マルチキャストを受信し前記上位インタフェースを動的に管理する振り分けテーブルを生成する上位インタフェース振り分けテーブル生成ステップ、を備え、
当該上位インタフェースが受信した前記マルチキャストを、前記下位インタフェースを介して配信する
ことを特徴とするマルチキャストパケット配信装置における負荷分散方法。
【請求項５】
前記上位インタフェースは、クエリを受信すると共に、受信した時間によってリンクの状態を判定するリンク状態判定ステップを備え、
前記リンク状態判定ステップは、
所定時間に所定のクエリを受信しなかった場合には、リンクダウンと判定すると共に、前記上位インタフェースの優先度を解除し、
更に、前記リンクダウンと判定された後に前記所定のクエリを受信した場合には、リンクアップと判定すると共に、前記上位インタフェースの優先度を設定値に戻す
ことを特徴とする請求項４に記載のマルチキャストパケット配信装置における負荷分散
方法。
【請求項６】
前記上位インタフェースは、クエリを受信すると解析し、前記クエリを受信したプロトコルのバージョンを判定するバージョン判定ステップを更に備え、
前記上位インタフェースは、前記バージョン判定ステップにより所定のプロトコルのバージョン以外の上位ネットワークが存在すると判定される場合には、前記マルチキャストを受信する前記複数の上位インタフェースのうち、優先度が最大である上位インタフェースが前記全てのマルチキャストを受信する
ことを特徴とする請求項４又は５に記載のマルチキャストパケット配信装置における負荷分散方法。
【請求項７】
下位インタフェースからの受信状態を統合することにより、構築されるメンバシップデータベースを有すると共に、マルチキャストを受信するマルチキャストパケット配信装置における冗長化方法であって、
前記マルチキャストを受信する複数の上位インタフェースと、
ルーティングテーブルであるユニキャスト・ルーティングテーブルと、を備えると共に、
前記上位インタフェースの優先度と前記ユニキャスト・ルーティングテーブルとに基づいて、前記メンバシップデータベースから、前記各マルチキャストを受信し前記上位インタフェースを動的に管理する振り分けテーブルを生成する上位インタフェース振り分けテーブル生成ステップ、を備え、
当該上位インタフェースが受信した前記マルチキャストを、前記下位インタフェースを介して配信する
ことを特徴とするマルチキャストパケット配信装置における冗長化方法。
【請求項８】
前記上位インタフェースは、クエリを受信すると共に、受信した時間によってリンクの状態を判定するリンク状態判定ステップを備え、
前記リンク状態判定ステップは、
所定時間に所定のクエリを受信しなかった場合には、リンクダウンと判定すると共に、前記上位インタフェースの優先度を解除し、
更に、前記リンクダウンと判定された後に前記所定のクエリを受信した場合には、リンクアップと判定すると共に、前記上位インタフェースの優先度を設定値に戻す
ことを特徴とする請求項７に記載のマルチキャストパケット配信装置における冗長化方法。
【請求項９】
前記上位インタフェースは、クエリを受信すると解析し、前記クエリを受信したプロトコルのバージョンを判定するバージョン判定ステップを更に備え、
前記上位インタフェースは、前記バージョン判定ステップにより所定のプロトコルのバージョン以外の上位ネットワークが存在すると判定される場合には、前記マルチキャストを受信する前記複数の上位インタフェースのうち、優先度が最大である上位インタフェースが前記全てのマルチキャストを受信する
ことを特徴とする請求項７又は８に記載のマルチキャストパケット配信装置における冗長化方法。
【請求項１０】
コンピュータを請求項１乃至３の何れか１項に記載のマルチキャストパケット配信装置として機能させるためのプログラム。
【請求項１１】
コンピュータを請求項４乃至６の何れか１項に記載のマルチキャストパケット配信装置における負荷分散方法として機能させるための負荷分散プログラム。
【請求項１２】
コンピュータを請求項７乃至９の何れか１項に記載のマルチキャストパケット配信装置における冗長化方法として機能させるための冗長化プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチキャストパケット配信装置、マルチキャストパケット配信装置における負荷分散方法、マルチキャストパケット配信装置における冗長化方法、マルチキャストパケット配信装置におけるプログラム、マルチキャストパケット配信装置における負荷分散プログラム及びマルチキャストパケット配信装置における冗長化プログラムに関し、特に、複数の上位インタフェースを用いてマルチキャストの負荷分散、冗長化を行うマルチキャストパケット配信装置、マルチキャストパケット配信装置における負荷分散方法、マルチキャストパケット配信装置における冗長化方法、マルチキャストパケット配信装置におけるプログラム、マルチキャストパケット配信装置における負荷分散プログラム及びマルチキャストパケット配信装置における冗長化プログラムに関する。
【背景技術】
【０００２】
従来から、マルチキャスト・ルーティングプロトコルの代表的なものにはＰＩＭ（protocol independent multicast）が知られている。
【０００３】
このＰＩＭは、開発コストが非常に高いので、ネットワークの末端部分のルータには、通常、ＩＧＭＰ／ＭＬＤ（internet group management protocol／multicast listener discovery）Ｐｒｏｘｙが実装されることが多い。
【０００４】
ＩＧＭＰ／ＭＬＤは、リンク内のマルチキャストの受信者を管理するプロトコルであり、ＩＧＭＰは、ＩＰｖ４（internet protocol version ４）、ＭＬＤは、ＩＰｖ６（internet protocol version ６）で使用される。
【０００５】
各リンクには、ＩＧＭＰ／ＭＬＤルータと、ＩＧＭＰ／ＭＬＤリスナが存在する。
【０００６】
ルータは、定期的にリンク内にクエリメッセージ（query message）を送信する。
【０００７】
マルチキャストを受信しているリスナは、クエリメッセージに対して、受信しているマルチキャストの情報をレポートメッセージ（report message）で返答する。また、リスナの受信状態に変更があった場合には、即座にレポートメッセージでルータに知らせる。
【０００８】
ルータは、受信したレポートメッセージによってリンク上のマルチキャストの受信状態を管理する。
【０００９】
また、ＩＧＭＰｖ１／ＩＧＭＰｖ２／ＭＬＤｖ１のメッセージでは、マルチキャストアドレス情報のみを伝達可能だが、ＩＧＭＰｖ３／ＭＬＤｖ２のメッセージでは、マルチキャストＭＣの送信元情報も伝達可能である。
【００１０】
例えば、送信元ＡとＢから同一のマルチキャストＭＣが配信されており、リスナは、送信元Ａからのマルチキャストのみを受信したいとする。
【００１１】
この場合、ＩＧＭＰｖ１／ＩＧＭＰｖ２／ＭＬＤｖ１では「マルチキャストＭＣ」という情報しか伝達できないため、送信元ＡとＢ両方のマルチキャストがリスナに転送されることになる。
【００１２】
一方、ＩＧＭＰｖ３／ＭＬＤｖ２では「送信元がＡのマルチキャストＭＣ」という表現が可能なので、送信元がＢのマルチキャストは、リスナに転送されない。
【００１３】
これを実現するために、ＩＧＭＰｖ３／ＭＬＤｖ２には、ＩＮＣＬＵＤＥ又はＥＸＣＬＵＤＥのフィルタモードがある。
【００１４】
マルチキャストＭＣ、フィルタモードがＩＮＣＬＵＤＥ、送信元Ａ及びＢの場合には、「送信元がＡとＢのマルチキャストＭＣの受信」を意味し、これを（ＭＣ、ＩＮＣＬＵＤＥ、Ａ Ｂ）と表すことができる。
【００１５】
また、マルチキャストＭＣ、フィルタモードがＥＸＣＬＵＤＥ、送信元Ｃ及びＤの場合には、「送信元がＣとＤ以外のマルチキャストＭＣの受信」を意味し、（ＭＣ、ＥＸＣＬＵＤＥ、Ｃ Ｄ）と表すことができる。
【００１６】
また、ＩＧＭＰｖ１／ＩＧＭＰｖ２／ＭＬＤｖ１のメッセージは、（ＭＣ、ＥＸＣＬＵＤＥ、ＮＵＬＬ）と同義である。
【００１７】
ここで、ＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータは、下位インタフェースでは、ルータとして動作し、上位インタフェースではリスナとして動作する。
【００１８】
この従来のＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータの動作について、図８を使用して説明する。
【００１９】
図８に示すＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１００は、１つの上位インタフェース１０２と、１つ以上の下位インタフェース１０４（１０４Ａから１０４Ｃを含め、総称して１０４という。）を備え、上位ネットワーク１０１から受信したマルチキャストを、必要としている下位ネットワーク１０５（１０５Ａから１０５Ｃを含め、総称して１０５という。）へ転送する。
【００２０】
このＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１００は、各下位インタフェース１０４が保持している受信状態からメンバシップデータベース１０３を構築し、上位インタフェース１０２では、メンバシップデータベース１０３の内容に従って、ＩＧＭＰ／ＭＬＤリスナとして動作する。
【００２１】
ここで、マルチキャストに関するものが、特許文献１及び２に記載されている。
【特許文献１】特開２００５-２７７９４８号公報
【特許文献２】特開２００６-１０１４７１号公報
【発明の開示】
【発明が解決しようとする課題】
【００２２】
ところで、従来のＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータには、次のような問題があった。
【００２３】
第１の問題点は、上位インタフェースを１つしか持てないため、負荷分散を行うことができない点である。
【００２４】
なぜなら、マルチキャストは、映像配信などに用いられており、ブロードバンド化によって動画コンテンツが広帯域化しているため、多数のマルチキャストを受信している場合には、帯域不足により受信に支障をきたすことが考えられた。
【００２５】
また、第２の問題点は、上位インタフェースを固定で設定する必要があり、冗長化を行うことができない点である。
【００２６】
そのため、ＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙを用いたネットワークの経路上に障害が発生すると、下位のネットワークにマルチキャストが全く流れなくなる。
【００２７】
ところで、特許文献１に記載されたマルチキャストパケット配信システムに関するものは、メインとバックアップの上位インタフェースを設定しておき、メイン側に障害が発生した場合には、バックアップ側に切り替えるものである。
【００２８】
また、特許文献２に記載されたマルチキャストのルータに関するものは、複数の上位インタフェースを同時に使用するものについて記載されている。
【００２９】
しかしながら、この特許文献１に記載されたマルチキャストパケット配信システムに関するものは、使用している上位インタフェースは常に１つなので、第１の問題点である負荷分散を行うことができなかった。
【００３０】
また、特許文献２に記載されたマルチキャストのルータに関するものは、各マルチキャストの転送経路を静的に設定する必要があり、第２の問題点である冗長化を実現することができなかった。
【００３１】
従って、特許文献１及び２に記載されたものでは、マルチキャストパケットを送信する際に、負荷分散と冗長化を行うことができなかった。
【００３２】
本発明は、上記問題点に鑑みてなされたものであり、負荷分散と冗長化を行うことができるマルチキャストパケット配信装置、マルチキャストパケット配信装置における負荷分散方法、マルチキャストパケット配信装置における冗長化方法、マルチキャストパケット配信装置におけるプログラム、マルチキャストパケット配信装置における負荷分散プログラム及びマルチキャストパケット配信装置における冗長化プログラムを実現することを目的とする。
【課題を解決するための手段】
【００３３】
本発明に係るマルチキャストパケット配信装置は、下位インタフェースからの受信状態を統合することにより、構築されるメンバシップデータベースを有すると共に、マルチキャストを受信するマルチキャストパケット配信装置であって、前記マルチキャストを受信する複数の上位インタフェースと、ルーティングテーブルであるユニキャスト・ルーティングテーブルと、を備えると共に、前記上位インタフェースの優先度と前記ユニキャスト・ルーティングテーブルとに基づいて、前記メンバシップデータベースから、前記各マルチキャストを受信し前記上位インタフェースを動的に管理する振り分けテーブルを生成する上位インタフェース振り分けテーブル生成手段、を備え、当該上位インタフェースが受信した前記マルチキャストを、前記下位インタフェースを介して配信することを特徴とする。
【００３４】
本発明に係る負荷分散方法は、下位インタフェースからの受信状態を統合することにより、構築されるメンバシップデータベースを有すると共に、マルチキャストを受信するマルチキャストパケット配信装置における負荷分散方法であって、前記マルチキャストを受信する複数の上位インタフェースと、ルーティングテーブルであるユニキャスト・ルーティングテーブルと、を備えると共に、前記上位インタフェースの優先度と前記ユニキャスト・ルーティングテーブルとに基づいて、前記メンバシップデータベースから、前記各マルチキャストを受信し前記上位インタフェースを動的に管理する振り分けテーブルを生成する上位インタフェース振り分けテーブル生成ステップ、を備え、当該上位インタフェースが受信した前記マルチキャストを、前記下位インタフェースを介して配信することを特徴とする。
【００３５】
本発明に係る冗長化方法は、下位インタフェースからの受信状態を統合することにより、構築されるメンバシップデータベースを有すると共に、マルチキャストを受信するマルチキャストパケット配信装置における冗長化方法であって、前記マルチキャストを受信する複数の上位インタフェースと、ルーティングテーブルであるユニキャスト・ルーティングテーブルと、を備えると共に、前記上位インタフェースの優先度と前記ユニキャスト・ルーティングテーブルとに基づいて、前記メンバシップデータベースから、前記各マルチキャストを受信し前記上位インタフェースを動的に管理する振り分けテーブルを生成する上位インタフェース振り分けテーブル生成ステップ、を備え、当該上位インタフェースが受信した前記マルチキャストを、前記下位インタフェースを介して配信することを特徴とする。
【発明の効果】
【００３６】
本発明によれば、複数の上位インタフェースからマルチキャストを受信しているので、帯域を有効活用し、負荷分散を行うことができると共に、ユニキャスト・ルーティングテーブルを参照して上位インタフェースを決定しているので、効率的な経路でマルチキャストを受信でき、冗長化を実現できる。
【発明を実施するための最良の形態】
【００３７】
本発明に係る実施の形態では、ＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータにおいて、マルチキャストを受信する上位インタフェースを複数用意し、各マルチキャストを受信する上位インタフェースを、メンバシップデータベースとユニキャスト・ルーティングテーブルとを基に決定することにより、マルチキャスト転送の負荷分散と冗長化を実現した。
（第１の実施の形態）
次に、本発明の実施の形態の構成について図面を参照して詳細に説明する。
（１）第１の実施の形態によるＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１（本発明のマルチキャストパケット配信装置に該当する。）のネットワーク構成
（１−１）ＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１のネットワーク構成
まず、図１には、本発明に係る第１の実施の形態によるＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１を使用するネットワーク構成が示されている。
【００３８】
図１に示すＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１は、複数の上位インタフェースを通してネットワーク３に接続されており、下位インタフェースにはマルチキャストの受信者４（４Ａ、４Ｂを総称して４と記載する。）が設けられている。
【００３９】
また、ネットワーク３上には、マルチキャストを配信する複数の配信サーバ２（２Ａから２Ｃを総称して２と記載する。）が設けられている。
【００４０】
次に、図２には、本発明に係る第１の実施の形態によるＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１の構成を示すブロック図が記載されている。
【００４１】
図２に示すＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１は、複数の上位ネットワーク１１（１１Ａから１１Ｃを総称して１１と記載する。）と、上位ネットワーク１１に接続するための上位インタフェース１２（１２Ａから１２Ｃを総称して１２と記載する。）と、上位インタフェース振り分けテーブル１３と、ユニキャスト・ルーティングテーブル１４と、メンバシップデータベース１５と、下位ネットワーク１７（１７Ａから１７Ｃを総称して１７と記載する。）と、下位ネットワークに接続するための下位インタフェース１６（１６Ａから１６Ｃを総称して１６と記載する。）とを備えている。
【００４２】
上位インタフェース振り分けテーブル１３と、ユニキャスト・ルーティングテーブル１４と、メンバシップデータベース１５は、ＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１内に記憶されている。
【００４３】
本実施の形態では、全ての上位ネットワーク１１は、ＩＧＭＰｖ３／ＭＬＤｖ２が用いられているものとする。
【００４４】
下位ネットワーク１７に、ＩＧＭＰｖ１／ＩＧＭＰｖ２／ＭＬＤｖ１の受信者がいた場合には、下位インタフェース１６は、ＩＧＭＰｖ３／ＭＬＤｖ２のＲＦＣ（request for comment）で定められた互換動作をする。
【００４５】
次に、上位インタフェース振り分けテーブル１３の詳細な構成を図３に示す。
【００４６】
図３に示す上位インタフェース振り分けテーブル１３は、上位インタフェース、優先度、受信するマルチキャストの項目を備えている。
【００４７】
なお、図３では、上位インタフェース１２のｕｐ１の優先度が２００、ｕｐ２の優先度が１００、ｕｐ３の優先度が５０に設定されており、数値が大きいほど優先度が高い。
【００４８】
また、マルチキャスト２２４.１.１.１について、送信元が１０.１.１.１のパケットは、ｕｐ１から受信し、送信元が１０.２.２.２のパケットはｕｐ２から受信し、送信元が１０.３.３.３のパケットはｕｐ３から受信することを意味する。
【００４９】
マルチキャスト２２４.２.２.２は、送信元が１０.１.１.１と１０.４.４.４と１０.５.５.５のパケットをｕｐ１から受信して、他のインタフェースからは受信しない。
【００５０】
マルチキャスト２２４.３.３.３は、送信元が１０.１０.１０.１０以外のパケットをｕｐ１から受信し、他のインタフェースからは受信しない。
【００５１】
各上位インタフェース１２は、上位インタフェース振り分けテーブル１３から自身が受信するべきマルチキャスト情報を取得し、マルチキャストの受信者４としてＩＧＭＰ／ＭＬＤの動作をする。
【００５２】
次に、ユニキャスト・ルーティングテーブル１４の詳細な構成を図４に示す。
【００５３】
図４に示すユニキャスト・ルーティングテーブル１４は、通常ルータが備えているものと同様のルーティングテーブルであり、送信されるデータの経路をチェックするための情報のことである。
【００５４】
ユニキャスト・ルーティングテーブル１４は、宛先ネットワーク、ネクストホップ、出力インタフェースの項目を備えている。
【００５５】
ＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１がユニキャストパケットを転送するときは、ユニキャスト・ルーティングテーブル１４の宛先部分を参照し、一致するエントリを検索する。一致するエントリが存在したら、ネクストホップと出力インタフェースを基に、パケットを転送する。
【００５６】
次に、メンバシップデータベース１５の詳細な構成を図５に示す。
【００５７】
図５に示すメンバシップデータベース１５は、全ての下位ネットワーク１７の受信状態を統合したデータベースである。
【００５８】
図５に示すメンバシップデータベース１５は、ソースリストが１０.１.１.１と１０.２.２.２と１０.３.３.３から送信されるマルチキャスト２２４.１.１.１を受信し、ソースリストが１０.１.１.１と１０.４.４.４と１０.５.５.５から送信されるマルチキャスト２２４.２.２.２を受信し、１０.１０.１０.１０以外から送信されるマルチキャスト２２４.３.３.３を受信することを意味する。
【００５９】
これは、通常のＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１が備えているものと同様であり、構築方法は従来から知られる公知技術の１つであるＲＦＣ４６０５に記述されている。
【００６０】
これにより、ＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１は、上位ネットワーク１１から受信したマルチキャストパケットを、下位ネットワーク１７に転送する。
【００６１】
下位ネットワーク１７の各マルチキャストの受信者４は、レポートメッセージによって、受信するマルチキャストアドレス等を通知する。
【００６２】
下位ネットワーク１７からレポートメッセージを受信したＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１は、全ての下位インタフェース１６の受信状態を統合して、メンバシップデータベース１５を構築する。
【００６３】
構築されたメンバシップデータベース１５から、各上位インタフェース１２の優先度と、ユニキャスト・ルーティングテーブル１４を基に、上位インタフェース振り分けテーブル１３を作る。
【００６４】
従って、上位インタフェース振り分けテーブル１３は、どのマルチキャストをどの上位インタフェースから受信するのかを管理するテーブルとなる。
【００６５】
各上位インタフェース１２は、上位インタフェース振り分けテーブル１３を参照して、受信すべきマルチキャストを求め、マルチキャストの受信者４として動作する。
【００６６】
上位インタフェース１２から受信したマルチキャストは、受信者４の存在する下位ネットワーク１７に転送する。
（１−２）ＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１の全体動作
次に、図６のフローチャートを参照しながら、第１の実施の形態におけるＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１の動作について詳細に説明する。
【００６７】
まず、図６では、図１のＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１が、上位インタフェース振り分けテーブル１３を構築する動作について説明する。
【００６８】
図６のフローチャートにおいて行なわれる各処理は、マルチキャストの受信状態が変更される可能性がある場合に実行される。
【００６９】
具体的に受信状態が変更される可能性があるのは、以下の場合である。
１．）上位インタフェースや下位インタフェースを追加・削除した場合
２．）メンバシップデータベース１５が変更された場合
３．）上位インタフェースがリンクダウンした場合
４．）上位インタフェースがリンクアップした場合
５．）ユニキャスト・ルーティングテーブル１４が変化した場合
図６のステップＦ０１からステップＦ１０の間の各処理は、メンバシップデータベース１５の各エントリ（マルチキャストアドレス）に対して行う（ステップＦ０１）。
【００７０】
この場合、メンバシップデータベース１５（図５）のフィルタモードによって異なる処理になる。
【００７１】
例えば、図５に示すフィルタモードがＥＸＣＬＵＤＥのときには（ステップＦ０２）、そのマルチキャストは、優先度が最大の上位インタフェース１２に割り当てる（ステップＦ０４）。
【００７２】
一方、フィルタモードがＩＮＣＬＵＤＥのときには、ステップＦ０３に進み、各送信元に対して図６のステップＦ０３からステップＦ０９の処理を行う。
【００７３】
まず、送信元がユニキャスト・ルーティングテーブル１４（図４）に登録されているかどうかを判定し（ステップＦ０５）、登録されている場合には、出力インタフェースが有効な上位インタフェース（上位インタフェースに設定されていて優先度が０より大きい）であるかどうかを判定する（ステップＦ０６）。
【００７４】
どちらの条件も満たした場合には、上位インタフェース振り分けテーブル１３（図３）の当該する上位インタフェース１２に送信元を追加する（ステップＦ０７）。
【００７５】
これに対し、ステップＦ０５及びステップＦ０６の条件を満たさない場合には、優先度が最大の上位インタフェース１２に送信元を追加する（ステップＦ０８）。
【００７６】
もし、優先度が最大である上位インタフェース１２が複数存在するときには、それらの中から一つをランダムに選択する。
【００７７】
これらの処理が完了したら、上位インタフェース振り分けテーブル１３の内容を、各上位インタフェース１２の受信状態に反映させる（ステップＦ１１）。
【００７８】
その結果、受信状態が変更になった上位インタフェース１２から、上位ネットワーク１１に対してＩＧＭＰ／ＭＬＤ Ｒｅｐｏｒｔが送信される。
【００７９】
ここで、図５のメンバシップデータベース１５と図４のユニキャスト・ルーティングテーブル１４から、図３の上位インタフェース振り分けテーブル１３を構築する方法について、具体例を用いて説明する。
【００８０】
まず、図５に示すマルチキャスト２２４.１.１.１のフィルタモードは、ＩＮＣＬＵＤＥなので、ソースリストの各送信元アドレスに対して図６のステップＦ０３からステップＦ０９の処理を行う。
【００８１】
送信元１０.１.１.１は、ユニキャスト・ルーティングテーブル１４（図４）に存在しており、出力先インタフェースがｕｐ１なので、上位インタフェース振り分けテーブル１３（図３）のｕｐ１に、(２２４.１.１.１、ＩＮＣＬＵＤＥ、１０.１.１.１)を追加する。
【００８２】
送信元１０.２.２.２は、ユニキャスト・ルーティングテーブル１４（図４）の出力先インタフェースがｕｐ２なので、上位インタフェース振り分けテーブル１３（図３）のｕｐ２に(２２４.１.１.１、ＩＮＣＬＵＤＥ、１０.２.２.２)を追加する。
【００８３】
送信元１０.３.３.３は、ユニキャスト・ルーティングテーブル１４（図４）の出力先インタフェースがｕｐ３なので、上位インタフェース振り分けテーブル１３（図３）のｕｐ３に(２２４．１．１．１、ＩＮＣＬＵＤＥ、１０.３.３.３)を追加する。
【００８４】
次に、マルチキャスト２２４.２.２.２（図５）についての処理を行う。
【００８５】
フィルタモードは、ＩＮＣＬＵＤＥなので、上記と同様の処理になる。
【００８６】
送信元１０.１.１.１は、ユニキャスト・ルーティングテーブル１４（図４）の出力先インタフェースがｕｐ１なので、上位インタフェース振り分けテーブル１３（図３）のｕｐ１に(２２４.２.２.２、ＩＮＣＬＵＤＥ、１０.１.１.１)を追加する。
【００８７】
送信元１０.４.４.４と１０.５.５.５は、ユニキャスト・ルーティングテーブル１４（図４）に存在しないため（ステップＦ０５）、上位インタフェース１２の中で最も優先度の高いｕｐ１に(２２４.２.２.２、ＩＮＣＬＵＤＥ、１０.４.４.４ １０.５.５.５)を追加する（ステップＦ０８）。
【００８８】
マルチキャスト２２４.３.３.３は、フィルタモードがＥＸＣＬＵＤＥなので、最も優先度の高いｕｐ１に(２２４.３.３.３、ＥＸＣＬＵＤＥ、１０.１０.１０.１０)を追加する（ステップＦ０４）。
【００８９】
このようにして、図３に示した上位インタフェース振り分けテーブル１３を構築することができる。
（１−３）ＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータにおけるリンク動作の判定方法
次に、ＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１のリンクアップ、リンクダウンの判定方法を、図７のタイムチャートを使用して説明する。
【００９０】
ＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１では、リンク内の受信者４を探索するためにＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１が定期的にＩＧＭＰ／ＭＬＤ Ｑｕｅｒｙと呼ばれるメッセージを送信するように決められている。
【００９１】
また、各上位インタフェース１２では、上位ネットワーク１１から送信されてくるＩＧＭＰ／ＭＬＤ Ｑｕｅｒｙを監視し、ＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１が指定した時間、ＩＧＭＰ／ＭＬＤ Ｑｕｅｒｙを受信しなかった場合には、リンクダウンと判定する。
【００９２】
図７は、優先度を２００に設定した上位インタフェース１２において、リンクダウン・リンクアップを判定する例である。
【００９３】
Ｔ１、Ｔ２、Ｔ３、Ｔ４、Ｔ５、Ｔ６は、それぞれＩＧＭＰ／ＭＬＤ Ｑｕｅｒｙを受信した時刻である。
【００９４】
時刻Ｔ３でＩＧＭＰ／ＭＬＤ Ｑｕｅｒｙを受信してから、リンクダウン判定時間が経過した時刻をＴxとする（この間にＩＧＭＰ／ＭＬＤ Ｑｕｅｒｙは受信していないものとする）。
【００９５】
時刻Ｔxにおいて上位ネットワーク１１がリンクダウンしたと判定し、このインタフェースの優先度を０にする。
【００９６】
優先度が０の上位インタフェース１２には、マルチキャストの振り分けを行わない。
【００９７】
その後、時刻Ｔ４で再びＩＧＭＰ／ＭＬＤ Ｑｕｅｒｙを受信すると、上位ネットワーク１１がリンクアップしたと判定し、優先度を設定値である２００に戻す。
【００９８】
このように、各上位インタフェース１２において、ＩＧＭＰ／ＭＬＤ Ｑｕｅｒｙの受信によって、リンクアップ、リンクダウンの判定を行うことができる。
（１−４）第１の実施の形態におけるＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１の効果
本実施の形態によれば、複数の上位インタフェース１２からマルチキャストを受信しているので、帯域を有効活用できることである。
【００９９】
また、ユニキャスト・ルーティングテーブル１４を参照して上位インタフェース１２を決定しているので、効率的な経路でマルチキャストを受信でき、また冗長化を実現することができる。
（２）第２の実施の形態によるＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１
（２−１）ＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１の動作
次に、第２の実施の形態によるＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１について、図面を参照しながら詳細に説明する。
【０１００】
上述の第１の実施の形態では、上位ネットワーク１２は、全てＩＧＭＰｖ３／ＭＬＤｖ２で動作していることを前提としている。
【０１０１】
この場合、ＩＧＭＰｖ１／ＩＧＭＰｖ２／ＭＬＤｖ１の上位ネットワーク１１が存在すると、マルチキャストを正しく受信できないことが考えられる。
【０１０２】
本実施の形態では、ＩＧＭＰｖ１／ＩＧＭＰｖ２／ＭＬＤｖ１の上位ネットワーク１１が存在する場合でも正しく動作するように変更する。
【０１０３】
各上位インタフェース１２では、受信したＩＧＭＰ／ＭＬＤ Ｑｕｅｒｙメッセージを解析し、どのバージョンのＱｕｅｒｙメッセージであるのかを判定する。
【０１０４】
ＩＧＭＰｖ３／ＭＬＤｖ２以外の上位ネットワーク１１が存在する場合には、複数インタフェースからのマルチキャスト受信をやめ、優先度が最大である上位インタフェース１２から、全てのマルチキャストを受信するように変更する。
【０１０５】
すなわち、従来のＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙと同様の動作になる。
【０１０６】
再び、全ての上位インタフェースがＩＧＭＰｖ３／ＭＬＤｖ２になった場合には、複数の上位インタフェース１２に分けて受信するように変更する。
【０１０７】
このように変更することにより、複数の上位インタフェース１２から同一のマルチキャストを受信することを回避できる。
【０１０８】
更に、他の実施の形態として、ＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ１に、上位インタフェース、下位インタフェース、上位インタフェースの優先度、リンクダウン判定時間を、ユーザの任意な値に設定しても良く、条件を付加して設定するようにしても良い。
【図面の簡単な説明】
【０１０９】
【図１】本発明に係る第１の実施の形態によるＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータを使用したネットワーク構成を示したネットワーク構成図である。
【図２】本発明に係る第１の実施の形態によるＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータの構成を示すブロック図である。
【図３】本発明に係る第１の実施の形態による上位インタフェース振り分けテーブルの具体例を示した図である。
【図４】本発明に係る第１の実施の形態によるユニキャスト・ルーティングテーブルの具体例を示した図である。
【図５】本発明に係る第１の実施の形態によるメンバシップデータベースの具体例を示した図である。
【図６】本発明に係る第１の実施の形態におけるＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータの動作を説明するフローチャートである。
【図７】本発明に係る第１の実施の形態におけるリンクアップ、リンクダウンを判定するタイミングチャートである。
【図８】従来技術におけるＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータの構成を示したブロック図である。
【符号の説明】
【０１１０】
１  ＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ
２Ａ、２Ｂ、２Ｃ  配信サーバ
３  ネットワーク
４Ａ、４Ｂ  受信者
１１Ａ、１１Ｂ、１１Ｃ  上位ネットワーク
１２Ａ、１２Ｂ、１２Ｃ  上位インタフェース
１３  上位インタフェース振り分けテーブル
１４  ユニキャスト・ルーティングテーブル
１５  メンバシップデータベース
１６Ａ、１６Ｂ、１６Ｃ  下位インタフェース
１７Ａ、１８Ｂ、１７Ｃ  下位ネットワーク
１００  ＩＧＭＰ／ＭＬＤ Ｐｒｏｘｙルータ
１０１  上位ネットワーク
１０２  上位インタフェース
１０３  メンバシップデータベース
１０４Ａ、１０４Ｂ、１０４Ｃ  下位インタフェース
１０５Ａ、１０５Ｂ、１０５Ｃ  下位ネットワーク
【図１】
2008258962.tif 000003
【図２】
2008258962.tif 000004
【図３】
2008258962.tif 000005
【図４】
2008258962.tif 000006
【図５】
2008258962.tif 000007
【図６】
2008258962.tif 000008
【図７】
2008258962.tif 000009
【図８】
2008258962.tif 000010