Summary

  • draft-many-teas-rsvp-power-00 proposes a five-mode, bilateral framework for putting one explicitly identified traffic-engineered resource to sleep and waking it again. Revision 00 is an individual work-in-progress Internet-Draft; its RSVP POWER object values remain unassigned.
  • The protocol deliberately separates coordination from physical power control. A reliable exchange can prove state-machine progress, but it cannot by itself prove traffic drainage, local hardware state, coherent retained TE state, an independent wake path or restored forwarding.

Two routers agree that a lightly used link may sleep. One sends SleepPrepare; the other accepts. The sender later issues GoSleep, receives GoSleepAck and records the transaction as complete. The monitoring console turns the link grey. The power ledger still shows the same draw.

Nothing in that sequence requires fraud. The signaling engine and the physical power manager are different systems. A local interlock may have refused the hardware action. One end may have entered a low-power state while the other remained active. A reservation may still refer to the link. Or the link may genuinely be asleep while the only route capable of waking it has vanished with it.

Power Transition Framework for TE Resources, dated 30 September 2026, is unusually clear about this boundary. Its proposed protocol coordinates adjacent endpoints; a separate local component performs the physical operation. “An implementation MUST NOT report successful completion merely because a sleep request was sent.” That sentence turns an energy feature into a question of evidence.

Revision 00 is an individual Standards Track Internet-Draft associated with TEAS. It expires on 3 April 2027. It is not an RFC, working-group consensus, an IANA allocation or proof of an implementation. The new RSVP POWER object's class number and C-Type are still TBD.

One resource, not merely one adjacency

The framework starts with a scope rule that deserves operational attention. A sleep transaction applies to one explicitly identified resource. The identifier must distinguish parallel links between the same pair of nodes. A node cannot act on another interface merely because the request arrived over a related adjacency.

For the RSVP realization, a numbered link is identified by the sender's local link address with a zero link index. An unnumbered link uses the sender's router identifier and its local unnumbered TE link identifier. The pair is a composite identity. If the receiver cannot resolve it unambiguously, it must reject the request rather than guess.

That prevents a dangerous shortcut. “Peer A asked Peer B to save power” is not enough information when A and B share four fibres with different reservations and protection roles. The receipt needs the resource tuple, the authenticated peer and the local interface to which the receiver resolved it. Identity is part of the safety mechanism, not inventory decoration.

Preparation is a promise to continue, not a completed act

The generic state machine has five modes. Operating means there is no active sleep coordination. Requisition means the sender has asked the peer to prepare. Ready means the peer has accepted, while the initiator still awaits local authorization or the receiver awaits the final instruction. Pending follows GoSleep. Sleeping is the coordinated terminal state.

Those names preserve distinctions that dashboards often erase. SleepPrepareAck says the receiver resolved the resource and was willing to participate. It does not say that the interface is dark. GoSleep authorizes the next stage. It does not show that either endpoint's power manager acted. GoSleepAck completes the peer exchange, but the implementation still has to couple that exchange to truthful local state.

A useful receipt therefore records both planes. The protocol plane carries message ID, peer, resource, role, expected state, acknowledgement and timer result. The execution plane records each endpoint's power-manager decision and observed hardware state. If a device exposes only “sleep succeeded” without revealing which evidence closed the claim, an operator cannot distinguish a completed physical transition from a tidy state-machine label.

Failure is designed to stay awake

The draft's safest property is conservative failure. An unknown resource, missing capability, invalid peer relationship, failed local authorization, malformed message, failed send or unexpected state must not power down the resource. The node stays in, or returns to, Operating. A timer expiry removes transaction state and reports failure; it must not trigger power-down as a side effect.

The proposed RSVP procedure uses 180 seconds for the SleepPrepare and GoSleep confirmation phases. That number is a default wait, not a service-level promise and not evidence that a transition required 180 seconds. Operators should record which phase expired, the resource identity, the last valid message and whether local actuation had begun.

