(57)【特許請求の範囲】
【請求項１】
マルチキャストグループに対してクライアントが送信した参加／離脱情報を判別する第1ステップと、
該クライアントの参加／離脱情報をマルチキャスト参加／離脱通知情報に加工する第２ステップと、
該マルチキャスト参加／離脱通知情報を送信元サーバに転送する第３ステップと、
を備え、
マルチキャストデータの送信前に該送信元サーバから送出されるダミーのデータによって該マルチキャストアドレスと該送信元サーバとの関係を把握し、該クライアントから該参加／離脱情報を受信したときに、該クライアントの情報及び該マルチキャストアドレスを該送信元サーバへ送信することを特徴とするネットワーク中継方法。
【請求項２】
請求項１において、
該マルチキャスト参加／離脱通知情報が、該クライアントの識別情報とマルチキャストアドレスと参加／離脱開始時刻とを含むことを特徴とするネットワーク中継方法。
【請求項３】
請求項１において、
該第1ステップが、該クライアントからのマルチキャスト制御パケットに搭載された該クライアントの参加／離脱情報を判別し、該第２ステップが、該クライアントの参加／離脱情報をマルチキャスト参加／離脱通知パケットに加工し、該第3ステップが該マルチキャスト参加／離脱通知パケットを該送信元サーバに転送することを特徴としたネットワーク中継方法。
【請求項４】
請求項３において、
該第1ステップが、同一マルチキャストグループのクライアントの集約参加／離脱通知パケットを下流のネットワーク中継装置から受信したと判別したとき、該第２ステップは、自分自身のクライアントから同一のマルチキャストグループに対する参加／離脱情報を集約している場合、それら全ての参加／離脱情報を1つのパケットに集約した集約参加／離脱通知パケットを生成し、該第3ステップで該集約参加／離脱通知パケットを即座に該送信元サーバへ転送することを特徴としたネットワーク中継方法。
【請求項５】
請求項１から４のいずれか一つにおいて、
該第3ステップでは、該送信元サーバから転送要求があるときまで、該クライアントの参加／離脱情報を保持することを特徴としたネットワーク中継方法。
【請求項６】
請求項２において、
該クライアントの識別情報としてパケットに含まれる送信元アドレスを利用することを特徴としたネットワーク中継方法。
【請求項７】
請求項１において、
該第３ステップは、該クライアントが、定期的な問合せに応答しないとき、該クライアントの離脱通知情報を該送信元サーバに送ることを特徴としたネットワーク中継方法。
【請求項８】
マルチキャストグループに対してクライアントが送信した参加／離脱情報を判別する判別部と、
該クライアントの参加／離脱情報をマルチキャスト参加／離脱通知情報に加工する情報加工部と、
該マルチキャスト参加／離脱通知情報を送信元サーバに転送する転送処理部と、
を備え、
マルチキャストデータの送信前に該送信元サーバから送出されるダミーのデータによって該マルチキャストアドレスと該送信元サーバの関係を把握し、該クライアントから該参加／離脱情報を受信したときに、該クライアントの情報及び該マルチキャストアドレスを該送信元サーバへ送信することを特徴とするネットワーク中継装置。
【請求項９】
請求項８において、
該マルチキャスト参加／離脱通知情報が、該クライアントの識別情報とマルチキャストアドレスと参加／離脱開始時刻とを含むことを特徴としたネットワーク中継装置。
【請求項１０】
請求項８において、
該判別部が、該クライアントからのマルチキャスト制御パケットに搭載された該クライアントの参加／離脱情報を判別し、該情報加工部が、該クライアントの参加／離脱情報をマルチキャスト参加／離脱通知パケットに加工し、該転送処理部が該マルチキャスト参加／離脱通知パケットを該送信元サーバに転送することを特徴としたネットワーク中継装置。
【請求項１１】
請求項１０において、
該判別部が、同一マルチキャストグループのクライアントの集約参加／離脱通知パケットを下流のネットワーク中継装置から受信したと判別したとき、該情報加工部は、自分自身のクライアントから同一のマルチキャストグループに対する参加／離脱情報を集約している場合、それら全ての参加／離脱情報を1つのパケットに集約した集約参加／離脱通知パケットを生成し、該転送処理部が、該集約参加／離脱通知パケットを即座に該送信元サーバへ転送することを特徴としたネットワーク中継装置。
【請求項１２】
請求項８から１１のいずれか一つにおいて、
該転送処理部は、該送信元サーバから転送要求があるときまで、該クライアントの参加／離脱情報を保持することを特徴としたネットワーク中継装置。
【請求項１３】
請求項９において、
該クライアントの識別情報としてパケットに含まれる送信元アドレスを利用することを特徴としたネットワーク中継装置。
【請求項１４】
請求項８において、
該転送処理部は、該クライアントが、定期的な問合せに応答しないとき、該クライアントの離脱通知を該送信元サーバに送ることを特徴としたネットワーク中継装置。
【請求項１５】
請求項８から１４のいずれかに記載のネットワーク中継装置から送信されたマルチキャスト参加／離脱通知情報を判別する判別部と、
該マルチキャスト参加／離脱通知における該クライアントの情報を抽出して保持する保持部と、
を備えたことを特徴とするサーバ。
【請求項１６】
請求項１５において、
該クライアントの情報に基づいてマルチキャストデータ配信の時間課金を行う手段を備えたことを特徴とするサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク中継方法及び装置に関し、特にマルチキャストによりサーバからクライアントにデータ配信する時のネットワーク中継方法及び装置に関するものである。
【背景技術】
【０００２】
近年は、パーソナルコンピュータの急速な普及と共に、企業網(イントラネット)も拡充の方向に在り、コンピュータやネットワークそれ自体の高機能化、高性能化も進んでいる。また、ウェブページ(WWW)の普及、動画、音声といったマルチメディアデータの普及も急速に進みつつある。
さらに、近年は企業ユーザ、一般ユーザも含めたインターネットアクセスにおけるブロードバンドネットワークの普及が進みつつあり、いわゆるマルチメディアと呼ばれる音声や動画の利用や、これを利用した配信、放送サービスによるビジネス形態が増えて来ている。
【０００３】
普及途上の現在では、各ユーザにユニキャストでデータを配信する方法が多く用いられており、特に多数のユーザがアクセスするような動画配信などでは、負荷分散の目的から、データ配信元に多数のサーバを設置したり、あるいは地域毎にキャッシュサーバを設けて、ユーザは近隣のキャッシュサーバからデータを受信する仕組みが取り入れられている。
【０００４】
これはオンデマンド放送でもリアルタイム放送でも同じであり、多数のユーザがそれぞれ満足する品質を提供するためには、必要とされる設備が多く、多額の投資を必要とする。
一方、大量のデータを効率良く伝送するために「マルチキャスト」技術によるデータ伝送も行われ始めており、マルチキャストを使用したマルチメディアデータ伝送は今後ますます普及することが予想される。
【０００５】
マルチキャストは、基本的にオンデマンドの配信は行えないが、ライブ中継など、リアルタイムの動画配信や音声配信では多くのメリットを有する。
すなわち、マルチキャスト配信では、図1に示すように、サーバS1はデータを受信するユーザ（クライアント）の数に関わらず、1つのストリームをマルチキャスト対応ネットワークMNWに送信するだけでマルチキャストルータ1_1,1_2(以下,符号「１」で総称することがある。)やLANスイッチSW1, SW2(以下,符号「SW」で総称することがある。)を介して多数のクライアントR1,R2…に該データを受信させることができる。
【０００６】
従って各地にキャッシュを設ける必要もなく、さらにはユニキャストと異なり各ネットワークでの帯域を節約することができる。
言い換えると、ユーザ数に関わらず、或る経路のトラフィック量は一定に保つことができ、その他の通信に与える影響も少なく、また、ユニキャストの場合のように配信専用にネットワークやキャッシュサーバなどの設備を設ける必要がなく、非常に安価にマルチメディアデータを配信することが可能となる。
【０００７】
ただし、サーバからクライアントまでのネットワーク全体がマルチキャストに対応している必要がある、という制限はあるが、現在ではネットワークに設置される中継装置やデータ配信サーバ、あるいはクライアントが使用するパーソナルコンピュータの全てでマルチキャストの対応はほぼ完了している状況になっており、特にリアルタイム放送形式の動画配信や音声配信では徐々にマルチキャストが使用される割合が高くなって来ると考えられている。
【０００８】
ここで、マルチキャストデータ配信の環境や仕組みについて概要を説明する。
具体的には、IPマルチキャストアドレス（グループアドレス）とデータリンク層のマルチキャストアドレス、クライアント（ホスト）とマルチキャストルータ間のプロトコルであるIGMP(Internet Group Management Protocol)、ネットワーク内でマルチキャスト配信ツリーを構築するマルチキャストルーティングプロトコルのそれぞれについて説明する。なお、データリンク層はイーサネット（登録商標）の場合について説明する。
【０００９】
IPマルチキャスト配信は、アドレスにマルチキャストアドレスを使用し、図28(a)及び(b)に示す如く、クライアントR1,R2とマルチキャストルータ1との間で機能し、ルータ1が配下のクライアントR1,R2のマルチキャストグループの把握を行う機能を提供するIGMP、及びルータ間でサーバから複数の各受信クライアントまでのマルチキャストデータ配信ツリーを構築するマルチキャストルーティングプロトコルを動作させることで実現される。
【００１０】
ここで、IGMPとは、クライアントR1,R2とルータ1が図29に示すパケットフォーマットのIGMPメッセージをやり取りすることによって、ルータ1が自分が属するローカルネットワークに受信クライアントが存在するか否かを把握／管理するプロトコルである。
言い換えるとクライアントR1,R2が或るマルチキャストグループに参加することをルータ1に伝えるための、ルータ−クライアント間のプロトコルであり、ルータ、クライアント共にIGMP（図30に示すIPヘッダにおける「プロトコルID」が“2”の場合に適用）で規定されているそれぞれの機能を実装する必要がある。IGMPv1はRFC1112の付録1で、IGMPv2はRFC2236で規定され、IGMPv3がIETFにて標準化中である。
【００１１】
また、マルチキャストルーティングプロトコルとは、図1に示すように、複数のマルチキャストルータ1やレイヤ3スイッチSWによって構成されるネットワークにおいて、ルータ１がマルチキャストデータストリームを受信クライアントR1,R2へ配信するために、ルータ1のどのインタフェースへマルチキャストデータをコピーして送信するかを決める経路制御(あるいは経路木の構成)のための、ルータ間のプロトコルである。
【００１２】
その種類として、DVMRP(MBoneで使用、RFC1075で規定)、PIM(RFC2117で規定、及び新たなバージョンがIETFで検討中)、MOSPF(OSFP上のみで動作可、RFC1584、1585で規定)などがある。
なお、上記のRFC1112とは、クラスDのIPアドレス、すなわちマルチキャストIPアドレスとマルチキャスト物理アドレスとのマッピングや、特定のマルチキャスト物理アドレスのパケットのみを受信し上位層へ上げるフィルタリング機能である。
【００１３】
このマルチキャストIPアドレスとマルチキャスト物理アドレスとの対応付けは、マルチキャストIPアドレスの下位23ビットをマルチキャスト物理アドレス“01.00.5E.00.00.0016”の下位23ビットに入れると規定(RFC1700)されている。例えば、マルチキャストIPアドレス“239.133.130.34”はマルチキャスト物理アドレス“01:00:5E:05:82:22”となる。
また、マルチキャストアドレス(IPv4)は、クラスDアドレスとして規定されており、10進表記で、“224.0.0.0”から“239.255.255.255”の範囲である。
【００１４】
図31にクラスDのIPアドレスを示す。クラスDアドレスは、最初の4ビット“1110”で識別される。図示の通り、いくつかのマルチキャストアドレスは特定用途のために予約されている。
ローカルサイト用の割り当て、すなわち、“239.0.0.0”から“239.255.255.255”までが、例えば企業ネットワークやISPなどで一般に使用できるIPマルチキャストアドレスである。
【００１５】
上記のようなマルチキャストデータの配信手順を図28により以下に簡単に説明する。
[1]マルチキャストグループへの参加
(1)マルチキャストルータ1は、ローカルネットワークに接続しているクライアントR1,R2にマルチキャストグループへの参加を尋ねるため、図29に示すフォーマット(IGMPv2)のパケットにおけるIGMPヘッダ内のタイプ値が「0x11」の“HMQ(Host Membership Query)（メンバ問合せ）”メッセージ（図28(a)(1)）を定期的に“224.0.0.1”(All-Systems-Group)宛に送信する。
(2)マルチキャストグループへの参加を希望するクライアントは上記の“メンバ問合せ”に応答して、参加を希望するグループのマルチキャストアドレスを通知するために、同じフォーマットのパケットにおけるIGMPヘッダ内のタイプ値が「0x12」の“HMR(Host Membership Report)（メンバ参加希望）”メッセージ（同図(2)）を参加するマルチキャストアドレス宛に送信する。
【００１６】
マルチキャストルータ1は、これを受信して、クライアントが参加するマルチキャストグループ（上述のクラスDのアドレスで識別される。）を把握し、ローカルネットワークへマルチキャストデータ（ストリーム）の送信を開始する。
[2]マルチキャストデータ配信
(1)一方、マルチキャストデータの送信サーバ（例えば図1のサーバS1）は、クラスDのアドレスで識別されるマルチキャストグループ宛に、“1つの”データ(ストリーム)を送信する。
(2)ネットワーク内のマルチキャストルータ1は、そのマルチキャストグループに参加している各受信クライアントへの経路に沿って、そのグループ宛のデータストリームを必要に応じてコピーしながら伝送して行く。
【００１７】
言い換えると、マルチキャストルーティングプロトコルによって構成された、送信サーバから各受信クライアントへ至るマルチキャストデータ配信の経路木に沿って、マルチキャストデータが配信される。最終的に、サーバが送信した“1つの”データストリームは、ネットワーク内の“複数の”クライアントへ配信されることになる。
[3]マルチキャストグループからの離脱
(1)参加しているマルチキャストグループからの離脱を希望するクライアントは、離脱を決めた時点で、図28(b)に示すように、“Leave（離脱希望）”メッセージ（同図(3)）を“224.0.0.2”(All-Routers-Group)宛に送信する。
(2)“離脱希望”メッセージを受信したマルチキャストルータ1は、未だ他にそのマルチキャストグループに参加しているクライアントが存在しないことを確認するために、そのグループアドレスを指定して“GS-Q(Group Specific Query)”メッセージ（同図(4)）を送信する。
【００１８】
この場合、もし“離脱希望”メッセージを送信したクライアント以外に、未だそのグループに参加しているクライアントが存在するときには、そのクライアントは“メンバ参加希望”メッセージを送信してその存在をマルチキャストルータ1に伝える。
このように、マルチキャストを使用したデータ、コンテンツの配信では、メリットが多くある反面、ユニキャストの場合のように各クライアント宛にサーバがデータを送信する訳では無いため、また、マルチキャスト自体がUDP(User Data Protocol)パケットを使用するため、個々のユーザ管理が困難である。
【００１９】
管理が困難であるということは、例えば、ある時点の受信クライアント数や、各々のクライアントについて、いつからいつまでデータを受信していたかを把握したり、さらにクライアント自体の情報などを取得・管理することができないということである。
従って、どのコンテンツに人気があり、どの位の数のクライアントが受信していたかということを検討するための情報収集や、サービス形態としてデータを受信していた時間に応じた課金などが実現できなかった。
【００２０】
従って本発明は、マルチキャストによりサーバからクライアントにデータ配信する時に、マルチキャストに参加／離脱する個々のクライアント情報を管理するネットワーク中継方法及び装置を実現することを目的とする。
【発明の開示】
【００２１】
上記の目的を達成するため、本発明に係るネットワーク中継方法は、マルチキャストグループに対してクライアントが送信した参加／離脱情報を判別する第1ステップと、該クライアントの参加／離脱情報をマルチキャスト参加／離脱通知情報に加工する第２ステップと、該マルチキャスト参加／離脱通知情報を送信元サーバに転送する第３ステップと、
を備え、マルチキャストデータの送信前に該送信元サーバから送出されるダミーのデータによって該マルチキャストアドレスと該送信元サーバとの関係を把握し、該クライアントから該参加／離脱情報を受信したときに、該クライアントの情報及び該マルチキャストアドレスを該送信元サーバへ送信することを特徴としている。
【００２２】
上記のマルチキャスト参加／離脱通知情報は、該クライアントの識別情報とマルチキャストアドレスと参加／離脱開始時刻とを含むことができる。
また、上記の第1ステップでは、該クライアントからのマルチキャスト制御パケットに搭載された該クライアントの参加／離脱情報を判別し、上記の第２ステップでは、該クライアントの参加／離脱情報をマルチキャスト参加／離脱通知パケットに加工し、該第3ステップが該パケットを該送信元サーバに転送することができる。
【００２３】
また、上記の第２ステップが、該マルチキャスト参加／離脱通知パケットを該送信元サーバへ転送する際、一定時間内に別のクライアントから同一のマルチキャストグループに対する参加／離脱情報を受信した場合、その受信したタイミングで、それら全てのクライアントの参加／離脱情報を1つのパケットに集約した集約参加／離脱通知パケットを生成し、該第3ステップで該集約参加／離脱通知パケットを該送信元サーバに転送することができる。
【００２４】
上記の参加／離脱情報は、集約された参加／離脱情報である。
さらに、上記の第1ステップで、該マルチキャスト参加／離脱通知パケットを下流のネットワーク装置から受信したと判別したとき、上記の第３ステップでは、該マルチキャスト参加／離脱通知パケットをさらに該送信元サーバへ転送することができる。
さらに上記の第1ステップで、該集約参加／離脱通知パケットを下流のネットワーク装置から受信したと判別したとき、上記の第３ステップでは、該集約参加／離脱通知パケットをさらに該送信元サーバへ転送することができる。
【００２５】
さらに上記の第1ステップで、該集約参加／離脱通知パケットを下流のネットワーク中継方法から受信したと判別したとき、上記の第２ステップでは、自分自身のクライアントから同一のマルチキャストグループに対する参加／離脱情報を集約している場合、それら全ての参加／離脱情報を1つのパケットに集約した集約参加／離脱通知パケットを生成し、これを上記第3ステップで即座に該送信元サーバへ転送することができる。
【００２６】
さらに、上記第3のステップでは、該送信元サーバから転送要求があるときまで、該クライアントの参加／離脱情報を保持することができる。
さらに、上記のクライアントの識別情報としてパケットに含まれる送信元アドレスを利用することも可能である。
さらに上記の第３ステップでは、該クライアントが、定期的な問合せに応答しないとき、該クライアントの離脱通知情報を該送信元サーバに送ることができる。
【００２７】
上記の本発明に係るネットワーク中継方法を実現する装置としては、マルチキャストグループに対してクライアントが送信した参加／離脱情報を判別する判別部と、該クライアントの参加／離脱情報をマルチキャスト参加／離脱通知情報に加工する情報加工部と、該マルチキャスト参加／離脱通知情報を送信元サーバに転送する転送処理部と、を備え、マルチキャストデータの送信前に該送信元サーバから送出されるダミーのデータによって該マルチキャストアドレスと該送信元サーバの関係を把握し、該クライアントから該参加／離脱情報を受信したときに、該クライアントの情報及び該マルチキャストアドレスを該送信元サーバへ送信することを特徴としている。
【００２８】
上記のマルチキャスト参加／離脱通知情報は、該クライアントの識別情報とマルチキャストアドレスと参加／離脱開始時刻とを含むことができる。
また、上記の判別部は、該クライアントからのマルチキャスト制御パケットに搭載された該クライアントの参加／離脱情報を判別し、上記の情報加工部は該クライアントの参加／離脱情報をマルチキャスト参加／離脱通知パケットに加工し、該転送処理部が該マルチキャスト参加／離脱通知パケットを該送信元サーバに転送することができる。
【００２９】
また、上記の情報加工部は、該マルチキャスト参加／離脱通知を該送信元サーバへ転送する際、一定時間内に別のクライアントから同一のマルチキャストグループに対する参加／離脱情報を受信した場合、その受信したタイミングで、それら全てのクライアントの参加／離脱情報を1つのパケットに集約した集約参加／離脱通知パケットを生成し、該転送処理部が、該集約参加／離脱通知パケットを該送信元サーバに転送することができる。
【００３０】
上記の参加／離脱情報は、集約された参加／離脱情報である。
また、上記の判別部が、該マルチキャスト参加／離脱通知を下流のネットワーク装置から受信したと判別したとき、上記の転送処理部は、該マルチキャスト参加／離脱通知パケットをさらに該送信元サーバへ転送することができる。
また、上記の判別部が、該集約参加／離脱通知パケットを下流のネットワーク装置から受信したと判別したとき、上記の転送処理部は、該集約参加／離脱通知パケットをさらに該送信元サーバへ転送することができる。
【００３１】
さらに上記の判別部が、該集約参加／離脱通知パケットを下流のネットワーク中継装置から受信したと判別したとき、上記の情報加工部は、自分自身のクライアントから同一のマルチキャストグループに対する参加／離脱情報を集約している場合、それら全ての参加／離脱情報を1つのパケットに集約した集約参加／離脱通知パケットを生成し、これを該転送処理部が、即座に該送信元サーバへ転送することができる。
【００３２】
また、上記の転送処理部は、該送信元サーバから転送要求があるときまで、該クライアントの参加／離脱情報を保持することができる。
上記のクライアントの識別情報としてパケットに含まれる送信元アドレスを利用することができる。
さらに上記の転送処理部は、該クライアントが、定期的な問合せに応答しないとき、該クライアントの離脱通知情報を該送信元サーバに送ることができる。
【００３３】
さらに上記のネットワーク中継装置から送信されたマルチキャスト参加／離脱通知情報を判別する判別部と、該マルチキャスト参加／離脱通知における該クライアントの情報を抽出して保持する保持部と、でサーバを構成することができる。
そして、このサーバにおいては、該クライアントの情報に基づき、マルチキャストデータ配信（コンテンツ受信）の時間課金を行う手段を有することができる。
【００３４】
上述した本発明に係るネットワーク中継方法及び装置について図を参照して以下に説明する。
図1は本発明の概念を説明するためのネットワーク構成例を示している。図中、S1はマルチキャストデータの送信サーバ、1_1,1_2は本発明のネットワーク中継方法及び装置を実装したマルチキャスト（対応）ルータ、SW1,SW2はクライアントを収容するLANスイッチあるいはレイヤ2スイッチ、MNWはマルチキャストルータで構成されたネットワーク、R1は通常データを受信するクライアント、R2はマルチキャストデータを受信するクライアント、PKT1は受信クライアントR1,R2とマルチキャストルータ1_2間で機能するマルチキャスト制御用パケット、PKT2は受信クライアントの参加又は離脱（以下、参加／離脱と称する。）情報を含めてサーバへS1へ向けて転送されるユーザ情報パケットである。なお、パケットPKT1,PKT2もPKTで総称することがある。
【００３５】
また図2は、通常マルチキャスト機能を実装しているルータである本発明のネットワーク中継装置1の原理構成図を示している。このネットワーク中継装置1は、送受信インタフェース2,7,8と、マルチキャスト制御パケットPKT1の判別部3と、サーバS1にユーザ情報を通知するためのクライアント管理理情報パケットPKT2の生成部4と、ルーティングテーブル6を含み通常のネットワーク中継装置に実装されているルーティング処理(マルチキャストルーティング処理を含む)などを行う転送処理部5とで構成されている。
【００３６】
動作において、送受信インタフェース2にLANスイッチSW2を介して受信クライアントR2が接続されているとき、受信クライアントR2からは、マルチキャストデータの受信を望むこと（マルチキャストグループ参加希望）を示す、あるいは今まで受信していたがもう受信を中止すること（マルチキャストグループ離脱希望）をマルチキャストルータ1に通知するためのマルチキャスト制御パケットPKT1が送信され、これをマルチキャストルータ1が受信する。
【００３７】
マルチキャストルータ1は、受信パケットが何であるかをパケット判別部3で検査する。もしマルチキャスト制御パケットPKT1であれば、これを通常のマルチキャストデータ転送制御するために転送処理部5へ送り、ルーティングテーブル6に情報を反映する。
これと同時に、ユーザ情報をサーバS1で管理できるようにするため、パケット生成部4でユーザ情報を格納したマルチキャスト参加／離脱通知パケットを生成し、転送処理部5に送り、サーバS1が存在する方向のインタフェース7又は8から転送する。
【００３８】
これがサーバ51へ到着することで、従来マルチキャストのデータ転送では不可能であったデータの受信ユーザ管理が実現できる。
【発明を実施するための最良の形態】
【００３９】
以下、本発明に係るネットワーク中継方法及び装置の実施例を説明する。なお、マルチキャスト制御メッセージについて、最も普及し、広く実装されている上記のIGMPv2(RFC 2236にて規定)メッセージの場合について説明するが、本発明はマルチキャスト制御メッセージがIGMPv1、IGMPv3である場合にも適用可能である。
また、IPv6の場合は、IGMPv2相当の機能はMLD(Multicast Listener Discovery)と呼ばれ、RFC2710で規定されている。またIGMPv3相当の機能もIETFで標準化作業中である。本実施例ではネットワークレイヤがIPv4の場合について説明するが、当然ながらIPv6の場合にも適用可能である。IPv6とIPv4マルチキャストの差異については後述する。
【００４０】
図3は、本発明が対象とする企業IPネットワークやISP(Internet Service Provider)やキャリアのIPネットワークなど、一般的なIPネットワークを示し、図1と同様に、パーソナルコンピュータなどのクライアントR1〜R3や、網を構成するマルチキャスト対応ルータ1_1〜1_8（以下、符号「1」で総称することがある。）マルチキャストルーティングプロトコルMRPによりマルチキャストデータの配信や管理を行うサーバS1などから構成される。
また、クライアントR1〜R3は図1に示したようにLANスイッチ／レイヤ2スイッチに収容されマルチキャストルータ1に接続される形態が、企業においてもインターネットアクセスにおいても一般的であるが、図を簡略化するため示されていない。なお、図示のクライアント管理情報パケットCMP1〜CMP3は図1のパケットPKT1とPKT2とでそれぞれ構成されるものである。
【００４１】
実施例［１］
図4は、図3のネットワーク構成例において、本発明の実施例[1]を簡略化して示したものであり、クライアントR1からはマルチキャスト参加パケットPKT1がマルチキャストルータ1に送られ、これに応答してマルチキャストルータ1からはマルチキャスト参加通知パケットPKT2_1がサーバS1へ送られる様子とサーバS１がマルチキャストデータDTを送信している様子が示されている。
【００４２】
なお、IGMPパケットフォーマットとIGMPメッセージフィールド、は図29に示したものであり、IPv4ヘッダは図30に示したものを用いればよい。
また図5には、図2に原理的に示した本発明のネットワーク中継装置であるマルチキャストルータやマルチキャスト対応レイヤ3スイッチなどの実施例構成が示されている。
図中、パケット判別部3_1〜3_3（以下、符号「3」で総称することがある。）は、クライアントからのマルチキャスト参加希望メッセージ(IGMP Report)や離脱希望メッセージ(IGMPLeaveメッセージ)を検出して、既知のマルチキャスト制御を行うマルチキャスト処理部9へ送ると共に、タイマ10及びクライアント情報保持部11にも送る。
【００４３】
タイマ10は、クライアント情報保持部11並びにパケット生成部4と共に後述する如く、クライアント情報の集約された参加／離脱情報通知メッセージ（パケット）の生成時に使用するものである。
以下、図3及び4を参照して、図5に示したネットワーク中継装置1の動作を説明する。
まず、ネットワーク中継装置1は自己の各インタフェース2,7,8配下に存在するマルチキャストデータの受信クライアントR1〜R3の情報を把握する。具体的には、マルチキャストデータの受信を望むクライアントR1〜R3から送信されるパケットをパケット判別部3で検査し、パケットがIGMP参加希望(report)メッセージを含んでいれば、その受信インタフェース配下に受信クライアントが存在することを認識する。
【００４４】
IGMP参加希望メッセージの識別方法は、まず、(1)IPアドレスがマルチキャストアドレスであることと、(2)IPヘッダ内の「プロトコル番号」がIGMPを示す“2”であり、さらに(3)IGMPメッセージのタイプ値が「0x16」であることを確認する。
IGMP参加希望メッセージ内には、図29に示したように、受信クライアントR1〜R3が受信を希望するマルチキャストアドレス(グループアドレス)が格納されている。
【００４５】
ネットワーク中継装置1は、このメッセージの送信元のクライアントがマルチキャストデータの受信を望んでいること（マルチキャスト参加希望）をサーバS1で管理できるように、パケット生成部4にて宛先アドレス（図30参照）をサーバS1のアドレスとしてマルチキャスト参加通知パケットPKT2_1を生成し、サーバS1へ向けて転送処理部5が通常のルーティング処理で転送する。
【００４６】
この時、サーバS1がこれを受信した場合にマルチキャスト参加通知メッセージであることが識別できるように、IGMPメッセージのタイプ値を変更して送信する。
すなわち、標準で決まっているIGMPメッセージのタイプ値は図29に示したとおり、バージョン1(IGMPv1)とバージョン2(IGMPv2)とバージョン3(IGMPv3)とがある(IGMPv3はインターネット技術の標準化団体であるIETF(Internet Engineering Task Force)で標準化作業中)が、本発明ではマルチキャスト参加通知メッセージは上記以外のタイプ値を設定して識別するものとする。このタイプ値については後述する。
【００４７】
クライアントR1〜R3がマルチキャストデータDT1〜DT3の受信を希望することを示すIGMP参加希望メッセージは、自分自身が受信したいアドレスへ送信される(検討中のIGMPv3では“224.0.0.22”へ送信される。)が、サーバS1でマルチキャストデータDT1〜DT3の受信クライアントの情報を管理可能とするために、ネットワーク中継装置1においてIGMP参加希望メッセージを受信した時、その宛先アドレスフィールドをサーバアドレスで置き換え、サーバS1へ送信する。
【００４８】
この時、図29に示したIGMPメッセージの「最大応答時間フィールド」は、処理上では不要なため、「0」に設定しておくなどの方法が考えられる。また「チェックサム」はデータの完全性のためにもあらためて計算した値を設定しておくことが望ましい。
グループアドレスにはクライアントが受信を要求しているマルチキャストアドレスG1を含めることで、例えば同じクライアントが複数の別のマルチキャストアドレスを受信したい場合などにそれぞれ区別して管理できることになる。
【００４９】
図6には、上記のようにクライアント中継装置1からサーバS1へ送られるマルチキャスト参加通知パケットPKT2_1のフォーマットが示されており、受信クライアント情報には、マルチキャスト参加を希望するクライアントR1のアドレスと参加開始時刻t1が搭載される。
これを受信したサーバS1は、メッセージタイプを確認し、参加通知メッセージである場合は、その送信元アドレスフィールド（図30参照）に格納されているクライアントR1のアドレスを、サーバS1が送信しているマルチキャストデータのアドレスG1及び参加通知パケットの受信時刻t1と関連付けて格納することで、クライアントR1が、どのマルチキャストデータ(ここではG1)をいつから(ここではt1)受信し始めたかを管理することができる。
【００５０】
またこの時、受信クライアントR1をそのインタフェースで収容しているネットワーク中継装置1は、マルチキャストアドレスG1とサーバS1のアドレスを、マルチキャストデータを受信するまで知ることはできない。
そこで、実際の運用では、トラフィック量の少ないダミーのマルチキャストデータを、実際のマルチキャストコンテンツの送信前から流しておくようにすれば、ネットワーク中継装置1はマルチキャストアドレスG1とそのサーバS1との関係を認識でき、クライアントR1からIGMP参加希望メッセージを受信した場合に、G1とS1の関係を把握し、情報R1,G1をサーバS1へ送信することが出来る。
【００５１】
また当然ながら、マルチキャストのセッションはマルチキャストアドレスで区別されるため、G1以外に、例えばマルチキャストアドレスG2に対するIGMP参加希望メッセージを受信していたら、G1とは並列した処理を行うことになる。
図7(a)には、上記の動作シーケンスが図示されており、クライアントR1からIGMP参加希望パケットPKT1が送信されると(同図(1))、これを受信したマルチキャストルータ1でマルチキャスト参加通知パケットPKT2_1を生成し（同図(2)）、さらに該パケットPKT2_1がマルチキャスト対応ネットワークMNWを経由してサーバS1に送信される（同図(3)）と、サーバS1ではクライアント管理のためのテーブルが作成される（同図(4)）。
【００５２】
このときのテーブルの一例が同図(b)に示されている。
実施例［２］
通常、ネットワーク中継装置は、図5に示した如く、複数のインタフェース2,8,7を持ち、図8に示す如く、それぞれにサブネットが接続され、サブネット毎に多数のクライアントが接続されている。対象ネットワークの規模が大きい場合、多くの参加通知メッセージPKT2がサーバS1側に送信されることになり、時間的に分散されていれば良いが、集中した場合にはサーバS1に処理負荷が課かる。
【００５３】
そこで、各ネットワーク中継装置1において配下の受信クライアントの情報を集約し、1つのパケットに複数クライアントの情報を含めて一括で送信することが望ましい。
例えば、ネットワーク中継装置1で、マルチキャストアドレスG1に対する受信要求制御メッセージ、すなわちIGMP参加希望メッセージが受信された時にタイマ10を動作させる。
このタイマ10が満了するまでに受信された同じ（マルチキャスト）グループアドレスが対象の全てのIGMP参加希望メッセージの情報、すなわち各受信クライアントのソースアドレスを図9のパケットフォーマットに示す如く1つのパケットのクライアント情報に含めてサーバ宛に集約参加通知メッセージPKT2_2として送信する。
【００５４】
タイマ値の決定方法は、例えばサーバで、あるいはマルチキャストデータの送信を行っている管理者などが、課金の目的で1分毎に情報を管理したい場合はタイマ値を60秒とすれば良い。
またこの時、これが通常のIGMP参加希望メッセージとは異なり、さらに上記の参加通知メッセージとも異なることを示すため、IGMP参加希望メッセージのタイプフィールドに標準で規定されておらず、上記の参加通知メッセージでもないタイプ値を用いる。
【００５５】
図10(a)には、クライアントR1〜R1とマルチキャストルータ1とサーバS1との間の動作シーケンスの概略が図示されている。
クライアントR1からのIGMP参加希望パケットが送信されると（同図(1)）、これを受信したマルチキャストルータ1でタイマ10が起動され（同図(2)）、その後、クライアントR3及びR2から同様のパケットを受信したとき（同図(3),(4)）、タイマ10が満了したこと（同図(5)）を条件として、集約参加通知パケットを生成し（同図(6)）、このパケットをサーバS1に送信する(同図(7))。サーバS1では、これに応じてクライアントの管理テーブルを作成する（同図(8)）。
【００５６】
同図(b)には、この時点でサーバS1が保持する情報のテーブル例を示す。なお、図示の「xx」、「tx」などは、他のマルチキャストやクライアントに関するステータスを持っている状態を示したものである。
実施例［３］
図11に示す如く、集約参加通知メッセージPKT2_21がサーバS1に向けて、或るネットワーク中継装置1_2から送信されると、サーバ方向の次段のネットワーク中継装置1_1で受信される。このネットワーク中継装置1_1はパケットPKT2_21を検査し、それが集約参加通知メッセージであった場合、さらにサーバS1方向へ転送する。
【００５７】
この時、ネットワーク中継装置1_1もネットワーク中継装置1_2と同じようにローカルインタフェース上に受信クライアントを持っている可能性がある。
仮にネットワーク中継装置1_1が受信クライアントR11〜R14からマルチキャストデータG1に関する参加希望メッセージを受信し、情報集約のためにタイマ10を動作させている状態で、ネットワーク中継装置1_2からのマルチキャストデータG1に関する集約参加通知パケットPKT2_21を受信したら、ネットワーク中継装置1_2の情報を遅延させてサーバS1へ届けることを避けるためにタイマ10をキャンセルし、これまでネットワーク中継装置1_1がマルチキャストデータG1に対して保持していたローカルの受信クライアントR11〜R14の情報を、受信した集約参加通知パケットPKT2_21に加えたパケットPKT2_22を生成し、即座に送信する。
【００５８】
図12は、ネットワーク中継装置1_1から送信される集約参加通知パケットPKT2_22のフォーマットを示している。
もし仮に、ネットワーク中継装置1_1がネットワーク中継装置1_2からの集約参加通知パケットPKT2_21を受信する前に、ローカルの受信クライアントR11〜R14からのIGMP参加希望メッセージを受信していなければ、そのままサーバ方向のインタフェースへ転送する。また、これらの動作はマルチキャストアドレス毎にそれぞれ独立して行われる。
【００５９】
図13(a)は、このときのシーケンスを図示しており、ネットワーク中継装置1_1はクライアントR11からマルチキャスト参加パケットを受信（同図(1)）した時点でタイマを起動し（同図(2)）、さらにクライアントR12からマルチキャスト参加パケットを受信した後（同図(3)）、ネットワーク中継装置1_2から集約参加通知パケットを受信したときには（同図(4)）、タイマを強制終了させ（同図(5)）、ネットワーク中継装置1_2からの集約参加通知パケットPKT2_21にクライアントR11,R12の参加情報を加えて即座に送信し（同図(6)）、これを受けてサーバS1でテーブル作成（同図(7)）している。
【００６０】
同図(b)に、この時にサーバS1で管理しているテーブル例を示す。
サーバの実施例
図14に示すように、サーバ側でもユーザ情報パケットであることを検査、識別するパケット判別部22を持ち、該当する場合はクライアント管理テーブル23にクライアント情報とステータス、さらには例えば分単位で受信開始時刻を記録する。
【００６１】
これらの情報を元にして、管理アプリケーション24が、ユーザ数の把握と時間課金計算のための情報を把握することができる。また、ユーザ数が多い場合には、例えば同一のコンテンツを持ったサーバの増設などサーバサイトの設計に対する参考情報とすることができる。
図示の例では、サーバが受信者管理とマルチキャストデータの送信を兼ねる場合を示している。また、通信プロセス25及びアプリケーション26は、マルチキャスト伝送制御部27を駆動して、コンテンツ28よりマルチキャストデータDTを送受信インタフェース21よりマルチキャスト対応ネットワークへ送出する機能を果たしている。
【００６２】
パケットの変形例
さらに、マルチキャスト参加通知パケットや集約参加通知パケットに関して、図9や12に示すように、クライアントから受信したIGMP参加希望メッセージを、必要な情報の伝達用に流用する方法の他、独自のフォーマットを持つIPパケットでも良い。
例えば、図15に示すように、データリンク層ヘッダ(例えばMACヘッダ)及びIPヘッダに対するペイロード部分にマルチキャストデータアドレス情報を含めてもよい。この時は、それが参加通知パケットや集約参加通知パケットであることを識別する方法があれば良く、例えば、図16に示すように、IPヘッダのプロトコルIDに現在規定されていない値を使用し、これを確認することで識別することができる。
【００６３】
なお、周知(Well-Known)のプロトコルIDはIANA(Internet Assigned Numbers Authority)あるいはICANN(The Internet Corporation for Assigned Names and Numbers)が管理しているため、メッセージ用として申請すれば実運用で使用可能である。
実施例［４］
受信クライアントが、マルチキャストデータの受信を中止する場合、通常の離脱希望メッセージ（パケット）、すなわち“IGMP Leave”を送信する。IGMPv2では、IGMP離脱希望メッセージが使用され、IGMPv3では受信を望むマルチキャストアドレスを「空」にしたIGMP参加希望メッセージ(ALL-IGMPv3ルータを示す“224.0.0.22”へ送信される。)が使用される。
【００６４】
受信クライアントを管理するためには、これらの「どのクライアンがいつ受信を止めたか」という情報もサーバで管理することとなる。なお、この離脱情報に関しては、上記の参加情報の場合と基本的には同様である。
以下の説明ではIGMPv2の例を示す。
これまでマルチキャストデータを受信していたクライアントが送信する離脱希望メッセージは「All-Routers-Groupアドレス」である、“224.0.0.2”へ送信される(なお、IGMPv3の「受信を望むマルチキャストアドレスを「空」にしたIGMP参加希望メッセージ」は“224.0.0.22”へ送信される。)。
【００６５】
これを受信したネットワーク中継装置1は、IGMP離脱希望メッセージであるか否かをパケット判別部3で検査する。IGMP離脱希望メッセージの識別方法は、まず、(1)IPアドレスが“224.0.0.2”であること、(2)IPヘッダ内の「プロトコル番号」がIGMPを示す“2”であり、さらに(3)IGMPメッセージのタイプ値が「0x17」であることを確認することである。
【００６６】
IGMP離脱希望メッセージ内には、これと同様に受信クライアントが離脱を希望するマルチキャストアドレスが格納されている。ネットワーク中継装置1は、このメッセージの送信元のクライアントが、これまで受信していたマルチキャストデータの受信を中止したいことをサーバS1へ伝えるために、パケット生成部4にて宛先アドレスをサーバS1のアドレスとした離脱通知パケットを生成し、転送処理部5がサーバS1へ向けて通常のルーティング処理で転送する。
【００６７】
この時、サーバS1がこれを受信した場合に離脱通知メッセージであることを識別できるように、IGMPメッセージのタイプ値を変更して送信する。このような離脱通知パケットのフォーマット例を図17に示す。
これを受信したサーバS1は、メッセージタイプを確認し、離脱通知パケットである場合には、そのソースアドレスフィールドに格納されているクライアントR1のアドレスとサーバS1が送信しているマルチキャストデータのアドレスG1に関連付けて、離脱通知パケットの受信時刻t2を加えることで、アドレスR1を持つクライアントが、どのマルチキャストデータ(ここではG1)の受信をいつ中止(ここではt2)したかを管理することができる。
【００６８】
さらに、クライアントR1に関して、前述のように、サーバS1では、クライアントR1がマルチキャストアドレスG1へ送信していたデータを時刻t1から開始したという情報(すなわち「R1、G1、t1」)を保持しており、これと離脱開始時刻t2を関連付けることで、クライアントR1が受信していた時間「t2-t1」が算出できる。すなわちクライアントR1はマルチキャストデータG1を(t2-t1)の間受信していたことを示している。
【００６９】
このように、シーケンスは前述のIGMP参加希望メッセージの場合と同じであり、図18(a)において、図7(a)と同様に手順(1)〜(4)として示されている。また、サーバS1で管理するテーブル例が図18(b)に示されており、図示のように離脱時刻情報と受信していた時間情報が追加されている。
実施例［５］
当然ながら、ネットワーク中継装置1は図5に示したとおり、複数インタフェース2,7,8を持ち、図8に示したように、それぞれにサブネットが接続され、各サブネット毎に多数のクライアントが接続されている。対象ネットワークの規模が大きい場合、多くの離脱通知メッセージがサーバ側に送信されることになり、集中して送信された場合にはサーバS1に処理負荷が課かる可能性がある。
【００７０】
そこで、マルチキャスト参加情報の場合と同様に各ネットワーク中継装置1において、配下の受信クライアントの離脱情報を集約し、1つのパケットに複数クライアントの情報を含めて一括で送信する方法が考えられる。
例えば、ネットワーク中継装置1で、マルチキャストアドレスG1に対する離脱メッセージ、すなわちIGMP離脱希望メッセージが最初に受信された時にタイマ10を動作させる。
【００７１】
このタイマ10が満了までに受信されたすべてのIGMP離脱希望メッセージの情報、すなわち各受信クライアントのソースアドレスを図17のパケットフォーマットに示す如く、1つのパケットのクライアント情報に含めてサーバ宛にマルチキャスト集約離脱通知メッセージとして送信する。
タイマ値の決定方法は、例えばサーバで、あるいはマルチキャストデータの送信を行っている管理者などが、課金の目的で1分毎に情報を管理したい場合はタイマ値を60秒とすれば良い。タイマ満了後は、再度IGMP離脱希望メッセージを受信した時点でタイマ10を起動する。
【００７２】
またこの時、これが通常のIGMP離脱希望メッセージとは異なり、さらに上記の離脱通知メッセージとも異なることを示すために、IGMP離脱希望メッセージのタイプフィールドに、標準で規定されておらず、前述の参加通知メッセージや集約参加通知メッセージ及び上記の離脱通知メッセージとも異なるIGMPタイプ値を用いればよい。
さらに、図29に示したIGMPメッセージの「最大応答時間フィールド」は、処理上では不要なため、「0」に設定しておくなどの方法が考えられる。また「チェックサム」はデータの完全性のためにも、改めて計算した値を設定しておくことが望ましい。
【００７３】
グループアドレスフィールドにはクライアントが受信中止を要求しているマルチキャストアドレスG1を含めることで、例えば同じクライアントが複数の別のマルチキャストアドレスを受信しており、これも受信を中止したい場合などにそれぞれ区別して管理することができる。
図19に、3つの受信クライアントR1〜R3がほぼ同時にマルチキャストグループG1を離脱する場合の情報を含めた集約離脱通知パケットのフォーマット例を示す。
【００７４】
また図20に、サーバS1がこの集約離脱通知パケットを受信したときのクライアント管理テーブル23を示す。
実施例［６］
IGMP参加希望パケットについて図11及び図13に示したように、集約離脱通知メッセージの場合もサーバS1に向けて、ネットワーク中継装置1_2から送信されると、サーバ方向の次段のネットワーク中継装置1_1に受信される。ネットワーク中継装置1_1はパケットを検査し、それが集約離脱通知メッセージであった場合、さらにサーバ方向へ転送する。
【００７５】
この時、ネットワーク中継装置1_1もネットワーク中継装置1_2と同じようにローカルインタフェース上に受信クライアントを持っている可能性がある。
仮にネットワーク中継装置1_1が受信クライアントR11〜R14からマルチキャストG1に関するIGMP離脱希望メッセージを受信して、情報集約のためにタイマ10を動作させている状態で、ネットワーク中継装置1_2からのマルチキャストデータG1に関する集約参加通知パケットを受信したとする。
【００７６】
このときには、ネットワーク中継装置1_2の情報を遅延させてサーバS1へ届けることを避けるためにタイマ10をキャンセルし、これまでネットワーク中継装置1_1がマルチキャストデータG1に対して保持していたローカルの受信クライアントR11〜R14の情報を、受信した集約参加通知パケットに加えて即座に送信する。
もし仮に、ネットワーク中継装置1_1が同1_2からの集約参加通知パケットを受信する前に、ローカルの受信クライアントR11〜R14からの離脱希望メッセージを受信していなければ、そのままサーバ方向のインタフェースへ転送する。また、これらの動作はマルチキャストアドレス毎にそれぞれ独立して行われる。
【００７７】
これは図11において、ネットワーク中継装置1_1がクライアントR11〜R14など、直接接続するクライアントから離脱希望メッセージを受信し、情報集約のためにタイマ10を起動している場合に、ネットワーク中継装置1_2がサーバ方向へ集約離脱通知パケットを送信し、ネットワーク中継装置1_1で受信された時点でタイマ10を停止し、ネットワーク中継装置1_2からの集約離脱通知パケットにさらにクライアントR11〜R14の情報を追加して即座にサーバS1へ転送する、という動作になる。
【００７８】
この場合に、ネットワーク中継装置1_1から送信される集約離脱通知パケットのフォーマット例を図21に示す。また、この集約離脱通知パケットを受信したときのサーバS1のクライアント管理テーブル23の状態を図22に示す。
クライアントの識別情報
以上、マルチキャストデータ配信における受信クライアント管理について述べたが、各クライアントの識別はクライアントのIPアドレスで行うことが最も利便性が良い。すなわち、ユーザ側から送信されるIGMP参加希望パケット、あるいはIGMP離脱希望パケットのソース（送信元）アドレスであるIPアドレスを使用することができる。
【００７９】
例えば、ダイヤルアップユーザの場合では、ユーザが契約しているISP(Internet Service Provider)からユーザ宅内のパーソナルコンピュータにIPアドレスが割り当てられるため、これを使用、あるいはFTTH(Fiber to the Home)やADSL(Asymmetric Digital Subscriber Line)などのブロードバンドアクセスでは、ユーザ宅内の小型ルータ(SOHO(Small Office Home Office) ルータ)の外向きのインタフェースにアドレスが割り当てられるため、これを使用することができる。
【００８０】
ISPのアドレス割当は、当然ながら課金管理のために「どのユーザにどのIPアドレスをいつからいつまで割り当てたか」という情報と共に行われる。したがって、この情報とマルチキャストの受信クライアントのIPアドレス情報と受信時間(t2-t1)を結び付ければ、マルチキャストコンテンツの時間課金計算が可能となる。
この時、ユーザ宅内にSOHOルータがあり、内部に複数の端末が存在しており両方で同じマルチキャストを受信している状態で、一方の端末が離脱メッセージ、すなわちIGMP離脱希望メッセージを送信したとすると、ネットワーク中継装置(マルチキャストルータ)はそれを受信し、そのインタフェース配下に未だそのマルチキャストデータを受信したいクライアントが存在するか否かを確認するために、図28(b)について説明した“GS-Q(Group Specific Query)”メッセージを送信する。
【００８１】
これをSOHOルータ経由で受信したユーザ宅内のもう1台のクライアントは、受信継続の希望を示すために改めて参加希望メッセージを送信するため、また同じアドレス、すなわちSOHOルータに割り当てられているアドレスは受信クライアントの情報として残ることになり、受信できなくなることは無い。すなわち現在のインターネットアクセスの形態や今後増加すると見られているADSLやFTTHなどのブロードバンドアクセス環境でも問題なく動作する。
管理情報の一括送信
以上、クライアント側が送信するIGMP参加／離脱メッセージを基に、クライアントの参加や離脱の情報をサーバへ転送することで受信クライアントを管理する方法及び装置について述べた。
【００８２】
これとは別に、通常、複数のクライアントを収容しているネットワーク中継装置でクライアント情報を保持・蓄積しておき、管理情報が必要となる契機で管理サーバへ一括送信する方法が考えられる。この場合は、サーバ側のクライアント管理の処理負荷を低減できる。
一般的なイントラネット、あるいはインターネットアクセスでのエンドユーザ収容のネットワーク形態では、図１に示したように、各受信クライアントR1,R2はLANスイッチ／レイヤ2スイッチSW1,SW2に収容され、さらに上流のネットワーク中継装置(マルチキャスト)に接続されている。
【００８３】
この時、各ネットワーク中継装置が、それぞれのインタフェース配下の受信クライアントの情報と、どのマルチキャストアドレス宛のデータをいつからいつまで受信していたかという情報を、上述した手段で保持する。
すなわち、IGMP参加希望メッセージの受信で、その受信クライアントのIPアドレスと、要求しているマルチキャストアドレスG1及び参加時刻t1を記録する。
【００８４】
同じ受信クライアントからIGMP離脱希望メッセージを受信した場合は、クライアントアドレスの情報に、IGMP離脱希望メッセージを受信した時刻t2を加える。これを各インタフェースで各マルチキャスト毎について行えば、管理に必要な情報を取得できる。
各ネットワーク中継装置が自分自身に接続しているそれぞれのローカルサブネットについて収集した管理情報は、すぐにサーバ方向へ送信するのではなく、例えばマルチキャストセッションが終了した時点などを契機として、ネットワークを構成する事業者、あるいはサービスを提供しているISPなどの管理サーバに向けて、保持している受信クライアントの情報を一括送信する。
【００８５】
あるいはマルチキャストセッションが終了した時点で、そのマルチキャストに関する情報を送信するなどの方法や、サーバ側からのコマンドにより送信してもよい。
これにより、もしリアルタイムに受信クライアントの情報をサーバ側で把握する必要が無い場合には、マルチキャストデータの送信終了後の或る時点で一括して送信することにより、サーバ側の運用や管理が簡単になる。もちろんこれらの情報は各ユーザ毎の時間課金計算や、受信ユーザ数(視聴率)調査などの目的に利用することができる。
【００８６】
上述したローカルでのユーザ情報保持機能は、図1を参照して、図中のLANスイッチSW1,SW2に設けても良いし、マルチキャストルータ1_1,1_2に設けても良い。
IGMPタイプ値の設定
以上、本発明の一実施例について述べたが、参加通知パケット、集約参加通知パケット、離脱通知パケット、及び集約離脱通知パケットをそれぞれ識別するIGMPタイプ値については、図29に示した標準規格で使用されていない値を用いればよく、例えば、
・参加通知パケット：0x31
・集約参加通知パケット：0x32
・離脱通知パケット：0x33
・集約離脱通知パケット：0x34
とすれば良い。
【００８７】
また、本発明はIPv6マルチキャストにも適用可能であるが、IPv4マルチキャストとの主な差違を以下に示す。
(1)マルチキャストMACアドレスは、128ビットIPv6アドレスの下位32ビットを48ビットのMACアドレス33:33:xx:xx:xx:xxへマッピングすることにより生成する。
(2)IPv4のIGMPに相当するMLDは、図23に示すICMPv6メッセージ(RFC2463で規定)を使用し、ICMPv6のタイプ値「130」がIGMPの問合せ(Query)メッセージ、「131」が参加希望(Report)メッセージ、「132」がDone(IGMP離脱希望と同じ)である（図24参照）。
(3)IPv6マルチキャストアドレスはFF0X:0:0:0:0:0:0:0で識別される(先頭8ビットが11111111)
すなわちこれらを意識して対応することで、本発明の方式はIPv6環境のマルチキャストにも適用可能である。
【００８８】
実施例［７］
以上の方法により受信クライアントの管理が可能になるが、クライアントのOS障害やメディア再生アプリケーションのハングアップなどで受信ができない場合に、離脱メッセージ、すなわちIGMP離脱希望メッセージを送信することができない。この場合、正確なクライアントの離脱管理ができないことになる。これを解決するための実施例を以下に述べる。
通常、マルチキャストルータは、IGMP問合せ(Query)メッセージを“All-Systems Group”アドレスである“224.0.0.1”へ定期送信(デフォルト125秒)しており、受信中の各クライアントはこの問合せメッセージを受信してIGMP参加希望メッセージを送信する。
上述したIGMP参加希望メッセージはクライアントが、マルチキャストデータの受信を決めた時点で自主的に送信するものである場合が多く、ネットワーク中継装置から定期送信されるIGMP問合せメッセージに応答して送信するものではない場合が多いが、定期送信されるIGMP問合せメッセージに応答して送信されるIGMP参加希望メッセージにより定期的なクライアントの生存監視を行っている。これは通常の標準で規定された動作である。
【００８９】
もし仮に或る受信クライアントがOS障害やメディア再生アプリケーションのハングアップなどで受信ができない場合には、ネットワーク中継装置から定期送信されるIGMP問合せメッセージに応答しなくなり、IGMP参加希望メッセージを送信しなくなる。
ネットワーク中継装置では、IGMP問合せメッセージに応答しなくなった受信クライアントを受信停止と見なし、自己のクライアント管理テーブルに離脱時間を記入し、ステータスを「受信停止／エラー」と記述し、そのクライアント用の離脱通知メッセージを生成してサーバS1へ送信することで、このような障害に対応したクライアント管理が可能となる。
【００９０】
この場合には、クライアントが、マルチキャストデータの受信を決めた時点で自発的に送信するIGMP参加希望メッセージで情報が書き込まれる場合が多いことは上述したとおりであるが、定期送信されるIGMP問合せメッセージに応答したIGMP参加希望メッセージの受信を待って生存確認を行うという動作になる。
もし正確に1分単位でクライアント管理を行う場合は、定期送信される問合せメッセージのタイマをデフォルトの125秒から60秒に設定して運用すればよい。10分単位などの場合はデフォルト値で十分である。
【００９１】
もしクライアントが受信を開始した場合には、その開始時刻と、その後の離脱時刻も管理テーブルに反映すればよい。
また、ネットワーク中継装置で管理テーブルを保持しておく場合には、情報をネットワーク中継装置の管理テーブルに反映しておき、ある契機でサーバへ一括送信すれば良い。
あるいは、別の手段として、各受信クライアントの生存確認をPingにより行う方法などもある。
【００９２】
この概要が図25に示されている。
すなわち、同図(a)は3つのフェーズPS1〜PS3に分けることができ、フェーズPS1では、グループ参加を行うため、クライアントR1はIGMP参加希望パケットを送信し（同図(1)）、マルチキャストルータ1は、参加通知パケットを生成する（同図(2)）とともに該パケットをマルチキャスト対応ネットワークMNWを経由してサーバS1へ送信する（同図(3)）。サーバS1は、これよりクライアント管理テーブル23を作成する（同図(4)）。
【００９３】
フェーズPS2は障害検出フェーズを示し、マルチキャストルータ1が定期的に問合せメッセージを送信している場合（同図(5)）、クライアントR1が障害状態にあると仮定すれば、クライアントR1はその問合せに対してIGMP参加希望パケットは送信できない（同図(6)）。
これにより、マルチキャストルータ1はクライアントR1が障害状態にあることを検出し、自己のクライアント管理テーブルにその旨記入する（同図(7)）。そして、マルチキャストルータ1はクライアントR1に関する離脱通知パケットを生成し（同図(8)）、サーバS1へ送信する（同図(9)）。サーバS1では、クライアントR1に関する管理情報を更新する（同図(10)）。
【００９４】
フェーズPS3は受信再開フェーズを示し、障害が復旧した後、クライアントR1はIGMP参加希望パケットを送信し（同図(11)）、これに応答してマルチキャストルータ1は参加通知パケットを生成して（同図(12)）、サーバS1へ送信する（同図(13)）。サーバS1ではクライアント管理テーブルを更新する（同図(14)）。
この結果、サーバS1におけるクライアント管理テーブル23内のクライアントR1に関する情報は受信を再開した時間t3の情報も含めて同図(b)に示すようになる。
時間課金サービス
以上、受信クライアントのサーバでの管理方式について述べたが、この仕組みを使用して新たなサービスを提供することができる。
【００９５】
既に述べたように、マルチキャストによる音声、画像などのデータ配信では、どのような受信クライアントが存在し、或る時点で総計いくつの受信クライアントが存在し、あるいは統計でいくつの受信クライアントがマルチキャストデータを受信していたか、というような情報が把握できなかった。
これはマルチキャストの仕組みに元々そのような概念が無いことと、データ送信にUDPパケットを使用するためであり、このような背景が、同時に多くの利点も持つマルチキャストの普及を妨げている。
【００９６】
そこで、本発明の提供するネットワーク中継装方法及び装置により、従来では不可能であったマルチキャストデータ配信におけるユーザ管理サービスや、受信クライアント毎のコンテンツ利用の時間課金サービスが提供できる。
現在の（ユニキャストによる）有料コンテンツ配信のサービス形態は、主に以下の2つが提供されている。一方は一定料金でサービス利用の権利を購入する形態で、他方が従量課金形態である。また、これらはすべてユニキャストであり、配信形態はオンデマンドあるいはリアルタイム中継である。
【００９７】
この時、特にリアルタイム中継に関しては、設備投資を抑制できる点でマルチキャストが有効であることは既に述べたが、ユーザ自体の管理ができないためにサービスを提供するとすればコンテンツアクセスの権利を購入するという方法以外になかった。しかもマルチキャストはオンデマンドでは無くリアルタイムコンテンツ配信であるため、受信可能な時間に必ずアクセスする必要があった。
【００９８】
しかし、本発明により受信クライアント管理を行えば、コンテンツにアクセスしていた時間に応じた課金が可能であり、事業者はサービスの提供が非常にし易くなる。
また、ユーザ側にとっても、仮にコンテンツの放送時間にアクセスすることができなければ無課金、あるいは、コンテンツ放送中の一定時間だけコンテンツにアクセスして配信される番組を利用した場合に、その時間分だけの課金となり、ユーザ側にとってもメリットのあるサービスが提供可能となる。
【００９９】
このサービス提供形態例が図26及び図27に示されている。
図26の例では、ISP/NSPなどのサーバサイトSTには、クライアント管理／認証サーバS11と課金サーバSRとマルチキャストコンテンツ配信／クライアント管理サーバS13とが設けられており、サーバS13がクライアント20等のマルチキャスト参加／離脱情報を、サーバS11でクライアント管理／認証することにより、クライアント収容スイッチSW及びマルチキャスト対応ルータ1_1〜1_5等を経由して収集する。
【０１００】
そして、図27に示すように、インターネット接続／コンテンツ配信事業者30は、通常のインターネット接続サービス32をクライアント20に提供(2)してインターネット接続料金(3)をクライアント（ユーザ）に課金するとともに、インターネット接続／コンテンツ配信事業者30がさらなる付加価値サービスとして、クライアント20にコンテンツ配信サービスを提供(1)する際に、マルチキャストを使用した従量課金によるマルチキャストコンテンツ配信サービスDSを提供することができる。
【０１０１】
すなわち、クライアント20の番組受信時間に基づいて課金するコンテンツ配信サービスDSを提供することができ、インターネット接続／コンテンツ配信事業者30はクライアント20の番組聴取時間に基づいて、クライアント20に対して番組聴取料金を課金・請求する。
以上のとおり、本発明によれば、現在のユニキャスト通信と同様に、従来不可能であったマルチキャストによるデータ配信における受信ユーザ管理を可能とすることでマルチキャスト通信における信頼性を提供でき、マルチキャスト対応ネットワーク機器やエンドシステム、マルチキャスト対応アプリケーションの普及に寄与するものである。
【０１０２】
また本発明によれば、マルチキャスト環境でのユーザ管理機能を提供することにより、ある時点での受信クライアント数やトータルの受信者数などの把握、管理を可能とし、マルチキャストによるコンテンツ配信サービスやインターネットリアルタイム放送の普及に寄与するものである。
さらに、本発明により、マルチキャスト配信でありながらユーザ管理を提供することにより、従来不可能であったマルチキャストコンテンツ配信における時間課金サービスを提供することができ、コンテンツ配信ビジネスの普及や、さらにはコンテンツ受信の目的でのブロードバンドネットワークの普及にも貢献するものである。
【図面の簡単な説明】
【０１０３】
【図１】本発明に係るネットワーク中継方法及び装置を説明するためのネットワーク構成例を示した図である。
【図２】本発明に係るネットワーク中継装置の原理構成ブロック図である。
【図３】本発明の実施例を説明するためのネットワーク構成例を示した図である。
【図４】図3のネットワーク構成例を簡略化して示した図である。
【図５】本発明に係るネットワーク中継装置の実施例を示した構成ブロック図である。
【図６】マルチキャスト参加通知パケットのフォーマット図である。
【図７】サーバへのマルチキャスト参加通知シーケンスとサーバが管理する受信クライアント管理テーブルを示した図である。
【図８】クライアント情報集約時のネットワーク例を示した図である。
【図９】マルチキャスト集約参加通知パケットのフォーマット図である。
【図１０】サーバへのマルチキャスト集約参加通知シーケンスと受信クライアント管理テーブルを示した図である。
【図１１】下流からのマルチキャスト集約参加通知パケットとマルチキャスト参加希望メッセージの情報の集約ネットワーク例を示した図である。
【図１２】サーバへの経路の途中で情報が加えられたマルチキャスト集約参加通知パケットのフォーマット図である。
【図１３】マルチキャスト集約参加通知パケットへの情報追加シーケンスと受信クライアント管理テーブルを示した図である。
【図１４】サーバの一実施例(クライアント管理とマルチキャストデータ送信サーバを兼ねる場合)を示したブロック図である。
【図１５】プロトコルIDフィールドで識別するマルチキャスト(集約)参加通知パケットのフォーマット図である。
【図１６】図１５におけるIPヘッダを示したフォーマット図である。
【図１７】マルチキャスト離脱通知パケットのフォーマット図である。
【図１８】サーバへのマルチキャスト離脱通知シーケンスと受信クライアント管理テーブルを示した図である。
【図１９】マルチキャスト集約離脱通知パケットのフォーマット図である。
【図２０】サーバが管理するマルチキャスト集約離脱時の受信クライアント管理テーブル図である。
【図２１】サーバへの経路の途中で情報を加えられたマルチキャスト集約離脱通知パケットのフォーマット図である。
【図２２】図２１に関してサーバが管理する受信クライアント管理テーブル図である。
【図２３】ICMPv6メッセージの一般的なフォーマット図である。
【図２４】MLDメッセージの一般的なフォーマット図である。
【図２５】クライアント障害の検出とサーバへの通知及び管理テーブル更新の概要を示した図である。
【図２６】マルチキャストコンテンツを利用したときの時間課金サービス概念図である。
【図２７】本発明を利用したマルチキャストコンテンツ配信サービスと時間課金体系の一例を示した図である。
【図２８】IGMPの一般的なマルチキャスト参加／離脱手順を説明するための図である。
【図２９】IGMPv2パケットの一般的なフォーマット図である。
【図３０】IPv4ヘッダの一般的なフォーマット図である。
【図３１】マルチキャストアドレスの利用目的別の割当を説明した図である。
【符号の説明】
【０１０４】
1(1_1〜1_7)  マルチキャストルータ(ネットワーク中継装置)
2,7,8,21  送受信インタフェース
3(3_1〜3_3),22  パケット判別部
4  パケット生成部
5  転送処理部
6  ルーティングテーブル
9  マルチキャスト処理部
10  タイマ
11  クライアント情報保持部
23  クライアント管理テーブル
S1,S11〜S13  サーバ
MNW  マルチキャスト対応ネットワーク
PKT (PKT1,PKT2,PKT2_1,PKT2_2,PKT_21,PKT_22)  パケット
SW (SW1,SW2)  LANスイッチ
CMP1〜CMP3  クライアント管理情報パケット
R1〜R3,R11〜R14  クライアント
DT  マルチキャストデータ
図中、同一符号は同一又は相当部分を示す。
【図１】
0004297875.tif 000002
【図２】
0004297875.tif 000003
【図３】
0004297875.tif 000004
【図４】
0004297875.tif 000005
【図５】
0004297875.tif 000006
【図６】
0004297875.tif 000007
【図７】
0004297875.tif 000008
【図８】
0004297875.tif 000009
【図９】
0004297875.tif 000010
【図１０】
0004297875.tif 000011
【図１１】
0004297875.tif 000012
【図１２】
0004297875.tif 000013
【図１３】
0004297875.tif 000014
【図１４】
0004297875.tif 000015
【図１５】
0004297875.tif 000016
【図１６】
0004297875.tif 000017
【図１７】
0004297875.tif 000018
【図１８】
0004297875.tif 000019
【図１９】
0004297875.tif 000020
【図２０】
0004297875.tif 000021
【図２１】
0004297875.tif 000022
【図２２】
0004297875.tif 000023
【図２３】
0004297875.tif 000024
【図２４】
0004297875.tif 000025
【図２５】
0004297875.tif 000026
【図２６】
0004297875.tif 000027
【図２７】
0004297875.tif 000028
【図２８】
0004297875.tif 000029
【図２９】
0004297875.tif 000030
【図３０】
0004297875.tif 000031
【図３１】
0004297875.tif 000032