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.¶

Section 3 elaborates on a set of general needs for Energy Management. Requirements for an Energy Management standard are specified in Sections 4 through 8.¶

Sections 4 through 6 contain conventional requirements specifying information on entities and control functions.¶

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.¶

1.2. Conventional Requirements for Energy Efficiency Management

The specification of requirements for an Energy Efficiency Management standard starts with Section 4, 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 5 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 6.¶

1.3. Specific Requirements for Energy Management

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.¶

3.1. Power States

Entities can be set to an operational state that results in the lowest power level that still meets the service-level performance objectives. In principle, there are three basic types of Power States for an entity or for a whole system:¶

o full Power State¶

o sleep state (not functional but immediately available)¶

o off state (may require significant time to become operational)¶

In specific network devices, the number of Power States and their properties vary considerably. Simple entities may only have the extreme states: full Power State and off state. Many network devices have three basic Power States: on, off, and sleep. However, more finely grained Power States can be implemented, especially when Energy efficiency gains for communication systems are highly sought after, for environmental, business, and technical reasons. Examples are various operational low Power States in which a network device requires less energy than in the full power "on" state, but -- compared to the sleep state -- is still operational with reduced performance or functionality.¶

Another example is standby power state in which network device has multiple standby components and one active component for the same functionality, standby components are partially functional and can be immediately available when active component is down. The standby power state can be introduced to save energy while impove the overall network utilization.¶

3.2. Saving Energy versus Maintaining Service Level

One of the objectives of Energy Efficiency Management is to reduce energy consumption. While this objective is clear, attaining that goal is often difficult. In many cases, there is no way to reduce power without the consequence of a potential service (performance or capacity) degradation. In this case, a trade-off needs to be made between service-level objectives (e.g., network performance) and energy minimization. In other cases, a reduction of power can easily be achieved while still maintaining sufficient service-level performance, for example, by switching entities to lower Power States when higher performance is not needed. To measure of the trade-off between service-level object and energy consumption, a new set of energy efficiency metrics needs to defined.¶

3.3. Local versus Network-Wide Energy Management

Many energy-saving functions are executed locally by an entity; it monitors its usage and dynamically adapts its power according to the required performance. It may, for example, switch to a sleep state or backup state when it is not in use, or outside of scheduled business hours. An Energy Efficiency Management System may observe an entity's Power State and configure or optimize its power-saving policies.¶

Energy savings can also be achieved with policies implemented by a network management system that controls Power States of managed entities. Information about the power received and provided by entities in different Power States may be required in order to set such policies. Often, this information is best acquired through monitoring.¶

Network-wide and local Energy Management methods both have advantages and disadvantages, and it is often desirable to combine them. Central management is often favorable for setting Power States of a large number of entities at the same time, for example, at the beginning and end of business hours in a building. Local management is often preferable for power-saving measures based on local observations, such as the high or low functional load of an entity.¶

3.4. Energy Monitoring versus Energy Saving

Monitoring energy, power, and Power States alone does not reduce the energy needed to run an entity. In fact, it may even increase it slightly due to monitoring instrumentation that needs energy. Reporting measured quantities over the network may also increase energy use, though the acquired information may be an essential input to control loops that save energy.¶

Monitoring energy and Power States can also be required for other purposes, including:¶

o investigating energy-saving potential¶

o evaluating the effectiveness of energy-saving policies and measures¶

o deriving, implementing, and testing power management strategies¶

o accounting for the total power received and provided by an entity, a network, or a service¶

o predicting an entity's reliability based on power usage¶

o choosing the time of the next maintenance cycle for an entity¶

3.5. Overview of Energy Management Requirements

The following basic management functions are required:¶

o monitoring Power States¶

o monitoring power (energy conversion rate)¶

o monitoring (accumulated) received and provided energy¶

o monitoring Power Attributes¶

o setting Power States¶

In addition, to support energy efficiency management, additional requirements concerned with discovery functions and control functions are introduced:¶

o discovering energy-managed network, devices and their components¶

o discovering inventory of power components together with their capabilities, optimization control capabilities, nominal condition use¶

o discovering supported power state of each network device within the network¶

o discovering power relationship between component within network device and across network devices.¶

