Кратко
- RFC 3471 расширил плоскость управления MPLS на коммутацию пакетов, временных слотов, длин волн и волокон, в том числе в устройствах, не читающих заголовки пакетов.
- Обобщённая метка получала смысл из контекста интерфейса: предложение, допустимый набор или успешная сигнализация не доказывали физическое выделение ресурса и доставку трафика.
Исторический ход RFC 3471 состоял в том, чтобы сохранить полезную абстракцию, не объявляя одинаковой всю лежащую под ней физику. В обычном MPLS метка путешествовала с пакетом или ячейкой. GMPLS должен был управлять оборудованием, которое могло вообще не распознавать границы пакетов: оно переключало позицию в цикле, длину волны либо пространственный путь между портами.
Документ вышел в январе 2003 года в потоке стандартов и описывал функции независимо от конкретного протокола. Форматы CR-LDP и RSVP-TE были вынесены в RFC 3472 и RFC 3473, детали отдельных транспортных технологий — в профильные документы. Общей становилась координация, а не материальное устройство сети.
RFC выделил четыре класса интерфейсов. PSC работал с пакетами или ячейками, TDM — с временными позициями, LSC — с длинами волн, FSC — с волокнами и физическими портами. Класс относился к интерфейсу, а не обязательно ко всему узлу. Один аппарат мог соединять разные уровни коммутации.
LSP образовывали иерархию. Несколько пакетных путей помещались в TDM-LSP, тот — в волновой LSP, а затем в волоконный. Агрегация сокращала число состояний, но не создавала наследования доказательств. Наличие внешнего оптического сигнала не перечисляло клиентские потоки, а исправный внутренний путь не подтверждал внешний ресурс.
Generalized Label Request разделял LSP Encoding Type, Switching Type и G-PID. Первый описывал природу сигнала, второй — операцию на конкретном канале, третий — клиентскую нагрузку, значимую главным образом для концов. Кодирование, способ переключения и полезное содержимое были связанными, но отдельными фактами.
Сама обобщённая метка не содержала поля типа. Соседние узлы должны были понимать формат из контекста линии. Это сокращало избыточность, однако превращало происхождение в часть смысла. Число без локального и удалённого интерфейса, направления, класса переключения и технологии не позволяло восстановить физический ресурс.
Непакетные ресурсы были дискретными и дефицитными. Линия могла объявлять поддержку нескольких кодировок, не имея свободного слота или длины волны в момент запроса. Техническая возможность не была квитанцией о свободной ёмкости.
Suggested Label позволяла вышестоящему узлу заранее предложить ресурс и начать настройку медленной оптической матрицы. Нижестоящий узел мог заменить предложение. Такой ход ускорял процесс, но не передавал окончательное право выбора. Надёжная запись должна хранить предложение, замену, итоговый выбор и завершение программирования.
Label Set ограничивал допустимые варианты, например из-за непрерывности длины волны или возможностей оборудования. Вхождение в набор означало «пока разрешено», а не «выбрано», «зарезервировано» или «работает». На следующем переходе пересечение могло оказаться пустым.
Двунаправленный LSP координировал оба направления одной процедурой, чтобы независимые установки не боролись за взаимные ресурсы. При одновременных запросах правило по идентификатору исходного узла определяло победителя. Оно устраняло гонку управления, но ничего не говорило о коммерческом приоритете, симметрии оптики или результате приложения.
Разделение каналов управления и данных стало отдельной операционной границей. IP-сигнализация могла идти не по тому пути, что оптическая цепь. Поэтому живая управляющая смежность не исключала обрыва данных. И наоборот, настроенное соединение могло продолжать пропускать свет после потери управления. Индикатор «работает» требовал указать, какую плоскость наблюдали.
Сведения о защите и административном статусе оставались намерениями. Запрос защиты не доказывал разнообразие или резерв ёмкости. Аутентификация сообщения подтверждала отправителя, но не положение физического переключателя и не доставку нагрузки.
RFC 3945, RFC 4201–4204 и RFC 4328 развили архитектуру, агрегирование каналов, маршрутизацию, OSPF, управление линиями и G.709. Они показывают эволюцию стандартов, но не всеобщее внедрение каждой функции.
Принцип Heng Lu о первичности работающего кода отделяет знак от результата. Минимальная начальная спецификация объясняет скромный общий слой. Разделение уровней реальности не даёт слить способность, ограничение, предложение, выделение, состояние оборудования, сигнал и услугу в один зелёный статус.
Полная цепочка начинается с интерфейсов и контекста переключения. Она сохраняет объявленные возможности, текущие ограничения, автора предложения и владельца решения, итоговые метки обоих направлений, результат настройки и путь управления. Затем отдельно измеряются физическая непрерывность, качество сигнала, приход нагрузки и эффект для приложения. RFC 3471 не превратил фотоны в пакеты; он дал им общий язык координации, не объявляя язык доказательством работающего мира.
Источники
- RFC 3471
- RFC 3471 в текстовом виде
- Карточка IETF Datatracker
- История IETF Datatracker
- Поиск исправлений RFC 3471
- RFC 3031: архитектура MPLS
- RFC 3209: RSVP-TE
- RFC 3472: расширения CR-LDP для GMPLS
- RFC 3473: расширения RSVP-TE для GMPLS
- RFC 3945: архитектура GMPLS
- RFC 4201: агрегирование каналов
- RFC 4202: требования маршрутизации GMPLS
- RFC 4203: расширения OSPF для GMPLS
- RFC 4204: протокол управления линией
- RFC 4328: сигнализация G.709
- Heng Lu: первичность работающего кода
- Heng Lu: минимальная начальная спецификация
- Heng Lu: уровни реальности
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
