Hybrid Energy Saving Mechanism for Transport Network

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 6 May 2027.¶

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

This document presents a transport network energy saving management framework that harmonizes device-level autonomy with network-wide coordination. The framework is grounded in the reference model defined in [I-D.belmq-green-framework], and addresses the specific requirements identified in [I-D.ietf-green-use-cases] through practical mechanisms for multi-layer energy optimization.¶

The framework is organized into two functionally distinct yet complementary layers that work in concert to achieve coordinated energy optimization:¶

• Device-Centric Energy Saving: The device-centric management encompasses individual network elements that execute real-time, localized energy adjustments based on local data collection and policies received from the network controller. Device-centric management enables a fast response to transient traffic conditions and maintains autonomous operation.¶
• Controller-Centric Energy Saving: The controller-level energy management provides centralized visibility, cross-layer analysis, and strategic policy formulation across the entire network domain. Controller-centric management performs long-term traffic prediction, assesses network-level risks, and provides a northbound interface to users for intuitive evaluation of energy-saving effects.¶

2. Monitoring

Transport networks require comprehensive, real-time, and granular measurements spanning physical, logical, and environmental domains to enable cross-layer correlation and coordinated optimization.¶

• Power Monitoring: Power monitoring is the foundation for understanding energy consumption patterns and identifying optimization opportunities. Power monitoring encompasses measurements at multiple hierarchical levels within network elements, from component-level power consumption including that of boards, fans, and PSUs, to device-level chassis power consumption.¶
• Traffic Monitoring: Traffic monitoring extends the framework to address transport network-specific requirements. Understanding traffic characteristics across multiple layers is essential for correlating energy consumption with network utilization and for identifying temporal patterns that enable predictive optimization. This enables both real-time response to transient traffic changes and long-term trend analysis for strategic planning.¶
• Topology Monitoring: Topology monitoring provides the cross-layer visibility necessary for coordinated energy optimization. Transport networks span multiple protocol layers with complex interdependencies; understanding these relationships is critical for making energy-saving decisions that respect service requirements and network constraints. Topology monitoring across both transport and IP layers should be used to capture relevant logical relationships, such as protection relationships, resource aggregation, and service-to-infrastructure mappings that support the formulation of energy optimization strategies.¶

3. Hybrid Device-and-Controller Coordination

Section 6.1 of [I-D.belmq-green-framework] discusses the implementation focus and where intelligence resides. The transport network uses the hybrid approach which requires both device capabilities and controller coordination.¶

Transport network devices must independently manage their energy saving functions regardless of whether the DCN is available for local real-time processing. They require local algorithms, minimal controller dependency, and autonomous operation. Secondly, the device-centric function performs traffic prediction, quickly responds to short-term traffic changes, formulates strategies, and executes actions.¶

On the other hand, the controller-centric energy saving function performs long-term traffic prediction based on network topology resources, assesses network-level risks, provides a northbound interface to users, and enables visualized and intuitive evaluation of energy-saving effects.¶

Depending on the scenario, inference time, accuracy, and other factors, different intelligent algorithms are deployed on the controllers and devices to predict long‑term trends, short‑term cycles, and burst traffic. This allows the controller to accurately predict long-term changes in services and devices to accurately predict short-term burst traffic, thereby adjusting the equipment operating status in advance and avoiding service disruption.¶

4. Device-Centric Energy Saving

This allows devices to make local decisions on resource scheduling based on real-time, node-local data/information collection, enabling faster reaction to transient traffic conditions via on-device analysis.¶

1. Data collection¶

   • Sensors continuously gather real-time power and energy-related metrics, including chip, port, board, fan, and chassis power consumption, as well as device zone temperature and instantaneous traffic load.¶

2. Analysis¶

   • An embedded processing unit applies lightweight algorithms to model the relationship between local load and power consumption. It performs short-term traffic trend prediction, evaluates energy-saving strategies through simulation, and supports cross-layer command coordination. Conditions are continuously assessed against configured energy-saving policies.¶

3. Simulation and Verification¶

   • The simulation model describes the relationships among device parameters and relationships between devices. It uses the scenario-specific data and the energy-saving scheme to simulate and verify the power consumption information after the scheme is executed. Based on the power consumption information, the feasibility of the energy-saving scheme is tested and determined.¶

4. Control and Execution¶

   • Devices dynamically switch the power state of the components (e.g., ports, line cards, switch cards, chassis) based on local traffic load, in accordance with policies received from the network controller. For instance, when predicted traffic falls below a predefined threshold, the system sequentially initiates energy-saving actions, such as placing boards into sleep mode and intelligently adjusting fan speeds.¶
   • Supported power states include deep sleep, light sleep, normal operation, and power-off. Deep sleep maintains only essential core links, substantially reducing energy consumption during idle periods. Light sleep can support hitless wake-up from sleep modes to ensure zero service impact, particularly for high-priority services.¶

