Requirements for Energy Efficiency Management

1.1. Background

With rising energy costs and an increasing awareness of the environmental impact of running information technology equipment, Energy efficiency Management functions and management interfaces are becoming an additional basic requirement for network management systems and devices connected to a network.¶

This document defines requirements for standards specifications for Energy efficiency Management, including discovery functions, monitoring functions and control functions. Energy efficiency Management functions focus mainly on network devices and their built-in components that receive and provide electrical energy. Devices such as switches, routers, servers and storage devices should have an IP address providing a management interface for the network device. Alternatively, energy-related devices (for example, in building management, which typically don't support IP) might be connected via a proxy/gateway with an IP address.¶

These requirements are concerned with the standards specification process and not the implementation of specified standards. All requirements in this document must be reflected by standards specifications to be developed. However, which of the features specified by these standards will be mandatory, recommended, or optional for compliant implementations is to be defined by Standards Track document(s) and not in this document.¶

2.1. Incremental Application of the GREEN Framework

This section describes an incremental example [legacy-path] of usage showing how a product, a service and a network can use the framework in different settings.¶

This use case is the less trendy of all the use cases by far as its ambitious is limited to migration and coexistence, as usual. Nevertheless from a telco perspective, it is the centrality for 2 main reasons:¶

• to start immediatly the move to energy efficiency using legacy devices;¶

• to account the gain of the move one started;¶

Once upon a time there was an very old legacy router named Rusty equipped with outdated ethernet and ugly optical interfaces. Despite his worn-out appearance, Rusty was determined to contribute to the energy efficiency effort. He dreamed of finding a way to optimize his old circuits and help reduce the power consumption of the network he had faithfully served for so many years. Though he was no longer in his prime, Rusty believed that even an old router like him could make a difference in a world striving for sustainability and help reduce the carbon footprint. He is convince that he still had a part to play in making the digital world a greener place.¶

Device moving gradually to GREEN energy efficiency support:¶

• step 1 "baseline" : establishing a reference point of typical energy usage, which is crucial for identifying inefficiencies and measuring improvements over time. At this step the controler use only the (c) part of the framework. It is collected from the datasheet.¶

By establishing a baseline and using benchmarking, you can determine if your networking equipment is performing normally or if it is "off" from expected performance, guiding you in making necessary improvements.¶

The initial measurement of your networking equipment's energy efficiency and performance, aka Baselining, needs to be in coordination with the vendor specifications and industry standards to understand what is considered normal or optimal performance. example: Baseline: Your switches operate at 5 Gbps per watt. Benchmarking: Vendor specification is 8 Gbps per watt; industry standard is 10 Gbps per watt. Action: Implement energy-saving measures and upgrades. Tracking: Measure again to see if efficiency improves towards 8-10 Gbps per watt.¶

• step 2 "component": part of the device hw or sw migrated to support GREEN framework elements.¶

• step 3 "device controleur"¶

• step 4 "network level"¶

For this use case, the following requirements apply :¶

(i) Avoid a power-on/power-off frequency to break component parts (aka laser, power parts, wire connectors ...)¶

(ii) the gain must be measurable¶

(iii) network-wide energy efficiency solutions must include legacy devices and green-wg ready devices¶

2.2. Selective reduction of energy consumption in network parts proportional to traffic levels

Traffic levels in a network follow patterns reflecting the behavior of consumers. Those patterns show periodicity in the terms of the traffic delivered, that can range from daily (from 00:00 to 23:59) to seasonal (e.g., winter to summer), showing peaks and valleys that could be exploited to reduce the consumption of energy in the network proportionally, in case the underlying network elements incorporate such capabilities. The reduction of energy consumption could be performed by leveraging on sleep modes in components up to more extreme actions such as switching off network components or modules. Such decisions are expected to no impact on the service delivered to customers, and could be accompanied by traffic relocation and / or concentration in the network. For this use case, the following requirements apply:¶

2.3. Reporting on Lifecycle Management

Lifecycle information related to manufacturing energy costs, transport, recyclability, and end-of-life disposal impacts is part of what is called "embedded carbon." This information is considered to be an estimated value, which might not be implemented today in the network devices. It might be part of the vendor information, and to be collected from datasheets or databases. In accordance with ISO 14040/44, this information should be considered as part of the sustainable strategy related to energy efficiency. Also, refer to the ecodesign framework [(EU) 2024/1781] published in June by the European Commission.¶

2.4. Real-time Energy Metering of Virtualised or Cloud-native Network Functions

Facilitating more precise and real-time estimations of energy consumed by virtualised or cloud-native network functions.¶

Effective metering of virtualized network infrastructure is critical for the efficient management and operation of next-generation mobile networks [GREEN_NGNM].¶

2.5. Indirect Energy Monitoring and control

While the conventional requirements summarized above seem to be all that would be needed for Energy Management, there are significant differences between Energy Management and most well-known network management functions. The most significant difference is the need for some devices to report on other entities. There are two major reasons for this.¶

o For monitoring a particular entity, it is not always sufficient to communicate only with that entity. When the entity has no instrumentation for determining power, it might still be possible to obtain power values for the entity via communication with other entities in its power distribution tree. A simple example of this would be the retrieval of power values from a power meter at the power line into the entity. A Power Distribution Unit (PDU) and a Power over Ethernet (PoE) switch are common examples. Both supply power to other entities at sockets or ports, respectively, and are often instrumented to measure power per socket or port. Also it could be considered to obtain power values for the entity via communication with other entities outside of the power distribution tree, like for example external databases or even data sheets.¶

o Similar considerations apply to controlling the power supply of an entity that often needs direct or indirect communications with another entity upstream in the power distribution tree. Again, a PDU and a PoE switch are common examples, if they have the capability to switch power on or off at their sockets or ports, respectively.¶

These specific issues of Energy Management, as well as other issues, are covered by requirements specified in Sections 7 and 8.¶

The requirements in these sections need a new Energy Management framework that deals with the specific nature of Energy Management. The actual standards documents, such as MIB module specifications, address conformance by specifying which features must, should, or may be implemented by compliant implementations.¶

2.6. Consideration of other domains for obtention of end-to-end metrics

The technologies under the scope of IETF provide the necessary connectivity to other technological domains. For the obtention of metrics end-to-end it would be required to combine or compose the metrics per each of those domains.¶

An exemplary case is the one of a network slice service. The concept of network slice was initially defined by 3GPP [TS23.501], and it has been further extended to the concerns of IETF [RFC9543].¶

In regards energy efficiency, 3GPP defines a number of energy-related key performance indicators (KPI) in [TS28.554], specifically Energy Efficiency (EE) and Energy Consumption (EC) KPIs. There are KPIs particular for a slice supporting a specific kind of service (e.g., Mobile Broadband or MBB), or generic ones, like Generic Network Slice EE or Network Slice EC. Assuming these as the KPIs of interest, the motivation of this use case is the obtention of the equivalent KPIs at IETF level, that is, for the network slice service as defined in [RFC9543].¶

Note that according to [TS28.554], the Generic Network Slice EE is the performance of the network slice divided by the Network Slice EC. Same approach can be followed at IETF level. Note that for avoiding double counting the energy at IETF level in the calculation of the end-to-end metric, the 3GPP metric should only consider the efficiency and consumption of the 3GPP-related technologies.¶

2.7. Dynamic adjustment of network element throughput according to traffic levels in wireless transport networks

Radio base stations are typically connected to the backbone network by means of fiber or wireless transport (e.g., microwave) technologies. In the specific case of wireless transport, automation frameworks have been defined [ONF-MW][RFC8432][mWT025] for their control and management.¶

One of the parameters subject of automated control is the power of the radio links. The relevance of that capability is that the power can be adjusted accordingly to the traffic observed. Wireless transport networks are typically planned to support the maximum traffic capacity in their area of aggregation, that is, the traffic peak. With that input, the number of radio links in the network element and the corresponding power per radio link (for supporting a given modulation and link length in the worst weather conditions) are configured. This is done to avoid any kind of traffic loss in the worst operational situation. However, such operational needs are sporadic, giving room for optimization during normal operational circumstances and/or low traffic periods.¶

Power-related parameters are for instance defined in [RFC8561]. Those power parameters can be dynamically configured to adjust the power to the observed traffic levels with some coarse granularity, but pursuing certain degrees of proportionality.¶

2.8. Video streaming use case

Video streaming is nowadays the major source of traffic observed in ISP networks, in a propotion of 70% or even higher. Over-the-top distribution of streaming traffic is typically done by delivering a unicast flow per end user for the content of its interest.In consequence, during the hours of higher demand, the total traffic in the network is proportional to the concurrence of users consuming the video streaming service. The amount of traffic is also dependent of the resolution of the encoded video (the higher the resolution, the higher the bit rate per video flow), which tends to be higher as long as the users devices support such higher resolutions.¶

The consequence of both the growth in the number of flows to be supported simultaneously, and the higher bit rate per flow, is that the nework elements in the path between the source of the video and the user have to be dimensioned accordingly. This implies the continuous upgrade of those network elements in terms of capacity, with the need of deploying high-capacity network elements and components. Apart from the fact that this process is shortening the lifetime of network elements, the need of high capacity interfaces also increase the energy consumption (despite the effort of manufacturers in creating more efficient network element platforms). Note that nowadays there is no actual possibility of activating energy consumption proportionality (in regards the delivered traffic) to such network elements.¶

As a mean of slowing down this cycle of continuos renewal, and reduce the need og higher bit rate interfaces / line cards, it seems convenient to explore mechanisms that could reduce the volume of traffic without impacting the user service expectations. Variants of multicast or different service delivery strategies can help to improve the energy efficiency associated to the video streaming service. It should be noted that another front for optimization is the one related to the deployment of cache servers in the network.¶

4.1. Conventional Requirements for Energy Efficiency Management

The specification of requirements for an Energy Efficiency Management standard starts with Section 4.3, which addresses the identification of entities and the granularity of reporting of energy-related information. A standard must support the unique identification of entities, reporting per network, per entire device, and reporting energy-related information on individual components of a device or attached devices.¶

Section 4.4 specifies requirements related to the monitoring of entities. This includes general (type, context) information and specific information on Power States, Power Inlets, Power Outlets, power, energy. The control of Power State and power saving functionalities, optimization functionalities by entities is covered by requirements specified in Section 5.6.¶

4.2. General Considerations Related to Energy Management

The basic objective of Energy Efficiency Management is to operate sets of network devices using minimal energy, while maintaining a certain level of service.¶

4.3. Identification of Entities

Entities must be capable of being uniquely identified within the context of the management system. This includes entities that are components of managed devices as well as entire devices or the entire network.¶

Entities that report on or control other entities must identify the entities they report on or control: see Section 7 or Section 8, respectively, for the detailed requirements.¶

An entity may be an entire network, or network device or a component of it. Examples of components of interest are a hard drive, a fan, or a line card. The ability to control individual components to save energy may be required. For example, server blades can be switched off when the overall load is low, or line cards at switches may be powered down at night.¶

Identifiers for network, network devices and components are already defined in standard YANG modules Network Topology YANG module [RFC8345] and Hardware YANG module [RFC8348]. Note that Network Topology YANG module [RFC8345] identifiers are reused in the Network Inventory YANG module [I-D.ietf-ivy-network-inventory-yang] and are also the basis for the Digital Map Modeling efforts in the NMOP Working Group.¶

Instrumentation for measuring the received and provided energy of a device is typically more expensive than instrumentation for retrieving its Power State. Many devices may provide Power State information for all individual components separately, while reporting the received and provided energy only for the entire device.¶

4.4. Information on Entities

This section describes information on entities for which the standard must provide means for retrieving and reporting.¶

Required information can be structured into seven groups. Section 5.1 specifies requirements for general information on entities, such as type of entity or context information. Requirements for information on Power Inlets and Power Outlets of entities are specified in Section 5.2. The monitoring of power and energy is covered by Sections 5.3 and 5.5, respectively. Section 5.4 covers requirements related to entities' Power States. Finally, the reporting of time series of values is covered by Section 5.7.¶

4.5. Control of Entities

Many entities control their Power State locally. Other entities need interfaces for an Energy Management System to control their Power State.¶

A power supply is typically not self-managed by devices, and control of a power supply is typically not conducted as an interaction between an Energy Management System and the device itself. It is rather an interaction between the management system and a device providing power at its Power Outlets. Similar to Power State control, power supply control may be policy driven. Note that shutting down the power supply abruptly may have severe consequences for the device.¶

4.6. Management of oultet Entities

As discussed in Section 5, not all energy-related information may be available at the entity in question. Such information may be provided by other entities. This section groups the requirements for the discovery, the reporting and the control of information.¶

The intend is to summarize them in a table in section 9.¶

6.1. Secure Energy Management

The standard must provide privacy, integrity, and authentication mechanisms for all actions addressed in Sections 5 through 8. The security mechanisms must meet the security requirements detailed in Section 1.4 of [RFC3411].¶

6.2. Isolation of Insufficiently Secure Entities

The standard must provide means to allow the isolation of entities that are not sufficiently secure to operate on the public Internet, e.g., behind a gateway that implements sufficient security that the vulnerable entities are not directly exposed to the Internet.¶

6.3. Optional Restriction of Functions

The standard must allow compliant implementations to disable sensitive functions, or to not implement such functions at all, when operating in environments that are not sufficiently secured. This applies particularly to the control functions described in Sections 6 and 8.¶

6.4. Other Aspects

Adding new interfaces on devices increase attack surfaces. Devices have brief variation of power consumption due their internal works. Reducing the power available may reduce their routing capacity which may reduce network performance and resiliency.¶

9.1. Open Issues to be Discussed at IETF121

o Consider 5g vs network slicing: 3GPP spec describong energy efficiency KPIs. 3GPP TS 28.554. Reference:https://datatracker.ietf.org/doc/rfc9543/ o POE use case: open issue section? o Reduce traffic (video streaming) o Connectivity from radio side (trying to control the traffic/related work to CCAMP) o Marisol to add one use case: drift from data specifications... (somehow link to the above) o Use case per Domain specific? Meanwhile, they are considered as part of the network... Servers might be considered outside of scope o Energy Metric in E2E view¶

9.2. Open Issues collected since the BoF

o Power and Energy Monitoring and Control MIB modules has not been converted yet into YANG modules. Based on their deployements status, discuss their reuse and their mapping in Yang for energy monitoring¶

o Do we need to keep a reference to the MIB object entPhysicalUUID (in section 4.4 from ENTITY-MIB v4) in case of legacy device (MIB)?¶

o The EMAN requirements and EMAN framework had a lot of emphasis on the "Reporting on Other Entities", typically smart PDU or PoE. Is this important? Should this be removed? Should it be addressed in a future charter? This is text about "Sections 7 and 8 contain requirements specific to Energy Management. Due to the nature of power supply, some monitoring and control functions are not conducted by interacting with the entity of interest but rather with other entities, for example, entities upstream in a power distribution tree."¶

Expressed differently: Out of scope for the short term approach of EMAN framework enhancements, but might be good to call it out, EMAN doesn't include mechanisms for integrating occupancy sensors or user behavior analytics, which can be critical for optimizing HVAC, lighting, and other systems for energy efficiency. This is a key aspect for Smart Buildings and Data Centers energy efficiency metrics.¶

o It's not clear whether we need new Power State (Set)? Maybe not but we need to explain the mapping of existing energy efficient features to specific Power States.¶

o basic (scalar) units are not enough to describe Power Data Unit capabilities and/or output. We need a more complex structure (which might already exist?) to cover and combine meanings (that I copied from the chats) like CO2 footprint, clean energy, mix, renewable. as an example, this should help to describe reduction of energy consumption and the increase of renewable energy consumption¶

o Enhance EMAN framework, to support a more robust and comprehensive Energy Efficiency Strategy. Let devices report whatever they can using existing interfaces, without waiting until they implement new capabilities determined by new or existing standards. Including the capability to integrate with external data sources (for example, for devices that don't have the capability or reporting any energy-related metrics) such as vendor datasheets that provide energy consumption. Use case => upgrading a device for better Energy Efficiency Management. Not sure whether framework-related requirements should be covered here.¶

o Leveraging existing devices modularity to introduce eco-designed components in the networks while being able to assess the gains in sustainability. https://datatracker.ietf.org/doc/html/draft-stephan-legacy-path-eco-design-01 https://github.com/emile22/sustainability¶

o Discuss the need to reflect component on/off frequency capacity (in YANG) to avoid too intensive power on/off.¶

o Discuss the need to support a description of the different nature of the sources of the energy used (mix). It should be flexible are the types of sources might augment in the future.¶

o Company's SBTi approved decarbonization plan and how to link it to GREEN WG scope, short/mid vs long term.¶

The Science Based Targets initiative(SBTi)[https://sciencebasedtargets.org] defines and promotes best practice in science-based target setting. Offering a range of target-setting resources and guidance, the SBTi independently assesses and approves companies targets in line with its strict criteria.¶

Open issue, https://github.com/marisolpalmero/GREEN-bof/issues/88¶

o Consideration to include in scope, allocate/compute and report the energy spent on behalf of a particular customer/user. Open issue, marisolpalmero/GREEN-bof#89¶

10.1. Normative References

[IEC.61850-7-4] International Electrotechnical Commission, "Communication networks and systems for power utility automation -- Part 7-4: Basic communication structure -- Compatible logical node classes and data object classes", March 2010.¶

[IEC.62053-21] International Electrotechnical Commission, "Electricity metering equipment (a.c.) -- Particular requirements -- Part 21: Static meters for active energy (classes 1 and 2)", January 2003.¶

[IEC.62053-22] International Electrotechnical Commission, "Electricity metering equipment (a.c.) -- Particular requirements -- Part 22: Static meters for active energy (classes 0,2 S and 0,5 S)", January 2003.¶

[IEEE-100] IEEE, "The Authoritative Dictionary of IEEE Standards Terms, IEEE 100, Seventh Edition", December 2000.¶

[IEEE-1621] Institute of Electrical and Electronics Engineers, "IEEE 1621-2004 - IEEE Standard for User Interface Elements in Power Control of Electronic Devices Employed in Office/Consumer Environments", 2004.¶

[ATIS-0600015.03.2013] ATIS, "ATIS-0600015.03.2013: Energy Efficiency for Telecommunication Equipment: Methodology for Measurement and Reporting for Router and Ethernet Switch Products", 2013.¶

[ETSI-ES-203-136] ETSI, "ETSI ES 203 136: Environmental Engineering (EE); Measurement methods for energy efficiency of router and switch equipment", 2017, <https://www.etsi.org/deliver/ etsi_es/203100_203199/203136/01.02.00_50/ es_203136v010200m.pdf>.¶

[ITUT-L.1310] ITU-T, "L.1310 : Energy efficiency metrics and measurement methods for telecommunication equipment", 2020, https://www.itu.int/rec/T-REC-L.1310/en.¶

10.2. Informative References

[IEC.60050] International Electrotechnical Commission, "Electropedia: The World's Online Electrotechnical Vocabulary", 2013, http://www.electropedia.org/iev/iev.nsf/ welcome?openform.¶

[ITU-M.3400] International Telecommunication Union, "ITU-T Recommendation M.3400 -- Series M: TMN and Network Maintenance: International Transmission Systems, Telephone Circuits, Telegraphy, Facsimile and Leased Circuits -- Telecommunications Management Network - TMN management functions", February 2000.¶

11.1. Terminology

This section is excepted to move in the GREEN WG draft in charge of terms. The terms below are a sub set of the whole terminology. There are many other drafts giving additionnal definitions.¶

The terms specified in the terminology section are capitalized throughout the document; the exceptions are the well-known terms "energy" and "power". These terms are generic and are used in generated terms such as "energy-saving", "low-power", etc.¶

Embedded carbon (or embodied carbon)¶

  The total amount of greenhouse gas emissions, measured in tonnes
  of CO2 equivalent (tCO2e), associated with the entire lifecycle
  of a product or material, from raw material extraction through
  manufacturing, transportation, use, and end-of-life disposal or
  recycling.

Embodied energy¶

  The total amount of energy consumed in all processes associated
  with the production of a building material or product, from the
  extraction and processing of raw materials, through manufacturing,
  transportation, and installation, to the end of its useful life,
  including disposal or recycling.

Energy¶

  Energy is the capacity of a system to do work.  As used by
  electric utilities, it is generally a reference to electrical
  energy and is measured in kilowatt-hours (kWh) [IEEE-100].

Power¶

  Power is the time rate at which energy is emitted, transferred, or
  received; power is usually expressed in watts (or in joules per
  second) [IEEE-100].  (The term "power" does not refer to the
  concept of demand, which is an averaged power value.)

Power Attributes¶

  Power Attributes are measurements of electric current, voltage,
  phase, and frequencies at a given point in an electrical power
  system (adapted from [IEC.60050]).

  NOTE: Power Attributes are not intended to be "judgmental" with
  respect to a reference or technical value and are independent of
  any usage context.

Energy Management¶

  Energy Management is a set of functions for measuring, modeling,
  planning, and optimizing networks to ensure that the network
  elements and attached devices use energy efficiently and in a
  manner appropriate to the nature of the application and the cost
  constraints of the organization [ITU-M.3400].

Energy Efficiency Management¶

 Involves deploying and managing network infrastructures with the
 goal of optimizing energy use on network devices while improving
 the overall network utilization.

Energy Management System¶

  An Energy Management System is a combination of hardware and
  software used to administer a network with the primary purpose
  being Energy Management.

Energy Monitoring¶

  Energy Monitoring is a part of Energy Efficiency Management that deals
  with collecting or reading information from network elements and their
  components to aid in Energy Efficiency Management.

Energy Control¶

  Energy Control is a part of Energy Management that deals with
  controlling energy supply and Power State of network elements, as
  well as their components.

Power Interface¶

  A Power Interface is an interface at which a device is connected
  to a power transmission medium, at which it can in turn receive
  power, provide power, or both.

Power Inlet¶

  A Power Inlet is a Power Interface at which a device can receive
  power from other devices.

Power Outlet¶

  A Power Outlet is a Power Interface at which a device can provide
  power to other devices.

Power State¶

  A Power State is a condition or mode of a device that broadly
  characterizes its capabilities, power consumption, and
  responsiveness to input [IEEE-1621].

11.2. In Preparation of the GREEN BoF at IETF 120

The EMAN (Energy MANagement) working group (WG), created in 2010 and now concluded, has produced multiples RFCs¶

  * RFC7603, Energy Management (EMAN) Applicability Statement

  * RFC7577, Definition of Managed Objects for Battery Monitoring

  * RFC7460, Monitoring and Control MIB for Power and Energy

  * RFC7461, Energy Object Context MIB

  * RFC7326, Energy Management Framework

  * RFC6988, Requirements for Energy Management

  * RFC6933, Entity MIB (Version 4)

Note also that some other energy-related MIB modules have been created, but not by the EMAN Working Group¶

  * RFC3433, Entity Sensor MIB module

  * RFC3621, Power Ethernet MIB modules

  * RFC1628, UPS Power Monitoring MIB module

  * LLDP MIB module and LLDP MED MIB module

Due to limitations regarding Writeable MIB module, one IESG statement published in 2014 encourages the use the NETCONF/YANG standards for configuration. Based on the YANG modules developments, three MIB modules (Entity MIB module, Entity Sensor MIB module, Entity State MIB module) have been converted into the "YANG Data Model for Hardware Management" RFC8348.¶

However, Power and Energy Monitoring and Control MIB modules has not been converted yet into YANG modules.¶

Eleven years after the EMAN requirements RFC 6988 publication, this document re-evaluates the energy-related requirements, as a preparation for the GREEN BoF at IETF 120.¶

11.3. High-level Differences with RFC6988

The following section will delve into the specific details but from a high level point of view, the differences between this document and the RFC6988 are:¶

• New definition for "Energy Efficiency Management"¶

• A focus towards YANG, and not any longer on MIB modules¶

• As a consequence from the previous point, the ENTITY-MIB v4 RFC6933 is replaced by the Hardware YANG module RFC8348¶

• battery management is removed (as batteries haves some self-optimization features these days). Nevertheless 'Battery' will appear as a source of power of a type of backup¶

• Less focus on the Power over Ethernet management, Nevertheless Reporting on Other Entities remains an open issue¶

• A focus on reporting lifecycle management, considering energy and transformation towards carbon awareness¶