JP2000049779A - ディジタル通信ネットワーク上のエンドノードによるマルチキャスト情報配布方法 - Google Patents

Abstract

(57)【要約】 【課題】 ディジタルデータや情報をネットワーク中の
複数のエンドノードに効率的に、信頼性をもって、かつ
自動的に配布する方法を提供すること。 【解決手段】 接続されループの無いマルチキャストツ
リーを自動的に生成、維持する方式をアプリケーション
層マルチキャストと組み合せ、各新ノードはその隣接ノ
ードを選択し選択された隣接ノードを隣接ノードリスト
にその親ノードとして追加することによりマルチキャス
トツリーに加入する場合に、各ノードは、（１）親ノー
ドを持たないルートノードを除く各ノードは、常にただ
一つだけ親ノードを維持すること、（２）あるノードが
親ノードを選択する際に、ルートパスがそのあるノード
をふくむようなノードが子側ノードとして識別され、そ
の子側ノードからルートノードへ導く親ノードの系列を
ルートパスとした時に、該あるノードは子側ノードをそ
の親ノードとしては決して選択しないこと、という規則
に従う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ディジタル通信ネ
ットワークに関し、より詳しくはネットワーク内の複数
エンドノードにディジタルデータまたは情報を配布する
方法に関する。

【０００２】

【従来の技術】以下の文献は、本発明の分野の一般背景
情報を提供するものであり、以下の記載において括弧内
に示された略号により参照されるものである。

