JP5827664B2 - マルチキャスティングの要求、マルチキャスティング要求の処理、および前記プロセスの補助のための、方法およびデバイス - Google Patents

Description

本発明は、マルチキャストの分野に関し、より詳細には、エニーソースマルチキャスト（ＡＳＭ）に基づくマルチキャストソース中でマルチキャストデータの送信を要求するための方法および装置、ランデブーポイント（ＲＰ）において対応するマルチキャスト送信要求を処理するための方法および装置、ならびに転送デバイス中でＲＰとマルチキャストソースとの間の対話を補助するための方法および装置に関する。

ＩＰユニキャストとは異なり、ＩＰマルチキャストの宛先アドレスは、クラスＤアドレスとも呼ばれる２２４．０．０．０から２３９．２５５．２５５．２５５までの範囲のグループアドレスである。これは、動的に割振りおよび返還される、ある種の一時アドレスである。あらゆるマルチキャストグループは、動的に割り振られたクラスＤアドレスに対応する。マルチキャストグループのマルチキャストが終了したとき、対応するクラスＤアドレスは、後のマルチキャストのためにリサイクルされる。

現実のネットワーク中でマルチキャストデータパケット転送を実施するためには、相互接続された全てのデバイスが、相互運用可能なマルチキャストルーティングプロトコルを実行しなければならない。マルチキャストルーティングプロトコルは、インターネットグループ管理プロトコル（ＩＧＭＰ）、稠密モードプロトコル（例えばＤＶＭＲＰ、ＰＩＭ−ＤＭ）、希薄モードプロトコル（例えばＰＩＭ−ＳＭ、ＣＢＴ）、およびリンク状態ルーティングプロトコル（ＭＯＳＰＦ）に分けられる。

ここで、マルチキャストルーティングの鍵は、マルチキャストグループごとにマルチキャストツリーを確立することであり、マルチキャストツリーは、種々のマルチキャストプロトコルに従って相互に異なる。現在、ソースマルチキャストツリーと共有ツリーという２つのマルチキャストツリー構築技法がある。

ソースマルチキャストツリーは、マルチキャストソースから構築されるマルチキャストツリーであり、マルチキャストソースが稠密でありマルチキャストデータの量が多い場合に適する。

共有ツリーは、ＲＰを介してマルチキャストグループの各メンバへと構築されるマルチキャストツリーであり、マルチキャストソースは、マルチキャスティングのために関連情報をＲＰに送信する。共有ツリーは、マルチキャストソースが希薄でありマルチキャストデータの量が少ない場合に、ルータのルーティング情報交換のコストを削減するのに適する。現在、一般的な希薄モードのマルチキャストルーティングプロトコルは、希薄モードのＰＩＭ−ＳＭ（プロトコル独立マルチキャスト希薄モード）プロトコルである。

本発明は、以下の技術的問題に対する改革に基づいて提案するものである。

マルチキャストアドレスは、マルチキャストソースとオペレータとの交渉の後でＤＨＣＰサーバなどの専用サーバによって割り振られ、このマルチキャストアドレスが他のマルチキャストソースによっても使用されているかどうかはマルチキャストソースにはわからない。しかし、ＡＳＭに基づくマルチキャスト方式では、異なるマルチキャストグループが同じマルチキャストツリー（共有ツリーとも呼ばれる）を共有し、マルチキャストツリーのルートノードとしてのＲＰが、これらのマルチキャストグループのためにマルチキャストデータをブランチおよびリーフに転送するタスクを担う。ＲＰがマルチキャストソースのマルチキャスト送信要求を制御せず、単にマルチキャスト送信要求の受信後に送信を許可するだけである場合、その制限されたマルチキャスト転送能力は、おそらく、より重い負荷に耐えられる余裕はほとんどなく、したがって、新しいマルチキャストソースまたは新しいマルチキャストサービスが加わるせいで、正常に実施されたマルチキャストサービスのデータパケット転送が妨げられ、これはユーザ体験に影響を及ぼす。

本発明の少なくとも１つの実施形態によれば、ＡＳＭに基づくＲＰにおいて、マルチキャストソースからマルチキャスト送信要求を受信したとき、ＲＰは、マルチキャスト送信要求とＲＰ中の残りの転送リソースとに従って、マルチキャストソースのマルチキャスト送信要求を処理する。

ここで、マルチキャスト転送能力は、ハードウェア処理能力やネットワーク伝送能力などを含む。具体的には、ネットワーク伝送能力は、対応可能なマルチキャストソースの数、マルチキャストサービスの数、または総帯域幅によって反映される。

マルチキャスト送信要求は、来るべきマルチキャストサービスの記述、例えば帯域幅要件やサービスのタイプなどを搬送することができるので、ＲＰは、割振り可能な帯域幅に基づいて要求を処理することができる。

ここで、ＲＰは、各マルチキャストグループに対応する帯域幅を別々に制御することができ、あるマルチキャストグループがその占有できる帯域幅を使い果たした後は、たとえ他のマルチキャストグループに事前割振りされた利用可能な帯域幅がある場合でも、このマルチキャストグループを指す新しいマルチキャスト送信要求はもはや許可されない。

任意選択で、各マルチキャストグループは、ＲＰ中の総マルチキャスト帯域幅を共有することができる。すなわち、あるマルチキャストグループのサービスがビジーのとき、このマルチキャストグループは、総帯域幅のうちの多くの量を占有することができ、負荷の軽い他のマルチキャストグループは、それらの要件に従って残り帯域幅のうちの少量のみを占有する。マルチキャストサービスの終了後、対応する帯域幅は、後続のマルチキャスト送信要求がどの特定のマルチキャストグループを指しているかにかかわらず、後続のマルチキャスト送信要求のために解放される。

任意選択で、ＲＰは、各マルチキャストグループに対するマルチキャストソース数の上限を有するように構成することができ、したがって、あるマルチキャストグループにマルチキャストデータを転送しているマルチキャストソースの数がこの上限に達したときは、このマルチキャストグループにマルチキャストデータを送信するための新しい要求は拒否される。

任意選択で、ＲＰは、全てのマルチキャストグループに対するマルチキャストソース数の総上限を有するように構成することができ、したがって、ＲＰがマルチキャストデータを転送しているマルチキャストソースの数がこの上限に達したときは、どんな新しいマルチキャスト送信要求も拒否される。

本発明の第１の態様によれば、ＡＳＭに基づくＲＰ中で、マルチキャストソースのマルチキャスト送信要求を処理する方法であって、少なくとも１つのマルチキャストアドレスへのマルチキャストデータの送信を要求するためのマルチキャスト送信要求を前記マルチキャストソースから受信するステップと、前記マルチキャスト送信要求および前記ＲＰ中の残りのマルチキャスト転送リソースに従って、マルチキャストソースの前記マルチキャスト送信要求を処理するステップとを含む方法が提供される。

本発明の第２の態様によれば、ＡＳＭに基づく転送デバイス中で、ＲＰとマルチキャストソースとの間のシグナリング対話を補助する方法であって、前記マルチキャストソースから来た、少なくとも１つのマルチキャストアドレスを示すマルチキャスト送信要求を受信すること、および、前記少なくとも１つのマルチキャストアドレスのそれぞれにつき、前記マルチキャストソースに代わって、マルチキャストアドレスに対応するＲＰに、マルチキャストアドレスへのマルチキャストデータの送信を要求することを含む方法が提供される。

