JP6047229B2 - 情報中心ネットワークにおける名前ベースの近隣探索及びマルチホップサービス探索 - Google Patents

Description

本出願は、Ｘｉｎｗｅｎ Ｚｈａｎｇ等により２０１２年４月２０日に出願された「Ａ Ｍｅｔｈｏｄ ｆｏｒ Ｎａｍｅ−Ｂａｓｅｄ Ｎｅｉｇｈｂｏｒ Ｄｉｓｃｏｖｅｒｙ ａｎｄ Ｍｕｌｔｉ−Ｈｏｐ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ ｉｎ Ｃｏｎｔｅｎｔ−Ｏｒｉｅｎｔｅｄ Ｎｅｔｗｏｒｋ Ａｒｃｈｉｔｅｃｔｕｒｅ」と題する米国仮出願第６１／６３６，４３０号の優先権を主張する、Ｘｉｎｗｅｎ Ｚｈａｎｇ等により２０１２年１０月２３日に出願された「Ｎａｍｅ−Ｂａｓｅｄ Ｎｅｉｇｈｂｏｒ Ｄｉｓｃｏｖｅｒｙ ａｎｄ Ｍｕｌｔｉ−Ｈｏｐ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ ｉｎ Ｉｎｆｏｒｍａｔｉｏｎ−Ｃｅｎｔｒｉｃ Ｎｅｔｗｏｒｋ」と題する米国仮出願第１３／６５８，２９９号の優先権を主張し、それら双方は、参照することにより、その全体が再現されたかの如く、ここに援用される。

コンテンツ中心ネットワーク（Ｃｏｎｔｅｎｔ−Ｃｅｎｔｒｉｃ Ｎｅｔｗｏｒｋ）又はＮａｍｅｄ Ｄａｔａ Ｎｅｔｗｏｒｋ（ＮＤＮ）等の、情報中心ネットワーク（Ｉｎｆｏｒｍａｔｉｏｎ−Ｃｅｎｔｒｉｃ Ｎｅｔｗｏｒｋ）（ＩＣＮ）（本明細書においては総括して、ＩＣＮｓと言及される）において、コンテンツルータは、ユーザの要求及びコンテンツを適切な複数の受信者に対してルーティングする役割を担う。ＩＣＮにおいて、コンテンツ配信フレームワークの一部である各エンティティに対して、ドメイン全体で一意的な名前が割り当てられる。これらのエンティティは、ビデオクリップ又はウェブページ等のデータコンテンツ及び／又はルータ、スイッチ、又はサーバ等のインフラストラクチャ要素を含んでもよい。コンテンツルータは、コンテンツネットワーク内で、複数のコンテンツパケットを特定のルートで送るために、複数のネットワークアドレスの代わりに、複数の完全なコンテンツ名又は複数のコンテンツ名の複数のプレフィックスであり得る、複数の名前プレフィックスを使用する。ＩＣＮｓにおいて、出版、要求、管理（例えば、変更、削除等）を含むコンテンツ配信は、コンテンツ名に基づいてもよく、かつコンテンツの場所に基づかなくてもよい。従来の複数のインターネットプロトコル（ＩＰ）ネットワークとは異なっている可能性のあるＩＣＮｓの一側面は、複数の地理的ポイントを相互接続し、かつコンテンツを一時的にキャッシュする又はより持続的にコンテンツを記憶するＩＣＮｓの能力である。これは、コンテンツが、元のサーバに代えて、ネットワークから提供されることを可能とする場合があり、そして従って、ユーザの使用感を大幅に改善する可能性がある。キャッシング／記憶は、ユーザにより取得される実時間データ又はユーザ又は第三者のプロバイダ等であるコンテンツプロバイダのものである持続的なデータについて使用されてもよい。

ＩＣＮにおけるサービス探索の問題を考える。そのコピーをｗｗｗ．ｚｅｒｏｃｏｎｆ．ｏｒｇにおいて見つけることが可能であり、かつ参照することにより、その全体が再現したかの如くここに援用される、Ｚｅｒｏ Ｃｏｆｉｇｕｒａｔｉｏｎ Ｎｅｔｗｏｒｋｉｎｇ（Ｚｅｒｏｃｏｎｆ）において記載されるように、ＩＰ上に構築されたアドレスベースのサービス探索以外に、名前ベースのサービス探索の解決手段があると好ましい。この目的に対して、除外フィルタ（ＥＦ）メカニズムが提案されており、かつＣＣＮｘにおいて実装されている。ここで、発見された複数のサービス名は、同じ名前プレフィックスの繰り返される探索関連の複数のメッセージの除外フィルタに含まれ、かつこのフィルタ内のサービス名で返された複数のデータメッセージは除外されることになるので、各ラウンドにおいて、せいぜい、存在する場合に新しいサービス名が発見されるだけとなる。（ＥＦメカニズムの詳細情報は、参照することにより、その全体が再現されたかの如くここに援用される、ｃｏｎｆｅｒｅｎｃｅｓ．ｓｉｇｃｏｍｍ．ｏｒｇ／ｓｉｇｃｏｍｍ／２０１１／ｐａｐｅｒｓ／ｉｃｎ／ｐ６８．ｐｄｆにて見出すことが可能である。）しかしながら、除外されるサービス名の数に応じて、単一の探索セッションは、関連データメッセージ交換の複数のラウンドを必要とするので、このＥＦメカニズムは、効率的ではない場合があり、かつ探索されるサービス名の不明な数のため、いつディスカバリプロトコルを終了すべきかを決定することは、エンドユーザにとって困難となる場合がある。

一実施例において、開示は、コンテンツルータであって、情報中心ネットワーク内の他の複数のノードに対する複数の物理リンク、複数のメッセージを受信するように構成される前記複数の物理リンクと結合される受信部、複数のメッセージを送信するように構成される、前記複数の物理リンクと結合される送信部、及び前記受信部及び前記送信部に結合されるプロセッサ及びメモリ装置を含む、サービス公開及び探索（ＳＰＤ）モジュールであって、前記ＳＰＤは、前記複数の物理リンクの複数のステータスの更新を記憶するように構成される、サービス公開及び探索（ＳＰＤ）モジュール、を備え、前記ＳＰＤは、受信したメッセージを転送するための次のホップ及びホップの数を、受信したメッセージの名前ベースのサービス探索プロトコル名の中のプレフィックスに基づいて決定するように構成される、コンテンツルータ、を含む。

他の実施例において、開示は、ネットワークノードであって、情報中心ネットワーク内の複数の遠隔ノードからの／へのインタレスト（ｉｎｔｅｒｅｓｔ）メッセージ及びデータメッセージを受信／送信するように構成される複数のインターフェース、前記複数のインターフェースと結合するプロセッサを含むリンクマネージャ（ＬＭ）であって、前記ＬＭは、前記複数のインターフェースを監視するように構成される、リンクマネージャ（ＬＭ）、及びプロセッサを含みかつ前記複数のインターフェース及び前記ＬＭに結合されるローカルサービス公開及び探索（ＳＰＤ）モジュールであって、前記ローカルＳＰＤモジュールは、ローカルノード上の複数のサービスにより公開された複数のサービスプロファイルと前記複数の遠隔ノードの中の複数の遠隔ＳＰＤから収集された複数のサービスプロファイルとを集約するように構成され、複数のローカルサービスは、前記ローカルＳＰＤに対してのみ公開され、前記ローカルＳＰＤは、前記ローカルノードから指定されたホップ内の前記複数の遠隔ノードのうちの到達可能な１つにおける利用可能なサービスを探索するように構成され、かつ前記ＳＰＤモジュールは、前記複数のサービスプロファイルの名前ベースのサービス探索プロトコル名の中のプレフィックスに基づき、対応する複数のインターフェースを持つ前記複数の遠隔ノードを構成及び登録するように構成される、ローカルサービス公開及び探索（ＳＰＤ）モジュール、を備え、前記ＬＭは、前記複数の遠隔ノードのうちの１つに対する新しいリンクが前記複数のインターフェースのうちの１つにおいて検出された場合に、前記ローカルＳＰＤに通知するように構成される、ネットワークノード、を含む。

第３の態様において、開示は、情報中心ネットワークの中の複数のサービスを発見する方法であって、複数のローカルサービスの複数のサービスプロファイルを受信するステップ、プロセッサにより遠隔ノードに対するインタレストメッセージを準備するステップであって、前記インタレストメッセージは、複数のサービスプロファイル及びホップ数の要求を含み、前記ホップ数は前記インタレストメッセージを転送するためのホップの数を示す、準備するステップ、前記遠隔ノードからデータメッセージを受信するステップであって、前記データメッセージは前記遠隔ノードにより及び前記ローカルノードの前記ホップ数内の前記遠隔ノードと結合された他の複数の遠隔ノードから提供される複数のサービスに対する集約された複数のサービスプロファイルを含む、受信するステップ、及びプロセッサにより、前記複数のローカルサービスの前記複数のサービスプロファイル及び前記遠隔ノードから受信した前記集約された複数のサービスプロファイルを集約するステップ、を備える、方法、を含む。

これら及び他の特徴は、以下の詳細な説明を添付の図面及び特許請求範囲と併せて考慮することにより、より明確に理解されるであろう。

本開示のより完全な理解のために、今、添付図面及び詳細な説明と関連して考慮される以下の簡単な説明が参照される。ここで、同様な参照符号は、同様な部分を表す。

実施例に従う、探索のための拡張されたＣＣＮノードのアーキテクチャを示すブロック図である。

実施例に従う、ＳＰＤモジュールの包括的な機能を示すブロック図である。

開示される実施例に従う、複数の隣接関係の例示的な設定方法を示すブロック図である。 開示される実施例に従う、複数の隣接関係の例示的な設定方法を示すブロック図である。 開示される実施例に従う、複数の隣接関係の例示的な設定方法を示すブロック図である。 開示される実施例に従う、複数の隣接関係の例示的な設定方法を示すブロック図である。 開示される実施例に従う、複数の隣接関係の例示的な設定方法を示すブロック図である。 開示される実施例に従う、複数の隣接関係の例示的な設定方法を示すブロック図である。 開示される実施例に従う、複数の隣接関係の例示的な設定方法を示すブロック図である。

開示される実施例に従う、複数の隣接ノードがノードのグループに加わるための例示的な方法を示すブロック図である。 開示される実施例に従う、複数の隣接ノードがノードのグループに加わるための例示的な方法を示すブロック図である。 開示される実施例に従う、複数の隣接ノードがノードのグループに加わるための例示的な方法を示すブロック図である。 開示される実施例に従う、複数の隣接ノードがノードのグループに加わるための例示的な方法を示すブロック図である。

開示される実施例に従う、隣接ノードがノードのグループから離れるための例示的な方法を示すブロック図である。 開示される実施例に従う、隣接ノードがノードのグループから離れるための例示的な方法を示すブロック図である。

開示される実施例に従う、０−ホップサービス探索の例示的な方法を示すブロック図である。 開示される実施例に従う、０−ホップサービス探索の例示的な方法を示すブロック図である。 開示される実施例に従う、０−ホップサービス探索の例示的な方法を示すブロック図である。 開示される実施例に従う、０−ホップサービス探索の例示的な方法を示すブロック図である。

開示される実施例に従う、ノードのグループ内で１−ホップ離れたサービスを探索する例示的な方法を示すブロック図である。 開示される実施例に従う、ノードのグループ内で１−ホップ離れたサービスを探索する例示的な方法を示すブロック図である。 開示される実施例に従う、ノードのグループ内で１−ホップ離れたサービスを探索する例示的な方法を示すブロック図である。 開示される実施例に従う、ノードのグループ内で１−ホップ離れたサービスを探索する例示的な方法を示すブロック図である。 開示される実施例に従う、ノードのグループ内で１−ホップ離れたサービスを探索する例示的な方法を示すブロック図である。 開示される実施例に従う、ノードのグループ内で１−ホップ離れたサービスを探索する例示的な方法を示すブロック図である。

開示される実施例に従う、２−ホップサービス探索の例示的な方法を示すブロック図である。 開示される実施例に従う、２−ホップサービス探索の例示的な方法を示すブロック図である。 開示される実施例に従う、２−ホップサービス探索の例示的な方法を示すブロック図である。 開示される実施例に従う、２−ホップサービス探索の例示的な方法を示すブロック図である。 開示される実施例に従う、２−ホップサービス探索の例示的な方法を示すブロック図である。 開示される実施例に従う、２−ホップサービス探索の例示的な方法を示すブロック図である。 開示される実施例に従う、２−ホップサービス探索の例示的な方法を示すブロック図である。 開示される実施例に従う、２−ホップサービス探索の例示的な方法を示すブロック図である。

送信／受信部の実施例の概略図である。

汎用コンピュータシステムの実施例の概略図である。

１つ以上の実施例の例示的実装が以下に与えられるが、開示された複数のシステム及び／又は複数の方法は、現在知られているか又は存在するかにかかわらず、任意の数の技術を使用して実施されてもよい、ということが最初に理解されるべきである。この開示は、本明細書において示されかつ説明される例示的な複数の設計及び実装を含む、以下に示される例示的な複数の実装、複数の図面、及び複数の技術には決して限定されるべきではないが、この開示は、それらの複数の均等物の全範囲と共に、添付の複数の特許請求項の範囲の中で変更され得る。

例えば、名前ベースの近隣探索プロトコル及び名前ベースのサービス探索プロトコル等の２つの基本的なプロトコルを含む、ＩＣＮにおける名前ベースの近隣及びサービス探索方式が本明細書において開示される。これらの名前ベースの探索プロトコル及び名前ベースのサービス探索プロトコルを、例えば、コンテンツ中心ネットワーク（ＣＣＮ）等の情報中心ネットワーク（ＩＣＮ）に適用することは、トランスポートモデル（ｔｒａｎｓｐｏｒｔａｔｉｏｎ ｍｏｄｅｌ）における如何なる変更も必要としない。サービス公開及び探索（ＳＰＤ）モジュールを組み込んだＩＣＮノードアーキテクチャが開示される。実施例において、複数の近隣関係の設定及び維持を解決するために、名前ベースの近隣探索プロトコルが提供される。このプロトコルは、ＩＣＮノードが起動した場合に初期化され、かつＳＰＤにおいて独立して実行を継続してもよい。実施例において、単一のサービス探索セッションにおける、起点ノードから複数ホップ以内の到達可能な複数のノードにより知られる全ての利用可能なサービス（プロファイル）を発見するための、名前ベースのサービス探索プロトコルが提供される。名前ベースの近隣探索プロトコルにより、複数のサービス探索インタレスト（ｉｎｔｅｒｅｓｔ）メッセージについて、いくつかの必要な転送情報ベース（ＦＩＢ）の複数のエントリが設定された後、名前ベースのサービス探索プロトコルが実行されてもよい。名前ベースの近隣探索プロトコルは、複数の中間ノードであって、そこから収集及び集約されたサービスプロファイルが配信され得る、複数の中間ノード、の複数のインターフェース（本明細書においては、複数のフェースとも言及される）をたどることにより、起点ノードから複数の遠隔ノードにおける任意の利用可能なサービスへの第１の利用可能な経路を見つけることが可能であってもよい。実施例において、アプリケーションは、そのサービスプロファイルに基づいて、サービスを要求することを決定してもよい。開示される複数の方法、システム、装置、及び図は、本明細書において、主に、ＣＣＮに関して開示される。しかしながら、同一又は類似の複数の方法、システム、及び装置は、任意のＩＣＮアーキテクチャに適用することが可能であるということを当業者は認識するであろう。