Both endpoints may initiate the same transition simultaneously. For the same resource, the node with the numerically higher stable comparable identifier remains Sender; the loser cancels its own Sender transaction and proceeds as Receiver. The rule does not collapse separate parallel links into one collision. Equal identifiers are invalid or ambiguous and should reach an operator rather than create two active transactions.

This deterministic tie-break is a minimum coordination rule. It does not decide whether sleeping the link is commercially or operationally wise. Local policy still owns demand forecasts, protection margins, maintenance windows and which services make a resource ineligible.

The control plane must remember what the hardware forgets

Powering down a TE resource cannot silently erase the structures needed to bring it back. The draft requires link identity, addressing, TE attributes and parallel-link disambiguation to survive the sleep interval. Existing LSP, path, reservation, label and protection state must be retained or reconciled under the relevant protocol and policy. Sleep is not an implicit successful teardown.

Retention is helpful but not automatically correct. A reservation preserved during a long sleep can become stale. A protection commitment may now depend on a different failure model. A path computation engine may have excluded the resource while another database still advertises it. The draft requires nodes to prevent new use of an unavailable resource and to restore eligibility only after wakeup and local readiness. The operator still needs a reconciliation receipt showing which state was retained, withdrawn, changed and reinstated.

This is the separation between reversibility in theory and reversibility in production. Keeping an object in a database makes restoration possible. It does not prove that the physical link, adjacency, labels, reservations and protection state will converge to the same coherent version.

A sleeping link cannot carry its own alarm clock

Wakeup may be initiated by either endpoint, a service requirement or local policy. The initiator sends GoWakeup; each endpoint independently restores its local resource state and cleans up the sleep transaction. Repeated wakeup requests are idempotent.

But the request must travel over a path that does not depend on the sleeping resource being operational. The framework requires at least one control-plane path to remain available while the resource sleeps. This is more than an implementation detail. It is a precondition for recoverability.

The wake-path proof should identify the route, trust relationship and failure domain that remain reachable after the target resource disappears. A management path that shares the same line card, conduit, optical span or power feed may be logically different and physically doomed. The draft does not prescribe an out-of-band design; it makes the dependency visible for local architecture to solve.

And GoWakeup is only the start of recovery. A truthful closeout observes the local hardware become ready, the adjacency or reachability return, retained state reconcile, the resource re-enter TE participation, test traffic pass and protected services remain within their constraints. “Wake message delivered” is not “forwarding restored.”

Reliable messaging is not outcome assurance

In the RSVP-TE realization, ResourceNotify carries a RESOURCE_SPEC and the proposed POWER object. MESSAGE_ID with ACK_Desired supplies reliable-message mechanics. The power procedure adds roles, expected states, transaction correlation and timers. Unknown codes, missing resource identity or malformed mandatory content must not trigger a power action.

Those controls are valuable precisely because they have limited scope. They can show that the intended peer received a valid message and that duplicates were handled. They cannot measure watts, prove traffic drained, inspect a relay, validate a laser's state or observe a packet after restoration.

The operational evidence chain is therefore explicit: exact specification revision; approved local policy; composite resource identity; eligibility at both endpoints; correlated preparation; correlated sleep instruction; separate physical-state receipts; custody of TE state; independent wake reachability; local readiness; restored TE participation; and observed forwarding. Any energy or carbon claim comes after that chain and needs its own measurement and attribution.

Heng Lu's minimum-initial-specification principle fits this architecture. The common protocol can stay narrow: deterministic identity, messages, roles, collision handling and fail-safe transitions. Operators retain decisions about eligibility, physical actuation, evidence retention and service thresholds. Voluntary adoption is proved by running code and results, not by the publication of a draft or the presence of a feature flag.

The draft does not promise that a sleeping link is green, safe or recoverable. It does something more useful for an initial proposal: it names the points where those claims must stop borrowing proof from one another.

Sources