



SUSTAIN                                                  L. M. Contreras
Internet-Draft                                          G. Sanchez-Illan
Intended status: Informational                                Telefonica
Expires: 1 September 2026                                      A. Hecker
                                                               O. Abboud
                                                     Huawei Technologies
                                                        28 February 2026


    Functional entities for enabling per service eco-data reporting
                  draft-csha-sustain-reporting-arch-00

Abstract

   This document provides an architectural mapping between the Exigence
   intra-domain functional architecture and the IETF GREEN Framework for
   Energy Efficiency Management.  The purpose is to harmonize Exigence’s
   service-centric energy attribution and green orchestration functions
   with the multi-layered monitoring, control and API-exposed energy
   management architecture defined in the GREEN reference model.

   This document identifies a number of functional components enabling a
   service-centric energy attribution for the network domain, and
   describes their mapping to the IETF GREEN framework for energy
   efficiency management, including interfaces and energy-object
   concepts.  Such functional components allow the realization of green
   orchestration capabilities with multi-layered monitoring, control and
   API-exposed energy management.

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 1 September 2026.






Contreras, et al.       Expires 1 September 2026                [Page 1]

Internet-Draft  Functional Entities for Reporting Eco-da   February 2026


Copyright Notice

   Copyright (c) 2026 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview of the IETF GREEN Reference Model  . . . . . . . . .   3
   4.  Overview of the Functional Blocks . . . . . . . . . . . . . .   5
   5.  Mapping of Functions to the GREEN Framework . . . . . . . . .   6
     5.1.  Device & Component Level  . . . . . . . . . . . . . . . .   6
     5.2.  Controller Level  . . . . . . . . . . . . . . . . . . . .   6
     5.3.  Network-Domain Level  . . . . . . . . . . . . . . . . . .   7
     5.4.  Reporting Function  . . . . . . . . . . . . . . . . . . .   7
   6.  Mapping of Process Flows and Interfaces . . . . . . . . . . .   7
   7.  Handling Double Counting  . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   10. Informative References  . . . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The IETF GREEN Framework [I-D.belmq-green-framework] defines an
   extensible, device-to-system architecture for representing,
   measuring, aggregating and controlling energy information across
   devices, controllers, and network-wide systems.

   In order to collect the energy consumption associated to a given
   service, different functional blocks can be considered as part of
   such framework, making possible the creation of an end-to-end
   energy-reporting overlay collectng and reporting the data through a
   Reporting Function (RF).  This architecture provides energy
   attribution at the service-function level through a consistent
   functional pipeline: service discovery, resource allocation, energy
   measurement, attribution, and, if necessary, green orchestration.



Contreras, et al.       Expires 1 September 2026                [Page 2]

Internet-Draft  Functional Entities for Reporting Eco-da   February 2026


   This document propose detailed extensions on top of the GREEN
   framework for such purpose.

2.  Terminology

   Key terms from the GREEN framework, including Energy Object, Energy
   Management System (EnMS), Power Interface, and Relationship types
   (Power Source, Metering, Aggregation), follow
   [I-D.belmq-green-framework].

3.  Overview of the IETF GREEN Reference Model

   The GREEN Framework [I-D.belmq-green-framework] organizes
   energy-management functionality into three levels:

   *  Device & Component Level: Energy Objects, physical meters, PoE
      endpoints, legacy devices, and the energy topology relations among
      them.

   *  Controller / EnMS Level: Aggregation, computation, and
      policy-driven control; supports centralized, distributed, or
      hierarchical layouts.

   *  Network Domain Level: Inventories, data repositories, analytics
      platforms, and service APIs (e.g., PETRA).

   The framework is graphically described as follows.
























Contreras, et al.       Expires 1 September 2026                [Page 3]

Internet-Draft  Functional Entities for Reporting Eco-da   February 2026


 +------------------------------------------------------------------+
 |                                                                  |
 |                  (3) Network Domain Level                        |-+
 |                                                                  | |
 +------------------------------------------------------------------+ |
                                                                      |
 (a)              (b)          (c)                                    v
 Inventory        Monitor        DataSheets/DataBase and/or          (g)
 Of identity      Energy        | via API,                           API
 and Capability   Efficiency    | Metadata and other             Service
      ^               ^         | device/component/network     Interface
      |               |         | related information to be:          ^
      |               |         |                                     |
      |               |         |  .Power/Energy related metrics      |
      |               |         |  .Origin of Energy Mix              |
      |               |         |  .Carbon aware based on location    |
      |               |         |                                     |
      |               |         |                                     |
      |               |         v                                     |
 +------------------------------------------------------------------+ |
 |                                                                  | |
 |       (2) controller (collection, compute and aggregate?)        |-+
 |                                                                  |
 +------------------------------------------------------------------+
                 ^                      ^                      ^ |
      (d)        |     (e)              |   (f)                | |
      Inventory  |     Monitor power    |   Control            | |
      Capability |     Proportion       |   (Energy saving     | |
                 |     Energy efficiency|   Functionality      | |
                 |     ratio, power     |   Localized mgmt/    | |
                 |     consumption,     |   network wide mgmt) | |
                 |     etc)             |                      | |
                 |                      |                      | v
 +--------------------------------------------------------------------+
 |                                                                    |
 |                       (1) Device/Component                         |
 |                                                                    |
 | +---------+  +-----------+  +----------------+  +----------------+ |
 | | (I)     |  | (II)      |  | (III)          |  | (IV)           | |
 | |         |  |           |  | Legacy         |  | 'Attached'(PoE | |
 | | Device  |  | Component |  | Device         |  | end Point)     | |
 | |         |  |           |  |                |  |                | |
 | +---------+  +-----------+  +----------------+  +----------------+ |
 +--------------------------------------------------------------------+







