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

LTP — 1ホップの信頼性を運ぶコンバージェンスレイヤ

DTNのバンドルという論理単位を、往復数十分の1リンク区間でどう確実に(あるいはあえて不確実に)転送するか。RFC 5326/CCSDS 734.1-BのLTPを、レッドパート・グリーンパート、チェックポイント・レポートによる選択的再送、光伝搬遅延に基づくタイムアウト設計から理解する。

前提知識: dtn

LTPDTNCCSDSコンバージェンスレイヤ選択的再送

この回で学ぶこと

前々回、DTN(Delay/Disruption Tolerant Networking)のバンドルプロトコル(Bundle Protocol, BP)が、往復数十分にも及ぶ深宇宙リンクや、頻繁に途切れる接続を前提に、「バンドル」という自己完結した論理単位をノード間でホップごとに中継していく仕組みであることを見ました。しかしBPそのものは、あるノードから隣のノードへバンドルを実際にどうやってビット単位で転送するかについては規定していません。BPは「何を、どのノードへ、いつまでに届けるべきか」を管理する上位層のプロトコルであり、その下には「1つのリンク区間(1ホップ)の上で、実際にバイト列を確実に運ぶ」役割を担う層が必要です。この役割を果たす層を DTNアーキテクチャでは コンバージェンスレイヤ(Convergence Layer, CL) と呼びます。

この回で扱う LTP (Licklider Transmission Protocol) は、深宇宙・惑星間リンクを主なターゲットとして設計された代表的なコンバージェンスレイヤプロトコルです。IETFのRFC 5326として標準化されており、CCSDSでも CCSDS 734.1-B (CCSDS Licklider Transmission Protocol (LTP) for CCSDS) として勧告化されています。名前は、インターネットの前身であるARPANETの構想に関わり、「銀河間コンピュータネットワーク」という言葉を残したJ. C. R. Licklider にちなんでいます。

この回では、なぜ地上のTCPをそのまま深宇宙リンクに使えないのか、そしてLTPがその制約にどう答えているのかを、レッドパート/グリーンパートという信頼性の粒度設計と、チェックポイント・レポートセグメントによる選択的再送の仕組みから理解します。

直感的な全体像: なぜTCPではダメなのか

地上のインターネットで信頼性のあるデータ転送と言えば、まず思い浮かぶのはTCPです。TCPは接続を始める前に SYN/SYN-ACK/ACK の3ウェイハンドシェイクを行い、以降もデータセグメントごとに ACK を細かくやり取りしながら、ウィンドウサイズを調整し、輻輳(混雑)を検知しては送信レートを絞る、という非常に対話的(interactive)なプロトコルです。地上のネットワークでは往復時間(RTT)がせいぜい数十〜数百ミリ秒程度なので、この頻繁な対話はほとんどコストになりません。

ところが探査機との通信では話がまったく違います。地球と火星の間の光の片道伝搬時間(One-Way Light Time, OWLT)は、両惑星の相対位置によって約3分から22分まで変動し、往復(Round-Trip Light Time, RTLT)では最大で40分を超えます。この状況でTCPのように「1セグメント送るごとにACKを待つ」設計を採用すると、リンクの実効スループットはRTLTに支配されて壊滅的に低下します。さらに悪いことに、探査機とのコンタクト(通信可能な時間窓)自体がDSN(Deep Space Network)のスケジュールによって1日数時間に限られていることも多く、ハンドシェイクや個々のACK待ちに費やす時間はそのまま実データを送れる時間の浪費になります。

LTPはこの制約に対して、根本的に異なる設計思想を取ります。**「相手からの応答をできる限り待たずに、送れるだけのデータを一方的に送りきる」**という、しばしば “send and (mostly) forget” と表現される方針です。接続確立のハンドシェイクは存在せず、最初のデータセグメントを送った瞬間にセッションが暗黙に開始されます。そして、信頼性の確認(再送が必要かどうかのチェック)は、転送するデータ全体の中でごく限られたタイミング(チェックポイント)でしか行いません。この設計により、たとえ往復に40分かかるリンクであっても、その40分の大半を実データの送信に充てることができます。

LTPのセッションとブロック

LTPが1回の転送単位として扱うデータを ブロック(block) と呼びます。BPとLTPの階層関係で言えば、1つのブロックは典型的には1つ以上のバンドルを含みます(BPがバンドルをLTPの「クライアントサービスデータ」として渡し、LTPはそれを送達対象のブロックとして扱う、あるいは複数の小さいバンドルを1つのブロックに集約することもあります)。

ブロックを送信するたびに、送信側のLTPエンジンは一意な セッション(session) を生成します。セッションは、送信元のLTPエンジンを識別する エンジンID と、そのエンジンが発行する セッション番号 の組で一意に識別されます。

