idnits 2.17.1 draft-quittek-power-monitoring-requirements-02.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 -- The document date (October 22, 2010) is 4935 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) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: April 25, 2011 NEC Europe Ltd. 6 B. Claise 7 M. Chandramouli 8 Cisco Systems, Inc. 9 October 22, 2010 11 Requirements for Power Monitoring 12 draft-quittek-power-monitoring-requirements-02 14 Abstract 16 This memo discusses requirements for energy management, particularly 17 for monitoring energy consumption and controlling power states of 18 managed devices. This memo further shows that existing IETF 19 standards are not sufficient for energy management and that energy 20 management requires architectural considerations that are diffenrent 21 from common other management functions. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 25, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Energy management functions . . . . . . . . . . . . . . . 4 59 1.2. Specific aspects of energy management . . . . . . . . . . 6 61 2. Scenarios and target devices . . . . . . . . . . . . . . . . . 6 62 2.1. Scenario 1: Routers, switches, middleboxes, and hosts . . 6 63 2.2. Scenario 2: PoE sourcing equipment and PoE powered 64 devices . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 2.3. Scenario 3: Power probes and Smart meters . . . . . . . . 7 66 2.4. Scenario 4: Mid-level managers . . . . . . . . . . . . . . 7 67 2.5. Scenario 5: Gateways to building networks . . . . . . . . 7 68 2.6. Scenario 6: Home energy gateways . . . . . . . . . . . . . 8 69 2.7. Scenario 7: Data center devices . . . . . . . . . . . . . 8 70 2.8. Scenario 8: Battery powered devices . . . . . . . . . . . 8 72 3. Monitoring Requirements . . . . . . . . . . . . . . . . . . . 8 73 3.1. Granularity of monitoring and control . . . . . . . . . . 8 74 3.2. Remote and Aggregated Monitoring . . . . . . . . . . . . . 9 75 3.3. Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.4. Required Information . . . . . . . . . . . . . . . . . . . 10 77 3.4.1. Power State Monitoring . . . . . . . . . . . . . . . . 10 78 3.4.2. Energy Consumption Monitoring . . . . . . . . . . . . 11 79 3.4.3. Power Quality . . . . . . . . . . . . . . . . . . . . 11 80 3.4.4. Battery State Monitoring . . . . . . . . . . . . . . . 12 82 4. Monitoring Models . . . . . . . . . . . . . . . . . . . . . . 12 84 5. Control Requirements . . . . . . . . . . . . . . . . . . . . . 13 86 6. Existing Standards . . . . . . . . . . . . . . . . . . . . . . 13 87 6.1. Existing IETF Standards . . . . . . . . . . . . . . . . . 13 88 6.1.1. ENTITY STATE MIB . . . . . . . . . . . . . . . . . . . 13 89 6.1.2. ENTITY SENSOR MIB . . . . . . . . . . . . . . . . . . 14 90 6.1.3. UPS MIB . . . . . . . . . . . . . . . . . . . . . . . 14 91 6.1.4. POWER ETHERNET MIB . . . . . . . . . . . . . . . . . . 15 92 6.1.5. LLDP MED MIB . . . . . . . . . . . . . . . . . . . . . 15 93 6.2. Existing standards of other bodies . . . . . . . . . . . . 15 94 6.2.1. DMTF . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 7. Suggested Actions . . . . . . . . . . . . . . . . . . . . . . 16 98 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 102 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 104 11. Informative References . . . . . . . . . . . . . . . . . . . . 17 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 108 1. Introduction 110 With rising energy cost and with an increasing awareness of the 111 ecological impact of running IT and networking equipment, energy 112 management is becoming an additional basic requirement for network 113 management frameworks and systems. 115 Different to other typical network management functions, energy 116 management often extends its scope beyond devices with IP network 117 interfaces. Requirements in this document do not fully cover all 118 these networks, but they cover means for opening IP network 119 management towards them. 121 In general, IETF Standards for energy management should be defined in 122 such a way that they can be applied to several areas including 123 o Communication networks and IT systems 124 o Building networks 125 o Home networks 126 o Smart (power) grids 128 1.1. Energy management functions 130 The basic objective of energy management is operating communication 131 networks and other equipment with a minimal amount of energy. An 132 energy management system should provide means for reducing the power 133 consumption of individual components of a network as well as of the 134 whole network. 136 One approach to achieve this goal is setting all components to an 137 operational state that results in lower energy consumption but still 138 meets service level performance objectives. The sufficient 139 performance level may vary over time and can depend on several 140 factors. In principle, there are four basic types of power states 141 for a component or for a whole system: 142 o full power state 143 o reduced power states (lower clock rate for processor, lower data 144 rate on a link, etc.) 145 o stand-by/sleep state (not functional, but immediately available) 146 o power-off state (requiring significant time for becoming 147 operational) 148 In actual implementations the number of power states and their 149 properties vary a lot. Very simple devices may just have a full 150 power and a power off state, while other devices may have a high 151 number of different reduced power and sleep states. 153 While the general objective of energy management is quite clear, the 154 way to attain that goal is often difficult. In many cases there is 155 no way of reducing power consumption without the consequence of a 156 potential performance degradation. Then a trade-off needs to be 157 dealt with between service level objectives and energy efficiency. 158 In other cases a reduction of energy consumption can easily be 159 achieved while still maintaining sufficient service level 160 performance, for example, by switching components to lower power 161 states when higher performance is not needed. 163 Network management systems can control such situations by 164 implementing policies to achieve a certain degree of energy 165 efficiency. In order to make policy decisions properly, information 166 about the energy consumption of network components and sub-components 167 in different power states is required. Often this information is 168 acquired best through monitoring. 170 Monitoring operational power states and energy consumption is also 171 useful for other energy management purposes including but not limited 172 to 173 o investigating power saving potential 174 o evaluating the effectiveness of energy saving policies and 175 measures 176 o deriving, implementing, and testing power management strategies 177 o accounting the total power consumption of a network element, a 178 network, a service, or subcomponents of those 180 From the considerations described above the following basic 181 management functions appear to be required for energy management: 182 o monitoring power states of network elements and their 183 subcomponents 184 o monitoring actual power (energy consumption rate) of network 185 elements and their subcomponents 186 o monitoring (accumulated) energy consumption of network elements 187 and their subcomponents 188 o setting power states of network elements and their subcomponents 189 o setting and enforcing power saving policies 191 Editorial note: With the extension to power state control and policy 192 enforcement, the title of the draft does not anymore match the scope 193 well. The name of the draft will be updated in a future revision. 195 It should be noted that monitoring energy consumption and power 196 states itself is obviously not in itself a means to reduce the energy 197 consumption of a device. In fact, it is likely to increase the power 198 consumption of a device slightly. However, the acquired energy 199 consumption and power state information is essential fordefining 200 energy saving policies and can be used as input to power state 201 control loops that in total can lead to energy savings. 203 It should further be noted that active power control is complementary 204 (but essential) to other energy savings measures such as low power 205 electronics, energy saving protocols (e.g. IEEE 802.3az), and 206 energy-efficient device design (for example, stand-by and low-power 207 modes for individual components of a device), and energy-efficient 208 network architectures. Measurement of energy consumption may also 209 provide input for developing these technologies. 211 1.2. Specific aspects of energy management 213 There are two aspects of energy management that make it different 214 from other common network management functions. The first difference 215 is that energy consumption is often measured remotely to the device 216 under consideration. A reason for this is that today very few 217 devices are instrumented with the hardware and software for measuring 218 their own current power and accumulated energy consumption. Often 219 power and energy for such devices is measured by other devices. 221 A common example is a Power over Ethernet (PoE) sourcing device that 222 provides means for measuring provided power per port. If the device 223 connected to a port is known, power and energy measurements for that 224 device can be conducted by the PoE sourcing device. Another example 225 is a smart power strip. Again, if it is known which devices are 226 plugged into which outlets of the smart power strip, then the power 227 strip can provide measured values for these devices. 229 The second difference is that often it is desirable to apply energy 230 management also to networks and devices that do not communicate via 231 IP, for example, in building networks where besides IP several other 232 communication protocols are used. In these networks, it may be 233 desirable that devices with IP interfaces report energy and power 234 values for other devices. Reports may be based on measurements at 235 the reporting device, similar to the PoE sourcing device and the 236 smart strip. But reports may also be just relayed from non-IP 237 communication to IP communication. 239 2. Scenarios and target devices 241 This section describes a selection of scenarios for the application 242 of energy management. For each scenario a list of target devices is 243 given in the headline, for which IETF energy management standards are 244 needed. 246 2.1. Scenario 1: Routers, switches, middleboxes, and hosts 248 Power management of network devices is considered as a fundamental 249 (basic first step) requirement. The devices listed in this scenario 250 are some of the components of a communication network. For these 251 network devices, the chassis draws power from an outlet and feeds all 252 its internal sub-components. 254 2.2. Scenario 2: PoE sourcing equipment and PoE powered devices 256 This scenario covers devices using Power over Ethernet (PoE). A PoE 257 Power Sourcing Equipment (PSE), for example, a PoE switch, provices 258 power to a PoW Powered Device (PD), for example, a PoE desktop phone. 259 Here, the PSE provides means for controlling power supply (switching 260 it on and off) and for monitoring actual power provided at a port to 261 a specific PD. 263 2.3. Scenario 3: Power probes and Smart meters 265 Today, very few devices are equipped with sufficient instrumentation 266 to measure their own actual power and accumulated energy consumption. 267 Often external probes are connected to the power supply for measuring 268 these properties for a single device or for a set of devices. 270 Homes, buildings, and data centers have smart meters that monitor and 271 report accumulated power consumption of an entire home, a set of 272 offices or a set of devices in data centers. 274 Power Distribution Unit (PDUs) attached to racks in data center and 275 other smart power strips are evolving with smart meters and remote 276 controllable power switches embedded for each socket. 278 2.4. Scenario 4: Mid-level managers 280 Sometimes it is useful to have mid-level managers that provide energy 281 management functions not just for themselves but also for a set of 282 associated devices. For example, a switch can provide energy 283 management functions for all devices connected to its ports, even if 284 these devices are not PoE PDs, but have their own power supply as, 285 for example, PCs connected to the switch. 287 2.5. Scenario 5: Gateways to building networks 289 Due to the potential energy savings, energy management of buildings 290 has received significant attention. There are gateway network 291 elements to manage the multiple components of a building energy 292 management network Heating Ventilating Air Conditioning (HVAC), 293 lighting, electrical, fire and emergency systems, elevators etc. The 294 gateway device provides power monitoring and control function for 295 other devices in the building network. 297 2.6. Scenario 6: Home energy gateways 299 Home energy gateway can be used for energy management of a home. 300 This gateway can manage the appliances (refrigerator, heating/ 301 cooling, washing machine etc.) and interface with the electrical 302 grid. The gateway can implement policies based on demand and energy 303 pricing from the grid. 305 2.7. Scenario 7: Data center devices 307 Energy efficiency of data centers has become a fundamental challenges 308 of data center operation. Energy management is conducted on 309 different aggregation levels, such as network level, Power 310 Distribution Unit (PDU) level, and server level. 312 2.8. Scenario 8: Battery powered devices 314 Some devices have a battery as a back-up source of power. Given the 315 finite capacity and lifetime of a battery, means for reporting the 316 actual charge, age, and state of a battery are required. 318 3. Monitoring Requirements 320 3.1. Granularity of monitoring and control 322 Often it is desirable to switch off individual components of a device 323 but not the entire device. The switch may need to continue serving a 324 few ports (for example, the ports serving an email server or needed 325 for server backup), but most other ports could be entirely switched 326 off under some policies (for example at night or the weekend in an 327 office). 329 As illustrated by this example, it is often desirable to monitor 330 power state and energy consumption on a granularity level that is 331 finer than just the device level. Monitoring should be available for 332 individual components of devices, such as line cards, processor 333 cards, hard drives, etc. For example, for IP routers the following 334 list of views of a router gives an idea of components that 335 potentially could be monitored and controlled individually: 336 o Physical view: chassis (or stack), central control engine, line 337 cards, service cards, etc. 338 o Component view: CPU, ASICs, fans, power supply, ports (single 339 ports and port groups), storage and memory 340 o Feature view: L2 forwarding, L3 routing, security features, load 341 balancing features, network management, etc. 343 o Logical view: system, data-plane, control-plane, etc. 344 o Relationship view: line cards, ports and the correlation between 345 transmission speed and power consumption, relationship of system 346 load and total power consumption 348 Instrumentation for measuring energy consumption of a device is 349 typically more expensive than instrumentation for retrieving the 350 devices power state. It may be a reasonable compromise in many cases 351 to provide power state information for all individually switchable 352 components of a device separately, while the energy consumption is 353 only measured for the entire device. 355 3.2. Remote and Aggregated Monitoring 357 There are several ways power and energy consumption can be measured 358 and reported. Measurements can be performed locally at the device 359 that consumes energy or remotely by a device that has access to the 360 power supply of another device. 362 Instrumentation for power and energy measurements at a device 363 requires additional hardware. A cost-efficient alternative is 364 measuring power and energy consumption aggregated for a set of 365 devices, for example a PoE PSE reporting these values per port group 366 instead of per port, or a power distribution unit that reports the 367 values for all connected devices instead of per socket. 369 If aggregated measurement is conducted, it is obvious that reporting 370 provides aggregated values. but aggregated reporting can also be 371 combined with local measurements. A managed node may act as mid- 372 level manager or protocol converter for several devices that measure 373 power consumption by themselves, for example a home gateway or a 374 gateway to building networks. In this case, the reporting node may 375 choose to report for each device individual values or aggregated 376 values from groups of devices that transmitted their power and energy 377 consumption values to the reporting node. 379 Often it is sufficient and more cost efficient having a single device 380 measuring and providing power state and energy consumption 381 information not just for itself but also for several further devices 382 that are in some way attached to it. If the measuring and reporting 383 device has access to individual power supply lines for each device, 384 then it can measure energy consumption per device. If it only has 385 access to a joint power supply for several devices, then it will 386 measure aggregated values. 388 One example for the first case is a switch acting as power sourcing 389 equipment for several IP phones using Power over Ethernet (PoE). The 390 switch can measure the power consumption for each phone individually 391 at the port the phone is connected to or it measures aggregated 392 values per port group for a set of devices.. The phones do not need 393 to provide means for energy consumption measurement and reporting by 394 themselves. 396 Another example is a smart meter that just measures and reports the 397 energy transmitted through attached electric cables. Such a smart 398 meter can be used to monitor energy consumption of an individual 399 device if connected to the devices' individual power supply. But in 400 many common cases it measures the aggregated energy consumption of 401 several devices, for example, as part of an uninterruptible power 402 supply (UPS) that serves several devices at a single power cord, or 403 as a smart electric meter for a set of machines in a rack, in an 404 office building or at a residence. 406 3.3. Accuracy 408 Depending on how power and energy consumption values are obtained the 409 confidence in the reported value and its accuracy may vary. Managed 410 nodes reporting values concerning themselves or other devices should 411 qualify the confidence in reported values and quantify the accuracy 412 of measurements. For accuracy reporting, the accuracy classes 413 specified in IEC 61850 should be considered. 415 3.4. Required Information 417 This section lists requirements for information to be retrieved. 418 Because of the different nature of power state monitoring and energy 419 consumption monitoring, these are discussed separately. In addition, 420 a section on battery monitoring is included which again comes with a 421 set of very different requirements. 423 Not all of the individual requirements listed in subsections below 424 are equally relevant. A classification into 'required' and 425 'optional' is still in progress. 427 3.4.1. Power State Monitoring 429 The power state of a device or component typically can only have a 430 small number of discrete values such as, for example, full power, low 431 power, standby, hibernating, off. However, some of these states may 432 have one or more sub-states or state parameters. For example, in low 433 power state, a reduced clock rate may be set to a large number of 434 different values. For the device power state, the following 435 information is considered to be relevant: 437 o the current state - the time of the last change 438 o the cause for the last transition 439 o time to transit from one stage to another 440 o the total time spent in each state 441 o the duration of the last period spent in each state 442 o the number of transitions to each state 443 o the current power source 445 For some network management tasks it may be desirable to receive 446 notifications from devices when components or the entire device 447 change their power state. 449 3.4.2. Energy Consumption Monitoring 451 Independent of the power state, energy consumption of a device or a 452 device's component is a quantity for which the value may change 453 continuously. Therefore, the information that needs to be retrieved 454 concerning this quantity is quite different: 455 o the current real power (energy consumption rate) averaged over a 456 short time interval 457 o total energy consumption 458 o energy consumption since the last report or for the last 459 configured time interval 460 o total energy consumption per power state 461 o energy consumption per power state since the last report 462 For some network management tasks it may be desirable to receive 463 notifications from devices when the current power consumption of a 464 component or of the entire device exceeds or falls below certain 465 thresholds. 467 Energy consumption of a device or a device's component is a quantity 468 for which the value may change continuously. For some network 469 management tasks it is required to measure the power over time with a 470 relatively high time resolution. In such a case not just single 471 values for the current power of a component is needed, but a series 472 of power values reporting on consecutive time intervals. 474 In order to put measured data into perspective, the precision of the 475 measured data, i.e. the potential error in the measured data, needs 476 to be known as well. 478 3.4.3. Power Quality 480 In addition to the quantity of power or energy, also power quality 481 should be reported according to IEC 62053-22 and IEC 60044-1. 483 3.4.4. Battery State Monitoring 485 An increasing number of networked devices are expected to be battery 486 powered. This includes e.g. smart meters that report meter readings 487 and are installed in places where external power supply is not always 488 possible or costly. But also other devices might have internal/ 489 external batteries to power devices for short periods of time when 490 the main power fails, to power parts of the device when the main 491 device is switches off etc. Knowing the state of these batteries is 492 important for the operation of these devices and includes information 493 such as: 494 o the current charge of the battery 495 o the age of the battery 496 o the state of the battery (e.g. being re-charged) 497 o last usage of the battery 498 o maximum energy provided by the battery 499 It is possible for devices that are only battery-powered to send 500 notifications when the current battery charge has dropped below a 501 certain threshold in order to inform the management system of needed 502 replacement. The same applies for the age of a battery. 504 4. Monitoring Models 506 Monitoring of power states and energy consumption can be performed in 507 pull mode (for example, SNMP GET [RFC3410]) or in push mode (for 508 example SNMP notification [RFC3410], Syslog [RFC5424], or IPFIX 509 [RFC5101]). 511 Pull mode monitoring is often easier to handle for a network 512 management systems, because it can determine when it gets certain 513 information from a certain device. However, the overhead of pull 514 model monitoring is typically higher than for push model monitoring, 515 particularly when large numbers of values are to be collected, such 516 as time series of power values. 518 In such cases, push model monitoring may be preferable with a device 519 sending a data stream of values without explicit request for each 520 value from the network management system. For notifications on 521 events, only the push model is considered to be appropriate. 523 Applying these considerations to the required information leads to 524 the conclusion that most of the information can appropriately be 525 reported using the pull model. The only exceptions are notifications 526 on power state changes and high volume time series of energy 527 consumption values. 529 5. Control Requirements 531 To realize the envisioned benefits of energy savings, just monitoring 532 power states and energy consumption would not be sufficient. Energy 533 efficiency can be realized only by setting the network entities or 534 components to energy saving power states when appropriate. 536 With means for power state control, energy saving policies and 537 control loops can be realized. Policies may, for example, define 538 different power state settings based on the time-of-day. Control 539 loops may, for example, change power states based on actual network 540 load. 542 Trivially, all entities being subject of energy management should 543 have at least two power states, such as "on" and "off" or "on" and 544 "sleep" to be set. In many cases, it may be desirable to have more 545 operational ("on" mode") and non-operational ("off"/"sleep" mode) 546 power states. This applies particularly to devices with a lot of 547 configuration parameters that influence their energy consumption. 548 Examples for specifications of power states of managed devices can be 549 found in the Advanced Configuration and Power Interface (ACPI) 550 [ACPI.R30b] or the DMTF Power State Management Profile 551 [DMTF.DSP1027]. 553 6. Existing Standards 555 This section analyzes existing standards for energy consumption and 556 power state monitoring. It shows that there are already several 557 standards that cover some part of the requirements listed above, but 558 even all together they do not cover all of the requirements for 559 energy management. 561 6.1. Existing IETF Standards 563 There are already RFCs available that address a subset of the 564 requirements. 566 6.1.1. ENTITY STATE MIB 568 RFC 4268 [RFC4268] defines the ENTITY STATE MIB module. 569 Implementations of this module provide information on entities 570 including the standby status (hotStandby, coldStandby, 571 providingService), the operational status (disabled, enabled, 572 testing), the alarm status (underRepair, critical, major, minor, 573 warning), and the usage status (idle, active, busy). This 574 information is already useful as input to policy decisions and for 575 other network monitoring tasks. However, the number of states would 576 cover only a small subset of the requirements for power state 577 monitoring and it does not provide means for energy consumption 578 monitoring. For associating the provided information to specific 579 components of a device, the ENTITY STATE MIB module makes use of the 580 means provided by the ENTITY MIB module [RFC4133]. Particularly, it 581 uses the entPhysicalIndex for identifying entities. 583 The standby status provided by the ENTITY STATE MIB module is related 584 to power states required for energy management, but the number of 585 states is too restricted for meeting all energy management 586 requirements. For energy management several more power states are 587 required, such as different sleep and operational states as defined 588 by the Advanced Configuration and Power Interface (ACPI) [ACPI.R30b] 589 or the DMTF Power State Management Profile [DMTF.DSP1027]. 591 6.1.2. ENTITY SENSOR MIB 593 RFC 3433 [RFC3433] defines the ENTITY SENSOR MIB module. 594 Implementations of this module offer a generic way to provide data 595 collected by a sensor. A sensor could be an energy consumption meter 596 delivering measured values in Watt. This could be used for reporting 597 current power of a device and its components. Furthermore, the 598 ENTITY SENSOR MIB can be used to retrieve the precision of the used 599 power meter. 601 Similar to the ENTITY STATE MIB module, the ENTITY SENSOR MIB module 602 makes use of the means provided by the ENTITY MIB module [RFC4133] 603 for relating provided information to components of a device. 605 However, there is no unit available for reporting energy quantities, 606 such as, for example, watt seconds or kilowatt hours, and the ENTITY 607 SENSOR MIB module does not support reporting accuracy of measurements 608 according to the IEC / ANSI accuracy classes, which are commonly in 609 use for electric power and energy measurements. The ENTITY SENSOR 610 MIB modules only provides a coarse-grained method for indicating 611 accuracy by stating the number of correct digits of fixed point 612 values. 614 6.1.3. UPS MIB 616 RFC 1628 [RFC1628] defines the UPS MIB module. Implementations of 617 this module provide information on the current real power of devices 618 attached to an uninterruptible power supply (UPS) device. This 619 application would require identifying which device is attached to 620 which port of the UPS device. 622 UPS MIB provides information on the state of the UPS network. The 623 MIB module contains several variables identify the UPS entity (name, 624 model,..), the battery state, to characterize the input load to the 625 UPS, to characterize the output from the UPS, to indicate the various 626 alarm events. The measurements of power in UPS MIB are in Volts, 627 Amperes and Watts. The units of power measurement are RMS volts, RMS 628 Amperes and are not based on Entity-Sensor MIB [RFC3433]. 630 6.1.4. POWER ETHERNET MIB 632 Similar to the UPS MIB, implementations of the POWER ETHERNET MIB 633 module defined in RFC3621 [RFC3621] provide information on the 634 current energy consumption of the devices that receive Power over 635 Ethernet (PoE). This information can be retrieved at the power 636 sourcing equipment. Analogous to the UPS MIB, it is required to 637 identify which devices are attached to which port of the power 638 sourcing equipment. 640 The POWER ETHERNET MIB does not report power and energy consumption 641 on a per port basis, but can report aggregated values for groups of 642 ports. It does not use objects of the ENTITY MIB module for 643 identifying entities, although this module existed already when the 644 POWER ETHERNET MIB modules was standardized. 646 6.1.5. LLDP MED MIB 648 The Link Layer Discovery Protocol (LLDP) defined in IEEE 802.1ab is a 649 data link layer protocol used by network devices for advertising of 650 their identities, capabilities, and interconnections on a LAN 651 network. The Media Endpoint Discovery (MED) (ANSI/TIA-1057) is an 652 enhancement of LLDP known as LLDP-MED. The LLDP-MED enhancements 653 specifically address voice applications. LLDP-MED covers 6 basic 654 areas: capabilities discovery, LAN speed and duplex discovery, 655 network policy discovery, location identification discovery, 656 inventory discovery, and power discovery. 658 6.2. Existing standards of other bodies 660 6.2.1. DMTF 662 The DMTF has defined a power state management profile [DMTF.DSP1027] 663 that is targeted at computer systems. It is based on the DMTF's 664 Common Information Model (CIM) and rather a device profile than an 665 actual energy consumption monitoring standard. 667 The power state management profile is used to describe and to manage 668 the power state of computer systems. This includes e.g. means to 669 change the power state of a device (e.g. to shutdown the device) 670 which is an aspect of but not sufficient for active energy 671 management. 673 7. Suggested Actions 675 Based on the analysis of requirements in Section 3 and the discussion 676 of monitoring models in Section 4 this memo proposes to develop a 677 standard for pull-based monitoring of power states, energy 678 consumption, and battery states. The analysis of existing MIB 679 modules in the previous section shows that they are not sufficient to 680 meet the requirements discussed in Section 3. 682 As a consequence, it suggested to develop one or more MIB modules for 683 this purpose. Such MIB modules could also cover push-based reporting 684 of power state changes using SNMP notifications. The only aspect 685 that would not be covered well by a MIB/SNMP solution is the 686 reporting of large time series of energy consumption values. For 687 this purpose SNMP does not appear to be an optimal choice. 688 Particularly for supporting smart meter functionality, a push-based 689 protocol appears to be more appropriate. Within the IP protocol 690 family the Syslog and IPFIX protocols seem to be the most suitable 691 candidates. There are more standard protocols with the capability to 692 transfer measurement series, for example, DIAMETER, but these 693 protocols are designed and well suited for other application areas 694 than network monitoring. 696 Comparing the two candidates (Syslog and IPFIX), IPFIX seems to be 697 the better suited one. While Syslog is optimized for the 698 transmission of text messages, IPFIX is better equipped for 699 transmitting sequences of numerical values. Encoding numerical 700 values into syslog is well feasible, see, for example, the mapping of 701 SNMP notifications to Syslog messages in [RFC5675], but IPFIX 702 provides better means. With the extensible IPFIX information model 703 [RFC5102] no protocol extension would be required for transmitting 704 energy consumption information. Only a set of new information 705 elements would need to be registered at IANA. However, this memo 706 suggests that the definition of such information elements should be 707 conducted within the IETF and they should be documented in a 708 standards track RFC. 710 8. Acknowledgements 712 The authors would like to thank Ralf Wolter, for his first essay on 713 this draft. 715 9. Security Considerations 717 This memo currently does not impose any security considerations. 719 10. IANA Considerations 721 This memo has no actions for IANA.. 723 11. Informative References 725 [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268, 726 November 2005. 728 [RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", 729 RFC 3621, December 2003. 731 [RFC1628] Case, J., "UPS Management Information Base", RFC 1628, 732 May 1994. 734 [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor 735 Management Information Base", RFC 3433, December 2002. 737 [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", 738 RFC 4133, August 2005. 740 [RFC5101] Claise, B., "Specification of the IP Flow Information 741 Export (IPFIX) Protocol for the Exchange of IP Traffic 742 Flow Information", RFC 5101, January 2008. 744 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 745 Meyer, "Information Model for IP Flow Information Export", 746 RFC 5102, January 2008. 748 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 749 "Introduction and Applicability Statements for Internet- 750 Standard Management Framework", RFC 3410, December 2002. 752 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 754 [RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network 755 Management Protocol (SNMP) Notifications to SYSLOG 756 Messages", RFC 5675, October 2009. 758 [ACPI.R30b] 759 Hewlett-Packard Corporation, Intel Corporation, Microsoft 760 Corporation, Phoenix Corporation, and Toshiba Corporation, 761 "Advanced Configuration and Power Interface Specification, 762 Revision 3.0b", October 2006. 764 [DMTF.DSP1027] 765 Dasari (ed.), R., Davis (ed.), J., and J. Hilland (ed.), 766 "Power State Management Profile", September 2008. 768 Authors' Addresses 770 Juergen Quittek (editor) 771 NEC Europe Ltd. 772 NEC Laboratories Europe 773 Network Research Division 774 Kurfuersten-Anlage 36 775 Heidelberg 69115 776 DE 778 Phone: +49 6221 4342-115 779 Email: quittek@neclab.eu 781 Rolf Winter 782 NEC Europe Ltd. 783 NEC Laboratories Europe 784 Network Research Division 785 Kurfuersten-Anlage 36 786 Heidelberg 69115 787 DE 789 Phone: +49 6221 4342-121 790 Email: Rolf.Winter@neclab.eu 792 Thomas Dietz 793 NEC Europe Ltd. 794 NEC Laboratories Europe 795 Network Research Division 796 Kurfuersten-Anlage 36 797 Heidelberg 69115 798 DE 800 Phone: +49 6221 4342-128 801 Email: Thomas.Dietz@neclab.eu 802 Benoit Claise 803 Cisco Systems, Inc. 804 De Kleetlaan 6a b1 805 Degem 1831 806 BE 808 Phone: +32 2 704 5622 809 Email: bclaise@cisco.com 811 Mouli Chandramouli 812 Cisco Systems, Inc. 813 Sarjapur Outer Ring Road 814 Bangalore, 815 IN 817 Phone: +91 80 4426 3947 818 Email: moulchan@cisco.com