JP4857262B2 - エンド・ツー・エンドの信頼性のあるグループ通信のための方法および装置 - Google Patents

Description

本発明は、スケーラブルなスループットを有し、エンド・ツー・エンドの信頼性が保証された、アプリケーション・レベル・マルチキャストによるコンテンツ配信のための方法および装置に関する。

インターネット・ベースのコンテンツ配信ネットワーク等の多くのアプリケーションにおいて、情報を送信する望ましい手段はマルチキャストである。これは、選ばれた１群のホストに対して同時に情報を送信するものである。現在、インターネット・プロトコル（「ＩＰ」）・ネットワークにおいてマルチキャストをサポートするために、１組の標準が存在する。しかしながら、ネットワーク・サポートＩＰマルチキャストに対する代替案として、オーバーレイ（またはアプリケーション・レイヤ）・マルチキャストが、ますます普及している。ＩＰマルチキャストはインターネット上で普遍的に利用可能でなく、各通信グループごとにグローバルに一意のＩＰアドレスを割り当てる必要があるが、マルチキャスト・オーバーレイは、既存のインフラストラクチャ上で容易に実施可能であり、グローバルなグループ識別子は必要ない。

高レベルの抽象化において、オーバーレイ・ネットワークは、ノードがエンド・システムであり、いずれかの２つのノード間のエッジがこれらの２つのノード間の経路を表す有向通信グラフとして説明することができる。エンド・システム・マルチキャスト・アーキテクチャにおいて、エンド・システム間でポイント・ツー・ポイント接続を確立することによってオーバーレイを形成し、各ノードは蓄積交換の方法で下流ノードにデータを転送する。エンド・システム・レベルにおいて、マルチキャスト分散ツリー（multicast distribution tree）を形成する。かかるパラダイムは、エンド・システム・マルチキャスト、またはアプリケーション・レベル・マルチキャスト、または単にオーバーレイを用いたマルチキャストと呼ばれる。この経路は、物理ネットワークにおいていくつかのルータを実際に横切る場合があるが、このレベルの抽象化では、経路はオーバーレイ・ネットワークにおける直接リンクとして見なされる。

ノードは、例えばツリー・トポロジのような、様々な形状またはトポロジによって接続することができる。エンド・システムは、蓄積交換の方法でデータを他のノードに転送することに明示的に参加する。オーバーレイ・ネットワークにおいてその親ノードからデータを受信した後、ノードは、その送信リンクの各々でデータを複製し、オーバーレイ・ネットワークにおけるその下流ノードの各々にそれを転送する。

広帯域インターネット・アクセスを利用したユーザまたはホストの急増によって、エンド・システム・マルチキャストは、導入に際して固有の障害があるＩＰサポート・マルチキャストに対する代替案として、ますます実用的かつ実現可能で魅力的なものになっている。いくつかの最近の研究では、効率的なオーバーレイ・ツリー構成および保守のためのプロトコル展開が検討された。これらの研究には、Y. H. Chu、S. G. Rao、H. Zhangの「A Case for End System Multicast」（Proceedings of ACM SIGMETRICS、２０００年６月）、P. Francis、Yoidの「Extending the Internet MulticastArchitecture」（２０００年４月）http://www.icir.org/yoid/docs/yoidArch.ps.gz、D. Pendarakis、S. Shi、D. Verma、M. Waldvogel、ALMIの「An ApplicationLevel Multicast Infrastructure」、（インターネット技術およびシステムに関する第３回Usenixシンポジウム（ＵＳＩＴＳ）、２００１年３月）、B. Zhang、S. Jamin、L. Zhang、「Host Multicast: A Framework for Delivering Multicast To End Users」（Proceedings of IEEE Infocom（２０００年））、S. Banerjee、B. Bhattacharjee、C. Kommareddyの「Scalable Application Layer Multicast」（Proceedings of ACM Sigcomm（２００２年））、J. Liebeherr、M. Nahasの「Application-layer Multicast with DelaunayTriangulations」（JSAC、マルチキャストに関する特別号（２００３年）、S. Shi、J. Turnerの「Placing Serves In Overlay Networks」（Technical Report WUCS-02-05、ワシントン大学（２００２年））、S. Shi、J. S. Turnerの「Multicast Routing and Bandwidth Dimensioningin Overlay Networks」（IEEE JSAC（２００２年））、A. Riabov、Z. Liu、L. Zhangの「Multicastoverlay Trees with Minimal Delay」（Proceedings of ICDCS（２００４年））がある。

また、ポイント・ツー・ポイントの伝送制御プロトコル（「ＴＣＰ」）接続を用いて、オーバーレイにおいて信頼性の高いマルチキャストを実施可能である。J. Jannotti、D. Gifford、K. Johnson、M. Kaashoek、J. O’Tooleの「Overcast: Reliable Multicasting with anOverlay Network」（Proc. of the4th Sympoisum on Operating System Design and Implementation（２０００年１０月））においては、エンド・システム間でハイパーテキスト転送プロトコル（「ＨＴＴＰ」）接続を用いる。Y. Chawathe、S. McCanne、E. A. Brewerの「RMX: Reliable Multicast for Heterogeneous Networks」（Proceedings of IEEE Infocom（２０００年））では、ＴＣＰセッションを直接用いる。かかる手法の主な利点は、展開の容易さである。更に、ホップ・バイ・ホップ（hop-by-hop）の輻輳制御およびデータ回復のために、受信器においてより適切に不均質性を扱えることが議論されている。
Y. H. Chu、S. G. Rao、H. Zhangの「A Case for End System Multicast」（Proceedings of ACM SIGMETRICS、２０００年６月） P. Francis、Yoidの「Extending the Internet MulticastArchitecture」（２０００年４月） http://www.icir.org/yoid/docs/yoidArch.ps.gz、D. Pendarakis、S. Shi、D. Verma、M. Waldvogel、ALMIの「An ApplicationLevel Multicast Infrastructure」、（インターネット技術およびシステムに関する第３回Usenixシンポジウム（ＵＳＩＴＳ）、２００１年３月） B. Zhang、S. Jamin、L. Zhang、「Host Multicast: A Framework for Delivering Multicast To End Users」（Proceedings of IEEE Infocom（２０００年）） S. Banerjee、B.Bhattacharjee、C. Kommareddyの「Scalable Application Layer Multicast」（Proceedings of ACM Sigcomm（２００２年）） J. Liebeherr、M. Nahasの「Application-layer Multicast with DelaunayTriangulations」（JSAC、マルチキャストに関する特別号（２００３年） S. Shi、J. Turnerの「Placing Serves In Overlay Networks」（Technical Report WUCS-02-05、ワシントン大学（２００２年）） S. Shi、J. S. Turnerの「Multicast Routing and Bandwidth Dimensioningin Overlay Networks」（IEEE JSAC（２００２年）） A. Riabov、Z. Liu、L. Zhangの「Multicast overlay Trees with Minimal Delay」（Proceedings of ICDCS（２００４年）） J. Jannotti、D. Gifford、K. Johnson、M. Kaashoek、J. O’Tooleの「Overcast: Reliable Multicasting with anOverlay Network」（Proc. of the4th Sympoisum on Operating System Design and Implementation（２０００年１０月）） Y. Chawathe、S. McCanne、E. A. Brewerの「RMX: Reliable Multicast for Heterogeneous Networks」（Proceedings of IEEE Infocom（２０００年）） S. Banerjee、S. Lee、B. Bhattacharjee、A. Srinivasanの「Resilient Multicast using Overlays」（Sigmetrics（２００３年）） S. Floyd、V. Jacobson、C. Liu、S. McCanne、L. Zhangの「A Reliable Multicast Framework forLight-Weight Sessions and Application Level Framing」（IEEE/ACM ToN（１９９７年１２月）、Vol.5、Number 6、７８４〜８０３ページ） C. Bormann、J. Ott、H.-C. Gehrcke、T. Kerschat、N. Seifertの「MTP-2:Towards Achieving the S.E.R.O.Properties for Multicast Transport」（ICCCN（１９９４年）） B. N. Levine、J. J.Garcia-Luna-Acevesの「A Comparisonof Reliable Multicast Protocols」（ACM Multimedia Systems（１９９８年８月）） E. M. Shoolerの「Why MulticastProtocols (Don’t) Scale: An Analysis of Multipoint Algorithms forScalable Group Communication」（ph.D.Dissertation、CS Department、256-80 California Institute of Technology（２０００年）） A. Chaintreau、F. Baccelli、C. Diotの「Impact of TCP-like Congestion Control on the Throughput of MulticastGroup」（IEEE/ACM Transactionson Networking Vol. 10、５００〜５１２ページ、２００２年８月） G. Urvoy-Keller、E. W.Biersackの「A Multicast Congestion Control Model forOverlay Networks and its Performance」（NGC（２００２年１０月）） F. Baccelli、A. Chaintreau、Z. Liu、A. Riabov、S. Sahuの「Scalability of Reliable Group CommunicationUsing Overlays」（IEEE Infocom（２００４年））

しかしながら、ＴＣＰセッションを直接用いる手法から、２つの問題が生じる。第１の問題は、エンド・ツー・エンドの信頼性に関わるものである。マルチキャスト・オーバーレイ・ツリーにおいて内部ノードに故障が生じると、その故障ノードから発するサブツリー内のノードは、残りのツリーに再度アタッチし、かつ、ＴＣＰセッションが停止した点からそれらのセッションにおいて再度確立する必要がある。残りのツリーに再度アタッチし、ＴＣＰセッションの再確立することの問題は、文献において、レジリエンス（resiliency）問題と呼ばれ、これは、この文脈では、故障の検出およびツリーの再構築を含む。

最近、レジリエンス・アーキテクチャは、注目の話題になっている。例えば、S. Banerjee、S. Lee、B. Bhattacharjee、A. Srinivasanの「Resilient Multicast using Overlays」（Sigmetrics（２００３年））においては、ランダム・バックアップ・リンクを用いたレジリエンス・マルチキャスト・アーキテクチャが提案された。再アタッチのノードを発見し、ツリーを再構築することができても、ＴＣＰセッションが停止した点からそれらを再開可能であるという保証はない。この限界は、オーバーレイ・ネットワークにおける中間ノードの転送バッファが有限サイズを有し、ある時間期間の間、ある量の情報しか維持することができないという事実による。従って、新たに確立したＴＣＰセッションが必要とするパケットは、もはや転送バッファには存在しない場合がある。

オーバーレイを用いた信頼性の高いマルチキャストにおいて生じる第２の問題は、スケーラビリティである。信頼性の高いコンテンツ配信を提供するためにオーバーレイに基づいたグループ通信においてＴＣＰプロトコルを用いる場合のこのプロトコルの性能については、充分に理解されていない。研究では、ＴＣＰ接続のオーバーレイ・ネットワークの使用を提唱しているが、これらの研究は、スループット、バッファ要求、およびコンテンツ配信のレイテンシの点でスケーラビリティの問題に対処しない。

これに対して、過去十年間で、ＩＰサポートの信頼性の高いマルチキャスト転送プロトコルの設計および評価のため、多くの取り組みがなされている。これは、例えば、S. Floyd、V. Jacobson、C. Liu、S. McCanne、L. Zhangの「A Reliable Multicast Framework forLight-Weight Sessions and Application Level Framing」（IEEE/ACM ToN（１９９７年１２月）、Vol.5、Number 6、７８４〜８０３ページ）、C. Bormann、J. Ott、H.-C. Gehrcke、T. Kerschat、N. Seifertの「MTP-2:Towards Achieving the S.E.R.O. Properties for MulticastTransport」（ICCCN（１９９４年））、B. N. Levine、J. J. Garcia-Luna-Acevesの「A Comparison of Reliable Multicast Protocols」（ACM Multimedia Systems（１９９８年８月））がある。他の研究、例えば、E. M. Shoolerの「Why Multicast Protocols (Don’t) Scale: AnAnalysis of Multipoint Algorithms for Scalable Group Communication」（ph.D. Dissertation、CS Department、256-80California Institute of Technology（２０００年））、A. Chaintreau、F. Baccelli、C. Diotの「Impact of TCP-like Congestion Control on the Throughput of MulticastGroup」（IEEE/ACM Transactionson Networking Vol. 10、５００〜５１２ページ、２００２年８月）は、かかるＩＰサポートの信頼性の高いマルチキャスト・スキームでは、グループのサイズが大きくなるとグループのスループットがゼロになることを示している。このため、これらのスキームにはスケーラビリティの問題がある。

最近、オーバーレイに基づいた信頼性の高いマルチキャストのスケーラビリティ問題に関して、いくつかの暫定的な結果が報告されている。G. Urvoy-Keller、E. W.Biersackの「A Multicast Congestion Control Model forOverlay Networks and its Performance」（NGC（２００２年１０月））において、著者らは、スケーラビリティ問題を調査する一方で、ポイント・ツー・ポイントの信頼性の高い転送のための固定ウインドウ・サイズのＴＣＰフレンドリ輻輳制御機構について考察している。シミュレーションの結果が提示され、グループ・スループットに対してエンド・システム・バッファのサイズが及ぼす影響を示した。F. Baccelli、A. Chaintreau、Z. Liu、A. Riabov、S. Sahuの「Scalability of Reliable Group CommunicationUsing Overlays」（IEEE Infocom（２００４年））において、ＥＣＮ（Early Congestion Notification）によるＡＩＭＤ（Additive Increase MultiplicativeDecrease）ウインドウ輻輳機構が、ポイント・ツー・ポイントの信頼性の高い転送プロトコルとして考察されている。エンド・システムが有限サイズのバッファを有するという仮定のもとに、グループ・スループットがグループ・サイズとは独立した定数によって下限が規定されるという意味で、かかるオーバーレイに基づいた信頼性の高いマルチキャストがスケーラブル・スループットを有することが示された。

従って、ＴＣＰを用いてエンド・システム間の転送を実行し、中間ノードが有限サイズの転送バッファおよびバックアップ・バッファを有する単純なエンド・システム・マルチキャスト・アーキテクチャに対する要望がある。マルチキャスト・アーキテクチャは、エンド・ツー・エンドの信頼性を提供し、多数の同時ノード故障を許容する。更に、この信頼性の高いグループ通信のスループットは、常に、いかなるグループ・サイズおよびいかなるバッファ・サイズに対しても厳密に正である。