o support additional energy efficiency metrics for energy efficiency monitoring, e.g., heat consumption, energy efficiency ratio, maximum wake up time, etc.¶

o support separation of desired power state and actual power state and optimize energy usage to allow update actual power state to match desired power state.¶

o Introduce energy saving method, and energy efficiency metrics to support explicit power control or energy efficiency optimization and control.¶

o allow control and optimize energy usage to make the trade-off between network performance and power consumption.¶

o support both local management and network wide management based on energy saving functionality.¶

Energy usage control and optimization is complementary to other energy-saving design, such as low-power electronics, energy-efficient device design (for example, low-power modes for components), and energy-efficient network architectures and is exercised using management interface. Measurement of received and provided energy can provide useful data for energy efficiency management.¶

4.1. Identifying Entities

The standard must provide means for uniquely identifying entities. Uniqueness must be preserved such that collisions of identities are avoided at potential receivers of monitored information.¶

4.2. Identifying Entitiy Capabilities

The standard must provide means for discovering inventory of power components together with their capabilities, optimization control capabilities, nominal condition use. In addition, The standard must provide means for discovering supported power state of each network device within the network and power relationship between component within network device and across network devices.¶

4.3. Persistence of Identifiers

The standard must provide means for indicating whether identifiers of entities are persistent across a restart of the entity.¶

4.4. Change of Identifiers

The standard must provide means to indicate any change of entity identifiers.¶

4.5. Using Entity Identifiers of Existing YANG Modules

The standard must provide means for reusing entity identifiers from existing standards, including at least the following:¶

o the network-id, link-id, node-id, port-id of the Network Topology YANG module [RFC8345]¶

o the ne-id, Universal Unique IDentifier (UUID) of the network element and component-id, UUID of each component within the network element in Network Inventory YANG module [I-D.ietf-ivy-network-inventory-yang]¶

o the name, UUID of each hardware component in the Hardware YANG module [RFC8348]¶

Generic means for reusing other entity identifiers must be provided.¶

5.1. General Information on Entities

For Energy Management, understanding the role and context of an entity may be required. An Energy Management System may aggregate values of received and provided energy according to a defined grouping of entities. When controlling and setting Power States, it may be helpful to understand the grouping of the entity and role of an entity in a network. For example, it may be important to exclude some mission-critical network devices from being switched to lower power or even from being switched off.¶

5.2. Power Interfaces

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.¶

A Power Interface is either an inlet or an outlet. Some Power Interfaces change over time from being an inlet to being an outlet and vice versa. However, most Power Interfaces never change.¶

Network Devices have Power Inlets at which they are supplied with electric power. Most devices have a single Power Inlet, while some have multiple inlets. Different Power Inlets on a device are often connected to separate power distribution trees. For Energy Monitoring, it is useful to retrieve information on the number of inlets of a device, the availability of power at inlets, and which inlets are actually in use.¶

Network Devices can have one or more Power Outlets for supplying other devices with electric power.¶

For identifying and potentially controlling the source of power received at an inlet, identifying the Power Outlet of another network device at which the received power is provided may be required. Analogously, for each outlet, it is of interest to identify the Power Inlets that receive the power provided at a certain outlet. Such information is also required for constructing the wiring topology of electrical power distribution to devices.¶

Static properties of each Power Interface are required information for Energy Efficiency Management. Static properties include the kind of electric current (AC or DC), the nominal voltage, the nominal AC frequency, and the number of AC phases. Note that the nominal voltage is often not a single value but a voltage range, such as, for example, (100V-120V), (100V-240V), (100V-120V,220V-240V).¶

5.3. Power

Power is measured as an instantaneous value or as the average over a time interval.¶

Obtaining highly accurate values for power and energy may be costly if dedicated metering hardware is required. Entities without the ability to measure with high accuracy their power, received energy, and provided energy may just report estimated values, for example, based on load monitoring, Power State, or even just the entity type.¶

Depending on how power and energy values are obtained, the confidence in a reported value and its accuracy will vary. Entities reporting such values should qualify the confidence in the reported values and quantify the accuracy of measurements. For reporting accuracy, the accuracy classes specified in IEC 62053-21 [IEC.62053-21] and IEC 62053-22 [IEC.62053-22] should be considered.¶

