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

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

SpacePacketやTM/TCフレームというCCSDS独自の体系とは別に、地上のインターネットが使うIPそのものを宇宙リンクに持ち込む試みがある。Encapsulation Service(CCSDS 133.1-B)によるカプセル化の仕組みと、UDPベースの軽量ファイル転送プロトコルSaratogaを、オーバーヘッドの定量評価とCFDPとの対比から理解する。

前提知識: SCPS — TCP/IPを宇宙リンクに適応させた通信プロトコル群

IPCCSDSSaratogaカプセル化プロトコル設計

この回で学ぶこと

SCPSの回では、地上のTCP/IPスイートを「宇宙リンク用に改造する」というアプローチを見ました。SCPS-TPはTCPのウィンドウ制御や輻輳制御をチューニングし直したものでしたが、あくまで土台にあるのはTCP/IPというプロトコルモデルそのものでした。一方、Space PacketやSpace Data Link Protocol、CFDPといったこれまで学んできた仕組みは、地上のTCP/IPとはまったく別の系譜——CCSDSが宇宙データシステムのために独自に設計したプロトコル体系——に属しています。APIDによる送信元識別、フレームによる多重化、NAKベースの選択的再送。これらはどれもIPやTCPとは異なる語彙で作られた、宇宙リンク専用の道具立てでした。

しかし宇宙機関の中には、この2つの系譜を統合しようとする、もう一つの流れがあります。それがIP over CCSDS、すなわち「CCSDS独自のプロトコルを経由せず、地上のインターネットで使われているIP(Internet Protocol)そのものを、宇宙リンクの上にそのまま流してしまう」というアプローチです。この回では、なぜそんなことをしたくなるのかという動機から出発し、IPパケットをSpace Packetの世界に橋渡しするEncapsulation Service(CCSDS 133.1-B)の仕組み、そしてIP/UDPの上に乗る軽量なファイル転送プロトコルSaratogaを見ていきます。最後に、なぜ深宇宙探査機の多くが依然として純粋なIPよりもCCSDS独自プロトコルやDTN(Bundle Protocol)を選び続けているのか、その使い分けの理由を定量的に整理します。

直感的導入: 「地上と同じインターネット」を宇宙に持ち込むという発想

なぜわざわざIPを宇宙に持ち込みたいのでしょうか。理由は技術的な優位性というより、むしろ経済合理性にあります。

地上には、何十年もかけて磨き上げられた、IPを前提とする膨大なソフトウェア資産があります。ルータ、スイッチ、ファイアウォールといったネットワーク機器はもちろん、pingやtracerouteのような基本的な診断ツール、Webサーバやブラウザ、監視ダッシュボード、そして無数のアプリケーション開発フレームワークまで、そのすべてがIPアドレスとポート番号という共通言語の上に成り立っています。

もし探査機や宇宙ステーションの機器が標準的なIPで話せるなら、これらの資産をほぼそのまま——場合によっては市販の(COTS: Commercial Off-The-Shelf)ネットワーク機器やソフトウェアパッケージをろくに改造せずに——宇宙システムの中に持ち込めます。逆にCCSDS独自のプロトコル体系にこだわり続ける限り、通信ソフトウェアはミッションのたびに専用実装を書き起こし、専用の地上支援設備(EGSE)を用意し、専用の運用者訓練をする必要があります。「車輪の再発明をしない」という、ソフトウェア工学ではごく当たり前の発想を、宇宙システムにも適用したいというのが、IP over CCSDSの根底にある動機です。

もちろんこれは無条件に得な話ではありません。SCPSの回で見たように、地上のTCP/IPの前提(短いRTT、輻輳=ロスの主因、対称な帯域)は深宇宙リンクではことごとく崩れます。IPそのものを持ち込むという選択にも、同様のコストが伴います。この回の後半では、そのコストを具体的な数字で見ていきます。

CCSDSプロトコルスタックにおけるIPの位置づけ

Space Packetの回で整理した階層図を思い出してください。

アプリケーション層(観測機器・搭載ソフトウェア)
        ↓
