<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc linkmailto="no" ?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-references-in-index="yes" ?>

<!DOCTYPE rfc []>

<rfc category="std" docName="draft-neumann-green-streaming-yang-00" ipr="trust200902" submissionType="IETF">
  <front>
    <title abbrev="Energy YANG Model for Streaming">YANG Data Model for Energy Measurements in Streaming Devices</title>

    <author fullname="Dom Robinson" initials="D." surname="Dom">
      <organization>id3as</organization>
      <address>
        <postal>
          <street>20 Rowan Way</street>
          <city>Brighton, Sussex</city>
          <country>UK</country>
        </postal>
        <email>dom@id3as.co.uk</email>
      </address>
    </author>

    <author fullname="Benjamin Schwarz" initials="B." surname="Benjamin">
      <organization>CTOiC</organization>
      <address>
        <postal>
          <street>89, rue des Poissonniers</street>
          <city>Paris</city>
          <country>France</country>
        </postal>
        <email>bs@ctoic.net</email>
      </address>
    </author>

    <author initials='C.' surname='Christoph' fullname='Christoph Neumann'>
    <organization>Broadpeak</organization>
    <address>
    <postal>
    <street>15, rue Claude Chappe</street>
    <city>Cesson-Sevigne</city>
    <code>35510</code>
    <country>France</country>
    </postal>
    <email>christoph.neumann@broadpeak.tv</email></address>
    </author>

    <date year="2025"/>

    <abstract>
      <t>
        This document defines a YANG data model for representing energy 
        measurements from streaming-capable devices. The model supports both
        instantaneous power readings and correlated streaming metrics needed
        to analyze energy efficiency in streaming applications.
      </t>
    </abstract>

    <note title="Requirements Language">
      <t>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
      <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all
      capitals, as shown here.</t>
    </note>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>
        The increasing focus on environmental sustainability in streaming
        media delivery requires accurate measurement and analysis of energy
        consumption across the delivery chain. This document defines a YANG
        data model for reporting energy measurements from streaming-capable
        devices, along with relevant streaming metrics needed for correlation
        and analysis.
      </t>
      <t>
        The model is designed to support both A-side (mains power) and B-side
        (internal component) power measurements while maintaining clear
        distinction between these measurement types.
        The internal component usage may be used by a collecting entity to 
        estimate the total device power used if such 
        power measurements are not available within the device.
      </t>
    </section>

    <section anchor="yang-model-structure" title="YANG Model Structure">
      <t>
        The proposed YANG model defines a comprehensive framework for representing energy
        measurements in streaming devices. The model is structured around four
        key components that together provide a complete picture of device
        energy consumption and its relationship to streaming activities.
      </t>

      <section anchor="energy-measurement-data" title="Energy Measurement Data">
        <t>
          The core of the model focuses on both instantaneous and historical
          power measurements. This dual approach allows for real-time
          monitoring as well as trend analysis. The model distinguishes
          between total system power (A-side) and component-level power
          (B-side) measurements to support different measurement capabilities
          across device types.
        </t>
      </section>

      <section anchor="device-identification" title="Device Identification and Capabilities">
        <t>
          Proper device identification and capability reporting is important
          for accurate data interpretation. This component allows devices
          to clearly communicate their measurement capabilities, ensuring
          that data consumers can properly interpret and validate the
          reported measurements.
        </t>
      </section>

      <section anchor="streaming-metrics" title="Streaming-related Metrics">
        <t>
          To enable meaningful energy efficiency analysis, the model includes
          streaming-specific metrics that can be correlated with power
          measurements. These metrics provide essential context for
          understanding energy consumption patterns in relation to actual
          streaming activities.
        </t>
      </section>

    </section>

    <section anchor="yang-module" title="YANG Module">
      <figure>
        <artwork><![CDATA[
module: eyang
  +--rw energy-measurements
     +--rw device-info
     |  +--rw device-id          string
     |  +--rw device-type        enumeration
     |  +--rw measurement-capabilities
     |     +--rw supports-mains-power?      boolean
     |     +--rw supports-component-power?  boolean
     |     +--rw supports-component-usage?  boolean
     +--rw power-readings
     |  +--rw timestamp                    yang:timestamp
     |  +--rw mains-power
     |  |  +--rw watts?                    decimal64
     |  +--rw component-power
     |  |  +--rw cpu-watts?                decimal64
     |  |  +--rw gpu-watts?                decimal64
     |  |  +--rw memory-watts?             decimal64
     |  |  +--rw network-watts?            decimal64
     |  +--rw component-usage
     |     +--rw cpu-usage?                decimal64
     |     +--rw gpu-usage?                decimal64
     |     +--rw memory-usage?             decimal64
     |     +--rw network-usage?            decimal64
     +--rw streaming-metrics
        +--rw active-streams?              uint32
        +--rw total-bandwidth-mbps?        decimal64
        +--rw video-brightness?            uint8
        +--rw encoding-parameters?         string
        +--rw network-utilization?         decimal64
        ]]></artwork>
      </figure>
    </section>

    <section anchor="json-encoding" title="JSON Encoding">
      <t>
        The following shows the JSON schema for data exchange:
      </t>
      <figure>
        <artwork><![CDATA[
{
  "energy-measurements": {
    "device-info": {
      "device-id": "string",
      "device-type": "string",
      "measurement-capabilities": {
        "supports-mains-power": boolean,
        "supports-component-power": boolean
        "supports-component-usage": boolean
      }
    },
    "power-readings": {
      "timestamp": "string",
      "mains-power": {
        "watts": number,
      },
      "component-power": {
        "cpu-watts": number,
        "gpu-watts": number,
        "memory-watts": number,
        "network-watts": number
      },
      "component-usage": {
        "cpu-usage": number,
        "gpu-usage": number,
        "memory-usage": number,
        "network-usage": number
      }      
    },
    "streaming-metrics": {
      "active-streams": number,
      "total-bandwidth-mbps": number,
      "video-brightness": number,
      "encoding-parameters": "string",
      "network-utilization": number
    }
  }
}
        ]]></artwork>
      </figure>
    </section>

    <section anchor="data-model-details" title="Data Model Details">
      <section anchor="device-info" title="Device Information">
        <ul>
          <li>
          device-id: Opaque identifier for the device. 
          Device identification is important for proper data attribution and
          analysis. 
        </li>
        <li>
          device-type: The device-type enumeration is chosen to
          cover the major categories of streaming infrastructure while
          remaining extensible for future devices. Each device type may
          have different measurement capabilities and characteristics that
          affect how their energy data should be interpreted.
          One of: encoder, decoder, cdn-cache, router, switch,
                settop-box, tv, mobile-device   
        </li>  
        </ul> 
      </section>

      <section anchor="measurement-capabilities" title="Measurement Capabilities">
        <t>
          The capability reporting mechanism allows devices to explicitly
          declare their measurement abilities. This is essential because:
        </t>
        <ul>
          <li>Not all devices can measure both mains and component power</li>
          <li>Measurement methods may vary in accuracy and reliability</li>
          <li>Some devices may only support subset of measurements</li>
        </ul>
        <t>
          This information helps data consumers properly interpret and
          validate the reported measurements.  
          The following attributes indicates which types of power measurements the device supports:
        </t>
        <ul>
          <li>supports-mains-power: Device can report total power draw</li>
          <li>supports-component-power: Device can report component-level power</li>   
          <li>supports-component-usage: Device can report component-level usage</li>   
        </ul> 
      </section>

      <section anchor="power-readings" title="Power Readings">
        <t>
          Power readings are structured to support both high-level and
          detailed energy analysis:
        </t>
        <ul>
          <li>timestamp: UTC timestamp of measurement. Timestamp precision is critical for correlation analysis</li>
          <li>mains-power: Total power draw from mains (A-side measurement). Mains power provides system-level energy perspective</li>
          <li>component-power: Individual component power measurements (B-side). Component power enables detailed efficiency analysis</li>
          <li>component-usage: Individual component measurements usage (B-side). Component usage enables estimating the power used if such 
        power measurements are not available within the device. </li>
        </ul>
      </section>

      <section anchor="streaming-metrics-detail" title="Streaming Metrics">
        <t>
          The streaming metrics are selected to enable use-case that require correlation
          analyses:
        </t>
        <ul>
          <li>active-streams: Number of active streaming sessions as an indicator for system load</li>
          <li>total-bandwidth-mbps: Current bandwidth utilization as an indicator for network utilization</li>
          <li>video-brightness: Average screen brightness (0-255)</li>
          <li>encoding-parameters: Active encoding settings that may affect processing requirements</li>
          <li>network-utilization: Network interface utilization (%)</li>
        </ul>
        <t>
          These metrics were chosen based on empirical research showing
          their relevance to energy consumption patterns.
        </t>
      </section>
    </section>

    <section  title="Acknowledgement">
        <t>
    This draft has been elaborated in the context of the working group 7 of Greening of Streaming.
        </t>    
    </section>

  </middle>

  <back>
    <references title="Normative References">
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
    <front>
        <title>Key words for use in RFCs to Indicate Requirement Levels</title>
        <author fullname="S. Bradner" initials="S." surname="Bradner"/>
        <date month="March" year="1997"/>
        <abstract>
        <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
        </abstract>
    </front>
    <seriesInfo name="BCP" value="14"/>
    <seriesInfo name="RFC" value="2119"/>
    <seriesInfo name="DOI" value="10.17487/RFC2119"/>
    </reference>

    <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
    <front>
        <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
        <author fullname="B. Leiba" initials="B." surname="Leiba"/>
        <date month="May" year="2017"/>
        <abstract>
        <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
        </abstract>
    </front>
    <seriesInfo name="BCP" value="14"/>
    <seriesInfo name="RFC" value="8174"/>
    <seriesInfo name="DOI" value="10.17487/RFC8174"/>
    </reference>
    </references>
  </back>
</rfc>
