(57)【要約】【課題】  あるマルチキャストグループに未登録のホストから、そのマルチキャストグループへの参加又は離脱の要求があった場合、その未登録ホストのみに対して応答する手段を備えたパケット転送装置を提供する。【解決手段】  パケット転送装置１１は、ホスト１０−３から参加又は離脱要求を行うグループ（２２４．１０．１０．１０）の識別子を含むパケットを受信すると、そのパケットの送信元ホスト１０−３が上記グループに登録されているか否かを判断する手段と、未登録の場合、上記グループ識別子（第１のグループ識別子）をその未登録ホスト１０−３宛に情報を配信する配信サーバ１２−２に付与されている第２のグループ識別子に変換し、そのパケットを配信サーバ１２−２に送信する手段と、上記配信サーバ１２−２から上記情報を含むパケットを受信すると、そのパケットに含まれる上記第２のグループ識別子を上記第１のグループ識別子に変換し、そのパケットを未登録ホスト１０−３に送信する手段を備える。【選択図】  図１
2006005814.tif 000002
【特許請求の範囲】
【請求項１】
複数の通信端末と通信網に接続され、前記通信端末及び前記通信網とマルチキャスト通信を行うパケット転送装置であって、
予め前記マルチキャスト通信により送信されるパケットの送信先グループ毎に割り当てられるグループ識別子を、前記パケットの送信先となる複数の通信端末のアドレスに対応付けて記憶する記憶部と、
前記通信端末もしくは前記通信網と前記グループ識別子を含むパケットの送受信を行う複数の回線インタフェースと、
第１の通信端末の出力であって、前記複数の回線インタフェースの何れかで受信した第１のパケットに含まれる第１のグループ識別子及び前記第１の通信端末のアドレスが前記記憶部に記憶されているか否かを判断する手段と、前記第１のグループ識別子を第２のグループ識別子に変換し、該第１のパケットを前記通信網に送信するように制御する手段と、前記通信網から前記第２のグループ識別子を含む第２のパケットを受信すると、前記第２のグループ識別子を前記第１のグループ識別子に変換し、該第２のパケットを前記第１の通信端末に送信するように制御する手段を有する制御部と、
を備えたことを特徴とするパケット転送装置。
【請求項２】
前記制御部は、前記複数の回線インタフェースの何れかで受信した第１のパケットに含まれる第１のグループ識別子及び前記第１の通信端末のアドレスが前記記憶部に記憶されているか否かを判断し、記憶されていない場合、前記第１のグループ識別子を第２のグループ識別子に変換することを特徴とする請求項１記載のパケット転送装置。
【請求項３】
前記第１のパケットは、マルチキャストグループ参加要求を示すパケットであることを特徴とする請求項１又は請求項２記載のパケット転送装置。
【請求項４】
前記第２のパケットには、配信拒否を示す情報が含まれていることを特徴とする請求項１乃至請求項３記載のパケット転送装置。
【請求項５】
前記第１のパケットは、マルチキャストグループ離脱要求を示すパケットであることを特徴とする請求項１又は請求項２記載のパケット転送装置。
【請求項６】
前記第１、第２のパケットは、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍｅｍｂｅｒｓｈｉｐ Ｐｒｏｔｏｃｏｌ）パケットであることを特徴とする請求項１乃至請求項５記載のパケット転送装置。
【請求項７】
前記第１、第２のパケットは、ＭＬＤ（Ｍｕｌｔｉｃａｓｔ Ｌｉｓｔｅｎｅｒ Ｄｉｓｃｏｖｅｒｙ）パケットであることを特徴とする請求項１乃至請求項５記載のパケット転送装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツ等の情報の配信に用いられるマルチキャスト通信技術に関する。
【背景技術】
【０００２】
多数の（ユーザ）端末に同時に同一の情報（コンテンツ等）を配布する時に有効な通信技術として、マルチキャスト通信技術が知られている。マルチキャスト通信は、複数の端末の各々に対して１対１通信で情報を配信するユニキャスト通信に比べて、配信サーバの負荷削減やトラフィック量の削減という点で利点がある。マルチキャスト通信では、ＩＰｖ４ではＩＧＭＰ「Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍｅｍｂｅｒｓｈｉｐ Ｐｒｏｔｏｃｏｌ」、ＩＰｖ６ではＭＬＤ「Ｍｕｌｔｉｃａｓｔ Ｌｉｓｔｅｎｅｒ Ｄｉｓｃｏｖｅｒｙ」がプロトコルとして使用される。ＩＧＭＰは、ＩＥＴＦ「Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ」がインターネット標準として公開するＲＦＣ１１１２(非特許文献１)やＲＦＣ２２３６(非特許文献２)で定義されている。同様に、ＭＬＤは、ＲＦＣ２７１０(非特許文献２)で定義されている。
【０００３】
上記ＩＧＭＰやＭＬＤは、ホストとパケット転送装置（ゲートウェイ、ルータ等）との間で使用され、同一のデータを複数のホストに効率よく配送するマルチキャストで、配送を受けるために構成されるホストのグループ（マルチキャストグループ）を制御するためのプロトコルである。ホストがマルチキャストグループに参加要求（マルチキャストデータの配信要求）をしたり、そのマルチキャストグループから離脱要求（マルチキャストデータの配信停止要求）をしたりする際に、ＩＧＭＰやＭＬＤが使用される。
【０００４】
あるマルチキャストグループに登録されているホストからの要求により、情報配信サーバから情報がパケット形式で配信されると、下位のパケット転送装置（ゲートウェイ、ルータ等）がそのパケットを受信し、そのパケットを要求のあったマルチキャストグループに属するホスト数分コピーし、それらのホストに対して転送する。
【０００５】
【非特許文献１】ＲＦＣ１１１２  ４章、７章、ＡＰＰＥＮＤＩＸ １
【非特許文献２】ＲＦＣ２２３６  ２章、３章、６章、７章
【非特許文献３】ＲＦＣ２７１０  ３章、４章、５章、６章
【発明の開示】
【発明が解決しようとする課題】
【０００６】
前述のマルチキャスト通信技術によれば、例えば、ホストが、特定のマルチキャストグループに参加したり、そのマルチキャストグループから離脱したい場合、ＩＧＭＰやＭＬＤを使用してパケット転送装置にその旨を伝える。パケット転送装置は、ＩＧＭＰやＭＬＤにより、配下のマルチキャストグループに属する全てのホスト（登録ホスト）を把握できる。従って、パケット転送装置は、登録ホストに対して、１つのマルチキャスト用のパケットをホスト数分コピーして、それを同時に送信すれば良いので、マルチキャストデータを効率よく転送できる。
【０００７】
一方で、あるマルチキャストグループに未登録のホストのユーザが、誤ってその未登録のマルチキャストグループにアクセスする場合が想定される。この場合、未登録ホストは、パケット転送装置に対して、マルチキャストグループへの参加を要求するパケットを送信する。しかしながら、パケット転送装置は、未登録ホストからの参加要求に対してはアクセスを拒否して、受信パケットを廃棄するのみで、未登録ホストに対しては何も応答しない。そのため、未登録ホストは、要求したマルチキャストグループに参加できないことを確認できない。仮に未登録ホストに対して応答すると、参加要求がされたマルチキャストグループに属する全てのホストに対してデータ配信拒否の通知がなされてしまう。
【０００８】
又、コンテンツを配信する事業者は、未登録ホストに対しても、配信コンテンツの予告やダイジェストを流して、未登録のマルチキャストグループへの登録を促したいとの要望がある。しかしながら、前述のように、従来のパケット転送装置には、未登録ホストのみに対して、応答する手段がない。
【０００９】
本発明は、上記点に鑑みてなされたもので、あるマルチキャストグループに未登録のホストから、そのマルチキャストグループへの参加又は離脱の要求があった場合、その未登録ホストのみに対して応答する手段を備えるパケット転送装置を提供することにある。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、複数のホストと、これらホストと接続されたゲートウェイと、このゲートウェイ及びあるマルチキャストグループに登録されているホストに対して情報を配信する配信サーバ（第１の配信サーバ）と接続された通信網からなる通信システムにおいて、マルチキャストグループに未登録のホストに対して、配信拒否等の情報を含むパケットを配信する配信サーバ（第２の配信サーバ）を設けている。
【００１１】
上記ゲートウェイは、ホストから、あるマルチキャストグループに対して参加又は離脱の要求を示すパケットを受信すると、その要求元のホストが、要求のあったマルチキャストに登録されているか否かを判断し、登録されていれば、第１の配信サーバに受信パケットを送信し、登録されていなければ、受信パケットに含まれる上記第１の配信サーバのマルチキャストグループを識別する情報（第１のグループ識別子）を上記第２の配信サーバのマルチキャストグループを識別する情報（第２のグループ識別子）に変換し、そのパケットを上記第２の配信サーバに送信する。又、ゲートウェイは、上記第２の配信サーバから上記第２のグループ識別情報を含むパケットを受信すると、上記第２のグループ識別情報を上記第１の識別情報に変換し、そのパケットを未登録ホストに対して送信する。
【発明の効果】
【００１２】
本発明によれば、あるマルチキャストグループに未登録のホストから、そのマルチキャストグループへの参加又は離脱の要求があった場合、その未登録ホストに対して応答する手段を提供することができるので、未登録ホストのユーザは、そのマルチキャストグループに参加できないことを確認できる。
【００１３】
又、本発明によれば、コンテンツ配信事業者は、未登録ホストに対しても、配信コンテンツの予告やダイジェストを流することができるので、画像や音声を使った様々なサービスを実現可能となり、未登録のマルチキャストグループへの登録を促すことができる。
【００１４】
更に、本発明によれば、上記手段を実現するために、ホストに対して新たな機能追加や設定等は必要ないので、ユーザに負担をかけることなく、より高度なサービスを提供できる。
【発明を実施するための最良の形態】
【００１５】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
【実施例１】
【００１６】
図１は、本発明のパケット転送装置が用いられる通信システム１の構成を示す図である。本実施例では、ＩＧＭＰを用いたマルチキャスト通信の場合について説明する。通信システム１は、複数のホスト（通信端末）（１０−１、１０−２、１０−３）と、これらホストと接続されたパケット転送装置（例えば、ゲートウェイ）１１と、配信サーバ（１２−１、１２−２、１２−３）と、上記ゲートウェイ及び配信サーバと接続されたバックボーンネットワーク（通信網）（例えば、ＩＰｖ４網）１４とから構成されている。ネットワーク１４は、例えば、ルータ１５を有し、マルチキャストデータを受信するホストは、ゲートウェイ１１、ルータ１５を介して、配信サーバ１２−１又は１２−２又は１２−３に接続される。
【００１７】
ここで、各ホストのユーザは、予め情報配信会社と視聴できるチャンネルを契約しており、その情報は予めゲートウェイ１１に登録されている。マルチキャストグループは、各チャンネル番号と対応している。ホスト１０−１（Ｒ１）、１０−２（Ｒ２）は、契約済のチャンネルの視聴（マルチキャストグループへの参加）を試みる登録ホストを示し、ホスト１０−３（Ｕ１）は、未契約のチャンネルの視聴（登録ホスト１０−１、１０−２のグループへの参加）を試みる未登録ホストを示す。
【００１８】
各ホストには、ＩＰアドレスとマルチキャストグループを識別するＩＤ（マルチキャストアドレス）が付与されている。配信サーバは、グループ（チャンネル毎）に存在し、これら配信サーバにもＩＰアドレスとグループＩＤが付与されている。本実施例では、ホスト１０−１、１０−２と配信サーバ１２−１は、グループＩＤが（２２４．１０．１０．１０）であるので、同一のグループである。同様に、ホスト１０−３と配信サーバ１２−２は、グループＩＤが（２２４．１０．１０．２０）であるので、同一のグループである。
【００１９】
又、詳細を後述するが、配信サーバ１２−２は、例えば、マルチキャストグループ１に未登録のホスト１０−３が、グループＩＤ（２２４．１０．１０．１０）のグループに対して参加要求を行った場合、その未登録ホスト１０−３に対して、配信拒否の通知をしたり、グループＩＤ（２２４．１０．１０．１０）のグループへの登録を促すため、配信コンテンツの予告やダイジェストを流すためのサーバ（未登録ホスト宛の配信サーバ）であり、配信サーバ１２−１を所有する事業者と同じ事業者が所有する。この配信サーバ１２−２にも、グループＩＤ（２２４．３０．３０．３０）が付与されている。この場合、ゲートウェイ１１がグループＩＤ（アドレス）変換機能を有し、未登録ホスト１０−３から参加要求メッセージを受信すると、その参加要求メッセージに含まれるグループＩＤ（２２４．１０．１０．１０）をグループＩＤ（２２４．３０．３０．３０）に変換して出力することにより、上記参加要求メッセージが配信サーバ１２−２に転送される。
【００２０】
又、本実施例では、ホスト１０−１、１０−２、１０−３に接続されるゲートウェイ１１のポート番号を各々１、２、３とし、ネットワークに接続されるゲートウェイのポート番号をｍ、ｎとする。尚、通信システム１内では、前述のメッセージが、ヘッダ１７を有するパケット１６の形で送受信される。従って、ポート番号は、ゲートウェイ１１がパケット１６を送受信するホストを特定するために使用される。
【００２１】
図２は、通信システム１で用いられるＩＧＭＰメッセージのヘッダ２０の構成を示す図である。ＲＦＣ１１１２、２２３６に記載されているように、ＩＧＭＰメッセージのヘッダ２０は、Ｔｙｐｅ２１、Ｍａｘｉｍｕｍ Ｒｅｓｐｏｎｓｅ Ｔｉｍｅ２２、Ｃｈｅｃｋｓｕｍ２３、Ｇｒｏｕｐ Ａｄｄｒｅｓｓ２４の各フィールドを有する。
【００２２】
Ｔｙｐｅ２１は、ＩＧＭＰメッセージタイプの種別を示し、この内容により、ＩＧＭＰメッセージが、Ｍｅｍｂｅｒｓｈｉｐ Ｑｕｅｒｙ(マルチキャストグループ参加)、Ｍｅｍｂｅｒｓｈｉｐ Ｒｅｐｏｒｔ(マルチキャストグループ報告)、Ｌｅａｖｅ Ｇｒｏｕｐ（マルチキャストグループ離脱）の何れを表すメッセージなのかを識別できる。尚、前述の参加要求メッセージの場合は、Ｔｙｐｅ２１の内容が、Ｍｅｍｂｅｒｓｈｉｐ Ｑｕｅｒｙ(マルチキャストグループ参加)となる。
【００２３】
Ｍａｘｉｍｕｍ Ｒｅｓｐｏｎｓｅ Ｔｉｍｅ２２は、ＩＧＭＰメッセージを送信するための最大遅延時間を示す。Ｇｒｏｕｐ Ａｄｄｒｅｓｓ２４には、ＩＰｖ４用のマルチキャストグループＩＤが入る。
【００２４】
図３は、本発明によるゲートウェイ１１の構成を示すブロック図である。ゲートウェイ１１は、複数の回線インタフェース３０−ｉ（ｉは、０以外の自然数）と複数のプロトコル処理部３１−ｉと内部スイッチ３２とこれらを統括的に制御する制御部３３等から構成されている。
【００２５】
回線インタフェース３０−ｉは、ホスト１０−ｉとネットワーク１４とのインタフェースであり、ホスト１０−ｉ、ネットワーク１４とパケットの送受信を行う。本実施例では、１つの回線インタフェースに対して１つのホストが接続されている。従って、１つの回線インタフェースには、１つのポートが存在することになるので、回線インタフェース毎に１つのポート番号が付与される。
【００２６】
プロトコル処理部３１−ｉは、あるマルチキャストグループに未登録のホストから、そのマルチキャストグループへの参加又は離脱の要求があった場合に、その未登録ホストのみに対して応答する手段を有する。又、プロトコル処理部３１−ｉは、パケットをマルチキャストグループのホスト数分コピーする手段や、それらのパケット（マルチキャストパケット）のルーティング処理等を行う手段を備える。
【００２７】
内部スイッチ３２は、プロトコル処理部３１−ｉから受信したパケットを、該パケットのヘッダ情報に基づき、複数のプロトコル処理部３１−ｉの何れかに出力する。
【００２８】
図４は、プロトコル処理部３１−ｉの詳細な構成を示すブロック図である。プロトコル処理部３１−ｉは、回線インタフェース３０−ｉからパケットを受信するための回線側受信バッファ４０と、プロトコル処理を実行するプロセッサ４１と、内部スイッチ３２にパケットを送信するための内部イッチ側送信バッファ４２と、内部スイッチ３２からパケットを受信するための内部スイッチ側受信バッファ４３と、回線インタフェース３０−ｉにパケットを送信するための回線側送信バッファ４４と、各種テーブル（ユーザ管理テーブル４５−１、配信サーバ管理テーブル４５−２、送信先テーブル４５−３）を格納するメモリ（記憶部）４５と、制御部３３とのインタフェースであるプロセッサ間インタフェース４６とから構成されている。
【００２９】
ここで、プロセッサ４１は、回線側受信バッファ４０に蓄積されたパケットを読み出してメッセージの形にし、前述のプロトコル処理を行った後、再度、そのメッセージをパケットに組立てて内部スイッチ側送信バッファ４２に出力する。プロセッサ４１は、内部スイッチ３２から受信したパケットについてもこれと同様の処理を行う。
【００３０】
図５は、ユーザ管理テーブル４５−１の構成を示す図である。ユーザ管理テーブル４５−１には、ホスト（１０−１、・・・１０−３）のＩＰアドレス５０とポート番号５２と各ホストのグループＩＤ５１とが記憶されている。
【００３１】
本実施例では、ゲートウェイ１１に備えるプロトコル処理部３１−ｉが、受信パケットの内容（ＩＰアドレス、グループＩＤ）とこのユーザ管理テーブル４５−１の内容に基づいて、上記受信パケット送信元ホストの登録の有無を判断するのに用いる。
【００３２】
図６は、配信サーバ管理テーブル４５−２の構成を示す図である。配信サーバ管理テーブル４５−２には、グループＩＤ６０と、そのグループＩＤに対応する配信サーバのＩＰアドレス６１と、あるマルチキャストグループに未登録のホストがそのマルチキャストグループへの参加等の要求があった場合にその未登録ホスト宛てに情報を配信する配信サーバのグループＩＤ６２と、そのグループＩＤに対応する配信サーバ（未登録ホスト宛の配信サーバ）のＩＰアドレス６３とが記憶されている。
【００３３】
本実施例では、ゲートウェイ１１に備えるプロトコル処理部３１−ｉが、受信パケットの内容（グループＩＤ）と配信サーバ管理テーブル４５−２の内容とに基づいて、受信パケットに含まれる参加要求メッセージのグループＩＤを未登録ホスト宛の配信サーバのグループＩＤに変換する。
【００３４】
図７は、送信先テーブル４５−３の構成を示す図である。送信先テーブル４５−３には、グループＩＤ７０と、そのグループＩＤを有する登録ホストと未登録ホストに対して、何れのホストにパケットを出力するかを特定するためのポート番号７１、７２とが記憶されている。
【００３５】
本実施例では、ゲートウェイ１１に備えるプロトコル処理部３１−ｉが、受信パケットの内容（グループＩＤ）と送信先テーブル４５−３の内容等に基づいて、受信パケットの出力先を特定する。
【００３６】
図８は、ホスト（１０−１〜１０−３）画面の構成例を示す図である。ホスト画面は、配信サーバからの情報（コンテンツ）を表示する表示部８０と、視聴したい情報のチャンネルを入力するチャンネル（Ｃｈａｎｎｅｌ）入力部８１と、情報配信を要求（グループ参加要求）する開始（ＳＴＡＲＴ）ボタン８２と、情報配信の停止を要求（グループ離脱要求）する停止（ＳＴＯＰ）ボタン８３等を備えている。
【００３７】
尚、図８に示す画面では、配信サーバから何も情報を受信していない状態を示している。例えば、情報配信会社と契約済みのチャンネルをホスト画面のチャンネル入力部８１に入力し、開始ボタン８２を押すと、参加要求メッセージ用のパケットが、ゲートウェイ１１、ネットワーク１４を介して配信サーバに送られ、配信サーバからはそのチャンネルに相当する情報がネットワーク１４、ゲートウェイ１１を介して送られ、ホスト画面の表示部８０に表示される。又、既に他の契約済みチャンネルの情報を視聴している場合には、表示部８０にはその情報が流れており、その状態で更に別のチャンネルの情報が見たい場合には、チャンネル入力部８１にそのチャンネルを入力すれば良い。
【００３８】
図９〜図１１は、本発明によるゲートウェイ１１の動作を示すフローチャートである。
（１）グループ（登録配信サーバ）参加要求
まず、グループＩＤ（２２４．１０．１０．１０）のホスト１０−１（Ｒ１）が、グループＩＤ（２２４．１０．１０．１０）の配信サーバ１２−１に参加要求を行う場合（図１）のゲートウェイ１１の動作について説明する。例えば、ホスト１０−１のユーザが、配信サーバ１２−１の所有者（情報配信会社）と契約しているチャンネルのうち、チャンネル１０の情報を視聴したいとする。この時、配信サーバ１２−１から全く情報を受信していない場合には、ホストの表示画面には何も表示されていない状態となる（図８）。この状態で、チャンネル入力部８１に、視聴したいデータのチャンネル１０を入力し（図１２）、開始ボタン８２を押すと、ホスト１０−１から、参加要求メッセージを含むパケット１６がゲートウェイ１１に送信される（図１）。
【００３９】
ゲートウェイ１１に備える回線インタフェース３０−１は、ホスト１０−１から参加要求用のパケット１６を受信すると（ステップＳ９０）、その受信パケットをプロトコル処理部３１−１に出力する。そのパケットは、プロトコル処理部３１−１に備える回線側受信バッファ４０に一時的に蓄積される。プロセッサ４１は、回線側受信バッファ４０に蓄積されたパケットを読み出し、そのパケットに含まれる参加要求メッセージのＴｙｐｅ２１（図２）の内容から、受信パケットが、グループ参加要求用のパケットであることを認識する（Ｓ９１）。次に、プロセッサ４１は、参加要求メッセージのＧｒｏｕｐ Ａｄｄｒｅｓｓ２４の内容（グループＩＤ：２２４．１０．１０．１０）とホスト１０−１のＩＰアドレス（１０．１．１．１）とに基づいて、ユーザ管理テーブル４５−１を検索し（Ｓ９２）、そのグループＩＤとＩＰアドレスが登録されているかどうかを判断する（Ｓ９３）。ここでは、グループＩＤ（２２４．１０．１０．１０）とＩＰアドレス（１０．１．１．１）がユーザ管理テーブル４５−１に登録されている（図５、５００−１）ので、プロセッサ４１は、ホスト１０−１がグループＩＤ（２２４．１０．１０．１０）のグループに登録されていると判断する。次に、プロセッサ４１は、そのグループＩＤに基づいて、配信サーバ管理テーブル４５−２を検索し（Ｓ１１０）、上記参加要求メッセージと取得した配信サーバ１２−１のＩＰアドレス（２０．２０．２０．１）を含むパケットを内部スイッチ側送信バッファ４２に出力する。そのパケットは、内部スイッチ３２に出力された後、内部スイッチ３２によって、パケットのヘッダに基づき複数のプロトコル処理部の何れか（例えば、３１−ｎ、図３）に出力され、それに接続されている回線インタフェース（例えば、３０−ｎ）を介して配信サーバ１２−１に送信（Ｓ１１１）される（図１）。
【００４０】
配信サーバ１２−１は、ゲートウェイ１１から上記グループ参加要求用のパケットを受信すると、チャンネル１０の情報を含むパケットをルータ１５に送信する。
【００４１】
ゲートウェイ１１に備える回線インタフェース３０−ｎは、配信サーバ１２−１から受信したパケットをプロトコル処理部３１−ｎに出力する。プロトコル処理部３１−ｎに備えるプロセッサ４１は、回線側受信バッファ４０からパケットを読み出し、出力先（ホスト１０−１）となるポート番号１を、ユーザ管理テーブル４５−１を参照し、送信先テーブル４５−３の登録ホストのポート番号欄７１に追加（Ｓ１１２）する（図７、７００−１）とともに、パケットを内部スイッチ側送信バッファ４２に出力する。そのパケットは、上記同様にして回線インタフェース３０−１から出力され、ホスト１０−１に送信（Ｓ１１３）される（図１）。尚、ホスト１０−２も、ホスト１０−１と同じグループＩＤが付与されているので、ホスト１０−２にも上記パケットが送信される。
【００４２】
ホスト１０−１は、受信パケットに含まれる情報（映像等）をホスト画面の表示部８０に表示する（図１３）。これによって、ホスト１０−１のユーザは、視聴したい映像等が視聴できる。
（２）グループ（未登録配信サーバ）参加要求
次に、グループＩＤ（２２４．１０．１０．２０）のホスト１０−３（Ｕ３）が、グループＩＤ（２２４．１０．１０．１０）の配信サーバ１２−１に参加要求を行う場合の動作について説明する。例えば、ホスト１０−３のユーザが、配信サーバ１２−１の所有者（情報配信会社）と未契約のチャンネル（例えば、チャンネル１０）を図８に示すチャンネル入力部８１に誤って入力し（図１４）、開始ボタン８２を押したとする。この場合、ホスト１０−３から、参加要求メッセージを含むパケットがゲートウェイ１１に送信される（図１）。尚、Ｓ９０、Ｓ９１、Ｓ９２、Ｓ９３（図９）の処理は、上記（１）と同様である。ここでは、ホスト１０−３から送信されてきたパケットに含まれるグループＩＤ（２２４．１０．１０．１０）とＩＰアドレス（１０．１０．１０．１０）が、ユーザ管理テーブル４５−１に登録されていない（図５）ので、プロセッサ４１は、グループＩＤ（２２４．１０．１０．１０）に基づいて配信サーバ管理テーブル４５−２を検索し（Ｓ９４）、ホスト１０−３（未登録ホスト）宛配信サーバ１２−２のグループＩＤ（２２４．３０．３０．３０）とＩＰアドレス（３０．３０．３０．１）を取得する。次に、プロセッサ４１は、参加要求メッセージのＧｒｏｕｐ Ａｄｄｒｅｓｓ２４の内容を（２２４．１０．１０．１０）から（２２４．３０．３０．３０）に変換する（Ｓ９５）。次に、プロセッサ４１は、グループＩＤが変換された後の参加要求メッセージと配信サーバ１２−２のＩＰアドレス（３０．３０．３０．１）を含むパケットを内部スイッチ側送信バッファ４２に出力する。そのパケットは、内部スイッチ３２に出力された後、内部スイッチ３２によって、パケットのヘッダに基づき複数のプロトコル処理部の何れか（例えば、３１−ｍ、図３）に出力され、それに接続されている回線インタフェース（例えば、３０−ｍ）を介して配信サーバ１２−２に送信（Ｓ９６）される（図１）。
【００４３】
配信サーバ１２−２は、ゲートウェイ１１から上記パケットを受信すると、例えば、配信拒否を示す情報を含むパケットをルータ１５に送信する。
【００４４】
ゲートウェイ１１に備える回線インタフェース３０−ｍは、配信サーバ１２−２から受信したパケットをプロトコル処理部３１−ｍに出力する。プロトコル処理部３１−ｍに備えるプロセッサ４１は、回線側受信バッファ４０からパケットを読み出し、それに含まれる配信サーバ１２−２のグループＩＤ（２２４．３０．３０．３０）に基づいて配信サーバ管理テーブル４５−２を検索し（Ｓ９７）、ホスト１０−３のグループＩＤ（２２４．１０．１０．１０）を取得する。次に、プロセッサ４１は、参加要求メッセージのＧｒｏｕｐ Ａｄｄｒｅｓｓ２４の内容を（２２４．３０．３０．３０）から（２２４．１０．１０．１０）に変換する（Ｓ９８）。次に、プロセッサ４１は、出力先（ホスト１０−３）となるポート番号３をユーザ管理テーブル４５−１を参照し、送信先テーブル４５−３のポート番号欄７１に追加（Ｓ９９）する（図７、７００−１）とともに、パケットを内部スイッチ側送信バッファ４２に出力する。そのパケットは、上記同様にして回線インタフェース３０−３から出力され、ホスト１０−３に送信（Ｓ１００）される（図１）。
【００４５】
ホスト１０−１は、受信パケットに含まれる配信拒否を示す情報をホスト画面の表示部８０に表示する（図１４）。本実施例では、例えば、「未登録のため視聴できません。本チャンネルの登録をお願いいたします。」と表示される。尚、図１４に示す画面には、チャンネル１０のダイジェストや予告を流すようにしても良い。これによって、ホスト１０−３のユーザは、誤って未契約のチャンネルを入力したことを確認できる。又、コンテンツを配信する事業者は、未登録チャンネルへの登録を促すことができる。
（３）グループ（登録配信サーバ）離脱要求
ホスト１０−１のユーザが、図１３に示すチャンネル１０の情報を視聴している時（上記（１））に、その情報の配信停止を要求する（離脱要求）場合について説明する。ユーザが、ホスト画面の停止ボタン８３を押すと、ホスト１０−１から、離脱要求メッセージを含むパケットがゲートウェイ１１に送信される。
【００４６】
ゲートウェイ１１に備える回線インタフェース３０−１は、ホスト１０−１から離脱要求用のパケットを受信すると（ステップＳ９０）、その受信パケットをプロトコル処理部３１−１に出力する。そのパケットは、プロトコル処理部３１−１に備える回線側受信バッファ４０に一時的に蓄積される。プロセッサ４１は、回線側受信バッファ４０に蓄積されたパケットを読み出し、そのパケットに含まれる離脱要求メッセージのＴｙｐｅ２１（図２）の内容から、受信パケットが、グループ離脱要求用のパケットであることを認識する（Ｓ９１）。次に、プロセッサ４１は、参加要求メッセージのＧｒｏｕｐ Ａｄｄｒｅｓｓ２４の内容（グループＩＤ：２２４．１０．１０．１０）とホスト１０−１のＩＰアドレス（１０．１．１．１）とに基づいて、ユーザ管理テーブル４５−１を検索し（Ｓ１２０）、そのグループＩＤとＩＰアドレスが登録されているかどうかを判断する（Ｓ１２１）。ここでは、グループＩＤ（２２４．１０．１０．１０）とＩＰアドレス（１０．１．１．１）がユーザ管理テーブル４５−１に登録されている（図５、５００−１）ので、プロセッサ４１は、ホスト１０−１がグループＩＤ（２２４．１０．１０．１０）のグループに登録されていると判断する。次に、プロセッサ４１は、そのグループＩＤに基づいて、配信サーバ管理テーブル４５−２を検索し（Ｓ１３０）、上記離脱要求メッセージと取得した配信サーバ１２−１のＩＰアドレス（２０．２０．２０．１）を含むパケットを内部スイッチ側送信バッファ４２に出力する。そのパケットは、内部スイッチ３２に出力された後、内部スイッチ３２によって、パケットのヘッダに基づき複数のプロトコル処理部の何れか（例えば、３１−ｎ、図３）に出力され、それに接続されている回線インタフェース（例えば、３０−ｎ）を介して配信サーバ１２−１に送信（Ｓ１３１）される。
【００４７】
配信サーバ１２−１は、ゲートウェイ１１から上記グループ離脱要求用のパケットを受信すると、チャンネル１０の情報を含むパケットの配信を停止する。
【００４８】
又、プロトコル処理部３１−１に備えるプロセッサ４１は、離脱要求を行ったホスト１０−１が接続されているポートの番号１を送信先テーブル４５−３の登録ホストのポート番号欄７１から削除（Ｓ１３２）する。これによって、ホスト１０−１へのパケット送信が停止するので、ホスト１０−１のユーザは、チャンネル１０の情報が視聴できなくなる。
（４）グループ（未登録配信サーバ）離脱要求
ホスト１０−３のユーザが、チャンネル１０のダイジェストを視聴している時（上記（２）に、そのダイジェストの配信停止を要求する（離脱要求）場合について説明する。ユーザが、ホスト画面の停止ボタン８３を押すと、ホスト１０−３から、離脱要求メッセージを含むパケットがゲートウェイ１１に送信される。この場合、Ｓ９０、Ｓ９１、Ｓ１２０、Ｓ１２１（図９）の処理は、上記（３）と同様である。ここでは、ホスト１０−３から送信されてきたパケットに含まれるグループＩＤ（２２４．１０．１０．１０）とＩＰアドレス（１０．１０．１０．１０）が、ユーザ管理テーブル４５−１に登録されていない（図５）ので、プロセッサ４１は、グループＩＤ（２２４．１０．１０．１０）に基づいて配信サーバ管理テーブル４５−２を検索し（Ｓ１２２）、ホスト１０−３（未登録ホスト）宛配信サーバ１２−２のグループＩＤ（２２４．３０．３０．３０）とＩＰアドレス（３０．３０．３０．１）を取得する。次に、プロセッサ４１は、離脱要求メッセージのＧｒｏｕｐ Ａｄｄｒｅｓｓ２４の内容を（２２４．１０．１０．１０）から（２２４．３０．３０．３０）に変換する（Ｓ９１２３）。次に、プロセッサ４１は、グループＩＤが変換された後の離脱要求メッセージと配信サーバ１２−２のＩＰアドレス（３０．３０．３０．１）を含むパケットを内部スイッチ側送信バッファ４２に出力する。そのパケットは、内部スイッチ３２に出力された後、内部スイッチ３２によって、パケットのヘッダに基づき複数のプロトコル処理部の何れか（例えば、３１−ｍ、図３）に出力され、それに接続されている回線インタフェース（例えば、３０−ｍ）を介して配信サーバ１２−２に送信（Ｓ１２４）される。
【００４９】
配信サーバ１２−２は、ゲートウェイ１１から上記パケットを受信すると、例えば、配信拒否を示す情報を含むパケットの配信を停止する。
【００５０】
又、プロトコル処理部３１−２に備えるプロセッサ４１は、ホスト１０−３が接続されているポートの番号３に基づいて送信先テーブル４５−３を検索し（Ｓ１２５）、ポート番号３が送信先テーブル４５−３に登録されているか否かを判断する（Ｓ１２６）。プロセッサ４１は、登録されていれば、そのポート番号を送信先テーブル４５−３のポート番号欄７１から削除する（Ｓ１２７）。又、Ｓ１２６で、ポート番号３が、送信先テーブル４５−３に登録されていなければ、回線側受信バッファ４０等に残っているホスト１０−３宛のパケットを廃棄する（Ｓ１２８）。
【実施例２】
【００５１】
実施例１では、ＩＧＭＰを使用するマルチキャスト通信の場合を説明したが、ＭＬＤを使用するマルチキャスト通信の場合にも本発明を適用できる。
【００５２】
図１５は、ＭＬＤメッセージのヘッダ１５０の構成を示す図である。ＲＦＣ２７１０に記載されているように、ＭＬＤメッセージのヘッダは、Ｔｙｐｅ１５１、Ｃｏｄｅ１５２、Ｃｈｅｃｋｓｕｍ１５３、Ｍａｘｉｍｕｍ Ｒｅｓｐｏｎｓｅ Ｄｅｌａｙ１５４、Ｒｅｓｅｖｅｄ１５５、Ｍｕｌｔｉｃａｓｔ Ａｄｄｒｅｓｓ１５６の各フィールドを有する。
【００５３】
Ｔｙｐｅ１５１は、ＭＬＤメッセージのタイプの種別を示し、Ｍｕｌｔｉｃａｓｔ Ｌｉｓｔｅｎｅｒ Ｑｕｅｒｙ（マルチキャストグループ問い合わせ）、Ｍｕｌｔｉｃａｓｔ Ｌｉｓｔｅｎｅｒ Ｒｅｐｏｒｔマルチキャストグループ報告）、Ｍｕｌｔｉｃａｓｔ Ｌｉｓｔｅｎｅｒ Ｄｏｎｅ（マルチキャストグループ離脱）がある。
【００５４】
Ｍａｘｉｍｕｍ Ｒｅｓｐｏｎｓｅ Ｄｅｌａｙは、ＭＬＤメッセージを送信するための最大遅延時間を示す。Ｍｕｌｔｉｃａｓｔ Ａｄｄｒｅｓｓには、ＩＰｖ６用のマルチキャストグループアドレスが入る。
【００５５】
従って、実施例２では、ネットワーク１４がＩＰｖ６網であり、通信システム１内で使用されるメッセージが、図１５で示すＭＬＤメッセージである点が実施例１と相違するのみで、ゲートウェイ１１が、ホストからMLDメッセージを含むパケットを受信した後に行う動作は、実施例１と同様である。
【実施例３】
【００５６】
上記実施例１、２では、図９、図１１に示すように、グループ離脱の場合には、ホストからの離脱要求メッセージを含むパケットを受信して、離脱処理を行うようにしたが、ホストからの離脱要求メッセージを含むパケットを受信しなくても離脱処理は可能である。例えば、グループ参加処理を示す図１０において、ゲートウェイ１１が、ステップ１００の処理をした後、一定時間経過後、ゲートウェイ１１自らが、グループ離脱要求用のメッセージを生成し、図１１に示すグループ離脱処理を行うとともに、グループＩＤの変換処理を停止して、ホストへの情報配信を停止するようにしても良い。
【実施例４】
【００５７】
上記実施例１、２、３では、未登録ホストに対して、配信拒否等の通知を行う配信サーバ１２−２を備えていたが、その配信サーバ１２−２の機能をゲートウェイ１１に備えても良い。尚、この場合には、ゲートウェイ１１におけるＩＤ変換手段は不要となる。
【実施例５】
【００５８】
上記実施例１、２、３、４では、１つの回線インタフェースに１つのポートが存在する場合について説明したが、１つの回線インタフェースに複数のポートが存在する場合であっても、ゲートウェイ1１での動作は、上記実施例１、３，３と同様である。
【実施例６】
【００５９】
上記実施例１、２、３、４、５では、参加要求メッセージを含むパケットが、内部スイッチ３２を介してルーティングされるようにしていたが、パケットが内部スイッチ１２を介さない装置の構成であっても良い。
【図面の簡単な説明】
【００６０】
【図１】本発明によるパケット転送装置（ゲートウェイ）１１が用いられる通信システム１の構成を示す図である。
【図２】通信システム１で用いられるＩＧＭＰメッセージのヘッダ２０の構成を示す図である。
【図３】本発明によるゲートウェイ１１の構成を示すブロック図である。
【図４】プロトコル処理部３１−ｉの詳細な構成を示すブロック図である
【図５】ユーザ管理テーブル４５−１の構成を示す図である。
【図６】配信サーバ管理テーブル４５−２の構成を示す図である。
【図７】送信先テーブル４５−３の構成を示す図である。
【図８】ホスト（１０−１〜１０−３）画面の構成例を示す図である。
【図９】本発明によるゲートウェイ１１の動作を示すフローチャートである。
【図１０】同じく、本発明によるゲートウェイ１１の動作（グループ参加処理）を示すフローチャートである。
【図１１】同じく、本発明によるゲートウェイ１１の動作（グループ離脱処理）を示すフローチャートである。
【図１２】ホスト画面のチャンネル入力部８１にチャンネルが入力されたことを示す図である。
【図１３】登録ホスト画面の表示部８０に映像等の情報が流れていることを示す図である。
【図１４】未登録ホスト画面に配信拒否を示す情報が表示されていることを示す図である。
【図１５】通信システム１で用いられるＭＬＤメッセージのヘッダ１５０の構成を示す図である。
【符号の説明】
【００６１】
１０−１〜１０−３  ホスト
１１  パケット転送装置
１２−１〜１２−３  配信サーバ
１４  バックボーンネットワーク
１５  ルータ
３０−ｉ  回線インタフェース
３１−ｉ  プロトコル処理部
３２  内部スイッチ
３３  制御部
４０  回線側受信バッファ
４１  プロセッサ
４２  内部スイッチ側送信バッファ
４３  内部スイッチ側受信バッファ
４４  回線側送信バッファ
４５  メモリ
４６  プロセッサ間インタフェース。
【図１】
2006005814.tif 000003
【図２】
2006005814.tif 000004
【図３】
2006005814.tif 000005
【図４】
2006005814.tif 000006
【図５】
2006005814.tif 000007
【図６】
2006005814.tif 000008
【図７】
2006005814.tif 000009
【図８】
2006005814.tif 000010
【図９】
2006005814.tif 000011
【図１０】
2006005814.tif 000012
【図１１】
2006005814.tif 000013
【図１２】
2006005814.tif 000014
【図１３】
2006005814.tif 000015
【図１４】
2006005814.tif 000016
【図１５】
2006005814.tif 000017