From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6988.txt | 1571 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1571 insertions(+) create mode 100644 doc/rfc/rfc6988.txt (limited to 'doc/rfc/rfc6988.txt') diff --git a/doc/rfc/rfc6988.txt b/doc/rfc/rfc6988.txt new file mode 100644 index 0000000..40a5e45 --- /dev/null +++ b/doc/rfc/rfc6988.txt @@ -0,0 +1,1571 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Quittek, Ed. +Request for Comments: 6988 NEC Europe Ltd. +Category: Informational M. Chandramouli +ISSN: 2070-1721 Cisco Systems, Inc. + R. Winter + T. Dietz + NEC Europe Ltd. + B. Claise + Cisco Systems, Inc. + September 2013 + + + Requirements for Energy Management + +Abstract + + This document defines requirements for standards specifications for + Energy Management. The requirements defined in this document are + concerned with monitoring functions as well as control functions. + Monitoring functions include identifying energy-managed devices and + their components, as well as monitoring their Power States, Power + Inlets, Power Outlets, actual power, Power Attributes, received + energy, provided energy, and contained batteries. Control functions + include such functions as controlling power supply and Power 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 for Energy Management. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the 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 a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6988. + + + + + + +Quittek, et al. Informational [Page 1] + +RFC 6988 Requirements for Energy Management September 2013 + + +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 ....................................................3 + 1.1. Conventional Requirements for Energy Management ............3 + 1.2. Specific Requirements for Energy Management ................4 + 2. Terminology .....................................................5 + 3. General Considerations Related to Energy Management .............6 + 3.1. Power States ...............................................7 + 3.2. Saving Energy versus Maintaining Service Level .............7 + 3.3. Local versus Network-Wide Energy Management ................7 + 3.4. Energy Monitoring versus Energy Saving .....................8 + 3.5. Overview of Energy Management Requirements .................8 + 4. Identification of Entities ......................................9 + 5. Information on Entities ........................................10 + 5.1. General Information on Entities ...........................10 + 5.2. Power Interfaces ..........................................11 + 5.3. Power .....................................................13 + 5.4. Power State ...............................................15 + 5.5. Energy ....................................................17 + 5.6. Battery State .............................................18 + 5.7. Time Series of Measured Values ............................19 + 6. Control of Entities ............................................21 + 7. Reporting on Other Entities ....................................21 + 8. Controlling Other Entities .....................................22 + 8.1. Controlling Power States of Other Entities ................22 + 8.2. Controlling Power Supply ..................................23 + 9. Security Considerations ........................................23 + 10. Acknowledgments ...............................................25 + 11. References ....................................................25 + 11.1. Normative References .....................................25 + 11.2. Informative References ...................................26 + + + + + +Quittek, et al. Informational [Page 2] + +RFC 6988 Requirements for Energy Management September 2013 + + +1. Introduction + + With rising energy costs and an increasing awareness of the + ecological impact of running information technology equipment, Energy + 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 for + Energy Management, both monitoring functions and control functions. + Energy Management functions focus mainly on devices and their + components that receive and provide electrical energy. Devices such + as hosts, routers, and middleboxes may have an IP address or may be + connected indirectly to the Internet via a proxy with an IP address + providing a management interface for the device, for example, devices + in a building infrastructure using non-IP protocols and a gateway to + the Internet. + + These requirements are 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 by Standards + Track document(s) and not in this document. + + Section 3 elaborates on a set of general needs for Energy Management. + Requirements for an Energy Management standard are specified in + Sections 4 through 8. + + Sections 4 through 6 contain conventional requirements specifying + information on entities and control functions. + + Sections 7 and 8 contain requirements specific to Energy Management. + Due to the nature of power supply, some monitoring and control + functions are not conducted by interacting with the entity of + interest but rather with other entities, for example, entities + upstream in a power distribution tree. + +1.1. Conventional Requirements for Energy Management + + The specification of requirements for an Energy Management standard + starts with Section 4, 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. + + + + +Quittek, et al. Informational [Page 3] + +RFC 6988 Requirements for Energy Management September 2013 + + + 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, energy, and batteries. The control of Power State and power + supply by entities is covered by requirements specified in Section 6. + +1.2. Specific Requirements for Energy Management + + While the conventional requirements summarized above seem to be all + that would be needed for Energy Management, there are significant + differences between Energy Management and most well-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 particular entity, it is not always sufficient to + communicate only with that entity. When the entity has no + instrumentation for determining power, it might still be possible + to obtain power values for the entity via communication with other + entities in its power distribution tree. A simple example of this + would be the retrieval of power values from a power meter at the + power line into the entity. A Power Distribution Unit (PDU) and a + Power over Ethernet (PoE) 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 of an + entity that 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 off at their sockets or ports, + respectively. + + o Energy Management often extends beyond entities with IP network + interfaces to non-IP building systems accessed via a gateway + (sometimes called an Energy Management System or controller). + Requirements in this document do not cover the details of these + networks and energy devices but specify means for opening IP + network management towards them. + + These specific issues of Energy Management, as well as other issues, + are covered by requirements specified in Sections 7 and 8. + + The requirements in these sections need a new Energy Management + framework that deals with the specific nature of Energy Management. + The actual standards documents, such as MIB module specifications, + address conformance by specifying which features must, should, or may + be implemented by compliant implementations. + + + +Quittek, et al. Informational [Page 4] + +RFC 6988 Requirements for Energy Management September 2013 + + +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 + + Energy is the capacity of a system to do work. As used by + electric utilities, it is generally a reference to electrical + energy and is measured in kilowatt-hours (kWh) [IEEE-100]. + + Power + + Power is the time rate at which energy 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 Attributes are measurements of electric current, voltage, + phase, and frequencies at a given point in an electrical power + system (adapted from [IEC.60050]). + + NOTE: Power Attributes are not intended to be "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 Energy Management. + + + + + + + + +Quittek, et al. Informational [Page 5] + +RFC 6988 Requirements for Energy Management September 2013 + + + 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 and Power State of network elements, as + well as attached devices and their components. + + Power Interface + + A Power Interface is an interface at which a device is connected + to a power transmission medium, at which it can in turn receive + power, provide power, or both. + + Power Inlet + + A Power Inlet is a Power Interface at which a device can receive + power from other devices. + + Power Outlet + + A Power Outlet is a Power Interface at which a device can provide + power to other devices. + + Power State + + A Power State is a condition or mode of a device that broadly + characterizes its capabilities, power consumption, and + responsiveness to input [IEEE-1621]. + +3. General Considerations Related to Energy Management + + The basic objective of Energy Management is to operate sets of + devices using minimal energy, while maintaining a certain level of + service. [EMAN-STATEMENT] presents the applicability of the EMAN + framework to a variety of scenarios and also lists use cases and + target devices. + + + + + + + + + + +Quittek, et al. Informational [Page 6] + +RFC 6988 Requirements for Energy Management September 2013 + + +3.1. Power States + + Entities can be set to an operational state that results in the + lowest power level that still meets the service-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 (not functional but immediately available) + + o off state (may require significant time to become operational) + + In specific devices, the number of Power States and their properties + vary considerably. Simple entities may only have the extreme states: + full Power 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 low + Power 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 Energy versus Maintaining Service Level + + One of the objectives of Energy Management is to reduce energy + consumption. While this objective is clear, attaining that goal is + often difficult. In many cases, there is no way to reduce power + without the consequence of a potential service (performance or + capacity) degradation. In this case, a trade-off needs to be made + between service-level objectives and energy minimization. In other + cases, a reduction of power can easily be achieved while still + maintaining sufficient service-level performance, for example, by + switching entities to lower Power States when higher performance is + not needed. + +3.3. Local versus Network-Wide Energy Management + + Many energy-saving functions are executed locally by an entity; it + monitors its usage and dynamically adapts its power according to the + required performance. It may, for example, switch to a sleep state + when it is not in use, or outside of scheduled business hours. An + Energy Management System may observe an entity's Power State and + configure its power-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 the power received and provided by + + + + +Quittek, et al. Informational [Page 7] + +RFC 6988 Requirements for Energy Management September 2013 + + + entities in different Power States may be required in order to set + such policies. Often, this information is best acquired through + monitoring. + + Network-wide and local Energy Management methods both have advantages + and disadvantages, and it 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 for power-saving measures based on local + observations, such as the high or low functional load of an entity. + +3.4. Energy Monitoring versus Energy Saving + + Monitoring energy, power, and Power States alone does not reduce the + energy needed to run an entity. In fact, it may even increase it + slightly due to monitoring instrumentation that needs energy. + Reporting measured quantities over the network may also increase + energy use, though the acquired information may be an essential input + to control loops that save energy. + + Monitoring energy and Power States can also be required for other + purposes, including: + + o investigating energy-saving potential + + o evaluating the effectiveness of energy-saving policies and + measures + + o deriving, implementing, and testing power management strategies + + o accounting for the total power received and provided by an entity, + a network, or a service + + o predicting an entity's reliability based on power usage + + o choosing the time of the next maintenance cycle for an entity + +3.5. Overview of Energy Management Requirements + + The following basic management functions are required: + + o monitoring Power States + + o monitoring power (energy conversion rate) + + o monitoring (accumulated) received and provided energy + + + + +Quittek, et al. Informational [Page 8] + +RFC 6988 Requirements for Energy Management September 2013 + + + o monitoring Power Attributes + + o setting Power States + + Power control is complementary to other energy-saving measures, such + as low-power electronics, energy-saving protocols, energy-efficient + device design (for example, low-power modes for components), and + energy-efficient network architectures. Measurement of received and + provided energy can provide useful data for developing these + technologies. + +4. Identification of Entities + + Entities must be capable of being uniquely identified within 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. + The ability to control individual components to save energy may be + required. For example, server blades can be switched off when the + overall load is low, 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 the Link Layer Discovery Protocol + (LLDP) MIB module [IEEE-802.1AB] and the Link Layer Discovery + Protocol -- Media Endpoint Discovery (LLDP-MED) MIB module + [ANSI-TIA-1057] for devices, and the Entity MIB module [RFC6933] and + the power Ethernet MIB [RFC3621] for components of devices. Energy + Management needs a means to link energy-related information to such + identifiers. + + Instrumentation for measuring the received and provided energy 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 provided energy 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. + + + +Quittek, et al. Informational [Page 9] + +RFC 6988 Requirements for Energy Management September 2013 + + +4.2. Persistence of Identifiers + + The standard must provide means for indicating whether identifiers of + entities are persistent across a restart of the entity. + +4.3. Change of Identifiers + + The standard must provide means to indicate any change of entity + identifiers. + +4.4. Using Entity Identifiers of Existing MIB Modules + + The standard must provide means for reusing entity identifiers from + existing standards, including at least the following: + + o the entPhysicalIndex in the Entity MIB module [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 for reusing other entity identifiers must be provided. + +5. Information on 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. The monitoring of power and + energy 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 Information on Entities + + For Energy Management, understanding the role and context of an + entity may be required. An Energy Management System may aggregate + values of received and provided energy according to a defined + grouping of entities. When controlling and setting Power States, it + may be helpful to understand the grouping of the entity and role of + + + + +Quittek, et al. Informational [Page 10] + +RFC 6988 Requirements for Energy Management September 2013 + + + an entity in a network. For example, it may be important to exclude + some mission-critical network devices from being switched to lower + power or even from being switched off. + +5.1.1. Type of Entity + + The standard must provide means to configure, retrieve, and report a + textual name or a description of an entity. + +5.1.2. Context of 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. Significance of 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 reporting power + priorities of entities. Power priorities indicate an order in which + Power States of entities are changed, for example, to lower Power + States for saving power. + +5.1.5. Grouping of Entities + + The standard must provide means for grouping entities. This can be + achieved in multiple ways, for example, by providing means to tag + entities, assign them to domains, or assign device types to them. + +5.2. Power Interfaces + + A Power Interface is an interface at which a device is connected to a + power transmission medium, at which it can in turn receive power, + provide 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. However, most Power Interfaces never change. + + Devices have Power Inlets at which they are supplied with electric + power. Most devices have a single Power Inlet, while some have + multiple inlets. Different Power Inlets on a device are often + connected to separate power distribution trees. For Energy + + + +Quittek, et al. Informational [Page 11] + +RFC 6988 Requirements for Energy Management September 2013 + + + Monitoring, it is useful to retrieve information on the number of + inlets of a device, the availability of power at inlets, and which + inlets are actually in use. + + Devices can have one or more Power Outlets for supplying other + devices with electric power. + + For identifying and potentially controlling the source of power + received at an inlet, identifying the Power Outlet of another device + at which the received power is provided may be required. + Analogously, for each outlet, it is of interest to identify the Power + Inlets that receive the power provided at a certain outlet. Such + information is also required for constructing the wiring topology of + electrical power 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 that the 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. List of Power Interfaces + + The standard must provide means for monitoring the list of Power + Interfaces of a device. + +5.2.2. Operational Mode of Power Interfaces + + The standard must provide means for monitoring the operational mode + of a Power Interface, 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 the power 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 the power provided at a Power Outlet. + + + + + + + + + +Quittek, et al. Informational [Page 12] + +RFC 6988 Requirements for Energy Management September 2013 + + +5.2.5. Availability of Power + + If the Power States allow it, the standard must provide means for + monitoring the availability of power at each Power Interface. This + includes indicating whether a power supply at a Power Interface is + switched on or off. + +5.2.6. Use of Power + + The standard must provide means for monitoring each Power Interface + if it is actually in use. For inlets, this means that the device + actually receives power at the inlet. For outlets, this means that + power is actually provided from the outlet to one or more devices. + +5.2.7. Type of 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. Number of 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 for power and energy may be costly + if dedicated metering hardware is required. Entities without the + ability to measure with high accuracy their power, received energy, + and provided energy may just report estimated values, for example, + based on load monitoring, Power State, or even just the entity type. + + Depending on how power and energy values are obtained, the confidence + in a reported value and its accuracy will vary. Entities reporting + such values should qualify the confidence in the reported values and + + + +Quittek, et al. Informational [Page 13] + +RFC 6988 Requirements for Energy Management September 2013 + + + 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 the power supplied to a device are also of + interest. For AC power supply in particular, several Power + Attributes beyond the real power are of potential interest to Energy + Management Systems. The set of these properties includes the complex + Power Attributes (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 Power Attributes should be in line + with already-existing standards, such as [IEC.61850-7-4]. + + For some network management tasks, it is desirable to receive + notifications from entities when their power 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. Reporting power includes + reporting the direction of power flow. + +5.3.2. Power Measurement Interval + + The standard must provide means for reporting the corresponding time + or time interval for which a power value is reported. The power + 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 method used to obtain + these values. Based on how the measurement was conducted, it is + possible to associate a certain degree of confidence with the + reported power value. For example, there are methods of measurement + such as direct power measurement, estimation based on performance + values, or hard-coding average power values for an entity. + +5.3.4. Accuracy of Power and Energy Values + + The standard must provide means for reporting the accuracy of + reported power and energy values. + + + + + + +Quittek, et al. Informational [Page 14] + +RFC 6988 Requirements for Energy Management September 2013 + + +5.3.5. Actual Voltage and Current + + The standard must provide means for reporting the actual voltage and + actual current for each Power Interface as well as for a device. For + AC power supply, means must be provided for reporting the actual + voltage and actual current per phase. + +5.3.6. High-Power/Low-Power Notifications + + The standard must provide means for creating notifications if power + 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. In + addition to the real power, at least two of 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. + For AC power 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 of a + power supply for each Power Interface. For AC power 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 an entity and to + provide the means for retrieving the list of all supported Power + States. + + + + + + +Quittek, et al. Informational [Page 15] + +RFC 6988 Requirements for Energy Management September 2013 + + + 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 possibly use different Power State sets while + simultaneously interfacing with a particular entity, the Energy + Management System must provide means for supporting multiple Power + State sets used simultaneously at an entity. + + Power States have parameters that describe their properties. It is + required to have a standardized means for reporting some key + properties, such as the typical power of an entity in a certain + state. + + There is also a need to report statistics on Power States, including + the time spent as well as the received and provided energy 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. List of 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. List of 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. List of Supported Power States within 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 typical power for + each supported Power State. + + + +Quittek, et al. Informational [Page 16] + +RFC 6988 Requirements for Energy Management September 2013 + + +5.4.7. Power State Statistics + + The standard must provide means for monitoring statistics per Power + State, including the total time spent in a Power State, the number of + times each state was entered, and the last time each state was + entered. More Power State statistics are addressed by the + 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. Energy + + The monitoring of electrical energy received or provided by an entity + is a core function of Energy Management. Since energy 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 two timestamps in + the past. + + It is useful for entities to record their received and provided + energy per Power State and report these quantities. + +5.5.1. Energy Measurement + + The standard must provide means for reporting measured values of + energy and the direction of the energy flow received or provided by + an entity. The standard must also provide the means to report the + energy passing through each Power Interface. + +5.5.2. Time Intervals + + The standard must provide means for reporting the time interval for + which an energy value is reported. + +5.5.3. Energy Per Power State + + The standard must provide means for reporting the received and + provided energy for each individual Power State. This extends the + requirements on Power State statistics described in Section 5.4.7. + + + + + + + +Quittek, et al. Informational [Page 17] + +RFC 6988 Requirements for Energy Management September 2013 + + +5.6. Battery State + + Batteries are special entities that supply power. The status of + these batteries is typically controlled by automatic functions that + act locally on the entity, 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 which energy-related + information is reported, or the battery can be modeled as an + individual entity for which energy-related information is monitored + individually according to requirements in Sections 5.1 through 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, and additional 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 of milliampere-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 Battery Temperature + + The standard must provide means for reporting the actual temperature + of a battery. + + + + + + +Quittek, et al. Informational [Page 18] + +RFC 6988 Requirements for Energy Management September 2013 + + +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. Low Battery 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.1 through 5.6.8 for each + individual battery contained in a single entity. + +5.7. Time Series of Measured Values + + For some network management tasks, obtaining time series of measured + values from entities, such as power, energy, battery charge, etc., is + required. + + In general, 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)? + + + + + +Quittek, et al. Informational [Page 19] + +RFC 6988 Requirements for Energy Management September 2013 + + + The most discussed and probably most needed quantity is energy. But + a need for others, such as power and battery charge, can be + identified as well. + + There are three time interval types under discussion for accumulated + quantities such as energy. They can be reported as total values, + accumulated between the last restart of the measurement and a certain + timestamp. Alternatively, energy 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 as power, different measurement + methods are considered. Such quantities can be reported using values + sampled at certain timestamps or, alternatively, by mean values for + these quantities averaged between two (consecutive) timestamps 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 reporting power or energy values + using the IP Flow Information Export (IPFIX) protocol [RFC7011] + [RFC7012]. The Simple Network Management Protocol (SNMP) [RFC3411] + is an example of a protocol that can be used for realizing pull-based + reporting of time series. + + For reporting time series of measured values, 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 Series of Energy Values + + The standard must provide means for reporting time series of energy + 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. The 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. + + + + +Quittek, et al. Informational [Page 20] + +RFC 6988 Requirements for Energy Management September 2013 + + +6. Control of Entities + + Many entities control their Power State locally. Other entities need + interfaces for an Energy Management System to control their Power + State. + + A power supply is typically not self-managed by devices, 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 + providing power at its Power Outlets. Similar to Power State + control, power supply control may be policy driven. Note that + shutting down the power 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 switching a power supply off or + turning a power supply on at Power Interfaces providing power to one + or more devices. + +7. Reporting on Other Entities + + As discussed in Section 5, not all energy-related information may be + available at the entity in question. Such information may be + provided by other entities. This section covers only the reporting + of information. See Section 8 for requirements on controlling other + entities. + + There are cases where a power supply unit switches power for several + entities by turning power on or off at a single Power Outlet or where + a power meter measures the accumulated power 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 single entity but is + an accumulated value for a set of entities. All of the entities + belonging to that set need to be identified. + +7.1. Reports on Other Entities + + The standard must provide means for an entity to report information + on another entity. + + + + + + +Quittek, et al. Informational [Page 21] + +RFC 6988 Requirements for Energy Management September 2013 + + +7.2. Identity of Other Entities on 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 Accumulated over 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. List of All Entities on 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 which energy-related information can be reported. + +7.5. Content of Reports on Other Entities + + For entities that report on one or more other entities, the standard + must provide means for indicating what type or types of energy- + related information can be reported, and for which entities. + +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 States of Other Entities + + Some entities have control over Power States of other entities. For + example, 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 similar cases, a way to make + this control accessible to the Energy Management System is needed. + + In 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. + + + + + + + + + +Quittek, et al. Informational [Page 22] + +RFC 6988 Requirements for Energy Management September 2013 + + +8.1.1. Control of Power States of Other Entities + + The standard must provide means for an Energy Management System to + send Power State control commands to an entity that controls the + Power States of entities other than the entity to which the command + was sent. + +8.1.2. Identity of 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. List of 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. List of 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 the power supply of other entities, + for example, because the other entity is supplied via a Power Outlet + of the entity. For this and similar cases, 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 and power supply of entities are considered + highly sensitive actions, since they can significantly affect the + operation of directly and indirectly connected devices. Therefore, + all control actions addressed in Sections 6 and 8 must be + sufficiently protected through authentication, authorization, and + integrity protection mechanisms. + + + + + +Quittek, et al. Informational [Page 23] + +RFC 6988 Requirements for Energy Management September 2013 + + + 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 in Sections 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 allow the isolation of such devices, + e.g., behind a sufficiently secured gateway. Another solution is to + allow compliant implementations to disable sensitive functions, or to + not implement 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 provided energy; 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 requirements detailed in + Section 1.4 of [RFC3411]. + +9.2. Isolation of Insufficiently Secure Entities + + The standard must provide means to allow the isolation of entities + that are not sufficiently secure to operate on the public Internet, + e.g., behind a gateway that implements sufficient security that the + vulnerable entities are not directly exposed to the Internet. + +9.3. Optional Restriction of Functions + + The standard must allow compliant implementations to disable + sensitive functions, or to not implement such functions at all, when + operating in environments that are not sufficiently secured. This + applies particularly to the control functions described in Sections 6 + and 8. + + + + + + + + + +Quittek, et al. Informational [Page 24] + +RFC 6988 Requirements for Energy Management September 2013 + + +10. Acknowledgments + + The authors would like to thank Ralf Wolter for his first essay on + this document. Many thanks to William Mielke, John Parello, + JinHyeock Choi, Georgios Karagiannis, and Michael Suchoff for their + helpful comments on the document. Many thanks to Stephen Farrell, + Robert Sparks, Adrian Farrel, Barry Leiba, Brian Haberman, Peter + Resnick, Sean Turner, Stewart Bryant, and Ralph Droms for their IESG + reviews. Finally, special thanks to the document shepherd, Nevil + Brownlee, and to the EMAN working group chairs: Nevil Brownlee and + Bruce Nordman. + +11. References + +11.1. Normative References + + [ANSI-TIA-1057] + Telecommunications Industry Association, ANSI- + TIA-1057-2006, "TIA Standard -- Telecommunications -- IP + Telephony Infrastructure -- Link Layer Discovery Protocol + for Media Endpoint Devices", April 2006. + + [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 -- + Part 21: Static meters for active energy (classes 1 + and 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,5 S)", January 2003. + + [IEEE-100] IEEE, "The Authoritative Dictionary of IEEE Standards + Terms, IEEE 100, Seventh Edition", December 2000. + + [IEEE-1621] + Institute of Electrical and Electronics Engineers, + "IEEE 1621-2004 - IEEE Standard for User Interface + Elements in Power Control of Electronic Devices Employed + in Office/Consumer Environments", 2004. + + + +Quittek, et al. Informational [Page 25] + +RFC 6988 Requirements for Energy Management September 2013 + + + [IEEE-802.1AB] + IEEE Computer Society, "IEEE Std 802.1AB-2009 -- IEEE + Standard for Local and Metropolitan Area Networks -- + Station and Media Access Control Discovery", + September 2009. + + [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, + . + + [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. + + [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, + "Specification of the IP Flow Information Export (IPFIX) + Protocol for the Exchange of Flow Information", STD 77, + RFC 7011, September 2013. + + [RFC7012] Claise, B., Ed., and B. Trammell, Ed., "Information Model + for IP Flow Information Export (IPFIX)", RFC 7012, + September 2013. + + + + +Quittek, et al. Informational [Page 26] + +RFC 6988 Requirements for Energy Management September 2013 + + + [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network + Time Protocol Version 4: Protocol and Algorithms + Specification", RFC 5905, June 2010. + +Authors' Addresses + + Juergen Quittek (editor) + NEC Europe Ltd. + NEC Laboratories Europe + Network Research Division + Kurfuersten-Anlage 36 + Heidelberg 69115 + Germany + + Phone: +49 6221 4342-115 + EMail: quittek@neclab.eu + + + Mouli Chandramouli + Cisco Systems, Inc. + Sarjapur Outer Ring Road + Bangalore + India + + Phone: +91 80 4426 3947 + 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-121 + EMail: Rolf.Winter@neclab.eu + + + + + + + + + + + + + +Quittek, et al. Informational [Page 27] + +RFC 6988 Requirements for Energy Management September 2013 + + + Thomas Dietz + NEC Europe Ltd. + NEC Laboratories Europe + Network Research Division + Kurfuersten-Anlage 36 + Heidelberg 69115 + Germany + + Phone: +49 6221 4342-128 + EMail: Thomas.Dietz@neclab.eu + + + Benoit Claise + Cisco Systems, Inc. + De Kleetlaan 6a b1 + Diegem 1831 + Belgium + + Phone: +32 2 704 5622 + EMail: bclaise@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Quittek, et al. Informational [Page 28] + -- cgit v1.2.3