idnits 2.17.1 draft-nordman-eman-er-framework-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 21, 2013) is 3840 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-eman-framework-11 == Outdated reference: A later version (-11) exists of draft-ietf-eman-applicability-statement-04 == Outdated reference: A later version (-20) exists of draft-ietf-eman-battery-mib-09 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Nordman 3 Internet-Draft Lawrence Berkeley National Laboratory 4 Intended status: Informational October 21, 2013 5 Expires: April 24, 2014 7 Energy Reporting Framework 8 draft-nordman-eman-er-framework-02 10 Abstract 12 Managing energy consumption of devices presents new challenges and 13 issues. The EMAN Requirements draft identifies essential 14 capabilities needed to accomplish this. This draft describes how an 15 energy management system can use EMAN to gather and interpret data 16 from individual devices, and how some of the Requirements are 17 implemented in the model. This document focuses on Energy Reporting, 18 though acknowledges and fully includes the limited control functions 19 specified in the Requirements draft. Topics addressed in detail 20 include the topology of power distribution, reporting mechanisms, and 21 the various roles of devices, power interfaces, and components. 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 24, 2014. 40 Copyright Notice 42 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Guiding Principles . . . . . . . . . . . . . . . . . . . 4 59 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Energy Management System . . . . . . . . . . . . . . . . 4 61 2.2. Device . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.3. Power Interface . . . . . . . . . . . . . . . . . . . . . 5 63 2.4. Component . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.5. Energy Object . . . . . . . . . . . . . . . . . . . . . . 5 65 2.6. Battery . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3. Topologies . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.1. Power Distribution . . . . . . . . . . . . . . . . . . . 6 68 3.2. Reporting . . . . . . . . . . . . . . . . . . . . . . . . 9 69 4. Fulfilling Basic EMAN Requirements . . . . . . . . . . . . . 10 70 4.1. Identification . . . . . . . . . . . . . . . . . . . . . 10 71 4.2. Local Data . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.3. Power Interfaces . . . . . . . . . . . . . . . . . . . . 12 73 4.4. Power, Static . . . . . . . . . . . . . . . . . . . . . . 12 74 4.5. Power . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 4.6. Power State . . . . . . . . . . . . . . . . . . . . . . . 13 76 4.7. Energy . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 4.8. Control . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 4.9. Reporting . . . . . . . . . . . . . . . . . . . . . . . . 14 79 4.10. Data Summary . . . . . . . . . . . . . . . . . . . . . . 14 80 5. How the ER Framework Fulfills Advanced EMAN Requirements . . 15 81 5.1. Identification, Advanced . . . . . . . . . . . . . . . . 15 82 5.2. Power, Advanced . . . . . . . . . . . . . . . . . . . . . 16 83 5.3. Power State, Advanced . . . . . . . . . . . . . . . . . . 16 84 5.4. Energy, Advanced . . . . . . . . . . . . . . . . . . . . 17 85 5.5. Battery . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 5.6. Time-series Data . . . . . . . . . . . . . . . . . . . . 18 87 5.7. Reporting, Advanced . . . . . . . . . . . . . . . . . . . 18 88 5.8. Proxy Control . . . . . . . . . . . . . . . . . . . . . . 18 89 5.9. Security . . . . . . . . . . . . . . . . . . . . . . . . 19 90 6. EnMS Operation . . . . . . . . . . . . . . . . . . . . . . . 19 91 6.1. Incomplete data . . . . . . . . . . . . . . . . . . . . . 19 92 6.2. Separately Tracking Energy Flows by Direction . . . . . . 20 93 6.3. Aggregate Devices . . . . . . . . . . . . . . . . . . . . 20 94 6.4. Proxy Control . . . . . . . . . . . . . . . . . . . . . . 21 95 6.5. Cloud Devices . . . . . . . . . . . . . . . . . . . . . . 21 96 6.6. External Power Meters . . . . . . . . . . . . . . . . . . 21 98 7. EMAN Requirements Summary . . . . . . . . . . . . . . . . . . 21 99 8. Outstanding Issues . . . . . . . . . . . . . . . . . . . . . 25 100 8.1. How to Address Requirement 7.5 . . . . . . . . . . . . . 25 101 8.2. EMAN Framework Content . . . . . . . . . . . . . . . . . 26 102 8.3. Metering . . . . . . . . . . . . . . . . . . . . . . . . 26 103 8.4. PI Capability . . . . . . . . . . . . . . . . . . . . . . 26 104 8.5. Data Representation for Section 5.1 . . . . . . . . . . . 26 105 8.6. Move Requirement Satisfaction Details to Appendix . . . . 26 106 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 108 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 109 12. Informative References . . . . . . . . . . . . . . . . . . . 26 110 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 112 1. Introduction 114 Managing energy consumption of devices is different from typical 115 network management functions because of the special nature of energy 116 supply and use. The EMAN Requirements draft [RFC6988] identifies 117 necessary capabilities for an energy management standard. This 118 document describes how an energy management system (EnMS) uses EMAN 119 and how to use and interpret EMAN data. 121 In addition to the Requirements draft, this document derives content 122 and inspiration from several now-expired drafts: Considerations for 123 Power and Energy Management [I-D.norwin-energy-consider], Energy 124 Perspective on Applicability [I-D.nordman-eman-energy-perspective], 125 and most significantly, the Reference Model for Energy Management 126 [I-D.quittek-eman-reference-model]. The EMAN Applicability statement 127 [I-D.ietf-eman-applicability-statement] is also informative. 129 The current EMAN Framework draft [I-D.ietf-eman-framework] addresses 130 some of the requirements in ways suitable for this framework, 131 particularly for Advanced capabilities (see Section 5). Those 132 requirements are noted below. 134 The EMAN requirements are overwhelmingly about the reporting of 135 energy data, not about control. The only requirements that address 136 control are setting power state (directly and by a proxy) and cutting 137 power supply. Thus, while these are fully included in this 138 framework, it is titled "Energy Reporting" to match the empirical 139 facts about the content of the EMAN requirements. 141 1.1. Guiding Principles 143 This presentation, in form and content, takes simplicity as an 144 overarching goal. Complexity is burdensome for implementation of 145 EMAN capabilities in individual devices, burdensome for 146 implementation of management systems, and burdensome for readers and 147 users of this standard to understand what they need to to accomplish 148 their goals. 150 Energy management involves people of many backgrounds and so 151 documents about it should be accessible to a wide variety of 152 audiences, from network professionals, to energy professionals, to 153 building managers, or any person with an interest in energy use. 155 2. Concepts 157 At the core of this framework are just a few key concepts. Energy is 158 used by Devices. Devices have Power Interfaces, which are like 159 network interfaces, through which power is transferred into or out of 160 a device. Devices may have internal components with distinct power 161 consumption or other characteristics. Measurement for devices occurs 162 at interfaces so that the total or net consumption of a device can be 163 determined from these. EMAN data are transferred from a device to an 164 Energy Management System. 166 2.1. Energy Management System 168 An Energy Management System (EnMS) is an entity that receives EMAN 169 data from many devices and interprets it. An EnMS is often in the 170 same building as the devices being monitored. A building can have 171 zero, one, or many EnMS. A device can do both, acting as an EnMS and 172 reporting EMAN data to another EnMS. While the EMAN Requirements 173 draft does not identify requirements for an EnMS, it is necessary to 174 understand some of EnMS operation to fully describe how the EMAN 175 framework operates. 177 Basic EnMS operations include: discovering relevant devices, 178 acquiring static data about them, acquiring dynamic data about them 179 on a periodic basis, processing the resulting data, and implementing 180 control and/or reporting functions. 182 2.2. Device 184 A Device is most commonly a complete product. At any given time, a 185 device may be drawing electricity in, and may be sending electricity 186 out. Combining these results in the net energy consumed by a device. 188 For devices with a single power interface, there is an identity 189 between data about the interface and about the device as a whole, so 190 the two can share an identity within EMAN. The power interface 191 reports some data that a device does not (see Section 2.5) so that in 192 most cases both will be needed. 194 2.3. Power Interface 196 A Power Interface (PI) is an interface on a device through which 197 power can flow into a device (an inlet) or out of it (an outlet). 198 Some PIs change over time from being an inlet to being an outlet and 199 vice versa, however most PIs never change. Most devices have a 200 single inlet. Devices with multiple inlets often have them connected 201 to separate power distribution trees. Most devices have no outlets, 202 but those that do often have many. The only distinction between an 203 inlet and outlet is the sign of the power value: positive for an 204 inlet and negative for an outlet. A PI can indicate whether it is 205 capable of being only an inlet, only an outlet, or can switch between 206 the two. PIs are all contained (in ENTITY MIB sense) in the device; 207 a PI is never contained in a component, and a PI cannot contain 208 anything within it. A PI consumes no power itself. It is always on 209 the border of a device, never internal. 211 The flow of electricity within a building is determined by which 212 power interfaces are connected to each other - the wiring topology. 213 Thus, a key attribute of a PI is a list of the other interfaces it is 214 connected to. The power interface term is not new. It is used 215 similarly by the Power over Ethernet (PoE) standard [IEEE-802.3af] 216 and [IEEE-802.3at] where a power interface denotes the interface 217 between a device and the Ethernet transmission medium. 219 2.4. Component 221 A component is a distinct part of a device. Components lack some of 222 the features of devices, such as having power interfaces; instead, 223 they simply have a net total consumption from the pool of power 224 available within a device. A component can contain other components, 225 that draw from the pool of power within the containing component. 227 2.5. Energy Object 229 Devices, PIs, and Components are all Energy Objects (EOs). The term 230 "entity" in the Requirements draft generally corresponds to Energy 231 Object. The kinds of data available for an EO depends on its type as 232 shown in Figure 1. Basic data will be implemented by many or most 233 devices. Most devices are unlikely to implement advanced data. 235 The total energy and power for a device must match the total of all 236 of its PIs. PIs dump power into or take power out of the pool of 237 power in a device. A component draws power from the pool. 238 Components do not have power interfaces. The sum of all components 239 in a device may be less than total device consumption as there may be 240 hardware consuming power that is not part of any modeled component. 242 Device PI Component Kind 243 Basic 244 X X X Identification 245 X X X Local data 246 X Power Interfaces 247 X Power, static 248 X X X Power 249 X X X Power state 250 X X X Energy 251 X Reporting 252 Advanced 253 X X Identification, Advanced 254 X Power, Advanced 255 X Battery`````` 256 X X X Energy, Advanced 257 X X X Time-series data 258 X Reporting, advanced 259 X Proxy control 261 Figure 1: Kinds of EMAN data 263 2.6. Battery 265 A battery in a device is a special type of component. EMAN has 266 battery-specific data such as battery chemistry and charge state, see 267 [I-D.ietf-eman-battery-mib]. A device can report on a battery with 268 the battery-specific data, the component data, or both. 270 3. Topologies 272 EMAN covers several distinct topologies, particularly the 273 distribution of electricity and the communication of information. 274 The ability of EMAN to model power interfaces (PIs) of devices 275 enables flexible and powerful capabilities. This section describes 276 some of them. With this model an EnMS can query all devices in a 277 building for their EMAN data and combine what it receives from each 278 into a comprehensive picture of electricity flows and device state. 280 3.1. Power Distribution 281 An EnMS combines all the data it acquires to create as complete a 282 picture of power flows as possible; it is not necessary for each 283 device to have complete information about its connectivity. For 284 example, terminal devices that only consume power may only know the 285 identity of the PI from which they draw power. The EnMS then sees 286 many devices connected to a single outlet PI and can infer that they 287 are all wired to each other, regardless of whether the supplying PI 288 knows the identity of the devices it powers. Similarly, a supplying 289 device may know the identify of the PI it supplies power to and so 290 can create the map, even if the supplied device does not know where 291 it draws power from. 293 For each PI on a device, the group of PIs that are known to be 294 directly wired to that PI is reported. In Figure 2, Device-A can 295 report that its PI-1 is wired to PI-2, and Device-B can report that 296 PI-2 is wired to PI-1. The EnMS knows that PI-1 is part of Device-A 297 and that PI-2 is part of Device-B. Only one of the PIs needs to know 298 of the wiring connection for the EnMS to fully understand it. The 299 drawing shows how a PI is part of a device but is on its periphery. 300 The line shown is of power flow only. 302 +---------------+ +---------------+ 303 | +--------+ +--------+ | 304 | Device-A | PI-1 |>-------->| PI-2 | Device-B | 305 | +--------+ +--------+ | 306 +---------------+ +---------------+ 308 Figure 2: Simple wiring topology example 310 Figure 3 shows how wiring is commonly done in AC supply systems, with 311 Device A being a circuit breaker. In this case, four devices are 312 wired together. It is possible that all four know of the identity of 313 all others, but commonly less is known. PI-2, PI-3, and PI-4 may 314 each know they are wired to PI-1, and PI-1 may know nothing, but the 315 linkage of all four can be inferred by the EnMS. As another example, 316 PI-3 and PI-4 may know of the connection to PI-1, with PI-1 knowing 317 it is connected to PI-2; this also enables construction of the full 318 set. Finally, PI-1 could know it is connected to PI-2 and PI-3, but 319 have no knowledge of PI-4; however, it could observe that PI-2 and 320 PI-3 do not account for all the energy leaving PI-1 and so infer that 321 at least one other device is also wired to PI-1. 323 +--------+----------+ 324 ---->| PI-2 | Device-B | 325 +---------------+ | +--------+----------+ 326 | +--------+ | +--------+----------+ 327 | Device-A | PI-1 |>-------->| PI-3 | Device-C | 328 | +--------+ | +--------+----------+ 329 +---------------+ | +--------+----------+ 330 ---->| PI-4 | Device-D | 331 +--------+----------+ 333 Figure 3: Typical AC wiring topology example 335 Figure 4 shows how wiring is commonly done in DC supply systems, with 336 Device-A being a PoE switch, USB hub, or similar device. For 337 technologies which inherently have communication, device identity can 338 be readily determined. 340 +----------+--------+ +--------+----------+ 341 | | PI-1 |>-------->| PI-4 | Device-B | 342 | +--------+ +--------+----------+ 343 | +--------+ +--------+----------+ 344 | Device-A | PI-2 |>-------->| PI-5 | Device-C | 345 | +--------+ +--------+----------+ 346 | +--------+ +--------+----------+ 347 | | PI-3 |>-------->| PI-6 | Device-D | 348 +----------+--------+ +--------+----------+ 350 Figure 4: Typical DC wiring topology example 352 From the capability of each PI (or the direction of power flow on 353 first report) it is clear which PI is the source. For devices that 354 provide power (typically a power distribution unit, circuit breaker, 355 or PoE switch), one can determine which PIs are inlets and which are 356 outlets. Thus, mapping a traditional tree-structured power 357 distribution system is a simple process. 359 Some installations have more complex power distribution, as with more 360 than one device providing power to a circuit, or PIs that can and do 361 change the direction of power flow. These can be readily modeled 362 though require more sophisticated interpretation by the EnMS. 364 An EnMS may choose to put information it has inferred (principally 365 about PI connectivity) back into the individual devices, but is not 366 required to. Doing so is valuable when there is more than one EnMS 367 present. 369 With a power distribution map, a management system knows which 370 devices supply power to which other devices, so that the effect of 371 switching off a PI (usually at an outlet, but possibly at an inlet) 372 can be determined. The same applies to metering at PIs, which can 373 also occur at an outlet or inlet. 375 Power source control is accomplished by physically preventing power 376 from flowing, or re-enabling it. In contrast, power state control is 377 accomplished by communication protocols and not by power distribution 378 control so that power state control mechanisms and capabilities have 379 no required relation to power distribution systems. Power control 380 for a PI is modeled with power state, with on corresponding with 381 power able to flow, and off that power cannot flow. 383 3.2. Reporting 385 Only devices report data; PIs and components do not. An EMAN device 386 may report on itself, or on a device other than itself. Self- 387 reporting is the basic EMAN case and simply involves a device putting 388 its internal data into the EMAN representation. The EnMS knows the 389 identity of the device doing the reporting and the identity of the 390 device being reported on, and these are the same. The left side of 391 Figure 5 shows this. 393 +----------+ +----------+ 394 | EnMS | | EnMS | 395 +----------+ +----------+ 396 ^ ^ 397 | | 398 +----------+ +----------+ +----------+ 399 | Device-A | | Device-A |<-----| Device-B | 400 +----------+ +----------+ +----------+ 402 Figure 5: Two basic reporting scenarios 404 The other EMAN case is non-self-reporting, or other-reporting. The 405 EnMS knows the identity of the device reporting and the identify of 406 the device being reported on and can see that they are different. 407 There are three types of other-reporting relationships, where 408 Device-B is: 410 a) an IP device (like Device-A) that has the ability to report 411 EMAN data to an EnMS, 412 b) an IP device that does not have the ability to report EMAN data 413 to an EnMS, or 414 c) a non-IP device. 416 The right side of Figure 5 shows this where the Device-B to Device-A 417 communication technology depends on which case applies. 419 Case a) is particularly useful when some amount of collection and/or 420 summation is done. Summation can be across energy objects, and/or 421 across time for an individual energy object. The reporting device 422 may retain the detailed data in case it becomes of interest to an 423 EnMS later. 425 Case c) includes circumstances in which some or all of the EMAN data 426 are communicated over non-IP mechanisms, as well as when the EMAN 427 device monitors power flowing to the monitored device and may have 428 access to other information, such as the identity of the device it 429 provides power to. 431 Case b) is similar to c) except that the device reported on is an IP 432 device that is unable to report data in EMAN format. 434 Practically, the EnMS is indifferent to the distinction between these 435 cases or even whether the data is self-reported or other-reported; it 436 only matters what device is being reported on. 438 The lines shown in Figure 5 are data transfer, not power flow. For 439 the right side of Figure 5, Device-B could be powered by Device-A, or 440 have no power relation at all with Device-A (only a reporting 441 connection). How Device-A obtains the data about Device-B has no 442 effect on how the data are reported. 444 4. Fulfilling Basic EMAN Requirements 446 This section further elaborates the ER Framework and shows how its 447 features fulfill many of the requirements in the EMAN Requirements 448 draft. Each subsection includes the relevant requirements, 449 abbreviated (for the full list see Section 7). Requirement numbers 450 are noted in the text where the requirement is met. This section 451 only covers basic requirements that many devices will implement. 452 More advanced capabilities and requirements are covered in Section 5. 454 When implementing EMAN capability on a device, only the basic 455 identification data are required. All other data in Section 4 and 456 all data in Section 5 are optional to report. In a few cases, 457 features included that do not derive from specific requirements are 458 included, and these are always identified as such. 460 4.1. Identification 462 4.1. uniquely identifying entities. 464 Figure 6: EMAN Requirement for Identification 466 There are only two truly mandatory items for an energy object to 467 implement in EMAN. The first is a unique identity (UUID) (4.1). The 468 second is an energy object type which can be device, component, power 469 interface, or aggregate device (see Section 6.3). The EMAN Framework 470 specifies the UUID and includes an integer as an index for the energy 471 objects the device can report on. 473 In addition to the requirements, a widely useful feature for a device 474 is to report a URL for standard manufacturer data on the brand/model 475 of the device, represented as a string. Related to this, and also 476 not derivative of a requirement, is a string for each of the brand 477 (manufacturer) and model of the device. 479 4.2. Local Data 481 5.1.1. configure, retrieve and report a textual name or a description 482 5.1.2. retrieving and reporting context information ..., for example, 483 tags associated with an entity that indicate the entity's role. 484 5.1.3. retrieving and reporting the significance of entities within 485 its context, for example, how important the entity is. 486 5.1.4. retrieving and reporting Power priorities of entities. Power 487 priorities indicate an order in which Power States of entities 488 are changed. 489 5.1.5. grouping entities. This can be achieved in multiple ways, for 490 example, by providing means to tag entities, to assign them to 491 domains, or to assign device types to them. 493 Figure 7: EMAN Requirements for Local Data 495 Local data are those generated at the point of product use and so are 496 created for each building individually. The first item is a text 497 string for the name (5.1.1). The second is a list of keywords, each 498 of which will be a pair of strings, one representing a name or type 499 and the other one representing a value (5.1.2, .3, .4, .5). Since 500 none of these data types - role, priority, grouping, domain, or 501 device type - has been standardized, their representation and 502 encoding are determined locally. This flexible mechanism can be used 503 for various purposes, as the following examples illustrate using 504 different notation styles. 506 role="switch" 508 powerDownPriority: 6 510 "lineofbusiness:Helpdesk" 512 South Wing 514 domain::office 516 4.3. Power Interfaces 518 5.2.1. monitoring the list of Power Interfaces of a device. 519 5.2.2. monitoring the operational mode of a Power Interface which is 520 either "Power Inlet" or "Power Outlet". 521 5.2.3. identifying the Power Outlet that provides the Power received 522 at a Power Inlet. 523 5.2.4. identifying the list of Power Inlets that receive the Power 524 provided at a Power Outlet. 525 5.2.5. monitoring the availability of Power at each Power Interface. 526 ... indicates whether ... supply is switched on or off. 527 5.2.6. monitoring for each Power Interface if it is in actual use. 528 ... inlets ... device actually receives Power. ... outlets ... 529 Power is actually provided. 531 Figure 8: EMAN Requirements for Power Interfaces 533 PIs provide wiring topology and are the source of core energy and 534 power data. A device provides PI information as a list of UUIDs of 535 PIs it contains (5.2.1). Each PI provides a list of UUIDs of PIs 536 that it knows it is wired to (5.2.3, .4). The power mode of a PI is 537 indicated by the sign of the power value; positive for power flowing 538 in, and negative for power flowing out (5.2.2). The availability of 539 power at a PI is shown by its power state (see Section 4.6) (5.2.5). 540 Actual flow of power is indicated by the power value being non-zero 541 (5.2.6). 543 Since wiring topology usually changes only infrequently, it would be 544 burdensome for an EnMS to constantly refresh these data. To avoid 545 this, a device can provide a timestamp of the last time there was a 546 wiring topology change. Only when this changes does an EnMS need to 547 rescan the topology. This feature does not arise from a listed 548 requirement. 550 Another capability not specified by any requirement is what 551 directions of power flow a PI is capable of. This is indicated by an 552 enumeration value of either inlet-only, outlet-only, or both. 554 4.4. Power, Static 556 5.2.7. reporting the type of current (AC or DC) for each Power 557 Interface as well as for a device. 558 5.2.8. reporting the nominal voltage range for each Power Interface. 559 5.2.9. reporting the nominal AC frequency for each Power Interface. 560 5.2.10. reporting the number of AC phases for each Power Interface. 562 Figure 9: EMAN Requirements for Power, Static 564 These characteristics of power apply only to PIs and are static. 565 They do not change so can be set at the factory. They can be 566 represented by an enumeration (5.2.7), two strings (5.2.8, .9), and 567 an integers (5.2.10). 569 The requirements say that a device should also report its type of 570 current, but as some devices support both AC and DC simultaneously on 571 different PIs. There is not always a single type of current for a 572 whole device (as there is for a single PI). This is a shortcoming of 573 the requirements document, and the situation is covered by single PI 574 devices (see Section 2.2). 576 4.5. Power 578 5.3.1. reporting the real power for each Power Interface as well as 579 for an entity. ... includes ... the direction. 580 5.3.2. reporting the corresponding time or time interval for which a 581 Power value is reported. 583 Figure 10: EMAN Requirements for Power 585 Power is represented as an integer and a power-of-ten multiplier and 586 the direction of power is by its sign (5.3.1; see Section 4.3). Any 587 kind of energy object can report power level data. The time of a 588 power reading is indicated by a corresponding timestamp. 590 4.6. Power State 592 5.4.1. reporting the actual Power State of an entity. 594 Figure 11: EMAN Requirement for Power State 596 The EMAN Framework [I-D.ietf-eman-framework] describes how EMAN 597 supports devices to have any number of power state series, and at any 598 time, a state can be reported for each. This representation is 599 suitable. Each energy object has a list of power state series it 600 supports and a corresponding state for each entry in the list 601 (5.4.1). 603 For PIs, the state indicates whether or not power can flow: 'on' 604 means power can flow, 'off' that power unable to flow, and 'sleep' 605 that only trickle power is available. Technologies which support 606 trickle power include PoE, USB, and UPAMD. Since the IEEE 1621 power 607 state series has these three states and only these, it is a natural 608 one to use for PIs. 610 4.7. Energy 611 5.5.1. reporting measured values of Energy and the direction of the 612 Energy flow received or provided by an entity. ... report the 613 Energy passing through each Power Interface. 614 5.5.2. reporting the time interval for which an Energy value is 615 reported. 617 Figure 12: EMAN Requirements for Energy 619 Energy is reported as an accumulated meter reading and a timestamp 620 (5.5.1). An EnMS subtracts one reading/timestamp from a later one to 621 get an interval of time and the energy flow during that time (5.5.2). 622 The sign of this energy value indicates whether net energy was 623 brought into a device or component (a positive value) or sent out of 624 it (a negative one) (5.5.1). 626 4.8. Control 628 6.1. setting Power States of entities. 629 6.2. switching Power supply off or turning Power supply on at Power 630 Interfaces. 632 Figure 13: EMAN Requirements for Control 634 A device or component may accept a command to set the power state 635 value to attempt a changing of the power state (6.1). For a PI, this 636 turns supply on and off (6.2; see Section 4.6). No new data elements 637 are introduced by these requirements. 639 4.9. Reporting 641 7.1. an entity to report information on another entity. 642 7.2. reporting the identity of other entities on which information is 643 reported. ... For entities that report on one or more other 644 entities. 645 7.4. reporting the complete list of all those entities on which 646 Energy-related information can be reported. ... For entities that 647 report on one or more other entities. 649 Figure 14: EMAN Requirements for Reporting 651 Each device must be able to report the UUIDs of each device it can 652 report for, including itself (7.2). An EnMS can request data for any 653 listed device (7.1, .4). It can also request data for any PI or 654 component of any listed device. 656 4.10. Data Summary 657 The basic requirements above result in the following data elements 658 for a fully compliant implementatios. Note that a minimal 659 implementation would only require the first two data elements. In 660 the table below, the first column lists which type of energy objects 661 are relevant: device, PI, or component. The second column lists the 662 requirement level, mandatory, recommended, or optional. 664 EOs R Kind Data 665 --- - -------------- ----------------------------------------------- 666 DPC m Identification Index (within the device) 667 DPC m UUID (for unique identification globally) 668 D o URL for brand/model specifications 669 D C o Brand, model (strings) 670 DPC m Local Data Text name 671 DPC o Keyword list (strings) 672 D r Power Interf. List of PIs in device (UUIDs) 673 P r List of PIs known to be connected to PI (UUIDs) 674 P r Timestamp of last change to wiring topology 675 P m Power, Static Type of current (AC or DC) 676 P m Nominal voltage range, AC frequency, AC phases 677 DPC r Power Timestamp of power reading 678 DPC r Numeric value and exponent for power in W 679 DPC m Power State List of supported power state series 680 DPC m Current power state (for each supported series) 681 DPC m Energy Timestamp of energy reading 682 DPC m Numeric value and exponent for energy in Wh 683 D r Reporting List of devices that can be reported on (UUIDs) 685 Figure 15: Summary of Basic EMAN Data 687 A key point about the above table is that it is modest in size and 688 minimally burdensome for both implementers and those who use the EMAN 689 data in real buildings. 691 5. How the ER Framework Fulfills Advanced EMAN Requirements 693 This section describes how the ER Framework fulfills the rest of the 694 requirements in the EMAN Requirements draft. Each subsection begins 695 with the requirements listed, abbreviated, as from Section 7. Most 696 devices will not implement any of these, and many EnMS may not as 697 well. That said, for those devices and buildings where these are 698 relevant, these provide important capability. Many readers can skip 699 this section entirely. For most of these, content from the EMAN 700 Framework draft is suitable. 702 5.1. Identification, Advanced 703 4.2. indicating whether identifiers ... are persistent across a 704 re-start. 705 4.3. indicate any change of entity identifiers. 706 4.4. re-using entity identifiers from existing standards including 707 ... the Entity MIB module ... the LLDP MIB module ... the 708 LLDP-MED MIB module ... and the ... the Power Ethernet MIB. ... 709 Generic means for re-using other entity identifiers must be 710 provided. 712 Figure 16: EMAN Requirements for Identification, Advanced 714 These require a flag for identifier persistance (4.2), a timestamp of 715 the last entity identifier change (4.3), and a list of identifiers 716 each consisting of a pair of strings, one string representing a type 717 and the other one representing a value (4.4). 719 5.2. Power, Advanced 721 5.3.3. means to indicate the method how these values have been 722 obtained. 723 5.3.4. reporting the accuracy of reported Power and Energy values. 724 5.3.5. reporting the actual voltage and actual current for each Power 725 Interface as well as for a device. In case of AC Power supply ... 726 per phase. 727 5.3.6. creating notifications if Power values of an entity rise above 728 or fall below given thresholds. 729 5.3.7. reporting the complex power for each Power Interface and for 730 each phase at a Power Interface. 731 5.3.8. reporting the actual AC frequency for each Power Interface. 732 5.3.9. reporting the Total Harmonic Distortion (THD) of voltage and 733 current for each Power Interface. 734 5.3.10. reporting the impedance of Power supply for each Power 735 Interface. In case of AC Power supply ... per phase. 737 Figure 17: EMAN Requirements for Power, Advanced 739 The treatment of these requirements in the EMAN Framework draft is 740 suitable. Note that 5.3.3, .4, and .6 apply to any energy object, 741 but the rest only apply to PIs. 743 5.3. Power State, Advanced 745 5.4.2. retrieving the list of all potential Power States of an 746 entity. 747 5.4.3. supporting multiple Power State sets simultaneously at an 748 entity. 749 5.4.4. retrieving the list of all Power State sets supported by an 750 entity. 752 5.4.5. retrieving the list of all potential Power States of an entity 753 for each supported Power State set. 754 5.4.6. retrieving the typical Power for each supported Power State. 755 5.4.7. monitoring statistics per Power State including the total time 756 spent in a Power State, the number of times each state was 757 entered and the last time each state was entered. 758 5.4.8. generating a notification when the actual Power State of an 759 entity changes. 761 Figure 18: EMAN Requirements for Power State 763 The treatment of these requirements in the EMAN Framework draft is 764 suitable. 766 5.4. Energy, Advanced 768 5.5.3. reporting the received and provided Energy for each individual 769 Power State. 771 Figure 19: EMAN Requirement for Energy, Advanced 773 The treatment of these requirements in the EMAN Framework draft is 774 suitable, except for the notion of distinct values for consumed, 775 provided, and net consumption (see Section 6.2). 777 5.5. Battery 779 5.6.1. reporting the current charge ... in units of milliampere hours 780 5.6.2. reporting the charging state (charging, discharging, etc.) 781 5.6.3. reporting the number of completed charging cycles 782 5.6.4. reporting the actual capacity 783 5.6.5. reporting the actual temperature 784 5.6.6. reporting static properties ... including the nominal 785 capacity, the number of cells, the nominal voltage, and the ... 786 technology. 787 5.6.7. generating a notification when the charge ... decreases 788 below a given threshold. 789 5.6.8. generating a notification when the number of charging cycles 790 ... exceeds a given threshold. 791 5.6.9. meeting requirements 5.6.1 to 5.6.8 for each individual 792 battery contained in a single entity. 794 Figure 20: EMAN Requirements for Batteries 796 The treatment of these requirements in the Battery MIB draft 797 [I-D.ietf-eman-battery-mib] is suitable. 799 5.6. Time-series Data 801 5.7.1. reporting time series of Energy values. If ... comparison ... 802 between multiple entities ... is required, then time 803 synchronization ... must be provided. 804 5.7.2. supporting alternative interval types. Requirement 5.5.2 805 applies to every reported time value. 806 5.7.3. should ... reporting the number of values of a time series 807 that can be stored. 809 Figure 21: EMAN Requirements for Time-series data 811 Time-series data is of the same form as single-value data for power 812 and energy, notably a timestamp plus the relevant value. Thus, 813 reporting is of a list of these (5.7.1). Every interval type can be 814 derived from pairs of single-value data, by subtracting the time and 815 energy values (5.7.2). For sequential windows, adjacent values are 816 compared; for overlapping windows, non-adjacent values are compared. 817 The energy object must be able to report the number of available time 818 series data slots (5.7.3). A device must be able to accept a setting 819 of time from an EnMS for time syncronization (5.7.1), though for 820 security purposes, this might affect only EMAN reporting and not 821 change the global system clock of the device. To implement all this, 822 a device must be able to accept commands to initiate time-series data 823 collection, including the requested time interval. 825 5.7. Reporting, Advanced 827 7.3. reporting the list of all entities from which contributions are 828 included in an accumulated value. 829 7.5. indicating which Energy-related information can be reported for 830 which of those entities. ... For entities that report on one or 831 more other entities. 833 Figure 22: EMAN Requirements for Reporting, Advanced 835 This framework includes the concept of an aggregate device (7.3; see 836 Section 6.3). No new dta elements are required for this. The method 837 to implement 7.5 is TBD. 839 5.8. Proxy Control 841 8.1.1. an Energy Management System to send Power State control 842 commands to an entity that concern the Power States of [other] 843 entities. 844 8.1.2. reporting the identities of the entities for which the 845 reporting entity has means to control their Power States. 846 8.1.3. an entity to report the list of all entities for which it can 847 control the Power State. 848 8.1.4. an entity that receives commands controlling its Power State 849 from other entities to report the list of all those entities. 851 Figure 23: EMAN Requirements for Proxy Control 853 Only a device can control the power state of another entity, but any 854 energy object can be controlled this way. An energy object that can 855 be controlled by a proxy must be able to provide a list of 856 controllers (8.1.4). A device must be able to provide a list of 857 energy objects that it is capable to control the power state of 858 (8.1.2). 8.1.3 appears to be a duplicate of 8.1.2. To use this 859 feature, a device receives a power state set command for a UUID that 860 it is not itself. 862 5.9. Security 864 9.1. provide privacy, integrity, and authentication mechanisms for 865 all actions addressed in Sections 5 - 8. ... must meet the 866 security requirements elaborated in Section 1.4 of [RFC3411]. 867 9.2. allow for isolation of entities that that are not sufficiently 868 secure to operate on the public Internet. 870 Figure 24: EMAN Requirements for Security 872 The treatment of these requirements in the EMAN Framework draft is 873 suitable. 875 6. EnMS Operation 877 The full utility and application of EMAN can only be understood with 878 some understanding of how an EnMS operates. This section covers 879 several of these. This section does not introduce new data items. 881 6.1. Incomplete data 883 Section 3 noted that data on PI connectivity need not be complete to 884 be useful, and need not be complete on every device to be 885 comprehensive. The ability to report and use incomplete data is 886 generic in EMAN. This is particularly valuable for including the 887 many legacy devices with few or no EMAN capabilities. 889 Note that for the case in the right side of Figure 5, the data 890 available from Device-A and Device-B need not be the same. There may 891 be a different combination of PIs and components available on them, 892 and for each energy object, one of the devices may know and report 893 more data than the other. 895 Devices may lack power or energy detail for several PIs but still be 896 able to report data about the device total. 898 6.2. Separately Tracking Energy Flows by Direction 900 In some cases it may be desired to separately track the flows of 901 energy into or out of a device, PI, or component for those that 902 support bi-directional power flow. When the direction of power flow 903 changes within a reporting period, the opposite flows cancel each 904 other out, giving a correct indication of the net flow, but lacking 905 the tracking of the total in each direction. Doing this is readily 906 accomplished by having two PIs in place of one, or two components in 907 place of one. Each is used only for a single direction of power 908 flow. In this way, the separate directions are correctly tracked, 909 and by summation, the net flow can be calculated. Implementations 910 which desire this (batteries being a prime example) can do this, and 911 those that do not simply use a single PI or component. This ability 912 adds no data fields or complexity to the ER framework. 914 6.3. Aggregate Devices 916 An aggregate device is a not a real device, but an information 917 construct to represent the summation of data across a set of energy 918 objects. It has a UUID as any device does, has no power interfaces 919 (since it does not interact with power in the real world), and has 920 one or more components. Each component of an aggregate device can be 921 any type of energy object. Commonly, all objects in an aggregate 922 object will be of the same type (all devices, all PIs, or all 923 components) but this is not required. A device may or may not report 924 any data for the UUIDs in the aggregate object components; all that 925 is required is to have the component UUIDs. The aggregate device 926 concept introduces no new data items to the EMAN structure. 928 In producing an aggregate result, EMAN does not define how a 929 reporting device should treat incomplete data, any mismatch in the 930 alignment of timestamps among the objects to be aggregated, or 931 whether power states should be aggregated or how such an aggregation 932 would be interpreted. A device is free to do whatever it likes in 933 this regard. The only requirement is that power and energy reported 934 reflect a summation of all the constituent energy objects. Since 935 this is an aggregate device and not an aggregate PI, advanced power 936 data are not reported. 938 Common examples of aggregate objects might be all servers in a data 939 center rack, all fans in a data center, all devices in a single room, 940 all lights in a building, or all devices under the financial 941 responsibility of a single tenant. 943 6.4. Proxy Control 945 Control of the power state of one device by a second device is not 946 common, but does occur. A prime example is the ability to wake (or 947 turn on) a sleeping PC with the "Wake On LAN" technology. Another 948 example would be when the device being controlled is not an IP 949 device. 951 6.5. Cloud Devices 953 Another use of EMAN to accomplish real-world needs is through the use 954 of "cloud" devices. Like an aggregate device, these are not a single 955 real-world object (or not necessarily one), but do correspond to real 956 wiring topology. An example is a tree-structured wiring topology 957 with circuit breaker panels. An individual circuit breaker, or 958 collection of them, can be represented as a cloud device. The meter 959 device shows a PI on it wired to an inlet PI on the cloud device, and 960 individual end-use devices (or downstream circuit breakers) are wired 961 to an outlet PI on the cloud device. The cloud device has a UUID, 962 but is not a device on the network, and no data are reported from the 963 cloud device. Since no data are reported, there is no cloud device 964 of energy object. 966 What this does is correctly represent the data known about the wiring 967 topology, while hiding some potentially-existing (but unknown) 968 complexity inside the cloud. It adds no complexity to the EMAN model 969 and only adds the creation and use of a single UUID in PIs as 970 appropriate. It is flexible in allowing for a wire variety of 971 topologies of devices, clouds, and devices operating as meters. 973 6.6. External Power Meters 975 A device which is only a power meter is modeled exactly as any other 976 device. It is modeled as a device that has an inlet power interface 977 receiving power and one or more outlet power interfaces providing 978 power. The fact that a device may consume none of the energy that 979 passes through it is not relevant to EMAN, and in this case, the 980 quantitative values on both PIs will be identical except of opposite 981 sign. 983 A DC-powered blade server in a chassis has its own identity on the 984 network and if it reports for itself, it is a separate device, not a 985 component of the chassis. Similarly, a PoE-powered device can be 986 modeled as either a separate device, or a component of the powering 987 device. 989 7. EMAN Requirements Summary 990 This section summarizes the content of the EMAN Requirements 991 document, lists all specific requirements. The text is excerpted for 992 brevity, in one case text in [ brackets ] is added, and "..." 993 indicates text deleted within a requirement. The words "should" and 994 "must" occur in the introductory text; these are often redundant to 995 the actual requirements and so are not included in this list. 996 Requirements generally begin with "The standard must provide means 997 for ..."; this text is omitted. The headings below are not part of 998 the requirements draft. 1000 Requirements: Basic 1002 Identification 1003 4.1. uniquely identifying entities. 1005 Local Data 1006 5.1.1. configure, retrieve and report a textual name or a description 1007 5.1.2. retrieving and reporting context information ..., for example, 1008 tags associated with an entity that indicate the entity's role. 1009 5.1.3. retrieving and reporting the significance of entities within 1010 its context, for example, how important the entity is. 1011 5.1.4. retrieving and reporting Power priorities of entities. Power 1012 priorities indicate an order in which Power States of entities 1013 are changed. 1014 5.1.5. grouping entities. This can be achieved in multiple ways, for 1015 example, by providing means to tag entities, to assign them to 1016 domains, or to assign device types to them. 1018 Power Interfaces 1019 5.2.1. monitoring the list of Power Interfaces of a device. 1020 5.2.2. monitoring the operational mode of a Power Interface which is 1021 either "Power Inlet" or "Power Outlet". 1022 5.2.3. identifying the Power Outlet that provides the Power received 1023 at a Power Inlet. 1024 5.2.4. identifying the list of Power Inlets that receive the Power 1025 provided at a Power Outlet. 1026 5.2.5. monitoring the availability of Power at each Power Interface. 1027 ... indicates whether ... supply is switched on or off. 1028 5.2.6. monitoring for each Power Interface if it is in actual use. 1029 ... inlets ... device actually receives Power. ... outlets ... 1030 Power is actually provided. 1032 Power, Static 1033 5.2.7. reporting the type of current (AC or DC) for each Power 1034 Interface as well as for a device. 1035 5.2.8. reporting the nominal voltage range for each Power Interface. 1036 5.2.9. reporting the nominal AC frequency for each Power Interface. 1037 5.2.10. reporting the number of AC phases for each Power Interface. 1039 Power 1040 5.3.1. reporting the real power for each Power Interface as well as 1041 for an entity. ... includes ... the direction. 1042 5.3.2. reporting the corresponding time or time interval for which a 1043 Power value is reported. 1045 Power State 1046 5.4.1. reporting the actual Power State of an entity. 1048 Energy 1049 5.5.1. reporting measured values of Energy and the direction of the 1050 Energy flow received or provided by an entity. ... report the 1051 Energy passing through each Power Interface. 1052 5.5.2. reporting the time interval for which an Energy value is 1053 reported. 1055 Control 1056 6.1. setting Power States of entities. 1057 6.2. switching Power supply off or turning Power supply on at Power 1058 Interfaces. 1060 Reporting 1061 7.1. an entity to report information on another entity. 1062 7.2. reporting the identity of other entities on which information is 1063 reported. ... For entities that report on one or more other 1064 entities. 1065 7.4. reporting the complete list of all those entities on which 1066 Energy-related information can be reported. ... For entities that 1067 report on one or more other entities. 1069 Requirements: Advanced 1071 Identification, Advanced 1072 4.2. indicating whether identifiers ... are persistent across a 1073 re-start. 1074 4.3. indicate any change of entity identifiers. 1075 4.4. re-using entity identifiers from existing standards including 1076 ... the Entity MIB module ... the LLDP MIB module ... the 1077 LLDP-MED MIB module ... and the ... the Power Ethernet MIB. ... 1078 Generic means for re-using other entity identifiers must be 1079 provided. 1081 Power, Advanced 1082 5.3.3. means to indicate the method how these values have been 1083 obtained. 1084 5.3.4. reporting the accuracy of reported Power and Energy values. 1085 5.3.5. reporting the actual voltage and actual current for each Power 1086 Interface as well as for a device. In case of AC Power supply ... 1088 per phase. 1089 5.3.6. creating notifications if Power values of an entity rise above 1090 or fall below given thresholds. 1091 5.3.7. reporting the complex power for each Power Interface and for 1092 each phase at a Power Interface. 1093 5.3.8. reporting the actual AC frequency for each Power Interface. 1094 5.3.9. reporting the Total Harmonic Distortion (THD) of voltage and 1095 current for each Power Interface. 1096 5.3.10. reporting the impedance of Power supply for each Power 1097 Interface. In case of AC Power supply ... per phase. 1099 Power State 1100 5.4.2. retrieving the list of all potential Power States of an 1101 entity. 1102 5.4.3. supporting multiple Power State sets simultaneously at an 1103 entity. 1104 5.4.4. retrieving the list of all Power State sets supported by an 1105 entity. 1106 5.4.5. retrieving the list of all potential Power States of an entity 1107 for each supported Power State set. 1108 5.4.6. retrieving the typical Power for each supported Power State. 1109 5.4.7. monitoring statistics per Power State including the total time 1110 spent in a Power State, the number of times each state was 1111 entered and the last time each state was entered. 1112 5.4.8. generating a notification when the actual Power State of an 1113 entity changes. 1115 Energy, Advanced 1116 5.5.3. reporting the received and provided Energy for each individual 1117 Power State. 1119 Battery 1120 5.6.1. reporting the current charge ... in units of milliampere hours 1121 5.6.2. reporting the charging state (charging, discharging, etc.) 1122 5.6.3. reporting the number of completed charging cycles 1123 5.6.4. reporting the actual capacity 1124 5.6.5. reporting the actual temperature 1125 5.6.6. reporting static properties ... including the nominal 1126 capacity, the number of cells, the nominal voltage, and the ... 1127 technology. 1128 5.6.7. generating a notification when the charge ... decreases 1129 below a given threshold. 1130 5.6.8. generating a notification when the number of charging cycles 1131 ... exceeds a given threshold. 1132 5.6.9. meeting requirements 5.6.1 to 5.6.8 for each individual 1133 battery contained in a single entity. 1135 Time-series data 1136 5.7.1. reporting time series of Energy values. If ... comparison ... 1137 between multiple entities ... is required, then time 1138 synchronization ... must be provided. 1139 5.7.2. supporting alternative interval types. Requirement 5.5.2 1140 applies to every reported time value. 1141 5.7.3. should ... reporting the number of values of a time series 1142 that can be stored. 1144 Reporting 1145 7.3. reporting the list of all entities from which contributions are 1146 included in an accumulated value. 1147 7.5. indicating which Energy-related information can be reported for 1148 which of those entities. ... For entities that report on one or 1149 more other entities. 1151 Proxy Control 1152 8.1.1. an Energy Management System to send Power State control 1153 commands to an entity that concern the Power States of [other] 1154 entities. 1155 8.1.2. reporting the identities of the entities for which the 1156 reporting entity has means to control their Power States. 1157 8.1.3. an entity to report the list of all entities for which it can 1158 control the Power State. 1159 8.1.4. an entity that receives commands controlling its Power State 1160 from other entities to report the list of all those entities. 1162 Security 1163 9.1. provide privacy, integrity, and authentication mechanisms for 1164 all actions addressed in Sections 5 - 8. ... must meet the 1165 security requirements elaborated in Section 1.4 of [RFC3411]. 1166 9.2. allow for isolation of entities that that are not sufficiently 1167 secure to operate on the public Internet. 1169 8. Outstanding Issues 1171 The following are questions that need further consideration by the 1172 EMAN working group. 1174 8.1. How to Address Requirement 7.5 1176 "7.5. indicating which Energy-related information can be reported for 1177 which of those entities. ... For entities that report on one or more 1178 other entities." An EnMS could simply query all data for an energy 1179 object and observe what are available. A more efficient mechanism 1180 could be defined. Regardless, any value should have "unknown" as an 1181 option. 1183 8.2. EMAN Framework Content 1185 Incorporate details from the EMAN Framework draft and the Battery MIB 1186 draft where they are to be included substantially as-is. 1188 8.3. Metering 1190 Add text to section 3 explaining how measurement done at different 1191 power interfaces leads to conclusions about device metering. 1193 8.4. PI Capability 1195 Per Section 4.3, should there be a data element to indicate if a PI 1196 can be only an inlet, only an outlet, or either? 1198 8.5. Data Representation for Section 5.1 1200 Consider the syntax of the items to be represented and whether the 1201 proposal for a single text string is sufficient. Possibly provide 1202 examples. 1204 8.6. Move Requirement Satisfaction Details to Appendix 1206 Consider whether the details in sections 4 and 5 on how specific 1207 requirements are satisfied should be moved to an appendix. Sections 1208 4 and 5 would retain, and possibly expand, their explanation of the 1209 framework content itself. This would make the document more readable 1210 (and shorter, not counting the appendix) while retaining 1211 documentation of the relationships of framework content to 1212 requirements in the appendix. 1214 9. Security Considerations 1216 This memo currently does not impose any security considerations. 1218 10. IANA Considerations 1220 This memo has no actions for IANA. 1222 11. Acknowledgements 1224 This memo was inspired by discussions with many people, including 1225 (but not limited to) Juergen Quittek, Rolf Winter, Benoit Claise, 1226 John Parello, and Mouli Chandramouli. 1228 12. Informative References 1230 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1231 Architecture for Describing Simple Network Management 1232 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1233 December 2002. 1235 [RFC6988] Quittek, J., Chandramouli, M., Winter, R., Dietz, T., and 1236 B. Claise, "Requirements for Energy Management", RFC 6988, 1237 September 2013. 1239 [I-D.ietf-eman-framework] 1240 Parello, J., Claise, B., Schoening, B., and J. Quittek, 1241 "Energy Management Framework", draft-ietf-eman- 1242 framework-11 (work in progress), October 2013. 1244 [I-D.ietf-eman-applicability-statement] 1245 Schoening, B., Chandramouli, M., and B. Nordman, "Energy 1246 Management (EMAN) Applicability Statement", draft-ietf- 1247 eman-applicability-statement-04 (work in progress), 1248 October 2013. 1250 [I-D.ietf-eman-battery-mib] 1251 Quittek, J., Winter, R., and T. Dietz, "Definition of 1252 Managed Objects for Battery Monitoring", draft-ietf-eman- 1253 battery-mib-09 (work in progress), July 2013. 1255 [I-D.nordman-eman-energy-perspective] 1256 Nordman, B., "Energy perspective on applicability", draft- 1257 nordman-eman-energy-perspective-01 (work in progress), 1258 March 2011. 1260 [I-D.norwin-energy-consider] 1261 Nordman, B. and R. Winter, "Considerations for Power and 1262 Energy Management", draft-norwin-energy-consider-02 (work 1263 in progress), March 2011. 1265 [I-D.quittek-eman-reference-model] 1266 Quittek, J., Nordman, B., and R. Winter, "Reference Model 1267 for Energy Management", draft-quittek-eman-reference- 1268 model-03 (work in progress), October 2011. 1270 [IEEE-802.3af] 1271 IEEE 802.3 Working Group, ., "IEEE Std 802.3af-2003 - IEEE 1272 Standard for Information technology - Telecommunications 1273 and information exchange between systems - Local and 1274 metropolitan area networks - Specific requirements - Part 1275 3: Carrier Sense Multiple Access with Collision Detection 1276 (CSMA/CD) Access Method and Physical Layer Specifications 1277 - Amendment: Data Terminal Equipment (DTE) - Power via 1278 Media Dependent Interface (MDI)", July 2003. 1280 [IEEE-802.3at] 1281 IEEE 802.3 Working Group, ., "IEEE Std 802.3at-2009 - IEEE 1282 Standard for Information technology - Telecommunications 1283 and information exchange between systems - Local and 1284 metropolitan area networks - Specific requirements - Part 1285 3: Carrier Sense Multiple Access with Collision Detection 1286 (CSMA/CD) Access Method and Physical Layer Specifications 1287 - Amendment: Data Terminal Equipment (DTE) - Power via 1288 Media Dependent Interface (MDI) Enhancements", October 1289 2009. 1291 Author's Address 1293 Bruce Nordman 1294 Lawrence Berkeley National Laboratory 1295 1 Cyclotron Road 1296 Berkeley 94720 1297 US 1299 Phone: +1 510 486 7089 1300 Email: bnordman@lbl.gov