JP2012516087A - ネットワークにおけるアドレス割り当て - Google Patents

Abstract

ネットワークにおけるアドレス割当の方法には、ノード間の交渉から、第１ノードが、クライアントに対するネットワークアドレスの分配と管理に責任のあるサーバ・ロールを担うべきかをどうか決定することを備える。もしこの決定がなされると、第１ノードにはネットワークアドレスのプールが提供される。本発明は、例えば、ネットワーク要求条件またはトラヒック負荷に従って、ネットワークのサーバ間におけるアドレス・プールの動的再割当の方法を提供する。

Description

本発明はネットワークにおけるアドレス割り当てに関し、具体的には、クライアント・ロールを持つノードに対してネットワークアドレスの分配と管理に責任があるサーバ・ロールを持つネットワーク・ノードに対する、ネットワークアドレスのプールの動的割り当てに関する。

自律コンピュータ・システムを生成するという着想は、コンピュータ・ネットワークにおける自動設定の概念に重く依存する。動的ネットワークでユーザの干渉無しでの通信の確立は、次世代のコンピュータ・ネットワークに最も重要なトピックスの一つである。動的ネットワークにおける自動設定に関する最大の挑戦の一つはアドレス指定であり−ネットワークにおけるアドレスの自動的割り当てと管理は、移動、ポリシー制御および間欠的接続のような挑戦の存在により更に複雑になる、自律通信環境の決定的重要な部分である。

将来のネットワーク形成では、ユーザが手動でデバイス構成を変更する必要性無しに、ノードはネットワークに接続し、ネットワークから切断するであろう、と予想される。自動的ブートストラップのためのしっかりとしたメカニズムを通じて、ノードが参加し、通信の開始を希望するネットワークの既存のノードと連絡をとることにより、ノードがそれ自身を構成してもよい。自己設定を実現するために幾つかの方法が提案された。これらの例には、動的アドレス指定、アドレス管理および、アドホック・ネットワークの動的構成のためのメカニズムを含む。

動的環境においてノードのためのアドレスを定める方法は知られているが、これらはしばしば、ＤＨＣＰ（動的ホスト構成プロトコル）またはもう一つの種類のメカニズムが利用可能である、固定的で構造化したネットワークの存在と助力に依存する。その他の解決策は、ノードがそのハードウエア・アドレス（例えば、ＭＡＣ−媒体アクセス制御−アドレスのような物理アドレス）を参照し、それ自身のネットワークアドレスを計算するためにこの情報を使用する。それにもかかわらず、アドレスが自己起因である場合、すでにその他に割り当てたアドレスをノードが使用しないようなメカニズムが必要である。同様に、例えば、特許文献１、特許文献２、または特許文献３で説明しているアドレス衝突を避けるため、その物理アドレスと事前に定めたネットワーク関連情報とから情報を合成することにより、それ自身のネットワークアドレスを生成してもよい、ということをその他の提案は暗示している。

その他の解決策は、サーバが送った広告メッセージから情報をノードが取ってきて、それを、それ自身のインタフェース・タイプについての情報、またはその他の事前に定めた情報と合成し、それ自身の正当なネットワークアドレスを生成するというメカニズムを検討したが、これについては特許文献４を参照されたい。しかしながら、これは、再び、固定サーバの提供を要求する。

更なる戦略が、特定のアドレスを使用して、ホーム・ドメインに接続したノードに対して提案された。他の地域に移動し、他のドメインと交信する場合、ノードは、それが、そのホーム・ドメインから離れたままの時間の間に使用する一時的アドレスを受信または計算する。これについては、例えば、特許文献５または非特許文献１を参照されたい。

試行錯誤（“発見的方法”）は、多くのドメイン問題で使用される共通の方法である。アドレス指定の文脈では、ノードは単純にそれ自身のアドレスを生成する可能性がある。次に、このノードは、このアドレスがすでにネットワークのもう一つのノードで使用されているかどうかを検証する。もし使用されていないなら、ノードは、生成されたアドレスを自分自身に帰属させる。

また、ある量の利用可能なアドレスを運ぶ一つ以上のサーバを提供することも提案された。これらのサーバは、ノードがそれらの正当なアドレスをそこから取ってくる、アドレス・プールの管理に責任がある。これについては、例えば特許文献６を参照されたい。

米国特許出願公開第２００３／００８１５７８号 米国特許出願公開第２００４／０２４０４７４号 米国特許第６，７２８，２３２号 米国特許出願公開第２００７／０１６００５１号 米国特許第５，７０８，６５５号 米国特許第６，９９３，５８３号

Charles Perkins, "IP Mobility Support for IPv4", RFC 3344, ２００２年８月

本発明の第１の側面は、ネットワークにおいてアドレス割り当ての方法を提供する。本方法には、ノード間の交渉から、第１ノードが、クライアントにネットワークアドレスの分配と管理に責任のある、サーバ・ロールを担わなければならないかどうかを決定することを備える。もしこの決定が行われたなら、第１ノードにネットワークアドレスのプールを提供する。

当然注意すべきであるが、用語“第１ノード”は、本説明において特別なノードの一貫した識別を可能とするために使用される。用語“第１ノード”は、ネットワークの開始後ネットワークとの関連を要請するために、本ノードが時間順に第１番目のノードである、ということを要求しない。以下で説明する幾つかの実施形態では、第１ノードはネットワークとすでに関連しているが、他の実施形態では、第１ノードは、ネットワークとの関連を要請しているノードである。

サーバ・ノードは、第１ノードにネットワークアドレスのプールを提供してもよい。（ネットワークアドレスのプールを提供するサーバ・ノードは、本ノードがサーバ・ロールを担うべきであると決定してしまってもよいが、本発明はこれを要求しない。サーバ・ロールを担うノードのみが、ネットワークアドレスのプールを割り当てられることができる。）このようにして、本発明は、ネットワーク要求条件により、ネットワークのサーバ間でアドレス・プールの動的再割り当てを提供する。アドレス・プールの再割り当ては、ネットワークのノード間の交渉の結果として起こり、したがって、ネットワークはサーバのアドレス・プールの集中型割り当てのために構成要素を要求しないという意味で、自動的に起こるということができる。（本方法は、ネットワークアドレスのプールを最初にネットワークに割り当てる、ということを要求しない。任意の適当な方法でこれを行ってもよく：−例として、ネットワーク管理者がネットワークの一つのノードをサーバとして最初に構成し、ネットワークアドレスのプールを提供してもよい。次に、このすでに存在するサーバがネットワークに入る次のノードに正当なアドレスを提示する−本発明は、ネットワークに割り当てられたネットワークアドレスが、ネットワークのノード間で引き続いて割り当てられる方法に関する。）

以下の時点の一つで本決定を実行してもよい：
ネットワークの開始時点で；
第１ノードがネットワークに関連を要請した後；
ネットワークのサーバ・ノードが過負荷になった後；または、
ネットワークのサーバ・ノードがネットワークから退く場合。

本発明は、これらの場合の一つについての決定を実行することに限定されなく、その他の場合で実行されてもよい。例えば、もしネットワーク・ノードがブリッジ・ノードとして動作していると見なされる（即ち、それが、クライアント・ノードからサーバ・ノードにトラヒックを中継している）なら、ネットワーク・ノードはサーバになるよう提示を行なわれる可能性がある。

第１ノードがネットワークとの関連を要請した後、本決定を実行する場合、もし本決定が、第１ノードがサーバ・ロールを担わないということであれば、第１ノードは、代わりに、ネットワークのクライアント・ロールを提示されてもよい。

その他の実施形態では、第１ノードは、ネットワークの既存のクライアント・ノードである。

もし第１ノードがサーバ・ロールをになうなら、本方法には、第１ノードにネットワークアドレスの更なるプールを引き続いて提供することを備えてもよい。もし第１ノードが、そのクライアントに割り当てるため、その最初のアドレス・プールにおけるよりもっと多くのアドレスを要求するなら、もっと多くのアドレスを獲得するため、ネットワークのその他のサーバと交渉することができる。更なるアドレス・プールは、最初のアドレス・プールを提供したものと同じサーバからもたらされてもよく、またはネットワークのもう一つのサーバからもたらされてもよい。

第１ノードがもはやサーバ・ロールを実行しないという表示を受信した後、本サーバ・ノードは、第１ノードがサーバ・ロール（これには、第１ノードが後続のサーバに同様に割り当てたアドレスを含んでもよい）を担った後第１ノードに割り当てられたネットワークアドレスのプールに対する責任を引き続いて取り戻してもよい。例えば、本表示は、例えば第１ノードがネットワークから退くことか第１ノードの機能停止によって生じる可能性のある、第１ノードとの通信の機能停止であってもよい。

サーバ・ノードは、アドレス・プールの責任を再び担う前に第１ノードがもはやサーバ・ロールを実行しないという表示を受信した後、事前に決定した期間待ってもよい。通信リンクの機能停止のため、第１ノードとの通信が一時的に失われたなら、これにより、通信リンクが再確立され、従って第１ノードがそのクライアントに新しいアドレスを割り当てる必要性を避ける場合、第１ノードはその最初のアドレス・プールを保持することが可能となる。

第１ノードが一つ以上の更なるサーバに割り当てた第１アドレス・プールのアドレスに対する責任を取り戻すことを、サーバ・ノードは避けてもよい。第１ノードが任意の更なるサーバに割り当てたアドレスは、更なるサーバと一緒に留まってもよく、それによってネットワークアドレスの新しいプールをこれらの更なるサーバに提供する必要性を避ける。