本発明の第３の態様によれば、ＡＳＭに基づくマルチキャストソース中で、マルチキャストデータの送信を要求する方法であって、少なくとも１つのマルチキャストアドレスを示すユニキャスト用マルチキャスト送信要求を生成すること、および、前記少なくとも１つのマルチキャストアドレスに対応する転送デバイスまたはＲＰに前記マルチキャスト要求を送信することを含む方法が提供される。

本発明の第４の態様によれば、ＡＳＭに基づくマルチキャストソース中で、マルチキャストデータの送信を要求する方法であって、マルチキャストアドレスを示し、マルチキャストアドレスへのマルチキャストデータの送信をマルチキャストソースが要求するのを表す、マルチキャスト用マルチキャスト送信要求を生成すること、および、マルチキャスト用マルチキャスト送信要求をマルチキャストアドレスに送信することを含む方法が提供される。

本発明の第５の態様によれば、マルチキャストソースのマルチキャスト送信要求を処理するための、ＡＳＭに基づくＲＰ中の第１の装置であって、少なくとも１つのマルチキャストアドレスへのマルチキャストデータの送信を要求するためのマルチキャスト送信要求を前記マルチキャストソースから受信するための第１の受信手段と、前記マルチキャスト送信要求および前記ＲＰ中の残りのマルチキャスト転送リソースに従って、マルチキャストソースのマルチキャスト送信要求を処理するための処理手段とを備える、第１の装置が提供される。

本発明の第６の態様によれば、ＲＰとマルチキャストソースとの間のシグナリング対話を補助するための、ＡＳＭに基づく転送デバイス中の第２の装置であって、少なくとも１つのマルチキャストアドレスを示すマルチキャスト送信要求を前記マルチキャストソースから受信するための第２の受信手段と、前記少なくとも１つのマルチキャストアドレスのそれぞれにつき、前記マルチキャストソースに代わって、マルチキャストアドレスに対応するＲＰに、マルチキャストアドレスへのマルチキャストデータの送信を要求する要求手段とを備える、第２の装置が提供される。

本発明の第７の態様によれば、マルチキャストデータの送信を要求するための、ＡＳＭに基づくマルチキャストソース中の第３の装置であって、少なくとも１つのマルチキャストアドレスを示すユニキャスト用マルチキャスト送信要求を生成するための第１の生成手段と、前記少なくとも１つのマルチキャストアドレスに対応する転送デバイスまたはＲＰに前記マルチキャスト要求を送信するための第２の送信手段とを備える、第３の装置が提供される。

本発明の第８の態様によれば、マルチキャストデータの送信を要求するための、ＡＳＭに基づくマルチキャストソース中の第４の装置であって、マルチキャストアドレスを示し、マルチキャストアドレスへのマルチキャストデータの送信をマルチキャストソースが要求するのを表す、マルチキャスト用マルチキャスト送信要求を生成するための第２の生成手段と、マルチキャストソースのマルチキャスト要求をマルチキャストアドレスに送信するための第３の送信手段とを備える、第４の装置が提供される。

ＲＰによってそのリソースの状況に従って実施される、マルチキャスト送信要求の妥当な制御によって、本発明により提供される方法および装置を使用するとき、ＲＰのハードウェア処理負荷およびポートトラフィック負荷を適切な範囲内に効果的に維持することができ、それによりリソースの浪費を回避することができる。また、既存のまたは重要なサービスに対する新しいマルチキャストサービスの悪影響も回避することができ、それによりユーザのサービス体験を保証することができる。

本発明の他の特徴および利点は、非限定的な実施形態に関する後続の詳細な記述を添付の図面と共に読めばより明らかになるであろう。図面において、同一または同様の参照符号は、同一または同様の手順特徴または装置（モジュール）特徴を示す。

ＡＳＭに基づくＩＰネットワークの概略図である。 本発明の一実施形態による、ＡＳＭマルチキャストソースがマルチキャストデータの送信を要求する方法のフローチャートである。 本発明の別の実施形態による、ＡＳＭマルチキャストソースがマルチキャストデータの送信を要求する方法のフローチャートである。 本発明のさらに別の実施形態による、ＡＳＭマルチキャストソースがマルチキャストデータの送信を要求する方法のフローチャートである。 本発明の一実施形態による、ＡＳＭに基づくＲＰがマルチキャスト送信要求を処理する方法のフローチャートである。 本発明の一実施形態による、図３ａに示すステップＳ３２の詳細なフローチャートである。 本発明の別の実施形態による、図３ａに示すステップＳ３２の詳細なフローチャートである。 本発明のさらに別の実施形態による、図３ａに示すステップＳ３２の詳細なフローチャートである。 本発明のさらに別の実施形態による、図３ａに示すステップＳ３２の詳細なフローチャートである。 本発明の一実施形態による、マルチキャスト送信要求を処理するための、ＡＳＭに基づくＲＰ中の第１の装置のブロック図である。 本発明の一実施形態による、図４ａの処理手段の内部ブロック図である。 本発明の別の実施形態による、図４ａの処理手段の内部ブロック図である。 本発明のさらに別の実施形態による、図４ａの処理手段の内部ブロック図である。 本発明のさらに別の実施形態による、図４ａの処理手段の内部ブロック図である。 本発明の一実施形態による、ＲＰとマルチキャストソースとの対話を補助するための、ＡＳＭに基づく転送デバイスＡＳＭ中の第２の装置のブロック図である。 本発明の一実施形態による、マルチキャストデータの送信を要求するための、ＡＳＭに基づくマルチキャストソース中の第３の装置のブロック図である。 本発明の一実施形態による、マルチキャストデータの送信を要求するための、ＡＳＭに基づくマルチキャストソース中の第４の装置のブロック図である。

本発明の非限定的な各実施形態について、添付の図面に関連して以下に詳細に述べる。

図１は、ＡＳＭに基づくＩＰネットワークの概略図である。明確にするために本発明に関連のある部分のみが図示されているが、省略部分は、既存のまたは後に開発される技法と共に当業者によって実現することができ、そのような省略は本発明の十分な開示に影響しないことを理解されたい。加えて、当業者には理解されるように、図面に示すあらゆる種類のネットワークデバイスの数は、以下の記述の要件を満たすために過ぎず、本発明に対するどんな限定もなさない。

図１に示すように、ラップトップなどのマルチキャストソース１が、家庭ネットワーク中のモデムなどのデバイスを介してＩＰネットワークに接続する。図１にはまた、ＰＩＭ−ＳＭまたはＢＩＤＩＲ−ＰＩＭプロトコルに基づく２つのルータ２１および２２を示すが、これらのルータは、１つまたは複数のマルチキャストグループの指定転送デバイスＤＦ（または転送ルータＤＲ）として事前に選ばれるものであり、以下ではこれらをそれぞれ転送デバイス２１および転送デバイス２２と呼ぶ。マルチキャストアドレスＤ１の転送デバイス（マルチキャストグループＧ１に属する）が転送デバイス２１であって、Ｄ１に対応するＲＰがＲＰ３である場合、転送デバイス２１は、そのユーザ側から来た、Ｄ１を指すマルチキャストデータおよびシグナリングを、さらに次の転送に向けてＲＰ３に送信することを担う。同様に、転送デバイス２１はまた、そのネットワーク側から来た、Ｄ１を指すマルチキャストデータおよびシグナリングを、ユーザ側の、マルチキャストグループＧ１に加わった各ＩＰ端末に送信することを担う。