Contreras, et al.       Expires 1 September 2026                [Page 4]

Internet-Draft  Functional Entities for Reporting Eco-da   February 2026


   Interfaces (a–g) define how discovery, monitoring, metrics, control,
   and higher-level service APIs interact across levels.  The
   description of such interfaces is provided in
   [I-D.belmq-green-framework].

4.  Overview of the Functional Blocks

   Distinct functions can be considered to collectively enable energy
   measurement, attribution, optimization, incentives and
   service-variant orchestration.  Altogether define a functional
   blueprint applicable to any network domain.  Such a blueprint
   contains three planes, i.e. User, Control, and Management planes,
   that can be mapped onto the general IETF GREEN Framework.

   The functional blocks are:

   *  Service Energy Information Function (SEIF): this function is
      responsible for attributing resource-level energy measurements to
      service-level energy consumption.  It produces the
      service-oriented energy information consumed by the Reporting
      Function.

   *  Resource Energy Measurement Function (REMF): this function
      measures the energy consumption (and carbon information, when
      available) of any resource in the network domain, providing the
      raw energy telemetry used by higher-level functions.

   *  Resource Allocation Function (RAF): this function tracks which
      resources are allocated to which service, maintaining mappings so
      that energy usage can later be attributed correctly.

   *  Service Directory Function (SDF): this function maintains the list
      of active services and maps each service identifier to the service
      instances running in the domain

   *  Orchestration and Optimization Function (O2F): this orchestration
      function optimizes and manages service placement and lifecycle
      from an energy-aware perspective.  It could include capabilities
      such as optimal placement, service lifecycle, incentives, etc.

   *  Reporting Function (RF): this function is in charge of
      consolidating the eco-data information and reporting it by means
      such as APIs (for instance, [I-D.petra-green-api] or
      [I-D.amalj-sustain-shape]).







Contreras, et al.       Expires 1 September 2026                [Page 5]

Internet-Draft  Functional Entities for Reporting Eco-da   February 2026


5.  Mapping of Functions to the GREEN Framework

   Next sub-sections describe a potential mapping of functions to GREEN
   framework levels.

5.1.  Device & Component Level

   GREEN defines Energy Objects, meters, PoE endpoints, components, and
   their topological relations (source, metering, aggregation).  The
   Resource Energy Measurement Function (REMF) corresponds precisely to
   the acquisition of energy measurements from such Energy Objects and
   exposes the resource-level consumption that Service Energy
   Information Function (SEIF) later attributes.

   As result, the following mapping can apply:

   *  GREEN Energy Objects → network domain resources

   *  GREEN Metering Interfaces → REMF measurement sources

   *  Physical or virtual meters → REMF telemetry ingestion points

5.2.  Controller Level

   The GREEN Controller Level aggregates metrics, correlates contextual
   information, and executes energy-aware control policies.

   +---------------------------+----------------------------------+
   | GREEN Controller Function |         Functional Block         |
   +---------------------------+----------------------------------+
   | Energy Aggregation and    | SEIF (service-level attribution  |
   | Metrics Processing        | from REMF + RAF)                 |
   +---------------------------+----------------------------------+
   | Inventory and Resource    | RAF (mapping SF→resource) + SDF  |
   | Mapping                   |                                  |
   +---------------------------+----------------------------------+
   | Energy-Aware Control      | O2F (left for further study      |
   |                           | in future versions)              |
   +---------------------------+----------------------------------+

   The Service Energy Information Function (SEIF) specifically associate
   the metrics of relevance for the service of interest.









Contreras, et al.       Expires 1 September 2026                [Page 6]

Internet-Draft  Functional Entities for Reporting Eco-da   February 2026


5.3.  Network-Domain Level

   The GREEN Network Domain Level includes repositories and domain-wide
   inventories.  All the eco-data information which cannot be
   automatically retrieved from the network or the devices can be
   gathered from here, such as values reported in datasheets,
   consumption models (e.g., dependent on the network or device load),
   etc.

