(57)【要約】マルチキャストによりサーバからクライアントにデータ配信する時のネットワーク中継方法及び装置において、マルチキャストグループに対してクライアントが送信した参加／離脱情報を判別し、該クライアントの参加／離脱情報をマルチキャスト参加／離脱通知情報に加工し、該マルチキャスト参加／離脱通知情報をサーバに転送する。
2004043019.tif 000002
【特許請求の範囲】
【請求項１】
マルチキャストグループに対してクライアントが送信した参加／離脱情報を判別する第１ステップと、
該クライアントの参加／離脱情報をマルチキャスト参加／離脱通知情報に加工する第２ステップと、
該マルチキャスト参加／離脱通知情報をサーバに転送する第３ステップと、
を備えたことを特徴とするネットワーク中継方法。
【請求項２】
請求の範囲１において、
該マルチキャスト参加／離脱通知情報が、該クライアントの識別情報とマルチキャストアドレスと参加／離脱開始時刻とを含むことを特徴とするネットワーク中継方法。
【請求項３】
請求の範囲１において、
該第１ステップが、該クライアントからのマルチキャスト制御パケットに搭載された該クライアントの参加／離脱情報を判別し、該第２ステップが、該クライアントの参加／離脱情報を該マルチキャスト参加／離脱通知パケットに加工し、該第３ステップが該マルチキャスト参加／離脱通知パケットを該サーバに転送することを特徴としたネットワーク中継方法。
【請求項４】
請求の範囲３において、
該第２ステップが、該マルチキャスト参加／離脱通知パケットを該サーバへ転送する際、一定時間内に別のクライアントから同一のマルチキャストグループに対する参加／離脱情報を受信した場合、それら全てのクライアントの参加／離脱情報を１つのパケットに集約した集約参加／離脱通知パケットを生成し、該第３ステップで該集約参加／離脱通知パケットを該サーバに転送することを特徴としたネットワーク中継方法。
【請求項５】
請求の範囲３において、
該第１ステップが、該マルチキャスト参加／離脱通知パケットを下流のネットワーク装置から受信したと判別したとき、該第３ステップは、該マルチキャスト参加／離脱通知パケットをさらに該サーバへ転送することを特徴としたネットワーク中継方法。
【請求項６】
請求の範囲４において、
該第１ステップが、該集約参加／離脱通知パケットを下流のネットワーク装置から受信したと判別したとき、該第３ステップは、該集約参加／離脱通知パケットをさらに該サーバへ転送することを特徴としたネットワーク中継方法。
【請求項７】
請求の範囲４において、
該第１ステップが、該集約参加／離脱通知パケットを下流のネットワーク中継方法から受信したと判別したとき、該第２ステップは、自分自身のクライアントから同一のマルチキャストグループに対する参加／離脱情報を集約している場合、それら全ての参加／離脱情報を１つのパケットに集約した集約参加／離脱通知パケットを生成し、該第３ステップで該集約参加／離脱通知パケットを即座に該サーバへ転送することを特徴としたネットワーク中継方法。
【請求項８】
請求の範囲１から７のいずれか一つにおいて、
該第３ステップでは、該サーバから転送要求があるときまで、該クライアントの参加／離脱情報を保持することを特徴としたネットワーク中継方法。
【請求項９】
請求の範囲２において、
該クライアントの識別情報としてパケットに含まれる送信元アドレスを利用することを特徴としたネットワーク中継方法。
【請求項１０】
請求の範囲１おいて、
該第３ステップは、該クライアントが、定期的な問合せに応答しないとき、該クライアントの離脱通知情報を該サーバに送ることを特徴としたネットワーク中継方法。
【請求項１１】
マルチキャストグループに対してクライアントが送信した参加／離脱情報を判別する判別部と、
該クライアントの参加／離脱情報をマルチキャスト参加／離脱通知情報に加工する情報加工部と、
該マルチキャスト参加／離脱通知情報をサーバに転送する転送処理部と、
を備えたことを特徴とするネットワーク中継装置。
【請求項１２】
請求の範囲１において、
該マルチキャスト参加／離脱通知情報が、該クライアントの識別情報とマルチキャストアドレスと参加／離脱開始時刻とを含むことを特徴とするネットワーク中継装置。
【請求項１３】
請求の範囲１において、
該判別部が、該クライアントからのマルチキャスト制御パケットに搭載された該クライアントの参加／離脱情報を判別し、該情報加工部が、該クライアントの参加／離脱情報を該マルチキャスト参加／離脱通知パケットに加工し、該転送処理部が該マルチキャスト参加／離脱通知パケットを該サーバに転送することを特徴としたネットワーク中継装置。
【請求項１４】
請求の範囲１において、
該情報加工部が、該マルチキャスト参加／離脱通知を該サーバへ転送する際、一定時間内に別のクライアントから同一のマルチキャストグループに対する参加／離脱情報を受信した場合、それら全てのクライアントの参加／離脱情報を１つのパケットに集約した集約参加／離脱通知パケットを生成し、該転送処理部が、該集約参加／離脱通知パケットを該サーバに転送することを特徴とするネットワーク中継装置。
【請求項１５】
請求の範囲３において、
該判別部が、該マルチキャスト参加／離脱通知を下流のネットワーク装置から受信したと判別したとき、該転送処理部は、該マルチキャスト参加／離脱通知パケットをさらに該サーバへ転送することを特徴としたネットワーク中継装置。
【請求項１６】
請求の範囲４において、
該判別部が、該集約参加／離脱通知パケットを下流のネットワーク装置から受信したと判別したとき、該転送処理部は、該集約参加／離脱通知パケットをさらに該サーバへ転送することを特徴としたネットワーク中継装置。
【請求項１７】
請求の範囲４において、
該判別部が、該集約参加／離脱通知パケットを下流のネットワーク中継装置から受信したと判別したとき、該情報加工部は、自分自身のクライアントから同一のマルチキャストグループに対する参加／離脱情報を集約している場合、それら全ての参加／離脱情報を１つのパケットに集約した集約参加／離脱通知パケットを生成し、該転送処理部が、該集約参加／離脱通知パケットを即座に該サーバへ転送することを特徴としたネットワーク中継装置。
【請求項１８】
請求の範囲１から７のいずれか一つにおいて、
該転送処理部は、該サーバから転送要求があるときまで、該クライアントの参加／離脱情報を保持することを特徴としたネットワーク中継装置。
【請求項１９】
請求の範囲２において、
該クライアントの識別情報としてパケットに含まれる送信元アドレスを利用することを特徴としたネットワーク中継装置。
【請求項２０】
請求の範囲８において、
該転送処理部は、該クライアントが、定期的な問合せに応答しないとき、該クライアントの離脱通知を該サーバに送ることを特徴としたネットワーク中継装置。
【請求項２１】
請求の範囲１から１０のいずれかに記載のネットワーク中継装置から送信されたマルチキャスト参加／離脱通知情報を判別する判別部と、
該マルチキャスト参加／離脱通知における該クライアントの情報を抽出して保持する保持部と、
を備えたことを特徴とするサーバ。
【請求項２２】
請求の範囲２１において、
該クライアントの情報に基づいてマルチキャストデータ配信の時間課金を行う手段を備えたことを特徴するサーバ。
【発明の詳細な説明】
【技術分野】  本発明は、ネットワーク中継方法及び装置に関し、特にマルチキャストによりサーバからクライアントにデータ配信する時のネットワーク中継方法及び装置に関するものである。
【背景技術】  近年は、パーソナルコンピュータの急速な普及と共に、企業網（イントラネット）も拡充の方向に在り、コンピュータやネットワークそれ自体の高機能化、高性能化も進んでいる。また、ウェブページ（ＷＷＷ）の普及、動画、音声といったマルチメディアデータの普及も急速に進みつつある。
さらに、近年は企業ユーザ、一般ユーザも含めたインターネットアクセスにおけるブロードバンドネットワークの普及が進みつつあり、いわゆるマルチメディアと呼ばれる音声や動画の利用や、これを利用した配信、放送サービスによるビジネス形態が増えて来ている。
普及途上の現在では、各ユーザにユニキャストでデータを配信する方法が多く用いられており、特に多数のユーザがアクセスするような動画配信などでは、負荷分散の目的から、データ配信元に多数のサーバを設置したり、あるいは地域毎にキャッシュサーバを設けて、ユーザは近隣のキャッシュサーバからデータを受信する仕組みが取り入れられている。
これはオンデマンド放送でもリアルタイム放送でも同じであり、多数のユーザがそれぞれ満足する品質を提供するためには、必要とされる設備が多く、多額の投資を必要とする。
一方、大量のデータを効率良く伝送するために「マルチキャスト」技術によるデータ伝送も行われ始めており、マルチキャストを使用したマルチメディアデータ伝送は今後ますます普及することが予想される。
マルチキャストは、基本的にオンデマンドの配信は行えないが、ライブ中継など、リアルタイムの動画配信や音声配信では多くのメリットを有する。
すなわち、マルチキャスト配信では、図１に示すように、サーバＳ１はデータを受信するユーザ（クライアント）の数に関わらず、１つのストリームをマルチキャスト対応ネットワークＭＮＷに送信するだけでマルチキャストルータ１＿１，１＿２（以下，符号「１」で総称することがある。）やＬＡＮスイッチＳＷ１，ＳＷ２（以下，符号「ＳＷ」で総称することがある。）を介して多数のクライアントＲ１，Ｒ２…に該データを受信させることができる。
従って各地にキャッシュを設ける必要もなく、さらにはユニキャストと異なり各ネットワークでの帯域を節約することができる。
言い換えると、ユーザ数に関わらず、或る経路のトラフィック量は一定に保つことができ、その他の通信に与える影響も少なく、また、ユニキャストの場合のように配信専用にネットワークやキャッシュサーバなどの設備を設ける必要がなく、非常に安価にマルチメディアデータを配信することが可能となる。
ただし、サーバからクライアントまでのネットワーク全体がマルチキャストに対応している必要がある、という制限はあるが、現在ではネットワークに設置される中継装置やデータ配信サーバ、あるいはクライアントが使用するパーソナルコンピュータの全てでマルチキャストの対応はほぼ完了している状況になっており、特にリアルタイム放送形式の動画配信や音声配信では徐々にマルチキャストが使用される割合が高くなって来ると考えられている。
ここで、マルチキャストデータ配信の環境や仕組みについて概要を説明する。
具体的には、ＩＰマルチキャストアドレス（グループアドレス）とデータリンク層のマルチキャストアドレス、クライアント（ホスト）とマルチキャストルータ間のプロトコルであるＩＧＭＰ（Ｉｎｔｅｒｎｅｔ  Ｇｒｏｕｐ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）、ネットワーク内でマルチキャスト配信ツリーを構築するマルチキャストルーティングプロトコルのそれぞれについて説明する。なお、データリンク層はイーサネットの場合について説明する。
ＩＰマルチキャスト配信は、アドレスにマルチキャストアドレスを使用し、図２８（ａ）及び（ｂ）に示す如く、クライアントＲ１，Ｒ２とマルチキャストルータ１との間で機能し、ルータ１が配下のクライアントＲ１，Ｒ２のマルチキャストグループの把握を行う機能を提供するＩＧＭＰ、及びルータ間でサーバから複数の各受信クライアントまでのマルチキャストデータ配信ツリーを構築するマルチキャストルーティングプロトコルを動作させることで実現される。
ここで、ＩＧＭＰとは、クライアントＲ１，Ｒ２とルータ１が図２９に示すパケットフォーマットのＩＧＭＰメッセージをやり取りすることによって、ルータ１が自分が属するローカルネットワークに受信クライアントが存在するか否かを把握／管理するプロトコルである。
言い換えるとクライアントＲ１，Ｒ２が或るマルチキャストグループに参加することをルータ１に伝えるための、ルータ−クライアント間のプロトコルであり、ルータ、クライアント共にＩＧＭＰ（図３０に示すＩＰヘッダにおける「プロトコルＩＤ」が“２”の場合に適用）で規定されているそれぞれの機能を実装する必要がある。ＩＧＭＰｖ１はＲＦＣ１１１２の付録１で、ＩＧＭＰｖ２はＲＦＣ２２３６で規定され、ＩＧＭＰｖ３がＩＥＴＦにて標準化中である。
また、マルチキャストルーティングプロトコルとは、図１に示すように、複数のマルチキャストルータ１やレイヤ３スイッチＳＷによって構成されるネットワークにおいて、ルータ１がマルチキャストデータストリームを受信クライアントＲ１，Ｒ２へ配信するために、ルータ１のどのインタフェースへマルチキャストデータをコピーして送信するかを決める経路制御（あるいは経路木の構成）のための、ルータ間のプロトコルである。
その種類として、ＤＶＭＲＰ（ＭＢｏｎｅで使用、ＲＦＣ１０７５で規定）、ＰＩＭ（ＲＦＣ２１１７で規定、及び新たなバージョンがＩＥＴＦで検討中）、ＭＯＳＰＦ（ＯＳＦＰ上のみで動作可、ＲＦＣ１５８４、１５８５で規定）などがある。
なお、上記のＲＦＣ１１１２とは、クラスＤのＩＰアドレス、すなわちマルチキャストＩＰアドレスとマルチキャスト物理アドレスとのマッピングや、特定のマルチキャスト物理アドレスのパケットのみを受信し上位層へ上げるフィルタリング機能である。
このマルチキャストＩＰアドレスとマルチキャスト物理アドレスとの対応付けは、マルチキャストＩＰアドレスの下位２３ビットをマルチキャスト物理アドレス“０１．００．５Ｅ．００．００．００１６”の下位２３ビットに入れると規定（ＲＦＣ１７００）されている。例えば、マルチキャストＩＰアドレス“２３９．１３３．１３０．３４”はマルチキャスト物理アドレス“０１：００：５Ｅ：０５：８２：２２”となる。
また、マルチキャストアドレス（ＩＰｖ４）は、クラスＤアドレスとして規定されており、１０進表記で、“２２４．０．０．０”から“２３９．２５５．２５５．２５５”の範囲である。
図３１にクラスＤのＩＰアドレスを示す。クラスＤアドレスは、最初の４ビット“１１１０”で識別される。図示の通り、いくつかのマルチキャストアドレスは特定用途のために予約されている。
ローカルサイト用の割り当て、すなわち、“２３９．０．０．０”から“２３９．２５５．２５５．２５５”までが、例えば企業ネットワークやＩＳＰなどで一般に使用できるＩＰマルチキャストアドレスである。
上記のようなマルチキャストデータの配信手順を図２８により以下に簡単に説明する。
［１］マルチキャストグループへの参加
（１）マルチキャストルータ１は、ローカルネットワークに接続しているクライアントＲ１，Ｒ２にマルチキャストグループへの参加を尋ねるため、図２９に示すフォーマット（ＩＧＭＰｖ２）のパケットにおけるＩＧＭＰヘッダ内のタイプ値が「Ｏｘ１１」の“ＨＭＱ（Ｈｏｓｔ  Ｍｅｍｂｅｒｓｈｉｐ  Ｑｕｅｒｙ）（メンバ問合せ）”メッセージ（図２８（ａ）▲１▼）を定期的に“２２４．０．０．１”（Ａｌｌ−Ｓｙｓｔｅｍｓ−Ｇｒｏｕｐ）宛に送信する。
（２）マルチキャストグループへの参加を希望するクライアントは上記の“メンバ問合せ”に応答して、参加を希望するグループのマルチキャストアドレスを通知するために、同じフォーマットのパケットにおけるＩＧＭＰヘッダ内のタイプ値が「Ｏｘ１２」の“ＨＭＲ（Ｈｏｓｔ  Ｍｅｍｂｅｒｓｈｉｐ  Ｒｅｐｏｒｔ）（メンバ参加希望）”メッセージ（同図▲２▼）を参加するマルチキャストアドレス宛に送信する。
マルチキャストルータ１は、これを受信して、クライアントが参加するマルチキャストグループ（上述のクラスＤのアドレスで識別される。）を把握し、ローカルネットワークへマルチキャストデータ（ストリーム）の送信を開始する。
［２］マルチキャストデータ配信
（１）一方、マルチキャストデータの送信サーバ（例えば図１のサーバＳ１）は、クラスＤのアドレスで識別されるマルチキャストグループ宛に、“１つの”データ（ストリーム）を送信する。
（２）ネットワーク内のマルチキャストルータ１は、そのマルチキャストグループに参加している各受信クライアントへの経路に沿って、そのグループ宛のデータストリームを必要に応じてコピーしながら伝送して行く。
言い換えると、マルチキャストルーティングプロトコルによって構成された、送信サーバから各受信クライアントへ至るマルチキャストデータ配信の経路木に沿って、マルチキャストデータが配信される。最終的に、サーバが送信した“１つの”データストリームは、ネットワーク内の“複数の”クライアントへ配信されることになる。
［３］マルチキャストグループからの離脱
（１）参加しているマルチキャストグループからの離脱を希望するクライアントは、離脱を決めた時点で、図２８（ｂ）に示すように、“Ｌｅａｖｅ（離脱希望）”メッセージ（同図▲３▼）を“２２４．０．０．２”（Ａｌｌ−Ｒｏｕｔｅｒｓ−Ｇｒｏｕｐ）宛に送信する。
（２）“離脱希望”メッセージを受信したマルチキャストルータ１は、未だ他にそのマルチキャストグループに参加しているクライアントが存在しないことを確認するために、そのグループアドレスを指定して“ＧＳ−Ｑ（Ｇｒｏｕｐ  Ｓｐｅｃｉｆｉｃ  Ｑｕｅｒｙ）”メッセージ（同図▲４▼）を送信する。
この場合、もし“離脱希望”メッセージを送信したクライアント以外に、未だそのグループに参加しているクライアントが存在するときには、そのクライアントは“メンバ参加希望”メッセージを送信してその存在をマルチキャストルータ１に伝える。
このように、マルチキャストを使用したデータ、コンテンツの配信では、メリットが多くある反面、ユニキャストの場合のように各クライアント宛にサーバがデータを送信する訳では無いため、また、マルチキャスト自体がＵＤＰ（Ｕｓｅｒ  Ｄａｔａ  Ｐｒｏｔｏｃｏｌ）パケットを使用するため、個々のユーザ管理が困難である。
管理が困難であるということは、例えば、ある時点の受信クライアント数や、各々のクライアントについて、いつからいつまでデータを受信していたかを把握したり、さらにクライアント自体の情報などを取得・管理することができないということである。
従って、どのコンテンツに人気があり、どの位の数のクライアントが受信していたかということを検討するための情報収集や、サービス形態としてデータを受信していた時間に応じた課金などが実現できなかった。
従って本発明は、マルチキャストによりサーバからクライアントにデータ配信する時に、マルチキャストに参加／離脱する個々のクライアント情報を管理するネットワーク中継方法及び装置を実現することを目的とする。
【発明の開示】
上記の目的を達成するため、本発明に係るネットワーク中継方法は、マルチキャストグループに対してクライアントが送信した参加／離脱情報を判別する第１ステップと、該クライアントの参加／離脱情報をマルチキャスト参加／離脱通知情報に加工する第２ステップと、該マルチキャスト参加／離脱通知情報をサーバに転送する第３ステップと、を備えたことを特徴としている。
上記のマルチキャスト参加／離脱通知情報は、該クライアントの識別情報とマルチキャストアドレスと参加／離脱開始時刻とを含むことができる。
また、上記の第１ステップでは、該クライアントからのマルチキャスト制御パケットに搭載された該クライアントの参加／離脱情報を判別し、上記の第２ステップでは、該クライアントの参加／離脱情報を該マルチキャスト参加／離脱通知パケットに加工し、該第３ステップが該パケットを該サーバに転送することができる。
また、上記の第２ステップでは、該マルチキャスト参加／離脱通知パケットを該サーバへ転送する際、一定時間内に別のクライアントから同一のマルチキャストグループに対する参加／離脱情報を受信した場合、それら全てのクライアントの参加／離脱情報を１つのパケットに集約した集約参加／離脱通知パケットを生成し、該第３ステップで該集約参加／離脱通知パケットを該サーバに転送することができる。
さらに、上記の第１ステップで、該マルチキャスト参加／離脱通知パケットを下流のネットワーク装置から受信したと判別したとき、上記の第３ステップでは、該マルチキャスト参加／離脱通知パケットをさらに該サーバへ転送することができる。
さらに上記の第１ステップで、該集約参加／離脱通知パケットを下流のネットワーク装置から受信したと判別したとき、上記の第３ステップでは、該集約参加／離脱通知パケットをさらに該サーバへ転送することができる。
さらに上記の第１ステップで、該集約参加／離脱通知パケットを下流のネットワーク中継方法から受信したと判別したとき、上記の第２ステップでは、自分自身のクライアントから同一のマルチキャストグループに対する参加／離脱情報を集約している場合、それら全ての参加／離脱情報を１つのパケットに集約した集約参加／離脱通知パケットを生成し、これを上記第３ステップで即座に該サーバへ転送することができる。
さらに、上記第３のステップでは、該サーバから転送要求があるときまで、該クライアントの参加／離脱情報を保持することができる。
さらに、上記のクライアントの識別情報としてパケットに含まれる送信元アドレスを利用することも可能である。
さらに上記の第３ステップでは、該クライアントが、定期的な問合せに応答しないとき、該クライアントの離脱通知情報を該サーバに送ることができる。
上記の本発明に係るネットワーク中継方法を実現する装置としては、マルチキャストグループに対してクライアントが送信した参加／離脱情報を判別する判別部と、該クライアントの参加／離脱情報をマルチキャスト参加／離脱通知情報に加工する情報加工部と、該マルチキャスト参加／離脱通知情報をサーバに転送する転送処理部と、を備えたことを特徴としている。
上記のマルチキャスト参加／離脱通知情報は、該クライアントの識別情報とマルチキャストアドレスと参加／離脱開始時刻とを含むことができる。
また、上記の判別部は、該クライアントからのマルチキャスト制御パケットに搭載された該クライアントの参加／離脱情報を判別し、上記の情報加工部は該クライアントの参加／離脱情報を該マルチキャスト参加／離脱通知パケットに加工し、該転送処理部が該マルチキャスト参加／離脱通知パケットを該サーバに転送することができる。
また、上記の情報加工部は、該マルチキャスト参加／離脱通知を該サーバへ転送する際、一定時間内に別のクライアントから同一のマルチキャストグループに対する参加／離脱情報を受信した場合、それら全てのクライアントの参加／離脱情報を１つのパケットに集約した集約参加／離脱通知パケットを生成し、該転送処理部が、該集約参加／離脱通知パケットを該サーバに転送することができる。
また、上記の判別部が、該マルチキャスト参加／離脱通知を下流のネットワーク装置から受信したと判別したとき、上記の転送処理部は、該マルチキャスト参加／離脱通知パケットをさらに該サーバへ転送することができる。
また、上記の判別部が、該集約参加／離脱通知パケットを下流のネットワーク装置から受信したと判別したとき、上記の転送処理部は、該集約参加／離脱通知パケットをさらに該サーバへ転送することができる。
さらに上記の判別部が、該集約参加／離脱通知パケットを下流のネットワーク中継装置から受信したと判別したとき、上記の情報加工部は、自分自身のクライアントから同一のマルチキャストグループに対する参加／離脱情報を集約している場合、それら全ての参加／離脱情報を１つのパケットに集約した集約参加／離脱通知パケットを生成し、これを該転送処理部が、即座に該サーバへ転送することができる。
また、上記の転送処理部は、該サーバから転送要求があるときまで、該クライアントの参加／離脱情報を保持することができる。
上記のクライアントの識別情報としてパケットに含まれる送信元アドレスを利用することができる。
さらに上記の転送処理部は、該クライアントが、定期的な問合せに応答しないとき、該クライアントの離脱通知情報を該サーバに送ることができる。
さらに上記のネットワーク中継装置から送信されたマルチキャスト参加／離脱通知情報を判別する判別部と、該マルチキャスト参加／離脱通知における該クライアントの情報を抽出して保持する保持部と、でサーバを構成することができる。
そして、このサーバにおいては、該クライアントの情報に基づき、マルチキャストデータ配信（コンテンツ受信）の時間課金を行う手段を有することができる。
上述した本発明に係るネットワーク中継方法及び装置について図を参照して以下に説明する。
図１は本発明の概念を説明するためのネットワーク構成例を示している。図中、Ｓ１はマルチキャストデータの送信サーバ、１＿１，１＿２は本発明のネットワーク中継方法及び装置を実装したマルチキャスト（対応）ルータ、ＳＷ１，ＳＷ２はクライアントを収容するＬＡＮスイッチあるいはレイヤ２スイッチ、ＭＮＷはマルチキャストルータで構成されたネットワーク、Ｒ１は通常データを受信するクライアント、Ｒ２はマルチキャストデータを受信するクライアント、ＰＫＴ１は受信クライアントＲ１，Ｒ２とマルチキャストルータ１＿２間で機能するマルチキャスト制御用パケット、ＰＫＴ２は受信クライアントの参加又は離脱（以下、参加／離脱と称する。）情報を含めてサーバへＳ１へ向けて転送されるユーザ情報パケットである。なお、パケットＰＫＴ１，ＰＫＴ２もＰＫＴで総称することがある。
また図２は、通常マルチキャスト機能を実装しているルータである本発明のネットワーク中継装置１の原理構成図を示している。このネットワーク中継装置１は、送受信インタフェース２，７，８と、マルチキャスト制御パケットＰＫＴ１の判別部３と、サーバＳ１にユーザ情報を通知するためのクライアント管理理情報パケットＰＫＴ２の生成部４と、ルーティングテーブル６を含み通常のネットワーク中継装置に実装されているルーティング処理（マルチキャストルーティング処理を含む）などを行う転送処理部５とで構成されている。
動作において、送受信インタフェース２にＬＡＮスイッチＳＷ２を介して受信クライアントＲ２が接続しているとき、受信クライアントＲ２からは、マルチキャストデータの受信を望むこと（マルチキャストグループ参加希望）を示す、あるいは今まで受信していたがもう受信を中止すること（マルチキャストグループ離脱希望）をマルチキャストルータ１に通知するためのマルチキャスト制御パケットＰＫＴ１が送信され、これをマルチキャストルータ１が受信する。
マルチキャストルータ１は、受信パケットが何であるかをパケット判別部３で検査する。もしマルチキャスト制御パケットＰＫＴ１であれば、これを通常のマルチキャストデータ転送制御するために転送処理部５へ送り、ルーティングテーブル６に情報を反映する。
これと同時に、ユーザ情報をサーバＳ１で管理できるようにするため、パケット生成部４でユーザ情報を格納したマルチキャスト参加／離脱通知パケットを生成し、転送処理部５に送り、サーバＳ１が存在する方向のインタフェース７又は８から転送する。
これがサーバ５１へ到着することで、従来マルチキャストのデータ転送では不可能であったデータの受信ユーザ管理が実現できる。
【図面の簡単な説明】  図１は、本発明に係るネットワーク中継方法及び装置を説明するためのネットワーク構成例を示した図である。
図２は、本発明に係るネットワーク中継装置の原理構成ブロック図である。
図３は、本発明の実施例を説明するためのネットワーク構成例を示した図である。
図４は、図３のネットワーク構成例を簡略化して示した図である。
図５は、本発明に係るネットワーク中継装置の実施例を示した構成ブロック図である。
図６は、マルチキャスト参加通知パケットのフォーマット図である。
図７は、サーバへのマルチキャスト参加通知シーケンスとサーバが管理する受信クライアント管理テーブルを示した図である。
図８は、クライアント情報集約時のネットワーク例を示した図である。
図９は、マルチキャスト集約参加通知パケットのフォーマット図である。
図１０は、サーバへのマルチキャスト集約参加通知シーケンスと受信クライアント管理テーブルを示した図である。
図１１は、下流からのマルチキャスト集約参加通知パケットとマルチキャスト参加希望メッセージの情報の集約ネットワーク例を示した図である。
図１２は、サーバへの経路の途中で情報が加えられたマルチキャスト集約参加通知パケットのフォーマット図である。
図１３は、マルチキャスト集約参加通知パケットへの情報追加シーケンスと受信クライアント管理テーブルを示した図である。
図１４は、サーバの一実施例（クライアント管理とマルチキャストデータ送信サーバを兼ねる場合）を示したブロック図である。
図１５は、プロトコルＩＤフィールドで識別するマルチキャスト（集約）参加通知パケットのフォーマット図である。
図１６は、図１５におけるＩＰヘッダを示したフォーマット図である。
図１７は、マルチキャスト離脱通知パケットのフォーマット図である。
図１８は、サーバへのマルチキャスト離脱通知シーケンスと受信クライアント管理テーブルを示した図である。
図１９は、マルチキャスト集約離脱通知パケットのフォーマット図である。
図２０は、サーバが管理するマルチキャスト集約離脱時の受信クライアント管理テーブル図である。
図２１は、サーバへの経路の途中で情報を加えられたマルチキャスト集約離脱通知パケットのフォーマット図である。
図２２は、図２１に関してサーバが管理する受信クライアント管理テーブル図である。
図２３は、ＩＣＭＰｖ６メッセージの一般的なフォーマット図である。
図２４は、ＭＬＤメッセージの一般的なフォーマット図である。
図２５は、クライアント障害の検出とサーバへの通知及び管理テーブル更新の概要を示した図である。
図２６は、マルチキャストコンテンツを利用したときの時間課金サービス概念図である。
図２７は、本発明を利用したマルチキャストコンテンツ配信サービスと時間課金体系の一例を示した図である。
図２８は、ＩＧＭＰの一般的なマルチキャスト参加／離脱手順を説明するための図である。
図２９は、ＩＧＭＰｖ２パケットの一般的なフォーマット図である。
図３０は、ＩＰｖ４ヘッダの一般的なフォーマット図である。
図３１は、マルチキャストアドレスの利用目的別の割当を説明した図である。
【符号の説明】
１（１＿１〜１＿７）  マルチキャストルータ（ネットワーク中継装置）
２，７，８，２１  送受信インタフェース
３（３＿１〜３＿３），２２  パケット判別部
４  パケット生成部
５  転送処理部
６  ルーティングテーブル
９  マルチキャスト処理部
１０  タイマ
１１  クライアント情報保持部
２３  クライアント管理テーブル
Ｓ１，Ｓ１１〜Ｓ１３  サーバ
ＭＮＷ  マルチキャスト対応ネットワーク
ＰＫＴ（ＰＫＴ１，ＰＫＴ２，ＰＫＴ２＿１，ＰＫＴ２＿２，ＰＫＴ＿２１，ＰＫＴ＿２２）  パケット
ＳＷ（ＳＷ１，ＳＷ２）  ＬＡＮスイッチ
ＣＭＰ１〜ＣＭＰ３  クライアント管理情報パケット
Ｒ１〜Ｒ３，Ｒ１１〜Ｒ１４  クライアント
ＤＴ  マルチキャストデータ
図中、同一符号は同一又は相当部分を示す。
【発明を実施するための最良の形態】  以下、本発明に係るネットワーク中継方法及び装置の実施例を説明する。なお、マルチキャスト制御メッセージについて、最も普及し、広く実装されている上記のＩＧＭＰｖ２（ＲＦＣ  ２２３６にて規定）メッセージの場合について説明するが、本発明はマルチキャスト制御メッセージがＩＧＭＰｖ１、ＩＧＭＰｖ３である場合にも適用可能である。
また、ＩＰｖ６の場合は、ＩＧＭＰｖ２相当の機能はＭＬＤ（Ｍｕｌｔｉｃａｓｔ  Ｌｉｓｔｅｎｅｒ  Ｄｉｓｃｏｖｅｒｙ）と呼ばれ、ＲＦＣ２７１０で規定されている。またＩＧＭＰｖ３相当の機能もＩＥＴＦで標準化作業中である。本実施例ではネットワークレイヤがＩＰｖ４の場合について説明するが、当然ながらＩＰｖ６の場合にも適用可能である。ＩＰｖ６とＩＰｖ４マルチキャストの差異については後述する。
図３は、本発明が対象とする企業ＩＰネットワークやＩＳＰ（Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）やキャリアのＩＰネットワークなど、一般的なＩＰネットワークを示し、図１と同様に、パーソナルコンピュータなどのクライアントＲ１〜Ｒ３や、網を構成するマルチキャスト対応ルータ１＿１〜１＿８（以下、符号「１」で総称することがある。）マルチキャストルーティングプロトコルＭＲＰによりマルチキャストデータの配信や管理を行うサーバＳ１などから構成される。
また、クライアントＲ１〜Ｒ３は図１に示したようにＬＡＮスイッチ／レイヤ２スイッチに収容されマルチキャストルータ１に接続される形態が、企業においてもインターネットアクセスにおいても一般的であるが、図を簡略化するため示されていない。なお、図示のクライアント管理情報パケットＣＭＰ１〜ＣＭＰ３は図１のパケットＰＫＴ１とＰＫＴ２とでそれぞれ構成されるものである。
実施例［１］
図４は、図３のネットワーク構成例において、本発明の実施例［１］を簡略化して示したものであり、クライアントＲ１からはマルチキャスト参加パケットＰＫＴ１がマルチキャストルータ１に送られ、これに応答してマルチキャストルータ１からはマルチキャスト参加通知パケットＰＫＴ２＿１がサーバＳ１へ送られる様子とサーバＳ１がマルチキャストデータＤＴを送信している様子が示されている。
なお、ＩＧＭＰパケットフォーマットとＩＧＭＰメッセージフィールド、は図２９に示したものであり、ＩＰｖ４ヘッダは図３０に示したものを用いればよい。
また図５には、図２に原理的に示した本発明のネットワーク中継装置であるマルチキャストルータやマルチキャスト対応レイヤ３スイッチなどの実施例構成が示されている。
図中、パケット判別部３＿１〜３＿３（以下、符号「３」で総称することがある。）は、クライアントからのマルチキャスト参加希望メッセージ（ＩＧＭＰ  Ｒｅｐｏｒｔ）や離脱希望メッセージ（ＩＧＭＰ  Ｌｅａｖｅメッセージ）を検出して、既知のマルチキャスト制御を行うマルチキャスト処理部９へ送ると共に、タイマ１０及びクライアント情報保持部１１にも送る。
タイマ１０は、クライアント情報保持部１１並びにパケット生成部４と共に後述する如く、クライアント情報の集約された参加／離脱情報通知メッセージ（パケット）の生成時に使用するものである。
以下、図３及び４を参照して、図５に示したネットワーク中継装置１の動作を説明する。
まず、ネットワーク中継装置１は自己の各インタフェース２，７，８配下に存在するマルチキャストデータの受信クライアントＲ１〜Ｒ３の情報を把握する。具体的には、マルチキャストデータの受信を望むクライアントＲ１〜Ｒ３から送信されるパケットをパケット判別部３で検査し、パケットがＩＧＭＰ参加希望（ｒｅｐｏｒｔ）メッセージを含んでいれば、その受信インタフェース配下に受信クライアントが存在することを認識する。
ＩＧＭＰ参加希望メッセージの識別方法は、まず、▲１▼ＩＰアドレスがマルチキャストアドレスであることと、▲２▼ＩＰヘッダ内の「プロトコル番号」がＩＧＭＰを示す“２”であり、さらに▲３▼ＩＧＭＰメッセージのタイプ値が「Ｏｘ１６」であることを確認する。
ＩＧＭＰ参加希望メッセージ内には、図２９に示したように、受信クライアントＲ１〜Ｒ３が受信を希望するマルチキャストアドレス（グループアドレス）が格納されている。
ネットワーク中継装置１は、このメッセージの送信元のクライアントがマルチキャストデータの受信を望んでいること（マルチキャスト参加希望）をサーバＳ１で管理できるように、パケット生成部４にて宛先アドレス（図３０参照）をサーバＳ１のアドレスとしてマルチキャスト参加通知パケットＰＫＴ２＿１を生成し、サーバＳ１へ向けて転送処理部５が通常のルーティング処理で転送する。
この時、サーバＳ１がこれを受信した場合にマルチキャスト参加通知メッセージであることが識別できるように、ＩＧＭＰメッセージのタイプ値を変更して送信する。
すなわち、標準で決まっているＩＧＭＰメッセージのタイプ値は図２９に示したとおり、バージョン１（ＩＧＭＰｖ１）とバージョン２（ＩＧＭＰｖ２）とバージョン３（ＩＧＭＰｖ３）とがある（ＩＧＭＰｖ３はインターネット技術の標準化団体であるＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）で標準化作業中）が、本発明ではマルチキャスト参加通知メッセージは上記以外のタイプ値を設定して識別するものとする。このタイプ値については後述する。
クライアントＲ１〜Ｒ３がマルチキャストデータＤＴ１〜ＤＴ３の受信を希望することを示すＩＧＭＰ参加希望メッセージは、自分自身が受信したいアドレスへ送信される（検討中のＩＧＭＰｖ３では“２２４．０．０．２２”へ送信される。）が、サーバＳ１でマルチキャストデータＤＴ１〜ＤＴ３の受信クライアントの情報を管理可能とするために、ネットワーク中継装置１においてＩＧＭＰ参加希望メッセージを受信した時、その宛先アドレスフィールドをサーバアドレスで置き換え、サーバＳ１へ送信する。
この時、図２９に示したＩＧＭＰメッセージの「最大応答時間フィールド」は、処理上では不要なため、「０」に設定しておくなどの方法が考えられる。また「チェックサム」はデータの完全性のためにもあらためて計算した値を設定しておくことが望ましい。
グループアドレスにはクライアントが受信を要求しているマルチキャストアドレスＧ１を含めることで、例えば同じクライアントが複数の別のマルチキャストアドレスを受信したい場合などにそれぞれ区別して管理できることになる。
図６には、上記のようにクライアント中継装置１からサーバＳ１へ送られるマルチキャスト参加通知パケットＰＫＴ２＿１のフォーマットが示されており、受信クライアント情報には、マルチキャスト参加を希望するクライアントＲ１のアドレスと参加開始時刻ｔ１が搭載される。
これを受信したサーバＳ１は、メッセージタイプを確認し、参加通知メッセージである場合は、その送信元アドレスフィールド（図３０参照）に格納されているクライアントＲ１のアドレスを、サーバＳ１が送信しているマルチキャストデータのアドレスＧ１及び参加通知パケットの受信時刻ｔ１と関連付けて格納することで、クライアントＲ１が、どのマルチキャストデータ（ここではＧ１）をいつから（ここではｔ１）受信し始めたかを管理することができる。
またこの時、受信クライアントＲ１をそのインタフェースで収容しているネットワーク中継装置１は、マルチキャストアドレスＧ１とサーバＳ１のアドレスを、マルチキャストデータを受信するまで知ることはできない。
そこで、実際の運用では、トラフィック量の少ないダミーのマルチキャストデータを、実際のマルチキャストコンテンツの送信前から流しておくようにすれば、ネットワーク中継装置１はマルチキャストアドレスＧ１とそのサーバＳ１との関係を認識でき、クライアントＲ１からＩＧＭＰ参加希望メッセージを受信した場合に、Ｇ１とＳ１の関係を把握し、情報Ｒ１，Ｇ１をサーバＳ１へ送信することが出来る。
また当然ながら、マルチキャストのセッションはマルチキャストアドレスで区別されるため、Ｇ１以外に、例えばマルチキャストアドレスＧ２に対するＩＧＭＰ参加希望メッセージを受信していたら、Ｇ１とは並列した処理を行うことになる。
図７（ａ）には、上記の動作シーケンスが図示されており、クライアントＲ１からＩＧＭＰ参加希望パケットＰＫＴ１が送信されると（同図（１））、これを受信したマルチキャストルータ１でマルチキャスト参加通知パケットＰＫＴ２＿１を生成し（同図（２））、さらに該パケットＰＫＴ２＿１がマルチキャスト対応ネットワークＭＮＷを経由してサーバＳ１に送信される（同図（３））と、サーバＳ１ではクライアント管理のためのテーブルが作成される（同図（４））。
このときのテーブルの一例が同図（ｂ）に示されている。
実施例［２］
通常、ネットワーク中継装置は、図５に示した如く、複数のインタフェース２，８，７を持ち、図８に示す如く、それぞれにサブネットが接続され、サブネット毎に多数のクライアントが接続されている。対象ネットワークの規模が大きい場合、多くの参加通知メッセージＰＫＴ２がサーバＳ１側に送信されることになり、時間的に分散されていれば良いが、集中した場合にはサーバＳ１に処理負荷が課かる。
そこで、各ネットワーク中継装置１において配下の受信クライアントの情報を集約し、１つのパケットに複数クライアントの情報を含めて一括で送信することが望ましい。
例えば、ネットワーク中継装置１で、マルチキャストアドレスＧ１に対する受信要求制御メッセージ、すなわちＩＧＭＰ参加希望メッセージが受信された時にタイマ１０を動作させる。
このタイマ１０が満了するまでに受信された同じ（マルチキャスト）グループアドレスが対象の全てのＩＧＭＰ参加希望メッセージの情報、すなわち各受信クライアントのソースアドレスを図９のパケットフォーマットに示す如く１つのパケットのクライアント情報に含めてサーバ宛に集約参加通知メッセージＰＫＴ２＿２として送信する。
タイマ値の決定方法は、例えばサーバで、あるいはマルチキャストデータの送信を行っている管理者などが、課金の目的で１分毎に情報を管理したい場合はタイマ値を６０秒とすれば良い。
またこの時、これが通常のＩＧＭＰ参加希望メッセージとは異なり、さらに上記の参加通知メッセージとも異なることを示すため、ＩＧＭＰ参加希望メッセージのタイプフィールドに標準で規定されておらず、上記の参加通知メッセージでもないタイプ値を用いる。
図１０（ａ）には、クライアントＲ１〜Ｒ１とマルチキャストルータ１とサーバＳ１との間の動作シーケンスの概略が図示されている。
クライアントＲ１からのＩＧＭＰ参加希望パケットが送信されると（同図（１））、これを受信したマルチキャストルータ１でタイマ１０が起動され（同図（２））、その後、クライアントＲ３及びＲ２から同様のパケットを受信したとき（同図（３），（４））、タイマ１０が満了したこと（同図（５））を条件として、集約参加通知パケットを生成し（同図（６））、このパケットをサーバＳ１に送信する（同図（７））。サーバＳ１では、これに応じてクライアントの管理テーブルを作成する（同図（８））。
同図（ｂ）には、この時点でサーバＳ１が保持する情報のテーブル例を示す。なお、図示の「ｘｘ」、「ｔｘ」などは、他のマルチキャストやクライアントに関するステータスを持っている状態を示したものである。
実施例［３］
図１１に示す如く、集約参加通知メッセージＰＫＴ２＿２１がサーバＳ１に向けて、或るネットワーク中継装置１＿２から送信されると、サーバ方向の次段のネットワーク中継装置１＿１で受信される。このネットワーク中継装置１＿１はパケットＰＫＴ２＿２１を検査し、それが集約参加通知メッセージであった場合、さらにサーバＳ１方向へ転送する。
この時、ネットワーク中継装置１＿１もネットワーク中継装置１＿２と同じようにローカルインタフェース上に受信クライアントを持っている可能性がある。
仮にネットワーク中継装置１＿１が受信クライアントＲ１１〜Ｒ１４からマルチキャストデータＧ１に関する参加希望メッセージを受信し、情報集約のためにタイマ１０を動作させている状態で、ネットワーク中継装置１＿２からのマルチキャストデータＧ１に関する集約参加通知パケットＰＫＴ２＿２１を受信したら、ネットワーク中継装置１＿２の情報を遅延させてサーバＳ１へ届けることを避けるためにタイマ１０をキャンセルし、これまでネットワーク中継装置１＿１がマルチキャストデータＧ１に対して保持していたローカルの受信クライアントＲ１１〜Ｒ１４の情報を、受信した集約参加通知パケットＰＫＴ２＿２１に加えたパケットＰＫＴ２＿２２を生成し、即座に送信する。
図１２は、ネットワーク中継装置１＿１から送信される集約参加通知パケットＰＫＴ２＿２２のフォーマットを示している。
もし仮に、ネットワーク中継装置１＿１がネットワーク中継装置１＿２からの集約参加通知パケットＰＫＴ２＿２１を受信する前に、ローカルの受信クライアントＲ１１〜Ｒ１４からのＩＧＭＰ参加希望メッセージを受信していなければ、そのままサーバ方向のインタフェースへ転送する。また、これらの動作はマルチキャストアドレス毎にそれぞれ独立して行われる。
図１３（ａ）は、このときのシーケンスを図示しており、ネットワーク中継装置１＿１はクライアントＲ１１からマルチキャスト参加パケットを受信（同図（１））した時点でタイマを起動し（同図（２））、さらにクライアントＲ１２からマルチキャスト参加パケットを受信した後（同図（３））、ネットワーク中継装置１＿２から集約参加通知パケットを受信したときには（同図（４））、タイマを強制終了させ（同図（５））、ネットワーク中継装置１＿２からの集約参加通知パケットＰＫＴ２＿２１にクライアントＲ１１，Ｒ１２の参加情報を加えて即座に送信し（同図（６））、これを受けてサーバＳ１でテーブル作成（同図（７））している。
同図（ｂ）に、この時にサーバＳ１で管理しているテーブル例を示す。
サーバの実施例
図１４に示すように、サーバ側でもユーザ情報パケットであることを検査、識別するパケット判別部２２を持ち、該当する場合はクライアント管理テーブル２３にクライアント情報とステータス、さらには例えば分単位で受信開始時刻を記録する。
これらの情報を元にして、管理アプリケーション２４が、ユーザ数の把握と時間課金計算のための情報を把握することができる。また、ユーザ数が多い場合には、例えば同一のコンテンツを持ったサーバの増設などサーバサイトの設計に対する参考情報とすることができる。
図示の例では、サーバが受信者管理とマルチキャストデータの送信を兼ねる場合を示している。また、通信プロセス２５及びアプリケーション２６は、マルチキャスト伝送制御部２７を駆動して、コンテンツ２８よりマルチキャストデータＤＴを送受信インタフェース２１よりマルチキャスト対応ネットワークへ送出する機能を果たしている。
パケットの変形例
さらに、マルチキャスト参加通知パケットや集約参加通知パケットに関して、図９や１２に示すように、クライアントから受信したＩＧＭＰ参加希望メッセージを、必要な情報の伝達用に流用する方法の他、独自のフォーマットを持つＩＰパケットでも良い。
例えば、図１５に示すように、データリンク層ヘッダ（例えばＭＡＣヘッダ）及びＩＰヘッダに対するペイロード部分にマルチキャストデータアドレス情報を含めてもよい。この時は、それが参加通知パケットや集約参加通知パケットであることを識別する方法があれば良く、例えば、図１６に示すように、ＩＰヘッダのプロトコルＩＤに現在規定されていない値を使用し、これを確認することで識別することができる。
なお、周知（Ｗｅｌｌ−Ｋｎｏｗｎ）のプロトコルＩＤはＩＡＮＡ（Ｉｎｔｅｒｎｅｔ  Ａｓｓｉｇｎｅｄ  Ｎｕｍｂｅｒｓ  Ａｕｔｈｏｒｉｔｙ）あるいはＩＣＡＮＮ（Ｔｈｅ  Ｉｎｔｅｒｎｅｔ  Ｃｏｒｐｏｒａｔｉｏｎ  ｆｏｒ  Ａｓｓｉｇｎｅｄ  Ｎａｍｅｓ  ａｎｄ  Ｎｕｍｂｅｒｓ）が管理しているため、メッセージ用として申請すれば実運用で使用可能である。
実施例［４］
受信クライアントが、マルチキャストデータの受信を中止する場合、通常の離脱希望メッセージ（パケット）、すなわち“ＩＧＭＰ  Ｌｅａｖｅ”を送信する。ＩＧＭＰｖ２では、ＩＧＭＰ離脱希望メッセージが使用され、ＩＧＭＰｖ３では受信を望むマルチキャストアドレスを「空」にしたＩＧＭＰ参加希望メッセージ（ＡＬＬ−ＩＧＭＰｖ３ルータを示す“２２４．０．０．２２”へ送信される。）が使用される。
受信クライアントを管理するためには、これらの「どのクライアンがいつ受信を止めたか」という情報もサーバで管理することとなる。なお、この離脱情報に関しては、上記の参加情報の場合と基本的には同様である。
以下の説明ではＩＧＭＰｖ２の例を示す。
これまでマルチキャストデータを受信していたクライアントが送信する離脱希望メッセージは「Ａｌｌ−Ｒｏｕｔｅｒｓ−Ｇｒｏｕｐアドレス」である、“２２４．０．０．２”へ送信される（なお、ＩＧＭＰｖ３の「受信を望むマルチキャストアドレスを「空」にしたＩＧＭＰ参加希望メッセージ」は“２２４．０．０．２２”へ送信される。）。
これを受信したネットワーク中継装置１は、ＩＧＭＰ離脱希望メッセージであるか否かをパケット判別部３で検査する。ＩＧＭＰ離脱希望メッセージの識別方法は、まず、▲１▼ＩＰアドレスが“２２４．０．０．２”であること、▲２▼ＩＰヘッダ内の「プロトコル番号」がＩＧＭＰを示す“２”であり、さらに▲３▼ＩＧＭＰメッセージのタイプ値が「Ｏｘ１７」であることを確認することである。
ＩＧＭＰ離脱希望メッセージ内には、これと同様に受信クライアントが離脱を希望するマルチキャストアドレスが格納されている。ネットワーク中継装置１は、このメッセージの送信元のクライアントが、これまで受信していたマルチキャストデータの受信を中止したいことをサーバＳ１へ伝えるために、パケット生成部４にて宛先アドレスをサーバＳ１のアドレスとした離脱通知パケットを生成し、転送処理部５がサーバＳ１へ向けて通常のルーティング処理で転送する。
この時、サーバＳ１がこれを受信した場合に離脱通知メッセージであることを識別できるように、ＩＧＭＰメッセージのタイプ値を変更して送信する。このような離脱通知パケットのフォーマット例を図１７に示す。
これを受信したサーバＳ１は、メッセージタイプを確認し、離脱通知パケットである場合には、そのソースアドレスフィールドに格納されているクライアントＲ１のアドレスとサーバＳ１が送信しているマルチキャストデータのアドレスＧ１に関連付けて、離脱通知パケットの受信時刻ｔ２を加えることで、アドレスＲ１を持つクライアントが、どのマルチキャストデータ（ここではＧ１）の受信をいつ中止（ここではｔ２）したかを管理することができる。
さらに、クライアントＲ１に関して、前述のように、サーバＳ１では、クライアントＲ１がマルチキャストアドレスＧ１へ送信していたデータを時刻ｔ１から開始したという情報（すなわち「Ｒ１、Ｇ１、ｔ１」）を保持しており、これと離脱開始時刻ｔ２を関連付けることで、クライアントＲ１が受信していた時間「ｔ２−ｔ１」が算出できる。すなわちクライアントＲ１はマルチキャストデータＧ１を（ｔ２−ｔ１）の間受信していたことを示している。
このように、シーケンスは前述のＩＧＭＰ参加希望メッセージの場合と同じであり、図１８（ａ）において、図７（ａ）と同様に手順（１）〜（４）として示されている。また、サーバＳ１で管理するテーブル例が図１８（ｂ）に示されており、図示のように離脱時刻情報と受信していた時間情報が追加されている。
実施例［５］
当然ながら、ネットワーク中継装置１は図５に示したとおり、複数インタフェース２，７，８を持ち、図８に示したように、それぞれにサブネットが接続され、各サブネット毎に多数のクライアントが接続されている。対象ネットワークの規模が大きい場合、多くの離脱通知メッセージがサーバ側に送信されることになり、集中して送信された場合にはサーバＳ１に処理負荷が課かる可能性がある。
そこで、マルチキャスト参加情報の場合と同様に各ネットワーク中継装置１において、配下の受信クライアントの離脱情報を集約し、１つのパケットに複数クライアントの情報を含めて一括で送信する方法が考えられる。
例えば、ネットワーク中継装置１で、マルチキャストアドレスＧ１に対する離脱メッセージ、すなわちＩＧＭＰ離脱希望メッセージが最初に受信された時にタイマ１０を動作させる。
このタイマ１０が満了までに受信されたすべてのＩＧＭＰ離脱希望メッセージの情報、すなわち各受信クライアントのソースアドレスを図１７のパケットフォーマットに示す如く、１つのパケットのクライアント情報に含めてサーバ宛にマルチキャスト集約離脱通知メッセージとして送信する。
タイマ値の決定方法は、例えばサーバで、あるいはマルチキャストデータの送信を行っている管理者などが、課金の目的で１分毎に情報を管理したい場合はタイマ値を６０秒とすれば良い。タイマ満了後は、再度ＩＧＭＰ離脱希望メッセージを受信した時点でタイマ１０を起動する。
またこの時、これが通常のＩＧＭＰ離脱希望メッセージとは異なり、さらに上記の離脱通知メッセージとも異なることを示すために、ＩＧＭＰ離脱希望メッセージのタイプフィールドに、標準で規定されておらず、前述の参加通知メッセージや集約参加通知メッセージ及び上記の離脱通知メッセージとも異なるＩＧＭＰタイプ値を用いればよい。
さらに、図２９に示したＩＧＭＰメッセージの「最大応答時間フィールド」は、処理上では不要なため、「０」に設定しておくなどの方法が考えられる。また「チェックサム」はデータの完全性のためにも、改めて計算した値を設定しておくことが望ましい。
グループアドレスフィールドにはクライアントが受信中止を要求しているマルチキャストアドレスＧ１を含めることで、例えば同じクライアントが複数の別のマルチキャストアドレスを受信しており、これも受信を中止したい場合などにそれぞれ区別して管理することができる。
図１９に、３つの受信クライアントＲ１〜Ｒ３がほぼ同時にマルチキャストグループＧ１を離脱する場合の情報を含めた集約離脱通知パケットのフォーマット例を示す。
また図２０に、サーバＳ１がこの集約離脱通知パケットを受信したときのクライアント管理テーブル２３を示す。
実施例［６］
ＩＧＭＰ参加希望パケットについて図１１及び図１３に示したように、集約離脱通知メッセージの場合もサーバＳ１に向けて、ネットワーク中継装置１＿２から送信されると、サーバ方向の次段のネットワーク中継装置１＿１に受信される。ネットワーク中継装置１＿１はパケットを検査し、それが集約離脱通知メッセージであった場合、さらにサーバ方向へ転送する。
この時、ネットワーク中継装置１＿１もネットワーク中継装置１＿２と同じようにローカルインタフェース上に受信クライアントを持っている可能性がある。
仮にネットワーク中継装置１＿１が受信クライアントＲ１１〜Ｒ１４からマルチキャストＧ１に関するＩＧＭＰ離脱希望メッセージを受信して、情報集約のためにタイマ１０を動作させている状態で、ネットワーク中継装置１＿２からのマルチキャストデータＧ１に関する集約参加通知パケットを受信したとする。
このときには、ネットワーク中継装置１＿２の情報を遅延させてサーバＳ１へ届けることを避けるためにタイマ１０をキャンセルし、これまでネットワーク中継装置１＿１がマルチキャストデータＧ１に対して保持していたローカルの受信クライアントＲ１１〜Ｒ１４の情報を、受信した集約参加通知パケットに加えて即座に送信する。
もし仮に、ネットワーク中継装置１＿１が同１＿２からの集約参加通知パケットを受信する前に、ローカルの受信クライアントＲ１１〜Ｒ１４からの離脱希望メッセージを受信していなければ、そのままサーバ方向のインタフェースへ転送する。また、これらの動作はマルチキャストアドレス毎にそれぞれ独立して行われる。
これは図１１において、ネットワーク中継装置１＿１がクライアントＲ１１〜Ｒ１４など、直接接続するクライアントから離脱希望メッセージを受信し、情報集約のためにタイマ１０を起動している場合に、ネットワーク中継装置１＿２がサーバ方向へ集約離脱通知パケットを送信し、ネットワーク中継装置１＿１で受信された時点でタイマ１０を停止し、ネットワーク中継装置１＿２からの集約離脱通知パケットにさらにクライアントＲ１１〜Ｒ１４の情報を追加して即座にサーバＳ１へ転送する、という動作になる。
この場合に、ネットワーク中継装置１＿１から送信される集約離脱通知パケットのフォーマット例を図２１に示す。また、この集約離脱通知パケットを受信したときのサーバＳ１のクライアント管理テーブル２３の状態を図２２に示す。
クライアントの識別情報
以上、マルチキャストデータ配信における受信クライアント管理について述べたが、各クライアントの識別はクライアントのＩＰアドレスで行うことが最も利便性が良い。すなわち、ユーザ側から送信されるＩＧＭＰ参加希望パケット、あるいはＩＧＭＰ離脱希望パケットのソース（送信元）アドレスであるＩＰアドレスを使用することができる。
例えば、ダイヤルアップユーザの場合では、ユーザが契約しているＩＳＰ（Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）からユーザ宅内のパーソナルコンピュータにＩＰアドレスが割り当てられるため、これを使用、あるいはＦＴＴＨ（Ｆｉｂｅｒ  ｔｏ  ｔｈｅ  Ｈｏｍｅ）やＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ  Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ）などのブロードバンドアクセスでは、ユーザ宅内の小型ルータ（ＳＯＨＯ（Ｓｍａｌｌ  Ｏｆｆｉｃｅ  Ｈｏｍｅ  Ｏｆｆｉｃｅ）ルータ）の外向きのインタフェースにアドレスが割り当てられるため、これを使用することができる。
ＩＳＰのアドレス割当は、当然ながら課金管理のために「どのユーザにどのＩＰアドレスをいつからいつまで割り当てたか」という情報と共に行われる。したがって、この情報とマルチキャストの受信クライアントのＩＰアドレス情報と受信時間（ｔ２−ｔ１）を結び付ければ、マルチキャストコンテンツの時間課金計算が可能となる。
この時、ユーザ宅内にＳＯＨＯルータがあり、内部に複数の端末が存在しており両方で同じマルチキャストを受信している状態で、一方の端末が離脱メッセージ、すなわちＩＧＭＰ離脱希望メッセージを送信したとすると、ネットワーク中継装置（マルチキャストルータ）はそれを受信し、そのインタフェース配下に未だそのマルチキャストデータを受信したいクライアントが存在するか否かを確認するために、図２８（ｂ）について説明した“ＧＳ−Ｑ（Ｇｒｏｕｐ  Ｓｐｅｃｉｆｉｃ  Ｑｕｅｒｙ）”メッセージを送信する。
これをＳＯＨＯルータ経由で受信したユーザ宅内のもう１台のクライアントは、受信継続の希望を示すために改めて参加希望メッセージを送信するため、また同じアドレス、すなわちＳＯＨＯルータに割り当てられているアドレスは受信クライアントの情報として残ることになり、受信できなくなることは無い。すなわち現在のインターネットアクセスの形態や今後増加すると見られているＡＤＳＬやＦＴＴＨなどのブロードバンドアクセス環境でも問題なく動作する。
管理情報の一括送信
以上、クライアント側が送信するＩＧＭＰ参加／離脱メッセージを基に、クライアントの参加や離脱の情報をサーバへ転送することで受信クライアントを管理する方法及び装置について述べた。
これとは別に、通常、複数のクライアントを収容しているネットワーク中継装置でクライアント情報を保持・蓄積しておき、管理情報が必要となる契機で管理サーバへ一括送信する方法が考えられる。この場合は、サーバ側のクライアント管理の処理負荷を低減できる。
一般的なイントラネット、あるいはインターネットアクセスでのエンドユーザ収容のネットワーク形態では、図１に示したように、各受信クライアントＲ１，Ｒ２はＬＡＮスイッチ／レイヤ２スイッチＳＷ１，ＳＷ２に収容され、さらに上流のネットワーク中継装置（マルチキャスト）に接続されている。
この時、各ネットワーク中継装置が、それぞれのインタフェース配下の受信クライアントの情報と、どのマルチキャストアドレス宛のデータをいつからいつまで受信していたかという情報を、上述した手段で保持する。
すなわち、ＩＧＭＰ参加希望メッセージの受信で、その受信クライアントのＩＰアドレスと、要求しているマルチキャストアドレスＧ１及び参加時刻ｔ１を記録する。
同じ受信クライアントからＩＧＭＰ離脱希望メッセージを受信した場合は、クライアントアドレスの情報に、ＩＧＭＰ離脱希望メッセージを受信した時刻ｔ２を加える。これを各インタフェースで各マルチキャスト毎について行えば、管理に必要な情報を取得できる。
各ネットワーク中継装置が自分自身に接続しているそれぞれのローカルサブネットについて収集した管理情報は、すぐにサーバ方向へ送信するのではなく、例えばマルチキャストセッションが終了した時点などを契機として、ネットワークを構成する事業者、あるいはサービスを提供しているＩＳＰなどの管理サーバに向けて、保持している受信クライアントの情報を一括送信する。
あるいはマルチキャストセッションが終了した時点で、そのマルチキャストに関する情報を送信するなどの方法や、サーバ側からのコマンドにより送信してもよい。
これにより、もしリアルタイムに受信クライアントの情報をサーバ側で把握する必要が無い場合には、マルチキャストデータの送信終了後の或る時点で一括して送信することにより、サーバ側の運用や管理が簡単になる。もちろんこれらの情報は各ユーザ毎の時間課金計算や、受信ユーザ数（視聴率）調査などの目的に利用することができる。
上述したローカルでのユーザ情報保持機能は、図１を参照して、図中のＬＡＮスイッチＳＷ１，ＳＷ２に設けても良いし、マルチキャストルータ１＿１，１＿２に設けても良い。
ＩＧＭＰタイプ値の設定
以上、本発明の一実施例について述べたが、参加通知パケット、集約参加通知パケット、離脱通知パケット、及び集約離脱通知パケットをそれぞれ識別するＩＧＭＰタイプ値については、図２９に示した標準規格で使用されていない値を用いればよく、例えば、
・参加通知パケット：Ｏｘ３１
・集約参加通知パケット：Ｏｘ３２
・離脱通知パケット：Ｏｘ３３
・集約離脱通知パケット：Ｏｘ３４
とすれば良い。
また、本発明はＩＰｖ６マルチキャストにも適用可能であるが、ＩＰｖ４マルチキャストとの主な差違を以下に示す。
（１）マルチキャストＭＡＣアドレスは、１２８ビットＩＰｖ６アドレスの下位３２ビットを４８ビットのＭＡＣアドレス３３：３３：ｘｘ：ｘｘ：ｘｘ：ｘｘへマッピングすることにより生成する。
（２）ＩＰｖ４のＩＧＭＰに相当するＭＬＤは、図２３に示すＩＣＭＰｖ６メッセージ（ＲＦＣ２４６３で規定）を使用し、ＩＣＭＰｖ６のタイプ値「１３０」がＩＧＭＰの問合せ（Ｑｕｅｒｙ）メッセージ、「１３１」が参加希望（Ｒｅｐｏｒｔ）メッセージ、「１３２」がＤｏｎｅ（ＩＧＭＰ離脱希望と同じ）である（図２４参照）。
（３）ＩＰｖ６マルチキャストアドレスはＦＦＯＸ：０：０：０：０：０：０：０で識別される（先頭８ビットが１１１１１１１１）
すなわちこれらを意識して対応することで、本発明の方式はＩＰｖ６環境のマルチキャストにも適用可能である。
実施例［７］
以上の方法により受信クライアントの管理が可能になるが、クライアントのＯＳ障害やメディア再生アプリケーションのハングアップなどで受信ができない場合に、離脱メッセージ、すなわちＩＧＭＰ離脱希望メッセージを送信することができない。この場合、正確なクライアントの離脱管理ができないことになる。これを解決するための実施例を以下に述べる。
通常、マルチキャストルータは、ＩＧＭＰ問合せ（Ｑｕｅｒｙ）メッセージを“Ａｌｌ−Ｓｙｓｔｅｍｓ  Ｇｒｏｕｐ”アドレスである“２２４．０．０．１”へ定期送信（デフォルト１２５秒）しており、受信中の各クライアントはこの問合せメッセージを受信してＩＧＭＰ参加希望メッセージを送信する。
上述したＩＧＭＰ参加希望メッセージはクライアントが、マルチキャストデータの受信を決めた時点で自主的に送信するものである場合が多く、ネットワーク中継装置から定期送信されるＩＧＭＰ問合せメッセージに応答して送信するものではない場合が多いが、定期送信されるＩＧＭＰ問合せメッセージに応答して送信されるＩＧＭＰ参加希望メッセージにより定期的なクライアントの生存監視を行っている。これは通常の標準で規定された動作である。
もし仮に或る受信クライアントがＯＳ障害やメディア再生アプリケーションのハングアップなどで受信ができない場合には、ネットワーク中継装置から定期送信されるＩＧＭＰ問合せメッセージに応答しなくなり、ＩＧＭＰ参加希望メッセージを送信しなくなる。
ネットワーク中継装置では、ＩＧＭＰ問合せメッセージに応答しなくなった受信クライアントを受信停止と見なし、自己のクライアント管理テーブルに離脱時間を記入し、ステータスを「受信停止／エラー」と記述し、そのクライアント用の離脱通知メッセージを生成してサーバＳ１へ送信することで、このような障害に対応したクライアント管理が可能となる。
この場合には、クライアントが、マルチキャストデータの受信を決めた時点で自発的に送信するＩＧＭＰ参加希望メッセージで情報が書き込まれる場合が多いことは上述したとおりであるが、定期送信されるＩＧＭＰ問合せメッセージに応答したＩＧＭＰ参加希望メッセージの受信を待って生存確認を行うという動作になる。
もし正確に１分単位でクライアント管理を行う場合は、定期送信される問合せメッセージのタイマをデフォルトの１２５秒から６０秒に設定して運用すればよい。１０分単位などの場合はデフォルト値で十分である。
もしクライアントが受信を開始した場合には、その開始時刻と、その後の離脱時刻も管理テーブルに反映すればよい。
また、ネットワーク中継装置で管理テーブルを保持しておく場合には、情報をネットワーク中継装置の管理テーブルに反映しておき、ある契機でサーバへ一括送信すれば良い。
あるいは、別の手段として、各受信クライアントの生存確認をＰｉｎｇにより行う方法などもある。
この概要が図２５に示されている。
すなわち、同図（ａ）は３つのフェーズＰＳ１〜ＰＳ３に分けることができ、フェーズＰＳ１では、グループ参加を行うため、クライアントＲ１はＩＧＭＰ参加希望パケットを送信し（同図（１））、マルチキャストルータ１は、参加通知パケットを生成する（同図（２））とともに該パケットをマルチキャスト対応ネットワークＭＮＷを経由してサーバＳ１へ送信する（同図（３））。サーバＳ１は、これよりクライアント管理テーブル２３を作成する（同図（４））。
フェーズＰＳ２は障害検出フェーズを示し、マルチキャストルータ１が定期的に問合せメッセージを送信している場合（同図（５））、クライアントＲ１が障害状態にあると仮定すれば、クライアントＲ１はその問合せに対してＩＧＭＰ参加希望パケットは送信できない（同図（６））。
これにより、マルチキャストルータ１はクライアントＲ１が障害状態にあることを検出し、自己のクライアント管理テーブルにその旨記入する（同図（７））。そして、マルチキャストルータ１はクライアントＲ１に関する離脱通知パケットを生成し（同図（８））、サーバＳ１へ送信する（同図（９））。サーバＳ１では、クライアントＲ１に関する管理情報を更新する（同図（１０））。
フェーズＰＳ３は受信再開フェーズを示し、障害が復旧した後、クライアントＲ１はＩＧＭＰ参加希望パケットを送信し（同図（１１））、これに応答してマルチキャストルータ１は参加通知パケットを生成して（同図（１２））、サーバＳ１へ送信する（同図（１３））。サーバＳ１ではクライアント管理テーブルを更新する（同図（１４））。
この結果、サーバＳ１におけるクライアント管理テーブル２３内のクライアントＲ１に関する情報は受信を再開した時間ｔ３の情報も含めて同図（ｂ）に示すようになる。
時間課金サービス
以上、受信クライアントのサーバでの管理方式について述べたが、この仕組みを使用して新たなサービスを提供することができる。
既に述べたように、マルチキャストによる音声、画像などのデータ配信では、どのような受信クライアントが存在し、或る時点で総計いくつの受信クライアントが存在し、あるいは統計でいくつの受信クライアントがマルチキャストデータを受信していたか、というような情報が把握できなかった。
これはマルチキャストの仕組みに元々そのような概念が無いことと、データ送信にＵＤＰパケットを使用するためであり、このような背景が、同時に多くの利点も持つマルチキャストの普及を妨げている。
そこで、本発明の提供するネットワーク中継装方法及び装置により、従来では不可能であったマルチキャストデータ配信におけるユーザ管理サービスや、受信クライアント毎のコンテンツ利用の時間課金サービスが提供できる。
現在の（ユニキャストによる）有料コンテンツ配信のサービス形態は、主に以下の２つが提供されている。一方は一定料金でサービス利用の権利を購入する形態で、他方が従量課金形態である。また、これらはすべてユニキャストであり、配信形態はオンデマンドあるいはリアルタイム中継である。
この時、特にリアルタイム中継に関しては、設備投資を抑制できる点でマルチキャストが有効であることは既に述べたが、ユーザ自体の管理ができないためにサービスを提供するとすればコンテンツアクセスの権利を購入するという方法以外になかった。しかもマルチキャストはオンデマンドでは無くリアルタイムコンテンツ配信であるため、受信可能な時間に必ずアクセスする必要があった。
しかし、本発明により受信クライアント管理を行えば、コンテンツにアクセスしていた時間に応じた課金が可能であり、事業者はサービスの提供が非常にし易くなる。
また、ユーザ側にとっても、仮にコンテンツの放送時間にアクセスすることができなければ無課金、あるいは、コンテンツ放送中の一定時間だけコンテンツにアクセスして配信される番組を利用した場合に、その時間分だけの課金となり、ユーザ側にとってもメリットのあるサービスが提供可能となる。
このサービス提供形態例が図２６及び図２７に示されている。
図２６の例では、ＩＳＰ／ＮＳＰなどのサーバサイトＳＴには、クライアント管理／認証サーバＳ１１と課金サーバＳＲとマルチキャストコンテンツ配信／クライアント管理サーバＳ１３とが設けられており、サーバＳ１３がクライアント２０等のマルチキャスト参加／離脱情報を、サーバＳ１１でクライアント管理／認証することにより、クライアント収容スイッチＳＷ及びマルチキャスト対応ルータ１＿１〜１＿５等を経由して収集する。
そして、図２７に示すように、インターネット接続／コンテンツ配信事業者３０は、通常のインターネット接続サービス３２をクライアント２０に提供▲２▼してインターネット接続料金▲３▼をクライアント（ユーザ）に課金するとともに、インターネット接続／コンテンツ配信事業者３０がさらなる付加価値サービスとして、クライアント２０にコンテンツ配信サービスを提供▲１▼する際に、マルチキャストを使用した従量課金によるマルチキャストコンテンツ配信サービスＤＳを提供することができる。
すなわち、クライアント２０の番組受信時間に基づいて課金するコンテンツ配信サービスＤＳを提供することができ、インターネット接続／コンテンツ配信事業者３０はクライアント２０の番組聴取時間に基づいて、クライアント２０に対して番組聴取料金を課金・請求する。
以上のとおり、本発明によれば、現在のユニキャスト通信と同様に、従来不可能であったマルチキャストによるデータ配信における受信ユーザ管理を可能とすることでマルチキャスト通信における信頼性を提供でき、マルチキャスト対応ネットワーク機器やエンドシステム、マルチキャスト対応アプリケーションの普及に寄与するものである。
また本発明によれば、マルチキャスト環境でのユーザ管理機能を提供することにより、ある時点での受信クライアント数やトータルの受信者数などの把握、管理を可能とし、マルチキャストによるコンテンツ配信サービスやインターネットリアルタイム放送の普及に寄与するものである。
さらに、本発明により、マルチキャスト配信でありながらユーザ管理を提供することにより、従来不可能であったマルチキャストコンテンツ配信における時間課金サービスを提供することができ、コンテンツ配信ビジネスの普及や、さらにはコンテンツ受信の目的でのブロードバンドネットワークの普及にも貢献するものである。
【図１】
2004043019.tif 000003
【図２】
2004043019.tif 000004
【図３】
2004043019.tif 000005
【図４】
2004043019.tif 000006
【図５】
2004043019.tif 000007
【図６】
2004043019.tif 000008
【図７】
2004043019.tif 000009
【図８】
2004043019.tif 000010
【図９】
2004043019.tif 000011
【図１０】
2004043019.tif 000012
【図１１】
2004043019.tif 000013
【図１２】
2004043019.tif 000014
【図１３】
2004043019.tif 000015
【図１４】
2004043019.tif 000016
【図１５】
2004043019.tif 000017
【図１６】
2004043019.tif 000018
【図１７】
2004043019.tif 000019
【図１８】
2004043019.tif 000020
【図１９】
2004043019.tif 000021
【図２０】
2004043019.tif 000022
【図２１】
2004043019.tif 000023
【図２２】
2004043019.tif 000024
【図２３】
2004043019.tif 000025
【図２４】
2004043019.tif 000026
【図２５】
2004043019.tif 000027
【図２６】
2004043019.tif 000028
【図２７】
2004043019.tif 000029
【図２８】
2004043019.tif 000030
【図２９】
2004043019.tif 000031
【図３０】
2004043019.tif 000032
【図３１】
2004043019.tif 000033
【国際調査報告】
2004043019.tif 000034
2004043019.tif 000035
2004043019.tif 000036
2004043019.tif 000037