Кратко

  • draft-many-teas-rsvp-power-00 предлагает пять режимов для согласованного сна и пробуждения точно указанного TE-ресурса. Редакция 00 — индивидуальный рабочий Internet-Draft; значения объекта RSVP POWER не назначены.
  • Сигнализация координирует соседей, а физическое действие выполняет локальный менеджер питания. Нужны отдельные доказательства состояния обоих устройств, сохранности TE-данных, независимого пути пробуждения и фактической передачи после возврата.

Последовательность выглядит успешной: SleepPrepare, согласие, GoSleep, подтверждение. Панель пометила канал спящим, но потребление не изменилось — локальная защита не разрешила выполнить действие на оборудовании.

Именно такой разрыв допускает архитектура Power Transition Framework for TE Resources от 30 сентября 2026 года. Протокол согласует переход между соседними узлами. Физическое переключение остаётся за локальным компонентом вне области документа. Поэтому реализация не должна объявлять успех только потому, что запрос сна был отправлен.

Редакция 00 — индивидуальный черновик, связанный с TEAS, с предполагаемым статусом Standards Track и сроком до 3 апреля 2027 года. Это не RFC, не консенсус группы, не назначение IANA и не свидетельство внедрения. Class и C-Type нового объекта POWER остаются TBD.

Сначала нужно доказать, какой именно ресурс меняется

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

В реализации RSVP нумерованный канал задаётся локальным адресом отправителя и нулевым индексом. Ненумерованный использует пару router identifier и локального TE link identifier. Если получатель не может разрешить её однозначно, он обязан отказать.

Квитанция хранит эту составную идентичность, аутентифицированного соседа и найденный локальный интерфейс. Запись «A попросил B сэкономить энергию» не различает основную и резервную линии. Точный scope здесь является средством безопасности.

Ready не означает, что оборудование спит

Модель различает Operating, Requisition, Ready, Pending и Sleeping. SleepPrepareAck переводит стороны к Ready: получатель узнал ресурс и готов участвовать, но ещё может отсутствовать локальное разрешение или финальная команда. После GoSleep начинается Pending.

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

Поэтому нужны две связанные дорожки. Протокольная содержит ресурс, соседа, роль, ожидаемый режим, идентификатор сообщения и таймер. Исполнительная — решение локального менеджера и наблюдаемое состояние железа на каждой стороне. Без этой связи слово Sleeping шире доказательств.

Безопасный отказ оставляет ресурс включённым

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

Для фаз подготовки и подтверждения RSVP-вариант рекомендует 180 секунд. Это значение таймера, а не измеренный SLA. По истечении транзакция удаляется и фиксируется ошибка; timeout не является разрешением на физическое действие.

Если оба конца одновременно начинают переход одного ресурса, Sender остаётся узел с большим стабильным сравнимым идентификатором. Второй отменяет свою отправку и становится Receiver. Разные параллельные линии не являются одной коллизией. Правило устраняет гонку, но не решает, разумно ли убирать резерв.

TE-состояние должно пережить отключение

Идентичность, адреса, атрибуты TE и различение параллельных каналов сохраняются. LSP, пути, резервации, метки и защита должны быть сохранены или согласованы по применимым правилам. Сон не считается неявным успешным teardown.

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

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

Спящий канал не может нести собственный будильник

GoWakeup может начать любая сторона, локальная политика или сервисная потребность; повторение обрабатывается идемпотентно. Но запрос должен идти по пути, который не зависит от спящего ресурса. Хотя бы один control-plane path обязан оставаться доступным.

Название «сеть управления» ещё не доказывает независимость. Логически отдельный путь может разделять line card, кабельный канал, оптический участок или питание. Черновик не навязывает out-of-band схему, но оставляет оператору обязанность проверить зависимости.

Получение GoWakeup только начинает восстановление. Затем подтверждаются готовность оборудования, adjacency или reachability, согласование резерваций, возврат в TE и прохождение трафика. Доставка команды пробуждения и восстановленная передача — разные факты.

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

Принцип Lu Heng о минимальной начальной спецификации подходит этой задаче. Общая часть стандартизует идентичность, сообщения, роли, коллизии и безопасный отказ. Пригодность, физическое действие и пороги сервиса остаются локальными. Добровольное принятие доказывают работающий код и результаты, а не публикация.

Источники