図１は、実施例に従う、探索のための拡張されたＣＣＮノードのアーキテクチャ１００を示すブロック図である。ＣＣＮノードアーキテクチャ１００は、サービス公開及び探索（ＳＰＤ）コンポーネント１１２、リンクマネージャ（ＬＭ）１４、ＣＣＮアプリケーション及びサービスコンポーネント１０２、ＣＣＮデーモン（ｃｃｎｄ）１０４、及び複数の物理リンク１１６を含んでもよい。複数の物理リンクは、トランスミッションコントロールプロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）ベースの複数のリンク、複数のイーサネットリンク、複数の拡張デジタル加入者線（ＸＤＳＬ）リンク、複数のＷｉＦｉリンク、３Ｇ及び４Ｇの複数の無線リンク、及び複数のＢｌｕｅｔｏｏｔｈ（登録商標）リンクを含んでもよい。ｃｃｎｄ１０４は、コンテンツストア（ＣＳ）１０６、保留中のインタレスト（ｉｎｔｅｒｅｓｔ）の表（ＰＩＴ）１０８、及び転送情報ベース（ＦＩＢ）１１０を含んでもよい。ＣＳ１０６は、コンテンツを記憶してもよく、そして、インタレストパケットが受信された場合、要求されたコンテンツがＣＳ１０６の中に記憶されているかどうか決定するためにＣＳ１０６は確認されてもよい。要求されたコンテンツがＣＳ１０６の中に記憶されている場合、当該コンテンツはＣＳ１０６から取得され、かつ要求者に提供されてもよい。また、ネットワーク内の他の複数の場所から取得されたコンテンツは、ＣＳ１０６の中に記憶されてもよい。ＰＩＴ１０８は、コンテンツに関する保留中の複数の要求及び複数のインターフェースであって、それに対して関連するコンテンツが要求された、複数のインターフェース、の表示を記憶してもよい。データパケットが受信された場合、保留中の複数の要求について、ＰＩＴ１０８が確認されてもよい。保留中の要求が検出された場合、データパケットは、ＣＳ１０６の中に記憶されてもよく、かつＰＩＴの中にリストされた複数のインターフェースに対して転送されてもよい。ＰＩＴエントリが見つからない場合、データパケットは破棄されてもよい。ＦＩＢ１１０は、複数のコンテンツ名のプレフィックスを、１つ又は複数の次のホップルータに対して関連付けるテーブル又は他のデータ構造を含んでもよい。ｃｃｎｄ１０４は、通常のルーティング、転送及びキャッシュ機能を備えたネットワークスタックとして実行することができる。ＳＰＤモジュール１１２は、アプリケーションレベルにおいて、ローカルに実行することができる。ＳＰＤモジュール１１２は、プロセッサ及び／又はメモリ（又は記憶）コンポーネントを含んでもよい。ＳＰＤモジュール１１２は、隣接する複数のコンテンツルータ及び隣接する複数のコンテンツルータにおいて利用可能な複数のサービスについての情報を含んでもよい。ＬＭ１１４は、プロセッサを含んでもよい。実施例において、ＳＰＤモジュール１１２及びＬＭ１１４はプロセッサを共有してもよい。ＬＭ１１４は、全ての物理リンク１１６の接続を監視してもよく、かつ全ての物理リンク１１６のステータスの更新をＳＰＤモジュール１１２に通知してもよい。

開示される名前ベースの近隣探索プロトコルにおいて、近傍は、ターゲットノードに対する直接の接続により定義され、かつ１ホップの範囲内に限定される。実施例において、利用可能なＬＭ１１４は、全ての物理リンク１１６の接続を監視し、かつ全ての物理リンク１１６の複数のステータス更新をＳＰＤ１１２モジュールに通知することが仮定される。複数の隣接関係の設定及び維持は、図１のノードアーキテクチャ１００に基づく、開示される名前ベースの近隣探索プロトコルにより解決される可能性のある複数の問題のうちのいくつかである。名前ベースの近隣探索プロトコルは、ノード１００が起動した場合に初期化され、かつＳＰＤ１１２において独立して実行を継続してもよい。任意のリンク状態が更新され次第すぐに、開示される名前ベースの近隣探索プロトコルは、ＬＭ１１４により起動されることが可能であってもよい。

図２は、実施例に従うＳＰＤモジュール２０４の複数の機能を示す、システム２００のブロック図である。ＳＰＤモジュール２０４は、図１に示されるＳＰＤモジュール１１２として実装されてもよい。ローカルノード２０２において利用可能なＬＭ（図示せず）は、全ての物理リンクの接続を監視してもよく、かつ、例えば、図１に示される複数の物理リンク１１６等の、全ての物理リンクの状態の更新をＳＰＤモジュール２０４に通知してもよい。各サービスがそのサービスプロファイルを直接ネットワークに公開することが可能な従来の複数の方式とは対照的に、開示されるサービス公開メカニズムにおいて、各サービスプロファイル２０６、２０８は、ローカルＳＰＤモジュール２０４に対してその（複数の）サービスを公開してもよい。ＳＰＤモジュール２０４は、ローカルノードにおいて公開された複数のサービスを管理し、ローカルノード２０２において公開されたサービスプロファイル２０６、２０８及び遠隔ノード（図示せず）から収集された複数のサービスプロファイルを集約し、かつ収集及び集約された複数のサービスプロファイルを含み得るデータメッセージによりサービス探索インタレスト（ｉｎｔｅｒｅｓｔ）メッセージに対して応答してもよい。

開示される名前ベースのサービス探索方式は、ＣＣＮのトランスポートモデルに対して如何なる変更も必要としないかもしれず、そしてエンドユーザは、探索セッションにおいて、単一の探索インタレストメッセージを用いることだけが必要であってもよい。開示される名前ベースのサービス探索方式は、例えば、名前ベースの近隣探索プロトコル及び名前ベースのサービス探索プロトコル等の、２つの基本的なプロトコルを含んでもよい。

本明細書において、各種構成要素、サービス、メッセージ、及びプロトコルを記述するためのいくつかの符号が表１に示される。
表１：符号

図３−９は、開示される実施例に従う、複数の近隣関係を設定するための例示的な方法を示すブロック図である。図３に示されるステップ１において、ノード「２」３０２に関して、各ノード３０１−３０３が起動される場合、ノード「２」３０２のＳＰＤ２ ３１２は、特定のフェース「ｆ２ｓ」を使用して、最初にノード「２」３０２の「ｃｃｎｄ２」と結合されていてもよく、そして、例えば、近隣探索に関する「／ｎｄｉｓ：ｆ２ｓ」及びサービス探索に関する「／ｓｄｉｓ：ｆ２ｓ」といった、２つの特定のＦＩＢエントリを事前に設定してもよい。事前に定義された言語構成要素「／ｎｄｉｓ」を含む、任意の近隣探索インタレストメッセージ及び事前に定義された言語構成要素「／ｓｄｉｓ」を含む、任意のサービス探索インタレストメッセージは、正確なプレフィックスの一致がない場合、２つの事前に定義されたＦＩＢエントリと一致する最も長いプレフィックスに基づいて、フェース「ｆ２ｓ」を介して、ノード「２」３０２のＳＰＤ２ ３１２に転送されてもよい。ノード「１」３０１及びノード「３」３０３が起動される場合、ノード「１」３０１及びノード「３」３０３は、ノード「２」３０２と同様な方法で実行される。

図４に示されるステップ２において、ノード３０１−３０３のいずれかが互いに接続を開始して、かつ新しい複数の物理リンクを設定した場合、各ノード３０１−３０３におけるＬＭ（図示せず）は、全ての物理リンクの接続を監視し、かつ全ての物理リンクの状態の更新を、ＳＰＤモジュール３１１−３１３に通知する。ノード「２」３０２に関して、ノード「２」３０２のＬＭからノード「１」３０１及びノード「３」３０３に対して新しく接続されたリンクについてのリンク更新通知を受信した場合、ＳＰＤ２ ３１２は、まず、２つの接続された物理リンク「ｆ２１＠ｎ２−−ｆ１１＠ｎ１」及び「ｆ２２＠ｎ２−−ｆ３１＠ｎ３」について、ノード「２」３０２における「ｃｃｎｄ２」の２つの新しいフェースである「ｆ２１」及び「ｆ２２」を構成及び登録してもよい。また、ＳＰＤ３１２は、フェース「ｆ２１」と関連付けられるランダム系列「ｒ２１」及びフェース「ｆ２２」と関連付けられるランダム系列「ｒ２２」を生成してもよい。その後、ＳＰＤ２ ３１２は、近隣探索の実行のために、２つの個別のＦＩＢエントリ「／ｎｄｉｓ／ｒ２１：ｆ２１」及び「／ｎｄｉｓ／ｒ２２：ｆ２２」を設定してもよい。

ランダム系列「ｒ２１」は、複数の近隣探索インタレストメッセージの個別の名前プレフィックス「／ｎｄｉｓ／ｒ２１」を作成するために使用されてもよく、かつ同じノード「２」における「／ｎｄｉｓ／ｒ２２」、その隣接ノード「１」における「／ｎｄｉｓ／ｒ１１」、及びその隣接ノード「３」における「／ｎｄｉｓ／ｒ３１」を含む、既存の複数のプレフィックスとの競合を防止してもよい。複数の名前プレフィックスを含めることにより、個別の名前プレフィックス「／ｎｄｉｓ／ｒ２１」を伴う近隣探索インタレストメッセージは、既存の個別ＦＩＢエントリ「／ｎｄｉｓ／ｒ２１：ｆ２１」との正確なプレフィックスの一致に基づき、フェース「ｆ２１」を介して、ソースノード「２」３０２から隣接ノード「１」３０１に転送されてもよい、ということが規定されてもよい。

新しい複数のリンクに対するＬＭからの複数のリンク更新通知を受信する場合に、ノード「１」３０１及び「３」３０３は、ノード「２」３０２と同じような方法で実行されてもい。

図５に示されるステップ３において、ノード「２」３０２に注目して、ＳＰＤ２ ３１２は、２つの接続された物理リンク「ｆ２１＠ｎ２−−ｆ１１＠ｎ１」及び「ｆ２２＠ｎ２−−ｆ３１＠ｎ３」それぞれに関して、個別の名前プレフィックスを伴う２つの新しい近隣探索インタレストメッセージ「Ｉ１（ｎｍ＝／ｎｄｉｓ／ｒ２１）」及び「Ｉ３（ｎｍ＝／ｎｄｉｓ／ｒ２２）」を作成し、そしてその後、フェース「ｆ２ｓ」を介して、ノード「２」３０２における「ｃｃｎｄ２」に対して、２つの新しい近隣探索インタレストメッセージを送信してもよい。ノード「２」３０２における「ｃｃｎｄ２」は、２つの送出されるインタレストメッセージ「Ｉ１（ｎｍ＝／ｎｄｉｓ／ｒ２１）」及び「Ｉ３（ｎｍ＝／ｎｄｉｓ／ｒ２２）」それぞれに関して、２つの新しい個別ＰＩＴエントリ「／ｎｄｉｓ／ｒ２１：ｆ２ｓ」及び「／ｎｄｉｓ／ｒ２２：ｆ２ｓ」を作成してもよい。ノード「２」３０２における「ｃｃｎｄ２」は、既存の個別ＦＩＢエントリ「／ｎｄｉｓ／ｒ２１：ｆ２１」との正確な一致に基づき、フェース「ｆ２１」を介して、「Ｉ１」をノード「１」３０１における隣接「ｃｃｎｄ１」に転送してもよい。また、「ｃｃｎｄ２」も、既存の個別ＦＩＢエントリ「／ｎｄｉｓ／ｒ２２：ｆ２２」との正確な一致に基づき、フェース「ｆ２２」を介して、「Ｉ３」をノード「３」３０３における隣接「ｃｃｎｄ３」に転送してもよい。

着信するインタレストメッセージ「Ｉ１（ｎｍ＝／ｎｄｉｓ／ｒ２１）」を受信する場合、ノード「１」３０１における「ｃｃｎｄ１」は、新しい個別ＰＩＴエントリ「／ｎｄｉｓ／ｒ２１：ｆ１１」を作成してもよく、かつ事前に定義されたＦＩＢエントリ「／ｎｄｉｓ：ｆ１ｓ」と一致する最も長いプレフィックスに基づき、フェース「ｆ１ｓ」を介して、「Ｉ１」をＳＰＤ１ ３１１に転送してもよい。着信するインタレストメッセージ「Ｉ３（ｎｍ＝／ｎｄｉｓ／ｒ２２）」を受信する場合、ノード「３」３０３における「ｃｃｎｄ３」は、新しい個別ＰＩＴエントリ「／ｎｄｉｓ／ｒ２２：ｆ３１」を作成してもよく、かつ事前に定義されたＦＩＢエントリ「／ｎｄｉｓ：ｆ３ｓ」と一致する最も長いプレフィックスに基づき、フェース「ｆ３ｓ」を介して、「Ｉ３」をＳＰＤ３ ３１３に転送してもよい。

