Кратко

  • RFC 5151 регулирует RSVP-TE LSP, пересекающие AS, области IGP и границы оверлеев GMPLS.
  • Сквозной путь может сочетать непрерывную сигнализацию, вложенные H-LSP и сшитые сегменты.
  • Ingress задаёт ограничения, но каждая граница применяет собственную политику, возможности и локальное вычисление.
  • Домен вправе отвергнуть ERO, раскрывающий его внутренние узлы, либо расширить loose hop без публикации полного расчёта.
  • Отказ может быть возвращён кодом 104, иным менее точным кодом или молчаливым отбрасыванием по политике безопасности.
  • Пограничный узел может заменить точный PathErr утверждением о сбое всего домена, когда этого требует конфиденциальность.
  • PathErr нельзя просто подавить; его разрешено удерживать при crankback, удалить после успеха или выпустить после провала всех попыток.
  • В RRO внутренние узлы можно заменить идентификатором AS или удалить, однако сама граница обязана остаться.
  • После фильтрации сигнализация продолжает работать, хотя управленческая диагностика и Fast Reroute могут потерять нужные данные.
  • Notify можно перехватить на границе и переслать дальше; цена обработки растёт линейно с числом доменов.
  • Бит 4 подтверждает требование непрерывного LSP, но не полноту маршрута, точность причины или доставку трафика.
  • Для управляемого сервиса нужны отдельные квитанции о запросе, пограничном решении, преобразовании ошибки, восстановлении и фактическом прохождении данных.

ERO пересекает не только топологию, но и полномочия

Explicit Route Object несёт описание маршрута, которое сформировали предыдущие вычисления, доступная TE-информация и уже применённые политики. Когда оно достигает границы, следующий узел не обязан быть пассивным исполнителем. Он решает, допустимо ли раскрытие, как развернуть loose hop и какой выход соответствует локальным правилам.

Если ERO прямо называет внутренние узлы домена, оператор может считать это нарушением конфиденциальности. Нормальным ответом становится Inter-domain explicit route rejected. В зависимости от политики безопасности Path может быть отброшен без ответа или получить менее информативную ошибку. Коды 103, 104, 28 и 29 описывают разные классы конфликта политики, явного маршрута, способности к непрерывной сигнализации и несовместимого ERO, но внешнему наблюдателю не всегда достанется самая точная версия.

Loose IP- или AS-hop, напротив, приглашает границу выполнить локальное расширение. Если после локального узла список заканчивается, следующим loose hop становится адрес назначения RSVP Session. Когда ERO ссылается на TE-link, созданный H-LSP или сшитым сегментом, продолжить его как обычный непрерывный участок нельзя: способ выбирают возможности, ограничения и политика.

Принятый маршрут — это результат решения, а не журнал альтернатив

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

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

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

Ошибка узла может покинуть домен как ошибка домена

При неудачной установке PathErr идёт обратно к ingress. Каждая граница на обратном пути его видит. Когда конфиденциальность действительно требует обобщения, пограничный узел вправе заменить «узел X отказал по причине Y» сообщением «домен B не смог установить путь». Обычные транзитные узлы не должны переписывать ошибку, а границам не следует обобщать её без необходимости.

Правило запрещает просто заставить ошибку исчезнуть. Однако crankback создаёт временное исключение. Граница может удержать PathErr, попробовать иной внутренний маршрут или другой последующий домен, если параметры Path и политика это допускают. Успешная попытка требует удалить удерживаемую ошибку; провал всех попыток — отправить её вверх, иногда с агрегированными сведениями.

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

RRO сохраняет пограничный каркас, но может потерять внутреннюю причинность

Record Route Object необязателен. Он используется для обнаружения петель и фиксации пройденных hops. RFC 5151 позволяет границе заменить перечень внутренних узлов одним идентификатором AS или удалить его. Саму себя граница удалить не может: она обязана остаться в RRO.

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

Зелёный LSP и неполный RRO поэтому не противоречат друг другу. Первый относится к состоянию управления, второй — к объёму раскрытого свидетельства. Ошибка возникает, когда система наблюдения считает присутствие RRO доказательством его полноты и автоматически превращает пограничный каркас в точную карту причин.

Защитный маршрут зависит от скрытого рабочего маршрута

