Network Working GroupInternet Engineering Task Force (IETF) J. Quittek, Ed.Internet-DraftRequest for Comments: 6988 NEC Europe Ltd. Category: Informational M. ChandramouliIntended status: InformationalISSN: 2070-1721 Cisco Systems, Inc.Expires: November 03, 2013R. WinterNEC Europe Ltd.T. Dietz NEC Europe Ltd. B. Claise Cisco Systems, Inc.May 02,September 2013 Requirements for Energy Managementdraft-ietf-eman-requirements-14Abstract This document defines requirements for standards specifications forenergy management.Energy Management. The requirements defined in this documentconcernare concerned with monitoring functions as well as control functions. Monitoring functions includeidentification ofidentifying energy-managed devices and their components, as well as monitoringoftheirpower states, power inlets, power outlets,Power States, Power Inlets, Power Outlets, actualpower (the instantaneouspower,as opposed to the demand, which is an averaged power), power attributes,Power Attributes, received energy, provided energy, and contained batteries. Control functionsserve forinclude such functions as controlling power supply andpower statePower State of energy-managed devices and their components. This document does not specify the features that must be implemented by compliant implementations but rather lists features that must be supported by standards forenergy management.Energy Management. Status of This Memo ThisInternet-Draftdocument issubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsnot an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are amaximumcandidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status ofsix monthsthis document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 03, 2013.http://www.rfc-editor.org/info/rfc6988. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .32 1.1. Conventional RequirementsForfor Energy Management . . . . .43 1.2. Specific RequirementsForfor Energy Management . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. General Considerations RelatedToto Energy Management . . . . . 6 3.1. Power States . . . . . . . . . . . . . . . . . . . . . .76 3.2. Saving EnergyVersusversus Maintaining Service Level . . . . . 7 3.3. LocalVersusversus Network-Wide Energy Management . . . . . . . 7 3.4. Energy MonitoringVersusversus Energy Saving . . . . . . . . . 8 3.5. OverviewOfof Energy Management Requirements . . . . . . . 8 4. IdentificationOfof Entities . . . . . . . . . . . . . . . . . 9 5. InformationOnon Entities . . . . . . . . . . . . . . . . . . . 10 5.1. General InformationOnon Entities . . . . . . . . . . . . . 10 5.2. Power Interfaces . . . . . . . . . . . . . . . . . . . . 11 5.3. Power . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.4. Power State . . . . . . . . . . . . . . . . . . . . . . . 15 5.5. Energy . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.6. Battery State . . . . . . . . . . . . . . . . . . . . . .1817 5.7. Time SeriesOfof Measured Values . . . . . . . . . . . . . 19 6. ControlOfof Entities . . . . . . . . . . . . . . . . . . . . .2120 7. ReportingOnon Other Entities . . . . . . . . . . . . . . . . . 21 8. Controlling Other Entities . . . . . . . . . . . . . . . . . 22 8.1. Controlling Power StatesOfof Other Entities . . . . . . . 22 8.2. Controlling Power Supply . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10.IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11.Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 2512.11. References . . . . . . . . . . . . . . . . . . . . . . . . . 2512.1.11.1. Normative References . . . . . . . . . . . . . . . . . . 2512.2.11.2. Informative References . . . . . . . . . . . . . . . . . 26Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 271. Introduction With rising energycostcosts andwithan increasing awareness of the ecological impact of running information technology equipment,energy managementEnergy Management (EMAN) functions and interfaces are becoming an additional basic requirement for network management systems and devices connected to a network. This document defines requirements for standards specifications forenergy management,Energy Management, both monitoring functions and control functions.The main subject of energy management are entities in the network, i.e. device or one of a device's components, that receive and provide electric energy. Devices may have an IP address, such as hosts, routers, and middleboxes, or they are connected indirectly to the Internet via a proxy with an IP address providing a management interface for the device. An example are devices in a building infrastructure using non-IP protocols and a gateway to the Internet. The main subject of energy management areEnergy Management functions focus mainly on devices and their components that receive and provideelectricelectrical energy. Devicesmay have an IP address,such as hosts, routers, andmiddleboxes,middleboxes may have an IP address orthey mightmay be connected indirectly to the Internet via a proxy with an IP address providing a management interface for thedevice. An example aredevice, for example, devices in a building infrastructure using non-IP protocols and a gateway to the Internet. These requirementsconcernare concerned with the standards specification process and not the implementation of specified standards. All requirements in this document must be reflected by standards specifications to be developed. However, which of the features specified by these standards will be mandatory, recommended, or optional for compliant implementations is to be defined bystandards trackStandards Track document(s) and not in this document. Section 3 elaborates on a set of general needs forenergy management.Energy Management. Requirements for anenergy managementEnergy Management standard are specified in Sections 4tothrough 8. Sections 4tothrough 6 contain conventional requirements specifying information on entities and control functions. Sections 7 and 8 contain requirements specific toenergy management.Energy Management. Due to the nature of power supply, some monitoring and control functions are not conducted by interacting with the entity ofinterest,interest but rather with other entities, for example, entities upstream in a power distribution tree. 1.1. Conventional RequirementsForfor Energy Management The specification of requirements for anenergy managementEnergy Management standard starts with Section4 addressing4, which addresses the identification of entities and the granularity of reporting of energy-related information. A standard must support the unique identification of entities, reporting per entire device, and reporting energy-related information on individual components of a device or attached devices. Section 5 specifies requirements related to the monitoring of entities. This includes general (type, context) information and specific information on Power States,power inlets, power outlets,Power Inlets, Power Outlets, power, energy, and batteries.ControlThe control of Power State and power supplyofby entities is covered by requirements specified in Section 6. 1.2. Specific RequirementsForfor Energy Management While the conventional requirements summarized above seem to be all that would be needed forenergy management,Energy Management, there are significant differences betweenenergy managementEnergy Management and mostwell knownwell-known network management functions. The most significant difference is the need for some devices to report on other entities. There are three major reasons for this. o For monitoring a particularentityentity, it is not always sufficient to communicate only withthe entity only.that entity. When the entity has no instrumentation for determining power, it might still be possible to obtain power values for the entitybyvia communication with other entities in its power distribution tree. A simple exampleis retrievingof this would be the retrieval of power values from a power meter at the power line into the entity.Common examples are aA Power Distribution Unit (PDU) and a Power over Ethernet (PoE)switch.switch are common examples. Both supply power to other entities at sockets or ports, respectively, and are often instrumented to measure power per socket or port. o Similar considerations apply to controlling the power supply ofaan entitywhichthat often needs direct or indirect communications with another entity upstream in the power distribution tree. Again, a PDU and a PoE switch are common examples, if they have the capability to switch power on or offpowerat their sockets or ports, respectively. o EnergymanagementManagement often extends beyond entities with IP networkinterfaces,interfaces to non-IP building systems accessed via a gateway (sometimes called anenergy management systemEnergy Management System or controller). Requirements in this document do not cover the details of these networks and energydevices,devices but specify means for opening IP network management towards them. These specific issues ofenergy management and a set of further onesEnergy Management, as well as other issues, are covered by requirements specified in Sections 7 and 8. The requirements in these sections need a newenergy managementEnergy Management framework that deals with the specific nature ofenergy management.Energy Management. The actual standards documents, such as MIB module specifications, address conformance by specifying whichfeaturefeatures must, should, or may be implemented by compliant implementations. 2. Terminology The terms specified in the terminology section are capitalized throughout the document; the exceptions are the well-known terms "energy" and "power". These terms are generic and are used in generated terms such as "energy-saving", "low-power", etc. Energy EnergyThat which does work oriscapablethe capacity ofdoinga system to do work. As used by electric utilities, it is generally a reference to electrical energy and is measured inkilo-watt hourskilowatt-hours (kWh) [IEEE-100]. PowerThePower is the time rate at whichEnergyenergy is emitted, transferred, or received; power is usually expressed in watts (or in joules per second) [IEEE-100]. (The term "power" does not refer to the concept of demand, which is an averaged power value.) Power Attributes Power AttributesMeasurementsare measurements ofthe electricalelectric current, voltage,phasephase, and frequencies at a given point in an electrical powersystem. Reference: Adaptedsystem (adapted from[IEC60050] NOTES: 1.[IEC.60050]). NOTE: Power Attributesisare not intended to bejudgmental"judgmental" with respect to a reference or technical value and are independent of any usage context. Energy Management Energy Management is a set of functions for measuring, modeling, planning, and optimizing networks to ensure that the network elements and attached devices use energy efficiently and in a manner appropriate to the nature of the application and the cost constraints of the organization [ITU-M.3400]. Energy Management System An Energy Management System is a combination of hardware and software used to administer a network with the primary purpose being EnergyManagement [Fed-Std-1037C].Management. Energy Monitoring Energy Monitoring is a part of Energy Management that deals with collecting or reading information from network elements and attached devices and their components to aid in Energy Management. Energy Control Energy Control is a part of Energy Management that deals with controlling energy supply andpower statePower State of networkelements andelements, as well as attached devices and their components. Power Interface A Power Interface is an interface at which a device is connected to aPowerpower transmissionmediummedium, at which it can in turn receivePower,power, providePower,power, or both. Power Inlet A Power Inlet is a Power Interface at which a device can receivePowerpower from other devices. Power Outlet A Power Outlet is a Power Interface at which a device can providePowerpower to other devices. Power State A Power State is a condition or mode of a device that broadly characterizes its capabilities,Powerpower consumption, and responsiveness to input [IEEE-1621]. 3. General Considerations RelatedToto Energy Management The basic objective of Energy Management isoperatingto operate sets of deviceswithusing minimalEnergy,energy, while maintaining a certain level of service.[I-D.ietf-eman-applicability-statement][EMAN-STATEMENT] presents the applicability of the EMAN framework to a variety ofscenarios,scenarios and also lists use cases and target devices. 3.1. Power States Entities can be set to an operational state that results in the lowest power level that still meets theservice levelservice-level performance objectives. In principle, there are three basic types of Power States for an entity or for a whole system: o full Power State o sleep state (notfunctional,functional but immediately available) o off state (may require significant time to become operational) In specific devices, the number of Power States and their propertiesvariesvary considerably. Simple entities mayjust haveonly have the extremestates,states: fullpowerPower State and off state. Many devices have three basic Power States: on, off, and sleep. However, more finely grained Power States can be implemented. Examples are various operational lowpower statesPower States in which a device requires less energy than in the full power "on" state, but--- compared to the sleep state--- is still operational with reduced performance or functionality. 3.2. Saving EnergyVersusversus Maintaining Service Level One of the objectives of Energy Management is to reducethe Energyenergy consumption. While this objective is clear,the way to attainattaining that goal is often difficult. In manycasescases, there is no wayof reducingto reduce power without the consequence of a potential service (performance or capacity) degradation. In this case, a trade-off needs to be made betweenservice levelservice-level objectives and energy minimization. In othercasescases, a reduction of power can easily be achieved while still maintaining sufficientservice levelservice-level performance, for example, by switching entities to lower Power States when higher performance is not needed. 3.3. LocalVersusversus Network-Wide Energy Management ManyEnergy savingenergy-saving functions are executed locally by an entity; it monitors its usage and dynamically adapts itsPowerpower according to the required performance. It may, for example, switch to a sleep state when it is not inuseuse, oroutoutside of scheduled business hours. An Energy Management System may observe an entity's Power State and configure itsPower savingpower-saving policies. Energy savings can also be achieved with policies implemented by a network management system that controls Power States of managed entities. Information about thePowerpower received and provided by entities in different Power States may be required in order to set such policies.OftenOften, this information isacquiredbest acquired through monitoring.Both methods, network-wideNetwork-wide and local EnergyManagement,Management methods both have advantages anddisadvantagesdisadvantages, andoftenit is often desirable to combine them. Central management is often favorable for setting Power States of a large number of entities at the same time, for example, at the beginning and end of business hours in a building. Local management is often preferable forPower savingpower-saving measures based on local observations, such as the high or low functional load of an entity. 3.4. Energy MonitoringVersusversus Energy Saving MonitoringEnergy, Power,energy, power, and Power States alone does not reduce theEnergyenergy needed to run an entity. In fact, it may even increase it slightly due to monitoring instrumentation that needsEnergy.energy. Reporting measured quantities over the network may also increaseEnergyenergy use, though the acquired information may be an essential input to control loops that saveEnergy.energy. MonitoringEnergyenergy and Power States can also be required for otherpurposespurposes, including: o investigatingEnergy savingenergy-saving potential o evaluating the effectiveness ofEnergy savingenergy-saving policies and measures o deriving, implementing, and testingPowerpower management strategies o accounting for the totalPowerpower received and provided by an entity, a network, or a service o predicting an entity's reliability based onPowerpower usage o choosing the time of the next maintenance cycle for an entity 3.5. OverviewOfof Energy Management Requirements The following basic management functions are required: o monitoring Power States o monitoringPower (Energypower (energy conversion rate) o monitoring (accumulated) received and providedEnergyenergy o monitoring PowerattributesAttributes o setting Power States Power control is complementary to otherEnergy savings measuresenergy-saving measures, such as low-power electronics,Energy savingenergy-saving protocols, energy-efficient device design (for example, low-power modes for components), and energy-efficient network architectures. Measurement of received and providedEnergyenergy can provide useful data for developing these technologies. 4. IdentificationOfof Entities Entities must be capable of being uniquely identifiedwithwithin the context of the management system. This includes entities that are components of managed devices as well as entire devices. Entities that report on or control other entities must identify the entities they report on or control: see Section 7 or Section 8, respectively, for the detailed requirements. An entity may be an entire device or a component of it. Examples of components of interest are a hard drive, a battery, or a line card.It may be required to be ableThe ability to control individual components to saveEnergy.energy may be required. For example, server blades can be switched off when the overall load islowlow, or line cards at switches may be powered down at night. Identifiers for devices and components are already defined in standard MIB modules, such as theLLDPLink Layer Discovery Protocol (LLDP) MIB module [IEEE-802.1AB] and theLLDP-MEDLink Layer Discovery Protocol -- Media Endpoint Discovery (LLDP-MED) MIB module [ANSI-TIA-1057] fordevicesdevices, and the Entity MIB module[RFC4133][RFC6933] and thePowerpower Ethernet MIB [RFC3621] for components of devices. Energy Management needs a means to linkEnergy- relatedenergy-related information to such identifiers. Instrumentation for measuring the received and providedEnergyenergy of a device is typically more expensive than instrumentation for retrieving its Power State. Many devices may provide Power State information for all individual components separately, while reporting the received and providedEnergyenergy only for the entire device. 4.1. Identifying Entities The standard must provide means for uniquely identifying entities. Uniqueness must be preserved such that collisions of identities are avoided at potential receivers of monitored information. 4.2. PersistenceOfof Identifiers The standard must provide means for indicating whether identifiers of entities are persistent across are-startrestart of the entity. 4.3. ChangeOfof Identifiers The standard must provide means to indicate any change of entity identifiers. 4.4. Using Entity IdentifiersOfof Existing MIB Modules The standard must provide means forre-usingreusing entity identifiers from existingstandardsstandards, including at least the following: o the entPhysicalIndex in the Entity MIB module[RFC4133][RFC6933] o the LldpPortNumber in the LLDP MIB module [IEEE-802.1AB] and in the LLDP-MED MIB module [ANSI-TIA-1057] o the pethPsePortIndex and the pethPsePortGroupIndex in the Power Ethernet MIB [RFC3621] Generic means forre-usingreusing other entity identifiers must be provided. 5. InformationOnon Entities This section describes information on entities for which the standard must provide means for retrieving and reporting. Required information can be structured into seven groups. Section 5.1 specifies requirements for general information on entities, such as type of entity or context information. Requirements for information on Power Inlets and Power Outlets of entities are specified in Section 5.2.MonitoringThe monitoring ofPowerpower andEnergyenergy is covered by Sections 5.3 and 5.5, respectively. Section 5.4 covers requirements related to entities' Power States. Section 5.6 specifies requirements for monitoring batteries. Finally, the reporting of time series of values is covered by Section 5.7. 5.1. General InformationOnon Entities For EnergyManagement it may be required to understandManagement, understanding the role and context of anentity.entity may be required. An Energy Management System may aggregate values of received and providedEnergyenergy according to a defined grouping of entities. When controlling and setting PowerStatesStates, it may be helpful to understand the grouping of the entity and role of an entity in anetwork, fornetwork. For example, it may be important to exclude somemission criticalmission-critical network devices from being switched to lowerPowerpower or even from being switched off. 5.1.1. TypeOfof Entity The standard must provide means to configure,retrieveretrieve, and report a textual name or a description of an entity. 5.1.2. ContextOf Anof an Entity The standard must provide means for retrieving and reporting context information on entities, for example, tags associated with an entity that indicate the entity's role. 5.1.3. SignificanceOfof Entities The standard must provide means for retrieving and reporting the significance of entities within its context, for example, how important the entity is. 5.1.4. Power Priority The standard must provide means for retrieving and reportingPowerpower priorities of entities. Power priorities indicate an order in which Power States of entities are changed, for example, to lower Power States for savingPower.power. 5.1.5. GroupingOfof Entities The standard must provide means for grouping entities. This can be achieved in multiple ways, for example, by providing means to tag entities,toassign them to domains, ortoassign device types to them. 5.2. Power Interfaces A Power Interface is an interface at which a device is connected to aPowerpower transmissionmediummedium, at which it can in turn receivePower,power, providePower,power, or both. A Power Interface is either an inlet or an outlet. Some Power Interfaces change over time from being an inlet to being an outlet and vice versa.HoweverHowever, most Power Interfaces never change. Devices have Power Inlets at which they are supplied with electricPower.power. Most devices have a single Power Inlet, while some have multiple inlets. Different Power Inlets on a device are often connected to separatePowerpower distribution trees. For Energy Monitoring, it is useful to retrieve information on the number of inlets of a device, the availability ofPowerpower atinletsinlets, and whichof theminlets are actually in use. Devices can have one or more Power Outlets for supplying other devices with electricPower.power. For identifying and potentially controlling the source ofPowerpower received at an inlet,it may be required to identifyidentifying the Power Outlet of another device at which the receivedPowerpower isprovided.provided may be required. Analogously, for eachoutletoutlet, it is of interest to identify the Power Inlets that receive thePowerpower provided at a certain outlet. Such information is also required for constructing the wiring topology of electricalPowerpower distribution to devices. Static properties of each Power Interface are required information for Energy Management. Static properties include the kind of electric current (AC or DC), the nominal voltage, the nominal AC frequency, and the number of AC phases. Note thatoftenthe nominal voltage is often not a single value but a voltage range, such as, for example, (100V-120V), (100V-240V), (100V-120V,220V-240V). 5.2.1.Lists OfList of Power Interfaces The standard must provide means for monitoring the list of Power Interfaces of a device. 5.2.2. Operational ModeOfof Power Interfaces The standard must provide means for monitoring the operational mode of a PowerInterfaceInterface, which is either "Power Inlet" or "Power Outlet". 5.2.3. Corresponding Power Outlet The standard must provide means for identifying the Power Outlet that provides thePowerpower received at a Power Inlet. 5.2.4. Corresponding Power Inlets The standard must provide means for identifying the list of Power Inlets that receive thePowerpower provided at a Power Outlet. 5.2.5. AvailabilityOfof Power If the Power States allow it, the standard must provide means for monitoring the availability ofPowerpower at each Power Interface. Thisindicatesincludes indicating whether a power supply at a PowerInterfaces Power supplyInterface is switched on or off. 5.2.6. UseOfof Power The standard must provide means for monitoringforeach Power Interface if it is actually inactualuse. Forinletsinlets, this means that the device actually receivesPowerpower at the inlet. Foroutletsoutlets, this means thatPowerpower is actually provided fromitthe outlet to one or more devices. 5.2.7. TypeOf currentof Current The standard must provide means for reporting the type of current (AC or DC) for each Power Interface as well as for a device. 5.2.8. Nominal Voltage Range The standard must provide means for reporting the nominal voltage range for each Power Interface. 5.2.9. Nominal AC Frequency The standard must provide means for reporting the nominal AC frequency for each Power Interface. 5.2.10. NumberOfof AC Phases The standard must provide means for reporting the number of AC phases for each Power Interface. 5.3. Power Power is measured as an instantaneous value or as the average over a time interval. Obtaining highly accurate values forPowerpower andEnergyenergy may be costly ifit requiresdedicated meteringhardware.hardware is required. Entities without the ability to measure with high accuracy theirPower andpower, received energy, and providedEnergy with high accuracyenergy may just report estimated values, forexampleexample, based on load monitoring, Power State, or even just the entity type. Depending on howPowerpower andEnergyenergy values are obtained, the confidence inthea reported value and its accuracy will vary. Entities reporting such values should qualify the confidence in the reported values and quantify the accuracy of measurements. For reporting accuracy, the accuracy classes specified in IEC 62053-21 [IEC.62053-21] and IEC 62053-22 [IEC.62053-22] should be considered. Further properties of thePowerpower supplied to a device are also of interest.Particularly forFor ACPower supply,power supply in particular, several PowerattributesAttributes beyond the realPowerpower are of potential interest to Energy Management Systems. The set of these propertiesinclude theincludes the complex PowerattributesAttributes (apparent power, reactive power, and phase angle of the current or power factor) as well as the actual voltage, the actual AC frequency, the Total Harmonic Distortion (THD) of voltage and current, and the impedance of an AC phase or of the DC supply. A new standard for monitoring these PowerattributesAttributes should be in line withalready existingalready-existing standards, such as [IEC.61850-7-4]. For some network managementtaskstasks, it is desirable to receive notifications from entities when theirPowerpower value exceeds or falls below given thresholds. 5.3.1. Real Power / Power Factor The standard must provide means for reporting the real power for each Power Interface as well as for an entity. ReportingPowerpower includes reporting the direction ofPowerpower flow. 5.3.2. Power Measurement Interval The standard must provide means for reporting the corresponding time or time interval for which aPowerpower value is reported. ThePowerpower value can be measured at the corresponding time or averaged over the corresponding time interval. 5.3.3. Power Measurement Method The standard must provide means to indicate the methodhowused to obtain thesevalues have been obtained.values. Based on how the measurement was conducted, it is possible to associate a certain degree of confidence with the reportedPowerpower value. For example, there are methods of measurement such as directPowerpower measurement,or byestimation based on performance values, orhard codinghard-coding averagePowerpower values for an entity. 5.3.4. AccuracyOfof PowerAndand Energy Values The standard must provide means for reporting the accuracy of reportedPowerpower andEnergyenergy values. 5.3.5. Actual VoltageAndand Current The standard must provide means for reporting the actual voltage and actual current for each Power Interface as well as for a device.In case ofFor ACPowerpower supply, means must be provided for reporting the actual voltage and actual current per phase. 5.3.6.High/low PowerHigh-Power/Low-Power Notifications The standard must provide means for creating notifications ifPowerpower values of an entity rise above or fall below given thresholds. 5.3.7. Complex Power / Power Factor The standard must provide means for reporting the complex power for each Power Interface and for each phase at a Power Interface.BesidesIn addition to the real power, at least twooutof the following three quantities need to be reported: apparent power, reactive power, and phase angle. The phase angle can be substituted by the power factor. 5.3.8. Actual AC Frequency The standard must provide means for reporting the actual AC frequency for each Power Interface. 5.3.9. Total Harmonic Distortion The standard must provide means for reporting the Total Harmonic Distortion (THD) of voltage and current for each Power Interface.In case ofFor ACPowerpower supply, means must be provided for reporting the THD per phase. 5.3.10. Power Supply Impedance The standard must provide means for reporting the impedance ofPowera power supply for each Power Interface.In case ofFor ACPowerpower supply, means must be provided for reporting the impedance per phase. 5.4. Power State Many entities have a limited number of discrete Power States. There is a need to report the actual Power State of anentity,entity and to provide the means for retrieving the list of all supported Power States. Different standards bodies have already defined sets of Power States for some entities, and others are creating new Power State sets. In this context, it is desirable that the standard support many of these Power State standards. In order to support multiple management systems that possiblyusinguse different Power Statesets,sets while simultaneously interfacing with a particular entity, the Energy ManagementstandardSystem must provide means for supporting multiple Power State sets used simultaneously at an entity. Power States have parameters that describeitstheir properties. It is required to have a standardized means for reporting some key properties, such as the typicalPowerpower of an entity in a certain state. Therealsois also a need to report statistics on PowerStatesStates, including the time spentandas well as the received and providedEnergyenergy in a Power State. 5.4.1. Actual Power State The standard must provide means for reporting the actual Power State of an entity. 5.4.2. ListOfof Supported Power States The standard must provide means for retrieving the list of all potential Power States of an entity. 5.4.3. Multiple Power State Sets The standard must provide means for supporting multiple Power State sets simultaneously at an entity. 5.4.4. ListOfof Supported Power State Sets The standard must provide means for retrieving the list of all Power State sets supported by an entity. 5.4.5. ListOfof Supported Power StatesWithin Awithin a Set The standard must provide means for retrieving the list of all potential Power States of an entity for each supported Power State set. 5.4.6. Typical Power Per Power State The standard must provide means for retrieving the typicalPowerpower for each supported Power State. 5.4.7. Power State Statistics The standard must provide means for monitoring statistics per PowerStateState, including the total time spent in a Power State, the number of times each state wasenteredentered, and the last time each state was entered. More Power State statistics are addressed byrequirementthe requirements in Section 5.5.3. 5.4.8. Power State Changes The standard must provide means for generating a notification when the actual Power State of an entity changes. 5.5. EnergyMonitoringThe monitoring of electricalEnergyenergy received or provided by an entity is a core function of Energy Management. SinceEnergyenergy is an accumulated quantity, it is always reported for a certain interval of time. This can be, for example, the time from the last restart of the entity to the reporting time, the time from another past event to the reporting time, the last given amount of time before the reporting time, or a certain interval specified by twotime stampstimestamps in the past. It is useful for entities to record their received and providedEnergyenergy per Power State and report these quantities. 5.5.1. Energy Measurement The standard must provide means for reporting measured values ofEnergyenergy and the direction of theEnergyenergy flow received or provided by an entity. The standard must also provide the means to report theEnergyenergy passing through each Power Interface. 5.5.2. Time Intervals The standard must provide means for reporting the time interval for which anEnergyenergy value is reported. 5.5.3. Energy Per Power State The standard must provide means for reporting the received and providedEnergyenergy for each individual Power State. This extends therequirement 5.4.7requirements on Power Statestatistics.statistics described in Section 5.4.7. 5.6. Battery State Batteries are special entities that supplyPower.power. The status of these batteries is typically controlled by automatic functions that act locally on theentityentity, and manually by users of the entity. There is a need to monitor the battery status of these entities by network management systems. Devices containing batteries can be modeled in two ways. The entire device can be modeled as a single entity on whichEnergy-relatedenergy-related information isreportedreported, or the battery can be modeled as an individual entity for whichEnergy-relatedenergy-related information is monitored individually according to requirements in Sections 5.1tothrough 5.5. Further information on batteries is of interest for Energy Management, such as the current charge of the battery, the number of completed charging cycles, the charging state of the battery, its temperature, andfurtheradditional static and dynamic battery properties. It is desirable to receive notifications if the charge of a battery becomes very low or if a battery needs to be replaced. 5.6.1. Battery Charge The standard must provide means for reporting the current charge of a battery, in units ofmilliampere hoursmilliampere-hours (mAh). 5.6.2. Battery Charging State The standard must provide means for reporting the charging state (charging, discharging, etc.) of a battery. 5.6.3. Battery Charging Cycles The standard must provide means for reporting the number of completed charging cycles of a battery. 5.6.4. Actual Battery Capacity The standard must provide means for reporting the actual capacity of a battery. 5.6.5. Actual BatteryCapacityTemperature The standard must provide means for reporting the actual temperature of a battery. 5.6.6. Static Battery Properties The standard must provide means for reporting static properties of a battery, including the nominal capacity, the number of cells, the nominal voltage, and the battery technology. 5.6.7. LowbatteryBattery Charge Notification The standard must provide means for generating a notification when the charge of a battery decreases below a given threshold. Note that the threshold may depend on the battery technology. 5.6.8. Battery Replacement Notification The standard must provide means for generating a notification when the number of charging cycles of a battery exceeds a given threshold. 5.6.9. Multiple Batteries If the battery technology allows, the standard must provide means for meeting requirements in Sections 5.6.1tothrough 5.6.8 for each individual battery contained in a single entity. 5.7. Time SeriesOfof Measured Values For some network management tasks,it is required to obtainobtaining time series of measured values from entities, such asPower, Energy,power, energy, battery charge,etc.etc., is required. Ingeneralgeneral, time series measurements could be obtained in many different ways. Means should be provided to either push such values from the location where they are available to the management system or to have them stored locally for a sufficiently long period of time such that a management system can retrieve the full time series. The following issues are to be considered when designing time series measurement and reporting functions: 1. Which quantities should be reported? 2. Which time interval type should be used (total, delta, sliding window)? 3. Which measurement method should be used (sampled, continuous)? 4. Which reporting model should be used (push or pull)? The most discussed and probably most needed quantity isEnergy.energy. But a need for others, such asPowerpower and batterychargecharge, can be identified as well. There are three time interval types under discussion for accumulated quantities such asEnergy.energy. They can be reported as total values, accumulated between the last restart of the measurement and a certain timestamp. Alternatively,Energyenergy can be reported as delta values between two consecutive timestamps. Another alternative is reporting values for sliding windows as specified in [IEC.61850-7-4]. For non-accumulative quantities, such asPower,power, different measurement methods are considered. Such quantities can be reported using values sampled at certaintime stamps or alternativelytimestamps or, alternatively, by mean values for these quantities averaged between two (consecutive)time stampstimestamps or over a sliding window. Finally, time series can be reported using different reporting models, particularly push-based or pull-based. Push-based reporting can, for example, be realized by reportingPowerpower orEnergyenergy values using theIPFIXIP Flow Information Export (IPFIX) protocol[RFC5101],[RFC5102]. SNMP[RFC5101] [RFC5102]. The Simple Network Management Protocol (SNMP) [RFC3411] is an exampleforof a protocol that can be used for realizing pull-based reporting of time series. For reporting time series of measuredvaluesvalues, the following requirements have been identified. Further decisions concerning issues discussed above need to be made when developing concrete Energy Management standards. 5.7.1. Time SeriesOfof Energy Values The standard must provide means for reporting time series ofEnergyenergy values. If the comparison of time series between multiple entities is required, then time synchronization between those entities must be provided (for example, with the Network Time Protocol [RFC5905]). 5.7.2. Time Series Interval Types The standard must provide means for supporting alternative interval types.RequirementThe requirement in Section 5.5.2 applies to every reported time value. 5.7.3. Time Series Storage Capacity The standard should provide means for reporting the number of values of a time series that can be stored for later reporting. 6. ControlOfof Entities Many entities control their Power State locally. Other entities need interfaces for an Energy Management System to control their Power State.PowerA power supply is typically not self-managed bydevices. And controlling Powerdevices, and control of a power supply is typically not conducted as an interaction between an Energy Management System and the device itself. It is rather an interaction between the management system and a device providingPowerpower at its Power Outlets. Similar to Power State control,Powerpower supply control may be policy driven. Note that shutting down thePowerpower supply abruptly may have severe consequences for the device. 6.1. Controlling Power States The standard must provide means for setting Power States of entities. 6.2. Controlling Power Supply The standard must provide means for switchingPowera power supply off or turningPowera power supply on at Power Interfaces providingPowerpower to one or moredevice.devices. 7. ReportingOnon Other Entities As discussed in Section 5, not allEnergy-relatedenergy-related information may be available at theconcerned entity.entity in question. Such information may be provided by other entities. This section covers only the reporting ofinformation only.information. See Section 8 for requirements on controlling other entities. There are cases where aPowerpower supply unit switchesPowerpower for several entities by turningPowerpower on or off at a single Power Outlet or where aPowerpower meter measures the accumulatedPowerpower of several entities at a single power line. Consequently, it should be possible to report that a monitored value does not relate to just a singleentity,entity but is an accumulated value for a set of entities. All ofthesethe entities belonging to that set need to be identified. 7.1. ReportsOnon Other Entities The standard must provide means for an entity to report information on another entity. 7.2. IdentityOfof Other EntitiesOnon Which Information Is Reported For entities that report on one or more other entities, the standard must provide means for reporting the identity of other entities on which information is reported. Note that, in some situations, a manual configuration might be required to populate this information. 7.3. Reporting Quantities AccumulatedOverover Multiple Entities The standard must provide means for reporting the list of all entities from which contributions are included in an accumulated value. 7.4. ListOfof All EntitiesOnon Which Information Is Reported For entities that report on one or more other entities, the standard must provide means for reporting the complete list of all those entities on whichEnergy-relatedenergy-related information can be reported. 7.5. ContentOfof ReportsOnon Other Entities For entities that report on one or more other entities, the standard must provide means for indicatingwhich Energy-relatedwhat type or types of energy- related information can bereportedreported, and for whichof thoseentities. 8. Controlling Other Entities This section specifies requirements for controlling Power States and power supply of entities by communicating with other entities that have the means for doing that control. 8.1. Controlling Power StatesOfof Other Entities Some entities have control over Power States of other entities. Forexampleexample, a gateway to a building system may have the means to control the Power State of entities in the building that do not have an IP interface. For this scenario and other similarcases means are neededcases, a way to make this control accessible to the Energy ManagementSystem.System is needed. Inaddition to this,addition, it is required that an entity that has its state controlled by other entities has the means to report the list of these other entities. 8.1.1. ControlOfof Power StatesOfof Other Entities The standard must provide means for an Energy Management System to send Power State control commands to an entity thatconcerncontrols the Power States of entities other than theoneentity to which the command wassent to.sent. 8.1.2. IdentityOfof Other Power State Controlled Entities The standard must provide means for reporting the identities of the entities for which the reporting entity has the means to control their Power States. Note that, in some situations, a manual configuration might be required to populate this information. 8.1.3. ListOfof All Power State Controlled Entities The standard must provide means for an entity to report the list of all entities for which it can control the Power State. 8.1.4. ListOfof All Power State Controllers The standard must provide means for an entity that receives commands controlling its Power State from other entities to report the list of all those entities. 8.2. Controlling Power Supply Some entities may have control of thePowerpower supply of other entities, for example, because the other entity is supplied via a Power Outlet of the entity. For this and similarcasescases, means are needed to make this control accessible to the Energy Management System. This need is already addressed by the requirement in Section 6.2. In addition, it is required that an entity that has its supply controlled by other entities has the means to report the list of these other entities. This need is already addressed by requirements in Sections 5.2.3 and 5.2.4. 9. Security Considerations Controlling Power State andPowerpower supply of entities are considered highly sensitiveactionsactions, since they can significantly affect the operation of directly and indirectlyaffectedconnected devices.ThereforeTherefore, all control actions addressed insectionsSections 6 and 8 must be sufficiently protected through authentication, authorization, and integrity protection mechanisms. Entities that are not sufficiently secure to operate directly on the public Internet do exist and can be a significant cause of risk, for example, if the remote control functions described insectionsSections 6 and 8 can be exercised on those devices from anywhere on the Internet. The standard needs to provide means for dealing with such cases. One solution is providing means that allowforthe isolation of such devices,e.g.e.g., behind a sufficiently secured gateway. Another solution isallowingto allow compliant implementationsthat have disabledto disable sensitive functions, or to notimplemented sensitive functions. Monitoring Energy-relatedimplement such functions at all. The monitoring of energy-related quantities of an entity as addressed in Sections 5-through 8 can be used to derive more information than just the received and providedEnergy, soenergy; therefore, monitored data requires protection. This protection includes authentication and authorization of entities requesting access to monitored data as well as confidentiality protection during transmission of monitored data. Privacy of stored data in an entity must be taken into account. Monitored data may be used as input to control, accounting, and other actions, so integrity of transmitted information and authentication of the origin may be needed. 9.1. Secure Energy Management The standard must provide privacy, integrity, and authentication mechanisms for all actions addressed in Sections 5-through 8. The security mechanisms must meet the security requirementselaborateddetailed in Section 1.4 of [RFC3411]. 9.2. IsolationOfof Insufficiently Secure Entities The standard must provide means to allowforthe isolation of entities thatthatare not sufficiently secure to operate on the public Internet, e.g., behind a gateway thatdoes implementimplements sufficient securitysothat the vulnerable entities are not directly exposed to the Internet. 9.3. Optional RestrictionOfof Functions The standard must allowforcompliant implementationsthat doto disable sensitive functions, or to not implementsensitivesuch functionsor disable themat all, when operating in environments that are not sufficientlysecured environments.secured. This applies particularly to the control functions described insectionsSections 6 and 8. 10.IANA Considerations This document has no actions for IANA. 11.Acknowledgments The authors would like to thank Ralf Wolter for his first essay on thisdraft.document. Many thanks to William Mielke, John Parello, JinHyeock Choi, Georgios Karagiannis, and Michael Suchoff for their helpful comments on thedraft.document. Many thanksfor their IESG reviewsto Stephen Farrell, Robert Sparks, Adrian Farrel, Barry Leiba, Brian Haberman, Peter Resnick, Sean Turner, Stewart Bryant, and RalphDroms.Droms for their IESG reviews. Finally, special thanks to the documentshepherdshepherd, Nevil Brownlee, and to the EMAN working group chairs: Nevil Brownlee and Bruce Nordman.12.11. References12.1.11.1. Normative References[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", RFC 3621, December 2003. [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005.[ANSI-TIA-1057] Telecommunications Industry Association,, "ANSI- TIA-1057-2006 - TIAANSI- TIA-1057-2006, "TIA Standard--- Telecommunications--- IP Telephony Infrastructure--- Link Layer Discovery Protocol for Media EndpointDevices ",Devices", April 2006.[IEEE-100] IEEE, , "Authoritative Dictionary of IEEE Standards Terms, IEEE 100, Seventh Edition ", December 2000.[IEC.61850-7-4] International Electrotechnical Commission, "Communication networks and systems for power utility automation -- Part 7-4: Basic communication structure -- Compatible logical node classes and data object classes", March 2010. [IEC.62053-21] International Electrotechnical Commission,,"Electricity metering equipment (a.c.)--- Particular requirements--- Part22:21: Static meters for active energy (classes 1 and2) ",2)", January 2003. [IEC.62053-22] International Electrotechnical Commission,,"Electricity metering equipment (a.c.)--- Particular requirements--- Part 22: Static meters for active energy (classes 0,2 S and 0,5S) ",S)", January 2003.[IEC.61850-7-4] International Electrotechnical Commission, , "Communication networks and systems for power utility automation - Part 7-4: Basic communication structure - Compatible logical node classes and data object classes ", 2010.[IEEE-100] IEEE, "The Authoritative Dictionary of IEEE Standards Terms, IEEE 100, Seventh Edition", December 2000. [IEEE-1621] Institute of Electrical and Electronics Engineers,,"IEEEP1621-2004 -Draft1621-2004 - IEEE Standard for User Interface Elements in Power Control of Electronic Devices Employed inOfficeOffice/ ConsumerEnvironments ", June 2005.Environments", 2004. [IEEE-802.1AB] IEEE Computer Society,,"IEEE Std 802.1AB-2009--- IEEE Standard for Local andmetropolitan area networks -Metropolitan Area Networks -- Station and Media Access ControlDiscovery ",Discovery", September 2009.12.2.[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", RFC 3621, December 2003. [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. Chandramouli, "Entity MIB (Version 4)", RFC 6933, May 2013. 11.2. Informative References [EMAN-STATEMENT] Schoening, B., Chandramouli, M., and B. Nordman, "Energy Management (EMAN) Applicability Statement", Work in Progress, April 2013. [IEC.60050] International Electrotechnical Commission, "Electropedia: The World's Online Electrotechnical Vocabulary", 2013, <http://www.electropedia.org/iev/iev.nsf/ welcome?openform>. [ITU-M.3400] International Telecommunication Union, "ITU-T Recommendation M.3400 -- Series M: TMN and Network Maintenance: International Transmission Systems, Telephone Circuits, Telegraphy, Facsimile and Leased Circuits -- Telecommunications Management Network - TMN management functions", February 2000. [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008. [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.[I-D.ietf-eman-applicability-statement] Schoening, B., Chandramouli, M., and B. Nordman, "Energy Management (EMAN) Applicability Statement", draft-ietf- eman-applicability-statement-03 (work in progress), April 2013. [Fed-Std-1037C] United States National Communications System Technology and Standards Division, , "Federal Standard 1037C - Telecommunications: Glossary of Telecommunication Terms ", August 1996. [IEC60050] , "International Electrotechnical Vocabulary. http://www.electropedia.org/iev/iev.nsf/welcome?openform ", . [ITU-M.3400] International Telecommunication Union, , "ITU-T Recommendation M.3400 - Series M: TMN and Network Maintenance: International Transmission Systems, Telephone Circuits, Telegraphy, Facsimile and Leased Circuits - Telecommunications Management Network - TMN management functions ", February 2000.Authors' Addresses Juergen Quittek (editor) NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342-115Email:EMail: quittek@neclab.eu Mouli Chandramouli Cisco Systems, Inc. Sarjapur Outer Ring Road Bangalore India Phone: +91 80 4426 3947Email:EMail: moulchan@cisco.com Rolf Winter NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342-121Email:EMail: Rolf.Winter@neclab.eu Thomas Dietz NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342-128Email:EMail: Thomas.Dietz@neclab.eu Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1831 Belgium Phone: +32 2 704 5622Email:EMail: bclaise@cisco.com