\text{Session ID} = (\text{Engine ID}_{\text{src}},\ \text{Session Number})

重要なのは、LTPは1つのセッションのACKが返るのを待ってから次のセッションを開始する必要がない、という点です。複数のブロック転送(複数のセッション)を同時並行で走らせることができ、これによって「帯域幅×遅延積(bandwidth-delay product)」が非常に大きい深宇宙リンクでも、リンクを遊ばせることなくデータをパイプライン的に送り込み続けられます。TCPが1コネクションのウィンドウサイズ調整でこの問題に対処するのに対し、LTPは「セッションを並行して多重化する」というやや異なるアプローチでこれに対処していると理解すると整理しやすいでしょう。

レッドパートとグリーンパート

LTPの最も特徴的な設計が、1つのブロックの中でデータを2種類に分けて扱えることです。

レッドパート (red part): 信頼性転送の対象。欠落があれば検出され、再送によって完全な受信が保証される部分。
グリーンパート (green part): 信頼性なし転送の対象。一度送ったら送りっぱなしで、欠落があっても再送はされない部分。

1つのブロックは、先頭から長さ $L$ オクテットまでがレッドパート、残り $N-L$ オクテットがグリーンパートという形で分割されます( $N$ はブロック全体の長さ)。

\text{Block} = \underbrace{[\,0,\ L\,)}_{\text{赤: 信頼性あり}} \ \cup\ \underbrace{[\,L,\ N\,)}_{\text{緑: 信頼性なし}}

境界値 $L$ を選ぶことで、1つのブロックを完全にTCP的な「全部確実に届ける」動作( $L=N$ )にすることも、完全にUDP的な「送りっぱなし」動作( $L=0$ )にすることも、あるいはその中間(先頭の重要な部分だけ確実に届け、残りはベストエフォート)にすることもできます。

この柔軟性が実務上重要なのは、宇宙探査機のデータには本質的に異なる信頼性要求が混在するからです。たとえば科学観測データやコマンドの確認応答は1ビットでも欠けると意味を成さないためレッドパートに、逆に高頻度でサンプリングされるハウスキーピングテレメトリや、リアルタイム性が重要でRTLT経過後の再送データがもはや使い道を失うような情報(たとえば秒単位で更新される探査機の粗い姿勢情報など)はグリーンパートに、という形で1つのセッションの中に混在させられます。CFDPが主にファイル転送という単位で信頼性の有無を切り替えるのに対し、LTPは1つのブロックの中でバイト単位に信頼性の境界を引けるという点で、より細粒度な設計になっています。

チェックポイント・レポートによる選択的再送

レッドパートの信頼性は、どうやって保証されるのでしょうか。LTPはTCPのようにセグメントごとにACKを返す方式は取らず、代わりに チェックポイント(checkpoint) と レポートセグメント(report segment) という仕組みを使います。

送信側は、レッドパートのデータセグメントを次々と送信します。このとき、レッドパートの末尾のセグメント(あるいは明示的に指定されたセグメント)には チェックポイントフラグ を立てます。これは「ここまで送り終えたので、受信状況を報告してほしい」という合図です。
受信側は、チェックポイントフラグの付いたセグメントを受け取ると、それまでにレッドパートのどの範囲を実際に受信できたかをまとめた レポートセグメント (RS) を送信側に送り返します。レポートセグメントの中身は、受信済みのバイト範囲を $(\text{offset}, \text{length})$ の組の並び(受信claim)として列挙したもので、これは事実上「受信済み範囲のリスト」による選択的確認応答(selective acknowledgment)です。
送信側はレポートセグメントを受け取ると、レッドパート全体の範囲からclaimされた範囲を差し引き、欠落している範囲だけを再送します。再送されたセグメントの末尾にも新しいチェックポイントフラグが付き、再びレポートセグメントが要求されます。
この「チェックポイント→レポート」のラウンドを、レポートセグメントが「レッドパート全体を1つのclaimとして受信済み」と報告するまで繰り返します。全体受信が確認されると、送信側はそのレポートセグメントに対して レポート確認セグメント (Report-Acknowledgment Segment, RA) を返し、これ以上そのレポートに対する再送タイマーを維持する必要がないことを受信側に伝えて、そのラウンドの往復を終了します。

この方式は、CFDPで学んだ、NAK(Negative Acknowledgment)によって欠落した部分だけをピンポイントで再送させる選択的再送の考え方と本質的に同じ発想です。TCPの古典的なGo-Back-N的な再送(タイムアウトした時点から全部送り直す)とは異なり、「実際に欠けている部分だけ」を再送することで、往復に数十分もかかるリンク上で1回でも無駄なラウンドトリップを踏むことの被害を最小化しています。

