(57)【要約】      （修正有）【課題】情報指向型ネットワーク（ＩＣＮ）におけるマルチキャスト群と関連付けられるルーティング情報を更新するためのシステムを提供する。【解決手段】ＩＣＮにおける第１のノードは、マルチキャスト群のための更新メッセージを隣接ノードから受信する。マルチキャスト群は、ルートアンカーノードおよび多数のアンカーノードを含み、ルートアンカーノードは、アンカーノードより小さい名前を有する。更新メッセージは、マルチキャスト群およびマルチキャスト群のルートアンカーノードと関連付けられる、プレフィックスを特定する。システムは、第１のノードに保存されるトポロジ情報に基づいて、第１のノードの隣接ノードから、通知条件を満たす１つ以上の次ホップ隣接ノードを選択し、更新メッセージを１つ以上の次ホップ隣接ノードへ転送する。【選択図】図１
2016123088.tif 000002
【特許請求の範囲】
【請求項１】
情報指向型ネットワーク（ＩＣＮ）においてマルチキャスト群と関連付けられるルーティング情報を更新する、コンピュータ実行可能な方法であって、前記方法は、
前記ＩＣＮにおける第１のノードにより、前記マルチキャスト群の更新メッセージを隣接ノードから受信することであって、前記マルチキャスト群は、ルートアンカーノードおよび多数のアンカーノードを含み、前記ルートアンカーノードは、前記アンカーノードより小さい名前を有し、前記更新メッセージは、前記マルチキャスト群および前記マルチキャスト群の前記ルートアンカーノードと関連付けられるプレフィックスを特定する、受信すること、
前記第１のノードに保存されるトポロジ情報に基づいて、前記第１のノードの隣接ノードから、通知条件を満たす１つ以上の次ホップ隣接ノードを選択すること、および、
前記更新メッセージを、前記１つ以上の次ホップ隣接ノードへ転送すること、
を備える、コンピュータ実行可能な方法。
【請求項２】
前記通知条件を満たす次ホップ隣接ノードは、前記マルチキャスト群のアンカーノードであり、前記アンカーノードの全ての隣接ノードは、前記アンカーノードを好適なアンカーノードとして報告する、請求項１に記載の方法。
【請求項３】
前記通知条件を満たす次ホップ隣接ノードは、前記アンカーノードの少なくとも１つへの最短経路を提供する、請求項１に記載の方法。
【請求項４】
前記マルチキャスト群を接合しようとする第２のノードにより、接合要求を生成すること、
前記第２のノードの隣接ノードを、前記マルチキャスト群の前記ルートアンカーへの次ホップノードとして順序条件に基づいて選択することであって、前記ルートアンカーノードへの前記第２のノードの前記次ホップノードは、前記ルートアンカーノードへの最短経路を提供する、選択すること、および、
前記接合要求を、前記第２のノードの前記選択された隣接ノードへ転送すること、
をさらに備える、請求項１に記載の方法。
【請求項５】
前記ルートアンカーノードまたは前記マルチキャスト群のアンカーノードから送信された、前記接合要求に対する応答を受信すること、をさらに備え、
前記応答は、前記第２のノードへの前記接合要求の逆経路を辿る、請求項４に記載の方法。
【請求項６】
前記ルートアンカーノード、前記アンカーノード、および、前記接合要求を受信する１つ以上のルータを含む、マルチポイントスパニングツリーを確立すること、
をさらに備える、請求項４に記載の方法。
【請求項７】
前記ルートアンカーノードおよび前記アンカーノードは、
前記マルチキャスト群のソース、および、
前記マルチキャスト群の受信器、
のうちの１つである、請求項１に記載の方法。
【請求項８】
計算デバイスにより実行されると、前記計算デバイスに、情報指向型ネットワーク（ＩＣＮ）におけるマルチキャスト群と関連付けられるルーティング情報を更新するための方法を行わせる命令を保存する、持続性コンピュータ可読保存媒体であって、前記方法は、
前記ＩＣＮにおける第１のノードにより、前記マルチキャスト群のための更新メッセージを隣接ノードから受信することであって、前記マルチキャスト群は、ルートアンカーノードおよび多数のアンカーノードを含み、前記ルートアンカーノードは、前記アンカーノードより小さい名前を有し、前記更新メッセージは、前記マルチキャスト群および前記マルチキャスト群の前記ルートアンカーノードと関連付けられるプレフィックスを特定する、受信すること、
前記第１のノードに保存されるトポロジ情報に基づいて、前記第１のノードの隣接ノードから、通知条件を満たす１つ以上の次ホップ隣接ノードを選択すること、および、
前記更新メッセージを、前記１つ以上の次ホップ隣接ノードへ転送すること、
を備える、持続性コンピュータ可読保存媒体。
【請求項９】
前記通知条件を満たす次ホップ隣接ノードは、前記マルチキャスト群のアンカーノードであって、前記アンカーノードの隣接ノードは、前記アンカーノードを好適なアンカーノードとして報告する、請求項８に記載のコンピュータ可読保存媒体。
【請求項１０】
情報指向型ネットワーク（ＩＣＮ）におけるマルチキャスト群と関連付けられるルーティング情報を更新するためのコンピュータシステムであって、前記システムは、
プロセッサ、および、
前記プロセッサと結合され、前記プロセッサにより実行されると、前記プロセッサに方法を行わせる命令を保存する、保存デバイスであって、前記方法は、
前記ＩＣＮにおける第１のノードにより、前記マルチキャスト群のための更新メッセージを隣接ノードから受信することであって、前記マルチキャスト群は、ルートアンカーノードおよび多数のアンカーノードを含み、前記ルートアンカーノードは、前記アンカーノードより小さい名前を有し、前記更新メッセージは、前記マルチキャスト群および前記マルチキャスト群の前記ルートアンカーノードと関連付けられるプレフィックスを特定する、受信すること、
前記第１のノードに保存されるトポロジ情報に基づいて、前記第１のノードの隣接ノードから、通知条件を満たす１つ以上の次ホップ隣接ノードを選択すること、および、
前記更新メッセージを、前記１つ以上の次ホップ隣接ノードへ転送すること、
を備える、保存デバイス、
を備える、コンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、一般的に、コンテンツ指向型ネットワーク（ＣＣＮ）に関する。より具体的には、本開示は、コンテンツ指向型ネットワーク（ＣＣＮ）において複数のソースを伴うマルチキャスト群を支援するシステムおよび方法に関する。
【背景技術】
【０００２】
インターネットおよび電子商取引の普及は、ネットワーク業界において革新的な変化を起こし続けている。今日では、オンライン動画の閲覧から、日々のニュース配信、小売販売、および、インスタントメッセージに至るまで、膨大な数の情報交換がオンラインで行われている。さらに、ますます多くのインターネット利用が、携帯電話で行われている。しかしながら、現代のインターネットは、主に位置ベースのアドレス方式で動作する。２つの最も普遍的なプロトコルである、インターネットプロトコル（ＩＰ）およびイーサネット（登録商標）プロトコルは、どちらもエンドホストアドレスに基づいている。すなわち、コンテンツの消費者は、コンテンツを、典型的に物理的な物体または位置と関連付けられるアドレス（例えば、ＩＰアドレスまたはイーサネット（登録商標）媒体アクセス制御（ＭＡＣ）アドレス）から、明示的にコンテンツを要求することにより、コンテンツを受信し得るのみである。この制限的なアドレス方式は、絶え間なく変わるネットワークの要求に応えることに対して、徐々に十分ではなくなってきている。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
近年、情報指向型ネットワーク（ＩＣＮ）アーキテクチャが、コンテンツが直接的に命名およびアドレス指定される業界において、提案されてきた。コンテンツ指向型ネットワーク（ＣＣＮ）において、例示的なＩＣＮアーキテクチャは、コンテンツ搬送への新しい手法をもたらす。アプリケーションレベルで、コンテンツが移動する際のエンドツーエンドの会話と見なされるネットワークトラフィックを有する代わりに、コンテンツは独自の名前に基づいて要求または返送され、ネットワークはコンテンツを提供者から消費者へのルーティングを行う役割を有する。コンテンツは、テキスト、画像、映像、および／または音声など、任意のデータ形式を含む、通信システムにおいて搬送され得るデータを含むことに、留意されたい。消費者および提供者は、ＩＣＮの内部または外部のコンピュータを操作する人物または自動化プロセスであり得る。１つのコンテンツは、コンテンツ全体またはコンテンツの各々の部分を指し得る。例えば、新聞記事は、データパケットとして具現化される複数のコンテンツにより表されてよい。さらに、１つのコンテンツは、認証データ、作成データ、コンテンツ所有者などの情報で、コンテンツを説明または拡大させる、メタデータと関連付けられ得る。
【０００４】
全てのＩＣＮアーキテクチャのコアは、名前解決およびコンテンツのルーティングであり、いくつかの手法が提案されてきた。一部のＩＣＮアーキテクチャにおいて、データオブジェクトの名前は、ディレクトリサーバを用いてアドレスにマッピングされ、その後、アドレスベースのルーティングがコンテンツ配信のために使用される。対照的に、多数のＩＣＮアーキテクチャは、名前解決およびコンテンツルーティングを統合する、コンテンツの名前ベースのルーティングを使用する。名前ベースのルーティングでは、一部のルータ（製作者またはキャッシングサイト）が、命名されたデータオブジェクト（ＮＤＯ）のローカルコピーの存在、または、共通プレフィックスを共有する一連の名前付きオブジェクトを示す名前プレフィックスの存在、を宣伝し、それらへのルートが確立される。コンテンツの消費者は、ＮＤＯまたは名前プレフィックスの宣伝を発行したルータへのルートに沿って転送される、コンテンツ要求を発行する。
【０００５】
様々なＩＣＮアーキテクチャの中で、ＣＣＮは、コンテンツ要求が転送されるルートを確立するために、分散ルーティングプロトコルを使用する。ＣＣＮにおいて、コンテンツ要求（「インタレスト」と称される）は、１つまたは複数の経路を介して名前プレフィックスへ送信されてよい。ＣＣＮなどのインタレストベースのＩＣＮアーキテクチャが、マルチキャスティングのための「自然な支援」を提供することが、議論されてきた。しかしながら、これは、インタレストの名前がマルチキャスト群のソースを示す場合、単一ソースのマルチキャスティングのためだけの事例である。
【課題を解決するための手段】
【０００６】
本発明の１つの実施形態は、情報指向型ネットワーク（ＩＣＮ）のマルチキャスト群と関連付けられるルーティング情報を更新するためのシステムを提供する。動作中、ＩＣＮの第１のノードは、マルチキャスト群のための更新メッセージを、隣接ノードから受信する。マルチキャスト群は、ルートアンカーノードおよび多数のアンカーノードを含み、ルートアンカーノードは、アンカーノードより小さい名前を有する。更新メッセージは、マルチキャスト群およびマルチキャスト群のルートアンカーノードと関連付けられる、プレフィックスを特定する。システムは、第１のノードに保存されるトポロジ情報に基づいて、第１のノードの隣接ノードから、通知条件を満たす１つ以上の次ホップ隣接ノードを選択して、更新メッセージを１つ以上の次ホップ隣接ノードへ転送する。
【０００７】
この実施形態の変形において、通知条件を満たす次ホップ隣接ノードは、マルチキャスト群のアンカーノードであり、アンカーノードの全ての隣接ノードは、アンカーノードを好適なアンカーノードとして報告する。
【０００８】
この実施形態の変形において、通知条件を満たす次ホップ隣接ノードは、アンカーノードのうちの少なくとも１つへの最短経路を提供する。
【０００９】
この実施形態の変形において、マルチキャスト群を接合しようとする第２のノードは、接合要求を生成する。システムは、第２のノードの隣接ノードを、マルチキャスト群のルートアンカーへの次ホップノードとして、順序条件に基づいて選択する。ルートアンカーノードへの第２のノードの次ホップノードは、ルートアンカーノードへの最短経路を提供する。システムは、接合要求を、選択された第２のノードの隣接ノードへ転送する。
【００１０】
さらなる変形において、システムは、ルートアンカーノードまたはマルチキャスト群のアンカーノードから送信された接合要求への応答を受信する。応答は、接合要求の逆経路を第２のノードへ辿る。
【００１１】
さらなる変形において、システムは、ルートアンカーノード、アンカーノード、および接合要求を受信する１つ以上のルータを含む、マルチポイントスパニングツリーを確立する。
【００１２】
この実施形態の変形において、ルートアンカーノードおよびアンカーノードは、以下のうちの１つである：マルチキャスト群のソースおよびマルチキャスト群の受信器。
【図面の簡単な説明】
【００１３】
【図１】図１は、本発明の実施形態にしたがって、ネットワークの例示的なアーキテクチャを図示する。
【図２】図２は、本発明の実施形態にしたがって、ルータで管理される例示的な隣接テーブルを図示する図を提示する。
【図３】図３は、本発明の実施形態にしたがって、ルータで管理される例示的なルーティングテーブルを図示する図を提示する。
【図４】図４は、本発明の実施形態にしたがって、ルータで管理される例示的なマルチポイントルーティングテーブルを図示する図を提示する。
【図５】図５は、本発明の実施形態にしたがって、ＩＣＭを実装するルータの例示的なアーキテクチャを提示する図を提示する。
【図６】図６は、本発明の実施形態にしたがって、例示的なＩＣＮにおけるルートアンカー更新の伝搬を図示する。
【図７】図７は、本発明の実施形態にしたがって、例示的なＩＣＮにおけるマルチインスタンス化目的地スパニングツリー（ＭＩＤＳＴ）の確立を図示する。
【図８】図８は、本発明の実施形態にしたがって、情報指向型マルチキャスティングのための例示的なシステムを図示する。
【発明を実施するための形態】
【００１４】
図において、同様の参照番号は同様の図要素を指す。
【００１５】
本発明の実施形態は、情報指向型ネットワーク（ＩＣＮ）において複数のソースを伴うマルチキャスト群を支援する、情報指向型マルチキャスティング（ＩＣＭ）システムを提供する。より具体的には、ＩＣＭは、マルチキャスト群を示す各名前プレフィックスのためのマルチインスタンス化目的地スパニングツリー（ＭＩＤＳＴ）を確立することにより、マルチキャスト群へのルーティングを支援する。所与のマルチキャスト群の全てのアンカーは、プレフィックスに対するＭＩＤＳＴを介して接続される。ＩＣＭは、ソース開始型マルチキャスティング（ＳＩＭ）および受信器開始型マルチキャスティングの両方を、支援し得る。
【００１６】
リンク状態型コンテンツルーティング（ＬＣＲ）システムの動作を実証するために、本開示は、ＣＣＮを例として使用する。しかしながら、ＬＣＲシステムの動作は、ＣＣＮに限定されない。一般的に、ＬＣＲは、任意の他の種類のＩＣＮネットワークへ適用され得る。
【００１７】
ＣＣＮは、２種類のメッセージを使用する。すなわち、インタレストとコンテンツオブジェクトである。インタレストは、コンテンツオブジェクトの「名前」とも称される、階層的に構造化された可変長識別子（ＨＳＶＬＩ）を保持し、オブジェクトの要求としての役割を果たす。ネットワーク要素（例えば、ルータ）が同じ名前に対する複数のインタレストを受信した場合、それらのインタレストを統合してよい。マッチングコンテンツオブジェクトを伴うインタレストの経路に沿うネットワーク要素は、オブジェクトをキャッシュおよび返送し、インタレストを満たす。コンテンツオブジェクトは、インタレストの起点（複数可）へ、インタレストの逆経路を辿る。
【００１８】
本開示において使用される用語は、一般的に、以下のように定義される（しかし、解釈はこれらに限定されない）：
【００１９】
「ＨＳＶＬＩ」：名前とも呼ばれる、階層的に構造化された可変長識別子。これは、名前コンポーネントの順序付きリストであり、可変長オクテット列であってよい。人間可読形式において、ｃｃｎｘ：／ｐａｔｈ／ｐａｒｔなどの形式で表され得る。さらに、ＨＳＶＬＩは、人間可読でなくてもよい。上述したように、ＨＳＶＬＩはコンテンツを指し、コンテンツの組織的な構造を表すことが可能であって、人間にとって少なくとも部分的に意味を持つことが望ましい。ＨＳＶＬＩの個々のコンポーネントは、任意の長さを有してよい。さらに、ＨＳＶＬＩは、明確に区切られたコンポーネントを有することができ、任意のバイト列を含むことができ、人間可読文字に限定されない。最長プレフィックス一致ルックアップは、ＨＳＶＬＩを伴うパケットの転送において重要である。例えば、「／ｐａｒｃ／ｈｏｍｅ／ｂｏｂ」においてインタレストを示すＨＳＶＬＩは、「／ｐａｒｃ／ｈｏｍｅ／ｂｏｂ／ｔｅｓｔ．ｔｘｔ」および「／ｐａｒｃ／ｈｏｍｅ／ｂｏｂ／ｂａｒ．ｔｘｔ」の両方に合致する。最長一致は、名前コンポーネントの数に関して、最も特定的であるため最良と見なされる。ＨＳＶＬＩの詳細な説明は、発明者Ｖａｎ  Ｌ．ＪａｃｏｂｓｏｎおよびＪａｍｅｓ  Ｄ．Ｔｈｏｒｎｔｏｎによる、２００９年９月２３日に出願された米国特許番号第８，１６０，０６９号「ＳＹＳＴＥＭ  ＦＯＲ  ＦＯＲＷＡＲＤＩＮＧ  Ａ  ＰＡＣＫＥＴ  ＷＩＴＨ  Ａ  ＨＩＥＲＡＲＣＨＩＣＨＡＬＬＹ  ＳＴＲＵＣＴＵＲＥＤ  ＶＡＲＩＡＢＬＥ−ＬＥＮＧＴＨ  ＩＤＥＮＴＩＦＩＥＲ（階層的に構造化された可変長識別子付きパケットを転送するシステム）」において、参照され得る。
【００２０】
「インタレスト」：コンテンツオブジェクトの要求。インタレストは、ＨＳＶＬＩの名前プレフィックス、および、同じ名前プレフィックスを伴う複数のオブジェクトの中から選択するために使用され得る、他の選択的なセレクタ、を特定する。名前がインタレストの名前プレフィックス（および、発行者キー−ＩＤ一致など、選択的に他の要求パラメータ）と一致する、任意のコンテンツオブジェクトは、インタレストを満たす。
【００２１】
「コンテンツオブジェクト」：インタレストに応答して送信される、データオブジェクト。暗号署名を介して結合された、ＨＳＶＬＩ名およびコンテンツペイロードを有する。選択的に、全てのコンテンツオブジェクトは、コンテンツオブジェクトのＳＨＡ−２５６ダイジェストからなる、間接的な終端名を有する。１つの実施形態において、間接的なダイジェストは、有線で搬送されないが、必要に応じて各ホップで計算される。この開示において、「コンテンツオブジェクト」という用語、および、「命名されたデータオブジェクト（ＮＤＯ）」という用語は、交換可能である。
【００２２】
「フェイス」：ＣＣＮにおいて、フェイスという用語は、インタフェースの概念を一般化したものである。フェイスは、ネットワークへの接続であってよく、または、アプリケーション側への直接的な接続であってよい。フェイスは、特定のネットワークインタフェースでブロードキャストまたはマルチキャストのパケットを、送信および受信するよう構成されてよく、または、下位の搬送におけるポイントツーポイントのアドレス指定を使用して、または、トンネル（例えば、ＴＣＰトンネル）を使用して、パケットを送信および受信するよう構成されてよい。さらに、フェイスは、ＵＤＰまたはＯＳ特有のプロセス間通信経路のようなカプセル化を介する、同じ機器で起動する単一のアプリケーションプロセスへの接続であってよい。全てのメッセージは、フェイスを介して到着し、フェイスを介して送出される。この開示において、「隣接ノード」という用語は、「フェイス」という用語と交換可能であり、インタレストの入力または出力インタフェースを指す。
【００２３】
「インスタンス」：この開示において、「インスタンス」という用語は、マルチキャスト群の受信器またはソースのいずれかを指すために、使用され得る。
【００２４】
「プレフィックス」：この開示において、「プレフィックス」という用語は、特定のマルチキャスト群の名前、または、マルチキャスト群の名前プレフィックスのいずれかを指すために、使用され得る。
【００２５】
「アンカー」：この開示において、「アンカー」という用語は、局所的に利用可能なマルチキャスト群のインスタンスを有することを宣伝するルータを指すために、使用される。より具体的には、プレフィックスに対応するコンテンツの一部または全てを宣伝するルータ（または、ノード）が、プレフィックスのアンカーとして参照される。
【００２６】
先に述べたように、ＨＳＶＬＩは１つのコンテンツを表し、階層的に構造化されていて、最も一般的なレベルから最も特定的なレベルへ順序付けられた、連続するコンポーネントを含む。各々のＨＳＶＬＩの長さは、固定されていない。コンテンツ指向型ネットワークにおいて、従来のＩＰネットワークとは異なり、パケットはＨＳＶＬＩにより識別されてよい。例えば、「ａｂｃｄ／ｂｏｂ／ｐａｐｅｒｓ／ｃｃｎ／ｎｅｗｓ」は、コンテンツの名前である可能性があり、対応するパケット（複数可）を識別する。すなわち、「ＡＢＣＤ」という名前の組織で、「Ｂｏｂ」という名前のユーザに対する、新聞の「ｃｃｎ」収集からの「ニュース」記事を表す。コンテンツを要求するために、ノードは、コンテンツのインタレストをコンテンツの名前により表現（例えば、ブロードキャスト）する。コンテンツのインタレストは、コンテンツの名前または識別子による、コンテンツの問い合わせであり得る。ネットワークにおいて入手可能である場合、コンテンツは、コンテンツを保存する任意のノードから要求ノードへ返送される。ルーティング基盤は、インタレストを、情報を有すると思われる予想ノードへ知的に伝搬し、その後、インタレストメッセージが辿る逆経路に沿って戻される、利用可能なコンテンツを保持する。基本的に、コンテンツオブジェクトは、インタレストメッセージにより残されるパン屑リストにしたがって、要求ノードに到達する。
【００２７】
図１は、本発明の実施形態にしたがって、ネットワークの例示的なアーキテクチャを図示する。この例において、ネットワーク１８０は、ノード１００〜１４５を備える。ネットワークにおける各ノードは、１つ以上の他のノードと結合される。ネットワーク接続１８５は、そのような接続の例である。ネットワーク接続は実線で示され、各線は、さらに、１つのノードを別のノードと結合し得る、サブネットワークまたはスーパーネットワークを提示し得る。ネットワーク１８０は、コンテンツ指向型、ローカルネットワーク、スーパーネットワーク、または、サブネットワークであり得る。これらのネットワークの各々は、１つのネットワークのノードが他のネットワークのノードに到達し得るよう、相互に接続され得る。ネットワーク接続は、ブロードバンド、無線、電話、衛星、または、任意の種類のネットワーク接続であり得る。ノードは、コンピュータシステム、ユーザを表すエンドポイント、および／または、インタレストを生成し得る、または、コンテンツを生じさせ得る、デバイスであってよい。
【００２８】
本発明の実施形態にしたがって、消費者は、コンテンツに対するインタレストを生成して、インタレストをネットワーク１８０のノードへ転送し得る。コンテンツは、ネットワーク１８０のノードで、ネットワークの内部または外側に配置され得る発行者またはコンテンツ提供者により、保存され得る。例えば、図１において、コンテンツにおけるインタレストは、ノード１０５で生じる。コンテンツがノードで入手可能でない場合、インタレストは、第１のノードと結合される１つ以上のノードへ進む。例えば、図１において、インタレストは、コンテンツを入手可能でない、ノード１１５へ進む（インタレストフロー１５０）。次に、インタレストは、ノード１１５から、またもコンテンツを有しない、ノード１２５へ向かう（インタレストフロー１５５）。その後、インタレストは、コンテンツを入手可能な、ノード１３０へ向かう（インタレストフロー１６０）。その後、コンテンツオブジェクトのフローは、コンテンツが配信されるノード１０５へ到達するまで、経路を逆に辿る（コンテンツフロー１６５、１７０、および１７５）。認証などの他のプロセスが、コンテンツのフローに関与し得る。
【００２９】
ネットワーク１８０において、コンテンツホルダ（ノード１３０）とインタレスト生成ノード（ノード１０５）との間の経路における、任意の数の中間ノード（ノード１００〜１４５）は、コンテンツがネットワークを辿る際、コンテンツのローカルコピーをキャッシュすることに関与し得る。キャッシュすることにより、他の利用者に近接して配置される第２の利用者に対するネットワーク負荷を、局所的にキャッシュされるコンテンツへのアクセスを黙示的に共有することにより、削減する。
【００３０】
隣接したリンクの状態および異なるマルチキャスト群の受信器の存在を提示する、リンク状態の宣伝（ＬＳＡ）を大量に送信する各ノードに依存した、リンク状態ルーティング手法を含む、ＩＣＮにおけるマルチキャスティングを支援するために、様々な手法が提案されている。さらに、コアベースツリー（ＣＢＴ）が、各マルチキャストソースからの大量送信、または、付属のマルチキャスト群受信器を伴うこれらのルータに関する情報の大量送信を回避する、マルチキャストルーティング手法として、導入されてきた。ＣＢＴにおいて、既定のノードは、マルチキャスト群の中間段階としての役割を果たし、群のコアと称される。ノードは、全てのネットワークノードへのルートを管理し、したがって、全ての潜在的なコアへのルートを管理し、マルチキャスト群のアドレスからコアのアドレスへのマッピングを、ある外部手段により学習する。マルチキャスト群の各受信器は、接合要求を群のコアへ向けて送信し、全ての受信器およびコアをつなぐ共有マルチキャストツリーを確立する。ソースは、データパケットをコアへ向けて単に送信し、データパケットは、マルチキャスト群の全ての受信器へマルチキャストツリーを介して送信される。他の手法であるプロトコル非依存型マルチキャスト（ＰＩＭ）は、ＣＢＴと類似しているが、マルチキャストツリーは単一指向性である。したがって、ソースは、マルチキャストデータを、連絡地点（ＲＰ）と呼ばれる中間ノードへ送信しなければならず、その後、マルチキャストツリー全体にデータを大量に送信する。
【００３１】
他のマルチキャスト手法は、プルベースの手法およびプッシュベースの手法を含む。プルベースの手法は、ＣＣＮおよびネームドデータネットワーキング（ＮＤＮ）など、インタレストベースのＩＣＮアーキテクチャに適用される。インタレストが、要求されたコンテンツを有するサイトに向けられたツリーに沿って統合されることを考慮して、ＮＤＮおよびＣＣＮが、マルチキャスティングのための自然な支援を提供することを、議論してきた。しかしながら、ＣＣＮおよびＮＤＮは、単一ソースのマルチキャスティングのみの効率的な支援を提供可能であり、インタレストは、要求されたマルチキャストソースの名前を提示し、マルチキャスト群ソースの存在がネットワークを介して宣伝されると、推定される。この手法は、膨大なソースを伴うマルチキャスティングの事例に対しては、良好に作用しない。これは、各マルチキャストソースが、ネットワークにおいて既知でなければならず、各ソースに対するツリーが管理される必要があり、拡大縮小がうまくできないからである。
【００３２】
プッシュベースのマルチキャスト手法は、インタレストに基づかない他のＩＣＮアーキテクチャにより、適用されてきた。コンテンツ指向型出版／加入システム（ＣＯＰＳＳ）は、ＰＩＭベースの手法の好適な例である。ＣＯＰＳＳにおいて、ユーザは、任意の法的なコンテンツ名であり得る、コンテンツ記述子（ＣＤ）のコンテンツに対して署名を行ってよく、各ＣＤは連絡地点（ＲＰ）と関連付けられる。ＲＰの数は、ＩＣＮノードの数と同じであってよい。ルータは、ＣＤベースの署名テーブルを管理してＩＰマルチキャストと同じ機能性を提供し、ＣＯＰＳＳはコンテンツ層で少量モードのマルチキャスティングを支援する。ＲＰは、１つ以上の発行者からコンテンツを受信し、マルチキャスト群のルータにより確立されるマルチキャストツリー全体に送信される。しかしながら、そのようなプッシュベースのマルチキャスティングスキームは、特に複数ソースのマルチキャスティングにおいて、非効率であり得る。
【００３３】
本発明の実施形態は、インタレストベースのＩＣＮアーキテクチャにおける複数ソースのマルチキャスティングを支援し得る、ＰＩＭベースの手法より効率的な、情報指向型マルチキャスティングシステム（ＩＣＭ）を提供する。ＩＣＭシステムの動作は、以下であると仮定する：（ａ）各ネットワークノードは、平面または階層構造の名前を割り当てられる；（ｂ）各マルチキャスト群は、独自の名前を用いて要求され得る；（ｃ）マルチキャスト群の名前（ＭＧＮ）は、平面または階層的なネーミング（ＨＳＶＬＩベースのネーミング）を使用して示され、同じネーミング変換がシステム全体で使用される；および、（ｄ）ルーティングプロトコルはネットワークで動作し、ネットワークにおいて宣伝される各マルチキャスト群の最も近いインスタンスへの少なくとも１つのルートを伴う、各ルータを提供する。
【００３４】
ＩＣＭを実施するために、ルータは、リンクコストテーブル（ＬＴｉ）、隣接テーブル（ＮＴｉ）またはトポロジテーブル（ＴＴｉ）、ルーティングテーブル（ＲＴｉ）、および、マルチポイントルーティングテーブル（ＭＲＴｉ）を含む、多数のデータ構造を管理する。リンクコストテーブル、隣接／トポロジテーブル、および、ルーティングテーブルは、ＩＣＮにおいて起動するコンテンツルーティングプロトコルにより提供され、マルチポイントルーティングテーブルは、ＩＣＭにより構築されることに、留意されたい。
【００３５】
ルータｉのリンクコストテーブル（ＬＴｉ）は、ルータｉから隣接ルータの各々へのリンクのコストをリスト化する。この開示において、ルータｉからルータｋへのリンクは（ｉ，ｋ）で示され、リンクのコストは
【００３６】
【数１】
2016123088.tif 000003
【００３７】
で示される。一部の実施形態において、リンクのコストは、管理上の制約およびリンクのルータｉによる性能測定値の関数であり得る、正の数であると推定される。リンク（ｉ，ｋ）に対するリンクコストテーブルのエントリは、隣接ルータｋの名前およびリンク
【００３８】
【数２】
2016123088.tif 000004
【００３９】
のコストを含む。
【００４０】
隣接テーブル（ＮＴｉ）は、ルータｉおよび隣接ルータを包含する、プレフィックスに対するセットＮｉにおける各ルータのルーティング情報を保存する。一部の実施形態において、プレフィックスｊに関してルータｋに対するＮＴｉに保存される情報は、
【００４１】
【数３】
2016123088.tif 000005
【００４２】
と示され、最も近いアンカーおよびプレフィックスのルートアンカーのルーティング情報からなる。
【００４３】
図２は、本発明の実施形態にしたがって、ルータで管理される例示的な隣接テーブルを図示する図を提示する。図２において、ルータｉにより管理される隣接テーブル２００は、隣接ルータの名前およびプレフィックスにより指標化された、多数のエントリを含む。例えば、エントリ２０２は、プレフィックスｊに関してルータｋのための情報を含む。エントリ２０２は、プレフィックスｊ、隣接ルータｋからプレフィックスｊまでの距離
【００４４】
【数４】
2016123088.tif 000006
【００４５】
および、プレフィックスｊのアンカー
【００４６】
【数５】
2016123088.tif 000007
【００４７】
により作成される連番
【００４８】
【数６】
2016123088.tif 000008
【００４９】
を保存する、アンカー
【００５０】
【数７】
2016123088.tif 000009
【００５１】
を提示する３要素の組である、ｋにより報告されるプレフィックスｊの最も近いアンカーのためのルーティング情報を含む。さらに、エントリ２０２は、プレフィックスｊのルートアンカー
【００５２】
【数８】
2016123088.tif 000010
【００５３】
隣接ルータｋからｊのルートアンカーまでの距離
【００５４】
【数９】
2016123088.tif 000011
【００５５】
および、プレフィックスｊの
【００５６】
【数１０】
2016123088.tif 000012
【００５７】
により作成される連番
【００５８】
【数１１】
2016123088.tif 000013
【００５９】
を識別する３要素の組である、プレフィックスｊのルートアンカーのためのルーティング情報を含む。プレフィックスのルートアンカーは、最小の名前または最小の辞書式順序値を伴う、プレフィックスのアンカーである。この開示において、｜ｉ｜は、名前ｉの辞書式順序値を示す。したがって、各ルータｉおよび任意の隣接ルータで、以下が成り立つ：
【００６０】
【数１２】
2016123088.tif 000014
【００６１】
および、
【００６２】
【数１３】
2016123088.tif 000015
【００６３】
ここで、
【００６４】
【数１４】
2016123088.tif 000016
【００６５】
は、プレフィックスｊのルートアンカーである。
【００６６】
プレフィックスｊがルータｉで局所的に入手可能な場合、
【００６７】
【数１５】
2016123088.tif 000017
【００６８】
が成り立つことに、留意されたい。この事例において、ルータｉはプレフィックスｊの最も近いアンカーであるが、プレフィックスｊのルートアンカーではないかもしれない。ルータｉからルートアンカー
【００６９】
【数１６】
2016123088.tif 000018
【００７０】
までの距離は、
【００７１】
【数１７】
2016123088.tif 000019
【００７２】
であり、ここで、ｓ≠ｉは、ルータｉにより選択されたルートアンカー
【００７３】
【数１８】
2016123088.tif 000020
【００７４】
への次ホップである。ルータｉがプレフィックスｊのルートアンカーである場合、
【００７５】
【数１９】
2016123088.tif 000021
【００７６】
である。
【００７７】
一部の実施形態において、隣接テーブル（ＮＴｉ）に含まれる情報は、ネットワークがリンク状態情報に基づいてコンテンツルーティングプロトコルを起動する際、トポロジテーブル（ＴＴｉ）から生じ得る。トポロジテーブル（ＴＴｉ）は、各ルータおよび各既知のプレフィックスの各隣接ルータにより、報告または転送される、リンク状態情報を示す。一部の実施形態において、ＴＴｉに保存される情報は、隣接ルータにより転送されるノードまたはプレフィックスへのリンクと共に、ｉから各隣接ルータおよび各局所的に入手可能なプレフィックスまでのリンクを含む。
【００７８】
ルータｉで管理されるルーティングテーブル（ＲＴｉ）は、ルータｉで既知の各プレフィックスのルーティング情報を保存する。一部の実施形態において、ルーティングテーブルは、プレフィックスにより指標化される複数のエントリを含んでよい。図３は、本開示の実施形態にしたがって、ルータで管理される例示的なルーティングテーブルを図示する図を提示する。図３において、ルータｉにより管理されるルーティングテーブル３００は、複数のエントリを含む。各エントリは、プレフィックスの名前、プレフィックスのためのルーティング更新情報、プレフィックスに対する一連の有効な次ホップ隣接ルータ、プレフィックスへの最短距離を提案する隣接ルータ、および、任意の次ホップ隣接ルータにより報告される、異なる有効な各アンカーのための３要素の組を保存するアンカーリスト、を含む。例えば、エントリ３０２は、プレフィックス（ｊ）、ルーティング更新情報
【００７９】
【数２０】
2016123088.tif 000022
【００８０】
プレフィックスｊに対する一連の有効な次ホップ隣接ルータ
【００８１】
【数２１】
2016123088.tif 000023
【００８２】
プレフィックスｊへの最短経路隣接ルータ
【００８３】
【数２２】
2016123088.tif 000024
【００８４】
および、アンカーセット
【００８５】
【数２３】
2016123088.tif 000025
【００８６】
を含む。ルーティング更新情報
【００８７】
【数２４】
2016123088.tif 000026
【００８８】
は、ルータｉからプレフィックスｊまでの現在の距離
【００８９】
【数２５】
2016123088.tif 000027
【００９０】
ｊへの最短距離を提案するアンカーの中で、最小の名前を有するプレフィックスｊのアンカー
【００９１】
【数２６】
2016123088.tif 000028
【００９２】
および、プレフィックスｊの
【００９３】
【数２７】
2016123088.tif 000029
【００９４】
により作成される連番
【００９５】
【数２８】
2016123088.tif 000030
【００９６】
を示す、３要素の組を含む。アンカーセット
【００９７】
【数２９】
2016123088.tif 000031
【００９８】
は、任意の次ホップ隣接ルータにより報告される、各異なる有効なアンカーの３要素の組
【００９９】
【数３０】
2016123088.tif 000032
【０１００】
を保存する。ここで、ｍはアンカーの名前であり、ｓｎ（ｍ）はアンカーｍにより報告される連番である。
【０１０１】
マルチポイントルーティングテーブル（ＭＲＴｉ）は、プレフィックスにより指標化される複数のエントリを含み、ルータ間でのメッセージ交換により更新される。図４は、本開示の実施形態にしたがって、ルータで管理される例示的なマルチポイントルーティングテーブルを図示する図を提示する。図４において、ルータｉにより管理されるマルチポイントルーティングテーブル４００は、複数のエントリを含む。各エントリは、プレフィックスの名前、プレフィックスのマルチポイント更新情報、および、プレフィックスのＭＩＤＳＴを接合した隣接ルータのリストを含む。例えば、エントリ４０２は、プレフィックス（ｊ）、プレフィックスｊのマルチポイント更新情報
【０１０２】
【数３１】
2016123088.tif 000033
【０１０３】
および、プレフィックスｊのＭＩＤＳＴを接合した一連の隣接ルータ
【０１０４】
【数３２】
2016123088.tif 000034
【０１０５】
を含む。マルチポイント更新情報
【０１０６】
【数３３】
2016123088.tif 000035
【０１０７】
は、プレフィックスｊのルートアンカー
【０１０８】
【数３４】
2016123088.tif 000036
【０１０９】
ルートアンカーへの距離
【０１１０】
【数３５】
2016123088.tif 000037
【０１１１】
および、プレフィックスｊに対する
【０１１２】
【数３６】
2016123088.tif 000038
【０１１３】
により作成される連番
【０１１４】
【数３７】
2016123088.tif 000039
【０１１５】
を示す、３要素の組を含む。
【０１１６】
各ルータは、マルチポイントルーティングテーブルを、隣接ルータから受信した更新メッセージ、および、ルータ間で交換された信号送信メッセージに基づいて更新し、特定のＭＩＤＴＳを接合する。
【０１１７】
一部の実施形態において、ルータｉから隣接ルータｍへ送信された更新メッセージは、ルータｉの名前、メッセージを識別するために使用されるメッセージの連番（ｍｓｎｉ）、および、更新のリストを、更新の必要があるプレフィックスごとに含み得る。ルータｉにより送信されるプレフィックスｊの更新は
【０１１８】
【数３８】
2016123088.tif 000040
【０１１９】
で示され、プレフィックスｊの名前、ｊまでの距離
【０１２０】
【数３９】
2016123088.tif 000041
【０１２１】
アンカー
【０１２２】
【数４０】
2016123088.tif 000042
【０１２３】
および、プレフィックスｊのアンカー
【０１２４】
【数４１】
2016123088.tif 000043
【０１２５】
により作成される連番
【０１２６】
【数４２】
2016123088.tif 000044
【０１２７】
を提示する。一方で、ルータｉによりプレフィックスｊの隣接ルータｋから受信された更新メッセージは、
【０１２８】
【数４３】
2016123088.tif 000045
【０１２９】
で示され、プレフィックスｊの名前、ｊまでの距離
【０１３０】
【数４４】
2016123088.tif 000046
【０１３１】
アンカー
【０１３２】
【数４５】
2016123088.tif 000047
【０１３３】
および、プレフィックスｊのアンカー
【０１３４】
【数４６】
2016123088.tif 000048
【０１３５】
により作成される連番
【０１３６】
【数４７】
2016123088.tif 000049
【０１３７】
を提示する。
【０１３８】
ＩＣＭは、マルチインスタンス化目的地スパニングツリー（ＭＩＤＳＴ）を用いて、マルチキャスト群へのルーティングを支援する。マルチキャスト群に対応する所与のプレフィックスの全てのアンカーは、プレフィックスのルートアンカーに定着した、プレフィックスのＭＩＤＳＴを介して相互に接続される。一部の実施形態において、ＭＩＤＳＴは、ルートアンカーおよび同じ群の他のアンカーの間に配置されるルータによってのみ交換されるルーティング更新を使用して、確立される。
【０１３９】
プレフィックスのＭＩＤＳＴは、分散手法で確立され得る。より具体的には、ルートアンカーであると見なされるアンカーではない、プレフィックスの複数のアンカーに関して既知のルータは、ルートアンカーに関する更新を、好適な経路に沿って、既知の他のアンカーの各々へ送信する。ルートアンカーに関する更新を受信するルータは、自己の更新を、既知の他のアンカーの各々への好適な次ホップへ送信する。このように、ルートアンカーに関する距離更新は、同じプレフィックスの全ての他のアンカーへ伝搬する。ルートアンカーに関する更新は、ルートアンカーと他のアンカーとの間の好適な経路における、それらのルータにのみ伝搬する。ルータｉは、プレフィックスｊのルートアンカーのルーティング情報を変更すると、ルートアンカー通知条件（ＲＮＣ）を満たす各隣接ルータに対するルートアンカーに関する更新の予定を決める。ＲＮＣは、以下の２つの状態が成り立つ場合にのみ、ルータｉが（３つの要素の組
【０１４０】
【数４８】
2016123088.tif 000050
【０１４１】
を含む）マルチポイント更新をルータｋ∈Ｎｉ−｛ｉ｝へ送信することを提示する：
【０１４２】
【数４９】
2016123088.tif 000051
【０１４３】
｜ｉ｜は名前ｉの辞書式順序値を示すことに、留意されたい。
【０１４４】
状態（１）は、ルータｋが、アンカーまたはルートアンカーとして、ルータｉに見なされている同じルートアンカーを報告していないことを示す。状態（２）は、ルータｉがアンカーであって、全ての隣接ルータがｉを選択されたアンカーとして報告する場合、または、ｋが、ルートアンカーでないアンカーへの辞書式順序で最小の次ホップである場合、ルータｉがルータｋに対するルートアンカーに関する更新を転送することを示す。
【０１４５】
図５は、本発明の実施形態にしたがって、ＩＣＭを実装するルータの例示的なアーキテクチャを提示する図を提示する。図５において、ＩＣＭルータ５００は、隣接テーブルモジュール５０２、ルーティングテーブルモジュール５０４、マルチポイントルーティングテーブルモジュール５０６、更新受信モジュール５０８、隣接ルータ選択モジュール５１０、転送モジュール５１２、要求生成モジュール５１４、および、応答受信／処理モジュール５１６を含む。
【０１４６】
隣接テーブルモジュール５０２は、隣接テーブルを管理および更新する役割を有する。ルーティングテーブルモジュール５０４は、ルーティングテーブルを管理および更新する役割を有する。先に説明したように、隣接テーブルおよびルーティングテーブルに含まれる情報、および、これら２つのテーブルの更新は、ネットワークで起動するコンテンツルーティングプロトコルにより処理される。この開示の範囲は、使用される特定のコンテンツルーティングプロトコルにより限定されない。一部の実施形態において、距離ベースのコンテンツルーティング（ＤＣＲ）プロトコルが、ＩＣＮにおけるコンテンツルーティングに使用される。
【０１４７】
マルチポイントルーティングテーブルモジュール５０６は、マルチポイントルーティングテーブルを管理および更新する役割を有する。一部の実施形態において、ルータは、マルチポイントルーティングテーブルのエントリを、プレフィックスのアンカーおよび／またはルートアンカーに関する更新メッセージ、および、ルータ間で交換される「接合」メッセージに基づいて、更新する。
【０１４８】
更新受信モジュール５０８は、ルートアンカー更新を受信する役割を有する。受信された更新は、ルートアンカーに関連する情報を含む、マルチポイントルーティングテーブルを更新するマルチポイントルーティングテーブルモジュール５０６を、結果としてもたらし得る。隣接ルータ選択モジュール５１０は、ルートアンカー更新を転送する隣接ルータを選択する役割を有し、転送モジュール５１２は、ルートアンカー更新を転送する役割を有する。一部の実施形態において、転送モジュール５１２は、さらに、ルートアンカーに関連する局所的に発生する更新を転送する役割を有する。隣接ルータ選択モジュール５１０は、ルータに保存された情報（リンクコストテーブル、隣接テーブル、および、マルチポイントルーティングテーブルなど）に基づいて、特定のプレフィックスのルートアンカー更新を転送する１つ以上のルータを選択する。一部の実施形態において、隣接ルータ選択モジュール５１０は、ＲＮＣ条件を満たす一連の隣接ルータを選択し、転送モジュール５１２は、ルートアンカー更新を選択された隣接ルータへ転送する。ネットワークにマルチキャスティングのための信号送信パケットを大量に送る他の手法と比較して、本発明の実施形態において、更新は、ネットワークにおけるルータのサブセット間で交換されるだけであることに、留意されたい。実際、更新は、同じマルチキャスト群におけるアンカーであるルータへ、または、ルートアンカーと他のアンカーとの間に配置される中継ルータへ、送信されるだけである。
【０１４９】
要求生成モジュール５１４は、「接合」要求を生成する役割を有する。より具体的には、ルータがマルチキャスト群を、ソースまたは受信器として接合したい場合、要求生成モジュール５１４は「接合」要求を生成する。一部の実施形態において、「接合」要求は、マルチキャスト群の名前およびルートアンカーの名前を含む。そのような「接合」要求の生成において、隣接ルータ選択モジュール５１０は、プレフィックスのルートアンカーに対するルータの次ホップ隣接ルータの中から、最小の辞書式順序値を有する隣接ルータを選択する。一部の実施形態において、ルータは、隣接ルータを、ルートアンカーに対する次ホップ隣接ルータとして、隣接ルータがルートアンカー順序条件（ＲＯＣ）を満たすか否かに基づいて、選択する。より具体的には、ＲＯＣは、以下の３つの状態が成り立つ場合にのみ、ルータｉが隣接ルータｋ∈Ｎｉを、プレフィックスｊの次ホップ隣接ルータとして選択し得ることを示す。
【０１５０】
【数５０】
2016123088.tif 000052
【０１５１】
状態（３）は、隣接ルータｋにより報告されるルートアンカーが、ルータｉにより既知のプレフィックスｊの全てのアンカーの中の最小の名前（最小の辞書式順序値）を有することを示すことに、留意されたい。状態（４）は、隣接ルータｋが、全ての隣接ルータの中でルートアンカーへの最短距離を提案しなければならないことを示す。さらに、状態（５）は、ルートアンカーに対する選択された次ホップを伴うルータｉを、ルートアンカーまでの距離およびルートアンカーにより作成される連番に基づいて、順序付ける。より具体的には、状態（５）は、選択された次ホップｋが、ｉの連番より大きい、ルートアンカーにより作成された連番を報告しなければならないか、または、より短いルートアンカーへの距離を提供しなければならないことを示す。
【０１５２】
そのような「接合」要求を受信すると、ルータは、そのような要求を、ＲＯＣにしたがって、ルートアンカーに対する辞書式順序で最小の次ホップへ転送する。この手法において、「接合」要求は、プレフィックスのルートアンカーへ向かう経路を、ルータアンカーまたは既にマルチキャスト群のＭＩＤＳＴの一部であるルータｘに到達するまで辿る。一部の実施形態において、「接合」要求を受信および転送する各ルータは、有限の期間中、要求に対するエントリを保存する。さらなる実施形態において、要求に対するエントリは、ＣＣＮにおける保留インタレストテーブルと類似のデータ構造で管理される。そのようなエントリは「接合」要求の受信元である隣接ルータを示し、したがって、「接合」要求への応答は「接合」要求の逆経路を辿ることができる。応答受信／処理モジュール５１６は、「接合」要求への応答を受信および処理する役割を有する。そのような応答が処理されると、ルータは、プレフィックスのＭＩＤＳＴの一部となる。確認できるように、ルータは、「接合」要求を、ＲＯＣを満たす隣接ルータへ転送するだけであるので、マルチキャスト群のＭＩＤＳＴを確立することに対して必要な信号送信に使用される、ルータおよびリンクの数が、大幅に少なくなる。より具体的には、ルートアンカーへの好適な経路の一部であるリンクではない、プレフィックスのルートアンカーと別のアンカーとの間の最短経路に沿うルータのみが、「接合」要求の伝搬に関与してよい。そのようなプロセスは、全てのルータが所定のルートアンカーへのルートを有さなければならない、建物共有マルチキャストツリーまたはマルチキャストツリーに基づく連絡地点（ＲＰ）の従来の手法より、効率的である。
【０１５３】
図６は、本発明の実施形態にしたがって、例示的なＩＣＮにおけるルートアンカー更新の伝搬を図示する。図６において、ネットワーク６００は、各々が名前により識別される、ルータａ、ｃ、ｒ、…、ｘ、およびｙなど、１２個のルータを含む。図６に示される例において、４つのルータ（図において影になっている、ルータｃ、ｄ、ｕ、およびｏ）は、特定のマルチキャスト群ｍｇのアンカーの役割を果たす。これらのルータは、ｍｇのマルチキャスティング様式に応じて、ｍｇの付属ソースまたは付属受信器を有するため、ｍｇのアンカーである。４つのアンカーの中で、アンカーｃは最小の辞書式順序値を有しており、ルートアンカーである。図６において、各リンクは単価を有すると推定されることに、留意されたい。
【０１５４】
図６において、１つ以上の３要素の組は、各ルータの次の辞書式順序にリストされており、各々の３要素の組は、ｍｇのアンカーへの距離およびアンカーの識別子を示す。リストにおける第１の３要素の組は、ｍｇへの最小距離および同じ距離の全てのアンカーの中の最小の名前を伴うアンカーを示す。例えば、３つの３要素の組は、ルータｐの次にリストされ、ルータｐからアンカーｏへの距離が１（１つのホップ）であり、アンカーｕへの距離が１（１つのホップ）であり、アンカーｄへの距離が２（２つのホップ）であることを示す。言い換えると、ルータｐからプレフィックスのアンカーへの最小距離は１であり、そのような最小距離は、アンカーｏへの距離である。ルータｐからアンカーｏおよびｕへの距離は、どちらも１であるが、ｕより小さい辞書式順序値を有するため、アンカーｏは好適なアンカーとしてリスト表示される。ルータｈの次にリスト表示される２つの３要素の組があり、ルータｈからアンカーｃへの距離は、２（２つのホップ）であり、アンカーｕへの距離は２（２つのホップ）であることを示す。同様に、アンカーｃはルータｕより小さい辞書式順序値を有するため、たとえ距離が同じであっても、アンカーｃは第１の３要素の組にリスト表示され、アンカーｃがルータｈに対する好適なアンカーであることを示す。
【０１５５】
図６において、矢印は、情報転送ベース（ＦＩＢ）のエントリにしたがって、２つのルータ間のインタフェースの方向を示す。例えば、ルータｐからルータｕへと指し示す矢印は、ルータｐにより管理されるＦＩＢにおいて、ルータｕが名前プレフィックスｍｇを伴うインタレストの送信フェイスであることを示す。一方で、ルータｕにより管理されるＦＩＢにおいて、ルータｐは、名前プレフィックスｍｇを伴うインタレストの受信フェイスである。図示の目的で、図６は、特定のアンカーおよび同じ色を有する特定のアンカーに対する好適な次ホップで、符号化された色である。言い換えると、アンカーの色付き矢印は、対応するリンクが、アンカーの好適な次ホップ（すなわち、辞書式順序で最小である次ホップ）であることを示す。例えば、リンク（ｗ，ｂ）は青であり、ルータｂは、ルータｗのアンカーｃ（これも青）に対する好適な次ホップであることを示し、リンク（ｍ，ｒ）は緑であり、ルータｒは、ルータｍのアンカーｄ（これも緑）に対する好適な次ホップであることを示す。黒の矢印は、アンカーに対する好適でない次ホップを示す。例えば、リンク（ｍ，ｉ）は黒であり、ルータｉがアンカーｏに対する次ホップであるが、ｏは大きな辞書式順序値を有するので、このリンクは好適なリンクでないことを示す。
【０１５６】
図６において、ルートアンカー（ルータｃ）は青であり、破線の矢尻および青の矢尻は、ｍｇのルートアンカーであるｃに関する更新がｃから離れる方向に伝搬する際に経由する、これらのリンクを示す。更新の伝搬は、ＲＮＣを順守するために必要であることに、留意されたい。例えば、ルータｂは、隣接ルータがアンカーｏへ向かうｂに対する最良な選択であるため、ルートアンカー更新をｅに伝搬する。ルータｇは、アンカーｕに対する最良の選択であるため、ルートアンカー更新をｕに伝搬する。ルータｏは、ｏを好適なアンカーとして報告する全ての隣接ルータを伴うアンカーであるため、ｍｇのルートアンカーであるｃを示す更新を、全ての隣接ルータへ伝搬する。これらはＲＮＣの状態（２）により特定されることに、留意されたい。確認できるように、ＲＮＣであるため、プレフィックスのルートアンカーに関する更新は、プレフィックスの全ての他のアンカーへ到達し得る。しかしながら、図６で確認できるように、一部のルータ（青または破線の矢印と接続されない、ルータｒおよびｍなど）は、ルートアンカーｃに関する更新の伝搬に関与する必要はなく、ｃを伴うｍｇに関する更新をアンカーとして受信しない場合がある。これは、更新がネットワーク全体に大量に送信されなければならない従来の手法と比較して、利点である。
【０１５７】
図７は、本発明の実施形態にしたがって、例示的なＩＣＮにおけるマルチインスタンス化目的地スパニングツリー（ＭＩＤＳＴ）の確立を図示する。図７に示されるネットワークは、図６に示されるネットワーク６００と同じであり、各々がルータａ、ｃ、ｒ、…、およびｙなどの名前により識別される、２０個のルータを含む。先に説明されたように、アンカーｕなどのアンカーが、ルートアンカーがｃであるマルチキャスト群ｍｇを接合したい場合、「接合」要求を、ｃに対する辞書式順序で最小の次ホップへ送信する必要がある。図７に示されるように、ルータｕは、「接合」要求を、要求をルートアンカーｃへルータｅおよびｂを介して転送する、ルータｇへ送信し得る。同様に、他のアンカー（ｄおよびｏ）は、さらに、「接合」要求をルートアンカーｃへ向かって、ｍｇのＭＩＤＳＴを接合するために送信する。例えば、ルータｏは、「接合」要求をｃへ向かって送信してよく、そのような要求が、既にＭＩＤＳＴにあるｕに到達すると、応答がｏへ返送され、「接合」要求の逆経路を辿る。経路上のルータは、ＭＩＤＳＴの一部になる。図７において、プレフィックスｍｇのＭＩＤＳＴを構築するリンクは、オレンジの実線により示され、プレフィックスｍｇのマルチポイントデータトラフィックは、これらのリンクの両方向に進み得る。
【０１５８】
マルチキャスト群に適用されるマルチキャスト様式（ＳＩＭまたはＲＩＭ）に応じて、ＭＩＤＳＴは、ＩＣＭの実装において異なって使用されてよい。
【０１５９】
ソース始動型マルチキャスト（ＳＩＭ）において、マルチキャスト群のソースは、ネットワークにおける存在を宣伝し、受信器はソースの群への接合を試みる。マルチキャスト群のアンカーは、群のソースである。マルチキャスト群の各ソースは、存在を付属のルータへ、インタレストベースの信号送信またはプッシュベースの信号送信を使用して実施され得るマルチキャスト群管理プロトコル（ＭＧＭＰ）を使用して、使用されるＩＣＮアーキテクチャに応じて、宣伝する。マルチキャストソースから付属ルータへ送信されたＭＧＭＰメッセージは、マルチキャスト群の名前、群のソースとして作用する要求者を伴ってＳＩＭを実行する要求、および、選択的な属性を示す。一部の実施形態において、属性は、ソースが作動を維持する時間の長さをルータへ知らせる、削除タイマーを含んでよい。マルチキャスト群の名前は、マルチキャスト群がＳＩＭ様式で動作することを示す。マルチキャスト群のソースが付属ルータに群の存在を名前により宣伝させることを考えると、マルチキャストソースに付属するルータは、マルチキャスト群のアンカーである。
【０１６０】
ルータは、ＤＣＲなどのコンテンツルーティングプロトコルを使用して、ルーティングをマルチキャスト群の最も近いソースへ提供し、ＩＣＭはマルチキャスト群のＭＩＤＳＴを構築および管理する。結果として得られるＭＩＤＳＴは、マルチキャスト群の全てのソースを接続する。コンテンツを群の全てのマルチキャストソースから受信するために、受信器は、インタレストを、マルチキャスト群の名前を示す付属ルータへ単に送信する。同様に、ルータは、インタレストを、マルチキャスト群の最も近い既知のアンカーへ向けて送信する。マルチキャスト群からのコンテンツは、インタレストが辿る逆経路を通って配信される。マルチキャスト群のソースに付属するルータは、コンテンツを、マルチキャスト群のために作成されたＭＩＤＳＴの一部である各隣接ルータと同様に、群のインタレストを提示した各隣接ルータへ転送する。結果として、受信器は、コンテンツを、インタレストを示したマルチキャスト群の全てのソースから取得できる。ＩＣＭのＳＩＭ様式は、ＮＤＮおよびＣＣＮで利用可能な単一ソースのマルチキャスト支援の単なる拡張を実施するために、使用され得る。各マルチキャストソースのインタレストを送信しなければならない各受信器の代わりに、受信器は、コンテンツを要求するインタレストを、そのようなインタレストの名前により示されるマルチキャスト群の全てのソースから単に送信する。マルチキャストコンテンツのインタレストを提示するよう受信器に要求することは、プッシュベースの手法ほど効率的ではないことに、留意されたい。ＩＣＭは、複数のデータオブジェクトを生じさせる長期のインタレストを規定することにより、ＣＣＮおよびＮＤＮにおいて、より効率的に使用され得る。
【０１６１】
受信器始動型マルチキャスト（ＲＩＭ）において、マルチキャスト群の受信器は、ネットワークにおける存在を宣伝し、ソースはコンテンツを群の最も近い受信器へ向けて送信する。ＲＩＭにおけるマルチキャスト群のアンカーは、群の受信器である。マルチキャスト群の各受信器は、存在を付属ルータへ、マルチキャスト群管理プロトコル（ＭＧＭＰ）を使用して宣伝する。マルチキャスト受信器から付属ルータへ送信されたＭＧＭＰメッセージは、マルチキャスト群の名前、群の受信器として作用する要求者を伴ってＲＩＭ様式を実行する要求、および、選択的な属性を示す。一部の実施形態において、属性は、ソースが作用し続ける時間の長さをルータへ知らせる、削除タイマーを含んでよい。マルチキャスト群の名前は、マルチキャスト群がＲＩＭ様式を使用して動作することを示す。マルチキャスト受信器に付属するルータは、マルチキャスト群のアンカーである。ルータは、ＤＣＲなどのコンテンツルーティングプロトコルを使用して、ルーティングをマルチキャスト群の最も近いソースへ提供し、ＩＣＭはマルチキャスト群のＭＩＤＳＴを、ルーティングプロトコルにより提供される最も近いインスタンスルーティング情報を使用して、構築および管理する。結果的に得られるＭＩＤＳＴは、マルチキャスト群の全ての受信器を接続する。コンテンツを群のマルチキャスト受信器へ送信するために、ソースは、コンテンツを、同様にコンテンツを最も近いインスタンスルーティング情報に基づいて群の最も近いアンカーへ送信する、付属ルータへ単に送信する。コンテンツを受信するマルチキャスト群のＭＩＤＳＴにおける群またはルータの第１のアンカーは、コンテンツを、ＭＩＤＳＴを介して広める。結果として、マルチキャスト群の全ての受信器は、コンテンツを任意の１つのソースから取得する。
【０１６２】
図８は、本発明の実施形態にしたがって、情報指向型マルチキャスティングのための例示的なシステムを図示する。情報指向型マルチキャスティングのためのシステム８００は、プロセッサ８１０、メモリ８２０、および、ストレージ８３０を備える。ストレージ８３０は、典型的には、メモリ８２０内へロードされ、上述された方法を行うためにプロセッサ８１０により実行され得る、命令を保存する。１つの実施形態において、ストレージ８３０の命令は、隣接テーブルモジュール８３２、ルーティングテーブルモジュール８３４、マルチポイントルーティングテーブルモジュール８３６、更新受信モジュール８３８、隣接ルータ選択モジュール８４０、転送モジュール８４２、要求生成モジュール８４４、および、応答受信／処理モジュール８４６を実装でき、全てのモジュールは、様々な手段を介して相互に通信し得る。
【０１６３】
一部の実施形態において、モジュール８３２〜８４６は、部分的または全体的に、ハードウェアに実装されることができ、プロセッサ８１０の一部であり得る。さらに、一部の実施形態において、システムは、別個のプロセッサおよびメモリを含まなくてよい。代わりに、特定のタスクを行うことに加えて、モジュール８３２〜８４６は、別個または同時に、汎用または特定用途の計算エンジンの一部であってよい。
【０１６４】
ストレージ８３０は、プロセッサ８１０により実行されるプログラムを保存する。具体的には、ストレージ８３０は、情報指向型マルチキャスティングのためのシステム（アプリケーション）を実装するプログラムを保存する。動作中、アプリケーションプログラムは、ストレージ８３０からメモリ８２０内へロードされ、プロセッサ８１０により実行され得る。結果として、システム８００は、上述した機能を行い得る。システム８００は、選択的なディスプレイ８８０（タッチスクリーンディスプレイであり得る）、キーボード８６０、および、ポインティングデバイス８７０と結合されることができ、さらに、１つ以上のネットワークインタフェースを介してネットワーク８８２と結合され得る。
【０１６５】
この詳細な説明に記載されるデータ構造およびコードは、典型的には、コンピュータシステムにより使用されるコードおよび／またはデータを保存し得る、任意のデバイスまたは媒体であってよい、コンピュータ可読保存媒体に保存される。コンピュータ可読保存媒体は、揮発性メモリ、不揮発性メモリ、ディスクドライブ、磁気テープ、ＣＤ（コンパクトディスク）、ＤＶＤ（デジタル多用途ディスクまたはデジタルビデオディスク）など、磁気および光保存デバイス、または、既知であるか、または、今後に開発される、コンピュータ可読媒体を保存可能な他の媒体を含むが、それらに限定されない。
【０１６６】
詳細な説明の項に記載される方法およびプロセスは、上述されたように、コンピュータ可読保存媒体に保存され得る、コードおよび／またはデータとして具現化され得る。コンピュータシステムが、コンピュータ可読保存媒体に保存されたコードおよび／またはデータを読み込んで実行する場合、コンピュータシステムは、データ構造およびコードとして具現化され、コンピュータ可読保存媒体内に保存される、方法およびプロセスを行う。
【０１６７】
さらに、本明細書に記載される方法およびプロセスは、ハードウェアモジュールまたは装置に含まれ得る。これらのモジュールまたは装置は、特定用途向け集積回路（ＡＳＩＣ）チップ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定のソフトウェアモジュールまたはコードを特定の時間に実行する、専用または共有プロセッサ、および／または、既知であるか、または、今後に開発される、他のプログラマブル論理デバイスを含んでよいが、それらに限定されない。ハードウェアモジュールまたは装置が起動されると、含まれる方法およびプロセスを行う。
【図１】
2016123088.tif 000053
【図２】
2016123088.tif 000054
【図３】
2016123088.tif 000055
【図４】
2016123088.tif 000056
【図５】
2016123088.tif 000057
【図６】
2016123088.tif 000058
【図７】
2016123088.tif 000059
【図８】
2016123088.tif 000060