Network Working Group B. Claise Internet-Draft J. Parello Intended Status: Informational Cisco Systems, Inc. Expires: July 12, 2013 B. Schoening Independent Consultant J. Quittek NEC Europe Ltd. B. Nordman Lawrence Berkeley National Laboratory February 24, 2013 Energy Management Framework draft-ietf-eman-framework-07 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 July, 2013. Expires Jul 12 2013 [Page 1] Internet-Draft February 2013 Copyright Notice 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. Abstract This document defines a framework for providing Energy Management for devices and device components within or connected to communication networks. The framework defines an Energy Management Domain as a set of Energy Objects, for which each Energy Object is identified, classified and given context. Energy Objects can be monitored and/or controlled with respect to Power, Power State, Energy, Demand, Power Attributes, and Battery. Additionally the framework models relationships and capabilities between Energy Objects. Expires August, 2013 [Page 2] Internet-Draft February 2013 Table of Contents 1. Introduction .......................................... 5 2. Terminology ........................................... 6 Device................................................. 6 Component.............................................. 6 Energy Management...................................... 6 Energy Management System (EnMS)........................ 7 Power.................................................. 8 Demand................................................. 8 Power Attributes....................................... 8 Power Quality.......................................... 9 Electrical Equipment................................... 9 Non-Electrical Equipment (Mechanical Equipment)........ 9 Energy Object......................................... 10 Electrical Energy Object.............................. 10 Non-Electrical Energy Object.......................... 10 Energy Monitoring..................................... 10 Energy Control........................................ 10 Provide Energy:....................................... 10 Receive Energy:....................................... 11 Power Interface....................................... 11 Energy Management Domain.............................. 11 Energy Object Identification.......................... 11 Energy Object Context................................. 11 Energy Object Relationship............................ 12 Aggregation Relationship.............................. 12 Metering Relationship................................. 12 Power Source Relationship............................. 12 Proxy Relationship.................................... 12 Energy Object Parent.................................. 13 Energy Object Child................................... 13 Power State........................................... 13 Power State Set....................................... 13 Nameplate Power....................................... 13 3. Issues Specific to Energy Management ................. 13 3.1. Power Supply .................................... 15 3.2. Power and Energy Measurement .................... 20 3.3. Reporting Sleep and Off States .................. 21 3.4. Device and Device Components .................... 22 3.5. Non-Electrical Equipment ........................ 23 4. 4. Energy Management Abstraction ..................... 23 4.1. Energy Object and Energy Management Domain ...... 24 4.2. Power Interface ................................. 25 4.3. Energy Object Identification and Context ........ 25 4.4. Energy Object Relationships ..................... 27 4.5. Energy Monitoring ............................... 33 Expires August, 2013 [Page 3] Internet-Draft February 2013 4.6. Control ......................................... 35 4.7. Energy Management Reference Model................ 39 4.8 Using Device Relationships to Create Topologies... 40 4.9 Generalized Relationship Model.................... 47 5. Energy Management Information Model .................. 50 6. Example Topologies ................................... 56 6.1 Example I: Simple Device with one Source.......... 56 6.2 Example II: Multiple Inlets....................... 57 6.3 Example III: Multiple Sources..................... 58 7. Relationship with Other Standards .................... 58 8. Security Considerations .............................. 59 9. IANA Considerations .................................. 61 10. Acknowledgments ..................................... 61 11. References .......................................... 61 Normative References.................................. 61 Informative References................................ 62 OPEN ISSUES: Are Tracked via Issue Tracker. See https://trac.tools.ietf.org/wg/eman/trac/report/1 Expires August, 2013 [Page 4] Internet-Draft February 2013 1. Introduction Network management is often divided into the five main areas defined in the ISO Telecommunications Management Network model: Fault, Configuration, Accounting, Performance, and Security Management (FCAPS) [X.700]. Not covered by this management model is 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 identify, classify and provide context for such devices. The devices, or components of these devices, can then be monitored and controlled. Monitoring includes power, energy, demand, and attributes of power. Control for energy can be achieved by setting devices or components power state. If a device contains batteries, these can be also be monitored and controlled. 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 supplied to attached devices and reports this to an energy management system. Therefore, devices and their components are recognized as having relationships to other devices or components in the network from the point of view of energy management. There are further relationships between devices and components, respectively, including aggregation relationship, metering relationship, power source relationship, and proxy relationship. Energy Management Documents Overview The EMAN standard provides a set of specifications for Energy Management. This document specifies the framework, per the Energy Management requirements specified in [EMAN-REQ]. The applicability statement document [EMAN-AS] provides a list of use cases, a cross-reference between existing standards and the EMAN standard, and shows how this framework relates to other frameworks. Expires August, 2013 [Page 5] Internet-Draft February 2013 The Energy Object Context MIB [EMAN-OBJECT-MIB] specifies objects for addressing Energy Object Identification, classification, context information, and relationships from the point of view of Energy Management. The Power and Energy Monitoring MIB [EMAN-MON-MIB] contains objects for monitoring of Power, Energy, Demand, Power Attributes and Power States. Further, the battery monitoring MIB [EMAN-BATTERY-MIB] defines managed objects that provide information on the status of batteries in managed devices. 2. 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]. Some terms have a NOTE that is not part of the definition itself, but is present to take into account differences between terminologies of different standards organizations or to add a comment to help clarify the definition. Device A piece of electrical or non-electrical equipment. Reference: Adapted from [IEEE100] Component A part of an electrical or non-electrical equipment (Device). Reference: Adapted from [ITU-T-M-3400] 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 Expires August, 2013 [Page 6] Internet-Draft February 2013 appropriate for the nature of the application and the cost constraints of the organization. Reference: Adapted from [ITU-T-M-3400] NOTES: 1. Energy management refers to the activities, methods, procedures and tools that pertain to measuring, modeling, planning, controlling and optimizing the use of energy in networked systems [NMF]. 2. Energy Management is a management domain which is congruent to any of FCAPS areas 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 Energy Management Policies. Energy Management System (EnMS) An Energy Management System is a combination of hardware and software used to administer a network with the primary purpose being Energy Management. Reference: Adapted from [1037C] NOTES: 1. An Energy Management System according to [ISO50001] (ISO-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 ISO- EnMS allows organizations to improve energy performance and demonstrate conformity to requirements, standards, and/or legal requirements. 2. Example ISO-EnMS: Company A defines a set of policies and procedures indicating there should exist multiple computerized systems that will poll energy from their meters and pricing / source data from their local utility. Company A specifies that their CFO should collect information and summarize it quarterly to be sent to an accounting firm to produce carbon Expires August, 2013 [Page 7] Internet-Draft February 2013 accounting reporting as required by their local government. 3. For the purposes of EMAN, the definition from [1037C] is the preferred meaning of an Energy Management System (EnMS). The definition from [ISO50001] can be referred to as ISO Energy Management System (ISO-EnMS). 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). Reference: [IEEE100] NOTES 1. Energy is the capacity of a system to produce external activity or perform work [ISO50001] Power The time rate at which energy is emitted, transferred, or received; usually expressed in watts (joules per second). Reference: [IEEE100] Demand The average value of power or a related quantity over a specified interval of time. Note: Demand is expressed in kilowatts, kilovolt-amperes, kilovars, or other suitable units. Reference: [IEEE100] NOTES: 1. For EMAN we use kilowatts. Power Attributes Measurements of the electrical current, voltage, phase and frequencies at a given point in an electrical power system. Expires August, 2013 [Page 8] Internet-Draft February 2013 Reference: Adapted from [IEC60050] NOTES: 1. Power Characteristics is not intended to be judgmental with respect to a reference or technical value and are independent of any usage context. Power Quality Characteristics of the electric current, voltage, phase and frequencies at a given point in an electric power system, evaluated against a set of reference technical parameters. These parameters might, in some cases, relate to the compatibility between electricity supplied in an electric power system and the loads connected to that electric power system. Reference: [IEC60050] NOTES: 1. Electrical characteristics representing power quality information are typically required by customer facility energy management systems. It is not intended to satisfy the detailed requirements of power quality monitoring. Standards typically also give ranges of allowed values; the information attributes are the raw measurements, not the "yes/no" determination by the various standards. Reference: [ASHRAE-201] Electrical Equipment A general term including materials, fittings, devices, appliances, fixtures, apparatus, machines, etc., used as a part of, or in connection with, an electric installation. Reference: [IEEE100] Non-Electrical Equipment (Mechanical Equipment) A general term including materials, fittings, devices appliances, fixtures, apparatus, Expires August, 2013 [Page 9] Internet-Draft February 2013 machines, etc., used as a part of, or in connection with, non-electrical power installations. Reference: Adapted from [IEEE100] Energy Object An Energy Object (EO) is a piece of equipment 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. Electrical Energy Object An Electrical Energy Object (EEO) is an Energy Object that is a piece of Electrical Equipment Non-Electrical Energy Object A Non-Electrical Energy Object (NEEO) an Energy Object that is a piece of Non-Electrical Equipment. Energy Monitoring Energy Monitoring is a part of Energy Management that deals with collecting or reading information from Energy Objects to aid in Energy Management. Energy Control Energy Control is a part of Energy Management that deals with directing influence over Energy Objects. Provide Energy: An Energy Object "provides" energy to another Energy Object if there is an energy flow from this Energy Object to the other one. Expires August, 2013 [Page 10] Internet-Draft February 2013 Receive Energy: An Energy Object "receives" energy from another Energy Object if there is an energy flow from the other Energy Object to this one. Power Interface A Power Interface (or simply interface) is an interconnection among devices or components where energy can be provided, received, or both. Power Inlet A Power Inlet (or simply inlet) is an interface at which a device or component receives energy from another device or component. Power Outlet A Power Outlet (or simply outlet) is an interface at which a device or component provides energy to another device or component. Energy Management Domain An Energy Management Domain is a set of Energy Objects that is considered one unit of management. Energy Object Identification Energy Object Identification is a set of attributes that enable an Energy Object to be universally unique or linked to other systems. Energy Object Context Energy Object Context is a set of attributes that allow an Energy Management System to classify the Energy Object within an organization. Expires August, 2013 [Page 11] Internet-Draft February 2013 Energy Object Relationship An Energy Object Relationship is an association among Energy Objects NOTES 1. Relationships can be named and could include Aggregation, Metering, Power Source, and Proxy. Reference: Adapted from [CHEN] Aggregation Relationship An Aggregation Relationship is an Energy Object Relationship where one Energy Object aggregates Energy Management information of one or more other Energy Objects. The aggregating Energy Object has an Aggregation Relationship with each of the other Energy Objects. Metering Relationship A Metering Relationship is an Energy Object Relationship where one Energy Object measures power, energy, demand or power attributes of one or more other Energy Objects. The measuring Energy Object has a Metering Relationship with each of the measured objects. Power Source Relationship A Power Source Relationship is an Energy Object Relationship where one Energy Object provides power to one or more Energy Objects. These Energy Objects are referred to as having a Power Source Relationship. Proxy Relationship A Proxy Relationship is an Energy Object Relationship where one Energy Object provides the Energy Management capabilities on behalf of one or more other Energy Objects. These Energy Objects are referred to as having a Proxy Relationship. Expires August, 2013 [Page 12] Internet-Draft February 2013 Energy Object Parent An Energy Object Parent is an Energy Object that participates in an Energy Object Relationship and is considered as providing the capabilities in the relationship. Energy Object Child An Energy Object Child is an Energy Object that participates in an Energy Object Relationships and is considered as receiving the capabilities in the relationship. Power State A Power State is a condition or mode of a device that broadly characterizes its capabilities, power consumption, and responsiveness to input. Reference: Adapted from [IEEE1621] Power State Set A collection of Power States that comprise a named or logical grouping of control is a Power State Set. Nameplate Power The Nameplate Power is the nominal Power of a device as specified by the device manufacturer. 3. Issues Specific to Energy Management 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. Expires August, 2013 [Page 13] Internet-Draft February 2013 Target devices for Energy Management are all Energy Objects that can directly or indirectly be monitored or controlled by an Energy Management System (EnMS) using the Internet protocol, for example: - Simple electrical appliances / fixtures - Hosts, such as a PC, a server, or a printer - switches, routers, base stations, and other network equipment and middleboxes - A component within devices, such as a battery inside a PC, a line card inside a switch, etc... - Power over Ethernet (PoE) endpoints - Power Distribution Units (PDU) - Protocol gateway devices for Building Management Systems (BMS) - Electrical meters - Sensor controllers with subtended sensors There may also exist varying protocols deployed among these power distributions and communication networks. An Energy Management framework should also apply to these types of separate networks as they connect and interact with a communications network. This section explains special issues of Energy Management particularly concerning power supply, Power, and Energy metering, and the reporting of Power States. Energy Management has particular challenges in that a power distribution network is used for the supply of energy to various devices and components, while a separate communication network is typically used to monitor and control the power distribution network. To illustrate the issues we start with a simple and basic scenario where a single powered device receives Energy and reports energy-related information about itself to an Energy Management System (EnMS), see Figure 1 +--------------------------+ | Energy Management System | +--------------------------+ ^ ^ monitoring | | control v v Expires August, 2013 [Page 14] Internet-Draft February 2013 +-----------------+ | powered device | +-----------------+ Figure 1: Basic energy management scenario The powered device may have local energy control mechanisms, for example putting itself into a sleep mode when appropriate, and it may receive energy control commands for similar purposes from the EnMS. Information reported from a powered device to the EnMS includes at least the Power State of the powered device (on, sleep, off, etc.). This and similar cases are well understood and likely to become very common for Energy Management. They can be handled with well established and standardized management procedures. The only missing components today are standardized information and data models for reporting and configuration, such as, for example, energy-specific MIB modules [RFC2578] and YANG modules [RFC6020]. However, the nature of energy supply and use introduces some issues that are special to Energy Management. The following subsections address these issues and illustrate them by extending the basic scenario in Figure 1. WRT to Energy management there nothing new for faults, config, performance or security management. We can re-use those aspects of network management for an EnMS. But when there are aspects specific to EM then this framework adds them. For example with faults we can re-use rmon or snmp traps. For security existing means like SNMPv3 security can be used. 3.1. Power Supply A powered device may supply itself with power. Sensors, for example, commonly have batteries or harvest Energy. However, most powered devices that are managed by an EnMS receive external power. While many devices receive Power from unmanaged supply systems, the number of manageable power supply devices is increasing. In datacenters, for example, many Power Distribution Units (PDUs) allow the EnMS to switch power individually for each socket and also to measure the provided Power. This is an Expires August, 2013 [Page 15] Internet-Draft February 2013 action much different from many other network management tasks: In such and similar cases, switching power supply for a powered device or monitoring its power is not done by communicating with the actual powered device itself, but with an external device (in this case, the PDU Consequently, a standard for Energy Management must not just cover the powered devices that provide services for users, but also the power supply devices (which are powered devices as well) that monitor or control the power supply for other powered devices. A simple device such as a light bulb can be switched on or off only by switching its power supply. More complex devices may have the ability to switch off themselves or to bring themselves to states in which they consume very little power. For these devices as well, it is desirable to monitor and control their power supply. This extends the basic scenario from Figure 1 by a power supply device, see Figure 2. +-----------------------------------------+ | energy management system | +-----------------------------------------+ ^ ^ ^ ^ monitoring | | control monitoring | | control v v v v +--------------+ +-----------------+ | power supply |########| powered device | +--------------+ +-----------------+ ######## power supply line Figure 2: Power Supply The power supply device can be as simple as a plain power switch. It may offer interfaces to the EnMS to monitor and to control the status of its power outlets, as with PDUs and Power over Ethernet (PoE) [IEEE-802.3at] switches. The relationship between supply devices and the powered devices they serve creates several problems for managing power supply: o Identification of corresponding devices * A given powered device may be need to identify the supplying power supply device. Expires August, 2013 [Page 16] Internet-Draft February 2013 * A given power supply device may need to identify the corresponding supplied powered device(s). o Aggregation of monitoring and control for multiple powered devices * A power supply device may supply multiple powered devices with a single power supply line. o Coordination of power control for devices with multiple power inlets * A powered device may receive power via multiple power lines controlled by the same or different power supply devices. Identification of Power Supply and Powered Devices When a power supply device controls or monitors power supply at one of its power outlets, the effect on other devices is not always clear without knowledge about wiring of power lines. The same holds for monitoring. The power supplying device can report that a particular socket is powered, and it may even be able to measure power and conclude that there is a consumer drawing power at that socket, but it may not know which powered device(s)receives the provided power. In many cases it is obvious which other device is supplied by a certain outlet, but this always requires additional (reliable) information about power line wiring. Without knowing which device(s) are powered via a certain outlet, monitoring data are of limited value and the consequences of switching power on or off may be hard to predict. Even in well organized operations, powered devices' power cords can be plugged into the wrong socket, or wiring plans changed without updating the EnMS accordingly. For reliable monitoring and control of power supply devices, additional information is needed to identify the device(s) that receive power provided at a particular monitored and controlled socket. This problem also occurs in the opposite direction. If power supply control or monitoring for a certain device is needed, then the supplying power supply device has to be identified. To conduct Energy Management tasks for both power supply devices and other powered devices, sufficiently unique identities are needed, and knowledge of their power supply relationship is required. Expires August, 2013 [Page 17] Internet-Draft February 2013 Multiples Devices Supplied by a Single Power Line The second fundamental problem is the aggregation of monitoring and control that occurs when multiple powered devices are supplied by a single power supply line. It is often required for the EnMS to discover the full list of powered devices connected to a power supply line, as in Figure 3. +---------------------------------------+ | energy management system | +---------------------------------------+ ^ ^ ^ ^ monitoring | | control monitoring | | control v v v v +--------+ +------------------+ | power |########| powered device 1 | | supply | # +------------------+-+ +--------+ #######| powered device 2 | # +------------------+-+ #######| powered device 3 | +------------------+ Figure 3: Multiple Powered Devices Supplied by Single Power Line With this list, the single status value has clear meaning and is the sum of all powered devices. Control functions are limited by the fact that supply for the concerned devices can only be switched on or off for all of them at once. Individual control at the supply is not possible. If the full list of devices powered by a single supply line is not known by the controlling power supply device, then control of power supply is problematic, because the consequences of control actions can only be partially known. Multiple Power Supply for a Single Powered Device The third problem arises from the fact that there are devices with multiple power supplies. Some have this for redundancy of power supply, some for just making internal power converters (for example, from AC mains power to DC internal Expires August, 2013 [Page 18] Internet-Draft February 2013 power) redundant, and some because the capacity of a single supply line is insufficient. +----------------------------------------------+ | energy management system | +----------------------------------------------+ ^ ^ ^ ^ ^ ^ mon. | | ctrl. mon. | | ctrl. mon. | | ctrl. v v v v v v +----------+ +----------+ +----------+ | power |######| powered |######| power | | supply 1 |######| device | | supply 2 | +----------+ +----------+ +----------+ Figure 4: Multiple Power Supply for Single Powered Device The example in Figure 4 does not necessarily show a real world scenario, but it shows the two cases to consider: o multiple power supply lines between a single power supply device and a powered device o different power supply devices supplying a single powered device In any such case there may be a need to identify the supplying power supply device individually for each power inlet of a powered device. Without this information, monitoring and control of power supply for the powered device may be limited. Bidirectional Power Interfaces Some power technologies (mostly low power DC) allow power to be delivered bi-directionally. In the example, energy stored in batteries on one device can be delivered back to a power hub which redirects the power to another device. In this situation, the interface can function as both an inlet and outlet (at different times). A Power Interface can model a power inlet or a power outlet, depending on the conditions. Information of interest Power Interfaces include the power direction, as well as the energy received, provided, and the net result. Expires August, 2013 [Page 19] Internet-Draft February 2013 Relevance of Power Supply Issues In some scenarios, the problems with power supply do not exist or can be sufficiently solved. With Power over Ethernet (PoE) [IEEE-802.3at], there is always a one-to-one relationship between a Power Sourcing Equipment (PSE) and a Powered Device (PD). Also, the Ethernet link on the line used for powering can be used to identify the PD and in many cases also the PSE. For supply of AC mains power, the three problems described above cannot be solved in general. There is no commonly available protocol or automatic mechanism for identifying endpoints of a power line. And, AC power lines support supplying multiple powered devices with a single line and commonly do. Remote Power Supply Control There are three ways for an energy management system to change the Power State of powered devices. First is for the EnMS to provide policy or other useful information (like the electricity price) to the powered device for it to use in determining its Power State. The second is sending the powered devices a command to switch to another Power State. The third is to utilize an upstream device (to the powered device) that has capabilities to switch on and off power at its outlet. Some devices do not have capabilities for receiving commands or changing their Power States by themselves. Such Energy Objects may be controlled by switching on and off the power supply for them and so have particular need for the third method. In Figure 4, the power supply can switch on and off power at its power outlet and thereby switch on and off power supply for the connected powered device. 3.2. Power and Energy Measurement Some devices include hardware to directly measure their Power and Energy consumption. However, most common networked devices do not provide an interface that gives access to Energy and Power measurements. Hardware instrumentation for Expires August, 2013 [Page 20] Internet-Draft February 2013 this kind of measurements is typically not in place and adding it incurs an additional cost. With the increasing cost of Energy and the growing importance of Energy Monitoring, it is expected that in future more devices will include instrumentation for power and energy measurements, but this may take quite some time. Local Estimates One solution to this problem is for the powered device to estimate its own Power and consumed Energy. For many Energy Management tasks, getting an estimate is much better than not getting any information at all. Estimates can be based on actual measured activity level of a device or it can just depend on the power state (on, sleep, off, etc.). An advantage of estimates is that they can be realized locally and with much lower cost than hardware instrumentation. Local estimates can be dealt with in traditional ways. They don't need an extension of the basic scenarios above. However, the powered device needs an energy model of itself to make estimates. Management System Estimates Another approach to the lack of instrumentation is estimation by the EnMS. The EnMS can estimate Power based on basic information on the powered device, such as the type of device, or also its brand/model and functional characteristics. Energy estimates can combine the typical power level by Power State with reported data about the Power State. If the EnMS has a detailed energy model of the device, it can produce better estimates including the actual power state and actual activity level of the device. Such information can be obtained by monitoring the device with conventional means of performance monitoring. 3.3. Reporting Sleep and Off States Low power modes pose special challenges for energy reporting because they may preclude a device from listening to and responding to network requests. Devices may still be able to reliably track energy use in these modes, as power levels are Expires August, 2013 [Page 21] Internet-Draft February 2013 usually static and internal clocks can track elapsed time in these modes. Some devices have out-of-band or proxy abilities to respond to network requests in low-power modes. Others could use proxy abilities in an energy management protocol to improve this reporting, particularly if the powered device sends out notifications of power state changes. 3.4. Device and Device Components While the typical focus of energy management is entire powered devices, sometimes it is desirable to manage individual components of devices, such as line cards, fans, disks, etc. This framework uses a much simpler model for components than for entire devices. The concept of Power Interfaces is not used between a device and its contained components. Reporting of energy-related quantities for individual components is limited to the most important ones. Simplifications for components in this framework include o identifying components like devices but without distinct context information, o reporting a containment relationship to the containing device, o inheriting all context information from the containing device, o not modeling power interfaces and power lines between the a component and its containing device or other components, o only reporting real power and energy values for components, o supporting power state monitoring and control for components. In rare cases where there is a need to model components of a device in more detail, components of a device can be modeled as an individual device. Then all considerations for devices also apply to these components. The overhead of this model is higher and it should be applied only when needed. If used, it is not necessarily visible whether or not a set of components belongs to a single device, but for energy management purposes this might not be of high relevance. Expires August, 2013 [Page 22] Internet-Draft February 2013 3.5. Non-Electrical Equipment The primary focus of this framework is for the management of Electrical Equipment. Some Non-Electrical Equipment may be connected to a communication networks and could have their energy managed if normalized to the electrical units for power and energy. Some examples of Non-Electrical Equipment that may be connected to a communication network are: 1) A controller for compressed air. The controller is electrical only for its network connection. The controller is fueled by natural gas and produces compressed air. The energy transferred via compressed air is distributed to devices on a factory floor via a Power Interface: tools (drills, screwdrivers, assembly line conveyor belts). The energy measured is non-electrical (compressed air). 2) A controller for steam. The controller is electrical for its network attachment but it burns tallow and produces steam to subtended boilers. The energy is non-electrical (steam). 3) A controller or regulator for gas. The controller is electrical for its network attachment but it has physical non-electrical components for control. The energy is non- electrical (BTU). 4. Energy Management Abstraction Energy Management can be organized into areas of concern that include: - Energy Object Identification and Context - for modeling and planning - Energy Monitoring - for energy measurements - Energy Control - for optimization - Energy Procurement - for optimization of resources While an EnMS may be a central point for corporate reporting, cost, environmental impact, and regulatory compliance, Energy Management in this framework excludes Energy procurement and the environmental impact of energy use. As such the framework does not include: - Manufacturing costs of an Energy Object in currency or environmental units - Embedded carbon or environmental equivalences of an Energy Object Expires August, 2013 [Page 23] Internet-Draft February 2013 - Cost in currency or environmental impact to dismantle or recycle an Energy Object - Supply chain analysis of energy sources for Energy 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 Object and Energy Management Domain - Energy Object Identification and Context - Energy Object Relationships - Energy Monitoring - Energy Control - Deployment Topologies 4.1. Energy Object and Energy Management Domain A meter is a type of device and any device can perform metering. 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 can be any collection of devices in a building but is recommended to map 1:1 with a metered or sub-metered portion of the site. An Energy Object is part of a single Energy Management Domain. The Energy Management Domain MAY be configured on an Energy Object: the default value is a zero-length string. If all Energy Objects in the physical containment tree (see ENTITY-MIB) are part of the same Energy Management Domain, then it is safe to state that the Energy Object at the root of that containment tree is in that Energy Management Domain. An Energy Object Child may inherit the domain value from an Energy Object Parent or the Energy Management Domain may be configured directly in an Energy Object Child. Expires August, 2013 [Page 24] Internet-Draft February 2013 4.2. Power Interface There are some similarities between Power Interfaces and network interfaces. A network interface can be used in different modes, such as sending or receiving on an attached line. The Power Interface can be receiving or providing power. Most Power Interfaces never change their mode, but as the mode is simply a recognition of the current direction of electricity flow, there is no barrier to a mode change. A power interface can have capabilities for metering power and other electric quantities at the shared power transmission medium. This capability is modeled by an association to a power meter. In analogy to MAC addresses of network interfaces, a globally unique identifier is assigned to each Power Interface. Physically, a Power Interface can be located at an AC power socket, an AC power cord attached to a device, an 8P8C (RJ45) PoE socket, etc. 4.3. Energy Object Identification and Context Energy Object Identification A Universal Unique Identifier (UUID) [RFC4122] MUST be used to uniquely and persistently identify an Energy Object. Ideally the UUID should be used to distinguish the Energy Object among all Energy Management Domains within the EnMS. Every Energy Object SHOULD have a unique printable name within the Energy Management Domain. Possible naming conventions are: textual DNS name, MAC-address of the device, interface ifName, or a text string uniquely identifying the Energy Object. As an example, in the case of IP phones, the Energy Object name can be the device's DNS name. Expires August, 2013 [Page 25] Internet-Draft February 2013 Context in General In order to aid in reporting and in differentiation between Energy Objects, each Energy Object optionally contains information establishing its business, site, or organizational context within a deployment, i.e. the Energy Object Context. Context: Importance An Energy Object can provide an importance value in the range of 1 to 100 to help rank 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 EnMS and administrators can establish their own ranking, the following is a broad recommendation [CISC0-EW]: . 90 to 100 Emergency response . 80 to 90 Executive or business-critical . 70 to 79 General or Average . 60 to 69 Staff or support . 40 to 59 Public or guest . 1 to 39 Decorative or hospitality Context: Keywords An Energy Object can provide a set of keywords. These keywords are a list of tags that can be used for grouping, summary reporting within or between Energy Management Domains, and for searching. All alphanumeric characters and symbols (other than a comma), 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. White spaces before and after the commas are excluded, as well as within a Expires August, 2013 [Page 26] Internet-Draft February 2013 keyword itself. In such cases, the keywords are separated by commas and no spaces between keywords are allowed. For example, "HR,Bldg1,Private". Context: Role An Energy Object can provide a "role description" string that indicates the purpose the Energy Object serves in the EnMS. This could be a string describing the context the device fulfills in deployment. Administrators can define any naming scheme for the role of a device. As guidance a two-word role that combines the service the device provides along with type can be used [IPENERGY] Example types of devices: Router, Switch, Light, Phone, WorkStation, Server, Display, Kiosk, HVAC. Example Services by Line of Business: Line of Business Service Education Student, Faculty, Administration, Athletic Finance Trader, Teller, Fulfillment Manufacturing Assembly, Control, Shipping Retail Advertising, Cashier Support Helpdesk, Management Medical Patient, Administration, Billing Role as a two-word string: "Faculty Desktop", "Teller Phone", "Shipping HVAC", "Advertising Display", "Helpdesk Kiosk", "Administration Switch". 4.4. Energy Object Relationships Two Energy Objects MAY establish an Energy Object Relationship. Within a relationship one Energy Object becomes an Energy Object Parent while the other becomes an Energy Object Child. The Power Source Relationship gives a view of wiring topology. For example: a data center server receiving power from two specific Power Interfaces from two different PDUs. Expires August, 2013 [Page 27] Internet-Draft February 2013 Note: A power source relationship may or may not change as the direction of power changes between two Energy Objects. The relationship may remain to indicate the change of power direction was unintended or an error condition. The Metering Relationship gives the view of the metering topology. Standalone meters can be placed anywhere in a power distribution tree. For example, utility meters monitor and report accumulated power consumption of the entire building. Logically, the metering topology overlaps with the wiring topology, as meters are connected to the wiring topology. A typical example is meters that clamp onto the existing wiring. The Proxy Relationship allows software objects to be inserted into the wiring or metering topology to aid in management (monitoring and/or control). In many situations, the wiring, metering, and management topologies overlap. 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 port is the source of power for the attached device, so the Energy Object Parent is the switch port, which is a Power Interface, and the Energy Object Child is the device attached to the switch. This Energy Object Parent (the switch) has three Energy Object Relations with this Energy Object Child (the remote Energy Object): Power Source Relationship, Metering Relationship, and Proxy Relationship. However, the three topologies (wiring, metering, and management) don't always overlap. For example, when a protocol gateways device for Building Management Systems (BMS) controls subtended devices, which themselves receive Power from PDUs or wall sockets. Note: The Aggregation Relationship is slightly different compared to the other relationships (Power Source, Metering, and Proxy Relationships) as this refers more to a management function. 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. Expires August, 2013 [Page 28] Internet-Draft February 2013 The Energy Object Child SHOULD keep track of its Energy Object Parent(s) along with the Energy Object Relationships type(s). The Energy Object Parent SHOULD keep track of its Energy Object Child(ren), along with the Energy Object Relationships type(s). Energy Object Children Discovery There are multiple ways that the Energy Object Parent can discover its Energy Object Children: : . In case of PoE, the Energy Object Parent automatically discovers an Energy Object Child when the Child requests power. . The Energy 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 Object Parent might even support the LLDP-MED MIB [LLDP-MED-MIB], which returns extra information on the Energy Object Children. . The Energy Object Parent may reside on a network connected to a 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. . A different protocol between the Energy Object Parent and the Energy Object Children. Note that the communication specifications between the Energy Object Parent and Children is out of the scope of this document. However, in some situations, it is not possible to discover the Energy Object Relationships, and they must be set manually. For example, in today' network, an administrator must assign the connected Energy Object to a specific PDU Power Interface, with no means of discovery other than that manual connection. When an Energy Object Parent is a Proxy, the Energy Object Parent SHOULD enumerate the capabilities it is providing for the Energy 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. Expires August, 2013 [Page 29] Internet-Draft February 2013 Energy Object Relationship Conventions and Guidelines This Energy Management framework does not impose many "MUST" rules related to Energy Object Relationships. There are always corner cases that could be excluded with too strict specifications of relationships. However, this Energy Management framework proposes a series of guidelines, indicated with "SHOULD" and "MAY". Aggregation Aggregation relationships are intended to identify when one device is used to accumulate values from other devices. Typically this is for energy or power values among devices and not for Components or Power Interfaces on the same device. The intent of Aggregation relationships is to indicate when one device is providing aggregate values for a set of other devices when it is not obvious form the power source or simple containment within a device. Establishing aggregation relationships within the same device would make modeling more complex and the aggregated values can be implied form the use of Power Inlets, outlet and Energy Object value son the same device. Additionally since an EnMS is naturally a point of aggregation it is not necessary to model aggregation for an EnMS(s). Aggregation SHOULD be used for power and energy. It MAY be used for aggregation of other values from the information model for example but the rules and logical ability to aggregated each attribute is out of scope for this document. - A Device SHOULD NOT establish an Aggregation Relationship with a Component. - A Device SHOULD NOT establish an Aggregation Relationship with the Power Interfaces contained on the same device. - A Device SHOULD NOT establish an Aggregation Relationship with the an EnMS. - Aggregators SHOULD log or provide notification in the case of errors or missing values while performing aggregation. Power Source Expires August, 2013 [Page 30] Internet-Draft February 2013 Power Source relationships are intended to identify the connections between Power Interfaces. This is analogous to a Layer 2 connection in networking devices (a one hop connection). The preferred modeling would be for Power Interfaces to participate in Power Source Relationships. It may happen that the some Energy Objects may not have the capability to model Power Interfaces. Therefore, it may happen that a Power Source Relationship is established between two Energy Objects or two non-connected Power Interfaces. While strictly speaking Components and Power Interfaces on the same device do provide or receive energy from each other the Power Source relationship is intended to show energy transfer between Devices. Therefore relationship is implied on the same Device. - An Energy Object SHOULD NOT establish a Power Source Relationship with a Component. - A Power Source Relationship SHOULD be established with next known Power Interface in the wiring topology. o The next known Power Interface in the wiring topology would be the next device implementing the framework. In some cases the domain of devices under management may include some devices that do not implement the framework As such the Power Source relationship can be established with the next device in the topology that implements the framework and logically shows the Power Source of the device. - Transitive Power Source relationships SHOULD NOT be established. For examples if an Energy Object A has a Power Source Relationship "Poweredby" with the Energy Object B, and if the Energy Object B has a Power Source Relationship "Poweredby" with the Energy Object C, then the Energy Object A SHOULD NOT have a Power Source Relationship "PoweredBby" the Energy Object C. Metering Relationship Metering Relationships are intended to show when one Device is measuring the power or energy at a point in a power distribution system. Since one point of a power distribution system may cover many Devices with a complex wiring topology, this relationship type can be seen as an arbitrary set. Expires August, 2013 [Page 31] Internet-Draft February 2013 Additionally, Devices may include metering hardware for components and Power Interfaces or for the entire Device. For example some PDU's may have the ability to measure Power for each Power Interface (metered by outlet). Others may only be able to control power at each Power Interface but only measure Power at the Power Inlet and a total for all Power Interfaces (metered by device). In such cases a Device SHOULD be modeled as an Energy Object that meters all of its Power Outlets and each Power Outlet MAY be metered by the Energy Object representing the Device. - A Meter Relationship MAY be established with any other Energy Object, Component, or Power Interface. - Transitive Meter relationships MAY be used. - When there is a series of meters for one Energy Object, the Energy Object MAY establish a relationship with one or more of the meters. Proxy A Proxy relationship is intended to show when one Device is providing the Energy Object capabilities for another Device typically for protocol translations. Strictly speaking a a Component of a Device may provide the Energy Object capabilities for that Device (and vice versa) this relationship is intended to model relationships between Devices. - A Proxy relationship SHOULD be limited when possible to Energy Objects of different Devices. Energy Objects Relationship Extensions This framework for Energy Management, is based on four Energy Objects Relationships: Aggregation Relationship, Metering Relationship, Power Source Relationship, and Proxy Relationship. This framework is defined with possible extension of new Energy Objects Relationships in mind. 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, could be modeled with a future extension based on "gang relationship", whose semantic would specify the Energy Objects grouping. Expires August, 2013 [Page 32] Internet-Draft February 2013 4.5. Energy Monitoring For the purposes of this framework energy will be limited to electrical energy in watt hours. Other forms of Energy Objects that use or produce non-electrical energy may be part of an Energy Management Domain (See Section 3.5) but MUST provide information converted to and expressed in watt hours. An analogy for understanding power versus energy measurements can be made to speed and distance in automobiles. Just as a speedometer indicates the rate of change of distance, a power meter indicates the rate of transfer of energy. The odometer in an automobile measures the cumulative distance traveled and an energy meter indicates the accumulate energy transferred. So a less formal statement of the analogy is that power meters measures "speed" while energy meters measure "distance". Each Energy Object will have information that describes power information, along with how that measurement was obtained or derived (actual measurement, estimated, or presumed). For Energy Objects that can report actual power readings, an optional energy measurement can be provided. Optionally, an Energy Object can further describe the Power information with Power Quality information reflecting the electrical characteristics of the measurement. Optionally, an Energy Object that can report actual power readings can have energy meters that provide the energy used, produced, and net energy in kWh. These values are energy meters that accumulate the power readings. If energy values are returned then the three energy meters must be provided along with a description of accuracy. Optionally, an Energy Object can provide demand information over time. Power Measurement A power measurement MUST be qualified with the units, magnitude, direction of power flow, and SHOULD be qualified by what means the measurement was made (ex: Root Mean Square versus Nameplate). Expires August, 2013 [Page 33] Internet-Draft February 2013 In addition, the Energy 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 EnMS. 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 EnMS. 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 ^ Scale). For example, if current power usage of an Energy Object is 3, it could be 3 W, 3 mW, 3 KW, or 3 MW, depending on the value of the scaling factor. 3W implies that the BaseValue is 3 and Scale = 0, whereas 3mW implies BaseValue = 3 and ScaleFactor = -3. Electricity is usually billed in kilowatt-hours (not megajoules, the SI units). Similarly, battery charge is often measured as miliamperes-hour (mAh) instead of the SI unit coulomb. The units used in this framework are: W, A, Wh, Ah, V. In addition to knowing the usage and magnitude, it is useful to know how an Energy Object usage measurement was obtained: . Whether the measurements were made at the device itself or from a remote source. . Description of the method that was used to measure the power and whether this method can distinguish actual or estimated values. An EnMS can use this information to account for the accuracy and nature of the reading between different implementations. The EnMS can use the Nameplate Power for provisioning, capacity planning and potentially billing. 6.5.2 Optional Power Attributes Given a power measurement, it may be desirable to know additional power attributes associated with that measurement. Expires August, 2013 [Page 34] Internet-Draft February 2013 Optional Power Quality The information model should adhere to the IEC 61850 7-2 standard for describing AC measurements. Optional Demand It is well known in commercial electrical utility rates that demand is part of the calculation for billing. 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 Object, and not when the power measurement is assumed or predicted. Optional Battery Some Energy Objects may use batteries for storing energy and for receiving power supply. These Energy 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 the state information as defined in [EMAN-REQ]. 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. 4.6. Control An Energy Object can be controlled by setting it to a specific Power State. An Object implements a set of Power States consisting of at least two states, an on state and an off state. A Power State is an interface by which an Energy Object can be controlled. Each Energy Object should indicate the set of Power States that it implements. Well known Power States / Sets should be registered with IANA. Expires August, 2013 [Page 35] Internet-Draft February 2013 When a device is set to a particular Power State, it may be busy. The device will set the desired Power State and then update the actual Power State when it changes. There are then two Power State control variables: actual and requested. There are many existing standards for and implementations of Power States. An Energy Object can support a mixed set of Power States defined in different standards. A basic example is given by the three Power States defined in IEEE1621 [IEEE1621]: on, off, and sleep. The DMTF [DMTF], ACPI [ACPI], and PWG define larger numbers of Power States. The semantics of a power state is specified by a) the functionality provided by an Energy Object in this state, b) a limitation of the power that an Energy Object uses in this state, c) a combination of a) and b) The semantics of a Power State should be clearly defined. Limitation (curtailment) of the power used by an Energy Object in a state can be specified by - an absolute power value - a percentage value of power relative to the energy object's nameplate power - an indication of used power relative to another power state - for example: by stating used power in state A is less than in state B. For supporting Power State management it is useful to provide statistics on Power States including the time an Energy Object spent in a certain Power State and/or the number of times an Energy Object entered a power state. Power States should be registered at IANA with a name and a number. When requesting an Energy object to enter a Power State an indication of its name or its number can be used. Optionally an absolute or percentage of Nameplate Power can be provided to allow the Energy Object to transition to a nearest or equivalent Power State. Expires August, 2013 [Page 36] Internet-Draft February 2013 EMAN Power State Set An EMAN Power State Set represents an attempt for a 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 incorporates 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]. The expanded list of Power States are derived from [CISCO-EW] and 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). Each operational state represents 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: mechoff(1) : An off state where no Energy Object features are available. The Energy 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 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. hibernate(3): No Energy Object features are available. The Energy 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. Typically, energy consumption is zero or close to zero. This corresponds to state G1, S4 in ACPI. Expires August, 2013 [Page 37] Internet-Draft February 2013 sleep(4) : No Energy Object features are available, except for out-of-band management, such as 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 Object features are available, except for out-of-band management, such as 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 Object features are available, except for out-of-band management, such as wake-up mechanisms. This mode is analogous to hot-standby. The Energy 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. lowMinus(7) : Indicates some Energy Object features may not be available and the Energy 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 Object has taken measures or selected options to provideless than mediumMinus(9) usage. mediumMinus(9): Indicates all Energy Object features are available but the Energy Object has taken measures or selected options to provide less than medium(10) usage. medium(10) : Indicates all Energy Object features are available but the Energy Object has taken measures or selected options to provide less than highMinus(11) usage. highMinus(11): Indicates all Energy Object features are available and power usage is less than high(12). high(12) : Indicates all Energy Object features are available and the Energy Object is consuming the highest power. Expires August, 2013 [Page 38] Internet-Draft February 2013 A comparison of Power States can be seen in the following table: IEEE1621 DMTF ACPI EMAN Non-operational states off Off-Hard G3, S5 MechOff(1) off Off-Soft G2, S5 SoftOff(2) sleep Hibernate G1, S4 Hibernate(3) sleep Sleep-Deep G1, S3 Sleep(4) sleep Sleep-Light G1, S2 Standby(5) sleep Sleep-Light G1, S1 Ready(6) Operational states: on on G0, S0, P5 LowMinus(7) on on G0, S0, P4 Low(8) on on G0, S0, P3 MediumMinus(9) on on G0, S0, P2 Medium(10) on on G0, S0, P1 HighMinus(11) on on G0, S0, P0 High(12) Figure 5: Comparison of Power States 4.7. 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 Objects may communicate over varying protocols. For example the communications network may use IP Protocols (SNMP) but attached Energy Object Parent may communicate to Energy 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. In this section we will describe the topologies that can exist when describing a device, components and the relationships among them. We will then generalize those topologies by using an information model based upon relationships. The most abstract and general relationship between devices is a Parent and Child Expires August, 2013 [Page 39] Internet-Draft February 2013 relationship. Specific types of relationships are defined and used in concert to describe the topologies. 4.8 Using Device Relationships to Create Topologies The reference models here define physical and logical topologies of devices in a communication network. The physical topology defined by the model defines relationships between devices that reflect provisioning, transfer of energy, and aid in management. Logical topologies concern monitoring and controlling devices and covers metering of energy and power, reporting information relevant for energy management, and energy-related control of devices. Power Source Topology As described in Section 4, the power source(s) of a device is important for energy management. The Energy Management reference model addresses this by a "Power Source" Relationship. This is a relationship among devices providing energy and devices receiving energy. A simple example is a PoE PSE, for example, an Ethernet switch, providing power to a PoE PD, for example, a desktop phone. Here the switch provides energy and the phone receives energy. This relationship can be seen in the figure below. +----------+ power source +---------+ | switch | <-------------- | phone | +----------+ +---------+ Figure 6: Simple Power Source A single power provider can act as power source of multiple power receivers. An example is a power distribution unit (PDU) providing AC power for multiple switches. +-------+ power source +----------+ | PDU | <----------+--- | switch 1 | +-------+ | +----------+ | | +----------+ +--- | switch 2 | | +----------+ | Expires August, 2013 [Page 40] Internet-Draft February 2013 | +----------+ +--- | switch 3 | +----------+ Figure 7: Multiple Power Source This level of modeling is sufficient if there is no need to distinguish in monitoring and control between the individual receivers at the switch. However, if there is a need to monitor or control power supply for individual receivers at the power provider, then a more detailed level of modeling is needed. Devices receive or provide energy at power interfaces connecting them to a transmission medium. The Power Source relationship can be used also between power interfaces at the power provider side as well as at the power receiver side. The example below shows a power providing device with a power interface (PI) per connected receiving device. +-------+------+ power source +----------+ | | PI 1 | <-------------- | switch 1 | | +------+ +----------+ | | | +------+ power source +----------+ | PDU | PI 2 | <-------------- | switch 2 | | +------+ +----------+ | | | +------+ power source +----------+ | | PI 3 | <-------------- | switch 3 | +-------+------+ +----------+ Figure 8: Power Source with Power interfaces Power interfaces may also be modeled at the receiving device, for examples for consistency. +-------+------+ power source +----+----------+ | | PI 1 | <-------------- | PI | switch 1 | | +------+ +----+----------+ | | | +------+ power source +----+----------+ | PDU | PI 2 | <-------------- | PI | switch 2 | | +------+ +----+----------+ | | | +------+ power source +----+----------+ Expires August, 2013 [Page 41] Internet-Draft February 2013 | | PI 3 | <-------------- | PI | switch 3 | +-------+------+ +----+----------+ Figure 9: Power Interfaces at Receiving Device Power Source relationships are between devices and their interfaces. They are not transitive. In the examples below there is a PDU powering a switch powering a phone. +-------+ power +--------+ power +---------+ | PDU | <-------- | switch | <-------- | phone | +-------+ source +--------+ source +---------+ Figure 10: Power Source Non-Transitive Power Source Relationships are between the PDU and the switch and between the switch and the phone. Transitively , there exists a Power Source Relationship between the PDU and the phone. . +-------+ power +--------+ power +---------+ | PDU | <-------- | switch | <-------- | phone | +-------+ source +--------+ source +---------+ ^ | | power source | +------------------------------------------+ Figure 11: Power Source Transitive Metering Topology Case 1: Metering between two devices The metering topology between two devices is closely related to the power source topology. It is based on the assumption that in many cases the power provided and the power received is the same for both peers of a power source relationship. Then power measured at one end can be taken as the actual power value at the other end. Obviously, the same applies to energy at both ends. We define in this case a Metering Relationship between two devices or power interfaces of devices that have a power source relationship. Power and energy values measured at one Expires August, 2013 [Page 42] Internet-Draft February 2013 peer of the power source relationship are reported for the other peer as well. The Metering Relationship is independent of the direction of the Power Source Relationship. The more common case is that values measured at the power provider are reported for the power receiver, but also the reverse case is possible with values measured at the power receiver being reported for the power provider. Power Power +-----+----------+ Source +--------+ Source +-------+ | PDU |PI + meter| <-------- | switch | <------- | phone | +-----+----------+ Metering +--------+ +-------+ ^ | | | +-------------------------------------------+ metering Figure 12: Direct and One Hop Metering Case 2: Metering at a point in power distribution A Sub-meter in a power distribution system can logically measure the power or energy for all devices downstream from the meter in the power distribution system. As such, a Power metering relationship can be seen as a relationship between a meter and all of the devices downstream from the meter. We define in this case a Power Metering relationship between a metering device and devices downstream from the meter. In cases where the Power Source topology cannot be discovered or derived from the information available in the Energy Management Domain, the Metering Topology can be used to relate the upstream meter to the downstream devices in the absence of specific power source relationships. A Metering Relationship can occur between devices that are not directly connected as shown by the figure 13. +---------------+ | Device 1 | +---------------+ | PI | +---------------+ | +---------------+ Expires August, 2013 [Page 43] Internet-Draft February 2013 | Meter | +---------------+ . . . +----------+ +----------+ +-----------+ | Device A | | Device B | | Device C | +----------+ +----------+ +-----------+ Figure 14: Complex Metering Topology An analogy to communication networks would be modeling connections between servers (meters) and clients (devices) when the complete Layer 2 topology between the servers and clients is not known. Proxy Topology Some devices may provide energy management capabilities on behalf of other devices. For example, a controller may logically model power interfaces but the physical topology may require that the controller communicate to another device using a building management protocol. These proxied devices that are represented as power interfaces may be directly connected or may be controlled over a communication network with no direct connection. The proxied device may or may not be IP connected. When it is IP connected the communication may be via SNMP or any other protocol. While the EnMS may look at the logical representation of the controller as a device with power interfaces, it may require to report the physical topology and relationship to the subtended devices. To model this we define a proxy relationship to provide this visibility. +-------+------+ | | PI 1 | | +------+ | | | +------+ | PDU | PI 2 | | +------+ | | | +------+ | | PI 3 | +-------+------+ Expires August, 2013 [Page 44] Internet-Draft February 2013 +-------+ proxy +----+----------+ | |<--------- | PI 1 Physical | | + +----+----------+ | | | + proxy +----+----------+ | PDU |<--------- | PI 2 Physical | | + +----+----------+ | | | + proxy +----+----------+ | |<--------- | PI 3 Physical | +-------+ +----+----------+ Figure 15: Proxy Relationship Virtual and Physical Aggregation Topology Some devices can act as aggregation points for other devices. For example, a PDU controller device may contain the summation of power and energy readings for many PDU devices. The PDU controller will have aggregate values for power and energy for a group of PDU devices. This aggregation is independent of the physical power or communication topology. An Aggregation Relationship is an Energy Object Relationship where one Energy Object (called the Aggregate Energy Object) aggregates the Energy Management information of one or more other Energy Objects. These Energy Objects are referred to as having an Aggregation Relationship. The functions that the aggregation point may perform include the calculation of values such as average, count, maximum, median, minimum, or the listing (collection) of the aggregation values, etc. Based on the experience gained on aggregations at the IETF [draft-ietf-ipfix-a9n-08], the aggregation function in the EMAN framework is limited to the summation. While any power or energy values monitored from a device/power interface can be seen as a summation for all devices downstream from the monitoring device, the aggregation relationship is used SHOULD BE instantiated to represent a Expires August, 2013 [Page 45] Internet-Draft February 2013 summation when it is not obvious from the powering topology or a device to component containment. The Aggregation Relationship is then specified between the Energy Object device containing aggregate values and each of the other Energy Object devices for which the aggregation is reported. If it does not exist, a new Aggregate Energy Object specific for the Aggregation Relationship MUST be created. EDITORs NOTE: add an outlet gang example and expand below. A method to report on collections and summations of data is to create special pseudo-devices. These could be tagged in the MIB as not being a real device, but this may not be needed. ThisA pseudo-device would have no power PIs Power Interfaces, as to make clear that it does not interact with the real power world. It contains components which are actually entities from real devices and can be any combination of devices, PIs, and real components. Most commonly, a pseudo-device would contain a consistent set of entities - - a set of devices, a set of PIs, or a set of components. The power/energy values for the entire pseudo- device would be the sum of the components, as on a normal device. This provides an easy way to access the sum, as well as full documentation of what the components of that sum are. This method is completely flexible and adds no complexity to the EMAN framework or MIBs. Implementation of this mechanism would be completely optional for EMAN devices; likely most would not. When aggregation occurs across a set of entities, values to be aggregated may be missing for some entities. The EMAN framework does not specify how these should be treated, as different implementations may have good reason to take different approaches. One common treatment is to define the aggregation as missing if any of the constituent elements are missing (useful to be most precise). Another is to treat the missing value as zero (useful to have continuous data streams). The specifications of this aggregation function are out of scope of the EMAN framework, but must be clearly specified by the equipment vendor. Expires August, 2013 [Page 46] Internet-Draft February 2013 EDITOR'S NOTE: 4 solutions discussed on December 12th - pseudo device. Aggregate Energy Object - A semantic field (ex: summation): extra index in every measurement MIB table. - Multiply the variables => doesn't work - Remove aggregation PREFERRED: take the proposal from Bruce (below) and let's call pseud-device differently. Example Aggregate Energy Object 4.9 Generalized Relationship Model As displayed in Figure 15, the most basic energy management reference model is composed of an EnMS that obtains Energy Management information from Energy Objects. The Energy Object (EO) returns information for Energy Management directly to the EnMS. The protocol of choice for Energy Management is SNMP, as three MIBs are specified for Energy Management: the energy object context MIB [EMAN-OBJECT-MIB], the energy monitoring MIB [EMAN-MON-MIB], and the battery MIB [EMAN-BATTERY-MIB]. However, the EMAN requirement document [EMAN-REQ] also requires support for a push model distribution of time series values. The following diagrams mention IPFIX [RFC5101] as one possible solution for implementing a push mode transfer, however this is for illustration purposes only. The EMAN standard does not require the use of IPFIX and acknowledges that other alternative solutions may also be acceptable. +---------------+ | EnMS | - - +-----+---+-----+ ^ ^ | | | | | | |S |I +---------+ +----------+ |N |P | | |M |F | | |P |I +-----------------+ +--------+--------+ | |X | EO 1 | ... | EO N | v | +-----------------+ +-----------------+ - - Expires August, 2013 [Page 47] Internet-Draft February 2013 Figure 15: Simple Energy Management As displayed in the Figure 16, 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. +---------------+ | EnMS | - - +-----+--+------+ ^ ^ | | | | | | |S |I +------------+ +--------+ |N |P | | |M |F | | |P |I +------------------+ +------+-----------+ | |X | EO | | EO | v | | Parent 1 | ... | Parent N | - - +------------------+ +------------------+ ||| . One or ||| . Multiple ||| (*) . Energy ||| . Object ||| . Relationship(s): ||| - Aggregation ||| +-----------------------+ - Metering |||------| EO Child 1 | - Power Source || +-----------------------+ - Proxy || || +-----------------------+ ||-------| EO Child 2 | | +-----------------------+ | | |-------- ... | | | +-----------------------+ |--------| EO Child M | +-----------------------+ Expires August, 2013 [Page 48] Internet-Draft February 2013 Figure 16: Complex Energy Management Model While both the simple and complex Energy Management models contain an EnMS, this framework doesn't impose any requirements regarding a topology with a centralized EnMS(s) or one with distributed Energy Management via the Energy Objects within the deployment. Given the pattern in Figure 16, the complex relationships between Energy Objects can be modeled (refer also to section 5.3): - A PoE device modeled as an Energy Object Parent with the Power Source, Metering, and Proxy Relationships for one or more Energy Object Children - A PDU modeled as an Energy Object Parent with the Power Source and Metering Relationships for the plugged in Electrical Equipment (the Energy Object Children) - Building management gateway, used as proxy for non IP protocols, is modeled as an Energy Object Parent with the Proxy Relationship, and potentially the Aggregation Relationship to the managed Electrical Equipment - Etc. (*) If there is any communication between the Energy Object Parent and Energy Object Children, it can be via EMAN and SNMP (or IPFIX) but may be any other protocol IP or otherwise. In the [EMAN-OBJECT-MIB], each Energy Object is managed with an unique value of the entPhysicalIndex index from the ENTITY- MIB [RFC4133] The ENTITY-MIB [RFC4133] specifies the notion of physical containment tree, as: "Each physical component may be modeled as 'contained' within another physical component. A "containment-tree" is the conceptual sequence of entPhysicalIndex values that uniquely specifies the exact physical location of a physical component within the managed system. It is generated by 'following and recording' each 'entPhysicalContainedIn' instance 'up the tree towards the root', until a value of zero indicating no further containment is found." Expires August, 2013 [Page 49] Internet-Draft February 2013 A Energy Object Component is a special Energy Object that is a physical component as specified by the ENTITY-MIB physical containment tree. 5. Energy Management Information Model 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 a 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. Arrows indicate inheritance. Algorithms for class variable initialization, constructors or destructors are not shown. Attrbutes and structures are considered readable and writeable prefixed by a dash (-) which indicates readonly. Expires August, 2013 [Page 50] Internet-Draft February 2013 EO RELATIONSHIPS AND CONTEXT +---------------------------------+ | Energy Object Information | |---------------------------------| | -index : int | | name : string | | -energy object Identifier : UUID| | domain name : string | | alternate Key : string | +---------------------------------+ ^ | | +---------------------------+ | EO Context Information | |---------------------------| | role : string | | keywords[0..n] : string | | importance : int | | category : enum | +---------------------------+ +---------------------------------+ | EO Relationship | | ------------------------------- | | -index : int | | relation ID : UUID | | relationship type: enum | +---------------------------------+ +---------------------------------+ | EO Proxy Relationship | | ------------------------------- | | -index : int | | proxy ID : UUID | | proxy abilities : enum | +---------------------------------+ Expires August, 2013 [Page 51] Internet-Draft February 2013 EO AND MEASUREMENTS +-----------------------------------------------+ | Energy Object | |-----------------------------------------------| | -nameplate : Measurement | | current : enum { AC, DC } | | origin : enum { self, remote } | | battery[0..n]: Battery | | measurements[0..n]: Measurement | | status: | | --------------------------------------------- | | Measurement instantaneousUsage() | | DemandMeasurement historicalUsage() | +-----------------------------------------------+ +---------------------------------------+ | -Measurement | +---------------------------------------+ | multiplier : enum {-24..24} | | caliber : enum { actual, estimated, | | trusted, assumed...} | | accuracy : enum { 0..10000} | | time : timestamp | +---------------------------------------+ ^ ^ | | | +------------------+------------------+ | | -Power Measurement | | |-------------------------------------| | | value : long | | | units : "watts" | | | rate : enum {0,millisecond,seconds, | | | minutes,hours,...} | | | quality : PowerQuality | | +-------------------------------------+ | | +------------------+----------------------------+ | -Energy Measurement | |-----------------------------------------------| | collection start time : time | | units : enum | | consumed : long | | produced : long | Expires August, 2013 [Page 52] Internet-Draft February 2013 | net : long | | max consumed : long | | max produced : long | +-----------------------------------------------+ +-----------------------------------------------+ | -Time | |-----------------------------------------------| | startTime : timestamp | | usage : Measurement | | maxUsage : Measurement | +-----------------------------------------------+ | | +----------------------------------------+ | -TimeInterval | |--------------------------------------- | |value : long | |units : enum { seconds, miliseconds..} | +----------------------------------------+ | | +----------------------------------------+ | -DemandMeasurement | |----------------------------------------| |intervalLength : TimeInterval | |intervalNumbers: long | |intervalMode : enum { period, sliding, | |total } | |intervalWindow : TimeInterval | |sampleRate : TimeInterval | |status : enum {active, inactive } | |measurements : TimedMeasurement[] | +----------------------------------------+ Expires August, 2013 [Page 53] Internet-Draft February 2013 ATTRIBUTES +----------------------------------------+ | -PowerAttributes | |----------------------------------------| | | +----------------------------------------+ ^ | | +------------------+--------------------+ | -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 | | avgCurrent : long | | activePower : long | | reactivePower : long | | apparentPower : long | | powerFactor : long | +------------------------------------+ ^ ^ | | | | | | | | +-------------------------------+---+ | | -DelPhase | | |-----------------------------------| | |phaseToNextPhaseVoltage : long | | |thdVoltage : long | | Expires August, 2013 [Page 54] Internet-Draft February 2013 |thdCurrent : long | | +-----------------------------------+ | | +------------------+-----------+ | -WYEPhase | |------------------------------| |phaseToNeutralVoltage : long | |thdCurrent : long | |thdVoltage : long | +------------------------------+ EO & STATES +----------------------------------------------+ | Energy Object | |----------------------------------------------| | -currentLevel : int | | configuredLevel : int | | -configuredTime : timestamp | | reason: string | | powerStateSeries[0..n] : array of State | | adminState : enum | | operState : enum | +----------------------------------------------+ +-------------------------------+ | State | |-------------------------------| | name : string | | cardinality : int | | maxUsage : Measurement | | totalTime : time | | enterCount : int | +-------------------------------+ Figure 17: Information Model UML Representation Expires August, 2013 [Page 55] Internet-Draft February 2013 6. Example Topologies In this section we will give examples of how to use the Energy Management framework. In each example we will show how it can be applied when Devices have the capability to model Power Interfaces. We will also show in each example how the framework can be applied when devices cannot support Power Interfaces but only monitor information or control the Device as a whole. For instance a PDU may only be able to measure power and energy for the entire unit without the ability to distinguish among the inlets or outlet. Together these examples show how the framework can be adapted for Devices with different capabilities (typically hardware) for Energy Management. Given for all Examples: Device W: A computer with one power supply. Power interface 1 is an inlets for Device W. Device X: A computer with two power supplies. Power interface 1 and power interface 2 are both inlets for Device X. Device Y: A PDU with multiple Power Interfaces numbered 0..10, Power interface 0 is an inlet and power interface 1..10 are outlets. Device Z: A PDU with multiple Power Interfaces numbered 0..10, Power interface 0 is an inlet and power interface 1..10 are outlets. 6.1 Example I: Simple Device with one Source Topology: Device W inlet 1 is plugged into Device Y outlet 8. With Power Interfaces: Device W has an Energy Object representing the computer itself as well as one Power Interface defined as an inlet. Device Y would have an Energy Object representing the PDU itself (the Device) with a Power Interface 0 defined as an inlet and Power Interfaces 1..10 defined as outlets. Expires August, 2013 [Page 56] Internet-Draft February 2013 The interfaces of the devices would have a Power Source Relationship such that: Device W inlet 1 is powered by Device Y outlet 8 Without Power Interfaces: In this case Device W has an Energy Object representing the computer. Device Y would have an Energy Object representing the PDU. The devices would have a Power Source Relationship such that: Device W is powered by Device Y. 6.2 Example II: Multiple Inlets Topology: Device X inlet 1 is plugged into Device Y outlet 8. Device X inlet 2 is plugged into Device Y outlet 9. With Power Interfaces: Device X has an Energy Object representing the computer itself. It contains two Power Interface defined as inlets. Device Y would have an Energy Object representing the PDU itself (the Device) with a Power Interface 0 defined as an inlet and Power Interface 1..10 defined as outlets. The interfaces of the devices would have a Power Source Relationship such that: Device X inlet 1 is powered by Device Y outlet 8 Device X inlet 2 is powered by Device Y outlet 9 Without Power Interfaces: In this case Device X has an Energy Object representing the computer. Device Y would have an Energy Object representing the PDU. The devices would have a Power Source Relationship such that: Device X is powered by Device Y. Expires August, 2013 [Page 57] Internet-Draft February 2013 6.3 Example III: Multiple Sources Topology: Device X inlet 1 is plugged into Device Y outlet 8. Device X inlet 2 is plugged into Device Z outlet 9 With Power Interfaces: Device X has an Energy Object representing the computer itself. It contains two Power Interface defined as inlets. Device Y would have an Energy Object representing the PDU itself (the Device) with a Power Interface 0 defined as an inlet and Power Interface 1..10 defined as outlets. Device Z would have an Energy Object representing the PDU itself (the Device) with a Power Interface 0 defined as an inlet and Power Interface 1..10 defined as outlets. The interfaces of the devices would have a Power Source Relationship such that: Device X inlet 1 is powered by Device Y outlet 8 Device X inlet 2 is powered by Device Z outlet 9 Without Power Interfaces: In this case Device X has an Energy Object representing the computer. Device Y and Z would both have respective Energy Objects representing each entire PDU. The devices would have a Power Source Relationship such that: Device X is powered by Device Y and powered by Device Z. 7. Relationship with Other Standards This power management framework should, as much as possible, reuse existing standards efforts, especially with respect to information modeling and data modeling [RFC3444]. Expires August, 2013 [Page 58] Internet-Draft February 2013 The data model for power and energy related objects is based on IEC 61850. Specific examples include: The scaling factor, which represents Energy Object usage magnitude, conforms to the IEC 61850 definition of unit multiplier for the SI (System International) units of measure. The electrical characteristic 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. 8. 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. Security Considerations for SNMP Expires August, 2013 [Page 59] Internet-Draft February 2013 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 Energy Management Domain or business context of an Energy Object may result in misreporting or interruption of power. Unauthorized changes to a power state may disrupt the power settings of the different Energy Objects, and therefore the state of functionality of the respective Energy 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 Expires August, 2013 [Page 60] Internet-Draft February 2013 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. 9. IANA Considerations Initial values for the Power State Sets, together with the considerations for assigning them, are defined in [EMAN-MON- MIB]. 10. Acknowledgments The authors would like to Michael Brown for improving the text dramatically, and Rolf Winter for his feedback. The award for the best feedback and reviews goes to Bill Mielke. 11. References Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2819] S. Waldbusser, "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet Standard Management Framework ", RFC 3410, December 2002. [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version3)", RFC 4133, August 2005. Expires August, 2013 [Page 61] Internet-Draft February 2013 [RFC4122] Leach, P., Mealling, M., and R. Salz," A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005 Informative References [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2", RFC 2578, April 1999 [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences between Information Models and Data Models", RFC 3444, January 2003. [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. [RFC6020] M. Bjorklund, Ed., " YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [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. [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 Management", draft-ietf-eman-requirements-09, (work in progress), November 2011. [EMAN-OBJECT-MIB] Parello, J., and B. Claise, "Energy Object Contet MIB", draft-ietf-eman-energy-aware-mib-07, (work in progress), October 2012. Expires August, 2013 [Page 62] Internet-Draft February 2013 [EMAN-MON-MIB] Chandramouli, M.,Schoening, B., Quittek, J., Dietz, T., and B. Claise, "Power and Energy Monitoring MIB", draft-ietf-eman-energy-monitoring- mib-03, (work in progress), March 2012. [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, " Definition of Managed Objects for Battery Monitoring", draft-ietf-eman-battery-mib-06, (work in progress), March 2012. [EMAN-AS] Schoening, B., Chandramouli, M., and B. Nordman, "Energy Management (EMAN) Applicability Statement", draft-ietf-eman-applicability-statement-02, (work in progress), October 2011 [EMAN-TERMINOLOGY] J. Parello, "Energy Management Terminology", draft-parello-eman-definitions-06, (work in progress), March 2012 [ITU-T-M-3400] TMN recommandation on Management Functions (M.3400), 1997 [NMF] "Network Management Fundamentals", Alexander Clemm, ISBN: 1-58720-137-2, 2007 [TMN] "TMN Management Functions : Performance Management", ITU-T M.3400 [1037C] US Department of Commerce, Federal Standard 1037C, http://www.its.bldrdoc.gov/fs-1037/fs-1037c.htm [IEEE100] "The Authoritative Dictionary of IEEE Standards Terms" http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?pu number=4116785 [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/ [IEC60050] International Electrotechnical Vocabulary http://www.electropedia.org/iev/iev.nsf/welcome?openf orm [SQL] ISO/IEC 9075(1-4,9-11,13,14):2008 Expires August, 2013 [Page 63] Internet-Draft February 2013 [IEEE-802.3at] IEEE 802.3 Working Group, "IEEE Std 802.3at- 2009 - IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Amendment: Data Terminal Equipment (DTE) - Power via Media Dependent Interface (MDI) Enhancements", October 2009. [DMTF] "Power State Management Profile DMTF DSP1027 Version 2.0" December 2009 http://www.dmtf.org/sites/default/files/standards/doc uments/DSP1027_2.0.0.pdf [IPENERGY] R. Aldrich, J. Parello "IP-Enabled Energy Management", 2010, Wiley Publishing [X.700] CCITT Recommendation X.700 (1992), Management framework for Open Systems Interconnection (OSI) for CCITT applications. [ASHRAE-201] "ASHRAE Standard Project Committee 201 (SPC 201)Facility Smart Grid Information Model", http://spc201.ashraepcs.org [CHEN] "The Entity-Relationship Model: Toward a Unified View of Data", Peter Pin-shan Chen, ACM Transactions on Database Systems, 1976 [CISCO-EW] "Cisco EnergyWise Design Guide", John Parello, Roland Saville, Steve Kramling, Cisco Validated Designs, September 2010, http://www.cisco.com/en/US/docs/solutions/Enterprise/ Borderless_Networks/Energy_Management/energywisedg.ht ml Authors' Addresses Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1813 Expires August, 2013 [Page 64] Internet-Draft February 2013 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.schoening@verizon.net Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511 15 EMail: quittek@netlab.nec.de Bruce Nordman Lawrence Berkeley National Laboratory 1 Cyclotron Road Berkeley 94720 US Phone: +1 510 486 7089 Email: bnordman@lbl.gov Expires August, 2013 [Page 65]