前述の転送を実施するために、本発明の少なくとも１つの実施形態によれば、転送デバイス２１は、ユニキャストＩＰアドレスなど、マルチキャストアドレスＤ１に対応するＲＰ３の通信アドレスを事前に記憶する。転送デバイス２１が複数のマルチキャストグループの指定転送デバイスとして選ばれているときは、これら全てのマルチキャストグループに対応するＲＰの通信アドレスを記憶することが好ましい。これは転送デバイス２２についても同じであり、したがってここではこれ以上繰り返さない。

ここで、マルチキャストソース１などのＩＰ端末に（場合によっては間接的に）接続するための、転送デバイスの側を、本明細書ではそのユーザ側と呼ぶ。反対に、ＲＰに（場合によっては間接的に）接続するための、転送デバイスの他方の側を、本明細書ではそのネットワーク側と呼ぶ。このような記述は、より読みやすくするために用いるに過ぎず、本発明に基づく転送デバイスに対するどんな限定もなさない。

図１では、明確にするために、マルチキャストソース１（ＩＰ端末）と転送デバイスとの間の接続０１、転送デバイスとＲＰ３との間の接続０２、および、ＲＰ３とＩＰ端末４１、４２、４３との間の接続０３を、点線を使用して表す。省略したどんな接続も、有線、無線リンク、およびルータなどのネットワークデバイスで構成することができ、そのような省略は本発明の十分な開示に影響しないことを、当業者は理解されたい。ここで、接続０３は通常、転送デバイス２１、２２と同様の機能を有する転送デバイスを含む。

本明細書では、マルチキャストソース１によって開始されるマルチキャスト送信要求について主に述べる。手順全体は、マルチキャスト送信要求の送信と、マルチキャスト送信要求の処理という２つの部分に分けることができる。詳細には以下のとおりである。

１）マルチキャスト送信要求の送信
以下では、図１に示すようにマルチキャストソース１がマルチキャストデータをマルチキャストアドレスＤ１への送信を要求する場合を例とし、マルチキャストアドレスＤ１は、ＲＰ３に対応する。言い換えれば、ＲＰ３は、マルチキャストグループＧ１のマルチキャストツリーのルートノードである。図２ａ−２ｃを参照すると、マルチキャストソース１によって送信されたマルチキャスト要求がＲＰに到達するための３つの方法が記述されている。

１．１）マルチキャストソース１は、マルチキャストアドレスＤ１に対応するＲＰのＩＰアドレスを知っている
図２ａを参照すると、マルチキャストソース１のユーザは、マルチキャストデータをマルチキャストアドレスＤ１に送信することについてオペレータとの合意に達すると、Ａ１をユニキャストＩＰアドレスとするＲＰ３にマルチキャストアドレスＤ１が対応することを通知される。

したがって、マルチキャストアドレスＤ１へのマルチキャストデータの送信を要求するために、ステップＳ２０で、マルチキャストソース１は、宛先アドレスがＲＰ３のユニキャストＩＰアドレスであるユニキャストＩＰパケットを生成することが好ましい。マルチキャストアドレスＤ１がパケット中の事前定義済み位置に書き込まれ、これはＤ１へのマルチキャストデータの送信を要求することを表す。次いで、ステップＳ２１で、マルチキャスト送信要求は送信される。

したがって、ＩＰプロトコルにおける開発されたルーティング方式に基づいて、マルチキャスト送信要求は、一連の転送によってＲＰ３に到達する。ＲＰ３は、事前定義済み位置を解析することによって、マルチキャストソース１がどのマルチキャストアドレスにマルチキャストデータを送信しようとしているのかを知ることができる。

マルチキャストソース１によって生成されたマルチキャスト送信要求はまた、Ｄ１が占有したい帯域幅の量（マルチキャストアドレスＤ１に対応する必要帯域幅とも呼ばれる）をも示すことが好ましい。

マルチキャストソース１がマルチキャストデータを複数のマルチキャストアドレスに送信したいときであって、マルチキャストソース１がこれら全てのマルチキャストアドレスの対応ＲＰのＩＰアドレスを知っている場合は、同じＲＰに対応するマルチキャストアドレスを同じユニキャスト用マルチキャスト送信要求に書き込むことができ、生成した各マルチキャスト送信要求を対応するＲＰに送信することができることを、当業者は理解されたい。各マルチキャスト送信要求は、対応するマルチキャストアドレスの対応する必要帯域幅を含むことが好ましい。

１．２）マルチキャストソース１は、マルチキャストアドレスＤ１に対応するＲＰを知らないが、Ｄ１に対応する転送デバイスが転送デバイス２１であることは知っている。

図２ｂを参照されたい。この場合、ステップＳ２２で、マルチキャストソース１はやはりユニキャスト用マルチキャスト送信要求を生成するが、その中の宛先アドレスは、転送デバイス２１のユニキャストアドレスに変わる。ステップＳ２３で、生成されたマルチキャスト送信要求は送信され、次いで転送デバイス２１に到達する。

マルチキャスト送信要求の中のマルチキャストアドレスＤ１を解析し、次いでマルチキャストアドレスとＲＰとの間の事前記憶済みマッピング情報に照会することによって、転送デバイス２１は、マルチキャストアドレスＤ１に対応するＲＰ、すなわちＲＰ３を正確に決定することができ、ステップＳ２３で、マルチキャストソース１に代わってＤ１へのマルチキャストデータの送信をＲＰ３に要求することができる。一般性を失うことなく、例えば、ステップＳ２３で、転送デバイス２１は、受信したマルチキャスト送信要求の中の宛先アドレスを、照会されたＲＰ３のＩＰアドレスに変更し、次いで、ソースアドレスがＤ１である要求をＲＰ３に転送する。転送されるマルチキャスト送信要求はまた、例えばマルチキャストソース１のＩＰアドレスを事前定義済み位置に書き込むことによって、要求の開始元がマルチキャストソース１であることも示すことが好ましい。

マルチキャストソース１によって生成されたマルチキャスト送信要求にはまた、Ｄ１が占有したい帯域幅（マルチキャストアドレスＤ１に対応する帯域幅要件とも呼ばれる）が記されていることが好ましい。

マルチキャストソース１がＤ１−Ｄ３など複数のマルチキャストアドレスにマルチキャストデータを送信したい場合は、マルチキャストソース１は、これらの各マルチキャストアドレスに対応する転送デバイスをそれぞれ照会することができ、好ましくは、同じ転送デバイスに対応するマルチキャストアドレスを、同じユニキャスト用マルチキャスト送信要求の中に書き込んで、これを対応する転送デバイスに送信する。例えば、Ｄ１とＤ２が両方とも転送デバイス２１に対応し、Ｄ３が転送デバイス２２に対応し、したがって２つのユニキャスト用マルチキャスト送信要求が生成される。すなわち、第１のユニキャスト用マルチキャスト送信要求はＤ１およびＤ２を示し、その宛先アドレスは転送デバイス２１のＩＰアドレスである。第２のユニキャスト用マルチキャスト送信要求はＤ３を示し、その宛先アドレスは転送デバイス２２のＩＰアドレスである。次いで、各転送デバイスは、各マルチキャストアドレスに対応するＲＰを照会し、好ましくはまた、同じＲＰに対応するマルチキャストアドレスを、転送すべき同じマルチキャスト送信要求の中に配置して、これを対応するＲＰに送信する。各マルチキャスト送信要求は、対応マルチキャストアドレスに対応する必要帯域幅を含むことが好ましい。

