JP4737410B2 - ネットワーク内でサービス、リソースおよび／または機能を検索する方法 - Google Patents

Description

本発明は、ネットワーク内でサービス、リソースおよび／または機能を検索する方法に関する。ここで、ネットワークは、ルーティング可能なネットワークアドレスが割り当てられた多数のノードを備え、検索対象のサービス、リソースおよび／または機能はソースノードによって指定される。

上記のような方法がかねてから最新技術として存在する。例えばファイアウォール、データストレージ、メディアキャッシュ、トランスコーダ等の特殊なサービス、リソースおよび／または機能をネットワーク側で提供するという傾向がますます強まるに伴い、このような方法の重要性が着実に高まっている。

具体的な汎用方法として、利用可能なサービスまたはリソースを周知のディレクトリサービスに登録することが広く知られている（非特許文献１および２参照）。特定のサービス／リソースを検索するクライアントまたはノードがそれぞれ、直接このディレクトリサービスに要求を行う。

もう１つの既知の手法として、特定のネットワーク側のサービスおよび／またはリソースを探す際に「ルックアップ」要求をネットワーク内にブロードキャストするというものがある（非特許文献３参照）。要求されたサービスまたは要求されたリソースを提供することができ、その準備ができているノードが、このルックアップ要求に応答する。この方法は「フラディング」とも呼ばれる。

E. Guttman, C. Perkins, J. Veizades, M. Day, Service Location Protocol, Version 2, Internet RFC2608, 1999 J. Hodges, R. Morgan, Lightweight Directory Access Protocol (v3): Technical Specification, Internet RFC3377 K. S. Lim, R. Stadler, "A Navigation Pattern for Scalable Internet Management", Seventh IFIP/IEEE International Symposium on Integrated Network Management (IM2001), Seattle, USA, May 2001, pp.405-420

上記ディレクトリベースの手法の欠点は、ディレクトリサービスを絶えず更新するのは極めてコストが高いことである。これは特に、高度にダイナミックな環境やモバイル環境に当てはまる。ディレクトリサービスを最新の状態に保つために必要な更新要求の数は非常に多くなり、特に、サービスの利用可能性（アベイラビリティ）やサービスを利用するのに必要な具体的情報が頻繁に変わる場合にはそうである。サービスを提供するノードがモバイルノードである場合も同様である。

ディレクトリサービスの利用に付随するもう１つの欠点は、ディレクトリに基づくサービスは通常、トポロジー的側面、すなわち具体的には、ネットワーク内のリソースやサービスの位置を考慮に入れることができないことである。

また、上記フラディングによる方法の重大な欠点は、スケーラブルでないことである。大規模なネットワークでは、上記の手法は大量の余分なトラフィックを生じ、非常に多くの応答を引き起こす可能性がある。要求されたサービスがネットワーク内のどこにあるかについての対応する指示がなければ、このような検索は、ネットワークのすべてのノードに影響を及ぼす。

本発明は、ダイナミックな環境でも簡単な手段で効率的な検索を可能とし、上記従来の課題を解決しようとするものである。また、本方法はスケーラブルであるべきである。

上記の課題は、請求項１に記載の特徴を備えた方法によって解決される。これによれば、冒頭に述べたようなネットワーク内でサービス、リソースおよび／または機能を検索する方法は、少なくとも１つの宛先ノードおよび／または宛先ノードに近いノードによってネットワーク内の対応する方向が指定されることを特徴とする。この方向により、ソースノードと対応する宛先ノードとの間のルーティングパスが定義される。また、ソースノードと宛先ノードの間のルーティングパスに近いあらかじめ設定可能なノードのみが検索に含まれることを特徴とする。

