Network Working Group B. Claise Internet-Draft J. Parello Intended Status: Informational Cisco Systems, Inc. Expires: April 30, 2012 B. Schoening Independent Consultant J. Quittek NEC Europe Ltd. October 31, 2011 Energy Management Framework draft-ietf-eman-framework-03 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on October, 2011. Internet-Draft Oct 2011 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document defines a framework for providing Energy Management for devices within or connected to communication networks. The framework defines 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 Quality, and battery. Additionally the framework models relationships and capabilities between Energy Objects. Expires April 30, 2012 [Page 2] Internet-Draft Oct 2011 Table of Contents 1. Introduction................................................4 1.1. Energy Management Document Overview....................5 2. Requirements & Use Cases....................................6 3. Terminology.................................................6 4. Energy Management Reference Model...........................9 5. Framework High Level Concepts and Scope....................12 5.1. Energy Object and Energy Management Domain............13 5.2. Energy Object Identification and Context..............13 5.2.1 Energy Object Identification......................13 5.2.2 Context in General................................14 5.2.3 Context: Importance...............................14 5.2.4 Context: Keywords.................................15 5.2.5 Context: Role.....................................16 5.3. Energy Object Relationships...........................17 5.3.1 Energy Object Children Discovery..................17 5.4. Energy Monitoring.....................................18 5.4.1 Power Measurement.................................19 5.5. Energy Control........................................21 5.5.1 IEEE1621 Power State Series.......................21 5.5.2 DMTF Power State Series...........................22 5.5.3 EMAN Power State Set..............................23 6. Structure of the Information Model: UML Representation.....25 7. Configuration..............................................30 8. Fault Management...........................................31 9. Relationship with Other Standards Development Organizations.................................................31 9.1. Information Modeling..................................31 10. Security Considerations...................................32 10.1. Security Considerations for SNMP........................32 11. IANA Considerations.......................................33 12. Acknowledgments...........................................33 13. References................................................33 Normative References.......................................33 Informative References.....................................34 TO DO/OPEN ISSUE - Do we want to add some examples such as http://www.ietf.org/proceedings/81/slides/eman-4.pdf slide 14 to 1]? Proposal: add it to [EMAN-AS] - Do we need variable range of states (i.e. dimmer)? Is this a requirement? How to model the batteries, as a component or a relationship? See the meeting minutes: Expires April 30, 2012 [Page 3] Internet-Draft Oct 2011 o "Modeling of the battery? If we are not modeling components then why model batteries? Use the Entity MIB" - Comment from Prantl on the list, related to energy control: non-discrete power-states are not supported -> Section 5.5. specifies the possibility of mapping "Manufacturer" Power States to the 12 Eman Power states, where there can be more than 12 Manufacturer Power States. However, in the context of power-capping of Servers we have a "non-discrete" floating cap corresponding to the Manufacturer Power State. The Problem is that different Servers will have completely different ranges of supported cap-values, e.g. Server 1 has a dynamic range of 300-500Watt, Server2 has a range of 70- 270Watts. Now let's assume Powerstate 9=400 Watts for Server1, but would be 170Watts for Server2. Which would mean I have to specify a Mapping for each Server-Model. It would be far more practical if it would be possible to supply a key-value-pair with a certain power-state in Case the State needs context such as a power-cap, I would then specify a state of e.g. 7 and supply the desired Cap in the kvp-field. PROPOSAL: 1. decide if we need a variable power state that is a percent of maximum. 2. Power-capping can be done by the EnMS. [EMAN-AS] to document this use case. 1. Introduction Network management is divided into the five main areas defined in the ISO Telecommunications Management Network model: Fault, Configuration, Accounting, Performance, and Security Management (FCAPS) [X.700]. Absent from this management model is any consideration of Energy Management, which is now becoming a critical area of concern worldwide as seen in [ISO50001]. Note that Energy Management has particular challenges in that a power distribution network is responsible 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. This document defines a framework for providing Energy Management for devices within or connected to communication Expires April 30, 2012 [Page 4] Internet-Draft Oct 2011 networks. The framework describes how to identify, classify and provide context for a device in a communications network from the point of view of Energy Management. The identified device, called Energy Objects, can then be monitored for Energy Management by obtaining measurements for Power, Energy, Demand and Power Quality. If a device contains a battery(s) the characteristics and performance of the battery(s) can also be managed. An Energy Object state can be monitored or controlled by providing an interface expressed as one or more Power State Sets. The most basic example of Energy Management is a single Energy Object reporting information about itself. However, in many cases, Energy is not measured by the Energy Object itself, but by a meter located upstream in the power distribution tree. An example is a power distribution unit (PDU) that measures Energy consumption of attached devices and may report this to an Energy Management System (EnMS). Therefore, Energy Objects are recognized as having relationships to other devices in the network from the point of view of Energy Management. These relationships include Aggregation Relationship, Metering Relationship, Power Source Relationship , Proxy Relationship , and Dependency Relationship. 1.1. Energy Management Document 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, cross-reference between existing standards and the EMAN standard, and shows how the this relates to other frameworks. The [EMAN-AWARE-MIB] specifies objects for addressing Energy Object Identification, classification, context information, and relationships form the point of view of Energy Management. The Power and Energy Monitoring MIB [EMAN-MON-MIB] contains objects for monitoring of Power, Energy, Demand, Power Quality and Power State Sets. Definition of Managed Objects for Battery Monitoring [EMAN- BATTERY-MIB] defines managed objects that provide information on the status of batteries in managed devices. Expires April 30, 2012 [Page 5] Internet-Draft Oct 2011 2. Requirements & Use Cases Requirements for Power and Energy monitoring for networking devices are specified in [EMAN-REQ]. The Energy Management use cases covered by this framework are covered in the EMAN applicability statement document in [EMAN-AS]. Typically requirements and use cases for communication networks cover the devices that make up the communication network and endpoints. With Energy Management, there exists a wide variety of devices that may be contained in the same deployments as a communication network but comprise a separate facility, home, or power distribution network. Target devices for the 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 datacenter server, or a printer - Routers - Switches - Switches with line card components - Power over Ethernet (PoE) endpoints, - Power Distribution Units (PDU) - Protocol gateways devices for Building Management Systems (BMS) - Electrical Meters - Sensor controllers with subtended sensors There may also exist varying protocols deployed among these power distributions and communication networks. For an Energy Management framework to be useful, it should also apply to these types of separate networks as they connect and interact with a communications network. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This section contains definitions of terms used throughout this specification. Defined terms have their first letter capitalized. Expires April 30, 2012 [Page 6] Internet-Draft Oct 2011 Energy Management System (EnMS) EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Energy Management EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Energy Monitoring EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Energy EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Power EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Demand EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Power Quality EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Energy Control EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Energy Object Expires April 30, 2012 [Page 7] Internet-Draft Oct 2011 EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Electrical Equipement EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Energy Object Identification EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions EDITOR'S NOTE: the uniqueness must be clarified in [EMAN-REQ] Energy Object Context EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Energy Management Domain EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Energy Object Relationships EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Aggregation Relationship EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Metering Relationship EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Power Source Relationship EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Expires April 30, 2012 [Page 8] Internet-Draft Oct 2011 Proxy Relationship EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Dependency Relationship EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Energy Object Parent EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Energy Managed Object Child EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Power State EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Manufacturer Power State EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Power State Set EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions Nameplate Power EDITOR'S NOTE: use the latest definition from the [draft- parello-eman-definitions-03] definitions 4. Energy Management Reference Model The scope of this framework is to enable network and network- attached devices to be administered for Energy Management. The Expires April 30, 2012 [Page 9] Internet-Draft Oct 2011 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. As displayed in the Figure 1, the most basic energy 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-aware MIB [EMAN-AWARE-MIB], the energy monitoring MIB [EMAN-MON-MIB], and the battery MIB [EMAN-BATTERY-MIB]. However, the EMAN requirement document [EMAN-REQ] also require the push of time series of power values. Therefore, IPFIX [RFC5101] is also mentioned as the appropriate solution in the following figures, even if there are no documents describing the IPFIX solution at the time of writing these lines. Note that this framework doesn't exclude another solution than IPFIX. +---------------+ | EnMS | - - +-----+---+-----+ ^ ^ | | | | | | |S |I +---------+ +----------+ |N |P | | |M |F | | |P |I +-----------------+ +--------+--------+ | |X | EO 1 | ... | EO N | v | +-----------------+ +-----------------+ - - Figure 1: Simple Energy Management As displayed in the Figure 2, a more complex energy reference model includes Energy Managed Object Parents and Children. The Energy Managed Object Parent returns information for themselves as well as information according to the Energy Managed Object Relationships. Expires April 30, 2012 [Page 10] Internet-Draft Oct 2011 +---------------+ | 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 || - Dependency || +-----------------------+ ||-------| EO Child 2 | | +-----------------------+ | | |-------- ... | | | +-----------------------+ |--------| EO Child M | +-----------------------+ Figure 2: 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 centralize EnMS or one with a distributed Energy Management via the Energy Objects within the deployment. Expires April 30, 2012 [Page 11] Internet-Draft Oct 2011 Given the pattern in figure 2, 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 this Energy Object Child - A PDU modeled as an Energy Object Parent with the Power Source and Metering Relationships for the plugged in host (the Energy Object Children) - A PC with line cards modeled as an Energy Object Parent with Dependency Relationships for the line cards (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 - Etc. The communication between the Energy Object Parent and Energy Object Children is out of the scope of this framework. 5. Framework High Level Concepts and Scope Energy Management can be organized into areas of concern that include: - Energy 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 - Cost in currency or environmental impact to dismantle or recycle an Energy Object - Relationship or capabilities of an Energy Object to an electrical or smart grid - Supply chain analysis of energy sources or Energy Object deployment Expires April 30, 2012 [Page 12] Internet-Draft Oct 2011 - 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 5.1. Energy Object and Energy Management Domain In building management, a meter refers to the meter provided by the utility used for billing and measuring power to an entire building or unit within a building. A sub-meter refers to a customer or user installed meter that is not used by the utility to bill but instead used to get readings from sub portions of a building. An Energy Management Domain should map 1-1 with a metered or sub-metered portion of the site. An Energy Object is part of a single Energy Management Domain. The Energy Management Domain should be configured on an Energy Object. 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. 5.2. Energy Object Identification and Context 5.2.1 Energy Object Identification Energy Objects MUST contain a value that uniquely identifies the Energy Object among all the Energy Management Domains within an EnMS. A universal identifier (UUID) [RFC4122] MUST be used to uniquely identify an Energy Object. Every Energy Object should have a unique printable name. Possible naming conventions are: textual DNS name, MAC-address of the device, interface ifName, or a text string uniquely Expires April 30, 2012 [Page 13] Internet-Draft Oct 2011 identifying the Energy Object. As an example, in the case of IP phones, the Energy Object name can be the device DNS name. 5.2.2 Context in General In order to aid in reporting and in differentiation between Energy Objects, each Energy Object optionally contains information establishing its business, site, or organizational context within a deployment, i.e. the Energy Object Context. 5.2.3 Context: Importance An Energy Object can provide an importance value in the range of 1 to 100 to help differentiate a device's use or relative value to the site. The importance range is from 1 (least important) to 100 (most important). The default importance value is 1. For example: A typical office environment has several types of phones, which can be rated according to their business impact. A public desk phone has a lower importance (for example, 10) than a business-critical emergency phone (for example, 100). As another example: A company can consider that a PC and a phone for a customer-service engineer is more important than a PC and a phone for lobby use. Although EnMS and administrators can establish their own ranking, the following is a broad recommendation: . 90 to 100 Emergency response . 80 to 90 Executive or business-critical . 70 to 79 General or Average . 60 to 69 Staff or support . 40 to 59 Public or guest . 1 to 39 Decorative or hospitality Expires April 30, 2012 [Page 14] Internet-Draft Oct 2011 5.2.4 Context: Keywords An Energy Object can provide a set of keywords. These keywords are a list of tags that can be used for grouping and summary reporting within or between Energy Management Domains. All alphanumeric characters and symbols, such as #, (, $, !, and &, are allowed. Potential examples are: IT, lobby, HumanResources, Accounting, StoreRoom, CustomerSpace, router, phone, floor2, or SoftwareLab. There is no default value for a keyword. Multiple keywords can be assigned to a device. In such cases, the keywords are separated by commas and no spaces between keywords are allowed. For example, "HR,Bldg1,Private". Another keyword use case is the virtual grouping of Energy Objects. For example, a Power Distribution Unit (PDU) that allows physical entities like outlets to be "ganged" together as a logical entity for simplified management purposes. This is particularly useful for servers with multiple power supplies, where each power supply is connected to a different physical outlet. Other implementations allow "gangs" to be created based on common ownership of outlets, such as business units or load shed priority or other non-physical relationships. For example, current PDU implementations allow for an "M-to-N" mapping between outlet "gangs" and physical outlets: Outlet 1 (physical entity) Outlet 2 (physical entity) Outlet 3 (physical entity) Outlet 4 (physical entity) Outlet Gang A (virtual entity) Outlet Gang B (virtual entity) Gang A -> Outlets 1, 2 and 3 Gang B -> Outlets 3 and 4 Note the allowed overlap on Outlet 3, where Outlet 3 belongs to both "gangs". The keywords concept for this specific example would be used as such: Outlet 1 Energy Object 1, keywords: gangA Expires April 30, 2012 [Page 15] Internet-Draft Oct 2011 Outlet 2 Energy Object 2, keywords: gangA Outlet 3 Energy Object 3, keywords: gangA, gangB Outlet 4 Energy Object 4, keywords: gangB Each "Outlet Gang" virtual entity, aggregated based on the value of the keywords, reports the aggregated data from the individual outlet entities that comprise it. The same concept enables a single point of control for all the individual outlet entities. For example, turning "Outlet Gang A" to the "off" state would turn outlets 1, 2, and 3 "off" in some implementations. Note that the impact of this action on "Outlet Gang B" is out of scope of this document. 5.2.5 Context: Role An Energy 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 Expires April 30, 2012 [Page 16] Internet-Draft Oct 2011 Role as a two-word string: "Faculty Desktop", "Teller Phone", "Shipping HVAC", "Advertising Display", "Helpdesk Kiosk", "Administration Switch". 5.3. 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. . For Example: A Power-over-Ethernet (PoE) device (such as an IP phone or an access point) is attached to a switch port. The switch is the source of Power for the attached device, so the Energy Object Parent is the switch, and the Energy Object Child is the device attached to the switch. 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. The Energy Object Child MUST keep track of its Energy Object Parent(s) along with the Energy Object Relationships type. The Energy Object Parent MUST keep track of its Energy Object Child(ren). While the Energy Object Relationships provide the different topologies information to all the EnMS in a consistent way, their implementation is optional. 5.3.1 Energy Object Children Discovery There are multiple ways that the Energy Object Parent can discover its Energy Object Children, if they are not present on the same physical network: . 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 Expires April 30, 2012 [Page 17] Internet-Draft Oct 2011 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 facilities gateway. A typical example is a converged building gateway, monitoring several other devices in the building, and serving as a proxy between SNMP and a protocol such as BACNET. . Energy Object Parent/Energy Object Child relationships may be set by manual or automatic network configuration functions. Note that the communication specifications between the Energy Object Parent and Children is out of the scope of this document. 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. 5.4. 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 but MUST provide information converted to and expressed in watt hours. Each Energy Object will have information that describes Power information along with how that measurement was obtained or derived. 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 odometers that provide the Energy used, produced, and net Energy in Kwh. These values are odometers that accumulate the Power readings. If Energy values are returned then the three odometers must be provided along a description of accuracy. Expires April 30, 2012 [Page 18] Internet-Draft Oct 2011 Optionally, an Energy Object can provide Demand information over time 5.4.1 Power Measurement A Power measurement must be qualified with the units, magnitude, direction of power flow, and by what means the measurement was made (ex: Root Mean Square versus Nameplate). In addition, the Energy 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 EMS. Power measurement magnitude should conform to the IEC 61850 definition of unit multiplier for the SI (System International) units of measure. Measured values are represented in SI units obtained by BaseValue * 10 raised to the power of the scale. For example, if current power usage of an Energy Object is 3, it could be 3 W, 3 mW, 3 KW, or 3 MW, depending on the value of the scaling factor. Energy is often billed in kilowatt-hours instead of megajoules from the SI units. Similarly, battery charge is often measured as miliamperes-hour (mAh) instead of coulombs from the SI units. The units used in this framework are: W, A, Wh, Ah, V. A conversion from Wh to Joule and from Ah to Coulombs is obviously possible, and can be described if required. In addition to knowing the usage and magnitude, it is useful to know how an Energy 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 EMS can use this information to account for the accuracy and nature of the reading between different implementations. Expires April 30, 2012 [Page 19] Internet-Draft Oct 2011 The EMS can use the Nameplate Power for provisioning, capacity planning and potentially billing. 5.4.2 Optional Power Quality Given a Power measurement, it may in certain circumstances be desirable to know the Power Quality associated with that measurement. The information model must adhere to the IEC 61850 7-2 standard for describing AC measurements. Note that the Power Quality include two sets of characteristics: characteristics as received from the utility, and characteristics depending on how the Power is used. In some Energy Management Domains, the power quality may not be needed, available, or relevant to the EMS. Optional Demand It is well known in commercial electrical utility rates that Demand is used as a measurement for billing. Also the highest peak demand measured over a time horizon, such as 1 month or 1 year, is often the basis for charges. A single window of time of high usage can penalize the consumer with higher energy consumption charges. However, it is relevant to measure the Demand only when there are actual power measurements from an Energy 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 . battery type . nominal and remaining capacity . current charge . current state (charging, discharging, not in use, etc.) . number of charging cycles Expires April 30, 2012 [Page 20] Internet-Draft Oct 2011 . expected remaining time that the battery can serve as power supply . expected remaining lifetime of the battery Beyond that a device containing a battery should be able to generate alarms when the battery charge falls below a given threshold and when the battery needs to be replaced. 5.5. Energy Control Energy Objects can be controlled by setting it to a Power State. Power States Sets can be seen as an interface by which an Energy Object can be controlled. Each Energy Object should indicate the Power State Sets that it implements. Well known Power State Sets should be registered with IANA When and individual Power State is configured from a specific Power State Set, an Energy Object may be busy at the request time. The Energy Object will set the desired state and then update the actual Power State when the priority task is finished. This mechanism implies two different Power State variables: actual versus desired There are several standards and implementations of Power State Set. An Energy Object can support one or multiple Power State Set implementations concurrently. This framework list three initial possible Power State Series that can be supported by an Energy Object: IEEE1621 - [IEEE1621] DMTF - [DMTF] EMAN - Specified here 5.5.1 IEEE1621 Power State Series The IEEE1621 Power State Series [IEEE1621] consists of 3 rudimentary states : on, off or sleep. on(0) - The device is fully On and all features of the device are in working mode. Expires April 30, 2012 [Page 21] Internet-Draft Oct 2011 off(1) - The device is mechanically switched off and does not consume energy. sleep(2) - The device is in a power saving mode, and some features may not be available immediately. 5.5.2 DMTF Power State Series DMTF [DMTF] standards organization has defined a power profile standard based on the CIM (Common Information Model) model that consists of 15 power states ON (2), SleepLight (3), SleepDeep (4), Off-Hard (5), Off-Soft (6), Hibernate(7), PowerCycle Off- Soft (8), PowerCycle Off-Hard (9), MasterBus reset (10), Diagnostic Interrupt (11), Off-Soft-Graceful (12), Off-Hard Graceful (13), MasterBus reset Graceful (14), Power-Cycle Off- Soft Graceful (15), PowerCycle-Hard Graceful (16). DMTF standard is targeted for hosts and computers. Details of the semantics of each Power State within the DMTF Power State Series can be obtained from the DMTF Power State Management Profile specification [DMTF]. DMTF power profile extends ACPI power states. The following table provides a mapping between DMTF and ACPI Power State Series and EMAN Power State Sets (described in the next section): State DMTF Power ACPI EMAN Power State State State Name Non-operational states: 1 Off-Hard G3, S5 MechOff 2 Off-Soft G2, S5 SoftOff 3 Hibernate G1, S4 Hibernate 4 Sleep-Deep G1, S3 Sleep 5 Sleep-Light G1, S2 Standby 6 Sleep-Light G1, S1 Ready Operational states: 7 On G0, S0, P5 LowMinus 8 On G0, S0, P4 Low 9 On G0, S0, P3 MediumMinus 10 On G0, S0, P2 Medium 11 On G0, S0, P1 HighMinus 12 On G0, S0, P0 High Expires April 30, 2012 [Page 22] Internet-Draft Oct 2011 Figure 3: DMTF / ACPI Power State Mapping 5.5.3 EMAN Power State Set The EMAN Power State Set represents an attempt for a uniform standard approach to model the different levels of Power of a device. The EMAN Power States are an expansion of the basic Power States as defined in [IEEE1621] that also incorporate the Power States defined in [ACPI] and [DMTF]. Therefore, in addition to the non-operational states as defined in [ACPI] and [DMTF] standards, several intermediate operational states have been defined. There are twelve Power States, that expand on [IEEE1621] on, sleep and off. The expanded list of Power States are divided into six operational states, and six non-operational states. The lowest non-operational state is 1 and the highest is 6. Each non-operational state corresponds to an [ACPI] Global and System states between G3 (hard-off) and G1 (sleeping). For each operational state represent a performance state, and may be mapped to [ACPI] states P0 (maximum performance power) through P5 (minimum performance and minimum power). In each of the non-operational states (from mechoff(1) to ready(6)), the Power State preceding it is expected to have a lower Power value and a longer delay in returning to an operational state: IEEE1621 Power(off): mechoff(1) : An off state where no Energy 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. IEEE1621 Power(sleep) 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 Expires April 30, 2012 [Page 23] Internet-Draft Oct 2011 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. sleep(4) : No Energy Object features are available, except for out-of-band management, for example wake-up mechanisms. The time for availability is longer than standby(5). An example for state sleep(4) is a save-to-RAM state, where DRAM context is maintained. Typically, energy consumption is close to zero. This corresponds to state G1, S3 in ACPI. standby(5) : No Energy Object features are available, except for out-of-band management, for example wake-up mechanisms. This mode is analogous to cold-standy. The time for availability is longer than ready(6). For example, the processor context is not maintained. Typically, energy consumption is close to zero. This corresponds to state G1, S2 in ACPI. ready(6) : No Energy Object features are available, except for out-of-band management, for example 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. IEEE1621 Power(on): 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. Expires April 30, 2012 [Page 24] Internet-Draft Oct 2011 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. 6. Structure of the Information Model: UML Representation The following basic UML represents an information model expression of the concepts in this framework. This information model, provided as a reference for implementers, is represented as an MIB in the different related IETF Energy Monitoring documents. However, other programming structure with different data models could be used as well. Notation is a shorthand UML with lowercase types considered platform or atomic types (i.e. int, string, collection). Uppercase types denote classes described further. Collections and cardinality are expressed via qualifier notation. Attributes labeled static are considered class variables and global to the class. Algorithms for class variable initialization, constructors or destructors are not shown EDITOR'S NOTE: the first part of the UML must be aligned with the latest [EMAN-AWARE-MIB] document version. EO RELATIONSHIPS AND CONTEXT +----------------------------+ | _Child Specific Info __ | |----------------------------| +---------------------------+ | parentId : UUID | | Context Information | | parentProxyAbilities | |---------------------------| | : bitmap | | roleDescription : string | | _mgmtMacAddress : octets | | keywords[0..n] : string | | mgmtAddress : inetaddress | | importance : int | | mgmtAddressType : enum | | category : enum | | mgmtDNSName : inetaddress | +---------------------------+ +----------------------------+ | | | | | | Expires April 30, 2012 [Page 25] Internet-Draft Oct 2011 v v +-----------------------------------------+ | Energy Object Information | |-----------------------------------------| | index : int | | energyObjectId | UUID | | name : string | | meterDomainName | string | | alternateKey | string | +-----------------------------------------+ ^ | | | +-------------------------+ | Links Object | |-------------------------| | physicalEntity : int | | ethPortIndex : int | | ethPortGrpIndex : int | | lldpPortNumber : int | +-------------------------+ EO AND MEASUREMENTS +-----------------------------------------------+ | Energy Object | |-----------------------------------------------| | nameplate : Measurement | | battery[0..n]: Battery | | measurements[0..n]: Measurement | | --------------------------------------------- | | Measurement instantaneousUsage() | | DemandMeasurement historicalUsage() | +-----------------------------------------------+ +-----------------------------------+ | Measurements | | __________________________________| +-----------------------------------+ ^ | | +------------------+----------------------------+ | PowerMeasurement | Expires April 30, 2012 [Page 26] Internet-Draft Oct 2011 |-----------------------------------------------| | value : long | | rate : enum {0,millisecond,seconds, | | minutes,hours,...} | | multiplier : enum {-24..24} | | units : "watts" | | caliber : enum { actual, estimated, | | trusted, assumed...} | | accuracy : enum { 0..10000} | | current : enum {AC, DC} | | origin : enum { self, remote } | | time : timestamp | | quality : PowerQuality | +-----------------------------------------------+ | | +------------------+----------------------------+ | EnergyMeasurement | |-----------------------------------------------| | consumed : long | | generated : long | | net : long | | accuracy : enum { 0..10000} | +-----------------------------------------------+ +-----------------------------------------------+ | TimeMeasurement | |-----------------------------------------------| | startTime : timestamp | | usage : Measurement | | maxUsage : Measurement | +-----------------------------------------------+ | | +----------------------------------------+ | TimeInterval | |--------------------------------------- | |value : long | |units : enum { seconds, miliseconds..} | +----------------------------------------+ | | +----------------------------------------+ | DemandMeasurement | |----------------------------------------| |intervalLength : TimeInterval | |intervalNumbers: long | Expires April 30, 2012 [Page 27] Internet-Draft Oct 2011 |intervalMode : enum { period, sliding, | |total } | |intervalWindow : TimeInterval | |sampleRate : TimeInterval | |status : enum {active, inactive } | |measurements : TimedMeasurement[] | +----------------------------------------+ QUALITY +----------------------------------------+ | PowerQuality | |----------------------------------------| | | +----------------------------------------+ ^ | | +------------------+--------------------+ | 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 | +------------------------------------+ Expires April 30, 2012 [Page 28] Internet-Draft Oct 2011 ^ ^ | | | | | | | | +-------------------------------+---+ | | DelPhase | | |-----------------------------------| | |phaseToNextPhaseVoltage : long | | |thdVoltage : long | | |thdCurrent : long | | +-----------------------------------+ | | +------------------+-----------+ | WYEPhase | |------------------------------| |phaseToNeutralVoltage : long | |thdCurrent : long | |thdVoltage : long | +------------------------------+ EO & STATES +----------------------------------------------+ | Energy Object | |----------------------------------------------| | currentLevel : int | | configuredLevel : int | | configuredTime : timestamp | | reason: string | | emanLevels[0..11] : State | | levelMappings[0..n] : LevelMapping | +----------------------------------------------+ +-------------------------------+ | State | |-------------------------------| | name : string | | cardinality : int | | maxUsage : Measurement | +-------------------------------+ Expires April 30, 2012 [Page 29] Internet-Draft Oct 2011 Figure 8: Information Model UML Representation 7. Configuration This power management framework allows the configuration of the following key parameters: . Energy Object name: A unique printable name for the Energy Object. . Energy Object role: An administratively assigned name to indicate the purpose an Energy Object serves in the network. . Energy Object importance: A ranking of how important the Energy Object is, on a scale of 1 to 100, compared with other Energy Objects in the same Energy Management Domain. . Energy Object keywords: A list of keywords that can be used to group Energy Objects for reporting or searching. . Energy Management Domain: Specifies the name of an Energy Management Domain for the Energy Object. . Energy Object Power State: Specifies the current Power State (0..12) for the Energy Object. . Demand parameters: For example, which interval length to report the Deman over, the number of intervals to keep, etc. . Assigning an Energy Object Parent to an Energy Object Child . Assigning an Energy Object Child to an Energy Object Parent. This framework supports multiple means for setting the Power State of a specific Energy Object. However, the Energy Object might be busy executing an important task that requires the current Power State for some more time. For example, a PC might have to finish a backup first, or an IP phone might be busy with a current phone call. Therefore a second value contains the actual Power State. A difference in values between the two objects indicates that the Energy Object is currently in Power State transition. Other, already well established means for setting Power States, such as DASH [DASH], already exist. Such a protocol may be implemented between the Energy Object Parent and the Energy Object Child, when the Energy Object Parent acts as a Proxy. Expires April 30, 2012 [Page 30] Internet-Draft Oct 2011 Note that the Wake-up-on-Lan (WoL) mechanism allows to transition a device out of the Off Power State. 8. Fault Management [EMAN-REQ] specifies some requirements about Power States such as "the current state - the time of the last change", "the total time spent in each state", "the number of transitions to each state", etc. Such requirements are fulfilled via the pmPowerStateChange NOTIFICATION-TYPE [EMAN-MON-MIB]. This SNMP notification is generated when the value(s) of Power State has changed for the Energy Object. Regarding high and low thresholding mechanism, the RMON alarm and event [RFC2819] allows to periodically takes statistical samples from Energy Object variables, compares them to previously configured thresholds, and to generate an event (i.e. an SNMP notification) if the monitored variable crosses a threshold. The RMON alarm can monitor variables that resolve to an ASN.1 primitive type of INTEGER (INTEGER, Integer32, Counter32, Counter64, Gauge32, or TimeTicks), so basically most the variables in [EMAN-MON-MIB]. 9. Relationship with Other Standards Development Organizations 9.1. Information Modeling This power management framework should, as much as possible, reuse existing standards efforts, especially with respect to information modeling and data modeling [RFC3444]. The data model for power, energy related objects is based on IEC 61850. Specific examples include: . The scaling factor, which represents Energy 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: Expires April 30, 2012 [Page 31] Internet-Draft Oct 2011 . IEC 62053-22 60044-1 class 0.1, 0.2, 0.5, 1 3. . ANSI C12.20 class 0.2, 0.5 . The electrical characteristics and quality adheres closely to the IEC 61850 7-2 standard for describing AC measurements. . The power state definitions are based on the DMTF Power State Profile and ACPI models, with operational state extensions. 10. Security Considerations Regarding the data attributes specified here, some or all may be considered sensitive or vulnerable in some network environments. Reading or writing these attributes without proper protection such as encryption or access authorization may have negative effects on the network capabilities. 10.1. Security Considerations for SNMP Readable objects in a MIB modules (i.e., objects with a MAX- ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control GET and/or NOTIFY access to these objects and possibly to encrypt the values of these objects when sending them over the network via SNMP. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. For example: . Unauthorized changes to the Power Domain or business context of an Energy 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 Expires April 30, 2012 [Page 32] Internet-Draft Oct 2011 secure (for example, by using IPsec), there is still no secure control over who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in these MIB modules. It is recommended that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is not recommended. Instead, it is recommended to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of these MIB modules is properly configured to give access to the objects only to those principals (users) that have legitimate rights to GET or SET (change/create/delete) them. 11. IANA Considerations Initial values for the Power State Sets, together with the considerations for assigning them, are defined in [EMAN-MON- MIB]. 12. Acknowledgments The authors would like to Michael Brown for improving the text dramatically, and Bruce Nordman for his excellent feedback. 13. References Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2819] S. Waldbusser, "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000 Expires April 30, 2012 [Page 33] Internet-Draft Oct 2011 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet Standard Management Framework ", RFC 3410, December 2002. [RFC4122] Leach, P., Mealling, M., and R. Salz," A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005 Informative References [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. [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-04, (work in progress), July 2010. [EMAN-AWARE-MIB] Parello, J., and B. Claise, "Energy-aware Networks and Devices MIB", draft-ietf-eman-energy- aware-mib-02, (work in progress), July 2011. [EMAN-MON-MIB] Chandramouli, M.,Schoening, B., Quittek, J., Dietz, T., and B. Claise, "Power and Energy Monitoring Expires April 30, 2012 [Page 34] Internet-Draft Oct 2011 MIB", draft-ietf-eman-energy-monitoring-mib-00, (work in progress), August 2011. [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, " Definition of Managed Objects for Battery Monitoring", draft-ietf-eman-battery-mib-03, (work in progress), August 2011. [EMAN-AS] Tychon, E., Schoening, B., Chandramouli, M., and B. Nordman, "Energy Management (EMAN) Applicability Statement", draft-tychon-eman-applicability-statement- 04, (work in progress), October 2011 [DASH] "Desktop and mobile Architecture for System Hardware", http://www.dmtf.org/standards/mgmt/dash/ [ISO50001] "ISO 50001:2011 Energy management systems - Requirements with guidance for use", http://www.iso.org/ [DMTF] "Power State Management Profile DMTF DSP1027 Version 2.0" December 2009 http://www.dmtf.org/sites/default/files/standards/docum ents/DSP1027_2.0.0.pdf [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. Authors' Addresses Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1813 BE Phone: +32 2 704 5622 Email: bclaise@cisco.com John Parello Cisco Systems, Inc. Expires April 30, 2012 [Page 35] Internet-Draft Oct 2011 3550 Cisco Way San Jose, California 95134 US Phone: +1 408 525 2339 Email: jparello@cisco.com Brad Schoening 44 Rivers Edge Drive Little Silver, NJ 07739 US Phone: Email: brad@bradschoening.com Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511 15 EMail: quittek@netlab.nec.de Expires April 30, 2012 [Page 36]