ネットワーク・プロトコル#158

Named Data Networking — 「どこに送るか」ではなく「何が欲しいか」で通信するネットワーキング

IPもBundle Protocolも、根底では「宛先ノードのアドレス」を前提にしていた。情報指向ネットワーキング(ICN)の代表格であるNamed Data Networking(NDN)は、宛先ではなく「欲しいデータの名前」そのものを要求するという全く異なる通信モデルを提案する。InterestとDataという2種類のパケット、そして経路上のキャッシュ(Content Store)がDTN環境や惑星表面の編隊探査とどう噛み合うのかを、研究段階の技術として正直に位置づけながら理解する。

前提知識: IP over CCSDS — 宇宙リンクの上でインターネットプロトコルそのものを走らせる

NDNICN情報指向ネットワーキングDTNキャッシュ

この回で学ぶこと

IP over CCSDSの回では、CCSDS独自のプロトコル体系とは別に、地上のインターネットが使うIP(Internet Protocol)そのものを宇宙リンクに持ち込むという選択肢を見ました。そこで強調したのは、IP over CCSDSであっても、Space Packetによる従来のCCSDS方式であっても、通信の基本単位は「宛先(あるいは送信元)ノードのアドレスを指定して、そのノードにパケットを届ける」という発想の上に成り立っている、という点でした。IPアドレスにせよAPIDにせよ、あるいはDTNのBundle Protocolが使うエンドポイントID(EID)にせよ、「このデータは、あの特定のノードに向かうものだ」という場所(ロケーション)の指定が通信の出発点になっていることに変わりはありません。

この回で扱う情報指向ネットワーキング(ICN: Information-Centric Networking)、その代表的な実現形である**Named Data Networking(NDN)**は、この前提そのものをひっくり返します。NDNの世界では、通信の出発点は「誰に送るか」ではなく「何が欲しいか」です。ネットワークに向かって「この名前のデータをください」と要求を投げ込み、その名前に合致するデータを持っているノードが(それが元の発信源であろうと、途中でたまたまキャッシュを持っていた中継ノードであろうと)応答すればよい、という設計です。IPが「場所指向(location-centric)」であるのに対し、NDNは文字通り「データ指向(data-centric)」です。

この回では、まずNDNの基本的な通信モデル——InterestパケットとDataパケットという2種類のパケット、そして経路上のノードが持つContent Storeによるキャッシュの仕組み——を整理します。そのうえで、なぜこの発想がDTNの回で学んだ遅延耐性ネットワークと相性が良いのか、そして惑星表面や編隊飛行を行う探査機群でどのような効率化の可能性があるのかを見ていきます。最後に、NDNが現時点でどこまで実用段階にあり、どこから先が研究段階なのかを、誇張せずに整理します。

直感的導入: 「あの人に届けて」ではなく「これをください」

具体例で考えてみましょう。あなたが図書館で本を探しているとします。

場所指向のやり方は、こうです。「3階の書架、B列、17番目の棚、左から5冊目」という住所を誰かに教えてもらい、その住所へ直接向かい、そこにある本を受け取ります。もしその本が貸し出し中で棚になければ、あなたは空振りです。同じ本が実は1階の返却待ちワゴンに一時的に置かれていたとしても、あなたはそれを知る術がありません。「特定の場所」だけを頼りにしているからです。

データ指向のやり方は、こうです。「『銀河鉄道の夜、宮沢賢治』という本をください」と司書に尋ねます。司書は、その本が3階の書架にあろうと、返却ワゴンにあろうと、あるいは同僚が机の上に一時的に置いていようと、「その名前の本」を持っている場所を見つけてあなたに渡してくれます。あなたが気にしているのは本の住所ではなく、本の**中身(タイトル)**そのものです。

IPやBundle Protocolが提供してきたのは前者、「特定の住所に向かう」という仕組みでした。NDNが提供するのは後者、「欲しいものの名前を言えば、ネットワークのどこかにいる誰かがそれを届けてくれる」という仕組みです。この違いは些細な言い換えではなく、パケットの構造から経路上のノードが持つべき状態まで、ネットワークの設計原理そのものを変えてしまうほど本質的な違いです。

NDNの基本モデル: InterestとDataという2種類のパケット

NDNのネットワークを流れるパケットは、たった2種類しかありません。