図６に示されるステップ４において、インタレストメッセージ「Ｉ１（ｎｍ＝／ｎｄｉｓ／ｒ２１）」を受信する場合、ＳＰＤ１ ３１１は、データペイロード内で、それ自身の名前プレフィックス「ｎ１」を含む同じ名前プレフィックス「Ｉ１」を伴う新しい近隣探索データメッセージ「Ｄ１（ｎｍ＝／ｎｄｉｓ／ｒ２１、ｄｐ＝ｎ１）」を生成してもよく、そしてその後、フェース「ｆ１ｓ」を介して、「Ｄ１」をノード「１」３０１における「ｃｃｎｄ１」に送り返してもよい。ノード「１」３０１における「ｃｃｎｄ１」は、既存の個別ＰＩＴエントリ「／ｎｄｉｓ／ｒ２１：ｆ１１」に基づき、フェース「ｆ１１」を介して、送出されるデータメッセージ「Ｄ１（ｎｍ＝／ｎｄｉｓ／ｒ２１、ｄｐ＝ｎ１）」をノード「２」３０２における「ｃｃｎｄ２」に対して転送してもよく、そしてその後、データメッセージの使用のために、このＰＩＴエントリを削除してもよい。ノード「２」３０２における「ｃｃｎｄ２」は、既存の個別ＰＩＴエントリ「／ｎｄｉｓ／ｒ２１：ｆ２ｓ」に基づき、フェース「ｆ２ｓ」を介して、着信するデータメッセージ「Ｄ１（ｎｍ＝／ｎｄｉｓ／ｒ２１、ｄｐ＝ｎ１）」をＳＰＤ２ ３１２に対して転送してもよく、そして、データメッセージの使用のために、このＰＩＴエントリを削除してもよい。

インタレストメッセージ「Ｉ３（ｎｍ＝／ｎｄｉｓ／ｒ２２）」を受信する場合、ＳＰＤ３ ３１３は、データペイロード内で、それ自身の名前プレフィックス「ｎ３」を含む同じ名前プレフィックス「Ｉ３」を伴う新しい近隣探索データメッセージ「Ｄ３（ｎｍ＝／ｎｄｉｓ／ｒ２２、ｄｐ＝ｎ３）」を生成してもよく、そしてその後、フェース「ｆ３ｓ」を介して、「Ｄ３」を、ノード「３」３０３の「ｃｃｎｄ３」に送り返してもよい。ノード「３」３０３における「ｃｃｎｄ３」は、既存の個別ＰＩＴエントリ「／ｎｄｉｓ／ｒ２２：ｆ３１」に基づき、フェース「ｆ３１」を介して、送出するデータメッセージ「Ｄ３（ｎｍ＝／ｎｄｉｓ／ｒ２２、ｄｐ＝ｎ３）」をノード「２」３０２の「ｃｃｎｄ２」に転送してもよく、そしてその後、データメッセージの使用のために、このＰＩＴエントリを削除してもよい。ノード「２」３０２における「ｃｃｎｄ２」は、既存の個別ＰＩＴエントリ「／ｎｄｉｓ／ｒ２２：ｆ２ｓ」に基づき、フェース「ｆ２ｓ」を介して、着信するデータメッセージ「Ｄ３（ｎｍ＝／ｎｄｉｓ／ｒ２２、ｄｐ＝ｎ３）」をＳＰＤ３１２に転送してもよく、そしてデータメッセージの使用のために、このＰＩＴエントリを削除してもよい。

ステップ４が終了すると、図７に示すステップ５において、ＳＰＤ２ ３１２は、隣接ノード「１」３０１の名前プレフィックス「ｎ１」をデータペイロード「Ｄ１（ｎｍ＝／ｎｄｉｓ／ｒ２１、ｄｐ＝ｎ１）」から独立して取得してもよく、かつ「Ｄ１」の個別名前プレフィックス「／ｎｄｉｓ／ｒ２１」と既存の個別ＦＩＢエントリ「／ｎｄｉｓ／ｒ２１：ｆ２１」とを正確に一致させることにより、例えば、ｆ２１（ｎ１）といったように、名前プレフィックス「ｎ１」をフェース「ｆ２１」と関連付けてもよい。また、ＳＰＤ２ ３１２は、隣接ノード「３」３０３の名前プレフィックス「ｎ３」をデータペイロード「Ｄ３（ｎｍ＝／ｎｄｉｓ／ｒ２２、ｄｐ＝ｎ３）」から独立して取得してもよく、かつ「Ｄ３」の個別名前プレフィックス「／ｎｄｉｓ／ｒ２２」と既存の個別ＦＩＢエントリ「／ｎｄｉｓ／ｒ２２：ｆ２２」とを正確に一致させることにより、例えば、ｆ２２（ｎ３）といったように、名前プレフィックス「ｎ３」をフェース「ｆ２２」と関連付けてもよい。従って、ＳＰＤ３１１−３１３は、特定の近傍３０１−３０３の名前プレフィックスと特定のフェースとの間のマッピングリストを維持してもよい。

加えて、以下のサービス探索に関して、ＳＰＤ２ ３１２は、受信したデータメッセージ「Ｄ１」及び「Ｄ３」から取得した名前プレフィックス「ｎ１」及び「ｎ３」を使用して、２つの新しい個別ＦＩＢエントリ「／ｓｄｉｓ／ｎ１：ｆ２１」及び「／ｓｄｉｓ／ｎ３：ｆ２２」を設定してもよい。その後、ＳＰＤ２ ３１２は、２つのランダム系列「ｒ２１」及び「ｒ２２」の役目の完了に伴い、２つの既存の個別ＦＩＢエントリ「／ｎｄｉｓ／ｒ２１：ｆ２１」及び「／ｎｄｉｓ／ｒ２２：ｆ２２」を削除してもよい。

図８に示すステップ６において、ＳＰＤ２ ３１２は、近傍３０１及び３０３の名前プレフィックス「ｎ１」及び「ｎ３」を取得するために、インタレスト−データメッセージ交換（ｉｎｔｅｒｅｓｔ−ｄａｔａ ｍｅｓｓａｇｅ ｅｘｃｈａｎｇｅ）の１ラウンドを利用してもよく、そしてその後、実行中の近隣探索に関する既存の個別ＦＩＢエントリ「／ｎｄｉｓ／ｒ２１：ｆ２１」及び「／ｎｄｉｓ／ｒ２２：ｆ２２」を後述のサービス探索に関する新しい個別ＦＩＢエントリ「／ｓｄｉｓ／ｎ１：ｆ２１」及び「／ｓｄｉｓ／ｎ３：ｆ２２」と交換してもよい。

図９に示されるステップ７において、同様に、ＳＰＤ１ ３１１及びＳＰＤ３ ３１３は、ＳＰＤ２ ３１２と実質的に同時に、上記ステップ１−６を独立に実行してもよく、近傍の名前プレフィックス「ｎ２」を取得してもよく、そしてその後、実行中の近隣探索に関する既存の個別ＦＩＢエントリ「／ｎｄｉｓ／ｒ１１：ｆ１１」及び「／ｎｄｉｓ／ｒ３１：ｆ３１」を後述のサービス探索に関する新しい個別ＦＩＢエントリ「／ｓｄｉｓ／ｎ２：ｆ１１」及び「／ｓｄｉｓ／ｎ２：ｆ３１」と交換してもよい。最後に、接続された複数のノードの定常状態は、図９において示される。

図１０−１３は、入ってくるノードが、接続された複数のノードのグループに加わるための、開示される実施例に従う例示的な方法を示すブロック図である。ここで、当該複数のノードの近隣関係は既に設定されている。図１０において示されるステップ１において、隣接ノードが加わる前の、接続された複数のノードの定常状態が図９において示されている。新着ノード「４」３０４が複数のノードのグループの中のジョイントノード「２」３０２に対する接続を開始し、かつ新しい物理リンクを設定する場合、各ノード「１」３０１、「２」３０２、及び「３」３０３におけるリンクマネージャ（ＬＭ）は、新しい物理リンクの接続を検出し、かつそれぞれのＳＰＤモジュール３１１、３１２、３１３にリンク状態の更新を通知する。

ノード「２」３０２について、ノード「４」３０４に対して接続される新しいリンクに関するノード「２」３０２のＬＭからの複数のリンク更新通知を受信する場合、ＳＰＤ２ ３１２は、まず、新しく接続された物理リンク「ｆ２３＠ｎ２−−ｆ４１＠ｎ４」に関して、ノード「２」３０２の「ｃｃｎｄ２」における新しいフェース「ｆ２３」を構成及び登録してもよく、フェース「ｆ２３」と関連付けられるランダム系列「ｒ２３」を生成してもよく、かつその後、実行中の近隣探索に関する新しい個別ＦＩＢエントリ「／ｎｄｉｓ／ｒ２３：ｆ２３」を設定してもよい。

ノード「４」３０４について、ノード「２」３０２に対して接続される新しいリンクに関するノード「４」３０４のＬＭからの複数のリンク更新通知を受信する場合、ＳＰＤ４ ３１４は、まず、新しく接続された物理リンク「ｆ４１＠ｎ４−−ｆ２３＠ｎ２」に関して、ノード「４」３０４の「ｃｃｎｄ４」における新しいフェース「ｆ４１」を構成及び登録してもよく、フェース「ｆ４１」と関連付けられるランダム系列「ｒ４１」を生成してもよく、かつその後、実行中の近隣探索に関する新しい個別ＦＩＢエントリ「／ｎｄｉｓ／ｒ４１：ｆ４１」を設定してもよい。

図１０におけるステップ１が終了すると、図１１において示されるステップ２において、次にノード「２」３０２が注目される。ジョイントノード「２」３０２のＳＰＤ２ ３１２は、インタレスト−データメッセージ交換の１ラウンドによる複数の近隣関係の設定の前述の複数のステップ（上に記載され、かつ図３−９に示される）を独立に実行してもよい。ＳＰＤ２ ３０２は、まず、近隣探索インタレストメッセージ「Ｉ４（ｎｍ＝／ｎｄｉｓ／ｒ２３）」を送信してもよく、かつその後、近隣探索データメッセージ「Ｄ４（ｎｍ＝／ｎｄｉｓ／ｒ２３、ｄｐ＝ｎ４）」を受信してもよい。ＳＰＤ２ ３１２は、新しい近傍の名前プレフィックス「ｎ４」を取得してもよく、そしてその後、実行中の近隣探索に関する既存の個別ＦＩＢエントリ「／ｎｄｉｓ／ｒ２３：ｆ２３」を、対応するサービス探索に関する新しい個別ＦＩＢエントリ「／ｓｄｉｓ／ｎ４：ｆ２３」と交換してもよい。

図１０におけるステップ１が終了すると、図１２に示されるステップ３において、次にノード「４」３０４が注目される。新着ノード「４」３０４のＳＰＤ４ ３１４は、インタレスト−データメッセージ交換の１ラウンドによる複数の近隣関係の設定の前述の複数のステップ（上に記載され、かつ図３−９に示される）を独立に実行してもよい。ＳＰＤ４ ３０４は、まず、近隣探索インタレストメッセージ「Ｉ２（ｎｍ＝／ｎｄｉｓ／ｒ４１）」を送信してもよく、かつその後、近隣探索データメッセージ「Ｄ２（ｎｍ＝／ｎｄｉｓ／ｒ４１、ｄｐ＝ｎ２）」を受信してもよい。ＳＰＤ４ ３１４は、新しい近傍の名前プレフィックス「ｎ２」を取得してもよく、そしてその後、実行中の近隣探索に関する既存の個別ＦＩＢエントリ「／ｎｄｉｓ／ｒ４１：ｆ４１」を、対応するサービス探索に関する新しい個別ＦＩＢエントリ「／ｓｄｉｓ／ｎ２：ｆ４１」と交換してもよい。

図１３において示されるステップ４において、接続された複数のノード３０１−３０４の定常状態が示される。実施例において開示される隣接ノードの結合メカニズムは、新しい物理リンクの設定に関わる接続されたばかりの複数のノードのみによって実行されてもよく、その一方で他の複数のノードはこれらの動作を実行する必要はないかもしれない、ということに注意する。その結果、接続されたばかりのノード３０４のフェース及び複数のＦＩＢエントリは更新されてもよいが、他の複数のノード３０１−３０３のフェース及び複数のＦＩＢエントリは、変更されないかもしれない。

図１４及び１５は、去っていく隣接ノードが複数のノードのグループから離れる場合の、開示される実施例に従う例示的な方法を示すブロック図である。去っていくノードが、接続された複数のノードから一度抜け出すと、その去っていくノードは、接続された複数のノードのグループの隣接ノードではなくなるかもしれない。隣接ノードが離れる前の、接続された複数のノードの定常状態が図１３に示される。図１４において示されるステップ１において、隣接ノード「３」３０３が複数のノードのグループの中のジョイントノード「２」３０２に対する切断を開始し、かつ既存の物理リンクを切断する場合、各ノード３０２、３０３のリンクマネージャ（ＬＭ）は、既存の物理リンクの切断を検出してもよく、かつ各ノード３０２、３０３におけるＳＰＤモジュール３１２、３１３に、リンク状態の更新を通知してもよい。

ノード「２」３０２について、ノード「３」３０３に対して切断される既存のリンクに対するノード「２」３０２のＬＭからの複数のリンク更新通知を受信する場合、ＳＰＤ２ ３１２は、まず、新たに切断された物理リンク「ｆ２２＠ｎ２−−ｆ３１＠ｎ３」に関するノード「２」３０２の「ｃｃｎｄ２」における切断されたフェース「ｆ２２」を構成及び登録解除してもよく、かつ次のサービス探索のために、既存の個別ＦＩＢエントリ「／ｓｄｉｓ／ｎ３：ｆ２２」を削除してもよい。

ノード「３」３０３について、ノード「２」３０２に対して切断される既存のリンクに対するノード「３」３０３のＬＭからの複数のリンク更新通知を受信する場合、ＳＰＤ３ ３１３は、まず、新たに切断された物理リンク「ｆ３１＠ｎ３−−ｆ２２＠ｎ２」に関する「ｃｃｎｄ３」における切断されたフェース「ｆ３１」を構成及び登録解除してもよく、かつ次のサービス探索のために、既存の個別ＦＩＢエントリ「／ｓｄｉｓ／ｎ２：ｆ３１」を削除してもよい。

切断されたノードの定常状態が図１５に示されている。図１５において示されるステップ２において、一実施例における隣接ノード脱退メカニズムは、既存の物理リンクの切断に関与する切断されたばかりのノード３０３によってのみ実行されてもよく、その一方で、他のノード３０１、３０２、３０４はこれらの動作を実行する必要はないかもしれない、ということに注意する。その結果、切断されたばかりのノード３０３のフェース及び複数のＦＩＢエントリは、更新されてもよいが、他のノード３０１、３０２、３０４のフェース及び複数のＦＩＢエントリは、変更されないかもしれない。

