最初に、1つまたは複数の実施形態の例示的な実施態様を以下に提供するが、開示されるシステムおよび/または方法は、現在既知であるか、または既存のものであるか否かにかかわらず、任意の数の技法を使用して実装されてもよいことが理解されるべきである。本開示は、本明細書に例示および記載の例示的な設計および実施態様を含む、下記に示す例示的な実施態様、図面および技法には決して限定されるべきではなく、それらの全範囲の均等物とともに、添付の特許請求の範囲の適用範囲内で変更されてもよい。
CONまたはICNは、コンテンツ配布トラフィックおよび会話型トラフィックの両方をサポートするための次世代インターネットアーキテクチャと考えられている。今日のインターネットプロトコル(IP)ルータとは異なり、ICNルータは、コンテンツルーティング、コンテンツ計算能力、およびコンテンツローカルキャッシュ/記憶機能を兼ね備えることができる。今日のIPネットワークと同様に、ICN(新規の相互作用層としての)は、会話型トラフィックモデルおよびコンテンツ配布モデルのような、複数の異なるトラフィックモデルをサポートすることが可能であり得る。会話型モデルは、音声/ビデオ・マルチメディア・アプリケーション、ボイスオーバIP(VoIP)、インスタントメッセージ、ソーシャルネットワーキング、トランザクションベースのオンラインバンキングのようなアプリケーション、リアルタイム通信のためのいくつかのリアルタイム転送プロトコル(RTP)接続、および/または他の同様のネットワークトラフィックを含んでもよい。コンテンツ配布モデルは、ブロードキャストもしくはマルチキャストメディア(たとえば、IPテレビ)および/または同様のトラフィックのような、コンテンツ検索およびプッシュ事象を含んでもよい。一般的に、会話型モデルはピア間の非共有可能通信に対応し得、一方で配布モデルは、多くの人々またはユーザの間で分配される共有可能コンテンツに対応し得る。
コンテンツ中心ネットワーク(CCN)/名前付きデータネットワーキング(NDN)提言のようないくつかのICNモデルにおいて、相互作用機能はコンテンツ配布モデルに焦点を当てたものであり得る。CCN/NDNデータ転送プレーンにおいて、コンテンツ配布を効率的にサポートするために、名前ベースのルーティングおよび転送をサポートするのに、ステートフルな手法が使用される場合がある。ステートフルな手法において、要求ごとに、コンテンツルータはネットワーク内状態を(たとえば、制限時間内)保持してもよく、状態はコンテンツ名ごとであってもよい。たとえば、新たに受信されたインタレストに対して、CCN/NDNはPIT内で状態レコードを生成および保持し得る。PITはこのステートフル情報を、インタレストのループバックを打ち切り、他のインタレストを同じコンテンツ名に集約し、返ってきたコンテンツデータを元の要求者への後方経路へ誘導するのに使用することができる。PITはまた、ICNがアドホックネットワーク(たとえば、IPルーティングプロトコルを用いないインフラ不要なネットワーク)に適用されるとき、動的なソースルーティングをサポートするのに使用することができる。
PITはコンテンツ配信をサポートするのに有用または有効であり得るが、PITによって不利益も生じ得る。具体的には、PITの状態情報は、線形的またはインタレストの数に比例するものであり得、したがって、VoIPトラフィックまたはオンラインバンキングサービスのような会話型トラフィックモデルが考えられるとき、相当なスケーラビリティ問題を有し得る。たとえば、夫々の交換されるVoIPトラフィックが、たとえばプライバシーの懸念に起因して交換情報を他者と共有することができない、対応するエンド・ツー・エンドのセッションを必要とする場合がある。しかしながら、PITは、VoIPトラフィックまたは他の類似のトラフィックについてはレコードエントリを保持する必要がない場合がある。VoIPトラフィックにPITを使用しても、VoIPトラフィックのハンドリングおよびそのようなトラフィックのルーティングを改善しない場合があり、スケーラビリティ問題につながる場合がある。
コンテンツ/情報配布モデルおよびホスト間会話型モデルの両方をサポートするためにデュアルモードデータ転送プレーン動作を使用するためのシステムおよび方法が、本明細書において開示される。デュアルモードデータ転送プレーン動作は、PITスケーラビリティ問題を解決することができ、ICNまたはCONにおける名前ベースのルーティングおよび転送に基づき得る。デュアルモードデータ転送プレーン動作は、たとえば、PITを使用してコンテンツ配布を処理するための第1のモードと、音声/ビデオトラフィックのようなホスト間(たとえば、2者以上のホスト間の)非共有可能会話型トラフィックを処理するための第2のモードとを備えることができる。会話型トラフィックは、たとえば、インタレストおよびコンテンツデータの両方の双方向におけるデータルーティングのためにFIBを使用してハンドリングされ得る。第1のモードにおいて、パケットは第1のまたはスローパスにおいて処理することができ、これは、ローカルキャッシングデータ検索、PITルックアップおよび更新、ならびにFIBルックアップおよび転送のような複数の動作を含んでもよい。第2のモードにおいて、パケットは第2のまたはファストパスにおいて処理することができ、これは、他の動作のないFIBルックアップおよび転送を含んでもよい。このデュアルモード動作をサポートするために、下記に詳細に説明するように、ICN PDUのための新規のヘッダが使用されてもよい。デュアルモードデータ転送プレーン動作は、配布トラフィックモデルおよび会話型トラフィックモデルの両方を柔軟かつスケーラブルにハンドリングすることができ、トラフィックアプリケーションによる監督を受けることができる。
図1は、一般的な単一モード転送プレーン動作100を示し、これはICNまたはCONにおいて現在使用される場合がある。たとえば、単一モード転送プレーン動作100はCCN/NDNデータ転送プレーンにおいて使用される場合がある。単一モード転送プレーン動作100は、ICNまたはCON内のコンテンツルータ101によって実装され得る。コンテンツルータ101は、ICNまたはCONにおいてコンテンツデータ転送を適切にハンドリングするために、複数のポートまたはインターフェース102(たとえば、フェース0、フェース1、フェース2、...)と、複数の転送テーブルまたはデータ構造体とを備えてもよい。インターフェース102は、複数の固定(有線)リンク、無線リンク、ネットワーク、インターネット、および/または他の構成要素若しくはシステムを介して、1つまたは複数のユーザまたはコンテンツ加入者(図示せず)および1つまたは複数のサービスまたはアプリケーション103に結合されてもよい。
コンテンツルータ101の転送テーブルは、CS110と、PIT120と、転送情報ベース(FIB)130とを備えてもよい。CS110は、インタレスト(コンテンツに関するユーザ要求)を対応するデータ(要求されているコンテンツ)と関連付けるのに使用されてもよい。たとえば、CS110は、各受信インタレストを示す「名前」列と、対応するコンテンツデータを示す「データ」列とを備えてもよく、これらは、コンテンツルータ101において受信されてもよく、任意選択的にまたは部分的にコンテンツルータ101においてキャッシュされてもよい。PIT120は、各インタレストを1つまたは複数の要求元または受信インターフェース102と関連付けることによって、サービスされているまたは(対応する要求されているコンテンツデータが受信されるまで)保留になっている各受信インタレストを記録し、追跡するのに使用されてもよい。たとえば、PIT120は、各インタレストを示す「プレフィックス」列と、そのインタレストに関する1つまたは複数の受信インターフェース102を示す「要求フェース」列とを備えてもよい。FIB130は、インタレストを、インタレストが受信および転送される対応するインターフェース102と関連付けるのに使用されてもよい。たとえば、FIB130は、各インタレストを示す「プレフィックス」列と、対応する受信および転送インターフェース102を示す「フェースリスト」列とを備えてもよい。コンテンツルータ101は、3つの転送テーブルの各々を指示するポインタテーブル140またはデータ構造体を備えてもよい。たとえば、ポインタテーブル140は、各転送テーブルのロケーションを指示するかまたは示す「ptr」列と、各対応する転送テーブルの名前またはタイプ(たとえば、CSに対する「C」、PITに対する「P」、およびFIBに対する「F」)を示す「タイプ」列を備えてもよい。
単一モード転送プレーン動作100において、インタレストは、たとえば、ユーザまたはコンテンツ加入者(図示せず)から無線リンクを介して第1のポートまたはインターフェース102(フェース0)において受信されてもよい。インタレストは、要求されているコンテンツを示す名前プレフィックスを備えてもよく、CS110に転送されるかまたはCS110において処理されてもよい。CS110内で、示された名前プレフィックスを使用して受信されたインタレストに対してエントリが作成されてもよい。名前プレフィックスは、その「名前」列の下でCS110の新規または空の行に入力されてもよい。その後、インタレストはPIT120に転送されるか、またはPIT120において処理されてもよい。PIT120内で、示された名前プレフィックスを使用して受信されたインタレストに対してエントリが作成されてもよい。要求元または受信インターフェース102(フェース0)も、同じエントリ内で示されてもよい。名前プレフィックスはその「プレフィックス」列の下でPIT120の新規または空の行に入力されてもよく、フェース0は、その「要求フェース」列の下で同じ行内に示されてもよい。その後、インタレストはFIB130に転送されるか、またはFIB130において処理されてもよい。FIB130内で、示された名前プレフィックスを使用して受信されたインタレストに対してエントリが作成されてもよい。要求元インターフェース102(フェース0)も、同じエントリ内で示されてもよい。名前プレフィックスはその「プレフィックス」列の下でFIB130の新規または空の行に入力されてもよく、フェース0は、その「フェースリスト」列の下で同じ行内に示されてもよい。その後、インタレストは転送インターフェース102(フェース1)上で、たとえば、次のホップまたはコンテンツルータ(図示せず)に転送されてもよい。
要求されたコンテンツデータが、たとえば、転送インターフェース102(フェース1)上で次のホップを介して受信されると、受信データ内で示されている名前プレフィックスが、FIB130内の対応するエントリと照合されてもよい。このように、そのデータに関する受信転送インターフェース102(フェース1)は、照合されたエントリの「フェースリスト」列に追加されてもよい。その後、名前プレフィックスはPIT120内の対応するエントリと照合されてもよい。したがって、コンテンツデータは、照合されたエントリの「要求フェース」列内で示されているインターフェース(複数の場合もあり)102(フェース0)上で転送されてもよい。名前プレフィックスはまた、CS110内の対応するエントリと照合されてもよく、コンテンツデータは、照合されたエントリの「データ」列内にキャッシュされてもよい。コンテンツデータはキャッシュ基準または方式に従って完全にまたは部分的にキャッシュされてもよいし、されなくてもよい。
ブロードキャストもしくはマルチキャストメディア(たとえば、IPテレビ)のようなコンテンツ配布トラフィックについて、インタレストは、たとえば、複数のユーザまたはコンテンツ加入者から、複数のインターフェース102上で受信されてよい。したがって、照合されたエントリの「要求フェース」列が、コンテンツが送信(ブロードキャストまたはマルチキャスト)され得る複数のインターフェース102を示す場合がある。しかしながら、非共有可能である会話型トラフィックについては、PIT120において各受信インターフェース102に対してエントリが作成され得る。そのため、エントリの数は要求元のユーザまたは加入者の数に比例し得、これによって、ユーザの数が大幅に増大するとPIT120のサイズが大幅に増大する場合がある。これによって、PIT120についてより大規模なネットワーク(相対的にスケールが大きいICNまたはCON)のスケーラビリティ問題が生じる場合があり、そのため転送効率が低減し、費用が増大し、またはその両方が起こる場合がある。
図2は、ネットワークシステムにおける一般的な単一モード転送シナリオ200を示し、これは、単一モード転送プレーン動作100に基づいてもよい。データまたはコンテンツは、名前プレフィックスを使用してネットワークシステム内で転送されてもよい。ネットワークシステムは、1つまたは複数のティア1ネットワーク(たとえば、インターネットのための)、1つまたは複数のティア2ネットワーク(たとえば、IPバックボーン、インターネット・サービス・プロバイダ(ISP)、インターネット相互接続点(IXP)、存在点(POP)、...のための)、および1つまたは複数のティア3ネットワーク(たとえば、マルチホームISP、シングルホームISP、...のための)を含んでもよい、複数のネットワーク(たとえば、ICN)を備えてもよい。ティア3ネットワークは、ユーザ(インターネットユーザ)により近くてもよく、ティア1ネットワークはインターネットレベルにあってもよく、ティア2ネットワークはティア1ネットワークとティア3ネットワークとの間の中間ネットワークであってもよい。ティアネットワークは、コンテンツルータ101のような、対応するPITを備えてもよい複数のコンテンツルータを備えてもよい。
シナリオ200は、ネットワークシステムにわたって複数のコンテンツルータ、たとえば、エッジルータを示しており、PITのスケーラビリティに問題があり得、たとえば、PITのエントリの数が著しく多いものであり得る。たとえば、ティア1ネットワークとティア2ネットワークとの間、および、ティア2ネットワークとティア3ネットワークとの間のエッジルータにあるPITは、(図2の「爆発」絵図によって示されているように)非スケーラブルである場合がある。具体的には、このシナリオは、表210に示すような複数のネットワーク条件に対応する。条件は、各グループのティアネットワーク(ティア1、ティア2、およびティア3)に関する、相対的な上流ルータ集中度、平均入口帯域幅、およびPITサイズ(ルータごと)を含む。ティア1およびティア2ネットワークに関する上流ルータ集中度(それぞれ8.4および8)は、ティア3ネットワークの上流ルータ集中度よりも大幅に大きいものであり得る。平均入口帯域幅は、ティア2ネットワーク(36.2ギガバイト(G))と比較して、ティア1ネットワークについてはより大きく(110G)、ティア3ネットワークについてはより小さい(3.5G)ものであり得る。平均入口帯域幅に比例し得るPITサイズも、ティア2ネットワーク(0.411G)と比較して、ティア1ネットワークについてはより大きく(3.29G)、ティア3ネットワークについてはより小さい(0.049G)ものであり得る。
図3は、PITのスケーラビリティ問題を解決し、そのためたとえば、CCN/NDNデータ転送プレーンにおけるルーティング効率を改善するICNにおいて使用され得る、デュアルモード転送プレーン動作300の一実施形態を示している。デュアルモード転送プレーン動作300は、ICN内のコンテンツルータ301によって実装され得る。コンテンツルータ301は、インタレスト/データを受信および送信するための複数のポートまたはインターフェースと、CS310、PIT320、およびFIB330を含む、ICNにおいてコンテンツデータ転送を適切にハンドリングするための複数の転送テーブルまたはデータ構造体とを備えてもよい。デュアルモード転送プレーン動作300において、トラフィックは、トラフィックのタイプに従って優先モードまたは非優先モードにおいて転送されてもよい。具体的には、会話型トラフィック(たとえば、非共有可能トラフィック)は、優先モードを使用して転送されてもよく、コンテンツ配布トラフィック(たとえば、共有可能トラフィック)は、非優先モードを使用して転送されてもよい。各タイプのトラフィックの各々のインタレストおよびデータの両方が、優先または非優先モードに従って転送されてもよい。転送モードは、下記に説明するようなPDUフォーマットを使用するなどして、受信インタレストおよびデータ内で示されてもよい。
非優先モードは、コンテンツ配布または共有可能トラフィックに(インタレストおよびデータの両方に)使用されてもよく、転送プレーン動作100に対応し得る。したがって、CS310、PIT320、およびFIB330の各々は、転送プレーン動作100に記載されているようなインタレストおよびデータの受信、ハンドリング、および転送に使用されてもよい。コンテンツデータは複数のユーザまたは加入者間で共有可能であり得るため、PIT330内の同じエントリが複数の受信ポートに対して共有されてもよく、これによってスケーラビリティ問題が回避され得る。優先モードは、会話型または非共有可能トラフィックに(インタレストおよびデータの両方に)使用されてもよく、CS310およびPIT320を使用することなく、FIB330がインタレストおよびデータの受信、ハンドリング、および転送に使用され得る。PIT320(およびCS310)に入力されるのを回避することによって、インタレストおよびコンテンツの転送が優先され得、PITスケーラビリティ問題が解決され得る。FIB330は、FIB130と同様に、インタレストを、インタレストが受信および転送される対応するポートと関連付けるのに使用されてもよい。要求されたコンテンツデータが、たとえば、対応するインタレストの受信ポートとは異なるポート上で受信されると、受信データ内で示されている名前プレフィックスが、FIB330内の対応するエントリと照合されてもよい。照合されたエントリ内のインタレスト受信ポートがデータを転送するのに使用され得、データを受信するポートが照合されたエントリに加えられ得る。PIT320のスケーラビリティを改善するのに加えて、デュアルモード転送プレーン動作300は、種々のタイプのコンテンツインタレスト/データを転送する際の柔軟性を提供し、したがって、全体的なルーティング効率を改善することができる。
図4は、デュアルモード転送プレーン動作300においてインタレストを送信するのに使用されてもよいインタレストPDUフォーマット400の一実施形態を示す。インタレストPDUフォーマット400は、インタレストが属するトラフィックのタイプ(会話型またはコンテンツ配布トラフィック)を示すことができ、そのため、上述のように、トラフィックが然るべく転送されることができる。インタレストPDUは、受信インタレストメッセージとともに、またはその一部として受信されることができ、メッセージ・タイプ・フィールド410と、転送モードフィールド420と、ソースオブジェクト名フィールド430と、宛先オブジェクト名フィールド440と、チェックサムフィールド450と、無効期間または有効期間(TTL)フィールド460と、署名フィールド470と、ノンスフィールド480と、メタ・データ・リストまたはアレイ490と、ペイロードフィールド499とを備えてもよい。メタ・データ・リストまたはアレイ490は、自己証明型エイリアス値もしくはフィールド491、デバイスタイプ値もしくはフィールド492、全地球測位システム(GPS)値もしくはフィールド493、セレクタ値またはフィールド494、および/または、セキュアド・コミュニティ識別子(ID)値もしくはフィールドを含んでもよい他の値もしくはフィールド495を備えてもよい。ペイロードフィールド499に先行する上記のフィールドは、PDUのヘッダを表してもよいし、またはその一部であってもよい。
図5は、デュアルモード転送プレーン動作300においてデータ応答を送信するのに使用されてもよいデータPDUフォーマット500の別の実施形態を示す。データPDUは、(PDUフォーマット400にある)対応するインタレストPDUに応答してコンテンツルータに返されてもよい。PDUフォーマット500は、データが属するトラフィックのタイプ(会話型またはコンテンツ配布トラフィック)を示すことができ、そのため、トラフィックが然るべく転送されることができる。データPDUは、受信コンテンツデータとともに、またはその一部として受信されることができ、メッセージ・タイプ・フィールド510と、転送モードフィールド520と、ソースオブジェクト名フィールド530と、宛先オブジェクト名フィールド540と、チェックサムフィールド550と、TTLフィールド560と、署名フィールド570と、メタデータリストまたはアレイ590と、ペイロードフィールド599とを備えてもよい。メタ・データ・リストまたはアレイ590は、自己証明型エイリアス値もしくはフィールド591、デバイスタイプ値もしくはフィールド592、GPS値もしくはフィールド593、セレクタ値もしくはフィールド594、および/または、セキュアド・コミュニティID値もしくはフィールドを含んでもよい他の値もしくはフィールド595を備えてもよい。ペイロードフィールド599に先行する上記のフィールドは、PDUのヘッダを表してもよいし、またはその一部であってもよい。データPDUフォーマット500内のフィールドは、後述するインタレストPDUフォーマット400内の対応するフィールドと実質的に同様に構成されてもよい。
ペイロード499はインタレストデータを備えてもよく、ペイロード599はインタレストデータに対応し得るコンテンツデータを備えてもよい。メッセージ・タイプ・フィールド410は、PDUがインタレストPDUであるか、またはデータPDUであるかを示すために設定され得るフラグを備えてもよい。代替的に、メッセージ・タイプ・フィールド410は、PDUがインタレストPDUであるか、またはデータPDUであるかを示すように、決定された値を備えてもよい。インタレストは宛先オブジェクト名フィールド440内の宛先オブジェクト名でルーティングされてもよい。非キャッシュ可能トラフィックの場合、インタレストは宛先オブジェクト名でルーティングされてもよく、対応するデータ応答がソースオブジェクト名フィールド430内のソースオブジェクト名を使用してルーティングされてもよい。メッセージ・タイプ・フィールド510は、メッセージ・タイプ・フィールド410と同様に構成されてもよい。
転送モードフィールド420は、PDUが優先モードを使用して転送されているか、または非優先モードを使用して転送されているかを示すために設定され得るフラグを備えてもよい。代替的に、転送モードフィールド420は、PDUが優先モードを使用して転送されているか、または非優先モードを使用して転送されているかを示すように決定された値を備えてもよい。フラグはアプリケーションによって決定されてもよい。たとえば、PDUが、個人宛VoIP/ビデオのような非キャッシュ可能(または非共有可能)コンテンツである場合、アプリケーション層はモードを優先に設定してもよい。共有可能コンテンツであり得るYoutube(登録商標)ストリーミングビデオの場合、フラグは非優先として設定されてもよい。転送エンジン(コンテンツルータ301のための)は、FIB330を(ソース/宛先オブジェクト名に基づいて)調べ、それに従ってPDUを指定ポートもしくはインターフェースに送り出す(優先もしくはファストモード)か、または、PIT操作、ローカルキャッシュ操作、および/もしくは何らかの他の演算プロセスを使用する(非優先またはスローモード)かを決定するためにこのフラグを検査してもよい。
転送モードが優先として設定されると、PDUは、ソースオブジェクト名(ソース・オブジェクト・フィールド430内)を搬送してもよい。たとえば、デバイスがモバイルであり、デバイス上のアプリケーションがシームレス・モビリティ・サービスに加入している場合、アプリケーションはフラグを非優先に設定し、ソース/宛先オブジェクト名の両方をモビリティ制御に使用してもよい。デバイスが基地局との接続の変化を検出すると、ネットワーク内のシームレス・アンカー・ポイントが特定のユーザ/アプリケーションのためにデータをキャッシュすることを可能にするように転送モードが設定されてもよい。これによって、モバイルデバイスが新たな接続点に再アンカリングされた後にアプリケーションがデータを検索することが可能になり得る。転送モードフィールド520は、転送モードフィールド420と同様に構成されてもよい。
ソースオブジェクト名フィールド430は、要求者(またはユーザ)名を示すことができ、宛先オブジェクト名フィールド440は、要求されているオブジェクト名を示すことができる。転送タイプが優先であるとき、ソースオブジェクト名がインタレストPDU内に含まれ得る。そうでない場合、ソースオブジェクト名を使用することは任意選択であってもよい。宛先オブジェクト名は優先および非優先モードの両方において含まれ得る。たとえば、非共有可能コンテンツであり得る音声通信について、(被発呼側からの)データ応答PDU内のソースオブジェクト名(たとえば、呼出し側)が、メッセージをオブジェクト要求者に返すために、FIB330を有するコンテンツルータ301によって使用されてもよい。
デュアルモード転送プレーン動作300をサポートするために、コンテンツ要求者または加入者(および同様に、コンテンツ制作者)は、データ応答を求める関連アプリケーションプレフィックスを発行することを期待され得る。これによって、プレフィックスがFIB330内にデータ投入されることが可能になり得、それによって、データ応答がルーティングし戻され得る。共有可能コンテンツ(たとえば、Youtube(登録商標)ビデオ)の場合、インタレストPDUフォーマット400はソース識別子(ID)を搬送しなくてもよく、戻されたコンテンツはPIT320ルックアップを介してルーティングし戻され得る。転送フラグ(メッセージ・タイプ・フィールド410内)が優先モードに設定されているとき、後方転送を目的としてインタレストPDU内でソースオブジェクト名が設定され得る。ソースオブジェクト名および宛先オブジェクト名は構造化名またはフラット名のいずれかであってもよい。構造化名は、ユニフォームリソース識別子(URI)のような階層フォーマットを有してもよい。フラット名はデジタルフォーマットを有してもよく、これは、ハッシュ関数から生成されるビット列であってもよい。構造化名が使用されるとき、PDUまたはパケットはデフォルトのゲートウェイルータに転送されてもよく、ここで、たとえば、コンテンツルータ301がPDUを転送するための次のホップを見つけることができない場合に宛先サーバを決定するためにドメイン名システム(DNS)が使用されてもよい。コンテンツルータ301はその後、PDUを宛先サーバに転送してコンテンツを取り戻してもよい。ソースオブジェクト名フィールド530および宛先オブジェクト名フィールド540は、それぞれソースオブジェクト名フィールド430および宛先オブジェクト名フィールド440と同様に構成されてもよい。
チェックサムフィールド450は、受信PDUのインテグリティを示すために検証され得る値を備えてもよい。チェックサム値は、たとえば、PDUがメモリまたは記憶装置内で破損したか否かをチェックするためにPDUのヘッダおよびペイロード部内でエラーがないかチェックするのに使用されてもよい。PDU内にチェックサムを設定するには、2つのルータ(コンテンツルータ)間の信頼性のあるコンテンツ中継が必要となり得る。そうでなければ、PDUの送信は信頼性のあるものにならない場合がある。チェックサムフィールド550は、チェックサムフィールド450と同様に構成されてもよい。
TTLフィールド460は、転送モードの設定に応じて、たとえば、パケットの転送ループを防止するために、PITもしくはローカルキャッシュ内に記憶されているインタレスト/データの持続時間を示すために、またはその両方のために、受信PDUまたはパケットの持続期間を示すことができる。TTLは、異なる転送モードでは異なる解釈を有してもよい。優先モードにおいて、TTLの目的は、PDUおよびFIB内のソースオブジェクト名および宛先オブジェクト名の両方が転送を監督するのに使用されるときに転送ループを打ち切ることであってもよい。たとえば、転送ループは、コンテンツルータの間のマルチパス転送に起因して生じる場合がある。非優先モードにおいて、TTLは、インタレストまたはデータPDUがPITまたはローカルキャッシュ内でどれだけ長く存在するか、または有効なままであることができるかを示すのに使用されてもよい。
優先モードにおいて、TTLは転送ループを防止するためにインタレストPDUおよびデータPDUの両方において使用されてもよい。この場合のTTLは、最大許容ホップの数として設定されてもよい。転送中、すべてのホップ(ルータ)は、TTL値を1単位ずつ、約0の値に達するまで低減し得る。TTL値が約0である場合、PDUは破棄され得る。非優先モードにおいて、TTLはある単位の現在時刻(TOD)として設定されてもよく、これはPDUの持続時間を示してもよい。たとえば、相対的に長いTODを有する持続的なインタレストが、ICNにおけるイベント・プッシュ・サービスをサポートするために、PIT内に記憶されてもよい(たとえば、加入者は、存在しないコンテンツを事前に検索することができる)。データPDU内のTTLはデータがどれだけ長く各ローカルキャッシュ内に記憶されることができるかを示し得る。このTTLを使用して、コンテンツルータは、ICNネットワーク内で失効したコンテンツを排除するためにポリシーベースの減衰関数を実装してもよい。TTLはアプリケーションによって設定されてもよい。TTLフィールド560は、TTLフィールド460と同様に構成されてもよい。
署名フィールド470は、名前およびペイロードに基づいてもよい暗号学的ハッシュ関数、たとえば、ハッシュ(名前,ペイロード)を備えてもよい。署名は、PDU内の宛先オブジェクト名、静的メタデータアイテム、および/またはペイロードの間の関係を保持する署名入り証明書であってもよい。PDUの受信者は、この署名を使用して指定の関係(たとえば、コンテンツが信頼できる発行者からのものであるか否か)を検証することができる。ノンスフィールド480は乱数を備えてもよく、メッセージ・リプレイ・アタックを防止するのに使用することができる。このフィールドを使用して、受信ルータは受信PDUを追跡し、リプレイアタックを示し得る、同じPDUが複数回受信されている状況を検出することができる。受信ルータはリプレイされた(または再送信された)PDU(複数の場合もあり)を破棄してもよい。署名フィールド570およびノンスフィールド580は、それぞれ署名フィールド470およびノンスフィールド480と同様に構成されてもよい。
メタ・データ・アレイ490は、コンテキストベースのパラメータ、演算関数、または演算関数に対するウェブリンクのような名前ベースのポインタのリストであってもよい。メタ・データ・アレイ490は、コンテンツ転送、アクセス、記憶動作、セキュリティ、および/または指定のサービス処理動作を監督/誘導するのに使用されてもよい。メタ・データ・リストまたはアレイ490内の自己証明型エイリアス値またはフィールド491は、コンテンツ発行者からの公開鍵または公開鍵のハッシュであってもよい。要求者がインタレストを送信すると、このフィールド内のエイリアスがインタレストPDU内で送信されてもよい。これに応答してデータPDUが返送されると、データPDUもエイリアスを搬送し得る。コンテンツルータは、発行者のソースまたは出処を検証するためにエイリアスがインタレストPDUとデータPDUとの間で一致するか否かを検証することができる。一致しないエイリアスを備える返されたデータPDUは、そのようなPDUは不正発行者から来ているおそれがあるため、破棄され得る。
インタレストPDU内のデバイスタイプ値492は、要求オブジェクトのタイプ(たとえば、iPhone(登録商標)またはiPad(登録商標))を示すことができる。GPSフィールド493は要求者(ユーザデバイスまたはアプリケーション)の地理的位置(たとえば、座標)を示すことができる。セレクタフィールド494は、受信コンテンツルータが、当該コンテンツが一致したインタレストへ返される前に(たとえば、データPDUがローカルキャッシュ内に記憶されているときに)1つまたは複数の指定機能を実施することを可能にし得るサービス機能ポインタを備えることができる。セキュアド・コミュニティIDは、アクセス制御ポリシーを認証するためにインタレストおよびデータPDU内で使用することができる。メタ・データ・アレイ590、自己証明型エイリアス値またはフィールド591、デバイスタイプ値またはフィールド592、GPS値またはフィールド593、セレクタ値またはフィールド594、および、データPDUフォーマット500の他の値またはフィールド595は、インタレストPDUフォーマット400内のそれらの対応するフィールドと同様に構成されてもよい。
一実施形態において、コンテンツルータ301のような2つのコンテンツルータが隣接関係を確立するとき、ルータは、チェックサム値がたとえば、コンテンツ層相互作用において信頼可能なデータ送信をサポートする必要があるか否かを交渉し得る。アプリケーションタイプに基づいて、ユーザまたは端末デバイスは、上述のように、インタレストPDUを構築するためにソースオブジェクト名を割り当て得る。たとえば、アプリケーションが音声アプリケーションであるとき、ソースオブジェクト名がPDU内で搬送され得る。そうでなく、アプリケーションがたとえば、Youtube(登録商標)ビデオをダウンロードすることである場合、ビデオ名(たとえば、URI)が宛先名として使用されてもよい。メッセージ・タイプ・フラグがそれに応じて設定されてもよい(インタレストまたはデータのいずれか)。TTLは、端末デバイスによって、またはデバイスが接続されている第1のコンテンツルータによってのいずれかで設定されてもよい。たとえば、インタレストが将来のイベントに関するものである場合、TTLは、インタレストがこれから起きるイベントを待つために持続的なインタレストであることを示してもよい。データPDUにおいて、署名が上述のように適切に生成され得る。転送タイプがそれに従って設定され得る。少なくともいくつかのメタ・データ・アレイ・フィールドがPDU内で搬送され得る。たとえば、インタレストPDUにおいて、セキュアド・コミュニティIDがアクセス制御に使用されてもよい。自己証明型エイリアスもソース検証に使用されてもよい。たとえば、PDU内の残りのフィールドが設定された後、チェックサムが(必要な場合)計算されてもよく、その後PDUが第1のコンテンツルータに送信され得る。
コンテンツルータが宛先オブジェクト名を有するインタレストを受信すると、ルータはインタレストPDU内のチェックサムを検証し得る。したがって、損傷したパケットが検出された場合は破棄することができる。その後、ルータは転送モードをチェックすることができる。転送モードが優先オブジェクトに対応する場合、転送動作は上述のようにファストパス(または優先モード)として処理することができる。コンテンツルータの転送エンジン(FE)は対応するFIBを調べて、いずれの次ホップインターフェース(複数の場合もあり)にパケットが転送され得るかを判定することができる。この場合、TTL(たとえば、ホップの数)が1単位ずつ低減され得る。TTLが約0まで低減された場合、PDUは破棄され得る。インタレストの一致がポリシーに基づいてFIBにおいて見つからない場合、パケットは破棄されるか、すべての出口インターフェースに送り出される(たとえば、エニーキャストまたはフラッディング)か、またはデフォルトのゲートウェイルータに送信され得る。転送モードが非優先に対応する場合、転送動作はスローパス(または非優先モード)において処理することができる。この場合、ローカルキャッシュ内の宛先オブジェクト名に一致が見つかった場合、コンテンツは送信し戻されることができる。非共有可能アプリケーションまたはモビリティエージェントは、コンテンツキャッシングを可能にしシームレスなモビリティをサポートするために、(PDUを使用して)一時的に非優先モードを設定することができる。そうでない場合、たとえば、以前に確立されたものと同じ名前状態の下で新たなエントリを作成するか、または入口インターフェース数の待ち行列に入れることによって、PITの名前ごとの状態が更新されてもよい。
PDU内で受信されるTTLおよびメタデータはPIT内に記憶され得る。TTLを低減するためにローカルタイマが使用されてもよい。TTLが約0まで落とされると、対応するインタレストがPITから削除され得る。PIT動作の後、FEはFIBを調べてどこにパケットが転送され得るかを判定することができる。パケットを送信する前に、コンテンツルータがPDUのいくつかの構成要素(たとえば、TTL)を変更する場合があるため、チェックサムが再計算され得る。FIB内で、第2のコンテンツルータまたは発行者のデバイスであり得るPDUの宛先オブジェクトが見つかった後、上述のようにデータPDUが生成され得る。転送タイプに基づいて、(優先モードにおいて)転送ループを防止するために、または(非優先モードにおいて)コンテンツがネットワークのローカルキャッシュ内にどれだけ長く存在し得るかを規定するために、TTLが使用され得る。関連サービスをサポートするためにPDUヘッダ内のメタデータが使用され得る。たとえば、発行者はいずれのインタレストがデータを消費してよいかを決定するためにセキュアド・コミュニティIDを定義してもよい。発行者はまた、コンテンツルータがコンテンツのソースを検証することを可能にするために自己証明型エイリアスを関連付けてもよい。
データPDUが受信されると、PDUのチェックサムが検証され得、ルータのFEがPDU内で示されている転送モードをチェックすることができる。インタレストPDUと同様に、転送動作もファストパスまたはスローパスとして処理され得る。スローまたは非優先モードにおいて、PDUのペイロードがローカルキャッシュにおいて複製され得、関連メタデータに基づいて処理され得る。たとえば、コンテンツルータは、一致したセキュアド・コミュニティIDまたはエイリアスを有するインタレストのみが、要求者に返されるデータPDUを受信することができる、と決定することができる。このため、データPDU内で搬送されているエイリアスがPIT内のいかなるインタレストのエイリアスとも一致しない場合、PDUは破棄され得る(たとえば、データPDUが不正発行者から送信されているおそれがある)。真正のデータPDUについては、PITは(データPDU内の情報に従って)更新されることができ、対応するコンテンツデータがPITからの名前ごとの状態に基づいてすべてのまたは複数の要求者に配布されることができる。
インタレストおよび対応するコンテンツデータを受信および転送するための上記の方式と同様の方式が、プッシュイベント通知動作をサポートするのに使用されてもよい。プッシュイベント通知動作シナリオにおいては、インタレストを送信することによってイベントデータをプルする代わりに、加入者が、自身の関心のあるイベントプレフィックスを(たとえば、コンテンツ・ルーティング・プロトコルを介して)1つまたは複数もしくはすべてのルータのFIBにデータ投入することができる。そのため、1つまたは複数のルータが、ルータのFIBに対してイベントプレフィックスを構成することができる。イベント発行者は、その後、イベントプレフィックスを宛先オブジェクト名の一部として使用し、メタデータを使用していずれのルータ(複数の場合もあり)がイベントを記憶することができるかを示すことができる。たとえば、一時的イベントはデータPDUとして表現され、発行者がイベントを加入者に向けてプッシュするときに優先され得る。イベントは、デバイスが接続され得るアクセスルータに送信され得る。配布プロセスの間、1つまたは複数のルータ上のFEは、関連FIBを使用してイベントデータを転送することができる。この場合、TTL(PDU内)が、転送ループを打ち切るか、または防止するのに使用され得る。メタデータに基づいて、イベントは指定加入者(複数の場合もあり)にプッシュされ得る。
図6は、ICNのデュアルモード転送プレーン動作300を分析するのに使用される実験シミュレーションのためのシミュレーショントポロジ600の一実施形態を示す。シミュレーションは、デュアルモードにおいてCCNを操作することによって得られる効率を比較するのに使用される。シミュレーショントポロジ600は、参照によって本明細書に援用される、http://abilene.internet2.edu/に記載されているインターネット2アビリントポロジに対応する。シミュレーショントポロジ600は、CCNxのような実世界プロトコル実施態様を使用したシミュレーション分析を可能にするNS3−DCE環境を使用して構成される。NS3−DCE環境は、M. Lacageによって、参照により本明細書に援用される、2010年11月のthe University of Nice−Sophia Antipolisにおける、「Outils dexperimentation pour la recherche en reseaux」と題する博士論文において説明されている。ccnx−0.4.0リリースがこのシミュレーションに使用される。このシミュレーションに関するさらなる詳細は、Ravishankar Ravindran他によって、参照によりその全体が本明細書に援用される、「コンテンツ中心ネットワークにおけるデュアルモード転送のサポート(Supporting Dual−Mode Forwarding in Content Centric Network)」と題するHuawei社内報(Huawei Research Center, Santa Clara, California)(Ravindran他)において説明されている。
シミュレーショントポロジ600は、0〜11とラベリングされている、複数の相互接続ノード(たとえば、コンテンツルータ)を備える。ノードは、図6に示すように、会話型アプリケーションおよびコンテンツ共有(またはコンテンツ配布)アプリケーションをホストする。分析のために考えられたトラフィックは、コンテンツ共有トラフィック(コンテンツ共有アプリケーション用)と音声会話トラフィック(会話型アプリケーション用)との組合せである。インタレストルーティングは最短経路優先ロジックに従って実施される。
コンテンツ共有アプリケーションは、ユーザ間のコンテンツ共有に起因するトラフィックに対するモデルを提示する。シミュレーショントポロジ600は、共有可能コンテンツのためのリポジトリノードとして構成されているノード11を含む。ノード11は、共有コンテンツを蓄積するためのリポジトリ(repo)610と関連付けられている。Ravindran他によって詳細に説明されているように、リポジトリ610は2000個のコンテンツオブジェクトを有して初期化されており、幾何平均サイズは100チャンクである。コンテンツ人気度は、2の指数パラメータを用いたジップ分布によって求められ、人気度クラスの数Kは100に設定されている。シミュレーション時間を実用限界内に保持するために、これらのパラメータは、G.Carofiglio他によって、参照により本明細書に援用される、「コンテンツ中心ネットワーキングにおけるデータ転送のモデル化(Modeling data transfer in content centric networking)」と題する技術報告書(http://perso.rd.francetelecom.fr/muscariello/report−itc−transport.pdf, 2011)において考えられているものをスケールダウンしたものである。シミュレーショントポロジ600において、ノード1、5、7、および9が共有コンテンツに関する要求を生成するために選択される。ファイル共有アプリケーションはCCNxリリースに含まれているccndsendchunksおよびccncatchunks2ユーティリティに基づく。ccncatchunks2は1のウィンドウサイズで操作される。
会話型アプリケーションはポイント・ツー・ポイント・ストリーミング会話型コンテンツをシミュレートする。Ravindran他によって詳細に説明されているように、アプリケーションは、パケット生成速度が50パケット/秒(s)であり、音声ペイロードが160バイト(B)である固定ビットレート音声アプリケーションとしてモデル化される。この目的のための新規のCCNxユーティリティが開発された。このユーティリティは、インタレストおよびデータ応答が同じ速度で生成される双方向音声セッションを実施する。シミュレーショントポロジ600を参照すると、ノード0、2、4、および8は会話型コンテンツのトラフィックを生成するために選択されている。デフォルト(または優先)モードにおいて、音声パケットの終了はシミュレーションシナリオに応じて1sまたは5sに設定され、デュアルモードにおいて音声パケットは転送されるときに顕著に陳腐化する。
優先及び非優先転送モードまたは方式の効率を比較するために、シミュレーションから複数の性能測定基準が収集される。性能基準は、最大CSサイズ、最大PITサイズ、キャッシュヒット率、誤り指数、および平均往復時間(RTT)を含む。RTTは、そのアプリケーションに関するチャンクあたりの応答時間であり、インタレストが発行されたときからデータ応答が受信された時点までで測定される。図7は、最大CSサイズと、シミュレーションの結果または出力値(パラメータ)から得られる音声コールレートとの間の関係700を示す。結果は、選択された負荷およびインタレストルーティングロジックに起因してノード2、5、および8を接続するリンク(2→1)、(5→2)、(8→5)が最高のリンク利用度を有するときのノード2、5、および8に対応する。
関係700の種々の曲線は、2つの転送モードの下での各種負荷に対する最大CSサイズの性能を比較している。デフォルトまたは非優先モードにおいて、最大CSサイズは音声コールのレートが増大するとともに増大する。コールレートの増大によって、単位時間あたりにより多くのコールがアクティブになり得、そのためより多くの音声コンテンツがCS内でキャッシュされ得、これによってエッジルータおよびトランジットルータの両方においてCS利用度が増大し得るため、こうなると予測される。CSサイズは入来するインタレストの割合に応じて決まり、これによって、ノード5および8はノード2よりも大きいCSを有することになり得る。デュアルモードにおいて、音声データ応答パケットはCS処理をバイパスすることができ、これによって、エッジまたはトランジットルータ内にパケットのメモリは残らないことになり得る。これは図7に表されており、CSキャッシュサイズは、コンテンツ共有アプリケーションから生じるデータ応答のみと関連付けられる。これによって、CSサイズは音声コールレートが増大してもほぼ同じままになる。
図8は、最大PITサイズに関して得られる効率を分析するための、最大PITサイズと、シミュレーションの結果から得られる音声コールレートとの間の関係800を示す。最大PITサイズの挙動は、両方の転送モードについて、最大CSサイズのそれと相関する。結果はノード2、5、および8に関して提示されている。関係800は、音声コールレートが増大するにつれて、デフォルトの場合は比例してPITサイズが増大するが、デュアルモードの場合は実質的に影響を受けないままであることを示している。この原因は、優先とマークされている音声インタレストが、PIT処理をバイパスするFIBを使用した高速転送を受けるためであり得る。CSの場合と同様に、3つのノードに関するPITサイズに差が出る理由は、インタレスト到着パターンおよびネットワーク内のインタレスト・ルーティング・ロジックに起因し得る。
図9は、往復時間と、シミュレーションの結果から得られるクラスidとの間の関係900を示す。関係900は、両方の転送モードを使用するコンテンツ共有アプリケーションに関する平均RTT性能を示す。両方の場合において、クラス人気度が低減するとともにコンテンツ誤りの確率は増大するため、RTT性能はクラスidが増大するとともに増大する。デフォルトをデュアルモード転送の場合と比較すると、デュアルモード転送の場合はキャッシュヒット率が改善するため、RTTも改善し得る。この原因は、デュアルモード転送によって、コンテンツ共有アプリケーションに益するCSリソースに関する競合がなくなり(または大幅に低減し)、その結果ヒット率およびRTTがより良好になり得るためであり得る。
図10は、往復時間と、シミュレーションの結果から得られる音声コール要求レートとの間の関係1000を示す。関係1000は、2つの転送モードに関する音声アプリケーションのRTTの性能を示す。結果は、ノード2、4、および8との音声セッションを有するノード0に関して提示されている。ノード対(0,2)、(0,4)および(0,8)の平均RTTの差は、ホップの数が増大すること、および経路内トランジットリンクの利用度が高くなることに起因し得る。具体的には、単一のCCNノードについて、インタレストおよび対応するデータ応答は4〜5ミリ秒(ms)の範囲内にあると観察される。シミュレーション設定は、リンクあたり約2ミリ秒(ms)のち遅延を含み、シミュレーション設定に起因するオーバヘッド要因によって、RTT観察が合理的に説明される。デフォルトをデュアルモードと比較すると、音声アプリケーションは改善を示していないことになり得る。デュアルモードはデフォルトCCNの場合と同程度に良好であるか、またはそれよりもやや悪いことが分かる。この観察は、CCNxが、CS、PITCSおよびFIBを1つの論理データ構造として実装することに起因し得る。これによって、プロトコルの実施態様を大幅に変更することなく優先コンテンツをハンドリングするための効率的なファストパス転送の実施が阻害され得る。
図11は、ICN(たとえば、CCN)において使用されてもよいハイブリッドモード転送実施態様1100の一実施形態を示す。ハイブリッドモード転送実施態様1100は、ステートフルモード実施態様1110およびステートレスモード実施態様1120を使用することができる。ステートフルモード動作1110は、ICNの端部において、またはネットワークのアクセス部分において(端部もしくはアクセスルータにおいて)単一モード転送動作(たとえば、単一モード転送プレーン動作100)を使用することができる。そのため、ステートフルモード実施態様1110は、上述のようなPIT動作を使用してネットワークの端部または周縁においてインタレストおよびデータを転送することができる。端部またはネットワークアクセス領域においてPIT動作を使用することは、ネットワークの端部におけるサービス妨害(DOS)攻撃および/または分散DOS(DDOS)攻撃を抑制するのに有用であり得る。ステートレスモード実施態様1120は、ICNのコアまたはバックボーンにおいて(コアまたはバックボーンルータにおいて)、デュアルモード転送プレーン動作300のようなデュアルモード転送動作を使用することができる。そのため、ステートレスモード実施態様1120は、PITおよびCSを使用することなく、FIBを使用してネットワークコア領域において会話型トラフィックに関するインタレストおよびデータを転送することができ、それによって、上述のように共有可能会話型トラフィックについてPITスケーラビリティ問題を解決することができる。ステートフルモード実施態様1110(単一モードまたは非優先(デフォルト)転送)およびステートレスモード実施態様1120(デュアルモードまたは優先転送)の両方を使用することによって、ハイブリッドモード転送実施態様1100は、PIT動作の利点(ネットワーク端部における)とPITスケーラビリティ問題の解決(ネットワークコアにおける)との間で妥協点または平衡をもたらすことができる。
図12は、ICNまたはCCNのようなネットワークシステムにおいてハイブリッドモード転送実施態様1100を使用することができる、ハイブリッドモード転送シナリオ1200の一実施形態を示す。ネットワークシステムは複数のネットワーク(たとえば、ICN)を備えてもよく、当該ネットワークは、たとえば、単一モード転送シナリオ200におけるネットワークと同様の、1つまたは複数のティア1ネットワーク、1つまたは複数のティア2ネットワーク、および1つまたは複数のティア3ネットワークを含んでもよい。ティア1およびティア2ネットワークは、ネットワークシステムのバックボーン部分に対応し得る。ティア3ネットワークはネットワークシステムのアクセス部分に対応し得、複数のコンテンツユーザ(消費者)または加入者に結合されてもよい。ティアネットワークは、コンテンツルータ101のような、(対応するCSおよびFIBを有する)対応するPITを備えてもよい複数のコンテンツルータを備えてもよい。
シナリオ1200は、ネットワークシステムにわたって複数のコンテンツルータ、たとえば、エッジルータを示している。ルータは、たとえば、ティア1ネットワークとティア2ネットワークとの間、および、ティア2ネットワークとティア3ネットワークとの間のバックボーンルータを含み得、PITのスケーラビリティが問題になり得る(転送される非共有可能会話型トラフィックの数が著しく大きいとき)。この問題を克服するために、バックボーンルータは、インタレストおよびデータトラフィックを転送するためにデュアルモード転送動作300(またはステートレスモード実施態様1120)を使用することができる。具体的には、上述のように、会話型トラフィックはFIBを使用して優先モードで(ネットワークシステムのバックボーン部分において)転送されることができ、コンテンツ配布トラフィックはCS、PIT、およびFIBを使用して非優先モードで転送されることができる。ルータは、たとえば、ティア3ネットワークとユーザとの間のアクセスルータをも含み得、DOS、DDOS、またはリプレイアタックに対するもののような、ネットワークシステムのセキュリティが問題になり得る。そのため、アクセスルータは、インタレストおよびデータトラフィックを転送するために単一モード転送動作100(またはステートフルモード実施態様1110)を使用することができる。具体的には、上述のように、コンテンツトラフィックは、CS、PIT、およびFIBを使用してデフォルトまたは非優先モードで(ネットワークシステムのアクセス部分において)転送され得る。
図13は、ICNにおける非共有可能会話型トラフィックおよび共有可能コンテンツ配布トラフィックの両方のインタレストおよびデータを転送するのに使用することができるデュアルモード転送方法1300の一実施形態を示す。デュアルモード転送方法1300は、コンテンツルータ301のような、ICN内のコンテンツルータまたはノードによって実施することができる。方法1300はブロック1310において開始することができ、インタレスト/データPDUが受信され得る。たとえば、コンテンツルータが、PDUフォーマット400と同様のインタレストPDUを受信してよく、または、たとえば、以前受信したインタレストに応答して、PDUフォーマット500と同様のデータPDUを受信してもよい。ブロック1320において、方法1300は(コンテンツルータにおいて)インタレスト/データPDUが優先モードを使用して転送されているか、または非優先モードを使用して転送されているかを判定し得る。たとえば、PDUが優先モード(会話型トラフィック用)を使用してまたは非優先モードを使用して転送されていることを示すようにフラグが設定されているかを判定するために、コンテンツルータは、インタレストPDUフォーマット400内の転送モードフィールド420またはデータPDUフォーマット500内の転送モードフィールド520をチェックしてもよい。トラフィックが非共有可能または会話型トラフィックである場合、優先モードがセットされ得る。そうでない場合、非優先モードが使用され得る。ブロック1320における条件が真である場合、方法1300はブロック1330に進み得る。そうでない場合、方法1300はブロック1340に進み得る。
ブロック1330において、インタレスト/データPDUが、たとえば、デュアルモード転送プレーン動作300における優先モードについて上述したように、CSおよびPITを用いずにFIBを使用して処理され得る。その後、方法1300はブロック1350に進み得る。ブロック1340において、インタレスト/データPDUが、たとえば、一般的な単一モード転送プレーン動作100におけるデフォルトの非優先モードについて上述したように、CS、PIT、およびFIBを使用して処理され得る。この場合、受信データPDUのコンテンツ(またはペイロード)の少なくとも一部がコンテンツルータに(たとえば、CSに)キャッシュされてもよい。ブロック1350において、インタレスト/データPDUが、たとえば、ネットワーク内の次のホップに転送され得る。その後、方法1300は終了し得る。
図14は、ネットワークを通じてデータを移送および処理する任意のデバイスであってもよい、ネットワークユニット1400の一実施形態を示す。たとえば、ネットワークユニット1400は、コンテンツルータ301に対応してもよく、または、コンテンツルータもしくはICN内の任意のノード内に位置してもよい。ネットワークユニット1400はまた、上述の方式および方法を実施またはサポートするように構成されてもよい。ネットワークユニット1400は、他のネットワーク構成要素から信号およびフレーム/データを受信するための受信機(Rx)1412に結合されている1つまたは複数の入口ポートまたはユニット1410を備えてもよい。ネットワークユニット1400は、いずれのネットワーク構成要素にコンテンツを送信すべきかを判定するためのコンテンツ・アウェア・ユニット1420を備えてもよい。コンテンツ・アウェア・ユニット1420は、ハードウェア、ソフトウェア、またはその両方を使用して実装されてもよい。ネットワークユニット1400はまた、他のネットワーク構成要素に信号およびフレーム/データを送信するための送信機(Tx)1432に結合されている1つまたは複数の出口ポートまたはユニット1430を備えてもよい。受信機1412、コンテンツ・アウェア・ユニット1420、および送信機1432はまた、ハードウェア、ソフトウェア、またはその両方に基づいてもよい、上記で開示されている方式および方法のうちの少なくともいくつかを実施するように構成されてもよい。ネットワークユニット1400の構成要素は図14に示すように配置されてもよい。
コンテンツ・アウェア・ユニット1420はまた、プログラム可能コンテンツ転送プレーンブロック1428と、プログラム可能コンテンツ転送プレーンブロック1428に結合されてもよい1つまたは複数の記憶ブロック1422とを備えてもよい。プログラム可能コンテンツ転送プレーンブロック1428は、アプリケーション層またはL3におけるようなコンテンツ転送および処理機能を実施するように構成されてもよく、コンテンツは、コンテンツ名またはプレフィックス、および、可能性として、コンテンツをネットワークトラフィックにマッピングする他のコンテンツ関連情報に基づいて転送されてもよい。そのようなマッピング情報は、コンテンツ・アウェア・ユニット1420またはネットワークユニット1400にある1つまたは複数のコンテンツテーブル(たとえば、CS、PIT、およびFIB)内に保持されてもよい。プログラム可能コンテンツ転送プレーンブロック1428は、コンテンツに関するユーザ要求を解釈し、それに従って、たとえば、メタデータおよび/またはコンテンツ名(プレフィックス)に基づいてネットワークまたは他のコンテンツルータからコンテンツをフェッチすることができ、コンテンツを、たとえば一時的に、記憶ブロック1422内に記憶することができる。プログラム可能コンテンツ転送プレーンブロック1428はその後、キャッシュしたコンテンツをユーザに転送することができる。プログラム可能コンテンツ転送プレーンブロック1428は、ソフトウェア、ハードウェア、またはその両方を使用して実装されてもよく、IP層またはL2の上で動作してもよい。
さらに、プログラム可能コンテンツ転送プレーンブロック1428は、上述のデュアルモード転送方式またはハイブリッドモード転送方式を実施してもよい。ハイブリッドモード転送方式の場合、プログラム可能コンテンツ転送プレーンブロック1428は、ネットワークユニット1400がネットワークのバックボーンに位置する場合はデュアルモード転送方式を(PITを使用することなく)実施することができ、ネットワークユニット1400がネットワークのアクセス部分に位置する場合は単一モード転送方式を(PITを使用して)実施することができる。記憶ブロック1422は、加入者によって要求されているコンテンツのようなコンテンツを一時的に記憶するためのキャッシュ1424を備えてもよい。加えて、記憶ブロック1422は、発行者によって投稿されたコンテンツのようなコンテンツを相対的に長く記憶するための長期記憶装置1426を備えてもよい。たとえば、キャッシュ1424および長期記憶装置1426は、ダイナミック・ランダム・アクセス・メモリ(DRAM)、ソリッド・ステート・ドライブ(SSD)、ハードディスク、またはそれらの組合せを含んでもよい。
上述のネットワーク構成要素は、それに課される必要な作業負荷をハンドリングするのに十分な処理能力、メモリ資源、およびネットワークスループット能力を有するコンピュータまたはネットワーク構成要素のような、任意の汎用ネットワーク構成要素において実装されてもよい。図15は、本明細書に開示の構成要素の1つまたは複数の実施形態を実装するのに適した一般的な汎用ネットワーク構成要素1500を示す。ネットワーク構成要素1500は、二次記憶装置1504、読出し専用メモリ(ROM)1506、ランダム・アクセス・メモリ(RAM)1508を含むメモリデバイス、入出力(I/O)デバイス1510、およびネットワーク接続デバイス1512と通信しているプロセッサ1502(中央処理装置またはCPUと称する場合がある)を含む。プロセッサ1502は、1つまたは複数のCPUチップとして実装されてもよく、あるいは、1つまたは複数の特定用途向け集積回路(ASIC)の一部であってもよい。
二次記憶装置1504は、一般的には、1つまたは複数のディスクドライブまたはテープドライブからなり、データの不揮発性記憶のために、および、RAM1508がすべての作業用データを保持するほど十分に大きくない場合にはオーバーフローデータ記憶デバイスとして、使用される。二次記憶装置1504は、実行のために選択されるとRAM1508にロードされるプログラムを記憶するのに使用されてもよい。ROM1506は、プログラム実行中に読み出される命令およびおそらくはデータを記憶するのに使用される。ROM1506は、一般的に、二次記憶装置1504のより大きい記憶容量と比較して小さい記憶容量を有する不揮発性メモリデバイスである。RAM1508は、揮発性データを記憶するのに、おそらくは命令を記憶するのに使用される。ROM1506およびRAM1508の両方に対するアクセスは一般的に、二次記憶装置1504よりも速い。
少なくとも1つの実施形態が開示されており、当業者によってなされる実施形態(複数の場合もあり)の変形形態、組合せ、および/もしくは変更形態、ならびに/または実施形態(複数の場合もあり)の特徴は本開示の範囲内にある。実施形態(複数の場合もあり)の特徴を組み合わせ、統合し、および/または省略することから生じる代替的な実施形態も、本開示の範囲内にある。数値範囲または限定が明確に記載されている場合、そのような明確な範囲または限定は、明確に記載されている範囲または限定の中に入る同様の大きさの反復的な範囲または限定を含むものと理解されるべきである(たとえば、約1〜約10は2、3、4などを含み、0.10よりも大きい、は0.11、0.12、0.13などを含む)。たとえば、下限Rlおよび上限Ruを有する数値範囲が開示されているか否かにかかわらず、その範囲内に入るいかなる数字も具体的に開示されている。特に、範囲内の以下の数が具体的に開示されている。R=Rl+k×(Ru−Rl)。式中、kは1パーセント〜100パーセントに及ぶ変数であり、1パーセントずつ増分する。すなわち、kは1パーセント、2パーセント、3パーセント、4パーセント、...、7パーセント、...、70パーセント、71パーセント、72パーセント、...、95パーセント、96パーセント、97パーセント、98パーセント、99パーセント、または100パーセントである。さらに、上記において規定されているように2つのR数によって画定されている任意の数値範囲も具体的に開示されている。特許請求項の任意の要素に対して「任意選択的に(optionally)」という用語が使用されている場合、これは、その要素が必要とされているか、または代替的にその要素が必要とされていないことを意味し、両方の選択肢が特許請求項の範囲内にある。備える(comprises)、含む(includes)、および有する(having)のようなより広い用語が使用されている場合、これは、〜からなる(consisting of)、基本的に〜からなる(consisting essentially of)、および、実質的に〜からなる(comprised substantially of)のようなより狭い用語への支持を提供するものとして理解されるべきである。したがって、保護の範囲は、上記に記載されている説明によって限定されず、以下の特許請求の範囲によって画定され、その範囲は、特許請求の範囲の主題のすべての均等物を含む。あらゆる特許請求項がさらなる開示として本明細書に組み込まれており、特許請求の範囲は本開示の実施形態(複数の場合もあり)である。本開示における引用文献、特に本願の優先日よりも後の刊行日を有する任意の引用文献の考察は、それが従来技術であることを認めるものではない。本開示において引用されているすべての特許、特許出願、および刊行物の開示は、それらが本開示を補助する例示的な、手続き上の、または他の詳細を提供する限りにおいて、参照によって本明細書に援用される。
いくつかの実施形態が本開示において提供されてきたが、開示されているシステムおよび方法は、本開示の精神または範囲から逸脱することなく多くの他の特定の形態において具現化され得ることは理解されるべきである。本発明の実施例は例示とみなされるべきであり、限定ではなく、本明細書において与えられている詳細に限定されることは意図されていない。たとえば、さまざまな要素もしくは構成要素は組み合わされるか、もしくは別のシステムに統合されてもよく、または、特定の特徴は省略されるか、もしくは実装されなくてもよい。
加えて、さまざまな実施形態において個別または別個のものとして説明および例示されている技法、システム、サブシステム、および方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、技法、または方法と組み合わされ、または統合されてもよい。互いに結合もしくは直接的に結合または通信しているものとして図示または説明されている他のアイテムは、それが電気的、機械的、または他の様態であるかにかかわらず、何らかのインターフェース、デバイス、または中間構成要素を通じて間接的に結合または通信していてもよい。変更、置換、および代替の他の例が当業者によって解明可能であり、本明細書に開示されている精神および範囲から逸脱することなくなされ得る。
[関連出願の相互参照]
本願は、Guo Qiang Wang他によって2011年9月1日付けで出願された、「情報中心ネットワークのための一般化デュアルモードデータ転送プレーン(A Generalized Dual−Mode Data Forwarding Plane for Information−Centric Network)」と題する米国仮特許出願第61/530,288号に基づく優先権を主張するとともに、Guo Qiang Wang他によって2012年2月9日付けで出願、「情報中心ネットワークのための一般化デュアルモードデータ転送プレーン(A Generalized Dual−Mode Data Forwarding Plane for Information−Centric Network)」と題する米国仮特許出願第13/369763号に基づく優先権を主張する。これらの特許文献は、その全体を参照によって援用される。