Кратко

  • Управляющая волна RREQ идёт от OrigNode к TargNode, но найденный ею маршрут несёт данные в обратную сторону; поиск RREP строит второе направление данных.
  • Адреса концов, локальные InstanceID и шестибитная Delta не дают смешать параллельные поиски, но не подтверждают текущее состояние пересылки.
  • Надёжное утверждение о двустороннем сервисе требует согласованных по времени свидетельств для обоих маршрутов, обоих потоков пакетов и завершённого обмена запросом и ответом.

Ответ не мог просто занять дорогу запроса

В Low-Power and Lossy Network слышимость не обязана быть взаимной. Мощность, помехи и расписание могут сделать одно направление приемлемым для Objective Function, а обратное — нет. RFC 9854 добавляет к RPL реактивный поиск AODV именно для того, чтобы такая асимметрия имела явное представление.

Временная RREQ-Instance укоренена в OrigNode, и RREQ-DIO распространяются к TargNode. Но восходящий маршрут к этому корню обслуживает данные от цели к источнику. Управление RREP движется от цели к источнику и при асимметрии строит вторую DODAG с корнем в TargNode. Её маршрут несёт данные от источника к цели. Для обеих инстанций направление управляющего сообщения противоположно направлению обслуживаемых данных.

Бит S начинается с единицы и сохраняется, только если на каждом переходе обратное направление тоже удовлетворяет Objective Function. При S=1 цель может вернуть RREP по unicast через известный вектор или запись, не создавая вторую DODAG. При S=0 цель создаёт RREP-Instance и рассылает RREP-DIO по multicast; узлы могут выбрать других preferred parents. «Двусторонний» здесь значит два найденных направления, а не одну симметричную цепочку.

И даже S=1 имеет узкий смысл. RFC не предписывает единого теста симметрии: ETX/RSSI — лишь пример наряду с предварительным знанием, тестовым трафиком и OAM. Это заявление участников при выбранной методике и в определённый момент, а не вечное измерение радио и не квитанция позднейшей пересылки.

Delta связывает состояние, но не результат

RPLInstanceID назначается локально. Между теми же концами могут одновременно идти поиски с разными Objective Functions, а разные источники вправе выбрать одинаковое число. Поэтому идентичность RREQ-Instance соединяет локальный номер с IP-адресом OrigNode; для RREP используется номер и адрес TargNode.

Если ожидаемое значение RREP уже занято активной инстанцией с тем же DODAGID, цель выбирает другое. Шестибитная Delta фиксирует, на сколько увеличено полученное значение RREQ; арифметика выполняется по модулю 256. Получатель вычитает Delta, чтобы при установке маршрута к цели восстановить номер парного RREQ. DODAGID добавляет контекст конца, которого недостаточно в одном октете.

Механизм устраняет реальную ошибку управления: состояние одного поиска или Objective Function нельзя присоединить к другому. Он доказывает, что корректный получатель способен распознать пару. Он не доказывает установку на всех нужных узлах, сохранность записей, общую эпоху двух направлений или использование маршрута пакетом.

Rank, последовательность и время отвечают на разные вопросы

Rank обозначает относительное положение узла в версии DODAG, а не обязательно расстояние или стоимость пути. RFC 9854 повторяет предупреждение базового RFC 6550; метрики и ограничения для Objective Function перечислены отдельно в RFC 6551. Низкий Rank нельзя превращать в измеренную доступность сервиса.

Номера последовательности защищают логическую свежесть. OrigNode увеличивает свой номер при новом поиске. Состояние к источнику хранит Orig SeqNo, а состояние к цели — ART Destination Sequence Number. Совпадающую, но устаревшую запись следует удалить. Это упорядочивает поколения, но не свидетельствует об установке в оборудовании и не измеряет живую связь.

Время тоже разделено. Поле L ограничивает участие во временной инстанции и прямо не зависит от route lifetime. Срок маршрутной записи задаётся конфигурацией DODAG и может продлеваться фактическим использованием. «Инстанция активна», «маршрут не истёк» и «пакет недавно замечен» — разные часы; сводить их к одному зелёному индикатору нельзя.

Hop-by-hop и source routing оставляют разные следы

При H=1 промежуточные маршрутизаторы создают записи с источником, инстанцией, назначением, next hop, сроком и последовательностью. В симметричном случае для пути к цели next hop может быть отправителем RREP; в асимметричном он следует preferred parent второй DODAG. Квитанция установки должна назвать направление, узел, next hop, поколение и срок истечения.

При H=0 путь несёт Address Vector. Асимметричный вектор RREP перечисляет узлы, через которые действительно прошла вторая управляющая волна; в симметричном случае цель возвращает первый вектор без изменений. Проверка повторных адресов уменьшает риск петли, но вектор остаётся управляющим объектом. Он не показывает, что каждый интерфейс был достижим, когда позднее шёл пакет.

После получения RREP OrigNode, по формулировке RFC, может начать передачу данных приложения. «Может начать» завершает discovery и открывает область фактов, которых протокол не создаёт. Первый пакет может встретить истёкшую запись, новую асимметрию, перегрузку или приложение без ответа.

Пять квитанций для одного кругового обмена

Первая квитанция — идентичность discovery: оба адреса и DODAGID, числовые InstanceID, Delta, Objective Function, H и S, последовательности, часы временных инстанций и наблюдатель. Вторая независимо описывает маршрут TargNode→OrigNode, найденный RREQ: записи по нужным узлам либо точный вектор. Третья делает то же для OrigNode→TargNode после RREP; набор узлов может отличаться.

Четвёртая квитанция — направленное наблюдение пакетов. Счётчику или probe нужны окно времени, знаменатель, история сбросов, источник, цель и контекст инстанции. Успех в одну сторону доказывает только одну сторону; даже две успешные проверки из разных эпох не означают одновременную работоспособность.

Пятая принадлежит приложению. Она связывает уникальный запрос в OrigNode с принятием на цели, формированием ответа и его возвратом до заявленного срока. Это и есть факт сервиса. Его нельзя вывести из парного управляющего обмена.

Безопасность ограничивает говорящих, но не исходы

RFC 9854 наследует необязательную защиту RPL и ссылается на анализ угроз в RFC 7416. Участнику нужен ключ защищённого поиска, однако злонамеренный маршрутизатор с ключом всё равно способен сообщать ложные данные, вводить discovery или менять replies. Вредоносный source vector может создать петлю, поддельный gratuitous RREP — поддержать denial of service.

Аутентификация повышает уверенность в обработке управляющего сообщения внутри настроенного домена; она не превращает маршрутизатор в независимого свидетеля конечного сервиса. Реестр IANA RPL содержит MOP 4 и коды опций RREQ, RREP и ART. Регистрация подтверждает общий формат, а не развёртывание.

Страница RFC Editor, запись Datatracker и поиск errata подтверждают статус Proposed Standard, историю публикации и отсутствие найденной errata на момент проверки. Они не дают переписи реализаций и результатов сервиса.

Принцип Heng Lu Running-Code Primacy отделяет спецификацию от работающей реальности. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption удерживает общие правила минимальными, а локальную проверку — явной. Эссе об уровнях реальности задаёт последнюю границу: символически аккуратная пара не заменяет исполнимые свидетельства маршрутов, пакетов и приложения.

Источники