本発明によって初めて認識されたこととして、ネットワーク側のサービス、リソースおよび／または機能（以下では、単に簡潔にするためであるが、まとめてサービスと称する）の特に効率的な検索は、まず、少なくとも１つの宛先ノードおよび／または宛先ノードに近いノードによってネットワーク内の方向が指定される場合に可能となる。宛先ノード（複数可）は、要求先の通信相手のモバイルデバイスであっても、いくつかの通信相手のモバイルデバイスであってもよい。方向は、宛先ノードの近くに位置するノードによって指定されることも可能である。実施例では、宛先ノードは例えば通信相手の基地局であり得る。別の応用例では、宛先ノードは例えばサーバであり、そこから特定のデータがダウンロードされる。本発明によれば、方向を指定することにより、ソースノードと対応する宛先ノードとの間のルーティングパスが定義され、ルーティングパスはネットワークのある特定の数のノードによって形成される。

本発明によれば、ソースノードと宛先ノードの間のルーティングパスに沿ったあらかじめ設定可能なノードのみが検索に含まれる。これにより、少量のデータのみが生成されて、効率的な検索が可能となる。また、本発明による方法はスケーラブルである。というのは、大規模なネットワークでも、ソースノードと宛先ノードの間のルーティングパスの近くに位置するノードのみが検索に含まれるからである。ネットワークの他のノードは検索による影響を受けない。

本発明による方法は、例えば最新のモバイルネットワークにおいて有効に使用可能である。最新のモバイルネットワークでは、当事者は、良好なアダプテーション、トランスコーディング、キャッシング、ウェブキャッシュおよび／またはＳＩＰプロキシの機能／サーバを見出すという課題を解決しなければならないことが多い。例えばデータストリームのソースへ向かって当事者のホームネットワークからやって来る、方向付きの（有向）検索により、検索対象の機能をデータストリームのルーティングパスの近くで見つけることができる。検索対象のサービスの位置が検索元から、すなわち当事者のモバイルデバイスから離れるほど、本発明による検索パターンは、既知の手法と比べた場合に、より有利になる。したがって、本発明による方法は、ＵＴＲＡＮ、ＷＬＡＮ、ＡＤＳＬ、イーサーネット等のネットワーク間のローミングに特に適している。

ネットワークを出て行くノードがある一方で常に新たなノードがネットワークに入って来ることを特徴とするアドホックネットワークでは、既知のサービスロケーションプロトコル（ＳＬＰ）も、冒頭に述べたいずれの方法も使用可能でない。特に、無線帯域幅が狭く、通常は電力リソースが非常に制限されているため、いわゆるフラディングはコストがかかりすぎる。本発明による方法によって提案される特定方向の検索によれば、このようなアドホックネットワークにおいても効率的な検索が可能である。地理的ルーティング環境では、例えば次の有線アクセスポイントへ向かう検索を実行することができる。この場合、アクセスポイントは、例えば移動や車の運転の向かう方向に位置する。

特に好ましい実施形態では、検索パラメータの指定が提供される。これを用いると、検索に含まれることになる、ルーティングパスに近いノードを指定できる。さらに、検索パラメータは、具体的に検索対象となるサービスの種類に合わせて調整されることが可能である。これにより、高度のフレキシビリティを達成することができる。例えば、ネットワークにおいてめったに提供されないことが既知であるサービスを検索する場合、検索パラメータは、検索に多数のノードが含まれるように定義できる。よく提供されるサービスについては逆のことが同様に成り立つ。

特に好ましい実施形態では、検索パラメータは、ルーティングパスのノードからの側方距離として、すなわち「横方向への延長」として定義される。ここで、側方距離を示すパラメータは任意に選択できる。具体的には、検索パラメータは、例えばルーティングパスのノードからの側方距離のホップ数を示す整数ｉ＝１，...，ｎとすることができる。その結果として、検索パラメータｉ＝２は、ルーティングパスのノードから側方に最大２ホップの距離にあるすべてのノードが検索に含まれることを意味する。別法として、検索パラメータは、例えば地理的距離として、あるいは時間的遅延として定義することも可能である。

別法として、検索パラメータをソースノードからの距離の関数として定義することも考えられる。そうすることにより、ノードが検索に含まれる際の側方距離は、距離が増大すると小さくなるように定義することもできる。このような定義はキャッシュ検索の場合に有益である。というのは、その場合、キャッシュの位置はクライアントの近く、すなわちソースノードの近くが望ましいからである。

