idnits 2.17.1 draft-ietf-eman-requirements-07.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 956 has weird spacing: '...ntities on wh...' == Line 968 has weird spacing: '...ntities on wh...' -- The document date (July 3, 2012) is 4313 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4133 (Obsoleted by RFC 6933) -- Obsolete informational reference (is this intentional?): RFC 5101 (Obsoleted by RFC 7011) -- Obsolete informational reference (is this intentional?): RFC 5102 (Obsoleted by RFC 7012) == Outdated reference: A later version (-11) exists of draft-ietf-eman-applicability-statement-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Quittek, Ed. 3 Internet-Draft R. Winter 4 Intended status: Informational T. Dietz 5 Expires: January 4, 2013 NEC Europe Ltd. 6 B. Claise 7 M. Chandramouli 8 Cisco Systems, Inc. 9 July 3, 2012 11 Requirements for Energy Management 12 draft-ietf-eman-requirements-07 14 Abstract 16 This document defines requirements for standards specifications for 17 energy management. The requirements defined in this document concern 18 monitoring functions as well as control functions. In detail, the 19 focus of the requirements is on the following features: 20 identification of powered entities, monitoring of their Power State, 21 power inlets, power outlets, actual power, power properties, received 22 energy, provided energy, and contained batteries. Further 23 requirements are included to enable control of powered entities' 24 power supply and Power State. This document does not specify the 25 features that must be implemented by compliant implementations but 26 rather features that must be supported by standards for energy 27 management. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 4, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1.1. Conventional requirements for energy management . . . . . 6 65 1.2. Specific requirements for energy management . . . . . . . 6 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3. General Considerations Related to Energy Management . . . . . 8 70 3.1. Power states . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.2. Saving energy versus maintaining service level 72 agreements . . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.3. Local versus network-wide energy management . . . . . . . 9 74 3.4. Energy monitoring versus energy saving . . . . . . . . . . 10 75 3.5. Overview of energy management requirements . . . . . . . . 10 77 4. Identification of Powered Entities . . . . . . . . . . . . . . 10 79 5. Information on Powered Entities . . . . . . . . . . . . . . . 11 80 5.1. General information on Powered Entities . . . . . . . . . 12 81 5.2. Power Interfaces . . . . . . . . . . . . . . . . . . . . . 13 82 5.3. Power . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 5.4. Power State . . . . . . . . . . . . . . . . . . . . . . . 16 84 5.5. Energy . . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 5.6. Battery State . . . . . . . . . . . . . . . . . . . . . . 19 86 5.7. Time series of measured values . . . . . . . . . . . . . . 20 88 6. Control of Powered Entities . . . . . . . . . . . . . . . . . 21 90 7. Reporting on other Powered Entities . . . . . . . . . . . . . 22 92 8. Controlling Other Powered Entities . . . . . . . . . . . . . . 23 93 8.1. Controlling Power States of other Powered Entities . . . . 23 94 8.2. Controlling power supply . . . . . . . . . . . . . . . . . 24 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 100 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 102 12. Informative References . . . . . . . . . . . . . . . . . . . . 25 104 Appendix A. Existing Standards . . . . . . . . . . . . . . . . . 27 105 A.1. Existing IETF Standards . . . . . . . . . . . . . . . . . 28 106 A.1.1. ENTITY MIB . . . . . . . . . . . . . . . . . . . . . . 28 107 A.1.2. ENTITY STATE MIB . . . . . . . . . . . . . . . . . . . 28 108 A.1.3. ENTITY SENSOR MIB . . . . . . . . . . . . . . . . . . 29 109 A.1.4. UPS MIB . . . . . . . . . . . . . . . . . . . . . . . 29 110 A.1.5. POWER ETHERNET MIB . . . . . . . . . . . . . . . . . . 30 111 A.1.6. LLDP MED MIB . . . . . . . . . . . . . . . . . . . . . 30 112 A.2. Existing standards of other bodies . . . . . . . . . . . . 30 113 A.2.1. DMTF . . . . . . . . . . . . . . . . . . . . . . . . . 30 114 A.2.2. OVDA . . . . . . . . . . . . . . . . . . . . . . . . . 31 115 A.2.3. IEEE-ISTO Printer WG . . . . . . . . . . . . . . . . . 31 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 119 1. Introduction 121 With rising energy cost and with an increasing awareness of the 122 ecological impact of running IT equipment, energy management 123 functions and interfaces are becoming an additional basic requirement 124 for network management systems and devices connected to a network. 126 This document defines requirements for standards specifications for 127 energy management, both monitoring functions and control functions. 128 In detail, the requirements listed are focused on the following 129 features: identification of Powered Entities , monitoring of their 130 Power State, power inlets, power outlets, actual power, power 131 properties, received energy, provided energy, and contained 132 batteries. Further included is control of Powered Entities ' power 133 supply and Power State. 135 The main subject of energy management are devices and their 136 components that receive and provide electric energy. Devices may 137 have an IP address, such as hosts, routers, and middleboxes, or they 138 are connected indirectly to the Internet via a proxy with an IP 139 address providing a management interface for the device. An example 140 are devices in a building infrastructure using non-IP protocols and a 141 gateway to the Internet. 143 These requirements concern the standards specification process and 144 not the implementation of specified standards. All requirements in 145 this document must be reflected by standards specifications to be 146 developed. However, which of the features specified by these 147 standards will be mandatory, recommended, or optional for compliant 148 implementations is to be defined by standards track document(s) and 149 not in this document. 151 Section 3 elaborates a set of general needs for energy management. 152 Requirements for an energy management standard are specified in 153 Sections 4 to 8. 155 Sections 4 to 6 contain conventional requirements specifying 156 information on Powered Entities and control functions. 158 Sections 7 and 8 contain requirements specific to energy management. 159 Due to the nature of power supply, some monitoring and control 160 functions are not conducted by interacting with the Powered Entity of 161 interest, but with other entities, for example, entities upstream in 162 a power distribution tree. 164 1.1. Conventional requirements for energy management 166 The specification of requirements for an energy management standard 167 starts with Section 4 addressing the identification of Powered 168 Entities and the granularity of reporting of energy-related 169 information. A standard must support unique identification of 170 powered entities, reporting per entire powered device, and reporting 171 energy-related information on individual components of a device or 172 subtended devices. 174 Section 5 specifies requirements related to monitoring of Powered 175 Entities . This includes general (type, context) information and 176 specific information on Power States, power inlets, power outlets, 177 power, energy, and batteries. Control Power State and power supply 178 of Powered Entities is covered by requirements specified in 179 Section 6. 181 1.2. Specific requirements for energy management 183 While the conventional requirements summarized above seem to be all 184 that would be needed for energy management, there are significant 185 differences between energy management and most well known network 186 management functions. The most significant difference is the need 187 for some devices to report on other entities. There are three major 188 reasons for this. 189 o For monitoring a particular Powered Entity it is not always 190 sufficient to communicate with the Powered Entity only. When the 191 Powered Entity has no instrumentation for determining power, it 192 might still be possible to obtain power values for the entity by 193 communication with other entities in its power distribution tree. 194 A simple example is retrieving power values from a power meter at 195 the power line into the Powered Entity. Common examples are a 196 Power Distribution Unit (PDU) and a Power over Ethernet (PoE) 197 switch. Both supply power to other entities at sockets or ports, 198 respectively, and are often instrumented to measure power per 199 socket or port. 200 o Similar considerations apply to controlling power supply of a 201 Powered Entity which often needs direct or indirect communications 202 with another entity upstream in the power distribution tree. 203 Again, a PDU and a PoE switch are common examples, if they have 204 the capability to switch on or off power at their sockets or 205 ports, respectively. 206 o Energy management often extends beyond entities with IP network 207 interfaces, to non-IP building systems accessed via a gateway. 208 Requirements in this document do not cover details of these 209 networks, but specify means for opening IP network management 210 towards them. 212 These specific issues of energy management and a set of further ones 213 are covered by requirements specified in Sections 7 and 8. 215 The requirements in these sections need a new energy management 216 framework that deals with the specific nature of energy management. 217 The actual standards documents, such as MIB module specifications, 218 address conformance by specifying which feature must, should, or may 219 be implemented by compliant implementations. 221 2. Terminology 223 Energy 225 That which does work or is capable of doing work. As used by 226 electric utilities, it is generally a reference to electrical 227 energy and is measured in kilo-watt hours (kWh) [IEEE-100]. 229 Power 231 The time rate at which energy is emitted, transferred, or 232 received; usually expressed in watts (or in joules per second) 233 [IEEE-100]. 235 Energy management 237 Energy Management is a set of functions for measuring, modeling, 238 planning, and optimizing networks to ensure that the network 239 elements and attached devices use energy efficiently and is 240 appropriate for the nature of the application and the cost 241 constraints of the organization [ITU-M.3400]. 243 Energy management system 245 An Energy Management System is a combination of hardware and 246 software used to administer a network with the primary purpose 247 being energy management [Fed-Std-1037C]. 249 Energy monitoring 251 Energy monitoring is a part of energy management that deals with 252 collecting or reading information from network elements and 253 attached devices and their components to aid in energy management. 255 Energy control 257 Energy control is a part of energy management that deals with 258 directing influence over network elements and attached devices and 259 their components. 261 Powered Entity 263 A Powered Entity is either a device or one of a device's 264 components that is subject to energy monitoring or control or 265 both. 267 Power Interface 269 A Power Interface is an interface at which a device is connected 270 to a power transmission medium at which it can receive power, 271 provice power, or both. 273 Power inlet 275 A power inlet is a Power Interface at which a device can receive 276 power fro other devices. 278 Power outlet 280 A power outlet is a Power Interface at which a device can provide 281 power to other devices. 283 Power State 285 A Power State is a condition or mode of a device that broadly 286 characterizes its capabilities, power consumption, and 287 responsiveness to input [IEEE-1621]. 289 3. General Considerations Related to Energy Management 291 The basic objective of energy management is operating sets of devices 292 with minimal energy, while maintaining a certain level of service. 293 Use cases for energy management can be found in 294 [I-D.ietf-eman-applicability-statement]. 296 3.1. Power states 298 Powered Entities can be set to an operational state that results in 299 the lowest power level that still meets the service level performance 300 objectives. In principle, there are four basic types of Power States 301 for a Powered Entity or for a whole system: 303 o full Power State 304 o reduced Power States (e.g. lower clock rate for processor, lower 305 data rate on a link, etc.) 306 o sleep state (not functional, but immediately available) 307 o off state (may require significant time to become operational) 308 In specific devices, the number of Power States and their properties 309 varies considerably. Simple powered entities may just have only the 310 extreme states, full power and off state. Many devices have three 311 basic Power States: on, off, and sleep. However, more finely grained 312 Power States can be implemented with many levels of each Power State. 314 3.2. Saving energy versus maintaining service level agreements 316 While the general objective of energy management is quite clear, the 317 way to attain that goal is often difficult. In many cases there is 318 no way of reducing power without the consequence of a potential 319 performance, service, or capacity degradation. Then a trade-off 320 needs to be dealt with between service level objectives and energy 321 minimization. In other cases a reduction of power can easily be 322 achieved while still maintaining sufficient service level 323 performance, for example, by switching Powered Entities to lower 324 Power States when higher performance is not needed. 326 3.3. Local versus network-wide energy management 328 Many energy saving functions are executed locally by a Powered 329 Entity; it monitors its usage and dynamically adapts its power 330 according to the required performance. It may, for example, switch 331 to a sleep state when it is not in use or out of scheduled business 332 hours. An energy management system may observe an entity's power 333 state and configure its power saving policies. 335 Energy savings can also be achieved with policies implemented by a 336 network management system that controls Power States of managed 337 entities. Information about the power received and provided by 338 Powered Entities in different Power States may be required to set 339 policies. Often this information is acquired best through 340 monitoring. 342 Both methods, network-wide and local energy management, have 343 advantages and disadvantages and often it is desirable to combine 344 them. Central management is often favorable for setting Power States 345 of a large number of entities at the same time, for example, at the 346 beginning and end of business hours in a building. Local management 347 is often preferable for power saving measures based on local 348 observations, such as high or low load of an entity. 350 3.4. Energy monitoring versus energy saving 352 Monitoring energy, power, and Power States alone does not reduce the 353 energy needed to run a Powered Entity. In fact, it may even increase 354 it slightly due to monitoring instrumentation that needs energy. 355 Reporting measured quantities over the network may also increase 356 energy use, though the acquired information may be an essential input 357 to control loops that save energy. 359 Monitoring energy and Power States can also be required for other 360 purposes including: 361 o investigating energy saving potential 362 o evaluating the effectiveness of energy saving policies and 363 measures 364 o deriving, implementing, and testing power management strategies 365 o accounting for the total power received and provided by a Powered 366 Entity, a network, or a service 367 o predicting a Powered Entity's reliability based on power usage 368 o choosing time of next maintenance cycle for a powered entity 370 3.5. Overview of energy management requirements 372 The following basic management functions are required: 373 o monitoring Power States 374 o monitoring power (energy conversion rate) 375 o monitoring (accumulated) received and provided energy 376 o monitoring power properties 377 o setting Power States 379 Power control is complementary to other energy savings measures such 380 as low power electronics, energy saving protocols, energy-efficient 381 device design (for example, low-power modes for components), and 382 energy-efficient network architectures. Measurement of received and 383 provided energy can provide useful data for developing these 384 technologies. 386 4. Identification of Powered Entities 388 Powered Entities must be uniquely identified. This includes entities 389 that are components of managed devices as well as entire devices. 391 For Powered Entities that report on or control other Powered Entities 392 it is important to identify the Powered Entities they report on or 393 control, see Section 7 or Section 8, respectively. 395 An entity may be an entire device or a component of it. Examples of 396 components of interest are a hard drive, a battery, or a line card. 398 It may be required to be able to control individual components to 399 save energy. For example, server blades can be switched off when the 400 overall load is low or line cards at switches may be powered down at 401 night. 403 Identifiers for devices and components are already defined in 404 standard MIB modules, such as the LLDP MIB module [IEEE-802.1AB] and 405 the LLDP-MED MIB module [ANSI-TIA-1057] for devices and the Entity 406 MIB module [RFC4133] and the Power Ethernet MIB [RFC3621] for 407 components of devices. Energy management needs means to link energy- 408 related information to such identifiers. 410 Instrumentation for measuring received and provided energy of a 411 device is typically more expensive than instrumentation for 412 retrieving its Power State. Many devices may provide Power State 413 information for all individual components separately, while reporting 414 the received and provided energy only for the entire device. 416 4.1. Identifying Powered Entities 418 The standard must provide means for uniquely identifying Powered 419 Entities . Uniqueness must be preserved such that collisions of 420 identities are avoided at potential receivers of monitored 421 information. 423 4.2. Persistence of identifiers 425 The standard must provide means for indicating whether identifiers of 426 Powered Entities are persistent across a re-start of the Powered 427 Entity. 429 4.3. Using entity identifiers of other MIB modules 431 The standard must provide means for re-using entity identifiers from 432 other standards including at least the following: 433 o the entPhysicalIndex in the Entity MIB module [RFC4133] 434 o the LldpPortNumber in the LLDP MIB module [IEEE-802.1AB] and in 435 the LLDP-MED MIB module [ANSI-TIA-1057] 436 o the pethPsePortIndex and the pethPsePortGroupIndex in the Power 437 Ethernet MIB [RFC3621] 438 Generic means for re-using other entity identifiers must be provided. 440 5. Information on Powered Entities 442 This section describes information on Powered Entities for which the 443 standard must provide means for retrieving and reporting. 445 Required information can be structured into seven groups. 446 Section 5.1 specifies requirements for general information on Powered 447 Entities , such as type of powered entity or context information. 448 Requirements for information on power inlets and power outlets of 449 Powered Entities are specified in Section 5.2. Monitoring of power 450 and energy is covered by Sections 5.3 and 5.5, respectively. 451 Section 5.4 covers requirements related to entities' Power States. 452 Section 5.6 specifies requirements for monitoring batteries. 453 Finally, the reporting of time series of values is covered by 454 Section 5.7. 456 5.1. General information on Powered Entities 458 For energy management it may be required to understand the role and 459 context of a Powered Entity. An energy management system may 460 aggregate values of received and provided energy according to a 461 defined grouping of entities. When controlling and setting Power 462 States it may be helpful to understand the grouping of the entity and 463 role of a Powered Entity in a network, for example, it may be 464 important to exclude some vital network devices from being switched 465 to lower power or even from being switched off. 467 5.1.1. Type of Powered Entity 469 The standard must provide means to configure, retrieve and report a 470 textual name or a description of a powered entity. 472 5.1.2. Context of Powered Entities 474 The standard must provide means for retrieving and reporting context 475 information on Powered Entities , for example, tags associated with a 476 Powered Entity that indicate the Powered Entity's role. 478 5.1.3. Significance of Powered Entities 480 The standard must provide means for retrieving and reporting the 481 significance of Powered Entities within its context, for example, how 482 important the Powered Entity is. 484 5.1.4. Power priority 486 The standard must provide means for retrieving and reporting power 487 priorities of Powered Entities . Power priorities indicate an order 488 in which Power States of Powered Entities are changed, for example, 489 to lower Power States for saving power. 491 5.1.5. Grouping of Powered Entities 493 The standard must provide means for grouping powered entities. This 494 can be achieved in multiple ways, for example, by providing means to 495 tag Powered Entities , to assign them to domains, or to assign device 496 types to them. 498 5.2. Power Interfaces 500 A Power Interface is either an inlet or an outlet. Some Power 501 Interfaces can change over time from being an inlet to being an 502 outlet and vice versa. However most power interfaces never change. 504 Powered Entities have power inlets at which they are supplied with 505 electric power. Most Powered Entities have a single power inlet, 506 while some have multiple inlets. Different power inlets on a device 507 are often connected to separate power distribution trees. For energy 508 monitoring, it is useful to retrieve information on the number of 509 inlets of a Powered Entity, the availability of power at inlets and 510 which of them are actually in use. 512 Powered Entities can have one or more power outlets for supplying 513 other Powered Entities with electric power. 515 For identifying and potentially controlling the source of power 516 received at an inlet, it may be required to identify the power outlet 517 of another Powered Entity at which the received power is provided. 518 Analogously, for each outlet it is of interest to identify the power 519 inlets that receive the power provided at a certain outlet. Such 520 information is also required for constructing the wiring topology of 521 electrical power distribution to Powered Entities . 523 Static properties of each Power Interface are required information 524 for energy management. Static properties include the kind of 525 electric current (AC or DC), the nominal voltage, the nominal AC 526 frequency, and the number of AC phases. 528 5.2.1. Lists of Power Interfaces 530 The standard must provide means for monitoring the list of Power 531 Interfaces. 533 5.2.2. Corresponding power outlet 535 The standard must provide means for identifying the power outlet that 536 provides the power received at a power inlet. 538 5.2.3. Corresponding power inlets 540 The standard must provide means for identifying the list of power 541 inlets that receive the power provided at a power outlet. 543 5.2.4. Availability of power 545 The standard must provide means for monitoring the availability of 546 power at each Power Interface. This indicates whether at a Power 547 Interfaces power supply is switched on or off. 549 5.2.5. Use of power 551 The standard must provide means for monitoring for each Power 552 Interfaces if it is in actual use. For inlets this means that the 553 Powered Entity actually receives power at the inlet. For outlets 554 this means that power is actually provided from it to one or more 555 powered entities. 557 5.2.6. Type of current 559 The standard must provide means for reporting the type of current (AC 560 or DC) for each Power Interface as well as for an entire Powered 561 Entity. 563 5.2.7. Nominal voltage 565 The standard must provide means for reporting the nominal voltage for 566 each Power Interface. 568 5.2.8. Nominal AC frequency 570 The standard must provide means for reporting the nominal AC 571 frequency for each Power Interface. 573 5.2.9. Number of AC phases 575 The standard must provide means for reporting the number of AC phases 576 for each Power Interface. 578 5.3. Power 580 Power is measured as an instantaneous value or as the average over a 581 time interval. 583 Obtaining highly accurate values for power and energy may be costly 584 if it requires dedicated metering hardware. Powered Entities without 585 the ability to measure their power and received and provided energy 586 with high accuracy may just report estimated values, for example 587 based on load monitoring, Power State, or even just the entity type. 589 Depending on how power and energy values are obtained, the confidence 590 in the reported value and its accuracy will vary. Powered Entities 591 reporting such values should qualify the confidence in the reported 592 values and quantify the accuracy of measurements. For reporting 593 accuracy, the accuracy classes specified in IEC 62053-21 594 [IEC.62053-21] and IEC 62053-22 [IEC.62053-22] should be considered. 596 Further properties of the supplied power are also of interest. For 597 AC power supply, power attributes beyond the real power to be 598 reported include the apparent power, the reactive power, and the 599 phase angle of the current or the power factor. For both AC and DC 600 power the power characteristics are also subject of monitoring. 601 Power parameters include the actual voltage, the actual frequency, 602 the Total Harmonic Distortion (THD) of voltage and current, the 603 impedance of an AC phase or of the DC supply. Power monitoring 604 should be in line with existing standards, such as [IEC.61850-7-4]. 606 For some network management tasks it is desirable to receive 607 notifications from Powered Entities when their power value exceeds or 608 falls below given thresholds. 610 5.3.1. Real power 612 The standard must provide means for reporting the real power for each 613 Power Interface as well as for an entire Powered Entity. Reporting 614 power includes reporting the direction of power flow. 616 5.3.2. Power measurement interval 618 The standard must provide means for reporting the corresponding time 619 or time interval for which a power value is reported. The power 620 value can be measured at the corresponding time or averaged over the 621 corresponding time interval. 623 5.3.3. Power measurement method 625 The standard must provide means to indicate the method how these 626 values have been obtained. Based on how the measurement was 627 conducted, it is possible to associate a certain degree of confidence 628 with the reported power value. For example, there are methods of 629 measurement such as direct power measurement, or by estimation based 630 on performance values, or hard coding average power values for a 631 Powered Entity. 633 5.3.4. Accuracy of power and energy values 635 The standard must provide means for reporting the accuracy of 636 reported power and energy values. 638 5.3.5. Actual voltage and current 640 The standard must provide means for reporting the actual voltage and 641 actual current for each power interface as well as for an entire 642 Powered Entity. In case of AC power supply, means must be provided 643 for reporting the actual voltage and actual current per phase. 645 5.3.6. High/low power notifications 647 The standard must provide means for creating notifications if power 648 values of a Powered Entity rise above or fall below given thresholds. 650 5.3.7. Complex power 652 The standard must provide means for reporting the complex power for 653 each Power Interface and for each phase at a Power Interface. 654 Besides the real power, at least two out of the following three 655 quantities need to be reported: apparent power, reactive power, phase 656 angle. The phase angle can be substituted by the power factor. 658 5.3.8. Actual AC frequency 660 The standard must provide means for reporting the actual AC frequency 661 for each Power Interface. 663 5.3.9. Total harmonic distortion 665 The standard must provide means for reporting the Total Harmonic 666 Distortion (THD) of voltage and current for each Power Interface. In 667 case of AC power supply, means must be provided for reporting the THD 668 per phase. 670 5.3.10. Power supply impedance 672 The standard must provide means for reporting the impedance of power 673 supply for each Power Interface. In case of AC power supply, means 674 must be provided for reporting the impedance per phase. 676 5.4. Power State 678 Many Powered Entities have a limited number of discrete Power States. 680 There is a need to report the actual Power State of a Powered Entity, 681 and means for retrieving the list of all supported Power States. 683 Different standards bodies have already defined sets of Power States 684 for some Powered Entities , and others are creating new Power State 685 sets. In this context, it is desirable that the standard support 686 many of these power state standards. In order to support multiple 687 management systems possibly using different Power State sets, while 688 simultaneously interfacing with a particular Powered Entity, the 689 energy management standard must provide means for supporting multiple 690 Power State sets used simultaneously at a powered entity. 692 Power States have parameters that describe its properties. It is 693 required to have standardized means for reporting some key 694 properties, such as average power and maximum power of a Powered 695 Entity in a certain state. 697 There also is a need to report statistics on Power States including 698 the time spent and the received and provided energy in a Power State. 700 5.4.1. Actual Power State 702 The standard must provide means for reporting the actual Power State 703 of a Powered Entity. 705 5.4.2. List of supported Power States 707 The standard must provide means for retrieving the list of all 708 potential Power States of a Powered Entity. 710 5.4.3. Multiple Power State sets 712 The standard must provide means for supporting multiple Power State 713 sets simultaneously at a Powered Entity. 715 5.4.4. List of supported Power State sets 717 The standard must provide means for retrieving the list of all Power 718 State sets supported by a Powered Entity. 720 5.4.5. List of supported Power States within a set 722 The standard must provide means for retrieving the list of all 723 potential Power States of a Powered Entity for each supported Power 724 State set. 726 5.4.6. Maximum and average power per Power State 728 The standard must provide means for retrieving the maximum power and 729 the average power for each supported Power State. These values may 730 be static. 732 5.4.7. Power State statistics 734 The standard must provide means for monitoring statistics per Power 735 State including the total time spent in a Power State, the number of 736 times each state was entered and the last time each state was 737 entered. More Power State statistics are addressed by requirement 738 5.5.3. 740 5.4.8. Power State changes 742 The standard must provide means for generating a notification when 743 the actual Power State of a powered entity changes. 745 5.5. Energy 747 Monitoring of electrical energy received or provided by a Powered 748 Entity is a core function of energy management. Since energy is an 749 accumulated quantity, it is always reported for a certain interval of 750 time. This can be, for example, the time from the last restart of 751 the powered entity to the reporting time, the time from another past 752 event to the reporting time, the last given amount of time before the 753 reporting time, or a certain interval specified by two time stamps in 754 the past. 756 It is useful for Powered Entities to record their received and 757 provided energy per Power State and report these quantities. 759 5.5.1. Energy 761 The standard must provide means for reporting measured values of 762 energy and the direction of the energy flow received or provided by a 763 Powered Entity. The standard must also provide the means to report 764 the energy passing through each Power Interface. 766 5.5.2. Time intervals 768 The standard must provide means for reporting the time interval for 769 which an energy value is reported. 771 5.5.3. Energy per Power State 773 The standard must provide means for reporting the received and 774 provided energy for each individual power state. This extends the 775 requirement 5.4.7 on Power State statistics. 777 5.6. Battery State 779 Many Powered Entities contain batteries that supply them with power 780 when disconnected from electrical power distribution grids. The 781 status of these batteries is typically controlled by automatic 782 functions that act locally on the Powered Entity and manually by 783 users of the powered entity. There is a need to monitor the battery 784 status of these entities by network management systems. 786 Devices containing batteries can be modeled in two ways. The entire 787 device can be modeled as a single Powered Entity on which energy- 788 related information is reported or the battery can be modeled as an 789 individual Powered Entity for which energy-related information is 790 monitored individually according to requirements in Sections 5.1 to 791 5.5. 793 Further information on batteries is of interest for energy 794 management, such as the current charge of the battery, the number of 795 completed charging cycles, the charging state of the battery, and 796 further static and dynamic battery properties. It is desirable to 797 receive notifications if the charge of a battery becomes very low or 798 if a battery needs to be replaced. 800 5.6.1. Battery charge 802 The standard must provide means for reporting the current charge of a 803 battery. 805 5.6.2. Battery charging state 807 The standard must provide means for reporting the charging state 808 (charging, discharging, etc.) of a battery. 810 5.6.3. Battery charging cycles 812 The standard must provide means for reporting the number of completed 813 charging cycles of a battery. 815 5.6.4. Actual battery capacity 817 The standard must provide means for reporting the actual capacity of 818 a battery. 820 5.6.5. Static battery properties 822 The standard must provide means for reporting static properties of a 823 battery, including the nominal capacity, the number of cells, the 824 nominal voltage, and the battery technology. 826 5.6.6. Low battery charge notification 828 The standard must provide means for generating a notification when 829 the charge of a battery decreases below a given threshold. 831 5.6.7. Battery replacement notification 833 The standard must provide means for generating a notification when 834 the number of charging cycles of battery exceeds a given threshold. 836 5.6.8. Multiple batteries 838 The standard must provide means for meeting requirements 5.6.1 to 839 5.6.7 for each individual battery contained in a single Powered 840 Entity. 842 5.7. Time series of measured values 844 For some network management tasks, it is required to obtain time 845 series of measured values from Powered Entities , such as power, 846 energy, battery charge, etc. 848 In general time series measurements could be obtained in many 849 different ways. It should be avoided that such time series can only 850 be obtained through regular polling by the energy management system. 851 Means should be provided to either push such values from the location 852 where they are available to the management system or to have them 853 stored locally for a sufficiently long period of time such that a 854 management system can retrieve full time series. 856 The following issues are to be considered when designing time series 857 measurement and reporting functions: 858 1. Which quantities should be reported? 859 2. Which time interval type should be used (total, delta, sliding 860 window)? 861 3. Which measurement method should be used (sampled, continuous)? 862 4. Which reporting model should be used (push or pull)? 864 The most discussed and probably most needed quantity is energy. But 865 a need for others, such as power and battery charge can be identified 866 as well. 868 There are three time interval types under discussion for accumulated 869 quantities such as energy. They can be reported as total values, 870 accumulated between the last restart of the measurement and a certain 871 timestamp. Alternatively, energy can be reported as delta values 872 between two consecutive timestamps. Another alternative is reporting 873 values for sliding windows as specified in [IEC.61850-7-4]. 875 For non-accumulative quantities, such as power, different measurement 876 methods are considered. Such quantities can be reported using values 877 sampled at certain time stamps or alternatively by mean values for 878 these quantities averaged between two (consecutive) time stamps or 879 over a sliding window. 881 Finally, time series can be reported using different reporting 882 models, particularly push-based or pull-based. Push-based reporting 883 can, for example, be realized by reporting power or energy values 884 using the IPFIX protocol [RFC5101],[RFC5102]. SNMP [RFC3411] is an 885 example for a protocol that can be used for realizing pull-based 886 reporting of time series. 888 For reporting time series of measured values the following 889 requirements have been identified. Further decisions concerning 890 issues discussed above need to be made when developing concrete 891 energy management standards. 893 5.7.1. Time series of energy values 895 The standard must provide means for reporting time series of energy 896 values. 898 5.7.2. Time series storage capacity 900 The management standard should provide means for reporting the number 901 of values of a time series that can be stored for later reporting. 903 6. Control of Powered Entities 905 Many Powered Entities control their Power State locally. Other 906 Powered Entities need interfaces for an energy management system to 907 control their Power State. 909 Power supply is typically not self-managed by powered entities. And 910 controlling power supply is typically not conducted as interaction 911 between energy management system and the Powered Entity itself. It 912 is rather an interaction between the management system and an entity 913 providing power at its power outlets. Similar to Power State 914 control, power supply control may be policy driven. Note that 915 shutting down the power supply abruptly may have severe consequences 916 for the Powered Entity. 918 6.1. Controlling Power States 920 The standard must provide means for setting Power States of Powered 921 Entities . 923 6.2. Controlling power supply 925 The standard must provide means for switching power supply off or 926 turning power supply on at power outlets providing power to one or 927 more Powered Entity. 929 7. Reporting on other Powered Entities 931 As discussed in Section 5, not all energy-related information may be 932 available at the concerned Powered Entity. Such information may be 933 provided by other Powered Entities . This section covers reporting 934 of information only. See Section 8 for requirements on controlling 935 other Powered Entities . 937 There are cases where a power supply unit switches power for several 938 Powered Entities by turning power on or off at a single power outlet 939 or where a power meter measures the accumulated power of several 940 Powered Entities at a single power line. Consequently, it should be 941 possible to report that a monitored value does not relate to just a 942 single Powered Entity, but is an accumulated value for a set of 943 Powered Entities . All of these Powered Entities belonging to that 944 set need to be identified. 946 If a Powered Entity has information about where energy-related 947 information on itself can be retrieved, then it would be useful to 948 communicate this information. This applies even if the information 949 only provides accumulated quantities for several Powered Entities . 951 7.1. Reports on other Powered Entities 953 The standard must provide means for a Powered Entity to report 954 information on another Powered Entity. 956 7.2. Identity of other Powered Entities on which is reported 958 For entities that report on one or more other entities, the standard 959 must provide means for reporting the identity of other Powered 960 Entities on which information is reported. 962 7.3. Reporting quantities accumulated over multiple Powered Entities 964 The standard must provide means for reporting the list of all Powered 965 Entities from which contributions are included in an accumulated 966 value. 968 7.4. List of all Powered Entities on which is reported 970 For entities that report on one or more other entities, the standard 971 must provide means for reporting the complete list of all those 972 Powered Entities on which energy-related information can be reported. 974 7.5. Content of reports on other Powered Entities 976 For entities that report on one or more other entities, the standard 977 must provide means for indicating which energy-related information 978 can be reported for which of those Powered Entities . 980 7.6. Indicating source of remote information 982 For an entity that has one or more other entities reporting on its 983 behalf, the standard must provide means for the entity to indicate 984 which information is available at which other entity. 986 8. Controlling Other Powered Entities 988 This section specifies requirements for controlling Power States and 989 power supply of Powered Entities by communicating with other Powered 990 Entities that have means for controlling Power State or power supply 991 of others. 993 8.1. Controlling Power States of other Powered Entities 995 Some Powered Entities have control over Power States of other Powered 996 Entities . For example a gateway to a building system may have means 997 to control the Power State of powered entities in the building that 998 do not have an IP interface. For this scenario and other similar 999 cases means are needed to make this control accessible to the energy 1000 management system. 1002 In addition to this, it is required that a Powered Entity that has 1003 its state controlled by other Powered Entities has means to report 1004 the list of these other Powered Entities . 1006 8.1.1. Control of Power States of other Powered Entities 1008 The standard must provide means for an energy management system to 1009 send Power State control commands to a Powered Entity that concern 1010 the Power States of other Powered Entities than the one the command 1011 was sent to. 1013 8.1.2. Identity of other Power State controlled entities 1015 The standard must provide means for reporting the identities of the 1016 Powered Entities for which the reporting Powered Entity has means to 1017 control their Power States. 1019 8.1.3. List of all Power State controlled entities 1021 The standard must provide means for a Powered Entity to report the 1022 list of all Powered Entities for which it can control the Power 1023 State. 1025 8.1.4. List of all Power State controllers 1027 The standard must provide means for a Powered Entity that receives 1028 commands controlling its Power State from other Powered Entities to 1029 report the list of all those entities. 1031 8.2. Controlling power supply 1033 Some Powered Entities may have control of the power supply of other 1034 Powered Entities , for example, because the other Powered Entity is 1035 supplied via a power outlet of the Powered Entity. For this and 1036 similar cases means are needed to make this control accessible to the 1037 energy management system. This need is already addressed by 1038 requirement 6.2. 1040 In addition, it is required that a Powered Entity that has its supply 1041 controlled by other Powered Entities has means to report the list of 1042 these other Powered Entities . This need is already addressed by 1043 requirements 5.2.2 and 5.2.3. 1045 9. Security Considerations 1047 Controlling Power State and power supply of powered entities are 1048 highly sensitive actions since they can significantly affect the 1049 operation of directly and indirectly affected devices. Therefore all 1050 control actions addressed in 6 and 8 must be sufficiently protected 1051 through authentication, authorization, and integrity protection 1052 mechanisms. 1054 Monitoring energy-related quantities of a Powered Entity addressed in 1055 Sections 5 - 8 can be used to derive more information than just the 1056 received and provided energy, so monitored data requires privacy 1057 protection. Monitored data may be used as input to control, 1058 accounting, and other actions, so integrity of transmitted 1059 information and authentication of the origin may be needed. 1061 9.1. Secure energy management 1063 The standard must provide privacy, integrity, and authentication 1064 mechanisms for all actions addressed in Sections 5 - 8. The security 1065 mechanisms must address all threats listed in Section 1.4 of 1066 [RFC3411]. 1068 10. IANA Considerations 1070 This document has no actions for IANA. 1072 11. Acknowledgements 1074 The authors would like to thank Ralf Wolter for his first essay on 1075 this draft. Many thanks to William Mielke, John Parello, Bruce 1076 Nordman, JinHyeock Choi, Georgios Karagiannis, and Michael Suchoff 1077 for helpful comments on the draft. 1079 12. Informative References 1081 [RFC1628] Case, J., "UPS Management Information Base", RFC 1628, 1082 May 1994. 1084 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1085 Architecture for Describing Simple Network Management 1086 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1087 December 2002. 1089 [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor 1090 Management Information Base", RFC 3433, December 2002. 1092 [RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", 1093 RFC 3621, December 2003. 1095 [RFC3805] Bergman, R., Lewis, H., and I. McDonald, "Printer MIB v2", 1096 RFC 3805, June 2004. 1098 [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", 1099 RFC 4133, August 2005. 1101 [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268, 1102 November 2005. 1104 [RFC5101] Claise, B., "Specification of the IP Flow Information 1105 Export (IPFIX) Protocol for the Exchange of IP Traffic 1106 Flow Information", RFC 5101, January 2008. 1108 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 1109 Meyer, "Information Model for IP Flow Information Export", 1110 RFC 5102, January 2008. 1112 [I-D.ietf-eman-applicability-statement] 1113 Silver, L., Chandramouli, M., and B. Nordman, "Energy 1114 Management (EMAN) Applicability Statement", 1115 draft-ietf-eman-applicability-statement-01 (work in 1116 progress), June 2012. 1118 [ACPI.R30b] 1119 Hewlett-Packard Corporation, Intel Corporation, Microsoft 1120 Corporation, Phoenix Corporation, and Toshiba Corporation, 1121 "Advanced Configuration and Power Interface 1122 Specification, Revision 3.0b", October 2006. 1124 [ANSI-TIA-1057] 1125 Telecommunications Industry Association, "ANSI-TIA-1057- 1126 2006 - TIA Standard - Telecommunications - IP Telephony 1127 Infrastructure - Link Layer Discovery Protocol for Media 1128 Endpoint Devices", April 2006. 1130 [DMTF.DSP1027] 1131 Dasari (ed.), R., Davis (ed.), J., and J. Hilland (ed.), 1132 "Power State Management Profile", September 2008. 1134 [Fed-Std-1037C] 1135 United States National Communications System Technology & 1136 Standards Division, "Federal Standard 1037C - 1137 Telecommunications: Glossary of Telcommunication Terms", 1138 August 1996. 1140 [IEEE-ISTO] 1141 Printer Working Group, "PWG 5106.4 - PWG Power Management 1142 Model for Imaging Systems 1.0", February 2011. 1144 [IEEE-100] 1145 IEEE, "Authoritative Dictionary of IEEE Standards Terms, 1146 IEEE 100, Seventh Edition", December 2000. 1148 [IEC.62053-21] 1149 International Electrotechnical Commission, "Electricity 1150 metering equipment (a.c.) - Particular requirements - Part 1151 22: Static meters for active energy (classes 1 and 2)", 1152 2003. 1154 [IEC.62053-22] 1155 International Electrotechnical Commission, "Electricity 1156 metering equipment (a.c.) - Particular requirements - Part 1157 22: Static meters for active energy (classes 0,2 S and 1158 0,5 S)", 2003. 1160 [IEC.61850-7-4] 1161 International Electrotechnical Commission, "Communication 1162 networks and systems for power utility automation - Part 1163 7-4: Basic communication structure - Compatible logical 1164 node classes and data object classes", 2010. 1166 [IEEE-1621] 1167 Institute of Electrical and Electronics Engineers, "IEEE 1168 P1621-2004 -Draft Standard for User Interface Elements 1169 in Power Control of Electronic Devices Employed in Office 1170 Consumer Environments", June 2005. 1172 [IEEE-802.1AB] 1173 IEEE Computer Society, "IEEE Std 802.1AB-2009 - IEEE 1174 Standard for Local and metropolitan area networks - 1175 Station and Media Access Control Discovery", September 1176 2009. 1178 [ITU-M.3400] 1179 International Telcommunication Union, "ITU-T 1180 Recommendation M.3400 - Series M: TMN and Network 1181 Maintenance: International Transmission Systems, 1182 Telephone Circuits, Telegraphy, Facsimile and Leased 1183 Circuits - Telecommunications Management Network - TMN 1184 management functions", February 2000. 1186 Appendix A. Existing Standards 1188 This section analyzes existing standards for energy and Power State 1189 monitoring. It shows that there are already several standards that 1190 cover only some part of the requirements listed above, but even all 1191 together they do not cover all of the requirements for energy 1192 management. 1194 A.1. Existing IETF Standards 1196 There are already RFCs available that address a subset of the 1197 requirements. 1199 A.1.1. ENTITY MIB 1201 The ENTITY-MIB module defined in [RFC4133] was designed to model 1202 physical and logical entities of a managed system. A physical entity 1203 is an identifiable physical component. A logical entity can use one 1204 or more physical entities. From an energy monitoring perspective of 1205 a managed system, the ENTITY-MIB modeling framework can be reused and 1206 whenever RFC 4133 [RFC4133] has been implemented. The 1207 entPhysicalIndex from entPhysicalTable can be used to identify an 1208 entity/component. However, there are use cases of energy monitoring, 1209 where the application of the ENTITY-MIB does not seem readily 1210 apparent and some of those entities could be beyond the original 1211 scope and intent of the ENTITY-MIB. 1213 Consider the case of remote devices attached to the network, and the 1214 network device could collect the energy measurement and report on 1215 behalf of such attached devices. Some of the remote devices such as 1216 PoE phones attached to a switch port have been considered in the 1217 Power-over-Ethernet MIB module [RFC3621]. However, there are many 1218 other devices such as a computer, which draw power from a wall outlet 1219 or building HVAC devices which seem to be beyond the original scope 1220 of the ENTITY-MIB. 1222 Yet another example, is smart-PDUs, which can report the energy 1223 provided to the device attached to the power outlet of the PDU. In 1224 some cases, the device can be attached to multiple to power outlets. 1225 Thus, the energy measured at multiple outlets need to be aggregated 1226 to determine the energy provided to a single device. From mapping 1227 perspective, between the PDU outlets and the device this is a many- 1228 to-one mapping. It is not clear if such a many-to-one mapping is 1229 feasible within the ENTITY-MIB framework. 1231 A.1.2. ENTITY STATE MIB 1233 RFC 4268 [RFC4268] defines the ENTITY STATE MIB module. 1234 Implementations of this module provide information on entities 1235 including the standby status (hotStandby, coldStandby, 1236 providingService), the operational status (disabled, enabled, 1237 testing), the alarm status (underRepair, critical, major, minor, 1238 warning), and the usage status (idle, active, busy). This 1239 information is already useful as input for policy decisions and for 1240 other network management tasks. However, the number of states would 1241 cover only a small subset of the requirements for Power State 1242 monitoring and it does not provide means for energy monitoring. For 1243 associating the information conveyed by the ENTITY STATE MIB to 1244 specific components of a device, the ENTITY STATE MIB module makes 1245 use of the means provided by the ENTITY MIB module [RFC4133]. 1246 Particularly, it uses the entPhysicalIndex for identifying entities. 1248 The standby status provided by the ENTITY STATE MIB module is related 1249 to Power States required for energy management, but the number of 1250 states is too restricted for meeting all energy management 1251 requirements. For energy management several more Power States are 1252 required, such as different sleep and operational states as defined 1253 by the Advanced Configuration and Power Interface (ACPI) [ACPI.R30b] 1254 or the DMTF Power State Management Profile [DMTF.DSP1027]. 1256 A.1.3. ENTITY SENSOR MIB 1258 RFC 3433 [RFC3433] defines the ENTITY SENSOR MIB module. 1259 Implementations of this module offer a generic way to provide data 1260 collected by a sensor. A sensor could be an energy meter delivering 1261 measured values in Watt. This could be used for reporting current 1262 power of an entity and its components. Furthermore, the ENTITY 1263 SENSOR MIB can be used to retrieve the accuracy of the used power 1264 meter. 1266 Similar to the ENTITY STATE MIB module, the ENTITY SENSOR MIB module 1267 makes use of the means provided by the ENTITY MIB module [RFC4133] 1268 for relating provided information to components of a device. 1270 However, there is no unit available for reporting energy quantities, 1271 such as, for example, watt seconds or kilowatt hours, and the ENTITY 1272 SENSOR MIB module does not support reporting accuracy of measurements 1273 according to the IEC / ANSI accuracy classes, which are commonly in 1274 use for electric power and energy measurements. The ENTITY SENSOR 1275 MIB modules only provides a coarse-grained method for indicating 1276 accuracy by stating the number of correct digits of fixed point 1277 values. 1279 A.1.4. UPS MIB 1281 RFC 1628 [RFC1628] defines the UPS MIB module. Implementations of 1282 this module provide information on the current real power of entities 1283 attached to an uninterruptible power supply (UPS) device. This 1284 application would require identifying which entity is attached to 1285 which port of the UPS device. 1287 UPS MIB provides information on the state of the UPS network. The 1288 MIB module contains several variables that are used to identify the 1289 UPS entity (name, model,..), the Battery State, to characterize the 1290 input load to the UPS, to characterize the output from the UPS, to 1291 indicate the various alarm events. The measurements of power in UPS 1292 MIB are in Volts, Amperes and Watts. The units of power measurement 1293 are RMS volts, RMS Amperes and are not based on Entity-Sensor MIB 1294 [RFC3433]. 1296 A.1.5. POWER ETHERNET MIB 1298 Similar to the UPS MIB, implementations of the POWER ETHERNET MIB 1299 module defined in RFC3621 [RFC3621] provide information on the 1300 current power of the entities that receive Power over Ethernet (PoE). 1301 This information can be retrieved at the power sourcing equipment. 1302 Analogous to the UPS MIB, it is required to identify which entities 1303 are attached to which port of the power sourcing equipment. 1305 The POWER ETHERNET MIB does not report power and energy on a per port 1306 basis, but can report aggregated values for groups of ports. It does 1307 not use objects of the ENTITY MIB module for identifying entities, 1308 although this module existed already when the POWER ETHERNET MIB 1309 modules was standardized. 1311 A.1.6. LLDP MED MIB 1313 The Link Layer Discovery Protocol (LLDP) defined in IEEE 802.1ab is a 1314 data link layer protocol used by network devices for advertising of 1315 their identities, capabilities, and interconnections on a LAN 1316 network. The Media Endpoint Discovery (MED) (ANSI-TIA-1057) is an 1317 enhancement of LLDP known as LLDP-MED. The LLDP-MED enhancements 1318 specifically address voice applications. LLDP-MED covers 6 basic 1319 areas: capabilities discovery, LAN speed and duplex discovery, 1320 network policy discovery, location identification discovery, 1321 inventory discovery, and power discovery. 1323 A.2. Existing standards of other bodies 1325 A.2.1. DMTF 1327 The DMTF has defined a Power State management profile [DMTF.DSP1027] 1328 that is targeted at computer systems. It is based on the DMTF's 1329 Common Information Model (CIM) and it is rather an entity profile 1330 than an actual energy monitoring standard. 1332 The Power State management profile is used to describe and to manage 1333 the Power State of computer systems. This includes e.g. means to 1334 change the Power State of an entity (e.g. to shutdown the entity) 1335 which is an aspect of but not sufficient for active energy 1336 management. 1338 A.2.2. OVDA 1340 ODVA is an association consisting of members from industrial 1341 automation companies. ODVA supports standardization of network 1342 technologies based on the Common Industrial Protocol (CIP). Within 1343 ODVA, there is a special interest group focused on energy and 1344 standardization and inter-operability of energy aware entities. 1346 A.2.3. IEEE-ISTO Printer WG 1348 The charter of the IEEE-ISTO Printer Working Group is for open 1349 standards that define printer related protocols, that printer 1350 manufacturers and related software vendors shall benefit from the 1351 interoperability provided by conformance to these standards. One 1352 particular aspect the Printer WG is focused on is power monitoring 1353 and management of network printers and imaging systems PWG Power 1354 Management Model for Imaging Systems [IEEE-ISTO]. Clearly, these 1355 devices are within the scope of energy management since these devices 1356 receive power and are attached to the network. In addition, there is 1357 ample scope of power management since printers and imaging systems 1358 are not used that often. IEEE-ISTO Printer working group has defined 1359 MIB modules for monitoring power and Power State series that can be 1360 useful for power management of printers. The energy management 1361 framework should also take into account the standards defined in the 1362 Printer working group. In terms of other standards, IETF Printer MIB 1363 RFC3805 [RFC3805] has been standardized, however, this MIB module 1364 does not address power management of printers. 1366 Authors' Addresses 1368 Juergen Quittek (editor) 1369 NEC Europe Ltd. 1370 NEC Laboratories Europe 1371 Network Research Division 1372 Kurfuersten-Anlage 36 1373 Heidelberg 69115 1374 DE 1376 Phone: +49 6221 4342-115 1377 Email: quittek@neclab.eu 1378 Rolf Winter 1379 NEC Europe Ltd. 1380 NEC Laboratories Europe 1381 Network Research Division 1382 Kurfuersten-Anlage 36 1383 Heidelberg 69115 1384 DE 1386 Phone: +49 6221 4342-121 1387 Email: Rolf.Winter@neclab.eu 1389 Thomas Dietz 1390 NEC Europe Ltd. 1391 NEC Laboratories Europe 1392 Network Research Division 1393 Kurfuersten-Anlage 36 1394 Heidelberg 69115 1395 DE 1397 Phone: +49 6221 4342-128 1398 Email: Thomas.Dietz@neclab.eu 1400 Benoit Claise 1401 Cisco Systems, Inc. 1402 De Kleetlaan 6a b1 1403 Degem 1831 1404 BE 1406 Phone: +32 2 704 5622 1407 Email: bclaise@cisco.com 1409 Mouli Chandramouli 1410 Cisco Systems, Inc. 1411 Sarjapur Outer Ring Road 1412 Bangalore, 1413 IN 1415 Phone: +91 80 4426 3947 1416 Email: moulchan@cisco.com