JP6564937B2

JP6564937B2 - コンテンツ指向ネットワーキング（ｃｃｎ）ネットワークにおいてデータをプッシュするための方法および装置

Info

Publication number: JP6564937B2
Application number: JP2018507518A
Authority: JP
Inventors: ラヴィシャンカール・ラヴィンドラン; グオ・チャン・ワン
Original assignee: ホアウェイ・テクノロジーズ・カンパニー・リミテッド
Priority date: 2015-08-14
Filing date: 2016-08-11
Publication date: 2019-08-21
Anticipated expiration: 2036-08-11
Also published as: WO2017028734A1; EP3320670A1; US20170048346A1; EP3320670B1; CN107925674B; JP2018525927A; EP3320670A4; US10757213B2; CN107925674A

Description

相互参照
本出願は、2015年8月14日に出願した、「METHOD AND APPARATUS FOR PUSHING DATA IN A CONTENT-CENTRIC NETWORKING (CCN) NETWORK」と題した米国非仮特許出願第14/826,785号の優先権を主張するものであり、この米国非仮特許出願は、その全体が再現されているかのように参照により本明細書に組み込まれる。

本開示は、概して、情報指向ネットワーキング(information centric networking)に関し、より詳細には、コンテンツ指向ネットワーキング(CCN)ネットワークにおいてデータをプッシュするための方法および装置に関する。

先進的な低コストのワイヤレステクノロジーが、過去数年間、極めて多様な現実の応用を可能にしてきた。ワイヤレスセンサーテクノロジーが、想像し得るほぼすべての応用分野で台頭してきた。インターネット接続性を備えたスマートフォンおよびネットワーキング能力を有する家庭用電子機器が、日常生活に浸透してきた。モノのインターネット(IoT)は、すべての可能なデバイスが寄与する可能性がある大規模な感知エコシステム(sensing ecosystem)の概念を形作るために勃興してきた新規のパラダイムである。この文脈におけるモノの定義は、非常に曖昧である。モノの定義は、小売りの包装上のRFIDタグから周りの環境を観測するインテリジェントなトランスデューサまであらゆるものである可能性がある。そのような世界規模の感知ネットワーク内の接続されるデバイスの量は、膨大である。これは、ここ数十年のものであり、ホスト同士の接続性に基づく現在のインターネットアーキテクチャにとって根本的課題となっている。

現在のインターネットは、ロケーションによってコンテンツをアドレス指定する。それは、ポイントツーポイント接続に基づいており、そのことは、結局のところ、すべての接続されるデバイスがホスト名またはIPアドレスによって一意にアドレス指定可能でなければならないことを意味する。このパラダイムは、元々、データではなくリソースを共有するために設計された。今日、インターネット使用の大部分は、データを共有することから成り立っており、それは、そのパラダイムが元々設計の対象としていたものではない。様々な不完全な改善策が現れては消えていったが、完全なアーキテクチャの再設計が必要とされる。情報指向ネットワーキング(ICN)は、ロケーションの代わりに名前によってコンテンツをアドレス指定する新しいネットワーキングパラダイムである。インターネット上のほとんどのコンテンツのロケーションがエンドユーザと無関係であるので、その新しいネットワーキングパラダイムの目的は、ロケーションの体系による現在のコンテンツを置き換えることである。いくつかのICNアーキテクチャの提案が研究団体から登場したが、その中でも、コンテンツ指向ネットワーキング(CCN)は最も重要である。しかし、CCNは、データのプルに基づくアーキテクチャであり、典型的なIoTのデータプッシュの用途の助けにはならない。

以上のことから、CCNプロトコルを使用してIoTアプリケーションを実装する必要が生じたことは、当業者に理解され得る。本開示によれば、現在のパケットプリミティブ(primitive)とは異なるように処理される、関心-通知(interest-notification)と呼ばれる新しい種類のCCNメッセージプリミティブが、提案され、通常の情報指向ネットワーキング技術に関連する問題を大きく和らげ、実質的になくす、コンテンツ指向ネットワーキング(CCN)ネットワークにおいてデータをプッシュするための方法および装置が、提供される。

一実施形態によれば、CCNネットワーク内のノードデバイスの入力インターフェースデバイスにおいてソースからメッセージを受信するステップであって、ノードデバイスが、CCNプロトコルを実行する、ステップを含むコンテンツ指向ネットワーキング(CCN)ネットワークにおいてデータをプッシュするための方法が、提供される。受信されたメッセージが関心-通知メッセージであるという判定がなされる。受信されたメッセージは、Typeフィールド、Content Nameフィールド、およびCacheable Objectフィールドを含むことによって関心-通知メッセージとして特定される。Typeフィールドは、受信されたメッセージがCCNネットワーク内にデータをプッシュしていることを示す。Content Nameフィールドは、階層的な名前をCCNネットワーク内にプッシュされているデータに関連付ける。Cacheable Objectフィールドは、CCNネットワーク内にプッシュされているデータを表すキャッシュ可能なオブジェクト(cacheable object)を含む。受信されたメッセージが関心-通知メッセージであることに応じて、キャッシュ可能なオブジェクトが抽出される。キャッシュ可能なオブジェクトは、ノードデバイスのキャッシュに入れられる。

別の実施形態によれば、コンテンツ指向ネットワーキング(CCN)ネットワークにおいてデータをプッシュするためのエンティティが、提供される。エンティティは、CCNネットワーク内のノードデバイスの入力インターフェースデバイスにおいてソースからメッセージを受信するための受信要素であって、ノードデバイスが、CCNプロトコルを実行する、受信要素と、受信されたメッセージが関心-通知メッセージであると判定するための判定要素と、受信されたメッセージが関心-通知メッセージであることに応じて、キャッシュ可能なオブジェクトを抽出するための抽出要素とを含み得る。受信されたメッセージは、Typeフィールド、Content Nameフィールド、およびCacheable Objectフィールドを含むことによって関心-通知メッセージとして特定され得る。Typeフィールドは、受信されたメッセージがCCNネットワーク内にデータをプッシュしていることを示す。Content Nameフィールドは、階層的な名前をCCNネットワーク内にプッシュされているデータに関連付ける。Cacheable Objectフィールドは、CCNネットワーク内にプッシュされているデータを表すキャッシュ可能なオブジェクトを含む。キャッシュ可能なオブジェクトは、ノードデバイスのキャッシュに入れられる。

本開示は、通常の情報指向ネットワーキング技術に勝る多くの技術的利点を説明する。たとえば、1つの技術的利点は、ネットワークにおいてデータをプッシュするためにCCNプロトコルを使用することである。別の技術的利点は、ネットワークにおいてデータをプッシュするためのCCNメッセージフォーマットを確立することである。その他の技術的利点は、下の図、説明、および請求項から当業者に容易にわかり、当業者によって認識され得るであろう。

本発明およびその利点のより完全な理解のために、ここで、同様の参照番号が同様の部分を表す添付の図面と併せて考慮される以下の説明に対する参照がなされる。