検索を開始するため、ソースノードは、自分から１ホップ離れたルーティングパスのノードへメッセージを送ることができる。メッセージは、まず、要求されたサービスに関するデータと、検索パラメータとを含み得る。

また、メッセージは、例えば検索の側方延長の変化等を記述する関数のような、検索に関連する他のデータを含み得る。

宛先ノードの方向へ向かうルーティングパスに沿ってメッセージを伝搬させるため、ルーティングパスの各ノードは、メッセージを初めて受信すると、ルーティングパス上で１ホップ離れた次のノードへメッセージを転送する。

側方方向に検索を延長するため、ルーティングパスの各ノードは、ルーティングパス上の次のノードへメッセージを送信するだけでなく、ルーティングパス上で側方方向に１ホップ離れたノードへもメッセージを送信することができる。このための前提条件は、検索パラメータがそれを許可することである。検索パラメータが上記のようにホップ数ｉとして定義される場合には、結果としてｉはゼロに等しくなり得ない。定義された検索パラメータによる検索の側方延長を制限するため、ルーティングパスの側方に位置し初めてメッセージを受信する各ノードが検索パラメータを変更する（すなわち、例えばホップ数ｉを１だけデクリメントする）ことができる。これが適用可能な場合、すなわちｉがデクリメント後も依然としてゼロよりも大きい場合、ノードは、ルーティングパスからさらに１ホップ離れたノードへ、変更した検索パラメータを有するメッセージを送信することができる。

具体的実施態様では、要求されたサービスを提供できるノードが発見されたらすぐに検索を中断する。このような検索の中断は、主たる重点がサービスの特定の品質にあるのではなく、検索労力の最小化にある場合に特に有利である。別法として、要求されたサービスを指定の品質で提供できるノードが発見された後にのみ検索を中断することも考えられる。品質とはサービスのさまざまな特性を指し、具体的にはその利用可能性、負荷、容量、コスト等とすることができる。

特定のアプリケーションでは、検索を数回実行し、最初の実行では検索パラメータをルーティングパスからの小さい距離として定義すると特に有利であることが分かった。例えば、検索パラメータをｉ＝１と選択することで、ルーティングパスのノードに加えて、ルーティングパスのノードから側方方向にちょうど１ホップだけ離れたノードのみを検索に含めることができる。このような最初の（高速な）実行において、要求された検索基準にマッチするサービスが見つからなかった場合、後続の実行では、検索パラメータをルーティングパスからさらに大きい側方距離として、例えばｉ＝２，３，...と再定義することができる。

要求されたサービスの利用可能性に関して、検索に含まれるノードから得られる情報をソースノードに集約することができると特に有利である。この目的のため、横方向延長の最遠のノードから出発して、対応するメッセージ（以下、エコーと称する）をルーティングパスのノードへ送信し、そこから（宛先ノードから出発して）ソースノードの方向へ送信することができる。すなわち、各ノードはそれに対応する親ノードへ、すなわち当初のメッセージを受信した時の発信元のノードへ、エコーを送信する。エコーは、当該ノード自身の情報とともに、その子ノード、すなわち前に直接または間接にメッセージを送信した送信先のノードの（集約された）情報を含む。

特にモバイルネットワークやアドホックネットワークでは、特定のノードがエコーを送信しないことが起こり得る。その理由としては、例えば、ノードがその電源状態により省電力モードに入っていたり、ノードがしばらくの間ネットワークを出てしまっていたりすることがある。このような場合、ソースノードに確実に情報を集約するメカニズムが有利であることが分かる。この意味で、例えば、ノードはまず、その１つまたは複数の子ノードからエコーを受信しない場合、あらかじめ設定可能な期間（タイムアウト）の間待機することができる。期間経過後もそれぞれのノードからエコーを依然として受信しない場合、対応するノードの情報なしでその親ノードへエコーを送信することができる。このようなエコーに付随する情報の喪失は、ルーティングパスに近いノードの場合のほうが、ルーティングパスからより遠く離れたノードの場合よりも大きいので、ノードに対するタイムアウトは、ルーティングパスの近くに位置するほど長く選択すると有利であろう。したがって、ルーティングパスのノードには最長のタイムアウトが割り当てられ、最遠の側方延長のノードには最短のタイムアウトが割り当てられる。タイムアウトの定義値は、例えば最初にソースノードによって送信され検索に含まれるノードへ転送されたメッセージとともにノードに通知することができる。

