(57)【要約】【課題】  ＩＰマルチキャスト転送システムにおいて使用されるＩＰマルチキャスト転送装置およびＩＰマルチキャスト通信情報管理装置を提供する。【解決手段】  マルチキャスト通信情報管理装置１（ＶＬＭ）とマルチキャスト転送装置２（ＶＬＲ）と通信装置３とから成るシステムによってインターネット上でのマルチキャスト通信を実現するものであり、ＶＬＲ２はその配下の通信装置３を管理するＶＬＲ管理領域を構成し、そのＶＬＲ管理領域内部で一意なＩＰマルチキャストアドレスを用いて、通信装置３へ送信する一方、ＶＬＭ１は、そのＶＬＭ１が管理するグループ通信（ＶＭＣセッション）に参加するＶＬＲ２を管理するＶＬＭ管理領域を構成し、同じＶＭＣセッションに参加するＶＬＲ２に他のＶＬＲ２との通信に必要な情報を通知することで、ＶＬＲ間でのＶＭＣセッションのデータの転送を可能とする。【選択図】  図１
2005094608.tif 000002
【特許請求の範囲】
【請求項１】
１以上の配下の通信装置をネットワークに接続し、これらの通信装置を管理する通信装置管理領域を形成し、かつ、グループ通信（以下、「ＶＭＣセッション」という）のチャネルを管理するチャネル管理装置とネットワークを介して接続するとともに、他の通信装置管理領域を管理する装置との間でＩＰマルチキャスト対応またはＩＰマルチキャスト非対応のネットワークを介してＶＭＣセッションのデータを送受信し、上記配下の通信装置に対し、通信装置管理領域内部で一意なＩＰマルチキャストアドレスに従いＶＭＣセッションのデータを送信することを特徴とするＩＰマルチキャスト転送装置。
【請求項２】
上記ＶＭＣセッションに関する情報を記憶するＶＭＣ情報記憶部を備え、上記配下の通信装置から、特定のＶＭＣセッションへの参加要求とＶＭＣセッションを特定する情報であるＶＭＣ−ＩＤとが送信されると、上記ＶＭＣセッションのデータを上記通信装置に送信するために使用するＩＰマルチキャストアドレスを選択し、上記ＶＭＣ−ＩＤと上記ＩＰマルチキャストアドレスとを対応づけて上記ＶＭＣ情報記憶部に格納し、上記ＶＭＣセッションを管理するチャネル管理装置に対し、上記ＶＭＣセッションへの参加を要求し、この要求を受けた上記チャネル管理装置から上記ＶＭＣセッションへ参加している他のＩＰマルチキャスト転送装置に関する情報の送信を受け、この情報を上記ＶＭＣ−ＩＤと対応づけて上記ＶＭＣ情報記憶部に格納する一方、配下の通信装置からＶＭＣセッションのデータが送信されてきた場合、上記ＶＭＣ情報記憶部から、上記データの宛先であるＩＰマルチキャストアドレスに基づいてＶＭＣ−ＩＤを抽出し、かつ、このＶＭＣ−ＩＤで特定されるＶＭＣセッションに参加している他のＩＰマルチキャスト転送装置に関する情報を抽出するとともに、上記データを、ＶＭＣ−ＩＤを付加して上記他のＩＰマルチキャスト転送装置に転送する一方、他のＩＰマルチキャスト転送装置からＶＭＣセッションのデータを受信すると、このデータからＶＭＣ−ＩＤを取り出し、このＶＭＣ−ＩＤに対応するＩＰマルチキャストアドレスを上記ＶＭＣ情報記憶部から抽出し、上記受信したデータにそのＩＰマルチキャストアドレスを付加して配下の通信装置へ送信することを特徴とする請求項１記載のＩＰマルチキャスト転送装置。
【請求項３】
通信回線を介してネットワーク上のネットワーク中継器と接続し、ＩＰマルチキャスト通信を利用したグループ通信（以下、「ＶＭＣセッション」という）のチャネルを管理し、そのＶＭＣセッションに参加する通信装置をネットワークに接続させるネットワーク中継器を管理するＩＰマルチキャスト通信情報管理装置において、ＶＭＣセッションと対応づけてネットワーク中継器に関する情報を記憶する記憶部を備え、ネットワーク中継器からのＶＭＣセッションへの参加要求を受けると、このＶＭＣセッションへの参加を要求してきたネットワーク中継器の情報を上記ＶＭＣセッションを特定するチャネル識別子と対応付けて上記記憶部に記憶させ、かつ、上記ネットワーク中継器の情報を、上記ＶＭＣセッションへ参加しているすべてのネットワーク中継器へ送信する一方、いずれかのネットワーク中継器から、ＶＭＣセッションからの脱退要求を受けると、このネットワーク中継器に関する情報を上記記憶部から削除するとともに、このＶＭＣセッションに参加するすべてのネットワーク中継器にその更新された上記記憶部の内容を送信することを特徴とするＩＰマルチキャスト通信情報管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ＩＰマルチキャスト転送システムにおいて使用されるＩＰマルチキャスト転送装置およびＩＰマルチキャスト通信情報管理装置の提供に関する。
【背景技術】
【０００２】
マルチキャスト通信とは、ネットワークに接続された通信装置のうち、一部の通信装置のグループに対してデータを一斉送信する手法である。このマルチキャスト通信は、必要とする通信装置に対してのみデータ送信を行うため、効率のよい通信手法である。そこで、かかるマルチキャスト通信を自由に行えることが要望されている。
【０００３】
ところで、インターネット上でマルチキャスト通信を実現する手段としてＩＰマルチキャストがある。このＩＰマルチキャストでは、ＩＰマルチキャストアドレスを利用して通信を行う。ＩＰマルチキャストアドレスとは、ＩＰアドレスのうちあらかじめマルチキャスト用に用意された特別のアドレスのことである。ＩＰマルチキャストでは、このＩＰマルチキャストアドレスをデータ受信を望む複数の通信装置からなるグループの識別子とし、これを宛先としてデータを送信することによりマルチキャスト通信を実現する。
つまり、ＩＰマルチキャストを利用して通信を行う場合、あらかじめＩＰマルチキャストアドレスを決定しておかなくてはならない。ＩＰマルチキャストアドレスの決定に際し、ＩＰマルチキャスト通信が伝搬するネットワーク内で、他のＩＰマルチキャストアドレスと重複することがあってはならない。
【０００４】
従来、ＩＰマルチキャスト通信において利用するＩＰマルチキャストアドレスは、送信者が任意に選択するか、または、ＩＰマルチキャストアドレスを管理する管理者に問い合わせることによって決定されていた。
しかし、このようなＩＰマルチキャストアドレスの管理法では、送信者がＩＰマルチキャストアドレスを任意に選択する場合、そのＩＰマルチキャストアドレスが重複することがあり、ネットワーク内での一意性が確保できず、正常にＩＰマルチキャストを利用した通信が行えない場合があった。
また、ＩＰマルチキャストアドレスを管理する管理者により決定してもらう場合、そのＩＰマルチキャストアドレスの決定に時間がかかりすぎるという問題があった。
【０００５】
このような不都合に対し、ＩＰマルチキャストアドレスを重複無く自動的に決定する仕組みが、いくつか考案されている。特開２０００−２４４４８８号公報に開示されたマルチキャストセッション管理装置の発明もその１つである。このマルチキャストセッション管理装置は、マルチキャスト通信の送信者からのデータをユニキャストで受信し、そのデータを送信者に代わってＩＰマルチキャスト送信をする。そして、マルチキャストセッション管理装置が、使用可能なマルチキャストアドレスを一元管理することにより、マルチキャストアドレスの重複使用を防止している。
【０００６】
しかし、マルチキャストセッション管理装置は、下流の装置に対し、ＩＰマルチキャストを利用して送信するので、送信経路上に、ＩＰマルチキャストに非対応のネットワーク中継器あれば、そこで通信が切断されてしまう。
また、グループ通信への参加者が多くなったりすると、複数のマルチキャストセッション管理装置を設け、送信者からのデータを分散して受信することがある。
しかし、複数のマルチキャストセッション管理装置を設けた場合、各装置が利用するＩＰマルチキャストアドレスが重複していたのでは、同一の参加者に対し、複数の装置から同一内容のデータが送信されてしまう。それでは、負荷の軽減のために複数装置を設けた意味がない。そのため、複数のマルチキャストセッション管理装置を設ける場合は、各装置が、互いにＩＰマルチキャストアドレスの管理情報を通知し、重複したＩＰマルチキャストアドレスを使用しないようにしている。
【特許文献１】特開２０００−２４４４８８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
以上のように、ＩＰマルチキャストアドレスを管理する手法は、いくつか考案されているとはいえ、いずれも小規模ネットワークでの利用を想定している。
例えば、上記した従来のマルチキャストセッション管理装置も、参加者が少ないときは、ＩＰマルチキャストアドレスを一元管理ができるとはいえ、複数の装置を設けるときは、各装置は、他の装置が使用するＩＰマルチキャストアドレスと重複しないようにしなければならない。つまり、規模の大きなネットワーク上に、上記マルチキャストセッション管理装置を設置しようとしても、ＩＰマルチキャストアドレスの管理という困難な問題から解放されたことにはならない。
このように、大規模なネットワークで、これらの手法を利用することはきわめて困難である。依然として、ＩＰマルチキャスト通信が転送されるすべての組織間で、どのＩＰマルチキャストアドレスがどのＩＰマルチキャスト通信で利用されているのかについて、あらかじめ情報を共有していなければならないからである。
【０００８】
かかる情報の共有のために、ＩＰマルチキャストアドレスを集中管理する組織を編成し、ここで一元的にＩＰマルチキャストアドレスを管理することが行われている。しかし、集中的に管理する場合、ＩＰアドレスという膨大な量の情報を管理する必要があるため、ＩＰマルチキャストアドレスの利用を申請してから承諾されるまでには、およそ数日の期間を要するというのが現状である。
【０００９】
ところで、マルチキャスト通信が自由に行えることへの要望が高まっているとはいえ、特に要望が高いマルチキャスト通信は、いわば「泡沫的マルチキャスト通信」とでもいうべきものである。つまり、各個人が寄り集まり、自由に情報を共有し、比較的短い期間で解散するというグループにおいて利用されるマルチキャスト通信である。
このような泡沫的マルチキャスト通信にとって、申請が承諾されるまで数日も要するのではあまりにも不便である。例えば、特定のテーマについて緊急に幅広く意見を募るためにグループ通信を利用しようとする場合、申請が承諾された時点では、もはやマルチキャストで通信を行う意義が消滅したということさえ考えられる。
【００１０】
この発明の根底には、ＩＰマルチキャストアドレスはＩＰマルチキャスト通信が伝搬しうるネットワーク内で一意性を確保しなければならない点に上記問題の原因があるという認識がある。そこで、ネットワーク全体でのＩＰマルチキャストアドレスの管理を容易にすることを第１の解決すべき課題と考えた。
【００１１】
さらに、ＩＰマルチキャスト通信には次のような問題もある。すなわち、現在のインターネットを構成するすべてのネットワーク中継器（以下、「ルータ」という）がＩＰマルチキャストに対応しているわけではない、という問題である。たとえば、スイッチングハブのような中継機器は、ＭＡＣアドレスをチェックして送信するので、ＩＰマルチキャストに対応できない。このようなＩＰマルチキャストに非対応のルータが通信経路上に存在すると、そのマルチキャストのパケットは無視され、マルチキャストの通信が切断されてしまう。
上記した従来のマルチキャストセッション管理装置も、この問題を抱えている。大規模なネットワークでこの装置を実用化しようとすると、通信経路にあるルータをすべてＩＰマルチキャスト対応のものに取り替えなければならなくなる。
【００１２】
ＩＰマルチキャストに対応していないネットワークを越えてＩＰマルチキャスト通信を実現する手法として、トンネリング技術が提案されてはいる。しかし、既存のトンネリング技術では、ＩＰマルチキャストアドレスの一意性の要件が前提とされている。したがって、トンネリング技術は、ＩＰマルチキャストアドレスの管理に伴う種々の困難を何ら軽減するものではない。
そこで、この発明は、ＩＰマルチキャストに対応していないルータが通信経路上に存在している場合でも、ＩＰマルチキャスト通信の利点を取り入れたグループ通信を可能にすることを、第２の解決すべき課題と考えた。
【課題を解決するための手段】
【００１３】
第１の発明は、１以上の配下の通信装置をネットワークに接続し、これらの通信装置を管理する通信装置管理領域を形成し、かつ、グループ通信（以下、「ＶＭＣセッション」という）のチャネルを管理するチャネル管理装置とネットワークを介して接続するとともに、他の通信装置管理領域を管理する装置との間でＩＰマルチキャスト対応またはＩＰマルチキャスト非対応のネットワークを介してＶＭＣセッションのデータを送受信し、上記配下の通信装置に対し、通信装置管理領域内部で一意なＩＰマルチキャストアドレスに従いＶＭＣセッションのデータを送信することを特徴とする。
【００１４】
第２の発明は、第１の発明において、上記ＶＭＣセッションに関する情報を記憶するＶＭＣ情報記憶部を備え、上記配下の通信装置から、特定のＶＭＣセッションへの参加要求とＶＭＣセッションを特定する情報であるＶＭＣ−ＩＤとが送信されると、上記ＶＭＣセッションのデータを上記通信装置に送信するために使用するＩＰマルチキャストアドレスを選択し、上記ＶＭＣ−ＩＤと上記ＩＰマルチキャストアドレスとを対応づけて上記ＶＭＣ情報記憶部に格納し、上記ＶＭＣセッションを管理するチャネル管理装置に対し、上記ＶＭＣセッションへの参加を要求し、この要求を受けた上記チャネル管理装置から上記ＶＭＣセッションへ参加している他のＩＰマルチキャスト転送装置に関する情報の送信を受け、この情報を上記ＶＭＣ−ＩＤと対応づけて上記ＶＭＣ情報記憶部に格納する一方、配下の通信装置からＶＭＣセッションのデータが送信されてきた場合、上記ＶＭＣ情報記憶部から、上記データの宛先であるＩＰマルチキャストアドレスに基づいてＶＭＣ−ＩＤを抽出し、かつ、このＶＭＣ−ＩＤで特定されるＶＭＣセッションに参加している他のＩＰマルチキャスト転送装置に関する情報を抽出するとともに、上記データを、ＶＭＣ−ＩＤを付加して上記他のＩＰマルチキャスト転送装置に転送する一方、他のＩＰマルチキャスト転送装置からＶＭＣセッションのデータを受信すると、このデータからＶＭＣ−ＩＤを取り出し、このＶＭＣ−ＩＤに対応するＩＰマルチキャストアドレスを上記ＶＭＣ情報記憶部から抽出し、上記受信したデータにそのＩＰマルチキャストアドレスを付加して配下の通信装置へ送信することを特徴とする。
【００１５】
第３の発明は、通信回線を介してネットワーク上のネットワーク中継器と接続し、ＩＰマルチキャスト通信を利用したグループ通信（以下、「ＶＭＣセッション」という）のチャネルを管理し、そのＶＭＣセッションに参加する通信装置をネットワークに接続させるネットワーク中継器を管理するＩＰマルチキャスト通信情報管理装置において、ＶＭＣセッションと対応づけてネットワーク中継器に関する情報を記憶する記憶部を備え、ネットワーク中継器からのＶＭＣセッションへの参加要求を受けると、このＶＭＣセッションへの参加を要求してきたネットワーク中継器の情報を、上記ＶＭＣセッションを特定するチャネル識別子と対応付けて上記記憶部に記憶させ、かつ、上記ネットワーク中継器の情報を、上記ＶＭＣセッションへ参加しているすべてのネットワーク中継器へ送信する一方、いずれかのネットワーク中継器から、ＶＭＣセッションからの脱退要求を受けると、このネットワーク中継器に関する情報を上記記憶部から削除するとともに、このＶＭＣセッションに参加するすべてのネットワーク中継器にその更新された上記記憶部の内容を送信することを特徴とする。
【発明の効果】
【００１６】
第１の発明によれば、マルチキャスト通信への参加者とそれを管理するＩＰマルチキャスト転送装置との間でだけＩＰマルチキャストアドレスの一意性が保たれればよいので、同じＶＭＣセッションに参加する全員に同一のＩＰマルチキャストアドレスを割り当てる必要がなくなった。したがって個々のＩＰマルチキャスト転送装置が、自己の配下にある通信装置を管理する通信装置管理領域の中だけでＩＰマルチキャストアドレスの管理を行えばよいので、一意性の確保が容易となり、ＩＰマルチキャストアドレスを迅速に決定できる。
さらに、ＩＰマルチキャスト転送装置間に、ＩＰマルチキャスト非対応のルータが存在してもＶＭＣセッションのアプリケーションデータを転送できるので、ルータをＩＰマルチキャスト対応のものに取り替えることなく、この発明のＩＰマルチキャスト転送装置を実際の運用に供することができる。
【００１７】
第２の発明によれば、ＩＰマルチキャスト転送装置相互間で共有しているＶＭＣ−ＩＤに基づいて、各ＩＰマルチキャスト転送装置は、自己の通信装置管理領域内部で使用するＩＰマルチキャストアドレスを取り出すことができる。そのため、他の通信装置管理領域内部でどのようなＩＰマルチキャストアドレスが使用されているかを知っている必要がない。
【００１８】
第３の発明によれば、ＩＰマルチキャスト通信情報管理装置がＶＭＣセッションに参加しているすべてのＩＰマルチキャスト転送装置に関する情報を管理し、各ＩＰマルチキャスト転送装置に他のＩＰマルチキャスト転送装置に関する情報を通知している。この情報には、ＩＰマルチキャスト転送装置間での通信に必要な情報が含まれているので、ＩＰマルチキャスト転送装置はＶＭＣセッションのアプリケーションデータを、この情報に基づいて他ＩＰマルチキャスト転送装置へ転送すればよい。したがって、ＩＰマルチキャストに対応していないネットワーク中継器がＩＰマルチキャスト転送装置間に存在しても、ＶＭＣセッションのアプリケーションデータの送受信が実現できる。
【発明を実施するための最良の形態】
【００１９】
図１は、この発明によって実現される、ＶＭＣセッション、すなわちＩＰマルチキャストを利用したグループ通信の実施形態を示した図である。
このグループは、ＩＰマルチキャスト通信情報管理装置（以下「ＶＬＭ」という）１とＩＰマルチキャスト転送装置（以下「ＶＬＲ」という）２と各ＶＬＲ２の配下にある通信装置３から構成され、ＶＬＭ１とＶＬＲ２とはインターネットＮを介して接続されている。
なお、以下、表現の便宜のため、通信装置３を「端末３」あるいは「参加者端末３」ということがある。
【００２０】
ＶＭＣセッションを実現するシステム全体は、ＶＬＭ１がＶＬＲ２を管理する領域と、ＶＬＲ２がその配下の端末３を管理する通信装置管理領域とから構成される。以下、前者をＶＬＭ管理領域Ａ、後者をＶＬＲ管理領域Ｂという。
【００２１】
このようなシステムの構成は、任意のＶＭＣセッションごとに生成される。そして、任意のＶＭＣセッションを識別子であるＶＭＣ−ＩＤによって他のＶＭＣセッションと識別する。
【００２２】
図２にこのＶＭＣ−ＩＤの内容を示す。ＶＭＣ−ＩＤは、ＶＬＭ識別子とチャネル識別子とを組み合せたものである。
ＶＬＭ識別子とは、ＶＬＭ１を特定する情報である。このＶＬＭ識別子として、たとえば、ＶＬＭ１のＵＲＬあるいはグローバルＩＰアドレスを用いることができる。
チャネル識別子とは、チャネル、すなわち特定のＶＭＣセッションを特定する情報である。放送局をその使用する周波数で区別し、１チャネルとか、３チャネルとかというが、この場合のチャネルと同意義である。つまり、テレビ受像機の特定のチャネルを選択すると、そのチャネルを選択した視聴者だけに、一斉に同一内容が放送される。この実施形態のシステムを利用したＩＰマルチキャスト通信も、これと同様であり、特定のチャネルを端末３から選択した者だけに、同一ＶＭＣセッションのアプリケーションデータが一斉に送られてくる。
【００２３】
図２には、ＶＬＭ識別子が“ｖｌｍ．ｊａｉｓｔ．ａｃ．ｊｐ”であり、チャネル識別子が“ｃｈａｔ１”の場合が例示されている。この例では、ＶＭＣ−ＩＤは“ｖｌｍ．ｊａｉｓｔ．ａｃ．ｊｐ／ｃｈａｔ１”になり、当該ＶＭＣセッションを他のＶＭＣセッションと識別する情報となる。
上記のチャネル識別子は、当該ＶＭＣセッションを制御管理しているＶＬＭ１の内部で管理されている。そのため、ＶＬＭ識別子とチャネル識別子との組合せであるＶＭＣ−ＩＤを特定すればインターネットの広大な領域の中から特定のＶＭＣセッションを識別できる。つまり、ＶＭＣ−ＩＤのＶＬＭ識別子を表す部分から当該ＶＭＣセッションを管理しているのはどのＶＬＭ１であるかがわかる。当該ＶＬＭ１は、ＶＭＣ−ＩＤからチャネル識別子を取り出し、そのチャネル識別子から、どのＶＭＣセッションへの参加要求であるかを認識する。
【００２４】
上記のＶＭＣ−ＩＤによって識別されるＶＭＣセッションは、ＶＬＭ１と当該ＶＭＣセッションに参加する参加者端末群と、参加者端末３を管理するＶＬＲ群とから構成される。そして、ＶＬＭ管理領域Ａでは、ＶＬＭ１が、ＶＭＣ−ＩＤで特定されるＶＭＣセッションに参加している全ＶＬＲ２の情報を管理している。しかし、この領域では、参加者端末３の管理を行っていない。参加者端末３の管理は、ＶＬＭ管理領域Ａとは独立した領域であるＶＬＲ管理領域Ｂの内部で行われているからである。
【００２５】
ＶＬＲ管理領域Ｂでは、ＶＬＭ１により管理されている各ＶＬＲ２が、当該ＶＬＲ２にＶＭＣセッションへの参加を要求してきたすべての端末３の情報を管理している。このように、ひとつのＶＭＣ−ＩＤで識別される任意のＶＭＣセッションは、ＶＬＭ管理領域ＡとＶＬＲ管理領域Ｂとの２段階の構成からなるシステムによって実現される。
【００２６】
ＶＬＲ管理領域Ｂの内部では、当該ＶＭＣセッションの内容であるアプリケーションデータは、ＶＬＲ２とその配下の参加者端末３との間では、ＶＬＲ−端末間通信により共有される。そして、このＶＬＲ−端末間通信は、ＩＰマルチキャスト通信の手法を利用して行われる。そのため、参加者端末３の台数分だけデータを複製し、各端末３へデータを送信する必要がないので、効率のよい通信が実現できる。
【００２７】
一方、このアプリケーションデータは、当該ＶＭＣセッションに参加する他のＶＬＲ２との間では、ＶＬＲ間通信により共有される。このようなＶＬＲ間通信が可能になるのは、ＶＬＭ管理領域Ａの内部で、同じＶＭＣセッションに参加する他のＶＬＲ２の情報が、ＶＬＭ１によって、各ＶＬＲ２に通知され、その情報を各ＶＬＲ２が記憶しているからである。
なお、ＶＬＲ−端末間通信の通信手法はマルチキャスト通信であるが、ＶＬＲ間通信の手法は必ずしもマルチキャスト通信でなくてもよい。この実施形態では、ユニキャスト通信の利用を想定している。ＶＬＲ２自体は、ＩＰマルチキャストに対応したルータであるが、ＶＬＲ２間の通信経路上に存在するルータのすべてがＩＰマルチキャスト対応とは限らないからである。
【００２８】
次に、ＶＬＭ１とＶＬＲ２がそれぞれどのように構成されているかを、図３に従い説明する。
ＶＬＭ１は、ＶＬＭチャネル情報記憶部４と、ＶＬＭチャネル参加脱退要求受信部５と、ＶＬＭチャネル情報管理部６と、ＶＬＭチャネル情報送信部７とを備えている。
【００２９】
ＶＬＭチャネル情報記憶部４には、図４に示すように、当該ＶＬＭ１が管理しているすべてのチャネル識別子と、そのチャネル識別子で特定されるＶＭＣセッションへ参加しているすべてのＶＬＲ２の情報とが記憶されている。なお、このＶＬＭチャネル情報記憶部４には、端末３に関する情報は記憶されていない。ＶＬＭチャネル情報記憶部４は、ＶＬＭ１が参加ＶＬＲ２を管理するＶＬＭ管理領域Ａのためにあるからである。
【００３０】
ＶＬＭチャネル参加脱退要求受信部５は、ＶＬＲ２から当該ＶＬＭ１が管理するＶＭＣセッションへの参加または脱退を要求する信号が送信されたきた場合、この信号を受信する。
ＶＬＭチャネル情報管理部６は、ＶＬＭチャネル参加脱退要求受信部５で受信した参加要求信号を基に、ＶＬＭチャネル情報記憶部４内の当該ＶＭＣセッションに対応する内容を更新する。
ＶＬＭ情報送信部７は、この更新されたＶＬＭチャネル情報記憶部４の情報をＶＬＲ２に対し通知する。
【００３１】
ＶＬＲ２は、ＶＭＣ情報記憶部８と、ＶＭＣセッション参加脱退要求受信部９と、ＶＭＣ情報管理部１０と、ＩＰマルチキャストアドレス管理部１１とを備えている。
【００３２】
ＶＭＣ情報記憶部８には、図５に示すように、ＶＭＣ−ＩＤと、このＶＭＣ−ＩＤで特定されるＶＭＣセッションのためにＶＬＲ―端末間通信で使用されるＩＰマルチキャストアドレスと、このＶＭＣセッションに参加している端末３の識別子と、このＶＭＣセッションに参加している他ＶＬＲ２に関する情報とが記憶されている。
【００３３】
ここで、ＩＰマルチキャストアドレスは、当該ＶＬＲ２がその配下の端末３にＩＰマルチキャストを利用した通信に用いられるものである。端末３の識別子とは、たとえば、その端末３のＩＰアドレスである。ただし、このＩＰアドレスは、プライベートでもグローバルでもよい。ＶＬＲ２が、ＶＬＲ管理領域Ｂ内部で他の端末３と識別できれば足りるからである。
他ＶＬＲ２に関する情報には、ＶＬＲ識別子と、ＶＬＲ間での通信手法と、ＶＬＲ間での通信に必要な情報が含まれる。ＶＬＲ識別子は、特定のＶＬＲ２を識別する情報であり、例えば、そのＶＬＲ２のグローバルＩＰアドレスが用いられる。
なお、図５には、チャネルがひとつの場合が示されているが、ＶＭＣ情報記憶部８には、配下の端末３が参加しているチャネル個数、つまりＶＭＣセッション数分だけの情報が記憶されている。
【００３４】
ＶＭＣセッション参加脱退要求受信部９は、端末３からのＶＭＣセッションへの参加または脱退要求信号を受信する。
ＶＭＣ情報管理部１０は、上記の参加または脱退要求信号に含まれるＶＭＣ−ＩＤに含まれるＶＬＭ識別子により特定されるＶＬＭ１に対して、上記ＶＭＣ−ＩＤに含まれるチャネル識別子により特定されるＶＭＣセッションへの参加または脱退要求を行う。あわせて、ＶＭＣ情報管理部１０は、上記したＶＬＭ１のＶＬＭチャネル情報送信部７から送信されてきた更新されたチャネル情報を受信し、それを、上記したＶＭＣ情報記憶部８に記憶させる。
【００３５】
ＩＰマルチキャストアドレス管理部１１は、当該ＶＬＲ２が当該ＶＭＣセッションへ参加する端末３にＩＰマルチキャスト通信を利用できるようにするため、ＶＬＲ管理領域Ｂの内部で重複のない一意なＩＰマルチキャストアドレスを自動的に決定する。そして、このＩＰマルチキャストアドレスを端末３に通知する。このＩＰマルチキャストアドレスは、ＶＬＲ２とその配下の端末３との間で取決められたものであり、閉じられた領域であるＶＬＲ管理領域Ｂの内部でのみ利用されるものであり、インターネット上を流れる通信に利用されるものではない。したがって、他のＶＬＲ２がその配下の端末３との間で使用するＩＰマルチキャストアドレスと重複しているかどうかは一切問題にならない。そのため、ＶＬＲ２同士が、互いに自分が使用しているＩＰマルチキャストアドレスに関する情報を通知し合うことは必要ない。
【００３６】
また、ＶＬＲ２は、ＩＰマルチキャスト送受信部１２と、転送ルール決定部１３と、ＶＬＲ間転送部１４も備える。
【００３７】
ＩＰマルチキャスト送受信部１２は、端末３からＶＭＣセッションのアプリケーションデータが送信されたとき、これを受信し、転送ルール決定部１３へ渡す機能を有する。また、ＩＰマルチキャスト送受信部１２は、転送ルール決定部１３によりＩＰマルチキャストアドレスが特定されると、このＩＰマルチキャストアドレスを付加して配下の端末３へ送信する機能も有する。
転送ルール決定部１３は、配下の端末３から送信されるアプリケーションデータに付加されているＩＰマルチキャストアドレスをキーとしてＶＭＣ情報記憶部８からＶＭＣ−ＩＤを抽出する機能、および、他ＶＬＲ２から受信したアプリケーションデータに付加されたＶＭＣ−ＩＤをキーとしてＶＭＣ情報記憶部８からＩＰマルチキャストアドレスを抽出する機能とを有する。つまり、転送ルール決定部１３は、ＶＭＣ−ＩＤとＩＰマルチキャストアドレスとの相互変換を行う働きをする。
ＶＬＲ間転送部１４は、他ＶＬＲとの間でＶＭＣセッションのアプリケーションデータを送受信する機能を有する。
【００３８】
次に、この実施形態において、ＩＰマルチキャスト方式でＶＭＣセッションがどのように行われるかについて、詳しく説明する。
【００３９】
このＶＭＣセッションを構成するＶＬＭ１は、ＵＲＬが“ｖｌｍ．ｊａｉｓｔ．ａｃ．ｊｐ”であり、これと対応するグローバルＩＰアドレス“１０．０．０．１０１”をもつＶＬＭ１０１であるものとする。
また、このＶＭＣセッションを構成するＶＬＲ２は、ＩＰアドレス“１９２．１６８．１．２０１”をもつＶＬＲ２０１と、ＩＰアドレス“１９２．１６８．２．２０２”をもつＶＬＲ２０２と、ＩＰアドレス“１９２．１６８．３．２０３”をもつＶＬＲ２０３であるものとする。さらに、ＶＬＲ２０１の配下には端末３０１と端末３０４、ＶＬＲ２０２の配下には端末３０２、ＶＬＲ２０３の配下には端末３０３が接続されているものとする。
【００４０】
ＶＬＭ１０１は、チャネル識別子が“ｃｈａｔ１”であるチャネルのＶＭＣセッションを管理している。この時点では、ＶＬＭ１０１のＶＬＭチャネル情報記憶部４には、図６（１）のように、レコードＲＥＣ１にチャネル識別子を表すデータが記憶されている。
【００４１】
端末３０１が、ＶＭＣ−ＩＤとして“ｖｌｍ．ｊａｉｓｔ．ａｃ．ｊｐ／ｃｈａｔ１”を指定し、ＶＬＲ２０１に対し当該ＶＭＣセッションへの参加要求を送信してきたとする。ＶＬＲ２０１のＶＭＣセッション参加脱退要求受信部９は、この参加要求信号を、ＩＰマルチキャストアドレス管理部１１とＶＭＣ情報管理部１０に渡す。
ここで、端末３０１のようなＶＭＣセッションへの参加希望者は、ホームページやメッセージングサービス等の何らかの情報共有手法を用いて、参加したいＶＭＣセッションのＶＭＣ−ＩＤを特定する。
【００４２】
ＩＰマルチキャストアドレス管理部１１は、ＶＬＲ２０１が自己のＶＬＲ管理領域Ｂ内で使用することのできるＩＰマルチキャストアドレスの中から現在使用していないものを選択し、これを当該ＶＭＣセッションに利用するＩＰマルチキャストアドレスと決定する。この決定したＩＰマルチキャストアドレスをαとすると、このαを端末３０１に対し通知する一方、ＶＭＣ情報記憶部８の内容を更新する。
αが通知された時点でのＶＭＣ情報記憶部８の内容を図７（１）に示す。ここでレコードＩＲＥＣ１にはＶＭＣ−ＩＤ、レコードＩＲＥＣ２には、決定されたＩＰマルチキャストアドレス、レコードＩＲＥＣ３には、ＶＭＣセッションへ参加する端末３を識別する情報が記憶されている。
【００４３】
一方、ＶＬＲ２０１のＶＭＣ情報管理部１０は、ＶＭＣ−ＩＤから、参加要求があったＶＭＣセッションは、ＶＬＭ識別子が“ｖｌｍ．ｊａｉｓｔ．ａｃ．ｊｐ”であるＶＬＭ、すなわちＶＬＭ１０１が通信を制御管理するチャネルの中で、チャネル識別子として“ｃｈａｔ１”をもつチャネルであると認識する。そして、ＶＬＭ１０１のＶＬＭチャネル参加脱退要求受信部５に対し、当該ＶＭＣセッションへの参加要求信号を渡す。
【００４４】
ＶＬＭチャネル参加脱退要求受信部５からこの信号を渡されたＶＬＭ１０１のＶＬＭチャネル情報管理部６は、ＶＬＭチャネル情報記憶部４を更新する。更新後のＶＬＭチャネル情報記憶部４の内容を図６（２）に示す。ＶＬＲ２０１のＶＬＲ識別子であるＶＬＲ２０１のＩＰアドレスがレコードＲＥＣ２に書き込まれたことがわかる。ここで、図示はしていないが、ＶＬＲ識別子以外に、ＶＬＲ間での通信手法や通信に必要な情報も書き込まれる。
【００４５】
ＶＬＭ１０１のＶＬＭチャネル情報送信部７は、上記のように更新されたＶＬＭチャネル情報記憶部４の内容をＶＬＲ２０１に送信する。このように、ＶＬＭ１０１は、更新されたＶＬＭチャネル情報記憶部４の内容をＶＭＣ−ＩＤで識別されるＶＭＣセッションに参加しているすべてのＶＬＲに対して通知する。この例では、現時点では、参加しているＶＬＲはＶＬＲ２０１だけなので、ＶＬＲ２０１だけに通知する。なお、ＶＬＲ２０１は、送信された内容が、他ＶＬＲに関するものではないので、ＶＭＣ情報記憶部８を更新することはない。
【００４６】
次に、端末３０２が、ＶＭＣ−ＩＤとして“ｖｌｍ．ｊａｉｓｔ．ａｃ．ｊｐ／ｃｈａｔ１”を指定し、ＶＬＲ２０２に対し当該ＶＭＣセッションへの参加要求を送信してきたとする。ＶＬＲ２０２のＶＭＣセッション参加脱退要求受信部９は、この参加要求信号を、ＩＰマルチキャストアドレス管理部１１とＶＭＣ情報管理部１０に渡す。ＩＰマルチキャストアドレス管理部１１は、ＶＬＲ２０２が自己のＶＬＲ管理領域Ｂ内で使用することのできるＩＰマルチキャストアドレスの中から現在使用していないものを決定する。この決定したＩＰマルチキャストアドレスをβとすると、このβを端末３０２に対し通知する一方、ＶＭＣ情報記憶部８の内容を更新する。βが通知された時点でのＶＭＣ情報記憶部８の内容を図８（１）に示す。
【００４７】
なお、βは、当該ＶＬＲ２０２が管理する閉じられた領域であるＶＬＲ管理領域Ｂ内部で重複さえしなければ自由に決定できる。先にＶＬＲ２０１が管理する領域でＩＰマルチキャストアドレスαが決定されたが、βはαとの一致の有無は問題ではない。ＩＰマルチキャストアドレスは閉じられた領域である各ＶＬＲ管理領域Ｂ内で自由に決定可能だからである。したがって、ＶＬＲ２０１とＶＬＲ２０２が互いにＩＰマルチキャストアドレスに関する情報を交換しあう必要はない。
【００４８】
一方、ＶＬＲ２０２のＶＭＣ情報管理部１０は、ＶＭＣ−ＩＤから、端末３０２が参加を要求してきたＶＭＣセッションは、ＶＬＭ識別子が“ｖｌｍ．ｊａｉｓｔ．ａｃ．ｊｐ”であるＶＬＭ１、すなわちＶＬＭ１０１が通信を制御管理するチャネルの中で、チャネル識別子として“ｃｈａｔ１”をもつチャネルであると認識する。そして、ＶＬＭ１０１のＶＬＭチャネル参加脱退要求受信部５に対し、当該チャネルへの参加要求信号を送信する。
【００４９】
ＶＬＭチャネル参加脱退要求受信部５からこの信号を渡されたＶＬＭ１０１のＶＬＭチャネル情報管理部６は、ＶＬＭチャネル情報記憶部４を更新する。更新後のＶＬＭチャネル情報記憶部４の内容を図６（３）に示す。ＶＬＲ２０２を識別するＶＬＲ２０２のＩＰアドレスがレコードＲＥＣ２に追加されたことがわかる。
ＶＬＭ１０１のＶＬＭチャネル情報送信部７は、上記のようにＶＬＭチャネル情報記憶部４が更新されたので、参加ＶＬＲ２であるＶＬＲ２０１とＶＬＲ２０２のＶＭＣ情報管理部１０に、当該更新内容を送信する。
【００５０】
受信したＶＬＲ２０１のＶＭＣ情報管理部１０は、図７（２）に示すようにＶＭＣ情報記憶部８の内容を更新する。レコードＩＲＥＣ４にこのＶＭＣセッションに新たに参加した他ＶＬＲであるＶＬＲ２０２の識別子が記憶されたことがわかる。
なお、図示はしていないが、ＶＬＲ識別子以外に、ＶＬＲ２０２との間での通信手法や通信に必要な情報も記憶される。
また、新たに参加したＶＬＲ２０２のＶＭＣ情報管理部１０は、図８（２）に示すようにＶＭＣ情報記憶部８の内容を更新する。レコードＪＲＥＣ４にこのＶＭＣセッションに参加している他ＶＬＲ２であるＶＬＲ２０１のＩＰアドレスが記憶されたことがわかる。
【００５１】
次に、端末３０３が、ＶＭＣ−ＩＤとして“ｖｌｍ．ｊａｉｓｔ．ａｃ．ｊｐ／ｃｈａｔ１”を指定し、ＶＬＲ２０３に対し当該ＶＭＣセッションへの参加要求を送信してきたとする。ＶＬＲ２０３のＶＭＣセッション参加脱退要求受信部９は、この参加要求信号を、ＩＰマルチキャストアドレス管理部１１とＶＭＣ情報管理部１０に渡す。
ＩＰマルチキャストアドレス管理部１１は、ＶＬＲ２０３が自己のＶＬＲ管理領域Ｂ内で使用することのできるＩＰマルチキャストアドレスの中から現在使用していないものを決定する。この決定したＩＰマルチキャストアドレスをγとすると、このγを端末３０３に対し通知する一方、ＶＭＣ情報記憶部８の内容を更新する。γが通知された時点でのＶＭＣ情報記憶部８の内容を図９（１）に示す。
【００５２】
一方、ＶＬＲ２０３のＶＭＣ情報管理部１０は、ＶＭＣ−ＩＤから、端末３０３が参加を要求してきたＶＭＣセッションは、ＶＬＭ識別子が“ｖｌｍ．ｊａｉｓｔ．ａｃ．ｊｐ”であるＶＬＭ１、すなわちＶＬＭ１０１が通信を制御管理するチャネルの中で、チャネル識別子として“ｃｈａｔ１”をもつチャネルであると認識する。そして、ＶＬＭ１０１のＶＬＭチャネル参加脱退要求受信部５に対し、当該ＶＭＣセッションへの参加要求信号を送信する。
【００５３】
ＶＬＭチャネル参加脱退要求受信部５からこの信号を渡されたＶＬＭ１０１のＶＬＭチャネル情報管理部６は、ＶＬＭチャネル情報記憶部４を更新する。更新後のＶＬＭチャネル情報記憶部４の内容を図６（４）に示す。ＶＬＲ２０３を識別するＶＬＲ２０３のＩＰアドレスがレコードＲＥＣ２に追加されたことがわかる。
ＶＬＭ１０１のＶＬＭチャネル情報送信部７は、上記のようにＶＬＭチャネル情報記憶部４が更新されたので、参加ＶＬＲ２であるＶＬＲ２０１とＶＬＲ２０２とＶＬＲ２０３の各ＶＭＣ情報管理部１０に、当該更新内容を送信する。
【００５４】
受信したＶＬＲ２０１のＶＭＣ情報管理部１０は、図７（３）に示すようにＶＭＣ情報記憶部８の内容を更新する。レコードＩＲＥＣ４にこのＶＭＣセッションに新たに参加したＶＬＲ２０３のＩＰアドレスが追加されたことがわかる。
受信したＶＬＲ２０２のＶＭＣ情報管理部１０は、図８（３）に示すようにＶＭＣ情報記憶部８の内容を更新する。レコードＪＲＥＣ４にこのＶＭＣセッションに新たに参加したＶＬＲ２０３のＩＰアドレスが追加されたことがわかる。
また、新たに参加したＶＬＲ２０３のＶＭＣ情報管理部１０は、送信された情報に基づいて図９（２）に示すようにＶＭＣ情報記憶部８の内容を更新する。レコードＫＲＥＣ４にこのＶＭＣセッションに参加している他ＶＬＲ２であるＶＬＲ２０１とＶＬＲ２０２のＩＰアドレスが記憶されたことがわかる。
【００５５】
次に、端末３０４が、ＶＭＣ−ＩＤとして“ｖｌｍ．ｊａｉｓｔ．ａｃ．ｊｐ／ｃｈａｔ１”を指定し、ＶＬＲ２０１に対し当該ＶＭＣセッションへの参加要求を送信してきたものとする。ＶＬＲ２０１のＶＭＣセッション参加脱退要求受信部９は、この参加要求信号を、ＩＰマルチキャストアドレス管理部１１とＶＭＣ情報管理部１０に渡す。ＩＰマルチキャストアドレス管理部１１は、図７（３）に示すＶＭＣ情報記憶部８の内容を参照し、レコードＩＲＥＣ１からチャネル“ｃｈａｔ１”への参加要求がすでにあること、及び、レコードＩＲＥＣ２の内容から、すでにＩＰマルチキャストアドレスαが割り当てられていることを認識する。そして、端末３０４に対して、このαを通知する。
【００５６】
一方、ＶＭＣ情報管理部１０は、図７（４）に示すように新たな参加端末である端末３０４をＶＭＣ情報記憶部８に記憶させる。レコードＩＲＥＣ３に端末３０４が追加されたことがわかる。
ここで、ＶＬＲ２０１のＶＭＣ情報管理部１０は、端末３０４が新たにＶＭＣセッションに参加したという情報をＶＬＭ１０１に通知することはしない。ＶＬＲ２０１は、チャネル“ｃｈａｔ１”に参加することを、既にＶＬＭ１０１に対して要求済みだからである。このように、ＶＬＲ２がＶＬＭ１に通知するのは、ＶＬＲ２自体のＶＭＣセッションへの参加要求であって、個々の端末単位での参加要求ではない。この点にも、ＶＬＭ管理領域ＡとＶＬＲ管理領域Ｂとを相互に独立、かつ、閉じられた領域としたこの実施形態の特徴が表れている。
【００５７】
以上、端末３からＶＬＲ２への参加要求があった場合のＶＬＲ２の処理内容、ＶＬＲ２からＶＬＭ１への参加要求があった場合のＶＬＭ１の処理内容について説明してきた。
次に、図１０と図１１を参考にしながら、ＶＭＣセッションの通信内容であるアプリケーションデータが参加端末間でどのように送受信されるかについて説明する。
図１０に示される矢印はアプリケーションデータの流れを意味し、矢印（ａ）と（ｃ）と（ｅ）はＶＬＲ−端末間通信を、矢印（ｂ）と（ｄ）はＶＬＲ間通信を表している。
なお、図１１（１）〜図１１（３）には、この実施形態の説明に必要なフィールドだけを記した。
【００５８】
端末３０１からＶＭＣセッションへのデータ送信があった場合（図１０の矢印（ａ））、ＶＬＲ２０１のＩＰマルチキャスト送受信部１２が受信する。このとき、端末３０１からの送信内容は、図１１（１）に示すように、アプリケーションデータと、ＩＰマルチキャストアドレス（＝α）と、ＶＭＣセッションの送信者である端末３０１の識別子とに大別される。上記ＩＰマルチキャスト送受信部１２は、ＩＰマルチキャストアドレスαと、送信者識別子と、アプリケーションデータと、受信インタフェース情報を、ＶＬＲ２０１の転送ルール決定部１３へ渡す。
【００５９】
上記転送ルール決定部１３は、図７（４）に示すＶＭＣ情報記憶部８を参照し、ＩＰマルチキャストアドレスαに対応するＶＭＣ−ＩＤ“ｖｌｍ．ｊａｉｓｔ．ａｃ．ｊｐ／ｃｈａｔ１”を取り出す。そして、図７（４）のレコードＩＲＥＣ４から、当該ＶＭＣセッションに参加している他のＶＬＲ２を取り出す。その結果、ＶＬＲ２０２が転送するべきＶＬＲ２であると特定し、ＶＬＲ間転送部１４に対し、この他ＶＬＲ２に関する情報と、ＶＭＣ−ＩＤと、送信者識別子と、アプリケーションデータとを渡す。
【００６０】
ＶＬＲ２０１のＶＬＲ間転送部１４は、ＶＭＣ−ＩＤと、ＶＬＲ２０１自らの識別子と、アプリケーションデータと、他ＶＬＲ間との通信方式に従い必要な情報をＶＬＲ２０２に向けて転送する。通信方式に従って必要な情報には、転送先であるＶＬＲ２０２のＩＰアドレスが含まれる。このときのＶＬＲ２０１とＶＬＲ２０２間の通信内容を図１１（２）に示す。
【００６１】
次に、ＶＬＲ２０２のＶＬＲ間転送部１４が、ＶＬＲ２０１のＶＬＲ間転送部１４から上記した転送データを受け取り（図１０の矢印（ｂ））、ＶＬＲ２０２の転送ルール決定部１３に、ＶＭＣ−ＩＤと、転送元であるＶＬＲ２０１の識別子と、アプリケーションデータを渡す。ＶＬＲ２０２の転送ルール決定部１３は、受信データ中のＶＭＣ−ＩＤからＶＭＣセッションを特定する。
また、ＶＭＣ−ＩＤに基づいて図８（３）に示すＶＭＣ情報記憶部８を参照し、ＩＰマルチキャストアドレスは“β”であることを認識する。そして、このＩＰマルチキャストアドレス“β”と、当該ＶＭＣセッションの送信者である端末３０１の識別子と、アプリケーションデータをＶＬＲ２０２のＩＰマルチキャスト送受信部１２に渡す。
【００６２】
ＶＬＲ２０２のＩＰマルチキャスト送受信部１２は、図１１（３）に示すように、ＶＭＣ送信者識別子を送信者とし、ＩＰマルチキャストアドレス“β”を宛先として、アプリケーションデータをＩＰマルチキャスト通信を利用して送信する（図１０の矢印（ｃ））。
【００６３】
次にＶＬＲ２０２からＶＬＲ２０３への当該アプリケーションデータの転送（図１０の矢印（ｄ））について説明する。ＶＬＲ２０２のＶＬＲ間転送部１４が、ＶＬＲ２０１のＶＬＲ間転送部１４から受け取った（図１０の矢印（ｂ））転送データをＶＬＲ２０２の転送ルール決定部１３に、ＶＭＣ−ＩＤと、転送元であるＶＬＲ２０１の識別子と、アプリケーションデータを渡す。ＶＬＲ２０２の転送ルール決定部１３は、受信データ中のＶＭＣ−ＩＤに基づいてＶＭＣ情報記憶部からＶＭＣセッションと、そのＶＭＣセッションに参加している他ＶＬＲに関する情報を取り出す。この他ＶＬＲに関する情報から、ＶＬＲ２０３がアプリケーションデータを転送するべきＶＬＲであることを決定する。そこで、転送ルール決定部１３は、転送先のＶＬＲ２０３の識別子と、ＶＬＲ２０３との通信に必要な情報と、ＶＭＣ−ＩＤと、ＶＭＣセッションの送信者である端末３０１の識別子と、アプリケーションデータをＶＬＲ２０２のＶＬＲ間転送部１４に渡し、ＶＬＲ間転送部１４がこれらをＶＬＲ２０３のＶＬＲ間転送部１４に向け転送する。
受け取ったアプリケーションデータは、ＶＬＲ２０３によって、配下の端末３０３にＩＰマルチキャストを利用して送信される（図１０の矢印（ｅ））。
【００６４】
上記したＶＬＲ２０１からＶＬＲ２０２へのデータ転送のようなＶＬＲ間の通信では、ＩＰユニキャストを利用する。このようにＩＰユニキャストによるＶＬＲ間通信ができるのは、同じＶＭＣセッションに参加している各ＶＬＲ２同士が、ＶＬＭ１を介して他ＶＬＲ情報を取得しているからである。
【００６５】
ところで、ＩＰマルチキャスト通信のデータをＩＰユニキャストでカプセル化して転送する従来のトンネリング技術では、転送元が転送先のＩＰマルチキャストアドレスを知っていなくてはならなかった。したがって、ＶＬＲ２０１がＶＬＲ２０２に対し、トンネリング技術によってアプリケーションデータを転送する場合、ＶＬＲ２０１はＶＬＲ２０２側のＩＰマルチキャストアドレスがβであることを知っている必要があった。
しかし、この実施形態では、他ＶＬＲ２で使用されているＩＰマルチキャストアドレスが何であるかを知っている必要はない。このことは、図１１（２）に示す例で、ＶＬＲ２０１からＶＬＲ２０２へアプリケーションデータを転送する際、転送先のＶＬＲ２０２で使用しているＩＰマルチキャストアドレス“β”が含まれていないことからもわかる。但し、ＩＰマルチキャストアドレスの代わりにＶＭＣ−ＩＤが転送データに含まれる。このＶＭＣ−ＩＤが転送先のＶＬＲ２０２でＩＰマルチキャストアドレス“β”に変換される。したがって、ＶＬＲ２０１は、ＶＬＲ２０２でＩＰマルチキャストアドレスとしてβが利用されていることを知らなくてもＶＬＲ２０２にＶＭＣセッションのアプリケーションデータを転送できる。
【００６６】
なお、各ＶＬＲ２がＩＰマルチキャスト通信に対応できるならば、ＶＬＲ間の通信をＩＰマルチキャスト方式で行えばよいと考えられる。しかし、ＶＬＲ間でデータ転送をする場合、これらのＶＬＲ２の間には、他のルータが介在していることが通常である。もし、ＶＬＲ間の途中に存在するルータの中に１つでもＩＰマルチキャスト通信に対応していないものがあるならば、ＶＬＲ間のＩＰマルチキャスト通信ができなくなってしまう。かといって、トンネリング技術では、既に述べたように、ＩＰマルチキャストアドレスの管理の問題についての考慮を欠いている。
【００６７】
しかし、この実施形態では、ＩＰマルチキャスト非対応のルータが存在するという問題を解決することができた。
しかも、１つのＶＬＲ２が管理する閉じたＶＬＲ管理領域Ｂ内部では、ＩＰマルチキャスト通信を利用し、効率よく通信ができる。
【００６８】
つまり、この実施形態では、既存の『転送にＩＰマルチキャストのみを利用するグループ通信手法』とは異なり、ＩＰマルチキャストとＩＰユニキャストという複数の転送方式を組合せてグループ通信を実現したわけである。この実施形態は、ＶＭＣセッションのアプリケーションデータを参加者にだけ効率よく転送できるので、あたかもシステム全体でマルチキャストパケットのための仮想リンクを構成しているように見える。
そして、このような手法を採用したことにより、ＩＰマルチキャストアドレスの管理の問題を解決し、かつ、ＩＰマルチキャストに非対応なネットワーク上のネットワーク中継器の存在という問題も解決した。
【００６９】
このように、ＩＰマルチキャスト通信とＩＰユニキャスト通信を組合せて、広域に存在するネットワーク内でグループ通信の享受を可能としたのは、システム全体をＶＬＲ２が参加端末３を管理する領域と、ＶＬＭ１が参加ＶＬＲ２を管理する領域とに分けたことにある。
そして、これら２種類の領域の連携を可能にする働きをするのがＶＭＣ−ＩＤである。
【００７０】
ＶＬＲ間でデータを転送する場合、図１１（２）に示すように、データにＶＭＣ−ＩＤを付加する。各ＶＬＲ２の転送ルール決定部１３は、データに付加されているＶＭＣ−ＩＤに基づき自己のＶＭＣ情報記憶部８を参照し、そのＶＭＣ−ＩＤに対応して、どのようなＩＰマルチキャストアドレスを配下の端末３に割り当てているのかを抽出することができる。そのため、ＶＬＲ２は、ＩＰマルチキャストを利用して配下の端末３に効率よくデータの送信ができる。
一方、各ＶＬＲ２の転送ルール決定部１３は、データに付加されているＶＭＣ−ＩＤに基づき自己のＶＭＣ情報記憶部８を参照し、そのＶＭＣ−ＩＤに対応して、他にどのような識別子をもつＶＬＲ２が当該ＶＭＣセッションに参加しているかを抽出できる。そのため、ＶＬＲ２は、同じＶＭＣセッションに参加している他のＶＬＲ２にデータを転送することが可能となる。
したがって、当該ＶＭＣ−ＩＤで特定されるＶＭＣセッションのすべての参加者の間でアプリケーションデータの共有が可能となる。
【００７１】
ところで、この実施形態は、短期間に仲間が集合して、仲間内で通信を行い、短期間に解散するような泡沫的マルチキャスト通信を専ら念頭に置いている。そのため、参加や脱退は頻繁に行われる。
そこで、以下にこのＶＭＣセッションから参加者が脱退する場合のＶＬＭ１とＶＬＲ２の処理について説明する。
【００７２】
端末３０３がチャネル“ｃｈａｔ１”からの脱退をＶＬＲ２０３のＶＭＣセッション参加脱退要求受信部９に要求してきたとする。ＶＬＲ２０３のＩＰマルチキャストアドレス管理部１１は、ＶＭＣ情報記憶部８から、図９（３）に示すように、レコードＫＲＥＣ３から端末３０３を削除する。
次にＶＬＲ２０３のＶＭＣ情報管理部１０は、ＶＭＣ情報記憶部８を参照し、チャネル“ｃｈａｔ１”に参加している端末３がひとつもなくなったことを検知し、ＶＭＣ情報記憶部８からＶＭＣ−ＩＤ“ｖｌｍ．ｊａｉｓｔ．ａｃ．ｊｐ／ｃｈａｔ１”で識別されるＶＭＣセッションに関する情報を削除する。つまり、図９（３）のレコードＫＲＥＣ１〜ＫＲＥＣ４を削除する。
【００７３】
一方、ＶＬＲ２０３は、自己が管理している端末３のうちでチャネル“ｃｈａｔ１”に参加しているものが１つもなくなったので、ＶＬＭ１０１のＶＬＭチャネル参加脱退要求受信部５に対し、チャネル“ｃｈａｔ１”からの脱退要求を行う。この脱退要求に基づいてＶＬＭ１０１のＶＬＭチャネル情報管理部６は、図６（５）に示すように、ＶＬＭチャネル情報記憶部４を更新する。レコードＲＥＣ２からＶＬＲ２０３の識別子であるＩＰアドレス“１９２．１６８．３．２０３”が削除されていることがわかる。
【００７４】
次に、ＶＬＭチャネル情報送信部７は、更新されたＶＬＭチャネル情報記憶部４の更新された内容をＶＬＲ２０１とＶＬＲ２０２に送信し、各ＶＬＲ２のＶＭＣ情報管理部１０は、ＶＭＣ情報記憶部８の内容を図７（５）と図８（４）に示すように更新する。図７（５）のレコードＩＲＥＣ４と図８（４）のレコードＪＲＥＣ４のいずれからもＶＬＲ２０３に関する情報が削除されていることがわかる。
【００７５】
上記の実施形態において、ＶＬＲ２は、自己が管理している参加者端末３に対しＩＰマルチキャスト通信を利用してデータを送信できること、および、他のＶＬＲ間のデータ転送はＩＰユニキャスト通信を利用して行うことについて説明した。
このＶＬＲ２の機能を図１２に示すようにダイアルアップルータに適用することができる。
ダイアルアップルータにＶＬＲを適用することにより、ダイアルアップルータより上流のネットワーク中継器が、ＩＰマルチキャストに対応している必要性がなくなる。
また、ＩＰマルチキャストを利用する範囲は、ＶＭＣセッションへの参加者端末３とダイアルアップルータとの間だけとなるため、ＩＰマルチキャストアドレスはそれぞれのダイアルアップルータが配下の端末３を管理している領域内部で重複しない自由なアドレスが利用可能となっている。
すなわち、ダイアルアップルータ配下のネットワーク毎に、他のネットワークとは別個にＩＰマルチキャストアドレスの割当・管理を行うことができる。
【００７６】
また、図１３に示すように、ＶＬＲをインターネットサービスプロバイダ（以下、「ＩＳＰ」という）のルータであるＩＳＰルータに適用することもできる。
この場合、ＩＳＰのルータより上流のネットワーク中継器はＩＰマルチキャストに対応している必要はない。
この適用例では、ＩＰマルチキャストアドレスは、ＩＳＰルータの配下のネットワークを管理する領域内部で、当該ＩＳＰが自由に割り当てることができる。
すなわち、ＩＳＰルータ配下のネットワーク毎で別々のＩＰマルチキャストアドレスの割当・管理を行うことが可能となる。
【００７７】
さらに、図１４に示すように、ＶＬＲをインターネット上のよりバックボーンに近いルータに適用することもできる。
この場合、ＩＰマルチキャストに対応するネットワークはさらに拡大している。
【００７８】
これらのＶＬＲの適用例は、ＩＰマルチキャストアドレスの管理を分散的に行えることを示している。
また、ネットワークにおいて、ＩＰマルチキャストに対応できる範囲を段階的に拡大していけること示している。
【００７９】
ＶＬＲ間の通信の概要は、既に述べたとおりであるが、通信経路の最適化について特に言及していなかった。以下、通信回線の品質に基づき、どのようにして最適な通信経路を決定するかについて、説明する。
【００８０】
図１５に示す例のように、ＶＬＲ２０１、ＶＬＲ２０２、ＶＬＲ２０３が同じＶＭＣセッションに参加しているものとする。図中丸付きの数字はネットワーク特性値を表わしている。この例では、ネットワーク特性値はＲＴＴ（＝Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）を示しているものとする。各ＶＬＲ間ネットワークのＲＴＴ値には大きな差があり、ＶＬＲ２０１−ＶＬＲ２０２間で通信を行う場合、ＶＬＲ２０１−ＶＬＲ２０３間あるいはＶＬＲ２０２−ＶＬＲ２０３間で通信を行う場合と比べ、１０倍のＲＴＴを要している。
【００８１】
この場合、ＶＬＲ２０１から転送されるアプリケーションデータは、経路Ｗ１を用いて、ＶＬＲ２０２及びＶＬＲ２０３と共有するよりも、経路Ｗ２を用いて共有した方が、より速くすべてのＶＬＲにアプリケーションデータが行き渡ると予想される。したがって、図１５の例では、最適な経路としてＷ２が選ばれる。
なお、ネットワーク特性値は、上記のＲＴＴに限らず、ＶＬＲ間のネットワークを構成するルータ数でもよく、帯域幅やパケット損失率やジッタなどのＩＰ通信の特性値でもよい。
【００８２】
この例が示すとおり、ＶＬＲ間通信をどのような経路を用いて実現するかは、ＶＭＣセッションの特性に大きく関わる問題である。この実施形態において、この経路を計算する方法には、ＶＬＭが集中的に行う方法と各ＶＬＲが分散的の行う方法との２つがある。
【００８３】
まず、ＶＬＭ１が集中的に経路計算を行う方法を説明する。この方法を採用する場合、ＶＬＭ１「とＶＬＲ２のブロック図は、図１６のようになる。図３と比べ、ＶＬＭ１にＶＬＲ間通信経路管理部１５とＶＬＲ２にＶＬＲ間ネットワーク情報収集部１６とが追加されている。
ＶＬＭ１のＶＬＲ間通信経路管理部１５は、ＶＬＭ１が管理している任意のＶＭＣセッションに参加している各ＶＬＲ２のＶＬＲ間ネットワーク情報収集部１６に対して、同じＶＭＣセッションに参加している他ＶＬＲ２との間のネットワーク情報を収集するように指示する。指示された各ＶＬＲ２のＶＬＲ間ネットワーク情報収集部１６は、自らと他ＶＬＲ２との間のネットワークについて、その情報を収集する。ＶＬＲ間ネットワーク情報収集部１６は、その収集した情報をＶＬＭ１のＶＬＲ間通信経路管理部１５に送信する。
このように、ＶＬＭ１のＶＬＲ間通信経路管理部１５には、各ＶＬＲ間のネットワーク情報が集まる。ＶＬＭ１はこれを用いて経路計算を行い、当該セッションに参加している全ＶＬＲ２に対し送信する。その結果、最適な経路を用いたＶＬＲ間通信が実現できる。
【００８４】
次に、各ＶＬＲ２が分散的に経路計算を行う方法について説明する。この方法を採用する場合、ＶＬＭ１とＶＬＲ２のブロック図は、図１７のようになる。図３と比べ、ＶＬＭ２にＶＬＲ間ネットワーク情報収集部１６とＶＬＲ間通信経路管理部１７とが追加されている。
ＶＬＲ間ネットワーク情報収集部１６は、自己のＶＬＲ２のＶＭＣ情報記憶部８より、同じＶＭＣセッションに参加している他ＶＬＲ２の情報を読み取り、自らと他ＶＬＲ２との間のネットワークについて、その情報を収集する。その収集した情報を、ＶＭＣ情報記憶部８に記憶させる。当該ＶＬＲのＶＬＲ間通信経路管理部１７は、自己のＶＭＣ情報記憶部８より、他ＶＬＲ２との間のＶＬＲ間ネットワーク情報を読み取り、その情報を用いて、ＶＬＲ間通信の最適経路を決定する。決定した経路は、ＶＭＣ情報記憶部８に記憶される。
このように、各ＶＬＲ２がそれぞれ経路を決定する。
【００８５】
上記した２つの経路計算の方法は、それぞれ長短がある。ＶＬＭ１が集中的に計算する方法は、頻繁に参加ＶＬＲ２が変更し、参加人数が比較的少ないＶＭＣセッションでの利用に向いている。一方、ＶＬＲ２が分散的に計算する方法は、参加ＶＬＲ２がそれほど頻繁に変わらず、参加人数が多いＶＭＣセッションでの利用に向いている。
【００８６】
なお、上記の実施形態におけるＶＬＭ１とＶＬＲ２のそれぞれの内部構成と各構成要素の機能はあくまでも一例であり、これらに限られるものではない。また、図１１（１）〜図１１（３）に示す送信データの構成、図４に示すＶＬＭチャネル情報記憶部と図５に示すＶＭＣ情報記憶部のテーブル構造は一例であり、これらに限定されるものではない。これらは、ＶＬＭ１、ＶＬＲ２に組み込まれるソフトウェア及びハードウェアをどのように設計し実装するかに依存する。
【図面の簡単な説明】
【００８７】
【図１】実施形態の全体構成を示す基本概念図である。
【図２】ＶＭＣ−ＩＤの説明図である。
【図３】ＶＬＭとＶＬＲの内部構成を示すブロック図である。
【図４】ＶＬＭチャネル情報記憶部のテーブル構造を示す図である。
【図５】ＶＭＣ情報記憶部のテーブル構造を示す図である。
【図６（１）】ＶＬＭのＶＬＭチャネル情報記憶部に書き込まれる内容を例示する図である。
【図６（２）】ＶＬＭのＶＬＭチャネル情報記憶部に書き込まれる内容を例示する図である。
【図６（３）】ＶＬＭのＶＬＭチャネル情報記憶部に書き込まれる内容を例示する図である。
【図６（４）】ＶＬＭのＶＬＭチャネル情報記憶部に書き込まれる内容を例示する図である。
【図６（５）】ＶＬＭのＶＬＭチャネル情報記憶部に書き込まれる内容を例示する図である。
【図７（１）】ＶＬＲのＶＭＣ情報記憶部に書き込まれる内容を例示する図である。
【図７（２）】ＶＬＲのＶＭＣ情報記憶部に書き込まれる内容を例示する図である。
【図７（３）】ＶＬＲのＶＭＣ情報記憶部に書き込まれる内容を例示する図である。
【図７（４）】ＶＬＲのＶＭＣ情報記憶部に書き込まれる内容を例示する図である。
【図７（５）】ＶＬＲのＶＭＣ情報記憶部に書き込まれる内容を例示する図である。
【図８（１）】ＶＬＲのＶＭＣ情報記憶部に書き込まれる内容を例示する図である。
【図８（２）】ＶＬＲのＶＭＣ情報記憶部に書き込まれる内容を例示する図である。
【図８（３）】ＶＬＲのＶＭＣ情報記憶部に書き込まれる内容を例示する図である。
【図８（４）】ＶＬＲのＶＭＣ情報記憶部に書き込まれる内容を例示する図である。
【図９（１）】ＶＬＲのＶＭＣ情報記憶部に書き込まれる内容を例示する図である。
【図９（２）】ＶＬＲのＶＭＣ情報記憶部に書き込まれる内容を例示する図である。
【図９（３）】ＶＬＲのＶＭＣ情報記憶部に書き込まれる内容を例示する図である。
【図１０】ＶＭＣセッションにおいてアプリケーションデータの流れを例示する図である。
【図１１（１）】ＶＭＣセッションにおいて転送されるデータの構成を例示する図である。
【図１１（２）】ＶＭＣセッションにおいて転送されるデータの構成を例示する図である。
【図１１（３）】ＶＭＣセッションにおいて転送されるデータの構成を例示する図である。
【図１２】ＶＬＲをダイアルアップルータに適用した場合の概念図である。
【図１３】ＶＬＲをＩＳＰルータに適用した場合の概念図である。
【図１４】ＶＬＲをバックボーンに近いルータに適用した場合の概念図である。
【図１５】経路最適化の考え方を説明する図である。
【図１６】ＶＬＭが集中的に経路計算を行う場合の、ＶＬＭとＶＬＲの内部構成を示すブロック図である。
【図１７】ＶＬＲが分散的に経路計算を行う場合の、ＶＬＭとＶＬＲの内部構成を示すブロック図である。
【符号の説明】
【００８８】
１      ＩＰマルチキャスト通信情報管理装置（ＶＬＭ）
２      ＩＰマルチキャスト転送装置（ＶＬＲ）
３      通信装置
４      （ＶＬＭの）ＶＬＭチャネル情報記憶部
５      （ＶＬＭの）ＶＬＭチャネル参加脱退要求受信部
６      （ＶＬＭの）ＶＬＭチャネル情報管理部
７      （ＶＬＭの）ＶＬＭチャネル情報送信部
８      （ＶＬＲの）ＶＭＣ情報記憶部
９      （ＶＬＲの）ＶＭＣセッション参加脱退要求受信部
１０    （ＶＬＲの）ＶＭＣ情報管理部
１１    （ＶＬＲの）ＩＰマルチキャストアドレス管理部
１２    （ＶＬＲの）ＩＰマルチキャスト送受信部
１３    （ＶＬＲの）転送ルール決定部
１４    （ＶＬＲの）ＶＬＲ間転送部
Ａ      ＶＬＭ管理領域
Ｂ      ＶＬＲ管理領域
【図１】
2005094608.tif 000003
【図２】
2005094608.tif 000004
【図３】
2005094608.tif 000005
【図４】
2005094608.tif 000006
【図５】
2005094608.tif 000007
【図６（１）】
2005094608.tif 000008
【図６（２）】
2005094608.tif 000009
【図６（３）】
2005094608.tif 000010
【図６（４）】
2005094608.tif 000011
【図６（５）】
2005094608.tif 000012
【図７（１）】
2005094608.tif 000013
【図７（２）】
2005094608.tif 000014
【図７（３）】
2005094608.tif 000015
【図７（４）】
2005094608.tif 000016
【図７（５）】
2005094608.tif 000017
【図８（１）】
2005094608.tif 000018
【図８（２）】
2005094608.tif 000019
【図８（３）】
2005094608.tif 000020
【図８（４）】
2005094608.tif 000021
【図９（１）】
2005094608.tif 000022
【図９（２）】
2005094608.tif 000023
【図９（３）】
2005094608.tif 000024
【図１０】
2005094608.tif 000025
【図１１（１）】
2005094608.tif 000026
【図１１（２）】
2005094608.tif 000027
【図１１（３）】
2005094608.tif 000028
【図１２】
2005094608.tif 000029
【図１３】
2005094608.tif 000030
【図１４】
2005094608.tif 000031
【図１５】
2005094608.tif 000032
【図１６】
2005094608.tif 000033
【図１７】
2005094608.tif 000034