コンテンツ指向ネットワーキング(CCN)プロトコルを実装するネットワーク図である。 CCNノードデバイスの簡略化されたブロック図である。 CCNノードデバイスにおいてInterestメッセージを処理するためのプロセスフローを示す図である。 CCNノードデバイスにおいてContent Objectメッセージを処理するためのプロセスフローを示す図である。 Interestメッセージに関する例示的なフォーマットを示す図である。キャッシュ可能なオブジェクトを含む特別な種類のInterest Messageに関する例示的なフォーマットを示す図である。キャッシュ可能なオブジェクトを含む特別な種類のInterest Messageに関する例示的なフォーマットを示す図である。キャッシュ可能なオブジェクトを含む特別な種類のInterest Messageに関する例示的なフォーマットを示す図である。 Interest Notificationメッセージの例示的なフォーマットを示す図である。 CCNノードデバイスにおいてInterestメッセージ、Interest Notificationメッセージ、およびContent Objectメッセージのうちのいずれかを処理するためのプロセスフローを示す図である。メッセージフローを示すネットワーク図である。障害発生中のメッセージフローを示すネットワーク図である。ネットワークを通じてデータを転送し、処理する任意のデバイスである可能性があるネットワークデバイスの図である。ネットワークデバイス内のネットワーク構成要素の図である。

以降で検討される図1から図12と、この特許文書において本発明の原理を説明するために使用される様々な実施形態とは、ただの例示に過ぎず、本発明の範囲をいかなる形でも限定すると考えられるべきでない。当業者は、本発明の原理が任意の種類の好適に構成されたデバイスまたはシステムに実装され得ることを理解するであろう。1つの図に示され、検討される特徴は、1つまたは複数のその他の図において適宜実装される可能性がある。

図1は、CCNの概念を実装するネットワーク100の簡略化された図を示す。ネットワーク100は、CCNノードデバイス102を含む。ネットワーク100は、センサー104、インターネット110アクセスのあるクライアント106、IoTサーバ108、シンク要素112、およびCCNノードデバイス102の機能を含む少なくとも1つのアプリケーションサーバ114などのその他のエンティティおよびデバイスも含む可能性がある。CCNノードデバイス102に関するその他の例は、アクセスポイント、ゲートウェイ、コンテンツルータ、エッジ/サービス/コアルータ、ドメインコントローラ(AS)140、および1つまたは複数のコンテンツリポジトリを含む。各エンティティは、データをキャッシュする能力も含む可能性がある。ネットワーク100は、CCNプロトコルを使用して通信するその他の構成要素を含む可能性があり、これらの構成要素は、データを提供し、要求する能力を有する様々なアプリケーションを実行し得る。CCNノードデバイス102は、フォワーディングおよびバッファリングを実施するネットワークエンティティである。CCNノードデバイス102は、関与するマシンの識別情報またはロケーションとは無関係に名前付きデータ上に構築されたトランスポートプロトコルを使用する。CCNは、その最も低いレベルにホストの概念を持たない。パケット「アドレス」は、コンテンツ、デバイス、またはサービスの名前を指定するが、ロケーションの名前を指定しない。CCNプロトコルは、ホストをその他のホストに接続するのではなく名前付きコンテンツを効率的に配信する。データのあらゆるパケットは、いずれかのCCNノードデバイス102においてキャッシュされる可能性がある。マルチキャストまたはブロードキャスト配信の本質的に備わっているサポートと相まって、これは、多くの人が同じコンテンツに関心があるときに、ネットワークの非常に効率的な使用につながる。

CCNプロトコルは、名前付きデータパケットに関するロケーションに依存しない配信サービスを提供する。サービスは、エンドツーエンド配信のためのマルチホップフォワーディング、フロー制御、ネットワーク内で利用可能なバッファストレージを使用する透過的な自動マルチキャスト配信、ループのないマルチパスフォワーディング、配信パスに無関係なコンテンツの完全性の検証、および任意のアプリケーションデータの運搬を含む。アプリケーションは、パケットを送信することができる何らかのより低いレイヤの通信サービス上でCCNプロトコルを実行する。より低いレイヤのサービスの性質に対していかなる制約もなく、つまり、より低いレイヤのサービスは、物理トランスポートまたは別のネットワークもしくはトランスポートプロトコルである可能性がある。たとえば、アプリケーションは、通常、既存のIP接続性を活かすためにUDPの上でCCNプロトコルを実行する。CCNプロトコルにおいてコンテンツはロケーションと無関係に命名されるので、そのコンテンツは、ネットワーク内で無期限に維持される可能性もあり、事実上、分散型ファイルシステムサービスの形態を提供する。

CCNプロトコルは、広範なネットワークアプリケーションをサポートする。CCNモデルは、ビデオまたはドキュメントファイルの配信などの記憶されたコンテンツのアプリケーションをサポートする。CCNモデルは、リアルタイム通信および発見プロトコルもサポートし、TCP接続などのホスト間でやりとり(conversation)を運ぶことができる。プロトコルは、ネーミング規約の選択をアプリケーションに任せることによって幅広い範囲のアプリケーションをサポートする。CCNプロトコルは、アプリケーション間のエンドツーエンド通信のために設計されており、したがって、別個のレイヤとして実装されるよりもアプリケーションの処理に統合されるように意図されている。

CCNプロトコルは、コンテンツを直接アドレス指定可能およびルーティング可能にすることによってそのコンテンツを重視する。エンドポイントは、IPアドレスの代わりに名前付きデータに基づいて通信する。CCNは、(「Interest」と呼ばれる)コンテンツ要求メッセージおよび(「Content Object」と呼ばれる)コンテンツ返送メッセージの基礎的な交換によって特徴付けられる。Interestメッセージは、名前によってデータを要求するために使用される。Interestメッセージは、取り出すコンテンツのチャンクを極めてはっきりと特定することができる。代替的に、Interestメッセージは、どのデータが接頭辞によって名前を指定された集合から受け付けられ得るかを制限するために接頭辞およびその他の資格を与える可能性がある。

CCNの名前は、データの特定のチャンクを特定することがあるが、複数のデータが下に存在する可能性がある名前ツリー内の点の名前を指定することによってデータの集合を特定する場合もある。データの集合を特定する名前は、ネットワークアドレスがそのネットワークにアタッチされたホストの集合を特定すると理解され得るIPのホストアドレス指定方式におけるネットワークのアドレスに類似している。集合の名前を指定する場合、CCNの名前は、ちょうどIPv4ネットワークアドレスがメンバーのホストのIPアドレスの接頭辞を与えるように、集合内のあらゆるコンテンツの名前の接頭辞である。この理由で、CCNの名前は、名前の接頭辞または単に接頭辞と呼ばれる可能性がある。

Content Objectは、データを供給するために使用される。Content Objectメッセージは、データのペイロードのみでなく、(暗黙的なダイジェスト構成要素を伴わない)特定する名前、暗号署名、および(パブリッシャと呼ばれる)署名者の識別情報も、署名についてのその他の情報と一緒に含む。形式上、Content Objectメッセージは、名前、パブリッシャ、およびデータのチャンクの変えることのできない結束である。あらゆるContent Objectメッセージは、有効な署名を含むことを求められる。このようにして、CCNプロトコルによって伝達されるすべてのデータは、正当性を証明される。

どのCCNの関与者(party)も、そのCCNの関与者が受信する任意のContent Objectメッセージに対する署名を検証することを選択し得る。データを利用しようとしているアプリケーションは、まず、データを検証しなければならない。検証は、検証されるContent Objectメッセージに含まれていない公開鍵を必要とする可能性がある。CCNの関与者は、検証に失敗するContent Objectメッセージを破棄する。

CCNプロトコルを使用する通信は、受信者によって制御される。データの消費者は、利用可能な接続性を介してInterestメッセージを送信し、メッセージを受信し、(Interest Message内の指定に従って)要求に一致するかまたは要求を満たすデータを有する任意の関与者は、一致するContent Objectメッセージを送信し得る。データは、データに一致するInterestに応じてのみ送信される。Interestメッセージは、最小限の帯域幅のコストでデータの多くの潜在的なソースに到達するために基礎をなす転送のブロードキャストまたはマルチキャスト設備を使用して送信され得る。

