Internet-Draft hybrid energy saving mechanism for trans July 2026
Chen, et al. Expires 7 January 2027 [Page]
Workgroup:
GREEN
Internet-Draft:
draft-chen-green-transport-energy-saving-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
X. Chen
CMCC
J. Zhou
ZTE
J. Yan
ZTE

Hybrid Energy Saving Mechanism for Transport Network

Abstract

This document continues the transport network energy saving that harmonizes device-level autonomy with network-wide coordination. By implementing control at hybrid both the device and network controller coordination, it enables dynamic, SLA-aware, and multi-layer energy optimization.

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 7 January 2027.

▲

Table of Contents

1. Introduction

This document presents transport network energy saving management framework that harmonizes device-level autonomy with network-wide coordination. The framework is grounded in [I-D.belmq-green-framework] 's reference model 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:

2. Monitoring

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

3. Hybrid Both Device and Controller Coordination

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

Transport network device must independently manage its energy saving no matter DCN is available for local real-time process. It needs local algorithms, minimal controller dependency, autonomous operation. Secondly, the device-centric performs traffic prediction, quickly responds to short-term traffic changes, formulates strategies, and executes actions.

On the other side, the controller-centric energy saving 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 controller and device to intelligently predict long and short 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 though 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 between parameters of device and relationships between devices themseleves. It use the data from scenario and energy-saving scheme to simulate and verfify the consumption information after executing energy-saving scheme. Based on the power consumption information, the feasibility of 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 device 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 satisfy 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 also can simulates 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 include:

    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 layers: devices provide fast, localized responses to transient conditions, while the controller provides global optimization and strategic guidance. The coordination between devices and the controller relies on a set of well-defined information exchange interfaces. The key information flows are summarized below.

Device-to-Controller Information Flows:

Controller-to-Device Information Flows:

Device-to-Device Information Flows:

All interfaces are designed to be asynchronous. Devices do not wait for controller confirmation before executing local decisions based on pre-provisioned policies, which ensures fast response to transient conditions. However, devices are expected to report state changes to the controller to maintain global view 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 |
|                            |        |                            |
+----------------------------+        +----------------------------+
Figure 1: Transport Network Energy Saving Framework

Devices report operational data including power measurements, traffic characteristics, device status, and multi-granularity aggregated data to the controller. Controllers distribute energy-saving policies, SLA constraints, cross-layer control commands, and configuration updates to devices.

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 the notifications of energy-saving policies, which can guide other devices to perform operations or provide information to the 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:

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 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:

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 advertise time windows during which energy-saving operations are permitted or prohibited. For each time window, the device advertises:

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:

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 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. It ensures the network reliability during network anomalies or congestion events.

So redundant resources should be reserved to accommodate scenarios like protection switching at failure cases. This guarantees service reliability while maintaining energy-saving benefits.

9. Informative References

[I-D.belmq-green-framework]
Claise, B., Contreras, L. M., Lindblad, J., Palmero, M. P., Stephan, E., and Q. Wu, "Framework for Energy Efficiency Management", Work in Progress, Internet-Draft, draft-belmq-green-framework-10, , <https://datatracker.ietf.org/doc/html/draft-belmq-green-framework-10>.
[I-D.ietf-green-terminology]
Chen, G., Boucadair, M., Wu, Q., Contreras, L. M., and M. P. Palmero, "Terminology for Energy Efficiency Network Management", Work in Progress, Internet-Draft, draft-ietf-green-terminology-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-green-terminology-02>.
[I-D.ietf-green-use-cases]
Stephan, E., Palmero, M. P., Claise, B., Wu, Q., Contreras, L. M., Bernardos, C. J., and X. Chen, "Use Cases for Energy Efficiency Management", Work in Progress, Internet-Draft, draft-ietf-green-use-cases-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-green-use-cases-01>.

Authors' Addresses

Xinyu Chen
China Mobile
No.32 Xuanwumen west street
Beijing
100053
China
Jin Zhou
ZTE Corporation
Jinjie Yan
ZTE Corporation