JP3709209B2 - ネットワーク解析方法 - Google Patents

Description

【０００１】
【産業上の利用分野】
本発明は、それぞれ複数のノードを備えた複数のサブネットワークからなる形式のネットワークに関連して使用されるネットワーク解析方法に関する。
【０００２】
【従来の技術】
本発明のネットワーク解析方法は特に、構成要素のサブネットワークが、７層OSI基準モデルのレベル２で動作するブリッジにより相互接続された論理セグメントであるネットワークに適用されるものである。しかしながら、このネットワーク解析方法は、OSI基準モデルのレベル３で動作するルータ或いはゲートウェイにより相互接続された「IP」サブネットワークを備えたインターネット（Internet）のような他のネットワークを備えた適当な環境下においても使用することができる。
【０００３】
【発明が解決しようとする課題】
ネットワーク監視システムがより高度になり広範囲にわたるものになるにつれて、ネットワークオペレータが、そのような監視システムにより与えられるネットワーク動作における大量のデータの中から有意のデータを識別しなければならないという問題が増えてくる。これは、対象となるネットワークが幾つかのサブネットワークからなり、所定のノードが全てのサブネットワーク全体にわたるグローバル（大域）サーバとして動作している場合には特にそうである。なぜならそのような場合には、各々のサブネットワークで実際に何が起きているのかを知ることが困難だからである。
【０００４】
本発明の課題は、サブネットワークレベルにおけるネットワークの動作の評価を容易にするネットワーク解析方法を提供することである。
【０００５】
【課題を解決するための手段】
この課題を解決するため、一つの側面において本発明は、ローカル（局所）サーバとして動作するノード、すなわち主に特定の１つのサブネットワークを取り扱うノードを識別するよう機能するネットワーク解析方法を提供する。より詳細には、この側面において本発明は、それぞれ複数のノードを備えた複数のサブネットワークからなる形式のネットワークに関連して使用されるネットワーク解析方法であって、
（１）ネットワークを監視して、ノード間のトラヒックにより判別されたノード間の連係を表すトラヒックデータを収集して蓄積するステップと、
（２）グローバルサーバとして動作すると識別されたノードに関連したトラヒックを優先的に除去することによりトラヒックデータを処理し、残りのトラヒックを使用してローカルサーバとして動作するノードを識別するステップとからなる方法を提供する。
【０００６】
グローバルサーバトラヒックの優先的な除去は、ローカルサーバの正体を効率的に明らかにし、それらを識別することを可能にする。
【０００７】
本方法のステップ（２）は好ましくは、トラヒックデータを検査して、前記ノードの中から全てのグローバルサーバ候補を識別することを含む。この場合にグローバルサーバ候補とは、前記サブネットワークのいずれかに対する連係が、全てのノードに対するその総連係の第１の所定の割合（一般に50％）よりも少ないノードである。そして、
−前記グローバルサーバ候補が識別された場合には、総連係が最多のグローバルサーバ候補を識別し、これに関連するトラヒックをトラヒックデータから除去し、そしてステップ（２）の開始に戻り、このように修正されたトラヒックデータを使用して当該ステップを繰り返し、
−そのようなグローバルサーバ候補が識別されなかった場合には、トラヒックデータを検査して、前記ノードの中から全てのローカルサーバ候補を識別する。この場合にローカルサーバ候補とは、それに対する最多の連係を有するサブネットワークについて、その最多連係がそのローカルサーバ候補の総連係の第２の所定の割合（やはり一般的に50％）以上であるノードである。また、
−前記ローカルサーバ候補が識別された場合には、総連係が最多のローカルサーバ候補を識別し（好適には最多総連係であるが、代替的には何れか１つのサブネットワークに対する最多連係でもよい）、この候補をローカルサーバとして記録し、これに関連するトラヒックをトラヒックデータから除去し、ステップ（２）の開始に戻り、このように修正されたトラヒックデータを使用して当該ステップを繰り返し、
−前記ローカルサーバ候補が識別されなかった場合には、ステップ（２）から抜ける。
【０００８】
あるノードの他の関連するノードとの連係は一般に、関連するノード数、関連するノードとのトラヒックに含まれるフレーム数、関連するノードとのトラヒックに含まれるバイト数の中の、少なくとも１つによって測定される。例えば連係は、関連するノード数によって測定されうるが、これと共に、比較すべき２つの連係値が同じであるという状況を解決するためにトラヒック量の測定（フレーム／バイト）を使用することができる。
【０００９】
ノードがサーバとして動作しているかどうかに関する判断は、関連するトラヒック連係に完全に基づいて行うことができるが、好ましくは、ノードが関連する個別のトラヒック項目に関してサーバ役として動作するか或いはクライアント役として動作するかを示す役割情報の収集を可能にするような仕方で、ネットワークの監視が実行される。この場合、ステップ（２）におけるグローバル或いはローカルサーバとしてのノードの識別は、ノードがクライアントとして動作することが前記役割情報により示されたトラヒックを参照することなしに実行される。役割情報は例えば、一対のノード間を通過するトラヒックに関連したノード端点の「周知ポート（well known port）」状態を基礎として導き出される。この対のノードの一方のノードはサーバ役で動作し、他方のノードはクライアント役で動作すると識別され、前記一方のノードの端点は周知ポートとなるが、他方の端点はそうではない。
【００１０】
ローカルサーバが識別されたならば、次いで更に解析を行うことが可能となり、どの程度ネットワーク性能が改善できるかを決定することができる。このようにして、好適には主たる方法のステップ（２）において識別されたローカルサーバの少なくとも１つについて、そのローカルサーバに対して最適なサブネットワークに関する決定がなされるが、この決定は、対象とするローカルサーバを各サブネットワーク上で観念的に順次位置決めすることと、ローカルサーバのそのような各位置毎に、現在の観念的な位置にあるローカルサーバと関連するサブネットワーク間のトラヒックの測定量を与える所定の最適位置関数を評価することを含む。このような決定は更に、前記最適サブネットワークとして、前記関数の評価により、サブネットワーク間の前記トラヒックに関して最小値が示されるサブネットワークを識別することを含む。簡単化と高速化のため、最適位置関数は好ましくは、対象とするローカルサーバとの連係を有し、ローカルサーバの現在の観念的な位置に対応するサブネットワーク以外のサブネットワーク上に位置するノードのカウントとされる。
【００１１】
ローカルサーバに対する最適サブネットワークが決定されたならば、好適にはまた、このローカルサーバが前記最適サブネットワーク上に位置している場合には、それがサーバとして連係を有しているノードの何れかを、前記最適サブネットワークに移動すべきかどうかに関しての決定もなされる。この決定は、そのノードとローカルサーバとの間の連係が、実質的にそのノードの総連係の半分以上であるかどうかを、各ノード毎に検査することを含んでいる。
【００１２】
ローカルサーバが識別された場合に実行可能となる他の有用な解析は、ローカルサーバとそのクライアントノードをワークグループ中に関連付けることである。この目的のために、各ローカルサーバは、ローカルサーバのグループ内で降順の連係で順番に取り上げられ、そのような各サーバ毎に、
（ｉ）対象とするローカルサーバが、前記順番中で高次のローカルサーバに関して生成された他のワークグループに既に割り当てられていなければ、それについてのワークグループがそれぞれに生成され、
（ii）対象とするローカルサーバについての前記それぞれのワークグループが（ｉ）で既に生成されている場合には、サーバがそのワークグループに割り当てられ、そして
（iii）ローカルサーバへの連係が実質的にそのノードの総連係の少なくとも半分である全てのノードが、ローカルサーバとして同じワークグループに割り当てられる。
【００１３】
１つのそのようなサーバが、そのような他のサーバに十分にリンクされたクライアントである場合には、ワークグループは１つ以上のローカルサーバを含むことができることが理解されよう。
【００１４】
このようにして確立されたワークグループを使用して、１つのサブネットワークを２つのサブネットワークに分割する価値があるかどうかに関しての決定を行うことができるが、この決定は、
（ａ）ワークグループを対象とするサブネットワークに関してだけ考慮した場合に、もはやその中に含めることが適当でない全てのノードをワークグループから除去することにより、前記ワークグループ又は対象とするサブネットワーク上に位置するローカルサーバに関して生成された各ワークグループを切り詰めるステップと、
（ｂ）ノードがサブネットワークに関連したワークグループ中に未だない場合に、対象とするサブネットワークの各ノード毎に更なるワークグループをそれぞれ形成するステップと、
（ｃ）対象とするサブネットワークに関連するワークグループを、そのようなワークグループが２つだけ残るように合併するステップと、及び
（ｄ）ステップ（ｃ）の後に残った２つのワークグループ間のトラヒック量を、そのようなワークグループの各々に関連した総トラヒックと比較することにより、サブネットワークを分割する価値があるかどうかを決定するステップとを含む。
【００１５】
ローカルサーバの識別に続いて実行される解析タスクは、もちろん、好ましくは主たる方法のステップ（１）で収集されたトラヒックデータを使用して実行されるが、しかし全てのグローバルサーバトラヒックは除去される。しかしながら、全てのグローバルサーバトラヒックが除去されない場合でも、解析タスクは一般に、依然としてある程度の有用な情報を生成する。
【００１６】
本発明の他の側面によれば、それぞれ複数のノードを備えた複数のサブネットワークからなる形式のネットワークに関連して使用されるネットワーク解析方法が提供され、この方法は、
（１）ネットワークを監視して、ノード間のトラヒックにより判断されたノード間の連係を示すトラヒックデータを収集して蓄積するステップと、
（２）トラヒックデータを処理してローカルサーバとして動作するノードを識別するステップと、及び
（３）ステップ（２）で識別されたローカルサーバの少なくとも１つに対して、そのローカルサーバに対する最適なサブネットワークを決定し、この決定が、対象とするローカルサーバを各サブネットワーク上で観念的に順次位置決めすることと、ローカルサーバのそのような各位置毎に、現在の観念的な位置にあるローカルサーバと関連するサブネットワーク間のトラヒックの測定量を与える所定の最適位置関数を評価することを含み、前記決定が更に、前記最適サブネットワークとして、前記関数の評価により、サブネットワーク間の前記トラヒックに関して最小値が示されるサブネットワークを識別するステップとを含むものである。
【００１７】
本発明の更なる側面によれば、論理セグメントを２つのそのようなセグメントに分割する価値があるか否かを決定するために、複数のノードを備えた論理セグメントを有するネットワークに関連して使用されるネットワーク解析方法が提供され、この方法は、
（１）論理セグメントを監視して、ノード間のトラヒックにより判断されたセグメントのノード間の連係を表すトラヒックデータを収集して蓄積するステップと、
（２）セグメントトラヒックデータを解析するための第１の反復処理を実行して、前記ノードをそれぞれローカルサーバと１つ以上のクライアントノードを備えたワークグループに分類し、この第１の反復処理の各反復が、最多のトラヒック連係を有するノードをそれぞれの新しいワークグループにローカルサーバとして割り当て、更にクライアントノードとして、ローカルサーバノードへの連係が対象とするノードの総連係の所定の割合よりも大きなノードを同じワークグループに割り当て、新しいワークグループに関連したトラヒックを除去してトラヒックデータを修正することを含むステップと、
（３）ステップ（２）で識別されたワークグループを合併して２つのワークグループを残す第２の反復処理を実行し、この第２の反復処理の各反復が、関連するトラヒックの量が最小であるワークグループを識別し、それを最多の連係を有するワークグループと合併することを含むステップと、
（４）ステップ（３）の後に残った２つのワークグループの間のトラヒックの量をそのようなワークグループのそれぞれに関連した総トラヒックと比較することにより、論理セグメントが分割に値するかどうかを決定するステップからなる。
【００１８】
以下では本発明によるネットワーク解析方法を、非限定的な実施例により、添付図面を参照して説明する。
【００１９】
【実施例】
図１は、それぞれが複数のノードＮを備えた４つの論理セグメント（サブネットワーク）X1, X2, X3及びX4からなるネットワークの例を示しており、特定の論理セグメントに関連するノードは一緒になってクラスタを形成している。論理セグメントは、７層OSI基準モデルのレベル２において動作するブリッジの形態の橋渡し（spanning）デバイスにより相互接続されており、各ブリッジは図１のクラスタ図において、それが相互接続する２つの論理セグメントの各々における対応するノードの形態で表されている。ブリッジによる論理セグメントの相互接続のパターンは、本発明の記述のためには重要でない。図１の例示的なネットワークは、ブリッジされたイーサネットから構成することができ、各々のノードは、ネットワークの全ての論理セグメントにわたって有効なイーサネットアドレスにより識別される。ノードＮは相互の間でトラヒックをソースし及びシンクするが、このトラヒックは、ソースノードアドレスと宛先ノードアドレスの両者と、送信すべきデータとを運ぶ個別のメッセージパケットの形態を有する。
【００２０】
図１のネットワークは、本発明のネットワーク解析方法の説明の便を図るために、以下に用いられる例示的なトラヒック分布図の基礎として使用される。以下の説明においては、どのノードがどの論理セグメントに関連するかについては、ネットワークのトポロジーは既知であると仮定する。
【００２１】
図２は、所定の期間にわたって図１のネットワークを横切るトラヒックを示し、２つのノード間のメッセージパケットの伝送は、ノードの間に描かれた線により表されている。線の太さは、トラヒック量の概略を示す。本例においては、トラヒックフローは、各パケットに関連する層２のソースアドレス及び宛先アドレスの検査により導き出される。層２のアドレスはネットワーク全体にわたって有効であるので、層２のアドレスの検査により、メッセージパケットがネットワークを横切る経路とは無関係に、そのパケットの真のソースノード及び宛先ノードが与えられる。
【００２２】
トラヒックの線が詰まっているため図２は明確さを欠くにも拘わらず、幾つかのノードはネットワークの他のノードと大量に通信していることが判る。例えば、論理セグメントX1上のノードN1とN2はネットワークの事実上全ての他のノードと通信しているように見えるが、このことから、これらのノードはネットワークを監視或いは制御する上で何らかの全体的な役割を有することを合理的に推論することができる。
【００２３】
図２の形態の図は、ネットワークオペレータに対し、ネットワーク上で何が起きているかに関して一般的な感覚を与えるが、それらはネットワークの挙動についての詳細な精査を可能とするものではなく、誤解しやすいものである。
【００２４】
以下に説明するネットワーク解析方法は、ネットワークの特性に関する有用な情報を提供し、またその性能がどの程度改善されるかという観点から、図２の形態の図を生成するのに使用されるものと同様なトラヒックデータを解析する。
【００２５】
ここで説明されるネットワーク解析方法の後ろ楯となっている概略の考えは、ネットワークの性能の主たる改善は、一般に通信のグローバルパターンを有するノードを再配置することからは得られない（即ち、それらの通信は基本的に１つの論理セグメントとのものではない）が、基本的に１つの論理セグメント（ノード自身が位置しているセグメントである必要ではないが）に通信しているノードに関連してネットワークを修正することから得られるということである。
【００２６】
したがって、重要な解析タスクは、基本的にグローバルな仕方で通信するノード（「グローバルサーバ」）を、基本的に１つのセグメントだけと通信しそのセグメントに関して主たる通信者であるノード（「ローカルサーバ」）から分割することである。主として１つのセグメントだけと通信するノードは多数存在するであろうが、それらのノードの幾つかだけがサーバのような役割を有していることが理解されよう。そのようなローカルサーバが識別されたならば、次いでここに説明するネットワーク解析方法が使用され、それらのローカルサーバのいずれかを他の論理セグメントに移動すべきかどうかに関して、またセグメントを２つの関連するローカルサーバの間で分割する価値があるかどうかに関しての示唆が行われる。
【００２７】
図３は、以下に説明する本発明の実施にあたって使用される主プログラム項目及び主データ構造を示す。より詳細には、３つの主プログラム構成要素が用意されており、それらは抽出サーバ（Extract-Servers）プログラム10、移動示唆（Move-Suggestion）プログラム11、及び分割示唆（Split-Suggestion）プログラム12である。
【００２８】
抽出サーバプログラム10は、トラヒックデータ及びネットワークの論理配置上のデータの双方を利用することができる。トラヒックデータは、特定の期間にわたるネットワーク上のノードからノードへのトラヒックを特徴付ける１組のトラヒック要素22の形態をしている。ネットワークの論理配置上のデータは、セグメント20のリスト及びノード21のリストの形態をしており、各リストはセグメントとノードの間の関連情報を含んでいる。抽出サーバプログラム10は、トラヒック要素22の中に現れるトラヒックデータを解析し、グローバルサーバリスト23及びローカルサーバリスト24を生成する。
【００２９】
移動示唆プログラム11は、プログラム項目である配置サーバ（Place-Server）13及び配置クライアント（Place-Client）14を含んでいる。移動示唆プログラム11は、プログラム10により識別されたローカルサーバの各々を順番に調べて、ローカルサーバを他のセグメントに移動するのが有利であるかどうか、またそうであれば、そのクライアントノード（即ち、それが通信するノード）のいずれかを同じセグメントに移動するのも有利であるかどうかを決定する。この解析を基礎として、プログラム11は、移動示唆のリスト（ノード移動リスト25）を生成する。プログラム11はまた、ワークグループのリスト（ワークグループリスト26）をも生成し、各々のワークグループは、ローカルサーバと、存在するならばそれに密接に連係したクライアントノードを含む。
【００３０】
分割示唆プログラム12は、プログラム要素である切り詰めワークグループ（Prune-Workgroup）15、合併ワークグループ（Merge-Workgroup）16、及び分割決定（Split-Decision）17を含んでいる。プログラム12は、ネットワークの各論理セグメントを順番に調べて、ワークグループリスト26の中に列記されたワークグループを基礎として使用して、全てのノードを２つのワークグループにグループ分けする。プログラム12は次いで、セグメントを２つのワークグループに分割する価値があるかをどうかを決定し、またそれを行うことが有利であると決定した場合には、セグメント分割リスト27の中の分割示唆に入る。
【００３１】
以下で明らかとなるように、プログラム10, 11及び12（特にグローバル及びローカルサーバを識別する際のプログラム10）の複雑さのレベルは、トラヒックデータ（トラヒック要素22）により与えられる詳細さの程度に依存している。かくしてトラヒックデータは、単純にレベル２のパケット情報に基づいたものとすることができる。即ち、パケットのデータ部分の中に含まれている高次レベル構造を調べるための試行を行うことなしに、ネットワークを横切って送られるメッセージパケットのソースノードアドレス及び宛先ノードアドレスに基づいたものとすることができる。代替的には、トラヒックデータは、特定のノードに関して送受信されるパケットが、サーバ役或いはクライアント役で動作するノードとそのようにするかの指示を与える観点から、そのような高次レベルの構造を考慮することができる。トラヒックデータのこのより詳細な形態がない場合には、抽出サーバログラム10は、単純にトラヒック連係の大きさを基礎として、どのノードがサーバであるかの判断を行わなければならない。
【００３２】
どのようなレベルのトラヒックデータが要求されるにせよ、当業者にとっては適切なネットワーク監視システムが明らかである。１つのそのようなシステムは、例えば、ランダムにパケットをサンプリングすることに基づく本出願人の欧州特許明細書EP-A-0 480 555号に説明されている（どの程度のデータがサンプリングされたパケットの各々に捕捉されるかに関しての詳細は、その明細書に説明されているものと変更する必要があるかもしれないが、そのような変更は、当業者にとっては日常茶飯事であることが判る）。監視点において受信されたパケットのそれぞれを記録するものを含む、他の監視システムを使用することもできる。
【００３３】
説明を簡単にするために、メッセージデータの高次レベル構造の検査にたよることなしに、トラヒックデータがレベル２のパケット情報に基づいている場合について、プログラム10, 11及び12の動作を最初に説明する。その後に、高次構造情報について可能な調整について説明する。
【００３４】
既に示したように、プログラム10, 11, 12により解析されるトラヒックデータは、１組のトラヒック要素22を含んでいる。図４Ａは、トラヒックデータがレベル２のパケット情報のみに基づいている場合について、トラヒック要素22の構造を示す。図から判るように、各トラヒック要素は４つのフィールド、即ち、ノード１識別性フィールド、ノード２識別性フィールド、総トラヒックフィールド、及び「イネーブル」フラグフィールドを含んでいる。トラヒック要素22が図４Ａの形態を有している場合には、ネットワーク内の通信ノードの各対毎にそれぞれのトラヒック要素22が存在し、関与しているノードの識別性は、ノード１及びノード２の識別性フィールドに記録される。このようなトラヒック要素22の各々は、対象となるノードの間を双方向に送信される総トラヒックを（例えば、パケット数及び／又はバイト数によって）記録するのに使用される。
【００３５】
図４Ａの各トラヒック要素22のイネーブルフラグフィールドにより、プログラム10, 11, 12により特定の時点において考慮されるトラヒックデータから、その要素を包含するか或いは除外するかについてマーキングすることが可能となる。規則として、トラヒック要素22のイネーブルフラグがセットされているときには、それは現在の関連するトラヒックデータに含まれるが、一方フラグがリセットされているときには、その要素は除外される。最初に（プログラム10の開始にあたり）、トラヒックデータを構成する全てのトラヒック要素のイネーブルフラグはセット状態にある。
【００３６】
次に抽出サーバプログラム10について検討すると、このプログラムは図５にフローチャートの形態で示されており、ステップ30から39を含んでいる。開始にあたり、プログラム10はトラヒック要素22により表されるトラヒックデータを検査し、全てのアクティブノード、即ちトラヒックの送信或いは受信を行うノードのリストを生成する（ステップ30）。実際にアクティブノードがない場合には（ステップ31で検査される）、プログラム10は直ちに終了する。しかしながら、一般的にそうであるように、アクティブノードが存在することをトラヒックデータが示す場合には、プログラム10は次いでステップ32に進み、アクティブノードのリストの中から、グローバルサーバとして動作するノードの存在を探す。
【００３７】
ここでは、「グローバルサーバ」は、ネットワークの論理セグメントX1-X4のいずれかとのトラヒック連係が、そのノードの全てのセグメントとの総連係の所定の割合よりも少ないノードを意味する。一般的に、この所定の割合は50％程度である。換言すれば、グローバルサーバは、ネットワークのいかなる特定の論理セグメントとも優越的な連係を持たないノードである。ノードがグローバルサーバであるかどうかに関しての評価を行う場合に使用されるトラヒック連係の測定量は、好ましくは同等ノードの数、即ち対象とするノードが通信するノードの数の単純なカウントである。しかしながら、各トラヒック要素22の総トラヒックフィールドが適切な情報を記録することを条件として、各論理セグメントと交換するパケット、フレーム或いはバイトによるトラヒック量の測定を基礎とすることも可能である。
【００３８】
図６は、論理セグメントX1内のグローバルサーバノードN1によるネットワークトラヒックを示す。図から判るように、ノードN1は実質的に全ての他のノードと通信し、その結果、論理セグメントX1からX4のいずれか１つとのその通信は、全てのセグメントを合わせたものとの通信の50％よりも少ない。
【００３９】
ステップ32でアクティブノードリストの中に少なくとも１つのグローバルサーバが見つかったとすると、プログラム10は次にステップ33を実行し、最多の総トラヒック連係を有するアクティブノードリスト中のグローバルサーバを識別する（ここでも、同等ノードカウントにより測定することが好ましいが、２つのグローバルサーバが同じ同等ノードカウントを有する場合には、総トラヒック量を検査する手法を取ることができる）。ステップ33で最もアクティブなグローバルサーバを識別すると、このサーバの識別性は、グローバルサーバリスト23に追加される（ステップ34）。
【００４０】
プログラム10は次にステップ35へ進み、識別されたばかりのサーバがアクティブノードリストから除去され、その関連するトラヒック要素22は、それらの要素の各々においてイネーブルフラグをリセットすることによりディセーブルされる。
【００４１】
ここでプログラムはステップ32に戻り、修正されたトラヒックデータ（即ち、要素22の或るものがディセーブルされたトラヒックデータ）を基礎として、アクティブノードリストの中に何らかのグローバルサーバが存在するかどうかを再度検査する。そうである場合には、ステップ33から35が繰り返される。この処理は、ステップ32の検査により、アクティブノードリスト中にグローバルサーバが識別されなくなるまで継続される。図２のトラヒックの例においては、グローバルサーバが見つからなくなるまで、ステップ33から35が３回反復される。１回目の反復はノードN1をグローバルサーバとして識別し、２回目の反復はノードN2をグローバルサーバとして識別し、３回目の反復はノードN3をグローバルサーバとして識別する。図７に示されるように、これらのグローバルサーバのトラヒック要素がディセーブルされると、残りの要素がトラヒック分布を表すことになる。
【００４２】
ステップ32でグローバルサーバが識別できなかったときには、次いでステップ36が実行されて、アクティブノードリストの中の何らかのローカルサーバの存在が検査される。ここでは、「ローカルサーバ」は、それが最も多くリンクされている論理セグメントとのトラヒック連係が、全てのセグメントとのその総連係の所定の割合（一般的に50％程度）よりも多いノードである。かくして例えば、図７のノードN4, N5, N6及びN7は、検討中のトラヒックについてローカルサーバとして動作する（実際には、図７においてローカルサーバとして動作する多数の他のノードがあるが、これらは説明を簡単にするため参照されていない）。ローカルサーバの検査に使用されるトラヒック連係の測定量は、グローバルサーバの検査と同様に、同等ノードの単純なカウント、或いは実際のトラヒック量の測定とすることができることが判る。また、トラヒック連係の測定量は、ステップ35によるトラヒック要素のディセーブルにより修正されたトラヒックデータを基礎として実行されることが理解される。
【００４３】
アクティブノードリストの中に少なくとも１つのローカルサーバが識別されたとすると、プログラム10は次いでステップ37に進み、最多のトラヒック連係を有するローカルサーバを識別する（好ましくは同等ノードの総数のカウントとして測定され、測定値が同じ場合にはトラヒック量を参照して解決される）。最多のトラヒック連係を有するローカルサーバが識別されたならば、このサーバの識別性がローカルサーバリスト24に追加される（ステップ38）。ステップ35が次いで実行され、識別されたサーバをアクティブノードリストから除去し、その関連するトラヒック要素22をディセーブルする。
【００４４】
その後、プログラム10はステップ32にループして戻り、アクティブノードリスト中の何らかのグローバルサーバの存在を再度検査する（識別されたばかりのローカルサーバに関連するトラヒック要素のディセーブルは、アクティブノードリストの中に新しいグローバルサーバを出現させることがあるが、これは本例のトラヒックではそうでないことが理解されよう）。
【００４５】
グローバル及びローカルサーバの識別は、このようにしてグローバルサーバの優先的な識別により、グローバル或いはローカルサーバが見つからなくなるまで継続される。これにより、プログラムはステップ36からステップ39に抜けて、プログラム10の実行に際してディセーブルされた全てのトラヒック要素22を再度イネーブルする。次いで、プログラム10は終了する。
【００４６】
抽出サーバプログラム10がローカルサーバを識別したならば、移動示唆プログラム11を実行して、各ローカルサーバ毎に最適な論理セグメントX1からX4を確認し、その結果として何れかのローカルサーバをそのクライアントノードの何れかと共に移動すべきか否かを示唆することが可能になる。ローカルサーバを有効に移動できる典型的な状況が図８に示されており、この図は、論理セグメントX3及びX4と、ローカルサーバノードN5と関連する、図７に示されているトラヒックの構成要素を示している。図８から、ローカルサーバノードN5は論理セグメントX3上に位置しているけれども、ノードN5は主として論理セグメントX4と通信していることが判る。ローカルサーバノードN5にとって、論理セグメントX3から論理セグメントX4に移動するのが有利であることは明らかである。移動示唆プログラム11が識別しようとするのは、このタイプの状況である。
【００４７】
図９は、移動示唆プログラム11のフローチャートである。このプログラムは、識別されたグローバルサーバに関連するトラヒック要素22が除去された、収集トラヒックデータについて動作することを意図したものであり、したがってプログラム11の最初のステップ40は、グローバルサーバに関連するトラヒック要素をディセーブルする。それ以降、プログラム11はループ構造に入り、各ローカルサーバが同等カウントサイズの順で順番に検討され（ステップ41）、このループ構造からの出口検査は、処理すべきローカルサーバが残っているかを見て検査するステップ42にある。
【００４８】
各ローカルサーバは、異なる論理セグメントに移動すべきか、或いはそのクライアントノードの何れかを移動すべきかを決定するために、ステップ44から48の処理を受ける。
【００４９】
より詳細には、ステップ44では配置サーバプログラム項目13が実行され、検討しているローカルサーバ（現在の「ターゲット」サーバ）を移動すべきであるかどうかが決定され、全ての移動示唆はノード移動リスト25に配置される。配置サーバプログラム項目13はまた、後続するステップ46でターゲットサーバのクライアントノードの何れかを移動すべきか否かを検査することができるように、ターゲットサーバに対して示唆された移動を観念的に実施する。
【００５０】
ステップ45では、ターゲットサーバがそれまで、より高次のクライアントノードカウントを有するローカルサーバに関して先行する反復ステップ44-48で生成されたワークグループに含まれていない場合には、そのターゲットサーバについて新たなワークグループデータ構造（以下単に「ワークグループ」という）が生成される。ワークグループは、ワークグループリスト26内でリンクされる。各ワークグループは、その生成をもたらしたローカルサーバが位置する論理セグメントに関連すると考えられる。
【００５１】
次にステップ46では、配置クライアントプログラム項目14が実行され、ターゲットサーバのクライアントノードのいずれかをサーバの論理セグメントに移動すべきかどうかが確認される（これはステップ44により与えられる何らかの移動示唆の実施後にサーバが位置するセグメントである）。配置クライアントプログラムにより生成された全てのクライアント移動示唆は、ノード移動リスト25に蓄積され、各々の示唆は一時的に実施される。更に、ターゲットサーバに十分にリンクされた全てのクライアントノード（即ち、そのクライアントの総連係の実質的に少なくとも半分がターゲットサーバとのものである）が、ターゲットサーバとして同じワークグループに配置される。
【００５２】
クライアントノードがその関連するローカルサーバと十分にリンクしているかどうかの評価は、ノードカウントよりもトラヒック量の測定を考察することにより実行できることが理解されよう。
【００５３】
ターゲットサーバの全てのクライアントノードが、それらを有利に移動させることができるかどうかについて確認された後、ターゲットサーバ及びそのクライアントの元のセグメントからの観念上の移動は、関連するセグメント及びノードデータ構造20及び21での適切な動作により逆にされる（ステップ47及び48）。
【００５４】
ローカルサーバリスト24に記録された全てのローカルサーバが、ステップ44から48の処理を受けたならば、移動示唆プログラム項目11のループ構造は、ステップ42で抜け出て、全てのグローバルサーバのトラヒック要素は、プログラム項目11が終了する前に再度イネーブルされる（ステップ49）。
【００５５】
ローカルサーバがプログラム項目11によりそれらのクライアントカウントのサイズの順番に処理される理由は、ステップ45において、ノードのワークグループへの関連付けを可能な限り最大化するためであることに注目すべきである。更に詳細には、より少なくリンクされたローカルサーバを後で処理すると、それらがより多くリンクされたローカルサーバのワークグループの中に既に含まれてしまうようになることが可能である。この場合には、より少なくリンクされたローカルサーバがより多くリンクされたローカルサーバと同じワークグループに含まれるだけでなく、より少なくリンクされたローカルサーバに十分リンクされた、そのより少なくリンクされたローカルサーバのクライアントノードも、より多くリンクされたローカルサーバのワークグループに含まれるようになる。
【００５６】
図10は、移動示唆プログラム11のステップ44において実行される配置サーバプログラム項目13のフローチャートである。配置サーバプログラム13には、特定のターゲットの識別性が通され、次いでそのサーバを異なるセグメントに移動する価値があるか否かの検査に進む。しかしながら予備ステップとして、プログラム13は最初に、そのサーバが実際には容易に移動することができない橋渡しデバイス（ブリッジ／ルータ／ゲートウェイ）であって、プログラム13のためには固定として取り扱うべきか否かを検査する（ステップ50参照）。実際のところステップ50は、何らかの理由により移動不可能であると指定されたノードのリストを確認することに一般化できる。
【００５７】
配置サーバプログラム13は次にステップ51に進み、検討中のサーバに対する最適セグメントを確認する。本例においてはこれは、サーバと同じセグメント上のクライアントは「０」ホップ（hop）カウントを記録するが、異なるセグメント上のクライアントは「１」ホップカウントを記録するということを基礎として動作する、サーバとそのクライアントノードとの間で、最小の総ホップカウントを探すことにより実行される（メッセージをサーバからそのクライアントへ送るために、物理ネットワーク上で実際にどの程度多くのセグメントをホップする必要があるかとは無関係に）。このようにして、サーバは順番に各論理セグメント上に観念的に位置され、対応するホップカウント値が計算される。次いで最小ホップカウントを生成するセグメント位置が、検討中のサーバに対する最適セグメントとして識別される。
【００５８】
最適セグメントを決定するために、上述した単純なホップカウント測定以外の測定を使用できることが理解されよう。適当な測定は、ターゲットサーバとそのサーバの各位置毎のクライアントとの間のトラヒックのセグメント間構成要素に敏感なものである。かくして例えば、他の適当な測定は、サーバの各位置毎に生成されたパケット／フレーム／バイト単位でのセグメント間トラヒック量である。
【００５９】
ターゲットサーバに対する最適セグメント位置が決定されたならば、このセグメントが、ターゲットセグメントの現在のセグメントと異なっているかどうかがステップ52でチェックされる。これらのセグメントが同じである場合には、プログラム13は終了する。しかしながら、最適セグメントがサーバに対する現在のセグメントと異なっているとすると、ステップ53が実行され、そのターゲットサーバが、先に検討されたサーバに関して生成されたワークグループ内のクライアントサーバとして既に固定されているか否かの確認が行われる。既に上述したように、サーバをクライアントとして、より多くリンクされたサーバに十分にリンクさせ、従って後者のワークグループ内に固定することができる。この場合には、より少なくリンクされたサーバは移動不可能であると判断され、プログラム13は、そのサーバに対して移動示唆を行うことなく終了する。
【００６０】
ターゲットサーバが他のサーバのワークグループ内のクライアントとして固定されていない場合には、配置サーバプログラム13のステップ54が実行され、移動示唆がノード移動リスト25に追加される。この示唆は、対象とするサーバ、その現在のセグメント及び提案された新しいセグメントを識別する。この提案された移動もまた、サーバとセグメントデータ構造の適切な修正により一時的に観念的に実行され、サーバが識別されたばかりの最適セグメント上に現存することが示される。その後、プログラム13は終了する。
【００６１】
図11は、移動示唆プログラム11のステップ46において実行される配置クライアントプログラム項目14のフローチャートである。このプログラム14は、移動示唆プログラム11の現在の反復に際して検討されるターゲットサーバの各クライアントノード毎に実行される。
【００６２】
プログラム14の最初の２つのステップ60及び61はそれぞれ、検討中のクライアントノードがワークグループ内で既に固定されているか、或いはそれがデバイスであるか（或いはそうでなければより一般的に不動化されているか）を確認し、いずれの場合でもクライアントノードは移動不可能と判断され、プログラム14は終了する。
【００６３】
しかしながら、検討中のクライアントノードが移動不可能ではない場合には、次にステップ62で検査が実行され、クライアントノードが対象とするサーバに十分にリンクされているかどうかが調べられる。ここで、「十分にリンクされている（well-linked）」とは、サーバに対するクライアントノードの連係が、そのクライアントノードの総連係（トラヒック量で測定）の50％よりも多いことを意味する。50％の数字の或る程度の変化は、特に上向き方向であれば可能であることが理解されよう。クライアントノードがそのサーバに対して十分にリンクされていない場合には、そのクライアントノードをサーバと同じセグメントに移動することは適当であるとは判断されず、プログラム14は終了する。しかしながら、クライアントノードが検討中のサーバに十分にリンクしている場合には、クライアントノードはサーバのワークグループに追加され、ターゲットの識別性がクライアントノードのデータ構造中に入れられ、そのサーバはクライアントノードに対する主たるサーバとして識別される（ステップ63）。その後、クライアントのセグメントがサーバのセグメントと異なっているかどうかに関しての確認がステップ64でなされ、そうである場合にはステップ65が実行されて移動示唆がノード移動リスト25に追加され、クライアントノードをサーバのセグメントへ移動することが提案される。ステップ65の実行はまた、対象とするクライアントノード及びセグメントデータ構造を更新することにより、クライアントノードをサーバのセグメントに一時的に移動することを含んでいる。
【００６４】
以上においては移動示唆プログラム11の動作及びその関連するプログラム項目13及び14の説明を行ってきたが、今度は分割示唆プログラム項目12をその関連するプログラム項目15, 16及び17と共に検討する。
【００６５】
分割示唆プログラム12は、順番に各論理セグメントを検討して、セグメントの何れかを２つに分割するのが有利か否かを決定する。図12は、論理セグメント、この場合にはセグメントX2が２つのセグメントに分割される、例示的なトラヒックデータからとった状況を示している（ここでは、ローカルサーバノードN6及びN7の周囲をベースとするグループ化に対応している）。
【００６６】
分割示唆プログラム12は、移動示唆プログラム11によりワークグループリスト26内に構築されたノードのグループ化に基づいて開始される。しかしながら、リスト26に記録されたワークグループを、セグメントの分割に関する決定を行うのに直ちに使用できる訳ではない。なぜならそのようなワークグループの各々は１つより多いセグメントからのノードを含むことがあり、またこれに加えて、全てのネットワークノードがワークグループに含まれている訳ではないからである（サーバノードに十分リンクされたノードだけがプログラム11により含まれている）。
【００６７】
図13を参照すると、分割示唆プログラム12の最初のステップ70は、ワークグループリスト26に何らかのワークグループが存在するか否かの確認を含んでいる。そのようなワークグループが存在しない場合には、どのようなセグメント分割示唆も行われることなくプログラム12は終了する。しかしながら、一般的にワークグループリスト26には幾つかのワークグループが存在し、この場合にはプログラム12はステップ71に進み、切り詰めワークグループプログラム項目15が実行される。切り詰めワークグループプログラム15の目的は、各ワークグループを切り詰めて、それがただ１つのセグメントと関係し、またそのセグメント上に、プログラム11のステップ45でワークグループが生成されたサーバへと、そのセグメント上のノードを辿って戻ることができる連係を有するノードだけを含むようにすることである。より詳細には、プログラム15はワークグループから、ワークグループと同じ論理セグメント上にない全てのノード、及びワークグループ内に含まれていることが直接的にせよ間接的にせよ、ワークグループの論理セグメント上にないノードを元来包含したことの結果である全てのノードを除去する。
【００６８】
ワークグループが切り詰められたならば、各セグメントを順番に取り上げて処理ステップ74から77を実行するため、ステップ72及び73に基づくループ機構を有するループ構造に入る。より詳細には、ステップ72において、セグメントのリストの中の最初の或いは次のセグメントがターゲットとされ、ステップ73において、リストの終わりに達したかどうかが確認される（達していればプログラム12は終了する）。
【００６９】
各論理セグメント毎に、ステップ74から77が実行される。ステップ74では、集合（collection）「WGCLTN」が、現在のターゲットセグメントに関連するリスト26中の全てのワークグループから形成される。ステップ75は、集合WGCLTNに１つより多くのワークグループが存在するかどうかを確認し、そうでない場合には論理セグメントは分割するに値しないと仮定され、処理はループの開始に戻って次のセグメントを取り上げる。しかしながら、WGCLTNに少なくとも２つのワークグループが存在するとすれば、プログラム12はステップ76へ進み、合併ワークグループプログラム項目16が実行されて、検討中の論理セグメント上の全てのノードがワークグループに割り当てられ、ワークグループの数は２つだけに減らされる。
【００７０】
その後、ステップ77は分割決定プログラム項目17を実行し、検討中の論理セグメントをステップ76により生成された最終的な２つのワークグループに対応して分割する価値があるか否かを決定する。肯定的な分割示唆はどのようなものでもセグメント分割リスト27に入れられ、各入力項目は、対象とするセグメントと、セグメントを分割して入れることが示唆されたノードの２つのグループを識別する。
【００７１】
図14は、切り詰めワークグループプログラム項目15のフローチャートである。このプログラム15は基本的には、ステップ85から87への処理がワークグループリスト26の中の各ワークグループの各構成ノード毎に適用される、二重ループ構造を有している。より詳細には、ステップ80及び81はループ制御ステップであり、全てのワークグループが調べられるまでリスト26内の各ワークグループを順番に検査するようにプログラム15を動作させる。検査された新しいワークグループの各々毎に、ステップ82でリスト「除去済（Removed）」が初期化される。その後、内側ループ構造に入り、現在のワークグループの各ノードが順番に検討される。しかしながら、ワークグループの構成ノードの次々への処理の進行は、ステップ86の処理がノードに関して実行されるか否かに依存しており、実行される場合にはそのノードはワークグループから除去されて除去済リストに入れられ、ワークグループノードの処理は再び最初から開始される。反対に、ステップ86が特定のノードに関して実行されない場合には、検討中のワークグループの次のノードへと処理が継続される。
【００７２】
より詳細には、除去済リストがステップ82で初期化された後に、ステップ83がターゲットワークグループの最初の構成ノードを取り上げ、ステップ84はそのようなノードがあるかどうかを確認する（ない場合は、ワークグループ内の全てのノードが処理されたことを示しており、処理はステップ80に戻って新しいワークグループを取り上げる）。ステップ85が、次いで最初のノードに関して実行されるが、このステップは対象とするノードがワークグループと同じセグメント上にあるかどうかに関しての単純な検査である。ターゲットノードがワークグループと同じセグメント上にない場合には、次いでステップ86が実行されてターゲットノードをワークグループから除去し、それを除去済リストに入れる。その後、処理はステップ85に戻る。即ち、同じワークグループが再度取り上げられ、その新たな最初のノードが見つけられる。他方、ステップ85でターゲットノードがワークグループと同じセグメント上にあることが判った場合には、ステップ87が実行され、ターゲットノードの主たるサーバが除去済リストの中にあるかどうかが確認される。これはもちろん、ワークグループについて検査された最初のノードについてはそうではない。ステップ87で否定的な結果が出た場合にはステップ88が実行され、ターゲットノードをワークグループ内の次のノードに進め、処理はステップ84に戻される。処理はこのようにして進行し、ノードはワークグループと同じセグメント上に存在しないか（ステップ85で検査される如く）、或いは対象とするノードの主たるサーバが除去済リストの中にある（ステップ87で検査される如く）場合には、ステップ86で現在のワークグループから切り詰められる。いずれかのノードが切り詰められる場合には、ワークグループのノード処理は再度初期化される。
【００７３】
図15は、分割示唆プログラム12のステップ26で実行される合併ワークグループプログラム項目16のフローチャートである。このプログラム項目の開始に際しては、対象とするセグメントのノードの多くが、そのセグメントに関連するワークグループに割り当てられていない。従ってプログラム16の最初のステップ90は、対象とするセグメント上の全てのアクティブな未割り当てノード、即ちそのセグメントのワークグループ中に未だないトラヒックに関連するノードの集合「AUN」を生成することである。
【００７４】
リストAUNが生成されたならば、プログラム16はステップ91へ進み、AUN内の全てのノードに対してそれぞれ新たなワークグループを生成し、そのようなワークグループは各々、対象とするセグメントに対するワークグループの集合WGCLTNに記録される。
【００７５】
反復処理が次いで実行され、集合WGCLTN内のワークグループの数が２つに減らされる。ステップ92は、この条件のための検査である。ワークグループの数を２つに減らす処理は、ワークグループを一緒に合併することにより実行される。このようにして、ステップ93ではWGCLTN内の最小ワークグループが、対象とするノードの数、或いはこれらのノード間を流れるトラヒック量のいずれかによって識別される。識別されたならば、その最小ワークグループは集合WGCLTNから除去され、それが最多の連係（ノード或いはトラヒック量）を有するWGCLTN内のワークグループに追加される。この追加はステップ94で実行される。
【００７６】
WGCLTN内のワークグループの数が２つに減らされたならば、合併ワークグループプログラム16から抜ける。
【００７７】
図16は、分割示唆プログラム12のステップ77で実行される分割決定プログラム項目17のフローチャートである。プログラム17は、対象とするセグメントに対するWGCLTNリスト内の２つの残っているワークグループに対応して、論理セグメントを２つのセグメントに分割すべきかどうかに関しての決定を行う。この決定は、２つのワークグループの内部及びそれらの間のトラヒックフローを基礎としてなされる（便宜上、これらのワークグループはWG1及びWG2として参照される）。図16のフローチャートにおいては、トラヒックフローはバイトで評価されると仮定されているが、もちろんこれはトラヒック要素22の総トラヒックフィールド内に収集されるトラヒック測定において使用されるトラヒック測定単位に依存している。
【００７８】
プログラム17のステップ95において、各ワークグループWG1及びWG2の内部トラヒックが求められる。この内部トラヒックは、各ワークグループ内のノード間の総トラヒックである。ステップ95においてはまた、ワークグループWG1とワークグループWG2の間の連係の判定がなされる。既に示されたように、内部トラヒックの測定及びワークグループの連係は全て、図16のフローチャートではバイトにより求められている。
【００７９】
次にステップ96が実行され、対象とするセグメントについての総内部トラヒックが、やはりバイトで求められる。
【００８０】
以上の測定を基礎として、ステップ97が次いで実行され、対象とするセグメントを２つに分割する価値があるか否かが決定される。この決定に使用される規準は実用的なものであり、状況に応じて変更することができる。しかしながら基本的には、２つのワークグループWG1及びWG2間の総連係がそれほど多くない場合のみ、論理セグメントは分割に値する。ワークグループの一方或いは双方がセグメントに対する総トラヒックのうち少量のみを表しているか、或いは何れかのワークグループのノード数が少ない場合には、セグメントを分割する効果は殆どない。ステップ97は、３つの検査を実行することによって以上を詳細に調べ、これら３つの全ての検査に合格した場合にのみ、セグメントの分割を推奨する。３つの検査は以下の通りである。即ち、
−ワークグループWG1及びWG2の各々についての、バイト単位での内部トラヒックが、総セグメント内部トラヒックの所定の割合（例えば20％）よりも多いかどうかの検査と、
−ワークグループWG1及びWG2の各々におけるノード数が所定のしきい値（例えば４）より大きいかどうかの検査と、
−ワークグループWG1及びWG2の間の連係が、WG1及びWG2の各々についての内部トラヒックよりも少ないかどうかに関する検査である。
【００８１】
最初に述べたように、本発明のネットワーク解析方法の実施の上記説明は、トラヒックデータが、データ送信／受信ノードのサーバ／クライアント役の指示を含まないトラヒックデータである場合のものである。しかしながら、このような情報が利用可能な場合もある。従って例えば、TCPプロトコルの下に送信されるメッセージについて、各メッセージはソースノードポート番号及び宛先ノードポート番号を含む。幾つかのポート番号が、より一般的なサービスのために予め割り当てられる。このようにして予め割り当てられたポート番号は、「周知ポート」として知られている。例えば、ホスト名サーバサービスを提供する装置は、ポート番号42の周知ポート上でこれを行い、同様にX.400メイルサービスは周知ポート番号103上で提供される。
【００８２】
一般に、１つのノードが周知ポートではない端点を使用し、それが他のノードの既知ポートと通信している場合には、最初に述べたノードはクライアントとして動作するが、後者のノードはサーバとして動作する。従ってソースノード及び宛先ノードのポート番号を確認することにより、ノードにより実行されているそれぞれの役割に関する評価を行うことが可能となる。
【００８３】
しかしながら、２つのノードが相互に、双方とも既知ポートを介して通信することは度々発生する。この場合、どちらのノードがサーバとして動作しどちらのノードがクライアントであるかを判断することができないか、或いは対象とするノードの役割に関して判断を行うために周知ポート番号の何らかの優先化を行うことによらねばならないかである。もちろん、いずれのノードも周知ポートを使用していなければ、ポート番号を調べても対象とするノードの役割を決定する役には立たない。
【００８４】
図４Ｂは、ノードの役割を識別するために周知ポート番号が用いられる場合に使用するのに適した、トラヒック要素データ構造の形態を示す。図４Ｂのデータ構造の最初の２つのフィールドは、通信ノード対の識別性を含んでいる。第３及び第４のフィールドは、識別されたノードのどちらがクライアントとして動作し、どちらがサーバとして動作するのかを特定するために使用される（そのような情報が導き出されている場合）。第５のフィールドは、考慮されているプロトコルを識別する。この点に関し、周知ポートの使用はTCPプロトコルに制限されておらず、同一の又は類似の機構が他のプロトコルで動作される。図４Ｂのデータ構造の第６のフィールドは、サーバとして動作すると識別されたノードに対するポート番号を保持するために使用される。このポート番号は、もちろん周知ポート番号である。第７及び第８のフィールドは、対象とするノード対の間のトラヒックフローにおける、２つの方向におけるトラヒック量データを含んでいる。最後のフィールドは、図４Ａのデータ構造に関して既に記述したイネーブルフラグフィールドである。
【００８５】
役割情報が収集されていない場合には、ノードの各対毎に１つのトラヒック要素を与えることだけが必要であったが、そのような情報がトラヒックから導き出される場合には、各ノード対に関して少なくとも３つのトラヒック要素が必要であることが理解されよう。第１の要素は、サーバとして動作するノードの最初の１つに関してトラヒックを記録するためのものであり、第２の要素はサーバとして動作する他のノードに関してトラヒックを記録するためのものであり、第３の要素は役割に関して割り当てが出来なかったものに関するトラヒックを記録するためのものである。実際、他のノードにおける周知でないポートと通信している１つのノードにおける周知ポートの組み合わせ毎に、それぞれにトラヒック要素を提供することが好都合である。
【００８６】
上記方法で収集されたノード役割情報は、グローバル及びローカルサーバを識別するのに特に有用であり、これが抽出サーバプログラム10により実行される動作である。この後者のプログラムの実行に際しては、ノードがグローバルサーバであるかローカルサーバであるかに関する評価は、クライアント役とは逆のサーバ役で動作する場合のトラヒック連係に基づいており、このような区別を行うことは、各ノード対毎に多数のトラヒック要素を使用することを通じて可能となる。より詳細には、ノードがサーバとして動作するかどうかを評価するに際しては、そのノードがサーバとして識別されたトラヒック要素が参照される。実際には一般に、対象とするノードの役割が定義されていないトラヒック要素も参照される（換言すれば、無視されるトラヒック要素は、対象とするノードがクライアントとして識別されたものだけである）。サーバが識別された役割を持たないトラヒックを含めることは、周知ポートを含むどのようなトラヒックも存在しなければ両者の場合に同じ結果が得られるという限りにおいて、上述した図５の抽出サーバプログラムの説明と一致している。
【００８７】
サーバに関連するトラヒックがディセーブルされた場合（例えば図５のステップ35において）、これは対象とするノードがサーバとして識別された、或いは識別が行われなかったトラヒック要素をディセーブルすることだけを含むものであることが理解されよう。
【００８８】
移動示唆プログラム11及び分割示唆プログラム12に関連して役割情報がどのように使用されるかに関しても、同様な考察が当てはまる。
【００８９】
上述のネットワーク解析方法に対する種々の修正が、もちろん可能である。しかして本方法は、７層OSI基準モデルのレベル２における論理セグメントにより形成されるサブネットワークから構成されるネットワークに関連して説明されたが、この方法はまた、サブネットワークが他の形態、例えば７層OSI基準モデルのレベル３において動作するルータ／ゲートウェイにより分割されたノードのグループであるネットワークにも適用できる。
【００９０】
更に、抽出サーバプログラム10、移動示唆プログラム11、及び分割示唆プログラム12により表される３つの主たる解析タスクは、適切な開始情報が与えられれば、独立に動作させることができる。かくして移動示唆タスクにローカルサーバ及びそれらのクライアントのリスト、並びに適切なトラヒックデータを与えることにより、移動示唆解析タスクを抽出サーバタスクとは別個に実行することができる。同様に、分割示唆タスクも抽出サーバタスクとは別個に実行することができる。実際上分割示唆タスクは、等価なワークグループ情報がどこかからか利用可能とされるか、或いはワークグループをそれ自体で構築するように分割示唆タスクの動作が修正された場合には、移動示唆タスクとは別個に実行することができる。このために、対象とするサブネットワークの内部トラヒック上のデータを解析して、反復処理によってサブネットワーク上のノードをワークグループに分類することができる。この反復処理は各反復について、
−最多のトラヒック連係を有するノードをそれぞれの新しいワークグループへとローカルサーバとして割り当て、
−更にクライアントノードとして、ローカルサーバノードへの連係が対象とするノードの総連係の所定の割合（例えば50％）よりも多いノードを、同じワークグループに割り当て、及び
−新しいワークグループと関連するトラヒックの除去によりトラヒックデータを修正することを含む。
【００９１】
これらのワークグループは、次いで既述の方法により２つに減らすことができ、次いでサブネットワークを有利に分割できるか否かについての決定がなされる。
【００９２】
以下では本発明の種々の構成要件の組み合わせからなる実施例を例示する。
１．それぞれに複数のノードを備えた複数のサブネットワークからなる形式のネットワークに関して使用されるネットワーク解析方法であって、（１）ネットワークを監視し、ノード間のトラヒックにより判別されたノード間の連係を示すトラヒックデータを収集し蓄積するステップと、
（２）グローバルサーバとして動作すると識別されたノードに関連するトラヒックを優先的に除去することにより前記トラヒックデータを処理し、残りのトラヒックを使用してローカルサーバとして動作するノードを識別するステップとからなる方法。
【００９３】
２．前記ステップ（２）が、前記トラヒックデータを検査して前記ノードの中から全てのグローバルサーバ候補を識別することを含み、前記グローバルサーバ候補が前記サブネットワークのいずれかに対する連係が全てのノードに対するその総連係の第１の所定の割合よりも少ないノードであり、
−前記グローバルサーバ候補が識別された場合には、総連係が最多のグローバルサーバ候補を識別し、これに関連するトラヒックを前記トラヒックデータから除去してステップ（２）の開始に戻り、このように修正されたトラヒックデータを使用して当該ステップを繰り返し、
−そのようなグローバルサーバ候補が識別されなかった場合には、前記トラヒックデータを検査して前記ノードの中から全てのローカルサーバ候補を識別し、前記ローカルサーバ候補はそれに対する最多の連係を有するサブネットワークについての最多連係がそのローカルサーバ候補の総連係の第２の所定の割合以上のノードであり、及び
−前記ローカルサーバ候補が識別された場合には、総連係が最多のローカルサーバ候補を識別し、この候補をローカルサーバとして記録し、これに関連するトラヒックを前記トラヒックデータから除去してステップ（２）の開始に戻り、このように修正されたトラヒックデータを使用して当該ステップを繰り返し、
−前記ローカルサーバ候補が識別されなかった場合にはステップ（２）から抜けることからなる、上記１の方法。
【００９４】
３．前記第１及び第２の所定の割合が、双方とも実質的に半分である、上記２の方法。
【００９５】
４．前記トラヒックデータが前記ノードの一対の間でのトラヒックの表示をそれぞれにもたらすトラヒック要素として蓄積されており、前記サーバに関連するトラヒックを除去する前記トラヒックデータの修正が、関連するトラヒック要素を現在ディセーブルされているとしてマーキングすることにより実行される、上記１から３の何れかの方法。
【００９６】
５．ノードの他の関連するノードとの連係が、
−関連するノードの数、
−関連するノードとのトラヒックに関与するフレームの数、
−関連するノードとのトラヒックに関与するバイトの数
のうち少なくとも１つにより測定される、上記１から４の何れかの方法。
【００９７】
６．前記ステップ（１）において、ノードが関連する個別のトラヒック項目に関してサーバ役として動作するかクライアント役として動作するかを示す役割情報の収集を可能にする仕方でネットワークの監視が実行され、ステップ（２）におけるグローバル或いはローカルサーバとしてのノードの識別が、ノードがクライアントとして動作することが前記役割情報により示されたトラヒックを参照することなしに実行される、上記１から５の何れかの方法。
【００９８】
７．前記役割情報が、一対のノード間を通過するトラヒックに関連したノード端点の周知ポート状態を基礎として導出され、前記対のノードの一方のノードはサーバ役で動作し他方のノードはクライアント役で動作すると識別され、前記一方のノードの端点は周知ポートとなるが他方の端点はそうではない、上記６の方法。
【００９９】
８．前記ステップ（２）において識別されたローカルサーバの少なくとも１つについて、そのローカルサーバに最適なサブネットワークの決定がなされ、前記決定が、対象とするローカルサーバを各サブネットワーク上で観念的に順次位置決めすることと、ローカルサーバのそのような各位置毎に、現在の観念的な位置にあるローカルサーバと関連するサブネットワーク間のトラヒックの測定量を与える所定の最適位置関数を評価することを含み、前記決定が更に、前記最適サブネットワークとして、前記関数の評価によりサブネットワーク間の前記トラヒックに関して最小値が示されるサブネットワークを識別することを含む、上記１から７の何れかの方法。
【０１００】
９．前記最適位置関数が、対象とするローカルサーバとの連係を有し、前記ローカルサーバの前記現在の観念的な位置に対応するサブネットワーク以外のサブネットワーク上に位置するノードのカウントである、上記８の方法。
【０１０１】
10．前記最適サブネットワークが決定された前記ローカルサーバに対し、このローカルサーバがその前記最適サブネットワーク上に位置している場合に、それがサーバとして連係を有しているノードの何れかを、前記最適サブネットワークに移動すべきかどうかに関しての決定が行われ、この決定が、ノードとローカルサーバとの間の連係が実質的にそのノードの総連係の半分以上であるか否かを各ノード毎に検査することを含む、上記８又は９の方法。
【０１０２】
11．前記ステップ（２）において識別されたローカルサーバのグループについて、各ローカルサーバを降順の連係で順番に取り上げ、そのような各サーバ毎に、
（ｉ）対象とするローカルサーバが、前記順番中で高次のローカルサーバに関して生成された他のワークグループに既に割り当てられていなければ、それについてのワークグループをそれぞれに生成し、
（ii）対象とするローカルサーバについての前記それぞれのワークグループが（ｉ）で既に生成されている場合には、サーバをそのワークグループに割り当て、及び
（iii）ローカルサーバへの連係が実質的にそのノードの総連係の少なくとも半分である全てのノードを、ローカルサーバとして同じワークグループに割り当てることからなる、上記１から10の何れかの方法。
【０１０３】
12．前記サブネットワークの少なくとも１つについて、該サブネットワークを２つのサブネットワークに分割する価値があるか否かが決定され、この決定が、
（ａ）ワークグループを対象とするサブネットワークに関してだけ考慮した場合に、もはやその中に含めることが適当でない全てのノードをワークグループから除去することにより、前記ワークグループ又は対象とするサブネットワーク上に位置するローカルサーバに関して生成された各ワークグループを切り詰めるステップと、
（ｂ）ノードがサブネットワークに関連したワークグループ中に未だない場合に、対象とするサブネットワークの各ノード毎に更なるワークグループをそれぞれ形成するステップと、
（ｃ）対象とするサブネットワークに関連するワークグループを、そのようなワークグループが２つだけ残るように合併するステップと、及び
（ｄ）ステップ（ｃ）の後に残った２つのワークグループ間のトラヒック量を、そのようなワークグループの各々に関連した総トラヒックと比較することにより、サブネットワークを分割する価値があるかどうかを決定するステップとを含む、上記11の方法。
【０１０４】
13．前記ステップ（ａ）が、切り詰められるワークグループから、対象とするサブネットワークと異なるサブネットワーク上に位置する全てのノード、及びワークグループ内に含まれていることが直接的にせよ間接的にせよ、対象とするサブネットワークと異なるサブネットワーク上に位置するノードとの関連に依存している全てのノードを除去する、上記12の方法。
【０１０５】
14．前記ステップ（ｃ）が反復処理を含み、その反復の各々に際して、関連するトラヒック量が最小であるワークグループがそれと最多の連係を有するワークグループと合併される、上記12の方法。
【０１０６】
15．動作が上記１のステップ（１）において収集されたトラヒックデータを用いて実行されるが、グローバルサーバトラヒックが除去される、上記８から14の何れかの方法。
【０１０７】
16．それぞれ複数のノードを備えた複数のサブネットワークからなる形式のネットワークに関連して使用されるネットワーク解析方法であって、
（１）ネットワークを監視して、ノード間のトラヒックにより判断されたノード間の連係を示すトラヒックデータを収集して蓄積するステップと、
（２）トラヒックデータを処理してローカルサーバとして動作するノードを識別するステップと、及び
（３）前記ステップ（２）で識別されたローカルサーバの少なくとも１つに対して、そのローカルサーバに対する最適なサブネットワークを決定し、この決定が、対象とするローカルサーバを各サブネットワーク上で観念的に順次位置決めすることと、ローカルサーバのそのような各位置毎に、現在の観念的な位置にあるローカルサーバと関連するサブネットワーク間のトラヒックの測定量を与える所定の最適位置関数を評価することを含み、前記決定が更に、前記最適サブネットワークとして、前記関数の評価により、サブネットワーク間の前記トラヒックに関して最小値が示されるサブネットワークを識別するステップとを含むことからなる方法。
【０１０８】
17．論理セグメントを２つのそのようなセグメントに分割する価値があるか否かを決定するための、複数のノードを備えた論理セグメントを有するネットワークに関連して使用されるネットワーク解析方法であって、
（１）論理セグメントを監視して、ノード間のトラヒックにより判断されたセグメントのノード間の連係を表すトラヒックデータを収集して蓄積するステップと、
（２）セグメントトラヒックデータを解析するための第１の反復処理を実行して、前記ノードをそれぞれローカルサーバと１つ以上のクライアントノードを備えたワークグループに分類し、この第１の反復処理の各反復が、最多のトラヒック連係を有するノードをそれぞれの新しいワークグループにローカルサーバとして割り当て、更にクライアントノードとして、ローカルサーバノードへの連係が対象とするノードの総連係の所定の割合よりも大きなノードを同じワークグループに割り当て、新しいワークグループに関連したトラヒックを除去してトラヒックデータを修正することを含むステップと、
（３）前記ステップ（２）で識別されたワークグループを合併して２つのワークグループを残す第２の反復処理を実行し、この第２の反復処理の各反復が、関連するトラヒックの量が最小であるワークグループを識別し、それを最多の連係を有するワークグループと合併することを含むステップと、
（４）前記ステップ（３）の後に残った２つのワークグループの間のトラヒックの量をそのようなワークグループのそれぞれに関連した総トラヒックと比較することにより、論理セグメントが分割に値するかどうかを決定するステップとからなる方法。
【０１０９】
【発明の効果】
以上のように本発明によれば、グローバルサーバトラヒックを優先的に除去して、ローカルサーバの正体を効率的に識別することが可能となる。従って、対象となるネットワークが幾つかのサブネットワークからなり、所定のノードが全てのサブネットワーク全体にわたるグローバルサーバとして動作しているようなネットワークの動作を、サブネットワークレベルで解析することが容易となる。
【図面の簡単な説明】
【図１】 ４つのサブネットワークを有するネットワークの例を示すノードクラスタの図である。
【図２】 所定の監視期間における図１のネットワークのノード間の総トラヒックの例を示す、図１に類似の図である。
【図３】 本発明のネットワーク解析方法において使用される主プログラム項目及びデータ構造を示す図である。
【図４】 Ａ及びＢはそれぞれ、トラヒック要素データ構造の第１及び第２の形態を示す図である。
【図５】 図３に示された抽出サーバプログラムのフローチャートである。
【図６】 図２と同様であるが、ノードN1に関連する総トラヒックの構成要素のみを示す図である。
【図７】 図２と同様であるが、図５の抽出サーバプログラムにより識別されたグローバルサーバと関連するトラヒックの除去の後に残る総トラヒックの構成要素のみを示す図である。
【図８】 図２と同様であるが、ネットワークの一部分のみと、図５の抽出サーバプログラムにより識別されたローカルサーバノードN5と関連する総トラヒックの構成要素のみを示す図である。
【図９】 図３に示された移動示唆プログラムのフローチャートである。
【図１０】 図９の移動示唆プログラムにより使用される配置サーバプログラム項目のフローチャートである。
【図１１】 図９の移動示唆プログラムにより使用される配置クライアントプログラム項目のフローチャートである。
【図１２】 図２と同様であるが、１つのサブネットワークのみと、サブネットワークについて局所的であり図５の抽出サーバプログラムにより識別されたローカルサーバと関連する総トラヒックの構成要素のみを示す図である。
【図１３】 図３に示された分割示唆プログラムのフローチャートである。
【図１４】 図13の分割示唆プログラムにより使用される切り詰めワークグループプログラム項目のフローチャートである。
【図１５】 図13の分割示唆プログラムにより使用される合併ワークグループプログラム項目のフローチャートである。
【図１６】 図13の分割示唆プログラムにより使用される分割決定プログラム項目のフローチャートである。
【符号の説明】
X1,X2,X3,X4 論理セグメント（サブネットワーク）
N1,N2 ノード
10 抽出サーバプログラム
11 移動示唆プログラム
12 分割示唆プログラム
13 配置サーバ
14 配置クライアント
15 切り詰めワークグループ
16 合併ワークグループ
17 分割決定
20 セグメント
21 ノード
22 トラヒック要素
23 グローバルサーバリスト
24 ローカルサーバリスト
25 ノード移動リスト
26 ワークグループリスト
27 セグメント分割リスト