本決定が、第１ノードがサーバ・ロールを担わなければ成らない、ということであれば、第１ノードは、ネットワークの少なくとも一つのノードをバックアップ・サーバとして、引き続いて選んでもよい。第１ノードはそのクライアント・ノードの少なくとも一つをバックアップ・サーバとして選んでもよい。もし第１ノードが機能停止することがあったなら、バックアップ・サーバがその役割を担う可能性がある。

本発明の第２の側面は、ネットワークにノードを関連させる方法を提供する。本方法には、ノードからネットワークに関連性リクエストを送ることを備える。ノードで、ネットワークのノードからのレスポンスを受信した後、本ノードは、受信したレスポンスがネットワークのクライアント・ノードからか、ネットワークのサーバ・ノードからかを決定する。次に、受信したレスポンスに基づき、ノードはクライアントまたはサーバとしてネットワークに関連してもよい。

もしノードがネットワークのサーバ・ノードからレスポンスを受信したなら、ノードとサーバ・ノードとの間の交渉から決定したように、クライアントまたはサーバのどちらかとして、本ノードはネットワークに関連してもよい。

もしノードがネットワークのサーバ・ノードから全くレスポンスを受信しないが、ネットワークのクライアント・ノードからレスポンスを受信したなら、本ノードは、ｎホップ・クライアント（ｎ＞１）としてネットワークに関連してもよい。“ｎホップ・クライアント”とは、サーバに直接に（即ち、一つのネットワーク・リンクによって）関連しないが、少なくとも一つの中間のクライアント（“ブリッジ・ノード”として知られている）を経由してサーバに関連するクライアントである。

もし本ノードがサーバとしてネットワークに関連するなら、本方法には、クライアントに分配するためのネットワークアドレスのプールをノードで受信するノードを更に備えてもよい。

本発明の第３の側面は、以下のように適応するネットワーク・ノードを提供する：ノード間の交渉から、第１ノードが、クライアントへのネットワークアドレスの分配と管理に責任のあるサーバ・ロールを担うべきであるかどうか、を決定すること；もしそうなら、第１ノードにネットワークアドレスのプールを提供するよう構成すること。

本ネットワーク・ノードは直接的にサーバであってもよく、または、もし本決定は第１ノードがサーバ・ロールを担うべきであるということであれば、それ自身、第１ノードにネットワークアドレスのプールを提供するだろうネットワークに遠隔的に関連してもよい。

本発明の第４の側面はネットワーク・ノードを提供するが、本ノードは以下のように適応する：ネットワークに関連性リクエストを送ること；ネットワークのノードからレスポンスを受信すること；受信したレスポンスがネットワークのクライアント・ノードからかネットワークのサーバ・ノードからかを決定すること；受信したレスポンスに基づき、クライアントまたはサーバとしてネットワークに関連すること。

本発明の第５の側面は、プログラムで実行された場合、ネットワーク・ノードに第１および第２の側面で定めた方法を実行させる命令を含む、コンピュータ読み取り可能媒体を提供する。

本発明は、ネットワーク内で“アドレスの自己組織化”（“ＳｏｏＡ”）という方法を提供する。本ＳｏｏＡは、ネットワークにおけるアドレスの分配と管理を達成するメカニズムであり、ネットワークアドレスのプールが動的方法でネットワークのサーバに割り当て可能となる−即ち、特定のサーバの割り当てられるネットワークアドレスのプールは固定されないが、例えば、ネットワーク要求条件および／またはネットワークにおけるトラヒック条件に基づき、経時的に変化してもよい。上記で説明した従来の方法と対比して、ＳｏｏＡは完全に自律的であり−一方、幾つかの従来の解決策は、アドレス分配を管理するためにＤＨＣＰまたはその他のメカニズムを使用するが、本ＳｏｏＡは、その他のサポート・メカニズムを全く必要としない、自己構成環境を定める。動的割り当てアドレス・プールの着想を使用して、本提案の戦略は、ロバストで、分散的、拡大縮小可能で、自動管理可能なアドレス割り当てメカニズムを実装する。

動的ネットワークにおいて動的アドレス指定を提供する既存の解決策は、一般的には、ＤＨＣＰのようなアドレス指定に責任を持つ集中型メカニズムを提示する、構造化ネットワークに適用する。動的ネットワークの解決策として説明した場合でも、従来の解決策は一般的に適用可能であることに失敗している、即ち、動的ネットワークを定める全ての状況には適用可能でない。構造化ネットワークとの関連が全く不可能であるシナリオでは、なかんずくＤＨＣＰは、アドレス分配を管理するために利用可能でない可能性がある。特に、動的ネットワークの開始は、自己アドレス指定をサポートしなければならない場合は主に、重大な局面である。

ネットワークでＤＨＣＰ無しを仮定し、通常、アドレス・プールの概念に依存する、多くの従来解決策がある。しかしながら、単にネットワークアドレスをプールに分割し、サーバ間でそれらを分配することは、非効率のままである。高度に動的で非構造化ネットワークにおいては特に、このアドレス分配に対するロバスト管理が要求される。分散型アドレスの管理には、追加のプロトコルが要求される。

本発明は、自己構成ネットワークにおいてアドレスを割り当てる（または、ブートストラップ・アドレス指定する）メカニズムを定める。アドレス割り当てはネットワークの残りの機能にとって重要である。動的ネットワークでアドレス指定するための現在の解決策は、ＤＨＣＰの使用に、または、正当なアドレスを提供し、それらを管理するためのもう一つの固定的メカニズムに、一般的には依存する。本発明は、事前に定めた、および／または固定的外部エンティティのサポート無しに、アドレスを割り当てる。更に、アドレス指定の現在の解決策は、通常、分配を管理するためにプロトコルの大きなスタックを要求する。本発明のメカニズムは、効率的なアドレス指定を保証するため、全ての必要な機能を統合した一つのプロトコルのみを使用する。

全体として、自己ブートストラップが第１のステップであり、自己構成ネットワークのための基本的機能である。自己構成ネットワークは、ネットワークに関連するノード間で関連性を提供するために、効率的な自己アドレス割り当てに直接依存している。

本発明のＳｏｏＡ方法は、動的ネットワークにおけるネットワークアドレスの自己分配と自己管理を提供する。

本発明のＳｏｏＡ方法は、例えば、サーバ・ロールを担うノード（“サーバ”）およびクライアント・ロールを担うノード（“クライアント”）から成る階層構造において、ネットワーク内の幾つかのまたは全てのノードを組織するメカニズムである。本サーバは、アドレス割り当てプロセスの面倒を見るという目的を持ち、アドレスの分配と管理の両方に責任を持っている。各サーバには、プールのネットワークアドレスの少なくとも一つが提供される。サーバ間の交信を通して、利用可能なアドレスがネットワーク内にばらまかれ、幾つかのその他のサーバに関連したいと希望するノードおよび通信チャネルを確立しようとするノードに帰属する。ネットワークのリソース、例えば認証、暗号化等の正しいアクセスおよび利用を保証するため、本発明のＳｏｏＡ方法で一つ以上のセキュリティ・メカニズムを使用するのが望ましい。例えば図１または図２１で示す階層で、アドレス割り当てに責任のあるサーバ自身を構成してもよい。（当然注意すべきであるが、ネットワークには、このサーバ階層の一部でない更なるサーバがあってもよい。）

ノード（ネットワークの新しいノードまたは既存のクライアント・ノードであってもよい）がネットワークでサーバ・ロールを担っている場合、サーバとしてすでに機能しているもう一つのノードは新しいノードに利用可能なアドレス・プールを提供する。これのより、アドレスをサーバ間に分配可能となり、その結果、それらをクライアントおよびその他のサーバに割り当ててもよい。この分配は、図１に示すツリー形式構造に従うアドレス割り当て階層を生成する。図１の構造では、サーバ１０．２．０．０およびサーバ１０．３．０．０は、階層において各々サーバ１０．０．０．０の下にあり、サーバ１０．３．２．０、サーバ１０．３．３．０およびサーバ１０．３．４．０は各々サーバ１０．３．０．０の下にある。この構造は、例えば、ＤＮＳ構造と同じように機能するが、アドレス変換へ名前を制御する代わりに、本解決策は、代表アドレスに関連する情報およびどのノードがこの情報を管理しているかをストアする。この構造を使用して、ノードは、非常に効率的で拡張可能な方法でその他のサーバに相談し、回答することが可能であり、これは、本情報ベースを動的であるが構造化した方法で分配するからである。

クライアント・ロールを持つノード（即ち“クライアント”）はアドレス指定に対して全く制御を持たない。しかしながら、その他のクライアントとサーバ間の関連を可能にする場合には、それらは基本的な役割を演じる。ノードがネットワークと関連したい場合。それはサーバ・ルックアップ手順を開始する。サーバにすでに関連しているクライアントは、新しいノードと本サーバとの間の通信をブリッジすることができる。このようにして、もしノードが、直接関連しているサーバに十分近接していないなら、そのようなサーバに到達するため既存のクライアントを使用できる。（以下に更に詳細に説明するように、サーバ・ノードはまた、ブリッジの役割を引き受けてもよい。）

もし、クライアントがブリッジとしてしばしば使用された、とサーバが見ると、例えば、リクエストの構成可能なスレッショウルド値またはその現在の作業負荷に依存して、それは、それ以下のレベルにあるサーバになるようなクライアントを選んでもよい。

過負荷サーバで、まだ非割り当てのアドレスを持つものは、また、そのクライアントの一つ以上（または全てでさえ）を新しいサーバに移すことにより、その作業負荷を分割するよう選んでもよい。本サーバは、それにメッセージを送ることにより新しいサーバになるよう、既存のクライアントを勧誘し、もし可能なら、本クライアントは、その“親サーバ”から作業負荷の一部を集める新しいサーバになる。