5.4.  Reporting Function

   The Reporting Function (RF) aligns with the GREEN Service API
   mechanism when responding to service-energy queries, similar to
   PETRA’s [I-D.petra-green-api] [I-D.amalj-sustain-shape] aggregated,
   service-path–relevant reporting.  The RF exposes ecodata reports as
   domain-level exported information consumable by higher-layer
   orchestrators.  This is also where PETRA-compatible energy views may
   be offered for inter-domain composition.

6.  Mapping of Process Flows and Interfaces

   The interfaces defined in the IETF GREEN Framework can be mapped to
   the propsoed funcitonal blocks as follows:

   *  GREEN Discovery Interfaces (a,d): SDF and RAF consume resource and
      service inventories from the domain

   *  Monitoring Interfaces (b,e): REMF streams energy measurements
      consistent with GREEN’s monitoring and accuracy model (push-based,
      hierarchical inheritance, accuracy classifications).

   *  Metrics Interfaces (c): SEIF transforms RAW metrics from REMF into
      service-level ones using RAF mappings—analogous to GREEN’s derived
      metrics and efficiency computations.

   *  Control Interface (f): An Optimization Function can executes
      lifecycle, energy-variant optimization, and domain
      reallocation—aligned with GREEN’s energy-saving control interface.
      This optimization function is left for further analysis in future
      versions of this document.

   *  Service API Interface (g): The RF exposes ecodata for inter-domain
      or multi-layer energy composition, conceptually similar to PETRA’s
      recursive API-exposed energy reporting.







Contreras, et al.       Expires 1 September 2026                [Page 7]

Internet-Draft  Functional Entities for Reporting Eco-da   February 2026


7.  Handling Double Counting

   In order to allow per-service eco-data reporting it is necessary to
   rely on service-instance identifiers and ecodata merging rules to
   avoid double counting across domains.  The IETF GREEN Framework
   defines metering and power-source relationships to prevent
   aggregation of identical values from upstream/downstream Energy
   Objects.

   In consequence, it is necessary to combine the per-service tagging
   approach with the proposed IETF GREEN relationship modelling to
   ensure correct aggregation across layers and domains.

   This combined approach is left for further work in future versions of
   this document.

8.  Security Considerations

   Security considerations adhere the IETF GREEN Framework focus on
   protecting power-state control, integrity of telemetry,
   confidentiality of measurement data, and authentication for all
   control and monitoring interfaces.

   More detailed analysis will be provided in future versions of the
   document.

9.  IANA Considerations

   This document makes no IANA requests.

10.  Informative References

   [I-D.amalj-sustain-shape]
              Sánchez, A. G., Rodriguez-Natal, A., Contreras, L. M.,
              Palmero, M. P., and J. Lindblad, "Sustainability holistic
              API for Path Energy Evaluation (SHAPE)", Work in Progress,
              Internet-Draft, draft-amalj-sustain-shape-01, 27 February
              2026, <https://datatracker.ietf.org/doc/html/draft-amalj-
              sustain-shape-01>.

   [I-D.belmq-green-framework]
              Claise, B., Contreras, L. M., Lindblad, J., Palmero, M.
              P., Stephan, E., and Q. Wu, "Framework for Energy
              Efficiency Management", Work in Progress, Internet-Draft,
              draft-belmq-green-framework-10, 8 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-belmq-green-
              framework-10>.




Contreras, et al.       Expires 1 September 2026                [Page 8]

Internet-Draft  Functional Entities for Reporting Eco-da   February 2026


   [I-D.petra-green-api]
              Rodriguez-Natal, A., Contreras, L. M., Palmero, M. P.,
              Lindblad, J., and A. G. Sánchez, "Path Energy Traffic
              Ratio API (PETRA)", Work in Progress, Internet-Draft,
              draft-petra-green-api-02, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-petra-green-
              api-02>.

Acknowledgements

   This work has been partially funded by the Smart Networks and
   Services Joint Undertaking (SNS JU) under the European Union's
   Horizon Europe research and innovation project Exigence (Grant
   Agreement no. 101139120).

Authors' Addresses

   Luis M. Contreras
   Telefonica
   Ronda de la Comunicacion, s/n
   28050 Madrid
   Spain
   Email: luismiguel.contrerasmurillo@telefonica.com
   URI:   http://lmcontreras.com


   Guillermo Sanchez-Illan
   Telefonica
   Ronda de la Comunicacion, s/n
   28050 Madrid
   Spain
   Email: guillermo.sanchezillan@telefonica.com


   Artur Hecker
   Huawei Technologies
   Germany
   Email: artur.hecker@huawei.com


   Osama Abboud
   Huawei Technologies
   Germany
   Email: osama.abboud@huawei.com







Contreras, et al.       Expires 1 September 2026                [Page 9]