Further properties of the power supplied to a device are also of interest. For AC power supply in particular, several Power Attributes beyond the real power are of potential interest to Energy Management Systems. The set of these properties includes the complex Power Attributes (apparent power, reactive power, and phase angle of the current or power factor) as well as the actual voltage, the actual AC frequency, the Total Harmonic Distortion (THD) of voltage and current, and the impedance of an AC phase or of the DC supply. A new standard for monitoring these Power Attributes should be in line with already-existing standards, such as [IEC.61850-7-4].¶

For some network management tasks, it is desirable to receive notifications from entities when their power value exceeds or falls below given thresholds.¶

5.4. Power State

Many entities have a limited number of discrete Power States.¶

There is a need to report the actual Power State of an entity and to provide the means for retrieving the list of all supported Power States.¶

Different standards bodies have already defined sets of Power States for some entities, and others are creating new Power State sets. In this context, it is desirable that the standard support many of these Power State standards. In order to support multiple management systems that possibly use different Power State sets while simultaneously interfacing with a particular entity, the Energy Management System must provide means for supporting multiple Power State sets used simultaneously at an entity.¶

Power States have parameters that describe their properties. It is required to have a standardized means for reporting some key properties, such as the typical power of an entity in a certain state.¶

There is also a need to report statistics on Power States, including the time spent as well as the received and provided energy in a Power State.¶

5.5. Energy

The monitoring of electrical energy received or provided by an entity is a core function of Energy Management. Since energy is an accumulated quantity, it is always reported for a certain interval of time. This can be, for example, the time from the last restart of the entity to the reporting time, the time from another past event to the reporting time, the last given amount of time before the reporting time, or a certain interval specified by two timestamps in the past.¶

It is useful for entities to record their received and provided energy per Power State and report these quantities.¶

In addition, it is also useful for entities to record energy attributes such as maximum wake up time, maximum sleep time, service interruption time, transition time, maximum packet throughput, maximum bit throughput and report these quantities.¶

5.6. Time Series of Measured Values

For some network management tasks, obtaining time series of measured values from entities, such as power, energy, etc., is required.¶

In general, time series measurements could be obtained in many different ways. Means should be provided to either push such values from the location where they are available to the management system or to have them stored locally for a sufficiently long period of time such that a management system can retrieve the full time series.¶

The following issues are to be considered when designing time series measurement and reporting functions:¶

1. Which quantities should be reported?¶

2. Which time interval type should be used (total, delta, sliding window)?¶

3. Which measurement method should be used (sampled, continuous)?¶

4. Which reporting model should be used (push or pull)?¶

The most discussed and probably most needed quantity is energy. But a need for others, such as power, can be identified as well.¶

There are three time interval types under discussion for accumulated quantities such as energy. They can be reported as total values, accumulated between the last restart of the measurement and a certain timestamp. Alternatively, energy can be reported as delta values between two consecutive timestamps. Another alternative is reporting values for sliding windows as specified in [IEC.61850-7-4].¶

For non-accumulative quantities, such as power, different measurement methods are considered. Such quantities can be reported using values sampled at certain timestamps or, alternatively, by mean values for these quantities averaged between two (consecutive) timestamps or over a sliding window.¶

Finally, time series can be reported using different reporting models, particularly push-based or pull-based. Push-based reporting can, for example, be realized by reporting power or energy values using the NETCONF protocol [RFC6241]. The NETCONF a protocol can also be used to realize pull-based reporting of time series.¶

For reporting time series of measured values, the following requirements have been identified. Further decisions concerning issues discussed above need to be made when developing concrete Energy Management standards.¶

6.1. Carbon Reporting

To report on carbon equivalents for global reporting, it is important to correlate the location where the specific entity/network element is operating with the corresponding carbon factor. Refer to the world emission factor from the International Energy Agency (IEA), electricity maps applications that reflect the carbon intensity of the electricity consumed, etc.¶

6.2. Energy Mix

Energy efficiency is not limited to reducing the energy consumption, it is common to include carbon free, solar energy, wind energy, cogeneration in the efficiency. The type of the sources of energy of the power is one criteria of efficiency. There are other dimensions that must visible: As many telecom locations include battery there is a requirement to known that the source come from a battery or directly from the grid...¶