１．３）マルチキャストソース１は、マルチキャストアドレスＤ１に対応するＲＰも知らず、Ｄ１がどの転送デバイスに対応するかも知らない。

図２ｃを参照されたい。この場合、マルチキャストソース１は、ステップＳ２５で、マルチキャスト送信要求として、宛先アドレスがＤ１であるマルチキャストパケットを生成する。ＰＩＭ−ＳＭまたはＢＩＤＩＲ−ＰＩＭプロトコルなど、ＡＳＭのプロトコルに従って、ステップＳ２６で送信される宛先アドレスがＤ１であるマルチキャストパケットは、マルチキャストグループＧ１の指定転送デバイス、すなわち転送デバイス２１にルーティングされる。図２ｃ中の点線を特に使用して、マルチキャストパケットが転送デバイス２２には到達しないことを示す。

次のステップＳ２７で、転送デバイス２１は、マルチキャストソース１に代わって、マルチキャストアドレスＤ１へのマルチキャストデータの送信をＲＰ３に要求する。正確な方式は、例えば、まず転送デバイス１が事前記憶済みマッピング情報に照会して、マルチキャストアドレスＤ１に対応するＲＰ、すなわちＲＰ３を見つけ、次いで、ＲＰ３のＩＰアドレスを宛先アドレスとする新しいユニキャスト用マルチキャスト送信要求を生成し、マルチキャストアドレスＤ１を特定のフィールド（その位置および機能は当然ながら各ＲＰにわかっているはずである）に書き込むものである。各マルチキャスト送信要求は、対応するマルチキャストアドレスの対応する必要帯域幅を含むことが好ましい。

マルチキャスト送信要求の送信方式を以上に紹介した。どのような方式でマルチキャスト送信要求がマルチキャストソースによってＲＰに送信されるかは、本発明の保護の範囲を必ずしも限定せず、本発明は、ＲＰによって実施される、マルチキャストソースによって開始された要求の制御およびフィルタリングについての考察をより重視することを理解されたい。これについて以下により詳細に述べる。

図３ａは、本発明の一実施形態による、ＡＳＭに基づくＲＰがマルチキャスト送信要求を処理する方法のフローチャートであり、この方法は主にステップＳ３１およびＳ３２を含む。ステップＳ３１で、図１に示したＲＰ３などのＲＰが、図１に示したマルチキャストソース１などのマルチキャストソースからマルチキャスト送信要求を受信し、次いでステップＳ３２で、マルチキャスト送信要求および残りのマルチキャスト転送リソースに従って、マルチキャスト送信要求を処理する。ここで、ステップＳ３１の実施については上述してあり、以下では主にステップＳ３２を紹介する。

ステップＳ３２の実施は、マルチキャスト送信要求がＲＰ３に到達する方式に依存しない。というのは、どの手段によるかにかかわらず、ＲＰ３には、どのマルチキャストソースがマルチキャスト送信要求を開始しているか、およびそのマルチキャストソースがどのマルチキャストグループにマルチキャストデータを送信したいかがわかるからである。

すでに上述したように、有効な各マルチキャストアドレスは、シグナリングおよびマルチキャストデータを転送するための対応するマルチキャストツリーのルートノードとして、対応するＲＰを有し、したがって本発明は、ある時点でマルチキャストアドレスとＲＰとの間のマッピング関係が変化するような、特別な場合を考慮することが好ましい。例えば、ＲＰ３に対応するマルチキャストアドレスＤ５が今や、追加のＲＰに対応するように変更される。各ＲＰは新しいマッピング関係を適時に知っているにもかかわらず、転送デバイスまたはマルチキャストソースは、適時に更新されていない場合があり、そのため、元々知っていたマッピング関係に従ってマルチキャスト送信要求を送信する場合がある。この結果、マルチキャスト送信要求は、誤ったＲＰに不適切に送信されることがある。例えば、Ｄ５へのマルチキャストデータの送信を要求するマルチキャスト送信要求が、依然としてＲＰ３に送信されてしまう。この場合、ＲＰ３は、マルチキャスト要求応答をマルチキャストソース１に返す（直接に、または対応する転送デバイスによって転送される）ことが好ましく、このマルチキャスト要求応答は、ＲＰ３がもはやＤ５に対応するＲＰではないことを示し、また好ましくは、マルチキャストソース１が別のマルチキャスト送信要求を開始し直すことができるように、追加のＲＰのＩＰアドレスも示す。

ＲＰ３はまた、シグナリング交換を省くために、マルチキャスト送信要求を追加のＲＰに転送することもできることが好ましい。

以下では、マルチキャスト送信要求が正しいＲＰに送信される場合に焦点を合わせる。図３ｂ−３ｅに示す、ステップＳ３２のいくつかの実装形態について、以下のように考察する。

マルチキャストデータ転送に利用可能な残りの総帯域幅を考慮する。

この場合の原理として、ＲＰ３に対応する全てのマルチキャストアドレスが、ＲＰ３中のマルチキャストデータ転送に利用可能な帯域幅を共有し、マルチキャスト転送のための帯域幅の対応する上限が各マルチキャストアドレスに対して個別に設定されることはない。言い換えれば、ＲＰ３がＤ１およびＤ２に対応し、ＲＰ３によるマルチキャストデータ転送に利用可能な帯域幅がＤ１のマルチキャストサービスによって完全に占有される、といった場合もあり得る。

図１および図２と共に、図３ｂを参照されたい。ここでは、ステップＳ３２１で、ＲＰ３はまず、マルチキャスト送信要求に従って、各マルチキャストアドレスに対応する必要帯域幅を決定する。すでに上述したように、マルチキャストソース１は、各マルチキャストアドレスに対応する必要帯域幅をマルチキャスト送信要求の中に書き込むことができ、したがってＲＰ３は、ステップＳ３２１で必要帯域幅を得ることができ、それにより、マルチキャストソース１がマルチキャストアドレスＤ１へのマルチキャストデータの送信に使用したい帯域幅の量を知ることができる。この場合、マルチキャストソース１が、マルチキャストデータをＤ１に送信するために１５０ｋｂｐｓを使用したいと仮定する。

次いで、次のステップＳ３２２で、ＲＰ３は、マルチキャストデータ転送に利用可能な残り帯域幅がマルチキャストソース１の要求を満たせるかどうか判定する。例えば、データを転送するためのＲＰ３のポートにおける総帯域幅は１０Ｍｂｐｓであり、このうち１Ｍｂｐｓがマルチキャストデータ転送用である。したがって、ＲＰ３は、必要帯域幅１５０ｋｂｐｓがこのような１Ｍｂｐｓの残り以下かどうか判定し、これに基づいてステップＳ３２２の判定が得られる。

前述の１Ｍｂｐｓのうち、すでに８００ｋｂｐｓがマルチキャストデータ転送に使用されている、すなわち２００ｋｂｐｓが残っていると仮定する。１５０ｋｂｐｓは２００ｋｂｐｓよりも少ないので、ステップＳ３２２では肯定判定が得られる。次いでステップＳ３２３に進み、マルチキャストソース１は、マルチキャストアドレスＤ１にマルチキャストデータを送信するのをＲＰ３によって許可される。