関与者は、たとえ一致する多くのContent Objectを有するとしても、単一の受信されたInterestメッセージに応答して最大でも1つのContent Objectメッセージを送信する。InterestメッセージとDataメッセージとの間のこの1対1のマッピングは、データが送信者から送信されるレートを受信者が制御することを可能にし、望まれていないところへデータを送信するのに帯域幅を消費することを避けるフローのバランスを維持する。

ノードデバイスは、2つの異なるノードデバイスが、(たとえば、ブロードキャストまたはマルチキャストによって)両方のノードデバイスによって受信された単一のInterestに応答して2つのContent Objectメッセージを送信する可能性を最小化するための抑制メカニズムを実装する。抑制メカニズムは、応答時間をランダム化することと、別のノードデバイスが応答をブロードキャストまたはマルチキャスト済みであり、したがって、Interestが破棄され得るという事実を検出することとを含む。

複数のContent Objectメッセージを必要とするデータの大きな集合を取り出したい受信者は、Interestメッセージのシーケンスを送信する。パイプライン化するために、受信者は、次のInterestメッセージを送信する前に各Interestメッセージに応答したデータを待つことなく複数のInterestメッセージを送信する可能性がある。これは、受信者が異なるInterestを構築するためにContent Objectの名前について前もって十分に知っている場合にのみ可能である。同一の要求により複数のInterestメッセージを送信することは、どのContent Objectを送信者が前に送信したかのいかなる記憶にも基づかず、それらの送信者がそのときに利用可能などのコンテンツを有するかのみに基づいて送信者がInterestに応答するので、常に、同じContent Objectを繰り返し送信させることになる。

CCNプロトコルは、メッセージの基礎をなす転送が信頼できると仮定しない。信頼できる配信を提供するために、時間の何らかの妥当な期間内に満たされないInterestメッセージは、再送信される。受信者は、その受信者がデータをまだ欲しがっている満たされていないInterestに関するタイマーを保持し、タイマーが切れるときにそれらのInterestを再送信する。

図2は、CCNノードデバイス102の例を示す。(単一のアプリケーションなどの制限されたCCNの関与者とは対照的に)完全なCCNノードデバイスは、バッファリング/キャッシングおよびループのないフォワーディングを提供するために以下のデータ構造を含む。CCNノードデバイス102は、コンテンツストア(CS)202、1つまたは複数のネットワークインターフェースデバイス(Face)204、転送情報ベース(FIB:Forwarding Information Base)メモリ206、保留関心テーブル(PIT:Pending Interest Table)メモリ208、およびフォワーディング論理メモリ209、およびプロセッサ210を含む。CS202は、名前に対する接頭辞一致検索によるContent Objectの取り出しのために編成されたバッファメモリを有する。CCNのContent Objectメッセージは自己識別し、自己認証するので、それぞれのCCNのContent Objectメッセージは、多くの消費者にとって潜在的に有用である。CS202は、最長時間未使用(LRU:Least Recently Used)または最低使用頻度(LFU:Least Frequently Used)などの、再利用の可能性を最大化する置き換えポリシーを実装する。CS202は、古さ(staleness)ビットも実装する。CS202は、Content Objectメッセージを無期限に保有する可能性があるが、それらのContent Objectメッセージを維持するためのいかなる特別の対策を施すことも要求されない。各CS202は、古さビットをあらゆるContent Objectに関連付ける。

新たに到着したコンテンツに関する古さビットの初期設定は、「古くない(not stale)」である。設定された古さビットを有するContent Objectは、Interestが設定された「答えが古い可能性がある」ビット("answer may be stale" bit)を持たない場合、Interest Messageに応答して送信される対象にならない。効果は、その古いContent Objectが存在しなかった場合と同じである(つまり、Interestがストア内の何らかのその他のContent Objectと一致するか、またはそれに失敗して、その他のノードデバイスに進む可能性がある)。古いContent Objectの厳密な複製が到着する場合、効果は、古いContent Objectが存在しなかった場合と同じである。特に、ストア内のContent Objectは、もはや古くない。実際問題として、古いContent Objectは、ストレージの割当量が到達されたときにストアから廃棄するもののリストの上位にランク付けされるべきである。

古さビットが設定される少なくとも2つの方法、すなわち、明示的設定またはタイマーによる設定がある。古さビットを明示的に設定するために、ローカルクライアントは、Interestメッセージ内で「古いものとして印を付ける」ビット("Mark as stale" bit)が設定されるようにしてコンテンツクライアントの関心(interest)を表し得る。これは、コンテンツをアクセス不可能にしようとする可能性がある攻撃の範囲を狭めるためにローカルクライアントに制限される。タイマーによって古さビットを設定するために、Content Objectは、Freshness要素を含む可能性がある。オブジェクト毎の古さタイマーが、CCNノードデバイスのローカルにあり、Content Objectが到着するときに開始する。Content Objectは、指定された秒数が過ぎるときに古くなる。

Face204は、インターフェースの概念の一般化である。Face204は、ネットワークへの接続であるか、またはアプリケーションの関与者への直接接続である可能性がある。Face204は、特定のネットワークインターフェース上でブロードキャストもしくはマルチキャストされるパケットを送受信するか、または基礎をなす転送におけるポイントツーポイントのアドレス指定を使用してもしくはトンネル(たとえば、TCPトンネル)を使用してパケットを送受信するように構成される可能性がある。Face204は、UDPなどのカプセル化またはOSに固有のプロセス間通信パスを介した、同じマシン上で実行される単一のアプリケーションプロセスへの接続である可能性もある。すべてのメッセージは、フェース(face)を通じて到着し、フェースを通じて送出される。

FIBメモリ206は、名前に対する最も長い接頭辞一致検索による取り出しのために編成された、Interestのための外向きのフェースのテーブルを提供する。FIBメモリ206内の各接頭辞エントリは、1つのFaceのみでなくFace204のリストを指す可能性がある。

PITメモリ208は、名前に対する最も長い接頭辞一致検索による取り出しのために編成された、満たされていないInterestに関するソースのテーブルである。PITメモリ208内の各エントリは、ソースのリストを指す可能性がある。PITメモリ208内のエントリは、無期限に保持されるのではなくタイムアウトする。

プロセッサ210は、以下で説明されるようにInterestおよびContent Objectメッセージを処理するためにCS202、PITメモリ208、FIBメモリ206、およびFace204とインターフェースを取る。フォワーディング論理メモリ209は、プロセッサ210のための実行命令を提供する。

上に挙げられたテーブルは、CCNのメッセージ処理およびフォワーディングのコアにおいて検索動作のコストを最小化するために単一のインデックスによって相互に接続される可能性があることに留意されたい。そのようなインデックスは、下で指定される検索順序の効果を実現するために順序付けられるかまたは優先順位付けされる。

図3は、Interest Messageを扱うためのプロセス300を示す。Interest Messageが到着Face204上でブロック302において受信されるとき、ブロック304において、CS202内で検索が実行される。一致するContent Objectが見つかる場合、そのContent Objectは、Interest Messageへの応答としてブロック306において到着Face204から送出される。一致するために、Content Objectは、Interest Message内で与えられる指定のすべてを満たさなければならない。複数のContent Objectが同時に一致する可能性があり、その場合、Interest Message内の指定が、どのContent Objectを返すべきかを決定するために使用される。CS202において一致が見つかるとき、処理は停止し、Interest Messageは破棄される。

