Кратко
- RFC 3469 разделил MPLS-восстановление на обнаружение, ожидание, уведомление, операцию переключения и реальное возвращение трафика.
- Заранее созданный путь мог разделять причину отказа, не иметь зарезервированной ёмкости, давать ограниченное качество или оставлять сервис без следующего уровня защиты.
Слово «резервный» звучит как готовый ответ. Однако при обрыве рабочего пути оно не сообщает, проходит ли альтернатива через ту же физическую точку, достаточно ли на ней полосы и когда первый пакет дойдёт до места слияния. RFC 3469 превратил эту неопределённость в последовательность проверяемых событий.
Документ вышел в феврале 2003 года как Informational RFC. Он не стандартизировал единственный протокол, не подтверждал внедрение и исключал вопросы перезапуска. Его роль состояла в создании словаря и критериев, с помощью которых разные схемы можно было сравнивать, не принимая конфигурацию за результат.
Первое различие проходило между rerouting и protection switching. В первом случае новый путь или сегмент строился после отказа. Во втором использовался путь, подготовленный заранее. Механизмы могли следовать друг за другом: быстрое переключение восстанавливало связь, сеть входила в полуcтабильное состояние, а после сходимости трафик переносился на более подходящий рабочий маршрут.
Заранее созданный маршрут всё же мог пересекать тот же канал, узел или домен риска. На нём могли быть метки, но не резерв полосы и буферов. Он мог быть создан для другой цели и лишь признан пригодным. Он мог выйти из строя раньше или одновременно с рабочим путём. Объект в плоскости управления не доказывал способность плоскости данных.
Начальный цикл RFC 3469 включал пять интервалов. T1 шёл от повреждения до обнаружения. T2 задавал ожидание. T3 измерял доставку Fault Indication Signal к Path Switch LSR, если обнаруживший узел не являлся точкой ремонта. T4 охватывал действия восстановления и координацию с Path Merge LSR. T5 завершался только тогда, когда трафик снова полностью прибывал в пострадавшую точку.
Именно T5 не позволял остановить секундомер на успешной команде. Запись пересылки может быть установлена, пока пакеты ещё теряются, меняют порядок, стоят в очереди или сталкиваются с нехваткой ресурсов. Завершение операции — квитанция управления; возвращение трафика — другая квитанция.
Для возврата на предпочтительный путь существовал отдельный цикл reversion. Нужно было увидеть ремонт, обнаружить очистку отказа, при необходимости выждать стабильность, передать уведомление, выполнить возврат и подтвердить движение. Мгновенный switch-back мог превратить нестабильный ремонт в новый сбой. Make-before-break уменьшал потери, но не отменял наблюдение.
Динамическая перестройка имела ещё одну временную линию: полуcтабильное состояние, сходимость, необязательный ограниченный hold-down, создание нового рабочего пути, переключение и прибытие трафика. Быстрая защита давала время на постоянное решение; она не обязана была быть этим решением.
RFC разделял построение пути и выделение ресурсов. Альтернатива могла быть заранее установлена, предварительно квалифицирована или создана по требованию. Ресурсы могли резервироваться до аварии либо после неё. Эквивалентный путь сохранял исходные гарантии. Ограниченный путь давал худший сервис и не предназначался для незаметного постоянного использования.
При 1+1 копия трафика постоянно шла по двум путям, а точка слияния выбирала. При 1:1 резерв мог обслуживать низкоприоритетный трафик до тех пор, пока защищённый поток не вытеснит его. В схемах 1:n и m:n реальная защита зависела от набора одновременных отказов, заложенного в план. Количество резервов не показывало покрытие.
Место ремонта меняло скорость и область. Локальный обход действовал рядом с неисправным каналом или соседом и сокращал путь сигнала. Глобальный мог охватить больший участок и обеспечить лучшую разнесённость, но уведомление должно было дойти до удалённой точки. Альтернативный выход восстанавливал доставку без восстановления точного старого маршрута. Bypass-туннель мог объединять много защит и не иметь ёмкости для их одновременного включения.
Защита могла охватывать лишь часть трафика. Успех премиального класса не говорил о судьбе остальных пакетов. Историческую ссылку на EXP bits после RFC 5462 следует понимать как Traffic Class; существенен выбор защищаемого множества.
Полный отказ и деградация также различались. Снижение качества становилось объявленным отказом лишь после пересечения настроенного порога. Нижний уровень мог сообщить раньше. Если обнаруживший LSR не имел права ремонтировать, он отправлял FIS уполномоченной точке. Наблюдение, объявление, уведомление и команда были четырьмя фактами.
После переключения возникала новая уязвимость. В revertive-режиме трафик ждал устойчивости предпочтительного пути. Пока он использовал единственную защиту, второй отказ мог застать его без резерва, а ресурсы старого пути оставались связанными. В non-revertive-режиме обход становился рабочим, отремонтированный путь — защитным, либо строилась новая оптимальная пара.
Поэтому RFC различал recovery time и full restoration time. Первое складывалось из обнаружения, ожидания, уведомления, операции и возврата трафика. Второе продолжалось до размещения нагрузки на каналах, спроектированных для аварийного сценария. Они совпадали лишь тогда, когда первый обход уже был эквивалентным и постоянным.
В критерии входили уязвимость при настройке, резервная ёмкость, дополнительная задержка, качество защиты, перестановка пакетов, объём состояния, потери и покрытие. Сравнение с SONET-переключением порядка 50 миллисекунд было целью проектирования, а не измерением или гарантией приложения.
Позже RFC 4090 стандартизировал RSVP-TE Fast Reroute; RFC 4426, 4427 и 4428 развили функции, термины и многоуровневый анализ; RFC 5714 описал рамки IP Fast Reroute. Эта линия не доказывает конкретное внедрение, физическое разнесение или успешный пользовательский результат.
Принцип приоритета работающего кода Heng Lu задаёт строгую проверку: «предустановлен» и «восстановлен» остаются символами, пока таблицы, ресурсы и трафик не совпадут. Минимальная начальная спецификация объясняет набор сочетаемых примитивов. Слои реальности сохраняют повреждение, сигнал, решение, пакет и исход раздельно.
Исторический вывод RFC 3469 не требует больше резервных линий. Он запрещает считать запись о линии записью о восстановлении. Нужны доказательства того, кто увидел отказ, кто его объявил, куда дошёл сигнал, кто имел право переключить, какие ресурсы были доступны, где появились пакеты, какое качество сохранилось и когда сервис вновь получил защиту от следующего удара.
Источники
- RFC 3469
- Текст RFC 3469
- IETF Datatracker
- История IETF Datatracker
- Поиск исправлений RFC 3469
- RFC 3031: архитектура MPLS
- RFC 2702: требования MPLS TE
- RFC 3272: Traffic Engineering Интернета
- RFC 3386: иерархия и многоуровневая живучесть
- RFC 4090: RSVP-TE Fast Reroute
- RFC 4426: функции восстановления GMPLS
- RFC 4427: терминология восстановления
- RFC 4428: многоуровневое восстановление
- RFC 5462: поле MPLS Traffic Class
- RFC 5714: IP Fast Reroute
- Heng Lu: Running-Code Primacy
- Heng Lu: Minimum Initial Specification
- Heng Lu: On Reality Layers
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