7.1. Provisioning Power States

The standard must provide means for provisioning Power States of entities.¶

When an Energy Object is set to a particular Power State, the represented device or component may be busy. The Energy Object should set the desired Power State and then update the actual Power State when the device or component changes. The standard must provide means to report the intented and applied Power States, with the Network Management Datastore Architecture (NMDA) [RFC8342]¶

7.2. Controlling Power SupplyProvisioning

The standard must provide means for switching a power supply off or turning a power supply on at Power Interfaces providing power to one or more devices.¶

7.3. Controlling Energy Saving and Optimization Functionalities

The standard must provide means for controlling energy saving and optimization functionalities and allocating the committed component resource (e.g., adjust fan speed, shutdown high speed interface) or committed device resource (e.g., multiple cards scheduling, multiple power module scheduling).¶

In addition, the standard must provide means to support both local management and network wide management based on energy saving functionality.¶

8.1. Discovery of Power inlet Entities

Energy consumption must not be accounted twice¶

8.2. Controlling Other Entities

This section specifies requirements for controlling Power States and power supply of entities by communicating with other entities that have the means for doing that control.¶

9.1. Operator'requirements from [charter-refinement] document

The table below is a copy of the operator'requirements table of [charter-refinement]. They are based on the inputs received from operators for the GREEN BoF [operators-inputs].¶

9.2. Requirements extracted from [legacy-path]

(i) Avoid control to break the component¶

(ii) the gain must be measurable¶

(iii) network-wide solution must include legacy devices and green-wg ready devices¶

9.3. Requirements from [rfc6988bis-green] draft Open Issues

9.4. Requirements extracted from [sustainability-insights] uses cases

There are limited to energy consumption vs sustainability¶

9.5. Framework Discussed During the BoF

The overall framework is shown in Figure 1.¶

       What needs to be standardized for Framework


(3) Network Domain Level :

(a)              (b)              (c)
Inventory        Monitor       +- DataSheets/DataBase and/or via API
Of identity      Energy        |  Metadata and other device/component
and Capability   Efficiency    |  /network related information:
     ^               ^         |
     |               |         |  .Power/Energy related metrics
     |               |         |  .information
     |               |         |  .origin of Energy Mix
     |               |         |  .carbon aware based on location
     |               |         |
     |               |         |
     |               |         |
     |               |         v
+--------------------------------------------------------------------+
|                   *                                                |
|     (2) controller   (collection, compute and aggregate?)          |
|                                                                    |
+--------------------------------------------------------------------+
             ^              ^                   ^ |
  (d)        |  (e)         |  (f)              | |(g)
  Inventory  |  Monitor     |  GREEN WG:        | |GREEN WG: Control
  Capability |  Traffic     |  Monitor power    | |(Energy saving
             |  & power     |  Proportion,      | |Functionality
             |  consumption |  Energy efficiency| |Localized mgmt/
             |              |  ratio, etc)      | |network wide mgmt)
             |              |                   | |
             |              |                   | |
             |              |                   | v
+--------------------------------------------------------------------+
|                                            *                       |
|                  (1) Device/Component Level                        |
|                                                                    |
| +---------+  +-----------+  +----------------+  +----------------+ |
| | (I)     |  | (II)      |  | (III)          |  | (IV)           | |
| | Network |  | Device    |  | Legacy Network |  | 'Attached'(PoE | |
| | Device  |  | Component |  | Device         |  | kind) Device   | |
| |         |  |           |  |                |  |                | |
| +---------+  +-----------+  +----------------+  +----------------+ |
+--------------------------------------------------------------------+

(*) Energy Efficiency Management Function is implemented inside the
device or in a controller

The main elements in the framework are as follows:¶

(a),(d) Inventory¶

(b),(c) GREEN Metrics¶

(b),(f) Monitor energy efficiency¶

(e) Monitor power consumption and traffic (IPPM WG throughput, traffic load, etc)¶

(g) Control Energy Saving¶

10.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].¶

10.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.¶

10.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.¶

15.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.¶

15.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.¶

16.1. 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.¶

16.2. 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)¶

• Less focus on the Power over Ethernet management¶

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