5. Controller-Centric Energy Saving

This network-level energy management operates from a network controller platform, providing a holistic view and strategic control. Unlike device-local management, its role is primarily one of coordination, optimization, and assurance across the multi-layer network.¶

1. Data collection¶

   The controller ingests and correlates telemetry from all managed devices, building a holistic network model that spans real-time power consumption, topology, and traffic state.¶

   • Transport Layer Topology: Logical link information and resource status from both the optical layer (L0) and electrical layer (L1/L2).¶
   • IP Layer Topology: Logical links, protection relations and routing adjacencies from the IP layer (L3). For instance, protection paths may carry extra traffic under normal conditions but must be reserved for failover scenarios. This integrated view allows the network controller to assess risks, such as extended wake‑up delays from deep sleep modes, that could impact service performance during protection switching or other reactive scenarios.¶

2. Analysis¶

   • Leveraging AI/ML and analytical engines, the controller performs predictive traffic and load forecasting. It identifies optimization opportunities through cross-layer correlation. It can also simulate the potential impact of different energy management strategies before deployment.¶

3. Control and Execution¶

   The central controller acts as the brain for network-level energy optimization. Its key functions are as follows:¶

   The controller analyzes historical and real-time traffic data to predict future load patterns. Based on these predictions and service SLAs, it generates holistic energy-saving strategies.¶

   • Computing paths for traffic migration to consolidate services onto fewer network elements.¶
   • Instructing idle or underutilized devices to enter low-power states (e.g., deep sleep for best-effort services, light sleep for premium services). These policies are then dispatched to devices.¶

   Cross-layer Coordination: The controller translates high-level strategies into specific, synchronized actions for both transport and IP layers to ensure service continuity. For example, before putting a transport node to sleep, it coordinates with the IP layer to reroute traffic away from that node.¶

6. Information Exchange Interfaces

This section describes the collaborative information exchanges between device-centric and controller-centric energy saving functions. The hybrid approach leverages the strengths of both levels: devices provide fast, localized responses, while the controller provides network optimization and policy guidance. Coordination between devices and the controller relies on a set of well-defined interfaces. The key information exchanges are summarized below.¶

Device-to-Controller Interactions:¶

• Capability Reporting: Upon initialization or capability modification, a device advertises its supported power states (e.g., deep sleep, light sleep), state transition delays, operational granularity (e.g., port-level, board-level, or chassis-level), and specific operational constraints to the controller.¶
• Energy Measurement Data Reporting: Devices periodically (e.g., every 15 min) report component-level measurements including power consumption, temperature, and traffic load to the controller, enabling the controller to maintain a network-wide energy view.¶
• State Change Notification: When a device undergoes a power state change, or when an energy-saving action succeeds or fails, the device actively notifies the controller of the event, including the target component, prior and current states, timestamp, execution result, and failure reason if applicable.¶
• Policy Feedback: Upon receiving a policy from the controller, the device responds with an acceptance or rejection. If accepted, the device may subsequently report its execution status of the policy.¶

Controller-to-Device Interactions:¶

• Policy Provisioning: When an energy saving policy is generated or updated, the controller pushes it to the target devices. Each policy specifies the target components, the desired power states, trigger conditions (e.g., time windows or traffic thresholds), rollback conditions, maximum allowable wake-up delay, and priority level.¶
• On-Demand Querying: The controller may explicitly query a device to retrieve its current energy-saving state or historical operational energy data.¶

Device-to-Device Interactions:¶

• Peer Coordination: Devices within the same protection group synchronize their energy-saving states with each other. This ensures that when one device enters a sleep state, its protection peer is aware of the status, preventing any adverse impact on failover capabilities.¶

All data interactions are designed to be asynchronous. Devices execute local decisions based on pre-configured policies without waiting for controller confirmation, ensuring rapid response to transient conditions. However, devices MUST report state changes to the controller to maintain global state consistency.¶

7. YANG Data Model Considerations

The implementation of the hybrid device-centric and controller-centric energy optimization requires standardized data models for representing energy-related information, policies, and control mechanisms. This section discusses the YANG data model considerations for this implementation.¶

The framework defines information flows between devices and controllers:¶

                               User
                                ^
                                |
                                |
                                v
+------------------------------------------------------------------+
|                                                                  |
|                 Transport Network Controller                     |
|                                                                  |
+------------------------------------------------------------------+
               ^                                   ^
               |                                   |
            Monitoring                   Energy-Saving Strategy
               |                                   |
               v                                   v
+----------------------------+        +----------------------------+
|                            |        |                            |
|  Transport Network Element |<------>|  Transport Network Element |
|                            |        |                            |
+----------------------------+        +----------------------------+