次に、サービス探索プロトコルを考えると、サービス探索セッションにおける必要なホップ数を定義するためのインタレストメッセージの新しい属性として、ホップ数（ｈ）が導入される。図３−１５に記載されるＳＰＤ３１１−３１４のいずれか等のＳＰＤは、現在のホップに到達した複数のインタレストメッセージを処理し、かつ現在のホップにおいて受信されたインタレストメッセージのホップ数から１減少した新しいホップ数を伴う次のホップについての新しい複数のインタレストメッセージを作成するために使用されてもよい。受信されたインタレストメッセージのホップ数が０である場合、ＳＰＤは次のホップについての新しいインタレストメッセージは作成せず、かつ集約及びキャッシュされた複数のサービスプロファイルを含むデータメッセージにより、当該インタレストメッセージに応答してもよい。

アプリケーションにより生成されるランダム系列であり得るセッションの補助的変数（ｓｎ）が、特定のサービス探索セッションにおける特定の起点ノードから発せられる複数のインタレストメッセージの特定のセットと、異なるセッションにおける異なる複数の起点ノードから発せられる他の複数のインタレストメッセージとを区別するためのインタレストメッセージの新しい属性として導入される。同じサービス探索セッションにおいて、冗長かつ繰り返しの複数のインタレストメッセージの処理を回避し、かつ不要かつ重複した複数のデータメッセージについて、これらの利害関係者に対して応答することを防止するために、セッションの補助的変数が使用されてもよい。セッションの補助的変数は、ＳＰＤが同じセッションの補助的変数を伴う複数のインタレストメッセージを受信した場合に、集約された複数のサービスプロファイルを含むデータメッセージを伴う最初に受信したインタレストメッセージに対してのみ、それが応答してもよく、かつその後に到着した複数のインタレストメッセージを破棄してもよい、ということを規定する。データメッセージで応答されないインタレストメッセージ及びＰＩＴエントリは、異なる複数のホップノードに対するローカルタイムアウトに達した場合に、消されるか、又は削除されてもよい。

全ての着信するインタレストメッセージが途中のローカルｃｃｎｄにより転送される現在のホップノードのＳＰＤは、名前プレフィックスの規定を定めない場合、前のホップノードを知らないので、望ましくない後方へのインタレストメッセージ、例えば、現在のホップノードから前のホップノードに送信されるインタレストメッセージ、の作成を回避するための名前プレフィックスの規定が開示される。例えば、「／ｓｄｉｓ／ｎｘ２／ｎｘ１」といった、３つの言語構成要素を使用した名前プレフィックスの規定の規則が開示される。ここで、第１の言語構成要素「ｓｄｉｓ」は、サービス探索のインタレスト及び複数のデータメッセージについて事前に定められていてもよく、第２の言語構成要素「ｎｐ」は、次のホップノード（あて先）の名前プレフィックスを示してもよく、かつ第３の言語構成要素「ｎｘ」は、現在のホップノード（起点）の名前プレフィックスを示してもよい。従って、名前プレフィックス「／ｓｄｉｓ／ｎｘ２／ｎｘ１」を伴うインタレストメッセージを受信する場合、現在のホップノード「ｎｘ２」におけるＳＰＤは、名前プレフィックス「／ｓｄｉｓ／ｎｘ２／ｎｘ１」を伴う受信されたインタレストメッセージが前のホップノード「ｎｘ１」から来ていることを判定することができる。現在のホップノードのＳＰＤは、未達の次のホップノードに対して、「ｎｘ１」を含まない名前プレフィックスを伴う新しいインタレストメッセージのみを作成してもよく、そして名前プレフィックス「／ｓｄｉｓ／ｎｘ２／ｎｘ１」を伴う、後方へのインタレストメッセージが現在のノード「ｎｘ２」から前のホップノード「ｎｘ１」に送信されることを防止してもよい。

図１６−１９は、開示される実施例に従う、０−ホップサービス探索の例示的な方法を示すブロック図である。図１６において示されるステップ１において、サービス探索を実行する前に、ノード「１」３０１のアプリケーション１ ３２１は、特定のフェース「ｆ１ａ」を用いて、ノード「１」３０１の「ｃｃｎｄ１」と既に結合されていてもよく、或いは利用可能な複数のＳＰＤアプリケーションプログラムインターフェース（ＡＰＩｓ）のいくつかを用いてＳＰＤ１ ３１１と結合されていてもよい。２つの特定のＦＩＢエントリ、「／ｎｄｉｓ：ｆ１ｓ」及び「／ｓｄｉｓ：ｆ１ｓ」、は、上に論じられる近隣探索プロトコルの中で言及されるように、ＳＰ１ ３１１により既に設定されていてもよい。また、ＳＰＤ１ ３１１は、ノード「１」３０１のＳＰＤ１ ３１１において利用可能かつ公開される全てのローカルサービスについて、複数のＦＩＢエントリ「／ｎ１／ｓｖ^＊：ｆ１ｓ」のグループを設定してもよく、かつ複数の隣接関係に関する近隣探索により更新された複数の個別ＦＩＢエントリのリストを維持してもよい（０−ホップサービス探索における場合とは限らない）。

ノード「１」３０１について、名前プレフィックス「／ｓｄｉｓ」又は「／ｎ１／ｓｖ＊：ｆ１ｓ」を含む任意のサービス探索インタレストメッセージは、２つのＦＩＢエントリと一致する最も長いプレフィックスに基づき、フェース「ｆ１ｓ」を介して、ＳＰＤ１ ３１１によって転送されてもよい。

０−ホップサービス探索に関して、複数のサービスプロファイルのいくつかは、ローカルＳＰＤにより既に収集及び集約されていてもよく、かつアプリケーションは、他の複数のノードに対して複数のサービス探索インタレストメッセージを送信することなく、ローカルＳＰＤにより既にキャッシュされている集約された複数のサービスプロファイルを速く取得することを要求してもよい、ということが仮定されてもよい。

図１６において示されるステップ１が終了すると、図１７において示されるステップ２において、ノード「１」３０１のアプリケーションＡＰＰ１ ３２１は、０−ホップサービス検索を使用して、ローカルＳＰＤ３１１により既にキャッシュされている複数の集約サービスプロファイルを速く取得するための２つのオプションを有してもよい。一つのオプションは、アプリケーションＡＰＰ１ ３２１が、サービス探索を要求するためにＳＰＤ ＡＰＩｓを利用してもよく、かつＳＰＤ３１１に、０−ホップサービス探索の所望のホップ数「ｈ＝０」及びサービス探索セッションの補助的変数「ｓｎ０」を与えてもよい、ということである。

第２のオプションは、アプリケーションＡＰＰ１ ３２１が、インタレスト−データメッセージ交換の１ラウンドを使用して、ノード「１」３０１のローカルｃｃｎｄを介して、サービス探索を要求してもよい、ということである。この場合、アプリケーションＡＰＰ１ ３２１は、事前に定められた名前プレフィックス「／ｓｄｉｓ」及びセッションの補助的変数「ｓｎ０」、例えば、「Ｉ１（ｎｍ＝／ｓｄｉｓ、ｓｎ０、ｈ＝０）」、を使用して、新しい０−ホップサービス探索インタレストメッセージを作成してもよく、そしてその後、フェース「ｆ１ａ」を介して、「Ｉ１」をノード「１」３０１におけるローカル「ｃｃｎｄ１」に対して送信してもよい。ノード「１」３０１における「ｃｃｎｄ１」は、受信したインタレストメッセージ「Ｉ１」について、新しいＰＩＴエントリ「／ｓｄｉｓ（ｓｎ０，Ｈ＝０）：ｆ１ａ」を作成してもよく、かつ事前に定められたＦＩＢエントリ「／ｓｄｉｓ：ｆ１ｓ」と一致する正確なプレフィックスに基づき、フェース「ｆ１ｓ」を介して、受信したインタレストメッセージ「Ｉ１」をローカルＳＰＤ１ ３１１に転送してもよい。

両方のオプションは、ローカルＳＰＤ３１１から、集約されかつキャッシュされた複数のサービスプロファイルを取得することができてもよい。

図１７において示されるステップ２が終了すると、図１８に示されるステップ３において、ノード「１」３０１のＳＰＤ１ ３１１は、まず、受信したインタレストメッセージ「Ｉ１（ｎｍ＝／ｓｄｉｓ、ｓｎ０、ｈ＝０）」のホップ数「ｈ」が０に等しいかどうか確認する。このステップにおいて、「ｈ＝０」であり、このためＳＰＤ１ ３１１は、次のホップについての新しいインタレストメッセージを生成しないかもしれず、そしてさらに遅延することなく、このインタレストメッセージ「Ｉ１」に応答してもよい。

ノード「１」３０１のＳＰＤ１ ３１１は、集約されかつキャッシュされた複数のサービスプロファイルを返すための２つのオプションを有してもよい。１つのオプションは、ノード「１」３０１における集約されかつキャッシュされた複数のサービスプロファイル「ｓｐ１」をアプリケーションＡＰＰ１ ３２１に返すために、ＳＰＤ１ ３１１がＳＰＤのＡＰＩｓを利用してもよい、ということである。

第２のオプションは、ＳＰＤ１ ３１１がノード「１」における集約されかつキャッシュされたサービスプロファイル「ｓｐ１」を含む同じ名前プレフィックス「Ｉ１」を伴う新しいサービス探索データメッセージ「Ｄ１（ｎｍ＝／ｓｄｉｓ、ｄｐ＝ｓｐ１）」を、データペイロードにおいて生成してもよく、そしてその後、フェース「ｆ１ｓ」を介して、「Ｄ１」をノード「１」３０１の「ｃｃｎｄ１」に送り返してもよい、ということである。ノード「１」３０１の「ｓｓｎｄ１」は、既存のＰＩＴエントリ「／ｓｄｉｓ（ｓｎ０、ｈ＝０）：ｆ１ａ」に基づき、フェース「ｆ１ａ」を介して「Ｄ１（ｎｍ＝／ｓｄｉｓ、ｄｐ＝ｓｐ１）」をアプリケーションＡＰＰ１ ３２１に転送してもよく、そしてデータメッセージの使用のために、このＰＩＴエントリを削除してもよい。

最後に、図１９において示されるステップ４において、アプリケーションＡＰＰ１ ３２１は、単一のサービス探索セッションにおいて、ノード「１」３０１により知られる全ての利用可能なサービス（プロファイル）を発見してもよく、かつ複数の中間ノードの複数のフェースをたどることにより、例えば、「／ｎ１／ｓｖ^＊：ｆ１ｓ＠ｎ１」等の、ノード「１」３０１からノード「１」３０１において利用可能な任意の複数のサービスへの第１の利用可能な経路を検出してもよい。

図２０−２５は、開示される実施例に従う、複数のノードのグループ内のノードから１−ホップ離れたサービスを探索する例示的な方法を示すブロック図である。図２０において示されるステップ１において、サービス探索の実行前に、ノード「１」３０１のアプリケーションＡＰＰ１ ３２１は、特定のフェース「ｆ１ａ」を使用して、ノード「１」３０１の「ｃｃｎｄ１」と既に結合されていてもよく、或いは利用可能なＳＰＤ ＡＰＩｓのいくつかを用いて、ＳＰＤ１ ３１１と結合されていてもよい。近隣探索プロトコルにおいて述べられるように、２つの特定のＦＩＢエントリ、「／ｎｄｉｓ：ｆ１ｓ」及び「／ｓｄｉｓ：ｆ１ｓ」は、ＳＰＤ１ ３１１により、既に設定されていてもよい。また、ＳＰＤ１ ３１１は、ノード「１」３０１のＳＰＤ１ ３１１において利用可能かつ公開された全てのローカルサービスに関して、複数のＦＩＢエントリのグループ「／ｎ１／ｓｖ^＊：ｆ１ｓ」を設定してもよく、かつ、例えば、「／ｓｄｉｓ／ｎ２：ｆ１１」といった、複数の近隣関係に関する近隣探索により更新された複数の個別ＦＩＢエントリのリストを維持してもよい。同様に、これらの要件は、また、ノード「２」３０２より満たされてもよい。

ノード「１」３０１について、名前プレフィックス「／ｓｄｉｓ」又は「／ｎ１／ｓｖ^＊：ｆ１ｓ」を含む任意の複数のサービス探索インタレストメッセージは、２つのＦＩＢエントリと一致する最も長いプレフィックスに基づき、フェース「ｆ１ｓ」を介して、ＳＰＤ１ ３１１に転送されてもよく、かつ個別名前プレフィックス「／ｓｄｉｓ／ｎ２」を含む任意の複数のサービス探索インタレストメッセージは、既存のＦＩＢエントリ「／ｓｄｉｓ／ｎ２：ｆ１１」と一致する最も長いプレフィックスに基づき、フェース「ｆ１１」を介して、ノード「２」３０２の「ｃｃｎｄ２」に転送されてもよい。ノード「２」３０２は、ノード「１」３０１と同様の方法において動作してもよい。

図２０におけるステップ１を終了すると、図２１において示されるステップ２において、ノード「１」３０１のアプリケーションＡＰＰ１ ３２１は、新しい１−ホップサービス探索セッションを開始するための２つのオプションを有してもよい。１つのオプションは、アプリケーションＡＰＰ１ ３２１がサービス探索を要求するために、ＳＰＤ ＡＰＩｓを利用してもよく、かつＳＰＤ ３１１に、１−ホップサービス探索の所望のホップ数「ｈ＝１」及びサービス探索セッションの補助的変数「ｓｎ１」を与えてもよい、ということであってもよい。

第２のオプションは、アプリケーションＡＰＰ１ ３２１が、インタレスト−データメッセージ交換の１ラウンドを使用して、ノード「１」３０１のローカル「ｃｃｎｄ」を介して、サービス探索を要求してもよい、ということであってもよい。この場合、アプリケーションＡＰＰ１ ３２１は、事前に定められた名前プレフィックス「／ｓｄｉｓ」及びセッションの補助的変数「ｓｎ１」、例えば「Ｉ１（ｎｍ＝／ｓｄｉｓ、ｓｎ１、ｈ＝１）」、を使用して、新しい１−ホップサービス探索インタレストメッセージを作成してもよく、そしてその後、フェース「ｆ１ａ」を介して、「Ｉ１」をノード「１」３０１のローカル「ｃｃｎｄ１」に送信してもよい。ノード「１」３０１の「ｃｃｎｄ１」は、受信したインタレストメッセージ「Ｉ１」について、新しいＰＩＴエントリ「／ｓｄｉｓ（ｓｎ１、ｈ＝１）：ｆ１ａ」を作成してもよく、かつ事前に定められたＦＩＢエントリ「／ｓｄｉｓ：ｆ１ｓ」と一致する正確なプレフィックスに基づき、受信したインタレストメッセージ「Ｉ１」を、フェース「ｆ１ｓ」を介して、ローカルＳＰＤ１ ３１１に転送してもよい。