アドレス割り当てのよりよい制御を保つため、各サーバは、そのクライアントに割り当てた全てのアドレスとその他のサーバに分配した全てのプールとの履歴を保つ。この追跡で、本発明は、アドレスの損失を避けている。アドレス管理のために追加のプロトコルを全く必要としないので、このことは重要である。

“第１レベル”のサーバの生成（例えば、図１のサーバ１０．０．０．０の生成）は、自動化環境では努力目標を提示する。本発明は、この最初の生成を取り扱わないが、これは任意の適当な方法で実行可能であってもよい。本発明の説明は、最初のノードが、それらによって管理するネットワークアドレスのプールを示す幾つかの情報を受信したと推測するであろう。例えば、この割り当てを特定するために静的構成または方策を使用してもよい。これらの最初のサーバを、より少ない活力ともっと大きな計算能力を提示するＤＮＳルート・サーバと比較できる。

サーバ階層を示す概略図である。 クライアントとサーバとを持つネットワークの概略図である。 本発明の実施形態による方法の概略フローチャートである。 本発明の実施形態による方法の概略フローチャートである。 本発明の実施形態による方法の概略フローチャートである。 本発明の実施形態による方法の概略フローチャートである。 本発明の実施形態による方法の概略フローチャートである。 本発明の実施形態による方法の概略フローチャートである。 本発明の実施形態による方法の概略フローチャートである。 本発明の実施形態による方法の概略フローチャートである。 本発明の実施形態による方法の概略フローチャートである。 本発明の実施形態による方法の概略フローチャートである。 本発明の実施形態による方法の概略フローチャートである。 本発明の実施形態による方法の概略フローチャートである。 本発明の実施形態による方法の概略フローチャートである。 本発明の実施形態による方法の概略フローチャートである。 サーバとそのバックアップ・サーバとの間のメッセージ交換の概略図である。 サーバとそのバックアップ・サーバとの間のメッセージ交換の概略図である。 サーバとそのバックアップ・サーバとの間のメッセージ交換の概略図である。 本発明の実施形態による方法の概略フローチャートである。 サーバ階層の概略図である。 サーバ階層の概略図である。 サーバ階層内のアドレス・プールを示す図である。 本発明の実施形態による方法の概略フローチャートである。 本発明のネットワーク・ノードの概略図である。

例を使用し、以下の添付の図面を参照して、本発明の実施形態について更に説明する。

図２は、ネットワークにわたって広がるサーバ（黒い円）がアドレス分配を処理する基本的なシナリオを示す。サーバはそれらのクライアントの各々に正当なアドレスを提供する。クライアント（白い円）は、必ずしもサーバに直接関連を持つ必要はない（即ち、１ホップの関連を通して）。新しいクライアントがもう一つのクライアントを通してサーバにリンクを確立する場合、この新しいクライアントは、少なくとも、サーバから２ホップの離れている、といわれる。図２では、クライアントＡはサーバＢから２ホップの離れており、その他の全てのクライアントはそれらの各々のサーバに直接（即ち、１ホップの関連で）関連している。

図２では、サーバとそれらの各々のクライアントとの間のリンクを２方向矢印で表わす。サーバ−クライアント階層を表わさない本リンクは、点線で描いている。第１の場合では、これらのリンクにおいて、ノードおよびサーバがアドレス割り当てと利用可能性に気付くように保つため、すべての管理情報を送信するだろうということを表示するノード間で、“アドレス関係”を確立する。他方、点線は、ノード間でデータを交換するためにのみ使用するだろうリンクを表わしている。（注意すべきであるが、一般的に、図２に示すサーバ間でアドレス関係があるだろう（図２に示すサーバにそれらのアドレス・プールを提供する一つ以上のより高次のレベルを恐らく含む）；このアドレス関係は図２から削除している。）

本発明は、自己構成ネットワークにおいてアドレスを分配し管理する自律メカニズムから構成される。三つの要素は、ノードがネットワークで新しいノード、サーバおよびクライアントを担うことができる状態を表わす。ネットワークの開始時またはその後、新しいノードとしてネットワークと最初に関連するノードは、ネットワークにおいてその他のノードの不在を検証した後（不在を検証する手順は、本発明の範囲の外にあり、従って、任意の適当な手順を使用してもよい）、サーバ状態に対する交渉を開始するだろう。もう一つの新しいノードとして引き続いてネットワークと関連するノードは、それがクライアントまたはサーバとしてネットワークと関連するかどうかを決定するための交渉の対象であろう。本発明の実施形態について一般的なアドホック・ネットワーク（移動ネットワークであってもよいし、そうでなくてもよい）を参照して説明するが、その理由は、これらのネットワークはより高い活力を提示するが、本発明はそれらに制限されないためである。

サーバ構成要素
サーバはアドレス分配と管理に責任があるため、アドレス指定に関連するそれらの機能は、クライアントのものよりもっと複雑である。適当な処理と記憶能力を持つノードがサーバの自然な候補である。処理能力、ノードで利用可能な記憶空間、およびネットワークを退くノードのリスクの組合せを反映する属性として、ノード安定性を見ることができる。（望ましいことであるが、もしノードがネットワークを退くと仮定すれば、サーバのクライアントは新しいアドレスを入手しなければならないであろうから、サーバとして動作するノードは、ネットワークを退くのに低いリスクをもつ。）ノードがネットワークに入る場合、そのような属性は既存のサーバに知られるように作られてもよい。そのような情報は高度に動的であるが、レベルの観点からは、例えば、次のようにそれを定めてもよい：非常に安定、安定、不安定。

ノードがサーバの役割を担う可能性がある方法は多数ある。新しいサーバを生成する必要性を見ることは、例えば、次の結果として生じる：
（ａ）既存のサーバがその作業の幾つかを取り外そうと試みる；
（ｂ）ノードが多くのその他のノードを代表してブリッジとして動作する；
（ｃ）サーバが終了またはネットワークを退く前／時；
（ｄ）一つ以上のサブネットワークの生成。

ネットワークにおける既存のサーバが、新しいサーバを生成する必要性を把握すると、本サーバはネットワークと既存の関連を持つノードに、例えば、その安定性情報レベルを試験して、適合性に対してノードを試験した後サーバになることを尋ねてもよい。候補ノードが辞退するようなリクエストを許してもよい、ということに注意されたい。これが、そのようなリクエストが確認を要求する理由である。

サーバが実行する第１の動作は、ブロードキャスト・メッセージを通じた自己通知である。次に、サーバは、そのクライアントからまたは新しいノードからの任意のメッセージに耳を傾け、それを待つという初期状態に入る。

ネットワークアドレスを受信する前に、例えば、それらのＭＡＣアドレスおよび通信チャネル・タイプまたは技術を通して、ノードを識別してもよい。選択的には、それらはまた、一時的識別、例えばそれが動作開始する場合、各ノードが計算する自己割り当てアドレスを使用してもよい。これにより、ネットワークがインターネットに接続されていなくても、全てのノードが、ルーティング機能を使用可能となり、次にネットワークの全ての構成要素と全ての時に通信可能となる。それがネットワークに参加する前に、一時的識別またはアドレスを使用のためにノードに提供する任意の適当なメカニズムを使用してもよいが、本発明は、このための任意の特定の方法に制限されない。上述のＭＡＣアドレスに加えて、その他の形式のノード・アイデンティティ（例えば暗号特性に基づいた）を代わりに使用できる可能性がある。

図３は、サーバがノードからリクエストを受信した場合の動作シーケンスを示す。

新しいノードからリクエストを受信する（ステップ１）と、新しいノードがすでに拒否されたかどうかを決定するため、そのキャッシュ・テーブルをチェックする。もしこれがその場合なら、サーバは返答せず、それはそのキャッシュ・テーブル情報を更新し、初期状態に戻る。そうでなければ、幾つかの事前に定めた方策に基づき、本サーバは、新しいノードを受け入れるか入れないかを決定する（ステップ２）。そのような決定は、本サーバで局所的にまたは遠隔ノードの助力を通して行われる。本キャッシュ・テーブルは、ノードの“ブラックリスト”に類似である可能性のあるものにおいて、最近の拒否およびそうする理由についての情報を保持するために使用される。このキャッシュ・テーブルを参考にして、サーバは時間と努力とを節約してもよい。

もしサーバが新しいノードのリクエストを拒否するよう決定する（しかし、ノードは以前には拒否されなかった）なら、それは拒否メッセージをノードに送り（ステップ３）、ノードの識別子または一時的／自己割り当ての識別およびリクエストを拒否する理由で、キャッシュ・テーブルを更新する。（Ｄ）ＤｏＳアタックに伴う問題を回避するため、本リクエストを認証してもよく、サーバ間でブラックリストを交換してもよい。

もしサーバが新しいノードのリクエストを受け入れるよう決定するなら、それは、提示されたアドレス構成を含む提示メッセージを送り（ステップ４ａ、４ｂ）、サーバが作成した提示の受領を確認するため、ノードを待つ。この時点で、サーバは提示アドレスの状態を“予約済み”と印す。クライアントから確認を受信すると、サーバは最終確認を送り（ステップ５）、新しいノードと関連を確立し、構成プロセスが正しく行われたと推測する。その後、アドレスの状態を“割り当て済み”に変更し、その初期状態に戻る。もしノードが提示メッセージに応答しないなら、所定の期間後に提示メッセージを再送信する。事前に設定した再送信の最大値に達し、新しいノードから全く確認を受信しないなら、サーバは予約アドレスを開放し（ステップ６）、初期状態に戻る。