Space Packet Protocol (CCSDS 133.0-B)
        ↓
Space Data Link Protocol (TM/TC, CCSDS 132.0-B / 232.0-B)
        ↓
物理層(変調・符号化)

IP over CCSDSは、この積み重ねに新しい選択肢を追加します。すなわち、アプリケーション層のデータをSpace Packetに直接詰めるのではなく、まずIPパケットの形に整えてから、それを「何か特別な中身が入った荷物です」という汎用のラベルを貼ったカプセルに包み、そのカプセルをSpace PacketやSpace Data Link Protocolのフレームに載せて運ぶ、という経路です。

アプリケーション層(IPベースのソフトウェア資産)
        ↓  IPデータグラムを生成
IP (IPv4 / IPv6)
        ↓  IPデータグラムをカプセル化パケットに包む  ← 今回の主眼(1)
Encapsulation Service (CCSDS 133.1-B)
        ↓  カプセル化パケットをSpace Packetまたはフレームに載せる
Space Packet Protocol / Space Data Link Protocol
        ↓
物理層

このカプセル化の器を提供するのがCCSDS 133.1-BのEncapsulation Serviceであり、その上で「具体的にIPデータグラムをどう扱うか」を規定するのがCCSDS 702.1-B、IP over CCSDS Space Links です。

定式化1: Encapsulation Service — 任意のPDUを運ぶ汎用の器

Encapsulation Serviceが提供するEncapsulation Packetは、Space Packetとは異なる発想で設計された、もっと汎用的なコンテナです。Space Packetのヘッダが「APID(送信元)」「Packet Sequence Count(順序)」といった、CCSDSの世界観に特化したフィールドを固定6オクテットで持っていたのに対し、Encapsulation Packetのヘッダは次の2つの役割に絞り込まれています。

中身が何のプロトコルのPDU(Protocol Data Unit)かを示す(Protocol IDフィールド)。IPv4データグラム、IPv6データグラム、CFDPのPDU、Bundle Protocolのバンドル、あるいは別のEncapsulation Packetそのものなど、複数の候補の中から中身の種別を1つ指定します。これは地上のイーサネットフレームにおける「EtherTypeフィールド」(中身がIPv4なのかARPなのかを示す)と、発想としてはよく似ています。
カプセル全体の長さを示す(Length-of-Lengthフィールドと、それに続く可変長の長さフィールド)。ここがEncapsulation Packetの設計上の工夫どころです。

CCSDSがこれまで扱ってきたのは、テレメトリのようなごく小さいPDUから、IPデータグラムのようにキロバイト級になり得るPDUまで、サイズのレンジが非常に広い荷物です。もし長さフィールドを常に最大サイズに対応できる固定長(たとえば8オクテット)で確保してしまうと、数十バイトしかない小さなPDUを運ぶときにヘッダの大半が無駄になります。そこでEncapsulation Packetのヘッダは、運びたいPDUのサイズに応じて、長さフィールドの長さそのものを可変にするという設計を取ります。おおまかには、ヘッダはPDU種別を示す固定長の先頭バイトと、それに続く $k$ オクテットの長さフィールド( $k \in \{0, 1, 2, 4, 8\}$ 、値がPDUのオクテット数に応じて選ばれる。 $k=0$ は「長さは明示せず、外側のフレームやパケットの境界がそのままカプセルの終端を示す」という特殊なケース)から構成されます。

H_{\text{encap}}(k) = 1 + k \quad [\text{オクテット}]

$k$ オクテットで表現できる長さの上限はおよそ $2^{8k}$ なので、運びたいPDUの長さ $L$ [オクテット] に対して、ヘッダのオーバーヘッドを最小化する $k$ は

k^{*}(L) = \min\{\, k \in \{0,1,2,4,8\} : 2^{8k} > L \,\}

を満たす最小の $k$ です。たとえば典型的なイーサネットMTUサイズのIPv4データグラム( $L=1500$ オクテット)を運ぶ場合、 $k=1$ (表現上限256)では足りず、 $k=2$ (表現上限65536)で足りるので $k^{*}=2$ 、ヘッダは $H_{\text{encap}} = 1+2 = 3$ オクテットで済みます。この場合のヘッダのオーバーヘッド比は