CS202において一致がない場合、ブロック308においてPITメモリ208内で検索が実行される。一致するInterest MessageがPITメモリ208内で見つかる場合、等価なInterest Messageが既にフォワーディング済みであり、保留中である。新しいInterest Messageの到着Face204が、ブロック310においてPITメモリ208内の満たされていない関心のソースのリストに追加され、Interest Messageが、破棄される。

PITメモリ208において一致がない場合、ブロック312においてFIBメモリ206内で検索が実行される。一致する接頭辞がFIBメモリ206内で見つかる場合、ブロック314において、Interest Messageの到着Face204を特定するエントリが、PITメモリ208内に作成され、メッセージが、FIBメモリ206内の接頭辞に関して登録された外向きのFace204のうちの1つまたは複数に方針の規則に従って送信される。外向きのFace204のうちの1つが、名前のセマンティクスを使用して新しいフェースを動的に構成するローカルエージェントに実際に接続され得ることに留意されたい。

前のステップにおいて一致が見つからない場合、ノードデバイスは、現段階でInterest Messageを満たす方法を持たない。この状況を扱うために、ブロック316において、ポリシーの規則が従われる可能性がある。Interest Messageは、破棄される前の短い時間の間保持される可能性があり、ブロック316における新しいFIBメモリ206のエントリの生成は、Interest Messageを満たす方法を提供し得る。上に示されたように、CCNのコンテンツ名は、CCNプロトコル自体の動作においては解釈されず、単にマッチングされる。名前またはそれらの名前の構成要素の部分への意味のすべての割り当ては、接頭辞フォワーディング規則(prefix forwarding rule)に反映されたアプリケーション、機関、および/またはグローバルな規約に由来する。

図4は、Content Objectメッセージを扱うためのプロセス400を示す。ブロック402において、Content Objectメッセージが、受信される。ブロック404において、CS202内で検索が実行される。一致するContent Objectが見つかる場合、そのことは、いずれかのInterest Messageも既に満たされており、新しいInterest MessageがCS202の中から満たされることになるので、新しく到着したContent Objectがブロック406において安全に破棄され得る複製であることを意味する。

CS202において一致がない場合、ブロック408においてPITメモリ208内で検索が実行される。PITメモリ208内に一致がある場合、PITメモリ208内に表されるInterestに関するソースFace204のすべてでブロック410においてContent Objectが送信される。ノードデバイスは、Content Objectをフォワーディングする前にそのContent Objectの検証を実行する可能性があり、様々なポリシーの制約を適用する可能性がある。それから、コンテンツオブジェクトは、CS202にキャッシュされる。

PITメモリ208内で一致が見つからない場合、コンテンツは、まだ求められていない。ノードデバイスは、まだ求められていないデータをフォワーディングしない。ブロック412において、まだ求められていないデータは、破棄される可能性があり、またはそのデータが後で要求される場合に備えてCS202に記憶される可能性がある。

CCNのFIBメモリ206のエントリは、複数の次のホップの送信先を同時に指す可能性がある。Interest MessageおよびContent Objectの自己識別する性質は、任意の特定のノードデバイスにおいて任意の特定の接頭辞に関してただ1つの送信先のみを認めるスパニングツリーを確立することなしにループが避けられ得ることを意味する。複数の外向きのFaceの可能性は、メッセージをフォワーディングするときにそれらの外向きのフェースの中から選択を行うために異なる方針が使用され得ることを意味する。CCNノードデバイス102は、たとえそのCCNノードデバイス102がすべてのリストに挙げられた外向きのFace204上で順にInterest Messageを送信するだけの結果となるとしても何らかの方針の規則を実装する。ノードデバイスは、多くの異なる方針を実装する可能性がある。方針の規則は、FIBメモリ206のエントリによって指定される。それぞれのFIBメモリ206のエントリは、特定の接頭辞をアドレス指定するInterest Messageのフォワーディングを扱うための制約されたプログラムを含む可能性がある。

ノードデバイスは、何らかのタイムアウトの最中に新しいInterest Messageの到着によってリフレッシュされなかったPITメモリ208のエントリを破棄する。新しいInterestは、潜在的な受信者がコンテンツを受信することにまだ関心があることを裏付ける。ノードデバイスは、保留中のPITのエントリに関して周期的にInterest Messageを再送信する。ノードデバイスは、受信されたInterest Message(下流の関心)の活動性(liveness)をリフレッシュするために、保留中のInterest Message(上流の関心)を再送信するために使用されるタイムアウトとは異なるタイムアウトを使用する可能性があり、異なるフェースのために関連付けられた異なるタイムアウトを使用する可能性がある。このようにして、各ノードデバイスは、下流の関与者と上流の関与者との両方に一致する。

CCNプロトコルは、固定長のフィールドを持たない。その代わりに、CCNのデータフォーマットは、XMLスキーマによって定義され、明示的に特定されたフィールドの境界を用いて符号化される。CCNのコンテンツ名は、階層的に構造化され、いくつかの要素からなる。この設計は、任意の長さのフィールド値、省略されたときにパケットの空間を消費しない任意のフィールド、および入れ子にされた構造を可能にする。XML構造の使用は、フィールド値がテキスト文字列であることを示唆せず、メッセージが人間の読めるテキストとして符号化されることも必要としない。ほとんどのフィールドは、コンテンツを特定する任意の2進値を含む任意の2進値を含むように定義される。

図5は、典型的なInterestメッセージ500の例を示す。Interestメッセージ500は、最低でも、Type要素およびContent Name要素を含む。Type要素は、メッセージをInterestメッセージとして特定する。Content Name要素は、要求されるコンテンツに関する階層的な名前を表し、Interestメッセージの中で唯一の必須要素である。Interestメッセージ500は、以下のセレクタ要素--Name、MinSuffixComponents、MaxSuffixComponents、PublisherPublicKeyDigest、Exclude、ChildSelector、AnswerOriginKind、Scope、InterestLifetime、Nonce、およびFaceID--を含み得る。これらの残りの要素は、いくつかのカテゴリ--1)Interestに一致する可能性があるContent Objectをさらに限定するもの(MinSuffixComponents、MaxSuffixComponents、PublisherPublicKeyDigest、Exclude)、2)応答の出所を制限するもの(AnswerOriginKind、Scope、InterestLifetime)、3)一致する複数のContent Objectがあるときに何を送信すべきかの選択を教えるもの(ChildSelector)、および4)重複の抑制(Nonce)--に入る。

MinSuffixComponentsおよびMaxSuffixComponents要素は、一致するContentObject内に現れ得る暗黙的なダイジェストを数に入れる、接頭辞内の名前の構成要素を超える名前の構成要素の数に対する制限を指定する要素である。PublisherPublicKeyDigest要素は、一致があるためにContent ObjectのPublisherPublicKeyDigest要素の値と等しくなければならない値である。Exclude要素は、関心に応答してNameの接頭辞の続きとして現れるべきでない名前の構成要素の記述を具現化する。ChildSelector要素は、所与の関心が所与のコンテンツストア内の2つ以上のContentObjectに一致するときにどのContent Objectが返されるべきかの優先権を表す方法を提供する。AnswerOriginKind要素は、関心に対する応答を制御するいくつかのビットフィールドを符号化する。Scopeは、Interestが伝播する可能性がある場所を制限する。InterestLifetime要素は、関心がタイムアウトする前の残りの(おおよその)時間を示す。Nonce要素は、重複するInterestメッセージを検出し、破棄するために使用されるランダムに生成されたバイト列を運ぶ。FaceID要素は、関心をフォワーディングするための所望の外向きのフェースを指定するために使用され得る。

