Кратко

  • При shuffling входной PE заменяет CPI на PPI в объектах Session и Sender Template, а выходной PE выполняет обратное преобразование.
  • Поэтому один устойчивый сеанс ничего не говорит о том, какая версия PIT выбрала порт, была ли правильно создана физическая коммутация и дошёл ли пользовательский трафик до нужного конца.

Непрерывность, построенная на двух заменах

Клиентский пограничный узел просит соединить два порта, названных в адресном пространстве клиента. Запрос входит в сеть с другой властью над именами и выходит на дальней стороне снова с понятными клиенту обозначениями. Если наблюдать лишь два CE, перед нами один неизменный сеанс.

Именно такой результат создаёт shuffling в RFC 5251. Входной PE переписывает объекты RSVP-TE Session и Sender Template: Customer Port Identifier, CPI, заменяется на Provider Port Identifier, PPI. Выходной PE меняет PPI обратно на CPI. Логическое единство сохраняется благодаря тому, что нижележащие имена дважды меняются по правилам.

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

Один индекс не создаёт одну личность

CPI обозначает клиентскую сторону порта. PPI обозначает сторону провайдера. VPN-PPI представляет порт PE внутри адресного пространства клиента L1VPN. Назначением PPI управляет провайдер, а адресами CPI и VPN-PPI — администрация L1VPN.

Для ненумерованных портов PPI и VPN-PPI могут ради удобства использовать одинаковый индекс. Числовое совпадение не объединяет пространства полномочий. Запись «порт 17» без типа идентификатора, VPN-контекста и точки наблюдения уничтожает сведения, необходимые для восстановления перевода.

Адреса канала управления тоже локальны. Они обязаны быть уникальны внутри одного L1VPN, но могут повторяться в другом. Поэтому однозначная связь канала с VPN является частью факта. Сам по себе адрес не превращается в глобальную идентичность.

Для расследования нужна та версия PIT

Каждый граничный узел провайдера ведёт отдельную для VPN Port Information Table. В PIT хранятся пары CPI/PPI, а для локальных портов — сведения VPN-PPI. Таблица может наполняться конфигурацией; данные могут поступать из механизмов обнаружения BGP и OSPF, описанных в RFC 5195 и RFC 5252.

Но происхождение строки и её использование — разные события. При запросе входной PE выбирает PIT нужного L1VPN, разрешает целевой CPI в PPI и переписывает сигнальные объекты. Другая граница выполняет обратный поиск. Два решения создают одну картину для клиента.

Состояние таблицы сегодня не объясняет решение вчера. Формально корректная строка могла устареть, быть ошибочно настроена или относиться не к тому VPN. Тогда реализация безупречно выполнит неправильное преобразование. Поэтому раздел безопасности RFC 5251 сохраняет требования к защите управления и конфигурации и предлагает рассматривать проверку плоскости данных против случайной ошибки настройки.

Это не слабость протокола, а точная граница доказательства. Сигнализация подтверждает сигнальный переход. Тест CE—CE наблюдает следствие в плоскости данных. Ни один результат не вправе автоматически представлять другой.

Скрытая топология остаётся физической

Внутри сети провайдера сообщения несут PPI. Если выбран shuffling, преобразование на границах должно применяться ко всем относящимся к сеансу сообщениям RSVP-TE. Частичная реализация создала бы противоречивые состояния под одним видимым сеансом.

Клиент видит LSP и виртуальный линк между PE. Провайдер видит внутренний сегмент подробно. Граница может отфильтровать топологию, изменить или удалить Record Route и Notification. Защищать внутреннюю архитектуру законно. Но очищенный клиентский вид не позволяет восстановить скрытый маршрут.

Один сеанс не означает один физический переход, одно волокно, одну длину волны или неизменный путь. Более того, RFC 5251 допускает stitched и nested варианты. Сеанс PE—PE, существующий LSP или forwarding adjacency можно связать с клиентским запросом с помощью RFC 5150 и RFC 4206. Внешне услуги похожи, а внутренние квитанции различны. Режим исполнения должен оставаться в журнале.

Принятие запроса ещё не коммутация

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

Path и Resv принадлежат плоскости управления. Резервирование ресурсов, программирование метки или длины волны, состояние защиты, физическая непрерывность и пользовательский трафик лежат на последующих ступенях. Даже успешный тест непрерывности доказывает только фактически отправленный и полученный шаблон; показатели SLA и результат приложения требуют своих наблюдений.

Explicit Route Object от клиента также не передаёт ему власть над каждым внутренним переходом. PE может отклонить ERO, а при допустимой свободной форме всё равно рассчитывает и вставляет путь провайдера. Намерение клиента ограничивает услугу, но не подписывает каждое инженерное решение.

Цепочка, переживающая смену конфигурации

Сначала следует сохранить L1VPN, привязку канала управления, исходные CPI источника и цели и сам запрос. Затем — точное поколение PIT, происхождение строки, разрешённые PPI и значения Session и Sender Template до и после переписывания. На выходе нужны обратный поиск, восстановленные CPI и ответ целевого CE.

Отдельными ступенями идут состояние RSVP, программирование ресурсов, физическая коммутация, проверка плоскости данных и наблюдаемый результат услуги. Нормализованное поле «session up» не заменяет эту цепь. После изменения конфигурации оно не позволит объяснить, какое сопоставление поддерживало прошлый сеанс.

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

Дисциплина слоёв реальности Lu Heng даёт практическое правило. Имя в клиентском пространстве — не тот же факт, что имя в пространстве провайдера. Успешный перевод — не наблюдение физической связи. Непрерывный сеанс — ещё не непрерывная услуга. Работающая система остаётся подотчётной, когда каждая граница записывает, что именно она преобразовала и что действительно увидела.

Источники