Network Working Group J. Quittek, Ed. Internet-Draft R. Winter Intended status: Informational T. Dietz Expires: April 22, 2010 NEC Europe Ltd. B. Claise M. Chandramouli Cisco Systems, Inc. October 19, 2009 Requirements for Power Monitoring draft-quittek-power-monitoring-requirements-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 22, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Quittek, et al. Expires April 22, 2010 [Page 1] Internet-Draft Requirements for Power Monitoring October 2009 Abstract This memo discusses requirements for monitoring the energy consumption and the power state of devices. It shows that these requirements are not covered by existing standards and proposes directions for new work items on this subject at the IETF. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Monitoring Requirements . . . . . . . . . . . . . . . . . . . 4 2.1. Target Devices . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Granularity . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Remote and Aggregated Monitoring . . . . . . . . . . . . . 5 2.4. Required Information . . . . . . . . . . . . . . . . . . . 6 2.4.1. Power State Monitoring . . . . . . . . . . . . . . . . 6 2.4.2. Energy Consumption Monitoring . . . . . . . . . . . . 7 2.4.3. Battery State Monitoring . . . . . . . . . . . . . . . 8 3. Monitoring Models . . . . . . . . . . . . . . . . . . . . . . 8 4. Existing Standards . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Existing IETF Standards . . . . . . . . . . . . . . . . . 9 4.1.1. ENTITY STATE MIB . . . . . . . . . . . . . . . . . . . 9 4.1.2. ENTITY SENSOR MIB . . . . . . . . . . . . . . . . . . 9 4.1.3. UPS MIB . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.4. POWER ETHERNET MIB . . . . . . . . . . . . . . . . . . 10 4.2. Existing standards of other bodies . . . . . . . . . . . . 10 4.2.1. DMTF . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Suggested Actions . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Quittek, et al. Expires April 22, 2010 [Page 2] Internet-Draft Requirements for Power Monitoring October 2009 1. Introduction With rising energy costs and an increasing awareness of the ecological impact of running IT and networking equipment, active energy management is becoming an additional requirement for network management systems. The basic objective of energy management is operating communication networks and other equipment with a minimal amount of energy. An energy management system should provide means for reducing power consumption of individual network components and IT components. An essential step to achieve this goal is setting all components to an operational mode that consumes as little power as possible while still providing sufficient performance to meet service level objectives. The suitable performance level setting may vary over time-of-day and may depend on several circumstances. There are three basic kinds of power saving modes for a component: o reduced power modes (lower clock rate for processor, lower data rate on a link, etc.) o stand-by modes (not functional, but immediately available) o power off modes (requiring significant time for becoming operational) While the goal is quite clear, the way to get there is often complicated. In many cases there is no way of reducing power consumption without an effective performance degradation. Then a trade-off needs to be dealt with between service level objectives and energy efficiency. In other cases a reduction of energy comsumption can easily be achieved while still maintaining all service level objectives, for exampe, by switching components to a lower power mode when higher performance is not needed. Network management systems can control such situations by implementing policies to achieve a certain degree of energy efficiency. In order to make policy decisions properly, information about the energy consumption of network components in different modes is required. Often this information is acquired best through monitoring. Monitoring operational power states and energy consumption is also needed for other purposes including but not limited to o investigating of power saving potential o evaluating the effectiveness of energy saving policies and measures o deriving, implementing, and testing power management strategies Quittek, et al. Expires April 22, 2010 [Page 3] Internet-Draft Requirements for Power Monitoring October 2009 o accounting the total power consumption of a network element, a network, a service, or subcomponents of those Energy efficiency, not only of networks, has received a lot attention recently. Given the potential gains, there are numerous industry efforts that are concentrating on energy efficiency in several areas such as: o Energy efficiency of communication networks and IT systems o Energy efficiency of buildings o Efficient delivery of electricity from suppliers to consumers (smart [power] grids) In this memo however, we focus on power monitoring only. Participating entities are monitoring systems that receive information and networked devices that provide information on energy consumption and power state information concerning themselves or potentially also concerning other devices. Not in the scope of this memo are means for controlling the energy consumption and the power state of monitored devices. But it is assumed that proprietary and standardized solutions for this purpose are (or will become) available. It should be noted that monitoring energy consumption and power states itself is obviously not in itself a means to reduce the energy consumption of a device. On the contrary, it likely will slightly increase the power consumption of a device. However, the acquired information is required to enable measures that in total lead to energy savings. It should further be noted that active power control is complimentary (but essential) to other energy savings measures such as low power electronics, energy saving protocols (e.g. 802.3az), and energy- efficient device design (for example, stand-by and low-power modes for individual components of a device), and energy-efficient network architectures. Measurement of energy consumption may also provide input for developing these technologies. 2. Monitoring Requirements 2.1. Target Devices Considering the basic objective described in the previous section, energy monitoring should be applied to all components of a communication network including routers, switches, middleboxes, hosts, etc. Typically, the total power consumption of hosts is much larger than Quittek, et al. Expires April 22, 2010 [Page 4] Internet-Draft Requirements for Power Monitoring October 2009 the total consumption of all other kinds of network devices, but still the contribution of routers, switches, and middleboxes, etc. is not negligible. Therefore, monitoring capabilities should be provided for all kinds of network devices. Monitoring support should also be provided for certain components that do not have means for measuring energy consumption by themselves, but for which their power supply can be monitored by other devices. For examples see section Section 2.3. 2.2. Granularity Often it is desirable to switch off individual components of a device but not the entire device. The switch may need to continue serving a few ports (for example, the ports serving an email server or needed for server backup), but most other ports could be entirely switched off under some policies (for example at night or the weekend in an office). As illustrated by this example, it is often desirable to monitor power state and energy consumption on a granularity level that is finer than just the device level. Monitoring should be available for individual components of devices, such as line cards, processor cards, hard drives, etc. For example, for IP routers the following list of views of a router gives an idea of components that potentially should be monitored individually: o physical view: chassis (or stack), central control engine, line cards, service cards, etc. o component view: CPU, ASICs, fans, power supply, ports (single ports and port groups), storage and memory o feature view: L2 forwarding, L3 routing, security features, load balancing features, network management, etc. o logical view: system, data-plane, control-plane, etc. o relationship view: line cards, ports and the correlation between transmission speed and power consumption, relationship of system load and total power consumption Instrumentation for measuring energy consumption of a device is potentially much more expensive than instrumentation for retrieving the devices power state. It may be a reasonable compromise in many cases to provide power state information for all individually switchable components of a device separately, while the energy consumption is only measured for the entire device. 2.3. Remote and Aggregated Monitoring Often it is sufficient and more cost efficient having a single device measuring and providing power state and energy consumption Quittek, et al. Expires April 22, 2010 [Page 5] Internet-Draft Requirements for Power Monitoring October 2009 information not just for itself but also for several further devices that are in some way attached to it. If the measuring and reporting device has access to individual power supply lines for each device, then it can measure energy consumption per device. If it only has access to a joint power supply for several devices, then it will measure aggregated values. One example for the first case is a switch acting as power sourcing equipment for several IP phones using Power over Ethernet (PoE). The switch can measure the power consumption for each phone individually at the port the phone is connected to. The phones do not need to provide means for energy consumption measurement and reporting by themselves. Another example is a smart meter that just measures and reports the energy transmitted through attached electric cables. Such a smart meter can be used to monitor energy consumption of an individual device if connected to the devices' individual power supply. But in many common cases it measures the aggregated energy consumption of several devices, for example, as part of an uninterruptible power supply (UPS) that serves several devices at a single power cord, or as a smart electric meter for a set of machines in a rack, in an office building or at a residence. 2.4. Required Information This section lists requirements for information to be retrieved. Because of the different nature of power state monitoring and energy consumption monitoring, these are discussed separately. In addition, a section on battery monitoring is included which again comes with a set of very different requirements. Not all of the individual requirements listed in subsections below are equally relevant. A classification into 'required' and 'optional' is still in progress. 2.4.1. Power State Monitoring The power state of a device or component typically can only have a small number of discrete values such as, for example, full power, low power, standby, hibernating, off. However, some of these states may have one or more sub-states or state parameters. For example, in low power state, a reduced clock rate may be set to a large number of different values. For the device power state, the following information is considered to be relevant: Quittek, et al. Expires April 22, 2010 [Page 6] Internet-Draft Requirements for Power Monitoring October 2009 o the current state - the time of the last change o the cause for the last transition o time to transit from one stage to another o the total time spent in each state o the duration of the last period spent in each state o the number of transitions to each state o the current power source If the number of discreet sub-states is small, then is may be desirable to collect the same information as listed above for the main device state. For state parameters with many potential values, other information is more relevant: o the current parameter value(s) o the time of the last change (if parameters are to be adapted continuously) o the average value(s) per state o the standard deviation from the mean value(s) per state o the number of policy-based changes of the parameter(s) (if not expected to be too many) For some network management tasks it may be desirable to receive notifications from devices when components or the entire device change their power state. 2.4.2. Energy Consumption Monitoring Different to the power state, energy consumption of a device or a device's component is a quantity for which the value may change continuously. Therefore, the information that needs to be retrieved concerning this quantity is quite different: o the current real power (energy consumption rate) averaged over a short time interval o total energy consumption o energy consumption since the last report or for the last configured time interval o total energy consumption per power state o energy consumption per power state since the last report For some network management tasks it may be desirable to receive notifications from devices when the current power consumption of a component or of the entire device exceeds or falls below certain thresholds. For some network management tasks it is required to measure the power over time with a relatively high time resolution. In such a case not just single values for the current power of a component is needed, but a series of power values reporting on consecutive time intervals. Quittek, et al. Expires April 22, 2010 [Page 7] Internet-Draft Requirements for Power Monitoring October 2009 In order to put measured data into perspective, the precision of the measured data, i.e. the potential error in the measured data, needs to be known as well. 2.4.3. Battery State Monitoring An increasing number of networked devices are expected to be battery powered. This includes e.g. smart meters that report meter readings and are installed in places where external power supply is not always possible or costly. But also other devices might have internal/ external batteries to power devices for short periods of time when the main power fails, to power parts of the device when the main device is switches off etc. Knowing the state of these batteries is important for the operation of these devices and includes information such as: o the current charge of the battery o the age of the battery o the state of the battery (e.g. being re-charged) o last usage of the battery o maximum energy provided by the battery It is possible for devices that are only battery-powered to send notifications when the current battery charge has dropped below a certain threshold in order to inform the management system of needed replacement. The same applies for the age of a battery. 3. Monitoring Models Monitoring of power states and energy consumption can be performed in pull mode (for example, SNMP GET [RFC3410]) or in push mode (for example SNMP notification [RFC3410], Syslog [RFC5424], or IPFIX [RFC5101]). Pull mode monitoring is often easier to handle for a network management systems, because it can determine when it gets certain information from a certain device. However, the overhead of pull model monitoring is typically higher than for push model monitoring, particularly when large numbers of values are to be collected, such as time series of power values. In such cases, push model monitoring may be preferable with a device sending a data stream of values without explicit request for each value from the network management system. For notifications on events, only the push model is considered to be appropriate. Applying these considerations to the required information leads to the conclusion that most of the information can appropriately be reported using the pull model. The only exceptions are notifications Quittek, et al. Expires April 22, 2010 [Page 8] Internet-Draft Requirements for Power Monitoring October 2009 on power state changes and high volume time series of energy consumption values. 4. Existing Standards This section analyzes existing standards for energy consumption and power state monitoring. It shows that there are already several standards that cover some part of the requirements listed above, but even all together do not cover all of the requirements. 4.1. Existing IETF Standards There are already RFCs available that address a subset of the requirements. 4.1.1. 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, testing), the alarm status (underRepair, critical, major, minor, warning), and the usage status (idle, active, busy). This information is already useful as input to policy decisions and for other network monitoring tasks. However, it cover only a small subset of the requirements for power state monitoring and it does not provide means for energy consumption monitoring. For relating provided information to components of a device, the ENTITY STATE MIB module makes use of the means provided by the ENTITY MIB module [RFC4133]. 4.1.2. 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 consumption meter delivering measured values in Watt. This could be used for reporting current power of a device and its components. Furthermore, the ENTITY SENSOR MIB can be used to retrieve the precision of the used power meter. However, there is no unit available for reporting energy quantities, such as, for example, watt seconds or kilowatt hours. 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. Quittek, et al. Expires April 22, 2010 [Page 9] Internet-Draft Requirements for Power Monitoring October 2009 4.1.3. UPS MIB RFC 1628 [RFC1628] defines the UPS MIB module. Implementations of this module provide information on the current real power of devices attached to an uninterruptible power supply (UPS) device. This application would require to identify which device is attached to which port of the UPS device. 4.1.4. 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 individual devices that receive Power over Ethernet (PoE). The information can be retrieved at the power sourcing equipment. Like for the UPS MIB, it is required to identify which device is attached to which port of the power source equipment. 4.2. Existing standards of other bodies 4.2.1. DMTF The DMTF has defined a power state management profile [DMTF.DSP1027] that is targeted at computer systems. It is based on the DMTF's Common Information Model (CIM) and rather a device profile than an actual energy consumption monitoring standard. The power state management profile is used to describe and to manage the power state of computer systems. This includes e.g. means to change the power state of a device (e.g. to shutdown the device) which is an aspect of but not sufficient for active energy managagement. 5. Suggested Actions Based on the analysis of requirements in section Section 2 and the discussion of monitoring models in section Section 3 this memo proposes to develop a standard for pull-based monitoring of power state montoring and energy consumption. Particularly, it suggest to develop a MIB module for this purpose. Such a MIB module could also cover push-based reporting of power state changes using SNMP notification. The analysis of existing MIB modules in the previous section shows that they are not sufficient to meet the requirements discussed in section Section 2. The only aspect that is not covered well by a MIB/SNMP solution is the reporting of large time series of energy consumption values. For this purpose SNMP does not appear to be an optimal choice. Quittek, et al. Expires April 22, 2010 [Page 10] Internet-Draft Requirements for Power Monitoring October 2009 Particularly for supporting smart meter functionality, a push-based protocol appears to be more appropriate. Within the IP protocol family the Syslog and IPFIX protocols seem to be the most suitable candidates. There are more standard protocols with the capability to transfer measurement series, for example, DIAMETER, but these protocols are designed and well suited for other application areas than network monitoring. Comparing the two candidates (Syslog and IPFIX), IPFIX seems to be the better suited one. While Syslog is optimized for the transmission of text messages, IPFIX is better equipped for tranmitting sequences of numerical values. Encoding numerical values into syslog is well feasible, see, for example, the mapping of SNMP notifications to Syslog messages in [I-D.ietf-opsawg-syslog-snmp], but IPFIX provides better means. With the extensible IPFIX information model [RFC5102] no protocol extension would be required for transmitting energy consumption information. Only a set of new information elements would need to be registered at IANA. However, this memo suggest that the definition of such information elements should be conducted within the IETF and they should be documented in a standards track RFC. 6. Acknowledgements The authors would like to thank Ralf Wolter, for his first essay on this draft. 7. Security Considerations This memo currently does not impose any security considerations. 8. IANA Considerations This memo has no actions for IANA.. 9. References 9.1. Normative References [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268, November 2005. [RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", RFC 3621, December 2003. Quittek, et al. Expires April 22, 2010 [Page 11] Internet-Draft Requirements for Power Monitoring October 2009 [RFC1628] Case, J., "UPS Management Information Base", RFC 1628, May 1994. [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor Management Information Base", RFC 3433, December 2002. [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 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. [DMTF.DSP1027] Dasari (ed.), R., Davis (ed.), J., and J. Hilland (ed.), "Power State Management Profile", September 2008. 9.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [I-D.ietf-opsawg-syslog-snmp] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages", draft-ietf-opsawg-syslog-snmp-05 (work in progress), August 2009. Quittek, et al. Expires April 22, 2010 [Page 12] Internet-Draft Requirements for Power Monitoring October 2009 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@nw.neclab.eu 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@nw.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@nw.neclab.eu 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 22, 2010 [Page 13] Internet-Draft Requirements for Power Monitoring October 2009 Mouli Chandramouli Cisco Systems, Inc. Sarjapur Outer Ring Road Bangalore, IN Phone: +91 80 4426 3947 Email: moulchan@cisco.com Quittek, et al. Expires April 22, 2010 [Page 14]