DTN — TCP/IPが通用しない世界のためのネットワーク設計

この回で学ぶこと

前回までの回では、探査機が生成したビット列を、CCSDS Space Packetという構造化された単位に詰め、それを変調・符号化して電波に乗せ、中継アーキテクチャを介して地球まで届けるという、物理層・データリンク層の話を積み重ねてきました。今回からは視点をさらに一段引き上げ、「そもそもこのデータのやり取りを、ネットワークとしてどう設計するか」という問いに向き合います。

私たちが日常使っているインターネットは、TCP/IPというプロトコル群の上に成り立っています。TCPは「送信元から宛先まで、常に(あるいはほぼ常に)エンドツーエンドの経路がつながっていて、遅延はミリ秒〜せいぜい数百ミリ秒程度、パケットロス率も低い」という暗黙の前提の上に設計されています。ところが深宇宙探査機との通信では、この前提のすべてが崩れます。

• 遅延が桁違いに大きい: 光(電波)の伝搬速度は有限であり、地球-火星間ですら往復数十分かかります。
• 接続が断続的: 探査機の自転・公転、周回機の軌道周期、地球局の可視時間の制約によって、通信可能な時間帯はごく限られた「窓」でしかありません。
• パケットロス率が高い: 中継アーキテクチャの回で見たような微弱な信号、太陽電波雑音、掩蔽(occultation)など、地上のデータセンター間通信とは比較にならないほど損失が起きやすい環境です。

この回では、まずTCPがこの3つの条件下でなぜ実用にならないかを定量的に確認します。そのうえで、この問題に対する解として設計されたDTN (Delay/Disruption Tolerant Networking, 遅延耐性・断絶耐性ネットワーキング) の中核をなす Bundle Protocol の仕組み——蓄積転送(store-and-forward)とカストディ転送(custody transfer)——を見ていきます。

直感的導入: 光速の壁と、切れたり繋がったりする回線

まず素朴な感覚から出発しましょう。あなたが地球上でWebサイトを開くとき、サーバーへのリクエストとレスポンスは数十〜数百ミリ秒で往復します。この短い往復時間があるからこそ、TCPは「送って、確認応答(ACK)が来なければすぐ再送する」という単純な戦略で信頼性を確保できます。

しかし火星にいる探査機に「このコマンドを実行してよいか」と尋ね、返事を待つとしたらどうなるでしょうか。電波は光速で進みますが、火星は地球から最も近いときでも約5,460万km、最も遠いときには約4億kmも離れています。この距離を光が渡るだけで、片道十分から二十分以上かかります。往復(ラウンドトリップ)にすればその倍です。

さらに悪いことに、探査機や中継周回機は自転・公転しており、地上局のアンテナも地球の自転とともに動いています。したがって「今この瞬間に通信できるか」は常に保証されているわけではなく、可視時間(パス)の窓が開いているときだけ通信が成立します。中継アーキテクチャの回で見たように、火星周回機とローバーの間のパスは1日に数分〜十数分しかないこともあります。この「窓が開いたり閉じたりする」性質を**断続性(disruption/intermittent connectivity)**と呼びます。

地上のインターネットの設計者は、こうした状況をほとんど想定していませんでした。TCP/IPは「経路は常につながっている」ことを暗黙の前提とし、遅延は「ある程度短く、ほぼ一定」であることを前提としています。この2つの前提が崩れたとき、何が起きるのかを、次節で数式を使って具体的に確認します。

数式的な議論(1): 伝搬遅延を実際に計算する

光速を $c \approx 2.998 \times 10^5\ \text{km/s}$、天文単位を $1\ \text{AU} \approx 1.496\times10^8\ \text{km}$ とします。片道の伝搬遅延(片道光時間、one-way light time)は単純に

$$t_{\text{delay}} = \frac{d}{c}$$

で与えられます。ここで $d$ は地球と探査機の間の距離です。

地球-火星間。 火星は軌道離心率を持つため地球との距離は会合ごとに変動し、最も近いとき(好条件の衝)でおよそ $d_{\min} \approx 5.46\times10^7\ \text{km}$、最も遠いとき(合)でおよそ $d_{\max} \approx 4.01\times10^8\ \text{km}$ になります。それぞれの片道遅延は、

$$t_{\min} = \frac{5.46\times10^7}{2.998\times10^5} \approx 182\ \text{s} \approx 3.0\ \text{分}$$ $$t_{\max} = \frac{4.01\times10^8}{2.998\times10^5} \approx 1338\ \text{s} \approx 22.3\ \text{分}$$

