Кратко

  • RFC 9897 описывает согласование MP-DCCP, объявление адресов и аутентифицированное присоединение дополнительного подпотока к существующему соединению.
  • MP_CONFIRM и MP_JOIN подтверждают ограниченные факты управления, но не выбор планировщика, своевременный приём, переупорядочение, переключение или результат приложения.

На панели всё зелёное. Второй подпоток завершил рукопожатие, идентификатор соединения совпал, а HMAC связал присоединение с участниками первого потока. Но владелец сервиса спрашивает: какая важная дейтаграмма прошла по запасному пути, когда основной ухудшился? Журнал управления этого не знает.

RFC 9897, опубликованный как Proposed Standard в январе 2026 года, расширяет DCCP для нескольких путей; карточка RFC Editor фиксирует публикацию. Базовая служба RFC 4340 остаётся ненадёжной передачей дейтаграмм с контролем перегрузки. Несколько подпотоков могут выглядеть для приложения как одно соединение, но не становятся надёжным потоком байтов.

Первый подпоток согласует Multipath Capable и обменивается ключевым материалом узлов. Следующий несёт MP_JOIN, Connection Identifier партнёра и новый nonce; MP_HMAC проверяет принадлежность исходному соединению. Так произвольный поток нельзя выдать за его участника. Однако правильная ассоциация ещё не говорит, какой пакет приложения планировщик направил в этот подпоток.

Объявление адреса находится ступенью ниже. MP_ADDADDR сообщает адрес и при необходимости порт, защищается HMAC и получает последовательность для различения свежих и устаревших данных. Партнёр может сохранить или отбросить объявление. MP_CONFIRM делает обмен опцией надёжным, но RFC прямо исключает дальнейшую обработку из смысла подтверждения. Подтверждённый адрес не означает созданный подпоток; созданный подпоток не означает наблюдаемое использование.

Это сознательная граница стандарта. MP-DCCP предоставляет номера последовательности соединения, сведения RTT и подсказки приоритета. Алгоритм планирования, необязательное переупорядочение у получателя, время и порядок добавления или удаления подпотоков остаются за конечными узлами. Даже максимальное число подпотоков не согласуется протоколом — реализация сама ограничивает ресурсы.

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

Граница безопасности также ограничена. RFC защищает присоединение и отдельные сигналы в своей модели ключей, но не даёт автоматически всех криптографических свойств приложению. Для этого указаны сквозные средства, например DTLS поверх DCCP. Address ID не устраняет все middlebox. DCCP-UDP предлагает инкапсуляцию для прохождения, однако RFC 9897 оставляет её вне самого MP-DCCP.

Термины и идеи сигнализации частично заимствованы из RFC 8684, а при обсуждении лимита путей цитируется RFC 8041. Это контекст, а не перенос свойств доставки или опыта MPTCP. Реестр параметров DCCP IANA подтверждает назначения Feature 10, Option 46, версии 0 и подопций, но не поддержку и не качество реализации.

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

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

Стандарт даёт второму пути дисциплинированный вход. Отказоустойчивость начинается лишь там, где доказательства продолжаются после него.

Sources