| Internet-Draft | Green BoF requirements collections | September 2024 |
| Stephan & Palmero | Expires 8 March 2025 | [Page] |
This memo extracts and groups requirements from the revisit of operator's requirements made in the last charter refinement work and from the drafts which provided material to the green BoF. The aim is to determine initial sets of requirements actionable at different levels of the framework.¶
Discussion Venues¶
The source of this draft and an issue tracker can be found at https://github.com/emile22/green-bof-req-collections¶
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/green-bof-req-collections/draft-stephan-green-bof-reqs-collections.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-stephan-green-bof-reqs-collections/.¶
Discussion of this document takes place on the Getting Ready for Energy-Efficient Networking Working Group mailing list (mailto:green-bof@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/green-bof/. Subscribe at https://www.ietf.org/mailman/listinfo/green-bof/.¶
Source for this draft and an issue tracker can be found at https://github.com/emile22/green-bof-req-collections.¶
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 8 March 2025.¶
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.¶
This memo extracts and groups requirements from the revisit of operator's requirements made in the last charter refinement work [charter-refinement] and from the drafts which provided material [GREEN-BOF], [sustainability-insights], [legacy-path] and [rfc6988bis-green] to the green BoF. The aim is to determine initial sets of requirements actionable at different levels of the framework presented in [charter-refinement].¶
The tables below respect the format and the semantic of operators requirements table of [charter-refinement].¶
The table below is a copy of the operator'requirements table of [charter-refinement]. They are based on the inputs received from operators for the GREEN BoF [operators-inputs].¶
| category | requirements | note | Priority |
|---|---|---|---|
| Observability | Component granularity, e.g., per line-card, per-port | Per component measurement | 1 |
| Observability | Availability of information on the power consumption of the device, without needing instrumentation connected to the infrastructure | Related to connected device case | 1 |
| Observability | Triggering of alarms when consumption deviate from a nominal usage | Alarm notification | 1?? |
| Observability | Improvement of metering solutions (finer granularity, control of the energy efficiency and saving, interoperability, exposure) | Standardized metering?? | 1 |
| Analysis | Common definition of energy efficiency in network devices/components | Standard metric | 1 |
| Analysis | Common methodology of measurements for fair comparison | Standard methodology | 2 |
| Analysis | How to provide accurate figures (context of the measurement in terms of time period, location, traffic, etc | Time based, location based visualization | 2 ?? |
| Analysis | Database for decision in case of large data transfer | Information Correlation | 3 |
| Analysis | Ability of multi-layer analysis (e.g., IP plus optical) | POI Use Case | 3 |
| Control& Mgmt | To have devices with elastic power consumption according to the carried traffic | Dynamic Energy Saving | 2 |
| Control& Mgmt | Support of network-wide energy saving and optimization functions | Network Level Mgmt | 2 |
| Control& Mgmt | Support of network-wide control of energy optimization APIs, allowing external applications to optimize consumption | Network Level Mgmt | 2 |
| Control& Mgmt | Advanced sleep mode, needing some sort of low power mode when node is lightly utilized | Dynamic Energy Saving | 2 |
| Control& Mgmt | Ability to steer traffic based on power savings | Traffic Engineering | 4 |
| Control& Mgmt | Comparison of decision vs optimal case | Intent based Concept | 2 |
| Control& Mgmt | Synchronous query support | Network Level Query | 2 |
| Inventory Management | Inventory of power components (of devices, racks, etc) including together | Component & Device Level | 1 |
| Interaction with other domain | Inclusion of data center networks in the picture | Data Center Case | 3 |
| Interaction with other domain | Inclusion of data center networks in the picture | Mobile Network Case | 3 |
| Sustainability & Carbon Emission | Optimize the overall CO2 footprint (i.e., energy mix based on source type) facilitating the engineering of PoP More renewable energy | More renewable energy | 4 |
| Sustainability & Carbon Emission | Support GHG units | Measurement Units | 4 |
| Sustainability & Carbon Emission | Support Energy units | More renewable energy | 2 ?? |
| Sustainability & Carbon EmissiCarbon, renewable | 4 | ||
| Sustainability & Carbon Emission | Accounting of legacy installed based GHG/energy | Accounting Cost | 4 |
| Sustainability & Carbon Emission | Track device/network Energy Consumption Before Operation | Manufacturing, transport(weight, volume, package) | 4 |
| category | requirements | note | Priority |
|---|---|---|---|
| Inventory Management | component control capacity (aka component max on/off frequency supported) | Per component control | 1 (i) |
| Analysis | assess the gains of introducing eco-designed components in a device | Device Level Mgmt | 1 (ii) |
| Control& Mgmt | comprehensive support of network-wide energy efficiency includes legacy devices | Network Level Mgmt | 1 (iii) |
(i) Avoid control to break the component¶
(ii) the gain must be measurable¶
(iii) network-wide solution must include legacy devices and green-wg ready devices¶
| category | requirements | note | Priority |
|---|---|---|---|
| Control& Mgmt | Distinguish backup sources | rfc6988bis battery | 2 |
| Inventory Management | Reporting on Other Entities, typically smart PDU or PoE | Fit in "Inventory of power components (of devices, racks, etc) including together" | 2 |
| Observability or Interaction with Other domain | Room sensor (hvac...) | Data Center Case | 4 |
| Observability | flexible (future-proof) description of the nature of the sources of the energy used | Standard metric | 2 |
There are limited to energy consumption vs sustainability¶
| category | requirements | note | Priority |
|---|---|---|---|
| Observability | Provide near-real-time energy consumption to different device types, service types, and individual users | Helps identify which devices or network functions are consuming more energy. | 2 |
| Migration or Upgrade | Provide KPIs for energy efficiency parameters, enhance accuracy of upgrade decisions | Helps make informed decisions about upgrades based on actual usage data. | |
| Recycling | Report on percentage of recycled user devices and components. Enable comprehensive reporting and recycling efforts | Major driver of the circular economy, transparency is key | 4 |
| Power Optimization | Provide KPIs for energy efficiency parameters. Perform actions to reduce energy consumption | Monitor network and application performance to optimize power usage | 4 |
| Control& Mgmt Switch off | Stop and restart WiFi APs with the right time, space, and service granularity | Save power consumption during periods when APs are not in use. | 2 |
The overall framework is shown in Figure 1.¶
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
The main elements in the framework are as follows:¶
(a),(d) 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¶
Based on the framework discussed during the BoF, the architectural requirements for the "GREEN" Framework:¶
From a network inventory [network-inventory] point of view, when discussing Energy Efficiency metrics, also known as GREEN metrics, it is important to distinguish between static and dynamic attributes:¶
"Static" attributes refer to those that do not change based on the state of the network infrastructure. The following examples are all static attributes that we can relate to the inventory, implemented in the network devices or as part of external sources:¶
Static attributes also include benchmarking information related to energy consumption by design and test conditions, normally associated to PSU's, line-cards, etc.:¶
These attributes might be collected from the device/component itself or they might be parameters as part of external sources, i.e., databases owned by the hardware or software providers, where API access will be preferred.¶
Normally, the "Discovery" process will be updating static attributes that represent the up-to-date inventory of the network. The Discovery process relates primarily to the static attributes, where will consider if a device or component has been replaced or is out of service. The "Operation" process will be updating the so-called dynamic attributes.¶
Dynamic attributes are those that are subject to change due to the running operations, including configuration and state changes, and they will need to be collected regularly.¶
They will be updated as part of the regular operations. Dynamic attributes might be related to sensors(environmental), traffic, state, etc. They will include attributes like:¶
The data collection frequency might need to be adjusted based on the specific attributes. For example, the discovery of linecards installed on network devices will not change every hour, whereas temperature and power sensor information changes will need to be closer to real-time.¶
Even though sensors normally are embedded in the network device/component, there are external sensors meant to measure temperature and energy consumption. The network controller will need to collect and correlate information to compose the right GREEN metric for the network device/component.¶
Based on the work initiated under [I-D.draft-cx-opsawg-green-metrics-02], it might be required to prioritise the definition and data models for the metrics relevant to the components and network elements, as they will be the ones influencing the most to the metrics related to flows, path and network.¶
Monitor and Performance will include the guidelines for the association of the different attributes that defined the GREEN metrics to compose and aggregate the data collection to formed the reporting¶
The architecture could define a prefer interface, based in YANG as the preferred data model, but should allow enough freedom in the implementation, where any kind of quantity can be measured, any kind of collection protocol and mechanism employed, and the telemetry data flows aggregated using any kind of operation.¶
Control will consider how to improve GREEN metrics with the final goal to automate the monitoring, performance and remediation in case of a fault or deviation of the performance defined for the metrics.¶
This section describes an incremental example of usage showing how a product, a service and a network can use the framework in different settings.¶
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.¶
moving to GREEN energy effiency support: 3 steps (uc) :¶
season 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.¶
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.¶
season 2 "component": part of its hw or sw migrated to support GREEN framework elements, TODO add refs to [legacy-path] sections.¶
season 3 "device controleur"¶
season 4 "network level"¶
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.¶
This document has no IANA actions.¶
This version collectes works from the Green Bof proponents: Luis, Marisol, Tony, Qin and Emile, from our coachs Jari, Adrian and Benoit, and from our supporter Tobe¶