(57)【要約】【課題】本発明は，一般にネットワークにおけるマルチキャスト送信の効率改善を目的とする。【解決手段】ネットワークデバイスに特定のマルチキャストグループ及びソースデバイスのための多重マルチキャスト配信構造を設定する際に，マルチキャストプロトコルが制御メッセージ内にインスタンス番号を含むように拡張される。ネットワークデバイスは，複数のアップストリームルータに対して，参加すべきマルチキャストグループの異なるインスタンスを指定する参加要求を送信する。マルチキャストグループのソースデバイスは，例えばユニキャスト等価コストマルチパス（ＥＣＭＰ）ハッシングアルゴリズムを用いてＮ個のインスタンスのうち一つを選択し，Ｎ個のインスタンスのうち選択された一つに対応するマルチキャスト配信構造を介して，マルチキャストグループのためのマルチキャストコンテンツを送信する。【選択図】図１１
2007208953.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク内にマルチキャスト配信構造を形成させる方法であって，デバイスにおいて，一つのソースデバイスからのマルチキャストグループのＮ個のインスタンスに参加するステップを有し，前記Ｎ個のインスタンスのそれぞれが，前記マルチキャストグループのための前記ネットワーク内の異なるマルチキャスト配信構造に対応する方法。
【請求項２】
参加ステップが，前記デバイスから，前記デバイスと前記マルチキャストグループのための前記ソースデバイスとの間に配置された複数のアップストリームデバイスへ，前記Ｎ個のインスタンスのそれぞれに対する参加要求を送信するステップを有し，それぞれの前記参加要求は，参加すべき前記マルチキャストグループの前記Ｎ個のインスタンスのうち異なる一つを指定する請求項１に記載の方法。
【請求項３】
前記複数のアップストリームデバイス内に前記参加要求を配信するステップを更に有する請求項１に記載の方法。
【請求項４】
前記デバイスにおいて，前記マルチキャストグループのための前記Ｎ個のインスタンスを指定するステップを更に有し，
デバイスにおけるマルチキャストグループのためのマルチキャスト配信構造のＮ個のインスタンスを指定するステップは，前記Ｎ個のインスタンスへの配信にディスカバリプロトコルを用いるステップを有し，
前記ディスカバリプロトコルは，マルチキャスト仮想専用ネットワーク（ＭＶＰＮ）プロトコル又はマルチキャスト仮想専用ローカルエリアネットワークサービス（ＭＶＰＬＳ）プロトコルとする請求項１に記載の方法。
【請求項５】
デバイスが，該デバイスとマルチキャストグループのためのソースデバイスとの間に配置された少なくとも２台のアップストリームデバイスからそれぞれメッセージを受信し，該メッセージがアップストリームデバイスを選択するための少なくとも一つの基準を指定するマルチキャスト最適化データを含むステップと，
前記マルチキャスト最適化データに基づいて少なくとも２台のアップストリームデバイスから少なくとも１かつＮ台までを選択するステップとを更に有し，
参加要求を送信するステップは，前記マルチキャストグループのための前記Ｎ個のインスタンスに参加するために，前記デバイスから前記の選択したアップストリームデバイスへ，前記Ｎ個のインスタンスのそれぞれに対する前記参加要求を送信するステップを有する請求項１に記載の方法。
【請求項６】
少なくとも２台のアップストリームデバイスから少なくとも１かつＮ台までを選択するステップは，前記アップストリームデバイスを順序付けるための前記メッセージの前記マルチキャスト最適化データに１以上の基準を適用するステップを有し，
前記アップストリームデバイスを順序付けるための前記基準は，前記ネットワーク内の前記マルチキャストグループの前記インスタンスに関するマルチキャストトラヒックの重複の最小化と，前記ネットワーク内の前記マルチキャストトラヒックの負荷バランスと，より短い通信遅延を有するネットワーク経路選択とのうち１以上を含む請求項５に記載の方法。
【請求項７】
前記Ｎ個のインスタンスに対応する前記マルチキャスト配信構造を，部分的に重複させる請求項１に記載の方法。
【請求項８】
前記の複数のインスタンスに参加するステップは，プロトコル独立マルチキャスト（ＰＩＭ）プロトコル及びポイント−ツ−マルチポイント（Ｐ２ＭＰ）ラベル配信プロトコル（ＬＤＰ）のうち一つの拡張を用いて前記インスタンスに参加するステップを有する請求項１に記載の方法。
【請求項９】
ネットワークデバイスであって，
インスタンス数Ｎを指定する構成データを格納する制御ユニットと，
前記インスタンス数Ｎに基づいて，マルチキャストグループのＮ個のインスタンスにＮ個の参加要求を生成する，前記制御ユニット内で実行されるマルチキャストプロトコルであって，前記Ｎ個のインスタンスのそれぞれが，前記マルチキャストグループのための異なるマルチキャスト配信構造に対応し，それぞれの前記参加要求は，参加すべき前記マルチキャストグループの前記Ｎ個のインスタンスのうち異なる一つを指定するプロトコルと，
前記マルチキャストグループに参加するために，前記ネットワークデバイスと前記マルチキャストグループのためのソースデバイスとの間に配置された複数のアップストリームデバイスへ前記参加要求を出力するインタフェースとを備えるネットワークデバイス。
【請求項１０】
請求項９に記載のネットワークデバイスであって，
前記インタフェースは前記複数のアップストリームデバイスのうち少なくとも２台からそれぞれメッセージを受信し，それぞれの該メッセージはアップストリームデバイスを選択するための少なくとも一つの基準を指定するマルチキャスト最適化データを含み，
前記制御ユニットは，前記マルチキャスト最適化データに基づいて前記の少なくとも２台のアップストリームデバイスのうち少なくとも１台かつＮ台までを選択し，かつ前記Ｎ個のインスタンスのそれぞれに参加要求を生成し，
前記インタフェースは，前記マルチキャストグループの前記Ｎ個のインスタンスに参加するために前記の選択されたアップストリームデバイスへ前記参加要求を出力し，
前記制御ユニットは，前記アップストリームデバイスを順序付けるための前記メッセージの前記マルチキャスト最適化データに１以上の基準を適用することによって前記少なくとも２台のアップストリームデバイスのうち少なくとも１台かつＮ台までを選択し，
前記アップストリームデバイスを順序付けるための前記基準は，前記ネットワーク内の前記マルチキャストグループの前記インスタンスのためにマルチキャストトラヒックの重複の最小化と，前記ネットワーク内の前記マルチキャストトラヒックの負荷バランスと，より短い通信遅延を有するネットワーク経路選択とのうち１以上を含むネットワークデバイス。
【請求項１１】
システムであって，
マルチキャストグループのためのマルチキャストコンテンツを提供するソースデバイスと，
ネットワークデバイスであって，該ネットワークデバイスと前記ソースデバイスとの間に配置された複数のアップストリームデバイスを介して，前記ソースデバイスと結合されたネットワークデバイスとを備え，
前記ネットワークデバイスは，該ネットワークデバイスから前記複数のアップストリームデバイスへマルチキャストグループのための指定されたＮ個のインスタンスのそれぞれに対して参加要求を送信し，
前記Ｎ個のインスタンスのそれぞれは，前記マルチキャストグループのための異なるマルチキャスト配信構造に対応し，またそれぞれの前記参加要求は，参加すべき前記Ｎ個のインスタンスのうち異なる一つを指定し，
前記ソースデバイスは，前記Ｎ個のインスタンスのうち一つを選択し，かつ前記Ｎ個のインスタンスのうちの前記の選択された一つに対応する前記マルチキャスト配信構造を介して，前記ネットワークデバイスへ前記マルチキャストグループのための前記マルチキャストコンテンツを送信するシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，計算機ネットワーク，より特定すれば計算機ネットワーク内のマルチキャストコンテンツの送信に関する。
【背景技術】
【０００２】
計算機ネットワークとは，データを交換し，リソースを共有する相互接続された計算デバイスの集合である。ネットワーク内の計算デバイス間でデータを伝送するためのいくつかの方法がある。”マルチキャスト”として知られる一つの方法では，マルチキャストツリーを利用して，ソースデバイスが配信するための一つのデータパケットを１以上のあて先計算デバイスのグループへ送信する。マルチキャストでは，ソースデバイスはデータにマルチキャスト識別子を割当て，グループの各計算デバイスがデータのコピーを受信できるようにする。あるときは，ソースデバイスはネットワークを介して，マルチキャストのために構成されたルータへマルチキャストパケットを送信する。次にルータはパケットを複製して，そのパケットのコピーを他のマルチキャストが可能なルータへ転送する。他のルータは，次にそのパケットを複製し，それぞれのあて先デバイスがパケットのコピーを受信するように転送プロセスを繰り返す。この方法によって，マルチキャストパケットはマルチキャストツリーを用いて１以上のネットワークを介して配信される。
【０００３】
消費者は，”マルチキャストアクション要求”を発行することによって，１コンテンツプロバイダ又は多数のコンテンツプロバイダによって提供される異なったマルチキャストコンテンツを切り替えることができる。特に，マルチキャストアクション要求は，ユーザがマルチキャスト識別子に関連付けられたさまざまなマルチキャストグループに参加・離脱できるようにする。参加要求のようなマルチキャストアクション要求を発行するプロトコルの例は，インターネットグループ管理プロトコル（ＩＧＭＰ）である。特定のマルチキャストグループに参加するために，受信デバイスはアップストリーム（すなわち中間の）ルータにマルチキャスト参加要求を送信し，ルータは次に，その参加要求をソースデバイスに転送する。
【発明の開示】
【課題を解決するための手段】
【０００４】
一般に，本発明は，ネットワークにおけるマルチキャスト送信の効率を改善させるためのテクニックに向けられている。特定のマルチキャストグループ及びソースデバイスのために一つの配信構造（例えばツリー）を確立する代わりに，本テクニックは，各デバイスが特定のマルチキャストグループ及びソースデバイスのための多重マルチキャスト配信構造を設定できるようにすることができる。このテクニックによれば，マルチキャスト配信構造を設定するために用いられる制御メッセージ内にインスタンス番号を含むようにマルチキャストプロトコルが拡張され，そのインスタンス番号は，マルチキャストグループ及びソースデバイスのための複数のインスタンスのうちの一つに対応する。ソースデバイスはそれで，マルチキャストコンテンツを送信するために用いる複数のマルチキャスト配信構造うちの一つを，例えばユニキャスト等価コストマルチパス（ＥＣＭＰ）ハッシングアルゴリズムを用いて選択することができる。
【０００５】
各受信ノードは，例えば設定又はディスカバリプロトコルによって，ＥＣＭＰの幅，すなわちマルチキャストグループ及びソースデバイスのための複数のインスタンスの数Ｎを知っている。各受信ノードはそれで，Ｎ個の参加メッセージを送信し，各メッセージは異なるインスタンス番号を有し，アップストリームデバイス内に配信される。この方法によれば，Ｎ本のマルチキャストツリーが形成されるが，ソースデバイスはマルチキャストコンテンツを送信するために複数のマルチキャストツリーのうちただ一つを選択するので，各受信デバイスは，ソースデバイスからマルチキャストコンテンツのコピーを一つだけ受信する。参加メッセージは，拡張されたプロトコル独立マルチキャスト（ＰＩＭ）プロトコル又はポイント−ツーマルチポイント（Ｐ２ＭＰ）ラベル配信プロトコル（ＬＤＰ）を用いて送信することができる。ＩＰマルチキャストに関しては例示の目的でのみ記載しているが，本発明の原理はまた，ＬＤＰ，Ｐ２ＭＰ又はマルチプロトコルラベル交換（ＭＰＬＳ）環境のような他の環境におけるマルチキャストツリー構築にも適用できる。
【０００６】
一つの実施例においては，ネットワーク内にマルチキャスト配信構造を形成する方法が，デバイスにおいて，一つのソースデバイスからのマルチキャストグループのＮ個のインスタンスに参加するステップを有し，前記Ｎ個のインスタンスのそれぞれが，前記マルチキャストグループのための前記ネットワーク内の異なるマルチキャスト配信構造に対応する。
【０００７】
他の実施例においては，ネットワーク内のマルチキャスト配信構造を用いるステップが，マルチキャストグループのためのソースデバイスにおいて，前記マルチキャストグループのためのＮ個のインスタンスのうち一つを選択するステップと，前記Ｎ個のインスタンスのうちの前記の選択された一つに対応する前記マルチキャスト配信構造を介して，前記デバイスへ前記マルチキャストグループのためのマルチキャストコンテンツを送信するステップとを有する。
【０００８】
更なる実施例においては，ネットワークデバイスが，インスタンス数Ｎを指定する構成データを格納する制御ユニットと，前記インスタンス数Ｎに基づいて，マルチキャストグループのＮ個のインスタンスにＮ個の参加要求を生成する，前記制御ユニット内で実行されるマルチキャストプロトコルであって，前記Ｎ個のインスタンスのそれぞれが，前記マルチキャストグループのための異なるマルチキャスト配信構造に対応するプロトコルを有する。それぞれの前記参加要求は，参加すべき前記マルチキャストグループの前記Ｎ個のインスタンスのうち異なる一つを指定する。前記ネットワークデバイスはまた，前記マルチキャストグループに参加するために，前記ネットワークデバイスと前記マルチキャストグループのためのソースデバイスとの間に配置された複数のアップストリームデバイスへ前記参加要求を出力するインタフェースも備える。
【０００９】
更に他の実施例においては，システムが，マルチキャストグループのためのマルチキャストコンテンツを提供するソースデバイスと，ネットワークデバイスであって，該ネットワークデバイスと前記ソースデバイスとの間に配置された複数のアップストリームデバイスを介して，前記ソースデバイスと結合されたネットワークデバイスとを備える。前記ネットワークデバイスは，該ネットワークデバイスから前記複数のアップストリームデバイスへマルチキャストグループのための指定されたＮ個のインスタンスのそれぞれに対して参加要求を送信する。前記Ｎ個のインスタンスのそれぞれは，前記マルチキャストグループのための異なるマルチキャスト配信構造に対応し，またそれぞれの前記参加要求は，参加すべき前記Ｎ個のインスタンスのうち異なる一つを指定する。前記ソースデバイスは，前記Ｎ個のインスタンスのうち一つを選択し，かつ前記Ｎ個のインスタンスのうちの前記の選択された一つに対応する前記マルチキャスト配信構造を介して，前記ネットワークデバイスへ前記マルチキャストグループのための前記マルチキャストコンテンツを送信する。
【００１０】
他の実施例においては，計算機可読媒体が，一つのソースデバイスからのマルチキャストグループのためのＮ個のインスタンスを指定し，前記のＮ個のインスタンスのそれぞれは，前記マルチキャストグループの異なるマルチキャスト配信構造に対応するように，プログラム可能なプロセッサに指示する命令を有する。前記命令は更に，前記デバイスから，前記マルチキャストグループのための前記デバイスと前記ソースデバイスとの間に配置された複数のアップストリームデバイスへ，Ｎ個のインスタンスのそれぞれに対する参加要求を送信するようにプログラム可能なプロセッサに指示する。それぞれの前記参加要求は，参加すべき前記マルチキャストグループの前記Ｎ個のインスタンスのうち異なる一つを指定する。
【００１１】
本発明の１以上の実施例の詳細は，付属する図面及び以下の説明によって明らかにされる。本発明の他の特徴，目的及び利点は，本願の記載及び図面並びに請求項から明白になるであろう。
【発明を実施するための最良の形態】
【００１２】
図１Ａは，例示のシステム１０を示すブロック図であり，受信機１４Ａ〜１４Ｄ（ネットワークデバイスの例であって，集合的に受信機１４と呼ぶ）が，本発明の原理に沿った方法でソースデバイス１２からマルチキャストトラヒックを受信するための１以上のルータ（アップストリームデバイス）を選択する。ソースデバイス１２はインターネットプロトコル（ＩＰ）ビデオサービス，ＩＰテレビジョン（ＩＰＴＶ），デスクトップ会議，社内放送又は他のコンテンツのようなコンテンツを，受信機１４に提供する。例えば，ソースデバイス１２は，受信機１４が参加中の１以上のマルチキャストグループへマルチキャストデータパケットの形でコンテンツを提供することができる。各マルチキャストデータパケットは，それぞれのマルチキャストグループを識別するマルチキャスト識別子を含んでいる。ルータ１６Ａ〜１６Ｆ（集合的にルータ１６と呼ぶ）は，受信機１４とマルチキャストグループとを関連付ける情報を管理し，ソースデバイス１２から受信機１４へマルチキャストデータパケットのコピーを送信することができる。
【００１３】
ＩＰマルチキャストを用いてマルチキャストツリーを構築することに関して，本発明は例示の目的で記載される。しかし，このテクニックはまた，ラベル配信プロトコル（ＬＤＰ），ポイント−ツ−マルチキャストポイント（Ｐ２ＭＰ）又はマルチプロトコルラベル交換（ＭＰＬＳ）環境のような他の環境においてマルチキャスト配信構造を構築するためにも適用できる。例えば，２００５年８月２９日に提出された米国特許出願，No. 11/215,813，”Point to Multi-Point Label Switched Paths with Label Distribution Protocol”に記載されているように，マルチキャストストリームは，ラベル交換パス（ＬＳＰ），例えばＰ２ＭＰ  ＬＳＰ，を介して送信することができる。
【００１４】
図１Ａに示されたシステム１０の構成は，単に例示である。例えば，システム１０は追加のソースデバイス（示されていない）を含んでもよい。一般に，ソースデバイス１２は，ビデオサーバのような任意のマルチキャストコンテンツのソースデバイスを表現したものである。更に，受信機１４は，パーソナルコンピュータ，ラップトップコンピュータ，携帯コンピュータ，ワークステーション，サーバ，デジタルテレビ，ネットワーク機能を持つ携帯電話機，及びその類似物のようなマルチキャストコンテンツを受信することができる任意の種類のデバイスを含んでもよい。
【００１５】
受信機１４は，マルチキャストアクション要求を発行するために，インターネットグループ管理プロトコル（ＩＧＭＰ）又は他のマルチキャストプロトコルを介してルータ１６と対話することができる。受信機１４は，例えばマルチキャストグループに参加し，又はマルチキャストグループから離脱するために，それぞれ参加又は離脱マルチキャストアクション要求を発行することができる。例えば，受信機１４は，ルータ１６がマルチキャストデータパケットを配信する例としてのマルチキャストグループのメンバになるためにマルチキャスト参加要求を発行することができる。他の例として，受信機１４の一つはグループから離脱するためにマルチキャスト離脱要求（”切取り（ｐｒｕｎｅ）”アクション要求とも呼ばれる）を発行することができ，それによって対応するルータ１６からのコンテンツ配信が停止される。類似の方法で，受信機１４はマルチキャストグループを切り替えるために，ルータ１６にマルチキャストアクション要求を発行することができ，それで受信機１４はソースデバイス１２が提供する別のコンテンツにアクセスすることができる。
【００１６】
本発明の原理によれば，受信機１４とルータ１６とはそれらがメンバであるマルチキャストグループと，それらが接続している，そのグループのためのマルチキャストコンテンツを提供できるか又は既に提供している，アップストリームデバイス又はダウンストリームデバイスの数とに関する情報を含むメッセージを交換することができる。ルータ１６と同様に受信機１４は，この情報を用いて，マルチキャスト参加要求を発行する先の”アップストリーム”ルータを賢く選択することができる。その判断を行う際に，受信デバイスはシステム１０の状態を監視し，マルチキャストトラヒックの重複の最小化，現在の帯域幅レベルにあった負荷バランス及び通信遅延を有する経路の回避，のようなアップストリームルータ１６を順序付ける任意のさまざまな基準を利用することができる。
【００１７】
ルータが受信機とソースデバイスとの間の”アップストリーム”ルータかどうかは，デバイスが用いる”アップストリーム”の定義に依存する。ネットワーク内の各ルータは，”アップストリーム”について同じ定義を持つのが望ましい。例えば，一つの”アップストリーム”の定義によれば，特定の受信機と特定のソースデバイスとに関して，ソースデバイスから特定のルータまでの距離が，ソースデバイスから受信機までの距離よりも短いとき，そのルータはアップストリームルータであり，ここでその距離は，インターネットゲートウェイプロトコル（ＩＧＰ）の計量に従って判定される。他の”アップストリーム”の定義によれば，受信機とソースデバイスとに関して，ルータからソースデバイスまでの距離が，あて先からソースデバイスまでの距離よりも短ければ，そのルータはアップストリームルータである。この定義は，二つのデバイス間のＩＧＰ計量が非対称であるため，最初の定義と異なる結果をもたらすかも知れない。更に他の一式の定義は，アップストリームルータが，特定のルータからソースデバイスまでの（又はソースデバイスからルータまでの）ＩＧＰ計量によって定義される最短経路上になければならないという追加の要求条件を付け加える。更に，特定のルータは，ある文脈ではアップストリームルータであり，他の文脈ではダウンストリームルータであって，特定のソースデバイス及び受信機との関係に依存する。
【００１８】
図１Ａの例において，システム１０には現在ソースデバイス１２から発せられた一つのマルチキャストストリーム２６があり，受信機１４Ａにのみ配信されているとしよう。更に，受信機１４Ｂがマルチキャストストリーム２６に関連付けられた例示のためのマルチキャストグループ＜ソースデバイス１２，グループ１＞に参加を所望しているとしよう。その結果，受信機１４Ｂはまずマルチキャスト最適化（ＭＯ）パケット２０Ａを，受信機１４Ｂが接続している各アップストリームルータ，すなわちルータ１６Ａに送信する。ＭＯパケット２０Ａは，例えばルータ１６Ａに，受信機１４Ｂが接続しているアップストリームルータの数，並びに受信機１４Ｂがマルチキャストストリーム２６に関連付けられた特定のソースデバイス及びグループ＜ソースデバイス１２，グループ１＞のためのマルチキャストトラヒックを受信するアップストリームルータの数を通知する。
【００１９】
この例では，ルータ１６Ａが受信機１４Ｂに関連付けられた唯一のアップストリームルータであり，それでＭＯパケット２０Ａは，受信機１４Ｂはグループ＜ソースデバイス１２，グループ１＞のためのマルチキャストトラヒックを受信するためにただ一つのアップストリームルータを有することをルータ１６Ａに通知することができる。ＭＯパケット２０Ａはまた，グループに参加する可能性のあるダウンストリームデバイスを受信機１４Ｂがいくつ有するか，また既にグループのメンバになっているダウンストリームデバイスを受信機１４Ｂがいくつ有するかもルータ１６Ａに通知することができる。ここで受信機１４Ｂはどちらの範疇のダウンストリームデバイスも有しない。ルータ１６ＡがＭＯパケット２０Ａを受信すると，ルータ１６Ａは，パケット内に含まれる情報を，マルチキャスト最適化データ（ＭＯＤ）としてデータベースに保存する。
【００２０】
応答として，ルータ１６Ａは受信機１４ＢにＭＯ応答パケット２１Ａを送信する。ＭＯ応答パケット２１Ａは，例えばルータ１６Ａが有する従属及び非従属のダウンストリームデバイスの数，及び既にマルチキャストグループに参加中の従属デバイスを有するかどうかを，受信機１４Ｂに通知する。従属ダウンストリームデバイスという用語は，ルータに従属しているデバイス，すなわちルータが，そのダウンストリームデバイスがマルチキャストストリームを受信することができる唯一のアップストリームルータであるデバイスを指すために用いられる。非従属ダウンストリームデバイスという用語は，グループのためのルータからマルチキャストストリームを受信する可能性があり，またそのダウンストリームデバイスがマルチキャストストリームを受信することができる他のアップストリームルータにも接続しているデバイスを指すために用いられる。
【００２１】
この場合，ＭＯ応答パケット２１Ａは，ルータ１６Ａが１台の従属ダウンストリームデバイス（すなわち受信機１４Ｂ）と，１台の非従属ダウンストリームデバイス（すなわち受信機１４Ｃ）と，０台の参加ダウンストリームデバイスとを有することを受信機１４Ｂに通知する。ルータ１６Ａは，受信機１４Ｃから受信した類似のＭＯパケット２０（示されていない）によって，受信機１４Ｃが非従属ダウンストリームデバイスであることを事前に知らされている。この方法によって，受信機１４Ｂは，既にマルチキャストグループに参加中のルータ１６Ａの対向（ｐｅｅｒ）ダウンストリームデバイスがあるかどうか，及び将来マルチキャストトラヒックを受信するためにルータ１６Ａに従属する対向デバイスがあるかどうかを知ることができる。
【００２２】
受信機１４ＣがＭＯ応答パケット２１Ａを受信すると，受信機１４Ｃはパケットに含まれるマルチキャスト最適化データをデータ構造に保存することができる。更に，受信機１４Ｃは，マルチキャストストリーム２６に関連付けられたマルチキャストグループ＜ソースデバイス１２，グループ1＞に参加を要求するためにルータ１６Ａに参加要求２４Ａを送信する。
【００２３】
受信機１４Ｂがグループに参加するために参加要求２４Ａを発行する前か後に，ルータ１６ＡはＭＯパケット２０Ｂ，２０Ｃをそれぞれルータ１６Ｄ及び１６Ｅに送信する。ＭＯパケット２０Ｂ，２０Ｃは，ルータ１６Ａが所望の特定のソースデバイス及びグループのためのマルチキャストトラヒックをそれから受信できる２台の可能性のあるアップストリールータをルータ１６Ａが有することを指示することができる。ＭＯパケット２０Ｂ，２０Ｃはまた，ルータ１６Ａが２台のダウンストリームデバイス（すなわち受信機１４Ｂ，１４Ｃ）及び特定の＜Ｓ，Ｇ＞に参加中の１台のダウンストリームデバイス（すなわち受信機１４Ｂ）を有することを指示することができる。ある実施例においては，ルータ１６ＡはＭＯパケット２０Ｂ，２０Ｃを，受信機１４Ｂがグループに参加する前でさえも送信することができる。
【００２４】
応答として，ルータ１６Ｄ及び１６Ｅは，それぞれＭＯ応答パケット２１Ｂ，２１Ｃをルータ１６Ａに送信する。ＭＯ応答パケット２１Ｂは，ルータ１６Ｄが２台のダウンストリームデバイス（すなわち受信機１４Ａ及び中間ルータ１６Ａ）を有し，そのうち一つ（すなわち受信機１４Ａ）は既にグループに参加していることを指示する。ＭＯ応答パケット２１Ｃは，ルータ１６Ｅが２台のダウンストリームデバイスを有し，そのうちどちらもグループに参加していないことを指示する。この情報に基づいて，ルータ１６Ａはマルチキャストサブツリーを賢く形成することができる。例えば図１Ａに示すように，ルータ１６Ａは，ルータ１６Ｄが既にソースデバイス１２からのグループのためのマルチキャストトラヒックを受信しているので，ルータ１６Ａが＜ソースデバイス１２，グループ１＞のためのマルチキャストストリーム２６を受信するアップストリームルータとして，ルータ１６Ｄを選択することができる。この方法によって，ルータはシステム１０内でのマルチキャストパケットの不必要な重複を避けることができる。他の例として，ルータ１６Ａは負荷バランスの目的でルータ１６Ｅを選択してもよい。
【００２５】
ルータ１６Ａがルータ１６Ｄを選択したと仮定すると，ルータ１６Ａは参加要求２４Ｂを選択されたルータ１６Ｄへ送信する。ルータ１６Ｄは同様に，ＭＯパケット２０Ｄをソースデバイス１２へ送信し，ＭＯ応答パケット２１Ｄをソースデバイス１２から受信する。そして，参加要求２４Ｄをソースデバイス１２へ送信する。ソースデバイス１２はグループ＜Ｓ，Ｇ＞のためのマルチキャストストリーム２６をルータ１６Ｄへ送信し，ルータ１６Ｄはそのストリーム２６を複製してパケットをルータ１４Ａとルータ１６Ａとの双方へ送信する。ルータ１６Ａは次に，マルチキャストストリーム２６を受信機１４Ｂへ送信する。一つの実施例においては，マルチキャストストリーム２６はラベル交換パス（ＬＳＰ），例えばポイント−ツ−マルチポイント（Ｐ２ＭＰ）ＬＳＰを介して送信することができる。
【００２６】
この方法においては，マルチキャスト最適化データ（ＭＯＤ）は，アップストリーム及びダウンストリームでローカルデバイスまで伝播され，ダウンストリームデバイスが特定のマルチキャストグループのための最適なアップストリームデバイスを賢く選択できるようにする。それによって最適なマルチキャスト配信構造（例えばツリー及びサブツリー）を形成し，システム１０内のマルチキャストの効率を高める。ＭＯパケット２０，２１は，既存のルーティングプロトコル，例えばOpen Shortest Path First（ＯＳＰＦ）の拡張として，若しくはＩＧＭＰ，プロトコル独立マルチキャスト（ＰＩＭ），距離ベクトルマルチキャストルーティングプロトコル（ＤＶＭＲＰ），マルチキャストＯＳＰＦ（ＭＯＳＰＦ）又はマルチキャストトランスポートプロトコル（ＭＴＰ）のようなマルチキャストプロトコルの拡張として，若しくはＭＯＤを交換するために特別に設計された別のプロトコルとして送信される。デバイスは，マルチキャスト最適化データに変化が起きたときだけ，又はマルチキャストアクション要求に応答するとき，ＭＯパケットを周期的に送ることができる。
【００２７】
例えば，マルチキャスト最適化データは，既にマルチキャストグループに参加中の対応するアップストリームデバイスに属する他のダウンストリームデバイスの数と，マルチキャストグループのためのマルチキャストデータを提供することができる唯一の可能性のあるアップストリームデバイスであるアップストリームデバイスに関する従属ダウンストリームデバイスの数と，そのアップストリームデバイス又は少なくとも一つの他のアップストリームデバイスからマルチキャストデータを受信することができる非従属ダウンストリームデバイスの数と，可能性のあるアップストリームデバイスの数と，可能性のあるダウンストリームデバイスの数とのうち１以上を指示することができる。他の例としてＭＯＤは，マルチキャストグループのソースデバイスから対応するアップストリームデバイスまでの距離と，対応するアップストリームデバイスからソースデバイスまでの距離と，ソースデバイスから対応するアップストリームデバイスまでの遅延と，アップストリームデバイスを通過するマルチキャストグループの数と，アップストリームデバイスを通過する合計マルチキャスト帯域幅とを指示することができる。
【００２８】
図１Ｂに関して，受信機１４Ｃがその後マルチキャストストリーム２６と関連付けられたマルチキャストコンテンツを受信することを所望しているとしよう。図１Ｂに示されているように，受信機１４ＣはＭＯパケット２０Ｅ，２０Ｆをそれぞれアップストリームデバイス１６Ａ及び１６Ｂに送信する。ＭＯパケット２０Ｅ，２０Ｆは，受信機１４Ｃがグループ＜ソースデバイス１２，グループ１＞のためのマルチキャストトラヒックをそこから受信できる２台の可能性のあるアップストリームデバイスを受信機１４Ｃが有することを指示することができる。ＭＯパケット２０Ｅ，２０Ｆはまた，受信機１４Ｃが０台の可能性のあるダウンストリームデバイス及び０台の参加済みダウンストリームデバイスを有することを指示することもできる。
【００２９】
応答として，ルータ１６Ａ及び１６ＢはそれぞれＭＯ応答パケット２１Ｅ，２１Ｆを受信機１４Ｃへ送信する。ＭＯ応答パケット２１Ｅは，ルータ１６Ａが既にグループに参加中の１台のダウンストリームデバイス（すなわち受信機１４Ｂ）を有することを指示する。ＭＯ応答パケット２１Ｆは，ルータ１６Ｂが既にグループに参加中のダウンストリームデバイスを有しないことを指示する。この情報に基づいて，受信機１４Ｃは，受信機１４Ｃがグループのためのマルチキャストストリームをそれから受信するアップストリームルータを賢く選択することができる。この例において，受信機１４Ｃは，ルータ１６Ａが既にグループのためのマルチキャストトラヒックを受信しているので，ルータ１６Ａを選択する。この方法によって，アップストリームルータはシステム１０内の不必要なマルチキャストパケットの重複を避けることができる。代替として，受信機１４Ｃは上述のように他の基準を利用してもよい。
【００３０】
受信機１４Ｃがルータ１６Ａを選択したとすると，受信機１４Ｃは参加要求２４Ｅをルータ１６Ａに送信する。ルータ１６Ａは受信機１４Ｃを参加済みダウンストリームデバイスとして追加し，続いてマルチキャストストリーム２６と関連付けられた，特定の＜Ｓ，Ｇ＞のためのマルチキャストストリーム２６を複製し，そのパケットのコピーを受信機１４Ｂ及び１４Ｃの双方へ送信する。ある実施例においては，ルータ１６ＡはＭＯアップデートメッセージ２９Ａを受信機１４Ｂへ，ＭＯアップデートメッセージ２９Ｂをルータ１６Ｄへ送信することができ，それによってルータ１６Ａが今，特定の＜Ｓ，Ｇ＞に参加中の２台のダウンストリームデバイスを有することを指示する。
【００３１】
図１Ｃに関して，受信機１４Ｄがその後マルチキャストストリーム２６に関連付けられたマルチキャストコンテンツを受信することを望んでいるとしよう。図１Ｃに示されているように，受信機１４ＤはＭＯパケット２０Ｇ，２０Ｈをそれぞれルータ１６Ｂ及び１６Ｃに送信する。ＭＯパケット２０Ｇ，２０Ｈは，受信機１４Ｄがグループ＜ソースデバイス１２，グループ１＞のためのマルチキャストトラヒックをそれから受信できる２台の可能性のあるアップストリームデバイスを受信機１４Ｄが有することを指示することができる。ＭＯパケット２０Ｇ，２０Ｈはまた，受信機１４Ｄが０台の可能性のあるダウンストリームデバイス及び０台の参加済みダウンストリームデバイスを有することを指示することもできる。
【００３２】
応答として，又はそれ以前に，ルータ１６Ｂ及び１６ＣはそれぞれＭＯ応答パケット２１Ｇ，２１Ｈを受信機１４Ｄへ送信する。ＭＯ応答パケット２１Ｇは，ルータ１６Ｂが既に特定の所望のグループに，ルータ１６Ｂ以外のアップストリームルータを介して参加中の１台のダウンストリームデバイス（すなわち受信機１４Ｃ）を有することを指示する。ＭＯ応答パケット２１Ｈは，ルータ１６Ｃが既にグループに参加中のダウンストリームデバイスを有しないことを指示する。
【００３３】
この情報に基づいて，受信機１４Ｄは，受信機１４Ｄがグループのためのマルチキャストストリームをそれから受信するアップストリームルータとしてルータ１６Ｂを賢く選択することができる。更に，受信機１４Ｄはまた，ルータ１６Ｂ及び１６Ｃを通過するマルチキャストストリーム（示されていない）を有する他のグループについての情報を考慮することができ，またシステム１０の負荷バランスをとるようにアップストリームルータを選択することができる。この例において，受信機１４Ｄは，参加要求２４Ｇをルータ１６Ｂへ送信する。
【００３４】
ルータ１６Ｂは，ＭＯアップデートメッセージ２９Ｃを受信機１４Ｃへ送信して，ルータ１６Ｂが今，グループ＜ソースデバイス１２，グループ１＞に参加中のダウンストリームデバイスを有することを指示できる。受信機１４ＣはＭＯアップデートメッセージ２９Ｃに含まれる情報を，マルチキャスト最適化データとしてデータベースに保存することができる。ルータ１６Ｂは，図１Ａにおけるルータ１６Ａに関して上述したものと類似の方法で，ＭＯ情報及び参加要求をアップストリームでルータ１６Ｅへ伝播させることができる。ルータ１６Ｅが参加要求２４Ｊをルータ１６Ｂから受信すると，ルータ１６ＥはＭＯアップデートメッセージ２９Ｄをルータ１６Ａへ送信して，ルータ１６Ｂが今，グループ＜ソースデバイス１２，グループ１＞に参加中のダウンストリームデバイスを有することを指示することができる。ルータ１６Ｅはその情報をアップストリームで伝播させ，参加要求２４Ｋをソースデバイス１２へ送信する。ソースデバイス１２は次に，グループ＜ソースデバイス１２，グループ１＞のためのマルチキャストストリーム２６’をルータ１６Ｅへ送信し，ルータ１６Ｅはマルチキャストストリーム２６’をルータ１６Ｂへ送信する。ルータ１６Ｂは次に，マルチキャストストリーム２６’を受信機１４Ｄへ送信する。
【００３５】
図１Ｄに関して，受信機１４Ａがその後マルチキャストグループ＜ソースデバイス１２，グループ１＞を離脱するとしよう。図１Ｄに示すように，受信機１４Ａはマルチキャストグループ＜ソースデバイス１２，グループ１＞を離脱するために，離脱要求３２Ａをルータ１６Ｄへ送信する。ルータ１６Ｄは受信機１４Ａをグループから削除し，マルチキャストストリームを受信機１４Ａへ送信するのを停止する。
【００３６】
更に，ルータ１６ＤはＭＯアップデートメッセージ２９Ｅをルータ１６Ａへ送信して，ルータ１６Ｄが今，グループ＜ソースデバイス１２，グループ１＞のメンバであるダウンストリームデバイスを１台だけ有することを指示する。この特定のマルチキャストグループに関して，ルータ１６Ａは，ルータ１６Ｅが同じグループ＜ソースデバイス１２，グループ１＞のためのマルチキャストストリーム２６’を受信していることを指示するルータ１６ＥからのＭＯアップデートメッセージ２９Ｄ（図１Ｃ参照）に基づいて，この情報を賢く利用してアップストリームルータをルータ１６Ｄからルータ１６Ｅへ切り替えることができる。したがって，ルータ１６Ａはグループからの離脱を要求するためにルータ１６Ｄへ離脱要求３２Ｂを送信することができ，グループに参加するために参加要求２４Ｌをルータ１６Ｅへ送信することができる。ルータ１６Ｅはルータ１６Ａをグループ内のダウンストリームデバイスとして追加し，ルータ１６Ａへマルチキャストストリーム２６’を送信することによって，図１Ｄに示す新しいマルチキャストツリーが出来上がる。
【００３７】
図２Ａは，マルチキャスト最適化データをアップストリームデバイスと共有する際にダウンストリームデバイスが用いるマルチキャスト最適化パケット３４の例としての形式を示すブロック図である。パケット３４は拡張マルチキャストプロトコル又は拡張ルーティングプロトコルが用いるパケットであってもよい。代替として，パケット３４はマルチキャスト最適化のために設計された別のプロトコルが利用するものであってもよい。例えば，近隣のデバイスとマルチキャスト最適化データ（ＭＯＤ）を共有し，近隣のデバイスについてのＭＯＤを取得するために，グループ＜Ｓ，Ｇ＞に参加することを期待して，ダウンストリームデバイスはそれが属するアップストリームデバイスのすべてにパケット３４を送信してもよい。この方法によって，ダウンストリームデバイスは特定のマルチキャストグループに参加するために参加要求を送信する先のアップストリームデバイスを賢く選択することができる。
【００３８】
図２Ａの例においては，パケット３４は典型的なパケットのソース及びあて先情報を含むヘッダ３６を含む。例えば，ヘッダ３６はＩＰアドレス，ポート番号，プロトコル又は他の情報を含むことができる。パケット３４はまた，引き続くデータが適用されるそれぞれのマルチキャストグループを識別する，例えばソースデバイス及びグループの番号であるグループ識別子を含むグループ識別フィールド３８（”ＩＤ”）も含む。他の例として，グループ識別子は，マルチキャストアドレスであってもよい。
【００３９】
ＭＯＤフィールド４０Ａ〜４０Ｃ（集合的にＭＯＤフィールド４０と呼ぶ）は，マルチキャスト送信の最適化を補助するためにダウンストリームデバイスが共有することができる情報を含む。例えば，ＭＯＤフィールド４０Ａは，ダウンストリームデバイスが接続され，ダウンストリームデバイスが特定のマルチキャストグループのためのマルチキャストトラヒックを受信する可能性がある，アップストリームデバイスの数を含む。ＭＯＤフィールド４０Ｂは，マルチキャストグループのためのマルチキャストトラヒックを受信するために，参加要求を発行する可能性のあるパケット３４を送信するダウンストリームデバイスに接続されたダウンストリームデバイスの数を含む。ＭＯＤフィールド４０Ｃは，実際に特定のマルチキャストグループに参加中の，パケット３４を送信するデバイスに属するダウンストリームデバイスの数を含む。ＭＯＤフィールド４０は，単に例として示したものであり，他の種類のマルチキャスト最適化データがパケット３４に含まれてもよい。更に，多重マルチキャストグループのためのこの情報又は他の情報を一つのパケットで搬送してもよい。
【００４０】
図２Ｂは，マルチキャスト最適化データをダウンストリームデバイスと共有する際にアップストリームデバイスが用いる，例としてのマルチキャスト最適化応答パケット４２を示すブロック図である。ダウンストリームデバイスからのパケット３４（図２Ａ参照）の受信は，受信アップストリームデバイスがそのアップストリームデバイスの近隣のデバイスについての他のＭＯＤを含む対応する応答パケット４２を送信するきっかけとなる。代替としてアップストリームデバイスは，管理者が設定したとおりに，又はマルチキャストアクション要求に応答して，応答パケット４２を周期的に送信することができる。それとは関係なく，アップストリームデバイスは，マルチキャストの効率を上げるために，パケット３４の形式に適合する１以上のパケットを介して，マルチキャスト最適化情報を近隣のデバイスに伝送することができる。
【００４１】
応答パケット４２は，その応答パケットのためのソース情報及びあて先情報，並びに未解決の特定のマルチキャストグループを識別するグループＩＤフィールド４６を指示するヘッダ４４を含む。ＭＯＤフィールド４８Ａ〜４８Ｃ（集合的にＭＯＤフィールド４８と呼ぶ）は，ネットワーク内の最適なマルチキャストツリーを選択及び形成するのを助けるためにアップストリームデバイスが共有することができる情報を含む。この例においては，ＭＯＤフィールド４８Ａは，識別されたマルチキャストグループのためのマルチキャストトラヒックを配信することができる唯一のアップストリームデバイス（すなわち従属ダウンストリームデバイス）であるパケット４２を送信するアップストリームデバイスに属するダウンストリームデバイスの数を含む。ＭＯＤフィールド４８Ｂは，アップストリームルータからマルチキャストストリームを受信する可能性のあるダウンストリームデバイスであって，マルチキャストグループのためのマルチキャストストリームをそれから受信する他のアップストリームルータに接続されてもいるダウンストリームデバイス（すなわち，非従属ダウンストリームデバイス）の数を含む。ＭＯＤフィールド４８Ｃは，実際にマルチキャストグループに参加中の，パケット４２を送信するデバイスに属するダウンストリームデバイスの数を含む。ＭＯＤフィールド４８は，単に例として示したものであり，他の種類のマルチキャスト最適化データをパケット４２に含めてもよい。更に，多重マルチキャストグループのためのこの情報又は他の情報を，一つのパケットで搬送してもよい。
【００４２】
図３は，近隣のアップストリームルータとマルチキャスト最適化データを共有する，図１Ａ〜１Ｄの任意の受信機１４のような受信機の例としての動作を示すフローチャートである。図３は受信機１４Ｃに関して示されている。
【００４３】
最初に，（典型的にはユーザ要求に応答して）受信機１４Ｃがグループ＜Ｓ，Ｇ＞のためのマルチキャストストリームを受信することを所望し，受信機１４Ｃがグループに参加する（ステップ５０）。受信機１４Ｃは，”アップストリーム”の適切な定義に従って，可能性のあるアップストリームルータを決定する（ステップ５２）。ある実施例においては，受信機１４Ｃはソースデバイスへの最短経路を計算することができる。等価コスト計量を有するソースへの多重経路があるかも知れず，受信機１４Ｃは，ＭＯＤを用いて最短経路を選択することができる。代替として，受信機１４Ｃは最短経路を計算せずに，その代わりにソースデバイスへのすべての可能性のある経路を考慮するかも知れない。どの場合においても，受信機１４Ｃは参加要求を送信する先のアップストリームルータを決定する必要がある。
【００４４】
受信機１４Ｃは，マルチキャスト最適化（ＭＯ）パケット３４（図２Ａ参照）を，ソースデバイスへのすべての経路上，若しくはコスト計量又は長さに基づくサブセットの経路上にあるアップストリームルータのそれぞれ，すなわちアップストリームルータ２２Ａ及び２２Ｂへ送信する（ステップ５４）。受信機１４Ｃは次に，それぞれのアップストリームルータからＭＯ応答パケット４２（図２Ｂ参照）を受信する（ステップ５６）。受信機１４Ｃは，ＭＯ応答パケット内に含まれるマルチキャスト最適化データをデータベースに保存することができる。受信機１４Ｃは，マルチキャスト最適化データに基づいてアップストリームルータを選択する（ステップ５８）。例えば受信機１４Ｃは，アップストリームルータが既にグループのためのマルチキャストトラヒックを受信しているかどうかを考慮してもよい。他の例として，受信機１４Ｃはルータ１６を順序付けるために，マルチキャストトラヒック重複の最小化，現在の帯域幅レベルでの負荷バランス，及び通信遅延を有する経路の回避のような，任意のさまざまな基準を利用してもよい。受信機１４Ｃは，選択したアップストリームルータへ参加要求を送信し（ステップ６０），選択したアップストリームルータからマルチキャストパケットを受信する（ステップ６２）。
【００４５】
図４は，近隣のデバイスとマルチキャスト最適化データを共有する，図１Ａ〜１Ｄに示す任意のルータ１６のようなアップストリームルータの例としての動作を示すフローチャートである。図４は，ルータ１６Ａに関して示されている。ルータ１６Ａは受信機１４Ｂ及び１４Ｃのどちらか一つ又は双方からＭＯパケット３４（図２Ａ）を受信することができる（ステップ６４）。例えば，ルータ１６Ａは，受信機１４Ｂがこのグループのための唯一のアップストリームルータを有する，すなわち受信機１４Ｂが対応するグループのためのマルチキャストコンテンツを受信するためにルータ１６Ａに従属していることを指示するＭＯパケットを受信機１４Ｂから受信することができる。ルータ１６Ａはまた，受信機１４Ｃがこのグループのための可能性のある２台のアップストリームルータを有することを指示するＭＯパケットを受信機１４Ｃから受信することができる。
【００４６】
ルータ１６Ａは，ＭＯ応答パケット４２（図２Ｂ参照）を受信機１４Ｂ及び１４Ｃのうち一つ又は双方へ送信する（ステップ６６）。ＭＯ応答パケット４２は，例えばルータ１６Ａが１台の従属ダウンストリームデバイスと，１台の非従属ダウンストリームデバイスを有することを指示することができる。ルータ１６Ａはこのようにして，それに属するダウンストリームデバイスのそれぞれから受信したＭＯデータを，すべての他のダウンストリームデバイスと共有する。この方法によって，ルータ１６Ａはシステム１０内で情報を交換することを容易にし，それでダウンストリームデバイスはマルチキャストを受信するための最適なアップストリームルータを賢く選択することができる。
【００４７】
ルータ１６Ａは，受信機から参加要求を受信することができる（ステップ６８）。ルータ１６Ａが要求されたグループのためのマルチキャストパケットをまだ受信していないとき，ルータ１６Ａは，ＭＯデータ及び参加要求を次のアップストリームデバイスへ伝播させることができる。ある実施例においては，ルータ１６Ａは選択的に，ソースデバイスへの最短経路を計算することができる。ルータ１６Ａは，ＭＯパケット３４をルータ１６Ａの他のアップストリームルータ，すなわち１６Ｄ及び１６Ｅへ送信することができ（ステップ７０），そしてＭＯ応答パケット４２をルータ１６Ｄ及び１６Ｅから受信することができる（ステップ７２）。ルータ１６Ａは，受信したマルチキャスト最適化データに基づいて，グループのためのマルチキャストコンテンツを受信する先のアップストリームルータを選択し（ステップ７４），選択したアップストリームルータへ参加要求を送信し（ステップ７６），そして選択したアップストリームルータからマルチキャストパケットを受信することができる（ステップ７８）。
【００４８】
図５は，本発明の実施例に従ってマルチキャスト最適化データ（ＭＯＤ）８１を格納し，配信し，そして受信する例としてのルータ８０を示すブロック図である。ルータ８０は，図１Ａ〜１Ｄに示すルータ１６と大体類似して動作することができる。ある場合には，ルータ８０は，エッジルータであってもよく，そして受信機１４はネットワークスイッチ，例えばＤＳＬＡＭ又はイーサネット（登録商標）スイッチを介してルータ８０に接続することができる。代替として，ルータ８０は，受信機１４に直接接続されない中間ルータであってもよい。一般に，ルータ８０は，ＭＯＤ８１を含むＭＯパケット及びＭＯ応答パケットを受信及び送信することができる。
【００４９】
図示された実施例において，ルータ８０は，入リンク８４Ａ〜８４Ｎ（”入リンク８４”）上のパケットを受信し，出リンク８６Ａ〜８６Ｎ（”出リンク８６”）上のパケットを送信するインタフェースカード８２Ａ〜８２Ｎ（”ＩＦＣ８２”）を含む。ＩＦＣ８２は，高速スイッチ８８及びリンク９０によって相互接続されている。一つの例においては，スイッチ８８はスイッチ機構，スイッチ装置，構成可能ネットワークスイッチ又はハブ，及びその類似物を含む。リンク９０は，集積回路内の電気的経路，外部データバス，光リンク，ネットワーク接続，無線接続，又は他の種類の通信経路のような任意の形態の通信経路を含む。ＩＦＣ８２は，複数のインタフェースポート（示されていない）を介して入リンク８４と出リンク８６とに結合されている。
【００５０】
ルータ８０はまた，ルーティング情報９６を，ルータ８０が接続されている現在のネットワーク及び他のネットワークエンティティのトポロジを反映するように維持する制御ユニット９４も含む。一般に，ルータ８０が入リンク８４の一つを介してユニキャストパケットを受信すると，制御ユニット９４はルーティング情報９６に従ってそのパケットのあて先を判定し，そのあて先に基づいて出リンク８６の一つへ，そのパケットを出力する。
【００５１】
制御ユニット９４は更に，マルチキャスト転送情報９８を維持する。ルータ８０が入リンク８４の一つを経由してマルチキャストパケットを受信すると，制御ユニット９４はマルチキャスト転送情報９８に従って一組の出リンク８６へ，そのパケットを転送する。制御ユニット９４は，例えばＯＳＰＦ，ＬＤＰ，ＭＰＬＳ，ＩＧＰなどのルーティングプロトコル１００，及び例えばＩＧＭＰなどのマルチキャストプロトコル１０２のための動作環境を提供する。ルータ８０は，例えば参加要求及び離脱要求などのマルチキャストアクション要求を送信及び受信するためにマルチキャストプロトコル１０２を用いることができる。他の実施例においては，他のプロトコルが制御ユニット９４の中で実行されてもよい。
【００５２】
例えば，ルーティングプロトコル１００及びマルチキャストプロトコル１０２のうち一つ又は双方を，マルチキャストを最適化するためにＭＯＤ８１が他のデバイスへ搬送され，かつ他のデバイスから受信されるような方法で拡張することができる。ここで説明したように，プロトコル拡張によって可変数のＭＯＤフィールドを他のデバイスへ伝送できるようになる。他の実施例においては，ＭＯＤ８１を交換するために，別のプロトコルを確立してもよい。例えば，可能性のあるアップストリームデバイスの数，可能性のあるダウンストリームデバイスの数，参加中のダウンストリームデバイスの数，従属ダウンストリームデバイスの数，非従属ダウンストリームデバイスの数又は他のＭＯＤをここで説明したテクニックに従って規定してもよい。
【００５３】
図５の例においては，マルチキャストプロトコル１０２がＭＯＤ８１を維持する。ルータ８０は，マルチキャストプロトコル１０２又はルーティングプロトコル１００を用いて出リンク８６のうちの一つを介してＭＯＤを含むＭＯパケットを送信し，また入リンク８４のうち一つを介してＭＯＤを含むＭＯ応答パケットを受信する。又はＭＯアップデートメッセージを送信及び受信する。ルータ８０が，図２ＡのＭＯパケット３４と類似のＭＯパケットを送信するとき，ルータ８０はＭＯパケットのフィールドをＭＯＤ８１からのデータで埋めることができる。ルータ８０が，図２ＢのＭＯ応答パケット４２に類似のＭＯ応答パケットを受信するとき，ルータ８０はＭＯ応答パケットのフィールド内に含まれる情報をＭＯＤ８１に保存することができる。制御ユニット９４は，ルーティング情報９６，マルチキャスト転送情報９８，及びＭＯＤ８１を，テーブル，データベース，リンクリスト，基数ツリー，フラットファイル，又は任意の他のデータ構造のうち１以上の形態で維持する。
【００５４】
動作中ルータ８０は，特定のグループのための参加要求を送信するためのアップストリームルータを決定するときにＭＯＤ８１を適用する。特に，ルータ８０がグループに参加する必要があるとき，ルータ８０は，マルチキャストコンテンツがグループのための近隣のデバイスへ実際に送信されているか，又は送信される可能性があるかを知るために，ＭＯＤ８１を含むＭＯパケット又はＭＯ応答パケットを送信又は受信することができる。ルータ８０は，ＭＯＤ８１を用いてどのアップストリームルータへ参加要求を送信するかを決定することができる。より特定すれば，ルータ８０は，アップストリームルータのうちの一つが，グループのためのマルチキャストコンテンツを既に受信しているかどうかを考慮することができる。ルータ８０はまた，受信するマルチキャストコンテンツのためのアップストリームルータ選択における負荷バランスを，ＭＯＤ８１を用いて考慮することができる。
【００５５】
図５に示されたルータ８０のアーキテクチャは，例示の目的で示されたものに過ぎない。本発明は，このアーキテクチャに限定されない。他の実施例においては，ルータ８０をさまざまな方法で構成することができる。例えば一つの実施例においては，制御ユニット９４及びその対応する機能は，ＩＦＣ８２内で配信することができる。他の実施例においては，制御ユニット９４は，ルーティング機能を実行し，ルーティング情報ベース（ＲＩＢ），例えばルーティング情報９６，を維持するルーティングエンジンと，ＲＩＢに従って生成される転送情報ベース（ＦＩＢ）に基づいてパケットの転送を実行する転送エンジンとを含む。
【００５６】
制御ユニット９４は，ソフトウェアだけ，又はハードウェアだけで実装してもよいし，若しくはソフトウェア，ハードウェア又はファームウェアの組合せとして実装してもよい。例えば，制御ユニット９４は，ソフトウェア命令を実行する１以上のプロセッサを含むことができる。この場合，ルーティングプロトコル１００及びマルチキャストプロトコル１０２のような制御ユニット９４のさまざまなソフトウェアモジュールは，計算機メモリ又はハードウェアディスクのような計算機可読媒体上に格納される実行可能な命令を含む。
【００５７】
図６は，マルチキャスト最適化データを格納する例としてのデータ構造１０４を示すブロック図である。図６の例においては，例としてのデータ構造１０４は，受信機１４Ｃの制御ユニットによって管理される。例えば，データ構造１０４は，図５の制御ユニット９４によって管理されるＭＯＤ８１に類似したものであってもよい。受信機１４Ｃは，ＭＯパケット内で受信されたＭＯＤを用いて，データ構造１０４の行と列とを保持する。データ構造１０４はネットワークデバイスを指示するデバイス列１０６を含み，対応する行にそのネットワークデバイスのＭＯＤが格納されている。データ構造１０４はまた，ソースデバイス列１０８及びマルチキャストグループ列１１０も含み，それらは共にマルチキャストグループ＜Ｓ，Ｇ＞を指示する。
【００５８】
データ構造１０４の列１１２は対応するデバイスが有する可能性のあるアップストリームデバイス（”ＮＰＵ”）の数を格納し，一方列１１４は対応するデバイスが有する可能性のあるダウンストリームデバイス（”ＮＰＤ”）の数を格納する。列１１６は対応するデバイスが有する参加中のダウンストリームデバイス（”ＪＤ”）の数を格納し，列１１８は対応するデバイスが有する従属ダウンストリームデバイス（”ＮＤＤ”）の数を格納し，そして列１２０は対応するデバイスが有する非従属ダウンストリームデバイス（”ＮＮＤＤ”）の数を格納する。受信機１４Ｃが，例えばＭＯパケット，ＭＯ応答パケット又はＭＯアップデートメッセージなどのＭＯメッセージを受信すると，受信機１４Ｃの制御ユニットはデータ構造１０４内に新しいエントリを追加するか，又は既存のエントリを更新する。
【００５９】
図６の例においては，最初の３行がデバイス１０．１．１．２に対応し，この例ではそれは受信機１４ＣのためのＩＰアドレスである。第４，第５の行はデバイス１０．１．１．６（ルータ１６ＡのためのＩＰアドレス）に対応し，最後の行はデバイス１０．１．８．７（ルータ１６ＢのためのＩＰアドレス）に対応する。第１行はマルチキャストソースデバイス２２４．０．０．１９５（ソースデバイス１２のためのマルチキャストアドレス），グループ１に対応し，第２行はソースデバイス２２４．０．０．１９５，グループ２に対応する。＜ソースデバイス１２，グループ１＞は図１Ａ〜１Ｄにおいて議論されたマルチキャストグループである。第３行は他のマルチキャストソースデバイス２２４．０．０．２００，（図１Ａ〜１Ｄには示されていない）に対応する。
【００６０】
図６の例において，受信機１４Ｃはデータ構造１０４内にそれ自身に関するＭＯＤを維持する。例えば，＜ソースデバイス１２，グループ１＞及び＜ソースデバイス１２，グループ２＞のために，受信機１４Ｃは２台の可能性のあるアップストリームデバイス，０台の可能性のあるダウンストリームデバイス及び結果的に０台の参加中のダウンストリームデバイス，０台の従属ダウンストリームデバイス，ならびに０台の非従属ダウンストリームデバイスを有する。
【００６１】
受信機１４Ｃはまた，ＭＯパケットに応答してルータ１６Ａ及び１６Ｂが受信機１４Ｃへ送信したＭＯ応答パケットを介して，ルータ１６Ａ及び１６ＢからＭＯＤを取得する。受信機１４ＣはこのＭＯＤをデータ構造１０４に保存する。例えば，受信機１４Ｃは第４行に，ルータ１６Ａが＜ソースデバイス１２，グループ１＞のために２台の可能性のあるアップストリームデバイス，２台の可能性のあるダウンストリームデバイス，１台の参加中のダウンストリームデバイス，１台の従属ダウンストリームデバイス及び１台の非従属ダウンストリームデバイスを有することを格納する。他の例として，受信機１４Ｃは最後の行に，ルータ１６Ｂが＜ソースデバイス１２，グループ１＞のために１台の可能性のあるアップストリームデバイス，２台の可能性のあるダウンストリームデバイス，０台の参加中のダウンストリームデバイス，０台の従属ダウンストリームデバイス及び２台の非従属ダウンリンクを有することを格納する。
【００６２】
図６のデータ構造１０４は，単なる例示である。例としてのデータ構造１０４に示されていない他の種類のＭＯＤを，受信機１４Ｃが格納してもよい。以上説明したように，図にはテーブルの形態で示されているが，データ構造１０４は，テーブル，データベース，リンクリスト，基数ツリー，フラットファイル，又は任意の他のデータ構造のうち１以上の形態で維持することができる。
【００６３】
図７は，ローカルエリアネットワーク（ＬＡＮ）環境１２６を示すブロック図であり，そこでソースデバイス１２８は，グループのためのマルチキャストデータストリーム１３０を，１台以上の中間デバイス１３４Ａ〜１３４Ｂ（集合的に中間デバイス１３４と呼ぶ）を介してバックボーン１３２に注入する。受信機１３６Ａ〜１３６Ｃ（集合的に受信機１３６と呼ぶ）は，バックボーン１３２上を流れるマルチキャストデータストリーム１３０にアクセスし，共有することができる。ここで説明する本発明の原理は，ＬＡＮ環境１２６にすぐに適用できる。例えば，受信機１３６Ｂは，近隣のデバイスにＭＯパケットを送信し，またＭＯＤを取得するために近隣のデバイスからＭＯ応答パケットを受信することができる。受信機１３６ＢはＭＯＤを用いることによって，グループに参加するために用いるアップストリームルータをより賢く選択することができる。例えば，ソースデバイス１２８は既に中間デバイス１３４Ａへマルチキャストデータストリーム１３０を送信しているので，この場合受信機１３６Ｂは，参加要求を送信するために中間デバイス１３４Ａを選択することができる。この方法によって，ソースデバイス１２８はＬＡＮ環境１２６へ重複してデータストリームを注入する必要がない。
【００６４】
図８は，他の例としての計算機システム１３８を示すブロック図であり，そこで受信機１４０Ａ〜１４０Ｂ（集合的に受信機１４０と呼ぶ）は，同じマルチキャストグループのための複数の”インスタンス”へマルチキャスト参加要求１４２を送信する。以下詳細に説明するように，受信機１４０とルータ１４４との間で交換される制御情報は，インスタンスの数を利用するように拡張され，それで一つのマルチキャストグループが多数のマルチキャストツリーを設定する能力を持たせ，それぞれのツリーがソースデバイス１４６から受信機１４０へさまざまな経路を取ることができる。ソースデバイス１４６は，それでマルチキャストコンテンツをグループへ供給するときにさまざまなツリーを利用することができ，ソースデバイスが等価コストマルチパス（ＥＣＭＰ）のような原理を利用して計算機ネットワークを介したコンテンツ配信の負荷分散，又は他の制御をすることを可能にする。
【００６５】
より特定すれば，さまざまなインスタンスが一つのソースデバイス１４６からのマルチキャストグループのための複数のマルチキャストツリーに対応する。マルチキャストツリーを形成するために受信機１４０は，同じマルチキャストグループのための複数の参加要求１４２を，ソースデバイス１４６へのさまざまな経路に沿ったルータ１４４Ａ〜１４４Ｆのサブセットへ送信する。一つの実施例においては，システム１３８における各デバイスは要求されるインスタンスの数を指定するパラメータで設定される。特定のソースデバイス及びマルチキャストグループ，＜ソースデバイスＳ，グループＧ＞のための複数のインスタンスの数はＮで記すことができる。例えば，デバイスは，管理者又はソフトウェアエージェントが設定することができる。インスタンスの数は，ネットワーク内のすべてのマルチキャストグループに対して同じであってもよいし，グループごとに独立に決定してもよい。代替として，デバイスは，システム１３８の現在のトポロジに基づいて，特定のグループのために最適なＮを選択するために情報を交換することができ，また選択として，協調的にＮを選択するために上述したマルチキャスト最適化データ（ＭＯＤ）を利用してもよい。デバイスは，各デバイスが正しくインスタンス数を指定しているか検証するために，例えばマルチキャスト仮想専用ネットワーク（ＭＶＰＮ）プロトコル，又はマルチキャスト仮想専用ローカルネットワークサービス（ＭＶＰＬＳ）プロトコルなどのディスカバリプロトコルを動作させてもよい。デバイスが正しいインスタンス数を知らないときは，これはデバイスが一つのマルチキャストグループのために重複したマルチキャストストリームを受信したり，重複するマルチキャストストリームを受信しない結果となることがある。
【００６６】
図８の例において，＜ソースデバイス１４６，グループ１＞に対してＮ＝３と仮定しよう。したがって，各受信機１４０は各インスタンスに１つづつ，３個の参加要求１４２を送信する。参加要求１４２は，グループ識別子にインスタンス番号を含むように拡張することができる。各受信機１４０は，それぞれの参加要求１４２をどの経路に沿って送信するかを決定する。受信機１４０は，さまざまなインスタンスのための代替のマルチキャストツリーを構築するために，アップストリームルータ内に参加要求を配信するように試みてもよい。受信機１４０はまた，上述のマルチキャスト最適化テクニックを用いて，例えばそのインスタンスへの参加要求を既に受信しているアップストリームへ特定のインスタンスへ参加要求を送信するように，各インスタンスへの参加要求を送信する先のアップストリームルータを賢く選択することができる。
【００６７】
この例においては，受信機１４０Ａは始めに，ルータ１４４Ａへ最初の参加要求１４２Ａを送信する。参加要求１４２Ａは，＜ソースデバイス１４６，グループ１，インスタンス３＞（以降，＜Ｓ，Ｇ，３＞とする）のためのマルチキャストツリーに参加を要求する。受信機１４０Ａはまた，それぞれ＜Ｓ，Ｇ，１＞及び＜Ｓ，Ｇ，２＞へ参加を要求する参加要求１４２Ｂ及び１４２Ｃをルータ１４４Ｂへ送信する。受信機１４０Ｂは参加要求１４２Ｄをルータ１４４Ａへ送信して＜Ｓ，Ｇ，３＞への参加を要求し，参加要求１４２Ｅをルータ１４４Ｂへ送信して＜Ｓ，Ｇ，１＞への参加を要求し，そして参加要求１４２Ｆをルータ１４４Ｃへ送信して＜Ｓ，Ｇ，２＞への参加を要求する。この方法によって，マルチキャスト参加アクションは，特定のマルチキャストグループ及びソースデバイスを指定するとき，インスタンス番号を含むように拡張されている。
【００６８】
ルータ１４４Ａは＜Ｓ，Ｇ，３＞のための参加要求１４２Ａ及び１４２Ｄを受信する。ルータ１４４Ａは，ルータ１４４Ａが既に＜Ｓ，Ｇ，３＞のための状態を有するかどうか，すなわちルータ１４４Ａが＜Ｓ，Ｇ，３＞のためのマルチキャスト転送情報９８（図５参照）に登録されているかどうかを判定する。言い換えれば，ルータ１４４Ａは，同じソースデバイス，グループ及びインスタンス（この例では＜Ｓ，Ｇ，３＞）への参加要求を既に受信しているかどうかを判定する。受信していないときは，ルータ１４４Ａは＜Ｓ，Ｇ，３＞に参加するために，参加要求１４２Ｇをアップストリームルータへ送信する。そうでなければ，ルータ１４４Ａは参加要求を転送しない。なぜならばこれは冗長な参加要求であり，同じマルチキャストコンテンツの多重コピーを受信する結果となるからである。この方法で，ルータ１４４は選択的に参加要求を転送し，それによって，たとえ各受信機が同じグループに関連付けられた複数インスタンスへのリーフノードであっても，同じマルチキャストコンテンツの重複したコピーをどの受信デバイスも受信しないことを保証する。
【００６９】
図８の例において，ルータ１４４Ａはルータ１４４Ｄを選択して，参加要求１４２Ｇをそこへ転送する。ルータ１４４Ｄは次に，ルータ１４４Ｄが＜Ｓ，Ｇ，３＞のための状態を既に有するかどうかを同様に判定し，有していないときは＜Ｓ，Ｇ，３＞のためのソースデバイス１４６へ参加要求１４２Ｌを送信する。この方法で，受信機１４０Ａ及び１４０Ｂはマルチキャストグループのインスタンス３のためのマルチキャストツリーに参加する。
【００７０】
類似の方法で，ルータ１４４Ｂは＜Ｓ，Ｇ，１＞のための参加要求１４２Ｂ及び１４２Ｅ，並びに＜Ｓ，Ｇ，２＞のための１４２Ｃを受信する。ルータ１４４Ｂはルータ１４４Ｂが＜Ｓ，Ｇ，１＞及び＜Ｓ，Ｇ，２＞のための状態を既に有するかどうかを判定し，有していなければ，＜Ｓ，Ｇ，１＞及び＜Ｓ，Ｇ，２＞へ参加するために，アップストリームルータへ参加要求１４２Ｈ及び１４２Ｊを送信する。ここでルータ１４４Ｂは１台のアップストリームルータしか有しないので，ルータ１４４Ｂは双方の参加要求をルータ１４４Ｅへ送信する。ルータ１４４Ｅは参加要求を受信し,ルータ１４４Ｅがインスタンスのための状態を既に有するかどうかを判定し，有しなければ＜Ｓ，Ｇ，１＞及び＜Ｓ，Ｇ，２＞にそれぞれ参加するために参加要求１４２Ｍ及び１４２Ｎをソースデバイス１４６へ送信する。この方法で受信機１４０Ａはマルチキャストグループのインスタンス１及び２のためのマルチキャストツリーに参加し，また１４０Ｂはマルチキャストグループのインスタンス１のためのマルチキャストツリーに参加する。
【００７１】
ルータ１４４Ｃは，＜Ｓ，Ｇ，２＞に参加するための参加要求１４２Ｆを受信し，ルータ１４４Ｃが＜Ｓ，Ｇ，２＞のための状態を有するかどうかを判定し，有しなければ＜Ｓ，Ｇ，２＞に参加するために参加要求１４２Ｋをルータ１４４Ｆへ送信する。ルータ１４４Ｆは参加要求１４２Ｋを受信し，ルータ１４４Ｆが＜Ｓ，Ｇ，２＞のための状態を有するかどうかを判定し，有しなければ＜Ｓ，Ｇ，２＞に参加するために参加要求１４２Ｐをソースデバイス１４６へ送信する。この方法によって，受信機１４０Ｂはマルチキャストグループのインスタンス２のためのマルチキャストツリーに参加する。受信機１４０及びルータ１４４は，マルチキャストグループのインスタンスを離脱するために，特定のインスタンスを規定する離脱要求を類似の方法で発行する。
【００７２】
図９は，複数のマルチキャストツリー１５０Ａ，１５０Ｂ及び１５０Ｃ（集合的にマルチキャストツリー１５０と呼ぶ）が，マルチキャストグループ＜ソースデバイス１４６，グループ１＞のインスタンス３，１，及び２のためにそれぞれ形成された後の図８の例としてのシステム１３８を示すブロック図である。
【００７３】
実際は，ソースデバイス１４６がマルチキャストグループ１のためのマルチキャストフローを受信すると，ソースデバイス１４６はそのマルチキャストフローを送信するためにマルチキャストツリー１５０のうち一つを選択する。例えば，ソースデバイス１４６は，インスタンス＜Ｓ，Ｇ，１＞，＜Ｓ，Ｇ，２＞又は＜Ｓ，Ｇ，３＞の中から一つを選択するために，ユニキャスト等価コストマルチパス（ＥＣＭＰ）が用いるようなフローハッシュ関数を用いることができる。他の例として，ソースデバイス１４６は，どのマルチキャストツリー１５０が最も混雑していないか，又は最も広い帯域幅を得られるかを判定するためにネットワーク１３８を監視してもよい。
【００７４】
マルチキャストツリー１５０は，完全に分離されたツリーである必要はない。マルチキャストツリー１５０は部分的に重複してもよいし，又は完全に重複してさえもよい。図９の例においては，マルチキャストツリー１５０Ｂの一部はマルチキャストツリー１５０Ｃの一部と重複している。マルチキャストツリーがさまざまな経路を通過するように，可能ならば重複を避けるためにマルチキャストツリーを広げるのが望ましい。
【００７５】
典型的には，ソースデバイス１４６は，受信機１４０においてパケットを並べ替えなくてもよいように，マルチキャストフロー内のすべてのパケットを一つのマルチキャストツリーを使って送信する。しかしながらある実施例においては，ソースデバイス１４６はマルチキャストフロー内のパケットを多重マルチキャストツリー１５０を用いてラウンドロビンで送信し，受信機１４０は受信時にパケットを並べ替える。どの場合においても，マルチキャストフローを送信するためにソースデバイス１４６がどのマルチキャストツリー１５０を選択しようとも，受信機１４０はマルチキャストフロー内の各マルチキャストパケットの一つのコピーだけをそれぞれ受信する。
【００７６】
ソースデバイス１４６が，マルチキャストコンテンツを送信するためにインスタンス１に対応するマルチキャストツリー，すなわちマルチキャストツリー１５０Ｂを選択したとしよう。この場合，ソースデバイス１４６はルータ１４４Ｅへ各パケットの一つのコピーを送信する。ルータ１４４Ｅはそのパケットを複製し，各パケットの一つのコピーを受信機１４０Ａへ，もう一つを受信機１４０Ｂへ送信する。この方法によって，受信機１４０はそれぞれ，マルチキャストフロー内の各パケットのコピーを一つだけ受信する。
【００７７】
例えば，ルータ１４４Ｅが動作不能になったときは，ソースデバイス１４６はグループ１のためのマルチキャストフローをマルチキャストツリー１５０Ｂを介して送信するのを停止し，マルチキャストツリー１５０Ａを介してマルチキャストフローを送信するように切り替える。この方法でソースデバイス１４６は，予め確立されているマルチキャストツリー間を継ぎ目なく切り替えることができ，それでマルチキャストを中断するのを回避してネットワーク１３８へのマルチキャストサービスを改善することができる。
【００７８】
図１０は，インスタンス番号を含むように拡張されたパケット１５２の例としてのマルチキャストパケット形式を示すブロック図である。例えば，パケット１５２は参加要求，離脱要求，プロトコル独立マルチキャスト（ＰＩＭ）ハローメッセージ，又は他のマルチキャスト制御メッセージをカプセル化するＩＰパケットであってもよい。パケット１５２は，例えばＰＩＭ，ポイント−ツ−マルチポイント（Ｐ２ＭＰ）ラベル配信プロトコル（ＬＤＰ），又はマルチキャスト最適化のために設計された別のプロトコルなどの拡張されたマルチキャストプロトコルが用いてもよい。受信機１４０又はアップストリームルータ１４４（図８参照）は，マルチキャストグループの要求されたＮ個のインスタンスのそれぞれにパケット１５２を送信することができる。
【００７９】
図１０の例において，パケット１５２は典型的なパケットソース及びあて先情報を含むヘッダ１５４を含む。例えば，ヘッダ１５４はＩＰアドレス，ポート番号，チェックサム，プロトコル又は他の情報を含むことができる。パケット１５２はまた，グループ識別フィールド１５６Ａ〜１５６Ｃ（集合的にグループ識別フィールド１５６と呼ぶ）も含む。ソース識別フィールド１５６Ａは，マルチキャストトラヒックのソースのための識別子を含む。グループ識別フィールド１５６Ｂは，グループを識別するグループ識別子（例えばマルチキャストアドレス）を含む。インスタンスフィールド１５６Ｃはインスタンス番号を識別する。タイプフィールド１５８は，特定の制御メッセージと関連付けられた値を含む。
【００８０】
図１１は，本発明の原理に従ってＥＣＭＰマルチキャストツリーを形成する際の，例としての受信機，アップストリームルータ及びシステムのソースの例としての動作を示すフローチャートである。例示のために，図１１を図８の受信機１４０Ａ，ルータ１４４Ａ及びソースデバイス１４６に関して説明する。
【００８１】
受信機１４０Ａは，特定のグループのためのインスタンス数Ｎを受信機１４０Ａに通知する設定情報を受信する（ステップ１６０）。この例においては，受信機１４０Ａはマルチキャストグループ＜ソースデバイス１４６，グループ１＞，インスタンス数３に対する情報で設定されている。管理者又はソフトウェアエージェントがこの設定情報を受信機１４０Ａに提供してもよいし，受信機１４０Ａがディスカバリプロトコルを用いて近隣のデバイスと情報を交換し，恐らくは事前に交換されているＭＯＤを用いて最適なインスタンスの数を決定してもよい。
【００８２】
受信機１４０Ａが，恐らくはユーザの要求に応答して，＜ソースデバイス１４６，グループ１＞のためのマルチキャストコンテンツを受信しようと所望すると，受信機１４０Ａは，＜ソースデバイス１４６，グループ１＞のための３個のインスタンスにそれぞれ一つずつ，３個の参加要求をアップストリームルータへ送信する（ステップ１６２）。参加要求は，図１０のパケット１５２に類似のものである。可能ならば，受信機１４０Ａはアップストリームルータ内に参加要求を配信することができる。受信機１４０Ａはまた，選択的に，近隣のデバイスとマルチキャスト最適化データを共有するために，上述のマルチキャスト最適化テクニックを利用してもよい。この方法で，受信機１４０Ａは参加要求を送信する先のアップストリームルータについて，より賢い判断を行うことができる。例えば，受信機１４０Ａは，図２ＡのＭＯパケット３４に類似するがパケットが関係するインスタンスの数を指定する追加フィールドを含む，ＭＯパケットを送信することができる。受信機１４０Ａはそのような３個のインスタンスのそれぞれに関するＭＯパケットを，すべてのアップストリームルータへ送信することができ，応答としてアップストリームルータから，図２ＢのＭＯ応答パケット４２に類似するがパケットが関係するインスタンス数を指定する追加フィールドを含む，ＭＯ応答パケットを受信することができる。
【００８３】
受信機１４０Ａは，ルータ１４４Ａが＜ソースデバイス１４６，グループ１，インスタンス３＞のための１台の参加中のダウンストリームデバイス（すなわち受信機１４０Ｂ）を有することを受信機１４０Ａに通知するＭＯ応答パケットをルータ１４４Ａから受信することができ，またルータ１４４Ｂが＜ソースデバイス１４６，グループ１，インスタンス１＞のための１台の参加中のダウンストリームデバイス（すなわち受信機１４０Ｂ）を有することを受信機１４０Ａに通知するＭＯ応答パケットをルータ１４４Ｂから受信することができる。このＭＯＤを用いて，受信機１４０Ａは＜Ｓ，Ｇ，３＞のための参加要求をルータ１４４Ａへ，＜Ｓ，Ｇ，１＞に対する参加要求をルータ１４４Ｂへ送信することを判断できる。
【００８４】
ルータ１４４Ａは，それに属するダウンストリームデバイスから１以上の参加要求を受信する（ステップ１６４）。ルータ１４４Ａは，参加要求に指定されたインスタンスのための状態が既に存在するかどうか，すなわちルータ１４４Ａが既にそのインスタンスのためのマルチキャストツリーの一部であるかどうかを判定することができる（ステップ１６６）。ルータ１４４Ａがそのインスタンスのための状態を有しなければ，ルータ１４４Ａはそのインスタンスのためにマルチキャスト転送情報９８の中にエントリを作成し，アップストリームの近隣デバイスのうち一つに参加メッセージを送信する（ステップ１６８）。ルータ１４４Ａが既にそのインスタンスのための状態を有していれば，ルータ１４４Ａは，グループ及びインスタンスのためのマルチキャストコンテンツが受信機１４０Ａへ送信されるように，ダウンストリームデバイス（例えば受信機１４０Ａ）を追加する（ステップ１７０）。ルータ１４４Ａとソースデバイス１４６との間の追加アップストリームルータはステップ１６４〜１７０と類似して動作する。
【００８５】
ソースデバイス１４６は＜ソースデバイス１４６，グループ１＞のためのさまざまなＮ個のインスタンスのための参加要求を受信する（ステップ１７２）。この方法によって，多重マルチキャストツリーは受信機１４０及びソースデバイス１４６との間に形成される。ソースデバイス１４６が＜ソースデバイス１４６，グループ１＞のためのマルチキャストトラヒックを受信すると，ソースデバイス１４６はインスタンスに対応するさまざまなマルチキャストツリーのうち一つを，例えばユニキャストＥＣＭＰフローハッシュ関数を用いて選択し（ステップ１７４），マルチキャストコンテンツを選択されたマルチキャストツリーを介して送信する（ステップ１７６）。
【００８６】
受信機１４０及びルータ１４４は，図５のルータ８０に類似のものであってもよい。本発明の原理に従って，マルチキャストプロトコル１０２（例えばＰＩＭ）をマルチキャストグループのインスタンスごとに動作するように拡張することができる。例えばルータ８０は，マルチキャストプロトコル１０２を用いてマルチキャストグループの特定のインスタンスに参加又はインスタンスから離脱するための，拡張された参加要求及び離脱要求を送信及び受信することができる。マルチキャスト転送情報９８及びＭＯＤ８１はルータ８０が属する各マルチキャストグループの複数のインスタンスのそれぞれに対する情報を含む。
【００８７】
本発明のさまざまな実施例が説明された。これらの実施例及び他の実施例は本願請求項の範囲内に入るものである。
【図面の簡単な説明】
【００８８】
【図１Ａ】本発明の原理に一致する方法で，受信デバイスと中間ルータがマルチキャスト最適化データ（ＭＯＤ）を交換し，マルチキャストトラヒックを受信するためのアップストリームルータを選択する例としてのシステムを示すブロック図である。
【図１Ｂ】本発明の原理に一致する方法で，受信デバイスと中間ルータがマルチキャスト最適化データ（ＭＯＤ）を交換し，マルチキャストトラヒックを受信するためのアップストリームルータを選択する例としてのシステムを示すブロック図である。
【図１Ｃ】本発明の原理に一致する方法で，受信デバイスと中間ルータがマルチキャスト最適化データ（ＭＯＤ）を交換し，マルチキャストトラヒックを受信するためのアップストリームルータを選択する例としてのシステムを示すブロック図である。
【図１Ｄ】本発明の原理に一致する方法で，受信デバイスと中間ルータがマルチキャスト最適化データ（ＭＯＤ）を交換し，マルチキャストトラヒックを受信するためのアップストリームルータを選択する例としてのシステムを示すブロック図である。
【図２Ａ】マルチキャストの効率を改善するために，システム内でアップストリームデバイスとマルチキャスト最適化データを共有する際に，ダウンストリームデバイスが用いる例としてのパケット形式を示すブロック図である。
【図２Ｂ】マルチキャストの効率を改善するために，システム内でダウンストリームデバイスとマルチキャスト最適化データを共有する際に，アップストリームデバイスが用いる例としてのパケット形式を示すブロック図である。
【図３】近隣のアップストリームルータとマルチキャスト最適化データを共有する際の，受信機の例としての動作を示すフローチャートである。
【図４】近隣のデバイスとマルチキャスト最適化データを共有する際の，アップストリームルータの例としての動作を示すフローチャートである。
【図５】本発明の実施例に従ってマルチキャスト最適化データを配信又は受信する例としてのルータを示すブロック図である。
【図６】マルチキャスト最適化データを格納する例としてのデータ構造を示すブロック図である。
【図７】ソースデバイスが，１台以上の中間デバイスを介してグループのためのマルチキャストデータストリームをバックボーンへ注入する，ローカルエリアネットワーク（ＬＡＮ）環境を示すブロック図である。
【図８】受信機が，同じマルチキャストグループのための多重マルチキャストツリーに対応する複数のインスタンスのためのマルチキャスト参加要求を送信する，他の例としての計算機システムを示すブロック図である。
【図９】同じマルチキャストグループのための多重マルチキャストツリーのために複数のマルチキャストツリーが形成された後の，図８の例としてのシステムを示すブロック図である。
【図１０】インスタンス番号を含むように拡張された例としてのマルチキャストパケット形式を示すブロック図である。
【図１１】本発明の原理に従うシステムの受信機，アップストリームルータ，及びソースの例としての動作を示すフローチャートである。
【符号の説明】
【００８９】
１０    システム
１２    ソースデバイス
１４    受信機
１６    アップストリームルータ
３４    ＭＯパケット
４２    ＭＯ応答パケット
８０    ルータ
８１    ＭＯＤ
８２    インタフェースカード
８８    スイッチ
９０    リンク
９４    制御ユニット
９６    ルーティング情報
９８    マルチキャスト転送情報
１００    ルーティングプロトコル
１０４    データ構造
１２６    ＬＡＮ環境
１２８    ソースデバイス
１３０    マルチキャストデータストリーム
１３２    バックボーン
１３６    受信機
１３８    計算機システム
１４０    受信機
１４４    ルータ
１４６    ソースデバイス
１５０    マルチキャストツリー
１５２    パケット
１５６    グループ識別フィールド
【図１Ａ】
2007208953.tif 000003
【図１Ｂ】
2007208953.tif 000004
【図１Ｃ】
2007208953.tif 000005
【図１Ｄ】
2007208953.tif 000006
【図２Ａ】
2007208953.tif 000007
【図２Ｂ】
2007208953.tif 000008
【図３】
2007208953.tif 000009
【図４】
2007208953.tif 000010
【図５】
2007208953.tif 000011
【図６】
2007208953.tif 000012
【図７】
2007208953.tif 000013
【図８】
2007208953.tif 000014
【図９】
2007208953.tif 000015
【図１０】
2007208953.tif 000016
【図１１】
2007208953.tif 000017