ステップＳ３２３は、多くの方式で実施することができる。一般性を失うことなく、ＲＰ３は、マルチキャストソース１がマルチキャストアドレスＤ１にマルチキャストデータを送信できることを示すマルチキャスト要求応答を生成し、さらに、ＲＰ３はまた、その事前記憶済みのアクティブなマルチキャストソースのリストを更新して、マルチキャストソース１を、マルチキャストアドレスＤ１に対応する許可済みマルチキャストソースまたはアクティブなマルチキャストソースとして追加し、好ましくは、１５０ｋｂｐｓの帯域幅情報を、マルチキャストソース１に対するマルチキャストアドレスＤ１の属性情報とする。

したがって、ＲＰ３におけるマルチキャスト転送に利用可能な残り帯域幅は、５０ｋｂｐｓ（２００ｋｂｐｓ−１５０ｋｂｐｓ）のみである。新しいマルチキャスト送信要求があった場合は、５０ｋｂｐｓを用いて、対応する必要帯域幅と比較することになる（上のＳ３２２に関する記述を参照されたい）。

マルチキャストソース１がＲＰ３の許可を得た後の動作については、現行のマルチキャストプロトコルに詳細に明記されており、本明細書では詳述しない。

マルチキャストソース１によって要求されたＤ１に対応する必要帯域幅が、ＲＰ３におけるマルチキャスト転送に利用可能な残り帯域幅を超過し、例えば３００ｋｂｐｓである場合、ＲＰ３の後続の動作は様々である。以下のものに限定されないがこれらの動作には、ＲＰ３が単純に、マルチキャスト送信要求を拒否し、マルチキャストソース１に他の情報を提供しないこと、ＲＰ３が、Ｄ１に対応する必要帯域幅を更新して新しいマルチキャスト送信要求を開始するようマルチキャストソース１に指示すること、ＲＰ３が、マルチキャストソース１に対して新しい適切な必要帯域幅を提案して、マルチキャストソース１が提案された必要帯域幅を使用して新しいマルチキャスト送信要求を開始したときにはＲＰ３からの許可が得られることを基本的に保証することが含まれる。

図３ｂを参照すると、ステップＳ３２５は、マルチキャストソース１が１つのマルチキャストアドレスのみに対して要求を開始する場合に、より適する。例えば、ＲＰ３は、マルチキャスト転送用の残り帯域幅２００ｋｂｐｓに従ってマルチキャスト要求応答を生成するが、このマルチキャスト要求応答を使用して、マルチキャストソース１に、１５０ｋｂｐｓを新しい必要帯域幅としてマルチキャスト送信要求を開始し直すといった指示が提供される。任意選択で、ＲＰ３は、この一時的に失敗した要求を記録し、新しい要求を開始するためのいくらかの期間をマルチキャストソース１に与えることができる。理解しやすいように、この期間を「猶予期間」と呼ぶことができ、この期間内では、他のマルチキャストソースから来たマルチキャスト要求は処理が遅延されることになるが、マルチキャストソース１から来た新しいマルチキャスト送信要求は、より高い優先順位を享受することができる。猶予期間が切れると、他のマルチキャストソースからのマルチキャスト送信要求は、マルチキャストソース１からの要求と平等に扱われることになる。この場合、ステップＳ３２５に記されている第１の数は１である。

図３ｂで、マルチキャストソース１が、複数のマルチキャストアドレス、例えばＤ１およびＤ２に対してマルチキャスト送信要求を開始する場合を考えてみる。ステップＳ３２２で、ＲＰ３２２は、各マルチキャストアドレスの対応する必要帯域幅を加算することによって合計を得て、この合計を、２００ｋｂｐｓなど、マルチキャストデータ転送に利用可能な残り帯域幅と比較する。前者が後者以下である場合は、ステップＳ３２３に進み、マルチキャストソース１のこの要求を許可する。反対に、この合計が２００ｋｂｐｓよりも大きい場合は、ステップＳ３２４とステップＳ３２５は両方とも適切な選択であり、これらのステップをそれぞれ以下のように紹介する。

ステップＳ３２４：Ｄ１とＤ２の対応する帯域幅要件が両方とも１５０ｋｂｐｓであると仮定する。したがってＲＰ３は、これらから任意の１つ、マルチキャストアドレスＤ１などを選択し、Ｄ１へのマルチキャストデータの送信をマルチキャストソース１に許可する。特に、例えば、ＲＰ３は、マルチキャスト要求応答をマルチキャストソース１に送信して、マルチキャストアドレスＤ１の要求が許可されることを通知し、また、ＲＰ３自体によって事前に記憶されたアクティブなマルチキャストソースのテーブルを、Ｄ１に対応するアクティブなマルチキャストソースとしてマルチキャストソース１を追加することによって、かつ好ましくは、１５０ｋｂｐｓを、マルチキャストソース１およびＤ１に関係するテーブルの項目とすることによって更新する。このようなテーブルに書き込まれた帯域幅の値は、ＲＰ３がマルチキャストデータ転送用の残り帯域幅を計算するための重要な根拠として使用することができる。ＲＰ３がマルチキャストデータ転送のみを担う場合、ＲＰ３はまた、その対応するポートにおけるトラフィックを監視することによって、どれくらいの残り帯域幅が利用可能かを知ることができ、したがって、このようなアクティブなマルチキャストソースのテーブル中で残りの利用可能帯域幅を調べる必要はない。

ステップＳ３２５：ステップＳ３２４に対する代替として、マルチキャストデータ転送に利用可能な残り帯域幅を総必要帯域幅が超過するとき、ＲＰ３は、この２つのマルチキャストアドレスＤ１、Ｄ２のうちの第１の数に対する必要帯域幅を更新するよう、マルチキャストソース１に指示することができる。この場合、第１の数は値１または２を有する。詳細については上記の紹介を参照することができ、したがってここではこれ以上述べない。

上の例の一変形によれば、マルチキャスト送信要求は、各マルチキャストアドレスに対応する必要帯域幅を含まない。したがって、ＲＰ３は、マルチキャストソース１が開始したいマルチキャスト送信によって占有されることになる帯域幅を、マルチキャストアドレスの位置するアドレスセグメントに従って推定する。当然、この推定は、アドレスセグメントとマルチキャストサービスとの関係に依存する。別法として、アドレスセグメントとマルチキャストサービスタイプとの関係がない場合は、適切な推定帯域幅ＢをＲＰ３に対して構成することができる。いずれかのマルチキャストソースがいずれかのマルチキャストアドレスへのマルチキャストデータの送信を要求するとき、ＲＰ３は常に、消費されることになる帯域幅をＢと見なして、後続のステップＳ３２２での判定の助けとする。

前述のアクティブなマルチキャストソースのテーブルに対して、本発明では、時間しきい値が設定されることが好ましい。この時間しきい値は、例えば以下のように機能する。すなわち、マルチキャストソース１がＤ１に対応するアクティブなマルチキャストソースであると仮定すると、ＲＰ３は、マルチキャストソース１からＤ１に送信されたマルチキャストパケットを最後に受信したときからタイマを開始する。時間しきい値内でマルチキャストソース１からＤ１へのマルチキャストパケットがもはや受信されない場合は、マルチキャストソース１はもはやＤ１に対応するアクティブなマルチキャストソースではないと判定されることになり、ＲＰ３は、Ｄ１に対応するアクティブなマルチキャストソースからマルチキャストソース１を削除することになる。マルチキャストソース１が、他のマルチキャストアドレスに対応するアクティブなマルチキャストソースでもあった場合は、ＲＰ３は、Ｄ１における時間切れによって、これら他のマルチキャストアドレスに対応するアクティブなマルチキャストソースからマルチキャストソース１を削除することはしないことが好ましい。