本発明は、複数のエンド・ユーザ・ノードを含むスケーラブルなエンド・ツー・エンドの信頼性の高いマルチキャスト・オーバーレイ・ネットワークに関し、ネイティブの伝送制御プロトコル（「ＴＣＰ」）を、逆圧（back-pressure）機構と共に用いて、ノード間のデータ・パケット喪失を回避する。各中間ノードは、入力および出力バッファならびに有限サイズを有するバックアップ・バッファを含む。バックアップ・バッファを用いて、入力バッファから出力バッファにコピーされたパケットのコピーをストアする。これらのバックアップ・バッファにストアされたデータ・パケットのコピーは、ノード故障の後にＴＣＰ接続が再確立された場合に用いる。ＴＣＰの逆圧機構は、信頼性の高いポイント・ツー・ポイント転送のみでなく、スケーラブルなエンド・システム・マルチキャストを可能とする。

本発明は、ノード故障の結果としてオーバーレイ・ネットワークから切断された孤立したエンド・システム・ノードの再接続を提供する方法およびシステムに関する。多数の同時ノード故障を処理することができる。孤立ノードおよびこれらの孤立ノードに関連したいずれかのサブツリーの再接続の後、ネットワーク全体に新しいツリー・トポロジを伝達し、オーバーレイ・ネットワーク・ツリーにおいてソース・ノードから各エンド・システム・ノードまでの連続的な絶え間ないデータ・パケット・ストリームの配信を保証するために必要なデータ・パケットのコピーを、新しく再接続したエンド・システム・ノードに供給する。これらのデータ・パケット・コピーは、オーバーレイ・ネットワークにおけるノードの各々に含まれるバックアップ・バッファにストアされたものである。孤立ノードは、オーバーレイ・ネットワークの所望の構成に従って再接続され、例えば、スループットのようなネットワークの特定の品質を最適化するため、または、例えば通信遅延のような望ましくない特性を最小限に抑えるために構成したグリーディな発見的方法（greedy heuristic）に従うことができる。また、本発明は、エンド・システム・ノードが、オーバーレイ・ネットワーク・ツリーからの切断またはこれへの参加を行うための手順を提供し、マルチキャスト・オーバーレイ・ツリー全体を通じたグループ通信の信頼性およびスケーラビリティを保証する。

信頼性の高いグループ通信には、単一のソースから複数のエンド・ユーザまで、効率的に同一コンテンツを同時に伝送することが必要である。このコンテンツの同報通信は、マルチキャスト・ツリー構造を用いることによって効率的になる。この構造では、ツリーの各ノードがその母ノードから受信したパケットを複製し、複製したパケットの１つをその娘ノードの各々に送信する。ツリーのノードがインターネット・ルータであり、特定のルーティングおよび制御機構を必要とするネイティブの信頼性の高いインターネット・プロトコル（「ＩＰ」）・マルチキャストとは異なり、マルチキャスト・オーバーレイが用いるツリーでは、ノードは実際のエンド・システムまたはエンド・ユーザであり、エンド・システム間で現在利用可能なポイント・ツー・ポイント接続だけが必要である。

オーバーレイ・ネットワーク・ツリーにおけるエッジは、２つのノード間を接続する経路を表す。この経路は物理ネットワークにおいていくつかのルータを横切る場合があるが、マルチキャスト・オーバーレイ・ネットワークにおいて用いるレベルの抽象化では、この経路を、オーバーレイ・ネットワーク・ツリーにおけるエンド・システム・ノード間の直接リンクと見なす。エンド・システム・ノードは、蓄積交換の方法で、データ・パケットを他のエンド・システム・ノードに転送することに明示的に参加する。

例えば母ノードおよび娘ノードのようなノード間のポイント・ツー・ポイント通信は、適切な通信プロトコルを用いて実行される。オーバーレイ・ネットワーク・ツリー内のノード間でデータ・パケットを信頼性高く配信または伝送し、ならびに、様々なノード間でプロトコルおよび制御信号を伝達することができる、いずれかの適切な通信プロトコルを使用可能である。好ましくは、通信プロトコルはＴＣＰである。この実施形態では、所与のマルチキャスト・オーバーレイ・ネットワークにおける各ノード対間のポイント・ツー・ポイントまたはホップ・ツー・ホップ（hop-to-hop）伝送プロトコルとして、ＴＣＰを用いる。一実施形態では、例えば、ＴＣＰ−ＲＥＮＯまたはＴＣＰ−ＮｅｗＲＥＮＯにおけるように、高速再送信高速回復（Fast Retransmit Fast Recovery）を実施する。高速再送信高速回復の一例は、M. AllmanおよびV. PaxsonのRFC2581-TCP Congestion Control（http://www.ietf.org/rfc/rfc2581.txt(1999)において入手可能）にみることができ、これは、引用によりその全体が本願にも含まれるものとする。一つの代替的な実施形態では、ＳＡＣＫ（Selective Acknowledgement）も用いる。更に、必須ではないが、ＥＣＮ（Explicit Congestion Notification）を、ノード間の通信プロトコルにおける中間ステップとして用いることができる。

図１から図３に示すように、マルチキャスト・オーバーレイ・ネットワーク１０において、ソース母ノード１２は、１つ以上の娘ノード１４にデータを送信する。ソース母ノード１２からデータを受信した後、各娘ノード１４は、データを複製し、以降の母ノードとして機能し、その送信リンク１６の各々で、オーバーレイ・ツリー１０における以降の娘ノード１８の各々に、データのコピーを送信する。このオーバーレイ・ネットワーク１０において、データを受信のみして再送信しないリーフ・ノードを除いて、パケットをストアし転送する各ノードは、パケット転送の目的のためにバッファを供給する。図３に示すように、全てのノード１４は、ソース母ノード１２を除くがリーフ・ノード１８を含めて、上流ＴＣＰの受信側ウインドウに対応する入力バッファ２０を含み、リーフ・ノード１８を除いて、各ノード１４は、いくつかの出力または転送バッファ２２を含む。好ましくは、各ノード１４は、各下流ＴＣＰ接続または以降の娘ノード１８ごとに１つの出力バッファを含む。

更に、所与のノード・グループの各々は、入力バッファ２０および出力バッファ２２の各々と通信状態にある少なくとも１つのバックアップ・バッファ２４を含む。一実施形態では、バックアップ・バッファを含むノード・グループは、入力バッファおよび出力バッファの双方を含むソース・ノードの後のノードを含む。従って、リーフ・ノードすなわちデータ・パケットを受信のみするが再送信しないノードは、バックアップ・バッファを含まない。本明細書において用いる場合、ノード、またはエンド・システム・ノードは、リーフ・ノードを含むがソース母ノードは含まない所与のマルチキャスト・オーバーレイ・ネットワーク内のエンド・システムまたはエンド・ユーザを指す。各バックアップ・バッファ２４は、入力バッファ２０（受信側ウインドウ）から出力バッファ２２へとコピーされ転送されたデータ・パケットのコピーをストアする。これらのバックアップ・バッファ２４は、オーバーレイ・ネットワーク１０において所望の量の冗長性を提供し、例えば、１つ以上のエンド・システム・ノードが故障した後にオーバーレイ・ネットワークにおいて様々なノード間で通信接続を再確立する場合に用いられる。

各ノードごとの入力バッファ２０、出力バッファ２２、およびバックアップ・バッファ２４のサイズは、各ノードを介して転送されるデータの量に基づいて選択される。入力バッファ２０、出力バッファ２２、およびバックアップ・バッファ２４は、通常、有限のサイズまたはキャパシティを有する。これらのバッファ・サイズは、入力バッファ２０、出力バッファ２２、およびバックアップ・バッファ２４について、それぞれ、Ｂ_IN、Ｂ_OUT、Ｂ_BACKと表すことができる。一実施形態では、バックアップ・バッファのサイズは、Ｂ_BACK≧ｍ（Ｂ_OUT ^max＋Ｂ_IN ^max）＋Ｂ_OUT ^maxによって与えられる。ここで、Ｂ_OUT ^maxは、最大の出力バッファ・サイズであり、Ｂ_IN ^maxは最大の入力バッファ・サイズであり、ｍは、バックアップ・バッファにストアされたデータ・パケット・コピーが対応可能な同時ノード故障の数である。

一般に、マルチキャスト・オーバーレイ・ツリー１０のトポロジは、グループの性能、すなわち、オーバーレイ・ツリーを介したデータ・パケットの伝送に影響を与える。例えば、ツリーの深さ、すなわち、連続してまたは続けて配置されたツリー内のノード数が大きすぎる場合、ツリー内の深くにあるノードは、パケットを受信する際に長い遅延がある。更に、ツリーの外側範囲（out-degree）または拡散が大きすぎる場合、特に「ラスト・マイル（last mile）」において、下流の接続は共有リンクの帯域幅を得るために争い、輻輳および通信遅延を引き起こす。本発明の目的のため、ツリー・トポロジは既定のものとして扱い、所与のツリーの外側範囲または広がりは、定数Ｄによって規定される。

管理の観点から、マルチキャスト・オーバーレイ・ツリー・トポロジの少なくとも一部を、エンド・システム・ノードの１つ以上にストアする。従って、このトポロジ情報がストアされている各ノードは、マルチキャスト・オーバーレイ・ツリー全体の少なくとも部分的なビューを有する。あるいは、マルチキャスト・オーバーレイ・ツリー・トポロジ全体を、ノードの各々にストアする。本明細書において例示する一実施形態では、比較的単純な構造を用い、各ノードがその上位ノードおよびそのサブツリー全体を知ることができる。この構造は例示の目的のためにのみ与え、本発明はこのタイプの構造に限定されない。本発明に従って、代替的なアーキテクチャを実施することも可能である。

本発明に従って、様々なマルチキャスト・オーバーレイ・ツリー・トポロジを使用可能であるので、一般的な表記を用いて所与のツリー・トポロジ内の様々なノードを示す。図２を参照すると、各ノードに、マルチキャスト・ツリーにおけるエンド・システムの位置を表す番号対（ｋ、ｌ）２６が割り当てられている。最初のインデクスｋ（２８）は、ソース・ノード１２またはツリーのルートからの距離であり、レベルとも称する。第２のインデクスｌ（３０）は、同じレベル内にある多数のエンド・システムに付番することができる。完全な二進ツリーでは、ソース・ノードからの同じレベル上または同じ距離ｋ内のエンド・システムは全て、番号ｌ＝０、．．．、２^k−１が与えられる。例示するように、完全な二進ツリーは、２の最高レベルすなわちｋ＝２およびｌ＝０、１、２、３を有する。

更に、ノード（ｋ、ｌ）の母ノードは、（ｋ−１、ｍ（ｋ、ｌ））と表される。ノード（ｋ、ｌ）の娘ノードは、（ｋ＋１、ｌ’）と表され、ｌ’∈ｄ（ｋ、ｌ）である。完全二進ツリーでは、

であり、ｄ（ｋ、ｌ）は｛２ｌ、２ｌ＋１｝である。

本発明は、スケーラブルなスループットを有し、エンド・ツー・エンドの信頼性が保証された、マルチキャスト・オーバーレイ・ツリーにおけるノード間のデータ・パケットの信頼性の高い伝送および転送を提供することを対象とする。一実施形態では、本発明に従った方法は、通信プロトコルおよび逆圧機構を用いて、マルチキャスト・オーバーレイ・ツリーにおいてノード間のデータ・パケット喪失を防止することを含む。本明細書において用いる場合、一般に逆圧機構、具体的にはＴＣＰの逆圧機構とは、オーバーレイ・ネットワーク・ツリー内でフレームまたはデータ・パケットの喪失を回避するために用いる機構またはアルゴリズムを示し、ツリーにおいて遠くに配置されたエンド・システム・ノードに含まれる入力または出力バッファが容量に達した場合、例えば送信側または母ノードへとネットワークを介して障害信号を送信する。

マルチキャスト・オーバーレイでは、３つの異なるタイプのパケット喪失があり得る。第１のタイプは、エンド・システム・ノード間の経路において生じる喪失である（送信側および受信側または母および娘）。一実施形態では、本発明は、ＴＣＰを用いてエンド・システム・ノード間でデータ・パケットを転送することによって、これらの第１の喪失を回避または回復させる。特に、本発明は、ＴＣＰ内の肯定応答および再送信機構を利用する。

第２のタイプは、エンド・システム・ノードに位置する入力バッファにおけるオーバーフローによる喪失である。本発明によれば、第２の喪失は、マルチキャスト・ツリーを介してデータ・パケットを転送するために用いる通信プロトコルの逆圧機構によって対処される。一実施形態では、プロトコルはＴＣＰであり、逆圧機構は、単一のパケット・データ喪失ではＲＥＮＯ、多数の喪失またはエラーにはＮｅｗＲＥＮＯ、およびＳＡＣＫを含む。あるいは、ＥＣＮを用いることも可能である。逆圧機構の一実施形態では、所与の受信側ノードにおける入力バッファの利用可能空間を、例えば送信側または所与のノードの母ノードのような、ツリー内の他のノードに伝達する。一実施形態では、これは、ＴＣＰの肯定応答プロトコル（「ＡＣＫ」）によって伝達される。ＴＣＰ接続の所与のノードによって送信される肯定応答パケットは、その入力バッファまたは受信側ウインドウにおいて現在利用可能な空間を含む。受信側ノードが送信した空間情報に応答して、新しいパケットおよびいずれかの他の「イン・フライ（in-fly）」パケットが入力バッファ内に充分な空間を有しない限り、送信側ノードは新しいデータ・パケットを送信または転送する。入力バッファにおける利用可能空間を送信側ノードに通知することに加えて、入力バッファにおける利用可能空間が著しく減少した場合、所与の受信側ノードは、例えばソース・ノードに送信した特別データ・パケットを用いて、オーバーレイ・ツリーにおける他のノードに通知を送る。一実施形態では、バッファ空間が最大セグメント・サイズ（ＭＳＳ）と約２倍以上異なる場合に、通知を送る。