Claims (12)

1. それぞれに複数のノードを備えた複数のサブネットワークからなる形式のネットワークに関して使用されるネットワーク解析方法であって、
   （１）ネットワークを監視して、ノード間の連係を判別するためのノード間のトラヒックデータを収集し蓄積するステップであって、ここで、「連係」とは、ノード間のトラヒック量によって決定されるノード間の相互接続性の程度を表すものとして定義されることからなる、ステップと、
   （２）前記トラヒックデータを解析して、グローバルサーバとして動作するノードを識別するステップであって、グローバルサーバは、任意の一つのサブネットワークのノードとの連係が、すべてのサブネットワークのすべてのノードとの総連係の第１の所定の割合よりも少ないノードであることからなる、ステップと、
   （３）前記蓄積されたトラヒックデータにアクセスして、グローバルサーバとして動作するものとして識別されたノードに関連するトラヒックデータを除去し、
   この除去の後残っている蓄積されたトラフィックデータを解析することによって、ローカルサーバとして動作するノードを識別するステップであって、ローカルサーバは、特定のサブネットワークのノードとの連係が、すべてのサブネットワークのすべてのノードとの総連係の第２の所定の割合以上であるノードであることからなる、ステップ
   からなる方法。
2. 前記ステップ（３）が、前記トラヒックデータを検査して前記ノードの中から全てのグローバルサーバ候補を識別するステップを含み、グローバルサーバ候補は、任意の前記サブネットワークに対する連係が全てのノードに対するその総連係の前記第１の所定の割合よりも少ないノードであり、
   前記グローバルサーバ候補が識別された場合には、総連係が最多のグローバルサーバ候補を識別し、これに関連するトラヒックを前記トラヒックデータから除去して、前記ステップ（３）の開始に戻り、このように修正されたトラヒックデータを使用して当該ステップを繰り返し、
   そのようなグローバルサーバ候補が識別されなかった場合には、前記トラヒックデータを検査して前記ノードの中から全てのローカルサーバ候補を識別し、ローカルサーバ候補はそれに対する最多の連係を有するサブネットワークについて、この連係がそのローカルサーバ候補の総連係の前記第２の所定の割合以上のノードであり、
   前記ローカルサーバ候補が識別された場合には、総連係が最多のローカルサーバ候補を識別し、この候補をローカルサーバとして記録し、これに関連するトラヒックをトラヒックデータから除去して前記ステップ（３）の開始に戻り、このように修正されたトラヒックデータを使用して当該ステップを繰り返し、
   前記ローカルサーバ候補が識別されなかった場合には前記ステップ（２）から抜けることからなる、請求項１の方法。