CCNアーキテクチャにおいて、Interestメッセージは、メッセージのペイロード内で特定されるときにデータをプルするために使用される。それから、プルされているデータは、適宜、ネットワーク内でキャッシュされる。プルに基づくアーキテクチャであるので、CCNアーキテクチャは、データをプッシュすることを本来サポートしない。Interestメッセージは、データを求めるために使用されるのでキャッシュ可能ではない。通常、Interestメッセージは、処理されると破棄され、CCNアーキテクチャ内でキャッシュされない。しかし、IoTアプリケーション内の典型的なプリミティブは、周期的にまたは特定のイベントに基づいてトリガされる可能性があるプッシュ通知である。本開示は、IoTアプリケーションを支援してCCN内でデータをプッシュするためにInterest型メッセージを使用する能力を提供する。データをプッシュする能力は、ネットワーク内の可用性に関する特定のパラメータを測定する様々なセンサーを有するIoTアプリケーションの実装を広げる。

CCNプロトコルは、名前によってデータを要求するための図5に示されたInterestメッセージと、要求に応答して要求元にデータを提供するContent Objectメッセージを使用してネットワーク100内でデータをプルする用に設計される。しかし、CCNプロトコルが最初にデータを要求することなしにネットワーク100にデータをプッシュすることが、有益である可能性がある。そのような筋書きでは、ネットワーク100内のエンティティが、ネットワーク100内のソースエンティティから特定のデータを受信することを申し込む可能性がある。データのソースが最初にデータの要求を受信することなしにネットワーク100を通じてデータをプッシュすることを可能にすることによって、ネットワーク100の能力は、CCNプロトコルがデータを自律的にプッシュする能力を含んでいるとしたならば大きく拡大するであろう。

図6A〜図6Cは、特別な種類のInterestメッセージの例を示す。図6Aにおいては、Interest-Notificationメッセージ600が、ネットワーク100を通じてデータをプッシュする能力を提供する。Interest-Notificationメッセージ600は、Interestメッセージと同様の形態を持つ代わりに、新しい種類のCCNネットワークパケットである。Interest-Notificationメッセージ600は、メッセージがキャッシュ可能なオブジェクトを運ぶ種類であることを示すType要素を含む。Interest-Notificationメッセージ600は、Content Name要素と、Cacheable Object自体と、Cacheable Objectを検証するための署名を含むセキュリティメタデータとをさらに含む。Content Name要素は、ネットワーク100にプッシュされているCacheable Objectに関する階層的な名前を表す。Interest-Notificationメッセージ600のCacheable Object要素は、Interestメッセージに応答して送信される、上述のContent Objectと同じフィールドを含む。セキュリティメタデータデータフィールドは、Cacheable Objectを検証するための署名を含む。図6Bおよび図6Cは、Interest-Notificationメッセージの別の変化型を示す。図6Bにおいては、Interest-Notificationメッセージ602が、Interestメッセージを、Cacheable ObjectがそのInterestメッセージとともにピギーバックされるまたはカプセル化されるようにしてカプセル化する。図6Cにおいては、Interest-Notificationメッセージ604が、Content Objectメッセージを、Cacheable ObjectがそのContent Objectメッセージとともにピギーバックされるまたはカプセル化されるようにしてカプセル化する。InterestまたはContent Object内の名前は、消費するエンドポイントへのルーティングのために使用される可能性があり、一方、Cached-objectの名前は、生成者がキャッシュされるオブジェクトをその名前の下に生成する名前を表す。

図7は、ネットワーク100内でデータをプッシュするために使用されるInterest-Notificationメッセージ700の代替的な例を示す。Interest-Notificationメッセージ700は、Interestメッセージと同様にType要素およびName要素を含む。Interest-Notificationメッセージ700は、メッセージをキャッシュ可能なオブジェクトを含むものとして特定する通知フラグも含む。Content Objectに関する例示的なフィールドと同様の例示的なフィールドが、Cacheable Objectに関して示される。この代替的な手法においては、現在のInterestメッセージプリミティブが、そのInterestメッセージを関心-通知メッセージとして特定するために使用される。しかし、処理論理は、メッセージがInterestメッセージとして処理されるのかまたはInterest-Notificationメッセージとして処理されるのかに関する通知フラグの値に依存する。Interest-Notificationメッセージ600と700との両方に関して、それらのInterest-Notificationメッセージ600および700内の、キャッシュ可能なオブジェクトの指示が、Interestメッセージのために使用される規則とは異なる規則を開始する。PITメモリ208の処理が、Interest-Notificationメッセージ600および700に関しては飛ばされる。Interest-Notificationメッセージ600および700は、Interest-Notificationメッセージ600および700をどこにルーティングすべきかを決定するためにFIBメモリ206内のエントリとマッチングされる。

図8は、ネットワーク100内で受信されたメッセージを評価する際のプロセス800を示す。プロセス800は、CCNプロトコルを実装するネットワーク100内の任意のエンティティによって実行され得る。プロセス800は、CCNノードデバイス102においてCCNメッセージを受信すると、ブロック802において始まる。ブロック804において、メッセージが、ペイロードの種類に関してチェックされる。メッセージは、Content Objectメッセージである場合、ブロック806において上述のように処理される。メッセージは、Interestメッセージである場合、ブロック808において上述のように処理される。メッセージは、Interest-Notificationメッセージである場合、Interest-NotificationメッセージがPITメモリ208の処理に含まれないことを唯一の例外として、必要に応じて、通常のInterestメッセージとしてブロック810において処理される。加えて、メッセージに含まれるキャッシュ可能なオブジェクトが、CCNノードデバイス102においてキャッシュするためにブロック810において抽出される。それから、キャッシュ可能なオブジェクトは、通常のInterestメッセージによる取り出しのために利用可能になる。そして、Interest-Notificationメッセージが、FIBメモリ206内の情報に基づいてその他のCCNノードデバイス102にフォワーディングされ、さらに、キャッシュ可能なオブジェクトに申し込むエンドポイントにフォワーディングされる。

図9は、ネットワーク100におけるInterest-Notificationメッセージ900のルーティングを示す。センサー104aは、Interest-Notificationメッセージ900内に入れるためのキャッシュ可能なオブジェクトを生成する。Interest-Notificationメッセージは、ネットワーク100を通じてIoTサーバ108にルーティングされる(プッシュされる)。ネットワーク100内の各エンティティは、Interest-Notificationメッセージ900を処理し、キャッシュ可能なオブジェクトがローカルにキャッシュされるべきであるかどうか、およびInterest-NotificationメッセージがFIBメモリ206の処理に従ってフォワーディングされるべきであるかどうかを判定する。キャッシュ可能なオブジェクトは、その他のセンサー104、シンク要素112、およびCCNノードデバイス102のうちの1つまたは複数を含むネットワーク100内の任意の場所にキャッシュされる可能性がある。図9に示される例において、Interest-Notificationメッセージ900は、IoTサーバ108にフォワーディングされ、キャッシュ可能なオブジェクトは、センサー104b、シンク要素112a、CCNノードデバイス102a、およびCCNノードデバイス102bのうちの1つまたは複数にキャッシュされる。