つまり火星が地球から最も遠いとき、コマンドを送ってから探査機に届くまでだけで22分以上かかり、その応答が返ってくるまでの往復時間(RTT)は最大でおよそ

$$\text{RTT}_{\max} = 2\,t_{\max} \approx 2676\ \text{s} \approx 44.6\ \text{分}$$

にも達します。 地上のWebサーバーとの通信が数十ミリ秒で終わることを考えると、これは6桁近くも大きい数字です。

地球-木星間。 木星は地球からさらに遠く、最も近いときでおよそ $d_{\min}\approx5.88\times10^8\ \text{km}$、最も遠いときでおよそ $d_{\max}\approx9.68\times10^8\ \text{km}$ です。同じ計算をすると、

$$t_{\min} = \frac{5.88\times10^8}{2.998\times10^5} \approx 1961\ \text{s} \approx 32.7\ \text{分}, \qquad t_{\max} = \frac{9.68\times10^8}{2.998\times10^5} \approx 3229\ \text{s} \approx 53.8\ \text{分}$$

木星探査機との通信では、片道だけで30分台後半から1時間近くかかることが分かります。往復では実に1時間半〜1時間48分です。これほどの遅延がある環境で、私たちが日常使っているネットワークプロトコルがどう振る舞うかを、次に見ていきます。

数式的な議論(2): TCPの3ウェイハンドシェイクが破綻する

TCPで通信を始めるには、まず3ウェイハンドシェイクが必要です。クライアントがSYNを送り、サーバーがSYN-ACKを返し、クライアントがACKを返してようやく最初のデータを送れます。片道遅延を $d$ とすると、SYN送信からACK到達までに $1.5\,\text{RTT} = 3d$ かかり、しかもこれは「最初の1バイトが送れる」時点にすぎず、そのデータが確かに届いたことをサーバーが確認応答するまでにはさらに $1\,\text{RTT} = 2d$ かかります。

$$T_{\text{handshake}} = \frac{3}{2}\,\text{RTT} = 3d$$

火星が最も遠いとき($d \approx 22.3$分)にこれを当てはめると、

$$T_{\text{handshake}} = 3 \times 22.3\ \text{分} \approx 66.9\ \text{分} \approx 1.1\ \text{時間}$$

接続を確立するためだけに1時間以上かかる計算です。 さらに悪いことに、中継アーキテクチャの回で見た周回機-ローバー間のパスは数分〜十数分しか開いていません。もし通信可能な窓が1回のパスの数分間しかなければ、TCPのハンドシェイクすら1回のパスの中で完了しないという事態が普通に起こり得ます。ハンドシェイクが窓の途中で中断されれば、次のパスが来るまで(場合によっては1火星日近く)最初からやり直しです。

数式的な議論(3): 再送タイムアウトと、遅延がスループットを殺す

仮にハンドシェイクを乗り越えたとしても、次に問題になるのが**再送タイムアウト(RTO, Retransmission Timeout)**です。TCPはRTT(往復時間)を継続的に測定し、その推定値と分散から

$$\text{RTO} \approx \text{SRTT} + 4\times\text{RTTVAR}$$

という形でタイムアウト値を決めます(Jacobson-Karelsのアルゴリズム)。RTTが44分もあれば、RTOもそれに応じて数十分単位になります。パケットが本当に失われたのか、まだ届いていないだけなのかをTCPが判断できるまでに数十分かかるということです。

さらに深刻なのは、TCPがパケットロスを「輻輳(混雑)の兆候」と解釈するという設計上の前提です。深宇宙リンクで起きる損失の大半は、混雑ではなく、探査機の姿勢変化によるアンテナ指向のズレ、太陽電波雑音、掩蔽といった物理的な断絶です。しかしTCPはこれを区別できず、ロスが起きるたびに輻輳ウィンドウを叩き潰し(スロースタートからやり直し)、回復にまた何RTTも要します。

この効果を定量化する古典的な近似式がMathisの式です。定常状態でのTCPスループットの上限は、最大セグメントサイズ $\text{MSS}$、RTT、そしてパケットロス率 $p$ を使って、

$$\text{Throughput} \lesssim \frac{\text{MSS}}{\text{RTT}}\cdot\frac{C}{\sqrt{p}}, \qquad C \approx 1.22$$