\eta_{\text{encap}} = \frac{H_{\text{encap}}}{H_{\text{encap}} + L} = \frac{3}{3+1500} \approx 0.20\%

と、ほとんど無視できる水準です。Encapsulation Packet自体の設計は、非常に軽量に作られていることが分かります。問題はこの先——Encapsulation Packetの中にさらにIPヘッダやUDPヘッダが入れ子になるところにあります。

定式化2: IP over CCSDS の「IPタックス」を定量評価する

CCSDS 702.1-Bが規定するのは、このEncapsulation Packetの中身としてIPv4またはIPv6のデータグラムをそのまま格納する、という具体的な使い方です(Protocol IDフィールドで「IPE: Internet Protocol Extension」を指定します)。つまり実際にIPパケットを1個運ぶには、Encapsulation Packetのヘッダに加えて、IPヘッダ、そしてその上のトランスポート層ヘッダ(UDPやTCP)まで、すべてが積み重なって運ばれることになります。IPv4ヘッダは最小20オクテット、IPv6ヘッダは40オクテット固定、UDPヘッダは8オクテット固定です。したがって、Encapsulation PacketでIP/UDPのPDUを1個運ぶのに必要な総ヘッダオーバーヘッドは

H_{\text{total}}^{\text{IPv4}} = H_{\text{encap}} + H_{\text{IPv4}} + H_{\text{UDP}} = 3 + 20 + 8 = 31\ \text{オクテット}

H_{\text{total}}^{\text{IPv6}} = H_{\text{encap}} + H_{\text{IPv6}} + H_{\text{UDP}} = 3 + 40 + 8 = 51\ \text{オクテット}

これを、CCSDS独自のプロトコルだけで完結させた場合——すなわちSpace Packetの6オクテット一次ヘッダだけで同じデータを運ぶ場合と比較してみましょう。ペイロード長 $L$ を変えながらオーバーヘッド比 $\eta = H/(H+L)$ を並べると、次のようになります。

ペイロード長 $L$	Space Packetのみ(6オクテット)	IP over CCSDS, IPv4+UDP(31オクテット)	IP over CCSDS, IPv6+UDP(51オクテット)
200 オクテット(小さなテレメトリ相当)	$6/206 \approx 2.9\%$	$31/231 \approx 13.4\%$	$51/251 \approx 20.3\%$
1500 オクテット(MTUサイズのファイル転送セグメント相当)	$6/1506 \approx 0.40\%$	$31/1531 \approx 2.0\%$	$51/1551 \approx 3.3\%$

この表から、2つの重要な傾向が読み取れます。

1. 「IPタックス」(IP/UDPヘッダを載せるコスト)は、ペイロードが大きいほど相対的に軽くなる。 大きなファイル転送セグメントであれば数%程度の追加コストで済みますが、CCSDSが伝統的に得意としてきた小さくて頻繁なテレメトリパケットでは、IPを被せることで正味のオーバーヘッドが1桁近く増えてしまいます。

2. IP over CCSDSは、Space Packet単体に対して常に上位互換ではなく、明確なトレードオフである。 ソフトウェア資産の再利用という利点と引き換えに、帯域が貴重な深宇宙リンクではこの数%〜20%程度のオーバーヘッド増加が無視できないコストになり得ます。逆に、後述する国際宇宙ステーション(ISS)のように帯域に比較的余裕があるリンクでは、このコストは十分に許容範囲に収まります。

Saratogaプロトコル: UDPベースの軽量ファイル転送

IPをそのまま宇宙リンクに持ち込めるようになると、その上で動くアプリケーション層のプロトコルも、地上のIPネットワークの発想で設計できるようになります。その代表例がSaratogaです。Saratogaは、Surrey大学のSurrey Space Centreを中心に開発された、UDPの上に直接乗るファイル転送プロトコルで、CFDPと同じく「長遅延・非対称帯域・断続的接続」という宇宙リンクの特性に適応させることを目的としていますが、その実現の仕方はCFDPとはかなり異なります。