Interest(関心パケット): 「この名前のデータが欲しい」という要求。中心となるフィールドはName(欲しいデータの階層的な名前、たとえば/mars/msl/navcam/sol/3421/frame/0012のようにスラッシュ区切りの階層構造を持つ)と、経路上でのループ検出に使うNonceです。IPパケットのヘッダにあった送信元アドレス・宛先アドレスに相当するフィールドは、NDNのInterestには存在しません。
Data(データパケット): Interestで要求された名前そのものと、実際のコンテンツ本体、そしてそのコンテンツの生成者による**署名(Signature)**をひとまとめにしたパケット。

Interestに宛先アドレスがないという点が、この設計の核心です。ではNDNのノード(フォワーダと呼びます)は、どうやって「どちらの方向にInterestを転送すればよいか」を判断するのでしょうか。各ノードは次の3つのデータ構造を持つことで、これを実現します。

データ構造	役割	IP/DTNでの類似物
FIB (Forwarding Information Base)	名前の接頭辞(プレフィックス)ごとに、どのインタフェース(face)へ転送すべきかを記録	IPのルーティングテーブル、Bundle ProtocolのContact Graph Routing
PIT (Pending Interest Table)	まだ応答(Data)が返ってきていないInterestについて、「どのインタフェースから要求が来たか」をパンくずのように記録	直接の類似物はない(TCPのコネクション状態に近いが、宛先ではなく名前ごとに管理される)
CS (Content Store)	過去に転送したDataパケットのキャッシュ	Webプロキシのキャッシュ、CDNのエッジキャッシュ

Interestを受け取ったフォワーダの処理は、次の順序で行われます。

CS参照: 要求された名前に一致するDataを自分のContent Storeにすでに持っていれば、その場でDataを送り返す。上流(発信源側)には一切転送しない。
PIT参照: 同じ名前へのInterestがすでにPITに記録されている(=誰かがすでに同じものを問い合わせ中)なら、新しく要求してきたインタフェースをそのPITエントリに追記するだけで、上流への転送は行わない(Interest集約)。
FIB参照: どちらにも該当しなければ、FIBを参照して名前の接頭辞に一致するインタフェースへInterestを転送し、「このインタフェースから要求が来た」という記録をPITに新規作成する。

そしてDataパケットが(発信源から、あるいは途中のキャッシュから)返ってきたときの処理は、この逆をたどります。

Dataの名前に一致するPITエントリを探す。
そのPITエントリに記録されているすべてのインタフェースへDataを転送する(1回のInterest集約で複数のノードから要求されていた場合、まとめて全員に届く)。
自分のContent StoreにこのDataをキャッシュとして保存する。
使い終わったPITエントリを削除する。

重要なのは、この一連の手順のどこにも「宛先アドレス」が登場しないことです。Dataがどこへ戻っていくかは、PITというパンくず(breadcrumb)——「さっきこの名前のInterestがどこから来たか」という記録——だけによって決まります。往路(Interest)がたどった経路を逆にたどってDataが返る、という対称的な転送モデルが、アドレスなしで成立しているのです。

定式化1: 名前の階層構造と最長一致転送

NDNの名前は、IPアドレスのようなビット列ではなく、/で区切られた階層的なコンポーネントの列として表現されます。名前 $N$ を

N = (c_1, c_2, \dots, c_k)

というコンポーネントの順序付き列だとします(たとえば/mars/msl/navcam/sol/3421なら $c_1=\texttt{mars}$ 、 $c_2=\texttt{msl}$ 、……)。FIBとPITの検索は、この名前に対して**最長一致(Longest Prefix Match, LPM)**で行われます。すなわち、要求された名前 $N$ に対して、FIBに登録されている接頭辞の集合 $\{P_1, P_2, \dots\}$ の中から

P^{*} = \arg\max_{P_i \,:\, P_i \text{ は } N \text{ の接頭辞}} \; |P_i|

を満たす、 $N$ の接頭辞になっている中で最も長い(=最も具体的な)登録済み接頭辞 $P^{*}$ を選び、それに対応するインタフェースへ転送します。

これはIPのCIDR(Classless Inter-Domain Routing)における最長プレフィックスマッチと、アルゴリズム上の見た目はよく似ています。しかし両者が集約している意味はまったく異なります。IPのプレフィックス集約は「同じネットワーク経路上にある、地理的・トポロジ的に近いアドレスの集まり」を1つのエントリにまとめる、場所(トポロジ)の集約です。これに対しNDNの名前接頭辞は、「同じ探査機・同じ観測機器・同じ種類のデータ」といったコンテンツの意味的な階層構造を表しており、そのデータが物理的にどのノードにあるかとは独立に定義できます。/mars/msl/navcam/...という名前は、そのデータが火星にあるMSLローバーの搭載メモリにあるのか、地球のミッション運用センターのアーカイブにあるのか、あるいは途中の中継周回機のContent Storeにたまたまキャッシュされているのかを一切問いません。名前空間の設計は、ネットワークのトポロジ設計から切り離されているというのが、NDNのアドレッシングモデルの本質的な特徴です。