と近似できます。ここに、火星が遠いときのRTT($\approx2676$秒)、典型的なMSS(1460バイト $=11680$ ビット)、そして深宇宙リンクとしてはむしろ楽観的な損失率 $p = 0.1\% = 10^{-3}$ を代入してみましょう。

$$\text{Throughput} \approx \frac{11680}{2676}\times\frac{1.22}{\sqrt{10^{-3}}} \approx 4.37 \times \frac{1.22}{0.0316} \approx 4.37\times38.6 \approx 169\ \text{bit/s}$$

物理層のリンク自体は数百kbps〜数Mbpsのデータレートを運べるのに、TCPの輻輳制御アルゴリズムのせいで、理論上のスループットはわずか毎秒169ビットにまで押し潰されてしまうのです。これは、遅延に依存する $1/\text{RTT}$ という因子が、地上の数十ミリ秒に対して深宇宙の数十分では4桁近く小さくなることの直接的な帰結です。TCPを深宇宙リンクにそのまま持ち込むことがいかに非現実的か、この1本の式が物語っています。

Bundle Protocol: 蓄積転送というパラダイム転換

以上の議論から分かるのは、「エンドツーエンドで常時接続を仮定し、失われたら送信元から宛先まで往復して再送する」というTCPの設計思想そのものが、惑星間通信の環境と根本的に相容れないということです。DTNはこの前提を丸ごと捨てて、まったく異なる設計原理を採用します。それが**蓄積転送(store-and-forward)**です。

DTNの基本データ単位はバンドル(bundle)と呼ばれます。バンドルは、宛先アドレス・送信元アドレス・有効期限(lifetime)などの制御情報と、実際のペイロード(応用データ)をひとまとめにした、自己完結的なデータの塊です。この考え方を定めた仕様がBundle Protocolで、CCSDSではCCSDS 734.2-B(Bundle Protocol Specification)として標準化されています。もともとはIETFのDTN研究グループ(DTNRG)が策定した仕様に遡り、2007年にRFC 5050(Bundle Protocol Version 6)として発表された後、2022年に改訂版のRFC 9171(Bundle Protocol Version 7)が発行されました。CCSDSの734.2-BはこのIETF仕様と整合を取りながら、宇宙運用向けのプロファイルを規定しています。

Bundle Protocolを支える設計思想は、次のように要約できます。

経路上のどのノードも、次のホップへ確実に転送できる見込みが立つまで、バンドルを自分のローカルストレージに保持し続けてよい(むしろ、そうすべきである)。

これは地上のルータの振る舞いとは根本的に異なります。地上のIPルータは基本的に「今すぐ転送できないパケットは捨てる」という前提で動いており、長時間のバッファリングは想定されていません。DTNのノードは逆に、転送できないなら、転送できる瞬間まで持っておくことを積極的な設計原理として組み込んでいます。

郵便システムとの類比

この発想は、実は目新しいものではありません。近代的な郵便システムを考えてみてください。あなたが投函した手紙は、宛先まで直接運ばれるわけではありません。まず最寄りの郵便局に一時保管され、地域の集配センターへ運ばれ、そこでまた次の中継地点への便が来るまで保管され……というように、**複数の中継局を経由しながら、そのつど「一時的に保管され、次の便のタイミングで転送される」**という形で届きます。差出人と受取人の間に「常時開通した専用回線」がある必要はなく、各中継局が自分の持ち場の範囲で責任を持って次へ渡せば、全体として手紙は届きます。

Bundle Protocolのノードは、まさにこの「郵便局」の役割を果たします。あるノードが次のホップへの回線が(まだ)開いていなくても、それは異常事態ではなく想定内の状態であり、回線が開くタイミング(次の周回機のパス、次に可視になる地上局など)を待ってバンドルを転送すればよいのです。

カストディ転送: 責任のバケツリレー

蓄積転送だけでは、まだ1つ問題が残ります。「途中のノードにバンドルを渡した送信元は、いつ自分の手元のコピーを消してよいのか」という問題です。もし何も保証がなければ、送信元は宛先に届いたという確証が得られるまで、永遠にコピーを保持し続けなければなりません。これでは送信元のストレージがいずれ枯渇してしまいますし、そもそも宛先までの確認応答には(TCPと同じ理屈で)往復数十分〜数時間がかかってしまいます。

これを解決するのが**カストディ転送(custody transfer)**という考え方です。基本的な発想は、

中継ノードが「このバンドルの責任(custody)を引き受けた」ことを明示的に確認応答し、それを受け取った前のノード(直前のカストディアン)は、自分のバッファを解放してよい。