Devices report operational data including power measurements, traffic characteristics, device status, and multi-granular aggregated data to the controller. Conversely, the controller provisions and updates devices with energy-saving policies, SLA constraints, cross-layer control commands, and configuration modifications.¶

To address this hybrid coordination, the following YANG considerations should be evaluated:¶

1. Controller and Users: YANG models for northbound interfaces enabling users to configure energy-saving objectives, view optimization results, and monitor energy consumption.¶
2. Controller and Devices: YANG models for southbound interfaces enabling the controller to distribute policies, receive telemetry, and issue control commands to devices.¶
3. Device and Device: Peer-to-peer interactions between devices to support cross-layer coordination and local optimization. This may involve protocol or signaling extensions, such as capability advertisement, energy-saving status synchronization, or notifications of energy-saving policies, which can guide other devices to perform operations or provide information to other devices.¶

Transport networks differ from other network domains in that energy-saving operations are subject to a set of operational constraints that are specific to the transport domain. Devices MUST advertise these constraints to the controller so that the controller can formulate energy-saving strategies that do not compromise network reliability. The following constraints are defined:¶

Protection Constraints:

In transport networks, network elements are typically organized into protection groups (e.g., 1+1, 1:N) to ensure service survivability per ITU-T G.808.1. A component that belongs to an active protection group MUST NOT be placed into a power-saving state unless the protection function can be guaranteed by other means. For each protection group, the device advertises:¶

• protection-group-id: unique identifier of the protection group¶

• role: working or protection¶

• protection-type: 1+1, 1:N, or shared-mesh¶

• energy-saving-permitted: true or false¶

• permitted-states: list of power states allowed (e.g., only light-sleep, not deep-sleep)¶

For example, in a 1+1 protection configuration, the working line card may be permitted to enter light sleep during low-traffic periods if the protection line card remains fully operational. The protection line card itself MUST NOT be placed into any sleep state as it must be ready for immediate failover. In contrast, in a 1:N protection configuration where one protection card backs up N working cards, all N working cards may be candidates for energy saving, but the protection card must remain in the normal state at all times.¶

Service Priority Constraints:

Transport networks carry services with different priority levels. Devices advertise the maximum service priority level that can be affected by energy-saving operations. Components carrying services above this priority level MUST NOT be placed into energy-saving states. The device advertises:¶

• max-affected-service-priority: integer value (0-7, where 0 is highest)¶

• Each component advertises current-service-priority: the highest priority of all services currently traversing it¶

A typical configuration in a transport network may set max-affected-service-priority = 3, meaning that services with priority 0, 1, 2 (e.g., 5G backhaul, financial trading, emergency services) are never impacted. Only services with priority 3-7 may be subject to energy-saving actions. This ensures that critical services maintain their SLA commitments defined in the service-level agreement.¶

Time Window Constraints:

Transport networks often have predictable traffic patterns with distinct peak and off-peak periods for network operations. Devices are configured with time windows during which energy-saving operations are permitted or prohibited. Each time window includes:¶

• window-id: unique identifier¶

• window-type: permitted or prohibited¶

• recurrence: daily, weekly, once¶

• start-time: e.g., T00:00:00+08:00 (local time)¶

• end-time: e.g., T06:00:00+08:00¶

• day-of-week: list of days if weekly recurrence¶

A typical transport network configuration permits light sleep on weekdays from 00:00 to 06:00 and throughout weekends, but prohibits any deep sleep during business hours (08:00-20:00) to maintain service availability. For example, an OTN device may be configured with the following time windows:¶

• permitted: daily 00:00-06:00, all day Saturday and Sunday¶

• prohibited: daily 08:00-20:00 (business hours)¶

• cautious: daily 06:00-08:00 and 20:00-00:00 (transition windows where only light sleep is permitted, not deep sleep)¶

8. Security Considerations

A general principle is that the more significant the energy savings, the slower the module response time and the longer the wake-up delay, which may impact service performance.¶

To address this, the following items should be considered:¶

1. Power state configuration aligned with service tolerance: During low-traffic periods (e.g., nighttime), idle line cards/standby main control units can enter deep sleep mode for maximum energy savings. During peak hours (e.g., daytime), a light sleep mode should be adopted to enable faster wake-up and minimize service disruption.¶
2. Resource reservation for reliable energy efficiency: In the transport network, the total bandwidth utilization of a network element is primarily determined by the aggregate traffic across its ports. However, in practice, the available capacity cannot be entirely assigned to user traffic, as a portion of the bandwidth must be reserved for protection switching, rerouting operations and control-plane overhead. This ensures the network reliability during network anomalies or congestion events.¶

Therefore, redundant resources should be reserved to accommodate scenarios like protection switching during failures. This guarantees service reliability while maintaining energy-saving benefits.¶

Authors' Addresses