Кратко

  • RFC 2370 поместил данные приложений в Opaque LSA типов 9, 10 и 11 с областями распространения в пределах канала, области и автономной системы.
  • O-бит, подтверждение и запись в LSDB доказывали способность и транспорт протокола, но не понимание, актуальность, расчёт пути, установку пересылки или реальную доставку трафика.

В июле 1998 года OSPF получил не новую формулу маршрута, а общий конверт. Его заголовок подчинялся известным правилам link-state базы, а тело могло принадлежать будущему приложению. Протокол умел надежно обращаться с объектом, не выдавая это умение за знание его смысла.

Слово Opaque не означало шифрование. LSA сохраняла возраст, Options, тип, Link State ID, Advertising Router, номер последовательности, контрольную сумму и длину. Затем шли выровненные по 32 битам данные приложения. OSPF владел жизненным циклом оболочки; смысл, полномочия и действие оставались у отдельной спецификации и работающей программы.

Это был тонкий общий слой: идентичность, область, flooding, повторная передача, подтверждение, старение и хранение. Расширение могло использовать зрелую систему распространения, не превращая базовый документ в универсальный источник будущих решений.

Тип указывал не важность, а границу распространения

Тип 9 оставался на локальном канале. Реализация должна была помнить связанную интерфейсную область и не переносить объект на другой канал. Тип 10 оставался внутри OSPF area. Тип 11 распространялся по AS по правилам, близким к внешним LSA, но не входил в stub area.

Scope был исполняемым ограничением. Верная контрольная сумма не давала типу 10 права пройти через ABR. Тип 11, полученный внутри stub area, нарушал контракт и подлежал отклонению. Отправитель и получатель вместе отвечали за то, чтобы локальное заявление не превратилось в глобальное.

Link State ID делился на восьмибитный Opaque Type и 24-битный идентификатор экземпляра. Эта пара помогала найти потребителя. Она не доказывала истинность тела, предметные полномочия источника или необходимость действия.

O-бит описывал переносчик, а не всех читателей

Во время обмена Database Description маршрутизатор сообщал O-битом готовность принимать и пересылать Opaque LSA. Только способные соседи включали их в сводку базы и списки повторной передачи. Неспособный сосед мог случайно услышать multicast и отбросить неизвестный LS type.

Сигнал отвечал на узкий вопрос о механизме переноса. Он не перечислял Opaque Types, для которых на узле установлено приложение. Маршрутизатор мог добросовестно переносить данные, которых не понимал. Приложение могло существовать, но видеть неполную топологию из-за разрыва способности по пути.

Поэтому синхронизацию LSDB нельзя считать сходимостью приложения. OSPF сохраняет допустимую по области LSA и подтверждает её. Потребитель выбирает тип, разбирает тело, проверяет источник и свежесть, сопоставляет другие состояния и применяет политику. Строка LSDB — квитанция переносчика, не приложения.

Новая последовательность могла нести старый факт

Opaque LSA наследовали sequence number, checksum, LS age, MaxAge, MinLSInterval, MinLSArrival, retransmission и acknowledgement. Каждый механизм отвечал на отдельный вопрос. Контрольная сумма защищала байты, а не семантику. Последовательность упорядочивала экземпляры, но не датировала исходное измерение. Ack подтверждал приём соседом, не использование.

Разрыв особенно проявился у типа 11. RFC 5250 заменил RFC 2370, потому что маршрутизаторы вне области источника могли до примерно часа использовать AS-wide информацию после отказа источника. Новая версия связала источник с видимой достижимостью ASBR и потребовала прекратить использование его Opaque LSA после потери этой достижимости.

Исходное flooding могло работать по спецификации, пока приложение пользовалось устаревшим утверждением. Широта распространения не создавала истинность. Доступность автора стала отдельным доказательством.

Traffic Engineering показал перенос без автоматического исполнения

RFC 3630 использовал Opaque LSA типа 10 для атрибутов traffic engineering. Узлы без TE-логики могли пересылать их как непрозрачные объекты, а потребители строили TE-базу. Новому приложению не потребовался собственный протокол распространения.

Но получение LSA не запускало результат. Изменение обновляло TE-базу без обязательного обычного SPF. Инстанцирование пути оставалось отдельной операцией, а частичное участие могло оставить пробелы в расширенной топологии. Синхронизированная LSA, полная модель, рассчитанный путь, установленное состояние и наблюдаемый трафик требовали разных записей.

RFC 7684 позднее применил канал к расширенным атрибутам префиксов и каналов. Нынешний реестр IANA сохраняет типы 9, 10 и 11 и последующие пространства. Он подтверждает назначение идентификатора, а не развертывание в конкретной сети.

Аутентификация также не объединяла слои. OSPF мог защищать обмен, а RFC 5709 добавил HMAC-SHA. Это связывало пакет с участником под настроенным ключом. Приложение всё ещё решало, вправе ли участник заявлять конкретное свойство, согласуется ли оно с другими данными, достаточно ли оно свежо и разрешено ли действие. Множество разных аутентифицированных LSA также могло расходовать память и процессор.

Такой дизайн соответствует Running-Code Primacy и минимальной начальной спецификации Heng Lu. Общий слой содержит только детерминированные правила совместимости. Поздние расширения становятся реальностью через реализацию, развертывание и добровольное принятие. Публикация создаёт возможность, но не маршрут и не результат.

Источники