Network Working Group B. Claise Internet-Draft J. Parello Intended Status: Informational Cisco Systems, Inc. Expires: January 8, 2012 B. Schoening Independent Consultant J. Quittek NEC Europe Ltd. July 8, 2011 Energy Management Framework draft-ietf-eman-framework-02 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 October, 2011. Internet-Draft July 2011 Copyright Notice Copyright (c) 2011 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. Abstract This document defines a framework for providing Energy Management for devices within or connected to communication networks. The framework defines a domain of Energy Management devices that is a logical unit of Energy Management. Within a domain each device is identified, classified and given context. Devices can be monitored and/or controlled with respect to power, power state, energy, demand, electrical quality, and battery. Additionally the framework models relationships and capabilities between devices in a domain. Expires January 8, 2012 [Page 2] Internet-Draft July 2011 Table of Contents 1. Introduction........................................... 4 1.1. Energy Management Document Overview............... 4 2. Requirements & Use Cases............................... 5 3. Terminology............................................ 6 4. Energy Management Reference Model..................... 11 5. Framework High Level Concepts and Scope............... 14 5.1. Energy Managed Object and Energy Management Domain15 5.2. Energy Managed Object Identification and Context. 15 5.2.1 Identification .............................. 15 5.2.2 Context in General .......................... 16 5.2.3 Context: Importance ......................... 16 5.2.4 Context: Keywords............................ 17 5.2.5 Context: Role ............................... 18 5.3. Energy Managed Object Relationships.............. 18 5.3.1 Energy Managed Object Children Discovery .... 19 5.4. Energy Monitoring ............................... 19 5.5. Energy Control................................... 22 5.5.1 IEEE1621 Power State Series ................. 22 5.5.2 DMTF Power State Series...................... 23 5.5.3 EMAN Power State Series...................... 24 6. Structure of the Information Model: UML Representation 28 7. Configuration ........................................ 33 8. Fault Management ..................................... 34 9. Relationship with Other Standards Development Organizations............................................ 35 9.1. Information Modeling............................. 35 10. Security Considerations.............................. 35 10.1. Security Considerations for SNMP .................. 36 11. IANA Considerations ................................. 37 12. Acknowledgments ..................................... 37 13. References .......................................... 37 Normative References ................................. 37 Informative References ............................... 37 TO DO/OPEN ISSUE - IPFIX or not? Initially IPFIX was mentioned in [EMAN-REQ], then we see now: "A solution for this is that the concerned entity or another entity closely interacting with the concerned entity collect time series of power values and make them available via push or pull mechanisms to receivers of the information.". So, the questions are: Is IPFIX a requirement? What other mechanism do we have to PUSH time series of power Expires January 8, 2012 [Page 3] Internet-Draft July 2011 values (no, SNMP notifications are not suitable)? So should we or not include IPFIX in this document? - Power Monitor has been renamed to Energy Managed Object. Get consensus on the terminology. Another example is Power Quality - A couple of EDITOR'S NOTES in the draft 1. Introduction Network management is divided into the five main areas defined in the ISO Telecommunications Management Network model: Fault, Configuration, Accounting, Performance, and Security Management (FCAPS). Absent from this management model is any consideration of Energy Management, which is now becoming a critical area of concern worldwide as seen in [ISO50001]. This document defines a framework for providing Energy Management for devices within or connected to communication networks. The framework describes how to identity, classify and provide context for a device in a communications network from the point of view of Energy Management. The identified device can then be monitored for Energy Management by obtaining measurements for power, energy, demand and electrical quality. If a device contains a battery(s) the characteristics and performance of the battery(s) can also be managed. A device's state can be monitored or controlled by providing an interface expressed as one or more Power State Sets. The most basic example of energy management is a single device reporting information about itself. However, in many cases, energy is not measured by the device itself, but by a meter located upstream in the power distribution tree. An example is a power distribution unit (PDU) that measures energy consumption of attached devices and may report this to an Energy Management System. Therefore, devices are recognized as having relationships to other devices in the network from the point of view of Energy Management. These relationships include Aggregation, Metering, Power Source(s), Proxy, and Dependency. 1.1. Energy Management Document Overview The EMAN standard provides a set of specifications that together provide Energy Management. This document specifies the framework, per the Energy Management requirements specified in [EMAN-REQ] Expires January 8, 2012 [Page 4] Internet-Draft July 2011 The applicability statement document [EMAN-AS] provides a list of use cases, cross-reference between existing standards and the EMAN standard, and shows how the this relates to other frameworks. The [EMAN-AWARE-MIB] provides objects for addressing identification, classification, context information, and relationships form the point of view of Energy Management. The Power and Energy Monitoring MIB [EMAN-MON-MIB] contains objects for monitoring of Power, Energy, Demand, Electrical Quality and Power State Sets. Definition of Managed Objects for Battery Monitoring [EMAN- BATTERY-MIB] defines managed objects that provide information on the status of batteries in managed devices. EDITOR'S NOTE: [EMAN-MON-MIB] and [EMAN-AS] are not EMAN working group documents. Hence, these references will be changed in the future. 2. Requirements & Use Cases Requirements for power and energy monitoring for networking devices are specified in [EMAN-REQ]. The Energy Management use cases covered by this framework are covered in the EMAN applicability statement document in [EMAN-AS]. Typically requirements and use cases for communication networks cover the devices that make up the communication network and endpoints. With Energy Management, there exists a wide variety of devices that may be contained in the same deployments as a communication network but comprise a separate facility, home, or power distribution network. For example, target devices for this specification can include (but are not limited to): - Simple electrical appliances / fixtures - Hosts, such as a PC or a datacenter server - Routers - Switches - Switches with line card components - Power over Ethernet (PoE) endpoints, - Power Distribution Units (PDU) - Protocol gateways devices for Building Management Systems (BMS) - Electrical Meters Expires January 8, 2012 [Page 5] Internet-Draft July 2011 - Sensor controllers with subtended sensors There may also exist varying protocols deployed among these parallel networks. For an Energy Management framework to be useful, it should also apply to these types of separate networks as they connect and interact with a communications network. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This section contains definitions of terms used throughout this specification. Defined terms have their first letter capitalized. Entities, relationships and or capabilities are defined with respect to well known software patterns as described in [GAMMA] and [EIPATT] Energy Management System (EnMS) An EnMS is a set of systems or procedures upon which organizations can develop and implement an energy policy, set targets, action plans and take into account legal requirements related to energy use. An EnMS allows organizations to improve energy performance and demonstrate conformity to requirements, standards and/or legal requirements. This definition is in line with the definition of "Energy management systems - Requirements with guidance for use" [ISO50001]. With respect to communication networks these same goals will apply to the communications networks and attached devices within an organization. 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 Expires January 8, 2012 [Page 6] Internet-Draft July 2011 constraints of the organization. In that light, Energy Management is a system congruent to any of FCAPS area of management in the ISO/OSI Network Management Model [TMN] Energy Management for communication networks and attached devices is a subset or part of an organization's greater EnMS. Energy Management Systems An Energy Management System (EMS) is congruent to a Network Management System (NMS) and is a combination of hardware and software used to administer a network with the primarily purpose being Energy Management. Energy Monitoring Energy Monitoring is a part of Energy Management that deals with collecting or reading measurements from devices to aid in Energy Management. This could include Energy, Power, Demand, Quality, Context and/or Battery information. Energy Energy Energy is the capacity of a system to produce external activity or perform work and can be electricity, fuels, steam, heat, compressed air, and other like media. Energy is typically expressed in watt hours or joules. Power Power is a rate of energy conversion. As the unit of time approaches zero a power measurement is called an instantaneous power reading. Typically when implementing Power monitoring in hardware, a measuring device may have to compute an average value per some unit of time to express a reading to approximate an instantaneous power measurement. Demand Demand is an average of Power measurements over an interval(s) of time and typically expressed in kilowatt hours. This measurement is significant because some utilities or energy providers bill by Demand measurements as well as for maximum Expires January 8, 2012 [Page 7] Internet-Draft July 2011 Demand per billing periods. Power values may spike during short-terms by devices, but Demand measurements recognize that maximum Demand does not equal maximum Power during an interval. Power Quality EDITOR'S NOTE: This may be rephrased as Electrical Characteristics. Power Quality is defined as a set of values to describe the electrical characteristics of Power as provided by an electrical source as seen by the Energy Managed Object. For example: AC phase, apparent and reactive power, etc. Energy Control Energy Control is a part of Energy Management that deals with modifying or setting the state of an Energy Managed Object in order to optimize or ensure its efficiency. Energy Managed Object An Energy Managed Object (EMO) is a device that is part of or attached to a communications network that is monitored, controlled, or aids in the management of another device for Energy Management. Energy Aware Object An Energy Managed Object may not have the capability to provide information necessary for Energy Management itself. If an Energy Managed Object can provide Energy Management Context, Energy Monitor and optionally Energy Control values for itself then the Energy Managed Object is said to be an Energy Aware Object For example: as the most simplistic example, a set of light bulbs where all values are provided by an EMS through estimation and or catalogue information are not Energy Aware. In contrast a set of network switches that can report the same information based upon hardware sensing is said to be Energy Aware. Energy Managed Object Identification Expires January 8, 2012 [Page 8] Internet-Draft July 2011 Energy Managed Object Identification is a set of attributes that enable an Energy Managed Object to be: uniquely identified among all Energy Management Domains; linked to other systems; classified as to type model and or manufacturer. RFC EDITOR'S: the uniqueness must be clarified in [EMAN-REQ] Energy Managed Object Context Energy Managed Object Context is a set of attributes that allow an Energy Management system to classify the use of the Energy Managed Object within an organization. The classification contains use and/or ranking of the Energy Managed Object as compared to other Energy Managed Objects in the Energy Management Domain. Energy Management Domain An Energy Management Domain is a name or name space that logically groups Energy Managed Objects into a zone of Energy Management. Typically, this zone will have as members all Energy Managed Objects that are powered from the same electrical panel(s) for which there is a meter or sub meter. For example: All Energy Managed Objects drawing power from the same distribution panel with the same AC voltage within a building, or all Energy Managed Objects in a building for which there is one main meter, would comprise an Energy Management Domain. From the standpoint of Energy Management, it is useful to report Energy as the sum of the Energy of all the Energy Managed Objects within an Energy Management Domain and then correlate that value with metered values. Energy Managed Object Relationships Energy Managed Objects may have functional relationships to each other within an Energy Management Domain. The functional relationships include Aggregation, Metering, Power Source(s), Proxy, and Dependency. One device will provide a capability or functional value in the relationship and another will be the receiver of the capability. These capabilities include Aggregation, Metering, Power Source, Proxy and Dependency. Aggregation Relationship Expires January 8, 2012 [Page 9] Internet-Draft July 2011 An Energy Managed Object may aggregate the Energy Management information of one or more Energy Managed Objects and is referred to as an Aggregation Relationship. An Energy Managed Object may be aggregated by another Energy Managed Object(s). Aggregate values are obtained by reading values from multiple Energy Managed Objects and producing a single value of more significant meaning such as average, count, maximum, median, minimum, mode and most commonly sum. Metering Relationship An Energy Managed Object may measure the Energy of another Energy Managed Object(s) and is referred to as a Metering Relationship. An Energy Managed Object may be metered by another Energy Managed Object(s). Example: a PoE port on a switch measure the Power it provides to the connected Energy Managed Object. Power Source Relationship An Energy Managed Object may be the source of or distributor of power to another Energy Managed Object(s) and is referred to as a Power Source Relationship. An Energy Managed Object may be powered by another Energy Managed Object(s). Example: a PDU provides power for a connected host. Proxy Relationship An Energy Managed Object that provides Energy Management capabilities on behalf of another Energy Managed Object so that is appears to be Energy Aware is referred to a Proxy Relationship. An Energy Managed Object may be proxied by another Energy Managed Object(s). Example: a protocol gateways device for Building Management Systems (BMS) with subtended devices. Dependency Relationship An Energy Managed Object may be a component of or rely completely upon another Energy Managed Object to operate and is referred to as a Dependency Relationship. An Energy Managed Object may be dependent on another Energy Managed Object(s). Example: A Switch chassis with multiple line cards Energy Managed Object Parent Expires January 8, 2012 [Page 10] Internet-Draft July 2011 An Energy Managed Object Parent is an Energy Managed Object that provides one or more of the Energy Managed Object Relationships capabilities. Energy Managed Object Child An Energy Managed Object Child is an Energy Managed Object that has at least one Energy Managed Object Relationship capability provided by another Energy Managed Object. Power State A Power State is a way to classify a Power setting on an Energy Managed Object (e.g., on, off, or sleep). A Power State can be viewed as a method for Energy Control Manufacturer Power State A Manufacturer Power State is a device-specific way to classify a Power setting implemented on an Energy Managed Object. Power State Set A collection of Power States that comprise one named or logical grouping of control is a Power State Set. For example, the states {on, off, and sleep} as defined in [IEEE1621], or the 16 power states as defined by the [DMTF] can be considered two different Power State Sets. Nameplate Power The Nameplate Power is the maximal (nominal) Power that a device can support. This is typically determined via load testing and is specified by the manufacturer as the maximum value required to operate the device. This is sometimes referred to as the worst-case Power. The actual or average Power may be lower. The Nameplate Power is typically used for provisioning and capacity planning. 4. Energy Management Reference Model The scope of this framework is to enable network and network- attached devices to be administered for Energy Management. The framework recognizes that in complex deployments Energy Managed Expires January 8, 2012 [Page 11] Internet-Draft July 2011 Objects may communicate over varying protocols. For example the communications network may use IP Protocols (SNMP) but attached Energy Managed Object Parent may communicate to Energy Managed Object Children over serial communication protocols like BACNET, MODBUS etc. The likelihood of getting these different topologies to convert to a single protocol is not very high considering the rate of upgrades of facilities and energy related devices. Therefore the framework must address the simple case of a uniform IP network and a more complex mixed topology/deployment. As displayed in the Figure 1, the most basic energy reference model is composed of an Energy Management System (EMS) that obtains Energy Management information from Energy Managed Objects. The Energy Managed Object returns information for Energy Management directly to the EMS. The protocol of choice for Energy Management is SNMP, as three MIBs are specified for Energy Management: the energy-aware MIB [EMAN-AWARE-MIB], the energy monitoring MIB [EMAN-MON-MIB], and the battery MIB [EMAN-BATTERY-MIB]. However, the EMAN requirement document [EMAN-REQ] also require the push of time series of power values. Therefore, IPFIX [RFC5101] is also mentioned in the following figures. +---------------+ | EMS | - - +-----+---+-----+ ^ ^ | | | | | | |S |I +---------+ +----------+ |N |P | | |M |F | | |P |I +-----------------+ +--------+--------+ | |X | EMO 1 | ... | EMO N | v | +-----------------+ +-----------------+ - - Figure 1: Simple Energy Management As displayed in the Figure 2, a more complex energy reference model includes Energy Managed Object Parents and Children. The Energy Managed Object Parent returns information for themselves as well as information according to the Energy Managed Object Relationships. Expires January 8, 2012 [Page 12] Internet-Draft July 2011 +---------------+ | EMS | - - +-----+--+------+ ^ ^ | | | | | | |S |I +------------+ +--------+ |N |P | | |M |F | | |P |I +------------------+ +------+-----------+ | |X | EMO | | EMO | v | | Parent 1 | ... | Parent N | - - +------------------+ +------------------+ ||| . One or ||| . Multiple ||| . Enery Managed ||| . Object ||| . Relationship(s): ||| - Aggregation ||| +-----------------------+ - Metering |||------| EMO Child 1 | - Power Source || +-----------------------+ - Proxy || - Dependency || +-----------------------+ ||-------| EMO Child 2 | | +-----------------------+ | | |-------- ... | | | +-----------------------+ |--------| EMO Child M | +-----------------------+ Figure 2: Complex Energy Management Model While both the simple and complex Energy Management models contain an EMS, this framework doesn't impose any requirements regarding a topology with a centralize EMS or one with a distributed Energy Management via the Energy Managed Objects within the deployment. Expires January 8, 2012 [Page 13] Internet-Draft July 2011 Given the pattern in figure 2, the complex relationships between Energy Managed Objects can be modeled (refer also to section 5.3): - A PoE device modeled as an Energy Managed Object Parent with the Power Source, Metering, and Proxy Relationships for this powered device - A PDU modeled as an Energy Managed Object Parent with the Power Source and Metering for the plugged in host - A PC with line cards modeled as an Energy Managed Object Parent with Dependency Relationships for the line cards - Building management gateway, used as proxy for non IP protocols, is modeled as an Energy Managed Object Parent with the Proxy Relationship, and potentially the Aggregation Relationship - Etc. The communication between the Energy Managed Object Parent and Energy Managed Object Children is out of the scope of this framework. 5. Framework High Level Concepts and Scope Energy Management can be organized into areas of concern that include: - Energy Managed Object Identification and Context - for modeling and planning - Energy Monitoring - for energy measurements - Energy Control - for optimization - Energy Procurement - for optimization of resources The framework addresses Energy Management but excludes Energy Procurement and the environmental impact of energy use. As such the framework does not include: - Manufacturing costs of an Energy Managed Object in currency or environmental units - Embedded carbon or environmental equivalences of an Energy Managed Object - Cost in currency or environmental impact to dismantle or recycle an Energy Managed Object - Relationship or capabilities of an Energy Managed Object to an electrical or smart grid Expires January 8, 2012 [Page 14] Internet-Draft July 2011 - Supply chain analysis of energy sources or Energy Managed Object deployment - Conversion of the usage or production of energy to units expressed from the source of that energy (such as the greenhouse gas emissions associated with 1000kW from a diesel source). The next sections describe Energy Management organized into the following areas: - Energy Managed Object and Energy Management Domain - Energy Managed Object Identification and Context - Energy Managed Object Relationships - Energy Monitoring - Energy Control - Deployment Topologies 5.1. Energy Managed Object and Energy Management Domain An Energy Management Domain is a manageable set of devices that has a meter or sub-meter attached and typically corresponds to a power distribution point or panel. In building management, a meter refers to the meter provided by the utility used for billing and measuring power to an entire building or unit within a building. A sub-meter refers to a customer or user installed meter that is not used by the utility to bill but instead used to get readings from sub portions of a building. An Energy Management Domain should map 1-1 with a metered or sub-metered portion of the site. The Energy Management Domain should be configured on an Energy Managed Object. An Energy Managed Object Child may inherit the domain value from an Energy Managed Object Parent or the Energy Management Domain may be configured directly in an Energy Managed Object Child. 5.2. Energy Managed Object Identification and Context 5.2.1 Identification Energy Managed Objects MUST contain a value that uniquely identifies the Energy Managed Object among all the Energy Management Domains within an EnMS. It is recommended that a Expires January 8, 2012 [Page 15] Internet-Draft July 2011 universal identifier (UUID) be used to uniquely identify the Energy Managed Object. Every Energy Managed Object should have a unique printable name. Possible naming conventions are: textual DNS name, MAC-address of the device, interface ifName, or a text string uniquely identifying the Energy Managed Object. As an example, in the case of IP phones, the Energy Managed Object name can be the device DNS name. 5.2.2 Context in General In order to aid in reporting and in differentiation between Energy Managed Objects, each Energy Managed Object optionally contains information establishing its business, site, or organizational context within a deployment. 5.2.3 Context: Importance An Energy Managed Object can provide an importance value in the range of 1 to 100 to help differentiate a device's use or relative value to the site. The importance range is from 1 (least important) to 100 (most important). The default importance value is 1. For example: A typical office environment has several types of phones, which can be rated according to their business impact. A public desk phone has a lower importance (for example, 10) than a business-critical emergency phone (for example, 100). As another example: A company can consider that a PC and a phone for a customer-service engineer is more important than a PC and a phone for lobby use. Although Energy Management Systems and administrators can establish their own ranking, the following is a broad recommendation: . 90 to 100 Emergency response . 80 to 90 Executive or business-critical . 70 to 79 General or Average . 60 to 69 Staff or support Expires January 8, 2012 [Page 16] Internet-Draft July 2011 . 40 to 59 Public or guest . 1 to 39 Decorative or hospitality 5.2.4 Context: Keywords An Energy Managed Object can provide a set of keywords. These keywords are a list of tags that can be used for grouping and summary reporting within or between Energy Management Domains. All alphanumeric characters and symbols, such as #, (, $, !, and &, are allowed. Potential examples are: IT, lobby, HumanResources, Accounting, StoreRoom, CustomerSpace, router, phone, floor2, or SoftwareLab. There is no default value for a keyword. Multiple keywords can be assigned to a device. In such cases, the keywords are separated by commas and no spaces between keywords are allowed. For example, "HR,Bldg1,Private". Another keyword use case is the virtual grouping of Energy Managed Objects. For example, a Power Distribution Unit (PDU) that allows physical entities like outlets to be "ganged" together as a logical entity for simplified management purposes. This is particularly useful for servers with multiple power supplies, where each power supply is connected to a different physical outlet. Other implementations allow "gangs" to be created based on common ownership of outlets, such as business units or load shed priority or other non-physical relationships. For example, current PDU implementations allow for an "M-to-N" mapping between outlet "gangs" and physical outlets: Outlet 1 (physical entity) Outlet 2 (physical entity) Outlet 3 (physical entity) Outlet 4 (physical entity) Outlet Gang A (virtual entity) Outlet Gang B (virtual entity) Gang A -> Outlets 1, 2 and 3 Gang B -> Outlets 3 and 4 Expires January 8, 2012 [Page 17] Internet-Draft July 2011 Note the allowed overlap on Outlet 3, where Outlet 3 belongs to both "gangs". The keywords concept for this specific example would be used as such: Outlet 1 Energy Managed Object 1, keywords: gangA Outlet 2 Energy Managed Object 2, keywords: gangA Outlet 3 Energy Managed Object 3, keywords: gangA, gangB Outlet 4 Energy Managed Object 4, keywords: gangB Each "Outlet Gang" virtual entity, aggregated based on the value of the keywords, reports the aggregated data from the individual outlet entities that comprise it. The same concept enables a single point of control for all the individual outlet entities. For example, turning "Outlet Gang A" to the "off" state would turn outlets 1, 2, and 3 "off" in some implementations. Note that the impact of this action on "Outlet Gang B" is out of scope of this document. 5.2.5 Context: Role An Energy Managed Object can provide a "role description" string that indicates the purpose the Energy Managed Object serves in the EnMS. This could be a string describing the context the device fulfills in deployment. For example, a lighting fixture in a kitchen area could have a role of "Hospitality Lighting" to provide context for the use of the device. 5.3. Energy Managed Object Relationships An Energy Managed Object MAY be an Energy Managed Object Parent or Energy Managed Object Child of another Energy Managed Object. Energy Managed Objects establish a parent and child relationship when one Energy Managed Object provides capabilities for another Energy Managed Object. For Example: A Power-over-Ethernet (PoE) device (such as an IP phone or an access point) is attached to a switch port. The switch is the source of power for the attached device, so the Energy Managed Object Parent is the switch, and the Energy Managed Object Child is the device attached to the switch. Expires January 8, 2012 [Page 18] Internet-Draft July 2011 The communication between the parent and child for monitoring or collection of power data is left to the device manufacturer. For example: A parent switch may use LLDP to communicate with a connected child, and a parent lighting controller may use BACNET to communicate with child lighting devices. 5.3.1 Energy Managed Object Children Discovery There are multiple ways that the Energy Managed Object Parent can discover its Energy Managed Object Children, if they are not present on the same physical network: . In case of PoE, the Energy Managed Object Parent automatically discovers an Energy Managed Object Child when the Child requests power. . The Energy Managed Object Parent and Children may run the Link Layer Discovery Protocol [LLDP], or any other discovery protocol, such as Cisco Discovery Protocol (CDP). The Energy Managed Object Parent might even support the LLDP-MED MIB [LLDP-MED-MIB], which returns extra information on the Energy Managed Object Children. . The Energy Managed Object Parent may reside on a network connected facilities gateway. A typical example is a converged building gateway, monitoring several other devices in the building, and serving as a proxy between SNMP and a protocol such as BACNET. . Energy Managed Object Parent/Energy Managed Object Child relationships may be set by manual or automatic network configuration functions. Note that the communication specifications between the Energy Managed Object Parent and Children is out of the scope of this document. When an Energy Managed Object Parent is a Proxy, the Energy Managed Object Parent should enumerate the capabilities it is providing for the Energy Managed Object Child. The child would express that it wants its parent to proxy capabilities such as, energy reporting, power state configurations, non physical wake capabilities (such as WoL)), or any combination of capabilities. 5.4. Energy Monitoring For the purposes of this framework energy will be limited to electrical energy in watt hours. Other forms of Energy Managed Objects that use or produce non-electrical energy may be part of an Energy Management Domain but MUST provide information converted to and expressed in watt hours. Expires January 8, 2012 [Page 19] Internet-Draft July 2011 Each Energy Managed Object will have information that describes Power and Energy information along with how that measurement was obtained or derived. Optionally, an Energy Managed Object can further describe the power information with power quality information reflecting the electrical characteristics of the measurement. Optionally, an Energy Managed Object can provide Demand information over time Power Measurement A Power measurement must be qualified with the units, magnitude, direction of power flow, and by what means the measurement was made (ex: Root Mean Square versus Nameplate). In addition, the Energy Managed Object should describe how it intends to measure Power as one of consumer, producer or meter of usage. Given the intent readings can be summarized or analyzed by an EMS. For example metered usage reported by a meter and consumption usage reported by a device connected to that meter may naturally measure the same usage. With the two measurements identified by intent a proper summarization can be made by an EMS. Power measurement magnitude should conform to the IEC 61850 definition of unit multiplier for the SI (System International) units of measure. Measured values are represented in SI units obtained by BaseValue * 10 raised to the power of the scale. For example, if current power usage of an Energy Managed Object is 3, it could be 3 W, 3 mW, 3 KW, or 3 MW, depending on the value of the scaling factor. Electric energy is often billed in kilowatt-hours instead of megajoules from the SI units. Similarly, battery charge is often measured as miliamperes-hour (mAh) instead of coulombs from the SI units. The units used in this framework are: W, A, Wh, Ah, V. An conversion from Wh to Joule and from Ah to Coulombs is obviously possible, and can be described if required. In addition to knowing the usage and magnitude, it is useful to know how an Energy Managed Object usage measurement was obtained: . Whether the measurements were made at the device itself or from a remote source. Expires January 8, 2012 [Page 20] Internet-Draft July 2011 . Description of the method that was used to measure the power and whether this method can distinguish actual or estimated values. An EMS can use this information to account for the accuracy and nature of the reading between different implementations. The EMS can use the Nameplate Power for provisioning, capacity planning and potentially billing. Optional Power Quality Given a Power measurement it may in certain circumstances be desirable to know the electrical characteristics associated with that measurement. The information model must adhere to the IEC 61850 7-2 standard for describing AC measurements. In some Energy Management Domains, the power quality may not be needed, available, or relevant to the EMS. Optional Demand It is well known in commercial electrical utility rates that Demand is used as a measurement for billing. Also the highest peak demand measured over a time horizon, such as 1 month or 1 year, is often the basis for charges. A single window of time of high usage can penalize the consumer with higher energy consumption charges. However, it is relevant to measure the Demand only when there are actual power measurements from an Energy Managed Object, and not when the power measurement is assumed or predicted. Optional Battery Some Energy Managed Objects may use batteries for storing energy and for receiving power supply. These Energy Managed Objects should report their current power supply (battery, power line, etc.) and the battery status for each contained battery. Battery-specific information to be reported should include the number of batteries contained in the device and per battery . battery type . nominal and remaining capacity . current charge . current state (charging, discharging, not in use, etc.) Expires January 8, 2012 [Page 21] Internet-Draft July 2011 . number of charging cycles . expected remaining time that the battery can serve as power supply . expected remaining lifetime of the battery Beyond that a device containing a battery should be able to generate alarms when the battery charge falls below a given threshold and when the battery needs to be replaced. 5.5. Energy Control Energy Managed Objects can be controlled by setting it to a Power State. Sets of Power States can be seen as an interface by which an Energy Managed Object can be controlled. Each Energy Managed Object should indicate the Power State Sets that is implements. Well known Power State Sets should be registered with IANA When and individual Power State is configured from a specific Power State Set, an Energy Managed Object may be busy at the request time. The Energy Managed Object will set the desired state and then update the actual Power State when the priority task is finished. This mechanism implies two different Power State variables: actual versus desired There are several standards and implementations of Power State Set. An Energy Managed Object can support one or multiple Power State Set implementations concurrently. This framework list three initial possible Power State Series that can be supported by an Energy Managed Object: IEEE1621 - [IEEE1621] DMTF - [DMTF] EMAN - Specified here 5.5.1 IEEE1621 Power State Series The IEEE1621 Power State Series [IEEE1621] consists of 3 rudimentary states : on, off or sleep. on(0) - The device is fully On and all features of the device are in working mode. Expires January 8, 2012 [Page 22] Internet-Draft July 2011 off(1) - The device is mechanically switched off and does not consume energy. sleep(2) - The device is in a power saving mode, and some features may not be available immediately. 5.5.2 DMTF Power State Series DMTF [DMTF] standards organization has defined a power profile standard based on the CIM (Common Information Model) model that consists of 15 power states ON (2), SleepLight (3), SleepDeep (4), Off-Hard (5), Off-Soft (6), Hibernate(7), PowerCycle Off- Soft (8), PowerCycle Off-Hard (9), MasterBus reset (10), Diagnostic Interrupt (11), Off-Soft-Graceful (12), Off-Hard Graceful (13), MasterBus reset Graceful (14), Power-Cycle Off- Soft Graceful (15), PowerCycle-Hard Graceful (16). DMTF standard is targeted for hosts and computers. Details of the semantics of each Power State within the DMTF Power State Series can be obtained from the DMTF Power State Management Profile specification [DMTF]. DMTF power profile extends ACPI power states. The following table provides a mapping between DMTF and ACPI Power State Series and EMAN Power State Sets (described in the next section): State DMTF Power ACPI EMAN Power State State State Name Non-operational states: 1 Off-Hard G3, S5 MechOff 2 Off-Soft G2, S5 SoftOff 3 Hibernate G1, S4 Hibernate 4 Sleep-Deep G1, S3 Sleep 5 Sleep-Light G1, S2 Standby 6 Sleep-Light G1, S1 Ready Operational states: 7 On G0, S0, P5 LowMinus 8 On G0, S0, P4 Low 9 On G0, S0, P3 MediumMinus 10 On G0, S0, P2 Medium 11 On G0, S0, P1 HighMinus 12 On G0, S0, P0 High Figure 3: DMTF / ACPI Power State Mapping Expires January 8, 2012 [Page 23] Internet-Draft July 2011 5.5.3 EMAN Power State Series The EMAN Power State Series represents an attempt for a uniform standard approach to model the different levels of Power of a device. The EMAN Power States are an expansion of the basic Power States as defined in [IEEE1621] that also incorporate the Power States defined in [ACPI] and [DMTF]. Therefore, in addition to the non-operational states as defined in [ACPI] and [DMTF] standards, several intermediate operational states have been defined. There are twelve Power States, that expand on [IEEE1621] on,sleep and off. The expanded list of Power States are divided into six operational states, and six non-operational states. The lowest non-operational state is 1 and the highest is 6. Each non-operational state corresponds to an [ACPI] Global and System states between G3 (hard-off) and G1 (sleeping). For each operational state represent a performance state, and may be mapped to [ACPI] states P0 (maximum performance power) through P5 (minimum performance and minimum power). In each of the non-operational states (from mechoff(1) to ready(6)), the Power State preceding it is expected to have a lower Power value and a longer delay in returning to an operational state: IEEE1621 Power(off): mechoff(1) : An off state where no Energy Managed Object features are available. The Energy Managed Object is unavailable. No energy is being consumed and the power connector can be removed. This corresponds to ACPI state G3. softoff(2) : Similar to mechoff(1), but some components remain powered or receive trace power so that the Energy Managed Object can be awakened from its off state. In softoff(2), no context is saved and the device typically requires a complete boot when awakened. This corresponds to ACPI state G2. IEEE1621 Power(sleep) hibernate(3): No Energy Managed Object features are available. The Energy Managed Object may be awakened without requiring a complete boot, but the time for availability is longer than sleep(4). An example for state hibernate(3) is a save to-disk state where DRAM context is not maintained. Expires January 8, 2012 [Page 24] Internet-Draft July 2011 Typically, energy consumption is zero or close to zero. This corresponds to state G1, S4 in ACPI. sleep(4) : No Energy Managed Object features are available, except for out-of-band management, for example wake- up mechanisms. The time for availability is longer than standby(5). An example for state sleep(4) is a save-to-RAM state, where DRAM context is maintained. Typically, energy consumption is close to zero. This corresponds to state G1, S3 in ACPI. standby(5) : No Energy Managed Object features are available, except for out-of-band management, for example wake- up mechanisms. This mode is analogous to cold-standy. The time for availability is longer than ready(6). For example, the processor context is not maintained. Typically, energy consumption is close to zero. This corresponds to state G1, S2 in ACPI. ready(6) : No Energy Managed Object features are available, except for out-of-band management, for example wake- up mechanisms. This mode is analogous to hot-standby. The Energy Managed Object can be quickly transitioned into an operational state. For example, processors are not executing, but processor context is maintained. This corresponds to state G1, S1 in ACPI. IEEE1621 Power(on): lowMinus(7) : Indicates some Energy Managed Object features may not be available and the Energy Managed Object has selected measures/options to provide less than low(8) usage. This corresponds to ACPI State G0. This includes operational states lowMinus(7) to full(12). low(8) : Indicates some features may not be available and the Energy Managed Object has taken measures or selected options to provideless than mediumMinus(9) usage. mediumMinus(9): Indicates all Energy Managed Object features are available but the Energy Managed Object has taken measures or selected options to provide less than medium(10) usage. medium(10) : Indicates all Energy Managed Object features are available but the Energy Managed Object has taken measures or selected options to provide less than highMinus(11) usage. Expires January 8, 2012 [Page 25] Internet-Draft July 2011 highMinus(11): Indicates all Energy Managed Object features are available and power usage is less than high(12). high(12) : Indicates all Energy Managed Object features are available and the Energy Managed Object is consuming the highest power. Energy Managed Objects may have Manufacturer Power States Sets and can map these to the EMAN Power State Sets. The follow shows examples when Manufacturer Power State Sets have fewer or more states than the EMAN Power State Set A first example would be an imaginary device type, with only five states: "none", "short", "tall", "grande", and "venti". Manufacturer Power State Respective Name 0 none 1 short 2 tall 3 grande 4 venti Figure 4: Mapping Example 1 In the unlikely event that there is no possible mapping between these Manufacturer Power States and the proposed Energy Managed Object States, the Power State will remain 0 throughout, as displayed below. Power State / Name Manufacturer Power State / Name 0 / unknown 0 / none 0 / unknown 1 / short 0 / unknown 2 / tall 0 / unknown 3 / grande 0 / unknown 4 / venti Figure 5: Mapping Example 2 If a mapping between the Manufacturer Power States and the Energy Managed Object Power States is achievable, both series of states must exist in the MIB module in the Energy Managed Object Parent, allowing the EMS to understand the mapping between them by correlating the Power State with the Manufacturer Power States. Power State / Name Manufacturer Power State / Name 1 / MechOff 0 / none 2 / SoftOff 0 / none Expires January 8, 2012 [Page 26] Internet-Draft July 2011 3 / Hibernate 0 / none 4 / Sleep, Save-to-RAM 0 / none 5 / Standby 0 / none 6 / Ready 1 / short 7 / LowMinus 1 / short 8 / Low 1 / short 9 / MediumMinus 2 / tall 10 / Medium 2 / tall 11 / HighMinus 3 / grande 12 / High 4 / venti Figure 6: Mapping Example 3 How the Energy Managed Object States are then mapped is an implementation choice. However, it is recommended that the Manufacturer Power States map to the lowest applicable Power States, so that setting all Energy Managed Objects to a Power State would be conservative in terms of disabled functionality on the Energy Managed Object. A second example would be a device type, such as a dimmer or a motor, with a high number of operational states. For the sake of the example, 100 operational states are assumed. Power State / Name Manufacturer Power State / Name 1 / MechOff 0 / off 2 / SoftOff 0 / off 3 / Hibernate 0 / off 4 / Sleep, Save-to-RAM 0 / off 5 / Standby 1 / off 6 / Ready 2 / off 7 / LowMinus 11 / 1% 7 / LowMinus 12 / 2% 7 / LowMinus 13 / 3% . . . . . . 8 / Low 15 / 15% 8 / Low 16 / 16% 8 / Low 17 / 17% . . . . . . 9 / MediumMinus 30 / 30% 9 / MediumMinus 31 / 31% 9 / MediumMinus 32 / 32% . . Expires January 8, 2012 [Page 27] Internet-Draft July 2011 . . . . 10 / Medium 45 / 45% 10 / Medium 46 / 46% 10 / Medium 47 / 47% . . . . . . etc... Figure 7: Mapping Example 4 As specified in section 6, this framework allows the configuration of the Power State, while configuring the Manufacturer Power State from the MIB directly is not possible. 6. Structure of the Information Model: UML Representation EDITOR'S NOTE: right place here or in the appendix? The following basic UML represents an information model expression of the concepts in this framework. This information model, provided as a reference for implementers, is represented as an MIB in the different related IETF Energy Monitoring documents. However, other programming structure with different data models could be used as well. Notation is a shorthand UML with lowercase types considered platform or atomic types (i.e. int, string, collection). Uppercase types denote classes described further. Collections and cardinality are expressed via qualifier notation. Attributes labeled static are considered class variables and global to the class. Algorithms for class variable initialization, constructors or destructors are not shown Expires January 8, 2012 [Page 28] Internet-Draft July 2011 EMO RELATIONSHIPS AND CONTEXT +----------------------------+ | _Child Specific Info __ | |----------------------------| +---------------------------+ | parentId : UUID | | Context Information | | parentProxyAbilities | |---------------------------| | : bitmap | | roleDescription : string | | _mgmtMacAddress : octets | | keywords[0..n] : string | | mgmtAddress : inetaddress | | importance : int | | mgmtAddressType : enum | | category : enum | | mgmtDNSName : inetaddress | +---------------------------+ +----------------------------+ | | | | | | v v +-----------------------------------------+ | Energy Managed Object Information | |-----------------------------------------| | index : int | | powerMonitorId | UUID | | name : string | | meterDomainName | string | | alternateKey | string | +-----------------------------------------+ ^ | | | +-------------------------+ | Links Object | |-------------------------| | physicalEntity : int | | ethPortIndex : int | | ethPortGrpIndex : int | | lldpPortNumber : int | +-------------------------+ EMO AND MEASUREMENTS +-----------------------------------------------+ | Energy Managed Object | |-----------------------------------------------| Expires January 8, 2012 [Page 29] Internet-Draft July 2011 | nameplate : Measurement | | battery[0..n]: Battery | | measurements[0..n]: Measurement | | --------------------------------------------- | | Measurement instantaneousUsage() | | DemandMeasurement historicalUsage() | +-----------------------------------------------+ +-----------------------------------+ | Measurements | | __________________________________| +-----------------------------------+ ^ | | +------------------+----------------------------+ | PowerMeasurement | |-----------------------------------------------| | value : long | | rate : enum {0,millisecond,seconds, | | minutes,hours,...} | | multiplier : enum {-24..24} | | units : "watts" | | caliber : enum { actual, estimated, | | trusted, assumed...} | | accuracy : enum { 0..10000} | | current : enum {AC, DC} | | origin : enum { self, remote } | | time : timestamp | | quality : MeasurementQuality | +-----------------------------------------------+ +-----------------------------------------------+ | TimeMeasurement | |-----------------------------------------------| | startTime : timestamp | | usage : Measurement | | maxUsage : Measurment | +-----------------------------------------------+ +----------------------------------------+ | TimeInterval | |--------------------------------------- | |value : long | |units : enum { seconds, miliseconds..} | +----------------------------------------+ Expires January 8, 2012 [Page 30] Internet-Draft July 2011 +----------------------------------------+ | DemandMeasurement | |----------------------------------------| |intervalLength : TimeInterval | |intervalNumbers: long | |intervalMode : enum { period, sliding, | |total } | |intervalWindow : TimeInterval | |sampleRate : TimeInterval | |status : enum {active, inactive } | |measurements : TimedMeasurement[] | +----------------------------------------+ QUALITY +----------------------------------------+ | MeasurementQuality | |----------------------------------------| | | +----------------------------------------+ ^ | | +------------------+--------------------+ | ACQuality | |---------------------------------------| | acConfiguration : enum {SNGL, DEL,WYE}| | avgVoltage : long | | avgCurrent : long | | frequency : long | | unitMultiplier : int | | accuracy : int | | totalActivePower : long | | totalReactivePower : long | | totalApparentPower : long | | totalPowerFactor : long | +---------+-----------------------------+ | 1 | | | | +------------------------------------+ | | ACPhase | | * |------------------------------------| +--------+ phaseIndex : long | Expires January 8, 2012 [Page 31] Internet-Draft July 2011 | avgCurrent : long | | activePower : long | | reactivePower : long | | apparentPower : long | | powerFactor : long | +------------------------------------+ ^ ^ | | | | | | | | +-------------------------------+---+ | | DelPhase | | |-----------------------------------| | |phaseToNextPhaseVoltage : long | | |thdVoltage : long | | |thdCurrent : long | | +-----------------------------------+ | | +------------------+-----------+ | WYEPhase | |------------------------------| |phaseToNeutralVoltage : long | |thdCurrent : long | |thdVoltage : long | +------------------------------+ EMO & STATES +----------------------------------------------+ | Energy Managed Object | |----------------------------------------------| Expires January 8, 2012 [Page 32] Internet-Draft July 2011 | currentLevel : int | | configuredLevel : int | | configuredTime : timestamp | | reason: string | | manufacturerLevels[0..n]: State | | emanLevels[0..11] : State | | levelMappings[0..n] : LevelMapping | +----------------------------------------------+ +-------------------------------+ | State | |-------------------------------| | name : string | | cardinality : int | | maxUsage : Measurement | +-------------------------------+ +-----------------------------------------------+ | Level Mapping | |-----------------------------------------------| | emanLevelIndex: int | | manufacturerLevelIndex : int | +-----------------------------------------------+ 7. Configuration This power management framework allows the configuration of the following key parameters: . Energy Managed Object name: A unique printable name for the Energy Managed Object. . Energy Managed Object Role: An administratively assigned name to indicate the purpose an Energy Managed Object serves in the network. . Energy Managed Object Importance: A ranking of how important the Energy Managed Object is, on a scale of 1 to 100, compared with other Energy Managed Objects in the same Energy Management Domain. . Energy Managed Object Keywords: A list of keywords that can be used to group Energy Managed Objects for reporting or searching. . Energy Management Domain: Specifies the name of an Energy Management Domain for the Energy Managed Object. Expires January 8, 2012 [Page 33] Internet-Draft July 2011 . Energy Managed Object State: Specifies the current Power State (0..12) for the Energy Managed Object. . Demand parameters: For example, which interval length to report the Deman over, the number of intervals to keep, etc. . Assigning an Energy Managed Object Parent to an Energy Managed Object Child . Assigning an Energy Managed Object Child to an Energy Managed Object Parent. When an Energy Managed Object requires a mapping with the Manufacturer Power State, the Energy Managed Object configuration is done via the Power State settings, and not directly via the Manufacturer Power States, which are read-only. Taking into account Figure 7, where the LowMinus Power State corresponds to three different Manufacturer Power States (11 for 1%, 12 for 2%, and 13 for 3%), the implication is that this framework will not set the Manufacturer Power State to one percent granularity without communicating over or configuring the proprietary protocol for this Energy Managed Object. This framework supports multiple means for setting the Power State of a specific Energy Managed Object. However, the Energy Managed Object might be busy executing an important task that requires the current Power State for some more time. For example, a PC might have to finish a backup first, or an IP phone might be busy with a current phone call. Therefore a second value contains the actual Power State. A difference in values between the two objects indicates that the Energy Managed Object is currently in Power State transition. Other, already well established means for setting Power States, such as DASH [DASH], already exist. Such a protocol may be implemented between the Energy Managed Object Parent and the Energy Managed Object Child, when the Energy Managed Object Parent acts as a Proxy. Note that the Wake-up-on-Lan (WoL) mechanism allows to transition a device out of the Off Power State. 8. Fault Management [EMAN-REQ] specifies some requirements about power states such as "the current state - the time of the last change", "the total time spent in each state", "the number of transitions to each state", etc. Such requirements are fulfilled via the pmPowerStateChange NOTIFICATION-TYPE [EMAN-MON-MIB]. This SNMP Expires January 8, 2012 [Page 34] Internet-Draft July 2011 notification is generated when the value(s) of Power State has changed for the Energy Managed Object. 9. Relationship with Other Standards Development Organizations 9.1. Information Modeling This power management framework should, as much as possible, reuse existing standards efforts, especially with respect to information modeling and data modeling [RFC3444]. The data model for power, energy related objects is based on IEC 61850. Specific examples include: . The scaling factor, which represents Energy Managed Object usage magnitude, conforms to the IEC 61850 definition of unit multiplier for the SI (System International) units of measure. . The electrical characterisitc is based on the ANSI and IEC Standards, which require that we use an accuracy class for power measurement. ANSI and IEC define the following accuracy classes for power measurement: . IEC 62053-22 60044-1 class 0.1, 0.2, 0.5, 1 3. . ANSI C12.20 class 0.2, 0.5 . The electrical characteristics and quality adheres closely to the IEC 61850 7-2 standard for describing AC measurements. . The power state definitions are based on the DMTF Power State Profile and ACPI models, with operational state extensions. 10. Security Considerations Regarding the data attributes specified here, some or all may be considered sensitive or vulnerable in some network environments. Reading or writing these attributes without proper protection such as encryption or access authorization may have negative effects on the network capabilities. Expires January 8, 2012 [Page 35] Internet-Draft July 2011 10.1. Security Considerations for SNMP Readable objects in a MIB modules (i.e., objects with a MAX- ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control GET and/or NOTIFY access to these objects and possibly to encrypt the values of these objects when sending them over the network via SNMP. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. For example: . Unauthorized changes to the Power Domain or business context of an Energy Managed Object may result in misreporting or interruption of power. . Unauthorized changes to a power state may disrupt the power settings of the different Energy Managed Objects, and therefore the state of functionality of the respective Energy Managed Objects. . Unauthorized changes to the demand history may disrupt proper accounting of energy usage. With respect to data transport SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example, by using IPsec), there is still no secure control over who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in these MIB modules. It is recommended that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is not recommended. Instead, it is recommended to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of these MIB modules is properly configured to give access to the objects only to those principals (users) that have legitimate rights to GET or SET (change/create/delete) them. Expires January 8, 2012 [Page 36] Internet-Draft July 2011 11. IANA Considerations EDITOR'S NOTE: Add power states 12. Acknowledgments The authors would like to Michael Brown for improving the text dramatically, and Bruce Nordman for his excellent feedback. 13. References Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet Standard Management Framework ", RFC 3410, December 2002. [RFC5101] B. Claise, Ed., Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information, RFC 5101, January 2008. Informative References [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences between Information Models and Data Models", RFC 3444, January 2003. [ACPI] "Advanced Configuration and Power Interface Specification", http://www.acpi.info/spec30b.htm [IEEE1621] "Standard for User Interface Elements in Power Control of Electronic Devices Employed in Office/Consumer Environments", IEEE 1621, December 2004. [LLDP] IEEE Std 802.1AB, "Station and Media Control Connectivity Discovery", 2005. Expires January 8, 2012 [Page 37] Internet-Draft July 2011 [LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information Base extension module for TIA-TR41.4 media endpoint discovery information", July 2005. [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and M. Chandramouli, "Requirements for Energy Managed Objecting", draft-ietf-eman-requirements-03, (work in progress), June 2010. [EMAN-AWARE-MIB] Parello, J., and B. Claise, "Energy-aware Networks and Devices MIB", draft-ietf-eman-energy- aware-mib-01, (work in progress), March 2011. [EMAN-MON-MIB] Chandramouli, M.,Schoening, B., Quittek, J., Dietz, T., and B. Claise, "Power and Energy Monitoring MIB", draft-claise-energy-monitoring-mib-08, (work in progress), May 2011. [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, " Definition of Managed Objects for Battery Monitoring", draft-ietf-eman-battery-mib-02, (work in progress), July 2011. [EMAN-AS] Tychon, E., Laherty, M., and B. Schoening, "Energy Management (EMAN) Applicability Statement", draft- tychon-eman-applicability-statement-02, (work in progress), June 2011 [DASH] "Desktop and mobile Architecture for System Hardware", http://www.dmtf.org/standards/mgmt/dash/ [ISO50001] "ISO 50001:2011 Energy management systems - Requirements with guidance for use", http://www.iso.org/ [DMTF] "Power State Management Profile DMTF DSP1027 Version 2.0" December 2009 http://www.dmtf.org/sites/default/files/standards/docum ents/DSP1027_2.0.0.pdf [TMN] "TMN Management Functions : Performance Management.", ITU- T M.3400 [GAMMA] Eric Gamma et al. "Design Patterns: Element of Reusable Object-Oriented Software", 1994 Expires January 8, 2012 [Page 38] Internet-Draft July 2011 [EIPATT] Gregor Hohpe, Bobby Woolf, "Enterprise Integration Patterns: Designing Building and Deploying Messaging Solutions" 2004, http://eaipatterns.com/index.html Authors' Addresses Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1813 BE Phone: +32 2 704 5622 Email: bclaise@cisco.com John Parello Cisco Systems, Inc. 3550 Cisco Way San Jose, California 95134 US Phone: +1 408 525 2339 Email: jparello@cisco.com Brad Schoening 44 Rivers Edge Drive Little Silver, NJ 07739 US Phone: Email: brad@bradschoening.com Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511 15 EMail: quittek@netlab.nec.de Expires January 8, 2012 [Page 39] Internet-Draft July 2011 Expires January 8, 2012 [Page 40]