Getting Ready for Energy-Efficient Networking R. C. Sofia Internet-Draft D. Ali Intended status: Informational fortiss GmbH Expires: 7 January 2026 6 July 2025 Energy-aware Differentiated Services (EA-DS) draft-sofia-green-energy-aware-diffserv-00 Abstract This document proposes to extend the Differentiated Services (DiffServ) Quality of Service (QoS) model to support energy-efficient networking. As a first draft, it discusses how such extensions could be done, bringing first examples of energy-efficiency metrics that could be applied to mark traffic, and providing routing applicability examples by interpreting existing or experimental DSCP codepoints to represent not only traditional QoS parameters (e.g., latency, jitter), but also application-level energy sensitivity. By incorporating energy metrics into traffic classification, network devices and orchestrators can make routing and resource allocation decisions that optimize both service performance and energy consumption. 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 7 January 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. C. Sofia & Ali Expires 7 January 2026 [Page 1] Internet-Draft Energy-aware DiffServ July 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.3. Scope and Applicability . . . . . . . . . . . . . . . . . 4 1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 2. Energy-awareness and Node, Link, Path Telemetry Considerations . . . . . . . . . . . . . . . . . . . . . 6 3. Energy-aware DSCP Mapping . . . . . . . . . . . . . . . . . . 7 4. Routing Behaviour . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Example: Minimize Link Energy . . . . . . . . . . . . . . 10 4.2. Example: Lowest Total Energy (Links and Nodes) . . . . . 11 4.3. Example: Lowest Energy-Load Preference . . . . . . . . . 11 4.4. Example: No energy-awareness Preference . . . . . . . . . 12 5. Telemetry and Probing for Energy-aware Routing Considerations . . . . . . . . . . . . . . . . . . . . . 12 5.1. Passive Probing . . . . . . . . . . . . . . . . . . . . . 12 5.2. Active Probing . . . . . . . . . . . . . . . . . . . . . 12 5.3. Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7.1. DSCP Misuse and Traffic Reclassification . . . . . . . . 14 7.2. Control Plane Manipulation . . . . . . . . . . . . . . . 14 7.3. Privacy Preservation . . . . . . . . . . . . . . . . . . 15 7.4. Energy Specific Threats . . . . . . . . . . . . . . . . . 15 7.5. Inter-domain Trust and Policy Consistency . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 C. Sofia & Ali Expires 7 January 2026 [Page 2] Internet-Draft Energy-aware DiffServ July 2025 1. Introduction Energy efficiency and sustainability are becoming design priorities in data communications, driven by the increasing complexity of ultra- dense, heterogeneous mobile network environments and the proliferation of mobile, decentralized applications. These applications often demand not only high processing power and bandwidth, but also bounded latency guarantees. At the same time, several international efforts are aligning with global net-zero objectives, investing in energy-optimized infrastructures, relying on Artificial Intelligence (AI)-based power management, renewable energy integration, and intelligent resource allocation strategies spanning both hardware and software development. As discussed in initiatives such as GREEN and the IRTF SUSTAIN research group, there is a growing need to integrate energy awareness into the broader operation of communication networks. This includes embedding energy considerations into the routing and forwarding processes, which are traditionally optimized solely for performance metrics. In this context, the present work proposes extending Quality of Service (QoS) models by incorporating energy-specific metrics as first-class parameters. Integrating energy sensitivity into QoS models offers tangible benefits across network management and operations. However, it also introduces new challenges: how to effectively express and signal energy metrics, how to gather and interpret the required telemetry, and how to manage the trade-offs between energy savings, system complexity, and performance. To address this, this draft specifically focuses on how such integration would fit the Differentiated Services (DiffServ) model as defined in [RFC2474] and [RFC2475]. The approach is to interpret existing and experimental DiffServ Code Points (DSCP) to encode both application-level QoS requirements and energy-related constraints. By doing so, network elements such as routers, switches, and orchestrators can make resource allocation and forwarding decisions that take into account energy-sensitivity parameters, such as power consumption or CO2 footprinting. This enables a more energy-efficient network behavior without compromising service-level expectations. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. C. Sofia & Ali Expires 7 January 2026 [Page 3] Internet-Draft Energy-aware DiffServ July 2025 1.2. Problem Statement As networks and internet applications evolve from real-time control systems to data-intensive analytics heavily involving AI workloads, the need to manage both performance and energy efficiency during networking operations, such as routing, is becoming increasingly critical. Quality of Service (QoS) models such as the Differentiated Services (DiffServ) [RFC2474][RFC2475] offer well-established frameworks for expressing and enforcing QoS application requirements in the form of latency, jitter, packet loss, among others. However, the modern shift toward decentralized architectures, such as multi- tenant, heterogeneous, and dynamic edge-cloud environments, demands a dual operational objective: maintaining service quality while minimizing energy consumption. Applications now vary not only in their strict traditional QoS constraints, but also in their energy sensitivity and adaptability. For instance, an Internet of Things (IoT) telemetry flow may tolerate delayed or batched delivery to reduce energy use, while a control loop for an industrial system may demand immediate and high-energy processing regardless of cost. In the absence of mechanisms to signal such energy-related requirements within a QoS model like DiffServ, network elements and orchestration systems lack the information needed to make coordinated decisions that optimize for both energy and performance, while meeting application-level requirements. Enabling such integration would support dynamic, intelligent traffic handling, including energy-aware routing ("green" routing), scaling of compute resources based on traffic class, or even energy-based preemption, while still respecting application-level QoS expectations. DiffServ provides a scalable approach to classifying and prioritizing traffic using Differentiated Services Code Points (DSCP). It effectively addresses performance-related service differentiation, but, similarly to other QoS models, it is agnostic to the energy consumption of the underlying infrastructure, whether in the forwarding paths or in the compute nodes executing workloads. As such, extending DiffServ to incorporate energy-awareness is a timely and necessary evolution to support sustainable, energy-efficient, and policy-aligned networking in increasingly complex and environmentally conscious operational environments. 1.3. Scope and Applicability The energy-aware discussion on extensions to DiffServ proposed in this document is applicable in environments where fine-grained policy enforcement, traffic classification, and telemetry-driven routing or scheduling are operationally feasible. The work is primarily applicable to multi-tenant federated edge-cloud environments where energy-sensitive networking policies are relevant. These include: C. Sofia & Ali Expires 7 January 2026 [Page 4] Internet-Draft Energy-aware DiffServ July 2025 * Cloud-edge computing infrastructures, especially those integrating AI workloads or energy-constrained nodes. * Industrial IoT environments, where specific classes of traffic (e.g., control loops vs. telemetry) exhibit distinct energy and latency requirements. * Software-defined WANs (SD-WANs) deployments, where centralized controllers manage QoS and routing policies. * Federated edge-cloud platforms, such as those based on CODECO, where energy efficiency is a key orchestration objective. These scenarios typically involve DSCP marking and enforcement at ingress points, real-time or periodic energy/load telemetry collection, and centralized or distributed routing logic. The proposed approach assumes that DSCP markings are respected across the path and that telemetry is exposed with sufficient granularity, with attention to privacy 1.4. Definitions Latency: (also known as bounded latency) refers to the end-to-end transmission delay between a sender and a receiver when a traffic flow is initiated by an application. By definition, latency corresponds to the time interval between the sending of the first packet of a flow from a source to a destination and the time at which the last packet of that flow is received Node energy, n_e(i) is the amount of energy (typically measured in Joules or Watts over time) consumed by a node to host, process, and serve workloads, including compute, memory, storage, and network interface activity. Node load CPU, memory, or I/O resource usage that may affect dynamic energy consumption and thermal management. Link energy, l_e(i,j) The amount of energy (typically measured in milliJoules per bit (mJ/bit) or Watts) consumed by the transmission of data across a network connection between two nodes, including switches, routers, and network interface cards (NICs) involved in the path. C. Sofia & Ali Expires 7 January 2026 [Page 5] Internet-Draft Energy-aware DiffServ July 2025 Link load, l(i,j) The current traffic load (e.g., as a percentage of link capacity), which can affect both latency and energy cost. Energy sensitivity A qualitative or quantitative indication of how tolerant a given application or flow is to variations in energy consumption (e.g., delay to save power, or no tolerance at all). 2. Energy-awareness and Node, Link, Path Telemetry Considerations To enable energy-aware routing and resource management, network elements MUST have access to timely, accurate telemetry about the energy consumption and utilization characteristics of both nodes and links. This information allows the control or data plane to make informed decisions about path selection and traffic treatment based not only on traditional QoS metrics (e.g., delay, jitter, loss), but also on energy-related factors. To enforce energy-aware policies, networking nodes MUST expose telemetry on: * Node energy. * Node usage * Link energy. * Link usage Network nodes MAY also expose telemetry on other parameters such as: * Node power state transition (e.g., idle, transmit, receive modes). * Other energy related metrics, such as CO2 footprint. A combined path energy cost can be computed by aggregating both node and link energy metrics along a given forwarding path. Formulations of some of these metrics can be found in related initiatives. As a representative example, this work references node and link energy/ load metrics used in the CODECO edge-cloud container orchestration framework [codeco]. While CODECO offers a practical implementation of energy metric collection and usage, the definitions and methods presented here are not exclusive to CODECO and can be generalized to other orchestration or telemetry frameworks. Hence, the metrics defined in CODECO deliverable D10 [codeco_d10] offer a compute- and network-oriented view of energy metrics and can serve as a useful reference for exploring how similar principles might be applied to DiffServ-based QoS extensions. These metrics are illustrative and not prescriptive, and alternative formulations or telemetry models C. Sofia & Ali Expires 7 January 2026 [Page 6] Internet-Draft Energy-aware DiffServ July 2025 may be equally valid. Such telemetry can serve as input for policy engines or SDN controllers in future DiffServ extensions. In particular, the CODECO framework defines: * Node energy as n_e(i): Per-node energy over time, aggregated from system sensors. * Link energy, l_e(i,j): Dynamic energy cost for traffic across interface j of node i, derived from interface statistics and probing. * Node usage: % of CPU available derived from interface statistics and probing. * Link usage, l: traffic across interface j of node i, derived from interface statistics and probing. 3. Energy-aware DSCP Mapping The DSCP field provides a 6-bit space in the IP header used to classify traffic into Per-Hop Behaviors (PHBs), as defined in [RFC2474] and further elaborated in [RFC4594]. This document proposes extending the semantics of selected DSCP values to encode energy sensitivity, in addition to traditional QoS dimensions such as latency, jitter, and packet loss. Table 1 provides a representative mapping of DSCP values to energy-aware service classes. Where possible, this mapping is aligned with the traffic classes and PHBs defined in RFC 4594, ensuring backward compatibility and operational consistency. Additionally, a subset of experimental DSCP values (from the local/experimental range) is introduced to support emerging use cases in energy-aware networking environments. Each DSCP class in the table is annotated with an intended energy sensitivity, an example use case, and a recommended policy behavior. These annotations are illustrative and meant to guide implementations that wish to leverage DiffServ for integrated energy and performance-aware traffic treatment. Experimental DSCP values (e.g., 0x2E, 0x1A, 0x0A) are intended for closed or federated environments where domain-wide agreement on codepoint interpretation is feasible. These enable finer-grained control over routing or resource scheduling policies that optimize for energy efficiency alongside service quality. +=====+====+============+===========+============+==================+ |DSCP |PHB |RFC 4594 |Energy |Example | Example | |Value|Name|Traffic |Sensitivity|Usage | Recommended | | | |Class | | | Behaviour | +=====+====+============+===========+============+==================+ |46 |EF |Real-Time |Ignore |VoIP, | Route via path | | | |Interactive | |industrial | with lowest | C. Sofia & Ali Expires 7 January 2026 [Page 7] Internet-Draft Energy-aware DiffServ July 2025 | | | | |control | latency and | | | | | | | jitter; energy | | | | | | | cost not | | | | | | | considered | +-----+----+------------+-----------+------------+------------------+ |34 |AF41|Broadcast |Moderate |Real-time HD| Prefer low- | | | |Video | |video | latency and | | | | | | | low-loss paths | | | | | | | with moderate | | | | | | | energy | | | | | | | awareness | +-----+----+------------+-----------+------------+------------------+ |26 |AF31|Multimedia |Moderate |Interactive | Route via | | | |Conferencing| |conferencing| medium-energy, | | | | | | | lightly loaded | | | | | | | paths to | | | | | | | balance latency | | | | | | | and energy- | | | | | | | efficiency | +-----+----+------------+-----------+------------+------------------+ |18 |AF21|High |High |AI/ML batch | Prefer energy- | | | |Throughput | |jobs, smart | efficient | | | |Data | |uploads | routes even if | | | | | | | slightly higher | | | | | | | delay; include | | | | | | | load balancing | +-----+----+------------+-----------+------------+------------------+ |10 |AF11|Low-Latency |High |Firmware | Select | | | |Data | |updates, | underutilized, | | | | | |telemetry | low-energy | | | | | |sync | paths, tolerate | | | | | | | variable | | | | | | | latency | +-----+----+------------+-----------+------------+------------------+ |8 |CS1 |Background |Very High |Backups, | Route via | | | |Data | |logs, cold | lowest-energy, | | | | | |storage | longest-delay | | | | | | | paths; | | | | | | | preemptable | | | | | | | traffic | +-----+----+------------+-----------+------------+------------------+ |0 |BE |Best Effort |Max energy |Non-critical| Allow | | | | |savings |data | opportunistic | | | | | |transfer | routing; | | | | | | | energy- | | | | | | | efficiency | | | | | | | maximized, no | | | | | | | performance | C. Sofia & Ali Expires 7 January 2026 [Page 8] Internet-Draft Energy-aware DiffServ July 2025 | | | | | | guarantee | +-----+----+------------+-----------+------------+------------------+ |0x2E |EXP |Experimental|Low |Secure, | Route through | | | |Use (High | |energy- | secure but | | | |Priority) | |sensitivity | energy-aware | | | | | |critical | paths; | | | | | |flows | monitored for | | | | | | | telemetry | | | | | | | feedback | +-----+----+------------+-----------+------------+------------------+ |0x1A |EXP |Experimental|Moderate |Distributed | Trade-off | | | |Balanced | |compute jobs| between energy | | | |Load | | | cost and | | | | | | | congestion | | | | | | | across nodes | | | | | | | and links | +-----+----+------------+-----------+------------+------------------+ |0x0A |EXP |Experimental|Very High |Delay- | Explicitly | | | |Energy Saver| |tolerant | prefer energy- | | | | | |batch | minimizing | | | | | |processing | paths; | | | | | | | opportunistic | | | | | | | or deferred | | | | | | | routing | +-----+----+------------+-----------+------------+------------------+ Table 1: Energy-aware DSCP Mapping Aligned with RFC 4594 4. Routing Behaviour Network elements and orchestrators MAY implement routing and scheduling decisions that consider both the DSCP value (as a proxy for energy sensitivity) and real-time energy metrics collected from network nodes and links. A few examples based on the Figure 1 topology: C. Sofia & Ali Expires 7 January 2026 [Page 9] Internet-Draft Energy-aware DiffServ July 2025 R1 / \ l_e=1.2,l=60% l_e=1.0,l=50% / \ A B \ / l_e=0.8,l=40% l_e=0.6,l=35% \ / R2----------\ | \ l_e=0.7,l=30% \ l_e=0.6,l=25% | \ C--------------D / \ l_e=0.5,l=20% l_e=0.4,l=15% / \ (1) (2) (Source and Destination) Figure 1: Example topology with link and node Energy/Load Metrics. Where: * (1) Source node. * (2) Destination node * R1, R2 routers * A, B, C, D: Intermediate access routers/edge nodes Between nodes, each link has the following costs: * e = energy per bit (in mJ/bit). * l = current load (in % usage) 4.1. Example: Minimize Link Energy The aim is to define a policy that always selects links with lowest energy, independently of node energy or load. Here, delay-tolerant or low-priority traffic WOULD be routed via links that overall provide the minimum cumulative energy cost, independently of the node location, number of hops, or total latency. * Selected path: 1 -- C --D --2 * Link Costs: C. Sofia & Ali Expires 7 January 2026 [Page 10] Internet-Draft Energy-aware DiffServ July 2025 * 1--C: 0.5, C--D: 0.4, D--2: 0.4 = 1.3 mJ/bit total link energy * Alternative Path (e.g., via R1): much higher link energy (1.2+1.0) * DSCP: CS1 (8) or BE (0) * Traffic example: Background data sync, logs 4.2. Example: Lowest Total Energy (Links and Nodes) The aim is to define a policy that results in the selection of routes with both total lowest cumulative energy, and low utilization, considering both link and node load. * Candidate Path: 1 --C --R2 --B --2 * Link energy: 0.5 + 0.7 + 0.6 + 0.6 = 2.4 * Node energy: C (0.6) + R2 (0.9) + B (1.0) = 2.5 * Total = 4.9 mJ/bit * Alternative path via R1 has total energy = 6.0+ mJ/bit * DSCP: AF31 (26) or AF21 (18) * Traffic example: Analytics, smart batching apps 4.3. Example: Lowest Energy-Load Preference The aim of this policy would be to consider a combination of energy and load, to ensure that traffic WOULD be routed over nodes that can offer the path with low energy and also low usage: * Candidate Path: 1 --C --R2 --D --2 * Load: C -- 20%, R2 -- 30%, D -- 15%, links -- 25-30% * Energy: C + R2 + D = 0.6 + 0.9 + 0.5 = 2.0 mJ (nodes) * Links 2.0 mJ --Total 4.0 mJ * DSCP: AF11 (10) or Experimental (0x30) * Traffic Type: Opportunistic jobs like firmware updates or distributed computations where network and compute utilization should be minimized. C. Sofia & Ali Expires 7 January 2026 [Page 11] Internet-Draft Energy-aware DiffServ July 2025 4.4. Example: No energy-awareness Preference In this example, the DSCP marking would allow routers to ignore any energy preference, ensuring a traditional expedited treatment. * Path Selected: 1 --C --R2 --A --R1 --B --2 * DSCP Mapping: EF (DSCP 46) * Traffic Type: Real-time voice/video or control systems 5. Telemetry and Probing for Energy-aware Routing Considerations Energy-aware service differentiation requires accurate, real-time insights into the state of the network, particularly with respect to energy consumption and resource load. Such insights can be gathered through two primary telemetry mechanisms: passive or active (in-band) probing. 5.1. Passive Probing Passive probing refers to the collection of performance and usage metrics by observing ongoing traffic without modifying it. Common methods include flow monitoring (e.g., NetFlow, IPFIX), SNMP-based counters, interface statistics, and network tap-based analytics. Passive probing is advantageous due to its low intrusiveness, wide support in existing infrastructure, and suitability for long-term trend analysis. However, it typically lacks real-time granularity, does not reflect per-packet variation, and often provides limited insight into specific in-network behavior such as queuing delay or microbursts. Passive probing is beneficial to bring a fine-grained perspective on energy sensitivity based on: * Interface energy counters (if supported by hardware) * Node CPU/memory utilization * Link usage 5.2. Active Probing Active probing (or in-band telemetry) involves the use of explicit probes or modifications to data-plane packets to embed monitoring information. This includes: * In-situ Operations, Administration, and Maintenance (IOAM) [RFC9197] C. Sofia & Ali Expires 7 January 2026 [Page 12] Internet-Draft Energy-aware DiffServ July 2025 * In-band Network Telemetry (INT) using programmable data planes (e.g., P4) * Application-layer probes for measuring latency and loss * Synthetic probing (e.g., ping, traceroute with extensions) Active probing allows for per-hop, per-packet collection of: * Processing delay * Queue depth * Path-level latency and jitter * Node and link identifiers * (Optionally) energy cost annotations per segment This level of visibility is especially valuable for adaptive, energy- aware routing decisions. For example, flows marked with energy- sensitive DSCP values may be routed dynamically based on the measured per-path energy profile, using IOAM metadata. However, in the context of edge-cloud multi-tenant, federated environments, active probing may increase the overall operational inherent to deploying a monitoring architecture across mobile, heterogeneous large-scale edge-cloud environments. 5.3. Hybrid Approaches In practice, energy-sensitive service differentiation may benefit from a combination of passive and active mechanisms. Passive metrics can provide baseline load and energy cost estimates, while active probing offers precision feedback for high-priority or adaptive flows. Control planes (e.g., SDN controllers or orchestrators) can use telemetry to: * Select energy-efficient paths for DSCP classes that tolerate delay * Adjust queue policies or scheduling weights in real-time * Trigger re-marking or flow deferral when energy thresholds are reached Probing systems MUST ensure time-synchronization and data fidelity if they are used for per-hop energy optimization. Energy-related telemetry formats and reporting intervals SHOULD be aligned with flow-level characteristics to avoid overreaction or instability. C. Sofia & Ali Expires 7 January 2026 [Page 13] Internet-Draft Energy-aware DiffServ July 2025 6. IANA Considerations This document does not request IANA action but suggests using DSCP values in the experimental or local-use ranges for energy-aware extensions. 7. Security Considerations Energy-aware Differentiated Services introduce several new potential attack vectors and privacy implications beyond those already present in traditional DiffServ and QoS mechanisms. 7.1. DSCP Misuse and Traffic Reclassification This work proposes to rely on experimental DSCP values to signal energy sensitivity and influence routing and scheduling decisions. Malicious or misconfigured endpoints could falsely mark traffic to gain preferential treatment, such as being routed through energy- saving paths or low-congestion nodes. To mitigate this, networks SHOULD: * Enforce DSCP re-marking at domain ingress (e.g., at provider or enterprise edges) * Authenticate or validate traffic classification based on application profiles or identity * Restrict high-sensitivity DSCP values (e.g., EF or experimental green classes) to trusted endpoints 7.2. Control Plane Manipulation Energy-aware routing relies on telemetry and policy interpretation at centralized or distributed control planes. Attackers who gain access to these systems could manipulate: * Energy metrics to bias routing * Load reports to induce congestion * Path computation engines to direct traffic inefficiently or disrupt service Control planes MUST be protected using standard practices: * Mutual authentication between controllers and forwarding devices * Role-based access control (RBAC) for orchestration systems C. Sofia & Ali Expires 7 January 2026 [Page 14] Internet-Draft Energy-aware DiffServ July 2025 * Secure telemetry channels (e.g., TLS, IPsec) 7.3. Privacy Preservation Probing mechanisms, in particular active probing, may expose internal node performance, energy use, and utilization patterns. This can leak information about the network's architecture, topology, or workload behaviour. Networks SHOULD: * Limit the telemetry scope (e.g., aggregate rather than per-packet reporting) * Apply encryption or anonymization where telemetry crosses trust boundaries * Use access controls for telemetry consumers and collectors 7.4. Energy Specific Threats Manipulating energy-related behavior may not only degrade QoS but also undermine broader sustainability goals. Attackers may attempt to: * Overload energy-efficient paths to force fallback to high- consumption infrastructure * Create asymmetric energy drain in multi-tenant environments * Starve critical energy-aware flows by congesting green paths Such threats can be mitigated by: * Incorporating energy fairness into policy logic * Monitoring for unusual shifts in energy path usage * Reserving minimum energy budgets for critical DSCP classes 7.5. Inter-domain Trust and Policy Consistency In multi-domain deployments (e.g., federated edge-cloud or SD-WAN), DSCP interpretations and energy policies may vary across domains. Without consistent trust models, forwarding domains may ignore, alter, or misinterpret DSCP markings. To prevent this: * Domains SHOULD negotiate DSCP-to-policy mappings where possible C. Sofia & Ali Expires 7 January 2026 [Page 15] Internet-Draft Energy-aware DiffServ July 2025 * Border routers MUST apply local enforcement and telemetry filtering * DSCP field usage SHOULD be aligned with IANA and IETF-recommended classes 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, . [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, . [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, . 8.2. Informative References [codeco] C. Sofia et al., R., ""A Framework for Cognitive, Decentralized Container Orchestration," inProc. IEEE Access, vol. 12, pp. 79978-80008, 2024, doi: 10.1109/ ACCESS.2024.3406861.", 2024. C. Sofia & Ali Expires 7 January 2026 [Page 16] Internet-Draft Energy-aware DiffServ July 2025 [codeco_d10] C. Sofia et al., R., ""CODECO Deliverable D10 - Technological Guidelines, Reference Architecture, and Open-source Ecosystem Design.https://doi.org/10.5281/zenodo.12819444", 2024. Acknowledgements This work has been funded by The European Commission in the context of the Horizon Europe CODECO project under grant number 101092696, and by SGC, Grant agreement nr: M-0626, project SemComIIoT. We thank the following colleagues for their discussions concerning network probing and exposure as well as application workload scheduling aspects: * Alberto del Rio, Universidad Politecnica de Madrid, for contributions for active probing. * Kaikang Huang, fortiss, for contributions on energy-efficient network telemetry and probing * Tina Samizadeh, fortiss, for contributions on scheduling benchmarking * Alejandro Muniz, Telefonica, for contributions on network exposure * Luis Miguel Contreras Murillo, Telefonica, for contributions on network exposure Authors' Addresses Rute C. Sofia fortiss GmbH Guerickestr. 25 80805 Munich Germany Email: sofia@fortiss.org URI: www.rutesofia.com Dalal Ali fortiss GmbH Guerickestr. 25 80805 Munich Germany Email: ali@fortiss.org C. Sofia & Ali Expires 7 January 2026 [Page 17]