Кратко

  • RFC 9685 позволяет узлу подписаться через 6LoWPAN Neighbor Discovery на multicast- или anycast-адрес и запросить распространение доступности через RPL.
  • Установленное multicast-дерево подтверждает состояние плоскости управления, но спящий слушатель всё равно может пропустить последнюю радиопередачу.
  • Для операционного вывода нужны отдельные записи о допуске, состоянии по источникам, объединённом маршруте, распространении DAO, решении о пересылке, последнем канале и приёме приложением.

У Root был нужный target. Промежуточные маршрутизаторы держали ветви multicast-дерева. 6LR отправил индивидуальный MAC-кадр к подписанному листу. В журнале управления всё выглядело завершённым — кроме того, что устройство спало и приложение не увидело пакет.

Такой исход не опровергает RFC 9685. Стандарт определяет, как узел в маломощной сети сообщает о multicast- или anycast-адресе, который он слушает, и как маршрутизатор может перенести объединённое состояние в RPL. Он различает регистрацию, маршрутизацию и пересылку. Он не обещает, что одна успешная операция Neighbor Discovery синхронно доказывает пробуждение радио, приём IP-пакета и действие приложения.

Последний участок особенно легко потерять в отчётности. Контрольная плоскость оставляет удобные объекты: NA(EARO), EDAC, DAO, target, дерево. Сон узла выглядит как локальная подробность. Но для сервиса именно эта подробность отделяет «путь существовал» от «сообщение было получено».

Подписка подтверждает допуск, а не последующий пакет

RFC 8505 задаёт Extended Address Registration Option. RFC 9685 называет операцию с multicast- и anycast-адресами подпиской: несколько узлов вправе слушать один адрес, поэтому это не спор об исключительном владении unicast-адресом.

Поле P указывает тип адреса, а отдельный флаг R запрашивает обслуживание доступности, включая возможную инъекцию маршрута. TID, срок жизни и Registration Ownership Verifier связывают операцию с последовательностью и источником. При необходимости EDAR и EDAC проверяют право слушателя через 6LoWPAN Border Router. Защита ROVR наследует механизм RFC 8928.

Успешная NA(EARO) говорит, что запрос был принят в определённом контексте. Она не говорит, что маршрут уже распространился: регистрация и инъекция асинхронны. Она не говорит, что конкретный слушатель бодрствовал во время следующей передачи. И она не является бизнес-разрешением на участие в прикладной группе.

Поэтому квитанция допуска должна хранить узел, адрес, P, R, TID, ROVR, запрошенный срок, идентификатор канала, результат EDAR/EDAC, статус NA и время. Метка «активен» без этих полей заставляет более поздний пакет отвечать за событие, которого он ещё не мог наблюдать.

Одно дерево скрывает несколько независимых сроков

Для общей multicast- или anycast-адреса маршрутизатор хранит регистрацию каждой стороны или источника, но может объединить их в одну рекламу маршрута. RPL не обязан переносить отдельный target на каждый лист. Это экономит состояние в сети с ограниченными ресурсами.

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

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

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

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

В Storing mode дерево — только середина цепочки

В Storing mode протокола RPL DAO поднимаются через предпочтительных родителей и создают состояние multicast-дерева. Маршрутизатор пересылает пакет индивидуальными unicast MAC-кадрами по ветвям, кроме соседа, от которого пакет пришёл. Это снижает зависимость от ненадёжного прямого broadcast, но не гарантирует приём листом.

В новом Non-Storing multicast mode Root выполняет ingress replication. DAO объявляет multicast-адрес target-ом, а Root инкапсулирует копии к транзитным 6LR с помощью source-routing механики, связанной с RFC 9008. Здесь корректный набор целей у Root и актуальная запись слушателя у конечного 6LR — разные доказательства.

Anycast не создаёт множество копий. Несколько дочерних узлов могут объявить один адрес, однако конкретный пакет выбирает один из них. Число подписок задаёт множество кандидатов, а не fanout. Проверка anycast должна сохранять правило выбора, выбранный узел, путь и результат, иначе ответ одного кандидата будет ошибочно приписан всем.

RFC 6553 описывает работу RPL-опций, а RFC 9010 связывает регистрацию 6LoWPAN с RPL. Это важные части управления, но не подтверждения приложения. MLDv2 из RFC 3810 и MPL из RFC 7731 имеют собственные модели состояния; их телеметрию нельзя без доказательства выдавать за состояние RFC 9685.

Сон превращает ожидание пересылки в отдельный эксперимент

RFC 9685 отмечает две особенности маломощного канала. Direct MAC Broadcast может быть ненадёжным. Асинхронный broadcast может требовать, чтобы слушатель оставался бодрствующим. Поэтому при возможности 6LR должен доставлять multicast подписанным листам отдельными unicast MAC-кадрами.

Слово «должен» описывает поведение передатчика, а не наблюдаемый результат получателя. Кадр мог уйти вне окна бодрствования. Повторы могли исчерпаться. Link-layer acknowledgment, если он доступен, может подтвердить приём интерфейсом, но не обработку верхним уровнем. IP-стек может отбросить пакет. Приложение может принять datagram и не выполнить контролируемое действие.

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

Такой журнал не требует обещать телеметрию, которой устройство не умеет давать. Он требует честно назвать отсутствующую ступень. «6LR передал, подтверждения приёма нет» полезнее, чем составное «доставлено» на основании установленной ветви.

Перезагрузка может удалить даже правильную ветвь

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

Это ещё один пример того, почему прошлый зелёный статус не говорит о текущей доставке. Последняя NA остаётся исторически верной. Формально не истёкший срок остаётся правильным числом. Но маршрутизатор уже не держит запись, дерево могло измениться, а спящий лист не получил ничего.

Восстановление следует разложить по времени: boot, обнаружение отсутствия состояния, запрос обновления, новая регистрация, повторная инъекция, DAO и первая подтверждённая доставка. Тогда расследование видит, где именно возник разрыв, а не приписывает его абстрактной «нестабильности mesh».

Область действия и миграция задают границы, но не квитанции

RFC 7346 определяет области IPv6 multicast. RFC 9685 использует Realm-Local для RPL DODAG и Admin-Local, когда трафик проходит федерацию RPL-инстансов. Верно выбранная область ограничивает распространение; она не доказывает, что слушатель бодрствовал внутри неё.

Новый MOP 5 нельзя включить обновлением работающего инстанса. Оператор должен создать новый инстанс и мигрировать узлы. В существующей сети legacy-unicast может остаться в одном инстансе, а multicast и anycast — в другом. Для успеха нужна достаточная плотность способных 6LR; в Storing mode — ещё и непрерывная поддерживаемая структура до Root.

Паспорт устройства или capability-сигнал не подтверждает такую топологию. Нужно доказать, что конкретный лист в конкретный момент достигал подходящего 6LR и что нужный путь существовал. Даже после этого последняя радиопередача остаётся самостоятельной границей.

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

RFC 9685 позволяет RPL-Unaware Leaf получить multicast-службу, не выдавая ему право внедрять сообщения RPL. Это точное ограничение полномочий. Отчётность должна быть столь же точной: Neighbor Discovery отвечает за допуск, RPL — за распространение состояния, радио — за последний переход, приложение — за получение. Дерево может быть исправно, а последняя квитанция отсутствовать.

Источники