本発明の一つの実施形態によれば、サーバが、ネットワークと関連することを希望するノードからメッセージを受信すると、それは、サーバとしてまたはクライアントとして関連するためにノードを招いてもよい。この実施形態では、サーバが、新しいノードはサーバになるべきであると決定すると、それは、新しいノードがサーバ構成（“サーバ提示”）を確立できる情報とアドレス・プールとを含むメッセージを送る（ステップ４ａ）。次に、サーバはレスポンスを待つ。もし新しいサーバが“サーバ提示”を拒否するなら、サーバは、新しいノードがクライアントになることのみを許容する情報を含むもう一つのメッセージを送り（ステップ４ｂ）、上記で説明したのと同じプロセスを実行する（即ち、確認を待ち、後に最終確認メッセージを送る）。もし新しいノードが新しいクライアントであることを受け入れるなら、サーバは最終確認を送り、初期状態に戻る。既存のノードが新しいサーバになるよう、サーバが招く場合、同様のプロセスを使用してもよいが、ノードによる拒否の場合、サーバは全く動作をしない。

また、クライアントとして動作する既存のネットワークはそのサーバにメッセージを送る。図４はこの場合においてサーバで実行するステップを示す。ステップ１で、サーバはそのクライアントの一つから取消メッセージを受信する。これにより、サーバはそのアドレス・テーブルを更新でき（ステップ２）、このクライアントが使用していたアドレスを開放し（ステップ３）、初期状態に戻る（図４参照）。

また、サーバは、前に作成した通知への返答を受信できる。図５は、この場合にサーバで実行するステップを示す。ここでは、サーバは前に作成した通知への返答を受信し（ステップ１）、そのアドレス・テーブルを更新し（ステップ２）、初期状態に戻る。これは、サーバがクライアントの状態をチェックする方法を提供し、更新した状態情報をサーバに提供する間隔で実行されてもよい。

追加して、サーバはクライアント誤り報告を受信できる。図６は、この場合にサーバで実行するステップを示す。サーバがクライアント誤り報告を受信すると（ステップ１）、サーバは、アドレスを再構成すべきかどうか決定する（ステップ２）。もしサーバが、アドレスを変更しなければならないと決定するなら、サーバは現在割り当てられたアドレスを開放し、提示メッセージをクライアントに送る、新しい構成プロセスを開始する（ステップ３）。もし本提示が拒否されたなら、新しい提示に割り当てたアドレスは開放される（ステップ４）。もし本提示が受け入れられたなら、サーバは上記で説明した最終確認メッセージを送る（ステップ５）。

また可能なことであるが、サーバはもう一つのサーバからリクエストを受信する。例えば、サーバＸがそのプールにもっと多くのアドレスを加える必要がある場合、それは、サーバＹ（通常はサーバＸの親サーバであろう）にそのようなアドレスを求めるメッセージを送る。図７にこれを示す。ステップ１で、サーバＹは、そのプールに追加するアドレスを求めるメッセージをサーバＸから受信する。サーバＹは、それが利用可能なアドレスを持っているかどうかをチェックする（ステップ２）。もしサーバＹが利用可能なアドレスを持っているなら、サーバＹはサーバＸに提示メッセージを送り（ステップ３）、返答を待つ。サーバＸから確認返答を受信すると、サーバＹは最終確認を送り、初期状態に戻る。そうでなければ、サーバＹは割り当てたアドレスを開放し（図示せず）、初期状態に戻る。

もしサーバＹが利用可能なアドレスを持っていないなら、本リクエストを単純に拒否する代わりに、サーバＹは同様に、その親サーバから更なるアドレスを要求してもよい。サーバＹ以上の関連のサーバの一つがアドレスの新しいプールを提示するまで、このプロセスを繰り返してもよく（即ち本リクエストをより高次のサーバに渡しても良い）、次にこのプールは、それがサーバＹに達するまで転送される。アドレス・プールの受信後、サーバＹはサーバＸに提示を送る。

もしサーバＹが利用可能なアドレスを持っていないで、より高次のサーバからアドレスを獲得できないなら、サーバＹはサーバＸからの本リクエストを単に無視してもよく、初期状態に戻るか、サーバＸに拒否レスポンスを送ってもよい。もしサーバＸがサーバＹから返答を受信しないなら、それは、サーバＹが提示すべきアドレス・プールを持っていないと単に推測する。

サーバがサーバ誤り報告を送る場合、類似の手順を適用してもよい。

サーバは周期的にネットワークに自分自身を通知する必要がある。そうする時間の場合、サーバは、その通知と更新をそれらがまた受信することを保証するため、何かｎホップのクライアント（ｎ＞１）があるかどうかをチェックする。クライアントがブリッジ・ノードのシーケンスを通して記録する場合、サーバはそのようなクライアントについて知るようになる。

図８は、サーバがネットワークに自分自身を通知する手順を示す。もしｎホップのクライアントが全くいないなら、サーバはその中間ノードの通知メッセージをブロードキャストする（ステップ１）。そうでない場合は、少なくとも一つのｎホップクのライアントがいるなら、ステップ１には、この通知が全てのクライアントに到達していることを確かめるため、サーバがマルチキャスト・メッセージを送ること備える。通知メッセージを送った後、サーバはクライアントの返答をチェックし（ステップ２）、どれがまだアクティブ（返答を失敗したクライアントはもはやアクティブではないと推測して）かを検出し（ステップ３）、従って、アクティブでないと判定したクライアントを検出して、そのアドレス・テーブルを再構築する（ステップ４）。特定の数の連続した通知に返答しなかったそれらのクライアントは、死んだクライアント（アクティブでないノード）と考え、これらのクライアントに割り当てられたアドレスを開放する（ステップ５）。次に、サーバは初期状態に戻る。（勿論、もし全てのクライアントが通知メッセージに返答するなら、サーバがそのアドレス・テーブルを更新する必要性は全く無い。）

最終的に、サーバがその作業負荷をチェックする手順は、新しいクライアントを受け入れるプロセスの最後に走行できる。もしサーバが過負荷になったと評価すると、ネットワーク内のクライアントとの交渉を開始し、新しいサーバになって現在のその作業負荷の一部を担うよう、それに頼んでもよい。

新しいノードの構成要素
図９は、新しいノードが既存のネットワークに関連する手順を示す。新しいノードが既存のネットワークに関連することを希望し、サーバとリンクを確立しようと試みる時はいつでも、この手順を実行する。第１に、新しいノードは“サーバ・メッセージ”と呼ぶルックアップ・リクエストをブロードキャストする（ステップ１）。もし本ノードが所定の最大期間で全く返答を受信しないならと決定する（ステップ２）なら、それは、関連は全く不可能である（ステップ３）と推測する。

もし新しいノードがその通知に対する返答を受信するなら、そのようなメッセージは次の二つの異なる源を持つ可能性がある：それは、もう一つのクライアントからか、サーバからかである。それ故、もし返答を受信したとステップ２で決定するなら、テキスト４で新しいノードは、返答はもう一つのクライアントからか、またはサーバからかを決定する。もし返答がクライアントからくるなら、ノードは、サーバとｎホップの関連（ｎ＞１）を確立することに興味があるかどうかを決定する。もしノードが、幾つかの事前に決定した方策または理由から、ｎホップの関連を確立することを望まないなら、それは、サーバからの返答が無い場合、関連は全く不可能であるか、サーバにリクエストをブロードキャストする手順を再起動してもよい、と推測してもよい。これを多数回繰り返す。もしノードが、サーバとのｎホップの関連がその作業に適切であると決定すれば、それはそのようなｎホップの関連を確立する（ステップ５）。

あるいは、もしノードが、ステップ４で、返答はサーバからであると決定するなら、それは、そのサーバと関連を交渉する（ステップ６）。

図１０は、ノードがクライアントから返答を受信した（ステップ１）場合に実行されるステップを更に詳細に示す。ステップ２で、ノードは、返答したクライアント経由でネットワークへのｎホップの関連を受け入れるべきかどうかを決定する。もしノードが、ｎホップの関連を確立することを希望しないと決定すると、それは、関連が全く可能ではない（ステップ３）と推測する（そのとき、ノードは、サーバのためにリクエストを送るプロセスを繰り返してもよい。）

もしノードが、ネットワークへのｎホップの関連を受け入れることをステップ２で決定すると、それは、“ブリッジ・クライアント”を通して“サーバ・メッセージ”のためのリクエストを送り（ステップ４）、サーバからのレスポンスを待つ（ステップ５）。もしノードが所定の期間内でレスポンスを受信しないなら、ノードは、関連が全く可能ではない（ステップ３）と推測する（そして、サーバのためにもう一つのリクエストをブロードキャストして本手順を再起動してもよい）。もしノードがクライアントを経由してサーバから返答を受信するなら、新しいノードは、クライアント経由でサーバとのアドレス交渉プロセスを開始する（ステップ６）。

もし新しいノードが図９のステップ１でそのサーバ・リクエストをブロードキャストする場合に、新しいノードがサーバからレスポンスを受信すると、ノードは本提示を受け入れるか、または拒否することができる。新しいノードは、サーバまたはクライアントのどちらから一つ以上の提示メッセージを受信してもよい。しかしながら、新しいノードは、それらに中の一つのみに答えなければならない。上述のように、本発明では、そのような提示は新しいサーバになること、または新しいクライアントになることであり得る。

