Кратко
- В редакции 01
draft-claise-green-capability-discoveryот 10 сентября 2026 года к модели возможностей YANG добавлены максимальная мощность, а также типичные и предельные времена входа в состояние и выхода из него. - Каталог можно поставить до монтажа как экземпляр данных либо читать с работающего устройства как состояние только для чтения. Значения мощности, времена и охват компонентов могут быть неполными.
- Проект не определяет разрешённые переходы и не содержит операций записи. Номинальная мощность служит плановой оценкой, а не измерением потребления или разрешением перевести компонент в сон сейчас.
- Документ остаётся индивидуальным Internet-Draft без зафиксированного принятия группой GREEN. Для эксплуатации нужен отдельный протокол, соединяющий возможность, полномочие, ответ устройства и измеренный результат.
Между вычитанием и отключением остаётся сеть
В примере проекта карта потребляет номинально 200 ватт во включённом состоянии и 15 ватт во сне. Разница составляет 185 ватт. Обычное пробуждение занимает 800 миллисекунд, предельное — две секунды. Эти числа позволяют сравнивать платформы и искать достаточно длинные периоды простоя.
Они не отвечают на вопросы дежурного инженера. Несёт ли карта единственный путь? Достаточен ли резерв? Допускает ли обязательство перед клиентом две секунды восстановления? Кто утвердил действие и примет ли его устройство? Какова фактическая мощность при нынешней нагрузке и температуре?
Поддерживаемое состояние — свойство платформы. Разрешение — решение в конкретной обстановке. Экономия и сохранность сервиса — наблюдаемый итог. У этих утверждений разные источники власти.
Что появилось в редакции 01
Datatracker показывает A YANG Data Model for Power State Capability Discovery как действующий индивидуальный Internet-Draft. История фиксирует редакцию 00 от 25 августа и 01 от 10 сентября. RFC-поток и статус рабочей группы не указаны. Пометка Standards Track на титульной странице выражает намерение авторов, но не означает принятие GREEN, консенсус IETF, одобрение IESG или публикацию RFC.
Переход от редакции 00 к редакции 01 содержателен. Официальная разница добавляет максимальную мощность по состояниям, отделяет её от ожидаемой номинальной мощности и вводит четыре оценки времени перехода. Появились правила частичного охвата и новые примеры.
Авторы также перечисляют нерешённые вопросы. Нужна ли характеристика всей системы наряду с компонентами? Смогут ли изготовители предоставлять времена перехода? Как согласовать несовместимые значения Nameplate Power в материалах GREEN? Открытый вопрос не следует превращать в молчаливое обязательство поставщика или оператора.
Для одной платы нужны три записи
Предлагаемый модуль расширяет модель системных возможностей из RFC 9196. Значение может относиться ко всему устройству или к шасси, плате, порту либо оптическому модулю из аппаратного реестра RFC 8348. Сопутствующий проект GREEN о мощности и энергии использует то же имя компонента для административного состояния, рабочего состояния и мгновенной мощности.
Первая запись — статическая возможность. Производитель может передать её до включения оборудования в файле по RFC 9195. Работающее устройство может выдать тот же формат из операционного datastore по RFC 8342. В первом случае важны изготовитель, версия и дата; во втором — личность устройства и момент чтения.
Вторая запись — управление. В новом модуле все узлы имеют config false: нет записываемых данных, RPC, действий и уведомлений. Проект не описывает, какие переходы между состояниями разрешены. Контроллер может запросить изменение через управляющую часть другой модели GREEN, а устройство вправе принять или отвергнуть запрос.
Третья запись — итог. Нужны достигнутое состояние, измеренная мощность, перемещённый трафик, время восстановления и влияние на сервис. Подтверждение команды ещё ничего из этого не доказывает.
Отсутствующий компонент не потребляет ноль
Номинальные и максимальные значения необязательны. Устройство может перечислить состояния без ватт. При постепенном внедрении допускаются записи лишь для части компонентов. Отсутствие строки означает неизвестность, а не нулевое потребление и не отсутствие режима сна.
Мощность каждой записи относится только к выбранному компоненту и не включает автоматически дочерние элементы аппаратного дерева. Сумма по шасси полна, только если весь соответствующий подграф сверён и каждый элемент посчитан один раз. Иначе это нижняя граница.
Даже полный каталог содержит паспортные приближения. Фактическая мощность зависит от нагрузки, температуры и условий сети. Поэтому редакция требует считать nominal-power плановой базой, а не измерением. Проект энергосберегающего размещения путей может распространять медленно меняющуюся или сглаженную величину; централизованный контроллер может собирать живую телеметрию. Эти данные обслуживают разные решения.
Времена перехода также необязательны и зависят от условий. Энергетически выгодный сон может быть неприемлем для чувствительного к задержке трафика. Пригодность появляется только после сопоставления предельного времени с местным бюджетом сервиса.
Чтение каталога тоже требует охраны
Список показывает, какие компоненты дольше всего пробуждаются и где принудительные повторные переходы способны вызвать наибольший расход или сбой ёмкости. Проект требует защищённый транспорт управления, взаимную аутентификацию и ограничение чтения средствами RFC 8341.
Файл до развёртывания должен сохранять изготовителя, продукт, аппаратную ревизию, время, хеш и область применения. Живое чтение — идентификатор устройства, программную и инвентарную ревизии, время и путь доступа. Совпадение схемы не доказывает совпадение происхождения и свежести.
Квитанция фактического перехода
Для значимого изменения следует связать компонент и версию инвентаря; источник, возраст и полноту каталога; предположения о мощности; типичные и предельные времена; текущий замер; нагрузку и роль трафика; цель сервиса; политику и уполномоченного субъекта; точный запрос; принятие или отказ устройства; достигнутое состояние; измеренную разницу энергии; влияние на сервис; условие отката.
Такая квитанция — редакционное предложение Daniel Kade, а не требование проекта. Заметка Heng Lu о минимальной начальной спецификации предлагает сделать общий слой достаточным для сопоставления, но оставить будущие решения локальными. The Policy Mirror разделяет поверхности контроля, а Reality, Not Advocacy не позволяет выдавать намерение за наблюдаемый результат.
Устав GREEN очерчивает предмет работы, но сам по себе не принимает индивидуальный проект. Запрошенные в разделе IANA регистрации также ещё не существуют. Редакция 01 делает описание способности лучше. Полномочие на вмешательство она оставляет оператору.
Источники
- Текущая запись Datatracker
- История документа
- Редакция 00
- Редакция 01
- Разница между 00 и 01
- Проект YANG GREEN о мощности и энергии
- Устав группы GREEN
- RFC 9196 — Возможности систем
- RFC 9195 — Экземпляры данных YANG
- RFC 8348 — Аппаратный реестр
- RFC 8342 — Архитектура datastore
- RFC 8341 — Модель контроля доступа
- Проект размещения путей по мощности
- Heng Lu — Minimum Initial Specification
- Heng Lu — The Policy Mirror
- Heng Lu — Reality, Not Advocacy
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров

