以前の記事で、TCP/IP は「常時接続」と「低遅延」を前提としているため、宇宙空間では実用的ではないという記載をしました。

その解決策の一つとして実装されているのが、
DTN (Delay/Disruption Tolerant Networking)
というアーキテクチャです。

今回は、この技術の仕組みについて調べてみました。

1. Store-and-Forward (蓄積交換)

DTN の基本的な考え方は、「Store-and-Forward（蓄積交換）」です。

インターネット（TCP/IP）の世界では、ルーターはパケットを受け取ると、基本的にはすぐに次のルーターへ転送します（Forward）。
宛先が見つからなかったり、バッファが溢れたりすると、パケットは破棄（Drop）されます。「届かなければ再送すればいい」という考え方ですね。

一方、DTN では「次の通信相手が見つかるまで、データをストレージに保存して待つ（Store）」という動作をします。

イメージとしては、バケツリレーに近いです。

このように、エンドツーエンド（端から端まで）が同時に繋がっていなくても、時間をかけて運んでいく仕組みです。

2. IP パケットから Bundle へ

この通信において、データの配送単位となるのが「Bundle (バンドル)」です。

TCP/IP では、大きなデータを小さな「パケット」に分割して送りますが、宇宙では一つ欠けた時の再送コストが非常に高いです。

Bundle Protocol (BP) では、アプリケーションが送りたいデータと、それを届けるために必要なメタデータ（宛先、寿命など）をひとまとめ（Bundle）にします。
そして、この Bundle を単位として、ストア＆フォワードを行います。

Bundle Protocol は、IP などの下位層を問わない「オーバーレイネットワーク」として動作します。

これらを、Bundle という共通の形式で乗り継いでいくイメージです。

地球上のWebシステムでは、TTL (Time To Live) の単位として「秒」が使われますが、ここでもTTLは秒のようです。ただし、設定値として、数時間から、場合によっては数日という長期間が想定されているようです。（TCP/IPのTTLというのは別の意味合いがあるようですが、ここでは割愛）

「このデータは重要だから、火星から地球に届くまで 1 週間は中継ノードで保持し続けてほしい」
といった指定をするイメージです。

DTN と Bundle Protocol は、
「通信はいつでも切れる」「遅延は避けられない」
という前提を受け入れた上で設計されています。

Web 開発の世界では「リアルタイム性」が重視されがちですが、宇宙のプロトコルは逆に「非同期処理」を実現するものでした。
環境が変われば、最適なアーキテクチャも変わるという良い例ですね。

次回は、これらの技術が目指す「惑星間インターネット構想」について触れたいと思います。