要約

  • draft-many-teas-rsvp-power-00 は、明確に識別した一つの TE 資源を休止・起床させる五つの状態を提案する。revision 00 は個人提出の作業中 Internet-Draft で、RSVP POWER オブジェクトの値は未割り当てである。
  • 信号処理は隣接ノードを調整するが、電力を実際に変えるのは各装置のローカル管理機構である。成功の証拠には、両端の物理状態、保存された TE 状態、休止資源に依存しない起床経路、復帰後の転送確認が別々に要る。

運用画面では処理が完了している。SleepPrepare に相手が応答し、GoSleepAck も返った。ところが機器の消費電力は変わらない。ローカルの保護条件が電源操作を止めていたからだ。

2026 年 9 月 30 日付の Power Transition Framework for TE Resources は、このずれを仕様の外に追い出してはいない。むしろ境界を明記する。プロトコルが行うのは両端の調整で、物理的な操作は適用範囲外のローカル power manager が担う。したがって、sleep request を送っただけで完了を報告してはならない。

revision 00 は TEAS に関連づけられた Standards Track 想定の個人ドラフトで、期限は 2027 年 4 月 3 日。RFC でも WG 合意でも、IANA 割り当てでも実装実績でもない。新しい RSVP POWER オブジェクトの Class と C-Type は TBD のままである。

相手の名前ではリンクを選べない

一つの transaction が扱うのは一つの資源である。同じ二台の間に複数の平行リンクがあれば、主系、予備、保護で意味が異なる。関連する adjacency からメッセージが届いたことは、別の interface を操作する根拠にならない。

RSVP の実現では、番号付きリンクは送信側のローカルアドレスとゼロの index で表す。番号なしリンクは router identifier とローカル TE link identifier の組で表す。受信側が一意に解決できなければ、推測せず拒否する。

監査記録には、この複合 ID、認証済み peer、解決したローカル interface が必要だ。「A が B とのリンクを止めた」だけでは、四本のうちどれを止めたか分からない。資源 ID は台帳の飾りではなく、安全制御そのものである。

Ready は電源状態ではない

状態は Operating、Requisition、Ready、Pending、Sleeping に分かれる。Requisition は準備要求への返答待ち。Ready は参加の合意後で、ローカル承認または最終命令を待つ段階。GoSleep の後が Pending で、協調遷移を終えた状態が Sleeping である。

この区別が、運用 UI の早すぎる緑表示を防ぐ。SleepPrepareAck は資源が解決され、相手が参加できることを示すだけだ。GoSleep は次の段階を指示するが、リレーや光源の状態を測らない。GoSleepAck も、各端点の物理観測と結び付けて初めて意味が閉じる。

そのため証跡は二層になる。protocol 側は peer、resource、role、expected state、message ID、timeout を持つ。execution 側は power manager の判断とハードウェア状態を端点ごとに持つ。製品が根拠を示さず「Sleeping」とだけ返すなら、それは事実より大きなラベルである。

異常時は起きたままにする

この案は失敗を保守的に扱う。未知の資源、能力不足、利用不能な peer 関係、ローカル承認拒否、壊れたメッセージ、送信失敗、予期しない状態のどれも、power-down の原因にしてはならない。資源は Operating に留まるか戻る。

RSVP の確認待ちは 180 秒が標準値として示される。しかしこれは復旧 SLA ではない。期限が切れれば transaction を解放し、失敗を記録し、timeout だけを理由に物理操作してはならない。

両端が同じ資源に同時要求を出した場合は、安定して比較できる node ID の大きい側が Sender に残る。もう一方は自分の要求を取り消して Receiver になる。別々の平行リンクは衝突ではない。この規則は会話を一つにするが、休止が事業上妥当かまでは決めない。

電源を落としても TE の記憶は消せない

休止中も link identity、addressing、TE attributes、平行リンクの区別を保つ。既存 LSP、path、reservation、label、protection state は、該当する protocol と policy に従って保持または整合させる。休止を暗黙の正常 teardown とみなしてはいけない。

ただし保持は整合性の保証ではない。長い休止の間に reservation が古くなり、一方のデータベースだけが資源を利用可能と見なすことがある。利用不能中の新規使用を防ぎ、wake と local readiness の後にだけ通常の eligibility を戻す必要がある。

復旧記録は、何を保持し、撤回し、変更し、再設定したかを示さなければならない。DB に行を残すことと、分散制御状態が同じ版に戻ることは別である。

目覚まし時計は眠ったリンクの外に置く

GoWakeup はどちらの端点、ローカル policy、service requirement からでも始められ、反復しても安全である。しかし要求は、眠っている資源の動作に依存しない経路で届かなければならない。少なくとも一つの control-plane path が残る必要がある。

「管理網」という名称だけでは独立性にならない。論理上は別でも、同じ line card、duct、optical span、電源を共有していれば一緒に失われる。ドラフトは特定の out-of-band 構成を命じないが、運用者に依存関係の証明を求める形になっている。

そして GoWakeup の受信は復旧開始にすぎない。hardware ready、adjacency または reachability、reservation の整合、TE 参加、実トラフィックの通過を順に確認する必要がある。wake message の配送は forwarding の復旧ではない。

証拠の鎖は、正確な revision、承認済み policy、複合 resource identity、両端の eligibility、準備、最終指示、物理状態、TE state custody、独立 wake path、local readiness、TE 復帰、転送結果に分かれる。消費電力や炭素の主張には、さらに別の計測と帰属が要る。

Lu Heng の最小初期仕様という考え方なら、共通層は identity、messages、roles、collision、fail-safe に絞れる。休止条件、物理制御、証跡、サービス閾値はリスクを負う運用者が決める。自発的採用は文書公開ではなく running code と結果で示される。

出典