Фильтрация RRO влияет не только на посмертный анализ. Fast Reroute использует маршрутную информацию, чтобы определить labels и downstream merge point. При вычислении защиты через loose hops узел должен знать рабочий участок между point of local repair и merge point, иначе он не может гарантировать, что резерв обходит защищаемый риск.

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

Готовый backup tunnel доказывает существование второго сигнального объекта. Для доказательства разнообразия требуется назвать защищаемую группу рисков, показать, какие сведения о рабочем пути видел вычислитель, зафиксировать исключения и проверить результат переключения на реальном трафике. Конфиденциальность можно сохранить аттестацией без списка узлов, но нельзя заменить аттестацию рисунком из двух линий.

Notify меняет адресата и место, где возникает квитанция

GMPLS Notify может идти прямо к указанному получателю, а не hop-by-hop. Если граница хочет наблюдать событие для локальной защиты, RFC 5151 рекомендует ей заменить Notify Request на собственный адрес. После этого она должна разбирать, обрабатывать и пересылать часть уведомлений, первоначально предназначенных ingress.

Локальная реакция ускоряется: ближайшая власть получает сигнал первой. Но и доказательство доставки останавливается сначала там же. Квитанция пограничного узла не означает, что исходный адресат получил равнозначное содержание после фильтрации, модификации и пересылки. Более того, вычислительная цена такой цепочки растёт линейно с числом доменов.

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

Бит 4 описывает конструкцию, но не исход

Ingress может установить Contiguous LSP в бите 4 Attributes Flags TLV. Получив этот бит, граница не вправе использовать вложение или stitching. При снятом бите локальная политика может выбрать любой из этих способов. Транзитные узлы не должны менять запрос.

Узел, который понимает требование, но не способен построить непрерывный LSP, возвращает Routing Problem 28. Способная граница или расширитель loose hop сигнализирует непрерывно и, если присутствует RRO, отмечает поведение в RRO Attributes subobject. Неизвестные TLV и биты проходят неизменёнными по правилам расширяемости.

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

Локальная оптимизация может ухудшить целое без локальной ошибки

Непрерывный make-before-break обычно инициирует ingress. Вложенный или сшитый домен может оптимизировать свой H-LSP либо сегмент самостоятельно, сохраняя точки входа и выхода. Такая автономия уменьшает область изменения и позволяет оператору управлять своей сетью.

Однако хорошие локальные решения способны накопиться в плохой сквозной результат. Транзитный домен может считать собственный участок приемлемым и проигнорировать просьбу об оптимизации, хотя head end видит деградацию совокупного пути. Локальная процедура также не может выбрать новые междоменные границы, тогда как сквозная — может.

Следовательно, завершённая reoptimization подтверждает действие определённой администрации, а не улучшение всей услуги. Для второго утверждения нужны исходная метрика, перечень контролирующих сторон, их решения и измерение трафика после составления нового пути.

Доверие к соседу не восстанавливает потерянную детализацию

До включения inter-domain RSVP-TE соседние администрации должны установить подходящие отношения доверия. Они могут согласовать ключи, проверять контрактные атрибуты на границах, ограничивать частоту запросов и ошибок, фильтровать исходящие объекты. Если доверия нет, RFC рекомендует не разворачивать механизм и отключить его на междоменных интерфейсах.

Эти меры отвечают на важные вопросы: кто отправил сообщение, не было ли оно изменено, вправе ли отправитель просить ресурс. Но аутентифицированный сосед всё ещё может законно скрыть внутреннюю причину. Целостность обобщённого PathErr не превращает его в точный PathErr. Подлинность сокращённого RRO не возвращает удалённые hops.

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

Sources

  1. RFC 5151, HTML
  2. RFC 5151, text
  3. RFC Editor record
  4. IETF Datatracker record
  5. RFC 5151 history
  6. RFC 5151 references
  7. RFC 5151 errata
  8. RFC 3209
  9. RFC 3473
  10. RFC 4206
  11. RFC 4420
  12. RFC 5150
  13. RFC 4726
  14. RFC 4208
  15. RFC 4920
  16. RFC 4090
  17. RFC 4873
  18. RFC 4874
  19. RFC 4655
  20. RFC 4216
  21. RFC 4105
  22. RFC 2747
  23. RFC 5152
  24. IANA RSVP parameters
  25. Minimum Initial Specification
  26. On Reality Layers
  27. Running-Code Primacy