Network Working Group J. Quittek, Ed. Internet-Draft NEC Europe Ltd. Intended status: Informational M. Chandramouli Expires: April 8, 2013 Cisco Systems, Inc. R. Winter T. Dietz NEC Europe Ltd. B. Claise Cisco Systems, Inc. October 5, 2012 Requirements for Energy Management draft-ietf-eman-requirements-09 Abstract This document defines requirements for standards specifications for energy management. The requirements defined in this document concern monitoring functions as well as control functions. In detail, the focus of the requirements is on the following features: identification of energy-managed devices and their components, monitoring of their Power State, power inlets, power outlets, actual power, power properties, received energy, provided energy, and contained batteries. Further requirements are included to enable control of their power supply and Power State. This document does not specify the features that must be implemented by compliant implementations but rather features that must be supported by standards for energy management. 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 http://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 April 8, 2013. Copyright Notice Quittek, et al. Expires April 8, 2013 [Page 1] Internet-Draft Requirements for Energy Management October 2012 Copyright (c) 2012 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Quittek, et al. Expires April 8, 2013 [Page 2] Internet-Draft Requirements for Energy Management October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Conventional Requirements For Energy Management . . . . . 6 1.2. Specific Requirements for Energy Management . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. General Considerations Related to Energy Management . . . . . 8 3.1. Power States . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Saving Energy versus Maintaining Service Level Agreements . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Local Versus network-Wide energy Management . . . . . . . 9 3.4. Energy Monitoring Versus Energy Saving . . . . . . . . . . 9 3.5. Overview Of Energy Management Requirements . . . . . . . . 10 4. Identification Of Entities . . . . . . . . . . . . . . . . . . 10 5. Information On Entities . . . . . . . . . . . . . . . . . . . 11 5.1. General Information On Entities . . . . . . . . . . . . . 11 5.2. Power Interfaces . . . . . . . . . . . . . . . . . . . . . 12 5.3. Power . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Power State . . . . . . . . . . . . . . . . . . . . . . . 16 5.5. Energy . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.6. Battery State . . . . . . . . . . . . . . . . . . . . . . 18 5.7. Time Series Of Measured Values . . . . . . . . . . . . . . 19 6. Control Of Entities . . . . . . . . . . . . . . . . . . . . . 21 7. Reporting On Other Entities . . . . . . . . . . . . . . . . . 21 8. Controlling Other Entities . . . . . . . . . . . . . . . . . . 22 8.1. Controlling Power States Of Other Entities . . . . . . . . 23 8.2. Controlling Power Supply . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 12. Informative References . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Existing Standards . . . . . . . . . . . . . . . . . 26 A.1. Existing IETF Standards . . . . . . . . . . . . . . . . . 27 A.1.1. ENTITY MIB . . . . . . . . . . . . . . . . . . . . . . 27 A.1.2. ENTITY STATE MIB . . . . . . . . . . . . . . . . . . . 27 A.1.3. ENTITY SENSOR MIB . . . . . . . . . . . . . . . . . . 28 Quittek, et al. Expires April 8, 2013 [Page 3] Internet-Draft Requirements for Energy Management October 2012 A.1.4. UPS MIB . . . . . . . . . . . . . . . . . . . . . . . 28 A.1.5. POWER ETHERNET MIB . . . . . . . . . . . . . . . . . . 29 A.1.6. LLDP MED MIB . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Quittek, et al. Expires April 8, 2013 [Page 4] Internet-Draft Requirements for Energy Management October 2012 1. Introduction With rising energy cost and with an increasing awareness of the ecological impact of running IT equipment, energy management functions and 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 management, both monitoring functions and control functions. Subject of energy management are entities in the network. An entity is either a device or one of a device's components that is subject to individual energy monitoring or control or both. In detail, the requirements listed are focused on the following features: identification of entities, monitoring of their Power State, power inlets, power outlets, actual power, power properties, received energy, provided energy, and contained batteries. Further included is control of entities' power supply and Power State. The main subject of energy management are devices and their components that receive and provide electric energy. Devices may have an IP address, such as hosts, routers, and middleboxes, or they are connected indirectly to the Internet via a proxy with an IP address providing a management interface for the device. An example are devices in a building infrastructure using non-IP protocols and a gateway to the Internet. These requirements concern 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 a set of general needs for energy management. Requirements for an energy management standard are specified in Sections 4 to 8. Sections 4 to 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 with other entities, for example, entities upstream in a power distribution tree. Quittek, et al. Expires April 8, 2013 [Page 5] Internet-Draft Requirements for Energy Management October 2012 1.1. Conventional Requirements For Energy Management The specification of requirements for an energy management standard starts with Section 4 addressing the identification of entities and the granularity of reporting of energy-related information. A standard must support unique identification of entities, reporting per entire device, and reporting energy-related information on individual components of a device or subtended devices. Section 5 specifies requirements related to monitoring of entities. This includes general (type, context) information and specific information on Power States, power inlets, power outlets, power, energy, and batteries. Control Power State and power supply of entities is covered by requirements specified in Section 6. 1.2. 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 three major reasons for this. o For monitoring a particular entity it is not always sufficient to communicate with the entity only. When the entity has no instrumentation for determining power, it might still be possible to obtain power values for the entity by communication with other entities in its power distribution tree. A simple example is retrieving power values from a power meter at the power line into the entity. Common examples are a Power Distribution Unit (PDU) and a Power over Ethernet (PoE) switch. Both supply power to other entities at sockets or ports, respectively, and are often instrumented to measure power per socket or port. o Similar considerations apply to controlling power supply of a entity which 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 on or off power at their sockets or ports, respectively. o Energy management often extends beyond entities with IP network interfaces, to non-IP building systems accessed via a gateway. Requirements in this document do not cover details of these networks, but specify means for opening IP network management towards them. These specific issues of energy management and a set of further ones are covered by requirements specified in Sections 7 and 8. Quittek, et al. Expires April 8, 2013 [Page 6] Internet-Draft Requirements for Energy Management October 2012 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 feature must, should, or may be implemented by compliant implementations. 2. Terminology Energy That which does work or is capable of doing work. As used by electric utilities, it is generally a reference to electrical energy and is measured in kilo-watt hours (kWh) [IEEE-100]. Power The time rate at which energy is emitted, transferred, or received; usually expressed in watts (or in joules per second) [IEEE-100]. 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 is appropriate for the nature of the application and the cost constraints of the organization [ITU-M.3400]. 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 [Fed-Std-1037C]. Energy monitoring Energy monitoring is a part of energy management that deals with collecting or reading information from network elements and attached devices and their components to aid in energy management. Energy control Energy control is a part of energy management that deals with directing influence over network elements and attached devices and their components. Quittek, et al. Expires April 8, 2013 [Page 7] Internet-Draft Requirements for Energy Management October 2012 Power Interface A Power Interface is an interface at which a device is connected to a power transmission medium at which it can receive power, provice power, or both. Power inlet A power inlet is a Power Interface at which a device can receive power fro 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]. 3. General Considerations Related to Energy Management The basic objective of energy management is operating sets of devices with minimal energy, while maintaining a certain level of service. Use cases for energy management can be found in [I-D.ietf-eman-applicability-statement]. 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 devices, the number of Power States and their properties varies considerably. Simple entities may just have only the extreme states, full power and off state. Many devices have three basic Power States: on, off, and sleep. However, more finely grained Power States can be implemented. Quittek, et al. Expires April 8, 2013 [Page 8] Internet-Draft Requirements for Energy Management October 2012 3.2. Saving Energy versus Maintaining Service Level Agreements While the general objective of energy management is quite clear, the way to attain that goal is often difficult. In many cases there is no way of reducing power without the consequence of a potential performance, service, or capacity degradation. Then a trade-off needs to be dealt with between service level objectives 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. 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 when it is not in use or out of scheduled business hours. An energy management system may observe an entity's power state and configure 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 to set policies. Often this information is acquired best through monitoring. Both methods, network-wide and local energy management, have advantages and disadvantages and often it is 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 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: Quittek, et al. Expires April 8, 2013 [Page 9] Internet-Draft Requirements for Energy Management October 2012 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 time of 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 properties o setting Power States Power control is complementary to other energy savings measures such as low power electronics, energy saving protocols, energy-efficient device design (for example, low-power modes for components), and energy-efficient network architectures. Measurement of received and provided energy can provide useful data for developing these technologies. 4. Identification Of Entities Entities must be uniquely identified. This includes entities that are components of managed devices as well as entire devices. For entities that report on or control other entities it is important to identify the entities they report on or control, see Section 7 or Section 8, respectively. An entity may be an entire device or a component of it. Examples of components of interest are a hard drive, a battery, or a line card. It may be required to be able to control individual components to save energy. 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 devices and components are already defined in standard MIB modules, such as the LLDP MIB module [IEEE-802.1AB] and the LLDP-MED MIB module [ANSI-TIA-1057] for devices and the Entity MIB module [RFC4133] and the Power Ethernet MIB [RFC3621] for components of devices. Energy management needs means to link energy- related information to such identifiers. Quittek, et al. Expires April 8, 2013 [Page 10] Internet-Draft Requirements for Energy Management October 2012 Instrumentation for measuring 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.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. Persistence of identifiers The standard must provide means for indicating whether identifiers of entities are persistent across a re-start of the entity. 4.3. Using entity identifiers of other MIB modules The standard must provide means for re-using entity identifiers from other standards including at least the following: o the entPhysicalIndex in the Entity MIB module [RFC4133] o the LldpPortNumber in the LLDP MIB module [IEEE-802.1AB] and in the LLDP-MED MIB module [ANSI-TIA-1057] o the pethPsePortIndex and the pethPsePortGroupIndex in the Power Ethernet MIB [RFC3621] Generic means for re-using other entity identifiers must be provided. 5. 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. 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. Section 5.6 specifies requirements for monitoring batteries. Finally, the reporting of time series of values is covered by Section 5.7. 5.1. General Information On Entities For energy management it may be required to understand the role and context of an entity. An energy management system may aggregate Quittek, et al. Expires April 8, 2013 [Page 11] Internet-Draft Requirements for Energy Management October 2012 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 vital network devices from being switched to lower power or even from being switched off. 5.1.1. Type of entity The standard must provide means to configure, retrieve and report a textual name or a description of an entity. 5.1.2. Context of an entity The standard must provide means for retrieving and reporting context information on entities, for example, tags associated with an entity that indicate the entity's role. 5.1.3. Significance of entities The standard must provide means for retrieving and reporting the significance of entities within its context, for example, how important the entity is. 5.1.4. Power priority The standard must provide means for retrieving and reporting power priorities of entities. Power priorities indicate an order in which Power States of entities are changed, for example, to lower Power States for saving power. 5.1.5. Grouping of entities The standard must provide means for grouping entities. This can be achieved in multiple ways, for example, by providing means to tag entities, to assign them to domains, or to assign device types to them. 5.2. Power Interfaces A Power Interface is either an inlet or an outlet. Some Power Interfaces can change over time from being an inlet to being an outlet and vice versa. However most power interfaces never change. entities have power inlets at which they are supplied with electric power. Most entities 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 Quittek, et al. Expires April 8, 2013 [Page 12] Internet-Draft Requirements for Energy Management October 2012 monitoring, it is useful to retrieve information on the number of inlets of an entity, the availability of power at inlets and which of them are actually in use. Entities can have one or more power outlets for supplying other entities with electric power. For identifying and potentially controlling the source of power received at an inlet, it may be required to identify the power outlet of another entity at which the received power is provided. 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 entities. Static properties of each Power Interface are required information for energy 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. 5.2.1. Lists of Power Interfaces The standard must provide means for monitoring the list of Power Interfaces. 5.2.2. Corresponding power outlet The standard must provide means for identifying the power outlet that provides the power received at a power inlet. 5.2.3. Corresponding power inlets The standard must provide means for identifying the list of power inlets that receive the power provided at a power outlet. 5.2.4. Availability of power The standard must provide means for monitoring the availability of power at each Power Interface. This indicates whether at a Power Interfaces power supply is switched on or off. 5.2.5. Use of power The standard must provide means for monitoring for each Power Interfaces if it is in actual use. For inlets this means that the entity actually receives power at the inlet. For outlets this means that power is actually provided from it to one or more entities. Quittek, et al. Expires April 8, 2013 [Page 13] Internet-Draft Requirements for Energy Management October 2012 5.2.6. Type of current The standard must provide means for reporting the type of current (AC or DC) for each Power Interface as well as for an entity. 5.2.7. Nominal voltage The standard must provide means for reporting the nominal voltage for each Power Interface. 5.2.8. Nominal AC frequency The standard must provide means for reporting the nominal AC frequency for each Power Interface. 5.2.9. Number of AC phases The standard must provide means for reporting the number of AC phases for each Power Interface. 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 it requires dedicated metering hardware. Entities without the ability to measure their power and received and provided energy with high accuracy 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 the 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 supplied power are also of interest. For AC power supply, power attributes beyond the real power to be reported include the apparent power, the reactive power, and the phase angle of the current or the power factor. For both AC and DC power the power characteristics are also subject of monitoring. Power parameters include the actual voltage, the actual frequency, the Total Harmonic Distortion (THD) of voltage and current, the impedance of an AC phase or of the DC supply. Power monitoring should be in line with existing standards, such as [IEC.61850-7-4]. Quittek, et al. Expires April 8, 2013 [Page 14] Internet-Draft Requirements for Energy Management October 2012 For some network management tasks it is desirable to receive notifications from entities when their power value exceeds or falls below given thresholds. 5.3.1. Real power The standard must provide means for reporting the real power for each Power Interface as well as for an entire entity. Reporting power includes reporting the direction of power flow. 5.3.2. Power measurement interval The standard must provide means for reporting the corresponding time or time interval for which a power value is reported. The power value can be measured at the corresponding time or averaged over the corresponding time interval. 5.3.3. Power measurement method The standard must provide means to indicate the method how these values have been obtained. Based on how the measurement was conducted, it is possible to associate a certain degree of confidence with the reported power value. For example, there are methods of measurement such as direct power measurement, or by estimation based on performance values, or hard coding average power values for an entity. 5.3.4. Accuracy of power and energy values The standard must provide means for reporting the accuracy of reported power and energy values. 5.3.5. Actual voltage and current The standard must provide means for reporting the actual voltage and actual current for each power interface as well as for an entire entity. In case of AC power supply, means must be provided for reporting the actual voltage and actual current per phase. 5.3.6. High/low power notifications The standard must provide means for creating notifications if power values of an entity rise above or fall below given thresholds. 5.3.7. Complex power The standard must provide means for reporting the complex power for each Power Interface and for each phase at a Power Interface. Quittek, et al. Expires April 8, 2013 [Page 15] Internet-Draft Requirements for Energy Management October 2012 Besides the real power, at least two out of the following three quantities need to be reported: apparent power, reactive power, phase angle. The phase angle can be substituted by the power factor. 5.3.8. Actual AC frequency The standard must provide means for reporting the actual AC frequency for each Power Interface. 5.3.9. Total harmonic distortion The standard must provide means for reporting the Total Harmonic Distortion (THD) of voltage and current for each Power Interface. In case of AC power supply, means must be provided for reporting the THD per phase. 5.3.10. Power supply impedance The standard must provide means for reporting the impedance of power supply for each Power Interface. In case of AC power supply, means must be provided for reporting the impedance per phase. 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 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 possibly using different Power State sets, while simultaneously interfacing with a particular entity, the energy management standard must provide means for supporting multiple Power State sets used simultaneously at an entity. Power States have parameters that describe its properties. It is required to have standardized means for reporting some key properties, such as the typical power of an entity in a certain state. There also is a need to report statistics on Power States including the time spent and the received and provided energy in a Power State. Quittek, et al. Expires April 8, 2013 [Page 16] Internet-Draft Requirements for Energy Management October 2012 5.4.1. Actual Power State The standard must provide means for reporting the actual Power State of an entity. 5.4.2. List of supported Power States The standard must provide means for retrieving the list of all potential Power States of an entity. 5.4.3. Multiple Power State sets The standard must provide means for supporting multiple Power State sets simultaneously at an entity. 5.4.4. List of supported Power State sets The standard must provide means for retrieving the list of all Power State sets supported by an entity. 5.4.5. List of supported Power States within a set The standard must provide means for retrieving the list of all potential Power States of an entity for each supported Power State set. 5.4.6. Typical power per Power State The standard must provide means for retrieving the typical power for each supported Power State. 5.4.7. Power State statistics The standard must provide means for monitoring statistics per Power State including the total time spent in a Power State, the number of times each state was entered and the last time each state was entered. More Power State statistics are addressed by requirement 5.5.3. 5.4.8. Power State changes The standard must provide means for generating a notification when the actual Power State of an entity changes. 5.5. Energy Monitoring of electrical energy received or provided by an entity is a core function of energy management. Since energy is an accumulated Quittek, et al. Expires April 8, 2013 [Page 17] Internet-Draft Requirements for Energy Management October 2012 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 time stamps in the past. It is useful for entities to record their received and provided energy per Power State and report these quantities. 5.5.1. Energy The standard must provide means for reporting measured values of energy and the direction of the energy flow received or provided by an entity. The standard must also provide the means to report the energy passing through each Power Interface. 5.5.2. Time intervals The standard must provide means for reporting the time interval for which an energy value is reported. 5.5.3. Energy per Power State The standard must provide means for reporting the received and provided energy for each individual power state. This extends the requirement 5.4.7 on Power State statistics. 5.6. Battery State Many entities contain batteries that supply them with power when disconnected from electrical power distribution grids. The status of these batteries is typically controlled by automatic functions that act locally on the entity and manually by users of the entity. There is a need to monitor the battery status of these entities by network management systems. Devices containing batteries can be modeled in two ways. The entire device can be modeled as a single entity on which energy-related information is reported or the battery can be modeled as an individual entity for which energy-related information is monitored individually according to requirements in Sections 5.1 to 5.5. Further information on batteries is of interest for energy management, such as the current charge of the battery, the number of completed charging cycles, the charging state of the battery, and further static and dynamic battery properties. It is desirable to receive notifications if the charge of a battery becomes very low or if a battery needs to be replaced. Quittek, et al. Expires April 8, 2013 [Page 18] Internet-Draft Requirements for Energy Management October 2012 5.6.1. Battery charge The standard must provide means for reporting the current charge of a battery. 5.6.2. Battery charging state The standard must provide means for reporting the charging state (charging, discharging, etc.) of a battery. 5.6.3. Battery charging cycles The standard must provide means for reporting the number of completed charging cycles of a battery. 5.6.4. Actual battery capacity The standard must provide means for reporting the actual capacity of a battery. 5.6.5. Static battery properties The standard must provide means for reporting static properties of a battery, including the nominal capacity, the number of cells, the nominal voltage, and the battery technology. 5.6.6. Low battery charge notification The standard must provide means for generating a notification when the charge of a battery decreases below a given threshold. 5.6.7. Battery replacement notification The standard must provide means for generating a notification when the number of charging cycles of battery exceeds a given threshold. 5.6.8. Multiple batteries The standard must provide means for meeting requirements 5.6.1 to 5.6.7 for each individual battery contained in a single entity. 5.7. Time Series Of Measured Values For some network management tasks, it is required to obtain time series of measured values from entities, such as power, energy, battery charge, etc. In general time series measurements could be obtained in many Quittek, et al. Expires April 8, 2013 [Page 19] Internet-Draft Requirements for Energy Management October 2012 different ways. It should be avoided that such time series can only be obtained through regular polling by the energy management system. 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 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 and battery charge 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 time stamps or alternatively by mean values for these quantities averaged between two (consecutive) time stamps 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 IPFIX protocol [RFC5101],[RFC5102]. SNMP [RFC3411] is an example for a protocol that can be used for realizing 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. 5.7.1. Time series of energy values The standard must provide means for reporting time series of energy values. Quittek, et al. Expires April 8, 2013 [Page 20] Internet-Draft Requirements for Energy Management October 2012 5.7.2. Time series interval types The standard must provide means for supporting alternative interval types. Requirement 5.5.2 applies to every reported time value. 5.7.3. Time series storage capacity The management standard should provide means for reporting the number of values of a time series that can be stored for later reporting. 6. Control Of Entities Many entities control their Power State locally. Other entities need interfaces for an energy management system to control their Power State. Power supply is typically not self-managed by entities. And controlling power supply is typically not conducted as interaction between energy management system and the entity itself. It is rather an interaction between the management system and an entity 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 entity. 6.1. Controlling Power States The standard must provide means for setting Power States of entities. 6.2. Controlling power supply The standard must provide means for switching power supply off or turning power supply on at power interfaces providing power to one or more entity. 7. Reporting On Other Entities As discussed in Section 5, not all energy-related information may be available at the concerned entity. Such information may be provided by other entities. This section covers reporting of information only. See Section 8 for requirements on controlling other entities. There are cases where a power supply unit switches power for several entities by turning power on or off at a single power outlet or where a power meter measures the accumulated power of several entities at a single power line. Consequently, it should be possible to report that a monitored value does not relate to just a single entity, but Quittek, et al. Expires April 8, 2013 [Page 21] Internet-Draft Requirements for Energy Management October 2012 is an accumulated value for a set of entities. All of these entities belonging to that set need to be identified. If an entity has information about where energy-related information on itself can be retrieved, then it would be useful to communicate this information. This applies even if the information only provides accumulated quantities for several entities. 7.1. Reports on other entities The standard must provide means for an entity to report information on another entity. 7.2. Identity of other entities on which is reported For entities that report on one or more other entities, the standard must provide means for reporting the identity of other entities on which information is reported. 7.3. Reporting quantities accumulated over multiple entities The standard must provide means for reporting the list of all entities from which contributions are included in an accumulated value. 7.4. List of all entities on which is reported For entities that report on one or more other entities, the standard must provide means for reporting the complete list of all those entities on which energy-related information can be reported. 7.5. Content of reports on other entities For entities that report on one or more other entities, the standard must provide means for indicating which energy-related information can be reported for which of those entities. 7.6. Indicating source of remote information For an entity that has one or more other entities reporting on its behalf, the standard must provide means for the entity to indicate which information is available at which other entity. 8. Controlling Other Entities This section specifies requirements for controlling Power States and power supply of entities by communicating with other entities that Quittek, et al. Expires April 8, 2013 [Page 22] Internet-Draft Requirements for Energy Management October 2012 have means for doing that control. 8.1. Controlling Power States Of Other Entities Some entities have control over Power States of other entities. For example a gateway to a building system may have means to control the Power State of entities in the building that do not have an IP interface. For this scenario and other similar cases means are needed to make this control accessible to the energy management system. In addition to this, it is required that an entity that has its state controlled by other entities has means to report the list of these other entities. 8.1.1. Control of Power States of other entities The standard must provide means for an energy management system to send Power State control commands to an entity that concern the Power States of entities other than the one the command was sent to. 8.1.2. Identity of other Power State controlled entities The standard must provide means for reporting the identities of the entities for which the reporting entity has means to control their Power States. 8.1.3. List of all Power State controlled entities The standard must provide means for an entity to report the list of all entities for which it can control the Power State. 8.1.4. List of all Power State controllers The standard must provide means for an entity that receives commands controlling its Power State from other entities to report the list of all those entities. 8.2. Controlling Power Supply Some entities may have control of the power supply of other entities, for example, because the other entity is supplied via a power outlet of the entity. For this and similar cases means are needed to make this control accessible to the energy management system. This need is already addressed by requirement 6.2. In addition, it is required that an entity that has its supply controlled by other entities has means to report the list of these Quittek, et al. Expires April 8, 2013 [Page 23] Internet-Draft Requirements for Energy Management October 2012 other entities. This need is already addressed by requirements 5.2.2 and 5.2.3. 9. Security Considerations Controlling Power State and power supply of entities are highly sensitive actions since they can significantly affect the operation of directly and indirectly affected devices. Therefore all control actions addressed in 6 and 8 must be sufficiently protected through authentication, authorization, and integrity protection mechanisms. Monitoring energy-related quantities of an entity addressed in Sections 5 - 8 can be used to derive more information than just the received and provided energy, so monitored data requires privacy protection. Monitored data may be used as input to control, accounting, and other actions, so integrity of transmitted information and authentication of the origin may be needed. 9.1. Secure energy management The standard must provide privacy, integrity, and authentication mechanisms for all actions addressed in Sections 5 - 8. The security mechanisms must address all threats listed in Section 1.4 of [RFC3411]. 10. IANA Considerations This document has no actions for IANA. 11. Acknowledgements The authors would like to thank Ralf Wolter for his first essay on this draft. Many thanks to William Mielke, John Parello, Bruce Nordman, JinHyeock Choi, Georgios Karagiannis, and Michael Suchoff for helpful comments on the draft. 12. Informative References [RFC1628] Case, J., "UPS Management Information Base", RFC 1628, May 1994. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, Quittek, et al. Expires April 8, 2013 [Page 24] Internet-Draft Requirements for Energy Management October 2012 December 2002. [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor Management Information Base", RFC 3433, December 2002. [RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", RFC 3621, December 2003. [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005. [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268, November 2005. [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008. [I-D.ietf-eman-applicability-statement] Silver, L., Chandramouli, M., and B. Nordman, "Energy Management (EMAN) Applicability Statement", draft-ietf-eman-applicability-statement-01 (work in progress), June 2012. [ACPI.R30b] Hewlett-Packard Corporation, Intel Corporation, Microsoft Corporation, Phoenix Corporation, and Toshiba Corporation, "Advanced Configuration and Power Interface Specification, Revision 3.0b", October 2006. [ANSI-TIA-1057] Telecommunications Industry Association, "ANSI-TIA-1057- 2006 - TIA Standard - Telecommunications - IP Telephony Infrastructure - Link Layer Discovery Protocol for Media Endpoint Devices", April 2006. [DMTF.DSP1027] Dasari (ed.), R., Davis (ed.), J., and J. Hilland (ed.), "Power State Management Profile", September 2008. [Fed-Std-1037C] United States National Communications System Technology & Standards Division, "Federal Standard 1037C - Telecommunications: Glossary of Telcommunication Terms", Quittek, et al. Expires April 8, 2013 [Page 25] Internet-Draft Requirements for Energy Management October 2012 August 1996. [IEEE-100] IEEE, "Authoritative Dictionary of IEEE Standards Terms, IEEE 100, Seventh Edition", December 2000. [IEC.62053-21] International Electrotechnical Commission, "Electricity metering equipment (a.c.) - Particular requirements - Part 22: Static meters for active energy (classes 1 and 2)", 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)", 2003. [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", 2010. [IEEE-1621] Institute of Electrical and Electronics Engineers, "IEEE P1621-2004 -Draft Standard for User Interface Elements in Power Control of Electronic Devices Employed in Office Consumer Environments", June 2005. [IEEE-802.1AB] IEEE Computer Society, "IEEE Std 802.1AB-2009 - IEEE Standard for Local and metropolitan area networks - Station and Media Access Control Discovery", September 2009. [ITU-M.3400] International Telcommunication 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. Appendix A. Existing Standards This section analyzes existing standards for energy and Power State Quittek, et al. Expires April 8, 2013 [Page 26] Internet-Draft Requirements for Energy Management October 2012 monitoring. It shows that there are already several standards that cover only some part of the requirements listed above, but even all together they do not cover all of the requirements for energy management. A.1. Existing IETF Standards There are already RFCs available that address a subset of the requirements. A.1.1. ENTITY MIB The ENTITY-MIB module defined in [RFC4133] was designed to model physical and logical entities of a managed system. A physical entity is an identifiable physical component. A logical entity can use one or more physical entities. From an energy monitoring perspective of a managed system, the ENTITY-MIB modeling framework can be reused and whenever RFC 4133 [RFC4133] has been implemented. The entPhysicalIndex from entPhysicalTable can be used to identify an entity/component. However, there are use cases of energy monitoring, where the application of the ENTITY-MIB does not seem readily apparent and some of those entities could be beyond the original scope and intent of the ENTITY-MIB. Consider the case of remote devices attached to the network, and the network device could collect the energy measurement and report on behalf of such attached devices. Some of the remote devices such as PoE phones attached to a switch port have been considered in the Power-over-Ethernet MIB module [RFC3621]. However, there are many other devices such as a computer, which draw power from a wall outlet or building HVAC devices which seem to be beyond the original scope of the ENTITY-MIB. Yet another example, is smart-PDUs, which can report the energy provided to the device attached to the power outlet of the PDU. In some cases, the device can be attached to multiple to power outlets. Thus, the energy measured at multiple outlets need to be aggregated to determine the energy provided to a single device. From mapping perspective, between the PDU outlets and the device this is a many- to-one mapping. It is not clear if such a many-to-one mapping is feasible within the ENTITY-MIB framework. A.1.2. ENTITY STATE MIB RFC 4268 [RFC4268] defines the ENTITY STATE MIB module. Implementations of this module provide information on entities including the standby status (hotStandby, coldStandby, providingService), the operational status (disabled, enabled, Quittek, et al. Expires April 8, 2013 [Page 27] Internet-Draft Requirements for Energy Management October 2012 testing), the alarm status (underRepair, critical, major, minor, warning), and the usage status (idle, active, busy). This information is already useful as input for policy decisions and for other network management tasks. However, the number of states would cover only a small subset of the requirements for Power State monitoring and it does not provide means for energy monitoring. For associating the information conveyed by the ENTITY STATE MIB to specific components of a device, the ENTITY STATE MIB module makes use of the means provided by the ENTITY MIB module [RFC4133]. Particularly, it uses the entPhysicalIndex for identifying entities. The standby status provided by the ENTITY STATE MIB module is related to Power States required for energy management, but the number of states is too restricted for meeting all energy management requirements. For energy management several more Power States are required, such as different sleep and operational states as defined by the Advanced Configuration and Power Interface (ACPI) [ACPI.R30b] or the DMTF Power State Management Profile [DMTF.DSP1027]. A.1.3. ENTITY SENSOR MIB RFC 3433 [RFC3433] defines the ENTITY SENSOR MIB module. Implementations of this module offer a generic way to provide data collected by a sensor. A sensor could be an energy meter delivering measured values in Watt. This could be used for reporting current power of an entity and its components. Furthermore, the ENTITY SENSOR MIB can be used to retrieve the accuracy of the used power meter. Similar to the ENTITY STATE MIB module, the ENTITY SENSOR MIB module makes use of the means provided by the ENTITY MIB module [RFC4133] for relating provided information to components of a device. However, there is no unit available for reporting energy quantities, such as, for example, watt seconds or kilowatt hours, and the ENTITY SENSOR MIB module does not support reporting accuracy of measurements according to the IEC / ANSI accuracy classes, which are commonly in use for electric power and energy measurements. The ENTITY SENSOR MIB modules only provides a coarse-grained method for indicating accuracy by stating the number of correct digits of fixed point values. A.1.4. UPS MIB RFC 1628 [RFC1628] defines the UPS MIB module. Implementations of this module provide information on the current real power of entities attached to an uninterruptible power supply (UPS) device. This application would require identifying which entity is attached to Quittek, et al. Expires April 8, 2013 [Page 28] Internet-Draft Requirements for Energy Management October 2012 which port of the UPS device. UPS MIB provides information on the state of the UPS network. The MIB module contains several variables that are used to identify the UPS entity (name, model,..), the Battery State, to characterize the input load to the UPS, to characterize the output from the UPS, to indicate the various alarm events. The measurements of power in UPS MIB are in Volts, Amperes and Watts. The units of power measurement are RMS volts, RMS Amperes and are not based on Entity-Sensor MIB [RFC3433]. A.1.5. POWER ETHERNET MIB Similar to the UPS MIB, implementations of the POWER ETHERNET MIB module defined in RFC3621 [RFC3621] provide information on the current power of the entities that receive Power over Ethernet (PoE). This information can be retrieved at the power sourcing equipment. Analogous to the UPS MIB, it is required to identify which entities are attached to which port of the power sourcing equipment. The POWER ETHERNET MIB does not report power and energy on a per port basis, but can report aggregated values for groups of ports. It does not use objects of the ENTITY MIB module for identifying entities, although this module existed already when the POWER ETHERNET MIB modules was standardized. A.1.6. LLDP MED MIB The Link Layer Discovery Protocol (LLDP) defined in IEEE 802.1ab is a data link layer protocol used by network devices for advertising of their identities, capabilities, and interconnections on a LAN network. The Media Endpoint Discovery (MED) (ANSI-TIA-1057) is an enhancement of LLDP known as LLDP-MED. The LLDP-MED enhancements specifically address voice applications. LLDP-MED covers 6 basic areas: capabilities discovery, LAN speed and duplex discovery, network policy discovery, location identification discovery, inventory discovery, and power discovery. Quittek, et al. Expires April 8, 2013 [Page 29] Internet-Draft Requirements for Energy Management October 2012 Authors' Addresses Juergen Quittek (editor) NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 Heidelberg 69115 DE Phone: +49 6221 4342-115 Email: quittek@neclab.eu Mouli Chandramouli Cisco Systems, Inc. Sarjapur Outer Ring Road Bangalore, IN Phone: +91 80 4426 3947 Email: moulchan@cisco.com Rolf Winter NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 Heidelberg 69115 DE Phone: +49 6221 4342-121 Email: Rolf.Winter@neclab.eu Thomas Dietz NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 Heidelberg 69115 DE Phone: +49 6221 4342-128 Email: Thomas.Dietz@neclab.eu Quittek, et al. Expires April 8, 2013 [Page 30] Internet-Draft Requirements for Energy Management October 2012 Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Degem 1831 BE Phone: +32 2 704 5622 Email: bclaise@cisco.com Quittek, et al. Expires April 8, 2013 [Page 31]