Кратко

  • RFC 5152 задаёт посекционное вычисление междоменного TE LSP, когда головной LSR не видит полный путь или не может передать его целиком.
  • Доменом может быть автономная система, область IGP, оверлей или рекурсивно вложенная вычислительная область.
  • Граничный LSR использует локальную TED, сведения о достижимости, возможности и политику, поэтому последующие решения могут опираться на иной или более свежий срез состояния.
  • ERO может сочетать строгие и свободные переходы: часть выбора фиксируется заранее, а часть раскрывается на границах.
  • Выход из домена может быть задан статически или найден через IGP, BGP либо policy; его достижимость не означает глобальной оптимальности.
  • При невозможности построить следующий участок PathErr возвращает ошибку; crankback может проверить другой выход.
  • Головной узел может повторить тот же свободный маршрут, если подозревает устаревшую нижестоящую IGP-TE информацию.
  • Он также может задать другую последовательность переходов или ослабить ограничения, но тогда меняется проверяемая гипотеза.
  • RFC 5152 прямо предупреждает, что доменное вычисление не гарантирует оптимальный междоменный путь.
  • Пример A-B-C-D показывает: первый допустимый путь способен заблокировать второй, хотя пара A-C-D и A-B-D существует.
  • Поэтому неудача второй попытки условна относительно первого пути, порядка поиска, видимости, состояния TED, исключений и алгоритма.
  • Для отрицательного вывода нужны журналы исходной задачи и пространства поиска; одного PathErr, числа повторов или последующего успеха недостаточно.

Успешный повтор отвечает только за свою версию мира

Когда операция после повторного запуска завершается успешно, естественно заключить, что система восстановилась. Но причина успеха принципиальна. Обновилась ли Traffic Engineering Database? Был ли выбран другой выход из домена? Изменилась ли последовательность свободных переходов? Снизилась ли требуемая полоса или ослабла другая характеристика сервиса?

Каждый вариант создаёт новую постановку задачи. Повтор после обновления TED проверяет, существует ли путь в более свежем представлении сети. Смена egress проверяет другой локальный ответвлённый вариант. Ослабление ограничения проверяет, можно ли предоставить уже не ту же самую услугу, а близкую. Объединять их в запись «повтор успешен» — значит потерять границу между восстановлением и изменением контракта.

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

Путь собирается из снимков, сделанных разными властями

Междоменное вычисление нужно там, где головной LSR не располагает полной сквозной топологией. Сообщение RSVP-TE Path передаёт известный маршрут и назначение до границы; иногда оно содержит последующие границы или идентификаторы доменов. Boundary LSR вычисляет участок, которым вправе управлять, используя собственную TE-информацию и политику.

Архитектура применима к AS, областям IGP и другим вычислительным доменам. Она может повторяться рекурсивно внутри автономной системы, разделённой на области или субдомены. Ответственные за вычисление узлы находятся на самом LSP, а не наблюдают его из единого центра.

Поэтому итог строится не только из разных фрагментов карты, но и из разных моментов времени. Граница выше по маршруту могла принять решение по данным, которые уже расходятся с downstream TED. Даже честная и корректная локальная процедура не гарантирует, что вся цепочка отвечала одному согласованному снимку сети.

Свободный переход делегирует выбор, а не полноту поиска

ERO допускает строгие и свободные переходы в одном объекте. Строгий следующий узел обрабатывается обычными процедурами RSVP-TE. Свободный либо абстрактный переход через несколько LSR требует локального раскрытия на границе. Это сохраняет автономию домена и не требует публикации внутренней топологии.

Однако делегирование не говорит, сколько кандидатов должна проверить граница, как ранжировать egress, сохранять ли альтернативы для второго пути и что считать достаточным отрицательным результатом. Финальный ERO показывает маршрут, переживший цепочку решений. Он не является трассировкой поискового дерева.

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

Устаревшая TED — правдоподобная причина, но не универсальное объяснение

RFC 5152 допускает повтор той же последовательности свободных переходов, если головной узел предполагает устаревшую downstream IGP-TE информацию. Такая стратегия практична: состояние полосы, резервирования и достижимости меняется, а распространение сведений не мгновенно.

Но фраза «вероятно, устарели данные» должна оставаться гипотезой до тех пор, пока журнал не связывает отказ с конкретной версией TED и не показывает, какое изменение сделало маршрут возможным. Иначе повторный успех может скрыть совсем другую причину — например, освобождение ресурса, смену внутреннего алгоритма или иной выбор границы.

