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, . 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", DOI 10.17487/RFC8174, BCP 14, RFC 8174, May 2017, . 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, . 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]