一部のノードの利用不能性と、使用されるタイムアウトメカニズムに関して、２通りの場合を区別することができる。まず、ノードが利用不能であることが何らかの理由で既知となっている可能性がある。この意味では、階層化ネットワーク内で、例えば特定のノードが永久的または一時的に利用可能でないことが下位レイヤによって検出される場合がある。このような場合、タイマは、すべてのアクティブなノードからエコーが返された後に初めて開始すればよい。もう１つの状況として、特定のノードが故障しているのかそれとも利用可能でないのかに関して全く情報が入手できないことが起こり得る。このような場合、タイマは、検索に含まれるすべてのノードの間にメッセージが配布された後に初めて開始すると有利である。上記の両方の状況に対するタイムアウトの長さは互いに独立に選択することができる。

検索の終了後、仮想ネットワーク、たとえばオーバーレイネットワークを生成し、あらかじめ設定可能な基準に従い、検索結果に基づいて、それにノードを組み込むことができる。例えば、ノードは、できるだけ低コストあるいはできるだけ大容量となるように選択できる。そして、仮想ネットワークは「トンネルネットワーク」として作用し、現実のネットワークにおけるルーティングを変更することを必要とせずに、仮想ネットワークを通じて、サービスの利用に関するパケットを伝送することができる。

ここで、本発明の教示を有利に実施し、さらに改良する方法には複数の可能性がある。そのために、一方では請求項１に従属する請求項を参照し、他方では本発明の実施例に関する以下の説明を図面とともに参照すべきである。本発明の好ましい実施形態の説明に関しては、教示の一般的に好ましい実施形態および改良形態も説明される。

まず、図１は、多数のノードを備えたネットワークの概略図である。ここで、各ノードは２直線の交点として示されている。ネットワーク内の通信はルーティングメカニズムに基づく。ネットワークの各ノードには、ルーティング可能なネットワークアドレスが割り当てられる。

ネットワーク側サービスの検索が開始されるソースノードＱは、塗りつぶした黒い四角で示されている。検索は方向付きで、すなわち、同じく黒く塗りつぶされ宛先ノードＺを表す四角へ向かう方向に、実行される。ソースノードＱと宛先ノードＺの間にルーティングパスが形成される。ルーティングパスの個々のノードは、黒点付きの白丸で表される。ここで再度指摘しておくが、検索は、複数の異なる宛先ノードＺへ向かう方向に、対応する数のルーティングパスに沿って実行されることも可能である。分かりやすくするため、図にはただ１つの宛先ノードＺと、それに対応して１つのルーティングパスのみが示されている。

検索を開始するには、まず、「ＯｎＳｔａｒｔ」というプロセスを実行する。この「ＯｎＳｔａｒｔ」ルーチンにおいて、ソースノードＱは、自分から１ホップ離れたルーティングパスのノードを呼び出し、このノードへメッセージを送信する。メッセージは、検索すべきサービスに関する制御メッセージと、検索パラメータを含む。

検索パラメータは、検索がルーティングパスから側方方向へどのくらい遠くまで延長されるべきかを示す。詳細には、検索パラメータは、ルーティングパスのノードからｉホップ側方方向に位置するノードが検索に含まれることを示す整数ｉとして定義される。図示の例では、ｉはｉ＝１に選択されている。すなわち、ルーティングパス上で側方方向に直接隣接しているノードのみが検索に含まれる。図中、検索に含まれるすべてのノードは白丸で示されている。