定式化2: キャッシュが遅延と帯域消費を削減する仕組み

Content Storeによるキャッシュがどれだけの効果を持つかを、簡単なモデルで定量化してみましょう。ある惑星表面に、共通の観測対象(たとえば特定のクレーターの分光データ)に関心を持つ探査機・ローバーが $N$ 台配置されており、それぞれが同じ名前 $\eta$ のデータを要求する状況を考えます。

このデータの発信源(たとえば軌道上の周回機、あるいはそれを経由してさらに地球)までの経路のホップ数を $H_{\text{src}}$ 、探査機群の近傍にいる中継ノード(周回機や、たまたま先にそのデータを取得して保持しているローバー)までのホップ数を $H_{\text{cache}}$ とします。当然、近傍にキャッシュがある場合は $H_{\text{cache}} \ll H_{\text{src}}$ です。

$N$ 台のうち、最初にそのデータを要求する1台は、キャッシュがまだどこにも存在しないため、必ず発信源まで到達するInterestを送らねばなりません。しかし残りの探査機がその後(データのキャッシュ有効期限が切れる前に)同じ名前 $\eta$ を要求すれば、途中の中継ノードのContent Storeがすでにヒットを返せる可能性があります。ある探査機の要求が「すでに誰かの通過によってキャッシュ済みの状態に間に合う」確率を $q$ とすると、1台あたりの期待ホップコストは

\mathbb{E}[H] = (1-q)\, H_{\text{src}} + q\, H_{\text{cache}}

となり、 $N$ 台合計での期待総ホップコストは

\mathbb{E}[H_{\text{total}}] = N \cdot \mathbb{E}[H] = N\big[(1-q) H_{\text{src}} + q H_{\text{cache}}\big]

です。キャッシュがまったく機能しない極端なケース( $q=0$ 、つまり全ノードがキャッシュなしのIP的世界と同じように毎回発信源まで問い合わせる)と比較すると、削減効果は

\Delta H = N H_{\text{src}} - \mathbb{E}[H_{\text{total}}] = Nq\,(H_{\text{src}} - H_{\text{cache}})

で与えられます。この式から読み取れる重要な性質は2つあります。第一に、削減効果は要求する探査機の台数 $N$ に比例して大きくなる——編隊が大きいほど、あるいは同じ関心対象を持つノードが多いほど、キャッシュの恩恵は増します。第二に、削減効果は $H_{\text{src}} - H_{\text{cache}}$ 、すなわち発信源までの距離とキャッシュまでの距離の差が大きいほど効きます。地上のCDN(コンテンツ配信網)でキャッシュが効くのも同じ理屈ですが、宇宙リンクではこの「ホップコスト」が単なる遅延ではなく、帯域幅・送信電力・可視時間窓という物理的制約そのものに直結するため、削減効果の意味がより切実です。地球までの往復にホップを費やさずに済むということは、その分だけ限られたダウンリンク容量を他の観測データに回せる、ということを意味します。

なぜDTN環境と相性が良いのか: 「いつ」に加えて「誰が」も問わない

DTNの回で見たBundle Protocolは、「常時接続を前提としない」という点で画期的でした。蓄積転送(store-and-forward)とカストディ転送によって、通信のタイミング——いつ次のホップへ転送できるか——について、TCP/IPのような即時性を要求しない設計になっていました。しかしBundle Protocolも、バンドルには依然として**宛先のエンドポイントID(EID)を記載します。「このバンドルは、いつか届けばよいが、最終的には特定のあのノードに届けるべきものだ」という、宛先ノードのidentity(身元)**そのものは指定し続けているのです。

NDNのInterestパケットには、そもそもそのような宛先の身元が存在しません。要求しているのは名前 $\eta$ が指すデータであって、それがどのノードから届くかは問いません。この違いを整理すると、次のようになります。

	IP / IP over CCSDS	DTN (Bundle Protocol)	NDN