【０００３】[CBT] A. Ballardie, Core Based Trees
(CBT) Multicast RoutingArchitecture, RFC 2201, Sep
tember, 1997. [DVMRP] D. Waitzman, C. Partridge, S. Deering, Dis
tance Vector MulticastRouting Protocol, RFC 1075,
November, 1988. [IRC] J. Oikarinen, D. Reed, Internet Relay Chat P
rotocol, RFC 1459,May, 1993. [MBONE] The MBONE FAQ, http://www.mbone.com/mbone/
mbone.faq.html, Jan,1997. [SMTP] J. Postel, Simple Mail Transfer Protocol, R
FC 821, August, 1982. [SOM] M. Sola, M. Ohta, T. Maeno, Large Scale Mult
icast with DNS,Procedings of the International Wor
kshop on Asia-Pacific are advancedresearch informa
tion technology (IWS'98), pp. 144-151, March, 199
8. 複数のエンドノード（またはホスト）に情報を配布（ま
たはマルチキャスト）する技術として今日一般に使用さ
れるものとして次の３つが挙げられる。まず第一のもの
では、情報送信元（ソースホスト）が単に各受信者ホス
トに対し情報の各々別のコピーを送信する。これは信頼
性があり自動的ではあるが、同一の情報を何度も同一通
信リンク上に送信しなければならないため送信元ホスト
にとっては効率的ではない。

【０００４】第二のものでは、通信ネットワーク内のス
イッチまたはルータが自動的にそれらの間で各受信者ホ
ストをあるリーフとしたマルチキャスト分配ツリーを構
築する。これはネットワーク層マルチキャストと呼ば
れ、これを行う技術には例えば今日ＩＰ（Ｉｎｔｅｒｎ
ｅｔ Ｐｒｏｔｏｃｏｌ）インターネットにおいてなさ
れているような良く知られたものがある。ネットワーク
層マルチキャストはホストにとっては自動的で効率的で
はあるが、それ自体信頼性のあるものではない。これは
ネットワークのふくそう等によりルータがパケットを廃
棄することがあるためである。これはまた二つの理由か
らルータにとっても効率的ではない。第一に、各ルータ
はそれが属する全てのマルチキャストツリーの状態を維
持しなければならず、これはグローバルインターネット
において予想されるように非常に多数のマルチキャスト
ツリーがある場合には問題となり得る。第二に、ＩＰマ
ルチキャスト上のフロー制御は困難であり、ネットワー
クのふくそうに陥り易い。

【０００５】ネットワーク層マルチキャストを信頼性の
あるものとする方法もあるが、これらは一般にホストに
とって非効率となってしまう。例えば、一つの方法は受
信者ホストが受信した情報の受領通知をソースホストに
送るというものであるが、これはソースホストにおいて
受領通知の「爆発」を引き起こす。

【０００６】又、ネットワーク層マルチキャスト自体の
技術的側面の弱点というわけではないが、このアプロー
チでは、アプリケーションによる使用に先立ちネットワ
ーク（ルータ）インフラストラクチャがそのマルチキャ
スト機能をオンにする必要があるという実用上の問題が
ある。これは結果として、アプリケーションプログラマ
はネットワーク層マルチキャストが広くオンにされるま
ではこれに依存することを嫌い、一方でネットワーク管
理者はアプリケーションから要求されるまではネットワ
ーク層マルチキャストをオンにするのを嫌うという堂々
めぐりの問題を生じる。

【０００７】第三の一般的な技術として、ホスト自身の
間で構築されたマルチキャスト分配ツリー上に情報を配
布するものがある。これはアプリケーション層マルチキ
ャスト呼ばれる。この場合、各受信者ホストがいくつか
の他の受信者ホストへの情報の送信のタスクを共有す
る。各ホスト間の個別の送信自体はマルチキャストでは
ないが、個別の送信を総合した全体はマルチキャストと
なる。このアプローチは、各ホストではわずかな他のホ
ストに対してのみ情報を複製して分配する必要があるの
で各ホストにとって比較的効率的である。各ホスト間の
個別送信は信頼性がありパケットの廃棄をなくすフロー
制御（例えば、ＴＣＰを用いて）を伴うので、ホストが
破損しない限りこのアプローチは信頼性のある情報の配
送を行い、ネットワークをふくそうさせることもない。
また、これはネットワークに既に非マルチキャスト通信
用に設けられたもの以外に追加の機能を要求しない。

【０００８】しかしながら、アプリケーション層マルチ
キャストは自動的ではなく、ツリーは手動で構築されな
ければならない。即ち、ツリー上の各ホストの隣接ノー
ドをオフラインで選択しホストのコンフィグレーション
ファイルに書き込まれなければならない。このアプロー
チは例えばインターネット電子メール分配や分散チャッ
ト（ＩＲＣ）ネットワークに見られる。

【０００９】更に、もしホストが破損すればマルチキャ
ストツリーが区切られてすべての受信者ホストに情報が
配布できなくなる。これはホストを純粋なツリーではな
くメッシュトポロジー状に構成することにより解決でき
る。これにより、各ホストは情報を受取可能なホストを
いくつか有することになる。しかし、このアプローチは
結果として重複した情報配送となり非効率的である。

【００１０】

【発明が解決しようとする課題】既存のメッシュトポロ
ジーの分脈においてツリーを構築するアルゴリズムは多
数存在する。注目される例としてはＤＶＭＲＰ［ＤＶＭ
ＰＲ］がある。まず、出発点としてこれらのネットワー
クのノードは自身のトポロジカルな隣接ノードがどれか
を知っている。そこから、アルゴリズムを実行して実質
上トポロジー内のリンクを論理的に除去していって残っ
たアクティブなリンクによりツリーを構成するようにす
る。

【００１１】ＤＶＭＰＲのＭＢＯＮＥ［ＭＢＯＮＥ］上
での実装は特に注目に値する。ＭＢＯＮＥはインターネ
ット上を論理的にトンネルしたホストにより構成され
る。つまり、ホスト間のリンクは物理的リンクではな
く、インターネット上で論理的に接続されたものであ
る。しかし、ＭＢＯＮＥリンクは、メッシュネットワー
クとして予め手動で構築されたものである。ＤＶＭＰＲ
アルゴリズムがこのメッシュネットワークの上で実行さ
れてマルチキャスト用のツリーが生成される。

【００１２】ＤＶＭＰＲはグローバルな使用には適さな
い非効率な面を有する。特に、これは”ｆｌｏｏｄ−ａ
ｎｄ−ｐｒｕｎｅ”と呼ばれるツリー発見生成の方法を
用いる。ｆｌｏｏｄの部分ではパケットは全てのネット
ワークロケーションにブロードキャストされ、それらの
ロケーションのシステムがツリーへの加入を希望するか
どうか決定する。ツリーへの加入を希望しないロケーシ
ョンはその旨を示し、ツリーをそれらロケーションから
切り離させる。このＤＶＭＰＲのｆｌｏｏｄ（ツリー発
見）部分は特に非効率的である。

【００１３】Ｃｏｒｅ Ｂａｓｅｄ Ｔｒｅｅ（ＣＢ
Ｔ）はこの問題を解決しようとするプロトコルの一例で
ある。パケットをｆｌｏｏｄする代わりに、ツリーに加
入を希望するシステムがパケットをツリーのコアに向け
て送信し、このプロセス中にツリーの枝を構成する。コ
アがどこかを知るためには、Ｓｏｌａ他がＤＮＳ（Ｄｏ
ｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）ネームを使うこと
を提案している［ＳＯＭ］。ＤＮＳネームはコアを発見
し、その後ツリーに加入するするためのハンドルの一種
としてユーザが使用することができる。しかし、ツリー
の本当の名前は依然としてデータパケット中で用いられ
るのと同様ＩＰマルチキャストアドレス（これらもＤＮ
Ｓを介して割り当て、発見される必要がある）である。
これらのＩＰマルチキャストアドレスは割り当てられな
ければならず（ＩＰにおける難問のひとつ）、またＤＮ
Ｓを介して加入するホストに別々に搬送されなければな
らない。一旦コアが発見されれば、使用されたＤＮＳネ
ームにはもはやいかなる機能も果たさなくなる。

【００１４】今日インターネット上で実行されるアプリ
ケーション（上記のＭＢＯＮＥに加えて）でインターネ
ット上のホスト間で構築されたツリー上に情報を分配す
るものは多数存在し、Ｉｎｔｅｒｎｅｔ Ｒｅｌａｙ
Ｃｈａｔ（ＩＲＣ）［ＩＲＣ］と通常の電子メール［Ｓ
ＭＴＰ］が含まれる。しかし、いづれの場合も手動で構
築されたツリーに依存しており、自動的なツリー生成ア
ルゴリズムは有していない。

【００１５】通常の電子メールは手動で構築されたメー
ルリストの内容に基づいてメールを分配している。これ
らリストの内容は通常ツリーとなるが、しばしばループ
が形成される。これらは各メールメッセージが遭遇した
メールフォアワーダのリストを保持しているメールのヘ
ッダ自身により検出される。メールフォアワーダが受信
したメールメッセージのリスト中に自身を見つけると、
メッセージは廃棄される。通常、このエラーが人間のオ
ペレータに通知され、ループを形成することになった構
成ミスの発見、修正が試みられる。

【００１６】本発明は、上記に鑑みてなされたものであ
り、その目的とするところは、ディジタルデータや情報
をネットワーク中の複数のエンドノードに効率的に、信
頼性をもって、かつ自動的に配布する方法を提供するこ
とにある。

【００１７】

【課題を解決するための手段】本発明は、上記目的を達
成するため、ディジタル通信ネットワーク上の複数エン
ドノードに情報を配布する方法であって、（ａ）ルート
ノードを含んだ情報を受け取るエンドノード間で接続さ
れループの無いマルチキャストツリーを自動的に生成し
維持するステップで、各ノードは各隣接ノードが親ノー
ドか子ノードかを示す表示を持った隣接ノードリストを
有し、親ノードは二つの隣接ノード中でルートノードに
より近いノードとして定義され、子ノードは二つの隣接
ノード中でルートノードからより遠いノードとして定義
され、各新たなノードはその隣接ノードを選択し選択さ
れた隣接ノードを隣接ノードリストにその親ノードとし
て追加することによりマルチキャストツリーに加入する
場合に、各ノードが、（１）親ノードを持たないルート
ノードを除く各ノードは、常にただ一つだけ親ノードを
維持すること、（２）あるノードが親ノードを選択する
際に、ルートパスが該あるノードを含むようなノードが
子側ノードとして識別され、該子側ノードからルートノ
ードへ導く親ノードの系列をルートパスとした時に、該
あるノードは子側ノードをその親ノードとしては決して
選択しないこと、という規則に従うステップと、（ｂ）
ステップ（ａ）で生成され維持されたマルチキャストツ
リー上で、ソースノードがその隣接ノードの全てに情報
を送信し、情報を受けた各ノードがそこから情報を受け
取った一隣接ノードと除くその隣接ノードの全てに情報
を送信するという情報のアプリケーション層マルチキャ
ストを行うステップと、を有することを特徴とするディ
ジタル通信ネットワーク上のエンドノードによるマルチ
キャスト情報配布方法を提供する。

【００１８】

【発明の実施の形態】以下、図１から図２０を参照し
て、本発明に係るディジタル通信ネットワーク上のマル
チキャスト情報配布方法の一実施形態について詳述す
る。

【００１９】本発明は、効率的で信頼性があり、かつ自
動的な、ディジタル通信ネットワーク上のマルチキャス
ト情報配布方法を提供するものであり、詳しくは、アプ
リケーション層ツリーのアプローチを採用することによ
り、アプリケーション層アプローチの効率性と情報配送
信頼性を享受する一方、マルチキャストツリーを自動的
に生成する方法を組み込み、ホストの障害やボトルネッ
クに対抗してこれを維持することによりアプリケーショ
ン層アプローチの弱点を回避するものである。

【００２０】この方法は、ネットワークに対しては、非
マルチキャスト通信用に既に備えられたもの以外には追
加の機能を何等要求しない。特に、この方法は通常の信
頼性のある２局間通信プロトコル（インターネットにお
けるＴＣＰなど）とネットワークのネーミングサービス
（インターネットにおけるＤＮＳなど）のみを利用す
る。

【００２１】この方法は、ノードとリンクからなる論理
的ツリートポロジーを生成、維持するものであり、ここ
でノードとはホストであり、リンクとはツリー上で互い
に隣接しているとされる２つのノード間の基となるネッ
トワーク上の論理的パスである。ツリー上に送信された
情報はこれら論理的リンクを介して伝送される。ツリー
自体は回路（ループ）を持たない接続されたトポロジー
（ツリー上のいかなるノードからいかなるノードへもパ
スが存在する）として定義される。即ち、トポロジーを
通してあるノードから同じリンクを二度渡ることなしに
それ自身に回帰するようなパスは存在しない。

【００２２】１ 背景情報 図１は本発明で用いるツリーの形状の一例を示す。この
実施形態では、ツリーに関連して以下の概念を定義す
る。

【００２３】隣接ノード：ツリー上で隣合ったノード。
図１において隣接ノードはそれらの間に矢印が存在する
ものとして示される。

【００２４】ルート：ツリー上で親ノードを有しない唯
一のノード。

【００２５】親ノード：二つの隣接ノード中で、ルート
により近いものが親ノード。図１において親ノードは矢
印の先端にあるノードとして示される。

【００２６】子ノード：二つの隣接ノード中で、ルート
からより遠いものが子ノード。図１において子ノードは
矢印の後端にあるノードとして示される。

【００２７】ルートパス：あるノードからルートまで導
く、自身を含めたノードのリスト。図１においてノード
ＢからのルートパスはＢ−Ｃ−Ｅ−Ｒである。

【００２８】親側ノード：あるノードＸに対し、Ｘの親
ノードを介して到達可能な、親ノード自身を含むあらゆ
るノードが親側ノード。あるノードは、そのルートパス
がノードＸを含まないことにより、ノードＸの親側ノー
ドであると識別できる。

【００２９】子側ノード：あるノードＸに対し、親側ノ
ードでないあらゆるノードが子側ノード。あるノード
は、そのルートパスがノードＸを含むことにより、ノー
ドＸの子側ノードであると識別できる。

【００３０】新規参入ノード：ツリーに最初に加入する
プロセス中のノード。

【００３１】１．１ ２ノード間のメッセージ メッセージはいかなる２ノード間でも送信され得るもの
で、送信時にこれらが隣接ノードであるか否かを問わな
い。ノード間で渡される全てのメッセージは少なくとも
対象となるツリーとメッセージの送信者ノード、受信者
ノードを識別する。

【００３２】ここで、ネットワークの障害はないものと
し、いかなるノードもあらゆるノードに対してメッセー
ジを信頼性をもって渡すことが可能であるものとする。
更に、もし障害があってあるノードの組においてメッセ
ージの交換が不可能である場合には、これが対象となる
ノードにおいて検出されるものとする。

【００３３】１．２ マルチキャストメッセージ 全てのノードは隣接ノードリストを保持する。リストの
各エントリは隣接ノードが親ノードか子ノードかを示す
ようになっている。ツリーにメッセージをマルチキャス
トするには、メッセージの発信者ノードがその全ての隣
接ノードの各々に一つづつコピーを送信する。

【００３４】マルチキャストメッセージを受信すると、
受信者ノードはそれを受信したノードを除くその各隣接
ノードにコピーを一つづつ送信する。これにより、メッ
セージは最終的に全てのノードにより受信される。

【００３５】もしマルチキャストメッセージの配送中に
ツリーのトポロジーが変更された場合には、メッセージ
が全てのノードに届かない可能性がある。そのような変
更は例えばノードが障害を起こすかネットワーク中の別
の親ノードに接続することを決定した際に起こり得る。

【００３６】１．３ ノードとそのアプリケーション間
のメッセージ ノードは一般に（但し常にではない）ツリーのマルチキ
ャストサービスを利用するアプリケーションに関連して
いる。アプリケーションは既存のツリーに加入するか新
たなツリーを生成することを希望する時にノードを起動
する。するとノードがアプリケーションに成り代わって
ツリーに加入する。

【００３７】アプリケーションはホスト内部の通信メカ
ニズム（ＵＮＩＸにおけるソケットなど）を介してノー
ドにメッセージを送信する。そしてノードがメッセージ
をツリー上にマルチキャストする。ツリーからノードで
受信されたメッセージは同様にアプリケーションに渡さ
れる。

【００３８】２ ツリー形成、維持の分散アルゴリズム ２．１ 概観 ツリーを形成する主たる目的は、それを接続されたもの
に維持することである。もしノードが破損することがな
くツリーを離脱することもなければ、ツリーを構築する
ことは単純なことである。各ノードは単に既存のノード
の隣接ノードとなるだけである。これにより、ツリーは
枝毎に構築されていき、ループのないトポロジーとな
り、区切られることもない。

【００３９】これが基本的なアプローチであって、新規
参入ノード（ツリーに加入する新たなノード）は単にツ
リーに既に存在するノードを見つけてそれに付加する。
新規参入ノードはその最初の隣接ノードをその親ノード
と見なす。その親ノードは逆に新規参入ノードをその子
ノードと見なす。

【００４０】ところが、様々な理由により、新規参入ノ
ードの加入がない時でもトポロジーを変更する必要がし
ばしば生じてくる。一つの理由はツリー中のノードがト
ポロジーを最適化するために親ノードの変更を希望する
ことがあるということで、もう一つの理由はノードが破
損したりその他の理由により突然ツリーを離脱すること
があるということである。前者の場合は計画的または統
制トポロジー変更であり、後者は非計画的または緊急ト
ポロジー変更である。

【００４１】もし子ノードのないノードが新たな親ノー
ドを確率する必要がある時には、単に別のノードを選択
して付加する（加入する）だけでよい。しかし、子ノー
ドのあるノードの場合はそう単純にはすまない。ノード
は自身の子側ノードの一つを親ノードとして選択するこ
とを避けなければならない。もし仮に子ノードを選択し
てしまったとすると、それ自身とその全ての子側ノード
はその親側ノードから切断されてしまうことになる。し
かも、子側の区切り内でループが形成されてしまう。図
２はこの様子を示しており、ノードＣが誤って子側ノー
ドを親ノードとして選択した場合である。

【００４２】ツリー維持の分散アルゴリズムはこれらル
ープや区切りを避けるように設計されたメカニズムを含
んでいる。基本的にこれらはトポロジー変更に際して、
ノードが決して子側のノードをその親ノードとして選択
しないようにする。但し、このメカニズムはノードがそ
の現行の親ノードが有効なときに親ノードの選択をして
いる（例えばより最適な親が見つかったため）のか親ノ
ードを失った後に親ノードの選択をしているのかによっ
て違ってくる。

【００４３】２．１．１ 親ノード有効時の親ノード変
更 親ノードを変更時に接続されたツリーを維持するため
に、各ノードは次の単純なルールの組に従う。

【００４４】（１）各ノードは常にただ一つだけ親ノー
ドを維持する（但しルートノード自身は除く）。

【００４５】（２）ノードがその現行の親ノードを新た
な親ノードに置き換える場合には、親側ノードをその親
ノードとして選択する。

【００４６】例えば、図１を見ると、もし ノードＣが
新たな親ノードに付加するものとすると、その親側ノー
ドと表示されたノード群から一つを選択すべきである。
これらのノードのどれかを選択している限り、ツリーは
ループのない接続されたものとして残る。

【００４７】しかし、複数のノードが同時に親ノードを
変更しようとした場合に困難が生じる。例えば、ノード
ＣがノードＤに付加すると決めたとする（例えばノード
Ｄがその現行の親ノードよりもっとそれに近いため）。
もしこれと同時にノードＤが新たな親ノードＡを選択し
たとする（ノードＡはノードＤの親側にあるため理論的
には可能である）と、結果として得られるトポロジーは
図３に示すものとなり、ツリーは区切られたものとな
る。

【００４８】これを回避するために、アルゴリズムはル
ープ／区切りを生じるいかなる親変更も遮断する。再び
ノードＣが新たな親ノードを得る場合を見ると、ノード
Ｃの親側のどれかのノードがノードＣの子側から親ノー
ドを選択しようとした時にのみ問題が生じることが分か
る。ノードＣの親側ノード群内またはノードＣの子側ノ
ード群内に限られた同時変更はループ／区切りを生じな
い。

【００４９】またノードＣの親側からノードＣの子側へ
のパスのみがノードＣを通ることを考慮に入れると、こ
のような同時変更を回避するには比較的単純な次の方法
がある。

【００５０】（１）全ての変更はツリーを通して通信さ
れることを要求する。

【００５１】（２）親変更中のノードは他のいかなる変
更もその親ノードからその子ノードのいづれかへ通信さ
れることを阻止する。

【００５２】図３の例を再度用いると、ノードＤはそれ
が新たな親ノードに加入する意向をツリーを通してノー
ドＡに通信しなければならず、このパスはルート、ノー
ドＣの親ノード、ノードＣ，ノードＢ、そしてノードＡ
自身を含む。しかし、ノードＣは既に変更中であるか
ら、ノードＣはノードＤの親変更通知がその親ノードか
らノードＢに渡されることを許さず、その代わりに、ノ
ードＤに変更を許可しない旨のメッセージを返送する。
もしノードＣとＤが加入意向を示すメッセージをツリー
に沿って同時に通信しようとした場合には、これらは両
方拒絶され、いづれのノードも各々任意の短時間経って
から再度変更を試みる。

【００５３】２．１．２ 上記の親変更アルゴリズムは、ノードがその以前の親ノ
ードが破損したために新たな親ノードを得ようとする場
合には明らかに機能しない。加入意向を示すメッセージ
が通れる損傷のないパスがない。パス上の（今はダウン
した）親ノードの次のノードから意図する親ノードに加
入意向を示すメッセージを送ることも考えられるが、こ
のノードも破損している可能性がある。一般に、ほとん
どの任意の組の障害が起こり得ると仮定し、任意の損傷
したツリーを修復する一般的解決策を構ずることが最も
容易である。

【００５４】有効な親ノードのない場合にループが形成
されないようにするため、ノードはパケットの送信を意
図する親ノードのルートパスに沿って始める。パケット
は通過したノードのリストを維持し、もしループがあれ
ば、ノードがそれ自身既にリスト中にあることを見つけ
ることによりこれが検出される。

【００５５】２．２ ノードデータ構造 図１８は、ノードがツリー中での正しい位置を維持する
ために用いる内部データ構造を示す。

【００５６】ルートパスはノード自身から始まり、各前
掲のノードの親ノードをリストアップし、ルートノード
で終わるノードのリストからなる。このリストは大きな
ツリーに対しても一般には非常に短い。例えば、６０、
０００個のノードからなるツリーにおいて、各ノードが
３個の個ノードを有する場合、平均的なルートパスは５
つのノードを含み、最も長いルートパスでも１０個のノ
ードを含むにすぎない。

【００５７】ルートパスは別のノードが親側ノードであ
るかどうかを決定するために利用できることからアルゴ
リズムの鍵となる構成要素である。詳しくは、もしノー
ドＡが別のノードＢのルートパスになければ、ノードＡ
はノードＢが親側ノードであることが分かる。

【００５８】各ノードは、そのノードの隣接ノードを全
て含んだ隣接ノードリストを維持いており、隣接ノード
リストの各エントリは、隣接ノードのノード識別子（名
前とアドレス）、隣接ノードのノード状態（親か子）、
そして隣接ノードが親の場合には凍結状態（凍結か解
凍）を含んでいる。一般的にノードは、さらに多くの隣
接ノードを有することも可能ではあるが、せいぜい３つ
か４つ程度の隣接ノードを有している。

【００５９】各ノードはまた親側ノードのリストを維持
している。このリストは、親側ノードがいくら多数存在
しても、５ー１０個の親側ノードを含んでいる。このリ
ストの各エントリは、ノード識別子、ノードのルートパ
ス、エントリ挿入時刻を含んでいる。

【００６０】この記載からも明かなように、このアルゴ
リズムで要求されるデータ量は極めて少なく、ツリーの
サイズとは無関係である。

【００６１】２．３ メッセージタイプ このアルゴリズムではツリーを管理するために以下の６
つのメッセージを使用する。

【００６２】（１）加入メッセージ（質問と回答） （２）加入意向メッセージ（質問と回答） （３）ルートパス追跡メッセージ （４）予期離脱メッセージ（質問と回答） （５）離脱メッセージ （６）メンバー探索メッセージ（質問と回答） これらのメッセージ（回答形式のものを除く）とその内
容を図１９に示す。各メッセージはメッセージの送信者
と受信者の識別子から始まる。３つのメッセージ、即ち
加入意向メッセージ、ルートパス追跡メッセージ、メン
バー探索メッセージは複数のノードを通過する。これら
のメッセージは更に、受信ノードが後でどこに回答を送
信すべきかが分かるようにメッセージの発信元も識別す
る。

【００６３】２．４ アルゴリズムの概観 図２０は、ノードが受信しうる入力と、これら入力の結
果実行されるアルゴリズムの概観を示す。

【００６４】２つの入力が上位層のアプリケーションに
より生成され得る。これらはツリーに対する加入、離脱
の指示である。前者はノードにツリー加入アルゴリズム
を実行させ、このアルゴリズムは更に独立親変更アルゴ
リズムを実行する。このアルゴリズムは加入メッセージ
と加入意向メッセージを使用する。後者の入力はノード
にツリー離脱アルゴリズムを実行させる。このアルゴリ
ズムは離脱メッセージと予期離脱メッセージを使用す
る。

【００６５】１つの入力は下位層の通信プロトコルモジ
ュール（例えばＴＣＰ）により生成され得る。これは隣
接ノードが到達不能になったことの通知である。これは
結果として隣接ノードが到達不能と判明時のアルゴリズ
ムを実行させる。もし到達不能な隣接ノードが親ノード
であれば、このアルゴリズムは更に独立親変更アルゴリ
ズムか従属緊急親変更アルゴリズムを実行する。この後
者のアルゴリズムはルートパス追跡メッセージと加入メ
ッセージを使用する。

【００６６】上記の６つのメッセージ種別（質問形式の
ものがあればそれも）の各々を受信することにより６つ
の入力が生成され得る。この内２つ、離脱メッセージと
予期離脱メッセージは３つの親変更アルゴリズムのいづ
れかを実行させる。

【００６７】親側ノード発見アルゴリズムには入力がな
く、その代わり、これは背景タスクとして定期的に実行
される。このアルゴリズムは結果として親変更の決定と
なって独立親変更アルゴリズムか従属統制親変更アルゴ
リズムの実行を引き起こすことが可能である。

【００６８】３つの親変更アルゴリズムのどれを用いる
かは隣接ノードリストの内容による。もし隣接ノードリ
ストが子ノードを含まない場合には、独立親変更アルゴ
リズムが使用される。そうではなく、もし隣接ノードリ
ストが親ノードを含んでいる場合には、従属統制親変更
アルゴリズムが使用される。そうではなく、もし隣接ノ
ードリストが親ノードを含まない場合には、従属緊急親
変更アルゴリズムが使用される。

【００６９】２．５ 加入質問メッセージ受信のアルゴ
リズム 加入質問メッセージは加入しようとしているノードから
それが加入を希望するノード（その親候補）へ送られ
る。このアルゴリズムのフローチャートを図４に示す。

【００７０】加入質問メッセージを受信すると（Ｓ４
１）、親候補は加入しようとしているノード（メッセー
ジのソース）がそのルートパス上のノードの一つである
かどうかを調べる（Ｓ４２）。もしそうでなければ（Ｓ
４２ＮＯ）、親候補は加入しようとしているノードを許
諾する加入回答メッセージを送り（Ｓ４３）、加入しよ
うとしているノードを隣接ノードリストに加える（Ｓ４
４）。もしそうなら（Ｓ４２ＹＥＳ）、親候補は加入し
ようとしているノードを拒絶する加入回答メッセージを
送る（Ｓ４５）。

【００７１】２．６ 加入意向質問メッセージ受信アル
ゴリズム 加入意向質問メッセージはノードのリストを含み、この
リストは親変更中のノードからその親候補へのパスをそ
の親候補を含んで識別する。このアルゴリズムのフロー
チャートを図５に示す。

【００７２】加入意向質問メッセージを受信すると（Ｓ
５１）、受信ノードはまずそれが送信ノード（送信者）
からの加入意向メッセージの受信を凍結したかどうかを
調べる（Ｓ５２）。もしそうなら（Ｓ５２ＹＥＳ）、受
信ノードは質問を拒絶する加入意向回答メッセージを親
変更中のノードに送る（Ｓ５３）。

【００７３】そうでなければ（Ｓ５２ＮＯ）、受信ノー
ドは加入意向メッセージに含まれたノードのリストを調
べて、受信ノード自身がリスト中にあるかどうかを調べ
る（Ｓ５４）。もしなければ（Ｓ５４ＮＯ）、受信ノー
ドは質問を拒絶する加入意向回答メッセージを親変更中
のノードに送る（Ｓ５３）。

【００７４】もし自身がリスト中にあり（Ｓ５４ＹＥ
Ｓ）、自身より後の他のノードがリスト中にあり（Ｓ５
５ＮＯ）、そのノードが受信ノードの隣接ノードであれ
ば（Ｓ５６ＹＥＳ）、受信ノードはその隣接ノードに加
入意向質問メッセージを送信する（Ｓ５７）。そうでな
ければ（Ｓ５６ＮＯ）、受信ノードは質問を拒絶する加
入意向回答メッセージを親変更中のノードに送る（Ｓ５
３）。

【００７５】一方、もし受信ノードがリストの最後であ
れば（Ｓ５５ＹＥＳ）、受信ノードは質問を許諾する加
入意向回答メッセージを発信元（親変更中のノード）に
送る（Ｓ５８）。

【００７６】２．７ ルートパス追跡メッセージ受信ア
ルゴリズム ルートパス追跡質問メッセージは最初メッセージの発信
元だけを含んでいる、が、それが流されるにつれて、ル
ートパス中にあるノードのリストを構築していく。この
アルゴリズムのフローチャートを図６に示す。

【００７７】ルートパス追跡質問メッセージを受信する
と（Ｓ６１）、受信ノードは自身をリストに付加し（Ｓ
６４）、もし自身が以前にもリストに登場するかどうか
を調べる（Ｓ６５）。もしそうなら（Ｓ６５ＹＥＳ）、
受信ノードはメッセージを発信元に返送する（Ｓ６
６）。

【００７８】もしそうでなければ（Ｓ６５ＮＯ）、受信
ノードはそれがルートであるかどうか調べる（Ｓ６
７）。もしそうなら（Ｓ６７ＹＥＳ）、受信ノードはメ
ッセージを発信元に返送する（Ｓ６６）。もしそれがル
ートでなければ（Ｓ６７ＮＯ）、受信ノードはメッセー
ジをその親ノードに送信する（Ｓ６８）。

【００７９】２．８ 予期離脱質問メッセージ受信アル
ゴリズム このアルゴリズムのフローチャートを図７に示す。

【００８０】予期離脱メッセージを受信すると（Ｓ７
１）、受信ノードはメッセージ送信元がその親ノードで
あるかどうか調べる（Ｓ７２）。もし受信ノードがその
親ノード以外のノードから予期離脱メッセージを受信し
た場合（Ｓ７２ＮＯ）、メッセージは無視される（Ｓ７
３）。そうでなければ（Ｓ７２ＹＥＳ）、受信ノードが
子ノードを有するかどうかを調べ（Ｓ７４）、もし子ノ
ードを有する時には（Ｓ７４ＹＥＳ）、受信ノードは下
記の従属統制親変更アルゴリズムを実行し（Ｓ７５）、
もし子ノードを有しない時には（Ｓ７４ＮＯ）、下記の
独立親変更アルゴリズムを実行する（Ｓ７６）。いづれ
かのアルゴリズムが完了すると、質問の送信者に対して
回答が返送される（Ｓ７７）。

【００８１】２．９ 離脱メッセージ受信アルゴリズム このアルゴリズムのフローチャートを図８に示す。

【００８２】離脱メッセージを受信すると（Ｓ８１）、
受信ノードはメッセージがその子ノードからかどうかを
調べる（Ｓ８２）。もし離脱メッセージが子ノードから
であれば（Ｓ８２ＹＥＳ）、その子ノードを隣接ノード
リストから削除する（Ｓ８３）。

【００８３】そうでなければ（Ｓ８２ＮＯ）、受信ノー
ドはメッセージがその親ノードからかどうかを調べる
（Ｓ８４）。もし離脱メッセージが親ノードからであれ
ば（Ｓ８４ＹＥＳ）、その親ノードを隣接ノードリスト
から削除し（Ｓ８６）、もし離脱メッセージが親ノード
からでなければ（Ｓ８４ＮＯ）、メッセージは無視され
る（Ｓ８５）。

【００８４】次に、受信ノードが子ノードを有するかど
うかを調べる（Ｓ８７）。もし受信ノードが子ノードを
有するなら（Ｓ８７ＹＥＳ）、受信ノードは下記の従属
緊急親変更アルゴリズムを実行する（Ｓ８８）。もし受
信ノードが子ノードを有さないなら（Ｓ８７ＮＯ）、受
信ノードは下記の独立親変更アルゴリズムを実行する
（Ｓ８９）。

【００８５】２．１０ メンバー探索質問メッセージ受
信アルゴリズム メンバー探索質問メッセージはメッセージの発信元を識
別する。このアルゴリズムのフローチャートを図９に示
す。

【００８６】メンバー探索質問メッセージを受信すると
（Ｓ９１）、受信ノードはメッセージがその隣接ノード
からかどうかを調べる（Ｓ９２）。もしメンバー探索質
問メッセージが隣接ノードからでなければ（Ｓ９２Ｎ
Ｏ）、メッセージは無視される（Ｓ９３）。もしこのメ
ッセージが隣接ノードからであれば（Ｓ９２ＹＥＳ）、
受信ノードはそれ自身とその隣接ノードからメッセージ
を受信した隣接ノードを除いたものの内から一つを無作
為に選択する（Ｓ９４）。もし受信ノードが自身を選択
した場合には（Ｓ９５ＹＥＳ）、受信ノードはメッセー
ジの発信元にメンバー探索回答メッセージを送信する
（Ｓ９６）。メンバー探索回答メッセージは回答するノ
ードのルートパスを含んでいる。そうでなければ（Ｓ９
５ＮＯ）、受信ノードは質問メッセージを選択された隣
接ノードに送信する（Ｓ９７）。

【００８７】２．１１ ツリー加入アルゴリズム このアルゴリズムはノードが最初にツリーに加入する際
に実行される。ここであるノードが最初にツリーに加入
する時にはもしあれば少なくとも一つの既に存在するツ
リーメンバー（ツリーに付加したノード）を知っている
ものとする。下記のセクション４においてこの知識がど
のように求められるかに関する簡単なアルゴリズムを説
明する。

【００８８】まず、既に知られているツリーメンバーを
親側ノードリストに追加する。次いで、ノードはセクシ
ョン２．１５に記載した独立親変更アルゴリズムを実行
する。

【００８９】２．１２ ツリー離脱アルゴリズム このアルゴリズムはツリーのメンバーであるノードがツ
リーを離脱することを希望する際に実行される。このア
ルゴリズムのフローチャートを図１０に示す。

【００９０】ツリーを離脱することを決定すると（Ｓ１
０１）、ノードが子ノードを有しているかどうかを調べ
る（Ｓ１０２）。もしノードが子ノードを有していなけ
れば（Ｓ１０２ＮＯ）、ノードは単に離脱メッセージを
その親ノードに送り（Ｓ１０３）、親ノードを隣接ノー
ドリストから削除する（Ｓ１０４）。この時点で実効的
にノードはツリーから離脱したことになる。

【００９１】もしノードが子ノードを有する場合には
（Ｓ１０２ＹＥＳ）、ノードはそれらの各々に予期離脱
メッセージを送り（Ｓ１０５）、数分で切れるように設
定された回答タイマーをセットする（Ｓ１０６）。そし
て、ノードは離脱メッセージが全ての子ノードから来る
かタイマーが切れるまで待つ（Ｓ１０７）。

【００９２】ノードが子ノードから離脱メッセージを受
信する毎に（Ｓ１０８）、ノードはその子ノードを隣接
ノードリストから削除する（Ｓ１０９）。他にも子ノー
ドが残っている限り動作はそれからステップＳ１０７に
戻る（Ｓ１０１０ＹＥＳ）。残っている子ノードが無く
なった場合には（Ｓ１０１０ＮＯ），ノードは回答タイ
マーをキャンセルし（Ｓ１０１１）、離脱メッセージを
親ノードに送り（Ｓ１０３）、親ノードを隣接ノードリ
ストから削除する（Ｓ１０４）。この時点で実効的にノ
ードはツリーから離脱したことになる。

【００９３】もし全ての子ノードが離脱する前にタイマ
ーが切れた場合には（Ｓ１０１２）、ノードは離脱メッ
セージを残っている子ノードに送り（Ｓ１０１３）、そ
れらを全て隣接ノードリストから削除する（Ｓ１０１
４）。そして、ノードは離脱メッセージを親ノードにも
送り（Ｓ１０３）、親ノードを隣接ノードリストから削
除する（Ｓ１０４）。この時点で実効的にノードはツリ
ーから離脱したことになる。

【００９４】２．１２ ツリー離脱アルゴリズム このアルゴリズムはツリーのメンバーであるノードがツ
リーを離脱することを希望する際に実行される。このア
ルゴリズムのフローチャートを図１０に示す。

【００９５】ツリーを離脱することを決定すると（Ｓ１
０１）、ノードが子ノードを有しているかどうかを調べ
る（Ｓ１０２）。もしノードが子ノードを有していなけ
れば（Ｓ１０２ＮＯ）、ノードは単に離脱メッセージを
その親ノードに送り（Ｓ１０３）、親ノードを隣接ノー
ドリストから削除する（Ｓ１０４）。この時点で実効的
にノードはツリーから離脱したことになる。

【００９６】もしノードが子ノードを有する場合には
（Ｓ１０２ＹＥＳ）、ノードはそれらの各々に予期離脱
メッセージを送り（Ｓ１０５）、数分で切れるように設
定された回答タイマーをセットする（Ｓ１０６）。そし
て、ノードは離脱メッセージが全ての子ノードから来る
かタイマーが切れるまで待つ（Ｓ１０７）。

【００９７】ノードが子ノードから離脱メッセージを受
信する毎に（Ｓ１０８）、ノードはその子ノードを隣接
ノードリストから削除する（Ｓ１０９）。他にも子ノー
ドが残っている限り動作はそれからステップＳ１０７に
戻る（Ｓ１０１０ＹＥＳ）。残っている子ノードが無く
なった場合には（Ｓ１０１０ＮＯ），ノードは回答タイ
マーをキャンセルし（Ｓ１０１１）、離脱メッセージを
親ノードに送り（Ｓ１０３）、親ノードを隣接ノードリ
ストから削除する（Ｓ１０４）。この時点で実効的にノ
ードはツリーから離脱したことになる。

【００９８】もし全ての子ノードが離脱する前にタイマ
ーが切れた場合には（Ｓ１０１２）、ノードは離脱メッ
セージを残っている子ノードに送り（Ｓ１０１３）、そ
れらを全て隣接ノードリストから削除する（Ｓ１０１
４）。そして、ノードは離脱メッセージを親ノードにも
送り（Ｓ１０３）、親ノードを隣接ノードリストから削
除する（Ｓ１０４）。この時点で実効的にノードはツリ
ーから離脱したことになる。

【００９９】２．１３ 隣接ノードが到達不能と判明時
のアルゴリズム 隣接ノードは、隣接ノードから来ることが予想されてい
たメッセージが受信されなかった時に到達不能であると
判定され得る。例えば、２つの隣接ノード間に確立され
たＴＣＰプロトコルは定期的に隣接ノードにｋｅｅｐ−
ａｌｉｖｅパケットを送信するが、もしそのような送信
を数回行っても応答が受信されない場合には、隣接ノー
ドは到達不能と見なされる。

【０１００】これが起こると、到達不能であることをあ
たかもセクション２．９に記載し図８に示したように隣
接ノードから離脱メッセージを受信したかと同等に扱
う。つまり、もし子ノードが到達不能と判明した場合に
は、ステップＳ８３が実行され、もし親ノードが到達不
能と判明した場合には、ステップＳ８６以降が実行され
る。

【０１０１】２．１４ 親側ノード発見アルゴリズム ノードにとって、いくつか（５ー１０個）の親側ノード
のリストを最新の状態に維持することは、このリストか
らのエントリが親変更時に使用されることから重要であ
る。このアルゴリズムのフローチャートを図１１に示
す。

【０１０２】親側ノードリストは各エントリが挿入され
た時刻を示すタイムスタンプを含んでいる。ノードは定
期的にメンバー探索質問メッセージをその親ノードに送
信する（Ｓ１１１）。ある短時間後、この質問は一般に
対応する回答が受信されるという結果になる。

【０１０３】回答が受信されると（Ｓ１１２）、もし回
答の送信者が親側ノードリストに既にあるエントリとマ
ッチすれば（Ｓ１１３ＹＥＳ）、このエントリのタイム
スタンプをレフレッシュする（現時刻にセットする）
（Ｓ１１４）。そうでなければ（Ｓ１１３ＮＯ）、もし
リストが満杯であれば（Ｓ１１５ＹＥＳ）、リスト中の
最も古いエントリを削除する（Ｓ１１６）。いづれにせ
よ、回答の送信者は、送信者のルートパスと共にリスト
に追加される（Ｓ１１７）。

【０１０４】２．１５ 独立親変更アルゴリズム このアルゴリズムは子ノードを持たないノードが新たな
親ノードの獲得を希望する際に実行される。このアルゴ
リズムのフローチャートを図１２に示す。

【０１０５】独立親変更アルゴリズムが起動されると
（Ｓ１２１）、ノードはまずその親側ノードリストから
エントリを選択し（Ｓ１２２）、選択したノードに加入
質問メッセージを送信する（Ｓ１２３）。

【０１０６】もし回答が受信されなければ（Ｓ１２４Ｎ
Ｏ）、またもし回答が拒絶であれば（Ｓ１２５ＮＯ）、
ノードはこのエントリを親側ノードリストから削除し
（Ｓ１２６）、別のエントリをステップＳ１２２にて選
択する。

【０１０７】もし親側ノードリストが空になり、ノード
が依然として親ノードを有していれば、ノードはより多
くのノードが学習されるまで親側ノード発見アルゴリズ
ムをより頻繁に実行してもよい。

【０１０８】もし加入を許諾する回答が受信されれば
（Ｓ１２５ＹＥＳ）、回答したノードを隣接ノードリス
トに親ノードとして加える（Ｓ１２７）。

【０１０９】２．１６ 従属統制親変更アルゴリズム このアルゴリズムは、子ノードを持つノードがその現行
の親ノードが依然有効な時に新たなノードを親ノード
（親候補）として選択した際に実行される。ここで、親
候補のルートノードは知られているものとする（例えば
メンバー探索メッセージ回答から）。このアルゴリズム
のフローチャートを図１３に示す。

【０１１０】選択済みの親候補を用いた従属統制親変更
アルゴリズムが起動されると（Ｓ１３１）、ノードは現
行の親ノードから来る加入意向質問メッセージを凍結す
る（Ｓ１３２）。つまり、親変更が完了するまでは現行
の親ノードからの今後のいかなる加入意向質問メッセー
ジも拒絶される。

【０１１１】次ぎに、親候補へのパスを算出する（Ｓ１
３３）。このパスはノードのルートパスと親候補のルー
トパスを連結したものから冗長なホップを除いたものと
なる。例えば、ノードのルートパスが、このノードを
Ｎ、このノードの親ノードをＡ、ルートをＲとしてＮ−
Ａ−Ｂ−Ｄ−Ｒであり、親候補のルートパスが、親候補
をＰとしてＰ−Ｃ−Ｂ−Ｄ−Ｒであるとする。すると、
パスはＮ−Ａ−Ｂ−Ｃ−Ｐとなる。ノードＤとルートＲ
は冗長なので連結から除かれている。

【０１１２】次ぎに、このパスを有する加入意向メッセ
ージが現行の親ノードに送信される（Ｓ１３４）。同時
に、およそ１／２分の長さの加入意向タイマーをスター
トする。

【０１１３】もし否定的な回答が加入意向メッセージの
いづれかの受信者から受信された場合には（Ｓ１３５Ｎ
Ｏ）、ノードは一時的に処理をアボートしなければなら
ない。又、もし回答が受信される前に加入意向タイマー
が切れた場合には、ノードはやはり処理をアボートす
る。このため、ノードはまずその親ノードからの加入意
向メッセージを解凍する（即ち、その親ノードからの加
入意向メッセージを再び許可する）（Ｓ１３６）。そし
て、ノードはやり直しタイマーを１分程度の範囲の任意
の時間に設定し（Ｓ１３７）、タイマーが切れた後（Ｓ
１３８）、再び親候補を獲得することを試みてもよい。

【０１１４】もし肯定的な回答が親候補から受信された
場合には（Ｓ１３５ＹＥＳ）、次ぎに加入質問メッセー
ジを親候補に送信する（Ｓ１３９）。もし加入回答メッ
セージが肯定的であれば（Ｓ１３１０ＹＥＳ）、親候補
を隣接ノードリストに親ノードとして加える（Ｓ１３１
２）。そうでなければ（Ｓ１３１０ＮＯ）、回答を無視
する（Ｓ１３１１）。

【０１１５】次ぎに、その親ノードからの加入意向メッ
セージを解凍し（Ｓ１３１３）、前の親ノードを隣接ノ
ードリストから削除し（Ｓ１３１４）、離脱メッセージ
を前の親ノードに送信する（Ｓ１３１５）。ルートパス
はこのノード自身が付けられた新たな親ノードのものに
更新され（Ｓ１３１６）、それから子ノードにこの更新
されたルートパスが通知される（Ｓ１３１７）。

【０１１６】２．１７ 従属緊急親変更アルゴリズム このアルゴリズムは、子ノードを持つノードがその前の
親ノードが何等かの理由で無効になったために新たなノ
ードを親ノード（親候補）として選択する際に実行され
る。ここで、親候補のルートノードは知られているもの
とする（例えばメンバー探索メッセージ回答から）。こ
のアルゴリズムのフローチャートを図１４に示す。

【０１１７】選択済みの親候補を用いた従属緊急親変更
アルゴリズムが起動されると（Ｓ１４１）、ノードはま
ずルートパス追跡メッセージを親候補に送信し（空のル
ートパスリストと共に）（Ｓ１４２）、これが親候補か
らのルートパス追跡を起動する。もし回答が受信され
（Ｓ１４３ＹＥＳ）、回答がルートパスにループがある
ことを示していれば（Ｓ１４４ＹＥＳ）、ノードは短時
間（３０秒程度）ループがそれ自身で解消されるのを待
ち（Ｓ１４５）、ルートパス追跡を再度試みる（Ｓ１４
２）。

【０１１８】もし回答がループ無しを示す（Ｓ１４４Ｎ
Ｏ）が、ノードが回答にリストされている場合には（Ｓ
１４６ＹＥＳ）、ノードは自身が親候補のルートパスに
あることと親候補が無効であることを知る。この場合、
親候補は親側ノードリストから削除され（Ｓ１４７）、
もし他の親候補が親側ノードリストにあれば（Ｓ１４８
ＮＯ）、別の親候補を選択して（Ｓ１４９）、ルートパ
ス追跡を再度試みる（Ｓ１４２）。もし別の親候補がな
ければ（Ｓ１４８ＮＯ）、回答は無視される（Ｓ１４１
０）。

【０１１９】もしノードが回答にリストされていなけれ
ば（Ｓ１４６ＮＯ），ノードは加入質問メッセージを親
候補に送る（Ｓ１４１１）。もし加入回答メッセージが
肯定的であれば（Ｓ１４１２ＹＥＳ）、親候補を隣接ノ
ードリストに親ノードとして加える（Ｓ１４１３）。ル
ートパスはこのノード自身が付けられた新たな親ノード
のものに更新され（Ｓ１４１４）、それから子ノードに
この更新されたルートパスが通知される（Ｓ１４１
５）。

【０１２０】一方、もし加入回答メッセージが否定的で
あれば（Ｓ１４１２ＮＯ）、または、もし回答が受信さ
れなければ（Ｓ１４３ＮＯ）、親候補は親側ノードリス
トから削除され（Ｓ１４７）、もし他の親候補が親側ノ
ードリストにあれば（Ｓ１４８ＮＯ）、別の親候補を選
択して（Ｓ１４９）、ルートパス追跡を再度試みる（Ｓ
１４２）。もし別の親候補がなければ（Ｓ１４８Ｎ
Ｏ）、回答は無視される（Ｓ１４１０）。

【０１２１】３ 共有メディアブロードキャストを用い
た分散アルゴリズム ３．１ 概観 以上の記載は、ノード間の全ての通信が２局間通信、即
ち単独の送信者から単独の受信者へのもの、であること
を想定している。あるノードが複数の隣接ノードを有す
る場合には、マルチキャストパケットはこのノードから
複数回、各隣接ノード毎に一回ずつ、送信される。複数
のマルチキャストパケットは全てこのノードを含んでい
るホストの同一の物理インタフェースを通過する。隣接
ノードの数が少数に維持されていると仮定すれば、単独
有線上のこれら複数の送信は一般に問題とはならない。

【０１２２】しかし、ＬＡＮ等の共有メディアの場合に
は、隣接ノードが少数であることだけでは有線自体がト
ラヒックにより圧倒されてしまわないことを保証はでき
ない。例えば、２０個のノードが同一の有線上にあり、
そのうち一つが有線外のノードの子ノードであり、その
他のノードは全て有線上の他のノードの子ノードである
場合を考えると、もし仮にいづれのノードにとっても最
大子ノード数が僅か２個であったとしても、ツリー上に
送信されるたった一つのパケットにさえ同一有線上に同
一パケットを２０回個別に送信すること（その内たった
一つだけが実際にはルータにより有線外にフォアワード
される）が必要となる。

【０１２３】３．２ クラスタ構造とアルゴリズム この問題に対する解決策は、共有メディアの生来のブロ
ードキャストメカニズムを使用することである。ここ
で、同一共有メディア上のノードがそれら自身でクラス
タと呼ばれるものを形成する（図１５）。ノードの一つ
は動的に親ノードに選定され、クラスタヘッドまたは単
にヘッドと呼ばれる。このノードのみが唯一クラスタ外
の親ノードを見つけ、残りのノードはデフォルトでクラ
スタヘッドの子ノードとなって集合的にクラスタチャイ
ルドと呼ばれ、個別的にはクラスタフィートまたは単に
フィート（単数ならフット）と呼ばれる。

【０１２４】この場合クラスタヘッドを選定する動的な
アルゴリズムを用いる。このようなブロードキャストメ
ディア上の選定アルゴリズムは今日一般に用いられてい
るもので、簡単な例を以下で説明する。クラスタヘッド
はツリー形成、維持アルゴリズム（上記セクション２）
に参加する。即ち、クラスタヘッドは親ノードを獲得
し、クラスタ外の子ノードを獲得してもよい。

【０１２５】クラスタフィートはツリー形成、維持アル
ゴリズムそのものには参加しない。代わりにこれらは単
にクラスタ自体を親隣接ノードとして扱い、それ以外に
はクラスタ外のいかなる活動にも参加しない。全てのク
ラスタノードはクラスタ自体を隣接ノードとして扱い、
共有メディアブロードキャスト自体からフレームを送受
信する。この構成においては、いかなるマルチキャスト
パケットも有線を一度はクラスタのために、一度はクラ
スタヘッドの親ノードのために、そして一度はクラスタ
ヘッドが有し得る追加の子ノードがあればその各々のた
めに渡る。

【０１２６】３．３ クラスタヘッド選定の一例 共有メディアに付加されたノード中からクラスタヘッド
を選定するための典型的なアプローチは以下の通りであ
る。各ノードは定期的にその存在をアナウンスするメッ
セージをクラスタにブロードキャストする。このアナウ
ンスメントはそのノードが自分自身クラスタヘッドであ
ると見なしているかどうかを示す。

【０１２７】各ノードは他のノードのブロードキャスト
を聞いており、もしある時間間隔の後に自身をクラスタ
ヘッドであると宣伝するノードがなければ、アルファニ
ューメリカルに最も高い名前を有するノードが自身をク
ラスタヘッドとして選択して自身をクラスタにアナウン
スする。

【０１２８】もしある時間間隔の後に複数のノードがそ
れら自身クラスタヘッドであると宣伝した場合には、そ
のようなノードの内でアルファニューメリカルに最も高
い名前を有するノード以外は全てクラスタヘッドである
ことを止める。

【０１２９】４ 初期ツリー発見の分散アルゴリズム ４．１ 概観 以上のセクションにおいては、ツリーに初めて加入する
ノードは既にいくつかのツリーメンバーを知っているこ
とを前提としている。このセクションでは、どのように
してこれらのツリーメンバーが知られるようになるかに
ついて説明する。

【０１３０】ここで、以下の概念を導入する。

【０１３１】ホストネーム：ホストのネットワーク内で
の名前。例えば、インターネットでは、ホストネームは
ＤＮＳネーム（ｗｗｗ．ｙａｈｏｏ．ｃｏｍ等）であ
る。

【０１３２】ディレクトリサービス：全てのホストから
利用可能なサービスで、ホストネームをそのホストネー
ムのホストに到達できるネットワークアドレスに変換刷
るもの。例えば、インターネットでは、ＤＮＳサービス
がディレクトリサービスである。

【０１３３】ツリーネーム：ツリーの名前。これは有効
なホストネームでなければならない。

【０１３４】ツリーサブネーム：同一ツリーネームを有
するツリー中で各ツリーを識別する文字列。

【０１３５】ツリーマネージャ：ツリー中のノードで、
ツリーネームと同一のホストネームを有するホスト上に
いるもの。

【０１３６】基本的には、ツリーを生成するアプリケー
ションソフトウェアが自身のいるホストのホストネーム
をツリーの名前として用いる。これとツリーサブネーム
を組み合わせることにより、いかに多数のツリーネーム
であっても他のいかなるホストとも調整することなくい
かなるアプリケーションにおいても容易に生成すること
が可能となる。

【０１３７】ツリー生成するアプリケーションを起動し
たノードは、そのツリーのツリーマネージャとしても機
能する。ツリーマネージャとしては、ツリー中のいくつ
かの無作為に選択されたノード（ツリーのサイズに拘ら
ず大体１０ー１５個）に関する知識を維持することに責
任を負う。

【０１３８】ここで、ツリーに加入することを希望する
新たなノード（新規参入ノード）は予めツリーネームと
ツリーサブネームを持っているものとする。これは、例
えばｗｅｂページ上のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓ
ｏｕｒｃｅ Ｌｏｃａｔｏｒ）から等、ノード外部のメ
カニズムを介して学習される。新たなノードは、ネット
ワークディレクトリサービスを用いてツリーマネージャ
に接触する。それに対し、ツリーマネージャは新たなノ
ードにツリーの他のメンバーについて知らせる。これを
基に、新たなノードはツリーに加入することができる。

【０１３９】４．２ メッセージリストとコンポーネン
トアルゴリズム この機能のためにはツリーマネージャメッセージという
新たなメッセージが一つ必要になる。ツリーマネージャ
質問メッセージを受けてツリーマネージャが実行するア
ルゴリズムに加えて、以下のアルゴリズムが要求され
る。

【０１４０】（１）ツリーマネージャがツリーメンバー
のリストを維持するためのアルゴリズム （２）新規参入ノードがいくつかのツリーメンバーにつ
いて学習するためのアルゴリズム ４．３ ツリーマネージャメッセージ受信アルゴリズム このアルゴリズムのフローチャートを図１６に示す。

【０１４１】ツリーマネージャ質問メッセージを受信す
ると（Ｓ１６１）、ツリーマネージャはそのメンバーノ
ードリスト中の一つまたはそれ以上のエントリを含んだ
ツリーマネージャ回答メッセージを質問しているノード
に送信する（Ｓ１６２）。

【０１４２】４．４ ツリーマネージャのメンバーノー
ドリスト維持アルゴリズム ツリーマネージャのメンバーノードリスト維持アルゴリ
ズムは、以下の例外を除き、親側ノードリストに対する
親側ノード発見アルゴリズム（上記セクション２．１
４）と同一である。

【０１４３】（１）ツリーマネージャは最初自身をメン
バーノードリストに挿入する。

【０１４４】（２）メンバーノードリストにはより多数
のノードが保持される（５ー１０個ではなく１０ー１５
個）。

【０１４５】（３）定期的に送信されるメンバー探索質
問メッセージは、親ノードにだけではなく、無作為に選
択されたいかなる隣接ノードにも送信される。これによ
り、親側だけではなく、ツリーの様々な部分からのメン
バーが見つけられる。

【０１４６】４．５ 新規参入ノードのツリーメンバー
学習アルゴリズム このアルゴリズムは新規参入ノードと呼ばれるノードに
よって、それが初めに始動された後でそれが最初にツリ
ーに加入する前に実行される。このアルゴリズムのフロ
ーチャートを図１７に示す。

【０１４７】初めの新規参入ノードの始動の後（Ｓ１７
１）、新規参入ノードはまず、ツリーネームにより名付
けられたホストにおいて、ツリーマネージャ質問メッセ
ージをツリーマネージャに送る（Ｓ１７２）。もしある
時間の後に回答を受け取らなければ（Ｓ１７３ＮＯ）、
新規参入ノードはやり直しタイマーをセットすることで
短期間待機し（Ｓ１７５）、メッセージを再送してもよ
い。もし数回の試行の後に回答を受け取らなければ、ツ
リーに加入しようとする試みが失敗したと見なせる。

【０１４８】そうでなければ、ノードはツリーマネージ
ャ回答メッセージ中にリストアップされたメンバーの一
つを始点としてツリー加入アルゴリズム（上記セクショ
ン２．１１）を利用する（Ｓ１７４）。

【０１４９】５ 従来技術との比較 ここで、上述した本発明のマルチキャスト情報配布方法
を先に述べた従来技術のいくつかと比較する。

【０１５０】ＤＶＭＲＰ［ＤＶＭＲＰ］については、周
知の（メッシュ）トポロジーから始めてリンクを取り除
いていくことから本発明とは本質的に異なる。本発明で
は、無から始めて１ノードづつツリーを構築していき、
最初はツリーマネージャの発見メカニズムを介して互い
を見つけていく。

【０１５１】ＭＢＯＮＥ［ＭＢＯＮＥ］はインターネッ
ト上を論理的にトンネルしたホストにより構成されると
いう点では本発明に似ている。しかし、ＭＢＯＮＥのリ
ンクは前もって手動でメッシュネットワークとして構成
されたものである。その後ＤＶＭＲＰアルゴリズムがこ
のメッシュネットワークの上で実行され、マルチキャス
トに用いるツリーを生成する。前述したように、これは
本質的に本発明とは異なるものである。

【０１５２】Ｉｎｔｅｒｎｅｔ Ｒｅｌａｙ Ｃｈａｔ
（ＩＲＣ）［ＩＲＣ］と通常の電子メール［ＳＭＴＰ］
は手動で構成されたツリーに依存するものであり、本発
明のような自動ツリー生成アルゴリズムは有していな
い。

【０１５３】通常の電子メールは通過したノード（電子
メールの場合はメールフォアワーダ）をメッセージに付
加していくことに基づいたループ検出機能を有している
という点では本発明に似ている。しかし、電子メールの
場合にはツリー全体で送信される全てのメッセージにル
ープ検出機能が存在しなければならない。これに対し本
発明では、ノード間の親子関係のためにループ検出機能
はツリーのルートに向けて送信されたメッセージ一つだ
けしか要求しない。

【０１５４】Ｓｏｌａ他［ＳＯＭ］はコアを発見しその
後ツリーに加入するためにユーザが使う一種のハンドル
としてＤＮＳネームを用いるという点では本発明に似て
いる。しかし、類似はここまでで、見つけられたツリー
の本当の名前は依然としてデータパケット中で用いられ
るのと同様ＩＰマルチキャストアドレス（これらもＤＮ
Ｓを介して割り当て、発見される必要がある）である。
これらＩＰマルチキャストアドレスは割り当てられなけ
ればならず（ＩＰにおける難問のひとつ）またＤＮＳを
介して加入するホストに別々に搬送されなければならな
い。一旦コアが発見されれば、使用されたＤＮＳネーム
にはもはやいかなる機能も果たさなくなる。これに対
し、本発明ではＤＮＳネームはハンドル（ユーザが始め
に用いるもの）であると同時にツリーの名前（適当なフ
レームでノード間を搬送されるもの）でもあり、ツリー
発見と操作のために追加の名前やアドレスを割り当てる
必要はない。

【０１５５】以上説明したように、本発明によれば、デ
ィジタルデータや情報をネットワーク中の複数のエンド
ノードに効率的に、信頼性をもって、かつ自動的に配布
する方法を提供することが可能となる。

【０１５６】尚、上述した以外にも、本発明の本旨を逸
脱することなく上記の実施形態に様々な変更変形を加え
ることが可能であり、それら変更変形は全て本発明の範
囲に含まれるものである。

【０１５７】

【発明の効果】以上説明したように、本発明によれば、
ディジタルデータや情報をネットワーク中の複数のエン
ドノードに効率的に、信頼性をもって、かつ自動的に配
布する方法を提供することが可能となる。

【図面の簡単な説明】

【図１】本発明の一実施形態において使用する基本的な
ツリーの一例を示す図。

【図２】ループと区切りを含んだツリーの一例を示す
図。

【図３】同時親変更の一例を示す図。

【図４】本発明の一実施形態において用いる加入メッセ
ージの受信アルゴリズムのフローチャート。

【図５】本発明の一実施形態において用いる加入意向メ
ッセージの受信アルゴリズムのフローチャート。

【図６】本発明の一実施形態において用いるルートパス
追跡メッセージの受信アルゴリズムのフローチャート。

【図７】本発明の一実施形態において用いる予期離脱メ
ッセージの受信アルゴリズムのフローチャート。

【図８】本発明の一実施形態において用いる離脱メッセ
ージの受信アルゴリズムのフローチャート。

【図９】本発明の一実施形態において用いるメンバー探
索メッセージの受信アルゴリズムのフローチャート。

【図１０】本発明の一実施形態によるツリー離脱アルゴ
リズムのフローチャート。

【図１１】本発明の一実施形態による親側ノード発見ア
ルゴリズムのフローチャート。

【図１２】本発明の一実施形態による独立親変更アルゴ
リズムのフローチャート。

【図１３】本発明の一実施形態による従属統制親変更ア
ルゴリズムのフローチャート。

【図１４】本発明の一実施形態による従属緊急親変更ア
ルゴリズムのフローチャート。

【図１５】本発明の一実施形態によるクラスタノード間
の生来の共有メディアブロードキャストを用いたクラス
タを示す図。

【図１６】本発明の一実施形態において用いるツリーマ
ネージャメッセージの受信アルゴリズムのフローチャー
ト。

【図１７】本発明の一実施形態によるいくつかのツリー
メンバーについて学習するためのアルゴリズムのフロー
チャート。

【図１８】本発明の一実施形態によるノードがツリー中
で正しい位置を維持するために用いるデータ構造を示す
図。

【図１９】本発明の一実施形態において用いる６種類の
メッセージ種別のメッセージの内容を示す図。

【図２０】本発明の一実施形態によるノードへの入力と
ノードにより実行されるアルゴリズムの概観を示す図。

【符号の説明】

Ａ Ｂの子ノード Ｂ Ａの親ノード Ｃ ノード Ｄ ノード Ｅ 通過ノード Ｒ ルートノード

Claims (11)

【特許請求の範囲】
1. 【請求項１】 ディジタル通信ネットワーク上の複数エ
   ンドノードに情報を配布する方法であって、（ａ）ルー
   トノードを含んだ情報を受け取るエンドノード間で接続
   されループの無いマルチキャストツリーを自動的に生成
   し維持するステップで、各ノードは各隣接ノードが親ノ
   ードか子ノードかを示す表示を持った隣接ノードリスト
   を有し、親ノードは二つの隣接ノード中でルートノード
   により近いノードとして定義され、子ノードは二つの隣
   接ノード中でルートノードからより遠いノードとして定
   義され、各新たなノードはその隣接ノードを選択し選択
   された隣接ノードを隣接ノードリストにその親ノードと
   して追加することによりマルチキャストツリーに加入す
   る場合に、各ノードが、 （１）親ノードを持たないルートノードを除く各ノード
   は、常にただ一つだけ親ノードを維持すること、 （２）あるノードが親ノードを選択する際に、ルートパ
   スが該あるノードを含むようなノードが子側ノードとし
   て識別され、該子側ノードからルートノードへ導く親ノ
   ードの系列をルートパスとした時に、該あるノードは子
   側ノードをその親ノードとしては決して選択しないこ
   と、という規則に従うステップと、（ｂ）ステップ
   （ａ）で生成され維持されたマルチキャストツリー上
   で、ソースノードがその隣接ノードの全てに情報を送信
   し、情報を受けた各ノードがそこから情報を受け取った
   一隣接ノードと除くその隣接ノードの全てに情報を送信
   するという情報のアプリケーション層マルチキャストを
   行うステップと、を有することを特徴とするディジタル
   通信ネットワーク上のエンドノードによるマルチキャス
   ト情報配布方法。
2. 【請求項２】 請求項１記載の方法で、ステップ（ａ）
   において、もしノードが子ノードを持たない時には該ノ
   ードはいかなるノードをもその親ノードとして選択して
   よいことを特徴とする方法。
3. 【請求項３】 請求項１記載の方法で、ステップ（ａ）
   において、前記あるノードが少なくとも一つの子ノード
   を有し現行の親ノードがまだ有効である場合に、親変更
   は、 （１）全ての変更はマルチキャストツリーを通して通信
   されること、 （２）前記あるノードは他のいかなる変更も現行の親ノ
   ードから該あるノードの子ノードのいづれかに通信され
   ることを阻止すること、という要求を満たして行われる
   ことを特徴とする方法。
4. 【請求項４】 請求項３記載の方法で、ステップ（ａ）
   において、親変更は、マルチキャストツリー中の前記あ
   るノードから新たな親ノードへのパスを識別するノード
   リストを含んだ加入意向メッセージを、該あるノードか
   ら該パスに沿って送信することにより行われることを特
   徴とする方法。
5. 【請求項５】 請求項１記載の方法で、ステップ（ａ）
   において、前記あるノードが少なくとも一つの子ノード
   を有し現行の親ノードが無効である場合に、親変更は、
   新たな親ノードのルートパスが新たな親ノードからルー
   トノードへ導くパスと定義される時に、通過したノード
   のリストを保持するルートパス追跡メッセージを新たな
   親ノードのルートパスに沿って送信することにより行わ
   れることを特徴とする方法。
6. 【請求項６】 請求項１記載の方法で、ステップ（ａ）
   において、各ノードは更に親変更時にそこから新たな親
   ノードが選択される親側ノードリストを有し、各ノード
   は定期的にメンバー探索メッセージをその親ノードに送
   信して親側ノードリストを最新の状態に維持することを
   特徴とする方法。
7. 【請求項７】 請求項１記載の方法で、ステップ（ａ）
   において、各親ノードはマルチキャストツリーから離脱
   する前にその子ノードの各々に予期離脱メッセージを送
   信することを特徴とする方法。
8. 【請求項８】 請求項１記載の方法で、ステップ（ａ）
   において、同一共有メディア上の複数のノードは、該複
   数のノード間の通信に該同一共有メディアのブロードキ
   ャスト機能を用いたクラスタを形成し、該クラスタはマ
   ルチキャストツリー生成、維持のプロセスにおいて該ク
   ラスタ外部の他のノードから単一のノードとして取り扱
   われることを特徴とする方法。
9. 【請求項９】 請求項８記載の方法で、ステップ（ａ）
   において、クラスタは、マルチキャスト生成、維持のプ
   ロセスに参加することにより該クラスタをマルチキャス
   トツリーに付加し、該クラスタに含まれる他の全てのノ
   ードの親ノードとなり、前記複数のノードから動的に選
   定されたクラスタヘッドノードを有することを特徴とす
   る方法。
10. 【請求項１０】 請求項１記載の方法で、ステップ
    （ａ）において、マルチキャストツリー中のノードであ
    ってマルチキャストツリー中のいくつかの無作為に選択
    されたノードについての知識を維持する責任を負ったノ
    ードを各マルチキャストツリーのツリーマネージャとす
    るとき、各マルチキャストツリーは、そのツリーマネー
    ジャがいるホストのホストネームにより名付けられるこ
    とを特徴とする方法。
11. 【請求項１１】 請求項１０記載の方法で、ステップ
    （ａ）において、ホストネームはホストのＤＮＳ（ドメ
    インネームシステム）ネームにより与えられることを特
    徴とする方法。