図１１はサーバとの交渉のプロセスを示す。ステップ１で、新しいノードは、（図９のステップ１で送られたサーバ・リクエストに応答して）サーバから返答を受信する。ステップ２で、ノードは、サーバが関連を提示したかどうかを決定し；もしサーバが関連を提示しなかったなら、本プロセスは終了する。関連が提示されたなら、ノードは、本提示がクライアント提示かサーバ提示かをステップ３で決定する。本提示が新しいサーバになることであれば、本ノードは、この提示を受け入れるべきかどうかをステップ４で決定する。もし新しいノードが、本サーバ提示を受け入れることを希望しないなら、ノードはサーバ提示を拒否し（ステップ５）；次に、新しいノードは、本サーバ（またはもう一つのサーバ）から、新しいクライアントになるためのアドレスを提示するレスポンスを待ってもよい。

もし新しいノードが、新しいサーバになる提示を受け入れることを決定するなら、それはステップ６で本提示を確認し、最終確認がサーバから受信されたかどうかを見るために待つ。最終確認の受信を決定すると（ステップ７）、新しいノードはその状態をサーバに移し、それをネットワークに関連させたと推測する（ステップ８）。しかしながら、もし新しいノードが、最終確認が受信されなかったとステップ７で決定すると、それは、ネットワークに関連しようとする試みが失敗したと推測する（ステップ９）。

もし新しいノードが、本提示が新しいクライアントになることであるとステップ３で決定すると、ノードは、確認を送って（ステップ６）その興味を確認し、サーバからの最終確認を待つ。ノードがサーバからの最終確認の受信を決定すると、それは、その状態をクライアントに移し、それがネットワークへ関連させられる（ステップ８）と推測する。しかしながら、もし新しいノードがサーバから最終確認を受信しないなら、それは、ネットワークへ関連する試みが失敗したと推測する（ステップ９）。

クライアント構成要素
新しいノードが既存のネットワークに関連したい場合、それは上記で説明した手順に従う。もし新しいノードがサーバとの関連を確立したなら、新しいノードは、クライアントとしてネットワークに関連し、以下の手順で動作を開始する。

本クライアントはユニキャスト、マルチキャストまたはブロードキャスト・メッセージに耳を傾けることを開始する。クライアントを含むことができる通信には三つの可能な形式がある。

第１形式の通信は、すでに構成されたクライアントが、新しいノードが送ったサーバのためのリクエストを受信する場合に起こる。クライアントが新しいノードが送ったサーバのためのリクエストを受信する（図１２のステップ１）場合、クライアントは、ネットワークにおいて新しいノードと既存のサーバとの間のブリッジになる可能性を分析する。もしこれが可能であり、クライアントがブリッジになることを決定すれば（図１２のステップ２）、クライアントは、サーバとの通信を確立するのに助力を提示する新いノードにメッセージを送る（図１２のステップ３）。そうでなければ、クライアントは単に本リクエストを無視し、初期状態に戻る。これがクライアントと新しいノードとの間の通信である。

第２形式の通信は、新しいノードから生じてもよく、“ブリッジ・クライアント”を経由して、それをサーバに転送する必要がある。本メッセージは、サーバへの直接的関連が定めるものと同じものである。相違は、本メッセージをクライアントがサーバに経路指定（転送）する必要があるということであり、それは、新しいノードはサーバに直接到達できないからである。この場合、ブリッジ・クライアントは、本メッセージを受信（図１３のステップ１）後、メッセージを単に転送し（図１３のステップ２）、初期状態に戻る。これは、ブリッジ・クライアントを経由したサーバとｎホップの新しいノードとの間の通信である。

サーバに耳を傾ける場合、クライアントは第３形式の通信を受信する可能性がある。この通信は、新しいサーバになるよう、クライアントへの通知または提示によって使用される。図１４は、本メッセージが通知である場合のステップを示す。サーバ通知を受信する（図１４のステップ１）場合では、クライアントは通知に単に返答し（図１４のステップ３）、初期状態に戻る。もしクライアントが、ある時間制限内にサーバ通知を受信しなかったなら、クライアントは、サーバは死んいると推測し、そのアドレス・リースを強制的に取り消し、またネットワークにおけるそのクライアント・ロールを中止するだろう。また、クライアントは、それがもう一つのクライアントとサーバとの間の通信をブリッジしている（図１４のステップ３）かどうかを決定するであろうし、もしそうなら、クライアントはまた、それがブリッジとして動作するクライアントにサーバの通知を転送する（図１４のステップ４）。これがサーバとクライアントとの間の通信である。

もしクライアントで受信したメッセージが、サーバになる提示であれば、クライアントは、そのような提示を拒否するか受け入れることができる。図１５は、この場合における手順を示す。サーバ提示を受信する場合（図１５のステップ１）では、クライアントは本提示を受け入れるかどうかを決定する（図１５のステップ２）。幾つかの特定の理由で、もし新しいサーバになることが可能でないなら、クライアントは本提示を拒否するメッセージを送り（図１５のステップ３）、初期状態に戻る。しかしながら、クライアントが本提示を受け入れることを決定すると、それは確認メッセージをサーバに送り（図１５のステップ４）、最終確認を待つ。最終確認の受信（図１５のステップ５）を決定すると、クライアントはサーバにその状態を設定する（図１５のステップ６）。しかしながら、クライアントが、事前に設定した期間に最終確認を受信しなかったということをステップ５で決定すると、本提示の受け入れは失効する。

また、クライアントは、そのサーバとのアドレス・リースを取り消すことを決定してもよい。この場合、クライアントは、この時から先、本アドレスを使用しないだろうということを確認するサーバにメッセージを送り、更なる交渉または警告を全く無しに、ネットワークにおけるクライアント・ロールを中止する（図１６参照）。

バックアップ
ネットワークにおいて、例えば、もしサーバが機能停止に苦しむことがあったなら、肩代わりできる少なくとも一つのバックアップ・サーバを持つことは、サーバにとって通常である。十分に効果的である自律的ネットワークのためには、それは、ネットワークにおけるサーバにバックアップ・サーバを提供し、サーバが機能停止する場合、バックアップ・サーバが自動的に肩代わりすることができるメカニズムを持たなければならない（しばしばこれは“自己回復”として知られる）。バックアップおよび自己回復メカニズムは、アドレス管理の完全性を保証する目的を持つ。両方とも、サーバまたはリンク通信機能停止のような危機的状況を通過した後にネットワークを回復するよう試みる。本発明の更なる特徴は、サーバのためのバックアップの提供に関する。

望ましくは、ネットワークにおける各サーバは、デフォルトで、二つのバックアップ・サーバを持つだろう。この冗長は、もしサーバとそのバックアップとが機能停止したとしても、回復を保証するためである。機能停止は、従来のネットワークにおいてよりは高度に動的なネットワークにおいて、より可能性がある。２台のバックアップ・サーバは、第１レベルのバックアップと第２レベルのバックアップに分類される。第１レベルのバックアップ・サーバのみがサーバと直接的通信を持つ。第２レベルのバックアップ・サーバは、機能停止を含むネットワーク状態に気付くために、第１レベルのバックアップ・サーバとメッセージを交換する。

バックアップの選択
バックアップ・サーバの選択はサーバによって実行される。サーバはそのクライアントについての状態と安定性情報を持っているので、それは、クライアントの中からそのバックアップを選択するために適当な位置にいる。例として、ネットワークの構成パラメータを取り扱う、より高次のレベルのプロトコルが、クライアントについての情報を集めてもよい、しかし、サーバは、任意の適当な方法でそのバックアップ・サーバを選択してもよく、本発明はどれかの特別の方法に制限されない。

サーバとバックアップとの間の交信
好ましい実施形態では、サーバはそのバックアップ・サーバを選択する責任を持っている。バックアップ・サーバを選択するプロセスは、一般的には、サーバが現存のクライアントにサーバになることを勧誘する場合のそれに類似であり−サーバは、バックアップ・サーバになるようクライアントを勧誘するクライアントにメッセージを送り、もしクライアントがこの提示を受け入れるなら、クライアントはバックアップ・サーバになる。サーバの選択がなされた後、バックアップ・サーバは、サーバとのそれらの関係を管理しなければならない。図１７はサーバとそのバックアップ・サーバとの間の基本的関係を提示する。

第１レベルのバックアップ・サーバは、サーバにリクエスト・メッセージを周期的に送り（ステップ１）、サーバの返答を待つ。それがサーバから返答を受信する（ステップ２）場合、第１バックアップ・ノードはまた、第２レベルのバックアップ・サーバに報告メッセージを送る（ステップ３）。このように、第２バックアップはまた、新しい体制（例えば、サーバが行う新しいアドレス割り当て）に気が付く。本報告を送った後、第１レベルのバックアップ・サーバは、第２バックアップ・サーバがまだアクティブであるということを確認するため、第２バックアップ・サーバから返答を期待する（ステップ４）。

バックアップ２のために通信する、可能性のある機能停止のために、特別な考慮がなされる。新しいバックアップを推薦するため、機能停止手順を開始する。第１レベルのバックアップ・サーバが、周期的メッセージ交換を使用して第２レベルのバックアップ・サーバと連絡を保つので、それは、第２バックアップがまだアクティブであるかどうかを特定する責任がある。第２レベルのバックアップ・サーバが、所定の期間の間、第１バックアップ・サーバに全く返答メッセージを送らない場合、第１バックアップ・サーバは、第２バックアップ・サーバは機能停止したか、もはや到達できないと推測し、サーバに本状況を報告する。次に、サーバは第２バックアップ・サーバ位置として動作するよう、もう一つのクライアントを選択し、新しい第２レベルのバックアップ・サーバの役割を担うクライアントの識別（アドレス）について、それを知らせる第１レベルのバックアップ・サーバにメッセージを送る。この方法で、報告メッセージの交換を再開する。