通信の単位が指定するもの	宛先ノードのIPアドレス	宛先ノードのエンドポイントID(EID)	欲しいデータの名前
前提とする接続性	ほぼ常時接続(エンドツーエンド経路が今、成立している)	断続的でよい(いつか経路が繋がれば届く)	断続的でよい、かつ経路の相手が誰かも問わない
満たすべき相手	指定した宛先ノード、そのもの	指定した宛先ノード、そのもの(届くタイミングは柔軟)	名前に一致するデータを持つ任意のノード
解決している問題	—	「いつ」問題(遅延・断絶耐性)	「いつ」問題 + 「誰が」問題(データの出所の柔軟性)

つまりDTNは「宛先は決まっているが、届くタイミングは柔軟でよい」という時間軸の結合を緩めた設計でした。NDNはそれに加えて、「そもそも宛先という身元を固定しない」という相手軸の結合まで緩めています。断続的にしか繋がらない宇宙リンクで、探査機Aと探査機Bのどちらが先に目的のデータに到達するか、あるいはどの周回機が最初にそのデータを地球から持ち帰ってくるかが事前には分からない状況では、「特定のノードへの到達」を前提にしないこの緩やかな結合は、DTNの発想の延長線上として自然に噛み合います。**「そのデータを持っているノードに、たまたま接触した瞬間に、それが得られればよい」**という要求は、断続的な接続性そのものと相性が良いのです。

もっとも、この柔軟性には代償もあります。IPやBundle ProtocolのDataは「送信元は正しいはずだ」という通信路(チャネル)の信頼に依存して安全性が保たれてきましたが、NDNではデータがどの経路・どのキャッシュ経由で届くか分からないため、Dataパケットそのものに生成者の署名を含める**データ中心のセキュリティ(data-centric security)**が必須の設計要素になっています。誰から届いたデータであっても、署名を検証すれば真正性を確認できるという設計は、経路が予測できないNDNの世界では単なるオプションではなく、成立の前提条件です。

実務での使われ方

NDNそのものの研究基盤。 Named Data Networkingは、2010年に米国国立科学技術財団(NSF)が立ち上げたFuture Internet Architecture(FIA)プログラムで採択された5つの将来インターネットアーキテクチャ研究プロジェクトの1つとして本格的に開始されました。そのルーツは、PARC(Palo Alto Research Center)のVan Jacobsonが2006年に提唱したContent-Centric Networking(CCN)にさかのぼり、V. Jacobson et al., Networking Named Content(ACM CoNEXT, 2009)がその基礎理論を確立した論文として広く引用されています。UCLAのLixia Zhangらを中心とするNDN Projectはその後2015年からNDN-NP(Named Data Networking – Next Phase)として継続され、L. Zhang et al., Named Data Networking(ACM SIGCOMM Computer Communication Review, 2014)がアーキテクチャの全体像を要約した代表的なサーベイ論文になっています。地上のインターネット上には、世界中の大学・研究機関が参加するNDN Testbedが2010年代から運用され続けており、動画配信・IoT・車車間通信など、宇宙以外の応用分野での実証実験が積み重ねられてきました。標準化に関しては、IRTF(Internet Research Task Force)のICNRG(Information-Centric Networking Research Group)が、ICN全般のベースラインシナリオ(RFC 7476)やCCNxのセマンティクス・メッセージ形式(RFC 8569, RFC 8609)を整理していますが、これらはあくまでIETFの標準化トラックに入る前の研究成果としてのRFCであり、地上のインターネットにおいてすら、NDN/ICNはIPを置き換える実用インフラとしてではなく、研究・実証段階の技術として位置づけられています。

宇宙応用の現在地。 率直に言えば、NDN・ICNの宇宙応用は、この回で扱ってきたIP over CCSDSやDTNのBundle Protocolと違い、実際のミッションで運用された実績を持つ標準ではありません。CCSDSにおいてNDN/ICNを正式に規定する勧告(Blue Book)は現時点で存在せず、あくまで学術コミュニティによる概念検証・シミュレーション研究の段階にとどまります。とはいえ、DTNとICNを組み合わせる方向性への関心自体は確かに存在しており、たとえば「遅延耐性情報指向ネットワーキング(DTICN: Delay-Tolerant Information-Centric Networking)」という名称で、DTNの蓄積転送とICNの名前ベース要求を融合させるアイデアが特許出願の形でも見られるなど、民間・研究の両方でこの交差点への関心がうかがえます。惑星探査における具体的な応用像としては、この回で見たように、複数の探査機・ローバーが同じ科学的関心対象のデータを求める編隊探査や、月・火星表面に複数の拠点が展開される将来のシナリオにおいて、地球まで毎回問い合わせずに近傍のノードから直接データを得られる可能性が、研究レベルで議論され始めている段階です。したがってこの回の内容は、すでに実運用されている技術というより、DTNが10年以上前に歩んだのと同じ「地上のネットワークアーキテクチャ研究が、宇宙という極限環境への応用可能性を模索し始めている」フェーズにある技術として理解しておくのが適切です。

