Кратко

  • RFC 3472 выразил GMPLS через REQUEST, MAPPING и TLV протокола CR-LDP; обратное направление могло стать доступным до возврата прямых меток.
  • Пересланный REQUEST, допустимый Upstream Label или первый трафик в одну сторону были частичными чеками, а не доказательством двусторонней услуги.

Слово «двунаправленный» обещает единый момент готовности. В процедуре RFC 3472 два направления могли стать реальными в разное время.

Документ вышел в январе 2003 года в потоке стандартов и придал функциям RFC 3471 форму сообщений и TLV CR-LDP. Запросы, метки, диапазоны, предложения, наборы, защита, административное состояние и интерфейсы получили кодирование. Для RSVP-TE эту роль выполнял RFC 3473.

REQUEST двунаправленного LSP содержал Upstream Label. Он должен был быть пригоден для пересылки уже при отправке. Каждый получатель проверял его. Перед дальнейшей передачей промежуточный узел выделял исходящую обратную метку и создавал внутренний путь между локальными сегментами.

Когда REQUEST достигал терминатора, тот мог сразу отправлять трафик к инициатору. Второе направление ещё ждало Generalized Labels, возвращавшиеся в MAPPING и устанавливавшиеся на каждом переходе.

Поэтому обратный трафик при незавершённом прямом MAPPING был законным промежуточным состоянием. Доставка REQUEST не подтверждала обе стороны, физическую непрерывность и успешный диалог приложения.

Generalized Label Request распределял и другие проверки. Вход задавал кодирование и G-PID; Switching Type мог меняться по пути. Узел проверял вход, собственные возможности и выход или туннель. Локальная политика решала вопрос Forwarding Adjacency. Передача сообщения не означала одной одинаковой проверки всюду.

G-PID обычно оценивал выход, с исключением PSC/PHP. Отсутствие ранней ошибки не было окончательным разрешением клиентской нагрузки.

Suggested Label оставалась предложением. Ошибки игнорировались; иной ответ снизу требовал перенастройки или отказа. Вход не должен был передавать данные до возврата соответствующей метки. Предварительная настройка не давала права окончательного выбора.

Label Set описывал допустимость, а не наличие. Значения и диапазоны включались или исключались; отсутствие TLV означало приемлемость всех значений, не их свободу. Узел пересекал набор с реальными ресурсами. Пустой результат прекращал запрос.

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

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

Explicit Label Control связывал Label ER-Hop с предыдущим адресом или IF_ID. Ошибки порядка и направления отклоняли маршрут. Как головной узел получал сведения, оставалось вне документа.

При разделённых управлении и данных IF_ID называл канал и возвращался в MAPPING. Сбой вневолоконной сигнализации не должен был влиять на существующее оптическое соединение; восстановление управления не доказывало правильность старого кросса.

CR-LDP не имел быстрой RSVP-нотификации. RELEASE и WITHDRAW распространялись от отказа и освобождали ресурсы. Удаление делало обе метки недействительными; последующий трафик был бы устаревшим состоянием.

RFC 3468 позже записал решение IETF прекратить стандартную разработку CR-LDP в пользу RSVP-TE. Это объясняет институциональный путь, но не стирает механику и не доказывает мгновенное исчезновение реализаций.

Принцип Heng Lu о работающем коде отделяет сообщение от эффекта. Минимальная спецификация оставляет локальную политику локальной. Уровни реальности разделяют допуск, выделение, внутренний путь, MAPPING, трафик и приложение.

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

Источники