Power Transition Framework for TE Resources
draft-many-teas-rsvp-power-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Srihari R. Sangli , Colby Barth , Vishnu P. Beeram , Tony Li , Ron Bonica | ||
| Last updated | 2026-09-30 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-many-teas-rsvp-power-00
Traffic Engineering Architecture and Signaling S. Sangli
Internet-Draft C. Barth
Intended status: Standards Track V. P. Beeram
Expires: 3 April 2027 T. Li
R. Bonica
Hewlett Packard Enterprise
30 September 2026
Power Transition Framework for TE Resources
draft-many-teas-rsvp-power-00
Abstract
Traffic-engineered networks are commonly provisioned for peak demand.
However, during off-peak periods, some traffic-engineered resources
in the network may be lightly used. This leads to unnecessary power
consumption. A coordinated power transition can reduce power
consumption while preserving the control-plane and traffic-
engineering state needed to restore service safely.
This document defines a generic power management framework for
coordinating power-sleep and wakeup transitions between adjacent
nodes. It defines the roles, resource scope, procedures, collision
handling, failure behavior, and traffic-engineering preservation
requirements. It then specifies an RSVP-TE signaling extension for
supporting the power management framework.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 3 April 2027.
Sangli, et al. Expires 3 April 2027 [Page 1]
Internet-Draft Power Transition Framework for TE Resour September 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language and Terminology . . . . . . . . . . . . 3
3. Power Transition Procedures . . . . . . . . . . . . . . . . . 3
3.1. Roles and Resource Scope . . . . . . . . . . . . . . . . 4
3.2. Wakeup Procedure . . . . . . . . . . . . . . . . . . . . 4
3.3. Power-Sleep Procedure . . . . . . . . . . . . . . . . . . 5
3.4. Concurrent Requests and Collision Resolution . . . . . . 6
3.5. Failure, Timeout, and Recovery . . . . . . . . . . . . . 6
3.6. Traffic and TE-State Preservation Requirements . . . . . 7
4. RSVP-TE Signaling . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Mapping of Power-Transition Messages to RSVP . . . . . . 8
4.2. POWER Object . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Resource Identification . . . . . . . . . . . . . . . . . 9
4.4. Reliability, Acknowledgment, and Transaction
Correlation . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Backward Compatibility and Error Handling . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . 11
9. Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Operational networks are frequently engineered for peak utilization.
During lower-demand periods, portions of the topology may remain
active even though their forwarding capacity is not immediately
required. A power-management system can place an eligible traffic-
engineered resource in a low-power or power-down state and later
restore it when demand or policy requires.
Sangli, et al. Expires 3 April 2027 [Page 2]
Internet-Draft Power Transition Framework for TE Resour September 2026
A power transition is a distributed operation. Both ends of a
resource must agree before the resource is powered down, and the
control plane must continue to identify the resource and retain
sufficient traffic-engineering information to restore it. The
mechanism that controls the physical power state is implementation-
specific and is outside the scope of this document. This document
specifies the coordination protocol and its signaling requirements.
The framework is intentionally independent of RSVP-TE. Section 3
defines the generic procedures. Section 4 defines how RSVP-TE
carries those procedures for a directly connected RSVP-TE link.
RSVP-TE is one signaling realization of the framework; the framework
does not require RSVP-TE for other resource types or signaling
protocols.
2. Requirements Language and Terminology
The key words *MUST*, *MUST NOT*, *REQUIRED*, *SHALL*, *SHALL NOT*,
*SHOULD*, *SHOULD NOT*, *RECOMMENDED*, *NOT RECOMMENDED*, *MAY*, and
*OPTIONAL* in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174].
Power-sleep A coordinated transition in which the underlying
hardware for a resource is powered down or placed in a low-power
state.
Wakeup A transition that restores the underlying hardware to its
forwarding-capable state.
Sender The node that initiates a power-sleep transaction.
Receiver The adjacent node that receives and accepts or rejects a
power-sleep request.
Power manager The local system component that applies the physical
power transition. Signaling protocol processing MUST NOT be
assumed to perform the physical operation itself.
Power resource The link or other traffic-engineered resource
identified by the transaction.
3. Power Transition Procedures
Sangli, et al. Expires 3 April 2027 [Page 3]
Internet-Draft Power Transition Framework for TE Resour September 2026
3.1. Roles and Resource Scope
A power-sleep transaction operates on one explicitly identified
resource. The resource identifier MUST be sufficient to distinguish
parallel links between the same pair of nodes. A node MUST NOT apply
a transition to a different resource merely because the message
arrived over a related adjacency or interface.
The node requesting power-sleep is the Sender and the adjacent node
is the Receiver. These roles apply to one power-sleep transaction
only; a later transaction MAY assign the roles differently. Wakeup
is not restricted to one Sender. Either endpoint, or a local policy
or service event, MAY initiate wakeup.
Each endpoint SHOULD maintain local transaction state for the
resource. At a minimum, the model MUST have the following modes:
* *Operating mode:* no active power-sleep coordination exists and
the resource is available for normal operation.
* *Requisition mode:* the Sender has requested preparation for an
upcoming power-sleep and is waiting for acceptance or rejection.
* *Ready mode:* the Sender has received acceptance and is waiting
for local power manager authorization; or the Receiver has
accepted the request and is waiting for the Sender's final
instruction.
* *Pending mode:* the Sender has issued the sleep instruction and is
waiting for confirmation.
* *Sleeping mode:* the resource has completed the coordinated
transition to its low-power or power-down state.
An implementation MAY represent Operating mode by the absence of a
transaction object. Changes in mode SHOULD be recorded for
operational diagnosis.
3.2. Wakeup Procedure
Wakeup MAY be initiated by either endpoint, by an ingress or service
requirement, or by local policy. The initiator sends request for
wakeup with the resource identifier. The peer receiving wakeup
request MUST resolve the resource and request or perform local
wakeup.
Sangli, et al. Expires 3 April 2027 [Page 4]
Internet-Draft Power Transition Framework for TE Resour September 2026
At each endpoint, the wakeup operation triggers an independent
restoration of the local resource state to Operating mode and cleanup
of the sleep state. The endpoint initiating wakeup MUST use a path
to send the wakeup request such that it does not depend on the
sleeping resource being operational.
3.3. Power-Sleep Procedure
The following procedure applies to a resource eligible for power-
sleep:
1. The Sender in Operating mode verifies local policy, resource
eligibility, and the availability of a live adjacency or
equivalent peer relationship.
2. The Sender in Requisition mode creates transaction state for the
resource and requests to prepare for sleep, identifying the
resource.
3. The Receiver resolves the resource identifier and verifies that
the resource is locally eligible. If it cannot participate, it
continues to be in Operating mode and sends negative
acknowledgement. If it can participate, it sends acknowledgement
and transitions to Ready mode.
4. Upon receiving acknowledgment, the Sender transitions to Ready
mode, and notifies its local Power manager that preparation has
completed. This is the end of the sleep preparation phase.
5. If the intent is to put the interface to power-sleep, driven by
the local policy, the Sender in Ready mode instructs the Receiver
to sleep and transitions to Pending mode while waiting for
confirmation.
6. Upon receiving the request to sleep, the Receiver in Ready mode
acknowledges the request and completes its local transition to
Sleeping mode. The Sender, upon receiving acknowledgment from
the Receiver, completes its local transition to Sleeping mode.
7. The Sender may adopt a configurable timeout value to avoid
waiting indefinitely for a response from the Receiver.
The signaling protocol coordinates the endpoints. A local power
management framework that is outside the scope of this document is
responsible for the physical operation triggered by the Sleeping
state. An implementation MUST NOT report successful completion
merely because a sleep request was sent.
Sangli, et al. Expires 3 April 2027 [Page 5]
Internet-Draft Power Transition Framework for TE Resour September 2026
3.4. Concurrent Requests and Collision Resolution
Both endpoints can independently initiate preparation for sleep. If
a node has an active Sender transaction for the same resource when it
receives a competing request for sleep preparation, the nodes MUST
deterministically select one Sender.
The node identifiers used for the tie-break MUST be stable and
globally comparable within the protocol domain. The node with the
numerically higher identifier wins and remains Sender. It sends a
negative acknowledgment for the competing request. The losing node
cancels its Sender transaction, assumes the Receiver role, and
continues processing the peer's request. Equal identifiers are an
invalid or ambiguous condition. In such a case, the node MUST avoid
creating two active transactions and SHOULD log the condition for
operator intervention before discarding the competing request.
Collision resolution MUST be applied only when the requests identify
the same resource. A request for another parallel link is not a
collision.
Repeated wakeup requests MUST be handled idempotently.
3.5. Failure, Timeout, and Recovery
A node MUST reject or abort a transaction when it cannot resolve the
resource, lacks the required capability, lacks a usable peer
relationship, or cannot obtain local power manager authorization.
Where a response can still be sent, the Receiver SHOULD send a
negative acknowledgment. The Sender MUST treat a rejection as an
unsuccessful transaction and release its active state.
The Sender MUST bound the time spent waiting for a response from the
Receiver. The recommended default for each wait is 180 seconds. On
expiry, the Sender SHOULD release the transaction state and log the
failure for operator intervention. The timer does not imply
retransmission; an implementation MAY add retransmission only if it
preserves transaction correlation and bounded duplicate handling.
A failed send, malformed message, unknown resource, or unexpected
state MUST NOT cause an implementation to power down a resource.
Such a condition MUST leave the resource in, or return it to
Operating mode. Cleanup MUST cancel any associated timers and
discard the transaction.
Sangli, et al. Expires 3 April 2027 [Page 6]
Internet-Draft Power Transition Framework for TE Resour September 2026
Administrative disabling of power management MAY immediately discard
active transaction state. It MUST NOT be interpreted as a successful
negotiated sleep. The implementation SHOULD log the reason for the
abort.
3.6. Traffic and TE-State Preservation Requirements
Power transition signaling MUST NOT silently destroy the traffic-
engineering state associated with the resource. In particular:
* Link identity, addressing, TE attributes, and parallel-link
disambiguation MUST remain available across the sleep interval.
* Existing LSP, path, reservation, label, and protection state MUST
be retained or reconciled according to the applicable TE protocol
and policy. A power transition MUST NOT be treated as an implicit
successful teardown unless another protocol explicitly performs
that teardown.
* A node MUST prevent new use of an unavailable resource according
to its TE admission and flooding policy. The resource MUST become
eligible for normal use only after wakeup and local readiness have
completed.
* Wakeup processing MUST restore the resource's TE participation and
MUST use the preserved resource identity when reestablishing
adjacency, reachability, or reservations.
* There MUST be at least one control-plane path available for wakeup
while the resource is asleep.
Implementations SHOULD expose state transitions, failures,
collisions, and timeouts to operations.
4. RSVP-TE Signaling
This section specifies the RSVP-TE realization of the framework for a
directly connected RSVP-TE link. RSVP-TE carries the power-
transition messages in an RSVP ResourceNotify message as specified in
[I-D.kbr-teas-mptersvp]. The physical power action remains outside
RSVP-TE and is performed by the local power manager.
Sangli, et al. Expires 3 April 2027 [Page 7]
Internet-Draft Power Transition Framework for TE Resour September 2026
4.1. Mapping of Power-Transition Messages to RSVP
+===================+=======+============================+
| Framework message | Value | Meaning |
+===================+=======+============================+
| SleepPrepare | 0 | Sender proposes |
| | | preparation to power-sleep |
+-------------------+-------+----------------------------+
| SleepPrepareAck | 1 | Receiver accepts |
| | | preparation |
+-------------------+-------+----------------------------+
| SleepPrepareNak | 2 | Receiver rejects |
| | | preparation |
+-------------------+-------+----------------------------+
| GoSleep | 3 | Sender authorizes power- |
| | | sleep |
+-------------------+-------+----------------------------+
| GoSleepAck | 4 | Receiver confirms power- |
| | | sleep |
+-------------------+-------+----------------------------+
| GoWakeup | 5 | Initiator requests wakeup |
+-------------------+-------+----------------------------+
Table 1: Power Code Values
Each message is an RSVP ResourceNotify message containing one
RESOURCE_SPEC object as specified in [I-D.kbr-teas-mptersvp] and one
POWER object. A POWER object without a RESOURCE_SPEC object is
invalid and MUST be rejected.
4.2. POWER Object
Class = TBD, C-Type = TBD.
Its format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Power Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: POWER Object Format
Sangli, et al. Expires 3 April 2027 [Page 8]
Internet-Draft Power Transition Framework for TE Resour September 2026
The Power Code is an unsigned one-octet value. Values 0 through 5
have the meanings in Section 4.1. Values 6 through 255 are reserved
and MUST NOT be transmitted. A receiver that does not recognize a
Power Code MUST reject or discard the object according to RSVP object
processing rules and MUST NOT perform a power transition.
The POWER Object applies only to the resource identified by the
accompanying RESOURCE_SPEC object. A ResourceNotify message MUST NOT
carry more than one POWER object.
4.3. Resource Identification
The RESOURCE_SPEC object identifies the resource being transitioned.
For the RESOURCE_SPEC_Ipv4 Class or RESOURCE_SPEC_IPv6 Class, the
resource identifier is defined as:
* For a numbered link, the Sender's local link address is encoded in
the Link Address field and Link Index field is set to zero.
* For an unnumbered link, the Sender's Router Identifier is encoded
in the Link Address field and Sender's local unnumbered TE link
identifier is encoded in the Link Index field.
The tuple (Link Address, Link Index) MUST be interpreted as one
composite identifier. The receiver MUST resolve the tuple to its
local interface and MUST reject the request if it cannot
unambiguously do so.
4.4. Reliability, Acknowledgment, and Transaction Correlation
RSVP ResourceNotify provides the message container; the power
procedure provides the transaction semantics. The MESSAGE_ID with
ACK_Desired semantics for ResourceNotify message provides the needed
reliable transport for power coordination. However, both the Sender
and Receiver RSVP nodes MUST maintain state and a timer to recover
from error condition and put the resource back into Operating mode.
SleepPrepareAck and SleepPrepareNak correlate to a pending
SleepPrepare using the resource identifier and the peer relationship.
GoSleepAck correlates to a pending GoSleep using the same resource
identifier. An implementation MUST at minimum validate the resource
identifier, expected role, expected state, and peer before applying a
message.
A valid message received in an unexpected state MUST be ignored or
rejected without changing the power state. Duplicate acknowledgments
MUST be treated as harmless. GoWakeup MUST be processed
idempotently.
Sangli, et al. Expires 3 April 2027 [Page 9]
Internet-Draft Power Transition Framework for TE Resour September 2026
The RSVP implementation uses a timeout interval of 180 seconds for
the SleepPrepare and GoSleep confirmation phases. On expiry, the
state should be removed, the operation should be reported as failed,
and physical power-down MUST NOT be performed solely as a consequence
of the timeout.
ResourceNotify messages for a sleeping resource SHOULD be routed
through a reachable control-plane path independent of the sleeping
link.
4.5. Backward Compatibility and Error Handling
The POWER object is an optional RSVP extension. A node that does not
support power coordination may ignore or reject ResourceNotify
according to the RSVP processing rules applicable to an unknown
object. A Sender MUST treat the absence of a valid response as a
failed transaction and MUST NOT power down the resource unilaterally.
A receiver supporting this document MUST validate the ResourceNotify
object structure before interpreting its contents. ResourceNotify
messages carrying a POWER Object MUST contain a valid RESOURCE_SPEC.
Missing, malformed, duplicated, or unknown mandatory content MUST
result in rejection or discard and MUST NOT trigger a power action.
If the resource cannot be found, the peer relationship is not valid,
or local capability is unavailable, the receiver SHOULD send
SleepPrepareNak. Otherwise it MUST discard the message, record an
operational diagnostic, and leave the resource in Operating mode.
Power coordination is controlled by local policy. A local
administrative disable of RSVP power management MUST prevent new
coordination and MAY clear active coordination state. It MUST NOT
cause a GoWakeup exchange to be assumed.
5. Security Considerations
A forged or replayed power message could cause a link to become
unavailable or could cause unnecessary wakeup activity.
Implementations MUST apply the RSVP security and peer-authentication
mechanisms used for the associated RSVP adjacency and MUST validate
that the message is from the authorized peer for the identified
resource.
Sangli, et al. Expires 3 April 2027 [Page 10]
Internet-Draft Power Transition Framework for TE Resour September 2026
Resource identifiers, roles, expected states, and transaction
correlation MUST be checked before a message can cause a power
action. Implementations SHOULD rate-limit invalid messages and
record sufficient diagnostics to identify an attack or
misconfiguration. A malformed or unauthenticated message MUST NOT
cause a power transition.
6. IANA Considerations
IANA is requested to allocate a new RSVP object class number for the
POWER object, with C-Type 1.
IANA is requested to create a registry titled "RSVP Power Management
Codes". The registration policy is IETF Review. The initial values
are:
+=======+=================+============================+
| Value | Name | Reference |
+=======+=================+============================+
| 0 | SleepPrepare | This document, Section 4.1 |
+-------+-----------------+----------------------------+
| 1 | SleepPrepareAck | This document, Section 4.1 |
+-------+-----------------+----------------------------+
| 2 | SleepPrepareNak | This document, Section 4.1 |
+-------+-----------------+----------------------------+
| 3 | GoSleep | This document, Section 4.1 |
+-------+-----------------+----------------------------+
| 4 | GoSleepAck | This document, Section 4.1 |
+-------+-----------------+----------------------------+
| 5 | GoWakeup | This document, Section 4.1 |
+-------+-----------------+----------------------------+
Table 2: Initial RSVP Power Management Codes
Values 6 through 255 are reserved.
7. Acknowledgements
The authors would like to thank Joel Halpern for the invaluable
feedback and comments.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", DOI 10.17487/RFC2119, BCP 14,
RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Sangli, et al. Expires 3 April 2027 [Page 11]
Internet-Draft Power Transition Framework for TE Resour September 2026
[RFC3209] Awduche, D., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", DOI 10.17487/RFC3209, RFC 3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", DOI 10.17487/RFC8174, BCP 14, RFC 8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9. Informative References
[I-D.kbr-teas-mptersvp]
Kompella, K., Beeram, V.P., and C. Ramachandran, "RSVP-TE
Extensions for Multipath Traffic Engineered Directed
Acyclic Graph Tunnels", Work in Progress, Internet-Draft,
draft-kbr-teas-mptersvp, 2026,
<https://datatracker.ietf.org/doc/html/draft-kbr-teas-
mptersvp>.
Authors' Addresses
Srihari Sangli
Hewlett Packard Enterprise
Email: srihari.sangli@hpe.com
Colby Barth
Hewlett Packard Enterprise
Email: colby.barth@hpe.com
Vishnu P. Beeram
Hewlett Packard Enterprise
Email: vishnu.beeram@hpe.com
Tony Li
Hewlett Packard Enterprise
Email: tony.li@tony.li
Ron Bonica
Hewlett Packard Enterprise
Email: ron.bonica@hpe.com
Sangli, et al. Expires 3 April 2027 [Page 12]