(57)【特許請求の範囲】
【請求項１】
複数のユーザ端末とパケット転送装置がポイント・ツー・ポイントで接続されてマルチキャスト通信が行われるネットワークシステムにおいて、ユーザ端末とパケット転送装置間に配置されパケットの中継を行うマルチキャストパケット制御装置であって、
マルチキャスト通信で用いられるパケットを格納するマルチキャスト用送信バッファと、
マルチキャスト用送信バッファ使用率に対する転送スピード制限情報を記憶し、前記マルチキャスト用送信バッファから前記パケット転送装置への転送を制限するための転送制限テーブルと、
グループアドレス及び送信元アドレスを記憶し、廃棄したパケットを記録するための廃棄テーブルと、
前記転送制限テーブル及び前記廃棄テーブルを参照及び更新し、パケット転送制御を行うためのプロセッサと、
を備え、
前記プロセッサは、受信したパケットが、前記パケット転送装置からの参加確認に対する応答パケットであると判断したとき、該パケットを前記マルチキャスト用送信バッファに転送し、
前記プロセッサは、前記マルチキャスト用送信バッファの使用率を監視し、応答パケットが前記マルチキャスト用送信バッファに転送されるときに、監視された使用率と前記転送制限テーブルに設定されているマルチキャスト用送信バッファ使用率とを比較し、該当する転送スピード制限情報を求め、該転送スピード制限情報に基づき、制限が必要である場合は、前記マルチキャスト用送信バッファから前記パケット転送装置への転送スピード又は転送パケット数に制限をかけ、
前記プロセッサは、前記制限がかっているときに応答パケットを受信した場合は、前記廃棄テーブルを検索し、
前記プロセッサは、受信パケットのグループアドレス及び送信元アドレスに該当するデータが前記廃棄テーブルにない場合は、その受信パケットを廃棄し、前記廃棄テーブルに該グループアドレス及び送信元アドレスを記録し、
一方、前記プロセッサは、受信パケットのグループアドレス及び送信元アドレスに該当するデータが前記廃棄テーブルにある場合は、その受信パケットを優先して前記マルチキャスト用送信バッファに格納し、前記廃棄テーブルから該グループアドレス及び送信元アドレスに該当するデータを削除する、
前記マルチキャストパケット制御装置。
【請求項２】
前記マルチキャスト用送信バッファは、グループアドレスごとに複数のグループアドレス用バッファを備え、
前記転送制限テーブルは、マルチキャスト用送信バッファ使用率及び転送スピード制限情報を対して、グループアドレスをさらに記憶し、
前記プロセッサは、前記グループアドレス用バッファの使用率を監視し、応答パケットが前記グループアドレス用バッファに転送されるときに、受信パケットのグループアドレスに基づき、監視された使用率と前記転送制限テーブルに設定されているマルチキャスト用送信バッファ使用率とを比較し、該当する転送スピード制限情報を求め、該転送スピード情報に基づき、制限が必要である場合は、前記グループアドレス用バッファから前記パケット転送装置への転送スピード又は転送パケット数に制限をかけることを特徴とする請求項１に記載のマルチキャストパケット制御装置。
【請求項３】
前記プロセッサは、監視した前記マルチキャスト用送信バッファの使用率が設定値より小さくなったら、前記マルチキャスト用送信バッファから前記パケット転送装置への転送制限を解除することを特徴とする請求項１に記載のマルチキャストパケット制御装置。
【請求項４】
前記廃棄テーブルは、グループアドレス及び送信元アドレスに対して、廃棄されたパケットの優先度情報をさらに記憶し、
前記プロセッサは、前記廃棄テーブルを検索するとき、さらに、受信パケットのグループアドレス及び送信元アドレスに基づき優先度情報を求め、優先順位の一番高いパケットを最優先で前記マルチキャスト用送信バッファから前記パケット転送装置に転送することを特徴とする請求項１に記載のマルチキャストパケット制御装置。
【請求項５】
前記優先度情報は、パケットが廃棄された回数又は廃棄回数に応じた優先順位であることを特徴とする請求項４に記載のマルチキャストパケット制御装置。
【請求項６】
複数のユーザ端末とパケット転送装置がポイント・ツー・ポイントで接続されてマルチキャスト通信が行われるネットワークシステムにおいて、ユーザ端末とパケット転送装置間に配置されパケットの中継を行うマルチキャストパケット制御装置であって、
マルチキャスト通信で用いられるパケットを格納するマルチキャスト用送信バッファと、
マルチキャスト用送信バッファ使用率に対する転送スピード制限情報を記憶し、前記マルチキャスト用送信バッファからパケット転送装置への転送を制限するための転送制限テーブルと、
マルチキャスト用送信バッファ使用率に対するマルチキャスト用送信バッファサイズを記憶し、前記マルチキャスト用送信バッファの使用率に応じてバッファサイズを変更するための送信バッファサイズ変更テーブルと、
グループアドレス及び送信元アドレスを記憶し、受信されたパケットが前記マルチキャスト用送信バッファに格納されたことを記録するための送信バッファ格納テーブルと、
前記転送制限テーブル、前記送信バッファサイズ変更テーブル、前記送信バッファ格納テーブルを参照及び更新し、パケット転送制御を行うためのプロセッサと、
を備え、
前記プロセッサは、受信したパケットが前記パケット転送装置からのマルチキャスト通信のための要求パケットであると判断したとき、該パケットを前記マルチキャスト用送信バッファに転送し、
前記プロセッサは、前記マルチキャスト用送信バッファの使用率を監視し、要求パケットが前記マルチキャスト用送信バッファに転送されるときに、監視された使用率と前記転送制限テーブルに設定されているマルチキャスト用送信バッファ使用率とを比較し、該当する転送スピード制限情報を求め、該転送スピード制限情報に基づき、制限が必要である場合は、前記マルチキャスト用送信バッファから前記パケット転送装置への転送スピード又は転送パケット数に制限をかけ、
前記プロセッサは、前記マルチキャスト用送信バッファの使用率を監視し、
前記プロセッサは、前記制限がかかっているときに要求パケットを受信した場合は、監視したバッファ使用率と、前記送信バッファサイズ変更テーブルに記憶されたマルチキャスト用送信バッファ使用率に基づき、マルチキャスト用送信バッファサイズを求めて、そのサイズに従い、前記マルチキャスト用送信バッファのサイズを変更し、
前記プロセッサは、前記送信バッファ格納テーブルを検索し、受信パケットの前記アドレスが前記送信バッファ格納テーブルにない場合、受信パケットを前記マルチキャスト用送信バッファに格納し、該受信パケットのグループアドレス及び送信元アドレスを前記送信バッファ格納テーブルに記憶し、一方、前記プロセッサは、受信パケットの前記アドレスが前記送信バッファ格納テーブルにある場合、受信パケットを廃棄する、
前記マルチキャストパケット制御装置。
【請求項７】
前記マルチキャスト用送信バッファは、グループアドレスごとに複数のグループアドレス用バッファを備え、
前記送信バッファサイズ変更テーブルは、マルチキャスト用送信バッファ使用率及びマルチキャスト用送信バッファサイズに対して、グループアドレスをさらに記憶し、
前記プロセッサは、前記グループアドレス用バッファの各々の使用率を監視し、
前記プロセッサは、受信パケットのグループアドレスに基づき、監視したバッファ使用率と、前記送信バッファサイズ変更テーブルに記憶されたマルチキャスト用送信バッファ使用率に基づきマルチキャスト用送信バッファサイズを求めて、そのサイズに従い、前記グループアドレス用バッファのサイズを変更することを特徴とする請求項６に記載のマルチキャストパケット制御装置。
【請求項８】
前記マルチキャスト用送信バッファは、グループアドレスごとに複数のグループアドレス用バッファを備え、
前記転送制限テーブルは、マルチキャスト用送信バッファ使用率及び転送スピード制限情報を対して、グループアドレスをさらに記憶し、
前記プロセッサは、前記グループアドレス用バッファの使用率を監視し、応答パケットが前記グループアドレス用バッファに転送されるときに、受信パケットのグループアドレスに基づき、監視された使用率と前記転送制限テーブルに設定されているマルチキャスト用送信バッファ使用率とを比較し、該当する転送スピード制限情報を求め、該転送スピード情報に基づき、制限が必要である場合は、前記グループアドレス用バッファから前記パケット転送装置への転送スピード又は転送パケット数に制限をかけることを特徴とする請求項６に記載のマルチキャストパケット制御装置。
【請求項９】
前記プロセッサは、監視した前記マルチキャスト用送信バッファの使用率が設定値より小さくなったら、前記マルチキャスト用送信バッファから前記パケット転送装置への転送制限を解除することを特徴とする請求項６に記載のマルチキャストパケット制御装置。
【請求項１０】
前記要求パケットは、参加要求パケット又は離脱宣言パケットであることを特徴とする請求項６に記載のマルチキャストパケット制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送などのコンテンツ情報配信に用いられるマルチキャストパケット制御装置に係り、特に応答レポート、参加要求、離脱宣言の転送のためのマルチキャストパケット制御装置に関するものである。
【背景技術】
【０００２】
ブロードバンド化に伴い注目を集めているのが、放送などのコンテンツを配信するためのマルチキャスト技術である。通信用として構築されたＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ネットワーク上で放送サービスを実現するためにＩＰマルチキャスト対応のルータやアクセスサーバを用いることによって効率的な情報配信を行うことが可能となる。特定の複数宛先にデータを配信するマルチキャスト通信に関する技術として、ＩＥＴＦ(Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ)にて、ＩＰｖ４ではＩＧＭＰ(Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍｅｍｂｅｒｓｈｉｐ
Ｐｒｏｔｏｃｏｌ:ＲＦＣ１１１２、ＲＦＣ２２３６)、ＩＰｖ６ではＭＬＤ(Ｍｕｌｔｉｃａｓｔ Ｌｉｓｔｅｎｅｒ Ｄｉｓｃｏｖｅｒｙ:ＲＦＣ２７１０)がＴＣＰ/ＩＰの標準となっている。上記ＩＧＭＰやＭＬＤは、ユーザ端末とゲートウェイ（パケット転送装置（ゲートウェイ、ルータ等）ルータ等との間で使用され、同一のデータを複数のユーザ端末に効率よく配信するマルチキャストで、配信を受けるために構成されるユーザ端末のグループ（マルチキャストグループ）を制御するためのプロトコルである。ユーザ端末がマルチキャストグループに参加要求（マルチキャストデータの配信要求）をしたり、そのマルチキャストグループから離脱宣言（マルチキャストデータの配信停止要求）をしたりする際に、ＩＧＭＰやＭＬＤが使用される。  特定の複数宛先にデータを配信するマルチキャスト通信に関する技術として、あるマルチキャストグループに登録されているユーザ端末からの要求により、コンテンツ配信サーバから情報（コンテンツ）がパケット形式で配信されると、下位のパケット転送装置（ゲートウェイ、ルータ等）がそのパケット情報を受信し、そのパケットをその情報を要求のあったマルチキャストグループに属するユーザ端末数分コピーして、それらのそれらのユーザ端末に転送することにより、コンテンツ配信サービスが行われる。
【０００３】
従来のネットワーク構成では、配信サーバからあるマルチキャストグループに登録されている複数のユーザ端末に対して参加確認パケットが送信されると、そのパケットはマルチキャストルータとユーザ端末間のレイヤ２スイッチでコピーされ各ユーザ端末に送信される。それを受信したユーザ端末は応答レポートパケットを返信する。このとき、ユーザ端末からの応答レポートパケットによってネットワーク上の輻輳を避けるために、ユーザ端末は参加確認パケットを受信したらランダムタイマーをスタートさせ、そのタイマーがゼロになったときに、応答レポートパケットを返信する。最初にあるユーザ端末が応答レポートパケットを返信すると、そのパケットはレイヤ２スイッチでコピーされ同一サブネット内のその他のユーザ端末も受信できる。これを受信したユーザ端末は応答レポートを返信する必要がないと認識し、応答レポートパケットを返信しない。これによって最小限の応答レポートパケットでマルチキャストルータはマルチキャストデータの送信要否が判断できる。
【０００４】
ただし、上記ネットワークではマルチキャストの課金サービス等のユーザ管理やユーザ承認が正確に行えない場合がある。また、マルチキャストデータや応答レポートパケットがレイヤ２スイッチでコピーされ同一サブネット内のユーザ端末に一斉に送信されるため、セキュリティにもあまかった。
そこで近年では、例えば、ユーザ端末とルータ間のアクセス系ネットワークでは物理的にひとつのＬＡＮを仮想的に複数にわけるＶＬＡＮ（Ｖｉｒｔｕａｌ  ＬＡＮ）やＰＰＰｏＥ（Ｐｏｉｎｔ
ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ ｏｖｅｒ  Ｅｔｈｅｒｎｅｔ）を使用し、ユーザ端末とルータはＰｏｉｎｔ  ｔｏ  Ｐｏｉｎｔとなり、ユーザの特定・差別化やユーザごとのセキュリティチェックを可能としている。
【０００５】
【非特許文献１】ＲＦＣ１１１２
【非特許文献２】ＲＦＣ２２３６
【非特許文献３】ＲＦＣ２７１０
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ユーザ管理やセキュリティ確保のために、ＶＬＡＮまたはＰＰＰoＥを使用した場合、ユーザ端末とルータＰｏｉｎｔ  ｔｏ  Ｐｏｉｎｔとなる。このようなネットワーク上でマルチキャスト通信をおこなった場合、マルチキャストルータから参加確認パケットを複数のユーザ端末が受信すると、それらのユーザ端末はランダムな時間経過後に応答レポートパケットを送信する。この場合、各ユーザ端末は他のユーザ端末から応答レポートが送信されたことを認識できないため、マルチキャストルータが同時に大量の応答レポートパケットを受信することになる。従来のネットワークでは必要最小限の応答レポートがマルチキャストルータに送信されマルチキャストルータにも負荷がかからなかったが、本発明が想定している上述のようなネットワークでは、ユーザ端末数分の応答レポートが集中してマルチキャストルータに高負荷がかかり、マルチキャストデータの正常転送ができないという可能性がある。
【０００７】
また、ＩＧＭＰｖ２等では参加確認に対する応答レポートの集中をＭａｘｉｍｕｍ  Ｒｅｓｐｏｎｓｅ  Ｔｉｍｅの値とマルチキャストルータの参加確認の周期を大きくすることである程度分散できるが、周期を大きくしすぎるとマルチキャストルータがユーザ情報の更新をするのに時間がかかり、課金サービスなどのユーザ管理が正確に行いにくくなる場合がある。
同様に、ユーザ端末とルータがＰｏｉｎｔ  ｔｏ  Ｐｏｉｎｔとなるネットワークにおいて、マルチキャストサービス中の停電などによりユーザ端末が一斉にダウンし、その後一斉に復旧したときや、定時一斉放送サービスなどではユーザ端末からマルチキャストルータに参加要求パケットもしくは離脱宣言パケットが同時に大量送信され、マルチキャストルータに高負荷がかかり正常転送が行えない場合が想定される。
【０００８】
本発明の目的のひとつは、以上の点に鑑み、ＶＬＡＮまたはＰＰＰoＥ等を使用してユーザ端末とマルチキャストルータがＰｏｉｎｔ  ｔｏ  Ｐｏｉｎｔでのマルチキャスト通信において、ユーザ端末からマルチキャストルータに向けて応答レポートパケット、参加要求パケット、離脱宣言パケット等のパケットが同時に大量送信された場合でもマルチキャストルータに高負荷をかからないようにすることである。また、本発明の他の目的は、マルチキャストルータが正常なユーザ管理テーブルの更新を行えるようにすることである。
【課題を解決するための手段】
【０００９】
マルチキャストルータからの参加確認に対して、複数のユーザ端末から一斉に応答レポートパケットがマルチキャストルータに向けて返信されたとき、ユーザ端末とマルチキャストルータの間のレイヤ２スイッチでそのまま転送するのではなく、ある一定時間内にマルチキャストルータへ返信される応答レポートパケット数又は転送速度に制限をかける。この場合、制限をかけるとレイヤ２スイッチのマルチキャストルータ側の送信バッファに入りきらない応答レポートパケットは廃棄される。マルチキャストルータはユーザ端末の応答レポートパケットをマルチキャストルータに設定されたある回数だけ連続で受信できない場合に、マルチキャストルータはユーザ管理テーブルからそのユーザ情報を削除するため、連続で廃棄されなければ問題ない。
【００１０】
さらに、上述の場合でユーザ端末数がさらに増えると、あるユーザ端末の応答レポートパケットがレイヤ２スイッチで連続廃棄されて、マルチキャストは誤ってそのユーザ端末の情報をユーザ管理テーブルから削除する可能性が高くなってしまう。これを避けるために、レイヤ２スイッチに応答レポートパケットを廃棄した履歴がわかるようにテーブルを持たせ、一度廃棄したあるユーザの応答レポートパケットは次の参加確認時に優先してマルチキャストルータへ返信するようにすることができる。
廃棄されるパケットがさらに増えてきたら、廃棄履歴テーブルに廃棄された回数を記録し、廃棄された回数が多いユーザの応答レポートパケットから優先してマルチキャストルータへ返信するようにすることができる。
【００１１】
また、マルチキャストルータでは参加確認パケットを送信してから、ユーザ端末からの応答レポートパケットが返信されるまでの時間に制限があるが、ユーザからの参加要求や離脱宣言には時間的制限はないので、参加要求パケットや離脱宣言パケットの場合は別の手段を用いることができる。例えば、複数のユーザ端末が一斉に参加要求パケットや離脱宣言パケットをマルチキャストルータへ送信された場合には、上述と同様にユーザ端末とマルチキャストルータの間のレイヤ２スイッチでそのまま転送するのではなく、ある一定時間内にマルチキャストルータへ送信される参加要求パケット数もしくは離脱宣言パケット数又は転送速度に制限をかけることができる。ここで、例えば、パケットがレイヤ２スイッチで廃棄されないようにレイヤ２スイッチのマルチキャストルータ側送信バッファの使用率がある閾値を超えた場合には送信バッファサイズを大きくすることができる。
【００１２】
さらに、上述の場合でユーザ端末数がさらに増えると、ユーザ端末が参加要求パケットを送信したにもかかわらず、レイヤ２スイッチで参加要求パケットがバッファリングされていてマルチキャストルータには送信されていないとき、ユーザ端末が参加要求をリトライするという可能性がある。この場合は、レイヤ２スイッチで参加要求パケットを受信してマルチキャストルータ側送信バッファに移動させたパケットをテーブルに記録することができる。これによってレイヤ２スイッチがリトライの参加要求パケットを受信した場合にテーブルと比較してマルチキャストルータに送信済と判断しパケットを廃棄することができる。
【００１３】
本発明の第１の解決手段によると、
複数のユーザ端末とパケット転送装置がポイント・ツー・ポイントで接続されてマルチキャスト通信が行われるネットワークシステムにおいて、ユーザ端末とパケット転送装置間に配置されパケットの中継を行うマルチキャストパケット制御装置であって、
マルチキャスト通信で用いられるパケットを格納するマルチキャスト用送信バッファと、
マルチキャスト用送信バッファ使用率に対する転送スピード制限情報を記憶し、前記マルチキャスト用送信バッファから前記パケット転送装置への転送を制限するための転送制限テーブルと、
グループアドレス及び送信元アドレスを記憶し、廃棄したパケットを記録するための廃棄テーブルと、
前記転送制限テーブル及び前記廃棄テーブルを参照及び更新し、パケット転送制御を行うためのプロセッサと、
を備え、
前記プロセッサは、受信したパケットが、前記パケット転送装置からの参加確認に対する応答パケットであると判断したとき、該パケットを前記マルチキャスト用送信バッファに転送し、
前記プロセッサは、前記マルチキャスト用送信バッファの使用率を監視し、応答パケットが前記マルチキャスト用送信バッファに転送されるときに、監視された使用率と前記転送制限テーブルに設定されているマルチキャスト用送信バッファ使用率とを比較し、該当する転送スピード制限情報を求め、該転送スピード制限情報に基づき、制限が必要である場合は、前記マルチキャスト用送信バッファから前記パケット転送装置への転送スピード又は転送パケット数に制限をかけ、
前記プロセッサは、前記制限がかっているときに応答パケットを受信した場合は、前記廃棄テーブルを検索し、
前記プロセッサは、受信パケットのグループアドレス及び送信元アドレスに該当するデータが前記廃棄テーブルにない場合は、その受信パケットを廃棄し、前記廃棄テーブルに該グループアドレス及び送信元アドレスを記録し、
一方、前記プロセッサは、受信パケットのグループアドレス及び送信元アドレスに該当するデータが前記廃棄テーブルにある場合は、その受信パケットを優先して前記マルチキャスト用送信バッファに格納し、前記廃棄テーブルから該グループアドレス及び送信元アドレスに該当するデータを削除する、
前記マルチキャストパケット制御装置が提供される。
【００１４】
本発明の第２の解決手段によると、
複数のユーザ端末とパケット転送装置がポイント・ツー・ポイントで接続されてマルチキャスト通信が行われるネットワークシステムにおいて、ユーザ端末とパケット転送装置間に配置されパケットの中継を行うマルチキャストパケット制御装置であって、
マルチキャスト通信で用いられるパケットを格納するマルチキャスト用送信バッファと、
マルチキャスト用送信バッファ使用率に対する転送スピード制限情報を記憶し、前記マルチキャスト用送信バッファからパケット転送装置への転送を制限するための転送制限テーブルと、
マルチキャスト用送信バッファ使用率に対するマルチキャスト用送信バッファサイズを記憶し、前記マルチキャスト用送信バッファの使用率に応じてバッファサイズを変更するための送信バッファサイズ変更テーブルと、
グループアドレス及び送信元アドレスを記憶し、受信されたパケットが前記マルチキャスト用送信バッファに格納されたことを記録するための送信バッファ格納テーブルと、
前記転送制限テーブル、前記送信バッファサイズ変更テーブル、前記送信バッファ格納テーブルを参照及び更新し、パケット転送制御を行うためのプロセッサと、
を備え、
前記プロセッサは、受信したパケットが前記パケット転送装置からのマルチキャスト通信のための要求パケットであると判断したとき、該パケットを前記マルチキャスト用送信バッファに転送し、
前記プロセッサは、前記マルチキャスト用送信バッファの使用率を監視し、要求パケットが前記マルチキャスト用送信バッファに転送されるときに、監視された使用率と前記転送制限テーブルに設定されているマルチキャスト用送信バッファ使用率とを比較し、該当する転送スピード制限情報を求め、該転送スピード制限情報に基づき、制限が必要である場合は、前記マルチキャスト用送信バッファから前記パケット転送装置への転送スピード又は転送パケット数に制限をかけ、
前記プロセッサは、前記マルチキャスト用送信バッファの使用率を監視し、
前記プロセッサは、前記制限がかかっているときに要求パケットを受信した場合は、監視したバッファ使用率と、前記送信バッファサイズ変更テーブルに記憶されたマルチキャスト用送信バッファ使用率に基づき、マルチキャスト用送信バッファサイズを求めて、そのサイズに従い、前記マルチキャスト用送信バッファのサイズを変更し、
前記プロセッサは、前記送信バッファ格納テーブルを検索し、受信パケットの前記アドレスが前記送信バッファ格納テーブルにない場合、受信パケットを前記マルチキャスト用送信バッファに格納し、該受信パケットのグループアドレス及び送信元アドレスを前記送信バッファ格納テーブルに記憶し、一方、前記プロセッサは、受信パケットの前記アドレスが前記送信バッファ格納テーブルにある場合、受信パケットを廃棄する、
前記マルチキャストパケット制御装置が提供される。
【００１５】
また、本発明は、パケット転送装置からの参加確認に対する複数のユーザ端末の応答レポートが集中したら、そのことを認識しパケット転送装置に転送される応答レポートを制限する手段を有してもよい。
また、本発明は、送信バッファに入りきらないパケットを廃棄する手段を有し、廃棄されたパケットをテーブルに記録することで、廃棄したパケットを次の参加確認時に優先してパケット転送装置に送信する手段を有してもよい。
また、本発明は、廃棄されたパケットのなかでも、廃棄された回数によって優先度をつけ、連続で廃棄されることを避ける手段を有してもよい。
また、本発明は、複数のユーザ端末から同時に参加要求パケット、もしくは離脱宣言パケットが集中したら、そのことを認識しパケット転送装置に送信される参加要求パケット、もしくは離脱宣言パケットを制限する手段を有し、また前記パケット集中時に送信バッファのサイズを動的に変更する手段を有してもよい。
さらに、本発明は、ユーザ端末からの参加要求パケットが再送信された場合にそのパケットを廃棄する手段を有してもよい。
【発明の効果】
【００１６】
本発明によると、ＶＬＡＮやＰＰＰoＥ上でマルチキャスト通信をおこなったとき、ユーザ端末からマルチキャストルータに向けて応答レポートパケット、参加要求パケット、離脱宣言パケット等のパケットが短時間に大量送信された場合でも、マルチキャストルータがある一定時間内に処理しなければならないパケット数が抑えられ、マルチキャストルータに高負荷をかけることなく、かつ正常にマルチキャストサービスが実現できる。
また、本発明によると、マルチキャストサービスごと、つまりグループアドレスごとにＩＧＭＰパケットを処理することでユーザ端末が複数のマルチキャストサービスに参加している場合、もしくは参加しようとしている場合でも、マルチキャストルータに高負荷をかけることなく、かつ正常にマルチキャストサービスが実現でき、各サービス間で優先順位をつけることも可能になる。
本発明によると、新しいプロトコルの導入やユーザ端末に対して新たに機能追加や設定が不要で、ユーザに負担をかけることなく、複数かつ高度なマルチキャストサービスを提供することができる。
【発明の実施の形態】
【００１７】
以下、本発明の実施形態を適宜図面を用いて説明する。以下例ではＩＰｖ４、ＩＧＭＰで説明しているが、本発明は、ＩＰｖ６、ＭＬＤ等の各種方式に適用することができる。なお、ＩＰｖ６、ＭＬＤにおいても基本的な動作は同等であるのでＩＰｖ６、ＭＬＤの例を提示した説明は割愛する。また説明を容易にするために、本発明の各手段を有するマルチキャストパケット制御装置としてレイヤ２スイッチを例に挙げているが、レイヤ２スイッチに限らず、各手段を実装でき、ルータとユーザ端末間に配置されるＢＡＳ（Ｂｒｏａｄｂａｎｄ
Ａｃｃｅｓｓ Ｓｅｒｖｅｒ）やハブのような通信装置であれば装置は選ばない。さらに、ルータを例に挙げているが、これ以外にも、マルチキャスト配信をするものであれば、適宜のパケット転送装置を採用することができる。
【００１８】
１．システム構成
図１に、ネットワーク構成例を示す。
このネットワーク構成例では、ユーザ端末（Ｈ１−１〜Ｈ１−n、Ｈ２−１〜Ｈ２−n）は一旦レイヤ２スイッチ（１００、１０１）に収容され、それぞれアクセスネットワーク（ＮＷ１、ＮＷ２）を介してＩＳＰ網（ＮＷ３）内にあるルータ（Ｒｏｕｔｅｒ）（２００）を介してインターネット（３００）やコンテンツ配信サーバ（Ｓ１、Ｓ２）等に接続される。なおユーザ端末（Ｈ１−１〜Ｈ１−n、Ｈ２−１〜Ｈ２−n）とルータ（２００）の間は、ＶＬＡＮやＰＰＰoＥ、ＰＰＰoＡ等で接続される。
図２は、ＩＧＭＰパケットの流れを示した図である。
ユーザ端末（Ｈ１−１〜Ｈ１−ｎ）とルータ（２００）間はＶＬＡＮやＰＰＰoＥ、ＰＰＰoＡ等でＰｏｉｎｔ  ｔｏ  Ｐｏｉｎｔ接続となっている（Ｌ１〜Ｌ３）。ユーザ端末（Ｈ１−１〜Ｈ１−ｎ）は、あらかじめコンテンツ配信業者と契約しており、マルチキャストグループ（例えば、グループアドレス２２４．１０．１０．１０）に参加する資格を有している。なお、ここでは、各ユーザ端末（Ｈ１−１〜Ｈ１−ｎ）には、一例として、ＭＡＣアドレス００−００−８７−１１−１１−１１、００−００−８７−２２−２２−２２、００−００−８７−ｎｎ−ｎｎ−ｎｎがそれぞれ与えられているものとする。コンテンツ配信サーバ（Ｓ１）はルータ（２００）を介して各ユーザ端末（Ｈ１−１〜Ｈ１−ｎ）がマルチキャストデータの配信を希望しているかどうかを定期的に確認する。このときルータ（２００）はコンテンツ配信サーバ（Ｓ１）に代わって各ユーザ端末（Ｈ１−１〜Ｈ１−ｎ）の情報を集約する。ルータ（２００）は各ユーザ端末（Ｈ１−１〜Ｈ１−ｎ）に向けて参加確認パケット（５０１−１〜５０１−n）を送信する。これに対しユーザ端末（Ｈ１−１〜Ｈ１−ｎ）はマルチキャストデータの配信継続を希望する場合はルータ（２００）へ応答レポートパケット（６０１−１〜６０１−n）を返信する。ルータ（２００）はこれらの応答レポートパケット（６０１−１〜６０１−n）を受信することで各ユーザ端末（Ｈ１−１〜Ｈ１−ｎ）がマルチキャストデータの配信継続を希望していることを把握する。
【００１９】
図３に、本実施の形態におけるレイヤ２スイッチ（１００）の内部構成図を示す。
このレイヤ２スイッチは複数の入出力回線の回線インタフェース（１００−１−ｉ）（ここで、ｉ＝１〜ｎ）と、回線インタフェース（１００−１−ｉ）の制御を行う回線インタフェース制御部（１００−２）、パケットの解析などの処理を行うプロセッサ（１００−３）、プロセッサ（１００−３）が処理を行うために使用するメモリ（１００−４）、外付けの制御端末（１００−６）とのインタフェースを行う制御端末インタフェース（１００−５）、回線インタフェース（１００−１−ｉ）を経由し送受信するパケットを一時的に格納する送受信バッファ（１００−７）を備える。さらに、送受信バッファ（１００−７）は、送信バッファ（１００−７−１）、受信バッファ（１００−７−２）、ＩＧＭＰ用送信バッファ（１００−７−３）を有する。また、メモリ（１００−４）には、プロセッサが実行するプログラム（１００−４−５）、ユーザ端末（Ｈ１−１〜Ｈ１−ｎ）からルータ（２００）に向けて送信されるＩＧＭＰパケットの転送に制限をかける転送制限テーブル（１００−４−１）、廃棄したパケットを記録する廃棄テーブル（１００−４−２）、ＩＧＭＰ送信バッファ（１００−７−３）のサイズを変更する送信バッファサイズ変更テーブル（１００−４−３）、ＩＧＭＰ送信バッファ（１００−７−３）に移動したパケットを記録しておく送信バッファ格納テーブル（１００−４−４）が格納されている。
【００２０】
図４は、各ユーザ端末（Ｈ１−１〜Ｈ１−ｎ）とルータ（２００）間でやりとりされるＩＧＭＰメッセージのヘッダ（５００）の構成を示す図である。
ＲＦＣ１１２１、２２３６に記載されているように、ＩＧＭＰメッセージのヘッダ（５００）はＴｙｐｅ（５００−１）、Ｍａｘｉｍｕｍ  Ｒｅｓｐｏｎｓｅ  Ｔｉｍｅ（５００−２）、Ｃｈｅｃｋｓｕｍ（５００−３）、Ｇｒｏｕｐ  Ａｄｄｒｅｓｓ（５００−４）の各フィールドを有する。Ｔｙｐｅ（５００−１）はＩＧＭＰメッセージタイプの種別を示し、この内容により、ＩＧＭＰメッセージが参加確認パケット、応答レポートパケット、離脱宣言パケットのいずれかを表すメッセージなのかを識別できる。なお、参加要求パケットはＴｙｐｅ（５００−１）の内容が応答レポートパケットと同じになる。ユーザ端末は参加確認パケットを受信してから、Ｍａｘｉｍｕｍ  Ｒｅｓｐｏｎｓｅ  Ｔｉｍｅ（５００−２）に設定している値だけ待ってから応答レポートを返信する。
【００２１】
次に、メモリ（１００−４）の各テーブルについて説明する。
図５は、ルータ（２００）が持っているユーザ管理テーブル（２００−１）の説明図である。各データは、グループアドレス（２００−１−１）、ユーザ端末ＩＰアドレス（２００−１−２）、ポート（２００−１−３）、連続応答なし回数（２００−１−４）を含む。ルータはある一定時間ごとにテーブルにあるユーザ端末宛てに参加確認をおこないその応答レポート、もしくはユーザ端末からの参加要求、離脱宣言によってこのテーブルを更新している。ルータ（２００）は応答レポートによってテーブルを更新する場合、一般的にユーザ管理精度を上げるために複数回連続でユーザ端末からの応答がなかった場合に、そのユーザ情報をテーブルから削除する。
【００２２】
図６は、転送制限テーブル（１００−４−１）の詳細な説明図である。
各データは、ＩＧＭＰ用送信バッファ使用率（１００−４−１−２）、転送スピード制限（１００−４−１−３）を含む。ＩＧＭＰ用送信バッファ（１００−７−３）の使用率がＩＧＭＰ用送信バッファ使用率（１００−４−１−２）の設定値に応じてレイヤ２スイッチ（１００）からルータ（２００）に転送されるＩＧＭＰパケットが制限される（詳細は後述）。
図７及び図８は、廃棄テーブル（１００−４−２）の詳細な説明図である。
各データは、グループアドレス（１００−４−２−１）、送信元ＭＡＣアドレス（１００−４−２−２）、廃棄回数（１００−４−２−３）及び／又は優先度（１００−４−２−４）を含む優先度情報を含む。このテーブルには、ＩＧＭＰ用送信バッファ（１００−７−３）にはいりきらずに破棄されたパケットの送信元ＭＡＣアドレス（１００−４−２−２）と廃棄回数（１００−４−２−３）を記録し、次のルータ（２００）からの参加確認時に廃棄したパケットを優先してＩＧＭＰ送信バッファ（１００−７−３）に移動させる。図８はさらに廃棄回数（１００−４−２−３）が増えた場合に優先度（１００−４−２−１）があげられ、これにより、当該グループアドレス及び送信元アドレスのパケットを優先的にＩＧＭＰ用送信バッファ（１００−７−３）に移動させることを表している（詳細は後述）。なお、優先度情報は、優先度による制御を行わない場合は省略できる。
【００２３】
図９は、送信バッファサイズ変更テーブル（１００−４−３）の詳細な説明図である。
各データは、ＩＧＭＰ用送信バッファ使用率（１００−４−３−２）、ＩＧＭＰ用送信バッファサイズ（１００−４−３−３）を含む。ＩＧＭＰ用送信バッファ（１００−７−３）の使用率がＩＧＭＰ用送信バッファ使用率（１００−４−３−２）の設定値をこえるとＩＧＭＰ用送信バッファ（１００−７−３）のサイズを大きくし、パケットが廃棄されないようにする（詳細は後述）。
図１０は、送信バッファ格納テーブル（１００−４−４）の詳細な説明図である。
各データは、グループアドレス（１００−４−４−１）、送信元ＭＡＣアドレス（１００−４−４−２）を含む。このテーブルには、受信バッファからＩＧＭＰ用送信バッファ（１００−７−３）に格納されたパケットのこれらのアドレスを記録しておく（詳細は後述）。
【００２４】
２．動作概要
図１５は、通常時のＩＧＭＰ用送信バッファを示す図である。この図は、受信バッファ（１００−７−２）からＩＧＭＰ用送信バッファ（１００−７−３）にＩＧＭＰパケットが転送され、ルータ（２００）へＩＧＭＰパケットが送信されることを表している。
図１６は、使用率があがったＩＧＭＰ用送信バッファを示す図である。この図は、図１５の状態からさらにＩＧＭＰパケットが増え、ＩＧＭＰ用送信バッファ（１００−７−３）の使用率が送信バッファサイズ変更テーブル（１００−４−３）で設定している閾値（１００−４−１−２）に達して、ルータ（２００）へ転送されるＩＧＭＰパケットが制限されていることを表している。
図１７は、ＩＧＭＰ用送信バッファの使用率が高くて、パケットが廃棄される様子を示す図である。この図は、図１６の制限が続くことで、受信バッファ（１００−７−２）から転送されてくるＩＧＭＰパケットがＩＧＭＰ用送信バッファ（１００−７−３）にはいりきらなくなり廃棄されている様子を表している。
図１８は、優先的にＩＧＭＰ用送信バッファに転送する様子を示す図である。この図は、図１７と同様に制限がかかっている状態で、受信バッファ（１００−７−２）に優先したいパケットがあった場合に、優先パケットをＩＧＭＰ用送信バッファ（１００−７−３）に転送していることを表している。
【００２５】
３．動作シーケンス
図１１は、ルータ（２００）からの参加確認とそれに対するユーザ端末（Ｈ１−１〜Ｈ１−ｎ）の応答レポートが一斉に返信された場合のシーケンス図である。
図１２は、ユーザ端末（Ｈ１−１〜Ｈ１−ｎ）から一斉に参加要求もしくは離脱宣言された場合のシーケンス図である。
図１３は、レイヤ２スイッチ（１００）がユーザ端末（Ｈ１−１〜Ｈ１−ｎ）から応答レポートパケットを受信したときの処理フローチャートである。
図１４は、レイヤ２スイッチ（１００）がユーザ端末（Ｈ１−１〜Ｈ１−ｎ）から参加要求パケットもしくは離脱宣言パケットを受信したときの処理フローチャートである。
【００２６】
３−１．  実施の形態１  （応答レポートが一斉に送信された場合）
まず、ルータ（２００）からの参加確認に対してユーザ端末（Ｈ１−１〜Ｈ１−ｎ）から応答レポートパケットが一斉に返信されたときのレイヤ２スイッチ（１００）の動作について説明する。
ルータ（２００）がユーザ端末（Ｈ１−１〜Ｈ１−ｎ）に向けて参加確認パケットを一斉送信する（５０１−１〜５０１−ｎ）とそれに対してユーザ端末（Ｈ１−１〜Ｈ１−ｎ）が一斉に応答レポートを返信する（６０１−１〜６０１−ｎ）。応答レポートパケットはレイヤ２スイッチ（１００）の回線インタフェース（１００−１）に到着し、回線インタフェース制御部（１００−２）に転送される。回線制御インタフェース部（１００−２）は、受信したパケットを受信バッファ（１００−７−２）に転送するとともに、プロセッサ（１００−３）に対しパケットを受信したことを通知するための割り込みを上げる。割り込みを受け取ったプロセッサ（１００−３）は、受信バッファ（１００−７−２）からパケットを読み出し、図１３のフローに従ってパケットを処理する。
まず、レイヤ２スイッチ（１００）のプロセッサ（１００−３）は、受信したパケットがＩＧＭＰパケットかどうかを判断する（９００）。ＩＧＭＰパケットでなければ、プロセッサ（１００−３）は、そのパケットを通常通り送信バッファ（１００−７−１）に転送する（９０１）。ＩＧＭＰパケットのときは、同様に制限なく送信バッファ（１００−７−１）に転送してしまうとルータ（２００）にＩＧＭＰパケットが集中してルータ（２００）に負荷がかかってしまう。これを避けるために、プロセッサ（１００−３）は、ＩＧＭＰパケットをＩＧＭＰ用送信バッファ（１００−７−３）に転送する。またプロセッサ（１００−３）は、ＩＧＭＰ用送信バッファ（１００−７−３）の使用率を監視していて（９０８）、ＩＧＭＰパケットがＩＧＭＰ用送信バッファ（１００−７−３）に転送されるときに、この使用率と転送制限テーブル（１００−４−１）に設定されている使用率（１００−４−１−２）を比較し、ＩＧＭＰパケットのＩＧＭＰ送信バッファ（１００−７−３）からルータ（２００）への転送パケット数又は転送スピードに制限をかけるか否かを判断する（９０２）。このとき、プロセッサ（１００−３）は、ＩＧＭＰ送信バッファ使用率（１００−４−２）を検索し、これを監視により得た使用率と比較して、該当する転送スピード制限（１００−４−１−３）を求める。プロセッサ（１００−３）は、制限が必要な場合は、ＩＧＭＰ用送信バッファ（１００−７−３）からルータ（２００）への転送スピードを制限し、一方、制限が必要ない場合はそのままＩＧＭＰ用送信バッファ（１００−７−３）からルータ（２００）に転送する（９０３）。
【００２７】
制限がかっている（８００）ときに、受信したＩＧＭＰパケットが送信バッファ（１００−７−３）に入りきらない場合（６０１−２）、プロセッサ（１００−３）が廃棄テーブル（１００−４−２）を検索して（８０１）そのパケットを優先すべきかどうかを判断する（９０４）。このとき、プロセッサ（１００−３）は、受信パケットのグループアドレス及び送信元ＭＡＣアドレスに基づき、廃棄回数（１００−４−２−３）及び／又は優先度（１００−４−２−４）を検索する。廃棄テーブル（１００−４−２）に該当データがない場合は、そのパケットは廃棄され（９０５）、廃棄テーブル（１００−４−２）に廃棄したことが記録される（８０２）。すなわち、そのパケットのグループアドレス（１００−４−２−１）、送信元ＭＡＣアドレス（１００−４−２−２）、廃棄回数（１００−４−２−３）、優先度（１００−４−２−４）が記録される。プロセッサ（１００−３）は、転送制限テーブル（１００−４−１）を参照し、ＩＧＭＰ用送信バッファ（１００−７−３）の使用率（１００−４−１−２）が設定値より小さくなったら（９０７）転送制限を解除する（８０３）。なお、ステップ９０７で、プロセッサ（１００−３）が制限必要であると判断すると、プロセッサ（１００−３）は使用率を確認する（９０８）。
【００２８】
ユーザ端末（Ｈ１−１〜Ｈ１−ｎ）からの応答レポートがレイヤ２スイッチ（１００）で一部廃棄されてルータ（２００）に転送されると（６１１−１、６１１−ｎ）、ルータ（２００）は、転送された応答レポートに従い、ユーザ管理テーブル（２００−１）を更新する。すなわち、グループアドレス（２００−１−１）、ユーザ端末ＩＰアドレス（２００−１−２）、ポート（２００−１−３）、連続応答なし回数（２００−１−４）を更新する。ただし、ルータ（２００）は、破棄されたてしまったユーザ情報を一回の参加確認ではユーザ管理テーブル（２００−１）からは削除しない（８０４）。
ルータ（２００）からの二回目又はそれ以降の参加確認がユーザ端末（Ｈ１−１〜Ｈ１−ｎ）に向けて送信されると（５０２−１〜５０２−ｎ）、一回目と同様にユーザ端末（Ｈ１−１〜Ｈ１−ｎ）は応答レポートを返信する（６０２−１〜６０２−ｎ）。レイヤ２スイッチ（１００）がこれらの応答レポートを受信すると、一回目と同様に図１３のフローに従って処理する。ここで、転送制限がされているとすると（８０５）、プロセッサ（１００−３）は、パケットのグループアドレスと送信元ＭＡＣアドレスに基づき、廃棄テーブル（１００−４−２）内を検索する（８０６）。このとき一回目の参加確認時に廃棄したＩＧＭＰパケットがあった場合に、受信バッファ（１００−７−２）から優先してＩＧＭＰ用送信バッファ（１００−７−３）に転送する（９０６）。転送したら廃棄テーブル（１００−４−２）からパケット情報を削除して更新する（８０７）。
これによって、一回目で廃棄されたＩＧＭＰパケットが優先してルータ（２００）に転送される（６１２−２）。そして、ルータ（２００）は、ユーザ管理テーブル（２００−１）から一回目に廃棄されたユーザ情報を削除することなくユーザ管理テーブル（２００−１）を更新することができる（８０９）。
【００２９】
また、応答レポートを返信するユーザ端末が増えた場合に一回目と二回目の参加確認時に連続で廃棄されてしまうことが考えられる。この場合には、図８の廃棄テーブル（１００−４−２）のように廃棄されたパケットのなかでも廃棄回数により優先順位をつけることができる。このとき、プロセッサ（１００−３）は、受信パケットのグループアドレス及び送信元ＭＡＣアドレスに基づき、廃棄回数（１００−４−２−３）をカウントアップし、それに応じて優先度（１００−４−２−４）を記録する。そして、プロセッサ（１００−３）は、受信したパケットのグループアドレス及びＭＡＣ送信元アドレスに基づき、廃棄テーブル（１００−４−２）を検索し、優先度（１００−４−２−４）又は廃棄回数（１００−４−２−３）に従い、転送の優先順位を判断する。なお、廃棄回数（１００−４−２−３）又は優先度（１００−４−２−４）のいずれかを省略してもよい。また、優先順位をつけない場合は、廃棄回数（１００−４−２−３）及び優先度（１００−４−２−４）のデータを省略することができる。これによって三回目の参加確認時には二回連続で廃棄されたパケットが最優先でルータ（２００）に転送されるため、ルータ（２００）が誤ってユーザ管理テーブル（２００−１）からユーザ情報を削除してしまうことを避けられる。
【００３０】
また、プロセッサ（１００−３）は、転送制限が解除されてからある一定時間経過すると廃棄テーブル（１００−４−２）を初期化する（８１０）。
このような手段により、参加確認の周期や回数を大きく変更することなくかつルータ（２００）に高負荷をかかることを避けられるため、ユーザ端末（Ｈ１−１〜Ｈ１−ｎ）が一斉に応答レポートを返信してもルータ（２００）はユーザ管理テーブル（２００−１）の正常更新ができ、マルチキャストデータの正常転送も行える。なお、送信元ＭＡＣアドレス以外にも、ＩＰアドレス等の適宜の送信元アドレスを用いてもよい。
【００３１】
３−２．  実施の形態２  （参加要求、離脱宣言が一斉に送信された場合）
次に、ルータ（２００）からの参加確認とは関係なく複数のユーザ端末（Ｈ１−１〜Ｈ１−ｎ）から参加要求もしくは離脱宣言が一斉に送信された場合について説明する。
ユーザ端末（Ｈ１−１〜Ｈ１−ｎ）から参加要求が一斉に送信されると（６０５−１〜６０５−ｎ）、上述の手段と同様に図１４のフローに従ってパケットを処理する（９００〜９０３）。このとき、上述と同様に、プロセッサ（１００−３）は、転送制限テーブル（１００−４−１）を参照し、監視された使用率と比較して、制限が必要か否か判断する（９０２）。パケットが集中した場合はＩＧＭＰ用送信バッファ（１００−７−３）からルータ（２００）へのパケット転送に制限がかけられる（８２０）。また、ＩＧＭＰパケットがＩＧＭＰ用送信バッファ（１００−７−３）にはいりきらないことで廃棄されてしまわないように、プロセッサ（１００−３）は、送信バッファサイズ変更テーブル（１００−４−３）に従ってＩＧＭＰ用送信バッファ（１００−７−３）のサイズを大きくする（８２１）。このとき、プロセッサ（１００−３）は、監視した使用率と、テーブル内のＩＧＭＰ用送信バッファ使用率（１００−４−３−２）とを比較し、該当するＩＧＭＰ用送信バッファサイズ（１００−４−３−３）を定める。
【００３２】
次にプロセッサ（１００−３）が送信バッファ格納テーブル（１００−４−４）内を検索して（８２２）、受信バッファ（１００−７−２）からＩＧＭＰ用送信バッファ（１００−７−３）に転送済みかを判断する（９２２）。このとき、プロセッサ（１００−３）は、受信したパケットのグループアドレス及び送信元ＭＡＣアドレスに基づき、該当するデータが送信バッファ格納テーブル（１００−４−４）に記憶されていれば転送済み、記憶されていなければ未転送と判断する。受信パケットが未転送ならばＩＧＭＰ用送信バッファ（１００−７−３）に転送され（９２３）、プロセッサ（１００−３）が転送されたグループアドレス及び送信元ＭＡＣアドレスを含むパケット情報を送信バッファ格納テーブル（１００−４−４）に記録してテーブルを更新する（８２３、９２４）。
ＩＧＭＰ用送信バッファ（１００−７−３）に転送されたＩＧＭＰパケットは転送スピードが制限されている（８２０）ものの、ルータ（２００）に確実に転送される（６１５−１〜６１５―ｎ）。これらを受信したルータ（２００）は、ユーザ管理テーブル（２００−１）を更新し、参加を受け付け（８２４）、ユーザ管理テーブル（２００−１）をもとにマルチキャストデータの配信を開始する（７０５−１、７０５−ｎ）。
【００３３】
ここで、ルータ（２００）でのユーザ登録処理を分散させているのでユーザ数が増えてくると参加要求はしたもののマルチキャストデータの配信が開始されずに、参加要求をリトライする（６０６−２）ユーザ端末（Ｈ１−２）がでてくる可能性がある。この場合、そのユーザ端末（Ｈ１−２）の参加要求パケットは時間はずれるものの、ルータ（２００）に転送され（６１１−２）参加を受け付けられる（８２５）。そのため、参加要求のリトライ（６０６−２）をレイヤ２スイッチ（１００）が受信した場合、図１４のフローに従いプロセッサ（１００−３）が送信バッファ格納テーブル（１００−４−４）内を検索して（８２２）、該当するパケット情報がテーブルにあるのでＩＧＭＰ用送信バッファ（１００−７−３）に当該パケットが既に格納済みであると判断し（９２０）、該パケットを廃棄する（８２７）。参加が受け付けられればユーザ端末（Ｈ１−２）にもマルチキャストデータの配信が開始される（７０５−２）。
またプロセッサ（１００−３）はＩＧＭＰ用送信バッファ（１００−７−３）の使用率を監視していて（９２２）、設定値（１００−４−１−２）より小さくなったら（９２３）転送制限を解除する（８２８）。転送制限を解除していからある一定時間が経過するとプロセッサ（１００−３）は送信バッファ格納テーブル（１００−４−４）とＩＧＭＰ用送信バッファサイズ（１００−４−３−３）を初期化する（８２９、８３０）。
以上は、参加要求の場合を記述したが離脱宣言の場合も、レイヤ２スイッチ（１００）の処理としては同じである。
【００３４】
３−３．  実施の形態３  （グループアドレスごとに制限をかける場合）
図１９は、ＩＧＭＰ用送信バッファ（１００−７−３）をグループアドレスごとに分割（１００−７−３−１〜１００−７−３−ｎ）した場合を表している。
図２０は、図６の転送制限テーブル（１００−４−１）に複数のグループアドレス（１００−４−１−１）を設定した場合の詳細である。グループアドレス（１００−４−１−１）ごとにＩＧＭＰ用送信バッファ使用率（１００−４−１−２）、転送スピード制限（１００−４−１−３）の設定値をかえることができる。
図２１は、図９の送信バッファサイズ変更テーブル（１００−４−３）に複数のグループアドレス（１００−４−３−１）を設定した場合の詳細である。グループアドレス（１００−４−３−１）ごとにＩＧＭＰ用送信バッファ使用率（１００−４−３−２）、ＩＧＭＰ用送信バッファサイズ（１００−４−３−３）の設定値をかえることができる。
【００３５】
以下に、実施の形態１において、転送制限処理をグループアドレスごとに行った場合について説明する。
レイヤ２スイッチ（１００）のＩＧＭＰ用送信バッファ（１００−７−３）を図１９のようにグループアドレスごとにわける。レイヤ２スイッチ（１００）がＩＧＭＰパケットを受信し、プロセッサ（１００−３）がＩＧＭＰ用送信バッファ（１００−７−３）に転送する際に、パケットのグループアドレス（５０４）部をチェックし、そのグループアドレス用のＩＧＭＰ用送信バッファ（１００−７−３−１〜１００−７−３−ｎ）に転送する。このときに転送制限テーブル（１００−４−１）を図２０のようにグループアドレスごとに設定する。プロセッサ（１００−３）が転送制限をかけるとき、受信パケットのグループアドレスに基づき転送制限テーブル（１００−４−１）のグループアドレス（１００−４−１−１）に対する使用率（１００−４−１−２）を求め、その使用率と監視した使用率とを比較し、該当する転送スピード（１００−４−１−３）を求める。プロセッサ（１００−３）は、この転送スピードに従ってグループアドレスごとにＩＧＭＰ用送信バッファ（１００−７−３−１〜１００−７−３−ｎ）に転送制限をかける。その他の処理、フローは実施の形態１と同様に行う。
実施の形態２において、ＩＧＭＰ用送信バッファ（１００−７−３）のサイズ変更をグループアドレスごとに行った場合について説明する。上記と同様に、レイヤ２スイッチ（１００）のＩＧＭＰ用送信バッファ（１００−７−３）を図１９のようにグループアドレスごとにわけ、プロセッサ（１００−３）がグループアドレス用のＩＧＭＰ用送信バッファ（１００−７−３−１〜１００−７−３−ｎ）に転送する。このとき送信バッファサイズ変更テーブル（１００−４−３）を図２１のようにグループアドレスごとに送信バッファサイズを設定する。プロセッサ（１００−３）が、受信パケットのグループアドレスに基づき送信バッファサイズ変更テーブル（１００−４−３）のグループアドレス（１００−４−３−１）に対する使用率（１００−４−３−２）を求め、その使用率と監視した使用率と比較し、該当するＩＧＭＰ用送信バッファサイズ（１００−４−３−３）を求める。プロセッサ（１００−３）は、このバッファサイズに従って、グループアドレスごとにＩＧＭＰ用送信バッファ（１００−７−３−１〜１００−７−３−ｎ）のサイズを変更する。その他の処理、フローは実施の形態２と同様に行う。
このような手段によって、マルチキャストサービスが複数になりユーザ端末（Ｈ１−１〜Ｈ１−ｎ）から一斉に送信されるＩＧＭＰパケットのグループアドレスが複数になっても、サービスごと（グループアドレスごと）に制限がかけることができ、ルータ（２００）への負荷が低減でき、かつサービスごとに優先順位をつけることもできる。
【産業上の利用可能性】
【００３６】
本発明は、ＩＰｖ６、ＭＬＤ等の各種方式に適用することができる。また、本発明は、レイヤ２スイッチに限らず、各手段を実装でき、ルータとユーザ端末間に配置されるＢＡＳ（Ｂｒｏａｄｂａｎｄ
Ａｃｃｅｓｓ Ｓｅｒｖｅｒ）やハブのような通信装置であれば装置は選ばない。さらに、本発明は、ルータ以外にも、マルチキャスト配信をするものであれば、適宜のパケット転送装置を採用することができる。
【図面の簡単な説明】
【００３７】
【図１】本実施の形態のネットワーク構成例を示す図
【図２】本実施の形態におけるマルチキャストパケットの流れを示す図
【図３】本発明のレイヤ２スイッチの内部構成の一例
【図４】ＩＧＭＰメッセージフォーマット
【図５】ユーザ管理テーブルの一例
【図６】転送制限テーブルの一例
【図７】廃棄テーブルの一例
【図８】廃棄テーブルの一例
【図９】送信バッファサイズ変更テーブルの一例
【図１０】送信バッファ格納テーブルの一例
【図１１】応答レポートが集中した場合のシーケンス例
【図１２】参加要求もしくは離脱宣言が集中した場合のシーケンス例
【図１３】レイヤ２スイッチが応答レポートを受信したときに処理フローの例
【図１４】レイヤ２スイッチが参加要求もしくは離脱宣言を受信したときの処理フローの例
【図１５】通常時のＩＧＭＰ用送信バッファを示す図
【図１６】使用率があがったＩＧＭＰ用送信バッファを示す図
【図１７】ＩＧＭＰ用送信バッファの使用率が高くて、パケットが廃棄される様子を示す図
【図１８】優先的にＩＧＭＰ用送信バッファに転送する様子を示す図
【図１９】ＩＧＭＰ用送信バッファをグループアドレスごとに分けた場合を示す図
【図２０】転送制限テーブルに複数のグループアドレスを設定した場合を示す図
【図２１】送信バッファサイズ変更テーブルに複数のグループアドレスを設定した場合を示す図
【符号の説明】
【００３８】
Ｈ１−１〜Ｈ１〜ｎ、Ｈ２−１〜Ｈ２〜ｎ：ユーザ端末
１００、１０１：レイヤ２スイッチ
１００−１〜１００−ｎ：回線インターフェース
１００−２：回線インターフェース制御部
１００−３：プロセッサ
１００−４：メモリ
１００−４−１：転送制限テーブル
１００−４−２：廃棄テーブル
１００−４−３：送信バッファサイズ変更テーブル
１００−４−４：送信バッファ格納テーブル
１００−４−５：プログラム
１００−５：制御端末インターフェース
１００−６：制御端末
１００−７：送受信バッファ
１００−７−１：送信バッファ
１００−７−２：受信バッファ
１００−７−３：ＩＧＭＰ用送信バッファ
２００：ルータ
２００−１：ユーザ管理テーブル
３００：インターネット
Ｓ１、Ｓ２：コンテンツ配信サーバ
ＮＷ１、ＮＷ２：アクセスネットワーク
Ｌ１〜Ｌ３：仮想ネットワーク
５０１−１〜５０１−ｎ、５０２−１〜５０２−ｎ：参加確認パケット
６０１−１〜６０１−ｎ、６０２−１〜６０２−ｎ、６１１−１〜６１１−ｎ、６１２−１〜６１２−ｎ：
応答レポートパケット、参加要求パケット、離脱宣言パケット
７０１−１〜７０１−ｎ：マルチキャストデータ
【図１】
0004673752.tif 000002
【図２】
0004673752.tif 000003
【図３】
0004673752.tif 000004
【図４】
0004673752.tif 000005
【図５】
0004673752.tif 000006
【図６】
0004673752.tif 000007
【図７】
0004673752.tif 000008
【図８】
0004673752.tif 000009
【図９】
0004673752.tif 000010
【図１０】
0004673752.tif 000011
【図１１】
0004673752.tif 000012
【図１２】
0004673752.tif 000013
【図１３】
0004673752.tif 000014
【図１４】
0004673752.tif 000015
【図１５】
0004673752.tif 000016
【図１６】
0004673752.tif 000017
【図１７】
0004673752.tif 000018
【図１８】
0004673752.tif 000019
【図１９】
0004673752.tif 000020
【図２０】
0004673752.tif 000021
【図２１】
0004673752.tif 000022