3. 前記第１及び第２の所定の割合が、双方とも約半分である、請求項２の方法。
4. 前記トラヒックデータが、前記ノードの一対の間でのトラヒックの表示をそれぞれが提供するトラヒック要素として蓄積されており、前記サーバに関連するトラヒックを除去する前記トラヒックデータの修正が、関連するトラヒック要素を現在ディセーブルされているとしてマーキングすることにより実行される、請求項１乃至３のいずれかの方法。
5. あるノードと他の関連するノードとの連係が、
   関連するノードの数、
   前記あるノードと前記関連するノード間のトラヒックに含まれるデータフレームの数、
   前記あるノードと前記関連するノード間のトラヒックに含まれるデータバイトの数
   のうちの少なくとも１つにより測定される、請求項１乃至４のいずれかの方法。
6. 前記ステップ（１）において、ノードが、該ノードに関連する個別のトラヒック項目に関してサーバ役として動作するかクライアント役として動作するかを示す役割情報の収集を可能にする仕方でネットワークの監視が実行され、前記ステップ（３）におけるグローバルまたはローカルサーバとしてのノードの識別が、ノードがクライアントとして動作することが前記役割情報により示されたトラヒックを参照することなしに実行される、請求項１乃至５のいずれかの方法。
7. 前記役割情報が、一対のノード間を通過するトラヒックに関連したノード端点の周知ポート状態に基づいて導出され、前記対のノードのうち、ポート番号が所定の範囲内にあるポートを端点として有するノードがサーバ役として動作するものとして識別され、ポート番号が前記所定の範囲内にはないポートを端点として有するノードがクライアント役として動作するものとして識別される、請求項６の方法。
8. 前記ステップ（３）において識別された少なくとも１つのローカルサーバについて、該ローカルサーバに最適なサブネットワークを決定し、当該決定が、前記ネットワークの各サブネットワークに前記ローカルサーバを配置するために、前記ローカルサーバの論理的な位置の変化を仮定することと、ローカルサーバのそのような論理的な各位置毎に、既に収集されたトラヒックデータに基づいて、その仮定された論理的な位置にあるローカルサーバに関連するサブネットワーク間のトラヒックの測定量を決定することと、前記測定量が、サブネットワーク間の前記トラヒックに関して最小値を示すところのサブネットワークを、前記最適サブネットワークとして識別することを含む、請求項１から７のいずれかの方法。
9. 前記測定量が、前記ローカルサーバとの通信連係を有し、前記ローカルサーバの前記現在の仮定された位置に対応するサブネットワーク以外のサブネットワーク上に位置するノードのカウントである、請求項８の方法。
10. 前記最適サブネットワークが決定されたローカルサーバに対し、該ローカルサーバが前記最適サブネットワーク上のサーバとして通信連係を有している任意のノードを、前記最適サブネットワークに論理的に移動すべきかどうかについての決定が、そのノードとローカルサーバとの間の連係がそのノードの総通信連係の約半分以上であるか否かを各ノード毎に検査することに基づいて行われる、請求項８又は９の方法。
11. 請求項８で規定される動作が、全てのグローバルサーバトラヒックが除去された状態で、請求項１のステップ（１）において収集されたトラヒックデータを用いて実行される、請求項８乃至１０のいずれかの方法。
12. 各々が複数のノードを有する複数のサブネットワークからなる形式のネットワークに関連して使用されるネットワーク解析方法であって、
    （１）ネットワークを監視して、ノード間の連係を判別するためのノード間のトラヒックデータを収集し蓄積するステップであって、ここで「連係」とは、ノード間のトラヒック量により決定されるノード間の相互接続性の程度を意味することからなる、ステップと、
    （２）トラヒックデータを処理してローカルサーバとして動作するノードを識別するステップであって、ローカルサーバは、特定のサブネットワークのノードとの連係が、すべてのサブネットワークのすべてのノードとの総連係の第２の所定の割合以上であるノードであることからなる、ステップと、
    （３）前記ステップ（２）で識別されたローカルサーバの少なくとも１つに対して、該少なくとも１つのローカルサーバに対する最適なサブネットワークを決定するステップであって、この決定ステップが、前記少なくとも１つのローカルサーバの各サブネットワーク上における論理的な位置の変化を仮定し、前記少なくとも１つのローカルサーバの論理的な各位置について、既に収集されたトラヒックデータに基づいて、その仮定された論理的な位置にある前記少なくとも１つのローカルサーバと関連するサブネットワーク間のトラヒックの測定量を決定することと、前記測定量が、サブネットワーク間のトラヒック量に関して最小値を示すところのサブネットワークを、前記最適サブネットワークとして識別することからなる、ステップ
    を含む、方法。

Images