他方、もし第２レベルのバックアップ・サーバは、第１レベルのバックアップ・サーバからの周期的メッセージを受信することを停止すべきであるなら、それは、第１レベルのバックアップ・サーバが機能停止したと推測する。次に、第２レベルのバックアップ・サーバは、第１レベルのバックアップ・サーバの役割を担い、このことをサーバに公表する。その結果、サーバは、もう一つの第２レベルのバックアップ・サーバであろう。

図１８は、サーバが機能停止する場合の状況を提示する。

図１８のステップ１−４は、図１７のステップ１−４に対応し、サーバ、第１バックアップ・サーバおよび第２バックアップ・サーバが正しく動作していることに対応する。サーバが第１レベルのバックアップ・サーバからのメッセージに返答していないか、第１バックアップ・サーバに報告している場合、本サーバが機能停止した可能性がある、ということに第１レベルのバックアップ・サーバは気付く。それ故、ステップ５で、第１レベルのバックアップ・サーバはリクエスト・メッセージをサーバに送るが、サーバは機能停止したので、サーバからの返答を受信しない。サーバ通知の欠如を含め、設定期間でレスポンスを全く受信しない後に、第１レベルのバックアップ・サーバは、サーバが機能停止した（サーバの機能停止よりむしろ通信リンクの機能停止のように、返答の欠如のその他の可能な説明があるけれども）と結論を下し、階層ですぐより高次のレベルのサーバに連絡し、それがサーバの位置を担ったことを通知してもよく、また一方、ステップ７で確認通知する第２バックアップ・サーバに報告する（ステップ６）。より高次のレベルのサーバは、新しいサーバ通知の受信を確認し、それを表示し、また、その返答で前のサーバの機能停止を報告するメッセージを送る（ステップ９）。その結果、第１バックアップ・サーバは第２バックアップ・サーバに、それがサーバの位置を担っているということを知らせ（ステップ１０）、第２バックアップ・サーバはステップ１１で本通知の受信を確認すべきである。同じ簡単な手順が任意のレベルの機能停止に適用される。より高次のレベルのサーバが欠如している場合、より高次のレベルのサーバとの通信に関する全てのステップを除外する以外は、手順は上記のようになるであろう。

もしステップ９で、その返答でサーバの機能停止を確認しなかったなら、サーバと第１バックアップ・サーバとの間の通信リンクが機能停止したという場合である可能性がある。この場合、サーバ自身は、そのバックアップ・サーバと通信し、新しいバックアップ・サーバの選択をトリガするよう、そのような機能停止を検出してもよい。また、もしより高次のサーバが、ステップ９でその返答でサーバ機能停止を確認しなかったなら、第１レベルのバックアップ・サーバは、それ自身とそのサーバとの間の通信リンクが機能停止したと推測する。その結果、第１レベルのバックアップ・サーバはそのバックアップ役割を停止し、サーバはすでにそのバックアップとして動作する新しいクライアントを選択していると推測する。これは、サーバおよび第１レベルのバックアップ・サーバが同時に回復動作を開始することを防止するはずである。

図１９は、サーバとその第１レベルのバックアップがともに機能停止した場合の状況におけるメッセージ・フローを提示する。

図１９のステップ１−４は図１７のステップ１−４に対応し、サーバ、第１バックアップ・サーバおよび第２バックアップ・サーバが正しく動作していることに対応する。次に、それは、サーバおよび第１バックアップ・サーバが両方とも機能停止するということを仮定している。

第２レベルのバックアップ・サーバは、第１レベルのバックアップ・サーバから報告を周期的に受信するタスクを持ち、ネットワークは正しく動作しており、第１バックアップに返答していると仮定している。もし、所定の期間後、第２バックアップ・サーバが第１バックアップ・サーバから報告を受信しなかったなら、それは、ネットワーク問題の可能性があると推測する。これがその場合かどうかを確認するため、第２バックアップ・サーバは、図１９のステップ５で、ネットワーク状況の確認を獲得するため、階層ですぐより高次のサーバに連絡する。もし、ステップ６におけるその返答で、より高次のサーバが、サーバおよび第１バックアップ・サーバが機能停止したということを確認すると、第２レベルのバックアップはサーバの位置を推測し、ステップ７でより高次のサーバに助言し、二つの新しいバックアップ・サーバ（図１９には図示せず）を選択する。そうでなければ、もしより高次のサーバが、ステップ６におけるその返答で、機能停止状況を確認しないなら、即ち、サーバおよび／または第１レベルのバックアップ・サーバは依然として動作しているなら、第２バックアップ・サーバは、それはもはやバックアップ・サーバでないと推測する。

図１８および１９に示したものに加えて、その他の機能停止モードが可能である。例えば、サーバは動作することを継続するが、一つまたは両方のバックアップ・サーバが機能停止する、ということが可能である。この状況では、サーバは、機能停止したサーバを置き換えるため、新しいバックアップ・サーバを選択する責任がある。

もし第１レベルのバックアップ・サーバのみが機能停止するなら、それにもかかわらず、サーバは、第２レベルのバックアップ・サーバとの連絡を失い、その結果それは、両方のバックアップ・サーバが機能停止したと推測し、二つの新しいバックアップ・サーバを選択する手順を開始する。この場合におけるネットワークでまだアクティブである第２バックアップは、再度選択されることができる。

第２レベルのバックアップ・サーバが機能停止する場合では、すでに説明したように、第１レベルのバックアップはサーバに報告を送り、サーバは、第２レベルのバックアップ・サーバの位置を取るため、もう一つのノードを選択する。

第１および第２の両方のレベルのバックアップ・サーバが機能停止する場合、サーバは、そのクライアントについて既にそれが持っている情報に基づき、バックアップ・サーバ・ロールを担うため二つのノードを選択する。

図２０は、サーバの機能停止が起こる（ステップ１）場合の状態図を示す。既に説明したように、第１レベルのバックアップ・サーバは置換えサーバになることを好み、もし第１レベルのバックアップ・サーバはステップ２でサーバ・ロールを担うなら、第２レベルのバックアップ・サーバは、ステップ３で、第１レベルのバックアップ・サーバの役割を担い、新しいサーバ（即ち、前の第１レベルのバックアップ・サーバ）は、ステップ４で、新しい第２レベルのバックアップ・サーバを選択する。（もし‘旧’サーバが再び“動作している”のであれば、それは、新しいノードとして処理されるであろう。）

もし第１レベルのバックアップ・サーバが、また機能停止したという理由で、ステップ２で、サーバ・ロールを担わないなら、第２レベルのバックアップ・サーバは、ステップ５で、サーバ・ロールを担ってもよい。もし第１バックアップ・サーバがサーバの役割を担うことができない場合のみ、第２レベルのバックアップはサーバの代わりをするだろう。新しいサーバ（即ち、前の第２レベルのバックアップ・サーバ）は、ステップ６で、新しい第１レベルのバックアップ・サーバを選択し、ステップ４で、新しい第２レベルのバックアップ・サーバを選択する。

更に、もし第２レベルのバックアップ・サーバが、ステップ５で、サーバ・ロールを担わないなら（即ち、もしどちらのバックアップ・サーバとも機能停止したサーバの役割を担うことができないなら）、より高次のレベルのサーバ（もし存在すれば）は、ステップ７で、アドレス指定の責任を引き継ぎ、機能停止したサーバが制御していてプールを管理してもよい。その結果、より高次のサーバは、それと連絡を持つため、ネットワークの機能停止した部分の一部であったサブネットワークを待ち、一方、特定の期間予約したそれらのアドレス割り当てを保つ。もしサブネットワークがこの期間の間により高次のサーバと連絡しないなら、それらのアドレス・プールは“自由な”状態に設定されてもよい。

もしより高次のレベルのバックアップ・サーバが、ステップ７で、サーバ・ロールを担わないなら、これは、ネットワークで重大な問題があるということを表示する可能性があり、恐らくネットワークの破綻につながる（ステップ９）。

図２４は、ノードがバックアップ・サーバになる提示を受信するプロセスを示す。最初に、ステップ１で、ノードは（ネットワークのサーバから）、そのサーバに対してバックアップ・サーバ（例えば、第１レベルのバックアップ・サーバまたは第２レベルのバックアップ・サーバ）になる提示を受信する。

ステップ２で、ノードは、バックアップ・サーバになる提示を受け入れるか入れないかを決定する。もしそれが本提示を受け入れないと決定すれば、それは、本提示を拒否することにより、返答する（ステップ３）。

もしノードが、ステップ２で本提示を受け入れることを決定すれば、それは、ステップ４で、バックアップ・サーバとして動作するその意欲の確認をサーバに送って返答する。

ステップ５で、ノードは、バックアップ・サーバになる提示の最終確認をサーバから受信するかどうかを決定する。そのような最終確認が受信されたなら、ノードはバックアップ・サーバの役割を担う（ステップ６）。しかしながら、もしノードが、サーバから提示の最終確認を（例えば、事前設定した期間内で）受信しないなら、それは、もはやサーバはバックアップ・サーバになることをそれに希望しないと推測し、プロセスは終わる。

ネットワークの自己回復
この場合における自己回復は、サーバとそのより高次のレベルのサーバとの間の通信リンクが機能停止し、そのため、サーバが制御するサブネットワークがアドレス制御から孤立させられるが、サーバおよびその下の任意の子サーバの階層が維持され、従って制御ネットワークへの再関連に利用可能である、という状況に関連している。ネットワークの構造内でアドレス情報の完全性を保つため、この状況を好ましく取り扱わなければならない。