演習問題

ある惑星表面の編隊に $N=6$ 台のローバーが配置されており、共通の名前 $\eta$ のデータを要求するとします。発信源(周回機経由で地球)までのホップコストが $H_{\text{src}}=40$ 、近傍の中継ノードのContent Storeにキャッシュされている場合のホップコストが $H_{\text{cache}}=3$ だとして、キャッシュヒット確率 $q=0.7$ のときの期待総ホップコスト $\mathbb{E}[H_{\text{total}}]$ と、キャッシュがまったく機能しない場合( $q=0$ )との削減量 $\Delta H$ を計算してください。
NDNのFIB検索が採用する最長一致(Longest Prefix Match)は、IPのCIDRにおける最長プレフィックスマッチとアルゴリズムの見た目は似ていますが、集約している対象の性質が本質的に異なります。本文中の説明を踏まえ、IPのプレフィックス集約とNDNの名前接頭辞集約が、それぞれ何を基準にデータをグループ化しているかを対比して説明してください。
DTNの回で学んだBundle Protocolは、宛先ノードのエンドポイントID(EID)を指定しつつ、届くタイミングの柔軟性で断続的な接続性に対応していました。これに対しNDNのInterestパケットは宛先の身元そのものを指定しません。この違いが、「複数の探査機のうちどれが最初に目的のデータへ到達するか事前に分からない」という状況で、なぜNDNの方がより自然に対応できるのかを、本文中の表を参考にしながら自分の言葉で説明してください。
NDNのDataパケットには生成者による署名が必須の要素として含まれています。IPパケットやSpace Packetには、これに相当する「ペイロードそのものへの署名」が必須要素として含まれていません。なぜNDNではこれが必須になるのか、経路上のどのノードからDataが届くか事前に分からないという設計上の特徴と結びつけて説明してください。

まとめと次回予告

Named Data Networkingは、IPやBundle Protocolが前提としてきた「宛先ノードのアドレス(あるいはエンドポイントID)を指定する」という通信モデルを離れ、「欲しいデータの名前」そのものを要求するという、まったく異なる発想の情報指向ネットワーキングでした。InterestとDataという2種類のパケット、そしてFIB・PIT・Content Storeという3つのデータ構造によって、宛先アドレスなしに双方向の通信が成立する仕組みを見ました。この「特定のノードへの到達を前提としない」という緩やかな結合は、DTNが「いつ」の柔軟性を提供したのに加えて「誰から」の柔軟性まで提供するものであり、断続的な接続性を持つ宇宙リンクや、複数の探査機が同じデータに関心を持つ編隊探査のシナリオと理論的には自然に噛み合います。ただし、NDN/ICNの宇宙応用はCCSDSでの標準化には至っておらず、あくまで学術研究の段階にある技術だという位置づけを、正直に押さえておく必要があります。

次回は、これまで見てきたCCSDS独自の階層(Space Packet、Space Data Link Protocol)と、地上のインターネットが採用するOSI参照モデルという、2つの異なる「プロトコル階層の設計思想」を比較します。なぜCCSDSはOSIの7層モデルをそのまま採用せず、独自の階層を作り上げたのか、その設計判断の背景に軽く触れます。

参考文献

V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, R. L. Braynard, Networking Named Content, Proceedings of ACM CoNEXT, 2009
L. Zhang, A. Afanasyev, J. Burke, V. Jacobson, k. claffy, P. Crowley, C. Papadopoulos, L. Wang, B. Zhang, Named Data Networking, ACM SIGCOMM Computer Communication Review, vol. 44, no. 3, 2014
IRTF RFC 7476, Information-Centric Networking: Baseline Scenarios
IRTF RFC 8569 / RFC 8609, Content-Centric Networking (CCNx) Semantics / Messages
CCSDS 734.2-B-1, CCSDS Bundle Protocol Specification(本回との対比対象)
V. Cerf et al., Delay-Tolerant Networking Architecture, RFC 4838
G. Xylomenos et al., A Survey of Information-Centric Networking Research, IEEE Communications Surveys & Tutorials, 2014