idnits 2.17.1 draft-ietf-eman-applicability-statement-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 22) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 21, 2014) is 3651 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3805' is mentioned on line 1015, but not defined == Unused Reference: 'DASH' is defined on line 1240, but no explicit reference was found in the text == Unused Reference: 'DMTF' is defined on line 1279, but no explicit reference was found in the text == Unused Reference: 'IEC62301' is defined on line 1313, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-eman-applicability-statement-04 -- No information found for draft-ietf-eman-monitoring-mib - is the name correct? == Outdated reference: A later version (-19) exists of draft-ietf-eman-framework-10 == Outdated reference: A later version (-20) exists of draft-ietf-eman-battery-mib-09 == Outdated reference: A later version (-09) exists of draft-parello-eman-definitions-08 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Energy Management Working Group Brad Schoening 3 Internet Draft Independent Consultant 4 Intended status: Informational Mouli Chandramouli 5 Expires: October 18, 2014 Cisco Systems Inc. 6 Bruce Nordman 7 Lawrence Berkeley National Laboratory 8 April 21, 2014 10 Energy Management (EMAN) Applicability Statement 11 draft-ietf-eman-applicability-statement-05 13 Abstract 15 The objective of Energy Management (EMAN) is to provide an 16 energy management framework for networked devices. This 17 document presents the applicability of the EMAN framework to a 18 variety of scenarios. This document lists use cases and target 19 devices that can potentially implement the EMAN framework and 20 associated SNMP MIB modules. These use cases are useful for 21 identifying requirements for the framework and MIBs. Further, 22 we describe the relationship of the EMAN framework to relevant 23 other energy monitoring standards and architectures. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance 28 with the provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet 31 Engineering Task Force (IETF), its areas, and its working 32 groups. Note that other groups may also distribute working 33 documents as Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other 37 documents at any time. It is inappropriate to use Internet- 38 Drafts as reference material or to cite them other than as "work 39 in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 This Internet-Draft will expire on October 18, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described 61 in Section 4.e of the Trust Legal Provisions and are provided 62 without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction ............................................... 3 67 1.1. Energy Management Overview ............................. 4 68 1.2. EMAN Document Overview ................................. 4 69 1.3. Energy Measurement ..................................... 5 70 1.4. Energy Management ...................................... 5 71 1.5. EMAN Framework Application ............................. 6 72 2. Scenarios and Target Devices ............................... 7 73 2.1. Network Infrastructure Energy Objects .................. 7 74 2.2. Devices Powered by and Connected to a Network Device ... 8 75 2.3. Devices Connected to a Network ......................... 9 76 2.4. Power Meters .......................................... 10 77 2.5. Mid-level Managers .................................... 11 78 2.6. Non-residential Building System Gateways .............. 11 79 2.7. Home Energy Gateways .................................. 12 80 2.8. Data Center Devices ................................... 13 81 2.9. Energy Storage Devices ................................ 14 82 2.10. Industrial Automation Networks ....................... 15 83 2.11. Printers ............................................. 15 85 2.12. Off-Grid Devices ..................................... 16 86 2.13. Demand Response ...................................... 17 87 2.14. Power Capping ........................................ 17 88 3. Use Case Patterns ......................................... 18 89 3.1. Metering .............................................. 18 90 3.2. Metering and Control .................................. 18 91 3.3. Power Supply, Metering and Control .................... 18 92 3.4. Multiple Power Sources ................................ 18 93 4. Relationship of EMAN to other Standards ................... 19 94 4.1. Data Model and Reporting .............................. 19 95 4.1.1. IEC - CIM...................................... 19 96 4.1.2. DMTF........................................... 19 97 4.1.3. ODVA........................................... 21 98 4.1.4. Ecma SDC....................................... 21 99 4.1.5. PWG............................................ 22 100 4.1.6. ASHRAE......................................... 22 101 4.1.7. ZigBee......................................... 23 102 4.2. Measurement ........................................... 23 103 4.2.1. ANSI C12....................................... 24 104 4.2.2. IEC 62301...................................... 24 105 4.3. Other ................................................. 24 106 4.3.1. ISO............................................ 24 107 4.3.2. Energy Star.................................... 25 108 4.3.3. Smart Grid..................................... 25 109 5. Limitations ............................................... 26 110 6. Security Considerations ................................... 26 111 7. IANA Considerations ....................................... 27 112 8. Acknowledgements .......................................... 27 113 9. References ................................................ 27 114 9.1. Normative References .................................. 27 115 9.2. Informative References ................................ 27 117 1. Introduction 119 The focus of the Energy Management (EMAN) framework is energy 120 monitoring and management of energy objects [EMAN-DEF]. The 121 scope of devices considered are network equipment and its 122 components, and devices connected directly or indirectly to 123 the network. The EMAN framework enables monitoring 124 (heterogeneous devices to report their energy consumption) 125 and, if permissible, control. There are multiple scenarios 126 where this is desirable, particularly considering the 127 increased importance of limiting consumption of finite energy 128 resources and reducing operational expenses. 130 The EMAN framework [EMAN-FRAMEWORK] describes how energy 131 information can be retrieved from IP-enabled devices using 132 Simple Network Management Protocol (SNMP), specifically, 133 Management Information Base (MIBs) for SNMP. 135 This document describes typical applications of the EMAN 136 framework, as well as its opportunities and limitations. It 137 also reviews other standards that are similar in part to EMAN 138 those other standards relate to the EMAN framework. 140 The rest of the document is organized as follows. Section 2 141 contains a list of use cases or network scenarios that EMAN 142 addresses. Section 3 contains an abstraction of the use case 143 scenarios to distinct patterns. Section 4 deals with other 144 standards related to EMAN and applicable to EMAN. 146 1.1. Energy Management Overview 148 EMAN addresses the electrical energy consumed by devices 149 connected to a network. A first step to increase the energy 150 efficiency in networks and devices attached to the network 151 is to enable energy objects to report their energy usage over 152 time. The EMAN framework addresses this problem with an 153 information model for electrical equipment: energy object 154 identification, energy object context, power measurement and 155 power characteristics. 157 The EMAN drafts define SNMP MIB modules based on the 158 information model. By implementing the SNMP MIB modules, any 159 energy object can report its energy consumption according to the 160 information model. While the MIB drafts contain MIB modules, 161 the information model can be adapted to other mechanisms such as 162 YANG modules, NETCONF etc. 164 It is important to distinguish energy objects that can only 166 report their own energy usage from devices that can also collect 168 and aggregate energy usage of other energy objects. 170 Target devices and scenarios considered for energy management 171 are presented in Section 2 with detailed examples. 173 1.2. EMAN Document Overview 175 The EMAN working group charter called for producing a series of 176 Internet standard drafts in the area of energy management. The 177 following drafts were created by the working group. 179 Applicability Statement [EMAN-AS] this document presents use 180 cases and scenarios for energy management. In addition, other 181 relevant energy standards and architectures are discussed. 183 Requirements [EMAN-REQ] this document presents requirements of 184 energy management and the scope of the devices considered. 186 Framework [EMAN-FRAMEWORK] This document defines a framework 187 for providing energy management for devices within or 188 connected to communication networks. 190 Energy-Aware MIB [EMAN-AWARE-MIB] This document proposes a MIB 191 module that characterizes a device identity, context and 192 relationships to other entities. 194 Monitoring MIB [EMAN-MONITORING-MIB] This document defines a 195 MIB module for monitoring the power and energy consumption of 196 a device. The MIB module contains an optional module for 197 metrics associated with power characteristics. 199 Battery MIB [EMAN-BATTERY-MIB] This document contains a MIB 200 module for monitoring characteristics of an internal battery. 202 Energy Management Terminology [EMAN-DEF] This document lists 203 the definitions for the common terms used in the Energy 204 Management Working Group. 206 1.3. Energy Measurement 208 More and more devices are able to measure and report their own 209 energy consumption. Smart power strips and some Power over 210 Ethernet (PoE) switches can meter consumption of connected 211 devices. However, when managed and reported through proprietary 212 means, this information is minimally useful at the enterprise 213 level. 215 The primary goal of the EMAN MIBs is to enable reporting and 216 management within a standard framework that is applicable to a 217 wide variety of end devices, meters, and proxies. This enables 218 a management system to know who's consuming what, when, and how 219 at any time by leveraging existing networks, across various 220 equipment, in a unified and consistent manner. 222 Given that an energy object can consume energy and/or provide 223 energy to other devices, there are three types of energy 224 measurement: energy input to a device, energy supplied to other 225 devices, and net (resultant) energy consumed (the difference 226 between energy input and provided). 228 1.4. Energy Management 230 Beyond energy monitoring, the EMAN framework provides mechanisms 231 for energy control. 233 There are many cases where reducing energy consumption of 234 devices is desirable, such as when the device utilization is low 235 or when the electricity is expensive or in short supply. 237 In some cases, energy control requires considering the energy 238 object context. For instance, in a building during non-business 239 hours: usually not all phones would be turned off to keep some 240 phones available in case of emergency; and office cooling is 241 usually not turned off totally, but the comfort level is 242 reduced. 244 Energy object control requires flexibility and support for 245 different polices and mechanisms: from centralized management 246 with a network management station, to autonomous management by 247 individual devices, and alignment with dynamic demand-response 248 mechanisms. 250 The EMAN framework can be used as a tool for the demand/response 251 scenario where in response to time-of-day fluctuation of energy 252 costs or possible energy shortages, it is possible to respond 253 and reduce the energy consumption for the network devices, 254 effectively changing its power state. 256 1.5. EMAN Framework Application 258 A Network Management System (NMS) is the entity that requests 259 information from compatible devices using SNMP protocol. An NMS 260 implements many network management functions, e.g. security 261 management, or identity management. An NMS that deals 262 exclusively with energy is called an Energy Management System 263 (EnMS). It may be limited to monitoring energy use, or it may 264 also implement control functions. An EnMS collects energy 265 information for devices in the network. 267 Energy management can be implemented by extending existing SNMP 268 support to the EMAN specific MIBs. SNMP provides an industry 269 proven and well-known mechanism to discover, secure, measure, 270 and control SNMP-enabled end devices. The EMAN framework 271 provides an information and data model to unify access to a 272 large range of devices. 274 The scope of the target devices and the network scenarios 275 considered for energy management are listed in Section 2. 277 2. Scenarios and Target Devices 279 In this section a selection of scenarios for energy management 280 are presented. The fundamental objective of the use cases is to 281 list important network scenarios that the EMAN framework should 282 solve. These use cases then drive the requirements for the EMAN 283 framework. 285 Each scenario lists target devices for which the energy 286 management framework can be applied, how the reported-on devices 287 are powered, and how the reporting is accomplished. While there 288 is some overlap between some of the use cases, the use cases 289 illustrate network scenarios that the EMAN framework supports. 291 2.1. Network Infrastructure Energy Objects 293 This scenario covers network devices and their components. 294 Power management of energy objects is a fundamental requirement 295 of energy management of networks. 297 It can be important to monitor the energy consumption and 298 possibly manage the power state of these devices at a 299 granularity level finer than just the entire device. For these 300 devices, the chassis draws power from one or more sources and 301 feeds all its internal components. It is highly desirable to 302 have monitoring available for individual components, such as 303 line cards, processors, and disk drives as well as peripherals 304 such as USB devices. 306 As an illustrative example, consider a switch with the following 307 grouping of sub-entities for which energy management could be 308 useful. 310 . physical view: chassis (or stack), line cards, service 311 modules of the switch. 312 . component view: CPU, ASICs, fans, power supply, ports 313 (single port and port groups), storage and memory. 315 The ENTITY-MIB provides the containment tree framework, for 316 uniquely identifying the physical sub-components of network 317 devices. A component can be an Energy Object and the ENTITY-MIB 318 containment tree expresses if one Energy Object belongs to 319 another Energy Object (e.g. a line-card Energy Object contained 320 in a chassis Energy Object). The table entPhysicalContainsTable 321 which has the index of entPhysicalChildIndex and the MIB object 322 entPhysicalContainedIn which points to the containing entity. 324 The essential properties of this use case are: 326 . Target devices: network devices such as routers and 327 switches as well as their components. 328 . How powered: typically by a Power Distribution Unit (PDU) 329 on a rack or from a wall outlet. The components of a 330 device are powered by the device chassis. 331 . Reporting: direct power measurement can be performed at a 332 device level. Components can report their power 333 consumption directly or the chassis/device that can report 334 on behalf of some components. 336 2.2. Devices Powered by and Connected to a Network Device 338 This scenario covers Power over Ethernet (PoE) devices. A PoE 339 Power Sourcing Equipment (PSE) device [RFC3621] (e.g. a PoE 340 switch) provides power to a Powered Device (PD) (e.g. a desktop 341 phone). For each port, the PSE can control the power supply 342 (switching it on and off) and meter actual power provided. PDs 343 obtain network connectivity as well as power over a single 344 connection so the PSE can determine which device is associated 345 with each port. 347 PoE ports on a switch are commonly connected to devices such as 348 IP phones, wireless access points, and IP cameras. The switch 349 needs power for its internal use and to supply power to PoE 350 ports. Monitoring the power consumption of the switch 351 (supplying device) and the power consumption of the PoE end- 352 points (consuming devices) is a simple use case of this 353 scenario. 355 This scenario illustrates the relationships between entities. 356 The PoE IP phone is powered by the switch. If there are many IP 357 phones connected to the same switch and the power consumption of 358 all the IP phones can be aggregated by the switch. In that 359 case, the switch performs the aggregation function for other 360 entities. 362 The essential properties of this use case are: 364 . Target devices: power over Ethernet devices such as IP 365 phones, wireless access points, and IP cameras. 366 . How powered: PoE devices are connected to the switch port 367 which supplies power to those devices. 368 . Reporting: PoE device power consumption is measured and 369 reported by the switch (PSE) which supplies power. In 370 addition, some edge devices can support the EMAN framework. 372 This use case can be divided into two sub cases: 374 a) The end device supports the EMAN framework, in which case 375 this device is an EMAN Energy Object by itself, with its own 376 UUID, like in scenario "Devices Connected to a Network" 377 below. The device is responsible for its own power 378 reporting and control. 380 b) The end device does not have EMAN capabilities, and the 381 power measurement may not be able to be performed 382 independently, and so is only performed by the supplying 383 device. This scenario is similar to the "Mid-level Manager" 384 below. 386 In the sub case (a) note that two power usage reporting 387 mechanisms for the same device are available: one performed by 388 the PD itself and one performed by the PSE. Device specific 389 implementations will dictate which one to use. 391 It is also possible to illustrate the relationships between 392 entities. The PoE IP phone is powered by the switch. If there 393 are many IP phones connected to the same switch and the power 394 consumption of all the IP phones can be aggregated by the 395 switch. In that case, the switch performs the aggregation 396 function for other entities. 398 2.3. Devices Connected to a Network 400 The use case covers the metering relationship between an energy 401 object and the parent energy object it is connected to, while 402 receiving power from a different source. 404 An example is a PC which has a network connection to a switch, 405 but draws power from a wall outlet. In this case, the PC can 406 report power usage by itself, ideally through the EMAN 407 framework. 409 The wall outlet the PC is plugged in can be metered for example 410 by a Smart PDU, or unmetered. 412 a) If metered, the PC has a powered-by relationship to the Smart 413 PDU, and the Smart PDU acts as a "Mid-Level Manager" 415 b) If unmetered - or running on batteries - the PC will report 416 its own energy usage as any other Energy Object to the switch, 417 and the switch can possibly provide aggregation. 419 These two cases are not mutually exclusive. 421 In terms of relationships between entities, the PC has a powered 422 by relationship to the PDU and if the power consumption of the 423 PC is metered by the PDU then there is a metered by relation 424 between the PC and the PDU. 426 The essential properties of this use case are: 428 . Target devices: energy objects that have a network 429 connection, but receive power supply from another source. 430 . How powered: end devices (e.g. PCs) receive power supply 431 from the wall outlet (unmetered), or a PDU (metered). That 432 can also be powered autonomously (batteries). 433 . Reporting: devices can measure and report the power 434 consumption directly via the EMAN framework, or, 435 communicate it to the network device (switch) and the 436 switch can report the device's power consumption via the 437 EMAN framework. 439 2.4. Power Meters 441 Some electrical devices are not equipped with instrumentation to 442 measure their own power and accumulated energy consumption. 443 External meters can be used to measure the power consumption of 444 such electrical devices as well as collections of devices. This 445 use case covers energy objects able to measure or report the 446 power consumption of external electrical devices, not natively 447 connected to the network. 449 Three types of external metering are relevant to EMAN: PDUs, 450 standalone meters, and utility meters. External meters can 451 measure consumption of a single device or a set of devices. 453 Power Distribution Unit (PDUs) usually have inbuilt meters for 454 each socket and so can measure the power supplied to each device 455 in an equipment rack. The PDUs have remote management 456 functionality which can measure and possibly control the power 457 supply of each outlet. 459 Standalone meters can be placed anywhere in a power distribution 460 tree and so may measure the total of groups of devices. Utility 461 meters monitor and report accumulated power consumption of the 462 entire building. There can be sub-meters to measure the power 463 consumption of a portion of the building. 465 The essential properties of this use case are: 467 . Target devices: PDUs and meters. 468 . How powered: from traditional mains power but as passed 469 through a PDU or meter. 470 . Reporting: PDUs report power consumption of downstream 471 devices, usually a single device per outlet. 473 The meters can have a metering relationship and possibly 474 aggregation relationship between the meters and the devices for 475 which power consumption is accumulated and reported by the 476 meter. 478 2.5. Mid-level Managers 480 This use case covers aggregation of energy management data at 481 "mid-level managers" that can provide energy management 482 functions for themselves as well as associated devices. 484 A switch can provide energy management functions for all devices 485 connected to its ports, whether or not these devices are powered 486 by the switch or whether the switch provides immediate network 487 connectivity to the devices. Such a switch is a mid-level 488 manager, offering aggregation of power consumption data for 489 other devices. Devices report their EMAN data to the switch and 490 the switch aggregates the data for further reporting. 492 The essential properties of this use case: 494 . Target devices: devices which can perform aggregation; 495 commonly a switch or a proxy. 496 . How powered: mid-level managers are commonly powered by a 497 PDU or from a wall outlet but can be powered by any method. 498 . Reporting: the middle-manager aggregates the energy data 499 and reports that data to a NMS or higher mid-level manager. 501 2.6. Non-residential Building System Gateways 503 This use case describes energy management of non-residential 504 buildings. Building Management Systems (BMS) have been in place 505 for many years using legacy protocols not based on IP. In these 506 buildings, a gateway can provide a proxy function between IP and 507 legacy building automation protocols. The gateway provides an 508 interface between the EMAN framework and relevant building 509 management protocols. 511 Due to the potential energy savings, energy management of 512 buildings has received significant attention. There are gateway 513 network elements to manage the multiple components of a building 514 energy management system such as Heating, Ventilation, and Air 515 Conditioning (HVAC), lighting, electrical, fire and emergency 516 systems, elevators, etc. The gateway device uses legacy 517 building protocols to communicate with those devices, collects 518 their energy usage, and reports the results. 520 The gateway performs protocol conversion and communicates via 521 RS-232/RS-485 interfaces, Ethernet interfaces, and protocols 522 specific to building management such as BACNET [ASHRAE], MODBUS 523 [MODBUS], or ZigBee [ZIGBEE]. 525 The essential properties of this use case are: 527 . Target devices: building energy management devices - HVAC 528 systems, lighting, electrical, fire and emergency systems. 529 . How powered: any method. 530 . Reporting: the gateway collects energy consumption of non- 531 IP systems and communicates the data via the EMAN 532 framework. 534 2.7. Home Energy Gateways 536 This use case describes the scenario of energy management of a 537 home. The home energy gateway is another example of a proxy 538 that interfaces to electrical appliances and other devices in a 539 home. This gateway can monitor and manage electrical equipment 540 (e.g. refrigerator, heating/cooling, or washing machine) using 541 one of the many protocols that are being developed for 542 residential devices. 544 In its simplest form, metering can be performed at home. Beyond 545 the metering, it is also possible to implement energy saving 546 policies based on energy pricing from the utility grid. The 547 EMAN information model can be applied to energy management of a 548 home. 550 The essential properties of this use case are: 552 . Target devices: home energy gateway and smart meters in a 553 home. 554 . How powered: any method. 555 . Reporting: home energy gateway can collect power 556 consumption of device in a home and possibly report the 557 metering reading to the utility. 559 Beyond the canonical setting of a home drawing power from the 560 utility, it is also possible to envision an energy neutral 561 situation wherein the buildings/homes that can produce and 562 consume energy with reduced or zero net importing energy from 563 the utility grid. There are many energy production technologies 564 such as solar panels, wind turbines, or micro generators. This 565 use case illustrates the concept of covers self-contained energy 566 generation and consumption and possibly the aggregation of the 567 energy use of homes. 569 2.8. Data Center Devices 571 This use case describes energy management of a data center. 572 Energy efficiency of data centers has become a fundamental 573 challenge of data center operation, as datacenters are big 574 energy consumers and have expensive infrastructure. The 575 equipment generates heat, and heat needs to be evacuated though 576 a HVAC system. 578 A typical data center network consists of a hierarchy of 579 electrical energy objects. At the bottom of the network 580 hierarchy are servers mounted on a rack; these are connected to 581 top-of-the-rack switches, which in turn are connected to 582 aggregation switches, and then to core switches. Power 583 consumption of all network elements, servers, and storage 584 devices in the data center should be measured. Energy 585 management can be implemented on different aggregation levels, 586 at the network level, Power Distribution Unit (PDU) level, and 587 server level. 589 Beyond the network devices, storage devices and servers, data 590 centers contain UPSs to provide back-up power for the facility 591 in the event in the event of a power outage. A UPS can provide 592 backup power for many devices in a data center for a finite 593 period of time. Energy monitoring of such energy storage 594 devices is vital from a data center network operations point of 595 view. Presently, the UPS MIB can be useful in monitoring the 596 battery capacity, the input load to the UPS and the output load 597 from the UPS. Currently, there is no link between the UPS MIB 598 and the ENTITY MIB. 600 Thus, for data center energy management, in addition to 601 monitoring the energy usage of IT equipment, it is also 602 important to monitor the remaining capacity of the UPS. 604 In addition to monitoring the power consumption of a data 605 center, additional power characteristic metrics should be 606 monitored. Some of these are dynamic variations in the input 607 power supply from the grid referred to as power characteristics 608 is one metric. Secondly, it can be useful to monitor how 609 efficiently the devices utilize power. 611 The nameplate power consumption (the worst case possible power 612 draw) of all devices will make it possible to know an aggregate 613 of the potential worst-case power usage and compare it to the 614 budgeted power in the data center. 616 The essential properties of this use case are: 618 . Target devices: all IT devices in a data center, such as 619 network equipment, servers, and storage devices, as well as 620 power and cooling infrastructure. 621 . How powered: any method but commonly by one or more PDUs. 622 . Reporting: devices may report on their own behalf, or for 623 other connected devices as described in other use cases. 625 2.9. Energy Storage Devices 627 There are two types of devices with energy storage: those whose 628 primary function is to provide power to another device (e.g. a 629 UPS), and those with a different primary function, but which 630 have energy storage as a component (e.g. a notebook). This use 631 case covers both. 633 The energy storage can be a conventional battery, or any other 634 means to store electricity such as a hydrogen cell. 636 An internal battery can be a back-up or an alternative source of 637 power to mains power. As batteries have a finite capacity and 638 lifetime, means for reporting the actual charge, age, and state 639 of a battery are required. An internal battery can be viewed as 640 a component of a device and so be contained within the device 641 from an ENTITY-MIB perspective. 643 Battery systems are used in mobile telecom towers including for 644 use in remote locations. It is important to monitor the 645 remaining battery life and raise an alarm when this falls below 646 a threshold. 648 The essential properties of this use case are: 650 . Target devices: devices that have an internal battery. 652 . How powered: from internal batteries or mains power. 653 . Reporting: the device reports on its internal battery. 655 2.10. Industrial Automation Networks 657 Energy consumption statistics in the industrial sector are 658 staggering. The industrial sector alone consumes about half of 659 the world's total delivered energy, and is a significant user of 660 electricity. Thus, the need for optimization of energy usage in 661 this sector is natural. 663 Industrial facilities consume energy in process loads, and in 664 non-process loads. 666 The essential properties of this use case are: 668 . Target devices: devices used in industrial automation. 669 . How powered: any method. 670 . Reporting: currently, CIP protocol is currently used for 671 reporting energy for these devices. 673 2.11. Printers 675 This use case describes the scenario of energy monitoring and 676 management of printers. 678 Printers in this use case stand in for all imaging equipment, 679 also including multi-function devices (MFDs), copiers, scanners, 680 fax machines, and mailing machines. 682 Energy use of printers has been an industry concern for several 683 decades, and they usually have sophisticated power management 684 with a variety of low-power modes, particularly for managing 685 energy-intensive thermo-mechanical components. Printers also 686 have long made extensive use of SNMP for end-user system 687 interaction and for management generally, and cross-vendor 688 management systems manage fleets of printers in enterprises. 689 Power consumption during active modes can vary widely, with high 690 peak levels. 692 Printers can expose detailed power state information, distinct 693 from operational state information, with some printers reporting 694 transition states between stable long-term states. Many also 695 support active setting of power states, and setting of policies 696 such as delay times when no activity will cause automatic 697 transition to a lower power mode. Other features include 698 reporting on components, counters for state transitions, typical 699 power levels by state, scheduling, and events/alarms. 701 Some large printers also have a "Digital Front End" which is a 702 computer that performs functions on behalf of the physical 703 imaging system. These typically have their own presence on the 704 network and are sometimes separately powered. 706 There are some unique characteristics of printers from the point 707 of view energy management. While the printer is not in use, 708 there are timer based low power states, which consume little 709 power. On the other hand, while the printer is printing or 710 copying the cylinder needs to be heated so that power 711 consumption is quite high but only for a short period of time. 712 Given this work load, periodic polling of power levels alone 713 would not suffice. 715 The essential properties of this use case are: 717 . Target devices: all imaging equipment. 718 . How powered: typically AC from a wall outlet. 719 . Reporting: devices report for themselves. 721 2.12. Off-Grid Devices 723 This use case concerns self-contained devices that use energy 724 but are not connected to an infrastructure power delivery grid. 725 These devices typically scavenge energy from environmental 726 sources such as solar energy or wind power. The device 727 generally contains a closely coupled combination of 729 . power scavenging or generation component(s) 730 . power storage component(s) (e.g., battery) 731 . power consuming component(s) 733 With scavenged power, the energy input is often dependent on the 734 random variations of the weather. These devices therefore 735 require energy management both for internal control and remote 736 reporting of their state. In order to optimize the performance 737 of these devices and minimize the costs of the generation and 738 storage components, it is desirable to vary the activity level, 739 and, hopefully, the energy requirements of the consuming 740 components in order to make best use of the available stored and 741 instantaneously generated energy. With appropriate energy 742 management, the overall device can be optimized to deliver an 743 appropriate level of service without over provisioning the 744 generation and storage components. 746 In many cases these devices are expected to operate 747 autonomously, as continuous communications for the purposes of 748 remote control is either impossible or would result in excessive 749 power consumption. Non continuous polling requires the ability 750 to store and access later the information collected while the 751 communication was not possible. 753 The essential properties of this use case are: 755 Target Devices: remote network devices (mobile network) that 756 consume and produce energy. 757 How Powered: can be battery powered or using local energy 758 sources. 759 Reporting: devices report their power usage, but only 760 occasionally. 762 2.13. Demand Response 764 The theme of demand response from a utility grid spans across 765 several use cases. In some situations, in response to time-of- 766 day fluctuation of energy costs or sudden energy shortages due 767 power outages, it may be important to respond and reduce the 768 energy consumption of the network. 769 From EMAN use case perspective, the demand response scenario can 770 apply to a Data Center or a Building or a residential home. As 771 a first step, it may be important to monitor the energy 772 consumption in real-time of a Data center, building or home 773 which is already discussed in the previous use cases. Then 774 based on the potential energy shortfall, the EnMS could 775 formulate a suitable response. The EnMS could shut down 776 selected devices that are considered lower priority or uniformly 777 reduce the power supplied to all devices. For multi-site data 778 centers it may be possible to formulate policies such as follow- 779 the-sun type of approach, by scheduling the mobility of VMs 780 across Data centers in different geographical locations. 782 2.14. Power Capping 784 Power capping is a technique to limit the total power 785 consumption of a server, and it can be useful for power limited 786 data centers. Based on workload measurements, the server can 787 choose the optimal power state of the server in terms of 788 performance and power consumption. When the server operates at 789 less than the power supply capacity, it runs at full speed. 790 When the server power would be greater than the power supply 791 capacity, it runs at a slower speed so that its power 792 consumption matches the available power supply capacity. This 793 gives vendors the option to use smaller, cost-effective power 794 supplies that allow real world workloads to run at nominal 795 themselves. 797 3. Use Case Patterns 799 The use cases presented above can be abstracted to the following 800 broad patterns. 802 3.1. Metering 804 - energy objects which have capability for internal metering 805 - energy objects which are metered by an external device 807 3.2. Metering and Control 809 - energy objects that do not supply power, but can perform only 810 power metering for other devices 812 - energy objects that do not supply power, but can perform both 813 metering and control for other devices 815 3.3. Power Supply, Metering and Control 817 - energy objects that supply power for other devices but do not 818 perform power metering for those devices 820 - energy objects that supply power for other devices and also 821 perform power metering 823 - energy objects supply power for other devices and also perform 824 power metering and control for other devices 826 3.4. Multiple Power Sources 828 - energy objects that have multiple power sources and metering 829 and control are performed by the same power source 831 - energy objects that have multiple power sources supplying 832 power to the device and metering is performed by one source and 833 control is performed by another source 835 4. Relationship of EMAN to other Standards 837 The EMAN framework is tied to other standards and efforts that 838 deal with energy. EMAN leverages existing standards when 839 possible, and it helps enable adjacent technologies such as 840 Smart Grid. 842 The standards most relevant and applicable to EMAN are listed 843 below with a brief description of their objectives, the current 844 state and how that standard relates to EMAN. 846 4.1. Data Model and Reporting 848 4.1.1. IEC - CIM 850 The International Electro-technical Commission (IEC) has 851 developed a broad set of standards for power management. Among 852 these, the most applicable to EMAN is IEC 61850, a standard for 853 the design of electric utility automation. The abstract data 854 model defined in 61850 is built upon and extends the Common 855 Information Model (CIM). The complete 61850 CIM model includes 856 over a hundred object classes and is widely used by utilities 857 worldwide. 859 This set of standards was originally conceived to automate 860 control of a substation (facilities which transfer electricity 861 from the transmission to the distribution system). However, the 862 extensive data model has been widely used in other domains, 863 including Energy Management Systems (EMS). 865 IEC TC57 WG19 is an ongoing working group to harmonize the CIM 866 data model and 61850 standards. 868 Several concepts from IEC Standards have been reused in the EMAN 869 drafts. In particular, AC Power Quality measurements have been 870 reused from IEC 61850-7-4. The concept of Accuracy Classes for 871 measure of power and energy has been adapted from ANSI C12.20 872 and IEC standards 62053-21 and 62053-22. 874 4.1.2. DMTF 876 The Distributed Management Task Force (DMTF) has defined a Power 877 State Management profile [DMTF.DSP1027] for managing computer 878 systems using the DMTF's Common Information Model (CIM). These 879 specifications provide physical, logical, and virtual system 880 management requirements for power-state control services. The 881 DMTF standard does not include energy monitoring. 883 The Power State Management profile is used to describe and 884 manage the Power State of computer systems. This includes 885 controlling the Power State of an entity for entering sleep 886 mode, re-awaking, and rebooting. The EMAN framework references 887 the DMTF Power Profile and Power State Set. 889 4.1.2.1. Common Information Model Profiles 891 The DMTF uses CIM-based (Common Information Model) 'Profiles' to 892 represent and manage power utilization and configuration of 893 managed elements (note that this is not the 61850 CIM). Key 894 profiles for energy management are 'Power Supply' (DSP 1015), 895 'Power State' (DSP 1027) and 'Power Utilization Management' (DSP 896 1085). These profiles define many features for monitoring and 897 configuration of a Power Managed Element's static and dynamic 898 power saving modes, power allocation limits and power states. 900 Reduced power modes can be established as static or dynamic. 901 Static modes are fixed policies that limit power use or 902 utilization. Dynamic power saving modes rely upon internal 903 feedback to control power consumption. 905 Power states are eight named operational and non operational 906 levels. These are On, Sleep-Light, Sleep-Deep, Hibernate, Off- 907 Soft, and Off-Hard. Power change capabilities provide 908 immediate, timed interval, and graceful transitions between on, 909 off, and reset power states. Table 3 of the Power State Profile 910 defines the correspondence between the ACPI and DMTF power state 911 models, although it is not necessary for a managed element to 912 support ACPI. Optionally, a TransitingToPowerState property can 913 represent power state transitions in progress. 915 4.1.2.2. DASH 917 DMTF DASH (DSP0232) (Desktop And Mobile Architecture for System 918 Hardware) addresses managing heterogeneous desktop and mobile 919 systems (including power) via in-band and out-of-band 920 communications. DASH provides management and control of managed 921 elements like power, CPU, etc. using the DMTF's WS-Management 922 web services and CIM data model. 924 Both in-service and out-of-service systems can be managed with 925 the DASH specification in a fully secured remote environment. 926 Full power lifecycle management is possible using out-of-band 927 management. 929 4.1.3. ODVA 931 The Open DeviceNet Vendors Association (ODVA) is an association 932 for industrial automation companies and defines the Common 933 Industrial Protocol (CIP). Within ODVA, there is a special 934 interest group focused on energy and standardization and inter- 935 operability of energy-aware devices. 937 The Open DeviceNet Vendors Association (ODVA) is developing an 938 energy management framework for the industrial sector. There 939 are synergies and similar concepts between the ODVA and EMAN 940 approaches to energy monitoring and management. In particular, 941 one of the concepts being considered different energy meters 942 based on if the device consumes electricity or produces 943 electricity or a passive device. 945 ODVA defines a three-part approach towards energy management: 946 awareness of energy usage, consuming energy more efficiently, 947 and exchanging energy with the utility or others. Energy 948 monitoring and management promote efficient consumption and 949 enable automating actions that reduce energy consumption. 951 The foundation of the approach is the information and 952 communication model for entities. An entity is a network- 953 connected, energy-aware device that has the ability to either 954 measure or derive its energy usage based on its native 955 consumption or generation of energy, or report a nominal or 956 static energy value. 958 4.1.4. Ecma SDC 960 The Ecma International committee on Smart Data Centre (TC38-TG2 961 SDC [Ecma-SDC]) is defining semantics for management of entities 962 in a data center such as servers, storage, and network 963 equipment. It covers energy as one of many functional resources 964 or attributes of systems for monitoring and control. It only 965 defines messages and properties, and does not reference any 966 specific protocol. Its goal is to enable interoperability of 967 such protocols as SNMP, BACNET, and HTTP by ensuring a common 968 semantic model across them. Four power states are defined, Off, 969 Sleep, Idle, and Active. The standard does not include actual 970 energy or power measurements. 972 The 14th draft of SDC process was published in March 2011 and 973 the development of the standard is still underway. When used 974 with EMAN, the SDC standard will provide a thin abstraction on 975 top of the more detailed data model available in EMAN. 977 4.1.5. PWG 979 The IEEE-ISTO Printer Working Group [PWG5106.4] defines open 980 standards for printer related protocols, for the benefit of 982 printer manufacturers and related software vendors. The 984 Printer WG covers power monitoring and management of network 986 printers and imaging systems in the PWG Power Management Model 988 for Imaging Systems [PWG5106.4]. Clearly, these devices are 990 within the scope of energy management since these devices 992 receive power and are attached to the network. In addition, 994 there is ample scope of power management since printers and 996 imaging systems are not used that often. 998 The IEEE-ISTO Printer Working Group (PWG) defines SNMP MIB 999 modules for printer management and in particular a "PWG Power 1000 Management Model for Imaging Systems v1.0" [PWG5106.4] and a 1001 companion SNMP binding in the "PWG Imaging System Power MIB 1002 v1.0" [PWG5106.5]. This PWG model and MIB are harmonized with 1003 the DMTF CIM Infrastructure [DSP0004] and DMTF CIM Power State 1004 Management Profile [DSP1027] for power states and alerts. 1006 These MIB modules can be useful for monitoring the power and 1007 Power State of printers. The EMAN framework takes into account 1008 the standards defined in the Printer working group. The PWG may 1009 harmonize its MIBs with those from EMAN. The PWG covers many 1010 topics in greater detail than EMAN, as well as some that are 1011 specific to imaging equipment. The PWG also provides for 1012 vendor-specific extension states (beyond the standard DMTF CIM 1013 states). 1015 The IETF Printer MIB RFC3805 [RFC3805] has been standardized, 1016 however, this MIB module does not address power management. 1018 4.1.6. ASHRAE 1020 In the U.S., there is an extensive effort to coordinate and 1021 develop standards related to the "Smart Grid". The Smart Grid 1022 Interoperability Panel, coordinated by the government National 1023 Institute of Standards and Technology, identified the need for a 1024 building side information model (as a counterpart to utility 1025 models) and specified this in Priority Action Plan (PAP) 17. 1026 This was designated to be a joint effort by the American Society 1027 of Heating, Refrigerating and Air-Conditioning Engineers 1028 (ASHRAE) and the National Electrical Manufacturers Association 1029 (NEMA), both ANSI approved SDO's. The result is to be an 1030 information model, not a protocol. 1032 The ASHRAE effort addresses data used only within a building as 1033 well as data that may be shared with the grid, particularly as 1034 it relates to coordinating future demand levels with the needs 1035 of the grid. The model is intended to be applied to any 1036 building type, both residential and commercial. It is expected 1037 that existing protocols will be adapted to comply with the new 1038 information model, as would new protocols. 1040 There are four basic types of entities in the model: generators, 1041 loads, meters, and energy managers. 1043 The metering part of the model overlaps with the EMAN framework 1044 to a large degree, though there are features unique to each. 1045 The load part speaks to control capabilities well beyond what 1046 EMAN covers. Details of generation and of the energy management 1047 function are outside of EMAN scope. 1049 A public review draft of the ASHRAE standard was released in 1050 July, 2012. There are no apparent major conflicts between the 1051 two approaches, but there are areas where some harmonization is 1052 possible. 1054 4.1.7. ZigBee 1056 The ZigBee Smart Energy 2.0 effort [ZIGBEE] focuses on wireless 1057 communication to appliances and lighting. ZigBee 1.x is not 1058 based on IP, whereas ZigBee 2.0 is supposed to interoperate with 1059 IP. It is intended to enable building energy management and 1060 enable direct load control by utilities. 1062 ZigBee protocols are intended for use in embedded applications 1063 with low data rates and low power consumption. ZigBee defines a 1064 general-purpose, inexpensive, self-organizing mesh network that 1065 can be used for industrial control, embedded sensing, medical 1066 data collection, smoke and intruder warning, building 1067 automation, home automation, etc. 1069 ZigBee is currently not an ANSI recognized SDO. 1071 The EMAN framework addresses the needs of IP-enabled networks 1072 through the usage of SNMP, while ZigBee looks for completely 1073 integrated and inexpensive mesh solution. 1075 4.2. Measurement 1076 4.2.1. ANSI C12 1078 The American National Standards Institute (ANSI) has defined a 1079 collection of power meter standards under ANSI C12. The primary 1080 standards include communication protocols (C12.18, 21 and 22), 1081 data and schema definitions (C12.19), and measurement accuracy 1082 (C12.20). European equivalent standards are provided by IEC 1083 62053-22. ANSI C12.20 defines accuracy classes for power 1084 meters. 1086 These standards are oriented to the meter itself, are very 1087 specific, and used by electricity distributors and producers. 1089 The EMAN standard references ANSI C12 accuracy classes. 1091 4.2.2. IEC 62301 1093 IEC 62301, "Household electrical appliances Measurement of 1094 standby power", specifies a power level measurement procedure. 1095 While nominally for appliances and low-power modes, many aspects 1096 of it apply to other device types and modes and it is commonly 1097 referenced in test procedures for energy using products. 1099 While the standard is intended for laboratory measurements of 1100 devices in controlled conditions, many aspects of it are 1101 informative to those implementing measurement in products that 1102 ultimately report via EMAN. 1104 4.3. Other 1106 4.3.1. ISO 1108 The International Organization for Standardization (ISO) [ISO] 1109 is developing an energy management standard, ISO 50001, to 1110 complement ISO 9001 for quality management, and ISO 14001 for 1111 environmental management. The intent is to facilitate the 1112 creation of energy management programs for industrial, 1113 commercial, and other entities. The standard defines a process 1114 for energy management at an organization level. It does not 1115 define the way in which devices report energy and consume 1116 energy. 1118 ISO 50001 is based on the common elements found in all of ISO's 1119 management system standards, assuring a high level of 1120 compatibility with ISO 9001 and ISO 14001. ISO 50001 benefits 1121 include: 1123 o Integrating energy efficiency into management practices and 1124 throughout the supply chain 1125 o Energy management best practices and good energy management 1126 behaviors 1127 o benchmarking, measuring, documenting, and reporting energy 1128 intensity improvements and their projected impact on 1129 reductions in greenhouse gas (GHG) emissions 1130 o Evaluating and prioritizing the implementation of new energy- 1131 efficient technologies 1133 ISO 50001 has been developed by ISO project committee ISO PC 1134 242, Energy management. EMAN is complementary to ISO 9001. 1136 4.3.2. Energy Star 1138 The U.S. Environmental Protection Agency (EPA) and U.S. 1139 Department of Energy (DOE) jointly sponsor the Energy Star 1140 program [ESTAR]. The program promotes the development of energy 1141 efficient products and practices. 1143 To qualify as Energy Star, products must meet specific energy 1144 efficiency targets. The Energy Star program also provides 1145 planning tools and technical documentation to encourage more 1146 energy efficient building design. Energy Star is a program; it 1147 is not a protocol or standard. 1149 For businesses and data centers, Energy Star offers technical 1150 support to help companies establish energy conservation 1151 practices. Energy Star provides best practices for measuring 1152 current energy performance, goal setting, and tracking 1153 improvement. The Energy Star tools offered include a rating 1154 system for building performance and comparative benchmarks. 1156 There is no immediate link between EMAN and EnergyStar, one 1157 being a protocol and the other a set of recommendations to 1158 develop energy efficient products. However, Energy Star could 1159 include EMAN standards in specifications for future products, 1160 either as required or rewarded with some benefit. 1162 4.3.3. Smart Grid 1164 The Smart Grid standards efforts underway in the United States 1165 are overseen by the U.S. National Institute of Standards and 1166 Technology [NIST]. NIST is responsible for coordinating a 1167 public-private partnership with key energy and consumer 1168 stakeholders in order to facilitate the development of smart 1169 grid standards. These activities are monitored and facilitated 1170 by the SGIP (Smart Grid Interoperability Panel). This group has 1171 working groups for specific topics including homes, commercial 1172 buildings, and industrial facilities as they relate to the grid. 1173 A stated goal of the group is to harmonize any new standard with 1174 the IEC CIM and IEC 61850. 1176 When a working group detects a standard or technology gap, the 1177 team seeks approval from the SGIP for the creation of a Priority 1178 Action Plan (PAP), a private-public partnership to close the 1179 gap. PAP 17 is discussed in section 4.1.6. 1181 PAP 10 addresses "Standard Energy Usage Information". Smart 1182 Grid standards will provide distributed intelligence in the 1183 network and allow enhanced load shedding. For example, pricing 1184 signals will enable selective shutdown of non critical 1185 activities during peak price periods. Both centralized and 1186 distributed management controls are in scope. 1188 There is an obvious functional link between Smart Grid and EMAN 1189 in the form of demand response, even though the EMAN framework 1190 itself does not address any coordination with the grid. As EMAN 1191 enables control, it can be used by an EnMS to accomplish demand 1192 response through translation of a signal from an outside entity. 1194 5. Limitations 1196 EMAN addresses the needs of energy monitoring in terms of 1197 measurement and, considers limited control capabilities of 1198 energy monitoring of networks. 1200 EMAN does not create a new protocol stack, but rather defines a 1201 data and information model useful for measuring and reporting 1202 energy and other metrics over SNMP. 1204 EMAN does not address questions regarding Smart Grid, 1205 electricity producers, and distributors. 1207 6. Security Considerations 1209 EMAN uses the SNMP protocol and thus has the functionality of 1210 SNMP's security capabilities. SNMPv3 [RFC3411] provides 1211 important security features such as confidentiality, integrity, 1212 and authentication. 1214 7. IANA Considerations 1216 This memo includes no request to IANA. 1218 8. Acknowledgements 1220 Firstly, the authors thank Emmanuel Tychon for taking the lead 1221 for this draft and his substantial contributions to it. The 1222 authors thank Jeff Wheeler, Benoit Claise, Juergen Quittek, 1223 Chris Verges, John Parello, and Matt Laherty, for their valuable 1224 contributions. The authors thank Georgios Karagiannis for use 1225 case involving energy neutral homes, Elwyn Davies for off-grid 1226 electricity systems, and Kerry Lynn for demand response. 1228 9. References 1230 9.1. Normative References 1232 [RFC3411] An Architecture for Describing Simple Network 1233 Management Protocol (SNMP) Management Frameworks, RFC 1234 3411, December 2002. 1236 [RFC3621] Power Ethernet MIB, RFC 3621, December 2003. 1238 9.2. Informative References 1240 [DASH] "Desktop and mobile Architecture for System Hardware", 1241 http://www.dmtf.org/standards/mgmt/dash/ 1243 [NIST] http://www.nist.gov/smartgrid/ 1245 [Ecma-SDC] Ecma TC38 / SDC Task Group, "Smart Data Centre 1246 Resource Monitoring and Control (DRAFT)", March 2011. 1248 [ESTAR] http://en.wikipedia.org/wiki/Kilowatt_hour 1250 [EMAN-AS] B. Schoening, Mouli Chandramouli, Bruce Nordman, 1251 "Energy Management (EMAN) Applicability Statement", 1252 draft-ietf-eman-applicability-statement-04.txt, April 1253 2014. 1255 [EMAN-REQ] Quittek, J., Chandramouli, M. Winter, R., Dietz, T., 1256 Claise, B., and M. Chandramouli, "Requirements for 1257 Energy Management ", RFC 6988, September 2013. 1259 [EMAN-MONITORING-MIB] M. Chandramouli, Schoening, B., Dietz, T., 1260 Quittek, J. and B. Claise "Energy and Power Monitoring 1261 MIB " draft-ietf-eman-monitoring-mib-06, July 2013. 1263 [EMAN-AWARE-MIB] J. Parello, B. Claise and Mouli Chandramouli, 1264 "draft-ietf-eman-energy-aware-mib-09", work in 1265 progress, July 2013. 1267 [EMAN-FRAMEWORK] Claise, B., Parello, J., Schoening, B., J. 1268 Quittek, "Energy Management Framework", draft-ietf- 1269 eman-framework-10, April 2014. 1271 [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, 1272 "Definition of Managed Objects for Battery Monitoring" 1273 draft-ietf-eman-battery-mib-09.txt, July 2013. 1275 [EMAN-DEF] J. Parello "Energy Management Terminology", draft- 1276 parello-eman-definitions-08, Work in progress, April 1277 2013. 1279 [DMTF] "Power State Management ProfileDMTFDSP1027 Version 2.0" 1280 December2009. 1281 http://www.dmtf.org/sites/default/files/standards/docum 1282 ents/DSP1027_2.0.0.pdf 1284 [ESTAR] http://www.energystar.gov/ 1286 [ISO] http://www.iso.org/iso/pressrelease.htm?refid=Ref1434 1288 [ASHRAE] http://collaborate.nist.gov/twiki- 1289 sggrid/bin/view/SmartGrid/PAP17Information 1291 [ZIGBEE] http://www.zigBee.org/ 1293 [ISO] http://www.iso.org/iso/pressrelease.htm?refid=Ref1337 1295 [DSP0004] DMTF Common Information Model (CIM) Infrastructure, 1296 DSP0004, May 2009. 1297 http://www.dmtf.org/standards/published_documents/DSP00 1298 04_2.5.0.pdf 1300 [DSP1027] DMTF Power State Management Profile, DSP1027, December 1301 2009. 1302 http://www.dmtf.org/standards/published_documents/DSP10 1303 27_2.0.0.pdf 1305 [PWG5106.4]IEEE-ISTO PWG Power Management Model for Imaging 1306 Systems v1.0, PWG Candidate Standard 5106.4-2011, 1307 February 2011.ftp://ftp.pwg.org/pub/pwg/candidates/cs- 1308 wimspower10-20110214-5106.4.mib 1310 [PWG5106.5] IEEE-ISTO PWG Imaging System Power MIB v1.0, PWG 1311 Candidate Standard 5106.5-2011, February 2011. 1313 [IEC62301] International Electrotechnical Commission, "IEC 62301 1314 Household electrical appliances Measurement of standby 1315 power", Edition 2.0, 2011. 1317 [MODBUS] Modbus-IDA, "MODBUS Application Protocol Specification 1318 V1.1b", December 2006. 1320 Authors' Addresses 1322 Brad Schoening 1323 44 Rivers Edge Drive 1324 Little Silver, NJ 07739 1325 USA 1327 Phone: +1 917 304 7190 1328 Email: brad.schoening@verizon.net 1330 Mouli Chandramouli 1331 Cisco Systems, Inc. 1332 Sarjapur Outer Ring Road 1333 Bangalore 560103 1334 India 1336 Phone: +91 80 4429 2409 1337 Email: moulchan@cisco.com 1339 Bruce Nordman 1340 Lawrence Berkeley National Laboratory 1341 1 Cyclotron Road, 90-2000 1342 Berkeley 94720-8130 1343 USA 1345 Phone: +1 510 486 7089 1346 Email: bnordman@lbl.gov