図２１はネットワークにおけるサーバ階層の例を示す。矢印は親サーバ関係を示し、矢印の先で従属サーバを示し−従って、サーバＡはサーバＢおよびサーバＣの両方の親サーバである。図２１に提示したサーバ階層を考慮して、例として、サーバＣとその親サーバＡとの間で、同様な機能停止が起こる可能性がある。サーバＡがサーバＣとの通信を失う場合、サーバＣはその親サーバと通信できないため、サーバＣの下での全体のサブネットワーク体制が脅かされる。好ましい実施形態では、サーバＡは、サーバＣがネットワークに戻ってくるかも知れないという可能性を直ちに放棄しない。それ故、サーバＡは、特別な方法で、サーバＣに前に割り当てられたアドレス・プールを処理する。これが必要でないなら、それはアドレス・プールを再割り当てしない。もし、ある時間後、通信リンクがサーバＡとサーバＣとの間で再び動作を開始するなら、サーバＡは、まだサーバＣにアドレス・プールを割り当てられているので、同じアドレス構成を保つようＣに単に告げてもよい。

しかしながら、サーバＡとサーバＣとの間の通信リンクが確立されると、それは、例えば、サーバＡとサーバＣとの間のリンクの長期の機能停止があった場合、サーバＣが前に使用したアドレス・プールをサーバＡが既に再割り当てしたという場合である可能性がある。この場合では、サーバＡは新しい構成情報（即ち、新しいアドレス・プール）をサーバＣに送る。サーバＣはそれ自身のインタフェースを再構成し、それが率いるサブネットワークに新しいアドレス・プールのアドレスを再割り当てする必要がある。この体制回復プロセスはレベル毎に行われる、即ち、サーバＣを構成後、サーバＣは、そのすぐの従属サーバ（図２１のネットワークにおけるサーバＤ、ＥおよびＦ）に新しい構成を送る。同様に、それらのインタフェースを構成後、サーバＤおよびＦは、それらのすぐの従属サーバ（サーバＨおよびＫ）に新しい構成を送る。最後に、サーバＨは、自分自身を構成後、それらのすぐの従属サーバ（サーバＩおよびＪ）に新しい構成情報を送り、それによって、ネットワークの回復プロセスを完了する。

サーバの自己回復
アドレス割り当てメカニズムは、好ましくは、アドレスを再使用することを可能にするため、機能停止したサーバからアドレスのプールを回復できるべきである。これを実装する好ましい方法は、全てのサーバ間に基本的通信メカニズムを生成することによってである。この通信を通して、サーバは、それらが既に割り当てたアドレスまたはまだ利用可能なアドレスのプールについて、情報を交換する。上述のアドレス・プール割り当てのメカニズムは、この機能に対して基本的である。全ての“親サーバ”は、その“子サーバ”のそれぞれからの情報で更新されなければならない。サーバ間の関係（親および子）は、図２２を参照して説明されるであろう。

図２２で、以下のような方法でサーバの階層を構成する：サーバＡはサーバＡＡとサーバＡＢの親であり；サーバＡＡはサーバＡＡＡとサーバＡＡＢに対する親である。その他の全てのノード（Ｃ１．．．Ｃ２０）はこれらのサーバの一つに対するクライアント・ノードである。図２２における太線はサーバとそれらのクライアントとの間の関連を表わす。

その“子サーバ”についての情報を保持することにより、“親サーバ”は、子サーバが機能停止したということを検出すると、子サーバに前に割り当てたアドレス・プールを再推測できる。例えば、図２２で、もしサーバＡＡＢが機能停止すると、サーバＡＡ（サーバＡＡＢの親サーバ）は、サーバＡＡＢに前に割り当てられたアドレス・プールを再推測する。

しかしながら、“子サーバ”のアドレス・プールが親サーバによって再推測される場合、親サーバは、好ましくは、子サーバのアドレス・プールにおけるアドレスの幾つかが、同様にその他のサーバに割り当てられてしまっている可能性がある、ということに気付く可能性があり、好ましくは、これらのアドレスを完全には再推測しない。この実施形態は、子サーバが使用中で、親サーバと通信している間、子サーバがどのアドレスをその他のサーバに割り当てるかについての情報を親サーバが受信する、ということを要求する。このように、ネットワークの二つに分割した部分は、同等のアドレス・プールに亘って伝搬しないだろう。例えば、図２２で、もしサーバＡＡが機能停止するなら、サーバＡはサーバＡＡに前に割り当てられたアドレス・プールを取り戻すであろう。しかしながら、この実施形態では、サーバＡＡの子サーバ（サーバＡＡＡおよびサーバＡＡＢ）に割り当てた、このアドレス・プール、即ち、より少ないアドレス・プールの構成要素は、サーバＡに再割り当てしたアドレス・プールの一部であるべきではない。即ち、サーバＡＡに割り当てたが、サーバＡＡが子サーバに割り当てなかったアドレスのみを取り戻すべきであり−サーバＡＡがサーバＡＡＡまたはサーバＡＡＢに割り当てたということにサーバＡが気付くアドレスは、予約されたとして取り扱われ続けるであろうし、サーバＡによって取り戻されないであろう。この方法で、本発明は、ネットワークの二つに分割された部分は重畳しないだろう。図２２で提示したネットワーク構造に続いて、図２３はサーバＡ、ＡＡおよびＡＡＡのアドレス・プール間の相互作用を提示する。

図２３の例では、サーバＡのアドレス・プールをサブプールに分割し（図２３の左部分を参照）、サブプール１ＡのアドレスをサーバＡのクライアントに直接割り当て、サブプール２ＡのアドレスをサーバＡＡに割り当て、サブプール３ＡのアドレスをサーバＡＢに割り当てる、等である。図２３に示された関係とサーバＡＡが機能停止しているシナリオの両方を考慮すると、サーバＡは、サーバＡＡに前に割り当てたそのアドレス・プール２Ａにわたって責任を取り戻さなければならない。

しかしながら、サーバＡは、割り当てたアドレス・プールの部分は、サーバＡＡの責任の下では、更にサーバＡＡＡに割り当てられた、ということに気付かなければならない。これを、図２３の中心部分に示す−サーバＡＡのアドレス・プールをサブプールに分割し、サブプール１ＡＡのアドレスをサーバＡＡのクライアントに直接割り当て、サブプール２ＡＡのアドレスをサーバＡＡＡに割り当て、サブプール３ＡＡのアドレスをサーバＡＡＢに割り当てる、等である。それによって、その第２アドレス・サブプール２Ａにわたる制御の責任を取り戻す場合、サーバＡは、その他のサーバに再割り当てなかったアドレス・サブプールの一部を管理するのみであってもよく−そうであるから、サーバＡは、（サーバＡＡＡに割り当てた）アドレス・サブプール２ＡＡまたは（サーバＡＡＢに割り当てた）アドレス・サブプール２ＡＢを管理すべきではない。図２３で、もしサーバＡＡが機能停止するなら、サーバＡが再捕捉したプール（ＲＰ）のアドレス集合は次のようになるであろう：
ＲＰ＝（プール＃２Ａ）∩（サーバＡＡが割り当てたプール）
または
ＲＰ＝（プール＃２Ａ）−（サーバＡＡが割り当てたプール）

図２２の方法は、図２１の方法の代替案である。図２１の方法では、サーバＡは、サーバＣがサーバＤ、ＥおよびＦに部分割り当てしたアドレスを含めて、サーバＣの機能停止またはサーバＣとの通信の損失で、サーバＣに割り当てる全てのアドレスを再割り当てする。

サーバ・ブリッジ通信
サーバはまた、ブリッジのように動作できる（しばしば、クライアントは、サーバと１ホップ以上離れたクライアントとの間の通信をブリッジできるけれども）。例えば、新しいノードはサーバＡと１ホップの関連を持つが、例えばアドレスの欠如のため、このサーバはもっと多くのクライアントを担うことできず、また、サーバＡはもう一つのサーバ（サーバＢ）との１ホップの関連を持つ場合、それは、新しいノードとサーバＢとの間の通信をブリッジすることができる。このシナリオでは、サーバＡは、新しいノードが送ったメッセージをサーバＢに中継するのみであり、逆も同じである。

もしサーバＡがもっと多くのクライアントを担う能力を回復するなら、サーバＡは、それと関連するようブリッジされたクライアントに提示でき、それによってサーバに到達するクライアントの必要ホップ数を削減できる。もしクライアントがこの提示を受け入れるなら、サーバＡとクライアントとの間で関連を交渉し、確立後、クライアントはサーバＢにリースを取り消すメッセージを送る。

サーバ変更
サーバＡに既に関連しているクライアントが、第２サーバ、サーバＢからブロードキャスト通知を受信し、サーバＢがサーバＡより近い（即ち、サーバＡより少ないホップ数でサーバＢに到達できる）ということを確認する場合、クライアントはそのサーバを変更するよう選択できる。これが起こるシナリオは、過負荷のサーバが、そのクライアントの一つ（望ましくは、１ホップ以上は離れているクライアント）とその作業負荷を分割することを決定する場合である。選択されたクライアントがサーバになると、それが取る第１の動作は、ネットワークに自分自身を通知することである。その現在のサーバよりこの新しいサーバに近いノードは、新しい関連を交渉して、そのサーバをサーバＢに変更するよう選択できる。

本発明の方法を任意の動的ネットワーク（即ち、ノードが徐々にネットワークに加わり、退くネットワークである）に適用してもよい。

