(57)【特許請求の範囲】
【請求項１】
ネットワーク内のトラフィックをモニタリングする方法において、ネットワークの少なくとも２つのモニタリングプローブのモニタリング活動が調整手段によって調整され、
ネットワークの少なくとも２つのノードが調整手段として動作することが可能であり、モニタリングプローブのモニタリング活動を調整する責任が、フローパラメータキーの圧縮表現に従ってノード間で分担されることを特徴とする、ネットワーク内のトラフィックをモニタリングする方法。
【請求項２】
特定のトラフィックフローをモニタリングする責任が単一のプローブに割り当てられることを特徴とする請求項１に記載の方法。
【請求項３】
コンテンツベースのアドレシングがネットワーク内で使用されることを特徴とする請求項１または２に記載の方法。
【請求項４】
ノード障害および新規ノード加入を透過的に処理することがネットワーク内で実行されることを特徴とする請求項１ないし３のいずれか１項に記載の方法。
【請求項５】
ノードがピアツーピアシステムに属することを特徴とする請求項１ないし４のいずれか１項に記載の方法。
【請求項６】
プローブが、ピアツーピアシステムに属することを特徴とする請求項１ないし５のいずれか１項に記載の方法。
【請求項７】
前記フローパラメータキーが、フローを識別するフローの１つ以上のフィールドを含み、
前記圧縮表現が、前記１つ以上のフィールドのハッシュ値であり、
新しいフローの検出後、少なくとも１つのプローブが、そのフローを識別するフローの１つ以上のフィールドのハッシュ値を計算することを特徴とする請求項１ないし６のいずれか１項に記載の方法。
【請求項８】
前記ハッシュ値が、ＩＰソースおよび宛先アドレス、プロトコルタイプ、ならびにソースおよび宛先ポートからなるフロー５−タプルを入力としてとるハッシュ関数の結果であることを特徴とする請求項７に記載の方法。
【請求項９】
ハッシュ値を計算した後、プローブが、フローのモニタリングの調整を担当することになる担当ノードのアドレスを取得するために、計算したハッシュ値のコンテンツベースのルックアップを実行することを特徴とする請求項７または８に記載の方法。
【請求項１０】
担当ノードのアドレスを取得した後、プローブが、フローの所定のデータタイプおよび／またはフローの記述を含むメッセージを担当ノードへ送信することを特徴とする請求項９に記載の方法。
【請求項１１】
メッセージが、プローブおよび／またはモニタリングリソースの状態または利用可能性に関するレポートまたはデータをさらに含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記データが、利用可能メモリ、帯域幅、ＣＰＵサイクル、ＣＰＵ利用率および／またはタイムスタンプを含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
１つまたは複数のプローブからメッセージを受信した後、担当ノードが、フローをモニタリングする責任を１つの適当なプローブに割り当てることを特徴とする請求項１１または１２のいずれか１項に記載の方法。
【請求項１４】
前記担当ノードによる割当の決定が、前記レポートおよび／または前記データおよび／または前記担当ノードにローカルな情報および／またはユーザにより指定されたポリシーに基づくことを特徴とする請求項１３に記載の方法。
【請求項１５】
メッセージが、複数の検出されたフローのデータタイプおよび／または記述を含むことを特徴とする請求項１０ないし１４のいずれか１項に記載の方法。
【請求項１６】
ネットワークにおいて、ネットワーク内のトラフィックをモニタリングするため、ネットワークの少なくとも２つのモニタリングプローブのモニタリング活動が調整手段によって調整され、
ネットワークの少なくとも２つのノードが調整手段として動作することが可能であり、モニタリングプローブのモニタリング活動を調整する責任が、フローパラメータキーの圧縮表現に従ってノード間で分担されることを特徴とするネットワーク。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク内のトラフィックをモニタリングする方法に関する。本方法において、ネットワークの少なくとも２つのモニタリングプローブのモニタリング活動が調整手段によって調整される。また、本発明は、ネットワークに関する。本ネットワークにおいて、ネットワーク内のトラフィックをモニタリングするため、ネットワークの少なくとも２つのモニタリングプローブのモニタリング活動が調整手段によって調整される。
【背景技術】
【０００２】
モニタリングは、ネットワークの正確な動作およびネットワーク上で実行されるサービスの両方にとって重要である。事業者は、トラフィックエンジニアリング、サービス品質、セキュリティならびに障害および誤コンフィグレーションの検出等のさまざまな目的のためにモニタリングを実行する。これらのアプリケーションに関連するトラフィックは、ネットワーク内の複数のポイントを通って流れることが多いので、それを追跡するために分散型モニタリングアーキテクチャが必要とされる。
【０００３】
残念ながら、リアルタイムかつ分散方式でトラフィックをモニタリングすることは、一連の困難な問題を生じる。そのうちの第１の問題はスケーラビリティである。モニタリングの対象となるトラフィックの量は急激に増大している。報告されるところによれば、年間のグローバルＩＰトラフィック量は２０１２年までに０．５ゼタバイトを超え、２年ごとにほぼ倍になる。この増大は、いかなるモニタリングインフラストラクチャにも重大な圧力となる。フローベースのモニタリングは、事業者の需要を満たすために必要な分解能を保持しつつ、より粗い粒度で動作することによって、この問題に対処するのに役立つ。さらに、フローモニタリングは、小規模なフローに対するパケットサンプリング手法のバイアスを回避する。これは、セキュリティアプリケーションにとって重要な特徴である。
【０００４】
このようなトラフィックのモニタリングは、ネットワーク全体に広く散在するプローブ間でモニタリング作業が分担される分散型インフラストラクチャを必要とする。しかし、これらのプローブに対する調整インフラストラクチャが必要とされる。特に、各トラフィックフローが同時に複数のプローブを通る可能性が高いので、これらのプローブの１つだけがモニタリングを行い、フローに関するデータをエクスポートすることを保証する必要がある。この必要性は、パフォーマンス上の理由（すなわち、同一フローを複数回モニタリングして、対応するレポートをエクスポートすることは、貴重なリソースを浪費する）と、精度上の理由（すなわち、同一フローを複数回計上すると、モニタリングアプリケーションの集計結果が劣化することがある）の両方に由来する。
【０００５】
複数のプローブの活動を調整するために提案されているほとんどのアプローチは、集中型エンティティに基づいている。このエンティティは、トラフィックおよび各プローブ上で利用可能なリソースに関するすべての必要な情報を収集した後、最適なコンフィグレーションを計算する。この種の解決法の最も代表的な例の１つはＣｓａｍｐである。これは、調整ポイントがトラフィック行列およびルーティング方式の知識を有するとともに、プローブが各パケットを送信元−宛先識別子でマーキングできる、ということを仮定する。この仮定はＣｓａｍｐの最近のバージョンによって対処されているが、この改良は、より高いフロー粒度を扱わなければならないことと引き換えに実現されているため、一般的には次善の解決法となっている。
【０００６】
更新から生じる高レベルの変動以外に、この集中化された位置は、スケーラビリティの問題と単一障害点（single point of failure）を生じる。この問題に対処したＣｓａｍｐの改良バージョンが提案されているが、最適なリソース割当を犠牲にしてなされたものである。Ｃｓａｍｐは非特許文献１に記載されている。
【０００７】
単一調整ポイントによるアプローチは、大規模なモニタリングシステムにスケールアップしがたく、システムの耐障害性を低下させてしまう。また、特にドメイン間モニタリングの場合には、トラフィック行列およびルーティング状態を取得することが常に可能とは限らない。というのは、事業者はそのような情報を第三者に積極的に開示することはほとんどないからである。また、ネットワーク条件の変化後に新たなモニタリングコンフィグレーションを開始するためには、集中型アプローチはまず測定データを収集してから新たな最適解を計算しなければならない。これはかなりのレイテンシを伴うことがあり、不整合な測定値を生じる可能性がある。
【０００８】
別の解決法として、確率的データ構造を用いて、どのプローブがどのフローを現在モニタリングしているかに関する情報を配信することが挙げられる。このような解決法は非特許文献２に記載されており、基本的には、現在モニタリングされているすべてのフローを要約する確率的データ構造をあらゆるモニタリングノードへブロードキャストするために、エピデミックアルゴリズム（epidemic algorithm）を使用するものである。このようなモデルは、交換されるトラフィックに関して高いオーバーヘッドを伴い、スケーラビリティが低い。さらに、確率的サマリは通常、偽陽性を許容するので、ある一定数のフローがモニタリングを逃れる可能性が高い。残念ながら、このアプローチはゴシッピングプロトコル（gossiping protocol）を使用するので、大規模なネットワークにスケールできない。さらに、一部のフローが複数回モニタリングされる可能性がある。これは、ネットワーク事業者の要求条件によっては、受け入れられない場合がある。
【０００９】
また、非特許文献３には、ネットワーク内のトラフィックをモニタリングする別の方法が記載されている。
【先行技術文献】
【非特許文献】
【００１０】
【非特許文献１】Sekar, V., Reiter, M. K., Willinger, W., Zhang, H., Kompella, R. R., and Andersen, D. G., "CSAMP: a system for network-wide flow monitoring", In Proceedings of the 5th USENIX Symposium on Networked Systems Design and Implementation (San Francisco, California, April 16-18, 2008)
【非特許文献２】Sharma, M. and Byers, J., "Scalable Coordination Techniques for Distributed Network Monitoring", In Proceedings of the 6th Conference on Active and Passive Measurement (PAM 2005)
【非特許文献３】Vyas Sekar, Anupam Gupta, Michael K Reiter, Hui Zhang, "Coordinated Sampling sans Origin-Destination Identifiers: Algorithms, Analysis, and Evaluation", Technical Report, CMU-CS-09-104
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本発明の目的は、ネットワーク内のトラフィックをモニタリングする方法において、リソースおよびパフォーマンスの要求を低減した簡易なモニタリングメカニズムを提供するような改良およびさらなる展開を行うことである。また、本発明のもう１つの目的は、好ましくは上記方法を実行する、対応するネットワークを提供することである。
【課題を解決するための手段】
【００１２】
本発明によれば、上記の目的は、請求項１の構成を備えた方法および請求項１７の構成を備えたネットワークによって達成される。請求項１に記載の通り、本方法は、ネットワークの少なくとも２つのノードが調整手段として動作することが可能であり、モニタリングプローブのモニタリング活動を調整する責任が、フローパラメータキーの圧縮表現に従ってノード間で分担されることを特徴とする。請求項１７に記載の通り、本ネットワークは、ネットワークの少なくとも２つのノードが調整手段として動作することが可能であり、モニタリングプローブのモニタリング活動を調整する責任が、フローパラメータキーの圧縮表現に従ってノード間で分担されることを特徴とする。
【００１３】
本発明によって認識されたこととして、集中型調整ユニットを必要とせずに、複数の測定ポイントの調整が可能である。集中型調整ユニットの代わりに、ネットワークの少なくとも２つのノードが調整手段として動作することが可能である。特に、モニタリングプローブのモニタリング活動を調整する責任が、フローパラメータキーの圧縮表現に従ってノード間で分担される。このようなノード間の分担により、モニタリングメカニズムのよりローカルな調整が可能となるため、集中型調整ユニットの場合に必要なモニタリングトラフィックが低減される。
【００１４】
本発明によれば、リソースおよびパフォーマンスの要求を低減した簡易なモニタリングメカニズムが提供される。
【００１５】
本発明は、集中型調整ユニットを必要とせずに、複数の測定プローブまたはポイントの調整が可能な解決法を提供する。好ましくは、特定のトラフィックフローをモニタリングする責任が単一のプローブに割り当てられることにより、プローブを通るすべてのフローが１回だけモニタされる。このため、明示的に要求されない限り、同一フローに対応する重複したレポートやメッセージがプローブによってエクスポートされることがない。
【００１６】
本発明の好ましい実施形態において、ネットワークの確実なパフォーマンスのために、コンテンツベースのアドレシングがネットワーク内で使用されてもよい。また、ノード障害および新規ノード加入の透過的な処理がネットワーク内で使用されてもよい。
【００１７】
好ましくは、ノードはピアツーピアシステムに属してもよい。この場合、モニタリング調整インフラストラクチャは、ノードのピアツーピアネットワークを活用する。ノードは、測定やモニタリング作業を調整する責任を分担する。
【００１８】
好ましくは、プローブもまた、あるピアツーピアシステムまたは同じピアツーピアシステムに属してもよい。別法として、プローブは、ピアツーピアシステムに接続されてもよい。これにより、対応するネットワークは、モニタリングプローブおよび調整作業を実施するだけのノードの両方を含んでもよい。
【００１９】
本発明において、特別のピアツーピアシステムや技術は不要であり、好ましくは、例えば分散ハッシュテーブル（Distributed Hash Table, ＤＨＴ）の場合のようなコンテンツベースのアドレシングと、ノード障害および新規ノード加入の透過的な処理を実現するプロトコルを用いることができる。
【００２０】
本発明によるネットワーク内のトラフィックをモニタリングする方法の好ましい実施形態において、新しいフローの検出後、少なくとも１つのプローブが、そのフローを識別するフローの１つ以上のフィールドのハッシュ値を計算する。すなわち、このようなハッシュ値は、フローパラメータキーの圧縮表現を提供することが可能である。
【００２１】
好ましくは、ハッシュは、ＩＰソースおよび宛先アドレス、プロトコルタイプ、ならびにソースおよび宛先ポートからなるフロー５−タプルとしてもよい。これにより、フローの圧縮表現が簡単に得られる。
【００２２】
ハッシュ値を計算した後、プローブは、フローのモニタリングの調整を担当することになる担当ノードのアドレスを取得するために、計算したハッシュ値のコンテンツベースのルックアップを実行してもよい。担当ノードのアドレスを取得した後、プローブは、フローの所定のデータタイプおよび／またはフローの記述を含むメッセージを担当ノードへ送信してもよい。このようなメッセージは、プローブおよび／またはモニタリングリソースの状態または利用可能性に関するレポートまたはデータをさらに含んでもよい。データは、利用可能メモリ、帯域幅、ＣＰＵサイクル、ＣＰＵ利用率および／またはタイムスタンプを含んでもよい。モニタリング活動が、フローを観測する入口および出口プローブの情報を必要とする場合、このようなタイプスタンプがメッセージに含まれることにより、ノードは、フローが通る最後および最初の測定ポイントまたはプローブを知ることが可能となる。
【００２３】
１つまたは複数のプローブからメッセージを受信した後、担当ノードは、フローをモニタリングする責任を１つの適当なプローブに割り当てる。担当ノードによる割当のこのような決定は、レポートおよび／またはデータおよび／またはローカルな情報および／またはユーザにより指定されたポリシーに基づいてもよい。決定がローカルな情報のみに基づいて行われることが可能なので、グローバルに最適な選択が達成されない可能性がある。しかし、さまざまなローカルポリシーを採用可能である。
【００２４】
決定をした後、ノードは、選択されたプローブに対して、フローのモニタリングを開始するように通知すればよい。
【００２５】
さらに好ましい実施形態において、メッセージは、複数の検出されたフローのデータタイプおよび／または記述を含んでもよい。これにより、１つのプローブが、複数のフローに対するモニタリングポイントとして動作することができる。
【００２６】
本発明によれば、ユーザにより指定されたポリシーに従って、複数のプローブ間でモニタリング作業の負荷を分散することができる。ポリシーは、例えばＣＰＵ利用率、メモリ使用量等の、各プローブ上で利用可能なリソースのようなメトリックを考慮してもよい。本発明の解決法は、好ましくは従来のピアツーピア技術を活用することにより、特にコンテンツベースのアドレシング、耐障害性および負荷分散という特徴に関して、上記の結果を達成する。
【００２７】
本発明は、ネットワーク内の各フローがただ１つの測定ポイントによってモニタリングされることを保証するために、プローブのセットを調整する分散型の解決法を提供する。この解決法は、耐障害性があり、自己適応的に測定を調整し、単一障害点はない。また、本発明は、ローカルに最適な基準に従って、リソース利用可能性を考慮に入れることにより、測定作業を割り当てることが可能なフレームワークを提供する。
【００２８】
本発明によれば、スケーラブルで耐障害性のある測定調整のための解決法が提供される。これにより、複数の測定ポイントまたはプローブが、プローブを通るすべてのフローを１回だけモニタリングすることが可能となる。本発明は、冗長なフローレポートのエクスポートおよび生成を回避することにより、モニタリングリソースの利用の最適化を行うので、モニタリングシステムをより大きいトラフィック量および大規模なネットワークにスケールすることができる。他方、モニタリングデータの整合性が保証される。いくつかの既知のアプリケーション（例えば、確率的データサマリに基づくものや単に集計カウンタに基づくもの）は、同一フローの複数の測定値の間を区別することができない。重複する測定値が存在すると、同一イベントを複数回計上することになるため、誤った結果を生じる可能性がある。これは、さまざまなホストおよびポートへパケットを送信するソースアドレスを探索するスキャンディテクタを考えてみればよい。同じパケットが複数回測定されると、通常のトラフィックソースがスキャナとして標識されてしまい、ブラックリストに登録されたり、遮断されたりすることが起こり得る。
【００２９】
従来技術に比べて、本発明には多くの利点がある。集中型の調整による解決法に比べて、より高速な応答が保証される。というのは、接続状態の変化後に、新しいモニタリングコンフィグレーションの大規模な計算をする必要がないからである。また、単一障害点はなく、スケーラビリティははるかに高く、より多くのノードをピアツーピアネットワークに動的に追加することによってインフラストラクチャを容易に拡張することができる。エピデミックプロトコルに基づく分散型アプローチに比べて、より高い精度、より少ないオーバーヘッド、およびスケーラビリティが可能となる。というのは、確率的構造が関与せず、新たなサマリの連続的な再ブロードキャストは不要であり、重大なスケーラビリティ上の問題を有することで知られているエピデミックプロトコルが回避されるからである。
【００３０】
本発明を好ましい態様で実施するにはいくつもの可能性がある。このためには、一方で請求項１に従属する諸請求項を参照しつつ、他方で図面により例示された本発明の好ましい実施形態についての以下の説明を参照されたい。図面を用いて本発明の好ましい実施形態を説明する際には、本発明の教示による好ましい実施形態一般およびその変形例について説明する。
【図面の簡単な説明】
【００３１】
【図１】本発明によるネットワーク構造の好ましい実施形態を例示する図である。
【発明を実施するための形態】
【００３２】
好ましい実施形態によれば、本発明は、トラフィックフローがプローブによってちょうど１回だけモニタリングされることを保証すると同時に、ローカルな決定のみに基づいてモニタリングリソースを最適に割り当てるために、多数のモニタリングプローブＰの活動を調整する方法からなる。
【００３３】
モニタリング調整インフラストラクチャは、測定作業を調整する責任を分担するランデブーポイント（Rendez-vous Point）ＲＰと呼ばれるノードＲのピアツーピアネットワークを活用する。このようなネットワークは、モニタリングプローブＰおよび調整作業を実施するだけのノードＲの両方を含むことができる。本発明において、特別のピアツーピア技術は仮定されず、分散ハッシュテーブルの場合のようなコンテンツベースのアドレシングと、ノード障害および新規ノード加入の透過的な処理のメカニズムを実現するプロトコルを用いることができる。
【００３４】
図１は、本発明によるネットワークアーキテクチャの好ましい実施形態を示している。ピアツーピアランデブーアーキテクチャが示されており、番号はアクションの順番を表し、Ｒはランデブーポイントまたはノードを表し、Ｐはプローブを表す。プローブＰからノードＲ７への線はフロー識別子情報を表し、ノードＲ７からプローブＰへの線はモニタリング命令を表す。
【００３５】
モニタリングシステムのノードＲは、ピアツーピアシステムとして組織される。プローブＰは、このピアツーピアシステムに属する必要はないが、このピアツーピアシステムへのコネクションを有することができる。しかし、好ましい実施形態では、プローブＰはピアツーピアシステムに属する。
【００３６】
新しいフローがネットワークに入ると、それを捕捉した測定プローブＰはそれぞれ、そのフローを識別するフィールドのハッシュ値を計算する。例えば、ハッシュ値は、ソースおよび宛先ＩＰアドレス、プロトコルタイプ、ならびにソースおよび宛先ポートからなるフロー５−タプルである。これにより、ＤＨＴ（分散ハッシュテーブル）のハッシュ空間内のキーの識別子が得られる。
【００３７】
次に、プローブＰは、そのキーに対するコンテンツベースのルックアップを実行することにより、当該フローのモニタリングの調整を担当することになるノードＲ７のアドレスを取得する。次に、プローブＰは、フローの記述と、プローブの現在利用可能なモニタリングリソース（例えば、メモリ、帯域幅およびＣＰＵサイクル）に関するレポートとを含むメッセージを当該ノードＲ７へ送信する。これらのステップは、図１では、ステップ番号１および２で表されている。
【００３８】
ネットワークを通るフローのエンドツーエンド遅延は限られているので、それぞれのＲＰまたはノードＲは、有限のタイムスロット内で、新しいフローをモニタリングすることが可能なすべてのプローブからレポートを受信することになる。報告されたフローの特徴および利用可能なリソースに基づいて、ＲＰまたはノードＲは、担当の測定ポイントまたはプローブＰを選択する。決定がローカルな情報のみに基づいて行われるので、グローバルに最適な選択は達成できない。しかし、さまざまなローカルポリシーを採用可能である。周知のメモリ割当ストラテジの分野からいくつかの技術を援用することができる。可能なポリシーの例として以下のものがある。
・ベストフィット（Best fit, 当該フローをモニタリングするために利用可能なちょうど十分な量のリソースを有するプローブを選択する）
・ワーストフィット（Worst fit, 当該フローをモニタリングするために利用可能な最大量のリソースを有するプローブを選択する）
・ファーストフィット（First fit, 当該フローをモニタリングするために利用可能な十分な量のリソースを有する最初のプローブを選択する）
【００３９】
決定をした後、ＲＰまたはノードＲは、選択されたプローブＰに対して、フローのモニタリングを開始するように通知すればよい。なお、アプリケーションによって必要とされる場合には、複数の測定ポイントまたはプローブが選択されてもよい。
【００４０】
さらに、この方式は、ルーティング変更を処理することも可能である。フローの経路が変化する場合、そのフローはもはやその担当プローブを通って流れなくなる可能性がある。その時点で、フローは、残りの非担当プローブ、すなわち、新しいプローブのセットを通ることになる可能性がある。この場合のメカニズムも同様である。すなわち、新たなプローブが「新しい」フローの到着をＲＰまたはノードＲに報告し、ＲＰまたはノードＲが、従来のプローブおよび新しいプローブのセットのうちから担当プローブを選択する。変化の結果として、フローがもはやどのプローブも通らなくなる場合、ＲＰまたはノードＲはそのフローを終了したものと分類し、そのフローに関連する状態をプローブおよび自分自身の両方から削除することになる。
【００４１】
すなわち、本発明の解決法は、ルーティング変更によるハンドオーバーのモニタリングを処理することも可能である。フローが、そのフローをモニタリングしているプローブ（プローブＡとする）を通らなくなり、新しいプローブ（プローブＢ）を通って流れ始める場合、Ｂは、見かけ上新しいフローを観測していることについて、対応するＲＰまたはノードＲに通知する。ＲＰまたはノードＲは、このフローを既存のフローとして認識し、Ａに対して、そのフローがもはやＡを通って流れていないことを確認した後、Ｂに対して、そのフローのモニタリングを開始するよう命令することにより、ハンドオーバーを完了する。
【００４２】
本発明が提案する方式に対する簡単な最適化として、相異なるフローに関連するデータを単一のレポートにまとめることにより、適時性を犠牲にする代わりにメッセージ数を削減することが挙げられる。他の最適化も可能である。もちろん、このような調節の選択は、実施状況の個々の要求条件に従ってなされなければならない。
【００４３】
最後に注意すべき点であるが、モニタリングアプリケーションがフローごとに重複したレポートを明示的に要求する場合、例えば、ネットワークの入口および出口ポイントにおけるフローに関する統計を測定する場合にも、本方式はこれをサポート可能である。すなわち、システムは不要な重複測定／エクスポートを防止するが、明示的に必要とされる場合にはそれをサポートすることができる。
【００４４】
本発明によれば、各プローブ上でのモニタリング負荷を、現在のリソース利用率に従って分散させることができ、重複フローモニタリングを防止した簡易で、スケーラブルで、耐障害性のあるインフラストラクチャが提供される。
【００４５】
本発明の重要な側面は以下の通りである。
・基礎となるピアツーピア技術のため、調整インフラストラクチャはスケーラブルで耐障害性がある。より多くのリソースが必要とされる場合、測定インフラストラクチャにとって透過的な形で新たなノードを追加することができる。
・トラフィック行列およびルーティング状態に関する追加的情報は不要である。決定は、プローブによって送信される情報に基づいてローカルに行われる。
・メカニズムは、他の提案されているアプローチよりもはるかに単純であり、関与するすべてのノードに対して、はるかに少ないパフォーマンスしか要求しない。これにより、スケーラビリティが実現されるとともに、市販の汎用ハードウェア（すなわちＰＣ）を用いてこのようなメカニズムを構成することができる。
【００４６】
上記の説明および添付図面の記載に基づいて、当業者は本発明の多くの変形例および他の実施形態に想到し得るであろう。したがって、本発明は、開示した具体的実施形態に限定されるものではなく、変形例および他の実施形態も、添付の特許請求の範囲内に含まれるものと解すべきである。本明細書では特定の用語を用いているが、それらは総称的・説明的意味でのみ用いられており、限定を目的としたものではない。
【図１】
0005451889.tif 000002