idnits 2.17.1 draft-ietf-eman-framework-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 37 has weird spacing: '...ccessed at ht...' == Line 800 has weird spacing: '...control mon...' == Line 887 has weird spacing: '...control mon...' -- The document date (March 12, 2012) is 4428 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4133 (Obsoleted by RFC 6933) -- Obsolete informational reference (is this intentional?): RFC 5101 (Obsoleted by RFC 7011) == Outdated reference: A later version (-14) exists of draft-ietf-eman-requirements-05 == Outdated reference: A later version (-17) exists of draft-ietf-eman-energy-aware-mib-04 == Outdated reference: A later version (-13) exists of draft-ietf-eman-energy-monitoring-mib-02 == Outdated reference: A later version (-20) exists of draft-ietf-eman-battery-mib-05 == Outdated reference: A later version (-11) exists of draft-ietf-eman-applicability-statement-00 == Outdated reference: A later version (-09) exists of draft-parello-eman-definitions-05 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Claise 3 Internet-Draft J. Parello 4 Intended Status: Informational Cisco Systems, Inc. 5 Expires: September 12, 2012 B. Schoening 6 Independent Consultant 7 J. Quittek 8 NEC Europe Ltd. 9 B. Nordman 10 Lawrence Berkeley 11 National Laboratory 12 March 12, 2012 14 Energy Management Framework 15 draft-ietf-eman-framework-04 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full 20 conformance with the provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet 23 Engineering Task Force (IETF), its areas, and its working 24 groups. Note that other groups may also distribute working 25 documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of 28 six months and may be updated, replaced, or obsoleted by 29 other documents at any time. It is inappropriate to use 30 Internet-Drafts as reference material or to cite them other 31 than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be 37 accessed at http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on September, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as 44 the document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's 47 Legal Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the 49 date of publication of this document. Please review these 50 documents carefully, as they describe your rights and 51 restrictions with respect to this document. Code 52 Components extracted from this document must include 53 Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 Abstract 59 This document defines a framework for providing Energy 60 Management for devices within or connected to communication 61 networks, and components thereof. The framework defines an 62 Energy Management Domain as a set of Energy Objects, for 63 which each Energy Object is identified, classified and 64 given context. Energy Objects can be monitored and/or 65 controlled with respect to Power, Power State, Energy, 66 Demand, Power Quality, and battery. Additionally the 67 framework models relationships and capabilities between 68 Energy Objects. 70 Table of Contents 72 1. Introduction............................................5 73 1.1. Energy Management Document Overview................6 74 2. Terminology.............................................7 75 Energy Management.......................................8 76 Energy Management System (EnMS).........................8 77 ISO Energy Management System............................9 78 Energy..................................................9 79 Power..................................................10 80 Demand.................................................10 81 Power Quality..........................................10 82 Electrical Equipment...................................11 83 Non-Electrical Equipment (Mechanical Equipment)........11 84 Energy Object..........................................11 85 Electrical Energy Object...............................11 86 Non-Electrical Energy Object...........................11 87 Energy Monitoring......................................11 88 Energy Control.........................................12 89 Energy Management Domain...............................12 90 Energy Object Identification...........................12 91 Energy Object Context..................................13 92 Energy Object Relationship.............................13 93 Energy Object Parent...................................14 94 Energy Object Child....................................15 95 Power State............................................15 96 Power State Set........................................16 97 Nameplate Power........................................16 98 3. Requirements & Use Cases...............................16 99 4. Energy Management Issues...............................18 100 4.1. Power Supply......................................19 101 4.1.1 Identification of Power Supply and Powered 102 Devices.............................................20 103 4.1.2 Multiples Devices Supplied by a Single Power 104 Line................................................21 105 4.1.3 Multiple Power Supply for a Single Powered 106 Device..............................................22 107 4.1.4 Bidirectional Power Interfaces................23 108 4.1.5 Relevance of Power Supply Issues..............23 109 4.1.6 Remote Power Supply Control...................24 110 4.2. Power and Energy Measurement......................24 111 4.2.1 Local Estimates...............................24 112 4.2.2 Management System Estimates...................25 113 4.3. Reporting Sleep and Off States....................25 114 4.4. Energy Device and Energy Device Components........25 115 4.5. Non-Electrical Equipment..........................26 116 5. Energy Management Reference Model......................26 117 5.1. Energy Object, Energy Object Components and 118 Containment Tree.......................................29 119 6. Framework High Level Concepts and Scope................30 120 6.1. Energy Object and Energy Management Domain........31 121 6.2. Power Interface...................................31 122 6.3. Energy Object Identification and Context..........32 123 6.2.1 Energy Object Identification..................32 124 6.2.2 Context in General............................32 125 6.2.3 Context: Importance...........................32 126 6.2.4 Context: Keywords.............................33 127 6.2.5 Context: Role.................................34 128 6.4. Energy Object Relationships.......................34 129 6.4.1 Energy Object Children Discovery..............36 130 6.4.2 Energy Object Relationship Conventions and 131 Guidelines..........................................37 132 6.5. Energy Monitoring.................................37 133 6.5.1 Power Measurement.............................38 134 6.6. Energy Control....................................40 135 6.5.1 IEEE1621 Power State Series...................41 136 6.5.2 DMTF Power State Series.......................41 137 6.5.3 EMAN Power State Set..........................42 138 6.7. Energy Objects Relationship Extensions............45 139 7. Structure of the Information Model: UML 140 Representation............................................45 141 8. Configuration..........................................50 142 9. Fault Management.......................................51 143 10. Examples..............................................52 144 11. Relationship with Other Standards Development 145 Organizations.............................................55 146 11.1. Information Modeling.............................55 147 12. Security Considerations...............................56 148 12.1. Security Considerations for SNMP....................56 149 13. IANA Considerations...................................57 150 14. Acknowledgments.......................................57 151 15. References............................................57 152 Normative References...................................57 153 Informative References.................................58 155 TO DO/OPEN ISSUE 156 - Add figures to the section 10 examples 157 - The figure 5 and 6 from the framework must be updated 158 with the notion of power interfaces 159 - Aggregation Relationship is different compared to the 160 other Relationships. There are some use cases: a building 161 mediator implementing the MIB, with some subtended 162 devices, a meter for many devices, etc... However, this 163 is also a generic function. We could argue that an 164 aggregation function is something that is not particular 165 to the EMAN context. 166 - Since we speak about Power Interface now, we need to 167 double the EO Relationships here and in [EMAN-AWARE-MIB]: 168 Example: poweredBy versus providingPower. 169 - Energy Interface or Power Interface, which term is best? 170 - The UML must be aligned with the latest [EMAN-AWARE-MIB] 171 and [EMAN-AWARE-MIB] document versions. 172 - JOHN: Does the multiple URIs requirement apply to all of 173 the defined relationship fields? For example, can 174 eoProxyBy have multiple URIs? What about the other 175 relationships? Answer: yes, but need to be explained 176 - Needs scrub for terminology and new "provide and receive 177 energy" consensus. Power and energy also incorrectly used 178 interchangeably from merged text. 179 - Some reference in the terminology section will certainly 180 have to be removed. 181 - Complete the section "Energy Object Relationship 182 Guidelines and Conventions" 184 1. Introduction 186 Network management is divided into the five main areas 187 defined in the ISO Telecommunications Management Network 188 model: Fault, Configuration, Accounting, Performance, and 189 Security Management (FCAPS) [X.700]. Absent from this 190 management model is any consideration of Energy Management, 191 which is now becoming a critical area of concern worldwide 192 as seen in [ISO50001]. 194 Note that Energy Management has particular challenges in 195 that a power distribution network is responsible for the 196 supply of energy to various devices and components, while a 197 separate communication network is typically used to monitor 198 and control the power distribution network. 200 This document defines a framework for providing Energy 201 Management for devices within or connected to communication 202 networks. The framework describes how to identify, 203 classify and provide context for a device in a 204 communications network from the point of view of Energy 205 Management. 207 The identified device (Energy Device) or identified 208 components within a device (Energy Device Component) can 209 then be monitored for Energy Management by obtaining 210 measurements for Power, Energy, Demand and Power Quality. 211 If a device contains batteries, they can be also be 212 monitored and managed. An Energy Object state can be 213 monitored or controlled by providing an interface expressed 214 as one or more Power State Sets. The most basic example of 215 Energy Management is a single Energy Object reporting 216 information about itself. However, in many cases, energy 217 is not measured by the Energy Object itself, but by a meter 218 located upstream in the power distribution tree. An 219 example is a power distribution unit (PDU) that measures 220 energy received by attached devices and may report this to 221 an Energy Management System (EnMS). Therefore, Energy 222 Objects are recognized as having relationships to other 223 devices in the network from the point of view of Energy 224 Management. These relationships include Aggregation 225 Relationship, Metering Relationship, Power Source 226 Relationship, and Proxy Relationship. 228 1.1. Energy Management Document Overview 230 The EMAN standard provides a set of specifications for 231 Energy Management. This document specifies the framework, 232 per the Energy Management requirements specified in [EMAN- 233 REQ]. 235 The applicability statement document [EMAN-AS] provides a 236 list of use cases, a cross-reference between existing 237 standards and the EMAN standard, and shows how this 238 framework relates to other frameworks. 240 The Energy-aware Networks and Devices MIB [EMAN-AWARE-MIB] 241 specifies objects for addressing Energy Object 242 Identification, classification, context information, and 243 relationships from the point of view of Energy Management. 245 The Power and Energy Monitoring MIB [EMAN-MON-MIB] contains 246 objects for monitoring of Power, Energy, Demand, Power 247 Quality and Power States. 249 Further, the battery monitoring MIB [EMAN-BATTERY-MIB] 250 defines managed objects that provide information on the 251 status of batteries in managed devices. 253 2. Terminology 255 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 256 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 257 and "OPTIONAL" in this document are to be interpreted as 258 described in RFC 2119 [RFC2119]. 260 EDITOR'S NOTE: 261 - All terms are copied over from the version 262 5 of the [EMAN-TERMINOLOGY] draft. The only 263 differences in definition are 264 o Dependency Relationship is removed 265 o Energy Object Relationship improved to 266 remove the Dependency Relationship 267 o "Reference: herein" has not been copied 268 over from the terminology draft. 269 - "All" terms have been copied. Potentially, 270 some unused terms might have to be removed. 271 Alternatively, as this document is the first 272 standard track document in the EMAN WG, it 273 may become the reference document for the 274 terminology (instead of cutting/pasting the 275 terminology in all drafts) 276 - RFC-EDITOR: the Relationships need to be 277 updated. 278 - The Power Interface definition has been 279 added 281 Energy Device 283 An Energy Device is an Energy Object that may be 284 monolithic or contain Energy Device Components 286 Energy Device Component 288 An Energy Device Component is an Energy Object 289 contained in an Energy Device, for which the containing 290 Energy Device provides individual energy management 291 functions. Typically, the Energy Device Component 292 is part the Energy Device physical containment tree 293 in the ENTITY-MIB [RFC4133]. 295 Energy Management 297 Energy Management is a set of functions for 298 measuring, modeling, planning, and optimizing 299 networks to ensure that the network elements 300 and attached devices use energy efficiently and 301 is appropriate for the nature of the 302 application and the cost constraints of the 303 organization. 304 Reference: Adapted from [ITU-T-M-3400] 305 Example: A set of computer systems that will 306 poll electrical meters and store the readings 307 NOTES: 308 1. Energy management refers to the activities, 309 methods, procedures and tools that pertain 310 to measuring, modeling, planning, 311 controlling and optimizing the use of energy 312 in networked systems [NMF]. 313 2. Energy Management is a management domain 314 which is congruent to any of FCAPS areas of 315 management in the ISO/OSI Network Management 316 Model [TMN]. Energy Management for 317 communication networks and attached devices 318 is a subset or part of an organization's 319 greater Energy Management Policies. 321 Energy Management System (EnMS) 323 An Energy Management System is a combination of 324 hardware and software used to administer a 325 network with the primary purpose being Energy 326 Management. 327 Reference: Adapted from [1037C] 328 Example: A single computer system that polls 329 data from devices using SNMP 330 NOTES: 331 1. An Energy Management System according to 332 [ISO50001] (ISO-EnMS) is a set of systems or 333 procedures upon which organizations can 334 develop and implement an energy policy, set 335 targets, action plans and take into account 336 legal requirements related to energy use. 338 An EnMS allows organizations to improve 339 energy performance and demonstrate 340 conformity to requirements, standards, 341 and/or legal requirements. 342 2. Example ISO-EnMS: Company A defines a set 343 of policies and procedures indicating there 344 should exist multiple computerized systems 345 that will poll energy from their meters and 346 pricing / source data from their local 347 utility. Company A specifies that their CFO 348 should collect information and summarize it 349 quarterly to be sent to an accounting firm 350 to produce carbon accounting reporting as 351 required by their local government. 352 3. For the purposes of EMAN, the definition 353 from [1037C] is the preferred meaning of an 354 Energy Management System (EnMS). The 355 definition from [ISO50001] can be referred 356 to as ISO Energy Management System (ISO- 357 EnMS). 359 ISO Energy Management System 361 Energy Management System as defined by 362 [ISO50001] 364 Energy 366 That which does work or is capable of doing 367 work. As used by electric utilities, it is 368 generally a reference to electrical energy and 369 is measured in kilo-watt hours (kWh). 370 Reference: [IEEE100] 371 NOTES 372 1. Energy is the capacity of a system to 373 produce external activity or perform work 374 [ISO50001] 376 Power 378 The time rate at which energy is emitted, 379 transferred, or received; usually expressed in 380 watts (or in joules per second). 381 Reference: [IEEE100] 383 Demand 385 The average value of power or a related 386 quantity over a specified interval of time. 387 Note: Demand is expressed in kilowatts, 388 kilovolt-amperes, kilovars, or other suitable 389 units. 391 Reference: [IEEE100] 392 NOTES: 393 1. typically kilowatts 394 2. Energy providers typically bill by Demand 395 measurements as well as for maximum Demand 396 per billing periods. Power values may spike 397 during short-terms by devices, but Demand 398 measurements recognize that maximum Demand 399 does not equal maximum Power during an 400 interval. 402 Power Quality 404 Characteristics of the electric current, 405 voltage and frequencies at a given point in an 406 electric power system, evaluated against a set 407 of reference technical parameters. These 408 parameters might, in some cases, relate to the 409 compatibility between electricity supplied in 410 an electric power system and the loads 411 connected to that electric power system. 412 Reference: [IEC60050] 414 Electrical Equipment 416 A general term including materials, fittings, 417 devices, appliances, fixtures, apparatus, 418 machines, etc., used as a part of, or in 419 connection with, an electric installation. 420 Reference: [IEEE100] 422 Non-Electrical Equipment (Mechanical Equipment) 424 A general term including materials, fittings, 425 devices appliances, fixtures, apparatus, 426 machines, etc., used as a part of, or in 427 connection with, non-electrical power 428 installations. 429 Reference: Adapted from [IEEE100] 431 Energy Object 433 An Energy Object (EO) is a piece of equipment 434 that is part of or attached to a 435 communications network that is monitored, 436 controlled, or aids in the management of 437 another device for Energy Management. 439 Electrical Energy Object 441 An Electrical Energy Object (EEO) is an Energy 442 Object that is a piece of Electrical Equipment 444 Non-Electrical Energy Object 446 A Non-Electrical Energy Object (NEEO) an 447 Energy Object that is a piece of Non- 448 Electrical Equipment. 450 Energy Monitoring 452 Energy Monitoring is a part of Energy 453 Management that deals with collecting or 454 reading information from Energy Objects to aid 455 in Energy Management. 457 NOTES: 458 1. This could include Energy, Power, Demand, 459 Power Quality, Context and/or Battery 460 information. 462 Energy Control 464 Energy Control is a part of Energy Management 465 that deals with directing influence over 466 Energy Objects. 468 NOTES: 469 1. Typically in order to optimize or ensure its 470 efficiency. 472 Energy Management Domain 474 An Energy Management Domain is a set of Energy Objects 475 where all objects in the domain are considered one unit 476 of management. 478 For example, power distribution units and all of the 479 attached Energy Objects are part of the same Energy 480 Management Domain. 482 For example, all EEO's drawing power from the 483 same distribution panel with the same AC 484 voltage within a building, or all EEO's in a 485 building for which there is one main meter, 486 would comprise an Energy Management Domain. 488 NOTES: 489 1. Typically, this set will have as members all 490 EO's that are powered from the same source. 492 Energy Object Identification 494 Energy Object Identification is a set of 495 attributes that enable an Energy Object to be: 496 uniquely identified among all Energy Management 497 Domains; linked to other systems; classified as 498 to type, model, and or manufacturer 500 Energy Object Context 502 Energy Object Context is a set of attributes 503 that allow an Energy Management System to 504 classify the use of the Energy Object within an 505 organization. 506 NOTES: 507 1. The classification could contain the use 508 and/or the ranking of the Energy Object as 509 compared to other Energy Objects in the 510 Energy Management Domain. 512 Energy Object Relationship 514 An Energy Object Relationship is a functional association 515 among Energy Objects 517 NOTES 518 1. Relationships can be named and could include 519 Aggregation, Metering, Power Source, Proxy and 520 Dependency. 521 2. The Energy Object is the noun or entity in the 522 relationship with the relationship described as the verb. 524 Example: If EO x is a piece of Electrical Equipment and 525 EO y is an electrical meter clamped onto x's power cord, 526 then x and y have a Metering Relationship. It follows 527 that y meters x and that x is metered by y. 528 Reference: Adapted from [CHEN] 530 Aggregation Relationship 532 An Aggregation Relationship is an Energy Object 533 Relationship where one Energy Object aggregates the 534 Energy Management information of one or more other Energy 535 Objects. These Energy Objects are referred to as having 536 an Aggregation Relationship. 538 NOTES: 539 Aggregate values may be obtained by reading values from 540 multiple Energy Objects and producing a single value of 541 more significant meaning such as average, count, maximum, 542 median, minimum, mode and most commonly sum [SQL]. 544 Metering Relationship 546 A Metering Relationship is an Energy Object Relationship 547 where one Energy Object measures the Power or Energy of 548 one or more other Energy Objects. These Energy Objects 549 are referred to as having a Metering Relationship. 551 Example: a PoE port on a switch measures the Power it 552 provides to the connected Energy Object. 554 Power Source Relationship 555 A Power Source Relationship is an Energy Object 556 Relationship where one Energy Object is the source of or 557 distributor of Power to one or more other Energy Objects. 558 These Energy Objects are referred to as having a Power 559 Source Relationship. 561 Example: a PDU provides power for a connected device. 563 Proxy Relationship 565 A Proxy Relationship is an Energy Object Relationship 566 where one Energy Object provides the Energy Management 567 capabilities on behalf of one or more other Energy 568 Objects. These Energy Objects are referred to as having a 569 Proxy Relationship. 571 Example: a protocol gateways device for Building 572 Management Systems (BMS) with subtended devices. 574 Energy Object Parent 576 An Energy Object Parent is an Energy Object 577 that participates in an Energy Object 578 Relationships and is considered as providing 579 the capabilities in the relationship. 581 Example: in a Metering Relationship, the 582 Energy Object that is metering is called the 583 Energy Object Parent, while the Energy Object 584 that is metered is called the Energy Object 585 Child. 587 Energy Object Child 589 An Energy Object Child is an Energy Object 590 that participates in an Energy Object 591 Relationships and is considered as receiving 592 the capabilities in the relationship. 594 Example: in a Metering Relationship, the 595 Energy Object that is metering is called the 596 Energy Object Parent, while the Energy Object 597 that is metered is called the Energy Object 598 Child. 600 Power Interface 602 A power interface is an Energy Object that serves as a 603 interconnection among Energy Objects, and participates in 604 a 605 Power Source Relationship. 607 Power State 609 A Power State is a condition or mode of a 610 device that broadly characterizes its 611 capabilities, power consumption, and 612 responsiveness to input. 614 Reference: Adapted from [IEEE1621] 616 NOTES: 618 1. A Power State can be seen as a power setting 619 of an Energy Object that influences the 620 power consumption, the available 621 functionality, and the responsiveness of the 622 Energy Object. 624 2. A Power State can be viewed as one method 625 for Energy Control 627 Power State Set 629 A collection of Power States that comprise one 630 named or logical grouping of control is a 631 Power State Set. 633 Example: The states {on, off, and sleep} as 634 defined in [IEEE1621], or the 16 power states 635 as defined by the [DMTF] can be considered two 636 different Power State Sets. 638 Nameplate Power 640 The Nameplate Power is the maximal (nominal) 641 Power that a device can support. 643 NOTES: 645 1. This is typically determined via load 646 testing and is specified by the manufacturer 647 as the maximum value required for operating 648 the device. This is sometimes referred to 649 as the worst-case Power. The actual or 650 average Power may be lower. The Nameplate 651 Power is typically used for provisioning and 652 capacity planning. 654 3. Requirements & Use Cases 656 Requirements for Power and Energy monitoring for networking 657 devices are specified in [EMAN-REQ]. The Energy Management 658 use cases covered by this framework are covered in the EMAN 659 applicability statement document in [EMAN-AS]. Typically 660 requirements and use cases for communication networks cover 661 the devices that make up the communication network and 662 endpoints. 664 With Energy Management, there exists a wide variety of 665 devices that may be contained in the same deployments as a 666 communication network but comprise a separate facility, 667 home, or power distribution network. 669 Target devices for Energy Management are all Energy Objects 670 that can directly or indirectly be monitored or controlled 671 by an Energy Management System (EnMS) using the Internet 672 protocol, for example: 673 - Simple electrical appliances / fixtures 674 - Hosts, such as a PC, a datacenter server, or a 675 printer 676 - Routers 677 - Switches 678 - A component within devices, such as a battery inside 679 a PC, a line card inside a switch, etc... 680 - Power over Ethernet (PoE) endpoints 681 - Power Distribution Units (PDU) 682 - Protocol gateway devices for Building Management 683 Systems (BMS) 684 - Electrical meters 685 - Sensor controllers with subtended sensors 687 There may also exist varying protocols deployed among these 688 power distributions and communication networks. 690 For an Energy Management framework to be useful, it should 691 also apply to these types of separate networks as they 692 connect and interact with a communications network. 694 This is the first version of the IETF Energy Management 695 framework. Though it already covers a wide range of use 696 cases, there are still a lot of potential ones that are not 697 covered, yet. A simple example is the limitation to 698 discrete power states without parameters. Some devices 699 have energy-related properties that not well described with 700 discrete power 701 states, for example a dimmer with a continuous power range 702 from 0%-100%. Other devices may have even more parameters 703 than just a single percentage value. 705 Also policy-controlled energy management functions at 706 Energy Devices are not covered. An example would be a 707 policy telling a Energy Device not to raise its power above 708 a given power value. These and further use cases would 709 need an extension of the framework described in this 710 document. It is up to future updates of this document to 711 select more of such use-cases and to cover them by 712 extensions or revisions of the present framework. 714 4. Energy Management Issues 716 This section explains special issues of Energy Management 717 particularly concerning power supply, Power and Energy 718 metering, and the reporting of low Power States. 720 To illustrate the issues we start with a simple and basic 721 scenario with a single powered device that receives Energy 722 and that reports energy-related information about itself to 723 an Energy Management System (EnMS), see Figure 1 725 +--------------------------+ 726 | Energy Management System | 727 +--------------------------+ 728 ^ ^ 729 monitoring | | control 730 v v 731 +-----------------+ 732 | powered device | 733 +-----------------+ 735 Figure 1: Basic energy management scenario 737 The powered device may have local energy control 738 mechanisms, for example putting itself into a sleep mode 739 when appropriate, and it may receive energy control 740 commands for similar purposes from the EnMS. Information 741 reported from a powered device to the EnMS includes at 742 least the Power State of the powered device (on, sleep, 743 off, etc.). 745 This and similar cases are well understood and likely to 746 become very common for Energy Management. They can be 747 handled with well established and standardized management 748 procedures. The only missing components today are 749 standardized information and data models for reporting and 750 configuration, such as, for example, energy-specific MIB 751 modules [RFC2578] and YANG modules [RFC6020]. 753 However, the nature of energy supply and use introduces 754 some issues that are special to Energy Management. The 755 following subsections address these issues and illustrate 756 them by extending the basic scenario in Figure 1. 758 4.1. Power Supply 760 A powered device may supply itself with power. Sensors, 761 for example, commonly have batteries or harvest Energy. 762 However, most powered devices that are managed by an EnMS 763 receive external power. 765 While a huge number of devices receive Power from unmanaged 766 supply systems, the number of manageable power supply 767 devices is increasing. 769 In datacenters, many Power Distribution Units (PDUs) allow 770 the EnMS to switch power individually for each socket and 771 also to measure the provided Power. Here there is a big 772 difference to many other network management tasks: In such 773 and similar cases, switching power supply for a powered 774 device or monitoring its power is not done by communicating 775 with the actual powered device, but with an external power 776 supply device (in this case, the PDU). Note that those 777 external power supply devices may be an external power 778 meter). 780 Consequently, a standard for Energy Management must not 781 just cover the powered devices that provide services for 782 users, but also the power supply devices (which are powered 783 devices as well) that monitor or control the power supply 784 for other powered devices. 786 A very simple device such as a plain light bulb can be 787 switched on or off only by switching its power supply. 788 More complex devices may have the ability to switch off 789 themselves or to bring themselves to states in which they 790 consume very little power. For these devices as well, it 791 is desirable to monitor and control their power supply. 793 This extends the basic scenario from Figure 1 by a power 794 supply device, see Figure 2. 796 +-----------------------------------------+ 797 | energy management system | 798 +-----------------------------------------+ 799 ^ ^ ^ ^ 800 monitoring | | control monitoring | | control 801 v v v v 802 +--------------+ +-----------------+ 803 | power supply |########| powered device | 804 +--------------+ +-----------------+ 805 ######## power supply line 807 Figure 2: Power Supply 809 The power supply device can be as simple as a plain power 810 switch. It may offer interfaces to the EnMS to monitor and 811 to control the status of its power outlets, as with PDUs 812 and Power over Ethernet (PoE) [IEEE-802.3at] switches. 814 The relationship between supply devices and the powered 815 devices they serve creates several problems for managing 816 power supply: 817 o Identification of corresponding devices 818 * A given powered device may be need to identify the 819 supplying power supply device. 820 * A given power supply device may need to identify 821 the 822 corresponding supplied powered device(s). 823 o Aggregation of monitoring and control for multiple 824 powered 825 devices 826 * A power supply device may supply multiple powered 827 devices with a single power supply line. 828 o Coordination of power control for devices with 829 multiple 830 power inlets 831 * A powered device may receive power via multiple 832 power 833 lines controlled by the same or different power 834 supply 835 devices. 837 4.1.1 Identification of Power Supply and Powered Devices 839 When a power supply device controls or monitors power 840 supply at one of its power outlets, the effect on other 841 devices is not always clear without knowledge about wiring 842 of power lines. The same holds for monitoring. The power 843 supplying device can report that a particular socket is 844 powered, and it may even be able to measure power and 845 conclude that there is a consumer drawing power at that 846 socket, but it may not know which powered device receives 847 the provided power. 849 In many cases it is obvious which other device is supplied 850 by a certain outlet, but this always requires additional 851 (reliable) information about power line wiring. Without 852 knowing which device(s) are powered via a certain outlet, 853 monitoring data are of limited value and the consequences 854 of switching power on or off may be hard to predict. 856 Even in well organized operations, powered devices' power 857 cords can be plugged into the wrong socket, or wiring plans 858 changed without updating the EnMS accordingly. 860 For reliable monitoring and control of power supply 861 devices, additional information is needed to identify the 862 device(s) that receive power provided at a particular 863 monitored and controlled socket. 865 This problem also occurs in the opposite direction. If 866 power supply control or monitoring for a certain device is 867 needed, then the supplying power supply device has to be 868 identified. 870 To conduct Energy Management tasks for both power supply 871 devices and other powered devices, sufficiently unique 872 identities are needed, and knowledge of their power supply 873 relationship is required. 875 4.1.2 Multiples Devices Supplied by a Single Power Line 877 The second fundamental problem is the aggregation of 878 monitoring and control that occurs when multiple powered 879 devices are supplied by a single power supply line. It is 880 often required that the EnMS has the full list of powered 881 devices connected to a single outlet as in Figure 3. 883 +---------------------------------------+ 884 | energy management system | 885 +---------------------------------------+ 886 ^ ^ ^ ^ 887 monitoring | | control monitoring | | control 888 v v v v 889 +--------+ +------------------+ 890 | power |########| powered device 1 | 891 | supply | # +------------------+-+ 892 +--------+ #######| powered device 2 | 893 # +------------------+-+ 894 #######| powered device 3 | 895 +------------------+ 897 Figure 3: Multiple Powered Devices Supplied 898 by Single Power Line 900 With this list, the single status value has clear meaning 901 and is the sum of all powered devices. Control functions 902 are limited by the fact that supply for the concerned 903 devices can only be switched on or off for all of them at 904 once. Individual control at the supply is not possible. 906 If the full list of devices powered by a single supply line 907 is not known by the controlling power supply device, then 908 control of power supply is problematic, because the 909 consequences of control actions can only be partially 910 known. 912 4.1.3 Multiple Power Supply for a Single Powered Device 914 The third problem arises from the fact that there are 915 devices with multiple power supplies. Some have this for 916 redundancy of power supply, some for just making internal 917 power converters (for example, from AC mains power to DC 918 internal power) redundant, and some because the capacity of 919 a single supply line is insufficient. 921 +----------------------------------------------+ 922 | energy management system | 923 +----------------------------------------------+ 924 ^ ^ ^ ^ ^ ^ 925 mon. | | ctrl. mon. | | ctrl. mon. | | 926 ctrl. 927 v v v v v v 928 +----------+ +----------+ +----------+ 929 | power |######| powered |######| power | 930 | supply 1 |######| device | | supply 2 | 931 +----------+ +----------+ +----------+ 933 Figure 4: Multiple Power Supply for Single Powered Device 935 The example in Figure 4 does not necessarily show a real 936 world scenario, but it shows the two cases to consider: 937 o multiple power supply lines between a single power 938 supply 939 device and a powered device 941 o different power supply devices supplying a single 942 powered 943 device 944 In any such case there may be a need to identify the 945 supplying power supply device individually for each power 946 inlet of a powered device. 948 Without this information, monitoring and control of power 949 supply for the powered device may be limited. 951 4.1.4 Bidirectional Power Interfaces 953 Low wattage DC systems may allow power to be delivered bi- 954 directionally. Energy stored in batteries on one device 955 can be delivered back to a power hub which redirects the 956 current to power another device. In this situation, the 957 interface can function as both an inlet and outlet. 959 The framework for Energy Management introduces the notion 960 of Power Interface, which can model a power inlet and a 961 power outlet, depending on the conditions. The Power 962 Interface reports power direction, as well as the energy 963 received, supplied and the net result. 965 4.1.5 Relevance of Power Supply Issues 967 In some scenarios, the problems with power supply do not 968 exist or can be sufficiently solved. With Power over 969 Ethernet (PoE) [IEEE-802.3at], there is always a one-to-one 970 relationship between a Power Sourcing Equipment (PSE) and a 971 Powered Device (PD). Also, the Ethernet link on the line 972 used for powering can be used to identify the two connected 973 devices. 975 For supply of AC mains power, the three problems described 976 above cannot be solved in general. There is no commonly 977 available protocol or automatic mechanism for identifying 978 endpoints of a power line. 980 And, AC power lines support supplying multiple powered 981 devices with a single line and commonly do. 983 4.1.6 Remote Power Supply Control 985 There are three ways for an energy management system to 986 change the Power State of an powered devices. First is for 987 the EnMS to provide policy or other useful information 988 (like the electricity price) to the powered device for it 989 to use in determining its Power State. The second is 990 sending the powered devices a command to switch to another 991 Power State. The third is to utilize an upstream device 992 (to the powered device) that has capabilities to switch on 993 and off power at its outlet. 995 Some Energy Objects do not have capabilities for receiving 996 commands or changing their Power States by themselves. 997 Such Energy Objects may be controlled by switching on and 998 off the power supply for them and so have particular need 999 for the third method. 1001 In Figure 4, the power supply can switch on and off power 1002 at its power outlet and thereby switch on and off power 1003 supply for the connected powered device. 1005 4.2. Power and Energy Measurement 1007 Some devices include hardware to directly measure their 1008 Power and Energy consumption. However, most common 1009 networked devices do not provide an interface that gives 1010 access to Energy and Power measurements. Hardware 1011 instrumentation for this kind of measurements is typically 1012 not in place and adding it incurs an additional cost. 1014 With the increasing cost of Energy and the growing 1015 importance of Energy Monitoring, it is expected that in 1016 future more devices will include instrumentation for power 1017 and energy measurements, but this may take quite some time. 1019 4.2.1 Local Estimates 1021 One solution to this problem is for the powered device to 1022 estimate its own Power and consumed Energy. For many 1023 Energy Management tasks, getting an estimate is much better 1024 than not getting any information at all. 1026 Estimates can be based on actual measured activity level of 1027 a device or it can just depend on the power state (on, 1028 sleep, off, etc.). 1030 The advantage of estimates is that they can be realized 1031 locally and with much lower cost than hardware 1032 instrumentation. Local estimates can be dealt with in 1033 traditional ways. They don't need an extension of the 1034 basic scenarios above. However, the powered device needs 1035 an energy model of itself to make estimates. 1037 4.2.2 Management System Estimates 1039 Another approach to the lack of instrumentation is 1040 estimation by the EnMS. The EnMS can estimate Power based 1041 on basic information on the powered device, such as the 1042 type of device, or also its brand/model and functional 1043 characteristics. 1045 Energy estimates can combine the typical power level by 1046 Power State with reported data about the Power State. 1048 If the EnMS has a detailed energy model of the device, it 1049 can produce better estimates including the actual power 1050 state and actual activity level of the device. Such 1051 information can be obtained by monitoring the device with 1052 conventional means of performance monitoring. 1054 4.3. Reporting Sleep and Off States 1056 Low power modes pose special challenges for energy 1057 reporting because they may preclude a device from listening 1058 to and responding to network requests. Devices may still 1059 be able to reliably track energy use in these modes, as 1060 power levels are usually static and internal clocks can 1061 track elapsed time in these modes. 1063 Some devices do have out-of-band or proxy abilities to 1064 respond to network requests in low-power modes. Others 1065 could use proxy abilities in an energy management protocol 1066 to improve this reporting, particularly if the powered 1067 device sends out notifications of power state changes. 1069 4.4. Energy Device and Energy Device Components 1071 While the primary focus of energy management is entire 1072 powered devices, i.e. Energy Devices, sometimes it is 1073 necessary or desirable to manage Energy Device Components 1074 such as line cards, fans, disks, etc. 1076 The concept of a Power Interface may not apply to Energy 1077 Device Components since they may receive Energy from a pool 1078 available from the encompassing device. For example, a DC- 1079 powered blade server in a chassis may have its own identity 1080 on the network and be managed as a single device but its 1081 energy may be received from a shared power source among all 1082 blades in the chassis. 1084 4.5. Non-Electrical Equipment 1086 The primary focus of this framework is for the management 1087 of Electrical Equipment. Some Non-Electrical Equipment may 1088 be connected to a communication networks and could have 1089 their energy managed if normalize to the electrical units 1090 for power and energy. 1092 Some examples of Non-Electrical Equipment that may be 1093 connected to a communication network are: 1094 1) A controller for compressed air. The controller is 1095 electrical only for its network connection. The 1096 controller is fueled by natural gas and produces 1097 compressed air. The energy transferred via compressed 1098 air is distributed to devices on a factory floor via a 1099 Power Interface: tools (drills, screwdrivers, assembly 1100 line conveyor belts). The energy measured is non- 1101 electrical (compressed air). 1102 EDITOR'S NOTE: Note that, in such as case, some might 1103 argue that the "energy interface" term might be more 1104 accurate than Power Interface. To be discussed. 1106 2) A controller for steam. The controller is electrical for 1107 its network attachment but it burns tallow and produces 1108 steam to subtended boilers. The energy is non-electrical 1109 (steam). 1111 5. Energy Management Reference Model 1113 The scope of this framework is to enable network and 1114 network-attached devices to be administered for Energy 1115 Management. The framework recognizes that in complex 1116 deployments Energy Objects may communicate over varying 1117 protocols. For example the communications network may use 1118 IP Protocols (SNMP) but attached Energy Object Parent may 1119 communicate to Energy Object Children over serial 1120 communication protocols like BACNET, MODBUS etc. The 1121 likelihood of getting these different topologies to convert 1122 to a single protocol is not very high considering the rate 1123 of upgrades of facilities and energy related devices. 1124 Therefore the framework must address the simple case of a 1125 uniform IP network and a more complex mixed 1126 topology/deployment. 1128 As displayed in Figure 5, the most basic energy management 1129 reference model is composed of an EnMS that obtains Energy 1130 Management information from Energy Objects. The Energy 1131 Object (EO) returns information for Energy Management 1132 directly to the EnMS. 1134 The protocol of choice for Energy Management is SNMP, as 1135 three MIBs are specified for Energy Management: the energy- 1136 aware MIB [EMAN-AWARE-MIB], the energy monitoring MIB 1137 [EMAN-MON-MIB], and the battery MIB [EMAN-BATTERY-MIB]. 1138 However, the EMAN requirement document [EMAN-REQ] also 1139 requires support for a push model distribution of time 1140 series values. The following diagrams mention IPFIX 1141 [RFC5101] as one possible solution for implementing a push 1142 mode transfer, however this is for illustration purposes 1143 only. The EMAN standard does not require the use of IPFIX 1144 and acknowledges that other alternative solutions may also 1145 be acceptable. 1147 +---------------+ 1148 | EnMS | - - 1149 +-----+---+-----+ ^ ^ 1150 | | | | 1151 | | |S |I 1152 +---------+ +----------+ |N |P 1153 | | |M |F 1154 | | |P |I 1155 +-----------------+ +--------+--------+ | |X 1156 | EO 1 | ... | EO N | v | 1157 +-----------------+ +-----------------+ - - 1159 Figure 5: Simple Energy Management 1161 As displayed in the Figure 5, a more complex energy 1162 reference model includes Energy Managed Object Parents and 1163 Children. The Energy Managed Object Parent returns 1164 information for themselves as well as information according 1165 to the Energy Managed Object Relationships. 1167 +---------------+ 1168 | EnMS | - - 1169 +-----+--+------+ ^ ^ 1170 | | | | 1171 | | |S |I 1172 +------------+ +--------+ |N |P 1173 | | |M |F 1174 | | |P |I 1175 +------------------+ +------+-----------+ | |X 1176 | EO | | EO | v | 1177 | Parent 1 | ... | Parent N | - - 1178 +------------------+ +------------------+ 1179 ||| . 1180 One or ||| . 1181 Multiple ||| . 1182 Energy ||| . 1183 Object ||| . 1184 Relationship(s): ||| 1185 - Aggregation ||| +-----------------------+ 1186 - Metering |||------| EO Child 1 | 1187 - Power Source || +-----------------------+ 1188 - Proxy || 1189 || +-----------------------+ 1190 ||-------| EO Child 2 | 1191 | +-----------------------+ 1192 | 1193 | 1194 |-------- ... 1195 | 1196 | 1197 | +-----------------------+ 1198 |--------| EO Child M | 1199 +-----------------------+ 1201 Figure 6: Complex Energy Management Model 1203 While both the simple and complex Energy Management models 1204 contain an EnMS, this framework doesn't impose any 1205 requirements regarding a topology with a centralized EnMS 1206 or one with distributed Energy Management via the Energy 1207 Objects within the deployment. 1209 Given the pattern in Figure 6, the complex relationships 1210 between Energy Objects can be modeled (refer also to 1211 section 5.3): 1213 - A PoE device modeled as an Energy Object Parent with 1214 the Power Source, Metering, and Proxy Relationships 1215 for one or more Energy Object Children 1216 - A PDU modeled as an Energy Object Parent with the 1217 Power Source and Metering Relationships for the 1218 plugged in Electrical Equipment (the Energy Object 1219 Children) 1220 - Building management gateway, used as proxy for non 1221 IP protocols, is modeled as an Energy Object Parent 1222 with the Proxy Relationship, and potentially the 1223 Aggregation Relationship to the managed Electrical 1224 Equipment 1225 - Etc. 1227 The communication between the Energy Object Parent and Energy 1228 Object Children is out of the scope of this framework. 1230 5.1. Energy Object, Energy Object Components and Containment 1231 Tree 1233 The framework for Energy Management manages two different 1234 types of Energy Objects: Energy Device and Energy Device 1235 Components. A typical example of anEnergy Device is a 1236 switch. However, a port within the switch, which provides 1237 Power to one end point, is also an Energy Object if it 1238 meters the power provided. A second example is PC, which 1239 is a typical Energy Device, while the battery inside the PC 1240 is a Energy Object Component, managed as an individual 1241 Energy Object. Some more examples of Energy Device 1242 Components: power supply within a router, an outlet within 1243 a smart PDU, etc... 1245 In the [EMAN-AWARE-MIB], each Energy Object is managed with 1246 an unique value of the entPhysicalIndex index from the 1247 ENTITY-MIB [RFC4133] 1249 The ENTITY-MIB [RFC4133] specifies the notion of physical 1250 containment tree, as: 1251 "Each physical component may be modeled as 'contained' 1252 within 1253 another physical component. A "containment-tree" is the 1254 conceptual sequence of entPhysicalIndex values that 1255 uniquely specifies the exact physical location of a 1256 physical component within the managed system. It is 1257 generated by 'following and recording' each 1258 'entPhysicalContainedIn' instance 'up the tree towards 1259 the root', until a value of zero indicating no further 1260 containment is found." 1262 A Energy Object Component in the Energy Management context 1263 is a special Energy Object that is a physical component as 1264 specified by the ENTITY-MIB physical containment tree. 1266 6. Framework High Level Concepts and Scope 1268 Energy Management can be organized into areas of concern 1269 that include: 1271 - Energy Object Identification and Context - for modeling 1272 and planning 1273 - Energy Monitoring - for energy measurements 1274 - Energy Control - for optimization 1275 - Energy Procurement - for optimization of resources 1277 While an EnMS may be a central point for corporate 1278 reporting, cost, environmental impact, and regulatory 1279 compliance, Energy Management in this framework excludes 1280 Energy procurement and the environmental impact of energy 1281 use. As such the framework does not include: 1282 - Manufacturing costs of an Energy Object in currency or 1283 environmental units 1284 - Embedded carbon or environmental equivalences of an 1285 Energy Object 1286 - Cost in currency or environmental impact to dismantle or 1287 recycle an Energy Object 1288 - Supply chain analysis of energy sources for Energy Object 1289 deployment 1290 - Conversion of the usage or production of energy to units 1291 expressed from the source of that energy (such as the 1292 greenhouse gas emissions associated with 1000kW from a 1293 diesel source). 1295 The next sections describe Energy Management organized into 1296 the following areas: 1298 - Energy Object and Energy Management Domain 1299 - Energy Object Identification and Context 1300 - Energy Object Relationships 1301 - Energy Monitoring 1302 - Energy Control 1303 - Deployment Topologies 1305 6.1. Energy Object and Energy Management Domain 1307 In building management, a meter refers to the meter 1308 provided by the utility used for billing and measuring 1309 power to an entire building or unit within a building. A 1310 sub-meter refers to a customer or user installed meter that 1311 is not used by the utility to bill but instead used to get 1312 readings from sub portions of a building. 1314 An Energy Management Domain should map 1:1 with a metered 1315 or sub-metered portion of the site. An Energy Object is 1316 part of a single Energy Management Domain. The Energy 1317 Management Domain MAY be configured on an Energy Object: 1318 the default value is a zero-length string. 1320 If all Energy Objects in the physical containment tree (see 1321 ENTITY-MIB) are part of the same Energy Management Domain, 1322 then it is safe to state that the Energy Object at the root 1323 of that containment tree is in that Energy Management 1324 Domain. 1326 An Energy Object Child may inherit the domain value from an 1327 Energy Object Parent or the Energy Management Domain may be 1328 configured directly in an Energy Object Child. 1330 6.2. Power Interface 1332 There are some similarities between Power Interfaces and 1333 network interfaces. A network interface can be used in 1334 different modes, such as sending or receiving on an 1335 attached line. The Power Interface can be receiving or 1336 providing power. 1338 Most Power Interfaces never change their mode, but as the 1339 mode is simply a recognition of the current direction of 1340 electricity flow, there is no barrier to a mode change. 1342 A power interface can have capabilities for metering power 1343 and other electric quantities at the shared power 1344 transmission medium. 1346 This capability is modeled by an association to a power 1347 meter. 1349 In analogy to MAC addresses of network interfaces, a 1350 globally 1351 unique identifier is assigned to each Power Interface. 1353 Physically, a Power Interface can be located at an AC power 1354 socket, an AC power cord attached to a device, an 8P8C 1355 (RJ45) PoE socket, etc. 1357 6.3. Energy Object Identification and Context 1359 6.2.1 Energy Object Identification 1361 Energy Objects MUST be associated with a value that 1362 uniquely identifies the Energy Object among all the Energy 1363 Management Domains within an EnMS. A Universal Unique 1364 Identifier (UUID) [RFC4122] MUST be used to uniquely 1365 identify an Energy Object. 1367 Every Energy Object SHOULD have a unique printable name 1368 within the Energy Management Domain. Possible naming 1369 conventions are: textual DNS name, MAC-address of the 1370 device, interface ifName, or a text string uniquely 1371 identifying the Energy Object. As an example, in the case 1372 of IP phones, the Energy Object name can be the device's 1373 DNS name. 1375 6.2.2 Context in General 1377 In order to aid in reporting and in differentiation between 1378 Energy Objects, each Energy Object optionally contains 1379 information establishing its business, site, or 1380 organizational context within a deployment, i.e. the Energy 1381 Object Context. 1383 6.2.3 Context: Importance 1385 An Energy Object can provide an importance value in the 1386 range of 1 to 100 to help rank a device's use or relative 1387 value to the site. The importance range is from 1 (least 1388 important) to 100 (most important). The default importance 1389 value is 1. 1391 For example: A typical office environment has several types 1392 of phones, which can be rated according to their business 1393 impact. A public desk phone has a lower importance (for 1394 example, 10) than a business-critical emergency phone (for 1395 example, 100). As another example: A company can consider 1396 that a PC and a phone for a customer-service engineer is 1397 more important than a PC and a phone for lobby use. 1399 Although EnMS and administrators can establish their own 1400 ranking, the following is a broad recommendation: 1402 . 90 to 100 Emergency response 1404 . 80 to 90 Executive or business-critical 1406 . 70 to 79 General or Average 1408 . 60 to 69 Staff or support 1410 . 40 to 59 Public or guest 1412 . 1 to 39 Decorative or hospitality 1414 6.2.4 Context: Keywords 1416 An Energy Object can provide a set of keywords. These 1417 keywords are a list of tags that can be used for grouping, 1418 summary reporting within or between Energy Management 1419 Domains, and for searching. All alphanumeric characters 1420 and symbols (other than a comma), such as #, (, $, !, and 1421 &, are allowed. Potential examples are: IT, lobby, 1422 HumanResources, Accounting, StoreRoom, CustomerSpace, 1423 router, phone, floor2, or SoftwareLab. There is no default 1424 value for a keyword. 1426 Multiple keywords can be assigned to a device. White 1427 spaces before and after the commas are excluded, as well as 1428 within a keyword itself. In such cases, the keywords are 1429 separated by commas and no spaces between keywords are 1430 allowed. For example, "HR,Bldg1,Private". 1432 6.2.5 Context: Role 1434 An Energy Object can provide a "role description" string 1435 that indicates the purpose the Energy Object serves in the 1436 EnMS. This could be a string describing the context the 1437 device fulfills in deployment. 1439 Administrators can define any naming scheme for the role of 1440 a device. As guidance a two-word role that combines the 1441 service the device provides along with type can be used 1442 [IPENERGY] 1444 Example types of devices: Router, Switch, Light, Phone, 1445 WorkStation, Server, Display, Kiosk, HVAC. 1447 Example Services by Line of Business: 1449 Line of Business Service 1451 Education Student, Faculty, Administration, 1452 Athletic 1454 Finance Trader, Teller, Fulfillment 1456 Manufacturing Assembly, Control, Shipping 1458 Retail Advertising, Cashier 1460 Support Helpdesk, Management 1462 Medical Patient, Administration, Billing 1464 Role as a two-word string: "Faculty Desktop", "Teller 1465 Phone", "Shipping HVAC", "Advertising Display", "Helpdesk 1466 Kiosk", "Administration Switch". 1468 6.4. Energy Object Relationships 1470 Two Energy Objects MAY establish an Energy Object 1471 Relationship. Within a relationship one Energy Object 1472 becomes an Energy Object Parent while the other becomes an 1473 Energy Object Child. 1475 The Power Source Relationship gives the view the wiring 1476 topology. For example: a data center server receiving 1477 power from two specific Power Interfaces from two different 1478 PDUs. 1480 The Metering Relationship gives the view of the metering 1481 topology. Standalone meters can be placed anywhere in a 1482 power distribution tree. For example, utility meters 1483 monitor and report accumulated power consumption of the 1484 entire building. Logically, the metering topology overlaps 1485 with the wiring topology, as meters are connected to the 1486 wiring topology. A typical example is meters that clamp 1487 onto the existing wiring. 1489 The Proxy Relationship allows software objects to be 1490 inserted into the wiring or metering topology to aid in 1491 managing (monitoring and/or control) the Energy Domain. 1493 From a EnMS management point of view, this implies that 1494 there is yet another management topology that EnMS will 1495 need to be aware of. 1497 In the ideal situation, the wiring, the metering, and the 1498 management topologies overlap. For Example: A Power-over- 1499 Ethernet (PoE) device (such as an IP phone or an access 1500 point) is attached to a switch port. The switch port is 1501 the source of power for the attached device, so the Energy 1502 Object Parent is the switch port, which acts as a Power 1503 Interface, and the Energy Object Child is the device 1504 attached to the switch. This Energy Object Parent (the 1505 switch) has three Energy Object Relations with this Energy 1506 Object Child (the remote Energy Object): Power Source 1507 Relationship, Metering Relationship, and Proxy 1508 Relationship. 1510 However, the three topologies (wiring, metering, and 1511 management) don't always overlap. For example, when a 1512 protocol gateways device for Building Management Systems 1513 (BMS) controls subtended devices, which themselves receive 1514 Power from PDUs or wall sockets. 1516 Note: The Aggregation Relationship is slightly different 1517 compared to the other relationships (Power Source, 1518 Metering, and Proxy Relationships) as this refers more to a 1519 management function. 1521 The communication between the parent and child for 1522 monitoring or collection of power data is left to the 1523 device manufacturer. For example: A parent switch may use 1524 LLDP to communicate with a connected child, and a parent 1525 lighting controller may use BACNET to communicate with 1526 child lighting devices. 1528 The Energy Object Child MUST keep track of its Energy 1529 Object Parent(s) along with the Energy Object Relationships 1530 type(s). The Energy Object Parent MUST keep track of its 1531 Energy Object Child(ren), along with the Energy Object 1532 Relationships type(s). 1534 6.4.1 Energy Object Children Discovery 1536 There are multiple ways that the Energy Object Parent can 1537 discover its Energy Object Children: : 1539 . In case of PoE, the Energy Object Parent automatically 1540 discovers an Energy Object Child when the Child 1541 requests power. 1542 . The Energy Object Parent and Children may run the Link 1543 Layer Discovery Protocol [LLDP], or any other 1544 discovery protocol, such as Cisco Discovery Protocol 1545 (CDP). The Energy Object Parent might even support 1546 the LLDP-MED MIB [LLDP-MED-MIB], which returns extra 1547 information on the Energy Object Children. 1548 . The Energy Object Parent may reside on a network 1549 connected to a facilities gateway. A typical example 1550 is a converged building gateway, monitoring several 1551 other devices in the building, and serving as a proxy 1552 between SNMP and a protocol such as BACNET. 1553 . A different protocol between the Energy Object Parent 1554 and the Energy Object Children. Note that the 1555 communication specifications between the Energy Object 1556 Parent and Children is out of the scope of this 1557 document. 1559 However, in some situations, it is not possible to discover 1560 the Energy Object Relationships, and they must be set 1561 manually. For example, in today' network, an administrator 1562 must assign the connected Energy Object to a specific PDU 1563 Power Interface, with no means of discovery other than that 1564 manual connection. 1566 When an Energy Object Parent is a Proxy, the Energy Object 1567 Parent SHOULD enumerate the capabilities it is providing 1568 for the Energy Object Child. The child would express that 1569 it wants its parent to proxy capabilities such as, energy 1570 reporting, power state configurations, non physical wake 1571 capabilities (such as WoL)), or any combination of 1572 capabilities. 1574 6.4.2 Energy Object Relationship Conventions and Guidelines 1576 EDITOR'S NOTE: this section needs to be completed 1578 This Energy Management framework doesn't impose too many 1579 "MUST" rules related to the Energy Object Relationships. 1580 Indeed, there are always corner cases that would be 1581 excluded with too strict specifications. However, this 1582 Energy Management framework proposes a series of 1583 guidelines, indicated with "SHOULD" and "MAY": 1584 - The Energy Device SHOULD NOT establish Power Source 1585 Relationship with Energy Device Component 1586 - Power Source Relationship SHOULD be established with next 1587 known Power Interface in the wiring topology. It may 1588 happen that the some Energy Objects in the wiring 1589 topology are not known to the administrator. Therefore, 1590 it may happen that a Power Source Relationship is 1591 established between two non connected Power Interfaces. 1592 - If an Energy Object A has a Power Source Relationship 1593 "Poweredby" with the Energy Object B, and if the Energy 1594 Object B has a Power Source Relationship "Poweredby" with 1595 the Energy Object C, then the Energy Object A SHOULD NOT 1596 have a Power Source Relationship "PoweredBby" the Energy 1597 Object C. 1599 6.5. Energy Monitoring 1601 For the purposes of this framework energy will be limited 1602 to electrical energy in watt hours. Other forms of Energy 1603 Objects that use or produce non-electrical energy may be 1604 part of an Energy Management Domain (See Section 4.5. ) 1605 but MUST provide information converted to and expressed in 1606 watt hours. 1608 Each Energy Object will have information that describes 1609 power information, along with how that measurement was 1610 obtained or derived (actual measurement, estimated, or 1611 presumed). For Energy Objects that can report actual power 1612 readings, an optional energy measurement can be provided. 1614 Optionally, an Energy Object can further describe the Power 1615 information with Power Quality information reflecting the 1616 electrical characteristics of the measurement. 1618 Optionally, an Energy Object that can report actual power 1619 readings can have odometers that provide the energy used, 1620 produced, and net energy in kWh. These values are 1621 odometers that accumulate the power readings. If energy 1622 values are returned then the three odometers must be 1623 provided along with a description of accuracy. 1625 Optionally, an Energy Object can provide demand information 1626 over time. 1628 6.5.1 Power Measurement 1630 A power measurement MUST be qualified with the units, 1631 magnitude, direction of power flow, and SHOULD be qualified 1632 by what means the measurement was made (ex: Root Mean 1633 Square versus Nameplate). 1635 In addition, the Energy Object should describe how it 1636 intends to measure power as one of consumer, producer or 1637 meter of usage. Given the intent, readings can be 1638 summarized or analyzed by an EnMS. For example metered 1639 usage reported by a meter and consumption usage reported by 1640 a device connected to that meter may naturally measure the 1641 same usage. With the two measurements identified by intent 1642 a proper summarization can be made by an EnMS. 1644 Power measurement magnitude should conform to the IEC 61850 1645 definition of unit multiplier for the SI (System 1646 International) units of measure. Measured values are 1647 represented in SI units obtained by BaseValue * (10 ^ 1648 Scale). For example, if current power usage of an Energy 1649 Object is 3, it could be 3 W, 3 mW, 3 KW, or 3 MW, 1650 depending on the value of the scaling factor. 3W implies 1651 that the BaseValue is 3 and Scale = 0, whereas 3mW implies 1652 BaseValue = 3 and ScaleFactor = -3. 1654 Energy is often billed in kilowatt-hours instead of 1655 megajoules from the SI units. Similarly, battery charge is 1656 often measured as miliamperes-hour (mAh) instead of 1657 coulombs from the SI units. The units used in this 1658 framework are: W, A, Wh, Ah, V. A conversion from Wh to 1659 Joule and from Ah to Coulombs is obviously possible, and 1660 can be described if required. 1662 In addition to knowing the usage and magnitude, it is 1663 useful to know how an Energy Object usage measurement was 1664 obtained: 1666 . Whether the measurements were made at the device itself 1667 or from a remote source. 1669 . Description of the method that was used to measure the 1670 power and whether this method can distinguish actual or 1671 estimated values. 1673 An EnMS can use this information to account for the 1674 accuracy and nature of the reading between different 1675 implementations. 1677 The EnMS can use the Nameplate Power for provisioning, 1678 capacity planning and potentially billing. 1680 6.5.2 Optional Power Quality 1682 Given a power measurement, it may in certain circumstances 1683 be desirable to know the Power Quality associated with that 1684 measurement. The information model must adhere to the IEC 1685 61850 7-2 standard for describing AC measurements. Note 1686 that the Power Quality includes two sets of 1687 characteristics: characteristics as received from the 1688 utility, and characteristics depending on how the power is 1689 used. 1691 In some Energy Management Domains, the power quality may 1692 not be needed, available, or relevant to the EnMS. 1694 Optional Demand 1696 It is well known in commercial electrical utility rates 1697 that demand is part of the calculation for billing. The 1698 highest peak demand measured over a time horizon, such as 1 1699 month or 1 year, is often the basis for charges. A single 1700 window of time of high usage can penalize the consumer with 1701 higher energy consumption charges. However, it is relevant 1702 to measure the demand only when there are actual power 1703 measurements from an Energy Object, and not when the power 1704 measurement is assumed or predicted. 1706 Optional Battery 1708 Some Energy Objects may use batteries for storing energy 1709 and for receiving power supply. These Energy Objects 1710 should report their current power supply (battery, power 1711 line, etc.) and the battery status for each contained 1712 battery. Battery-specific information to be reported 1713 should include the number of batteries contained in the 1714 device and per battery the state information as defined in 1715 [EMAN-REQ]. 1717 Beyond that a device containing a battery should be able to 1718 generate alarms when the battery charge falls below a given 1719 threshold and when the battery needs to be replaced. 1721 6.6. Energy Control 1723 Energy Objects can be controlled by setting it to a 1724 specific Power State. Power States Set can be seen as an 1725 interface by which an Energy Object can be controlled. 1726 Each Energy Object should indicate the Power State Sets 1727 that it implements. Well known Power State Sets should be 1728 registered with IANA 1730 When an individual Power State is configured from a 1731 specific Power State Set, an Energy Object may be busy at 1732 the request time. The Energy Object will set the desired 1733 state and then update the actual Power State when the 1734 priority task is finished. This mechanism implies two 1735 different Power State variables: actual versus desired 1737 There are several standards and implementations of Power 1738 State Sets. An Energy Object can support one or multiple 1739 Power State Set implementations concurrently. 1741 This framework identifies three initial possible Power 1742 State Series that can be supported by an Energy Object: 1744 IEEE1621 - [IEEE1621] 1746 DMTF - [DMTF] 1748 EMAN - Specified here 1750 6.5.1 IEEE1621 Power State Series 1752 The IEEE1621 Power State Series [IEEE1621] consists of 3 1753 rudimentary states : on, off or sleep. 1755 on(0) - The device is fully on and all features of 1756 the device are in working mode. 1758 off(1) - The device is mechanically switched off and 1759 does not consume energy. 1761 sleep(2) - The device is in a power saving mode, and 1762 some features may not be available immediately. 1764 6.5.2 DMTF Power State Series 1766 DMTF [DMTF] standards organization has defined a power 1767 profile standard based on the CIM (Common Information 1768 Model) model that consists of 15 power states ON (2), 1769 SleepLight (3), SleepDeep (4), Off-Hard (5), Off-Soft (6), 1770 Hibernate(7), PowerCycle Off-Soft (8), PowerCycle Off-Hard 1771 (9), MasterBus reset (10), Diagnostic Interrupt (11), Off- 1772 Soft-Graceful (12), Off-Hard Graceful (13), MasterBus reset 1773 Graceful (14), Power-Cycle Off-Soft Graceful (15), 1774 PowerCycle-Hard Graceful (16). DMTF standard is targeted 1775 for hosts and computers. Details of the semantics of each 1776 Power State within the DMTF Power State Series can be 1777 obtained from the DMTF Power State Management Profile 1778 specification [DMTF]. 1780 DMTF power profile extends ACPI power states. The 1781 following table provides a mapping between DMTF and ACPI 1782 Power State Series and EMAN Power State Sets (described in 1783 the next section): 1785 State DMTF Power ACPI EMAN 1786 Power 1787 State State State 1788 Name 1790 Non-operational states: 1792 1 Off-Hard G3, S5 1793 MechOff(1) 1794 2 Off-Soft G2, S5 1795 SoftOff(2) 1796 3 Hibernate G1, S4 1797 Hibernate(3) 1798 4 Sleep-Deep G1, S3 Sleep(4) 1799 5 Sleep-Light G1, S2 1800 Standby(5) 1801 6 Sleep-Light G1, S1 Ready(6) 1803 Operational states: 1804 7 On G0, S0, P5 1805 LowMinus(7) 1806 8 On G0, S0, P4 Low(8) 1807 9 On G0, S0, P3 1808 MediumMinus(9) 1809 10 On G0, S0, P2 1810 Medium(10) 1811 11 On G0, S0, P1 1812 HighMinus(11) 1813 12 On G0, S0, P0 High(12) 1815 Figure 7: DMTF / ACPI Power State Mapping 1817 6.5.3 EMAN Power State Set 1819 The EMAN Power State Set represents an attempt for a 1820 standard approach to model the different levels of power of 1821 a device. The EMAN Power States are an expansion of the 1822 basic Power States as defined in [IEEE1621] that also 1823 incorporates the Power States defined in [ACPI] and [DMTF]. 1824 Therefore, in addition to the non-operational states as 1825 defined in [ACPI] and [DMTF] standards, several 1826 intermediate operational states have been defined. 1828 There are twelve Power States, that expand on [IEEE1621] 1829 on, sleep and off. The expanded list of Power States are 1830 divided into six operational states, and six non- 1831 operational states. The lowest non-operational state is 1 1832 and the highest is 6. Each non-operational state 1833 corresponds to an [ACPI] Global and System states between 1834 G3 (hard-off) and G1 (sleeping). Each operational state 1835 represents a performance state, and may be mapped to [ACPI] 1836 states P0 (maximum performance power) through P5 (minimum 1837 performance and minimum power). 1839 In each of the non-operational states (from mechoff(1) to 1840 ready(6)), the Power State preceding it is expected to have 1841 a lower Power value and a longer delay in returning to an 1842 operational state: 1844 mechoff(1) : An off state where no Energy Object 1845 features are available. The Energy Object is unavailable. 1846 No energy is being consumed and the power connector can be 1847 removed. This corresponds to ACPI state G3. 1849 softoff(2) : Similar to mechoff(1), but some 1850 components remain powered or receive trace power so that 1851 the Energy Object can be awakened from its off state. In 1852 softoff(2), no context is saved and the device typically 1853 requires a complete boot when awakened. This corresponds 1854 to ACPI state G2. hibernate(3): No Energy Object 1855 features are available. The Energy Object may be awakened 1856 without requiring a complete boot, but the time for 1857 availability is longer than sleep(4). An example for state 1858 hibernate(3) is a save to-disk state where DRAM context is 1859 not maintained. Typically, energy consumption is zero or 1860 close to zero. This corresponds to state G1, S4 in ACPI. 1862 sleep(4) : No Energy Object features are 1863 available, except for out-of-band management, such as wake- 1864 up mechanisms. The time for availability is longer than 1865 standby(5). An example for state sleep(4) is a save-to-RAM 1866 state, where DRAM context is maintained. Typically, energy 1867 consumption is close to zero. This corresponds to state 1868 G1, S3 in ACPI. 1870 standby(5) : No Energy Object features are 1871 available, except for out-of-band management, such as wake- 1872 up mechanisms. This mode is analogous to cold-standy. The 1873 time for availability is longer than ready(6). For 1874 example, the processor context is not maintained. 1875 Typically, energy consumption is close to zero. This 1876 corresponds to state G1, S2 in ACPI. 1878 ready(6) : No Energy Object features are 1879 available, except for out-of-band management, such as wake- 1880 up mechanisms. This mode is analogous to hot-standby. The 1881 Energy Object can be quickly transitioned into an 1882 operational state. For example, processors are not 1883 executing, but processor context is maintained. This 1884 corresponds to state G1, S1 in ACPI. lowMinus(7) : 1885 Indicates some Energy Object features may not be available 1886 and the Energy Object has selected measures/options to 1887 provide less than low(8) usage. This corresponds to ACPI 1888 State G0. This includes operational states lowMinus(7) to 1889 full(12). 1891 low(8) : Indicates some features may not be 1892 available and the Energy Object has taken measures or 1893 selected options to provideless than mediumMinus(9) usage. 1895 mediumMinus(9): Indicates all Energy Object 1896 features are available but the Energy Object has taken 1897 measures or selected options to provide less than 1898 medium(10) usage. 1900 medium(10) : Indicates all Energy Object features 1901 are available but the Energy Object has taken measures or 1902 selected options to provide less than highMinus(11) usage. 1904 highMinus(11): Indicates all Energy Object 1905 features are available and power usage is less than 1906 high(12). 1908 high(12) : Indicates all Energy Object features 1909 are available and the Energy Object is consuming the 1910 highest power. 1912 The Figure 8 displays the mappings from the IEEE1621 Power 1913 State Series to the EMAN Power State Series, showing that 1914 the EMAN twelve Power States expand on [IEEE1621] on, sleep 1915 and off. 1917 IEEE1621 EMAN Power State Name 1919 Non-operational states: 1921 Power(off) MechOff(1) 1922 Power(off) SoftOff(2) 1923 Power(sleep) Hibernate(3) 1924 Power(sleep) Sleep(4) 1925 Power(sleep) Standby(5) 1926 Power(sleep) Ready(6) 1928 Operational states: 1929 Power(on) LowMinus(7) 1930 Power(on) Low(8) 1931 Power(on) MediumMinus(9) 1932 Power(on) Medium(10) 1933 Power(on) HighMinus(10) 1934 Power(on) High(11) 1935 Figure 8: DMTF / ACPI Power State Mapping 1937 6.7. Energy Objects Relationship Extensions 1939 This framework for Energy Management, is based on four 1940 Energy Objects Relationships: Aggregation Relationship, 1941 Metering Relationship, Power Source Relationship, and Proxy 1942 Relationship. 1944 This framework is defined with possible extension of new 1945 Energy Objects Relationships in mind. For example, a Power 1946 Distribution Unit (PDU) that allows physical entities like 1947 outlets to be "ganged" together as a logical entity for 1948 simplified management purposes, could be modeled with a 1949 future extension based on "gang relationship", whose 1950 semantic would specify the Energy Objects grouping. 1952 7. Structure of the Information Model: UML Representation 1954 The following basic UML represents an information model 1955 expression of the concepts in this framework. This 1956 information model, provided as a reference for 1957 implementers, is represented as a MIB in the different 1958 related IETF Energy Monitoring documents. However, other 1959 programming structure with different data models could be 1960 used as well. 1962 Notation is a shorthand UML with lowercase types considered 1963 platform or atomic types (i.e. int, string, collection). 1964 Uppercase types denote classes described further. 1965 Collections and cardinality are expressed via qualifier 1966 notation. Attributes labeled static are considered class 1967 variables and global to the class. Algorithms for class 1968 variable initialization, constructors or destructors are 1969 not shown 1971 EDITOR'S NOTE: the first part of the UML must be aligned 1972 with the latest [EMAN-AWARE-MIB] document version. Also, 1973 received the following comment referring to the arrows in 1974 the following figure: "It is not clear to me what UML 1975 relationships are being specified here in the ASCIIfied UML 1976 relationships. Please provide a legend to make your 1977 conventions for mapping to UML clear." 1979 EO RELATIONSHIPS AND CONTEXT 1980 +-------------------------- 1981 --+ 1982 | _Child Specific Info __ 1983 | 1984 |-------------------------- 1985 --| 1986 +---------------------------+ | parentId : UUID 1987 | 1988 | Context Information | | parentProxyAbilities 1989 | 1990 |---------------------------| | : bitmap 1991 | 1992 | roleDescription : string | | mgmtMacAddress : octets 1993 | 1994 | keywords[0..n] : string | | mgmtAddress : 1995 inetaddress | 1996 | importance : int | | mgmtAddressType : enum 1997 | 1998 | category : enum | | mgmtDNSName : 1999 inetaddress | 2000 +---------------------------+ +-------------------------- 2001 --+ 2002 | | 2003 | | 2004 | | 2005 v v 2006 +-----------------------------------------+ 2007 | Energy Object Information | 2008 |-----------------------------------------| 2009 | index : int | 2010 | energyObjectId | UUID | 2011 | name : string | 2012 | meterDomainName | string | 2013 | alternateKey | string | 2014 +-----------------------------------------+ 2015 ^ 2016 | 2017 | 2018 | 2019 +-------------------------+ 2020 | Links Object | 2021 |-------------------------| 2022 | physicalEntity : int | 2023 | ethPortIndex : int | 2024 | ethPortGrpIndex : int | 2025 | lldpPortNumber : int | 2026 +-------------------------+ 2028 EO AND MEASUREMENTS 2030 +-----------------------------------------------+ 2031 | Energy Object | 2032 |-----------------------------------------------| 2033 | nameplate : Measurement | 2034 | battery[0..n]: Battery | 2035 | measurements[0..n]: Measurement | 2036 | --------------------------------------------- | 2037 | Measurement instantaneousUsage() | 2038 | DemandMeasurement historicalUsage() | 2039 +-----------------------------------------------+ 2041 +-----------------------------------+ 2042 | Measurements | 2043 | __________________________________| 2044 +-----------------------------------+ 2045 ^ 2046 | 2047 | 2048 +------------------+----------------------------+ 2049 | PowerMeasurement | 2050 |-----------------------------------------------| 2051 | value : long | 2052 | rate : enum {0,millisecond,seconds, | 2053 | minutes,hours,...} | 2054 | multiplier : enum {-24..24} | 2055 | units : "watts" | 2056 | caliber : enum { actual, estimated, | 2057 | trusted, assumed...} | 2058 | accuracy : enum { 0..10000} | 2059 | current : enum {AC, DC} | 2060 | origin : enum { self, remote } | 2061 | time : timestamp | 2062 | quality : PowerQuality | 2063 +-----------------------------------------------+ 2064 | 2065 | 2066 +------------------+----------------------------+ 2067 | EnergyMeasurement | 2068 |-----------------------------------------------| 2069 | consumed : long | 2070 | generated : long | 2071 | net : long | 2072 | accuracy : enum { 0..10000} | 2073 +-----------------------------------------------+ 2075 +-----------------------------------------------+ 2076 | TimeMeasurement | 2077 |-----------------------------------------------| 2078 | startTime : timestamp | 2079 | usage : Measurement | 2080 | maxUsage : Measurement | 2081 +-----------------------------------------------+ 2082 | 2083 | 2084 +----------------------------------------+ 2085 | TimeInterval | 2086 |--------------------------------------- | 2087 |value : long | 2088 |units : enum { seconds, miliseconds..} | 2089 +----------------------------------------+ 2090 | 2091 | 2092 +----------------------------------------+ 2093 | DemandMeasurement | 2094 |----------------------------------------| 2095 |intervalLength : TimeInterval | 2096 |intervalNumbers: long | 2097 |intervalMode : enum { period, sliding, | 2098 |total } | 2099 |intervalWindow : TimeInterval | 2100 |sampleRate : TimeInterval | 2101 |status : enum {active, inactive } | 2102 |measurements : TimedMeasurement[] | 2103 +----------------------------------------+ 2105 QUALITY 2107 +----------------------------------------+ 2108 | PowerQuality | 2109 |----------------------------------------| 2110 | | 2111 +----------------------------------------+ 2112 ^ 2113 | 2114 | 2115 +------------------+--------------------+ 2116 | ACQuality | 2117 |---------------------------------------| 2118 | acConfiguration : enum {SNGL, DEL,WYE}| 2119 | avgVoltage : long | 2120 | avgCurrent : long | 2121 | frequency : long | 2122 | unitMultiplier : int | 2123 | accuracy : int | 2124 | totalActivePower : long | 2125 | totalReactivePower : long | 2126 | totalApparentPower : long | 2127 | totalPowerFactor : long | 2128 +---------+-----------------------------+ 2129 | 1 2130 | 2131 | 2132 | 2133 | +------------------------------------+ 2134 | | ACPhase | 2135 | * |------------------------------------| 2136 +--------+ phaseIndex : long | 2137 | avgCurrent : long | 2138 | activePower : long | 2139 | reactivePower : long | 2140 | apparentPower : long | 2141 | powerFactor : long | 2142 +------------------------------------+ 2143 ^ ^ 2144 | | 2145 | | 2146 | | 2147 | | 2148 +-------------------------------+---+ | 2149 | DelPhase | | 2150 |-----------------------------------| | 2151 |phaseToNextPhaseVoltage : long | | 2152 |thdVoltage : long | | 2153 |thdCurrent : long | | 2154 +-----------------------------------+ | 2155 | 2156 +------------------+-----------+ 2157 | WYEPhase | 2158 |------------------------------| 2159 |phaseToNeutralVoltage : long | 2160 |thdCurrent : long | 2161 |thdVoltage : long | 2162 +------------------------------+ 2164 EO & STATES 2166 +----------------------------------------------+ 2167 | Energy Object | 2168 |----------------------------------------------| 2169 | currentLevel : int | 2170 | configuredLevel : int | 2171 | configuredTime : timestamp | 2172 | reason: string | 2173 | emanLevels[0..11] : State | 2174 | levelMappings[0..n] : LevelMapping | 2175 +----------------------------------------------+ 2177 +-------------------------------+ 2178 | State | 2179 |-------------------------------| 2180 | name : string | 2181 | cardinality : int | 2182 | maxUsage : Measurement | 2183 +-------------------------------+ 2185 Figure 9: Information Model UML Representation 2187 8. Configuration 2189 This power management framework allows the configuration of 2190 the following key parameters: 2192 . Energy Object name: A unique printable name for the 2193 Energy Object. 2194 . Energy Object role: An administratively assigned name 2195 to indicate the purpose an Energy Object serves in the 2196 network. 2197 . Energy Object importance: A ranking of how important 2198 the Energy Object is, on a scale of 1 to 100, compared 2199 with other Energy Objects in the same Energy 2200 Management Domain. 2202 . Energy Object keywords: A list of keywords that can be 2203 used to group Energy Objects for reporting or 2204 searching. 2205 . Energy Management Domain: Specifies the name of an 2206 Energy Management Domain for the Energy Object. 2207 . Energy Object Power State: Specifies the current Power 2208 State for the Energy Object. 2209 . Demand parameters: For example, which interval length 2210 to report the Demand over, the number of intervals to 2211 keep, etc. 2212 . Assigning an Energy Object Parent to an Energy Object 2213 Child 2214 . Assigning an Energy Object Child to an Energy Object 2215 Parent. 2217 This framework supports multiple means for setting the 2218 Power State of a specific Energy Objects. However, the 2219 Energy Object might be busy executing an important task 2220 that requires the current Power State for some more time. 2221 For example, a PC might have to finish a backup first, or 2222 an IP phone might be busy with a current phone call. 2223 Therefore a second value contains the actual Power State. 2224 A difference in values between the two objects indicates 2225 that the Energy Object is currently in Power State 2226 transition. 2228 Other, already well established means for setting Power 2229 States, such as DASH [DASH], already exist. Such a 2230 protocol may be implemented between the Energy Object 2231 Parent and the Energy Object Child, when the Energy Object 2232 Parent acts as a Proxy. Note that the Wake-up-on-Lan (WoL) 2233 mechanism allows to transition a device out of the Off 2234 Power State. 2236 9. Fault Management 2238 [EMAN-REQ] specifies some requirements about Power States 2239 such as "the current state - the time of the last change", 2240 "the total time spent in each state", "the number of 2241 transitions to each state", etc. Such requirements are 2242 fulfilled via the pmPowerStateChange NOTIFICATION-TYPE 2243 [EMAN-MON-MIB]. This SNMP notification is generated when 2244 the value(s) of Power State has changed for the Energy 2245 Object. 2247 Regarding high and low thresholding mechanism, the RMON 2248 alarm and event [RFC2819] allows to periodically takes 2249 statistical samples from Energy Object variables, compares 2250 them to previously configured thresholds, and to generate 2251 an event (i.e. an SNMP notification) if the monitored 2252 variable crosses a threshold. The RMON alarm can monitor 2253 variables that resolve to an ASN.1 primitive type of 2254 INTEGER (INTEGER, Integer32, Counter32, Counter64, Gauge32, 2255 or TimeTicks), so basically most the variables in [EMAN- 2256 MON-MIB]. 2258 10. Examples 2260 In this section we will give examples of how to use the 2261 Energy Management framework. In each example we will show 2262 how it can be applied when Energy Devices have the 2263 capability to model Power Interfaces. We will also show in 2264 each example how the framework can be applied when devices 2265 cannot support Power Interfaces but only monitor 2266 information or control the Energy Device as a whole. For 2267 instance a PDU may only be able to measure power and energy 2268 for the entire unit without the ability to distinguish 2269 among the inlets or outlet. 2271 Together these examples show how the framework can be 2272 adapted for Energy Devices with different capabilities 2273 (typically hardware) for Energy Management. 2275 Given for all Examples: 2277 Energy Device W: A computer with one power supply. Power 2278 interface 1 is an inlets for Device W. 2280 Energy Device X: A computer with two power supplies. Power 2281 interface 1 and power interface 2 are both inlets for 2282 Device X. 2284 Energy Device Y: A PDU with multiple Power Interfaces 2285 numbered 0..10, Power interface 0 is an inlet and power 2286 interface 1..10 are outlets. 2288 Energy Device Z: A PDU with multiple Power Interfaces 2289 numbered 0..10, Power interface 0 is an inlet and power 2290 interface 1..10 are outlets. 2292 Example I: Simple Device with one Source 2294 Topology: 2295 Energy Device W inlet 1 is plugged into Device Y outlet 2296 8. 2298 With Power Interfaces: 2300 Device W has an Energy Object representing the computer 2301 itself as well as one Power Interface defined as an 2302 inlet. 2304 Device Y would have an Energy Object representing the PDU 2305 itself (the Energy Device) with a Power Interface 0 2306 defined as an inlet and Power Interfaces 1..10 defined as 2307 outlets. 2309 The interfaces of the devices would have a Power Source 2310 Relationship such that: 2311 Device W inlet 1 is powered by Device Y outlet 8 2313 Without Power Interfaces: 2315 In this case Device W has an Energy Object representing 2316 the computer. Device Y would have an Energy Object 2317 representing the PDU. 2319 The devices would have a Power Source Relationship such 2320 that: 2321 Device W is powered by Device Y. 2323 Example II: Multiple Inlets 2325 Topology: 2326 Energy Device X inlet 1 is plugged into Device Y outlet 2327 8. 2328 Energy Device X inlet 2 is plugged into Device Y outlet 2329 9. 2331 With Power Interfaces: 2333 Device X has an Energy Object representing the computer 2334 itself. It contains two Power Interface defined as 2335 inlets. 2337 Device Y would have an Energy Object representing the PDU 2338 itself (the Energy Device) with a Power Interface 0 2339 defined as an inlet and Power Interface 1..10 defined as 2340 outlets. 2342 The interfaces of the devices would have a Power Source 2343 Relationship such that: 2344 Device X inlet 1 is powered by Device Y outlet 8 2345 Device X inlet 2 is powered by Device Y outlet 9 2347 Without Power Interfaces: 2349 In this case Device X has an Energy Object representing 2350 the computer. Device Y would have an Energy Object 2351 representing the PDU. 2353 The devices would have a Power Source Relationship such 2354 that: 2355 Device X is powered by Device Y. 2357 Example III: Multiple Sources 2359 Topology: 2360 Energy Device X inlet 1 is plugged into Device Y outlet 2361 8. 2362 Energy Device X inlet 2 is plugged into Device Z outlet 9 2364 With Power Interfaces: 2366 Device X has an Energy Object representing the computer 2367 itself. It contains two Power Interface defined as 2368 inlets. 2370 Device Y would have an Energy Object representing the PDU 2371 itself (the Energy Device) with a Power Interface 0 2372 defined as an inlet and Power Interface 1..10 defined as 2373 outlets. 2375 Device Z would have an Energy Object representing the PDU 2376 itself (the Energy Device) with a Power Interface 0 2377 defined as an inlet and Power Interface 1..10 defined as 2378 outlets. 2380 The interfaces of the devices would have a Power Source 2381 Relationship such that: 2382 Device X inlet 1 is powered by Device Y outlet 8 2383 Device X inlet 2 is powered by Device Z outlet 9 2385 Without Power Interfaces: 2387 In this case Device X has an Energy Object representing 2388 the computer. Device Y and Z would both have respective 2389 Energy Objects representing each entire PDU. 2391 The devices would have a Power Source Relationship such 2392 that: 2393 Device X is powered by Device Y and powered by Device Z. 2395 11. Relationship with Other Standards Development 2396 Organizations 2398 11.1. Information Modeling 2400 This power management framework should, as much as 2401 possible, reuse existing standards efforts, especially with 2402 respect to information modeling and data modeling 2403 [RFC3444]. 2405 The data model for power and energy related objects is 2406 based on IEC 61850. 2408 Specific examples include: 2410 . The scaling factor, which represents Energy Object 2411 usage magnitude, conforms to the IEC 61850 definition 2412 of unit multiplier for the SI (System International) 2413 units of measure. 2415 . The electrical characteristic is based on the ANSI and 2416 IEC Standards, which require that we use an accuracy 2417 class for power measurement. ANSI and IEC define the 2418 following accuracy classes for power measurement: 2420 . IEC 62053-22 60044-1 class 0.1, 0.2, 0.5, 1 3. 2422 . ANSI C12.20 class 0.2, 0.5 2424 . The electrical characteristics and quality adheres 2425 closely to the IEC 61850 7-2 standard for describing 2426 AC measurements. 2428 . The power state definitions are based on the DMTF 2429 Power State Profile and ACPI models, with operational 2430 state extensions. 2432 12. Security Considerations 2434 Regarding the data attributes specified here, some or all 2435 may be considered sensitive or vulnerable in some network 2436 environments. Reading or writing these attributes without 2437 proper protection such as encryption or access 2438 authorization may have negative effects on the network 2439 capabilities. 2441 12.1. Security Considerations for SNMP 2443 Readable objects in a MIB modules (i.e., objects with a 2444 MAX-ACCESS other than not-accessible) may be considered 2445 sensitive or vulnerable in some network environments. It 2446 is thus important to control GET and/or NOTIFY access to 2447 these objects and possibly to encrypt the values of these 2448 objects when sending them over the network via SNMP. 2450 The support for SET operations in a non-secure environment 2451 without proper protection can have a negative effect on 2452 network operations. For example: 2454 . Unauthorized changes to the Power Domain or business 2455 context of an Energy Object may result in misreporting 2456 or interruption of power. 2457 . Unauthorized changes to a power state may disrupt the 2458 power settings of the different Energy Objects, and 2459 therefore the state of functionality of the respective 2460 Energy Objects. 2461 . Unauthorized changes to the demand history may disrupt 2462 proper accounting of energy usage. 2464 With respect to data transport SNMP versions prior to 2465 SNMPv3 did not include adequate security. Even if the 2466 network itself is secure (for example, by using IPsec), 2467 there is still no secure control over who on the secure 2468 network is allowed to access and GET/SET 2469 (read/change/create/delete) the objects in these MIB 2470 modules. 2472 It is recommended that implementers consider the security 2473 features as provided by the SNMPv3 framework (see 2474 [RFC3410], section 8), including full support for the 2475 SNMPv3 cryptographic mechanisms (for authentication and 2476 privacy). 2478 Further, deployment of SNMP versions prior to SNMPv3 is not 2479 recommended. Instead, it is recommended to deploy SNMPv3 2480 and to enable cryptographic security. It is then a 2481 customer/operator responsibility to ensure that the SNMP 2482 entity giving access to an instance of these MIB modules is 2483 properly configured to give access to the objects only to 2484 those principals (users) that have legitimate rights to GET 2485 or SET (change/create/delete) them. 2487 13. IANA Considerations 2489 Initial values for the Power State Sets, together with the 2490 considerations for assigning them, are defined in [EMAN- 2491 MON-MIB]. 2493 14. Acknowledgments 2495 The authors would like to Michael Brown for improving the 2496 text dramatically, and Rolf Winter for his feedback. The 2497 award for the best feedback and reviews goes to Bill 2498 Mielke. 2500 15. References 2502 Normative References 2504 [RFC2119] Bradner, S., "Key words for use in RFCs to 2505 Indicate Requirement Levels", BCP 14, RFC 2119, 2506 March 1997. 2508 [RFC2819] S. Waldbusser, "Remote Network Monitoring 2509 Management Information Base", STD 59, RFC 2819, May 2510 2000 2512 [RFC3410] Case, J., Mundy, R., Partain, D., and B. 2513 Stewart, "Introduction and Applicability Statements 2514 for Internet Standard Management Framework ", RFC 2515 3410, December 2002. 2517 [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB 2518 (Version3)", RFC 4133, August 2005. 2520 [RFC4122] Leach, P., Mealling, M., and R. Salz," A 2521 Universally Unique IDentifier (UUID) URN 2522 Namespace", RFC 4122, July 2005 2524 Informative References 2526 [RFC2578] McCloghrie, K., Perkins, D., and J. 2527 Schoenwaelder, "Structure of Management Information 2528 Version 2 (SMIv2", RFC 2578, April 1999 2530 [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences 2531 between Information Models and Data Models", RFC 2532 3444, January 2003. 2534 [RFC5101] B. Claise, Ed., Specification of the IP Flow 2535 Information Export (IPFIX) Protocol for the 2536 Exchange of IP Traffic Flow Information, RFC 5101, 2537 January 2008. 2539 [RFC6020] M. Bjorklund, Ed., " YANG - A Data Modeling 2540 Language for the Network Configuration Protocol 2541 (NETCONF)", RFC 6020, October 2010. 2543 [ACPI] "Advanced Configuration and Power Interface 2544 Specification", http://www.acpi.info/spec30b.htm 2546 [IEEE1621] "Standard for User Interface Elements in Power 2547 Control of Electronic Devices Employed in 2548 Office/Consumer Environments", IEEE 1621, December 2549 2004. 2551 [LLDP] IEEE Std 802.1AB, "Station and Media Control 2552 Connectivity Discovery", 2005. 2554 [LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management 2555 Information Base extension module for TIA-TR41.4 2556 media endpoint discovery information", July 2005. 2558 [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., 2559 and M. Chandramouli, "Requirements for Energy 2560 Management", draft-ietf-eman-requirements-05, (work 2561 in progress), November 2011. 2563 [EMAN-AWARE-MIB] Parello, J., and B. Claise, "Energy-aware 2564 Networks and Devices MIB", draft-ietf-eman-energy- 2565 aware-mib-04, (work in progress), February 2012. 2567 [EMAN-MON-MIB] Chandramouli, M.,Schoening, B., Quittek, J., 2568 Dietz, T., and B. Claise, "Power and Energy 2569 Monitoring MIB", draft-ietf-eman-energy-monitoring- 2570 mib-02, (work in progress), March 2012. 2572 [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, " 2573 Definition of Managed Objects for Battery 2574 Monitoring", draft-ietf-eman-battery-mib-05, (work 2575 in progress), March 2012. 2577 [EMAN-AS] Schoening, B., Chandramouli, M., and B. Nordman, 2578 "Energy Management (EMAN) Applicability Statement", 2579 draft-ietf-eman-applicability-statement-00, (work 2580 in progress), October 2011 2582 [EMAN-TERMINOLOGY] J. Parello, "Energy Management 2583 Terminology", draft-parello-eman-definitions-05, 2584 (work in progress), March 2012 2586 [ITU-T-M-3400] TMN recommandation on Management Functions 2587 (M.3400), 1997 2589 [NMF] "Network Management Fundamentals", Alexander Clemm, 2590 ISBN: 1-58720-137-2, 2007 2592 [TMN] "TMN Management Functions : Performance Management", 2593 ITU-T M.3400 2595 [1037C] US Department of Commerce, Federal Standard 1037C, 2596 http://www.its.bldrdoc.gov/fs-1037/fs-1037c.htm 2598 [IEEE100] "The Authoritative Dictionary of IEEE Standards 2599 Terms" 2600 http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp? 2601 punumber=4116785 2603 [DASH] "Desktop and mobile Architecture for System 2604 Hardware", http://www.dmtf.org/standards/mgmt/dash/ 2606 [ISO50001] "ISO 50001:2011 Energy management systems - 2607 Requirements with guidance for use", 2608 http://www.iso.org/ 2610 [IEC60050] International Electrotechnical Vocabulary 2611 http://www.electropedia.org/iev/iev.nsf/welcome?ope 2612 nform 2614 [SQL] ISO/IEC 9075(1-4,9-11,13,14):2008 2616 [IEEE-802.3at] IEEE 802.3 Working Group, "IEEE Std 802.3at- 2617 2009 - IEEE Standard for Information technology - 2618 Telecommunications and information exchange between 2619 systems - Local and metropolitan area networks - 2620 Specific requirements - Part 3: Carrier Sense 2621 Multiple Access with Collision Detection (CSMA/CD) 2622 Access Method and Physical Layer Specifications - 2623 Amendment: Data Terminal Equipment (DTE) - Power 2624 via Media Dependent Interface (MDI) Enhancements", 2625 October 2009. 2627 [DMTF] "Power State Management Profile DMTF DSP1027 2628 Version 2.0" December 2009 2629 http://www.dmtf.org/sites/default/files/standards/d 2630 ocuments/DSP1027_2.0.0.pdf 2632 [IPENERGY] R. Aldrich, J. Parello "IP-Enabled Energy 2633 Management", 2010, Wiley Publishing 2635 [X.700] CCITT Recommendation X.700 (1992), Management 2636 framework for Open Systems Interconnection (OSI) 2637 for CCITT applications. 2639 [CHEN] "The Entity-Relationship Model: Toward a Unified 2640 View of Data", Peter Pin-shan Chen, ACM 2641 Transactions on Database Systems, 1976 2643 Authors' Addresses 2645 Benoit Claise 2646 Cisco Systems, Inc. 2647 De Kleetlaan 6a b1 2648 Diegem 1813 2649 BE 2651 Phone: +32 2 704 5622 2652 Email: bclaise@cisco.com 2654 John Parello 2655 Cisco Systems, Inc. 2656 3550 Cisco Way 2657 San Jose, California 95134 2658 US 2660 Phone: +1 408 525 2339 2661 Email: jparello@cisco.com 2663 Brad Schoening 2664 44 Rivers Edge Drive 2665 Little Silver, NJ 07739 2666 US 2668 Phone: 2669 Email: brad@bradschoening.com 2671 Juergen Quittek 2672 NEC Europe Ltd. 2673 Network Laboratories 2674 Kurfuersten-Anlage 36 2675 69115 Heidelberg 2676 Germany 2678 Phone: +49 6221 90511 15 2679 EMail: quittek@netlab.nec.de 2681 Bruce Nordman 2682 Lawrence Berkeley National Laboratory 2683 1 Cyclotron Road 2684 Berkeley 94720 2685 US 2687 Phone: +1 510 486 7089 2688 Email: bnordman@lbl.gov