第３のタイプは、エンド・システム・ノードに位置する出力バッファにおけるオーバーフローによる喪失である。これらの第３のタイプの喪失が起こり得るのは、例えば、データ・パケットをコピーしそのコピーを出力バッファに送信するプロセスの間である。一実施形態では、逆圧機構を用いてこのタイプの喪失を防ぐ。本発明によれば、所与のエンド・システム・ノードの入力バッファからデータ・パケットを除去するのは、このデータ・パケットをそのエンド・システム・ノードの出力バッファの全てにコピーした後のみである。出力バッファにおいてデータ・パケットを収容するための充分な空間が存在しないならば、コピー・プロセスはブロックされる。その出力バッファに１つのデータ・パケットのための充分な余裕があるならば、コピーおよび転送を再開する。このため、この「ブロッキング」逆圧機構は、エンド・システム・ノードの出力バッファにおけるオーバーフローを排除する。このオーバーフローは、出力バッファが有する処理容量よりも多くのデータ・パケットを出力バッファに送信したことの結果として生じる可能性がある。従って、本発明に従って用いるアーキテクチャは、第３のタイプのデータ・パケット喪失を回避する。本発明に従って用いる逆圧機構は、有限サイズのバッファについてもオーバーレイ・ノードにおけるデータ・パケット喪失を回避する。従って、本発明は、有限サイズの入力および出力バッファの使用を容易にする。

また、本発明は、パケット喪失による再配列遅延の問題に対処する。この問題はスループットに著しく影響し、従ってグループ通信のスケーラビリティに大きく影響する。オーバーレイ・ネットワーク・ツリーにおける経路に沿ってデータ・パケットが喪失すると、例えばＴＣＰのような通信プロトコルは、最終的に喪失したデータ・パケットを再送信する。しかしながら、これらの再送信の結果、データ・パケットの順序または配列がごちゃ混ぜになる可能性がある。例えば、大きいシーケンス番号を有するいくつかのデータ・パケットは、これらのデータ・パケットが後で転送され再送信データ・パケットの後に続くことを示すが、複製再送信データ・パケットが到着する前に所与のノードに到着する。所与のノードは、入力バッファから出力バッファに順番にデータ・パケットをコピーし転送する。従って、複製再送信データ・パケットが到着し転送されるまで、大きいシーケンス番号を有する初期に到着したデータ・パケットは転送バッファにコピーされない。

所与のノードにおいては、パケット処理における遅延は、そのノードのスループットに無視できる程度の影響しか与えない。しかしながら、処理遅延は、オーバーレイ・ネットワークにおけるデータ・パケットの全体的なフローにおいて乱れを生成する。これらの乱れは、後の下流ノードに到着するデータ・パケットのバーストとして表れ、ノード間の下流経路において著しい性能劣化を引き起こす恐れがある。また、１つのノードから発する乱れは、後のサブツリーに波及効果を生じる場合がある。更に、これらの性能劣化は、逆圧機構の結果として、ソース・ノード送信レートに影響を与え、従ってグループ通信スループットに影響を与える。

エンド・システム・マルチキャスト・ネットワークにおけるレジリエンスは、オーバーレイ・ネットワーク内のノード故障およびノード逸脱の処理に関係する。これらの故障および逸脱は、多くの場合、事前の通知も警告もなく生じる。従って、一実施形態において、本発明は、少なくとも１つのノードにおいて故障を検出した後、マルチキャスト・オーバーレイ・ネットワークにおけるノード間の信頼性の高いデータ・パケット転送を提供する。本発明に従った通信プロトコルおよび逆圧機構を用いて、パケット喪失の防止と組み合わせて、またはこれとは独立して、信頼性の高いデータ・パケット転送を提供することができる。また、本発明は、ローカル・エリア・ネットワークおよびワイド・エリア・ネットワークにおいてこれらのアルゴリズムを実施するために用いるコンピュータ実行可能コード、ならびに、これらのコードを含むコンピュータ読み取り可能媒体を対象とする。

一実施形態において、本発明は、マルチキャスト・オーバーレイ・ツリーにおける少なくとも１つのエンド・システム・ノード故障を検出する。好ましくは、本発明は、複数のノード故障の同時検出、および、複数のノード故障を検出した後の信頼性の高いデータ転送を可能とする。ＴＣＰ等の通信プロトコルは、応答していないノードを検出するための信頼性が高く効率的な機構を常に提供するわけではないので、故障を検出するために他の方法が必要である。本発明に従ってノード故障を検出するための適切な方法は、心拍プローブ（heartbeat probe）および賦活信号（keep-alive signals）を含む。心拍プローブでは、ユーザ・データグラム・プロトコル（「ＵＤＰ」）によって、所与のノードの隣接ノード全てに、一定の時間間隔で心拍メッセージを送信する。隣接ノードからの心拍が無くなると、ノード故障またはノード逸脱を知らせる。賦活メッセージング・システムは、同様の方法で確立することができる。

ノード故障を検出すると、マルチキャスト・オーバーレイ・ツリーを再構成して、故障ノードの孤立ノードおよびこれらの孤立ノードに発したサブツリーを元のマルチキャスト・ツリーに再アタッチまたは再接続すると共に、ソース・ノードから残りのエンド・システム・ノードの各々まで完全なデータ・パケット・シーケンスの配信を維持する。故障したエンド・システム・ノードの孤立ノードは、故障エンド・システム・ノードからデータ・パケットを導出または受信した故障ノードの下流にある全ノードを含む。孤立ノードは、故障ノードの娘であった孤立娘ノードおよびこれらの孤立娘ノードに発したサブツリーに含まれるエンド・システム・ノードを含む。一実施形態では、例えばＴＣＰノード接続のような新しいノード接続は、各孤立ノードの再接続の後に確立する。孤立ノードを再アタッチするために用いる新しいノードは、故障ノードの孤立ノードのための代替的な母ノードと考えることができる。マルチキャスト・ツリーを再構成するために、様々な方法を用いることができる。以下に、本発明と共に用いるのに適した方法について論じる。

本発明の方法の別の実施形態においては、複数の同時エンド・システム・ノード故障を検出し、孤立エンド・システム・ノードは全て同時にマルチキャスト・オーバーレイ・ツリーに再接続する。

この再構成を完了するには、ツリーをさかのぼって、ルートまたはソース母ノードに、新たに構成したサブツリーに関する情報を配信し、ツリーを下って、新たに再接続したサブツリーに、祖先のツリー情報を配信する。一実施形態では、新たに構成したサブツリーに関するトポロジ情報の配信は、故障ノードの母ノードおよび娘ノードによって開始し、祖先ツリー情報の配信は、「継母」ノードによって開始する。

故障または逸脱したノードを識別し、故障または逸脱したノードの孤立ノードおよびサブツリーを再接続した後にエンド・ツー・エンドの信頼性および故障を達成することは、ツリー構造のレジリエンスに加えてデータ完全性を保証することを含む。データ完全性の保証は、新しい代替的な母ノードまたは「継母」ノードを提供することを含み、データは充分に古いので、再接続した娘ノードおよびこれらの娘ノードの子供は、ソース母ノードから完全なデータ・パケット・シーケンスを受信する。本発明において、各エンド・システム・ノードに位置するバックアップ・バッファを用いてデータ完全性を保証するには、孤立ノードを再接続した後にサブツリーを通ったデータ・パケットのコピーをストアする。本明細書において用いる場合、完全なデータ・パケット・シーケンスは、例えば完全なビデオ会議、完全な映画、または完全なオーディオ同報通信のような、ソース・ノードから提供されたサービスまたは情報までの充分に完全かつ連続したデータ・ストリームをエンド・システム・ノードに与えるために必要なデータ・パケットの全てを含む。新たな接続を確立すると、新しい接続を生成している送信側ノードのバックアップ・バッファにおけるデータ・パケットを、新しい接続に対応するその送信側ノードの出力バッファにコピーする。バックアップ・バッファは、すでに入力バッファから出力バッファにコピーされたもっと古いデータ・パケットのコピーを含むので、送信側ノードは、現在は送信側ノードの入力バッファにあるものよりも古くて小さいシーケンス番号を有するその出力バッファのデータ・パケットから開始する。

バックアップ・バッファのサイズは、出力バッファに配信される古いデータの充分な量に対応するデータを保持するように選択される。以下で更に詳細に述べるように、一実施形態では、バックアップ・バッファのサイズは、入力および出力バッファのサイズに比べて充分大きく選択されるので、多数の同時ノード故障または逸脱がある場合でも、エンド・ツー・エンドの信頼性を提供することができる。例えば、Ｂ_OUT ^maxおよびＢ_IN ^maxが、それぞれ、所与のノードについての出力および入力バッファの最大サイズである場合、バックアップ・バッファは、ｍ個の同時ノード故障および逸脱を許容するために、以下のサイズである可能性がある。

本発明のこの実施形態によれば、各故障または逸脱したノードの娘ノードは、故障または逸脱ノードのｍ番目の世代の祖先において発したサブツリーにおけるノードのいずれかに再アタッチすることができる。

エンド・ツー・エンドの信頼性を保障するために本発明に従って用いられるバックアップ・バッファ・アーキテクチャは、極めて簡単である。特に、このアーキテクチャはアプリケーション・レベルで実施することができ、再アタッチする孤立ノードの各々と共に用いるために、正しいシーケンス番号を有するデータ・パケットを有するエンド・システム・ノードを検索する必要はない。

また、本発明は、ノードがマルチキャスト・オーバーレイ・ツリーを離脱またはこれに参加するための手順に対処する。従来、リアルタイム・アプリケーションのためにＵＤＰを用いたが、ＴＣＰは、公正な広帯域の共有および整然としたデータ・パケット配信を含む利点があるので、特にマルチメディア・アプリケーションでは、ＵＤＰに対する好ましい代替案である。更に、ＴＣＰは、ＨＴＴＰトラヒックしか許容しないクライアントが課したファイアウォールを通過することができる。本発明のエンド・システムに基づいた信頼性の高いマルチキャスト・アーキテクチャを展開して、ライブ・イベントを同報通信することができるので、ノードまたはエンド・ユーザが発信中ライブ同報通信をアクティブに離脱またはこれに参加するための手順が用いられる。

一実施形態において、ノードがマルチキャスト・オーバーレイ・ツリーから離脱または除去されるための手順は、除去されるノードの母ノードおよび娘ノードに逸脱または除去を通知し、その後、対応するＴＣＰセッションを切断することを含む。次いで、オーバーレイ・ネットワーク・ツリーを、ノード故障の場合のように再構成する。オーバーレイ・ネットワークにおけるノード・グループにノードが追加されたかまたはこれに参加すると、ノードはソース母ノードに接触し、これが、その母ノードに関する必要な情報を新しいノードに提供する。次いで、新しいノードは、指定された母ノードとのＴＣＰ接続を確立する。更に、新しいツリーにおけるエンド・ツー・エンドの信頼性の目的のため、ソース母ノードは、バッファ・サイズに関する制約に関して新しいノードに通知するので、新しいノードにおける入力および出力バッファのサイズは、それぞれＢ_IN ^maxおよびＢ_OUT ^maxを超えず、バックアップ・バッファのサイズは数式（１）を満足する。離脱および参加手順は、ノード故障の場合に用いたようなトポロジ情報更新プロセスによって完了する。

データ・パケット・シーケンスにおける中断の回避は、ささいな問題ではない場合がある。特にルートから遠いノードではそうである。なぜなら、これらのノードが故障時に受信しているパケットは、故障ノードを除いた全ての他のグループ・メンバによってすでに処理され廃棄されている可能性があるからである。従って、バックアップ・バッファを用いて、ストリーム・コンテンツ、すなわち、ノード故障の間に失われていた可能性があるデータ・パケットのコピーを作成する。図３に示すように、データ・パケットが入力バッファ２０から出力バッファ２２に移動すると、入力バッファから出る各データ・パケットのコピーを、バックアップ・バッファ２４にセーブする（４０）。そして、娘ノード１８に転送するために出力バッファ２２にコピーを送信する（４２）ことによって、バックアップ・バッファを用いてノード故障の間に失われたデータ・パケットを回復することができる。

本発明に従った、ｍの同時故障を許容するエンド・ツー・エンドの信頼性の高いグループ通信は、マルチキャスト・ツリーからｍのノードを同時に除去し、孤立ノードを全て同時に再接続し、送信を続けて、ソース母ノードからのデータ・パケットの完全送信を残りの全ノードに供給することとして定義することができる。換言すると、ｍ個のノードの故障は、残りのノードで受信されたストリームのシーケンスにもコンテンツにも、何ら変化を与えない。しかしながら、故障からの回復は遅延を生じる恐れがあり、接続性を回復することを必要とする。

オーバーレイ・ネットワークがｍの故障から回復している時間中に、更に別の故障から正確に回復することは保証されない。しかしながら、ｌ（１≦ｌ≦ｍ）の故障が生じると、システムが完全に回復する前に故障が起こった場合であっても、システムは更に（ｍ−ｌ）故障から回復することができる。かかる状況において、回復中に生じる新たな故障は、全体の回復時間を長くする。例えば、Ｂ_OUT ^maxおよびＢ_IN ^maxがそれぞれシステムにおける出力および入力バッファの最大サイズである場合、オーダｒのバックアップ・バッファは、サイズ（ｒ（Ｂ_OUT ^max＋Ｂ_IN ^max）＋Ｂ_OUT ^max）を有する。ここで、オーダｒは、本発明のシステムおよび方法によって処理可能な同時故障数として規定される。

一実施形態では、以下のアルゴリズムを用いて故障から回復する。ノード（ｋ’、ｌ’）はノード（ｋ、ｌ）の生き残った祖先である。これは、ノード（ｋ、ｌ）の母ノードが故障のため生き残れず、（ｋ’、ｌ’）が（ｋ、ｌ）からソース母ノードまでの経路上で最初の生き残ったノードである場合である。切断された各エンド・システム（ｋ、ｌ）は、生き残っている祖先（ｋ’、ｌ’）のサブツリーに属するノードに再接続される。接続を回復した後、ノード（ｋ’、ｌ’）は、そのバックアップ・バッファに含まれる全パケットを再送信する。次いで、これは送信を続け、入力バッファから読み取って出力バッファに書き込む。（ｋ’、ｌ’）から（ｋ、ｌ）への新しい経路上の中間ノード、および（ｋ、ｌ）の全サブツリーにおける全ノードは、すでに受信したパケットを無視することができ、単にそれらを下流ノードに転送する。

従って、本発明に従ったエンド・ツー・エンドの信頼性は、以下の原理によって表現することができる。サイズ（ｍ（Ｂ_OUT ^max＋Ｂ_IN ^max）＋Ｂ_OUT ^max）のバックアップ・バッファを有するマルチキャスト・オーバーレイ・システムは、エンド・ツー・エンドの信頼性が高く、ｍの故障を許容する。