ルーティングパスの最初のノードは、ソースノードＱからメッセージを受信するとすぐに、「ＯｎＩｎｉｔｉａｔｅ」ルーチンを実行する。このルーチンでは、メッセージに含まれる情報に基づいて、まず、自分が中間ノードであるかどうかをチェックする。中間ノードである場合、ルーティングパスでメッセージの送信先となる次の隣接ノードを判定する。さらに、検索の側方延長に関するメッセージに含まれる検索パラメータの解析も行う。図示した例、すなわちｉ＝１の場合では、ノードは、その側方近傍内のノードにもメッセージを送信する。側方ノードは、メッセージを受信し、自分が中間ノードでない、すなわちルーティングパス上にないと判断する。そこで側方ノードは検索パラメータを値１だけデクリメントする。その結果が０よりも大きい場合、あらかじめ設定可能な期間待機してから、さらに遠方のノードへメッセージを送信する。図示した例では、デクリメント後、結果はゼロに等しい。このため、メッセージは転送されない。すなわち、側方の横方向延長における検索は中断する。

次のステップで、「ＯｎＡｇｇｒｅｇａｔｅ」ルーチンが実行される。ここで、検索に含まれるノードから得られた利用可能性に関する（そして、該当する場合には、その品質に関する）すべての情報がソースノードＱに集約される。各ノードは自己の子、すなわち自己のメッセージを送信した先のノードおよびその子のリストを保持している。ノードが「ＯｎＡｇｇｒｅｇａｔｅ」ルーチンにおいてそのすべての子からエコーを受信した場合、「ＯｎＣｏｍｐｌｅｔｅ」というメソッドを開始する。すなわち、検索に関するその活動を終了する。子のないノード、すなわち、ルーティングパスから側方方向に最も遠く離れているノードについても同様である。

ソースノードＱが、そのすべての子からエコーを受信するとすぐに、「ＯｎＴｅｒｍｉｎａｔｅ」ルーチンが実行される。このルーチンは検索の終了である。

検索されたサービスの利用可能性に関して、検索の終了後、ソースノードＱでは、検索に含まれたすべてのノードの情報が利用可能である。また、例えば検索されたサービスについてノードがどのくらいのデータを処理できるかや、このサービスの利用のためのコストを示す付加情報によって、オーバーレイネットワークが生成される。このオーバーレイネットワークは、あらかじめ設定可能な基準（例えば、最も費用効果の高いパス、最も低い負荷等）に最適一致するノードを含む。オーバーレイネットワークのために選択されるノード（図中、灰色の四角で囲まれている）はトンネルを形成する。ネットワーク内のルーティングを変更することを必要とせずに、このトンネルを通じてパケットを伝送することができる。

最後に、特に指摘しておくべきことであるが、上記の任意に選択された実施例は単に本発明の教示を説明するためのものに過ぎず、決して本発明を実施例に限定するものではない。

本発明によるネットワークの構造と、ネットワーク内でサービス、リソースおよび／または機能を検索する方法の基本機能の概略図である。

Claims (21)

1. ルーティング可能なネットワークアドレスが割り当てられた多数のノードを備えたネットワーク内で、サービス、リソースおよび／または機能を検索する方法において、
   検索対象のサービス、リソースおよび／または機能、はソースノードによって指定され、
   少なくとも１つの宛先ノードおよび／または該宛先ノードから所望ホップ数離れたノードによって前記ネットワーク内の方向が指定され、
   前記指定された方向により、前記ソースノードと対応する宛先ノードとの間のルーティングパスが定義され、
   前記ソースノードと前記対応する宛先ノードとの間の前記ルーティングパスから予め設定可能なホップ数の範囲内のノードのみが前記検索に含まれ（ただし、前記ルーティングパスとは異なる迂回パスの検索を除く。）、前記ルーティングパスから予め設定可能なホップ数の範囲内のノードの各々が前記ルーティングパス上のノードから前記ルーティングパスに対して横方向に少なくとも１ホップ離れている、ことを特徴とする検索方法。
