Getting Ready for Energy-Efficient Networking E. Stephan Internet-Draft Orange Intended status: Informational M. Palmero Expires: 10 May 2025 Cisco Systems, Inc. B. Claise Q. Wu Huawei L. M. Contreras Telefonica 6 November 2024 Requirements for Energy Efficiency Management draft-stephan-green-ucs-and-reqs-01 Abstract This document delineates the requirements for standards specifications in Energy Efficiency Management, extending the foundational work of RFC6988 and incorporating recent insights from operator requirements and the GREEN BoF discussions. Eleven years after the publication of RFC6988, this document reassesses and updates the requirements to align with contemporary needs. The primary objectives of this draft, which are listed in the goals and scope with the creation of the GREEN WG charter, is focusing on two main targets: (1) collecting and updating requirements for the management of energy-efficient networks, and (2) defining use cases for managing energy-efficient networks. This draft merges the drafts [rfc6988bis-green] and [green-bof-reqs]. Discussion Venues Source of this draft and an issue tracker can be found at https://github.com/emile22/draft-stephan-green-terms-ucs-and-reqs About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://emile22.github.io/draft-stephan-green-ucs-and-reqs/draft- stephan-green-ucs-and-reqs.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- stephan-green-ucs-and-reqs/. Stephan, et al. Expires 10 May 2025 [Page 1] Internet-Draft Requirements for Energy Efficiency November 2024 Discussion of this document takes place on the Getting Ready for Energy-Efficient Networking Working Group mailing list (mailto:green@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/green/. Subscribe at https://www.ietf.org/mailman/listinfo/green/. Source for this draft and an issue tracker can be found at https://github.com/emile22/draft-stephan-green-ucs-and-reqs. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any 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 10 May 2025. Copyright Notice Copyright (c) 2024 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Incremental Application of the GREEN Framework . . . . . 6 2.2. Selective reduction of energy consumption in network parts proportional to traffic levels . . . . . . . . . . . . . 8 Stephan, et al. Expires 10 May 2025 [Page 2] Internet-Draft Requirements for Energy Efficiency November 2024 2.3. Reporting on Lifecycle Management . . . . . . . . . . . . 10 2.3.1. Carbon Reporting . . . . . . . . . . . . . . . . . . 10 2.3.2. Energy Mix . . . . . . . . . . . . . . . . . . . . . 10 2.4. Real-time Energy Metering of Virtualised or Cloud-native Network Functions . . . . . . . . . . . . . . . . . . . . 11 2.5. Indirect Energy Monitoring and control . . . . . . . . . 11 2.6. Consideration of other domains for obtention of end-to-end metrics . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.7. Dynamic adjustment of network element throughput according to traffic levels in wireless transport networks . . . . 12 2.8. Video streaming use case . . . . . . . . . . . . . . . . 13 3. Requirements Extracted from Proponents Documents . . . . . . 14 4. EMAN Requirements from RFC6988bis . . . . . . . . . . . . . . 20 4.1. Conventional Requirements for Energy Efficiency Management . . . . . . . . . . . . . . . . . . . . . . . 20 4.2. General Considerations Related to Energy Management . . . 21 4.2.1. Power States . . . . . . . . . . . . . . . . . . . . 21 4.2.2. Saving Energy versus Maintaining Service Level . . . 22 4.2.3. Local versus Network-Wide Energy Management . . . . . 22 4.2.4. Energy Monitoring versus Energy Saving . . . . . . . 22 4.2.5. Overview of Energy Management Requirements . . . . . 23 4.3. Identification of Entities . . . . . . . . . . . . . . . 24 4.3.1. Identifying Entities . . . . . . . . . . . . . . . . 25 4.3.2. Identifying Entitiy Capabilities . . . . . . . . . . 25 4.3.3. Persistence of Identifiers . . . . . . . . . . . . . 25 4.3.4. Change of Identifiers . . . . . . . . . . . . . . . . 25 4.3.5. Using Entity Identifiers of Existing YANG Modules . . 25 4.4. Information on Entities . . . . . . . . . . . . . . . . . 26 4.4.1. General Information on Entities . . . . . . . . . . . 26 4.4.2. Power Interfaces . . . . . . . . . . . . . . . . . . 27 4.4.3. Power . . . . . . . . . . . . . . . . . . . . . . . . 29 4.4.4. Power State . . . . . . . . . . . . . . . . . . . . . 31 4.4.5. Energy . . . . . . . . . . . . . . . . . . . . . . . 32 4.4.6. Time Series of Measured Values . . . . . . . . . . . 34 4.5. Control of Entities . . . . . . . . . . . . . . . . . . . 35 4.5.1. Provisioning Power States . . . . . . . . . . . . . . 35 4.5.2. Controlling Power SupplyProvisioning . . . . . . . . 36 4.5.3. Controlling Switching Power Speed . . . . . . . . . . 36 4.5.4. Controlling Energy Saving and Optimization Functionalities . . . . . . . . . . . . . . . . . . . 36 4.6. Management of oultet Entities . . . . . . . . . . . . . . 36 4.6.1. Discovery of Power inlet Entities . . . . . . . . . . 36 4.6.2. Controlling Other Entities . . . . . . . . . . . . . 38 5. Framework Discussed During the BoF . . . . . . . . . . . . . 39 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41 6.1. Secure Energy Management . . . . . . . . . . . . . . . . 42 6.2. Isolation of Insufficiently Secure Entities . . . . . . . 42 6.3. Optional Restriction of Functions . . . . . . . . . . . . 42 Stephan, et al. Expires 10 May 2025 [Page 3] Internet-Draft Requirements for Energy Efficiency November 2024 6.4. Other Aspects . . . . . . . . . . . . . . . . . . . . . . 42 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 42 9.1. Open Issues to be Discussed at IETF121 . . . . . . . . . 43 9.2. Open Issues collected since the BoF . . . . . . . . . . . 43 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 10.1. Normative References . . . . . . . . . . . . . . . . . . 45 10.2. Informative References . . . . . . . . . . . . . . . . . 45 11. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 46 11.1. Terminology . . . . . . . . . . . . . . . . . . . . . . 46 11.2. In Preparation of the GREEN BoF at IETF 120 . . . . . . 48 11.3. High-level Differences with RFC6988 . . . . . . . . . . 49 12. Informative References . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 1. Introduction This document delineates the requirements for standards specifications in Energy Efficiency Management, extending the foundational work of RFC6988 and incorporating recent insights from operator requirements and the GREEN BoF discussions. Eleven years after the publication of RFC6988, this document reassesses and updates the requirements to align with contemporary needs. The primary objectives of this draft, which are listed in the goals and scope with the creation of the GREEN WG charter, is focusing on two main targets: (1) collecting and updating requirements for the management of energy-efficient networks, and (2) defining use cases for managing energy-efficient networks. This draft replaces the drafts [rfc6988bis-green] and [green-bof-reqs] and groups requirements from the documents of the GREEN WG proponents [charter-refinement], [operators-inputs], [GREEN-BOF], [sustainability-insights], [legacy-path] and [rfc6988bis-green]. The aim is to determine initial sets of requirements actionable at different levels of the framework presented below Section 5. Requirements are named and grouped in tables and are set with individual priority (to be) determined by the GREEN WG consensus. Section 2 groups the 'core' use cases. Several of them might not be relevant for the current charter. Section 3 recalls a set of requirements established after the BoF in [charter-refinement]. Stephan, et al. Expires 10 May 2025 [Page 4] Internet-Draft Requirements for Energy Efficiency November 2024 Section 4 recalls [rfc6988bis-green] requirements which may fit to the GREEN WG. They still have to be grouped in tables and set with individual priorities. Section 5 recalls the raw framework discussed during the BoF to illustrate the segmentation of the requirements in three core functions: discovery, monitoring, and control. Discovery functions involve identifying energy-managed networks, devices, and their components, as well as discovering the inventory of power components capabilities, optimization control capabilities, and nominal condition use. Monitoring functions encompass tracking power states, power attributes, energy consumption, network performance, and energy efficiency metrics. Control functions include managing energy-saving and optimization functions and the power states of energy-managed devices and their components. Terms and definitions, mostly from RFC6988, related to energy efficiency metrics are recalled in Appendix and will be discussed in later stages for potential integration in another GREEN WG document. 1.1. Background With rising energy costs and an increasing awareness of the environmental impact of running information technology equipment, Energy efficiency Management functions and management 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 efficiency Management, including discovery functions, monitoring functions and control functions. Energy efficiency Management functions focus mainly on network devices and their built- in components that receive and provide electrical energy. Devices such as switches, routers, servers and storage devices should have an IP address providing a management interface for the network device. Alternatively, energy-related devices (for example, in building management, which typically don't support IP) might be connected via a proxy/gateway with an IP address. 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. Stephan, et al. Expires 10 May 2025 [Page 5] Internet-Draft Requirements for Energy Efficiency November 2024 2. Use Cases This section describes a number of relevant use cases with the purpose of elicit requirements for Energy Efficiency Management. This is a work in progress and additional use cases will be documented in next versions of this document. Use cases which are not tied enough to the current GREEN chater will be moved to the GREEN WG wiki pages or to other WGs or RGs. 2.1. Incremental Application of the GREEN Framework This section describes an incremental example [legacy-path] of usage showing how a product, a service and a network can use the framework in different settings. This use case is the less trendy of all the use cases by far as its ambitious is limited to migration and coexistence, as usual. Nevertheless from a telco perspective, it is the centrality for 2 main reasons: * to start immediatly the move to energy efficiency using legacy devices; * to account the gain of the move one started; Once upon a time there was an very old legacy router named Rusty equipped with outdated ethernet and ugly optical interfaces. Despite his worn-out appearance, Rusty was determined to contribute to the energy efficiency effort. He dreamed of finding a way to optimize his old circuits and help reduce the power consumption of the network he had faithfully served for so many years. Though he was no longer in his prime, Rusty believed that even an old router like him could make a difference in a world striving for sustainability and help reduce the carbon footprint. He is convince that he still had a part to play in making the digital world a greener place. Device moving gradually to GREEN energy efficiency support: * step 1 "baseline" : establishing a reference point of typical energy usage, which is crucial for identifying inefficiencies and measuring improvements over time. At this step the controler use only the (c) part of the framework. It is collected from the datasheet. By establishing a baseline and using benchmarking, you can determine if your networking equipment is performing normally or if it is "off" from expected performance, guiding you in making necessary improvements. Stephan, et al. Expires 10 May 2025 [Page 6] Internet-Draft Requirements for Energy Efficiency November 2024 The initial measurement of your networking equipment's energy efficiency and performance, aka Baselining, needs to be in coordination with the vendor specifications and industry standards to understand what is considered normal or optimal performance. example: Baseline: Your switches operate at 5 Gbps per watt. Benchmarking: Vendor specification is 8 Gbps per watt; industry standard is 10 Gbps per watt. Action: Implement energy-saving measures and upgrades. Tracking: Measure again to see if efficiency improves towards 8-10 Gbps per watt. * step 2 "component": part of the device hw or sw migrated to support GREEN framework elements. * step 3 "device controleur" * step 4 "network level" For this use case, the following requirements apply : +=============+===============+==================+=========+========+ | id | category | requirements |note |Priority| +=============+===============+==================+=========+========+ | Req01-UCINC | Discovery | Component |Per |1 | | | | granularity, |component| | | | | e.g., per line- | | | | | | card, per-port | | | +-------------+---------------+------------------+---------+--------+ | Req02-UCINC | Observability | Availability of |Related |1 | | | | information on |to | | | | | the power |connected| | | | | consumption of |device | | | | | the device, |case | | | | | without needing | | | | | | instrumentation | | | | | | connected to | | | | | | the | | | | | | infrastructure | | | +-------------+---------------+------------------+---------+--------+ | Req03-UCINC | Analysis | Common |Standard |1 | | | | definition of |metric | | | | | energy | | | | | | efficiency in | | | | | | network | | | | | | devices/ | | | | | | components | | | +-------------+---------------+------------------+---------+--------+ | Req04-UCINC | Inventory | component |Per |1 (i) | | | Management | control |component| | Stephan, et al. Expires 10 May 2025 [Page 7] Internet-Draft Requirements for Energy Efficiency November 2024 | | | capacity (aka |control | | | | | component max | | | | | | power-on/power- | | | | | | off frequency | | | | | | supported) | | | +-------------+---------------+------------------+---------+--------+ | Req05-UCINC | Analysis | assess the |Device |1 (ii) | | | | gains of |Level | | | | | introducing |Mgmt | | | | | eco-designed | | | | | | components in a | | | | | | device | | | +-------------+---------------+------------------+---------+--------+ | Req06-UCINC | Control& Mgmt | comprehensive |Network |1 (iii) | | | | support of |Level | | | | | network-wide |Mgmt | | | | | energy | | | | | | efficiency | | | | | | includes legacy | | | | | | devices | | | +-------------+---------------+------------------+---------+--------+ Table 1 (i) Avoid a power-on/power-off frequency to break component parts (aka laser, power parts, wire connectors ...) (ii) the gain must be measurable (iii) network-wide energy efficiency solutions must include legacy devices and green-wg ready devices 2.2. Selective reduction of energy consumption in network parts proportional to traffic levels Traffic levels in a network follow patterns reflecting the behavior of consumers. Those patterns show periodicity in the terms of the traffic delivered, that can range from daily (from 00:00 to 23:59) to seasonal (e.g., winter to summer), showing peaks and valleys that could be exploited to reduce the consumption of energy in the network proportionally, in case the underlying network elements incorporate such capabilities. The reduction of energy consumption could be performed by leveraging on sleep modes in components up to more extreme actions such as switching off network components or modules. Such decisions are expected to no impact on the service delivered to customers, and could be accompanied by traffic relocation and / or concentration in the network. For this use case, the following requirements apply: Stephan, et al. Expires 10 May 2025 [Page 8] Internet-Draft Requirements for Energy Efficiency November 2024 +===========+===============+==================+===========+========+ |id | category | requirements |note |Priority| +===========+===============+==================+===========+========+ |Req01-UCRED| Observability | Component |Per |1 | | | | granularity, |component | | | | | e.g., per line- |measurement| | | | | card, per-port | | | +-----------+---------------+------------------+-----------+--------+ |Req02-UCRED| Observability | Availability of |Related to |1 | | | | information on |connected | | | | | the power |device case| | | | | consumption of | | | | | | the device, | | | | | | without needing | | | | | | instrumentation | | | | | | connected to | | | | | | the | | | | | | infrastructure | | | +-----------+---------------+------------------+-----------+--------+ |Req03-UCRED| Analysis | Common |Standard |1 | | | | definition of |metric | | | | | energy | | | | | | efficiency in | | | | | | network | | | | | | devices/ | | | | | | components | | | +-----------+---------------+------------------+-----------+--------+ |Req04-UCRED| Analysis | Ability of |POI Use |3 | | | | multi-layer |Case | | | | | analysis (e.g., | | | | | | IP plus | | | | | | optical) | | | +-----------+---------------+------------------+-----------+--------+ |Req05-UCRED| Control& Mgmt | To have devices |Dynamic |2 | | | | with elastic |Energy | | | | | power |Saving | | | | | consumption | | | | | | according to | | | | | | the carried | | | | | | traffic | | | +-----------+---------------+------------------+-----------+--------+ |Req06-UCRED| Control& Mgmt | Advanced sleep |Dynamic |2 | | | | mode, needing |Energy | | | | | some sort of |Saving | | | | | low power mode | | | | | | when node is | | | | | | lightly | | | | | | utilized | | | Stephan, et al. Expires 10 May 2025 [Page 9] Internet-Draft Requirements for Energy Efficiency November 2024 +-----------+---------------+------------------+-----------+--------+ |Req07-UCRED| Control& Mgmt | Ability to |Traffic |4 | | | | steer traffic |Engineering| | | | | based on power | | | | | | savings | | | +-----------+---------------+------------------+-----------+--------+ Table 2 2.3. Reporting on Lifecycle Management Lifecycle information related to manufacturing energy costs, transport, recyclability, and end-of-life disposal impacts is part of what is called "embedded carbon." This information is considered to be an estimated value, which might not be implemented today in the network devices. It might be part of the vendor information, and to be collected from datasheets or databases. In accordance with ISO 14040/44, this information should be considered as part of the sustainable strategy related to energy efficiency. Also, refer to the ecodesign framework [(EU) 2024/1781] published in June by the European Commission. 2.3.1. Carbon Reporting To report on carbon equivalents for global reporting, it is important to correlate the location where the specific entity/network element is operating with the corresponding carbon factor. Refer to the world emission factor from the International Energy Agency (IEA), electricity maps applications that reflect the carbon intensity of the electricity consumed, etc. 2.3.2. Energy Mix Energy efficiency is not limited to reducing the energy consumption, it is common to include carbon free, solar energy, wind energy, cogeneration in the efficiency. The type of the sources of energy of the power is one criteria of efficiency. There are other dimensions that must visible: As many telecom locations include battery or additionnally several backups levels (as example battery, standby generator ...) there is a requirement to known exactly when a backup power is in used and which one is. Stephan, et al. Expires 10 May 2025 [Page 10] Internet-Draft Requirements for Energy Efficiency November 2024 2.4. Real-time Energy Metering of Virtualised or Cloud-native Network Functions Facilitating more precise and real-time estimations of energy consumed by virtualised or cloud-native network functions. Effective metering of virtualized network infrastructure is critical for the efficient management and operation of next-generation mobile networks [GREEN_NGNM]. 2.5. Indirect Energy Monitoring and control 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 two 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. Also it could be considered to obtain power values for the entity via communication with other entities outside of the power distribution tree, like for example external databases or even data sheets. 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. 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. Stephan, et al. Expires 10 May 2025 [Page 11] Internet-Draft Requirements for Energy Efficiency November 2024 2.6. Consideration of other domains for obtention of end-to-end metrics The technologies under the scope of IETF provide the necessary connectivity to other technological domains. For the obtention of metrics end-to-end it would be required to combine or compose the metrics per each of those domains. An exemplary case is the one of a network slice service. The concept of network slice was initially defined by 3GPP [TS23.501], and it has been further extended to the concerns of IETF [RFC9543]. In regards energy efficiency, 3GPP defines a number of energy-related key performance indicators (KPI) in [TS28.554], specifically Energy Efficiency (EE) and Energy Consumption (EC) KPIs. There are KPIs particular for a slice supporting a specific kind of service (e.g., Mobile Broadband or MBB), or generic ones, like Generic Network Slice EE or Network Slice EC. Assuming these as the KPIs of interest, the motivation of this use case is the obtention of the equivalent KPIs at IETF level, that is, for the network slice service as defined in [RFC9543]. Note that according to [TS28.554], the Generic Network Slice EE is the performance of the network slice divided by the Network Slice EC. Same approach can be followed at IETF level. Note that for avoiding double counting the energy at IETF level in the calculation of the end-to-end metric, the 3GPP metric should only consider the efficiency and consumption of the 3GPP-related technologies. 2.7. Dynamic adjustment of network element throughput according to traffic levels in wireless transport networks Radio base stations are typically connected to the backbone network by means of fiber or wireless transport (e.g., microwave) technologies. In the specific case of wireless transport, automation frameworks have been defined [ONF-MW][RFC8432][mWT025] for their control and management. Stephan, et al. Expires 10 May 2025 [Page 12] Internet-Draft Requirements for Energy Efficiency November 2024 One of the parameters subject of automated control is the power of the radio links. The relevance of that capability is that the power can be adjusted accordingly to the traffic observed. Wireless transport networks are typically planned to support the maximum traffic capacity in their area of aggregation, that is, the traffic peak. With that input, the number of radio links in the network element and the corresponding power per radio link (for supporting a given modulation and link length in the worst weather conditions) are configured. This is done to avoid any kind of traffic loss in the worst operational situation. However, such operational needs are sporadic, giving room for optimization during normal operational circumstances and/or low traffic periods. Power-related parameters are for instance defined in [RFC8561]. Those power parameters can be dynamically configured to adjust the power to the observed traffic levels with some coarse granularity, but pursuing certain degrees of proportionality. 2.8. Video streaming use case Video streaming is nowadays the major source of traffic observed in ISP networks, in a propotion of 70% or even higher. Over-the-top distribution of streaming traffic is typically done by delivering a unicast flow per end user for the content of its interest.In consequence, during the hours of higher demand, the total traffic in the network is proportional to the concurrence of users consuming the video streaming service. The amount of traffic is also dependent of the resolution of the encoded video (the higher the resolution, the higher the bit rate per video flow), which tends to be higher as long as the users devices support such higher resolutions. The consequence of both the growth in the number of flows to be supported simultaneously, and the higher bit rate per flow, is that the nework elements in the path between the source of the video and the user have to be dimensioned accordingly. This implies the continuous upgrade of those network elements in terms of capacity, with the need of deploying high-capacity network elements and components. Apart from the fact that this process is shortening the lifetime of network elements, the need of high capacity interfaces also increase the energy consumption (despite the effort of manufacturers in creating more efficient network element platforms). Note that nowadays there is no actual possibility of activating energy consumption proportionality (in regards the delivered traffic) to such network elements. As a mean of slowing down this cycle of continuos renewal, and reduce the need og higher bit rate interfaces / line cards, it seems convenient to explore mechanisms that could reduce the volume of Stephan, et al. Expires 10 May 2025 [Page 13] Internet-Draft Requirements for Energy Efficiency November 2024 traffic without impacting the user service expectations. Variants of multicast or different service delivery strategies can help to improve the energy efficiency associated to the video streaming service. It should be noted that another front for optimization is the one related to the deployment of cache servers in the network. 3. Requirements Extracted from Proponents Documents This section extracts and groups requirements from the documents of the GREEN WG proponents [GREEN-BOF], [sustainability-insights], [legacy-path] and [rfc6988bis-green]. The aim is to determine initial sets of requirements actionable at different levels of the framework presented below Section 5. The table below groups the operator'requirements based on the inputs received from operators for the GREEN BoF [charter- refinement],[operators-inputs]. +========+==============+===================+==============+========+ |id |category |requirements |note |Priority| +========+==============+===================+==============+========+ |Req01-OP|Observability |Component |Per component |1 | | | |granularity, e.g., |measurement | | | | |per line-card, | | | | | |per-port | | | +--------+--------------+-------------------+--------------+--------+ |Req02-OP|Observability |Availability of |Related to |1 | | | |information on the |connected | | | | |power consumption |device case | | | | |of the device, | | | | | |without needing | | | | | |instrumentation | | | | | |connected to the | | | | | |infrastructure | | | +--------+--------------+-------------------+--------------+--------+ |Req03-OP|Observability |Triggering of |Alarm |1 | | | |alarms when |notification | | | | |consumption | | | | | |deviate from a | | | | | |nominal usage | | | +--------+--------------+-------------------+--------------+--------+ |Req04-OP|Observability |Improvement of |Standardized |1 | | | |metering solutions |metering | | | | |(finer | | | | | |granularity, | | | | | |control of the | | | | | |energy efficiency | | | | | |and saving, | | | Stephan, et al. Expires 10 May 2025 [Page 14] Internet-Draft Requirements for Energy Efficiency November 2024 | | |interoperability, | | | | | |exposure) | | | +--------+--------------+-------------------+--------------+--------+ |Req05-OP|Analysis |Common definition |Standard |1 | | | |of energy |metric | | | | |efficiency in | | | | | |network devices/ | | | | | |components | | | +--------+--------------+-------------------+--------------+--------+ |Req06-OP|Analysis |Common methodology |Standard |2 | | | |of measurements |methodology | | | | |for fair | | | | | |comparison | | | +--------+--------------+-------------------+--------------+--------+ |Req07-OP|Analysis |How to provide |Time based, |2 | | | |accurate figures |location based| | | | |(context of the |visualization | | | | |measurement in | | | | | |terms of time | | | | | |period, location, | | | | | |traffic, etc | | | +--------+--------------+-------------------+--------------+--------+ |Req08-OP|Analysis |Database for |Information |3 | | | |decision in case |Correlation | | | | |of large data | | | | | |transfer | | | +--------+--------------+-------------------+--------------+--------+ |Req09-OP|Analysis |Ability of multi- |POI Use Case |3 | | | |layer analysis | | | | | |(e.g., IP plus | | | | | |optical) | | | +--------+--------------+-------------------+--------------+--------+ |Req10-OP|Control& Mgmt |To have devices |Dynamic Energy|2 | | | |with elastic power |Saving | | | | |consumption | | | | | |according to the | | | | | |carried traffic | | | +--------+--------------+-------------------+--------------+--------+ |Req11-OP|Control& Mgmt |Support of |Network Level |2 | | | |network-wide |Mgmt | | | | |energy saving and | | | | | |optimization | | | | | |functions | | | +--------+--------------+-------------------+--------------+--------+ |Req12-OP|Control& Mgmt |Support of |Network Level |2 | | | |network-wide |Mgmt | | | | |control of energy | | | | | |optimization APIs, | | | Stephan, et al. Expires 10 May 2025 [Page 15] Internet-Draft Requirements for Energy Efficiency November 2024 | | |allowing external | | | | | |applications to | | | | | |optimize | | | | | |consumption | | | +--------+--------------+-------------------+--------------+--------+ |Req13-OP|Control& Mgmt |Advanced sleep |Dynamic Energy|2 | | | |mode, needing some |Saving | | | | |sort of low power | | | | | |mode when node is | | | | | |lightly utilized | | | +--------+--------------+-------------------+--------------+--------+ |Req14-OP|Control& Mgmt |Ability to steer |Traffic |4 | | | |traffic based on |Engineering | | | | |power savings | | | +--------+--------------+-------------------+--------------+--------+ |Req15-OP|Control& Mgmt |Comparison of |Intent based |2 | | | |decision vs |Concept | | | | |optimal case | | | +--------+--------------+-------------------+--------------+--------+ |Req16-OP|Control& Mgmt |Synchronous query |Network Level |2 | | | |support |Query | | +--------+--------------+-------------------+--------------+--------+ |Req17-OP|Inventory |Inventory of power |Component & |1 | | |Management |components (of |Device Level | | | | |devices, racks, | | | | | |etc) including | | | | | |together | | | +--------+--------------+-------------------+--------------+--------+ |Req18-OP|Interaction |Inclusion of data |Data Center |3 | | |with other |center networks in |Case | | | |domain |the picture | | | +--------+--------------+-------------------+--------------+--------+ |Req19-OP|Interaction |Inclusion of data |Mobile Network|3 | | |with other |center networks in |Case | | | |domain |the picture | | | +--------+--------------+-------------------+--------------+--------+ |Req20-OP|Sustainability|Optimize the |More renewable|4 | | |& Carbon |overall CO2 |energy | | | |Emission |footprint (i.e., | | | | | |energy mix based | | | | | |on source type) | | | | | |facilitating the | | | | | |engineering of PoP | | | | | |More renewable | | | | | |energy | | | +--------+--------------+-------------------+--------------+--------+ |Req21-OP|Sustainability|Support GHG units |Measurement |4 | | |& Carbon | |Units | | Stephan, et al. Expires 10 May 2025 [Page 16] Internet-Draft Requirements for Energy Efficiency November 2024 | |Emission | | | | +--------+--------------+-------------------+--------------+--------+ |Req22-OP|Sustainability|Support Energy |More renewable|2 | | |& Carbon |units |energy | | | |Emission | | | | +--------+--------------+-------------------+--------------+--------+ |Req23-OP|Sustainability|Accounting of |Accounting |4 | | |& Carbon |legacy installed |Cost | | | |Emission |based GHG/energy | | | +--------+--------------+-------------------+--------------+--------+ |Req24-OP|Sustainability|Track device/ |Manufacturing,|4 | | |& Carbon |network Energy |transport | | | |Emission |Consumption Before |(weight, | | | | |Operation |volume, | | | | | |package) | | +--------+--------------+-------------------+--------------+--------+ Table 3 The table below groups requirements from [rf988bis-green] draft Open Issues. TODO: this table has to be reviewed as it part of it overlaps with the sections above related to rfc6988 Stephan, et al. Expires 10 May 2025 [Page 17] Internet-Draft Requirements for Energy Efficiency November 2024 +===========+===============+================+=============+========+ | id | category | requirements | note |Priority| +===========+===============+================+=============+========+ | Req01-BIS | Control& Mgmt | Distinguish | rfc6988bis |2 | | | | backup from | battery(i) | | | | | main power | | | | | | sources | | | +-----------+---------------+----------------+-------------+--------+ | Req02-BIS | Inventory | Reporting on | Fit in |2 | | | Management | Other | "Inventory | | | | | Entities, | of power | | | | | typically | components | | | | | smart PDU or | (of | | | | | PoE | devices, | | | | | | racks, | | | | | | etc) | | | | | | including | | | | | | together" | | +-----------+---------------+----------------+-------------+--------+ | Req03-BIS | Observability | Room sensor | Data |4 | | | or | (hvac...) | Center | | | | Interaction | | Case | | | | with Other | | | | | | domain | | | | +-----------+---------------+----------------+-------------+--------+ | Req04-BIS | Observability | flexible | Standard |2 | | | | (future-proof) | metric | | | | | description of | | | | | | the nature of | | | | | | the sources of | | | | | | the energy | | | | | | used | | | +-----------+---------------+----------------+-------------+--------+ Table 4 (i) It is crucial to know when a device is powered by a backup source for many obvious reasons The table below groups requirements from [sustainability-insights] uses cases related to energy consumption vs sustainability +=========+===============+================+==============+========+ |id | category | requirements | note |Priority| +=========+===============+================+==============+========+ |Req01-SIS| Observability | Provide near- | Helps |2 | | | | real-time | identify | | | | | energy | which | | Stephan, et al. Expires 10 May 2025 [Page 18] Internet-Draft Requirements for Energy Efficiency November 2024 | | | consumption to | devices or | | | | | different | network | | | | | device types, | functions | | | | | service types, | are | | | | | and individual | consuming | | | | | users | more energy. | | +---------+---------------+----------------+--------------+--------+ |Req02-SIS| Migration or | Provide KPIs | Helps make | | | | Upgrade | for energy | informed | | | | | efficiency | decisions | | | | | parameters, | about | | | | | enhance | upgrades | | | | | accuracy of | based on | | | | | upgrade | actual usage | | | | | decisions | data. | | +---------+---------------+----------------+--------------+--------+ |Req03-SIS| Recycling | Report on | Major driver |4 | | | | percentage of | of the | | | | | recycled user | circular | | | | | devices and | economy, | | | | | components. | transparency | | | | | Enable | is key | | | | | comprehensive | | | | | | reporting and | | | | | | recycling | | | | | | efforts | | | +---------+---------------+----------------+--------------+--------+ |Req04-SIS| Power | Provide KPIs | Monitor |4 | | | Optimization | for energy | network and | | | | | efficiency | application | | | | | parameters. | performance | | | | | Perform | to optimize | | | | | actions to | power usage | | | | | reduce energy | | | | | | consumption | | | +---------+---------------+----------------+--------------+--------+ |Req05-SIS| Control& Mgmt | Stop and | Save power |2 | | | Switch off | restart WiFi | consumption | | | | | APs with the | during | | | | | right time, | periods when | | | | | space, and | APs are not | | | | | service | in use. | | | | | granularity | | | +---------+---------------+----------------+--------------+--------+ Table 5 Stephan, et al. Expires 10 May 2025 [Page 19] Internet-Draft Requirements for Energy Efficiency November 2024 4. EMAN Requirements from RFC6988bis TODO: This section will groups the subsections requirements in tables to prepare the room for establishing their individual consensus priority. This section groups the inputs of the work of RFC6988bis [rfc6988bis-green]. Currently they still include a lot of verbatim text from [rfc6988] which don't fit exactly in the granularity of the current GREEN WG charter. Specifications made by the IETF, aka in WGs like EMAN, on energy managements focus mainly on SMI (aka MIBs) instead of YANG and cover neither the control nor energy efficiency. By consequence all EMAN WG requirements might not be applicable to the GREEN WG charter as they can worded and arraged differently. As an example battery is in the scope as a source of power but the detail of the management of the battery is not a requirement. The goal is to enable the resuse pieces of the energy-related requirements of RFC6988 and to map them in a framework of YANG/ Netconf for energy efficiency that might reuse "YANG Data Model for Hardware Management" [RFC8348], a conversion of former Entity MIB module, Entity Sensor MIB module, Entity State MIB modules. Section 4.2 elaborates on a set of general needs for Energy Management. Requirements for an Energy Management standard are specified in Sections 4.3 through 4.6. Sections 4.4 through 4.5 contain conventional requirements specifying information on entities and control functions. Sections 4.6 contains 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. 4.1. Conventional Requirements for Energy Efficiency Management The specification of requirements for an Energy Efficiency Management standard starts with Section 4.3, 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 network, per entire device, and reporting energy-related information on individual components of a device or attached devices. Stephan, et al. Expires 10 May 2025 [Page 20] Internet-Draft Requirements for Energy Efficiency November 2024 Section 4.4 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. The control of Power State and power saving functionalities, optimization functionalities by entities is covered by requirements specified in Section 5.6. 4.2. General Considerations Related to Energy Management The basic objective of Energy Efficiency Management is to operate sets of network devices using minimal energy, while maintaining a certain level of service. 4.2.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 network 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 network devices have three basic Power States: on, off, and sleep. However, more finely grained Power States can be implemented, especially when Energy efficiency gains for communication systems are highly sought after, for environmental, business, and technical reasons. Examples are various operational low Power States in which a network 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. Another example is standby power state in which network device has multiple standby components and one active component for the same functionality, standby components are partially functional and can be immediately available when active component is down. The standby power state can be introduced to save energy while impove the overall network utilization. Stephan, et al. Expires 10 May 2025 [Page 21] Internet-Draft Requirements for Energy Efficiency November 2024 4.2.2. Saving Energy versus Maintaining Service Level One of the objectives of Energy Efficiency 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 (e.g., network performance) 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. To measure of the trade-off between service-level object and energy consumption, a new set of energy efficiency metrics needs to defined. 4.2.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 or backup state when it is not in use, or outside of scheduled business hours. An Energy Efficiency Management System may observe an entity's Power State and configure or optimize 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 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. 4.2.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. Stephan, et al. Expires 10 May 2025 [Page 22] Internet-Draft Requirements for Energy Efficiency November 2024 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 4.2.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 o monitoring Power Attributes o setting Power States In addition, to support energy efficiency management, additional requirements concerned with discovery functions and control functions are introduced: o discovering energy-managed network, devices and their components o discovering inventory of power components together with their capabilities, optimization control capabilities, nominal condition use o discovering supported power state of each network device within the network o discovering power relationship between component within network device and across network devices. Stephan, et al. Expires 10 May 2025 [Page 23] Internet-Draft Requirements for Energy Efficiency November 2024 o support additional energy efficiency metrics for energy efficiency monitoring, e.g., heat consumption, energy efficiency ratio, maximum wake up time, etc. o support separation of desired power state and actual power state and optimize energy usage to allow update actual power state to match desired power state. o Introduce energy saving method, and energy efficiency metrics to support explicit power control or energy efficiency optimization and control. o allow control and optimize energy usage to make the trade-off between network performance and power consumption. o support both local management and network wide management based on energy saving functionality. Energy usage control and optimization is complementary to other energy-saving design, such as low-power electronics, energy-efficient device design (for example, low-power modes for components), and energy-efficient network architectures and is exercised using management interface. Measurement of received and provided energy can provide useful data for energy efficiency management. 4.3. 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 or the entire network. 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 network, or network device or a component of it. Examples of components of interest are a hard drive, a fan, 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. Stephan, et al. Expires 10 May 2025 [Page 24] Internet-Draft Requirements for Energy Efficiency November 2024 Identifiers for network, network devices and components are already defined in standard YANG modules Network Topology YANG module [RFC8345] and Hardware YANG module [RFC8348]. Note that Network Topology YANG module [RFC8345] identifiers are reused in the Network Inventory YANG module [I-D.ietf-ivy-network-inventory-yang] and are also the basis for the Digital Map Modeling efforts in the NMOP Working Group. 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.3.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.3.2. Identifying Entitiy Capabilities The standard must provide means for discovering inventory of power components together with their capabilities, optimization control capabilities, nominal condition use. In addition, The standard must provide means for discovering supported power state of each network device within the network and power relationship between component within network device and across network devices. 4.3.3. Persistence of Identifiers The standard must provide means for indicating whether identifiers of entities are persistent across a restart of the entity. 4.3.4. Change of Identifiers The standard must provide means to indicate any change of entity identifiers. 4.3.5. Using Entity Identifiers of Existing YANG Modules The standard must provide means for reusing entity identifiers from existing standards, including at least the following: o the network-id, link-id, node-id, port-id of the Network Topology YANG module [RFC8345] Stephan, et al. Expires 10 May 2025 [Page 25] Internet-Draft Requirements for Energy Efficiency November 2024 o the ne-id, Universal Unique IDentifier (UUID) of the network element and component-id, UUID of each component within the network element in Network Inventory YANG module [I-D.ietf-ivy-network-inventory-yang] o the name, UUID of each hardware component in the Hardware YANG module [RFC8348] Generic means for reusing other entity identifiers must be provided. 4.4. 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. Finally, the reporting of time series of values is covered by Section 5.7. 4.4.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 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. 4.4.1.1. Type of Entity The standard must provide means to configure, retrieve, and report a textual name or a description of an entity. 4.4.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. Stephan, et al. Expires 10 May 2025 [Page 26] Internet-Draft Requirements for Energy Efficiency November 2024 4.4.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. 4.4.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. 4.4.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. 4.4.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. Network 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 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. Network 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 network 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. Stephan, et al. Expires 10 May 2025 [Page 27] Internet-Draft Requirements for Energy Efficiency November 2024 Static properties of each Power Interface are required information for Energy Efficiency 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). 4.4.2.1. List of Power Interfaces The standard must provide means for monitoring the list of Power Interfaces of a device. 4.4.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". 4.4.2.3. Corresponding Power Outlet The standard must provide means for identifying the Power Outlet that provides the power received at a Power Inlet. 4.4.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. 4.4.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. 4.4.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. 4.4.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. Stephan, et al. Expires 10 May 2025 [Page 28] Internet-Draft Requirements for Energy Efficiency November 2024 4.4.2.8. Nominal Voltage Range The standard must provide means for reporting the nominal voltage range for each Power Interface. 4.4.2.9. Nominal AC Frequency The standard must provide means for reporting the nominal AC frequency for each Power Interface. 4.4.2.10. Number of AC Phases The standard must provide means for reporting the number of AC phases for each Power Interface. 4.4.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 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. Stephan, et al. Expires 10 May 2025 [Page 29] Internet-Draft Requirements for Energy Efficiency November 2024 4.4.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. 4.4.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. 4.4.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. 4.4.3.4. Accuracy of Power and Energy Values The standard must provide means for reporting the accuracy of reported power and energy values. 4.4.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. 4.4.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. 4.4.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. Stephan, et al. Expires 10 May 2025 [Page 30] Internet-Draft Requirements for Energy Efficiency November 2024 4.4.3.8. Actual AC Frequency The standard must provide means for reporting the actual AC frequency for each Power Interface. 4.4.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. 4.4.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. 4.4.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. 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. 4.4.4.1. Actual Power State The standard must provide means for reporting the actual Power State of an entity. Stephan, et al. Expires 10 May 2025 [Page 31] Internet-Draft Requirements for Energy Efficiency November 2024 4.4.4.2. List of Supported Power States The standard must provide means for retrieving the list of all potential Power States of an entity. 4.4.4.3. Multiple Power State Sets The standard must provide means for supporting multiple Power State sets simultaneously at an entity. 4.4.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. 4.4.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. 4.4.4.6. Typical Power Per Power State The standard must provide means for retrieving the typical power for each supported Power State. 4.4.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. 4.4.4.8. Power State Changes The standard must provide means for generating a notification when the actual Power State of an entity changes. 4.4.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 Stephan, et al. Expires 10 May 2025 [Page 32] Internet-Draft Requirements for Energy Efficiency November 2024 the past. It is useful for entities to record their received and provided energy per Power State and report these quantities. In addition, it is also useful for entities to record energy attributes such as maximum wake up time, maximum sleep time, service interruption time, transition time, maximum packet throughput, maximum bit throughput and report these quantities. 4.4.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. 4.4.5.2. Energy Efficiency Measurement The standard must provide means for measuring the trade-off between service-level object and energy consumption. [ETSI-ES-203-136], [ITUT-L.1310], [ATIS-0600015.03.2013] provide methodology and test procedure for measuring such energy efficiency related metrics, which is defined as the throughput forwarded by 1 watt. The traffic loads and the weighted multipliers need to be clearly established in advance. Note that, based on the specific optimization policy (throughput, heat, energy source, etc.), different derived metrics should be computed at the controller level. 4.4.5.3. Power Gain Measurement The standard must provide means for measuring power gain, which can be calculated by actual power to be consumed by the entity divided by the maximum power of the entity. In addition, the minimum power gain can also be measured and reported. 4.4.5.4. Time Intervals The standard must provide means for reporting the time interval for which an energy value is reported. 4.4.5.5. 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. Stephan, et al. Expires 10 May 2025 [Page 33] Internet-Draft Requirements for Energy Efficiency November 2024 4.4.6. Time Series of Measured Values For some network management tasks, obtaining time series of measured values from entities, such as power, energy, 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)? The most discussed and probably most needed quantity is energy. But a need for others, such as power, 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 NETCONF protocol [RFC6241]. The NETCONF a protocol can also be used to realize pull-based reporting of time series. Stephan, et al. Expires 10 May 2025 [Page 34] Internet-Draft Requirements for Energy Efficiency November 2024 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. 4.4.6.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]). 4.4.6.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. 4.4.6.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. 4.5. 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. 4.5.1. Provisioning Power States The standard must provide means for provisioning Power States of entities. Stephan, et al. Expires 10 May 2025 [Page 35] Internet-Draft Requirements for Energy Efficiency November 2024 When an Energy Object is set to a particular Power State, the represented device or component may be busy. The Energy Object should set the desired Power State and then update the actual Power State when the device or component changes. The standard must provide means to report the intented and applied Power States, with the Network Management Datastore Architecture (NMDA) [RFC8342] 4.5.2. Controlling Power SupplyProvisioning 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. 4.5.3. Controlling Switching Power Speed The standard must provide means to avoid the speed of switching a power supply off or turning a power supply on to break component parts (aka laser, power parts, wire connectors ...), or a too hight number of on/off switching to reduce their live duration. 4.5.4. Controlling Energy Saving and Optimization Functionalities The standard must provide means for controlling energy saving and optimization functionalities and allocating the committed component resource (e.g., adjust fan speed, shutdown high speed interface) or committed device resource (e.g., multiple cards scheduling, multiple power module scheduling). In addition, the standard must provide means to support both local management and network wide management based on energy saving functionality. 4.6. Management of oultet 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 groups the requirements for the discovery, the reporting and the control of information. The intend is to summarize them in a table in section 9. 4.6.1. Discovery of Power inlet Entities Energy consumption must not be accounted twice Stephan, et al. Expires 10 May 2025 [Page 36] Internet-Draft Requirements for Energy Efficiency November 2024 4.6.1.1. 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. 4.6.1.2. Reports on Other Entities The standard must provide means for an entity to report information on another entity. 4.6.1.3. 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. 4.6.1.4. 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. 4.6.1.5. 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. 4.6.1.6. 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. Stephan, et al. Expires 10 May 2025 [Page 37] Internet-Draft Requirements for Energy Efficiency November 2024 4.6.2. 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. 4.6.2.1. Controlling Power States of Other Entities RFC6988 allow some entities have control over Power States of other entities, e.g., in Building automation case where 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. In this document, we assume all network devices have IP connectivity in the operator controlled environment. Therefore only an Energy Management System has control over Power States of other entities. In addition, it is required that an entity that has its state controlled by the Energy Management System has the means to report the list of these other entities. 4.6.2.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. 4.6.2.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. 4.6.2.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. 4.6.2.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. Stephan, et al. Expires 10 May 2025 [Page 38] Internet-Draft Requirements for Energy Efficiency November 2024 4.6.2.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. 5. Framework Discussed During the BoF The overall framework is shown in Figure 1. Stephan, et al. Expires 10 May 2025 [Page 39] Internet-Draft Requirements for Energy Efficiency November 2024 What needs to be standardized for Framework (3) Network Domain Level : (a) (b) (c) Inventory Monitor +- DataSheets/DataBase and/or via API Of identity Energy | Metadata and other device/component and Capability Efficiency | /network related information: ^ ^ | | | | .Power/Energy related metrics | | | .information | | | .origin of Energy Mix | | | .carbon aware based on location | | | | | | | | | | | v +--------------------------------------------------------------------+ | * | | (2) controller (collection, compute and aggregate?) | | | +--------------------------------------------------------------------+ ^ ^ ^ | (d) | (e) | (f) | |(g) Inventory | Monitor | GREEN WG: | |GREEN WG: Control Capability | Traffic | Monitor power | |(Energy saving | & power | Proportion, | |Functionality | consumption | Energy efficiency| |Localized mgmt/ | | ratio, etc) | |network wide mgmt) | | | | | | | | | | | v +--------------------------------------------------------------------+ | * | | (1) Device/Component Level | | | | +---------+ +-----------+ +----------------+ +----------------+ | | | (I) | | (II) | | (III) | | (IV) | | | | Network | | Device | | Legacy Network | | 'Attached'(PoE | | | | Device | | Component | | Device | | kind) Device | | | | | | | | | | | | | +---------+ +-----------+ +----------------+ +----------------+ | +--------------------------------------------------------------------+ (*) Energy Efficiency Management Function is implemented inside the device or in a controller Stephan, et al. Expires 10 May 2025 [Page 40] Internet-Draft Requirements for Energy Efficiency November 2024 Figure 1: Framework discussed during the BoF The main elements in the framework are as follows: (a),(d) Discovery and Inventory (b),(c) GREEN Metrics (b),(f) Monitor energy efficiency (e) Monitor power consumption and traffic (IPPM WG throughput, traffic load, etc) (g) Control Energy Saving 6. 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. 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. Stephan, et al. Expires 10 May 2025 [Page 41] Internet-Draft Requirements for Energy Efficiency November 2024 6.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]. 6.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. 6.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. 6.4. Other Aspects Adding new interfaces on devices increase attack surfaces. Devices have brief variation of power consumption due their internal works. Reducing the power available may reduce their routing capacity which may reduce network performance and resiliency. 7. IANA Considerations This document has no IANA actions. 8. Acknowledgments The contribution of Luis M. Contreras to this document has been supported by the Smart Networks and Services Joint Undertaking (SNS JU) under the European Union's Horizon Europe research and innovation projects 6Green (Grant Agreement no. 101096925) and Exigence (Grant Agreement no. 101139120). 9. Open Issues Stephan, et al. Expires 10 May 2025 [Page 42] Internet-Draft Requirements for Energy Efficiency November 2024 9.1. Open Issues to be Discussed at IETF121 o Consider 5g vs network slicing: 3GPP spec describong energy efficiency KPIs. 3GPP TS 28.554. Reference:https://datatracker.ietf.org/doc/rfc9543/ o POE use case: open issue section? o Reduce traffic (video streaming) o Connectivity from radio side (trying to control the traffic/related work to CCAMP) o Marisol to add one use case: drift from data specifications... (somehow link to the above) o Use case per Domain specific? Meanwhile, they are considered as part of the network... Servers might be considered outside of scope o Energy Metric in E2E view 9.2. Open Issues collected since the BoF o Power and Energy Monitoring and Control MIB modules has not been converted yet into YANG modules. Based on their deployements status, discuss their reuse and their mapping in Yang for energy monitoring o Do we need to keep a reference to the MIB object entPhysicalUUID (in section 4.4 from ENTITY-MIB v4) in case of legacy device (MIB)? o The EMAN requirements and EMAN framework had a lot of emphasis on the "Reporting on Other Entities", typically smart PDU or PoE. Is this important? Should this be removed? Should it be addressed in a future charter? This is text about "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." Expressed differently: Out of scope for the short term approach of EMAN framework enhancements, but might be good to call it out, EMAN doesn't include mechanisms for integrating occupancy sensors or user behavior analytics, which can be critical for optimizing HVAC, lighting, and other systems for energy efficiency. This is a key aspect for Smart Buildings and Data Centers energy efficiency metrics. o It's not clear whether we need new Power State (Set)? Maybe not but we need to explain the mapping of existing energy efficient features to specific Power States. Stephan, et al. Expires 10 May 2025 [Page 43] Internet-Draft Requirements for Energy Efficiency November 2024 o basic (scalar) units are not enough to describe Power Data Unit capabilities and/or output. We need a more complex structure (which might already exist?) to cover and combine meanings (that I copied from the chats) like CO2 footprint, clean energy, mix, renewable. as an example, this should help to describe reduction of energy consumption and the increase of renewable energy consumption o Enhance EMAN framework, to support a more robust and comprehensive Energy Efficiency Strategy. Let devices report whatever they can using existing interfaces, without waiting until they implement new capabilities determined by new or existing standards. Including the capability to integrate with external data sources (for example, for devices that don't have the capability or reporting any energy- related metrics) such as vendor datasheets that provide energy consumption. Use case => upgrading a device for better Energy Efficiency Management. Not sure whether framework-related requirements should be covered here. o Leveraging existing devices modularity to introduce eco-designed components in the networks while being able to assess the gains in sustainability. https://datatracker.ietf.org/doc/html/draft-stephan- legacy-path-eco-design-01 https://github.com/emile22/sustainability o Discuss the need to reflect component on/off frequency capacity (in YANG) to avoid too intensive power on/off. o Discuss the need to support a description of the different nature of the sources of the energy used (mix). It should be flexible are the types of sources might augment in the future. o Company's SBTi approved decarbonization plan and how to link it to GREEN WG scope, short/mid vs long term. The Science Based Targets initiative(SBTi)[https://sciencebasedtargets.org] defines and promotes best practice in science-based target setting. Offering a range of target-setting resources and guidance, the SBTi independently assesses and approves companies targets in line with its strict criteria. Open issue, https://github.com/marisolpalmero/GREEN-bof/issues/88 o Consideration to include in scope, allocate/compute and report the energy spent on behalf of a particular customer/user. Open issue, marisolpalmero/GREEN-bof#89 10. References Stephan, et al. Expires 10 May 2025 [Page 44] Internet-Draft Requirements for Energy Efficiency November 2024 10.1. Normative References [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. [ATIS-0600015.03.2013] ATIS, "ATIS-0600015.03.2013: Energy Efficiency for Telecommunication Equipment: Methodology for Measurement and Reporting for Router and Ethernet Switch Products", 2013. [ETSI-ES-203-136] ETSI, "ETSI ES 203 136: Environmental Engineering (EE); Measurement methods for energy efficiency of router and switch equipment", 2017, . [ITUT-L.1310] ITU-T, "L.1310 : Energy efficiency metrics and measurement methods for telecommunication equipment", 2020, https://www.itu.int/rec/T-REC-L.1310/en (https://www.itu.int/rec/T- REC-L.1310/en). 10.2. Informative References [IEC.60050] International Electrotechnical Commission, "Electropedia: The World's Online Electrotechnical Vocabulary", 2013, http://www.electropedia.org/iev/iev.nsf/ welcome?openform (http://www.electropedia.org/iev/iev.nsf/ welcome?openform). Stephan, et al. Expires 10 May 2025 [Page 45] Internet-Draft Requirements for Energy Efficiency November 2024 [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. 11. Appendix This appendix should be removed when the initial set of GREEN WG documents will be stable 11.1. Terminology This section is excepted to move in the GREEN WG draft in charge of terms. The terms below are a sub set of the whole terminology. There are many other drafts giving additionnal definitions. 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. Embedded carbon (or embodied carbon) The total amount of greenhouse gas emissions, measured in tonnes of CO2 equivalent (tCO2e), associated with the entire lifecycle of a product or material, from raw material extraction through manufacturing, transportation, use, and end-of-life disposal or recycling. Embodied energy The total amount of energy consumed in all processes associated with the production of a building material or product, from the extraction and processing of raw materials, through manufacturing, transportation, and installation, to the end of its useful life, including disposal or recycling. 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 Stephan, et al. Expires 10 May 2025 [Page 46] Internet-Draft Requirements for Energy Efficiency November 2024 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 Efficiency Management Involves deploying and managing network infrastructures with the goal of optimizing energy use on network devices while improving the overall network utilization. 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. Energy Monitoring Energy Monitoring is a part of Energy Efficiency Management that deals with collecting or reading information from network elements and their components to aid in Energy Efficiency 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 their components. Power Interface Stephan, et al. Expires 10 May 2025 [Page 47] Internet-Draft Requirements for Energy Efficiency November 2024 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]. 11.2. In Preparation of the GREEN BoF at IETF 120 The EMAN (Energy MANagement) working group (WG), created in 2010 and now concluded, has produced multiples RFCs * RFC7603, Energy Management (EMAN) Applicability Statement * RFC7577, Definition of Managed Objects for Battery Monitoring * RFC7460, Monitoring and Control MIB for Power and Energy * RFC7461, Energy Object Context MIB * RFC7326, Energy Management Framework * RFC6988, Requirements for Energy Management * RFC6933, Entity MIB (Version 4) Note also that some other energy-related MIB modules have been created, but not by the EMAN Working Group Stephan, et al. Expires 10 May 2025 [Page 48] Internet-Draft Requirements for Energy Efficiency November 2024 * RFC3433, Entity Sensor MIB module * RFC3621, Power Ethernet MIB modules * RFC1628, UPS Power Monitoring MIB module * LLDP MIB module and LLDP MED MIB module Due to limitations regarding Writeable MIB module, one IESG statement published in 2014 encourages the use the NETCONF/YANG standards for configuration. Based on the YANG modules developments, three MIB modules (Entity MIB module, Entity Sensor MIB module, Entity State MIB module) have been converted into the "YANG Data Model for Hardware Management" RFC8348. However, Power and Energy Monitoring and Control MIB modules has not been converted yet into YANG modules. Eleven years after the EMAN requirements RFC 6988 publication, this document re-evaluates the energy-related requirements, as a preparation for the GREEN BoF at IETF 120. 11.3. High-level Differences with RFC6988 The following section will delve into the specific details but from a high level point of view, the differences between this document and the RFC6988 are: * New definition for "Energy Efficiency Management" * A focus towards YANG, and not any longer on MIB modules * As a consequence from the previous point, the ENTITY-MIB v4 RFC6933 is replaced by the Hardware YANG module RFC8348 * battery management is removed (as batteries haves some self- optimization features these days). Nevertheless 'Battery' will appear as a source of power of a type of backup * Less focus on the Power over Ethernet management, Nevertheless Reporting on Other Entities remains an open issue * A focus on reporting lifecycle management, considering energy and transformation towards carbon awareness 12. Informative References Stephan, et al. Expires 10 May 2025 [Page 49] Internet-Draft Requirements for Energy Efficiency November 2024 [GREEN-BOF] "BOF proposal for GREEN WG Creation", 10 May 2024, . [green-bof-reqs] "Green BoF requirements collections", 3 September 2024, . [GREEN_NGNM] "NGMN Alliance, GREEN FUTURE NETWORKS: METERING IN VIRTUALISED RAN INFRASTRUCTURE", n.d., . [I-D.ietf-ivy-network-inventory-yang] Yu, C., Belotti, S., Bouquier, J., Peruzzini, F., and P. Bedard, "A Base YANG Data Model for Network Inventory", Work in Progress, Internet-Draft, draft-ietf-ivy-network- inventory-yang-04, 5 November 2024, . [legacy-path] "Requirements for Energy Efficiency Management", 21 July 2024, . [mWT025] "ETSI GR mWT 025, Wireless Backhaul Network and Services Automation: SDN SBI YANG models, V1.1.1.", 31 March 2021. [ONF-MW] "ONF TR-532, Microwave Information Model, version 2.0.", 31 January 2024. [operators-inputs] "Input from Operators to GREEN BoF", 20 July 2024, . [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002, . Stephan, et al. Expires 10 May 2025 [Page 50] Internet-Draft Requirements for Energy Efficiency November 2024 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [rfc6988bis-green] "Requirements for Energy Efficiency Management, 11 years after the EMAN RFC6988", 21 July 2024, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, . [RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A YANG Data Model for Hardware Management", RFC 8348, DOI 10.17487/RFC8348, March 2018, . [RFC8432] Ahlberg, J., Ed., Ye, M., Ed., Li, X., Contreras, LM., and CJ. Bernardos, "A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters", RFC 8432, DOI 10.17487/RFC8432, October 2018, . [RFC8561] Ahlberg, J., Ye, M., Li, X., Spreafico, D., and M. Vaupotic, "A YANG Data Model for Microwave Radio Link", RFC 8561, DOI 10.17487/RFC8561, June 2019, . [RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "A Framework for Network Slices in Networks Built from IETF Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024, . Stephan, et al. Expires 10 May 2025 [Page 51] Internet-Draft Requirements for Energy Efficiency November 2024 [sustainability-insights] "Sustainability Insights", 7 May 2024, . [TS23.501] "3GPP TS 23.501, System architecture for the 5G System (5GS), 17.6.0.", 22 September 2022. [TS28.554] "3GPP TS 28.554, Management and orchestration; 5G end to end Key Performance Indicators (KPI), 17.15.0.", 25 September 2024. Authors' Addresses Emile Stephan Orange Email: emile.stephan@orange.com Marisol Palmero Cisco Systems, Inc. Email: mpalmero@cisco.com Benoit Claise Huawei Email: benoit.claise@huawei.com Qin Wu Huawei Email: bill.wu@huawei.com Luis M. Contreras Telefonica Email: luismiguel.contrerasmurillo@telefonica.com Stephan, et al. Expires 10 May 2025 [Page 52]