Кратко

  • Положительный PDR-ACK означает, что корень считает запрошенный Track построенным и обязуется поддерживать его в течение согласованного срока. Фактическое прохождение пакета он не удостоверяет.
  • Эксплуатационное доказательство связывает запрос и последовательность, состояние для конкретного режима, сроки сегментов и Track, идентификатор в пакете, наблюдения пути и результат приложения.

Система уже показывала зелёный статус, хотя передавать было ещё нечего. Корень ответил на правильный запрос и принял Track. В отчёте это превратилось в «детерминированный сервис работает». Но не было ни пакета с TrackID, ни счётчика на выходе, ни записи приложения. Подтверждение существовало; событие доставки — нет.

RFC 9914 опубликован в апреле 2026 года как Proposed Standard и определяет Root-Initiated Routing State для RPL. Карточка RFC Editor фиксирует обновление RFC 6550, RFC 6553 и RFC 8138. Это механизм построения Track в LLN, а не отчёт о внедрении или достигнутом SLA.

Вход отправляет P-DAO-REQ с TrackID, конечными точками, желаемым сроком и PDRSequence. Корень использует последовательность в PDR-ACK. Положительный ответ объявляет Track построенным и принимает обязательство на согласованный срок, отрицательный отвергает запрос. Оба относятся к управлению, а не к наблюдению трафика.

Форма состояния зависит от режима. В Non-Storing Mode корень хранит сведения для исходного маршрута или туннеля. В Storing Mode корень посылает Projected DAO — P-DAO — выходу; информация идёт обратно ко входу, и каждый маршрутизатор устанавливает свой отрезок. Положительный P-DAO-ACK возвращается от входа. Если его нет, корень может повторить запрос с тем же TrackID или разобрать Track. Единый индикатор «установлен» скрывает, где именно хранится состояние.

Отказы имеют ограниченные причины. Vector Information Option может сообщить Out of Resources, Predecessor Unreachable или Unreachable Target. Код объясняет, почему узел не принял сегмент, но не устанавливает физическую причину радиопотери и не доказывает отказ приложения.

Время также распределено. Segment Sequence упорядочивает изменения, Segment Lifetime задаёт срок отрезка. Старая последовательность игнорируется, повтор той же пары не должен менять состояние, нулевой срок удаляет сегмент. Сегменты обновляются асинхронно и независимо от общего срока Track. Внешнее обязательство может оставаться действующим при внутренних перестройках.

Изменения глубже по Track способны остаться прозрачными для входа. Если корень больше не может поддерживать услугу, он разрушает весь Track и может асинхронно прислать отрицательный PDR-ACK с нулевым сроком. Отсутствие такого сообщения не удостоверяет неизменность каждого перехода.

Маршрут Track имеет больший приоритет, чем главный DODAG. Пакет, уже вошедший в Track, не должен возвращаться к обычному DODAG; при недоступности следующего соседа он отбрасывается. Обычная связность RPL потому не заменяет доказательство доставки по Track.

TrackID и DODAGID можно наблюдать в RPL Packet Information, исходном маршруте или инкапсуляции по правилам RFC 9008 и RFC 6553. Захват связывает пакет с Track в данной точке, но не говорит за ненаблюдаемые узлы и приёмное приложение. При перепроецировании пакеты до и после изменения могут получить разные задержки, джиттер и перестановку.

RFC 8655 задаёт архитектурный контекст DetNet, а RFC 9912 — RAW с защитными путями, репликацией, устранением дублей и быстрой адаптацией. Они объясняют цель Track, но не измеряют конкретный поток.

Проецируемое состояние создаёт риск истощения ресурсов. Злоумышленник, способный подделать P-DAO, может вызвать постоянные изменения и занять память маршрутизаторов. RFC 9914 требует защиты канального уровня и ссылается на анализ угроз RPL в RFC 7416. Реестр RPL IANA координирует коды, но не удостоверяет безопасность сети.

Проверяемая запись сохраняет P-DAO-REQ и PDRSequence, решение корня и срок Track, режим, P-DAO/P-DAO-ACK при необходимости, отказы узлов, последовательности и сроки сегментов, наблюдаемые TrackID/DODAGID, телеметрию входа, выхода и переходов, потери и перестановки, а затем результат приложения. Это редакционная цепочка доказательств, не обязательная схема RFC.

Minimum Initial Specification Хэн Лу оставляет общий минимум узким, а дальнейшие решения — под местной ответственностью. Running-Code Primacy ставит исполненное и наблюдаемое состояние выше символа. Reality Layers разделяет запрос, ACK, маршрут, пакет и услугу. Это объявленные редакционные принципы, не дополнительные требования IETF.

Точное толкование не обесценивает подтверждение. Оно оставляет PDR-ACK сильным свидетельством своего слоя, а пакету и приёмнику — право доказать следующие слои.

Sources