Кратко

  • RFC 3626 выбирает MPR из симметричных одношаговых соседей, чтобы покрыть строгих двухшаговых соседей, сократить повторную передачу контроля и распространить достаточные сведения о связях. Это локальное условие управления, а не подтверждение доставки данных.
  • Более позднее разделение flooding MPR и routing MPR помогает разнести квитанции: кто передал управление, какие связи попали в расчёт, какая запись установлена в системе, куда прошёл пакет и что приняло приложение.

Одна аббревиатура скрывала две работы

Узел OLSR выбирает часть симметричных соседей как multipoint relays. Выбранные соседи помогают распространять широковещательные сообщения. Узлы, выбранные другими, также объявляют как минимум связи со своими MPR-селекторами в сообщениях Topology Control. Благодаря этому сеть получает достаточно материала для расчёта маршрутов при меньшем числе передач.

Инженерная экономия реальна. Но слово MPR легко превращается в слишком крупный статус: «этот узел обеспечивает достижимость». На самом деле в одной роли соседствуют по меньшей мере две обязанности — доставка управления и участие связей в построении маршрута.

RFC 3626 опубликован в октябре 2003 года как Experimental-протокол для мобильных самоорганизующихся сетей, а не как стандарт Интернета. Он определяет Optimized Link State Routing Protocol. Более поздний RFC 7181 для OLSRv2 уже различает flooding MPR и routing MPR, допускает разные метрики и разные наборы.

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

HELLO создаёт локальный материал для обеих ролей

HELLO передаётся локально на интерфейсе и никогда не пересылается. С его помощью узел обнаруживает связи, поддерживает соседей одного и двух шагов, получает willingness и сообщает, кого выбрал MPR.

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

MPR выбираются из симметричных одношаговых соседей так, чтобы через них были покрыты все симметричные строгие двухшаговые соседи. MPR_COVERAGE может увеличить число покрытий. Но покрытие считается на сообщённом графе; оно не измеряет полосу, помехи, очередь или независимость причин отказа.

Для доказуемого решения нужно сохранить интерфейс, отправителя HELLO, время приёма, срок, набор соседей, источник willingness, кандидатов и итог. Без входных данных набор MPR показывает, кому делегировали работу, но не почему.

Flooding MPR отвечает за распространение управления

В логике OLSRv2 flooding MPR выбирается для ретрансляции управляющих сообщений. Это подчёркивает самостоятельную цель: охватить нужную область сети с меньшим количеством передач.

Даже идеальное выполнение этой функции не говорит, какие связи следует предпочесть в маршруте. Метрика исходящего распространения может отличаться от метрики входящей связи, нужной для пути. Узел может хорошо разносить broadcast и плохо вести unicast.

Именно такой разрыв уже перечислен в разделе безопасности RFC 3626: узел способен без изменений передавать широковещательные сообщения управления и одновременно не пересылать одноадресные данные. Следовательно, счётчик ретрансляций не может закрыть инцидент доставки.

Квитанция функции должна содержать получение сообщения, отношение MPR selector, решение о пересылке, выходной интерфейс и наблюдение ниже по ветви. Она подтверждает распространение управления в измеренной области — не больше.

Routing MPR отвечает за материал маршрута

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

В RFC 3626 TC должен включать по меньшей мере связи к узлам, выбравшим отправителя MPR. ANSN упорядочивает изменения объявленного набора, включая переполнение номера. Получатели сохраняют временные topology tuples и рассчитывают собственные таблицы.

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

Квитанция маршрутизации объединяет originator, ANSN, все фрагменты, интерфейсы приёма, срок действия, решение о принятии и получившуюся версию топологии. Затем она связывает эту версию с расчётом пути.

Duplicate set помнит сообщение, а не всю рассылку

Чтобы не обрабатывать одну и ту же копию многократно, OLSR ведёт duplicate set по originator и sequence. Совпадение означает, что этот узел уже зарегистрировал данную идентичность в пределах срока.

Это не коллективное подтверждение. Одна ветвь могла получить сообщение, другая — потерять. Решение о повторной передаче зависит от интерфейса, selector-отношения и предыдущего состояния.

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

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

Два набора управления всё ещё не являются пакетом данных

RFC 3626 прямо говорит: OLSR сам не пересылает пакеты данных. Он обслуживает таблицу маршрутизации операционной системы, которая должна пересылать их.

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

Поэтому после квитанций flooding и routing нужны версия вычисления, изменение в kernel, фактическая строка, next-hop resolution, счётчики интерфейса и наблюдение пакета. Потери, дублирование, порядок и задержка измеряются отдельно. Последнюю квитанцию выдаёт приложение.

Разделение не усложняет картину искусственно. Оно отражает реальные владельцы и реальные точки отказа.

Время создаёт расхождение между наборами

HELLO, selector и topology tuples имеют сроки. Пропущенное обновление не удаляет их сразу. Пока один узел удерживает старую запись, другой может уже пересчитать MPR. Набор для flooding и набор для routing также могут изменяться не одновременно.

Sequence numbers защищают порядок, но не непрерывно измеряют среду. Корректно упорядоченное состояние может устареть внутри допустимого окна.

Мониторинг должен показывать возраст последнего HELLO и TC, оставшийся срок, пропущенные интервалы и зависимые решения. Иначе команда может увеличить hold time, улучшить видимую стабильность и одновременно расширить окно устаревших маршрутов.

Разные функции требуют разных бюджетов времени. Быстрая реакция распространения не гарантирует такой же скорости пересчёта и установки пути, а ни одна из них не задаёт время восстановления приложения.

HNA добавляет внешнего владельца решения

HNA позволяет шлюзу объявлять сеть, связанную с интерфейсом вне OLSR. Получатели хранят адрес шлюза, сеть, маску и срок и могут добавить маршрут. HNA исчезает по истечении, а не через тот же механизм отмены ANSN, что TC.

Flooding MPR может успешно разнести HNA. Routing-функция может успешно построить путь к шлюзу. Ни одна не доказывает право отправителя объявлять внешний prefix или доступность внешнего участка.

Нужен отдельный principal и политика импорта: какая идентичность может объявлять какой диапазон, через какой интерфейс, на какой срок и как отзыв происходит до истечения. Протокольная роль не создаёт внешнее полномочие.

Это граница между записью и реальностью в смысле Heng Lu. Запись способна точно сохранить утверждение. Право делать утверждение и результат его выполнения приходят из других источников.

Аутентификация не объединяет функции

RFC 3626 не задаёт специальных мер безопасности. Он предупреждает о раскрытии топологии, ложных HELLO, TC и HNA, подмене, изменении, непередаче, неверном выборе MPR и replay и рекомендует аутентификацию.

Аутентичность целого сообщения отличается от аутентичности каждой объявленной связи. Подпись связывает байты с credential, но не доказывает существование соседа, право на prefix или свежесть. Ранее правильное подписанное сообщение можно повторить, поэтому нужна временная защита.

Позднейшие RFC разработали форматы, обнаружение соседей, целостность и анализ угроз. Эти механизмы улучшают отдельные квитанции. Они не дают одному участнику права свидетельствовать сразу за распространение, маршрут, данные и приложение.

Разделение ролей защищает результат

Названия flooding MPR и routing MPR полезны не только разработчику протокола. Они не позволяют управлению превратиться в одну зелёную лампу.

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

Каждый владелец говорит только о своей поверхности. Именно так работающий код сохраняет практический авторитет, не присваивая себе авторство реальности.

Источники