というものです。バンドルを受け取ったノードが「自分がこのバンドルのカストディアンになった」という受諾信号(custody acceptance)を送り返すと、それを受け取った送信側ノードは安心して自分のコピーを削除できます。もし一定時間内にこの受諾信号が届かなければ、送信側ノードはローカルに(つまりそのノードから直前のホップまでの、短い伝搬遅延の範囲で)再送すればよく、送信元まで遡って全経路を再送信し直す必要はありません。

これを定量的に整理すると、次のようになります。ある経路が $n$ 個のホップからなり、$i$ 番目のホップの片道伝搬遅延を $d_i$ とします。TCPのようなエンドツーエンド確認応答方式では、途中のどこかでバンドルが失われた場合、その検知と再送の往復には経路全体の遅延の合計がかかります。

$$T_{\text{recover, end-to-end}} \sim 2\sum_{i=1}^{n} d_i$$

これに対しカストディ転送では、損失が起きたホップのその場で再送が完結するため、

$$T_{\text{recover, custody}} \sim 2\, d_j \qquad (j:\ \text{損失が起きたホップ})$$

で済みます。ホップ数が増えるほど、あるいは遠方のホップほど遅延が大きい多段中継網であるほど、この差は劇的に広がります。この「責任を細かく分割し、各区間で独立に信頼性を確保する」という発想が、往復数十分の遅延を持つ環境でも実用的な信頼性を実現するDTNの核心です。ただし、後継仕様のRFC 9171(BPv7)では、カストディ転送は基本仕様から拡張ブロックや下位の収束層プロトコルの機能に委ねる形へと整理されましたが、「途中のノードが責任を引き受け、送信元がバッファを解放できる」という設計思想そのものは、DTNアーキテクチャの根幹として今も生き続けています。

実務での使われ方

ION (Interplanetary Overlay Network)

NASA/JPLが開発したIONは、Bundle Protocolを含むDTNプロトコル群のオープンソース実装です。IONにはBundle Protocolに加えて、長遅延・高損失リンク向けの収束層(convergence layer)プロトコルであるLTP (Licklider Transmission Protocol、CCSDS 734.1-Bとして標準化)や、ファイル転送を担うCFDP (CCSDS File Delivery Protocol)、そして探査機や中継局の可視時間があらかじめ軌道力学から予測できることを利用して経路を計算する**Contact Graph Routing (CGR)**が含まれます。CGRは「このリンクは何時何分から何時何分まで開いている」という接触スケジュール(contact plan)を事前に与えられ、時間とともに変化するネットワークトポロジーの中で最適な転送タイミングを計算するという、地上のルーティングとは根本的に異なるアプローチを取ります。

DTNプロトコル群の宇宙での初の実証は、2008年にNASA/JPLが実施したDINET (Deep Impact Networking)実験です。彗星探査機ディープ・インパクト(のちのEPOXI)を深宇宙ノードに見立て、地球から約8000万km離れた状態で、シミュレートされた複数ノードの深宇宙ネットワーク越しに画像データをBundle Protocolで蓄積転送させることに成功しました。

国際宇宙ステーションでの実運用

国際宇宙ステーション(ISS)は、地上局やTDRSとの通信リンクが周回のたびに繋がったり切れたりする、まさに断続的接続の典型例です。NASAはISS上でDTNの実証実験を重ねたのち、2016年以降、ISSの運用系データ配送の一部にBundle Protocolを用いたDTNの実装を組み込み、継続的に運用してきました。これは、DTNが単なる理論上の提案ではなく、実際に人が乗る有人宇宙機の日常運用を支える技術として実績を積んできたことを示しています。

将来の月面・火星通信網

近年本格化している月探査では、NASAが提唱するLunaNet構想において、DTNのBundle Protocolが複数の中継衛星・月面拠点・地球局を結ぶ通信基盤の中核に据えられています。月面から見て中継衛星が地平線の下にいる時間帯や、月の裏側にいる時間帯が周期的に生じるため、中継アーキテクチャの回で見たStore-and-Forwardの必要性は、火星以上に本質的です。同様に、将来の火星通信網構想でも、複数の周回機・着陸機・ローバーが折り重なるように断続的な接続を提供する多ノードのネットワークを、DTNのアーキテクチャで統一的に扱うことが検討されています。DTNはもともと1998年頃、“父”と呼ばれるインターネットの設計者の一人ヴィントン・サーフ(Vint Cerf)らがJPLで進めた「InterPlaNetary Internet」構想に端を発しており、その名の通り、惑星間をまたぐインターネットそのものを作るという野心的な問題意識から生まれた技術です。