両方のオプションは、新しい１−ホップサービス探索セッションの開始をローカルＳＤＰ３１１に通知すること、及びローカルＳＤＰ３１１から新しい複数の収集されかつ集約されたサービスプロファイルを取得することができてもよい。

図２１に示されるステップ２を終了すると、図２２に示されるステップ３において、ノード「１」３０１のＳＰＤ１ ３１１は、まず、受信したインタレストメッセージ「Ｉ１（ｎｍ＝／ｓｄｉｓ、ｓｎ１、ｈ＝１）」のホップ数「ｈ」が０に等しいかどうか確認してもよい。このステップにおいて、「ｈ＝１」であり、現在のホップにおいて受信したインタレストメッセージの１つを、たとえは「ｈ＝１−１＝０」といったように、１減らすことにより、ＳＰＤ１ ３１１は、次のホップについて、新しい複数のインタレストメッセージの新しいホップ数を計算してもよい。

近隣探索により更新された複数の個別ＦＩＢエントリの数に基づき（この図において、「／ｓｄｉｓ／ｎ２：ｆ１１」について、ノード「１」３０１の数は１である）、ＳＰＤ１ ３１１は、個別名前プレフィックス「／ｓｄｉｓ／ｎ２／ｎ１」、同じセッションの補助的変数「ｓｎ１」、及び更新された次のホップ数「ｈ＝０」、例えば、「Ｉ２（ｎｍ＝／ｓｄｉｓ／ｎ２／ｎ１、ｓｎ１、ｈ＝０）」、を使用して、新しいサービス探索インタレストメッセージを作成してもよく、そしてその後、フェース「ｆ１ｓ」を介して、「Ｉ２」をローカル「ｃｃｎｄ１」に送信する。ノード「１」３０１の「ｃｃｎｄ１」は、送出されるインタレストメッセージ「Ｉ２」について、新しいＰＩＴエントリ「／ｓｄｉｓ／ｎ２／ｎ１（ｓｎ１、ｈ＝１）：ｆ１ｓ」を作成してもよく、かつ既存の個別ＦＩＢエントリ「／ｓｄｉｓ／ｎ２：ｆ１１」と一致する最も長いプレフィックスに基づき、フェース「ｆ１１」を介してノード「２」３０２における「ｃｃｎｄ２」に送出されるインタレストメッセージ「Ｉ２」を転送してもよい。

サービス探索インタレストメッセージ「Ｉ２（ｎｍ＝／ｓｄｉｓ／ｎ２／ｎ１、ｓｎ１、ｈ＝０）」を受信する場合、ノード「２」３０２の「ｃｃｎｄ２」は、着信するインタレストメッセージ「Ｉ２」について、新しい個別ＰＩＴエントリ「／ｓｄｉｓ／ｎ２／ｎ１（ｓｎ１、ｈ＝０）：ｆ２１」を作成してもよく、かつ事前に定められたＦＩＢエントリ「／ｓｄｉｓ：ｆ２ｓ」と一致する最も長いプレフィックスに基づき、着信するインタレストメッセージ「Ｉ２」を、フェース「ｆ２ｓ」を介して、ローカルＳＰＤ２ ３１２に転送してもよい。

図２２におけるステップ３が終了すると、図２３において示されるステップ４において、ノード「２」３０２のＳＰＤ２ ３１２は、まず、受信したインタレストメッセージ「Ｉ２（ｎｍ＝／ｓｄｉｓ／ｎ２／ｎ１、ｓｎ１、ｈ＝０）」のホップ数「ｈ」が０に等しいかどうか確認してもよい。この例において、「ｈ＝０」であり、このためＳＰＤ２ ３１２は、次のホップのための新しい複数のインタレストメッセージを作成しないかもしれず、かつこのインタレストメッセージ「Ｉ２」に応答してもよい。

ＳＰＤ１ ３１１は、データペイロードにおいて、ノード「２」３０２における集約されかつキャッシュされた複数のプロファイル「ｓｐ２」を含む同じ名前プレフィックス「Ｉ２」を伴う新しいサービス探索データメッセージ「Ｄ２（ｎｍ＝／ｓｄｉｓ／ｎ２／ｎ１、ｄｐ＝ｓｐ２）」を生成してもよく、そしてその後、フェース「ｆ２ｓ」を介して「Ｄ２」をノード「２」３０２の「ｃｃｎｄ２」に送り返してもよい。ノード「２」３０２の「ｃｃｎｄ２」は、既存の個別ＰＩＴエントリ「／ｓｄｉｓ／ｎ２／ｎ１（ｓｎ１、ｈ＝０）：ｆ２１」に基づき、送出されるデータメッセージ「Ｄ２（ｎｍ＝／ｓｄｉｓ／ｎ２／ｎ１、ｄｐ＝ｓｐ２）」を、フェース「ｆ２１」を介して、ノード「１」３０１の「ｃｃｎｄ１」に転送してもよく、かつデータメッセージの使用のために、このＰＩＴエントリを削除してもよい。

サービス探索データメッセージ「Ｄ２（ｎｍ＝／ｓｄｉｓ／ｎ２／ｎ１、ｄｐ＝ｓｐ２）」を受信する場合、ノード「１」３０１の「ｃｃｎｄ１」は、既存の個別ＰＩＴエントリ「／ｓｄｉｓ／ｎ２／ｎ１（ｓｎ１、ｈ＝０）：ｆ１ｓ」に基づき、着信するデータメッセージ「Ｄ２」を、フェース「ｆ１ｓ」を介して、ＳＰＤ１ ３１１に転送してもよく、かつデータメッセージの使用のために、このＰＩＴエントリを削除してもよい。

図２３におけるステップ４が完了すると、図２４において示されるステップ５において、ＳＰＤ１ ３１１は、「Ｄ２（ｎｍ＝／ｓｄｉｓ／ｎ２／ｎ１、ｄｐ＝ｓｐ’２）」のデータペイロードから、ノード「２」３０２における更新された複数のサービスプロファイル「ｓｐ’２」を取得してもよく、ノード「１」３０１において、「ｓｐ’２」をキャッシュされたサービスプロファイル「ｓｐ１」と共に集約してもよく（ｓｐ’１＝ｓｐ’２＋ｓｐ１）、そしてその後、キャッシュの中に、収集されかつ集約されたサービスプロファイル「ｓｐ’１」を記憶してもよい。また、ＳＰＤ１ ３１１は、「Ｄ２」の個別名前プレフィックス「／ｓｄｉｓ／ｎ２／ｎ１」と、既存の個別ＦＩＢエントリ「／ｓｄｉｓ／ｎ２：ｆ１１」との最長の一致により、着信するデータメッセージ「Ｄ２（ｎｍ＝／ｓｄｉｓ／ｎ２／ｎ１、ｄｐ＝ｓｐ’２）」を受信するノード「１」３０１におけるローカル「ｃｃｎｄ」のフェースをたどってもよく、かつノード「２」３０２のＳＰＤ２ ３１２において公開された全ての利用可能なサービスに関してたどられたフェース「ｆ１１」を使用して、ノード「１」３０１における複数のＦＩＢエントリ「／ｎ２／ｓｖ^＊：ｆ１１」の新しいグループを設定してもよい。

新しい収集されかつ集約された複数のサービスプロファイルを返すために、ＳＰＤ１ ３１１は、２つのオプションを有してもよい。１つのオプションは、ノード「１」３０１に関する新しい収集されかつ集約された複数のサービスプロファイル「ｓｐ’１」をアプリケーション「ＡＰＰ１」３２１に返すために、ＳＰＤ１ ３１１はＳＰＤ ＡＰＩｓを利用してもよい、ということであってもよい。

第２のオプションは、ＳＰ１ ３１１が、データペイロードにおいて、ノード「１」３０１に関する新しい収集されかつ集約された複数のサービスプロファイル「ｓｐ’１」を含む同じ名前プレフィックス「Ｉ１」を伴う新しいサービス探索データメッセージ「Ｄ１（ｎｍ＝／ｓｄｉｓ、ｄｐ＝ｓｐ’１）」を生成してもよく、そしてその後、フェース「ｆ１ｓ」を介して、「Ｄ１」をノード「１」３０１の「ｃｃｎｄ１」に送り返してもよい、ということであってもよい。ノード「１」３０１における「ｃｃｎｄ１」は、既存のＰＩＴエントリ「／ｓｄｉｓ（ｓｎ１、ｈ＝１）：ｆ１ａ」に基づき、「Ｄ１（ｎｍ＝／ｓｄｉｓ、ｄｐ＝ｓｐ’１）」を、フェース「ｆ１ａ」を介して、アプリケーションＡＰＰ１ ３２１に転送してもよく、かつデータメッセージの使用のために、このＰＩＴエントリを削除してもよい。

最後に、図２５において示されるステップ６において、アプリケーションＡＰＰ１ ３２１は、単一のサービス探索セッションにおいて、ノード「１」３０１から１−ホップの範囲内の、ノード「１」３０１及びノード「２」３０２により知られる全ての利用可能なサービス（プロファイル）を発見してもよく、かつ複数の中間ノードの複数のフェース、つまり、「／ｎ１／ｓｖ^＊：ｆ１ｓ＠ｎ１」及び「／ｎ２／ｓｖ^＊：ｆ１１＠ｎ１−−ｆ２ｓ＠ｎ２」、をたどることにより、ノード「１」３０１から、ノード「１」３０１及びノード「２」３０２において利用可能な任意の複数のサービスへの、第１の利用可能な経路を見出してもよい。

図２６−３３は、開示される実施例に従う、２−ホップサービス探索に関する例示的な方法を示すブロック図である。本明細書で使用される場合、２−ホップは、宛先ノードが中間ノードにより起点ノードから離されていることを意味する。開示される２−ホップサービス探索方法におけるステップ１が図２６において示されている。サービス探索を実行する前に、ノード「１」３０１のアプリケーションＡＰＰ１ ３２１は、特定のフェース「ｆ１ａ」を使用して、ノード「１」３０１の「ｃｃｎｄ１」と既に結合されていてもよく、或いは利用可能なＳＰＤ ＡＰＩｓのいくつかを使用して、ＳＰＤ１ ３１１と結合されていてもよい。近隣探索プロトコルにおいて述べられるように、２つの特定のＦＩＢエントリ、「／ｎｄｉｓ：ｆ１ｓ」及び「／ｓｄｉｓ：ｆ１ｓ」は、ＳＰＤ１ ３１１により、既に設定されていてもよい。また、ＳＰＤ１ ３１１は、ノード「１」３０１のＳＰＤ１ ３１１において利用可能かつ公開された全てのサービスについて、複数のＦＩＢエントリ、「／ｎ１／ｓｖ^＊：ｆ１ｓ」、のグループを設定してもよく、かつ複数の近隣関係、例えば、「／ｓｄｉｓ／ｎ２：ｆ１１」、についての近隣探索により更新された複数の個別ＦＩＢエントリのリストを維持してもよい。同様にこれらの条件は、また、ノード「２」３０２、ノード「３」３０３、及びノード「４」３０４により満たされてもよい。

ノード「１」３０１について、名前プレフィックス「／ｓｄｉｓ」又は「／ｎ１／ｓｖ^＊：ｆ１ｓ」を含む任意の複数のサービス探索インタレストメッセージは、２つのＦＩＢエントリと一致する最も長いプレフィックスに基づき、フェース「ｆ１ｓ」を介して、ＳＰＤ１ ３１１に転送されてもよく、かつ個別名前プレフィックス「／ｓｄｉｓ／ｎ２」を含む任意の複数のサービス探索インタレストメッセージは、既存のＦＩＢエントリ、「／ｓｄｉｓ／ｎ２：ｆ１１」、と一致する最も長いプレフィックスに基づき、フェース「ｆ１１」を介して、ノード「２」３０２の「ｃｃｎｄ２」に転送されてもよい。ノード「２」３０２、ノード「３」３０３、及びノード「４」３０４について、複数のサービス探索インタレストメッセージは、同様な方式において処理されてもよい。

図２６において示されるステップ１を終了すると、図２７において示されるステップ２において、ノード「１」３０１のアプリケーションＡＰＰ１ ３２１は、新しい２−ホップサービス探索セッションを開始するための２つのオプションを有してもよい。１つのオプションは、アプリケーション１ ３２１が、サービス探索を要求するために、ＳＰＤ ＡＰＩｓを利用してもよく、かつＳＰＤ１ ３１１に２−ホップサービス探索についての所望のホップ数「ｈ＝２」及びサービス探索セッションの補助的変数「ｓｎ２」を与えてもよい、ということであってもよい。

第２のオプションは、インタレスト−データメッセージ交換の１ラウンドを使用して、アプリケーションＡＰＰ１ ３２１が、ローカルｃｃｎｄを介して、サービス探索を要求してもよい、ということであってもよい。この場合、アプリケーションＡＰＰ１ ３２１は、事前に定められた名前プレフィックス「／ｓｄｉｓ」及びセッションの補助的変数「ｓｎ１」、例えば、「Ｉ１（ｎｍ＝／ｓｄｉｓ、ｓｎ２、ｈ＝２）」、を使用して、新しい２−ホップサービス探索インタレストメッセージを作成してもよく、そしてその後、フェース「ｆ１ａ」を介して、「Ｉ１」をノード「１」３０１のローカル「ｃｃｎｄ１」に送信してもよい。ノード「１」３０１の「ｃｃｎｄ１」は、受信したインタレストメッセージ「Ｉ１」について、新しいＰＩＴエントリ「／ｓｄｉｓ（ｓｎ２、ｈ＝２）：ｆ１ａ」を生成してもよく、かつ事前に定められたＦＩＢエントリ「／ｓｄｉｓ：ｆ１ｓ」と一致する正確なプレフィックスに基づき、受信したインタレストメッセージ「Ｉ１」を、フェース「ｆ１ｓ」を介して、ローカルＳＰＤ１ ３１１に転送してもよい。

両方のオプションは、新しい２−ホップサービス探索セッションを開始し、そしてその後、新しい収集及び集約された複数のサービスプロファイルをローカルＳＰＤから取得することを、ローカルＳＰＤに通知することができてもよい。

図２７におけるステップ２を終了すると、図２８に示されるステップ３において、ノード「１」３０１のＳＰＤ１ ３１１は、まず、受信したインタレストメッセージ「Ｉ１（ｎｍ＝／ｓｄｉｓ、ｓｎ２、ｈ＝２）」のホップ数「ｈ」が０に等しいかどうか確認してもよい。このステップにおいて、「ｈ＝２」であり、現在のホップにおいて受信したインタレストメッセージのホップ数を１減らすこと、例えば、「ｈ＝２−１＝１」により、ＳＰＤ１ ３１１は、次のホップに関して、新しいホップ数を計算してもよい。