CFDPは、CCSDSの正式な勧告として、宇宙データリンクプロトコルのフレームの上、あるいはBundle Protocolのバンドルの中に直接載ることを想定した、独自のPDU体系(Metadata PDU、File Data PDU、EOF PDU、NAK PDU、Finished/ACK PDU)を持つプロトコルでした。これに対しSaratogaは、最初からIP/UDPというありふれたトランスポートの上で動くことを前提に設計されており、パケットの種類も最小限(ピア発見・存在通知のためのBEACON、転送開始要求のREQUEST、ファイルのメタ情報を伝えるMETADATA、データ本体を運ぶDATA、そして受信状況を伝えるSTATUS)に絞り込まれています。

信頼性転送の核となる考え方は、実はCFDPと共通しています。Saratogaの受信側もCFDPと同じく、まだ受け取っていないバイト範囲の集合(ホールリスト, hole list)を管理し、それをSTATUSパケットにまとめて送信側に伝え、送信側はそのホールリストが示す範囲だけを選択的に再送します。これはCFDPの回で見たNAK PDUのギャップリストとまったく同じ発想——欠けている部分だけをピンポイントで埋め直す修復志向の再送——であり、その効率性(ラウンドを重ねるごとに期待欠損数が幾何級数的に減っていくという性質)についてはCFDPの回で導いた議論がそのまま当てはまるので、ここで数式を繰り返すことはしません。

両者の違いは、むしろ**「その仕組みをどの層の上に、どれだけ軽く実装するか」**という設計思想の違いに現れています。

	CFDP	Saratoga
土台とするトランスポート	CCSDS宇宙データリンクプロトコルのフレーム、またはBundle Protocolのバンドル	UDP/IP(すなわちIP over CCSDSのカプセル化が必要)
PDUの種類	Metadata / File Data / EOF / NAK / Finished / ACK など多め	BEACON / REQUEST / METADATA / DATA / STATUS と少なめ
信頼性転送の仕組み	NAK PDUによるギャップリスト方式の選択的再送(クラス2)	STATUSパケットによるホールリスト方式の選択的再送(発想はNAKと同じ)
ピア発見	想定しない(送信元・宛先のエンティティIDは事前設定)	BEACONパケットによる能動的なピア発見・存在通知を標準機能として持つ
標準化の位置づけ	CCSDS勧告(727.0-B)として正式に標準化、多機関で相互運用性を重視	主にIETFインターネットドラフトとして提案され、実装の軽量さ・小フットプリントを重視
想定する実装規模	フラッグシップミッションからCubeSatまで幅広く、機能が豊富な分だけ実装コストも相応	もともと小型衛星・組み込みプロセッサでの実装を強く意識した、最小限の状態管理

Saratogaが「より軽量な実装を目指した」と言われる所以は、CFDPが持つ多くのオプション(クラス1/クラス2の切り替え、多様な付加PDU、細かい確認応答モードの設定など)を切り詰め、UDPという既存の実績あるトランスポート層に信頼性以外の面倒(パケットの送受信そのもの)を任せることで、Saratoga自身が持つべき状態と実装コードの量を最小化している点にあります。この軽さゆえに、SaratogaはBundle Protocolの下で個々のリンクの信頼性を担うコンバージェンス層アダプタ(前回までに扱ったLTPと同じ役割)の候補としても検討されてきました。ただしLTPがCCSDSの枠組みの中でDTN専用に設計されたのに対し、SaratogaはIPネットワークならどこでも(宇宙リンクに限らず)使える汎用ファイル転送プロトコルとして生まれた、という出自の違いがあります。

実務での使われ方