演習問題

1. 土星は地球からおよそ $d_{\min}\approx1.2\times10^9\ \text{km}$(最も近いとき)、$d_{\max}\approx1.66\times10^9\ \text{km}$(最も遠いとき)離れています。本文の式 $t_{\text{delay}}=d/c$($c\approx2.998\times10^5\ \text{km/s}$)を使って、それぞれの片道伝搬遅延を分単位で計算してください。また往復(RTT)にすると何時間になるか求めてください。

2. ある周回機とローバーの間のパス(可視時間)が1回あたり6分しかないとします。RTTが44分の地球-探査機間の直接リンクでTCPの3ウェイハンドシェイクを行おうとした場合($T_{\text{handshake}}=1.5\,\text{RTT}$)、1回のパスの中でハンドシェイクを完了できるか判定してください。またこの結果が意味することを、DTNの蓄積転送の必要性と結びつけて説明してください。

3. Mathisの式 $\text{Throughput}\approx(\text{MSS}/\text{RTT})\times(C/\sqrt{p})$($C\approx1.22$)を使い、RTT $=2676$ 秒、MSS $=1460$ バイト($=11680$ ビット)の条件で、パケットロス率が $p=1\%$($=10^{-2}$)の場合のTCPスループット上限を求めてください。本文中で計算した $p=0.1\%$ の場合の結果(約169 bit/s)と比較し、損失率がスループットにどれだけ敏感に効くかを論じてください。

4. カストディ転送が「損失発生ホップでの局所的な再送」を可能にすることで、エンドツーエンドの再送に比べて回復時間を短縮できる理由を、本文中の $T_{\text{recover, end-to-end}}\sim2\sum_i d_i$ と $T_{\text{recover, custody}}\sim2d_j$ の比較を踏まえて、多段中継のネットワーク(たとえば地球-火星周回機-火星ローバー-さらに火星表面の別ノード、という3ホップ以上の経路)を具体例に説明してください。

まとめと次回予告

地上のインターネットが前提とする「常時接続・低遅延・低損失」は、惑星間通信の環境ではことごとく成り立ちません。光速という物理的な壁により地球-火星間の往復遅延は最大で45分近くに達し、TCPの3ウェイハンドシェイクや再送タイムアウトの仕組みはこの遅延の中でまともに機能せず、Mathisの式が示す通りスループットも実用に耐えないレベルまで落ち込みます。DTNはこの問題に対し、「常時接続を仮定しない」という発想の転換で応えます。バンドルという自己完結的な単位でデータを扱い、次ホップへの回線が開くまでノードがローカルにデータを蓄積し続けるstore-and-forwardアーキテクチャと、中継ノードが責任を引き受けたことを確認応答することで送信元のバッファを解放できるカストディ転送の考え方によって、断続的にしか繋がらないネットワークの上でも信頼性のあるデータ配送を実現しています。NASAのIONはこの思想を実装したソフトウェアとしてISSで実運用されており、将来のLunaNetや火星通信網の設計にも組み込まれつつあります。

次回は、CCSDSがデータ配送のもう1つの層として整備しているSLE (Space Link Extension) に軽く触れます。SLEは、地上局が受信したフレームデータを、実際にミッション運用センターまでネットワーク越しに届けるためのプロトコル群であり、DTNが探査機と地球の間の「宇宙リンク」の断続性を扱うのに対し、SLEは地上局とミッション運用センターの間の「地上ネットワーク」でのデータ配送を標準化するという、また別の層の相互運用性を担っています。

参考文献

• CCSDS 734.2-B-1, CCSDS Bundle Protocol Specification
• CCSDS 734.1-B-1, CCSDS Licklider Transmission Protocol (LTP) for CCSDS
• IETF RFC 9171, Bundle Protocol Version 7
• IETF RFC 5050, Bundle Protocol Specification (Version 6, 歴史的仕様)
• K. Fall, “A Delay-Tolerant Network Architecture for Challenged Internets,” Proceedings of ACM SIGCOMM, 2003
• S. Burleigh et al., “Delay-Tolerant Networking: An Approach to Interplanetary Internet,” IEEE Communications Magazine, 2003
• M. Mathis, J. Semke, J. Mahdavi, T. Ott, “The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm,” ACM SIGCOMM Computer Communication Review, 1997
• NASA/JPL, Interplanetary Overlay Network (ION) Design and Operation Documentation
• J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76