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