2. 前記検索に含まれる前記ルーティングパスから１ホップ以上離れたノードが、あらかじめ設定可能な検索パラメータによって定義されることを特徴とする請求項１に記載の方法。
3. 前記検索パラメータが、具体的に検索されるサービス、リソースおよび／または機能の種類に合わせて調整されることを特徴とする請求項２に記載の方法。
4. 前記検索パラメータが、前記ルーティングパスからの前記ノードの距離として定義されることを特徴とする請求項２または３に記載の方法。
5. 前記検索パラメータが、前記ルーティングパスからのホップ数、地理的距離または遅延として定義されることを特徴とする請求項４に記載の方法。
6. 前記検索パラメータが、前記ソースノードからの距離の関数として定義されることを特徴とする請求項２〜５のいずれか１項に記載の方法。
7. 前記検索を開始するために、前記ソースノードが１ホップ離れた前記ルーティングパスのノードへメッセージを送信し、該メッセージが、検索されるサービス、リソースおよび／または機能に関する指定と、前記検索パラメータとを含むことを特徴とする請求項２〜６のいずれか１項に記載の方法。
8. 前記ルーティングパスの各ノードが、初めて前記メッセージを受信すると、前記ルーティングパスの次のノードへ該メッセージを転送することを特徴とする請求項７に記載の方法。
9. 前記ルーティングパスの各ノードが、前記検索パラメータに従って、前記ルーティングパスから１ホップ離れたノードへ前記メッセージを送信することを特徴とする請求項７に記載の方法。
10. 前記ルーティングパスから離れて位置し初めて前記メッセージを受信した各ノードが、前記検索パラメータを変更し、前記検索を延長する場合には、変更した検索パラメータを有するメッセージを、前記ルーティングパスからさらに１ホップ遠方に離れたノードへ送信することを特徴とする請求項９に記載の方法。
11. 前記ルーティングパスから離れて位置し初めて前記メッセージを受信した各ノードが、前記検索パラメータのホップ数を１だけデクリメントすることを特徴とする請求項１０に記載の方法。
12. 前記検索対象のサービス、リソースおよび／または機能を提供できるノードが発見されると、前記検索を終了させることを特徴とする請求項１〜１１のいずれか１項に記載の方法。
13. 前記検索対象のサービス、リソースおよび／または機能をあらかじめ設定可能な品質で提供できるノードが発見されると、前記検索を終了させることを特徴とする請求項１〜１１のいずれか１項に記載の方法。
14. 前記検索を数回実行し、初回の実行に対する前記検索パラメータは、前記ルーティングパスのノードからちょうど１ホップ離れた範囲のノードのみが前記検索に含まれるように定義されることを特徴とする請求項２〜１３のいずれか１項に記載の方法。
15. 後続の実行に対する前記検索パラメータは、初回の実行後に前記検索に対応するサービス、リソースおよび／または機能が発見されなかった場合に、前記ルーティングパスからさらに遠方までの距離として定義されることを特徴とする請求項２〜１３のいずれか１項に記載の方法。
16. 前記検索に含まれるノードから得られた情報および検索されたサービス、リソースおよび／または機能の利用可能性に関する情報が前記ソースノードに集約されることを特徴とする請求項１〜１５のいずれか１項に記載の方法。
17. 前記検索に含まれるノードから得られた情報および検索されたサービス、リソースおよび／または機能の利用可能性に関する情報が前記ソースノードに集約され、
    前記情報を前記ソースノードに集約するために、各ノードが、前記メッセージを受信した直近上位ノードである親ノードへ対応するエコーを送信し、該エコーは、該ノード自身の情報と、前に直接または間接に前記メッセージを送信した先の自己の子ノードの情報とを含むことを特徴とする請求項８に記載の方法。
18. ノードが自己の１つまたは複数の子ノードからエコーを受信しない場合、対応する子ノードの情報なしで自己の親ノードへエコーを送信する前に、あらかじめ設定可能な期間、すなわちタイムアウトの間待機することを特徴とする請求項１７に記載の方法。
19. 該ノードが前記ルーティングパスのノードのより近くに配置されているほど、前記タイムアウトがより長く選択されることを特徴とする請求項１８に記載の方法。
20. 前記検索の終了後、あらかじめ設定可能な基準に従って、検索結果に基づいて、ノードが組み込まれた仮想ネットワークが生成されることを特徴とする請求項１〜１９のいずれか１項に記載の方法。
21. 前記仮想ネットワークはオーバーレイネットワークであることを特徴とする請求項２０項に記載の方法。
    

Images