各マルチキャストアドレスへのマルチキャストデータ転送に使用できる残り帯域幅を考慮する。

図３ｃを参照すると、図３ｂに示した場合との主要な違いの１つは、ＲＰ３において、マルチキャストデータを対応するマルチキャストアドレスに転送するのに利用可能な帯域幅の上限が、ＲＰ３に対応する各マルチキャストアドレスに対してそれぞれ設定されることにある。典型的には、総計１０Ｍｂｐｓの帯域幅のうちの１Ｍｂｐｓがマルチキャストデータ転送に利用可能であって、そのうちの３００ｋｂｐｓがマルチキャストアドレスＤ１に割り振られ、７００ｋｂｐｓが残っていると仮定する。当然、ＲＰ３に対応する他のマルチキャストアドレスがある場合、１Ｍｂｐｓの帯域幅の割振りは異なる可能性がある。

したがって、マルチキャストアドレスＤ１およびＤ２はもはや、総計１Ｍｂｐｓのマルチキャスト帯域幅を動的に共有しないことになる。マルチキャストアドレスＤ１を指すサービス要件が急に増大したとき、マルチキャストアドレスＤ１に対応する必要帯域幅が３００ｋｂｐｓを超過することが起こり得るが、このときは、この場合の規則に従って、ＲＰ３は、たとえＤ２によって占有されていない帯域幅がいくらか残っていたとしても、Ｄ２に事前に割り振られた７００ｋｂｐｓの帯域幅の一部をＤ１に与えることはしない。

上記の原理に基づいて、ＲＰ３において、Ｄ１の３００ｋｂｐｓの帯域幅のうち１００ｋｂｓが残っており、Ｄ２の７００ｋｂｐｓの帯域幅のうち６００ｋｂｐｓが残っていると仮定する。図３ｃに示すフローチャートは、マルチキャストソース１によって要求される各マルチキャストアドレスにつき実行される。マルチキャストアドレスＤを例にとると、ステップＳ３２１で、ＲＰ３は、１５０ｋｂｐｓなど、Ｄ１に対応する必要帯域幅をマルチキャスト送信要求メッセージから抽出する。

必要帯域幅１５０ｋｂｐｓは、Ｄ１へのマルチキャストデータの転送に利用可能な残り帯域幅１００ｋｂｐｓよりも大きいので、ステップＳ３２２’で否定判定が得られ、したがってステップＳ３２５’に入る。ステップＳ３２５’で、マルチキャストアドレスＤ１に対応する必要帯域幅を更新するよう指示する。詳細な手順については、前述のステップＳ３２５の内容を参照することができる。

反対に、Ｄ１に対応する必要帯域幅が、Ｄ１へのマルチキャストデータの転送に利用可能な残り帯域幅以下である場合は、ＲＰ３は、Ｄ１へのマルチキャストデータの送信をマルチキャストソース１に許可し、その事前記憶済みのアクティブなマルチキャストソースのテーブルを更新し、好ましくは、対応する必要帯域幅を、テーブル中のマルチキャストソース１とＤ１との両方に関係する項目とすることになる。

マルチキャストデータを特定のマルチキャストアドレスに転送するときの、サポート可能なマルチキャストソースの数を考慮する。

図３ｄを参照すると、図３ｂ−３ｃとは異なり、この場合、マルチキャストソース１のマルチキャスト送信要求が許可されるか否かを判定するための制限条件として、マルチキャストソースの数が使用される。詳細には次のとおりである。

ＲＰ３において、対応する各マルチキャストアドレス（Ｄ１およびＤ２など）につき、マルチキャストソースの上限数が設定される。例えば、ＲＰ３は、マルチキャストデータを、多くても３つのマルチキャストソースのためにＤ１に転送し、多くても５つのマルチキャストソースのためにＤ２に転送する。Ｄ１へのマルチキャストデータの送信を要求するマルチキャスト送信要求をマルチキャストソース１から受信したとき、ＲＰ３は、事前に記憶され継続的に更新されるアクティブなマルチキャストソースのテーブルを調べ、Ｄ１への転送のためにサポート可能なマルチキャストソースの数（すなわち３）と、ＲＰ３が現在マルチキャストデータをＤ１に転送しているマルチキャストソースの数との差が１以上かどうか判定し、それによりステップＳ３２２’の判定を得る。

わかるように、ＲＰ３がすでに３つのマルチキャストソースのためにマルチキャストデータをマルチキャストアドレスＤ１に転送しているときは、この方法はステップＳ３２６に入り、マルチキャストソース１からマルチキャストアドレスＤ１へのマルチキャストデータの送信は拒否される。反対に、Ｓ３２３’’に入り、要求は許可され、アクティブなマルチキャストソースのテーブルが相応に更新される。この場合、帯域幅は必要制限条件ではないので、帯域幅に関係する項目をアクティブなマルチキャストソースのテーブルに含める必要はない。

好ましくは、各マルチキャストソースによって使用される帯域幅が設定値を超過すべきでないという暗黙的な仮定があってよい。このようにすれば、マルチキャストソースの数が上限に達したとき、占有される帯域幅は、ＲＰが提供できるマルチキャスト帯域幅の上限を超えないことになる。

マルチキャストデータを各マルチキャストアドレスに転送するときの、サポート可能なマルチキャストソース総数を考慮する。

図３ｅを参照するが、ＲＰ３に対応するマルチキャストアドレスがＤ１およびＤ２を含むと仮定し、ＲＰ３がマルチキャストデータを転送することのできるマルチキャストソースの総数を制限条件として使用する。

特に、ＲＰ３が、多くても１０個のマルチキャストソースのためにマルチキャストデータを転送でき、すでに３つのマルチキャストソースのためにＤ１にデータを転送しており、６つのマルチキャストソースのためにＤ２にデータを転送していると仮定する。ステップＳ３２２’’’で、ＲＰ３は、データ転送時にサポート可能なマルチキャストソースの総数と、データを転送しているマルチキャストソースの数との差が１以上かどうか判定する。肯定判定が得られたときは、ステップＳ３２３’’’に入り、マルチキャストソース１が要求マルチキャストアドレスにマルチキャストデータを送信するのを許可する。

反対に、ＲＰ３がこの時点で１０個のマルチキャストソースに対してマルチキャストデータを転送している場合は、ステップＳ３２２’’’で否定判定が得られ、したがってＳ３２７に入る。Ｓ３２７で、マルチキャスト１が要求マルチキャストアドレスにマルチキャストデータを送信することは拒否される。

上の例では、マルチキャストソース１がマルチキャストデータの送信を要求する送信先マルチキャストアドレスが何個であるかにかかわらず、全て１つのマルチキャストソースとして扱われると考えることができる。したがって、ステップＳ３２２’’’で得られる差が１のときは、マルチキャストソース１がＤ１とＤ２とに別々に送信することを要求する場合であっても、要求は許可されることになる。