欠落セグメント数を $N_0$ 、各セグメントが独立に確率 $p$ で失われるモデルを考えると、 $i$ 回目のチェックポイント・レポートのラウンドの後に残っている欠落セグメントの期待値はおおよそ

\mathbb{E}[N_i] \approx N_0\, p^{\,i}

と幾何級数的に減少していきます。したがって $\mathbb{E}[N_i] < 1$ となるために必要なラウンド数はおおよそ

i^\ast \approx \frac{\ln N_0}{\ln(1/p)}

程度で済み、 $p$ がそれほど大きくなければ、数回のラウンドでレッドパート全体の受信が完了することが分かります。ただし1ラウンドごとにRTLT(またはそれに近い時間)を要するため、 $i^\ast$ が1つ増えるごとに転送完了までの所要時間はRTLT単位で伸びていく、という点がリンク設計上のシビアな制約になります。

タイムアウト設計: 光の伝搬遅延をそのまま使う

TCPは、動的にRTTを推定してタイムアウト時間(再送タイムアウト, RTO)を決めます。JacobsonとKarelsのアルゴリズムに代表されるように、観測したRTTのサンプルから平滑化された推定値 $\widehat{RTT}$ とその変動幅 $\widehat{RTTVAR}$ を計算し、

\text{RTO} = \widehat{RTT} + 4 \cdot \widehat{RTTVAR}

のように動的に更新します。これは地上ネットワークのように、遅延の主要因がルータのキューイングや輻輳といった予測しづらい変動である場合には合理的です。

しかし深宇宙リンクでは事情がまったく異なります。伝搬遅延の支配的な要因は、キューイングでも輻輳でもなく、光速で決まる幾何学的な距離そのものです。探査機と地球の相対位置は軌道力学から高精度に予測できるため、ある時刻における片道光伝搬時間 $\tau_{\text{OWLT}}(t)$ は、探査機の軌道暦(エフェメリス)さえあれば事前にほぼ正確に計算できます。

\tau_{\text{OWLT}}(t) = \frac{d(t)}{c}

( $d(t)$ は時刻 $t$ における地球局と探査機の距離、 $c$ は光速。)

したがってLTPは、TCPのように統計的にRTOを推定する必要がありません。チェックポイント再送タイマーの値は、その時点のコンタクトプラン(通信スケジュール表)に含まれる距離情報から計算される往復光伝搬時間

T_{\text{cp}} \approx 2\,\tau_{\text{OWLT}}(t) + T_{\text{margin}}

を、ほぼそのまま(処理遅延分のマージン $T_{\text{margin}}$ を加えて)使うことができます。これはLTPの設計における非常に実務的なポイントで、後述するION実装では、この光伝搬遅延の値をコンタクトプランのエントリから自動的にLTPエンジンへ供給する仕組みが用意されています。

またLTPは、チェックポイント・レポートともに再送回数の上限(それぞれ独立した再送カウンタとリトライ上限)を持ちます。上限に達してもレポートが返ってこない、あるいはレポート確認が返ってこない場合、そのセッションは キャンセルセグメント (Cancel Segment) によって明示的に打ち切られ、上位のBP層に転送失敗が通知されます。これはTCPが接続断を検出する仕組みに相当しますが、ここでも「何度再送を試みるべきか」の判断基準として、統計的な輻輳推定ではなく、既知の光伝搬遅延とコンタクト窓の残り時間という決定論的な情報が使われる点が特徴的です。

実務での使われ方

階層関係の整理。 LTPはDTNアーキテクチャの中で、BP(Bundle Protocol)の下、実際のリンク層(CCSDSの空間データリンクプロトコル、たとえばAOS/TM/TCフレームやProximity-1プロトコルなど)の上に位置する、1ホップ分のコンバージェンスレイヤです。BPが「バンドルをどのノード経由でどう転送すべきか」というネットワーク層的な判断(ルーティング、蓄積転送、有効期限管理)を担うのに対し、LTPは「そのバンドル(を含むブロック)を、今アクティブな1つのリンク区間の上でどう確実に(あるいは意図的に不確実に)送り届けるか」という、いわばデータリンク層とトランスポート層の中間に相当する役割を担います。同じBPノードでも、ある隣接ノードとの間ではLTPを、別の隣接ノード(たとえば地上セグメント内のIPネットワーク経由の中継)ではTCPをベースにしたコンバージェンスレイヤ(TCPCL)を使う、といった使い分けが可能です。

ION (Interplanetary Overlay Network)。 JPLが開発し、NASAがオープンソースとして公開しているDTNプロトコルスイート ION は、BP(BPv6/BPv7)、LTP、CFDP、そして次回扱うContact Graph Routing(CGR)を統合的に実装しています。IONにおいてLTPは、RFリンクを介した深宇宙・惑星間コンタクトの標準的なコンバージェンスレイヤアダプタとして位置づけられており、運用者が事前に定義するコンタクトプラン(いつ、どのノード間で、どの距離・データレートの通信が可能かを記述したスケジュール表)から、前節で述べた光伝搬遅延に基づくタイムアウト値が自動的に導出されます。