キャッシュ可能なオブジェクトがネットワーク100内のどこかにキャッシュされた状態で、アプリケーションまたはクライアント106などのその他のエンティティは、希望通りにキャッシュ可能なオブジェクトを要求する(プルする)ために通常のInterestメッセージ902を送信し得る。図9に示される例においては、Interestメッセージ902が、CCNノードデバイス102aによる処理のためにインターネット110、CCNノードデバイス102d、およびCCNノードデバイス102cを通じてフォワーディングされる。CCNノードデバイス102aは、クライアント106に返すためのキャッシュ可能なオブジェクトを含むContent Objectメッセージ904を生成する。加えて、IoTサーバ108は、通知の連続的なストリームに申し込む可能性がある。そのような筋書きにおいて、クライアント106は、希望通りにデータを要求(プル)し得る。代替的に、クライアント106は、連続的なストリームの代わりに周期的な通知を受信することを申し込む可能性がある。CCNノードデバイス102aのFIBメモリ206は、IoTサーバ108に連続的なInterest-Notificationメッセージ900を送信し、クライアント106にデータをプルさせることなしにクライアント106に周期的なInterest-Notificationメッセージ906を送信するように構成され得る。

上で示されたように、キャッシュ可能なオブジェクトに加えて、Interest-Notificationメッセージ600および700は、ネットワーク内にキャッシュ可能なオブジェクトを記憶することを管理するための属性を含む。これらの属性は、キャッシュフラグおよびコンテンツライフタイムを含む。キャッシュフラグは、キャッシュ可能なオブジェクトがネットワーク100内でキャッシュされるべきかどうかを示す。場合によっては、ネットワーク100においてプッシュされているデータは、レイテンシーの影響を受けやすく、したがって、キャッシングを必要としない可能性がある。その他の場合、ネットワーク100においてプッシュされているデータは、時間の特定の期間の間だけキャッシュされる必要がある。コンテンツライフタイム属性は、CS202にキャッシュされるときに、キャッシュ可能なオブジェクトがどれだけの長さ有効であるかを示す。キャッシュフラグおよびコンテンツライフタイム属性は、キャッシュ可能なオブジェクトのキャッシングを制御する能力を提供する。

キャッシュ可能なオブジェクトをキャッシュするときに考慮に入れられるいくつかのその他の考慮事項が、存在する。Interest-Notificationメッセージのストリームが、ネットワーク内の多くのソースから送信される可能性がある。キャッシュ可能なオブジェクトのキャッシングは、利用可能なキャッシュメモリを超えてしまう可能性がある。これに対処するために、キャッシュ可能なオブジェクトは、コンテンツオブジェクトよりも頻繁にキャッシュ内で削除され、置き換えられるようにコンテンツオブジェクトと区別され得る。キャッシュが満杯である場合、新しいキャッシュ可能なオブジェクトは、先入れ先出し、最長時間未使用、またはキャッシュ可能なオブジェクトのためだけのその他の優先方式を使用してキャッシュに入れられる可能性がある。別の技術は、キャッシュをキャッシュ可能なオブジェクトセクションおよびコンテンツオブジェクトセクションに論理的に区分けすることである。キャッシュ内のコンテンツオブジェクトに影響を与えることなく、新しいキャッシュ可能なオブジェクトは、キャッシュのキャッシュ可能なオブジェクトセクションのみに入れられ、古いキャッシュ可能なオブジェクトは、キャッシュのキャッシュ可能なオブジェクトセクションのみから削除される。

図10は、ネットワーク100内のInterest-Notificationメッセージの利点を示す。Interest-Notificationメッセージは、ネットワーク100内の故障したリンクを特定し得る。図10の例において、IoTサーバ108は、Interest-Notificationメッセージ1000を受信すると予測する。しかし、予測されたInterest-Notificationメッセージ1000は、IoTサーバ108において受信されなかった。この受信しないことは、IoTサーバ108とCCNノードデバイス102bとの間の故障したリンクまたはCCNノードデバイス102b内の故障の結果である可能性がある。たとえば、タイムアウトまたは順番通りでないInterest-Notificationメッセージの受信の後にIoTサーバ108がInterest-Notificationメッセージ1000を受信しなかったと判定すると、IoTサーバ108は、行方のわからないInterest-Notificationメッセージからのキャッシュ可能なオブジェクトを要求するためのInterestメッセージ1002を生成し得る。Interestメッセージ1002は、キャッシュ可能なオブジェクトがキャッシュされるCCNノードデバイス102aに達するまでCCNノードデバイス102eおよび102cを通って伝播する。CCNノードデバイス102aは、CCNノードデバイス102cおよび102eを通ってIoTサーバ108に返すために行方のわからないキャッシュ可能なオブジェクトを含むContent Objectメッセージ1004を生成する。Interest-Notificationメッセージ1000を受信しないことに関する情報が、修繕措置のためにネットワーク100を通じて送り返される可能性がある。

図11は、本開示によるSDN ICNスイッチによることを含め、ネットワーク100を通じてデータを転送し、処理する任意のデバイスである可能性があるネットワークデバイス1100の実施形態を示す。たとえば、ネットワークデバイス1100は、上述のCCNノードデバイス102のいずれかまたはネットワーク100内の任意のその他のエンティティに対応する可能性があり、または上述のCCNノードデバイス102のいずれかまたはネットワーク100内の任意のその他のエンティティ内に置かれる可能性がある。ネットワークデバイス1100は、上述の方式および方法を実装するかまたはサポートするように構成される可能性もある。ネットワークデバイス1100は、その他のネットワーク構成要素から信号およびフレーム/データを受信するための受信機(Rx)1112に結合された1つまたは複数の着信ポートまたはデバイス1110を含む可能性がある。ネットワークデバイス1100は、コンテンツをどのネットワーク構成要素に送信すべきかを決定するためのコンテンツを意識したデバイス(content aware device)1120を含む可能性がある。コンテンツを意識したデバイス1120は、ハードウェア、ソフトウェア、またはそれら両方を使用して実装される可能性がある。ネットワークデバイス1100は、その他のネットワーク構成要素に信号およびフレーム/データを送信するための送信機(Tx)1132に結合された1つまたは複数の発信ポートまたはデバイス1130も含む可能性がある。受信機1112、コンテンツを意識したデバイス1120、および送信機1132は、上の開示された方式および方法の少なくとも一部を実装するように構成される可能性もあり、ハードウェア、ソフトウェア、またはそれら両方に基づく可能性がある。ネットワークデバイス1100の構成要素は、図11に示されるように編成されるか、または任意のその他の構成で編成される可能性がある。

コンテンツを意識したデバイス1120は、プログラミング可能なコンテンツフォワーディングプレーンブロック1128と、プログラミング可能なコンテンツフォワーディングプレーンブロック1128に結合され得る1つまたは複数のストレージブロック1122とをさらに含む可能性がある。プログラミング可能なコンテンツフォワーディングプレーンブロック1128は、コンテンツ名または接頭辞と、おそらくはコンテンツをネットワークトラフィックにマッピングするその他のコンテンツに関連する情報とに基づいてコンテンツがフォワーディングされ得るアプリケーションレイヤまたはL3などのコンテンツフォワーディングおよび処理機能を実装するように構成され得る。そのようなマッピング情報は、コンテンツを意識したデバイス1120またはネットワークデバイス1100において1つまたは複数のコンテンツテーブル(たとえば、CS、PIT、およびFIB)に保持され得る。プログラミング可能なコンテンツフォワーディングプレーンブロック1128は、ユーザのコンテンツ要求を解釈し、それに応じて、ネットワークまたはその他のコンテンツルータから、たとえば、メタデータおよび/またはコンテンツ名(接頭辞)に基づいてコンテンツをフェッチする可能性があり、コンテンツをたとえば一時的にストレージブロック1122に記憶する可能性がある。それから、プログラミング可能なコンテンツフォワーディングプレーンブロック1128は、キャッシュされたコンテンツをユーザにフォワーディングし得る。プログラミング可能なコンテンツフォワーディングプレーンブロック1128は、ソフトウェア、ハードウェア、またはそれら両方を使用して実装される可能性があり、IPレイヤまたはL2よりも上で動作する可能性がある。