国際宇宙ステーション(ISS)。 ISSは、深宇宙探査機とは通信環境がまったく異なります。地球低軌道(高度約400km)を周回しており、静止軌道上のデータ中継衛星(TDRSS)を介した中継であっても往復遅延は高々1秒程度、深宇宙リンクの数十分〜数十時間という遅延とは比較になりません。帯域も、Ku帯を使った高速リンクによって比較的余裕があります。この「短遅延・広帯域・ほぼ継続的な接続性」という条件は、地上のTCP/IPが暗黙に前提としている環境そのものです。ISSでは船内のペイロードラック、実験機器、IP電話などが標準的なイーサネット/IPベースのネットワーク(Joint Station LAN, JSLなど)で相互接続されており、地上の商用ネットワーク機器やソフトウェアの資産をほぼそのまま活用できています。また、NASAが2012年にISSへ搭載したSDR(ソフトウェア無線)実験基盤(SCaN Testbed)では、DTNのBundle Protocolを含む複数の通信プロトコルの軌道上実証も行われており、ISSは新しい通信プロトコルの技術成熟度を上げるための試験場としても機能してきました。

さらに、静止軌道の商用通信衛星を使った実証としては、2009年にIntelsat社の静止衛星Intelsat-14に、Cisco社が開発したIPルータをペイロードとして搭載し、衛星上でIPパケットのルーティングを直接行う「IRIS(Internet Routing In Space)」プログラムが実施されました。これは深宇宙探査機ではありませんが、「衛星そのものをIPネットワークのノードとして扱う」というIP over CCSDS的な発想を、軌道上で実際に検証した早い時期の例として知られています。

深宇宙探査機では、なぜ純粋なIPよりもCCSDS独自プロトコルやDTNが好まれ続けるのか。 理由は、この回で見てきた定量的なトレードオフがそのまま逆向きに効いてくるからです。

帯域が貴重で、IPタックスが相対的に重い。 前節の表で見た通り、小さなテレメトリパケットにIP/UDPヘッダを被せると、オーバーヘッドが数%から一気に十数%〜20%へと跳ね上がります。ダウンリンク速度が数百bps〜数Mbps程度に留まることも珍しくない深宇宙リンクでは、このオーバーヘッドの増分がそのままサイエンスデータの実質的な取得量の減少に直結します。
遅延耐性の要求そのものが違う。 SCPSの回で見たように、標準的なIPのルーティング・アドレス解決の仕組みは、ネットワークのトポロジがある程度安定して見えることを暗黙に仮定しています。しかし深宇宙の惑星間ネットワークでは、探査機・周回機・地上局の間の可視性(コンタクト)がスケジュールされた時間帯にしか開かず、ある瞬間を切り取るとエンドツーエンドの経路自体が存在しないことも珍しくありません。この「経路が同時には成立しない」という条件に対応するには、DTNのBundle Protocolが採る蓄積&転送のオーバーレイモデルが必要であり、これは古典的なIPルーティングの発想の延長では素直には実現できません。
既存のCCSDS資産との整合性。 地上局の受信設備、フレーム同期、誤り訂正符号の運用ノウハウは、何十年もかけてSpace Packetとフレームを中心に構築されてきています。この資産をゼロから置き換えるコストは、ソフトウェア資産の再利用という利点だけでは正当化しにくい場合が多くあります。

したがって実務上の使い分けは、おおむね次のように整理できます。地球低軌道で帯域に余裕があり、接続がほぼ継続的なリンク(ISS、多くの地球観測衛星の直接可視パスなど)ではIP over CCSDSが実用的な選択肢になり得る一方、帯域が貴重で接続が間欠的な深宇宙リンクでは、Space Packet・CFDP・DTNといったCCSDS独自の体系(あるいはその発展形)が引き続き主役であり続けているというのが現状です。Encapsulation Serviceそのものは、IP以外の任意のPDU(CFDPのPDUやBundle Protocolのバンドルも含む)を運べる汎用の器なので、深宇宙ミッションにおいても「地上系のゲートウェイ間でIPトンネルを一時的に張る」といった限定的な用途では活用されています。

演習問題

