Кратко

  • RFC 3654 не требовал, чтобы Forwarding Element (FE) всегда продолжал пересылку или всегда останавливался при потере связи с Control Element (CE). Архитектура должна была обнаруживать потерю, восстанавливать связь, синхронизировать состояние и позволять заранее задать реакцию FE.
  • RFC 7121 позднее описал два режима восстановления: один возвращает FE в состояние до ассоциации; другой может перебирать резервные CE и продолжать пересылку до истечения тайм-аута. Восстановленная связь сама по себе не доказывает, что всё состояние FE восстановлено.

У одного сетевого устройства — две логические роли

В ноябре 2003 года RFC 3654 описал сетевой элемент как взаимодействие компонентов управления и пересылки, которое внешне может выглядеть единым IP-маршрутизатором. Control Element выполняет, например, протоколы маршрутизации и сигнализации; Forwarding Element обрабатывает пакеты по одному. Это логическое разделение, а не требование поставить два отдельных корпуса. Документ указывает на масштабируемость и независимое развитие плоскостей, но не утверждает, что архитектура уже широко внедрена. RFC 3654

Сложная ситуация возникает, когда у FE остаются таблицы и настроенные функции, но связь с управляющим CE теряется. Фраза «управление отказало» не отвечает на вопрос, что произошло с пакетами: FE может продолжить работу с имеющимся состоянием, остановиться либо попытаться связаться с резервным CE. RFC 3654 рассматривает эти варианты раздельно.

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

Архитектурное требование 7 объединяет четыре задачи: обнаружить потерю связи, восстановить её, эффективно синхронизировать состояние и заранее задать реакцию FE. Продолжение пересылки и остановка операций приведены как примеры, а не как единый обязательный ответ для всех устройств. Протокольное требование 8 повторяет ту же границу. RFC 3654

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

Позднейшие правила высокой доступности добавили состояние и срок

В 2010 году RFC 5810 в статусе Standards Track определил протокол ForCES и Transport Mapping Layer, чтобы выполнить протокольные требования RFC 3654. RFC 5812 описал модель FE: его возможности, текущее состояние, желаемую конфигурацию и логические функциональные блоки. Возможность — не то же самое, что состояние сейчас; ни то ни другое не тождественно требуемой конфигурации. RFC 5810 RFC 5812

RFC 7121 2014 года добавил процедуру высокой доступности внутри сетевого элемента ForCES. FE Protocol Object указывает главный и резервные CE; интервалы и политика heartbeat помогают обнаруживать проблемы связи. В режиме 0 по умолчанию потеря связи возвращает FE к состоянию до ассоциации; при последующем подключении его состояние нужно создать заново. Режим 1 предусматривает восстановление после перезапуска: FE по очереди пробует резервные CE, пока идёт CE Failover Timeout Interval. В состоянии «не ассоциирован» FE может продолжать пересылку в зависимости от настроенной политики. Если срок истекает без восстановления связи, FE переходит к предассоциационному состоянию и прекращает работу пути пересылки. После повторного подключения CE может попытаться синхронизировать утраченное состояние, однако способ синхронизации не входит в архитектуру ForCES и обычно предполагает новые сообщения конфигурации и запросы. RFC 7121

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

Другой документ ForCES, RFC 3532, посвящён динамическому перераспределению ресурсов и возможному отставанию модели управляющего элемента. Это соседний, но иной вопрос: здесь речь идёт о заранее выбранном действии FE и восстановлении высокой доступности после потери связи. RFC 3654 имеет информационный статус; последующие стандарты показывают развитие конструкции, но не доказывают её внедрение конкретным оператором. RFC 3532 RFC 3746 RFC 1812 Запись RFC 3654 в RFC Editor Запись RFC 3654 в IETF Datatracker

Источники