図２５は、本発明のネットワーク・ノードを示す。ネットワーク・ノード１０はサーバとして動作すると示され、ネットワーク１４を経由して一つ以上のクライアント１１−１３に関連する。ネットワーク・ノード１０はアドレス・テーブル１５を持ち、それは、ネットワーク１０に現在割り当てられた全てのネットワークアドレスを含み、アドレスの状態−例えば、アドレスが“自由”、“割り当て済み”または“予約済み” （ここで、“予約済み”は、ネットワーク・ノード１０が現在、そのアドレスをもう一つのノードに提示するプロセスにあるということを表示する）であるかどうか、を表示する。

ネットワーク・ノード１０は、例えばキャッシュ・テーブルの形式で、ブラックリスト１６を更に持っている。これは、例えば、ネットワーク１０が前にリクエストを（例えば図３のステップ３で）拒否したノードのリストである。

ネットワーク・ノードには、プール・テーブル１７を更に備える。これは、例えば、ネットワーク・ノードがその他のサーバに更に割り当てたアドレス・プールについての情報を保持するために使用されてもよく−例として、ネットワーク・ノードが子サーバに割り当て、同様に子サーバが一つ以上のその子サーバに割り当てたアドレス・プールについての情報を含んでいる（例えば、図２３に示すように）。もし子サーバが機能停止するか、子サーバとの通信が失われ、ネットワーク・ノード１０が子サーバに割り当てるアドレスを取り戻すよう要求されるなら、それは、子サーバに割り当て、子サーバがその子サーバの一つに更に割り当てなかったアドレスのみを取り戻す、図２２の方法を実行するために、プール・テーブルの情報を使用してもよい。

ネットワーク・ノード１０は、本発明の方法を実行するために、適当にプログラムされている。ネットワーク・ノードは、例えば、ネットワーク・ノードのプロセッサ（図示せず）上で実行した場合、プロセッサが本発明の方法を実行できる命令を含む、コンピュータ読み取り可能な媒体を使用して、プログラムされていてもよい。或いは、ネットワーク・ノードは、ネットワーク１１を経由して、または製造時にプログラムされていてもよい。

Claims (25)

1. ネットワークにおけるアドレス割り当ての方法であって、
   ノード間の交渉から、クライアントへのネットワークアドレスの分配および管理に対して責任があるサーバ・ロールを第１ノードが担うか否かを決定するステップと、
   前記第１ノードがサーバ・ロールを担うと決定されたとき、前記第１ノードにネットワークアドレス・プールを提供するステップと、
   を含むことを特徴とする方法。
2. 前記第１ノードがサーバ・ロールを担うと決定されたとき、前記ネットワークのサーバ・ノードが前記第１ノードに前記ネットワークアドレス・プールを提供する
   ことを特徴とする請求項１に記載の方法。
3. 前記決定は、
   前記ネットワークの開始時、
   前記第１ノードが前記ネットワークへの関連を要求したとき、
   前記ネットワークのサーバ・ノードが過負荷になったとき、
   前記ネットワークのサーバ・ノードが前記ネットワークを離脱するとき、
   の何れかの場合に実行される
   ことを特徴とする請求項１又は２に記載の方法。
4. 前記決定は、前記第１ノードが前記ネットワークに関連したときに実行され、
   前記方法は、前記第１ノードがサーバ・ロールを担わないと決定されたとき、前記第１ノードに前記ネットワークのクライアント・ロールを提示するステップを更に含む
   ことを特徴とする請求項１又は２に記載の方法。
5. 前記第１ノードは、前記ネットワークのクライアント・ノードである
   ことを特徴とする請求項１又は２に記載の方法。
6. 前記第１ノードがサーバ・ロールを担うと決定されたとき、
   引き続いて、前記第１ノードに更なるネットワークアドレス・プールを提供するステップを含む
   ことを特徴とする請求項１乃至３，５の何れか一項に記載の方法。
7. 前記サーバ・ノードが、前記第１ノードが前記サーバ・ロールをもはや実行していないという指標を受信すると、引き続いて、前記第１ノードが前記サーバ・ロールを担うときに前記第１ノードに提供された前記ネットワークアドレス・プールに対する責任を取り戻すステップを含む
   ことを特徴とする請求項２，請求項２に従属する場合の請求項３，５，６の何れか一項に記載の方法。
8. 前記サーバ・ノードは、前記ネットワークアドレス・プールに対する責任を取り戻す前に、前記第１ノードが前記サーバ・ロールをもはや実行していないという指標を受信した後、所定の期間待機する
   ことを特徴とする請求項７に記載の方法。
9. 前記サーバ・ノードは、前記第１ノードが１以上の更なるサーバに割り当てた第１のアドレスプールのアドレスに対する責任を取り戻さない
   ことを特徴とする請求項７又は８に記載の方法。
10. 前記第１ノードがサーバ・ロールを担うと決定されたとき、
    前記方法は、前記第１ノードが、引き続いて、前記ネットワークの少なくとも１つのノードをバックアップ・サーバとして選ぶ
    ことを特徴とする請求項１乃至３，５乃至９の何れか一項に記載の方法。
11. 前記第１ノードは、該第１ノードのクライアント・ノードの少なくとも１つをバックアップ・サーバとして選ぶ
    ことを特徴とする請求項９に記載の方法。
12. ネットワークにノードを関連付ける方法であって、
    前記ノードから前記ネットワークに関連リクエストを送信するステップと、
    前記ノードが、前記ネットワークのノードからの応答を受信するステップと、
    前記ノードが、前記受信された応答が前記ネットワークのクライアント・ノードからの応答であるか前記ネットワークのサーバ・ノードからの応答であるかを決定するステップと、
    前記受信された応答に従って、クライアントとして又はサーバとして前記ネットワークに関連するステップと、
    を含むことを特徴とする方法。
13. 前記ノードが前記ネットワークのサーバ・ノードからの応答を受信したとき、前記ノードと前記サーバ・ノードとの間の交渉から決定されたように、前記ノードはクライアントとして又はサーバとして前記ネットワークに関連する
    ことを特徴とする請求項１２に記載の方法。
14. 前記ノードが前記ネットワークのサーバ・ノードからの応答を受信せず前記ネットワークのクライアント・ノードから応答を受信したとき、前記ノードはｎホップ・クライアントとして前記ネットワークに関連する
    ことを特徴とする請求項１２に記載の方法。
15. 前記ノードはサーバとして前記ネットワークに関連し、
    前記方法は、前記ノードが、クライアントを構成するためのネットワークアドレス・プールを受信するステップを更に含む
    ことを特徴とする請求項１３に記載の方法。
16. ネットワークノードであって、
    ノード間の交渉から、クライアントへのネットワークアドレスの分配および管理に対して責任があるサーバ・ロールを第１ノードが担うか否かを決定し、
    前記第１ノードがサーバ・ロールを担うと決定されたとき、前記第１ノードにネットワークアドレス・プールが提供されるように手配する
    のに適している
    ことを特徴とするネットワークノード。
17. 前記第１ノードがサーバ・ロールを担うと決定されたとき、前記ネットワークノードは前記第１ノードに前記ネットワークアドレス・プールを提供するのに適している
    ことを特徴とする請求項１６に記載のネットワークノード。
18. 前記ネットワークの開始時、
    前記第１ノードが前記ネットワークへの関連を要求したとき、
    前記ネットワークのサーバ・ノードが過負荷になったとき、
    前記ネットワークのサーバ・ノードが前記ネットワークを離脱するとき、
    の何れかの場合に前記決定を実行するのに適している
    ことを特徴とする請求項１６又は１７に記載のネットワークノード。
19. 前記第１ノードが前記ネットワークに関連したときに前記決定を実行し、
    前記第１ノードがサーバ・ロールを担わないと決定されたとき、前記第１ノードに前記ネットワークのクライアント・ロールを提示する
    のに更に適している
    ことを特徴とする請求項１６又は１７に記載のネットワークノード。
20. 前記ネットワークノードは、前記第１ノードがサーバ・ロールを担うと決定されたとき、引き続いて、前記第１ノードに更なるネットワークアドレス・プールを提供するのに適している
    ことを特徴とする請求項１６乃至１８の何れか一項に記載のネットワークノード。
21. ネットワークノードであって、
    ネットワークに関連リクエストを送信し、
    前記ネットワークのノードから応答を受信し、
    前記受信された応答が前記ネットワークのクライアント・ノードからの応答であるか前記ネットワークのサーバ・ノードからの応答であるかを決定し、
    前記受信された応答に従って、クライアントとして又はサーバとして前記ネットワークに関連する、
    のに適している
    ことを特徴とするネットワークノード。
22. 前記ネットワークのサーバ・ノードからの応答を受信したとき、前記ネットワークノードと前記サーバ・ノードとの間の交渉から決定されたように、クライアントとして又はサーバとして前記ネットワークに関連するのに更に適している
    ことを特徴とする請求項２１に記載のネットワークノード。
23. 前記ネットワークノードが前記ネットワークのサーバ・ノードからの応答を受信せず前記ネットワークのクライアント・ノードから応答を受信したとき、ｎホップ・クライアントとして前記ネットワークに関連するのに更に適している
    ことを特徴とする請求項２１又は２２に記載のネットワークノード。
24. 前記ネットワークノードはサーバとして前記ネットワークに関連するとき、クライアントを構成するためのネットワークアドレス・プールを受信するのに更に適している
    ことを特徴とする請求項２２に記載のネットワークノード。
25. プロセッサにより実行されるとき、ネットワークノードに請求項１乃至１５の何れか一項に記載の方法を実行させる命令を格納したコンピュータ可読媒体。

Images