近隣探索により更新された複数の個別ＦＩＢエントリの数に基づき（この図において、ノード「１」の番号は、「／ｓｄｉｓ／ｎ２：ｆ１１」に関して１である）、ＳＰＤ１ ３１１は、個別名前プレフィックス「／ｓｄｉｓ／ｎ２／ｎ１」、同じセッション補助的変数「ｓｎ１」、及び更新された次のホップ数「ｈ＝１」、例えば、「Ｉ２（ｎｍ＝／ｓｄｉｓ／ｎ２／ｎ１、ｓｎ２、ｈ＝１）」、を使用して、新しいサービス探索インタレストメッセージを作成してもよく、そしてその後、フェース「ｆ１ｓ」を介して、「Ｉ２」をノード「１」３０１のローカル「ｃｃｎｄ１」に送信してもよい。ノード「１」３０１の「ｃｃｎｄ１」は、送出されるインタレストメッセージ「Ｉ２」に関して、新しいＰＩＴエントリ「／ｓｄｉｓ／ｎ２／ｎ１（ｓｎ２、ｈ＝１）：ｆ１ｓ」を作成してもよく、かつ既存のＦＩＢエントリ「／ｓｄｉｓ／ｎ２：ｆ１１」と一致する最も長いプレフィックスに基づき、送出されるインタレストメッセージ「Ｉ２」を、フェース「ｆ１１」を介して、ノード「２」３０２の「ｃｃｎｄ２」に転送してもよい。

サービス探索インタレストメッセージ「Ｉ２（ｎｍ＝／ｓｄｉｓ／ｎ２／ｎ１、ｓｎ２、ｈ＝１）」を受信する場合、ノード「２」３０２の「ｃｃｎｄ２」は、着信するインタレストメッセージ「Ｉ２」に関して、新しい個別ＰＩＴエントリ「／ｓｄｉｓ／ｎ２／ｎ１（ｓｎ２、ｈ＝１）：ｆ２１」を作成してもよく、かつ事前に定められたＦＩＢエントリ「／ｓｄｉｓ：ｆ２ｓ」と一致する最も長いプレフィックスに基づき、着信するインタレストメッセージ「Ｉ２」を、フェース「ｆ２ｓ」を介して、ＳＰＤ２ ３１２に転送してもよい。

図２８において示されるステップ３を終了すると、図２９において示されるステップ４において、ノード「２」３０２のＳＰＤ２ ３１２は、まず、受信したインタレストメッセージのホップ数「ｈ」が０に等しいかどうかを確認してもよい。このステップにおいて、「ｈ＝１」であり、ＳＰＤ２ ３１２は、現在のホップにおいて受信したインタレストメッセージの１つのホップ数を１だけ減らす、例えば、「ｈ＝１−１＝０」、ことにより、次のホップに関して、複数の新しいインタレストメッセージの新しいホップ数を計算してもよい。開示される名前プレフィックスの規定により、ＳＰＤ２ ３１２は、名前プレフィックス「／ｓｄｉｓ／ｎ２／ｎ１」を伴う受信した関連メッセージが、前のホップノード「ｎ１」から来ていることを知ることができ、かつ名前プレフィックス「／ｓｄｉｓ／ｎ１／ｎ２」を伴う後方インタレストメッセージが現在のホップノード「ｎ２」から前のホップノード「ｎ１」に送信されることを防止することができる。

近隣探索により更新された複数の個別ＦＩＢエントリの数に基づき（この図において、ノード「２」の数は、名前プレフィックス「／ｓｄｉｓ／ｎ１／ｎ２」を除いて、「／ｓｄｉｓ／ｎ１：ｆ２１」、「／ｓｄｉｓ／ｎ３：ｆ２２」及び「／ｓｄｉｓ／ｎ４：ｆ２３」に関して３である）、ＳＰＤ２ ３１２は、２つの個別名前プレフィックス、「／ｓｄｉｓ／ｎ３／ｎ２」及び「／ｓｄｉｓ／ｎ４／ｎ２」、同じセッション補助的変数「ｓｎ２」、及び更新された次のホップ数「ｈ＝０」、例えば、それぞれ、「Ｉ３（ｎｍ＝／ｓｄｉｓ／ｎ３／ｎ２、ｓｎ２、ｈ＝０）」及び「Ｉ４（ｎｍ＝／ｓｄｉｓ／ｎ４／ｎ２、ｓｎ２、ｈ＝０）」を使用して、２つの新しいサービス探索インタレストメッセージだけを作成してもよく、そしてその後フェース「ｆ２ｓ」を介して、「Ｉ３」及び「Ｉ４」をローカル「ｃｃｎｄ２」に送信してもよい。ノード「２」３０２における「ｃｃｎｄ２」は、２つの送出されるインタレストメッセージそれぞれについて、２つの新しいＰＩＴエントリ、「／ｓｄｉｓ／ｎ３／ｎ２（ｓｎ２、ｈ＝０）：ｆ２ｓ」及び「／ｓｄｉｓ／ｎ４／ｎ２（ｓｎ２、ｈ＝０）：ｆ２ｓ」、を作成してもよい。ＳＰＤ２ ３１２は、既存の個別ＦＩＢエントリ「／ｓｄｉｓ／ｎ３：ｆ２２」と一致する最も長いプレフィックスに基づき、フェース「ｆ２２」を介して、「Ｉ３」をノード「３」３０３における「ｃｃｎｄ３」に転送してもよく、かつ既存の個別ＦＩＢエントリ「／ｓｄｉｓ／ｎ４：ｆ２３」と一致する最も長いプレフィックスに基づき、フェース「ｆ２３」を介して、「Ｉ４」を、ノード「４」３０４における「ｃｃｎｄ４」に転送してもよい。

「Ｉ３（ｎｍ＝／ｓｄｉｓ／ｎ３／ｎ２、ｓｎ２、ｈ＝０）」を伴うサービス探索インタレストメッセージを受信する場合、ノード「３」３０３における「ｃｃｎｄ３」は、着信するインタレストメッセージ「Ｉ３」に関して、新しい個別ＰＩＴエントリ「／ｓｄｉｓ／ｎ３／ｎ２（ｓｎ２、ｈ＝０）：ｆ３１」を作成してもよく、かつ事前に定められたＦＩＢエントリ「／ｓｄｉｓ：ｆ３ｓ」と一致する最も長いプレフィックスに基づき、着信するインタレストメッセージ「Ｉ３」を、フェース「ｆ３ｓ」を介して、ＳＰＤ３ ３１３に転送してもよい。サービス探索インタレストメッセージ「Ｉ４（ｎｍ＝／ｓｄｉｓ／ｎ４／ｎ２、ｓｎ２、ｈ＝０）」を受信する場合、ノード「４」３０４における「ｃｃｎｄ４」は、着信するインタレストメッセージ「Ｉ４」に関して、新しい個別ＰＩＴエントリ「／ｓｄｉｓ／ｎ４／ｎ２（ｓｎ２、ｈ＝０）：ｆ４１」を作成してもよく、かつ事前に定められたＦＩＢエントリ「／ｓｄｉｓ：ｆ４ｓ」と一致する最も長いプレフィックスに基づき、着信するインタレストメッセージ「Ｉ４」を、フェース「ｆ４ｓ」を介して、ＳＰＤ４ ３１４に転送してもよい。

図３０において示されるステップ５において、ＳＰＤ３ ３１３及びＳＰＤ４ ３１４は、まず、受信したインタレストメッセージ、「Ｉ３（ｎｍ＝／ｓｄｉｓ／ｎ３／ｎ２、ｓｎ２、ｈ＝０）」及び「Ｉ４（ｎｍ＝／ｓｄｉｓ／ｎ４／ｎ２、ｓｎ２、ｈ＝０）」、のホップ数「ｈ」が０であるかどうか確認してもよい。このステップにおいて、「ｈ＝０」であり、このためＳＰＤ３ ３１３及びＳＰＤ４ ３１４は、次のホップに関する新しいインタレストメッセージを作成しないかもしれず、そしてインタレストメッセージ「Ｉ３」及び「Ｉ４」に応答してもよい。

一方で、ＳＰＤ３ ３１３は、データペイロードにおいて、ノード「３」３０３において集約されかつキャッシュされた複数のサービスプロファイル「ｓｐ３」を含む同じ名前プレフィックス「Ｉ３」を伴う新しいサービス探索データメッセージ「Ｄ３（ｎｍ＝／ｓｄｉｓ／ｎ３／ｎ２、ｄｐ＝ｓｐ３）」を生成してもよく、そしてその後、フェース「ｆ３ｓ」を介して、「Ｄ３」を、ノード「３」３０３の「ｃｃｎｄ３」に送り返してもよい。ノード「３」３０３の「ｃｃｎｄ３」は、既存の個別ＰＩＴエントリ「／ｓｄｉｓ／ｎ３／ｎ２（ｓｎ２、ｈ＝０）：ｆ３１」に基づき、送出されるデータメッセージ「Ｄ３（ｎｍ＝／ｓｄｉｓ／ｎ３／ｎ２、ｄｐ＝ｓｐ３）」を、フェース「ｆ３１」を介して、ノード「２」３０２の「ｃｃｎｄ２」に転送してもよく、かつデータメッセージの使用のために、このＰＩＴエントリを削除してもよい。

サービス探索データメッセージ「Ｄ３（ｎｍ＝／ｓｄｉｓ／ｎ３／ｎ２、ｄｐ＝ｓｐ３）」を受信する場合、ノード「２」３０２の「ｃｃｎｄ２」は、既存の個別ＰＩＴエントリ「／ｓｄｉｓ／ｎ３／ｎ２（ｓｎ２、ｈ＝０）：ｆ２ｓ」に基づき、フェース「ｆ２ｓ」を介して、着信するデータメッセージ「Ｄ３」をＳＰＤ２ ３１２に転送してもよく、かつデータメッセージの使用のために、このＰＩＴエントリを削除してもよい。

一方、ＳＰＤ４ ３１４は、データペイロードにおいて、ノード「４」３０４に関して集約されかつキャッシュされた複数のサービスプロファイル「ｓｐ４」を含む同じ名前プレフィックス「Ｉ４」を伴う新しいサービス探索データメッセージ「Ｄ４（ｎｍ＝／ｓｄｉｓ／ｎ４／ｎ２、ｄｐ＝ｓｐ４）」を生成してもよく、そしてその後、フェース「ｆ４ｓ」を介して、「Ｄ４」を、ノード「４」３０４の「ｃｃｎｄ４」に送り返してもよい。ノード「４」３０４の「ｃｃｎｄ４」は、既存の個別ＰＩＴエントリ「／ｓｄｉｓ／ｎ４／ｎ２（ｓｎ２、ｈ＝０）：ｆ４１」に基づき、送出されるデータメッセージ「Ｄ４（ｎｍ＝／ｓｄｉｓ／ｎ４／ｎ２、ｄｐ＝ｓｐ４）」を、フェース「ｆ４１」を介して、ノード「２」３０２の「ｃｃｎｄ２」に転送してもよく、かつデータメッセージの使用のために、このＰＩＴエントリを削除してもよい。

サービス探索データメッセージ「Ｄ４（ｎｍ＝／ｓｄｉｓ／ｎ４／ｎ２、ｄｐ＝ｓｐ４）」を受信する場合、ノード「２」３０２の「ｃｃｎｄ２」は、既存の個別ＰＩＴエントリ「／ｓｄｉｓ／ｎ４／ｎ２（ｓｎ２、ｈ＝０）：ｆ２ｓ」に基づき、フェース「ｆ２ｓ」を介して、着信するデータメッセージ「Ｄ４」を、「ＳＰＤ２」に転送してもよく、かつデータメッセージの使用のために、このＰＩＴエントリを削除してもよい。

図３１において示されるステップ３１において、ノード「２」３０２のＳＰＤ２ ３１２は、ノード「３」３０３及びノード「４」３０４に関する複数の集約されたサービスプロファイルを含む２つの新しいデータメッセージを受信してもよく、ノード「２」３０２に関するキャッシュされた複数のサービスプロファイルと共に、ノード「３」３０３及びノード「４」３０４に関する、受信した複数のサービスプロファイルを集約してもよく、ノード「２」３０２に関する、新しい複数の収集されかつ集約されたサービスプロファイルを生成してもよく、そしてその後、新しい複数の収集されかつ集約されたサービスプロファイルをキャッシュの中に記憶してもよい。

ＳＰＤ２ ３１２は、「Ｄ３（ｎｍ＝／ｓｄｉｓ／ｎ３／ｎ２、ｄｐ＝ｓｐ３）」のデータペイロードからノード「３」３０３に関するキャッシュされた複数のサービスプロファイル「ｓｐ３」を取得してもよく、かつ「Ｄ４（ｎｍ＝／ｓｄｉｓ／ｎ４／ｎ２、ｄｐ＝ｓｐ４）」のデータペイロードからノード「４」３０４に関するキャッシュされた複数のサービスプロファイル「ｓｐ４」を取得してもよく、ノード「２」３０２に関するキャッシュされた複数のサービスプロファイル「ｓｐ２」と共に、「ｓｐ３」及び「ｓｐ４」を集約してもよく（ｓｐ’２＝ｓｐ４＋ｓｐ３＋ｓｐ２）、そしてその後、収集されかつ集約された複数のサービスプロファイル「ｓｐ’２」をキャッシュの中に記憶してもよい。また、ＳＰＤ２ ３１２は、複数の個別の名前プレフィックス、「Ｄ３」の「／ｓｄｉｓ／ｎ３／ｎ２」及び「Ｄ４」の「／ｓｄｉｓ／ｎ４／ｎ２」と、既存の複数の個別ＦＩＢエントリ、「／ｓｄｉｓ／ｎ３：ｆ２２」及び「／ｓｄｉｓ／ｎ４：ｆ２３」、との最も長い一致により、着信するデータメッセージ「Ｄ３（ｎｍ＝／ｓｄｉｓ／ｎ３／ｎ２、ｄｐ＝ｓｐ３）」及び「Ｄ４（ｎｍ＝／ｓｄｉｓ／ｎ４／ｎ２、ｄｐ＝ｓｐ４）」を受信するローカル「ｃｃｎｄ」のフェースをたどってもよく、かつノード「３」の「ＳＰＤ３」及びノード「４」の「ＳＰＤ４」において公開された全ての利用可能なサービスについてたどられたフェース「ｆ２２」及び「ｆ２３」を使用して、ノード「２」に関する、複数のＦＩＢエントリ、「／ｎ３／ｓｖ^＊：ｆ２２」及び「／ｎ４／ｓｖ^＊：ｆ２３」、の２つの新しいグループを設定してもよい。