Даже доказанная несвежесть не означает, что исходный поиск был полным при своём снимке. Она объясняет расхождение между двумя попытками. Полнота требует отдельного свойства: доказательства того, что в пределах заданной модели и исходных ограничений были рассмотрены все релевантные композиции.

Crankback расширяет поиск локально

Если downstream ASBR не может найти участок, удовлетворяющий ограничениям, он возвращает PathErr предыдущей границе. При разрешённом и настроенном crankback предыдущий Boundary LSR может выбрать другой egress. Без него ошибка движется к головному узлу.

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

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

Первый путь меняет исходные данные для второго

Самое наглядное ограничение RFC 5152 — trapping-пример. В топологии A-B-C-D существуют два разнообразных пути: A-C-D и A-B-D. Если первым выбрать A-B-C-D, построить путь, разнообразный относительно него, уже не удаётся.

Здесь не требуется устаревшая TED. Все локальные сведения могут быть корректны, а первый путь — полностью допустим. Ошибка возникает в постановке: алгоритм сначала решает задачу одного пути, фиксирует результат, а затем пытается решить задачу пары на оставшемся пространстве.

Сообщение «второй путь не найден» поэтому обязано ссылаться на первый путь. Без его отпечатка отрицательный результат выдаёт условное состояние за свойство топологии. И даже обновление TED не исправит ловушку, если повтор сохраняет тот же первый путь и тот же порядок решений.

Ослабление ограничения может восстановить сервис и разрушить смысл сравнения

Оператор вправе ослабить ограничения после неудачи. Это может быть лучшим решением во время инцидента: меньше полоса, иная задержка, другой приоритет или более слабая форма разнообразия иногда ценнее полного отсутствия связи.

Однако успешный fallback нельзя использовать как доказательство, что первоначальный запрос был реализуем или что система нашла эквивалент. В отчёте должны одновременно существовать две записи: исходная услуга не была получена при таких-то данных и методе; изменённая услуга была получена после конкретного ослабления.

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

Реоптимизация может обновить участки, не пересмотрев композицию

Для contiguous LSP downstream-домен может уведомить головной узел о лучшем пути, после чего тот управляет make-before-break. В stitched или nested конструкции домен способен локально реоптимизировать H-LSP либо S-LSP, иногда прозрачно для head end. Частота, метрики и критерии полосы могут отличаться по доменам.

Локальное улучшение не обязательно меняет Boundary LSR, оставленные в ERO как свободные якоря. Внутренний маршрут станет свежее и дешевле, но последовательность доменов, создавшая trapping, сохранится. Отчёт о реоптимизации должен поэтому различать обновление внутренних hops, смену egress и пересчёт всей пары.

RFC 4736 позволяет сообщать о локальной реоптимизации, если прозрачный режим нежелателен. Такое сообщение повышает наблюдаемость события. Оно всё равно не свидетельствует, что глобальное пространство решений было пересмотрено.

Конфиденциальность ограничивает видимость — и требует аккуратной лексики

RFC 5152 не увеличивает объём топологической информации, которой обмениваются AS. Каждая сторона сохраняет подробности у себя, что защищает коммерческие и операционные границы. Выгода реальна и не должна превращаться в требование централизовать все карты.

Но при ограниченной видимости формулировка результата должна соответствовать объёму доказательства. Стандарт позволяет провайдеру выбирать метод вычисления для каждого LSP и упоминает PCE-подходы для сквозных constrained paths или diverse sets. Само название PCE не даёт гарантии: качество вывода по-прежнему зависит от полномочий, полноты и свежести данных, модели рисков и алгоритма.

Boundary-вычисление также требует защиты: авторизации ERO expansion, договорных фильтров полосы и приоритета, лимитов частоты setup и ошибок, контроля исходящих сообщений, согласованных ключей RSVP. Эти меры предотвращают злоупотребления вычислительной властью. Они не превращают повторный успех в доказательство исчерпывающего поиска.

Источники

  1. RFC 5152, HTML
  2. RFC 5152, текст
  3. Карточка RFC Editor
  4. Карточка IETF Datatracker
  5. История RFC 5152
  6. Ссылки RFC 5152
  7. Errata RFC 5152
  8. RFC 3209
  9. RFC 3473
  10. RFC 5151
  11. RFC 5150
  12. RFC 4920
  13. RFC 4655
  14. RFC 4726
  15. RFC 4105
  16. RFC 4216
  17. RFC 4736
  18. RFC 2747
  19. RFC 3097
  20. RFC 3630
  21. RFC 4203
  22. RFC 4205
  23. RFC 6805
  24. RFC 8694
  25. Minimum Initial Specification
  26. On Reality Layers
  27. Running-Code Primacy