Summary

  • Wesley Eddy вместе с Marc Blanchet и Tony Li выпустил 31 октября 2026 года рабочий проект IETF о сети IP в дальнем космосе. Его пример оставляет не менее пяти обычных IP-узлов и добавляет два настроенных конечных узла и два узла с долгим хранением пакетов.
  • Когда прерывистый канал отключён и обхода нет, пакет может остаться в ограниченной очереди. Переполнение и сбой памяти ведут к потерям. После ожидания заданный ранее маршрут может уже не вести к цели.

Очередь не равна обещанию доставки

Передача от Земли к Марсу занимает от четырёх до 24 минут в одну сторону, говорится в первичном проекте IETF. Вращение и соединение планет добавляют перерывы. Авторы допускают ожидание пакета в промежуточном устройстве на протяжении минут, часов и даже дней. В такой сети расписание антенн становится частью условий пересылки.

Формат IP-пакета при этом остаётся прежним. Поле TTL в IPv4 фактически считает переходы через узлы; в IPv6 оно называется Hop Count. Часы в буфере не уменьшают этот счётчик. Новая функция нужна там, где стабильная сеть выходит к каналу с разрывами. Если интерфейс отключён и другой маршрут отсутствует, узел сохраняет пакет локально. Когда путь появится снова, отправка возобновится.

У буфера есть предел. Проект описывает глубокую очередь с заданной ёмкостью и порядком отбрасывания. При заполнении выбор может зависеть от класса трафика, адресов отправителя и получателя или метки потока. Перезапуск устройства, очистка буфера либо непоправимая ошибка памяти также уничтожают ожидавшие пакеты. Промежуточному узлу достаточно обслуживания по принципу best effort; надёжную доставку обеспечивает транспорт между конечными точками. Правило потерь нужно установить до переполнения, а не после него.

Схема команды от центра управления к аппарату показывает, где именно требуются изменения. На концах работают два специально настроенных узла, возле радиоканала — два TIPTOP-маршрутизатора. Между ними остаются как минимум пять обычных IP-узлов. Отдельный оркестратор планирует наведение антенн, настройку модемов и записи в таблицах маршрутизации. Рисунок демонстрирует архитектуру, а не журнал работающей марсианской миссии.

Пакет просыпается, таблица уже другая

Наземные протоколы регулярно проверяют доступность соседей. На длинном и прерывистом канале такой обмен непрактичен. Авторы предлагают управляющий контроллер и обновления по плану контактов. BGP остаётся возможен между доменами, а для префиксов за разрывом понадобятся объявления от имени удалённой стороны.

Самая острая проблема возникает с явно заданным путём. Пакет прибывает на узел хранения по одному плану; к моменту следующего сеанса оставшаяся часть плана может стать недействительной. Запасной путь в заголовке каждого пакета съест дефицитную полосу. Проект предлагает пересчитывать остаток маршрута на промежуточном узле. Хранение сохраняет данные, а маршрутизация после паузы требует нового решения.

В проекте нет логов развёрнутой очереди TIPTOP. Время сеансов, заполнение, причины сброса и выбранные после паузы пути покажут фактический результат.

Первоисточник