ＳＰＤ２ ３１２は、データペイロードにおいて、ノード「２」３０２に関して集約されかつキャッシュされた複数のサービスプロファイル「ｓｐ２」を含む同じ名前プレフィックス「Ｉ２」を伴う新しいサービス探索データメッセージ「Ｄ２（ｎｍ＝／ｓｄｉｓ／ｎ２／ｎ１、ｄｐ＝ｓｐ’２）」を生成してもよく、そしてその後、フェース「ｆ２ｓ」を介して、「Ｄ２」を、ノード「２」３０２の「ｃｃｎｄ２」に送り返してもよい。ノード「２」３０２の「ｃｃｎｄ２」は、既存の個別ＰＩＴエントリ「／ｓｄｉｓ／ｎ２／ｎ１（ｓｎ２、ｈ＝１）：ｆ２１」に基づき、送出されるデータメッセージ「Ｄ２（ｎｍ＝／ｓｄｉｓ／ｎ２／ｎ１、ｄｐ＝ｓｐ’２）」を、フェース「ｆ２１」を介して、ノード「１」３０１の「ｃｃｎｄ１」に転送してもよく、かつデータメッセージの使用のために、このＰＩＴエントリを削除してもよい。

サービス探索データメッセージ「Ｄ２（ｎｍ＝／ｓｄｉｓ／ｎ２／ｎ１、ｄｐ＝ｓｐ２）」を受信する場合、ノード「１」３０１の「ｃｃｎｄ１」は、既存の個別ＰＩＴエントリ「／ｓｄｉｓ／ｎ２／ｎ１（ｓｎ２、ｈ＝１）：ｆ１ｓ」に基づき、フェース「ｆ１ｓ」を介して、着信するデータメッセージ「Ｄ２」を、ＳＰＤ１ ３１１に転送してもよく、かつデータメッセージの使用のために、このＰＩＴエントリを削除してもよい。

図３２において示されるステップ７において、ＳＰＤ１ ３１１は、「Ｄ２（ｎｍ＝／ｓｄｉｓ／ｎ２／ｎ１、ｄｐ＝ｓｐ’２）」のデータペイロードからノード「２」３０２に関するキャッシュされた複数のサービスプロファイル「ｓｐ’２」を取得してもよく、ノード「１」３０１に関するキャッシュされた複数のサービスプロファイル「ｓｐ１」と共に、「ｓｐ’２」を集約してもよく（ｓｐ’１＝ｓｐ’２＋ｓｐ１＝ｓｐ４＋ｓｐ３＋ｓｐ２＋ｓｐ１）、そしてその後、収集されかつ集約された複数のサービスプロファイル「ｓｐ’１」をキャッシュの中に記憶してもよい。また、ＳＰＤ１ ３１１は、個別の名前プレフィックス、「Ｄ２」の「／ｓｄｉｓ／ｎ２／ｎ１」と、既存の個別ＦＩＢエントリ「／ｓｄｉｓ／ｎ２：ｆ１１」との最も長い一致により、着信するデータメッセージ「Ｄ２（ｎｍ＝／ｓｄｉｓ／ｎ２／ｎ１、ｄｐ＝ｓｐ’２）」を受信するローカル「ｃｃｎｄ」のフェースをたどってもよく、かつノード「２」３０２のＳＰＤ２ ３１２、ノード「３」３０３のＳＰＤ３ ３１３、及びノード「４」３０４のＳＰＤ４ ３１４において公開された全ての利用可能なサービスについてたどられたフェース「ｆ１１」を使用して、ノード「１」３０１に関する、複数のＦＩＢエントリ「／ｎ２／ｓｖ^＊：ｆ１１」の新しいグループを設定してもよい。

新しい収集されかつ集約された複数のサービスプロファイルを返すために、ＳＰＤ１ ３１１は、２つのオプションを有してもよい。１つのオプションは、ノード「１」３０１に関する新しい収集されかつ集約された複数のサービスプロファイル「ｓｐ’１」をアプリケーションＡＰＰ１ ３２１に返すために、ＳＰＤ１ ３１１は、ＳＰＤ ＡＰＩｓを利用してもよい、ということであってもよい。

第２のオプションは、ＳＰ１ ３１１が、データペイロードにおいて、ノード「１」に関する新しい収集されかつ集約された複数のサービスプロファイル「ｓｐ’１」を含む同じ名前プレフィックス「Ｉ１」を伴う新しいサービス探索データメッセージ「Ｄ１（ｎｍ＝／ｓｄｉｓ、ｄｐ＝ｓｐ’１）」を生成してもよく、そしてその後、フェース「ｆ１ｓ」を介して、「Ｄ１」をノード「１」３０１における「ｃｃｎｄ１」に送り返してもよい、ということであってもよい。ノード「１」３０１における「ｃｃｎｄ１」は、既存のＰＩＴエントリ「／ｓｄｉｓ（ｓｎ２、ｈ＝２）：ｆ１ａ」に基づき、「Ｄ１（ｎｍ＝／ｓｄｉｓ、ｄｐ＝ｓｐ’１）」を、フェース「ｆ１ａ」を介して、アプリケーションＡＰＰ１ ３２１に転送してもよく、かつデータメッセージの使用のために、このＰＩＴエントリを削除してもよい。

最後に、図３３において示されるステップ８において、アプリケーションＡＰＰ１ ３２１は、単一のサービス探索セッションにおいて、ノード「１」３０１から２−ホップの範囲内の、ノード「１」３０１、ノード「２」３０２、ノード「３」３０３、及びノード「４」４０４により知られる全ての利用可能なサービス（プロファイル）を発見してもよく、かつ複数の中間ノードの複数のフェース、例えば、「／ｎ１／ｓｖ^＊：ｆ１ｓ＠ｎ１」及び「／ｎ２／ｓｖ^＊：ｆ１１＠ｎ１−−ｆ２ｓ＠ｎ２」、「／ｎ３／ｓｖ^＊：ｆ１１＠ｎ１−−ｆ２２＠ｎ２−−ｆ３ｓ＠ｎ３」及び「／ｎ４／ｓｖ^＊：ｆ１１＠ｎ１−−ｆ２３＠ｎ２−−ｆ４ｓ＠ｎ３」、をたどることにより、ノード「１」３０１から、ノード「１」３０１、ノード「２」３０２、ノード「３」３０３、及びノード「４」４０４において利用可能な任意の複数のサービスへの、第１の利用可能な経路を見出してもよい。

開示される名前ベースのサービス探索プロトコルは、前述の複数の設計の原則及びインタレスト−データメッセージ交換を使用する提案される複数の方式により、マルチ−ホップサービス探索シナリオへ容易に拡張されることが可能であり得る。

異なるホップ数を定義することにより、ＳＰＤはネットワークにおける探索の範囲を制御することができる。また、Ｚｅｒｏｃｏｎｆにおけるそれと同様に、ＳＰＤは、複数のパラメータを満たす複数のサービス記述だけが各ノードにより返されるようにするため、複数の探索パラメータを指定してもよい。これにより、ドメイン、種別、及び他の複数のパラメータによる探索が可能となる。

ｃｃｎノードの開始プログラム（ｉｎｉｔｉａｔｏｒ）からの経路を構築するために、どのようにプロトコルを使用することができるかを説明するための、マルチ−ホップサービス探索の１つの活用事例がここに記載される。例えば、図１６−３３におけるＡＰＰ１ ３２１が、それ自身から専用ノード、例えば、ｃｃｎｄ４ ３０４、への可能な複数の経路を調査することを望んでいると仮定する。各ＣＣＮノードついて、ローカルサービスは、その名前、すなわち、ｎａｍｅ＿ｐｒｏｆｉｌｅ＝｛ｎ４｝、と共にサービスプロファイルを公開する。探索プロトコルの最中、各ノードは、複数のプロファイルを受信してもよく、当該複数のプロファイルとそれ自身のローカルのｎａｍｅ＿ｐｒｏｆｉｌｅとを集約してもよく、かつ探索インタレストに対して応答を返してもよい。例えば、ＳＰＤ３ ３１３は、Ｄ３＝｛ｎ３｝と共に応答してもよく、ＳＰＤ４ ３１４は、Ｄ４＝｛ｎ４｝と共に応答してもよく、ＳＰＤ２ ３１２は、Ｄ２＝Ｄ４＋Ｄ３＝｛ｎ２、｛ｎ３、ｎ４｝｝と共に応答してもよい。ＳＰＤ１ ３１１がこれらの応答を受信する場合、ＳＰＤ１ ３１１は、ＡＰＰ１ ３２１にこれらの応答を戻すために転送してもよく、その後ＡＰＰ１ ３２１は、ノード「４」３０４におけるｃｃｎｄ４に到達する経路である｛ｎ１、ｎ４｝を特定することができる。

一般に、単一の宛先ノードに到達するのに利用可能な複数の経路が存在し得る。開始プログラムは、１つを選択してもよい。また、開始プログラムは、（複数の）経路を更新するために、複数の探索インタレストを周期的に送信してもよい。

経路探索は、センサネットワーク、アドホックネットワーク、及びモノのインターネット（ｉｎｔｅｒｎｅｔ−ｏｆ−ｔｈｉｎｇｓ）等の、トポロジーの観点から動的なネットワークにおいて、非常に重要な機能であり得る、ということに注意してもよい。

図３４は、ネットワークを介してデータを転送及び処理する任意の装置であり得る、ネットワークノード３４００の実施例を示す。例えば、ネットワークノード３４００は、上述の複数のＣＣＮ方式におけるコンテンツルータ又は任意のノード又はルータであってもよい。ネットワークノード３４００は、上述した名前ベースの近隣探索方法及びマルチ−ホップサービス探索方法を実行又はサポートするように構成されてもよい。ネットワークノード３４００は、他の複数のネットワーク構成要素からの複数の信号及び複数のフレーム／データを受信する受信部（Ｒｘ）３４１２と結合された１つ又は複数の入力ポート（また、複数のインターフェース又は複数のフェースとも呼ばれる）３４１０を含んでもよい。ネットワークノード３４００は、コンテンツをどのネットワーク構成要素に送信するかを判定するための、コンテンツ認識部３４２０を含んでもよい。コンテンツ認識部３４２０は、ハードウェア、ソフトウェア、又はその両方を使用して実装されてもよい。また、ネットワークユニット３４００は、他の複数のネットワーク構成要素に複数の信号及び複数のフレーム／データを送信する送信部（Ｔｘ）３４３２と結合された１つ又は複数の出力ポート（また、複数のインターフェース又は複数のフェースとも呼ばれる）３４３０を含んでもよい。また、受信部３４１２、コンテンツ認識部３４２０、及び送信部３４３２は、少なくとも、開示される複数の方法のいくつかを実行するように構成されてもよく、これらは、ハードウェア、ソフトウェア、又はその両方に基づいていてもよい。ネットワークノード３４００の複数の構成要素は、図３４において示されるように構成されてもよい。

また、コンテンツ認識部３４２０は、プログラマブルコンテンツ転送面ブロック３４２８及びプログラマブルコンテンツ転送面ブロック３４２８と結合され得る１つ以上の記憶ブロック３４２２を含んでもよい。プログラマブルコンテンツ転送面ブロック３４２８は、Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ（ＯＳＩ）モデルにおけるアプリケーションレイヤ又はレイヤ３（Ｌ３）等の、コンテンツ転送及び処理機能を実行するように構成されてもよい。ここで、コンテンツは、コンテンツ名又はプレフィックス及び場合によってはコンテンツをネットワークトラフィックに対応付ける他のコンテンツ関連情報に基づいて転送されてもよい。このようなマッピング情報は、コンテンツ認識部３４２０又はネットワークユニット３４００のコンテンツテーブルの中で維持されてもよい。プログラマブルコンテンツ転送面ブロック３４２８は、コンテンツに対する複数のユーザ要求を解釈してもよく、かつそれに応じて、ネットワーク又は他の複数のコンテンツルータから、例えば、メタデータ及び／又はコンテンツ名に基づいて、コンテンツを取得してもよく、かつコンテンツを、例えば、一時的に、記憶ブロック３４２２に記憶してもよい。プログラマブルコンテンツ転送面ブロック３４２８は、その後、キャッシュされたコンテンツをユーザに転送してもよい。プログラマブルコンテンツ転送面ブロック３４２８は、ソフトウェア、ハードウェア、又はその両方を使用して実装されてもよく、そしてＯＳｉモデルにおけるＩＰレイヤ又はレイヤ２（Ｌ２）の上で動作してもよい。記憶ブロック３４２２は、加入者により要求されたコンテンツ等のコンテンツを一時的に記憶するためのキャッシュ３４２４を含んでもよい。さらに、記憶ブロック３４２２は、発行者によって提出されるコンテンツ等のコンテンツを比較的長く記憶するための長期記憶部３４２６を含んでもよい。例えば、キャッシュ３４２４及び長期記憶部３４２６は、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）、ソリッドステートドライブ（ＳＳＤ）、ハードディスク、又はそれらの組合せを含んでもよい。

上述の複数のネットワークコンポーネントは、それに課される必要な作業負荷を処理するための十分な処理能力、メモリリソース、及びネットワークスループット能力を持つコンピュータ又はネットワーク構成要素等の、任意の汎用ネットワーク構成要素において実装されてもよい。図３５は、本明細書に開示された複数の構成要素の１つ以上の実施例を実現するのに適した、典型的な汎用ネットワーク構成要素３５００を示している。ネットワーク構成要素３５００は、二次記憶部３５０４、読み出し専用メモリ（ＲＯＭ）３５０６、ランダム・アクセス・メモリ（ＲＡＭ）３５０８、及びネットワーク接続装置３５１２を含む、複数のメモリ装置と通信しているプロセッサ３５０２（それは中央処理装置又はＣＰＵと呼ばれてもよい）を含む。プロセッサ３５０２は、１つ以上のＣＰＵチップとして実装されてもよく、或いは１つ以上の特定用途向け集積回路（ＡＳＩＣ）の一部であってもよい。

