Кратко

  • XRO действует на всём пути, а EXRS ограничивает участок внутри ERO. Оба исключают ресурсы из множества кандидатов, но не назначают уцелевший маршрут.
  • Сброшенный бит L означает MUST exclude, установленный бит L — SHOULD avoid; во втором случае локальная политика всё ещё может разрешить прохождение.
  • Разнообразие — результат, который нужно проверить по маршруту, топологии и ресурсам, а не обещание, переносимое одним флагом.

Что делает узел вычисления

RFC 3209 определяет Explicit Route Object для включения абстрактных узлов в RSVP-TE путь. RFC 4874 добавляет сигнализацию явных исключений, когда входному узлу не требуется вычислять весь маршрут. XRO может обозначать префиксы IPv4 или IPv6, ненумерованные интерфейсы, автономные системы и Shared Risk Link Groups; формы для префикса и интерфейса позволяют различать свойства интерфейса, узла и SRLG. EXRS является субобъектом ERO и действует только в пределах заданного сегмента.

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

Если обязательное исключение XRO противоречит включению в ERO, приоритет имеет исключение. Узел должен отклонить Path и вернуть определённую ошибку Routing Problem. Если правила исключения оставляют ноль вариантов пересылки, следует вернуть PathErr с указанием, что маршрут заблокирован Exclude Route. Слишком сложный для реализации или политики XRO также может привести к специальному PathErr. Это отказ установления, а не автоматический выбор резервного маршрута.

Узел, не поддерживающий XRO, может переслать его без анализа благодаря номеру класса XRO. Неподдерживаемые субобъекты или атрибуты также могут быть проигнорированы. Значит, наличие объекта в сообщении не доказывает, что каждый узел его понял. Record Route должен использоваться вычисляющими узлами для обнаружения нарушения и попытки перерасчёта, если реализация это допускает. На границе домена значение имеют безопасность, при которой обычные сведения ERO удаляются, и различия в поддержке downstream-реализаций.

Полный путь, сегмент и ссылочное знание

XRO ограничивает весь путь; EXRS ограничивает сегмент. Это различие особенно важно при построении неперекрывающихся защитных LSP: после записи первого пути его узлы или риски можно исключить перед расчётом второго. Но механизм не выдаёт второй путь и не доказывает его существование или физическое разделение. В новом вычислительном домене исключение может стать нерелевантным, если его ресурс там отсутствует; при перерасчёте оно может быть добавлено или снято. Инициатор, узел вычисления и downstream-орган, фактически реализующий сигнал, должны понимать, кто сохраняет, разрешает и проверяет ограничение.

RFC 6001 обновляет RFC 4874 для многоуровневого и многорегионального GMPLS. Он добавляет XRO-субобъекты для switching capability и label exclusions, сохраняя различие между обязательным исключением и рекомендацией избегать. RFC 8390 добавляет diversity XRO и EXRS с идентификатором, назначенным клиентом, PCE или сетью для ссылочного LSP или пути, когда инициатор не знает всех его ресурсов. Это может сократить раскрытие топологии и требуемое знание у инициатора, но переносит проверку на PCE или сеть, разрешающую идентификатор.

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

Власть, выгоды и цена

Инициатор получает отрицательное полномочие: он может сделать названные ресурсы недопустимыми. Узел вычисления сохраняет полномочие выбрать любой оставшийся маршрут — либо признать, что его нет. Выигрывают сервисы, которым нужны раздельные интерфейсы, узлы, SRLG или ссылочные пути. Цена — уменьшение допустимого множества, большее состояние сигнализации, возможное раскрытие топологии и зависимость от поддержки на всех границах. Без исключения расчёт может снова использовать нежелательный ресурс. При чрезмерных обязательных исключениях установление не состоится.

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

Анализ Elias Ward: Обязательное исключение превращает предпочтение в ограничение с отказом при невозможности соблюдения. Это помогает потребителю, которому нужно разнообразие, но уменьшает множество решений. Источник не устанавливает, какие операторы или поставщики поддерживают каждую субфункцию, не доказывает живую достижимость маршрута, внедрение, инциденты, измеренное качество, задержку установления, частоту отказов или влияние на клиентов. В пакете нет внешних обвинений. Неизвестно, приводит ли заявленное разнообразие в конкретной сети к физически раздельным путям; это требует операционной проверки.

Практические фикстуры проверки

  1. Один обязательный ресурс: создай два возможных перехода и включи один интерфейс с очищенным L-битом в XRO. Проверь, что выбранный путь не использует интерфейс; не приписывай XRO выбор второго пути.
  2. Противоречие ERO: включи ту же ресурсную сущность в ERO и обязательный XRO. Ожидай отклонение Path и Routing Problem.
  3. Полная блокировка: исключи все варианты пересылки. Ожидай PathErr о блокировке Exclude Route.
  4. Сложность: отправь XRO, превышающий возможности реализации или политики; проверь специальный PathErr о чрезмерной сложности.
  5. Два значения L: повтори тест с установленным L-битом. Зафиксируй SHOULD avoid и возможность локального прохождения; не трактуй его как MUST.
  6. Неподдерживаемый узел: пропусти XRO через узел без поддержки или используй неподдерживаемый субобъект; проверь Record Route и возможность перерасчёта.
  7. GMPLS-слои: протестируй исключение switching capability и label по RFC 6001 в нескольких слоях; проверь сохранение семантики MUST/SHOULD.
  8. Ссылочная разнообразность: примени идентификатор клиента, PCE или сети по RFC 8390, затем проверь противоречивый и неподдерживаемый идентификаторы и их сохранение через границу.
  9. Итоговая проверка: сопоставь Record Route с топологией и фактическими ресурсами. Успешное сигналирование само по себе не доказывает физического разнообразия.

Решение оператора

Сначала определи бенефициара и область действия ограничения. Выбирай MUST, когда повторное использование хуже отказа установления; выбирай SHOULD, когда важнее доступность. Проверь поддержку XRO, EXRS, RFC 6001 и RFC 8390 в каждой доменной и административной границе. Заранее определи реакцию на PathErr и ситуацию пустого допустимого множества. После установления сравни Record Route, ссылочный идентификатор и топологию. Если совпадение не доказано, разнообразие следует считать неподтверждённым.

Источники