Кратко

  • CATS выбирает экземпляры сервиса с учетом вычислительных ресурсов и параметров сети. Для подвижного клиента и сервиса с состоянием RFC 10054 требует, чтобы приложение явно сообщило, разрешает ли оно включить CATS.
  • Новый маршрут, привязка потока к экземпляру и восстановленный контекст приложения — разные доказательства. Более низкая задержка не означает, что второй узел готов продолжить сеанс.

Быстрый узел не обязательно знает, что пользователь делал минуту назад

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

В этом и состоит граница, которую формулирует RFC 10054. Computing-Aware Traffic Steering (CATS) выбирает экземпляры сервисов и направляет трафик, учитывая не только связность, но и вычислительные возможности и текущие ресурсы. Ближайшая площадка может быть перегружена или не располагать нужным оборудованием. Нагрузка меняется, клиент перемещается, и прежний выбор теряет актуальность.

С точки зрения маршрутизации CATS может быть прозрачным для приложения и работать как с сервисами, хранящими состояние, так и без него. Это позволяет сети выбирать точку обслуживания, не передавая приложению каждое решение о пути. Но прозрачность маршрута не делает прозрачным состояние приложения. Для подвижного клиента и stateful-сервиса RFC 10054 требует явного указания приложения, разрешает ли оно использовать CATS. Без такого указания перенаправление посреди сеанса способно рассогласовать контекст на разных площадках или прервать услугу.

Слово «разрешает» здесь имеет узкий операционный смысл. RFC 10054 не задаёт универсальный формат сигнала, общий программный интерфейс, экран согласия пользователя или юридическую процедуру авторизации. Положительный сигнал также не доказывает, что состояние уже перенесено на новую площадку и восстановлено без ошибок. Он фиксирует позицию сервиса по применению CATS; сам переход ещё нужно реализовать и проверить.

Маршрут, привязка и состояние — три разные вещи

Словом «переключение» часто называют три события. Первое — сеть меняет путь пакетов. Второе — сохраняется привязка потока к тому же экземпляру сервисного контакта и согласованному маршруту. Третье — приложение переносит контекст на другой экземпляр, восстанавливает его и продолжает сеанс с прежним смыслом. Первое относится к пересылке, второе — к affinity, третье — к переходу состояния сервиса.

RFC 10053 описывает affinity экземпляра сервисного контакта как направление пакетов потока к тому же экземпляру и по тому же пути, в частности ради защиты от переупорядочивания и резких колебаний задержки. При этом сам фреймворк не вводит механизм определения или принудительного соблюдения affinity. RFC 10054 добавляет три требования: R14 требует привязки по потоку для сеансов и транзакций с состоянием; R15 требует не хранить в сетевых узлах специфичное для приложения состояние каждого потока ради такой привязки; R16 рекомендует поддерживать непрерывность при перемещении устройства или экземпляра сервиса.

Это архитектурное условие, а не готовый протокол миграции. Сети нужно достаточно данных, чтобы обращаться с потоком согласованно, но она не должна становиться хранилищем состояния приложения. Приложение должно определить, какие сеансы можно перемещать и что требуется копировать, восстанавливать или оставлять на исходной площадке. В примере AR/VR из RFC 10054 общие базовые ресурсы отделены от клиентских входных данных, которые обрабатывает stateful-экземпляр. Если следующий пакет дошёл до новой площадки, это ещё не доказывает, что следующий кадр учёл предыдущую историю.

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

Требования не подтверждают готовность конкретного оператора

RFC 10054 — документ категории Informational, отражающий консенсус сообщества IETF и одобренный IESG к публикации; это не спецификация Internet Standards Track. Его примеры и требования ограничены сценариями одного домена. Документ описывает проблему и желаемое поведение, но не подтверждает, что оператор способен безопасно переместить любой сервис или что разные провайдеры используют общий контракт состояния.

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

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

Источники и статус