この主張を証明するため、ノード・チェーン（ｋ₁、ｌ₁）→（ｋ₂、ｌ₂）→（ｋ₃、ｌ₃）について考察する。Ｗ^(k _i+1 ^,l _i+1 ⁾は、ＴＣＰ接続（ｋ_i+1、ｌ_i+1）上の受信側ウインドウのサイズであり、i＝１、２である。ノード（ｋ₂、ｌ₂）の故障が検出されると、ノード（ｋ₃、ｌ₃）はノード（ｋ₁、ｌ₁）に接続し、パケット番号ｔ＋１から開始するパケットの再送信を要求する。ｔは、ノード（ｋ₃、ｌ₃）が受信した最後のパケットの番号である。ノード（ｋ₂、ｌ₂）の入力および出力バッファにストアされたパケット番号、プラス、ノード（ｋ₂、ｌ₂）と行き来するパケット「イン・フライ」の数は、多くても（Ｂ_OUT ^max＋Ｂ_IN ^max）である。この範囲は、受信側ウインドウ・サイズのＴＣＰの選択によって保障される。多くてもＷ^(k ₂ ^,l ₂ ⁾のパケットは、ノード（ｋ₂、ｌ₂）に対して「イン・フライ」であり、Ｗ^(k ₂ ^,l ₂ ⁾は、入力バッファ・ノード（ｋ₂、ｌ₂）におけるフリー・メモリの量を超えない。同様に、多くてもＷ^(k ₃ ^,l ₃ ⁾のパケットは、ノード（ｋ₃、ｌ₃）に対して「イン・フライ」であるが、（ｋ₃、ｌ₃）がパケットを受信したことを認証するまで、ノード（ｋ₂、ｌ₂）の出力バッファから除去されない。従って、ノード（ｋ₁、ｌ₁）における最小パケット番号とノード（ｋ₃、ｌ₃）における最大パケット番号との間の差は、ノード（ｋ₂、ｌ₂）におけるバッファ・サイズの和を超えない。再送信の間、ノード（ｋ₁、ｌ₁）におけるアプリケーションは、出力ソケット・バッファへのアクセスを有せず、このバッファのコンテンツを再送信する必要があり得る。従って、再送信する必要があるパケットの合計数は、Ｂ_OUT ^max＋（Ｂ_OUT ^max＋Ｂ_IN ^max）によって規定される。これは、オーダ１のバックアップ・バッファのサイズである。

（ｋ₂、ｌ₂）が２つ以上の娘ノードを有する場合、娘ノードの各々は、最大でＢ_OUT ^max＋（Ｂ_OUT ^max＋Ｂ_IN ^max）のパケットを再送信する必要があり、オーダ１の同じバックアップ・バッファは、全ての必要なパケットを提供する。

２つ以上の故障が生じ、切断したノード（ｋ、ｌ）からその生き残った祖先ノード（ｋ’、ｌ’）までの経路上に２つ以上の故障ノードがある場合、生き残った祖先ノードは、経路上の全故障ノードにおける入力および出力バッファのコンテンツ、プラス、（ｋ’、ｌ’）における出力バッファのコンテンツを再送信する必要がある場合がある。故障ノードの数はｍによって規定されるので、原理は証明されている。

実際、故障許容度の文献において、故障の許容度の定義は標準的な表記を用いた。従って、上述の証明は、実際にはもっと強力な結果を証明し、これはここでは当然の結果として述べる。

サイズ（ｍ（Ｂ_OUT ^max＋Ｂ_IN ^max）＋Ｂ_OUT ^max）のバックアップ・バッファを有するマルチキャスト・オーバーレイ・システムは、エンド・ツー・エンドの信頼性があり、ツリー・チェーンにおいてｍの同時かつ連続的な故障に対する許容度がある。

本発明に従ったマルチキャスト・オーバーレイ・ツリーによって、ノードは、送信中にグループを離脱しこれに参加することができる。ノードの離脱は、上述の故障回復方法によって処理することができる。ノードがオーバーレイ・ネットワークに参加する一実施形態では、送信に参加するノードは遠くのリーフ・ノードに接続したい場合があり、これは最小のシーケンス番号のパケットを処理しているので、新たに参加したノードはほとんどの送信済みのデータを捕捉することができる。しかしながら、遅延が重要なファクタである場合、参加するノードはできる限りルートに近いノードに接続することができる。実際、各ノードごとのダウン・リンクの最大数は、特にラスト・マイルの影響のために制限され、マルチキャスト・グループにおける全てのノードが新しい接続を受け入れることができるわけではない。従って、新たな接続のためのアップリンク・ノードは、まだ容量を使い尽くしていない「アクティブな」ノードから選ばれる。

故障後に接続性を回復するための手順は参加プロセスと同様であるが、ノード故障では、代替的な母ノードの選択は、故障ノードの生き残った祖先のサブツリーにいっそう制限される。通信遅延を最小限に抑えるアプリケーションでは、目標は、範囲の制約のもとで可能な限りバランスをとったツリーを維持することである。従って、一実施形態において、グリーディな発見的方法を用いて接続性を回復する。一実施形態では、グリーディな発見的方法は、範囲の制約のもとで全ツリー深さを最小化し、最長のサブツリーを、できる限りルートまたはソース・ノードに近いノードに再接続する。例えばGREEDY_RECONNECTと呼ぶアルゴリズムを、１つのノード故障の場合について以下に記載するが、多数の同時ノード故障の場合は、単一故障のシーケンスとして処理することができる。

まず、ノード（ｋ、ｌ）が故障したと仮定する。Ｓは、（ｋ、ｌ）の娘から発する１組の孤立サブツリーとする。Ａは、（ｋ−１、ｍ（ｋ、ｌ））のサブツリー内であるが（ｋ、ｌ）のサブツリーにはない１組のアクティブなノードとする。次に、最大の深さのサブツリーを有するノード（ｋ＋１、ｌ’）∈Ｓを選択する。次いで、ソースに最も近いノード（ｐ、１）∈Ａを選択し、（ｋ＋１、ｌ’）を（ｐ、ｑ）に接続する。次いで、Ｓ←Ｓ＼｛（ｋ−１、ｌ’）｝を更新し、（ｋ＋１、ｌ’）のサブツリーからＡにアクティブ・ノードを加える。このプロセスは、Ｓが空でなくなるまで、つまり、サブツリーの全てを再接続するまで、完了する。

目的の機能に応じて、他の手法を考慮することができる。別の実施形態では、例えば、スループットを最大化し、ラスト・マイル・リンクが限られた帯域幅を有する場合、下方の広がりがもっと高いスループットを与え、最適なトポロジはチェーンである可能性がある。更に別の実施形態では、遅延を最小化する場合、最適な構成は、全てのノードがソース・ノードと直接接続を有する星型である。更に、特定の目標が設定されていない場合、アップリンク・ノードのランダムな選択（広がりの制約を受ける）を用いる。

本発明に従った信頼性の高いマルチキャスト・オーバーレイ・アーキテクチャは、グループのスループットが、グループのサイズには無関係に正の定数によって下限を規定されるという意味で、スケーラブルである。逆圧機構を有する有限サイズのマルチキャスト・ツリーにおいても、グループ・スループットは正である。これは、G. Urvoy-KellrおよびE. W. Biersackの「A Multicast Congestion Control Model for Overlay Networks and itsPerformance」（NGC、２００２年１０月）に報告された予備的なシミュレーション結果の観点からは予想されない結果であり、ＩＰサポートの信頼性の高いマルチキャストに関する文献に報告された非スケーラビリティの結果とは対照的である。

本発明に従ったマルチキャスト・オーバーレイ・アーキテクチャのスケーラビリティの証明は、以下で述べる１組の確率論的仮定のもとで行われ、逆圧（ＥＣＮマーキング）およびノード故障再接続の双方をカバーする。この証明において用いたモデルは、いくつかの関連した数学的表現のもとで説明する。第１の数学的表現は、全ての必要な機構を適切に表し、レート・スケーラビリティの数学的証明において役立つランダム・グラフである。第２の数学的表現は、ペトリ・ネット（Petri net）であり、上述のランダム・グラフのある種の折りたたみ（folding）として見ることができ、ネットワーク・トポロジおよび制御のもっとグローバルで視覚的な表現を与える。第３の数学的表現は、（ｍａｘ、ｐｌｕｓ）帰納であり、ランダム・グラフにおける最大重み経路およびグループ・スループットにリンクされる。これらの帰納は、このクラスのオブジェクトをシミュレートするのに最も効率的な方法であることがわかっている。

図４を参照すると、入力および出力ブロッキング（逆圧）を有する高さ２の二進ツリー３２の例を示す。この二進ツリー３２は、ペトリ・ネットのような数学的表現において喪失のないマーキングのためのモデルを示す。逆圧機構に関連するブロッキング機構は、各ノードまたはエンド・システム３８の入力バッファ３４および出力バッファ３６において実施される。図５に、二進ツリー３２の単一エンド・システム・ノード３８を更に詳細に示す。図４および図５に示すように、各エンド・システム・ノード３２は、上述したインデクス表記（ｋ、ｌ）に従って識別または標示する。各エンド・システム・ノード（ｋ、ｌ）ごとに、各入力バッファ３４のサイズをＢ_IN ^(k,l)と示し、各出力バッファ３６のサイズをＢ_{OUT,(k’,l’)} ^(k,l)と示し、出力は以降のまたは娘のエンド・システム（ｋ’、ｌ’）に対する接続に対応する。入力バッファおよび出力バッファの双方のサイズは、データ・パケットにおいて測定する。簡略化のため、全てのパケットは同じサイズとして述べる。

他のタイプの通信プロトコルを使用可能であるが、好ましくはエンド・システム間の接続はＴＣＰ接続である。図に示すように、ＴＣＰ接続のために同様の表記を用いる。例えば、（ｋ、ｌ）と示すエンド・システムに対するＴＣＰ接続は、対応するインデクス標示（ｋ、ｌ）で示す。更に、各ＴＣＰ接続は、Ｈ_(k,l)と示す一連のルータ・シーケンスを含むルートに従う。ＴＣＰ接続（ｋ、ｌ）のルータは、インデクスｈ＝１、２、．．．、Ｈ_(k,l)によって標示されている。各ルータは、単一のサーバ・キューとして表される。接続（ｋ、ｌ）のルータｈの入力バッファは、ラベル（ｋ、ｌ、ｈ）を有するペトリ・ネットにおける場所として表される。図４および図５において、ペトリ・ネットにおけるこれらの場所は、円４４によって表されている。ＴＣＰ接続（ｋ、ｌ）の（ｋ、ｌ、ｂｅｇ）と示す場所は、エンド・システム（ｋ−１、ｍ（ｐ））の出力バッファを表す。同様に、場所（ｋ、ｌ、ｅｎｄ）は、エンド・システム（ｋ、ｌ）の入力バッファを表す。図４には、ＴＣＰ接続（１、０）についてインデクスｈのための表記を示す。

ＴＣＰ接続（ｋ、ｌ）のためのウインドウ・サイズ・シーケンスは、（Ｗ_m ^(k,l)）_m³1、４６として表される。更に厳密には、Ｗ_m ^(k,l)は、パケットｍによって見られるウインドウ・サイズである。このシーケンスは、組｛１、２、．．．、Ｗ_max｝においてその値を取り、ここでＷ_maxは最大のウインドウ・サイズである。例示の目的のため、このシーケンスについて、ＴＣＰ ＲＥＮＯの輻輳回避ＡＩＭＤルールに対応する以下のランダム発展（random evolution）を想定する。ランダム加算増大ルールを適用して、これがｗに等しい場合に、全てのｗパケットについて、パケット・マーキングがない限り、１最大セグメント・サイズ（ＭＳＳ）だけウインドウが増大するようにする。パケットがルータの１つによってマークされている場合、乗法低減ルールが適用され、ウインドウを二等分する。実用の目的のため、二等分の整数近似を用いて、組｛１、２、．．．、Ｗ_max｝にウインドウを保持する。同様に、ウインドウがＷ_maxに等しい場合、第１のパケット・マーキングまでこれはこの値に等しいままである。確率ｐ（ｋ、ｌ）によって独立してパケットをマークすることを想定した場合、（Ｗ_m ^(k,l)）は非周期でエルゴード敵なマルコフ連鎖（Markovchain）である。

図４および図５に示す擬似ペトリ・ネットによるパケットの処理に関して、トークンを用いて、データ・パケット、肯定応答、または、一般的には、スケジューリングまたは逆圧機構に関連した制御イベントを表す。トークンは、遷移（図にはバー４８で表す）に関連した処理ルールに従って場所から場所へと移動する。かかるペトリ・ネットにおける一般的なルールは、遷移の上流の場所の各々においてトークンが利用可能になるとすぐに、この遷移によるトークンの処理が行われるというものである。次いで、遷移によって異なるある程度のランダムな処理時間の後に、上流の各場所から１つのトークンを消費し、遷移の下流の全ての場所で１つのトークンを生成する。

例えば、グループ通信のパケットを表すトークンは、図の左の部分に位置するソースにおいて生成される。これらのトークンは、場所から場所へと移動する、すなわち、処理ルールによって規定された条件に応じて、ランダムな処理時間に関連した遅延を伴って、バッファからバッファへと移動する。例示したように、ｈ＝ｂｅｇおよびｈ＝ｅｎｄの場所に至る遷移は、ヌルの処理時間を有する。他の遷移は、ルートに沿って先入れ先出し（ＦＩＦＯ）ルータをモデリングしている。これらの遷移における処理時間は、ランダムな変数であり、ルータ／リンクを介したグループ通信のパケット処理に対するクロス・トラヒックの影響を表す。ルータ（ｋ、ｌ、ｈ）を介したパケットｍのランダム処理時間は、（σ_m ^(k,l,h)）によって表記され、パケットｍの集合サービス・タイム（AggregatedService Time）と称する。ＴＣＰ接続のパケットを各ルータにおいてＦＩＦＯの方法でスケジューリングするという事実は、ローカル・フィードバック・ループによって表され、１つのトークンが各ルータにアタッチされる。図４に示すように、これらのローカル・ループは、可読性および明確さのため、最も右側のＴＣＰ接続上で表されるのみである。かかるローカル・ループの結果として、パケットｍは、パケットｍ−１が去った後にルータにおいてそのサービス・タイムを開始することができるだけである。

他のフィードバック・アークは、様々なフロー制御および逆圧機構を表す。関連する場所をボックスに拡大して、最初にその場所に存在したトークンの数で標示する。ペトリ・ネットの初期条件は、全てのその場所がトークンのないバッファを表すこと、すなわち、マルチキャストはまだ開始しておらず、全ての入力および出力バッファは空であるということである。

Ｂ_IN ^(k,l)と標示された場所を有するフィードバック・アークは、その母ノードに戻るエンド・システム・ノード（ｋ、ｌ）の受信側ウインドウ・サイズの公示を表す。このアーク上の場所、および、場所（ｋ、ｌ、１）、（ｋ、ｌ、２）、．．．、（ｋ、ｌ、ｅｎｄ）で形成されるサイクル内のトークンの合計数は、不変であり、Ｂ_IN ^(k,l)に等しいままである。ＴＣＰ接続（ｋ、ｌ）のイン・フライ・パケットの合計数にエンド・システム・ノード（ｋ、ｌ）の入力バッファにおけるパケット数を加えたものがＢ_IN ^(k,l)に等しい場合、このフィードバック・アークの場所にはトークンが残っていないので、場所（ｋ、ｌ、ｂｅｇ）の下流の遷移はブロックされる。

Ｂ_{OUT,(k’,l’)} ^(k,l)と標示された場所を有するフィードバック・アークは、エンド・システム・ノード（ｋ、ｌ）の入力バッファから出るストリームのブロッキングを表す。なぜなら、ＴＣＰ接続（ｋ’、ｌ’）に関連した出力バッファに空間がないからである。このアークは、場所（ｋ’、ｌ’、ｂｅｇ）の下流のものからでなく、場所（ｋ’、ｌ’、ｅｎｄ）の上流の遷移に由来する。なぜなら、ＴＣＰ接続（ｋ’、ｌ’）の受信側によって承認された場合、パケットはこの出力バッファから削除されるだけだからである。

輻輳ウインドウ（Ｗ_m ^(k,l)）_m³1で標示されたフィードバック・アークは、ＴＣＰの動的ウインドウ・フロー制御を表す。しかしながら、ウインドウ・サイズが時間と共に変化しているので、このアークは、古典的なイベント・グラフにおけるようにはふるまっていない。

ペトリ・ネット・モデルでは、各パケットが承認された。しかしながら、現在のＴＣＰ実施では、１つおきのセグメントについて肯定応答を送信することができる。これは、上述のペトリ・ネットにおけるパケットがＴＣＰ接続において２つのセグメントの送信を表すと言うことによって、考慮に入れることができる。この仮定に基づいて、２ｘＭＳＳの「抽象パケット」サイズをモデルにおいて使用可能である。抽象パケットにおいて表現される整数であるプロセスＷ_m、は、ＣＷＮＤ／（２ｘＭＳＳ）の整数部分に等しい可能性がある。ここで、ＣＷＮＤは、ＴＣＰプロトコルについて与えられた輻輳ウインドウである。次いで、この値は、続けて送信された各ウインドウごとに、ＭＳＳ／（２ｘＭＳＳ）＝１／２だけ増大する、すなわち、Ｗ_mの値は、２Ｗ_mパケットを続けて送信した後に、１だけ増大する。

エボリューション等式を構築するため、パケットｍがソース・ノードにおいて利用可能である時をＴ_mと表記する。飽和入力の場合では、通信の開始およびＴ_m＝１から、ソースにおいて、全パケットは準備ができている。遷移（ｋ、ｌ、ｈ）がパケットｍの送信を完了する時を、ｘ_m ^(k,l,h)と表記する。慣例により、ｘ_m ^(k,l,beg)は、パケットｍがＴＣＰ接続（ｋ、ｌ）のソース・ノードの出力バッファ（これはサイズＢ_OUT,(k,l) ^{(k-1,m(k-1,l))}のバッファである）から逸脱する時である。同様に、ｘ_m ^(k,l,end)は、パケットｍがＴＣＰ接続（ｋ、ｌ）の受信側ノードの入力パケット（これはサイズＢ_IN ^(k,l)のバッファからのものである）から逸脱する時である。最後のサブセクションにおいて提示したモデルのダイナミクスは、以下の等式の組によって与えられる（ここで、ｖは最大を表す）。

ｋ≧１、ｌ≧０について、以下が成り立つ。

ランダム・グラフにおいて最大重みの経路を見つけるため、１組の頂点が以下のように表されるランダム・グラフを考える。

頂点（ｋ、ｌ、ｈ、ｍ）の重みは、ｈ∈｛１、２、．．．、Ｈ_(k,l)｝およびｍ≧１についてσ_m ^(k,l,h)によって与えられ、ｈ∈｛beg, end｝についてゼロに等しい。重みは、ｍ≦０であるいかなる頂点についても−∞である。

エッジの組は、Ｅ₁∪Ｅ₂∪Ｅ₃∪Ｅ₄∪Ｅ₅によって与えられる。ここで、以下が成り立つ。

このグラフを表すための最も効率的な方法は、ツリー上よりも直列のＴＣＰ接続の場合に集中することである。これは、例えば図６において行われ、Ｅ₁アークは水平方向のものであり、Ｅ₂アークは垂直方向のものである。図において、他のアークはマークされている。

ルートにおいてパケット可用性を表すため、Ｔ_m−Ｔ_m-1に等しい重みを有する１組の頂点｛（−１、０、１、ｍ）｜ｍ∈Ｚ｝を生成する。全てのｍ∈Ｚに対して、（０、０、ｂｅｇ、ｍ）→（−１、０、１、ｍ）および（−１、０、１、ｍ）→（−１、０、１、ｍ−１）に向かう追加エッジを加える。

上述の等式に基づいた即時誘導は、ｋ、ｌ、ｈ、ｍの全てについてのものが与えられる。

重み（π）、（ｋ、ｌ、ｈ、ｍ）から（−１、０、１、０）に及ぶ経路の長さπは、ｋ＋ｈ＋ｍによって乗算した定数によって規定することができ、また、このグラフにおける頂点に隣接するものは有限数であることに留意すると、外側範囲（または広がり）が定数Ｄによって規定されると仮定する限り、これらの２つの定数はツリーのサイズおよびトポロジに左右されない。

喪失および再配列モデルについて、モデルは、先に導入したランダム・グラフ・フレームワークに基づいている。ＴＣＰ機構のセルフ・クロッキング・モデルは、マーキングの場合におけると同じに維持される。しかしながら、喪失が起こると、後のパケットに対する潜在的な影響を有するランダム・グラフの新しいブランチとして、再送信パケットを追加する。

以下の考察では、インデクスｍに関連したグラフの頂点は、パケットｍ自体、または、パケットｍの後およびまたはパケットｍ＋１の前に送信した再送信パケットを参照する。

明確な提示のため、通常の場合を最初に検討する。この場合、１つのみの接続を分離して考慮し、充分なバッファが全てのデータを受信し（そのため逆圧によって影響を受けない）、飽和ソースを有する。この場合、輻輳ウインドウがそれを可能とするとすぐに（送信するパケットが最大シーケンス番号の承認プラスＣＷＮＤにある場合）、パケットはＴＣＰソースによって送信される。

通常の場合における高速再送信高速回復は、１つのパケット（インデクスｍを有する）が失われ、他の隣接パケットが失われない場合に開始する。

パケットｍ−Ｗ_mの逸脱がトリガされるのは、パケットｍ−Ｗ_m＋１、．．．、ｍ−１のＡＣＫが受信され、ｍ＋Ｗ_mまで、パケットｍ＋１、ｍ＋２の逸脱をトリガする場合である（なぜなら、ウインドウはこの間隔で１ユニット必ず増大し、従ってパケットｍ＋Ｗ_mが送信されるとＷ_m＋１に等しいからである）。パケットｍは失われるが、パケットｍ＋１、ｍ＋２、．．．は受信され、複製ＡＣＫＳをソースに送信するようにトリガする。第３の複製ＡＣＫはソースによって受信される（パケットｍ＋３の到着に対応する）ので、高速再送信高速回復手順を開始する。パケットｍ、ｍ＋１、．．．、ｍ＋Ｗ_mの再送信を行い、現在のＣＷＮＤを二等分し、３ユニット増大させる。ほとんどの時間（Ｗ_m≦３の場合の極端な場合を除く）、パケットの送信を停止し、受信した最大シーケンス番号はｍ−１であり、ＣＷＮＤは（（Ｗ_m＋１）／２＋３）に低減した。次いで、すでに送信した新しいパケット、ｍ＋４、ｍ＋５、．．．を受信し、それらの各々が新しい複製ＡＣＫをソースに返信し、これがＣＷＮＤを１ユニット増大させる。従って、パケットｍ＋（Ｗ_m＋１）／２＋ｋに対応する複製ＡＣＫを受信する場合、それによって観察されるウインドウが（Ｗ_m−１）であるかのように、パケットｍ＋Ｗ_m＋ｋは送信される。この段階が終了するのは、再送信パケットｍが、パケットｍ＋Ｗ_m＋（Ｗ_m＋１）／２をトリガしたパケットｍ＋Ｗ_mの直後に到着した場合である。次いで、ウインドウの通常増大エボリューションを再開し、ＣＷＮＤは（Ｗ_m＋１）に等しく、最大承認シーケンス番号はｍ＋Ｗ_mである。パケットｍ＋Ｗ_m＋（Ｗ_m＋１）／２は、このため、すぐに送信される。

要約すると、パケットｍ＋１、．．．、ｍ＋Ｗ_mでは、ウインドウは、追加の増大によって自然に発展（evolve）している。そして、パケットｍ＋Ｗ_m＋１、．．．、ｍ＋Ｗ_m＋（Ｗ_m−１）／２について、これは、最大（（Ｗ_m−１）／２、１）である。次いで、パケットｍ＋Ｗ_m＋（Ｗ_m＋１）／２について、ウインドウを最初に（Ｗ_m＋１）／２にセットして、追加の増大を再開する。

通常でない場合のパケット喪失の表現は、もっと複雑である。ｍの喪失が検出された場合、パケットｍ＋１、ｍ＋２、．．．、ｍ＋Ｗ_mのいくつかはソースを出発しなかったかもしれないからである。これらのパケットの送出は輻輳ウインドウによって可能となるが、例えば逆圧および以前のノードから利用可能でないパケットのような他の制約によって、それらは遅延した可能性がある。

従って、喪失および再配列の場合の正確なモデルは、構築されない。代わりに、１組の保存的な変形によって得られた簡略化した扱いやすいモデルを記述する。喪失および再配列の場合のスケーラビリティを証明するため、すなわち無限ツリーのための正確なモデルにおけるスループットの明白性（positiveness）を証明するため、簡略化した保存的モデルが同じ意味でスケーリングすることを証明すれば充分である。

ｍ’（ここでｍ≦ｍ’≦Ｗ_mである）が、ｍの後および喪失を検出する前に送出した最後のパケットのインデクスである場合、パケットｍ、ｍ＋１、．．．ｍ’のウインドウの発展は、通常の追加増大に従う。次いで、これを、パケットｍ’の到着直後に再送信パケットｍを受信するまで、（Ｗ_m’−１）／２≧（Ｗ_m−１）／２に固定する。これが生じた場合、送信された可能性がある最新のパケットは、ｍ’＋ｍａｘ（（Ｗ_m−１）／２、１）≦ｍ＋Ｗ_m＋ｍａｘ（（Ｗ_m−１）／２、１）である。

このウインドウを、ｍ＋１、ｍ＋２、．．．、．．．、ｍ＋Ｗ_m＋ｍａｘ（（Ｗ_m−１）／２、１）−１について、ｍａｘ（（Ｗ_m−１）／２、１）に送信し、ウインドウの追加増大発展は、パケットｍ＋Ｗ_m＋ｍａｘ（（Ｗ_m−１）／２、１）から再開する。これは、真のシステムが、考察した簡略化モデルよりも常に大きなウインドウを有し、従ってスループットが優れているという意味で、保存的である。

再送信パケットは、通常の場合と同様、ｍ＋Ｗ_mとｍ＋Ｗ_m＋１との間に、通信の最後の可能なステップに含まれている。これは、セルフ・クロッキング機構が半分のウインドウで再開した後に、直感的に最悪の時点でネットワークに負担をかけすぎる傾向がある。

ＳＡＣＫがＴＣＰ接続によって実施される場合、ここで述べる簡略化モデルは、実際的なウインドウ発展に関してなお保存的である。ウインドウ全体でなく、喪失したパケットのみを再送信する。

検討中の宛先エンド・システムにおいて受信したパケットは、シーケンス番号によって規定される順序に従って、その娘ノードに転送される。上述のように、パケットｍが喪失すると、受信側エンド・システムの入力バッファにおいて、パケットｍ＋１、．．．、ｍ’をブロックする。それらは、パケットｍ’とｍ’＋１との間で送信されたパケットｍの再送信が受信されると、すぐに解放される。更に、ｍ’の正確な値は評価することが容易でないので、保存的な選択を行う。パケットｍが喪失したと仮定すると、最新の可能なパケット（すなわちｍ＋Ｗ_m）の到着および再送信を待たなければならない。これは、特に、パケットｍ＋１、．．．、ｍ＋Ｗ_m−１がこの追加的な再配列制約を生じさせることを意味する。

喪失モデルに関連したランダム・グラフにおいて、エンド・システムについての頂点は（ｋ、ｌ）である。データ・パケットはｍであり、インデクスｈはｖ（ｋ、ｌ、ｈ、ｍ）である。全てのｋ≧１、ｌ、ｈ、およびｍについて、ｖ（ｋ、ｌ、ｈ、ｍ）の上部に頂点ｖ’（ｋ、ｌ、ｈ、ｍ）を加え、これは、パケットｍとｍ＋１との間のパケットの再送信の可能性を表す。更に、以下のエッジを加えて、垂直および水平の構造にリンクさせる。

水平エッジ： ｖ’（ｋ、ｌ、１、ｍ）→ｖ（ｋ、ｌ、ｂｅｇ、ｍ）およびｖ’（ｋ、ｌ、ｈ、ｍ）→ｖ’（ｋ、ｌ、ｈ−１、ｍ） ｈ＝２、．．．Ｈ
垂直エッジ： ｖ’（ｋ、ｌ、ｈ、ｍ）→ｖ（ｋ、ｌ、ｈ、ｍ） ｈ＝１、．．．Ｈ

これらのエッジのうちどれも、いずれのｖからいずれのｖにも達しない。従って、更に別のエッジがなければ、これらの相補的な頂点は何の役割も持たない。

ＴＣＰ接続（ｋ、ｌ）に対するパケットｍの喪失および再送信の影響を表すため、以下のパケットを遅延させるパケットｍの再送信を表すため（インデクスｍ＋Ｗ_m−１とｍ＋Ｗ_mとｎ間の余分なパケットとして）、全てのｈ＝１、．．．Ｈ_k,lおよびｍ’’＝ｍ、．．．、ｍ＋Ｗ_mについて、エッジＥ₇：ｖ（ｋ、ｌ、ｈ、ｍ’’＋１）→ｖ’（ｋ、ｌ、ｈ、ｍ’’）を加え、パケットｍ、ｍ＋１、．．．、ｍ＋Ｗ_m−１の再配列を表すため、エッジＥ₆：ｖ（ｋ、ｌ、ｅｎｄ、ｍ）→ｖ’（ｋ、ｌ、Ｈ_k,l、ｍ＋Ｗ_m−１）を加える。

図６に、（ツリーでなく）ラインの場合の完全なグラフ（アレイＥ₁、．．．、Ｅ₇の全タイプを含む）を表す。Ｅ₇に属するエッジは、垂直ローカル・アークである。Ｅ₁およびＥ₂の他のクラスに属するエッジは、可読性のためにステーションｋおよびパケットｍから出発した場合にのみ提示されている。グラフは、Ｂ_IN＝Ｂ_OUT＝Ｂを想定している。

以下のことをモデルにおいて考慮することができる。ツリーのあるノードの外側範囲が大きい場合、このノードから多数の同時転送が開始するため、このノードからのアクセス・リンクは実際のボトルネックになり得る。従って、このノードから発する転送のスループットは、実際、同じノードから発する他の転送によって大きく影響を受ける場合がある。

この「ラスト・マイル・リンク」効果は、本モデルに組み込むことができる。参照経路上に位置しない転送によって生成される余分なトラヒックは、合計サービス・タイムの増大によって表すことができ、これは、ある参照ＴＣＰ転送に対するクロス・トラヒックの影響を表す。

これを制御するため、一般的な考えでは、ツリー内の全てのノードの外側範囲に、例えばＤのような決定論的制限を設けることである。先に用いたものと同様の議論を用いて、ラスト・マイル・リンク上で提供される帯域幅共有は公平であると示すことは容易であり、このリンク上の合計サービス・タイムがＤで乗算されるシステムは、スループットに関して保存的な下限のシステムである。

従って、全てのオンードの外側範囲が定数によって制限される場合はいつでも、このラスト・マイル効果なしの場合のスループットのスケーラビリティの証明は、この効果を考慮したスケーラビリティの証明に拡大される。

次に、ツリーのサイズが大きい場合のグループ通信のスループットを考察する。このため、無限ツリーの確率を考える。

均質モデルは、以下のパラメータが当てはまる場合である。ツリーは固定範囲Ｄを有する。全てのＴＣＰ接続は、構造的および統計的に等価である。ホップ数は、全ての接続において同じである。パケット・マーキングまたは喪失のプロセスは、全ての接続において独立し、同一に分散し、パケット・マーキングまたは喪失確率ｐである。合計サービス・タイムは、全てのルータにおいて独立し、同一に分散し、有限平均を有する法σである。ツリーのどこでも、全ての逆圧バッファは同一である。

非均質モデルは、マルチキャスト・ツリーにおける広がりの範囲（インデクス（ｋ、ｌ）によって記述される）が、定数Ｄによって上から規定されている場合である。全てのルータのホップ数は、定数によって上から規定され、すなわち全ての（ｋ、ｌ）についてＨ_k,l≦Ｈである。ＴＣＰ接続（ｋ、ｌ）におけるパケット喪失確率は、定数ｐによって上から規定されている。パラメータＢ_IN ^(k,l)およびＢ_{OUT,(k’,l’)} ^(k,l)は、それぞれ、（ｋ、ｌ）および（ｋ’、ｌ’）に依存しない定数Ｂ_INおよびＢ_OUTによって下から規定されている。合計サービス・タイムは、独立しており、有限平均のランダム変数σによって上から規定されている（強力な順序の意味で）。

等式（２）におけるように、ｘ_m ^(k,l,h)を定義する。均質の場合および飽和ソースについて、ほとんど確実な（「ａ．ｓ．」）限度、すなわち以下が存在する。

この限度は、決定論的なものであり、（ｋ、ｌ、ｈ）から独立している。実数γは、ツリーのサイズおよびトポロジ、各オーバーレイにおけるルータ数、ウインドウの発展、クラス・トラヒックをモデルする合計サービス・タイムの法、ＴＣＰ接続の喪失プロセス、および、逆圧機構のパラメータに依存する。これは、マルチキャスト・オーバーレイの漸近グループ・スループットと呼ぶ。

非均質の場合、決定論的であり（ｋ、ｌ、ｈ）とは独立した以下の式が成り立つ。

この場合、γは何らかの下限システムの漸近グループ・スループットである。

経路列挙を用いて、軽い尾（light tailed）の場合におけるスループットを検討する。追加の想定は、以下の通りである。ランダム変数σは軽い尾である。すなわち、実数τ＞０が存在し、全ての０≦ｔ≦τについて、以下が成り立つ。

従って、無限高さｋ＝０、１、２．．．を有するマルチキャスト・オーバーレイ・ツリーを考える。σの法は軽い尾であると仮定し、規定した範囲Ｄおよび規定したホップ数Ｈであり、（ｋ、ｌ）について一様に、ＥＣＮおよび喪失−再配列の場合の双方で、以下が成り立つ。

ランダム変数ｘ_m ^(k,l,end)は、（ｋ、ｌ、ｅｎｄ、ｍ）から（−１、０、１、０）までの最大重み経路の重みである。ＥＣＮの場合、関数φは、φ（ｋ、ｌ、ｈ、ｍ）＝（Ｈ＋２）ｋ＋２（Ｈ＋２）ｍ＋ｖ（ｋ、ｌ、ｈ）によって与えられ（ｖ（ｋ、ｌ、ｂｅｇ）＝０およびｖ（ｋ、ｌ、ｅｎｄ）＝Ｈ_(k,l)＋１の場合を除いてｖ（ｋ、ｌ、ｈ）＝ｈ）、このグラフではあらゆる経路に沿って厳密に減少している。

この結果、（ｋ、ｌ、ｈ、ｍ）から（−１、０、１、０）までの経路は、同じ頂点に戻ることができず、（ｋ、ｌ、ｅｎｄ、ｍ）から（−１、０、１、０）までの経路に含まれる１組の頂点は、（Ｈ＋２）ｋ＋２（Ｈ＋２）ｍ＋２Ｈ＋３よりも大きくなることはできない。

グラフにおけるノードの隣接の最大数は、ｍａｘ（３、Ｄ＋１）であるので、別の結果は、かかる経路の数が、（ｍａｘ（３、Ｄ＋１））^{(H+2)k+2(H+2)m+2H+3}によって規定されるということである。

従って、マルコフの不等式を用いて、全てのπについて以下を得る。

イベントのいくつかの結合の確率が、確率の和によって上限を規定されることを用いて、ｍ≧ｋ≧１およびＤ≧２について、以下が示される。

ｘが充分に大きく選択されると、実際、これがｅ^tX≧（Ａ（ｔ）（２Ｄ＋１））^5(H+2)になるように選択された場合、ｍのこれらの一連の確率関数は収束するので、ボレル−カンテリ・レンマから、Ｐ（ｌｉｍ ｓｕｐ_m→∞ｘ^{（k,l,end）}／ｍ≦ｘ）＝１であり、結果が証明される。

喪失および再配列の場合、関連グラフについて関数φの新しい定義を導入する。φ（ｍ、ｋ、ｈ）＝（Ｈ＋２）ｍ＋（Ｈ＋２）Ｗ_maxｋ＋ｖ（ｈ）であり、ここで、ｖ（ｂｅｇ）＝０、１≦ｈ≦Ｈの場合ｖ（ｈ）＝ｈであり、ｖ（ｅｎｄ）＝Ｈ＋（Ｈ＋２）（Ｗ_max−１）＋１）、Ｗ_maxは最大ウインドウ・サイズである。ＴＣＰでは、Ｗ_max＝ｍｉｎ（Ｂ_in、Ｂ_out）である。このため、この関数はこのランダム・グラフのあらゆる経路に沿って減少することがわかる。そして、先に与えられた結果は、同じ証明によってこの場合に拡張することができる。

実施例
シミュレーションおよび実験を行って、本発明のシステムおよび方法の理論上の調査をサポートし評価した。具体的には、大きいツリーのシミュレーションのために特に効率的である数式に基づいたシミュレータを開発した。更に、信頼性の高いマルチキャスト・アーキテクチャの試作品を作り、Ｐｌａｎｅｔ−Ｌａｂ環境において実験を行った。更に、離散イベント・シミュレータを用いて、ノード故障、ノード離脱、およびノード追加の条件のもとで、ツリーのダイナミクスをシミュレートした。

シミュレーション調査を行って、特に、ノードの大きなグループまたはツリーにおいて長いファイル転送で得られたスループットについて、本発明のシステムおよび方法のスケーラビリティを評価した。この目的のため、上述の発展数式に基づいて、（ｍａｘ、ｐｌｕｓ）シミュレータを用いた。従来の離散イベント・シミュレータに比べて、この数式に基づいたシミュレータの主な利点は、はるかに大きいツリーの処理を容易にすることである。これは、スケーラビリティ分析において重要な問題である。

シミュレーションの設定および仮定は、以下のように要約される。パケット・サイズおよびシミュレーション長さについて、全ての性能結果をパケットで与える。これは、２ＭＳＳに等価である。

参照のため、および、Ｐｌａｎｅｔ−Ｌａｂ実験とのコンパチビリティのため、ＭＳＳ＝１００Ｂと仮定し、そのためパケットは２００Ｂである。各シミュレーション実行において、１０Ｍパケットの送信（２ＧＢデータに等価である）をシミュレートした。

ツリー・トポロジに関して、結果は、バランスの取れた二進ツリーの場合のみで報告する。エンド・システムおよびネットワーク接続は均質である。ＴＣＰ接続では、均質の場合を考慮し、各接続は連続で１０のルータを通過する。この接続上で送信された全てのパケットは、独立確率ｐを有し、負帰還を得る（喪失またはマーキング）。デフォルトのオプションはｐ＝０．０１である。ＴＣＰ接続における遅延のばらつきが大きいため、タイムアウトの発生は考慮しない。

ネットワーク負荷に関して、クロス・トラヒックは、各ルータにおける合計サービス・タイムによって特徴付けられる。これらのシミュレーションにおいて、双方ともパレート・ランダム値と考え、各ルータ／リンクごとに平均は１０ｍｓに等しい。これは、伝播遅延およびクロス・トラヒックによる待ち行列を組み込む。デフォルトのオプションは指数である。

同じ実験を、異なる値のバッファ・サイズについて繰り返した。Ｂ_INが５０パケット（すなわち１０ＫＢ）にセットされ、Ｂ_OUTが５０、１００、１０００、１０，０００パケット（それぞれ１０ＫＢ、２０ＫＢ、２００ＫＢ、２ＭＢ）として変動する場合の結果のみを報告する。このスケーラビリティ分析において、バックアップ・バッファのサイズは、何ら影響を与えない。このため、これらの実験について、Ｗ_max＝ｍｉｎ（Ｂ_IN、Ｂ_OUT）＝５０パケットを得る。

スループットのスケーラビリティについて、１０２３ノードまでのサイズの完全二進ツリーをシミュレートし、喪失の処理は異なる変形を用いた。すなわち、ＴＣＰ ＲＥＮＯはタイプ（高速再送信）、ＴＣＰ ＳＡＣＫ、およびＥＣＮを用いたＴＣＰである。また、出力バッファ・サイズの影響を考察した。

図７は、ＴＣＰ−ＳＡＣＫの場合のグループ・サイズの関数としてスループットを示す。極めて直感的に、グループ・スループットはグループ・サイズの減少関数であり、出力バッファ・サイズの増大関数であることが容易にわかる。出力バッファが大きく、１０００パケットより大きい場合、スループットは、小さいグループすなわち１０ノード未満で極めて迅速に平坦になる。もっと小さい出力バッファでは、漸近スループットへの収束は、グループ・サイズが１００ノードに達する場合に観察することができる。ＴＣＰの他の２つの変形は、同じ構成で、もっと小さい挙動を示す。ＳＡＣＫを用いないＴＣＰは、ＴＣＰ ＳＡＣＫのものより約８％小さいスループットを有するが、ＴＣＰ ＥＣＮはＴＣＰ ＳＡＣＫよりも約２％改善したわずかに優れたスループットを有する。

逆圧を用いない漸近スループットおよび単一接続スループットを比較すると、グループ・スループットは、送信側においてパケット可用性に対する制約なしで、単一接続のものの最小に等しい。このスループットは、ローカル・スループットと称する。従って、均質の場合、これは、グループ・スループットがローカル・スループットと同一であるということになる。本発明において、逆圧機構のため、この関係は保持されない。しかしながら、グループ漸近スループットがローカル・スループットからいかに遠いかを知ることは興味深い。表Ｉでは、これらの２つの量の比を与える。大きい出力バッファを有するグループ・スループットがローカル・スループットに極めて近いことを観察することは有意義である。換言すると、大きい出力バッファは、極めて重要な方法で、逆圧機構の効果を低減する。出力バッファが、例えば５０パケットのように（入力バッファと同一である）小さい場合であっても、逆圧機構によるグループ・スループットの劣化は中程度である（１８％未満）。

これらの例では、合計サービス・タイムによって、ルータにおけるクロス・トラヒックをモデル化する。合計サービス・タイムの軽い尾の想定のもとでのグループ・スループットのスケーラビリティを示す。シミュレーションを用いて、特に重い尾である場合のこの分布の影響を示す。図８において、指数および異なるパラメータを持つパレート分布について、グループ・サイズの関数としてスループットを示す。図８は、分布の尾が重くなると、スループットが小さくなることを示す。更に、パレートのように重い尾の分布についても、パラメータが２．１である場合のように第２のモーメントが存在する場合、スループット曲線は指数分布のものと同様の形状を有する。しかしながら、パラメータが１．９である場合、第２のモーメントはもはや存在せず、スループット曲線はいっそう速く減衰する傾向がある。これが示すのは、軽い尾の分布の想定は、何らかのモーメント条件によって緩和され置換され得るということである。実際、特別なチェーン・ツリーの場合、合計サービス・タイムが厳密に第２のモーメントよりも高いモーメントを有する場合、グループ・スループットは厳密に正の定数によって下限を規定されることがわかる。

出力バッファが大きい場合、漸近グループ・スループットは、単一接続のスループットに比較的近い。シミュレーションによって、逆圧機構を用いる場合であっても、グループ・スループットは単一接続スループットのものと同様の形状を有するということが示される。図９は、特定の場合のパケット喪失確率の関数としてグループ・スループットを示す。例示するように、単一接続スループット（すなわちローカル・スループット）は、サイズ１２６のグループのものに極めて近い。

モデルの実用性を評価するため、ＴＣＰマルチキャスト・オーバーレイ・システムの試作品を作った。Ｐｌａｎｅｔ−Ｌａｂネットワークを用い、大学に位置するコンピュータおよび世界中の研究センターに対するアクセスを得る。実施は、信号装置およびパイプによって同期させて、各出力および入力バッファごとに分離したプロセスを実行する。入力バッファからデータを読み取るとすぐに、それらは送信のために利用可能となる。別個の信号装置を用いて、データを出力バッファに送信することができない場合、データが入力ソケットから読み取られないことを保証し、逆圧を生成する。専用の中央ノードを用いて、実験の進展を監視し制御する。

スループットのスケーラビリティを分析するため、６３ノードのバランスの取れた二進ツリーを構築し、インターネットに接続した。同じソースのサイズ１５、３１、および６３のバランスの取れたサブツリーにおいて、同時送信を開始した。同時に実験を実行することによって、ネットワーキング条件の変動に関連する問題を回避した。このように、異なるサイズのツリー間で、ツリーを通してほぼ等しい比率で、リンク容量を常に共用する。パケット／秒でスループットを測定し、１０ＭＢデータの送信中に各リンクでこれを達成した。リンクのスループットは、受信ノードによって測定した。表ＩＩは、３つの異なるツリー・サイズおよび３つの異なる出力バッファ・サイズ設定について、グループ・スループット測定をまとめている。グループ・スループットは、ツリー内で観察されるリンク・スループットの最小値として計算する。先に示したシミュレーションと同様、各パケット・サイズは２００バイトである。更に、入力バッファ・サイズは５０パケットに等しく、出力バッファ・サイズは可変である。出力バッファ・サイズはパケット単位で与える。

グループ・スループットがグループ・サイズ内において極めてわずかに変化することがわかる。これは、上述のシミュレーション結果と一致しているが、予想されるように、絶対数は異なる。

この手法が故障後に回復することを検証するため、Ｐｌａｎｅｔ−Ｌａｂマシン上で実行する５ノードの耐故障チェーンを実施した。１０メガバイトのデータの送信中、５ノードのうち２つが故障する。故障は同時でなく、システムは１つの故障にのみ耐える必要がある。この実験において、入力バッファおよび出力バッファの双方のサイズは５０パケットに制限した。先の実験においてと同様、各パケットのサイズは２００バイト（ＭＳＳ＝１００バイト）である。故障回復アルゴリズムは、この場合、サイズ１５０のバックアップ・バッファを必要とする。この実験の１０回の実行を行い、グループ・スループットを測定した。接続後に再送信した冗長パケットの再接続時間および数を復元する。本アーキテクチャにおいて、再アタッチ手順の間にパケット・シーケンス番号を公示する必要はないことに留意すべきである。このため、故障ノードの娘ノードは、接続を再確立した後に複製パケットを受信することができる。これらの冗長送信は、グループ・スループットに影響を与える可能性がある。

我々の実施において、故障ノードは全てのその接続を閉じ、故障はドロップした接続を検出することによって検出される。故障を検出した後、孤立娘ノードは、生き残った祖先から入来する接続を聞き取る。故障を検出した時点と接続を復元した時点との間の間隔を測定する。この時間間隔は、２つの参加ノード、すなわち生き残った母（Ｍ）および娘（Ｄ）において別個に測定する。これらの測定結果を表ＩＩＩにまとめる。１つの故障当たり、秒単位の平均再接続時間および再送信パケットの数を与える。実験ごとに、平均グループ・スループットを与える。これらの実験において、再送信パケットの平均数は、バックアップ・バッファ・サイズの約半分である。ＴＣＰセッションは、ＴＣＰタイムアウトと同じ順序で、数秒で再確立される。故障検出を数秒で達成可能であるので、実験結果は、故障検出および再接続の手順全体が数秒で完了可能であることを示す。

上述のシミュレーション結果は、故障がない場合、バッファが大きいほどグループ・スループットがスケーラブルになることを示している。しかしながら、バッファが大きいと、エンド・ツー・エンドの信頼性を保証するため、バックアップ・バッファのサイズも比例して大きくなる。上述の実験は、故障が発生すると、バックアップ・バッファの大型化の結果として冗長送信が増加することを示した。これらの冗長送信は、次いで、グループ・スループットを低下させる。

この問題を調べるため、２、４、および６の故障（順次生じるので、システムは１つの故障を許容すれば良い）を有する１０ノードのチェーンを考える。表ＩＶは、これらの設定および異なる出力バッファ・サイズで得られたスループット測定値を示す。バックアップ・バッファ・サイズは、入力バッファ・サイズにセットされ、出力バッファ・サイズの２倍にセットされる。バッファ・サイズが大きくなると、グループ・スループットが実際に低下する可能性があることは興味深い。これらの実験によって、バッファ・サイズにおけるスループットの単調さは、故障がある場合にはもはや当てはまらないことが示される。故障が頻繁に起これば起こるほど、グループ・スループットに対して大きいバッファが与える影響はいっそう大きく（負に）なる。

上述のシミュレーションおよび実験を補足するため、離散イベント・シミュレータを作って、異なるアルゴリズムのもとの故障および回復によってツリー・トポロジの発展をシミュレートした。具体的には、ツリー再構成の発見的方法を評価した。

１０２３ノードのバランスの取れた二進ツリーから開始して、故障ノードを選択し、ランダムまたはグリーディな発見的方法を適用して接続性を復元する。ノードは、ベスト・ジョイン（best-join）を用いて追加した。ツリーは二進のままであり、２未満の外側範囲のノードにおいてのみ参加が許された。最長経路の長さおよび非リーフ・ノードの平均範囲を測定した。接続性を復元するために用いた２つの方法は、GREEDY_RECONNECT、および、２未満の外側範囲で孤立サブツリーをランダムに選択したノードに再接続するランダム化手順であった。

図１０および図１１に結果を示す。図１０には、ツリー深さの発展について、図１１には、非リーフ・ノードの平均範囲の発展についての結果を示す。これらのグラフは、５００回の実行にわたる平均ツリー深さおよび内部ノード広がりを示す。GREEDY_RECONNECTによって、ランダムニアクティブ・ノードを選択する平凡な手法に比べて、著しく小さいツリー深さおよび大きい内部ノード範囲を維持するのに役立つ。

ここで加持した本発明の例示的な実施形態が本発明の目的を達成することは明らかであるが、当業者によって、多数の変更および他の実施形態を考案可能であることは認められよう。更に、いずれかの実施形態からの機構（複数の機構）あるいは要素（複数の要素）またはその両方を、単独で、または他の実施形態（複数の実施形態）と組み合わせて使用可能である。従って、特許請求の範囲は、本発明の精神および範囲内に該当する全てのかかる変更および実施形態を包含するように意図されることは理解されよう。

本発明に従ったマルチキャスト・オーバーレイ・ネットワークの概略図である。 図１のオーバーレイ・ネットワークの別の概略図である。 本発明のオーバーレイ・ネットワークにおいて用いるエンド・システム・ノードの概略図である。 本発明に従った入力および出力ブロッキングを有する高さ２の二進ツリーの概略図である。 図４の単一ノードの概略図である。 再送信および再配列の制約を有する一連のＴＣＰ接続を表すランダム・グラフである。 ＴＣＰ ＳＡＣＫ、指数クロス・トラヒック、および異なる出力バッファ・サイズを有する、グループ・サイズの関数としてのグループ・スループットのグラフである。 クロス・トラヒックのいくつかの法についてのスループットのグラフである。 パケット喪失確率に関するグループ・スループットのグラフである。 ツリー深さの発展の一例のグラフである。 非リーフ・ノードの平均範囲の発展の一例のグラフである。

Claims (33)

1. スケーラブルなグループ通信スループットおよびエンド・ツー・エンド信頼性のあるマルチキャスト・オーバーレイ・ネットワーク・ツリーにおいてソース・ノードからリーフ・ノードを含む複数のエンド・システム・ノードへとデータ・パケットを配信するための方法であって、
   前記複数のエンド・システム・ノードのうち、前記ソース・ノードと前記リーフ・ノードの間の中間ノードが有限サイズの入力バッファ、出力バッファおよびバックアップ・バッファを含み、前記バックアップ・バッファのサイズが前記入力バッファおよび前記出力バッファの最大サイズならびに許容可能な同時ノード故障の数によって決められ、
   前記方法が、
   前記中間ノードにおいて入力バッファから出力バッファに転送されるデータ・パケットのコピーを前記バックアップ・バッファにストアするステップと、
   通信プロトコルまたは逆圧機構を用いて前記マルチキャスト・オーバーレイ・ネットワーク・ツリーにおけるエンド・システム・ノード間のデータ・パケット喪失を防止するステップを含む、方法。
2. スケーラブルなグループ通信スループットおよびエンド・ツー・エンド信頼性のあるマルチキャスト・オーバーレイ・ツリーにおいてソース・ノードからリーフ・ノードを含む複数のエンド・システム・ノードへとデータ・パケットを配信するための方法であって、
   前記複数のエンド・システム・ノードのうち、前記ソース・ノードと前記リーフ・ノードの間の中間ノードが有限サイズの入力バッファ、出力バッファおよびバックアップ・バッファを含み、前記バックアップ・バッファのサイズが前記入力バッファおよび前記出力バッファの最大サイズならびに許容可能な同時ノード故障の数によって決められ、
   前記方法が、
   前記中間ノードにおいて入力バッファから出力バッファに転送されるデータ・パケットのコピーを前記バックアップ・バッファにストアするステップと、
   前記マルチキャスト・オーバーレイ・ツリーにおいて少なくとも１つのエンド・システム・ノード故障を検出するステップと、
   前記エンド・システム・ノード故障によって生成した孤立エンド・システム・ノードを前記マルチキャスト・オーバーレイ・ツリーに再接続して、前記マルチキャスト・オーバーレイ・ツリーにおける全ての残りのエンド・システム・ノードへの信頼性の高いデータ・パケット転送を行いながら、前記ソース・ノードから前記残りのエンド・システム・ノードの各々への完全なデータ・パケット・シーケンスの配信を維持するステップと、
   を含む、方法。
3. 前記少なくとも１つのエンド・システム・ノード故障を検出するステップが、複数の同時エンド・システム・ノード故障を検出するステップを更に含み、前記孤立エンド・システム・ノードを再接続するステップが、前記複数のエンド・システム・ノード故障によって生成した前記孤立エンド・システム・ノードの全てを前記マルチキャスト・オーバーレイ・ツリーに同時に再接続するステップを更に含む、請求項２に記載の方法。
4. １つ以上のエンド・システム・ノードにストアされたオーバーレイ・ツリートポロジを用いて、前記マルチキャスト・オーバーレイ・ツリーへの前記孤立エンド・システム・ノードの再接続を容易にするステップを更に含む、請求項２に記載の方法。
5. 前記孤立エンド・システム・ノードを再接続するステップが、
   故障したエンド・システム・ノードの各孤立エンド・システム・ノードを、前記故障したエンド・システム・ノードの生き残った祖先ノードのサブツリーに属する代替的な母ノードに再接続するステップと、
   前記サブツリーを介して、前記生き残った祖先ノードにおけるバックアップ・バッファにストアされたデータ・パケットのコピーを再送信するステップと、
   を更に含む、請求項２に記載の方法。
6. 前記生き残った祖先ノードが、前記故障したエンド・システム・ノードから前記ソース・ノードまでの経路において最初の生き残ったノードである、請求項５に記載の方法。
7. 前記孤立エンド・システム・ノードの各々を再接続するステップがグリーディな発見的方法を用いるステップを更に含む、請求項５に記載の方法。
8. 前記グリーディな発見的方法を用いるステップが、
   前記故障したエンド・システム・ノードの孤立娘ノードに発する複数の孤立サブツリーから最大の深さを有する孤立サブツリーを選択するステップと、
   前記ソース・ノードに最も近い代替的な母ノードを選択するステップと、
   前記選択した孤立サブツリーを前記選択した代替的な母ノードに接続するステップと、
   全ての孤立サブツリーが代替的な母ノードに接続されるまで、前記孤立サブツリーの選択を繰り返すステップと、
   を含む、請求項７に記載の方法。
9. 前記マルチキャスト・オーバーレイ・ツリーをさかのぼって前記ソース・ノードまで、前記マルチキャスト・オーバーレイ・ツリーにおいて前記再接続した孤立エンド・システム・ノードに関する情報を配信するステップと、
   前記再接続した孤立エンド・システム・ノードに祖先エンド・システム・ノード情報を配信するステップと、
   を更に含む、請求項５に記載の方法。
10. 前記データ・パケットのコピーを前記再接続した孤立エンド・システム・ノードに転送するステップを更に含む、請求項２に記載の方法。
11. 各バックアップ・バッファのサイズがＢ_BACKであり、Ｂ_BACK≧ｍ（Ｂ_OUT ^max＋Ｂ_IN ^max）＋Ｂ_OUT ^maxであり、Ｂ_OUT ^maxは最大出力バッファ・サイズであり、Ｂ_IN ^maxは最大入力バッファ・サイズであり、ｍは、前記バックアップ・バッファにストアした前記データ・パケットのコピーが対処可能な同時エンド・システム・ノード故障の数である、請求項１０に記載の方法。
12. 前記マルチキャスト・オーバーレイ・ツリーからエンド・システム・ノードを切断するステップを更に含み、このステップが、
    保留中の切断について、切断される前記エンド・システム・ノードの母ノードおよび全ての娘ノードに通知し、
    前記母ノードおよび前記娘ノードの全てから前記エンド・システム・ノードを切断し、 前記切断したエンド・システム・ノードの各切断した娘ノードを、前記切断したエンド・システム・ノードの生き残った祖先ノードのサブツリーに属する代替的な母ノードに再接続し、
    前記サブツリーを介して、前記生き残った祖先ノードにおけるバックアップ・バッファにストアされたデータ・パケットのコピーを再送信することによって実行される、請求項２に記載の方法。
13. 前記マルチキャスト・オーバーレイ・ツリーに新しいエンド・システム・ノードを接続するステップを更に含み、このステップが、
    前記ソース・ノードに連絡し、
    新しいエンド・システム・ノードを接続するための母ノードを識別し、
    前記識別した母ノードに前記新しいエンド・システム・ノードを接続することによって実行される、請求項２に記載の方法。
14. 前記マルチキャスト・オーバーレイ・ツリーにおけるバッファ・サイズの制約に関して前記新しいエンド・システム・ノードに通知するステップを更に含む、請求項１３に記載の方法。
15. 前記マルチキャスト・オーバーレイ・ツリー全体に更新したトポロジ情報を配信するステップを更に含む、請求項１３に記載の方法。
16. スケーラブルなグループ通信スループットおよびエンド・ツー・エンド信頼性のあるマルチキャスト・オーバーレイ・ツリーにおいてソース・ノードからリーフ・ノードを含む複数のエンド・システム・ノードへとデータ・パケットを配信するための方法であって、
    前記複数のエンド・システム・ノードのうち、前記ソース・ノードと前記リーフ・ノードの間の中間ノードが有限サイズの入力バッファ、出力バッファおよびバックアップ・バッファを含み、前記バックアップ・バッファのサイズが前記入力バッファおよび前記出力バッファの最大サイズならびに許容可能な同時ノード故障の数によって決められ、
    前記方法が、
    前記中間ノードにおいて入力バッファから出力バッファに転送されるデータ・パケットのコピーを前記バックアップ・バッファにストアするステップと、
    通信プロトコルまたは逆圧機構を用いて前記マルチキャスト・オーバーレイ・ツリーにおけるエンド・システム・ノード間のデータ・パケット喪失を防止するステップと、
    前記マルチキャスト・オーバーレイ・ツリーにおいて少なくとも１つのエンド・システム・ノード故障を検出するステップと、
    前記エンド・システム・ノード故障によって生成した孤立エンド・システム・ノードを前記マルチキャスト・オーバーレイ・ツリーに再接続して、前記マルチキャスト・オーバーレイ・ツリーにおける全ての残りのエンド・システム・ノードへの信頼性の高いデータ・パケット転送を行いながら、前記ソース・ノードから前記残りのエンド・システム・ノードの各々への完全なデータ・パケット・シーケンスの配信を維持するステップと、
    を含む、方法。
17. 前記データ・パケット喪失を防止するステップが、
    伝送制御プロトコルを用いて前記マルチキャスト・オーバーレイ・ツリーにおけるエンド・システム・ノード間でデータ・パケットを転送するステップと、
    前記逆圧機構を用いて前記エンド・システム・ノードにおける入力バッファおよび出力バッファにおいてオーバーフローを防止するステップと、
    を含む、請求項１６に記載の方法。
18. 前記少なくとも１つのエンド・システム・ノード故障を検出するステップが、複数の同時エンド・システム・ノード故障を検出するステップを更に含み、前記孤立エンド・システム・ノードを再接続するステップが、前記複数のエンド・システム・ノード故障によって生成した前記孤立エンド・システム・ノードの全てを前記マルチキャスト・オーバーレイ・ツリーに同時に再接続するステップを更に含み、このステップが、
    故障した各ノードの各孤立ノードを、前記故障ノードの生き残った祖先ノードのサブツリーに属する代替的な母ノードに再接続し、
    全てのサブツリーを介して、前記生き残った祖先ノードにおけるバックアップ・バッファにストアされたデータ・パケットのコピーを再送信することによって実行される、請求項１６に記載の方法。
19. 前記孤立ノードの各々を再接続するステップが、グリーディな発見的方法を用いるステップを含み、このステップが、
    前記故障ノードの孤立娘ノードに発する複数の孤立サブツリーから最大の深さを有する孤立サブツリーを選択するステップと、
    前記ソース・ノードに最も近い代替的な母ノードを選択するステップと、
    前記選択した孤立サブツリーを前記選択した代替的な母ノードに接続するステップと、 全ての孤立サブツリーが代替的な母ノードに接続されるまで、前記孤立サブツリーの選択を繰り返すステップと、
    を含む、請求項１８に記載の方法。
20. 前記マルチキャスト・オーバーレイ・ツリーをさかのぼって前記ソース・ノードまで、前記マルチキャスト・オーバーレイ・ツリーにおいて前記再接続した孤立エンド・システム・ノードに関する情報を配信するステップと、
    前記再接続した孤立エンド・システム・ノードに祖先エンド・システム・ノード情報を配信するステップと、
    を更に含む、請求項１８に記載の方法。
21. 前記データ・パケットのコピーを前記再接続した孤立エンド・システム・ノードに転送するステップを更に含む、請求項１６に記載の方法。
22. 各バックアップ・バッファのサイズがＢ_BACKであり、Ｂ_BACK≧ｍ（Ｂ_OUT ^max＋Ｂ_IN ^max）＋Ｂ_OUT ^maxであり、Ｂ_OUT ^maxは最大出力バッファ・サイズであり、Ｂ_IN ^maxは最大入力バッファ・サイズであり、ｍは、前記バックアップ・バッファにストアした前記データ・パケットのコピーが対処可能な同時エンド・システム・ノード故障の数である、請求項２１に記載の方法。
23. 前記マルチキャスト・オーバーレイ・ツリーからエンド・システム・ノードを切断するステップを更に含み、このステップが、
    保留中の切断について、切断される前記エンド・システム・ノードの母ノードおよび全ての娘ノードに通知し、
    前記母ノードおよび前記娘ノードの全てから前記エンド・システム・ノードを切断し、 前記切断したエンド・システム・ノードの各切断した娘ノードを、前記切断したエンド・システム・ノードの生き残った祖先ノードのサブツリーに属する代替的な母ノードに再接続し、
    前記サブツリーを介して、前記生き残った祖先ノードにおけるバックアップ・バッファにストアされたデータ・パケットのコピーを再送信することによって実行される、請求項１６に記載の方法。
24. コンピュータ実行可能コードを含むコンピュータ読み取り可能記録媒体であって、コンピュータによって読み取られると、スケーラブルなグループ通信スループットおよびエンド・ツー・エンド信頼性のあるマルチキャスト・オーバーレイ・ツリーにおいてソース・ノードからリーフ・ノードを含む複数のエンド・システム・ノードへとデータ・パケットを配信するための方法を前記コンピュータに実行させ、
    前記複数のエンド・システム・ノードのうち、前記ソース・ノードと前記リーフ・ノードの間の中間ノードが有限サイズの入力バッファ、出力バッファおよびバックアップ・バッファを含み、前記バックアップ・バッファのサイズが前記入力バッファおよび前記出力バッファの最大サイズならびに許容可能な同時ノード故障の数によって決められ、
    前記方法が、
    前記中間ノードにおいて入力バッファから出力バッファに転送されるデータ・パケットのコピーを前記バックアップ・バッファにストアするステップと、
    通信プロトコルまたは逆圧機構を用いて前記マルチキャスト・オーバーレイ・ツリーにおけるエンド・システム・ノード間のデータ・パケット喪失を防止するステップを含む、コンピュータ読み取り可能記録媒体。
25. 前記データ・パケット喪失を防止するステップが、
    伝送制御プロトコルを用いて前記マルチキャスト・オーバーレイ・ツリーにおけるエンド・システム・ノード間でデータ・パケットを転送するステップと、
    前記逆圧機構を用いて前記エンド・システム・ノードにおける入力バッファおよび出力バッファにおいてオーバーフローを防止するステップと、
    を含む、請求項２４に記載のコンピュータ読み取り可能記録媒体。
26. コンピュータ実行可能コードを含むコンピュータ読み取り可能記録媒体であって、コンピュータによって読み取られると、スケーラブルなグループ通信スループットおよびエンド・ツー・エンド信頼性のあるマルチキャスト・オーバーレイ・ツリーにおいてソース・ノードからリーフ・ノードを含む複数のエンド・システム・ノードへとデータ・パケットを配信するための方法を前記コンピュータに実行させ、
    前記複数のエンド・システム・ノードのうち、前記ソース・ノードと前記リーフ・ノードの間の中間ノードが有限サイズの入力バッファ、出力バッファおよびバックアップ・バッファを含み、前記バックアップ・バッファのサイズが前記入力バッファおよび前記出力バッファの最大サイズならびに許容可能な同時ノード故障の数によって決められ、
    前記方法が、
    前記中間ノードにおいて入力バッファから出力バッファに転送されるデータ・パケットのコピーを前記バックアップ・バッファにストアするステップと、
    前記マルチキャスト・オーバーレイ・ツリーにおいて少なくとも１つのエンド・システム・ノード故障を検出するステップと、
    前記エンド・システム・ノード故障によって生成した孤立エンド・システム・ノードを前記マルチキャスト・オーバーレイ・ツリーに再接続して、前記マルチキャスト・オーバーレイ・ツリーにおける全ての残りのエンド・システム・ノードへの信頼性の高いデータ・パケット転送を行いながら、前記ソース・ノードから前記残りのエンド・システム・ノードの各々への完全なデータ・パケット・シーケンスの配信を維持するステップと、
    を含む、コンピュータ読み取り可能記録媒体。
27. 前記孤立エンド・システム・ノードを再接続するステップが、
    故障したエンド・システム・ノードの各孤立エンド・システム・ノードを、前記故障したエンド・システム・ノードの生き残った祖先ノードのサブツリーに属する代替的な母ノードに再接続するステップと、
    前記サブツリーを介して、前記生き残った祖先ノードにおけるバックアップ・バッファにストアされたデータ・パケットのコピーを再送信するステップと、
    を更に含む、請求項２６に記載のコンピュータ読み取り可能記録媒体。
28. 前記生き残った祖先ノードが、前記故障したエンド・システム・ノードから前記ソース・ノードまでの経路において最初の生き残ったノードであり、
    前記孤立エンド・システム・ノードの各々を再接続するステップがグリーディな発見的方法を用いるステップを含む、請求項２７に記載のコンピュータ読み取り可能記録媒体。
29. 前記グリーディな発見的方法を用いるステップが、
    前記故障したエンド・システム・ノードの孤立娘ノードに発する複数の孤立サブツリーから最大の深さを有する孤立サブツリーを選択するステップと、
    前記ソース・ノードに最も近い代替的な母ノードを選択するステップと、
    前記選択した孤立サブツリーを前記選択した代替的な母ノードに接続するステップと、 全ての孤立サブツリーが代替的な母ノードに接続されるまで、前記孤立サブツリーの選択を繰り返すステップと、
    を含む、請求項２８に記載のコンピュータ読み取り可能記録媒体。
30. 前記少なくとも１つのエンド・システム・ノード故障を検出するステップが、複数の同時エンド・システム・ノード故障を検出するステップを更に含み、前記孤立エンド・システム・ノードを再接続するステップが、前記複数のエンド・システム・ノード故障によって生成した前記孤立エンド・システム・ノードの全てを前記マルチキャスト・オーバーレイ・ツリーに同時に再接続するステップを更に含み、このステップが、
    故障した各ノードの各孤立ノードを、前記故障ノードの生き残った祖先ノードのサブツリーに属する代替的な母ノードに再接続し、
    全てのサブツリーを介して、前記生き残った祖先ノードにおけるバックアップ・バッファにストアされたデータ・パケットのコピーを再送信することによって実行される、請求項２６に記載のコンピュータ読み取り可能記録媒体。
31. 前記方法が、
    前記データ・パケットのコピーを前記再接続した孤立エンド・システム・ノードに転送するステップを更に含み、各バックアップ・バッファのサイズがＢ_BACKであり、Ｂ_BACK≧ｍ（Ｂ_OUT ^max＋Ｂ_IN ^max）＋Ｂ_OUT ^maxであり、Ｂ_OUT ^maxは最大出力バッファ・サイズであり、Ｂ_IN ^maxは最大入力バッファ・サイズであり、ｍは、前記バックアップ・バッファにストアした前記データ・パケットのコピーが対処可能な同時エンド・システム・ノード故障の数である、請求項２６に記載のコンピュータ読み取り可能記録媒体。
32. 前記方法が、前記マルチキャスト・オーバーレイ・ツリーからエンド・システム・ノードを切断するステップを更に含み、このステップが、
    保留中の切断について、切断される前記エンド・システム・ノードの母ノードおよび全ての娘ノードに通知し、
    前記母ノードおよび前記娘ノードの全てから前記エンド・システム・ノードを切断し、
    前記切断したエンド・システム・ノードの各切断した娘ノードを、前記切断したエンド・システム・ノードの生き残った祖先ノードのサブツリーに属する代替的な母ノードに再接続し、
    前記サブツリーを介して、前記生き残った祖先ノードにおけるバックアップ・バッファにストアされたデータ・パケットのコピーを再送信することによって実行される、請求項２６に記載のコンピュータ読み取り可能記録媒体。
33. 前記方法が、前記マルチキャスト・オーバーレイ・ツリーに新しいエンド・システム・ノードを接続するステップを更に含み、このステップが、
    前記ソース・ノードに連絡し、
    前記新しいエンド・システム・ノードを収容するための充分な利用可能外側範囲容量を有する母ノードを識別し、
    前記識別した母ノードに前記新しいエンド・システム・ノードを接続し、
    前記マルチキャスト・オーバーレイ・ツリーにおけるバッファ・サイズの制約に関して前記新しいエンド・システム・ノードに通知し、
    前記マルチキャスト・オーバーレイ・ツリー全体に更新したトポロジ情報を配信することによって実行される、請求項２６に記載のコンピュータ読み取り可能記録媒体。

Images