Summary

  • 2026 年 10 月 31 日，Wesley Eddy 与 Marc Blanchet、Tony Li 联名发布 IETF TIPTOP 深空 IP 架构草案。示意路径只需要两个特殊端系统和两个特殊转发器，途中至少五个节点仍可运行普通 IP。
  • 断链且没有替代路由时，转发器可以把包放进有容量上限的队列。满了就按预设规则丢包；重启或存储错误也会造成损失。包等到链路恢复时，原先指定的后半段路径可能已经作废。

包能等，天线有自己的日程

IETF 原始草案给出地球到火星单程四至二十四分钟的传播时间，行星自转和合日还会切断联络。下一次接触窗口可能晚几个小时，甚至几天。草案允许某些 IP 包在转发设备里等到窗口打开。真正改变的并非包头，而是设备的存储责任。

IPv4 的 TTL 名字像倒计时，实际按跳数扣减；IPv6 直接叫 Hop Count。包躺在队列里几个小时，不会因为钟表走动而耗光跳数。草案把特殊能力放在断续链路的边界：接口关闭、目的地又无其他路可走，转发器先收下包；同一条或另一条路恢复时再发出去。

“先收下”不能靠一句口号。节点必须给深队列划容量，设丢弃次序。空间满了，流量类别、源与目的地址、流标签等可以决定谁先被扔掉。设备重启、清空缓冲区或无法纠正的内存错误，也可能使等待中的包消失。端到端可靠传输负责补救，转发器仍可以只提供尽力而为服务。任务方如果没有提前写清丢弃规则，就把优先级交给了满盘的那一刻。

草案的指令路径展示了这种分工：任务控制中心和航天器各有一个经过调校的端系统；通信服务商一侧和航天器一侧各有一个 TIPTOP 转发器；至少五个普通 IP 节点夹在其中。路径外的编排系统根据接触计划安排天线、调制解调器和路由表。图上画的是可逐步部署的架构，尚非某次火星任务的交付日志。

排队期间，路由表也在老去

常规路由协议靠周期性探测确认邻居在线。深空链路响应慢且时断时续，这套招呼打不起。草案倾向在相关域内用控制器与计划路由；BGP 仍可用于域之间，但跨越长延迟链路时需要代理发布可达前缀。

更棘手的是显式路径。包带着控制器选好的路线进入中间节点，存了一段时间后，后续路线可能已失效。给每个包塞一条备用路，会占用紧俏的链路带宽。作者选择让中间节点重算剩余路径。等来的不仅是链路，也是一道新的转发决定。

草案没有实际部署节点的队列日志。接触时间、队列占用、丢弃记录和重算结果会说明哪些等待最终换来了送达。

原始资料