標準化と実運用実績。 LTPはRFC 5326としてIETFで標準化されているほか、CCSDSでも734.1-Bとして勧告化されており、国際的な相互運用性が意識された規格です。JPLが2008年に実施した DINET (Deep Impact Networking) 実験 では、運用中のEPOXI(旧Deep Impact)探査機を経由してDTN/BPおよびLTPによるデータ転送が実際に深宇宙で検証されました。また国際宇宙ステーション(ISS)上でも、DTNソフトウェアの技術実証(Telescience Resource Kitなどを用いた実験)にLTPが利用されています。将来のアルテミス計画に関連するLunaNet構想でも、月周回・月面ノード間の断続的なリンクにDTN/LTPを適用する検討が進められています。

演習問題

地球から距離 $2.5 \times 10^8$ km 離れた探査機との通信を考えます。光速 $c \approx 3.0 \times 10^5$ km/s として、片道光伝搬時間 $\tau_{\text{OWLT}}$ と往復光伝搬時間(RTLT)を求め、チェックポイント再送タイマー $T_{\text{cp}}$ の目安を(処理マージンを2分と仮定して)計算してください。
あるレッドパート転送で、初期の欠落セグメント数が $N_0 = 200$ 、セグメントごとの独立な損失確率が $p = 0.1$ であるとします。 $\mathbb{E}[N_i] \approx N_0 p^i$ を使って、期待欠落セグメント数が1を下回るまでに必要なラウンド数 $i^\ast$ の概算値を求めてください。またこのラウンド数と問1のRTLTから、レッドパート転送が完了するまでのおおよその所要時間を見積もってください。
LTPがTCPのような3ウェイハンドシェイクを持たず、また個々のデータセグメントごとのACKも行わない設計になっているのはなぜか、この回で学んだ「深宇宙リンクの往復遅延」と「コンタクト時間の希少性」という2つの観点から説明してください。
あるDSNコンタクト窓の長さが8時間、対象探査機とのRTLTが40分であるとします。このコンタクト内で実行できるチェックポイント・レポートの往復ラウンド数はおおよそ何回程度と見積もれますか。またこの制約を踏まえて、転送するブロックのレッドパート長 $L$ をどのように設計すべきか、あなたの考えを述べてください。

まとめと次回予告

LTPは、DTNのバンドルプロトコルが必要とする「1ホップ区間での確実な(あるいは意図的に不確実な)転送」を担うコンバージェンスレイヤであり、往復数十分という深宇宙リンク特有の制約に対して、TCP的な対話型のプロトコル設計を捨て、「送れるだけ送っておいて、チェックポイントという限られたタイミングでのみ受信状況を確認する」という送りっぱなし志向の設計を採用しています。レッドパート/グリーンパートによる信頼性粒度の混在、チェックポイント・レポートセグメントによる選択的再送、そして統計的推定ではなく軌道暦から得られる決定論的な光伝搬遅延に基づくタイムアウト設計は、いずれも「遅延は大きいが、その遅延自体は正確に予測できる」という深宇宙リンクの本質的な性質をうまく利用した工夫だと言えます。

次回は、BPがバンドルをどのノード経由でどう送るべきかを決める Contact Graph Routing (CGR) を扱います。地上のインターネットのルーティングが「今どのリンクが生きているか」をリアルタイムに発見しながら経路を決めるのに対し、DTNのリンクはそもそも常時接続ではなく、コンタクトプランによって「いつ、どのノード間の接続が使えるか」があらかじめスケジュールされています。CGRは、このスケジュール情報(コンタクトグラフ)を使って、まだ確立していない未来のコンタクトも見越した経路選択を行う、時間軸を組み込んだユニークなルーティング方式です。

参考文献

RFC 5326, Licklider Transmission Protocol - Specification, IETF (M. Ramadas, S. Burleigh, S. Farrell)
CCSDS 734.1-B, CCSDS Licklider Transmission Protocol (LTP) for CCSDS
RFC 4838, Delay-Tolerant Networking Architecture, IETF (V. Cerf et al.)
S. Burleigh et al., “Delay-Tolerant Networking: An Approach to Interplanetary Internet,” IEEE Communications Magazine, 2003
L. Wood et al., “Investigating the IETF Bundle Protocol and Licklider Transmission Protocol for the Interplanetary Internet,” JPL/ION関連技術文書
ION (Interplanetary Overlay Network) Design and Operation Guide, NASA/JPL