Summary

  • 2026年10月31日公開のIETF TIPTOP草案をWesley Eddy、Marc Blanchet、Tony Liが執筆した。例示された指令経路では、特別な終端が二つ、蓄積できる転送装置が二つあり、少なくとも五つの通常のIPノードがそのまま使われる。
  • リンクが切れ、代替経路もなければ、転送装置はパケットを上限付きキューに置ける。容量超過、再起動、メモリー障害は損失を生む。保存中に指定経路が古くなれば、再開後の行き先を計算し直す。

保存できるのは、無限ではない

IETFの原案によると、地球から火星までの片道伝搬時間は四～二十四分。自転や合によって通信できない期間もある。次の接触までパケットが数時間、場合によっては数日待つ設計を考えるのは、この物理的な予定表のためだ。

IPの形式を変える話ではない。IPv4のTTLは実際にはホップ数として動き、IPv6ではHop Countという名前になった。キューの中で時計が進んでも、その値は減らない。変えるのは断続リンクの手前にいる転送装置だ。インターフェースが停止し、ほかに宛先への道がなければ、受け取ったパケットを一時保管する。

ただし、保管庫には壁がある。草案は深いキューに容量上限と廃棄方針を設ける。満杯になれば、トラフィッククラス、送受信アドレス、フローラベルなどを根拠に何かを落とす。再起動や訂正できない記憶装置の異常でも失われる。転送装置に保証付き配送を義務づけず、信頼性の回復は終端間の転送層に任せる。だから容量と廃棄順は、発射後に気分で決める項目ではない。

図に描かれた指令の通り道には、地上の運用拠点と宇宙機の終端、通信事業者側と宇宙機側の転送装置が置かれる。その間のLANやWANには普通のIPノードが少なくとも五つ残る。別系統の編成装置が、アンテナの向き、モデム、経路表を接触計画に合わせて準備する。必要な箇所から導入する設計であり、特定の火星ミッションの実績を示した図ではない。

目を覚ましたパケットに昨日の地図を渡さない

通常のルーティングは隣接装置との定期的な生存確認に頼る。返答まで長くかかり、次の接触まで通信できないリンクでは、その会話は役に立ちにくい。草案は制御装置と接触予定に沿った更新を重視する。BGPはドメイン間に残せるが、遅いリンクをまたぐ到達性には代理広告が必要になる。

明示的な経路で中間装置まで来たパケットは、そこで長く眠る。起きたとき、指定された残りの経路が無効かもしれない。予備経路を各パケットに詰め込めば、細い回線をさらに圧迫する。著者らは中間装置が残りを再計算する方法を選ぶ。保存の成否は、通信再開時の経路判断と一体だ。

草案には稼働中のTIPTOP転送装置のキュー記録がない。接触時刻、使用量、廃棄数と再計算のログが実際の配送結果を示す。

原資料