上の例の一変形では、マルチキャストソースが種々のマルチキャストアドレスへのマルチキャストデータの送信を要求するとき、このマルチキャストソースは、処理のために複数のマルチキャストソースと見なされることになる。特に、マルチキャストソース１がマルチキャストデータをマルチキャストアドレスＤ１およびＤ２に送信を要求する例を考える。総マルチキャストソースの上限が１０であり、ＲＰ３が転送しているマルチキャストソースの数が９であると考えると、ＲＰ３は、多くても１つの新しいマルチキャストソースをサポートすることになる。したがって、図３ｅに示すステップＳ３２７の代替として、ＲＰ３は、Ｄ１とＤ２から一方を選択してマルチキャスト送信要求を開始し直すよう、マルチキャストソース１に指示することができる。あるいは、ＲＰ３は、直接にこれらから一方を選択し、マルチキャスト要求応答の送信によってこの選択をマルチキャストソース１に通知し、アクティブなマルチキャストソースのテーブルを更新する。図３ｄの例と同様、帯域幅に関係する項目は、アクティブなマルチキャストソースのテーブルに含めなくてよい。任意選択で、マルチキャストソース１がマルチキャストデータをＤ１およびＤ２にそれぞれ送信することを要求し、ＲＰ３が現在３つのマルチキャストソースのためにマルチキャストデータを転送している場合、マルチキャストソース１は、ステップＳ３２３’’’でＤ１およびＤ２への送信を許可される。さらに、後でアクティブマルチキャストテーブルが更新されるとき、マルチキャストソース１は、テーブルのＤ１およびＤ２に対応する部分中にそれぞれ現れることになり、新しいマルチキャスト送信要求が来たとき、マルチキャストソース１は、ＲＰ３がマルチキャストデータを転送する２つのマルチキャストソースと見なされることになる。

好ましくは、この方法に関する暗黙的な仮定、すなわち、各マルチキャストソースによって使用される帯域幅が設定値を超過しないという仮定もまたあってよい。したがって、各マルチキャストアドレスに対応するマルチキャストソースの数が上限に達したとき、占有される総帯域幅は、ＲＰが提供できるマルチキャスト帯域幅の上限を超過しないことになる。

本発明を方法のフローチャートと共に詳細に述べたが、以下では、装置を装置のブロック図と共に紹介する。上記における関連する内容をここで参照として使用できることを理解されたい。

図４ａに、本発明の一実施形態による、マルチキャスト送信要求を処理するための、ＲＰ中の第１の装置のブロック図を示すが、この場合、第１の受信手段３００および処理手段３０１が備わる。前者は、図２ａ−２ｃに示したステップＳ２１、Ｓ２４、またはＳ２７でマルチキャストソースまたは転送デバイスからマルチキャスト送信要求を受信して、これらを処理手段３０１に転送することを担う。

第１の装置３０中の処理手段３０１は、図３ｂ−３ｅと組み合わせたステップＳ３２に関する考察に従って、４ｂ−４ｅに示す４つの方式で実現することができる。必要とされる適用可能なシナリオの量に従って、第１の装置３０は、図４ｂ−４ｅ中の１つまたは複数の手段／モジュールで構成することができる。添付の図面に示す複数の手段／モジュールで構成されるとき、限定しないが第１の判定手段３０１０および第２の判定手段３０１２、第１の比較手段３０１１０および第２の比較手段３０１３、および第１の実行手段３０１１１および第２の実行手段３０１４を含めた、同じまたは同様の機能を実施するための手段／モジュールは、同じ手段／モジュールによって実現することができることを理解されたい。詳細には次のとおりである。

図４ｂを参照されたいが、この場合、第１の受信手段３００によって受信されたマルチキャスト送信要求に従って図３ｂに示したステップＳ３２１を実行するための、第１の決定手段３０１０を備える。第１のサブ処理手段３０１１が、第１の決定手段３０１０の決定結果と、ＲＰにおけるマルチキャストデータ転送に利用可能な残り帯域幅とに基づいて、マルチキャストソースのマルチキャスト送信要求を処理する。その機能は、図３ｂに示したステップＳ３２２を実行するための第１の比較手段３０１１０、および図３ｂに示したステップＳ３２３−Ｓ３２５を実行するための第１の実行手段３０１１１によって実現される。

図４ｃを参照されたいが、ここで処理手段３０１は、図３ｃに示したステップＳ３２１’を実行するための第２の決定手段３０１２を備える。決定結果は第２の比較手段３０１３に提供され、比較手段３０１３は、後続のステップＳ３２２’を実行し、比較結果は第２の実行手段３０１４に提供されて、ステップＳ３２３’またはＳ３２５’が実行される。ステップＳ３２５’について述べた任意の変形もまた、第２の実行手段３０１４によって実現することができる。

図４ｄを参照されたいが、ここで処理手段３０１は、図３ｄに示したステップＳ３２２’を実行するための第１の判定手段３０１５、ならびに、ステップＳ３２３’’およびステップＳ３２６を実行するための第３の実行手段３０１６を備える。

図４ｅを参照されたいが、ここで処理手段３０１は、図３ｅに示したステップＳ３２２’’’を実行するための第２の判定手段３０１７、ならびに、図３ｅ中のステップＳ３２３’’’およびステップＳ３２７を実行するための第４の実行手段３０１８を備える。

図５に、本発明の一実施形態による、ＲＰとマルチキャストソースとの対話を補助するための、転送デバイス中の第２の装置のブロック図を示す。図１中の転送デバイス２１を例にとると、図示の第２の装置２１０は、以下を備える：
少なくとも１つのマルチキャストアドレスを示すマルチキャスト送信要求をマルチキャストソースから受信するための、すなわち、図２ｂに示したステップＳ２３および図２ｃに示したステップＳ２６で送信されるマルチキャスト送信要求を受信するための、第２の受信手段２１００、
少なくとも１つのマルチキャストアドレスのそれぞれにつき、マルチキャストソースに代わって、マルチキャストアドレスに対応するＲＰに、マルチキャストアドレスへのマルチキャストデータの送信を要求するための、すなわち図２ｂ中のステップＳ２４および図２ｃ中のステップＳ２７を実行するための、要求手段２１０１、
マルチキャストソースに代わって転送デバイスによって生成された要求に応答するのに使用される、各マルチキャストアドレスに対応する各ＲＰによって送信されたマルチキャスト要求応答を、それぞれ受信するための、第３の受信手段２１０２、
受信したマルチキャスト要求応答を対応するマルチキャストソースに送信するための、第１の送信手段２１０３。

図６ａおよび６ｂに、本発明の種々の実施形態による、マルチキャストデータの送信を要求するための、マルチキャストソース中の第３および第４の装置をそれぞれ示す。図６ａは、前述のシナリオ１．１）および１．２）に対応し、図６ｂは、前述のシナリオ１．３）に対応する。必要とされる適用可能なシナリオの量に従って、マルチキャストソースは、図６ａ、６ｂ中の１つまたは複数の手段／モジュールで構成することができる。添付の図面に示す複数の手段／モジュールで構成されるとき、限定しないが第１の生成手段１００および第２の生成手段１１０を含めた、同じまたは同様の機能を実施するための手段／モジュールは、同じ手段／モジュールによって実現することができることを理解されたい。

特に、図示の第３の装置１０は、少なくとも１つのマルチキャストアドレスを示すユニキャスト用マルチキャスト送信要求を生成するための第１の生成手段１００と、少なくとも１つのマルチキャストアドレスの対応する転送デバイスまたはＲＰにマルチキャスト送信要求を送信するための第２の送信手段１０１とを備える。

