idnits 2.17.1 draft-ietf-eman-requirements-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 02, 2013) is 4004 days in the past. Is this intentional? 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) -- Obsolete informational reference (is this intentional?): RFC 5102 (Obsoleted by RFC 7012) == Outdated reference: A later version (-11) exists of draft-ietf-eman-applicability-statement-03 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Quittek, Ed. 3 Internet-Draft M. Chandramouli 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: November 03, 2013 R. Winter 6 NEC Europe Ltd. 7 T. Dietz 8 NEC Europe Ltd. 9 B. Claise 10 Cisco Systems, Inc. 11 May 02, 2013 13 Requirements for Energy Management 14 draft-ietf-eman-requirements-14 16 Abstract 18 This document defines requirements for standards specifications for 19 energy management. The requirements defined in this document concern 20 monitoring functions as well as control functions. Monitoring 21 functions include identification of energy-managed devices and their 22 components, monitoring of their power states, power inlets, power 23 outlets, actual power (the instantaneous power, as opposed to the 24 demand, which is an averaged power), power attributes, received 25 energy, provided energy, and contained batteries. Control functions 26 serve for controlling power supply and power state of energy-managed 27 devices and their components. 28 This document does not specify the features that must be implemented 29 by compliant implementations but rather features that must be 30 supported by standards for energy management. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 03, 2013. 49 Copyright Notice 51 Copyright (c) 2013 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Conventional Requirements For Energy Management . . . . . 4 68 1.2. Specific Requirements For Energy Management . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. General Considerations Related To Energy Management . . . . . 6 71 3.1. Power States . . . . . . . . . . . . . . . . . . . . . . 7 72 3.2. Saving Energy Versus Maintaining Service Level . . . . . 7 73 3.3. Local Versus Network-Wide Energy Management . . . . . . . 7 74 3.4. Energy Monitoring Versus Energy Saving . . . . . . . . . 8 75 3.5. Overview Of Energy Management Requirements . . . . . . . 8 76 4. Identification Of Entities . . . . . . . . . . . . . . . . . 9 77 5. Information On Entities . . . . . . . . . . . . . . . . . . . 10 78 5.1. General Information On Entities . . . . . . . . . . . . . 10 79 5.2. Power Interfaces . . . . . . . . . . . . . . . . . . . . 11 80 5.3. Power . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 5.4. Power State . . . . . . . . . . . . . . . . . . . . . . . 15 82 5.5. Energy . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 5.6. Battery State . . . . . . . . . . . . . . . . . . . . . . 18 84 5.7. Time Series Of Measured Values . . . . . . . . . . . . . 19 85 6. Control Of Entities . . . . . . . . . . . . . . . . . . . . . 21 86 7. Reporting On Other Entities . . . . . . . . . . . . . . . . . 21 87 8. Controlling Other Entities . . . . . . . . . . . . . . . . . 22 88 8.1. Controlling Power States Of Other Entities . . . . . . . 22 89 8.2. Controlling Power Supply . . . . . . . . . . . . . . . . 23 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 92 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 94 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 95 12.2. Informative References . . . . . . . . . . . . . . . . . 26 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 98 1. Introduction 100 With rising energy cost and with an increasing awareness of the 101 ecological impact of running information technology equipment, energy 102 management functions and interfaces are becoming an additional basic 103 requirement for network management systems and devices connected to a 104 network. 106 This document defines requirements for standards specifications for 107 energy management, both monitoring functions and control functions. 108 The main subject of energy management are entities in the network, 109 i.e. device or one of a device's components, that receive and 110 provide electric energy. Devices may have an IP address, such as 111 hosts, routers, and middleboxes, or they are connected indirectly to 112 the Internet via a proxy with an IP address providing a management 113 interface for the device. An example are devices in a building 114 infrastructure using non-IP protocols and a gateway to the Internet. 116 The main subject of energy management are devices and their 117 components that receive and provide electric energy. Devices may 118 have an IP address, such as hosts, routers, and middleboxes, or they 119 might be connected indirectly to the Internet via a proxy with an IP 120 address providing a management interface for the device. An example 121 are devices in a building infrastructure using non-IP protocols and a 122 gateway to the Internet. 124 These requirements concern the standards specification process and 125 not the implementation of specified standards. All requirements in 126 this document must be reflected by standards specifications to be 127 developed. However, which of the features specified by these 128 standards will be mandatory, recommended, or optional for compliant 129 implementations is to be defined by standards track document(s) and 130 not in this document. 132 Section 3 elaborates a set of general needs for energy management. 133 Requirements for an energy management standard are specified in 134 Sections 4 to 8. 136 Sections 4 to 6 contain conventional requirements specifying 137 information on entities and control functions. 139 Sections 7 and 8 contain requirements specific to energy management. 140 Due to the nature of power supply, some monitoring and control 141 functions are not conducted by interacting with the entity of 142 interest, but with other entities, for example, entities upstream in 143 a power distribution tree. 145 1.1. Conventional Requirements For Energy Management 147 The specification of requirements for an energy management standard 148 starts with Section 4 addressing the identification of entities and 149 the granularity of reporting of energy-related information. A 150 standard must support unique identification of entities, reporting 151 per entire device, and reporting energy-related information on 152 individual components of a device or attached devices. 154 Section 5 specifies requirements related to monitoring of entities. 155 This includes general (type, context) information and specific 156 information on Power States, power inlets, power outlets, power, 157 energy, and batteries. Control Power State and power supply of 158 entities is covered by requirements specified in Section 6. 160 1.2. Specific Requirements For Energy Management 162 While the conventional requirements summarized above seem to be all 163 that would be needed for energy management, there are significant 164 differences between energy management and most well known network 165 management functions. The most significant difference is the need 166 for some devices to report on other entities. There are three major 167 reasons for this. 169 o For monitoring a particular entity it is not always sufficient to 170 communicate with the entity only. When the entity has no 171 instrumentation for determining power, it might still be possible 172 to obtain power values for the entity by communication with other 173 entities in its power distribution tree. 174 A simple example is retrieving power values from a power meter at 175 the power line into the entity. Common examples are a Power 176 Distribution Unit (PDU) and a Power over Ethernet (PoE) switch. 177 Both supply power to other entities at sockets or ports, 178 respectively, and are often instrumented to measure power per 179 socket or port. 181 o Similar considerations apply to controlling power supply of a 182 entity which often needs direct or indirect communications with 183 another entity upstream in the power distribution tree. Again, a 184 PDU and a PoE switch are common examples, if they have the 185 capability to switch on or off power at their sockets or ports, 186 respectively. 188 o Energy management often extends beyond entities with IP network 189 interfaces, to non-IP building systems accessed via a gateway 190 (sometimes called an energy management system or controller). 191 Requirements in this document do not cover details of these 192 networks and energy devices, but specify means for opening IP 193 network management towards them. 195 These specific issues of energy management and a set of further ones 196 are covered by requirements specified in Sections 7 and 8. 198 The requirements in these sections need a new energy management 199 framework that deals with the specific nature of energy management. 200 The actual standards documents, such as MIB module specifications, 201 address conformance by specifying which feature must, should, or may 202 be implemented by compliant implementations. 204 2. Terminology 206 Energy 208 That which does work or is capable of doing work. As used by 209 electric utilities, it is generally a reference to electrical 210 energy and is measured in kilo-watt hours (kWh) [IEEE-100]. 212 Power 214 The time rate at which Energy is emitted, transferred, or 215 received; usually expressed in watts (or in joules per second) 216 [IEEE-100]. 218 Power Attributes 220 Measurements of the electrical current, voltage, phase and 221 frequencies at a given point in an electrical power system. 222 Reference: Adapted from [IEC60050] 224 NOTES: 1. Power Attributes is not intended to be judgmental with 225 respect to a reference or technical value and are independent of 226 any usage context. 228 Energy Management 230 Energy Management is a set of functions for measuring, modeling, 231 planning, and optimizing networks to ensure that the network 232 elements and attached devices use energy efficiently and in a 233 manner appropriate to the nature of the application and the cost 234 constraints of the organization [ITU-M.3400]. 236 Energy Management System 238 An Energy Management System is a combination of hardware and 239 software used to administer a network with the primary purpose 240 being Energy Management [Fed-Std-1037C]. 242 Energy Monitoring 244 Energy Monitoring is a part of Energy Management that deals with 245 collecting or reading information from network elements and 246 attached devices and their components to aid in Energy Management. 248 Energy Control 250 Energy Control is a part of Energy Management that deals with 251 controlling energy supply and power state of network elements and 252 attached devices and their components. 254 Power Interface 256 A Power Interface is an interface at which a device is connected 257 to a Power transmission medium at which it can receive Power, 258 provide Power, or both. 260 Power Inlet 262 A Power Inlet is a Power Interface at which a device can receive 263 Power from other devices. 265 Power Outlet 267 A Power Outlet is a Power Interface at which a device can provide 268 Power to other devices. 270 Power State 272 A Power State is a condition or mode of a device that broadly 273 characterizes its capabilities, Power consumption, and 274 responsiveness to input [IEEE-1621]. 276 3. General Considerations Related To Energy Management 278 The basic objective of Energy Management is operating sets of devices 279 with minimal Energy, while maintaining a certain level of service. 280 [I-D.ietf-eman-applicability-statement] presents the applicability of 281 the EMAN framework to a variety of scenarios, and lists use cases and 282 target devices. 284 3.1. Power States 286 Entities can be set to an operational state that results in the 287 lowest power level that still meets the service level performance 288 objectives. In principle, there are three basic types of Power 289 States for an entity or for a whole system: 291 o full Power State 293 o sleep state (not functional, but immediately available) 295 o off state (may require significant time to become operational) 297 In specific devices, the number of Power States and their properties 298 varies considerably. Simple entities may just have only the extreme 299 states, full power and off state. Many devices have three basic 300 Power States: on, off, and sleep. However, more finely grained Power 301 States can be implemented. Examples are various operational low 302 power states in which a device requires less energy than in the full 303 power "on" state, but - compared to the sleep state - is still 304 operational with reduced performance or functionality. 306 3.2. Saving Energy Versus Maintaining Service Level 308 One of the objectives of Energy Management is to reduce the Energy 309 consumption. While this objective is clear, the way to attain that 310 goal is often difficult. In many cases there is no way of reducing 311 power without the consequence of a potential service (performance or 312 capacity) degradation. In this case, a trade-off needs to be made 313 between service level objectives and energy minimization. In other 314 cases a reduction of power can easily be achieved while still 315 maintaining sufficient service level performance, for example, by 316 switching entities to lower Power States when higher performance is 317 not needed. 319 3.3. Local Versus Network-Wide Energy Management 321 Many Energy saving functions are executed locally by an entity; it 322 monitors its usage and dynamically adapts its Power according to the 323 required performance. It may, for example, switch to a sleep state 324 when it is not in use or out of scheduled business hours. An Energy 325 Management System may observe an entity's Power State and configure 326 its Power saving policies. 328 Energy savings can also be achieved with policies implemented by a 329 network management system that controls Power States of managed 330 entities. Information about the Power received and provided by 331 entities in different Power States may be required to set policies. 332 Often this information is acquired best through monitoring. 334 Both methods, network-wide and local Energy Management, have 335 advantages and disadvantages and often it is desirable to combine 336 them. Central management is often favorable for setting Power States 337 of a large number of entities at the same time, for example, at the 338 beginning and end of business hours in a building. Local management 339 is often preferable for Power saving measures based on local 340 observations, such as high or low functional load of an entity. 342 3.4. Energy Monitoring Versus Energy Saving 344 Monitoring Energy, Power, and Power States alone does not reduce the 345 Energy needed to run an entity. In fact, it may even increase it 346 slightly due to monitoring instrumentation that needs Energy. 347 Reporting measured quantities over the network may also increase 348 Energy use, though the acquired information may be an essential input 349 to control loops that save Energy. 351 Monitoring Energy and Power States can also be required for other 352 purposes including: 354 o investigating Energy saving potential 356 o evaluating the effectiveness of Energy saving policies and 357 measures 359 o deriving, implementing, and testing Power management strategies 361 o accounting for the total Power received and provided by an entity, 362 a network, or a service 364 o predicting an entity's reliability based on Power usage 366 o choosing time of next maintenance cycle for an entity 368 3.5. Overview Of Energy Management Requirements 370 The following basic management functions are required: 372 o monitoring Power States 374 o monitoring Power (Energy conversion rate) 375 o monitoring (accumulated) received and provided Energy 377 o monitoring Power attributes 379 o setting Power States 381 Power control is complementary to other Energy savings measures such 382 as low-power electronics, Energy saving protocols, energy-efficient 383 device design (for example, low-power modes for components), and 384 energy-efficient network architectures. Measurement of received and 385 provided Energy can provide useful data for developing these 386 technologies. 388 4. Identification Of Entities 390 Entities must be capable of being uniquely identified with the 391 context of the management system. This includes entities that are 392 components of managed devices as well as entire devices. 394 Entities that report on or control other entities must identify the 395 entities they report on or control: see Section 7 or Section 8, 396 respectively, for the detailed requirements. 398 An entity may be an entire device or a component of it. Examples of 399 components of interest are a hard drive, a battery, or a line card. 400 It may be required to be able to control individual components to 401 save Energy. For example, server blades can be switched off when the 402 overall load is low or line cards at switches may be powered down at 403 night. 405 Identifiers for devices and components are already defined in 406 standard MIB modules, such as the LLDP MIB module [IEEE-802.1AB] and 407 the LLDP-MED MIB module [ANSI-TIA-1057] for devices and the Entity 408 MIB module [RFC4133] and the Power Ethernet MIB [RFC3621] for 409 components of devices. Energy Management needs means to link Energy- 410 related information to such identifiers. 412 Instrumentation for measuring received and provided Energy of a 413 device is typically more expensive than instrumentation for 414 retrieving its Power State. Many devices may provide Power State 415 information for all individual components separately, while reporting 416 the received and provided Energy only for the entire device. 418 4.1. Identifying Entities 420 The standard must provide means for uniquely identifying entities. 421 Uniqueness must be preserved such that collisions of identities are 422 avoided at potential receivers of monitored information. 424 4.2. Persistence Of Identifiers 426 The standard must provide means for indicating whether identifiers of 427 entities are persistent across a re-start of the entity. 429 4.3. Change Of Identifiers 431 The standard must provide means to indicate any change of entity 432 identifiers. 434 4.4. Using Entity Identifiers Of Existing MIB Modules 436 The standard must provide means for re-using entity identifiers from 437 existing standards including at least the following: 439 o the entPhysicalIndex in the Entity MIB module [RFC4133] 441 o the LldpPortNumber in the LLDP MIB module [IEEE-802.1AB] and in 442 the LLDP-MED MIB module [ANSI-TIA-1057] 444 o the pethPsePortIndex and the pethPsePortGroupIndex in the Power 445 Ethernet MIB [RFC3621] 447 Generic means for re-using other entity identifiers must be provided. 449 5. Information On Entities 451 This section describes information on entities for which the standard 452 must provide means for retrieving and reporting. 454 Required information can be structured into seven groups. 455 Section 5.1 specifies requirements for general information on 456 entities, such as type of entity or context information. 457 Requirements for information on Power Inlets and Power Outlets of 458 entities are specified in Section 5.2. Monitoring of Power and 459 Energy is covered by Sections 5.3 and 5.5, respectively. Section 5.4 460 covers requirements related to entities' Power States. Section 5.6 461 specifies requirements for monitoring batteries. Finally, the 462 reporting of time series of values is covered by Section 5.7. 464 5.1. General Information On Entities 465 For Energy Management it may be required to understand the role and 466 context of an entity. An Energy Management System may aggregate 467 values of received and provided Energy according to a defined 468 grouping of entities. When controlling and setting Power States it 469 may be helpful to understand the grouping of the entity and role of 470 an entity in a network, for example, it may be important to exclude 471 some mission critical network devices from being switched to lower 472 Power or even from being switched off. 474 5.1.1. Type Of Entity 476 The standard must provide means to configure, retrieve and report a 477 textual name or a description of an entity. 479 5.1.2. Context Of An Entity 481 The standard must provide means for retrieving and reporting context 482 information on entities, for example, tags associated with an entity 483 that indicate the entity's role. 485 5.1.3. Significance Of Entities 487 The standard must provide means for retrieving and reporting the 488 significance of entities within its context, for example, how 489 important the entity is. 491 5.1.4. Power Priority 493 The standard must provide means for retrieving and reporting Power 494 priorities of entities. Power priorities indicate an order in which 495 Power States of entities are changed, for example, to lower Power 496 States for saving Power. 498 5.1.5. Grouping Of Entities 500 The standard must provide means for grouping entities. This can be 501 achieved in multiple ways, for example, by providing means to tag 502 entities, to assign them to domains, or to assign device types to 503 them. 505 5.2. Power Interfaces 507 A Power Interface is an interface at which a device is connected to a 508 Power transmission medium at which it can receive Power, provide 509 Power, or both. 511 A Power Interface is either an inlet or an outlet. Some Power 512 Interfaces change over time from being an inlet to being an outlet 513 and vice versa. However most Power Interfaces never change. 515 Devices have Power Inlets at which they are supplied with electric 516 Power. Most devices have a single Power Inlet, while some have 517 multiple inlets. Different Power Inlets on a device are often 518 connected to separate Power distribution trees. For Energy 519 Monitoring, it is useful to retrieve information on the number of 520 inlets of a device, the availability of Power at inlets and which of 521 them are actually in use. 523 Devices can have one or more Power Outlets for supplying other 524 devices with electric Power. 526 For identifying and potentially controlling the source of Power 527 received at an inlet, it may be required to identify the Power Outlet 528 of another device at which the received Power is provided. 529 Analogously, for each outlet it is of interest to identify the Power 530 Inlets that receive the Power provided at a certain outlet. Such 531 information is also required for constructing the wiring topology of 532 electrical Power distribution to devices. 534 Static properties of each Power Interface are required information 535 for Energy Management. Static properties include the kind of 536 electric current (AC or DC), the nominal voltage, the nominal AC 537 frequency, and the number of AC phases. Note that often the nominal 538 voltage is not a single value but a voltage range, such as, for 539 example, (100V-120V), (100V-240V), (100V-120V,220V-240V). 541 5.2.1. Lists Of Power Interfaces 543 The standard must provide means for monitoring the list of Power 544 Interfaces of a device. 546 5.2.2. Operational Mode Of Power Interfaces 548 The standard must provide means for monitoring the operational mode 549 of a Power Interface which is either "Power Inlet" or "Power Outlet". 551 5.2.3. Corresponding Power Outlet 553 The standard must provide means for identifying the Power Outlet that 554 provides the Power received at a Power Inlet. 556 5.2.4. Corresponding Power Inlets 557 The standard must provide means for identifying the list of Power 558 Inlets that receive the Power provided at a Power Outlet. 560 5.2.5. Availability Of Power 562 If the Power States allow it, the standard must provide means for 563 monitoring the availability of Power at each Power Interface. This 564 indicates whether at a Power Interfaces Power supply is switched on 565 or off. 567 5.2.6. Use Of Power 569 The standard must provide means for monitoring for each Power 570 Interface if it is in actual use. For inlets this means that the 571 device actually receives Power at the inlet. For outlets this means 572 that Power is actually provided from it to one or more devices. 574 5.2.7. Type Of current 576 The standard must provide means for reporting the type of current (AC 577 or DC) for each Power Interface as well as for a device. 579 5.2.8. Nominal Voltage Range 581 The standard must provide means for reporting the nominal voltage 582 range for each Power Interface. 584 5.2.9. Nominal AC Frequency 586 The standard must provide means for reporting the nominal AC 587 frequency for each Power Interface. 589 5.2.10. Number Of AC Phases 591 The standard must provide means for reporting the number of AC phases 592 for each Power Interface. 594 5.3. Power 596 Power is measured as an instantaneous value or as the average over a 597 time interval. 599 Obtaining highly accurate values for Power and Energy may be costly 600 if it requires dedicated metering hardware. Entities without the 601 ability to measure their Power and received and provided Energy with 602 high accuracy may just report estimated values, for example based on 603 load monitoring, Power State, or even just the entity type. 605 Depending on how Power and Energy values are obtained, the confidence 606 in the reported value and its accuracy will vary. Entities reporting 607 such values should qualify the confidence in the reported values and 608 quantify the accuracy of measurements. For reporting accuracy, the 609 accuracy classes specified in IEC 62053-21 [IEC.62053-21] and IEC 610 62053-22 [IEC.62053-22] should be considered. 612 Further properties of the Power supplied to a device are also of 613 interest. Particularly for AC Power supply, several Power attributes 614 beyond the real Power are of potential interest to Energy Management 615 Systems. The set of these properties include the the complex Power 616 attributes (apparent power, reactive power, and phase angle of the 617 current or power factor) as well as the actual voltage, the actual AC 618 frequency, the Total Harmonic Distortion (THD) of voltage and 619 current, and the impedance of an AC phase or of the DC supply. A new 620 standard for monitoring these Power attributes should be in line with 621 already existing standards, such as [IEC.61850-7-4]. 623 For some network management tasks it is desirable to receive 624 notifications from entities when their Power value exceeds or falls 625 below given thresholds. 627 5.3.1. Real Power / Power Factor 629 The standard must provide means for reporting the real power for each 630 Power Interface as well as for an entity. Reporting Power includes 631 reporting the direction of Power flow. 633 5.3.2. Power Measurement Interval 635 The standard must provide means for reporting the corresponding time 636 or time interval for which a Power value is reported. The Power 637 value can be measured at the corresponding time or averaged over the 638 corresponding time interval. 640 5.3.3. Power Measurement Method 642 The standard must provide means to indicate the method how these 643 values have been obtained. Based on how the measurement was 644 conducted, it is possible to associate a certain degree of confidence 645 with the reported Power value. For example, there are methods of 646 measurement such as direct Power measurement, or by estimation based 647 on performance values, or hard coding average Power values for an 648 entity. 650 5.3.4. Accuracy Of Power And Energy Values 651 The standard must provide means for reporting the accuracy of 652 reported Power and Energy values. 654 5.3.5. Actual Voltage And Current 656 The standard must provide means for reporting the actual voltage and 657 actual current for each Power Interface as well as for a device. In 658 case of AC Power supply, means must be provided for reporting the 659 actual voltage and actual current per phase. 661 5.3.6. High/low Power Notifications 663 The standard must provide means for creating notifications if Power 664 values of an entity rise above or fall below given thresholds. 666 5.3.7. Complex Power / Power Factor 668 The standard must provide means for reporting the complex power for 669 each Power Interface and for each phase at a Power Interface. 670 Besides the real power, at least two out of the following three 671 quantities need to be reported: apparent power, reactive power, phase 672 angle. The phase angle can be substituted by the power factor. 674 5.3.8. Actual AC Frequency 676 The standard must provide means for reporting the actual AC frequency 677 for each Power Interface. 679 5.3.9. Total Harmonic Distortion 681 The standard must provide means for reporting the Total Harmonic 682 Distortion (THD) of voltage and current for each Power Interface. In 683 case of AC Power supply, means must be provided for reporting the THD 684 per phase. 686 5.3.10. Power Supply Impedance 688 The standard must provide means for reporting the impedance of Power 689 supply for each Power Interface. In case of AC Power supply, means 690 must be provided for reporting the impedance per phase. 692 5.4. Power State 694 Many entities have a limited number of discrete Power States. 696 There is a need to report the actual Power State of an entity, and 697 means for retrieving the list of all supported Power States. 699 Different standards bodies have already defined sets of Power States 700 for some entities, and others are creating new Power State sets. In 701 this context, it is desirable that the standard support many of these 702 Power State standards. In order to support multiple management 703 systems possibly using different Power State sets, while 704 simultaneously interfacing with a particular entity, the Energy 705 Management standard must provide means for supporting multiple Power 706 State sets used simultaneously at an entity. 708 Power States have parameters that describe its properties. It is 709 required to have standardized means for reporting some key 710 properties, such as the typical Power of an entity in a certain 711 state. 713 There also is a need to report statistics on Power States including 714 the time spent and the received and provided Energy in a Power State. 716 5.4.1. Actual Power State 718 The standard must provide means for reporting the actual Power State 719 of an entity. 721 5.4.2. List Of Supported Power States 723 The standard must provide means for retrieving the list of all 724 potential Power States of an entity. 726 5.4.3. Multiple Power State Sets 728 The standard must provide means for supporting multiple Power State 729 sets simultaneously at an entity. 731 5.4.4. List Of Supported Power State Sets 733 The standard must provide means for retrieving the list of all Power 734 State sets supported by an entity. 736 5.4.5. List Of Supported Power States Within A Set 738 The standard must provide means for retrieving the list of all 739 potential Power States of an entity for each supported Power State 740 set. 742 5.4.6. Typical Power Per Power State 744 The standard must provide means for retrieving the typical Power for 745 each supported Power State. 747 5.4.7. Power State Statistics 749 The standard must provide means for monitoring statistics per Power 750 State including the total time spent in a Power State, the number of 751 times each state was entered and the last time each state was 752 entered. More Power State statistics are addressed by requirement 753 5.5.3. 755 5.4.8. Power State Changes 757 The standard must provide means for generating a notification when 758 the actual Power State of an entity changes. 760 5.5. Energy 762 Monitoring of electrical Energy received or provided by an entity is 763 a core function of Energy Management. Since Energy is an accumulated 764 quantity, it is always reported for a certain interval of time. This 765 can be, for example, the time from the last restart of the entity to 766 the reporting time, the time from another past event to the reporting 767 time, the last given amount of time before the reporting time, or a 768 certain interval specified by two time stamps in the past. 770 It is useful for entities to record their received and provided 771 Energy per Power State and report these quantities. 773 5.5.1. Energy 775 The standard must provide means for reporting measured values of 776 Energy and the direction of the Energy flow received or provided by 777 an entity. The standard must also provide the means to report the 778 Energy passing through each Power Interface. 780 5.5.2. Time Intervals 782 The standard must provide means for reporting the time interval for 783 which an Energy value is reported. 785 5.5.3. Energy Per Power State 787 The standard must provide means for reporting the received and 788 provided Energy for each individual Power State. This extends the 789 requirement 5.4.7 on Power State statistics. 791 5.6. Battery State 793 Batteries are special entities that supply Power. The status of 794 these batteries is typically controlled by automatic functions that 795 act locally on the entity and manually by users of the entity. There 796 is a need to monitor the battery status of these entities by network 797 management systems. 799 Devices containing batteries can be modeled in two ways. The entire 800 device can be modeled as a single entity on which Energy-related 801 information is reported or the battery can be modeled as an 802 individual entity for which Energy-related information is monitored 803 individually according to requirements in Sections 5.1 to 5.5. 805 Further information on batteries is of interest for Energy 806 Management, such as the current charge of the battery, the number of 807 completed charging cycles, the charging state of the battery, its 808 temperature, and further static and dynamic battery properties. It 809 is desirable to receive notifications if the charge of a battery 810 becomes very low or if a battery needs to be replaced. 812 5.6.1. Battery Charge 814 The standard must provide means for reporting the current charge of a 815 battery, in units of milliampere hours (mAh). 817 5.6.2. Battery Charging State 819 The standard must provide means for reporting the charging state 820 (charging, discharging, etc.) of a battery. 822 5.6.3. Battery Charging Cycles 824 The standard must provide means for reporting the number of completed 825 charging cycles of a battery. 827 5.6.4. Actual Battery Capacity 829 The standard must provide means for reporting the actual capacity of 830 a battery. 832 5.6.5. Actual Battery Capacity 834 The standard must provide means for reporting the actual temperature 835 of a battery. 837 5.6.6. Static Battery Properties 839 The standard must provide means for reporting static properties of a 840 battery, including the nominal capacity, the number of cells, the 841 nominal voltage, and the battery technology. 843 5.6.7. Low battery Charge Notification 845 The standard must provide means for generating a notification when 846 the charge of a battery decreases below a given threshold. Note that 847 the threshold may depend on the battery technology. 849 5.6.8. Battery Replacement Notification 851 The standard must provide means for generating a notification when 852 the number of charging cycles of battery exceeds a given threshold. 854 5.6.9. Multiple Batteries 856 If the battery technology allows, the standard must provide means for 857 meeting requirements 5.6.1 to 5.6.8 for each individual battery 858 contained in a single entity. 860 5.7. Time Series Of Measured Values 862 For some network management tasks, it is required to obtain time 863 series of measured values from entities, such as Power, Energy, 864 battery charge, etc. 866 In general time series measurements could be obtained in many 867 different ways. Means should be provided to either push such values 868 from the location where they are available to the management system 869 or to have them stored locally for a sufficiently long period of time 870 such that a management system can retrieve full time series. 872 The following issues are to be considered when designing time series 873 measurement and reporting functions: 875 1. Which quantities should be reported? 877 2. Which time interval type should be used (total, delta, sliding 878 window)? 880 3. Which measurement method should be used (sampled, continuous)? 882 4. Which reporting model should be used (push or pull)? 884 The most discussed and probably most needed quantity is Energy. But 885 a need for others, such as Power and battery charge can be identified 886 as well. 888 There are three time interval types under discussion for accumulated 889 quantities such as Energy. They can be reported as total values, 890 accumulated between the last restart of the measurement and a certain 891 timestamp. Alternatively, Energy can be reported as delta values 892 between two consecutive timestamps. Another alternative is reporting 893 values for sliding windows as specified in [IEC.61850-7-4]. 895 For non-accumulative quantities, such as Power, different measurement 896 methods are considered. Such quantities can be reported using values 897 sampled at certain time stamps or alternatively by mean values for 898 these quantities averaged between two (consecutive) time stamps or 899 over a sliding window. 901 Finally, time series can be reported using different reporting 902 models, particularly push-based or pull-based. Push-based reporting 903 can, for example, be realized by reporting Power or Energy values 904 using the IPFIX protocol [RFC5101],[RFC5102]. SNMP [RFC3411] is an 905 example for a protocol that can be used for realizing pull-based 906 reporting of time series. 908 For reporting time series of measured values the following 909 requirements have been identified. Further decisions concerning 910 issues discussed above need to be made when developing concrete 911 Energy Management standards. 913 5.7.1. Time Series Of Energy Values 915 The standard must provide means for reporting time series of Energy 916 values. If the comparison of time series between multiple entities 917 is required, then time synchronization between those entities must be 918 provided (for example, with the Network Time Protocol [RFC5905]). 920 5.7.2. Time Series Interval Types 922 The standard must provide means for supporting alternative interval 923 types. Requirement 5.5.2 applies to every reported time value. 925 5.7.3. Time Series Storage Capacity 926 The standard should provide means for reporting the number of values 927 of a time series that can be stored for later reporting. 929 6. Control Of Entities 931 Many entities control their Power State locally. Other entities need 932 interfaces for an Energy Management System to control their Power 933 State. 935 Power supply is typically not self-managed by devices. And 936 controlling Power supply is typically not conducted as interaction 937 between Energy Management System and the device itself. It is rather 938 an interaction between the management system and a device providing 939 Power at its Power Outlets. Similar to Power State control, Power 940 supply control may be policy driven. Note that shutting down the 941 Power supply abruptly may have severe consequences for the device. 943 6.1. Controlling Power States 945 The standard must provide means for setting Power States of entities. 947 6.2. Controlling Power Supply 949 The standard must provide means for switching Power supply off or 950 turning Power supply on at Power Interfaces providing Power to one or 951 more device. 953 7. Reporting On Other Entities 955 As discussed in Section 5, not all Energy-related information may be 956 available at the concerned entity. Such information may be provided 957 by other entities. This section covers reporting of information 958 only. See Section 8 for requirements on controlling other entities. 960 There are cases where a Power supply unit switches Power for several 961 entities by turning Power on or off at a single Power Outlet or where 962 a Power meter measures the accumulated Power of several entities at a 963 single power line. Consequently, it should be possible to report 964 that a monitored value does not relate to just a single entity, but 965 is an accumulated value for a set of entities. All of these entities 966 belonging to that set need to be identified. 968 7.1. Reports On Other Entities 970 The standard must provide means for an entity to report information 971 on another entity. 973 7.2. Identity Of Other Entities On Which Is Reported 975 For entities that report on one or more other entities, the standard 976 must provide means for reporting the identity of other entities on 977 which information is reported. Note that, in some situations, a 978 manual configuration might be required to populate this information. 980 7.3. Reporting Quantities Accumulated Over Multiple Entities 982 The standard must provide means for reporting the list of all 983 entities from which contributions are included in an accumulated 984 value. 986 7.4. List Of All Entities On Which Is Reported 988 For entities that report on one or more other entities, the standard 989 must provide means for reporting the complete list of all those 990 entities on which Energy-related information can be reported. 992 7.5. Content Of Reports On Other Entities 994 For entities that report on one or more other entities, the standard 995 must provide means for indicating which Energy-related information 996 can be reported for which of those entities. 998 8. Controlling Other Entities 1000 This section specifies requirements for controlling Power States and 1001 power supply of entities by communicating with other entities that 1002 have means for doing that control. 1004 8.1. Controlling Power States Of Other Entities 1006 Some entities have control over Power States of other entities. For 1007 example a gateway to a building system may have means to control the 1008 Power State of entities in the building that do not have an IP 1009 interface. For this scenario and other similar cases means are 1010 needed to make this control accessible to the Energy Management 1011 System. 1013 In addition to this, it is required that an entity that has its state 1014 controlled by other entities has means to report the list of these 1015 other entities. 1017 8.1.1. Control Of Power States Of Other Entities 1018 The standard must provide means for an Energy Management System to 1019 send Power State control commands to an entity that concern the Power 1020 States of entities other than the one the command was sent to. 1022 8.1.2. Identity Of Other Power State Controlled Entities 1024 The standard must provide means for reporting the identities of the 1025 entities for which the reporting entity has means to control their 1026 Power States. Note that, in some situations, a manual configuration 1027 might be required to populate this information. 1029 8.1.3. List Of All Power State Controlled Entities 1031 The standard must provide means for an entity to report the list of 1032 all entities for which it can control the Power State. 1034 8.1.4. List Of All Power State Controllers 1036 The standard must provide means for an entity that receives commands 1037 controlling its Power State from other entities to report the list of 1038 all those entities. 1040 8.2. Controlling Power Supply 1042 Some entities may have control of the Power supply of other entities, 1043 for example, because the other entity is supplied via a Power Outlet 1044 of the entity. For this and similar cases means are needed to make 1045 this control accessible to the Energy Management System. This need 1046 is already addressed by requirement 6.2. 1048 In addition, it is required that an entity that has its supply 1049 controlled by other entities has means to report the list of these 1050 other entities. This need is already addressed by requirements 5.2.3 1051 and 5.2.4. 1053 9. Security Considerations 1055 Controlling Power State and Power supply of entities are highly 1056 sensitive actions since they can significantly affect the operation 1057 of directly and indirectly affected devices. Therefore all control 1058 actions addressed in sections 6 and 8 must be sufficiently protected 1059 through authentication, authorization, and integrity protection 1060 mechanisms. 1062 Entities that are not sufficiently secure to operate directly on the 1063 public Internet do exist and can be a significant cause of risk, for 1064 example, if the remote control functions described in sections 6 and 1065 8 can be exercised on those devices from anywhere on the Internet. 1067 The standard needs to provide means for dealing with such cases. One 1068 solution is providing means that allow for isolation of such devices, 1069 e.g. behind a sufficiently secured gateway. Another solution is 1070 allowing compliant implementations that have disabled or not 1071 implemented sensitive functions. 1073 Monitoring Energy-related quantities of an entity addressed in 1074 Sections 5 - 8 can be used to derive more information than just the 1075 received and provided Energy, so monitored data requires protection. 1076 This protection includes authentication and authorization of entities 1077 requesting access to monitored data as well as confidentiality 1078 protection during transmission of monitored data. Privacy of stored 1079 data in an entity must be taken into account. Monitored data may be 1080 used as input to control, accounting, and other actions, so integrity 1081 of transmitted information and authentication of the origin may be 1082 needed. 1084 9.1. Secure Energy Management 1086 The standard must provide privacy, integrity, and authentication 1087 mechanisms for all actions addressed in Sections 5 - 8. The security 1088 mechanisms must meet the security requirements elaborated in 1089 Section 1.4 of [RFC3411]. 1091 9.2. Isolation Of Insufficiently Secure Entities 1093 The standard must provide means to allow for isolation of entities 1094 that that are not sufficiently secure to operate on the public 1095 Internet, e.g., behind a gateway that does implement sufficient 1096 security so that the vulnerable entities are not directly exposed to 1097 the Internet. 1099 9.3. Optional Restriction Of Functions 1101 The standard must allow for compliant implementations that do not 1102 implement sensitive functions or disable them when operating in not 1103 sufficiently secured environments. This applies particularly to the 1104 control functions described in sections 6 and 8. 1106 10. IANA Considerations 1108 This document has no actions for IANA. 1110 11. Acknowledgments 1112 The authors would like to thank Ralf Wolter for his first essay on 1113 this draft. Many thanks to William Mielke, John Parello, JinHyeock 1114 Choi, Georgios Karagiannis, and Michael Suchoff for their helpful 1115 comments on the draft. Many thanks for their IESG reviews to Stephen 1116 Farrell, Robert Sparks, Adrian Farrel, Barry Leiba, Brian Haberman, 1117 Peter Resnick, Sean Turner, Stewart Bryant, and Ralph Droms. 1118 Finally, special thanks to the document shepherd Nevil Brownlee, and 1119 to the EMAN working group chairs: Nevil Brownlee and Bruce Nordman. 1121 12. References 1123 12.1. Normative References 1125 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1126 Architecture for Describing Simple Network Management 1127 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1128 December 2002. 1130 [RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", RFC 1131 3621, December 2003. 1133 [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", 1134 RFC 4133, August 2005. 1136 [ANSI-TIA-1057] 1137 Telecommunications Industry Association, , "ANSI- 1138 TIA-1057-2006 - TIA Standard - Telecommunications - IP 1139 Telephony Infrastructure - Link Layer Discovery Protocol 1140 for Media Endpoint Devices ", April 2006. 1142 [IEEE-100] 1143 IEEE, , "Authoritative Dictionary of IEEE Standards Terms, 1144 IEEE 100, Seventh Edition ", December 2000. 1146 [IEC.62053-21] 1147 International Electrotechnical Commission, , "Electricity 1148 metering equipment (a.c.) - Particular requirements - Part 1149 22: Static meters for active energy (classes 1 and 2) ", 1150 2003. 1152 [IEC.62053-22] 1153 International Electrotechnical Commission, , "Electricity 1154 metering equipment (a.c.) - Particular requirements - Part 1155 22: Static meters for active energy (classes 0,2 S and 0,5 1156 S) ", 2003. 1158 [IEC.61850-7-4] 1159 International Electrotechnical Commission, , 1160 "Communication networks and systems for power utility 1161 automation - Part 7-4: Basic communication structure - 1162 Compatible logical node classes and data object classes ", 1163 2010. 1165 [IEEE-1621] 1166 Institute of Electrical and Electronics Engineers, , "IEEE 1167 P1621-2004 -Draft Standard for User Interface Elements in 1168 Power Control of Electronic Devices Employed in Office 1169 Consumer Environments ", June 2005. 1171 [IEEE-802.1AB] 1172 IEEE Computer Society, , "IEEE Std 802.1AB-2009 - IEEE 1173 Standard for Local and metropolitan area networks - 1174 Station and Media Access Control Discovery ", September 1175 2009. 1177 12.2. Informative References 1179 [RFC5101] Claise, B., "Specification of the IP Flow Information 1180 Export (IPFIX) Protocol for the Exchange of IP Traffic 1181 Flow Information", RFC 5101, January 2008. 1183 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 1184 Meyer, "Information Model for IP Flow Information Export", 1185 RFC 5102, January 2008. 1187 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1188 Time Protocol Version 4: Protocol and Algorithms 1189 Specification", RFC 5905, June 2010. 1191 [I-D.ietf-eman-applicability-statement] 1192 Schoening, B., Chandramouli, M., and B. Nordman, "Energy 1193 Management (EMAN) Applicability Statement", draft-ietf- 1194 eman-applicability-statement-03 (work in progress), April 1195 2013. 1197 [Fed-Std-1037C] 1198 United States National Communications System Technology 1199 and Standards Division, , "Federal Standard 1037C - 1200 Telecommunications: Glossary of Telecommunication Terms ", 1201 August 1996. 1203 [IEC60050] 1204 , "International Electrotechnical Vocabulary. 1205 http://www.electropedia.org/iev/iev.nsf/welcome?openform 1206 ", . 1208 [ITU-M.3400] 1209 International Telecommunication Union, , "ITU-T 1210 Recommendation M.3400 - Series M: TMN and Network 1211 Maintenance: International Transmission Systems, Telephone 1212 Circuits, Telegraphy, Facsimile and Leased Circuits - 1213 Telecommunications Management Network - TMN management 1214 functions ", February 2000. 1216 Authors' Addresses 1218 Juergen Quittek (editor) 1219 NEC Europe Ltd. 1220 NEC Laboratories Europe 1221 Network Research Division 1222 Kurfuersten-Anlage 36 1223 Heidelberg 69115 1224 Germany 1226 Phone: +49 6221 4342-115 1227 Email: quittek@neclab.eu 1229 Mouli Chandramouli 1230 Cisco Systems, Inc. 1231 Sarjapur Outer Ring Road 1232 Bangalore 1233 India 1235 Phone: +91 80 4426 3947 1236 Email: moulchan@cisco.com 1238 Rolf Winter 1239 NEC Europe Ltd. 1240 NEC Laboratories Europe 1241 Network Research Division 1242 Kurfuersten-Anlage 36 1243 Heidelberg 69115 1244 Germany 1246 Phone: +49 6221 4342-121 1247 Email: Rolf.Winter@neclab.eu 1248 Thomas Dietz 1249 NEC Europe Ltd. 1250 NEC Laboratories Europe 1251 Network Research Division 1252 Kurfuersten-Anlage 36 1253 Heidelberg 69115 1254 Germany 1256 Phone: +49 6221 4342-128 1257 Email: Thomas.Dietz@neclab.eu 1259 Benoit Claise 1260 Cisco Systems, Inc. 1261 De Kleetlaan 6a b1 1262 Diegem 1831 1263 Belgium 1265 Phone: +32 2 704 5622 1266 Email: bclaise@cisco.com