ペイロード長 $L = 64$ オクテットの小さなIPv6データグラム(UDP使用)をEncapsulation Serviceでカプセル化して運ぶ場合の、 $H_{\text{total}}^{\text{IPv6}}$ とオーバーヘッド比 $\eta$ を計算し、本文中の $L=200$ 、 $L=1500$ の場合の値と比較して、ペイロードが小さいほどIPタックスが重くなるという傾向を数値で確認してください。
SaratogaのSTATUSパケットによるホールリスト方式の選択的再送は、CFDPの回で学んだNAK PDUによるギャップリスト方式と発想が同じです。CFDPの回で導いた「期待欠損数はラウンドを追うごとに $p$ 倍ずつ幾何級数的に減少する」という結果(セグメント数 $N$ 、損失率 $p$ )は、Saratogaのホールリスト方式にも同様に当てはまると考えられます。この共通点を踏まえたうえで、それでもSaratogaがCFDPより「軽量な実装」と評される理由を、両者が採用する土台となるプロトコル層とPDUの種類の数という観点から説明してください。
なぜISSのような地球低軌道の宇宙ステーションでは標準的なTCP/IPアプリケーションが実用的に動作するのに、火星探査機との通信ではSCPSの回で見たように標準TCPがほとんど機能しなくなるのか。両者のリンクの往復遅延(RTT)と帯域遅延積(BDP)の違いに触れながら説明してください。
ある小型月探査ミッションが、月周回機と地球局の間のリンク(RTT数秒程度、帯域は中程度、接続はほぼ継続的)でファイル転送プロトコルを選定しようとしています。IP over CCSDS + Saratogaと、CCSDS独自プロトコル + CFDPのどちらがより適切な選択と考えられるか、この回で学んだオーバーヘッドの定量評価と、両プロトコルの設計思想の違いを踏まえて、自分の考えを理由とともに述べてください。

まとめと次回予告

IP over CCSDSは、CCSDS独自のプロトコル体系とは別の道として、地上のIPをそのまま宇宙リンクに持ち込むことで、ソフトウェア資産の再利用という経済合理性を得ようとする試みです。Encapsulation Service(CCSDS 133.1-B)は、PDUの種別を示すProtocol IDと、PDUサイズに応じて可変長になる長さフィールドという、軽量で汎用的なカプセル化の器を提供し、その上でCCSDS 702.1-Bが具体的にIPv4/IPv6データグラムの運び方を定めています。ただし、IPやUDPのヘッダを重ねて運ぶことには無視できないオーバーヘッド(「IPタックス」)が伴い、そのコストは小さなペイロードほど重くのしかかります。Saratogaは、このIPという土台の上に、CFDPと同じNAKベースの選択的再送の発想を、UDPに直接乗るごく少数のPDU種別だけで軽量に実装したファイル転送プロトコルでした。そして実務では、帯域に余裕がありほぼ継続的に接続できるISSのようなリンクでIPが実用的な選択肢になる一方、帯域が貴重で接続が間欠的な深宇宙リンクでは、依然としてCCSDS独自プロトコルとDTNのBundle Protocolが主役であり続けている、という使い分けを見ました。

次回は、探査機の中に目を移し、観測機器と搭載コンピュータをつなぐ内部データバスの世界へと踏み込みます。すでに触れたSpaceWireに加え、航空宇宙分野で広く使われてきたMIL-STD-1553バスや、地上の自動車産業発のCANバスが宇宙機にどう採用されているかを軽く比較し、探査機内部のデータ経路と、これまで扱ってきた探査機-地上間のリンクとの違いを整理します。

参考文献

CCSDS 133.1-B-3, Encapsulation Packet Protocol, Blue Book
CCSDS 702.1-B-1, IP over CCSDS Space Links, Blue Book
L. Wood et al., Saratoga: A Scheme for Bulk Data Transfer, IETF Internet-Draft (draft-wood-tsvwg-saratoga)
CCSDS 727.0-B, CCSDS File Delivery Protocol (CFDP)
CCSDS 714.0-B, SCPS Transport Protocol (SCPS-TP)
V. Cerf et al., Delay-Tolerant Networking Architecture, RFC 4838
J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76