ストレージブロック1122は、加入者によって要求されるコンテンツなどのコンテンツを一時的に記憶するためのキャッシュ1124を含む可能性がある。加えて、ストレージブロック1122は、パブリッシャによって送られるコンテンツなどのコンテンツを比較的長く記憶するための長期ストレージ1126を含む可能性がある。たとえば、キャッシュ1124および長期ストレージ1126は、ダイナミックランダムアクセスメモリ(DRAM)、ソリッドステートドライブ(SSD)、ハードディスク、またはこれらの組合せを含む可能性がある。

図12は、本明細書において開示された構成要素のうちの1つまたは複数の実施形態を実装するために好適な典型的な汎用ネットワーク構成要素1200を示す。上述のネットワーク構成要素は、そのネットワーク構成要素にかけられる必要な作業負荷を扱うための十分な処理能力、メモリリソース、およびネットワークスループット能力を備えたコンピュータまたはネットワーク構成要素などの任意の汎用ネットワーク構成要素上に実装され得る。ネットワーク構成要素1200は、2次ストレージ1204、読み出し専用メモリ(ROM)1206、ランダムアクセスメモリ(RAM)1208を含むメモリデバイス、入力/出力(I/O)デバイス1210、およびネットワーク接続性デバイス1212と通信する(中央演算処理装置またはCPUと呼ばれる可能性がある)プロセッサ1202を含む。プロセッサ1202は、1つもしくは複数のCPUチップとして実装される可能性があり、または1つもしくは複数の特定用途向け集積回路(ASIC)の一部である可能性がある。

概して、2次ストレージ1204は、1つまたは複数のディスクドライブまたはテープドライブからなり、データの不揮発性の記憶のために使用され、RAM1208がすべての作業データを保持するのに十分なだけ大きくない場合は、あふれたデータのストレージデバイスとして使用される。2次ストレージ1204は、プログラムが実行のために選択されるときにRAM1208にロードされるそのようなプログラムを記憶するために使用され得る。ROM1206は、プログラムの実行中に読まれる命令およびおそらくはデータを記憶するために使用される。ROM1206は、2次ストレージ1204のより大きなメモリ容量と比べて小さなメモリ容量を通常有する不揮発性メモリデバイスである。RAM1208は、揮発性データを記憶し、おそらくは命令を記憶するために使用される。ROM1206とRAM1208との両方へのアクセスは、概して、2次ストレージ1204へのアクセスよりも速い。

要約すると、名前によって要求されるとき、CCNは、最も近いキャッシュからユーザに名前付きコンテンツを配信し、より少ないネットワークホップを横切り、冗長な要求をなくし、全体的により少ないリソースを消費する。上述のように、CCNは、もはや、キャッシュに記憶するためにネットワークにおいてデータをプッシュし、データに関する申し込みに対処するために使用され得る。ネットワークにプッシュされるデータは、ネットワークにおいて要求されるデータと区別される可能性がある。要求メッセージの変化型、Interest-Notificationメッセージが、ネットワークにまだ求められていないデータを送信するために使用される。説明されたInterest-Notificationメッセージの使用は、CCN環境内でIoTアプリケーションを実装する能力を提供する。

一部の実施形態においては、デバイスのうちの1つまたは複数の機能またはプロセスのうちの一部またはすべてが、コンピュータ可読プログラムコードから形成され、コンピュータ可読媒体に具現化されるコンピュータプログラムによって実装またはサポートされる。語句「コード」は、ソースコード、オブジェクトコード、および実行可能コードを含む任意の種類のコンピュータコードを含む。語句「コンピュータ可読媒体」は、読み出し専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、ハードディスクドライブ、コンパクトディスク(CD)、デジタルビデオディスク(DVD)、または任意のその他の種類のメモリなどの、コンピュータによってアクセスされ得る任意の種類の媒体を含む。

本特許明細書全体を通じて使用された特定の語および語句の定義を説明することが、都合が良い可能性がある。用語「含む(include)」および「含む(comprise)」ならびにこれらの派生語は、限定のない包含を意味する。用語「または(or)」は、包含的であり、および/または(and/or)を意味する。語句「に関連付けられる(associated with)」および「それらに関連付けられる(associated therewith)」ならびにこれらの派生語は、〜を含む(include)、〜内に含まれる(be included within)、〜と相互に接続する(interconnect with)、〜を含む(contain)、〜内に含まれる(be contained within)、〜にまたは〜と接続する、〜にまたは〜と結合する、〜と通信可能である、〜と協力する、〜を交互配置する、〜を並置する、〜に近い、〜にまたは〜と結びつけられる、〜を有する、〜の特性を有するなどの意味である。

本開示は特定の実施形態および広く関連する方法を説明したが、これらの実施形態および方法の代替形態および変更形態は、当業者に明らかであり、容易に認識され得るであろう。したがって、例示的な実施形態の上記の説明は、本開示を定義または限定しない。また、その他の変更、置き換え、および修正が、添付の請求項によって定義される本開示の範囲を逸脱することなく可能である。

100 ネットワーク
102 CCNノードデバイス
102a CCNノードデバイス
102b CCNノードデバイス
102c CCNノードデバイス
102d CCNノードデバイス
102e CCNノードデバイス
104 センサー
104a センサー
104b センサー
106 クライアント
108 IoTサーバ
110 インターネット
112 シンク要素
112a シンク要素
114 アプリケーションサーバ
140 ドメインコントローラ
202 コンテンツストア
204 ネットワークインターフェースデバイス
206 転送情報ベースメモリ
208 保留関心テーブルメモリ
209 フォワーディング論理メモリ
210 プロセッサ
300 プロセス
400 プロセス
500 Interestメッセージ
600 Interest-Notificationメッセージ
602 Interest-Notificationメッセージ
604 Interest-Notificationメッセージ
700 Interest-Notificationメッセージ
800 プロセス
900 Interest-Notificationメッセージ
902 Interestメッセージ
904 Content Objectメッセージ
906 Interest-Notificationメッセージ
1000 Interest-Notificationメッセージ
1002 Interestメッセージ
1004 Content Objectメッセージ
1100 ネットワークデバイス
1110 着信ポートまたはデバイス
1112 受信機
1120 コンテンツを意識したデバイス
1122 ストレージブロック
1124 キャッシュ
1126 長期ストレージ
1128 プログラミング可能なコンテンツフォワーディングプレーンブロック
1130 発信ポートまたはデバイス
1132 送信機
1200 汎用ネットワーク構成要素
1202 プロセッサ
1204 2次ストレージ
1206 読み出し専用メモリ
1208 ランダムアクセスメモリ
1210 入力/出力(I/O)デバイス
1212 ネットワーク接続性デバイス

Claims

