(57)【要約】【課題】配信元への負荷の集中を回避できるスイッチングハブを提供する。【解決手段】スイッチングハブ１において、配信元に宛てられメンバから送信されたグループからの離脱を知らせる離脱メッセージを配信元に中継せず、配信元の代わりにメンバの確認を要求する確認要求メッセージをメンバに送信する配信元代理部１４を備えた。【選択図】図１
2008141353.tif 000002
【特許請求の範囲】
【請求項１】
複数のポートと、ポートで受信したマルチキャスト制御用のメッセージを解釈するメッセージ解釈部と、このメッセージ解釈に基づいて当該マルチキャストグループのメンバを認識するメンバ認識部と、この認識に基づきマルチキャストの配信元からのマルチキャストデータを上記メンバのみに中継する選択中継部とを備えたスイッチングハブにおいて、上記配信元に宛てられ上記メンバから送信されたグループからの離脱を知らせる離脱メッセージを上記配信元に中継せず、上記配信元の代わりにメンバの確認を要求する確認要求メッセージを上記メンバに送信する配信元代理部とを備えたことを特徴とするスイッチングハブ。
【請求項２】
上記メンバ認識部におけるメンバの残存を管理し、最後のメンバから送信された離脱メッセージを受信したとき、上記配信元に離脱メッセージを送信する最終離脱部を備えたことを特徴とする請求項１記載のスイッチングハブ。
【請求項３】
上記配信元から送信されたメッセージから上記配信元のＩＰアドレスを取得する配信元ＩＰアドレス取得部を備え、上記配信元代理部は、確認要求メッセージの送信元アドレス欄に上記配信元のＩＰアドレスを格納して送信することを特徴とする請求項１又は２記載のスイッチングハブ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、配信元への負荷の集中を回避できるスイッチングハブに関する。
【背景技術】
【０００２】
マルチキャストルータ等の配信元からマルチキャストグループのメンバとなっているホストに対してマルチキャストで映像や音声などのマルチキャストデータを配信することがある。このマルチキャスト制御のプロトコルとして、例えば、ＩＰの一部として実装されるＩＧＭＰがある。
【０００３】
ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ  Ｇｒｏｕｐ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）は、同一のデータを複数のホストに効率よく配信するためのＩＰマルチキャストと呼ばれるネットワーク技術において、配信を受けるために構成されるホストのグループを制御するためのプロトコルである。このプロトコルは、あるホストがグループに参加・離脱したり、マルチキャストルータ間でグループに関する情報をやり取りしたりするのに使われる。
【０００４】
ＩＧＭＰには、ＩＧＭＰｖ１、ＩＧＭＰｖ２などがあるが、ＩＧＭＰｖ２が下位（ＩＧＭＰｖ１）に対して互換性を有する。
【０００５】
ＩＧＭＰでは配信元となるルータやサーバをＩＧＭＰクエリア（ＩＧＭＰ−Ｑｕｅｒｉｅｒ）と呼ぶ。ホストは、ＩＧＭＰクエリアに対して参加メッセージ（ＩＧＭＰ−Ｒｅｐｏｒｔ）を送信してグループのメンバとなることにより、マルチキャストデータを受信することができる。
【０００６】
スイッチングハブを使用したネットワークにおいては、ＩＰマルチキャストを効率よく行うために、スイッチングハブにはＩＧＭＰクエリアとホストとの間でスイッチングハブが中継するＩＧＭＰメッセージを覗き見して解釈するＩＧＭＰスヌーピング（ＩＧＭＰ−Ｓｎｏｏｐｉｎｇ）の機能が実装される。
【０００７】
図９に示されるように、ＩＧＭＰスヌーピングの機能が実装されたスイッチングハブ９１のポートに、ＩＧＭＰクエリア９２と複数のホスト９３，９４，９５が接続されている。この構成により、スイッチングハブ９１が覗き見したメッセージの解釈に基づいて当該マルチキャストグループのメンバを認識できるようになる。ＩＧＭＰスヌーピングの機能が実装されないスイッチングハブでは、ＩＧＭＰクエリアからのマルチキャストデータを全てのホストに中継するしかないが、スイッチングハブ９１は、メンバの認識に基づきメンバでないホストにはマルチキャストデータを中継しないようにできる。
【０００８】
【特許文献１】特開２００４−１１２７２４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
ところで、メンバがマルチキャストグループから離脱して配信を不要とする場合、図９に示されるように、該メンバであるホスト９４が配信元であるＩＧＭＰクエリアに離脱メッセージ（ＩＧＭＰ−Ｌｅａｖｅ）を送信する。図１０に示されるように、離脱メッセージを受信したＩＧＭＰクエリア９２は、マルチキャストで確認要求メッセージ（ＩＧＭＰ−Ｑｕｅｒｙ）を送信する。図１１に示されるように、この確認要求メッセージを受信した全ホスト９３，９４，９５の中で、メンバとなっているホスト９３，９５のみが確認応答メッセージ（ＩＧＭＰ−Ｒｅｐｏｒｔ）をＩＧＭＰクエリア９２に送信する。
【００１０】
ＩＧＭＰクエリア９２では確認応答メッセージを１つでも受信した場合は、マルチキャストデータの送信を継続し、確認応答メッセージを１つも受信しなかった場合は、メンバなしと認識してマルチキャストデータの送信を停止する。
【００１１】
しかし、図１１に示されるように、複数のメンバが確認応答メッセージを送信すると、確認応答メッセージがＩＧＭＰクエリア９２に一度に集中するため、ＩＧＭＰクエリアは一時的に負荷過剰となる。なお、図９〜図１１は、簡単のためホストを３台としているが、ホストの台数に制限はなく、さらに、スイッチングハブを多段に接続することも可能であるから、メンバの数は非常に多数となり、確認応答メッセージの集中は甚大となる。
【００１２】
そこで、本発明の目的は、上記課題を解決し、配信元への負荷の集中を回避できるスイッチングハブを提供することにある。
【課題を解決するための手段】
【００１３】
上記目的を達成するために本発明は、複数のポートと、ポートで受信したマルチキャスト制御用のメッセージを解釈するメッセージ解釈部と、このメッセージ解釈に基づいて当該マルチキャストグループのメンバを認識するメンバ認識部と、この認識に基づきマルチキャストの配信元からのマルチキャストデータを上記メンバのみに中継する選択中継部とを備えたスイッチングハブにおいて、上記配信元に宛てられ上記メンバから送信されたグループからの離脱を知らせる離脱メッセージを上記配信元に中継せず、上記配信元の代わりにメンバの確認を要求する確認要求メッセージを上記メンバに送信する配信元代理部とを備えたものである。
【００１４】
上記メンバ認識部におけるメンバの残存を管理し、最後のメンバから送信された離脱メッセージを受信したとき、上記配信元に離脱メッセージを送信する最終離脱部を備えてもよい。
【００１５】
上記配信元から送信されたメッセージから上記配信元のＩＰアドレスを取得する配信元ＩＰアドレス取得部を備え、上記配信元代理部は、確認要求メッセージの送信元アドレス欄に上記配信元のＩＰアドレスを格納して送信してもよい。
【発明の効果】
【００１６】
本発明は次の如き優れた効果を発揮する。
【００１７】
（１）配信元への負荷の集中を回避できる。
【発明を実施するための最良の形態】
【００１８】
以下、本発明の一実施形態を添付図面に基づいて詳述する。
【００１９】
図１に示されるように、本発明に係るスイッチングハブ１は、複数のポート２と、全てのポート２間でパケットの転送を行うスイッチＬＳＩ３と、スイッチングハブ１全体の動作を制御するＣＰＵ４と、ＣＰＵ４が実行するソフトウェアを格納したメモリ５とを備える。
【００２０】
ここでは、本発明に関連したソフトウェア・ハードウェアのみ説明し、本発明に特に関連しないスイッチングハブのソフトウェア・ハードウェアは周知のものが搭載されるものとし、説明を省く。
【００２１】
図示のように、メモリ５には、本発明に関連して、メッセージ解釈ソフトウェア、メンバ認識ソフトウェア、選択中継ソフトウェア、配信元代理ソフトウェア、最終離脱ソフトウェア、配信元ＩＰアドレス取得ソフトウェアが実装される。
【００２２】
メッセージ解釈ソフトウェアは、例えば、ＩＧＭＰにおいてＩＧＭＰスヌーピングをおこなうものであり、ＣＰＵ４で実行され、ポート２で受信したパケットに格納されている離脱メッセージ等のマルチキャスト制御用のメッセージを解釈するメッセージ解釈部１１を実現するものである。詳しくは、受信したパケットがＩＧＭＰパケットかどうかをＩＧＭＰメッセージの有無によって判定し、ＩＧＭＰタイプを読み取ってメッセージの種類を判定し、マルチキャストグループアドレスを読み取ってマルチキャストグループを判定する。
【００２３】
メンバ認識ソフトウェアは、ＣＰＵ４で実行され、メッセージ解釈部１１でのメッセージ解釈に基づいて当該マルチキャストグループのメンバを認識するメンバ認識部１２を実現するものである。詳しくは、参加メッセージを送信してきたホストはメンバと認識し、当該マルチキャストグループのメンバ一覧表にホストのアドレス又は接続ポートを書き込み、離脱メッセージを送信してきたメンバはメンバ一覧表から削除する。
【００２４】
選択中継ソフトウェアは、ＣＰＵ４で実行され、メンバ認識部１２での認識に基づきマルチキャストの配信元からのマルチキャストデータを該当するメンバのみに中継する選択中継部１３を実現するものである。詳しくは、配信元から受信したパケットについて、マルチキャストデータであるかどうか判定し、マルチキャストグループを判定し、そのマルチキャストグループのメンバ一覧表から送信が必要なホストのアドレス又は接続ポートを判定する。
【００２５】
ここまでのソフトウェアは、図９に示した従来のスイッチングハブがすでに実装していたものである。以下のソフトウェアは、本発明のスイッチングハブのみが実装するものである。
【００２６】
配信元代理ソフトウェアは、ＣＰＵ４で実行され、配信元に宛てられメンバから送信された離脱メッセージを配信元に中継せず、配信元の代わりに確認要求メッセージをメンバに送信する配信元代理部１４を実現するものである。詳しくは、ホストから受信したパケットについてメッセージ解釈部１１でのメッセージ解釈に基づいて離脱メッセージであるかどうか判定し、そのマルチキャストグループアドレスを格納した確認要求メッセージを作成し、当該ホストに送信する。
【００２７】
配信元代理ソフトウェア（配信元代理部１４）は、さらに、確認要求メッセージの送信元アドレス欄に配信元のＩＰアドレスを格納して送信する機能を有する。すなわち、自身（スイッチングハブ１）がホスト（離脱メッセージを送信してきたメンバ）に対して送信する確認要求メッセージのＩＰヘッダの送信元アドレス欄に配信元であるＩＧＭＰクエリアのＩＰアドレスを格納する。配信元のＩＰアドレスは、後述する配信元ＩＰアドレス取得部１６が取得する。
【００２８】
最終離脱ソフトウェアは、ＣＰＵ４で実行され、メンバ認識部１２におけるメンバの残存を管理し、最後のメンバから送信された離脱メッセージを受信したとき、配信元に離脱メッセージを送信する最終離脱部１５を実現するものである。詳しくは、離脱メッセージに書き込まれているマルチキャストグループについてのメンバ一覧表を参照し、当該マルチキャストグループのメンバ一覧表に格納されているメンバの個数を調べ、個数が１であれば最後のメンバと判定する。
【００２９】
配信元ＩＰアドレス取得ソフトウェアは、ＣＰＵ４で実行され、配信元から送信されたメッセージから配信元のＩＰアドレスを取得する配信元ＩＰアドレス取得部１６を実現するものである。メッセージはＩＰパケットに格納して送信されるので、ＩＰアドレスを取得することは簡単である。
【００３０】
メモリ５には、上記の各ソフトウェアを実行する際に必要となる変数・定数、例えば、マルチキャスト制御用の各種メッセージを運ぶパケットのフォーマット、送信しようとするパケット、受信したパケット、メッセージ解釈結果、マルチキャストグループの一覧表、グループごとのメンバ一覧表、グループごとのメンバの残存数、グループごとの配信元のＩＰアドレスなどを格納するエリアが各々確保される。
【００３１】
以上のソフトウェア・ハードウェア構成により、本発明に係るスイッチングハブ１は、複数のポート２と、ポートで受信したマルチキャスト制御用のメッセージを解釈するメッセージ解釈部１１と、このメッセージ解釈に基づいて当該マルチキャストグループのメンバを認識するメンバ認識部１２と、この認識に基づきマルチキャストの配信元からのマルチキャストデータを上記メンバのみに中継する選択中継部１３とを備えたスイッチングハブにおいて、上記配信元に宛てられ上記メンバから送信されたグループからの離脱を知らせる離脱メッセージを上記配信元に中継せず、上記配信元の代わりにメンバの確認を要求する確認要求メッセージを上記メンバに送信する配信元代理部１４とを備えたスイッチングハブ１として動作する。
【００３２】
さらに、スイッチングハブ１は、メンバ認識部１２におけるメンバの残存を管理し、最後のメンバから送信された離脱メッセージを受信したとき、上記配信元に離脱メッセージを送信する最終離脱部１５と、上記配信元から送信されたメッセージから上記配信元のＩＰアドレスを取得する配信元ＩＰアドレス取得部１６を備え、上記配信元代理部１４は、確認要求メッセージの送信元アドレス欄に上記配信元のＩＰアドレスを格納して送信することができる。
【００３３】
図２に、マルチキャスト制御用のメッセージを格納するパケットのフォーマットの例として、ＩＧＭＰパケットのフォーマットを示す。
【００３４】
図２（ａ）に示されるように、ＩＧＭＰパケット２０１は、ＩＰパケット２０２にＩＧＭＰメッセージを格納したものであり、ＩＰパケット２０２の宛先・送信元アドレスを格納する欄であるＩＰヘッダ２０３に続けてＩＧＭＰメッセージを格納するＩＧＭＰメッセージ欄２０４が設けられる。
【００３５】
図２（ｂ）に示されるように、ＩＧＭＰメッセージ２１１は、ＩＧＭＰバージョンの欄２１２、ＩＧＭＰタイプの欄２１３、最大応答時間の欄２１４、チェックサム欄２１５、マルチキャストグループアドレスの欄２１６からなる。ＩＧＭＰタイプの欄２１３に、メッセージタイプを表すコードを格納することで、参加メッセージ（ＩＧＭＰ−Ｒｅｐｏｒｔ）、離脱メッセージ（ＩＧＭＰ−Ｌｅａｖｅ）、確認要求メッセージ（ＩＧＭＰ−Ｑｕｅｒｙ）、確認応答メッセージ（ＩＧＭＰ−Ｒｅｐｏｒｔ）を識別することができる。
【００３６】
図１のスイッチングハブ１がメンバであるホストからＩＧＭＰメッセージを受信したときの処理アルゴリズムを図３に示す。処理アルゴリズムは、メンバからパケットを受信するステップ３１、離脱メッセージかどうか判定するステップ３２、離脱メッセージであったＹＥＳのとき確認要求メッセージを各ホストに送信するステップ３３と、送信後の応答待ち時間を計測する離脱タイマを起動するステップ３４と、確認応答メッセージを受信したかどうか判定するステップ３５と、確認応答メッセージを受信していないＮＯのとき離脱タイマがタイムアウトになったかどうか判定し、離脱タイマがタイムアウトしていないＮＯのとき、上記ステップ３５に戻り待ちを続けるステップ３６と、離脱タイマがタイムアウトしたＹＥＳのとき、メンバの残存がなくなったという認識をして離脱メッセージを配信元に送信するステップ３７とを有する。ステップ３２でＮＯ、ステップ３５でＹＥＳのときはマルチキャスト制御に関して何もしない。
【００３７】
図１のスイッチングハブ１を用いて構成した簡単なネットワークを図４に示すと共に、このネットワークにおける本発明のスイッチングハブ１の動作を説明する。
【００３８】
このネットワーク４１は、図９のネットワークと同一ネットワーク構造であり、配信元であるルータ４２と、本発明のスイッチングハブ１と、３台のホスト４３，４４，４５を有する。各装置はパケットを相互に送受信することにより、パケットに格納したデータやメッセージをやり取りするが、以下では、説明を省略し、マルチキャスト制御に関するメッセージをやり取りするものとして説明する。
【００３９】
まず、図４に示されるように、現状において、３台のホスト４３，４４，４５は全てメンバであるとする。このうちの１つであるホスト４４が離脱メッセージを送信し、スイッチングハブ１がその離脱メッセージを受信する。スイッチングハブ１は、従来のようにこの離脱メッセージをルータ４２に転送するのではなく、自身がルータ４２の代わりに確認要求メッセージを当該ホスト４４に送信する。このホスト４４は離脱メッセージを送信した後なので、確認応答メッセージは送信しない。
【００４０】
スイッチングハブ１は、ホスト４３，４５には確認要求メッセージを送信しないので、ホスト４３，４５は確認応答メッセージを送信しない。
【００４１】
この結果、ルータ４２では確認応答メッセージが１つも受信されない。ルータ４２は、確認要求メッセージを送信していないので、確認応答メッセージが受信されなくても、メンバに変動があったことを認識しない。よって、この後もルータ４２は、マルチキャストデータの送信を継続する。スイッチングハブ１は、そのマルチキャストデータを残ったメンバである２つのホスト４３，４５のみに中継する。
【００４２】
その後、図５に示されるように、ホスト４３が最後のメンバとして残存している状態となり、さらに、そのホスト４３が離脱メッセージを送信し、スイッチングハブ１がその離脱メッセージを受信する。スイッチングハブ１は、メンバの残存を管理しているので、ホスト４３が最後のメンバであることが認識できる。そこで、スイッチングハブ１は、ルータ４２に離脱メッセージを送信する。
【００４３】
これに対応してルータ４２は確認要求メッセージを送信するが、これを受信したスイッチングハブ１は、自身に接続されているホスト４３，４４，４５の中にメンバがいないことを認識しているので、確認要求メッセージをどのホスト４３，４４，４５にも中継せず、自身がルータ４２に確認応答メッセージを送信することもない。
【００４４】
この結果、ルータ４２には確認応答メッセージが１つも受信されない。ルータ４２は、確認要求メッセージを送信したことに対して確認応答メッセージが受信されないことにより、メンバが存在しないことを認識する。
【００４５】
以上の動作において、確認応答メッセージがルータ４２に一度に集中することがないので、負荷の集中を回避できる。
【００４６】
次に、ネットワーク構成を変形した実施形態を説明する。
【００４７】
図６に示したネットワーク６１では、スイッチングハブ１に対してＩＧＭＰスヌーピング等のメッセージ解釈部を持たないハブ６２が接続され、そのハブ６２にホスト６３，６４，６５が接続されている。他の構成は図４のネットワークと同じである。
【００４８】
ここで、ホスト６４がメンバであり、他にメンバがあるかどうか不明とする。ホスト６４が離脱メッセージを送信したとき、ハブ６２は、メッセージ解釈部を持たないので、離脱メッセージを解釈することなく、そのままスイッチングハブ１に中継する。離脱メッセージを受信したスイッチングハブ１は、確認要求メッセージをハブ６２に送信し、ハブ６２は、確認要求メッセージをそのまま全ホスト６３，６４，６５に中継する。
【００４９】
図７に示されるように、メンバであるホスト６３，６５は確認応答メッセージを送信し、ハブ６２は、これらの確認応答メッセージをそのまま中継する。スイッチングハブ１は、確認応答メッセージを受信し、メンバが存在することを確認するが、確認応答メッセージをルータ４２には中継しない。
【００５０】
この結果、ルータ４２が送信したマルチキャストデータはスイッチングハブ１がハブ６２に中継し、ハブ６２は無条件にこれを中継するので、メンバであるホスト６３，６５はマルチキャストデータを受信することができる。
【００５１】
図８に示したネットワーク８１では、同じマルチキャストグループに属する複数の配信元（ＩＧＭＰクエリア）が存在する。すなわち、図４で説明したのと同じルータ４２がメインの配信元となっており、図６で説明したのと同じハブ６２にサブの配信元であるルータ８２が接続されている。
【００５２】
ここで、メンバであるホスト６４が離脱メッセージを送信すると、スイッチングハブ１が確認要求メッセージを送信し、ハブ６２は、確認要求メッセージをそのまま中継する。このため、ルータ８２も確認要求メッセージを受信する。このとき、ルータ８２が受信した確認要求メッセージの送信元ＩＰアドレスがメインの配信元のＩＰアドレスと異なると、ルータ８２が誤動作する。その点、本発明では、スイッチングハブ１が送信した確認要求メッセージの送信元ＩＰアドレスは、ルータ４２のＩＰアドレスとなっている。したがって、ルータ８２が誤動作することがない。
【００５３】
マルチキャスト制御のプロトコルとしてＩＧＭＰを例にとって説明したが、これに限らす、配信元とホストとの間でこれまで説明したようなメッセージが送受信されるプロトコルが使用されているネットワークにおいては、スイッチングハブに本発明を適用することができる。
【図面の簡単な説明】
【００５４】
【図１】本発明の一実施形態を示すスイッチングハブの内部構成図である。
【図２】（ａ）はＩＧＭＰパケットのフォーマット、（ｂ）はＩＧＭＰメッセージのフォーマットを示す図である。
【図３】本発明のスイッチングハブがホストからパケットを受信したときの処理流れ図である。
【図４】本発明のスイッチングハブを用いたネットワークの構成図である。
【図５】図４のネットワークの別のタイミングにおける構成図である。
【図６】本発明の他の実施形態によるネットワークの構成図である。
【図７】図６のネットワークの別のタイミングにおける構成図である。
【図８】本発明の他の実施形態によるネットワークの構成図である。
【図９】従来のスイッチングハブを用いたネットワークの構成図である。
【図１０】図９のネットワークの別のタイミングにおける構成図である。
【図１１】図９のネットワークの別のタイミングにおける構成図である。
【符号の説明】
【００５５】
１  スイッチングハブ
２  ポート
３  スイッチＬＳＩ
４  ＣＰＵ
５  メモリ
１１  メッセージ解釈部
１２  メンバ認識部
１３  選択中継部
１４  配信元代理部
１５  最終離脱部
１６  配信元ＩＰアドレス取得部
【図１】
2008141353.tif 000003
【図２】
2008141353.tif 000004
【図３】
2008141353.tif 000005
【図４】
2008141353.tif 000006
【図５】
2008141353.tif 000007
【図６】
2008141353.tif 000008
【図７】
2008141353.tif 000009
【図８】
2008141353.tif 000010
【図９】
2008141353.tif 000011
【図１０】
2008141353.tif 000012
【図１１】
2008141353.tif 000013