二次記憶部３５０４は、典型的には、１つ以上のディスクドライブ又はテープドライブから構成され、そしてデータの不揮発性記憶のため及びＲＡＭ３５０８が全ての作業データを保持するのに十分な大きさでない場合のオーバフローデータ記憶部として使用される。二次記憶部３５０４は、複数のプログラムを記憶するために使用されてもよい。そのような複数のプログラムが実行のために選択された場合には、ＲＡＭ３５０８にロードされる。ＲＯＭ３５０６は、複数の命令及び場合によってはプログラムの実行中に読み込まれるデータを記憶するために使用される。ＲＯＭ３５０６は、典型的には、二次記憶部３５０４の大きなメモリ容量と比べて小さいメモリ容量を有する不揮発性メモリである。ＲＡＭ３５０８は、揮発性データを記憶するため及び場合によっては複数の命令を記憶するために使用される。ＲＯＭ３５０６及びＲＡＭ３５０８の双方へのアクセスは、典型的には、二次記憶部３５０４に対する場合よりも速い。

１つ以上の実施例が開示され、かつ当業者によって行われる（複数の）実施例及び／又は（複数の）実施例の複数の特徴の変形、組合せ、及び／又は変更は、本開示の範囲内である。（複数の）実施例の複数の特徴の組合せ、統合、及び／又は省略により生じる複数の代替の実施例もまた、本開示の範囲内である。数値範囲又は限定が明確に記載されている場合、そのような明示的な範囲又は限定は、明示的に記載された範囲又は限定内に属する同様な大きさの反復的な範囲及び限定を含むものと理解されるべきである（例えば、約１から約１０までは、２、３、４等を含む；０．１より大きいは、０．１１、０．１２、０．１３等を含む）。例えば、下限、Ｒ_ｌ、及び上限、Ｒ_ｕ、を伴って数値範囲が開示される場合は常に、その範囲に属する任意の数が具体的に開示されている。特に、以下の範囲内の数値が具体的に開示されている：Ｒ＝Ｒｌ＋ｋ^＊（Ｒｕ−Ｒｌ）、ここで、ｋは１パーセントの増加を伴う１パーセントから１００パーセントの範囲に及ぶ変数である、すなわち、ｋは１パーセント、２パーセント、３パーセント、４パーセント、７パーセント、…、７０パーセント、７１パーセント、７２パーセント、．．．、９７パーセント、９６パーセント、９７パーセント、９８パーセント、９９パーセント、又は１００パーセントである。また、上に定義されたように、２つのＲ数により定められる任意の数値範囲もまた、具体的に開示される。特に明記しない限り、用語「約（ａｂｏｕｔ）」の使用は、その後の数の１０％を意味する。請求項の任意の要素に関する用語「選択的に（ｏｐｔｉｏｎａｌｌｙ）」の使用は、その要素が必須であることを意味し、或いは代替的に、その要素が必須ではないことを意味し、両方の選択肢は、その請求項の範囲内である。「包含する（ｃｏｍｐｒｉｓｅｓ）」、「含む（ｉｎｃｌｕｄｅｓ）」、及び「有する（ｈａｖｉｎｇ）」等のより広い用語の使用は、「からなる（ｃｏｎｓｉｓｔｉｎｇ ｏｆ）」、「本質的に〜からなる（ｃｏｎｓｉｓｔｉｎｇ ｅｓｓｅｎｔｉａｌｌｙ ｏｆ）」、及び「実質的に〜を包含する（ｃｏｍｐｒｉｓｅｄ ｓｕｂｓｔａｎｔｉａｌｌｙ ｏｆ）」等のより狭い用語に対するサポートを与えるものであると理解されるべきである。従って、保護の範囲は、上に述べられた記載によっては限定されず、そうではなくて以下の複数の請求項により定められ、その範囲は、複数の請求項の内容の全ての均等物を含む。各クレームはいずれも、明細書への追加の開示として取り入れられており、かつ複数の請求項は、本開示の（複数の）実施例である。本開示における参考文献、特に本出願の優先日後の公開日を有する任意の参考文献、の考察は、それが従来技術であるということを認めるものではない。本開示において引用される全ての特許、特許出願、及び刊行物の開示は、それらが本開示を補足する典型的、手続き上の、又は他の詳細を与えるという程度において、参照により本明細書に援用される。

本開示において、いくつかの実施例が提供されているが、開示される複数のシステム及び方法は、本開示の精神又は範囲から逸脱することなく、他の複数の特定の形態において具体化されることがある、ということが理解されるべきである。これらの複数の例は、例示であり、かつ限定するものではないとして考慮されるべきであり、そしてその意図は、本明細書に与えられた詳細に限定するものではない。例えば、各種要素又は構成要素は、組み合わされてもよく、或いは他のシステムにおいて統合されてもよく、又は特定の特徴を省略してもよく、或いは実装されない場合がある。

また、各種実施例において、分離した又は離れたものとして記載及び説明される技術、システム、サブシステム、及び方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、技術、又は方法と組み合わされてもよく、或いは統合されてもよい。結合される、又は直接結合される、又は互いに通信するとして示される又は考察される他の複数の項目は、間接的に結合されてもよく、或いは電気的、機械的、又はその他を問わず、いくつかのインターフェース、装置、又は中間の構成要素を介して通信してもよい。改変、置換、及び変更のその他の複数の例は、本明細書に開示される精神及び範囲から逸脱することなく、当業者により発見可能であり、かつ行われ得る。

Claims (18)

1. コンテンツルータであって：
   情報中心ネットワーク内の他の複数のノードに対する複数の物理リンク；
   複数のメッセージを受信するように構成される前記複数の物理リンクと結合される受信部；
   複数のメッセージを送信するように構成される前記複数の物理リンクと結合される送信部；及び
   前記受信部及び送信部と結合されるプロセッサ及びメモリ装置を含むサービス公開及び探索（ＳＰＤ）モジュールであって、前記ＳＰＤは前記複数の物理リンクの状態の更新を記憶するように構成される、サービス公開及び探索（ＳＰＤ）モジュール；
   を備え、
   前記ＳＰＤは、受信したインタレストメッセージを転送するための次のホップ及びホップの数を、該受信したインタレストメッセージの名前ベースのサービス探索プロトコル名の中のプレフィックスに含まれるホップ数フィールドを参照することで決定するように構成される、
   コンテンツルータ。
2. 前記名前ベースのサービス探索プロトコルは、名前ベースのサービス探索メッセージに含まれる第１の項、第２の項、及び第３の項を含み、前記第１の項は事前に定められたサービス検索インタレスト及びデータメッセージを含み、前記第２の項は次の宛先ホップノードの名前プレフィックスを表し、かつ前記第３の項は現在の起点ホップノードの名前プレフィックスを表す、
   請求項１に記載のコンテンツルータ。
3. 前記現在の起点ホップノードに関する前記ＳＰＤは、未達の複数のホップノードに対する新しいインタレストメッセージを作成するように構成され、新しいインタレストメッセージは、名前プレフィックスを伴う後方インタレストメッセージが前記現在のホップノードから送信されることを防止するために、前のホップを含まない新しい名前プレフィックスを含む、
   請求項２に記載のコンテンツルータ。
4. 前記コンテンツルータは、収集されかつ集約されたサービスプロファイルからの複数の中間ノードの複数のフェースをたどることにより、起点ノードから遠隔ノード上の利用可能なサービスへの第１の利用可能な経路を検出するように構成される、
   請求項１に記載のコンテンツルータ。
5. 前記ＳＰＤは、現在のホップに到達した前記複数のインタレストメッセージを処理し、かつ現在のホップにおいて受信された前記インタレストメッセージの１つから１だけ少ない新しいホップ数を伴う次のホップについての新しい複数のインタレストメッセージを作成するように構成される、
   請求項１に記載のコンテンツルータ。
6. 受信したインタレストメッセージの前記ホップ数が０に等しい場合、前記ＳＰＤは次のホップに関する新しいインタレストメッセージを作成せず、かつ前記ＳＰＤは、前記受信したインタレストメッセージに対して、データメッセージの中の集約されかつキャッシュされたサービスプロファイルにより応答する、
   請求項５に記載のコンテンツルータ。
7. 前記名前ベースのサービス探索プロトコルは、特定のサービス探索セッションにおける特定の起点ノードから発せられた複数のインタレストメッセージの特定のセットと、異なる複数のセッションにおける異なる複数の起点ノードから発せられた他の複数のインタレストメッセージとを区別するための、インタレストメッセージの中のセッション補助変数属性を含む、
   請求項１に記載のコンテンツルータ。
8. 前記ＳＰＤは、前記セッション補助変数属性に基づき、冗長かつ繰り返しの複数のインタレストメッセージのうちの、１つのインタレストメッセージの処理を回避するように構成される
   請求項７に記載のコンテンツルータ。
9. 前記送信部は、データメッセージの中の集約された複数のサービスプロファイルを伴う最初に受信されるインタレストメッセージだけに応答し、かつその後に到着する複数のインタレストメッセージが同じセッション補助変数を含む場合、その後に到着する複数のインタレストメッセージを破棄するように構成される、
   請求項７に記載のコンテンツルータ。
10. ネットワークノードであって：
    情報中心ネットワーク内の複数の遠隔ノードからの／へのインタレストメッセージ及びデータメッセージを受信／送信するように構成される複数のインターフェース；
    前記複数のインターフェースと結合するプロセッサを含むリンクマネージャ（ＬＭ）であって、前記ＬＭは、前記複数のインターフェースを監視するように構成される、リンクマネージャ（ＬＭ）；及び
    プロセッサを含みかつ前記複数のインターフェース及び前記ＬＭに結合されるローカルサービス公開及び探索（ＳＰＤ）モジュールであって、前記ローカルＳＰＤモジュールは、ローカルノードの複数のサービスにより公開された複数のサービスプロファイルと前記複数の遠隔ノードの中の複数の遠隔ＳＰＤから収集された複数のサービスプロファイルとを集約するように構成され、複数のローカルサービスは、前記ローカルＳＰＤモジュールに対してのみ公開され、前記ローカルＳＰＤモジュールは、前記ローカルノードから指定されたホップ内の前記複数の遠隔ノードのうちの到達可能な１つにおける利用可能なサービスを探索するように構成され、かつ前記ローカルＳＰＤモジュールは、前記複数のサービスプロファイルの名前ベースのサービス探索プロトコル名の中のプレフィックスに基づき、対応する複数のインターフェースを持つ前記複数の遠隔ノードを構成及び登録するように構成される、ローカルサービス公開及び探索（ＳＰＤ）モジュール；
    を備え、
    前記ＬＭは、前記複数の遠隔ノードのうちの１つに対する新しいリンクが前記複数のインターフェースのうちの１つにおいて検出された場合に、前記ローカルＳＰＤモジュールに通知するように構成され、
    前記ローカルＳＰＤモジュールは、受信したインタレストメッセージを転送するための次のホップ及びホップ数を、該受信したインタレストメッセージの名前ベースのサービス探索プロトコル名のプレフィックスに含まれるホップ数フィールドを参照することで決定するように構成される、
    ネットワークノード。
11. 前記ローカルＳＰＤモジュールは、前記インタレストメッセージを受信し、かつ前記ホップ数がゼロでない場合に、新しいホップ数を伴う新しいインタレストメッセージを作成するように構成され、前記新しいホップ数は、１を減じた前記ホップ数に等しい、
    請求項１０に記載のネットワークノード。
12. 前記ローカルＳＰＤモジュールは、前記ホップ数がゼロに等しい場合に、前記インタレストメッセージに応答して応答データメッセージを作成するように構成される、
    請求項１０に記載のネットワークノード。
13. 前記インタレストメッセージは、起点ノードの名前を含む、
    請求項１０に記載のネットワークノード。
14. 前記ローカルＳＰＤモジュールは、前記起点ノードに対してインタレストメッセージを転送しないように構成される、
    請求項１３に記載のネットワークノード。
15. 情報中心ネットワークの中の複数のサービスを発見するプロセッサを備えるネットワークノードにより実行される方法であって：
    複数のローカルサービスの複数のサービスプロファイルを受信するステップ；
    前記プロセッサにより、遠隔ノードに対するインタレストメッセージを準備するステップであって、前記インタレストメッセージは、複数のサービスプロファイル及び該インタレストメッセージを転送するためのホップ及びホップ数を決定するための前記遠隔ノードにより参照されるホップ数フィールドを含む、準備するステップ；
    前記遠隔ノードからデータメッセージを受信するステップであって、前記データメッセージは前記遠隔ノードにより及び前記遠隔ノードの前記ホップ数内の前記遠隔ノードと結合された他の複数の遠隔ノードから提供される複数のサービスに対する集約された複数のサービスプロファイルを含む、受信するステップ；及び
    前記プロセッサにより、前記複数のローカルサービスの前記複数のサービスプロファイル及び前記遠隔ノードから受信した前記集約された複数のサービスプロファイルを集約するステップ；
    を備える、方法。
16. 前記インタレストメッセージは第１のインタレストメッセージを含み、前記遠隔ノードは第１の遠隔ノードを含む、請求項１５に記載の方法であって、さらに：
    前記第１の遠隔ノードから第２のインタレストメッセージを受信するステップであって、
    前記第２のインタレストメッセージは、複数のサービスプロファイルの第２の要求及び第２のホップ数を含み、前記第２のホップ数は、前記第２のインタレストメッセージを転送するための、前記第１の遠隔ノードから離れるホップ数を指定する、第２のインタレストメッセージを受信するステップ；及び
    第２の遠隔ノードに第３のインタレストメッセージを送信するステップであって、前記第３のインタレストメッセージは、前記複数のサービスプロファイルの第２の要求及び第３のホップ数を含み、前記第３のホップ数は、１を減じた前記第２のホップ数に等しく、かつ前記第３のホップ数は、前記第３のインタレストメッセージを転送するための、ローカルノードから離れるホップ数を示す、送信するステップ；
    を備える、請求項１５に記載の方法。
17. 前記データメッセージは第１のデータメッセージを含む、請求項１６に記載の方法であって、さらに：
    前記第２の遠隔ノードから第２のデータメッセージを受信するステップであって、前記第２のデータメッセージは、前記第２の遠隔ノード及び前記第１の遠隔ノードから前記第２のホップ数以内の複数の遠隔ノードにより提供される複数のサービスに関する集約された複数のサービスプロファイルを含む、第２のデータメッセージを受信するステップ；
    新しい集約された複数のサービスプロファイルを生成するために、前記第２のデータメッセージ内の前記複数のサービスプロファイルと、前記ローカルノードにより提供される複数のサービスの前記複数のサービスプロファイルとを集約するステップ；及び
    第３のデータメッセージの中の前記新しい集約された複数のサービスプロファイルを前記第１の遠隔ノードに送信するステップ；
    を備える、請求項１６に記載の方法。
18. 前記インタレストメッセージは、前記インタレストメッセージと他の複数のノードにより生成された複数のインタレストメッセージとを区別するためのセッション補助変数を含む、
    請求項１５に記載の方法。

Images