コンテンツ指向ネットワーキング(CCN)ネットワークにおいてデータをプッシュするための方法であって、
CCNネットワーク内のノードデバイスの入力インターフェースデバイスにおいてソースからメッセージを受信するステップであって、前記ノードデバイスがCCNプロトコルを実行する、ステップと、
前記受信されたメッセージが関心-通知メッセージであると判定するステップであって、前記受信されたメッセージが、Typeフィールド、Content Nameフィールド、およびCacheable Objectフィールドを含むことによって前記関心-通知メッセージとして特定され、前記Typeフィールドが、前記受信されたメッセージが前記CCNネットワーク内にデータをプッシュしていることを示し、前記Content Nameフィールドが、階層的な名前を、前記CCNネットワーク内にプッシュされている前記データに関連付け、前記Cacheable Objectフィールドが、前記CCNネットワーク内にプッシュされている前記データを表すキャッシュ可能なオブジェクトを含む、ステップと、
前記受信されたメッセージが関心-通知メッセージであることに応じて前記キャッシュ可能なオブジェクトを抽出するステップと、
前記キャッシュ可能なオブジェクトを前記ノードデバイスのキャッシュに入れるステップと、
保留中の関心の処理を飛ばすために、前記関心-通知メッセージを、コンテンツオブジェクトを要求するプル型の関心メッセージではなく、プッシュ型メッセージとして処理するステップと、
前記処理することに応じて、転送情報ベースメモリを使用して前記関心-通知メッセージを出力インターフェースデバイスにフォワーディングするステップとを含む、方法。
前記受信されたメッセージがコンテンツオブジェクトを要求する関心メッセージであると判定するステップと、
前記ノードデバイスにおいて前記コンテンツオブジェクトがキャッシュされているかどうかを判定するステップと、
前記ノードデバイスにおいて前記コンテンツオブジェクトがキャッシュされていることに応じて前記コンテンツオブジェクトを前記ソースに提供するステップとをさらに含む請求項１に記載に方法。
コンテンツオブジェクトが、関心-通知メッセージによって前記ノードデバイスにおいて前記キャッシュに以前に入れられたキャッシュ可能なオブジェクトである請求項１または２に記載の方法。
前記キャッシュ内で、関心メッセージによって要求されたコンテンツオブジェクトを、前記関心-通知メッセージ内で提供されるキャッシュ可能なオブジェクトと区別するステップをさらに含む請求項１から３のいずれか一項に記載の方法。
前記関心-通知メッセージが、新しい種類のCCNネットワークメッセージであり、前記新しい種類のCCNネットワークメッセージが、関心メッセージのTypeフィールドと、前記CCNネットワークメッセージがキャッシュ可能なオブジェクトを含むことを示すフラグフィールドとを含む請求項１から４のいずれか一項に記載の方法。
前記関心-通知メッセージが、最初に前記データが前記CCNネットワーク内の1つまたは複数のノードデバイスによって要求されることなしに、前記1つまたは複数のノードデバイスにデータをプッシュする請求項１から５のいずれか一項に記載の方法。
前記関心-通知メッセージが、前記キャッシュ可能なオブジェクトが前記キャッシュ内でどれだけの長さ有効であるかを示すライフタイムフィールドを含む請求項１から６のいずれか一項に記載の方法。
前記関心-通知メッセージが、前記キャッシュ可能なオブジェクトが前記キャッシュ内にキャッシュされるべきであるかどうかを示すキャッシュフラグフィールドを含む請求項１から７のいずれか一項に記載の方法。
前記関心-通知メッセージが、関心メッセージおよびコンテンツオブジェクトのいずれか一方を前記キャッシュ可能なオブジェクトとともにカプセル化する請求項１から８のいずれか一項に記載の方法。
コンテンツ指向ネットワーキング(CCN)ネットワークにおいてデータをプッシュするための装置であって、
ソースからメッセージを受信するように構成された入力インターフェースデバイスであって、前記装置がCCNプロトコルを実行する、入力インターフェースデバイスと、
データおよび命令コードを記憶するように構成されたメモリと、
プロセッサであって、前記命令コードを実行すると、
前記受信されたメッセージが関心-通知メッセージであると判定することであって、前記受信されたメッセージが、Typeフィールド、Content Nameフィールド、およびCacheable Objectフィールドを含むことによって前記関心-通知メッセージとして特定され、前記Typeフィールドが、前記受信されたメッセージがCCNネットワーク内にデータをプッシュしていることを示し、前記Content Nameフィールドが、階層的な名前を、前記CCNネットワーク内にプッシュされている前記データに関連付け、前記Cacheable Objectフィールドが、前記CCNネットワーク内にプッシュされている前記データを表すキャッシュ可能なオブジェクトを含む、判定すること、
前記受信されたメッセージがキャッシュ可能なオブジェクトを含む関心-通知メッセージであるかどうかを判定すること、
前記受信されたメッセージが前記関心-通知メッセージであることに応じて前記キャッシュ可能なオブジェクトを抽出することを行うように構成された、プロセッサと、
前記キャッシュ可能なオブジェクトを受信し、キャッシュするように構成されたコンテンツストアと、
前記関心-通知メッセージが前記CCNネットワーク内でさらにフォワーディングされるべきかどうかを特定するように構成された転送情報ベースメモリとを含み、
前記プロセッサが、
保留中の関心の処理を飛ばすために、前記関心-通知メッセージを、コンテンツオブジェクトを要求するプル型の関心メッセージではなく、プッシュ型メッセージとして処理し、
前記転送情報ベースメモリによって特定された出力インターフェースデバイスに前記関心-通知メッセージをフォワーディングするようにさらに構成される、装置。
前記プロセッサが、
前記受信されたメッセージがコンテンツオブジェクトを要求する関心メッセージであると判定し、
前記コンテンツオブジェクトが前記コンテンツストアにキャッシュされているかどうかを判定し、
前記コンテンツオブジェクトが前記コンテンツストアにキャッシュされていることに応じて前記コンテンツストアから前記コンテンツオブジェクトを提供するようにさらに構成される請求項１０に記載の装置。
コンテンツオブジェクトが、前記コンテンツストアに以前に入れられた前記関心-通知メッセージからのキャッシュ可能なオブジェクトである請求項１０または１１に記載の装置。
前記コンテンツストアが、関心メッセージによって要求されたコンテンツオブジェクトを、前記CCNネットワークにプッシュされた関心-通知メッセージに含まれるキャッシュ可能なオブジェクトと区別する請求項１０から１２のいずれか一項に記載の装置。
前記関心-通知メッセージが、新しい種類のCCNネットワークメッセージであり、前記新しい種類のCCNネットワークメッセージが、関心メッセージのTypeフィールドと、前記CCNネットワークメッセージがキャッシュ可能なオブジェクトを含むことを示すフラグフィールドとを含む請求項１０から１３のいずれか一項に記載の装置。
前記関心-通知メッセージが、前記キャッシュ可能なオブジェクトが前記コンテンツストア内でどれだけの長さ有効であるかを示すライフタイムフィールドを含む請求項１０から１４のいずれか一項に記載の装置。
前記関心-通知メッセージが、前記キャッシュ可能なオブジェクトが前記コンテンツストア内にキャッシュされるべきであるかどうかを示すキャッシュフラグフィールドを含む請求項１０から１５のいずれか一項に記載の装置。
前記関心-通知メッセージが、関心メッセージおよびコンテンツオブジェクトのいずれか一方を前記キャッシュ可能なオブジェクトとともにカプセル化する請求項１０に記載の装置。