装置１０はまた、マルチキャストソースが少なくとも１つのマルチキャストアドレスにマルチキャストデータを送信できるかどうかを示すマルチキャスト要求応答をそれぞれ受信するための、第４の受信手段１０２を備えることが好ましい。

図示の第４の装置１１は、マルチキャストアドレスを示し、マルチキャストアドレスへのマルチキャストデータの送信をマルチキャストソースが要求することを表す、マルチキャスト用マルチキャスト送信要求を生成するための、第２の生成手段１１０と、マルチキャスト用マルチキャスト送信要求をマルチキャストアドレスに送信するための、第３の送信手段１１１と、マルチキャストソースがマルチキャストアドレスにマルチキャストデータを送信できるかどうかを示すマルチキャスト要求応答を受信するための、第５の受信手段１１２とを備える。

本発明は上記の特定の実施形態に限定されず、添付の特許請求の範囲によって定義される範囲を逸脱することなく当業者によって任意の改変または修正を加えることができることを理解されたい。

Claims (4)

1. エニーソースマルチキャストＡＳＭに基づくランデブーポイントＲＰで実行される、マルチキャストソースのマルチキャスト送信要求を処理する方法であって、
   ａ．ＲＰにおいて、少なくとも１つのマルチキャストアドレスへのマルチキャストデータの送信を要求するためのマルチキャスト送信要求を前記マルチキャストソースから受信するステップと、
   ｂ．ＲＰにおいて、前記マルチキャスト送信要求および前記ＲＰ中の残りのマルチキャスト転送リソースに従って、マルチキャストソースの前記マルチキャスト送信要求を処理するステップとを含み、残りのマルチキャスト転送リソースは、ＲＰにおいて、ＲＰにおけるマルチキャスト転送に利用可能な残りの帯域幅量を分析することによって、決定され、
   前記ＲＰ中の残りのマルチキャスト転送リソースが、各マルチキャストアドレスにつき、ＲＰがマルチキャストデータをマルチキャストアドレスに転送するときにサポート可能なマルチキャストソースの数と、ＲＰがマルチキャストデータをマルチキャストアドレスに転送しているマルチキャストソースの数との差を含み、前記ステップｂが、前記少なくとも１つのマルチキャストアドレスのそれぞれにつき、
   ＲＰがマルチキャストデータをマルチキャストアドレスに転送するときにサポート可能なマルチキャストソースの数と、ＲＰがマルチキャストデータをマルチキャストアドレスに転送しているマルチキャストソースの数との差が１以上であるかどうか判定する動作と、
   ＲＰがマルチキャストデータをマルチキャストアドレスに転送するときにサポート可能なマルチキャストソースの数と、ＲＰがマルチキャストデータをマルチキャストアドレスに転送しているマルチキャストソースの数との差が１以上である場合に、マルチキャストアドレスへのマルチキャストデータの送信を前記マルチキャストソースに許可する動作とを実行することを含む、方法。
2. エニーソースマルチキャストＡＳＭに基づくランデブーポイントＲＰで実行される、マルチキャストソースのマルチキャスト送信要求を処理する方法であって、
   ａ．ＲＰにおいて、少なくとも１つのマルチキャストアドレスへのマルチキャストデータの送信を要求するためのマルチキャスト送信要求を前記マルチキャストソースから受信するステップと、
   ｂ．ＲＰにおいて、前記マルチキャスト送信要求および前記ＲＰ中の残りのマルチキャスト転送リソースに従って、マルチキャストソースの前記マルチキャスト送信要求を処理するステップとを含み、残りのマルチキャスト転送リソースは、ＲＰにおいて、ＲＰにおけるマルチキャスト転送に利用可能な残りの帯域幅量を分析することによって、決定され、
   前記ＲＰ中の残りのマルチキャスト転送リソースが、ＲＰがマルチキャストデータを転送するときにサポート可能なマルチキャストソースの総数と、ＲＰがマルチキャストデータを転送しているマルチキャストソースの数との差を含み、前記ステップｂが、
   − 前記差が１以上であるかどうか判定すること、および、
   − 前記差が１以上である場合に前記少なくとも１つのマルチキャストアドレスへのマルチキャストデータの送信を前記マルチキャストソースに許可することを含む、方法。
3. マルチキャストソースのマルチキャスト送信要求を処理するための、エニーソースマルチキャストＡＳＭに基づくマルチキャストランデブーポイントＲＰ中の装置であって、
   ＲＰに配置された、少なくとも１つのマルチキャストアドレスへのマルチキャストデータの送信を要求するためのマルチキャスト送信要求を前記マルチキャストソースから受信するための第１の受信手段と、
   ＲＰに配置された、前記マルチキャスト送信要求および前記ＲＰ中の残りのマルチキャスト転送リソースに従って、マルチキャストソースの前記マルチキャスト送信要求を処理するための処理手段とを備え、残りのマルチキャスト転送リソースは、ＲＰにおいて、ＲＰにおけるマルチキャストデータ転送に利用可能な残りの帯域幅量を分析することによって、決定され、
   前記ＲＰ中の残りのマルチキャスト転送リソースが、各マルチキャストアドレスにつき、ＲＰがマルチキャストデータをマルチキャストアドレスに転送するときにサポート可能なマルチキャストソースの数と、ＲＰがマルチキャストデータをマルチキャストアドレスに転送しているマルチキャストソースの数との差を含み、前記処理手段が、前記少なくとも１つのマルチキャストアドレスのそれぞれにつき、
   ＲＰがマルチキャストデータをマルチキャストアドレスに転送するときにサポート可能なマルチキャストソースの数と、ＲＰがマルチキャストデータをマルチキャストアドレスに転送しているマルチキャストソースの数との差が１以上であるかどうか判定する動作と、
   ＲＰがマルチキャストデータをマルチキャストアドレスに転送するときにサポート可能なマルチキャストソースの数と、ＲＰがマルチキャストデータをマルチキャストアドレスに転送しているマルチキャストソースの数との差が１以上である場合に、マルチキャストアドレスへのマルチキャストデータの送信を前記マルチキャストソースに許可する動作とを実行する、装置。
4. マルチキャストソースのマルチキャスト送信要求を処理するための、エニーソースマルチキャストＡＳＭに基づくマルチキャストランデブーポイントＲＰ中の装置であって、
   ＲＰに配置された、少なくとも１つのマルチキャストアドレスへのマルチキャストデータの送信を要求するためのマルチキャスト送信要求を前記マルチキャストソースから受信するための第１の受信手段と、
   ＲＰに配置された、前記マルチキャスト送信要求および前記ＲＰ中の残りのマルチキャスト転送リソースに従って、マルチキャストソースの前記マルチキャスト送信要求を処理するための処理手段とを備え、残りのマルチキャスト転送リソースは、ＲＰにおいて、ＲＰにおけるマルチキャストデータ転送に利用可能な残りの帯域幅量を分析することによって、決定され、
   前記ＲＰ中の残りのマルチキャスト転送リソースが、ＲＰがマルチキャストデータを転送するときにサポート可能なマルチキャストソースの総数と、ＲＰがマルチキャストデータを転送しているマルチキャストソースの数との差を含み、前記処理手段が、
   − 前記差が１以上であるかどうか判定し、および、
   − 前記差が１以上である場合に前記少なくとも１つのマルチキャストアドレスへのマルチキャストデータの送信を前記マルチキャストソースに許可する、装置。

Images