Кратко

  • RFC 3476 поместил объекты оптического UNI от OIF в публичные пространства LDP и RSVP, но содержание и правила применения оставил спецификации OIF.
  • Разнесение или уровень обслуживания могли быть недоступны, соединение — неизвестно, а отправитель или получатель — не уполномочен. Правильно прочитанный код был первым свидетельством, а не итогом.

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

RFC 3476 был опубликован в марте 2003 года со статусом Informational, а не Internet Standard. Optical Internetworking Forum разработал сигнализацию для оптического User Network Interface, UNI. Задача состояла в максимальном повторном использовании LDP, RSVP, RSVP-TE и GMPLS. Лишь немногим специфическим элементам UNI требовались новые идентификаторы в пространствах протоколов IETF.

Для LDP документ перечислил по три TLV Source ID и Destination ID в формах IPv4, IPv6 и NSAP. К ним добавились Egress Label, Local Connection ID, Diversity, Contract ID и UNI Service Level. Значения лежали в диапазоне от 0x0960 до 0x0970. В RSVP появился GENERALIZED_UNI с номером класса 229 и C-Type 1, а также UNI_IPv4_SESSION с классом 1 и C-Type 11. Подобъекты несли исходный и конечный TNA, требование разнесения, выходную метку и уровень обслуживания.

Точность таблицы не превращала её в полное определение услуги. Для многих полей RFC прямо отсылал содержание и применение к спецификации UNI от OIF. Публичный номер создавал устойчивую ссылку. Внешнее соглашение объясняло смысл. Реальная сеть всё равно должна была проверить личность, полномочия, политику и наличие ресурсов.

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

Не все элементы становились публичными. Специальные статусные коды LDP для UNI находились в диапазоне Private Use 0x3Fxxxxxx и не требовали управления IANA. Два сообщения, Status Enquiry и Status Response, уже устарели, поэтому номера для них не запрашивались. Реестр отражал отбор: одни конструкции получили публичную идентичность, другие остались частными, третьи исчезли до назначения.

Лучше всего предел виден в ошибках RSVP. Сеть могла ответить Diversity not available, Service level not available или Invalid/Unknown connection ID. Policy Control Failure различал Unauthorized sender и Unauthorized receiver. Во всех этих случаях номер был понят. Отказ возникал на следующем уровне — там, где решались политика, состояние и ресурсы.

Объект GENERALIZED_UNI может иметь правильные класс, C-Type, длину и подобъекты. Его адреса TNA могут быть корректны. Это не доказывает, что отправитель вправе заказать канал, получатель согласен, два независимых маршрута существуют, а ёмкость свободна. Синтаксическая корректность и эксплуатационная выполнимость требуют разных квитанций.

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

Соседние RFC сохраняли разделение. RSVP управлял состоянием резервирования, RSVP-TE добавлял сигнализацию туннелей, LDP распределял метки, GMPLS распространял понятие метки за пределы пакета. RFC 3471–3475 различали идентичность, обмены, уведомления, Call и Connection. RFC 3476 добавил числовой шов для UNI, но не отменил остальные этапы.

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

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

Дисциплина слоёв реальности Heng Lu начинает проверку с сырого сообщения. Следует хранить протокол, значение, длину, биты U/F либо class/C-Type и результат парсера. Затем значение разрешается по датированному снимку реестра и точным редакциям RFC и OIF. Идентичность, аутентификация, авторизация, допуск, маршрут, резерв, программирование оборудования, сигнал, трафик и результат услуги связываются отдельными доказательствами.

Читаемый Source ID не равен подтверждённому полномочию. Подобъект Diversity не доказывает два независимых пути. Service Level не является выполненным SLA. Egress Label не является актом физической приёмки. Отсутствие ошибки также не подтверждает положительно все последующие действия.

Путь отказа надо сохранять полностью: объект ошибки, код, подкод, отправивший узел, время и исходный запрос. «Diversity not available» информативнее общего сбоя, но не удостоверяет всю скрытую топологию и не исключает устаревшие данные о ресурсах или альтернативный вариант.

RFC 3476 важен как история ограниченной координационной власти. Публичный реестр позволяет независимым реализациям назвать один и тот же объект. Это необходимая инфраструктура, но не суверенитет над услугой и не доказательство её существования. Номер открывает дело; закрыть его могут только квитанции следующих слоёв.

Источники